- Aug 11, 2023
-
-
William Breathitt Gray authored
All idio-16 library consumers have migrated to the new interface leveraging the gpio-regmap API. Legacy interface functions and code are removed as no longer needed. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/651cff1cc3eb57b455a8048121cf6a4d4367f018.1680618405.git.william.gray@linaro.org/ Signed-off-by:
William Breathitt Gray <william.gray@linaro.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
William Breathitt Gray authored
The regmap API supports IO port accessors so we can take advantage of regmap abstractions rather than handling access to the device registers directly in the driver. Migrate the pci-idio-16 module to the new idio-16 library interface leveraging the gpio-regmap API. Suggested-by:
-
William Breathitt Gray authored
The regmap API supports IO port accessors so we can take advantage of regmap abstractions rather than handling access to the device registers directly in the driver. Migrate the 104-idio-16 module to the new idio-16 library interface leveraging the gpio-regmap API. Suggested-by:
-
William Breathitt Gray authored
The regmap API supports IO port accessors so we can take advantage of regmap abstractions rather than handling access to the device registers directly in the driver. By leveraging the regmap API, the idio-16 library is reduced to simply a devm_idio_16_regmap_register() function and a configuration structure struct idio_16_regmap_config. Legacy functions and code will be removed once all consumers have migrated to the new idio-16 library interface. For IDIO-16 devices we have the following IRQ registers: Base Address +1 (Write): Clear Interrupt Base Address +2 (Read): Enable Interrupt Base Address +2 (Write): Disable Interrupt An interrupt is asserted whenever a change-of-state is detected on any of the inputs. Any write to 0x2 will disable interrupts, while any read will enable interrupts. Interrupts are cleared by a write to 0x1. For 104-IDIO-16 devices, there is no IRQ status register, so software has to assume that if an interrupt is raised then it was for the 104-IDIO-16 device. For PCI-IDIO-16 devices, there is an additional IRQ register: Base Address +6 (Read): Interrupt Status Interrupt status can be read from 0x6 where bit 2 set indicates that an IRQ has been generated. Reviewed-by: -
Bartosz Golaszewski authored
When comparing strings passed to us from configfs, we can pass the page argument directly to sysfs_streq() and avoid manual string trimming. Signed-off-by:
-
- Aug 03, 2023
-
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use of_match_ptr() here, and __maybe_unused can also be removed. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Signed-off-by:
Zhu Wang <wangzhu9@huawei.com> Reviewed-by:
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use of_match_ptr() here, and __maybe_unused can also be removed. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Signed-off-by:
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use CONFIG_OF and of_match_ptr() here, we remove them all. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Signed-off-by:
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use CONFIG_OF and of_match_ptr() here, so we remove them all. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Signed-off-by:
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use of_match_ptr() here. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Hence we remove of_match_ptr(). Signed-off-by:
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use of_match_ptr() here. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Hence we remove of_match_ptr(). Signed-off-by:
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use of_match_ptr() here. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Hence we remove of_match_ptr(). Signed-off-by:
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use of_match_ptr() here. We remove both CONFIG_OF and of_match_ptr() here. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Signed-off-by:
-
Zhu Wang authored
The driver depends on CONFIG_OF, so it is not necessary to use of_match_ptr() here. Even for drivers that do not depend on CONFIG_OF, it's almost always better to leave out the of_match_ptr(), since the only thing it can possibly do is to save a few bytes of .text if a driver can be used both with and without it. Hence we remove of_match_ptr(). Signed-off-by:
-
Ruan Jinjie authored
Since commit a85a6c86 ("driver core: platform: Clarify that IRQ 0 is invalid"), there is no possible for platform_get_irq() to return 0. And the return value of platform_get_irq() is more sensible to show the error reason. Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
Alexandru Ardelean <alex@shruggie.ro> Signed-off-by:
Andrei Coardos <aboutphysycs@gmail.com> Reviewed-by:
Andy Shevchenko <andy@kernel.org> Signed-off-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
- Aug 02, 2023
-
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
Stanislav Jakubek authored
Convert Broadcom Kona family GPIO controller bindings to DT schema. Changes during conversion: - add used, but previously undocumented SoC-specific compatibles Signed-off-by:
Stanislav Jakubek <stano.jakubek@gmail.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
Andrei Coardos authored
This function call is not required because no counterpart platform_get_drvdata() call is present to leverage the private data of the driver. Since the private data is confined to this driver file, external access is not feasible. The use of this function appears redundant in the current context of the driver's implementation. Reviewed-by:
-
Andrei Coardos authored
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call, to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by:
-
- Jul 29, 2023
-
-
Andrei Coardos authored
The platform_set_drvdata() call was never used, ever since the driver was originally added. It looks like this copy+paste left-over. Possibly the author copied from a driver that had this line, but also had a remove hook. Reviewed-by:
Baolin Wang <baolin.wang@linux.alibaba.com> Signed-off-by:
-
Andrei Coardos authored
The platform_set_drvdata() isn't needed for anything. The function is a simple setter that doesn't change anything in the code. That is because there isn't a get function and since it has no dependencies it can be removed. Reviewed-by:
-
Andrei Coardos authored
The platform_set_drvdata() was needed when the driver had an explicit remove function. That function got removed a while back, so we don't need to keep a pointer (on 'dev->driver_data') for the private data of the driver anymore. Reviewed-by:
-
Alexandru Ardelean authored
The platform_set_drvdata() was needed when the driver had an explicit remove function. That function got removed a while back, so we don't need to keep a pointer (on 'dev->driver_data') for the private data of the driver anymore. Signed-off-by:
-
Alexander Stein authored
This is a gpio-controller, so gpio-line-names should be allowed as well. stmpe2403 supports up to 24 GPIOs. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
-
Ruan Jinjie authored
There is no need to call the dev_err_probe() function directly to print a custom message when handling an error from platform_get_irq() function as it is going to display an appropriate error message in case of a failure. Signed-off-by:
-
Okan Sahin authored
The DS4520 is a 9-bit nonvolatile (NV) I/O expander. It offers users a digitally programmable alternative to hardware jumpers and mechanical switches that are being used to control digital logic node. Signed-off-by:
Okan Sahin <okan.sahin@analog.com> Signed-off-by:
-
Okan Sahin authored
Add ADI DS4520 devicetree document. Signed-off-by:
-
Ruan Jinjie authored
There is no need to call the dev_err_probe() function directly to print a custom message when handling an error from platform_get_irq() function as it is going to display an appropriate error message in case of a failure. And the code to handle bank->irq = 0 is redundant because platform_get_irq() do not return 0. Signed-off-by:
-
- Jul 27, 2023
-
-
William Breathitt Gray authored
The 104-DIO-48E features an 8254 Counter/Timer chip providing three counter/timers which can be used for frequency measurement, frequency output, pulse width modulation, pulse width measurement, event count, etc. The counter/timers use the same addresses as PPI 0 (addresses 0x0 to 0x3), so a raw_spinlock_t is used to synchronize operations between the two regmap mappings to prevent clobbering. Reviewed-by:
-
Peng Fan authored
Add i.MX8QM/DXL gpio compatible which is compatible with i.MX35. Signed-off-by:
Peng Fan <peng.fan@nxp.com> Acked-by:
-
Andy Shevchenko authored
Driver is so simple, yet there was a room for mistakes. Reduce their appearance in the future by enabling COMPILE_TEST option. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by:
-
