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] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h66c7sa6.fsf@waldekranz.com>
Date: Mon, 06 Jan 2025 00:30:25 +0100
From: Tobias Waldekranz <tobias@...dekranz.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
 f.fainelli@...il.com, olteanv@...il.com, netdev@...r.kernel.org,
 chris.packham@...iedtelesis.co.nz, pabeni@...hat.com, marek.behun@....cz
Subject: Re: [PATCH v2 net 3/4] net: dsa: mv88e6xxx: Never force link on
 in-band managed MACs

On sön, jan 05, 2025 at 10:41, "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
> On Sun, Jan 05, 2025 at 12:16:07AM +0100, Tobias Waldekranz wrote:
>> On lör, jan 04, 2025 at 22:09, "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
>> > Host system:
>> >
>> >   ---------------------------+
>> >     NIC (or DSA switch port) |
>> >      +-------+    +-------+  |
>> >      |       |    |       |  |
>> >      |  MAC  <---->  PCS  <-----------------------> PHY, SFP or media
>> >      |       |    |       |  |     ^
>> >      +-------+    +-------+  |     |
>> >                              |   phy interface type
>> >   ---------------------------+   also in-band signalling
>> >                                  which managed = "in-band-status"
>> > 				 applies to
>> 
>> This part is 100% clear
>
> Apparently it isn't, because...
>
>> In other words, my question is:
>> 
>> For a NIC driver to properly support the `managed` property, how should
>> the setup and/or runtime behavior of the hardware and/or the driver
>> differ with the two following configs?
>> 
>>     &eth0 {
>>         phy-connection-type = "sgmii";
>>         managed = "auto";
>>     };
>> 
>> vs.
>> 
>>     &eth0 {
>>         phy-connection-type = "sgmii";
>>         managed = "in-band-status";
>>     };
>
> if it were, you wouldn't be asking this question.
>
> Once again. The "managed" property defines whether in-band signalling
> is used over the "phy-connection-type" link, which for SGMII will be
> between the PCS and PHY, as shown in my diagram above that you claim
> to understand 100%, but by the fact you are again asking this question,
> you do not understand it AT ALL.
>
> I don't know how to better explain it to you, because I think I've been
> absolutely clear at every stage what the "managed" property describes.
> I now have nothing further to add if you still can't understand it, so,
> sorry, I'm giving up answering your emails on this topic, because it's
> just too frustrating to me to continue if you still don't "get it".

I agree that you have clearly explained what it describes, many times.

My remaining question - which you acknowledge that I asked twice, yet
chose not to answer - was how software is supposed to _act_ on that
description; presuming that the property is not in the DT merely for
documentation purposes.

I will study the kernel sources more closely and try to find
enlightenment that way instead.  Thank you for your time.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ