summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
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>
2024-11-17watchdog: rti: of: honor timeout-sec propertyAlexander Sverdlin
Currently "timeout-sec" Device Tree property is being silently ignored: even though watchdog_init_timeout() is being used, the driver always passes "heartbeat" == DEFAULT_HEARTBEAT == 60 as argument. Fix this by setting struct watchdog_device::timeout to DEFAULT_HEARTBEAT and passing real module parameter value to watchdog_init_timeout() (which may now be 0 if not specified). Cc: stable@vger.kernel.org Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support") Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20241107203830.1068456-1-alexander.sverdlin@siemens.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
2024-11-17RDMA/bnxt_re: Correct the sequence of device suspendKalesh AP
When in fatal error condition, mark device as detached first and then complete all pending HWRM commands as firmware is not going to process them and eventually time out. Move the device to error only if suspend is called when device is in Fatal state. Also, remove some outdated comments. Remove the stop_irq call which is no longer required. Fixes: cc5b9b48d447 ("RDMA/bnxt_re: Recover the device when FW error is detected") Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1731660464-27838-4-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-17RDMA/bnxt_re: Use the default mode of congestion controlKalesh AP
Instead of driver setting the congestion mode, use the default values setup by Firmware. Enable the tos_ecn field in FW. Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1731660464-27838-3-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-17RDMA/bnxt_re: Support different traffic classChandramohan Akula
Adding support for different traffic class passed to driver. Fix the traffic class setting in modify_qp by skipping the ECN bits. Pass the service level received from applications to the firmware. Signed-off-by: Chandramohan Akula <chandramohan.akula@broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1731660464-27838-2-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-17IB/cm: Rework sending DREQ when destroying a cm_idSean Hefty
A DREQ is sent in 2 situations: 1. When requested by the user. This DREQ has to wait for a DREP, which will be routed to the user. 2. When the cm_id is destroyed. This DREQ is generated by the CM to notify the peer that the connection has been destroyed. In the latter case, any DREP that is received will be discarded. There's no need to hold a reference on the cm_id. Today, both situations are covered by the same function: cm_send_dreq_locked(). When invoked in the cm_id destroy path, the cm_id reference would be held until the DREQ completes, blocking the destruction. Because it could take several seconds to minutes before the DREQ receives a DREP, the destroy call posts a send for the DREQ then immediately cancels the MAD. However, cancellation is not immediate in the MAD layer. There could still be a delay before the MAD layer returns the DREQ to the CM. Moreover, the only guarantee is that the DREQ will be sent at most once. Introduce a separate flow for sending a DREQ when destroying the cm_id. The new flow will not hold a reference on the cm_id, allowing it to be cleaned up immediately. The cancellation trick is no longer needed. The MAD layer will send the DREQ exactly once. Signed-off-by: Sean Hefty <shefty@nvidia.com> Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Signed-off-by: Vlad Dumitrescu <vdumitrescu@nvidia.com> Link: https://patch.msgid.link/a288a098b8e0550305755fd4a7937431699317f4.1731495873.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-17IB/cm: Do not hold reference on cm_id unless neededSean Hefty
Typically, when the CM sends a MAD it bumps a reference count on the associated cm_id. There are some exceptions, such as when the MAD is a direct response to a receive MAD. For example, the CM may generate an MRA in response to a duplicate REQ. But, in general, if a MAD may be sent as a result of the user invoking an API call (e.g. ib_send_cm_rep(), ib_send_cm_rtu(), etc.), a reference is taken on the cm_id. This reference is necessary if the MAD requires a response. The reference allows routing a response MAD back to the cm_id, or, if no response is received, allows updating the cm_id state to reflect the failure. For MADs which do not generate a response from the target, however, there's no need to hold a reference on the cm_id. Such MADs will not be retried by the MAD layer and their completions do not change the state of the cm_id. There are 2 internal calls used to allocate MADs which take a reference on the cm_id: cm_alloc_msg() and cm_alloc_priv_msg(). The latter calls the former. It turns out that all other places where cm_alloc_msg() is called are for MADs that do not generate a response from the target: sending an RTU, DREP, REJ, MRA, or SIDR REP. In all of these cases, there's no need to hold a reference on the cm_id. The benefit of dropping unneeded references is that it allows destruction of the cm_id to proceed immediately. Currently, the cm_destroy_id() call blocks as long as there's a reference held on the cm_id. Worse, is that cm_destroy_id() will send MADs, which it then needs to complete. Sending the MADs is beneficial, as they notify the peer that a connection is being destroyed. However, since the MADs hold a reference on the cm_id, they block destruction and cannot be retried. Move cm_id referencing from cm_alloc_msg() to cm_alloc_priv_msg(). The latter should hold a reference on the cm_id in all cases but one, which will be handled in a separate patch. cm_alloc_priv_msg() is used when sending a REQ, REP, DREQ, and SIDR REQ, all of which require a response. Also, merge common code into cm_alloc_priv_msg() and combine the freeing of all messages which do not need a response. Signed-off-by: Sean Hefty <shefty@nvidia.com> Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Signed-off-by: Vlad Dumitrescu <vdumitrescu@nvidia.com> Link: https://patch.msgid.link/1f0f96acace72790ecf89087fc765dead960189e.1731495873.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-17IB/cm: Explicitly mark if a response MAD is a retransmissionSean Hefty
In several situations the CM may send a reply to a received MAD without the reply being directly linked with a cm_id. For example, it may send a REJ in response to a REQ which does not match a listener. Or, it may send a DREP in response to a DREQ if the cm_id has already been destroyed. This can happen if the original DREP was lost and the DREQ was retried. When such a response MAD completes, it updates a counter tracking how many MADs were retried. However, not all response MADs issued directly by the CM may be retries. The REJ mentioned in the example above is such a case. To distinguish between responses which were retries versus those that are not, the send_handler performs the following check: is a retry if the response is not associated with a cm_id and the response is not a REJ message. Replace this indirect method of checking if a response is a retry with an explicit check. Note that these retries are generated directly by the CM, rather than retried by the MAD layer. This change will be needed by later changes which would otherwise break the indirect check. Signed-off-by: Sean Hefty <shefty@nvidia.com> Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Signed-off-by: Vlad Dumitrescu <vdumitrescu@nvidia.com> Link: https://patch.msgid.link/1ee6e2a68f8de1992b9da23aa1d7e3f9f25e0036.1731495873.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-17efi: Fix memory leak in efivar_ssdt_loadCyrill Gorcunov
When we load SSDT from efi variable (specified with efivar_ssdt=<var> boot command line argument) a name for the variable is allocated dynamically because we traverse all EFI variables. Unlike ACPI table data, which is later used by ACPI engine, the name is no longer needed once traverse is complete -- don't forget to free this memory. Same time we silently ignore any errors happened here let's print a message if something went wrong (but do not exit since this is not a critical error and the system should continue to boot). Also while here -- add a note why we keep SSDT table on success. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
generated by cgit v1.2.3-70-g09d2 (git 2.48.1) at 2025-07-23 17:31:35 +0000