linux-toradex.git/drivers/mfd/arizona-core.c, branch v6.15 Linux kernel for Apalis and Colibri modules mfd: Add missing MODULE_DESCRIPTION() macros 2024-07-04T16:38:40+00:00 Jeff Johnson quic_jjohnson@quicinc.com 2024-06-10T02:21:28+00:00 5fed47abb330818534a5a0d969f6634e5bd225d8 On x86, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/arizona.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/pcf50633-gpio.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/timberdale.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/ssbi.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/rt4831.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/intel_soc_pmic_bxtwc.o Add the missing invocation of the MODULE_DESCRIPTION() macro to all files which have a MODULE_LICENSE(). This includes mfd-core.c and vexpress-sysreg.c which, although they did not produce a warning with the x86 allmodconfig configuration, may cause this warning with other configurations. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Andy Shevchenko <andy@kernel.org> # for Intel Broxton PMIC Link: https://lore.kernel.org/r/20240609-md-drivers-mfd-v1-1-47cdd0b394e9@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org> 
On x86, make allmodconfig && make W=1 C=1 reports:

 WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/arizona.o
 WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/pcf50633-gpio.o
 WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/timberdale.o
 WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/ssbi.o
 WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/rt4831.o
 WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mfd/intel_soc_pmic_bxtwc.o

Add the missing invocation of the MODULE_DESCRIPTION() macro to all
files which have a MODULE_LICENSE().

This includes mfd-core.c and vexpress-sysreg.c which, although they
did not produce a warning with the x86 allmodconfig configuration, may
cause this warning with other configurations.

Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Andy Shevchenko <andy@kernel.org> # for Intel Broxton PMIC
Link: https://lore.kernel.org/r/20240609-md-drivers-mfd-v1-1-47cdd0b394e9@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
mfd: Explicitly include correct DT includes 2023-08-18T20:48:03+00:00 Rob Herring robh@kernel.org 2023-07-14T17:47:27+00:00 dc0c386e09a701e3c7c2dd58799cee992fa4e4b6 The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230714174731.4059811-1-robh@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> 
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230714174731.4059811-1-robh@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak 2023-02-22T08:25:53+00:00 Liang He windhl@126.com 2023-01-05T06:10:55+00:00 4414a7ab80cebf715045e3c4d465feefbad21139 In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get() as pm_runtime_get_sync() will increase the refcnt even when it returns an error. Signed-off-by: Liang He <windhl@126.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230105061055.1509261-1-windhl@126.com 
In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get()
as pm_runtime_get_sync() will increase the refcnt even when it
returns an error.

Signed-off-by: Liang He <windhl@126.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230105061055.1509261-1-windhl@126.com
mfd: arizona: Remove #ifdef guards for PM related functions 2022-12-07T13:28:12+00:00 Paul Cercueil paul@crapouillou.net 2022-10-23T09:48:43+00:00 50d3ac7d3ce472801c4c0b3f8705b943657a6552 Only export the arizona_pm_ops if CONFIG_PM is set, but leave the suspend/resume functions (and related code) outside #ifdef guards. If CONFIG_PM is not set, the arizona_pm_ops will be defined as "static __maybe_unused", and the structure plus all the callbacks will be automatically dropped by the compiler. This has the advantage of always compiling these functions in, independently of any Kconfig option. Thanks to that, bugs and other regressions are subsequently easier to catch. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee@kernel.org> 
Only export the arizona_pm_ops if CONFIG_PM is set, but leave the
suspend/resume functions (and related code) outside #ifdef guards.

If CONFIG_PM is not set, the arizona_pm_ops will be defined as
"static __maybe_unused", and the structure plus all the callbacks will
be automatically dropped by the compiler.

This has the advantage of always compiling these functions in,
independently of any Kconfig option. Thanks to that, bugs and other
regressions are subsequently easier to catch.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee@kernel.org>
mfd: arizona: Split of_match table into I2C and SPI versions 2021-11-05T14:40:26+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2021-09-28T16:30:35+00:00 3f65555c417c9c2eee235a137b5e5088a65439e4 The Arizona driver has both some devices which only have an I2C interface and some which only have a SPI interface. Currently both of these share an of_match table, but this means inapproriate compatibles are available for each interface. Tidy this up by creating a table for each interface listing only the appropriate compatibles. Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210928163035.23960-1-ckeepax@opensource.cirrus.com 
The Arizona driver has both some devices which only have an I2C
interface and some which only have a SPI interface. Currently both of
these share an of_match table, but this means inapproriate compatibles
are available for each interface. Tidy this up by creating a table for
each interface listing only the appropriate compatibles.

Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210928163035.23960-1-ckeepax@opensource.cirrus.com
mfd: arizona: Allow building arizona MFD-core as module 2021-06-02T09:50:04+00:00 Hans de Goede hdegoede@redhat.com 2021-05-21T13:50:23+00:00 33d550701b915938bd35ca323ee479e52029adf2 There is no reason why the arizona core,irq and codec model specific regmap bits cannot be build as a module. All they do is export symbols which are used by the arizona-spi/i2c and arizona-codec modules, which themselves can be built as module. Change the Kconfig and Makefile arizona bits so that the arizona MFD-core can be built as a module. This is especially useful on x86 platforms with a WM5102 codec, this allows the arizona MFD driver necessary for the WM5102 codec to be enabled in generic distro-kernels without growing the base kernel-image size. Note this also adds an explicit "depends on MFD_ARIZONA" to all the arizona codec Kconfig options. The codec drivers use functions from mfd arizona-core. These new depends are necessary to disallow the codec drivers being builtin when the arizona-core is build as a module, otherwise we end up with missing symbol errors when building vmlinuz. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> 
There is no reason why the arizona core,irq and codec model specific
regmap bits cannot be build as a module. All they do is export symbols
which are used by the arizona-spi/i2c and arizona-codec modules, which
themselves can be built as module.

Change the Kconfig and Makefile arizona bits so that the arizona MFD-core
can be built as a module.

This is especially useful on x86 platforms with a WM5102 codec, this
allows the arizona MFD driver necessary for the WM5102 codec to be
enabled in generic distro-kernels without growing the base kernel-image
size.

Note this also adds an explicit "depends on MFD_ARIZONA" to all the
arizona codec Kconfig options. The codec drivers use functions from mfd
arizona-core. These new depends are necessary to disallow the codec
drivers being builtin when the arizona-core is build as a module,
otherwise we end up with missing symbol errors when building vmlinuz.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: arizona: Drop arizona-extcon cells 2021-03-18T11:46:09+00:00 Hans de Goede hdegoede@redhat.com 2021-03-07T15:17:55+00:00 4e0b9ea85e6fb7654a3d28c23bbde736ce1592ae The arizona jack-dection handling is being reworked so that the codec-child-device drivers directly handle jack-detect themselves, so it is no longer necessary to instantiate "arizona-extcon" child-devices. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> 
The arizona jack-dection handling is being reworked so that the
codec-child-device drivers directly handle jack-detect themselves,
so it is no longer necessary to instantiate "arizona-extcon"
child-devices.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: arizona: Replace arizona_of_get_type() with device_get_match_data() 2021-02-04T13:54:56+00:00 Hans de Goede hdegoede@redhat.com 2021-01-20T21:49:54+00:00 039da225d644e523a3bbec78ee258b25fe0676f9 Replace the custom arizona_of_get_type() function with the generic device_get_match_data() helper. Besides being a nice cleanup this also makes it easier to add support for binding to ACPI enumerated devices. While at it also fix a possible NULL pointer deref of the id argument to the probe functions (this could happen on e.g. manual driver binding through sysfs). Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> 
Replace the custom arizona_of_get_type() function with the generic
device_get_match_data() helper. Besides being a nice cleanup this
also makes it easier to add support for binding to ACPI enumerated
devices.

While at it also fix a possible NULL pointer deref of the id
argument to the probe functions (this could happen on e.g. manual
driver binding through sysfs).

Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: arizona: Ensure 32k clock is put on driver unbind and error 2020-06-18T10:23:15+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2020-06-15T13:53:21+00:00 ddff6c45b21d0437ce0c85f8ac35d7b5480513d7 Whilst it doesn't matter if the internal 32k clock register settings are cleaned up on exit, as the part will be turned off losing any settings, hence the driver hasn't historially bothered. The external clock should however be cleaned up, as it could cause clocks to be left on, and will at best generate a warning on unbind. Add clean up on both the probe error path and unbind for the 32k clock. Fixes: cdd8da8cc66b ("mfd: arizona: Add gating of external MCLKn clocks") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> 
Whilst it doesn't matter if the internal 32k clock register settings
are cleaned up on exit, as the part will be turned off losing any
settings, hence the driver hasn't historially bothered. The external
clock should however be cleaned up, as it could cause clocks to be
left on, and will at best generate a warning on unbind.

Add clean up on both the probe error path and unbind for the 32k
clock.

Fixes: cdd8da8cc66b ("mfd: arizona: Add gating of external MCLKn clocks")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
mfd: arizona: Remove BUG_ON usage 2020-06-18T10:23:15+00:00 Charles Keepax ckeepax@opensource.cirrus.com 2020-06-15T13:53:20+00:00 14024cc9fe9478b9948521c0d38fde03ac00cd3d BUG_ON macros are generally frowned upon when the issue isn't super critical, the kernel can certainly carry on with the 32k clock on the CODEC in a bad state so change the BUG_ON to a WARN_ON. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> 
BUG_ON macros are generally frowned upon when the issue isn't super
critical, the kernel can certainly carry on with the 32k clock on the
CODEC in a bad state so change the BUG_ON to a WARN_ON.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>