Re: [PATCH v1 0/4] Remove use of fw_devlink_purge_absent_suppliers()

[Martin Kepplinger]

Am Donnerstag, dem 09.03.2023 um 16:24 -0800 schrieb Saravana Kannan:
> On Thu, Mar 2, 2023 at 1:41 AM Martin Kepplinger
> <martin.kepplinger@xxxxxxx> wrote:
> > 
> > Am Donnerstag, dem 02.03.2023 um 10:12 +0100 schrieb Martin
> > Kepplinger:
> > > Am Mittwoch, dem 01.03.2023 um 13:49 -0800 schrieb Saravana
> > > Kannan:
> > > > Yongqin, Martin, Amelie,
> > > > 
> > > > We recent refactor of fw_devlink that ends with commit
> > > > fb42378dcc7f
> > > > ("mtd: mtdpart: Don't create platform device that'll never
> > > > probe"),
> > > > fw_devlink is smarter and doesn't depend on compatible
> > > > property.
> > > > So,
> > > > I
> > > > don't think these calls are needed anymore. But I don't have
> > > > these
> > > > devices to test on and be sure and the hardware I use to test
> > > > changes
> > > > doesn't have this issue either.
> > > > 
> > > > Can you please test these changes on the hardware where you hit
> > > > the
> > > > issue to make sure things work as expected?
> > > > 
> > > > Yongqin, If you didn't have the context, this affected
> > > > hikey960.
> > > > 
> > > > Greg,
> > > > 
> > > > Let's wait for some tests before we land these.
> > > > 
> > > > Thanks,
> > > > Saravana
> > > 
> > > hi Sravana,
> > > 
> > > I picked the 12 commits leading up to commit fb42378dcc7f ("mtd:
> > > mtdpart: Don't create platform device that'll never probe") (
> > > https://source.puri.sm/martin.kepplinger/linux-next/-/commits/test_fw_devlink
> > > ) and included the tipd patch below to test it.
> > > 
> > > With that, I get the following errors:
> > > 
> > > [    0.237931] imx-uart 30890000.serial: Failed to create device
> > > link
> > > with regulator-gnss
> > > [    0.334054] nwl-dsi 30a00000.mipi-dsi: Failed to create device
> > > link
> > > with regulator-lcd-1v8
> > > [    0.346964] nwl-dsi 30a00000.mipi-dsi: Failed to create device
> > > link
> > > with backlight-dsi
> > > 
> > > but they are independent of this final tipd patch below. I'll
> > > test a
> > > real linux-next tree soon, for completeness, maybe I missed
> > > something?
> > > 
> > > Anyways, on that tree, your tipd removal patch breaks type-c
> > > still
> > > for
> > > me, imx8mq-librem5.dtsi
> > > 
> > > just to give a first reply quickly... thanks,
> > > 
> > >                              martin
> > > 
> > 
> > just confirming: it's the same as above on next-20230302 + this
> > patch (
> > https://source.puri.sm/martin.kepplinger/linux-next/-/commits/test_fw_devlink_next-20230302
> > ) with the errors already independent from the patch. I should have
> > tested earlier patches -.-
> 
> Thanks a lot for testing Martin!
> 
> Your email is a little ambiguous to me. With the 12 refactor commits
> +
> the 4 patches in this series, things are breaking for you. But if you
> drop the 4 patches in this series, things work again. Is that right?

no. Sorry if I wasn't clear. I can't justify to block these 4 patches.
they *themselves* don't break anything.

Something broke *earlier* than these 4 patches in one of the other 12.

As to *what* broke: The error messages during boot, and the charger and
fuel gauge don't work anymore, I see:

# cat /sys/kernel/debug/devices_deferred 
3-0036	max17042: failed: power supply register
0-003f	
38100000.usb	platform: wait for supplier endpoint
32c00000.hdmi	platform: supplier 0-003f not ready
3-006a	bq25890-charger: registering power supply


I haven't had time to track it down and see where the issue is. Could
be one of the 12 patches, could be a wrong description for my board:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
or something else (an i2c issue?).

(for completeness, the exact tree I ran:
https://source.puri.sm/martin.kepplinger/linux-next/-/commits/test_fw_devlink
)

> 
> Let's ignore the "Failed to create device link" errors for now --
> it's
> not related to this usb-c-connector series. It's basically pointing
> out issues that we ignored silently in the past -- it's basically
> pointing out holes in fw_devlink's visibility of devices. I'll get to
> them later.

ok. good to know. please do.

And since I'm the only one seeing an issue, please move the patches
forward. I'll need to fix this after the fact and hope to have time for
it next week.

> 
> -Saravana


                           martin