[PATCH] powerpc/pseries: add lparctl driver for platform-specific functions

[Nathan Lynch]

This adds a chardev+ioctl-based interface for user space to access pseries
platform-specific functions which don't easily fit elsewhere.

The immediate motivation is to unbreak librtas[1] with kernel lockdown
enabled. librtas provides a thin root-only user-space API, allowing nearly
direct access to RTAS functions. Since its inception, some of librtas's
APIs have used /dev/mem to allocate buffers that are addressable by RTAS
for use with the powerpc-specific rtas() syscall. This design likely would
not be our first choice today, but it has served adequately for about two
decades without much change, and librtas has a non-negligible number of
existing users, including powerpc-utils, ppc64-diag, lsvpd, lscpu
(util-linux), and several non-OSS programs. With lockdown enabled, /dev/mem
access is prohibited, preventing communication with the management console
and breaking associated functions such as DLPAR and partition migration.

So the task is to provide new lockdown-compatible interfaces for librtas to
prefer over the legacy /dev/mem+sys_rtas(), allowing it to maintain its own
user-facing ABIs as much as possible. This means that we make different
interface choices than we would were we writing everything from scratch. In
the ioctl commands added here, we do not map RTAS error statuses to Linux
errno values, because the existing users of librtas's system parameter APIs
expect the RTAS status codes. Instead, the ioctl succeeds if the kernel
manages to call the RTAS function at all, and passes the RTAS status back
to user space in the argument buffer.

Add the ability to retrieve and change system parameters as defined by
PAPR. Along with proposed implementation changes to librtas[2], this
effectively fixes librtas's rtas_get_sysparm() and rtas_set_sysparm() APIs
for existing users with lockdown. This is enough to get HMC communication
working via the proprietary RSCT stack, enabling LPM, processor DLPAR,
memory DLPAR, and various other use cases.

While this starts with RTAS-implemented functions, there's no reason it
couldn't host facilities that rely on hcalls or other PAPR-specified
interfaces. It could be an alternative to adding more key=value lines to
/proc/powrpc/lparcfg. Hence the generic name 'lparctl'.

Utilities tested (ppc64le kernel and user space):
* ppc64_cpu --run-mode (powerpc-utils, gets/sets processor diag run mode)
* serv_config (powerpc-utils, gets/sets various system and LPAR policies)
* lscpu (util-linux, retrieves processor topology)
* RSCT (proprietary, retrieves HMC connection details)

Future work to unbreak more librtas APIs may include:
* VPD retrieval via ibm,get-vpd
* RTAS error injection
* indicator query/manipulation for diagnostics

[1] https://github.com/ibm-power-utilities/librtas
[2] https://github.com/ibm-power-utilities/librtas/pull/26

Signed-off-by: Nathan Lynch 
---
 .../userspace-api/ioctl/ioctl-number.rst  |   1 +
 arch/powerpc/include/uapi/asm/lparctl.h   |  63 +++
 arch/powerpc/platforms/pseries/Makefile   |   2 +-
 arch/powerpc/platforms/pseries/lparctl.c  | 171 ++
 4 files changed, 236 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/include/uapi/asm/lparctl.h
 create mode 100644 arch/powerpc/platforms/pseries/lparctl.c

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index fcab013e47c9..029de1b7ebdb 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -349,6 +349,7 @@ Code  Seq#Include File  
 Comments
  

 0xB1  00-1F  PPPoX
  

+0xB2  01-02  arch/powerpc/include/uapi/asm/lparctl.h 
powerpc/pseries lparctl API
 0xB3  00 linux/mmc/ioctl.h
 0xB4  00-0F  linux/gpio.h

 0xB5  00-0F  uapi/linux/rpmsg.h  

diff --git a/arch/powerpc/include/uapi/asm/lparctl.h 
b/arch/powerpc/include/uapi/asm/lparctl.h
new file mode 100644
index ..42e1ee5fe3c8
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/lparctl.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef POWERPC_UAPI_LPARCTL_H
+#define POWERPC_UAPI_LPARCTL_H
+
+#include 
+#include 
+
+#define LPARCTL_IOCTL_BASE 0xb2
+
+#define LPARCTL_IO(nr) _IO(LPARCTL_IOCTL_BASE, nr)
+#define LPARCTL_IOR(nr, type)  _IOR(LPARCTL_IOCTL_BASE, nr, type)
+#define LPARCTL_IOW(nr, type)  _IOW(LPARCTL_IOCTL_BASE, nr, type)
+#define LPARCTL_IOWR(nr, type) _IOWR(LPARCTL_IOCTL_BASE, nr, type)
+
+/**
+ * struct lparctl_get_system_parameter 

Re: [RFC PATCH net-next 0/9] net: pcs: Add support for devices probed in the "usual" manner

[Sean Anderson]

On 7/21/22 5:41 PM, Sean Anderson wrote:
> On 7/20/22 9:53 AM, Vladimir Oltean wrote:
>> On Tue, Jul 19, 2022 at 03:34:45PM -0400, Sean Anderson wrote:
>>> We could do it, but it'd be a pretty big hack. Something like the
>>> following. Phylink would need to be modified to grab the lock before
>>> every op and check if the PCS is dead or not. This is of course still
>>> not optimal, since there's no way to re-attach a PCS once it goes away.
>> 
>> You assume it's just phylink who operates on a PCS structure, but if you
>> include your search pool to also cover include/linux/pcs/pcs-xpcs.h,
>> you'll see a bunch of exported functions which are called directly by
>> the client drivers (stmmac, sja1105). At this stage it gets pretty hard
>> to validate that drivers won't attempt from any code path to do
>> something stupid with a dead PCS. All in all it creates an environment
>> with insanely weak guarantees; that's pretty hard to get behind IMO.
> 
> Right. To do this properly, we'd need wrapper functions for all the PCS
> operations. And the super-weak guarantees is why I referred to this as a
> "hack". But we could certainly make it so that removing a PCS might not
> bring down the MAC.
> 
>>> IMO a better solution is to use devlink and submit a patch to add
>>> notifications which the MAC driver can register for. That way it can
>>> find out when the PCS goes away and potentially do something about it
>>> (or just let itself get removed).
>> 
>> Not sure I understand what connection there is between devlink (device
>> links) and PCS {de}registration notifications. 
> 
> The default action when a supplier is going to be removed is to remove
> the consumers. However, it'd be nice to notify the consumer beforehand.
> If we used device links, this would need to be integrated (since otherwise
> we'd only find out that a PCS was gone after the MAC was gone too).
> 
>> We could probably add those
>> notifications without any intervention from the device core: we would
>> just need to make this new PCS "core" to register an 
>> blocking_notifier_call_chain
>> to which interested drivers could add their notifier blocks. How a> certain 
>> phylink user is going to determine that "hey, this PCS is
>> definitely mine and I can use it" is an open question. In any case, my
>> expectation is that we have a notifier chain, we can at least continue
>> operating (avoid unbinding the struct device), but essentially move our
>> phylink_create/phylink_destroy calls to within those notifier blocks.
>> Again, retrofitting this model to existing drivers, phylink API (and
>> maybe even its internal structure) is something that's hard to hop on
>> board of; I think it's a solution waiting for a problem, and I don't
>> have an interest to develop or even review it.
> 
> I don't either. I'd much rather just bring down the whole MAC when any
> PCS gets removed. Whatever we decide on doing here should also be done
> for (serdes) phys as well, since they have all the same pitfalls. For
> that reason I'd rather use a generic, non-intrusive solution like device
> links. I know Russell mentioned composite devices, but I think those
> would have similar advantages/drawbacks as a device-link-based solution
> (unbinding of one device unbinds the rest).

OK, I've thought about this a bit more. Right now, you can crash the
kernel by unbinding a phy (either serdes or networking) and waiting for
a state change. The serdes problem could probably be solved by
strengthening the existing device_link_add calls. This will of course
unbind the netdev if you unbind the serdes. I think this is not a common
use case; if a user does this they probably know what they're doing (or
not).

The problem with ethernet phys is a bit worse. It's very common to have
something like

+ netdev
|
+-+ mdiobus
  |
  +-- phy

which poses a problem for device links. The phy is a child of the
netdev, so it should be unbound first. device_link_add will see this and
refuse to create a link, since such a link implies that netdev should be
unbound before phy.

One solution might be something like:

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index a74b320f5b27..05894e1c3e59 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3111,6 +3112,13 @@ static int phy_remove(struct device *dev)
 {
struct phy_device *phydev = to_phy_device(dev);
 
+   // I'm pretty sure this races with multiple unbinds...
+   rtnl_lock();
+   device_unlock(dev);
+   dev_close(phydev->attached_dev);
+   device_lock(dev);
+   rtnl_unlock();
+   WARN_ON(phydev->attached_dev);
+
cancel_delayed_work_sync(>state_queue);
 
mutex_lock(>lock);

which is probably the least intrusive we can get. But this isn't very
nice for PCSs.

First, PCSs are not always used by netdevs. 

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.19-6 tag

[pr-tracker-bot]

The pull request you sent on Fri, 29 Jul 2022 22:49:59 +1000:

> https://lore.kernel.org/amd-gfx/20220728203347.2019728-1-rodrigo.sique...@amd.com/
>  cheers

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9d928d9b78beec5d4b8afde9c144919b979685f2

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE

[Paul E. McKenney]

Or better yet, try the patch that Rafael proposed.  ;-)

Thanx, Paul

On Fri, Jul 29, 2022 at 08:26:22AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 29, 2022 at 03:24:58AM -0700, Michel Lespinasse wrote:
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > > Xeons") wrecked intel_idle in two ways:
> > > > > 
> > > > >  - must not have tracing in idle functions
> > > > >  - must return with IRQs disabled
> > > > > 
> > > > > Additionally, it added a branch for no good reason.
> > > > > 
> > > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on 
> > > > > Xeons")
> > > > > Signed-off-by: Peter Zijlstra (Intel) 
> > > > 
> > > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > > usage" when booting a kernel with debug options compiled in. Please
> > > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > > and is still present in v5.19-rc8.
> > > > 
> > > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > > 
> > > I finally got a chance to take a quick look at this.
> > > 
> > > The rcu_eqs_exit() function is making a lockdep complaint about
> > > being invoked with interrupts enabled.  This function is called from
> > > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > > interrupts before invoking rcu_eqs_exit().
> > > 
> > > The only other call to rcu_idle_exit() does not disable interrupts,
> > > but it is via rcu_user_exit(), which would be a very odd choice for
> > > cpuidle_enter_state().
> > > 
> > > It seems unlikely, but it might be that it is the use of local_irq_save()
> > > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > > the trouble.  If this is the case, then the commit shown below would
> > > help.  Note that this commit removes the warning from lockdep, so it
> > > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > > equivalent debugging.
> > > 
> > > Could you please try your test with the -rce commit shown below applied?
> > 
> > Thanks for looking into it.
> 
> And thank you for trying this shot in the dark!
> 
> > After checking out Peter's commit 32d4fd5751ea,
> > cherry picking your commit ed4ae5eff4b3,
> > and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> > I am now seeing this a few seconds into the boot:
> > 
> > [3.010650] [ cut here ]
> > [3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 
> > sched_clock_tick+0x27/0x60
> 
> And this is again a complaint about interrupts not being disabled.
> 
> But it does appear that the problem was the lockdep complaint, and
> eliminating that did take care of part of the problem.  But lockdep
> remained enabled, and you therefore hit the next complaint.
> 
> > [3.010657] Modules linked in:
> > [3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> > 5.19.0-rc1-test-5-g1be22fea0611 #1
> > [3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 
> > 01/17/2022
> > [3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> 
> The most straightforward way to get to sched_clock_tick() from
> cpuidle_enter_state() is via the call to sched_clock_idle_wakeup_event().
> 
> Except that it disables interrupts before invoking sched_clock_tick().
> 
> > [3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 
> > 74 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 
> > <0f> 0b e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
> >  89 c0 48 03 1c c5 c0 98
> > [3.010667] RSP: :b2803e28 EFLAGS: 00010002
> > [3.010670] RAX: 0001 RBX: c8ce7fa07060 RCX: 
> > 0001
> > [3.010671] RDX:  RSI: b268dd21 RDI: 
> > b269ab13
> > [3.010673] RBP: 0001 R08: ffc300d5 R09: 
> > 0002be80
> > [3.010674] R10: 03625b53183a R11: a012b802b7a4 R12: 
> > b2aa9e80
> > [3.010675] R13: b2aa9e00 R14: 0001 R15: 
> > 
> > [3.010677] FS:  () GS:a012b800() 
> > knlGS:
> > [3.010678] CS:  0010 DS:  ES:  CR0: 80050033
> > [3.010680] CR2: a012f81ff000 CR3: 000c99612001 CR4: 
> > 003706f0
> > [3.010681] DR0:  DR1:  DR2: 
> > 
> > [3.010682] DR3:  DR6: fffe0ff0 DR7: 
> > 0400
> > [3.010683] Call Trace:
> > [3.010685]  
> > [3.010688]  cpuidle_enter_state+0xb7/0x4b0
> > [

Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE

[Paul E. McKenney]

On Fri, Jul 29, 2022 at 03:24:58AM -0700, Michel Lespinasse wrote:
> On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > Xeons") wrecked intel_idle in two ways:
> > > > 
> > > >  - must not have tracing in idle functions
> > > >  - must return with IRQs disabled
> > > > 
> > > > Additionally, it added a branch for no good reason.
> > > > 
> > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > Signed-off-by: Peter Zijlstra (Intel) 
> > > 
> > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > usage" when booting a kernel with debug options compiled in. Please
> > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > and is still present in v5.19-rc8.
> > > 
> > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> > 
> > I finally got a chance to take a quick look at this.
> > 
> > The rcu_eqs_exit() function is making a lockdep complaint about
> > being invoked with interrupts enabled.  This function is called from
> > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > interrupts before invoking rcu_eqs_exit().
> > 
> > The only other call to rcu_idle_exit() does not disable interrupts,
> > but it is via rcu_user_exit(), which would be a very odd choice for
> > cpuidle_enter_state().
> > 
> > It seems unlikely, but it might be that it is the use of local_irq_save()
> > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > the trouble.  If this is the case, then the commit shown below would
> > help.  Note that this commit removes the warning from lockdep, so it
> > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > equivalent debugging.
> > 
> > Could you please try your test with the -rce commit shown below applied?
> 
> Thanks for looking into it.

And thank you for trying this shot in the dark!

> After checking out Peter's commit 32d4fd5751ea,
> cherry picking your commit ed4ae5eff4b3,
> and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> I am now seeing this a few seconds into the boot:
> 
> [3.010650] [ cut here ]
> [3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 
> sched_clock_tick+0x27/0x60

And this is again a complaint about interrupts not being disabled.

But it does appear that the problem was the lockdep complaint, and
eliminating that did take care of part of the problem.  But lockdep
remained enabled, and you therefore hit the next complaint.

> [3.010657] Modules linked in:
> [3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 5.19.0-rc1-test-5-g1be22fea0611 #1
> [3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> [3.010663] RIP: 0010:sched_clock_tick+0x27/0x60

The most straightforward way to get to sched_clock_tick() from
cpuidle_enter_state() is via the call to sched_clock_idle_wakeup_event().

Except that it disables interrupts before invoking sched_clock_tick().

> [3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 
> 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b 
> e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
>  89 c0 48 03 1c c5 c0 98
> [3.010667] RSP: :b2803e28 EFLAGS: 00010002
> [3.010670] RAX: 0001 RBX: c8ce7fa07060 RCX: 
> 0001
> [3.010671] RDX:  RSI: b268dd21 RDI: 
> b269ab13
> [3.010673] RBP: 0001 R08: ffc300d5 R09: 
> 0002be80
> [3.010674] R10: 03625b53183a R11: a012b802b7a4 R12: 
> b2aa9e80
> [3.010675] R13: b2aa9e00 R14: 0001 R15: 
> 
> [3.010677] FS:  () GS:a012b800() 
> knlGS:
> [3.010678] CS:  0010 DS:  ES:  CR0: 80050033
> [3.010680] CR2: a012f81ff000 CR3: 000c99612001 CR4: 
> 003706f0
> [3.010681] DR0:  DR1:  DR2: 
> 
> [3.010682] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [3.010683] Call Trace:
> [3.010685]  
> [3.010688]  cpuidle_enter_state+0xb7/0x4b0
> [3.010694]  cpuidle_enter+0x29/0x40
> [3.010697]  do_idle+0x1d4/0x210
> [3.010702]  cpu_startup_entry+0x19/0x20
> [3.010704]  rest_init+0x117/0x1a0
> [3.010708]  arch_call_rest_init+0xa/0x10
> [3.010711]  start_kernel+0x6d8/0x6ff
> [3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> [3.010728]  
> [3.010729] irq event stamp: 44179
> [3.010730] hardirqs last  enabled at 

Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE

[Rafael J. Wysocki]

On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
 wrote:
>
> On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > > Xeons") wrecked intel_idle in two ways:
> > > >
> > > >  - must not have tracing in idle functions
> > > >  - must return with IRQs disabled
> > > >
> > > > Additionally, it added a branch for no good reason.
> > > >
> > > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > > Signed-off-by: Peter Zijlstra (Intel) 
> > >
> > > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > > usage" when booting a kernel with debug options compiled in. Please
> > > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > > and is still present in v5.19-rc8.
> > >
> > > I'm not sure, is this too late to fix or revert in v5.19 final ?
> >
> > I finally got a chance to take a quick look at this.
> >
> > The rcu_eqs_exit() function is making a lockdep complaint about
> > being invoked with interrupts enabled.  This function is called from
> > rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> > via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> > interrupts before invoking rcu_eqs_exit().
> >
> > The only other call to rcu_idle_exit() does not disable interrupts,
> > but it is via rcu_user_exit(), which would be a very odd choice for
> > cpuidle_enter_state().
> >
> > It seems unlikely, but it might be that it is the use of local_irq_save()
> > instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> > the trouble.  If this is the case, then the commit shown below would
> > help.  Note that this commit removes the warning from lockdep, so it
> > is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> > equivalent debugging.
> >
> > Could you please try your test with the -rce commit shown below applied?
>
> Thanks for looking into it.
>
> After checking out Peter's commit 32d4fd5751ea,
> cherry picking your commit ed4ae5eff4b3,
> and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
> I am now seeing this a few seconds into the boot:
>
> [3.010650] [ cut here ]
> [3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 
> sched_clock_tick+0x27/0x60
> [3.010657] Modules linked in:
> [3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 5.19.0-rc1-test-5-g1be22fea0611 #1
> [3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
> [3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
> [3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 
> 18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b 
> e8 e2 6c 89 00 48 c7 c3 40 d5 02 00
>  89 c0 48 03 1c c5 c0 98
> [3.010667] RSP: :b2803e28 EFLAGS: 00010002
> [3.010670] RAX: 0001 RBX: c8ce7fa07060 RCX: 
> 0001
> [3.010671] RDX:  RSI: b268dd21 RDI: 
> b269ab13
> [3.010673] RBP: 0001 R08: ffc300d5 R09: 
> 0002be80
> [3.010674] R10: 03625b53183a R11: a012b802b7a4 R12: 
> b2aa9e80
> [3.010675] R13: b2aa9e00 R14: 0001 R15: 
> 
> [3.010677] FS:  () GS:a012b800() 
> knlGS:
> [3.010678] CS:  0010 DS:  ES:  CR0: 80050033
> [3.010680] CR2: a012f81ff000 CR3: 000c99612001 CR4: 
> 003706f0
> [3.010681] DR0:  DR1:  DR2: 
> 
> [3.010682] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [3.010683] Call Trace:
> [3.010685]  
> [3.010688]  cpuidle_enter_state+0xb7/0x4b0
> [3.010694]  cpuidle_enter+0x29/0x40
> [3.010697]  do_idle+0x1d4/0x210
> [3.010702]  cpu_startup_entry+0x19/0x20
> [3.010704]  rest_init+0x117/0x1a0
> [3.010708]  arch_call_rest_init+0xa/0x10
> [3.010711]  start_kernel+0x6d8/0x6ff
> [3.010716]  secondary_startup_64_no_verify+0xce/0xdb
> [3.010728]  
> [3.010729] irq event stamp: 44179
> [3.010730] hardirqs last  enabled at (44179): [] 
> asm_sysvec_apic_timer_interrupt+0x1b/0x20
> [3.010734] hardirqs last disabled at (44177): [] 
> __do_softirq+0x3f0/0x498
> [3.010736] softirqs last  enabled at (44178): [] 
> __do_softirq+0x332/0x498
> [3.010738] softirqs last disabled at (44171): [] 
> irq_exit_rcu+0xab/0xf0
> [3.010741] ---[ end trace  ]---

Can you please give this patch a go:
https://patchwork.kernel.org/project/linux-pm/patch/Yt/axpfi88new...@e126311.manchester.arm.com/
?

Re: [PATCH 04/36] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE

[Michel Lespinasse]

On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > > Xeons") wrecked intel_idle in two ways:
> > > 
> > >  - must not have tracing in idle functions
> > >  - must return with IRQs disabled
> > > 
> > > Additionally, it added a branch for no good reason.
> > > 
> > > Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> > > Signed-off-by: Peter Zijlstra (Intel) 
> > 
> > After this change was introduced, I am seeing "WARNING: suspicious RCU
> > usage" when booting a kernel with debug options compiled in. Please
> > see the attached dmesg output. The issue starts with commit 32d4fd5751ea
> > and is still present in v5.19-rc8.
> > 
> > I'm not sure, is this too late to fix or revert in v5.19 final ?
> 
> I finally got a chance to take a quick look at this.
> 
> The rcu_eqs_exit() function is making a lockdep complaint about
> being invoked with interrupts enabled.  This function is called from
> rcu_idle_exit(), which is an expected code path from cpuidle_enter_state()
> via its call to rcu_idle_exit().  Except that rcu_idle_exit() disables
> interrupts before invoking rcu_eqs_exit().
> 
> The only other call to rcu_idle_exit() does not disable interrupts,
> but it is via rcu_user_exit(), which would be a very odd choice for
> cpuidle_enter_state().
> 
> It seems unlikely, but it might be that it is the use of local_irq_save()
> instead of raw_local_irq_save() within rcu_idle_exit() that is causing
> the trouble.  If this is the case, then the commit shown below would
> help.  Note that this commit removes the warning from lockdep, so it
> is necessary to build the kernel with CONFIG_RCU_EQS_DEBUG=y to enable
> equivalent debugging.
> 
> Could you please try your test with the -rce commit shown below applied?

Thanks for looking into it.

After checking out Peter's commit 32d4fd5751ea,
cherry picking your commit ed4ae5eff4b3,
and setting CONFIG_RCU_EQS_DEBUG=y in addition of my usual debug config,
I am now seeing this a few seconds into the boot:

[3.010650] [ cut here ]
[3.010651] WARNING: CPU: 0 PID: 0 at kernel/sched/clock.c:397 
sched_clock_tick+0x27/0x60
[3.010657] Modules linked in:
[3.010660] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
5.19.0-rc1-test-5-g1be22fea0611 #1
[3.010662] Hardware name: LENOVO 30BFS44D00/1036, BIOS S03KT51A 01/17/2022
[3.010663] RIP: 0010:sched_clock_tick+0x27/0x60
[3.010665] Code: 1f 40 00 53 eb 02 5b c3 66 90 8b 05 2f c3 40 01 85 c0 74 
18 65 8b 05 60 88 8f 4e 85 c0 75 0d 65 8b 05 a9 85 8f 4e 85 c0 74 02 <0f> 0b e8 
e2 6c 89 00 48 c7 c3 40 d5 02 00
 89 c0 48 03 1c c5 c0 98
[3.010667] RSP: :b2803e28 EFLAGS: 00010002
[3.010670] RAX: 0001 RBX: c8ce7fa07060 RCX: 0001
[3.010671] RDX:  RSI: b268dd21 RDI: b269ab13
[3.010673] RBP: 0001 R08: ffc300d5 R09: 0002be80
[3.010674] R10: 03625b53183a R11: a012b802b7a4 R12: b2aa9e80
[3.010675] R13: b2aa9e00 R14: 0001 R15: 
[3.010677] FS:  () GS:a012b800() 
knlGS:
[3.010678] CS:  0010 DS:  ES:  CR0: 80050033
[3.010680] CR2: a012f81ff000 CR3: 000c99612001 CR4: 003706f0
[3.010681] DR0:  DR1:  DR2: 
[3.010682] DR3:  DR6: fffe0ff0 DR7: 0400
[3.010683] Call Trace:
[3.010685]  
[3.010688]  cpuidle_enter_state+0xb7/0x4b0
[3.010694]  cpuidle_enter+0x29/0x40
[3.010697]  do_idle+0x1d4/0x210
[3.010702]  cpu_startup_entry+0x19/0x20
[3.010704]  rest_init+0x117/0x1a0
[3.010708]  arch_call_rest_init+0xa/0x10
[3.010711]  start_kernel+0x6d8/0x6ff
[3.010716]  secondary_startup_64_no_verify+0xce/0xdb
[3.010728]  
[3.010729] irq event stamp: 44179
[3.010730] hardirqs last  enabled at (44179): [] 
asm_sysvec_apic_timer_interrupt+0x1b/0x20
[3.010734] hardirqs last disabled at (44177): [] 
__do_softirq+0x3f0/0x498
[3.010736] softirqs last  enabled at (44178): [] 
__do_softirq+0x332/0x498
[3.010738] softirqs last disabled at (44171): [] 
irq_exit_rcu+0xab/0xf0
[3.010741] ---[ end trace  ]---

Re: [linux-next] Build failure drivers/cxl/cxl_pmem (powerpc)

[Dan Williams]

Michael Ellerman wrote:
> Sachin Sant  writes:
> > Linux-next (5.19.0-rc8-next-20220728) fails to build on powerpc with
> > following error:
> >
> > ERROR: modpost: "memory_add_physaddr_to_nid" [drivers/cxl/cxl_pmem.ko] 
> > undefined!
> > make[1]: *** [scripts/Makefile.modpost:128: modules-only.symvers] Error 1
> >
> > The code in question was last changed by following patch:
> >
> > commit 04ad63f086d1
> >cxl/region: Introduce cxl_pmem_region objects
> 
> This should fix it.
> 
> Dan, do you want to apply that on top of your tree to reduce the window
> of breakage?

Yes, will apply, thanks.

Re: [PATCH] powerpc/85xx: P2020: Add law_trgt_if property to PCIe DT nodes

[Rob Herring]

On Fri, Jul 29, 2022 at 7:17 AM Michael Ellerman
 wrote:
>
> On Wed, 4 May 2022 20:08:22 +0200, Pali Rohár wrote:
> > DT law_trgt_if property defines Local Access Window Target Interface.
> >
> > Local Access Window Target Interface is used for identifying individual
> > peripheral and mapping its memory to CPU. Interface id is defined by
> > hardware itself.
> >
> > U-Boot uses law_trgt_if DT property in PCIe nodes for configuring memory
> > mapping of individual PCIe controllers.
> >
> > [...]
>
> Applied to powerpc/next.
>
> [1/1] powerpc/85xx: P2020: Add law_trgt_if property to PCIe DT nodes
>   
> https://git.kernel.org/powerpc/c/1f00b5ab992c122c51bc37662b3b4df5963462f3

Why? Minimally, it needs a vendor prefix and s/_/-/ as I commented.

Rob

Re: [PATCH -next v3 0/2] powerpc: add support for syscall stack randomization

[Michael Ellerman]

On Fri, 1 Jul 2022 16:24:33 +0800, Xiu Jianfeng wrote:
> This patchset adds support for syscall stack randomization for
> powerpc, which can make harder the various stack-based attacks that
> rely on deterministic stack structure.
> 
> Changes in v3:
>   -add a lead-up patch to move system_call_exception() to syscall.c to
>   avoid disabling stack protector for all functions in interrupt.c
> Changes in v2:
>   -move choose choose_random_kstack_offset() to the end of 
> system_call_exception
>   -allow full 6 (10) bits of entropy
>   -disable stack-protector for interrupt.c
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc: Move system_call_exception() to syscall.c
  https://git.kernel.org/powerpc/c/1547db7d1f4481c1f3ec731f3edc724ef3026ede
[2/2] powerpc: add support for syscall stack randomization
  https://git.kernel.org/powerpc/c/f4a0318f278d98d9492916722e85f258c2221f88

cheers

Re: [PATCH] powerpc/sysdev: Fix comment typo

[Michael Ellerman]

On Fri, 15 Jul 2022 11:52:50 +0800, Jason Wang wrote:
> The double `is' is duplicated in line 110, remove one.
> 
> 

Applied to powerpc/next.

[1/1] powerpc/sysdev: Fix comment typo
  https://git.kernel.org/powerpc/c/738f9dca0df3bb630e6f06a19573ab4e31bd443a

cheers

Re: [PATCH] powerpc/pseries/vas: Fix comment typo

[Michael Ellerman]

On Mon, 18 Jul 2022 15:55:53 +0800, Jason Wang wrote:
> The double `the' in line 807 is duplicated, remove one.
> 
> 

Applied to powerpc/next.

[1/1] powerpc/pseries/vas: Fix comment typo
  https://git.kernel.org/powerpc/c/901a30cf5f765a26f1308701d9df9e7f3d0023a5

cheers

Re: [PATCH] powerpc/52xx: Mark gpt driver as not removable

[Michael Ellerman]

On Sun, 12 Jun 2022 23:34:00 +0200, Uwe Kleine-König wrote:
> Returning an error code (here -EBUSY) from a remove callback doesn't
> prevent the driver from being unloaded. The only effect is that an error
> message is emitted and the driver is removed anyhow.
> 
> So instead drop the remove function (which is equivalent to returning zero)
> and set the suppress_bind_attrs property to make it impossible to unload
> the driver via sysfs.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/52xx: Mark gpt driver as not removable
  https://git.kernel.org/powerpc/c/1978c48495171165453a7c90d1345c1d8d776d02

cheers

Re: [PATCH 1/3] powerpc/platforms/83xx/suspend: Reorder to get rid of a forward declaration

[Michael Ellerman]

On Thu, 7 Jul 2022 08:14:39 +0200, Uwe Kleine-König wrote:
> By moving up pmc_types and pmc_match, the forward declaration for pmc_match
> can be dropped.
> 
> 

Applied to powerpc/next.

[1/3] powerpc/platforms/83xx/suspend: Reorder to get rid of a forward 
declaration
  https://git.kernel.org/powerpc/c/fde345e4d39a4f16697a8060564fff1dbac05035
[2/3] powerpc/platforms/83xx/suspend: Prevent unloading the driver
  https://git.kernel.org/powerpc/c/ccc1439b924bca5d5a5d81cf6b0d4b10b321282e
[3/3] powerpc/platforms/83xx/suspend: Remove write-only global variable
  https://git.kernel.org/powerpc/c/95b002e4e47a36d88deec70808ef36674fb33cf5

cheers

Re: [PATCH] macintosh:fix oob read in do_adb_query function

[Michael Ellerman]

On Wed, 13 Jul 2022 23:37:34 +0800, Ning Qiang wrote:
> In do_adb_query function of drivers/macintosh/adb.c, req->data is copy
> form userland. the  parameter "req->data[2]" is Missing check, the
> array size of adb_handler[] is 16, so "adb_handler[
> req->data[2]].original_address" and "adb_handler[
> req->data[2]].handler_id" will lead to oob read.
> 
> 
> [...]

Applied to powerpc/next.

[1/1] macintosh:fix oob read in do_adb_query function
  https://git.kernel.org/powerpc/c/fd97e4ad6d3b0c9fce3bca8ea8e6969d9ce7423b

cheers

Re: [PATCH] selftests/powerpc: Fix matrix multiply assist test

[Michael Ellerman]

On Fri, 17 Jun 2022 14:39:35 +1000, Rashmica Gupta wrote:
> The ISA states: "when ACC[i] contains defined data, the contents of VSRs
> 4×i to 4×i+3 are undefined until either a VSX Move From ACC instruction
> is used to copy the contents of ACC[i] to VSRs 4×i to 4×i+3 or some other
> instruction directly writes to one of these VSRs." We aren't doing this.
> 
> This test only works on Power10 because the hardware implementation
> happens to map ACC0 to VSRs 0-3, but will fail on any other implementation
> that doesn't do this. So add xxmfacc between writing to the accumulator
> and accessing the VSRs.
> 
> [...]

Applied to powerpc/next.

[1/1] selftests/powerpc: Fix matrix multiply assist test
  https://git.kernel.org/powerpc/c/cd1e64935f79e31d666172c52c951ca97152b783

cheers

Re: [PATCH] powerpc/signal: Update comment for clarity

[Michael Ellerman]

On Fri, 17 Jun 2022 14:31:35 +1000, Rashmica Gupta wrote:
> The comment being referred to was deleted in commit af1bbc3dd3d5 ("powerpc:
> Remove UP only lazy floating point and vector optimisations").
> 
> Add a bit more detail so it's clear why we need to clear the FP/VEC/VSX
> bits here.
> 
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/signal: Update comment for clarity
  https://git.kernel.org/powerpc/c/e4787e71ae2de3f60bc04fe09d1be4ef628b6c68

cheers

Re: [PATCH] powerpc: make facility_unavailable_exception 64s

[Michael Ellerman]

On Fri, 17 Jun 2022 14:28:05 +1000, Rashmica Gupta wrote:
> The facility unavailable exception is only available on ppc book3s
> machines so use CONFIG_PPC_BOOK3S_64 rather than CONFIG_PPC64.
> tm_unavailable is only called from facility_unavailable_exception so can
> also be under this Kconfig symbol.
> 
> 

Applied to powerpc/next.

[1/1] powerpc: make facility_unavailable_exception 64s
  https://git.kernel.org/powerpc/c/fcdb758ce113c5d1b2b7034a058a9c472e42415e

cheers

Re: [PATCH v2 1/2] powerpc/pci: Add config option for using OF 'reg' for PCI domain

[Michael Ellerman]

On Wed, 6 Jul 2022 12:21:47 +0200, Pali Rohár wrote:
> Since commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on
> device-tree properties"), powerpc kernel always fallback to PCI domain
> assignment from OF / Device Tree 'reg' property of the PCI controller.
> 
> In most cases 'reg' property is not zero and therefore there it cause that
> PCI domain zero is not present in system anymore.
> 
> [...]

Patch 2 applied to powerpc/next.

[2/2] powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and 
alias
  https://git.kernel.org/powerpc/c/0fe1e96fef0a5c53b4c0d1500d356f3906000f81

cheers

Re: [PATCH] powerpc/fsl-pci: Fix Class Code of PCIe Root Port

[Michael Ellerman]

On Wed, 6 Jul 2022 12:10:43 +0200, Pali Rohár wrote:
> By default old pre-3.0 Freescale PCIe controllers reports invalid PCI Class
> Code 0x0b20 for PCIe Root Port. It can be seen by lspci -b output on P2020
> board which has this pre-3.0 controller:
> 
>   $ lspci -bvnn
>   00:00.0 Power PC [0b20]: Freescale Semiconductor Inc P2020E [1957:0070] 
> (rev 21)
>   !!! Invalid class 0b20 for header type 01
>   Capabilities: [4c] Express Root Port (Slot-), MSI 00
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/fsl-pci: Fix Class Code of PCIe Root Port
  https://git.kernel.org/powerpc/c/0c551abfa004ce154d487d91777bf221c808a64f

cheers

Re: [PATCH] powerpc: dts: turris1x.dts: Add CPLD reboot node

[Michael Ellerman]

On Wed, 13 Jul 2022 15:44:29 +0200, Pali Rohár wrote:
> CPLD firmware can reset board by writing value 0x01 at CPLD memory offset
> 0x0d. Define syscon-reboot node for this reset support.
> 
> 

Applied to powerpc/next.

[1/1] powerpc: dts: turris1x.dts: Add CPLD reboot node
  https://git.kernel.org/powerpc/c/0531a4abd1c6c2e270f5ac6fc725ff550fcd14ab

cheers

Re: [PATCH] powerpc/85xx: P2020: Add law_trgt_if property to PCIe DT nodes

[Michael Ellerman]

On Wed, 4 May 2022 20:08:22 +0200, Pali Rohár wrote:
> DT law_trgt_if property defines Local Access Window Target Interface.
> 
> Local Access Window Target Interface is used for identifying individual
> peripheral and mapping its memory to CPU. Interface id is defined by
> hardware itself.
> 
> U-Boot uses law_trgt_if DT property in PCIe nodes for configuring memory
> mapping of individual PCIe controllers.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/85xx: P2020: Add law_trgt_if property to PCIe DT nodes
  https://git.kernel.org/powerpc/c/1f00b5ab992c122c51bc37662b3b4df5963462f3

cheers

Re: [PATCH] powerpc/85xx: Fix description of MPC85xx and P1/P2 boards options

[Michael Ellerman]

On Sat, 9 Jul 2022 14:43:05 +0200, Pali Rohár wrote:
> More MPC85xx and P1/P2 boards options have incorrect description. Fix them
> to include list of all boards for which they enable/disable support.
> 
> 

Applied to powerpc/next.

[1/1] powerpc/85xx: Fix description of MPC85xx and P1/P2 boards options
  https://git.kernel.org/powerpc/c/d20c96deb3e2c1cedc47d2be9fc110ffed81b1af

cheers

Re: [PATCH 0/5] powerpc/pci: Cleanup unused code and enable 256 PCI buses

[Michael Ellerman]

On Wed, 6 Jul 2022 12:43:03 +0200, Pali Rohár wrote:
> This patch series cleanup unused code by eliminating it at compile time
> and then enable usage of all 256 PCI buses per every PCI domain as
> currently PCI bus numbers have to be unique across all PCI domains.
> So first bus number of each PCI domain would be zero and not the bus
> number of the previous domain plus one. As such bus assignment changes
> BDF address of every PCI device on multi-domain system, this new
> "feature" is configurable by config option to prevent regressions.
> 
> [...]

Applied to powerpc/next.

[1/5] powerpc/pci: Hide pci_device_from_OF_node() for non-powermac code
  https://git.kernel.org/powerpc/c/a2954a7e47b60bb8d8c51f1b4d55af7585a4108a
[2/5] powerpc/pci: Make pcibios_make_OF_bus_map() static
  https://git.kernel.org/powerpc/c/407a767182d3dc87176aabddd7c109b36a5727e9
[3/5] powerpc/pci: Hide pci_create_OF_bus_map() for non-chrp code
  https://git.kernel.org/powerpc/c/704544588735b2e1115212dbba1c210b3687ff7a
[4/5] powerpc/pci: Disable filling pci-OF-bus-map for non-chrp/powermac
  https://git.kernel.org/powerpc/c/7f102d61983275ab68b5ac2715afa35c5f4ffd86
[5/5] powerpc/pci: Add config option for using all 256 PCI buses
  https://git.kernel.org/powerpc/c/5663568130825458a2a8535ccef0db9a1bf7be82

cheers

Re: [PATCH v2] powerpc: add documentation for HWCAPs

[Michael Ellerman]

On Fri, 15 Jul 2022 11:26:36 +1000, Nicholas Piggin wrote:
> Take the arm64 HWCAP documentation file and adjust it for powerpc.
> 
> 

Applied to powerpc/next.

[1/1] powerpc: add documentation for HWCAPs
  https://git.kernel.org/powerpc/c/ef1911c6d26678b0e91fea33f076e98925997f0c

cheers

Re: [PATCH] powerpc/vdso: Fix __kernel_sync_dicache sequence with coherent icache

[Michael Ellerman]

On Fri, 20 May 2022 22:36:49 +1000, Nicholas Piggin wrote:
> Processors with coherent icache require the sequence sync ; icbi ; isync
> to entire store->execute coherency. icbi (to any address) must be
> executed to ensure isync flushes the pipeline. See "POWER9 Processor
> User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi)" for
> details.
> 
> __kernel_sync_dicache is missing icbi for the coherent icache path.
> Add it.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/vdso: Fix __kernel_sync_dicache sequence with coherent icache
  https://git.kernel.org/powerpc/c/28f07fab26319dacc5675ae01dfc84d82122c59b

cheers

Re: [PATCH 1/2] powerpc/mce: mce_init use early_cpu_to_node

[Michael Ellerman]

On Mon, 11 Jul 2022 13:06:52 +1000, Nicholas Piggin wrote:
> cpu_to_node is not available (setup_arch() is called before
> setup_per_cpu_areas() by start_kernel()).
> 
> 

Patch 1 applied to powerpc/next.

[1/2] powerpc/mce: mce_init use early_cpu_to_node
  https://git.kernel.org/powerpc/c/f57261e69825b332f22480b37a33e03d066c0da2

cheers

Re: [PATCH 0/3] powerpc/64s: Restrict NMMU workarounds

[Michael Ellerman]

On Wed, 25 May 2022 12:23:55 +1000, Nicholas Piggin wrote:
> POWER10 doesn't require the two Nest MMU workarounds according to the
> workbook. Also remove the last vestige of the spurious fault flushing
> for NMMU which shouldn't have been required anyway.
> 
> Thanks,
> Nick
> 
> [...]

Applied to powerpc/next.

[1/3] powerpc/64s: POWER10 nest MMU does not require flush escalation workaround
  https://git.kernel.org/powerpc/c/abf0878ce95f8a9b47d8ecf2de1d4617bec21711
[2/3] powerpc/64s: POWER10 nest MMU can upgrade PTE access authority without 
TLB flush
  https://git.kernel.org/powerpc/c/2a8a0f420f74425bf5f80760fd14d7a2c3abb87d
[3/3] powerpc/64s: Remove spurious fault flushing for NMMU
  https://git.kernel.org/powerpc/c/fd193f85d3206cc7e7aeea2b6033d105cca38d01

cheers

Re: [PATCH v2 0/3] Provide PowerVM LPAR Platform KeyStore driver for Self Encrypting Drives

[Michael Ellerman]

On Sat, 23 Jul 2022 07:30:45 -0400, Nayna Jain wrote:
> PowerVM provides an isolated Platform KeyStore(PKS)[1] storage allocation
> for each partition(LPAR) with individually managed access controls to store
> sensitive information securely. The Linux Kernel can access this storage by
> interfacing with the hypervisor using a new set of hypervisor calls.
> 
> This storage can be used for multiple purposes. The current two usecases
> are:
> 
> [...]

Patch 1 applied to powerpc/next.

[1/3] powerpc/pseries: define driver for Platform KeyStore
  https://git.kernel.org/powerpc/c/2454a7af0f2a42918aa972147a0bec38e6656cd8

cheers

Re: [PATCH v6 1/3] powerpc/powernv: Avoid crashing if rng is NULL

[Michael Ellerman]

On Thu, 28 Jul 2022 00:32:17 +1000, Michael Ellerman wrote:
> On a bare-metal Power8 system that doesn't have an "ibm,power-rng", a
> malicious QEMU and guest that ignore the absence of the
> KVM_CAP_PPC_HWRNG flag, and calls H_RANDOM anyway, will dereference a
> NULL pointer.
> 
> In practice all Power8 machines have an "ibm,power-rng", but let's not
> rely on that, add a NULL check and early return in
> powernv_get_random_real_mode().
> 
> [...]

Applied to powerpc/next.

[1/3] powerpc/powernv: Avoid crashing if rng is NULL
  https://git.kernel.org/powerpc/c/90b5d4fe0b3ba7f589c6723c6bfb559d9e83956a
[2/3] powerpc/powernv/kvm: Use darn for H_RANDOM on Power9
  https://git.kernel.org/powerpc/c/7ef3d06f1bc4a5e62273726f3dc2bd258ae1c71f
[3/3] powerpc/powernv: rename remaining rng powernv_ functions to pnv_
  https://git.kernel.org/powerpc/c/978030f054ff97d9079b35f0178e2013918fb316

cheers

Re: [PATCH] powerpc: Update reviewers

[Michael Ellerman]

On Wed, 29 Jun 2022 16:08:17 +1000, Michael Ellerman wrote:
> Christophe and Nick have been active in recent years on the mailing list
> and making contributions, add them as reviewers.
> 
> Paul and Ben are no longer actively reviewing powerpc patches, remove
> them from the reviewers, they're still on linuxppc-dev if needed.
> 
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Update reviewers
  https://git.kernel.org/powerpc/c/51ac6d4ceaa4f2e878c1aa399135f2514a6acc24

cheers

Re: [PATCH] powerpc: Fix all occurences of duplicate words

[Michael Ellerman]

On Mon, 18 Jul 2022 19:51:58 +1000, Michael Ellerman wrote:
> Since commit 87c78b612f4f ("powerpc: Fix all occurences of "the the"")
> fixed "the the", there's now a steady stream of patches fixing other
> duplicate words.
> 
> Just fix them all at once, to save the overhead of dealing with
> individual patches for each case.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Fix all occurences of duplicate words
  https://git.kernel.org/powerpc/c/2b461880c20777d317b4ad24ef040918860133ca

cheers

Re: [PATCH 01/13] selftests/powerpc: Ensure 16-byte stack pointer alignment

[Michael Ellerman]

On Tue, 28 Jun 2022 00:02:27 +1000, Michael Ellerman wrote:
> The PUSH/POP_BASIC_STACK helpers in basic_asm.h do not ensure that the
> stack pointer is always 16-byte aligned, which is required per the ABI.
> 
> Fix the macros to do the alignment if the caller fails to.
> 
> Currently only one caller passes a non-aligned size, tm_signal_self(),
> which hasn't been caught in testing, presumably because it's a leaf
> function.
> 
> [...]

Applied to powerpc/next.

[01/13] selftests/powerpc: Ensure 16-byte stack pointer alignment

https://git.kernel.org/powerpc/c/fd19a1f72aa7bf687609e0810e644fe5b3846342
[02/13] selftests/powerpc/ptrace: Set LOCAL_HDRS

https://git.kernel.org/powerpc/c/cf4baafd7846b3def67057a09b7603a6b566417a
[03/13] selftests/powerpc/ptrace: Split CFLAGS better

https://git.kernel.org/powerpc/c/3c20a1d07c377d7260ca853e216cc85bbd7857fa
[04/13] selftests/powerpc: Don't save CR by default in asm helpers

https://git.kernel.org/powerpc/c/8f2e02394dc907f5e0140bfab80a9aa11e3449ed
[05/13] selftests/powerpc: Don't save TOC by default in asm helpers

https://git.kernel.org/powerpc/c/cfbc0723d18f5aeab4308c66d7d1992317eed7c9
[06/13] selftests/powerpc: Add 32-bit support to asm helpers

https://git.kernel.org/powerpc/c/bd4d3042e7570fc024b5ff15e895363e4bf5a78f
[07/13] selftests/powerpc/ptrace: Drop unused load_fpr_single_precision()

https://git.kernel.org/powerpc/c/af9f3f31f6cc8e3f637f19189e83d99f3fdd96ad
[08/13] selftests/powerpc/ptrace: Convert to load/store doubles

https://git.kernel.org/powerpc/c/53fa86e7ece54cbb1fae1443bd6b348088d8ce7e
[09/13] selftests/powerpc/ptrace: Build the ptrace-gpr test as 32-bit when 
possible

https://git.kernel.org/powerpc/c/149a497d5fda3e996a00437260a4c170e43909c8
[10/13] selftests/powerpc/ptrace: Do more of ptrace-gpr in asm

https://git.kernel.org/powerpc/c/611e385087efc2cc3a7033aedd3f84ad0cf2a703
[11/13] selftests/powerpc/ptrace: Make child errors more obvious

https://git.kernel.org/powerpc/c/7b1513d02edf4a6334618070641f47abbbef0cef
[12/13] selftests/powerpc/ptrace: Use more interesting values

https://git.kernel.org/powerpc/c/c5a814cc992002c36fa5b7db5fbd55efb7430386
[13/13] selftests/powerpc/ptrace: Add peek/poke of FPRs

https://git.kernel.org/powerpc/c/6c9c7d8fbc3a2a0cfed0e7a5b39581847b632f0b

cheers

Re: [PATCH v2] powerpc/purgatory: Omit use of bin2c

[Michael Ellerman]

On Mon, 25 Jul 2022 10:56:19 +0900, Masahiro Yamada wrote:
> The .incbin assembler directive is much faster than bin2c + $(CC).
> 
> Do similar refactoring as in commit 4c0f032d4963 ("s390/purgatory:
> Omit use of bin2c").
> 
> Please note the .quad directive matches to size_t in C (both 8 byte)
> because the purgatory is compiled only for the 64-bit kernel.
> (KEXEC_FILE depends on PPC64).
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/purgatory: Omit use of bin2c
  https://git.kernel.org/powerpc/c/9257971377e2fe6e82f41f688651a82a2f160a88

cheers

Re: [PATCH v5 0/4] Extending NMI watchdog during LPM

[Michael Ellerman]

On Wed, 13 Jul 2022 17:47:25 +0200, Laurent Dufour wrote:
> When a partition is transferred, once it arrives at the destination node,
> the partition is active but much of its memory must be transferred from the
> start node.
> 
> It depends on the activity in the partition, but the more CPU the partition
> has, the more memory to be transferred is likely to be. This causes latency
> when accessing pages that need to be transferred, and often, for large
> partitions, it triggers the NMI watchdog.
> 
> [...]

Applied to powerpc/next.

[1/4] powerpc/mobility: wait for memory transfer to complete
  https://git.kernel.org/powerpc/c/882c0d1704cf61df13f01933269202d51e74b9f3
[2/4] watchdog: export lockup_detector_reconfigure
  https://git.kernel.org/powerpc/c/7c56a8733d0a2a4be2438a7512566e5ce552fccf
[3/4] powerpc/watchdog: introduce a NMI watchdog's factor
  https://git.kernel.org/powerpc/c/f5e74e836097d1004077390717d4bd95d4a2c27a
[4/4] pseries/mobility: set NMI watchdog factor during an LPM
  https://git.kernel.org/powerpc/c/118b1366930c8c833b8b36abef657f40d4e26610

cheers

Re: [PATCH v2] powerpc/perf: Give generic PMU a nice name

[Michael Ellerman]

On Fri, 10 Jun 2022 14:10:06 +0930, Joel Stanley wrote:
> When booting on a machine that uses the compat pmu driver we see this:
> 
>  [0.071192] GENERIC_COMPAT performance monitor hardware support registered
> 
> Which is a bit shouty. Give it a nicer name.
> 
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/perf: Give generic PMU a nice name
  https://git.kernel.org/powerpc/c/78988b273d592ce74c8aecdd5d748906c38a9e9d

cheers

Re: [PATCH v2] powerpc/crash: save cpu register data in crash_smp_send_stop()

[Michael Ellerman]

On Thu, 30 Jun 2022 12:19:42 +0530, Hari Bathini wrote:
> During kdump, two set of NMI IPIs are sent to secondary CPUs, if
> 'crash_kexec_post_notifiers' option is set. The first set of NMI IPIs
> to stop the CPUs and the other set to collect register data. Instead,
> capture register data for secondary CPUs while stopping them itself.
> Also, fallback to smp_send_stop() in case the function gets called
> without kdump configured.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/crash: save cpu register data in crash_smp_send_stop()
  https://git.kernel.org/powerpc/c/c7255058b5430b5c42932383bd8887d591e7973a

cheers

Re: [PATCH v5 1/2] powerpc/perf: Use PVR rather than oprofile field to determine CPU version

[Michael Ellerman]

On Thu, 7 Jul 2022 16:37:17 +0200, Christophe Leroy wrote:
> From: Rashmica Gupta 
> 
> Currently the perf CPU backend drivers detect what CPU they're on using
> cur_cpu_spec->oprofile_cpu_type.
> 
> Although that works, it's a bit crufty to be using oprofile related fields,
> especially seeing as oprofile is more or less unused these days.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/perf: Use PVR rather than oprofile field to determine CPU version
  https://git.kernel.org/powerpc/c/ec3eb9d941a98f4c0dac263110729680a734279b
[2/2] powerpc: Remove remaining parts of oprofile
  https://git.kernel.org/powerpc/c/62ccae78820b25a0ac64bb0f648388ec834fcb3c

cheers

Re: [PATCH v3 1/4] video: fbdev: offb: Include missing linux/platform_device.h

[Michael Ellerman]

On Fri, 8 Jul 2022 09:11:05 +0200, 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")
> 
> [...]

Applied to powerpc/next.

[1/4] video: fbdev: offb: Include missing linux/platform_device.h
  https://git.kernel.org/powerpc/c/ebef8abc963b9e537c0a0d619dd8faf1b8f2b183
[2/4] scsi: cxlflash: Include missing linux/irqdomain.h
  https://git.kernel.org/powerpc/c/61657dcd528b75cd196adaf56890124c13953c8d
[3/4] powerpc: Remove asm/prom.h from asm/mpc52xx.h and asm/pci.h
  https://git.kernel.org/powerpc/c/4d5c5bad51935482437528f7fa4dffdcb3330d8b
[4/4] powerpc: Finally remove unnecessary headers from asm/prom.h
  https://git.kernel.org/powerpc/c/36afe68714d45edf34430d28e3dc787425ad8b22

cheers

Re: [PATCH v1 1/5] powerpc/32: Do not allow selection of e5500 or e6500 CPUs on PPC32

[Michael Ellerman]

On Mon, 11 Jul 2022 16:19:29 +0200, Christophe Leroy wrote:
> Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
> enlarged the CPU selection logic to PPC32 by removing depend to
> PPC64, and failed to restrict that depend to E5500_CPU and E6500_CPU.
> Fortunately that got unnoticed because -mcpu=8540 will override the
> -mcpu=e500mc64 or -mpcu=e6500 as they are ealier, but that's
> fragile and may no be right in the future.
> 
> [...]

Applied to powerpc/next.

[1/5] powerpc/32: Do not allow selection of e5500 or e6500 CPUs on PPC32
  https://git.kernel.org/powerpc/c/9be013b2a9ecb29b5168e4b9db0e48ed53acf37c
[2/5] powerpc/32: Don't always pass -mcpu=powerpc to the compiler
  https://git.kernel.org/powerpc/c/446cda1b21d9a6b3697fe399c6a3a00ff4a285f5
[3/5] powerpc/405: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')
  https://git.kernel.org/powerpc/c/ff27d9200a98757efc7c2cdf198904fd79cf4ffd
[4/5] powerpc/44x: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')
  https://git.kernel.org/powerpc/c/2255411d1d0f0661d1e5acd5f6edf4e6652a345a
[5/5] powerpc/64e: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')
  https://git.kernel.org/powerpc/c/d6b551b8f90cc92c7d3c09cf38c748efe305ecb4

cheers

Re: [PATCH] powerpc/32s: Fix boot failure with KASAN + SMP + JUMP_LABEL_FEATURE_CHECK_DEBUG

[Michael Ellerman]

On Fri, 1 Jul 2022 08:06:15 +0200, Christophe Leroy wrote:
> Since commit 4291d085b0b0 ("powerpc/32s: Make pte_update() non
> atomic on 603 core"), pte_update() has been using
> mmu_has_feature(MMU_FTR_HPTE_TABLE) to avoid a useless atomic
> operation on 603 cores.
> 
> When kasan_early_init() sets up the early zero shadow, it uses
> __set_pte_at(). On book3s/32, __set_pte_at() calls pte_update()
> when CONFIG_SMP is selected in order to ensure the preservation of
> _PAGE_HASHPTE in case of concurrent update of the PTE. But that's
> too early for mmu_has_feature(), so when
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG is selected, mmu_has_feature()
> calls printk(). That's too early to call printk() because KASAN
> early zero shadow page is not set up yet. It leads to a deadlock.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/32s: Fix boot failure with KASAN + SMP + 
JUMP_LABEL_FEATURE_CHECK_DEBUG
  https://git.kernel.org/powerpc/c/6042a1652d643d1d34fa89bb314cb102960c0800

cheers

Re: [PATCH 1/3] powerpc/probes: Remove ppc_opcode_t

[Michael Ellerman]

On Thu, 7 Jul 2022 16:55:14 +0200, Christophe Leroy wrote:
> ppc_opcode_t is just an u32. There is no point in hiding u32
> behind such a typedef. Remove it.
> 
> 

Applied to powerpc/next.

[1/3] powerpc/probes: Remove ppc_opcode_t
  https://git.kernel.org/powerpc/c/7b48377e1d9f68a1b58dfd22d40b083f38ce76a0
[2/3] powerpc/ppc-opcode: Define and use PPC_RAW_TRAP() and PPC_RAW_TW()
  https://git.kernel.org/powerpc/c/d00d762daf1278641eec92d74011a7e625e84a68
[3/3] powerpc/ppc-opcode: Define and use PPC_RAW_SETB()
  https://git.kernel.org/powerpc/c/de40303b54bc458d7df0d4b4ee1d296df7fe98c7

cheers

Re: [PATCH 1/2] powerpc/32: Call mmu_mark_initmem_nx() regardless of data block mapping.

[Michael Ellerman]

On Tue, 14 Jun 2022 12:34:08 +0200, Christophe Leroy wrote:
> mark_initmem_nx() calls either mmu_mark_initmem_nx() or
> set_memory_attr() based on return from v_block_mapped()
> of _sinittext.
> 
> But we can now handle text and data independently, so that
> text may be mapped by block even when data is mapped by pages.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/32: Call mmu_mark_initmem_nx() regardless of data block mapping.
  https://git.kernel.org/powerpc/c/980bbf7ca72012d317617fcdbfabe8708e4cef29
[2/2] powerpc/32: Set an IBAT covering up to _einittext during init
  https://git.kernel.org/powerpc/c/2a0fb3c155c97c75176e557d61f8e66c1bd9b735

cheers

Re: [PATCH v3 0/4] pseries-wdt: initial support for H_WATCHDOG-based watchdog timers

[Michael Ellerman]

On Wed, 13 Jul 2022 15:23:31 -0500, Scott Cheloha wrote:
> PAPR v2.12 defines a new hypercall, H_WATCHDOG.  This patch series
> adds support for this hypercall to powerpc/pseries kernels and
> introduces a new watchdog driver, "pseries-wdt", for the virtual
> timers exposed by the hypercall.
> 
> This series is preceded by the following:
> 
> [...]

Applied to powerpc/next.

[1/4] powerpc/pseries: hvcall.h: add H_WATCHDOG opcode, H_NOOP return code
  https://git.kernel.org/powerpc/c/c6b2bd262b33aa2451f52aec2190131d1762945a
[2/4] powerpc/pseries: add FW_FEATURE_WATCHDOG flag
  https://git.kernel.org/powerpc/c/1621563ec62ff143c7b817dd5eab0884cdfaf89d
[3/4] powerpc/pseries: register pseries-wdt device with platform bus
  https://git.kernel.org/powerpc/c/578030bfe117060bf86c81aaa7b3faead4589810
[4/4] watchdog/pseries-wdt: initial support for H_WATCHDOG-based watchdog timers
  https://git.kernel.org/powerpc/c/69472ffa6575e3a1c1e3324dd06395af0f63eb71

cheers

Re: [PATCH kernel] powerpc/iommu: Fix iommu_table_in_use for a small default DMA window case

[Michael Ellerman]

On Thu, 14 Jul 2022 18:11:19 +1000, Alexey Kardashevskiy wrote:
> The existing iommu_table_in_use() helper checks if the kernel is using
> any of TCEs. There are some reserved TCEs:
> 1) the very first one if DMA window starts from 0 to avoid having a zero
> but still valid DMA handle;
> 2) it_reserved_start..it_reserved_end to exclude MMIO32 window in case
> the default window spans across that - this is the default for the first
> DMA window on PowerNV.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/iommu: Fix iommu_table_in_use for a small default DMA window case
  https://git.kernel.org/powerpc/c/d80f6de9d601c30b53c17f00cb7cfe3169f2ddad

cheers

Re: [PATCH 0/3] Documentation: powerpc: documentation fixes for Documentation/powerpc/elf_hwcaps.rst

[Michael Ellerman]

On Thu, 28 Jul 2022 10:33:30 +0700, Bagas Sanjaya wrote:
> After merging powerpc tree for linux-next integration testing, Stephen
> Rothwell reported htmldocs warnings at [1]. Fix these with self-explanatory
> fixes in the shortlog below.
> 
> [1]: 
> https://lore.kernel.org/linuxppc-dev/20220727220050.549db...@canb.auug.org.au/
> 
> Bagas Sanjaya (3):
>   Documentation: powerpc: fix indentation warnings
>   Documentation: use different label names for each arch's
> elf_hwcaps.rst
>   Documentation: powerpc: add elf_hwcaps to table of contents
> 
> [...]

Applied to powerpc/next.

[1/3] Documentation: powerpc: fix indentation warnings
  https://git.kernel.org/powerpc/c/4515862b66d3bdaf681cade1c72f047c93d94d01
[2/3] Documentation: use different label names for each arch's elf_hwcaps.rst
  https://git.kernel.org/powerpc/c/0595a216920cb035030c73cec3ab9fe413ef1d77
[3/3] Documentation: powerpc: add elf_hwcaps to table of contents
  https://git.kernel.org/powerpc/c/a05aae92f84ba6d2705f6dac206ef5dcf097ea96

cheers

Re: [PATCH kernel v2] pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window

[Michael Ellerman]

On Wed, 29 Jun 2022 16:06:14 +1000, Alexey Kardashevskiy wrote:
> The pseries platform uses 32bit default DMA window (always 4K pages) and
> optional 64bit DMA window available via DDW ("Dynamic DMA Windows"),
> 64K or 2M pages. For ages the default one was not removed and a huge
> window was created in addition. Things changed with SRIOV-enabled
> PowerVM which creates a default-and-bigger DMA window in 64bit space
> (still using 4K pages) for IOV VFs so certain OSes do not need to use
> the DDW API in order to utilize all available TCE budget.
> 
> [...]

Applied to powerpc/next.

[1/1] pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window
  https://git.kernel.org/powerpc/c/b1fc44eaa9ba31e28c4125d6b9205a3582b47b5d

cheers

Re: [PATCH V3 1/2] powerpc/perf: Add support for caps under sysfs in powerpc

[Michael Ellerman]

On Fri, 20 May 2022 14:16:29 +0530, Athira Rajeev wrote:
> Add caps support under "/sys/bus/event_source/devices//"
> for powerpc. This directory can be used to expose some of the
> specific features that powerpc PMU supports to the user.
> Example: pmu_name. The name of PMU registered will depend on
> platform, say power9 or power10 or it could be Generic Compat
> PMU.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/perf: Add support for caps under sysfs in powerpc
  https://git.kernel.org/powerpc/c/6320e693d98c7430653866b7ca6679338134cb79
[2/2] docs: ABI: sysfs-bus-event_source-devices: Document sysfs caps entry for 
PMU
  https://git.kernel.org/powerpc/c/999d7c47a0f737157608b9b0d2d37bdd1afec58c

cheers

Re: [PATCH kernel] powerpc/ioda/iommu/debugfs: Generate unique debugfs entries

[Michael Ellerman]

On Thu, 14 Jul 2022 18:08:00 +1000, Alexey Kardashevskiy wrote:
> The iommu_table::it_index is a LIOBN which is not initialized on PowerNV
> as it is not used except IOMMU debugfs where it is used for a node name.
> 
> This initializes it_index witn a unique number to avoid warnings and
> have a node for every iommu_table.
> 
> This should not cause any behavioral change without CONFIG_IOMMU_DEBUGFS.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/ioda/iommu/debugfs: Generate unique debugfs entries
  https://git.kernel.org/powerpc/c/d73b46c3c1449bf27f793b9d9ee86ed70c7a7163

cheers

RE: [PATCH v4 00/25] net: dpaa: Cleanups in preparation for phylink conversion

[Camelia Alexandra Groza]

> -Original Message-
> From: Sean Anderson 
> Sent: Monday, July 25, 2022 18:10
> To: David S . Miller ; Eric Dumazet
> ; Jakub Kicinski ; Paolo Abeni
> ; net...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; Camelia Alexandra Groza
> ; open list ;
> Madalin Bucur ; linux-arm-
> ker...@lists.infradead.org; Sean Anderson ;
> Krzysztof Kozlowski ; Leo Li
> ; Rob Herring ;
> devicet...@vger.kernel.org
> Subject: [PATCH v4 00/25] net: dpaa: Cleanups in preparation for phylink
> conversion
> 
> This series contains several cleanup patches for dpaa/fman. While they
> are intended to prepare for a phylink conversion, they stand on their
> own. This series was originally submitted as part of [1].
> 
> [1] 
> https://lore.kernel.org/netdev/20220715215954.1449214-1-sean.ander...@seco.com
>  

For the series:
Acked-by: Camelia Groza 
 
> Changes in v4:
> - Clarify commit message
> - weer -> were
> - tricy -> tricky
> - Use mac_dev for calling change_addr
> - qman_cgr_create -> qman_create_cgr
> 
> Changes in v3:
> - Incorperate some minor changes into the first FMan binding commit
> 
> Changes in v2:
> - Convert FMan MAC bindings to yaml
> - Remove some unused variables
> - Fix prototype for dtsec_initialization
> - Fix warning if sizeof(void *) != sizeof(resource_size_t)
> - Specify type of mac_dev for exception_cb
> - Add helper for sanity checking cgr ops
> - Add CGR update function
> - Adjust queue depth on rate change
> 
> Sean Anderson (25):
>   dt-bindings: net: Convert FMan MAC bindings to yaml
>   net: fman: Convert to SPDX identifiers
>   net: fman: Don't pass comm_mode to enable/disable
>   net: fman: Store en/disable in mac_device instead of mac_priv_s
>   net: fman: dtsec: Always gracefully stop/start
>   net: fman: Get PCS node in per-mac init
>   net: fman: Store initialization function in match data
>   net: fman: Move struct dev to mac_device
>   net: fman: Configure fixed link in memac_initialization
>   net: fman: Export/rename some common functions
>   net: fman: memac: Use params instead of priv for max_speed
>   net: fman: Move initialization to mac-specific files
>   net: fman: Mark mac methods static
>   net: fman: Inline several functions into initialization
>   net: fman: Remove internal_phy_node from params
>   net: fman: Map the base address once
>   net: fman: Pass params directly to mac init
>   net: fman: Use mac_dev for some params
>   net: fman: Specify type of mac_dev for exception_cb
>   net: fman: Clean up error handling
>   net: fman: Change return type of disable to void
>   net: dpaa: Use mac_dev variable in dpaa_netdev_init
>   soc: fsl: qbman: Add helper for sanity checking cgr ops
>   soc: fsl: qbman: Add CGR update function
>   net: dpaa: Adjust queue depth on rate change
> 
>  .../bindings/net/fsl,fman-dtsec.yaml  | 145 +
>  .../devicetree/bindings/net/fsl-fman.txt  | 128 +
>  .../net/ethernet/freescale/dpaa/dpaa_eth.c|  59 ++-
>  .../ethernet/freescale/dpaa/dpaa_eth_sysfs.c  |   2 +-
>  drivers/net/ethernet/freescale/fman/fman.c|  31 +-
>  drivers/net/ethernet/freescale/fman/fman.h|  31 +-
>  .../net/ethernet/freescale/fman/fman_dtsec.c  | 325 ++--
>  .../net/ethernet/freescale/fman/fman_dtsec.h  |  58 +-
>  .../net/ethernet/freescale/fman/fman_keygen.c |  29 +-
>  .../net/ethernet/freescale/fman/fman_keygen.h |  29 +-
>  .../net/ethernet/freescale/fman/fman_mac.h|  24 +-
>  .../net/ethernet/freescale/fman/fman_memac.c  | 240 +
>  .../net/ethernet/freescale/fman/fman_memac.h  |  57 +-
>  .../net/ethernet/freescale/fman/fman_muram.c  |  31 +-
>  .../net/ethernet/freescale/fman/fman_muram.h  |  32 +-
>  .../net/ethernet/freescale/fman/fman_port.c   |  29 +-
>  .../net/ethernet/freescale/fman/fman_port.h   |  29 +-
>  drivers/net/ethernet/freescale/fman/fman_sp.c |  29 +-
>  drivers/net/ethernet/freescale/fman/fman_sp.h |  28 +-
>  .../net/ethernet/freescale/fman/fman_tgec.c   | 163 +++---
>  .../net/ethernet/freescale/fman/fman_tgec.h   |  54 +-
>  drivers/net/ethernet/freescale/fman/mac.c | 497 ++
>  drivers/net/ethernet/freescale/fman/mac.h |  45 +-
>  drivers/soc/fsl/qbman/qman.c  |  76 ++-
>  include/soc/fsl/qman.h|   9 +
>  25 files changed, 739 insertions(+), 1441 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/fsl,fman-
> dtsec.yaml
> 
> --
> 2.35.1.1320.gc452695387.dirty

[GIT PULL] Please pull powerpc/linux.git powerpc-5.19-6 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull two more powerpc fixes for 5.19.

Notably the re-enablement of the new amdgpu display engine, which was 
previously causing
build errors.

Restricting it to compilers using 128-bit long double seems to have fixed the 
build
failures people were seeing, while still allowing it to build with distribution 
compilers.

It's survived several days in linux-next. There was one report of a new build 
failure, but
that was a genuine failure that has already been fixed:

  
https://lore.kernel.org/amd-gfx/20220728203347.2019728-1-rodrigo.sique...@amd.com/

cheers


The following changes since commit ff6992735ade75aae3e35d16b17da1008d753d28:

  Linux 5.19-rc7 (2022-07-17 13:30:22 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-5.19-6

for you to fetch changes up to c653c591789b3acfa4bf6ae45d5af4f330e50a91:

  drm/amdgpu: Re-enable DCN for 64-bit powerpc (2022-07-26 08:25:38 +1000)

- --
powerpc fixes for 5.19 #6

 - Re-enable the new amdgpu display engine for powerpc, as long as the compiler 
is
   correctly configured.

 - Disable stack variable initialisation in prom_init to fix GCC 12 
allmodconfig.

Thanks to: Dan Horák, Sudip Mukherjee.

- --
Michael Ellerman (3):
  powerpc/64s: Disable stack variable initialisation for prom_init
  Merge tag 'v5.19-rc7' into fixes
  drm/amdgpu: Re-enable DCN for 64-bit powerpc


 arch/powerpc/Kconfig| 4 
 arch/powerpc/kernel/Makefile| 1 +
 drivers/gpu/drm/amd/display/Kconfig | 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmLj1tkACgkQUevqPMjh
pYCa4BAAjoZx05wxNVch2/p50TejvE1RNN63wQr3FZTsixn4I0fNM2uVwoZ/v3uy
EosAcNlJCqD3ZkseCYSVZABN9i41NGAiWkZOaOBA8Gk99PXJz0+sg4RrqE2ikoyT
n0EqcvtyvciBEp/vt1Hrn+MvkVoPdilwRJHCVKSPfiQg7n/kSnRJ1gmhjap8Tjy2
8riyHE2526WCl1cZsP+9us8JsTIpiFfjbLCOPv4wq/D6jqzEE5Aewu8euPhaNuXk
w6F5dUQ9pxAxMue2edpGVmIUTaPU+zwr9gxVQbd4nIVXl2A2HeAySuVgzWW3DdwR
zw4GbviQdHQVac7BiSGWLlpXg0jzXUFbWRZj3QWz9L90WlxNDdSO90gcTMjzkqj/
G3SpfTuNMphdMldwJ+TNS1g3LYJtBC5iV9Cuhq125uW3lMnZZ1BBaeIJTnemr3dY
qK4lxYTUT/UwdH+9qgIa6KZ+guGyu8UIe1GxUcHBlozvP7OoDijsSEChAQ1mNw41
zQUPcnCCTZ0ZlDG9kHF4FmXvrOQy682AajKapPwxUiOPKRDzc8QHMK6igLY3sdA5
lOdQlClTHCSa1yx5U+f3PSaS/eDkfThSFtJSOQvdIGz7fpeLuV8bWSJR+JYErLBT
uVZj0Pej4Ah4IaG1hMfJshq7+arghhULQqqbKMj4BqhwvP0i/rA=
=7HNO
-END PGP SIGNATURE-

Re: [PATCH kernel] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains

[Jason Gunthorpe]

On Fri, Jul 29, 2022 at 04:24:36AM +, Tian, Kevin wrote:
> > It is a POWER specific thing with one not-so-obvious consequence of each
> > window having an independent page size (fixed at the moment or creation)
> > and (most likely) different page size, like, 4K vs. 2M.
> 
> page size is anyway decided by the iommu driver. Same for other vendors.
> the caller (e.g. vfio) just tries to map as many contiguous pages as
> possible but in the end it's iommu driver to decide the actual size.

An iommu_domain with a non-uniform page_size is weird, but it could be
made to work as some device-specific thing. The only thing the core
codes care about is the minimum alignment, so you'd just have to set
it to 4k and mapping the wrong thing to the 2M area would fail.

domains with their io page size != PAGE_SIZE are already very special
things that require special handling by userspace..

Jason

Re: [linux-next] Build failure drivers/cxl/cxl_pmem (powerpc)

[Sachin Sant]

> From 8ca5b098b6ff1048953be748dbffc987996e2605 Mon Sep 17 00:00:00 2001
> From: Michael Ellerman 
> Date: Fri, 29 Jul 2022 16:13:55 +1000
> Subject: [PATCH] powerpc/mm: Export memory_add_physaddr_to_nid() for modules
> 
> The cxl_pmem module wants to call memory_add_physaddr_to_nid(), so
> export the symbol.
> 
> Fixes: 04ad63f086d1 ("cxl/region: Introduce cxl_pmem_region objects")
> Reported-by: Sachin Sant 
> Signed-off-by: Michael Ellerman 
> ---

Thanks Michael.

Tested-by: Sachin Sant 

> arch/powerpc/mm/mem.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 7b0d286bf9ba..01772e79fd93 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -55,6 +55,7 @@ int memory_add_physaddr_to_nid(u64 start)
> {
>   return hot_add_scn_to_nid(start);
> }
> +EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
> #endif
> 
> int __weak create_section_mapping(unsigned long start, unsigned long end,
> -- 
> 2.35.3
> 

[Bug 215285] power9 le: amdgpu: *ERROR* hw_init of IP block failed -22

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215285

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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 215285] power9 le: amdgpu: *ERROR* hw_init of IP block failed -22

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215285

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mich...@ellerman.id.au
 Resolution|--- |ANSWERED

--- Comment #2 from Michael Ellerman (mich...@ellerman.id.au) ---
This would be better reported to the amdgpu developers:

https://gitlab.freedesktop.org/drm/amd/-/issues

-- 
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 216183] [bisected] Kernel 5.19-rc4 boots ok with CONFIG_PPC_RADIX_MMU=y but fails to boot with CONFIG_PPC_HASH_MMU_NATIVE=y

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216183

--- Comment #9 from Michael Ellerman (mich...@ellerman.id.au) ---
I can't make sense of that bisection result. I'm not saying it's wrong, but I
can't see how that commit can cause this bug.

-- 
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 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=206669

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|NEEDINFO|ASSIGNED

-- 
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 213079] [bisected] IRQ problems and crashes on a PowerMac G5 with 5.12.3

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213079

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||mich...@ellerman.id.au

-- 
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 216090] GCC12: printk.h:446:44: error: using a dangling pointer to '__str'

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216090

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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 216090] GCC12: printk.h:446:44: error: using a dangling pointer to '__str'

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216090

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 CC||mich...@ellerman.id.au
 Resolution|ANSWERED|CODE_FIX

--- Comment #2 from Michael Ellerman (mich...@ellerman.id.au) ---
Fixed in 2a83afe72a2b ("powerpc/64: Drop ppc_inst_as_str()").

The warning has also been disabled in 49beadbd47c2 ("gcc-12: disable
'-Wdangling-pointer' warning for now").

-- 
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 v2] powerpc/85xx: Fix reference leak in xes_mpc85xx_setup_arch

[Michael Ellerman]

Miaoqian Lin  writes:
> of_find_node_by_path() returns remote device nodepointer with
> refcount incremented, we should use of_node_put() on it when done.
> Add missing of_node_put() to avoid refcount leak.
>
> Fixes: 3038acf9091f ("powerpc/85xx: Add platform support for X-ES MPC85xx 
> boards")
> Signed-off-by: Miaoqian Lin 
> ---
> changes in v2:
> - update Fixes tag.
> v1 Link: https://lore.kernel.org/all/20220603120907.1-1-linmq...@gmail.com
> ---
>  arch/powerpc/platforms/85xx/xes_mpc85xx.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/85xx/xes_mpc85xx.c 
> b/arch/powerpc/platforms/85xx/xes_mpc85xx.c
> index 5836e4ecb7a0..93f67b430714 100644
> --- a/arch/powerpc/platforms/85xx/xes_mpc85xx.c
> +++ b/arch/powerpc/platforms/85xx/xes_mpc85xx.c
> @@ -130,6 +130,8 @@ static void __init xes_mpc85xx_setup_arch(void)
>   mpc85xx_smp_init();
>  
>   fsl_pci_assign_primary();
> +
> + of_node_put(root);
>  }

For context, here is the full function:

static void __init xes_mpc85xx_setup_arch(void)
{
struct device_node *root;
const char *model = "Unknown";

root = of_find_node_by_path("/");
if (root == NULL)
return;

model = of_get_property(root, "model", NULL);

printk(KERN_INFO "X-ES MPC85xx-based single-board computer: %s\n",
   model + strlen("xes,"));

xes_mpc85xx_fixups();

mpc85xx_smp_init();

fsl_pci_assign_primary();
}


So yes it's missing an of_node_put(root).

But rather than add the of_node_put(), it would be simpler to just use
of_root directly, then it doesn't need an of_node_put() at all.

But then look closer. To begin with model is assigned "Unknown", but
then unconditionally overwritten by the of_get_property() call. So
that's a waste of space.

And then if there's no model property of_get_property() will return
NULL, and then the model + strlen("xes,") would oops.

And all of that just to print the model at boot, which is not really
necessary, anyone who cares can look it up in /proc/device-tree
after the system has booted.

So please just remove the lookup and printing of model entirely.

cheers

Re: [linux-next] Build failure drivers/cxl/cxl_pmem (powerpc)

[Michael Ellerman]

Sachin Sant  writes:
> Linux-next (5.19.0-rc8-next-20220728) fails to build on powerpc with
> following error:
>
> ERROR: modpost: "memory_add_physaddr_to_nid" [drivers/cxl/cxl_pmem.ko] 
> undefined!
> make[1]: *** [scripts/Makefile.modpost:128: modules-only.symvers] Error 1
>
> The code in question was last changed by following patch:
>
> commit 04ad63f086d1
>cxl/region: Introduce cxl_pmem_region objects

This should fix it.

Dan, do you want to apply that on top of your tree to reduce the window
of breakage?

cheers


>From 8ca5b098b6ff1048953be748dbffc987996e2605 Mon Sep 17 00:00:00 2001
From: Michael Ellerman 
Date: Fri, 29 Jul 2022 16:13:55 +1000
Subject: [PATCH] powerpc/mm: Export memory_add_physaddr_to_nid() for modules

The cxl_pmem module wants to call memory_add_physaddr_to_nid(), so
export the symbol.

Fixes: 04ad63f086d1 ("cxl/region: Introduce cxl_pmem_region objects")
Reported-by: Sachin Sant 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/mm/mem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 7b0d286bf9ba..01772e79fd93 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -55,6 +55,7 @@ int memory_add_physaddr_to_nid(u64 start)
 {
return hot_add_scn_to_nid(start);
 }
+EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
 #endif
 
 int __weak create_section_mapping(unsigned long start, unsigned long end,
-- 
2.35.3