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 B2DE4C43460 for ; Mon, 19 Apr 2021 12:17:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7D0ED6101E for ; Mon, 19 Apr 2021 12:17:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239130AbhDSMRl (ORCPT ); Mon, 19 Apr 2021 08:17:41 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:49693 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239056AbhDSMRg (ORCPT ); Mon, 19 Apr 2021 08:17:36 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1McIYO-1m4VGN1dSm-00cdhN; Mon, 19 Apr 2021 14:17:03 +0200 Received: by mail-wr1-f45.google.com with SMTP id a4so33804401wrr.2; Mon, 19 Apr 2021 05:17:03 -0700 (PDT) X-Gm-Message-State: AOAM530v/yBC/2XYq7ELiJsOKT38utH8V09hnr+DbReIt0QSUowLKCu9 qzJPWUNHn5H0Tj77oevy9M0tidTBIegyWgN+ZY8= 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 Cc: Geert Uytterhoeven , "Alice Guo (OSS)" , gregkh , Rafael Wysocki , =?UTF-8?Q?Horia_Geant=C4=83?= , aymen.sghaier@nxp.com, Herbert Xu , David Miller , Tony Lindgren , Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Vinod Koul , peter.ujfalusi@gmail.com, Andrzej Hajda , Neil Armstrong , Robert Foss , David Airlie , Daniel Vetter , Kevin Hilman , tomba@kernel.org, jyri.sarha@iki.fi, Joerg Roedel , Will Deacon , Mauro Carvalho Chehab , Ulf Hansson , Adrian Hunter , Kishon , Jakub Kicinski , Linus Walleij , Roy Pledge , Leo Li , Santosh Shilimkar , Matthias Brugger , Eduardo Valentin , Keerthy , Felipe Balbi , Tony Prisk , Alan Stern , Wim Van Sebroeck , Guenter Roeck , Linux Kernel Mailing List , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , linux-omap , Linux-Renesas , linux-clk , dmaengine@vger.kernel.org, dri-devel , "open list:ARM/Amlogic Meson SoC support" , Linux ARM , "open list:IOMMU DRIVERS" , Linux Media Mailing List , linux-mmc , Networking , linux-phy@lists.infradead.org, "open list:GPIO SUBSYSTEM" , linuxppc-dev , linux-staging@lists.linux.dev, "moderated list:ARM/Mediatek SoC..." , Linux PM list , USB list , LINUXWATCHDOG Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:P71GUur0c8Et4KTdfK062CelxJMlxDzHdi6foeZVMrh68Tz4kVO xXC4vz+qe3LvNC/lTgY8q6jr08cIcxgzzrqqwLuy4gBjPze3CRaFI6Tn0ivsylYkqTjCGCd UznPeEk90qstnxb0iWNZx7FG5N+vrUigS/VNsT3W/kFEpTHiyw396kNMzzFJBTjXO+naZJ+ Cfu35e3pJq/mHwP5LQM/Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:Tj0dSv4OACg=:QLuHKXqc+6Lj41NGnufoGl N+UnlZp25078q227oT0o/4kxbd0mQOAoQ/NCUKgnVsoYmGtmK6mEBskoottCNbYunStcV9NF4 wE8ToQWQ05B3nZv4Vjj9qNbaiSwQl2/EIEpHx8+6DQaiGM4h6uplPIOIDeaZjltt02tsjjmk7 kxpSU+zIeAbNwqmXYSk5Vm3CpYS1xMcDA6Eiv0+uZeBUE0kKjN4jwkU6+BKG/eaq+T9ufKwnD crSJLI+V67wSaKUzbHccJ3EU1Sb6dMM2cPoEC3Av6tRhuAXiX84+lOxtkljO1IFE9iL1JBVn5 CjGxqnLONV0vManrkRS3zSk/dqMTqKx9iNczeHNAz+sKCK3kGK1HvvAI82zCriMShj36q2Yiu latEFCHqqv6CzIpzD2Q+F98/Rh3nVZdyFAqvuM6r16X0t/3dzAs72dYw+jzCHok5qetil5Q2V 5rdGScTR8+ZhGbwiKRQyQ6I2CQTnccKZ549zJci96NqNdfUe5jbzVwZOI0walCavZ7GVu0d2F jvOU246bo6oNPkDzH9c2gJBnZtcrzAKb4pwtF9+3cOiLZPnCE0nY+1vjm75YQHDBCyxvLdR64 g4tTIuRlUg3P8XaXbJiPp80y/nkM8kt4yG+up76tnDKMDxMpP5a+pkpQ1YQ2I6y3uojN6bE8n CFp8= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 E3F3BC433ED for ; Mon, 19 Apr 2021 12:17:14 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 94E00611CE for ; Mon, 19 Apr 2021 12:17:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94E00611CE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 4DD5B834C6; Mon, 19 Apr 2021 12:17:14 +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 OugyVtljI5kZ; Mon, 19 Apr 2021 12:17:13 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTP id E069983459; Mon, 19 Apr 2021 12:17:12 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id B12C9C000E; Mon, 19 Apr 2021 12:17:12 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id CF441C000B for ; Mon, 19 Apr 2021 12:17:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A7DB8607BF for ; Mon, 19 Apr 2021 12:17:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPwOpyBcq1aX for ; Mon, 19 Apr 2021 12:17:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) by smtp3.osuosl.org (Postfix) with ESMTPS id 310356064C for ; Mon, 19 Apr 2021 12:17:06 +0000 (UTC) Received: from mail-lj1-f169.google.com ([209.85.208.169]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.97]) with ESMTPSA (Nemesis) id 1Mzi3l-1llRNO3sbR-00vfJJ for ; Mon, 19 Apr 2021 14:17:04 +0200 Received: by mail-lj1-f169.google.com with SMTP id a25so25791581ljm.11 for ; Mon, 19 Apr 2021 05:17:03 -0700 (PDT) X-Gm-Message-State: AOAM5330JIQY6BiDsRWk6e8Bc5/ekRVPAtAMqIqnhCyNz0J7NH9vlkkk pFlbFqzIm7vU3O682divZQWpO0K53DWbCyeheEg= 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 X-Provags-ID: V03:K1:JpMg4eOTzywsMVgUjhWyTOC/jUGEGJuYjU9MGjaShhROxtiVy3W 1Lv5zhxWslAXJ6yv7ixPTIpSzs3Ww6yhVMYIo11UljRVrn/022g/ewl68vbMwc/Q467udKx npoF+VcK9N6ab2xXdLiHQSNQdUmbxdML8al5Tq5O5/eLRYeckPWIFXpIen3RhOB0QTjpwx5 794PWKD3i174cYP4umI1Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:FfDSK5oh0zU=:aeD1clYsnTS7hWBlIHD6pm Mz4iuOaH4ZvhsZ4PyKjMbUwjti3xt4h2SLkRjwM4clAgF3bbHO/FDYkcOhAxvXU1qfEY+FHTh AU8IaI9EOpdlzeZRZLNo8qEblkKDSrPwqTZmw757xF80GFgEUDXouoX5+t6CgdCnwb+lIA53G XODQ+UnI3rjkoNAk59Xg0S7U2bQ5t3JTdaVzQAUX3wsx9vs1muJF4Ub5j+HDD284nhhJRXvCj Nf8E3aKmckptUJsIMDt7orn94zFtQB/YsCL/zo/8HghCG1hDx5ai5X2kP+oxdUYxI2uSurKoe N0a8ooAHAxO1GzcUC4/U502zoRwnFlMIqmQ8AQd3CRjbARpWOTiQd87+H0MaT9XOSbzJmFKG1 A/P0CXEuKtHMrNRcQMul8D7IBR1xFsaz6bPiCavKSwWGAd5yk9m5kFEIwR9Z3Fy8Li4sH3+c3 9CZCpfic+xsd4FWsrgsprVW4nKXG94TTDtoQ2UuEfau2eb2KQGZbn9qDmhxV2tV46tc29N6rS a6ymKmOwAoCx1d1UIut2F2Ac9pBSYes6kUdX00xRwAKfn1lztwCWhVUnI8jq4J2fMAVZvWOGQ H9i2J6EyEQ4MpADhSECnnmp3rRbP9OQvEGwsF4QVhLjKk+axld3Ir0FMbhd4M6nk5/Tg1dm0+ 9++0= 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 , 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 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" 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 _______________________________________________ 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 8DFC9C433B4 for ; Mon, 19 Apr 2021 12:17:09 +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 3BD1D61002 for ; Mon, 19 Apr 2021 12:17:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3BD1D61002 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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 BB9EF6E2D7; Mon, 19 Apr 2021 12:17:08 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9B6836E2D7 for ; Mon, 19 Apr 2021 12:17:05 +0000 (UTC) Received: from mail-lf1-f49.google.com ([209.85.167.49]) by mrelayeu.kundenserver.de (mreue009 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MTiHd-1l4ORu2yMv-00TyS9 for ; Mon, 19 Apr 2021 14:17:03 +0200 Received: by mail-lf1-f49.google.com with SMTP id g8so55627082lfv.12 for ; Mon, 19 Apr 2021 05:17:03 -0700 (PDT) X-Gm-Message-State: AOAM531UvOvCSYr2jwSBtEhniWtp/0DtYtaBqUpAsAT0euoxjBW80bOs IJpK3qbFRHeXEnEoIqEpIzFaWUftNOSTjr5BpG8= 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 X-Provags-ID: V03:K1:zSjFi8aUot0zGcMBxFIpQUNsqtkeBaQH1g5pc3FS7S3z9qDcpar +B20CfVGpZ98ECl+uY9vce6dxdlc+byrRs8ruhML69JWusTI1bxhxyO1Unw+drF0kTNtqL0 6v9znrR6YhGBTf0J0hFLcRrilPFhZ5IIjQLBoIDu+d2Glb23F37dQPpUx27ztPhz6+Eo76V vddC4t52daB0zFcOoTl+Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:lF711O/l5Pw=:CJNvJ5JaP81eP5Eo7K1YTf jpGwA3vX2I60wUDb8XtNvV+KrCZT51LDY2Fy/WWoSaZOuT9f5JHgcMXrcXzVh6JchwfbtJOKx CgA8DrfrPATETdbWfYJG12dQbpBEOiXOPcRMzdo1GkF9/GZOJ9EyXq3ebetqRsL9xfrFrqeVE euU7ReDBOITEhXoAe69DGF+KXAIr5cII0A2BJK8d4go7ckIAJx39ldCrKEyHayb65WuukjN9f KIUQmApnO5vzMhpx3gFtCh3uJkC8rREp2llxS0BLA7CXA/+IdHHuHFBgQiZV+wD8+wK0/JR1f U/5YYzgyZ0LbbzxnK6H8eiqhSRORrgIPoVwIKEhilx9kodIEI2jB2B/JdOvmlygj//cH5qI0e NC3VYRJK+A3vydBB9kQj+BzkMi4xsR/dL6liRHUp+lkcKLBm8aC01rMlFFDILApipHoNaHIJT 17i4c2RR1m/GK4ut54Mvw+j0UuypJVL3NmanMyxLjd4PNdfnxUWO8Td4qJu1aXJurloJ5B+O0 KU3Ruib2/qt9RQuDIjoqwcj5lGbvmd7DsOjV8hjYfvLx1ON+lF3kqPvU3ZF9ie1Kx/YPapL7K PJVLMT+HgCn/tmwYG69+SMfIRgZUe0jinH2psmEroVoAuHOWWsmARJEdElhwRwc7yPbTaRwbw U3Ss= 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 , 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 , 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" , Keerthy , dmaengine@vger.kernel.org, Roy Pledge , jyri.sarha@iki.fi, David Miller Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 _______________________________________________ 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 B0845C433B4 for ; Mon, 19 Apr 2021 12:17:33 +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 350B2611F0 for ; Mon, 19 Apr 2021 12:17:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 350B2611F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ELCUgU4sIC9lhiC5aW3pCH+28hm5Gox5kYM3LF77ZRE=; b=gMqoH2byDDMpYTkdMgPGWTK39 XCLZv/iWB1m0i6UKBCxyQoalr1DxpbIFv9tdfJdajnl16XN+J7BhhCHr9H+Aqo+oAYwYzA6wvjlmx 51Pgfa2OkO4D7Y6DAecJYaI37Rv4elD5c7Z73xOeXdQ91cWHpmff7ATDYAIEpzgVVsSPj6g++fk8A eFgWpCPM+/sZFAaiIbXApWmsnQoWwoHMPNMuIIaFRJr+N3LX16/LlCg7r7Q8jIe7h892sTFJZIzaG sZKe1UAnW6wrIn1qkVhrNSdNy/9NrzMYJksUUIZopWX4u8QRRKF+bFiEsA+fATpfMja+9RSoYQ37s CDAUffrpQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYSq6-009prm-5c; Mon, 19 Apr 2021 12:17:18 +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 1lYSpz-009ppm-HL; Mon, 19 Apr 2021 12:17:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Jte4PESVCyOxZgmueTIRmzESggoF2gOLGuf4QLB+EB0=; b=dEjx4FacO0Qc/yqZrU0+Ht6nuo 4/uFe56LP3DgbOdG1Glqe3iWmnIq1uxlsb0OUk/vfGdWwLqpuNEZtgkOlqg8ecMIhgAJZHK3+0/oT BdcE2fQD1zeTv6H8izVXUXj/VKNA1HT8U/3e7NfVmrVA811MEgAIL5pGkeHeb1ZyW9zi6x5dF0SRC 8tPaIgMDnG3dN0JerVPyaaIH5EHVdy0dgvyF9zqxpP6kik14qHqwnRKrlefZbNQfRro81ajsKMqaK O59IPz5s177J3PFXPdWhZw5u739vpeVDSE1zg6R7arSpswMcmkVuLCvWPd3UxgO8QMlQ6DKEOUVzW aJw6q1sw==; Received: from mout.kundenserver.de ([217.72.192.73]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYSpv-00BLMA-AV; Mon, 19 Apr 2021 12:17:10 +0000 Received: from mail-ed1-f43.google.com ([209.85.208.43]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1Ma1wY-1l2RQy3Y8K-00W0u9; Mon, 19 Apr 2021 14:17:04 +0200 Received: by mail-ed1-f43.google.com with SMTP id j7so3488470eds.8; Mon, 19 Apr 2021 05:17:03 -0700 (PDT) X-Gm-Message-State: AOAM530E08lvsRHMRNDydOZidFtApXVQ9lG+sKzfZ4kuuw7KmIVAJbRD Jvyapn36T22Tt77rVib32sw0LpT5rgiC5zZAu/0= 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 Cc: Geert Uytterhoeven , "Alice Guo (OSS)" , gregkh , Rafael Wysocki , =?UTF-8?Q?Horia_Geant=C4=83?= , aymen.sghaier@nxp.com, Herbert Xu , David Miller , Tony Lindgren , Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Vinod Koul , peter.ujfalusi@gmail.com, Andrzej Hajda , Neil Armstrong , Robert Foss , David Airlie , Daniel Vetter , Kevin Hilman , tomba@kernel.org, jyri.sarha@iki.fi, Joerg Roedel , Will Deacon , Mauro Carvalho Chehab , Ulf Hansson , Adrian Hunter , Kishon , Jakub Kicinski , Linus Walleij , Roy Pledge , Leo Li , Santosh Shilimkar , Matthias Brugger , Eduardo Valentin , Keerthy , Felipe Balbi , Tony Prisk , Alan Stern , Wim Van Sebroeck , Guenter Roeck , Linux Kernel Mailing List , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , linux-omap , Linux-Renesas , linux-clk , dmaengine@vger.kernel.org, dri-devel , "open list:ARM/Amlogic Meson SoC support" , Linux ARM , "open list:IOMMU DRIVERS" , Linux Media Mailing List , linux-mmc , Networking , linux-phy@lists.infradead.org, "open list:GPIO SUBSYSTEM" , linuxppc-dev , linux-staging@lists.linux.dev, "moderated list:ARM/Mediatek SoC..." , Linux PM list , USB list , LINUXWATCHDOG X-Provags-ID: V03:K1:g/QI9y9oQjjikvBQx8Nmh/qtx5Rfg/NuQCZqr/O03hRfwIE0GyD F3w4+EGg9GUaJHQlTjxVPX/0008CCVaqT1gHII/tbpbWzu7rMV/mHgswtMWuEvgVIVa0XqO XS0Jk7hAZUDhBP17ugBGfsLkDFI7TOGNXMrXnURMRWSZPYcujxBaF4LEGwH6jBCpXzgh+LG W+hlgWEp/+a8n/biU8XHQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:fj3kO2X5yGs=:r4DRa7oPbhL2Cp/tMsxLri 0UXNSBm5TFCw6p+MqcLW5k8ejukcMbKjXlbd94/KtlzQTBrXXcWsWDXmPS6ncAsJI/gRBgYN4 O2+rYdvaBYfvSus6eJgdSQkmHU0twbJ66r+efv2Tmd26CHfLv9IvnC6rUHRElo4ctzldbLMWy GTTe/6fuv1tGNLcHPfZHSL7/roKq4yDMeaDpzgAajuK7OgdYKrcdB0MrUdc8EK2tSdDXt7xti fAG35cuWVr6jNZGzlFqRlLJNvuVlZUQp2H/WvnMgu4WINKSq5VkThVw77cQ0JQsf1aETyVAOA UCUcmUaKVS/UqkLJ2M4VC+aXORwr3Q3mbahhYfSHUfb6U6c9jRaJn+3E7Q3sXeuG1PsexhbCw 90pWRbH8j5Enw7LhVinWavvXgo4GMbtB0v5ZdVbmYXfoaJt/wJy/JXZ7BykePlZOhwJr2uaP+ wzHMnhH0PKdQLzRIUXcUs2rZDZ4qQRXgbx3fzBCfBrIsJVpaqJeECt89e3tIbJRflgCgTN0nV M0h4M+57ycRVc4VpG6rAhdA0PU3usjjdawrRLRjcXx/W+e85jvRsqHXOhzSLZKGpRtRHHd9sV qGAurZ8DiwqxiEIJM9RvEOXZuCUEXSBPPYRS0IbdsitnQZWIsMXU3dDQs6esoGesTtPCz1/bY 7w3s= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_051707_671018_F06B008E X-CRM114-Status: GOOD ( 29.72 ) 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 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 _______________________________________________ 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 89A12C433B4 for ; Mon, 19 Apr 2021 12:17:22 +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 0A3B1611F0 for ; Mon, 19 Apr 2021 12:17:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A3B1611F0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JYVh2Oi1VRrOzsHWBnT49TP03ZigjpMGSJL6DSQIc4U=; b=rAuQBYiTHS1fL9Bl7K52KEr5f zWwJYvLQ1WkQUwpfjEHH/iHzdavIjlSw5wBJd0yVH50I41b2FNYetdbjrPDyPeyyOnJvcE0zYTH0r lgVlPgXBhZeFhx0K/3rNj7OZkhaWjsjdj1xHhcAITnws2hS1hJftvFslKNQtQ2xn97dOaBNDqQtD7 xbiVoHtM5P0hlF4T2fq7ogZgY8Jb9cUV9hvqnDLY/YIOfpU+HcRCN43M+J4mR9LABGenRKfJFIOdc SSWOw2/P+pG8vALyV6ora4CKIGD2NM99c6XFj6HwGifHq3cdoLYHKpWww1L+D2bMDcNV7lTicJmfN XST2TfGmw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYSq4-009pqh-Fm; Mon, 19 Apr 2021 12:17:16 +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 1lYSpz-009ppm-HL; Mon, 19 Apr 2021 12:17:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Jte4PESVCyOxZgmueTIRmzESggoF2gOLGuf4QLB+EB0=; b=dEjx4FacO0Qc/yqZrU0+Ht6nuo 4/uFe56LP3DgbOdG1Glqe3iWmnIq1uxlsb0OUk/vfGdWwLqpuNEZtgkOlqg8ecMIhgAJZHK3+0/oT BdcE2fQD1zeTv6H8izVXUXj/VKNA1HT8U/3e7NfVmrVA811MEgAIL5pGkeHeb1ZyW9zi6x5dF0SRC 8tPaIgMDnG3dN0JerVPyaaIH5EHVdy0dgvyF9zqxpP6kik14qHqwnRKrlefZbNQfRro81ajsKMqaK O59IPz5s177J3PFXPdWhZw5u739vpeVDSE1zg6R7arSpswMcmkVuLCvWPd3UxgO8QMlQ6DKEOUVzW aJw6q1sw==; Received: from mout.kundenserver.de ([217.72.192.73]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYSpv-00BLMA-AV; Mon, 19 Apr 2021 12:17:10 +0000 Received: from mail-ed1-f43.google.com ([209.85.208.43]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1Ma1wY-1l2RQy3Y8K-00W0u9; Mon, 19 Apr 2021 14:17:04 +0200 Received: by mail-ed1-f43.google.com with SMTP id j7so3488470eds.8; Mon, 19 Apr 2021 05:17:03 -0700 (PDT) X-Gm-Message-State: AOAM530E08lvsRHMRNDydOZidFtApXVQ9lG+sKzfZ4kuuw7KmIVAJbRD Jvyapn36T22Tt77rVib32sw0LpT5rgiC5zZAu/0= 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 Cc: Geert Uytterhoeven , "Alice Guo (OSS)" , gregkh , Rafael Wysocki , =?UTF-8?Q?Horia_Geant=C4=83?= , aymen.sghaier@nxp.com, Herbert Xu , David Miller , Tony Lindgren , Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Vinod Koul , peter.ujfalusi@gmail.com, Andrzej Hajda , Neil Armstrong , Robert Foss , David Airlie , Daniel Vetter , Kevin Hilman , tomba@kernel.org, jyri.sarha@iki.fi, Joerg Roedel , Will Deacon , Mauro Carvalho Chehab , Ulf Hansson , Adrian Hunter , Kishon , Jakub Kicinski , Linus Walleij , Roy Pledge , Leo Li , Santosh Shilimkar , Matthias Brugger , Eduardo Valentin , Keerthy , Felipe Balbi , Tony Prisk , Alan Stern , Wim Van Sebroeck , Guenter Roeck , Linux Kernel Mailing List , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , linux-omap , Linux-Renesas , linux-clk , dmaengine@vger.kernel.org, dri-devel , "open list:ARM/Amlogic Meson SoC support" , Linux ARM , "open list:IOMMU DRIVERS" , Linux Media Mailing List , linux-mmc , Networking , linux-phy@lists.infradead.org, "open list:GPIO SUBSYSTEM" , linuxppc-dev , linux-staging@lists.linux.dev, "moderated list:ARM/Mediatek SoC..." , Linux PM list , USB list , LINUXWATCHDOG X-Provags-ID: V03:K1:g/QI9y9oQjjikvBQx8Nmh/qtx5Rfg/NuQCZqr/O03hRfwIE0GyD F3w4+EGg9GUaJHQlTjxVPX/0008CCVaqT1gHII/tbpbWzu7rMV/mHgswtMWuEvgVIVa0XqO XS0Jk7hAZUDhBP17ugBGfsLkDFI7TOGNXMrXnURMRWSZPYcujxBaF4LEGwH6jBCpXzgh+LG W+hlgWEp/+a8n/biU8XHQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:fj3kO2X5yGs=:r4DRa7oPbhL2Cp/tMsxLri 0UXNSBm5TFCw6p+MqcLW5k8ejukcMbKjXlbd94/KtlzQTBrXXcWsWDXmPS6ncAsJI/gRBgYN4 O2+rYdvaBYfvSus6eJgdSQkmHU0twbJ66r+efv2Tmd26CHfLv9IvnC6rUHRElo4ctzldbLMWy GTTe/6fuv1tGNLcHPfZHSL7/roKq4yDMeaDpzgAajuK7OgdYKrcdB0MrUdc8EK2tSdDXt7xti fAG35cuWVr6jNZGzlFqRlLJNvuVlZUQp2H/WvnMgu4WINKSq5VkThVw77cQ0JQsf1aETyVAOA UCUcmUaKVS/UqkLJ2M4VC+aXORwr3Q3mbahhYfSHUfb6U6c9jRaJn+3E7Q3sXeuG1PsexhbCw 90pWRbH8j5Enw7LhVinWavvXgo4GMbtB0v5ZdVbmYXfoaJt/wJy/JXZ7BykePlZOhwJr2uaP+ wzHMnhH0PKdQLzRIUXcUs2rZDZ4qQRXgbx3fzBCfBrIsJVpaqJeECt89e3tIbJRflgCgTN0nV M0h4M+57ycRVc4VpG6rAhdA0PU3usjjdawrRLRjcXx/W+e85jvRsqHXOhzSLZKGpRtRHHd9sV qGAurZ8DiwqxiEIJM9RvEOXZuCUEXSBPPYRS0IbdsitnQZWIsMXU3dDQs6esoGesTtPCz1/bY 7w3s= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_051707_671018_F06B008E X-CRM114-Status: GOOD ( 29.72 ) 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 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 _______________________________________________ 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 85D7FC433ED for ; Mon, 19 Apr 2021 12:17:22 +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 EE2DA6101E for ; Mon, 19 Apr 2021 12:17:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE2DA6101E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7LdH0+RkdpyVDE9LcCsOULL1/9IB5Rfl0XbE2eYQdnY=; b=rgIRF+IJIj/Q3UUl4KDDtA85j kr+XBK4Ff+u3c68lYMXxYCD7lvIio1LZgDc9LbXokCpgug1cjPXTykZJihZBGl7Qz0E8kbRhSarPx l+w//A9JvkVHpx9FDt1DUhWWB+Y/xt1gwpdkzQthDRm/SpW/SU2Dhrh0uCXnhDKtVJvEQrCT/CGbK DPyfk1KidTxETc0TwHYR6rxOIdAvUC4IVBp3YcFbPkYZfGzuoObwQxVcdGWbxnngAa9zs9NVJ9NFt ssh/qiBleQDaduIJFoLORAQ4x04913xusYIaG5XDM9C0aJHjgnuIj/lYO51yLCrufdM/SpeAmtjmG 19jC4vDbg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYSq8-009psR-GJ; Mon, 19 Apr 2021 12:17:20 +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 1lYSpz-009ppm-HL; Mon, 19 Apr 2021 12:17:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Jte4PESVCyOxZgmueTIRmzESggoF2gOLGuf4QLB+EB0=; b=dEjx4FacO0Qc/yqZrU0+Ht6nuo 4/uFe56LP3DgbOdG1Glqe3iWmnIq1uxlsb0OUk/vfGdWwLqpuNEZtgkOlqg8ecMIhgAJZHK3+0/oT BdcE2fQD1zeTv6H8izVXUXj/VKNA1HT8U/3e7NfVmrVA811MEgAIL5pGkeHeb1ZyW9zi6x5dF0SRC 8tPaIgMDnG3dN0JerVPyaaIH5EHVdy0dgvyF9zqxpP6kik14qHqwnRKrlefZbNQfRro81ajsKMqaK O59IPz5s177J3PFXPdWhZw5u739vpeVDSE1zg6R7arSpswMcmkVuLCvWPd3UxgO8QMlQ6DKEOUVzW aJw6q1sw==; Received: from mout.kundenserver.de ([217.72.192.73]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYSpv-00BLMA-AV; Mon, 19 Apr 2021 12:17:10 +0000 Received: from mail-ed1-f43.google.com ([209.85.208.43]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1Ma1wY-1l2RQy3Y8K-00W0u9; Mon, 19 Apr 2021 14:17:04 +0200 Received: by mail-ed1-f43.google.com with SMTP id j7so3488470eds.8; Mon, 19 Apr 2021 05:17:03 -0700 (PDT) X-Gm-Message-State: AOAM530E08lvsRHMRNDydOZidFtApXVQ9lG+sKzfZ4kuuw7KmIVAJbRD Jvyapn36T22Tt77rVib32sw0LpT5rgiC5zZAu/0= 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 Cc: Geert Uytterhoeven , "Alice Guo (OSS)" , gregkh , Rafael Wysocki , =?UTF-8?Q?Horia_Geant=C4=83?= , aymen.sghaier@nxp.com, Herbert Xu , David Miller , Tony Lindgren , Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Vinod Koul , peter.ujfalusi@gmail.com, Andrzej Hajda , Neil Armstrong , Robert Foss , David Airlie , Daniel Vetter , Kevin Hilman , tomba@kernel.org, jyri.sarha@iki.fi, Joerg Roedel , Will Deacon , Mauro Carvalho Chehab , Ulf Hansson , Adrian Hunter , Kishon , Jakub Kicinski , Linus Walleij , Roy Pledge , Leo Li , Santosh Shilimkar , Matthias Brugger , Eduardo Valentin , Keerthy , Felipe Balbi , Tony Prisk , Alan Stern , Wim Van Sebroeck , Guenter Roeck , Linux Kernel Mailing List , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , linux-omap , Linux-Renesas , linux-clk , dmaengine@vger.kernel.org, dri-devel , "open list:ARM/Amlogic Meson SoC support" , Linux ARM , "open list:IOMMU DRIVERS" , Linux Media Mailing List , linux-mmc , Networking , linux-phy@lists.infradead.org, "open list:GPIO SUBSYSTEM" , linuxppc-dev , linux-staging@lists.linux.dev, "moderated list:ARM/Mediatek SoC..." , Linux PM list , USB list , LINUXWATCHDOG X-Provags-ID: V03:K1:g/QI9y9oQjjikvBQx8Nmh/qtx5Rfg/NuQCZqr/O03hRfwIE0GyD F3w4+EGg9GUaJHQlTjxVPX/0008CCVaqT1gHII/tbpbWzu7rMV/mHgswtMWuEvgVIVa0XqO XS0Jk7hAZUDhBP17ugBGfsLkDFI7TOGNXMrXnURMRWSZPYcujxBaF4LEGwH6jBCpXzgh+LG W+hlgWEp/+a8n/biU8XHQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:fj3kO2X5yGs=:r4DRa7oPbhL2Cp/tMsxLri 0UXNSBm5TFCw6p+MqcLW5k8ejukcMbKjXlbd94/KtlzQTBrXXcWsWDXmPS6ncAsJI/gRBgYN4 O2+rYdvaBYfvSus6eJgdSQkmHU0twbJ66r+efv2Tmd26CHfLv9IvnC6rUHRElo4ctzldbLMWy GTTe/6fuv1tGNLcHPfZHSL7/roKq4yDMeaDpzgAajuK7OgdYKrcdB0MrUdc8EK2tSdDXt7xti fAG35cuWVr6jNZGzlFqRlLJNvuVlZUQp2H/WvnMgu4WINKSq5VkThVw77cQ0JQsf1aETyVAOA UCUcmUaKVS/UqkLJ2M4VC+aXORwr3Q3mbahhYfSHUfb6U6c9jRaJn+3E7Q3sXeuG1PsexhbCw 90pWRbH8j5Enw7LhVinWavvXgo4GMbtB0v5ZdVbmYXfoaJt/wJy/JXZ7BykePlZOhwJr2uaP+ wzHMnhH0PKdQLzRIUXcUs2rZDZ4qQRXgbx3fzBCfBrIsJVpaqJeECt89e3tIbJRflgCgTN0nV M0h4M+57ycRVc4VpG6rAhdA0PU3usjjdawrRLRjcXx/W+e85jvRsqHXOhzSLZKGpRtRHHd9sV qGAurZ8DiwqxiEIJM9RvEOXZuCUEXSBPPYRS0IbdsitnQZWIsMXU3dDQs6esoGesTtPCz1/bY 7w3s= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210419_051707_671018_F06B008E X-CRM114-Status: GOOD ( 29.72 ) 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 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 -- 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, 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