* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Johan Hovold @ 2026-04-07 9:07 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Eric Dumazet, Leon Romanovsky,
Christoph Hellwig, Robin Murphy, maz, Alexander Lobakin,
Saravana Kannan, Mark Brown, alexander.stein, andrew, andrew,
andriy.shevchenko, astewart, bhelgaas, brgl, davem, devicetree,
driver-core, hkallweit1, jirislaby, joel, kees, kuba, lgirdwood,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pci,
linux-serial, linux-usb, linux, mani, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Doug Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
This flag is only set before registering a device with driver core so
there is no issue using the existing bitfield here (with the caveat that
PCI pwrctrl may have gotten that wrong). I haven't checked the other
flags, but I assume most of them work the same way.
But apart from the commit message being misleading, switching to using
atomic ops and accessors for consistency is fine.
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
These two uses are broken currently though and should be using
device_set_of_node_from_dev() so that an extra reference is taken to
balance the one dropped by the platform bus code.
I'll send two fixes to Mark, any merge conflict should be trivial to
fixup.
Reviewed-by: Johan Hovold <johan@kernel.org>
Johan
^ permalink raw reply
* Re: [PATCH v12 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: PK Lee @ 2026-04-07 9:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jason-Hsu, p.k.lee
In-Reply-To: <258747f4-9da5-44da-8eb9-24f8a8cbff3a@lunn.ch>
> > +&mac3 {
> > + status = "okay";
> > + phy-mode = "rmii";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_rmii4_default>;
> > + fixed-link {
> > + speed = <100>;
> > + full-duplex;
> > + };
>
> What is on the other end of this fixed link?
The other end of this fixed link is the CPU port of a Marvell 88E6393X
switch. We are using this switch in unmanaged mode rather than using
the DSA subsystem. Therefore, we use a fixed-link to force the mac3 to
100Mbps full-duplex RMII to match the CPU port configuration.
>
> > +};
> > +
> > +&mdio0 {
> > + status = "okay";
> > +};
>
> If there are no devices on the bus, why enable it?
We intentionally enable it so user-space tools can access the switch
registers. I have added a comment in v13 to clarify this.
>
> Andrew
P.K. Lee
^ permalink raw reply
* Re: [PATCH 2/5] arm64: dts: qcom: sm8550-hdk: update PCIe port label reference
From: Joe Sandom @ 2026-04-07 8:55 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <bzbxyduvwlk42yj6mchu2denfvhqemahdeuuwxgzpbz52kmhn5@roukkyhpdbwf>
On Sun, Apr 05, 2026 at 12:07:39AM +0300, Dmitry Baryshkov wrote:
> On Sat, Apr 04, 2026 at 10:50:55AM +0100, Joe Sandom via B4 Relay wrote:
> > From: Joe Sandom <jsandom@axon.com>
> >
> > Update the pcieport0 reference to pcie0_port0 to match the label
> > rename in sm8550.dtsi.
>
> This one (and the next one) should be squashed with the port label
> rename.
Thanks for the correction. Will address this in v2
>
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> > index ee13e6136a8259d28540e718851e094f74ead278..e821b731bdc496c872703723df02ae9b9b0233b5 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> > +++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> > @@ -1012,7 +1012,7 @@ &pcie0 {
> > status = "okay";
> > };
> >
> > -&pcieport0 {
> > +&pcie0_port0 {
> > wifi@0 {
> > compatible = "pci17cb,1107";
> > reg = <0x10000 0x0 0x0 0x0 0x0>;
> >
> > --
> > 2.34.1
> >
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: qcom: sm8550: add PCIe MHI register regions and port labels
From: Joe Sandom @ 2026-04-07 8:53 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <sdr64ldaoitb7rj6a7eupmqrsh47wgir6nkbsnbsv6bpftiqyf@youdquby6sog>
On Sun, Apr 05, 2026 at 12:07:14AM +0300, Dmitry Baryshkov wrote:
> On Sat, Apr 04, 2026 at 10:50:54AM +0100, Joe Sandom via B4 Relay wrote:
> > From: Joe Sandom <jsandom@axon.com>
> >
> > Add the MHI register regions to the pcie0 and pcie1 controller nodes
> > so that the MHI bus layer can access controller registers directly.
> >
> > Also add labels to the root port nodes (pcie0_port0, pcie1_port0) to
> > allow board DTS files to reference them for adding endpoint devices
> > to each pcie root port.
>
> Two separate changes, please.
ack. Will address this in v2
>
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/sm8550.dtsi | 14 ++++++++------
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index 912525e9bca6f5e1cbb8887ee0bf9e39650dc4ff..d4caf4d00832d7f1e8f65bf2bc873cddadc42168 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -1964,8 +1964,9 @@ pcie0: pcie@1c00000 {
> > <0 0x60000000 0 0xf1d>,
> > <0 0x60000f20 0 0xa8>,
> > <0 0x60001000 0 0x1000>,
> > - <0 0x60100000 0 0x100000>;
> > - reg-names = "parf", "dbi", "elbi", "atu", "config";
> > + <0 0x60100000 0 0x100000>,
> > + <0 0x01C03000 0 0x1000>;
>
> Lowercase the hex, align vertically.
ack. Will address this in v2
>
> > + reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
> > #address-cells = <3>;
> > #size-cells = <2>;
> > ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
> > @@ -2092,7 +2093,7 @@ opp-16000000-3 {
> > };
> > };
> >
> > - pcieport0: pcie@0 {
> > + pcie0_port0: pcie@0 {
> > device_type = "pci";
> > reg = <0x0 0x0 0x0 0x0 0x0>;
> > bus-range = <0x01 0xff>;
> > @@ -2138,8 +2139,9 @@ pcie1: pcie@1c08000 {
> > <0x0 0x40000000 0x0 0xf1d>,
> > <0x0 0x40000f20 0x0 0xa8>,
> > <0x0 0x40001000 0x0 0x1000>,
> > - <0x0 0x40100000 0x0 0x100000>;
> > - reg-names = "parf", "dbi", "elbi", "atu", "config";
> > + <0x0 0x40100000 0x0 0x100000>,
> > + <0x0 0x01C0B000 0x0 0x1000>;
> > + reg-names = "parf", "dbi", "elbi", "atu", "config", "mhi";
> > #address-cells = <3>;
> > #size-cells = <2>;
> > ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
> > @@ -2288,7 +2290,7 @@ opp-32000000-4 {
> > };
> > };
> >
> > - pcie@0 {
> > + pcie1_port0: pcie@0 {
> > device_type = "pci";
> > reg = <0x0 0x0 0x0 0x0 0x0>;
> > bus-range = <0x01 0xff>;
> >
> > --
> > 2.34.1
> >
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [RFC PATCH 06/15] libfdt: Don't assume that a FDT_BEGIN_NODE tag is available at offset 0
From: Herve Codina @ 2026-04-07 8:51 UTC (permalink / raw)
To: Luca Ceresoli
Cc: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <DHHWY06CRC21.XENO1ENNAV55@bootlin.com>
Hi Luca, David,
On Wed, 01 Apr 2026 17:11:42 +0200
"Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> > In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present
> > at the offset 0 of the structure block.
> >
> > This assumption is not correct. Indeed, a FDT_NOP can be present at the
> > offset 0 and this is a legit case.
> >
> > fdt_first_node() has been introduce recently to get the offset of the
> ^
> introduced
Will be fixed in the next iteration.
...
> > int fdt_next_node(const void *fdt, int offset, int *depth)
> > {
> > - int nextoffset = 0;
> > + int nextoffset = offset;
> > uint32_t tag;
> >
> > + if (offset <= 0) {
>
> What is the difference between 0 and a engative value?
I will add a comment in the code.
0 means that we want the next node from the first node.
The negative value is an invalid value. In that case we start from the
first node. This was the behavior of the code without my modification and
I kept the same behavior in that case.
>
> This is where the parameter value is not obvious to the newcomer and I'd
> love seeing it concisely documented.
David, is functions documentation expected ?
I can add to this documentation if you want it.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Thomas Richard @ 2026-04-07 8:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260405-smoky-spectacular-koel-dbfcda@quoll>
Hello Krzysztof,
On 4/5/26 10:06 AM, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 09:02:23PM +0200, Thomas Richard wrote:
>> Create schema for LAN75XX compatible USB Ethernet controllers. The smsc75xx
>> driver only supports LAN7500 and LAN7505 devices.
>>
>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>> ---
>> .../devicetree/bindings/net/microchip,lan75xx.yaml | 52 ++++++++++++++++++++++
>> 1 file changed, 52 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..b84022976044ffec2024cff9fc0aa5016723abed
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>
> Rather microchip,lan7500.yaml. Wildcards don't really scale when you
> have 75yy coming which does not fit into this binding.
>
>
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/microchip,lan75xx.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip LAN7500/LAN7505 USB Ethernet Controllers
>> +
>> +maintainers:
>> + - Thomas Richard <thomas.richard@bootlin.com>
>> +
>> +description:
>> + Device tree properties for LAN75XX compatible USB Ethernet controller.
>> +
>> +allOf:
>> + - $ref: ethernet-controller.yaml#
>> +
>> +properties:
>> + compatible:
>> + items:
>
> Drop items, that's enum directly.
>
>> + - enum:
>> + - usb424,7500
>> + - usb424,7505
>
> But you should notice that this is exactly the same as 95xx, so why it
> cannot go there? Because of the wildcard 95xx naming? That's not a
> reason.
Yes I noticed. I did not put them in 95xx because it is not the same
driver. Isn't that a valid reason?
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH net-next v2 9/9] net: dsa: lan9645x: add port statistics
From: Jens Emil Schulz Ostergaard @ 2026-04-07 8:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195639.2789284-1-kuba@kernel.org>
On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: dsa: lan9645x: add port statistics
>
> Add statistics support for the port counters. Chip registers are 32 bit,
> so this unit is responsible maintaining a 64bit software cache, and
> updating it frequently to handle overflows in hardware.
>
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > index 24a60f40f6b8..9a46c08dad59 100644
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> [ ... ]
> > @@ -262,6 +264,12 @@ static int lan9645x_setup(struct dsa_switch *ds)
> > if (!lan9645x->owq)
> > return -ENOMEM;
> >
> > + err = lan9645x_stats_init(lan9645x);
> > + if (err) {
> > + dev_err(dev, "Failed to init stats.\n");
> > + goto owq_destroy;
> > + }
> > +
> [ ... ]
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> > index 000000000000..3e82a859f173
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> [ ... ]
> > +static const struct lan9645x_ethtool_stat lan9645x_port_ethtool_stats[] = {
> > + { "rx_uc", SCNT_RX_UC },
> > + { "rx_cat_drop", SCNT_RX_CAT_DROP },
> [ ... ]
> > + { "tx_uc", SCNT_TX_UC },
> > + { "tx_drop", SCNT_TX_DROP },
> [ ... ]
> > +};
>
> Is it necessary to duplicate standard networking statistics in the driver
> private ethtool output?
>
> The networking subsystem guidelines state that stats possessing a standard UAPI
> representation, such as tx_dropped and rx_packets in struct rtnl_link_stats64,
> should not be duplicated in the ethtool -S output.
>
> Could these redundant strings be removed since the driver natively supports
> them via lan9645x_stats_get_stats64?
>
I do not think they are redundant. They are only available in an aggregated form
via rtnl_link_stats64, not directly. Information is lost if they are removed.
> [ ... ]
> > +static const struct lan9645x_view_stats lan9645x_view_stat_cfgs[] = {
> > + [LAN9645X_STAT_PORTS] = {
> > + .name = "ports",
> > + .type = LAN9645X_STAT_PORTS,
> > + .layout = lan9645x_port_stats_layout,
> > + .num_cnts = ARRAY_SIZE(lan9645x_port_stats_layout),
> > + .num_indexes = NUM_PHYS_PORTS,
> > + },
> > +};
> [ ... ]
> > +static u64 *lan9645x_stats_view_idx_update(struct lan9645x *lan9645x,
> > + enum lan9645x_view_stat_type vtype,
> > + int idx)
> > +{
> > + struct lan9645x_stats *s = lan9645x->stats;
> > +
> > + mutex_lock(&s->hw_lock);
> > + __lan9645x_stats_view_idx_update(lan9645x, vtype, idx);
> > + mutex_unlock(&s->hw_lock);
> > +
> > + return STAT_COUNTERS(lan9645x, vtype, idx);
> > +}
>
> Does this code overflow the allocated buffer when called for the CPU port?
>
> The stats buffer cnts is allocated using num_indexes, which is NUM_PHYS_PORTS
> (9). This covers ports 0 to 8. However, the CPU port is defined as index 9
> (CPU_PORT = 9).
>
> When the DSA core invokes stat callbacks like get_ethtool_stats or get_stats64
> for the CPU port, the idx argument is 9. While the helper
> __lan9645x_stats_view_idx_update skips the hardware read for out-of-bounds
> indices, lan9645x_stats_view_idx_update ignores that failure and returns the
> result of STAT_COUNTERS(lan9645x, vtype, idx).
>
> This computes a pointer past the end of the cnts array, which the callers then
> blindly dereference, potentially leaking kernel memory or causing a crash. Can
> bounds checking be added to the callers, or should the buffer be sized to
> include the CPU port?
>
No this is not called for the CPU port index 9.
> [ ... ]
> > +void lan9645x_stats_get_ethtool_stats(struct lan9645x *lan9645x, int port,
> > + u64 *data)
> > +{
> > + struct lan9645x_stats *stats = lan9645x->stats;
> > + u64 *c;
> > + int i;
> > +
> > + c = lan9645x_stats_view_idx_update(lan9645x, LAN9645X_STAT_PORTS, port);
> > +
> > + spin_lock(&stats->sw_lock);
> > + for (i = 0; i < ARRAY_SIZE(lan9645x_port_ethtool_stats); i++)
> > + *data++ = c[lan9645x_port_ethtool_stats[i].idx];
> > + spin_unlock(&stats->sw_lock);
> > +}
> [ ... ]
> > +/* Called in atomic context */
> > +void lan9645x_stats_get_stats64(struct lan9645x *lan9645x, int port,
> > + struct rtnl_link_stats64 *stats)
> > +{
> > + struct lan9645x_stats *s = lan9645x->stats;
> > + u64 *c;
> > +
> > + c = STAT_COUNTERS(lan9645x, LAN9645X_STAT_PORTS, port);
> > +
> > + spin_lock(&s->sw_lock);
>
> Can this code deadlock when a softirq interrupts a process holding the lock?
>
> The sw_lock spinlock protects the 64-bit software stats counters. In
> lan9645x_stats_get_stats64, which acts as the ndo_get_stats64 callback, this
> lock is acquired using a plain spin_lock. The code comment notes this function
> is called in atomic context (such as from NET_RX_SOFTIRQ via dev_get_stats).
>
> Concurrently, process context paths like lan9645x_stats_get_ethtool_stats and
> lan9645x_check_stats_work also acquire sw_lock using plain spin_lock. Because
> plain spin_lock does not disable softirqs, if a softirq preempts the execution
> on a CPU while process context holds sw_lock, the softirq will spin
> indefinitely waiting for the lock.
>
> Should the process-context acquisitions use spin_lock_bh instead?
>
As far as I can tell ndo_get_stats64 is not called from softirq. Ocelot also uses
a plain spin_lock here. Since no softirq path touches this lock, there is no
deadlock.
> [ ... ]
> > +int lan9645x_stats_init(struct lan9645x *lan9645x)
> > +{
> > + const struct lan9645x_view_stats *vs;
> > + struct lan9645x_stats *stats;
> > + int err, i;
> > +
> > + lan9645x->stats = devm_kzalloc(lan9645x->dev, sizeof(*stats),
> > + GFP_KERNEL);
>
> Will this memory be leaked when the DSA switch unbinds and rebinds?
>
> The lan9645x_stats_init function allocates lan9645x->stats, vstat->cnts, and
> vstat->buf using devm_kzalloc and devm_kcalloc. This function is called from
> lan9645x_setup, which is the DSA .setup callback.
>
> The DSA tree lifecycle is independent of the platform device lifecycle. If the
> master netdevice is unbound and bound again, the DSA switch's .teardown and
> .setup callbacks will be invoked multiple times. Because .teardown cannot free
> devres-managed memory, the memory tied to the platform device will be leaked
> on every setup cycle until the switch's platform device itself is destroyed.
>
> Could this use standard kzalloc allocations paired with kfree in teardown?
Similar comment as the devm_* comment for the .setup function. I do not think
this is a problem, since there can not be multiple setup/teardown cycles
during the device lifetime. dsa_tree_teardown is only called from
dsa_switch_remove which is called by the switch drivers .remove.
As far as I can tell both felix and ksz use device managed allocations in their
setup callback.
^ permalink raw reply
* [PATCH v6 9/9] riscv: dts: spacemit: k1-musepi-pro: add SD card support with UHS modes
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
From: Trevor Gamblin <tgamblin@baylibre.com>
Update the Muse Pi Pro devicetree with SD card support to match what
was done for the OrangePi RV2 in [1]. More precisely:
- Enable sdhci0 controller with 4-bit bus width
- Configure card detect GPIO with inversion
- Connect vmmc-supply to buck4 for 3.3V card power
- Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching
- Add dual pinctrl states for voltage-dependent pin configuration
- Support UHS-I SDR25, SDR50, and SDR104 modes
[1] https://lore.kernel.org/linux-riscv/20260316-orangepi-sd-card-uhs-v3-0-aefd3b7832df@gmail.com/T/#
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts | 66 ++++++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts b/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
index 29e333b670cf0a5c4ed852668460db475b9c44cb..774a4640f06562b5632c510e8961e3d8f60a3b81 100644
--- a/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
@@ -18,6 +18,24 @@ aliases {
ethernet0 = ð0;
serial0 = &uart0;
};
+ reg_dc_in: dc-in-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_in_5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_vcc_4v: vcc-4v {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_4v";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <4000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
chosen {
stdout-path = "serial0";
@@ -77,3 +95,51 @@ &uart0 {
pinctrl-names = "default";
status = "okay";
};
+
+&i2c8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c8_cfg>;
+ status = "okay";
+
+ pmic@41 {
+ compatible = "spacemit,p1";
+ reg = <0x41>;
+ interrupts = <64>;
+ vin-supply = <®_vcc_4v>;
+
+ regulators {
+ buck4: buck4 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ aldo1: aldo1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&sdhci0 {
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&mmc1_cfg>;
+ pinctrl-1 = <&mmc1_uhs_cfg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+ cap-sd-highspeed;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&aldo1>;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 8/9] riscv: dts: spacemit: k1-bananapi-f3: add SD card support with UHS modes
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add complete SD card controller support with UHS high-speed modes.
- Enable sdhci0 controller with 4-bit bus width
- Configure card detect GPIO with inversion
- Connect vmmc-supply to buck4 for 3.3V card power
- Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching
- Add dual pinctrl states for voltage-dependent pin configuration
- Support UHS-I SDR25, SDR50, and SDR104 modes
This enables full SD card functionality including high-speed UHS modes
for improved performance.
Suggested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 5790d927b93db350c8f53aa0f314183b3173fd76..a7d88564630f3332270ba5fe47b078bb14f564e5 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -220,7 +220,7 @@ buck3_1v8: buck3 {
regulator-always-on;
};
- buck4 {
+ buck4: buck4 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3300000>;
regulator-ramp-delay = <5000>;
@@ -241,7 +241,7 @@ buck6 {
regulator-always-on;
};
- aldo1 {
+ aldo1: aldo1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3400000>;
regulator-boot-on;
@@ -367,3 +367,23 @@ hub_3_0: hub@2 {
reset-gpios = <&gpio K1_GPIO(124) GPIO_ACTIVE_LOW>;
};
};
+
+&sdhci0 {
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&mmc1_cfg>;
+ pinctrl-1 = <&mmc1_uhs_cfg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ broken-cd;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+ cap-sd-highspeed;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&aldo1>;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 7/9] riscv: dts: spacemit: k1-orangepi-rv2: add SD card support with UHS modes
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add complete SD card controller support with UHS high-speed modes.
- Enable sdhci0 controller with 4-bit bus width
- Configure card detect GPIO with inversion
- Connect vmmc-supply to buck4 for 3.3V card power
- Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching
- Add dual pinctrl states for voltage-dependent pin configuration
- Support UHS-I SDR25, SDR50, and SDR104 modes
This enables full SD card functionality including high-speed UHS modes
for improved performance.
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 9c417a483f6bad6e60617cf8d5400ca079588726..95cfb4681ced8f539693717e718a3633c35989d5 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -140,3 +140,22 @@ aldo1: aldo1 {
};
};
};
+
+&sdhci0 {
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&mmc1_cfg>;
+ pinctrl-1 = <&mmc1_uhs_cfg>;
+ bus-width = <4>;
+ cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>;
+ cd-inverted;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+ cap-sd-highspeed;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&aldo1>;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 6/9] riscv: dts: spacemit: k1-orangepi-rv2: add PMIC and power infrastructure
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add Spacemit P1 PMIC configuration and board power infrastructure for
voltage regulation support.
- Add board power regulators (5V input, 4V rail)
- Enable I2C8 for PMIC communication
- Configure PMIC with buck4 (vmmc) and aldo1 (vqmmc) regulators
- Set up regulator constraints for SD card operation
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 48 ++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 7b7331cb3c726f11d597f81917f3a3f5fc21e1b9..9c417a483f6bad6e60617cf8d5400ca079588726 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -19,6 +19,25 @@ aliases {
ethernet1 = ð1;
};
+ reg_dc_in: dc-in-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_in_5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_vcc_4v: vcc-4v {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_4v";
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <4000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ vin-supply = <®_dc_in>;
+ };
+
chosen {
stdout-path = "serial0";
};
@@ -92,3 +111,32 @@ &uart0 {
pinctrl-0 = <&uart0_2_cfg>;
status = "okay";
};
+
+&i2c8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c8_cfg>;
+ status = "okay";
+
+ pmic@41 {
+ compatible = "spacemit,p1";
+ reg = <0x41>;
+ interrupts = <64>;
+ vin-supply = <®_vcc_4v>;
+
+ regulators {
+ buck4: buck4 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <5000>;
+ regulator-always-on;
+ };
+
+ aldo1: aldo1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 5/9] riscv: dts: spacemit: k1: add SD card controller and pinctrl support
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add SD card controller infrastructure for SpacemiT K1 SoC with complete
pinctrl support for both standard and UHS modes.
- Add sdhci0 controller definition with clocks, resets and interrupts
- Add mmc1_cfg pinctrl for 3.3V standard SD operation
- Add mmc1_uhs_cfg pinctrl for 1.8V UHS high-speed operation
- Configure appropriate drive strength and power-source properties
This provides complete SD card infrastructure that K1-based boards can
enable.
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 40 ++++++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 13 +++++++++
2 files changed, 53 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
index b13dcb10f4d66022d27307de73a6ea3287e97441..b3c472a0783b99091662d2d3516aa7fec4b3c3a3 100644
--- a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
@@ -570,4 +570,44 @@ pwm14-1-pins {
drive-strength = <32>;
};
};
+
+ mmc1_cfg: mmc1-cfg {
+ mmc1-data-cmd-pins {
+ pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
+ <K1_PADCONF(105, 0)>, /* mmc1_d2 */
+ <K1_PADCONF(106, 0)>, /* mmc1_d1 */
+ <K1_PADCONF(107, 0)>, /* mmc1_d0 */
+ <K1_PADCONF(108, 0)>; /* mmc1_cmd */
+ bias-pull-up = <1>;
+ drive-strength = <19>;
+ power-source = <3300>;
+ };
+
+ mmc1-clk-pins {
+ pinmux = <K1_PADCONF(109, 0)>; /* mmc1_clk */
+ bias-pull-down = <1>;
+ drive-strength = <19>;
+ power-source = <3300>;
+ };
+ };
+
+ mmc1_uhs_cfg: mmc1-uhs-cfg {
+ mmc1-data-cmd-pins {
+ pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
+ <K1_PADCONF(105, 0)>, /* mmc1_d2 */
+ <K1_PADCONF(106, 0)>, /* mmc1_d1 */
+ <K1_PADCONF(107, 0)>, /* mmc1_d0 */
+ <K1_PADCONF(108, 0)>; /* mmc1_cmd */
+ bias-pull-up = <1>;
+ drive-strength = <42>;
+ power-source = <1800>;
+ };
+
+ mmc1-clk-pins {
+ pinmux = <K1_PADCONF(109, 0)>; /* mmc1_clk */
+ bias-pull-down = <1>;
+ drive-strength = <42>;
+ power-source = <1800>;
+ };
+ };
};
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index f0bad6855c970a609253d4b0ca2a4fcbf06bb8e3..28949f804610c60b7fa89d957507be32e3b49f34 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -1211,6 +1211,19 @@ emmc: mmc@d4281000 {
interrupts = <101>;
status = "disabled";
};
+
+ sdhci0: mmc@d4280000 {
+ compatible = "spacemit,k1-sdhci";
+ reg = <0x0 0xd4280000 0x0 0x200>;
+ clocks = <&syscon_apmu CLK_SDH_AXI>,
+ <&syscon_apmu CLK_SDH0>;
+ clock-names = "core", "io";
+ resets = <&syscon_apmu RESET_SDH_AXI>,
+ <&syscon_apmu RESET_SDH0>;
+ reset-names = "axi", "sdh";
+ interrupts = <99>;
+ status = "disabled";
+ };
};
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 4/9] mmc: sdhci-of-k1: add comprehensive SDR tuning support
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Implement software tuning algorithm to enable UHS-I SDR modes for SD
card operation and HS200 mode for eMMC. This adds both TX and RX delay
line tuning based on the SpacemiT K1 controller capabilities.
Algorithm features:
- Add tuning register definitions (RX_CFG, DLINE_CTRL, DLINE_CFG)
- Conditional tuning: only for high-speed modes (≥100MHz)
- TX tuning: configure transmit delay line with optimal values
(dline_reg=0, delaycode=127) to ensure optimal signal output timing
- RX tuning: single-pass window detection algorithm testing full
delay range (0-255) to find optimal receive timing window
- Retry mechanism: multiple fallback delays within optimal window
for improved reliability
Tested-by: Anand Moon <linux.amoon@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
drivers/mmc/host/sdhci-of-k1.c | 172 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 172 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-k1.c b/drivers/mmc/host/sdhci-of-k1.c
index d9144537032a51a12d7480885f247f4c66583e59..37b0911e7cf2023ad440fbdbf504821457f061f6 100644
--- a/drivers/mmc/host/sdhci-of-k1.c
+++ b/drivers/mmc/host/sdhci-of-k1.c
@@ -69,6 +69,28 @@
#define SDHC_PHY_DRIVE_SEL GENMASK(2, 0)
#define SDHC_RX_BIAS_CTRL BIT(5)
+#define SPACEMIT_SDHC_RX_CFG_REG 0x118
+#define SDHC_RX_SDCLK_SEL0_MASK GENMASK(1, 0)
+#define SDHC_RX_SDCLK_SEL1_MASK GENMASK(3, 2)
+#define SDHC_RX_SDCLK_SEL1 FIELD_PREP(SDHC_RX_SDCLK_SEL1_MASK, 1)
+
+#define SPACEMIT_SDHC_DLINE_CTRL_REG 0x130
+#define SDHC_DLINE_PU BIT(0)
+#define SDHC_RX_DLINE_CODE_MASK GENMASK(23, 16)
+#define SDHC_TX_DLINE_CODE_MASK GENMASK(31, 24)
+
+#define SPACEMIT_SDHC_DLINE_CFG_REG 0x134
+#define SDHC_RX_DLINE_REG_MASK GENMASK(7, 0)
+#define SDHC_RX_DLINE_GAIN BIT(8)
+#define SDHC_TX_DLINE_REG_MASK GENMASK(23, 16)
+
+#define SPACEMIT_RX_DLINE_REG 9
+#define SPACEMIT_RX_TUNE_DELAY_MIN 0x0
+#define SPACEMIT_RX_TUNE_DELAY_MAX 0xFF
+
+#define SPACEMIT_TX_TUNING_DLINE_REG 0x00
+#define SPACEMIT_TX_TUNING_DELAYCODE 127
+
struct spacemit_sdhci_host {
struct clk *clk_core;
struct clk *clk_io;
@@ -96,6 +118,50 @@ static inline void spacemit_sdhci_clrsetbits(struct sdhci_host *host, u32 clr, u
sdhci_writel(host, val, reg);
}
+static void spacemit_sdhci_set_rx_delay(struct sdhci_host *host, u8 delay)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_DLINE_CODE_MASK,
+ FIELD_PREP(SDHC_RX_DLINE_CODE_MASK, delay),
+ SPACEMIT_SDHC_DLINE_CTRL_REG);
+}
+
+static void spacemit_sdhci_set_tx_delay(struct sdhci_host *host, u8 delay)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_TX_DLINE_CODE_MASK,
+ FIELD_PREP(SDHC_TX_DLINE_CODE_MASK, delay),
+ SPACEMIT_SDHC_DLINE_CTRL_REG);
+}
+
+static void spacemit_sdhci_set_tx_dline_reg(struct sdhci_host *host, u8 dline_reg)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_TX_DLINE_REG_MASK,
+ FIELD_PREP(SDHC_TX_DLINE_REG_MASK, dline_reg),
+ SPACEMIT_SDHC_DLINE_CFG_REG);
+}
+
+static void spacemit_sdhci_tx_tuning_prepare(struct sdhci_host *host)
+{
+ spacemit_sdhci_setbits(host, SDHC_TX_MUX_SEL, SPACEMIT_SDHC_TX_CFG_REG);
+ spacemit_sdhci_setbits(host, SDHC_DLINE_PU, SPACEMIT_SDHC_DLINE_CTRL_REG);
+ udelay(5);
+}
+
+static void spacemit_sdhci_prepare_tuning(struct sdhci_host *host)
+{
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_DLINE_REG_MASK,
+ FIELD_PREP(SDHC_RX_DLINE_REG_MASK, SPACEMIT_RX_DLINE_REG),
+ SPACEMIT_SDHC_DLINE_CFG_REG);
+
+ spacemit_sdhci_setbits(host, SDHC_DLINE_PU, SPACEMIT_SDHC_DLINE_CTRL_REG);
+ udelay(5);
+
+ spacemit_sdhci_clrsetbits(host, SDHC_RX_SDCLK_SEL1_MASK, SDHC_RX_SDCLK_SEL1,
+ SPACEMIT_SDHC_RX_CFG_REG);
+
+ if (host->mmc->ios.timing == MMC_TIMING_MMC_HS200)
+ spacemit_sdhci_setbits(host, SDHC_HS200_USE_RFIFO, SPACEMIT_SDHC_PHY_FUNC_REG);
+}
+
static void spacemit_sdhci_reset(struct sdhci_host *host, u8 mask)
{
sdhci_reset(host, mask);
@@ -191,6 +257,111 @@ static unsigned int spacemit_sdhci_clk_get_max_clock(struct sdhci_host *host)
return clk_get_rate(pltfm_host->clk);
}
+static int spacemit_sdhci_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+ int current_len = 0, current_start = 0;
+ int max_pass_len = 0, max_pass_start = 0;
+ struct mmc_host *mmc = host->mmc;
+ struct mmc_ios ios = mmc->ios;
+ u8 final_delay;
+ int ret = 0;
+ int i;
+
+ /*
+ * Tuning is required for SDR50/SDR104, HS200/HS400 cards and
+ * if clock frequency is greater than 100MHz in these modes.
+ */
+ if (host->clock < 100 * 1000 * 1000 ||
+ !(ios.timing == MMC_TIMING_MMC_HS200 ||
+ ios.timing == MMC_TIMING_UHS_SDR50 ||
+ ios.timing == MMC_TIMING_UHS_SDR104))
+ return 0;
+
+ if (mmc->caps2 & MMC_CAP2_NO_MMC) {
+ spacemit_sdhci_set_tx_dline_reg(host, SPACEMIT_TX_TUNING_DLINE_REG);
+ spacemit_sdhci_set_tx_delay(host, SPACEMIT_TX_TUNING_DELAYCODE);
+ spacemit_sdhci_tx_tuning_prepare(host);
+
+ dev_dbg(mmc_dev(host->mmc), "TX tuning: dline_reg=%d, delaycode=%d\n",
+ SPACEMIT_TX_TUNING_DLINE_REG, SPACEMIT_TX_TUNING_DELAYCODE);
+ }
+
+ spacemit_sdhci_prepare_tuning(host);
+
+ for (i = SPACEMIT_RX_TUNE_DELAY_MIN; i <= SPACEMIT_RX_TUNE_DELAY_MAX; i++) {
+ spacemit_sdhci_set_rx_delay(host, i);
+ ret = mmc_send_tuning(host->mmc, opcode, NULL);
+
+ dev_dbg(mmc_dev(host->mmc), "RX delay %d: %s\n",
+ i, ret == 0 ? "pass" : "fail");
+
+ if (ret == 0) {
+ /* Test passed - extend current window */
+ if (current_len == 0)
+ current_start = i;
+ current_len++;
+ } else {
+ /* Test failed - check if current window is best so far */
+ if (current_len > max_pass_len) {
+ max_pass_len = current_len;
+ max_pass_start = current_start;
+ }
+ current_len = 0;
+ }
+ }
+
+ if (current_len > max_pass_len) {
+ max_pass_len = current_len;
+ max_pass_start = current_start;
+ }
+
+ if (max_pass_len < 3) {
+ dev_err(mmc_dev(host->mmc), "Tuning failed: no stable window found\n");
+ return -EIO;
+ }
+
+ final_delay = max_pass_start + max_pass_len / 2;
+ spacemit_sdhci_set_rx_delay(host, final_delay);
+ ret = mmc_send_tuning(host->mmc, opcode, NULL);
+ if (ret) {
+ u8 retry_delays[] = {
+ max_pass_start + max_pass_len / 4,
+ max_pass_start + (3 * max_pass_len) / 4,
+ max_pass_start,
+ max_pass_start + max_pass_len - 1
+ };
+ int retry_count = ARRAY_SIZE(retry_delays);
+
+ dev_warn(mmc_dev(mmc), "Primary delay %d failed, trying alternatives\n",
+ final_delay);
+
+ for (i = 0; i < retry_count; i++) {
+ if (retry_delays[i] >= SPACEMIT_RX_TUNE_DELAY_MIN &&
+ retry_delays[i] <= SPACEMIT_RX_TUNE_DELAY_MAX) {
+ spacemit_sdhci_set_rx_delay(host, retry_delays[i]);
+ ret = mmc_send_tuning(host->mmc, opcode, NULL);
+ if (!ret) {
+ final_delay = retry_delays[i];
+ dev_info(mmc_dev(mmc), "Retry successful with delay %d\n",
+ final_delay);
+ break;
+ }
+ }
+ }
+
+ if (ret) {
+ dev_err(mmc_dev(mmc), "All retry attempts failed\n");
+ return -EIO;
+ }
+ }
+
+ dev_dbg(mmc_dev(host->mmc),
+ "Tuning successful: window %d-%d, using delay %d\n",
+ max_pass_start, max_pass_start + max_pass_len - 1, final_delay);
+
+ return 0;
+}
+
static int spacemit_sdhci_pre_select_hs400(struct mmc_host *mmc)
{
struct sdhci_host *host = mmc_priv(mmc);
@@ -326,6 +497,7 @@ static const struct sdhci_ops spacemit_sdhci_ops = {
.set_bus_width = sdhci_set_bus_width,
.set_clock = spacemit_sdhci_set_clock,
.set_uhs_signaling = spacemit_sdhci_set_uhs_signaling,
+ .platform_execute_tuning = spacemit_sdhci_execute_tuning,
};
static const struct sdhci_pltfm_data spacemit_sdhci_k1_pdata = {
--
2.53.0
^ permalink raw reply related
* [PATCH v6 3/9] mmc: sdhci-of-k1: add regulator and pinctrl voltage switching support
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Add voltage switching infrastructure for UHS-I modes by integrating both
regulator framework (for supply voltage control) and pinctrl state
switching (for pin drive strength optimization).
- Add regulator supply parsing and voltage switching callback
- Add optional pinctrl state switching between "default" (3.3V) and
"state_uhs" (1.8V) configurations
- Enable coordinated voltage and pin configuration changes for UHS modes
This provides complete voltage switching support while maintaining
backward compatibility when pinctrl states are not defined.
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
drivers/mmc/host/sdhci-of-k1.c | 72 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-k1.c b/drivers/mmc/host/sdhci-of-k1.c
index 0dd06fc19b8574ae1b00f7e5d09b7d4c87d06770..d9144537032a51a12d7480885f247f4c66583e59 100644
--- a/drivers/mmc/host/sdhci-of-k1.c
+++ b/drivers/mmc/host/sdhci-of-k1.c
@@ -16,6 +16,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/reset.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
#include "sdhci.h"
@@ -71,6 +72,9 @@
struct spacemit_sdhci_host {
struct clk *clk_core;
struct clk *clk_io;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pinctrl_default;
+ struct pinctrl_state *pinctrl_uhs;
};
/* All helper functions will update clr/set while preserve rest bits */
@@ -219,6 +223,46 @@ static void spacemit_sdhci_pre_hs400_to_hs200(struct mmc_host *mmc)
SPACEMIT_SDHC_PHY_CTRL_REG);
}
+static int spacemit_sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct spacemit_sdhci_host *sdhst = sdhci_pltfm_priv(pltfm_host);
+ struct pinctrl_state *state;
+ int ret;
+
+ ret = sdhci_start_signal_voltage_switch(mmc, ios);
+ if (ret)
+ return ret;
+
+ if (!sdhst->pinctrl)
+ return 0;
+
+ /* Select appropriate pinctrl state based on signal voltage */
+ switch (ios->signal_voltage) {
+ case MMC_SIGNAL_VOLTAGE_330:
+ state = sdhst->pinctrl_default;
+ break;
+ case MMC_SIGNAL_VOLTAGE_180:
+ state = sdhst->pinctrl_uhs;
+ break;
+ default:
+ dev_warn(mmc_dev(mmc), "unsupported voltage %d\n", ios->signal_voltage);
+ return 0;
+ }
+
+ ret = pinctrl_select_state(sdhst->pinctrl, state);
+ if (ret) {
+ dev_warn(mmc_dev(mmc), "failed to select pinctrl state: %d\n", ret);
+ return 0;
+ }
+ dev_dbg(mmc_dev(mmc), "switched to %s pinctrl state\n",
+ ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180 ? "UHS" : "default");
+
+ return 0;
+}
+
static inline int spacemit_sdhci_get_clocks(struct device *dev,
struct sdhci_pltfm_host *pltfm_host)
{
@@ -252,6 +296,30 @@ static inline int spacemit_sdhci_get_resets(struct device *dev)
return 0;
}
+static inline void spacemit_sdhci_get_pins(struct device *dev,
+ struct sdhci_pltfm_host *pltfm_host)
+{
+ struct spacemit_sdhci_host *sdhst = sdhci_pltfm_priv(pltfm_host);
+
+ sdhst->pinctrl = devm_pinctrl_get(dev);
+ if (IS_ERR(sdhst->pinctrl)) {
+ sdhst->pinctrl = NULL;
+ dev_dbg(dev, "pinctrl not available, voltage switching will work without it\n");
+ return;
+ }
+
+ sdhst->pinctrl_default = pinctrl_lookup_state(sdhst->pinctrl, "default");
+ if (IS_ERR(sdhst->pinctrl_default))
+ sdhst->pinctrl_default = NULL;
+
+ sdhst->pinctrl_uhs = pinctrl_lookup_state(sdhst->pinctrl, "uhs");
+ if (IS_ERR(sdhst->pinctrl_uhs))
+ sdhst->pinctrl_uhs = NULL;
+
+ dev_dbg(dev, "pinctrl setup: default=%p, uhs=%p\n",
+ sdhst->pinctrl_default, sdhst->pinctrl_uhs);
+}
+
static const struct sdhci_ops spacemit_sdhci_ops = {
.get_max_clock = spacemit_sdhci_clk_get_max_clock,
.reset = spacemit_sdhci_reset,
@@ -324,6 +392,10 @@ static int spacemit_sdhci_probe(struct platform_device *pdev)
host->mmc->caps |= MMC_CAP_NEED_RSP_BUSY;
+ spacemit_sdhci_get_pins(dev, pltfm_host);
+
+ host->mmc_host_ops.start_signal_voltage_switch = spacemit_sdhci_start_signal_voltage_switch;
+
ret = spacemit_sdhci_get_clocks(dev, pltfm_host);
if (ret)
goto err_pltfm;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Andrea della Porta @ 2026-04-07 8:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrea della Porta, Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <20260405-enormous-glittering-avocet-285f82@quoll>
Hi Krzysztof,
On 09:52 Sun 05 Apr , Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 04:31:54PM +0200, Andrea della Porta wrote:
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > +
>
> Missing ref to pwm.yaml.
The reference to pwm.yaml is at line 13, as follows:
allOf:
- $ref: pwm.yaml#
currently right after the maintainers: block. Are you
suggesting to move it after the required: block?
>
> > +additionalProperties: false
>
> and this should be unevaluatedProperties. See other files.
Ack.
Many thanks,
Andrea
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH v6 2/9] mmc: sdhci-of-k1: enable essential clock infrastructure for SD operation
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Ensure SD card pins receive clock signals by enabling pad clock
generation and overriding automatic clock gating. Required for all SD
operation modes.
The SDHC_GEN_PAD_CLK_ON setting in LEGACY_CTRL_REG is safe for both SD
and eMMC operation as both protocols use the same physical MMC interface
pins and require proper clock signal generation at the hardware level
for signal integrity and timing.
Additional SD-specific clock overrides (SDHC_OVRRD_CLK_OEN and
SDHC_FORCE_CLK_ON) are conditionally applied only for SD-only
controllers to handle removable card scenarios.
Tested-by: Anand Moon <linux.amoon@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.dev>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
drivers/mmc/host/sdhci-of-k1.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-k1.c b/drivers/mmc/host/sdhci-of-k1.c
index 455656f9842df90c7a94a290aeec22157b378fc1..0dd06fc19b8574ae1b00f7e5d09b7d4c87d06770 100644
--- a/drivers/mmc/host/sdhci-of-k1.c
+++ b/drivers/mmc/host/sdhci-of-k1.c
@@ -21,6 +21,13 @@
#include "sdhci.h"
#include "sdhci-pltfm.h"
+#define SPACEMIT_SDHC_OP_EXT_REG 0x108
+#define SDHC_OVRRD_CLK_OEN BIT(11)
+#define SDHC_FORCE_CLK_ON BIT(12)
+
+#define SPACEMIT_SDHC_LEGACY_CTRL_REG 0x10C
+#define SDHC_GEN_PAD_CLK_ON BIT(6)
+
#define SPACEMIT_SDHC_MMC_CTRL_REG 0x114
#define SDHC_MISC_INT_EN BIT(1)
#define SDHC_MISC_INT BIT(2)
@@ -101,6 +108,12 @@ static void spacemit_sdhci_reset(struct sdhci_host *host, u8 mask)
if (!(host->mmc->caps2 & MMC_CAP2_NO_MMC))
spacemit_sdhci_setbits(host, SDHC_MMC_CARD_MODE, SPACEMIT_SDHC_MMC_CTRL_REG);
+
+ spacemit_sdhci_setbits(host, SDHC_GEN_PAD_CLK_ON, SPACEMIT_SDHC_LEGACY_CTRL_REG);
+
+ if (host->mmc->caps2 & MMC_CAP2_NO_MMC)
+ spacemit_sdhci_setbits(host, SDHC_OVRRD_CLK_OEN | SDHC_FORCE_CLK_ON,
+ SPACEMIT_SDHC_OP_EXT_REG);
}
static void spacemit_sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned int timing)
--
2.53.0
^ permalink raw reply related
* [PATCH v6 1/9] dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-0-b5b8a1b2bfc8@gmail.com>
Document pinctrl properties to support voltage-dependent pin
configuration switching for UHS-I SD card modes.
Add optional pinctrl-names property with two states:
- "default": For 3.3V operation with standard drive strength
- "state_uhs": For 1.8V operation with optimized drive strength
These pinctrl states allow the SDHCI driver to coordinate voltage
switching with pin configuration changes, ensuring proper signal
integrity during UHS-I mode transitions.
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
.../devicetree/bindings/mmc/spacemit,sdhci.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
index 9a055d963a7f0cdba4741c1e3e7269688dcd5f45..932fccc609bf8dbaf3ecfe09d9e610852ac7afa0 100644
--- a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
@@ -11,6 +11,7 @@ maintainers:
allOf:
- $ref: mmc-controller.yaml#
+ - $ref: sdhci-common.yaml#
properties:
compatible:
@@ -44,6 +45,18 @@ properties:
- const: axi
- const: sdh
+ pinctrl-names:
+ minItems: 1
+ items:
+ - const: default
+ - const: uhs
+
+ pinctrl-0:
+ description: Default pinctrl state for 3.3V operation
+
+ pinctrl-1:
+ description: Optional pinctrl state for 1.8V UHS operation with "uhs" name
+
required:
- compatible
- reg
@@ -62,4 +75,7 @@ examples:
interrupt-parent = <&plic>;
clocks = <&clk_apmu 10>, <&clk_apmu 13>;
clock-names = "core", "io";
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&sdhci_default_cfg>;
+ pinctrl-1 = <&sdhci_uhs_cfg>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 0/9] riscv: spacemit: enable SD card support with UHS modes for OrangePi RV2
From: Iker Pedrosa @ 2026-04-07 8:25 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: Troy Mitchell, Michael Opdenacker, Javier Martinez Canillas,
linux-mmc, devicetree, linux-riscv, spacemit, linux-kernel,
Iker Pedrosa, Anand Moon, Trevor Gamblin
This series enables complete SD card support for the Spacemit K1-based
OrangePi RV2 board, including UHS (Ultra High Speed) modes for
high-performance SD card operation.
Background
The Spacemit K1 SoC includes an SDHCI controller capable of supporting
SD cards up to UHS-I speeds (SDR104 at 208MHz). However, mainline
currently lacks basic SD controller configuration, SDHCI driver
enhancements for voltage switching and tuning, and power management
infrastructure.
Implementation
The series enables SD card support through coordinated layers:
- Hardware infrastructure (patches 1-2): Device tree bindings for voltage
switching hardware and essential clock infrastructure.
- SDHCI driver enhancements (patches 3-7): Regulator framework
integration, pinctrl state switching for voltage domains, AIB register
programming, and comprehensive SDR tuning support for reliable UHS
operation.
- SoC and board integration (patches 8-10): Complete K1 SoC controller
definitions, PMIC power infrastructure, and OrangePi RV2 board enablement
with full UHS support.
This transforms the OrangePi RV2 from having no SD card support to full
UHS-I capability, enabling high-performance storage up to 208MHz.
Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
---
Changes in v6:
- Add pinctrl support for voltage switching. Document optional
pinctrl-names property supporting "default" and "uhs" pinctrl states
for coordinating pin configuration changes during UHS-I voltage
switching.
- Update pinctrl state naming from "state_uhs" to "uhs" to match DT
binding naming convention.
- Fix MMC drive strength values based on vendor kernel investigation.
Correct 3.3V operation from 7mA to 19mA and 1.8V UHS operation from
13mA to 42mA to match proven vendor implementation.
- Link to v5: https://lore.kernel.org/r/20260330-orangepi-sd-card-uhs-v5-0-bd853604322d@gmail.com
Changes in v5:
- Document optional pinctrl-names property supporting "default" and
"state_uhs" pinctrl states for coordinating pin configuration changes
during UHS-I voltage switching.
- Link to v4: https://lore.kernel.org/r/20260323-orangepi-sd-card-uhs-v4-0-567c9775fd0e@gmail.com
Changes in v4:
- Revert to start_signal_voltage_switch() approach for bidirectional
voltage switching: replace voltage_switch() callback with
start_signal_voltage_switch() to properly handle both 3.3V and 1.8V
signal voltage directions.
- Fix DC input voltage specification: corrected the main power supply
from 12V to 5V to match the OrangePi RV2 board specifications. The
board uses a 5V USB-C input connector, not a 12V rail as previously
specified in the device tree.
- k1-bananapi-f3.dts: add `broken-cd` property to work around card
detection. Using `broken-cd` disables hotplug detection but keeps SD
card functionality working without additional dependencies.
- Add SD card support for Muse Pi Pro board (contributed by Trevor
Gamblin): enable SD card support with UHS-I capabilities following the
same pattern as OrangePi RV2, including dual pinctrl states, PMIC
power supplies, and card detection.
- Link to v3: https://lore.kernel.org/r/20260316-orangepi-sd-card-uhs-v3-0-aefd3b7832df@gmail.com
Changes in v3:
- Rebase on mmc.git/next to resolve conflicts with "mmc: sdhci-of-k1:
add reset support" patch.
- Squash tuning infrastructure and implementation patches (3 and 4)
together to form complete functionality and avoid unused function
warnings.
- Reduce code nesting: implemented an early return sanity check in
spacemit_sdhci_voltage_switch() to reduce indentation and improve
logic flow.
- Refactor pinctrl initialization: moved pinctrl resource acquisition
and state lookup into a dedicated helper function,
spacemit_sdhci_get_pins().
- Use generic regulator node names (buck4, aldo1) instead of
device-specific aliases (sd_vmmc, sd_vqmmc) to better reflect that
these PMIC outputs serve multiple devices.
- Remove dead code handling 3.3V voltage switching from
spacemit_sdhci_voltage_switch().
- Optimize tuning algorithm to use single-pass window detection instead
of storing results in array, reducing memory usage and complexity.
- Remove unnecessary card detect check in execute_tuning() - rely on MMC
core.
- Clarify commit message to mention both SD (UHS-I) and eMMC (HS200)
tuning support.
- Add SD card support for Banana Pi BPI-F3 board with UHS-I capabilities
following the same pattern as OrangePi RV2.
- Link to v2: https://lore.kernel.org/r/20260309-orangepi-sd-card-uhs-v2-0-5bb2b574df5d@gmail.com
Changes in v2:
- Removed custom AIB voltage switching code per maintainer feedback. The
existing pinctrl driver already handles AIB voltage switching
automatically via power-source property changes during UHS mode
transitions. This eliminates code duplication.
- Squashed regulator and pinctrl commits into single voltage switching
implementation.
- Moved voltage switching callback from dynamic probe assignment to
static sdhci_ops declaration. Removed redundant SDHCI core call since
the framework handles standard voltage switching automatically.
- Made clock override (SDHC_OVRRD_CLK_OEN | SDHC_FORCE_CLK_ON)
conditional for SD/SDIO cards only. This follows vendor driver pattern
of differentiating SD and eMMC card handling.
- Include no-mmc property for SD card.
- Link to v1: https://lore.kernel.org/r/20260302-orangepi-sd-card-uhs-v1-0-89c219973c0c@gmail.com
---
Iker Pedrosa (8):
dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
mmc: sdhci-of-k1: enable essential clock infrastructure for SD operation
mmc: sdhci-of-k1: add regulator and pinctrl voltage switching support
mmc: sdhci-of-k1: add comprehensive SDR tuning support
riscv: dts: spacemit: k1: add SD card controller and pinctrl support
riscv: dts: spacemit: k1-orangepi-rv2: add PMIC and power infrastructure
riscv: dts: spacemit: k1-orangepi-rv2: add SD card support with UHS modes
riscv: dts: spacemit: k1-bananapi-f3: add SD card support with UHS modes
Trevor Gamblin (1):
riscv: dts: spacemit: k1-musepi-pro: add SD card support with UHS modes
.../devicetree/bindings/mmc/spacemit,sdhci.yaml | 16 ++
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 24 +-
arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts | 66 ++++++
arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 67 ++++++
arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 40 ++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 13 ++
drivers/mmc/host/sdhci-of-k1.c | 257 +++++++++++++++++++++
7 files changed, 481 insertions(+), 2 deletions(-)
---
base-commit: 4c3b07bf68391122266dfb01126484daf352cf70
change-id: 20260226-orangepi-sd-card-uhs-0ecb05839b0c
Best regards,
--
Iker Pedrosa <ikerpedrosam@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: sram: qcom,imem: Add the Milos compatible
From: Luca Weiss @ 2026-04-07 8:21 UTC (permalink / raw)
To: Krzysztof Kozlowski, Luca Weiss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260405-rampant-green-harrier-eaf680@quoll>
On Sun Apr 5, 2026 at 9:54 AM CEST, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 05:00:23PM +0200, Luca Weiss wrote:
>> Add compatible for Milos SoC IMEM.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> Documentation/devicetree/bindings/sram/qcom,imem.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> index c63026904061..38488e28a6b4 100644
>> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
>> @@ -19,6 +19,7 @@ properties:
>> - enum:
>> - qcom,apq8064-imem
>> - qcom,ipq5424-imem
>> + - qcom,milos-imem
>
> Wasn't this imem binding supposed to stop growing and switch to a
> different style?
Then I missed the memo. Is this written anywhere (apart from LKML)?
Regards
Luca
^ permalink raw reply
* Re: [PATCH v6 3/3] fpga-mgr: Add Efinix SPI programming driver
From: Ian Dannapel @ 2026-04-07 8:20 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-fpga, devicetree, linux-kernel, mdf, yilun.xu, trix, robh,
krzk+dt, conor+dt, neil.armstrong, heiko, marex,
prabhakar.mahadev-lad.rj, dev
In-Reply-To: <adSgQJa/8ZPlzPbO@yilunxu-OptiPlex-7050>
Hi,
thanks for the quick review.
On Tue, Apr 7, 2026 at 8:33 AM Xu Yilun <yilun.xu@linux.intel.com> wrote:
>
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index aeb89bb13517..21eb0ef1fc2e 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -24,6 +24,7 @@ obj-$(CONFIG_FPGA_MGR_VERSAL_FPGA) += versal-fpga.o
> > obj-$(CONFIG_FPGA_MGR_MICROCHIP_SPI) += microchip-spi.o
> > obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG) += lattice-sysconfig.o
> > obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG_SPI) += lattice-sysconfig-spi.o
> > +obj-$(CONFIG_FPGA_MGR_EFINIX_SPI) += efinix-spi.o
> > obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
> > obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT) += altera-pr-ip-core-plat.o
>
> This is the tail of "FPGA Manager Drivers", move it here.
All right
>
> ...
>
> > +static int efinix_spi_write_init(struct fpga_manager *mgr,
> > + struct fpga_image_info *info,
> > + const char *buf, size_t count)
> > +{
> > + struct device *dev = &mgr->dev;
>
> Why do you make this change? This is just one-time usage, and in some
> other functions you don't make the same change. Please delete it.
Will revert it
>
> > + struct efinix_spi_conf *conf = mgr->priv;
> > + struct spi_transfer assert_cs = {
> > + .cs_change = 1,
> > + };
> > + struct spi_message message;
> > + int ret;
> > +
> > + if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
> > + dev_err(dev, "Partial reconfiguration not supported\n");
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + /*
> > + * Efinix passive SPI configuration requires chip select to stay
> > + * asserted from reset until the bitstream is fully clocked in.
> > + * Lock the SPI bus so no other device can toggle CS between the
> > + * reset pulse and the write/complete transfers.
> > + */
> > + spi_bus_lock(conf->spi->controller);
> > + spi_message_init_with_transfers(&message, &assert_cs, 1);
> > + ret = spi_sync_locked(conf->spi, &message);
> > + if (ret) {
> > + spi_bus_unlock(conf->spi->controller);
> > + return ret;
> > + }
> > +
> > + /* Reset with CS asserted */
> > + efinix_spi_reset(conf);
> > +
> > + return 0;
> > +}
> > +
> > +static int efinix_spi_write(struct fpga_manager *mgr, const char *buf,
> > + size_t count)
> > +{
> > + struct device *dev = &mgr->dev;
>
> ditto.
>
> > + struct spi_transfer write_xfer = {
> > + .tx_buf = buf,
> > + .len = count,
> > + .cs_change = 1, /* Keep CS asserted */
>
> Move this comment to its first appearance.
>
> ...
>
> > +static const struct of_device_id efinix_spi_of_match[] = {
> > + { .compatible = "efinix,trion-config", },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, efinix_spi_of_match);
> > +
> > +static const struct spi_device_id efinix_ids[] = {
> > + { "trion-config", 0 },
> > + { "titanium-config", 0 },
> > + { "topaz-config", 0 },
>
> Since you've trimmed of_match_table, any reason to keep 3
> spi_device_ids? IIUC you could keep them in sync.
I don't see any reason to have other IDs, will drop them.
I would also rename the file from efinix-spi.c to efinix-config.c to
match the dt bindings
^ permalink raw reply
* [PATCH v13 2/2] arm: dts: aspeed: ventura: add Meta Ventura BMC
From: P.K. Lee @ 2026-04-07 8:17 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
In-Reply-To: <20260407081700.2658011-1-pkleequanta@gmail.com>
Add Linux device tree related to Meta (Facebook) Ventura specific
devices connected to the BMC (AST2600) SoC. The purpose of Ventura is to
detect liquid leakage from all compute trays, switch trays and rack
sensors within the rack, log the events, and take necessary actions
accordingly.
Signed-off-by: P.K. Lee <pkleequanta@gmail.com>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../aspeed/aspeed-bmc-facebook-ventura.dts | 1636 +++++++++++++++++
2 files changed, 1637 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 0f0b5b707654..f5ac72d5933c 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-santabarbara.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+ aspeed-bmc-facebook-ventura.dtb \
aspeed-bmc-facebook-wedge40.dtb \
aspeed-bmc-facebook-wedge100.dtb \
aspeed-bmc-facebook-wedge400-data64.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
new file mode 100644
index 000000000000..6ce6201f7755
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
@@ -0,0 +1,1636 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2023 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/i2c/i2c.h>
+#include <dt-bindings/gpio/aspeed-gpio.h>
+
+/ {
+ model = "Facebook ventura RMC";
+ compatible = "facebook,ventura-rmc", "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ i2c16 = &i2c3mux0ch3;
+ i2c17 = &i2c3mux0ch4;
+ i2c18 = &i2c3mux0ch5;
+ i2c19 = &i2c3mux0ch6;
+ i2c20 = &i2c3mux0ch0;
+ i2c21 = &i2c3mux0ch1;
+ i2c22 = &i2c3mux0ch2;
+ i2c23 = &i2c3mux0ch7;
+ i2c24 = &i2c0mux0ch0;
+ i2c25 = &i2c0mux0ch1;
+ i2c26 = &i2c0mux0ch2;
+ i2c27 = &i2c0mux0ch3;
+ i2c28 = &i2c0mux0ch4;
+ i2c29 = &i2c0mux0ch5;
+ i2c30 = &i2c0mux0ch6;
+ i2c31 = &i2c0mux0ch7;
+ i2c32 = &i2c1mux0ch0;
+ i2c33 = &i2c1mux0ch1;
+ i2c34 = &i2c1mux0ch2;
+ i2c35 = &i2c1mux0ch3;
+ i2c36 = &i2c1mux0ch4;
+ i2c37 = &i2c1mux0ch5;
+ i2c38 = &i2c1mux0ch6;
+ i2c39 = &i2c1mux0ch7;
+ i2c40 = &i2c2mux0ch0;
+ i2c41 = &i2c2mux0ch1;
+ i2c42 = &i2c2mux0ch2;
+ i2c43 = &i2c2mux0ch3;
+ i2c44 = &i2c2mux0ch4;
+ i2c45 = &i2c2mux0ch5;
+ i2c46 = &i2c2mux0ch6;
+ i2c47 = &i2c2mux0ch7;
+ };
+
+ chosen {
+ stdout-path = "serial4:57600n8";
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+ <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+ <&adc1 2>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "bmc_heartbeat_amber";
+ gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-1 {
+ label = "fp_id_amber";
+ default-state = "off";
+ gpios = <&gpio0 ASPEED_GPIO(B, 5) GPIO_ACTIVE_HIGH>;
+ };
+
+ led-2 {
+ label = "bmc_ready_noled";
+ default-state = "on";
+ gpios = <&gpio0 ASPEED_GPIO(B, 3) (GPIO_ACTIVE_HIGH|GPIO_TRANSITORY)>;
+ };
+
+ led-3 {
+ label = "power_blue";
+ default-state = "off";
+ gpios = <&gpio0 ASPEED_GPIO(P, 4) GPIO_ACTIVE_HIGH>;
+ };
+
+ led-4 {
+ label = "compute1_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g5_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-5 {
+ label = "compute1_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-6 {
+ label = "compute1_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-7 {
+ label = "compute2_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-8 {
+ label = "compute2_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-9 {
+ label = "compute2_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-10 {
+ label = "compute3_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-11 {
+ label = "compute3_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-12 {
+ label = "compute3_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-13 {
+ label = "compute4_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-14 {
+ label = "compute4_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-15 {
+ label = "compute4_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-16 {
+ label = "compute5_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-17 {
+ label = "compute5_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-18 {
+ label = "compute5_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-19 {
+ label = "compute6_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-20 {
+ label = "compute6_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-21 {
+ label = "compute6_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-22 {
+ label = "compute7_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-23 {
+ label = "compute7_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-24 {
+ label = "compute7_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-25 {
+ label = "compute8_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-26 {
+ label = "compute8_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-27 {
+ label = "compute8_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-28 {
+ label = "nvs1_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-29 {
+ label = "nvs1_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-30 {
+ label = "nvs1_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-31 {
+ label = "nvs2_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-32 {
+ label = "nvs2_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-33 {
+ label = "nvs2_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-34 {
+ label = "nvs3_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-35 {
+ label = "nvs3_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-36 {
+ label = "nvs3_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g4_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-37 {
+ label = "nvs4_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-38 {
+ label = "nvs4_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-39 {
+ label = "nvs4_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-40 {
+ label = "nvs5_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-41 {
+ label = "nvs5_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-42 {
+ label = "nvs5_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-43 {
+ label = "nvs6_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-44 {
+ label = "nvs6_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-45 {
+ label = "nvs6_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-46 {
+ label = "nvs7_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-47 {
+ label = "nvs7_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-48 {
+ label = "nvs7_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g3_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-49 {
+ label = "nvs8_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-50 {
+ label = "nvs8_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-51 {
+ label = "nvs8_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-52 {
+ label = "nvs9_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-53 {
+ label = "nvs9_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-54 {
+ label = "nvs9_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-55 {
+ label = "compute9_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-56 {
+ label = "compute9_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-57 {
+ label = "compute9_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-58 {
+ label = "compute10_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-59 {
+ label = "compute10_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-60 {
+ label = "compute10_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-61 {
+ label = "compute11_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-62 {
+ label = "compute11_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-63 {
+ label = "compute11_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ led-64 {
+ label = "compute12_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ led-65 {
+ label = "compute12_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-66 {
+ label = "compute12_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g6_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-67 {
+ label = "compute13_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led-68 {
+ label = "compute13_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+
+ led-69 {
+ label = "compute13_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-70 {
+ label = "compute14_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-71 {
+ label = "compute14_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-72 {
+ label = "compute14_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-73 {
+ label = "compute15_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led-74 {
+ label = "compute15_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ led-75 {
+ label = "compute15_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ led-76 {
+ label = "compute16_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ led-77 {
+ label = "compute16_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-78 {
+ label = "compute16_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g2_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led-79 {
+ label = "compute17_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-80 {
+ label = "compute17_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-81 {
+ label = "compute17_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+
+ led-82 {
+ label = "compute18_led_switch";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led-83 {
+ label = "compute18_led_blue";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-84 {
+ label = "compute18_led_amber";
+ default-state = "off";
+ gpios = <&tray_leds_g1_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-85 {
+ label = "fan0_ledd1_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-86 {
+ label = "fan0_ledd2_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-87 {
+ label = "fan0_ledd1_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-88 {
+ label = "fan0_ledd2_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g1_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-89 {
+ label = "fan1_ledd1_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-90 {
+ label = "fan1_ledd2_blue";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-91 {
+ label = "fan1_ledd1_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-92 {
+ label = "fan1_ledd2_amber";
+ default-state = "off";
+ gpios = <&fan_leds_g2_gpio 5 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x80000000>;
+ };
+
+ p1v8_bmc_aux: regulator-p1v8-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p1v8_bmc_aux";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ p2v5_bmc_aux: regulator-p2v5-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p2v5_bmc_aux";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ spi1_gpio: spi {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sck-gpios = <&gpio0 ASPEED_GPIO(Z, 3) GPIO_ACTIVE_HIGH>;
+ mosi-gpios = <&gpio0 ASPEED_GPIO(Z, 4) GPIO_ACTIVE_HIGH>;
+ miso-gpios = <&gpio0 ASPEED_GPIO(Z, 5) GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio0 ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
+ num-chipselects = <1>;
+
+ tpm@0 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+ };
+};
+
+&adc0 {
+ vref-supply = <&p1v8_bmc_aux>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+ &pinctrl_adc2_default &pinctrl_adc3_default
+ &pinctrl_adc4_default &pinctrl_adc5_default
+ &pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+ vref-supply = <&p2v5_bmc_aux>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc10_default>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ spi-max-frequency = <50000000>;
+#include "openbmc-flash-layout-128.dtsi"
+ };
+ flash@1 {
+ status = "okay";
+ m25p,fast-read;
+ label = "alt-bmc";
+ spi-max-frequency = <50000000>;
+ };
+};
+
+&gpio0 {
+ gpio-line-names =
+ /*A0-A7*/ "","","","","","","","",
+ /*B0-B7*/ "BATTERY_DETECT","","","BMC_READY","","","","",
+ /*C0-C7*/ "","","","","","","","",
+ /*D0-D7*/ "","","","","","","","",
+ /*E0-E7*/ "","","","","","","","",
+ /*F0-F7*/ "","","","","","","","",
+ /*G0-G7*/ "","","","","","","","",
+ /*H0-H7*/ "","","","","","","","",
+ /*I0-I7*/ "","","","","","","","",
+ /*J0-J7*/ "","","","","","","","",
+ /*K0-K7*/ "","","","","","","","",
+ /*L0-L7*/ "","","","","","","","",
+ /*M0-M7*/ "","","","","","","","",
+ /*N0-N7*/ "","","","","","","","",
+ /*O0-O7*/ "","","","","","","","USBDBG_IPMI_EN_L",
+ /*P0-P7*/ "","","","","","","","",
+ /*Q0-Q7*/ "","","","","","FM_MDIO_SW_SEL","","",
+ /*R0-R7*/ "","","","","","","","",
+ /*S0-S7*/ "","","","","","","","",
+ /*T0-T7*/ "","","","","","","","",
+ /*U0-U7*/ "","","","","","","","",
+ /*V0-V7*/ "","","","","","","","",
+ /*W0-W7*/ "","","","","","","","",
+ /*X0-X7*/ "","","","","","","","",
+ /*Y0-Y7*/ "","","","","","","","",
+ /*Z0-Z7*/ "","","","","","","","";
+};
+
+&i2c0 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c0mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c0mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c0mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c0mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c0mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c0mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c0mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c0mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c1mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c1mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c1mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c1mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c1mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c1mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c1mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c1mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c2mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c2mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c2mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c2mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c2mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c2mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c2mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c2mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c3 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c3mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c3mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c3mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c3mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ adc@1f {
+ compatible = "ti,adc128d818";
+ reg = <0x1f>;
+ ti,mode = /bits/ 8 <1>;
+ };
+
+ fan_leds_g1_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "FAN0_PRSNT", "FAN1_PRSNT",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+
+ // Fan Board 0 FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ adc@1f {
+ compatible = "ti,adc128d818";
+ reg = <0x1f>;
+ ti,mode = /bits/ 8 <1>;
+ };
+
+ fan_leds_g2_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "FAN2_PRSNT", "FAN3_PRSNT",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+
+ // Fan Board 1 FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ pwm@20 {
+ compatible = "maxim,max31790";
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@2 {
+ reg = <2>;
+ sensor-type = "TACH";
+ };
+ channel@5 {
+ reg = <5>;
+ sensor-type = "TACH";
+ };
+ };
+
+ hwmon: hwmon@23 {
+ compatible = "nuvoton,nct7363";
+ reg = <0x23>;
+ #pwm-cells = <2>;
+
+ //fan 0 IL
+ fan-0 {
+ pwms = <&hwmon 0 20000>;
+ tach-ch = /bits/ 8 <0x09>;
+ };
+
+ //fan 0 OL
+ fan-1 {
+ pwms = <&hwmon 0 20000>;
+ tach-ch = /bits/ 8 <0x0B>;
+ };
+
+ //fan 1 IL
+ fan-2 {
+ pwms = <&hwmon 4 20000>;
+ tach-ch = /bits/ 8 <0x0A>;
+ };
+
+ //fan 1 OL
+ fan-3 {
+ pwms = <&hwmon 4 20000>;
+ tach-ch = /bits/ 8 <0x0D>;
+ };
+
+ //fan 2 IL
+ fan-4 {
+ pwms = <&hwmon 6 20000>;
+ tach-ch = /bits/ 8 <0x0F>;
+ };
+
+ //fan 2 OL
+ fan-5 {
+ pwms = <&hwmon 6 20000>;
+ tach-ch = /bits/ 8 <0x01>;
+ };
+
+ //fan 3 IL
+ fan-6 {
+ pwms = <&hwmon 10 20000>;
+ tach-ch = /bits/ 8 <0x00>;
+ };
+
+ //fan 3 OL
+ fan-7 {
+ pwms = <&hwmon 10 20000>;
+ tach-ch = /bits/ 8 <0x03>;
+ };
+ };
+ };
+
+ i2c3mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ // REAR-IO Board FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c3mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c4 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+
+ // VR TEMP U399
+ temperature-sensor@4c {
+ compatible = "ti,tmp75";
+ reg = <0x4c>;
+ };
+
+ // VR TEMP U397
+ temperature-sensor@4d {
+ compatible = "ti,tmp75";
+ reg = <0x4d>;
+ };
+
+ // BRICK TEMP U398
+ temperature-sensor@4e {
+ compatible = "ti,tmp75";
+ reg = <0x4e>;
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp75";
+ reg = <0x4f>;
+ };
+
+ // RMC FRU
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+};
+
+&i2c6 {
+ status = "okay";
+
+ gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&i2c7 {
+ status = "okay";
+ bus-frequency = <100000>;
+ multi-master;
+ i2c-scl-clk-low-timeout-us = <31744>;
+
+ //USB Debug Connector
+ ipmb@10 {
+ compatible = "ipmb-dev";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ i2c-protocol;
+ };
+};
+
+&i2c9 {
+ status = "okay";
+
+ // SCM TEMP SENSOR
+ temperature-sensor@4b {
+ compatible = "ti,tmp75";
+ reg = <0x4b>;
+ };
+
+ // SCM FRU EEPROM
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ // BSM FRU EEPROM
+ eeprom@56 {
+ compatible = "atmel,24c64";
+ reg = <0x56>;
+ };
+};
+
+&i2c10 {
+ status = "okay";
+
+ gpio@10 {
+ compatible = "nxp,pca9555";
+ reg = <0x10>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "IT_STOP_PUMP_SPARE_2", "IT_STOP_PUMP_2",
+ "IT_STOP_PUMP_SPARE", "IT_STOP_PUMP",
+ "", "RPU_2_READY_PLD_R",
+ "RPU_READY_SPARE_PLD_R", "",
+ "wPWRGD_P12V_SCM_R", "wPWRGD_P12V_AUX_R",
+ "wPWRGD_P24V_AUX_R", "wPWRGD_P52V_HSC_PWROK_R",
+ "wSMB_TMC75_TEMP_ALERT_N_R", "wP48V_HSC_ALERT_N",
+ "wP24V_AUX_INA230_ALERT_N_R", "wP24V_SM_INA230_ALERT_N_R";
+ };
+
+ gpio@11 {
+ compatible = "nxp,pca9555";
+ reg = <0x11>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "wPWRGD_P24V_SMPWROK",
+ "wPWRGD_P1V05_AUX_R", "wPWRGD_P1V5_AUX_R",
+ "wPWRGD_P3V3_AUX_R", "wPWRGD_P5V_AUX_R",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ power-monitor@14 {
+ compatible = "infineon,xdp710";
+ reg = <0x14>;
+ };
+
+ gpio@16 {
+ compatible = "nxp,pca9555";
+ reg = <0x16>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PWREN_COMPUTE_BLADE2_EN_R", "PWREN_COMPUTE_BLADE1_EN_R",
+ "", "",
+ "", "",
+ "", "",
+ "PWREN_NVS_BLADE2_EN_L_R", "PWREN_NVS_BLADE1_EN_L_R",
+ "PWREN_COMPUTE_BLADE8_EN_R", "PWREN_COMPUTE_BLADE7_EN_R",
+ "PWREN_COMPUTE_BLADE6_EN_R", "PWREN_COMPUTE_BLADE5_EN_R",
+ "PWREN_COMPUTE_BLADE4_EN_R", "PWREN_COMPUTE_BLADE3_EN_R";
+ };
+
+ gpio@17 {
+ compatible = "nxp,pca9555";
+ reg = <0x17>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PWREN_COMPUTE_BLADE18_EN_R", "PWREN_COMPUTE_BLADE17_EN_R",
+ "PWREN_COMPUTE_BLADE16_EN_R", "PWREN_COMPUTE_BLADE15_EN_R",
+ "PWREN_COMPUTE_BLADE14_EN_R", "PWREN_COMPUTE_BLADE13_EN_R",
+ "PWREN_COMPUTE_BLADE12_EN_R", "PWREN_COMPUTE_BLADE11_EN_R",
+ "PWREN_COMPUTE_BLADE9_EN_R", "PWREN_NVS_BLADE9_EN_L_R",
+ "PWREN_NVS_BLADE8_EN_L_R", "PWREN_NVS_BLADE7_EN_L_R",
+ "PWREN_NVS_BLADE6_EN_L_R", "PWREN_NVS_BLADE5_EN_L_R",
+ "PWREN_NVS_BLADE4_EN_L_R", "PWREN_NVS_BLADE3_EN_L_R";
+ };
+
+ gpio@19 {
+ compatible = "nxp,pca9555";
+ reg = <0x19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <22 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "wIT_GEAR_RPU_2_LINK_PRSNT_SPARE_N_R", "wIT_GEAR_RPU_2_LINK_PRSNT_N_R",
+ "wIT_GEAR_RPU_LINK_PRSNT_SPARE_N_R", "wIT_GEAR_RPU_LINK_PRSNT_N_R",
+ "", "",
+ "", "";
+ };
+
+ gpio@1a {
+ compatible = "nxp,pca9555";
+ reg = <0x1a>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "wPRSNT_LEAK1_SENSOR_R_PLD_N", "wPRSNT_LEAK0_SENSOR_R_PLD_N",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "wPRSNT_LEAK2_SENSOR_R_PLD_N";
+ };
+
+ gpio@1b {
+ compatible = "nxp,pca9555";
+ reg = <0x1b>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <18 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "wPRSNT_LEAK4_SENSOR_R_PLD_N",
+ "wPRSNT_LEAK3_SENSOR_R_PLD_N", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "PWREN_COMPUTE_BLADE10_EN_R";
+ };
+
+ power-monitor@44 {
+ compatible = "lltc,ltc4286";
+ reg = <0x44>;
+ };
+};
+
+&i2c14 {
+ status = "okay";
+};
+
+&i2c15 {
+ status = "okay";
+
+ tray_leds_g1_gpio: gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g2_gpio: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g3_gpio: gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g4_gpio: gpio@24 {
+ compatible = "nxp,pca9555";
+ reg = <0x24>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g5_gpio: gpio@25 {
+ compatible = "nxp,pca9555";
+ reg = <0x25>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ tray_leds_g6_gpio: gpio@26 {
+ compatible = "nxp,pca9555";
+ reg = <0x26>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ // LED Board FRU
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+};
+
+&mac3 {
+ status = "okay";
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii4_default>;
+
+ /* Connected to Marvell 88E6393X CPU port in unmanaged mode */
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+&mdio0 {
+ status = "okay";
+ /* * Intentionally left empty.
+ * Enabled to allow user-space tools (e.g., mdio)
+ * to access the unmanaged Marvell switch registers.
+ */
+};
+
+&sgpiom0 {
+ status = "okay";
+ ngpios = <128>;
+ bus-frequency = <2000000>;
+
+ gpio-line-names =
+ /*"input pin","output pin"*/
+ /*A0 - A7*/
+ "power-chassis-good","power-chassis-control",
+ "IOEXP1_INT_N","WATER_VALVE_CLOSED_N",
+ "wPRSNT_RETURN_PLD_R_N","FM_MDIO_SW_SEL_PLD",
+ "wPRSNT_SUPPLY_PLD_R_N","FM_88E6393X_BIN_UPDATE_EN_N",
+ "LEAK3_DETECT","",
+ "LEAK4_DETECT","",
+ "RETURN_CNTL_FB_D_R","",
+ "SUPPLY_CNTL_FB_D_R","",
+ /*B0 - B7*/
+ "IOEXP0_INT_N","",
+ "IOEXP11_INT_N","",
+ "IOEXP10_INT_N","",
+ "IOEXP9_INT_N","",
+ "RPU_2_READY_SPARE_PLD_R","",
+ "IOEXP7_INT_N","",
+ "IOEXP6_INT_N","",
+ "RPU_READY_PLD_R","",
+ /*C0 - C7*/
+ "wAALC_RPU_READY","",
+ "LEAK0_DETECT","",
+ "LEAK1_DETECT","",
+ "LEAK2_DETECT","",
+ "PRSNT_COMPUTE_TRAY1_N","",
+ "PRSNT_COMPUTE_TRAY2_N","",
+ "PRSNT_COMPUTE_TRAY3_N","",
+ "PRSNT_COMPUTE_TRAY4_N","",
+ /*D0 - D7*/
+ "PRSNT_COMPUTE_TRAY5_N","",
+ "PRSNT_COMPUTE_TRAY6_N","",
+ "PRSNT_COMPUTE_TRAY7_N","",
+ "PRSNT_COMPUTE_TRAY8_N","",
+ "PRSNT_NVS_TRAY1_N","",
+ "PRSNT_NVS_TRAY2_N","",
+ "PRSNT_COMPUTE_TRAY11_N","",
+ "PRSNT_COMPUTE_TRAY12_N","",
+ /*E0 - E7*/
+ "PRSNT_COMPUTE_TRAY13_N","",
+ "PRSNT_COMPUTE_TRAY14_N","",
+ "PRSNT_COMPUTE_TRAY15_N","",
+ "PRSNT_COMPUTE_TRAY16_N","",
+ "PRSNT_COMPUTE_TRAY17_N","",
+ "PRSNT_COMPUTE_TRAY18_N","",
+ "PRSNT_NVS_TRAY3_N","",
+ "PRSNT_NVS_TRAY4_N","",
+ /*F0 - F7*/
+ "PRSNT_NVS_TRAY5_N","",
+ "PRSNT_NVS_TRAY6_N","",
+ "PRSNT_NVS_TRAY7_N","",
+ "PRSNT_NVS_TRAY8_N","",
+ "PRSNT_NVS_TRAY9_N","",
+ "PRSNT_COMPUTE_TRAY9_N","",
+ "PRSNT_COMPUTE_TRAY10_N","",
+ "SMALL_LEAK_COMPUTE_TRAY1_N","",
+ /*G0 - G7*/
+ "SMALL_LEAK_COMPUTE_TRAY2_N","",
+ "SMALL_LEAK_COMPUTE_TRAY3_N","",
+ "SMALL_LEAK_COMPUTE_TRAY4_N","",
+ "SMALL_LEAK_COMPUTE_TRAY5_N","",
+ "SMALL_LEAK_COMPUTE_TRAY6_N","",
+ "SMALL_LEAK_COMPUTE_TRAY7_N","",
+ "SMALL_LEAK_COMPUTE_TRAY8_N","",
+ "SMALL_LEAK_NVS_TRAY1_N","",
+ /*H0 - H7*/
+ "SMALL_LEAK_NVS_TRAY2_N","",
+ "SMALL_LEAK_COMPUTE_TRAY11_N","",
+ "SMALL_LEAK_COMPUTE_TRAY12_N","",
+ "SMALL_LEAK_COMPUTE_TRAY13_N","",
+ "SMALL_LEAK_COMPUTE_TRAY14_N","",
+ "SMALL_LEAK_COMPUTE_TRAY15_N","",
+ "SMALL_LEAK_COMPUTE_TRAY16_N","",
+ "SMALL_LEAK_COMPUTE_TRAY17_N","",
+ /*I0 - I7*/
+ "SMALL_LEAK_COMPUTE_TRAY18_N","",
+ "SMALL_LEAK_NVS_TRAY3_N","",
+ "SMALL_LEAK_NVS_TRAY4_N","",
+ "SMALL_LEAK_NVS_TRAY5_N","",
+ "SMALL_LEAK_NVS_TRAY6_N","",
+ "SMALL_LEAK_NVS_TRAY7_N","",
+ "SMALL_LEAK_NVS_TRAY8_N","",
+ "SMALL_LEAK_NVS_TRAY9_N","",
+ /*J0 - J7*/
+ "SMALL_LEAK_COMPUTE_TRAY9_N","",
+ "SMALL_LEAK_COMPUTE_TRAY10_N","",
+ "PWRGD_COMPUTE_TRAY1_N","",
+ "PWRGD_COMPUTE_TRAY2_N","",
+ "PWRGD_COMPUTE_TRAY3_N","",
+ "PWRGD_COMPUTE_TRAY4_N","",
+ "PWRGD_COMPUTE_TRAY5_N","",
+ "PWRGD_COMPUTE_TRAY6_N","",
+ /*K0 - K7*/
+ "PWRGD_COMPUTE_TRAY7_N","",
+ "PWRGD_COMPUTE_TRAY8_N","",
+ "PWRGD_NVS_TRAY1_PWROK_N","",
+ "PWRGD_NVS_TRAY2_PWROK_N","",
+ "PWRGD_COMPUTE_TRAY11_N","",
+ "PWRGD_COMPUTE_TRAY12_N","",
+ "PWRGD_COMPUTE_TRAY13_N","",
+ "PWRGD_COMPUTE_TRAY14_N","",
+ /*L0 - L7*/
+ "PWRGD_COMPUTE_TRAY15_N","",
+ "PWRGD_COMPUTE_TRAY16_N","",
+ "PWRGD_COMPUTE_TRAY17_N","",
+ "PWRGD_COMPUTE_TRAY18_N","",
+ "PWRGD_NVS_TRAY3_PWROK_N","",
+ "PWRGD_NVS_TRAY4_PWROK_N","",
+ "PWRGD_NVS_TRAY5_PWROK_N","",
+ "PWRGD_NVS_TRAY6_PWROK_N","",
+ /*M0 - M7*/
+ "PWRGD_NVS_TRAY7_PWROK_N","",
+ "PWRGD_NVS_TRAY8_PWROK_N","",
+ "PWRGD_NVS_TRAY9_PWROK_N","",
+ "PWRGD_COMPUTE_TRAY9_N","",
+ "PWRGD_COMPUTE_TRAY10_N","",
+ "LEAK_DETECT_COMPUTE_TRAY1_N","",
+ "LEAK_DETECT_COMPUTE_TRAY2_N","",
+ "LEAK_DETECT_COMPUTE_TRAY3_N","",
+ /*N0 - N7*/
+ "LEAK_DETECT_COMPUTE_TRAY4_N","",
+ "LEAK_DETECT_COMPUTE_TRAY5_N","",
+ "LEAK_DETECT_COMPUTE_TRAY6_N","",
+ "LEAK_DETECT_COMPUTE_TRAY7_N","",
+ "LEAK_DETECT_COMPUTE_TRAY8_N","",
+ "LEAK_DETECT_NVS_TRAY1_N","",
+ "LEAK_DETECT_NVS_TRAY2_N","",
+ "LEAK_DETECT_COMPUTE_TRAY11_N","",
+ /*O0 - O7*/
+ "LEAK_DETECT_COMPUTE_TRAY12_N","",
+ "LEAK_DETECT_COMPUTE_TRAY13_N","",
+ "LEAK_DETECT_COMPUTE_TRAY14_N","",
+ "LEAK_DETECT_COMPUTE_TRAY15_N","",
+ "LEAK_DETECT_COMPUTE_TRAY16_N","",
+ "LEAK_DETECT_COMPUTE_TRAY17_N","",
+ "LEAK_DETECT_COMPUTE_TRAY18_N","",
+ "LEAK_DETECT_NVS_TRAY3_N","",
+ /*P0 - P7*/
+ "LEAK_DETECT_NVS_TRAY4_N","",
+ "LEAK_DETECT_NVS_TRAY5_N","",
+ "LEAK_DETECT_NVS_TRAY6_N","",
+ "LEAK_DETECT_NVS_TRAY7_N","",
+ "LEAK_DETECT_NVS_TRAY8_N","",
+ "LEAK_DETECT_NVS_TRAY9_N","",
+ "LEAK_DETECT_COMPUTE_TRAY9_N","",
+ "LEAK_DETECT_COMPUTE_TRAY10_N","";
+};
+
+&uhci {
+ status = "okay";
+};
+
+&wdt1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdtrst1_default>;
+ aspeed,reset-type = "soc";
+ aspeed,external-signal;
+ aspeed,ext-push-pull;
+ aspeed,ext-active-high;
+ aspeed,ext-pulse-duration = <256>;
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v13 1/2] dt-bindings: arm: aspeed: add Meta Ventura board
From: P.K. Lee @ 2026-04-07 8:16 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
In-Reply-To: <20260407081700.2658011-1-pkleequanta@gmail.com>
Document the new compatibles used on Meta Ventura.
Signed-off-by: P.K. Lee <pkleequanta@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index aedefca7cf4a..afabfe22c8f3 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -92,6 +92,7 @@ properties:
- facebook,harma-bmc
- facebook,minerva-cmc
- facebook,santabarbara-bmc
+ - facebook,ventura-rmc
- facebook,yosemite4-bmc
- ibm,blueridge-bmc
- ibm,everest-bmc
--
2.43.0
^ permalink raw reply related
* [PATCH v13 0/2] Add Meta (Facebook) Ventura BMC (AST2600)
From: P.K. Lee @ 2026-04-07 8:16 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, joel, andrew,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
Cc: Jason-Hsu, p.k.lee
Add Linux device tree entry related to Meta (Facebook) Ventura specific
devices connected to the BMC (AST2600) SoC. The purpose of Ventura is to
detect liquid leakage from all compute trays, switch trays and rack
sensors within the rack, log the events, and take necessary actions
accordingly.
---
v1:
1. Create ventura dts file.
2. Add commit msg.
3. Use format-patch to generate patch.
4. Add subject prefixes matching the subsystem.
---
v2:
1. Modify email content.
---
v3:
1. Add mail list.
---
v4:
1. Apply git send-email --thread option.
2. Sort nodes in the dts alphanumerically.
---
v5:
1. Run scripts/checkpatch.pl and fix reported warnings.
2. Remove unnecessary 88E6393X CONFIG FRU.
---
v6:
1. Add a new stage for the DTS change.
2. Run scripts/checkpatch.pl and fix reported error.
3. Fix the issue in a separate patch.
---
v7:
1. Fix broken indentation in the device tree file.
2. Sort nodes alphabetically, then by address if equal.
3. Rename fan sensor nodes from 'hwmon' to 'fan-controller'.
---
v8:
1. This patch series has significant changes compared to
previous versions, and quite some time has passed since the last
submission.Therefore, previously received Acked-by/Reviewed-by/Tested-by
tags are not included in this version.
If needed, tags can be added again after review of thisnew version.
---
v9:
1. Reordered the node sequence under i2c5.
2. Added a description of the platform's intended use to the commit
messages.
3. Added 3 GPIO expanders to i2c10 and defined the necessary GPIO
line names.
---
v10:
1. Added IRQ support in GPIO expanders under i2c10 to handle edge-triggered
events.
2. Reordered the nodes.
---
v11:
1. Modified the position for i2c3mux0ch6 and i2c3mux0ch7.
---
v12:
1. Added a GPIO expander at address 0x11 on i2c10, and assign an SGPIO pin
as the IRQ for it.
2. Fixed the "failed to match any schema with compatible" issues.
3. Reorder the nodes in alphabetically.
---
v13:
1. Add two GPIO expanders (0x16 and 0x17) to i2c10 and assign two SGPIO
pins as IRQs.
2. Move the RPU_READY_SPARE_PLD_R and RPU_2_READY_PLD_R pins from
SGPIO to the GPIO expander (0x10).
3. Add all tray PWREN pins to the GPIO expanders (0x16, 0x17 and 0x1b).
4. Add explanatory comments for "unmanaged mode" under &mac3 and
"intentionally left empty" under &mdio.
P.K. Lee (2):
dt-bindings: arm: aspeed: add Meta Ventura board
arm: dts: aspeed: ventura: add Meta Ventura BMC
.../bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../aspeed/aspeed-bmc-facebook-ventura.dts | 1636 +++++++++++++++++
3 files changed, 1638 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura.dts
base-commit: e11fa6b1ff6c27c808d17e479bd7d5582e772062
branch: dev-6.6
--
2.43.0
^ permalink raw reply
* Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"
From: Thierry Reding @ 2026-04-07 8:16 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Aaron Kling, Thierry Reding, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Hunter, devicetree, linux-tegra,
linux-kernel
In-Reply-To: <oPjOdaRsQES6O8jgrehMZw@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 9789 bytes --]
On Tue, Apr 07, 2026 at 01:09:10PM +0900, Mikko Perttunen wrote:
> On Monday, April 6, 2026 4:49 PM Aaron Kling wrote:
> > On Tue, Feb 17, 2026 at 4:13 AM Thierry Reding
> > <thierry.reding@kernel.org> wrote:
> > >
> > > On Tue, Feb 17, 2026 at 12:53:54PM +0900, Mikko Perttunen wrote:
> > > > On Thursday, January 22, 2026 7:22 PM Mikko Perttunen wrote:
> > > > > On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> > > > > > On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > > > > > >
> > > > > > > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > > > > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > > > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > > >
> > > > > > > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > > > > > > >
> > > > > > > > > > Mmu is now being enabled for the display controllers.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > > > ---
> > > > > > > > > > arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > > > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > > > > > > > #iommu-cells = <1>;
> > > > > > > > > >
> > > > > > > > > > nvidia,memory-controller = <&mc>;
> > > > > > > > > > - status = "disabled";
> > > > > > > > > > + status = "okay";
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > smmu: iommu@12000000 {
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > 2.51.0
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Question for Jon as the author of the commit being reverted. The
> > > > > > > > > commit message states "we do not have a way to pass frame-buffer
> > > > > > > > > memory from the bootloader to the kernel". If I understand this
> > > > > > > > > correctly, this is talking about seamless handoff. What does this have
> > > > > > > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > > > > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > > > > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > > > > > > allows for better and faster memory allocation. My initial attempts to
> > > > > > > > > enable this didn't work because I tried to attach them to the main mmu
> > > > > > > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > > > > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > > > > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > > > > > > packaging up the change to submit, I found that this had been
> > > > > > > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > > > > > > additional factors?
> > > > > > > >
> > > > > > > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > > > > > > rather to simple-framebuffer. While this does technically work, it also
> > > > > > > > causes a spew of SMMU faults during early boot because the firmware does
> > > > > > > > not properly pass the SMMU mapping information to the kernel.
> > > > > > > >
> > > > > > > > In a nutshell what happens is that the firmware sets up the display
> > > > > > > > controller to scan out from a reserved memory region, but it does so
> > > > > > > > without involving the SMMU, so it uses physical addresses directly. When
> > > > > > > > the kernel boots and the SMMU is enabled the continued accesses from
> > > > > > > > display hardware cause SMMU faults (because there is no mapping for the
> > > > > > > > framebuffer addresses).
> > > > > > > >
> > > > > > > > That said, we did solve these issues and this may not be happening
> > > > > > > > anymore with the most recent L4T releases, so it may be okay to revert
> > > > > > > > this now. We should find out exactly which release includes all the
> > > > > > > > needed changes so that it can be referenced in the commit message. I
> > > > > > > > want to avoid people running new kernels with an old L4T release and
> > > > > > > > then seeing these errors without any reference as to why that might
> > > > > > > > suddenly happen.
> > > > > > >
> > > > > > > For reference, I have rolled back my Android usecase to use the L4T
> > > > > > > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > > > > > > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > > > > > > pending cboot patch to support simple-framebuffer handoff, but haven't
> > > > > > > fully verified it as tegra-drm is currently unable to takeover from
> > > > > > > simplefb like openrm does for t234. But all that to say that since I
> > > > > > > no longer use r35 for t194 I don't have the setup to easily verify
> > > > > > > which point release works here and what doesn't.
> > > > > >
> > > > > > Any further thoughts on this patch?
> > > > > >
> > > > > > Aaron
> > > > >
> > > > > FWIW,
> > > > >
> > > > > looks like the edk2 patch to update iommu-addresses --
> > > > >
> > > > > commit 6071946461389221d2314cbbae0377610b5b1f6a
> > > > > Author: Jan Bobek <jbobek@nvidia.com>
> > > > > Date: Tue Mar 21 00:15:27 2023 +0000
> > > > >
> > > > > feat(NvDisplayControllerDxe): update FDT with framebuffer info
> > > > >
> > > > > On ready-to-boot and whenever FDT is installed, update FDT with
> > > > > framebuffer mode information, base address and size.
> > > > >
> > > > > Signed-off-by: Jan Bobek <jbobek@nvidia.com>
> > > > > Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
> > > > >
> > > > > is in since r36.2
> > > > >
> > > > > $ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"
> > > > > r36.2
> > > > > r36.3.0
> > > > > r36.4.0
> > > > > r36.4.3
> > > > > r36.4.4
> > > > > r36.4.5
> > > > > r38.2
> > > > > r38.4
> > > > >
> > > > > Not so good for T194 since r36 only supports Orin.
> > > > >
> > > > > I'll look into getting this cherry-picked to r35.
> > > > >
> > > > > Mikko
> > > > >
> > > > >
> > > >
> > > > I looked into this and it appears a version of this is in r35, but it
> > > > only supports T234. However, I also found that at one point, L4T
> > > > bootloader configuration has been modified to place the display
> > > > controllers into SMMU bypass until otherwise configured by the kernel
> > > > -- which the kernel does in tegra_mc_probe_device.
> > > >
> > > > I think that means there is still potential for an issue where the
> > > > display continues to be on between tegra_mc_probe_device and tegradrm
> > > > reconfiguring it. However, I cannot reproduce that happening -- most
> > > > likely the display is being turned off before that because of a clock
> > > > or power domain being turned off.
> > > >
> > > > In any case, this means that we no longer need to pass the
> > > > framebuffer's information to the kernel. I think it would be good to
> > > > have some clarity to ensure the issue described above cannot happen,
> > > > but otherwise we should be able to enable IOMMU.
> > >
> > > The problem would happen if you enable some sort of early framebuffer
> > > support, such as simple-drm or simple-framebuffer. Maybe even efifb. I
> > > think it'd still be worth getting the iommu-addresses code into r35 if
> > > for nothing else but to have a bit more of a safety buffer for the
> > > future.
> > >
> > > If we don't and for some reason decide that we want early framebuffer
> > > support, it might be too late to get UEFI updated for Tegra194. I recall
> > > that the UEFI code for Tegra194 is different from the one for Tegra234,
> > > so it is probably not as trivial as a simple cherry-pick, but I'll try
> > > to do some digging and find the code that does this for Xavier.
> >
> > Any updates on this?
>
> FWIW, in my testing with L4T versions with UEFI firmware, I'm not seeing
> any issues even if efifb is enabled. My inclination would be to merge,
> and we can work on issues related to early framebuffer separately.
>
> Outside adding support to r35, one option is to make it so TegraDRM has
> to explicitly call tegra_mc_probe_device (not necessarily directly) when
> it has quiesced the hardware during probe. This would not allow seamless
> early framebuffer transition, but otherwise it should work. Implementing
> this for tegra-smmu would also allow us to get rid of the IOMMU API
> paths in TegraDRM and Host1x, which would be a great boon.
I did most of this work a long time ago and L4T just wasn't ready yet to
make use of all this cleanup potential. We can probably go find most of
the code and it might still be largely applicable.
It's a bit disappointing that this didn't go anywhere for the longest
time and all of a sudden most of it just seems to be irrelevant.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/4] soc: rockchip: rk3588: add SYS_GRF SOC_CON6 register offset
From: Nicolas Frattaroli @ 2026-04-07 8:10 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Daniele Briguglio
Cc: linux-clk, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Daniele Briguglio
In-Reply-To: <20260320-rk3588-mclk-gate-grf-v3-3-980338eacd2c@superkali.me>
On Friday, 20 March 2026 11:34:15 Central European Summer Time Daniele Briguglio wrote:
> Add the RK3588_SYSGRF_SOC_CON6 register offset to the RK3588 GRF
> header. This register contains the I2S MCLK output to IO gate bits,
> needed by the clock driver.
>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
> ---
> include/soc/rockchip/rk3588_grf.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/soc/rockchip/rk3588_grf.h b/include/soc/rockchip/rk3588_grf.h
> index 02a7b2432d99..db0092fc66ad 100644
> --- a/include/soc/rockchip/rk3588_grf.h
> +++ b/include/soc/rockchip/rk3588_grf.h
> @@ -19,4 +19,6 @@
> /* Whether the LPDDR5 is in 2:1 (= 0) or 4:1 (= 1) CKR a.k.a. DQS mode */
> #define RK3588_PMUGRF_OS_REG6_LP5_CKR BIT(0)
>
> +#define RK3588_SYSGRF_SOC_CON6 0x0318
> +
> #endif /* __SOC_RK3588_GRF_H */
>
>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Verified the definition by comparing it to hardware documentation,
it checks out.
^ 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