summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-11-06spi: apple: Add driver for Apple SPI controllerHector Martin
This SPI controller is present in Apple SoCs such as the M1 (t8103) and M1 Pro/Max (t600x). It is a relatively straightforward design with two 16-entry FIFOs, arbitrary transfer sizes (up to 2**32 - 1) and fully configurable word size up to 32 bits. It supports one hardware CS line which can also be driven via the pinctrl/GPIO driver instead, if desired. TX and RX can be independently enabled. There are a surprising number of knobs for tweaking details of the transfer, most of which we do not use right now. Hardware CS control is available, but we haven't found a way to make it stay low across multiple logical transfers, so we just use software CS control for now. There is also a shared DMA offload coprocessor that can be used to handle larger transfers without requiring an IRQ every 8-16 words, but that feature depends on a bunch of scaffolding that isn't ready to be upstreamed yet, so leave it for later. The hardware shares some register bit definitions with spi-s3c24xx which suggests it has a shared legacy with Samsung SoCs, but it is too different to warrant sharing a driver. Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Janne Grunau <j@jannau.net> Link: https://patch.msgid.link/20241106-asahi-spi-v5-2-e81a4f3a8e19@jannau.net Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-06HID: steelseries: Add capacity_level mappingBastien Nocera
The capacity level mappings are taken from: https://support.steelseries.com/hc/en-us/articles/360049205612-How-do-I-know-the-Arctis-battery-level-how-do-I-charge-the-Arctis Even if we have a percentage, exporting a capacity_level that matches with the hardware warning levels means that upower can show warnings at the same time as the hardware. So the headset starts beeping at the same time as the critical warning notification appears :eyeroll: Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-11-06HID: steelseries: Fix battery requests stopping after some timeBastien Nocera
In some cases, the headset receiver will answer one of our requests with garbage, or not at all. This is a problem when we only request battery information once we've received a battery response, as we might never get to request battery information again. If the data from the receiver could not be parsed, and there's no pending battery requests, schedule a new request. Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-11-06USB: serial: qcserial: add support for Sierra Wireless EM86xxJack Wu
Add support for Sierra Wireless EM86xx with USB-id 0x1199:0x90e5 and 0x1199:0x90e4. 0x1199:0x90e5 T: Bus=03 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 14 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90e5 Rev= 5.15 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Semtech EM8695 Mobile Broadband Adapter S: SerialNumber=004403161882339 C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=qcserial E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=qcserial E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x1199:0x90e4 T: Bus=03 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 16 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90e4 Rev= 0.00 S: Manufacturer=Sierra Wireless, Incorporated S: SerialNumber=004403161882339 C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 2mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=qcserial E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Jack Wu <wojackbb@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2024-11-06HID: hid-goodix: Fix HID get/set feature operation overwritten problemCharles Wang
Implement the hid get/set feature report function using a separate address, rather than sharing an address with coordinate reporting, to prevent feature events from being overwritten by coordinate events. Signed-off-by: Charles Wang <charles.goodix@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-11-06HID: hid-goodix: Return 0 when receiving an empty HID feature packageCharles Wang
Align with the i2c-hid driver by returning 0 instead of -EINVAL when an empty response is received, ensuring that userspace programs utilizing the hidraw node receive consistent return values. Signed-off-by: Charles Wang <charles.goodix@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-11-06gpio: Use of_property_present() for non-boolean propertiesRob Herring (Arm)
The use of of_property_read_bool() for non-boolean properties is deprecated in favor of of_property_present() when testing for property presence. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241104190628.274717-1-robh@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-06gpio: mpfs: add polarfire soc gpio supportLewis Hanly
Add a driver to support the Polarfire SoC gpio controller. Interrupt controller support is unavailable for now and will be added at a later date. Signed-off-by: Lewis Hanly <lewis.hanly@microchip.com> Co-developed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104-tiny-evaluate-9336020b4b6a@spud Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-06platform/x86: x86-android-tablets: Add support for Vexia EDU ATLA 10 tabletHans de Goede
Add support for the Vexia EDU ATLA 10 tablet, Android 4.2/4.4 + Guadalinex Ubuntu tablet distributed to schools in the Spanish Andalucía region. Besides the usual broken DSDT issues this tablet is special because all its LPSS island peripherals are enumerated as PCI devices rather then as ACPI devices as they typically are. At the same time there are disabled (_STA=0) ACPI devices for the peripherals and child ACPI devices for e.g. attached I2C/SDIO devices are children of these disabled ACPI devices and thus will not be used by Linux since the parent is disabled. So besides the usual manual i2c-client instantiation for accel/touchscreen this tablet also requires manual i2c-client instantiation for the codec and for the PMIC. Also it seems the mainboard was designed for Windows not Android, so it has an I2C attached embedded controller instead of allowing direct access to the charger + fuel-gauge chips as is usual with Android boards. Normally when there is an embedded controller, there also is ACPI battery support, but since this shipped with Android that is missing and Linux needs to have a power_supply class driver talking directly to the EC. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20241104200848.58693-4-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-11-06platform/x86: x86-android-tablets: Add support for getting i2c_adapter by ↵Hans de Goede
PCI parent devname() On the Vexia EDU ATLA 10 tablet, which ships with Android + a custom Linux (guadalinex) using the custom Android kernel the I2C controllers are not enumerated as ACPI devices as they typically are. Instead they are enumerated as PCI devices which do not have ACPI firmware nodes associated with them, so getting the i2c_adapter by the ACPI path of its firmware node does not work. Add support for getting the i2c_adapter by the devname() of its PCI parent instead. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20241104200848.58693-3-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-11-06platform/x86: x86-android-tablets: Add get_i2c_adap_by_handle() helperHans de Goede
Add get_i2c_adap_by_handle() helper function, this is a preparation patch for adding support for getting i2c_adapter-s by PCI parent devname(). Suggested-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20241104200848.58693-2-hdegoede@redhat.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-11-06platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect ↵Vishnu Sankar
fan speed Fix for Thinkpad's with ECFW showing incorrect fan speed. Some models use decimal instead of hexadecimal for the speed stored in the EC registers. For example the rpm register will have 0x4200 instead of 0x1068, here the actual RPM is "4200" in decimal. Add a quirk to handle this. Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20241105235505.8493-1-vishnuocv@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-11-06firmware: arm_scpi: Check the DVFS OPP count returned by the firmwareLuo Qiu
Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero. dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Signed-off-by: Luo Qiu <luoqiu@kylinsec.com.cn> Message-Id: <55A2F7A784391686+20241101032115.275977-1-luoqiu@kylinsec.com.cn> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-11-06vp_vdpa: fix id_table array not null terminated errorXiaoguang Wang
Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory. Fixes: ffbda8e9df10 ("vdpa/vp_vdpa : add vdpa tool support in vp_vdpa") Cc: stable@vger.kernel.org Suggested-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Angus Chen <angus.chen@jaguarmicro.com> Signed-off-by: Xiaoguang Wang <lege.wang@jaguarmicro.com> Message-Id: <20241105133518.1494-1-lege.wang@jaguarmicro.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Acked-by: Jason Wang <jasowang@redhat.com>
2024-11-06virtio_pci: Fix admin vq cleanup by using correct info pointerFeng Liu
vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: <TASK> ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ================================================================== Fixes: 4c3b54af907e ("virtio_pci_modern: use completion instead of busy loop to wait on admin cmd result") Signed-off-by: Feng Liu <feliu@nvidia.com> Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Message-Id: <20241024135406.81388-1-feliu@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-11-06vDPA/ifcvf: Fix pci_read_config_byte() return code handlingYuan Can
ifcvf_init_hw() uses pci_read_config_byte() that returns PCIBIOS_* codes. The error handling, however, assumes the codes are normal errnos because it checks for < 0. Convert the error check to plain non-zero check. Fixes: 5a2414bc454e ("virtio: Intel IFC VF driver for VDPA") Signed-off-by: Yuan Can <yuancan@huawei.com> Message-Id: <20241017013812.129952-1-yuancan@huawei.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Zhu Lingshan <lingshan.zhu@kernel.org>
2024-11-06vdpa: solidrun: Fix UB bug with devresPhilipp Stanner
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf(). Cc: stable@vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20241028074357.9104-3-pstanner@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-11-06leds: class: Protect brightness_show() with led_cdev->led_access mutexMukesh Ojha
There is NULL pointer issue observed if from Process A where hid device being added which results in adding a led_cdev addition and later a another call to access of led_cdev attribute from Process B can result in NULL pointer issue. Use mutex led_cdev->led_access to protect access to led->cdev and its attribute inside brightness_show() and max_brightness_show() and also update the comment for mutex that it should be used to protect the led class device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74 [ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 3313.874301][ T4013] Mem abort info: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault [ 3313.874313][ T4013] Data abort info: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000 .. [ 3313.874332][ T4013] Dumping ftrace buffer: [ 3313.874334][ T4013] (ftrace buffer empty) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74 [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Call trace: [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74 [ 3313.874690][ T4013] brightness_show+0x20/0x4c [ 3313.874692][ T4013] dev_attr_show+0x38/0x74 [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130 [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54 [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4 [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8 [ 3313.874711][ T4013] ksys_read+0x78/0xe8 [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c [ 3313.874718][ T4013] invoke_syscall+0x58/0x114 [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0 [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28 [ 3313.874727][ T4013] el0_svc+0x38/0x68 [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Reviewed-by: Anish Kumar <yesanishhere@gmail.com> Link: https://lore.kernel.org/r/20241103160527.82487-1-quic_mojha@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-06leds: ktd2692: Set missing timing propertiesRaymond Hackley
props.timing is not set after commit b5a8c50e5c18 ("leds: ktd2692: Convert to use ExpressWire library"). Set it with ktd2692_timing. Fixes: b5a8c50e5c18 ("leds: ktd2692: Convert to use ExpressWire library") Signed-off-by: Raymond Hackley <raymondhackley@protonmail.com> Acked-by: Duje Mihanović <duje.mihanovic@skole.hr> Link: https://lore.kernel.org/r/20241103083505.49648-1-raymondhackley@protonmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-06leds: max5970: Fix unreleased fwnode_handle in probe functionJavier Carrasco
An object initialized via device_get_named_child_node() requires calls to fwnode_handle_put() when it is no longer required to avoid leaking memory. Add the automatic cleanup facility for 'led_node' to ensure that fwnode_handle_put() is called in all execution paths. Fixes: 736214b4b02a ("leds: max5970: Add support for max5970") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20241031-max5970-of_node_put-v2-1-0ffe1f1d3bc9@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-06leds: Introduce ordered workqueue for LEDs events instead of system_wqDmitry Rokosov
This allows to setup ordered workqueue for LEDs events. This may be useful, because default 'system_wq' does not guarantee execution order of each work_struct, thus for several brightness update requests (for multiple LEDs), real brightness switch could be in random order. Yes, for sysfs-based LEDs we have flush_work() call inside brightness_store() operation, but it's blocking call, so userspace caller can be blocked at a long time, which means LEDs animation stream can be broken. Ordered workqueue has the same behaviour as system_wq + flush_work(), but all scheduled works are async and userspace caller is not blocked, which it better for userspace animation scheduling. Signed-off-by: Alexey Romanov <avromanov@salutedevices.com> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Link: https://lore.kernel.org/r/20240903223936.21292-1-ddrokosov@salutedevices.com [Lee: Couple of style fix-ups] Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-06mfd: rt5033: Fix missing regmap_del_irq_chip()Zhang Changzhong
Fix missing call to regmap_del_irq_chip() in error handling path by using devm_regmap_add_irq_chip(). Fixes: 0b271258544b ("mfd: rt5033: Add Richtek RT5033 driver core.") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1730302867-8391-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-06clk: renesas: vbattb: Add VBATTB clock driverClaudiu Beznea
The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that is used by the RTC. The input to the VBATTB could be a 32KHz crystal or an external clock device. The HW block diagram for the clock generator is as follows: +----------+ XC `\ RTXIN --->| |----->| \ +----+ VBATTCLK | 32K clock| | |----->|gate|-----------> | osc | XBYP | | +----+ RTXOUT --->| |----->| / +----------+ , After discussions w/ Stephen Boyd the clock tree associated with this hardware block was exported in Linux as: vbattb-xtal xbyp xc mux vbattbclk where: - input-xtal is the input clock (connected to RTXIN, RTXOUT pins) - xc, xbyp are mux inputs - mux is the internal mux - vbattclk is the gate clock that feeds in the end the RTC to allow selecting the input of the MUX though assigned-clock DT properties, using the already existing clock drivers and avoid adding other DT properties. If the crystal is connected on RTXIN, RTXOUT pins the XC will be selected as mux input. If an external clock device is connected on RTXIN, RTXOUT pins the XBYP will be selected as mux input. The load capacitance of the internal crystal can be configured with renesas,vbattb-load-nanofarads DT property. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/20241101095720.2247815-4-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-11-06wifi: rtlwifi: Remove some exhalbtc deadcodeDr. David Alan Gilbert
exhalbtc_rf_status_notify(), exhalbtc_coex_dm_switch() and exhalbtc_antenna_detection() are unused since they were added in 2017's commit 7937f02d1953 ("rtlwifi: btcoex: hook external functions for newer chips") Remove them. This leaves ex_btc8723b1ant_coex_dm_reset() unused. Remove it. exhalbtc_dbg_control(), exhalbtc_stack_update_profile_info(), exhalbtc_set_hci_version(), and exhalbtc_set_bt_patch_version() are unused since their addition in 2014 by commit aa45a673b291 ("rtlwifi: btcoexist: Add new mini driver") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241104144331.29262-1-linux@treblig.org
2024-11-06wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failuresGuilherme G. Piccoli
Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000. Cc: stable@vger.kernel.org # v6.1+ Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com
2024-11-06wifi: rtw88: Enable the new RTL8821AU/RTL8812AU driversBitterblue Smith
These are older Wifi 5 chips. RTL8821AU is 1x1, with or without Bluetooth. RTL8812AU is 2x2, without Bluetooth. Beamforming is not implemented. It looks like these chips need a different implementation than what is in bf.c. Speed tests with RTL8821AU: 137 Mbps download, 144 Mbps upload. Speed tests with RTL8812AU: 344 Mbps download, 387 Mbps upload. Station mode and AP mode were tested. Bluetooth coexistence works. I used my Bluetooth headphones for several days, listening to music and watching videos. There is only a problem with the wifi speeds with one router: With ISP's HG6544C router: Official driver: 3/5 Mbps. rtw88: a bit more, but not steady at all. Not enough to watch a 1080p Youtube video. With my D-Link Eagle R32 router running Openwrt, on the same channel: Official driver: 6/10 Mbps. rtw88: download starts around 30, climbs to 50 / upload is 10 Mbps. I can watch a 1080p Youtube video. The music doesn't cut out during any speed tests. I also tested transferring files to and from my phone. I don't have other types of Bluetooth devices to test. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/0b8e8093-8103-4999-86bf-0055ec52ea64@gmail.com
2024-11-06wifi: rtw88: Add rtw8821au.c and rtw8812au.cBitterblue Smith
These are the entry points for the new modules rtw88_8821au (RTL8821AU/RTL8811AU) and rtw88_8812au (RTL8812AU). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/91c495f8-a607-429b-8bc0-5a45d3c1393e@gmail.com
2024-11-06wifi: rtw88: Add rtw8812a.{c,h}Bitterblue Smith
These contain code specific to RTL8812AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/a0057683-79eb-4ab2-8f74-11a3bc58adfb@gmail.com
2024-11-06wifi: rtw88: Add rtw8821a.{c,h}Bitterblue Smith
These contain code specific to RTL8821AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/37218648-ada7-4fad-b7bd-d2aee28cefb9@gmail.com
2024-11-06wifi: rtw88: Add rtw88xxa.{c,h}Bitterblue Smith
These contain code shared by both RTL8821AU and RTL8812AU chips. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/b8590382-a954-412d-a96b-63e360b97acc@gmail.com
2024-11-06wifi: rtw88: Add rtw8821a_table.{c,h}Bitterblue Smith
These contain various arrays for initialising RTL8821AU. Also TX power limits. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/087c7260-fcc3-4e22-886b-ac477cad9198@gmail.com
2024-11-06wifi: rtw88: Add rtw8812a_table.{c,h}Bitterblue Smith
These contain various arrays for initialising RTL8812AU. Also TX power limits. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/086f476c-e832-4867-963c-a64a63252fd6@gmail.com
2024-11-06wifi: rtw89: coex: set higher priority to BT when WL scan and BT A2DP existChing-Te Ku
If WiFi operation channel & scan channel both at 2.4GHz, original will keep going at WL > BT priority table for a long time. It makes A2DP can not sent audio data to SUT device in time then performed a lag audio. Assign a BT > WL priority table when A2DP exist, to avoid the issue. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241031023032.7102-1-pkshih@realtek.com
2024-11-06wifi: rtw89: 8852b: change RF mode to normal mode when set channelChih-Kang Chang
Set the RF mode from 0xA(low power mode) to 0x3(Normal mode) to avoid abnormal TX waveform in OFDM rate. Originally the RF mode will be changed to normal mode by the firmware after entering LPS once. Therefore, this change does not affect power saving. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030091603.6073-1-pkshih@realtek.com
2024-11-06wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()Pei Xiao
kmalloc may fail, return value might be NULL and will cause NULL pointer dereference. Add check NULL return of kmalloc in btc_fw_set_monreg(). Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Fixes: b952cb0a6e2d ("wifi: rtw89: coex: Add register monitor report v7 format") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/516a91f3997534f708af43c7592cbafdd53dd599.1730253508.git.xiaopei01@kylinos.cn
2024-11-06wifi: rtw89: 8922a: fill the missing OP1dB configurationKuan-Chung Chen
OP1dB stands for Output 1dB Compression Point. At this point, the power amplifier starts to enter the saturation region, resulting in distortion. The configuration of OP1dB can optimize the RX gain saturation region, improving RX throughput from 573 to 675 Mbps. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022903.13243-1-pkshih@realtek.com
2024-11-06wifi: rtw89: mac: no configure CMAC/DMAC tables for firmware secure bootPing-Ke Shih
The initial CMAC/DMAC tables used by WiFi 6 chips are not needed to be called for firmware secure boot. Otherwise, it causes firmware abnormal and throw warnings. rtw89_8852be 0000:03:00.0: FW status = 0x1400 rtw89_8852be 0000:03:00.0: FW BADADDR = 0xb872f800 rtw89_8852be 0000:03:00.0: FW EPC/RA = 0xb89333b7 rtw89_8852be 0000:03:00.0: FW MISC = 0x0 rtw89_8852be 0000:03:00.0: R_AX_HALT_C2H = 0x10002010 rtw89_8852be 0000:03:00.0: R_AX_SER_DBG_INFO = 0x0 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c95 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9d rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-9-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: use common function to parse security section for WiFi 6 chipsPing-Ke Shih
The MSSC (multiple security section count) can be regular number (shown in below figure) or 0xFF (supported already). For WiFi 7 or newer WiFi 6 chips, the MSSC will be 0xFF. But early WiFi 6 chip such as RTL8852B could be either one of the cases. Extend __parse_security_section() to support both with/without secure boot mode accordingly. +---------------------------+ -\ | firmware header | | | | | | +-----------------------+ | | | | section type/size * N | | | | +-----------------------+ | | +---------------------------+ -/ : : +---------------------------+ -\ | secure section type (ID:9)| | | | | +----|-> [ security key data ] | | | +---------------------------+ -/ | |MSS Pool for above section | | | [ security key data 1 ] | +----|- [ security key data 2 ] | by mss_idx | [ security key data 3 ] | | ... M | * M = MSSC (MSSC != 0xFF) +---------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-8-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: move v1 MSSC out of __parse_security_section() to share with v0Ping-Ke Shih
The security section can be a common parser for v0 and v1 format of firmware header, so move retrieval code of v1 MSSC from the function, and then sharing becomes possible. Not logic change at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-7-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: set recorded IDMEM share mode in firmware header to registerPing-Ke Shih
For WiFi 6 chips, firmware secure boot will run on a IDMEM mode specified in firmware header. Retrieve the mode from firmware, and set to registers accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-6-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: shrink download size of security section for RTL8852BPing-Ke Shih
For RTL8852B, when current firmware is secure boot, the security section needs a special treatment that shrink its size to 960. As figure below, not only shrink the amount of download size of security section (2), but also need to modify the section size in firmware header (1) that is also downloaded to chip. +---------------------------+ | firmware header | | | | +-----------------------+ | | | section type, size N -|-|-------+ | | ... (1) | | | | +-----------------------+ | | +---------------------------+ | 2048 shrink to 960 : : | +---------------------------+ -\ | | security section type 9 | | | | (2) | | <--+ | | | +---------------------------+ -/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-5-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: read firmware secure info v0 from efuse for WiFi 6 chipsPing-Ke Shih
WiFi 6 chips could program secure information in v0 or v1 format. Use existing v1 parser or newly added v0 parser to recognize firmware key that is going to be used. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-4-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: move recognize firmware MSS info v1 to commonPing-Ke Shih
The WiFi 6 chip use the same firmware MSS information v1 read from efuse, so move this logic to common. No change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-3-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: move reading efuse of fw secure info to commonPing-Ke Shih
The secure key used by certain hardware module is programmed in efuse, so driver should read the information from efuse before downloading firmware. Originally only RTL8922AE can support firmware secure boot, and read efuse during chip power on. To extend to support all chips, move the caller to common power on flow and add separate functions to read efuse for WiFi 6 chips. No logic change at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-2-pkshih@realtek.com
2024-11-05md/md-bitmap: Add missing destroy_work_on_stack()Yuan Can
This commit add missed destroy_work_on_stack() operations for unplug_work.work in bitmap_unplug_async(). Fixes: a022325ab970 ("md/md-bitmap: add a new helper to unplug bitmap asynchrously") Cc: stable@vger.kernel.org Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20241105130105.127336-1-yuancan@huawei.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2024-11-04 (ice, idpf, i40e, e1000e) For ice: Marcin adjusts ordering of calls in ice_eswitch_detach() to resolve a use after free issue. Mateusz corrects variable type for Flow Director queue to fix issues related to drop actions. For idpf: Pavan resolves issues related to reset on idpf; avoiding use of freed vport and correctly unrolling the mailbox task. For i40e: Aleksandr fixes a race condition involving addition and deletion of VF MAC filters. For e1000e: Vitaly reverts workaround for Meteor Lake causing regressions in power management flows. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: e1000e: Remove Meteor Lake SMBUS workarounds i40e: fix race condition by adding filter's intermediate sync state idpf: fix idpf_vc_core_init error path idpf: avoid vport access in idpf_get_link_ksettings ice: change q_index variable type to s16 to store -1 value ice: Fix use after free during unload with ports in bridge ==================== Link: https://patch.msgid.link/20241104223639.2801097-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05net: stmmac: Add glue layer for T-HEAD TH1520 SoCJisheng Zhang
Add dwmac glue driver to support the DesignWare-based GMAC controllers on the T-HEAD TH1520 SoC. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by: Drew Fustini <dfustini@tenstorrent.com> Link: https://patch.msgid.link/20241103-th1520-gmac-v7-2-ef094a30169c@tenstorrent.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05r8169: remove leftover locks after reverted changeHeiner Kallweit
After e31a9fedc7d8 ("Revert "r8169: disable ASPM during NAPI poll"") these locks aren't needed any longer. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/680f2606-ac7d-4ced-8694-e5033855da9b@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05net: phy: ti: add PHY_RST_AFTER_CLK_EN flagDiogo Silva
DP83848 datasheet (section 4.7.2) indicates that the reset pin should be toggled after the clocks are running. Add the PHY_RST_AFTER_CLK_EN to make sure that this indication is respected. In my experience not having this flag enabled would lead to, on some boots, the wrong MII mode being selected if the PHY was initialized on the bootloader and was receiving data during Linux boot. Signed-off-by: Diogo Silva <diogompaissilva@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Fixes: 34e45ad9378c ("net: phy: dp83848: Add TI DP83848 Ethernet PHY") Link: https://patch.msgid.link/20241102151504.811306-1-paissilva@ld-100007.ds1.internal Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-05net: stmmac: add support for dwmac 3.72aLothar Rubusch
The dwmac 3.72a is an ip version that can be found on Intel/Altera Arria10 SoCs. Going by the hardware features "snps,multicast-filter-bins" and "snps,perfect-filter-entries" shall be supported. Thus add a compatibility flag, and extend coverage of the driver for the 3.72a. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20241102114122.4631-2-l.rubusch@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-14 20:48:48 +0000