[PATCH 1/2] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6561

[Conor Dooley]

On Sat, Aug 03, 2024 at 03:31:52PM +0300, Ilya Orazov wrote:
> > > > > > I made my patch according to a similar one that adds support for
> > > > > > nxp,tjr1443. You can find it's conversation on
> > > > > > https://lore.kernel.org/all/6ee5e2ce00019bd3f77d6a702b38bab1a45f3bb0.1674037830.git.geert+renesas@glider.be/t/#u.
> > > > >
> > > > > > I thought we want to hold all PHY chip names in one compatible enum
> > > > > > and each in its own of_device_id struct in driver and extend them
> > > > > > where appropriate.
> > > > >
> > > > > Nah, fallbacks are preferred when the programming model is either
> > > > > identical or a "compatible superset" of an existing device. New
> > > > > of_device_id structs should only be used where we need to account for
> > > > > differences in the programming model.
> > > >
> > > > However, I am curious as to why the NXP CAN PHY transceiver was not
> > > > included as fallback compatible. Geert, could you please share your
> > > > thoughts on this matter?
> > >
> > > The TJR1443 looked sufficiently similar to the TCAN1043 to use the
> > > same driver configuration (which is limited to having standby and/or
> > > enable signals or not).  However, I'm not sure it behaves exactly
> > > the same, e.g. in case of reporting an error condition (which is not
> > > yet supported by the driver). The part numbers are also different,
> > > so this is not a simple case of SN74HCxx vs. CD74HCxx.
> > >
> > > Summary: I don't know if they are identical, or if TJR1443 is a
> > > compatible superset of TCAN1043, or vice versa. Hence I went for the
> > > safest way....
> >
> > If we don't know for sure what the craic is with compatibility, then we
> > should leave the existing tjr1443 compatible as-is I think.
> 
> If I understood the kernel documentation correctly, we use fallback
> compatibles when devices are similar or there is an iterative
> relationship between them. In my case, the TCAN1042 and ATA6561 are
> from different manufacturers, and I'm not sure about their fully
> identical functionality.

It's about programming models being compatible, not identical. The
manufacturer also doesn't matter.

> Therefore, I'll go back to the original idea where I shouldn't use a
> fallback compatible here and must leave it as another compatible
> property with its own of_device_id struct.
> 
> What do you think about it? In my opinion, this is not a case for
> fallback compatibility.

Why is it not a case, other than the reasons you already mentioned that
I don't agree with?

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-phy/attachments/20240805/e1c8d78e/attachment.sig>