[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ff2bb3e-789e-4543-a951-e7f2c0cde80d@kernel.org>
Date: Fri, 18 Jul 2025 08:55:27 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ivan Vecera <ivecera@...hat.com>, netdev@...r.kernel.org
Cc: 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 <Prathosh.Satish@...rochip.com>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Michal Schmidt <mschmidt@...hat.com>, Petr Oros <poros@...hat.com>
Subject: Re: [PATCH net-next 1/2] dt-bindings: dpll: Add clock ID property
On 17/07/2025 19:10, Ivan Vecera wrote:
> Add property to specify the ID of the clock that the DPLL device
> drives. The ID value represents Unique Clock Identified (EUI-64)
> defined by IEEE 1588 standard.
With the exception of clock-output-names and gpio-hogs, we do not define
how the output looks like in the provider bindings.
I also don't understand how this maps to channels and what "device
drives a clock" means. Plus how this is not deducible from the compatible...
So many questions.
And your driver code confirms that this looks like misrepresenting
consumer properties.
Best regards,
Krzysztof
Powered by blists - more mailing lists