linux-kernel - qcom firmware / scm interface (was 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: <9F29C4A8-BD35-4E87-9765-56597A38F134@codeaurora.org>
Date:	Wed, 4 Feb 2015 14:45:31 -0600
From:	Kumar Gala <galak@...eaurora.org>
To:	Olof Johansson <olof@...om.net>
Cc:	"arm@...nel.org" <arm@...nel.org>,
	Kevin Hilman <khilman@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Lina Iyer <lina.iyer@...aro.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	Olav Haugan <ohaugan@...eaurora.org>,
	Vikram Mulukutla <markivx@...eaurora.org>
Subject: qcom firmware / scm interface (was Re: [GIT PULL] qcom SoC changes for v3.20)

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

So I’ve been looking at the ARM firmware_ops and I’m not sure it makes much sense to try and contort either the QCOM SCM interface to match or the other way around.  The firmware_ops don’t really match what the qcom scm interface exposes and trying to make it would just seem to make the firmware_ops to QCOM specific to be of any value.

I’ll look at cleaning up the SCM code and moving it to drivers/firmware instead of drivers/soc/qcom if that is more desirable.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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