- Oct 27, 2021
-
-
Tooniis authoredTUSB320L is a newer chip with additional features, and it has additional steps in its mode changing sequence: - Disable CC state machine, - Write to mode register, - Wait for 5 ms, - Re-enable CC state machine. It also has an additional register that a revision number can be read from. Add support for the mode changing sequence, and read the revision number during probe and print it as info. Signed-off-by:
Yassine Oudjana <y.oudjana@protonmail.com> Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com>
-
Tooniis authored
Reset the chip and set its mode to default (maintain mode set by PORT pin) during probe to make sure it comes up in the default state. Signed-off-by:
-
Fabio Aiuto authored
use low level P-Unit semaphore lock for axp288 register accesses directly and for more than one access a time, to reduce the number of times this semaphore is locked and released which is an expensive operation. i2c-bus to the XPower is shared between the kernel and the SoCs P-Unit. The P-Unit has a semaphore wich the kernel must lock for axp288 register accesses. When the P-Unit semaphore is locked CPU and GPU power states cannot change or the system will freeze. The P-Unit semaphore lock is already managed inside the regmap access logic, but for each access the semaphore is locked and released. So use directly iosf_mbi_(un)block_punit_i2c_access(), we are safe in doing so because nested calls to the same semaphore are turned to nops. Suggested-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Fabio Aiuto <fabioaiuto83@gmail.com> Signed-off-by:
-
Linus Walleij authoredThis driver includes the legacy <linux/gpio.h> header but does not use it. Drop this include. Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
The USB GPIO extcon driver does not use any of the legacy includes <linux/gpio.h> or <linux/of_gpio.h> but exploits the fact that this brings in <linux/mod_device_table.h>. Fix this up by using the right includes. Signed-off-by:
-
- Jun 21, 2021
-
-
Stephan Gerhold authored
SM5504 is another MUIC from Silicon Mitus that is fairly similar to SM5502. They seem to use the same register set, but: - SM5504 has some additional bits in SM5502_REG_CONTROL - SM5504 has a quite different set of interrupts - SM5504 reports USB OTG as dev_type1 = BIT(0) instead of BIT(7) Overall it's minor and we can support this by defining a separate struct sm5502_type for SM5504. Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
-
Stephan Gerhold authored
Prepare for supporting SM5504 in the extcon-sm5502 driver by replacing enum sm5504_types with a struct sm5504_type that stores the chip-specific definitions. This struct can then be defined separately for SM5504 without having to add if (type == TYPE_SM5504) everywhere in the code. Signed-off-by:
-
Stephan Gerhold authored
sm5022_muic_i2c_probe() does not use the i2c_device_id, so implement i2c_driver->probe_new() instead of probe(). Signed-off-by:
-
Stephan Gerhold authored
Use devm_regmap_add_irq_chip() to avoid having to remove the irqchip explicitly in sm5502_muic_i2c_remove(). Signed-off-by:
-
Marek Szyprowski authored
The platform device driver name is "max8997-muic", so advertise it properly in the modalias string. This fixes automated module loading when this driver is compiled as a module. Fixes: b76668ba ("Extcon: add MAX8997 extcon driver") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Stephan Gerhold authored
When sm5502_init_dev_type() iterates over sm5502_reg_data to initialize the registers it is limited by ARRAY_SIZE(sm5502_reg_data). There is no need to add another empty element to sm5502_reg_data. Having the additional empty element in sm5502_reg_data will just result in writing 0xff to register 0x00, which does not really make sense. Fixes: 914b881f ("extcon: sm5502: Add support new SM5502 extcon device driver") Signed-off-by:
-
Ferry Toth authored
extcon driver for Basin Cove PMIC shadows the switch status used for dwc3 DRD to detect a change in the switch position. This change initializes the status at probe time. Cc: stable@vger.kernel.org Fixes: 492929c5 ("extcon: mrfld: Introduce extcon driver for Basin Cove PMIC") Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Ferry Toth <ftoth@exalondelft.nl> Signed-off-by:
-
- Jun 17, 2021
-
-
Matti Vaittinen authored
Simplify driver by switching to use the resource managed IRQ requesting and resource managed work-queue initialization. Signed-off-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by:
-
Matti Vaittinen authored
If reading MAX8997_MUIC_REG_STATUS1 fails at probe the driver exits without freeing the requested IRQs. Free the IRQs prior returning if reading the status fails. Fixes: 3e34c819 ("extcon: max8997: Avoid forcing UART path on drive probe") Signed-off-by:
-
Matti Vaittinen authored
The extcon IRQ schedules a work item. IRQ is requested using devm while WQ is cancelld at remove(). This mixing of devm and manual unwinding has potential case where the WQ has been emptied (.remove() was ran) but devm unwinding of IRQ was not yet done. It may be possible the IRQ is triggered at this point scheduling new work item to the already flushed queue. According to the input documentation the input device allocated by devm_input_allocate_device() does not need to be explicitly unregistered. Use the new devm_work_autocancel() and remove the remove() to simplify the code. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by:
-
Matti Vaittinen authored
The extcon IRQ schedules a work item. IRQ is requested using devm while WQ is cancelld at remove(). This mixing of devm and manual unwinding has potential case where the WQ has been emptied (.remove() was ran) but devm unwinding of IRQ was not yet done. It is possible the IRQ is triggered at this point scheduling new work item to the already flushed queue. Use new devm_work_autocancel() to remove the remove() and to kill the bug. Signed-off-by:
-
- Apr 08, 2021
-
-
Anirudh Ghayal authored
VBUS can be detected via a dedicated PMIC pin. Add support for reporting the VBUS status. Signed-off-by:
Anirudh Ghayal <aghayal@codeaurora.org> Signed-off-by:
Kavya Nunna <knunna@codeaurora.org> Signed-off-by:
Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by:
-
Nikita Travkin authored
In it's curent state this driver ignores OTG adapters with ID pin connected to ground. This commit adds a check to set extcon into host mode when such OTG adapter is connected. Signed-off-by:
Nikita Travkin <nikitos.tr@gmail.com> Signed-off-by:
-
Timon Baetz authored
This allows the MAX8997 charger to set the current limit depending on the detected extcon charger type. Signed-off-by:
Timon Baetz <timon.baetz@protonmail.com> Signed-off-by:
-
- Mar 23, 2021
-
-
Matti Vaittinen authored
Few drivers implement remove call-back only for ensuring a delayed work gets cancelled prior driver removal. Clean-up these by switching to use devm_delayed_work_autocancel() instead. Additionally, this helps avoiding mixing devm and manual resource management and cleans up a (theoretical?) bug from extconn-palmas.c and extcon-qcom-spmi-misc.c where (devm managed)IRQ might schedule new work item after wq was cleaned at remove(). This change is compile-tested only. All testing is appreciated. Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Mar 18, 2021
-
-
Hans de Goede authored
The jack handling for arizona codecs is being refactored so that it is done directly by the codec drivers, instead of having an extcon-driver bind to a separate "arizona-extcon" child-device for this. drivers/mfd/arizona-core.c has already been updated to no longer instantiate an "arizona-extcon" child-device for the arizona codecs. This means that the "arizona-extcon" driver is no longer useful (there are no longer any devices for it to bind to). This commit drops the extcon Kconfig / Makefile bits and moves drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c . This is a preparation patch for converting the arizona extcon-driver into a helper library for letting the arizona codec-drivers directly report jack state through the standard sound/soc/soc-jack.c functions. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Tested-by:
Lee Jones <lee.jones@linaro.org>
-
Hans de Goede authored
Before this commit the extcon-arizona code was mixing pm_runtime_get() and pm_runtime_get_sync() in different places. In all places where pm_runtime_get[_sync]() is called, the code makes use of the device immediately after the call. This means that we should always use pm_runtime_get_sync(). Signed-off-by:
-
Hans de Goede authored
The initial value of the GPIO should match the info->micd_modes[0].gpio value. arizona_extcon_probe() already stores the necessary flag in a mode variable, but instead of passing mode as flags to the gpiod_get() it was using a hardcoded GPIOD_OUT_LOW. Signed-off-by:
-
Hans de Goede authored
We must free/disable all interrupts and cancel all pending works before doing further cleanup. Before this commit arizona_extcon_remove() was doing several register writes to shut things down before disabling the IRQs and it was cancelling only 1 of the 3 different works used. Move all the register-writes shutting things down to after the disabling of the IRQs and add the 2 missing cancel_delayed_work_sync() calls. This fixes various possible races on driver unbind. One of which would always trigger on devices using the mic-clamp feature for jack detection. The ARIZONA_MICD_CLAMP_MODE_MASK update was done before disabling the IRQs, causing: 1. arizona_jackdet() to run 2. detect a jack being inserted (clamp disabled means jack inserted) 3. call arizona_start_mic() which: 3.1 Enables the MICVDD regulator 3.2 takes a pm_runtime_reference And this was all happening after the ARIZONA_MICD_ENA bit clearing, which would undo 3.1 and 3.2 because the ARIZONA_MICD_CLAMP_MODE_MASK update was being done after the ARIZONA_MICD_ENA bit clearing. So this means that arizona_extcon_remove() would exit with 1. MICVDD enabled and 2. The pm_runtime_reference being unbalanced. MICVDD still being enabled caused the following oops when the regulator is released by the devm framework: [ 2850.745757] ------------[ cut here ]------------ [ 2850.745827] WARNING: CPU: 2 PID: 2098 at drivers/regulator/core.c:2123 _regulator_put.part.0+0x19f/0x1b0 [ 2850.745835] Modules linked in: extcon_arizona ... ... [ 2850.746909] Call Trace: [ 2850.746932] regulator_put+0x2d/0x40 [ 2850.746946] release_nodes+0x22a/0x260 [ 2850.746984] __device_release_driver+0x190/0x240 [ 2850.747002] driver_detach+0xd4/0x120 ... [ 2850.747337] ---[ end trace f455dfd7abd9781f ]--- Note this oops is just one of various theoretically possible races caused by the wrong ordering inside arizona_extcon_remove(), this fixes the ordering fixing all possible races, including the reported oops. Signed-off-by:
-
Hans de Goede authored
When the jack is partially inserted and then removed again it may be removed while the hpdet code is running. In this case the following may happen: 1. The "JACKDET rise" or ""JACKDET fall" IRQ triggers 2. arizona_jackdet runs and takes info->lock 3. The "HPDET" IRQ triggers 4. arizona_hpdet_irq runs, blocks on info->lock 5. arizona_jackdet calls arizona_stop_mic() and clears info->hpdet_done 6. arizona_jackdet releases info->lock 7. arizona_hpdet_irq now can continue running and: 7.1 Calls arizona_start_mic() (if a mic was detected) 7.2 sets info->hpdet_done Step 7 is undesirable / a bug: 7.1 causes the device to stay in a high power-state (with MICVDD enabled) 7.2 causes hpdet to not run on the next jack insertion, which in turn causes the EXTCON_JACK_HEADPHONE state to never get set This fixes both issues by skipping these 2 steps when arizona_hpdet_irq runs after the jack has been unplugged. Signed-off-by:
-
- Mar 15, 2021
-
-
Dinghao Liu authored
When devm_kcalloc() fails, we should execute device_unregister() to unregister edev->dev from system. Fixes: 046050f6 ("extcon: Update the prototype of extcon_register_notifier() with enum extcon") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by:
-
- Dec 11, 2020
-
-
Marek Szyprowski authored
The platform device driver name is "max77693-muic", so advertise it properly in the modalias string. This fixes automated module loading when this driver is compiled as a module. Fixes: db1b9037 ("extcon: MAX77693: Add extcon-max77693 driver to support Maxim MAX77693 MUIC device") Signed-off-by:
-
Linus Walleij authored
The Texas Instruments TSU6111 is compatible to the FSA880/FSA9480. Signed-off-by:
-
Michael Auchter authored
This patch adds an extcon driver for the TI TUSB320 USB Type-C device. This can be used to detect whether the port is configured as a downstream or upstream facing port. Signed-off-by:
Michael Auchter <michael.auchter@ni.com> Signed-off-by:
-
- Sep 29, 2020
-
-
Liu Shixin authored
module_platform_driver() makes the code simpler by eliminating boilerplate code. Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Reviewed-by:
-
Krzysztof Kozlowski authored
The commit 85256f61 ("extcon: ptn5150: Check current USB mode when probing") reused code for checking CC status register in the probe path to determine what is initially connected. However if nothing is connected, the CC status register will have 0x0 value and print an error message: ptn5150 1-003d: Unknown Port status : 0 This is not an error. Also any other unknown port status values are not really errors but unhandled cases. Fixes: 85256f61 ("extcon: ptn5150: Check current USB mode when probing") Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
- Sep 24, 2020
-
-
Krzysztof Kozlowski authored
The register addresses are not continuous, so use simple defines for them. This also makes it easier to find the address for register. No functional change. Signed-off-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and the error value gets printed. Signed-off-by:
-
Krzysztof Kozlowski authored
devm_extcon_dev_allocate() can fail of multiple reasons. The call returns proper error code on failure so pass it instead of fixed ENOMEM. Signed-off-by:
-
Krzysztof Kozlowski authored
devm_extcon_dev_allocate() can fail of multiple reasons. The call returns proper error code on failure so pass it instead of fixed ENOMEM. Signed-off-by:
-
Krzysztof Kozlowski authored
devm_extcon_dev_allocate() can fail of multiple reasons. The call returns proper error code on failure so pass it instead of fixed ENOMEM. Signed-off-by:
-
Krzysztof Kozlowski authored
devm_extcon_dev_allocate() can fail of multiple reasons. The call returns proper error code on failure so pass it instead of fixed ENOMEM. Signed-off-by:
-
Ramuthevar Vadivel Murugan authored
Set the capability value of property for VBUS and POLARITY. Signed-off-by:
Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> [cw00.choi: Replace the space with tab for the indentation] Signed-off-by:
-
Ramuthevar Vadivel Murugan authored
Switch to GENMASK() and BIT() macros. Signed-off-by:
-
Andy Shevchenko authored
dev_err_probe() is designed to be used like return dev_err_probe(dev, ret, "Error message\n"); Hence no need to have a separate return statement. Besides that dev_err_probe() prints already returned error code, no need to repeat that either. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
