Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Doug Thompson]

--- On Thu, 5/7/09, Ingo Molnar <mingo@elte.hu> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Subject: Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64
> To: "Andrew Morton" <akpm@linux-foundation.org>
> Cc: "Borislav Petkov" <borislav.petkov@amd.com>, greg@kroah.com, norsk5@yahoo.com, tglx@linutronix.de, hpa@zytor.com, mchehab@redhat.com, aris@redhat.com, edt@aei.ca, linux-kernel@vger.kernel.org
> Date: Thursday, May 7, 2009, 3:18 PM
> 
> * Andrew Morton <akpm@linux-foundation.org>
> wrote:
> 
> > On Thu, 7 May 2009 16:38:07 +0200
> > Borislav Petkov <borislav.petkov@amd.com>
> wrote:
> > 
> > > Hi,
> > > 
> > > On Thu, May 07, 2009 at 04:27:24PM +0200, Ingo
> Molnar wrote:
> > > > Regarding workflow, the arch/x86 bits look
> good to me now, so you've 
> > > > got my Acked-by for that.
> > > 
> > > Cool, thanks.
> > > 
> > > Does that mean you're going to pick that one
> or...
> > > 
> > > > Most of the EDAC patches are hosted in 
> > > > -mm, so we could carry them in the x86 tree
> separately as well and 
> > > > export it to linux-next so that -mm will
> have it automatically.
> > > 
> > > is the bunch going through Andrew as a whole?
> > > 
> > 
> > I could.  But there's negligible overlap with
> other EDAC work so 
> > we might as well merge this via IngoTrees or directly
> from your 
> > tree.
> 
> If Doug and you agrees too then i have no problem (at all)
> with 
> Borislav carrying these bits in a separate tree, as long as
> he also 
> opens an edac-next branch for linux-next and asks Stephen
> to pull 
> it, and keeps it an append-mostly tree that isnt rebased.
> 
> [ I still have to do a finegrained review of this lot, a
> quick look
>   suggested i'll have a few minor things to note ;) ]
> 
>     Ingo
> 

I agree, if it removes a burden from some

doug t

[RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Borislav Petkov]

Hi,

here's v3 of the EDAC module for AMD k8, Fam10h and Fam11h processors.
Among the changes from the previous version are a split of the
driver into several .c files based on functionality, removal of
StinkyIdentifiers and bunch of cleanups all over the place.

Thanks again to all the reviewers for their constructive comments, as
always give it a good stare and flame away :).

There's also a git repo with the patchset based on Linus' branch from
yesterday:

git://git.kernel.org/pub/scm/linux/kernel/git/bp/amd64_edac.git

Changelog:

- v2:
Highlights are the addition of two helpers to read/write MSRs on several
CPUs, denoted by a cpumask and using an array of MSR values per-CPU, as
hpa suggested. Since IMHO they look generic enough I've added them to
arch/x86/lib/msr-on-cpu.c (now renamed to msr.c).

Thanks,
Boris.


 arch/x86/include/asm/msr.h          |   21 +
 arch/x86/lib/Makefile               |    2 +-
 arch/x86/lib/msr-on-cpu.c           |   97 -
 arch/x86/lib/msr.c                  |  152 ++
 drivers/edac/Kconfig                |   26 +
 drivers/edac/Makefile               |   13 +
 drivers/edac/amd64_edac.c           | 3759 +++++++++++++++++++++++++++++++++++
 drivers/edac/amd64_edac.h           |  951 +++++++++
 drivers/edac/amd64_edac_dbg.c       |  291 +++
 drivers/edac/amd64_edac_err_types.c |  163 ++
 drivers/edac/amd64_edac_inj.c       |  203 ++
 11 files changed, 5580 insertions(+), 98 deletions(-)

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Ingo Molnar]

* Borislav Petkov <borislav.petkov@amd.com> wrote:

> Hi,
> 
> here's v3 of the EDAC module for AMD k8, Fam10h and Fam11h processors.
> Among the changes from the previous version are a split of the
> driver into several .c files based on functionality, removal of
> StinkyIdentifiers and bunch of cleanups all over the place.
> 
> Thanks again to all the reviewers for their constructive comments, as
> always give it a good stare and flame away :).
> 
> There's also a git repo with the patchset based on Linus' branch from
> yesterday:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/bp/amd64_edac.git
> 
> Changelog:
> 
> - v2:
> Highlights are the addition of two helpers to read/write MSRs on several
> CPUs, denoted by a cpumask and using an array of MSR values per-CPU, as
> hpa suggested. Since IMHO they look generic enough I've added them to
> arch/x86/lib/msr-on-cpu.c (now renamed to msr.c).
> 
> Thanks,
> Boris.
> 
> 
>  arch/x86/include/asm/msr.h          |   21 +
>  arch/x86/lib/Makefile               |    2 +-
>  arch/x86/lib/msr-on-cpu.c           |   97 -
>  arch/x86/lib/msr.c                  |  152 ++
>  drivers/edac/Kconfig                |   26 +
>  drivers/edac/Makefile               |   13 +
>  drivers/edac/amd64_edac.c           | 3759 +++++++++++++++++++++++++++++++++++
>  drivers/edac/amd64_edac.h           |  951 +++++++++
>  drivers/edac/amd64_edac_dbg.c       |  291 +++
>  drivers/edac/amd64_edac_err_types.c |  163 ++
>  drivers/edac/amd64_edac_inj.c       |  203 ++
>  11 files changed, 5580 insertions(+), 98 deletions(-)

Regarding workflow, the arch/x86 bits look good to me now, so you've 
got my Acked-by for that. Most of the EDAC patches are hosted in 
-mm, so we could carry them in the x86 tree separately as well and 
export it to linux-next so that -mm will have it automatically.

	Ingo

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Borislav Petkov]

Hi,

On Thu, May 07, 2009 at 04:27:24PM +0200, Ingo Molnar wrote:
> Regarding workflow, the arch/x86 bits look good to me now, so you've 
> got my Acked-by for that.

Cool, thanks.

Does that mean you're going to pick that one or...

> Most of the EDAC patches are hosted in 
> -mm, so we could carry them in the x86 tree separately as well and 
> export it to linux-next so that -mm will have it automatically.

is the bunch going through Andrew as a whole?

-- 
Regards/Gruss,
Boris.

Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Andrew Morton]

On Thu, 7 May 2009 16:38:07 +0200
Borislav Petkov <borislav.petkov@amd.com> wrote:

> Hi,
> 
> On Thu, May 07, 2009 at 04:27:24PM +0200, Ingo Molnar wrote:
> > Regarding workflow, the arch/x86 bits look good to me now, so you've 
> > got my Acked-by for that.
> 
> Cool, thanks.
> 
> Does that mean you're going to pick that one or...
> 
> > Most of the EDAC patches are hosted in 
> > -mm, so we could carry them in the x86 tree separately as well and 
> > export it to linux-next so that -mm will have it automatically.
> 
> is the bunch going through Andrew as a whole?
> 

I could.  But there's negligible overlap with other EDAC work so we
might as well merge this via IngoTrees or directly from your tree.

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 7 May 2009 16:38:07 +0200
> Borislav Petkov <borislav.petkov@amd.com> wrote:
> 
> > Hi,
> > 
> > On Thu, May 07, 2009 at 04:27:24PM +0200, Ingo Molnar wrote:
> > > Regarding workflow, the arch/x86 bits look good to me now, so you've 
> > > got my Acked-by for that.
> > 
> > Cool, thanks.
> > 
> > Does that mean you're going to pick that one or...
> > 
> > > Most of the EDAC patches are hosted in 
> > > -mm, so we could carry them in the x86 tree separately as well and 
> > > export it to linux-next so that -mm will have it automatically.
> > 
> > is the bunch going through Andrew as a whole?
> > 
> 
> I could.  But there's negligible overlap with other EDAC work so 
> we might as well merge this via IngoTrees or directly from your 
> tree.

If Doug and you agrees too then i have no problem (at all) with 
Borislav carrying these bits in a separate tree, as long as he also 
opens an edac-next branch for linux-next and asks Stephen to pull 
it, and keeps it an append-mostly tree that isnt rebased.

[ I still have to do a finegrained review of this lot, a quick look
  suggested i'll have a few minor things to note ;) ]

	Ingo

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Borislav Petkov]

Hi,

On Thu, May 07, 2009 at 11:18:59PM +0200, Ingo Molnar wrote:
> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Thu, 7 May 2009 16:38:07 +0200
> > Borislav Petkov <borislav.petkov@amd.com> wrote:
> > 
> > > Hi,
> > > 
> > > On Thu, May 07, 2009 at 04:27:24PM +0200, Ingo Molnar wrote:
> > > > Regarding workflow, the arch/x86 bits look good to me now, so you've 
> > > > got my Acked-by for that.
> > > 
> > > Cool, thanks.
> > > 
> > > Does that mean you're going to pick that one or...
> > > 
> > > > Most of the EDAC patches are hosted in 
> > > > -mm, so we could carry them in the x86 tree separately as well and 
> > > > export it to linux-next so that -mm will have it automatically.
> > > 
> > > is the bunch going through Andrew as a whole?
> > > 
> > 
> > I could.  But there's negligible overlap with other EDAC work so 
> > we might as well merge this via IngoTrees or directly from your 
> > tree.
> 
> If Doug and you agrees too then i have no problem (at all) with 
> Borislav carrying these bits in a separate tree, as long as he also 
> opens an edac-next branch for linux-next and asks Stephen to pull 
> it, and keeps it an append-mostly tree that isnt rebased.

I'll still need to rebase stuff to latest Linus tree for now since we're
not yet ready reorganizing/cleaning up the code. After it gets merged,
I'll switch to append-only mode.

-- 
Regards/Gruss,
Boris.

Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Mauro Carvalho Chehab]

Em Fri, 8 May 2009 12:07:38 +0200
Borislav Petkov <borislav.petkov@amd.com> escreveu:

> Hi,
> 
> On Thu, May 07, 2009 at 11:18:59PM +0200, Ingo Molnar wrote:
> > 
> > * Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > > On Thu, 7 May 2009 16:38:07 +0200
> > > Borislav Petkov <borislav.petkov@amd.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > On Thu, May 07, 2009 at 04:27:24PM +0200, Ingo Molnar wrote:
> > > > > Regarding workflow, the arch/x86 bits look good to me now, so you've 
> > > > > got my Acked-by for that.
> > > > 
> > > > Cool, thanks.
> > > > 
> > > > Does that mean you're going to pick that one or...
> > > > 
> > > > > Most of the EDAC patches are hosted in 
> > > > > -mm, so we could carry them in the x86 tree separately as well and 
> > > > > export it to linux-next so that -mm will have it automatically.
> > > > 
> > > > is the bunch going through Andrew as a whole?
> > > > 
> > > 
> > > I could.  But there's negligible overlap with other EDAC work so 
> > > we might as well merge this via IngoTrees or directly from your 
> > > tree.
> > 
> > If Doug and you agrees too then i have no problem (at all) with 
> > Borislav carrying these bits in a separate tree, as long as he also 
> > opens an edac-next branch for linux-next and asks Stephen to pull 
> > it, and keeps it an append-mostly tree that isnt rebased.
> 
> I'll still need to rebase stuff to latest Linus tree for now since we're
> not yet ready reorganizing/cleaning up the code. After it gets merged,
> I'll switch to append-only mode.

One good idea is to split the Kbuild changes into a separate changeset. This
way, if compilation happens to break due to a merge conflict with other patches,
you can just write a fix patch fixing it before the Kbuild one, without
breaking git bisect.

-- 

Cheers,
Mauro

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Ingo Molnar]

* Borislav Petkov <borislav.petkov@amd.com> wrote:

> Hi,
> 
> On Thu, May 07, 2009 at 11:18:59PM +0200, Ingo Molnar wrote:
> > 
> > * Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > > On Thu, 7 May 2009 16:38:07 +0200
> > > Borislav Petkov <borislav.petkov@amd.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > On Thu, May 07, 2009 at 04:27:24PM +0200, Ingo Molnar wrote:
> > > > > Regarding workflow, the arch/x86 bits look good to me now, so you've 
> > > > > got my Acked-by for that.
> > > > 
> > > > Cool, thanks.
> > > > 
> > > > Does that mean you're going to pick that one or...
> > > > 
> > > > > Most of the EDAC patches are hosted in 
> > > > > -mm, so we could carry them in the x86 tree separately as well and 
> > > > > export it to linux-next so that -mm will have it automatically.
> > > > 
> > > > is the bunch going through Andrew as a whole?
> > > > 
> > > 
> > > I could.  But there's negligible overlap with other EDAC work so 
> > > we might as well merge this via IngoTrees or directly from your 
> > > tree.
> > 
> > If Doug and you agrees too then i have no problem (at all) with 
> > Borislav carrying these bits in a separate tree, as long as he also 
> > opens an edac-next branch for linux-next and asks Stephen to pull 
> > it, and keeps it an append-mostly tree that isnt rebased.
> 
> I'll still need to rebase stuff to latest Linus tree for now since 
> we're not yet ready reorganizing/cleaning up the code. After it 
> gets merged, I'll switch to append-only mode.

that's OK! Rebasing of your own commits is fine (especially during 
active development, and especially if there's a lot of outstanding 
review feedback). What matters is to have an eventual cool-down so 
that earlier commits become append-only. That makes a tree more 
trustable - while you never know what's in a fully rebased tree.

	Ingo

Re: [RFC PATCH 00/21 v3] amd64_edac: EDAC module for AMD64

[Andrew Morton]

On Thu, 7 May 2009 15:49:22 +0200
Borislav Petkov <borislav.petkov@amd.com> wrote:

> here's v3 of the EDAC module for AMD k8, Fam10h and Fam11h processors.
> Among the changes from the previous version are a split of the
> driver into several .c files based on functionality, removal of
> StinkyIdentifiers and bunch of cleanups all over the place.
> 
> Thanks again to all the reviewers for their constructive comments, as
> always give it a good stare and flame away :).
> 
> There's also a git repo with the patchset based on Linus' branch from
> yesterday:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/bp/amd64_edac.git

Seeing as you have a git tree and I'm always happy to avoid work, I'd
suggest that you ask Stephen Rothwell to inlude this drivee in
linux-next and then ask Linus to pull it during the 2.6.31-rc1 merge
window.

That does put an onus upon you to ensure that any changes which you
make to your tree between now and then are suitably reviewed, please.