[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e331736-36f2-4796-945f-613279329585@lunn.ch>
Date: Thu, 10 Apr 2025 23:12:41 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Ivan Vecera <ivecera@...hat.com>
Cc: Prathosh.Satish@...rochip.com, conor@...nel.org, krzk@...nel.org,
netdev@...r.kernel.org, vadim.fedorenko@...ux.dev,
arkadiusz.kubalewski@...el.com, jiri@...nulli.us, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, lee@...nel.org,
kees@...nel.org, andy@...nel.org, akpm@...ux-foundation.org,
mschmidt@...hat.com, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 02/14] dt-bindings: dpll: Add support for Microchip
Azurite chip family
On Thu, Apr 10, 2025 at 08:33:31PM +0200, Ivan Vecera wrote:
>
>
> On 10. 04. 25 7:36 odp., Andrew Lunn wrote:
> > > Prathosh, could you please bring more light on this?
> > >
> > > > Just to clarify, the original driver was written specifically with 2-channel
> > > > chips in mind (ZL30732) with 10 input and 20 outputs, which led to some confusion of using zl3073x as compatible.
> > > > However, the final version of the driver will support the entire ZL3073x family
> > > > ZL30731 to ZL30735 and some subset of ZL30732 like ZL80732 etc
> > > > ensuring compatibility across all variants.
> >
> > Hi Prathosh
> >
> > Your email quoting is very odd, i nearly missed this reply.
> >
> > Does the device itself have an ID register? If you know you have
> > something in the range ZL30731 to ZL30735, you can ask the hardware
> > what it is, and the driver then does not need any additional
> > information from DT, it can hard code it all based on the ID in the
> > register?
> >
> > Andrew
> >
> Hi Andrew,
> yes there is ID register that identifies the ID. But what compatible should
> be used?
>
> microchip,zl3073x was rejected as wildcard and we should use all
> compatibles.
You have two choices really:
1) You list each device with its own compatible, because they are in
fact not compatible. You need to handle each one different, they have
different DT properties, etc. If you do that, please validate the ID
register against the compatible and return -ENODEV if they don't
match.
2) You say the devices are compatible. So the DT compatible just
indicates the family, enough information for the driver to go find the
ID register. This does however require the binding is the same for all
devices. You cannot have one family member listing 10 inputs in its
binding, and another family member listing 20.
If you say your devices are incompatible, and list lots of
compatibles, you can then use constraints in the yaml, based on the
compatible, to limit each family member to what it supports.
My guess is, you are going to take the first route.
Andrew
Powered by blists - more mailing lists