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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Krzysztof,

On Sat, Jan 11, 2025 at 12:00 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> On 10/01/2025 15:14, Bartosz Golaszewski wrote:
> >> 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.
>
> Well, folks, I don't know the exact device, so maybe there is no point
> in a new compatible if there is a claim all devices have same interface
> and documenting all of them would result in 1000 redundant
> compatibles... but OTOH, that's what we still do with jedec,spi and
> at24, so if we can add specific compatibles for these, we can do same
> also here.

Except that we don't for jedec,spi, unfortunately[1].

At24 and jedec,spi use a complex programming API, with lots of room
for deviation and extension. '595 is a pure hardware part[2]: it is
just a shift register (driven by SPI clock and MOSI) with a latch
(driven by deasserting SPI chip select), without room for deviation.
Anything that behaves differently is not a jelly-bean '595 part.

[1] "[PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for
more MT25QU parts'
    https://lore.kernel.org/all/363186079b4269891073f620e3e2353cf7d2559a.1669988238.git.geert+renesas@xxxxxxxxx

[2] Ignoring the rumor that all Microchip I/O expanders are actually
    pre-programmed PIC microcontrollers ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux