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

Powered by blists - more mailing lists