The kernel uses 3100 to indicate ISA version 3.1, not 3010, so
fix the Microwatt device tree to use 3100.
Signed-off-by: Paul Mackerras
---
arch/powerpc/boot/dts/microwatt.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/microwatt.dts
b/arch/powerpc
From: "J. Neuschäfer"
The standard property for the model name is called "model".
Signed-off-by: J. Neuschäfer
---
Changes in v2:
- Rebase on v6.15-rc1 (no changes except line numbers)
- Link to v1:
https://lore.kernel.org/r/20241225-microwatt-v1-1-8e071fcfc...@posteo.net
---
arch/powerpc/boo
On Wed, Jan 29, 2025 at 06:20:31PM +1000, Nicholas Piggin wrote:
> Perfectly reasonable to not add broadcast tlbie in microwatt.
If you call "the easy way out" reasonable, then sure. This pretty
trivial hardware addition causes so many software headaches whenn
missing, it isn't funny. "Friends d
On Wed, Jan 29, 2025 at 06:18:54PM +1100, Paul Mackerras wrote:
> Interesting. I looked in my copy of v2.07 (PowerISA_V2.07_PUBLIC.pdf)
> and it mentions rfscv in a couple of places, but has no description of
> scv or rfscv. I'll change it to v3.0.
Huh, rfscv is 3.0 and later according to later
On Wed, Jan 29, 2025 at 04:36:14PM +1000, Nicholas Piggin wrote:
> On Wed Jan 29, 2025 at 8:52 AM AEST, Paul Mackerras wrote:
> > Microwatt now implements ISA v3.1 (SFFS compliancy subset), including
> > prefixed instructions, scv/rfscv, and the FSCR, HFSCR, TAR, and CTRL
> > registers. The privil
On Wed, Jan 29, 2025 at 09:52:09AM +1100, Paul Mackerras wrote:
> - isa = <3000>;
> + isa = <3010>;
Does this mean 3.1, or 3.01? If the former, can this also encode 3.1C?
Should uwatt say to support that?
> little-endian {
> -
Microwatt now implements ISA v3.1 (SFFS compliancy subset), including
prefixed instructions, scv/rfscv, and the FSCR, HFSCR, TAR, and CTRL
registers. The privileged mode of operation is now hypervisor mode
and there is no privileged non-hypervisor mode; the MSR[HV] bit is
forced to 1.
Besides upd
e it would actually have any measurable performance benefit. When
> I saw it was optional in the ISA for LCS and below, and that the
> kernel has all the machinery for handling the cross-CPU invalidations
> via IPI, it became very much the path of least resistance to use the
> kernel
On Wed, Jan 29, 2025 at 04:36:14PM +1000, Nicholas Piggin wrote:
> On Wed Jan 29, 2025 at 8:52 AM AEST, Paul Mackerras wrote:
> > Microwatt now implements ISA v3.1 (SFFS compliancy subset), including
> > prefixed instructions, scv/rfscv, and the FSCR, HFSCR, TAR, and CTRL
> > registers. The privil
On Wed Jan 29, 2025 at 8:52 AM AEST, Paul Mackerras wrote:
> Microwatt now implements ISA v3.1 (SFFS compliancy subset), including
> prefixed instructions, scv/rfscv, and the FSCR, HFSCR, TAR, and CTRL
> registers. The privileged mode of operation is now hypervisor mode
> and there is no privilege
Microwatt now implements ISA v3.1 (SFFS compliancy subset), including
prefixed instructions, scv/rfscv, and the FSCR, HFSCR, TAR, and CTRL
registers. The privileged mode of operation is now hypervisor mode
and there is no privileged non-hypervisor mode; the MSR[HV] bit is
forced to 1.
Besides upd
From: "J. Neuschäfer"
The standard property for the model name is called "model".
Signed-off-by: J. Neuschäfer
---
arch/powerpc/boot/dts/microwatt.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/microwatt.dts
b/arch/powerpc/boot/dts/microwatt.dts
> event is handled in the user space (drmgr tool). For the DLPAR
>> > IO ADD, the corresponding device tree nodes and properties will
>> > be added to the device tree after the device enable. The user
>> > space (drmgr tool) uses configure_connector RTAS call with the
&
). For the DLPAR
> > IO ADD, the corresponding device tree nodes and properties will
> > be added to the device tree after the device enable. The user
> > space (drmgr tool) uses configure_connector RTAS call with the
> > DRC index to retrieve the device nodes and updates the de
Hi Haren,
One query below about the of_node refcounting.
Haren Myneni writes:
> In the powerpc-pseries specific implementation, the IO hotplug
> event is handled in the user space (drmgr tool). For the DLPAR
> IO ADD, the corresponding device tree nodes and properties will
> be
In the powerpc-pseries specific implementation, the IO hotplug
event is handled in the user space (drmgr tool). For the DLPAR
IO ADD, the corresponding device tree nodes and properties will
be added to the device tree after the device enable. The user
space (drmgr tool) uses configure_connector
In the powerpc-pseries specific implementation, the IO hotplug
event is handled in the user space (drmgr tool). But update the
device tree and /dev/mem access to allocate buffers for some
RTAS calls are restricted when the kernel lockdown feature is
enabled. For the DLPAR IO REMOVE, the
suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Haren-Myneni/powerpc-pseries-dlpar-Add-device-tree-nodes-for-DLPAR-IO-add/20240817-115833
base: https://git.kernel.org/pub/scm/li
suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Haren-Myneni/powerpc-pseries-dlpar-Add-device-tree-nodes-for-DLPAR-IO-add/20240817-115833
base: https://git.kernel.org/pub/scm/li
In the powerpc-pseries specific implementation, the IO hotplug
event is handled in the user space (drmgr tool). But update the
device tree and /dev/mem access to allocate buffers for some
RTAS calls are restricted when the kernel lockdown feature is
enabled. For the DLPAR IO REMOVE, the
In the powerpc-pseries specific implementation, the IO hotplug
event is handled in the user space (drmgr tool). For the DLPAR
IO ADD, the corresponding device tree nodes and properties will
be added to the device tree after the device enable. The user
space (drmgr tool) uses configure_connector
For the DLPAR IO ADD, the corresponding device tree nodes and
properties will be added to the device tree after enable the
device. The user space (drmgr tool) uses configure_connector
RTAS call with the DRC index to retrieve the corresponding
device nodes but this RTAS call needs /dev/mem access
For the DLPAR IO REMOVE, the corresponding device tree nodes and
properties have to be removed from the device tree after disable
the device. In the current implementation, the user space (drmgr
tool) remove the device tree nodes by updating /proc/ppc64/ofdt
which needs /dev/mem. But /dev/mem
For the DLPAR IO REMOVE, the corresponding device tree nodes and
properties have to be removed from the device tree after disable
the device. In the current implementation, the user space (drmgr
tool) remove the device tree nodes by updating /proc/ppc64/ofdt
which needs /dev/mem. But /dev/mem
For the DLPAR IO ADD, the corresponding device tree nodes and
properties will be added to the device tree after enable the
device. The user space (drmgr tool) uses configure_connector
RTAS call with the DRC index to retrieve the corresponding
device nodes but this RTAS call needs /dev/mem access
This is effectively a revert of commit 6ea4c0fe4570 ("soc/fsl/qbman:
Update device tree with reserved memory").
What that commit intended to do: Fix up the device tree that is passed
to a subsequent kexec-loaded kernel, so that the reserved-memory nodes
have the same base addres
With the driver for nxp,lpc3220-dmamux we can remove the pl08x platform
data and let pl08x driver to create peripheral channels from the DT
properties.
Signed-off-by: Piotr Wojtaszczyk
---
Changes for v4:
- This patch is new in v4
arch/arm/mach-lpc32xx/phy3250.c | 54 ---
On 21/06/2024 07:56, Markus Elfring wrote:
>> With the driver for nxp,lpc3220-dmamux we can remove the pl08x platform
>> data and let pl08x driver to create peripheral channels from the DT
>> properties.
>
> Do you see opportunities to improve such a change description?
> https://git.kernel.org/pu
> With the driver for nxp,lpc3220-dmamux we can remove the pl08x platform
> data and let pl08x driver to create peripheral channels from the DT
> properties.
Do you see opportunities to improve such a change description?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docum
With the driver for nxp,lpc3220-dmamux we can remove the pl08x platform
data and let pl08x driver to create peripheral channels from the DT
properties.
Signed-off-by: Piotr Wojtaszczyk
---
Changes for v4:
- This patch is new in v4
arch/arm/mach-lpc32xx/phy3250.c | 54 ---
The of_device_is_available() check only needs to be done once per device
node, there's no need to repeat it for each thread. Move it out of the
loop.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/setup-common.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --g
Hi Shawn,
thanks for your feedback.
Am Donnerstag, 26. Januar 2023, 10:44:21 CET schrieb Shawn Guo:
> On Fri, Jan 20, 2023 at 02:34:47PM +0100, Alexander Stein wrote:
> > Add device tree for the MBLS102xA mainboard with TQMLS1021A SoM.
> >
> > Signed-off-by: Alexander Stein
On Fri, Jan 20, 2023 at 02:34:47PM +0100, Alexander Stein wrote:
> Add device tree for the MBLS102xA mainboard with TQMLS1021A SoM.
>
> Signed-off-by: Alexander Stein
> ---
> Changes in v2:
> * Remove unnecessary status = "okay"
> * Remove underscore from node
Add device tree for the MBLS102xA mainboard with TQMLS1021A SoM.
Signed-off-by: Alexander Stein
---
Changes in v3:
* None
Changes in v2:
* Remove unnecessary status = "okay"
* Remove underscore from node names
* Move reg direct below compatiblefor i2c devices
* Remove i2c device nod
Add device tree for the MBLS102xA mainboard with TQMLS1021A SoM.
Signed-off-by: Alexander Stein
---
Changes in v2:
* Remove unnecessary status = "okay"
* Remove underscore from node names
* Move reg direct below compatiblefor i2c devices
* Remove i2c device nodes without software suppo
From: Nathan Lynch
[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
From: Nathan Lynch
[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
From: Nathan Lynch
[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
From: Nathan Lynch
[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
From: Nathan Lynch
[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
From: Nathan Lynch
[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
From: Nathan Lynch
[ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
rtas_os_term() is called during panic. Its behavior depends on a couple
of conditions in the /rtas node of the device tree, the traversal of
which entails locking and local IRQ state changes. If the kernel panics
a
>> >> couple of conditions in the /rtas node of the device tree, the
>> >> traversal of which entails locking and local IRQ state changes. If the
>> >> kernel panics while devtree_lock is held, rtas_os_term() as currently
>> >> written could hang.
On Tue Nov 29, 2022 at 4:26 AM AEST, Nathan Lynch wrote:
> "Nicholas Piggin" writes:
> > On Sat Nov 19, 2022 at 1:07 AM AEST, Nathan Lynch wrote:
> >> rtas_os_term() is called during panic. Its behavior depends on a
> >> couple of conditions in t
"Nicholas Piggin" writes:
> On Sat Nov 19, 2022 at 1:07 AM AEST, Nathan Lynch wrote:
>> rtas_os_term() is called during panic. Its behavior depends on a
>> couple of conditions in the /rtas node of the device tree, the
>> traversal of which entails locking and
es where we cache various tokens.
Right... I think it's better practice to use an explicitly sized type
where the data is directly derived from the device tree and ultimately
passed to the firmware call interface. Gradually enacting this while
tolerating some cosmetic inconsistency in the code seems OK to me, but
I'm open to other opinions.
On Sat Nov 19, 2022 at 1:07 AM AEST, Nathan Lynch wrote:
> rtas_os_term() is called during panic. Its behavior depends on a
> couple of conditions in the /rtas node of the device tree, the
> traversal of which entails locking and local IRQ state changes. If the
> kernel panics while
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> rtas_os_term() is called during panic. Its behavior depends on a
> couple of conditions in the /rtas node of the device tree, the
> traversal of which entails locking and local IRQ state changes. If
> the
> kernel panics whi
Add a device tree source file for the Nintendo Wii U video game console.
Signed-off-by: Ash Logan
Co-developed-by: Roberto Van Eeden
Signed-off-by: Roberto Van Eeden
Co-developed-by: Emmanuel Gil Peyrot
Signed-off-by: Emmanuel Gil Peyrot
---
v1->v2: Style and formatting changes suggested
rtas_os_term() is called during panic. Its behavior depends on a
couple of conditions in the /rtas node of the device tree, the
traversal of which entails locking and local IRQ state changes. If the
kernel panics while devtree_lock is held, rtas_os_term() as currently
written could hang.
Instead
if (!early_init_dt_verify(params))
panic("BUG: Failed verifying flat device tree, bad version?");
+ of_scan_flat_dt(early_init_dt_scan_model, NULL);
+
#ifdef CONFIG_PPC_RTAS
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
--
2.37.3
nit_dt_verify(params))
panic("BUG: Failed verifying flat device tree, bad version?");
+ of_scan_flat_dt(early_init_dt_scan_model, NULL);
+
#ifdef CONFIG_PPC_RTAS
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
--
2.37.3
nit_dt_verify(params))
panic("BUG: Failed verifying flat device tree, bad version?");
+ of_scan_flat_dt(early_init_dt_scan_model, NULL);
+
#ifdef CONFIG_PPC_RTAS
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
--
2.37.3
nit_dt_verify(params))
panic("BUG: Failed verifying flat device tree, bad version?");
+ of_scan_flat_dt(early_init_dt_scan_model, NULL);
+
#ifdef CONFIG_PPC_RTAS
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
--
2.37.3
On Mon, 2022-09-26 at 08:16 -0500, Nathan Lynch wrote:
> The /proc/powerpc/ofdt interface allows the root user to freely alter
> the in-kernel device tree, enabling arbitrary physical address writes
> via drivers that could bind to malicious device nodes, thus making it
> possibl
On Mon, Sep 26, 2022 at 9:17 AM Nathan Lynch wrote:
>
> The /proc/powerpc/ofdt interface allows the root user to freely alter
> the in-kernel device tree, enabling arbitrary physical address writes
> via drivers that could bind to malicious device nodes, thus making it
> poss
The /proc/powerpc/ofdt interface allows the root user to freely alter
the in-kernel device tree, enabling arbitrary physical address writes
via drivers that could bind to malicious device nodes, thus making it
possible to disable lockdown.
Historically this interface has been used on the pseries
a/security/security.c
>> +++ b/security/security.c
>> @@ -60,6 +60,7 @@ const char *const
>> lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
>> [LOCKDOWN_XMON_WR] = "xmon write access",
>> [LOCKDOWN_BPF_WRITE_USER] = "use of bpf to write user RAM",
Paul Moore writes:
> On Thu, Sep 22, 2022 at 3:38 PM Nathan Lynch wrote:
>>
>> The /proc/powerpc/ofdt interface allows the root user to freely alter
>> the in-kernel device tree, enabling arbitrary physical address writes
>> via drivers that could bind to malicious d
On Thu, Sep 22, 2022 at 3:38 PM Nathan Lynch wrote:
>
> The /proc/powerpc/ofdt interface allows the root user to freely alter
> the in-kernel device tree, enabling arbitrary physical address writes
> via drivers that could bind to malicious device nodes, thus making it
> poss
The /proc/powerpc/ofdt interface allows the root user to freely alter
the in-kernel device tree, enabling arbitrary physical address writes
via drivers that could bind to malicious device nodes, thus making it
possible to disable lockdown.
Historically this interface has been used on the pseries
Le 03/03/2021 à 06:00, Youlin Song a écrit :
> If the device tree has been allocated memory and it will
> be in the memblock reserved space.Obviously it is in a
> valid memory declaration and will be mapped by the kernel.
Could you please provide clearer explanation ? I don't u
On Wed, Jun 29, 2022 at 08:13:13PM +0200, Krzysztof Kozlowski wrote:
> On 29/06/2022 18:13, Segher Boessenkool wrote:
> > On Wed, Jun 29, 2022 at 11:58:18AM +0200, Krzysztof Kozlowski wrote:
> >>> + /* TODO: Add SMP */
> >>> + PowerPC,espresso@0 {
> >>
> >> Node name should be gener
On 29/06/2022 18:13, Segher Boessenkool wrote:
> On Wed, Jun 29, 2022 at 11:58:18AM +0200, Krzysztof Kozlowski wrote:
>> On 28/06/2022 15:31, Ash Logan wrote:
>>> + model = "nintendo,wiiu";
>>
>> It's not compatible, but user-visible string, e.g. "Nintendo Wii U"
>
> The "model" property in OF i
On Wed, Jun 29, 2022 at 11:58:18AM +0200, Krzysztof Kozlowski wrote:
> On 28/06/2022 15:31, Ash Logan wrote:
> > + model = "nintendo,wiiu";
>
> It's not compatible, but user-visible string, e.g. "Nintendo Wii U"
The "model" property in OF is documented as:
---
“model”
On 28/06/2022 15:31, Ash Logan wrote:
> Add a device tree source file for the Nintendo Wii U video game console.
>
> Signed-off-by: Ash Logan
> Co-developed-by: Roberto Van Eeden
> Signed-off-by: Roberto Van Eeden
> Co-developed-by: Emmanuel Gil Peyrot
> Signed-off-by
Add a device tree source file for the Nintendo Wii U video game console.
Signed-off-by: Ash Logan
Co-developed-by: Roberto Van Eeden
Signed-off-by: Roberto Van Eeden
Co-developed-by: Emmanuel Gil Peyrot
Signed-off-by: Emmanuel Gil Peyrot
---
v1->v2: Style and formatting changes suggested
(vphn_get_nid()) to mark
>> nodes online (setup_node_data()). Hence NUMA nodes we find during
>> lookup in numa_setup_cpu() will always be found online.
>>
>> To keep logic simpler/correct, make sure that if the hypervisor
>> or device tree returned a not online node,
up_node_data()). Hence NUMA nodes we find during
> lookup in numa_setup_cpu() will always be found online.
>
> To keep logic simpler/correct, make sure that if the hypervisor
> or device tree returned a not online node, don't use that to build
> the map table. Instead, use the fi
numa_setup_cpu() will always be found online.
To keep logic simpler/correct, make sure that if the hypervisor
or device tree returned a not online node, don't use that to build
the map table. Instead, use the first_online_node.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/numa.c | 2 +-
1
Add a device tree source file for the Nintendo Wii U video game console.
Signed-off-by: Ash Logan
Co-developed-by: Roberto Van Eeden
Signed-off-by: Roberto Van Eeden
Co-developed-by: Emmanuel Gil Peyrot
Signed-off-by: Emmanuel Gil Peyrot
---
v1->v2: Style and formatting changes suggested
> > 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
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
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-cf
On Mon, 4 Apr 2022 20:15:35 +1000, Russell Currey wrote:
> The device-tree properties no-need-l1d-flush-msr-pr-1-to-0 and
> no-need-l1d-flush-kernel-on-user-access are the equivalents of
> H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY and H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS
> from the H_GET_CPU_CHA
On Thu, 19 May 2022 22:27:06 +0930, Joel Stanley wrote:
> In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
> tree") the kernel tried to determine the pid and lpid bits from the
> device tree. If they are not found, there is a fallback, but Microwatt
> was
numa_setup_cpu can return nodes that are not online. But setup_node_data()
only initialize NODE_DATA for only online numa nodes. Hence avoid returning
nodes that are not online.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Fri, 20 May 2022 at 00:06, Nicholas Piggin wrote:
>
> Excerpts from Joel Stanley's message of May 19, 2022 10:57 pm:
> > In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
> > tree") the kernel tried to determine the pid and lpid bits from the
On Fri, 2022-05-20 at 10:06 +1000, Nicholas Piggin wrote:
> Excerpts from Joel Stanley's message of May 19, 2022 10:57 pm:
> > In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
> > tree") the kernel tried to determine the pid and lpid bits from th
Excerpts from Joel Stanley's message of May 19, 2022 10:57 pm:
> In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
> tree") the kernel tried to determine the pid and lpid bits from the
> device tree. If they are not found, there is a fallback, but Micro
In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
tree") the kernel tried to determine the pid and lpid bits from the
device tree. If they are not found, there is a fallback, but Microwatt
wasn't covered as has the unusual configuration of being both !HV and bare
Joel Stanley writes:
> On Tue, 5 Apr 2022 at 06:13, Michael Ellerman wrote:
>>
>> Joel Stanley writes:
>> > On Mon, 4 Apr 2022 at 10:15, Russell Currey wrote:
>> >>
>> >> The device-tree properties no-need-l1d-flush-msr-pr-1-to-0 and
>&
On Tue, 2022-04-05 at 02:49 +, Joel Stanley wrote:
> I booted both patches in this series on a power10 powernv machine,
> applied on top of v5.18-rc1:
>
> $ dmesg |grep -i flush
> [ 0.00] rfi-flush: fallback displacement flush available
> [ 0.00] rfi-flush: patched 12 locations
On Tue, 5 Apr 2022 at 06:13, Michael Ellerman wrote:
>
> Joel Stanley writes:
> > On Mon, 4 Apr 2022 at 10:15, Russell Currey wrote:
> >>
> >> The device-tree properties no-need-l1d-flush-msr-pr-1-to-0 and
> >> no-need-l1d-flush-kerne
Joel Stanley writes:
> On Mon, 4 Apr 2022 at 10:15, Russell Currey wrote:
>>
>> The device-tree properties no-need-l1d-flush-msr-pr-1-to-0 and
>> no-need-l1d-flush-kernel-on-user-access are the equivalents of
>> H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY and H_CPU_BEHAV_NO_L1
On Mon, 4 Apr 2022 at 10:15, Russell Currey wrote:
>
> The device-tree properties no-need-l1d-flush-msr-pr-1-to-0 and
> no-need-l1d-flush-kernel-on-user-access are the equivalents of
> H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY and H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS
> from the H_GET_CPU_CHARAC
On Wed, 2022-03-23 at 16:26 -0300, Murilo Opsfelder Araújo wrote:
> Hi, Russell.
>
> I think this patch could have been split in half with their
> corresponding Fixes: tag.
>
> This may sound nitpicking but doing this would certainly help distros
> doing their backports.
Hi Murilo,
I didn't use
The device-tree properties no-need-l1d-flush-msr-pr-1-to-0 and
no-need-l1d-flush-kernel-on-user-access are the equivalents of
H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY and H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS
from the H_GET_CPU_CHARACTERISTICS hcall on pseries respectively.
In commit d02fa40d759f ("po
The device-tree property no-need-store-drain-on-priv-state-switch is
equivalent to H_CPU_BEHAV_NO_STF_BARRIER from the
H_CPU_GET_CHARACTERISTICS hcall on pseries.
Since commit 84ed26fd00c5 ("powerpc/security: Add a security feature for
STF barrier") powernv systems with this device-tre
Hi, Russell.
I think this patch could have been split in half with their corresponding
Fixes: tag.
This may sound nitpicking but doing this would certainly help distros doing
their backports.
More comments below.
On 3/22/22 04:47, Russell Currey wrote:
The device-tree properties no-need
The device-tree properties no-need-l1d-flush-msr-pr-1-to-0,
no-need-l1d-flush-kernel-on-user-access and
no-need-store-drain-on-priv-state-switch are the equivalents of
H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY, H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS
and H_CPU_BEHAV_NO_STF_BARRIER from the H_GET_CPU_CHARACTERISTICS
On Mon, Mar 07, 2022 at 11:10:40AM -0300, Alifer Moraes wrote:
> From: Pierluigi Passaro
>
> 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-c
From: Pierluigi Passaro
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-na
On Mon, Mar 07, 2022 at 11:10:40AM -0300, Alifer Moraes wrote:
> + - 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 incomple
Hi Rob,
Thanks for the review.
On 3/3/22 00:36, Rob Herring wrote:
On Tue, Mar 1, 2022 at 10:44 PM Ash Logan wrote:
Add a device tree source file for the Nintendo Wii U video game console.
Test this with 'make W=1 dtbs_checks'.
Does make W=1 ARCH=powerpc wiiu_defconfig dtbs_
On Tue, Mar 1, 2022 at 10:44 PM Ash Logan wrote:
>
> Add a device tree source file for the Nintendo Wii U video game console.
Test this with 'make W=1 dtbs_checks'.
>
> Signed-off-by: Ash Logan
> Co-developed-by: Roberto Van Eeden
> Signed-off-by: Roberto
Add a device tree source file for the Nintendo Wii U video game console.
Signed-off-by: Ash Logan
Co-developed-by: Roberto Van Eeden
Signed-off-by: Roberto Van Eeden
Co-developed-by: Emmanuel Gil Peyrot
Signed-off-by: Emmanuel Gil Peyrot
---
arch/powerpc/boot/dts/wiiu.dts | 327
Hi Maxim,
On Tue, Jan 11, 2022 at 06:22:04PM +0300, Maxim Kiselev wrote:
> On board rev A, the network interface labels for the switch ports
> written on the front panel are different than on rev B and later.
>
> This patch introduces a separate device tree for rev A.
> The main
On board rev A, the network interface labels for the switch ports
written on the front panel are different than on rev B and later.
This patch introduces a separate device tree for rev A.
The main device tree is supposed to cover rev B and later.
Signed-off-by: Maxim Kiselev
---
arch/powerpc
On Mon, 29 Nov 2021 13:09:15 +1000, Nicholas Piggin wrote:
> Allow the LPID bit width and partition table size to be set at runtime
> from the device tree.
>
> Move the PID bit width detection into the same place.
>
> KVM does not support using the extra bits yet, this is ma
1 - 100 of 3178 matches
Mail list logo
