linux-kernel - RE: [PATCH 0/2] Docs/EDID: Fixed and improved EDID documentation

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: <82DABEC7F9941D458E51BA62B2739EF437ADEC88@sun1049.dh.corp>
Date:   Thu, 15 Nov 2018 09:02:27 +0000
From:   Christoph Niedermaier <cniedermaier@...electronics.de>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
CC:     "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "C.Emde@...dl.org" <C.Emde@...dl.org>,
        Jonathan Corbet <corbet@....net>
Subject: RE: [PATCH 0/2] Docs/EDID: Fixed and improved EDID documentation

On Tue, 13 Nov 2018, Jani Nikula wrote:
> On Tue, 06 Nov 2018, Jonathan Corbet <corbet@....net> wrote:
>> On Mon, 5 Nov 2018 09:48:33 +0100
>> Christoph Niedermaier <cniedermaier@...electronics.de> wrote:
>>
>>> A problem was found when EDID data sets for displays other than the 
>>> provided samples were generated. The patch series has no effect on 
>>> the provided samples that still match the data used in 
>>> drivers/gpu/drm/drm_edid_load.c.
>>> The provided samples use small values for XOFFSET, XPULSE, YOFFSET 
>>> and YPULSE, where the error doesn't occur. This fix corrects the use 
>>> of that values in case of high values, because the most significant 
>>> bits were treated incorrectly.
>>> 
>>> The previous version made it necessary to first generate an EDID data 
>>> set without correct CRC and then to fix the CRC in a second step. 
>>> This patch series adds the CRC calculation to the makefile in such a 
>>> way that a correct EDID data set is generated in a single build step.
>>
>> This seems reasonable, I guess; I've applied both.  It seems to me, 
>> though, that this stuff is in the wrong place.  Perhaps we should go 
>> one step further and move it to tools/ ?
>
> And then the next step further would be to write a tool in a high level language to generate the data rather than assemble the binary. Such a tool would, of course, catch errors like the ones fixed by this patch.

It would be nice, but for now it works.
Speaking for me such a task has low priority,
because in my opinion this code is not often used and
it is more intended for documentation purpose.

Best regards,
Christoph