<br><br><div class="gmail_quote">On Tue, Dec 13, 2011 at 12:28 AM, Hartmut Knaack <span dir="ltr"><<a href="mailto:knaack.h@gmx.de">knaack.h@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Felix Fietkau schrieb:<br>
<div><div class="h5">> On 2011-11-26 1:33 PM, Dave Taht wrote:<br>
>> I am curious as to if anyone was working on getting the ar71xx arch and<br>
>> drivers upstream?<br>
>><br>
>> It appears that the ath79 arch was intended to be the same thing, but has<br>
>> nearly no users in the upstream kernel aside from two boards, and was last<br>
>> worked on back in april...<br>
>><br>
>> the ar71xx patches in openwrt supports 43 boards at present and a<br>
>> great deal of additional (and possibly duplicated) functionality.<br>
>><br>
>> <a href="http://nbd.name/gitweb.cgi?p=openwrt.git;a=tree;f=target/linux/ar71xx/files/arch/mips/ar71xx;h=878ba990e3b04c98e5e244011a82177e465f405a;hb=HEAD" target="_blank">http://nbd.name/gitweb.cgi?p=openwrt.git;a=tree;f=target/linux/ar71xx/files/arch/mips/ar71xx;h=878ba990e3b04c98e5e244011a82177e465f405a;hb=HEAD</a><br>

>><br>
>> So I'm curious as to what were the show-stoppers aside from the name change<br>
>> and the huge backlog of boards and specialized devices?<br>
>><br>
>> (I see that the usb drivers are different, and I have no idea if the ag71xx<br>
>>  ethernet driver is actually in there in some form under some name)<br>
>><br>
>> (msg somewhat triggered by seeing the drivers/net directory getting<br>
>> re-organized in linux 3.2 and trying to hack in BQL on top of the<br>
>> existing patchset)<br>
> 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<br>
> supporting different boards with one kernel is somewhat cumbersome, a<br>
> much better way to deal with it is adding device tree support and using<br>
> 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<br>
> ath79 as well.<br>
><br>
> - Felix<br>
><br>
</div></div>Maybe we could distribute the work to some volunteers around here (you can count on me, and Dave also seems to be motivated). </blockquote><div><br>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.<br>
<br>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.<br>
 <br>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.<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've had a peek into the device tree topic and came up with <a href="http://devicetree.org/Device_Tree_Usage" target="_blank">http://devicetree.org/Device_Tree_Usage</a> and <a href="http://devicetree.org/Linux" target="_blank">http://devicetree.org/Linux</a> as some kind of reference manual. So, what needs to be done? I'd say:<br>

    - change device drivers to query their properties from device tree instead of some platform_data structs (do we need those structs any longer?)<br>
    - convert the mach-*.c files to dtb<br>
    - ... (insert whatever I missed)<br></blockquote><div><br>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.<br><br>And that said, there are significant components of ar71xx, drivers, etc, that would be need to be reviewed by those<br>
subsystem maintainers.  <br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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?<br>

_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel" target="_blank">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br>FR Tel: 0638645374<br><a href="http://www.bufferbloat.net" target="_blank">http://www.bufferbloat.net</a><br>