- 18 Feb, 2022 40 commits
-
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Icenowy Zheng <icenowy@aosc.io> Cc: Luca Weiss <luca@z3ntu.xyz> Cc: Martijn Braam <martijn@brixit.nl> Reviewed-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20220130193147.279148-25-jic23@kernel.org
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Also switch to SIMPLE_DEV_PM_OPS rather than opencoding the same. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of ifdef based config guards. Also switch to SIMPLE_DEV_PM_OPS rather than open coding the structure. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. In this case SIMPLE_DEV_PM_OPS() could have been used previously. Now we have DEFINE_SIMPLE_DEV_PM_OPS() which also deals with letting the compiler remove the structure and functions so use that instead. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Reviewed-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based config guards. Removing instances of this approach from IIO also stops them being copied into new drivers. Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the bus specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220130205701.334592-17-jic23@kernel.org
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the bus specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the bus specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the bus specific device drivers that use them. Note the MAGN postfix here is reflecting that this driver is only responsible for part of the BMC150 device. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the bus specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the bus specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the bus specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the bus specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unneessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the various specific device drivers that use them. Signed-off-by:
-
Jonathan Cameron authored
Note these are used in the related ad5696-i2c drivers as well as the more obviously connected ad5686-spi driver. In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the various specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the various specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the various specific device drivers that use them. For more information see https://lwn.net/Articles/760045/ Both the exports used between the two common modules and the individual drivers are moved to a single namespace as greater granularity does not feel useful. Signed-off-by:
-
Jonathan Cameron authored
The obvious choice of ms_sensors felt rather too likely to clash with other namespaces introduced in future, hence the longer abbreviation. In order to avoid unnecessary pollution of the global symbol namespace move the common/library functions into a specific namespace and import that into the various specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the core/library functions into a specific namespace and import that into the various bus specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the core/library functions into a specific namespace and import that into the various specific device drivers that use them. For more information see https://lwn.net/Articles/760045/ An alternative here would be to conclude that we are unlikely to see support for the other ad7091r parts in the near future and just merge the two modules into one supporting just the i2c -5 variant. Signed-off-by:
-
Jonathan Cameron authored
In order to avoid unnecessary pollution of the global symbol namespace move the core/library functions into a specific namespace and import that into the various specific device drivers that use them. For more information see https://lwn.net/Articles/760045/Signed-off-by:
-
