On Mon, Jun 05, 2023 at 02:37:16PM +0200, Nicolas Ferre wrote: > Arnd, Conor, > > On 04/06/2023 at 23:08, Conor Dooley wrote: > > On Sun, Jun 04, 2023 at 11:49:48AM +0200, Arnd Bergmann wrote: > > > On Sat, Jun 3, 2023, at 23:23, Conor Dooley wrote: > > > > On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote: > > > > > Hey Varshini, > > > > > > > > > > On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote: > > > > > > Document the support added for the Advanced interrupt controller(AIC) > > > > > > chip in the sam9x7 soc family > > > > > Please do not add new family based compatibles, but rather use per-soc > > > > > compatibles instead. > > > > These things leave me penally confused. Afaiu, sam9x60 is a particular > > s/penally/perennially/ > > > > > > SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and > > > > sam9x75. It would appear to me that each should have its own compatible, > > > > no? > > > I think the usual way this works is that the sam9x7 refers to the > > > SoC design as in what is actually part of the chip, whereas the 70, > > > 72 and 75 models are variants that have a certain subset of the > > > features enabled. > > Yes, That's the case. > > > If that is the case here, then referring to the on-chip parts by > > > the sam9x7 name makes sense, and this is similar to what we do > > > on TI AM-series chips. > > This is what we did for most of our SoCs families, indeed. > > > If it is the case that what differentiates them is having bits chopped > > off, and there's no implementation differences that seems fair. > > Ok, thanks. > > > > There is a remaining risk that a there would be a future > > > sam9x71/73/74/76/... product based on a new chip that uses > > > incompatible devices, but at that point we can still use the > > > more specific model number to identify those without being > > > ambiguous. > > This is exactly what we did for sama5d29 which is not the same silicon vs. > the other members of the sama5d2 family. We used the more specify sama5d29 > sub-string for describing the changing parts (CAN-FD and Ethernet). > > > > The same thing can of course happen when a SoC > > > vendor reuses a specific name of a prior product with an update > > > chip that has software visible changes. > > > > > > I'd just leave this up to Varshini and the other at91 maintainers > > > here, provided they understand the exact risks. > > Yep, I understand the risk and will try to review the compatibility strings > that would need more precise description (maybe PMC or AIC). > > > Ye, seems fair to me. Nicolas/Claudiu etc, is there a convention to use > > the "0" model as the compatible (like the 9x60 did) or have "random" > > things been done so far? > > sam9x60 was a single SoC, not a member of a "family", so there was no > meaning of the "0" here. Moreover, the "0" ones are usually not the subset, > if it even exists. > So far, we used the silicon string to define the compatibility string, > adding a more precise string for hardware of family members that needed it > (as mentioned above for sama5d29). > > > > It's different for the parts that are listed as just sam9x60 > > > compatible in the DT, I think those clearly need to have sam9x7 > > > in the compatible list, but could have the sam9x60 identifier > > > as a fallback if the hardware is compatible. > > Aye. > > Yep, agreed. Can we convert this binding to schema so all this is perfectly clear what's valid or not. Rob
