[Arm-netbook] upstreaming the fex for the eoma

[Luke Kenneth Casson Leighton]

On Mon, Dec 16, 2013 at 11:34 AM, Marco Martin <notmart at gmail.com> wrote:
> Hi all,
>
> I would like to upstream the script.fex file (or the files?) for the eoma68
> into https://github.com/linux-sunxi/sunxi-boards
>
> my fex at the moment is:
> https://github.com/notmart/sunxi-boards/blob/master/sys_config/a20/eoma68_a20.fex
>
> that seems to work correctly.
>
> however I'll forward some comments on it that were made on the linux-sunxi irc
> channel (oliv3r that i think he maintains the sunxi-boards repo):
>
> it has enabled several things that aren't available on the improv (wifi,
> touchscreen on i2c.so, enabled cameras) basically boils down to try to do a
> fex file that catches all the possible feature boards vs one fex file per
> feature board.
> Not knowing a lot about this in particular I can pretty much just refer what i
> was told and let you guys decide how we want the fex file, or the multiple fex
> files that would end up in that repository (at least i think it makes sense to
> put everything in that place)

 marco: there's some... shall we say... eeenteresting issues raised by
the nature of EOMA modular standards, in fact any on-demand
user-swappable modules (of which EOMA68 really seems to be the only
one)

 the bottom line is that, really, *no* fex file may be "upstreamed"
until there is infrastructure in place to deal with the dynamic
modular nature of EOMA/EOMA68.

 to catch "all possible feature boards" is flat-out impossible, and is
completely against the direction that's been planned all along.

 what's been planned is to use the EOMA68-compliance I2C EEPROM - the
decision was taken to store device-tree "snippets" - and for those
"snippets" to be stitched together along-side a "base" device-tree
file.  that "base" device-tree file *could* (and should) be
upstreamed. the "snippets" likewise, in the extremely likely event
that "feature boards" themselves are also upstreamed.  but combining
the two types (base and snippets) and hoping for the best is NOT on
the table for discussion.

 although it was considered, i am very, very reluctant to permit fex
files to become part of the EOMA68 standard.  i say that in
pre-emption of any suggestion to instead permit storage of fex-file
"snippets" in the EOMA68 compliance EEPROM, because once that decision
is made, then *all* present and future EOMA68 CPU Cards *must* be
capable of interpreting fex files, now and forever.

 the other option would be to gateway script.fex into device-tree.
however, the views of various contributors on the linux kernel mailing
list regarding script.fex has been made explicitly clear.  in one
instance by attempting to illegally mass-mail-bomb my email account by
making unauthorised use of 3rd party mailing list services to
subscribe my email address several thousand times.

 so the question becomes: which is more work - to convert all sunxi
code over to device-tree (in the hope that future CPU Cards will also
comply)?  or is it more work to add - and maintain (in a non-upstream
fashion) a script.fex'd array of linux kernels, of which the
EOMA68-A20 will be the only one that will be "easy" in the immediate
future, and where all other CPU Cards will need to be both
"script.fex'd" and then maintained *outside* of the linux kernel
infrastructure, non-upstream, pretty much forever?

... put [deliberately] like that, it's not really a choice... :)

i realise however that you need something to work with in the
short-term.  you are free to do that, but if you want to submit an
"upstream" fex file, you are free to call it whatever you wish as long
as it does not have the words "eoma" or "eoma68" in it.  i trust that
this is clear.

l.