* Re: [PATCH v3 01/12] dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
From: sashiko-bot @ 2026-07-06 17:58 UTC (permalink / raw)
To: Prabhakar
Cc: conor+dt, linux-rtc, wsa+renesas, Alexandre Belloni, robh,
devicetree
In-Reply-To: <20260706175138.12587-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The RZ/T2H RTC variant adds a 1Hz clock output capability but the binding schema fails to document and require the `#clock-cells` property.
--
commit 521c08a40b8b1ac0b30dec5219ca0271639457ef
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
This commit adds compatible strings for the RTC block found on the Renesas
RZ/T2H and RZ/N2H SoCs. It also updates the binding schema to require the
additional clock inputs used by these variants.
> diff --git a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
> --- a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
[ ... ]
> @@ -54,6 +58,23 @@ required:
> - clock-names
> - power-domains
>
> +allOf:
> + - $ref: rtc.yaml#
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,r9a09g077-rtc
> + - renesas,r9a09g087-rtc
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + clock-names:
> + minItems: 2
[Severity: Medium]
The commit message mentions that the RZ/T2H RTC variant supports a 1Hz clock
output signal on the RTCAT1HZ pin. Since this introduces a clock provider
capability, shouldn't the #clock-cells property be documented and required
here with an appropriate const constraint?
Without documenting this property, adding #clock-cells to an RTC node using
the renesas,r9a09g077-rtc compatible string will cause device trees to fail
dt_binding_check validation due to the unevaluatedProperties: false constraint.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706175138.12587-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=1
^ permalink raw reply
* Re: [PATCH v3 03/12] rtc: rzn1: fix weekday underflow when alarm crosses month boundary
From: sashiko-bot @ 2026-07-06 18:00 UTC (permalink / raw)
To: Prabhakar
Cc: Alexandre Belloni, conor+dt, devicetree, wsa+renesas, linux-rtc,
robh
In-Reply-To: <20260706175138.12587-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> In rzn1_rtc_set_alarm(), the driver attempts to calculate the weekday
> for an alarm by computing the day delta between the alarm time and the
> current time:
>
> days_ahead = tm->tm_mday - tm_now.tm_mday;
> wday = (tm_now.tm_wday + days_ahead) % 7;
>
> However, if an alarm is scheduled for the beginning of the next month
> while the current time is at the end of the month (e.g., current day is
> 31, alarm day is 1), `tm->tm_mday - tm_now.tm_mday` results in a negative
> value (-30). Since `days_ahead` is an unsigned int, this underflows to a
> large positive number, leading to an incorrect `wday` being written to
> the RZN1_RTC_ALW register. As a result, the alarm fails to fire.
>
> Fix this by utilizing the already computed `alarm` time64_t timestamp.
> Convert it back into an rtc_time struct via rtc_time64_to_tm(), which
> automatically handles month boundaries and correctly populates the
> `tm_wday` field.
>
> Fixes: b5ad1bf00d2c4 ("rtc: rzn1: Add alarm support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706175138.12587-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=3
^ permalink raw reply
* Re: [PATCH v3 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
From: sashiko-bot @ 2026-07-06 18:03 UTC (permalink / raw)
To: Prabhakar
Cc: linux-rtc, wsa+renesas, robh, Alexandre Belloni, devicetree,
conor+dt
In-Reply-To: <20260706175138.12587-13-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver may incorrectly fall back to SUBU mode on RZ/T2H and RZ/N2H SoCs, leading to accesses of the non-existent RTCA0SUBU register and a potential kernel panic.
--
commit ee14aa230b364e5ad7677d78cb0c0a8599351c1c
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
This commit adds support for the RTC block on Renesas RZ/T2H and RZ/N2H SoCs
using a new compatible string. It notes that the variants lack the RTCA0SUBU
register, but rely on the existing SCMP mode to function without it.
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index d1a974c6b8bbe..1d4d8d01749d3 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
> @@ -508,6 +508,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> }
>
> static const struct of_device_id rzn1_rtc_of_match[] = {
> + { .compatible = "renesas,r9a09g077-rtc" },
[Severity: High]
If the devicetree for this SoC omits the "xtal" clock or specifies a standard
32768 Hz frequency, will the driver inadvertently fall back to SUBU mode?
Looking at rzn1_rtc_probe(), the driver sets scmp_val = 0 for 32768 Hz
crystals or when the clock is absent:
drivers/rtc/rtc-rzn1.c:rzn1_rtc_probe() {
...
xtal = devm_clk_get_optional(dev, "xtal");
if (IS_ERR(xtal)) {
return PTR_ERR(xtal);
} else if (xtal) {
rate = clk_get_rate(xtal);
...
if (rate != 32768)
scmp_val = RZN1_RTC_CTL0_SLSB_SCMP;
}
...
if (scmp_val) {
...
} else {
rtc->rtcdev->ops = &rzn1_rtc_ops_subu;
}
...
}
If this happens on the RZ/T2H, rzn1_rtc_ops_subu exposes the .read_offset
and .set_offset callbacks. Any userspace read of the offset sysfs node
would then trigger a hardware access to the missing register:
drivers/rtc/rtc-rzn1.c:rzn1_rtc_read_offset() {
...
val = readl(rtc->base + RZN1_RTC_SUBU);
...
}
Can this lead to a synchronous external abort (kernel panic) when an
unprivileged user reads /sys/class/rtc/rtc0/offset?
Should we add match data to this compatible string to identify the variant
and explicitly reject probe with -EOPNOTSUPP if the clock configuration
would require the unsupported SUBU mode?
> { .compatible = "renesas,rzn1-rtc" },
> {},
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706175138.12587-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=12
^ permalink raw reply
* Re: [PATCH v3 06/12] rtc: rzn1: Fix alarm range check truncation on 32-bit systems
From: sashiko-bot @ 2026-07-06 18:04 UTC (permalink / raw)
To: Prabhakar
Cc: wsa+renesas, conor+dt, devicetree, linux-rtc, Alexandre Belloni,
robh
In-Reply-To: <20260706175138.12587-7-prabhakar.mahadev-lad.rj@bp.renesas.com>
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> alarm and farest were declared as unsigned long, but
> rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
> unsigned long is 32 bits, the assignment silently truncates the upper
> 32 bits of the timestamp.
>
> Fix by declaring alarm and farest as time64_t and replacing
> time_after() with a direct signed comparison, which is correct for
> time64_t values that will never realistically overflow.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706175138.12587-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=6
^ permalink raw reply
* Re: [PATCH] rtc: s32g: add missing MODULE_DEVICE_TABLE()
From: Ciprian Marian Costea @ 2026-07-07 10:50 UTC (permalink / raw)
To: Pengpeng Hou, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
NXP S32 Linux Team, Alexandre Belloni
Cc: linux-arm-kernel, linux-rtc, linux-kernel
In-Reply-To: <20260704122003.70108-1-pengpeng@iscas.ac.cn>
On 7/4/2026 3:20 PM, Pengpeng Hou wrote:
> The driver has an OF match table wired to .of_match_table, but does
> not export the table with MODULE_DEVICE_TABLE().
>
> Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
> information is generated for OF based module autoloading.
>
> This is a source-level fix. It does not claim dynamic hardware
> reproduction; the evidence is the driver-owned match table, its use by
> the platform driver, and the missing module alias publication.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> ---
> drivers/rtc/rtc-s32g.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/rtc/rtc-s32g.c b/drivers/rtc/rtc-s32g.c
> index 3a0818e972eb..86716192d10f 100644
> --- a/drivers/rtc/rtc-s32g.c
> +++ b/drivers/rtc/rtc-s32g.c
> @@ -366,6 +366,7 @@ static const struct of_device_id rtc_dt_ids[] = {
> { .compatible = "nxp,s32g2-rtc", .data = &rtc_s32g2_data },
> { /* sentinel */ },
> };
> +MODULE_DEVICE_TABLE(of, rtc_dt_ids);
>
> static DEFINE_SIMPLE_DEV_PM_OPS(s32g_rtc_pm_ops,
> s32g_rtc_suspend, s32g_rtc_resume);
^ permalink raw reply
* Re: [PATCH v4 9/9] clk: sunxi-ng: sun6i-rtc: add a733 support
From: Jerome Brunet @ 2026-07-08 12:38 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, Michael Turquette,
Stephen Boyd, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <CAGb2v67AXz=TPzNFnRMS9-vweL+6g5T57dwwYCdorwdi8HWcjA@mail.gmail.com>
On mar. 07 juil. 2026 at 00:47, Chen-Yu Tsai <wens@kernel.org> wrote:
>> +
>> +static struct ccu_div osc24M_32k_div_a733_clk = {
>> + .enable = BIT(1),
>> + .div = _SUNXI_CCU_DIV_TABLE(14, 2, osc24M_32k_div_a733_table),
>> + .common = {
>> + .reg = DCXO_CTRL_REG,
>> + .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k-div",
>> + osc24M,
>> + &ccu_rodiv_ops,
>> + 0),
>> + },
>> +};
>> +
>> +static SUNXI_CCU_GATE(osc24M_32k_clk, "osc24M-32k", "osc24M-32k-div",
>
> I'm not a big fan of using global clock parent names, especially when we
> can have proper struct clk_hw pointer references. However in this case
> it seems unavoidable without making a huge mess.
>
Indeed there is no way around it to support different SoC path with
static data.
>> + LOSC_OUT_GATING_REG, BIT(16), 0);
>>
>> static const struct clk_hw *rtc_32k_parents[] = {
>> &osc32k_clk.common.hw,
>> @@ -267,6 +296,15 @@ static struct ccu_mux osc32k_fanout_clk = {
>> },
>> };
[...]
>> };
>> MODULE_DEVICE_TABLE(of, sun6i_rtc_ccu_match);
>> @@ -375,6 +435,13 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
>> osc32k_fanout_init_data.parent_data = data->osc32k_fanout_parents;
>> osc32k_fanout_init_data.num_parents = data->osc32k_fanout_nparents;
>>
>> + if (data->have_dcxo_status)
>> + sun6i_rtc_ccu_hw_clks.hws[CLK_OSC24M_32K_DIV] =
>> + &osc24M_32k_div_a733_clk.common.hw;
>> +
>> + if (!data->have_phy_ref_gates)
>> + sun6i_rtc_ccu_hw_clks.num = CLK_OSC24M_32K_DIV + 1;
>
> Maybe keep the old CLK_NUMBER macro and call the new one CLK_NUMBER_A733?
> The point is to not directly use a random macro + 1 here.
Are you sure you about this ? You are going to end up with this
CLK_NUMBER_A733 in the table which is going to be odd (unless I put an
explanation next it) then this CLK_NUMBER without any suffix put next to
clock gate things
The choice I made initially was meant to keep thing as clear as possible
* CLK_NUMBER remains the number of clock in the table
* CLK_OSC24M_32K_DIV + 1 (while not very nice) clearly show which is the
last clock in that case. It is not random IMO.
If you still prefer the suggestion above, I'll submit v5 with it but it
look odd to me.
>
> Otherwise,
>
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
>
>> +
>> return devm_sunxi_ccu_probe(dev, reg, &sun6i_rtc_ccu_desc);
>> }
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
>> index ab7b92b47f59..4f4f4cb00f1d 100644
>> --- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
>> +++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
>> @@ -11,6 +11,6 @@
>> #define CLK_RTC_32K 6
>> #define CLK_OSC24M_32K_DIV 7
>>
>> -#define CLK_NUMBER (CLK_OSC24M_32K_DIV + 1)
>> +#define CLK_NUMBER (CLK_HOSC_SERDES1 + 1)
>>
>> #endif /* _CCU_SUN6I_RTC_H */
>>
>> --
>> 2.47.3
>>
--
Jerome
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Sudeep Holla @ 2026-07-09 10:10 UTC (permalink / raw)
To: Hans de Goede
Cc: Bjorn Andersson, Sudeep Holla, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Brian Masney, Rafael J. Wysocki, Viresh Kumar, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Guenter Roeck, Jyoti Bhayana, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Dmitry Torokhov, Ulf Hansson,
Liam Girdwood, Mark Brown, Philipp Zabel, Alexandre Belloni,
linux-clk, linux-pm, imx, linux-hwmon, linux-iio, linux-input,
linux-rtc
In-Reply-To: <8c2a4ae3-95cc-489a-a7a4-90a3ee2597e9@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 10:31:12PM +0200, Hans de Goede wrote:
> Hi,
>
> On 18-Jun-26 17:56, Bjorn Andersson wrote:
> > SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
> > modules, but they are then not automatically loaded. Rework the SCMI
> > device table alias support to make modpost consume the information from
> > MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
> > this information, if known. Also add a protocol-based alias to also
> > trigger driver loading when only the SCMI protocol id is known.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>
> So I just gave this a test spin and unfortunately it does not work.
>
> The problem with Fedora's kernel-config / setup is that the
> request_module() from patch 2/2 runs from the initramfs, but
> the scmi_cpufreq module is only available in the rootfs.
>
> It does work if I explictly add the scmi_cpufreq module to
> the initramfs, then it does get autoloaded.
>
> We really need some place to put a uevent sysfs attr which then
> gets replayed when udev is restarted from the rootfs and then
> re-reads all the uevent files as part of its coldplug
> enumeration.
>
I don't have much knowledge on uevent to provide any suggestions/help.
But isn't this a generic requirement ? I mean you could have modules
install on the rootfs and not all of them are packed in initramfs ?
Just wondering if that works for other modules, we can examine how
do they work and what are we missing ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 3/8] mfd: Support for ROHM BD73800 PMIC core
From: Lee Jones @ 2026-07-09 10:48 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Matti Vaittinen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Brian Masney, Linus Walleij,
Bartosz Golaszewski, Alexandre Belloni, devicetree, linux-kernel,
linux-clk, linux-gpio, linux-rtc
In-Reply-To: <043fc930caca4c436651e8fa77a1ae16a26d0a98.1782909323.git.mazziesaccount@gmail.com>
/* Sashiko Automation: Reviewed (0 Findings) */
On Wed, 01 Jul 2026, Matti Vaittinen wrote:
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> The BD73800 integrates regulators, ADC (intended for accumulating current /
> voltage / power values), a real-time clock (RTC), clock gate and GPIOs.
>
> Add core support for ROHM BD73800 Power Management IC.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
> drivers/mfd/Kconfig | 15 +-
> drivers/mfd/rohm-bd71828.c | 145 ++++++++++++++-
> include/linux/mfd/rohm-bd73800.h | 307 +++++++++++++++++++++++++++++++
> include/linux/mfd/rohm-generic.h | 1 +
> 4 files changed, 461 insertions(+), 7 deletions(-)
> create mode 100644 include/linux/mfd/rohm-bd73800.h
>
> diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
> index a79f354bf5cb..31637777b627 100644
> --- a/drivers/mfd/rohm-bd71828.c
> +++ b/drivers/mfd/rohm-bd71828.c
> @@ -2,7 +2,7 @@
> /*
> * Copyright (C) 2019 ROHM Semiconductors
> *
You should consider updating this.
> - * ROHM BD718[15/28/79] and BD72720 PMIC driver
> + * ROHM BD718[15/28/79], BD72720 and BD73[8/9]00 PMIC driver
> */
>
> #include <linux/gpio_keys.h>
> @@ -249,6 +256,17 @@ static const struct mfd_cell bd72720_mfd_cells[] = {
> },
> };
>
> +static const struct mfd_cell bd73800_mfd_cells[] = {
> + { .name = "bd73800-pmic", },
> + { .name = "bd73800-clk", },
> + { .name = "bd73800-gpio", },
> + {
> + .name = "bd73800-rtc",
> + .num_resources = ARRAY_SIZE(bd73800_rtc_irqs),
> + .resources = &bd73800_rtc_irqs[0],
> + },
> +};
'bd73800_rtc_irqs'?
> +
> static const struct regmap_range bd71815_volatile_ranges[] = {
> regmap_reg_range(BD71815_REG_SEC, BD71815_REG_YEAR),
> regmap_reg_range(BD71815_REG_CONF, BD71815_REG_BAT_TEMP),
> @@ -383,6 +412,24 @@ static const struct regmap_access_table bd72720_volatile_regs_4c = {
> .n_yes_ranges = ARRAY_SIZE(bd72720_volatile_ranges_4c),
> };
>
> +static const struct regmap_access_table bd73800_volatile_regs = {
> + .yes_ranges = &bd73800_volatile_ranges[0],
'bd73800_volatile_ranges'?
> + .n_yes_ranges = ARRAY_SIZE(bd73800_volatile_ranges),
> +};
> +
> +static const struct regmap_range bd73800_read_only_ranges[] = {
> + regmap_reg_range(BD73800_REG_PRODUCT_ID, BD73800_REG_NVMVERSION),
> + regmap_reg_range(BD73800_REG_POW_STATE, BD73800_REG_POW_STATE),
> + regmap_reg_range(BD73800_REG_ADC_ACCUM_CNT2, BD73800_REG_ADC_TEMP_VAL0),
> + regmap_reg_range(BD73800_REG_INT_MAIN_STAT, BD73800_REG_INT_MAIN_STAT),
> + regmap_reg_range(BD73800_REG_INT_MAIN_SRC, BD73800_REG_INT_5_SRC),
> +};
> +
> +static const struct regmap_access_table bd73800_ro_regs = {
> + .no_ranges = &bd73800_read_only_ranges[0],
Etc.
> + .n_no_ranges = ARRAY_SIZE(bd73800_read_only_ranges),
> +};
> +
> static const struct regmap_config bd71815_regmap = {
> .reg_bits = 8,
> .val_bits = 8,
> @@ -852,6 +962,25 @@ static const struct regmap_irq_chip bd72720_irq_chip = {
> .irq_reg_stride = 1,
> };
>
> +static const struct regmap_irq_chip bd73800_irq_chip = {
> + .name = "bd73800_irq",
> + .main_status = BD73800_REG_INT_MAIN_STAT,
> + .irqs = &bd73800_irqs[0],
Here too.
> + .num_irqs = ARRAY_SIZE(bd73800_irqs),
> + .status_base = BD73800_REG_INT_1_STAT,
> + .unmask_base = BD73800_REG_INT_1_EN,
> + .ack_base = BD73800_REG_INT_1_STAT,
> + .init_ack_masked = true,
> + .num_regs = 5,
> + .num_main_regs = 1,
> + /*
> + * Ignore mirrored bits [7:5]. They are handled as part of normal INT_4
> + * handling.
> + */
> + .num_main_status_bits = 5,
> + .irq_reg_stride = 1,
> +};
> +
> static int set_clk_mode(struct device *dev, struct regmap *regmap,
> int clkmode_reg)
> {
> diff --git a/include/linux/mfd/rohm-bd73800.h b/include/linux/mfd/rohm-bd73800.h
> new file mode 100644
> index 000000000000..4bceb20ac6b1
> --- /dev/null
> +++ b/include/linux/mfd/rohm-bd73800.h
> @@ -0,0 +1,307 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright 2024 ROHM Semiconductors.
> + *
This is new to use. Please update this too.
> + * Author: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> + */
> +
> +#ifndef _MFD_BD73800_H
> +#define _MFD_BD73800_H
> +
> +#include <linux/regmap.h>
> +
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Hans de Goede @ 2026-07-09 13:22 UTC (permalink / raw)
To: Sudeep Holla
Cc: Bjorn Andersson, Cristian Marussi, Nathan Chancellor,
Nicolas Schier, Michael Turquette, arm-scmi, linux-arm-kernel,
linux-kernel, linux-kbuild, Stephen Boyd, Brian Masney,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <20260709-spicy-fiery-squid-6eec1d@sudeepholla>
Hi,
On 9-Jul-26 12:10, Sudeep Holla wrote:
> On Thu, Jun 18, 2026 at 10:31:12PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 18-Jun-26 17:56, Bjorn Andersson wrote:
>>> SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
>>> modules, but they are then not automatically loaded. Rework the SCMI
>>> device table alias support to make modpost consume the information from
>>> MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
>>> this information, if known. Also add a protocol-based alias to also
>>> trigger driver loading when only the SCMI protocol id is known.
>>>
>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>>
>> So I just gave this a test spin and unfortunately it does not work.
>>
>> The problem with Fedora's kernel-config / setup is that the
>> request_module() from patch 2/2 runs from the initramfs, but
>> the scmi_cpufreq module is only available in the rootfs.
>>
>> It does work if I explictly add the scmi_cpufreq module to
>> the initramfs, then it does get autoloaded.
>>
>> We really need some place to put a uevent sysfs attr which then
>> gets replayed when udev is restarted from the rootfs and then
>> re-reads all the uevent files as part of its coldplug
>> enumeration.
>>
>
> I don't have much knowledge on uevent to provide any suggestions/help.
> But isn't this a generic requirement ? I mean you could have modules
> install on the rootfs and not all of them are packed in initramfs ?
> Just wondering if that works for other modules, we can examine how
> do they work and what are we missing ?
scmi is special because the actual devices under /sys/bus/scmi/devices
only get created when the module with the driver is loaded because
of some funtion/id mapping requiring info from the driver.
Patch 2/2 tries to work around this by loading all scmi drivers matching
the scmi protocol which is known at bus enumeration time, but this only
works if the actual scmi driver is in the initramfs because this done
through directly calling modprobe() from the kernel which does not
get "replayed" when switching to the real rootfs.
And no /sys/bus/scmi/devices/xxx device means no
/sys/bus/scmi/devices/xxx/modalias nor /sys/bus/scmi/devices/xxx/uevent
which udev uses for coldplug (hotplug event replay) when switching to
the real root.
The cleanest way to fix this from a how things are supposed to work
according to the generic kernel device-model design is to get rid of
the creation of the devices being delayed. Which may mean moving some
static mapping tables from the driver into the scmi core. I'm not
familiar enough with the scmi bus code to be sure.
Regards,
Hans
>
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Brian Masney @ 2026-07-09 13:28 UTC (permalink / raw)
To: Hans de Goede
Cc: Sudeep Holla, Bjorn Andersson, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <dae4deba-7e5f-434e-80ae-89033bdeb793@oss.qualcomm.com>
Hi Hans,
On Thu, Jul 09, 2026 at 03:22:29PM +0200, Hans de Goede wrote:
> On 9-Jul-26 12:10, Sudeep Holla wrote:
> > On Thu, Jun 18, 2026 at 10:31:12PM +0200, Hans de Goede wrote:
> >> On 18-Jun-26 17:56, Bjorn Andersson wrote:
> >>> SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
> >>> modules, but they are then not automatically loaded. Rework the SCMI
> >>> device table alias support to make modpost consume the information from
> >>> MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
> >>> this information, if known. Also add a protocol-based alias to also
> >>> trigger driver loading when only the SCMI protocol id is known.
> >>>
> >>> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> >>
> >> So I just gave this a test spin and unfortunately it does not work.
> >>
> >> The problem with Fedora's kernel-config / setup is that the
> >> request_module() from patch 2/2 runs from the initramfs, but
> >> the scmi_cpufreq module is only available in the rootfs.
> >>
> >> It does work if I explictly add the scmi_cpufreq module to
> >> the initramfs, then it does get autoloaded.
> >>
> >> We really need some place to put a uevent sysfs attr which then
> >> gets replayed when udev is restarted from the rootfs and then
> >> re-reads all the uevent files as part of its coldplug
> >> enumeration.
> >>
> >
> > I don't have much knowledge on uevent to provide any suggestions/help.
> > But isn't this a generic requirement ? I mean you could have modules
> > install on the rootfs and not all of them are packed in initramfs ?
> > Just wondering if that works for other modules, we can examine how
> > do they work and what are we missing ?
>
> scmi is special because the actual devices under /sys/bus/scmi/devices
> only get created when the module with the driver is loaded because
> of some funtion/id mapping requiring info from the driver.
>
> Patch 2/2 tries to work around this by loading all scmi drivers matching
> the scmi protocol which is known at bus enumeration time, but this only
> works if the actual scmi driver is in the initramfs because this done
> through directly calling modprobe() from the kernel which does not
> get "replayed" when switching to the real rootfs.
Should the SCMI drivers be added to the dracut module here?
https://github.com/dracut-ng/dracut/blob/main/modules.d/70kernel-modules/module-setup.sh#L73
A few years ago we had to add the interconnect drivers to the list for
Fedora.
Brian
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Hans de Goede @ 2026-07-09 14:07 UTC (permalink / raw)
To: Brian Masney
Cc: Sudeep Holla, Bjorn Andersson, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <ak-h8oPcL69fCUg2@redhat.com>
Hi Brian,
On 9-Jul-26 15:28, Brian Masney wrote:
> Hi Hans,
>
> On Thu, Jul 09, 2026 at 03:22:29PM +0200, Hans de Goede wrote:
>> On 9-Jul-26 12:10, Sudeep Holla wrote:
>>> On Thu, Jun 18, 2026 at 10:31:12PM +0200, Hans de Goede wrote:
>>>> On 18-Jun-26 17:56, Bjorn Andersson wrote:
>>>>> SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
>>>>> modules, but they are then not automatically loaded. Rework the SCMI
>>>>> device table alias support to make modpost consume the information from
>>>>> MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
>>>>> this information, if known. Also add a protocol-based alias to also
>>>>> trigger driver loading when only the SCMI protocol id is known.
>>>>>
>>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>>>>
>>>> So I just gave this a test spin and unfortunately it does not work.
>>>>
>>>> The problem with Fedora's kernel-config / setup is that the
>>>> request_module() from patch 2/2 runs from the initramfs, but
>>>> the scmi_cpufreq module is only available in the rootfs.
>>>>
>>>> It does work if I explictly add the scmi_cpufreq module to
>>>> the initramfs, then it does get autoloaded.
>>>>
>>>> We really need some place to put a uevent sysfs attr which then
>>>> gets replayed when udev is restarted from the rootfs and then
>>>> re-reads all the uevent files as part of its coldplug
>>>> enumeration.
>>>>
>>>
>>> I don't have much knowledge on uevent to provide any suggestions/help.
>>> But isn't this a generic requirement ? I mean you could have modules
>>> install on the rootfs and not all of them are packed in initramfs ?
>>> Just wondering if that works for other modules, we can examine how
>>> do they work and what are we missing ?
>>
>> scmi is special because the actual devices under /sys/bus/scmi/devices
>> only get created when the module with the driver is loaded because
>> of some funtion/id mapping requiring info from the driver.
>>
>> Patch 2/2 tries to work around this by loading all scmi drivers matching
>> the scmi protocol which is known at bus enumeration time, but this only
>> works if the actual scmi driver is in the initramfs because this done
>> through directly calling modprobe() from the kernel which does not
>> get "replayed" when switching to the real rootfs.
>
> Should the SCMI drivers be added to the dracut module here?
>
> https://github.com/dracut-ng/dracut/blob/main/modules.d/70kernel-modules/module-setup.sh#L73
>
> A few years ago we had to add the interconnect drivers to the list for
> Fedora.
That would be one solution. I first want to understand the problem better
though. The scmi bus not creating the devices until the kmod with the driver
has loaded is weird. I wonder if we can just move a small part of the drivers
(some mapping table) into the bus code and then just have this work as it
does on regular busses. I hope to be able to make some time to look into
this soonish.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Sudeep Holla @ 2026-07-09 14:21 UTC (permalink / raw)
To: Hans de Goede
Cc: Brian Masney, Bjorn Andersson, Sudeep Holla, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <f05860be-dd75-49f8-b27a-bff7b554e71b@oss.qualcomm.com>
On Thu, Jul 09, 2026 at 04:07:17PM +0200, Hans de Goede wrote:
> Hi Brian,
>
> On 9-Jul-26 15:28, Brian Masney wrote:
> > Hi Hans,
> >
> > On Thu, Jul 09, 2026 at 03:22:29PM +0200, Hans de Goede wrote:
> >> On 9-Jul-26 12:10, Sudeep Holla wrote:
> >>> On Thu, Jun 18, 2026 at 10:31:12PM +0200, Hans de Goede wrote:
> >>>> On 18-Jun-26 17:56, Bjorn Andersson wrote:
> >>>>> SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
> >>>>> modules, but they are then not automatically loaded. Rework the SCMI
> >>>>> device table alias support to make modpost consume the information from
> >>>>> MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
> >>>>> this information, if known. Also add a protocol-based alias to also
> >>>>> trigger driver loading when only the SCMI protocol id is known.
> >>>>>
> >>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> >>>>
> >>>> So I just gave this a test spin and unfortunately it does not work.
> >>>>
> >>>> The problem with Fedora's kernel-config / setup is that the
> >>>> request_module() from patch 2/2 runs from the initramfs, but
> >>>> the scmi_cpufreq module is only available in the rootfs.
> >>>>
> >>>> It does work if I explictly add the scmi_cpufreq module to
> >>>> the initramfs, then it does get autoloaded.
> >>>>
> >>>> We really need some place to put a uevent sysfs attr which then
> >>>> gets replayed when udev is restarted from the rootfs and then
> >>>> re-reads all the uevent files as part of its coldplug
> >>>> enumeration.
> >>>>
> >>>
> >>> I don't have much knowledge on uevent to provide any suggestions/help.
> >>> But isn't this a generic requirement ? I mean you could have modules
> >>> install on the rootfs and not all of them are packed in initramfs ?
> >>> Just wondering if that works for other modules, we can examine how
> >>> do they work and what are we missing ?
> >>
> >> scmi is special because the actual devices under /sys/bus/scmi/devices
> >> only get created when the module with the driver is loaded because
> >> of some funtion/id mapping requiring info from the driver.
> >>
> >> Patch 2/2 tries to work around this by loading all scmi drivers matching
> >> the scmi protocol which is known at bus enumeration time, but this only
> >> works if the actual scmi driver is in the initramfs because this done
> >> through directly calling modprobe() from the kernel which does not
> >> get "replayed" when switching to the real rootfs.
> >
> > Should the SCMI drivers be added to the dracut module here?
> >
> > https://github.com/dracut-ng/dracut/blob/main/modules.d/70kernel-modules/module-setup.sh#L73
> >
> > A few years ago we had to add the interconnect drivers to the list for
> > Fedora.
>
> That would be one solution. I first want to understand the problem better
> though. The scmi bus not creating the devices until the kmod with the driver
> has loaded is weird.
I need to recall why we moved from static list of devices to dynamic.
One reason I can think right now is the vendor protocols and their drivers
But in general it was an attempt to help multiple drivers bind to different
scmi_devices that have same protocol ID. E.g. the performance protocol
can be used by cpufreq and devfreq/performance genpd drivers.
> I wonder if we can just move a small part of the drivers
> (some mapping table) into the bus code and then just have this work as it
> does on regular busses. I hope to be able to make some time to look into
> this soonish.
>
I started with that few years ago and we then moved to this dynamic
device creation. But I agree if it is deviation from the norms(which I
wasn't aware of at the time), we can remove it.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Hans de Goede @ 2026-07-09 14:31 UTC (permalink / raw)
To: Sudeep Holla
Cc: Brian Masney, Bjorn Andersson, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <20260709-exuberant-galago-of-spirit-1c908f@sudeepholla>
Hi,
On 9-Jul-26 16:21, Sudeep Holla wrote:
> On Thu, Jul 09, 2026 at 04:07:17PM +0200, Hans de Goede wrote:
>> Hi Brian,
>>
>> On 9-Jul-26 15:28, Brian Masney wrote:
>>> Hi Hans,
>>>
>>> On Thu, Jul 09, 2026 at 03:22:29PM +0200, Hans de Goede wrote:
>>>> On 9-Jul-26 12:10, Sudeep Holla wrote:
>>>>> On Thu, Jun 18, 2026 at 10:31:12PM +0200, Hans de Goede wrote:
>>>>>> On 18-Jun-26 17:56, Bjorn Andersson wrote:
>>>>>>> SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
>>>>>>> modules, but they are then not automatically loaded. Rework the SCMI
>>>>>>> device table alias support to make modpost consume the information from
>>>>>>> MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
>>>>>>> this information, if known. Also add a protocol-based alias to also
>>>>>>> trigger driver loading when only the SCMI protocol id is known.
>>>>>>>
>>>>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>>>>>>
>>>>>> So I just gave this a test spin and unfortunately it does not work.
>>>>>>
>>>>>> The problem with Fedora's kernel-config / setup is that the
>>>>>> request_module() from patch 2/2 runs from the initramfs, but
>>>>>> the scmi_cpufreq module is only available in the rootfs.
>>>>>>
>>>>>> It does work if I explictly add the scmi_cpufreq module to
>>>>>> the initramfs, then it does get autoloaded.
>>>>>>
>>>>>> We really need some place to put a uevent sysfs attr which then
>>>>>> gets replayed when udev is restarted from the rootfs and then
>>>>>> re-reads all the uevent files as part of its coldplug
>>>>>> enumeration.
>>>>>>
>>>>>
>>>>> I don't have much knowledge on uevent to provide any suggestions/help.
>>>>> But isn't this a generic requirement ? I mean you could have modules
>>>>> install on the rootfs and not all of them are packed in initramfs ?
>>>>> Just wondering if that works for other modules, we can examine how
>>>>> do they work and what are we missing ?
>>>>
>>>> scmi is special because the actual devices under /sys/bus/scmi/devices
>>>> only get created when the module with the driver is loaded because
>>>> of some funtion/id mapping requiring info from the driver.
>>>>
>>>> Patch 2/2 tries to work around this by loading all scmi drivers matching
>>>> the scmi protocol which is known at bus enumeration time, but this only
>>>> works if the actual scmi driver is in the initramfs because this done
>>>> through directly calling modprobe() from the kernel which does not
>>>> get "replayed" when switching to the real rootfs.
>>>
>>> Should the SCMI drivers be added to the dracut module here?
>>>
>>> https://github.com/dracut-ng/dracut/blob/main/modules.d/70kernel-modules/module-setup.sh#L73
>>>
>>> A few years ago we had to add the interconnect drivers to the list for
>>> Fedora.
>>
>> That would be one solution. I first want to understand the problem better
>> though. The scmi bus not creating the devices until the kmod with the driver
>> has loaded is weird.
>
> I need to recall why we moved from static list of devices to dynamic.
> One reason I can think right now is the vendor protocols and their drivers
> But in general it was an attempt to help multiple drivers bind to different
> scmi_devices that have same protocol ID. E.g. the performance protocol
> can be used by cpufreq and devfreq/performance genpd drivers.
Note it is ok to have multiple drivers bind to the same modalias,
depending on the reason why there are multiple drivers either one
should detect that it is not compatible and exit probe() with -ENODEV
or there should be some other mechanism to make sure only one driver
loads.
E.g. duplicate USB device-ids happen (they shouldn't but they do) and
then the drivers typically figure out if they are talking to the device
which they were written for, or the other device with the same USB-ids
and then one of the 2 drivers exits with -ENODEV.
>> I wonder if we can just move a small part of the drivers
>> (some mapping table) into the bus code and then just have this work as it
>> does on regular busses. I hope to be able to make some time to look into
>> this soonish.
>>
>
> I started with that few years ago and we then moved to this dynamic
> device creation. But I agree if it is deviation from the norms(which I
> wasn't aware of at the time), we can remove it.
Looking at the issue this is causing for automatic module loading if we
can get back to the bus enumeration code always creating a device without
waiting for the driver kmod to load then that would be good IMHO.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Sudeep Holla @ 2026-07-09 14:37 UTC (permalink / raw)
To: Hans de Goede
Cc: Brian Masney, Bjorn Andersson, Sudeep Holla, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <5fb236b7-7b99-40fb-b80b-fa7e1dfccd70@oss.qualcomm.com>
On Thu, Jul 09, 2026 at 04:31:00PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9-Jul-26 16:21, Sudeep Holla wrote:
[...]
> >
> > I need to recall why we moved from static list of devices to dynamic.
> > One reason I can think right now is the vendor protocols and their drivers
> > But in general it was an attempt to help multiple drivers bind to different
> > scmi_devices that have same protocol ID. E.g. the performance protocol
> > can be used by cpufreq and devfreq/performance genpd drivers.
>
> Note it is ok to have multiple drivers bind to the same modalias,
> depending on the reason why there are multiple drivers either one
> should detect that it is not compatible and exit probe() with -ENODEV
> or there should be some other mechanism to make sure only one driver
> loads.
>
> E.g. duplicate USB device-ids happen (they shouldn't but they do) and
> then the drivers typically figure out if they are talking to the device
> which they were written for, or the other device with the same USB-ids
> and then one of the 2 drivers exits with -ENODEV.
>
Understood. Sorry I tried to explain with examples assuming you may not
be aware of the details, but now reading your response, you have better
examples.
> >> I wonder if we can just move a small part of the drivers
> >> (some mapping table) into the bus code and then just have this work as it
> >> does on regular busses. I hope to be able to make some time to look into
> >> this soonish.
> >>
> >
> > I started with that few years ago and we then moved to this dynamic
> > device creation. But I agree if it is deviation from the norms(which I
> > wasn't aware of at the time), we can remove it.
>
> Looking at the issue this is causing for automatic module loading if we
> can get back to the bus enumeration code always creating a device without
> waiting for the driver kmod to load then that would be good IMHO.
>
Sure if it fixes the issue for you. Cristian can point out anything I
might have missed to consider as he is the one who reworked it and made
it dynamic device creation which at the time sounded nice option to
solve the issue. We weren't aware that it could cause such issues 🙁.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Hans de Goede @ 2026-07-09 14:49 UTC (permalink / raw)
To: Sudeep Holla
Cc: Brian Masney, Bjorn Andersson, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <20260709-exuberant-narwhal-of-correction-7f4650@sudeepholla>
Hi,
On 9-Jul-26 16:37, Sudeep Holla wrote:
> On Thu, Jul 09, 2026 at 04:31:00PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 9-Jul-26 16:21, Sudeep Holla wrote:
> [...]
>>>
>>> I need to recall why we moved from static list of devices to dynamic.
>>> One reason I can think right now is the vendor protocols and their drivers
>>> But in general it was an attempt to help multiple drivers bind to different
>>> scmi_devices that have same protocol ID. E.g. the performance protocol
>>> can be used by cpufreq and devfreq/performance genpd drivers.
>>
>> Note it is ok to have multiple drivers bind to the same modalias,
>> depending on the reason why there are multiple drivers either one
>> should detect that it is not compatible and exit probe() with -ENODEV
>> or there should be some other mechanism to make sure only one driver
>> loads.
>>
>> E.g. duplicate USB device-ids happen (they shouldn't but they do) and
>> then the drivers typically figure out if they are talking to the device
>> which they were written for, or the other device with the same USB-ids
>> and then one of the 2 drivers exits with -ENODEV.
>>
>
> Understood. Sorry I tried to explain with examples assuming you may not
> be aware of the details, but now reading your response, you have better
> examples.
>
>>>> I wonder if we can just move a small part of the drivers
>>>> (some mapping table) into the bus code and then just have this work as it
>>>> does on regular busses. I hope to be able to make some time to look into
>>>> this soonish.
>>>>
>>>
>>> I started with that few years ago and we then moved to this dynamic
>>> device creation. But I agree if it is deviation from the norms(which I
>>> wasn't aware of at the time), we can remove it.
>>
>> Looking at the issue this is causing for automatic module loading if we
>> can get back to the bus enumeration code always creating a device without
>> waiting for the driver kmod to load then that would be good IMHO.
>>
>
> Sure if it fixes the issue for you. Cristian can point out anything I
> might have missed to consider as he is the one who reworked it and made
> it dynamic device creation which at the time sounded nice option to
> solve the issue. We weren't aware that it could cause such issues 🙁.
Note that before patch 1/2 of this series we did not have working
module-autoloading for SCMI modules at all. With that said yes it would
be nice to get this working.
Can you provide a patch for this to try ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Cristian Marussi @ 2026-07-09 15:49 UTC (permalink / raw)
To: Sudeep Holla
Cc: Hans de Goede, Brian Masney, Bjorn Andersson, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <20260709-exuberant-narwhal-of-correction-7f4650@sudeepholla>
On Thu, Jul 09, 2026 at 03:37:33PM +0100, Sudeep Holla wrote:
> On Thu, Jul 09, 2026 at 04:31:00PM +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 9-Jul-26 16:21, Sudeep Holla wrote:
> [...]
> > >
> > > I need to recall why we moved from static list of devices to dynamic.
> > > One reason I can think right now is the vendor protocols and their drivers
> > > But in general it was an attempt to help multiple drivers bind to different
> > > scmi_devices that have same protocol ID. E.g. the performance protocol
> > > can be used by cpufreq and devfreq/performance genpd drivers.
> >
> > Note it is ok to have multiple drivers bind to the same modalias,
> > depending on the reason why there are multiple drivers either one
> > should detect that it is not compatible and exit probe() with -ENODEV
> > or there should be some other mechanism to make sure only one driver
> > loads.
> >
> > E.g. duplicate USB device-ids happen (they shouldn't but they do) and
> > then the drivers typically figure out if they are talking to the device
> > which they were written for, or the other device with the same USB-ids
> > and then one of the 2 drivers exits with -ENODEV.
> >
>
> Understood. Sorry I tried to explain with examples assuming you may not
> be aware of the details, but now reading your response, you have better
> examples.
>
> > >> I wonder if we can just move a small part of the drivers
> > >> (some mapping table) into the bus code and then just have this work as it
> > >> does on regular busses. I hope to be able to make some time to look into
> > >> this soonish.
> > >>
> > >
> > > I started with that few years ago and we then moved to this dynamic
> > > device creation. But I agree if it is deviation from the norms(which I
> > > wasn't aware of at the time), we can remove it.
> >
> > Looking at the issue this is causing for automatic module loading if we
> > can get back to the bus enumeration code always creating a device without
> > waiting for the driver kmod to load then that would be good IMHO.
> >
>
> Sure if it fixes the issue for you. Cristian can point out anything I
> might have missed to consider as he is the one who reworked it and made
> it dynamic device creation which at the time sounded nice option to
> solve the issue. We weren't aware that it could cause such issues 🙁.
>
The reason for the awkward mechanism of dynamic device creation AFAICR
was an explicit request by Qualcomm (via its Linaro landing team at
that time) for the generic vendor module suppport that I was adding to
be fully self-contained: so that you can write your own protocol and
add the DT node and that's it, without the need to patch some centrally
maintained table in the core SCMI stack to add your new vendor protocol.
Not saying that it was necesarily a good idea to allow that, but that
was the origin of this....as far as I can remember....together with the
fact that the internal interfaces were reworked to be absolutely the
same for standard protocols and vendor protocols...
I thought that the current situation was that auto-loading was working
for vendor protocols (this autoload issue appeared at first for vendors
protocols one year ago) then I had made this hacky attempt to make it
work for standard protocols by forcibly emitting a uevent for all known
standard protos:
https://lore.kernel.org/arm-scmi/20250203100154.140877-2-cristian.marussi@arm.com/
...but that was clearly not the proper way..and all the rework was
dropped...
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Sudeep Holla @ 2026-07-09 15:54 UTC (permalink / raw)
To: Hans de Goede
Cc: Brian Masney, Bjorn Andersson, Cristian Marussi, Sudeep Holla,
Nathan Chancellor, Nicolas Schier, Michael Turquette, arm-scmi,
linux-arm-kernel, linux-kernel, linux-kbuild, Stephen Boyd,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <158aa658-3109-4b7e-8213-1cc2cbd5aeb5@oss.qualcomm.com>
On Thu, Jul 09, 2026 at 04:49:18PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9-Jul-26 16:37, Sudeep Holla wrote:
> > On Thu, Jul 09, 2026 at 04:31:00PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 9-Jul-26 16:21, Sudeep Holla wrote:
> > [...]
> >>>
> >>> I need to recall why we moved from static list of devices to dynamic.
> >>> One reason I can think right now is the vendor protocols and their drivers
> >>> But in general it was an attempt to help multiple drivers bind to different
> >>> scmi_devices that have same protocol ID. E.g. the performance protocol
> >>> can be used by cpufreq and devfreq/performance genpd drivers.
> >>
> >> Note it is ok to have multiple drivers bind to the same modalias,
> >> depending on the reason why there are multiple drivers either one
> >> should detect that it is not compatible and exit probe() with -ENODEV
> >> or there should be some other mechanism to make sure only one driver
> >> loads.
> >>
> >> E.g. duplicate USB device-ids happen (they shouldn't but they do) and
> >> then the drivers typically figure out if they are talking to the device
> >> which they were written for, or the other device with the same USB-ids
> >> and then one of the 2 drivers exits with -ENODEV.
> >>
> >
> > Understood. Sorry I tried to explain with examples assuming you may not
> > be aware of the details, but now reading your response, you have better
> > examples.
> >
> >>>> I wonder if we can just move a small part of the drivers
> >>>> (some mapping table) into the bus code and then just have this work as it
> >>>> does on regular busses. I hope to be able to make some time to look into
> >>>> this soonish.
> >>>>
> >>>
> >>> I started with that few years ago and we then moved to this dynamic
> >>> device creation. But I agree if it is deviation from the norms(which I
> >>> wasn't aware of at the time), we can remove it.
> >>
> >> Looking at the issue this is causing for automatic module loading if we
> >> can get back to the bus enumeration code always creating a device without
> >> waiting for the driver kmod to load then that would be good IMHO.
> >>
> >
> > Sure if it fixes the issue for you. Cristian can point out anything I
> > might have missed to consider as he is the one who reworked it and made
> > it dynamic device creation which at the time sounded nice option to
> > solve the issue. We weren't aware that it could cause such issues 🙁.
>
> Note that before patch 1/2 of this series we did not have working
> module-autoloading for SCMI modules at all. With that said yes it would
> be nice to get this working.
>
> Can you provide a patch for this to try ?
>
Not sure what exactly are you asking, but I don't have anything w.r.t
the discussion handy to share. The codebase has moved a lot to revert
just the dynamic creation addition patch unfortunately.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v3] dt-bindings: rtc: Convert rtc-cmos binding to YAML
From: Teja Sai Charan B @ 2026-07-09 22:19 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-rtc, devicetree, linux-kernel, Teja Sai Charan Bellamkonda
From: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
Convert the rtc-cmos devicetree bindings to dt schema.
The original text binding documents only the motorola,mc146818
compatible. Existing in-tree Devicetree sources also use the
intel,ce4100-rtc compatible together with the motorola,mc146818
fallback, but this was not documented. Document the Intel variant in the
schema so that these existing configurations are accepted during schema
validation.
Signed-off-by: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
---
Changes in v2:
- Allow intel,ce4100-rtc compatible used by existing DTS files
Changes in v3:
- Drop accidentally added result.txt
- Fix example unit-address to match reg property
---
.../devicetree/bindings/rtc/rtc-cmos.txt | 27 --------
.../devicetree/bindings/rtc/rtc-cmos.yaml | 63 +++++++++++++++++++
2 files changed, 63 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/rtc-cmos.txt
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
deleted file mode 100644
index 7d7b5f6bda65..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
+++ /dev/null
@@ -1,27 +0,0 @@
- Motorola mc146818 compatible RTC
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Required properties:
- - compatible : "motorola,mc146818"
- - reg : should contain registers location and length.
-
-Optional properties:
- - interrupts : should contain interrupt.
- - ctrl-reg : Contains the initial value of the control register also
- called "Register B".
- - freq-reg : Contains the initial value of the frequency register also
- called "Register A".
-
-"Register A" and "B" are usually initialized by the firmware (BIOS for
-instance). If this is not done, it can be performed by the driver.
-
-ISA Example:
-
- rtc@70 {
- compatible = "motorola,mc146818";
- interrupts = <8 3>;
- interrupt-parent = <&ioapic1>;
- ctrl-reg = <2>;
- freq-reg = <0x26>;
- reg = <1 0x70 2>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml b/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
new file mode 100644
index 000000000000..e37927e9916c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/rtc-cmos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola mc146818 compatible RTC
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: motorola,mc146818
+
+ - items:
+ - const: intel,ce4100-rtc
+ - const: motorola,mc146818
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ctrl-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Initial value of the control register
+ (also known as Register B).
+
+ freq-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Initial value of the frequency register
+ (also known as Register A).
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: rtc.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ rtc@1,70 {
+ compatible = "motorola,mc146818";
+ reg = <0x1 0x70 0x2>;
+
+ interrupts = <8 3>;
+
+ ctrl-reg = <2>;
+ freq-reg = <0x26>;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3] dt-bindings: rtc: Convert rtc-cmos binding to YAML
From: sashiko-bot @ 2026-07-09 22:25 UTC (permalink / raw)
To: Teja Sai Charan B
Cc: conor+dt, Alexandre Belloni, robh, linux-rtc, devicetree
In-Reply-To: <20260709221944.159244-1-tejaasaye@gmail.com>
> From: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
>
> Convert the rtc-cmos devicetree bindings to dt schema.
>
> The original text binding documents only the motorola,mc146818
> compatible. Existing in-tree Devicetree sources also use the
> intel,ce4100-rtc compatible together with the motorola,mc146818
> fallback, but this was not documented. Document the Intel variant in the
> schema so that these existing configurations are accepted during schema
> validation.
>
> Signed-off-by: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260709221944.159244-1-tejaasaye@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: rtc: Convert rtc-cmos binding to YAML
From: Krzysztof Kozlowski @ 2026-07-10 10:04 UTC (permalink / raw)
To: Teja Sai Charan B
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rtc, devicetree, linux-kernel
In-Reply-To: <20260709221944.159244-1-tejaasaye@gmail.com>
On Fri, Jul 10, 2026 at 03:49:44AM +0530, Teja Sai Charan B wrote:
> From: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
>
> Convert the rtc-cmos devicetree bindings to dt schema.
>
> The original text binding documents only the motorola,mc146818
> compatible. Existing in-tree Devicetree sources also use the
> intel,ce4100-rtc compatible together with the motorola,mc146818
> fallback, but this was not documented. Document the Intel variant in the
> schema so that these existing configurations are accepted during schema
> validation.
>
> Signed-off-by: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox