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 2C96DC04A68 for ; Wed, 27 Jul 2022 18:43:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238538AbiG0SnG (ORCPT ); Wed, 27 Jul 2022 14:43:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239023AbiG0Smr (ORCPT ); Wed, 27 Jul 2022 14:42:47 -0400 Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96E3E14095 for ; Wed, 27 Jul 2022 10:40:14 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id s204so21609284oif.5 for ; Wed, 27 Jul 2022 10:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=auHRXEOVurCyZQ+OD7PQkEunz1CClGN/q8cW3ry8A/g=; b=akCwbqOsMLF9KceYPsH4teUTmTLQJm9UmCBAtjLicHsInsBvGqYezvSQ7Vq/DLgJMh JaMrPsWCtssM6IJjbvwzpQGnOvwF10M7JqDIOvJLH/ZEBkayv0rbTQ5U9Q0fzE0qMaQa ujphGuNbPVj/jV8bmrH0778cavVEpkTM1FgZZZrUIoCZGLfBp/lp6x38VkwFC4q4MZzn hpetGpid8YOeWrW6XhpilDqQjtWyv+SBQeor7hjSo40dju6z9S6yJCy5WM7BD/IJZOVQ qWLBVAzv5fEclDkjni97HZAexI7xc00wO+kFrsW+ieELPQc7D13hfaFph9u7k40FGJ0S fpow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=auHRXEOVurCyZQ+OD7PQkEunz1CClGN/q8cW3ry8A/g=; b=ZKVCoCD4A+ufo7IvZuwgiYOjUjoxKzXKweAIimZV8floYZbxp8jmUqzLt+r+aYtNJq +jmuo06Cpjv6URZeSJJLcAx2PHes0s12cZPbq1o5QaIjjvOF6VSPhNYByCgTqac3gvLR UrIK4a9kPR4XBIhBjqtwyYhAN4/2ihqr5x9wWmfB4fQLi9zAt4LJTt73qttHYFjbBGrh RRzCQ1wLXj5k44y4AtsAifehJkxbGBF3ZmBdVNGJxjIKbbb2t7pE+7ep3fQXWBahoYnd y+OMsEqumy7oyf/AahLLmJFYhIXhqMXgUJI7q8wtMqOfkHL5MIT7wmYqBImyDgO3a0sL onpQ== X-Gm-Message-State: AJIora93fBd79/zP7q3Q6xnxRVHynzKR6Fl0NIQQSBpWWqt6ryao8rRA C9Mo82bwEyTVpjCUt5h16zfYp8qYo3EXA5eQiUNceA== X-Google-Smtp-Source: AGRyM1tmJ3CJLPbWQymZfXyGJNkgqaJhPLCByqEuYO5lRFaghvav9GCSr0ZX0nazp2AbJYqjEUkrSLAJV1vzXBhmZRw= X-Received: by 2002:aca:ba86:0:b0:33a:c6f7:3001 with SMTP id k128-20020acaba86000000b0033ac6f73001mr2382818oif.5.1658943612325; Wed, 27 Jul 2022 10:40:12 -0700 (PDT) MIME-Version: 1.0 References: <20220727064321.2953971-1-mw@semihalf.com> <20220727064321.2953971-7-mw@semihalf.com> <20220727143147.u6yd6wqslilspyhw@skbuf> <20220727163848.f4e2b263zz3vl2hc@skbuf> In-Reply-To: <20220727163848.f4e2b263zz3vl2hc@skbuf> From: Marcin Wojtas Date: Wed, 27 Jul 2022 19:40:00 +0200 Message-ID: Subject: Re: [net-next: PATCH v3 6/8] net: core: switch to fwnode_find_net_device_by_node() To: Vladimir Oltean Cc: Linux Kernel Mailing List , ACPI Devel Maling List , netdev , "Rafael J. Wysocki" , Andy Shevchenko , Sean Wang , Landen Chao , Linus Walleij , Andrew Lunn , Vivien Didelot , Florian Fainelli , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Russell King - ARM Linux , Heiner Kallweit , Grzegorz Bernacki , Grzegorz Jaszczyk , Tomasz Nowicki , Samer El-Haj-Mahmoud , upstream@semihalf.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org =C5=9Br., 27 lip 2022 o 18:38 Vladimir Oltean napisa=C5= =82(a): > > On Wed, Jul 27, 2022 at 05:18:16PM +0200, Marcin Wojtas wrote: > > Do you mean a situation analogous to what I addressed in: > > [net-next: PATCH v3 4/8] net: mvpp2: initialize port fwnode pointer > > ? > > Not sure if "analogous" is the right word. My estimation is that the > overwhelmingly vast majority of DSA masters can be found by DSA simply > due to the SET_NETDEV_DEV() call that the Ethernet drivers need to make > anyway. I see that mvpp2 also needed commit c4053ef32208 ("net: mvpp2: > initialize port of_node pointer"), but that isn't needed in general, and > I can't tell you exactly why it is needed there, I don't know enough > about the mvpp2 driver. SET_NETDEV_DEV() fills net_device->dev.parent with &pdev->dev and in most cases it is sufficient apparently it is sufficient for fwnode_find_parent_dev_match (at least tests with mvneta case proves it's fine). We have some corner cases though: * mvpp2 -> single controller can handle up to 3 net_devices and therefore we need device_set_node() to make this work. I think dpaa2 is a similar case * PCIE drivers with extra DT description (I think that's the case of enetc)= . > > > I found indeed a couple of drivers that may require a similar change > > (e.g. dpaa2). > > There I can tell you why the dpaa2-mac code mangles with net_dev->dev.of_= node, > but I'd rather not go into an explanation that essentially doesn't matter= . > The point is that you'd be mistaken to think that only the drivers which > touch the net device's ->dev->of_node are the ones that need updating > for your series to not cause regressions. As above - SET_NETDEV_DEV() should be fine in most cases, but we can never be 100% sure untils it's verified. > > > IMO we have 2 options: > > - update these drivers > > - add some kind of fallback? If yes, I am wondering about an elegant > > solution - maybe add an extra check inside > > fwnode_find_parent_dev_match? > > > > What would you suggest? > > Fixing fwnode_find_parent_dev_match(), of course. This change broke DSA > on my LS1028A system (master in drivers/net/ethernet/freescale/enetc/) > and LS1021A (master in drivers/net/ethernet/freescale/gianfar.c). Can you please check applying following diff: --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -695,20 +695,22 @@ EXPORT_SYMBOL_GPL(fwnode_get_nth_parent); * The routine can be used e.g. as a callback for class_find_device(). * * Returns: %1 - match is found * %0 - match not found */ int fwnode_find_parent_dev_match(struct device *dev, const void *data) { for (; dev; dev =3D dev->parent) { if (device_match_fwnode(dev, data)) return 1; + else if (device_match_of_node(dev, to_of_node(data)) + return 1; } return 0; } EXPORT_SYMBOL_GPL(fwnode_find_parent_dev_match); Thanks for the review and test. Marcin