arm: Split GENERIC into vendor files

[manu]

Summary

While this doesn't give us an optimum flexibility this allow a user to build a kernel for a specific SoC family just by commenting one line in the GENERIC kernel.

[imp]

I like this.

Have you consider the testing requirements for making sure that one can write a config file with these w/o them breaking over time?

[manu]

In D13624#284876, @imp wrote:

I like this.

Have you consider the testing requirements for making sure that one can write a config file with these w/o them breaking over time?

The only "bad" thing that could happen is that someone add a "device blah" in multiple vendor file and so config will warn.
If every change to the GENERIC file is to add a generic driver and every change to a vendor file is to add a vendor driver everything is fine (tm).
I have other plan for config to allow a much better conf files but for now it's still in my brain.

[imp]

In D13624#284888, @manu wrote:

In D13624#284876, @imp wrote:

I like this.

Have you consider the testing requirements for making sure that one can write a config file with these w/o them breaking over time?

The only "bad" thing that could happen is that someone add a "device blah" in multiple vendor file and so config will warn.
If every change to the GENERIC file is to add a generic driver and every change to a vendor file is to add a vendor driver everything is fine (tm).
I have other plan for config to allow a much better conf files but for now it's still in my brain.

So you don't plan to write a script to generate a GENERIC that has all the 'other' std.foo lines commented out for each std.foo type to make sure that compiles?

[manu]

In D13624#284912, @imp wrote:

In D13624#284888, @manu wrote:

In D13624#284876, @imp wrote:

I like this.

Have you consider the testing requirements for making sure that one can write a config file with these w/o them breaking over time?

The only "bad" thing that could happen is that someone add a "device blah" in multiple vendor file and so config will warn.
If every change to the GENERIC file is to add a generic driver and every change to a vendor file is to add a vendor driver everything is fine (tm).
I have other plan for config to allow a much better conf files but for now it's still in my brain.

So you don't plan to write a script to generate a GENERIC that has all the 'other' std.foo lines commented out for each std.foo type to make sure that compiles?

What I plan is more or less something like that :

add two new directive for config :

• deviceneed blah (which include device blah if it's not already present)
• devicerequire blah (which fail if device blah isn't present already)

And add all devices in std.vendor that the SoC needs.

Move the rest of the require stuff from GENERIC to std.armv7.

This way one can easily create an ALLWINNER kernel config that contain three lines :
IDENT ALLWINNER
include std.armv7
include std.allwinner

[manu]

outdated