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

Open Source and information security mailing list archives

Message-ID: <877f5ciilg.fsf@intel.com>
Date:   Mon, 30 Jan 2017 19:05:31 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Peter Senna Tschudin <peter.senna@...labora.com>,
        Archit Taneja <architt@...eaurora.org>
Cc:     mark.rutland@....com, daniel.vetter@...ll.ch,
        peter.senna@...il.com, dri-devel@...ts.freedesktop.org,
        tiwai@...e.com, ykk@...k-chips.com, jslaby@...e.cz,
        martyn.welch@...labora.co.uk, mchehab@....samsung.com,
        linux@...linux.org.uk, javier@...hile0.org, treding@...dia.com,
        linux@...ck-us.net, martin.donnelly@...com,
        devicetree@...r.kernel.org, pawel.moll@....com,
        ijc+devicetree@...lion.org.uk,
        Fabio Estevam <fabio.estevam@....com>,
        rmk+kernel@...linux.org.uk, robh+dt@...nel.org,
        linux-arm-kernel@...ts.infradead.org, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, kernel@...gutronix.de,
        galak@...eaurora.org, enric.balletbo@...labora.com,
        akpm@...ux-foundation.org, shawnguo@...nel.org, davem@...emloft.net
Subject: Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge

On Sat, 28 Jan 2017, Peter Senna Tschudin <peter.senna@...labora.com> wrote:
> 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.

Hrmh, I'm planning on moving the edid override and firmware edid
mechanisms at the drm_do_get_edid() level to be able to truly and
transparently use a different edid. Currently, they're only used for
modes, really, and lead to some info retrieved from overrides, some from
the real edid. This kind of hacks will bypass the override/firmware edid
mechanisms then too. :(

BR,
Jani.

>
> [...]
>
> I fixed all your other suggestions. Thank you!
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

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