Re: [PATCH 08/10] HID: apple: Add DockChannel HID transport driver

On 7/1/26 16:32, Michael Reeves wrote:
> Hi Yureka,
>
> Thank you for the review and the feedback.
>
> On Tue, Jun 30, 2026 at 11:21 PM Yureka Lilian <[email protected]> wrote:
> [...]
>>> +     strscpy(hid->uniq, dchid->serial, sizeof(hid->uniq));
>> If the keyboard appeared before stm, dchip->serial might be uninitialized.
> Yes, true, thank you for picking this up!
> [...]
>>> +     /*
>>> +      * Prefer to enable STM first, since it provides device IDs. Some
>>> +      * firmware versions do not expose STM, so let the keyboard start
>>> +      * without it.
>>> +      */
>>> +     if (iface->dchid->id_ready || !strcmp(iface->name, "stm") ||
>>> +         !strcmp(iface->name, "keyboard"))
>> I specifically asked for a mechanism to let the keyboard probe even on
>> devices which do not expose/have stm. Thanks for adding that!
>> However, I think this might need some more sophisticated mechanism to
>> decide whether the stm is still going to appear after the keyboard, or
>> not at all. I'm not sure if there is a way to tell this at this point,
>> or we need to add a timeout for the stm to appearing, which needs to
>> expire before we create the other interfaces with fake serials.
>>
> I do not think there is a way to tell at this point, unfortunately.
>
> I think the best way to resolve this would be to implement a delayed work
> item that is scheduled during probe. If STM appears and initalises before
> the timer (I'm not sure how long it should be right now, I will prototype and
> experiment) we cancel the delayed work, get the real serial, and spin up
> the keyboard. If the timeout expires without seeing the STM interface, we
> assume the platform does not have one, mark id_ready as true, and
> proceed to init the keyboard.

I see three ways forward (no specific order):

1) Implement the timeout as you described.

2) Use the approach that always waits for the stm to appear, and is 
proven to work well on the M2 devices targeted by this series. A 
different behavior that does not wait for the stm / determines the 
serials using other means can be added at a later point in the same 
driver but with a different compatible string.

3) Add an stm subnode (like the downstream Asahi device trees have for 
their dockchannel-mtp nodes [1]) which indicates whether the stm is 
present. Check for the existence of this subnode to decide whether to 
wait for the stm or add the HID devices with fake serials. Support for 
other methods of retrieving the serials can be added later and indicated 
by other subnodes.

I would appreciate feedback from all of you on which of these options we 
should move forward with.

>
> I will work on this and experiment to see if it's the best solution or
> if there's
> any others as well as to find the ideal timeout, and submit as part of v2.
> [...]
>
> Thanks again,
> Michael


Thanks,

- Yureka

Link: 
https://github.com/AsahiLinux/linux/blob/asahi-7.1.5-2/arch/arm64/boot/dts/apple/t8112-j413.dts#L260 
[1]