On Thu, 2018-01-11 at 08:30 +0100, Greg KH wrote: > 4.13? Why that kernel? It too is obsolete and insecure and > unsupported. Haha, it's n-1. come on :-) > What keeps you all from just always tracking the latest tree from Linus? > What is in your tree that is not upstream that requires you to have a > kernel tree at all? There are a couple of ARM based SoC families for which we are in the process of rewriting all the driver in upstreamable form. This takes time. To respond to your other email about the USB CDC, it's mine, I haven't resubmited it yet because it had a dependency on some the aspeed clk driver to function properly (so is unusable without it) and it took 2 kernel versions to get that clk stuff upstream for a number of reasons. So it's all getting upstream and eventually there will be (we hope) no "OpenBMC" kernel, it's just a way for us to get functional code with non-upstream-quality (read: vendor) drivers until we are one rewriting & upstreaming them all. > And if you do have out-of-tree code, why not use a process that makes it > trivial to update the base kernel version so that you can keep up to > date very easily? (hint, just using 'git' is not a good way to do > this...) Joel and I both find git perfectly fine for that. I've not touched quilt in eons and frankly don't regret it ;-) That said, Jae should definitely submit a driver against upstream, not against some random OpenBMC tree. Jae, for example when I submitted the original USB stuff back then, I did it from a local upstream based branch (with just a few hacks to work around the lack of the clk stuff). I will rebase it in the next few days to upstream merged with Stephen's clk tree to get the finally merged clk stuff, verify it works, and submit patches against upstream. There should be no mention of dev-4.10 or 4.13 on lkml or other upstream submission lists. Development work should happen upstream *first* and eventually be backported to our older kernels while they exist (hopefully I prefer if we are more aggressive at forward porting the crappy drivers so we can keep our tree more up to date but that's a different discussion). Cheers, Ben. > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
