From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 45EA2200DCD for ; Tue, 13 Dec 2011 04:32:00 -0800 (PST) Received: by ghrr18 with SMTP id r18so439275ghr.16 for ; Tue, 13 Dec 2011 04:31:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p64oq2Qx/VL/s4w8uFUHe6ye2tOGoHwYM7Es67e+0eo=; b=AFixR6U+i3UckgrdWNZWJXEunkS6NfpkWUSjtfTSBZpdCK/iyodon8T2KNZfithRI5 IGRe3EIWXBD4gbZZ8go1TDlWvBcrzQPmQTKbU28mjhdunAOo05NmmjEpbsRQ4DXim+3q s0C4CIRp8PFBl/COdswgu0vyIYaSfSlUDS8mw= MIME-Version: 1.0 Received: by 10.50.161.162 with SMTP id xt2mr18898998igb.72.1323779518370; Tue, 13 Dec 2011 04:31:58 -0800 (PST) Received: by 10.231.204.83 with HTTP; Tue, 13 Dec 2011 04:31:58 -0800 (PST) In-Reply-To: <4EE68E33.90909@gmx.de> References: <4ED1A557.2090404@openwrt.org> <4EE68E33.90909@gmx.de> Date: Tue, 13 Dec 2011 13:31:58 +0100 Message-ID: Subject: Re: [OpenWrt-Devel] ar71xx support in mainline kernel? From: Dave Taht To: OpenWrt Development List Content-Type: multipart/alternative; boundary=14dae9340bd3f4131104b3f86f51 Cc: bloat-devel X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 12:32:00 -0000 --14dae9340bd3f4131104b3f86f51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Dec 13, 2011 at 12:28 AM, Hartmut Knaack 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 an= d > >> 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=3Dopenwrt.git;a=3Dtree;f=3Dtarget/linux/ar71= xx/files/arch/mips/ar71xx;h=3D878ba990e3b04c98e5e244011a82177e465f405a;hb= =3DHEAD > >> > >> 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 o= f > > 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 ca= n > 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 longe= r?) > - 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@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net --14dae9340bd3f4131104b3f86f51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 13, 2011 at 12:28 AM, Hartmu= t Knaack <knaack.h@= 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 arc= h 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<= br> >> great deal of additional (and possibly duplicated) functionality.<= br> >>
>> http://nbd.name/gitweb.cgi?p= =3Dopenwrt.git;a=3Dtree;f=3Dtarget/linux/ar71xx/files/arch/mips/ar71xx;h=3D= 878ba990e3b04c98e5e244011a82177e465f405a;hb=3DHEAD
>>
>> So I'm curious as to what were the show-stoppers aside from th= e 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 t= he ag71xx
>> =A0ethernet driver is actually in there in some form under some na= me)
>>
>> (msg somewhat triggered by seeing the drivers/net directory gettin= g
>> re-organized in linux 3.2 and trying to hack in BQL on top of the<= br> >> existing patchset)
> I think it does not make much sense to try to integrate the code from<= br> > our ar71xx into ath79 and pushing that upstream. The mips-machine way = of
> supporting different boards with one kernel is somewhat cumbersome, a<= br> > much better way to deal with it is adding device tree support and usin= g
> that. Proper device tree support is currently being worked on for the<= br> > 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 he= re (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 va= cation right now. Merely figuring out what the right steps were to take thi= s 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 t= o their new locations, adopting the 'Platform' idea, discovering tw= o source files were now duplicated, and more or less got the thing to build= .
=A0
And then it changed out from under me. Merely shifting deck chairs a= round on the titanic in this way isn't the right thing, I'm sure th= ere are plenty of bits of code in various subsystems that will need to be r= eviewed and possibly change. Getting it done would require buy-in from lots= of people, and corporate support from atheros and/or the downstream vendor= s 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 wa= y.

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

Heh. I re= ad the same doc, and definately feel it's something one has to do at le= ast once to understand how to do it.

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

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@lists.open= wrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--
Dave T=E4ht
SKYPE: d= avetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
--14dae9340bd3f4131104b3f86f51--