- 03 Aug, 2023 14 commits
-
-
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 <wangzhu9@huawei.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-
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:
Linus Walleij <linus.walleij@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:
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:
-
- 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:
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:
-
- 29 Jul, 2023 9 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:
-
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:
-
- 27 Jul, 2023 8 commits
-
-
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:
William Breathitt Gray <william.gray@linaro.org> Signed-off-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:
-
Andy Shevchenko authored
Replace the GPLv2 boilerplate text with a nice and short SPDX header. Signed-off-by:
-
Andy Shevchenko authored
We have a temporary variable to keep pointer to struct device. Utilise it inside the ->probe() implementation. Signed-off-by:
-
Andy Shevchenko authored
There is nothing in the driver that requires OF APIs, make the driver OF independent. Signed-off-by:
-
Andy Shevchenko authored
Fix English spelling and grammar in the comments. While at it, fix the MODULE_AUTHOR() email address format. Reported-by:
-
Andy Shevchenko authored
Add missing platform_device.h that used to be implied by of_device.h. While at it, sort headers alphabetically for better maintenance. Reported-by:
Rob Herring <robh@kernel.org> Acked-by:
-
- 25 Jul, 2023 2 commits
-
-
Samuel Holland authored
This can reduce the kernel image size in multiplatform configurations. Acked-by:
Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by:
Samuel Holland <samuel.holland@sifive.com> Signed-off-by:
-
Samuel Holland authored
Do not parse the devicetree again when the data is already available from the IRQ subsystem. This follows the example of the ThunderX and X-Gene GPIO drivers. The ngpio check is needed to avoid a possible out-of-bounds read. Signed-off-by:
-
