#
e190a0c3 |
|
08-May-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
i2c: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Alain Volmat <alain.volmat@foss.st.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Jochen Friedrich <jochen@scram.de> Acked-by: Peter Rosin <peda@axentia.se> Acked-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Asmaa Mnebhi <asnaa@nvidia.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Chris Pringle <chris.pringle@phabrix.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Tali Perry <tali.perry@nuvoton.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
#
0e61637f |
|
26-Jan-2023 |
Hans de Goede <hdegoede@redhat.com> |
i2c: cht-wc: Add charger-chip info for the Lenovo Yoga Tab 3 YT3-X90F On x86 devices with a CHT Whiskey Cove PMIC the driver for the I2C bus coming from the PMIC is responsible for instantiating the i2c_client for the charger chip. Add the necessary i2c_board_info for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230126153823.22146-3-hdegoede@redhat.com
|
#
ea1558ce |
|
11-Aug-2022 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
i2c: move drivers from strlcpy to strscpy Follow the advice of the below link and prefer 'strscpy'. Conversion is easy because no driver used the return value and has been done with a simple sed invocation. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
#
a5ea3257 |
|
11-Feb-2022 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
i2c: cht-wc: Use generic_handle_irq_safe(). Instead of manually disabling interrupts before invoking use generic_handle_irq_safe() which can be invoked with enabled and disabled interrupts. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
#
4b326491 |
|
01-Feb-2022 |
Hans de Goede <hdegoede@redhat.com> |
i2c: cht-wc: Make charger i2c-client instantiation board/device-model specific The i2c-controller on the Cherry Trail - Whiskey Cove PMIC is special in that it is always connected to the I2C charger IC of the board on which the PMIC is used; and the charger IC is not described in ACPI, so the i2c-cht-wc code needs to instantiate an i2c-client for it itself. So far this was hardcoded to instantiate an i2c-client for the bq24292i, with all properties, etc. set to match how this charger is used on the GPD win and GPD pocket devices. There is a rudimentary check to make sure the ACPI tables are at least somewhat as expected, but this is far from accurate, leading to a wrong i2c-client being instantiated for the charger on some boards. Switch to the new DMI based intel_cht_wc_get_model() helper which is exported by the MFD driver for the CHT Whiskey Cove PMIC to help PMIC cell drivers like the i2c-cht-wc code reliably detect which board they are running on. And add board_info for the charger ICs as found on the other 2 known boards with a Whisky Cove PMIC. This has been tested on all 3 known boards. Acked-by: Wolfram Sang <wsa@kernel.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
#
e11654ec |
|
09-Jun-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
i2c: cht-wc: Replace of_node by NULL The driver is run on the platforms where OF node is always NULL. The confusion comes from IRQ domain APIs that take either OF or firmware node as input parameter. Since fwnode is not used here either, replace of_node by NULL. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
#
f9c3d273 |
|
29-Mar-2021 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
i2c: cht-wc: Constify the software node Additional device properties are always just a part of a software fwnode. If the device properties are constant, the software node can also be constant. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
#
e42688ed |
|
16-Apr-2020 |
Dejin Zheng <zhengdejin5@gmail.com> |
i2c: busses: remove duplicate dev_err() it will print an error message by itself when platform_get_irq() goes wrong. so don't need dev_err() in here again. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Suggested-by: Markus Elfring <Markus.Elfring@web.de> Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
6b5794ab |
|
07-Jan-2020 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
i2c: cht-wc: convert to use i2c_new_client_device() Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
539b7569 |
|
20-Aug-2019 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
i2c: cht-wc: drop check because i2c_unregister_device() is NULL safe No need to check the argument of i2c_unregister_device() because the function itself does it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
232219b9 |
|
12-Aug-2019 |
Hans de Goede <hdegoede@redhat.com> |
i2c-cht-wc: Fix lockdep warning When the kernel is build with lockdep support and the i2c-cht-wc driver is used, the following warning is shown: [ 66.674334] ====================================================== [ 66.674337] WARNING: possible circular locking dependency detected [ 66.674340] 5.3.0-rc4+ #83 Not tainted [ 66.674342] ------------------------------------------------------ [ 66.674345] systemd-udevd/1232 is trying to acquire lock: [ 66.674349] 00000000a74dab07 (intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock){+.+.}, at: regmap_write+0x31/0x70 [ 66.674360] but task is already holding lock: [ 66.674362] 00000000d44a85b7 (i2c_register_adapter){+.+.}, at: i2c_smbus_xfer+0x49/0xf0 [ 66.674370] which lock already depends on the new lock. [ 66.674371] the existing dependency chain (in reverse order) is: [ 66.674374] -> #1 (i2c_register_adapter){+.+.}: [ 66.674381] rt_mutex_lock_nested+0x46/0x60 [ 66.674384] i2c_smbus_xfer+0x49/0xf0 [ 66.674387] i2c_smbus_read_byte_data+0x45/0x70 [ 66.674391] cht_wc_byte_reg_read+0x35/0x50 [ 66.674394] _regmap_read+0x63/0x1a0 [ 66.674396] _regmap_update_bits+0xa8/0xe0 [ 66.674399] regmap_update_bits_base+0x63/0xa0 [ 66.674403] regmap_irq_update_bits.isra.0+0x3b/0x50 [ 66.674406] regmap_add_irq_chip+0x592/0x7a0 [ 66.674409] devm_regmap_add_irq_chip+0x89/0xed [ 66.674412] cht_wc_probe+0x102/0x158 [ 66.674415] i2c_device_probe+0x95/0x250 [ 66.674419] really_probe+0xf3/0x380 [ 66.674422] driver_probe_device+0x59/0xd0 [ 66.674425] device_driver_attach+0x53/0x60 [ 66.674428] __driver_attach+0x92/0x150 [ 66.674431] bus_for_each_dev+0x7d/0xc0 [ 66.674434] bus_add_driver+0x14d/0x1f0 [ 66.674437] driver_register+0x6d/0xb0 [ 66.674440] i2c_register_driver+0x45/0x80 [ 66.674445] do_one_initcall+0x60/0x2f4 [ 66.674450] kernel_init_freeable+0x20d/0x2b4 [ 66.674453] kernel_init+0xa/0x10c [ 66.674457] ret_from_fork+0x3a/0x50 [ 66.674459] -> #0 (intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock){+.+.}: [ 66.674465] __lock_acquire+0xe07/0x1930 [ 66.674468] lock_acquire+0x9d/0x1a0 [ 66.674472] __mutex_lock+0xa8/0x9a0 [ 66.674474] regmap_write+0x31/0x70 [ 66.674480] cht_wc_i2c_adap_smbus_xfer+0x72/0x240 [i2c_cht_wc] [ 66.674483] __i2c_smbus_xfer+0x1a3/0x640 [ 66.674486] i2c_smbus_xfer+0x67/0xf0 [ 66.674489] i2c_smbus_read_byte_data+0x45/0x70 [ 66.674494] bq24190_probe+0x26b/0x410 [bq24190_charger] [ 66.674497] i2c_device_probe+0x189/0x250 [ 66.674500] really_probe+0xf3/0x380 [ 66.674503] driver_probe_device+0x59/0xd0 [ 66.674506] device_driver_attach+0x53/0x60 [ 66.674509] __driver_attach+0x92/0x150 [ 66.674512] bus_for_each_dev+0x7d/0xc0 [ 66.674515] bus_add_driver+0x14d/0x1f0 [ 66.674518] driver_register+0x6d/0xb0 [ 66.674521] i2c_register_driver+0x45/0x80 [ 66.674524] do_one_initcall+0x60/0x2f4 [ 66.674528] do_init_module+0x5c/0x230 [ 66.674531] load_module+0x2707/0x2a20 [ 66.674534] __do_sys_init_module+0x188/0x1b0 [ 66.674537] do_syscall_64+0x5c/0xb0 [ 66.674541] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 66.674543] other info that might help us debug this: [ 66.674545] Possible unsafe locking scenario: [ 66.674547] CPU0 CPU1 [ 66.674548] ---- ---- [ 66.674550] lock(i2c_register_adapter); [ 66.674553] lock(intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock); [ 66.674556] lock(i2c_register_adapter); [ 66.674559] lock(intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock); [ 66.674561] *** DEADLOCK *** The problem is that the CHT Whiskey Cove PMIC's builtin i2c-adapter is itself a part of an i2c-client (the PMIC). This means that transfers done through it take adapter->bus_lock twice, once for the parent i2c-adapter and once for its own bus_lock. Lockdep does not like this nested locking. To make lockdep happy in the case of busses with muxes, the i2c-core's i2c_adapter_lock_bus function calls: rt_mutex_lock_nested(&adapter->bus_lock, i2c_adapter_depth(adapter)); But i2c_adapter_depth only works when the direct parent of the adapter is another adapter, as it is only meant for muxes. In this case there is an i2c-client and MFD instantiated platform_device in the parent->child chain between the 2 devices. This commit overrides the default i2c_lock_operations, passing a hardcoded depth of 1 to rt_mutex_lock_nested, making lockdep happy. Note that if there were to be a mux attached to the i2c-wc-cht adapter, this would break things again since the i2c-mux code expects the root-adapter to have a locking depth of 0. But the i2c-wc-cht adapter always has only 1 client directly attached in the form of the charger IC paired with the CHT Whiskey Cove PMIC. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
e9483576 |
|
23-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 143 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190524100844.561472061@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b3a65328 |
|
01-Jul-2018 |
Hans de Goede <hdegoede@redhat.com> |
i2c-cht-wc: Fix bq24190 supplier Commit f2a8aa053c17 ("typec: tcpm: Represent source supply through power_supply") moved the code to register a power_supply representing the device supplying power to the type-C connector, from the fusb302 code to the generic tcpm code. This has caused the power-supply registered by the fusb302 driver, which determines how much current the bq24190 can draw, to change name from "fusb302-typec-source" to "tcpm-source-psy-i2c-fusb302". Fixes: f2a8aa053c17 ("typec: tcpm: Represent source supply through...") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
04271ce9 |
|
28-Nov-2017 |
Arvind Yadav <arvind.yadav.cs@gmail.com> |
i2c-cht-wc: constify platform_device_id platform_device_id are not supposed to change at runtime. All functions working with platform_device_id provided by <linux/platform_device.h> work with const platform_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
0224d45c |
|
11-Oct-2017 |
Hans de Goede <hdegoede@redhat.com> |
i2c-cht-wc: Add device-properties for fusb302 integration Add device-properties to make the bq24292i charger connected to the bus get its input-current-limit from the fusb302 Type-C port controller which is used on boards with the cht-wc PMIC, as well as regulator_init_data for the 5V boost converter on the bq24292i. Since this means we now hook-up the bq24292i to the fusb302 Type-C port controller add a check for the ACPI device which instantiates the fusb302. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
5ca21c13 |
|
16-Aug-2017 |
Colin Ian King <colin.king@canonical.com> |
i2c-cht-wc: make cht_wc_i2c_adap_driver static The structure cht_wc_i2c_adap_driver is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: symbol 'cht_wc_i2c_adap_driver' was not declared. Should it be static? Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
ed109401 |
|
14-Aug-2017 |
Hans de Goede <hdegoede@redhat.com> |
i2c-cht-wc: Workaround CHT GPIO controller IRQ issues The Cherry Trail Whiskey Cove PMIC's IRQ line is attached to one of the GPIOs of the Cherry Trail SoC. The CHT GPIO controller sometimes fails to deliver IRQs (seen when there is an IRQ storm on another pin). This commit works around this by reducing the long timeout which was a poor attempt to workaround this from 3s to 30ms and after that manually checking the status register for transfer completion by calling the threaded IRQ handler directly. This is safe todo as the entire threaded IRQ handler is protected by a mutex. Note 30ms should be more then long enough, at 100KHz any smbus single byte transaction should be finished in 4ms. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
8de60c63 |
|
14-Aug-2017 |
Hans de Goede <hdegoede@redhat.com> |
i2c-cht-wc: Ack read irqs after reading the data register Testing has shown that writing 1 to clear the read-complete irq does not work until the data register has been read first. This commit fixes the driver to read the data register first, halving the amount of interrupts in most cases since we mostly read on this i2c bus. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
a5a46bd0 |
|
14-Aug-2017 |
Hans de Goede <hdegoede@redhat.com> |
i2c-cht-wc: Add locking to interrupt / smbus_xfer functions Although unlikely without locking the smbux_xfer function may miss the nack flag and further fixes in this patch-set add some more complex constructions which need protection. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
17a924bf |
|
12-Aug-2017 |
Hans de Goede <hdegoede@redhat.com> |
i2c-cht-wc: Add Intel Cherry Trail Whiskey Cove SMBUS controller driver The Intel Cherry Trail Whiskey Cove PMIC does not contain a builtin battery charger, instead boards with this PMIC use an external TI bq24292i charger IC, which is connected to a SMBUS controller built into the PMIC. This commit adds an i2c-bus driver for the PMIC's builtin SMBUS controller. The probe function for this i2c-bus will also register an i2c-client for the TI bq24292i charger after the i2c-bus has been registered. Note that several device-properties are set on the client-device to tell the bq24190 power-supply driver to integrate the Whiskey Cove PMIC and e.g. use the PMIC's BC1.2 detection (through extcon) to determine the maximum input current. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|