linux-kernel - Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

Open Source and information security mailing list archives

Date:   Wed, 03 Jan 2018 09:14:47 +0200
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Chris Wilson <chris@...is-wilson.co.uk>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Stefan Brüns <stefan.bruens@...h-aachen.de>
Cc:     David Airlie <airlied@...ux.ie>, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

On Tue, 02 Jan 2018, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> Quoting Rodrigo Vivi (2018-01-02 19:12:18)
>> On Sun, Dec 31, 2017 at 10:34:54PM +0000, Stefan Brüns wrote:
>> > +     edid = drm_get_edid(connector, i2c);
>> > +
>> > +     if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
>> > +             DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO bit-banging\n");
>> > +             intel_gmbus_force_bit(i2c, true);
>> > +             edid = drm_get_edid(connector, i2c);
>> > +             intel_gmbus_force_bit(i2c, false);
>> > +     }
>> 
>> Approach seems fine for this case.
>> I just wonder what would be the risks of forcing this bit and edid read when nothing is present on the other end?
>
> Should be no more risky than using GMBUS as the bit-banging is the
> underlying HW protocol; it should just be adding an extra delay to
> the disconnected probe. Offset against the chance that it fixes
> detection of borderline devices.
>
> I would say that given the explanation above, the question is why not
> apply it universally? (Bonus points for including the explanation as
> comments.)

I'm wondering, is gmbus too fast for the adapters, does gmbus generally
have different timing for the ack/nak as described in the commit message
than bit banging, or are the adapters just plain buggy? Do we have any
control over gmbus timings (don't have the time to peruse the bpsec just
now)?

BR,
Jani.

> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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