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

[Jae Hyun Yoo]

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
>