summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-11-18Merge tag 'vfs-6.13.file' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs file updates from Christian Brauner: "This contains changes the changes for files for this cycle: - Introduce a new reference counting mechanism for files. As atomic_inc_not_zero() is implemented with a try_cmpxchg() loop it has O(N^2) behaviour under contention with N concurrent operations and it is in a hot path in __fget_files_rcu(). The rcuref infrastructures remedies this problem by using an unconditional increment relying on safe- and dead zones to make this work and requiring rcu protection for the data structure in question. This not just scales better it also introduces overflow protection. However, in contrast to generic rcuref, files require a memory barrier and thus cannot rely on *_relaxed() atomic operations and also require to be built on atomic_long_t as having massive amounts of reference isn't unheard of even if it is just an attack. This adds a file specific variant instead of making this a generic library. This has been tested by various people and it gives consistent improvement up to 3-5% on workloads with loads of threads. - Add a fastpath for find_next_zero_bit(). Skip 2-levels searching via find_next_zero_bit() when there is a free slot in the word that contains the next fd. This improves pts/blogbench-1.1.0 read by 8% and write by 4% on Intel ICX 160. - Conditionally clear full_fds_bits since it's very likely that a bit in full_fds_bits has been cleared during __clear_open_fds(). This improves pts/blogbench-1.1.0 read up to 13%, and write up to 5% on Intel ICX 160. - Get rid of all lookup_*_fdget_rcu() variants. They were used to lookup files without taking a reference count. That became invalid once files were switched to SLAB_TYPESAFE_BY_RCU and now we're always taking a reference count. Switch to an already existing helper and remove the legacy variants. - Remove pointless includes of <linux/fdtable.h>. - Avoid cmpxchg() in close_files() as nobody else has a reference to the files_struct at that point. - Move close_range() into fs/file.c and fold __close_range() into it. - Cleanup calling conventions of alloc_fdtable() and expand_files(). - Merge __{set,clear}_close_on_exec() into one. - Make __set_open_fd() set cloexec as well instead of doing it in two separate steps" * tag 'vfs-6.13.file' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: selftests: add file SLAB_TYPESAFE_BY_RCU recycling stressor fs: port files to file_ref fs: add file_ref expand_files(): simplify calling conventions make __set_open_fd() set cloexec state as well fs: protect backing files with rcu file.c: merge __{set,clear}_close_on_exec() alloc_fdtable(): change calling conventions. fs/file.c: add fast path in find_next_fd() fs/file.c: conditionally clear full_fds fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() move close_range(2) into fs/file.c, fold __close_range() into it close_files(): don't bother with xchg() remove pointless includes of <linux/fdtable.h> get rid of ...lookup...fdget_rcu() family
2024-11-18nvme-pci: use sgls for all user requests if possibleKeith Busch
If the device supports SGLs, use these for all user requests. This format encodes the expected transfer length so it can catch short buffer errors in a user command, whether it occurred accidently or maliciously. For controllers that support SGL data mode, this is a viable mitigation to CVE-2023-6238. For controllers that don't support SGLs, log a warning in the passthrough path since not having the capability can corrupt data if the interface is not used correctly. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2024-11-18PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf()Zijun Hu
In addition to a primary endpoint controller, an endpoint function may be associated with a secondary endpoint controller, epf->sec_epc, to provide NTB (non-transparent bridge) functionality. Previously, pci_epc_remove_epf() incorrectly cleared epf->epc instead of epf->sec_epc when removing from the secondary endpoint controller. Extend the epc->list_lock coverage and clear either epf->epc or epf->sec_epc as indicated. Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-2-da5b6a99a66f@quicinc.com Fixes: 63840ff53223 ("PCI: endpoint: Add support to associate secondary EPC with EPF") Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Cc: stable@vger.kernel.org
2024-11-18nvme: define the remaining used sgls constantsKeith Busch
This provides a little more context when reading the code than hardcoded magic numbers. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2024-11-18nvme-pci: add support for sgl metadataKeith Busch
Supporting this mode allows creating and merging multi-segment metadata requests that wouldn't be possible otherwise. It also allows directly using user space requests that straddle physically discontiguous pages. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2024-11-18PCI: endpoint: Fix PCI domain ID release in pci_epc_destroy()Zijun Hu
pci_epc_destroy() invokes pci_bus_release_domain_nr() to release the PCI domain ID, but there are two issues: - 'epc->dev' is passed to pci_bus_release_domain_nr() which was already freed by device_unregister(), leading to a use-after-free issue. - Domain ID corresponds to the EPC device parent, so passing 'epc->dev' is also wrong. Fix these issues by passing 'epc->dev.parent' to pci_bus_release_domain_nr() and also do it before device_unregister(). Fixes: 0328947c5032 ("PCI: endpoint: Assign PCI domain number for endpoint controllers") Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-1-da5b6a99a66f@quicinc.com [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Cc: stable@vger.kernel.org
2024-11-18nvme/multipath: Fix RCU list traversal to use SRCU primitiveBreno Leitao
The code currently uses list_for_each_entry_rcu() while holding an SRCU lock, triggering false positive warnings with CONFIG_PROVE_RCU=y enabled: drivers/nvme/host/multipath.c:168 RCU-list traversed in non-reader section!! drivers/nvme/host/multipath.c:227 RCU-list traversed in non-reader section!! drivers/nvme/host/multipath.c:260 RCU-list traversed in non-reader section!! While the list is properly protected by SRCU lock, the code uses the wrong list traversal primitive. Replace list_for_each_entry_rcu() with list_for_each_entry_srcu() to correctly indicate SRCU-based protection and eliminate the false warning. Signed-off-by: Breno Leitao <leitao@debian.org> Fixes: be647e2c76b2 ("nvme: use srcu for iterating namespace list") Signed-off-by: Keith Busch <kbusch@kernel.org>
2024-11-18regulator: qcom-rpmh: Update ranges for FTSMPS525Melody Olvera
All FTSMPS525 regulators support LV and MV ranges; however, the boot loader firmware will determine which range to use as the device boots. Nonetheless, the driver cannot determine which range was selected, so hardcoding the ranges as either LV or MV will not cover all cases as it's possible for the firmware to select a range not supported by the driver's current hardcoded values. To this end, combine the ranges for the FTSMPS525s into one struct and point all regulators to the updated combined struct. This should work on all boards regardless of which range is selected by the firmware and more accurately caputres the capability of this regulator on a hardware level. Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patch.msgid.link/20241112002645.2803506-1-quic_molvera@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-18s390/con3215: Remove spurious NULL in attribute_group definitionThomas Weißschuh
This NULL value is most-likely a copy-paste error from an array definition. So far the NULL didn't have any effect. As there will be a union in struct attribute_group at this location, it will trigger a compiler warning. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241118-sysfs-const-attribute_group-fixes-v1-2-48e0b0ad8cba@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-18perf: arm-ni: Remove spurious NULL in attribute_group definitionThomas Weißschuh
This NULL value is most-likely a copy-paste error from an array definition. So far the NULL didn't have any effect. As there will be a union in struct attribute_group at this location, it will trigger a compiler warning. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241118-sysfs-const-attribute_group-fixes-v1-1-48e0b0ad8cba@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-18rtc: brcmstb-waketimer: don't include 'pm_wakeup.h' directlyWolfram Sang
The header clearly states that it does not want to be included directly, only via 'device.h'. 'platform_device.h' works equally well. Remove the direct inclusion. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20241118072917.3853-14-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18rtc: m48t59: Use platform_data struct for year offset valueFinn Thain
Instead of hard-coded values and ifdefs, store the year offset in the platform_data struct. Tested-by: Daniel Palmer <daniel@0x0f.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Finn Thain <fthain@linux-m68k.org> Tested-by: Andreas Larsson <andreas@gaisler.com> Acked-by: Andreas Larsson <andreas@gaisler.com> Link: https://lore.kernel.org/r/665c3526184a8d0c4a6373297d8e7d9a12591d8b.1731450735.git.fthain@linux-m68k.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to ↵Defa Li
avoid deadlock A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice. v2: - Modified the title and commit message ============================================ WARNING: possible recursive locking detected 6.11.0-mainline -------------------------------------------- init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&i3cbus->lock); lock(&i3cbus->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac Signed-off-by: Defa Li <defa.li@mediatek.com> Link: https://lore.kernel.org/r/20241107132549.25439-1-defa.li@mediatek.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18i3c: mipi-i3c-hci: Support SETDASA CCCBilly Tsai
When the I3C subsystem wants to assign a dynamic address using the SETDASA CCC, it needs to attach the I3C device with device info that includes only the static address. In the HCI, if the driver want to send this SETDASA CCC, a DAT entry is required to temporarily fill the device's static address into the dynamic address field. Afterward, the reattach API will be executed to update the DAT with the correct dynamic addrees value. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20241113035826.923918-1-billy_tsai@aspeedtech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18i3c: dw: Add quirk to address OD/PP timing issue on AMD platformShyam Sundar S K
The AMD Legacy I3C is having a problem with its IP, specifically with the push-pull and open-drain pull-up registers. These registers need to be manually programmed for every CCC submission to align with the duty cycle. Therefore, add a quirk to address this issue. Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Co-developed-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20241114110239.660551-3-Shyam-sundar.S-k@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18i3c: dw: Add support for AMDI0015 ACPI IDShyam Sundar S K
Add AMDI0015 _HID for Designware I3C driver so that the dw-i3c-master driver can be probed on AMD platforms. Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20241114110239.660551-2-Shyam-sundar.S-k@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18Merge branch 'for-6.13-force-console' into for-linusPetr Mladek
2024-11-18net: ethernet: ti: am65-cpsw: enable DSCP to priority map for RXRoger Quadros
AM65 CPSW hardware can map the 6-bit DSCP/TOS field to appropriate priority queue via DSCP to Priority mapping registers (CPSW_PN_RX_PRI_MAP_REG). Use a default DSCP to User Priority (UP) mapping as per https://datatracker.ietf.org/doc/html/rfc8325#section-4.3 and https://datatracker.ietf.org/doc/html/rfc8622#section-11 Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-11-18net: ethernet: ti: am65-cpsw: update pri_thread_map as per IEEE802.1Q-2014Roger Quadros
IEEE802.1Q-2014 supersedes IEEE802.1D-2004. Now Priority Code Point (PCP) 2 is no longer at a lower priority than PCP 0. PCP 1 (Background) is still at a lower priority than PCP 0 (Best Effort). Reference: IEEE802.1Q-2014, Standard for Local and metropolitan area networks Table I-2 - Traffic type acronyms Table I-3 - Defining traffic types Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-11-18platform/x86: p2sb: Cache correct PCI bar for P2SB on Gemini LakeHans de Goede
Gemini Lake (Goldmont Plus) is an Apollo Lake (Goldmont) derived design and as such has the P2SB at device.function 13.0, rather then at the default 31.1, just like Apollo Lake. At a mapping to P2SB_DEVFN_GOLDMONT to p2sb_cpu_ids[] for Goldmont Plus, so that the correct PCI bar gets cached. This fixes P2SB unhiding not working on these devices, which fixes SPI support for the bootrom SPI controller not working. Fixes: 2841631a0365 ("platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe") Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241116154546.85761-1-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-18platform/x86: panasonic-laptop: Return errno correctly in show callbackYao Zi
When an error occurs in sysfs show callback, we should return the errno directly instead of formatting it as the result, which produces meaningless output and doesn't inform the userspace of the error. Fixes: 468f96bfa3a0 ("platform/x86: panasonic-laptop: Add support for battery charging threshold (eco mode)") Fixes: d5a81d8e864b ("platform/x86: panasonic-laptop: Add support for optical driver power in Y and W series") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241118064637.61832-3-ziyao@disroot.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-11-18rtc: ab-eoz9: fix abeoz9_rtc_read_alarmAlexandre Belloni
abeoz9_rtc_read_alarm assumes we always read the alarm in 12-hour mode while abeoz9_rtc_set_alarm will always set it in 24-hour mode. We could support 12-hour mode in both functions but it seems very unlikely that the RTC would be set to 12-hour mode now as the driver has been setting it to 24-hour mode for a while now. The setting is undefined at power-up and unchanged by subsequent resets which doesn't help us. Link: https://lore.kernel.org/r/20241112151119.3451611-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18rtc: rv3028: fix RV3028_TS_COUNT typeAlexandre Belloni
Read RV3028_TS_COUNT in an unsigned int so static checkers stop reporting a mismatch between the format specifier and the type. Reported-by: Zhu Jun <zhujun2@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20241111104711.3170865-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18rtc: rzn1: update Michel's emailWolfram Sang
The Renesas address bounces, use the alternative one. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20241114193450.13982-1-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18rtc: rzn1: fix BCD to rtc_time conversion errorsWolfram Sang
tm_mon describes months from 0 to 11, but the register contains BCD from 1 to 12. tm_year contains years since 1900, but the BCD contains 20XX. Apply the offsets when converting these numbers. Fixes: deeb4b5393e1 ("rtc: rzn1: Add new RTC driver") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20241113113032.27409-1-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-18gpio: tegra186: Allow to enable driver on Tegra234Lars-Peter Clausen
Support for Tegra234 was added to the tegra186 driver in 1db9b241bb56 ( "gpio: tegra186: Add support for Tegra234"). But the driver is not selectable on Tegra234. Update the Kconfig entry to allow the driver to be enabled on Tegra234. Enable the driver by default on Tegra 234 as well, similar to the other platforms it supports. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241113162939.886242-1-lars@metafoo.de Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-18gpio: grgpio: Add NULL check in grgpio_probeCharles Han
devm_kasprintf() can return a NULL pointer on failure,but this returned value in grgpio_probe is not checked. Add NULL check in grgpio_probe, to handle kernel NULL pointer dereference error. Cc: stable@vger.kernel.org Fixes: 7eb6ce2f2723 ("gpio: Convert to using %pOF instead of full_name") Signed-off-by: Charles Han <hanchunchao@inspur.com> Link: https://lore.kernel.org/r/20241114091822.78199-1-hanchunchao@inspur.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-18Merge branch 'edac-misc' into edac-updatesBorislav Petkov (AMD)
* edac-misc: MAINTAINERS: Change FSL DDR EDAC maintainership RAS/AMD/ATL: Add debug prints for DF register reads EDAC/bluefield: Use Arm SMC for EMI access on BlueField-2 EDAC/bluefield: Fix potential integer overflow EDAC/igen6: Add Intel Panther Lake-H SoCs support Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
2024-11-18Merge tag 'i2c-host-6.13-p1' of ↵Wolfram Sang
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-mergewindow i2c-host updates for v6.13, part 1 Major Improvements and Refactoring: - All controllers using the 'remove_new' callback have been reverted to use the 'remove' callback. - Intel SCH controller underwent significant refactoring, this brings love and a modern look to the driver. - PIIX4 driver refactored to enable usage by other drivers (e.g., AMD ASF). - iMX/MXC improved message handling to reduce protocol overhead: Refactored DMA/non-DMA read/write and bus polling mechanisms to achieve this. - ACPI documentation for PIIX4. New Features: - i2c-cadence added support for atomic transfers. - Qualcomm CII added support for a 32MHz serial engine clock. Deprecated Features: - Dropped outdated support for AMD756 S4882 and NFORCE2 S4985. If somebody misses this, Jean will rewrite support using the proper i2c mux framework. New Hardware Support: - Added support for: - Intel Panther Lake (new ID) - AMD ASF (new driver) - S32G2/S32G3 SoCs (new ID) - Realtek RTL I2C Controller (new driver) - HJMC01 DesignWare ACPI HID (new ID) - PIC64GX to Microchip Core (new ID) - Qualcomm SDM670 to Qualcomm CCI (new ID)
2024-11-18Merge tag 'drm-xe-next-fixes-2024-11-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Fix a NULL pointer deref (Everest K.C.) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZzcsMT_FEqBE0cAW@fedora
2024-11-18Merge tag 'amd-drm-next-6.13-2024-11-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.13-2024-11-15: amdgpu: - Parition fixes - GFX 12 fixes - SR-IOV fixes - MES fixes - RAS fixes - GC queue handling fixes - VCN fixes - Add sysfs reset masks - Better error messages for P2P failurs - SMU fixes - Documentation updates - GFX11 enforce isolation updates - Display HPD fixes - PSR fixes - Panel replay fixes - DP MST fixes - USB4 fixes - Misc display fixes and cleanups - VRAM handling fix for APUs - NBIO fix amdkfd: - INIT_WORK fix - Refcount fix - KFD MES scheduling fixes drm/fourcc: - Add missing tiling mode Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241115165012.573465-1-alexander.deucher@amd.com
2024-11-18pinctrl: qcom: spmi: fix debugfs drive strengthJohan Hovold
Commit 723e8462a4fe ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping") fixed a long-standing issue in the Qualcomm SPMI PMIC gpio driver which had the 'low' and 'high' drive strength settings switched but failed to update the debugfs interface which still gets this wrong. Fix the debugfs code so that the exported values match the hardware settings. Note that this probably means that most devicetrees that try to describe the firmware settings got this wrong if the settings were derived from debugfs. Before the above mentioned commit the settings would have actually matched the firmware settings even if they were described incorrectly, but now they are inverted. Fixes: 723e8462a4fe ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping") Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver") Cc: Anjelique Melendez <quic_amelende@quicinc.com> Cc: stable@vger.kernel.org # 3.19 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/20241025121622.1496-1-johan+linaro@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-11-17i2c: Add driver for the RTL9300 I2C controllerChris Packham
Add support for the I2C controller on the RTL9300 SoC. There are two I2C controllers in the RTL9300 that are part of the Ethernet switch register block. Each of these controllers owns a SCL pin (GPIO8 for the fiorst I2C controller, GPIO17 for the second). There are 8 possible SDA pins (GPIO9-16) that can be assigned to either I2C controller. This relationship is represented in the device tree with a child node for each SDA line in use. This is based on the openwrt implementation[1] but has been significantly modified [1] - https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/realtek/files-5.15/drivers/i2c/busses/i2c-rtl9300.c Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: qcom-cci: Remove unused struct member cci_clk_rateVladimir Zapolskiy
The removal of the supply clock rate check implies a need to remove some unnecessary left-over data from the driver as well. Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: busses: Use *-y instead of *-objs in MakefileAndy Shevchenko
*-objs suffix is reserved rather for (user-space) host programs while usually *-y suffix is used for kernel drivers (although *-objs works for that purpose for now). Let's correct the old usages of *-objs in Makefiles. While at it, fix an obvious typo in help section of the Kconfig. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: imx: add support for S32G2/S32G3 SoCsCiprian Marian Costea
Some S32G2/S32G3 SoC I2C particularities exist such as different <clock divider, register value> pairs. Those are addressed by adding specific S32G2 and S32G3 compatible strings. Co-developed-by: Ionut Vicovan <Ionut.Vicovan@nxp.com> Signed-off-by: Ionut Vicovan <Ionut.Vicovan@nxp.com> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: qcom-cci: Remove the unused variable cci_clk_rateJiapeng Chong
Variable cci_clk_rate is not effectively used, so delete it. drivers/i2c/busses/i2c-qcom-cci.c:526:16: warning: variable ‘cci_clk_rate’ set but not used. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=11532 Fixes: 8284750a1829 ("i2c: qcom-cci: Stop complaining about DT set clock rate") Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: Drop legacy muxing pseudo-driversJean Delvare
The i2c-amd756-s4882 and i2c-nforce2-s4985 muxing pseudo-drivers were written at a time when the i2c core did not support muxing. They are essentially board-specific hacks. If we had to add support for these boards today, we would implement it in a completely different way. These Tyan server boards are 19 years old by now, so I very much doubt any of these is still running today. So let's just drop this clumsy code. If anyone really still needs this support and complains, I'll rewrite it in a proper way on top of i2c-mux. This also fixes the following warnings: drivers/i2c/busses/i2c-amd756.c:286:20: warning: symbol 'amd756_smbus' was not declared. Should it be static? drivers/i2c/busses/i2c-nforce2.c:123:20: warning: symbol 'nforce2_smbus' was not declared. Should it be static? Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Andi Shyti <andi.shyti@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: imx: prevent rescheduling in non dma modeStefan Eichenberger
We are experiencing a problem with the i.MX I2C controller when communicating with SMBus devices. We are seeing devices time-out because the time between sending/receiving two bytes is too long, and the SMBus device returns to the idle state. This happens because the i.MX I2C controller sends and receives byte by byte. When a byte is sent or received, we get an interrupt and can send or receive the next byte. The current implementation sends a byte and then waits for an event generated by the interrupt subroutine. After the event is received, the next byte is sent and we wait again. This waiting allows the scheduler to reschedule other tasks, with the disadvantage that we may not send the next byte for a long time because the send task is not immediately scheduled. For example, if the rescheduling takes more than 25ms, this can cause SMBus devices to timeout and communication to fail. This patch changes the behavior so that we do not reschedule the send/receive task, but instead send or receive the next byte in the interrupt subroutine. This prevents rescheduling and drastically reduces the time between sending/receiving bytes. The cost in the interrupt subroutine is relatively small, we check what state we are in and then send/receive the next byte. Before we had to call wake_up, which is even less expensive. However, we also had to do some scheduling, which increased the overall cost compared to the new solution. The wake_up function to wake up the send/receive task is now only called when an error occurs or when the transfer is complete. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: imx: separate atomic, dma and non-dma use caseStefan Eichenberger
Separate the atomic, dma and non-dma use case as a preparation step for moving the non-dma use case to the isr to avoid rescheduling while a transfer is in progress. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: imx: do not poll for bus busy in single master modeStefan Eichenberger
According to the i.MX8M Mini reference manual chapter "16.1.4.2 Generation of Start" it is only necessary to poll for bus busy and arbitration lost in multi master mode. This helps to avoid rescheduling while the i2c bus is busy and avoids SMBus devices to timeout. For backward compatibility, the single-master property needs to be explicitly set to disable the bus busy polling. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: designware: Add a new ACPI HID for HJMC01 I2C controllerHunter Yu
Define a new ACPI HID for HJMC01 Signed-off-by: Hunter Yu <hunter.yu@hj-micro.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: qcom-geni: Keep comment why interrupts start disabledWolfram Sang
The to-be-fixed commit rightfully reduced a race window, but also removed a comment which is still helpful after the fix. Bring the comment back. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: designware: constify abort_sourcesRaag Jadav
We never modify abort_sources, mark it as const. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: Switch back to struct platform_driver::remove()Uwe Kleine-König
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/i2c to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: qcom-geni: Support systems with 32MHz serial engine clockManikanta Mylavarapu
In existing socs, I2C serial engine is sourced from XO (19.2MHz). Where as in IPQ5424, I2C serial engine is sourced from GPLL0 (32MHz). The existing map table is based on 19.2MHz. This patch incorporates the clock map table to derive the SCL clock from the 32MHz source clock frequency. Signed-off-by: Manikanta Mylavarapu <quic_mmanikan@quicinc.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: qcom-cci: Stop complaining about DT set clock rateBryan O'Donoghue
It is common practice in the downstream and upstream CCI dt to set CCI clock rates to 19.2 MHz. It appears to be fairly common for initial code to set the CCI clock rate to 37.5 MHz. Applying the widely used CCI clock rates from downstream ought not to cause warning messages in the upstream kernel where our general policy is to usually copy downstream hardware clock rates across the range of Qualcomm drivers. Drop the warning it is pervasive across CAMSS users but doesn't add any information or warrant any changes to the DT to align the DT clock rate to the bootloader clock rate. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/linux-arm-msm/20240824115900.40702-1-bryan.odonoghue@linaro.org Signed-off-by: Richard Acayan <mailingradian@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: npcm: use a software flag to indicate a BER conditionTyrone Ting
If not clearing the BB (bus busy) condition in the BER (bus error) interrupt, the driver causes a timeout and hence the i2c core doesn't do the i2c transfer retry but returns the driver's return value to the upper layer instead. Clear the BB condition in the BER interrupt and a software flag is used. The driver does an i2c recovery without causing the timeout if the flag is set. Signed-off-by: Tyrone Ting <kfting@nuvoton.com> Reviewed-by: Tali Perry <tali.perry1@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: npcm: correct the read/write operation procedureTyrone Ting
Originally the driver uses the XMIT bit in SMBnST register to decide the upcoming i2c transaction. If XMIT bit is 1, then it will be an i2c write operation. If it's 0, then a read operation will be executed. In slave mode the XMIT bit can simply be used directly to set the state. XMIT bit can be used as an indication to the current state of the state machine during slave operation. (meaning XMIT = 1 during writing and XMIT = 0 during reading). In master operation XMIT is valid only if there are no bus errors. For example: in a multi master where the same module is switching from master to slave at runtime, and there are collisions, the XMIT bit cannot be trusted. However the maser already "knows" what the bus state is, so this bit is not needed and the driver can just track what it is currently doing. Signed-off-by: Tyrone Ting <kfting@nuvoton.com> Reviewed-by: Tali Perry <tali.perry1@gmail.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2024-11-17i2c: amd-asf: Fix uninitialized variables issue in amd_asf_process_targetQianqiang Liu
The len variable is not initialized, which may cause the for loop to behave unexpectedly. Fixes: 9b25419ad397 ("i2c: amd-asf: Add routine to handle the ASF slave process") Signed-off-by: Qianqiang Liu <qianqiang.liu@163.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-12 06:22:48 +0000