From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 00ECEC43334 for ; Sat, 23 Jul 2022 13:46:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wQaql97l0J7ocOekBI4FZt/NDm7pu9uXk8m40YagvnU=; b=eXbb/xs3Px/dDl S7cfiaqXXWo9SEs0Hfe71jbIIGsiEZmekGrv731TXshpshw2ERkL1rAQsjBRNFgRvNHeQG4+rRybA M53WFkKXvIqG3ppyn0GKt8tYDvnBDdrudfGmV45iNngcebHy4H+sF4sIeqdWjCkBREpN4XMPPBcRS tUCxnci8W/OBda13FA+AF57wY23s6ksXpFjtGlKGwnlzfF3iH6TONR6mB9WvHL+0HZYY5LAC0HeDp QpCHmJA6uF4Vy3ymd9sDqU7/5PLw6F2oHB+Tywi/8o/kibUL5ncnnZfPvnLPvEXGej6GcAIi/66YD ux+ow6t3shxU3N+u7I5g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oFFR9-003TrY-9n; Sat, 23 Jul 2022 13:44:55 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oFFR5-003Tp0-Kq; Sat, 23 Jul 2022 13:44:53 +0000 Received: by mail-ej1-x62b.google.com with SMTP id mf4so13019026ejc.3; Sat, 23 Jul 2022 06:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=49amiazncfe+YGfCcsE1Umxq5UaZUxFQiGQFBx6ze1c=; b=GLIzSCflcbjXQKRTFNrUPUCwiNVLFsPGiGJTuboZnWUsmIuIflEZO+CT6K5TmH7rbn RCzLCwDXGvlTP9QmVPo3bhZjTFjnw/SlnMR3uqYCjusfuTisFXtgjvYyt2ZGulp8HT2Y d9fa7k1valp+ReEH69JJtiBLmn5fDHE1Ik89gedHUzegG2JyLzkrpHQ9bFP6j9qrukPy CoJMS8qw+MSB9+LSt20cGAS9do5ANXxYx47Y9pXZq3dQrE5YnNCBi0gLefo7XJTpTTm+ QXCMZ7J1bsXPgvFdumg8YVyJAJEPNqeKR8e54kAhIAuZPjBEzyz+Qb318dbcFAsChVL7 wEmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=49amiazncfe+YGfCcsE1Umxq5UaZUxFQiGQFBx6ze1c=; b=ruVkMTAQlah/RbmPY+4xRyawfPocoPSdVSFRY56SFi1xk9V5e0UYUWwhLfnKYrMOFg EuQ3mtMM3OC0e0mNkErTQceIVLibNteZNPHf1po1ZZ7ksv2CkqjK2BHXSWSfLtJdPQGg N1odL92OfWtxcdkmcJW8ceOSzzapu+5OTBFbNiIEMScruC5RDahqaH73b9DxfFm81t1V kWMaNx6abLwtofypiBfsBo6vMb0BJoTwG1ZlxhUaM7yEe7UzOoPLYK4cvm0zdOt1sQnX VEVWl0cravQIBKAR5TD3Lgdmd6x0vToCrz8xfmumDLQMYaLp1s3m71WNLEPrZj8rjMrA loYg== X-Gm-Message-State: AJIora8b/DkMr0YlIO1+9zJ1BjHkQ+7lBgojzp4i34cSIrhAWyIEG3FV hspyhuGe0oyKOLma1PxHWu0= X-Google-Smtp-Source: AGRyM1uVkPV5hLTPJLLcAQ9tlPKSclPGRO6ACvn74IDvvQ5HKYpLnh7Bs/psd8uUthI973Mvf4L3mQ== X-Received: by 2002:a17:907:9608:b0:72f:4b13:c66c with SMTP id gb8-20020a170907960800b0072f4b13c66cmr3445161ejc.531.1658583888669; Sat, 23 Jul 2022 06:44:48 -0700 (PDT) Received: from skbuf ([188.25.231.115]) by smtp.gmail.com with ESMTPSA id 16-20020a170906301000b0072efb6c9697sm3171067ejz.101.2022.07.23.06.44.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Jul 2022 06:44:47 -0700 (PDT) Date: Sat, 23 Jul 2022 16:44:44 +0300 From: Vladimir Oltean To: "Russell King (Oracle)" Cc: Marek =?utf-8?B?QmVow7pu?= , Andrew Lunn , Heiner Kallweit , Alexandre Belloni , Alvin __ipraga , Andy Shevchenko , Claudiu Manoil , Daniel Scally , "David S. Miller" , DENG Qingfang , Eric Dumazet , Florian Fainelli , George McCollister , Greg Kroah-Hartman , Hauke Mehrtens , Heikki Krogerus , Jakub Kicinski , Kurt Kanzenbach , Landen Chao , Linus Walleij , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Matthias Brugger , netdev@vger.kernel.org, Paolo Abeni , "Rafael J. Wysocki" , Sakari Ailus , Sean Wang , UNGLinuxDriver@microchip.com, Vivien Didelot , Woojung Huh Subject: Re: [PATCH net-next 3/6] net: dsa: add support for retrieving the interface mode Message-ID: <20220723134444.e65w3zq6pg43fcm4@skbuf> References: <20220722105238.qhfq5myqa4ixkvy4@skbuf> <20220722124629.7y3p7nt6jmm5hecq@skbuf> <20220722165600.lldukpdflv7cjp4j@skbuf> <20220722223932.poxim3sxz62lhcuf@skbuf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220723_064451_747167_EA5E0F19 X-CRM114-Status: GOOD ( 27.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel