| Message ID | 20180109223126.13093-1-jae.hyun.yoo@linux.intel.com |
|---|---|
| Headers | show |
| Series | Add support PECI and PECI hwmon drivers | expand |
On Tue, Jan 09, 2018 at 02:31:20PM -0800, Jae Hyun Yoo wrote: > From: Jae Hyun Yoo <jae.hyun.yoo@intel.com> > > 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
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@intel.com> >> >> 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. Thanks, Jae
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@intel.com> > > > > > > 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
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@intel.com> >>>> >>>> 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. Thanks, Jae
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@intel.com> > > > > > > > > > > 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...) 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
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@intel.com> >>>>>> >>>>>> 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@jms.id.au> is the openbmc kernel maintainer. Thanks, Jae
On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote: > 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@intel.com> > > > > > > > > > > > > > > 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. 4.13? Why that kernel? It too is obsolete and insecure and unsupported. 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? 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...) thanks, greg k-h
On Wed, Jan 10, 2018 at 11:30 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote: >> 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. > > 4.13? Why that kernel? It too is obsolete and insecure and > unsupported. It contains support for our hardware that I have integrated from work in progress patches and upstream commits. The OpenBMC project, with myself as the kernel maintainer, have intentions to regularly move to upstream releases. This takes time and effort. This time and effort is balanced with submitting our drivers upstream. > What keeps you all from just always tracking the latest tree from Linus? Linus' tree does not contain all of the drivers required to boot systems. Many of them are still under review on lkml, and others still require rewrite from the vendor tree. > What is in your tree that is not upstream that requires you to have a > kernel tree at all? We have PECI, video compression, crypto, USB CDC, DRM (graphics), serial GPIO, LPC mailbox for the ASPEED SoC. Another silicon vendor has recently joined the project and that brings an entire SoC that is not upstream. We have patches on the ARM that are under review for this SoC, with more drivers undergoing cleanup in order to submit them to the relevant maintainers. > > 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...) We have a process that we've been developing under for the past few years. I find git to be a great tool for managing Linux kernel trees. What would you recommend for managing kernel trees? Cheers, Joel
On Thu, Jan 11, 2018 at 12:28:48AM -0800, Joel Stanley wrote: > On Wed, Jan 10, 2018 at 11:30 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote: > >> 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. > > > > 4.13? Why that kernel? It too is obsolete and insecure and > > unsupported. > > It contains support for our hardware that I have integrated from work > in progress patches and upstream commits. > > The OpenBMC project, with myself as the kernel maintainer, have > intentions to regularly move to upstream releases. This takes time and > effort. This time and effort is balanced with submitting our drivers > upstream. Of course, but please do not have your "users" use a kernel that is known to have bugs and can not be supported. That would not be good at all, don't you think? > > What keeps you all from just always tracking the latest tree from Linus? > > Linus' tree does not contain all of the drivers required to boot > systems. Many of them are still under review on lkml, and others still > require rewrite from the vendor tree. Merging vendor trees into your tree has got to be a complicated mess. Why try to keep it all together in one place? And who is responsible for getting the vendor code upstream? The individual drivers? Individual driver submissions should be quite easy, what is preventing them from getting merged? > > What is in your tree that is not upstream that requires you to have a > > kernel tree at all? > > We have PECI, video compression, crypto, USB CDC, DRM (graphics), > serial GPIO, LPC mailbox for the ASPEED SoC. What "USB CDC" do you have that is not upstream? I'll pick on this one specifically as I don't think I've seen any patches recently submitted for that driver at all. Am I just missing them? The other ones should also all be easy to get merged, with maybe the exception of the drm stuff due to the speed that subsystem moves at. But even there, the community is very helpful in getting stuff upstream, have you asked for help? > Another silicon vendor has recently joined the project and that brings > an entire SoC that is not upstream. We have patches on the ARM that > are under review for this SoC, with more drivers undergoing cleanup in > order to submit them to the relevant maintainers. Why are you merging all SoC trees together into one place? That seems like a nightmare to manage, especially with git. > > 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...) > > We have a process that we've been developing under for the past few > years. I find git to be a great tool for managing Linux kernel trees. > > What would you recommend for managing kernel trees? quilt is best for a tree that you can not rebase (i.e. a public git tree). Otherwise you end up getting patches all mushed together and hard to extract in any simple way. Take a clue from the distros that have been managing kernels for decades and deal with an updated kernel all the time easily. Good luck, it sounds like you will need it :) thanks, greg k-h
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
On Thu, Jan 11, 2018 at 9:41 AM, Greg KH <gregkh@linuxfoundation.org> wrote: > On Thu, Jan 11, 2018 at 12:28:48AM -0800, Joel Stanley wrote: >> On Wed, Jan 10, 2018 at 11:30 PM, Greg KH <gregkh@linuxfoundation.org> wrote: >> > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote: >> >> 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. >> > >> > 4.13? Why that kernel? It too is obsolete and insecure and >> > unsupported. >> >> It contains support for our hardware that I have integrated from work >> in progress patches and upstream commits. >> >> The OpenBMC project, with myself as the kernel maintainer, have >> intentions to regularly move to upstream releases. This takes time and >> effort. This time and effort is balanced with submitting our drivers >> upstream. > > Of course, but please do not have your "users" use a kernel that is > known to have bugs and can not be supported. That would not be good at > all, don't you think? I've been pretty happy with the progress in merging drivers upstream for OpenBMC. Of course things always take longer than planned, but they are getting there. Most servers today are probably running the aspeed vendor kernel based on linux-2.6.28.10, at least that's what my workstation runs (and no, I did not connect the BMC to my home network). The particular choices of mainline versions (4.10 and 4.13) may be unfortunate as they are both one off from a longterm release, but not being stuck on 2.6 is the important first step in order to upstream stuff. >> Another silicon vendor has recently joined the project and that brings >> an entire SoC that is not upstream. We have patches on the ARM that >> are under review for this SoC, with more drivers undergoing cleanup in >> order to submit them to the relevant maintainers. > > Why are you merging all SoC trees together into one place? That seems > like a nightmare to manage, especially with git. Why would anyone want to have multiple kernel trees just to run things on different SoCs? ;-) It's just a collection of device drivers in different stages of getting upstreamed. >> > 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...) >> >> We have a process that we've been developing under for the past few >> years. I find git to be a great tool for managing Linux kernel trees. >> >> What would you recommend for managing kernel trees? > > quilt is best for a tree that you can not rebase (i.e. a public git > tree). Otherwise you end up getting patches all mushed together and > hard to extract in any simple way. I'm ususally happy with having git with topic branches to make the rebasing easier. In many cases, you can just leave a topic branch for a particular subsystem unchanged between versions and just merge the latest version of those branches until the branch goes away after upstreaming. Arnd
On Thu, 2018-01-11 at 09:41 +0100, Greg KH wrote: > On Thu, Jan 11, 2018 at 12:28:48AM -0800, Joel Stanley wrote: > > On Wed, Jan 10, 2018 at 11:30 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > > > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote: > > > > 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. > > > > > > 4.13? Why that kernel? It too is obsolete and insecure and > > > unsupported. > > > > It contains support for our hardware that I have integrated from work > > in progress patches and upstream commits. > > > > The OpenBMC project, with myself as the kernel maintainer, have > > intentions to regularly move to upstream releases. This takes time and > > effort. This time and effort is balanced with submitting our drivers > > upstream. > > Of course, but please do not have your "users" use a kernel that is > known to have bugs and can not be supported. That would not be good at > all, don't you think? There is little choice, we don't have the manpower to rewrite/upstream all the drivers in a day, and rebasing to newer kernel takes time due to various dependencies, testing requirements etc. That being said, 4.13 is N-1, not too bad. > > > What keeps you all from just always tracking the latest tree from Linus? > > > > Linus' tree does not contain all of the drivers required to boot > > systems. Many of them are still under review on lkml, and others still > > require rewrite from the vendor tree. > > Merging vendor trees into your tree has got to be a complicated mess. > Why try to keep it all together in one place? There are no vendor trees to speak of that we could merge. At least not yet. We've been teaching vendors about doing proper drivers that can work with upstream, device-tree based platforms etc... but it takes time for them to get up to speed. So while we are rewriting the drivers (sometimes with the vendor's help), we keep a tree with the "sub-standard" ones hacked up to work on our DT based platform and with our other bits and pieces until we can ditch it. > And who is responsible for getting the vendor code upstream? The > individual drivers? Individual driver submissions should be quite easy, > what is preventing them from getting merged? It just takes time Greg. The original vendor drivers are in no shape to get anywhere near upstream. They have to be mostly rewritten one by one. Sometimes we can teach the vendor and help them along, some times we do it ourselves, but it's a time consuming process. It took 2 or 3 kernel versions just to get the clk drivers that Joel had written upstream for example. It took me a long time as well to get ftgmac100 sorted. > > > What is in your tree that is not upstream that requires you to have a > > > kernel tree at all? > > > > We have PECI, video compression, crypto, USB CDC, DRM (graphics), > > serial GPIO, LPC mailbox for the ASPEED SoC. > > What "USB CDC" do you have that is not upstream? See my other email :) > I'll pick on this one > specifically as I don't think I've seen any patches recently submitted > for that driver at all. Am I just missing them? > > The other ones should also all be easy to get merged, with maybe the > exception of the drm stuff due to the speed that subsystem moves at. > But even there, the community is very helpful in getting stuff upstream, > have you asked for help? We can't expect the community to rewrite the drivers for us. Some of the clk and pinmux stuff is intrinsically very complex, and took time (and we did get valuable feedback). Now that these basic pieces of infrastructure are in, it's a matter of tackling the remaining drivers one at a time. > > Another silicon vendor has recently joined the project and that brings > > an entire SoC that is not upstream. We have patches on the ARM that > > are under review for this SoC, with more drivers undergoing cleanup in > > order to submit them to the relevant maintainers. > > Why are you merging all SoC trees together into one place? That seems > like a nightmare to manage, especially with git. There are no SoC trees per-se. There is the OpenBMC tree which has hand-hacked vendor drivers plugged into it, which are going away one at a time as we clean them up. There's really one SoC family only in use (aspeed) at the moment with one other coming around the corner (Nuvoton). For the latter, my understanding is that we are trying to get the vendor to get their stuff upstream directly. > > > 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...) > > > > We have a process that we've been developing under for the past few > > years. I find git to be a great tool for managing Linux kernel trees. > > > > What would you recommend for managing kernel trees? > > quilt is best for a tree that you can not rebase (i.e. a public git > tree). Otherwise you end up getting patches all mushed together and > hard to extract in any simple way. > > Take a clue from the distros that have been managing kernels for decades > and deal with an updated kernel all the time easily. > > Good luck, it sounds like you will need it :) Nah, not luck, we just need to get those drivers done one at a time, it's not a matter of luck. And I find git to be just fine :) Cheers, Ben. > thanks, > > greg k-h
On Thu, Jan 11, 2018 at 07:56:51PM +1100, 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 :-) And, if you use it in a device, it's still totally unsupported and insecure. Seriously, does no one actually pay attention to the patches I merge in the stable trees anymore? Anyway, your other comments are good, glad to see work is progressing well, and yes it's better than a 2.6.y based kernel, but really, that's a low bar... thanks, greg k-h
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 >
On Thu, 2018-01-11 at 10:59 +0100, Greg KH wrote: > And, if you use it in a device, it's still totally unsupported and > insecure. Seriously, does no one actually pay attention to the patches > I merge in the stable trees anymore? Yeah not sure why we aren't picking an LTC here, it could be that it's just a dev branch, not release, Joel, what's the process in that case ? For anything going into products, if we're going to maintain a non- upstream branch, we should definitely stick it to an LTS release or we'll be missing a ton of security fixes. Cheers, Ben.
From: Jae Hyun Yoo <jae.hyun.yoo@intel.com> 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. The misc peci driver can be used as a multi-purpose PECI controller driver which serializes all PECI transactions that coming from user space and from other kernel modules. This misc peci driver could be replaced with other BMC chipsets' implementation if the implementation provide compatible 'peci_ioctl' inter-module call and ioctl scheme defined in peci.h and peci_ioctl.h files. The hwmon peci driver implements a generic PECI hwmon feature which is running with a PECI misc driver supports compatible native PECI command suite for retrieving temperatures of the CPU package, CPU cores and DIMM components. Please review. -Jae Jae Hyun Yoo (6): Documentation: dt-bindings: Add Aspeed PECI ARM: dts: aspeed: peci: Add Aspeed PECI drivers/misc: Add driver for Aspeed PECI and generic PECI headers Documentation: dt-bindings: Add a generic PECI hwmon Documentation: hwmon: Add a generic PECI hwmon drivers/hwmon: Add a driver for a generic PECI hwmon .../devicetree/bindings/hwmon/peci-hwmon.txt | 33 + .../devicetree/bindings/misc/aspeed-peci.txt | 55 + Documentation/hwmon/peci-hwmon | 74 ++ arch/arm/boot/dts/aspeed-g4.dtsi | 14 + arch/arm/boot/dts/aspeed-g5.dtsi | 14 + drivers/hwmon/Kconfig | 6 + drivers/hwmon/Makefile | 1 + drivers/hwmon/peci-hwmon.c | 953 +++++++++++++++++ drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/aspeed-peci.c | 1130 ++++++++++++++++++++ include/misc/peci.h | 11 + include/uapi/linux/Kbuild | 1 + include/uapi/linux/peci_ioctl.h | 270 +++++ 14 files changed, 2572 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/peci-hwmon.txt create mode 100644 Documentation/devicetree/bindings/misc/aspeed-peci.txt create mode 100644 Documentation/hwmon/peci-hwmon create mode 100644 drivers/hwmon/peci-hwmon.c create mode 100644 drivers/misc/aspeed-peci.c create mode 100644 include/misc/peci.h create mode 100644 include/uapi/linux/peci_ioctl.h