Re: next/master bisection: baseline.bootrr.intel-igb-probed on kontron-pitx-imx8m

From: Saravana Kannan <saravanak@google.com>
To: Mark Brown <broonie@kernel.org>
Cc: Michael Walle <michael@walle.cc>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	 Ulf Hansson <ulf.hansson@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 kernelci-results@groups.io, bot@kernelci.org,
	gtucker@collabora.com,  linux-arm-kernel@lists.infradead.org,
	linux-pci@vger.kernel.org
Subject: Re: next/master bisection: baseline.bootrr.intel-igb-probed on kontron-pitx-imx8m
Date: Fri, 12 Aug 2022 16:54:25 -0700	[thread overview]
Message-ID: <CAGETcx_JSViBcySNp+Rany2osBiKL7ON+tooPKW8TOTP6+t_HA@mail.gmail.com> (raw)
In-Reply-To: <YvEEidOZ62igUYrR@sirena.org.uk>

On Mon, Aug 8, 2022 at 5:41 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Aug 08, 2022 at 02:35:38PM +0200, Michael Walle wrote:
> > Am 2022-08-08 14:22, schrieb Mark Brown:
> > > On Sat, Aug 06, 2022 at 01:48:25PM -0700, KernelCI bot wrote:
>
> > > The KernelCI bisection bot found that 5a46079a96451 "PM: domains: Delete
> > > usage of driver_deferred_probe_check_state()" triggered a failure to
> > > probe the PCI controller or attached ethernet on kontron-pitx-imx8m.
> > > There's no obvious errors in the boot log when things fail, we simply
> > > don't see any of the announcements from the PCI controller probe like we
> > > do on a working boot:
>
> > I guess that is the same as:
> > https://lore.kernel.org/lkml/Yr3vEDDulZj1Dplv@sirena.org.uk/

Yeah, that series caused a bunch of breakages. So I sent a revert
series and then started working on the proper fix. I sent out the
proper fix a few days ago. Can anyone give this a shot?

[1-] https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/

Mark,

While you are here, I'm working towards patches on top of [1] where
fw_devlink will tie the sync_state() callback to each regulator. Also,
i realized that if you can convert the regulator_class to a
regulator_bus, we could remove a lot of the "find the supply for this
regulator when it's registered" code and let device links handle it.
Let me know if that's something you'd be okay with. It would change
the sysfs path for /sys/class/regulator and moves it to
/sys/bus/regulator, but not sure if that's considered an ABI breakage
(sysfs paths change all the time).

-Saravana

>
> Looks plausible, yes.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel