The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
ltc428_clk_provider_setup() does not fill in any parent clocks, and
assumes that init.num_parents is NULL. However, the latter in
uninitialized, and thus may cause a crash.
Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.
Fixes: cbc29538db ("hwmon: Add driver for LTC4282")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/8ec3c5cbd2df675a938f090470f5da5f22008517.1787165329.git.geert+renesas@glider.be
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When NR_CPUS is less than 16, or when SMP is disabled, the default value
of 16 is invalid.
While actual configuration picks up a sensible and valid default
(NR_CPUS or 1), "make savedefconfig" will still write a line like
CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1
to the defconfig file, even if that matches the sensible default.
Avoid needlessly enlarging the defconfig files, and reduce churn for
updating them, by specifying valid defaults depending on SMP and
NR_CPUS.
While at it, make the prompt depend on SMP, as there is no point in
asking the user about the maximum number of decompression streams if
there is only one valid answer.
Fixes: c9b47e6b23 ("erofs: cap LZMA stream pool size")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <xiang@kernel.org>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/6e7b5258ff73e93fe23dd83cf56f806ee60fa7a9.1787241693.git.geert+renesas@glider.be
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/8281eaf605069aac2211d83233e11285b8e8ca84.1787241693.git.geert+renesas@glider.be
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/6dba18b645aeea279a67f4625d5ec48037c76f0c.1787241693.git.geert+renesas@glider.be
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/c5290fb9a28b45d6bcec724d5897f8bcbf96ea50.1787241693.git.geert+renesas@glider.be
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/657f2b3a871074087aee0b7a70bf527ab0f48da8.1787241693.git.geert+renesas@glider.be
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
aml_spisg_clk_init() fills in init.parent_data, and assumes that
init.parent_names is NULL. However, the latter in uninitialized, and
thus may cause a crash.
Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.
Fixes: cef9991e04 ("spi: Add Amlogic SPISG driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Link: https://patch.msgid.link/9fb35ae0aedb7a6db0db6c78a8193c7602dd9d44.1787165329.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
visconti_clk_register_gate() fills in init.parent_data, and assumes that
init.parent_names is NULL. However, the latter in uninitialized, and
thus may cause a crash.
Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.
Fixes: b4cbe606dc ("clk: visconti: Add support common clock driver and reset driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
_register_mux() fills in init.parent_data, and assumes that
init.parent_names is NULL. However, the latter is uninitialized, and
thus may cause a crash.
Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.
Fixes: 667f420c09 ("clk: ti: mux: resolve parent clocks by DT index, not by name")
Closes: https://lore.kernel.org/CAMuHMdU3yVqoyHC4eNF2NuYo8wy+6ODLoYat4R71X99Mxc_=kw@mail.gmail.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Add a minimal Module Controller driver for the R-Car X5H (R8A78000) SoC.
For now this just supports the always-on power domains, and dummy module
clocks and resets for the serial console (which is enabled by the boot
loader).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Unlike older GIC variants, the GICv3 DT bindings do not support
specifying a CPU mask in PPI interrupt specifiers. Drop the masks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Renesas RZ/T2H and RZ/N2H LCDC and RTC Clock DT Binding Definitions
LCD Controller and Real-Time Clock DT binding definitions for the
Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs, shared by driver
and DT source files.
Replace the sole hexadecimal interrupt number by a decimal number, for
consistency with all other interrupt numbers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Replace sequences of of_machine_is_compatible() calls by single calls to
the of_machine_compatible_match() helper, to simplify the code, and to
reduce code size.
Note that this does have a slight performance impact on matching
platforms: while the C sequences terminated evaluation after a match,
(internal) of_device_compatible_match() calculates a matching score, and
thus always checks against all passed compatible values.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/2230eb28da9b8d8bdee4e4fd7e19dc8f074531bc.1780499233.git.geert+renesas@glider.be
The NVIDIA Tegra264 MAIN, AON, and UPHY pin controllers are only present
on NVIDIA Tegra264 SoCs. Hence add a dependency on ARCH_TEGRA, to
prevent asking the user about this driver when configuring a kernel
without NVIDIA Tegra SoC support.
Fixes: c985062069 ("pinctrl: tegra: Add Tegra264 pinmux driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
The NVIDIA Tegra238 MAIN and AON pin controllers are only present on
NVIDIA Tegra238 SoCs. Hence add a dependency on ARCH_TEGRA, to prevent
asking the user about this driver when configuring a kernel without
NVIDIA Tegra SoC support.
Fixes: 25cac7292d ("pinctrl: tegra: Add Tegra238 pinmux driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Currently, R-Car Gen2 and Gen3 share the same .plat_start() callback.
However, this single callback performs different operations, after
checking the XHCI's controller compatible value.
Avoid repeated checking of compatible values and reduce kernel size by
splitting this method in two separate functions. Update
xhci_rcar_resume_quirk() to dispatch to the correct method by calling it
through the .plat_start() function pointer, too.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/d1ee4e1bb9106f8251b061b52948434d560b4675.1780499433.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When reading /sys/kernel/debug/pinctrl/*.pinctrl-sh-pfc/pinconf-groups
while CONFIG_DEBUG_PINCTRL is enabled, the user is confronted with a
seemlingly endless stream of identical messages on the console:
sh-pfc e6060000.pinctrl: cannot get configuration for pin group, missing group config get function in driver
Fix this by implementing the sh_pfc_pinconf_ops.pin_config_group_get()
callback.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/130ce567f23fd6eef8f5fa7273480a0e3ff2d1d9.1777562482.git.geert+renesas@glider.be
Lazy discovery of discrete rates works as follows:
A. Grab the first three rates,
B. Grab the last rate, if there are more than three rates.
It is up to the SCMI provider implementation to decide how many rates
are returned in response to a single CLOCK_DESCRIBE_RATES command. Each
rate received is stored in the scmi_clock_rates.rates[] array, and
.num_rates is updated accordingly.
When more than 3 rates have been received after step A, the last rate
may have been received already, and stored in scmi_clock_rates.rates[]
(which has space for scmi_clock_desc.tot_rates entries). Hence grabbing
the last rate again will store it a second time, beyond the end of the
array.
Fix this by only grabbing the last rate when we don't already have it.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://patch.msgid.link/20260508153300.2224715-15-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
When using a bound-iterator with an upper bound, commands are sent, and
responses are received, until the upper bound is reached. However, it
is up to the SCMI provider implementation to decide how many rates are
returned in response to a single CLOCK_DESCRIBE_RATES command. If the
last response contains rates beyond the specified upper bound, they are
still passed up for further processing. This may lead to buffer
overflows in unprepared callsites.
While the imprecise bound handling may have been intentional (it was
mentioned in the commit message introducing the code), it is still
confusing for users, and may cause hard to debug crashes. Fix this by
strictly enforcing the upper bound.
Note that this may cause an increase in the number of
CLOCK_DESCRIBE_RATES commands issued, as retrieving the last rate may no
longer be done inadvertentently, but require its own command.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260508153300.2224715-12-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Renesas RZ/G3L DT Pin Control Binding Definitions
Pin Control DT bindings and binding definitions for the Renesas RZ/G3L
(R9A08G046) SoC, shared by driver and DT source files.
Renesas RZ/G3L DT Pin Control Binding Definitions
Pin Control DT bindings and binding definitions for the Renesas RZ/G3L
(R9A08G046) SoC, shared by driver and DT source files.
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linusw@kernel.org>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linusw@kernel.org>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
While Ingenic is a 32-bit platform, it is still better to use the
correct type, to serve as an example.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Linus Walleij <linusw@kernel.org>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linusw@kernel.org>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linusw@kernel.org>
When a range contains only an end ("-X"), the number string is parsed
twice, as both "sep == first" and "sep != last" are true. Fix this by
dropping the superfluous number parsing for "sep == first".
This does have a harmless functional impact for the unbounded range:
"-" is now accepted, while it was rejected before.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/fe257b3b7b7b5c17fd0e5727bb9746c731bd7e3c.1775205358.git.geert+renesas@glider.be
(sudeep.holla: Initialise ret to 0 as it will be uninitialise for "-" range)
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Unlike older GIC variants, the GICv3 DT bindings do not support
specifying a CPU mask in PPI interrupt specifiers. Drop the masks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Unlike older GIC variants, the GICv3 DT bindings do not support
specifying a CPU mask in PPI interrupt specifiers. Drop the masks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Unlike older GIC variants, the GICv3 DT bindings do not support
specifying a CPU mask in PPI interrupt specifiers. Drop the masks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Renesas RZ/G3L DT Binding Definitions
DT bindings and binding definitions for the Renesas RZ/G3L (R9A08G046)
SoC, shared by driver and DT source files.
Renesas RZ/G3L DT Binding Definitions
DT bindings and binding definitions for the Renesas RZ/G3L (R9A08G046)
SoC, shared by driver and DT source files.
Linux style is to handle early-on failure. Inverting the first
condition lets us simplify the second, and improves readability.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Each SCMI firmware quirk contains a code snippet, which handles the
quirk, and has full access to the surrounding context. When this
context is (part of) a loop body, the code snippet may want to use loop
control statements like "break" and "continue". Unfortunately the
SCMI_QUIRK() macro implementation contains a dummy loop, taking
precedence over any outer loops. Hence quirk code cannot use loop
control statements, but has to resort to polluting the surrounding
context with a label, and use goto.
Fix this by replacing the "do { ... } while (0)" construct in the
SCMI_QUIRK() implementation by "({ ... })".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Message-Id: <51de914cddef8fa86c2e7dd5397e5df759c45464.1773675224.git.geert+renesas@glider.be>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Currently, there are two helpers to match the root compatible value
against an of_device_id array:
- of_machine_device_match() returns true if a match is found,
- of_machine_get_match_data() returns the match data if a match is
found.
However, there is no helper that returns the actual of_device_id
structure corresponding to the match, leading to code duplication in
various drivers.
Fix this by reworking of_machine_device_match() to return the actual
match structure, and renaming it to of_machine_get_match().
Retain the old of_machine_device_match() functionality using a cheap
static inline wrapper around the new of_machine_get_match() helper.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/14e1c03d443b1a5f210609ec3a1ebbaeab8fb3d9.1772468323.git.geert+renesas@glider.be
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Geert Uytterhoeven