linux-kernel - Re: [PATCH 0/8] pinctrl: Add T-Head TH1520 SoC pin controllers

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: <CACRpkdbNwpiaXKgkZfq6cw5LuW7RGxCuQvF4n3F0YCcUqKSf0A@mail.gmail.com>
Date: Thu, 5 Sep 2024 13:46:35 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Drew Fustini <dfustini@...storrent.com>
Cc: Drew Fustini <drew@...7.com>, Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Emil Renner Berthing <emil.renner.berthing@...onical.com>, 
	Thomas Bonnefille <thomas.bonnefille@...tlin.com>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	linux-riscv@...ts.infradead.org, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/8] pinctrl: Add T-Head TH1520 SoC pin controllers

On Tue, Sep 3, 2024 at 6:08 AM Drew Fustini <dfustini@...storrent.com> wrote:

> This adds a pin control driver created by Emil for the T-Head TH1520
> RISC-V SoC used on the Lichee Pi 4A and BeagleV Ahead boards and
> updates the device trees to make use of it.
>
> Emil's series from January used separate compatibles for each pin
> controller instance. Rob did not think this was appropriate because the
> programming model is the same for each instance.
>
> This series takes a different approach. There is now only a single
> compatible for all pin controller instances. The pinctrl driver checks
> the unit address to identity which pin controller instance is being
> probed.

I don't know if that is a good way to do it, the unit name could change
for some reason and then the driver will not work, it seems fragile.

Can't we just add a custom property such as:
thead,pin-group-number = <2>;
to the device node?

Yours,
Linus Walleij