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: <06a4e5fd-3d26-4923-bcbf-0bdd66d756c4@linux.dev>
Date: Mon, 6 May 2024 10:45:30 -0400
From: Sean Anderson <sean.anderson@...ux.dev>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Michal Simek <michal.simek@....com>, linux-gpio@...r.kernel.org,
 Krishna Potthuri <sai.krishna.potthuri@....com>,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 devicetree@...r.kernel.org
Subject: Re: [PATCH 0/2] pinctrl: zynqmp: Support muxing individual pins

On 5/6/24 02:43, Linus Walleij wrote:
> On Fri, May 3, 2024 at 6:22 PM Sean Anderson <sean.anderson@...ux.dev> wrote:
> 
>> This series adds support for muxing individual pins, instead of
>> requiring groups to be muxed together. See [1] for additional
>> discussion.
>>
>> [1] https://lore.kernel.org/linux-arm-kernel/5bb0dc7e-4c89-4f3d-abc6-41ae9ded5ae9@linux.dev/
> 
> The way I usually would recommend to solve this would be to
> define new subgroups, so e.g. for a UARTS:
> 
> uart0_grp = pin_rx, pin_tx, pin_cts, pin_dts, pin_dcd;
> 
> And today this would be used like that:
> 
> mux0:
>     function = "uart0";
>     groups = "uart0_grp";
> 
> Then we realize that not everyone need all the modem
> control signals provided. What to do. Well this:
> 
> uart0_rxtx_grp = pin_rx, pin_tx:
> uart0_modem_grp = pin_cts, pin_dts, pin_dcd;
> 
> mux0:
>     function = "uart0";
>     groups = "uart0_rxtx_grp";
> 
> Now the CTS, DTS, DCD pins can be reused for something
> else such as GPIO.
> 
> I *know* that this breaks ABI: the driver group definitions change
> and the device tree needs to be changed too.
> 
> This only matters if the users have a habit of distributing the
> kernel and DTB separately so a new kernel needs to support
> and old DTB. This varies in how much control we have but I
> think for Xilinx systems the kernel and DTB are always updated
> in lockstep, so it really does not matter?

Well, the pin groups are actually defined in the PMU firmware. And
frankly, I don't see the point of pin "groups" when there are not actual
pin groups at the hardware level. The pins can all be muxed
individually, so there's no point in adding artificial groups on top.
Just mux the pins like the hardware allows and everything is easy. Cuts
down on the absurd number of strings too.

--Sean

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ