| Age | Commit message (Collapse) | Author | Files | Lines |
|
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: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-14-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-13-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-12-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-11-jic23@kernel.org
|
|
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>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-10-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-9-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-8-jic23@kernel.org
|
|
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>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-7-jic23@kernel.org
|
|
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>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-6-jic23@kernel.org
|
|
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>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-5-jic23@kernel.org
|
|
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>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-4-jic23@kernel.org
|
|
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>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-3-jic23@kernel.org
|
|
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>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-2-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Himanshu Jha <himanshujha199640@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-17-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-16-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-15-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-14-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Song Qiang <songqiang1304521@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-13-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-12-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Tomasz Duszynski <tduszyns@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-11-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-10-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-9-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-8-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-7-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-6-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: William Markezana <william.markezana@meas-spec.com>
Cc: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-5-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-4-jic23@kernel.org
|
|
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 <Jonathan.Cameron@huawei.com>
Cc: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-3-jic23@kernel.org
|
|
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: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Renato Lui Geh <renatogeh@gmail.com>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20220130205701.334592-2-jic23@kernel.org
|
|
To avoid unnecessary pollution of the global symbol namespace move the
driver core and type specific core exports into their a new namespace
and import that where needed.
For more info see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-14-jic23@kernel.org
|
|
The core module and type specific core modules are made up of
several files. There is no benefit in duplicating the MODULE_* macros
in each file so remove them.
Noticed whilst adding MODULE_IMPORT_NS() as I missed some files and
it still worked, making it clear not all of these blocks were needed.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220116180535.2367780-13-jic23@kernel.org
|
|
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Sean Nyekjaer <sean@geanix.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-12-jic23@kernel.org
|
|
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Mike Looijmans <mike.looijmans@topic.nl>
Link: https://lore.kernel.org/r/20220116180535.2367780-11-jic23@kernel.org
|
|
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-10-jic23@kernel.org
|
|
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-9-jic23@kernel.org
|
|
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
For more info see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Puranjay Mohan <puranjay12@gmail.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-8-jic23@kernel.org
|
|
To avoid unnecessary pollution of the global symbol namespace move the
driver core exports into their own namespace and import that into the two
bus modules.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-7-jic23@kernel.org
|
|
In order to avoid unnecessary pollution of the global symbol namespace
move the driver core exports into their own namespace and import
that into the two bus modules.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Lucas Stankus <lucas.p.stankus@gmail.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-6-jic23@kernel.org
|
|
In order to avoid unnecessary pollution of the global symbol namespace
move the core bma400 functions into a bma400 specific namespace
and import that into the two bus modules.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220116180535.2367780-5-jic23@kernel.org
|
|
In order to avoid unnecessary pollution of the global symbol namespace
move the core kxsd9 functions into a kxsd9 specific namespace and import
that into the two bus modules.
For more information see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-4-jic23@kernel.org
|
|
In order to avoid unnecessary pollution of the global symbol namespace
move the core mma7455 functions into an mma7455 specific namespace and
import that into the two bus modules.
For more information see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220116180535.2367780-3-jic23@kernel.org
|
|
In order to avoid unnecessary pollution of the global symbol namespace
move the core mma9551 functions into an mma9551 specific namespace.
For more information see https://lwn.net/Articles/760045/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20220116180535.2367780-2-jic23@kernel.org
|
|
This chip appears to be register-compatible with the LIS2DH. The new
description is a copy of the LIS2DH's description with a different WAI
value.
Datasheet: http://linux-chenxing.org/silan/SC7A20-SilanMicroelectronics.pdf
Datasheet: http://www.siitek.com.cn/Upfiles/down/SC7A20说明书_0.92(智能穿戴).pdf
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220202235049.8051-4-samuel@sholland.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/20220202204112.57095-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add support for the standard "mount-matrix" device property to
the mma8452 driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220208124336.511884-2-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The mma8452_driver declares both of_match_table and i2c_driver.id_table
match-tables, but its probe() function only checked for of matches.
Add support for i2c_device_id matches. This fixes the driver not loading
on some x86 tablets (e.g. the Nextbook Ares 8) where the i2c_client is
instantiated by platform code using an i2c_device_id.
Drop of_match_ptr() protection to avoid unused warning.
Fixes: c3cdd6e48e35 ("iio: mma8452: refactor for seperating chip specific data")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220208124336.511884-1-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The vendor introduced an updated revision of IQS620A(T) silicon
which is backwards-compatible with previous revisions, the only
exception being the offset used to derive temperature.
Enable this new revision by returning the appropriate offset as
a function of the hardware number provided by the parent MFD.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
|
|
Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220207124204.11658-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220210135724.26660-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Use devm_delayed_work_autocancel() instead of hand writing it.
It saves a few lines of code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/8d5c50f191bd8f751849d72127f83b14a7636d64.1644755396.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|