linux-kernel - Re: [Ksummit-2013-discuss] [ARM ATTEND] arch/arm SoC organization

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: <CAOesGMiq4M-8=CUsKf3bxBnxxiBQMEPc11K8pDePZnzHkv9QTA@mail.gmail.com>
Date:	Fri, 2 Aug 2013 22:24:42 -0700
From:	Olof Johansson <olof@...om.net>
To:	Christian Daudt <csd_b@...dt.org>
Cc:	Tony Lindgren <tony@...mide.com>,
	Jason Cooper <jason@...edaemon.net>,
	devicetree@...r.kernel.org,
	"ksummit-2013-discuss@...ts.linuxfoundation.org" 
	<ksummit-2013-discuss@...ts.linuxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>,
	Linux ARM Kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Ksummit-2013-discuss] [ARM ATTEND] arch/arm SoC organization

On Fri, Aug 2, 2013 at 4:06 PM, Christian Daudt <csd_b@...dt.org> wrote:
> On Fri, Aug 2, 2013 at 1:33 AM, Tony Lindgren <tony@...mide.com> wrote:
>> * Jason Cooper <jason@...edaemon.net> [130731 07:25]:
>>> So, I'd like to propose we discuss some lessons learned and maybe arrive
>>> at some best practices.  eg, should we just go with mach-$COMPANY/?  How
>>> best to handle config symbols for efficient building?  Deprecation path
>>> for legacy (unconverted) boards?
>>
>> A lot of that problem goes away by initializing everything as late
>> as possible, and making things to live under drivers.
> One category of items that we haven't found a good place for in this
> new multiplatform world is where does dt-driven non-driver code reside
> ? e.g. we have a secure monitor access function that only kicks in if
> the appropriate dt entry is available . It currently resides in
> mach-bcm/bcm_kona_smc.c as it seems like the only location for it at
> the moment, but that doesn't seem like the best place because (a)
> mach-bcm might end up littered with one-of cases like this and (b)
> anything in mach-bcm is not visible to arm64 SoCs, and some of those
> in the future will need to share with their arm32 cousins.

ARM is working on standardizing some of these interfaces through
things like PSCI. It should take care of _some_ of the SMC needs. I
know you're already shipping some of these platforms though and
firmware interfaces might be locked in to something that's not
PSCI-compatible. :(

>  But putting in drivers (e.g. drivers/smc) seems like the wrong thing
> to do also because this is not a driver.

I really don't think we need to migrate everything to drivers/*. At
some point the need of exorcising code out of arch/arm will reach a
plateu, and there's some code that just simply belongs in that sub
directory.

The sharing with arm64 is the obvious sticky point, since the base
directories aren't the same. Luckily not too many vendors have shipped
arm64 platforms, and nobody is shipping in volume yet, so there's a
little time to sort out some of this.

>  We have a couple of other smallish pieces of IP that just need a bit
> of generic init code to keep them happy, which we were discussing
> internally where to best land them. At present they are also headed to
> mach-bcm.

I think the 3.12 merge window will see the introduction of
drivers/platform/arm. It must not become a dumping ground for
board-file equivalent code though, so I am a little scared to
introduce it. Mostly it should contain whatever glue code isn't
possible or practical to describe with device tree (or ACPI) today,
and in particular for established consumer devices, i.e. for actual
product needs. Compare to what's in drivers/platform/x86 to get a feel
for what we're talking about.

>  Ultimately the question is 'what is allowed to reside in mach-<misc>
> ?' And by extension: 'is there a good home for everything else ?''

Right, and see above about some of my opinions on the matter. arm64
does complicate things quite a bit since it's no longer easy to share
code between the architectures.

Having a few concise examples of what code you're looking for a home
for could be useful for the discussion though. Would you mind
volunteering a few? :)

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