Messages in this thread | | | Subject | Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers | From | Jae Hyun Yoo <> | Date | Thu, 11 Jan 2018 11:54:16 -0800 |
| |
On 1/11/2018 12:56 AM, Benjamin Herrenschmidt wrote: > 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 for your reminding me the upstream process. I'll do like you said afterwards.
Thanks, Jae
>> thanks, >> >> greg k-h >
| |