* Re: [PATCH v2 2/3] dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
From: Binbin Zhou @ 2026-01-07 1:22 UTC (permalink / raw)
To: Rob Herring
Cc: Binbin Zhou, Huacai Chen, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, linux-rtc, Xiaochuang Mao, Huacai Chen,
Xuerui Wang, loongarch, devicetree, linux-mips, Keguang Zhang
In-Reply-To: <20260106191314.GA2568583-robh@kernel.org>
Hi Rob:
Thanks for your review.
On Wed, Jan 7, 2026 at 3:13 AM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jan 06, 2026 at 09:33:32AM +0800, Binbin Zhou wrote:
> > Add "loongson,ls2k0300-rtc" dedicated compatible to represent the RTC
> > interface of the Loongson-2K0300 chip.
> >
> > Its hardware design is similar to that of the Loongson-1B, but it does
> > not support the alarm feature.
>
> But you are requiring the interrupt property for it? Isn't it no alarm
> feature means no interrupt?
Yes, the `interrupts` attribute is not required without the alarm feature.
But my judgment condition is `not contains` (added in patch-1[1]).
There are only a few SoCs on the Loongson platform that don't support
the RTC alarm feature, so I think `not contains` looks cleaner and
simpler.
[1]: https://lore.kernel.org/all/8876bebaf08121bb5edd2500f5289284b75df011.1767663073.git.zhoubinbin@loongson.cn/
>
> >
> > Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> > ---
> > Documentation/devicetree/bindings/rtc/loongson,rtc.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > index 8a2520f963d8..b62419c33fd5 100644
> > --- a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > @@ -23,6 +23,7 @@ properties:
> > - loongson,ls1b-rtc
> > - loongson,ls1c-rtc
> > - loongson,ls7a-rtc
> > + - loongson,ls2k0300-rtc
> > - loongson,ls2k1000-rtc
> > - items:
> > - enum:
> > @@ -49,6 +50,7 @@ if:
> > contains:
> > enum:
> > - loongson,ls1c-rtc
> > + - loongson,ls2k0300-rtc
> >
> > then:
> > required:
> > --
> > 2.47.3
> >
--
Thanks.
Binbin
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
From: Rob Herring @ 2026-01-06 19:13 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, linux-rtc, Xiaochuang Mao, Huacai Chen,
Xuerui Wang, loongarch, devicetree, linux-mips, Keguang Zhang
In-Reply-To: <8876bebaf08121bb5edd2500f5289284b75df011.1767663073.git.zhoubinbin@loongson.cn>
On Tue, Jan 06, 2026 at 09:33:32AM +0800, Binbin Zhou wrote:
> Add "loongson,ls2k0300-rtc" dedicated compatible to represent the RTC
> interface of the Loongson-2K0300 chip.
>
> Its hardware design is similar to that of the Loongson-1B, but it does
> not support the alarm feature.
But you are requiring the interrupt property for it? Isn't it no alarm
feature means no interrupt?
>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> ---
> Documentation/devicetree/bindings/rtc/loongson,rtc.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> index 8a2520f963d8..b62419c33fd5 100644
> --- a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> @@ -23,6 +23,7 @@ properties:
> - loongson,ls1b-rtc
> - loongson,ls1c-rtc
> - loongson,ls7a-rtc
> + - loongson,ls2k0300-rtc
> - loongson,ls2k1000-rtc
> - items:
> - enum:
> @@ -49,6 +50,7 @@ if:
> contains:
> enum:
> - loongson,ls1c-rtc
> + - loongson,ls2k0300-rtc
>
> then:
> required:
> --
> 2.47.3
>
^ permalink raw reply
* Re: [RFC PATCH v1 4/4] rust: add PL031 RTC driver
From: Greg Kroah-Hartman @ 2026-01-06 15:12 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Ke Sun, Ke Sun, Rafael J. Wysocki, Alexandre Belloni,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux
In-Reply-To: <DFHLJSVBLDJS.1XEHCP2E0K47@kernel.org>
On Tue, Jan 06, 2026 at 04:04:00PM +0100, Danilo Krummrich wrote:
> On Tue Jan 6, 2026 at 3:44 PM CET, Greg Kroah-Hartman wrote:
> > On Tue, Jan 06, 2026 at 02:32:56PM +0100, Danilo Krummrich wrote:
> >> (Cc: Greg, Rafael)
> >>
> >> On Tue Jan 6, 2026 at 3:51 AM CET, Ke Sun wrote:
> >> > Following the platform driver implementation, the AMBA driver stores its
> >> > drvdata in amba_device->dev. However,
> >> > the RTC driver also stores its drvdata in the parent device (which is
> >> > also amba_device->dev), causing a conflict.
> >
> > Wait, what? That's broken in the C implementation, please, let's fix
> > that up now first. drvdata is ONLY for the specific device that driver
> > is attached to, it can not be used by anyone else.
>
> The C RTC class device implementation passes its parent device to all its
> callbacks, so the driver can obtain the device private data of the parent (bus)
> device.
Ugh :(
> The RTC core does only provide devres guarded registration functions and does
> some synchronization in devm_rtc_unregister_device() [1], such that no RTC class
> device callbacks can happen after the parent (bus) device is unbound (which is
> great).
>
> So, technically it doesn't seem to be broken, but given the rationale in my
> previous reply, I dislike that there is no separation of ownership and lifetime
> due to not separating bus and class device private data.
>
> [1] https://elixir.bootlin.com/linux/v6.19-rc4/source/drivers/rtc/class.c#L340
I agree, this should be fixed up somehow...
^ permalink raw reply
* Re: [RFC PATCH v1 4/4] rust: add PL031 RTC driver
From: Danilo Krummrich @ 2026-01-06 15:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ke Sun, Ke Sun, Rafael J. Wysocki, Alexandre Belloni,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux
In-Reply-To: <2026010631-verbally-probably-3ec2@gregkh>
On Tue Jan 6, 2026 at 3:44 PM CET, Greg Kroah-Hartman wrote:
> On Tue, Jan 06, 2026 at 02:32:56PM +0100, Danilo Krummrich wrote:
>> (Cc: Greg, Rafael)
>>
>> On Tue Jan 6, 2026 at 3:51 AM CET, Ke Sun wrote:
>> > Following the platform driver implementation, the AMBA driver stores its
>> > drvdata in amba_device->dev. However,
>> > the RTC driver also stores its drvdata in the parent device (which is
>> > also amba_device->dev), causing a conflict.
>
> Wait, what? That's broken in the C implementation, please, let's fix
> that up now first. drvdata is ONLY for the specific device that driver
> is attached to, it can not be used by anyone else.
The C RTC class device implementation passes its parent device to all its
callbacks, so the driver can obtain the device private data of the parent (bus)
device.
The RTC core does only provide devres guarded registration functions and does
some synchronization in devm_rtc_unregister_device() [1], such that no RTC class
device callbacks can happen after the parent (bus) device is unbound (which is
great).
So, technically it doesn't seem to be broken, but given the rationale in my
previous reply, I dislike that there is no separation of ownership and lifetime
due to not separating bus and class device private data.
[1] https://elixir.bootlin.com/linux/v6.19-rc4/source/drivers/rtc/class.c#L340
^ permalink raw reply
* Re: [RFC PATCH v1 4/4] rust: add PL031 RTC driver
From: Greg Kroah-Hartman @ 2026-01-06 14:44 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Ke Sun, Ke Sun, Rafael J. Wysocki, Alexandre Belloni,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux
In-Reply-To: <DFHJM2HAG7Q3.1HGZ3P7H55FD2@kernel.org>
On Tue, Jan 06, 2026 at 02:32:56PM +0100, Danilo Krummrich wrote:
> (Cc: Greg, Rafael)
>
> On Tue Jan 6, 2026 at 3:51 AM CET, Ke Sun wrote:
> > Following the platform driver implementation, the AMBA driver stores its
> > drvdata in amba_device->dev. However,
> > the RTC driver also stores its drvdata in the parent device (which is
> > also amba_device->dev), causing a conflict.
Wait, what? That's broken in the C implementation, please, let's fix
that up now first. drvdata is ONLY for the specific device that driver
is attached to, it can not be used by anyone else.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 00/17] tee: Use bus callbacks instead of driver callbacks
From: Sudeep Holla @ 2026-01-06 13:40 UTC (permalink / raw)
To: Jens Wiklander
Cc: Alexandre Belloni, Sudeep Holla, Uwe Kleine-König,
Jonathan Corbet, Sumit Garg, Olivia Mackall, Herbert Xu,
Clément Léger, Ard Biesheuvel, Maxime Coquelin,
Alexandre Torgue, Sumit Garg, Ilias Apalodimas, Jan Kiszka,
Christophe JAILLET, Rafał Miłecki, Michael Chan,
Pavan Chebbi, James Bottomley, Jarkko Sakkinen, Mimi Zohar,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
Peter Huewe, op-tee, linux-kernel, linux-doc, linux-crypto,
linux-rtc, linux-efi, linux-stm32, linux-arm-kernel,
Cristian Marussi, arm-scmi, linux-mips, netdev, linux-integrity,
keyrings, linux-security-module, Jason Gunthorpe
In-Reply-To: <CAHUa44HqRbCJTXsrTCm0G5iwtkQtq+Si=yOspCjpAn-N2uVSVg@mail.gmail.com>
On Mon, Jan 05, 2026 at 10:16:09AM +0100, Jens Wiklander wrote:
> Hi,
>
> On Thu, Dec 18, 2025 at 5:29 PM Jens Wiklander
> <jens.wiklander@linaro.org> wrote:
> >
> > On Thu, Dec 18, 2025 at 2:53 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > >
> > > On 18/12/2025 08:21:27+0100, Jens Wiklander wrote:
> > > > Hi,
> > > >
> > > > On Mon, Dec 15, 2025 at 3:17 PM Uwe Kleine-König
> > > > <u.kleine-koenig@baylibre.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > the objective of this series is to make tee driver stop using callbacks
> > > > > in struct device_driver. These were superseded by bus methods in 2006
> > > > > (commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
> > > > > methods.")) but nobody cared to convert all subsystems accordingly.
> > > > >
> > > > > Here the tee drivers are converted. The first commit is somewhat
> > > > > unrelated, but simplifies the conversion (and the drivers). It
> > > > > introduces driver registration helpers that care about setting the bus
> > > > > and owner. (The latter is missing in all drivers, so by using these
> > > > > helpers the drivers become more correct.)
> > > > >
> > > > > v1 of this series is available at
> > > > > https://lore.kernel.org/all/cover.1765472125.git.u.kleine-koenig@baylibre.com
> > > > >
> > > > > Changes since v1:
> > > > >
> > > > > - rebase to v6.19-rc1 (no conflicts)
> > > > > - add tags received so far
> > > > > - fix whitespace issues pointed out by Sumit Garg
> > > > > - fix shutdown callback to shutdown and not remove
> > > > >
> > > > > As already noted in v1's cover letter, this series should go in during a
> > > > > single merge window as there are runtime warnings when the series is
> > > > > only applied partially. Sumit Garg suggested to apply the whole series
> > > > > via Jens Wiklander's tree.
> > > > > If this is done the dependencies in this series are honored, in case the
> > > > > plan changes: Patches #4 - #17 depend on the first two.
> > > > >
> > > > > Note this series is only build tested.
> > > > >
> > > > > Uwe Kleine-König (17):
> > > > > tee: Add some helpers to reduce boilerplate for tee client drivers
> > > > > tee: Add probe, remove and shutdown bus callbacks to tee_client_driver
> > > > > tee: Adapt documentation to cover recent additions
> > > > > hwrng: optee - Make use of module_tee_client_driver()
> > > > > hwrng: optee - Make use of tee bus methods
> > > > > rtc: optee: Migrate to use tee specific driver registration function
> > > > > rtc: optee: Make use of tee bus methods
> > > > > efi: stmm: Make use of module_tee_client_driver()
> > > > > efi: stmm: Make use of tee bus methods
> > > > > firmware: arm_scmi: optee: Make use of module_tee_client_driver()
> > > > > firmware: arm_scmi: Make use of tee bus methods
> > > > > firmware: tee_bnxt: Make use of module_tee_client_driver()
> > > > > firmware: tee_bnxt: Make use of tee bus methods
> > > > > KEYS: trusted: Migrate to use tee specific driver registration
> > > > > function
> > > > > KEYS: trusted: Make use of tee bus methods
> > > > > tpm/tpm_ftpm_tee: Make use of tee specific driver registration
> > > > > tpm/tpm_ftpm_tee: Make use of tee bus methods
> > > > >
> > > > > Documentation/driver-api/tee.rst | 18 +----
> > > > > drivers/char/hw_random/optee-rng.c | 26 ++----
> > > > > drivers/char/tpm/tpm_ftpm_tee.c | 31 +++++---
> > > > > drivers/firmware/arm_scmi/transports/optee.c | 32 +++-----
> > > > > drivers/firmware/broadcom/tee_bnxt_fw.c | 30 ++-----
> > > > > drivers/firmware/efi/stmm/tee_stmm_efi.c | 25 ++----
> > > > > drivers/rtc/rtc-optee.c | 27 ++-----
> > > > > drivers/tee/tee_core.c | 84 ++++++++++++++++++++
> > > > > include/linux/tee_drv.h | 12 +++
> > > > > security/keys/trusted-keys/trusted_tee.c | 17 ++--
> > > > > 10 files changed, 164 insertions(+), 138 deletions(-)
> > > > >
> > > > > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> > > > > --
> > > > > 2.47.3
> > > > >
> > > >
> > > > Thank you for the nice cleanup, Uwe.
> > > >
> > > > I've applied patch 1-3 to the branch tee_bus_callback_for_6.20 in my
> > > > tree at https://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git/
> > > >
> > > > The branch is based on v6.19-rc1, and I'll try to keep it stable for
> > > > others to depend on, if needed. Let's see if we can agree on taking
> > > > the remaining patches via that branch.
> > >
> > > 6 and 7 can go through your branch.
> >
> > Good, I've added them to my branch now.
>
> This entire patch set should go in during a single merge window. I
> will not send any pull request until I'm sure all patches will be
> merged.
>
> So far (if I'm not mistaken), only the patches I've already added to
> next have appeared next. I can take the rest of the patches, too, but
> I need OK for the following:
>
[...]
>
> Sudeep, you seem happy with the following patches
> - firmware: arm_scmi: optee: Make use of module_tee_client_driver()
> - firmware: arm_scmi: Make use of tee bus methods
> OK if I take them via my tree, or would you rather take them yourself?
>
I am happy if you want to take all of them in one go. I think I have
already acked it. Please shout if you need anything else from me, happy to
help in anyway to make it easier to handle this change set.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC PATCH v1 4/4] rust: add PL031 RTC driver
From: Danilo Krummrich @ 2026-01-06 13:32 UTC (permalink / raw)
To: Ke Sun
Cc: Ke Sun, Greg Kroah-Hartman, Rafael J. Wysocki, Alexandre Belloni,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux
In-Reply-To: <88b1a3dd-e646-4583-bc41-07ff7e9422a7@gmail.com>
(Cc: Greg, Rafael)
On Tue Jan 6, 2026 at 3:51 AM CET, Ke Sun wrote:
> Following the platform driver implementation, the AMBA driver stores its
> drvdata in amba_device->dev. However,
> the RTC driver also stores its drvdata in the parent device (which is
> also amba_device->dev), causing a conflict.
A simple driver usually has two devices to deal with:
(1) The bus device, which represents the actual physical device sitting on
some bus, e.g. PCI or platform.
(2) A class device, which represents the higher level functionality - i.e. the
class the device belongs to - to the upper layers, e.g. RTC, DRM, PWM,
etc.
The bus device does not belong to the driver per se, it only gets bound to a
driver. This relationship remains until the driver itself is unregistered, the
physical device falls off the bus or they are manually unbound from each other.
The driver's bus device private data only lives as long as the two are bound and
the lifetime is managed by the bus abstraction, e.g. platform or AMBA.
The class device is created by the driver to represent its functionality to the
upper layers; its lifetime is defined by the driver.
Other than the bus device private data, the class device private data typically
lives as long as the class device itself.
In the relationship between the two, the bus device becomes the parent device of
the class device.
If the class device implementation guarantees that it is unregistered when the
parent (bus) device is unbound (which is the most common case), i.e. no more
class device callbacks happen afterwards, the abstraction can treat the parent
device as &Device<Bound>, which allows drivers to directly access device
resources from the parent device without further synchronization.
The short answer for your question is, store the class device private data
within the class device itself, not within the parent device.
Alternatively, if the class device implementation does guarantee that in all its
callbacks the parent device is bound, i.e. you have a &Device<Bound>, you can
also access the bus device private data with Device<Bound>::drvdata().
In this case you can technically also omit having separate private data for the
class device at all.
However, while this is actually been done in quite some C drivers, I do not
recommend this:
- At least in C this can become pretty error prone, given that bus device
resources are only valid to access as long as the device is bound to the
driver; in Rust we do protect against device resource accesses after driver
unbind though.
- Separating the private data properly encourages driver authors to actually
think about ownership and lifetime of objects, eventually leading to better
driver design.
A common pattern you will see in drivers is that the data relevant for the class
device goes into the class device private data and the class device itself is
stored within the bus device private data.
I hope this helps!
- Danilo
^ permalink raw reply
* Re: [PATCH v2 00/17] tee: Use bus callbacks instead of driver callbacks
From: Jon Hunter @ 2026-01-06 9:39 UTC (permalink / raw)
To: Uwe Kleine-König, Jens Wiklander, Jonathan Corbet,
Sumit Garg, Olivia Mackall, Herbert Xu, Clément Léger,
Alexandre Belloni, Ard Biesheuvel, Maxime Coquelin,
Alexandre Torgue, Sumit Garg, Ilias Apalodimas, Jan Kiszka,
Sudeep Holla, Christophe JAILLET, Rafał Miłecki,
Michael Chan, Pavan Chebbi, James Bottomley, Jarkko Sakkinen,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Peter Huewe
Cc: op-tee, linux-kernel, linux-doc, linux-crypto, linux-rtc,
linux-efi, linux-stm32, linux-arm-kernel, Cristian Marussi,
arm-scmi, linux-mips, netdev, linux-integrity, keyrings,
linux-security-module, Jason Gunthorpe,
linux-tegra@vger.kernel.org
In-Reply-To: <cover.1765791463.git.u.kleine-koenig@baylibre.com>
Hi Uwe,
On 15/12/2025 14:16, Uwe Kleine-König wrote:
> Hello,
>
> the objective of this series is to make tee driver stop using callbacks
> in struct device_driver. These were superseded by bus methods in 2006
> (commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
> methods.")) but nobody cared to convert all subsystems accordingly.
>
> Here the tee drivers are converted. The first commit is somewhat
> unrelated, but simplifies the conversion (and the drivers). It
> introduces driver registration helpers that care about setting the bus
> and owner. (The latter is missing in all drivers, so by using these
> helpers the drivers become more correct.)
>
> v1 of this series is available at
> https://lore.kernel.org/all/cover.1765472125.git.u.kleine-koenig@baylibre.com
>
> Changes since v1:
>
> - rebase to v6.19-rc1 (no conflicts)
> - add tags received so far
> - fix whitespace issues pointed out by Sumit Garg
> - fix shutdown callback to shutdown and not remove
>
> As already noted in v1's cover letter, this series should go in during a
> single merge window as there are runtime warnings when the series is
> only applied partially. Sumit Garg suggested to apply the whole series
> via Jens Wiklander's tree.
> If this is done the dependencies in this series are honored, in case the
> plan changes: Patches #4 - #17 depend on the first two.
>
> Note this series is only build tested.
>
> Uwe Kleine-König (17):
> tee: Add some helpers to reduce boilerplate for tee client drivers
> tee: Add probe, remove and shutdown bus callbacks to tee_client_driver
> tee: Adapt documentation to cover recent additions
> hwrng: optee - Make use of module_tee_client_driver()
> hwrng: optee - Make use of tee bus methods
> rtc: optee: Migrate to use tee specific driver registration function
> rtc: optee: Make use of tee bus methods
> efi: stmm: Make use of module_tee_client_driver()
> efi: stmm: Make use of tee bus methods
> firmware: arm_scmi: optee: Make use of module_tee_client_driver()
> firmware: arm_scmi: Make use of tee bus methods
> firmware: tee_bnxt: Make use of module_tee_client_driver()
> firmware: tee_bnxt: Make use of tee bus methods
> KEYS: trusted: Migrate to use tee specific driver registration
> function
> KEYS: trusted: Make use of tee bus methods
> tpm/tpm_ftpm_tee: Make use of tee specific driver registration
> tpm/tpm_ftpm_tee: Make use of tee bus methods
On the next-20260105 I am seeing the following warnings ...
WARNING KERN Driver 'optee-rng' needs updating - please use bus_type methods
WARNING KERN Driver 'scmi-optee' needs updating - please use bus_type methods
WARNING KERN Driver 'tee_bnxt_fw' needs updating - please use bus_type methods
I bisected the first warning and this point to the following
commit ...
# first bad commit: [a707eda330b932bcf698be9460e54e2f389e24b7] tee: Add some helpers to reduce boilerplate for tee client drivers
I have not bisected the others, but guess they are related
to this series. Do you observe the same?
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [RFC PATCH v1 0/4] rust: Add RTC driver support
From: Kari Argillander @ 2026-01-06 7:41 UTC (permalink / raw)
To: Ke Sun
Cc: Alexandre Belloni, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, linux-rtc, rust-for-linux,
Alvin Sun
In-Reply-To: <20260104060621.3757812-1-sunke@kylinos.cn>
On Sun, 4 Jan 2026 at 08:06, Ke Sun <sunke@kylinos.cn> wrote:
>
> This patch series adds RTC (Real-Time Clock) driver support for the Rust
> kernel, including the necessary infrastructure and a complete driver implementation
> for the ARM AMBA PrimeCell 031 RTC.
>
> The implementation provides a generic RTC framework supporting multiple bus types
> (Platform, AMBA, I2C) and demonstrates its usage with a complete PL031 RTC driver.
>
> ---
> v1:
> - Add AMBA bus abstractions
> - Add device wakeup support
> - Add RTC core framework with multi-bus support
> - Add PL031 RTC driver
> ---
>
> Ke Sun (4):
> rust: add AMBA bus abstractions
> rust: add device wakeup support
> rust: add RTC core abstractions and data structures
> rust: add PL031 RTC driver
>
> drivers/rtc/Kconfig | 11 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc_pl031_rust.rs | 529 ++++++++++
> rust/bindings/bindings_helper.h | 3 +
> rust/helpers/device.c | 7 +
> rust/helpers/helpers.c | 1 +
> rust/helpers/rtc.c | 9 +
> rust/kernel/amba.rs | 234 +++++
> rust/kernel/device.rs | 35 +
> rust/kernel/lib.rs | 4 +
> rust/kernel/rtc.rs | 1710 +++++++++++++++++++++++++++++++
> 11 files changed, 2544 insertions(+)
> create mode 100644 drivers/rtc/rtc_pl031_rust.rs
> create mode 100644 rust/helpers/rtc.c
> create mode 100644 rust/kernel/amba.rs
> create mode 100644 rust/kernel/rtc.rs
These files needs `MAINTAINERS` entry. It depends on maintainers do they prefer
that these are added current ones, made sub-entries or make new [RUST] one.
Probably easiest is just add to current ones and then it easier to discuss about
this in PR reviews. Then at least `MAINTAINERS` entry is not forgotten.
> base-commit: 805f9a061372164d43ddef771d7cd63e3ba6d845
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH] rtc: interface: Fix softlockup in rtc_timer_do_work()
From: Jinjie Ruan @ 2026-01-06 6:24 UTC (permalink / raw)
To: alexandre.belloni, linux-rtc, linux-kernel
In-Reply-To: <20251231092321.3787542-1-ruanjinjie@huawei.com>
On 2025/12/31 17:23, Jinjie Ruan wrote:
> On kvm qemu with cmos rtc and mc146818 chip, when the read time jump to
> a future time after set the uie timer expire with a current RTC time,
> rtc_timer_do_work() will loop for a while util softlockup because
> the expiration of the uie timer was way before the current
> RTC time and a new timer will be enqueued until the current rtc time
> is reached, as below:
>
> Fix it by voluntarily yield the CPU in the loop in rtc_timer_do_work().
>
> RTC_UIE_ON:
> read now: 2019:04:08:12:32:27, add timer0 (expire: 2019:04:08:12:32:28)
> ^^^^^^^^^^^^^^^^^^^^
> ...
> rtc_timer_do_work() iterate the list in a loop:
> read now: 2033:12:02:07:27:15
Please ignore, this seems to be a bug in QEMU.
> ^^^^^^^^^^^^^^^^^^^
> handle timer0, add timer1 to the list (expire: 2019:04:08:12:32:29)
> handle timer1, add timer2 to the list (expire: 2019:04:08:12:32:30)
> handle timer2, add timer3: 2019:04:08:12:32:31
> ...
> -> softlockup
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> drivers/rtc/interface.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index b8b298efd9a9..9ded10e82f4b 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -964,6 +964,7 @@ void rtc_timer_do_work(struct work_struct *work)
> timer->enabled = 1;
> timerqueue_add(&rtc->timerqueue, &timer->node);
> trace_rtc_timer_enqueue(timer);
> + cond_resched();
> }
> }
>
^ permalink raw reply
* Re: [PATCH v2 00/17] tee: Use bus callbacks instead of driver callbacks
From: Herbert Xu @ 2026-01-06 5:04 UTC (permalink / raw)
To: Jens Wiklander
Cc: Alexandre Belloni, Uwe Kleine-König, Jonathan Corbet,
Sumit Garg, Olivia Mackall, Clément Léger,
Ard Biesheuvel, Maxime Coquelin, Alexandre Torgue, Sumit Garg,
Ilias Apalodimas, Jan Kiszka, Sudeep Holla, Christophe JAILLET,
Rafał Miłecki, Michael Chan, Pavan Chebbi,
James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
Paul Moore, James Morris, Serge E. Hallyn, Peter Huewe, op-tee,
linux-kernel, linux-doc, linux-crypto, linux-rtc, linux-efi,
linux-stm32, linux-arm-kernel, Cristian Marussi, arm-scmi,
linux-mips, netdev, linux-integrity, keyrings,
linux-security-module, Jason Gunthorpe
In-Reply-To: <CAHUa44HqRbCJTXsrTCm0G5iwtkQtq+Si=yOspCjpAn-N2uVSVg@mail.gmail.com>
On Mon, Jan 05, 2026 at 10:16:09AM +0100, Jens Wiklander wrote:
>
> Herbert, you seem happy with the following patches
> - hwrng: optee - Make use of module_tee_client_driver()
> - hwrng: optee - Make use of tee bus methods
> OK if I take them via my tree, or would you rather take them yourself?
Feel free to take them through your tree.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC PATCH v1 4/4] rust: add PL031 RTC driver
From: Ke Sun @ 2026-01-06 2:51 UTC (permalink / raw)
To: Danilo Krummrich, Ke Sun
Cc: Alexandre Belloni, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux
In-Reply-To: <DFFTVRMAFF3S.13N6WCNAVVR6I@kernel.org>
On 1/4/26 21:10, Danilo Krummrich wrote:
> On Sun Jan 4, 2026 at 7:06 AM CET, Ke Sun wrote:
>> +/// PL031 RTC driver private data.
>> +#[pin_data(PinnedDrop)]
>> +struct Pl031DrvData {
>> + #[pin]
>> + base: Devres<IoMem<0>>,
> Please do not use 0 as generic argument, this should likely be RTC_YLR + 0x4
> (assuming that this register has a width of 32 bit).
>
> It allows you to perform register accesses until RTC_YLR + 0x4 with infallible
> accessors, since the call to IoMem::new() will validate that the memory region
> has at least a size of RTC_YLR + 0x4.
>
>> + variant: VendorVariant,
>> + /// RTC device reference for interrupt handler.
>> + ///
>> + /// Set in `init_rtcdevice` and remains valid for the driver's lifetime
>> + /// because the RTC device is managed by devres.
>> + rtc_device: Option<ARef<RtcDevice>>,
> I don't see a reason for a separate init_rtcdevice() method. Creating the RTC
> device should happen in probe(), which also gets you rid of this odd Option.
>
Hi Danilo,
I encountered an issue while refactoring the RTC abstraction.
Following the platform driver implementation, the AMBA driver stores its
drvdata in amba_device->dev. However,
the RTC driver also stores its drvdata in the parent device (which is
also amba_device->dev), causing a conflict.
This was already encountered in v1, which is why the design was awkward.
Do you have any suggestions on how to address this?
Here is part of the code:
// rust/kernel/amba.rs
impl<T: Driver + 'static> Adapter<T> {
extern "C" fn probe_callback(
adev: *mut bindings::amba_device,
id: *const bindings::amba_id,
) -> kernel::ffi::c_int {
let adev_internal = unsafe {
&*adev.cast::<Device<device::CoreInternal>>() };
let info = Self::amba_id_info(adev_internal, id);
from_result(|| {
let data = T::probe(adev_internal, info);
// Referring to the implementation in platform.rs, here
`dev_set_drvdata(&adev->dev, data)`
// will clobber the value that has already been set in
`amba::Driver::probe`.
adev_internal.as_ref().set_drvdata(data)?;
Ok(0)
})
}
}
// rust/kernel/rtc.rs
impl<T: RtcOps> Adapter<T> {
unsafe extern "C" fn read_time(
dev: *mut bindings::device, // **pointer to the `struct
device` embedded in a `struct amba_device`
tm: *mut bindings::rtc_time,
) -> c_int {
let bound_dev = unsafe {
device::Device::<device::Bound>::from_raw(dev) };
let rtc_tm = unsafe { &mut *tm.cast::<RtcTime>() };
match T::read_time(bound_dev, rtc_tm) {
Ok(()) => 0,
Err(err) => err.to_errno(),
}
}
}
// drivers/rtc/rtc_pl031_rust.rs
impl amba::Driver for Pl031AmbaDriver {
...
fn probe(
adev: &amba::Device<Core>,
id_info: Option<&Self::IdInfo>,
) -> impl PinInit<Self, Error> {
let dev = adev.as_ref();
let io_request = adev.io_request().ok_or(ENODEV)?;
...
// Allocate RTC device.
let rtcdev = RtcDevice::new::<Pl031DrvData>(dev)?;
let rtcdev_clone = rtcdev.clone();
// Set driver data with RTC device reference.
rtcdev.set_drvdata(try_pin_init!(Pl031DrvData {
base <- IoMem::new(io_request),
variant,
rtcdev: rtcdev_clone,
}))?;
...
// Register RTC device.
// **If CONFIG_RTC_HCTOSYS is enabled and the device is rtc0,
rtc_read_time will be
// called during the registration process. This requires
drvdata to be set up before registration.
Registration::register(dev, rtcdev)?;
Ok(Pl031AmbaDriver)
}
}
Best regards,
Ke Sun
>> +}
>> +
>> +// SAFETY: `Pl031DrvData` contains only `Send`/`Sync` types: `Devres` (Send+Sync),
>> +// `VendorVariant` (Copy), and `Option<ARef<RtcDevice>>` (Send+Sync because `RtcDevice` is
>> +// Send+Sync).
>> +unsafe impl Send for Pl031DrvData {}
>> +// SAFETY: `Pl031DrvData` contains only `Send`/`Sync` types: `Devres` (Send+Sync),
>> +// `VendorVariant` (Copy), and `Option<ARef<RtcDevice>>` (Send+Sync because `RtcDevice` is
>> +// Send+Sync).
>> +unsafe impl Sync for Pl031DrvData {}
> Why not implement Send + Sync for RtcDevice then?
>
>> +// Use AMBA device table for matching
>> +kernel::amba_device_table!(
>> + ID_TABLE,
>> + MODULE_ID_TABLE,
>> + <Pl031DrvData as rtc::DriverGeneric<rtc::AmbaBus>>::IdInfo,
>> + [
>> + (
>> + amba::DeviceId::new_with_data(0x00041031, 0x000fffff, Pl031Variant::ARM.to_usize()),
>> + Pl031Variant::ARM
>> + ),
>> + (
>> + amba::DeviceId::new_with_data(0x00180031, 0x00ffffff, Pl031Variant::STV1.to_usize()),
>> + Pl031Variant::STV1
>> + ),
>> + (
>> + amba::DeviceId::new_with_data(0x00280031, 0x00ffffff, Pl031Variant::STV2.to_usize()),
> Why a constructor new_with_data() if you already store data through the generic
> device ID mechanism right below?
>
>> + Pl031Variant::STV2
>> + ),
>> + ]
>> +);
^ permalink raw reply
* Re: [PATCH v2 0/3] RTC: Add Loongson-2K0300 support
From: Huacai Chen @ 2026-01-06 2:48 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, linux-rtc, Xiaochuang Mao,
Xuerui Wang, loongarch, devicetree, linux-mips, Keguang Zhang
In-Reply-To: <cover.1767663073.git.zhoubinbin@loongson.cn>
For the whole series:
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
On Tue, Jan 6, 2026 at 9:34 AM Binbin Zhou <zhoubinbin@loongson.cn> wrote:
>
> Hi all:
>
> This patch set introduces the Loongson-2K0300 RTC, which has a similar
> hardware design to the Loongson-1B, but without the alarm feature.
>
> Thanks.
> Binbin
>
> ==========
> V2:
> Patch (1/3):
> - New patch, correct Loongson-1C `interrupts` property;
>
> Patch (2/3):
> - Drop Loongson-1C changes;
>
> Patch (3/3):
> - Rename LS1C_RTC_CTRL_WORKAROUND to LOONGSON_RTC_CTRL_WORKAROUND for
> consistency.
>
> Link to V1:
> https://lore.kernel.org/all/cover.1766471839.git.zhoubinbin@loongson.cn/
>
> Binbin Zhou (3):
> dt-binding: rtc: loongson: Correct Loongson-1C interrupts property
> dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
> rtc: loongson: Add Loongson-2K0300 support
>
> .../devicetree/bindings/rtc/loongson,rtc.yaml | 14 ++++
> drivers/rtc/rtc-loongson.c | 71 ++++++++++++-------
> 2 files changed, 61 insertions(+), 24 deletions(-)
>
>
> base-commit: 16bd954c93360145bc77cc601e350913fc28182d
> --
> 2.47.3
>
^ permalink raw reply
* [PATCH v2 3/3] rtc: loongson: Add Loongson-2K0300 support
From: Binbin Zhou @ 2026-01-06 1:33 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, linux-rtc
Cc: Xiaochuang Mao, Huacai Chen, Xuerui Wang, loongarch, devicetree,
linux-mips, Keguang Zhang, Binbin Zhou
In-Reply-To: <cover.1767663073.git.zhoubinbin@loongson.cn>
The Loongson-2K0300's rtc hardware design is similar to that of the
Loongson-1B, but it does not support the alarm feature.
Introduce `LOONGSON_RTC_ALARM_WORKAROUND`, which indicates a chip that
does not support the alarm feature, and rewrite the related logic in
`loongson_rtc_alarm_setting()`.
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
drivers/rtc/rtc-loongson.c | 71 +++++++++++++++++++++++++-------------
1 file changed, 47 insertions(+), 24 deletions(-)
diff --git a/drivers/rtc/rtc-loongson.c b/drivers/rtc/rtc-loongson.c
index 2ca7ffd5d7a9..066f0644d1c3 100644
--- a/drivers/rtc/rtc-loongson.c
+++ b/drivers/rtc/rtc-loongson.c
@@ -66,7 +66,8 @@
* According to the LS1C manual, RTC_CTRL and alarm-related registers are not defined.
* Accessing the relevant registers will cause the system to hang.
*/
-#define LS1C_RTC_CTRL_WORKAROUND BIT(0)
+#define LOONGSON_RTC_CTRL_WORKAROUND BIT(0)
+#define LOONGSON_RTC_ALARM_WORKAROUND BIT(1)
struct loongson_rtc_config {
u32 pm_offset; /* Offset of PM domain, for RTC alarm wakeup */
@@ -89,7 +90,7 @@ static const struct loongson_rtc_config ls1b_rtc_config = {
static const struct loongson_rtc_config ls1c_rtc_config = {
.pm_offset = 0,
- .flags = LS1C_RTC_CTRL_WORKAROUND,
+ .flags = LOONGSON_RTC_CTRL_WORKAROUND | LOONGSON_RTC_ALARM_WORKAROUND,
};
static const struct loongson_rtc_config generic_rtc_config = {
@@ -97,6 +98,11 @@ static const struct loongson_rtc_config generic_rtc_config = {
.flags = 0,
};
+static const struct loongson_rtc_config ls2k0300_rtc_config = {
+ .pm_offset = 0x0,
+ .flags = LOONGSON_RTC_ALARM_WORKAROUND,
+};
+
static const struct loongson_rtc_config ls2k1000_rtc_config = {
.pm_offset = 0x800,
.flags = 0,
@@ -153,7 +159,7 @@ static int loongson_rtc_set_enabled(struct device *dev)
{
struct loongson_rtc_priv *priv = dev_get_drvdata(dev);
- if (priv->config->flags & LS1C_RTC_CTRL_WORKAROUND)
+ if (priv->config->flags & LOONGSON_RTC_CTRL_WORKAROUND)
return 0;
/* Enable RTC TOY counters and crystal */
@@ -167,7 +173,7 @@ static bool loongson_rtc_get_enabled(struct device *dev)
u32 ctrl_data;
struct loongson_rtc_priv *priv = dev_get_drvdata(dev);
- if (priv->config->flags & LS1C_RTC_CTRL_WORKAROUND)
+ if (priv->config->flags & LOONGSON_RTC_CTRL_WORKAROUND)
return true;
ret = regmap_read(priv->regmap, RTC_CTRL_REG, &ctrl_data);
@@ -299,9 +305,41 @@ static const struct rtc_class_ops loongson_rtc_ops = {
.alarm_irq_enable = loongson_rtc_alarm_irq_enable,
};
+static int loongson_rtc_alarm_setting(struct platform_device *pdev, void __iomem *regs)
+{
+ int ret = 0, alarm_irq;
+ struct device *dev = &pdev->dev;
+ struct loongson_rtc_priv *priv = dev_get_drvdata(dev);
+
+ if (priv->config->flags & LOONGSON_RTC_ALARM_WORKAROUND) {
+ /* Loongson-1C/Loongson-2K0300 RTC does not support alarm */
+ clear_bit(RTC_FEATURE_ALARM, priv->rtcdev->features);
+ return 0;
+ }
+
+ /* Get RTC alarm irq */
+ alarm_irq = platform_get_irq(pdev, 0);
+ if (alarm_irq < 0)
+ return alarm_irq;
+
+ ret = devm_request_irq(dev, alarm_irq, loongson_rtc_isr, 0, "loongson-alarm",
+ priv);
+ if (ret < 0)
+ return ret;
+
+ priv->pm_base = regs - priv->config->pm_offset;
+ device_init_wakeup(dev, true);
+
+ if (has_acpi_companion(dev))
+ acpi_install_fixed_event_handler(ACPI_EVENT_RTC,
+ loongson_rtc_handler, priv);
+
+ return ret;
+}
+
static int loongson_rtc_probe(struct platform_device *pdev)
{
- int ret, alarm_irq;
+ int ret;
void __iomem *regs;
struct loongson_rtc_priv *priv;
struct device *dev = &pdev->dev;
@@ -330,25 +368,9 @@ static int loongson_rtc_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(priv->rtcdev),
"devm_rtc_allocate_device failed\n");
- /* Get RTC alarm irq */
- alarm_irq = platform_get_irq(pdev, 0);
- if (alarm_irq > 0) {
- ret = devm_request_irq(dev, alarm_irq, loongson_rtc_isr,
- 0, "loongson-alarm", priv);
- if (ret < 0)
- return dev_err_probe(dev, ret, "Unable to request irq %d\n",
- alarm_irq);
-
- priv->pm_base = regs - priv->config->pm_offset;
- device_init_wakeup(dev, true);
-
- if (has_acpi_companion(dev))
- acpi_install_fixed_event_handler(ACPI_EVENT_RTC,
- loongson_rtc_handler, priv);
- } else {
- /* Loongson-1C RTC does not support alarm */
- clear_bit(RTC_FEATURE_ALARM, priv->rtcdev->features);
- }
+ ret = loongson_rtc_alarm_setting(pdev, regs);
+ if (ret)
+ return ret;
/* Loongson RTC does not support UIE */
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, priv->rtcdev->features);
@@ -379,6 +401,7 @@ static const struct of_device_id loongson_rtc_of_match[] = {
{ .compatible = "loongson,ls1b-rtc", .data = &ls1b_rtc_config },
{ .compatible = "loongson,ls1c-rtc", .data = &ls1c_rtc_config },
{ .compatible = "loongson,ls7a-rtc", .data = &generic_rtc_config },
+ { .compatible = "loongson,ls2k0300-rtc", .data = &ls2k0300_rtc_config },
{ .compatible = "loongson,ls2k1000-rtc", .data = &ls2k1000_rtc_config },
{ /* sentinel */ }
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/3] dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
From: Binbin Zhou @ 2026-01-06 1:33 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, linux-rtc
Cc: Xiaochuang Mao, Huacai Chen, Xuerui Wang, loongarch, devicetree,
linux-mips, Keguang Zhang, Binbin Zhou
In-Reply-To: <cover.1767663073.git.zhoubinbin@loongson.cn>
Add "loongson,ls2k0300-rtc" dedicated compatible to represent the RTC
interface of the Loongson-2K0300 chip.
Its hardware design is similar to that of the Loongson-1B, but it does
not support the alarm feature.
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
Documentation/devicetree/bindings/rtc/loongson,rtc.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
index 8a2520f963d8..b62419c33fd5 100644
--- a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
@@ -23,6 +23,7 @@ properties:
- loongson,ls1b-rtc
- loongson,ls1c-rtc
- loongson,ls7a-rtc
+ - loongson,ls2k0300-rtc
- loongson,ls2k1000-rtc
- items:
- enum:
@@ -49,6 +50,7 @@ if:
contains:
enum:
- loongson,ls1c-rtc
+ - loongson,ls2k0300-rtc
then:
required:
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/3] dt-binding: rtc: loongson: Correct Loongson-1C interrupts property
From: Binbin Zhou @ 2026-01-06 1:33 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, linux-rtc
Cc: Xiaochuang Mao, Huacai Chen, Xuerui Wang, loongarch, devicetree,
linux-mips, Keguang Zhang, Binbin Zhou
In-Reply-To: <cover.1767663073.git.zhoubinbin@loongson.cn>
The `interrupts` property indicates an RTC alarm interrupt, which is only
required for RTCs that support the alarm feature.
As we know, the Loongson-1C RTC does not support the alarm feature, so
it needs to be excluded.
Fixes: 487ef32caebe ("dt-bindings: rtc: Split loongson,ls2x-rtc into SoC-based compatibles")
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
---
.../devicetree/bindings/rtc/loongson,rtc.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
index f89c1f660aee..8a2520f963d8 100644
--- a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
@@ -42,6 +42,18 @@ required:
unevaluatedProperties: false
+if:
+ properties:
+ compatible:
+ not:
+ contains:
+ enum:
+ - loongson,ls1c-rtc
+
+then:
+ required:
+ - interrupts
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/3] RTC: Add Loongson-2K0300 support
From: Binbin Zhou @ 2026-01-06 1:33 UTC (permalink / raw)
To: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, linux-rtc
Cc: Xiaochuang Mao, Huacai Chen, Xuerui Wang, loongarch, devicetree,
linux-mips, Keguang Zhang, Binbin Zhou
Hi all:
This patch set introduces the Loongson-2K0300 RTC, which has a similar
hardware design to the Loongson-1B, but without the alarm feature.
Thanks.
Binbin
==========
V2:
Patch (1/3):
- New patch, correct Loongson-1C `interrupts` property;
Patch (2/3):
- Drop Loongson-1C changes;
Patch (3/3):
- Rename LS1C_RTC_CTRL_WORKAROUND to LOONGSON_RTC_CTRL_WORKAROUND for
consistency.
Link to V1:
https://lore.kernel.org/all/cover.1766471839.git.zhoubinbin@loongson.cn/
Binbin Zhou (3):
dt-binding: rtc: loongson: Correct Loongson-1C interrupts property
dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
rtc: loongson: Add Loongson-2K0300 support
.../devicetree/bindings/rtc/loongson,rtc.yaml | 14 ++++
drivers/rtc/rtc-loongson.c | 71 ++++++++++++-------
2 files changed, 61 insertions(+), 24 deletions(-)
base-commit: 16bd954c93360145bc77cc601e350913fc28182d
--
2.47.3
^ permalink raw reply
* Re: [PATCH v2 00/17] tee: Use bus callbacks instead of driver callbacks
From: Jens Wiklander @ 2026-01-05 9:16 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Uwe Kleine-König, Jonathan Corbet, Sumit Garg,
Olivia Mackall, Herbert Xu, Clément Léger,
Ard Biesheuvel, Maxime Coquelin, Alexandre Torgue, Sumit Garg,
Ilias Apalodimas, Jan Kiszka, Sudeep Holla, Christophe JAILLET,
Rafał Miłecki, Michael Chan, Pavan Chebbi,
James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
Paul Moore, James Morris, Serge E. Hallyn, Peter Huewe, op-tee,
linux-kernel, linux-doc, linux-crypto, linux-rtc, linux-efi,
linux-stm32, linux-arm-kernel, Cristian Marussi, arm-scmi,
linux-mips, netdev, linux-integrity, keyrings,
linux-security-module, Jason Gunthorpe
In-Reply-To: <CAHUa44GpW5aO26GDyL9RZub9vVYvVcJ7etwO0yXBN_mUi0W4AA@mail.gmail.com>
Hi,
On Thu, Dec 18, 2025 at 5:29 PM Jens Wiklander
<jens.wiklander@linaro.org> wrote:
>
> On Thu, Dec 18, 2025 at 2:53 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 18/12/2025 08:21:27+0100, Jens Wiklander wrote:
> > > Hi,
> > >
> > > On Mon, Dec 15, 2025 at 3:17 PM Uwe Kleine-König
> > > <u.kleine-koenig@baylibre.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > the objective of this series is to make tee driver stop using callbacks
> > > > in struct device_driver. These were superseded by bus methods in 2006
> > > > (commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
> > > > methods.")) but nobody cared to convert all subsystems accordingly.
> > > >
> > > > Here the tee drivers are converted. The first commit is somewhat
> > > > unrelated, but simplifies the conversion (and the drivers). It
> > > > introduces driver registration helpers that care about setting the bus
> > > > and owner. (The latter is missing in all drivers, so by using these
> > > > helpers the drivers become more correct.)
> > > >
> > > > v1 of this series is available at
> > > > https://lore.kernel.org/all/cover.1765472125.git.u.kleine-koenig@baylibre.com
> > > >
> > > > Changes since v1:
> > > >
> > > > - rebase to v6.19-rc1 (no conflicts)
> > > > - add tags received so far
> > > > - fix whitespace issues pointed out by Sumit Garg
> > > > - fix shutdown callback to shutdown and not remove
> > > >
> > > > As already noted in v1's cover letter, this series should go in during a
> > > > single merge window as there are runtime warnings when the series is
> > > > only applied partially. Sumit Garg suggested to apply the whole series
> > > > via Jens Wiklander's tree.
> > > > If this is done the dependencies in this series are honored, in case the
> > > > plan changes: Patches #4 - #17 depend on the first two.
> > > >
> > > > Note this series is only build tested.
> > > >
> > > > Uwe Kleine-König (17):
> > > > tee: Add some helpers to reduce boilerplate for tee client drivers
> > > > tee: Add probe, remove and shutdown bus callbacks to tee_client_driver
> > > > tee: Adapt documentation to cover recent additions
> > > > hwrng: optee - Make use of module_tee_client_driver()
> > > > hwrng: optee - Make use of tee bus methods
> > > > rtc: optee: Migrate to use tee specific driver registration function
> > > > rtc: optee: Make use of tee bus methods
> > > > efi: stmm: Make use of module_tee_client_driver()
> > > > efi: stmm: Make use of tee bus methods
> > > > firmware: arm_scmi: optee: Make use of module_tee_client_driver()
> > > > firmware: arm_scmi: Make use of tee bus methods
> > > > firmware: tee_bnxt: Make use of module_tee_client_driver()
> > > > firmware: tee_bnxt: Make use of tee bus methods
> > > > KEYS: trusted: Migrate to use tee specific driver registration
> > > > function
> > > > KEYS: trusted: Make use of tee bus methods
> > > > tpm/tpm_ftpm_tee: Make use of tee specific driver registration
> > > > tpm/tpm_ftpm_tee: Make use of tee bus methods
> > > >
> > > > Documentation/driver-api/tee.rst | 18 +----
> > > > drivers/char/hw_random/optee-rng.c | 26 ++----
> > > > drivers/char/tpm/tpm_ftpm_tee.c | 31 +++++---
> > > > drivers/firmware/arm_scmi/transports/optee.c | 32 +++-----
> > > > drivers/firmware/broadcom/tee_bnxt_fw.c | 30 ++-----
> > > > drivers/firmware/efi/stmm/tee_stmm_efi.c | 25 ++----
> > > > drivers/rtc/rtc-optee.c | 27 ++-----
> > > > drivers/tee/tee_core.c | 84 ++++++++++++++++++++
> > > > include/linux/tee_drv.h | 12 +++
> > > > security/keys/trusted-keys/trusted_tee.c | 17 ++--
> > > > 10 files changed, 164 insertions(+), 138 deletions(-)
> > > >
> > > > base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> > > > --
> > > > 2.47.3
> > > >
> > >
> > > Thank you for the nice cleanup, Uwe.
> > >
> > > I've applied patch 1-3 to the branch tee_bus_callback_for_6.20 in my
> > > tree at https://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git/
> > >
> > > The branch is based on v6.19-rc1, and I'll try to keep it stable for
> > > others to depend on, if needed. Let's see if we can agree on taking
> > > the remaining patches via that branch.
> >
> > 6 and 7 can go through your branch.
>
> Good, I've added them to my branch now.
This entire patch set should go in during a single merge window. I
will not send any pull request until I'm sure all patches will be
merged.
So far (if I'm not mistaken), only the patches I've already added to
next have appeared next. I can take the rest of the patches, too, but
I need OK for the following:
Jarkko, you seem happy with the following patches
- KEYS: trusted: Migrate to use tee specific driver registration function
- KEYS: trusted: Make use of tee bus methods
- tpm/tpm_ftpm_tee: Make use of tee specific driver registration
- tpm/tpm_ftpm_tee: Make use of tee bus methods
OK if I take them via my tree, or would you rather take them yourself?
Herbert, you seem happy with the following patches
- hwrng: optee - Make use of module_tee_client_driver()
- hwrng: optee - Make use of tee bus methods
OK if I take them via my tree, or would you rather take them yourself?
Sudeep, you seem happy with the following patches
- firmware: arm_scmi: optee: Make use of module_tee_client_driver()
- firmware: arm_scmi: Make use of tee bus methods
OK if I take them via my tree, or would you rather take them yourself?
Michael, Pavan, are you OK with the following patches
- firmware: tee_bnxt: Make use of module_tee_client_driver()
- firmware: tee_bnxt: Make use of tee bus methods
OK if I take them via my tree, or would you rather take them yourself?
Thanks,
Jens
^ permalink raw reply
* Re: [RFC PATCH v1 0/4] rust: Add RTC driver support
From: Ke Sun @ 2026-01-04 14:11 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Alexandre Belloni, 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: <DFFUFRMWKRMO.INAMUGECPSQU@kernel.org>
On 1/4/26 21:36, Danilo Krummrich wrote:
> On Sun Jan 4, 2026 at 7:06 AM CET, Ke Sun wrote:
>> Ke Sun (4):
>> rust: add AMBA bus abstractions
>> rust: add device wakeup support
>> rust: add RTC core abstractions and data structures
>> rust: add PL031 RTC driver
> May I ask how much of this (if any) has been generated with an LLM? Going
> through the code I saw quite some patterns that made me curious.
Yes, I used LLM assistance during development—mainly to help understand
certain R4L mechanisms. Code comments and some boilerplate were
generated with the help of LLM.
All code has been reviewed, tested, and verified by me to be correct and
compliant with kernel coding standards, under the assumption that my
understanding of the mechanisms is accurate.
Thanks for those. I'll look through your comments on the patch set and
address them.
^ permalink raw reply
* Re: [RFC PATCH v1 0/4] rust: Add RTC driver support
From: Danilo Krummrich @ 2026-01-04 13:36 UTC (permalink / raw)
To: Ke Sun
Cc: Alexandre Belloni, 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: <20260104060621.3757812-1-sunke@kylinos.cn>
On Sun Jan 4, 2026 at 7:06 AM CET, Ke Sun wrote:
> Ke Sun (4):
> rust: add AMBA bus abstractions
> rust: add device wakeup support
> rust: add RTC core abstractions and data structures
> rust: add PL031 RTC driver
May I ask how much of this (if any) has been generated with an LLM? Going
through the code I saw quite some patterns that made me curious.
^ permalink raw reply
* Re: [RFC PATCH v1 2/4] rust: add device wakeup support
From: Danilo Krummrich @ 2026-01-04 13:31 UTC (permalink / raw)
To: Ke Sun
Cc: gregkh, rafael, Alexandre Belloni, 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: <20260104060621.3757812-3-sunke@kylinos.cn>
(Cc: Greg, Rafael)
On Sun Jan 4, 2026 at 7:06 AM CET, Ke Sun wrote:
> diff --git a/rust/kernel/device.rs b/rust/kernel/device.rs
> index c79be2e2bfe38..c064111a24531 100644
> --- a/rust/kernel/device.rs
> +++ b/rust/kernel/device.rs
> @@ -325,6 +325,41 @@ pub fn drvdata<T: 'static>(&self) -> Result<Pin<&T>> {
> // - We've just checked that the type of the driver's private data is in fact `T`.
> Ok(unsafe { self.drvdata_unchecked() })
> }
> +
> + /// Initialize device wakeup capability.
> + ///
> + /// Marks the device as wakeup-capable and enables wakeup. The wakeup capability is
> + /// automatically disabled when the device is removed (resource-managed).
Let's use "when the device is unbound". While "remove" is a common term for this
as well, I prefer "unbind" since it is less ambiguous in this context.
> + ///
> + /// Returns `Ok(())` on success, or an error code on failure.
> + pub fn init_wakeup(&self) -> Result {
Please call this devm_init_wakeup().
> + // SAFETY: `self.as_raw()` is a valid pointer to a `struct device`.
> + // The function is exported from bindings_helper module via pub use.
> + let ret = unsafe { bindings::devm_device_init_wakeup(self.as_raw()) };
> + if ret != 0 {
> + return Err(Error::from_errno(ret));
> + }
> + Ok(())
Please use to_result() instead.
> + }
> +
> + /// Set a device interrupt as a wake IRQ.
> + ///
> + /// Attaches the interrupt `irq` as a wake IRQ for this device. The wake IRQ is
> + /// automatically configured for wake-up from suspend. Must be called after
> + /// [`Device::init_wakeup`].
> + ///
> + /// Returns `Ok(())` on success, or an error code on failure.
> + pub fn set_wake_irq(&self, irq: i32) -> Result {
The irq argument should be a new type holding the irq number and a
&'a Device<Bound>, i.e. IrqRequest [1].
Technically, this can also be implemented on IrqRequest directly, this way no
additional check for comparing the device pointers is needed; but the method is
fallible anyways, and it is a bit odd to have this method on IrqRequest, so I'd
abstain from this.
> + if irq < 0 {
> + return Err(crate::error::code::EINVAL);
You do not need the full qualified name, just EINVAL should work, but with the
above you don't need any manual irq number validation anyways.
> + }
> + // SAFETY: `self.as_raw()` is a valid pointer to a `struct device`.
> + let ret = unsafe { bindings::dev_pm_set_wake_irq(self.as_raw(), irq) };
> + if ret != 0 {
> + return Err(Error::from_errno(ret));
> + }
> + Ok(())
Please use to_result() instead.
> + }
> }
[1] https://rust.docs.kernel.org/kernel/irq/struct.IrqRequest.html
^ permalink raw reply
* Re: [RFC PATCH v1 4/4] rust: add PL031 RTC driver
From: Danilo Krummrich @ 2026-01-04 13:10 UTC (permalink / raw)
To: Ke Sun
Cc: Alexandre Belloni, 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: <20260104060621.3757812-5-sunke@kylinos.cn>
On Sun Jan 4, 2026 at 7:06 AM CET, Ke Sun wrote:
> +/// PL031 RTC driver private data.
> +#[pin_data(PinnedDrop)]
> +struct Pl031DrvData {
> + #[pin]
> + base: Devres<IoMem<0>>,
Please do not use 0 as generic argument, this should likely be RTC_YLR + 0x4
(assuming that this register has a width of 32 bit).
It allows you to perform register accesses until RTC_YLR + 0x4 with infallible
accessors, since the call to IoMem::new() will validate that the memory region
has at least a size of RTC_YLR + 0x4.
> + variant: VendorVariant,
> + /// RTC device reference for interrupt handler.
> + ///
> + /// Set in `init_rtcdevice` and remains valid for the driver's lifetime
> + /// because the RTC device is managed by devres.
> + rtc_device: Option<ARef<RtcDevice>>,
I don't see a reason for a separate init_rtcdevice() method. Creating the RTC
device should happen in probe(), which also gets you rid of this odd Option.
> +}
> +
> +// SAFETY: `Pl031DrvData` contains only `Send`/`Sync` types: `Devres` (Send+Sync),
> +// `VendorVariant` (Copy), and `Option<ARef<RtcDevice>>` (Send+Sync because `RtcDevice` is
> +// Send+Sync).
> +unsafe impl Send for Pl031DrvData {}
> +// SAFETY: `Pl031DrvData` contains only `Send`/`Sync` types: `Devres` (Send+Sync),
> +// `VendorVariant` (Copy), and `Option<ARef<RtcDevice>>` (Send+Sync because `RtcDevice` is
> +// Send+Sync).
> +unsafe impl Sync for Pl031DrvData {}
Why not implement Send + Sync for RtcDevice then?
> +// Use AMBA device table for matching
> +kernel::amba_device_table!(
> + ID_TABLE,
> + MODULE_ID_TABLE,
> + <Pl031DrvData as rtc::DriverGeneric<rtc::AmbaBus>>::IdInfo,
> + [
> + (
> + amba::DeviceId::new_with_data(0x00041031, 0x000fffff, Pl031Variant::ARM.to_usize()),
> + Pl031Variant::ARM
> + ),
> + (
> + amba::DeviceId::new_with_data(0x00180031, 0x00ffffff, Pl031Variant::STV1.to_usize()),
> + Pl031Variant::STV1
> + ),
> + (
> + amba::DeviceId::new_with_data(0x00280031, 0x00ffffff, Pl031Variant::STV2.to_usize()),
Why a constructor new_with_data() if you already store data through the generic
device ID mechanism right below?
> + Pl031Variant::STV2
> + ),
> + ]
> +);
^ permalink raw reply
* Re: [RFC PATCH v1 3/4] rust: add RTC core abstractions and data structures
From: Danilo Krummrich @ 2026-01-04 13:00 UTC (permalink / raw)
To: Ke Sun
Cc: Alexandre Belloni, 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: <20260104060621.3757812-4-sunke@kylinos.cn>
On Sun Jan 4, 2026 at 7:06 AM CET, Ke Sun wrote:
> Add Rust abstractions for RTC (Real-Time Clock) devices, including:
>
> - Data structures: RtcTime, RtcWkAlrm, RtcParam wrappers for RTC types
> - RtcDevice: Safe wrapper for struct rtc_device
> - DriverGeneric trait: Generic RTC driver trait over bus types
> - RtcOperations trait: VTable for RTC device operations
> - Bus abstractions: PlatformBus, AmbaBus, I2cBus implementations
This is my main concern with this patch: It bakes bus (device) code (e.g.
platform AMBA and I2C) into the RTC code, effectively duplicating infrastructure
where it does not belong to in the first place and limites on which bus RTC
devices can be registered artificially.
The driver model has a loosely coupled design between bus and class device code,
such that class devices can be registered freely from any driver driving a bus
device. There can also be more complicated topologies considering the auxiliary
bus, mfd, etc.
Please remove the duplicated bus (device) code and helper types and macros, such
as BusRegistration, impl_bus!, etc. Instead, please have a look at how the PWM
code works and incorporate the design.
Additionally, you can utilize the AsBusDevice trait to find the concrete bus
device (e.g. AMBA) in your class device callbacks from the generic parent device
of your RTC device.
I will take a more thorough look at the code from the driver core side of things
once this has been addressed.
Thanks,
Danilo
^ permalink raw reply
* Re: [RFC PATCH v1 1/4] rust: add AMBA bus abstractions
From: Danilo Krummrich @ 2026-01-04 12:37 UTC (permalink / raw)
To: Ke Sun
Cc: Alexandre Belloni, 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: <20260104060621.3757812-2-sunke@kylinos.cn>
On Sun Jan 4, 2026 at 7:06 AM CET, Ke Sun wrote:
> Add Rust abstractions for the ARM AMBA bus, including:
> - Device type wrapper for amba_device
> - DeviceId for device matching
> - TryFrom implementation for converting device::Device to amba::Device
> - IRQ and I/O resource management methods
I don't see any Driver trait or Adapter implementation implementing to register
and probe an AMBA driver.
Since I had a look at your RTC abstractions, I can see the reason why, i.e. you
baked that part into the RTC abstractions, but this is not how the device /
driver model works. I will comment about this in the RTC patch. But for this
one, please implement thing analogous to platform, PCI, etc.
> +impl DeviceId {
> + /// Creates a new device ID from an AMBA device ID and mask.
> + ///
> + /// A driver binds to a device when `(hardware_device_id & mask) == id`.
> + #[inline(always)]
> + pub const fn new(id: u32, mask: u32) -> Self {
> + // SAFETY: FFI type is valid to be zero-initialized.
> + let mut amba: bindings::amba_id = unsafe { core::mem::zeroed() };
Please use pin_init::zeroed() instead.
> + amba.id = id;
> + amba.mask = mask;
> + amba.data = core::ptr::null_mut();
> +
> + Self(amba)
> + }
> +
> + /// Creates a new device ID with driver-specific data.
> + #[inline(always)]
> + pub const fn new_with_data(id: u32, mask: u32, data: usize) -> Self {
> + // SAFETY: FFI type is valid to be zero-initialized.
> + let mut amba: bindings::amba_id = unsafe { core::mem::zeroed() };
Same here.
> + amba.id = id;
> + amba.mask = mask;
> + amba.data = data as *mut core::ffi::c_void;
What is this data? The driver specific data is derived from the index stored in
DRIVER_DATA_OFFSET. This does interfere with each other.
You already get driver specific data per entry from the generic code, you can
just drop this.
> + /// Returns the memory resource.
> + pub fn resource(&self) -> Option<&Resource> {
Why does this return an Option if you do not have a None case? Are you sure
resource can never be NULL?
> + // SAFETY: `self.as_raw()` returns a valid pointer to a `struct amba_device`.
> + let resource = unsafe { &raw mut (*self.as_raw()).res };
> + // SAFETY: `resource` is a valid pointer to a `struct resource`.
> + Some(unsafe { Resource::from_raw(resource) })
> + }
> +}
> +
> +impl<Ctx: device::DeviceContext> AsRef<device::Device<Ctx>> for Device<Ctx> {
> + fn as_ref(&self) -> &device::Device<Ctx> {
> + // SAFETY: By the type invariant of `Self`, `self.as_raw()` is a pointer to a
> + // valid `struct amba_device`.
> + let dev = unsafe { &raw mut (*self.as_raw()).dev };
> +
> + // SAFETY: `dev` points to a valid `struct device`.
> + unsafe { device::Device::from_raw(dev) }
> + }
> +}
> +
> +// SAFETY: `Device` is a transparent wrapper that doesn't depend on its generic
> +// argument.
> +crate::impl_device_context_deref!(unsafe { Device });
> +crate::impl_device_context_into_aref!(Device);
> +
> +impl<Ctx: device::DeviceContext> TryFrom<&device::Device<Ctx>> for &Device<Ctx> {
> + type Error = kernel::error::Error;
> +
> + fn try_from(dev: &device::Device<Ctx>) -> Result<Self, Self::Error> {
> + // SAFETY: By the type invariant of `Device`, `dev.as_raw()` is a valid pointer
> + // to a `struct device`.
> + if !unsafe { bindings::dev_is_amba(dev.as_raw()) } {
> + return Err(crate::error::code::EINVAL);
> + }
> +
> + // SAFETY: We've just verified that the bus type of `dev` equals
> + // `bindings::amba_bustype`, hence `dev` must be embedded in a valid
> + // `struct amba_device` as guaranteed by the corresponding C code.
> + let adev = unsafe { container_of!(dev.as_raw(), bindings::amba_device, dev) };
> +
> + // SAFETY: `adev` is a valid pointer to a `struct amba_device`.
> + Ok(unsafe { &*adev.cast() })
> + }
> +}
Please implement the AsBusDevice trait instead, this TryFrom solution you
probably found in the platform and PCI bus are for very specific cases. For
instance, if you have a driver that exports and auxiliary device, but is
supported on two busses.
In your case, you simply want to derive an amba device from a generic device in
a class device abstraction (RTC device), hence please incorporate the
AsBusDevice trait.
> +impl Device<device::Core> {}
> +
> +impl Device<device::Bound> {
> + /// Returns an [`IoRequest`] for the memory resource.
> + pub fn io_request(&self) -> Option<IoRequest<'_>> {
> + self.resource()
> + // SAFETY: `resource` is valid for the lifetime of the `IoRequest`.
> + .map(|resource| unsafe { IoRequest::new(self.as_ref(), resource) })
> + }
> +
> + /// Returns an [`IrqRequest`] for the IRQ at the given index.
> + pub fn irq_by_index(&self, index: u32) -> Result<IrqRequest<'_>> {
> + if index >= bindings::AMBA_NR_IRQS {
> + return Err(crate::error::code::EINVAL);
> + }
> +
> + // SAFETY: `self.as_raw()` returns a valid pointer to a `struct amba_device`.
> + let irq = unsafe { (*self.as_raw()).irq[index as usize] };
> +
> + if irq == 0 {
> + return Err(crate::error::code::ENXIO);
> + }
> +
> + // SAFETY: `irq` is guaranteed to be a valid IRQ number for `&self`.
> + Ok(unsafe { IrqRequest::new(self.as_ref(), irq) })
> + }
> +
> + /// Requests an IRQ at the given index and returns a [`irq::Registration`].
> + pub fn request_irq_by_index<'a, T: irq::Handler + 'static>(
> + &'a self,
> + flags: irq::Flags,
> + index: u32,
> + name: &'static CStr,
> + handler: impl PinInit<T, Error> + 'a,
> + ) -> Result<impl PinInit<irq::Registration<T>, Error> + 'a> {
Please don't return a Result here, the error code is already within the impl
PinInit<T, Error>. Please use pin_init::pin_init_scope() instead.
> + let request = self.irq_by_index(index)?;
> +
> + Ok(irq::Registration::<T>::new(request, flags, name, handler))
> + }
> +}
^ permalink raw reply
* Re: [RFC PATCH v1 4/4] rust: add PL031 RTC driver
From: Miguel Ojeda @ 2026-01-04 11:40 UTC (permalink / raw)
To: Ke Sun
Cc: Alexandre Belloni, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, linux-rtc, rust-for-linux,
Alvin Sun, Russell King
In-Reply-To: <20260104060621.3757812-5-sunke@kylinos.cn>
On Sun, Jan 4, 2026 at 7:07 AM Ke Sun <sunke@kylinos.cn> wrote:
>
> Add Rust implementation of the ARM AMBA PrimeCell 031 RTC driver.
> The driver uses the AMBA bus abstractions and RTC core framework
> introduced in previous commits.
Cc'ing AMBA (Russell) here as well, in case it is useful for context.
> + depends on RUST && RTC_CLASS && RUST_BUILD_ASSERT_ALLOW
> + This driver requires CONFIG_RUST_BUILD_ASSERT_ALLOW to be enabled
> + because it uses build-time assertions for memory safety checks.
While replying for the Cc, I noticed this...
One cannot require `CONFIG_RUST_BUILD_ASSERT_ALLOW`. If you need it,
then it is because some of the assertions are *not* true at build
time, in which case either you need to fix them so that the optimizer
can figure out that they are be true or, if they are intended to be
runtime assertions, then use something else (likely normal error
handling).
Put another way, one should always assume
`CONFIG_RUST_BUILD_ASSERT_ALLOW` does not exist, i.e. assume it has to
always be `n`. That config is just an escape hatch, and one can
consider it may get removed at any point.
Cheers,
Miguel
^ 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