Re: [PATCH v4 2/2] PCI/DPC: Disable DPC service when link is in L2/L3 ready, L2 and L3 state
On Mon, Apr 18, 2022 at 10:41 AM Sathyanarayanan Kuppuswamy wrote: > > > > On 4/8/22 8:31 AM, Kai-Heng Feng wrote: > > On Intel Alder Lake platforms, Thunderbolt entering D3cold can cause > > some errors reported by AER: > > [ 30.100211] pcieport :00:1d.0: AER: Uncorrected (Non-Fatal) error > > received: :00:1d.0 > > [ 30.100251] pcieport :00:1d.0: PCIe Bus Error: severity=Uncorrected > > (Non-Fatal), type=Transaction Layer, (Requester ID) > > [ 30.100256] pcieport :00:1d.0: device [8086:7ab0] error > > status/mask=0010/4000 > > [ 30.100262] pcieport :00:1d.0:[20] UnsupReq (First) > > [ 30.100267] pcieport :00:1d.0: AER: TLP Header: 3400 0852 > > > > [ 30.100372] thunderbolt :0a:00.0: AER: can't recover (no > > error_detected callback) > > [ 30.100401] xhci_hcd :3e:00.0: AER: can't recover (no error_detected > > callback) > > [ 30.100427] pcieport :00:1d.0: AER: device recovery failed > > > > Since AER is disabled in previous patch for a Link in L2/L3 Ready, L2 > > and L3, also disable DPC here as DPC depends on AER to work. > > > > Bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=215453 > > Reviewed-by: Mika Westerberg > > Signed-off-by: Kai-Heng Feng > > Reviewed-by: Kuppuswamy Sathyanarayanan > A gentle ping... > -- > Sathyanarayanan Kuppuswamy > Linux Kernel Developer
[Bug 216156] kmemleak: Not scanning unknown object at 0xc00000007f000000
https://bugzilla.kernel.org/show_bug.cgi?id=216156 --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- For the "WARNING: CPU: 0 PID: 232 at include/linux/skbuff.h:2911 .rtl8169_features_check+0x290/0x4f0" later in the dmesg I openend bug #216157 in doubt whether this is ppc64 specific. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216156] kmemleak: Not scanning unknown object at 0xc00000007f000000
https://bugzilla.kernel.org/show_bug.cgi?id=216156
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301232
--> https://bugzilla.kernel.org/attachment.cgi?id=301232=edit
cat /sys/kernel/debug/kmemleak
Apart from that kmemleak shows a lot of hits.
Only this patch was applied on top of 5.19-rc3 to prevent bug #216095:
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 3507095a69f6..a70ff9df5cb9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -556,7 +556,7 @@ static int __init of_platform_default_populate_init(void)
if (!of_get_property(node, "linux,opened", NULL) ||
!of_get_property(node, "linux,boot-display", NULL))
continue;
- dev = of_platform_device_create(node, "of-display",
NULL);
+ dev = of_platform_device_create(node, NULL, NULL);
if (WARN_ON(!dev))
return -ENOMEM;
boot_display = node;
@@ -565,7 +565,7 @@ static int __init of_platform_default_populate_init(void)
for_each_node_by_type(node, "display") {
if (!of_get_property(node, "linux,opened", NULL) ||
node == boot_display)
continue;
- of_platform_device_create(node, "of-display", NULL);
+ of_platform_device_create(node, NULL, NULL);
}
} else {
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 216156] kmemleak: Not scanning unknown object at 0xc00000007f000000
https://bugzilla.kernel.org/show_bug.cgi?id=216156 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 301231 --> https://bugzilla.kernel.org/attachment.cgi?id=301231=edit kernel .config (5.19-rc3, PowerMac G5 11,2) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216156] New: kmemleak: Not scanning unknown object at 0xc00000007f000000
https://bugzilla.kernel.org/show_bug.cgi?id=216156 Bug ID: 216156 Summary: kmemleak: Not scanning unknown object at 0xc0007f00 Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.19-rc3 Hardware: PPC-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-64 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org Regression: No Created attachment 301230 --> https://bugzilla.kernel.org/attachment.cgi?id=301230=edit dmesg (5.19-rc3, PowerMac G5 11,2) Happens every boot with kmemleak enabled: [...] PowerMac motherboard: PowerMac G5 Dual Core ioremap() called early from .btext_map+0x64/0xc0. Use early_ioremap() instead ioremap() called early from .iommu_init_early_dart+0x260/0x924. Use early_ioremap() instead kmemleak: Not scanning unknown object at 0xc0007f00 CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-rc3-PMacG5+ #2 Call Trace: [c113faf0] [c06c03d0] .dump_stack_lvl+0x7c/0xc4 (unreliable) [c113fb80] [c02dff90] .kmemleak_no_scan+0xe0/0x100 [c113fc00] [c0d487e8] .iommu_init_early_dart+0x2f0/0x924 [c113fd40] [c0d49984] .pmac_probe+0x1b0/0x20c [c113fde0] [c0d36ee8] .setup_arch+0x1b8/0x674 [c113feb0] [c0d316f4] .start_kernel+0xdc/0xb74 [c113ff90] [c000c5d8] start_here_common+0x1c/0x44 DART table allocated at: (ptrval) DART IOMMU initialized for U4 type chipset Using PowerMac machine description printk: bootconsole [udbg0] enabled CPU maps initialized for 1 thread per core [...] -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
> > > > Just for my understanding, are you suggesting to set a device tree > > > > property to force a fixed behavior in the driver ? > > > Yes. > > Why should we use a fixed behavior ? > The things that are fixed by the design should be fixed. > > > The device shares pins between the line inputs and the DMIC inputs so at > > > least some of the configuration is going to be determinted at system > > > design time, that will fix the usable values of at least one of the > > > controls which ought to be reflected in the runtime behaviour. > > In our design we use: > > - pin 1: DMIC_CLK > > - pin 24: LINEIN2R > > - pin 26: LINEIN2L > > - pin 27: DMIC_DATA > > we have no pins shared among DMIC and LINEIN. > This means that DMICDAT2 is not usefully selectable at runtime, you've > got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is > useful the DMIC1/2 switch is not. A customer could have the following working configuration - pin 1: DMIC_CLK - pin 24: LINEIN2R - pin 25: DMICDAT2 - pin 26: LINEIN2L - pin 27: DMICDAT1 with no shared pins: here there's the chance to select DMIC1, DMIC2 and LINEIN2 at runtime: I can't find a reason for a fixed behavior. Can you please elaborate ?
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
> > Just for my understanding, are you suggesting to set a device tree > > property to force a fixed behavior in the driver ? > Yes. Why should we use a fixed behavior ? > > WM8904 allows using both a DMIC and LINEIN, switching between one or > > the other and this is how we currently use it. > > Why the user should not be allowed to switch between DMIC and LINEIN ? > The device shares pins between the line inputs and the DMIC inputs so at > least some of the configuration is going to be determinted at system > design time, that will fix the usable values of at least one of the > controls which ought to be reflected in the runtime behaviour. In our design we use: - pin 1: DMIC_CLK - pin 24: LINEIN2R - pin 26: LINEIN2L - pin 27: DMIC_DATA we have no pins shared among DMIC and LINEIN. We have several customer switching between DMIC and LINEIN at runtime. > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. I beg your pardon: it should be fixed now.
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
> > > Via firmware description. > > Can you please provide any reference approach in the kernel code ? > git grep of_ > git grep fwnode_ > and I don't immediately remember what the prefix is for ACPI functions. Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ? WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it. Why the user should not be allowed to switch between DMIC and LINEIN ?
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
> > > > +static const char *cin_text[] = {
> > > > + "ADC", "DMIC"
> > > > +};
> > > > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > > > + WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
> > > Why would this be runtime selectable? I'd expect the decision to use
> > > an analogue or digital microphone to be made in the hardware design.
> > I agree that dedicated HW is required, but currently SW side there's no
> > support at all.
> > This patch is aiming to provide a way to enable DMIC on boards using it.
> > Is this supposed to be managed in a different way ?
> Via firmware description.
Can you please provide any reference approach in the kernel code ?
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
Hi All,
> > +static const char *cin_text[] = {
> > + "ADC", "DMIC"
> > +};
> > +
> > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > + WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
>
> Why would this be runtime selectable? I'd expect the decision to use
> an analogue or digital microphone to be made in the hardware design.
I agree that dedicated HW is required, but currently SW side there's no support
at all.
This patch is aiming to provide a way to enable DMIC on boards using it.
Is this supposed to be managed in a different way ?
Thanks
Best Regards
Pier
Re: [PATCH 3/4] ASoC: wm8904: extend device tree support
> > The platform_data structure is not populated when using device trees. > > This patch adds optional dts properties to allow populating it: > > - gpio-cfg > > - mic-cfg > > - num-drc-cfgs > > - drc-cfg-regs > > - drc-cfg-names > > - num-retune-mobile-cfgs > > - retune-mobile-cfg-regs > > - retune-mobile-cfg-names > > - retune-mobile-cfg-rates > > If you want to add all this, convert to DT schema first. > They all need vendor prefixes for starters. Beyond adding the vendor prefix, can you please add details or provide any reference about "convert to DT schema" ? > > > > Signed-off-by: Pierluigi Passaro > > Signed-off-by: Alifer Moraes > > --- > > .../devicetree/bindings/sound/wm8904.txt | 53 > > sound/soc/codecs/wm8904.c | 113 +- > > Binding changes go in their own patches. Do you mean that C code and TXT documentation should be provided as separated patches ? Thanks Best Regards Pier
Re: [PATCH 3/4] ASoC: wm8904: extend device tree support
Hi All, > > + - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property > > + > > + - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC) > > + The list must be (4 x num-drc-cfgs) entries long. > > + If absent or incomplete, DRC is disabled. > > What is the purpose of having num-drc-cfgs? We can tell how large > drc-cfg-regs is so it just seems redundant. Can you please point me to any reference implementation doing this ? > > + - num-retune-mobile-cfgs: Number of retune modes available from > > + retune-mobile-cfg-regs property > > Same here. Thanks Best Regards Pier
Re: [PATCH 1/4] video: fbdev: offb: Include missing linux/platform_device.h
On 6/11/22 18:50, Christophe Leroy wrote:
> A lot of drivers were getting platform and of headers
> indirectly via headers like asm/pci.h or asm/prom.h
>
> Most of them were fixed during 5.19 cycle but a newissue was
> introduced by commit 52b1b46c39ae ("of: Create platform devices
> for OF framebuffers")
>
> Include missing platform_device.h to allow cleaning asm/pci.h
>
> Cc: Thomas Zimmermann
> Fixes: 52b1b46c39ae ("of: Create platform devices for OF framebuffers")
> Signed-off-by: Christophe Leroy
Acked-by: Helge Deller
I assume you take this through the linuxppc git tree?
Helge
> ---
> drivers/video/fbdev/offb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
> index b1acb1ebebe9..91001990e351 100644
> --- a/drivers/video/fbdev/offb.c
> +++ b/drivers/video/fbdev/offb.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #ifdef CONFIG_PPC32
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
On Mon, Jun 20, 2022 at 05:52:43PM +, Pierluigi Passaro wrote: > > > Just for my understanding, are you suggesting to set a device tree > > > property to force a fixed behavior in the driver ? > > Yes. > Why should we use a fixed behavior ? The things that are fixed by the design should be fixed. > > The device shares pins between the line inputs and the DMIC inputs so at > > least some of the configuration is going to be determinted at system > > design time, that will fix the usable values of at least one of the > > controls which ought to be reflected in the runtime behaviour. > In our design we use: > - pin 1: DMIC_CLK > - pin 24: LINEIN2R > - pin 26: LINEIN2L > - pin 27: DMIC_DATA > we have no pins shared among DMIC and LINEIN. This means that DMICDAT2 is not usefully selectable at runtime, you've got IN1 as digital and IN2 as analogue, so while the DMIC/ADC switch is useful the DMIC1/2 switch is not. signature.asc Description: PGP signature
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
On Mon, Jun 20, 2022 at 03:30:45PM +, Pierluigi Passaro wrote: > Just for my understanding, are you suggesting to set a device tree property > to force a fixed behavior in the driver ? Yes. > WM8904 allows using both a DMIC and LINEIN, switching between one or the > other and this is how we currently use it. > Why the user should not be allowed to switch between DMIC and LINEIN ? The device shares pins between the line inputs and the DMIC inputs so at least some of the configuration is going to be determinted at system design time, that will fix the usable values of at least one of the controls which ought to be reflected in the runtime behaviour. Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. signature.asc Description: PGP signature
[PATCH] powerpc/pasemi: Fix refcount leak bug
In pas_pci_init(), we need one of_node_put() for of_find_node_by_path()
to keep refcount balance.
Signed-off-by: Liang He
---
arch/powerpc/platforms/pasemi/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pasemi/pci.c
b/arch/powerpc/platforms/pasemi/pci.c
index 55f0160910bf..4b371fb0d9aa 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -282,6 +282,7 @@ void __init pas_pci_init(void)
pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
np = of_find_compatible_node(root, NULL, "pasemi,rootbus");
+ of_node_put(root);
if (np) {
res = pas_add_bridge(np);
of_node_put(np);
--
2.25.1
Re: [PATCH 3/4] ASoC: wm8904: extend device tree support
On Mon, Jun 20, 2022 at 02:32:17PM +, Pierluigi Passaro wrote: > > > + - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC) > > > + The list must be (4 x num-drc-cfgs) entries long. > > > + If absent or incomplete, DRC is disabled. > > What is the purpose of having num-drc-cfgs? We can tell how large > > drc-cfg-regs is so it just seems redundant. > Can you please point me to any reference implementation doing this ? of_property_read_variable_uX_array() should do what you want, you can also use of_property_count_elems_of_size(). The main DT API header is linux/of.h. signature.asc Description: PGP signature
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
On Mon, Jun 20, 2022 at 03:03:50PM +, Pierluigi Passaro wrote: > > Via firmware description. > Can you please provide any reference approach in the kernel code ? git grep of_ git grep fwnode_ and I don't immediately remember what the prefix is for ACPI functions. signature.asc Description: PGP signature
[PATCH] powerpc/powermac: Fix refcount leak bug
In smp_core99_setup(), we need to add of_node_put() to keep refcount balance. Signed-off-by: Liang He --- arch/powerpc/platforms/powermac/smp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/powermac/smp.c b/arch/powerpc/platforms/powermac/smp.c index d9df45741ece..5b26a9012d2e 100644 --- a/arch/powerpc/platforms/powermac/smp.c +++ b/arch/powerpc/platforms/powermac/smp.c @@ -711,6 +711,7 @@ static void __init smp_core99_setup(int ncpus) printk(KERN_INFO "Processor timebase sync using" " platform function\n"); } + of_node_put(cpus); } #else /* CONFIG_PPC64 */ -- 2.25.1
Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
On Mon, Jun 20, 2022 at 02:49:51PM +, Pierluigi Passaro wrote:
> > > +static const char *cin_text[] = {
> > > + "ADC", "DMIC"
> > > +};
> > > +static SOC_ENUM_SINGLE_DECL(cin_enum,
> > > + WM8904_DIGITAL_MICROPHONE_0, 12, cin_text);
> > Why would this be runtime selectable? I'd expect the decision to use
> > an analogue or digital microphone to be made in the hardware design.
> I agree that dedicated HW is required, but currently SW side there's no
> support at all.
> This patch is aiming to provide a way to enable DMIC on boards using it.
> Is this supposed to be managed in a different way ?
Via firmware description.
signature.asc
Description: PGP signature
Re: [PATCH -next v5 2/8] arm64: extable: make uaaccess helper use extable type EX_TYPE_UACCESS_ERR_ZERO
On Mon, Jun 20, 2022 at 10:13:41PM +0800, Tong Tiangen wrote: > > > 在 2022/6/20 17:10, Mark Rutland 写道: > > On Mon, Jun 20, 2022 at 10:59:12AM +0800, Tong Tiangen wrote: > > > 在 2022/6/18 20:40, Mark Rutland 写道: > > > The following errors are reported during compilation: > > > [...] > > > arch/arm64/lib/clear_user.S:45: Error: invalid operands (*ABS* and *UND* > > > sections) for `<<' > > > [...] > > > > As above, I'm not seeing this. > > > > This suggests that the EX_DATA_REG() macro is going wrong somehow. Assuming > > the > > operand types correspond to the LHS and RHS of the expression, this would > > mean > > the GPR number is defined, but the REG value is not, and I can't currently > > see > > how that can happen. > Now I can compile success, both versions 9.4.0 and 11.2.0. > > I should have made a mistake. There is no problem using your implementation. > I will send a new version these days. No problem; thanks for confirming! Mark.
[PATCH v3] powerpc/powernv: Fix refcount leak bugs
In these driver init functions, there are two kinds of errors:
(1) missing of_put_node() for of_find_compatible_node()'s returned
pointer (refcount incremented) in fail path or when it is not
used anymore.
(2) missing of_put_node() for 'for_each_xxx' loop's break
These bugs are similar with the ones reported by commit-09700c504d.
Signed-off-by: Liang He
---
changelog:
v3: merge more refcount bugs into one commit
v2: merge opal-*.c
v1: send mising of_node_put patch for each file
arch/powerpc/platforms/powernv/idle.c | 1 +
arch/powerpc/platforms/powernv/opal-core.c | 2 ++
arch/powerpc/platforms/powernv/opal-powercap.c | 6 +-
arch/powerpc/platforms/powernv/opal-psr.c | 6 +-
arch/powerpc/platforms/powernv/opal-sensor-groups.c | 6 +-
arch/powerpc/platforms/powernv/opal.c | 1 +
6 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 6f94b808dd39..c1b369c7f507 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -1419,6 +1419,7 @@ static int __init pnv_parse_cpuidle_dt(void)
kfree(temp_u32);
kfree(temp_u64);
kfree(temp_string);
+ of_node_put(np);
return rc;
}
diff --git a/arch/powerpc/platforms/powernv/opal-core.c
b/arch/powerpc/platforms/powernv/opal-core.c
index adcb1a1a2bfe..bb7657115f1d 100644
--- a/arch/powerpc/platforms/powernv/opal-core.c
+++ b/arch/powerpc/platforms/powernv/opal-core.c
@@ -348,6 +348,8 @@ static int __init create_opalcore(void)
if (!dn || ret)
pr_warn("WARNING: Failed to read OPAL base & entry values\n");
+ of_node_put(dn);
+
/* Use count to keep track of the program headers */
count = 0;
diff --git a/arch/powerpc/platforms/powernv/opal-powercap.c
b/arch/powerpc/platforms/powernv/opal-powercap.c
index 64506b46e77b..78c359c90093 100644
--- a/arch/powerpc/platforms/powernv/opal-powercap.c
+++ b/arch/powerpc/platforms/powernv/opal-powercap.c
@@ -153,7 +153,7 @@ void __init opal_powercap_init(void)
pcaps = kcalloc(of_get_child_count(powercap), sizeof(*pcaps),
GFP_KERNEL);
if (!pcaps)
- return;
+ goto out_powercap;
powercap_kobj = kobject_create_and_add("powercap", opal_kobj);
if (!powercap_kobj) {
@@ -226,6 +226,7 @@ void __init opal_powercap_init(void)
}
i++;
}
+ of_node_put(powercap);
return;
@@ -236,6 +237,9 @@ void __init opal_powercap_init(void)
kfree(pcaps[i].pg.name);
}
kobject_put(powercap_kobj);
+ of_node_put(node);
out_pcaps:
kfree(pcaps);
+out_powercap:
+ of_node_put(powercap);
}
diff --git a/arch/powerpc/platforms/powernv/opal-psr.c
b/arch/powerpc/platforms/powernv/opal-psr.c
index 69d7e75950d1..ec32e0a93f08 100644
--- a/arch/powerpc/platforms/powernv/opal-psr.c
+++ b/arch/powerpc/platforms/powernv/opal-psr.c
@@ -135,7 +135,7 @@ void __init opal_psr_init(void)
psr_attrs = kcalloc(of_get_child_count(psr), sizeof(*psr_attrs),
GFP_KERNEL);
if (!psr_attrs)
- return;
+ goto out_psr;
psr_kobj = kobject_create_and_add("psr", opal_kobj);
if (!psr_kobj) {
@@ -162,10 +162,14 @@ void __init opal_psr_init(void)
}
i++;
}
+ of_node_put(psr);
return;
out_kobj:
+ of_node_put(node);
kobject_put(psr_kobj);
out:
kfree(psr_attrs);
+out_psr:
+ of_node_put(psr);
}
diff --git a/arch/powerpc/platforms/powernv/opal-sensor-groups.c
b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
index 8fba7d25ae56..9944376b115c 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor-groups.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
@@ -170,7 +170,7 @@ void __init opal_sensor_groups_init(void)
sgs = kcalloc(of_get_child_count(sg), sizeof(*sgs), GFP_KERNEL);
if (!sgs)
- return;
+ goto out_sg_put;
sg_kobj = kobject_create_and_add("sensor_groups", opal_kobj);
if (!sg_kobj) {
@@ -222,6 +222,7 @@ void __init opal_sensor_groups_init(void)
}
i++;
}
+ of_node_put(sg);
return;
@@ -231,6 +232,9 @@ void __init opal_sensor_groups_init(void)
kfree(sgs[i].sg.attrs);
}
kobject_put(sg_kobj);
+ of_node_put(node);
out_sgs:
kfree(sgs);
+out_sg_put:
+ of_node_put(sg);
}
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 55a8fbfdb5b2..d86cc48a10aa 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -952,6 +952,7 @@ static void __init opal_imc_init_dev(void)
np =
[PATCH v2] powerpc/sysdev: Fix refcount leak bugs
We need add corresponding of_node_put() to keep refcount balance
in sysdev.
Signed-off-by: Liang He
---
changelog:
v2: (1) merge all sysdev related bug into one commit
(2) find new bugs in spapr.c and mpic_msgr.c
v1: find missing of_node_put() in each file
arch/powerpc/sysdev/fsl_pci.c | 6 +-
arch/powerpc/sysdev/mpic_msgr.c | 10 +-
arch/powerpc/sysdev/xive/native.c | 15 ++-
arch/powerpc/sysdev/xive/spapr.c | 1 +
4 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 1011cfea2e32..4c986c955951 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -180,6 +180,7 @@ static int setup_one_atmu(struct ccsr_pci __iomem *pci,
static bool is_kdump(void)
{
struct device_node *node;
+ bool ret;
node = of_find_node_by_type(NULL, "memory");
if (!node) {
@@ -187,7 +188,10 @@ static bool is_kdump(void)
return false;
}
- return of_property_read_bool(node, "linux,usable-memory");
+ ret = of_property_read_bool(node, "linux,usable-memory");
+ of_node_put(node);
+
+ return ret;
}
/* atmu setup for fsl pci/pcie controller */
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index 698fefaaa6dd..2ff3a0a0cf3f 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -121,11 +121,13 @@ static unsigned int mpic_msgr_number_of_blocks(void)
count += 1;
}
+ of_node_put(aliases);
}
return count;
}
+
static unsigned int mpic_msgr_number_of_registers(void)
{
return mpic_msgr_number_of_blocks() * MPIC_MSGR_REGISTERS_PER_BLOCK;
@@ -144,12 +146,18 @@ static int mpic_msgr_block_number(struct device_node
*node)
for (index = 0; index < number_of_blocks; ++index) {
struct property *prop;
+ struct device_node *tn;
snprintf(buf, sizeof(buf), "mpic-msgr-block%d", index);
prop = of_find_property(aliases, buf, NULL);
- if (node == of_find_node_by_path(prop->value))
+ tn = of_find_node_by_path(prop->value);
+ if (node == tn) {
+ of_node_put(tn);
break;
+ }
+ of_node_put(tn);
}
+ of_node_put(aliases);
return index == number_of_blocks ? -1 : index;
}
diff --git a/arch/powerpc/sysdev/xive/native.c
b/arch/powerpc/sysdev/xive/native.c
index d25d8c692909..3925825954bc 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -579,12 +579,12 @@ bool __init xive_native_init(void)
/* Resource 1 is HV window */
if (of_address_to_resource(np, 1, )) {
pr_err("Failed to get thread mgmnt area resource\n");
- return false;
+ goto err_put;
}
tima = ioremap(r.start, resource_size());
if (!tima) {
pr_err("Failed to map thread mgmnt area\n");
- return false;
+ goto err_put;
}
/* Read number of priorities */
@@ -612,7 +612,7 @@ bool __init xive_native_init(void)
/* Resource 2 is OS window */
if (of_address_to_resource(np, 2, )) {
pr_err("Failed to get thread mgmnt area resource\n");
- return false;
+ goto err_put;
}
xive_tima_os = r.start;
@@ -624,7 +624,7 @@ bool __init xive_native_init(void)
rc = opal_xive_reset(OPAL_XIVE_MODE_EXPL);
if (rc) {
pr_err("Switch to exploitation mode failed with error %lld\n",
rc);
- return false;
+ goto err_put;
}
/* Setup some dummy HV pool VPs */
@@ -634,10 +634,15 @@ bool __init xive_native_init(void)
if (!xive_core_init(np, _native_ops, tima, TM_QW3_HV_PHYS,
max_prio)) {
opal_xive_reset(OPAL_XIVE_MODE_EMU);
- return false;
+ goto err_put;
}
+ of_node_put(np);
pr_info("Using %dkB queues\n", 1 << (xive_queue_shift - 10));
return true;
+
+err_put:
+ of_node_put(np);
+ return false;
}
static bool xive_native_provision_pages(void)
diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c
index 7d5128676e83..d398823d138e 100644
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -717,6 +717,7 @@ static bool __init xive_get_max_prio(u8 *max_prio)
}
reg = of_get_property(rootdn, "ibm,plat-res-int-priorities", );
+ of_node_put(rootdn);
if (!reg) {
pr_err("Failed to read 'ibm,plat-res-int-priorities'
property\n");
return false;
--
2.25.1
[PATCH v4] powerpc/powernv: wire up rng during setup_arch
The platform's RNG must be available before random_init() in order to be
useful for initial seeding, which in turn means that it needs to be
called from setup_arch(), rather than from an init call. Fortunately,
each platform already has a setup_arch function pointer, which means we
can wire it up that way. Complicating things, however, is that POWER8
systems need some per-cpu state and kmalloc, which isn't available at
this stage. So we split things into an early phase and a late phase,
with the early phase working well enough to seed the RNG with a
spinlock, before later getting fast per-cpu allocations. This commit
also removes some noisy log messages that don't add much.
Cc: sta...@vger.kernel.org
Cc: Michael Ellerman
Reviewed-by: Christophe Leroy
Fixes: a4da0d50b2a0 ("powerpc: Implement arch_get_random_long/int() for
powernv")
Signed-off-by: Jason A. Donenfeld
---
arch/powerpc/platforms/powernv/powernv.h | 2 +
arch/powerpc/platforms/powernv/rng.c | 68 ++--
arch/powerpc/platforms/powernv/setup.c | 2 +
3 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/powernv.h
b/arch/powerpc/platforms/powernv/powernv.h
index e297bf4abfcb..fd3f5e1eb10b 100644
--- a/arch/powerpc/platforms/powernv/powernv.h
+++ b/arch/powerpc/platforms/powernv/powernv.h
@@ -42,4 +42,6 @@ ssize_t memcons_copy(struct memcons *mc, char *to, loff_t
pos, size_t count);
u32 __init memcons_get_size(struct memcons *mc);
struct memcons *__init memcons_init(struct device_node *node, const char
*mc_prop_name);
+void powernv_rng_init(void);
+
#endif /* _POWERNV_H */
diff --git a/arch/powerpc/platforms/powernv/rng.c
b/arch/powerpc/platforms/powernv/rng.c
index e3d44b36ae98..c1beced9c32c 100644
--- a/arch/powerpc/platforms/powernv/rng.c
+++ b/arch/powerpc/platforms/powernv/rng.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include "powernv.h"
#define DARN_ERR 0xul
@@ -28,6 +29,12 @@ struct powernv_rng {
static DEFINE_PER_CPU(struct powernv_rng *, powernv_rng);
+static struct {
+ struct powernv_rng rng;
+ spinlock_t lock;
+} early_state __initdata = {
+ .lock = __SPIN_LOCK_UNLOCKED(powernv_early_rng)
+};
int powernv_hwrng_present(void)
{
@@ -84,7 +91,7 @@ static int powernv_get_random_darn(unsigned long *v)
return 1;
}
-static int __init initialise_darn(void)
+static int __init initialize_darn(void)
{
unsigned long val;
int i;
@@ -98,10 +105,18 @@ static int __init initialise_darn(void)
return 0;
}
}
+ return -EIO;
+}
- pr_warn("Unable to use DARN for get_random_seed()\n");
+static int __init powernv_get_random_long_early(unsigned long *v)
+{
+ unsigned long flags;
- return -EIO;
+ spin_lock_irqsave(_state.lock, flags);
+ *v = rng_whiten(_state.rng, in_be64(early_state.rng.regs));
+ spin_unlock_irqrestore(_state.lock, flags);
+
+ return 1;
}
int powernv_get_random_long(unsigned long *v)
@@ -163,32 +178,51 @@ static __init int rng_create(struct device_node *dn)
rng_init_per_cpu(rng, dn);
- pr_info_once("Registering arch random hook.\n");
-
ppc_md.get_random_seed = powernv_get_random_long;
return 0;
}
-static __init int rng_init(void)
+void __init powernv_rng_init(void)
+{
+ struct device_node *dn;
+ struct resource res;
+
+ /* Prefer darn over the rest. */
+ if (!initialize_darn())
+ return;
+
+ dn = of_find_compatible_node(NULL, NULL, "ibm,power-rng");
+ if (!dn)
+ return;
+ if (of_address_to_resource(dn, 0, ))
+ return;
+ early_state.rng.regs_real = (void __iomem *)res.start;
+ early_state.rng.regs = of_iomap(dn, 0);
+ if (!early_state.rng.regs)
+ return;
+ early_state.rng.mask = in_be64(early_state.rng.regs);
+ ppc_md.get_random_seed = powernv_get_random_long_early;
+}
+
+static __init int powernv_rng_late_init(void)
{
struct device_node *dn;
- int rc;
+
+ /*
+* If this didn't get initialized early on, then we're using darn,
+* or this isn't available at all, so return early.
+*/
+ if (ppc_md.get_random_seed != powernv_get_random_long_early)
+ return 0;
+ ppc_md.get_random_seed = NULL;
for_each_compatible_node(dn, NULL, "ibm,power-rng") {
- rc = rng_create(dn);
- if (rc) {
- pr_err("Failed creating rng for %pOF (%d).\n",
- dn, rc);
+ if (rng_create(dn))
continue;
- }
-
/* Create devices for hwrng driver */
of_platform_device_create(dn, NULL, NULL);
}
-
- initialise_darn();
-
return 0;
}
-machine_subsys_initcall(powernv, rng_init);
Re:Re: [PATCH] powerpc: kernel: Change the order of of_node_put()
At 2022-06-20 19:11:33, "Christophe Leroy" wrote: >Hi, > >Le 20/06/2022 à 11:23, Liang He a écrit : >> >> Hi, Christophe. >> >> Sorry to trobule you again. >> >> Now I have found other bugs in same directories (i.e., arch/powerpc/sysdev), >> with the ones I have sent but not recieved acked-by or confirmed email. >> >> So I need to merge the old ones into the new ones as a PATCH-v2 and then >> resend the >> old ones ? >> or just use a new PATCH to send only new ones? >> >> I am afraid to make new trouble for maintainers, so can you share your >> valuable >> experience? >> > >Here is the list of your patches : >https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=84258 > > From my point of view, for all the patches that are still in status >"new" it is better than you send a v2 with more things into a single >patch. When the patch is in "under review" state, it is better to not >update it anymore. > >So in the list there are for instance several patches for powernv, so it >would be good if you can regroup all of them in a single v2 patch. > >Christophe Thanks, Christophe. I will follow your rules and try to group the 'new' state ones.
Re: [PATCH] powerpc: kernel: Change the order of of_node_put()
Hi, Le 20/06/2022 à 11:23, Liang He a écrit : > > Hi, Christophe. > > Sorry to trobule you again. > > Now I have found other bugs in same directories (i.e., arch/powerpc/sysdev), > with the ones I have sent but not recieved acked-by or confirmed email. > > So I need to merge the old ones into the new ones as a PATCH-v2 and then > resend the > old ones ? > or just use a new PATCH to send only new ones? > > I am afraid to make new trouble for maintainers, so can you share your > valuable > experience? > Here is the list of your patches : https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=84258 From my point of view, for all the patches that are still in status "new" it is better than you send a v2 with more things into a single patch. When the patch is in "under review" state, it is better to not update it anymore. So in the list there are for instance several patches for powernv, so it would be good if you can regroup all of them in a single v2 patch. Christophe
Re:Re: [PATCH] powerpc: kernel: Change the order of of_node_put()
At 2022-06-18 16:48:26, "Christophe Leroy" wrote:
>
>
>Le 18/06/2022 à 10:03, Liang He a écrit :
>>
>>
>>
>>
>>
>> 在 2022-06-18 15:13:13，"Christophe Leroy" 写道：
>>>
>>>
>>> Le 17/06/2022 à 13:26, Liang He a écrit :
In add_pcspkr(), it is better to call of_node_put() after the
'if(!np)' check.
>>>
>>> Why is it better ?
>>>
>>>
>>>
>>> /**
>>> * of_node_put() - Decrement refcount of a node
>>> * @node: Node to dec refcount, NULL is supported to simplify writing of
>>> * callers
>>> */
>>> void of_node_put(struct device_node *node)
>>> {
>>> if (node)
>>> kobject_put(>kobj);
>>> }
>>> EXPORT_SYMBOL(of_node_put);
>>>
>>>
>>>
>>> Christophe
>>
>> Hi, Christophe.
>>
>> Thanks for your reply and I want to have a discussion.
>>
>> In my thought, xxx_put(pointer)'s semantic usually means
>> this reference has been used done and will not be used
>> anymore. Is this semantic more reasonable, right?
>>
>> Besides, if the np is NULL, we can just return and save a cpu
>> time for the xxx_put() call.
>>
>> Otherwise, I prefer to call it 'use(check)-after-put'.
>>
>> In fact, I have meet many other 'use(check)-after-put' instances
>> after I send this patch-commit, so I am waiting for this
>> discussion.
>>
>> This is just my thought, it may be wrong.
>>
>> Anyway, thanks for your reply.
>
>Well in principle you are right, in an ideal world it should be like
>that. However, you have to wonder if it is worth the churn. The CPU
>cycle argument is valid only if that function is used in a hot path. But
>as we are talking about error handling, it can't be a hot path.
>
>Taking into account the comment associated of of_node_put : "NULL is
>supported to simplify writing of callers", it means that usage is valid,
>just like it is with function kfree() after a kmalloc().
>
>So in a new developpement, or when doing real modifications to a driver,
>that kind of change can be done ideally. However for drivers that have
>been there for years without any change, ask yourself if it is worth the
>churn. You spend time on it, you require other people to spend time on
>it for reviewing and applying your patches and during that time they
>don't do other things that could have been more usefull.
>
>So unless this change is part of a more global patch, I think it is not
>worth the effort.
>
>By the way, also for all your other patches, I think you should start
>doing all the changes locally on your side, and when you are finished
>try to group things together in bigger patches per area instead of
>sending one by one. I see you have already started doing that for
>opal/powernv for instance, but there are still individual powernv/opal
>in the queue. I think you should group all together in a single patch.
>And same for other areas, please try to minimise the number of patches.
>We don't link huge bombs that modify all the kernel at once, but you can
>group things together, one patch for powerpc core parts, one patch for
>each platform in arch/powerpc/platforms/ etc ...
>
>
>Christophe
Hi, Christophe.
Sorry to trobule you again.
Now I have found other bugs in same directories (i.e., arch/powerpc/sysdev),
with the ones I have sent but not recieved acked-by or confirmed email.
So I need to merge the old ones into the new ones as a PATCH-v2 and then resend
the
old ones ?
or just use a new PATCH to send only new ones?
I am afraid to make new trouble for maintainers, so can you share your valuable
experience?
Thanks very much.
Liang
Re: [PATCH -next v5 2/8] arm64: extable: make uaaccess helper use extable type EX_TYPE_UACCESS_ERR_ZERO
On Mon, Jun 20, 2022 at 10:59:12AM +0800, Tong Tiangen wrote: > 在 2022/6/18 20:40, Mark Rutland 写道: > > On Sat, Jun 18, 2022 at 04:42:06PM +0800, Tong Tiangen wrote: > > > > > > diff --git a/arch/arm64/include/asm/asm-extable.h > > > > > > b/arch/arm64/include/asm/asm-extable.h > > > > > > index 56ebe183e78b..9c94ac1f082c 100644 > > > > > > --- a/arch/arm64/include/asm/asm-extable.h > > > > > > +++ b/arch/arm64/include/asm/asm-extable.h > > > > > > @@ -28,6 +28,14 @@ > > > > > > __ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0) > > > > > > .endm > > > > > > +/* > > > > > > + * Create an exception table entry for uaccess `insn`, which > > > > > > will branch to `fixup` > > > > > > + * when an unhandled fault is taken. > > > > > > + * ex->data = ~0 means both reg_err and reg_zero is set to > > > > > > wzr(x31). > > > > > > + */ > > > > > > + .macro _asm_extable_uaccess, insn, fixup > > > > > > + __ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_UACCESS_ERR_ZERO, ~0) > > > > > > + .endm > > > > > > > > > > I'm not too keen on using `~0` here, since that also sets other bits > > > > > in the > > > > > data field, and its somewhat opaque. > > > > > > > > > > How painful is it to generate the data fields as with the C version > > > > > of this > > > > > macro, so that we can pass in wzr explciitly for the two sub-fields? > > > > > > > > > > Other than that, this looks good to me. > > > > > > > > > > Thanks, > > > > > Mark. > > > > > > > > ok, will fix next version. > > > > > > > > Thanks, > > > > Tong. > > > > > > I tried to using data filelds as with C version, but here assembly code we > > > can not using operator such as << and |, if we use lsl and orr > > > instructions, > > > the gpr will be occupied. > > > > > > So how about using 0x3ff directly here? it means err register and zero > > > register both set to x31. > > > > I had a go at implementing this, and it seems simple enough. Please see: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/extable/asm-uaccess > > > > I made the following modifications, and the other parts are based on your > implementation: > > arch/arm64/include/asm/asm-extable.h > [...] > .macro _asm_extable_uaccess, insn, fixup > _ASM_EXTABLE_UACCESS(\insn, \fixup) > .endm > [...] I also made this same change locally when testing, and building with GCC 11.1.0 or LLVM 14.0.0 I am not seeing any problem when building, and the result is as expected: | [mark@lakrids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- defconfig | *** Default configuration is based on 'defconfig' | # | # No change to .config | # | [mark@lakrids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -j50 arch/arm64/lib/ | CALLscripts/atomic/check-atomics.sh | CC arch/arm64/kernel/asm-offsets.s | CALLscripts/checksyscalls.sh | AS arch/arm64/kernel/vdso/note.o | AS arch/arm64/kernel/vdso/sigreturn.o | LD arch/arm64/kernel/vdso/vdso.so.dbg | VDSOSYM include/generated/vdso-offsets.h | OBJCOPY arch/arm64/kernel/vdso/vdso.so | make[2]: Nothing to be done for 'arch/arm64/lib/'. | AS arch/arm64/lib/clear_page.o | AS arch/arm64/lib/clear_user.o | AS arch/arm64/lib/copy_from_user.o | AS arch/arm64/lib/copy_page.o | AS arch/arm64/lib/copy_to_user.o | CC arch/arm64/lib/csum.o | CC arch/arm64/lib/delay.o | AS arch/arm64/lib/memchr.o | AS arch/arm64/lib/memcmp.o | AS arch/arm64/lib/memcpy.o | AS arch/arm64/lib/memset.o | AS arch/arm64/lib/strchr.o | AS arch/arm64/lib/strcmp.o | AS arch/arm64/lib/strlen.o | AS arch/arm64/lib/strncmp.o | AS arch/arm64/lib/strnlen.o | AS arch/arm64/lib/strrchr.o | AS arch/arm64/lib/tishift.o | AS arch/arm64/lib/crc32.o | AS arch/arm64/lib/mte.o | CC [M] arch/arm64/lib/xor-neon.o | AR arch/arm64/lib/built-in.a | AR arch/arm64/lib/lib.a | [mark@lakrids:~/src/linux]% usekorg 12.1.0 aarch64-linux-objdump -j __ex_table -D arch/arm64/lib/clear_user.o | | arch/arm64/lib/clear_user.o: file format elf64-littleaarch64 | | | Disassembly of section __ex_table: | | <__ex_table>: | ... |8: 03ff0003.inst 0x03ff0003 ; undefined | ... | 14: 03ff0003.inst 0x03ff0003 ; undefined | ... | 20: 03ff0003.inst 0x03ff0003 ; undefined | ... | 2c: 03ff0003.inst 0x03ff0003 ; undefined | ... | 38: 03ff0003.inst 0x03ff0003 ; undefined | ... | 44: 03ff0003.inst 0x03ff0003 ; undefined > The following errors are reported during compilation: > [...] > arch/arm64/lib/clear_user.S:45: Error: invalid operands (*ABS* and *UND* > sections) for `<<' > [...] As above, I'm not seeing this. This suggests that the EX_DATA_REG() macro is going
[PATCH v5 5/5] powerpc/crash hp: add crash page helper functions
Define arch_[un]map_crash_pages functions to avoid build issues due to
undefined arch specific function to access crash memory pages.
A temporary patch to avoid build issues may need some changes in
generic code to avoid this.
The issue is under discussion:
https://lkml.org/lkml/2022/6/20/22
Signed-off-by: Sourabh Jain
---
arch/powerpc/kexec/core_64.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index 373cb46bcc0e..d833fa96dcfa 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -492,6 +492,13 @@ int update_cpus_node(void *fdt)
#if defined(CONFIG_HOTPLUG_CPU)
+void *arch_map_crash_pages(unsigned long paddr, unsigned long size)
+{
+ return __va(paddr);
+}
+
+void arch_unmap_crash_pages(void **ptr) { }
+
int crash_hotplug_support(void) { return 1; }
/**
--
2.36.1
[PATCH v5 4/5] powerpc/crash hp: add crash hotplug support for kexec_load
A common crash hotplug handler is used for both kexec_load and
kexec_file_load, which is already implemented in earlier patches while
adding support for kexec_file_load.
To enable the crash hotplug handler to work for kexec_load case the
fdt_index attribute of kimage_arch needs to be populated with index of
FDT segment in kexec segment array.
After loading kexec segments the FDT segment is identified by looping
through all the kexec segments and fdt_index is updated accordingly.
Signed-off-by: Sourabh Jain
---
arch/powerpc/kexec/core_64.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index 6d448b55dfad..373cb46bcc0e 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -74,6 +74,31 @@ int machine_kexec_prepare(struct kimage *image)
return 0;
}
+#if defined(CONFIG_HOTPLUG_CPU)
+int machine_kexec_post_load(struct kimage *kimage)
+{
+ int i;
+ void *ptr;
+ unsigned long mem;
+
+ if (kimage->type != KEXEC_TYPE_CRASH)
+ return 0;
+
+ /* Mark fdt_index invalid */
+ kimage->arch.fdt_index = -1;
+
+ for (i = 0; i < kimage->nr_segments; i++) {
+ mem = kimage->segment[i].mem;
+ ptr = __va(mem);
+
+ if (ptr && fdt_magic(ptr) == FDT_MAGIC)
+ kimage->arch.fdt_index = i;
+ }
+
+ return 0;
+}
+#endif
+
/* Called during kexec sequence with MMU off */
static notrace void copy_segments(unsigned long ind)
{
--
2.36.1
[PATCH v5 3/5] powerpc/crash hp: add crash hotplug support for kexec_file_load
Two major changes are done to enable the crash CPU hotplug handler.
Firstly, updated the kexec load path to prepare kimage for hotplug
changes, and secondly, implemented the arch specific crash hotplug
handler.
On the kexec load path, the memsz allocation for the crash FDT segment
is updated to ensure that it has sufficient buffer space to accommodate
future hot add CPUs. Additionally, kimage_arch struct member fdt_index
is initialized with the index of FDT segment in kexec segment array.
The crash hotplug handler updates the cpus node of crash FDT. While we
update crash FDT the kexec_crash_image is marked invalid and restored
after FDT update to avoid race.
Since memory crash hotplug support is not there yet the crash hotplug
handler simply warns the user and returns.
Signed-off-by: Sourabh Jain
---
arch/powerpc/kexec/core_64.c | 49
arch/powerpc/kexec/elf_64.c | 74 +++
arch/powerpc/kexec/file_load_64.c | 5 +++
3 files changed, 128 insertions(+)
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index 65b3afb2169a..6d448b55dfad 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -465,6 +465,55 @@ int update_cpus_node(void *fdt)
return ret;
}
+#if defined(CONFIG_HOTPLUG_CPU)
+
+int crash_hotplug_support(void) { return 1; }
+
+/**
+ * arch_crash_hotplug_handler() - Handle hotplug kexec segements changes FDT,
elfcorehdr
+ * @image: the active struct kimage
+ * @hp_action: the hot un/plug action being handled
+ * @cpu: when KEXEC_CRASH_HP_ADD/REMOVE_CPU, the cpu affected
+ *
+ * To accurately reflect CPU hot un/plug changes, the FDT
+ * must be updated with the new list of CPUs.
+ */
+void arch_crash_handle_hotplug_event(struct kimage *image,
+unsigned int hp_action, unsigned int cpu)
+
+{
+ void *fdt;
+
+ /* No action needed for CPU hot-unplug */
+ if (hp_action == KEXEC_CRASH_HP_REMOVE_CPU)
+ return;
+
+ /* crash update on memory hotplug is not support yet */
+ if (hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY || hp_action ==
KEXEC_CRASH_HP_ADD_MEMORY) {
+ pr_info_once("crash hp: crash update is not supported with
memory hotplug\n");
+ return;
+ }
+
+ /* Must have valid FDT index */
+ if (!image->arch.fdt_index < 0) {
+ pr_err("crash hp: unable to locate FDT segment");
+ return;
+ }
+
+ fdt = __va((void *)image->segment[image->arch.fdt_index].mem);
+
+ /* Temporarily invalidate the crash image while it is replaced */
+ xchg(_crash_image, NULL);
+
+ /* update FDT to refelect changes to CPU resrouces */
+ if (update_cpus_node(fdt))
+ pr_err("crash hp: failed to update crash FDT");
+
+ /* The crash image is now valid once again */
+ xchg(_crash_image, image);
+}
+#endif
+
#ifdef CONFIG_PPC_64S_HASH_MMU
/* Values we need to export to the second kernel via the device tree. */
static unsigned long htab_base;
diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
index eeb258002d1e..8ef18d6c3c32 100644
--- a/arch/powerpc/kexec/elf_64.c
+++ b/arch/powerpc/kexec/elf_64.c
@@ -24,6 +24,68 @@
#include
#include
+#include
+#include
+
+#if defined(CONFIG_HOTPLUG_CPU)
+/**
+ * get_cpu_node_sz() - Calculate the space needed to store a CPU device
+ *type node in FDT. The calculation is done based on
+ *the existing CPU node in unflatten device tree. Loop
+ *through all the properties of the very first CPU type
+ *device node found in unflatten device tree and returns
+ *the sum of the property length and property string size
+ *of all properties of a CPU node.
+ */
+static int get_cpu_node_sz(void)
+{
+ struct device_node *dn = NULL;
+ struct property *pp;
+ int cpu_node_size = 0;
+
+ dn = of_find_node_by_type(NULL, "cpu");
+
+ if (!dn) {
+ pr_warn("Unable to locate cpu device_type node.\n");
+ goto out;
+ }
+
+ /* Every node in FDT starts with FDT_BEGIN_NODE and ends with
+* FDT_END_NODE that takes one byte each.
+*/
+ cpu_node_size = 2;
+
+ for_each_property_of_node(dn, pp) {
+ /**
+* For each property add two bytes extra. One for string null
+* character for property name and other for FDT property start
+* tag FDT_PROP.
+*/
+ cpu_node_size = cpu_node_size + pp->length + strlen(pp->name) +
2;
+ }
+
+out:
+ return cpu_node_size;
+}
+
+/*
+ * get_crash_fdt_mem_sz() - calcuate mem size for crash kernel FDT
+ * @fdt: pointer to crash kernel FDT
+ *
+ * Calculate the buffer space needed to accommodate more CPU nodes in
+ * crash FDT post
[PATCH v5 1/5] powerpc/kexec: make update_cpus_node non-static
Make the update_cpus_node function non-static and export it for
usage in other kexec components.
The update_cpus_node definition is moved to core_64.c so that it
can be used with both kexec_load and kexec_file_load system calls.
No functional change intended.
Signed-off-by: Sourabh Jain
---
arch/powerpc/include/asm/kexec.h | 1 +
arch/powerpc/kexec/core_64.c | 88 +++
arch/powerpc/kexec/file_load_64.c | 87 --
3 files changed, 89 insertions(+), 87 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 2aefe14e1442..c8040c93b15a 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -129,6 +129,7 @@ unsigned int kexec_extra_fdt_size_ppc64(struct kimage
*image);
int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
unsigned long initrd_load_addr,
unsigned long initrd_len, const char *cmdline);
+int update_cpus_node(void *fdt);
#endif /* CONFIG_PPC64 */
#endif /* CONFIG_KEXEC_FILE */
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index 6cc7793b8420..65b3afb2169a 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -377,6 +378,93 @@ void default_machine_kexec(struct kimage *image)
/* NOTREACHED */
}
+/**
+ * add_node_props - Reads node properties from device node structure and add
+ * them to fdt.
+ * @fdt:Flattened device tree of the kernel
+ * @node_offset:offset of the node to add a property at
+ * @dn: device node pointer
+ *
+ * Returns 0 on success, negative errno on error.
+ */
+static int add_node_props(void *fdt, int node_offset, const struct device_node
*dn)
+{
+ int ret = 0;
+ struct property *pp;
+
+ if (!dn)
+ return -EINVAL;
+
+ for_each_property_of_node(dn, pp) {
+ ret = fdt_setprop(fdt, node_offset, pp->name, pp->value,
pp->length);
+ if (ret < 0) {
+ pr_err("Unable to add %s property: %s\n", pp->name,
fdt_strerror(ret));
+ return ret;
+ }
+ }
+ return ret;
+}
+
+/**
+ * update_cpus_node - Update cpus node of flattened device tree using of_root
+ *device node.
+ * @fdt: Flattened device tree of the kernel.
+ *
+ * Returns 0 on success, negative errno on error.
+ */
+int update_cpus_node(void *fdt)
+{
+ struct device_node *cpus_node, *dn;
+ int cpus_offset, cpus_subnode_offset, ret = 0;
+
+ cpus_offset = fdt_path_offset(fdt, "/cpus");
+ if (cpus_offset < 0 && cpus_offset != -FDT_ERR_NOTFOUND) {
+ pr_err("Malformed device tree: error reading /cpus node: %s\n",
+ fdt_strerror(cpus_offset));
+ return cpus_offset;
+ }
+
+ if (cpus_offset > 0) {
+ ret = fdt_del_node(fdt, cpus_offset);
+ if (ret < 0) {
+ pr_err("Error deleting /cpus node: %s\n",
fdt_strerror(ret));
+ return -EINVAL;
+ }
+ }
+
+ /* Add cpus node to fdt */
+ cpus_offset = fdt_add_subnode(fdt, fdt_path_offset(fdt, "/"), "cpus");
+ if (cpus_offset < 0) {
+ pr_err("Error creating /cpus node: %s\n",
fdt_strerror(cpus_offset));
+ return -EINVAL;
+ }
+
+ /* Add cpus node properties */
+ cpus_node = of_find_node_by_path("/cpus");
+ ret = add_node_props(fdt, cpus_offset, cpus_node);
+ of_node_put(cpus_node);
+ if (ret < 0)
+ return ret;
+
+ /* Loop through all subnodes of cpus and add them to fdt */
+ for_each_node_by_type(dn, "cpu") {
+ cpus_subnode_offset = fdt_add_subnode(fdt, cpus_offset,
dn->full_name);
+ if (cpus_subnode_offset < 0) {
+ pr_err("Unable to add %s subnode: %s\n", dn->full_name,
+ fdt_strerror(cpus_subnode_offset));
+ ret = cpus_subnode_offset;
+ goto out;
+ }
+
+ ret = add_node_props(fdt, cpus_subnode_offset, dn);
+ if (ret < 0)
+ goto out;
+ }
+out:
+ of_node_put(dn);
+ return ret;
+}
+
#ifdef CONFIG_PPC_64S_HASH_MMU
/* Values we need to export to the second kernel via the device tree. */
static unsigned long htab_base;
diff --git a/arch/powerpc/kexec/file_load_64.c
b/arch/powerpc/kexec/file_load_64.c
index 07da6bf1cf24..57f991b0a9da 100644
--- a/arch/powerpc/kexec/file_load_64.c
+++ b/arch/powerpc/kexec/file_load_64.c
@@ -951,93 +951,6 @@ unsigned int kexec_extra_fdt_size_ppc64(struct kimage
*image)
return (unsigned int)(usm_entries * sizeof(u64));
}
-/**
-
[PATCH v5 2/5] powerpc/crash hp: update kimage_arch struct
Once the kimage is prepared the only way to identify which kexec segment
holds FDT is by looping through all kexec segments. To avoid this a new
member "fdt_index" is added to kimage_arch struct. The new member holds
the index of FDT segment in the kexec segment array which gives direct
access to FDT segment.
The fdt_index will be populated during kexec load for both kexec_load
and kexec_file_load case.
Signed-off-by: Sourabh Jain
---
arch/powerpc/include/asm/kexec.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index c8040c93b15a..9489e5ca93fb 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -106,6 +106,9 @@ extern const struct kexec_file_ops kexec_elf64_ops;
struct kimage_arch {
struct crash_mem *exclude_ranges;
+#if defined(CONFIG_HOTPLUG_CPU)
+ int fdt_index;
+#endif
unsigned long backup_start;
void *backup_buf;
void *fdt;
--
2.36.1
[PATCH v5 0/5] In kernel handling of CPU hotplug events for crash kernel
This patch series implements the crash hotplug handler on PowerPC introduced
by https://lkml.org/lkml/2022/6/13/3382 patch series.
The Problem:
Post hotplug/DLPAR events the capture kernel holds stale information about the
system. Dump collection with stale capture kernel might end up in dump capture
failure or an inaccurate dump collection.
Existing solution:
==
The existing solution to keep the capture kernel up-to-date is observe the
hotplug event via udev rule and trigger a full capture kernel reload post
hotplug event.
Shortcomings:
- Leaves a window where kernel crash might not lead to successful dump
collection.
- Reloading all kexec components for each hotplug is inefficient. Since only
one or two kexec components need to be updated due to hotplug event reloading
all kexec component is redundant.
- udev rules are prone to races if hotplug events are frequent.
More about issues with an existing solution is posted here:
- https://lkml.org/lkml/2020/12/14/532
- https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-February/240254.html
Proposed Solution:
==
Instead of reloading all kexec segments on hotplug event, this patch series
focuses on updating only the relevant kexec segment. Once the kexec
segments are loaded in the kernel reserved area then an arch-specific hotplug
handler
will update the relevant kexec segment based on hotplug event type.
As mentioned above this patch series implemented a PowerPC crash hotplug
handler for the CPU. The crash hotplug handler memory is in our TODO list.
A couple of minor changes are required to realize the benefit of the patch
series:
- disalble the udev rule:
comment out the below line in kdump udev rule file:
RHEL: /usr/lib/udev/rules.d/98-kexec.rules
# SUBSYSTEM=="cpu", ACTION=="online", GOTO="kdump_reload_cpu"
- kexec tool needs to be updated with patch for kexec_load system call
to work (not needed if -s option is used during kexec panic load):
---
diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c
b/kexec/arch/ppc64/kexec-elf-ppc64.c
index 695b8b0..1dc6490 100644
--- a/kexec/arch/ppc64/kexec-elf-ppc64.c
+++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
@@ -45,6 +45,29 @@ uint64_t initrd_base, initrd_size;
unsigned char reuse_initrd = 0;
const char *ramdisk;
+#define MAX_CORE 256
+#define PER_CORE_NODE_SIZE 1500
+
+/**
+ * get_crash_fdt_mem_sz() - calcuate mem size for crash kernel FDT
+ * @fdt: pointer to crash kernel FDT
+ *
+ * Calculate the buffer space needed to add more CPU nodes in FDT after
+ * capture kenrel load due to hot add events.
+ *
+ * Some assumption are made to calculate the additional buffer size needed
+ * to accommodate future hot add CPUs to the crash FDT. The maximum core count
+ * in the system would not go beyond MAX_CORE and memory needed to store per
core
+ * date in FDT is PER_CORE_NODE_SIZE.
+ *
+ * Certainly MAX_CORE count can be replaced with possible core count and
+ * PER_CORE_NODE_SIZE to some standard value instead of randomly observed
+ * core size value on Power9 LPAR.
+ */
+static unsigned int get_crash_fdt_mem_sz(void *fdt) {
+ return fdt_totalsize(fdt) + (PER_CORE_NODE_SIZE * MAX_CORE);
+}
+
int elf_ppc64_probe(const char *buf, off_t len)
{
struct mem_ehdr ehdr;
@@ -179,6 +202,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf,
off_t len,
uint64_t max_addr, hole_addr;
char *seg_buf = NULL;
off_t seg_size = 0;
+ unsigned int mem_sz = 0;
struct mem_phdr *phdr;
size_t size;
#ifdef NEED_RESERVE_DTB
@@ -329,7 +353,13 @@ int elf_ppc64_load(int argc, char **argv, const char *buf,
off_t len,
if (result < 0)
return result;
- my_dt_offset = add_buffer(info, seg_buf, seg_size, seg_size,
+ if (info->kexec_flags & KEXEC_ON_CRASH) {
+ mem_sz = get_crash_fdt_mem_sz((void *)seg_buf);
+ fdt_set_totalsize(seg_buf, mem_sz);
+ info->fdt_index = info->nr_segments;
+ }
+
+ my_dt_offset = add_buffer(info, seg_buf, seg_size, mem_sz,
0, 0, max_addr, -1);
#ifdef NEED_RESERVE_DTB
diff --git a/kexec/kexec.c b/kexec/kexec.c
index f63b36b..846b1a8 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -672,6 +672,9 @@ static void update_purgatory(struct kexec_info *info)
if (info->segment[i].mem == (void *)info->rhdr.rel_addr) {
continue;
}
+ if (info->fdt_index == i)
+ continue;
+
sha256_update(, info->segment[i].buf,
info->segment[i].bufsz);
nullsz = info->segment[i].memsz - info->segment[i].bufsz;
diff --git a/kexec/kexec.h b/kexec/kexec.h
index 595dd68..0906a1b 100644
--- a/kexec/kexec.h
+++ b/kexec/kexec.h
@@ -169,6 +169,7 @@ struct kexec_info {
int command_line_len;
[PATCH] powerpc/embedded6xx/ls_uart: Add missing of_node_put()
In ls_uarts_init(), we need to add a of_node_put() to keep refcount balance. Signed-off-by: Liang He --- arch/powerpc/platforms/embedded6xx/ls_uart.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/powerpc/platforms/embedded6xx/ls_uart.c index 0133e175a0fc..4ecbc55b37c0 100644 --- a/arch/powerpc/platforms/embedded6xx/ls_uart.c +++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c @@ -124,6 +124,8 @@ static int __init ls_uarts_init(void) avr_clock = *(u32*)of_get_property(avr, "clock-frequency", ); phys_addr = ((u32*)of_get_property(avr, "reg", ))[0]; + of_node_put(avr); + if (!avr_clock || !phys_addr) return -EINVAL; -- 2.25.1
[PATCH] powerpc/powernv: Fix refcount leak bug in idle.c
In pnv_parse_cpuidle_dt(), of_find_node_by_path() will return a node pointer with refcount incremented. We should use of_node_put() in fail path or when it is not used anymore. Signed-off-by: Liang He --- arch/powerpc/platforms/powernv/idle.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c index 6f94b808dd39..c1b369c7f507 100644 --- a/arch/powerpc/platforms/powernv/idle.c +++ b/arch/powerpc/platforms/powernv/idle.c @@ -1419,6 +1419,7 @@ static int __init pnv_parse_cpuidle_dt(void) kfree(temp_u32); kfree(temp_u64); kfree(temp_string); + of_node_put(np); return rc; } -- 2.25.1
[PATCH] powerpc: Remove _PAGE_SAO stub for book3e/64
Since commit 634093c59a12 ("powerpc/mm: enable
ARCH_HAS_VM_GET_PAGE_PROT"), _PAGE_SAO is used only in
arch/powerpc/mm/book3s64/pgtable.c
The _PAGE_SAO stub defined as 0 for book3e/64 can be removed.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h
b/arch/powerpc/include/asm/nohash/64/pgtable.h
index 57083f95e82b..25b72b2b30ce 100644
--- a/arch/powerpc/include/asm/nohash/64/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -83,8 +83,6 @@
*/
#include
-#define _PAGE_SAO 0
-
#define PTE_RPN_MASK (~((1UL << PTE_RPN_SHIFT) - 1))
/*
--
2.36.1
Re: [PATCH v2 4/4] watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers
On 6/3/22 03:53, Scott Cheloha wrote: PAPR v2.12 defines a new hypercall, H_WATCHDOG. The hypercall permits guest control of one or more virtual watchdog timers. The timers have millisecond granularity. The guest is terminated when a timer expires. This patch adds a watchdog driver for these timers, "pseries-wdt". pseries_wdt_probe() currently assumes the existence of only one platform device and always assigns it watchdogNumber 1. If we ever expose more than one timer to userspace we will need to devise a way to assign a distinct watchdogNumber to each platform device at device registration time. Signed-off-by: Scott Cheloha Besides the patch ordering and 0444 vs. 0644 (which is up to the PPC maintainer to decide anyway :) ), looks good to me. Reviewed-by: Alexey Kardashevskiy --- .../watchdog/watchdog-parameters.rst | 12 + drivers/watchdog/Kconfig | 8 + drivers/watchdog/Makefile | 1 + drivers/watchdog/pseries-wdt.c| 264 ++ 4 files changed, 285 insertions(+) create mode 100644 drivers/watchdog/pseries-wdt.c diff --git a/Documentation/watchdog/watchdog-parameters.rst b/Documentation/watchdog/watchdog-parameters.rst index 223c99361a30..29153eed6689 100644 --- a/Documentation/watchdog/watchdog-parameters.rst +++ b/Documentation/watchdog/watchdog-parameters.rst @@ -425,6 +425,18 @@ pnx833x_wdt: - +pseries-wdt: +action: + Action taken when watchdog expires: 0 (power off), 1 (restart), + 2 (dump and restart). (default=1) +timeout: + Initial watchdog timeout in seconds. (default=60) +nowayout: + Watchdog cannot be stopped once started. + (default=kernel config parameter) + +- + rc32434_wdt: timeout: Watchdog timeout value, in seconds (default=20) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index c4e82a8d863f..06b412603f3e 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1932,6 +1932,14 @@ config MEN_A21_WDT # PPC64 Architecture +config PSERIES_WDT + tristate "POWER Architecture Platform Watchdog Timer" + depends on PPC_PSERIES + select WATCHDOG_CORE + help + Driver for virtual watchdog timers provided by PAPR + hypervisors (e.g. PowerVM, KVM). + config WATCHDOG_RTAS tristate "RTAS watchdog" depends on PPC_RTAS diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index f7da867e8782..f35660409f17 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -184,6 +184,7 @@ obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o obj-$(CONFIG_MEN_A21_WDT) += mena21_wdt.o # PPC64 Architecture +obj-$(CONFIG_PSERIES_WDT) += pseries-wdt.o obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o # S390 Architecture diff --git a/drivers/watchdog/pseries-wdt.c b/drivers/watchdog/pseries-wdt.c new file mode 100644 index ..cfe53587457d --- /dev/null +++ b/drivers/watchdog/pseries-wdt.c @@ -0,0 +1,264 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +/* + * Copyright (c) 2022 International Business Machines, Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRV_NAME "pseries-wdt" + +/* + * The PAPR's MSB->LSB bit ordering is 0->63. These macros simplify + * defining bitfields as described in the PAPR without needing to + * transpose values to the more C-like 63->0 ordering. + */ +#define SETFIELD(_v, _b, _e) \ + (((unsigned long)(_v) << PPC_BITLSHIFT(_e)) & PPC_BITMASK((_b), (_e))) +#define GETFIELD(_v, _b, _e) \ + (((unsigned long)(_v) & PPC_BITMASK((_b), (_e))) >> PPC_BITLSHIFT(_e)) + +/* + * The H_WATCHDOG hypercall first appears in PAPR v2.12 and is + * described fully in sections 14.5 and 14.15.6. + * + * + * H_WATCHDOG Input + * + * R4: "flags": + * + * Bits 48-55: "operation" + * + * 0x01 Start Watchdog + * 0x02 Stop Watchdog + * 0x03 Query Watchdog Capabilities + */ +#define PSERIES_WDTF_OP(op)SETFIELD((op), 48, 55) +#define PSERIES_WDTF_OP_START PSERIES_WDTF_OP(0x1) +#define PSERIES_WDTF_OP_STOP PSERIES_WDTF_OP(0x2) +#define PSERIES_WDTF_OP_QUERY PSERIES_WDTF_OP(0x3) + +/* + * Bits 56-63: "timeoutAction" (for "Start Watchdog" only) + * + * 0x01 Hard poweroff + * 0x02 Hard restart + * 0x03 Dump restart + */ +#define PSERIES_WDTF_ACTION(ac)SETFIELD(ac, 56, 63) +#define PSERIES_WDTF_ACTION_HARD_POWEROFF PSERIES_WDTF_ACTION(0x1) +#define PSERIES_WDTF_ACTION_HARD_RESTART PSERIES_WDTF_ACTION(0x2) +#define PSERIES_WDTF_ACTION_DUMP_RESTART PSERIES_WDTF_ACTION(0x3) + +/* + * H_WATCHDOG Output + * + * R3: Return code + * + * H_SUCCESSThe
