aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-12-20HID: potential dereference of null pointerJiasheng Jiang1-0/+3
The return value of devm_kzalloc() needs to be checked. To avoid hdev->dev->driver_data to be null in case of the failure of alloc. Fixes: 14c9c014babe ("HID: add vivaldi HID driver") Cc: stable@vger.kernel.org Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211215083605.117638-1-jiasheng@iscas.ac.cn
2021-12-20HID: holtek: fix mouse probingBenjamin Tissoires1-0/+15
An overlook from the previous commit: we don't even parse or start the device, meaning that the device is not presented to user space. Fixes: 93020953d0fa ("HID: check for valid USB device for many HID drivers") Cc: stable@vger.kernel.org Link: https://bugs.archlinux.org/task/73048 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215341 Link: https://lore.kernel.org/r/e4efbf13-bd8d-0370-629b-6c80c0044b15@leemhuis.info/ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2021-12-08HID: Ignore battery for Elan touchscreen on Asus UX550VEHans de Goede2-0/+3
Battery status is reported for the Asus UX550VE touchscreen even though it does not have a battery. Prevent it from always reporting the battery as low. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1897823 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-12-03HID: intel-ish-hid: ipc: only enable IRQ wakeup when requestedThomas Weißschuh1-2/+4
Fixes spurious wakeups from s0ix on Lenovo ThinkPad X1 Cargon Gen 9 on lid close. These wakeups are generated by interrupts from the ISH on changes to the lid status. By disabling the wake IRQ from the ISH we inhibit these spurious wakeups while keeping the resume from LID open through the ACPI interrupt. Reports on the Lenovo forums indicate that Lenovo ThinkPad X1 Yoga Gen6 is also affected. Fixes: ae02e5d40d5f ("HID: intel-ish-hid: ipc layer") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214855 Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211130060117.3026-1-linux@weissschuh.net
2021-12-03HID: google: add eel USB idxiazhengqiao2-0/+3
Add one additional hammer-like device. Signed-off-by: xiazhengqiao <xiazhengqiao@huaqin.corp-partner.google.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211203030119.28612-1-xiazhengqiao@huaqin.corp-partner.google.com
2021-12-03HID: add USB_HID dependancy to hid-prodikeysGreg Kroah-Hartman1-1/+1
The prodikeys HID driver only controls USB devices, yet did not have a dependancy on USB_HID. This causes build errors on some configurations like nios2 when building due to new changes to the prodikeys driver. Reported-by: kernel test robot <lkp@intel.com> Cc: stable@vger.kernel.org Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211203081231.2856936-1-gregkh@linuxfoundation.org
2021-12-03HID: add USB_HID dependancy to hid-chiconyGreg Kroah-Hartman1-1/+1
The chicony HID driver only controls USB devices, yet did not have a dependancy on USB_HID. This causes build errors on some configurations like sparc when building due to new changes to the chicony driver. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: stable@vger.kernel.org Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211203075927.2829218-1-gregkh@linuxfoundation.org
2021-12-02HID: bigbenff: prevent null pointer dereferenceBenjamin Tissoires1-1/+1
When emulating the device through uhid, there is a chance we don't have output reports and so report_field is null. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20211202095334.14399-3-benjamin.tissoires@redhat.com
2021-12-02HID: sony: fix error path in probeBenjamin Tissoires1-7/+15
When the setup of the GHL fails, we are not calling hid_hw_stop(). This leads to the hidraw node not being released, meaning a crash whenever somebody attempts to open the file. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20211202095334.14399-2-benjamin.tissoires@redhat.com
2021-12-02HID: add USB_HID dependancy on some USB HID driversGreg Kroah-Hartman1-3/+3
Some HID drivers are only for USB drivers, yet did not depend on CONFIG_USB_HID. This was hidden by the fact that the USB functions were stubbed out in the past, but now that drivers are checking for USB devices properly, build errors can occur with some random configurations. Reported-by: kernel test robot <lkp@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211202114819.2511954-1-gregkh@linuxfoundation.org
2021-12-02HID: check for valid USB device for many HID driversGreg Kroah-Hartman23-9/+92
Many HID drivers assume that the HID device assigned to them is a USB device as that was the only way HID devices used to be able to be created in Linux. However, with the additional ways that HID devices can be created for many different bus types, that is no longer true, so properly check that we have a USB device associated with the HID device before allowing a driver that makes this assumption to claim it. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: Michael Zaidman <michael.zaidman@gmail.com> Cc: Stefan Achatz <erazor_de@users.sourceforge.net> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> [bentiss: amended for thrustmater.c hunk to apply] Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-3-gregkh@linuxfoundation.org
2021-12-02HID: wacom: fix problems when device is not a valid USB deviceGreg Kroah-Hartman1-5/+12
The wacom driver accepts devices of more than just USB types, but some code paths can cause problems if the device being controlled is not a USB device due to a lack of checking. Add the needed checks to ensure that the USB device accesses are only happening on a "real" USB device, and not one on some other bus. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-2-gregkh@linuxfoundation.org
2021-12-02HID: add hid_is_usb() function to make it simpler for USB detectionGreg Kroah-Hartman6-9/+11
A number of HID drivers already call hid_is_using_ll_driver() but only for the detection of if this is a USB device or not. Make this more obvious by creating hid_is_usb() and calling the function that way. Also converts the existing hid_is_using_ll_driver() functions to use the new call. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-1-gregkh@linuxfoundation.org
2021-11-29HID: quirks: Add quirk for the Microsoft Surface 3 type-coverHans de Goede2-0/+2
Add a HID_QUIRK_NO_INIT_REPORTS quirk for the Microsoft Surface 3 (non pro) type-cover. Trying to init the reports seems to confuse the type-cover and causes 2 issues: 1. Despite hid-multitouch sending the command to switch the touchpad to multitouch mode, it keeps sending events on the mouse emulation interface. 2. The touchpad completely stops sending events after a reboot. Adding the HID_QUIRK_NO_INIT_REPORTS quirk fixes both issues. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: multitouch: Fix Iiyama ProLite T1931SAW (0eef:0001 again!)Ondrej Zary1-0/+5
Iiyama ProLite T1931SAW does not work with Linux - input devices are created but cursor does not move. It has the infamous 0eef:0001 ID which has been reused for various devices before. It seems to require export_all_inputs = true. Hopefully there are no HID devices using this ID that will break. It should not break non-HID devices (handled by usbtouchscreen). Signed-off-by: Ondrej Zary <linux@zary.sk> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: nintendo: eliminate dead datastructures in !CONFIG_NINTENDO_FF caseJiri Kosina1-3/+5
The rumbling-related identifiers are never used in !CONFIG_NINTENDO_FF case, so let's hide them in order to avoid unused warnings. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: magicmouse: prevent division by 0 on scrollClaudia Pellegrino1-2/+5
In hid_magicmouse, if the user has set scroll_speed to a value between 55 and 63 and scrolls seven times in quick succession, the step_hr variable in the magicmouse_emit_touch function becomes 0. That causes a division by zero further down in the function when it does `step_x_hr /= step_hr`. To reproduce, create `/etc/modprobe.d/hid_magicmouse.conf` with the following content: ``` options hid_magicmouse scroll_acceleration=1 scroll_speed=55 ``` Then reboot, connect a Magic Mouse and scroll seven times quickly. The system will freeze for a minute, and after that `dmesg` will confirm that a division by zero occurred. Enforce a minimum of 1 for the variable so the high resolution step count can never reach 0 even at maximum scroll acceleration. Fixes: d4b9f10a0eb6 ("HID: magicmouse: enable high-resolution scroll") Signed-off-by: Claudia Pellegrino <linux@cpellegrino.de> Tested-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: thrustmaster: fix sparse warningsVihas Mak1-3/+3
Changed 0 to NULL to fix following sparse warnings: drivers/hid/hid-thrustmaster.c:208:43: warning: Using plain integer as NULL pointer drivers/hid/hid-thrustmaster.c:241:17: warning: Using plain integer as NULL pointer drivers/hid/hid-thrustmaster.c:275:37: warning: Using plain integer as NULL pointer Signed-off-by: Vihas Mak <makvihas@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: Ignore battery for Elan touchscreen on HP Envy X360 15-eu0xxxTrevor Davenport2-0/+3
Battery status is reported for the HP Envy X360 Convertible 15-eu0xxx even if it does not have a battery. Prevent it from always reporting the battery as low. Signed-off-by: Trevor Davenport <trevor.davenport@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: input: set usage type to key on keycode remapThomas Weißschuh1-0/+1
When a scancode is manually remapped that previously was not handled as key, then the old usage type was incorrectly reused. This caused issues on a "04b3:301b IBM Corp. SK-8815 Keyboard" which has marked some of its keys with an invalid HID usage. These invalid usage keys are being ignored since support for USB programmable buttons was added. The scancodes are however remapped explicitly by the systemd hwdb to the keycodes that are printed on the physical buttons. During this mapping step the existing usage is retrieved which will be found with a default type of 0 (EV_SYN) instead of EV_KEY. The events with the correct code but EV_SYN type are not forwarded to userspace. This also leads to a kernel oops when trying to print the report descriptor via debugfs. hid_resolv_event() tries to resolve a EV_SYN event with an EV_KEY code which leads to an out-of-bounds access in the EV_SYN names array. Fixes: bcfa8d1457 ("HID: input: Add support for Programmable Buttons") Fixes: f5854fad39 ("Input: hid-input - allow mapping unknown usages") Reported-by: Brent Roman <brent@mbari.org> Tested-by: Brent Roman <brent@mbari.org> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: input: Fix parsing of HID_CP_CONSUMER_CONTROL fieldsHans de Goede1-3/+2
Fix parsing of HID_CP_CONSUMER_CONTROL fields which are not in the HID_CP_PROGRAMMABLEBUTTONS collection. Fixes: bcfa8d14570d ("HID: input: Add support for Programmable Buttons") BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2018096 Cc: Thomas Weißschuh <linux@weissschuh.net> Suggested-by: Benjamin Tissoires <btissoir@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-By: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-19HID: ft260: fix i2c probing for hwmon devicesMichael Zaidman1-6/+5
The below scenario causes the kernel NULL pointer dereference failure: 1. sudo insmod hid-ft260.ko 2. sudo modprobe lm75 3. unplug USB hid-ft260 4. plug USB hid-ft260 [ +0.000006] Call Trace: [ +0.000004] __i2c_smbus_xfer.part.0+0xd1/0x310 [ +0.000007] ? ft260_smbus_write+0x140/0x140 [hid_ft260] [ +0.000005] __i2c_smbus_xfer+0x2b/0x80 [ +0.000004] i2c_smbus_xfer+0x61/0xf0 [ +0.000005] i2c_default_probe+0xf9/0x130 [ +0.000004] i2c_detect_address+0x84/0x160 [ +0.000004] ? kmem_cache_alloc_trace+0xf6/0x200 [ +0.000009] ? i2c_detect.isra.0+0x69/0x130 [ +0.000005] i2c_detect.isra.0+0xbf/0x130 [ +0.000004] ? __process_new_driver+0x30/0x30 [ +0.000004] __process_new_adapter+0x18/0x20 [ +0.000004] bus_for_each_drv+0x84/0xd0 [ +0.000003] i2c_register_adapter+0x1e4/0x400 [ +0.000005] i2c_add_adapter+0x5c/0x80 [ +0.000004] ft260_probe.cold+0x222/0x2e2 [hid_ft260] [ +0.000006] hid_device_probe+0x10e/0x170 [hid] [ +0.000009] really_probe+0xff/0x460 [ +0.000004] driver_probe_device+0xe9/0x160 [ +0.000003] __device_attach_driver+0x71/0xd0 [ +0.000004] ? driver_allows_async_probing+0x50/0x50 [ +0.000004] bus_for_each_drv+0x84/0xd0 [ +0.000002] __device_attach+0xde/0x1e0 [ +0.000004] device_initial_probe+0x13/0x20 [ +0.000004] bus_probe_device+0x8f/0xa0 [ +0.000003] device_add+0x333/0x5f0 It happened when i2c core probed for the devices associated with the lm75 driver by invoking 2c_detect()-->..-->ft260_smbus_write() from within the ft260_probe before setting the adapter data with i2c_set_adapdata(). Moving the i2c_set_adapdata() before i2c_add_adapter() fixed the failure. Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com> Signed-off-by: Germain Hebert <germain.hebert@ca.abb.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-12Revert "HID: hid-asus.c: Maps key 0x35 (display off) to KEY_SCREENLOCK"Vinícius Angiolucci Reis1-1/+1
This reverts commit 2ea5999d07d2a0ab6ad92ccf65524707f2c5e456. As Dmitry Torokhov pointed out, the previous code (KEY_DISPLAY_OFF) is actually correct. The real issue is that current desktop environments don't deal it properly. Mapping it to another event does not solve the issue. So I'm reverting that change, keeping key 0x35 mapped to KEY_DISPLAY_OFF Signed-off-by: Vinícius Angiolucci Reis <angiolucci@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-11HID: intel-ish-hid: fix module device-id handlingArnd Bergmann7-47/+37
A late addititon to the intel-ish-hid framework caused a build failure with clang, and introduced an ABI to the module loader that stops working if any driver ever needs to bind to more than one UUID: drivers/hid/intel-ish-hid/ishtp-fw-loader.c:1067:4: error: initializer element is not a compile-time constant Change the ishtp_device_id to have correct documentation and a driver_data field like all the other ones, and change the drivers to use the ID table as the primary identification in a way that works with all compilers and avoids duplciating the identifiers. Fixes: f155dfeaa4ee ("platform/x86: isthp_eclite: only load for matching devices") Fixes: facfe0a4fdce ("platform/chrome: chros_ec_ishtp: only load for matching devices") Fixes: 0d0cccc0fd83 ("HID: intel-ish-hid: hid-client: only load for matching devices") Fixes: 44e2a58cb880 ("HID: intel-ish-hid: fw-loader: only load for matching devices") Fixes: cb1a2c6847f7 ("HID: intel-ish-hid: use constants for modaliases") Fixes: fa443bc3c1e4 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> [jkosina@suse.cz: fix ecl_ishtp_cl_driver.id initialization] [jkosina@suse.cz: fix conflict with already fixed kerneldoc] Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-10mod_devicetable: fix kdocs for ishtp_device_idThomas Weißschuh1-2/+1
The kdocs were copied from another device_id struct and not adapted. Fixes: fa443bc3c1e4 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-10HID: wacom: Use "Confidence" flag to prevent reporting invalid contactsJason Gerecke2-1/+8
The HID descriptor of many of Wacom's touch input devices include a "Confidence" usage that signals if a particular touch collection contains useful data. The driver does not look at this flag, however, which causes even invalid contacts to be reported to userspace. A lucky combination of kernel event filtering and device behavior (specifically: contact ID 0 == invalid, contact ID >0 == valid; and order all data so that all valid contacts are reported before any invalid contacts) spare most devices from any visibly-bad behavior. The DTH-2452 is one example of an unlucky device that misbehaves. It uses ID 0 for both the first valid contact and all invalid contacts. Because we report both the valid and invalid contacts, the kernel reports that contact 0 first goes down (valid) and then goes up (invalid) in every report. This causes ~100 clicks per second simply by touching the screen. This patch inroduces new `confidence` flag in our `hid_data` structure. The value is initially set to `true` at the start of a report and can be set to `false` if an invalid touch usage is seen. Link: https://github.com/linuxwacom/input-wacom/issues/270 Fixes: f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report") Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Tested-by: Joshua Dickens <joshua.dickens@wacom.com> Cc: <stable@vger.kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-10HID: nintendo: unlock on error in joycon_leds_create()Dan Carpenter1-1/+4
These two error paths need to drop the lock before returning. Fixes: c5e626769563 ("HID: nintendo: add player led support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-09platform/x86: isthp_eclite: only load for matching devicesThomas Weißschuh1-1/+6
Previously it was loaded for all ISHTP devices. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-09platform/chrome: chros_ec_ishtp: only load for matching devicesThomas Weißschuh1-1/+6
Previously it was loaded for all ISHTP devices. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-09HID: intel-ish-hid: hid-client: only load for matching devicesThomas Weißschuh1-1/+6
Previously it was loaded for all ISHTP devices. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-09HID: intel-ish-hid: fw-loader: only load for matching devicesThomas Weißschuh1-1/+6
Previously it was loaded for all ISHTP devices. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-09HID: intel-ish-hid: use constants for modaliasesThomas Weißschuh1-2/+2
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-09HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()Thomas Weißschuh3-0/+40
This allows to selectively autoload drivers for ISH devices. Currently all ISH drivers are loaded for all systems having any ISH device. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-11-04parisc: move CPU field back into thread_infoArd Biesheuvel4-24/+5
In commit 2214c0e77259 ("parisc: Move thread_info into task struct") PA-RISC gained support for THREAD_INFO_IN_TASK while changes were already underway to keep the CPU field in thread_info rather than move it into task_struct when THREAD_INFO_IN_TASK is enabled. The result is a broken build for all PA-RISC configs that enable SMP. So let's partially revert that commit, and get rid of the ugly hack to get at the offset of task_struct::cpu without having to include linux/sched.h, and put the CPU field back where it was before. Reported-by: Guenter Roeck <linux@roeck-us.net> Fixes: bcf9033e5449 ("sched: move CPU field back into thread_info if THREAD_INFO_IN_TASK=y") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2021-11-04parisc: Don't disable interrupts in cmpxchg and futex operationsDave Anglin2-23/+11
I no longer think interrupts can be disabled in the futex and cmpxchg operations because of COW breaks. This not ideal but I suspect it's the best we can do. For the cmpxchg operations in syscall.S, we rely on the code to not schedule off the gateway page. For the futex, I added code to disable preemption. So far, I haven't seen the warnings with the attached change but the change is only lightly tested. Signed-off-by: Dave Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de>
2021-11-04parisc: don't enable irqs unconditionally in handle_interruption()Sven Schnelle1-1/+1
If the previous context had interrupts disabled, we should better keep them disabled. This was noticed in the unwinding code where a copy_from_kernel_nofault() triggered a page fault, and after the fixup by the page fault handler interrupts where suddenly enabled. Signed-off-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: Helge Deller <deller@gmx.de>
2021-11-03string: uninline memcpy_and_padGuenter Roeck2-17/+22
When building m68k:allmodconfig, recent versions of gcc generate the following error if the length of UTS_RELEASE is less than 8 bytes. In function 'memcpy_and_pad', inlined from 'nvmet_execute_disc_identify' at drivers/nvme/target/discovery.c:268:2: arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7 Discussions around the problem suggest that this only happens if an architecture does not provide strlen(), if -ffreestanding is provided as compiler option, and if CONFIG_FORTIFY_SOURCE=n. All of this is the case for m68k. The exact reasons are unknown, but seem to be related to the ability of the compiler to evaluate the return value of strlen() and the resulting execution flow in memcpy_and_pad(). It would be possible to work around the problem by using sizeof(UTS_RELEASE) instead of strlen(UTS_RELEASE), but that would only postpone the problem until the function is called in a similar way. Uninline memcpy_and_pad() instead to solve the problem for good. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-03MIPS: Cobalt: Explain GT64111 early PCI fixupPali Rohár1-0/+15
Properly document why changing PCI Class Code for GT64111 device to Host Bridge is required as important details were after 20 years forgotten. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-11-03MAINTAINERS: Update BCM7XXX entry with additional patternsFlorian Fainelli1-0/+2
Broadcom STB systems use the bcm7038 pattern as well as the bcm7120 pattern for some of its drivers, add those to the existing entry. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211028163756.4014059-1-f.fainelli@gmail.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-11-03RDMA/core: Require the driver to set the IOVA correctly during rereg_mrAharon Landau1-3/+0
If the driver returns a new MR during rereg it has to fill it with the IOVA from the proper source. If IB_MR_REREG_TRANS is set then the IOVA is cmd.hca_va, otherwise the IOVA comes from the old MR. mlx5 for example has two calls inside rereg_mr: return create_real_mr(new_pd, umem, mr->ibmr.iova, new_access_flags); and return create_real_mr(new_pd, new_umem, iova, new_access_flags); Unconditionally overwriting the iova in the newly allocated MR will corrupt the iova if the first path is used. Remove the redundant initializations from ib_uverbs_rereg_mr(). Fixes: 6e0954b11c05 ("RDMA/uverbs: Allow drivers to create a new HW object during rereg_mr") Link: https://lore.kernel.org/r/4b0a31bbc372842613286a10d7a8cbb0ee6069c7.1635400472.git.leonro@nvidia.com Signed-off-by: Aharon Landau <aharonl@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-03RDMA/bnxt_re: Remove unsupported bnxt_re_modify_ah callbackKamal Heib3-7/+0
There is no need to return always zero for function which is not supported, especially since 0 is the wrong return code. Link: https://lore.kernel.org/r/20211102073054.410838-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-11-02ALSA: usb-audio: Add quirk for Audient iD14Takashi Iwai1-0/+2
Audient iD14 (2708:0002) may get a control message error that interferes the operation e.g. with alsactl. Add the quirk to ignore such errors like other devices. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1191247 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211102161859.19301-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-11-02power: supply: bq25890: Fix initial setting of the F_CONV_RATE fieldHans de Goede1-5/+5
The code doing the initial setting of the F_CONV_RATE field based on the bq->state.online flag. In order for this to work properly, this must be done after the initial bq25890_get_chip_state() call. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-11-02power: supply: bq25890: Fix race causing oops at bootHans de Goede1-12/+11
Before this commit the driver was registering its interrupt handler before it registered the power_supply, causing bq->charger to potentially be NULL when the interrupt handler runs, triggering a NULL pointer exception in the interrupt handler: [ 21.213531] BUG: kernel NULL pointer dereference, address: 0000000000000680 ... [ 21.213573] Hardware name: Xiaomi Inc Mipad2/Mipad, BIOS MIPad-P4.X64.0043.R03.1603071414 03/07/2016 [ 21.213576] RIP: 0010:__lock_acquire+0x5c5/0x1de0 ... [ 21.213629] Call Trace: [ 21.213636] ? disable_irq_nosync+0x10/0x10 [ 21.213644] ? __mutex_unlock_slowpath+0x35/0x260 [ 21.213655] lock_acquire+0xb5/0x2b0 [ 21.213661] ? power_supply_changed+0x23/0x90 [ 21.213670] ? disable_irq_nosync+0x10/0x10 [ 21.213676] _raw_spin_lock_irqsave+0x48/0x60 [ 21.213682] ? power_supply_changed+0x23/0x90 [ 21.213687] power_supply_changed+0x23/0x90 [ 21.213697] __bq25890_handle_irq+0x5e/0xe0 [bq25890_charger] [ 21.213709] bq25890_irq_handler_thread+0x26/0x40 [bq25890_charger] [ 21.213718] irq_thread_fn+0x20/0x60 ... Fix this by moving the power_supply_register() call to above the request_threaded_irq() call. Note this fix includes making the following 2 (necessary) changes: 1. Switch to the devm version of power_supply_register() to avoid the need to make the error-handling in probe() more complicated. 2. Rename the "irq_fail" label to "err_unregister_usb_notifier" since the old name no longer makes sense after this fix. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-11-02power: supply: bq27xxx: Fix kernel crash on IRQ handler register errorHans de Goede1-1/+2
When registering the IRQ handler fails, do not just return the error code, this will free the devm_kzalloc()-ed data struct while leaving the queued work queued and the registered power_supply registered with both of them now pointing to free-ed memory, resulting in various kernel crashes soon afterwards. Instead properly tear-down things on IRQ handler register errors. Fixes: 703df6c09795 ("power: bq27xxx_battery: Reorganize I2C into a module") Cc: Andrew F. Davis <afd@ti.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2021-11-02platform/x86: system76_acpi: Fix input device error handlingTim Crawford1-1/+0
Users on darp6 that do not have Open EC firmware have reported crashes on boot. Correct the error handling for the input device to fix it. Managed devices do not need to be explicitly unregistered or freed, as this is handled by devres. Drop the call to input_free_device. Fixes: 0de30fc684b3 ("platform/x86: system76_acpi: Replace Fn+F2 function for OLED models") Signed-off-by: Tim Crawford <tcrawford@system76.com> Link: https://lore.kernel.org/r/20211030154213.2515-1-tcrawford@system76.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-11-02mips: fix HUGETLB function without THP enabledZhaolong Zhang1-23/+22
ltp test futex_wake04 without THP enabled leads to below bt: [<ffffffff80a03728>] BUG+0x0/0x8 [<ffffffff80a0624c>] internal_get_user_pages_fast+0x81c/0x820 [<ffffffff8093ac18>] get_futex_key+0xa0/0x480 [<ffffffff8093b074>] futex_wait_setup+0x7c/0x1a8 [<ffffffff8093b2c0>] futex_wait+0x120/0x228 [<ffffffff8093dbe8>] do_futex+0x140/0xbd8 [<ffffffff8093e78c>] sys_futex+0x10c/0x1c0 [<ffffffff808703d0>] syscall_common+0x34/0x58 Move pmd_write() and pmd_page() from TRANSPARENT_HUGEPAGE scope to MIPS_HUGE_TLB_SUPPORT scope, because both THP and HUGETLB will need them. Signed-off-by: Zhaolong Zhang <zhangzl2013@126.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-11-02mips: cm: Convert to bitfield API to fix out-of-bounds accessGeert Uytterhoeven2-17/+16
mips_cm_error_report() extracts the cause and other cause from the error register using shifts. This works fine for the former, as it is stored in the top bits, and the shift will thus remove all non-related bits. However, the latter is stored in the bottom bits, hence thus needs masking to get rid of non-related bits. Without such masking, using it as an index into the cm2_causes[] array will lead to an out-of-bounds access, probably causing a crash. Fix this by using FIELD_GET() instead. Bite the bullet and convert all MIPS CM handling to the bitfield API, to improve readability and safety. Fixes: 3885c2b463f6a236 ("MIPS: CM: Add support for reporting CM cache errors") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-11-02afs: Set mtime from the client for yfs create operationsMarc Dionne1-19/+13
For operations that create vnodes on the server such as CreateFile, MakeDir or Symlink, the server will store its own current time as the mtime if the client doesn't pass in a time in the accompanying StoreStatus structure. If the server and client clocks are not well synchronized, the client may see timestamps in the future or inconsistent dependency checks with "make" for files that are not modified after creation: make[2]: Warning: File 'arch/x86/kernel/apic/modules.order' has modification time 0.14 s in the future make[2]: warning: Clock skew detected. Your build may be incomplete. This is already handled correctly for non yfs operations; also set the mtime for the corresponding yfs operations. Changes: v3: Replace S_IRWXUGO with 0777, per checkpatch v2: [dhowells] Merge the two xdr_encode_YFSStoreStatus*() functions together Signed-off-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> Link: http://lists.infradead.org/pipermail/linux-afs/2021-October/004395.html
2021-11-02afs: Sort out symlink readingDavid Howells3-9/+14
afs_readpage() doesn't get a file pointer when called for a symlink, so separate it from regular file pointer handling. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Link: https://lore.kernel.org/r/162687508008.276387.6418924257569297305.stgit@warthog.procyon.org.uk/ # rfc Link: https://lore.kernel.org/r/162981152280.1901565.2264055504466731917.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/163005742570.2472992.7800423440314043178.stgit@warthog.procyon.org.uk/ # v2