[PATCH 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

function is not reachable on PowerPC pSeries platform during Open Firmware PCI probing time. This patch calls pci_msi_setup_pci_dev() explicitly to disable MSI/MSI-X during PCI probe time on pSeries platform. Signed-off-by: Guilherme G. Piccoli gpicc...@linux.vnet.ibm.com --- arch/powerpc/kernel

[PATCH v2 1/2] PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code

. To fix this, the pseries PCI probe should manually call pci_msi_setup_pci_dev(), so this patch makes it non-static. Fixes: 1851617cd2da (PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI) Signed-off-by: Guilherme G. Piccoli gpicc...@linux.vnet.ibm.com --- drivers/pci/probe.c

[PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

on pSeries platform. Fixes: 1851617cd2da (PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI) Signed-off-by: Guilherme G. Piccoli gpicc...@linux.vnet.ibm.com --- arch/powerpc/kernel/pci_of_scan.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kernel

[PATCH 0/2] Disable MSI/MSI-X interrupts manually at PCI probe time in PowerPC architecture

disables MSI/MSI-X interrupts at PCI probe time. Guilherme G. Piccoli (2): PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case arch/powerpc/kernel/pci_of_scan.c | 3 +++ drivers/pci/probe.c | 2

Re: [PATCH v2 1/2] PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code

On 08/24/2015 04:37 AM, Michael Ellerman wrote: more: I was testing driver issues on kernel 2.6.32 (RHEL 6.6), and when I tried the mainline kernel, the driver wasn't able to enable MSI-X capabilities. Interestingly, on kernel 4.1 this behavior doesn't happen and the driver can use MSI-X

[PATCH 1/2] PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code

-static, so that it will be called on PCI probe path on powerpc pSeries platform in next patch. Signed-off-by: Guilherme G. Piccoli gpicc...@linux.vnet.ibm.com --- drivers/pci/probe.c | 2 +- include/linux/pci.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci

Re: [PATCH v2 1/2] PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code

On 08/19/2015 10:02 PM, Michael Ellerman wrote: In future you should send a reply like the above to my mail, and then separately send the new patch series. My preference is that the new series is not a reply to anything, though some other maintainers may disagree on that point. OK, sure. I can

[PATCH] Enable MSI/MSI-X caps and disable MSI interrupts at PCI probe time - code move

() directly from pci_init_capabilities(). Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/pci_of_scan.c | 3 --- drivers/pci/probe.c | 5 +++-- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/pci_o

Re: [PATCH] Enable MSI/MSI-X caps and disable MSI interrupts at PCI probe time - code move

Bjorn, ping? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

On 09/15/2015 01:18 PM, Bjorn Helgaas wrote: We could also argue that when CONFIG_PCI_MSI=n, dev->msi[x]_cap should not even exist, so we could catch that a build-time instead of run-time. My personal opinion is that it's not a big deal, and the existing code that includes dev->msi[x]_cap and

Re: [PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

On Sun, 2015-09-06 at 17:44 +0300, Michael S. Tsirkin wrote: My question is: is necessary to initialize MSI capabilities even with CONFIG_PCI_MSI not set? In negative case, would be "cleaner" revert the 3 commits, right? I think the reason why it's necessary is explained in commit log for

Re: [PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

On 09/07/2015 12:10 AM, Michael Ellerman wrote: But we later removed pci_msi_off() completely, so I think we probably *could* call pci_msi_setup_pci_dev() from pci_init_capabilities(). That would be much nicer because it makes more sense there, and it would do the right thing for powerpc and

Re: [PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

Hello Bjorn, of_create_pci_dev() already has a lot of code that duplicates pci_setup_device(), and it's a shame to add more. There's also a sparc version of of_create_pci_dev() that presumably has the same problem you're fixing for powerpc. Thanks for the information! Michael originally

[PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

r. Fixes: 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell") Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/eeh.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/eeh.c b/

Re: [PATCH] Enable MSI/MSI-X caps and disable MSI interrupts at PCI probe time - code move

On 11/24/2015 07:23 PM, Bjorn Helgaas wrote: On Wed, Nov 04, 2015 at 10:00:15AM -0200, Guilherme G. Piccoli wrote: Bjorn, ping? Sorry, Guilherme, this dropped off my radar, and I can't remember why. I'll take a look at it soon. Bjorn Thanks very much Bjorn! Sorry to bother, by the way

Re: [PATCH] Enable MSI/MSI-X caps and disable MSI interrupts at PCI probe time - code move

On 10/21/2015 12:17 PM, Guilherme G. Piccoli wrote: Commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI") changed the location of the code that initializes dev->msi_cap/msix_cap and disables MSI/MSI-X interrupts at PCI probe time in devi

Re: [PATCH] Enable MSI/MSI-X caps and disable MSI interrupts at PCI probe time - code move

n't make sense: The patch below is great, thanks for the modifications and for removing pci_msi_init_pci_dev() in a separated patch. commit e80e7edc55ba711f3fe23975061b3f1c336ceb95 Author: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> Date: Wed Oct 21 12:17:35 2015 -0200

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

On 01/13/2016 08:38 AM, Michael Ellerman wrote: But eeh_enabled() is still false? That seems like it's liable to cause breakage elsewhere. Yes, eeh_enabled() is false as expected. Notice that eeh_enabled() is telling if EEH is enabled or not, and since it's not (because there's no PCI

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

On 01/13/2016 04:04 AM, Benjamin Herrenschmidt wrote: On Sun, 2016-01-10 at 01:08 -0200, Guilherme G. Piccoli wrote:weust changes the way the arch checking is done in function This patch jeeh_add_device_early(): we use no more eeh_enabled(), but instead we check the running architecture

Re: [PATCH v2] powerpc: export cpu_to_core_id()

an add: "Tested-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com>" Cheers, Guilherme ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

On 01/13/2016 07:25 PM, Michael Ellerman wrote: But for example what happens if the user boots with eeh=off on the command line, and then hotplugs a device. It looks like because you're not using eeh_enabled() you will incorrectly initialise EEH anyway? Thanks very much for this catch Michael!

Re: [PATCH 0/2] Two patches regarding EEH availability checks - DLPAR/DDW

Hello Michael and Benjamin, any news on this one? Quick correction in this email subject: it was cropped because it's too long. The full title was "[PATCH 0/2] Two patches regarding EEH availability checks - DLPAR/DDW crash avoidance" ___

Re: [PATCH 1/2] powerpc/eeh: Check for EEH availability in eeh_add_device_early()

On 02/02/2016 08:44 PM, Gavin Shan wrote: /** + * eeh_available - Checks for the availability of EEH based on running + * architecture. + * + * This routine should be used in case we need to check if EEH is + * available in some situation, regardless if EEH is enabled or not. + * For example, if

Re: [PATCH 2/2] powerpc/pseries: Check if EEH is enabled on DDW mechanism code

On 02/02/2016 09:48 PM, Gavin Shan wrote: On Tue, Jan 19, 2016 at 06:18:20PM -0200, Guilherme G. Piccoli wrote: - /* only attempt to use a new window if 64-bit DMA is requested */ - if (!disable_ddw && dma_mask == DMA_BIT_MASK(64)) { + /* We should check if EEH is enab

[PATCH 0/2] Two patches regarding EEH availability checks - DLPAR/DDW

ce probe caused by DDW trying to use EEH struct. The 2nd patch in this series inserts a check based on eeh_enabled() function, so the DDW mechanism safely fallbacks to non-dynamic iommu if EEH is not enabled. Guilherme G. Piccoli (2): powerpc/eeh: Check for EEH availability in eeh_add_device

[PATCH 1/2] powerpc/eeh: Check for EEH availability in eeh_add_device_early()

ized yet). This way, we don't try to enable EEH on Cell and we don't hit the oops on DLPAR either. Fixes: 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell") Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/eeh.c | 19

[PATCH 2/2] powerpc/pseries: Check if EEH is enabled on DDW mechanism code

-line ("eeh=off") - without the patch, a device probe can hit a kernel oops because EEH is disabled but DDW will try to use it. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/platforms/pseries/iommu.c | 6 -- 1 file changed, 4 insertions

Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()

On 01/14/2016 09:37 PM, Michael Ellerman wrote: So, since my patch does not cover this case, I think would be more interesting "unlink" the DDW mechanism from the EEH. It seems easy, I'll try to send you a patch soon. Do you think it is a good approach? It sounds good, but I don't know off

[PATCH] Reuse PHB/domain number on PCI adresses when available

and PCI list, so we can be sure this modification, if accepted, won't impact any other related area. Thanks in advance, Guilherme Guilherme G. Piccoli (1): powerpc/pci: Reuse PHB number on pci_controller add if available arch/powerpc/kernel/pci-common.c | 47

[PATCH] powerpc/pci: Reuse PHB number on pci_controller add if available

finds a free domain, it will use its number; otherwise a new number is generated incrementing the higher domain value present on the system. No functional changes were introduced. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/pci-common.

Re: [PATCH v2] powerpc/pci: Assign fixed PHB number based on device-tree properties

Thanks very much for the comments Gavin! I agree with all of them, will rework the patch and send a new version. Cheers, Guilherme ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] powerpc/pci: Assign fixed PHB number based on device-tree properties

-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/pci-common.c | 43 +--- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 0f7a60f..d4217f9 100644 ---

Re: [PATCH] powerpc/pci: Reuse PHB number on pci_controller add if available

On 03/11/2016 10:14 AM, Gavin Shan wrote: Yeah, the BUID is PHB's identifier, but we only need the low 16-bits as its base is 0x8002000ULL in QEMU or pHyp. I think other platforms (like freescale's) still need dynamically allocated domain number, which could be managed by a bitmap.

[PATCH v3] powerpc/pci: Assign fixed PHB number based on device-tree properties

-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/pci-common.c | 41 +--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c index 0f7a60f..8777614 100644 ---

Re: [PATCH v4] powerpc/pci: Assign fixed PHB number based on device-tree properties

On 04/06/2016 04:38 PM, Ian Munsie wrote: +/* try fixed PHB numbering first, by checking archs and reading + * the respective device-tree property. */ +if (machine_is(pseries)) { +regs = of_get_property(dn, "reg", NULL); +if (regs) +return

[PATCH 2/2 v2] powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism

dn members instead of using eeh_dev-based address. No functional changes were made. This was tested on pSeries, both in PHyp and qemu guest. Fixes: 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn") Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch

[PATCH 1/2 v2] Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"

introduced by the commit d91dafc02f42 ("powerpc/eeh: Delay probing EEH device during hotplug") and so the original Cell issue does not happen anymore. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/eeh.c | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCH 2/2] powerpc/pseries: Check if EEH is enabled on DDW mechanism code

On 02/04/2016 03:30 AM, Gavin Shan wrote: On Wed, Feb 03, 2016 at 10:26:36AM -0200, Guilherme G. Piccoli wrote: On 02/02/2016 09:48 PM, Gavin Shan wrote: Gavin, thanks very much for the clarification. So, we can interchange edev->config_addr with pdn->pci_ext_config_space ? This would

Re: [PATCH 2/2 v2] powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism

On 04/06/2016 09:48 PM, Gavin Shan wrote: On Wed, Apr 06, 2016 at 09:20:05PM -0300, Guilherme G. Piccoli wrote: Fixes: 39baadbf36ce ("powerpc/eeh: Remove eeh information from pci_dn") Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> Reviewed-by:

[PATCH 1/2 v3] Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"

introduced by the commit d91dafc02f42 ("powerpc/eeh: Delay probing EEH device during hotplug") and so the original Cell issue does not happen anymore. Cc: sta...@vger.kernel.org Reviewed-by: Gavin Shan <gws...@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vn

[PATCH 2/2 v3] powerpc/iommu: Remove the dependency on EEH struct in DDW mechanism

net.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/platforms/pseries/iommu.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu

Re: [PATCH v3] powerpc/pci: Assign fixed PHB number based on device-tree properties

On 03/18/2016 01:00 AM, Gavin Shan wrote: Apart from below minor issues to be fixed, it looks good to me. Reviewed-by: Gavin Shan Thanks for the review Gavin, I'll fix the else/if detail and send a v4. + } else { + if (machine_is(powernv)) {

[PATCH v4] powerpc/pci: Assign fixed PHB number based on device-tree properties

Shan <gws...@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/pci-common.c | 40 +--- 1 file changed, 37 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/pci-common.c b/arch/po

Re: [v4] powerpc/pci: Assign fixed PHB number based on device-tree properties

On 03/25/2016 06:33 AM, Michael Ellerman wrote: Hi Guilherme, Some comments below ... Hi Michael, thanks for the comments. +/* For dynamic PHB numbering on get_phb_number(): max number of PHBs. */ +#defineMAX_PHBS8192 Did we just make that up? It seems like a lot, but

[PATCH v6] powerpc/pci: Assign fixed PHB number based on device-tree properties

G. Piccoli <gpicc...@linux.vnet.ibm.com> Reviewed-by: Gavin Shan <gws...@linux.vnet.ibm.com> Reviewed-by: Ian Munsie <imun...@au1.ibm.com> --- v6: * Dropped the of_get_property() use to use instead of_property_read_u64()/of_property_read_u32_array as per Michael's suggest

Re: [PATCH v5] powerpc/pci: Assign fixed PHB number based on device-tree properties

On 05/02/2016 01:57 PM, Bjorn Helgaas wrote: On Thu, Apr 14, 2016 at 06:55:24PM -0300, Guilherme G. Piccoli wrote: The domain/PHB field of PCI addresses has its value obtained from a global variable, incremented each time a new domain (represented by struct pci_controller) is added

[PATCH v5] powerpc/pci: Assign fixed PHB number based on device-tree properties

Shan <gws...@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/pci-common.c | 66 ++-- 1 file changed, 63 insertions(+), 3 deletions(-) v5: * Improved comments. * Changed the the Fixed P

Re: [PATCH v5] powerpc/pci: Assign fixed PHB number based on device-tree properties

On 04/19/2016 04:27 AM, Ian Munsie wrote: Thanks for addressing my feedback :) Reviewed-by: Ian Munsie Thanks very much for reviewing Ian =) Cheers, Guilherme ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [v6] powerpc/pci: Assign fixed PHB number based on device-tree properties

On 05/25/2016 03:26 AM, Michael Ellerman wrote: On Wed, 2016-18-05 at 01:48:00 UTC, "Guilherme G. Piccoli" wrote: The domain/PHB field of PCI addresses has its value obtained from a global variable, incremented each time a new domain (represented by struct pci_controller) is added on

Re: [v4] powerpc/pci: Assign fixed PHB number based on device-tree properties

On 05/25/2016 02:45 AM, Michael Ellerman wrote: Hi Guilherme, Sorry for the very late reply, this got lost in my email filters. No problem Michael, thanks for replying! On Mon, 2016-03-28 at 09:36 -0300, Guilherme G. Piccoli wrote: On 03/25/2016 06:33 AM, Michael Ellerman wrote

[PATCH] powerpc/eeh: trivial fix to non-conventional PCI address output on EEH log

inted as usual. No functional changes were introduced. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/kernel/eeh.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c index c9bc78

Re: [PATCH] powerpc/eeh: trivial fix to non-conventional PCI address output on EEH log

On 07/24/2016 10:46 PM, Gavin Shan wrote: On Mon, Jul 25, 2016 at 10:47:13AM +1000, Michael Ellerman wrote: "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: This is a very minor/trivial fix for the output of PCI address on EEH logs. The PCI address on "OF

Re: [PATCH] powerpc/eeh: trivial fix to non-conventional PCI address output on EEH log

On 07/24/2016 09:47 PM, Michael Ellerman wrote: "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: This is a very minor/trivial fix for the output of PCI address on EEH logs. The PCI address on "OF node" field currently is using ":" as a separ

Re: [PATCH] powerpc/pci: Only do fixed PHB numbering on powernv

On 08/08/2016 09:32 PM, Michael Ellerman wrote: "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: On 08/07/2016 08:48 PM, Gavin Shan wrote: On Fri, Aug 05, 2016 at 04:40:56PM +1000, Michael Ellerman wrote: The recent commit 63a72284b159 ("powerpc/pci: Assign f

Re: [PATCH] powerpc/pci: Only do fixed PHB numbering on powernv

On 08/09/2016 01:44 AM, Michael Ellerman wrote: "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: On 08/08/2016 09:32 PM, Michael Ellerman wrote: "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: (i) What is the specific issue? D

Re: [PATCH] powerpc/pci: Only do fixed PHB numbering on powernv

On 08/07/2016 08:48 PM, Gavin Shan wrote: On Fri, Aug 05, 2016 at 04:40:56PM +1000, Michael Ellerman wrote: The recent commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties"), added code to read a 64-bit property from the device tree, and if not found read a

Re: [PATCH] powerpc/eeh: trivial fix to non-conventional PCI address output on EEH log

On 07/24/2016 10:46 PM, Gavin Shan wrote: On Mon, Jul 25, 2016 at 10:47:13AM +1000, Michael Ellerman wrote: "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: This is a very minor/trivial fix for the output of PCI address on EEH logs. The PCI address on "OF

[PATCH v7] powerpc/pci: Assign fixed PHB number based on device-tree properties

G. Piccoli <gpicc...@linux.vnet.ibm.com> Reviewed-by: Gavin Shan <gws...@linux.vnet.ibm.com> Reviewed-by: Ian Munsie <imun...@au1.ibm.com> --- v7: * Removed the goto as per Michael's suggestion; * Changed of_property_read_u32_array() to of_property_read_u32_index

Re: [PATCH 2/3] powerpc/xmon: drop the nobt option from xmon plus minor fixes

On 02/21/2017 02:16 AM, Michael Ellerman wrote: > "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: >> Subject: Re: [PATCH 2/3] powerpc/xmon: drop the nobt option from xmon plus >> minor fixes > > In future please use the same version number f

Re: [PATCH 2/3] powerpc/xmon: drop the nobt option from xmon plus minor fixes

On 02/21/2017 02:33 AM, Michael Ellerman wrote: > Michael Ellerman <m...@ellerman.id.au> writes: >> "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: > ... >> >> Imagine you're debugging a machine and you drop into xmon to check >> so

[PATCH v2 0/3] powerpc/xmon: improvements and fixes

xmon without needing a kernel reload. 3) The nobt option was dropped and some minor issues were fixed, like a misplacement of __initdata. @mpe: The series was rebased against powerpc-next. Guilherme G. Piccoli (2): powerpc/xmon: drop the nobt option from xmon plus minor fixes powerpc/xmon: add

Re: [PATCH 0/3] powerpc/xmon: improvements and fixes

New version of the series was sent, please ignore this one. Thanks, Guilherme

[PATCH v3 3/3] powerpc/xmon: add debugfs entry for xmon

Writing these states to the file will take immediate effect in the debugger. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- v3: logic improved based in the changes made on patch 1. v2: dropped the custom parser by using simple attributes [mpe suggestion]. arc

[PATCH 2/3] powerpc/xmon: drop the nobt option from xmon plus minor fixes

__initcall() with modern device_initcall() on sysrq handler. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/xmon/xmon.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon

[PATCH v3 1/3] powerpc/xmon: Fix an unexpected xmon on/off state change

ed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- v3: changed xmon_off to xmon_on, simplifying the logic [mpe suggestion]. arch/powerpc/xmon/xmon.c | 17 ++--- 1 file changed, 10 insertions(+), 7

[PATCH 2/3] powerpc/xmon: drop the nobt option from xmon plus minor fixes

__initcall() with modern device_initcall() on sysrq handler. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/xmon/xmon.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon

[PATCH v2 3/3] powerpc/xmon: add debugfs entry for xmon

Writing these states to the file will take immediate effect on the debugger. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- v2: dropped the custom parser by using simple attributes [mpe suggestion]. arch/powerpc/xmon/xmon.c | 31 +++ 1 f

[PATCH v2 1/3] powerpc/xmon: Fix an unexpected xmon on/off state change

and 2. Signed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- arch/powerpc/xmon/xmon.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xm

[PATCH 0/3] powerpc/xmon: improvements and fixes

/disable xmon without need a kernel reload. 3) The nobt option was dropped and some minor issues were fixed, like a misplacement of __initdata. @Pan Xinhui: I did a minor modification in your commit message, feel free to improve it if you think it isn't ok. Thanks! Guilherme G. Piccoli (2

Re: [PATCH v3 3/3] powerpc/xmon: add debugfs entry for xmon

On 02/21/2017 03:35 AM, Pan Xinhui wrote: > > > 在 2017/2/21 09:58, Guilherme G. Piccoli 写道: >> Currently the xmon debugger is set only via kernel boot command-line. >> It's disabled by default, and can be enabled with "xmon=on" on the >> command-line.

[PATCH] powerpc/xmon: add debugfs entry for xmon

e to read from/write to is under the debugfs mount point, on powerpc directory. Reading this file will provide the current state of the debugger, one of the following: "on", "off", "early" or "nobt". Writing one of these states to the file will take immediate effect

Re: [PATCH] powerpc/xmon: add debugfs entry for xmon

On 14/02/2017 01:58, Pan Xinhui wrote: > > > 在 2017/2/14 10:35, Nicholas Piggin 写道: >> On Mon, 13 Feb 2017 19:00:42 -0200 >> >> xmon state changing after the first sysrq+x violates principle of least >> astonishment, so I think that should be fixed. >> > hi, Nick > yes, as long as xmon is

Re: [PATCH] powerpc/xmon: add debugfs entry for xmon

On 14/02/2017 09:37, Michael Ellerman wrote: > "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: > >> Currently the xmon debugger is set only via kernel boot command-line. >> It's disabled by default, and can be enabled with "xmon=on" on the

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

On 16/02/2017 03:09, Michael Ellerman wrote: > Pan Xinhui writes: > >> Once xmon is triggered by sysrq-x, it is enabled always afterwards even >> if it is disabled during boot. This will cause a system reset interrut >> fail to dump. So keep xmon in its original

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

Xinhui <xinhui@linux.vnet.ibm.com> Patch is fine - minor typo: interrut => interrupt Feel free to add my: Tested-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> Thanks, Guilherme > --- > arch/powerpc/xmon/xmon.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

On 02/17/2017 07:30 AM, Pan Xinhui wrote: > > > 在 2017/2/17 14:05, Michael Ellerman 写道: >> Pan Xinhui writes: >>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c >>> index 9c0e17c..f6e5c3d 100644 >>> --- a/arch/powerpc/xmon/xmon.c >>> +++

Re: [RESEND-RFC v2 1/3] powerpc/eeh: Refactor eeh_pe_update_time_stamp() to update freeze_count

On 03/01/2017 01:26 PM, Vaibhav Jain wrote: > > Thanks for reviewing the patch !! Yw =) > > "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: >> >> Not sure why, but many of the words in commit message are missing their >> first l

[PATCH] of/irq: improve error message on irq discovery process failure

nterrupts capability. No functional changes were introduced. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- drivers/of/irq.c| 5 - drivers/of/of_pci_irq.c | 8 +++- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/of/irq.c b/drivers/of/ir

Re: [PATCH] of/irq: improve error message on irq discovery process failure

On 11/09/2016 04:05 PM, Rob Herring wrote: > On Wed, Nov 9, 2016 at 8:05 AM, Guilherme G. Piccoli > <gpicc...@linux.vnet.ibm.com> wrote: >> On PowerPC machines some PCI slots might not have Level-triggered >> interrupts capability (also know as Level Signaled Inter

Re: [PATCH] of/irq: improve error message on irq discovery process failure

On 11/11/2016 05:12 PM, Benjamin Herrenschmidt wrote: > On Fri, 2016-11-11 at 16:32 +, Mark Rutland wrote: >> On Fri, Nov 11, 2016 at 08:30:43AM +1100, Benjamin Herrenschmidt >> wrote: >>> >>> On Wed, 2016-11-09 at 19:04 +, Mark Rutland wrote: If we don't have an

[PATCH] genirq/affinity: fix node generation from cpumask

ve _more_ nodes than vectors. Fixes: 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading infrastructure") Reported-by: Gabriel Krisman Bertazi <gabr...@krisman.be> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> Cc: sta...@vger.kernel.org # v4

Re: [PATCH] genirq/affinity: fix node generation from cpumask

On 12/15/2016 07:36 AM, Thomas Gleixner wrote: > On Thu, 15 Dec 2016, Gavin Shan wrote: >>> static int get_nodes_in_cpumask(const struct cpumask *mask, nodemask_t >>> *nodemsk) >>> { >>> - int n, nodes; >>> + int n, nodes = 0; >>> >>> /* Calculate the number of nodes in the supplied

Re: [PATCH v2] of/irq: improve error report on irq discovery process failure

On 12/09/2016 02:25 PM, Rob Herring wrote: > On Mon, Dec 5, 2016 at 1:01 PM, Guilherme G. Piccoli > <gpicc...@linux.vnet.ibm.com> wrote: >> On 12/05/2016 12:28 PM, Rob Herring wrote: >>> On Mon, Dec 5, 2016 at 7:59 AM, Guilherme G. Piccoli >>> <gpicc...@lin

Re: [PATCH v2] of/irq: improve error report on irq discovery process failure

On 12/05/2016 12:28 PM, Rob Herring wrote: > On Mon, Dec 5, 2016 at 7:59 AM, Guilherme G. Piccoli > <gpicc...@linux.vnet.ibm.com> wrote: >> On PowerPC machines some PCI slots might not have level triggered >> interrupts capability (also know as level signaled

[PATCH v2] of/irq: improve error report on irq discovery process failure

taking the fail path instead of returning directly from the loop. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- v2: * Changed function return code to always return negative values; * Improved/simplified warning outputs; * Changed some return codes and some error

[PATCH v4 1/3] powerpc/xmon: Fix an unexpected xmon on/off state change

and 2. Signed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- v3: changed xmon_off to xmon_on, simplifying the logic [mpe suggestion]. arch/powerpc/xmon/xmon.c | 17 ++--- 1 file changed, 10 insertio

[PATCH v4 2/3] powerpc/xmon: drop the nobt option from xmon plus minor fixes

this patch fixes __initdata placement on xmon_early and replaces __initcall() with modern device_initcall() on sysrq handler. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- v4: extended the auto backtrace functionality, by showing the trace in every xmon invokation

[PATCH v4 0/3] powerpc/xmon: improvements and fixes

G. Piccoli (2): powerpc/xmon: drop the nobt option from xmon plus minor fixes powerpc/xmon: add debugfs entry for xmon Pan Xinhui (1): powerpc/xmon: Fix an unexpected xmon on/off state change arch/powerpc/xmon/xmon.c | 59 +++- 1 file changed, 43

[PATCH v4 3/3] powerpc/xmon: add debugfs entry for xmon

Writing these states to the file will take immediate effect in the debugger. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- v4: fixed a bug in the patch (s/xmon_off/xmon_on/g basically). v3: logic improved based in the changes made on patch 1. arc

Re: [PATCH v4 2/3] powerpc/xmon: drop the nobt option from xmon plus minor fixes

On 03/30/2017 09:36 PM, Paul Mackerras wrote: > On Wed, Mar 22, 2017 at 04:27:50PM -0300, Guilherme G. Piccoli wrote: >> The xmon parameter nobt was added long time ago, by commit 26c8af5f01df >> ("[POWERPC] print backtrace when entering xmon"). The problem that time &

Re: [RESEND-RFC v2 1/3] powerpc/eeh: Refactor eeh_pe_update_time_stamp() to update freeze_count

Hi Vaibhav, nice patch! Some comments below: On 03/01/2017 08:24 AM, Vaibhav Jain wrote: > This patch introduces a new function eeh_pe_update_freeze_counter() > replacing existing function eeh_pe_update_time_stamp(). The new > function also manages the value of reeze_count along with tstamp to >

Re: [PATCH 2/2] kvm/xive: Add missing barriers and document them

eel free to add my: Tested-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> Cheers, Guilherme > --- > arch/powerpc/kvm/book3s_xive_template.c | 57 > +++-- > 1 file changed, 55 insertions(+), 2 deletions(-) > > diff --git

[PATCH] powerpc/xmon: Add option to show uptime information

(and this 2nd test crashed too into xmon). This small patch adds the 'U' command, to accomplish this. Suggested-by: Murilo Fossa Vicentini <mu...@linux.vnet.ibm.com> Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- Patch written against mpe's powerpc/next br

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On 10/13/2017 05:37 AM, Michael Ellerman wrote: > > I really dislike this. > > You're basically saying the kernel can't work out how to get a device > working, so let's leave it up to the user. Oh, it was never my intention to say such blasphemy :) It meant to be just a debug option to help the

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On 10/14/2017 06:13 AM, Benjamin Herrenschmidt wrote: > No, he's saying this is useful for the developers when debugging the > kernel driver (or for asking users to "test" something as part of > debugging a driver problem). > > It's common to have various command line options affecting PCIe >

Re: [PATCH] powerpc/powernv: Turn on SCSI_AACRAID in powernv_defconfig

On 08/28/2017 02:56 AM, Michael Ellerman wrote: > Some Power9 boxes will have this adapter installed, so add it to the > defconfig so we can boot on those machines without an initrd. Michael, not sure if this affects Petitboot (I know it has its own default config files), but in the past we had

Re: [PATCH] powerpc/powernv: Turn on SCSI_AACRAID in powernv_defconfig

On 08/29/2017 08:22 AM, Michael Ellerman wrote: > "Guilherme G. Piccoli" <gpicc...@linux.vnet.ibm.com> writes: > >> On 08/28/2017 02:56 AM, Michael Ellerman wrote: >>> Some Power9 boxes will have this adapter installed, so add it to the >>> defc

Re: [PATCH] powerpc/powernv: Turn on SCSI_AACRAID in powernv_defconfig

On 08/30/2017 08:07 AM, Michael Ellerman wrote: >[...] > OK. So maybe when the petitboot kernel moves up to 4.14 they may want to > flip it back to being a module. > OK, I'll be tuned! Thanks > I think the majority of machines that have one of these adapters will be > using it for their root

[PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

of it. This is a PowerPC-only change. Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.ibm.com> --- This patch was built/tested against powerpc/next branch. We recently had a situation in which i40e driver couldn't start, even after a full power cycle, due to a bug in its FW triggered by a DCB con

[PATCH] powerpc/xmon: Always enable xmon sysrq trigger

. In other words, xmon trigger will only be disabled if SysRq is 0 (completely disabled). So, while debugging a hung, when one tries to drop to xmon this patch prevents the frustrating message: "This sysrq operation is disabled". Signed-off-by: Guilherme G. Piccoli <gpicc...@linux.vnet.i

  1   2   3   >