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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 1/10/2018 12:27 PM, Greg KH wrote:
On Wed, Jan 10, 2018 at 11:30:05AM -0800, Jae Hyun Yoo wrote:
On 1/10/2018 11:17 AM, Greg KH wrote:
On Wed, Jan 10, 2018 at 11:14:34AM -0800, Jae Hyun Yoo wrote:
On 1/10/2018 2:17 AM, Greg KH wrote:
On Tue, Jan 09, 2018 at 02:31:20PM -0800, Jae Hyun Yoo wrote:
From: Jae Hyun Yoo <jae.hyun.yoo@xxxxxxxxx>

Hello,

This patch set provides support for PECI of AST2400/2500 which can give us PECI
functionalities such as temperature monitoring, platform manageability,
processor diagnostics and failure analysis. Also provides generic peci.h and
peci_ioctl.h headers to provide compatibility to peci drivers that can be
implemented later e.g. Nuvoton's BMC SoC family.

What is the "dev-4.10" in the subject for?  4.10 is really old and
obsolete :(

thanks,

greg k-h


I made this patch set on top of the v4.10 which OpenBmc project is currently
using. I'll rebase this patch set onto the current kernel.org mainline.

What is "OpenBmc", and why are they using an obsolete and insecure
kernel for their project?  That seems like a very foolish thing to do...

thanks,

greg k-h


OpenBmc is an open source project to create a highly extensible framework
for BMC (Board Management Controller) software for data-center computer
systems:
https://github.com/openbmc

Its current mainline is v4.10 but it is being kept upgrading so it will be
upgraded to the latest stable or long-term version soon.

Why hasn't it been updated in the year since 4.10 was released?  That's
a _very_ long time to be running on a totally insecure kernel, and no
new development should ever be done on old kernels, that's even crazier
(as we can't go back in time and accept patches for new features to old
releases...)


Thanks for your pointing it out and I totally agree with you. Actually, we are preparing 4.13 update for now and an another update will be followed up. As I answered above, I'll rebase this patch set onto the latest kernel.org mainline. Sorry for my misunderstanding of upstream process.

It sounds like the openbmc project needs to learn how to manage their
kernels a whole lot better, who do I need to go poke about this?
 > thanks,

greg k-h


I've already cc'ed openbmc developers so they are also seeing this thread. Joel Stanley <joel@xxxxxxxxx> is the openbmc kernel maintainer.

Thanks,
Jae
--
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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux