MIME-Version: 1.0
References: <20230301214952.2190757-1-saravanak@google.com>
 <2a8e407f4f18c9350f8629a2b5fa18673355b2ae.camel@puri.sm> <e65e08c13885468675af527ffa2ab882cc9e682d.camel@puri.sm>
In-Reply-To: <e65e08c13885468675af527ffa2ab882cc9e682d.camel@puri.sm>
From:   Saravana Kannan <saravanak@google.com>
Date:   Thu, 9 Mar 2023 16:24:05 -0800
Message-ID: <CAGETcx93K1VjAosX9NDEyLVLPK2utPSUV6dwzdAT-Dc5BfmhzQ@mail.gmail.com>
Subject: Re: [PATCH v1 0/4] Remove use of fw_devlink_purge_absent_suppliers()
To:     Martin Kepplinger <martin.kepplinger@puri.sm>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Guenter Roeck <linux@roeck-us.net>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Daniel Scally <djrscally@gmail.com>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Len Brown <lenb@kernel.org>,
        Yongqin Liu <yongqin.liu@linaro.org>,
        Sumit Semwal <sumit.semwal@linaro.org>,
        Amelie Delaunay <amelie.delaunay@foss.st.com>,
        kernel-team@android.com, linux-kernel@vger.kernel.org,
        linux-usb@vger.kernel.org, linux-acpi@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Mar 2, 2023 at 1:41=E2=80=AFAM Martin Kepplinger
<martin.kepplinger@puri.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_d=
evlink
> > ) 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_dev=
link_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?

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.

-Saravana