Re: [PATCH v4 04/10] dt-bindings: input: apple: Add DockChannel HID transport

[Yureka Lilian]

On 10/6/26 18:00, Rob Herring wrote:
> On Fri, Sep 25, 2026 at 10:09:31PM +1000, Michael Reeves wrote:
> [...]
> > +
> > +  mboxes:
> > +    items:
> > +      - description: ASC mailbox used for RTKit control
> > +      - description: DockChannel FIFO mailbox used for HID packets
> > +
> > +  mbox-names:
> > +    items:
> > +      - const: asc
> > +      - const: dockchannel
> > +
> > +  iommus:
> > +    maxItems: 1
> > +
> > +  stm:
> > +    type: object
> > +    description:
> > +      STM interface providing the vendor, product and version identifiers
> > +      and serial number shared by the HID devices. When present, the host
> > +      must query this interface before registering the keyboard.
> > +    additionalProperties: false
> An empty node is unusual. Why can't you just query the STM interface and
> treat it not existing or having those properties the same as no 'stm'
> node.

The issue is there is no indicator for the stm *not* being present: We 
boot the MTP coprocessor, and then receive a message when the stm is 
available. In that case we know it's ready and we can proceed with 
obtaining the serial numbers and registering the hid devices. But if 
there is no stm, we simply do not get the stm ready message, and the hid 
devices are never registered (this is the case in the original 
downstream Asahi dockchannel-hid). To make the stm optional *without* 
taking the information from the device tree, this would require some 
sort of timeout for waiting for the stm ready message. I outlined the 
available options in this thread[1] and argued the empty stm subnode 
makes sense, since this is describing a peripheral which may or may not 
be present (and this information is useful to initialize the device 
properly).

Link[1]: 
https://lore.kernel.org/asahi/bbaca769-312c-4a24-9524-16cb2b4f277f@xxxxxxxxxxxxxx/


Thanks,

- Yureka