[PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks
Bartosz Golaszewski
brgl at kernel.org
Tue May 26 02:48:01 PDT 2026
On Sun, May 24, 2026 at 10:06 AM Chen-Yu Tsai <wenst at chromium.org> wrote:
>
> > >
> > > I expect some discussion on this patch, because a) it adds some
> > > OF-specific code into an otherwise generic (core) driver, and
> > > b) it doesn't yet handle USB 2.0 / 3.x shared ports; it ends up powering
> > > on the port twice, which negates the port reset part.
> > >
> >
> > I understand that you do this because the port device has no OF node
> > assigned. If we wanted to call pwrseq_get() for the port device, is
> > there really no other way to associate it with the correct pwrseq
> > provider?
>
> I suppose we could tie the "port at X" node to the usb port device, but
> AFAIK no other subsystem does this so we would be introducing a new
> pattern.
>
> In the M.2 pwrseq driver, we would have to match by port node instead
> of its parent device node. We may end up with different behavior for
> the USB target vs the other targets.
>
I imagine, we can check the bus type of the parent device to know if
this is USB?
> Also, the "port at X" nodes only exist for the OF graph connections to
> connectors and/or muxes (this series doesn't deal with the latter).
> For directly connected devices, there is a "device at X" child node
> directly under the USB hub node. That node is what gets tied to the
> the USB device.
>
Is this a problem? I don't think I understand what you're saying here.
Bart
More information about the linux-arm-kernel
mailing list