| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2f84f3196c426a3957d479d8fe0d1440a82932af.camel@puri.sm>
Date: Mon, 13 Mar 2023 10:05:52 +0100
From: Martin Kepplinger <martin.kepplinger@...i.sm>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Guenter Roeck <linux@...ck-us.net>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Daniel Scally <djrscally@...il.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Len Brown <lenb@...nel.org>,
Yongqin Liu <yongqin.liu@...aro.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
Amelie Delaunay <amelie.delaunay@...s.st.com>,
kernel-team@...roid.com, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v1 0/4] Remove use of fw_devlink_purge_absent_suppliers()
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@...i.sm> 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@...i.sm> 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@google.com/
> >
> > 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@...eos:/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@...eos:/home/purism# cat /sys/kernel/debug/devices_deferred
0-003f
38100000.usb platform: wait for supplier endpoint
3-0036
Powered by blists - more mailing lists