[OpenWrt-Devel] ar71xx support in mainline kernel?

[Dave Taht]

On Tue, Dec 13, 2011 at 12:28 AM, Hartmut Knaack <knaack.h at gmx.de> wrote:

> Felix Fietkau schrieb:
> > On 2011-11-26 1:33 PM, Dave Taht wrote:
> >> I am curious as to if anyone was working on getting the ar71xx arch and
> >> drivers upstream?
> >>
> >> It appears that the ath79 arch was intended to be the same thing, but
> has
> >> nearly no users in the upstream kernel aside from two boards, and was
> last
> >> worked on back in april...
> >>
> >> the ar71xx patches in openwrt supports 43 boards at present and a
> >> great deal of additional (and possibly duplicated) functionality.
> >>
> >>
> http://nbd.name/gitweb.cgi?p=openwrt.git;a=tree;f=target/linux/ar71xx/files/arch/mips/ar71xx;h=878ba990e3b04c98e5e244011a82177e465f405a;hb=HEAD
> >>
> >> So I'm curious as to what were the show-stoppers aside from the name
> change
> >> and the huge backlog of boards and specialized devices?
> >>
> >> (I see that the usb drivers are different, and I have no idea if the
> ag71xx
> >>  ethernet driver is actually in there in some form under some name)
> >>
> >> (msg somewhat triggered by seeing the drivers/net directory getting
> >> re-organized in linux 3.2 and trying to hack in BQL on top of the
> >> existing patchset)
> > I think it does not make much sense to try to integrate the code from
> > our ar71xx into ath79 and pushing that upstream. The mips-machine way of
> > supporting different boards with one kernel is somewhat cumbersome, a
> > much better way to deal with it is adding device tree support and using
> > that. Proper device tree support is currently being worked on for the
> > lantiq target. Once that's functional, I'll look into adapting it to
> > ath79 as well.
> >
> > - Felix
> >
> Maybe we could distribute the work to some volunteers around here (you can
> count on me, and Dave also seems to be motivated).


I'm motivated, but I'm also tired, and taking a bit of vacation right now.
Merely figuring out what the right steps were to take this blob of code and
get it upstream over the next year would be good.

For example, I did take the time a few weeks ago to try to fold ar71xx, and
patches, into the 3.2 tree, moving around the various device drivers to
their new locations, adopting the 'Platform' idea, discovering two source
files were now duplicated, and more or less got the thing to build.

And then it changed out from under me. Merely shifting deck chairs around
on the titanic in this way isn't the right thing, I'm sure there are plenty
of bits of code in various subsystems that will need to be reviewed and
possibly change. Getting it done would require buy-in from lots of people,
and corporate support from atheros and/or the downstream vendors that base
products on it would help, too.

I did manage yesterday to backport BQL to 3.1.5, and ported the ar71xx
driver to it, but testing it is going to take energy I don't have right now
(next week, maybe), and there promises to be much activity in 3.2 and 3.3
that looks promising for beating bufferbloat that will be difficult to
backport and/or track. I am happy that red, after being broken for 3 years,
appears to be fixed in 3.1.5. More cool and useful stuff is on it's way.

I've had a peek into the device tree topic and came up with
> http://devicetree.org/Device_Tree_Usage and http://devicetree.org/Linuxas some kind of reference manual. So, what needs to be done? I'd say:
>    - change device drivers to query their properties from device tree
> instead of some platform_data structs (do we need those structs any longer?)
>    - convert the mach-*.c files to dtb
>    - ... (insert whatever I missed)
>

Heh. I read the same doc, and definately feel it's something one has to do
at least once to understand how to do it.

And that said, there are significant components of ar71xx, drivers, etc,
that would be need to be reviewed by those
subsystem maintainers.

I'm not quite sure where to start, so it would be best if you could lay out
> a schedule. And it would probably help a lot to see a reference device
> driver, to know how to implement it properly. So, what do you think?
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat-devel/attachments/20111213/8530f13f/attachment-0002.html>