Support for RTL838x based managed switches

Well I have 160 patches, which are not so easy to categorize as you do; they are a bit 'all over the place' :stuck_out_tongue:

got that in my branch

I saw those patches, but best to drop those. The upstream code is a mess, and MACH_ hasn't beent he 'common' prefix for a while afaik, and REALTEK_RTL is ... well just a bit stupid. RTL is the abbreviation for realtek, so now we have realtek-realtek. Also, I think MACH is more for 'pre-dts' times?

I think that's not a good idea, While some files might be 'identical' between the two kernels, it makes things very hard to manage. I understand that currently this is just about documentation, but any kernel version related change, could break this. So yes, this introduces code duplication, but that's okay if it means we can keep things more manageable. What if our next experimental kernel is 6.0 and half those files are not relevant anymore? It also makes it hard to figure out which files to use.

That sounds like a good idea, I did something along the lines as as well, actually I made it so we have a single kernel for all out targets (where applicable) https://gitlab.com/olliver/openwrt/openwrt/-/commit/201252b974af8f40bce7d97afbe676d73d3b7037.

This is the most interesting patch to me, as I hope it fixes my current RCU stalls.
It did! I think there's still a bug with relation to the timers, but with the SMP support, this bug gets tucked away as the second core can handle the timeouts.

I'll try to destil the generic MIPS patches and put them in my tree isolated from the rest, as there's some other good stuff in there too like:

for example.

Btw, Your commit (https://github.com/musashino-build/openwrt/commit/d89d378d410de6e1a19f6429c0a7e5c8ca873785) doesn't say, but why did you move the load address? What's the purpose/point?

1 Like