On Fri, Jan 10, 2025 at 3:10 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Hi Bartosz, > > On Fri, Jan 10, 2025 at 2:38 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > On Fri, Jan 10, 2025 at 2:32 PM Csókás Bence <csokas.bence@xxxxxxxxx> wrote: > > > On 2025. 01. 10. 14:00, Bartosz Golaszewski wrote: > > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > > > > > > > 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
