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

On 8/1/26 23:56, Yureka Lilian wrote:
> 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.

After checking ioreg -l under macOS on the MacBook Neo (which is the one 
Apple Silicon MacBook having the non-force-touch trackpad variant, and 
sending no stm report), I'm convinced it legit has no Serial to report 
for the keyboard/trackpad HID devices, so we'll always have to use the 
fake one there.

Knowing this, I'd rule out Option 2). Between option 1 (timeout) and 
option 3 (device tree node), I prefer the device tree node. We already 
have the keyboard subnode and we know for each MacBook model whether it 
has an stm or not, so having the stm subnode seems logical. As a bonus, 
the code for this is quite simple, and I will prepare the v2 of this 
series shortly.

>
>>
>> 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]
>