Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers

[Benjamin Herrenschmidt <benh@au1.ibm.com>]

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