netdev - Re: [PATCH net-next v2 00/10] define and enforce phylink bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 25 Sep 2023 10:47:02 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Conor Dooley <conor+dt@...nel.org>,
 George McCollister <george.mccollister@...il.com>,
 Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean
 <olteanv@...il.com>, Kurt Kanzenbach <kurt@...utronix.de>,
 Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Woojung Huh <woojung.huh@...rochip.com>, UNGLinuxDriver@...rochip.com,
 Linus Walleij <linus.walleij@...aro.org>,
 Alvin Šipraga <alsi@...g-olufsen.dk>,
 Clément Léger <clement.leger@...tlin.com>,
 Marcin Wojtas <mw@...ihalf.com>, Lars Povlsen <lars.povlsen@...rochip.com>,
 Steen Hegelund <Steen.Hegelund@...rochip.com>,
 Daniel Machon <daniel.machon@...rochip.com>,
 Radhey Shyam Pandey <radhey.shyam.pandey@....com>,
 Daniel Golle <daniel@...rotopia.org>, Landen Chao
 <Landen.Chao@...iatek.com>, DENG Qingfang <dqfext@...il.com>,
 Sean Wang <sean.wang@...iatek.com>,
 Geert Uytterhoeven <geert+renesas@...der.be>,
 Magnus Damm <magnus.damm@...il.com>,
 Maxime Chevallier <maxime.chevallier@...tlin.com>,
 Nicolas Ferre <nicolas.ferre@...rochip.com>,
 Claudiu Beznea <claudiu.beznea@...rochip.com>, Marek Vasut <marex@...x.de>,
 Claudiu Manoil <claudiu.manoil@....com>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 John Crispin <john@...ozen.org>, Madalin Bucur <madalin.bucur@....com>,
 Ioana Ciornei <ioana.ciornei@....com>, Lorenzo Bianconi
 <lorenzo@...nel.org>, Felix Fietkau <nbd@....name>,
 Horatiu Vultur <horatiu.vultur@...rochip.com>,
 Oleksij Rempel <linux@...pel-privat.de>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Giuseppe Cavallaro <peppe.cavallaro@...com>,
 Jose Abreu <joabreu@...opsys.com>,
 Grygorii Strashko <grygorii.strashko@...com>, Sekhar Nori <nsekhar@...com>,
 Shyam Pandey <radhey.shyam.pandey@...inx.com>, mithat.guner@...ont.com,
 erkin.bozoglu@...ont.com, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH net-next v2 00/10] define and enforce phylink bindings

On 24.09.2023 17:55, Andrew Lunn wrote:
> On Sun, Sep 24, 2023 at 10:49:49AM +0300, Arınç ÜNAL wrote:
>> On 24/09/2023 06:15, Andrew Lunn wrote:
>>>>> There is a MAC driver currently under review which does not have a PHY
>>>>> at all. The MAC is directly connected to a switch, all within one
>>>>> IC. The link is always running at 5Gbps, the link is always up. It is
>>>>> physically impossible to connect a PHY, so get_link_settings just
>>>>> returns hard coded values.
>>>>
>>>> The fixed-link property would be used to describe the link of the MAC here.
>>>
>>> Fixed-link make sense for a general purpose MAC which could be
>>> connected to a PHY, or could also be used without a PHY. fixed-link
>>> simplifies the code in that the MAC driver does not see a difference,
>>> it all looks like a PHY.
>>>
>>> However for a MAC which cannot be connected to a PHY, there is no need
>>> to emulate a PHY. The MAC driver will be simpler. So i would not
>>> recommend a fixed-link in this situation.
>>
>> There's a link, it must be described.
> 
> Why must it be described?
> 
> Lets take this to the extreme to make a point. The chip has a ground
> pin. Must i describe that?

I think it depends on how important the information is, to be put on the
devicetree. I don't think a ground pin of an SoC is important enough to be
described on the devicetree. It could be described as a text on the
relevant devicetree document though. I've recently submitted a patch that
does a similar thing. I've described which pin groups represent which pins.

https://lore.kernel.org/lkml/20230917162837.277405-2-arinc.unal@arinc9.com/

For an ethernet controller, its link is the core part of the hardware.
Therefore describing the link was deemed important. Hence certain
properties were made to describe the link on the devicetree.

All I proposed was to make sure these properties are always defined on the
devicetree since, for an ethernet controller to exist, it must have a link.

Arınç