- 18 Jan, 2024 38 commits
-
-
Wolfram Sang authored
Renesas is solely funding my I2C maintenance meanwhile, give them credit for that by using this email address. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
-
Alain Volmat authored
The stm32mp25 has only a single interrupt line used for both events and errors. In order to cope with that, reorganise the error handling code so that it can be called either from the common handler (used in case of SoC having only a single IT line) and the error handler for others. The CR1 register also embeds a new FMP bit, necessary when running at Fast Mode Plus frequency. This bit should be used instead of the SYSCFG bit used on other platforms. Add a new compatible to distinguish between the SoCs and two boolean within the setup structure in order to know if the platform has a single/multiple IT lines and if the FMP bit within CR1 is available or not. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Alain Volmat authored
Move readl_relaxed of I2C_ISR register at beginning of event isr so that it done once for both master & slave handling. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Alain Volmat authored
Add a new compatible st,stm32mp25-i2c for the STM32MP25 series which has only one interrupt line for both events and errors and differs in term of handling of FastModePlus. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Alain Volmat authored
Avoid usage of __func__ when reporting an error message since dev_err/dev_dbg are already providing enough details to identify the source of the message. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Alain Volmat authored
The irq handling is currently split between the irq handler and the threaded irq handler. Some of the handling (such as dma related stuffs) done within the irq handler might sleep or take some time leading to issues if the kernel is built with realtime constraints. In order to fix that, perform an overall rework to perform most of the job within the threaded handler and only keep fifo access in the non threaded handler. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Alain Volmat authored
Convert error handling upon calls of devm_request_irq functions during the probe of the driver. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Paul Menzel authored
On the Dell XPS 15 7590/0VYV0G, BIOS 1.24.0 09/11/2023, Linux prints the warning below. i801_smbus 0000:00:1f.4: Accelerometer lis3lv02d is present on SMBus but its address is unknown, skipping registration Following the same suggestions by Wolfram Sang as for the Dell Precision 3540 [1], the accelerometer can be successfully found on I2C bus 2 at address 0x29. $ echo lis3lv02d 0x29 | sudo tee /sys/bus/i2c/devices/i2c-2/new_device lis3lv02d 0x29 $ dmesg | tail -5 [ 549.522876] lis3lv02d_i2c 2-0029: supply Vdd not found, using dummy regulator [ 549.522904] lis3lv02d_i2c 2-0029: supply Vdd_IO not found, using dummy regulator [ 549.542486] lis3lv02d: 8 bits 3DC sensor found [ 549.630022] input: ST LIS3LV02DL Accelerometer as /devices/platform/lis3lv02d/input/input35 [ 549.630586] i2c i2c-2: new_device: Instantiated device lis3lv02d at 0x29 So, the device has that accelerometer. Add the I2C address to the mapping list, and test it successfully on the device. [1]: https://lore.kernel.org/linux-i2c/97708c11-ac85-fb62-2c8e-d37739ca826f@molgen.mpg.de/Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Acked-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Paul Menzel authored
On the Dell Precision 3540/0M14W7, BIOS 1.7.4 05/12/2020, Linux prints the warning below. i801_smbus 0000:00:1f.4: Accelerometer lis3lv02d is present on SMBus but its address is unknown, skipping registration With the help of Wolfram Sang, the test to probe it on I2C bus 6 at address 0x29 was successful. $ echo lis3lv02d 0x29 | sudo tee /sys/bus/i2c/devices/i2c-6/new_device [ 2110.787000] i2c i2c-6: new_device: Instantiated device lis3lv02d at 0x29 [ 2110.791932] lis3lv02d_i2c 6-0029: supply Vdd not found, using dummy regulator [ 2110.791981] lis3lv02d_i2c 6-0029: supply Vdd_IO not found, using dummy regulator [ 2110.809233] lis3lv02d: 8 bits 3DC sensor found [ 2110.900668] input: ST LIS3LV02DL Accelerometer as /devices/platform/lis3lv02d/input/input23 So, the device has that accelerometer. Add the I2C address to the mapping list. Link: https://lore.kernel.org/linux-i2c/97708c11-ac85-fb62-2c8e-d37739ca826f@molgen.mpg.de/Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Acked-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> [wsa: shortened commit message a little] Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Hans Hu authored
These Settings for the same register, REG_CR, can be put together to reduce code redundancy. Signed-off-by: Hans Hu <hanshu-oc@zhaoxin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Hans Hu authored
Use more appropriate parameter passing to reduce the amount of code Signed-off-by: Hans Hu <hanshu-oc@zhaoxin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Hans Hu authored
The frequency setting mode is adjusted to reduce the code redundancy, and it is also convenient to share with zhaoxin Signed-off-by: Hans Hu <hanshu-oc@zhaoxin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Hans Hu authored
Put the handling of interrupt events in a function class to reduce code redundancy. Signed-off-by: Hans Hu <hanshu-oc@zhaoxin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Hans Hu authored
Put wmt_i2c_wait_bus_not_busy() in a more appropriate place to reduce code redundancy Signed-off-by: Hans Hu <hanshu-oc@zhaoxin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
Legacy class-based device auto-detection shouldn't be used in new code. Therefore remove support in i2c-mux-reg as long as we don't have a user of this feature yet. Link: https://lore.kernel.org/linux-i2c/a22978a4-88e4-46f4-b71c-032b22321599@gmail.com/Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Greg Kroah-Hartman authored
Now that the driver core can properly handle constant struct bus_type, move the i2c_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Note, the sound/soc/rockchip/rk3399_gru_sound.c also needed tweaking as it decided to save off a pointer to a bus type for internal stuff, and it was using the i2c_bus_type as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Philipp Zabel authored
Add compatible for ROHM Semiconductor BR24G04 EEPROMs. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Roland Hieber <rhi@pengutronix.de> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
Bartosz Golaszewski authored
This driver does not depend on CONFIG_OF so using of_match_ptr() makes sense to reduce the size a bit. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
Christophe Leroy authored
sparse reports an error on some data that gets converted from be32. That's because that data is typed u32 instead of __be32. The type is correct, the be32_to_cpu() conversion is not. Remove the conversion. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312042210.QL4DA8Av-lkp@intel.com/Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-By: Jochen Friedrich <jochen@scram.de> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Alexander Stein authored
Both i2c_generic_scl_recovery() and the debug output indicate that SDA is purely optional for bus recovery. But devm_gpiod_get() never returns NULL making it mandatory. Fix this by calling devm_gpiod_get_optional instead. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Jean Delvare authored
I originally restricted i2c_register_spd() to only support systems with up to 4 memory slots, so that we can experiment with it on a limited numbers of systems. It's been more than 3 years and it seems to work just fine, so the time has come to lift this arbitrary limitation. The maximum number of memory slots which can be connected to a single I2C segment is 8, so support that many SPD EEPROMs. Any system with more than 8 memory slots would have either multiple SMBus channels or SMBus multiplexing, so it would need dedicated care. We'll get to that later as needed. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Tim Lunn authored
Rockchip RV1126 is using old style i2c controller, the i2c2 bus uses a non-sequential offset in the grf register for the mask/value bits for this bus. This patch fixes i2c2 bus on rv1126 SoCs. Signed-off-by: Tim Lunn <tim@feathertop.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Marek Szyprowski authored
Add support for atomic transfers using polling mode with interrupts intentionally disabled to get rid of the following warning introduced by commit 63b96983 ("i2c: core: introduce callbacks for atomic transfers") during system reboot and power-off: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1518 at drivers/i2c/i2c-core.h:40 i2c_transfer+0xe8/0xf4 No atomic I2C transfer handler for 'i2c-0' ... ---[ end trace 0000000000000000 ]--- Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chanho Park <chanho61.park@samsung.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Marek Szyprowski authored
To properly handle ACK on the bus when transferring more than one message in polling mode, move the polling handling loop from s3c24xx_i2c_message_start() to s3c24xx_i2c_doxfer(). This way i2c_s3c_irq_nextbyte() is always executed till the end, properly acknowledging the IRQ bits and no recursive calls to i2c_s3c_irq_nextbyte() are made. While touching this, also fix finishing transfers in polling mode by using common code path and always waiting for the bus to become idle and disabled. Fixes: 117053f7 ("i2c: s3c2410: Add polling mode support") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Marek Szyprowski authored
To properly handle read transfers in polling mode, no waiting for the ACK state is needed as it will never come. Just wait a bit to ensure start state is on the bus and continue processing next bytes. Fixes: 117053f7 ("i2c: s3c2410: Add polling mode support") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Chanho Park <chanho61.park@samsung.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Wolfram Sang authored
To support FM+, we mainly need to turn the SMD constant into a parameter and set it accordingly. That also means we can finally fix SMD to our needs instead of bailing out. A sanity check for SMD then becomes a sanity check for 'x == 0'. After all that, activating the enable bit for FM+ is all we need to do. Tested with a Renesas Falcon board using R-Car V3U. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Wolfram Sang authored
So far, we treated Gen4 as Gen3. But we are soon adding FM+ as a Gen4 specific feature, so prepare the code for the new devtype. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Wolfram Sang authored
The I2C core now provides a per-adapter debugfs directory. Use it instead of creating a custom one. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Tali Perry <tali.perry1@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Wolfram Sang authored
The I2C core now provides a per-adapter debugfs directory. Use it instead of creating a custom one. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Wolfram Sang authored
Two drivers already implement custom debugfs handling for their i2c_adapter and more will come. So, let the core create a debugfs directory per adapter and pass that to drivers for their debugfs files. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
staging: greybus: Don't let i2c adapters declare I2C_CLASS_SPD support if they support I2C_CLASS_HWMON After removal of the legacy eeprom driver the only remaining I2C client device driver supporting I2C_CLASS_SPD is jc42. Because this driver also supports I2C_CLASS_HWMON, adapters don't have to declare support for I2C_CLASS_SPD if they support I2C_CLASS_HWMON. It's one step towards getting rid of I2C_CLASS_SPD mid-term. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
media: netup_unidvb: Don't let i2c adapters declare I2C_CLASS_SPD support if they support I2C_CLASS_HWMON After removal of the legacy eeprom driver the only remaining I2C client device driver supporting I2C_CLASS_SPD is jc42. Because this driver also supports I2C_CLASS_HWMON, adapters don't have to declare support for I2C_CLASS_SPD if they support I2C_CLASS_HWMON. It's one step towards getting rid of I2C_CLASS_SPD mid-term. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
After removal of the legacy eeprom driver the only remaining I2C client device driver supporting I2C_CLASS_SPD is jc42. Because this driver also supports I2C_CLASS_HWMON, adapters don't have to declare support for I2C_CLASS_SPD if they support I2C_CLASS_HWMON. It's one step towards getting rid of I2C_CLASS_SPD mid-term. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
After removal of the legacy eeprom driver the only remaining I2C client device driver supporting I2C_CLASS_SPD is jc42. Because this driver also supports I2C_CLASS_HWMON, adapters don't have to declare support for I2C_CLASS_SPD if they support I2C_CLASS_HWMON. It's one step towards getting rid of I2C_CLASS_SPD mid-term. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Andi Shyti <andi.shyti@kernel.org> Acked-by: Jim Cromie <jim.cromie@gmail.com> # for SCX Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
I2C_CLASS_SPD was used to expose the EEPROM content to user space, via the legacy eeprom driver. Now that this driver has been removed, we can remove I2C_CLASS_SPD support. at24 driver with explicit instantiation should be used instead. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. Class-based device auto-detection is a legacy mechanism and shouldn't be used in new code. So we can remove this class completely now. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. Class-based device auto-detection is a legacy mechanism and shouldn't be used in new code. So we can remove this class completely now. Acked-by: Helge Deller <deller@gmx.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
Heiner Kallweit authored
After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. Class-based device auto-detection is a legacy mechanism and shouldn't be used in new code. So we can remove this class completely now. Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
-
- 27 Nov, 2023 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-traceLinus Torvalds authored
Pull tracing fixes from Steven Rostedt:: "Eventfs fixes: - With the usage of simple_recursive_remove() recommended by Al Viro, the code should not be calling "d_invalidate()" itself. Doing so is causing crashes. The code was calling d_invalidate() on the race of trying to look up a file while the parent was being deleted. This was detected, and the added dentry was having d_invalidate() called on it, but the deletion of the directory was also calling d_invalidate() on that same dentry. - A fix to not free the eventfs_inode (ei) until the last dput() was called on its ei->dentry made the ei->dentry exist even after it was marked for free by setting the ei->is_freed. But code elsewhere still was checking if ei->dentry was NULL if ei->is_freed is set and would trigger WARN_ON if that was the case. That's no longer true and there should not be any warnings when it is true. - Use GFP_NOFS for allocations done under eventfs_mutex. The eventfs_mutex can be taken on file system reclaim, make sure that allocations done under that mutex do not trigger file system reclaim. - Clean up code by moving the taking of inode_lock out of the helper functions and into where they are needed, and not use the parameter to know to take it or not. It must always be held but some callers of the helper function have it taken when they were called. - Warn if the inode_lock is not held in the helper functions. - Warn if eventfs_start_creating() is called without a parent. As eventfs is underneath tracefs, all files created will have a parent (the top one will have a tracefs parent). Tracing update: - Add Mathieu Desnoyers as an official reviewer of the tracing subsystem" * tag 'trace-v6.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: MAINTAINERS: TRACING: Add Mathieu Desnoyers as Reviewer eventfs: Make sure that parent->d_inode is locked in creating files/dirs eventfs: Do not allow NULL parent to eventfs_start_creating() eventfs: Move taking of inode_lock into dcache_dir_open_wrapper() eventfs: Use GFP_NOFS for allocation when eventfs_mutex is held eventfs: Do not invalidate dentry in create_file/dir_dentry() eventfs: Remove expectation that ei->is_freed means ei->dentry == NULL
-