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] [day] [month] [year] [list]
Message-ID: <CAMRc=Me+syDKW6sycGZ86rBJysaccsm3QUYd1+5cnfzRCo6P7A@mail.gmail.com>
Date: Fri, 10 Jan 2025 15:14:03 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Csókás Bence <csokas.bence@...lan.hu>, 
	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>, 
	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 3:10 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Bartosz,
>
> On Fri, Jan 10, 2025 at 2:38 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > On Fri, Jan 10, 2025 at 2:32 PM Csókás Bence <csokas.bence@...lan.hu> wrote:
> > > 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.
>
> At24 EEPROMs differ from '595 shift registers in that they provide an
> API with multiple commands, and some commands or parameter bits may
> differ among different implementations (but usually these differences
> are called quirks).
>
> All '595 (I'm deliberately writing it like that) shift registers
> should be 100% compatible, modulo some electrical specifications
> (voltage levels, maximum speed, power consumption, ...).
>
> Interestingly, the driver is called gpio-74x164.c, while no '164
> compatible value is present. Most important difference is that the
> '164 lacks the output latch, which is used as chip-select with SPI[1].
>
> > > 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).
>
> For the inverse operation (parallel in, serial out), there's just
> "pisosr-gpio".
>

Ok, I admit I don't know the correct next step. I'll wait for
Krzysztof, Rob or Conor to chime in (on the subject of representing
reality - the actual manufacturer - in DTS) and then possibly just
remove patches 1-2 from my tree.

Bartosz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ