- 08 May, 2019 38 commits
-
-
Aaro Koskinen authored
[ Upstream commit 583e6361 ] We always program the maximum DMA buffer size into the receive descriptor, although the allocated size may be less. E.g. with the default MTU size we allocate only 1536 bytes. If somebody sends us a bigger frame, then memory may get corrupted. Fix by using exact buffer sizes. Signed-off-by:
Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Konstantin Khorenko authored
[ Upstream commit 18bebc6d ] Bond expects ethernet hwaddr for its slave, but it can be longer than 6 bytes - infiniband interface for example. # cat /sys/devices/<skipped>/net/ib0/address 80:00:02:08:fe:80:00:00:00:00:00:00:7c:fe:90:03:00:be:5d:e1 # cat /sys/devices/<skipped>/net/ib0/bonding_slave/perm_hwaddr 80:00:02:08:fe:80 So print full hwaddr in sysfs "bonding_slave/perm_hwaddr" as well. Signed-off-by:
Konstantin Khorenko <khorenko@virtuozzo.com> Signed-off-by:
-
Omri Kahalon authored
[ Upstream commit eca4a928 ] Traditionally, the PF (Physical Function) which resides on vport 0 was the E-switch manager. Since the ECPF (Embedded CPU Physical Function), which resides on vport 0xfffe, was introduced as the E-Switch manager, the assumption that the E-switch manager is on vport 0 is incorrect. Since the eswitch code already uses the actual vport value, all we need is to always set other_vport=1. Signed-off-by:
Omri Kahalon <omrik@mellanox.com> Reviewed-by:
Max Gurtovoy <maxg@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Xi Wang authored
[ Upstream commit 669efc76 ] Currently, the rules for configuring search paths in Kbuild have changed, this will lead some erros when compiling hns3 with the following command: make O=DIR M=drivers/net/ethernet/hisilicon/hns3 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c:11:10: fatal error: hnae3.h: No such file or directory This patch fix it by adding $(srctree)/ prefix to the serach paths. Signed-off-by:
Xi Wang <wangxi11@huawei.com> Signed-off-by:
-
Jeffrey Hugo authored
[ Upstream commit 2bafa1e9 ] Similar to commit edfc3722 ("HID: quirks: Fix keyboard + touchpad on Toshiba Click Mini not working"), the Lenovo Miix 630 has a combo keyboard/touchpad device with vid:pid of 04F3:0400, which is shared with Elan touchpads. The combo on the Miix 630 has an ACPI id of QTEC0001, which is not claimed by the elan_i2c driver, so key on that similar to what was done for the Toshiba Click Mini. Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Alan Kao authored
[ Upstream commit dbee9c9c ] A memory save operation to 8-byte variable in RV32 is divided into two sw instructions in the put_user macro. The current fixup returns execution flow to the second sw instead of the one after it. This patch fixes this fixup code according to the load access part. Signed-off-by: Alan Kao<alankao@andestech.com> Cc: Greentime Hu <greentime@andestech.com> Cc: Vincent Chen <deanbo422@gmail.com> Signed-off-by:
Palmer Dabbelt <palmer@sifive.com> Signed-off-by:
-
Arvind Sankar authored
[ Upstream commit dabb8338 ] The runtime_suspend device callbacks are not supposed to save configuration state or change the power state. Commit fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend") changed the driver to not save configuration state during runtime suspend, however the driver callback still put the device into a low-power state. This causes a warning in the pci pm core and results in pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend. Fix this by not changing the power state either, leaving that to pci pm core, and make the same change for suspend callback as well. Also move a couple of defines into the appropriate header file instead of inline in the .c file. Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend") Signed-off-by:
Arvind Sankar <niveditas98@gmail.com> Reviewed-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Axel Lin authored
[ Upstream commit 13e8a05b ] Set .owner to prevent module unloading while being used. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Fixes: d903779b ("reset: meson: add meson audio arb driver") Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit d040e4e8 ] The device tree compiler yells like this: Warning (unit_address_vs_reg): /gpu-opp-table/opp@100000000: node has a unit name, but no reg property Let's match the cpu opp node names and use a dash. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Anders Roxell authored
[ Upstream commit ca8c3b92 ] When CONFIG_CFG80211 isn't enabled the compiler correcly warns about 'sinfo.pertid' may be unused. It can also happen for other error conditions that it not warn about. net/batman-adv/bat_v_elp.c: In function ‘batadv_v_elp_get_throughput.isra.0’: include/net/cfg80211.h:6370:13: warning: ‘sinfo.pertid’ may be used uninitialized in this function [-Wmaybe-uninitialized] kfree(sinfo->pertid); ~~~~~^~~~~~~~ Rework so that we only release '&sinfo' if cfg80211_get_station returns zero. Fixes: 7d652669 ("batman-adv: release station info tidstats") Signed-off-by:
Anders Roxell <anders.roxell@linaro.org> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Sven Eckelmann authored
[ Upstream commit f131a568 ] The batadv_hash_remove is a function which searches the hashtable for an entry using a needle, a hashtable bucket selection function and a compare function. It will lock the bucket list and delete an entry when the compare function matches it with the needle. It returns the pointer to the hlist_node which matches or NULL when no entry matches the needle. The batadv_tt_global_free is not itself protected in anyway to avoid that any other function is modifying the hashtable between the search for the entry and the call to batadv_hash_remove. It can therefore happen that the entry either doesn't exist anymore or an entry was deleted which is not the same object as the needle. In such an situation, the reference counter (for the reference stored in the hashtable) must not be reduced for the needle. Instead the reference counter of the actually removed entry has to be reduced. Otherwise the reference counter will underflow and the object might be freed before all its references were dropped. The kref helpers reported this problem as: refcount_t: underflow; use-after-free. Fixes: 7683fdc1 ("batman-adv: protect the local and the global trans-tables with rcu") Reported-by:
Martin Weinelt <martin@linuxlounge.net> Signed-off-by:
Antonio Quartulli <a@unstable.cc> Signed-off-by:
-
Sven Eckelmann authored
[ Upstream commit 3d65b9ac ] The batadv_hash_remove is a function which searches the hashtable for an entry using a needle, a hashtable bucket selection function and a compare function. It will lock the bucket list and delete an entry when the compare function matches it with the needle. It returns the pointer to the hlist_node which matches or NULL when no entry matches the needle. The batadv_tt_local_remove is not itself protected in anyway to avoid that any other function is modifying the hashtable between the search for the entry and the call to batadv_hash_remove. It can therefore happen that the entry either doesn't exist anymore or an entry was deleted which is not the same object as the needle. In such an situation, the reference counter (for the reference stored in the hashtable) must not be reduced for the needle. Instead the reference counter of the actually removed entry has to be reduced. Otherwise the reference counter will underflow and the object might be freed before all its references were dropped. The kref helpers reported this problem as: refcount_t: underflow; use-after-free. Fixes: ef72706a ("batman-adv: protect tt_local_entry from concurrent delete events") Signed-off-by:
-
Sven Eckelmann authored
[ Upstream commit 4ba104f4 ] The batadv_hash_remove is a function which searches the hashtable for an entry using a needle, a hashtable bucket selection function and a compare function. It will lock the bucket list and delete an entry when the compare function matches it with the needle. It returns the pointer to the hlist_node which matches or NULL when no entry matches the needle. The batadv_bla_del_claim is not itself protected in anyway to avoid that any other function is modifying the hashtable between the search for the entry and the call to batadv_hash_remove. It can therefore happen that the entry either doesn't exist anymore or an entry was deleted which is not the same object as the needle. In such an situation, the reference counter (for the reference stored in the hashtable) must not be reduced for the needle. Instead the reference counter of the actually removed entry has to be reduced. Otherwise the reference counter will underflow and the object might be freed before all its references were dropped. The kref helpers reported this problem as: refcount_t: underflow; use-after-free. Fixes: 23721387 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 15d82d22 ] When no alarm has been programmed on RSK-RZA1, an error message is printed during boot: rtc rtc0: invalid alarm value: 2019-03-14T255:255:255 sh_rtc_read_alarm_value() returns 0xff when querying a hardware alarm field that is not enabled. __rtc_read_alarm() validates the received alarm values, and fills in missing fields when needed. While 0xff is handled fine for the year, month, and day fields, and corrected as considered being out-of-range, this is not the case for the hour, minute, and second fields, where -1 is expected for missing fields. Fix this by returning -1 instead, as this value is handled fine for all fields. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit d6752e18 ] If we encounter a failure during suspend where this RTC was programmed to wakeup the system from suspend, but that wakeup couldn't be configured because the system didn't support wakeup interrupts, we'll run into the following warning: Unbalanced IRQ 166 wake disable WARNING: CPU: 7 PID: 3071 at kernel/irq/manage.c:669 irq_set_irq_wake+0x108/0x278 This happens because the suspend process isn't aborted when the RTC fails to configure the wakeup IRQ. Instead, we continue suspending the system and then another suspend callback fails the suspend process and "unwinds" the previously suspended drivers by calling their resume callbacks. When we get back to resuming this RTC driver, we'll call disable_irq_wake() on an IRQ that hasn't been configured for wake. Let's just fail suspend/resume here if we can't configure the system to wake and the user has chosen to wakeup with this device. This fixes this warning and makes the code more robust in case there are systems out there that can't wakeup from suspend on this line but the user has chosen to do so. Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Evan Green <evgreen@chromium.org> Cc: Benson Leung <bleung@chromium.org> Cc: Guenter Roeck <groeck@chromium.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Acked-By:
Benson Leung <bleung@chromium.org> Signed-off-by:
-
He, Bo authored
[ Upstream commit cef0d494 ] There is a race condition that could happen if hid_debug_rdesc_show() is running while hdev is in the process of going away (device removal, system suspend, etc) which could result in NULL pointer dereference: BUG: unable to handle kernel paging request at 0000000783316040 CPU: 1 PID: 1512 Comm: getevent Tainted: G U O 4.19.20-quilt-2e5dc0ac-00029-gc455a447dd55 #1 RIP: 0010:hid_dump_device+0x9b/0x160 Call Trace: hid_debug_rdesc_show+0x72/0x1d0 seq_read+0xe0/0x410 full_proxy_read+0x5f/0x90 __vfs_read+0x3a/0x170 vfs_read+0xa0/0x150 ksys_read+0x58/0xc0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x55/0x110 entry_SYSCALL_64_after_hwframe+0x49/0xbe Grab driver_input_lock to make sure the input device exists throughout the whole process of dumping the rdesc. [jkosina@suse.cz: update changelog a bit] Signed-off-by:
he, bo <bo.he@intel.com> Signed-off-by:
"Zhang, Jun" <jun.zhang@intel.com> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 6c44b15e ] create_singlethread_workqueue may fail and return NULL. The fix checks if it is NULL to avoid NULL pointer dereference. Also, the fix moves the call of create_singlethread_workqueue earlier to avoid resource-release issues. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Signed-off-by:
-
Leonidas P. Papadakos authored
[ Upstream commit 92472688 ] The rk3328-roc-cc board exhibits tx stability issues with large packets, as does the rock64 board, which was fixed with this patch https://patchwork.kernel.org/patch/10178969/ A similar patch was merged for the rk3328-roc-cc here https://patchwork.kernel.org/patch/10804863/ but it doesn't include the tx/rx_delay tweaks, and I find that they help with an issue where large transfers would bring the ethernet link down, causing a link reset regularly. Signed-off-by:
Leonidas P. Papadakos <papadakospan@gmail.com> Signed-off-by:
-
Waiman Long authored
[ Upstream commit ef1491e7 ] The following commit: 9dbbedaa ("efi: Make efi_rts_work accessible to efi page fault handler") converted 'efi_rts_work' from an auto variable to a global variable. However, when submitting the work, INIT_WORK_ONSTACK() was still used, causing the following complaint from debugobjects: ODEBUG: object 00000000ed27b500 is NOT on stack 00000000c7d38760, but annotated. Change the macro to just INIT_WORK() to eliminate the warning. Signed-off-by:
Waiman Long <longman@redhat.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by:
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: 9dbbedaa ("efi: Make efi_rts_work accessible to efi page fault handler") Link: http://lkml.kernel.org/r/20181114175544.12860-2-ard.biesheuvel@linaro.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Yufen Yu authored
[ Upstream commit d11de63f ] After commit 4d43d395 (workqueue: Try to catch flush_work() without INIT_WORK()), it can cause warning when delete nvme-loop device, trace like: [ 76.601272] Call Trace: [ 76.601646] ? del_timer+0x72/0xa0 [ 76.602156] __cancel_work_timer+0x1ae/0x270 [ 76.602791] cancel_work_sync+0x14/0x20 [ 76.603407] nvmet_ctrl_free+0x1b7/0x2f0 [nvmet] [ 76.604091] ? free_percpu+0x168/0x300 [ 76.604652] nvmet_sq_destroy+0x106/0x240 [nvmet] [ 76.605346] nvme_loop_destroy_admin_queue+0x30/0x60 [nvme_loop] [ 76.606220] nvme_loop_shutdown_ctrl+0xc3/0xf0 [nvme_loop] [ 76.607026] nvme_loop_delete_ctrl_host+0x19/0x30 [nvme_loop] [ 76.607871] nvme_do_delete_ctrl+0x75/0xb0 [ 76.608477] nvme_sysfs_delete+0x7d/0xc0 [ 76.609057] dev_attr_store+0x24/0x40 [ 76.609603] sysfs_kf_write+0x4c/0x60 [ 76.610144] kernfs_fop_write+0x19a/0x260 [ 76.610742] __vfs_write+0x1c/0x60 [ 76.611246] vfs_write+0xfa/0x280 [ 76.611739] ksys_write+0x6e/0x120 [ 76.612238] __x64_sys_write+0x1e/0x30 [ 76.612787] do_syscall_64+0xbf/0x3a0 [ 76.613329] entry_SYSCALL_64_after_hwframe+0x44/0xa9 We fix it by moving fatal_err_work init to nvmet_alloc_ctrl(), which may more reasonable. Signed-off-by:
Yufen Yu <yuyufen@huawei.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Alan Stern authored
commit c2b71462 upstream. The syzkaller fuzzer reported a bug in the USB hub driver which turned out to be caused by a negative runtime-PM usage counter. This allowed a hub to be runtime suspended at a time when the driver did not expect it. The symptom is a WARNING issued because the hub's status URB is submitted while it is already active: URB 0000000031fb463e submitted while active WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363 The negative runtime-PM usage count was caused by an unfortunate design decision made when runtime PM was first implemented for USB. At that time, USB class drivers were allowed to unbind from their interfaces without balancing the usage counter (i.e., leaving it with a positive count). The core code would take care of setting the counter back to 0 before allowing another driver to bind to the interface. Later on when runtime PM was implemented for the entire kernel, the opposite decision was made: Drivers were required to balance their runtime-PM get and put calls. In order to maintain backward compatibility, however, the USB subsystem adapted to the new implementation by keeping an independent usage counter for each interface and using it to automatically adjust the normal usage counter back to 0 whenever a driver was unbound. This approach involves duplicating information, but what is worse, it doesn't work properly in cases where a USB class driver delays decrementing the usage counter until after the driver's disconnect() routine has returned and the counter has been adjusted back to 0. Doing so would cause the usage counter to become negative. There's even a warning about this in the USB power management documentation! As it happens, this is exactly what the hub driver does. The kick_hub_wq() routine increments the runtime-PM usage counter, and the corresponding decrement is carried out by hub_event() in the context of the hub_wq work-queue thread. This work routine may sometimes run after the driver has been unbound from its interface, and when it does it causes the usage counter to go negative. It is not possible for hub_disconnect() to wait for a pending hub_event() call to finish, because hub_disconnect() is called with the device lock held and hub_event() acquires that lock. The only feasible fix is to reverse the original design decision: remove the duplicate interface-specific usage counter and require USB drivers to balance their runtime PM gets and puts. As far as I know, all existing drivers currently do this. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com CC: <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
commit c01c348e upstream. Some drivers (such as the vub300 MMC driver) expect usb_string() to return a properly NUL-terminated string, even when an error occurs. (In fact, vub300's probe routine doesn't bother to check the return code from usb_string().) When the driver goes on to use an unterminated string, it leads to kernel errors such as stack-out-of-bounds, as found by the syzkaller USB fuzzer. An out-of-range string index argument is not at all unlikely, given that some devices don't provide string descriptors and therefore list 0 as the value for their string indexes. This patch makes usb_string() return a properly terminated empty string along with the -EINVAL error code when an out-of-range index is encountered. And since a USB string index is a single-byte value, indexes >= 256 are just as invalid as values of 0 or below. Signed-off-by:
-
Malte Leip authored
commit c409ca3b upstream. Change the validation of number_of_packets in get_pipe to compare the number of packets to a fixed maximum number of packets allowed, set to be 1024. This number was chosen due to it being used by other drivers as well, for example drivers/usb/host/uhci-q.c Background/reason: The get_pipe function in stub_rx.c validates the number of packets in isochronous mode and aborts with an error if that number is too large, in order to prevent malicious input from possibly triggering large memory allocations. This was previously done by checking whether pdu->u.cmd_submit.number_of_packets is bigger than the number of packets that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes if all except possibly the last packet had maximum length, given by usb_endpoint_maxp(epd) * usb_endpoint_maxp_mult(epd). This leads to an error if URBs with packets shorter than the maximum possible length are submitted, which is allowed according to Documentation/driver-api/usb/URB.rst and occurs for example with the snd-usb-audio driver. Fixes: c6688ef9 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") Signed-off-by:
Malte Leip <malte@leip.net> Cc: stable <stable@vger.kernel.org> Acked-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Alan Stern authored
commit fc834e60 upstream. The syzkaller USB fuzzer identified a failure mode in which dummy-hcd would never give back an unlinked URB. This causes usb_kill_urb() to hang, leading to WARNINGs and unkillable threads. In dummy-hcd, all URBs are given back by the dummy_timer() routine as it scans through the list of pending URBS. Failure to give back URBs can be caused by failure to start or early exit from the scanning loop. The code currently has two such pathways: One is triggered when an unsupported bus transfer speed is encountered, and the other by exhausting the simulated bandwidth for USB transfers during a frame. This patch removes those two paths, thereby allowing all unlinked URBs to be given back in a timely manner. It adds a check for the bus speed when the gadget first starts running, so that dummy_timer() will never thereafter encounter an unsupported speed. And it prevents the loop from exiting as soon as the total bandwidth has been used up (the scanning loop continues, giving back unlinked URBs as they are found, but not transferring any more data). Thanks to Andrey Konovalov for manually running the syzkaller fuzzer to help track down the source of the bug. Signed-off-by:
-
Alan Stern authored
commit c114944d upstream. The syzkaller USB fuzzer spotted a slab-out-of-bounds bug in the ds2490 driver. This bug is caused by improper use of the altsetting array in the usb_interface structure (the array's entries are not always stored in numerical order), combined with a naive assumption that all interfaces probed by the driver will have the expected number of altsettings. The bug can be fixed by replacing references to the possibly non-existent intf->altsetting[alt] entry with the guaranteed-to-exist intf->cur_altsetting entry. Signed-off-by:
-
Alan Stern authored
commit ef61eb43 upstream. The syzkaller USB fuzzer found a general-protection-fault bug in the yurex driver. The fault occurs when a device has been unplugged; the driver's interrupt-URB handler logs an error message referring to the device by name, after the device has been unregistered and its name deallocated. This problem is caused by the fact that the interrupt URB isn't cancelled until the driver's private data structure is released, which can happen long after the device is gone. The cure is to make sure that the interrupt URB is killed before yurex_disconnect() returns; this is exactly the sort of thing that usb_poison_urb() was meant for. Signed-off-by:
-
Takashi Iwai authored
commit 3887c26c upstream. Some ASUS models like Q325UAR with ALC295 codec requires the same fixup that has been applied to ALC294 codec. Just copy the entry with the pin matching to cover ALC295 too. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784485 Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kailang Yang authored
commit 0700d3d1 upstream. Fixed Dell AIO speaker noise. spec->gen.auto_mute_via_amp = 1, this option was solved speaker white noise at boot. codec->power_save_node = 0, this option was solved speaker noise at resume back. Fixes: 92266651 ("ALSA: hda/realtek - Fix Dell AIO LineOut issue") Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Kailang Yang authored
commit 0a29c57b upstream. Add two Dell platform for headset mode. [ Note: this is a further correction / addition of the previous pin-based quirks for Dell machines; another entry for ALC236 with the d-mic pin 0x12 and an entry for ALC295 -- tiwai ] Fixes: b26e36b7 ("ALSA: hda/realtek - add two more pin configuration sets to quirk table") Signed-off-by:
-
Jarkko Nikula authored
commit 72bfcee1 upstream. Multiple users have reported their Synaptics touchpad has stopped working between v4.20.1 and v4.20.2 when using SMBus interface. The culprit for this appeared to be commit c5eb1190 ("PCI / PM: Allow runtime PM without callback functions") that fixed the runtime PM for i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801 for SMBus communication and testing showed they are able to get back working by preventing the runtime suspend of adapter. Normally when i2c-i801 SMBus adapter transmits with the client it resumes before operation and autosuspends after. However, if client requires SMBus Host Notify protocol, what those Synaptics touchpads do, then the host adapter must not go to runtime suspend since then it cannot process incoming SMBus Host Notify commands the client may send. Fix this by keeping I2C/SMBus adapter active in case client requires Host Notify. Reported-by:
Keijo Vaara <ferdasyn@rocketmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297 Fixes: c5eb1190 ("PCI / PM: Allow runtime PM without callback functions") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Jim Broadus authored
commit 93b6604c upstream. A previous change allowed I2C client devices to discover new IRQs upon reprobe by clearing the IRQ in i2c_device_remove. However, if an IRQ was assigned in i2c_new_device, that information is lost. For example, the touchscreen and trackpad devices on a Dell Inspiron laptop are I2C devices whose IRQs are defined by ACPI extended IRQ types. The client device structures are initialized during an ACPI walk. After removing the i2c_hid device, modprobe fails. This change caches the initial IRQ value in i2c_new_device and then resets the client device IRQ to the initial value in i2c_device_remove. Fixes: 6f108dd7 ("i2c: Clear client->irq in i2c_device_remove") Signed-off-by:
Jim Broadus <jbroadus@gmail.com> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by:
Charles Keepax <ckeepax@opensource.cirrus.com> [wsa: this is an easy to backport fix for the regression. We will refactor the code to handle irq assignments better in general.] Signed-off-by:
-
Charles Keepax authored
commit 6f108dd7 upstream. The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again. Signed-off-by:
-
Charles Keepax authored
commit b9bb3fdf upstream. irq_create_mapping calls irq_find_mapping internally and will use the found mapping if one exists, so there is no need to manually call this from i2c_smbus_host_notify_to_irq. Signed-off-by:
-
Anson Huang authored
commit d386bb90 upstream. The way of getting private imx_i2c_struct in i2c_imx_clk_notifier_call() is incorrect, should use clk_change_nb element to get correct address and avoid below kernel dump during POST_RATE_CHANGE notify by clk framework: Unable to handle kernel paging request at virtual address 03ef1488 pgd = (ptrval) [03ef1488] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Workqueue: events reduce_bus_freq_handler PC is at i2c_imx_set_clk+0x10/0xb8 LR is at i2c_imx_clk_notifier_call+0x20/0x28 pc : [<806a893c>] lr : [<806a8a04>] psr: a0080013 sp : bf399dd8 ip : bf3432ac fp : bf7c1dc0 r10: 00000002 r9 : 00000000 r8 : 00000000 r7 : 03ef1480 r6 : bf399e50 r5 : ffffffff r4 : 00000000 r3 : bf025300 r2 : bf399e50 r1 : 00b71b00 r0 : bf399be8 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4e03004a DAC: 00000051 Process kworker/2:1 (pid: 38, stack limit = 0x(ptrval)) Stack: (0xbf399dd8 to 0xbf39a000) 9dc0: 806a89e4 00000000 9de0: ffffffff bf399e50 00000002 806a8a04 806a89e4 80142900 ffffffff 00000000 9e00: bf34ef18 bf34ef04 00000000 ffffffff bf399e50 80142d84 00000000 bf399e6c 9e20: bf34ef00 80f214c4 bf025300 00000002 80f08d08 bf017480 00000000 80142df0 9e40: 00000000 80166ed8 80c27638 8045de58 bf352340 03ef1480 00b71b00 0f82e242 9e60: bf025300 00000002 03ef1480 80f60e5c 00000001 8045edf0 00000002 8045eb08 9e80: bf025300 00000002 03ef1480 8045ee10 03ef1480 8045eb08 bf01be40 00000002 9ea0: 03ef1480 8045ee10 07de2900 8045eb08 bf01b780 00000002 07de2900 8045ee10 9ec0: 80c27898 bf399ee4 bf020a80 00000002 1f78a400 8045ee10 80f60e5c 80460514 9ee0: 80f60e5c bf01b600 bf01b480 80460460 0f82e242 bf383a80 bf383a00 80f60e5c 9f00: 00000000 bf7c1dc0 80f60e70 80460564 80f60df0 80f60d24 80f60df0 8011e72c 9f20: 00000000 80f60df0 80f60e6c bf7c4f00 00000000 8011e7ac bf274000 8013bd84 9f40: bf7c1dd8 80f03d00 bf274000 bf7c1dc0 bf274014 bf7c1dd8 80f03d00 bf398000 9f60: 00000008 8013bfb4 00000000 bf25d100 bf25d0c0 00000000 bf274000 8013bf88 9f80: bf25d11c bf0cfebc 00000000 8014140c bf25d0c0 801412ec 00000000 00000000 9fa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<806a893c>] (i2c_imx_set_clk) from [<806a8a04>] (i2c_imx_clk_notifier_call+0x20/0x28) [<806a8a04>] (i2c_imx_clk_notifier_call) from [<80142900>] (notifier_call_chain+0x44/0x84) [<80142900>] (notifier_call_chain) from [<80142d84>] (__srcu_notifier_call_chain+0x44/0x98) [<80142d84>] (__srcu_notifier_call_chain) from [<80142df0>] (srcu_notifier_call_chain+0x18/0x20) [<80142df0>] (srcu_notifier_call_chain) from [<8045de58>] (__clk_notify+0x78/0xa4) [<8045de58>] (__clk_notify) from [<8045edf0>] (__clk_recalc_rates+0x60/0xb4) [<8045edf0>] (__clk_recalc_rates) from [<8045ee10>] (__clk_recalc_rates+0x80/0xb4) Code: e92d40f8 e5903298 e59072a0 e1530001 (e5975008) ---[ end trace fc7f5514b97b6cbb ]--- Fixes: 90ad2cbe ("i2c: imx: use clk notifier for rate changes") Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Reviewed-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
-
Ard Biesheuvel authored
commit 95e0cf3c upstream. The I2C host driver for SynQuacer fails to populate the of_node and ACPI companion fields of the struct i2c_adapter it instantiates, resulting in enumeration of the subordinate I2C bus to fail. Fixes: 0d676a6c ("i2c: add support for Socionext SynQuacer I2C controller") Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by:
-
Johannes Berg authored
commit 51787914 upstream. We need to dereference the directory to get its parent to be able to rename it, so it's clearly not safe to try to do this with ERR_PTR() pointers. Skip in this case. It seems that this is most likely what was causing the report by syzbot, but I'm not entirely sure as it didn't come with a reproducer this time. Cc: stable@vger.kernel.org Reported-by: syzbot+4ece1a28b8f4730547c9@syzkaller.appspotmail.com Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Douglas Anderson authored
commit b82d6c1f upstream. The commit fc3a2fca ("mwifiex: use atomic bitops to represent adapter status variables") had a fairly straightforward bug in it. It contained this bit of diff: - if (!adapter->is_suspended) { + if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) { As you can see the patch missed the "!" when converting to the atomic bitops. This meant that the resume hasn't done anything at all since that commit landed and suspend/resume for mwifiex SDIO cards has been totally broken. After fixing this mwifiex suspend/resume appears to work again, at least with the simple testing I've done. Fixes: fc3a2fca ("mwifiex: use atomic bitops to represent adapter status variables") Cc: <stable@vger.kernel.org> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Emmanuel Grumbach authored
commit 5c9adef9 upstream. We introduced a bug that prevented this old device from working. The driver would simply not be able to complete the INIT flow while spewing this warning: CSR addresses aren't configured WARNING: CPU: 0 PID: 819 at drivers/net/wireless/intel/iwlwifi/pcie/drv.c:917 iwl_pci_probe+0x160/0x1e0 [iwlwifi] Cc: stable@vger.kernel.org # v4.18+ Fixes: a8cbb46f ("iwlwifi: allow different csr flags for different device families") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: c8f1b51e ("iwlwifi: allow different csr flags for different device families") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
- 05 May, 2019 2 commits
-
-
Greg Kroah-Hartman authored
-
Rafael J. Wysocki authored
commit 9e80ad37 upstream. ath10k_mac_vif_chan() always returns an error for the given vif during system-wide resume which reliably triggers two WARN_ON()s in ath10k_bss_info_changed() and they are not particularly useful in that code path, so drop them. Tested: QCA6174 hw3.2 PCI with WLAN.RM.2.0-00180-QCARMSWPZ-1 Tested: QCA6174 hw3.2 SDIO with WLAN.RMH.4.4.1-00007-QCARMSWP-1 Fixes: cd93b83a ("ath10k: support for multicast rate control") Fixes: f279294e ("ath10k: add support for configuring management packet rate") Cc: stable@vger.kernel.org Reviewed-by:
Claire Chang <tientzu@chromium.org> Signed-off-by:
-
