On Sat, May 4, 2019 at 4:27 PM Greg Ungerer <gerg@xxxxxxxxxx> wrote: > On 4/5/19 3:06 am, Guenter Roeck wrote: > > On Fri, May 03, 2019 at 08:16:05AM +0100, Linus Walleij wrote: > >> On Fri, May 3, 2019 at 8:02 AM Greg Ungerer <gerg@xxxxxxxxxxx> wrote: > >>> Ultimately though I am left wondering if the ks8695 support in the > >>> kernel is useful to anyone the way it is at the moment. With a minimal > >>> kernel configuration I can boot up to a shell - but the system is > >>> really unreliable if you try to interactively use it. I don't think > >>> it is the hardware - it seems to run reliably with the old code > >>> it has running from flash on it. I am only testing the new kernel, > >>> running with the existing user space root filesystem on it (which > >>> dates from 2004 :-) > >> > >> Personally I think it is a bad sign that this subarch and boards do > >> not have active OpenWrt support, they are routers after all (right?) > >> and any active use of networking equipment should use a recent > >> userspace as well, given all the security bugs that popped up over > >> the years. Looking around on the internet, I found that Micrel at some point had their own openwrt fork for ks8695, but I can't find a copy any more, as the micrel.com domain is no longer used after the acquisition by Microchip. https://wikidevi.com/wiki/Micrel has a list of devices based on ks8695, and it seems that most of these are rather memory limited, which is a problem for recent openwrt builds. Only two of the 17 listed devices have the absolute minimum of 4MB flash and 32MB RAM for openwrt, two more have 8/32 and one or two have 4/64, but all these configurations are too limited for the web U/I now. > >> With IXP4xx, Gemini and EP93xx we have found active users and > >> companies selling the chips and reference designs and even > >> recommending it for new products (!) at times. If this is not the > >> case with KS8695 and no hobbyists are willing to submit it > >> to OpenWrt and modernize it to use device tree I think it should be > >> deleted from the kernel. > >> > > > > That may be the best approach if indeed no one is using it, > > much less maintaining it. > > Well, I for one don't really use it any more. So I don't have a lot > of motivation to maintain it any longer. I came across my patches while rebasing my backlog to 5.3-rc1. Should I save the (very small) trouble of sending them out again and just remove the platform then? Arnd
