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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLEfBGQsJw6Vn2FnCrMOEmwhTq9ro2Qca7bBAM_UKZ6-g@mail.gmail.com>
Date: Wed, 4 Sep 2024 12:49:49 -0500
From: Rob Herring <robh@...nel.org>
To: Ayush Singh <ayush@...gleboard.org>
Cc: Michael Walle <mwalle@...nel.org>, Mark Brown <broonie@...nel.org>, 
	Vaishnav M A <vaishnav@...gleboard.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Derek Kiernan <derek.kiernan@....com>, 
	Dragan Cvetic <dragan.cvetic@....com>, Arnd Bergmann <arnd@...db.de>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Nishanth Menon <nm@...com>, 
	Vignesh Raghavendra <vigneshr@...com>, Tero Kristo <kristo@...nel.org>, Andrew Lunn <andrew@...n.ch>, 
	jkridner@...gleboard.org, robertcnelson@...gleboard.org, 
	linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 1/7] dt-bindings: connector: Add mikrobus-connector

On Wed, Sep 4, 2024 at 12:09 PM Ayush Singh <ayush@...gleboard.org> wrote:
>
> >> gpio-map is what you are looking for. It's documented in the DT spec.
> >> It was created exactly for this purpose of remapping GPIO lines on a
> >> connector.
> >>
> >> Rob
>
>
> Hi. I found docs on nexus nodes [1] and tried using it for mikroBUS, but
> it does not seem to be working. Here is my connector:
>
> ```
>
>      mikrobus_gpio0: mikrobus-gpio0 {
>          #gpio-cells = <2>;
>          gpio-map =
>          <0 0 &main_gpio1 11 0>, <1 0 &main_gpio1 9 0>,
>          <2 0 &main_gpio1 24 0>, <3 0 &main_gpio1 25 0>,
>          <4 0 &main_gpio1 22 0>, <5 0 &main_gpio1 23 0>,
>          <6 0 &main_gpio1 7 0>, <7 0 &main_gpio1 8 0>,
>          <8 0 &main_gpio1 14 0>, <9 0 &main_gpio1 13 0>,
>          <10 0 &main_gpio1 12 0>, <11 0 &main_gpio1 10 0>;
>          gpio-map-mask = <0xf 0x0>;
>          gpio-map-pass-thru = <0x0 0x1>;
>      };
>
> ...
>
> &main_uart5 {
>      status = "okay";
>      pinctrl-names = "default";
>      pinctrl-0 = <&mikrobus_uart_pins_default>;
>
>      gnss {
>          compatible = "u-blox,neo-8";
>          reset-gpios = <&mikrobus_gpio0 10 GPIO_ACTIVE_LOW>;
>      };
> };
>
> ```
>
>
> After some fdtdump, I can see that at least the dtc compiler does not
> seem to do the forwarding at dt compile time. Here is the dump:

dtc knows nothing about it.

> ```
>
> mikrobus-gpio0 {
>          #gpio-cells = <0x00000002>;
>          gpio-map = <0x00000000 0x00000000 0x00000025 0x0000000b
> 0x00000000 0x00000001 0x00000000 0x00000025 0x00000009 0x00000000
> 0x00000002 0x00000000 0x00000025 0x00000018 0x00000000 0x00000003
> 0x00000000 0x00000025 0x00000019 0x00000000 0x00000004 0x00000000
> 0x00000025 0x00000016 0x00000000 0x00000005 0x00000000 0x00000025
> 0x00000017 0x00000000 0x00000006 0x00000000 0x00000025 0x00000007
> 0x00000000 0x00000007 0x00000000 0x00000025 0x00000008 0x00000000
> 0x00000008 0x00000000 0x00000025 0x0000000e 0x00000000 0x00000009
> 0x00000000 0x00000025 0x0000000d 0x00000000 0x0000000a 0x00000000
> 0x00000025 0x0000000c 0x00000000 0x0000000b 0x00000000 0x00000025
> 0x0000000a 0x00000000>;
>          gpio-map-mask = <0x0000000f 0x00000000>;
>          gpio-map-pass-thru = <0x00000000 0x00000001>;
>          phandle = <0x0000000e>;
>      };

You might need "gpio-controller" here. Though if you do, I think
that's a mistake in the kernel. It should work like interrupt-map and
generally you have either interrupt-controller or interrupt-map, but
not both (though that is allowed now too).

> ...
>
> serial@...0000 {
>              compatible = "ti,am64-uart", "ti,am654-uart";
>              reg = <0x00000000 0x02850000 0x00000000 0x00000100>;
>              interrupts = <0x00000000 0x000000b7 0x00000004>;
>              power-domains = <0x00000003 0x0000009c 0x00000001>;
>              clocks = <0x00000002 0x0000009c 0x00000000>;
>              clock-names = "fclk";
>              status = "okay";
>              pinctrl-names = "default";
>              pinctrl-0 = <0x0000000d>;
>              phandle = <0x00000081>;
>              gnss {
>                  compatible = "u-blox,neo-8";
>                  reset-gpios = <0x0000000e 0x0000000a 0x00000001>;
>              };
>   };
>
> ```
>
>
> So I am a bit unsure. Is the dtc parser in the kernel supposed to do the

No such thing as "dtc parser in the kernel".

> mapping, or is it supposed to be done by `dtc` at compile time?

No.

> Maybe we
> do not have support for it in upstream kernel yet?

Yes, there is upstream support. Grep for of_parse_phandle_with_args_map.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ