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] [day] [month] [year] [list]

Message-ID: <CAMuHMdV1XYpu3JeP3W-dZpO8kmN75XckuPRnw2zLW-ZqD4634g@mail.gmail.com>
Date: Wed, 17 Apr 2024 16:18:10 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Mario Limonciello <mario.limonciello@....com>
Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>, 
	Daniel Vetter <daniel@...ll.ch>, Jani Nikula <jani.nikula@...ux.intel.com>, 
	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

Hi Mario,

On Thu, Feb 15, 2024 at 8:04 PM Mario Limonciello
<mario.limonciello@....com> wrote:
> On 2/15/2024 12:47, Ville Syrjälä wrote:
> > On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> >> On 2/14/2024 17:13, Ville Syrjälä wrote:
> >>> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >>>> --- a/include/drm/drm_connector.h
> >>>> +++ b/include/drm/drm_connector.h
> >>>> @@ -1886,6 +1886,12 @@ struct drm_connector {
> >>>>
> >>>>            /** @hdr_sink_metadata: HDR Metadata Information read from sink */
> >>>>            struct hdr_sink_metadata hdr_sink_metadata;
> >>>> +
> >>>> +  /**
> >>>> +   * @acpi_edid_allowed: Get the EDID from the BIOS, if available.
> >>>> +   * This is only applicable to eDP and LVDS displays.
> >>>> +   */
> >>>> +  bool acpi_edid_allowed;
> >>>
> >>> Aren't there other bools/small stuff in there for tighter packing?
> >>
> >> Does the compiler automatically do the packing if you put bools nearby
> >> in a struct?  If so; TIL.
> >
> > Yes. Well, depends on the types and their alignment requirements
> > of course, and/or whether you specified __packed or not.
> >
> > You can use 'pahole' to find the holes in structures.
>
> Thanks!  I don't see a __packed attribute on struct drm_connector, but
> I'll put it near by other bools in case that changes in the future.

FTR, don't add __packed unless you have a very good reason to do so.
With __packed, the compiler will emit multiple byte-accesses to
access multi-byte integrals on platforms that do not support unaligned
memory access.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68korg

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds