Hi Jonathan, > > > > * DO use fallback compatibles when devices are the same as or a subset > > > > of prior implementations. > > > > > > > > I believe we fall in the "devices are the same" category, so I would > > > > have myself wrote a similar binding here with a compatible matching > > > > them all, plus a hardware-implementation-specific compatible as well; > > > > just in case. > > > > > > Fallback from one model to another. There is no "another" model here, > > > but wildcard. There is no such device as cv18xx, right? > > > > No there is not. But I don't think there is a "base" model either. > > Just multiple SoCs named cv18<something> with apparently the same ADC. > > > > So actually I guess the discussion here is about the wildcard > > compatible. It feels strange to me to have no generic compatible either > > with a wildcard or with a "base" implementation (because there is > > probably none). So I guess the solution here is to just list a single > > specific compatible in the end. > > It comes from long experience of silicon vendors not being consistent > with part naming. Oh, agreed :-) > Far too often we've had a nice generic wild card > entry and along comes the vendor with a new part in the middle > of that range that is completely incompatible. Then we end up with > people assuming the wildcard means it will work and a bunch of bug > reports. Hence no wild cards, just define first supported part as your > 'base' and go from there. I see what you mean. I must admit I'm not a big fan of naming compatibles (and drivers) after a working base rather than a good enough wildcard, but I do understand your point and kind of agree with it actually. > It's even more fun when a vendor driver papers over the differences > and so it 'works', but the upstream one doesn't. In extreme case > because a different driver entirely is required. > > So basically we don't trust silicon vendors :) > Speaking as someone who works for one - I think that's entirely > reasonable!! Haha <3 Thanks (once again) for your valuable inputs! Miquèl
