* [PATCH v6 3/7] mfd: macsmc: Wire up Apple SMC hwmon subdevice
From: James Calligeros @ 2025-12-15 9:37 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Jonathan Corbet, James Calligeros
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251215-macsmc-subdevs-v6-0-0518cb5f28ae@gmail.com>
Add the SMC hwmon functionality to the mfd device
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
---
drivers/mfd/macsmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c
index 9099a7a22f1f..fa7b822d55bd 100644
--- a/drivers/mfd/macsmc.c
+++ b/drivers/mfd/macsmc.c
@@ -46,6 +46,7 @@
static const struct mfd_cell apple_smc_devs[] = {
MFD_CELL_OF("macsmc-gpio", NULL, NULL, 0, 0, "apple,smc-gpio"),
+ MFD_CELL_OF("macsmc-hwmon", NULL, NULL, 0, 0, "apple,smc-hwmon"),
MFD_CELL_OF("macsmc-reboot", NULL, NULL, 0, 0, "apple,smc-reboot"),
MFD_CELL_OF("macsmc-rtc", NULL, NULL, 0, 0, "apple,smc-rtc"),
};
--
2.52.0
^ permalink raw reply related
* [PATCH v6 2/7] mfd: macsmc: Wire up Apple SMC RTC subdevice
From: James Calligeros @ 2025-12-15 9:37 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Jonathan Corbet, James Calligeros
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251215-macsmc-subdevs-v6-0-0518cb5f28ae@gmail.com>
Add the new SMC RTC function to the mfd device
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
---
drivers/mfd/macsmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c
index e3893e255ce5..9099a7a22f1f 100644
--- a/drivers/mfd/macsmc.c
+++ b/drivers/mfd/macsmc.c
@@ -47,6 +47,7 @@
static const struct mfd_cell apple_smc_devs[] = {
MFD_CELL_OF("macsmc-gpio", NULL, NULL, 0, 0, "apple,smc-gpio"),
MFD_CELL_OF("macsmc-reboot", NULL, NULL, 0, 0, "apple,smc-reboot"),
+ MFD_CELL_OF("macsmc-rtc", NULL, NULL, 0, 0, "apple,smc-rtc"),
};
static int apple_smc_cmd_locked(struct apple_smc *smc, u64 cmd, u64 arg,
--
2.52.0
^ permalink raw reply related
* [PATCH v6 1/7] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: James Calligeros @ 2025-12-15 9:37 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Jonathan Corbet, James Calligeros
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251215-macsmc-subdevs-v6-0-0518cb5f28ae@gmail.com>
Apple Silicon devices integrate a vast array of sensors, monitoring
current, power, temperature, and voltage across almost every part of
the system. The sensors themselves are all connected to the System
Management Controller (SMC). The SMC firmware exposes the data
reported by these sensors via its standard FourCC-based key-value
API. The SMC is also responsible for monitoring and controlling any
fans connected to the system, exposing them in the same way.
For reasons known only to Apple, each device exposes its sensors with
an almost totally unique set of keys. This is true even for devices
which share an SoC. An M1 Mac mini, for example, will report its core
temperatures on different keys to an M1 MacBook Pro. Worse still, the
SMC does not provide a way to enumerate the available keys at runtime,
nor do the keys follow any sort of reasonable or consistent naming
rules that could be used to deduce their purpose. We must therefore
know which keys are present on any given device, and which function
they serve, ahead of time.
Add a schema so that we can describe the available sensors for a given
Apple Silicon device in the Devicetree.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
---
.../bindings/hwmon/apple,smc-hwmon.yaml | 86 +++++++++++++++++++++++++
.../bindings/mfd/apple,smc.yaml | 36 +++++++++++
MAINTAINERS | 1 +
3 files changed, 123 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/apple,smc-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/apple,smc-hwmon.yaml
new file mode 100644
index 000000000000..2eec317bc4b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/apple,smc-hwmon.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/apple,smc-hwmon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple SMC Hardware Monitoring
+
+description:
+ Apple's System Management Controller (SMC) exposes a vast array of
+ hardware monitoring sensors, including temperature probes, current and
+ voltage sense, power meters, and fan speeds. It also provides endpoints
+ to manually control the speed of each fan individually. Each Apple
+ Silicon device exposes a different set of endpoints via SMC keys. This
+ is true even when two machines share an SoC. The CPU core temperature
+ sensor keys on an M1 Mac mini are different to those on an M1 MacBook
+ Pro, for example.
+
+maintainers:
+ - James Calligeros <jcalligeros99@gmail.com>
+
+$defs:
+ sensor:
+ type: object
+
+ properties:
+ apple,key-id:
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: "^[A-Za-z0-9]{4}$"
+ description: The SMC FourCC key of the desired sensor.
+ Must match the node's suffix.
+
+ label:
+ description: Human-readable name for the sensor
+
+ required:
+ - apple,key-id
+
+properties:
+ compatible:
+ const: apple,smc-hwmon
+
+patternProperties:
+ "^current-[A-Za-z0-9]{4}$":
+ $ref: "#/$defs/sensor"
+ unevaluatedProperties: false
+
+ "^fan-[A-Za-z0-9]{4}$":
+ $ref: "#/$defs/sensor"
+ unevaluatedProperties: false
+
+ properties:
+ apple,fan-minimum:
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: "^[A-Za-z0-9]{4}$"
+ description: SMC key containing the fan's minimum speed
+
+ apple,fan-maximum:
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: "^[A-Za-z0-9]{4}$"
+ description: SMC key containing the fan's maximum speed
+
+ apple,fan-target:
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: "^[A-Za-z0-9]{4}$"
+ description: Writeable endpoint for setting desired fan speed
+
+ apple,fan-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ pattern: "^[A-Za-z0-9]{4}$"
+ description: Writeable key to enable/disable manual fan control
+
+
+ "^power-[A-Za-z0-9]{4}$":
+ $ref: "#/$defs/sensor"
+ unevaluatedProperties: false
+
+ "^temperature-[A-Za-z0-9]{4}$":
+ $ref: "#/$defs/sensor"
+ unevaluatedProperties: false
+
+ "^voltage-[A-Za-z0-9]{4}$":
+ $ref: "#/$defs/sensor"
+ unevaluatedProperties: false
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml
index 0410e712c900..34ce048619f5 100644
--- a/Documentation/devicetree/bindings/mfd/apple,smc.yaml
+++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml
@@ -49,6 +49,9 @@ properties:
rtc:
$ref: /schemas/rtc/apple,smc-rtc.yaml
+ hwmon:
+ $ref: /schemas/hwmon/apple,smc-hwmon.yaml
+
additionalProperties: false
required:
@@ -89,5 +92,38 @@ examples:
nvmem-cells = <&rtc_offset>;
nvmem-cell-names = "rtc_offset";
};
+
+ hwmon {
+ compatible = "apple,smc-hwmon";
+
+ current-ID0R {
+ apple,key-id = "ID0R";
+ label = "AC Input Current";
+ };
+
+ fan-F0Ac {
+ apple,key-id = "F0Ac";
+ apple,fan-minimum = "F0Mn";
+ apple,fan-maximum = "F0Mx";
+ apple,fan-target = "F0Tg";
+ apple,fan-mode = "F0Md";
+ label = "Fan 1";
+ };
+
+ power-PSTR {
+ apple,key-id = "PSTR";
+ label = "Total System Power";
+ };
+
+ temperature-TW0P {
+ apple,key-id = "TW0P";
+ label = "WiFi/BT Module Temperature";
+ };
+
+ voltage-VD0R {
+ apple,key-id = "VD0R";
+ label = "AC Input Voltage";
+ };
+ };
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b11839cba9d..5f160eb6762e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2458,6 +2458,7 @@ F: Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml
F: Documentation/devicetree/bindings/dma/apple,admac.yaml
F: Documentation/devicetree/bindings/gpio/apple,smc-gpio.yaml
F: Documentation/devicetree/bindings/gpu/apple,agx.yaml
+F: Documentation/devicetree/bindings/hwmon/apple,smc-hwmon.yaml
F: Documentation/devicetree/bindings/i2c/apple,i2c.yaml
F: Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml
F: Documentation/devicetree/bindings/interrupt-controller/apple,*
--
2.52.0
^ permalink raw reply related
* [PATCH v6 0/7] mfd: macsmc: add rtc, hwmon and hid subdevices
From: James Calligeros @ 2025-12-15 9:37 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, Jean Delvare, Guenter Roeck, Dmitry Torokhov,
Jonathan Corbet, James Calligeros
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Hector Martin
Hi all,
This series adds support for the remaining SMC subdevices. These are the
RTC, hwmon, and HID devices. They are being submitted together as the RTC
and hwmon drivers both require changes to the SMC DT schema.
The RTC driver is responsible for getting and setting the system clock,
and requires an NVMEM cell. This series replaces Sven's original RTC driver
submission [1].
The hwmon function is an interesting one. While each Apple Silicon device
exposes pretty similar sets of sensors, these all seem to be paired to
different SMC keys in the firmware interface. This is true even when the
sensors are on the SoC. For example, an M1 MacBook Pro will use different
keys to access the LITTLE core temperature sensors to an M1 Mac mini. This
necessitates describing which keys correspond to which sensors for each
device individually, and populating the hwmon structs at runtime. We do
this with a node in the device tree. This series includes only the keys
for sensors which we know to be common to all devices. The SMC is also
responsible for monitoring and controlling fan speeds on systems with fans,
which we expose via the hwmon driver.
The SMC also handles the hardware power button and lid switch. Power
button presses and lid opening/closing are emitted as HID events, so we
add an input subdevice to handle them.
Since there are no real dependencies between the components of this series,
it should be fine for each subsystem to take the relevant patches through
their trees. The mfd one-liners should be taken in order to avoid trivial
conflicts.
Regards,
James
[1] https://lore.kernel.org/asahi/CAEg-Je84XxLWH7vznQmPRfjf6GxWOu75ZetwN7AdseAwfMLLrQ@mail.gmail.com/T/#t
[2] https://lore.kernel.org/asahi/20251106140050.GQ8064@google.com/
---
Changes in v6:
- Rebase onto 6.19-rc1, dropping already merged commits
- Link to v5: https://lore.kernel.org/r/20251112-macsmc-subdevs-v5-0-728e4b91fe81@gmail.com
Changes in v5:
- Drop inadvertent mfd core includes in rtc and input drivers
- Link to v4: https://lore.kernel.org/r/20251025-macsmc-subdevs-v4-0-374d5c9eba0e@gmail.com
Changes in v4:
- Added Rob's R-b to hwmon Devicetree schema
- Added missing include to hwmon driver
- Dropped superfluous dev_info() from hwmon probe
- Added Guenter's A-b to hwmon driver
- Renamed INPUT_MACSMC_INPUT to INPUT_MACSMC
- Dropped leftover mention of HID in input driver
- Reinstated input driver MODULE_ALIAS
- Trigger a hard wakeup on power button/lid switch when coming out of
s2idle
- Suppress KEY_POWER event on wakeup to prevent an immediate shutdown
when waking up
- Squashed hwmon Devicetree commits into one
- Link to v3: https://lore.kernel.org/r/20251007-macsmc-subdevs-v3-0-d7d3bfd7ae02@gmail.com
Changes in v3:
- Renamed macsmc-hid to macsmc-input
- Switched to pm_wakeup_event in macsmc-input
- macsmc-input now configures its capabilities before registering the device
- Renamed macsmc_hwmon to macsmc-hwmon
- Dropped module aliases in macsmc-input and macsmc_hwmon
- Introduced new SMC FourCC macro to silence GCC errors
- Condensed hwmon binding using $defs
- Made label property optional for hwmon sensors
- Fixed incorrect hwmon is_visible implementation
- Dropped 64-bit math from SMC float ops
- Fixed incorrect use of error numbers in hwmon driver
- Replaced a number of non-fatal dev_errs with dev_dbgs in hwmon driver
- Added hwmon driver documentation
- Added hwmon subdevice directly to the DT SMC node
- Included "common" hwmon sensors in SoC .dtsi files
- Fixed typo in hwmon-common.dtsi
- Added Neal's R-b to series
- Added required nodes to t602x Devicetrees
- Link to v2: https://lore.kernel.org/r/20250827-macsmc-subdevs-v2-0-ce5e99d54c28@gmail.com
Changes in v2:
- Added Rob's R-b tag to RTC DT binding
- Removed redundant nesting from hwmon DT binding
- Dedpulicated property definitions in hwmon DT schema
- Made label a required property for hwmon DT nodes
- Clarified semantics in hwmon DT schema definitions
- Split mfd tree changes into separate commits
- Fixed numerous style errors in hwmon driver
- Removed log messages sysfs read/write functions in hwmon driver
- Removed ignored errors from hwmon driver
- Removed uses of dev_err for non-errors in hwmon driver
- Made it more obvious that a number of hwmon fan properties are optional
- Modified hwmon driver to reflect DT schema changes
- Added compatible property to hwmon node
- Link to v1: https://lore.kernel.org/r/20250819-macsmc-subdevs-v1-0-57df6c3e5f19@gmail.com
---
Hector Martin (1):
input: macsmc-input: New driver to handle the Apple Mac SMC buttons/lid
James Calligeros (5):
dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
mfd: macsmc: Wire up Apple SMC RTC subdevice
mfd: macsmc: Wire up Apple SMC hwmon subdevice
mfd: macsmc: Wire up Apple SMC input subdevice
arm64: dts: apple: t8103, t8112, t60xx: Add hwmon SMC subdevice
Sven Peter (1):
arm64: dts: apple: t8103,t60xx,t8112: Add SMC RTC node
.../bindings/hwmon/apple,smc-hwmon.yaml | 86 ++++++++++
.../bindings/mfd/apple,smc.yaml | 36 +++++
MAINTAINERS | 2 +
.../boot/dts/apple/hwmon-common.dtsi | 33 ++++
.../boot/dts/apple/hwmon-fan-dual.dtsi | 22 +++
arch/arm64/boot/dts/apple/hwmon-fan.dtsi | 17 ++
.../boot/dts/apple/hwmon-laptop.dtsi | 33 ++++
.../boot/dts/apple/hwmon-mac-mini.dtsi | 15 ++
.../arm64/boot/dts/apple/t6001-j375c.dts | 2 +
arch/arm64/boot/dts/apple/t6001.dtsi | 2 +
.../arm64/boot/dts/apple/t6002-j375d.dts | 2 +
.../arm64/boot/dts/apple/t600x-die0.dtsi | 10 ++
.../boot/dts/apple/t600x-j314-j316.dtsi | 3 +
.../arm64/boot/dts/apple/t602x-die0.dtsi | 10 ++
arch/arm64/boot/dts/apple/t8103-j274.dts | 2 +
arch/arm64/boot/dts/apple/t8103-j293.dts | 3 +
arch/arm64/boot/dts/apple/t8103-j313.dts | 2 +
arch/arm64/boot/dts/apple/t8103-j456.dts | 2 +
arch/arm64/boot/dts/apple/t8103-j457.dts | 2 +
arch/arm64/boot/dts/apple/t8103.dtsi | 11 ++
arch/arm64/boot/dts/apple/t8112-j413.dts | 2 +
arch/arm64/boot/dts/apple/t8112-j473.dts | 2 +
arch/arm64/boot/dts/apple/t8112-j493.dts | 3 +
arch/arm64/boot/dts/apple/t8112.dtsi | 11 ++
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/macsmc-input.c | 207 +++++++++++++++++++++++++
drivers/mfd/macsmc.c | 3 +
28 files changed, 535 insertions(+)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20250816-macsmc-subdevs-87032c017d0c
Best regards,
--
James Calligeros <jcalligeros99@gmail.com>
^ permalink raw reply
* Re: [PATCH v1 00/17] tee: Use bus callbacks instead of driver callbacks
From: Uwe Kleine-König @ 2025-12-15 9:32 UTC (permalink / raw)
To: Sumit Garg
Cc: Jens Wiklander, 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, Michael Chan,
Pavan Chebbi, Rafał Miłecki, James Bottomley,
Jarkko Sakkinen, Mimi Zohar, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, Peter Huewe, op-tee, linux-kernel,
linux-crypto, linux-rtc, linux-efi, linux-stm32, linux-arm-kernel,
Cristian Marussi, arm-scmi, netdev, linux-mips, linux-integrity,
keyrings, linux-security-module, Jason Gunthorpe
In-Reply-To: <aT--ox375kg2Mzh-@sumit-X1>
[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]
Hello Sumit,
On Mon, Dec 15, 2025 at 04:54:11PM +0900, Sumit Garg wrote:
> On Thu, Dec 11, 2025 at 06:14:54PM +0100, 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.)
> >
> > The patches #4 - #17 depend on the first two, so if they should be
> > applied to their respective subsystem trees these must contain the first
> > two patches first.
>
> Thanks Uwe for your efforts to clean up the boilerplate code for TEE bus
> drivers.
Thanks for your feedback. I will prepare a v2 and address your comments
(whitespace issues and wrong callback in the shutdown method).
> > Note that after patch #2 is applied, unconverted drivers provoke a
> > warning in driver_register(), so it would be good for the user
> > experience if the whole series goes in during a single merge window.
>
> +1
>
> I suggest the whole series goes via the Jens tree since there shouldn't
> be any chances for conflict here.
>
> > So
> > I guess an immutable branch containing the frist three patches that can
> > be merged into the other subsystem trees would be sensible.
> >
> > After all patches are applied, tee_bus_type can be made private to
> > drivers/tee as it's not used in other places any more.
> >
>
> Feel free to make the tee_bus_type private as the last patch in the series
> such that any followup driver follows this clean approach.
There is a bit more to do for that than I'm willing to invest. With my
patch series applied `tee_bus_type` is still used in
drivers/tee/optee/device.c and drivers/tee/tee_core.c. Maybe it's
sensible to merge these two files into a single one.
The things I wonder about additionally are:
- if CONFIG_OPTEE=n and CONFIG_TEE=y|m the tee bus is only used for
drivers but not devices.
- optee_register_device() calls device_create_file() on
&optee_device->dev after device_register(&optee_device->dev).
(Attention half-knowledge!) I think device_create_file() should not
be called on an already registered device (or you have to send a
uevent afterwards). This should probably use type attribute groups.
(Or the need_supplicant attribute should be dropped as it isn't very
useful. This would maybe be considered an ABI change however.)
- Why does optee_probe() in drivers/tee/optee/smc_abi.c unregister all
optee devices in its error path (optee_unregister_devices())?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1 00/17] tee: Use bus callbacks instead of driver callbacks
From: Sumit Garg @ 2025-12-15 7:54 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, 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, Michael Chan,
Pavan Chebbi, Rafał Miłecki, James Bottomley,
Jarkko Sakkinen, Mimi Zohar, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, Peter Huewe, op-tee, linux-kernel,
linux-crypto, linux-rtc, linux-efi, linux-stm32, linux-arm-kernel,
Cristian Marussi, arm-scmi, netdev, linux-mips, linux-integrity,
keyrings, linux-security-module, Jason Gunthorpe
In-Reply-To: <cover.1765472125.git.u.kleine-koenig@baylibre.com>
On Thu, Dec 11, 2025 at 06:14:54PM +0100, 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.)
>
> The patches #4 - #17 depend on the first two, so if they should be
> applied to their respective subsystem trees these must contain the first
> two patches first.
Thanks Uwe for your efforts to clean up the boilerplate code for TEE bus
drivers.
>
> Note that after patch #2 is applied, unconverted drivers provoke a
> warning in driver_register(), so it would be good for the user
> experience if the whole series goes in during a single merge window.
+1
I suggest the whole series goes via the Jens tree since there shouldn't
be any chances for conflict here.
> So
> I guess an immutable branch containing the frist three patches that can
> be merged into the other subsystem trees would be sensible.
>
> After all patches are applied, tee_bus_type can be made private to
> drivers/tee as it's not used in other places any more.
>
Feel free to make the tee_bus_type private as the last patch in the series
such that any followup driver follows this clean approach.
-Sumit
> Best regards
> Uwe
>
> 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: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v1 07/17] rtc: optee: Make use of tee bus methods
From: Sumit Garg @ 2025-12-15 7:30 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Clément Léger, Alexandre Belloni,
op-tee, linux-rtc, linux-kernel
In-Reply-To: <a9c8da1b7b2832044129ec9e2616c40e0023ad57.1765472125.git.u.kleine-koenig@baylibre.com>
On Thu, Dec 11, 2025 at 06:15:01PM +0100, Uwe Kleine-König wrote:
> The tee bus got dedicated callbacks for probe and remove. Make use of
> these. This fixes a runtime warning about the driver needing to be
> converted to the bus methods.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> drivers/rtc/rtc-optee.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
-Sumit
>
> diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
> index f924a729ead0..eefde789d194 100644
> --- a/drivers/rtc/rtc-optee.c
> +++ b/drivers/rtc/rtc-optee.c
> @@ -547,9 +547,9 @@ static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> return 0;
> }
>
> -static int optee_rtc_probe(struct device *dev)
> +static int optee_rtc_probe(struct tee_client_device *rtc_device)
> {
> - struct tee_client_device *rtc_device = to_tee_client_device(dev);
> + struct device *dev = &rtc_device->dev;
> struct tee_ioctl_open_session_arg sess2_arg = {0};
> struct tee_ioctl_open_session_arg sess_arg = {0};
> struct optee_rtc *priv;
> @@ -682,8 +682,9 @@ static int optee_rtc_probe(struct device *dev)
> return err;
> }
>
> -static int optee_rtc_remove(struct device *dev)
> +static void optee_rtc_remove(struct tee_client_device *rtc_device)
> {
> + struct device *dev = &rtc_device->dev;
> struct optee_rtc *priv = dev_get_drvdata(dev);
>
> if (priv->features & TA_RTC_FEATURE_ALARM) {
> @@ -696,8 +697,6 @@ static int optee_rtc_remove(struct device *dev)
> tee_shm_free(priv->shm);
> tee_client_close_session(priv->ctx, priv->session_id);
> tee_client_close_context(priv->ctx);
> -
> - return 0;
> }
>
> static int optee_rtc_suspend(struct device *dev)
> @@ -724,10 +723,10 @@ MODULE_DEVICE_TABLE(tee, optee_rtc_id_table);
>
> static struct tee_client_driver optee_rtc_driver = {
> .id_table = optee_rtc_id_table,
> + .probe = optee_rtc_probe,
> + .remove = optee_rtc_remove,
> .driver = {
> .name = "optee_rtc",
> - .probe = optee_rtc_probe,
> - .remove = optee_rtc_remove,
> .pm = pm_sleep_ptr(&optee_rtc_pm_ops),
> },
> };
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v1 06/17] rtc: optee: Migrate to use tee specific driver registration function
From: Sumit Garg @ 2025-12-15 7:28 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Clément Léger, Alexandre Belloni,
op-tee, linux-rtc, linux-kernel
In-Reply-To: <a586934215a4971f9920398655cb85fd29d91c9f.1765472125.git.u.kleine-koenig@baylibre.com>
On Thu, Dec 11, 2025 at 06:15:00PM +0100, Uwe Kleine-König wrote:
> The tee subsystem recently got a set of dedicated functions to register
> (and unregister) a tee driver. Make use of them. These care for setting the
> driver's bus (so the explicit assignment can be dropped) and the driver
> owner (which is an improvement this driver benefits from).
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> drivers/rtc/rtc-optee.c | 14 +-------------
> 1 file changed, 1 insertion(+), 13 deletions(-)
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
-Sumit
>
> diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
> index 184c6d142801..f924a729ead0 100644
> --- a/drivers/rtc/rtc-optee.c
> +++ b/drivers/rtc/rtc-optee.c
> @@ -726,25 +726,13 @@ static struct tee_client_driver optee_rtc_driver = {
> .id_table = optee_rtc_id_table,
> .driver = {
> .name = "optee_rtc",
> - .bus = &tee_bus_type,
> .probe = optee_rtc_probe,
> .remove = optee_rtc_remove,
> .pm = pm_sleep_ptr(&optee_rtc_pm_ops),
> },
> };
>
> -static int __init optee_rtc_mod_init(void)
> -{
> - return driver_register(&optee_rtc_driver.driver);
> -}
> -
> -static void __exit optee_rtc_mod_exit(void)
> -{
> - driver_unregister(&optee_rtc_driver.driver);
> -}
> -
> -module_init(optee_rtc_mod_init);
> -module_exit(optee_rtc_mod_exit);
> +module_tee_client_driver(optee_rtc_driver);
>
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Clément Léger <clement.leger@bootlin.com>");
> --
> 2.47.3
>
^ permalink raw reply
* Re: PROBLEM: hwclock busted w/ M48T59 RTC (regression)
From: Nick Bowler @ 2025-12-14 22:04 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: linux-kernel, regressions, linux-rtc, Esben Haabendal, stable,
sparclinux
In-Reply-To: <48db01b1-f4e5-4687-8ffb-472981d153ed@leemhuis.info>
On Mon, Dec 08, 2025 at 03:35:42PM +0100, Thorsten Leemhuis wrote:
> Lo!
>
> On 11/26/25 04:18, Nick Bowler wrote:
> > Any thoughts?
>
> Not really, just a vague idea (and reminder, this is not my area or
> expertise, I'm just tracking regressions):
>
> Two fixes were proposed for the culprit, see:
>
> https://lore.kernel.org/all/BN0PR08MB69510928028C933749F4139383D1A@BN0PR08MB6951.namprd08.prod.outlook.com/
> https://lore.kernel.org/all/BN0PR08MB6951415A751F236375A2945683D1A@BN0PR08MB6951.namprd08.prod.outlook.com/
The first link is a patch for a totally different driver, as far as I
know not relevant to any system I have, but I guess that makes at least
3 different systems which have regressed...
I can't figure out how to turn the second link into a correctly-
formatted patch file, but since it is a one-line change I just manually
applied it on top of 6.19-rc1. This appears to fix the problem.
Thanks,
Nick
^ permalink raw reply
* Re: [GIT PULL] RTC for 6.19
From: pr-tracker-bot @ 2025-12-13 5:50 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: Linus Torvalds, linux-rtc, linux-kernel
In-Reply-To: <2025121222483455e77b38@mail.local>
The pull request you sent on Fri, 12 Dec 2025 23:48:34 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-6.19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d324e9a91502184e0ac201293a6ec0fbe10458ed
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [GIT PULL] RTC for 6.19
From: Alexandre Belloni @ 2025-12-12 22:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-rtc, linux-kernel
Hello Linus,
Here is the RTC subsystem pull request for 6.19. We have three new
drivers this cycle, they account for the majority of the added lines.
I may send you a few fixes after the merge windows as I still need to
review them.
The following changes since commit 3a8660878839faadb4f1a6dd72c3179c1df56787:
Linux 6.18-rc1 (2025-10-12 13:42:36 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-6.19
for you to fetch changes up to 16bd954c93360145bc77cc601e350913fc28182d:
rtc: spacemit: MFD_SPACEMIT_P1 as dependencies (2025-12-08 23:02:10 +0100)
----------------------------------------------------------------
RTC for 6.19
Subsystem:
- stop setting max_user_freq from the individual drivers as this has not been
hardware related for a while
New drivers:
- Andes ATCRTC100
- Apple SMC
- Nvidia VRS
Drivers:
- renesas-rtca3: add RZ/V2H support
- tegra: add ACPI support
----------------------------------------------------------------
Akhilesh Patil (1):
rtc: isl12026: Add id_table
Akiyoshi Kurita (1):
Documentation: ABI: testing: Fix "upto" typo in rtc-cdev
Alexander Kurz (1):
rtc: Kconfig: add MC34708 to mc13xxx help text
Alexandre Belloni (12):
rtc: amlogic-a4: simplify probe
rtc: sa1100: stop setting max_user_freq
rtc: ds1685: stop setting max_user_freq
rtc: pic32: stop setting max_user_freq
rtc: renesas-rtca3: stop setting max_user_freq
rtc: rv3028: stop setting max_user_freq
rtc: rv3032: stop setting max_user_freq
rtc: rv8803: stop setting max_user_freq
rtc: rx6110: stop setting max_user_freq
rtc: rx8010: stop setting max_user_freq
rtc: rx8025: stop setting max_user_freq
rtc: sh: stop setting max_user_freq
CL Wang (3):
dt-bindings: rtc: Add support for ATCRTC100 RTC
MAINTAINERS: Add entry for ATCRTC100 RTC driver
rtc: atcrtc100: Add ATCRTC100 RTC driver
Dan Carpenter (1):
rtc: atcrtc100: Fix signedness bug in probe()
Haotian Zhang (2):
rtc: amlogic-a4: fix double free caused by devm
rtc: gamecube: Check the return value of ioremap()
Hector Martin (1):
rtc: Add new rtc-macsmc driver for Apple Silicon Macs
Kartik Rajput (3):
rtc: tegra: Use devm_clk_get_enabled() in probe
rtc: tegra: Add ACPI support
rtc: tegra: Replace deprecated SIMPLE_DEV_PM_OPS
Lukas Bulwahn (1):
MAINTAINERS: drop unneeded file entry in NVIDIA VRS RTC DRIVER
Nick Huang (1):
rtc: s35390a: use u8 instead of char for register buffer
Nuno Sá (1):
rtc: max31335: Fix ignored return value in set_alarm
Ovidiu Panait (2):
dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H support
rtc: renesas-rtca3: Add support for multiple reset lines
Shubhi Garg (2):
dt-bindings: rtc: Document NVIDIA VRS RTC
rtc: nvvrs: add NVIDIA VRS RTC device driver
Sven Peter (1):
dt-bindings: rtc: Add Apple SMC RTC
Troy Mitchell (1):
rtc: spacemit: MFD_SPACEMIT_P1 as dependencies
Documentation/ABI/testing/rtc-cdev | 2 +-
.../devicetree/bindings/mfd/apple,smc.yaml | 9 +
.../bindings/rtc/andestech,atcrtc100.yaml | 43 ++
.../devicetree/bindings/rtc/apple,smc-rtc.yaml | 35 ++
.../devicetree/bindings/rtc/nvidia,vrs-10.yaml | 59 +++
.../devicetree/bindings/rtc/renesas,rz-rtca3.yaml | 46 +-
MAINTAINERS | 15 +
drivers/rtc/Kconfig | 41 +-
drivers/rtc/Makefile | 3 +
drivers/rtc/rtc-amlogic-a4.c | 32 +-
drivers/rtc/rtc-atcrtc100.c | 381 +++++++++++++++
drivers/rtc/rtc-ds1685.c | 3 -
drivers/rtc/rtc-gamecube.c | 4 +
drivers/rtc/rtc-isl12026.c | 7 +
drivers/rtc/rtc-macsmc.c | 140 ++++++
drivers/rtc/rtc-max31335.c | 6 +-
drivers/rtc/rtc-nvidia-vrs10.c | 542 +++++++++++++++++++++
drivers/rtc/rtc-pic32.c | 2 -
drivers/rtc/rtc-renesas-rtca3.c | 3 +-
drivers/rtc/rtc-rv3028.c | 2 -
drivers/rtc/rtc-rv3032.c | 2 -
drivers/rtc/rtc-rv8803.c | 2 -
drivers/rtc/rtc-rx6110.c | 2 -
drivers/rtc/rtc-rx8010.c | 1 -
drivers/rtc/rtc-rx8025.c | 2 -
drivers/rtc/rtc-s35390a.c | 18 +-
drivers/rtc/rtc-sa1100.c | 3 -
drivers/rtc/rtc-sh.c | 1 -
drivers/rtc/rtc-tegra.c | 45 +-
include/linux/rtc/ds1685.h | 1 -
30 files changed, 1352 insertions(+), 100 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/andestech,atcrtc100.yaml
create mode 100644 Documentation/devicetree/bindings/rtc/apple,smc-rtc.yaml
create mode 100644 Documentation/devicetree/bindings/rtc/nvidia,vrs-10.yaml
create mode 100644 drivers/rtc/rtc-atcrtc100.c
create mode 100644 drivers/rtc/rtc-macsmc.c
create mode 100644 drivers/rtc/rtc-nvidia-vrs10.c
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v1 07/17] rtc: optee: Make use of tee bus methods
From: Uwe Kleine-König @ 2025-12-11 17:15 UTC (permalink / raw)
To: Jens Wiklander, Clément Léger, Alexandre Belloni
Cc: Sumit Garg, op-tee, linux-rtc, linux-kernel
In-Reply-To: <cover.1765472125.git.u.kleine-koenig@baylibre.com>
The tee bus got dedicated callbacks for probe and remove. Make use of
these. This fixes a runtime warning about the driver needing to be
converted to the bus methods.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/rtc/rtc-optee.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
index f924a729ead0..eefde789d194 100644
--- a/drivers/rtc/rtc-optee.c
+++ b/drivers/rtc/rtc-optee.c
@@ -547,9 +547,9 @@ static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
return 0;
}
-static int optee_rtc_probe(struct device *dev)
+static int optee_rtc_probe(struct tee_client_device *rtc_device)
{
- struct tee_client_device *rtc_device = to_tee_client_device(dev);
+ struct device *dev = &rtc_device->dev;
struct tee_ioctl_open_session_arg sess2_arg = {0};
struct tee_ioctl_open_session_arg sess_arg = {0};
struct optee_rtc *priv;
@@ -682,8 +682,9 @@ static int optee_rtc_probe(struct device *dev)
return err;
}
-static int optee_rtc_remove(struct device *dev)
+static void optee_rtc_remove(struct tee_client_device *rtc_device)
{
+ struct device *dev = &rtc_device->dev;
struct optee_rtc *priv = dev_get_drvdata(dev);
if (priv->features & TA_RTC_FEATURE_ALARM) {
@@ -696,8 +697,6 @@ static int optee_rtc_remove(struct device *dev)
tee_shm_free(priv->shm);
tee_client_close_session(priv->ctx, priv->session_id);
tee_client_close_context(priv->ctx);
-
- return 0;
}
static int optee_rtc_suspend(struct device *dev)
@@ -724,10 +723,10 @@ MODULE_DEVICE_TABLE(tee, optee_rtc_id_table);
static struct tee_client_driver optee_rtc_driver = {
.id_table = optee_rtc_id_table,
+ .probe = optee_rtc_probe,
+ .remove = optee_rtc_remove,
.driver = {
.name = "optee_rtc",
- .probe = optee_rtc_probe,
- .remove = optee_rtc_remove,
.pm = pm_sleep_ptr(&optee_rtc_pm_ops),
},
};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 06/17] rtc: optee: Migrate to use tee specific driver registration function
From: Uwe Kleine-König @ 2025-12-11 17:15 UTC (permalink / raw)
To: Jens Wiklander, Clément Léger, Alexandre Belloni
Cc: Sumit Garg, op-tee, linux-rtc, linux-kernel
In-Reply-To: <cover.1765472125.git.u.kleine-koenig@baylibre.com>
The tee subsystem recently got a set of dedicated functions to register
(and unregister) a tee driver. Make use of them. These care for setting the
driver's bus (so the explicit assignment can be dropped) and the driver
owner (which is an improvement this driver benefits from).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/rtc/rtc-optee.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
index 184c6d142801..f924a729ead0 100644
--- a/drivers/rtc/rtc-optee.c
+++ b/drivers/rtc/rtc-optee.c
@@ -726,25 +726,13 @@ static struct tee_client_driver optee_rtc_driver = {
.id_table = optee_rtc_id_table,
.driver = {
.name = "optee_rtc",
- .bus = &tee_bus_type,
.probe = optee_rtc_probe,
.remove = optee_rtc_remove,
.pm = pm_sleep_ptr(&optee_rtc_pm_ops),
},
};
-static int __init optee_rtc_mod_init(void)
-{
- return driver_register(&optee_rtc_driver.driver);
-}
-
-static void __exit optee_rtc_mod_exit(void)
-{
- driver_unregister(&optee_rtc_driver.driver);
-}
-
-module_init(optee_rtc_mod_init);
-module_exit(optee_rtc_mod_exit);
+module_tee_client_driver(optee_rtc_driver);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Clément Léger <clement.leger@bootlin.com>");
--
2.47.3
^ permalink raw reply related
* [PATCH v1 00/17] tee: Use bus callbacks instead of driver callbacks
From: Uwe Kleine-König @ 2025-12-11 17:14 UTC (permalink / raw)
To: Jens Wiklander, 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, Michael Chan,
Pavan Chebbi, Rafał Miłecki, James Bottomley,
Jarkko Sakkinen, Mimi Zohar, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, Peter Huewe
Cc: op-tee, linux-kernel, linux-crypto, linux-rtc, linux-efi,
linux-stm32, linux-arm-kernel, Cristian Marussi, arm-scmi, netdev,
linux-mips, linux-integrity, keyrings, linux-security-module,
Jason Gunthorpe
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.)
The patches #4 - #17 depend on the first two, so if they should be
applied to their respective subsystem trees these must contain the first
two patches first.
Note that after patch #2 is applied, unconverted drivers provoke a
warning in driver_register(), so it would be good for the user
experience if the whole series goes in during a single merge window. So
I guess an immutable branch containing the frist three patches that can
be merged into the other subsystem trees would be sensible.
After all patches are applied, tee_bus_type can be made private to
drivers/tee as it's not used in other places any more.
Best regards
Uwe
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: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
--
2.47.3
^ permalink raw reply
* [PATCH] rtc: pcf2127: clear the PWRMNG bits for pcf2131
From: Alessandro Di Chiara via B4 Relay @ 2025-12-10 20:19 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Alessandro Di Chiara
From: Alessandro Di Chiara <alessandro.dichiara@se.com>
The pcf2131 does not retain the date by default. This is because the
reset value of the PWRMNG bits is 111, which is different from the
pcf2127/pcf2129, whose reset value is 000.
To keep consistency with the other rtc handled by the driver,
clear the PWRMNG bits for pcf2131 to enable:
- Battery switch-over function in standard mode.
- Battery low detection function.
Signed-off-by: Alessandro Di Chiara <alessandro.dichiara@se.com>
---
Hi,
this patch enables battery switch-over and low detection functions for
the rtc pcf2131.
Tested only with pcf2131.
---
drivers/rtc/rtc-pcf2127.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index bb4fe81d3d62..c6ea679645f2 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -1329,8 +1329,11 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
* Clear battery interrupt flags which can block new trigger events.
* Note: This is the default chip behaviour but added to ensure
* correct tamper timestamp and interrupt function.
+ * For pcf2131, clear the PWRMNG bits[7:5] because the reset value
+ * is 111, which is different from 2127/2129.
*/
ret = regmap_update_bits(pcf2127->regmap, PCF2127_REG_CTRL3,
+ (pcf2127->cfg->type == PCF2131 ? PCF2127_CTRL3_PM : 0) |
PCF2127_BIT_CTRL3_BTSE |
PCF2127_BIT_CTRL3_BIE |
PCF2127_BIT_CTRL3_BLIE, 0);
---
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
change-id: 20251210-rtc-pcf2131-clear-pwrmng-bits-20c33af7721c
Best regards,
--
Alessandro Di Chiara <alessandro.dichiara@se.com>
^ permalink raw reply related
* Re: [PATCH 1/4] rtc: zynqmp: correct frequency value
From: Tomas Melin @ 2025-12-10 12:29 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB980479009955E816E72E6EA892A3A@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 09/12/2025 18:51, T, Harini wrote:
> [Public]
>
> Hi,
>
>> -----Original Message-----
>> From: Tomas Melin <tomas.melin@vaisala.com>
>> Sent: Monday, December 1, 2025 6:20 PM
>> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
>> Subject: [PATCH 1/4] rtc: zynqmp: correct frequency value
>>
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> Fix calibration value in case a clock reference is provided.
>> The actual calibration value written into register is
>> frequency - 1.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> drivers/rtc/rtc-zynqmp.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
>> index
>> 3baa2b481d9f2008750046005283b98a0d546c5c..856bc1678e7d31144f320ae
>> 9f75fc58c742a2a64 100644
>> --- a/drivers/rtc/rtc-zynqmp.c
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -345,7 +345,10 @@ static int xlnx_rtc_probe(struct platform_device
>> *pdev)
>> &xrtcdev->freq);
>> if (ret)
>> xrtcdev->freq = RTC_CALIB_DEF;
>> + } else {
>> + xrtcdev->freq--;
> If freq > 65536, the 16-bit register silently truncates.
> Please add some checks for above mentioned scenario.
That is indeed a scenario that is not accounted for in the current
driver. I can add a separate patch for that as part of this series.
Thanks,
Tomas
>> }
>> +
>> ret = readl(xrtcdev->reg_base + RTC_CALIB_RD);
>> if (!ret)
>> writel(xrtcdev->freq, (xrtcdev->reg_base + RTC_CALIB_WR));
>>
>> --
>> 2.47.3
>>
> Thanks,
> Harini T
^ permalink raw reply
* Re: [PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges
From: Tomas Melin @ 2025-12-10 12:25 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB98046A63E80D7A7FA299366E92A3A@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 09/12/2025 21:28, T, Harini wrote:
> [Public]
>
> Hi,
>
>> -----Original Message-----
>> From: Tomas Melin <tomas.melin@vaisala.com>
>> Sent: Monday, December 1, 2025 6:20 PM
>> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
>> Subject: [PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges
>>
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> Maximum and minimum offsets in ppb that can be handled are dependent
>> on the rtc clock frequency and what can fit in the 16-bit register field.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> drivers/rtc/rtc-zynqmp.c | 8 +++-----
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
>> 3bc8831ba2c4c4c701a49506b67ae6174f3ade3d..0cebc99b15a6de2440a60afc
>> 2bd1769eccfa84b3 100644
>> --- a/drivers/rtc/rtc-zynqmp.c
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -44,8 +44,6 @@
>> #define RTC_FR_MASK 0xF0000
>> #define RTC_FR_MAX_TICKS 16
>> #define RTC_PPB 1000000000LL
>> -#define RTC_MIN_OFFSET -32768000
>> -#define RTC_MAX_OFFSET 32767000
>>
>> struct xlnx_rtc_dev {
>> struct rtc_device *rtc;
>> @@ -215,12 +213,12 @@ static int xlnx_rtc_set_offset(struct device *dev,
>> long offset)
>>
>> /* ticks to reach RTC_PPB */
>> tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
>> - if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
>> - return -ERANGE;
>> -
>> /* Number ticks for given offset */
>> max_tick = div_s64_rem(offset, tick_mult, &fract_offset);
>>
>> + if (freq + max_tick > RTC_TICK_MASK || (freq + max_tick < 1))
> The check 'freq + max_tick < 1' should be '<2' to prevent writing 0 to the calibration register when fract_offset < 0 causes max_tick--.
> Example: freq=32767, max_tick=-32766 passes (sum=1), but after decrement becomes calibval=0.
calibval=0 is not documented as invalid calibration value. AFAIS it
would mean a frequency of 1Hz. Can You provide more info on this?
Thanks,
Tomas
>> + return -ERANGE;
>> +
>> /* Number fractional ticks for given offset */
>> if (fract_offset) {
>> /* round up here so we stay below a full tick */
>>
>> --
>> 2.47.3
>>
>
> Thanks,
> Harini T
>
^ permalink raw reply
* Re: [PATCH 3/4] rtc: zynqmp: rework set_offset
From: Tomas Melin @ 2025-12-10 12:18 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB98045BF8A85640F924BCFD4492A3A@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 09/12/2025 21:03, T, Harini wrote:
> [Public]
>
> Hi,
>
>> -----Original Message-----
>> From: Tomas Melin <tomas.melin@vaisala.com>
>> Sent: Monday, December 1, 2025 6:20 PM
>> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
>> Subject: [PATCH 3/4] rtc: zynqmp: rework set_offset
>>
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> set_offset was using remainder of do_div as tick_mult which resulted in
>> wrong offset. Calibration value also assumed builtin calibration default.
>> Update fract_offset to correctly calculate the value for negative offset and
>> replace the for loop with division.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> drivers/rtc/rtc-zynqmp.c | 29 +++++++++++------------------
>> 1 file changed, 11 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
>> 7af5f6f99538f961a53ff56bfc656c907611b900..3bc8831ba2c4c4c701a49506b6
>> 7ae6174f3ade3d 100644
>> --- a/drivers/rtc/rtc-zynqmp.c
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -208,13 +208,13 @@ static int xlnx_rtc_read_offset(struct device *dev,
>> long *offset) static int xlnx_rtc_set_offset(struct device *dev, long offset) {
>> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
>> - unsigned long long rtc_ppb = RTC_PPB;
>> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
>> + unsigned int calibval, tick_mult, fract_part;
> tick_mult is mentioned as int in previous patch and unsigned here. Justify the type in commit description.
>> unsigned char fract_tick = 0;
>> - unsigned int calibval;
>> - short int max_tick;
>> - int fract_offset;
>> + int freq = xrtcdev->freq;
>> + int max_tick, fract_offset;
> Please follow reverse xmas tree variable ordering.
> Also keep the frac_* variables uniform in both set and read offset functions.
Agreed, I will use same name of variables and types in next version.
>>
>> + /* ticks to reach RTC_PPB */
> The comment is misleading. Its tick_mult is nanoseconds per tick, not a tick count.
Answered in patch 2/4.
>> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
> We can first validate offset and then calculate tick_mult to reduce CPU instructions incase of invalid inputs
In this patch it would in theory apply, but when looking at patch 4/4
You will notice that we need to first calculate the helpers so offset is
then performed as soon as possible.
>> if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
>> return -ERANGE;
>>
>> @@ -223,29 +223,22 @@ static int xlnx_rtc_set_offset(struct device *dev,
>> long offset)
>>
>> /* Number fractional ticks for given offset */
>> if (fract_offset) {
>> + /* round up here so we stay below a full tick */
>> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
>> if (fract_offset < 0) {
>> - fract_offset = fract_offset + tick_mult;
>> + fract_offset += (fract_part * RTC_FR_MAX_TICKS);
> It would be better to add comment to explain on the negative offset borrowing logic
I will add comment about this.
>> max_tick--;
>> }
>> - if (fract_offset > (tick_mult / RTC_FR_MAX_TICKS)) {
>> - for (fract_tick = 1; fract_tick < 16; fract_tick++) {
>> - if (fract_offset <=
>> - (fract_tick *
>> - (tick_mult / RTC_FR_MAX_TICKS)))
>> - break;
>> - }
>> - }
>> + fract_tick = fract_offset / fract_part;
> Its better to use DIV_ROUND_UP()
Please explain why, that would change the end result from what is is now.
Thanks,
Tomas
>> }
>>
>> /* Zynqmp RTC uses second and fractional tick
>> * counters for compensation
>> */
>> - calibval = max_tick + RTC_CALIB_DEF;
>> + calibval = max_tick + freq;
>>
>> if (fract_tick)
>> - calibval |= RTC_FR_EN;
>> -
>> - calibval |= (fract_tick << RTC_FR_DATSHIFT);
>> + calibval |= (RTC_FR_EN | (fract_tick <<
>> + RTC_FR_DATSHIFT));
>>
>> writel(calibval, (xrtcdev->reg_base + RTC_CALIB_WR));
>>
>>
>> --
>> 2.47.3
>>
>
> Regards,
> Harini T
^ permalink raw reply
* Re: [PATCH 2/4] rtc: zynqmp: rework read_offset
From: Tomas Melin @ 2025-12-10 12:04 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB98047B0A754AFFFB01163E0992A3A@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 09/12/2025 19:28, T, Harini wrote:
> [Public]
>
> Hi,
>
>> -----Original Message-----
>> From: Tomas Melin <tomas.melin@vaisala.com>
>> Sent: Monday, December 1, 2025 6:20 PM
>> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
>> Subject: [PATCH 2/4] rtc: zynqmp: rework read_offset
>>
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> read_offset() was using static frequency for determining the tick offset. It was
>> also using remainder from do_div() operation as tick_mult value which
>> caused the offset to be incorrect.
>>
>> At the same time, rework function to improve readability.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> drivers/rtc/rtc-zynqmp.c | 25 ++++++++++++++++---------
>> 1 file changed, 16 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
>> 856bc1678e7d31144f320ae9f75fc58c742a2a64..7af5f6f99538f961a53ff56bfc6
>> 56c907611b900 100644
>> --- a/drivers/rtc/rtc-zynqmp.c
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -178,21 +178,28 @@ static void xlnx_init_rtc(struct xlnx_rtc_dev
>> *xrtcdev) static int xlnx_rtc_read_offset(struct device *dev, long *offset) {
>> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
>> - unsigned long long rtc_ppb = RTC_PPB;
>> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
>> - unsigned int calibval;
>> + unsigned int calibval, fract_data, fract_part;
> Prefer one variable assignment per line for readability.
This is after all quite common practice, and in a function like this
where several variables are needed, I would argue that this is more
readable than the alternative. Is there some convention I'm not aware of?
>> + int max_tick, tick_mult;
> It would be better to explain why tick_mult is changed to int in the commit message.
This is part of the refactoring, mixing signed and unsigned variables in
operations is more risky than having same type.
>> + int freq = xrtcdev->freq;
> Please follow reverse xmas tree variable ordering.
Ok fixing this and other occurances.
>> long offset_val;
>>
>> + /* ticks to reach RTC_PPB */
> The comment is misleading. Its tick_mult is nanoseconds per tick, not a tick count.
Perhaps the comment was not well formulated. I suggest changing to
/* Tick to offset multiplier */
as that it what it is primarily used for. Would that be okay for You?
Thanks,
Tomas
>> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, freq);
>> +
>> calibval = readl(xrtcdev->reg_base + RTC_CALIB_RD);
>> /* Offset with seconds ticks */
>> - offset_val = calibval & RTC_TICK_MASK;
>> - offset_val = offset_val - RTC_CALIB_DEF;
>> - offset_val = offset_val * tick_mult;
>> + max_tick = calibval & RTC_TICK_MASK;
>> + offset_val = max_tick - freq;
>> + /* Convert to ppb */
>> + offset_val *= tick_mult;
>>
>> /* Offset with fractional ticks */
>> - if (calibval & RTC_FR_EN)
>> - offset_val += ((calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT)
>> - * (tick_mult / RTC_FR_MAX_TICKS);
>> + if (calibval & RTC_FR_EN) {
>> + fract_data = (calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT;
>> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
>> + offset_val += (fract_part * fract_data);
>> + }
>> +
>> *offset = offset_val;
>>
>> return 0;
>>
>> --
>> 2.47.3
>>
> Regards,
> Harini T
>
^ permalink raw reply
* RE: [PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges
From: T, Harini @ 2025-12-09 19:28 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20251201-zynqmp-rtc-updates-v1-4-33875c1e385b@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Monday, December 1, 2025 6:20 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Maximum and minimum offsets in ppb that can be handled are dependent
> on the rtc clock frequency and what can fit in the 16-bit register field.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 3bc8831ba2c4c4c701a49506b67ae6174f3ade3d..0cebc99b15a6de2440a60afc
> 2bd1769eccfa84b3 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -44,8 +44,6 @@
> #define RTC_FR_MASK 0xF0000
> #define RTC_FR_MAX_TICKS 16
> #define RTC_PPB 1000000000LL
> -#define RTC_MIN_OFFSET -32768000
> -#define RTC_MAX_OFFSET 32767000
>
> struct xlnx_rtc_dev {
> struct rtc_device *rtc;
> @@ -215,12 +213,12 @@ static int xlnx_rtc_set_offset(struct device *dev,
> long offset)
>
> /* ticks to reach RTC_PPB */
> tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
> - if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
> - return -ERANGE;
> -
> /* Number ticks for given offset */
> max_tick = div_s64_rem(offset, tick_mult, &fract_offset);
>
> + if (freq + max_tick > RTC_TICK_MASK || (freq + max_tick < 1))
The check 'freq + max_tick < 1' should be '<2' to prevent writing 0 to the calibration register when fract_offset < 0 causes max_tick--.
Example: freq=32767, max_tick=-32766 passes (sum=1), but after decrement becomes calibval=0.
> + return -ERANGE;
> +
> /* Number fractional ticks for given offset */
> if (fract_offset) {
> /* round up here so we stay below a full tick */
>
> --
> 2.47.3
>
Thanks,
Harini T
^ permalink raw reply
* RE: [PATCH 3/4] rtc: zynqmp: rework set_offset
From: T, Harini @ 2025-12-09 19:03 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20251201-zynqmp-rtc-updates-v1-3-33875c1e385b@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Monday, December 1, 2025 6:20 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH 3/4] rtc: zynqmp: rework set_offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> set_offset was using remainder of do_div as tick_mult which resulted in
> wrong offset. Calibration value also assumed builtin calibration default.
> Update fract_offset to correctly calculate the value for negative offset and
> replace the for loop with division.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 29 +++++++++++------------------
> 1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 7af5f6f99538f961a53ff56bfc656c907611b900..3bc8831ba2c4c4c701a49506b6
> 7ae6174f3ade3d 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -208,13 +208,13 @@ static int xlnx_rtc_read_offset(struct device *dev,
> long *offset) static int xlnx_rtc_set_offset(struct device *dev, long offset) {
> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
> - unsigned long long rtc_ppb = RTC_PPB;
> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
> + unsigned int calibval, tick_mult, fract_part;
tick_mult is mentioned as int in previous patch and unsigned here. Justify the type in commit description.
> unsigned char fract_tick = 0;
> - unsigned int calibval;
> - short int max_tick;
> - int fract_offset;
> + int freq = xrtcdev->freq;
> + int max_tick, fract_offset;
Please follow reverse xmas tree variable ordering.
Also keep the frac_* variables uniform in both set and read offset functions.
>
> + /* ticks to reach RTC_PPB */
The comment is misleading. Its tick_mult is nanoseconds per tick, not a tick count.
> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
We can first validate offset and then calculate tick_mult to reduce CPU instructions incase of invalid inputs
> if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
> return -ERANGE;
>
> @@ -223,29 +223,22 @@ static int xlnx_rtc_set_offset(struct device *dev,
> long offset)
>
> /* Number fractional ticks for given offset */
> if (fract_offset) {
> + /* round up here so we stay below a full tick */
> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
> if (fract_offset < 0) {
> - fract_offset = fract_offset + tick_mult;
> + fract_offset += (fract_part * RTC_FR_MAX_TICKS);
It would be better to add comment to explain on the negative offset borrowing logic
> max_tick--;
> }
> - if (fract_offset > (tick_mult / RTC_FR_MAX_TICKS)) {
> - for (fract_tick = 1; fract_tick < 16; fract_tick++) {
> - if (fract_offset <=
> - (fract_tick *
> - (tick_mult / RTC_FR_MAX_TICKS)))
> - break;
> - }
> - }
> + fract_tick = fract_offset / fract_part;
Its better to use DIV_ROUND_UP()
> }
>
> /* Zynqmp RTC uses second and fractional tick
> * counters for compensation
> */
> - calibval = max_tick + RTC_CALIB_DEF;
> + calibval = max_tick + freq;
>
> if (fract_tick)
> - calibval |= RTC_FR_EN;
> -
> - calibval |= (fract_tick << RTC_FR_DATSHIFT);
> + calibval |= (RTC_FR_EN | (fract_tick <<
> + RTC_FR_DATSHIFT));
>
> writel(calibval, (xrtcdev->reg_base + RTC_CALIB_WR));
>
>
> --
> 2.47.3
>
Regards,
Harini T
^ permalink raw reply
* RE: [PATCH 2/4] rtc: zynqmp: rework read_offset
From: T, Harini @ 2025-12-09 17:28 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20251201-zynqmp-rtc-updates-v1-2-33875c1e385b@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Monday, December 1, 2025 6:20 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH 2/4] rtc: zynqmp: rework read_offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> read_offset() was using static frequency for determining the tick offset. It was
> also using remainder from do_div() operation as tick_mult value which
> caused the offset to be incorrect.
>
> At the same time, rework function to improve readability.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 856bc1678e7d31144f320ae9f75fc58c742a2a64..7af5f6f99538f961a53ff56bfc6
> 56c907611b900 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -178,21 +178,28 @@ static void xlnx_init_rtc(struct xlnx_rtc_dev
> *xrtcdev) static int xlnx_rtc_read_offset(struct device *dev, long *offset) {
> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
> - unsigned long long rtc_ppb = RTC_PPB;
> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
> - unsigned int calibval;
> + unsigned int calibval, fract_data, fract_part;
Prefer one variable assignment per line for readability.
> + int max_tick, tick_mult;
It would be better to explain why tick_mult is changed to int in the commit message.
> + int freq = xrtcdev->freq;
Please follow reverse xmas tree variable ordering.
> long offset_val;
>
> + /* ticks to reach RTC_PPB */
The comment is misleading. Its tick_mult is nanoseconds per tick, not a tick count.
> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, freq);
> +
> calibval = readl(xrtcdev->reg_base + RTC_CALIB_RD);
> /* Offset with seconds ticks */
> - offset_val = calibval & RTC_TICK_MASK;
> - offset_val = offset_val - RTC_CALIB_DEF;
> - offset_val = offset_val * tick_mult;
> + max_tick = calibval & RTC_TICK_MASK;
> + offset_val = max_tick - freq;
> + /* Convert to ppb */
> + offset_val *= tick_mult;
>
> /* Offset with fractional ticks */
> - if (calibval & RTC_FR_EN)
> - offset_val += ((calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT)
> - * (tick_mult / RTC_FR_MAX_TICKS);
> + if (calibval & RTC_FR_EN) {
> + fract_data = (calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT;
> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
> + offset_val += (fract_part * fract_data);
> + }
> +
> *offset = offset_val;
>
> return 0;
>
> --
> 2.47.3
>
Regards,
Harini T
^ permalink raw reply
* RE: [PATCH 1/4] rtc: zynqmp: correct frequency value
From: T, Harini @ 2025-12-09 16:51 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20251201-zynqmp-rtc-updates-v1-1-33875c1e385b@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Monday, December 1, 2025 6:20 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH 1/4] rtc: zynqmp: correct frequency value
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Fix calibration value in case a clock reference is provided.
> The actual calibration value written into register is
> frequency - 1.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
> index
> 3baa2b481d9f2008750046005283b98a0d546c5c..856bc1678e7d31144f320ae
> 9f75fc58c742a2a64 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -345,7 +345,10 @@ static int xlnx_rtc_probe(struct platform_device
> *pdev)
> &xrtcdev->freq);
> if (ret)
> xrtcdev->freq = RTC_CALIB_DEF;
> + } else {
> + xrtcdev->freq--;
If freq > 65536, the 16-bit register silently truncates.
Please add some checks for above mentioned scenario.
> }
> +
> ret = readl(xrtcdev->reg_base + RTC_CALIB_RD);
> if (!ret)
> writel(xrtcdev->freq, (xrtcdev->reg_base + RTC_CALIB_WR));
>
> --
> 2.47.3
>
Thanks,
Harini T
^ permalink raw reply
* Re: [PATCH] Documentation: ABI: testing: Fix "upto" typo in rtc-cdev
From: Alexandre Belloni @ 2025-12-08 22:10 UTC (permalink / raw)
To: Akiyoshi Kurita; +Cc: linux-rtc, linux-kernel
In-Reply-To: <20251112113759.2953758-1-weibu@redadmin.org>
On Wed, 12 Nov 2025 20:37:59 +0900, Akiyoshi Kurita wrote:
> The word "upto" is a common typo for "up to". Correct this.
>
>
Applied, thanks!
[1/1] Documentation: ABI: testing: Fix "upto" typo in rtc-cdev
https://git.kernel.org/abelloni/c/22a6db422537
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2] rtc: gamecube: Check the return value of ioremap()
From: Alexandre Belloni @ 2025-12-08 22:10 UTC (permalink / raw)
To: Haotian Zhang; +Cc: linkmauve, linux-rtc, linux-kernel
In-Reply-To: <20251126080625.1752-1-vulab@iscas.ac.cn>
On Wed, 26 Nov 2025 16:06:25 +0800, Haotian Zhang wrote:
> The function ioremap() in gamecube_rtc_read_offset_from_sram() can fail
> and return NULL, which is dereferenced without checking, leading to a
> NULL pointer dereference.
>
> Add a check for the return value of ioremap() and return -ENOMEM on
> failure.
>
> [...]
Applied, thanks!
[1/1] rtc: gamecube: Check the return value of ioremap()
https://git.kernel.org/abelloni/c/d1220e47e4bd
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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