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@xxxxxxxxx/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.
Attachment:
signature.asc
Description: PGP signature
