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=-3.8 required=3.0 tests=BAYES_00, 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 5BCAAC43462 for ; Mon, 19 Apr 2021 09:34:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 39CEA6101D for ; Mon, 19 Apr 2021 09:34:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238579AbhDSJeq (ORCPT ); Mon, 19 Apr 2021 05:34:46 -0400 Received: from gw.atmark-techno.com ([13.115.124.170]:37258 "EHLO gw.atmark-techno.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237860AbhDSJej (ORCPT ); Mon, 19 Apr 2021 05:34:39 -0400 Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by gw.atmark-techno.com (Postfix) with ESMTPS id 8EF1580490 for ; Mon, 19 Apr 2021 18:34:08 +0900 (JST) Received: by mail-il1-f197.google.com with SMTP id i27-20020a056e021d1bb02901699edaa0aaso10873849ila.12 for ; Mon, 19 Apr 2021 02:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=DiVQ7koP22ctz4HHQKAKfB5+ZmsQ1OtLX1vcKNImeLTB2RrmnuXjHRI5ls9hjgRTEv Yri+BW56jZqMFZ6kYOQ0DvwhwL5THZNmO9ejTP5xXf0wUhB2M777kEvcb5962tPto7D7 M2cir+8x3JHVFLTilRkw7wyPWthmidr3TsjT6nuI2lze2TYKn9tlKwV6Wtvhn3JQMoWF gQqs/EwZfu7rpqOTZ9nlZk8FK7L0KCWYmK8AL76fyMZBZTnYCX06tt6okYZeW806J68A JlZDEH0SdkAk0jdtRJiaP6VTQ0RQDTWm6GF+dhC9T21mUS+qEAHHuDjExaIzOWhXEMJ1 UE4A== X-Gm-Message-State: AOAM532MdpWwYi5aEsDI9W0P/wfBX3sFAxpFvB6qBN6HrlCAK/f78a7r BYvYkgZGkAit2LehCwdE6ez6rUiEGD98N7gnO/SuCeVrydvm/YtHa2l4zYcP8/7ft2F9Ft5Du9M 6mEGU265DnQqJnohlWcYJnZiWe+z+ X-Received: by 2002:a63:1665:: with SMTP id 37mr11208897pgw.31.1618824837072; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3BVfHB/Iu3InVzb+YLUkuY7/BfcYMlC0sOGsbJiks+G4SQp5aPsproxuobb7vRE8Qif9k+g== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208853pgw.31.1618824836841; Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from pc-0115 (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id x18sm10982637pjn.51.2021.04.19.02.33.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from martinet by pc-0115 with local (Exim 4.94) (envelope-from ) id 1lYQHy-002k7D-3h; Mon, 19 Apr 2021 18:33:54 +0900 Date: Mon, 19 Apr 2021 18:33:44 +0900 From: Dominique MARTINET To: Geert Uytterhoeven Cc: "Alice Guo (OSS)" , gregkh@linuxfoundation.org, rafael@kernel.org, horia.geanta@nxp.com, aymen.sghaier@nxp.com, herbert@gondor.apana.org.au, davem@davemloft.net, tony@atomide.com, geert+renesas@glider.be, mturquette@baylibre.com, sboyd@kernel.org, vkoul@kernel.org, peter.ujfalusi@gmail.com, a.hajda@samsung.com, narmstrong@baylibre.com, robert.foss@linaro.org, airlied@linux.ie, daniel@ffwll.ch, khilman@baylibre.com, tomba@kernel.org, jyri.sarha@iki.fi, joro@8bytes.org, will@kernel.org, mchehab@kernel.org, ulf.hansson@linaro.org, adrian.hunter@intel.com, kishon@ti.com, kuba@kernel.org, linus.walleij@linaro.org, Roy.Pledge@nxp.com, leoyang.li@nxp.com, ssantosh@kernel.org, matthias.bgg@gmail.com, edubezval@gmail.com, j-keerthy@ti.com, balbi@kernel.org, linux@prisktech.co.nz, stern@rowland.harvard.edu, wim@linux-watchdog.org, linux@roeck-us.net, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, linux-omap@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, dmaengine@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, linux-media@vger.kernel.org, linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-phy@lists.infradead.org, linux-gpio@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-staging@lists.linux.dev, linux-mediatek@lists.infradead.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org, Arnd Bergmann Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Message-ID: References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > This is going to need quite some more work to be acceptable, in my > > opinion, but I think it should be possible. > > In general, this is very hard to do, IMHO. Some drivers may be used on > multiple platforms, some of them registering an SoC device, some of > them not registering an SoC device. So there is no way to know the > difference between "SoC device not registered, intentionally", and > "SoC device not yet registered". Hm, good point, I was probably a bit too optimistic if there are devices which don't register any soc yet have drivers which want one; I don't see how to make the difference indeed... And that does mean we can't just defer all the time. > soc_device_match() should only be used as a last resort, to identify > systems that cannot be identified otherwise. Typically this is used for > quirks, which should only be enabled on a very specific subset of > systems. IMHO such systems should make sure soc_device_match() > is available early, by registering their SoC device early. I definitely agree there, my suggestion to defer was only because I know of no other way to influence the ordering of drivers loading reliably and gave up on soc being init'd early. In this particular case the problem is that since 7d981405d0fd ("soc: imx8m: change to use platform driver") the soc probe tries to use the nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet. So soc loading gets pushed back to the end of the list because it gets defered and other drivers relying on soc_device_match get confused because they wrongly think a device doesn't match a quirk when it actually does. If there is a way to ensure the nvmem driver gets loaded before the soc, that would also solve the problem nicely, and avoid the need to mess with all the ~50 drivers which use it. Is there a way to control in what order drivers get loaded? Something in the dtb perhaps? Thanks, -- Dominique 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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 6BB37C43462 for ; Mon, 19 Apr 2021 09:34:13 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B691061245 for ; Mon, 19 Apr 2021 09:34:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B691061245 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atmark-techno.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 43D18402AF; Mon, 19 Apr 2021 09:34:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9qCPDLQoEGl; Mon, 19 Apr 2021 09:34:11 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp4.osuosl.org (Postfix) with ESMTP id 413C340397; Mon, 19 Apr 2021 09:34:06 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 10A9AC000F; Mon, 19 Apr 2021 09:34:06 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3C7A6C000B for ; Mon, 19 Apr 2021 09:34:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2B0C4835E0 for ; Mon, 19 Apr 2021 09:34:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK-zSmXRwmgu for ; Mon, 19 Apr 2021 09:33:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from gw.atmark-techno.com (gw.atmark-techno.com [13.115.124.170]) by smtp1.osuosl.org (Postfix) with ESMTP id B233583579 for ; Mon, 19 Apr 2021 09:33:59 +0000 (UTC) Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by gw.atmark-techno.com (Postfix) with ESMTPS id 0500F80491 for ; Mon, 19 Apr 2021 18:33:58 +0900 (JST) Received: by mail-pg1-f198.google.com with SMTP id r27-20020a63441b0000b02901e65403d377so5862694pga.14 for ; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=FcOkAreAOATnZITm4i115FFhMGcpAcdctaxjAXOSfyJ1DzDwJNd09gEZwfaV6BObrL ffA0GnSbVMyXj3pCFQQxH+vZm/I/QQJrDiW3FhGmh2igzYN7+D/9ZuijuHwDuQWS6HOY DwzIj9rgJuD5hXjCjEj7LvX2YkRQ88t+ucjXGnIytCL57TshyalPPyiUq/MxqxwN++JX bgMxSTqJSA8ToQza8rSXizxQrANDUYjldtb0bxXxZSAJGSnH5m/Ngh9MVEW/V3Tk5J65 k1lj6BTVGxHwz4h7qXh50Mon9MHwZbZcmiWoGkcMVb5ZM0/wt9ZWbETrpJxTA/4GI4V8 R7wQ== X-Gm-Message-State: AOAM532SD29/vB+bOP2tIXoWoSQwLDOnqEdb2xXU3mlfRHvkd6ZIuunt Aah7e54kHLxQch1QOrObTfmHazJunYnoThtALZofOvP6IKJp8Pw+22Srr1NRZqV3Qgj3Fi6pY2s aU09miNWh5LEuk85B6Krl+eWrgcuTyIE1Vw== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208900pgw.31.1618824837070; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3BVfHB/Iu3InVzb+YLUkuY7/BfcYMlC0sOGsbJiks+G4SQp5aPsproxuobb7vRE8Qif9k+g== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208853pgw.31.1618824836841; Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from pc-0115 (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id x18sm10982637pjn.51.2021.04.19.02.33.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from martinet by pc-0115 with local (Exim 4.94) (envelope-from ) id 1lYQHy-002k7D-3h; Mon, 19 Apr 2021 18:33:54 +0900 Date: Mon, 19 Apr 2021 18:33:44 +0900 From: Dominique MARTINET To: Geert Uytterhoeven Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Message-ID: References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: ulf.hansson@linaro.org, aymen.sghaier@nxp.com, geert+renesas@glider.be, rafael@kernel.org, airlied@linux.ie, mturquette@baylibre.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, a.hajda@samsung.com, netdev@vger.kernel.org, linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com, linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org, wim@linux-watchdog.org, herbert@gondor.apana.org.au, horia.geanta@nxp.com, khilman@baylibre.com, narmstrong@baylibre.com, linux-staging@lists.linux.dev, iommu@lists.linux-foundation.org, kishon@ti.com, tony@atomide.com, linux-omap@vger.kernel.org, stern@rowland.harvard.edu, kuba@kernel.org, linus.walleij@linaro.org, linux@roeck-us.net, linux-media@vger.kernel.org, linux-watchdog@vger.kernel.org, will@kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, edubezval@gmail.com, linux-gpio@vger.kernel.org, linux-mediatek@lists.infradead.org, ssantosh@kernel.org, matthias.bgg@gmail.com, linux-amlogic@lists.infradead.org, mchehab@kernel.org, linux-arm-kernel@lists.infradead.org, "Alice Guo \(OSS\)" , balbi@kernel.org, tomba@kernel.org, sboyd@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org, adrian.hunter@intel.com, robert.foss@linaro.org, leoyang.li@nxp.com, linux@prisktech.co.nz, vkoul@kernel.org, Arnd Bergmann , linux-crypto@vger.kernel.org, daniel@ffwll.ch, j-keerthy@ti.com, dmaengine@vger.kernel.org, Roy.Pledge@nxp.com, jyri.sarha@iki.fi, davem@davemloft.net X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > This is going to need quite some more work to be acceptable, in my > > opinion, but I think it should be possible. > > In general, this is very hard to do, IMHO. Some drivers may be used on > multiple platforms, some of them registering an SoC device, some of > them not registering an SoC device. So there is no way to know the > difference between "SoC device not registered, intentionally", and > "SoC device not yet registered". Hm, good point, I was probably a bit too optimistic if there are devices which don't register any soc yet have drivers which want one; I don't see how to make the difference indeed... And that does mean we can't just defer all the time. > soc_device_match() should only be used as a last resort, to identify > systems that cannot be identified otherwise. Typically this is used for > quirks, which should only be enabled on a very specific subset of > systems. IMHO such systems should make sure soc_device_match() > is available early, by registering their SoC device early. I definitely agree there, my suggestion to defer was only because I know of no other way to influence the ordering of drivers loading reliably and gave up on soc being init'd early. In this particular case the problem is that since 7d981405d0fd ("soc: imx8m: change to use platform driver") the soc probe tries to use the nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet. So soc loading gets pushed back to the end of the list because it gets defered and other drivers relying on soc_device_match get confused because they wrongly think a device doesn't match a quirk when it actually does. If there is a way to ensure the nvmem driver gets loaded before the soc, that would also solve the problem nicely, and avoid the need to mess with all the ~50 drivers which use it. Is there a way to control in what order drivers get loaded? Something in the dtb perhaps? Thanks, -- Dominique _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 C4BAFC433ED for ; Mon, 19 Apr 2021 09:34:11 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 752DA6101D for ; Mon, 19 Apr 2021 09:34:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 752DA6101D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atmark-techno.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D5D9F89E01; Mon, 19 Apr 2021 09:34:10 +0000 (UTC) Received: from gw.atmark-techno.com (gw.atmark-techno.com [13.115.124.170]) by gabe.freedesktop.org (Postfix) with ESMTP id 0B11989E01 for ; Mon, 19 Apr 2021 09:34:09 +0000 (UTC) Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by gw.atmark-techno.com (Postfix) with ESMTPS id B08568049E for ; Mon, 19 Apr 2021 18:34:08 +0900 (JST) Received: by mail-il1-f197.google.com with SMTP id q7-20020a056e0215c7b029013ea7521279so10913391ilu.11 for ; Mon, 19 Apr 2021 02:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=Nbgf+Yn/+UTfJ4zIaDILJPajRSdFhlOA0IwIOAN6Qx7kG+doUgSugmUZIsq9SCHTgm kC5iRBgeSvB98W7+CBbioVbNCpCgWZTPHB+QoC4rxofm1vMgojFZ4WHycDBo56iU0yh0 k2muSyl/T6btUQa6BQM5p5jDq20AeQkMK0ZU88GGMx0BXVoqtXueQdh7zok7DYBAWQMR tbViKgcgAu/3oKPJHHJAs17EvVTF2kKjN1tyKy2stPyI9/gf4KXjtbyfPD/kw+nRwYfW Vs2H1arRf2fHyTALg2LYqVaNnUIBGwDZ6QLwRfw1aY4Oso8XlyUoJTzF1sPqpUMJwacd dJNg== X-Gm-Message-State: AOAM530o2mKk9bEDGw6Ng1Mz4WrtObzalJj+THR/fpMJTX5zG7W1iEof X7VwKBxfX776TsqKEOsWjtQl7dKq6RECnQvxGMUp/hsPe2Y03+y64dxqiDXNDIdqJZ/5jgm6WkF 4bbCA2XnoMiF5WPyXNh8DqDva5rg+T2t+ X-Received: by 2002:a63:1665:: with SMTP id 37mr11208875pgw.31.1618824837066; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3BVfHB/Iu3InVzb+YLUkuY7/BfcYMlC0sOGsbJiks+G4SQp5aPsproxuobb7vRE8Qif9k+g== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208853pgw.31.1618824836841; Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from pc-0115 (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id x18sm10982637pjn.51.2021.04.19.02.33.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from martinet by pc-0115 with local (Exim 4.94) (envelope-from ) id 1lYQHy-002k7D-3h; Mon, 19 Apr 2021 18:33:54 +0900 Date: Mon, 19 Apr 2021 18:33:44 +0900 From: Dominique MARTINET To: Geert Uytterhoeven Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Message-ID: References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ulf.hansson@linaro.org, aymen.sghaier@nxp.com, geert+renesas@glider.be, rafael@kernel.org, airlied@linux.ie, mturquette@baylibre.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, a.hajda@samsung.com, netdev@vger.kernel.org, linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com, linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org, wim@linux-watchdog.org, herbert@gondor.apana.org.au, horia.geanta@nxp.com, khilman@baylibre.com, joro@8bytes.org, narmstrong@baylibre.com, linux-staging@lists.linux.dev, iommu@lists.linux-foundation.org, kishon@ti.com, tony@atomide.com, linux-omap@vger.kernel.org, stern@rowland.harvard.edu, kuba@kernel.org, linux@roeck-us.net, linux-media@vger.kernel.org, linux-watchdog@vger.kernel.org, will@kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, edubezval@gmail.com, linux-gpio@vger.kernel.org, linux-mediatek@lists.infradead.org, ssantosh@kernel.org, matthias.bgg@gmail.com, linux-amlogic@lists.infradead.org, mchehab@kernel.org, linux-arm-kernel@lists.infradead.org, "Alice Guo \(OSS\)" , balbi@kernel.org, tomba@kernel.org, sboyd@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org, adrian.hunter@intel.com, robert.foss@linaro.org, leoyang.li@nxp.com, linux@prisktech.co.nz, vkoul@kernel.org, Arnd Bergmann , linux-crypto@vger.kernel.org, j-keerthy@ti.com, dmaengine@vger.kernel.org, Roy.Pledge@nxp.com, jyri.sarha@iki.fi, davem@davemloft.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > This is going to need quite some more work to be acceptable, in my > > opinion, but I think it should be possible. > > In general, this is very hard to do, IMHO. Some drivers may be used on > multiple platforms, some of them registering an SoC device, some of > them not registering an SoC device. So there is no way to know the > difference between "SoC device not registered, intentionally", and > "SoC device not yet registered". Hm, good point, I was probably a bit too optimistic if there are devices which don't register any soc yet have drivers which want one; I don't see how to make the difference indeed... And that does mean we can't just defer all the time. > soc_device_match() should only be used as a last resort, to identify > systems that cannot be identified otherwise. Typically this is used for > quirks, which should only be enabled on a very specific subset of > systems. IMHO such systems should make sure soc_device_match() > is available early, by registering their SoC device early. I definitely agree there, my suggestion to defer was only because I know of no other way to influence the ordering of drivers loading reliably and gave up on soc being init'd early. In this particular case the problem is that since 7d981405d0fd ("soc: imx8m: change to use platform driver") the soc probe tries to use the nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet. So soc loading gets pushed back to the end of the list because it gets defered and other drivers relying on soc_device_match get confused because they wrongly think a device doesn't match a quirk when it actually does. If there is a way to ensure the nvmem driver gets loaded before the soc, that would also solve the problem nicely, and avoid the need to mess with all the ~50 drivers which use it. Is there a way to control in what order drivers get loaded? Something in the dtb perhaps? Thanks, -- Dominique _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B319BC433ED for ; Mon, 19 Apr 2021 09:34:40 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 281FC6101D for ; Mon, 19 Apr 2021 09:34:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 281FC6101D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atmark-techno.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=5ojHqwpS3tNN7JYr5YagpYIJhMeaSpdRy77gn8DqCoc=; b=eE0XmtZeGyxuwLGSmTW5R9rS5 zGOEbQ4wAhIBImzoiJ70cp78dQ+xC1ZOuiHAs5WOKJoVNQVY38HSEU/0+2TX2n472vMRurR0MNy4P UC41HnhbSYVoRSdQaRTXPm6+yaFowFf+9T+F/leLc7lInMguyBguZduU0jfS5UGMLmkz454BjfST7 qVKfYkE4n1qcTXmzAw4qMi2SpQ0lqHppZpZMyMtwGtWfftc/9Lqu/0+ODHxkHIL2X5mZH3H9nqxZb N/a/XCSdHaOXyCMypwG+5fXfv8uy9eyTTYXY1NCUGFUc7ExoJfJ83aQ9kMdldFfWPa76Bwm1YIw/8 qVtscd4HA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIS-009Ysx-Db; Mon, 19 Apr 2021 09:34:24 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIO-009Yrt-J9 for linux-mediatek@desiato.infradead.org; Mon, 19 Apr 2021 09:34:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=kaQa/AbeFluWEL1g4bjzwaRow8 yXqSwa46A+gZEm4zoKnEIJXxcrDNvfQU+tuCrUePruxaaSObME882ZfGQufXF3gRp2DNjbZeR2Z/m E6cTn53sGJ4KJY/UkrTEps9vMJepxE4AReRwZSb5vVzWgLpsZ9CMoP13Gy1zqIjJV90SYlrxKv3t2 ftYnANI1/x7e4WQiVu0W4GzIBhHxk4vxxoAkgOYN1WlyeT7gq3dn1g1eFFu5MW9OTyDuFC/WUDWKE kWFosyKmEwPydot5gQM6oNn2jn3YylssPEsYFUBlDEfZQP44EX86E2HRVYEZ+XOj0so0NMTSyRvjO A5kodCQQ==; Received: from gw.atmark-techno.com ([13.115.124.170]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIE-00BERZ-Sm for linux-mediatek@lists.infradead.org; Mon, 19 Apr 2021 09:34:19 +0000 Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by gw.atmark-techno.com (Postfix) with ESMTPS id A2B158049B for ; Mon, 19 Apr 2021 18:34:08 +0900 (JST) Received: by mail-il1-f198.google.com with SMTP id c10-20020a92cf0a0000b029016baf18aee1so10864119ilo.16 for ; Mon, 19 Apr 2021 02:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=kFQwDH66z3fkbfr1bqs6mkOBuisqKJKABXu+1MnEImTXwb7A5SlWmqTE+UglWIBnNU Xeuyrq9+v2qenfzHQDzHGlUXfMA56vovs2f9gVgWcC//jyDWa33x4RYTjG+O2dL9NRDi egYqbWbcDkVCHWe4P5DNvzaZHrMyqqeBs9egC5BU4G6RctG4K5KjzfdoUuqM+BYeJvQX wGVjkFnTtMjzHx7Ro9NAsndzlsX/FOLOQa8DM5nJz54ywMyNdFHWYBvd/duwgCalJCJf F1tTJnFZcrxfuLvAnkD4i8w4RolHvQxeoXm5mOusFtajU7G3W1DzBSUIKJM/m8afDlzc K/5A== X-Gm-Message-State: AOAM533kHDuol2stutlT+9yXu4njbPXJjsqYsC88C4PiZjl5E+8RS0of Z6EH61qEZYEDA99DDdfhBk06xPl5BE1tiyLNcIDIbUYTD+IQen2yelHIyOpeo0FfeF5IucrJy47 0vRFn3QZ+WlaEqEes/m/A/dn1eDUSGJSDLq32 X-Received: by 2002:a63:1665:: with SMTP id 37mr11208883pgw.31.1618824837068; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3BVfHB/Iu3InVzb+YLUkuY7/BfcYMlC0sOGsbJiks+G4SQp5aPsproxuobb7vRE8Qif9k+g== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208853pgw.31.1618824836841; Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from pc-0115 (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id x18sm10982637pjn.51.2021.04.19.02.33.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from martinet by pc-0115 with local (Exim 4.94) (envelope-from ) id 1lYQHy-002k7D-3h; Mon, 19 Apr 2021 18:33:54 +0900 Date: Mon, 19 Apr 2021 18:33:44 +0900 From: Dominique MARTINET To: Geert Uytterhoeven Cc: "Alice Guo (OSS)" , gregkh@linuxfoundation.org, rafael@kernel.org, horia.geanta@nxp.com, aymen.sghaier@nxp.com, herbert@gondor.apana.org.au, davem@davemloft.net, tony@atomide.com, geert+renesas@glider.be, mturquette@baylibre.com, sboyd@kernel.org, vkoul@kernel.org, peter.ujfalusi@gmail.com, a.hajda@samsung.com, narmstrong@baylibre.com, robert.foss@linaro.org, airlied@linux.ie, daniel@ffwll.ch, khilman@baylibre.com, tomba@kernel.org, jyri.sarha@iki.fi, joro@8bytes.org, will@kernel.org, mchehab@kernel.org, ulf.hansson@linaro.org, adrian.hunter@intel.com, kishon@ti.com, kuba@kernel.org, linus.walleij@linaro.org, Roy.Pledge@nxp.com, leoyang.li@nxp.com, ssantosh@kernel.org, matthias.bgg@gmail.com, edubezval@gmail.com, j-keerthy@ti.com, balbi@kernel.org, linux@prisktech.co.nz, stern@rowland.harvard.edu, wim@linux-watchdog.org, linux@roeck-us.net, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, linux-omap@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, dmaengine@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, linux-media@vger.kernel.org, linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-phy@lists.infradead.org, linux-gpio@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-staging@lists.linux.dev, linux-mediatek@lists.infradead.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org, Arnd Bergmann Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Message-ID: References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_023411_058836_CD69CB16 X-CRM114-Status: GOOD ( 26.00 ) X-BeenThere: linux-mediatek@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-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > This is going to need quite some more work to be acceptable, in my > > opinion, but I think it should be possible. > > In general, this is very hard to do, IMHO. Some drivers may be used on > multiple platforms, some of them registering an SoC device, some of > them not registering an SoC device. So there is no way to know the > difference between "SoC device not registered, intentionally", and > "SoC device not yet registered". Hm, good point, I was probably a bit too optimistic if there are devices which don't register any soc yet have drivers which want one; I don't see how to make the difference indeed... And that does mean we can't just defer all the time. > soc_device_match() should only be used as a last resort, to identify > systems that cannot be identified otherwise. Typically this is used for > quirks, which should only be enabled on a very specific subset of > systems. IMHO such systems should make sure soc_device_match() > is available early, by registering their SoC device early. I definitely agree there, my suggestion to defer was only because I know of no other way to influence the ordering of drivers loading reliably and gave up on soc being init'd early. In this particular case the problem is that since 7d981405d0fd ("soc: imx8m: change to use platform driver") the soc probe tries to use the nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet. So soc loading gets pushed back to the end of the list because it gets defered and other drivers relying on soc_device_match get confused because they wrongly think a device doesn't match a quirk when it actually does. If there is a way to ensure the nvmem driver gets loaded before the soc, that would also solve the problem nicely, and avoid the need to mess with all the ~50 drivers which use it. Is there a way to control in what order drivers get loaded? Something in the dtb perhaps? Thanks, -- Dominique _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 1AE08C433B4 for ; Mon, 19 Apr 2021 09:34:26 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C16361027 for ; Mon, 19 Apr 2021 09:34:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C16361027 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atmark-techno.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=AkPvBcQcbC2F7gMi4bOJWSZGFqP2YtvRoAU28iPcxmQ=; b=Ls7+TPNJk+5jmu+yl5FTLiGde XIBsYFPckwLa2tHxFcH/223eBKYK7MbyfkGzgnLapLuSK6yOvMQgrGFbIUTaQpCCQphYEv92Qe7Lz IUHJN4QmebDChkguNLpWJLhaGo45Vs9aqzb/qv44kNntJt/lpZ/aIL7q/XJTgv7N8P2gxmAdqDmd6 53PrvE5j7UmiOqOma+h7NC61+u53Vcpd4POzaH8GnyTrxbwB0/4bMXtwb402u32zjh/d1k7e9UZlH hj8oFPE1cWLEo+BI8gDdug5SVHgqbIUPB6hsmtYidcqwxMXQW/MJaGD2RuPdqpYWIDyZ3DNW28Xog EWEO1ELtg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIN-009Yrb-3Q; Mon, 19 Apr 2021 09:34:19 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIK-009YpL-N1 for linux-amlogic@desiato.infradead.org; Mon, 19 Apr 2021 09:34:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=kaQa/AbeFluWEL1g4bjzwaRow8 yXqSwa46A+gZEm4zoKnEIJXxcrDNvfQU+tuCrUePruxaaSObME882ZfGQufXF3gRp2DNjbZeR2Z/m E6cTn53sGJ4KJY/UkrTEps9vMJepxE4AReRwZSb5vVzWgLpsZ9CMoP13Gy1zqIjJV90SYlrxKv3t2 ftYnANI1/x7e4WQiVu0W4GzIBhHxk4vxxoAkgOYN1WlyeT7gq3dn1g1eFFu5MW9OTyDuFC/WUDWKE kWFosyKmEwPydot5gQM6oNn2jn3YylssPEsYFUBlDEfZQP44EX86E2HRVYEZ+XOj0so0NMTSyRvjO A5kodCQQ==; Received: from gw.atmark-techno.com ([13.115.124.170]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIE-00BERW-Sl for linux-amlogic@lists.infradead.org; Mon, 19 Apr 2021 09:34:15 +0000 Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by gw.atmark-techno.com (Postfix) with ESMTPS id A2BA28049C for ; Mon, 19 Apr 2021 18:34:08 +0900 (JST) Received: by mail-io1-f70.google.com with SMTP id y20-20020a6bd8140000b02903e6787c4986so4166627iob.23 for ; Mon, 19 Apr 2021 02:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=rjn8TE0MOMIDgbAIEdnQQJd7sIopk9acuaYyaN7rtaQAj0cRU+/u0mvpINn16HMaro KWGTz3NF740RxXz7cenxHPiULIrwf5zaF/2S9OVY+zsXNyG6mp0x5NhSIgkMvBCfkNfR pgXPuRrzQkvfKWUN8MipLahMr3d/2/x0PAl44kL1uWzoRw/Hrwgs17+vih1c/4DImKuk PFNxmzHSnZ0fKPEzrezO4Fp/B24elsK0ZoN99Lgt5a/0mn+wmqi8GAw6w39eD9zaAMNZ HkfgPvcsdpUh7fcRnaMuCZgjk8rxv61ZZ9h2wpZAzxrUyUkVdWZbsBkz3olSNvlAJZ42 lVww== X-Gm-Message-State: AOAM530WSCkD771CTxAI0ouAuoi5h2GvpV8oNU3a+8UlQxpOWS909irQ oInfOo5sWyuDaF/ZttodlziqBthJFKa2+krLFz9H87NRmIIndilQ8XjgcsNvBAAjEMUZGQ1BnrJ JXL9Pgii9tn1I3WWAdoY9kozTTToyRVQi0Ng= X-Received: by 2002:a63:1665:: with SMTP id 37mr11208876pgw.31.1618824837067; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3BVfHB/Iu3InVzb+YLUkuY7/BfcYMlC0sOGsbJiks+G4SQp5aPsproxuobb7vRE8Qif9k+g== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208853pgw.31.1618824836841; Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from pc-0115 (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id x18sm10982637pjn.51.2021.04.19.02.33.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from martinet by pc-0115 with local (Exim 4.94) (envelope-from ) id 1lYQHy-002k7D-3h; Mon, 19 Apr 2021 18:33:54 +0900 Date: Mon, 19 Apr 2021 18:33:44 +0900 From: Dominique MARTINET To: Geert Uytterhoeven Cc: "Alice Guo (OSS)" , gregkh@linuxfoundation.org, rafael@kernel.org, horia.geanta@nxp.com, aymen.sghaier@nxp.com, herbert@gondor.apana.org.au, davem@davemloft.net, tony@atomide.com, geert+renesas@glider.be, mturquette@baylibre.com, sboyd@kernel.org, vkoul@kernel.org, peter.ujfalusi@gmail.com, a.hajda@samsung.com, narmstrong@baylibre.com, robert.foss@linaro.org, airlied@linux.ie, daniel@ffwll.ch, khilman@baylibre.com, tomba@kernel.org, jyri.sarha@iki.fi, joro@8bytes.org, will@kernel.org, mchehab@kernel.org, ulf.hansson@linaro.org, adrian.hunter@intel.com, kishon@ti.com, kuba@kernel.org, linus.walleij@linaro.org, Roy.Pledge@nxp.com, leoyang.li@nxp.com, ssantosh@kernel.org, matthias.bgg@gmail.com, edubezval@gmail.com, j-keerthy@ti.com, balbi@kernel.org, linux@prisktech.co.nz, stern@rowland.harvard.edu, wim@linux-watchdog.org, linux@roeck-us.net, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, linux-omap@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, dmaengine@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, linux-media@vger.kernel.org, linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-phy@lists.infradead.org, linux-gpio@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-staging@lists.linux.dev, linux-mediatek@lists.infradead.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org, Arnd Bergmann Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Message-ID: References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_023411_054713_533E363B X-CRM114-Status: GOOD ( 25.81 ) X-BeenThere: linux-amlogic@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-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > This is going to need quite some more work to be acceptable, in my > > opinion, but I think it should be possible. > > In general, this is very hard to do, IMHO. Some drivers may be used on > multiple platforms, some of them registering an SoC device, some of > them not registering an SoC device. So there is no way to know the > difference between "SoC device not registered, intentionally", and > "SoC device not yet registered". Hm, good point, I was probably a bit too optimistic if there are devices which don't register any soc yet have drivers which want one; I don't see how to make the difference indeed... And that does mean we can't just defer all the time. > soc_device_match() should only be used as a last resort, to identify > systems that cannot be identified otherwise. Typically this is used for > quirks, which should only be enabled on a very specific subset of > systems. IMHO such systems should make sure soc_device_match() > is available early, by registering their SoC device early. I definitely agree there, my suggestion to defer was only because I know of no other way to influence the ordering of drivers loading reliably and gave up on soc being init'd early. In this particular case the problem is that since 7d981405d0fd ("soc: imx8m: change to use platform driver") the soc probe tries to use the nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet. So soc loading gets pushed back to the end of the list because it gets defered and other drivers relying on soc_device_match get confused because they wrongly think a device doesn't match a quirk when it actually does. If there is a way to ensure the nvmem driver gets loaded before the soc, that would also solve the problem nicely, and avoid the need to mess with all the ~50 drivers which use it. Is there a way to control in what order drivers get loaded? Something in the dtb perhaps? Thanks, -- Dominique _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 3649BC433ED for ; Mon, 19 Apr 2021 09:34:25 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C6DD61178 for ; Mon, 19 Apr 2021 09:34:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C6DD61178 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atmark-techno.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=OagmFKl/RYYJYQqxB65pwwgDDiFxvE/UM6PIVE9VzwA=; b=FyeIU1NXDwGXWWUXhPiGwu6MT Gw6AtO1F9zWd9rKVRhpNv6j4aeEpSLjc3zliyd2ET9xWJyQqf8xn4wCT/Yp938E6AOdKzYmpXWkIW lVMMxq3GN3zQxp1pLDwtyYj/lyjwTldfABoth5X8RzppwRhmJXQ9/mWKn1R8LxTq4MyEVdwYurL8y gc+FKhpK5yfNhM51KpGWRV/9DfklkigCOAPIoBJXVBsrgNOh89NJOpWJB2QJYpZEyVQA4kGHJ2JU5 CluJeh5d4ol0IgbWQaSWqh2Y1t87qyjVtguNklRcmWVeHJ0Vfgk6rZ3G+GkBfNEpFhTM3lO6uI+QG Alq6gqc0w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIQ-009Ysb-IN; Mon, 19 Apr 2021 09:34:22 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIO-009Yru-Ij for linux-phy@desiato.infradead.org; Mon, 19 Apr 2021 09:34:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=kaQa/AbeFluWEL1g4bjzwaRow8 yXqSwa46A+gZEm4zoKnEIJXxcrDNvfQU+tuCrUePruxaaSObME882ZfGQufXF3gRp2DNjbZeR2Z/m E6cTn53sGJ4KJY/UkrTEps9vMJepxE4AReRwZSb5vVzWgLpsZ9CMoP13Gy1zqIjJV90SYlrxKv3t2 ftYnANI1/x7e4WQiVu0W4GzIBhHxk4vxxoAkgOYN1WlyeT7gq3dn1g1eFFu5MW9OTyDuFC/WUDWKE kWFosyKmEwPydot5gQM6oNn2jn3YylssPEsYFUBlDEfZQP44EX86E2HRVYEZ+XOj0so0NMTSyRvjO A5kodCQQ==; Received: from gw.atmark-techno.com ([13.115.124.170]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYQIE-00BERY-Sn for linux-phy@lists.infradead.org; Mon, 19 Apr 2021 09:34:19 +0000 Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) by gw.atmark-techno.com (Postfix) with ESMTPS id 070A6804B3 for ; Mon, 19 Apr 2021 18:34:09 +0900 (JST) Received: by mail-io1-f71.google.com with SMTP id o9-20020a5e8a490000b02903e6e5e5c905so9204737iom.16 for ; Mon, 19 Apr 2021 02:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=I6HBYaO6RZ7yTEKf+GFdpulfEV4/nvTqtTIlJrj5bj9JduOpovW9G1kCUyt6t34+On pa7f4V/HgUGyaNJsEjAvILx/R9YhOIEbVNv326pvQRoj8ryoQuCFnGztG4rJdwH7XV1Q CY7bBxqBseTbnQKoLgnib7bcAe1szhDHjI2cb74kkVjWNtfbTt1J4J+oONyjQnXZr/ep 2p9/arH/hKeAMcCoj3iAjZZpgIFqjsec6jrj9FiecLgmDBMbah1sPNwFbx23ULWvpalQ rvSFRA4sXkVDhI12Ur0aY4ZlRS5Cg27z0SoO8NJwe5Vh0YfxuKUKlbkWiX52jAgNzMe8 lAxQ== X-Gm-Message-State: AOAM532saSoLBWbk+u7thQ3D2lh1wnFa49nNxjBmggy9AOIuPPZzUA4r tpdRopTFMWk8rz54eENqMVh92ixvl4gUlVBCulLrSLck4Bqz177q3Efj9SpYuH7rny3dwgGZbtG eTF8K8Mz0VFmjS0OeZLEQ+cDVw8RdMQ== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208899pgw.31.1618824837070; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3BVfHB/Iu3InVzb+YLUkuY7/BfcYMlC0sOGsbJiks+G4SQp5aPsproxuobb7vRE8Qif9k+g== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208853pgw.31.1618824836841; Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from pc-0115 (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id x18sm10982637pjn.51.2021.04.19.02.33.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from martinet by pc-0115 with local (Exim 4.94) (envelope-from ) id 1lYQHy-002k7D-3h; Mon, 19 Apr 2021 18:33:54 +0900 Date: Mon, 19 Apr 2021 18:33:44 +0900 From: Dominique MARTINET To: Geert Uytterhoeven Cc: "Alice Guo (OSS)" , gregkh@linuxfoundation.org, rafael@kernel.org, horia.geanta@nxp.com, aymen.sghaier@nxp.com, herbert@gondor.apana.org.au, davem@davemloft.net, tony@atomide.com, geert+renesas@glider.be, mturquette@baylibre.com, sboyd@kernel.org, vkoul@kernel.org, peter.ujfalusi@gmail.com, a.hajda@samsung.com, narmstrong@baylibre.com, robert.foss@linaro.org, airlied@linux.ie, daniel@ffwll.ch, khilman@baylibre.com, tomba@kernel.org, jyri.sarha@iki.fi, joro@8bytes.org, will@kernel.org, mchehab@kernel.org, ulf.hansson@linaro.org, adrian.hunter@intel.com, kishon@ti.com, kuba@kernel.org, linus.walleij@linaro.org, Roy.Pledge@nxp.com, leoyang.li@nxp.com, ssantosh@kernel.org, matthias.bgg@gmail.com, edubezval@gmail.com, j-keerthy@ti.com, balbi@kernel.org, linux@prisktech.co.nz, stern@rowland.harvard.edu, wim@linux-watchdog.org, linux@roeck-us.net, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, linux-omap@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, dmaengine@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, linux-media@vger.kernel.org, linux-mmc@vger.kernel.org, netdev@vger.kernel.org, linux-phy@lists.infradead.org, linux-gpio@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-staging@lists.linux.dev, linux-mediatek@lists.infradead.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org, Arnd Bergmann Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Message-ID: References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_023411_058449_FD11283E X-CRM114-Status: GOOD ( 25.71 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > This is going to need quite some more work to be acceptable, in my > > opinion, but I think it should be possible. > > In general, this is very hard to do, IMHO. Some drivers may be used on > multiple platforms, some of them registering an SoC device, some of > them not registering an SoC device. So there is no way to know the > difference between "SoC device not registered, intentionally", and > "SoC device not yet registered". Hm, good point, I was probably a bit too optimistic if there are devices which don't register any soc yet have drivers which want one; I don't see how to make the difference indeed... And that does mean we can't just defer all the time. > soc_device_match() should only be used as a last resort, to identify > systems that cannot be identified otherwise. Typically this is used for > quirks, which should only be enabled on a very specific subset of > systems. IMHO such systems should make sure soc_device_match() > is available early, by registering their SoC device early. I definitely agree there, my suggestion to defer was only because I know of no other way to influence the ordering of drivers loading reliably and gave up on soc being init'd early. In this particular case the problem is that since 7d981405d0fd ("soc: imx8m: change to use platform driver") the soc probe tries to use the nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet. So soc loading gets pushed back to the end of the list because it gets defered and other drivers relying on soc_device_match get confused because they wrongly think a device doesn't match a quirk when it actually does. If there is a way to ensure the nvmem driver gets loaded before the soc, that would also solve the problem nicely, and avoid the need to mess with all the ~50 drivers which use it. Is there a way to control in what order drivers get loaded? Something in the dtb perhaps? Thanks, -- Dominique -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy 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=-3.8 required=3.0 tests=BAYES_00, 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 CDE78C433B4 for ; Mon, 19 Apr 2021 10:07:21 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ABAAE60E0B for ; Mon, 19 Apr 2021 10:07:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABAAE60E0B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atmark-techno.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FP2YM17RGz3c4Q for ; Mon, 19 Apr 2021 20:07:19 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=atmark-techno.com (client-ip=13.115.124.170; helo=gw.atmark-techno.com; envelope-from=dominique.martinet@atmark-techno.com; receiver=) Received: from gw.atmark-techno.com (gw.atmark-techno.com [13.115.124.170]) by lists.ozlabs.org (Postfix) with ESMTP id 4FP1q763Tmz2y6B for ; Mon, 19 Apr 2021 19:34:11 +1000 (AEST) Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) by gw.atmark-techno.com (Postfix) with ESMTPS id 63129804C6 for ; Mon, 19 Apr 2021 18:34:09 +0900 (JST) Received: by mail-io1-f72.google.com with SMTP id p8-20020a5d9c880000b02903dc877cd48dso9226191iop.13 for ; Mon, 19 Apr 2021 02:34:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=pAXG6d8Ogyl4+zxNqDsdX9dAndhrJ4zThNQcqTxYs2wz+1d9Wg1Zvi79+g/jAizVsb QfHBre6/BPLIHIwZj+Rxb/rZIlgIehSxeOcbF/JJxm6u6KmBTh+3vIB+EnTJ5jeJ29P5 b3zNQ60MSCyZwIPqXKCR3CP2F6P1QrvMKbsD6UFwkuNnXcCOFuSUr31/1jwiEQ1tmSZ5 zz61leRHsYVtKQIWQcK3jNymIYn+w9rxsbqSTfYI+he/bYYCD9959/uvvWyT0xdmL5Xi 48yQBqz6aV6GyG/Rq6OwbzbjhCjf1/kL5xZjqWpXnruduSM30M/mFVNFfqrKIDSYwUwg 2KBA== X-Gm-Message-State: AOAM530TCaKMHv0psKpjLkw6w+IFDj3bDYHH51JtyxsBIyf8o4Amh4u4 KDraRXQzACNGeZbX+JlP/pkm5y3errWkS2tbRZFfhfKBa4LuuaK5DLxaoS41htvy1vlNofD6f6S 4eaam5KvTNuxlilCWhFMo60O2B3o4dQ== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208882pgw.31.1618824837068; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3BVfHB/Iu3InVzb+YLUkuY7/BfcYMlC0sOGsbJiks+G4SQp5aPsproxuobb7vRE8Qif9k+g== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208853pgw.31.1618824836841; Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from pc-0115 (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id x18sm10982637pjn.51.2021.04.19.02.33.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from martinet by pc-0115 with local (Exim 4.94) (envelope-from ) id 1lYQHy-002k7D-3h; Mon, 19 Apr 2021 18:33:54 +0900 Date: Mon, 19 Apr 2021 18:33:44 +0900 From: Dominique MARTINET To: Geert Uytterhoeven Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Message-ID: References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Mon, 19 Apr 2021 20:06:58 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ulf.hansson@linaro.org, aymen.sghaier@nxp.com, geert+renesas@glider.be, rafael@kernel.org, airlied@linux.ie, mturquette@baylibre.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, a.hajda@samsung.com, netdev@vger.kernel.org, linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com, linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org, wim@linux-watchdog.org, herbert@gondor.apana.org.au, horia.geanta@nxp.com, khilman@baylibre.com, joro@8bytes.org, narmstrong@baylibre.com, linux-staging@lists.linux.dev, iommu@lists.linux-foundation.org, kishon@ti.com, tony@atomide.com, linux-omap@vger.kernel.org, stern@rowland.harvard.edu, kuba@kernel.org, linus.walleij@linaro.org, linux@roeck-us.net, linux-media@vger.kernel.org, linux-watchdog@vger.kernel.org, will@kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, edubezval@gmail.com, linux-gpio@vger.kernel.org, linux-mediatek@lists.infradead.org, ssantosh@kernel.org, matthias.bgg@gmail.com, linux-amlogic@lists.infradead.org, mchehab@kernel.org, linux-arm-kernel@lists.infradead.org, "Alice Guo \(OSS\)" , balbi@kernel.org, tomba@kernel.org, sboyd@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org, adrian.hunter@intel.com, robert.foss@linaro.org, leoyang.li@nxp.com, linux@prisktech.co.nz, vkoul@kernel.org, Arnd Bergmann , linux-crypto@vger.kernel.org, daniel@ffwll.ch, j-keerthy@ti.com, dmaengine@vger.kernel.org, Roy.Pledge@nxp.com, jyri.sarha@iki.fi, davem@davemloft.net Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > This is going to need quite some more work to be acceptable, in my > > opinion, but I think it should be possible. > > In general, this is very hard to do, IMHO. Some drivers may be used on > multiple platforms, some of them registering an SoC device, some of > them not registering an SoC device. So there is no way to know the > difference between "SoC device not registered, intentionally", and > "SoC device not yet registered". Hm, good point, I was probably a bit too optimistic if there are devices which don't register any soc yet have drivers which want one; I don't see how to make the difference indeed... And that does mean we can't just defer all the time. > soc_device_match() should only be used as a last resort, to identify > systems that cannot be identified otherwise. Typically this is used for > quirks, which should only be enabled on a very specific subset of > systems. IMHO such systems should make sure soc_device_match() > is available early, by registering their SoC device early. I definitely agree there, my suggestion to defer was only because I know of no other way to influence the ordering of drivers loading reliably and gave up on soc being init'd early. In this particular case the problem is that since 7d981405d0fd ("soc: imx8m: change to use platform driver") the soc probe tries to use the nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet. So soc loading gets pushed back to the end of the list because it gets defered and other drivers relying on soc_device_match get confused because they wrongly think a device doesn't match a quirk when it actually does. If there is a way to ensure the nvmem driver gets loaded before the soc, that would also solve the problem nicely, and avoid the need to mess with all the ~50 drivers which use it. Is there a way to control in what order drivers get loaded? Something in the dtb perhaps? Thanks, -- Dominique