Linux-OMAP Archive on lore.kernel.org
 help / color / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	gregkh <gregkh@linuxfoundation.org>,
	"Rafael Wysocki" <rafael@kernel.org>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	aymen.sghaier@nxp.com, "Herbert Xu" <herbert@gondor.apana.org.au>,
	"David Miller" <davem@davemloft.net>,
	"Tony Lindgren" <tony@atomide.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Vinod Koul" <vkoul@kernel.org>,
	peter.ujfalusi@gmail.com, "Andrzej Hajda" <a.hajda@samsung.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Kevin Hilman" <khilman@baylibre.com>,
	tomba@kernel.org, jyri.sarha@iki.fi,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>, Kishon <kishon@ti.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Roy Pledge" <Roy.Pledge@nxp.com>, "Leo Li" <leoyang.li@nxp.com>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Eduardo Valentin" <edubezval@gmail.com>,
	Keerthy <j-keerthy@ti.com>, "Felipe Balbi" <balbi@kernel.org>,
	"Tony Prisk" <linux@prisktech.co.nz>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	dmaengine@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:ARM/Amlogic Meson SoC support"
	<linux-amlogic@lists.infradead.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	linux-phy@lists.infradead.org,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-staging@lists.linux.dev,
	"moderated list:ARM/Mediatek SoC..."
	<linux-mediatek@lists.infradead.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	"USB list" <linux-usb@vger.kernel.org>,
	LINUXWATCHDOG <linux-watchdog@vger.kernel.org>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 14:16:36 +0200
Message-ID: <CAK8P3a1Mu2F0irDDCL-50HiHth29iYFL5b7WHZ=UX6W7zzoxAg@mail.gmail.com> (raw)
In-Reply-To: <YH1OeFy+SepIYYG0@atmark-techno.com>

On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> 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

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19  4:27 [RFC v1 PATCH 0/3] support soc_device_match to return -EPROBE_DEFER Alice Guo (OSS)
2021-04-19  4:27 ` [RFC v1 PATCH 1/3] drivers: soc: add support for soc_device_match returning -EPROBE_DEFER Alice Guo (OSS)
2021-04-19  4:49   ` Dominique MARTINET
2021-04-19  6:40     ` Alice Guo (OSS)
2021-04-19  8:20   ` Geert Uytterhoeven
2021-04-20 11:21     ` Dan Carpenter
2021-04-19  4:27 ` [RFC v1 PATCH 2/3] caam: add defer probe when the caam driver cannot identify SoC Alice Guo (OSS)
2021-04-19  4:27 ` [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Alice Guo (OSS)
2021-04-19  5:02   ` Leon Romanovsky
2021-04-19  6:46     ` Alice Guo (OSS)
2021-04-19  5:02   ` Dominique MARTINET
2021-04-19  7:09     ` Alice Guo (OSS)
2021-04-19  9:03     ` Geert Uytterhoeven
2021-04-19  9:33       ` Dominique MARTINET
2021-04-19 12:16         ` Arnd Bergmann [this message]
2021-04-19 23:42           ` Dominique MARTINET
2021-04-20  9:07             ` Arnd Bergmann
2021-04-20  9:10             ` Arnd Bergmann
2021-04-19 13:36   ` Guenter Roeck
2021-04-20  9:40   ` Péter Ujfalusi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK8P3a1Mu2F0irDDCL-50HiHth29iYFL5b7WHZ=UX6W7zzoxAg@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=Roy.Pledge@nxp.com \
    --cc=a.hajda@samsung.com \
    --cc=adrian.hunter@intel.com \
    --cc=airlied@linux.ie \
    --cc=alice.guo@oss.nxp.com \
    --cc=aymen.sghaier@nxp.com \
    --cc=balbi@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=dmaengine@vger.kernel.org \
    --cc=dominique.martinet@atmark-techno.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=edubezval@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=horia.geanta@nxp.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=j-keerthy@ti.com \
    --cc=joro@8bytes.org \
    --cc=jyri.sarha@iki.fi \
    --cc=khilman@baylibre.com \
    --cc=kishon@ti.com \
    --cc=kuba@kernel.org \
    --cc=leoyang.li@nxp.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@prisktech.co.nz \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=narmstrong@baylibre.com \
    --cc=netdev@vger.kernel.org \
    --cc=peter.ujfalusi@gmail.com \
    --cc=rafael@kernel.org \
    --cc=robert.foss@linaro.org \
    --cc=sboyd@kernel.org \
    --cc=ssantosh@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tomba@kernel.org \
    --cc=tony@atomide.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vkoul@kernel.org \
    --cc=will@kernel.org \
    --cc=wim@linux-watchdog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-OMAP Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-omap/0 linux-omap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-omap linux-omap/ https://lore.kernel.org/linux-omap \
		linux-omap@vger.kernel.org
	public-inbox-index linux-omap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-omap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git