public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: "andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>,
	Aditya Garg <gargaditya08@live.com>
Cc: "maarten.lankhorst@linux.intel.com"
	<maarten.lankhorst@linux.intel.com>,
	"mripard@kernel.org" <mripard@kernel.org>,
	"airlied@gmail.com" <airlied@gmail.com>,
	"simona@ffwll.ch" <simona@ffwll.ch>,
	Kerem Karabay <kekrby@gmail.com>,
	Atharva Tiwari <evepolonium@gmail.com>,
	Aun-Ali Zaidi <admin@kodeit.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v5 2/2] drm/tiny: add driver for Apple Touch Bars in x86 Macs
Date: Tue, 25 Feb 2025 12:58:17 +0100	[thread overview]
Message-ID: <c0249cd8-68e4-4860-b5c3-e054df10ae30@suse.de> (raw)
In-Reply-To: <Z72chunE_vvxtjLQ@smile.fi.intel.com>

Hi

Am 25.02.25 um 11:33 schrieb andriy.shevchenko@linux.intel.com:
> On Tue, Feb 25, 2025 at 10:09:42AM +0000, Aditya Garg wrote:
>> From: Kerem Karabay <kekrby@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.

Best regards
Thomas

>
>> +		return ret;
>> +	}
>> +
>> +	adev = devm_drm_dev_alloc(dev, &appletbdrm_drm_driver, struct appletbdrm_device, drm);
>> +	if (IS_ERR(adev))
>> +		return PTR_ERR(adev);
>> +
>> +	adev->in_ep = bulk_in->bEndpointAddress;
>> +	adev->out_ep = bulk_out->bEndpointAddress;
>> +	adev->dmadev = dev;
>> +
>> +	drm = &adev->drm;
>> +
>> +	usb_set_intfdata(intf, adev);
>> +
>> +	ret = appletbdrm_get_information(adev);
>> +	if (ret) {
>> +		drm_err(drm, "Failed to get display information\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = appletbdrm_signal_readiness(adev);
>> +	if (ret) {
>> +		drm_err(drm, "Failed to signal readiness\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = appletbdrm_setup_mode_config(adev);
>> +	if (ret) {
>> +		drm_err(drm, "Failed to setup mode config\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = drm_dev_register(drm, 0);
>> +	if (ret) {
>> +		drm_err(drm, "Failed to register DRM device\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = appletbdrm_clear_display(adev);
>> +	if (ret) {
>> +		drm_err(drm, "Failed to clear display\n");
>> +		return ret;
>> +	}
>> +
>> +	return 0;
>> +}

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


  parent reply	other threads:[~2025-02-25 11:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-25 10:06 [PATCH v5 0/2] Touch Bar DRM driver for x86 Macs Aditya Garg
2025-02-25 10:07 ` [PATCH v5 1/2] drm/format-helper: Add conversion from XRGB8888 to BGR888 Aditya Garg
2025-02-25 10:09 ` [PATCH v5 2/2] drm/tiny: add driver for Apple Touch Bars in x86 Macs Aditya Garg
2025-02-25 10:33   ` andriy.shevchenko
2025-02-25 10:36     ` Aditya Garg
2025-02-25 10:46       ` andriy.shevchenko
2025-02-25 10:48         ` Aditya Garg
2025-02-25 11:01           ` andriy.shevchenko
2025-02-25 11:59             ` Thomas Zimmermann
2025-02-25 13:27               ` andriy.shevchenko
2025-02-25 13:53                 ` Thomas Zimmermann
2025-02-25 14:17                   ` andriy.shevchenko
2025-02-25 11:49         ` Aditya Garg
2025-02-25 11:58     ` Thomas Zimmermann [this message]
2025-02-25 13:25       ` andriy.shevchenko
2025-02-25 14:54       ` Aditya Garg
2025-02-25 14:56         ` Aditya Garg
2025-02-25 15:01           ` Aditya Garg
2025-02-25 15:10         ` Aditya Garg
2025-02-25 15:59           ` Aditya Garg
2025-02-25 16:06         ` Thomas Zimmermann
2025-02-25 16:09           ` Aditya Garg
2025-02-25 16:40             ` Aditya Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c0249cd8-68e4-4860-b5c3-e054df10ae30@suse.de \
    --to=tzimmermann@suse.de \
    --cc=admin@kodeit.net \
    --cc=airlied@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=evepolonium@gmail.com \
    --cc=gargaditya08@live.com \
    --cc=kekrby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox