linux-kernel - Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

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: <1370468873.18839.22.camel@localhost>
Date:	Wed, 05 Jun 2013 23:47:53 +0200
From:	Henrik Nordström <henrik@...riknordstrom.net>
To:	Linux on small ARM machines <arm-netbook@...ts.phcomp.co.uk>
Cc:	"jonsmirl@...il.com" <jonsmirl@...il.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	debian-arm@...ts.debian.org,
	ARM Linux Mailing List <linux-arm-kernel@...ts.infradead.org>,
	debian-kernel@...ts.debian.org
Subject: Re: [Arm-netbook] getting allwinner SoC support upstream (was Re:
 Uploading linux (3.9.4-1))

ons 2013-06-05 klockan 22:15 +0100 skrev Luke Kenneth Casson Leighton:

> what we do not want to happen is that they see upstream patches being
> submitted, they merge them into their internal tree (which to date has
> had zero upstream changes: they're currently only just getting round
> to doing 3.4 as we speak), and they *completely* ignore *absolutely
> everything* that's being done by the community, duplicating yet
> another set of device drivers (named drivers/*/sun8i_* and so on).

Well, that will obviously happen one or two more rounds, a bit depending
on which kernel releases Android will use. But I hope the Allwinner
kernel team will rethink when they hit more current kernels.

>  this proposal is a start: however what you have to bear in mind is
> that you now have to convince a very busy company that it is in their
> best interests to disrupt their schedule, to drop their existing
> working practices, to tell all their customers "please stop using the
> existing tools and please use these ones instead".

Why?

>  you also need to convince the creators of the proprietary
> firmware-flashing tools "livesuite" and "phoenix" to *also* convert
> their tools over to the new proposed idea.

Why?

>  can you provide such a supporting argument which would convince
> allwinner to accept the modifications to their working practices that
> you propose?

It does not really need to be such big modifications to their working
practices. Their configuration working practices is all built around the
fex file, and the new practices can be

0. Assuming kernel drivers gets ported over to using device tree.

1. Do configuration as you have always done in the .fex

2. Modify the build script to build a device tree from the fex +
template, in addition to script.bin.

3. Tell u-boot to load the device tree for the kernel.

That's it really.

licesuit do not modify script.bin. script.bin is compiled from the .fex
at image creation time. A couple more lines in the build script (and a
suitable translation tool) and there is also a device tree built and
installed and you get a nice and smoot transition.

> > Device tree on ARM's goal is to achieve a single kernel across vendors, not
> > just a single kernel for a single vendor.
> 
>  you'll be aware that i've mentioned a number of times and have
> discussed at some length why this is a goal that is completely
> impossible to achieve [*1].  sadly.

Here I disagree. It is possible. Not across all vendors but a
significant share.

Regards
enrik

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