[DEV] New kernel 2.6.38.6 in testing

[BinaryJay]

$this->bbcode_second_pass_quote('kmihelich', 'T')he v2 needs its own kernel init code, and I have a massive list of other things to do. If someone wants to write a patch, I'll integrate it into the kernel.

[kmihelich]

Chances are at least one of the other colors under /sys/class/leds will trigger the led. I think blue replaced green (correct for sheeva) which triggered orange for v2.

Everyone that owns a v2 has been effected since forever. There has never been kernel code that properly addressed the v2 leds. To be completely honest, every v2 has been using sheeva init code, and the fact that the v2 leds don't work when sheeva code gets changed does not constitute a bug. Someone took it upon themselves to correct what has been mainlined for sheeva to correctly address the leds present on those devices, and that's all it takes for someone else with respect to the v2. Simply, it has never been done.

[replabrobin]

For what it's worth, Sean Young (who has an eSata) tried to get the 3 LED patch into the latest kernel. However, it seems that ARM kernel development is stuck and only my two led patch made it in; of course that breaks eSata so Sean asked me to fix. By that time I was already testing the three LED version, but that also worked for him (when eSata mpp was fixed up) and that patch went here and in a slight variant (because of device naming) to the linux arm devs. From what I read it seems that the mach_board stuff is considered retro and deprecated so where to fix all these plugs is going to be problematic.

[kmihelich]

Looking at the continued development in the ARM architecture in the kernel, the way it is now seems to be the way it will be. There is a lot of mixed opinions about what should happen in the ARM tree, and Linus has been vocal to those developers to get their stuff together and work as a team.

Because of all the issues, I stay with mainline for our kernels.. there is too much fragmentation and lack of quality control in a lot of the side-project git repos. Marvell isn't exactly innovating in the Kirkwood family anymore, and the mainline code is likely to stay where its at unless you want to deal with the drawn out and headache-inducing process to get code accepted. But it can be done. For instance, GoFlex Net code was recently mainlined.

Since this distribution targets plug computers specifically (and now Cortex-A series platforms), I am all for having the community submit patches to be included in our kernel. Your Sheeva fix is the latest in a series of community patches we have applied. In github I have merged everything into one patch file, Arch Linux ARM.patch, which represents over 1000 lines of code to make things work better for everyone. If you need inspiration on how to create a whole new implementation for mach_kirkwood, look at the GoFlex Home setup in the patch. That's a wholly community-created patch for a specific device, and I have no problem patching it into our released kernels.

[replabrobin]

Just tried https://github.com/Arch Linux ARM/Arch Linux ARM, but am seein a 404 page

[kmihelich]

We've moved, part of the transition: https://github.com/archlinuxarm/pkgbuilds