he required function
non-static, so that it will be called on PCI probe path on powerpc pSeries
platform in next patch.
Signed-off-by: Guilherme G. Piccoli
---
drivers/pci/probe.c | 2 +-
include/linux/pci.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b
device(). The
latter 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
---
arch/powerpc/kernel/pci_of_sc
de, so it explicitly 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
lled and MSI/MSI-X interrupts are left enabled, which is a bug. 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
o disable MSI/MSI-X
during PCI probe time on pSeries platform.
Fixes: 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel
doesn't support MSI")
Signed-off-by: Guilherme G. Piccoli
---
arch/powerpc/kernel/pci_of_scan.c | 3 +++
1 file changed, 3 insertions(+)
dif
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
---
arch/powerpc/kernel/pci-common.c | 47
lks, Bjorn 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/pc
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.
Than
: Guilherme G. Piccoli
---
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
--- a/arch/powerpc/kernel/pci-common.c
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
: Guilherme G. Piccoli
---
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
--- a/arch/powerpc/kernel/pci-common.c
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)) {
+ prop
Shan
Signed-off-by: Guilherme G. Piccoli
---
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/powerpc/kernel/pci-common.c
index 0f7a60f..bc31ac1 100644
--- a/arch
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 then
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 (int)(be32_to_cpu
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
---
arch/powerpc/platforms/
roduced 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
---
arch/powerpc/kernel/eeh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/
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
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
Reviewed-by: Gavin Shan
Thanks, Guilherme. Please make
roduced 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
Signed-off-by: Guilherme G. Piccoli
---
arch/powerpc/kernel/eeh.c | 2 +-
1 file change
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")
Cc: sta...@vger.kernel.org
Reviewed-by: Gavin Shan
Signed-off-by: Guilherme G
Shan
Signed-off-by: Guilherme G. Piccoli
---
arch/powerpc/kernel/pci-common.c | 66 ++--
1 file changed, 63 insertions(+), 3 deletions(-)
v5:
* Improved comments.
* Changed the the Fixed PHB Numbering to set the PHB number bit
on the bitmap anyway
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
https://lists.ozlabs.org/l
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
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 interrup
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 cal
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 co
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 sp
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 in
pci_dev() directly from pci_init_capabilities().
Signed-off-by: Guilherme G. Piccoli
---
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_of_scan.c
b/arch/powerpc/kernel
Bjorn, ping?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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
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,
let me know if this doesn'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
Date: Wed Oct 21 12:17:35 2015 -0200
PCI/MSI:
on DLPAR either.
Fixes: 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell")
Signed-off-by: Guilherme G. Piccoli
---
arch/powerpc/kernel/eeh.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kerne
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 by
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 adapter
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!
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 han
itialized 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
---
arch/powerpc/kernel/eeh.c | 19 +
mmand-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
---
arch/powerpc/platforms/pseries/iommu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
an oops
during device 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
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"
___
Linuxppc-
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
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
> [...]
> What your doing is changing the phb_id to some transformation of "reg" for
> all platforms except which have "ibm,opal-phbid". This is what we observe.
> This is a radical altering of the prior phb_id selection before your patch.
>
> The question is, was that your intent ? We are expectin
Many other place in the kernel prefer the latter, so let's keep
it consistent in MIPS code as well. Also, removes a useless header.
Cc: Thomas Bogendoerfer
Signed-off-by: Guilherme G. Piccoli
---
arch/mips/sgi-ip22/ip22-reset.c | 11 +--
1 file changed, 5 insertions(+), 6 dele
or we should expect more panic reliability
with this patch.
Cc: Benjamin Herrenschmidt
Cc: Hari Bathini
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Paul Mackerras
Signed-off-by: Guilherme G. Piccoli
---
We'd like to thanks specially the MiniCloud infrastructure [0] maintainers,
that allow
regular mutex).
Fixes: 2227b7c74634 ("coresight: add support for CPU debug module")
Cc: Leo Yan
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Suzuki K Poulose
Signed-off-by: Guilherme G. Piccoli
---
drivers/hwtracing/coresight/coresight-cpu-debug.c | 7 ---
1 file changed, 4 insert
owing the same approach other architectures are doing.
Also, we remove the unnecessary include of a header already
included indirectly.
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Richard Henderson
Signed-off-by: Guilherme G. Piccoli
---
arch/alpha/kernel/setup.c
er, followed by the architecture one (that coredumps).
Also, we remove a useless header inclusion.
Cc: Anton Ivanov
Cc: Johannes Berg
Cc: Richard Weinberger
Signed-off-by: Guilherme G. Piccoli
---
arch/um/drivers/mconsole_kern.c | 8 +++-
arch/um/kernel/um_arch.c| 8
2 f
sc/power driver
to make use of spin_trylock - for that, we've added a second
version of the soft-power function. Also, some comments were
reorganized and trailing white spaces, useless header inclusion
and blank lines were removed.
Cc: Helge Deller
Cc: "James E.J. Bottomley"
Signe
lexander Gordeev
Cc: Christian Borntraeger
Cc: Heiko Carstens
Cc: Sven Schnelle
Cc: Vasily Gorbik
Signed-off-by: Guilherme G. Piccoli
---
As a design choice, the option used here to verify a given spinlock is taken
was the function "spin_is_locked()" - but we noticed that it is not of
meaningful
"id" over there.
Signed-off-by: Guilherme G. Piccoli
---
include/linux/panic_notifier.h | 5 +
kernel/panic.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/panic_notifier.h b/include/linux/panic_notifier.h
index 4
re will be moved to a new list, that encompass the
information notifiers only.
Fixes: 9eb60880d9a9 ("bus: brcmstb_gisb: add notifier handling")
Cc: Brian Norris
Cc: Florian Fainelli
Signed-off-by: Guilherme G. Piccoli
---
drivers/bus/brcmstb_gisb.c | 26 +++---
e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Cc: Andrea Parri (Microsoft)
Cc: Dexuan Cui
Cc: Haiyang Zhang
Cc: "K. Y. Srinivasan"
Cc: Michael Kelley
Cc: Stephen Hemminger
Cc: Tianyu Lan
Cc: Wei Liu
Tested-by: Fabio A M Martins
Signed-off-by: Guilherm
the priority of the
notifier blocks, in order they run early compared to other
notifiers, to prevent useless trace data (like the callback
names for the other notifiers). Finally, we also removed an
unnecessary header inclusion.
Signed-off-by: Guilherme G. Piccoli
---
kerne
hat this should be guarded as a tunable since
it can flood the kernel log buffer.
Cc: Arjan van de Ven
Cc: Cong Wang
Cc: Sebastian Andrzej Siewior
Cc: Valentin Schneider
Cc: Xiaoming Ni
Signed-off-by: Guilherme G. Piccoli
---
We have some design decisions that worth discussing here:
(a
Cc: Tianyu Lan
Cc: Vasily Gorbik
Cc: Wang ShaoBo
Cc: Wei Liu
Cc: zhenwei pi
Signed-off-by: Guilherme G. Piccoli
---
arch/mips/sgi-ip22/ip22-reset.c | 2 +-
arch/mips/sgi-ip32/ip32-reset.c | 3 +--
arch/powerpc/kernel/setup-common.c | 2 +-
arch/sparc/kernel/sstate
Mike Leach
Cc: Mikko Perttunen
Cc: Neeraj Upadhyay
Cc: Nicholas Piggin
Cc: Paul Mackerras
Cc: Suzuki K Poulose
Cc: Thierry Reding
Cc: Thomas Bogendoerfer
Signed-off-by: Guilherme G. Piccoli
---
arch/arm64/kernel/setup.c | 2 +-
arch/mips/kernel/relocate.c
lerman
Cc: Paul Mackerras
Cc: Pavel Machek
Cc: Richard Henderson
Cc: Richard Weinberger
Cc: Robert Richter
Cc: Stefano Stabellini
Cc: Stephen Hemminger
Cc: Sven Schnelle
Cc: Tony Luck
Cc: Vasily Gorbik
Cc: Wei Liu
Signed-off-by: Guilherme G. Piccoli
---
Notice that, with this name
fdefs / hardcoded approaches.
Cc: Alexander Gordeev
Cc: Christian Borntraeger
Cc: "David S. Miller"
Cc: Heiko Carstens
Cc: Sven Schnelle
Cc: Vasily Gorbik
Signed-off-by: Guilherme G. Piccoli
---
arch/s390/kernel/setup.c | 19 ++-
arch/sparc/kernel/se
subsequent patch.
Notice that the spinlock guarding kmsg_dumpers list also guards
increment/decrement of the dumper's counter, but there's no need
for that when reading the counter in the panic path, since that is
an atomic path and there's no other (planned) user.
Signed-off
eterministic, but also very customizable.
[0] https://lore.kernel.org/lkml/YfPxvzSzDLjO5ldp@alley/
Suggested-by: Petr Mladek
Signed-off-by: Guilherme G. Piccoli
---
Special thanks to Petr and Baoquan for the suggestion and feedback in a previous
email thread. There's some important design deci
nction.
We also moved its code to kernel/printk.c, it seems to make more
sense given it's related to printing stuff.
Suggested-by: Petr Mladek
Signed-off-by: Guilherme G. Piccoli
---
.../admin-guide/kernel-parameters.txt | 12 +++-
Documentation/admin-guide/sysctl/kernel.rst |
ers: hv: log when enabling crash_kexec_post_notifiers"
Cc: Andrea Parri (Microsoft)
Cc: Dexuan Cui
Cc: Haiyang Zhang
Cc: "K. Y. Srinivasan"
Cc: Michael Kelley
Cc: Stephen Brennan
Cc: Stephen Hemminger
Cc: Tianyu Lan
Cc: Wei Liu
Tested-by: Fabio A M Martins
Signed-off-by: Guil
ring (which was also improved in the
refactor) from within arch code.
Fixes: 06e629c25daa ("powerpc/fadump: Fix inaccurate CPU state info in vmcore
generated with panic")
Cc: Benjamin Herrenschmidt
Cc: Hari Bathini
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Paul Mackerras
Signe
There is no users anymore of this variable that requires
it to be "exported" in the headers; also, it was deprecated
by the kernel parameter "panic_notifiers_level".
Signed-off-by: Guilherme G. Piccoli
---
include/linux/panic.h | 2 --
include/linux/panic_notif
ing system")
Cc: Benjamin Herrenschmidt
Cc: Hari Bathini
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Paul Mackerras
Signed-off-by: Guilherme G. Piccoli
---
We'd like to thanks specially the MiniCloud infrastructure [0] maintainers,
that allow us to test PowerPC code in a very comp
: Richard Weinberger
Signed-off-by: Guilherme G. Piccoli
---
arch/um/kernel/um_arch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
index fc6e443299da..651310e3e86f 100644
--- a/arch/um/kernel/um_arch.c
+++ b/arch/um/kernel/um_arch.c
@@ -241,7
Cc: zhenwei pi
Signed-off-by: Guilherme G. Piccoli
---
drivers/misc/pvpanic/pvpanic.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
index 4b8f1c7d726d..049a12006348 100644
--- a/drivers/misc/pvpani
IQs in all
secondary CPUs in the kexec/panic path as well.
Cc: Marc Zyngier
Cc: Russell King
Signed-off-by: Guilherme G. Piccoli
---
arch/arm/kernel/machine_kexec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index f5
Evan Green
Cc: Julius Werner
Signed-off-by: Guilherme G. Piccoli
---
drivers/firmware/google/gsmi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index adaa492c3d2d..b01ed02e4a87 100644
--- a/drivers/firmwar
Kawai
Cc: Paolo Bonzini
Cc: Sean Christopherson
Signed-off-by: Guilherme G. Piccoli
---
arch/x86/include/asm/cpu.h | 1 +
arch/x86/kernel/crash.c| 8
arch/x86/kernel/reboot.c | 14 --
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/x86/in
t for S2/S3/S5 suspend
states (ARM)")
Cc: Brian Norris
Cc: Doug Berger
Cc: Florian Fainelli
Cc: Justin Chen
Cc: Lee Jones
Cc: Markus Mayer
Signed-off-by: Guilherme G. Piccoli
---
drivers/soc/bcm/brcmstb/pm/pm-arm.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletion
-by: Guilherme G. Piccoli
---
include/linux/notifier.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 87069b8459af..0589896fc7bd 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -201,12
ails you didn't want to or, (b) I forgot to include you but it was something
considered interesting by you.
Thanks in advance for reviews / comments / suggestions!
Cheers,
Guilherme
[0] https://lore.kernel.org/lkml/YfPxvzSzDLjO5ldp@alley/
Guilherme G. Piccoli (30):
x86/crash,reboot: Avoi
On 29/04/2022 10:23, Steven Rostedt wrote:
> On Fri, 29 Apr 2022 12:22:44 +0300
> Sergei Shtylyov wrote:
>
>>> + switch (ev) {
>>> + case DIE_OOPS:
>>> + do_dump = 1;
>>> + break;
>>> + case PANIC_NOTIFIER:
>>> + do_dump = 1;
>>> + break;
>>
>>W
On 28/04/2022 13:55, Helge Deller wrote:
> [...]
> You may add:
> Acked-by: Helge Deller # parisc
>
> Helge
Thanks Helge, added!
Cheers,
Guilherme
>
>
>> ---
>> arch/parisc/include/asm/pdc.h | 1 +
>> arch/parisc/kernel/firmware.c | 27 +++
>> drivers/parisc/power.
On 29/04/2022 10:56, Steven Rostedt wrote:
> [...]
> No. The fallthrough keyword is only needed when there's code between case
> labels. As it is very common to list multiple cases for the same code path.
> That is:
>
> case DIE_OOPS:
> case PANIC_NOTIFIER:
> do_dump = 1;
On 27/04/2022 21:28, Randy Dunlap wrote:
>
>
> On 4/27/22 15:49, Guilherme G. Piccoli wrote:
>> +crash_kexec_post_notifiers
>> +This was DEPRECATED - users should always prefer the
>
> This is DEPRECATED - use
On 28/04/2022 05:11, Suzuki K Poulose wrote:
> Hi Guilherme,
> [...]
> How would you like to proceed with queuing this ? I am happy
> either way. In case you plan to push this as part of this
> series (I don't see any potential conflicts) :
>
> Reviewed-by: Suzuki K Poulose
Thanks for your revi
Thanks Paul and Suzuki for the ACKs.
Cheers,
Guilherme
On 28/04/2022 13:26, Corey Minyard wrote:
> [...]
>
> For the IPMI portion:
>
> Acked-by: Corey Minyard
Thanks Alex and Corey for the ACKs!
>
> Note that the IPMI panic_event() should always return, but it may take
> some time, especially if the IPMI controller is no longer functional.
> So t
On 29/04/2022 14:53, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> 2022 3:49 PM
>> [...]
>> +panic_notifiers_level=
>> +[KNL] Set the panic notifiers execution order.
>> +Forma
Thanks Marc and Michael for the review/discussion.
On 29/04/2022 15:20, Marc Zyngier wrote:
> [...]
> My expectations would be that, since we're getting here using an IPI,
> interrupts are already masked. So what reenabled them the first place?
>
> Thanks,
>
> M.
>
Marc, I did some inve
On 29/04/2022 18:45, Russell King (Oracle) wrote:
> [...]
>> Marc, I did some investigation in the code (and tried/failed in the ARM
>> documentation as well heh), but this is still not 100% clear for me.
>>
>> You're saying IPI calls disable IRQs/FIQs by default in the the target
>> CPUs? Where do
On 29/04/2022 14:30, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> 2022 3:49 PM
>> [...]
>>
>> @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void)
>> if (ms_hyperv.misc_features & HV
On 29/04/2022 15:46, Heiko Carstens wrote:
> [...]
>
> Code looks good, and everything still seems to work. I applied this
> internally for the time being, and if it passes testing, I'll schedule
> it for the next merge window.
>
> Thanks!
Perfect Heiko, thanks a bunch for your review and tests!
On 29/04/2022 13:04, Max Filippov wrote:
> [...]
>> arch/xtensa/platforms/iss/setup.c | 4 ++--For xtensa:
>
> For xtensa:
> Acked-by: Max Filippov
>
Perfect, thanks Max!
Cheers,
Guilherme
On 27/04/2022 22:01, Xiaoming Ni wrote:
> [...]
> Duplicate Code.
>
> Is it better to use __func__ and %pS?
>
> pr_info("%s: %pS\n", __func__, n->notifier_call);
>
>
This is a great suggestion Xiaoming, much appreciated!
I feel like reinventing the wheel here - with your idea, code was super
c
Hi Michael, first of all thanks for the great review, much appreciated.
Some comments inline below:
On 29/04/2022 14:16, Michael Kelley (LINUX) wrote:
> [...]
>> hypervisor I/O completion), so we postpone that to run late. But more
>> relevant: this *same* vmbus unloading happens in the crash_shut
On 02/05/2022 12:38, Florian Fainelli wrote:
> [...]
>
> Acked-by: Florian Fainelli
>
> Not sure if the Fixes tag is warranted however as this is a clean up,
> and not really fixing a bug.
Perfect, thanks Florian. I'll add your ACK and remove the fixes tag in V2.
Cheers,
Guilherme
On 02/05/2022 12:38, Florian Fainelli wrote:
> [...]
> Acked-by: Florian Fainelli
>
> Likewise, I am not sure if the Fixes tag is necessary here.
Perfect Florian, thanks! I'll add your Acked-by tag and remove the
fixes for V2 =)
Cheers,
Guilherme
On 03/05/2022 14:31, Michael Kelley (LINUX) wrote:
> [...]
>
> To me, it's a weak correlation between having a kmsg dumper, and
> wanting or not wanting the info level output to come before kdump.
> Hyper-V is one of only a few places that register a kmsg dumper, so most
> Linux instances outside
On 03/05/2022 14:44, Michael Kelley (LINUX) wrote:
> [...]
>>
>> Hi Michael, thanks for your feedback! I agree that your idea could work,
>> but...there is one downside: imagine the kmsg_dump() approach is not set
>> in some Hyper-V guest, then we would rely in the regular notification
>> mechanism
On 03/05/2022 15:13, Michael Kelley (LINUX) wrote:
> [...]
>> (a) We could forget about this change, and always do the clean-up here,
>> not relying in machine_crash_shutdown().
>> Pro: really simple, behaves the same as it is doing currently.
>> Con: less elegant/concise, doesn't allow arm64 custo
On 03/05/2022 15:03, Evan Green wrote:
> [...]
> gsmi_shutdown_reason() is a common function called in other scenarios
> as well, like reboot and thermal trip, where it may still make sense
> to wait to acquire a spinlock. Maybe we should add a parameter to
> gsmi_shutdown_reason() so that you can
On 03/05/2022 18:56, Evan Green wrote:
> Hi Guilherme,
> [...]
>> Do you agree with that, or prefer really a parameter in
>> gsmi_shutdown_reason() ? I'll follow your choice =)
>
> I'm fine with either, thanks for the link. Mostly I want to make sure
> other paths to gsmi_shutdown_reason() aren't
On 04/05/2022 17:32, Thomas Bogendoerfer wrote:
> [...]
>
> applied to mips-next.
>
> Thomas.
>
Thanks a bunch Thomas =)
1 - 100 of 221 matches
Mail list logo
