From: Frank Li <Frank.li@oss.nxp.com>
To: Leonardo Costa <leoreis.costa@gmail.com>
Cc: Frank.Li@nxp.com, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Leonardo Costa <leonardo.costa@toradex.com>
Subject: Re: [PATCH 6/6] arm64: dts: freescale: imx8mp-verdin: Add Mezzanine with Toradex Display 10.1" LVDS V2
Date: Wed, 19 Aug 2026 09:18:27 -0500 [thread overview]
Message-ID: <aoW7M1CmaPWDxvhE@SMW015318> (raw)
In-Reply-To: <gsihg6tzkrq6gcygquzbjtiqntvoxp67lo6mqntnmbyvyw7s3y@suv4t26pl5eh>
On Wed, Aug 19, 2026 at 08:56:53AM -0300, Leonardo Costa wrote:
> On Tue, Aug 18, 2026 at 01:53:27PM -0500, Frank Li wrote:
> > On Tue, Aug 18, 2026 at 03:08:33PM -0300, Leonardo Costa wrote:
> > > It seems that the drivers are being deferred at boot start by the
> > > device_links_check_suppliers() function. It runs through the drivers before
> > > they're initialized and defers them if their suppliers are not available. The
> > > GPIO and PWM drivers are able to follow the gpio-map and pwm-map properties
> > > (through the of_parse_phandle_with_args_map() function), but from what I see,
> > > device_links_check_suppliers() has no such mechanism. It follows the phandle to
> > > the nexus connector node only, and since there's no compatible driver for it,
> > > the function defers the consumer drivers used in the overlay.
> > >
> > > I think this is what is happening mainly because setting the
> > > fw_devlink=permissive kernel parameter (which sets the DL_FLAG_SYNC_STATE_ONLY
> > > flag) solved the issue, though I could be misunderstanding something.
> > >
> > > int device_links_check_suppliers(struct device *dev)
> > > {
> > > ...
> > > list_for_each_entry(link, &dev->links.suppliers, c_node) {
> > > ...
> > >
> > > if (link->status != DL_STATE_AVAILABLE &&
> > > !device_link_test(link, DL_FLAG_SYNC_STATE_ONLY)) {
> > >
> > > ...
> > > device_links_missing_supplier(dev);
> > > ret = dev_err_probe(dev, -EPROBE_DEFER,
> > > "supplier %s not ready\n", dev_name(link->supplier));
> > > break;
> > > }
> > > WRITE_ONCE(link->status, DL_STATE_CONSUMER_PROBE);
> > > }
> > > ...
> > > }
> > >
> > > Has this behavior been observed before? Do you know of any work being done that
> > > addresses this?
> >
> > Does a dummy container driver (for debug) to proof your analyer? Let
> > me to find time to debug it.
> >
> > Frank
>
> I made a dummy driver matching that compatible string, and yes, it did
> solve the issue.
Thank you very much. Let me think how to fix this problem. Nexus node
should be direction overall.
Frank
>
> Leonardo
prev parent reply other threads:[~2026-08-19 14:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 13:33 [PATCH 0/6] arm64: dts: freescale: imx8mp-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS V1 and V2 Leonardo Costa
2026-08-13 13:33 ` [PATCH 1/6] arm64: dts: freescale: imx8mp-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS Leonardo Costa
2026-08-13 13:51 ` sashiko-bot
2026-08-13 16:52 ` Leonardo Costa
2026-08-13 13:33 ` [PATCH 2/6] arm64: dts: freescale: imx8mp-verdin: Add Toradex DSI to LVDS adapter with 10.1" display Leonardo Costa
2026-08-13 13:33 ` [PATCH 3/6] arm64: dts: freescale: imx8mp-verdin: Add Mezzanine with Toradex Display 10.1" LVDS Leonardo Costa
2026-08-13 13:33 ` [PATCH 4/6] arm64: dts: freescale: imx8mp-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS V2 Leonardo Costa
2026-08-13 14:19 ` sashiko-bot
2026-08-13 15:47 ` Leonardo Costa
2026-08-13 13:33 ` [PATCH 5/6] arm64: dts: freescale: imx8mp-verdin: Add Toradex DSI to LVDS adapter with the 10.1" V2 display Leonardo Costa
2026-08-13 14:28 ` sashiko-bot
2026-08-13 13:33 ` [PATCH 6/6] arm64: dts: freescale: imx8mp-verdin: Add Mezzanine with Toradex Display 10.1" LVDS V2 Leonardo Costa
2026-08-13 14:58 ` Frank Li
2026-08-13 15:43 ` Leonardo Costa
2026-08-13 16:15 ` Frank Li
2026-08-18 18:08 ` Leonardo Costa
2026-08-18 18:53 ` Frank Li
2026-08-19 11:56 ` Leonardo Costa
2026-08-19 14:18 ` Frank Li [this message]
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=aoW7M1CmaPWDxvhE@SMW015318 \
--to=frank.li@oss.nxp.com \
--cc=Frank.Li@nxp.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=leonardo.costa@toradex.com \
--cc=leoreis.costa@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.