On 6/13/24 2:43 PM, Rob Herring wrote: > On Thu, Jun 13, 2024 at 05:11:48PM +0200, Nuno Sá wrote: >> On Thu, 2024-06-13 at 09:39 -0500, David Lechner wrote: >>> On 6/13/24 9:18 AM, Krzysztof Kozlowski wrote: >>>> On 13/06/2024 15:57, David Lechner wrote: >>>>> >>>>>> >>>>>>> + - const: adi,ad4695 >>>>>>> + - items: >>>>>>> + - const: adi,ad4697-wlcsp >>>>>>> + - const: adi,ad4697 >>>>>>> + # same chips with higher max sample rate >>>>> >>>>> I suppose one could make the argument that the programming model is >>>>> the same on these too, but the maximum sampling frequency does seem >>>>> like an important bit of information so that you don't try to set >>>>> the conversion trigger rate too high. >>>>> >>>> >>>> which property is that? I don't see differences in the driver, so I >>>> don't get how these wlcsp compatibles allow you to control value of >>>> conversion trigger. >>> >>> This comment is unrelated to the package type (WLCSP or LFCSP). >>> >>> What I mean is that e.g. AD4695 and AD4696 are virtually identical >>> other than the maximum allowable sample rate (500 kSPS or 1 MSPS). >>> >>> So my thinking was that it would make sense to have: >>> >>> compatible = "ad4695"; >>> >>> for the lower sample rate chip and >>> >>> compatible = "ad4696", "ad4695"; >>> >>> for the higher sample rate chip since ad4696 can do everything >>> that ad4695 does plus a bit more. >>> >> >> IMO, that would make sense yes. If the higher sample rate chip fallsback, it will >> still work but not at full speed. The other way around is the one that we can't allow >> naturally. >> >> But possibly dumb question now... since both devices will be supported at the same >> time, do we actually care about having the fallback compatible? My understanding of >> the fallback story is that we may load a DTS in an older kernel where chip A is >> supported but chip B is not and it is ok for chip B to fallback to chip A. Since >> these devices will be supported at the same time, do we need to care? Unless out of >> tree stuff enters the equation? > > Yeah, it doesn't really matter much in that case. > >> Or is there another usecase that I'm not aware about (or maybe it just makes sense to >> document properly...)? > > Somewhat I guess. Perhaps if there's a 3rd chip with higher rate, then > it will be more obvious what to do and we don't have to have this > discussion again for it. :) > > Rob It sounds like maybe the best thing to do here then is just keep it simple? Like this: compatible: enum: - adi,ad4695 - adi,ad4696 - adi,ad4697 - adi,ad4698