Re: [PATCH RFC 00/12] arm64: mediatek: Add M.2 E-key slot on Chromebooks

[Bartosz Golaszewski]

On Wed, 27 May 2026 18:21:00 +0200, Chen-Yu Tsai <wenst@xxxxxxxxxxxx> said:
> On Tue, May 26, 2026 at 11:48 AM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
>>
>> On Sun, May 24, 2026 at 10:06 AM Chen-Yu Tsai <wenst@xxxxxxxxxxxx> 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@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?
>
> The "bus type" type is probably not exported. However since the DT binding
> explicitly says which port on the M.2 slot is for which connection type,
> I think the matching can do a special case check for the USB port.
> The next obstacle is that the target string is not given to the provider
> match function.
>
>> > Also, the "port@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@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.
>
> It shouldn't be. I'm just saying there would be different behavior on
> the USB side for connectors vs onboard devices (like hubs) device nodes.
>
> I talked to Greg earlier, and he said not to touch the hub driver; the
> hub driver should only deal with features from the USB spec. The
> "onboard USB devices" driver is what should be used. And this would
> be a proper case of adding an auxiliary device to the M.2 slot driver.
>

The onboard USB device is what initially inspired the PCI pwrctl code so it
doesn't surprise me we circle back to it.

> However this seems to completely decouple the power sequencing from the
> USB core. Take the USB A connector for example, it was recently added to
> the onboard USB devices driver. However the connector has a device node
> that is not a child node of any USB host controller or hub; it is connected
> through OF graph. At the same time, since it typically sits at the top
> level of the device tree, a platform device is directly created and the
> driver subsequently binds to that device. This is totally different from
> how the hub and other directly connected onboard USB devices work. In
> the onboard device case, the device node is a child node of the USB hub
> or controller, and the corresponding platform device only gets created
> when the USB hub driver probes, thereby sort of tying it into the USB
> device topology.
>

Which is precisely what we do for PCI pwrctl. Though I'm not sure how we could
replicate this behavior without touching the hub driver.

> If the power sequencing ends up not connected to the USB subsystem, then
> maybe the M.2 slot driver could just check if the USB port (port@3) was
> used, and just enable the USB / BT pwrseq target at probe time? That
> would mean less changes needed.
>

That sounds sane to me.

Bartosz