netdev - Re: [PATCH v2 net 3/4] net: dsa: mv88e6xxx: Never force link on in-band managed MACs

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]

Message-ID: <87ed1g6m7e.fsf@waldekranz.com>
Date: Mon, 06 Jan 2025 15:39:17 +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 mån, jan 06, 2025 at 08:20, "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
> On Mon, Jan 06, 2025 at 12:30:25AM +0100, Tobias Waldekranz wrote:
>> 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
>
> I *have* answered it. Every time.
>
>> description; presuming that the property is not in the DT merely for
>> documentation purposes.
>
> Utter claptap. Total rubbish. Completely wrong. It is acted on. It

I have _never_ said that is was not.  In the very sentence you are
quoting I stated my presumption that it was _not_ merely there as
documentation.  I simply wanted to _how_ the kernel acts on it - the
thing you summerize with the following sentence...

> causes phylink to enter in-band mode, and use the PCS to obtain the
> in-band data instead of the PHY.

..._this_ is the process I wanted to learn more about.  How phylink
operates in the two different modes, what the responsibilites of the NIC
driver are, of the PHY driver (if applicable), etc.

> YOU are the one refusing to listen to what I'm saying, yet you claim
> my explanations are clear and you understand them. You parently do
> not.

I am sure that there are several points you have made that I ought to
have groked sooner, and that I could have stated my questions more
clearly.  I am only human.  Let me assure you that I have read each of
your replies many times over, each time wanting nothing more than to
have that light bulb moment.

Sincerely, I am thankful that you have taken the time to try to help me,
and I never meant to cause any distress.