aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-10-28tty: serial: 21285: fix lockup on openRussell King1-6/+6
Commit 293f89959483 ("tty: serial: 21285: stop using the unused[] variable from struct uart_port") introduced a bug which stops the transmit interrupt being disabled when there are no characters to transmit - disabling the transmit interrupt at the interrupt controller is the only way to stop an interrupt storm. If this interrupt is not disabled when there are no transmit characters, we end up with an interrupt storm which prevents the machine making forward progress. Fixes: 293f89959483 ("tty: serial: 21285: stop using the unused[] variable from struct uart_port") Signed-off-by: Russell King <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28USB: apple-mfi-fastcharge: don't probe unhandled devicesBastien Nocera1-5/+12
From: Bastien Nocera <[email protected]> Contrary to the comment above the id table, we didn't implement a match function. This meant that every single Apple device that was already plugged in to the computer would have its device driver reprobed when the apple-mfi-fastcharge driver was loaded, eg. the SD card reader could be reprobed when the apple-mfi-fastcharge after pivoting root during boot up and the module became available. Make sure that the driver probe isn't being run for unsupported devices by adding a match function that checks the product ID, in addition to the id_table checking the vendor ID. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1878347 Link: https://lore.kernel.org/linux-usb/CAE3RAxt0WhBEz8zkHrVO5RiyEOasayy1QUAjsv-pB0fAbY1GSw@mail.gmail.com/ Fixes: 249fa8217b84 ("USB: Add driver to control USB fast charge for iOS devices") Cc: <[email protected]> # 5.8 Cc: Greg Kroah-Hartman <[email protected]> Cc: Alan Stern <[email protected]> [m.v.b: Add Link and Reported-by tags to the commit message] Reported-by: Pany <[email protected]> Tested-by: Pan (Pany) YUAN <[email protected]> Tested-by: Bastien Nocera <[email protected]> Signed-off-by: Bastien Nocera <[email protected]> Signed-off-by: M. Vefa Bicakci <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usbcore: Check both id_table and match() when both availableBastien Nocera3-12/+24
From: Bastien Nocera <[email protected]> When a USB device driver has both an id_table and a match() function, make sure to check both to find a match, first matching the id_table, then checking the match() function. This makes it possible to have module autoloading done through the id_table when devices are plugged in, before checking for further device eligibility in the match() function. Cc: <[email protected]> # 5.8 Cc: Greg Kroah-Hartman <[email protected]> Cc: Alan Stern <[email protected]> Co-developed-by: M. Vefa Bicakci <[email protected]> Tested-by: Bastien Nocera <[email protected]> Signed-off-by: Bastien Nocera <[email protected]> Signed-off-by: M. Vefa Bicakci <[email protected]> Tested-by: Pan (Pany) YUAN <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: host: ehci-tegra: Fix error handling in tegra_ehci_probe()Tang Bin1-2/+2
If the function platform_get_irq() failed, the negative value returned will not be detected here. So fix error handling in tegra_ehci_probe(). Fixes: 79ad3b5add4a ("usb: host: Add EHCI driver for NVIDIA Tegra SoCs") Acked-by: Alan Stern <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Tang Bin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: typec: stusb160x: fix an IS_ERR() vs NULL check in probeDan Carpenter1-2/+2
The typec_register_port() function doesn't return NULL, it returns error pointers. Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/20201023114017.GE18329@kadam Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: typec: tcpm: reset hard_reset_count for any disconnectLi Jun1-3/+3
Current tcpm_detach() only reset hard_reset_count if port->attached is true, this may cause this counter clear is missed if the CC disconnect event is generated after tcpm_port_reset() is done by other events, e.g. VBUS off comes first before CC disconect for a power sink, in that case the first tcpm_detach() will only clear port->attached flag but leave hard_reset_count there because tcpm_port_is_disconnected() is still false, then later tcpm_detach() by CC disconnect will directly return due to port->attached is cleared, finally this will result tcpm will not try hard reset or error recovery for later attach. ChiYuan reported this issue on his platform with below tcpm trace: After power sink session setup after hard reset 2 times, detach from the power source and then attach: [ 4848.046358] VBUS off [ 4848.046384] state change SNK_READY -> SNK_UNATTACHED [ 4848.050908] Setting voltage/current limit 0 mV 0 mA [ 4848.050936] polarity 0 [ 4848.052593] Requesting mux state 0, usb-role 0, orientation 0 [ 4848.053222] Start toggling [ 4848.086500] state change SNK_UNATTACHED -> TOGGLING [ 4848.089983] CC1: 0 -> 0, CC2: 3 -> 3 [state TOGGLING, polarity 0, connected] [ 4848.089993] state change TOGGLING -> SNK_ATTACH_WAIT [ 4848.090031] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @200 ms [ 4848.141162] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_ATTACH_WAIT, polarity 0, disconnected] [ 4848.141170] state change SNK_ATTACH_WAIT -> SNK_ATTACH_WAIT [ 4848.141184] pending state change SNK_ATTACH_WAIT -> SNK_UNATTACHED @20 ms [ 4848.163156] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [delayed 20 ms] [ 4848.163162] Start toggling [ 4848.216918] CC1: 0 -> 0, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 4848.216954] state change TOGGLING -> SNK_ATTACH_WAIT [ 4848.217080] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @200 ms [ 4848.231771] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_ATTACH_WAIT, polarity 0, disconnected] [ 4848.231800] state change SNK_ATTACH_WAIT -> SNK_ATTACH_WAIT [ 4848.231857] pending state change SNK_ATTACH_WAIT -> SNK_UNATTACHED @20 ms [ 4848.256022] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [delayed20 ms] [ 4848.256049] Start toggling [ 4848.871148] VBUS on [ 4848.885324] CC1: 0 -> 0, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] [ 4848.885372] state change TOGGLING -> SNK_ATTACH_WAIT [ 4848.885548] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @200 ms [ 4849.088240] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed200 ms] [ 4849.088284] state change SNK_DEBOUNCED -> SNK_ATTACHED [ 4849.088291] polarity 1 [ 4849.088769] Requesting mux state 1, usb-role 2, orientation 2 [ 4849.088895] state change SNK_ATTACHED -> SNK_STARTUP [ 4849.088907] state change SNK_STARTUP -> SNK_DISCOVERY [ 4849.088915] Setting voltage/current limit 5000 mV 0 mA [ 4849.088927] vbus=0 charge:=1 [ 4849.090505] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES [ 4849.090828] pending state change SNK_WAIT_CAPABILITIES -> SNK_READY @240 ms [ 4849.335878] state change SNK_WAIT_CAPABILITIES -> SNK_READY [delayed240 ms] this patch fix this issue by clear hard_reset_count at any cases of cc disconnect, í.e. don't check port->attached flag. Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging") Cc: [email protected] Reported-and-tested-by: ChiYuan Huang <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Li Jun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: cdc-acm: fix cooldown mechanismJerome Brunet2-9/+6
Commit a4e7279cd1d1 ("cdc-acm: introduce a cool down") is causing regression if there is some USB error, such as -EPROTO. This has been reported on some samples of the Odroid-N2 using the Combee II Zibgee USB dongle. > struct acm *acm = container_of(work, struct acm, work) is incorrect in case of a delayed work and causes warnings, usually from the workqueue: > WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:1474 __queue_work+0x480/0x528. When this happens, USB eventually stops working completely after a while. Also the ACM_ERROR_DELAY bit is never set, so the cooldown mechanism previously introduced cannot be triggered and acm_submit_read_urb() is never called. This changes makes the cdc-acm driver use a single delayed work, fixing the pointer arithmetic in acm_softint() and set the ACM_ERROR_DELAY when the cooldown mechanism appear to be needed. Fixes: a4e7279cd1d1 ("cdc-acm: introduce a cool down") Cc: Oliver Neukum <[email protected]> Reported-by: Pascal Vizeli <[email protected]> Acked-by: Oliver Neukum <[email protected]> Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: host: fsl-mph-dr-of: check return of dma_set_mask()Ran Wang1-3/+6
fsl_usb2_device_register() should stop init if dma_set_mask() return error. Fixes: cae058610465 ("drivers/usb/host: fsl: Set DMA_MASK of usb platform device") Reviewed-by: Peter Chen <[email protected]> Signed-off-by: Ran Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28usb: fix kernel-doc markupsMauro Carvalho Chehab4-4/+4
There is a common comment marked, instead, with kernel-doc notation. Also, some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Felipe Balbi <[email protected]> Link: https://lore.kernel.org/r/0b964be3884def04fcd20ea5c12cb90d0014871c.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28RDMA: Add rdma_connect_locked()Jason Gunthorpe4-15/+43
There are two flows for handling RDMA_CM_EVENT_ROUTE_RESOLVED, either the handler triggers a completion and another thread does rdma_connect() or the handler directly calls rdma_connect(). In all cases rdma_connect() needs to hold the handler_mutex, but when handler's are invoked this is already held by the core code. This causes ULPs using the 2nd method to deadlock. Provide a rdma_connect_locked() and have all ULPs call it from their handlers. Link: https://lore.kernel.org/r/[email protected] Reported-and-tested-by: Guoqing Jiang <[email protected]> Fixes: 2a7cec538169 ("RDMA/cma: Fix locking for the RDMA_CM_CONNECT state") Acked-by: Santosh Shilimkar <[email protected]> Acked-by: Jack Wang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Max Gurtovoy <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-10-28usb: typec: stusb160x: fix some signedness bugsDan Carpenter1-3/+4
These variables are enums but in this situation GCC will treat them as unsigned so the conditions are never true. Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/20201023112412.GD282278@mwanda Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28drm/shme-helpers: Fix dma_buf_mmap forwarding bugDaniel Vetter2-3/+8
When we forward an mmap to the dma_buf exporter, they get to own everything. Unfortunately drm_gem_mmap_obj() overwrote vma->vm_private_data after the driver callback, wreaking the exporter complete. This was noticed because vb2_common_vm_close blew up on mali gpu with panfrost after commit 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf"). Unfortunately drm_gem_mmap_obj also acquires a surplus reference that we need to drop in shmem helpers, which is a bit of a mislayer situation. Maybe the entire dma_buf_mmap forwarding should be pulled into core gem code. Note that the only two other drivers which forward mmap in their own code (etnaviv and exynos) get this somewhat right by overwriting the gem mmap code. But they seem to still have the leak. This might be a good excuse to move these drivers over to shmem helpers completely. Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Christian König <[email protected]> Cc: Christian König <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: Lucas Stach <[email protected]> Cc: Russell King <[email protected]> Cc: Christian Gmeiner <[email protected]> Cc: Inki Dae <[email protected]> Cc: Joonyoung Shim <[email protected]> Cc: Seung-Woo Kim <[email protected]> Cc: Kyungmin Park <[email protected]> Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf") Cc: Boris Brezillon <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rob Herring <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v5.9+ Reported-and-tested-by: [email protected] Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-28mmc: sdhci-of-esdhc: make sure delay chain locked for HS400Yangbo Lu2-0/+19
For eMMC HS400 mode initialization, the DLL reset is a required step if DLL is enabled to use previously, like in bootloader. This step has not been documented in reference manual, but the RM will be fixed sooner or later. This patch is to add the step of DLL reset, and make sure delay chain locked for HS400. Signed-off-by: Yangbo Lu <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 54e08d9a95ca ("mmc: sdhci-of-esdhc: add hs400 mode support") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-10-28usb: cdns3: Variable 'length' set but not usedPawel Laszczak1-2/+0
Patch removes not used variable 'length' from cdns3_wa2_descmiss_copy_data function. Fixes: 141e70fef4ee ("usb: cdns3: gadget: need to handle sg case for workaround 2 case") Acked-by: Roger Quadros <[email protected]> Signed-off-by: Pawel Laszczak <[email protected]> Signed-off-by: Peter Chen <[email protected]>
2020-10-27null_blk: synchronization fix for zoned deviceKanchan Joshi2-4/+19
Parallel write,read,zone-mgmt operations accessing/altering zone state and write-pointer may get into race. Avoid the situation by using a new spinlock for zoned device. Concurrent zone-appends (on a zone) returning same write-pointer issue is also avoided using this lock. Cc: [email protected] Fixes: e0489ed5daeb ("null_blk: Support REQ_OP_ZONE_APPEND") Signed-off-by: Kanchan Joshi <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-10-27ibmveth: Fix use of ibmveth in a bridge.Thomas Bogendoerfer1-6/+0
The check for src mac address in ibmveth_is_packet_unsupported is wrong. Commit 6f2275433a2f wanted to shut down messages for loopback packets, but now suppresses bridged frames, which are accepted by the hypervisor otherwise bridging won't work at all. Fixes: 6f2275433a2f ("ibmveth: Detect unsupported packets before sending to the hypervisor") Signed-off-by: Michal Suchanek <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-10-27ravb: Fix bit fields checking in ravb_hwtstamp_get()Andrew Gabbasov1-3/+7
In the function ravb_hwtstamp_get() in ravb_main.c with the existing values for RAVB_RXTSTAMP_TYPE_V2_L2_EVENT (0x2) and RAVB_RXTSTAMP_TYPE_ALL (0x6) if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_V2_L2_EVENT) config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L2_EVENT; else if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_ALL) config.rx_filter = HWTSTAMP_FILTER_ALL; if the test on RAVB_RXTSTAMP_TYPE_ALL should be true, it will never be reached. This issue can be verified with 'hwtstamp_config' testing program (tools/testing/selftests/net/hwtstamp_config.c). Setting filter type to ALL and subsequent retrieving it gives incorrect value: $ hwtstamp_config eth0 OFF ALL flags = 0 tx_type = OFF rx_filter = ALL $ hwtstamp_config eth0 flags = 0 tx_type = OFF rx_filter = PTP_V2_L2_EVENT Correct this by converting if-else's to switch. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Reported-by: Julia Lawall <[email protected]> Signed-off-by: Andrew Gabbasov <[email protected]> Reviewed-by: Sergei Shtylyov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-10-27chelsio/chtls: fix memory leaks in CPL handlersVinay Kumar Yadav1-15/+12
CPL handler functions chtls_pass_open_rpl() and chtls_close_listsrv_rpl() should return CPL_RET_BUF_DONE so that caller function will do skb free to avoid leak. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Vinay Kumar Yadav <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-10-27chelsio/chtls: fix deadlock issueVinay Kumar Yadav1-2/+0
In chtls_pass_establish() we hold child socket lock using bh_lock_sock and we are again trying bh_lock_sock in add_to_reap_list, causing deadlock. Remove bh_lock_sock in add_to_reap_list() as lock is already held. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Vinay Kumar Yadav <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-10-27Merge tag 'x86-urgent-2020-10-27' of ↵Linus Torvalds1-1/+8
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A couple of x86 fixes which missed rc1 due to my stupidity: - Drop lazy TLB mode before switching to the temporary address space for text patching. text_poke() switches to the temporary mm which clears the lazy mode and restores the original mm afterwards. Due to clearing lazy mode this might restore a already dead mm if exit_mmap() runs in parallel on another CPU. - Document the x32 syscall design fail vs. syscall numbers 512-547 properly. - Fix the ORC unwinder to handle the inactive task frame correctly. This was unearthed due to the slightly different code generation of gcc-10. - Use an up to date screen_info for the boot params of kexec instead of the possibly stale and invalid version which happened to be valid when the kexec kernel was loaded" * tag 'x86-urgent-2020-10-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/alternative: Don't call text_poke() in lazy TLB mode x86/syscalls: Document the fact that syscalls 512-547 are a legacy mistake x86/unwind/orc: Fix inactive tasks with stack pointer in %sp on GCC 10 compiled kernels hyperv_fb: Update screen_info after removing old framebuffer x86/kexec: Use up-to-dated screen_info copy to fill boot params
2020-10-27drm/vc4: hdmi: Avoid sleeping in atomic contextMaxime Ripard1-2/+3
When running the trigger hook, ALSA by default will take a spinlock, and thus will run the trigger hook in atomic context. However, our HDMI driver will send the infoframes as part of the trigger hook, and part of that process is to wait for a bit to be cleared for up to 100ms. To be nicer to the system, that wait has some usleep_range that interact poorly with the atomic context. There's several ways we can fix this, but the more obvious one is to make ALSA take a mutex instead by setting the nonatomic flag on the DAI link. That doesn't work though, since now the cyclic callback installed by the dmaengine helpers in ALSA will take a mutex, while that callback is run by dmaengine's virt-chan code in a tasklet where sleeping is not allowed either. Given the delay we need to poll the bit for, changing the usleep_range for a udelay and keep running it from a context where interrupts are disabled is not really a good option either. However, we can move the infoframe setup code in the hw_params hook, like is usually done in other HDMI controllers, that isn't protected by a spinlock and thus where we can sleep. Infoframes will be sent on a regular basis anyway, and since hw_params is where the audio parameters that end up in the infoframes are setup, this also makes a bit more sense. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Suggested-by: Mark Brown <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Mark Brown <[email protected]> Reviewed-by: Takashi Iwai <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-27ACPI: NFIT: Fix comparison to '-ENXIO'Zhang Qilong1-1/+1
Initial value of rc is '-ENXIO', and we should use the initial value to check it. Signed-off-by: Zhang Qilong <[email protected]> Reviewed-by: Pankaj Gupta <[email protected]> Reviewed-by: Vishal Verma <[email protected]> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-27ACPI: dock: fix enum-conversion warningArnd Bergmann1-1/+2
gcc points out a type mismatch: drivers/acpi/dock.c: In function 'hot_remove_dock_devices': drivers/acpi/dock.c:234:53: warning: implicit conversion from 'enum <anonymous>' to 'enum dock_callback_type' [-Wenum-conversion] 234 | dock_hotplug_event(dd, ACPI_NOTIFY_EJECT_REQUEST, false); This is harmless because 'false' still has the correct numeric value, but passing DOCK_CALL_HANDLER documents better what is going on and avoids the warning. Fixes: 37f908778f20 ("ACPI / dock: Walk list in reverse order during removal of devices") Fixes: f09ce741a03a ("ACPI / dock / PCI: Drop ACPI dock notifier chain") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Hanjun Guo <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-27PNP: fix kernel-doc markupsMauro Carvalho Chehab1-2/+2
It sounds that there were function renames. Update the kernel-doc markups accordingly. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-27device property: Don't clear secondary pointer for shared primary firmware nodeAndy Shevchenko1-1/+3
It appears that firmware nodes can be shared between devices. In such case when a (child) device is about to be deleted, its firmware node may be shared and ACPI_COMPANION_SET(..., NULL) call for it breaks the secondary link of the shared primary firmware node. In order to prevent that, check, if the device has a parent and parent's firmware node is shared with its child, and avoid crashing the link. Fixes: c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") Reported-by: Ferry Toth <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Tested-by: Ferry Toth <[email protected]> Cc: 5.9+ <[email protected]> # 5.9+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-27device property: Keep secondary firmware node secondary by typeAndy Shevchenko1-1/+1
Behind primary and secondary we understand the type of the nodes which might define their ordering. However, if primary node gone, we can't maintain the ordering by definition of the linked list. Thus, by ordering secondary node becomes first in the list. But in this case the meaning of it is still secondary (or auxiliary). The type of the node is maintained by the secondary pointer in it: secondary pointer Meaning NULL or valid primary node ERR_PTR(-ENODEV) secondary node So, if by some reason we do the following sequence of calls set_primary_fwnode(dev, NULL); set_primary_fwnode(dev, primary); we should preserve secondary node. This concept is supported by the description of set_primary_fwnode() along with implementation of set_secondary_fwnode(). Hence, fix the commit c15e1bdda436 to follow this as well. Fixes: c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()") Cc: Ferry Toth <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Tested-by: Ferry Toth <[email protected]> Cc: 5.9+ <[email protected]> # 5.9+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-27drm/amdgpu/pm: fix the fan speed in fan1_input in manual mode for navi1xAlex Deucher1-8/+3
It has been confirmed that the SMU metrics table should always reflect the current fan speed even in manual mode. Fixes: 3033e9f1c2de ("drm/amdgpu/swsmu: handle manual fan readback on SMU11") Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-27drm/amd/pm: fix the wrong fan speed in fan1_inputKenneth Feng1-8/+3
fix the wrong fan speed in fan1_input when the fan control mode is manual. the fan speed value is not correct when we set manual mode to fan1_enalbe - 1. since the fan speed in the metrics table always reflects the real fan speed,we can fetch the fan speed for both auto and manual mode. Signed-off-by: Kenneth Feng <[email protected]> Reviewed-by: Likun Gao <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-27drm/amdgpu/swsmu: drop smu i2c bus on navi1xAlex Deucher1-25/+0
Stop registering the SMU i2c bus on navi1x. This leads to instability issues when userspace processes mess with the bus and also seems to cause display stability issues in some cases. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1314 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1341 Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-10-27intel_idle: Fix max_cstate for processor models without C-state tablesChen Yu1-1/+1
Currently intel_idle driver gets the c-state information from ACPI _CST if the processor model is not recognized by it. However the c-state in _CST starts with index 1 which is different from the index in intel_idle driver's internal c-state table. While intel_idle_max_cstate_reached() was previously introduced to deal with intel_idle driver's internal c-state table, re-using this function directly on _CST is incorrect. Fix this by subtracting 1 from the index when checking max_cstate in the _CST case. For example, append intel_idle.max_cstate=1 in boot command line, Before the patch: grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name POLL After the patch: grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name /sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1_ACPI Fixes: 18734958e9bf ("intel_idle: Use ACPI _CST for processor models without C-state tables") Reported-by: Pengfei Xu <[email protected]> Cc: 5.6+ <[email protected]> # 5.6+ Signed-off-by: Chen Yu <[email protected]> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-27cpufreq: intel_pstate: Avoid missing HWP max updates in passive modeRafael J. Wysocki1-7/+6
If the cpufreq policy max limit is changed when intel_pstate operates in the passive mode with HWP enabled and the "powersave" governor is used on top of it, the HWP max limit is not updated as appropriate. Namely, in the "powersave" governor case, the target P-state is always equal to the policy min limit, so if the latter does not change, intel_cpufreq_adjust_hwp() is not invoked to update the HWP Request MSR due to the "target_pstate != old_pstate" check in intel_cpufreq_update_pstate(), so the HWP max limit is not updated as a result. Also, if the CPUFREQ_NEED_UPDATE_LIMITS flag is not set for the driver and the target frequency does not change along with the policy max limit, the "target_freq == policy->cur" check in __cpufreq_driver_target() prevents the driver's ->target() callback from being invoked at all, so the HWP max limit is not updated. To prevent that occurring, set the CPUFREQ_NEED_UPDATE_LIMITS flag in the intel_cpufreq driver structure if HWP is enabled and modify intel_cpufreq_update_pstate() to do the "target_pstate != old_pstate" check only in the non-HWP case and let intel_cpufreq_adjust_hwp() always run in the HWP case (it will update HWP Request only if the cached value of the register is different from the new one including the limits, so if neither the target P-state value nor the max limit changes, the register write will still be avoided). Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Reported-by: Zhang Rui <[email protected]> Cc: 5.9+ <[email protected]> # 5.9+: 1c534352f47f cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS ... Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]> Tested-by: Zhang Rui <[email protected]>
2020-10-27cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS driver flagRafael J. Wysocki1-1/+2
Generally, a cpufreq driver may need to update some internal upper and lower frequency boundaries on policy max and min changes, respectively, but currently this does not work if the target frequency does not change along with the policy limit. Namely, if the target frequency does not change along with the policy min or max, the "target_freq == policy->cur" check in __cpufreq_driver_target() prevents driver callbacks from being invoked and they do not even have a chance to update the corresponding internal boundary. This particularly affects the "powersave" and "performance" governors that always set the target frequency to one of the policy limits and it never changes when the other limit is updated. To allow cpufreq the drivers needing to update internal frequency boundaries on policy limits changes to avoid this issue, introduce a new driver flag, CPUFREQ_NEED_UPDATE_LIMITS, that (when set) will neutralize the check mentioned above. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-10-27cpufreq: Avoid configuring old governors as default with intel_pstateRafael J. Wysocki1-0/+2
Commit 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") was meant to cause intel_pstate to be used in the passive mode with the schedutil governor on top of it, but it missed the case in which either "ondemand" or "conservative" was selected as the default governor in the existing kernel config, in which case the previous old governor configuration would be used, causing the default legacy governor to be used on top of intel_pstate instead of schedutil. Address this by preventing "ondemand" and "conservative" from being configured as the default cpufreq governor in the case when schedutil is the default choice for the default governor setting. [Note that the default cpufreq governor can still be set via the kernel command line if need be and that choice is not limited, so if anyone really wants to use one of the legacy governors by default, it can be achieved this way.] Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") Reported-by: Julia Lawall <[email protected]> Cc: 5.8+ <[email protected]> # 5.8+ Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-10-27cpufreq: e_powersaver: remove unreachable breakZhang Qilong2-2/+0
A 'break' following a 'return' statement is pointless, so remove it. Signed-off-by: Zhang Qilong <[email protected]> Acked-by: Viresh Kumar <[email protected]> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-27Merge tag 'devicetree-fixes-for-5.10-1' of ↵Linus Torvalds1-2/+11
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - More binding additionalProperties/unevaluatedProperties additions - More yamllint fixes on additions in the merge window - CrOS embedded controller schema updates to fix warnings - LEDs schema update adding ID_RGB - A reserved-memory fix for regions starting at address 0x0 * tag 'devicetree-fixes-for-5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: dt-bindings: Another round of adding missing 'additionalProperties/unevalutatedProperties' dt-bindings: Explicitly allow additional properties in board/SoC schemas dt-bindings: More whitespace clean-ups in schema files mfd: google,cros-ec: add missing properties dt-bindings: input: convert cros-ec-keyb to json-schema dt-bindings: i2c: convert i2c-cros-ec-tunnel to json-schema of: Fix reserved-memory overlap detection dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value dt-bindings: leds: Update devicetree documents for ID_RGB
2020-10-27drm/vc4: drv: Add error handding for bindHoegeun Kwon1-0/+1
There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-27interconnect: qcom: use icc_sync state for sm8[12]50Dmitry Baryshkov2-6/+8
In addition to the rest of Qcom interconnect drivers use icc_sync_state for SM8150/SM8250 interconnect drivers to notify the interconnect framework when all consumers are probed and there is no need to keep the bandwidth set to maximum anymore. Also move the BCM initialization before creating the nodes to set the max bandwidth in hardware for the initialization/probing stage. Signed-off-by: Dmitry Baryshkov <[email protected]> Fixes: 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-10-27staging: fieldbus: anybuss: jump to correct label in an error pathJing Xiangfeng1-1/+1
In current code, controller_probe() misses to call ida_simple_remove() in an error path. Jump to correct label to fix it. Fixes: 17614978ed34 ("staging: fieldbus: anybus-s: support the Arcx anybus controller") Reviewed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Jing Xiangfeng <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-27staging: wfx: fix test on return value of gpiod_get_value()Jérôme Pouiller1-1/+1
The commit 8522d62e6bca ("staging: wfx: gpiod_get_value() can return an error") has changed the way the driver test the value returned by gpiod_get_value(). The new code was wrong. Fixes: 8522d62e6bca ("staging: wfx: gpiod_get_value() can return an error") Signed-off-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-27staging: wfx: fix use of uninitialized pointerJérôme Pouiller1-3/+3
With -Wuninitialized, the compiler complains: drivers/staging/wfx/data_tx.c:34:19: warning: variable 'band' is uninitialized when used here [-Wuninitialized] if (rate->idx >= band->n_bitrates) { ^~~~ Reported-by: kernel test robot <[email protected]> Reported-by: Nathan Chancellor <[email protected]> Fixes: 868fd970e187 ("staging: wfx: improve robustness of wfx_get_hw_rate()") Signed-off-by: Jérôme Pouiller <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-27staging: mmal-vchiq: Fix memory leak for vchiq_instanceSeung-Woo Kim1-4/+15
The vchiq_instance is allocated with vchiq_initialise() but never freed properly. Fix memory leak for the vchiq_instance. Reported-by: Jaehoon Chung <[email protected]> Signed-off-by: Seung-Woo Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-27staging: comedi: cb_pcidas: Allow 2-channel commands for AO subdeviceIan Abbott1-0/+1
The "cb_pcidas" driver supports asynchronous commands on the analog output (AO) subdevice for those boards that have an AO FIFO. The code (in `cb_pcidas_ao_check_chanlist()` and `cb_pcidas_ao_cmd()`) to validate and set up the command supports output to a single channel or to two channels simultaneously (the boards have two AO channels). However, the code in `cb_pcidas_auto_attach()` that initializes the subdevices neglects to initialize the AO subdevice's `len_chanlist` member, leaving it set to 0, but the Comedi core will "correct" it to 1 if the driver neglected to set it. This limits commands to use a single channel (either channel 0 or 1), but the limit should be two channels. Set the AO subdevice's `len_chanlist` member to be the same value as the `n_chan` member, which will be 2. Cc: <[email protected]> Signed-off-by: Ian Abbott <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-27staging: octeon: Drop on uncorrectable alignment or FCS errorAlexander Sverdlin1-15/+19
Currently in case of alignment or FCS error if the packet cannot be corrected it's still not dropped. Report the error properly and drop the packet while making the code around a little bit more readable. Fixes: 80ff0fd3ab64 ("Staging: Add octeon-ethernet driver files.") Signed-off-by: Alexander Sverdlin <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-27staging: octeon: repair "fixed-link" supportAlexander Sverdlin2-6/+9
The PHYs must be registered once in device probe function, not in device open callback because it's only possible to register them once. Fixes: a25e278020bf ("staging: octeon: support fixed-link phys") Signed-off-by: Alexander Sverdlin <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-27drm: kernel-doc: add description for a new function parameterMauro Carvalho Chehab1-0/+1
As reported by "make htmldocs": ./drivers/gpu/drm/drm_prime.c:808: warning: Function parameter or member 'dev' not described in 'drm_prime_pages_to_sg' Add a description for the new parameter. Fixes: 707d561f77b5 ("drm: allow limiting the scatter list size.") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Gerd Hoffmann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/9366f48e6e9c3ec2f31a3e68452a2b23a1089fce.1603791716.git.mchehab+huawei@kernel.org
2020-10-27drm/dp: fix a kernel-doc issue at drm_edid.cMauro Carvalho Chehab1-1/+1
The name of the argument is different, causing those warnings: ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member 'video_code' not described in 'drm_display_mode_from_cea_vic' ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 'vic' description in 'drm_display_mode_from_cea_vic' Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()") Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7f4d6c3ff6df63ebd006eb90a5108006c23e2168.1603791716.git.mchehab+huawei@kernel.org
2020-10-27drm/dp: fix kernel-doc warnings at drm_dp_helper.cMauro Carvalho Chehab1-0/+5
As warned by kernel-doc: ./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or member 'type' not described in 'drm_dp_downstream_is_type' ./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or member 'dev' not described in 'drm_dp_downstream_mode' Some function parameters weren't documented. Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port types") Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/03c9c8ba3f492aca76e2b4836803219cd9c971cf.1603791716.git.mchehab+huawei@kernel.org
2020-10-27drm: kernel-doc: document drm_dp_set_subconnector_property() paramsMauro Carvalho Chehab1-1/+6
Changeset e5b92773287c ("drm: report dp downstream port type as a subconnector property") added a new function to the kAPI, but didn't add any documentation for the parameters for drm_dp_set_subconnector_property(). Fixes: e5b92773287c ("drm: report dp downstream port type as a subconnector property") Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/0870be85a77bea4ba5cf1715010834289a4e10b1.1603791716.git.mchehab+huawei@kernel.org
2020-10-27nvmet: fix a NULL pointer dereference when tracing the flush commandChaitanya Kulkarni2-16/+9
When target side trace in turned on and flush command is issued from the host it results in the following Oops. [ 856.789724] BUG: kernel NULL pointer dereference, address: 0000000000000068 [ 856.790686] #PF: supervisor read access in kernel mode [ 856.791262] #PF: error_code(0x0000) - not-present page [ 856.791863] PGD 6d7110067 P4D 6d7110067 PUD 66f0ad067 PMD 0 [ 856.792527] Oops: 0000 [#1] SMP NOPTI [ 856.792950] CPU: 15 PID: 7034 Comm: nvme Tainted: G OE 5.9.0nvme-5.9+ #71 [ 856.793790] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e3214 [ 856.794956] RIP: 0010:trace_event_raw_event_nvmet_req_init+0x13e/0x170 [nvmet] [ 856.795734] Code: 41 5c 41 5d c3 31 d2 31 f6 e8 4e 9b b8 e0 e9 0e ff ff ff 49 8b 55 00 48 8b 38 8b 0 [ 856.797740] RSP: 0018:ffffc90001be3a60 EFLAGS: 00010246 [ 856.798375] RAX: 0000000000000000 RBX: ffff8887e7d2c01c RCX: 0000000000000000 [ 856.799234] RDX: 0000000000000020 RSI: 0000000057e70ea2 RDI: ffff8887e7d2c034 [ 856.800088] RBP: ffff88869f710578 R08: ffff888807500d40 R09: 00000000fffffffe [ 856.800951] R10: 0000000064c66670 R11: 00000000ef955201 R12: ffff8887e7d2c034 [ 856.801807] R13: ffff88869f7105c8 R14: 0000000000000040 R15: ffff88869f710440 [ 856.802667] FS: 00007f6a22bd8780(0000) GS:ffff888813a00000(0000) knlGS:0000000000000000 [ 856.803635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 856.804367] CR2: 0000000000000068 CR3: 00000006d73e0000 CR4: 00000000003506e0 [ 856.805283] Call Trace: [ 856.805613] nvmet_req_init+0x27c/0x480 [nvmet] [ 856.806200] nvme_loop_queue_rq+0xcb/0x1d0 [nvme_loop] [ 856.806862] blk_mq_dispatch_rq_list+0x123/0x7b0 [ 856.807459] ? kvm_sched_clock_read+0x14/0x30 [ 856.808025] __blk_mq_sched_dispatch_requests+0xc7/0x170 [ 856.808708] blk_mq_sched_dispatch_requests+0x30/0x60 [ 856.809372] __blk_mq_run_hw_queue+0x70/0x100 [ 856.809935] __blk_mq_delay_run_hw_queue+0x156/0x170 [ 856.810574] blk_mq_run_hw_queue+0x86/0xe0 [ 856.811104] blk_mq_sched_insert_request+0xef/0x160 [ 856.811733] blk_execute_rq+0x69/0xc0 [ 856.812212] ? blk_mq_rq_ctx_init+0xd0/0x230 [ 856.812784] nvme_execute_passthru_rq+0x57/0x130 [nvme_core] [ 856.813461] nvme_submit_user_cmd+0xeb/0x300 [nvme_core] [ 856.814099] nvme_user_cmd.isra.82+0x11e/0x1a0 [nvme_core] [ 856.814752] blkdev_ioctl+0x1dc/0x2c0 [ 856.815197] block_ioctl+0x3f/0x50 [ 856.815606] __x64_sys_ioctl+0x84/0xc0 [ 856.816074] do_syscall_64+0x33/0x40 [ 856.816533] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 856.817168] RIP: 0033:0x7f6a222ed107 [ 856.817617] Code: 44 00 00 48 8b 05 81 cd 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 8 [ 856.819901] RSP: 002b:00007ffca848f058 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [ 856.820846] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f6a222ed107 [ 856.821726] RDX: 00007ffca848f060 RSI: 00000000c0484e43 RDI: 0000000000000003 [ 856.822603] RBP: 0000000000000003 R08: 000000000000003f R09: 0000000000000005 [ 856.823478] R10: 00007ffca848ece0 R11: 0000000000000202 R12: 00007ffca84912d3 [ 856.824359] R13: 00007ffca848f4d0 R14: 0000000000000002 R15: 000000000067e900 [ 856.825236] Modules linked in: nvme_loop(OE) nvmet(OE) nvme_fabrics(OE) null_blk nvme(OE) nvme_corel Move the nvmet_req_init() tracepoint after we parse the command in nvmet_req_init() so that we can get rid of the duplicate nvmet_find_namespace() call. Rename __assign_disk_name() -> __assign_req_name(). Now that we call tracepoint after parsing the command simplify the newly added __assign_req_name() which fixes this bug. Signed-off-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2020-10-27nvme-fc: remove nvme_fc_terminate_io()James Smart1-33/+16
__nvme_fc_terminate_io() is now called by only 1 place, in reset_work. Consoldate and move the functionality of terminate_io into reset_work. In reset_work, rather than calling the create_association directly, schedule the connect work element to do its thing. After scheduling, flush the connect work element to continue with semantic of not returning until connect has been attempted at least once. Signed-off-by: James Smart <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.