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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 024BDC432BE for ; Tue, 31 Aug 2021 19:27:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DDB7C61053 for ; Tue, 31 Aug 2021 19:27:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240789AbhHaT2E (ORCPT ); Tue, 31 Aug 2021 15:28:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240607AbhHaT2C (ORCPT ); Tue, 31 Aug 2021 15:28:02 -0400 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3459CC061764 for ; Tue, 31 Aug 2021 12:27:07 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id z18so419190ybg.8 for ; Tue, 31 Aug 2021 12:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MiOmjNUrQTixfmxuIIBr9b2mal/6TnKrZ2hUhLBArdA=; b=LQ5DfuisFfwLylONTNqaEbGbMDFUlrFBwbH7uzQmaiairk1VdXureNF3ast1bdtiHJ 1OhdNZOseCGceTZIndqQ3bkMer4XSld2e7dnAd9uMTEiA7PS8GaXCTdO3IDSicU2Sopy pPjQFl+IV7DnIZbTdxmgiujRlcFdDgQnyqd0HafORlQfaUcKzeJM+rtI6EvQcmE9wSPe toKIFSnBzzG7JSG3KcpCza54fQ+OUPbOrF9BJ/H9MuW3cKGhLbtDSLThszd042O+RdCn EMxVbcUSYa78NwDnBcDw/h4mGE0H0xlIhxDKiCa6UwAdwH/aWI6HM1IWE+Uv/Z3fLQx9 QWDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MiOmjNUrQTixfmxuIIBr9b2mal/6TnKrZ2hUhLBArdA=; b=IrPR6OtBiWSl/My4wM4zng6OmYE9HeE2p7pWUUUz6BXGL5n4XluZaqcSPvuKYMmQ0j W2r3RiriUWW5BZyd6ujwx/JWeoNwcqhSnpi5N3CyPaki/CaQNVLkCtj0fPYVf9IUapxv TF3gHr5MStDdLmreZyKab8wQFaexmDxRHaLtZBGnxCrN4urDqZOArdBGQ6PMopmcJyPw S9O+Vio15gn1b4leGYLWLukjZL3Vrk9t7WwpdvWKzaULOgk8hK9xlwqne8p+i1EA1G1t efr8CFECFPoLAYrrK/tCiP9lriSHaAQdDDt9+qhYdKvrGvm0C2HpYH0qNU8h9iZEeunq 1cQQ== X-Gm-Message-State: AOAM532MzYtg++smb1555J5WX/EHky6hetqFLty4wDqktQth8D53lfnv lQwAw+xEhAvUCO/JUIzoqBXZIlezieiqvX61d2HEDA== X-Google-Smtp-Source: ABdhPJzbL1ke9geoFZR/f+VEBhnoIaAb/U4CLoY6acRJ2ip3Tlo8GdKSCEA0zQzpPM8yo2/DFDO0RlBa+uEN/mbu/fY= X-Received: by 2002:a25:d213:: with SMTP id j19mr33717553ybg.20.1630438026156; Tue, 31 Aug 2021 12:27:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Saravana Kannan Date: Tue, 31 Aug 2021 12:26:30 -0700 Message-ID: Subject: Re: [PATCH v1 1/2] driver core: fw_devlink: Add support for FWNODE_FLAG_BROKEN_PARENT To: Andrew Lunn 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 31, 2021 at 6:16 AM Andrew Lunn wrote: > > > > 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? > > > > Again, in those cases, based on your FEC example, fw_devlink=on > > actually improves things. > > Debatable. I did some testing. As expected some boards with Ethernet > switches are now broken. To clarify myself, I'm saying the patch to parse "ethernet" [8] will make things better with fw_devlink=on for FEC. Not sure if you tested that patch or not. And yes, "phy-handle" will make things worse for switches because it has two issues that need to be fixed. One is this deferred probe thing for which I gave a patch in the previous email and the other is what Marek reported (fix in the works). So can you revert "phy-handle" support and test with [8] and you should see things be better with fw_devlink=on. [8] - https://lore.kernel.org/netdev/CAGETcx9=AyEfjX_-adgRuX=8a0MkLnj8sy2KJGhxpNCinJu4yA@mail.gmail.com/ > Without fw_devlink=on, some boards are not > optimal, but they actually work. With it, they are broken. > > I did a bisect, and they have been broken since: > > ea718c699055c8566eb64432388a04974c43b2ea is the first bad commit > commit ea718c699055c8566eb64432388a04974c43b2ea > Author: Saravana Kannan > Date: Tue Mar 2 13:11:32 2021 -0800 > > Revert "Revert "driver core: Set fw_devlink=on by default"" > > This reverts commit 3e4c982f1ce75faf5314477b8da296d2d00919df. > > Since all reported issues due to fw_devlink=on should be addressed by > this series, revert the revert. fw_devlink=on Take II. > > Signed-off-by: Saravana Kannan > Link: https://lore.kernel.org/r/20210302211133.2244281-4-saravanak@google.com > Signed-off-by: Greg Kroah-Hartman > > drivers/base/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > So however it is fixed, it needs to go into stable, not just -rc1. Not sure what was the tip of the tree with which you bisected. For example, if phy-handle broke things, bisect could still point at this patch above depending on whether the first bisect is good/bad. Because reverting this patch effectively disabled phy-handle parsing too. To be clear, I'm not saying things aren't broken. I'm just pointing out some nuances with the bisect that we need to be aware of. > > Again, it's not a widespread problem as I explained before. > > fw_devlink=on has been the default for 2 kernel versions now. With no > > unfixed reported issues. > > Given that some Ethernet switches have been broken all that time, i > wonder what else has been broken? Normally, the kernel which is > release in December becomes the next LTS. It then gets picked up by > the distros and more wide spread tested. So it could be, you get a > flood of reports in January and February about things which are > broken. This is why i don't think you should be relying on bug > reports, you should be taking a more proactive stance and trying to > analyse the DTB blobs. As I mentioned earlier, just looking at DTB doesn't tell me much because the driver could still be fine depending on how it's written. Also, I don't have an easy way to do this. If I find a way, I'll do it. Btw, most bug reports that have been raised have been fixed with generic fixes that address general DT patterns. For example, fw_devlink has cycle detection built in, has support for devices that never get probed, etc. Enabling fw_devlink=on and handling bug reports with generic fixes has worked well so far to get fw_devlink to where it is today. I've tried to be very quick in responding to fw_devlink issues -- and that has worked out so far and hopefully it'll continue to work out. > I will spend some time trying out your proposed fix. See if they are a > quick fix for stable. Thanks for testing it out. And worst case, we'll revert phy-handle support. -Saravana