linux-kernel - Re: [PATCH v3 2/4] drm/edid: Add a function to check monitor string

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: <871q8p3xmp.fsf@intel.com>
Date: Tue, 05 Mar 2024 10:12:46 +0200
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Hsin-Yi Wang <hsinyi@...omium.org>
Cc: Douglas Anderson <dianders@...omium.org>, Neil Armstrong
 <neil.armstrong@...aro.org>, Jessica Zhang <quic_jesszhan@...cinc.com>,
 Sam Ravnborg <sam@...nborg.org>, Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
 Daniel Vetter <daniel@...ll.ch>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, Dmitry Baryshkov
 <dmitry.baryshkov@...aro.org>
Subject: Re: [PATCH v3 2/4] drm/edid: Add a function to check monitor string

On Mon, 04 Mar 2024, Hsin-Yi Wang <hsinyi@...omium.org> wrote:
> On Mon, Mar 4, 2024 at 4:09 PM Jani Nikula <jani.nikula@...ux.intel.com> wrote:
>>
>> On Mon, 04 Mar 2024, Hsin-Yi Wang <hsinyi@...omium.org> wrote:
>> > To clarify:
>> > struct drm_edid currently is only internal to drm_edid.c. So with
>> > change we will have to move it to the header drm_edid.h
>>
>> Absolutely not, struct drm_edid must remain an opaque type. The point is
>> that you ask drm_edid.c if there's a match or not, and the panel code
>> does not need to care what's inside struct drm_edid.
>>
>
> Sorry I might be misunderstanding about the requests here:
>
> If drm_edid should remain opaque, then struct drm_edid remains opaque,
> drm_edid_match() should take struct edid *edid as a parameter? just as
> other exposed functions in drm_edid.

No, it should take struct drm_edid *.

> If panel edp doesn't hold drm_edid returned from
> drm_edid_read_base_block(), what should it use to iterate the
> edp_panels array?

Panel edp can hold a *pointer* to struct drm_edid * without knowing the
full type. This is one of the points of struct drm_edid. Focus more of
the EDID parsing within drm_edid.c instead of having everyone parse it
to varying degrees of correctness.

>
> for (panel = edp_panels; panel->panel_id; panel++)
>     if(drm_edid_match(drm_edid, panel->ident))
>         ...
>

BR,
Jani.

-- 
Jani Nikula, Intel