netdev - Re: [PATCH net-next 3/6] net: dsa: add support for retrieving the interface mode

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 23 Jul 2022 16:44:44 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Marek Behún <kabel@...nel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Alvin __ipraga <alsi@...g-olufsen.dk>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Daniel Scally <djrscally@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        DENG Qingfang <dqfext@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        George McCollister <george.mccollister@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Sean Wang <sean.wang@...iatek.com>,
        UNGLinuxDriver@...rochip.com,
        Vivien Didelot <vivien.didelot@...il.com>,
        Woojung Huh <woojung.huh@...rochip.com>
Subject: Re: [PATCH net-next 3/6] net: dsa: add support for retrieving the
 interface mode

On Sat, Jul 23, 2022 at 08:12:04AM +0100, Russell King (Oracle) wrote:
> > > > Thanks for this explanation, if nothing else, it seems to support the
> > > > way in which I was interpreting managed = "in-band-status" to mean
> > > > "enable in-band autoneg", but to be clear, I wasn't debating something
> > > > about the way in which mvneta was doing things. But rather, I was
> > > > debating why would *other* drivers do things differently such as to come
> > > > to expect that a fixed-link master + an in-band-status CPU port, or the
> > > > other way around, may be compatible with each other.
> > > 
> > > Please note that phylink makes a DT specification including both a
> > > fixed-link descriptor and a managed in-band-status property illegal
> > > because these are two different modes of operating the link, and they
> > > conflict with each other.
> > 
> > Ok, thank you for this information which I already knew, what is the context?
> 
> FFS. You're the one who's writing emails to me that include *both*
> "fixed-link" and "in-band-status" together. I'm pointing out that
> specifying that in DT for a port together is not permitted.
> 
> And here I give up reading this email. Sorry, I'm too frustrated
> with this nitpicking, and too frustrated with spending hours writing a
> reply only to have it torn apart.

This is becoming toxic. You've imagined that when I was talking about
mixing fixed-link and managed = "in-band-status" I was referring to this
kind of DSA port OF node:

	port@N {
		managed = "in-band-status";

		fixed-link {
			speed = <1000>;
			full-duplex;
		};
	};

Now you're thinking I'm retarded because you've politely told me the above
is invalid, and you're wondering why I'm still talking despite of that.

Well guess what, I've never once mentioned this kind of invalid OF node,
I'm not the one who's writing emails to you that include
"both fixed-link and in-band-status together", yet in your mind the fact
that you may have misunderstood isn't even a possibility. What I'm
talking about is TWO OF nodes, one like this:

	master: ethernet@N: {
		managed = "in-band-status";
	};

	switch_cpu_port: port@N: {
		ethernet = <&master>;

		fixed-link {
			speed = <1000>;
			full-duplex;
		};
	};

It is *these* two that need to agree on in-band autoneg, when the "fixed-link"
of switch_cpu_port was created using software nodes, damn it. Andrew
said that it isn't specified whether in-band autoneg is used or not.
It was even repeated for the millionth time in the continuation of my
email, which you should have read instead of frustrating yourself for a
stupid reason again.

If you think I'm making this up and I *was* talking about in-band-status
and fixed-link together in the same node, go ahead and search back where
I've said that, or even implied that. But don't blame me when you'll get
frustrated again that you won't find it. I re-read what I said once
yesterday and once today.

That's where our communication problem is, you're politely trying to
tell your conversation partner that he's an idiot and he JUST DOESN'T
WANT TO UNDERSTAND, DAMN IT.

In any case, it looks like it's time to remove myself from this conversation.
I am going to propose a patch shortly which adds validation in DSA for
the OF nodes of DSA and CPU ports, and opts some drivers out of it.
I'm going to opt into validation as many drivers as reasonably possible.
You'll then have to work with the driver maintainers who opted out of
it. I'm not one of them, so you won't have to work with me. Beyond that,
I just don't care and I had enough. I have other things to do too.