* [GIT PULL] mpc85xx_edac changes for 3.13 @ 2013-11-12 16:19 Johannes Thumshirn 2013-11-14 5:41 ` Linus Torvalds 0 siblings, 1 reply; 10+ messages in thread From: Johannes Thumshirn @ 2013-11-12 16:19 UTC (permalink / raw) To: torvalds; +Cc: linux-kernel, linux-edac 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; ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-12 16:19 [GIT PULL] mpc85xx_edac changes for 3.13 Johannes Thumshirn @ 2013-11-14 5:41 ` Linus Torvalds 2013-11-14 5:47 ` Greg Kroah-Hartman 0 siblings, 1 reply; 10+ messages in thread From: Linus Torvalds @ 2013-11-14 5:41 UTC (permalink / raw) To: Johannes Thumshirn, Greg Kroah-Hartman, Borislav Petkov, Mauro Carvalho Chehab, Robert Richter Cc: Linux Kernel Mailing List, linux-edac 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-14 5:41 ` Linus Torvalds @ 2013-11-14 5:47 ` Greg Kroah-Hartman 2013-11-14 9:20 ` Borislav Petkov 0 siblings, 1 reply; 10+ messages in thread From: Greg Kroah-Hartman @ 2013-11-14 5:47 UTC (permalink / raw) To: Linus Torvalds, Doug Thompson Cc: Johannes Thumshirn, Borislav Petkov, Mauro Carvalho Chehab, Robert Richter, Linux Kernel Mailing List, linux-edac 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-14 5:47 ` Greg Kroah-Hartman @ 2013-11-14 9:20 ` Borislav Petkov 2013-11-14 11:18 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 10+ messages in thread From: Borislav Petkov @ 2013-11-14 9:20 UTC (permalink / raw) To: Greg Kroah-Hartman, Linus Torvalds Cc: Doug Thompson, Johannes Thumshirn, Borislav Petkov, Mauro Carvalho Chehab, Robert Richter, Linux Kernel Mailing List, linux-edac 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. -- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-14 9:20 ` Borislav Petkov @ 2013-11-14 11:18 ` Mauro Carvalho Chehab 2013-11-14 11:24 ` Borislav Petkov 0 siblings, 1 reply; 10+ messages in thread From: Mauro Carvalho Chehab @ 2013-11-14 11:18 UTC (permalink / raw) To: Linus Torvalds Cc: Borislav Petkov, Greg Kroah-Hartman, Doug Thompson, Johannes Thumshirn, Robert Richter, Linux Kernel Mailing List, linux-edac, Aristeu Rozanski Filho 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-14 11:18 ` Mauro Carvalho Chehab @ 2013-11-14 11:24 ` Borislav Petkov 2013-11-14 12:13 ` Robert Richter 2013-11-14 14:21 ` Johannes Thumshirn 0 siblings, 2 replies; 10+ messages in thread From: Borislav Petkov @ 2013-11-14 11:24 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Linus Torvalds, Borislav Petkov, Greg Kroah-Hartman, Doug Thompson, Johannes Thumshirn, Robert Richter, Linux Kernel Mailing List, linux-edac, Aristeu Rozanski Filho 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. -- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-14 11:24 ` Borislav Petkov @ 2013-11-14 12:13 ` Robert Richter 2013-11-14 14:21 ` Johannes Thumshirn 1 sibling, 0 replies; 10+ messages in thread From: Robert Richter @ 2013-11-14 12:13 UTC (permalink / raw) To: Borislav Petkov Cc: Mauro Carvalho Chehab, Linus Torvalds, Borislav Petkov, Greg Kroah-Hartman, Doug Thompson, Johannes Thumshirn, Linux Kernel Mailing List, linux-edac, Aristeu Rozanski Filho 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-14 11:24 ` Borislav Petkov 2013-11-14 12:13 ` Robert Richter @ 2013-11-14 14:21 ` Johannes Thumshirn 2013-11-14 17:08 ` Mauro Carvalho Chehab 2013-11-14 18:30 ` Borislav Petkov 1 sibling, 2 replies; 10+ messages in thread From: Johannes Thumshirn @ 2013-11-14 14:21 UTC (permalink / raw) To: Borislav Petkov Cc: Mauro Carvalho Chehab, Linus Torvalds, Borislav Petkov, Greg Kroah-Hartman, Doug Thompson, Johannes Thumshirn, Robert Richter, Linux Kernel Mailing List, linux-edac, Aristeu Rozanski Filho 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-14 14:21 ` Johannes Thumshirn @ 2013-11-14 17:08 ` Mauro Carvalho Chehab 2013-11-14 18:30 ` Borislav Petkov 1 sibling, 0 replies; 10+ messages in thread From: Mauro Carvalho Chehab @ 2013-11-14 17:08 UTC (permalink / raw) To: Johannes Thumshirn Cc: Borislav Petkov, Linus Torvalds, Borislav Petkov, Greg Kroah-Hartman, Doug Thompson, Robert Richter, Linux Kernel Mailing List, linux-edac, Aristeu Rozanski Filho 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT PULL] mpc85xx_edac changes for 3.13 2013-11-14 14:21 ` Johannes Thumshirn 2013-11-14 17:08 ` Mauro Carvalho Chehab @ 2013-11-14 18:30 ` Borislav Petkov 1 sibling, 0 replies; 10+ messages in thread From: Borislav Petkov @ 2013-11-14 18:30 UTC (permalink / raw) To: Johannes Thumshirn Cc: Mauro Carvalho Chehab, Linus Torvalds, Borislav Petkov, Greg Kroah-Hartman, Doug Thompson, Robert Richter, Linux Kernel Mailing List, linux-edac, Aristeu Rozanski Filho 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. -- ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-11-14 18:31 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-12 16:19 [GIT PULL] mpc85xx_edac changes for 3.13 Johannes Thumshirn 2013-11-14 5:41 ` Linus Torvalds 2013-11-14 5:47 ` Greg Kroah-Hartman 2013-11-14 9:20 ` Borislav Petkov 2013-11-14 11:18 ` Mauro Carvalho Chehab 2013-11-14 11:24 ` Borislav Petkov 2013-11-14 12:13 ` Robert Richter 2013-11-14 14:21 ` Johannes Thumshirn 2013-11-14 17:08 ` Mauro Carvalho Chehab 2013-11-14 18:30 ` Borislav Petkov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.