[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<CY5PR11MB6462CF4414B3B0A87EE35780ECB72@CY5PR11MB6462.namprd11.prod.outlook.com>
Date: Thu, 10 Apr 2025 18:36:10 +0000
From: <Prathosh.Satish@...rochip.com>
To: <ivecera@...hat.com>, <conor@...nel.org>
CC: <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
Hi Ivan,
yes you are right, the only difference is the number of channels.
Prathosh
-----Original Message-----
From: Ivan Vecera <ivecera@...hat.com>
Sent: Thursday 10 April 2025 18:36
To: Prathosh Satish - M66066 <Prathosh.Satish@...rochip.com>; conor@...nel.org
Cc: 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
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
On 10. 04. 25 7:07 odp., Prathosh.Satish@...rochip.com wrote:
> -----Original Message-----
> From: Ivan Vecera <ivecera@...hat.com>
> Sent: Thursday 10 April 2025 14:36
> To: Conor Dooley <conor@...nel.org>; Prathosh Satish - M66066
> <Prathosh.Satish@...rochip.com>
> Cc: Krzysztof Kozlowski <krzk@...nel.org>; netdev@...r.kernel.org;
> Vadim Fedorenko <vadim.fedorenko@...ux.dev>; Arkadiusz Kubalewski
> <arkadiusz.kubalewski@...el.com>; Jiri Pirko <jiri@...nulli.us>; Rob
> Herring <robh@...nel.org>; Krzysztof Kozlowski <krzk+dt@...nel.org>;
> Conor Dooley <conor+dt@...nel.org>; Prathosh Satish - M66066
> <Prathosh.Satish@...rochip.com>; Lee Jones <lee@...nel.org>; Kees Cook
> <kees@...nel.org>; Andy Shevchenko <andy@...nel.org>; Andrew Morton
> <akpm@...ux-foundation.org>; Michal Schmidt <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
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> the content is safe
>
> On 10. 04. 25 3:18 odp., Conor Dooley wrote:
>> On Thu, Apr 10, 2025 at 09:45:47AM +0200, Ivan Vecera wrote:
>>>
>>>
>>> On 10. 04. 25 9:06 dop., Krzysztof Kozlowski wrote:
>>>> On Wed, Apr 09, 2025 at 04:42:38PM GMT, Ivan Vecera wrote:
>>>>> Add DT bindings for Microchip Azurite DPLL chip family. These
>>>>> chips provides 2 independent DPLL channels, up to 10 differential
>>>>> or single-ended inputs and up to 20 differential or 20 single-ended outputs.
>>>>> It can be connected via I2C or SPI busses.
>>>>>
>>>>> Signed-off-by: Ivan Vecera <ivecera@...hat.com>
>>>>> ---
>>>>> .../bindings/dpll/microchip,zl3073x-i2c.yaml | 74 ++++++++++++++++++
>>>>> .../bindings/dpll/microchip,zl3073x-spi.yaml | 77
>>>>> +++++++++++++++++++
>>>>
>>>> No, you do not get two files. No such bindings were accepted since
>>>> some years.
>>>>
>>>>> 2 files changed, 151 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/dpll/microchip,zl3073x-i2c.yaml
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/dpll/microchip,zl3073x-spi.yaml
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/dpll/microchip,zl3073x-i2c.yam
>>>>> l
>>>>> b/Documentation/devicetree/bindings/dpll/microchip,zl3073x-i2c.yam
>>>>> l
>>>>> new file mode 100644
>>>>> index 0000000000000..d9280988f9eb7
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/dpll/microchip,zl3073x-i2c.
>>>>> +++ yaml
>>>>> @@ -0,0 +1,74 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
>>>>> +---
>>>>> +$id:
>>>>> +http://devicetree.org/schemas/dpll/microchip,zl3073x-i2c.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: I2C-attached Microchip Azurite DPLL device
>>>>> +
>>>>> +maintainers:
>>>>> + - Ivan Vecera <ivecera@...hat.com>
>>>>> +
>>>>> +description:
>>>>> + Microchip Azurite DPLL (ZL3073x) is a family of DPLL devices
>>>>> +that
>>>>> + provides 2 independent DPLL channels, up to 10 differential or
>>>>> + single-ended inputs and up to 20 differential or 20 single-ended outputs.
>>>>> + It can be connected via multiple busses, one of them being I2C.
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + enum:
>>>>> + - microchip,zl3073x-i2c
>>>>
>>>> I already said: you have one compatible, not two. One.
>>>
>>> Ah, you mean something like:
>>> iio/accel/adi,adxl313.yaml
>>>
>>> Do you?
>>>
>>>> Also, still wildcard, so still a no.
>>>
>>> This is not wildcard, Microchip uses this to designate DPLL devices
>>> with the same characteristics.
>>
>> That's the very definition of a wildcard, no? The x is matching
>> against several different devices. There's like 14 different parts
>> matching zl3073x, with varying numbers of outputs and channels. One
>> compatible for all of that hardly seems suitable.
>
> 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.
Huh, then ok... We should specify zl30731-5 compatibles and they differs only by number of channels (1-5) ?
The number of input and output pins are the same (10 and 20), right?
If so, I have to update the whole driver to accommodate dynamic number of channels according chip type.
Btw. Conor, Krzystof if we use microchip,zl30731, ..., microchip,zl30735... What should be the filename for the yaml file?
Thanks,
Ivan
> Thanks.
>>
>>>
>>> But I can use microchip,azurite, is it more appropriate?
>>
>> No, I think that is worse actually.
>
Powered by blists - more mailing lists