[PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

[Olof Johansson]

On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim <kgene.kim at samsung.com> wrote:
> On 02/13/14 04:14, Arnd Bergmann wrote:
>>
>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote:
>>>
>>> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas at arm.com>
>>> wrote:
>>>>
>>>> On 12 Feb 2014, at 16:25, Kumar Gala<galak at codeaurora.org>  wrote:
>>>>>
>>>>> One reason to keep around ARCH_* is for drivers shared between arm and
>>>>> arm64 that depend on it.
>>>>
>>>>
>>>> We already converted some of them (those depending on ARCH_VEXPRESS) to
>>>> just depend on ARM64. Ideally, at some point I'd like to see them as
>>>> defaulting to modules but I don't think we are there yet (we had some
>>>> discussions at the last KS, I'm not sure anyone started looking into
>>>> this).
>>>
>>>
>>> I'm torn about this, I think for something like VEXPRESS it makes sense,
>>> however I think  its reasonable to still have an config symbol for a full
>>> SoC family or something of that nature.
>>
>>
>> I think for SBSA compliant systems, we should be able to live with a
>> generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms,
>> we may need something more specific.
>>
> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to
> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about
> compliant with SBSA Level1 and having some specific features?

(It's a little hard to answer since nobody can download the doc and
then talk about it.)

What kind of features are you expecting though? More IP
blocks/devices? Those are just kernel config options to enable,
ideally as modules.

x86 doesn't need config options for each generation of their platform,
and neither should ARM64. Sure, there might be drivers that don't make
sense to enable on some platforms, but that's what defconfigs (or
distro configs), and modules are for -- the modules won't load unless
the hardware is there.

As long as we're not talking about massive amounts of code that is
part of the base platform, separating out per version again doesn't
make sense -- just enable for SBSA and it'll support Level 1 through
whatever. If the kernel size becomes a concern we can revisit, but
let's not start out that way.


-Olof