lkml.org 
[lkml]   [2021]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/4] usb: Use notifier for linking Type C ports.
    Hi Heikki,

    Thanks for taking a look at the series.

    On Tue, Nov 30, 2021 at 3:03 AM Heikki Krogerus
    <heikki.krogerus@linux.intel.com> wrote:
    >
    > Hi Prashant,
    >
    > On Fri, Nov 26, 2021 at 11:40:49AM +0200, Heikki Krogerus wrote:
    > > On Wed, Nov 24, 2021 at 03:10:06PM -0800, Prashant Malani wrote:
    > > > This series resolves the cyclic dependency error which was introduced by
    > > > commit 63cd78617350 ("usb: Link the ports to the connectors they are
    > > > attached to") which lead to it being reverted. The approach here is to
    > > > use a notifier to link a new Type C port to pre-existing USB ports
    > > > instead of calling an iterator of usb ports from the Type C connector
    > > > class. This allows commit 63cd78617350 ("usb: Link the ports to the
    > > > connectors they are attached to") to then be submitted without any
    > > > depmod cyclic dependency error.
    > > >
    > > > The final patch removes the usb port iterator since it is no longer
    > > > needed.
    > >
    > > This is not enough. Build the Type-C Class as a module and the USB bus
    > > statically, and the links will not get created.
    > >

    I see. I suppose it is academic now (given your follow up email about converting
    port-mapper to component framework), but would reversing where the
    notifier block is i.e,
    have usbcore expose the notifier registration API instead of
    typec-class, resolve
    the issue? That would mean the dependency is the same as what it is right now
    in the code, right (typec -> usbcore)

    > > I'm not sure you actually achieve much with this series, and I'm not
    > > sure this approach will ever fully solve the problem. As long as we
    > > have to declare API, we will have the circular dependency issue on our
    > > hands. But there are ways to avoid that.
    > >
    > > There is for example the component framework (drivers/base/component.c)
    > > that I've been thinking about using here. In this case it would work
    > > so that you declare the USB Type-C part as your aggregate driver, and
    > > everything that is connected to it (so USB ports, DisplayPorts, TBT,
    > > etc.) would then just declare themselves as general components. Could
    > > you take a look at that?
    >
    > I'm preparing a patch where I store all _PLDs in the ACPI tables, and
    > create list of devices that share it. I can convert port-mapper.c to
    > it and the component framework while at it.

    Great, thanks. We can help with testing once you have a patch series
    to share.

    Best regards,

    -Prashant

    \
     
     \ /
      Last update: 2021-11-30 20:28    [W:3.264 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site