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 9120AC43217 for ; Mon, 14 Nov 2022 19:54:31 +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=PiS4I8jkALrbAdoJwsfngGs20tFFO03ki2KfF6pPGt0=; b=rR7KNB9UJeeuOH clycgwY5XG1okZiSy8LnYN97K6+CEWP8zL8aghvoBVOQDiwsXQiBmdbcDSrqCA63/gYMC7wsDmbNm IGRvJtfStgyBv89nx0f36NpqOkRFtfRNbWCnUYQ0XR90f5thGBJmUr7s6OITMfe5RaEU4m6h9I0nM WsOUPeOpg2DL+e1DekG8kBSyDPvVcESFxDpmbFaG9NzYDO0Cr1vDrSe4mba9bk5X7uDgwt+VscIjj poFXRWIINH/chcwKmE+vZSgs0AOY5KP9nqbgPiogQJ6FQ54t6/Ig31jUE10eRfJkCnPtKYGJgpBT2 xgsAfkiGgTrBnDgaHa0w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oufWS-004IRI-Rz; Mon, 14 Nov 2022 19:53:37 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oufWP-004IKe-OB for linux-arm-kernel@lists.infradead.org; Mon, 14 Nov 2022 19:53:35 +0000 Received: by mail-ej1-x635.google.com with SMTP id kt23so30973217ejc.7 for ; Mon, 14 Nov 2022 11:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xgkgU+XJK79fNtmiiykE65yOYhyetkrTOcQMcl/CZJ8=; b=dDYVgHhmha1NxtiYQrt/rWBs0feFsx2LKpDZacWco2+/xjuJ4i9EdLPZYJrls6b6hE JOsOMx9dQU5J7msJp3jJetYQxd3p2PuK7qyVYct893G8pZfSzcuZ9SoEjZvdqwxFJ0Zv dST309VowM/mHEKLOFPG03JI+Wvh+CLiFP/HzNoYFvStwCBLjavOVujZOME86uio4LTS P9EmujlrnSVtl7H3DWpzSLSWl4SCreFHTQNBAwGkUKhIlZnNLyewd7wkvIeEYFgGFiNz cFV1w/AiZGZguTCqwVDomg9EUuxkLFfsEkek4XqKvB9C8FjQHqSZKVEiFv1L+OEag6X0 9B8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xgkgU+XJK79fNtmiiykE65yOYhyetkrTOcQMcl/CZJ8=; b=EabVxUKZQlmYzthtYlyYMzwo/DuI+KbOwbiqZ/dqsTwsTlPv+6JHghEvPFYzUbZBUF 2csV22eVKGc/KAdSd8mOhe0tTYD94Ixr9wERSLs/W2eUYphZo9P5HwS6aHZG9BTWVCXv pkBgL1dnQnV+XUNsP05c8loczEhDrYnJT7y6Xt2CmNQkaD92luYOkx4E1axyKtGBiTj8 TKLx6Sh7qb7JPHQHkYA4hW4ka425P5NX/zAkqs0BucHmkma1BLTeJumMOn8NC+INNBrv PkKCmZVI7NWy3rBExITcUBFbPde5EA3meKjeBa/7/EMMmQ94IsSx+ejlhFi1ZhxaQvUc Vu9A== X-Gm-Message-State: ANoB5plI+HYSSOWRhRkohEIey8sImQYtsHpa6/8OLRAkBolXxuKux9X7 9mKBQURSnSG3WinVZCu+clk= X-Google-Smtp-Source: AA0mqf5NrXQC9j3yvaQxmK6T+GZXv6adycdupZEpJskbybTG3KPOSJYuASy86evhxQ7UbgdKGMG3IA== X-Received: by 2002:a17:906:c00c:b0:7ae:e6ac:2427 with SMTP id e12-20020a170906c00c00b007aee6ac2427mr7498440ejz.345.1668455604968; Mon, 14 Nov 2022 11:53:24 -0800 (PST) Received: from skbuf ([188.25.170.202]) by smtp.gmail.com with ESMTPSA id v17-20020a1709067d9100b0074134543f82sm4614809ejo.90.2022.11.14.11.53.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Nov 2022 11:53:24 -0800 (PST) Date: Mon, 14 Nov 2022 21:53:21 +0200 From: Vladimir Oltean To: Sean Anderson Cc: Vladimir Oltean , Heiner Kallweit , Russell King , "netdev@vger.kernel.org" , Eric Dumazet , Paolo Abeni , Jakub Kicinski , "linux-kernel@vger.kernel.org" , Andrew Lunn , Ioana Ciornei , Madalin Bucur , "David S . Miller" , Alexandre Belloni , Benjamin Herrenschmidt , Claudiu Manoil , Florian Fainelli , Frank Rowand , Krzysztof Kozlowski , Leo Li , Michael Ellerman , Paul Mackerras , Rob Herring , Saravana Kannan , Shawn Guo , "UNGLinuxDriver@microchip.com" , Vivien Didelot , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , Arnd Bergmann , Marc Zyngier Subject: Re: [PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner Message-ID: <20221114195321.uludij5x747uzcxr@skbuf> References: <20221103210650.2325784-1-sean.anderson@seco.com> <20221109224110.erfaftzja4fybdbc@skbuf> <20221110152925.3gkkp5opf74oqrxb@skbuf> <7b4fb14f-1ca0-e4f8-46ca-3884392627c2@seco.com> <20221110160008.6t53ouoxqeu7w7qr@skbuf> <20221114172357.hdzua4xo7wixtbgs@skbuf> <209a0d25-f109-601f-d6f6-1adc44103aee@seco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <209a0d25-f109-601f-d6f6-1adc44103aee@seco.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221114_115333_844093_BB442D1C X-CRM114-Status: GOOD ( 40.76 ) 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 Mon, Nov 14, 2022 at 01:08:03PM -0500, Sean Anderson wrote: > On 11/14/22 12:23, Vladimir Oltean wrote: > > On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote: > >> these will probably be in device trees for a year before the kernel > >> starts using them. But once that is done, we are free to require them. > > > > Sorry, you need to propose something that is not "we can break compatibility > > with today's device trees one year from now". > > But only if the kernel gets updated and not the device tree. When can > such a situation occur? Are we stuck with this for the next 10 years all > because someone may have a device tree which they compiled in 2017, and > *insist* on using the latest kernel with? Is this how you run your > systems? I'm a developer (and I work on other platforms than the ones you're planning to break), so the answer to this question doesn't mean a thing. > We don't get the device tree from firmware on this platform; usually it > is bundled with the kernel in a FIT or loaded from the same disk > partition as the kernel. I can imagine that they might not always be > updated at exactly the same time, but this is nuts. What does "this" platform mean exactly? There are many platforms to which you've added compatible strings to keep things working assuming a dtb update, many of them very old. And those to which you did are not by far all that exist. There is no requirement that all platform device trees are upstreamed to the Linux kernel. > The original device tree is broken because it doesn't include compatible > strings for devices on a generic bus. There's no way to fix that other > than hard-coding the driver. This can be done for some buses, but this > is an MDIO bus and we already assume devices without compatibles are > PHYs. Let's be clear about this. It's "broken" in the sense that you don't like the way in which it works, not in the sense that it results in a system that doesn't work. And not having a compatible string is just as broken as it is for other devices with detectable device IDs, like Ethernet PHYs in general, PCI devices, etc. The way in which that works here, specifically, is that a generic PHY driver is bound to the Lynx PCS devices, driver which does nothing since nobody calls phy_attach_direct() to it. Then, using fwnode_mdio_find_device(), you follow the pcsphy-handle and you get a reference to the mdio_device (parent class of phy_device) object that resulted from the generic PHY driver probing on the PCS, and you program the PCS to do what you want. The PHY core does assume that mdio_devices without compatible strings are phy_devices, but also makes exceptions (and warns about it) - see commit ae461131960b ("of: of_mdio: Add a whitelist of PHY compatibilities."). Maybe the reverse exception could also be made, and a warning for that be added as well. > In the next version of this series, I will include a compatibility > function which can bind a driver automatically if one is missing when > looking up a phy. But I would really like to have an exit strategy. You'll have to get agreement from higher level maintainers than me that the strategy "wait one year, break old device trees" is okay. Generally we wouldn't have answers to this kind of questions that depend on whom you ask. Otherwise.. we would all know whom to ask and whom not to ;) Sadly I haven't found anything "official" in either Documentation/devicetree/usage-model.rst or Documentation/process/submitting-patches.rst. Maybe I missed it? I've added Arnd Bergmann for an ack, and also Marc Zyngier, not because of any particular connection to what's being changed here, but because I happen to know that he might have strong opinions on the topic :) Full context here: https://patchwork.kernel.org/project/netdevbpf/cover/20221103210650.2325784-1-sean.anderson@seco.com/ If I'm the only one opposing this, I guess I'll look elsewhere. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel