aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-28kselftest/arm64: Fix check_buffer_fill testVincenzo Frascino1-0/+3
The check_buffer_fill test reports the error below because the test plan is not declared correctly: # Planned tests != run tests (0 != 20) Fix the test adding the correct test plan declaration. Fixes: e9b60476bea0 ("kselftest/arm64: Add utilities and a test to validate mte memory") Signed-off-by: Vincenzo Frascino <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Gabor Kertesz <[email protected]> Cc: Amit Daniel Kachhap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28arm64: avoid -Woverride-init warningArnd Bergmann2-3/+5
The icache_policy_str[] definition causes a warning when extra warning flags are enabled: arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field overwritten [-Woverride-init] 38 | [ICACHE_POLICY_VIPT] = "VIPT", | ^~~~~~ arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for 'icache_policy_str[2]') arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field overwritten [-Woverride-init] 39 | [ICACHE_POLICY_PIPT] = "PIPT", | ^~~~~~ arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for 'icache_policy_str[3]') arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field overwritten [-Woverride-init] 40 | [ICACHE_POLICY_VPIPT] = "VPIPT", | ^~~~~~~ arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for 'icache_policy_str[0]') There is no real need for the default initializer here, as printing a NULL string is harmless. Rewrite the logic to have an explicit reserved value for the only one that uses the default value. This partially reverts the commit that removed ICACHE_POLICY_AIVIVT. Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-10-28ACPI: button: Drop no longer necessary Acer SW5-012 lid_init_state quirkHans de Goede1-13/+0
Commit 78a5b53e9fb4 ("Input: soc_button_array - work around DSDTs which modify the irqflags") adds a workaround for DSDTs with a _LID method which play tricks with the irqflags, assuming that the OS is using an irq-type of IRQ_TYPE_LEVEL_LOW. Now that this workaround is in place, we no longer need to disable the lid functionality on the Acer SW5-012. Fixes: 78a5b53e9fb4 ("Input: soc_button_array - work around DSDTs which modify the irqflags") Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-10-28RDMA/qedr: Fix memory leak in iWARP CMAlok Prasad1-0/+1
Fixes memory leak in iWARP CM Fixes: e411e0587e0d ("RDMA/qedr: Add iWARP connection management functions") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Kalderon <[email protected]> Signed-off-by: Igor Russkikh <[email protected]> Signed-off-by: Alok Prasad <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-10-28vt_ioctl: fix GIO_UNIMAP regressionJiri Slaby1-6/+5
In commit 5ba127878722, we shuffled with the check of 'perm'. But my brain somehow inverted the condition in 'do_unimap_ioctl' (I thought it is ||, not &&), so GIO_UNIMAP stopped working completely. Move the 'perm' checks back to do_unimap_ioctl and do them right again. In fact, this reverts this part of code to the pre-5ba127878722 state. Except 'perm' is now a bool. Fixes: 5ba127878722 ("vt_ioctl: move perm checks level up") Cc: [email protected] Reported-by: Fabian Vogt <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28vt: keyboard, extend func_buf_lock to readersJiri Slaby1-4/+13
Both read-side users of func_table/func_buf need locking. Without that, one can easily confuse the code by repeatedly setting altering strings like: while (1) for (a = 0; a < 2; a++) { struct kbsentry kbs = {}; strcpy((char *)kbs.kb_string, a ? ".\n" : "88888\n"); ioctl(fd, KDSKBSENT, &kbs); } When that program runs, one can get unexpected output by holding F1 (note the unxpected period on the last line): . 88888 .8888 So protect all accesses to 'func_table' (and func_buf) by preexisting 'func_buf_lock'. It is easy in 'k_fn' handler as 'puts_queue' is expected not to sleep. On the other hand, KDGKBSENT needs a local (atomic) copy of the string because copy_to_user can sleep. Use already allocated, but unused 'kbs->kb_string' for that purpose. Note that the program above needs at least CAP_SYS_TTY_CONFIG. This depends on the previous patch and on the func_buf_lock lock added in commit 46ca3f735f34 (tty/vt: fix write/write race in ioctl(KDSKBSENT) handler) in 5.2. Likely fixes CVE-2020-25656. Cc: <[email protected]> Reported-by: Minh Yuan <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28vt: keyboard, simplify vt_kdgkbsentJiri Slaby1-19/+9
Use 'strlen' of the string, add one for NUL terminator and simply do 'copy_to_user' instead of the explicit 'for' loop. This makes the KDGKBSENT case more compact. The only thing we need to take care about is NULL 'func_table[i]'. Use an empty string in that case. The original check for overflow could never trigger as the func_buf strings are always shorter or equal to 'struct kbsentry's. Cc: <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-10-28tty: serial: fsl_lpuart: LS1021A has a FIFO size of 16 words, like LS1028AVladimir Oltean1-6/+7
Prior to the commit that this one fixes, the FIFO size was derived from the read-only register LPUARTx_FIFO[TXFIFOSIZE] using the following formula: TX FIFO size = 2 ^ (LPUARTx_FIFO[TXFIFOSIZE] - 1) The documentation for LS1021A is a mess. Under chapter 26.1.3 LS1021A LPUART module special consideration, it mentions TXFIFO_SZ and RXFIFO_SZ being equal to 4, and in the register description for LPUARTx_FIFO, it shows the out-of-reset value of TXFIFOSIZE and RXFIFOSIZE fields as "011", even though these registers read as "101" in reality. And when LPUART on LS1021A was working, the "101" value did correspond to "16 datawords", by applying the formula above, even though the documentation is wrong again (!!!!) and says that "101" means 64 datawords (hint: it doesn't). So the "new" formula created by commit f77ebb241ce0 has all the premises of being wrong for LS1021A, because it relied only on false data and no actual experimentation. Interestingly, in commit c2f448cff22a ("tty: serial: fsl_lpuart: add LS1028A support"), Michael Walle applied a workaround to this by manually setting the FIFO widths for LS1028A. It looks like the same values are used by LS1021A as well, in fact. When the driver thinks that it has a deeper FIFO than it really has, getty (user space) output gets truncated. Many thanks to Michael for pointing out where to look. Fixes: f77ebb241ce0 ("tty: serial: fsl_lpuart: correct the FIFO depth size") Suggested-by: Michael Walle <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by：Fugang Duan <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
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 Chehab5-5/+5
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 Gunthorpe6-29/+48
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-28KVM: arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIREDStephen Boyd3-3/+3
According to the SMCCC spec[1](7.5.2 Discovery) the ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and SMCCC_RET_NOT_SUPPORTED. 0 is "workaround required and safe to call this function" 1 is "workaround not required but safe to call this function" SMCCC_RET_NOT_SUPPORTED is "might be vulnerable or might not be, who knows, I give up!" SMCCC_RET_NOT_SUPPORTED might as well mean "workaround required, except calling this function may not work because it isn't implemented in some cases". Wonderful. We map this SMC call to 0 is SPECTRE_MITIGATED 1 is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE For KVM hypercalls (hvc), we've implemented this function id to return SMCCC_RET_NOT_SUPPORTED, 0, and SMCCC_RET_NOT_REQUIRED. One of those isn't supposed to be there. Per the code we call arm64_get_spectre_v2_state() to figure out what to return for this feature discovery call. 0 is SPECTRE_MITIGATED SMCCC_RET_NOT_REQUIRED is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE Let's clean this up so that KVM tells the guest this mapping: 0 is SPECTRE_MITIGATED 1 is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE Note: SMCCC_RET_NOT_AFFECTED is 1 but isn't part of the SMCCC spec Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests") Signed-off-by: Stephen Boyd <[email protected]> Acked-by: Marc Zyngier <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: Andre Przywara <[email protected]> Cc: Steven Price <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: [email protected] Link: https://developer.arm.com/documentation/den0028/latest [1] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[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-27net: protect tcf_block_unbind with block lockLeon Romanovsky1-2/+2
The tcf_block_unbind() expects that the caller will take block->cb_lock before calling it, however the code took RTNL lock and dropped cb_lock instead. This causes to the following kernel panic. WARNING: CPU: 1 PID: 13524 at net/sched/cls_api.c:1488 tcf_block_unbind+0x2db/0x420 Modules linked in: mlx5_ib mlx5_core mlxfw ptp pps_core act_mirred act_tunnel_key cls_flower vxlan ip6_udp_tunnel udp_tunnel dummy sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad ib_ipoib rdma_cm iw_cm ib_cm ib_uverbs ib_core overlay [last unloaded: mlxfw] CPU: 1 PID: 13524 Comm: test-ecmp-add-v Tainted: G W 5.9.0+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:tcf_block_unbind+0x2db/0x420 Code: ff 48 83 c4 40 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8d bc 24 30 01 00 00 be ff ff ff ff e8 7d 7f 70 00 85 c0 0f 85 7b fd ff ff <0f> 0b e9 74 fd ff ff 48 c7 c7 dc 6a 24 84 e8 02 ec fe fe e9 55 fd RSP: 0018:ffff888117d17968 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88812f713c00 RCX: 1ffffffff0848d5b RDX: 0000000000000001 RSI: ffff88814fbc8130 RDI: ffff888107f2b878 RBP: 1ffff11022fa2f3f R08: 0000000000000000 R09: ffffffff84115a87 R10: fffffbfff0822b50 R11: ffff888107f2b898 R12: ffff88814fbc8000 R13: ffff88812f713c10 R14: ffff888117d17a38 R15: ffff88814fbc80c0 FS: 00007f6593d36740(0000) GS:ffff8882a4f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005607a00758f8 CR3: 0000000131aea006 CR4: 0000000000170ea0 Call Trace: tc_block_indr_cleanup+0x3e0/0x5a0 ? tcf_block_unbind+0x420/0x420 ? __mutex_unlock_slowpath+0xe7/0x610 flow_indr_dev_unregister+0x5e2/0x930 ? mlx5e_restore_tunnel+0xdf0/0xdf0 [mlx5_core] ? mlx5e_restore_tunnel+0xdf0/0xdf0 [mlx5_core] ? flow_indr_block_cb_alloc+0x3c0/0x3c0 ? mlx5_db_free+0x37c/0x4b0 [mlx5_core] mlx5e_cleanup_rep_tx+0x8b/0xc0 [mlx5_core] mlx5e_detach_netdev+0xe5/0x120 [mlx5_core] mlx5e_vport_rep_unload+0x155/0x260 [mlx5_core] esw_offloads_disable+0x227/0x2b0 [mlx5_core] mlx5_eswitch_disable_locked.cold+0x38e/0x699 [mlx5_core] mlx5_eswitch_disable+0x94/0xf0 [mlx5_core] mlx5_device_disable_sriov+0x183/0x1f0 [mlx5_core] mlx5_core_sriov_configure+0xfd/0x230 [mlx5_core] sriov_numvfs_store+0x261/0x2f0 ? sriov_drivers_autoprobe_store+0x110/0x110 ? sysfs_file_ops+0x170/0x170 ? sysfs_file_ops+0x117/0x170 ? sysfs_file_ops+0x170/0x170 kernfs_fop_write+0x1ff/0x3f0 ? rcu_read_lock_any_held+0x6e/0x90 vfs_write+0x1f3/0x620 ksys_write+0xf9/0x1d0 ? __x64_sys_read+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3f0 ? syscall_enter_from_user_mode+0x1d/0x50 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 <...> ---[ end trace bfdd028ada702879 ]--- Fixes: 0fdcf78d5973 ("net: use flow_indr_dev_setup_offload()") Signed-off-by: Leon Romanovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[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-27net/sched: act_mpls: Add softdep on mpls_gso.koGuillaume Nault1-0/+1
TCA_MPLS_ACT_PUSH and TCA_MPLS_ACT_MAC_PUSH might be used on gso packets. Such packets will thus require mpls_gso.ko for segmentation. v2: Drop dependency on CONFIG_NET_MPLS_GSO in Kconfig (from Jakub and David). Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC") Signed-off-by: Guillaume Nault <[email protected]> Link: https://lore.kernel.org/r/1f6cab15bbd15666795061c55563aaf6a386e90e.1603708007.git.gnault@redhat.com 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-27devlink: Unlock on error in dumpit()Dan Carpenter1-2/+4
This needs to unlock before returning. Fixes: 544e7c33ec2f ("net: devlink: Add support for port regions") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/20201026080127.GB1628785@mwanda Signed-off-by: Jakub Kicinski <[email protected]>
2020-10-27devlink: Fix some error codesDan Carpenter1-9/+15
These paths don't set the error codes. It's especially important in devlink_nl_region_notify_build() where it leads to a NULL dereference in the caller. Fixes: 544e7c33ec2f ("net: devlink: Add support for port regions") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/20201026080059.GA1628785@mwanda 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-27x86/debug: Fix DR_STEP vs ptrace_get_debugreg(6)Peter Zijlstra1-3/+6
Commit d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6") changed the semantics of the variable from random collection of bits, to exactly only those bits that ptrace() needs. Unfortunately this lost DR_STEP for PTRACE_{BLOCK,SINGLE}STEP. Furthermore, it turns out that userspace expects DR_STEP to be unconditionally available, even for manual TF usage outside of PTRACE_{BLOCK,SINGLE}_STEP. Fixes: d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6") Reported-by: Kyle Huey <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Kyle Huey <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-27x86/debug: Only clear/set ->virtual_dr6 for userspace #DBPeter Zijlstra1-6/+6
The ->virtual_dr6 is the value used by ptrace_{get,set}_debugreg(6). A kernel #DB clearing it could mean spurious malfunction of ptrace() expectations. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Kyle Huey <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-27x86/debug: Fix BTF handlingPeter Zijlstra1-7/+21
The SDM states that #DB clears DEBUGCTLMSR_BTF, this means that when the bit is set for userspace (TIF_BLOCKSTEP) and a kernel #DB happens first, the BTF bit meant for userspace execution is lost. Have the kernel #DB handler restore the BTF bit when it was requested for userspace. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Kyle Huey <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-27afs: Fix afs_launder_page to not clear PG_writebackDavid Howells2-4/+7
Fix afs_launder_page() to not clear PG_writeback on the page it is laundering as the flag isn't set in this case. Fixes: 4343d00872e1 ("afs: Get rid of the afs_writeback record") Signed-off-by: David Howells <[email protected]>
2020-10-27afs: Fix a use after free in afs_xattr_get_acl()Dan Carpenter1-1/+1
The "op" pointer is freed earlier when we call afs_put_operation(). Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: David Howells <[email protected]> cc: Colin Ian King <[email protected]>
2020-10-27afs: Fix tracing deref-before-checkDavid Howells1-1/+2
The patch dca54a7bbb8c: "afs: Add tracing for cell refcount and active user count" from Oct 13, 2020, leads to the following Smatch complaint: fs/afs/cell.c:596 afs_unuse_cell() warn: variable dereferenced before check 'cell' (see line 592) Fix this by moving the retrieval of the cell debug ID to after the check of the validity of the cell pointer. Reported-by: Dan Carpenter <[email protected]> Fixes: dca54a7bbb8c ("afs: Add tracing for cell refcount and active user count") Signed-off-by: David Howells <[email protected]> cc: Dan Carpenter <[email protected]>
2020-10-27afs: Fix copy_file_range()David Howells1-0/+1
The prevention of splice-write without explicit ops made the copy_file_write() syscall to an afs file (as done by the generic/112 xfstest) fail with EINVAL. Fix by using iter_file_splice_write() for afs. Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Signed-off-by: David Howells <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2020-10-27Merge tag 'x86-urgent-2020-10-27' of ↵Linus Torvalds5-15/+25
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-27dt-bindings: memory: tegra: Add missing swgroupsNicolin Chen1-0/+10
According to Tegra X1 TRM, there are missing swgroups in the tegra210_swgroups list. So this patch adds them in bindings. Note that the TEGRA_SWGROUP_GPU (in list) should be actually TEGRA_SWGROUP_GPUB (in TRM), yet TEGRA_SWGROUP_GPU (in TRM) is not being used -- only TEGRA_SWGROUP_GPUB (in TRM) is. So this patch does not add TEGRA_SWGROUP_GPU (in TRM) and keeps TEGRA_SWGROUP_GPU (in list) as it is. Signed-off-by: Nicolin Chen <[email protected]> Acked-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2020-10-27Merge tag 'orphan-handling-v5.10-rc2' of ↵Linus Torvalds2-0/+5
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull orphan section fixes from Kees Cook: "A couple corner cases were found from the link-time orphan section handling series: - arm: handle .ARM.exidx and .ARM.extab sections (Nathan Chancellor) - x86: collect .ctors.* with .ctors (Kees Cook)" * tag 'orphan-handling-v5.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: arm/build: Always handle .ARM.exidx and .ARM.extab sections vmlinux.lds.h: Keep .ctors.* with .ctors
2020-10-27mm/process_vm_access: Add missing #include <linux/compat.h>Geert Uytterhoeven1-0/+1
With e.g. m68k/defconfig: mm/process_vm_access.c: In function ‘process_vm_rw’: mm/process_vm_access.c:277:5: error: implicit declaration of function ‘in_compat_syscall’ [-Werror=implicit-function-declaration] 277 | in_compat_syscall()); | ^~~~~~~~~~~~~~~~~ Fix this by adding #include <linux/compat.h>. Reported-by: [email protected] Reported-by: damian <[email protected]> Reported-by: Naresh Kamboju <[email protected]> Fixes: 38dc5079da7081e8 ("Fix compat regression in process_vm_rw()") Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Jens Axboe <[email protected]> Signed-off-by: Linus Torvalds <[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-27arm/build: Always handle .ARM.exidx and .ARM.extab sectionsNathan Chancellor1-0/+4
After turning on warnings for orphan section placement, enabling CONFIG_UNWINDER_FRAME_POINTER instead of CONFIG_UNWINDER_ARM causes thousands of warnings when clang + ld.lld are used: $ scripts/config --file arch/arm/configs/multi_v7_defconfig \ -d CONFIG_UNWINDER_ARM \ -e CONFIG_UNWINDER_FRAME_POINTER $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 defconfig zImage ld.lld: warning: init/built-in.a(main.o):(.ARM.extab) is being placed in '.ARM.extab' ld.lld: warning: init/built-in.a(main.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(main.o):(.ARM.extab.ref.text) is being placed in '.ARM.extab.ref.text' ld.lld: warning: init/built-in.a(do_mounts.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(do_mounts.o):(.ARM.extab) is being placed in '.ARM.extab' ld.lld: warning: init/built-in.a(do_mounts_rd.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(do_mounts_rd.o):(.ARM.extab) is being placed in '.ARM.extab' ld.lld: warning: init/built-in.a(do_mounts_initrd.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(initramfs.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(initramfs.o):(.ARM.extab) is being placed in '.ARM.extab' ld.lld: warning: init/built-in.a(calibrate.o):(.ARM.extab.init.text) is being placed in '.ARM.extab.init.text' ld.lld: warning: init/built-in.a(calibrate.o):(.ARM.extab) is being placed in '.ARM.extab' These sections are handled by the ARM_UNWIND_SECTIONS define, which is only added to the list of sections when CONFIG_ARM_UNWIND is set. CONFIG_ARM_UNWIND is a hidden symbol that is only selected when CONFIG_UNWINDER_ARM is set so CONFIG_UNWINDER_FRAME_POINTER never handles these sections. According to the help text of CONFIG_UNWINDER_ARM, these sections should be discarded so that the kernel image size is not affected. Fixes: 5a17850e251a ("arm/build: Warn on orphan section placement") Link: https://github.com/ClangBuiltLinux/linux/issues/1152 Reported-by: kernel test robot <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Review-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> [kees: Made the discard slightly more specific] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[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]>
Powered by cgit, Gruvboxed by Blaster4385.