linux-kernel - Re: [PATCH] drm: bridge/dw_hdmi: Filter modes

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]

Date:	Thu, 18 Jun 2015 09:10:40 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Philipp Zabel <p.zabel@...gutronix.de>,
	Thierry Reding <treding@...dia.com>,
	Heiko Stuebner <heiko@...ech.de>,
	David Airlie <airlied@...ux.ie>,
	Andy Yan <andy.yan@...k-chips.com>,
	Yakir Yang <ykk@...k-chips.com>,
	Fabio Estevam <fabio.estevam@...escale.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

Russell,

On Thu, Jun 18, 2015 at 8:55 AM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
>> Perhaps you can try <https://patchwork.kernel.org/patch/5906771/>
>
> Something like that needs to be done, but let's get rid of the mdvi
> thing in struct hdmi_vmode - it doesn't belong there, it isn't part
> of the currently set video mode, but becomes a property of the
> connected sink.
>
> I'd also prefer it to be called "is_dvi_sink", especially as its
> function is changing from "is it a CEA mode" to "is the attached
> device a DVI sink".
>
> Even better would be to call it "is_hdmi_sink" to maintain positive
> logic with single-negation where required, rather than double-
> negation in places.

Yakir: sounds like you now have some feedback on your patch now.
Perhaps you can spin it with Russell's feedback?

When you send it next, please make sure you include Russell in the
"To" line.  Based at looking at who committed things to dw_hdmi in the
past, I've been sending my patches "To":
    Philipp Zabel
    Russell King
    Thierry Reding

...so perhaps that would be good for you to do, too?

>> I am nowhere near an HDMI expert.  If you have a better suggestion
>> then I'm more than happy for you to post it and drop my patch.  In my
>> non-expert opinion, it would seem awfully strange for an AV receiver
>> to modify the EDID though unless it was actively interpreting the
>> signal and generating a whole new signal on the other end.  In any
>> case, perhaps you can find such a device and that will give insight to
>> how we should deal with it.  Until such a device is found, it seems
>> fruitless to speculate.
>
> Neither am I, but I have had the ability to do some testing with AV
> receivers in the path of a HDMI device, and I've seen how they behave.
> (I made copious notes on this, which I intend to publish when I have
> a round tuit.)  Unfortunately, I have no DVI devices to test with,
> and DVI devices are a dying breed - most monitors today come with
> HDMI sockets instead.

Ah, OK.  Have you seen any that specifically confuse the DVI vs. HDMI bits?

I still have copious DVI devices around, personally.  I could have
sworn that supporting "older hardware" was actually pretty important
in Linux.  ...and I can still buy plenty of DVI devices out there.


> That's a shame... I'm not inclined to Ack it as-is - and I'd also like
> to see Yakir's patch reworked as I mentioned above.

Perhaps when Yakir spins his series he can include a patch like mine
in it.  It doesn't make sense for me to re-spin it until his is
resolved.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/