Message ID | 20230623080135.15696-1-fabrizio.castro.jz@renesas.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp5614986vqr; Fri, 23 Jun 2023 01:22:30 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7td84Qsnjb+IreR/3vQapDHDsTVIrXHQ70D2A1KucETGNvLkwAQSmsspumF0lo3d1517D+ X-Received: by 2002:a05:6808:211e:b0:39e:ff3d:afa4 with SMTP id r30-20020a056808211e00b0039eff3dafa4mr15626768oiw.52.1687508550555; Fri, 23 Jun 2023 01:22:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687508550; cv=none; d=google.com; s=arc-20160816; b=vRoz+BkYt6g5kndYWdTancryHtSWwHgA4dBxS90s9lqi2vgwKZmfMCWtHb2oEwIAAK pAbU/LPYF6vMfjDBeu5JRfNG2KrPHYPegnOVn1lx3yLFrvUc8D0y5ophvfsnJH/npOmI 1PJatiGBS2jGdFvDOSW07gaJpHdpdNOZSnuhx6JDnHHgGZ7lGaN1COFdvySTY9EosvWq mAd6WcJREPLU2d30hcS7mpNMR+r58i4ChcBIkkDfqI5YtTESjsBhzJr87eVJVkCPPhV5 Mm8MWjKCbe6TskHZXzoXagU8BpYPKR3x3RC3rL3bGkewwiqC0LcO8zYbk8vcHcHkdDQN 93Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=pESOncZiMRucpm/Vds3x3Hpx0PT/GROOrjYaL7StfTw=; b=heqdMC43Rt9w6rmQMxwvKVnixNXPyngDnywGqKeMBA5R2RIgQpwEkPkio8wVw60s4y F1BGnTG2QhHjJ7T7jWXITvMx4n2b3iRpeEhAa4ERr1d/5r2ZCA9WLrA1jrpPln9nNDmt wHY/P3yFc+ix1NgFvSjYsJvP2BvvjErs7sG7HCjohqpDnPuKz1V0pZiZy4HysVWljf7X aI1SbDju6g1RErTjmXDkkuoqXpT51Pu8sAuZ0nKMm7g3kBTPbuyy4C4LnwSfvjAVvGvS w5Mn4+dubHn60hpYQWmDlvE+xIIQcds21cUi2XLxxND4deB0ccp8dGMscV8rvbm6XPEb 5kJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=renesas.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pi14-20020a17090b1e4e00b0025de453ee4csi1624615pjb.168.2023.06.23.01.22.17; Fri, 23 Jun 2023 01:22:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=renesas.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231238AbjFWIBs (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Fri, 23 Jun 2023 04:01:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230170AbjFWIBr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 23 Jun 2023 04:01:47 -0400 Received: from relmlie6.idc.renesas.com (relmlor2.renesas.com [210.160.252.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5DC4E1BE2; Fri, 23 Jun 2023 01:01:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="6.01,151,1684767600"; d="scan'208";a="168666974" Received: from unknown (HELO relmlir5.idc.renesas.com) ([10.200.68.151]) by relmlie6.idc.renesas.com with ESMTP; 23 Jun 2023 17:01:44 +0900 Received: from mulinux.home (unknown [10.226.93.17]) by relmlir5.idc.renesas.com (Postfix) with ESMTP id 838C4400B9F5; Fri, 23 Jun 2023 17:01:40 +0900 (JST) From: Fabrizio Castro <fabrizio.castro.jz@renesas.com> To: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Geert Uytterhoeven <geert+renesas@glider.be> Cc: Fabrizio Castro <fabrizio.castro.jz@renesas.com>, Magnus Damm <magnus.damm@gmail.com>, linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Paterson <Chris.Paterson2@renesas.com>, Biju Das <biju.das@bp.renesas.com>, Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Subject: [PATCH] arm64: dts: renesas: rzv2mevk2: Fix eMMC/SDHI pinctrl names Date: Fri, 23 Jun 2023 09:01:35 +0100 Message-Id: <20230623080135.15696-1-fabrizio.castro.jz@renesas.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.1 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769480965968867522?= X-GMAIL-MSGID: =?utf-8?q?1769480965968867522?= |
Series |
arm64: dts: renesas: rzv2mevk2: Fix eMMC/SDHI pinctrl names
|
|
Commit Message
Fabrizio Castro
June 23, 2023, 8:01 a.m. UTC
The original commit uses the same names ("data" and "ctrl")
for the subnodes of pinctrl definitions for both eMMC and
SDHI0 (emmc_pins, sdhi0_pins, and sdhi0_pins_uhs) leading to
the below issue:
pinctrl-rzv2m b6250000.pinctrl: pin P8_2 already requested by 85000000.mmc; cannot claim for 85020000.mmc
pinctrl-rzv2m b6250000.pinctrl: pin-130 (85020000.mmc) status -22
renesas_sdhi_internal_dmac 85020000.mmc: Error applying setting, reverse things back
This commit fixes the problem by making the names for the
pinctrl subnodes of eMMC and SDHI0 unique.
Fixes: b6c0be722b0c ("arm64: dts: renesas: rzv2mevk2: Add uSD card and eMMC support")
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
.../arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
Comments
Hi Fabrizio, CC pinctrl Thanks for your patch! On Fri, Jun 23, 2023 at 10:01 AM Fabrizio Castro <fabrizio.castro.jz@renesas.com> wrote: > The original commit uses the same names ("data" and "ctrl") > for the subnodes of pinctrl definitions for both eMMC and > SDHI0 (emmc_pins, sdhi0_pins, and sdhi0_pins_uhs) leading to That should be fine, as the parents of these subnodes do have different names? > the below issue: > > pinctrl-rzv2m b6250000.pinctrl: pin P8_2 already requested by 85000000.mmc; cannot claim for 85020000.mmc > pinctrl-rzv2m b6250000.pinctrl: pin-130 (85020000.mmc) status -22 > renesas_sdhi_internal_dmac 85020000.mmc: Error applying setting, reverse things back To me, that sounds like a bug in the pinctrl core. Or am I missing something? > This commit fixes the problem by making the names for the > pinctrl subnodes of eMMC and SDHI0 unique. > > Fixes: b6c0be722b0c ("arm64: dts: renesas: rzv2mevk2: Add uSD card and eMMC support") > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> > --- > .../arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts b/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts > index 39fe3f94991e..11c5cffea5a5 100644 > --- a/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts > +++ b/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts > @@ -167,7 +167,7 @@ &i2c2 { > > &pinctrl { > emmc_pins: emmc { > - data { > + emmc_data { > pinmux = <RZV2M_PORT_PINMUX(0, 0, 2)>, /* MMDAT0 */ > <RZV2M_PORT_PINMUX(0, 1, 2)>, /* MMDAT1 */ > <RZV2M_PORT_PINMUX(0, 2, 2)>, /* MMDAT2 */ > @@ -179,7 +179,7 @@ data { > power-source = <1800>; > }; > > - ctrl { > + emmc_ctrl { > pinmux = <RZV2M_PORT_PINMUX(0, 10, 2)>, /* MMCMD */ > <RZV2M_PORT_PINMUX(0, 11, 2)>; /* MMCLK */ > power-source = <1800>; > @@ -197,7 +197,7 @@ i2c2_pins: i2c2 { > }; > > sdhi0_pins: sd0 { > - data { > + sd0_data { > pinmux = <RZV2M_PORT_PINMUX(8, 2, 1)>, /* SD0DAT0 */ > <RZV2M_PORT_PINMUX(8, 3, 1)>, /* SD0DAT1 */ > <RZV2M_PORT_PINMUX(8, 4, 1)>, /* SD0DAT2 */ > @@ -205,20 +205,20 @@ data { > power-source = <3300>; > }; > > - ctrl { > + sd0_ctrl { > pinmux = <RZV2M_PORT_PINMUX(8, 0, 1)>, /* SD0CMD */ > <RZV2M_PORT_PINMUX(8, 1, 1)>; /* SD0CLK */ > power-source = <3300>; > }; > > - cd { > + sd0_cd { > pinmux = <RZV2M_PORT_PINMUX(8, 7, 1)>; /* SD0CD */ > power-source = <3300>; > }; > }; > > sdhi0_pins_uhs: sd0-uhs { > - data { > + sd0_uhs_data { > pinmux = <RZV2M_PORT_PINMUX(8, 2, 1)>, /* SD0DAT0 */ > <RZV2M_PORT_PINMUX(8, 3, 1)>, /* SD0DAT1 */ > <RZV2M_PORT_PINMUX(8, 4, 1)>, /* SD0DAT2 */ > @@ -226,13 +226,13 @@ data { > power-source = <1800>; > }; > > - ctrl { > + sd0_uhs_ctrl { > pinmux = <RZV2M_PORT_PINMUX(8, 0, 1)>, /* SD0CMD */ > <RZV2M_PORT_PINMUX(8, 1, 1)>; /* SD0CLK */ > power-source = <1800>; > }; > > - cd { > + sd0_uhs_cd { > pinmux = <RZV2M_PORT_PINMUX(8, 7, 1)>; /* SD0CD */ > power-source = <1800>; > }; Gr{oetje,eeting}s, Geert
Hi Geert, Thanks for your reply. > From: Geert Uytterhoeven <geert@linux-m68k.org> > Subject: Re: [PATCH] arm64: dts: renesas: rzv2mevk2: Fix eMMC/SDHI > pinctrl names > > Hi Fabrizio, > > CC pinctrl > > Thanks for your patch! > > On Fri, Jun 23, 2023 at 10:01 AM Fabrizio Castro > <fabrizio.castro.jz@renesas.com> wrote: > > The original commit uses the same names ("data" and "ctrl") > > for the subnodes of pinctrl definitions for both eMMC and > > SDHI0 (emmc_pins, sdhi0_pins, and sdhi0_pins_uhs) leading to > > That should be fine, as the parents of these subnodes do have > different > names? That's what I originally thought as well. > > > the below issue: > > > > pinctrl-rzv2m b6250000.pinctrl: pin P8_2 already requested by > 85000000.mmc; cannot claim for 85020000.mmc > > pinctrl-rzv2m b6250000.pinctrl: pin-130 (85020000.mmc) status -22 > > renesas_sdhi_internal_dmac 85020000.mmc: Error applying setting, > reverse things back > > To me, that sounds like a bug in the pinctrl core. > Or am I missing something? I am not sure if this behaviour is intended or not, I'll probably have a deeper look into it later on if I have time, but right now (with the current state of things) this patch is necessary. It doesn't hurt to have unique names for subnodes, and looking through Renesas device trees, the names for the subnodes are unique for the other platforms. By the way, I didn't see the problem when I tested the original patch (I still have the logs of the original testing, that was based 6.2.0-rc3+, and all was working well), therefore it'd be good to look further into this later on, for future reference. Cheers, Fab > > > This commit fixes the problem by making the names for the > > pinctrl subnodes of eMMC and SDHI0 unique. > > > > Fixes: b6c0be722b0c ("arm64: dts: renesas: rzv2mevk2: Add uSD card > and eMMC support") > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> > > --- > > .../arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts | 16 ++++++++----- > --- > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts > b/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts > > index 39fe3f94991e..11c5cffea5a5 100644 > > --- a/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts > > +++ b/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts > > @@ -167,7 +167,7 @@ &i2c2 { > > > > &pinctrl { > > emmc_pins: emmc { > > - data { > > + emmc_data { > > pinmux = <RZV2M_PORT_PINMUX(0, 0, 2)>, /* > MMDAT0 */ > > <RZV2M_PORT_PINMUX(0, 1, 2)>, /* > MMDAT1 */ > > <RZV2M_PORT_PINMUX(0, 2, 2)>, /* > MMDAT2 */ > > @@ -179,7 +179,7 @@ data { > > power-source = <1800>; > > }; > > > > - ctrl { > > + emmc_ctrl { > > pinmux = <RZV2M_PORT_PINMUX(0, 10, 2)>, /* > MMCMD */ > > <RZV2M_PORT_PINMUX(0, 11, 2)>; /* > MMCLK */ > > power-source = <1800>; > > @@ -197,7 +197,7 @@ i2c2_pins: i2c2 { > > }; > > > > sdhi0_pins: sd0 { > > - data { > > + sd0_data { > > pinmux = <RZV2M_PORT_PINMUX(8, 2, 1)>, /* > SD0DAT0 */ > > <RZV2M_PORT_PINMUX(8, 3, 1)>, /* > SD0DAT1 */ > > <RZV2M_PORT_PINMUX(8, 4, 1)>, /* > SD0DAT2 */ > > @@ -205,20 +205,20 @@ data { > > power-source = <3300>; > > }; > > > > - ctrl { > > + sd0_ctrl { > > pinmux = <RZV2M_PORT_PINMUX(8, 0, 1)>, /* > SD0CMD */ > > <RZV2M_PORT_PINMUX(8, 1, 1)>; /* > SD0CLK */ > > power-source = <3300>; > > }; > > > > - cd { > > + sd0_cd { > > pinmux = <RZV2M_PORT_PINMUX(8, 7, 1)>; /* > SD0CD */ > > power-source = <3300>; > > }; > > }; > > > > sdhi0_pins_uhs: sd0-uhs { > > - data { > > + sd0_uhs_data { > > pinmux = <RZV2M_PORT_PINMUX(8, 2, 1)>, /* > SD0DAT0 */ > > <RZV2M_PORT_PINMUX(8, 3, 1)>, /* > SD0DAT1 */ > > <RZV2M_PORT_PINMUX(8, 4, 1)>, /* > SD0DAT2 */ > > @@ -226,13 +226,13 @@ data { > > power-source = <1800>; > > }; > > > > - ctrl { > > + sd0_uhs_ctrl { > > pinmux = <RZV2M_PORT_PINMUX(8, 0, 1)>, /* > SD0CMD */ > > <RZV2M_PORT_PINMUX(8, 1, 1)>; /* > SD0CLK */ > > power-source = <1800>; > > }; > > > > - cd { > > + sd0_uhs_cd { > > pinmux = <RZV2M_PORT_PINMUX(8, 7, 1)>; /* > SD0CD */ > > power-source = <1800>; > > }; > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- > geert@linux-m68k.org > > In personal conversations with technical people, I call myself a > hacker. But > when I'm talking to journalists I just say "programmer" or something > like that. > -- Linus Torvalds
On Fri, Jun 23, 2023 at 10:40 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Fri, Jun 23, 2023 at 10:01 AM Fabrizio Castro > <fabrizio.castro.jz@renesas.com> wrote: > > the below issue: > > > > pinctrl-rzv2m b6250000.pinctrl: pin P8_2 already requested by 85000000.mmc; cannot claim for 85020000.mmc > > pinctrl-rzv2m b6250000.pinctrl: pin-130 (85020000.mmc) status -22 > > renesas_sdhi_internal_dmac 85020000.mmc: Error applying setting, reverse things back > > To me, that sounds like a bug in the pinctrl core. > Or am I missing something? The pin control core tracks on a per-pin basis, it has no clue about the name of certain dt nodes. This bug would be in the DT parsing code for the different states I think, and rzv2m is not using the core helpers for this but rather rzv2m_dt_subnode_to_map() etc. Yours, Linus Walleij
Hi Linus, Fabrizio, On Sat, Jun 24, 2023 at 9:12 PM Linus Walleij <linus.walleij@linaro.org> wrote: > On Fri, Jun 23, 2023 at 10:40 AM Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > On Fri, Jun 23, 2023 at 10:01 AM Fabrizio Castro > > <fabrizio.castro.jz@renesas.com> wrote: > > > pinctrl-rzv2m b6250000.pinctrl: pin P8_2 already requested by 85000000.mmc; cannot claim for 85020000.mmc > > > pinctrl-rzv2m b6250000.pinctrl: pin-130 (85020000.mmc) status -22 > > > renesas_sdhi_internal_dmac 85020000.mmc: Error applying setting, reverse things back I managed to reproduce the issue[*], and devised a fix, which I will send shortly. > > To me, that sounds like a bug in the pinctrl core. > > Or am I missing something? > > The pin control core tracks on a per-pin basis, it has no clue about > the name of certain dt nodes. > > This bug would be in the DT parsing code for the different states > I think, and rzv2m is not using the core helpers for this but > rather rzv2m_dt_subnode_to_map() etc. Indeed, there's an issue in rzv2m_dt_subnode_to_map(): it registers groups and functions using just the subnode names, which may not be unique. When this happens, they are ignored silently. $ cat /sys/kernel/debug/pinctrl/b6250000.pinctrl/pingroups registered pin groups: group: data pin 130 (P8_2) pin 131 (P8_3) pin 132 (P8_4) pin 133 (P8_5) group: ctrl pin 128 (P8_0) pin 129 (P8_1) group: cd pin 135 (P8_7) $ cat /sys/kernel/debug/pinctrl/b6250000.pinctrl/pinmux-functions function 0: data, groups = [ data ] function 1: ctrl, groups = [ ctrl ] function 2: cd, groups = [ cd ] You can see this by adding checks in the pin control core: --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -639,8 +639,10 @@ int pinctrl_generic_add_group(struct pinctrl_dev *pctldev, const char *name, return -EINVAL; selector = pinctrl_generic_group_name_to_selector(pctldev, name); - if (selector >= 0) + if (selector >= 0) { + pr_err("Duplicate group name %s (selector %d)\n", name, selector); return selector; + } selector = pctldev->num_groups; --- a/drivers/pinctrl/pinmux.c +++ b/drivers/pinctrl/pinmux.c @@ -878,8 +878,10 @@ int pinmux_generic_add_function(struct pinctrl_dev *pctldev, return -EINVAL; selector = pinmux_func_name_to_selector(pctldev, name); - if (selector >= 0) + if (selector >= 0) { +pr_err("Duplicate function name %s (selector %d)\n", name, selector); return selector; + } selector = pctldev->num_functions; Is there any special reason why such duplicates are just ignored, and not flagged as an error? The RZ/G2L and RZ/N1 pin control drivers have the same issue, but it is not triggered on these platforms (yet), as their DTS files either do not use subnodes, or use unique subnode names. The RZ/A1 and RZ/A2 pin control drivers are not affected, as they do not support subnodes. The StarFive JH7100 pin control driver does it right, by constructing group/function names from both the node and the subnode names. [*] As I do not have an RZ/V2M board, I added pin control, eMMC, and SDHI snippets from RZ/V2M to the Koelsch DTS, and modified the drivers to not touch the non-existing hardware. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
diff --git a/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts b/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts index 39fe3f94991e..11c5cffea5a5 100644 --- a/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts +++ b/arch/arm64/boot/dts/renesas/r9a09g011-v2mevk2.dts @@ -167,7 +167,7 @@ &i2c2 { &pinctrl { emmc_pins: emmc { - data { + emmc_data { pinmux = <RZV2M_PORT_PINMUX(0, 0, 2)>, /* MMDAT0 */ <RZV2M_PORT_PINMUX(0, 1, 2)>, /* MMDAT1 */ <RZV2M_PORT_PINMUX(0, 2, 2)>, /* MMDAT2 */ @@ -179,7 +179,7 @@ data { power-source = <1800>; }; - ctrl { + emmc_ctrl { pinmux = <RZV2M_PORT_PINMUX(0, 10, 2)>, /* MMCMD */ <RZV2M_PORT_PINMUX(0, 11, 2)>; /* MMCLK */ power-source = <1800>; @@ -197,7 +197,7 @@ i2c2_pins: i2c2 { }; sdhi0_pins: sd0 { - data { + sd0_data { pinmux = <RZV2M_PORT_PINMUX(8, 2, 1)>, /* SD0DAT0 */ <RZV2M_PORT_PINMUX(8, 3, 1)>, /* SD0DAT1 */ <RZV2M_PORT_PINMUX(8, 4, 1)>, /* SD0DAT2 */ @@ -205,20 +205,20 @@ data { power-source = <3300>; }; - ctrl { + sd0_ctrl { pinmux = <RZV2M_PORT_PINMUX(8, 0, 1)>, /* SD0CMD */ <RZV2M_PORT_PINMUX(8, 1, 1)>; /* SD0CLK */ power-source = <3300>; }; - cd { + sd0_cd { pinmux = <RZV2M_PORT_PINMUX(8, 7, 1)>; /* SD0CD */ power-source = <3300>; }; }; sdhi0_pins_uhs: sd0-uhs { - data { + sd0_uhs_data { pinmux = <RZV2M_PORT_PINMUX(8, 2, 1)>, /* SD0DAT0 */ <RZV2M_PORT_PINMUX(8, 3, 1)>, /* SD0DAT1 */ <RZV2M_PORT_PINMUX(8, 4, 1)>, /* SD0DAT2 */ @@ -226,13 +226,13 @@ data { power-source = <1800>; }; - ctrl { + sd0_uhs_ctrl { pinmux = <RZV2M_PORT_PINMUX(8, 0, 1)>, /* SD0CMD */ <RZV2M_PORT_PINMUX(8, 1, 1)>; /* SD0CLK */ power-source = <1800>; }; - cd { + sd0_uhs_cd { pinmux = <RZV2M_PORT_PINMUX(8, 7, 1)>; /* SD0CD */ power-source = <1800>; };