> On 25 Feb 2025, at 8:40 PM, Aditya Garg <gargadity...@live.com> wrote:
>
>
>
>> On 25 Feb 2025, at 8:24 PM, Aditya Garg <gargadity...@live.com> wrote:
>>
>>
>>
>>>> On 25 Feb 2025, at 5:28 PM, Thomas Zimmermann <tzimmerm...@suse.de> wrote:
>>>
>>> Hi
>>>
>>>> Am 25.02.25 um 11:33 schrieb andriy.shevche...@linux.intel.com:
>>>>>> On Tue, Feb 25, 2025 at 10:09:42AM +0000, Aditya Garg wrote:
>>>>>> From: Kerem Karabay <kek...@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)
I think it shall also make sense since it is a USB device error, not a drm
error.
> 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?
