lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
 <ZQ2PR01MB1307BD49C0A49DAD3AA76049E600A@ZQ2PR01MB1307.CHNPR01.prod.partner.outlook.cn>
Date: Sat, 21 Dec 2024 04:15:56 +0000
From: Hal Feng <hal.feng@...rfivetech.com>
To: E Shattow <e@...eshell.de>, Conor Dooley <conor@...nel.org>
CC: Emil Renner Berthing <kernel@...il.dk>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Paul Walmsley
	<paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
	<aou@...s.berkeley.edu>, Jianlong Huang <jianlong.huang@...rfivetech.com>,
	Jisheng Zhang <jszhang@...nel.org>, Conor Dooley
	<conor.dooley@...rochip.com>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Emil Renner Berthing
	<emil.renner.berthing@...onical.com>
Subject: RE: [PATCH] riscv: dts: starfive: jh7110-common: Use named definition
 for mmc1 card detect

> On 19.12.24 17:42, E Shattow wrote: 
> On 12/17/24 10:33, Conor Dooley wrote:
> > On Mon, Dec 16, 2024 at 07:25:59PM -0800, E Shattow wrote:
> >> Hi, Hal
> >>
> >> On 12/16/24 18:02, Hal Feng wrote:
> >>>> On 17.12.24 04:13, Conor Dooley wrote:
> >>>> On Mon, 09 Dec 2024 20:06:46 -0800, E Shattow wrote:
> >>>>> Use named definition for mmc1 card detect GPIO instead of numeric
> literal.
> >>>>>
> >>>>>
> >>>>
> >>>> Applied to riscv-dt-for-next, thanks!
> >>>>
> >>>> [1/1] riscv: dts: starfive: jh7110-common: Use named definition for
> >>>> mmc1 card detect
> >>>>         https://git.kernel.org/conor/c/c96f15d79172
> >>>
> >>> No, here "41" means the GPIO number, but GPI_SYS_SDIO1_CD means
> the
> >>> multiplexed function and should be used by pinctrl pinmux not gpio
> subsystem.
> >>> Although GPI-SYS_SDIO1_CD is numerically the same as 41.
> >>>
> >>> Best regards,
> >>> Hal
> >>
> >> You're right, Hal. I'm confused trying to make sense of this.
> >>
> >>  From dts/upstream/src/riscv/starfive/jh7110-pinfunc.h:
> >>
> >> "gpio nr:  gpio number, 0 - 63"

This place needs to be updated.

For sysgpio: 
gpio nr:  gpio number, 0 - 63 when using GPIOMUX(n, ...),
                6 - 63 or 82 when using PINMUX(n, 1 or 2),  64 - 74 or 89 - 94 when using PINMUX(n, 0)

For aongpio: 
gpio nr:  gpio number, 0 - 3 when using GPIOMUX(n, ...),
                0 - 5 when using PINMUX(n, 0)

> >>
> >> And yet in dts/upstream/src/riscv/starfive/jh7110-common.dtsi there's:
> >>
> >>>                         pinmux = <PINMUX(64, 0)>,
> >>>                                  <PINMUX(65, 0)>,
> >>>                                  <PINMUX(66, 0)>,
> >>>                                  <PINMUX(67, 0)>,
> >>>                                  <PINMUX(68, 0)>,
> >>>                                  <PINMUX(69, 0)>,
> >>>                                  <PINMUX(70, 0)>,
> >>>                                  <PINMUX(71, 0)>,
> >>>                                  <PINMUX(72, 0)>,
> >>>                                  <PINMUX(73, 0)>;
> >>
> >>
> >> Loosely on the subject of MMC interface and GPIO numbering, what is
> >> the above code doing? These are not GPIO numbers 0-63 so what is this?
> >>
> >> I'm trying to understand this so I can write the Mars CM (-Lite) dts.
> >>
> >
> >
> >> Conor, and Hal: sorry for the mistake there.
> >
> > No worries, I've dropped the patch.
> 
> Okay. I was able to find pad definitions in the vendor Linux source:
> https://github.com/starfive-
> tech/linux/blob/5dfc879916d946dcc2521ef1eccd1d8bfb06a75e/include/dt-
> bindings/pinctrl/starfive%2Cjh7110-pinfunc.h
> 
> There are definitions for GPIO indexes beyond 0-63:
> 
>  > #define   PAD_SD0_CLK     64
>  > #define   PAD_SD0_CMD     65
>  > #define   PAD_SD0_DATA0   66
>  > #define   PAD_SD0_DATA1   67
>  > #define   PAD_SD0_DATA2   68
>  > #define   PAD_SD0_DATA3   69
>  > #define   PAD_SD0_DATA4   70
>  > #define   PAD_SD0_DATA5   71
>  > #define   PAD_SD0_DATA6   72
>  > #define   PAD_SD0_DATA7   73
>  > #define   PAD_SD0_STRB    74
>  > #define   PAD_GMAC1_MDC   75
>  > #define   PAD_GMAC1_MDIO  76
>  > #define   PAD_GMAC1_RXD0  77
>  > #define   PAD_GMAC1_RXD1  78
>  > #define   PAD_GMAC1_RXD2  79
>  > #define   PAD_GMAC1_RXD3  80
>  > #define   PAD_GMAC1_RXDV  81
>  > #define   PAD_GMAC1_RXC   82
>  > #define   PAD_GMAC1_TXD0  83
>  > #define   PAD_GMAC1_TXD1  84
>  > #define   PAD_GMAC1_TXD2  85
>  > #define   PAD_GMAC1_TXD3  86
>  > #define   PAD_GMAC1_TXEN  87
>  > #define   PAD_GMAC1_TXC   88
>  > #define   PAD_QSPI_SCLK   89
>  > #define   PAD_QSPI_CSn0   90
>  > #define   PAD_QSPI_DATA0  91
>  > #define   PAD_QSPI_DATA1  92
>  > #define   PAD_QSPI_DATA2  93
>  > #define   PAD_QSPI_DATA3  94

Yes, these pins with indexes beyond 0-63 are actually existed and
they are set to unchangeable fixed functions.

> 
> Where I got lost is that these are in mainline with include/dt-
> bindings/pinctrl/starfive,jh7110-pinctrl.h
> 
> I did not find these pad definitions above index 63 mentioned in the
> JH7110 Technical Reference Manual.
> 
> Is it worth sending a patch to use those definitions in jh7110-common.dtsi?

Yeah, actually it will be more readable to use the definitions to replace pin 64~94.

Best regards,
Hal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ