* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Alvin Sun @ 2026-02-21 16:32 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Danilo Krummrich, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Greg Kroah-Hartman,
Rafael J. Wysocki
In-Reply-To: <20260221111619162a41a1@mail.local>
On 2/21/26 19:16, Alexandre Belloni wrote:
> On 21/02/2026 17:31:09+0800, Alvin Sun wrote:
>> As in platform.rs [1] and i2c.rs [2], set_drvdata is always called by
>> the bus Adapter's probe_callback, not by the device driver.
>>
>> [1]:
>> https://elixir.bootlin.com/linux/v6.19-rc5/source/rust/kernel/platform.rs#L80
>> [2]:
>> https://elixir.bootlin.com/linux/v6.19-rc5/source/rust/kernel/i2c.rs#L160
>>
>> In Rust the Adapter already sets drvdata on the bus device in probe. If
>> the driver also calls amba_set_drvdata() there, it overwrites that
>> pointer; on remove/shutdown the framework then gets wrong data and can
>> hit use-after-free or crashes. So only the framework must set drvdata
>> on the bus device.
> But this is wrong, how do you then handle the class device on
> suspend/resume or on .remove?
There is a patch adding runtime PM for Tyr (platform device driver):
https://gitlab.freedesktop.org/panfrost/linux/-/merge_requests/60/diffs#dbdd2c5024317f2c80128c91a823e224b3a41550_240_256
If you are interested in adding Rust support for RTC, We can do some
research on top of it for RTC Rust drivers.
>
>> This applies only to the Rust implementation; in C, calling
>> amba_set_drvdata() is fine. In the Rust design the bus device owns the
>> bus device's drvdata and the class device owns the class device's
>> drvdata, so the class driver must not set drvdata on the bus device.
>>
>> This is my understanding of the Rust device driver abstraction design.
>> Danilo is the authority on this.
>>
>> Best regards,
>> Ke Sun
>>
>>> Out of 29 drivers, 18 are doing so.
>>>
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Danilo Krummrich @ 2026-02-21 14:33 UTC (permalink / raw)
To: Rafael J. Wysocki, Alexandre Belloni, Alvin Sun
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux, Greg Kroah-Hartman
In-Reply-To: <CAJZ5v0jo2sLKWVOBJz7QP9x_aMZbaVx+ES7QwYWkTzHp7d2xLQ@mail.gmail.com>
On Sat Feb 21, 2026 at 12:19 PM CET, Rafael J. Wysocki wrote:
> On Sat, Feb 21, 2026 at 12:16 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
>> > > Out of 29 drivers, 18 are doing so.
>
> The vast majority of around 50 platform drivers I've inspected
> recently use platform_set_drvdata() or equivalent in probe.
This thread seems to contain quite a bit of confusion and misunderstandings --
let me try to clarify.
(1) How Rust handles bus device private data.
In Rust the probe() function of a bus implementation (platform, PCI, etc.)
returns an initializer (impl PinInit<T, Error>) for the driver's device
private data.
The bus implementation takes this initializer and passes it (together with the
underlying struct device) to the driver-core. The driver-core allocates the
required memory, initializes the memory with the given initializer and stores
a pointer to the corresponding object with dev_set_drvdata().
So, technically, in Rust all platform drivers call platform_set_drvdata().
(Note that this is also true when the driver's device private data type is
empty (i.e. it has no fields). In this case it could still have a destructor
that must be called when the device private data structure is destroyed. Of
course there is no real memory allocation when the struct's size is zero.)
The driver's device private data can only be accessed when the bus device is
bound to the driver, i.e. the driver can only access it with a &Device<Bound>;
it (the driver's device private data) is automatically freed by the
driver-core when remove() and all devres callbacks have been completed.
I.e. the rules are - of course - the same as on the C side, but they are
enforced by the type system and the driver-core code.
(2) Bus device private data vs. class device private data.
The change to pass a struct rtc_device in class device callbacks of RTC,
rather than the base struct device of the corresponding bus device (e.g. AMBA,
platform, etc.) should not aim at storing all data in rtc->dev.private_data
that was previously stored in rtc->dev.parent->private_data.
Instead, it gives drivers the option to differentiate in terms of ownership
and lifetime.
While the bus device private data has a very defined lifetime from probe()
until the device is unbound from the driver, class device private data might
live shorter than this, or might even out-live driver unbind in some cases. It
really depends on the lifetime of the class device itself, which is not
generally defined.
Now, from a C side point of view this may not look like a big deal, as it
(unfortunately) is not that uncommon that struct fields are just initialized
and destroyed whenever needed and the code just takes it into account.
But at the same time, this is what leads to a lot of lifetime problems and
memory bugs and it is one of those things that Rust aims at avoiding by being
very strict about initialization, ownership and lifetimes.
However, I do also recognize that drivers creating an RTC device are typically
very simple and in practice I would not be surprised if it turns out that it
happens that drivers keep the struct rtc_device alive from probe() until the
bus device is unbound from the driver, i.e. lifetimes just end up being almost
the same. But I don't know if that's always the case.
Regardless of that, I think it would be good to keep driver authors finding a
common pattern, where class device callbacks carry the corresponding class
device struct (instead of the parent base struct device).
Especially on the Rust side we now have the chance to make the experience of
writing drivers as consistent as possible, which should help (new) driver
authors a lot in terms of learning the driver lifetime patterns.
I hope this helps.
- Danilo
^ permalink raw reply
* Re: [PATCH RFC 10/10] kobject: make struct kobject member default_groups a constant array
From: Heiner Kallweit @ 2026-02-21 14:04 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Jason Gunthorpe, Leon Romanovsky, Alexandre Belloni, driver-core,
Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <f18e8c2f-28b0-4905-87c2-a16dd54c53d1@t-8ch.de>
On 21.02.2026 14:27, Thomas Weißschuh wrote:
> Hello Heiner,
>
> On 2026-02-17 23:32:46+0100, Heiner Kallweit wrote:
>> Constify the default_groups array, allowing to assign constant arrays.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> (The patch author/From header and Signed-off-by line do not match)
>
Right, have to fix this once series is out of RFC state.
>> ---
>> include/linux/kobject.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
>> index c8219505a79..e45ee843931 100644
>> --- a/include/linux/kobject.h
>> +++ b/include/linux/kobject.h
>> @@ -116,7 +116,7 @@ char *kobject_get_path(const struct kobject *kobj, gfp_t flag);
>> struct kobj_type {
>> void (*release)(struct kobject *kobj);
>> const struct sysfs_ops *sysfs_ops;
>> - const struct attribute_group **default_groups;
>> + const struct attribute_group *const *default_groups;
>
> Thanks for working on this!
>
> Personally I try to constify the attribute structures together with
> their corresponding callbacks. This ensures that no structure is
> constified which its callback then tries to modify.
> Currently there is no support for const arguments to the callbacks of
> 'struct kobj_attribute' and 'struct device_attribute'. I am wondering
> if the changes to kobject and device groups should be kept out for now
> and be added together with the support for their const callback arguments.
>
I think we have to be precise what exactly gets constified:
In the series here it's about arrays of pointers to attribute groups.
Just these arrays can't be modified any longer. This includes no change
to whether data in the attribute groups and attributes can be modified.
These arrays of pointers to attribute groups are used in calls to
sysfs_create_groups() and device_add_groups(), e.g. from create_dir()
for kobject's, and from device_add_attrs().
And sysfs_create_groups() and device_add_groups() are changed accordingly
in this series.
Does this answer your question?
>
> Thomas
>
>> const struct kobj_ns_type_operations *(*child_ns_type)(const struct kobject *kobj);
>> const void *(*namespace)(const struct kobject *kobj);
>> void (*get_ownership)(const struct kobject *kobj, kuid_t *uid, kgid_t *gid);
^ permalink raw reply
* Re: [PATCH RFC 10/10] kobject: make struct kobject member default_groups a constant array
From: Thomas Weißschuh @ 2026-02-21 13:27 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Jason Gunthorpe, Leon Romanovsky, Alexandre Belloni, driver-core,
Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <04c85242-dc51-4ddf-9920-4dab57f2498f@kernel.org>
Hello Heiner,
On 2026-02-17 23:32:46+0100, Heiner Kallweit wrote:
> Constify the default_groups array, allowing to assign constant arrays.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
(The patch author/From header and Signed-off-by line do not match)
> ---
> include/linux/kobject.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index c8219505a79..e45ee843931 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -116,7 +116,7 @@ char *kobject_get_path(const struct kobject *kobj, gfp_t flag);
> struct kobj_type {
> void (*release)(struct kobject *kobj);
> const struct sysfs_ops *sysfs_ops;
> - const struct attribute_group **default_groups;
> + const struct attribute_group *const *default_groups;
Thanks for working on this!
Personally I try to constify the attribute structures together with
their corresponding callbacks. This ensures that no structure is
constified which its callback then tries to modify.
Currently there is no support for const arguments to the callbacks of
'struct kobj_attribute' and 'struct device_attribute'. I am wondering
if the changes to kobject and device groups should be kept out for now
and be added together with the support for their const callback arguments.
Thomas
> const struct kobj_ns_type_operations *(*child_ns_type)(const struct kobject *kobj);
> const void *(*namespace)(const struct kobject *kobj);
> void (*get_ownership)(const struct kobject *kobj, kuid_t *uid, kgid_t *gid);
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Rafael J. Wysocki @ 2026-02-21 11:19 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Alvin Sun, Danilo Krummrich, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Greg Kroah-Hartman,
Rafael J. Wysocki
In-Reply-To: <20260221111619162a41a1@mail.local>
On Sat, Feb 21, 2026 at 12:16 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 21/02/2026 17:31:09+0800, Alvin Sun wrote:
> > As in platform.rs [1] and i2c.rs [2], set_drvdata is always called by
> > the bus Adapter's probe_callback, not by the device driver.
> >
> > [1]:
> > https://elixir.bootlin.com/linux/v6.19-rc5/source/rust/kernel/platform.rs#L80
> > [2]:
> > https://elixir.bootlin.com/linux/v6.19-rc5/source/rust/kernel/i2c.rs#L160
> >
> > In Rust the Adapter already sets drvdata on the bus device in probe. If
> > the driver also calls amba_set_drvdata() there, it overwrites that
> > pointer; on remove/shutdown the framework then gets wrong data and can
> > hit use-after-free or crashes. So only the framework must set drvdata
> > on the bus device.
>
> But this is wrong, how do you then handle the class device on
> suspend/resume or on .remove?
>
> >
> > This applies only to the Rust implementation; in C, calling
> > amba_set_drvdata() is fine. In the Rust design the bus device owns the
> > bus device's drvdata and the class device owns the class device's
> > drvdata, so the class driver must not set drvdata on the bus device.
> >
> > This is my understanding of the Rust device driver abstraction design.
> > Danilo is the authority on this.
> >
> > Best regards,
> > Ke Sun
> >
> > > Out of 29 drivers, 18 are doing so.
+1
The vast majority of around 50 platform drivers I've inspected
recently use platform_set_drvdata() or equivalent in probe.
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Alexandre Belloni @ 2026-02-21 11:16 UTC (permalink / raw)
To: Alvin Sun
Cc: Danilo Krummrich, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Greg Kroah-Hartman,
Rafael J. Wysocki
In-Reply-To: <d1c9e33b-e1f3-41c6-af5e-a85fe2b86d10@linux.dev>
On 21/02/2026 17:31:09+0800, Alvin Sun wrote:
> As in platform.rs [1] and i2c.rs [2], set_drvdata is always called by
> the bus Adapter's probe_callback, not by the device driver.
>
> [1]:
> https://elixir.bootlin.com/linux/v6.19-rc5/source/rust/kernel/platform.rs#L80
> [2]:
> https://elixir.bootlin.com/linux/v6.19-rc5/source/rust/kernel/i2c.rs#L160
>
> In Rust the Adapter already sets drvdata on the bus device in probe. If
> the driver also calls amba_set_drvdata() there, it overwrites that
> pointer; on remove/shutdown the framework then gets wrong data and can
> hit use-after-free or crashes. So only the framework must set drvdata
> on the bus device.
But this is wrong, how do you then handle the class device on
suspend/resume or on .remove?
>
> This applies only to the Rust implementation; in C, calling
> amba_set_drvdata() is fine. In the Rust design the bus device owns the
> bus device's drvdata and the class device owns the class device's
> drvdata, so the class driver must not set drvdata on the bus device.
>
> This is my understanding of the Rust device driver abstraction design.
> Danilo is the authority on this.
>
> Best regards,
> Ke Sun
>
> > Out of 29 drivers, 18 are doing so.
> >
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: rtc: isl12026: convert to YAML schema
From: Krzysztof Kozlowski @ 2026-02-21 10:22 UTC (permalink / raw)
To: Piyush Patle
Cc: Alexandre Belloni, robh, krzk+dt, conor+dt, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <20260220084723.171639-1-piyushpatle228@gmail.com>
On Fri, Feb 20, 2026 at 02:17:23PM +0530, Piyush Patle wrote:
> Convert the ISL12026 RTC binding from text format to YAML schema.
> Remove the legacy text binding.
>
> The new schema enables dtbs_check validation.
> ---
> Changes in v2:
> - Fixed schema validation issues pointed out in review
> - Improved example node formatting
> - Removed redundant description text
>
> ---
> Changes in v3:
> - Dropped unnecessary block scalar ('|') in description
> - Removed unsupported select section to match existing RTC bindings
Where?
> - Aligned schema structure with other RTC YAML bindings
> - Fixed YAML formatting and dt_binding_check errors
>
> Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Alvin Sun @ 2026-02-21 9:31 UTC (permalink / raw)
To: Alexandre Belloni, Danilo Krummrich
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux, Greg Kroah-Hartman, Rafael J. Wysocki
In-Reply-To: <20260220225341c5eeb835@mail.local>
On 2/21/26 06:53, Alexandre Belloni wrote:
> On 20/01/2026 16:01:40+0800, Ke Sun wrote:
>> On 1/19/26 22:32, Danilo Krummrich wrote:
>>> On Fri Jan 16, 2026 at 5:21 PM CET, Ke Sun wrote:
>>>> diff --git a/drivers/rtc/dev.c b/drivers/rtc/dev.c
>>>> index baf1a8ca8b2b1..eddcc5a69db3b 100644
>>>> --- a/drivers/rtc/dev.c
>>>> +++ b/drivers/rtc/dev.c
>>>> @@ -410,7 +410,7 @@ static long rtc_dev_ioctl(struct file *file,
>>>> }
>>>> default:
>>>> if (rtc->ops->param_get)
>>>> - err = rtc->ops->param_get(rtc->dev.parent, ¶m);
>>>> + err = rtc->ops->param_get(rtc_ops_dev(rtc), ¶m);
>>>> else
>>>> err = -EINVAL;
>>>> }
>>> <snip>
>>>
>>>> +/**
>>>> + * rtc_ops_dev - Get the device pointer for RTC ops callbacks
>>>> + * @rtc: RTC device
>>>> + *
>>>> + * Returns &rtc->dev if RTC_OPS_USE_RTC_DEV flag is set,
>>>> + * otherwise returns rtc->dev.parent.
>>>> + */
>>>> +static inline struct device *rtc_ops_dev(struct rtc_device *rtc)
>>>> +{
>>>> + if (test_bit(RTC_OPS_USE_RTC_DEV, &rtc->flags))
>>>> + return &rtc->dev;
>>>> + return rtc->dev.parent;
>>>> +}
>>> I understand that the idea is to gradually convert all drivers to use the RTC
>>> device, rather than it's parent device in RTC device callbacks.
>>>
>>> My main concern is that once that has been achieved it's still not what we want
>>> to have eventually, i.e. RTC device callbacks should ideally take a struct
>>> rtc_device as argument and not the embedded base struct device.
>>>
>>> I.e. we'd kick off a conversion process that won't reach the actual desired
>>> state.
>> Hi Danilo,
>>
>> This is indeed an intermediate step.
>>
>> Full cleanup is in progress, but it's large and untested. I'm working on a
>> complete cleanup involving ~190+ files across arch/, drivers/rtc/, and
>> drivers/virtio/. Most changes are straightforward interface replacements,
>> but some drivers need additional modifications. Given the scale, I haven't
>> fully tested everything and can't guarantee correctness yet.
>>
>> The intermediate step enables gradual migration, allowing us to:
>> - Clean up and test each rtc driver incrementally
>> - Ensure correctness through gradual changes
>> - Avoid breaking existing functionality
>>
>> Once all cleanup is complete and tested, changing all rtc_class_ops
>> callbacks to use struct rtc_device * will be much simpler and safer.
>>
>> Currently there seem to be only these two approaches. I'm still waiting
>> for Alexandre's suggestion on how to proceed specifically, but haven't
>> received a response yet.
> I'm sorry, I still don't see the point of doing this. The driver will
> almost always need to set its driver data in the parent device because
> we need to be able to handle interrupts, suspend/resume or .remove(). So
> while intellectually, this would be more satisfying to have the
> callbacks take a struct rtc_device, functionally this doesn't have any
> purpose because we need to use the parent drvdata anyway.
>
> Said differently, you should explain why a device driver must not call
> amba_set_drvdata() ?
As in platform.rs [1] and i2c.rs [2], set_drvdata is always called by
the bus Adapter's probe_callback, not by the device driver.
[1]:
https://elixir.bootlin.com/linux/v6.19-rc5/source/rust/kernel/platform.rs#L80
[2]:
https://elixir.bootlin.com/linux/v6.19-rc5/source/rust/kernel/i2c.rs#L160
In Rust the Adapter already sets drvdata on the bus device in probe. If
the driver also calls amba_set_drvdata() there, it overwrites that
pointer; on remove/shutdown the framework then gets wrong data and can
hit use-after-free or crashes. So only the framework must set drvdata
on the bus device.
This applies only to the Rust implementation; in C, calling
amba_set_drvdata() is fine. In the Rust design the bus device owns the
bus device's drvdata and the class device owns the class device's
drvdata, so the class driver must not set drvdata on the bus device.
This is my understanding of the Rust device driver abstraction design.
Danilo is the authority on this.
Best regards,
Ke Sun
> Out of 29 drivers, 18 are doing so.
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] rtc: migrate driver data to RTC device
From: Alexandre Belloni @ 2026-02-20 23:19 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Ke Sun, Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux, Alvin Sun
In-Reply-To: <DFJ9L2GPU6WT.1RYEWZJ1V75DE@kernel.org>
On 08/01/2026 15:06:46+0100, Danilo Krummrich wrote:
> On Thu Jan 8, 2026 at 3:01 PM CET, Alexandre Belloni wrote:
> > On 08/01/2026 14:52:08+0100, Danilo Krummrich wrote:
> >> On Thu Jan 8, 2026 at 2:45 PM CET, Ke Sun wrote:
> >> >
> >> > On 1/8/26 19:12, Danilo Krummrich wrote:
> >> >> On Wed Jan 7, 2026 at 3:37 PM CET, Ke Sun wrote:
> >> >>> diff --git a/drivers/rtc/dev.c b/drivers/rtc/dev.c
> >> >>> index baf1a8ca8b2b1..0f62ba9342e3e 100644
> >> >>> --- a/drivers/rtc/dev.c
> >> >>> +++ b/drivers/rtc/dev.c
> >> >>> @@ -410,7 +410,7 @@ static long rtc_dev_ioctl(struct file *file,
> >> >>> }
> >> >>> default:
> >> >>> if (rtc->ops->param_get)
> >> >>> - err = rtc->ops->param_get(rtc->dev.parent, ¶m);
> >> >>> + err = rtc->ops->param_get(&rtc->dev, ¶m);
> >> >> It would make more sense to just pass a struct rtc_device than the embedded
> >> >> struct device in the RTC callbacks.
> >> > I considered passing struct rtc_device directly, but chose &rtc->dev
> >> > to minimize changes to existing drivers, since most callbacks use
> >> > dev_get_drvdata() on the device parameter.
> >>
> >> No, you should not expose the embedded base device. For accessing the private
> >> data you should add helpers like rtc_get_drvdata(). This is what other
> >> subsystems do as well, e.g. [1].
> >>
> >> [1] https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/i2c.h#L371
> >
> > This is not a correct example as i2c is a bus, just like amba is...
>
> Yes, struct i2c_client is indeed a bus device. However, the core struct device
> is what holds the device private data commonly in the same way, regardless of
> whether it is embedded in a bus or class device.
>
> If you look for a class device example, here's PWM [2] and input [3].
>
> [2] https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/pwm.h#L382
> [3] https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/input.h#L388
>
> > Actually, I don't think the rework is necessary at all or this would
> > mean we need to rewor most of our existing subsystems.
>
> That's not true, subsystems do not pass the parent device (i.e. the bus device)
> through their class device callbacks exclusively.
Like explained on the other thread, while it would be conceptually
better to pass a struct rtc_device to the callbacks, it doesn't solve
your issue. Let me take a random input drivers as an example:
https://elixir.bootlin.com/linux/v6.18.3/source/drivers/input/keyboard/pinephone-keyboard.c#L373
This sets its own private data on the parent device, it needs it later
on in the interrupt handler
https://elixir.bootlin.com/linux/v6.18.3/source/drivers/input/joystick/as5011.c#L313
It needs it later on in the remove callback
https://elixir.bootlin.com/linux/v6.18.3/source/drivers/input/misc/da7280.c#L1197
Needed later on for suspend/resume
So the input subsystem is not different from RTC
For PWM:
https://elixir.bootlin.com/linux/v6.18.6/source/drivers/pwm/pwm-pca9685.c#L450
Needed for suspend/resume and .remove()
https://elixir.bootlin.com/linux/v6.18.6/source/drivers/pwm/pwm-rockchip.c#L348
Needed for .remove()
Any other subsystem is going to have similar examples. I don't think
there is a pressing need to rewrite the rtc_class_ops callbacks.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Alexandre Belloni @ 2026-02-20 22:53 UTC (permalink / raw)
To: Ke Sun
Cc: Danilo Krummrich, Ke Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Greg Kroah-Hartman,
Rafael J. Wysocki
In-Reply-To: <77d373dc-c5f2-4dca-b0d2-b5cee6a21b3b@gmail.com>
On 20/01/2026 16:01:40+0800, Ke Sun wrote:
>
> On 1/19/26 22:32, Danilo Krummrich wrote:
> > On Fri Jan 16, 2026 at 5:21 PM CET, Ke Sun wrote:
> > > diff --git a/drivers/rtc/dev.c b/drivers/rtc/dev.c
> > > index baf1a8ca8b2b1..eddcc5a69db3b 100644
> > > --- a/drivers/rtc/dev.c
> > > +++ b/drivers/rtc/dev.c
> > > @@ -410,7 +410,7 @@ static long rtc_dev_ioctl(struct file *file,
> > > }
> > > default:
> > > if (rtc->ops->param_get)
> > > - err = rtc->ops->param_get(rtc->dev.parent, ¶m);
> > > + err = rtc->ops->param_get(rtc_ops_dev(rtc), ¶m);
> > > else
> > > err = -EINVAL;
> > > }
> > <snip>
> >
> > > +/**
> > > + * rtc_ops_dev - Get the device pointer for RTC ops callbacks
> > > + * @rtc: RTC device
> > > + *
> > > + * Returns &rtc->dev if RTC_OPS_USE_RTC_DEV flag is set,
> > > + * otherwise returns rtc->dev.parent.
> > > + */
> > > +static inline struct device *rtc_ops_dev(struct rtc_device *rtc)
> > > +{
> > > + if (test_bit(RTC_OPS_USE_RTC_DEV, &rtc->flags))
> > > + return &rtc->dev;
> > > + return rtc->dev.parent;
> > > +}
> > I understand that the idea is to gradually convert all drivers to use the RTC
> > device, rather than it's parent device in RTC device callbacks.
> >
> > My main concern is that once that has been achieved it's still not what we want
> > to have eventually, i.e. RTC device callbacks should ideally take a struct
> > rtc_device as argument and not the embedded base struct device.
> >
> > I.e. we'd kick off a conversion process that won't reach the actual desired
> > state.
> Hi Danilo,
>
> This is indeed an intermediate step.
>
> Full cleanup is in progress, but it's large and untested. I'm working on a
> complete cleanup involving ~190+ files across arch/, drivers/rtc/, and
> drivers/virtio/. Most changes are straightforward interface replacements,
> but some drivers need additional modifications. Given the scale, I haven't
> fully tested everything and can't guarantee correctness yet.
>
> The intermediate step enables gradual migration, allowing us to:
> - Clean up and test each rtc driver incrementally
> - Ensure correctness through gradual changes
> - Avoid breaking existing functionality
>
> Once all cleanup is complete and tested, changing all rtc_class_ops
> callbacks to use struct rtc_device * will be much simpler and safer.
>
> Currently there seem to be only these two approaches. I'm still waiting
> for Alexandre's suggestion on how to proceed specifically, but haven't
> received a response yet.
I'm sorry, I still don't see the point of doing this. The driver will
almost always need to set its driver data in the parent device because
we need to be able to handle interrupts, suspend/resume or .remove(). So
while intellectually, this would be more satisfying to have the
callbacks take a struct rtc_device, functionally this doesn't have any
purpose because we need to use the parent drvdata anyway.
Said differently, you should explain why a device driver must not call
amba_set_drvdata() ?
Out of 29 drivers, 18 are doing so.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 06/12] mfd: sec: add support for S2MU005 PMIC
From: Sander Vanheule @ 2026-02-20 16:56 UTC (permalink / raw)
To: Kaustabh Chakraborty, André Draszik, Lee Jones, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham,
Chanwoo Choi, Sebastian Reichel, Krzysztof Kozlowski,
Alexandre Belloni, Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <DG74Y3QSCLIO.32Q8ZKCTISXXB@disroot.org>
Hi,
On Thu, 2026-02-05 at 21:02 +0530, Kaustabh Chakraborty wrote:
> On 2026-02-04 15:23 +00:00, André Draszik wrote:
> > On Mon, 2026-01-26 at 00:37 +0530, Kaustabh Chakraborty wrote:
> > > +static const struct regmap_config s2mu005_regmap_config = {
> > > + .reg_bits = 8,
> > > + .val_bits = 8,
> > > +};
> >
> > No cache? And what is the .max_register value?
> >
>
> This was in the previous revision, but I ended up removing it because
> (at least I thought at that time) interfered with interrupts firing in
> some way. The actual issue was unrelated, so I will add it back.
>
> However, there is also another thing I see in logs:
>
> sec-pmic-i2c 2-003d: using zero-initialized flat cache, this may cause
> unexpected behavior
>
> This is due to REGCACHE_FLAT, I am not sure if I should just ignore
> this.
Sorry to be late to the party, but I'm somewhat responsible for that warning, so
allow me to chime in :-)
What you are might have been seeing is REGCACHE_FLAT giving you "cached" values
of 0x0, while the hardware actually has something else. This can cause omitted
writes, existing (bootloader) config to overwritten, etc.
As André suggested, using .num_reg_defaults_raw is a possibility, but then you
have to remember that the register defaults are taken to be what the hardware
state is at that moment, including pre-probe changes. These defaults are used to
seed the cache (so far, so good), but this may break the contract of
regmap_sync() if you ever want to use that after actually resetting the PMIC.
If you want to use the flat cache, I would suggest you use REGCACHE_FLAT_S,
which will track what has already been read from/written to hardware. You will
also need to specifiy .max_register.
I see the other regmap_config-s in this driver also use REGCACHE_FLAT, so you
may want to consider switching those over as well if these are also showing the
new warning.
Best,
Sander
^ permalink raw reply
* Re: [PATCH RFC 02/10] rtc: prepare for struct device member groups becoming a constant array
From: Alexandre Belloni @ 2026-02-20 14:38 UTC (permalink / raw)
To: yanjun.zhu
Cc: Heiner Kallweit, Thomas Weißschuh, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Jason Gunthorpe,
Leon Romanovsky, driver-core, Linux Kernel Mailing List,
linux-rdma, linux-rtc
In-Reply-To: <392127ee-11ad-4517-bb72-91af64fd191e@linux.dev>
On 18/02/2026 16:53:00-0800, yanjun.zhu wrote:
> On 2/17/26 2:26 PM, Heiner Kallweit wrote:
> > This prepares for making struct device member groups a constant array.
> > The assignment groups = rtc->dev.groups would result in a "discarding
> > const qualifier" warning with this change.
> > No functional change intended.
> >
> > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> > ---
> > drivers/rtc/sysfs.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/rtc/sysfs.c b/drivers/rtc/sysfs.c
> > index 4ab05e105a7..ae5e1252b4c 100644
> > --- a/drivers/rtc/sysfs.c
> > +++ b/drivers/rtc/sysfs.c
> > @@ -308,7 +308,7 @@ const struct attribute_group **rtc_get_dev_attribute_groups(void)
> > int rtc_add_groups(struct rtc_device *rtc, const struct attribute_group **grps)
> > {
> > size_t old_cnt = 0, add_cnt = 0, new_cnt;
> > - const struct attribute_group **groups, **old;
> > + const struct attribute_group **groups, *const *old;
> > if (grps) {
> > for (groups = grps; *groups; groups++)
> > @@ -320,9 +320,9 @@ int rtc_add_groups(struct rtc_device *rtc, const struct attribute_group **grps)
> > return -EINVAL;
> > }
> > - groups = rtc->dev.groups;
> > - if (groups)
> > - for (; *groups; groups++)
> > + old = rtc->dev.groups;
> > + if (old)
> > + while (*old++)
> > old_cnt++;
>
> The change from for (; *groups; groups++) to while (*old++) is not
> functionally equivalent. In the while version, the post-increment old++
> executes even when *old is NULL. This leaves the pointer old pointing one
> element past the NULL terminator. While old_cnt remains correct, this is a
> side-effect-heavy idiom that differs from standard kernel patterns and could
> be fragile if old is used later in the function.
>
Thanks for pointing this out, I agree we should keep the original for
loop.
With that change,
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Best Regards,
> Zhu Yanjun
>
> > new_cnt = old_cnt + add_cnt + 1;
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v3] dt-bindings: rtc: isl12026: convert to YAML schema
From: Piyush Patle @ 2026-02-20 8:47 UTC (permalink / raw)
To: Alexandre Belloni
Cc: robh, krzk+dt, conor+dt, linux-rtc, devicetree, linux-kernel
In-Reply-To: <20260220-vigorous-holistic-platypus-6ebebd@quoll>
Convert the ISL12026 RTC binding from text format to YAML schema.
Remove the legacy text binding.
The new schema enables dtbs_check validation.
---
Changes in v2:
- Fixed schema validation issues pointed out in review
- Improved example node formatting
- Removed redundant description text
---
Changes in v3:
- Dropped unnecessary block scalar ('|') in description
- Removed unsupported select section to match existing RTC bindings
- Aligned schema structure with other RTC YAML bindings
- Fixed YAML formatting and dt_binding_check errors
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
.../devicetree/bindings/rtc/isil,isl12026.txt | 28 --------
.../bindings/rtc/isil,isl12026.yaml | 64 +++++++++++++++++++
2 files changed, 64 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.txt
create mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.txt b/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
deleted file mode 100644
index 2e0be45193bb..000000000000
--- a/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-ISL12026 I2C RTC/EEPROM
-
-ISL12026 is an I2C RTC/EEPROM combination device. The RTC and control
-registers respond at bus address 0x6f, and the EEPROM array responds
-at bus address 0x57. The canonical "reg" value will be for the RTC portion.
-
-Required properties supported by the device:
-
- - "compatible": must be "isil,isl12026"
- - "reg": I2C bus address of the device (always 0x6f)
-
-Optional properties:
-
- - "isil,pwr-bsw": If present PWR.BSW bit must be set to the specified
- value for proper operation.
-
- - "isil,pwr-sbib": If present PWR.SBIB bit must be set to the specified
- value for proper operation.
-
-
-Example:
-
- rtc@6f {
- compatible = "isil,isl12026";
- reg = <0x6f>;
- isil,pwr-bsw = <0>;
- isil,pwr-sbib = <1>;
- }
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml b/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
new file mode 100644
index 000000000000..a6822605fd72
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/isil,isl12026.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intersil ISL12026 I2C RTC/EEPROM
+
+maintainers:
+ - Piyush Patle <piyushpatle228@gmail.com>
+
+description: |
+ The ISL12026 is a combination RTC and EEPROM device connected via I2C.
+ The RTC and control registers respond at address 0x6f, while the EEPROM
+ array responds at address 0x57. The "reg" property refers to the RTC
+ portion of the device.
+
+select:
+ properties:
+ compatible:
+ const: isil,isl12026
+ required:
+ - compatible
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: isil,isl12026
+
+ reg:
+ maxItems: 1
+ description: I2C address of the RTC portion (must be 0x6f)
+
+ isil,pwr-bsw:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Value written to the PWR.BSW bit for proper device operation.
+
+ isil,pwr-sbib:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Value written to the PWR.SBIB bit for proper device operation.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@6f {
+ compatible = "isil,isl12026";
+ reg = <0x6f>;
+ isil,pwr-bsw = <0>;
+ isil,pwr-sbib = <1>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: rtc: isl12026: convert to YAML schema
From: Krzysztof Kozlowski @ 2026-02-20 7:48 UTC (permalink / raw)
To: Piyush Patle
Cc: alexandre.belloni, robh, krzk+dt, conor+dt, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <20260219055115.195302-1-piyushpatle228@gmail.com>
On Thu, Feb 19, 2026 at 11:21:15AM +0530, Piyush Patle wrote:
> diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml b/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
> new file mode 100644
> index 000000000000..a6822605fd72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/isil,isl12026.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intersil ISL12026 I2C RTC/EEPROM
> +
> +maintainers:
> + - Piyush Patle <piyushpatle228@gmail.com>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + The ISL12026 is a combination RTC and EEPROM device connected via I2C.
> + The RTC and control registers respond at address 0x6f, while the EEPROM
> + array responds at address 0x57. The "reg" property refers to the RTC
> + portion of the device.
> +
> +select:
> + properties:
> + compatible:
> + const: isil,isl12026
> + required:
> + - compatible
Why do you have this select? Look at existing bindings - NONE have that.
Just in case if that was not obvious: don't send us AI microslop.
> +
> +allOf:
> + - $ref: rtc.yaml#
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] dt-bindings: rtc: isl12026: convert to YAML schema
From: Piyush Patle @ 2026-02-19 5:51 UTC (permalink / raw)
To: alexandre.belloni, robh, krzk+dt, conor+dt
Cc: linux-rtc, devicetree, linux-kernel
Convert the ISL12026 RTC binding from text format to YAML schema.
Remove the legacy text binding.
The new schema enables dtbs_check validation.
---
Changes in v2:
- Fixed schema validation issues pointed out in review
- Improved example node formatting
- Removed redundant description text
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
.../devicetree/bindings/rtc/isil,isl12026.txt | 28 --------
.../bindings/rtc/isil,isl12026.yaml | 64 +++++++++++++++++++
2 files changed, 64 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.txt
create mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.txt b/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
deleted file mode 100644
index 2e0be45193bb..000000000000
--- a/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-ISL12026 I2C RTC/EEPROM
-
-ISL12026 is an I2C RTC/EEPROM combination device. The RTC and control
-registers respond at bus address 0x6f, and the EEPROM array responds
-at bus address 0x57. The canonical "reg" value will be for the RTC portion.
-
-Required properties supported by the device:
-
- - "compatible": must be "isil,isl12026"
- - "reg": I2C bus address of the device (always 0x6f)
-
-Optional properties:
-
- - "isil,pwr-bsw": If present PWR.BSW bit must be set to the specified
- value for proper operation.
-
- - "isil,pwr-sbib": If present PWR.SBIB bit must be set to the specified
- value for proper operation.
-
-
-Example:
-
- rtc@6f {
- compatible = "isil,isl12026";
- reg = <0x6f>;
- isil,pwr-bsw = <0>;
- isil,pwr-sbib = <1>;
- }
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml b/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
new file mode 100644
index 000000000000..a6822605fd72
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/isil,isl12026.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intersil ISL12026 I2C RTC/EEPROM
+
+maintainers:
+ - Piyush Patle <piyushpatle228@gmail.com>
+
+description: |
+ The ISL12026 is a combination RTC and EEPROM device connected via I2C.
+ The RTC and control registers respond at address 0x6f, while the EEPROM
+ array responds at address 0x57. The "reg" property refers to the RTC
+ portion of the device.
+
+select:
+ properties:
+ compatible:
+ const: isil,isl12026
+ required:
+ - compatible
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: isil,isl12026
+
+ reg:
+ maxItems: 1
+ description: I2C address of the RTC portion (must be 0x6f)
+
+ isil,pwr-bsw:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Value written to the PWR.BSW bit for proper device operation.
+
+ isil,pwr-sbib:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Value written to the PWR.SBIB bit for proper device operation.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@6f {
+ compatible = "isil,isl12026";
+ reg = <0x6f>;
+ isil,pwr-bsw = <0>;
+ isil,pwr-sbib = <1>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC 02/10] rtc: prepare for struct device member groups becoming a constant array
From: yanjun.zhu @ 2026-02-19 0:53 UTC (permalink / raw)
To: Heiner Kallweit, Thomas Weißschuh, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Jason Gunthorpe,
Leon Romanovsky, Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <95e5af90-ed53-4009-a4ea-19ed04499ecc@kernel.org>
On 2/17/26 2:26 PM, Heiner Kallweit wrote:
> This prepares for making struct device member groups a constant array.
> The assignment groups = rtc->dev.groups would result in a "discarding
> const qualifier" warning with this change.
> No functional change intended.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/rtc/sysfs.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/sysfs.c b/drivers/rtc/sysfs.c
> index 4ab05e105a7..ae5e1252b4c 100644
> --- a/drivers/rtc/sysfs.c
> +++ b/drivers/rtc/sysfs.c
> @@ -308,7 +308,7 @@ const struct attribute_group **rtc_get_dev_attribute_groups(void)
> int rtc_add_groups(struct rtc_device *rtc, const struct attribute_group **grps)
> {
> size_t old_cnt = 0, add_cnt = 0, new_cnt;
> - const struct attribute_group **groups, **old;
> + const struct attribute_group **groups, *const *old;
>
> if (grps) {
> for (groups = grps; *groups; groups++)
> @@ -320,9 +320,9 @@ int rtc_add_groups(struct rtc_device *rtc, const struct attribute_group **grps)
> return -EINVAL;
> }
>
> - groups = rtc->dev.groups;
> - if (groups)
> - for (; *groups; groups++)
> + old = rtc->dev.groups;
> + if (old)
> + while (*old++)
> old_cnt++;
The change from for (; *groups; groups++) to while (*old++) is not
functionally equivalent. In the while version, the post-increment old++
executes even when *old is NULL. This leaves the pointer old pointing
one element past the NULL terminator. While old_cnt remains correct,
this is a side-effect-heavy idiom that differs from standard kernel
patterns and could be fragile if old is used later in the function.
Best Regards,
Zhu Yanjun
>
> new_cnt = old_cnt + add_cnt + 1;
^ permalink raw reply
* Re: [PATCH] dt-bindings: rtc: isl12026: convert to YAML schema
From: Rob Herring (Arm) @ 2026-02-18 20:27 UTC (permalink / raw)
To: Piyush Patle
Cc: krzk+dt, linux-rtc, devicetree, conor+dt, linux-kernel,
alexandre.belloni
In-Reply-To: <20260218190213.429892-1-piyushpatle228@gmail.com>
On Thu, 19 Feb 2026 00:32:13 +0530, Piyush Patle wrote:
> Convert the ISL12026 RTC binding to DT schema format.
>
> The binding was previously documented in text format.
> This converts it to YAML and enables dtbs_check validation.
>
> Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
> ---
> .../bindings/rtc/isil,isl12026.yaml | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/rtc/isil,isl12026.yaml:4:6: [error] string value is redundantly quoted with any quotes (quoted-strings)
./Documentation/devicetree/bindings/rtc/isil,isl12026.yaml:5:10: [error] string value is redundantly quoted with any quotes (quoted-strings)
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml: maintainers:0: 'Piyush Patle piyushpatle228@gmail.com' does not match '^(.+ <[\\S]+@[\\S]+>|[\\S]+@[\\S]+)$'
from schema $id: http://devicetree.org/meta-schemas/base.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260218190213.429892-1-piyushpatle228@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] dt-bindings: rtc: isl12026: convert to YAML schema
From: Krzysztof Kozlowski @ 2026-02-18 19:20 UTC (permalink / raw)
To: Piyush Patle, alexandre.belloni
Cc: robh, krzk+dt, conor+dt, linux-rtc, devicetree, linux-kernel
In-Reply-To: <20260218190213.429892-1-piyushpatle228@gmail.com>
On 18/02/2026 20:02, Piyush Patle wrote:
> Convert the ISL12026 RTC binding to DT schema format.
>
> The binding was previously documented in text format.
> This converts it to YAML and enables dtbs_check validation.
You already said it in the first sentence.
>
> Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
> ---
> .../bindings/rtc/isil,isl12026.yaml | 57 +++++++++++++++++++
Where is the conversion?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: rtc: isl12026: convert to YAML schema
From: Piyush Patle @ 2026-02-18 19:02 UTC (permalink / raw)
To: alexandre.belloni
Cc: robh, krzk+dt, conor+dt, linux-rtc, devicetree, linux-kernel
Convert the ISL12026 RTC binding to DT schema format.
The binding was previously documented in text format.
This converts it to YAML and enables dtbs_check validation.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
---
.../bindings/rtc/isil,isl12026.yaml | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml b/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
new file mode 100644
index 000000000000..5f0ac73b1fde
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/isil,isl12026.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/rtc/isil,isl12026.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Intersil ISL12026 I2C RTC/EEPROM
+
+maintainers:
+ - Piyush Patle piyushpatle228@gmail.com
+
+description: |
+ The ISL12026 is a combination RTC and EEPROM device connected via I2C.
+ The RTC and control registers respond at address 0x6f, while the EEPROM
+ array responds at address 0x57. The "reg" property refers to the RTC
+ portion of the device.
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: isil,isl12026
+
+ reg:
+ maxItems: 1
+ description: I2C address of the RTC portion (must be 0x6f)
+
+ isil,pwr-bsw:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Value written to the PWR.BSW bit for proper device operation.
+
+ isil,pwr-sbib:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Value written to the PWR.SBIB bit for proper device operation.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@6f {
+ compatible = "isil,isl12026";
+ reg = <0x6f>;
+ isil,pwr-bsw = <0>;
+ isil,pwr-sbib = <1>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC 01/10] IB/core: Prepare for immutable device groups
From: Leon Romanovsky @ 2026-02-18 8:54 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Alexandre Belloni, driver-core,
Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <0f7f4ffa-1465-4c54-8d3d-e9b551136669@kernel.org>
On Tue, Feb 17, 2026 at 11:25:20PM +0100, Heiner Kallweit wrote:
> This prepares for making struct device member groups a constant array.
> No functional change intended.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/infiniband/core/device.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
Thanks,
Acked-by: Leon Romanovsky <leon@kernel.org>
^ permalink raw reply
* [PATCH RFC 10/10] kobject: make struct kobject member default_groups a constant array
From: Heiner Kallweit @ 2026-02-17 22:32 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Constify the default_groups array, allowing to assign constant arrays.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/kobject.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index c8219505a79..e45ee843931 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -116,7 +116,7 @@ char *kobject_get_path(const struct kobject *kobj, gfp_t flag);
struct kobj_type {
void (*release)(struct kobject *kobj);
const struct sysfs_ops *sysfs_ops;
- const struct attribute_group **default_groups;
+ const struct attribute_group *const *default_groups;
const struct kobj_ns_type_operations *(*child_ns_type)(const struct kobject *kobj);
const void *(*namespace)(const struct kobject *kobj);
void (*get_ownership)(const struct kobject *kobj, kuid_t *uid, kgid_t *gid);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 09/10] driver core: make struct device_driver groups members contact arrays
From: Heiner Kallweit @ 2026-02-17 22:31 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Constify the groups arrays, allowing to assign constant arrays.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/device/driver.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index bbc67ec513e..c882daaef01 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -114,8 +114,8 @@ struct device_driver {
void (*shutdown) (struct device *dev);
int (*suspend) (struct device *dev, pm_message_t state);
int (*resume) (struct device *dev);
- const struct attribute_group **groups;
- const struct attribute_group **dev_groups;
+ const struct attribute_group *const *groups;
+ const struct attribute_group *const *dev_groups;
const struct dev_pm_ops *pm;
void (*coredump) (struct device *dev);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 08/10] driver core: make struct class groups members constant arrays
From: Heiner Kallweit @ 2026-02-17 22:30 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Constify the groups arrays, allowing to assign constant arrays.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/device/class.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/device/class.h b/include/linux/device/class.h
index 65880e60c72..2079239a5aa 100644
--- a/include/linux/device/class.h
+++ b/include/linux/device/class.h
@@ -50,8 +50,8 @@ struct fwnode_handle;
struct class {
const char *name;
- const struct attribute_group **class_groups;
- const struct attribute_group **dev_groups;
+ const struct attribute_group *const *class_groups;
+ const struct attribute_group *const *dev_groups;
int (*dev_uevent)(const struct device *dev, struct kobj_uevent_env *env);
char *(*devnode)(const struct device *dev, umode_t *mode);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 07/10] driver core: make struct bus_type groups members constant arrays
From: Heiner Kallweit @ 2026-02-17 22:30 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Constify the groupss arrays, allowing to assign constant arrays.
As a prerequisite this requires to constify the groups array argument
in few functions.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/base/base.h | 6 ++++--
drivers/base/driver.c | 4 ++--
include/linux/device/bus.h | 6 +++---
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 8c2175820da..b6852ba45cd 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -202,8 +202,10 @@ static inline void dev_sync_state(struct device *dev)
dev->driver->sync_state(dev);
}
-int driver_add_groups(const struct device_driver *drv, const struct attribute_group **groups);
-void driver_remove_groups(const struct device_driver *drv, const struct attribute_group **groups);
+int driver_add_groups(const struct device_driver *drv,
+ const struct attribute_group *const *groups);
+void driver_remove_groups(const struct device_driver *drv,
+ const struct attribute_group *const *groups);
void device_driver_detach(struct device *dev);
static inline void device_set_driver(struct device *dev, const struct device_driver *drv)
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index 8ab010ddf70..c5ebf1fdad7 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -203,13 +203,13 @@ void driver_remove_file(const struct device_driver *drv,
EXPORT_SYMBOL_GPL(driver_remove_file);
int driver_add_groups(const struct device_driver *drv,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
return sysfs_create_groups(&drv->p->kobj, groups);
}
void driver_remove_groups(const struct device_driver *drv,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
sysfs_remove_groups(&drv->p->kobj, groups);
}
diff --git a/include/linux/device/bus.h b/include/linux/device/bus.h
index 99c3c83ea52..00d8a080f93 100644
--- a/include/linux/device/bus.h
+++ b/include/linux/device/bus.h
@@ -78,9 +78,9 @@ struct fwnode_handle;
struct bus_type {
const char *name;
const char *dev_name;
- const struct attribute_group **bus_groups;
- const struct attribute_group **dev_groups;
- const struct attribute_group **drv_groups;
+ const struct attribute_group *const *bus_groups;
+ const struct attribute_group *const *dev_groups;
+ const struct attribute_group *const *drv_groups;
int (*match)(struct device *dev, const struct device_driver *drv);
int (*uevent)(const struct device *dev, struct kobj_uevent_env *env);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 06/10] driver core: make struct device_type member groups a constant array
From: Heiner Kallweit @ 2026-02-17 22:29 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Constify the groups array, allowing to assign constant arrays.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index bfa2ca603c2..808f723bbcf 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -87,7 +87,7 @@ int subsys_virtual_register(const struct bus_type *subsys,
*/
struct device_type {
const char *name;
- const struct attribute_group **groups;
+ const struct attribute_group *const *groups;
int (*uevent)(const struct device *dev, struct kobj_uevent_env *env);
char *(*devnode)(const struct device *dev, umode_t *mode,
kuid_t *uid, kgid_t *gid);
--
2.53.0
^ permalink raw reply related
page: next (older) | 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