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 55BD2C433ED for ; Mon, 19 Apr 2021 13:00:09 +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 806916100B for ; Mon, 19 Apr 2021 13:00:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 806916100B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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 4FP6Nl14pzz2yRy for ; Mon, 19 Apr 2021 23:00:07 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=212.227.126.134; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FP5RB1XQtz2xYd for ; Mon, 19 Apr 2021 22:17:09 +1000 (AEST) Received: from mail-ej1-f46.google.com ([209.85.218.46]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1N5CMP-1lfv3q1lLR-011DHD for ; Mon, 19 Apr 2021 14:17:03 +0200 Received: by mail-ej1-f46.google.com with SMTP id v6so51270470ejo.6 for ; Mon, 19 Apr 2021 05:17:02 -0700 (PDT) X-Gm-Message-State: AOAM53188vvapMT83ADkci9QKKN9Utlxq/SUVlBFQAFg2ffIJI/Ap3R7 jEFQFkwTsL+pZiMfdMGS9F2jyAzxuVoWF0Bid2o= X-Google-Smtp-Source: ABdhPJw4F20QerTwfst1rAMwc6NWiXDSUWeUkZ8E4j2sezaYrIv6atAni45jIwUzsYws7AyLO9D3pu8QFGIGztgXd7o= X-Received: by 2002:a05:6000:1843:: with SMTP id c3mr14679907wri.361.1618834612186; Mon, 19 Apr 2021 05:16:52 -0700 (PDT) MIME-Version: 1.0 References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> In-Reply-To: From: Arnd Bergmann Date: Mon, 19 Apr 2021 14:16:36 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match To: Dominique MARTINET Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:bFav/xEC3Tj835Cs0Gs5YB0Fs1KJY/yqkTcaiEmKQtB8CaAMoDY WfkzN03ANEaPa9dwmD+Oujq1iG9Im6/WwtXQIWARul5N7fwwSUPcwZmEu273i1vKFYJ93gz WkXW4Iujfq6IuYWu0A2AgHfHznwjRMCSZudaF0D+GvRrAj/TFcLX4oyIjIuIdOQ9asWKgqX ukogxUiYDhFObQoaBiNRw== X-UI-Out-Filterresults: notjunk:1;V03:K0:MTagkLDkmls=:ADvznjIkuHV9jc9bNiGULr oNjC+1Ps6SD3sCYAB/aoRxiN4GI5y0/ewJbIPr3MSzGIGq7XF5OWnF2ktZRwY8ujo29Tm8dpb rsNwxBQguOb/EoWEFSRsRH2wmuB1+P5neiC4MOBQ8sQVCn1rCrXJy2d4rPhY+pWO1OEpdgsTD qydFUVsFhdQRejN3/5oM3TTVk+wNHhsrv8b5eIuPML4wN/gtCNuASex9rDbZHIYmA8nQrc2gJ Kd3Lp5RLmn26VCLC/M/wpr5Y6k5iIjo9hxIK69C9lBUzOxLLywYvqJdUH1J62OmCVJ4P4pr9C Rx1HCCQYcfF6p6sTUZICN8bttzT1Qg0rClIzsyqLaFSDOj0PXFqIudL33MsUfXyu/whiTF4qq A0iAsh3pECvMYHNFVa7Xnmls6pbj/naIu3chfPhzzDA+YVlFeL08BWY/qW/M7kr1mWSwEdanm bAOt7RFfdAub4WblUzNKHOUsvabSWizRrXYBWShIUErQlp5rLKNk72CJnsM+MLa+CUieYO4dX t9l9f8dVMN0VZEPi/DiUOW2neH5qZBqVgodB4UM/EkQv/fZh0j5TZdPeavJZT4IaevqCOPzCT Oj4FP4C7osvADoCDv1I8YU/AzQxz5+PVSQsMd79K3EbPC7IHMMe+AI/98jlSaGH43AEY3OXdX +hPA= X-Mailman-Approved-At: Mon, 19 Apr 2021 22:59:43 +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 , aymen.sghaier@nxp.com, Geert Uytterhoeven , Rafael Wysocki , David Airlie , Michael Turquette , dri-devel , Linux Kernel Mailing List , Andrzej Hajda , Networking , linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com, linux-clk , Linux-Renesas , Wim Van Sebroeck , Herbert Xu , =?UTF-8?Q?Horia_Geant=C4=83?= , Kevin Hilman , Joerg Roedel , Neil Armstrong , linux-staging@lists.linux.dev, "open list:IOMMU DRIVERS" , Kishon , Tony Lindgren , linux-omap , Geert Uytterhoeven , Jakub Kicinski , Linus Walleij , Guenter Roeck , Linux Media Mailing List , LINUXWATCHDOG , Will Deacon , Linux PM list , linuxppc-dev , Eduardo Valentin , "open list:GPIO SUBSYSTEM" , "moderated list:ARM/Mediatek SoC..." , Santosh Shilimkar , Matthias Brugger , "open list:ARM/Amlogic Meson SoC support" , Mauro Carvalho Chehab , Linux ARM , "Alice Guo \(OSS\)" , Felipe Balbi , tomba@kernel.org, Stephen Boyd , gregkh , Alan Stern , USB list , linux-mmc , Adrian Hunter , Robert Foss , Leo Li , Tony Prisk , Vinod Koul , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Daniel Vetter , Keerthy , dmaengine@vger.kernel.org, Roy Pledge , jyri.sarha@iki.fi, David Miller Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET wrote: > Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > > 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 some cases, you can use the device_link infrastructure to deal with dependencies between devices. Not sure if this would help in your case, but have a look at device_link_add() etc in drivers/base/core.c > 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? For built-in drivers, load order depends on the initcall level and link order (how things are lined listed in the Makefile hierarchy). For loadable modules, this is up to user space in the end. Which of the drivers in this scenario are loadable modules? Arnd