linux-kernel - Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI

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: <877cj56cip.fsf@intel.com>
Date: Thu, 15 Feb 2024 16:13:50 +0200
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Ville Syrjälä <ville.syrjala@...ux.intel.com>, Mario
 Limonciello
 <mario.limonciello@....com>
Cc: Daniel Vetter <daniel@...ll.ch>, Alex Deucher
 <alexander.deucher@....com>, Hans de Goede <hdegoede@...hat.com>, "open
 list:DRM DRIVERS" <dri-devel@...ts.freedesktop.org>,
 amd-gfx@...ts.freedesktop.org, "open list:USB SUBSYSTEM"
 <linux-usb@...r.kernel.org>, linux-fbdev@...r.kernel.org,
 nouveau@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
 platform-driver-x86@...r.kernel.org, intel-xe@...ts.freedesktop.org,
 linux-renesas-soc@...r.kernel.org, "open list:ACPI"
 <linux-acpi@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>,
 Melissa Wen <mwen@...lia.com>, Mark Pearson <mpearson-lenovo@...ebb.ca>
Subject: Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI

On Thu, 15 Feb 2024, Ville Syrjälä <ville.syrjala@...ux.intel.com> wrote:
> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
>> +static int
>> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
>> +{
>> +	struct drm_connector *connector = data;
>> +	struct drm_device *ddev = connector->dev;
>> +	struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
>> +	unsigned char start = block * EDID_LENGTH;
>> +	void *edid;
>> +	int r;
>> +
>> +	if (!acpidev)
>> +		return -ENODEV;
>> +
>> +	switch (connector->connector_type) {
>> +	case DRM_MODE_CONNECTOR_LVDS:
>> +	case DRM_MODE_CONNECTOR_eDP:
>> +		break;
>> +	default:
>> +		return -EINVAL;
>> +	}
>
> We could have other types of connectors that want this too.
> I don't see any real benefit in having this check tbh. Drivers
> should simply notset the flag on connectors where it won't work,
> and only the driver can really know that.

Agreed.

>>  const struct drm_edid *drm_edid_read(struct drm_connector *connector)
>>  {
>> +	const struct drm_edid *drm_edid = NULL;
>> +
>>  	if (drm_WARN_ON(connector->dev, !connector->ddc))
>>  		return NULL;
>>  
>> -	return drm_edid_read_ddc(connector, connector->ddc);
>> +	if (connector->acpi_edid_allowed)
>
> That should probably be called 'prefer_acpi_edid' or something
> since it's the first choice when the flag is set.
>
> But I'm not so sure there's any real benefit in having this
> flag at all. You anyway have to modify the driver to use this,
> so why not just have the driver do the call directly instead of
> adding this extra detour via the flag?

Heh, round and round we go [1].


BR,
Jani.

[1] https://lore.kernel.org/r/87sf23auxv.fsf@intel.com


-- 
Jani Nikula, Intel