- 18 Aug, 2023 1 commit
-
-
Bartosz Golaszewski authored
Use macros defined in linux/cleanup.h to automate resource lifetime control in gpio-sim. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org>
-
- 15 Aug, 2023 1 commit
-
-
Bartosz Golaszewski authored
Turns out we can avoid the memmove() by using skip_spaces() and strim(). We did that in gpio-consumer, let's do it in gpio-sim. Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
- 12 Aug, 2023 1 commit
-
-
Bartosz Golaszewski authored
Simplify the logic when checking the current live value against the user input. Signed-off-by:
-
- 11 Aug, 2023 10 commits
-
-
Shenwei Wang authored
Release the parent interrupt request during runtime suspend, allowing the parent interrupt controller to enter runtime suspend if there are no active users. This change may not have a visible impact if the parent controller is the GIC, but it can enable significant power savings for parent IRQ controllers like IRQSteer inside a subsystem on i.MX8 SoCs. Releasing the parent IRQ provides an opportunity for the subsystem to enter suspend states if there are no active users. Signed-off-by:
Shenwei Wang <shenwei.wang@nxp.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
'devid' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: gpio-mxs.c:274:16: error: cast to smaller integer type 'enum mxs_gpio_id' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Rajeshwar R Shinde authored
Use of macro ARRAY_SIZE to calculate array size minimizes the redundant code and improves code reusability. This fixes warnings reported by Coccinelle: drivers/gpio/gpio-imx-scu.c:106:32-33: WARNING: Use ARRAY_SIZE Signed-off-by:
Rajeshwar R Shinde <coolrrsh@gmail.com> Reviewed-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. The WinSystems WS16C48 provides the following registers: Offset 0x0-0x5: Port 0-5 I/O Offset 0x6: Int_Pending Offset 0x7: Page/Lock Offset 0x8-0xA (Page 1): Pol_0-Pol_2 Offset 0x8-0xA (Page 2): Enab_0-Enab_2 Offset 0x8-0xA (Page 3): Int_ID0-Int_ID2 Port 0-5 I/O provides access to 48 lines of digital I/O across six registers, each bit position corresponding to the respective line. Writing a 1 to a respective bit position causes that output pin to sink current, while writing a 0 to the same bit position causes that output pin to go to a high-impedance state and allows it to be used an input. Reads on a port report the inverted state (0 = high, 1 = low) of an I/O pin when used in input mode. Interrupts are supported on Port 0-2. Int_Pending is a read-only register that reports the combined state of the INT_ID0 through INT_ID2 registers; an interrupt pending is indicated when any of the low three bits are set. The Page/Lock register provides the following bits: Bit 0-5: Port 0-5 I/O Lock Bit 6-7: Page 0-3 Selection For Bits 0-5, writing a 1 to a respective bit position locks the output state of the corresponding I/O port. Writing the page number to Bits 6-7 selects that respective register page for use. Pol_0-Pol_2 are accessible when Page 1 is selected. Writing a 1 to a respective bit position selects the rising edge detection interrupts for that input line, while writing a 0 to the same bit position selects the falling edge detection interrupts. Enab_0-Enab_2 are accessible when Page 2 is selected. Writing a 1 to a respective bit position enables interrupts for that input line, while writing a 0 to that same bit position clears and disables interrupts for that input line. Int_ID0-Int_ID2 are accessible when Page 3 is selected. A respective bit when read as a 1 indicates that an edge of the polarity set in the corresponding polarity register was detected for the corresponding input line. Writing any value to this register clears all pending interrupts for the register. Suggested-by:Michael Walle <michael@walle.cc> Reviewed-by:
William Breathitt Gray <william.gray@linaro.org> Reviewed-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. For the PCIe-IDIO-24 series of devices, the following BARs are available: BAR[0]: memory mapped PEX8311 BAR[1]: I/O mapped PEX8311 BAR[2]: I/O mapped card registers There are 24 FET Output lines, 24 Isolated Input lines, and 8 TTL/CMOS lines (which may be configured for either output or input). The GPIO lines are exposed by the following card registers: Base +0x0-0x2 (Read/Write): FET Outputs Base +0xB (Read/Write): TTL/CMOS Base +0x4-0x6 (Read): Isolated Inputs Base +0x7 (Read): TTL/CMOS In order for the device to support interrupts, the PLX PEX8311 internal PCI wire interrupt and local interrupt input must first be enabled. The following card registers for Change-Of-State may be used: Base +0x8-0xA (Read): COS Status Inputs Base +0x8-0xA (Write): COS Clear Inputs Base +0xB (Read): COS Status TTL/CMOS Base +0xB (Write): COS Clear TTL/CMOS Base +0xE (Read/Write): COS Enable The COS Enable register is used to enable/disable interrupts and configure the interrupt levels; each bit maps to a group of eight inputs as described below: Bit 0: IRQ EN Rising Edge IN0-7 Bit 1: IRQ EN Rising Edge IN8-15 Bit 2: IRQ EN Rising Edge IN16-23 Bit 3: IRQ EN Rising Edge TTL0-7 Bit 4: IRQ EN Falling Edge IN0-7 Bit 5: IRQ EN Falling Edge IN8-15 Bit 6: IRQ EN Falling Edge IN16-23 Bit 7: IRQ EN Falling Edge TTL0-7 An interrupt is asserted when a change-of-state matching the interrupt level configuration respective for a particular group of eight inputs with enabled COS is detected. The COS Status registers may be read to determine which inputs have changed; if interrupts were enabled, an IRQ will be generated for the set bits in these registers. Writing the value read from the COS Status register back to the respective COS Clear register will clear just those interrupts. Reviewed-by: -
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:
-
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:
-
- 03 Aug, 2023 16 commits
-
-
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:
-
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:
-
- 01 Aug, 2023 7 commits
-
-
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:
-
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:
-
- 29 Jul, 2023 4 commits
-
-
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:
-
