linux-kernel - Re: [PATCH 8/8] msm: scm: Move the scm driver to drivers/soc/qcom

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, 22 Jan 2015 10:49:56 -0600
From:	Kumar Gala <galak@...eaurora.org>
To:	Olof Johansson <olof@...om.net>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	Bjorn Andersson <bjorn@...o.se>,
	David Brown <davidb@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Lina Iyer <lina.iyer@...aro.org>
Subject: Re: [PATCH 8/8] msm: scm: Move the scm driver to drivers/soc/qcom


On Jan 21, 2015, at 7:53 PM, Bjorn Andersson <bjorn@...o.se> wrote:

> On Wed, Jan 21, 2015 at 5:13 PM, Olof Johansson <olof@...om.net> wrote:
> [..]
>> On Mon, Aug 4, 2014 at 6:31 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
>>> Architectural changes in the ARM Linux kernel tree mandate
>>> the eventual removal of the mach-* directories. Move the
>>> scm driver to drivers/soc/qcom and the scm header to
>>> include/soc/qcom to support that removal.
>> 
>> The idea is not blindly move one dumping ground to a new place.
>> 
>> I see only two exported functions from scm.c:
>> 
>> scm_get_version: This is not used anywhere in the kernel and can just be removed
>> scm_call: This is used by scm-boot, and would be better to translate
>> over to firmware_ops in the first place.
>> 
> 
> Hi Olof,
> 
> I started this a while ago, as it felt like the right thing to do <tm>.
> 
> The problem with this approach is that e.g. firmware loading is
> partially handled through this interface. So implementing a remoteproc
> driver for wifi etc required me to add 6 new ops to the struct,
> loading the modem looks like it requires one more. HDMI requires one.
> 
> Looking at the downstream branch there's a bunch more (20+), so we
> would explode the firmware_ops struct with Qualcomm "specific" ops.
> This is not necessarily a bad idea, but needs to be considered before
> we jump the gun.
> 
> 
> I haven't looked at the arm64 stuff in detail, but it looks to be
> shared between the two platforms, so either way it seems like the
> right approach to have this moved out to drivers/soc/qcom.

As Bjorn says the scm interface ends up having a number of qcom specific calls that I don’t think the firmware ops should be implementing.  I don’t see any value in adding qcom specific function pointers to the ops struct just to create another level of indirection.

I’m fine with adding a firmware_ops implementation that uses scm for those things that firmware_ops has today.  However, I’m not clear on what the view of extending firmware_ops to arm64 is.  If we do this do we move the firmware_ops code into drivers/soc ?

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