* [PATCH 1/6] dt-bindings: rtc: sc2731: Add compatible for SC2730
From: Otto Pflüger @ 2026-02-22 13:16 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger
In-Reply-To: <20260222-sc27xx-mfd-cells-v1-0-69526fe74c77@abscue.de>
The RTC block found in the SC2730 PMIC is compatible with the one found
in the SC2731 PMIC.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
---
Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml b/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml
index 5756f617df36..1deae2f4f09d 100644
--- a/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/sprd,sc2731-rtc.yaml
@@ -13,7 +13,12 @@ maintainers:
properties:
compatible:
- const: sprd,sc2731-rtc
+ oneOf:
+ - items:
+ - enum:
+ - sprd,sc2730-rtc
+ - const: sprd,sc2731-rtc
+ - const: sprd,sc2731-rtc
reg:
maxItems: 1
--
2.51.0
^ permalink raw reply related
* [PATCH 2/6] dt-bindings: leds: sc2731: Add compatible for SC2730
From: Otto Pflüger @ 2026-02-22 13:16 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger
In-Reply-To: <20260222-sc27xx-mfd-cells-v1-0-69526fe74c77@abscue.de>
The LED controller found in the SC2730 PMIC is compatible with the one
found in the SC2731 PMIC.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
---
Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml b/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml
index 97535d6dc47a..2ae5cc31e623 100644
--- a/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml
+++ b/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml
@@ -18,7 +18,12 @@ description: |
properties:
compatible:
- const: sprd,sc2731-bltc
+ oneOf:
+ - items:
+ - enum:
+ - sprd,sc2730-bltc
+ - const: sprd,sc2731-bltc
+ - const: sprd,sc2731-bltc
reg:
maxItems: 1
--
2.51.0
^ permalink raw reply related
* [PATCH 0/6] mfd: sc27xx: Use MFD cells and devm_mfd_add_devices()
From: Otto Pflüger @ 2026-02-22 13:16 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm,
Otto Pflüger
These changes resulted from the need to decouple the the Linux device
driver hierarchy from the device tree bindings for two different series
introducing regulator [1] and poweroff [2] support for the SC2730 PMIC.
There are different PMICs in the SC27xx series, including SC2730 and
SC2731. These have a lot of similarities, but some differences too. For
instance, they contain compatible RTC blocks, but completely different
sets of regulators.
On the Linux side, each PMIC block needs its own driver. The MFD driver
currently uses devm_of_platform_populate() to load the drivers for the
components of the PMIC, which only works when each component has its own
sub-node with a "compatible" property that is used to select a driver
for the device.
When viewed from the device tree side, the parent node representing the
PMIC already contains a "compatible" property that distinguishes the
different PMICs. While the device tree bindings currently do require a
separate "compatible" property for each sub-node (ADC, fuel gauge,
regulators, ...), this is essentially redundant since the node name and
the parent compatible uniquely identify the component. Moreover, some
parts of the PMIC such as the poweroff/reboot controller do not even
need a corresponding device tree node.
Change the MFD driver to use MFD cells instead, which allows it to
instantiate sub-devices both with and without device tree nodes.
Devices that do not have a separate device tree node with its own
"compatible" property can be matched by their platform device ID.
Use this to hook up the existing SC2731 poweroff and regulator drivers,
which were previously not loaded at all due to the lack of an ID table.
In the device tree bindings, deprecate the redundant "compatible"
property for the "regulators" node. While it might make sense to do this
for the other components too, there are a few reasons to only change the
regulators at this point:
- The regulators node is special since it is not as independent as the
other components. For instance, it is the only child node of the PMIC
that does not have a "reg" property. The set of regulators also
differs much more between different PMIC models than the register
layout of the other components.
- We already have some other PMICs where only the regulators are
treated specially like this, such as MediaTek MT6359 and MT6370.
- It was suggested to remove the "compatible" property for the new
SC2730 regulator bindings I am preparing in [2]. The bindings for
the other components do not need any significant changes at the
moment.
- Unlike the poweroff and regulator components, the other parts are
already working with the existing drivers and bindings.
For the other components that still have a "compatible" property used
for matching MFD cells, ensure that an SC2730-specific compatible is
defined in the bindings so that it can be listed in the SC2730-specific
device table in the MFD driver.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
[1]: https://lore.kernel.org/all/20250926-sc2730-reboot-v1-0-62ebfd3d31bb@abscue.de/
[2]: https://lore.kernel.org/all/20260220-sc2730-regulators-v1-0-3f2bbc9ecf14@abscue.de/
---
Otto Pflüger (6):
dt-bindings: rtc: sc2731: Add compatible for SC2730
dt-bindings: leds: sc2731: Add compatible for SC2730
regulator: dt-bindings: sc2731: Deprecate compatible property
mfd: sprd-sc27xx: Switch to devm_mfd_add_devices()
power: reset: sc27xx: Add platform_device_id table
regulator: sc2731: Add platform_device_id table
.../devicetree/bindings/leds/sprd,sc2731-bltc.yaml | 7 ++++-
.../devicetree/bindings/mfd/sprd,sc2731.yaml | 2 --
.../bindings/regulator/sprd,sc2731-regulator.yaml | 4 +--
.../devicetree/bindings/rtc/sprd,sc2731-rtc.yaml | 7 ++++-
drivers/mfd/sprd-sc27xx-spi.c | 33 +++++++++++++++++++++-
drivers/power/reset/sc27xx-poweroff.c | 8 ++++++
drivers/regulator/sc2731-regulator.c | 10 ++++++-
7 files changed, 62 insertions(+), 9 deletions(-)
---
base-commit: d4906ae14a5f136ceb671bb14cedbf13fa560da6
change-id: 20260221-sc27xx-mfd-cells-dab7905f3aae
Best regards,
--
Otto Pflüger <otto.pflueger@abscue.de>
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Danilo Krummrich @ 2026-02-22 12:49 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Rafael J. Wysocki, Alvin 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
In-Reply-To: <20260222000556ea1938c0@mail.local>
On Sun Feb 22, 2026 at 1:05 AM CET, Alexandre Belloni wrote:
> On 21/02/2026 15:33:48+0100, Danilo Krummrich wrote:
>> (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.
>>
>
> But what you explain here is that the drive is forbidden to use
> rtc->dev.parent->private_data at all because the rust core is already
> using it. What I'm saying is that it won't work because more than half
> of the drivers currently need it.
I think I was explaining the exact opposite, i.e. the driver's bus device
private data is stored in the exact same way as in C, but it has a defined
lifetime (from probe() until remove() and all devres callbacks have been
completed) and is managed by the driver-core.
Look at this example:
// The bus device private data.
struct SampleDriver {
foo: u32,
bar: u32,
}
impl pci::Driver for SampleDriver {
fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
// Return the driver's bus device private data. The driver-core
// will do all the work for us and eventually call
// `dev_set_drvdata()` on the base `struct device` of `pdev`.
Ok(Foo {
foo: 42,
bar: 24,
})
}
fn unbind(pdev: &pci::Device<Core>, self: Pin<&Self>) {
// Use the driver's device private data from the method's `self` argument.
dev_info!(pdev, "foo: {}, bar: {}\n", self.foo, self.bar);
// There's also the `Device<Bound>::drvdata()` accessor, let's
// use that as well.
// Get a generic `device::Device` from the `pci::Device`.
let dev = pdev.as_ref();
// Get the `drvdata`; we have to assert the type and let the driver-core
// validate that the asserted type is correct.
let drvdata = dev.drvdata::<SampleDriver>()?;
dev_info!(pdev, "foo: {}, bar: {}\n", drvdata.foo, drvdata.bar);
}
}
>> 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.
>>
>
> This still doesn't explain how you get the class private data that you
> need when you are in a driver callback that is called from the bus (e.g.
> suspend/resume) from what you explain, the driver doesn't have any
> chance to pass it. The whole goal of a device driver is to be the glue
> between a class device and a bus device as essentially this is the exact
> physical device, just represented differently.
It is not always as simple as "one bus device corresponds to one class device".
Sometimes drivers have to deal with multiple class devices for a single bus
device, sometimes they are separated through the auxiliary bus or MFD.
For instance, take struct net_device. In the context of cfg80211 wireless
drivers may create arbitrary struct net_device instances, depending on how often
the add_virtual_intf() callback is called (through netlink); example in [1].
Now, regarding your question "How to access class device private data from bus
device callbacks?". Nothing prevents a driver from embedding the class device in
its bus device private data in one or the other way.
In the net device example above, the driver would probably keep a list (or
xarray, etc.) of net devices in its bus device private data, as they can be
created and removed at any point of time.
(Note that this is also a good example for when the class device private data
lives shorter than the bus device private data.)
Here is an example of this looks like in code using a DRM device as class
device.
struct SampleIrqData;
// The class device private data.
struct SampleDrm {
sched: drm::GpuScheduler,
}
// The bus device private data.
#[pin_data]
struct SampleDriver {
#[pin]
irq: irq::Registration<SampleIrqData>,
drm: ARef<drm::Device<SampleDrm>, // Refcount of a `drm::Device`.
}
impl pci::Driver for SampleDriver {
fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
let dev = pdev.as_ref();
let drm = drm::Device::new(dev, SampleDrm::new()?)?;
drm.register();
Ok(impl_pin_init!(Self {
irq <- irq::Registration::new(...);
drm,
})
}
fn unbind(pdev: &pci::Device<Core>, self: Pin<&Self>) {
self.irq.synchronize();
self.drm.flush_scheduler();
}
}
Note that the irq::Registration is dropped when the bus device is unbound,
whereas the GpuScheduler is dropped when the DRM device is dropped.
Of course, depending on the actual class device this difference may be more or
less important, i.e. absolutely crucial in the net device example, less
important for RTC apparently. But it is always good to be precise about
ownership and lifetime of data.
As I already mentioned, I don't think it is good to fold ownership and lifetime
for bus and class devices together in cases where it happens that they are
mostly identical, i.e.:
>> 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.
[1] https://elixir.bootlin.com/linux/v6.19.2/source/drivers/net/wireless/microchip/wilc1000/netdev.c#L948
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Rafael J. Wysocki @ 2026-02-22 12:25 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Rafael J. Wysocki, Alexandre Belloni, Alvin 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
In-Reply-To: <DGKPPQI0QE73.S8I1M5NCI2BV@kernel.org>
On Sat, Feb 21, 2026 at 3:33 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> 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().
So do I understand correctly that the driver is required to tell the
core what type its driver_data will be and then the core will allocate
memory for it and clean it up on remove?
> (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.)
So in the simplest case when the driver doesn't need driver_data at
all, it will just use a struct with no fields as that driver_data
type, IIUC.
> 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.
Well, that's what happens on the C side of things too most of the time
because driver_data is allocated at probe time, very often using
devm_kzalloc() or equivalent.
> 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.
OK
> (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.
As a general rule, I agree, but I would advise against applying
general rules automatically everywhere.
> 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).
TBH I'm not really convinced about this particular thing and I think I
can provide an illustrative example.
Namely, quite incidentally, I've recently set out to add an RTC class
device to an existing driver, which is the ACPI time and alarm device
(TAD) one. The TAD functionality is based on ACPI control methods
provided by the platform firmware and it may (or may not) include
RTC-equivalent functions. So far, the driver has been providing a
completely custom sysfs interface to user space, but since more and
more platforms contain an ACPI TAD and some of them may not contain a
"traditional" RTC, having an RTC class device interface in that driver
may be quite useful.
I have a prototype of the requisite change (I'll post it shortly for
reference) and it turns out that because the RTC class callbacks take
the parent device pointer as an argument, wrapping them around the
existing driver routines backing the existing sysfs interface is
super-straightforward. Had the RTC class passed an RTC device pointer
to those callbacks, the driver would have had to do something to get
back from it to the parent device (which is what the driver really
works with). If there are more similar drivers, that would have led
to some code duplication that is in fact unnecessary.
Moreover, the RTC device pointer doesn't even need to be stored
anywhere in that driver because the driver need not use it directly at
all and the RTC device object memory is freed by the core when the
driver unbinds.
> 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.
Well, I'm not sure if "the experience of writing drivers as consistent
as possible" is more important than less code duplication and simpler
code.
^ permalink raw reply
* Re: [PATCH 0/7] rtc: sun6i: Add support for Allwinner A733 SoC
From: Jernej Škrabec @ 2026-02-22 10:41 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, Junhui Liu
Cc: linux-clk, linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, Junhui Liu
In-Reply-To: <20260121-a733-rtc-v1-0-d359437f23a7@pigmoral.tech>
Hi!
Dne sreda, 21. januar 2026 ob 11:59:06 Srednjeevropski standardni čas je Junhui Liu napisal(a):
> Add support for the Allwinner A733 RTC and its internal Clock Control
> Unit (CCU). Reuse the rtc-sun6i rtc driver while introducing a new
> SoC-specific RTC CCU driver to handle the hardware's evolved clock
> structure.
>
> To facilitate this addition and improve driver modularity, transition
> the binding between the RTC and its internal CCU from direct
> cross-subsystem function calls to the auxiliary bus. Also extract shared
> IOSC and 32kHz clock logic into a standalone ccu_rtc module for reuse
> across newer SoC generations.
>
> The A733 implementation supports hardware detection of three external
> crystal frequencies (19.2MHz, 24MHz and 26MHz), which is represented in
> the driver via read-only mux operations. Implement logic to derive a
> normalized 32kHz reference from these DCXO sources using fixed
> pre-dividers. Additionally, provide several new DCXO gate clocks for
> peripherals, including SerDes, HDMI, and UFS.
This work looks nice, but I have some questions/comments:
- you're missing RTC SPI clock, which is needed for RTC, at least according
to vendor 5.15 DT. Could it be that this bit set by vendor U-Boot so you
missed it during testing? Manual says that it's disabled by default.
- Vendor DT has strange RTC CCU phandles for UFS and HDMI. In first case
uses RTC wakeup and in second DCXO, which doesn't make any sense. Did you
do any experimentation with these clocks? It wouldn't be the first time
that either code or manual contained some kind of error.
Btw, switch last two patches. With current order during bisection you would
get a complaint that A733 RTC CCU driver is not present.
Best regards,
Jernej
^ permalink raw reply
* [GIT PULL] RTC for 7.0
From: Alexandre Belloni @ 2026-02-22 1:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-rtc, linux-kernel
Hello Linus,
Here is the RTC subsystem pull request for 7.0. There are a few fixes
and improvement this cycle.
The following changes since commit 8f0b4cce4481fb22653697cced8d0d04027cb1e8:
Linux 6.19-rc1 (2025-12-14 16:05:07 +1200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-7.0
for you to fetch changes up to 969c3cca0f3b88682cd833cee4cf01b0915629a3:
rtc: ds1390: fix number of bytes read from RTC (2026-02-20 23:12:25 +0100)
----------------------------------------------------------------
RTC for 7.0
Drivers:
- loongson: Loongson-2K0300 support
- s35390a: nvmem support
- zynqmp: rework calibration
----------------------------------------------------------------
Andreas Gabriel-Platschek (1):
rtc: ds1390: fix number of bytes read from RTC
Anthony Pighin (Nokia) (1):
rtc: interface: Alarm race handling should not discard preceding error
Binbin Zhou (3):
dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
dt-bindings: rtc: loongson: Document Loongson-2K0300 compatible
rtc: loongson: Add Loongson-2K0300 support
Jinjie Ruan (1):
rtc: class: Remove duplicate check for alarm
John Keeping (1):
rtc: pcf8563: use correct of_node for output clock
Lorenz Brun (1):
rtc: s35390a: implement nvmem support
Ovidiu Panait (1):
dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2N support
Peter Robinson (1):
rtc: nvvrs: Add ARCH_TEGRA to the NV VRS RTC driver
Randy Dunlap (1):
rtc: max31335: use correct CONFIG symbol in IS_REACHABLE()
Rouven Czerwinski (1):
rtc: optee: simplify OP-TEE context match
Sebastian Andrzej Siewior (1):
rtc: amlogic-a4: Remove IRQF_ONESHOT
Svyatoslav Ryhel (1):
dt-bindings: rtc: cpcap: convert to schema
Tomas Melin (5):
rtc: zynqmp: correct frequency value
rtc: zynqmp: check calibration max value
rtc: zynqmp: rework read_offset
rtc: zynqmp: rework set_offset
rtc: zynqmp: use dynamic max and min offset ranges
.../devicetree/bindings/rtc/cpcap-rtc.txt | 18 ------
.../devicetree/bindings/rtc/loongson,rtc.yaml | 13 ++++
.../bindings/rtc/motorola,cpcap-rtc.yaml | 32 +++++++++
.../devicetree/bindings/rtc/renesas,rz-rtca3.yaml | 5 +-
drivers/rtc/Kconfig | 1 +
drivers/rtc/class.c | 2 +-
drivers/rtc/interface.c | 2 +-
drivers/rtc/rtc-amlogic-a4.c | 2 +-
drivers/rtc/rtc-ds1390.c | 2 +-
drivers/rtc/rtc-loongson.c | 71 +++++++++++++-------
drivers/rtc/rtc-max31335.c | 6 +-
drivers/rtc/rtc-optee.c | 5 +-
drivers/rtc/rtc-pcf8563.c | 2 +-
drivers/rtc/rtc-s35390a.c | 32 +++++++++
drivers/rtc/rtc-zynqmp.c | 75 ++++++++++++----------
15 files changed, 179 insertions(+), 89 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
create mode 100644 Documentation/devicetree/bindings/rtc/motorola,cpcap-rtc.yaml
--
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-22 0:05 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Rafael J. Wysocki, Alvin 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
In-Reply-To: <DGKPPQI0QE73.S8I1M5NCI2BV@kernel.org>
On 21/02/2026 15:33:48+0100, Danilo Krummrich wrote:
> 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.
>
This still doesn't explain how you get the class private data that you
need when you are in a driver callback that is called from the bus (e.g.
suspend/resume) from what you explain, the driver doesn't have any
chance to pass it. The whole goal of a device driver is to be the glue
between a class device and a bus device as essentially this is the exact
physical device, just represented differently.
An i2c RTC is not either an i2c device or an RTC, it is a single device
and we need to be able to tell the framework when something happens on
the bus or we need to be able to talk on the bus when we want to do
something with the device.
> (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.
>
But what you explain here is that the drive is forbidden to use
rtc->dev.parent->private_data at all because the rust core is already
using it. What I'm saying is that it won't work because more than half
of the drivers currently need it.
I get that you are trying to avoid most of the issues by using devres
but I'm pretty sure there are cases where this doesn't work.
> 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.
>
The whole point of the RTC is to outlive the system but as Linux can't do
anything with the RTC unless it has a bus device to talk to, the class
device and the bus device have the exact same lifetime and we do handle
device appearing and disappearing from the bus. You may think RTC
drivers afe simple but there are plenty of lifetime issues that you will
never get with any other devices because they simply die with the
system.
--
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: Danilo Krummrich @ 2026-02-21 17:53 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Alvin 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: <20260221111619162a41a1@mail.local>
On Sat Feb 21, 2026 at 12:16 PM CET, 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?
I think you misunderstand what Alvin is saying here. We do have bus device
private data in all drivers. It's just that drivers do not set it randomly
through dev_set_drvdata() et al. Please see [1] for details.
[1] https://lore.kernel.org/all/DGKPPQI0QE73.S8I1M5NCI2BV@kernel.org/
^ permalink raw reply
* 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
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