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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PN3PR01MB9597BF95EC490951D75748F1B8C32@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
Date: Tue, 25 Feb 2025 10:36:03 +0000
From: Aditya Garg <gargaditya08@...e.com>
To: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>
CC: "maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de"
	<tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>,
	"simona@...ll.ch" <simona@...ll.ch>, Kerem Karabay <kekrby@...il.com>,
	Atharva Tiwari <evepolonium@...il.com>, Aun-Ali Zaidi <admin@...eit.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v5 2/2] drm/tiny: add driver for Apple Touch Bars in x86
 Macs



> On 25 Feb 2025, at 4:03 PM, andriy.shevchenko@...ux.intel.com wrote:
> 
> On Tue, Feb 25, 2025 at 10:09:42AM +0000, Aditya Garg wrote:
>> From: Kerem Karabay <kekrby@...il.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,
> 

I'm not sure how drm_err works, but struct drm_device does have a struct device *dev as well. Anyways, this is something I'll leave for Thomas to reply.