linux-kernel - Re: [PATCH 0/2] gpio: 74x164: use a compatible fallback and don't extend the driver

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: <CAMRc=MckJfEBK_ZUZ31hh7SMdbr4a-vZLtTGDCFttGK65wbXdA@mail.gmail.com>
Date: Fri, 10 Jan 2025 14:38:18 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Csókás Bence <csokas.bence@...lan.hu>
Cc: Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Maxime Ripard <mripard@...nel.org>, J . Neuschäfer <j.ne@...teo.net>, 
	"Geert Uytterhoeven via gmail . com" <geert@...ux-m68k.org>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH 0/2] gpio: 74x164: use a compatible fallback and don't
 extend the driver

On Fri, Jan 10, 2025 at 2:32 PM Csókás Bence <csokas.bence@...lan.hu> wrote:
>
> Hi,
>
> On 2025. 01. 10. 14:00, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> >
> > There were other suggested solutions (for instance: just use the
> > existing compatible for the On Semi variant) but I figured the most
> > common approach is to use a fallback value for 100% compatible models
> > and this is what Rob suggested as well.
> >
> > This reverts the driver change and makes the "onnn,74hc595a" compatible
> > use "fairchild,74hc595" as fallback.
>
> Is there any reason to introduce a new compatible name at all? Does some
> pre-existing, widely-used DT blob use it in the wild already? If not,
> then I don't think it's necessary; for any new boards, their DT's
> authors should just use the pre-existing names.
>

I don't have a strong opinion on this and will defer to DT maintainers
but a similar case I'm familiar with is the at24 EEPROM driver where
we've got lots of 1:1 compatible chips and we tend to add new
compatibles to DT bindings (with fallbacks to associated atmel models)
just for the sake of correct HW description in DTS.

> I'm especially against introducing a new, vendor-specific (On Semi, in
> this case) name; if we really want to introduce a new compatible, at
> least make it as generic as possible, i.e. `generic,74x595`, or even
> `generic,spi-shift-register-output`.
>

If anything, that would have to be the fallback that the driver knows.
The first string in the compatible property has to have an actual
vendor (I think, I'll let DT maintainers correct me).

Bart

> > Bartosz Golaszewski (2):
> >    Revert "gpio: 74x164: Add On Semi MC74HC595A compat"
> >    dt-bindings: gpio: fairchild,74hc595: use a fallback for Semi
> >      MC74HC595A
> >
> >   .../devicetree/bindings/gpio/fairchild,74hc595.yaml    | 10 ++++++----
> >   drivers/gpio/gpio-74x164.c                             |  2 --
> >   2 files changed, 6 insertions(+), 6 deletions(-)
>
> Bence
>