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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJAp7OgtnTN3H+zSazK2Xeob6wxpf9Ws=tibAupzP1cF31G=Mw@mail.gmail.com>
Date:	Wed, 21 Jan 2015 17:53:40 -0800
From:	Bjorn Andersson <bjorn@...o.se>
To:	Olof Johansson <olof@...om.net>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	David Brown <davidb@...eaurora.org>,
	Kumar Gala <galak@...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 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.

Regards,
Bjorn
--
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/