On Fri, Jan 10, 2025 at 2:32 PM Csókás Bence [off-list ref] wrote:

Hi,

On 2025. 01. 10. 14:00, Bartosz Golaszewski wrote:

quoted

From: Bartosz Golaszewski <redacted>

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

quoted

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