[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ffb526e4-623b-e87d-ac64-87c373ce36fb@kernel.org>
Date: Wed, 8 Mar 2023 11:19:16 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ken Sloat <ken.s@...iscite.com>
Cc: "noname.nuno@...il.com" <noname.nuno@...il.com>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"edumazet@...gle.com" <edumazet@...gle.com>,
Michael Hennerich <michael.hennerich@...log.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Rob Herring <robh+dt@...nel.org>, Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
Alexandru Tachici <alexandru.tachici@...log.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] dt-bindings: net: adin: Document bindings for fast
link down disable
On 07/03/2023 19:19, Ken Sloat wrote:
>>> Document the new optional flags "adi,disable-fast-down-1000base-t" and
>>> "adi,disable-fast-down-100base-tx" which disable the "Fast Link Down"
>>> feature in the ADI PHY.
>>
>> You did not explain why do you need it.
>
> My thoughts were this was explained in the feature patch and so was redundant here which is why I gave a brief summary, but if the norm is to duplicate this information I can certainly do that.
At least something should be here. Bindings are separate from Linux, so
the commit should stand on its own.
>>> description: Enable 25MHz reference clock output on CLK25_REF pin.
>>> type: boolean
>>>
>>> + adi,disable-fast-down-1000base-t:
>>> + $ref: /schemas/types.yaml#definitions/flag
>>> + description: |
>>> + If set, disables any ADI fast link down ("Enhanced Link Detection")
>>> + function bits for 1000base-t interfaces.
>>
>> And why disabling it per board should be a property of DT?
>>
> That seemed like a logical place to allow override on boards where it is undesired. Would you say that properties such as this should instead be custom PHY tunables, which may require patching of ethtool as well?
First, your other commit says that it breaks IEEE standard, so maybe it
should be always disabled?
Second, tunable per board, but why? DT describes the hardware, so just
because someone wants to tune something is not a reason to put it in DT.
The reason to put it in DT is - this boards requires or cannot work with
the feature because of some board characteristic.
Best regards,
Krzysztof
Powered by blists - more mailing lists