linux-kernel - Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

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: <20170128141646.GA21291@collabora.com>
Date:   Sat, 28 Jan 2017 15:16:46 +0100
From:   Peter Senna Tschudin <peter.senna@...labora.com>
To:     Archit Taneja <architt@...eaurora.org>
Cc:     airlied@...ux.ie, akpm@...ux-foundation.org,
        daniel.vetter@...ll.ch, davem@...emloft.net,
        devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        enric.balletbo@...labora.com, eballetbo@...il.com,
        galak@...eaurora.org, gregkh@...uxfoundation.org, heiko@...ech.de,
        ijc+devicetree@...lion.org.uk, javier@...hile0.org, jslaby@...e.cz,
        kernel@...gutronix.de, linux-arm-kernel@...ts.infradead.org,
        linux@...linux.org.uk, linux-kernel@...r.kernel.org,
        linux@...ck-us.net, mark.rutland@....com, martin.donnelly@...com,
        martyn.welch@...labora.co.uk, mchehab@....samsung.com,
        pawel.moll@....com, peter.senna@...il.com, p.zabel@...gutronix.de,
        thierry.reding@...il.com, rmk+kernel@...linux.org.uk,
        robh+dt@...nel.org, shawnguo@...nel.org, tiwai@...e.com,
        treding@...dia.com, ykk@...k-chips.com,
        Rob Herring <robh@...nel.org>,
        Fabio Estevam <fabio.estevam@....com>
Subject: Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++
 Bridge

On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
Hi Archit,

Thank you for the comments!

[...]
> > +	total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
> > +	if (total_size > EDID_LENGTH) {
> > +		kfree(block);
> > +		block = kmalloc(total_size, GFP_KERNEL);
> > +		if (!block)
> > +			return NULL;
> > +
> > +		/* Yes, read the entire buffer, and do not skip the first
> > +		 * EDID_LENGTH bytes.
> > +		 */
> 
> Is this the reason why you aren't using drm_do_get_edid()?

Yes, for some hw specific reason, it is necessary to read the entire
EDID buffer starting from 0, not block by block.

[...]

I fixed all your other suggestions. Thank you!