linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	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 <arnd@arndb.de>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 18:33:44 +0900	[thread overview]
Message-ID: <YH1OeFy+SepIYYG0@atmark-techno.com> (raw)
In-Reply-To: <CAMuHMdVY1SLZ0K30T2pimyrR6Mm=VoSTO=L-xxCy2Bj7_kostw@mail.gmail.com>


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

  reply	other threads:[~2021-04-19  9:34 UTC|newest]

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 [this message]
2021-04-19 12:16         ` Arnd Bergmann
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=YH1OeFy+SepIYYG0@atmark-techno.com \
    --to=dominique.martinet@atmark-techno.com \
    --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=arnd@arndb.de \
    --cc=aymen.sghaier@nxp.com \
    --cc=balbi@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=dmaengine@vger.kernel.org \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).