linux-kernel - Re: [GIT PULL] qcom SoC changes for v3.20

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: <CAF6AEGuLu+KYwBX59T4-SThPDJCYwKDU6_qWf7d80Dae6FAmbQ@mail.gmail.com>
Date:	Sun, 25 Jan 2015 11:03:47 -0500
From:	Rob Clark <robdclark@...il.com>
To:	Olof Johansson <olof@...om.net>
Cc:	Kumar Gala <galak@...eaurora.org>,
	Olav Haugan <ohaugan@...eaurora.org>,
	Kevin Hilman <khilman@...aro.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	Arnd Bergmann <arnd@...db.de>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	Vikram Mulukutla <markivx@...eaurora.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arm@...nel.org" <arm@...nel.org>,
	Lina Iyer <lina.iyer@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Thierry Reding <treding@...dia.com>,
	daeinki <inki.dae@...sung.com>,
	Stéphane Marchesin <marcheu@...omium.org>,
	Sean Paul <seanpaul@...omium.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [GIT PULL] qcom SoC changes for v3.20

On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson <olof@...om.net> wrote:
>>> I'd be OK with merging this, send a request and tag. Would that let
>>> the DRM folks make progress too?
>>
>> Will do, I don’t think it will address the DRM folks needs as they need access to make firmware calls from the DRM driver.
>>
>>> If you need a common place for this, drivers/firmware seems like a
>>> better home than drivers/soc.
>>
>> Agreed, what’s you take than on moving to use firmware_ops as defined in arch/arm and extended it or just leaving this as a qcom specific firmware interface?
>
> Are there any other SoCs out there with similar requirements on
> firmware interfaces? I think most of them so far have been fairly
> simple compared to the complexity of the qualcomm firmware.

I think the question is probably "how do downstream HDCP
implementations work on these other SoCs"..   so far, I think qcom is
the first to try to upstream HDCP support, but I know there have to be
at least a few downstream implementations lurking out there.

And I'm sure as some others come out of the woodwork there will be
some things to refactor.. like possibly shared helpers for
implementing the state machine, etc.

BR,
-R

> Would it make sense to use firmware_ops for the common pieces and have
> direct smc calls for the rest? I'm not sure that would buy us all that
> much. Hm.
>
> Well, at least it's an internal implementation detail. If we move it
> now and find a better way to do it down the road it can be refactored.
--
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/