Am Sonntag, dem 12.03.2023 um 15:41 +0100 schrieb Martin Kepplinger: > Am Freitag, dem 10.03.2023 um 14:18 -0800 schrieb Saravana Kannan: > > On Fri, Mar 10, 2023 at 2:07 AM Martin Kepplinger > > <martin.kepplinger@xxxxxxx> wrote: > > > > > > 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. > > > > If you find out it's one of the other 12 patches in the refactor > > that > > broke things for you, can you please reply to the right email in > > that > > series[1] and let me know which patch broke things for you and > > provide > > the debug details there? I don't want to mix issues with unrelated > > threads -- I want them to be easy to find in the future. > > > > [1] - > > https://lore.kernel.org/lkml/20230207014207.1678715-1-saravanak@xxxxxxxxxx/ > > > > For all my questions below, you don't need to reply here. Just > > reply > > to the right thread. > > Thanks. I'll have to reply here though - I'm puzzled how, but I got > it > wrong - I must have seen the "Failed to create device link" messages > without checking broken drivers: The 12 patches you linked above are > fine. (In a way that's good as I saw them in a stable kernel > already). > > commit ("usb: typec: tipd: Remove use of > fw_devlink_purge_absent_suppliers()") breaks things for me. That is > patch 2 of this series. That's for sure now. this thing is this: I have downstream patches against tipd, among others. And I don't know yet but we might very well do something wrong in our downstream tree that is now not compatible anymore with this removal... I switched to a tree without any downstream stuff: For the 12 earlier patches, I there see the follwing which is NOT your fault and we need to fix upstream (we fix that in our downstream tree): root@pureos:/home/purism# cat /sys/kernel/debug/devices_deferred 3-0036 And then I add patch 2 of this series (removing the call from tipd), it becomes: root@pureos:/home/purism# cat /sys/kernel/debug/devices_deferred 0-003f 38100000.usb platform: wait for supplier endpoint 3-0036