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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FF50C432BE for ; Sat, 28 Aug 2021 17:02:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1286A60E97 for ; Sat, 28 Aug 2021 17:02:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233282AbhH1RCz (ORCPT ); Sat, 28 Aug 2021 13:02:55 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:46128 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230470AbhH1RCy (ORCPT ); Sat, 28 Aug 2021 13:02:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=34N6KPTUp7LARCoRQy4s+AFxJpLySRpClrFRIaL/Ojg=; b=2pYR2t2UYn1zmKDF18hnELZW1t ifIU8YFelD1D6urPBYtDCOgHOzEXPjmJZEHF9NX0k+96wo4lnrN8n5dcCUbnnz1BHGWEq31Wrdifl KHaqQ7hrhGZyiLgD0hYT8rOc15OG8DYk8J5XK85FZx4CL/Q84Qw2m6m0DCfo9BdoBB30=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1mK1iG-004IxO-QV; Sat, 28 Aug 2021 19:01:48 +0200 Date: Sat, 28 Aug 2021 19:01:48 +0200 From: Andrew Lunn To: Saravana Kannan Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Linus Walleij , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Len Brown , Alvin Sipraga , kernel-team@android.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v1 1/2] driver core: fw_devlink: Add support for FWNODE_FLAG_BROKEN_PARENT Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Fri, Aug 27, 2021 at 02:33:02PM -0700, Saravana Kannan wrote: > On Fri, Aug 27, 2021 at 1:11 PM Andrew Lunn wrote: > > > > > > I've not yet looked at plain Ethernet drivers. This pattern could also > > > > exist there. And i wonder about other complex structures, i2c bus > > > > multiplexors, you can have interrupt controllers as i2c devices, > > > > etc. So the general case could exist in other places. > > > > > > I haven't seen any generic issues like this reported so far. It's only > > > after adding phy-handle that we are hitting these issues with DSA > > > switches. > > > > Can you run your parser over the 2250 DTB blobs and see how many > > children have dependencies on a parent? That could give us an idea how > > many moles need whacking. And maybe, where in the tree they are > > hiding? > > You are only responding to part of my email. As I said in my previous > email: "There are plenty of cases where it's better to delay the child > device's probe until the parent finishes. You even gave an example[7] > where it would help avoid unnecessary deferred probes." Can you please > give your thoughts on the rest of the points I made too? I must admit, my main problem at the moment is -rc1 in two weeks time. It seems like a number of board with Ethernet switches will be broken, that worked before. phy-handle is not limited to switch drivers, it is also used for Ethernet drivers. So it could be, a number of Ethernet drivers are also going to be broken in -rc1? But the issues sounds not to be specific to phy-handle, but any phandle that points back to a parent. So it could be drivers outside of networking are also going to be broken with -rc1? You have been very focused on one or two drivers. I would much rather see you getting an idea of how wide spread this problem is, and what should we do for -rc1? Even if modifying DSA drivers to component drivers is possible, while not breaking backwards compatibility with DT, it is not going to happen over night. That is something for the next merge window, not this merge window. So reverting the phy-handle seems like part of the fix for -rc1. But until you look at those 2250 DTB blobs, we have no idea if that is sufficient for -rc1. Andrew