[GIT PULL] mpc85xx_edac changes for 3.13

[GIT PULL] mpc85xx_edac changes for 3.13

[Johannes Thumshirn]

Hi Linus,

Please pull these changes for mpc85xx_edac. They have been around on linux-edac
for a while.

Thanks.

--
The following changes since commit 10d0c9705e80bbd3d587c5fad24599aabaca6688:

  Merge tag 'devicetree-for-3.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux (2013-11-12 16:52:17 +0900)

are available in the git repository at:


  git://github.com/morbidrsa/linux.git tags/mpc85xx-edac-for-3.13

for you to fetch changes up to 43b5acb650587ec6495c2e3b8c2e30311e9dc8cf:

  edac/85xx: Remove mpc85xx_pci_err_remove (2013-11-12 17:06:16 +0100)

----------------------------------------------------------------
mpc85xx_edac for 3.13

----------------------------------------------------------------
Chunhe Lan (1):
      edac/85xx: Add PCIe error interrupt edac support

Johannes Thumshirn (2):
      MAINTAINERS: Add edac-mpc85xx driver to MAINTAINERS
      edac/85xx: Remove mpc85xx_pci_err_remove

 MAINTAINERS                 |   7 +++
 drivers/edac/mpc85xx_edac.c | 120 ++++++++++++++++++++++++++++++++------------
 drivers/edac/mpc85xx_edac.h |   7 +++
 3 files changed, 101 insertions(+), 33 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 051e4dc..3391279 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3129,6 +3129,13 @@ W:	bluesmoke.sourceforge.net
 S:	Maintained
 F:	drivers/edac/i82975x_edac.c

+EDAC-MPC85XX
+M:	Johannes Thumshirn <johannes.thumshirn@men.de>
+L:	linux-edac@vger.kernel.org
+W:	bluesmoke.sourceforge.net
+S:	Maintained
+F:	drivers/edac/mpc85xx_edac.[ch]
+
 EDAC-PASEMI
 M:	Egor Martovetsky <egor@pasemi.com>
 L:	linux-edac@vger.kernel.org
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 3eb32f6..8f91821 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1,6 +1,8 @@
 /*
  * Freescale MPC85xx Memory Controller kenel module
  *
+ * Parts Copyrighted (c) 2013 by Freescale Semiconductor, Inc.
+ *
  * Author: Dave Jiang <djiang@mvista.com>
  *
  * 2006-2007 (c) MontaVista Software, Inc. This file is licensed under
@@ -196,6 +198,42 @@ static void mpc85xx_pci_check(struct edac_pci_ctl_info *pci)
 		edac_pci_handle_npe(pci, pci->ctl_name);
 }

+static void mpc85xx_pcie_check(struct edac_pci_ctl_info *pci)
+{
+	struct mpc85xx_pci_pdata *pdata = pci->pvt_info;
+	u32 err_detect;
+
+	err_detect = in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR);
+
+	pr_err("PCIe error(s) detected\n");
+	pr_err("PCIe ERR_DR register: 0x%08x\n", err_detect);
+	pr_err("PCIe ERR_CAP_STAT register: 0x%08x\n",
+			in_be32(pdata->pci_vbase + MPC85XX_PCI_GAS_TIMR));
+	pr_err("PCIe ERR_CAP_R0 register: 0x%08x\n",
+			in_be32(pdata->pci_vbase + MPC85XX_PCIE_ERR_CAP_R0));
+	pr_err("PCIe ERR_CAP_R1 register: 0x%08x\n",
+			in_be32(pdata->pci_vbase + MPC85XX_PCIE_ERR_CAP_R1));
+	pr_err("PCIe ERR_CAP_R2 register: 0x%08x\n",
+			in_be32(pdata->pci_vbase + MPC85XX_PCIE_ERR_CAP_R2));
+	pr_err("PCIe ERR_CAP_R3 register: 0x%08x\n",
+			in_be32(pdata->pci_vbase + MPC85XX_PCIE_ERR_CAP_R3));
+
+	/* clear error bits */
+	out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR, err_detect);
+}
+
+static int mpc85xx_pcie_find_capability(struct device_node *np)
+{
+	struct pci_controller *hose;
+
+	if (!np)
+		return -EINVAL;
+
+	hose = pci_find_hose_for_OF_device(np);
+
+	return early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP);
+}
+
 static irqreturn_t mpc85xx_pci_isr(int irq, void *dev_id)
 {
 	struct edac_pci_ctl_info *pci = dev_id;
@@ -207,7 +245,10 @@ static irqreturn_t mpc85xx_pci_isr(int irq, void *dev_id)
 	if (!err_detect)
 		return IRQ_NONE;

-	mpc85xx_pci_check(pci);
+	if (pdata->is_pcie)
+		mpc85xx_pcie_check(pci);
+	else
+		mpc85xx_pci_check(pci);

 	return IRQ_HANDLED;
 }
@@ -239,14 +280,22 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
 	pdata = pci->pvt_info;
 	pdata->name = "mpc85xx_pci_err";
 	pdata->irq = NO_IRQ;
+
+	if (mpc85xx_pcie_find_capability(op->dev.of_node) > 0)
+		pdata->is_pcie = true;
+
 	dev_set_drvdata(&op->dev, pci);
 	pci->dev = &op->dev;
 	pci->mod_name = EDAC_MOD_STR;
 	pci->ctl_name = pdata->name;
 	pci->dev_name = dev_name(&op->dev);

-	if (edac_op_state == EDAC_OPSTATE_POLL)
-		pci->edac_check = mpc85xx_pci_check;
+	if (edac_op_state == EDAC_OPSTATE_POLL) {
+		if (pdata->is_pcie)
+			pci->edac_check = mpc85xx_pcie_check;
+		else
+			pci->edac_check = mpc85xx_pci_check;
+	}

 	pdata->edac_idx = edac_pci_idx++;

@@ -275,16 +324,26 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
 		goto err;
 	}

-	orig_pci_err_cap_dr =
-	    in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_CAP_DR);
+	if (pdata->is_pcie) {
+		orig_pci_err_cap_dr =
+		    in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ADDR);
+		out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ADDR, ~0);
+		orig_pci_err_en =
+		    in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN);
+		out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN, 0);
+	} else {
+		orig_pci_err_cap_dr =
+		    in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_CAP_DR);

-	/* PCI master abort is expected during config cycles */
-	out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_CAP_DR, 0x40);
+		/* PCI master abort is expected during config cycles */
+		out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_CAP_DR, 0x40);

-	orig_pci_err_en = in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN);
+		orig_pci_err_en =
+		    in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN);

-	/* disable master abort reporting */
-	out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN, ~0x40);
+		/* disable master abort reporting */
+		out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN, ~0x40);
+	}

 	/* clear error bits */
 	out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR, ~0);
@@ -297,7 +356,8 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
 	if (edac_op_state == EDAC_OPSTATE_INT) {
 		pdata->irq = irq_of_parse_and_map(op->dev.of_node, 0);
 		res = devm_request_irq(&op->dev, pdata->irq,
-				       mpc85xx_pci_isr, IRQF_DISABLED,
+				       mpc85xx_pci_isr,
+				       IRQF_DISABLED | IRQF_SHARED,
 				       "[EDAC] PCI err", pci);
 		if (res < 0) {
 			printk(KERN_ERR
@@ -312,6 +372,22 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
 		       pdata->irq);
 	}

+	if (pdata->is_pcie) {
+		/*
+		 * Enable all PCIe error interrupt & error detect except invalid
+		 * PEX_CONFIG_ADDR/PEX_CONFIG_DATA access interrupt generation
+		 * enable bit and invalid PEX_CONFIG_ADDR/PEX_CONFIG_DATA access
+		 * detection enable bit. Because PCIe bus code to initialize and
+		 * configure these PCIe devices on booting will use some invalid
+		 * PEX_CONFIG_ADDR/PEX_CONFIG_DATA, edac driver prints the much
+		 * notice information. So disable this detect to fix ugly print.
+		 */
+		out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN, ~0
+			 & ~PEX_ERR_ICCAIE_EN_BIT);
+		out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ADDR, 0
+			 | PEX_ERR_ICCAD_DISR_BIT);
+	}
+
 	devres_remove_group(&op->dev, mpc85xx_pci_err_probe);
 	edac_dbg(3, "success\n");
 	printk(KERN_INFO EDAC_MOD_STR " PCI err registered\n");
@@ -327,28 +403,6 @@ err:
 }
 EXPORT_SYMBOL(mpc85xx_pci_err_probe);

-static int mpc85xx_pci_err_remove(struct platform_device *op)
-{
-	struct edac_pci_ctl_info *pci = dev_get_drvdata(&op->dev);
-	struct mpc85xx_pci_pdata *pdata = pci->pvt_info;
-
-	edac_dbg(0, "\n");
-
-	out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_CAP_DR,
-		 orig_pci_err_cap_dr);
-
-	out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN, orig_pci_err_en);
-
-	edac_pci_del_device(pci->dev);
-
-	if (edac_op_state == EDAC_OPSTATE_INT)
-		irq_dispose_mapping(pdata->irq);
-
-	edac_pci_free_ctl_info(pci);
-
-	return 0;
-}
-
 #endif				/* CONFIG_PCI */

 /**************************** L2 Err device ***************************/
diff --git a/drivers/edac/mpc85xx_edac.h b/drivers/edac/mpc85xx_edac.h
index 932016f..8c62564 100644
--- a/drivers/edac/mpc85xx_edac.h
+++ b/drivers/edac/mpc85xx_edac.h
@@ -134,13 +134,19 @@
 #define MPC85XX_PCI_ERR_DR		0x0000
 #define MPC85XX_PCI_ERR_CAP_DR		0x0004
 #define MPC85XX_PCI_ERR_EN		0x0008
+#define   PEX_ERR_ICCAIE_EN_BIT		0x00020000
 #define MPC85XX_PCI_ERR_ATTRIB		0x000c
 #define MPC85XX_PCI_ERR_ADDR		0x0010
+#define   PEX_ERR_ICCAD_DISR_BIT	0x00020000
 #define MPC85XX_PCI_ERR_EXT_ADDR	0x0014
 #define MPC85XX_PCI_ERR_DL		0x0018
 #define MPC85XX_PCI_ERR_DH		0x001c
 #define MPC85XX_PCI_GAS_TIMR		0x0020
 #define MPC85XX_PCI_PCIX_TIMR		0x0024
+#define MPC85XX_PCIE_ERR_CAP_R0		0x0028
+#define MPC85XX_PCIE_ERR_CAP_R1		0x002c
+#define MPC85XX_PCIE_ERR_CAP_R2		0x0030
+#define MPC85XX_PCIE_ERR_CAP_R3		0x0034

 struct mpc85xx_mc_pdata {
 	char *name;
@@ -158,6 +164,7 @@ struct mpc85xx_l2_pdata {

 struct mpc85xx_pci_pdata {
 	char *name;
+	bool is_pcie;
 	int edac_idx;
 	void __iomem *pci_vbase;
 	int irq;

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Linus Torvalds]

On Wed, Nov 13, 2013 at 1:19 AM, Johannes Thumshirn
<johannes.thumshirn@men.de> wrote:
>
>   git://github.com/morbidrsa/linux.git tags/mpc85xx-edac-for-3.13

Ok, it's a signed tag, but I haven't pulled from you before (all the
commits I see seem to have gone through Greg), and I don't recognize
any of the signatures on your tag.

That, together with not really knowing the whole edac area, makes me
not wonderfully happy about pulling directly. I a.lso see another edac
pull request in my mailbox, making me suspect that there are
maintainership problems (historically I've been getting the code
either though Greg, Borislav or Mauro). So I'd also like to make sure
that I at least _know_ about any disputes going on in this area?

So before I pull this, I'd quickly like to validate the gpg key, and
am cc'ing more people to see if I'm stepping into some political
nightmare. I can be ok with that, but I want to do so knowingly, not
blindly..

                Linus

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Greg Kroah-Hartman]

On Thu, Nov 14, 2013 at 02:41:24PM +0900, Linus Torvalds wrote:
> On Wed, Nov 13, 2013 at 1:19 AM, Johannes Thumshirn
> <johannes.thumshirn@men.de> wrote:
> >
> >   git://github.com/morbidrsa/linux.git tags/mpc85xx-edac-for-3.13
> 
> Ok, it's a signed tag, but I haven't pulled from you before (all the
> commits I see seem to have gone through Greg), and I don't recognize
> any of the signatures on your tag.
> 
> That, together with not really knowing the whole edac area, makes me
> not wonderfully happy about pulling directly. I a.lso see another edac
> pull request in my mailbox, making me suspect that there are
> maintainership problems (historically I've been getting the code
> either though Greg, Borislav or Mauro). So I'd also like to make sure
> that I at least _know_ about any disputes going on in this area?
> 
> So before I pull this, I'd quickly like to validate the gpg key, and
> am cc'ing more people to see if I'm stepping into some political
> nightmare. I can be ok with that, but I want to do so knowingly, not
> blindly..

I thought Doug was the maintainer of EDAC (now added to the to:), and
Mauro has been doing a bunch of work there, while he was at Red Hat.  I
haven't taken any EDAC patches in a while since Mauro started cleaning
up the area, so I don't know anything about this, sorry.

Doug?

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Borislav Petkov]

On Thu, Nov 14, 2013 at 02:47:50PM +0900, Greg Kroah-Hartman wrote:
> On Thu, Nov 14, 2013 at 02:41:24PM +0900, Linus Torvalds wrote:
> > On Wed, Nov 13, 2013 at 1:19 AM, Johannes Thumshirn
> > <johannes.thumshirn@men.de> wrote:
> > >
> > >   git://github.com/morbidrsa/linux.git tags/mpc85xx-edac-for-3.13
> > 
> > Ok, it's a signed tag, but I haven't pulled from you before (all the
> > commits I see seem to have gone through Greg), and I don't recognize
> > any of the signatures on your tag.
> > 
> > That, together with not really knowing the whole edac area, makes me
> > not wonderfully happy about pulling directly. I a.lso see another edac
> > pull request in my mailbox, making me suspect that there are
> > maintainership problems (historically I've been getting the code
> > either though Greg, Borislav or Mauro). So I'd also like to make sure
> > that I at least _know_ about any disputes going on in this area?
> > 
> > So before I pull this, I'd quickly like to validate the gpg key, and
> > am cc'ing more people to see if I'm stepping into some political
> > nightmare. I can be ok with that, but I want to do so knowingly, not
> > blindly..
> 
> I thought Doug was the maintainer of EDAC (now added to the to:), and
> Mauro has been doing a bunch of work there, while he was at Red Hat.  I
> haven't taken any EDAC patches in a while since Mauro started cleaning
> up the area, so I don't know anything about this, sorry.

Ok, let me try to explain the deal as I see it:

The original EDAC maintainer was/is Doug. I say is, because he told me
recently, he wants to get involved and collect stuff again.

Now, what we have been doing so far in the interim couple of years while
Doug was away is both Mauro and me have been sending the patches for
those EDAC drivers each of us maintains directly to Linus. I have also
been trying to collect stuff for other EDAC drivers and I know Mauro has
been doing that too, but, at least in my case, I was paying attention
*not* to step into the role of maintainer for the whole EDAC subsystem.

Here are my reasons why: Those drivers are for all kinds of arches for
which I certainly don't have the hardware to test patches on, and, in
some cases, even the people who wrote them disappear/go do something
else and thus it is really hard to get someone with the hardware to
atleast test the patch before I collect it.

So what I told Robert Richter (he sent you the pull request for
Calxeda Highbank) and Johannes Thumshirn (who volunteered to maintain
mpc85xx_edac.* because he has the hardware and needs it for work) was to
send pull requests straight to Linus.

In Robert's case, you have him in the chain of trust from previous
work and since he works for Calxeda now, you basically have the vendor
maintaining its own driver.

Johannes I told that he needs to get his key signed by a couple of
kernel devs but he hasn't had the time to go meet them and do that yet.

I know what you're gonna say now, you probably would like to pull from
only 1 or 2 EDAC maintainers tops and not from every driver maintainer.

I guess we can work with this temporary solution until Doug takes over
or, if he doesn't, come up with one maintainer who simply funnels stuff
to you. For example, I could do that but only with the drivers where I
have people with the hardware who can test and fix bugs - I don't want
any half-baked patches which fix hearsay bugs or brown-paper bags. I
certainly don't have the volume to review more involved patches for
other drivers so if we do this, I'll have to have people who ack them
and fix them when there's trouble.

You let me know what you would prefer and we will work something out.

Thanks!

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Mauro Carvalho Chehab]

Em Thu, 14 Nov 2013 10:20:10 +0100
Borislav Petkov <bp@suse.de> escreveu:

> On Thu, Nov 14, 2013 at 02:47:50PM +0900, Greg Kroah-Hartman wrote:
> > On Thu, Nov 14, 2013 at 02:41:24PM +0900, Linus Torvalds wrote:
> > > On Wed, Nov 13, 2013 at 1:19 AM, Johannes Thumshirn
> > > <johannes.thumshirn@men.de> wrote:
> > > >
> > > >   git://github.com/morbidrsa/linux.git tags/mpc85xx-edac-for-3.13
> > > 
> > > Ok, it's a signed tag, but I haven't pulled from you before (all the
> > > commits I see seem to have gone through Greg), and I don't recognize
> > > any of the signatures on your tag.
> > > 
> > > That, together with not really knowing the whole edac area, makes me
> > > not wonderfully happy about pulling directly. I a.lso see another edac
> > > pull request in my mailbox, making me suspect that there are
> > > maintainership problems (historically I've been getting the code
> > > either though Greg, Borislav or Mauro). So I'd also like to make sure
> > > that I at least _know_ about any disputes going on in this area?
> > > 
> > > So before I pull this, I'd quickly like to validate the gpg key, and
> > > am cc'ing more people to see if I'm stepping into some political
> > > nightmare. I can be ok with that, but I want to do so knowingly, not
> > > blindly..
> > 
> > I thought Doug was the maintainer of EDAC (now added to the to:), and
> > Mauro has been doing a bunch of work there, while he was at Red Hat.  I
> > haven't taken any EDAC patches in a while since Mauro started cleaning
> > up the area, so I don't know anything about this, sorry.
> 
> Ok, let me try to explain the deal as I see it:
> 
> The original EDAC maintainer was/is Doug. I say is, because he told me
> recently, he wants to get involved and collect stuff again.
> 
> Now, what we have been doing so far in the interim couple of years while
> Doug was away is both Mauro and me have been sending the patches for
> those EDAC drivers each of us maintains directly to Linus. I have also
> been trying to collect stuff for other EDAC drivers and I know Mauro has
> been doing that too, but, at least in my case, I was paying attention
> *not* to step into the role of maintainer for the whole EDAC subsystem.
> 
> Here are my reasons why: Those drivers are for all kinds of arches for
> which I certainly don't have the hardware to test patches on, and, in
> some cases, even the people who wrote them disappear/go do something
> else and thus it is really hard to get someone with the hardware to
> atleast test the patch before I collect it.
> 
> So what I told Robert Richter (he sent you the pull request for
> Calxeda Highbank) and Johannes Thumshirn (who volunteered to maintain
> mpc85xx_edac.* because he has the hardware and needs it for work) was to
> send pull requests straight to Linus.
> 
> In Robert's case, you have him in the chain of trust from previous
> work and since he works for Calxeda now, you basically have the vendor
> maintaining its own driver.
> 
> Johannes I told that he needs to get his key signed by a couple of
> kernel devs but he hasn't had the time to go meet them and do that yet.
> 
> I know what you're gonna say now, you probably would like to pull from
> only 1 or 2 EDAC maintainers tops and not from every driver maintainer.
> 
> I guess we can work with this temporary solution until Doug takes over
> or, if he doesn't, come up with one maintainer who simply funnels stuff
> to you. For example, I could do that but only with the drivers where I
> have people with the hardware who can test and fix bugs - I don't want
> any half-baked patches which fix hearsay bugs or brown-paper bags. I
> certainly don't have the volume to review more involved patches for
> other drivers so if we do this, I'll have to have people who ack them
> and fix them when there's trouble.
> 
> You let me know what you would prefer and we will work something out.

As Boris said, the official maintainer is Doug, but he is not being
active over the last couple years or so.

As I was actively writing new EDAC drivers and needed to rewrite
the core part of the subsystem, in order for it to properly work with
Intel modern memory controllers/CPUs, I was submitting the patches
to you directly. In the beginning, I was waiting for Doug's ack before
doing that. After he stopped answering emails, I kept him c/c for at 
least a couple Kernel versions. After that, I started to just c/c the
Mailing lists.

I also took the care to not step on Boris, with actively maintains the
amd64_edac driver. So, I only applied on my tree patches from the
AMD64 EDAC driver with his ack.

So, in practice, Borislav was working as a maintainer for amd64 EDAC
patches, and I working mainly as Intel EDAC maintainer. The (few) other
arm EDAC patches were either coming via my tree or via Boris tree,
depending on who got them first.

That's said, while working at Red Hat, I had access to a large number of
different hardware. So, I was capable of testing the changes on most x86
hardware supported. I also wrote some testing procedures while there, in
order to use Red Hat lab to test EDAC on all hardware that supports EDAC
we found there. Several bugs were corrected on those drivers due to that.

Nowadays, I'm still actively maintaining an userspace counterpart of the
EDAC subsystem[1], but I have access to just one hardware (a Sandy Bridge
Xeon machine). Currently, I'm not working on any new EDAC driver, although
I expect to have some new EDAC projects for the next year.

[1] https://git.fedorahosted.org/git/rasdaemon.git

Also, Aristeu asked me this week to merge some Ivy Bridge EDAC patches he
submitted in the past to the EDAC ML on my tree and forward them to you.

So, if you want, I can review the pending EDAC patches, apply them on
my tree and sending you a pull request, working as a maintainer, while
we don't have some full time maintainer for it.

Regards,
Mauro

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Borislav Petkov]

On Thu, Nov 14, 2013 at 09:18:43AM -0200, Mauro Carvalho Chehab wrote:
> So, in practice, Borislav was working as a maintainer for amd64 EDAC
> patches, and I working mainly as Intel EDAC maintainer. The (few)
> other arm EDAC patches were either coming via my tree or via Boris
> tree, depending on who got them first.

Yeah, and I think this has worked pretty good in the past so if you want
to, we can continue the same thing of sharing the load on EDAC patches
and we both do interim maintainers until Doug steps in.

And since it won't change any workflow for Linus, he's probably fine
with it too.

Yes, no? Comments?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Robert Richter]

On 14.11.13 12:24:18, Borislav Petkov wrote:
> On Thu, Nov 14, 2013 at 09:18:43AM -0200, Mauro Carvalho Chehab wrote:
> > So, in practice, Borislav was working as a maintainer for amd64 EDAC
> > patches, and I working mainly as Intel EDAC maintainer. The (few)
> > other arm EDAC patches were either coming via my tree or via Boris
> > tree, depending on who got them first.
> 
> Yeah, and I think this has worked pretty good in the past so if you want
> to, we can continue the same thing of sharing the load on EDAC patches
> and we both do interim maintainers until Doug steps in.
> 
> And since it won't change any workflow for Linus, he's probably fine
> with it too.
> 
> Yes, no? Comments?

There will be some upcomming arm/arm64 specific changes which might
effect also the core driver in the future. I would be willing to
collect and send these ones upstream in coordination with you.

Thanks,

-Robert

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Johannes Thumshirn]

On Thu, Nov 14, 2013 at 12:24:18PM +0100, Borislav Petkov wrote:
> On Thu, Nov 14, 2013 at 09:18:43AM -0200, Mauro Carvalho Chehab wrote:
> > So, in practice, Borislav was working as a maintainer for amd64 EDAC
> > patches, and I working mainly as Intel EDAC maintainer. The (few)
> > other arm EDAC patches were either coming via my tree or via Boris
> > tree, depending on who got them first.
>
> Yeah, and I think this has worked pretty good in the past so if you want
> to, we can continue the same thing of sharing the load on EDAC patches
> and we both do interim maintainers until Doug steps in.
>
> And since it won't change any workflow for Linus, he's probably fine
> with it too.
>
> Yes, no? Comments?

OK for me. For the MPC85xx EDAC I'll do the testing then and either Borislav or
Mauro send them upstream.

Regards,
	Johannes

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Mauro Carvalho Chehab]

Em Thu, 14 Nov 2013 15:21:25 +0100
Johannes Thumshirn <johannes.thumshirn@men.de> escreveu:

> On Thu, Nov 14, 2013 at 12:24:18PM +0100, Borislav Petkov wrote:
> > On Thu, Nov 14, 2013 at 09:18:43AM -0200, Mauro Carvalho Chehab wrote:
> > > So, in practice, Borislav was working as a maintainer for amd64 EDAC
> > > patches, and I working mainly as Intel EDAC maintainer. The (few)
> > > other arm EDAC patches were either coming via my tree or via Boris
> > > tree, depending on who got them first.
> >
> > Yeah, and I think this has worked pretty good in the past

Fully agreed.

> > so if you want
> > to, we can continue the same thing of sharing the load on EDAC patches
> > and we both do interim maintainers until Doug steps in.

Works for me.

> >
> > And since it won't change any workflow for Linus, he's probably fine
> > with it too.
> >
> > Yes, no? Comments?
> 
> OK for me. For the MPC85xx EDAC I'll do the testing then and either Borislav or
> Mauro send them upstream.

Ok.

Regards,
Mauro

Re: [GIT PULL] mpc85xx_edac changes for 3.13

[Borislav Petkov]

On Thu, Nov 14, 2013 at 03:21:25PM +0100, Johannes Thumshirn wrote:
> OK for me. For the MPC85xx EDAC I'll do the testing then and either
> Borislav or Mauro send them upstream.

Btw, would you send the patches to the list so that I can pick them up?

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--