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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9AE8C00144 for ; Fri, 29 Jul 2022 21:24:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238817AbiG2VY5 (ORCPT ); Fri, 29 Jul 2022 17:24:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231563AbiG2VYx (ORCPT ); Fri, 29 Jul 2022 17:24:53 -0400 Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37B838BA8B for ; Fri, 29 Jul 2022 14:24:53 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id q22so1902745pfn.9 for ; Fri, 29 Jul 2022 14:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=HlhQSe8JPPoTM03QiXKr5nJRIJvrGI/Hcq4MVfHK348=; b=QOMYUzuket6dH7SDS7xe+hU+0Yhp4/priRyU+ohixnUfONm9/g6q8g1ldqh4Q+4gJB Pajt+LR8Ucs+nfUcN0HMaKV3TX5KByzstl0t9PwtGAqDI7O0f8SU0rw2WR3Tyi8pKnzk zknt/iBT08xtufjXRQw2UhTmOgcpfwtYUXi0oraQM/J7WHDb2sDl9zhlXdzpwZc58697 JzBoqqirF42EukU59uqRJ3DUqEhv7oXRUmu9GA0DzIHCSbc6Svw73+Op5dKn8BcXPCEl W5Qzs9ll+btJpy+O7Z5ejjTL1gs3JMeNARp7+F6/3+sVy96bVb0aJeNhznbwbYbUY6N3 w4sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=HlhQSe8JPPoTM03QiXKr5nJRIJvrGI/Hcq4MVfHK348=; b=2SWeJXsX340C13HzImvqt4ms2M1I0i8Gk+zYpeJolRQ/2Hdc0AWeHCxM0kRA0Nq48P lZUaAFcfxkcbjcV4dhnC3R6Ae+U+A2UaiNuRN5HQZZZfqQg+rtyi8VnGcVyoXsooHMD3 6W4/PACNdViae3g3saFfzmHvYhLpa0l3AUtAu43hNjlDPjcMsH/H/n0CaDPRPX0gbFg0 HJ1RkA6cqxnskKaYE0jgEcbuO010l5FoqI3IAMIWZbDGkUJTLSbEP+kaVfRqAXMuJvy0 pMa0h5bmAGnXoAZDdZxjUMU3KOFQ66hQj47QH0KdUn+xBcIhiR1yyvpj9qvDCuG8tefG 2+4A== X-Gm-Message-State: AJIora+V7eBSMpH8PT4UCvrObZInA+M8G4/dw7eQaJLWZYhHfl1loynR Pj6ecRzzEndB0gz4M0UKkww= X-Google-Smtp-Source: AGRyM1v9JQmhwmLxF/pNl4Oi0hElUuZDK37M3RjSY7L9X/8LbECve9rKXQzkSymYU+vIv225j2tEsA== X-Received: by 2002:a63:b15:0:b0:41b:3459:e8a5 with SMTP id 21-20020a630b15000000b0041b3459e8a5mr4410140pgl.454.1659129892454; Fri, 29 Jul 2022 14:24:52 -0700 (PDT) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.googlemail.com with ESMTPSA id md14-20020a17090b23ce00b001f29ba338c1sm14948100pjb.2.2022.07.29.14.24.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jul 2022 14:24:51 -0700 (PDT) Message-ID: <7a8b57c3-5b5a-dfc8-67cb-52061fb9085e@gmail.com> Date: Fri, 29 Jul 2022 14:24:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v2 net-next 4/4] net: dsa: validate that DT nodes of shared ports have the properties they need Content-Language: en-US To: Andrew Lunn , Marcin Wojtas Cc: Vladimir Oltean , netdev , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vivien Didelot , Oleksij Rempel , Christian Marangi , John Crispin , Kurt Kanzenbach , Mans Rullgard , Arun Ramadoss , Woojung Huh , "UNGLinuxDriver@microchip.com" , Claudiu Manoil , Alexandre Belloni , George McCollister , DENG Qingfang , Sean Wang , Landen Chao , Matthias Brugger , Hauke Mehrtens , Martin Blumenstingl , Aleksander Jan Bajkowski , =?UTF-8?Q?Alvin_=c5=a0ipraga?= , Luiz Angelo Daros de Luca , Linus Walleij , Pawel Dembicki , =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= , Geert Uytterhoeven , Russell King , =?UTF-8?Q?Marek_Beh=c3=ban?= , Rob Herring , Frank Rowand , Tomasz Nowicki , Grzegorz Jaszczyk References: <20220729132119.1191227-1-vladimir.oltean@nxp.com> <20220729132119.1191227-5-vladimir.oltean@nxp.com> <20220729183444.jzr3eoj6xdumezwu@skbuf> From: Florian Fainelli In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 7/29/22 14:17, Andrew Lunn wrote: >> What I propose is to enforce more strictly an update of DT description >> with a specified timeline, abandoning 'camps' idea and driver-specific >> contents in the generic code. > > Regressions are the problem. We are supposed to be backwards > compatible with older DT blobs. If we now say old DT blobs are > invalid, and refuse to probe, we cause a regression. > > For some of the in kernel DT files using the mv88e6xxx i can make a > good guess at what the missing properties are. However, i'm bound to > guess wrong at some point, and cause a regression. So we could change > just those we can test. But at some point, the other blobs are going > to fail the enforces checks and cause a regression anyway. > > And what about out of tree blobs? Probably OpenWRT have some. Do we > want to cause them to regress? No, we do not want that, which is why Vladimir's approach IMHO is reasonable in that it acknowledges mistakes or shortcomings of the past into the present, and expects the future to be corrected and not repeat those same mistakes. The deprectiation window idea is all well and good in premise, however with such a large user base, I am not sure it is going to go very far unfortunately, nor that it will hinder our ability to have a more maintainable DSA framework TBH. BTW, OpenWrt does not typically ship DT blobs that stay frozen, all of the kernel, DTBs, root filesystem, and sometimes a recent u-boot copy will be updated at the same time because very rarely do the existing boot loader satisfy modern requirements (PSCI, etc.). -- Florian