* [PATCH 6/6] arm64: dts: rockchip: Enable CAN controller on RK3588-Tiger-Haikou
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
CAN0 is piped through the Q7-connector to the CAN-Header on the Haikou
base-board, so enable support for it there.
At least on RK3588-Tiger, the CAN clocks default to 99MHz, limiting
usable CAN bitrates without skew. Errata documentation mentions
300MHz as the default frequency on RK3568, so replicate this here
to allow more bitrates.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts b/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
index 873fbeb8daa1..6273e695b039 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts
@@ -155,6 +155,12 @@ vddd_audio_1v6: regulator-vddd-audio-1v6 {
};
};
+&can0 {
+ assigned-clocks = <&cru CLK_CAN0>;
+ assigned-clock-rates = <300000000>;
+ status = "okay";
+};
+
&combphy2_psu {
status = "okay";
};
--
2.47.3
^ permalink raw reply related
* [PATCH 3/6] can: rockchip-canfd: enable erratum 6 on RK3588
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
Sending extended CAN frames from the RK3588's CAN controller, sometimes
sends standard frames, as explained in the erratum's description:
can0 00001234 [4] DE AD BE EF
can0 00000001 [4] DE AD BE EF
can0 000007FF [4] DE AD BE EF
can0 00000800 [4] DE AD BE EF
can0 1FFFFFFF [4] DE AD BE EF
can0 12345678 [4] DE AD BE EF
can0 234 [4] DE AD BE EF
can0 00000001 [4] DE AD BE EF
Enabling the erratum, introduces the correct behaviour in re-sending the
frame:
can0 1FFFFFFF [4] DE AD BE EF
can0 12345678 [4] DE AD BE EF
can0 234 [4] DE AD BE EF
can0 00001234 [4] DE AD BE EF
can0 00000001 [4] DE AD BE EF
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 707f387e7cf4..105ca4d5cbef 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -53,6 +53,7 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {
.model = RKCANFD_MODEL_RK3588,
.quirks = /* Possible more Errata */
+ RKCANFD_QUIRK_RK3568_ERRATUM_6,
RKCANFD_QUIRK_CANFD_BROKEN,
};
--
2.47.3
^ permalink raw reply related
* [PATCH 2/6] can: rockchip-canfd: add support for the RK3588 variant
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
The RK3588 SoC uses a variant of this controller.
From the start it does not claim to support can-fd in any part of the
documentation, so it seems that is still broken.
Further errata will be enabled in subsequent patches, with more
in-depth explanation.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 11 +++++++++++
drivers/net/can/rockchip/rockchip_canfd.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e4ed..707f387e7cf4 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -50,6 +50,12 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
RKCANFD_QUIRK_CANFD_BROKEN,
};
+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {
+ .model = RKCANFD_MODEL_RK3588,
+ .quirks = /* Possibly more errata */
+ RKCANFD_QUIRK_CANFD_BROKEN,
+};
+
static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
{
switch (model) {
@@ -57,6 +63,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
return "rk3568v2";
case RKCANFD_MODEL_RK3568V3:
return "rk3568v3";
+ case RKCANFD_MODEL_RK3588:
+ return "rk3588";
}
return "<unknown>";
@@ -846,6 +854,9 @@ static const struct of_device_id rkcanfd_of_match[] = {
}, {
.compatible = "rockchip,rk3568v3-canfd",
.data = &rkcanfd_devtype_data_rk3568v3,
+ }, {
+ .compatible = "rockchip,rk3588-canfd",
+ .data = &rkcanfd_devtype_data_rk3588,
}, {
/* sentinel */
},
diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
index 93131c7d7f54..92566822e141 100644
--- a/drivers/net/can/rockchip/rockchip_canfd.h
+++ b/drivers/net/can/rockchip/rockchip_canfd.h
@@ -434,6 +434,7 @@
enum rkcanfd_model {
RKCANFD_MODEL_RK3568V2 = 0x35682,
RKCANFD_MODEL_RK3568V3 = 0x35683,
+ RKCANFD_MODEL_RK3588 = 0x3588,
};
struct rkcanfd_devtype_data {
--
2.47.3
^ permalink raw reply related
* [PATCH 1/6] dt-bindings: can: rockchip_canfd: add compatible for the RK3588 variant
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
The RK3588 uses a variant of the CAN(-FD) controller introduced at first
with the RK3568 SoC.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
.../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
index a077c0330013..02211ea3ec41 100644
--- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
@@ -20,6 +20,7 @@ properties:
- items:
- const: rockchip,rk3568v3-canfd
- const: rockchip,rk3568v2-canfd
+ - const: rockchip,rk3588-canfd
reg:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH 4/6] can: rockchip-canfd: enable erratum 5 on RK3588
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing, Heiko Stuebner
In-Reply-To: <20260630164336.3444550-1-heiko@sntech.de>
From: Heiko Stuebner <heiko.stuebner@cherry.de>
Lowering the clock-frequency as described in the erratum, also
leads to empty RX-fifos immediately, indicating that the
erratum is also present on the RK3588 variant.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 105ca4d5cbef..f3c8b54a9f02 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -53,7 +53,7 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588 = {
.model = RKCANFD_MODEL_RK3588,
.quirks = /* Possible more Errata */
- RKCANFD_QUIRK_RK3568_ERRATUM_6,
+ RKCANFD_QUIRK_RK3568_ERRATUM_5 | RKCANFD_QUIRK_RK3568_ERRATUM_6,
RKCANFD_QUIRK_CANFD_BROKEN,
};
--
2.47.3
^ permalink raw reply related
* [PATCH 0/6] Enable CAN support on RK3588
From: Heiko Stuebner @ 2026-06-30 16:43 UTC (permalink / raw)
To: mkl, mailhol
Cc: kernel, robh, krzk+dt, conor+dt, heiko, shawn.lin, linux-can,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
quentin.schulz, zhangqing
The RK3588 uses basically the same CAN controller as the RK3588, except
the documentation stopped claiming for it to support CAN-FD.
So add a compatible to the binding, the basic driver support and the
errata I could test for so far + enable CAN on the Tiger-Haikou board.
I'm not sure if more errata apply, so I've added Elaine Zhang in Cc
to maybe add more information.
Heiko Stuebner (6):
dt-bindings: can: rockchip_canfd: add compatible for the RK3588
variant
can: rockchip-canfd: add support for the RK3588 variant
can: rockchip-canfd: enable erratum 6 on RK3588
can: rockchip-canfd: enable erratum 5 on RK3588
arm64: dts: rockchip: Add RK3588 CAN controller nodes
arm64: dts: rockchip: Enable CAN controller on RK3588-Tiger-Haikou
.../net/can/rockchip,rk3568v2-canfd.yaml | 1 +
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++
.../boot/dts/rockchip/rk3588-tiger-haikou.dts | 6 +++
.../net/can/rockchip/rockchip_canfd-core.c | 12 ++++++
drivers/net/can/rockchip/rockchip_canfd.h | 1 +
5 files changed, 59 insertions(+)
--
2.47.3
^ permalink raw reply
* Re: [PATCH v3 5/6] irqchip/gic-v3-its: some minor improvement in comments
From: Thomas Gleixner @ 2026-06-30 16:46 UTC (permalink / raw)
To: Kemeng Shi, maz; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260623020135.3584-6-shikemeng@huaweicloud.com>
On Tue, Jun 23 2026 at 10:01, Kemeng Shi wrote:
> 1. "If it some" -> "If some"
> 2. "by table by reading" -> by reading"
> 3. "reading bit at offset '62'" -> "reading GITS_BASER_INDIRECT"
Please don't enumerate WHAT the patch is doing. We all can see that from
the patch itself.
Something like that is sufficient and clear enough:
'Fix grammar and replace a bit number with the symbol for better
readability'
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Conor Dooley @ 2026-06-30 17:01 UTC (permalink / raw)
To: Gregor Herburger
Cc: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <qgoblikagfbcmbqoryw4ajfa6qyx3wpj4qfeuuntima542qlkq@evebdvjaxern>
[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]
On Tue, Jun 30, 2026 at 03:56:32PM +0200, Gregor Herburger wrote:
> Hi Conor,
>
> On Fri, Jun 26, 2026 at 04:57:35PM +0100, Conor Dooley wrote:
> > On Fri, Jun 26, 2026 at 09:35:05AM +0200, Gregor Herburger wrote:
> > > The Raspberry Pi firmware allows to set a reboot mode called tryboot
> > > that allows to try booting from a different partition to allow updating
> > > of the boot partition. Allow reboot mode properties by referencing the
> > > reboot-mode schema.
> > >
> > > Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> > > ---
> > > .../devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > > index 983ea80eaec97..30b490e0d9fb3 100644
> > > --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > > @@ -133,11 +133,14 @@ properties:
> > > required:
> > > - compatible
> > >
> > > +allOf:
> > > + - $ref: /schemas/power/reset/reboot-mode.yaml#
> > > +
> > > required:
> > > - compatible
> > > - mboxes
> > >
> > > -additionalProperties: false
> > > +unevaluatedProperties: false
> >
> > I think you should keep additionalProperties: false and add
> > mode-normal: true
> > mode-tryboot: true
> >
> > (I don't know if the latter works though, you may need to have a $ref to
> > uint32-array).
> >
> > What you've done permits freeform reboot modes, but I think only normal
> > and tryboot are valid?
>
> Ah yes good point. I do think it should be restricted to
> 'mode-{normal,tryboot}'.
>
> Sashiko also suggested to set maxItems to 1 and I think that is a good idea as
> well, because afaik the firmware only accepts a 32bit value for the reboot flag.
> The $ref to uin32 is not needed that is already enforced by the
> patternProperties "^mode-.*$": in reboot-mode.yaml.
>
> Therefore I will add the following (and keep additionalProperties: false):
>
> properties:
> ...
>
> mode-normal:
> maxItems: 1
>
> mode-tryboot:
> maxItems: 1
>
> allOf:
> - $ref: /schemas/power/reset/reboot-mode.yaml#
>
>
> I will do some more testing and send a v2 later.
Cool, sounds good to me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Conor Dooley @ 2026-06-30 17:05 UTC (permalink / raw)
To: Gokul Praveen
Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar
In-Reply-To: <20260630134324.61085-3-g-praveen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
On Tue, Jun 30, 2026 at 07:13:24PM +0530, Gokul Praveen wrote:
> Update maxItems value of "clocks" property to 3 as description of
> this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
> and phy_en_refclk(optional))
>
> Update the "clock-names" property as well with the 3 clocks.
>
> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
> ---
> .../devicetree/bindings/phy/phy-cadence-torrent.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> index 9af39b33646a..54fe78da297a 100644
> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> @@ -34,7 +34,7 @@ properties:
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
> description:
> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
> pll1_refclk is optional and used for multi-protocol configurations requiring
> @@ -47,7 +47,7 @@ properties:
> minItems: 1
> items:
> - const: refclk
> - - enum: [ pll1_refclk, phy_en_refclk ]
> + - enum: [refclk, pll1_refclk, phy_en_refclk ]
This does not do what you want it to do, I would think, since it means
you can only have two clock names.
Additionally, please restrict 3 clocks to only whatever new TI device
actually has 3 clocks.
pw-bot: changes-requested
Thanks,
Conor.
>
> reg:
> minItems: 1
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 01/10] dt-bindings: mailbox: Add Apple t8122 ASC mailbox
From: Conor Dooley @ 2026-06-30 17:05 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-1-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: mailbox: apple: Add DockChannel mailbox
From: Conor Dooley @ 2026-06-30 17:07 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-2-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]
On Tue, Jun 30, 2026 at 10:54:30PM +1000, Michael Reeves via B4 Relay wrote:
> From: Michael Reeves <michael.reeves077@gmail.com>
>
> DockChannel is a FIFO and interrupt block used by Apple coprocessors
> to exchange byte-stream traffic with the AP.
>
> Describe it as a mailbox provider so HID and future serial clients can
> use the common mailbox API.
>
> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
> ---
> .../bindings/mailbox/apple,dockchannel.yaml | 75 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 76 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml b/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml
> new file mode 100644
> index 000000000000..4f326d8f3d5a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/apple,dockchannel.yaml
Please name this file matching the t8112 compatible (since that's your
fallback).
Otherwise, this looks good.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: changes-requested
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 03/10] dt-bindings: iommu: apple,dart: Add t8122 compatible
From: Conor Dooley @ 2026-06-30 17:07 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-3-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 04/10] dt-bindings: input: apple: Add DockChannel HID transport
From: Conor Dooley @ 2026-06-30 17:08 UTC (permalink / raw)
To: michael.reeves077
Cc: Sven Peter, Janne Grunau, Neal Gompa, Jassi Brar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Dmitry Torokhov,
Jiri Kosina, Benjamin Tissoires, asahi, linux-arm-kernel,
linux-kernel, devicetree, iommu, linux-input
In-Reply-To: <20260630-apple-mtp-keyboard-final-v1-4-506d936a1707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Tue, Jun 30, 2026 at 10:54:32PM +1000, Michael Reeves via B4 Relay wrote:
> From: Michael Reeves <michael.reeves077@gmail.com>
>
> Apple internal keyboards and trackpads behind MTP are exposed through a
> DockChannel HID transport.
>
> Add the client binding tying together the RTKit ASC mailbox,
> DockChannel mailbox, and MTP DART. The keyboard child can provide the
> HID country code used by hid-apple to distinguish layout variants.
>
> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
> ---
> .../bindings/input/apple,dockchannel-hid.yaml | 91 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 92 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml b/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml
> new file mode 100644
> index 000000000000..dbba4fc38971
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/apple,dockchannel-hid.yaml
Same thing here about the filename. Looks good otherwise, so please
change that.
pw-bot: changes-requested
\x02
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC v2 PATCH] reserve_mem: add support for static memory
From: Shyam Saini @ 2026-06-30 17:09 UTC (permalink / raw)
To: shyamsaini, ardb, catalin.marinas, david, linux-arm-kernel, will
Cc: akpm, bboscaccy, bp, dapeng1.mi, ebiggers, elver, enelsonmoore,
feng.tang, gpiccoli, kees, kuba, linux-doc, linux-kernel,
linux-mm, lirongqing, peterz, rdunlap, rppt, tgopinath, tony.luck
In-Reply-To: <aj6SqipC/dIN01iN@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Hi Everyone,
> On 25 Jun 2026 11:37, Mike Rapoport wrote:
> > Hi Shyam,
> >
> > On Wed, Jun 24, 2026 at 06:22:33PM -0700, Shyam Saini wrote:
> > > On 21 Jun 2026 13:36, Mike Rapoport wrote:
> > > > On Thu, Jun 18, 2026 at 11:23:31PM -0700, Shyam Saini wrote:
> > > > > reserve_mem relies on dynamic memory allocation, this limits the
> > > > > usecase where memory is required to be preserved across the boots.
> > > > > Eg: ramoops memory reservation on ACPI platforms
> > > > >
> > > > > So add support to pass a pre-determined static address and reserve
> > > > > memory at a specified location. This enables use case like ramoops
> > > > > on ACPI platforms to reliably access ramoops region with previous
> > > > > boot logs.
> > > > >
> > > > > Also skip the parsing of <align> when static address is passed.
> > > > >
> > > > > Example syntax for static address
> > > > > reserve_mem=4M@0x1E0000000:oops
> > > >
> > > > reserve_mem is best effort by design because such hacks as well as memmap=
> > > > cannot guarantee this memory is actually free.
> > > >
> > > > If you want to preserve ramoops reliably, use KHO with reserve_mem.
> > > > The first kernel will allocate memory, this memory will be preserved by KHO
> > > > and could be picked up by the second kernel.
> > >
> > > ok, On ARM64 DTS systems, we can reserve ramoops memory in the device tree during
> > > the warm reboot.
> >
> > The cc list actually implied x86 ;-)
> > Added arm64 folks now.
>
> Thanks for adding ARM folks, I had just included whatever get_maintainer script
> suggested, sorry.
> > > For an equivalent ARM64 ACPI platform, what is the recommended way to reserve
> > > and preserve that memory across the boots?
> >
> > I don't think it exists, but a command line option (be it memmap= or
> > reserve_mem=) does not seem the right way to me.
> >
> > Most of the arguments that were made against adding memmap= to arm64 [1]
> > apply here.
> >
> > If kexec is an option, KHO provides a reliable way to preserve memory
> > across boots.
> >
> > If kexec is not an option, we should look for a generic way to specify
> > something like DT's reserved_mem for ACPI/EFI systems.
> >
> > [1] https://lkml.kernel.org/lkml/20201118063314.22940-1-song.bao.hua@hisilicon.com/T/
> >
> Well, kexec is one of the option for my use case, it also requires
> memory reservation during warm reboot, I think memory can be reserved in
> the firmware but this will create a dependency on firmware for Linux
> reservation.
>
> It would be great to have a in kernel memory reservation mechanism for
> ARM64 ACPI platforms. I believe some other use cases like PMEM
> reservation would also benefit from this.
>
Following up on this, As Mike pointed that reserve_mem is best effort
reservation mechanism, so what is the recommended reliable Linux
mechanism, if any, to reserve a predetermined memory range during
early boot on ARM64/ACPI platforms for warm boot scenarios? KHO is
one option, but I'm specifically looking for a solution that preserves
the region across warm reboots.
Please let me know.
Thanks,
Shyam
^ permalink raw reply
* Re: [PATCH net-next v9 2/6] dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variant
From: Conor Dooley @ 2026-06-30 17:14 UTC (permalink / raw)
To: lizhi2
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms, lee, wens
In-Reply-To: <20260630063239.1158-1-lizhi2@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: ipmi: Add optional LPC properties to ASPEED BT devices
From: Conor Dooley @ 2026-06-30 17:15 UTC (permalink / raw)
To: YC Hsieh
Cc: Corey Minyard, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery,
openipmi-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org
In-Reply-To: <TY0PR06MB6855F690BCCCA45172F3F0AD93F72@TY0PR06MB6855.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]
On Tue, Jun 30, 2026 at 02:24:52AM +0000, YC Hsieh wrote:
> ************* Email Confidentiality Notice ********************
> 免責聲明:
> 本信件(或其附件)可能包含機密資訊，並受法律保護。如 台端非指定之收件者，請以電子郵件通知本電子郵件之發送者, 並請立即刪除本電子郵件及其附件和銷毀所有複印件。謝謝您的合作!
> 信驊科技以誠信正直原則永續經營企業，並已委由第三方公正單位勤業眾信及信驊科技獨立董事來管理匿名舉報系統，如各個利害關係人等有發現任何違法及違反公司從業道德、違反法令法規及專業準則、亦或霸凌及違反性別平等之情事，請直接透過以下可選擇匿名之舉報系統舉報，再次感謝您協助信驊持續邁向永續經營。信驊科技舉報網站連結：https://secure.conductwatch.com/aspeedtech/
>
> DISCLAIMER:
> This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you.
> ASPEED Technology is committed to sustainable business practices based on integrity and honesty principles. In order to ensure that all information can be openly and transparently communicated, a third-party independent organization, Deloitte and ASPEED Technology's independent directors, have been entrusted to manage the anonymous reporting system. If any stakeholders discover any illegal activities, violations of the company's professional ethics, infringements of laws and regulations, or incidents of bullying and gender inequality, please directly report through the anonymous reporting system provided below. We thank you for your assistance in helping ASPEED Technology continue its journey towards sustainable operations: https://secure.conductwatch.com/aspeedtech/
Sort this out, it's not compatible with mailing lists.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 05/13] KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ
From: Leonardo Bras @ 2026-06-30 17:19 UTC (permalink / raw)
To: Oliver Upton
Cc: Leonardo Bras, Catalin Marinas, Will Deacon, Marc Zyngier,
Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Rafael J. Wysocki, Len Brown, Saket Dumbre, Paolo Bonzini,
Jonathan Cameron, Chengwen Feng, Kees Cook,
Mikołaj Lenczewski, James Morse, Zeng Heng, mrigendrachaubey,
Thomas Huth, Ryan Roberts, Yeoreum Yun, Mark Brown, Kevin Brodsky,
James Clark, Fuad Tabba, Raghavendra Rao Ananta,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng,
linux-arm-kernel, linux-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <akPoyAGX5_ankwWD@kernel.org>
On Tue, Jun 30, 2026 at 09:03:20AM -0700, Oliver Upton wrote:
> On Tue, Jun 30, 2026 at 03:50:17PM +0100, Leonardo Bras wrote:
> > On Mon, Jun 29, 2026 at 10:22:12AM -0700, Oliver Upton wrote:
> > > If we need to initialize the IRQ I'd really like to see device tree
> > > bindings for HACDBSIRQ as well. Pretty much any system us plebs can get
> > > our hands on is gonna be DT anyway.
> >
> > Agree. I started out with ACPI because that's what the main target is, as
> > dirty-logging is focused in Live Migration, which is usually more
> > appreciated in the server space, which generally uses ACPI.
> >
> > I spoke to some people, and I could not hear of anyone releasing a product
> > based in DT that would implement this yet, so I postponed the DT
> > enablement.
>
> Nested virt is always a good example. In some distant future KVM could
> expose FEAT_HACDBS to the L1 hypervisor, and the VMM may be using DT
> instead of ACPI (like kvmtool).
Oh, good point.
>
> > >
> > > > +static irqreturn_t hacdbsirq_handler(int irq, void *pcpu)
> > > > +{
> > > > + u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
> > > > + unsigned long err = FIELD_GET(HACDBSCONS_EL2_ERR_REASON, cons);
> > > > +
> > > > + switch (err) {
> > > > + case HACDBSCONS_EL2_ERR_REASON_NOF:
> > > > + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> > > > + break;
> > > > + case HACDBSCONS_EL2_ERR_REASON_IPAHACF:
> > > > + /* When size not a power of two >= 4k, exit with reserved TTLW */
> > > > + int index = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
> > > > +
> > > > + if (index >= this_cpu_read(hacdbs_pcp.size)) {
> > > > + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> > > > + break;
> > > > + }
> > > > + fallthrough;
> > > > + case HACDBSCONS_EL2_ERR_REASON_STRUCTF:
> > > > + case HACDBSCONS_EL2_ERR_REASON_IPAF:
> > > > + this_cpu_write(hacdbs_pcp.status, HACDBS_ERROR);
> > > > + break;
> > > > + }
> > > > +
> > > > + return IRQ_HANDLED;
> > > > +}
> > >
> > > I have a pretty extreme distaste for creating a state machine between
> > > the callsite and the IRQ handler. The callsite should poll HACDBS for
> > > completion. The thread has nothing better to do anyway.
> >
> > Well, there is one argument it could just wait and save some energy, but I
> > agree it is not relevant in server space.
>
> I wouldn't suggest polling in a tight loop :) I'd say use something like
> __mdelay() to get the core into a low-power state w/o using a naked WFI.
> In fact, that already uses WFxT under the hood.
Awesome!
>
> > The main reason I did this is
> > because I am planning on later doing an improved version of this that would
> > clean the dirty-bit *while* running the guest, and having the IRQ is needed
> > for exiting guest so we can notify userspace the cleaning is done. So I
> > laid the HACDBSIRQ infra here so we don't have both polling and IRQ options
> > happening.
> >
> > That idea would require us to add new API (a return value for 'cleaned'),
> > and also a new flag for the clean ioctl. We also need the VMM to
> > implement that, but then we get a proper cpu usage of cleaning time.
> >
> > I wanted to start with a backwards compatible version, and do the above
> > idea once I put my hands in hardware that implements HACDBS, so I can
> > properly measure how much performance we get on above strategy.
> >
> > What do you think?
>
> Yeah, I'd want to see some extremely compelling performance numbers for
> this approach before considering it, alongside the necessary VMM patches
> to actually activate it.
>
> Seems likely to me that the VMM will want the background thread back
> ASAP that calls the clean ioctl so you'll need to work out how to cope
> with idle vCPUs in that case.
Fair point, HACDBS should be disabled if the vcpu gets scheduled-out, so we
would need to be sure the vcpus stay scheduled, or the cleaning may take
too long.
>
> Even still, with this hypothetical approach I'd expect KVM to inspect
> the HACDBS state on every exit. The IRQ is just a convenient kick back
> out to the main KVM_RUN loop.
Got it. Will use the HACDBSCONS register instead to get that info on
stopping.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH] memory: atmel-ebi: unwind SMC clock on probe failures
From: Krzysztof Kozlowski @ 2026-06-30 17:26 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260616151757.32322-1-pengpeng@iscas.ac.cn>
On 16/06/2026 17:17, Pengpeng Hou wrote:
> reg_cells += val;
> @@ -603,11 +605,23 @@ static int atmel_ebi_probe(struct platform_device *pdev)
>
> ret = atmel_ebi_dev_disable(ebi, child);
> if (ret)
> - return ret;
> + goto err_disable_smc_clk;
> }
> }
>
> - return of_platform_populate(np, NULL, NULL, dev);
> + ret = of_platform_populate(np, NULL, NULL, dev);
> + if (ret) {
> + of_platform_depopulate(dev);
Why do we need to depopulate when populate returned with an error?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] arm64: ptrace: use live x0 for seccomp and audit after ptrace
From: Catalin Marinas @ 2026-06-30 17:29 UTC (permalink / raw)
To: Will Deacon
Cc: Yiqi Sun, linux-arm-kernel, linux-kernel, rmk+kernel, ruanjinjie,
kees, mark.rutland
In-Reply-To: <akJuljttiQoki3sq@willie-the-truck>
Hi Will,
On Mon, Jun 29, 2026 at 02:09:42PM +0100, Will Deacon wrote:
> On Thu, Jun 25, 2026 at 06:45:02PM +0800, Yiqi Sun wrote:
> > On arm64, seccomp obtains syscall arguments via
> > syscall_get_arguments(), where arg0 is currently read from
> > regs->orig_x0. audit_syscall_entry() in syscall_trace_enter() also
> > takes arg0 from regs->orig_x0. However, the syscall wrapper consumes
> > live arguments from regs->regs[0..5].
> >
> > A ptracer can modify x0 on syscall-enter stop before seccomp and audit
> > run, but cannot update orig_x0 through the native syscall-stop
> > interface. This can leave seccomp and audit checking stale arg0 while
> > the syscall executes with updated live x0.
> >
> > Make both paths read arg0 from regs->regs[0], matching the actual
> > dispatch arguments and keeping seccomp and audit aligned after ptrace
> > updates.
> >
> > Fixes: f27bb139c387 ("arm64: Miscellaneous library functions")
> > Signed-off-by: Yiqi Sun <sunyiqixm@gmail.com>
> > ---
> > Changes in v2:
> > - Also switch the arm64 audit entry path to use live x0
> > - Clarify the orig_x0 synchronization comment in syscall_set_arguments()
> > ---
> > arch/arm64/include/asm/syscall.h | 7 +++----
> > arch/arm64/kernel/ptrace.c | 2 +-
> > 2 files changed, 4 insertions(+), 5 deletions(-)
>
> Sashiko has pointed out some issues with this patch that look legitimate
> to me:
>
> https://sashiko.dev/#/patchset/2f435bab0d61d0bf8fbaa54203525aae8e8f5371.1782384161.git.sunyiqixm@gmail.com
>
> Specifically, we don't appear to handle NO_SYSCALL properly and the
> syscall-exit stop is now going to see the return code instead of the
> syscall number.
Yes, good points from Sashiko.
> Looking at this more broadly, it looks like orig_x0 is used for three
> different cases:
At least the reported problem is real, the seccomp/audit code needs to
see the values the tracer modified and, IIUC, that's the behaviour x86
implements (it doesn't even clobber the arguments with the return
value). Unlike arm64, powerpc, arm32 expose orig_* to the ptrace
interface. We can't extend the user_pt_regs structure but we could
expose a new structure via ptrace.
> 1. syscall restarting:
> We restore from orig_x0, which should hold the
> original value passed by userspace.
Yes, we definitely need the orig_x0 since regs[0] was clobbered by the
return value.
> 2. syscall_get_arguments():
> This must work correctly vs syscall_set_arguments()
> (returning the latest set x0) but also
> syscall_get_return_value() (so we need to
> distinguish the return value and the argument
> somehow).
syscall_set_arguments() also updates orig_x0. W.r.t.
syscall_set_return_value(), it sets regs[0] which also matches what
syscall_get_return_value() reads. But yes, mismatch with the above.
> 3. syscall_rollback():
> Seccomp wants to restore the original values
> passed by userspace.
The "original values" comment is slightly misleading and just restoring
orig_x0 won't help with the other args anyway. x86 doesn't roll back any
arguments, it just uses the tracer's new values if they've been set via
syscall_trace_enter(). We do the same if the arguments are set via
syscall_set_arguments() since it updates orig_x0 but not if the tracer
did a gpr_set(). I don't think we can safely update orig_x0 via
gpr_set() since it has no idea whether it's in a syscall or not, may
mess up syscall restarting. Interestingly, riscv's SC_RISCV_REGS_TO_ARGS
uses orig_a0, a0 is always the return value even for gpr_get/set(). If
they want to change the syscall arguments, it's only possible via
PTRACE_SET_SYSCALL_INFO.
> So (1) and (3) look to require the same behaviour, but (2) wants
> something different because it needs to reflect changes made via
> syscall_set_arguments().
>
> The bodge we have for (2) today is that syscall_set_arguments() updates
> orig_x0, but I think that breaks (1) and (2) which is the underlying
> problem you're facing here.
I think the reason (1) needs orig_x0 is because regs[0] was clobbered by
the return value. For (3), orig_x0 and regs[0] are mostly in sync on
this path other than the NO_SYSCALL case where el0_svc_common() sets
regs[0] to -ENOSYS early, before we even reach a tracer.
> I haven't yet figured out the right way to fix this, but I'd be interested
> to hear from others. I think the starting point would be removing orig_x0
> from syscall_{get,set}_arguments() altogether so that it accurately
> represents the initial value passed by userspace.
I thought this might be a cleaner way forward but it's pretty messed up.
Depending on when syscall_get_arguments() is called, it needs different
things: we have seccomp before syscall and regs[0] would do but also
collect_syscall() at the end of a syscall and regs[0] has been clobbered
with the return value.
I also looked at replacing orig_x0 (or its meaning) with a ret_x0 and
only update it on the ERET to user but it breaks the ABI since a tracer
may expect to see the syscall return value in regs[0] on the exit path.
I think we need to keep orig_x0 as our original arg0 throughout the
kernel and just fix the tracer path to sync it on the syscall entry. It
doesn't unclutter the code but it shouldn't break the ABI either (unless
someone relied on the ptrace change x0 and not being noticed by
seccomp). Something like below:
----------------8<-----------------------------
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 4d08598e2891..cd21b301e154 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -2417,6 +2417,18 @@ int syscall_trace_enter(struct pt_regs *regs)
ret = report_syscall_entry(regs);
if (ret || (flags & _TIF_SYSCALL_EMU))
return NO_SYSCALL;
+ /*
+ * Keep orig_x0 authoritative so that seccomp (via
+ * syscall_get_arguments()), audit and the restart path all
+ * see the same first argument the syscall is dispatched with,
+ * even if it has been updated by a tracer. Skip this for
+ * NO_SYSCALL (set either by the user or the tracer) as
+ * regs[0] holds the return value (see the comment in
+ * el0_svc_common()). For compat, orig_r0 is provided directly
+ * through GPR index 17.
+ */
+ if (!is_compat_task() && regs->syscallno != NO_SYSCALL)
+ regs->orig_x0 = regs->regs[0];
}
/* Do the secure computing after ptrace; failures should be fast. */
----------------8<-----------------------------
If we want to change the ABI, we could do like riscv and only set the
arguments via PTRACE_SET_SYSCALL_INFO while the GPR ptrace accesses
whatever is in regs[0] - either the original arg or the return value. I
think they changed this inadvertently in 2023 when they moved to the
generic syscall.
We could also introduce NT_ARM_ORIG_X0 but on its own it feels a bit
weird for a tracer to know when the kernel may use orig_x0 or regs[0].
So quick hack above if it works, otherwise we need to look into change
the ABI and hoping no-one notices ;).
--
Catalin
^ permalink raw reply related
* Re: [PATCH] memory: stm32_omm: initialize ret in stm32_omm_set_amcr
From: Krzysztof Kozlowski @ 2026-06-30 17:29 UTC (permalink / raw)
To: Patrice Chotard, Maxime Coquelin, Alexandre Torgue, linux-kernel,
linux-stm32, linux-arm-kernel, Ruoyu Wang
In-Reply-To: <20260617182202.961843-1-ruoyuw560@gmail.com>
On Thu, 18 Jun 2026 02:22:02 +0800, Ruoyu Wang wrote:
> stm32_omm_set_amcr() returns ret after checking whether the AMCR value
> matches the device tree description. On the normal matching path ret is
> not otherwise assigned, so initialize it to 0 before the checks.
Applied, thanks!
[1/1] memory: stm32_omm: initialize ret in stm32_omm_set_amcr
https://git.kernel.org/krzk/linux-mem-ctrl/c/1527acf2295cf2d6e11e3e9b121d63709667e6e7
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: arm: ti: Add bindings for PHYTEC AM67x based hardware
From: Nathan Morrisson @ 2026-06-30 17:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: afd, sashiko-reviews, linux-arm-kernel, devicetree, linux-kernel,
upstream, w.egorov
Add device tree bindings for the AM67x based phyCORE-AM67x SoM and
phyBOARD-Rigel.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
No changes in v4
Documentation/devicetree/bindings/arm/ti/k3.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 69b5441cbf1a..ae47190d1f82 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -222,6 +222,13 @@ properties:
- ti,j722s-evm
- const: ti,j722s
+ - description: K3 AM67 SoC PHYTEC phyBOARD-Rigel
+ items:
+ - enum:
+ - phytec,am6754-phyboard-rigel
+ - const: phytec,am67-phycore-som
+ - const: ti,j722s
+
- description: K3 J742S2 SoC
items:
- enum:
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/2] arm64: dts: ti: Add support for the phyCORE-AM67x
From: Nathan Morrisson @ 2026-06-30 17:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: afd, sashiko-reviews, linux-arm-kernel, devicetree, linux-kernel,
upstream, w.egorov
In-Reply-To: <20260630173131.3000303-1-nmorrisson@phytec.com>
Add support for the PHYTEC phyCORE-AM67x SoM [1] and the
corresponding phyBOARD-Rigel carrier board [2]. The phyCORE-AM67x SoM
uses the TI AM67x SoC and can come with different sizes and models of
DDR, eMMC, and SPI NOR Flash.
Supported features:
* Audio playback and recording
* CAN
* Debug UART
* eMMC
* Ethernet
* GPIO buttons
* Heartbeat LED
* I2C Current sensor
* I2C EEPROM
* I2C Light sensor
* I2C RTC
* Micro SD card
* SPI NOR flash
* USB
[1] https://www.phytec.com/product/phycore-am67x/
[2] https://www.phytec.com/product/phyboard-am67x-development-kit/
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
---
Changes in v4:
* Swap the order of SPL, SPKR L and SPR, SPKR R in for
the audio card to use the proper sink, source ordering.
arch/arm64/boot/dts/ti/Makefile | 1 +
.../boot/dts/ti/k3-am67-phycore-som.dtsi | 324 +++++++++++++
.../boot/dts/ti/k3-am6754-phyboard-rigel.dts | 431 ++++++++++++++++++
3 files changed, 756 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 371f9a043fe5..623ee2369132 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
# Boards with J722s SoC
+dtb-$(CONFIG_ARCH_K3) += k3-am6754-phyboard-rigel.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
diff --git a/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
new file mode 100644
index 000000000000..bc74c4eef193
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2026 PHYTEC America LLC
+ * Author: Nathan Morrisson <nmorrisson@phytec.com>
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "phytec,am67-phycore-som", "ti,j722s";
+ model = "PHYTEC phyCORE-AM67";
+
+ aliases {
+ ethernet0 = &cpsw_port1;
+ gpio0 = &main_gpio0;
+ mmc0 = &sdhci0;
+ rtc0 = &i2c_som_rtc;
+ rtc1 = &wkup_rtc0;
+ spi0 = &ospi0;
+ };
+
+ memory@80000000 {
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ device_type = "memory";
+ bootph-all;
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_tfa_ddr: tfa@9e780000 {
+ reg = <0x00 0x9e780000 0x00 0x80000>;
+ no-map;
+ };
+
+ secure_ddr: optee@9e800000 {
+ reg = <0x00 0x9e800000 0x00 0x01800000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_dma_memory_region: memory@a0000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0000000 0x00 0x100000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_memory_region: memory@a0100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0100000 0x00 0xf00000>;
+ no-map;
+ };
+ };
+
+ vcc_5v0_som: regulator-vcc-5v0-som {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V0_SOM";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_pins_default>;
+
+ led-0 {
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&main_gpio0 13 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ function = LED_FUNCTION_HEARTBEAT;
+ };
+ };
+};
+
+&main_pmx0 {
+ leds_pins_default: leds-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x034, PIN_OUTPUT, 7) /* (K22) OSPI0_CSN2.GPIO0_13 */
+ >;
+ };
+
+ mdio_pins_default: mdio-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
+ J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
+ >;
+ bootph-all;
+ };
+
+ ospi0_pins_default: ospi0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x000, PIN_OUTPUT, 0) /* (L24) OSPI0_CLK */
+ J722S_IOPAD(0x02c, PIN_OUTPUT, 0) /* (K26) OSPI0_CSn0 */
+ J722S_IOPAD(0x00c, PIN_INPUT, 0) /* (K27) OSPI0_D0 */
+ J722S_IOPAD(0x010, PIN_INPUT, 0) /* (L27) OSPI0_D1 */
+ J722S_IOPAD(0x014, PIN_INPUT, 0) /* (L26) OSPI0_D2 */
+ J722S_IOPAD(0x018, PIN_INPUT, 0) /* (L25) OSPI0_D3 */
+ J722S_IOPAD(0x01c, PIN_INPUT, 0) /* (L21) OSPI0_D4 */
+ J722S_IOPAD(0x020, PIN_INPUT, 0) /* (M26) OSPI0_D5 */
+ J722S_IOPAD(0x024, PIN_INPUT, 0) /* (N27) OSPI0_D6 */
+ J722S_IOPAD(0x028, PIN_INPUT, 0) /* (M27) OSPI0_D7 */
+ J722S_IOPAD(0x008, PIN_INPUT, 0) /* (L22) OSPI0_DQS */
+ J722S_IOPAD(0x038, PIN_INPUT, 7) /* (J22) OSPI0_CSn3.GPIO0_14 */
+ >;
+ bootph-all;
+ };
+
+ pmic_irq_pins_default: pmic-irq-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x030, PIN_INPUT, 7) /* (K23) OSPI0_CSN1.GPIO0_12 */
+ >;
+ };
+
+ rgmii1_pins_default: rgmii1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
+ J722S_IOPAD(0x0150, PIN_INPUT, 0) /* (AD27) RGMII1_RD1 */
+ J722S_IOPAD(0x0154, PIN_INPUT, 0) /* (AE24) RGMII1_RD2 */
+ J722S_IOPAD(0x0158, PIN_INPUT, 0) /* (AE26) RGMII1_RD3 */
+ J722S_IOPAD(0x0148, PIN_INPUT, 0) /* (AE27) RGMII1_RXC */
+ J722S_IOPAD(0x0144, PIN_INPUT, 0) /* (AD23) RGMII1_RX_CTL */
+ J722S_IOPAD(0x0134, PIN_OUTPUT, 0) /* (AF27) RGMII1_TD0 */
+ J722S_IOPAD(0x0138, PIN_OUTPUT, 0) /* (AE23) RGMII1_TD1 */
+ J722S_IOPAD(0x013c, PIN_OUTPUT, 0) /* (AG25) RGMII1_TD2 */
+ J722S_IOPAD(0x0140, PIN_OUTPUT, 0) /* (AF24) RGMII1_TD3 */
+ J722S_IOPAD(0x0130, PIN_OUTPUT, 0) /* (AG26) RGMII1_TXC */
+ J722S_IOPAD(0x012c, PIN_OUTPUT, 0) /* (AF25) RGMII1_TX_CTL */
+ >;
+ bootph-all;
+ };
+};
+
+&mcu_pmx0 {
+ wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0) /* (B9) WKUP_I2C0_SCL */
+ J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (D11) WKUP_I2C0_SDA */
+ >;
+ bootph-all;
+ };
+};
+
+&cpsw3g {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&cpsw3g_mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins_default>;
+ status = "okay";
+
+ cpsw3g_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,min-output-impedance;
+ };
+};
+
+&cpsw_port1 {
+ phy-mode = "rgmii-id";
+ phy-handle = <&cpsw3g_phy1>;
+ status = "okay";
+};
+
+&ospi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ospi0_pins_default>;
+ bootph-all;
+ status = "okay";
+
+ serial_flash: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <25000000>;
+ vcc-supply = <&vdd_1v8>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <0>;
+ };
+};
+
+&sdhci0 {
+ non-removable;
+ bootph-all;
+ ti,driver-strength-ohm = <50>;
+ status = "okay";
+};
+
+&wkup_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ clock-frequency = <400000>;
+ bootph-all;
+ status = "okay";
+
+ pmic@30 {
+ compatible = "ti,tps65219";
+ reg = <0x30>;
+ buck1-supply = <&vcc_5v0_som>;
+ buck2-supply = <&vcc_5v0_som>;
+ buck3-supply = <&vcc_5v0_som>;
+ ldo1-supply = <&vdd_3v3>;
+ ldo2-supply = <&vdd_1v8>;
+ ldo3-supply = <&vdd_3v3>;
+ ldo4-supply = <&vdd_3v3>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ system-power-controller;
+ ti,power-button;
+
+ regulators {
+ vdd_3v3: buck1 {
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v8: buck2 {
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_lpddr4: buck3 {
+ regulator-name = "VDD_LPDDR4";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vddshv_sdio: ldo1 {
+ regulator-name = "VDDSHV_SDIO";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allow-bypass;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v2: ldo2 {
+ regulator-name = "VDD_1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdda_1v8_phy: ldo3 {
+ regulator-name = "VDDA_1V8_PHY";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v8_pll: ldo4 {
+ regulator-name = "VDD_1V8_PLL";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+
+ vdd_core: regulator-vdd-core@44 {
+ compatible = "ti,tps62873";
+ reg = <0x44>;
+ bootph-pre-ram;
+ regulator-name = "VDD_CORE";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ som_eeprom_opt: eeprom@51 {
+ compatible = "atmel,24c32";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+
+ i2c_som_rtc: rtc@52 {
+ compatible = "microcrystal,rv3028";
+ reg = <0x52>;
+ };
+};
+
+#include "k3-j722s-ti-ipc-firmware.dtsi"
diff --git a/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
new file mode 100644
index 000000000000..5fd4a8ceca16
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2026 PHYTEC America LLC
+ * Author: Nathan Morrisson <nmorrisson@phytec.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "k3-serdes.h"
+#include "k3-j722s.dtsi"
+#include "k3-am67-phycore-som.dtsi"
+
+/ {
+ compatible = "phytec,am6754-phyboard-rigel",
+ "phytec,am67-phycore-som", "ti,j722s";
+ model = "PHYTEC phyBOARD-Rigel AM67";
+
+ aliases {
+ gpio1 = &main_gpio1;
+ mmc1 = &sdhci1;
+ serial2 = &main_uart0;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ };
+
+ can_tc0: can-phy0 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <8000000>;
+ standby-gpios = <&gpio_exp1 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb0_connector: connector {
+ compatible = "gpio-usb-b-connector", "usb-b-connector";
+ label = "USB-C";
+ data-role = "dual";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_usbc_power_pins_default>;
+
+ id-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
+
+ port {
+ usb0_con: endpoint {
+ remote-endpoint = <&usb0_ep>;
+ };
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys_pins_default>;
+
+ key-home {
+ label = "home";
+ linux,code = <KEY_HOME>;
+ gpios = <&main_gpio1 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ key-menu {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ gpios = <&gpio_exp1 4 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ vcc_1v8: regulator-vcc-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_aud: regulator-vcc-3v3-aud {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_AUD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_mmc: regulator-vcc-3v3-mmc {
+ /* TPS22963C OUTPUT */
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_MMC";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_sw: regulator-vcc-3v3-sw {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_SW";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_speaker: regulator-vcc-speaker {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_SPEAKER";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Stereo Jack",
+ "Speaker", "L SPKR",
+ "Speaker", "R SPKR";
+ simple-audio-card,routing =
+ "MIC1RP", "Mic Jack",
+ "Mic Jack", "MICBIAS",
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "MIC1LM", "Stereo Jack",
+ "MIC1LP", "Stereo Jack",
+ "L SPKR", "SPL",
+ "R SPKR", "SPR";
+ simple-audio-card,name = "phyBOARD-Rigel";
+ simple-audio-card,format = "dsp_b";
+ simple-audio-card,bitclock-master = <&sound_master>;
+ simple-audio-card,frame-master = <&sound_master>;
+ simple-audio-card,bitclock-inversion;
+
+ simple-audio-card,cpu {
+ sound-dai = <&mcasp0>;
+ };
+
+ sound_master: simple-audio-card,codec {
+ sound-dai = <&audio_codec>;
+ clocks = <&audio_refclk1>;
+ };
+ };
+};
+
+&main_pmx0 {
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (N24) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+
+ gpio_exp0_int_pins_default: gpio-exp0-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0054, PIN_INPUT, 7) /* (T21) GPMC0_AD6.GPIO0_21 */
+ >;
+ };
+
+ gpio_exp1_int_pins_default: gpio-exp1-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0244, PIN_INPUT, 7) /* (A24) MMC1_SDWP.GPIO1_49 */
+ >;
+ };
+
+ gpio_exp2_int_pins_default: gpio-exp2-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0050, PIN_INPUT, 7) /* (T24) GPMC0_AD5.GPIO0_20 */
+ >;
+ };
+
+ gpio_keys_pins_default: gpio-keys-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01d4, PIN_INPUT, 7) /* (B21) UART0_RTSn.GPIO1_23 */
+ >;
+ };
+
+ main_i2c0_pins_default: main-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
+ J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_i2c1_pins_default: main-i2c1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e8, PIN_INPUT_PULLUP, 0) /* (C24) I2C1_SCL */
+ J722S_IOPAD(0x01ec, PIN_INPUT_PULLUP, 0) /* (A22) I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_mcan0_pins_default: main-mcan0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1dc, PIN_INPUT, 0) /* (C22) MCAN0_RX */
+ J722S_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (D22) MCAN0_TX */
+ >;
+ };
+
+ main_mcasp0_pins_default: main-mcasp0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1a8, PIN_INPUT, 0) /* (C26) MCASP0_AFSX */
+ J722S_IOPAD(0x1a4, PIN_INPUT, 0) /* (D25) MCASP0_ACLKX */
+ J722S_IOPAD(0x198, PIN_OUTPUT, 0) /* (A26) MCASP0_AXR2 */
+ J722S_IOPAD(0x194, PIN_INPUT, 0) /* (A25) MCASP0_AXR3 */
+ >;
+ };
+
+ main_mmc1_pins_default: main-mmc1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
+ J722S_IOPAD(0x0234, PIN_INPUT, 0) /* (H24) MMC1_CLK */
+ J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
+ J722S_IOPAD(0x022c, PIN_INPUT, 0) /* (H20) MMC1_DAT1 */
+ J722S_IOPAD(0x0228, PIN_INPUT, 0) /* (J23) MMC1_DAT2 */
+ J722S_IOPAD(0x0224, PIN_INPUT, 0) /* (H25) MMC1_DAT3 */
+ J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
+ >;
+ bootph-all;
+ };
+
+ main_uart0_pins_default: main-uart0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (F19) UART0_RXD */
+ J722S_IOPAD(0x01cc, PIN_OUTPUT, 0) /* (F20) UART0_TXD */
+ >;
+ bootph-all;
+ };
+
+ main_usbc_power_pins_default: main-usbc-power-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1b4, PIN_INPUT, 7) /* (B20) SPI0_CS0.GPIO1_15 */
+ >;
+ };
+};
+
+&audio_refclk1 {
+ assigned-clock-rates = <25000000>;
+};
+
+&main_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c0_pins_default>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ veml6030: light-sensor@10 {
+ compatible = "vishay,veml6030";
+ reg = <0x10>;
+ vdd-supply = <&vcc_3v3_sw>;
+ };
+};
+
+&main_i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c1_pins_default>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ audio_codec: audio-codec@18 {
+ compatible = "ti,tlv320aic3110";
+ reg = <0x18>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+ #sound-dai-cells = <0>;
+ ai31xx-micbias-vg = <2>;
+ reset-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
+
+ HPVDD-supply = <&vcc_3v3_aud>;
+ SPRVDD-supply = <&vcc_speaker>;
+ SPLVDD-supply = <&vcc_speaker>;
+ AVDD-supply = <&vcc_3v3_aud>;
+ IOVDD-supply = <&vcc_3v3_aud>;
+ DVDD-supply = <&vcc_1v8>;
+ };
+
+ gpio_exp0: gpio@20 {
+ compatible = "nxp,pcf8574";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp0_int_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <21 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "CSI3_STROBE", "CSI3_TRIGGER",
+ "CSI3_SHUTTER", "CSI3_OE",
+ "CSI2_STROBE", "CSI2_TRIGGER",
+ "CSI2_SHUTTER", "CSI2_OE";
+ };
+
+ gpio_exp1: gpio@21 {
+ compatible = "nxp,pcf8574";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp1_int_pins_default>;
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <49 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "GPIO0_HDMI_RST", "GPIO1_CAN_nEN",
+ "GPIO2_LED", "GPIO3_MCU_CAN0_nEN",
+ "GPIO4_BUT2", "GPIO5_MCU_CAN1_nEN",
+ "GPIO6_AUDIO_GPIO", "GPIO7_AUDIO_USER_RESET";
+ };
+
+ gpio_exp2: gpio@23 {
+ compatible = "nxp,pcf8574";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp2_int_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "CSI1_STROBE", "CSI1_TRIGGER",
+ "CSI1_SHUTTER", "CSI1_OE",
+ "CSI0_STROBE", "CSI0_TRIGGER",
+ "CSI0_SHUTTER", "CSI0_OE";
+ };
+
+ current-sensor@40 {
+ compatible = "ti,ina233";
+ reg = <0x40>;
+ shunt-resistor = <18000>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c02";
+ reg = <0x51>;
+ pagesize = <16>;
+ };
+};
+
+&main_mcan0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan0_pins_default>;
+ phys = <&can_tc0>;
+ status = "okay";
+};
+
+&main_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart0_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&mcasp0 {
+ #sound-dai-cells = <0>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcasp0_pins_default>;
+ tdm-slots = <2>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ status = "okay";
+};
+
+&sdhci1 {
+ /* SD/MMC */
+ vmmc-supply = <&vcc_3v3_mmc>;
+ vqmmc-supply = <&vddshv_sdio>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc1_pins_default>;
+ disable-wp;
+ no-1-8-v;
+ bootph-all;
+ status = "okay";
+};
+
+&serdes_ln_ctrl {
+ idle-states = <J722S_SERDES0_LANE0_USB>,
+ <J722S_SERDES1_LANE0_PCIE0_LANE0>;
+};
+
+&serdes0 {
+ status = "okay";
+
+ serdes0_usb_link: phy@0 {
+ reg = <0>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_USB3>;
+ resets = <&serdes_wiz0 1>;
+ };
+};
+
+&serdes_wiz0 {
+ status = "okay";
+};
+
+&usbss0 {
+ ti,vbus-divider;
+ status = "okay";
+};
+
+&usb0 {
+ dr_mode = "otg";
+ usb-role-switch;
+ maximum-speed = "high-speed";
+
+ port {
+ usb0_ep: endpoint {
+ remote-endpoint = <&usb0_con>;
+ };
+ };
+};
+
+&usbss1 {
+ ti,vbus-divider;
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "host";
+ phys = <&serdes0_usb_link>;
+ phy-names = "cdns3,usb3-phy";
+ maximum-speed = "super-speed";
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH V4 1/8] PCI: imx6: Move pci_pwrctrl_create_devices() to imx_pcie_probe()
From: Bjorn Helgaas @ 2026-06-30 17:37 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260630103139.3823329-2-sherry.sun@oss.nxp.com>
On Tue, Jun 30, 2026 at 06:31:32PM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Move pci_pwrctrl_create_devices() to imx_pcie_probe() so that it is only
> called once during probe, similar to other regulator_get calls.
Can we say something in the subject about the purpose of this? "Move
X to Y" summarizes the code change but not the motivation.
I guess previously pci_pwrctrl_create_devices() would be called during
probe and then again during resume, and we don't want it called during
resume?
^ permalink raw reply
* Re: [for-next][PATCH 04/15] tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()
From: Geert Uytterhoeven @ 2026-06-30 17:39 UTC (permalink / raw)
To: Steven Rostedt, David Carlier
Cc: linux-kernel, Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers,
Andrew Morton, Vineeth Pillai (Google), Peter Zijlstra, Linux ARM,
Linux-Renesas
In-Reply-To: <20260522143525.551205135@kernel.org>
Hi Steven, David,
On Fri, 22 May 2026 at 16:35, Steven Rostedt <rostedt@kernel.org> wrote:
> From: David Carlier <devnexen@gmail.com>
>
> The trace_##name##_enabled() static call branch is used when work needs to
> be done for a tracepoint. It allows that work to be skipped when the
> tracepoint is not active and still uses the static_branch() of the
> tracepoint to keep performance.
>
> Tracepoints themselves require being called in "RCU watching" locations
> otherwise races can occur that corrupts things. In order to make sure
> lockdep triggers at tracepoint locations, the lockdep checks are added to
> the tracepoint calling location and trigger even if the tracepoint is not
> enabled. This is done because a poorly placed tracepoint may never be
> detected if it is never enabled when lockdep is enabled.
>
> As trace_##name##_enabled() also prevents the lockdep checks when the
> tracepoint is disabled add lockdep checks to that as well so that if one
> is placed in a location that RCU is not watching, it will trigger a
> lockdep splat even when the tracepoint is not enabled.
>
> Cc: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Link: https://patch.msgid.link/20260430144159.10985-1-devnexen@gmail.com
> Signed-off-by: David Carlier <devnexen@gmail.com>
> [ Updated the change log ]
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Thanks for your patch, which is now commit 9764e731ef6abacd
("tracepoint: Add lockdep rcu_is_watching() check to
trace_##name##_enabled()") in v7.2-rc1.
This is causing multiple warnings during system suspend on Renesas
SH-Mobile AG5, R-Car H1. and R-Car M2-W:
PM: suspend entry (deep)
-Filesystems sync: 0.018 seconds
+Filesystems sync: 0.027 seconds
Freezing user space processes
Freezing user space processes completed (elapsed 0.001 seconds)
OOM killer disabled.
Freezing remaining freezable tasks
Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
-PM: suspend devices took 0.110 seconds
+------------[ cut here ]------------
+WARNING: include/trace/events/preemptirq.h:36 at
trace_irq_disable_enabled+0x3c/0x64, CPU#0: swapper/0/0
+------------[ cut here ]------------
+RCU not watching for tracepoint
+Modules linked in:
+WARNING: include/trace/events/preemptirq.h:40 at
trace_irq_enable_enabled+0x3c/0x64, CPU#1: swapper/1/0
+
+RCU not watching for tracepoint
+CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
7.1.0-rc4-koelsch-00006-g9764e731ef6a #2337 VOLUNTARY
+Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
+Call trace:
+ unwind_backtrace from show_stack+0x10/0x14
+ show_stack from dump_stack_lvl+0x7c/0xb0
+ dump_stack_lvl from __warn+0x98/0x27c
+ __warn from warn_slowpath_fmt+0xc0/0x124
+ warn_slowpath_fmt from trace_irq_disable_enabled+0x3c/0x64
+ trace_irq_disable_enabled from trace_hardirqs_off+0x6c/0xb0
+ trace_hardirqs_off from __irq_svc+0x48/0xac
+Exception stack(0xc1401f20 to 0xc1401f68)
+1f20: c027a764 effb0e88 00000000 00000001 c140b080 c027a764
c140801c c140b080
+1f40: c1407fe0 00000000 c140801c 00000000 fffffff8 c1401f70
c0b35980 c0b359d8
+1f60: 20000113 ffffffff
+ __irq_svc from cpu_idle_poll+0x114/0x130
+ cpu_idle_poll from do_idle+0xb8/0x268
+ do_idle from cpu_startup_entry+0x28/0x2c
+ cpu_startup_entry from rest_init+0x150/0x178
+ rest_init from start_kernel+0x634/0x6d8
+irq event stamp: 19112
+Modules linked in:
+hardirqs last enabled at (19111): [<c0b35adc>]
default_idle_call+0xe8/0x104
+
+hardirqs last disabled at (19112): [<c0200b88>] __irq_svc+0x48/0xac
+CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted
7.1.0-rc4-koelsch-00006-g9764e731ef6a #2337 VOLUNTARY
+Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
+Call trace:
+ unwind_backtrace from show_stack+0x10/0x14
+ show_stack from dump_stack_lvl+0x7c/0xb0
+ dump_stack_lvl from __warn+0x98/0x27c
+ __warn from warn_slowpath_fmt+0xc0/0x124
+ warn_slowpath_fmt from trace_irq_enable_enabled+0x3c/0x64
+ trace_irq_enable_enabled from trace_hardirqs_on+0x40/0xbc
+ trace_hardirqs_on from __irq_svc+0x94/0xac
+Exception stack(0xf0865f48 to 0xf0865f90)
+5f40: c027a764 effc2e88 00000000 00000001
c227cec0 c027a764
+5f60: c140801c c227cec0 c1407fe0 413fc0f2 c140801c 00000000
fffffff8 f0865f98
+5f80: c0b35980 c0b35988 20000013 ffffffff
+ __irq_svc from cpu_idle_poll+0xc4/0x130
+ cpu_idle_poll from do_idle+0xb8/0x268
+ do_idle from cpu_startup_entry+0x28/0x2c
+ cpu_startup_entry from secondary_start_kernel+0xdc/0xf0
+ secondary_start_kernel from 0x4020f094
+irq event stamp: 27461
+softirqs last enabled at (19008): [<c02341ec>] handle_softirqs+0x174/0x3e4
+hardirqs last enabled at (27461): [<c027a7d0>] do_idle+0x124/0x268
+softirqs last disabled at (18991): [<c0234a84>] __irq_exit_rcu+0xf0/0x194
+hardirqs last disabled at (27460): [<c027a734>] do_idle+0x88/0x268
+---[ end trace 0000000000000000 ]---
+softirqs last enabled at (27438): [<c02341ec>] handle_softirqs+0x174/0x3e4
+softirqs last disabled at (27425): [<c0234a84>] __irq_exit_rcu+0xf0/0x194
+---[ end trace 0000000000000000 ]---
+PM: suspend devices took 0.380 seconds
Disabling non-boot CPUs ...
Other Renesas ARM32 platforms I tried (R-Mobile A1, RZ/A1H, RZ/A2M)
are unafffected, perhaps because they are not SMP?
All Renesas ARM64 platforms I tried (R-Car Gen3/4) are also unaffected.
Reverting the commit fixes the issue.
Do you have a clue?
Thanks!
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -293,6 +293,10 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> static inline bool \
> trace_##name##_enabled(void) \
> { \
> + if (IS_ENABLED(CONFIG_LOCKDEP)) { \
> + WARN_ONCE(!rcu_is_watching(), \
> + "RCU not watching for tracepoint"); \
> + } \
> return static_branch_unlikely(&__tracepoint_##name.key);\
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Jason Gunthorpe @ 2026-06-30 17:42 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Alexey Kardashevskiy, Catalin Marinas, iommu, linux-arm-kernel,
linux-kernel, linux-coco, Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5ao6gtoncp.fsf@kernel.org>
On Mon, Jun 29, 2026 at 12:16:30PM +0530, Aneesh Kumar K.V wrote:
> >> Thinking about this more, I guess we should mark the swiotlb as
> >> cc_shared only with CC_ATTR_GUEST_MEM_ENCRYPT instead of
> >> CC_ATTR_MEM_ENCRYPT as we have below.
> >
> > The name cc_shared should be used for GUEST scenarios only.
> >
> > I guess there is some merit in keeping swiotlb using "decrypted" to
> > mean it usinig pgprot_decrypted and set_memory_decyped() which AMD
> > gives meaning to on both host and guest.
>
> Are you suggesting to change the struct io_tlb_mem::cc_shared back to
> struct io_tlb_mem::unencrypted?.
Yes
> > IDK what AMD should do on the host by default. I guess it should setup
> > a swiotlb pool of low dma addrs "unencrypted", but not "cc_shared"?
> >
>
> If by low DMA address you mean using an address with the C-bit
> cleared.
Yes
> The current code already does this and uses the swiotlb pool correctly
> on SME.
Well, through the force_dma_unencrypted() hack...
> The challenge arises when we want to force SWIOTLB
> bouncing even for devices that can handle encrypted DMA addresses (more
> on that below). For such a config force_dma_uencrypted(dev) will return
> false and swiotlb will be marked cc_shared/decrypted = true; This trip
> the new check we added.
Yes, because cc_shared (guest) and unencrypted (host) are very
different things and we've mixed them:
> if (unlikely(mem->cc_shared != force_dma_unencrypted(dev)))
I'm aruging force_dma_unencrypted should mean cc_shared and be
guest_only, but the SME hack breaks this.
> We can also do
>
> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
> /* swiotlb pool is incorrect for this device */
> if (unlikely(mem->cc_shared != force_dma_unencrypted(dev)))
> return (phys_addr_t)DMA_MAPPING_ERROR;
>
> /* Force attrs to match the kind of memory in the pool */
> if (mem->cc_shared)
> *attrs |= DMA_ATTR_CC_SHARED;
> else
> *attrs &= ~DMA_ATTR_CC_SHARED;
> } else {
> /*
> * Host memory encryption where device requires an
> * unencrypted dma_addr_t due to dma mask limit
> */
> if (force_dma_unencrypted(dev))
> *attrs |= DMA_ATTR_CC_SHARED;
> else
> *attrs &= ~DMA_ATTR_CC_SHARED;
> }
If we do this I would like to split the force_dma_.. functions into
guest and host, ie force_dma_cc_shared() and force_host_decrypted()
To make it clear there are two very different things here.
> Here I see value in having DMA_ATTR_UNENCRYPTED. The question is do we
> need to split this into two flags and introduce the resulting code
> duplication.
The external flag name should be DMA_ATTR_CC_SHARED and only used on
CC guest. Internally that turns into using set_memory_decrypted()
which works on guest and host for AMD. I don't know how to make the
host only case clearer and still keep the code efficient..
> > The dma api has to detect, after the driver sets the dma limit, that
> > none of system memory is usable when:
> > - The direct path is being used
> > - phys to dma for 0 is outside the dma limit
> >
> > Then it should assume the arch has setup a swiotlb pool for it to use
> > to fix the high memory problem.
> >
> > Similar hackery would be needed in the dma alloc path to know that
> > decrypted can be used to fix the high memory problem like for GUEST.
> >
> > I guess some 'dev_cannot_reach_memory(dev)' sort of test in a
> > few key places? Setup with a static branch to be a nop on everything
> > but AMD, compiled out on every other arch.
> >
>
> If we are not able to reach the memory because of the memory encryption
> bit, then isn't dev_cannot_reach_memory(dev) the same as
> force_dma_unencrypted(dev)? If so, that is how it is already done.
Sort of yes, but it is properly named to its purpose and not confused
with what should be a guest-only function.
> x86/dma: Disable forced SWIOTLB bouncing for SME IOMMU passthrough
Maybe as a crutch to get this series merged..
Jason
^ 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