[PATCH v5 2/2] drm/tiny: add driver for Apple Touch Bars in x86 Macs

[Aditya Garg]

> On 25 Feb 2025, at 8:24 PM, Aditya Garg <gargaditya08 at live.com> wrote:
> 
> 
> 
>> On 25 Feb 2025, at 5:28 PM, Thomas Zimmermann <tzimmermann at suse.de> wrote:
>> 
>> Hi
>> 
>>> Am 25.02.25 um 11:33 schrieb andriy.shevchenko at linux.intel.com:
>>>>> On Tue, Feb 25, 2025 at 10:09:42AM +0000, Aditya Garg wrote:
>>>>> From: Kerem Karabay <kekrby at gmail.com>
>>>>> 
>>>>> The Touch Bars found on x86 Macs support two USB configurations: one
>>>>> where the device presents itself as a HID keyboard and can display
>>>>> predefined sets of keys, and one where the operating system has full
>>>>> control over what is displayed.
>>>>> 
>>>>> This commit adds support for the display functionality of the second
>>>>> configuration. Functionality for the first configuration has been
>>>>> merged in the HID tree.
>>>>> 
>>>>> Note that this driver has only been tested on T2 Macs, and only includes
>>>>> the USB device ID for these devices. Testing on T1 Macs would be
>>>>> appreciated.
>>>>> 
>>>>> Credit goes to Ben (Bingxing) Wang on GitHub for reverse engineering
>>>>> most of the protocol.
>>>>> 
>>>>> Also, as requested by Andy, I would like to clarify the use of __packed
>>>>> structs in this driver:
>>>>> 
>>>>> - All the packed structs are aligned except for appletbdrm_msg_information.
>>>>> - We have to pack appletbdrm_msg_information since it is requirement of
>>>>>  the protocol.
>>>>> - We compared binaries compiled by keeping the rest structs __packed and
>>>>>  not __packed using bloat-o-meter, and __packed was not affecting code
>>>>>  generation.
>>>>> - To maintain consistency, rest structs have been kept __packed.
>>>>> 
>>>>> I would also like to point out that since the driver was reverse-engineered
>>>>> the actual data types of the protocol might be different, including, but
>>>>> not limited to, endianness.
>>> ...
>>> 
>>>> +static int appletbdrm_probe(struct usb_interface *intf,
>>>> +                const struct usb_device_id *id)
>>>> +{
>>>> +    struct usb_endpoint_descriptor *bulk_in, *bulk_out;
>>>> +    struct device *dev = &intf->dev;
>>>> +    struct appletbdrm_device *adev;
>>>> +    struct drm_device *drm;
>>>> +    int ret;
>>>> +
>>>> +    ret = usb_find_common_endpoints(intf->cur_altsetting, &bulk_in, &bulk_out, NULL, NULL);
>>>> +    if (ret) {
>>>> +        drm_err(drm, "Failed to find bulk endpoints\n");
>>> This is simply wrong (and in this case even lead to crash in some circumstances).
>>> drm_err() may not be used here. That's my point in previous discussions.
>>> Independently on the subsystem the ->probe() for the sake of consistency and
>>> being informative should only rely on struct device *dev,
>> 
>> That's never going to work with DRM. There's so much code in a DRM probe function that uses the DRM error functions.
>> 
>> This specific instance here is wrong, as the drm pointer hasn't been initialized. But as soon as it is, it's much better to use drm_err() and friends. It will do the right thing and give consistent output across drivers.
>> 
> Ok so this is actually an interesting case, since I am trying to fix it. To initialise the drm pointer, we need to initialise adev, and to initialise adev, we need to run usb_find_common_endpoints first. So IMO, we cannot use drm_err here, but rather dev_err_probe can be used.

So the option here can be:

1. Use dev_err_probe (it's not that no DRM driver uses it)
2. Remove the message (seems to be done by other drm drivers as well, I wouldn't really want that though)


Thomas, Andy what do you think?