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]

Date:	Sun, 25 Jan 2015 11:11:28 -0500
From:	Sean Paul <seanpaul@...omium.org>
To:	Rob Clark <robdclark@...il.com>
Cc:	Olof Johansson <olof@...om.net>, 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>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	gustavo@...ovan.org
Subject: Re: [GIT PULL] qcom SoC changes for v3.20

On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark <robdclark@...il.com> wrote:
> 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.
>

This isn't a concern on exynos, fwiw.

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

Shared helpers would be useful to have once there's another hdcp
implementation upstream. I haven't looked at our downstream hdcp
implementation in a while, so it's difficult to say how much could be
factored out. It's on my TODO stack... somewhere.

Sean


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