[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <064271f4-d775-279c-0aa2-c9e23194bc61@linaro.org>
Date: Wed, 30 Mar 2022 18:44:42 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc: Ioana Ciornei <ioana.ciornei@....com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kuba@...nel.org" <kuba@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH net-next] dt-bindings: net: convert sff,sfp to dtschema
On 30/03/2022 17:54, Russell King (Oracle) wrote:
>>
>> These are different. This is an example how to model the input clock to
>> the device being described in the bindings. This is not an example how
>> to use the clock provider, like you created here. The input clock
>> sometimes is defined in Exynos clock controller, sometimes outside. The
>> example there shows the second case - when it has to come outside. It's
>> not showing the usage of clocks provided by this device, but I agree
>> that it also might be trivial and obvious. If you think it is obvious,
>> feel free to comment/send a patch.
>
> Why is whether something is an input or output relevant? One can quite
> rightly argue that SFPs are both input and output. :)
>
I don't mind removing that example. Input - in the case of these
bindings - is quite specific. Output is opposite, not specific and can
vary, you can enable/disable, change frequency.
Discussion was two weeks ago, so all emails will bounce. :)
Best regards,
Krzysztof
Powered by blists - more mailing lists