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

2022-07-07 Thread Scott Cheloha
On Fri, Jun 24, 2022 at 11:27:24PM +1000, Michael Ellerman wrote:
> Hi Scott,
> 
> A few comments below ...
> 
> Scott Cheloha  writes:
> > 
> > [...]
> > 
> > diff --git a/Documentation/watchdog/watchdog-parameters.rst 
> > b/Documentation/watchdog/watchdog-parameters.rst
> > index 223c99361a30..29153eed6689 100644
> > --- a/Documentation/watchdog/watchdog-parameters.rst
> > +++ b/Documentation/watchdog/watchdog-parameters.rst
> > @@ -425,6 +425,18 @@ pnx833x_wdt:
> >  
> >  -
> >  
> > +pseries-wdt:
> > +action:
> > +   Action taken when watchdog expires: 0 (power off), 1 (restart),
> > +   2 (dump and restart). (default=1)
> 
> I doesn't look like these values match what other drivers use to any
> great extent.
> 
> So why not use the values from PAPR directly?
> 
> ie. 1 = power off, 2 = hard reset, 3 = dump & restart.
> 
> It seems like it would be easier to follow if the values map directly.
> 
> It's possible in future PAPR adds 247 to mean something, in which case
> maybe we'd want to map that to a less silly value, but at least for now
> the PAPR values are sensible enough.

I tried using 1-2-3 in Patch v1 but Guenter objected and we switched:

https://lore.kernel.org/linux-watchdog/a6090ef3-f597-e10b-010b-cc32bff08...@roeck-us.net/

I think the code is fine to read as-is.  We're not expecting the
administrator to read the PAPR, right?  So 1-2-3 is not any more
intuitive for the user than 0-1-2.

Given that it's all arbitrary and there aren't any hard rules for
module parameters outside of general programmer "that seems
fine"-ness, I would really like to leave the numbers as-is.

> > +timeout:
> > +   Initial watchdog timeout in seconds. (default=60)
> 
> That seems like a pretty common value, I don't see any guidance in PAPR.
> Do we have any input from PowerVM on whether that's a good value?

Currently the minimum timeout is 500ms on all the builds I've tried.
I doubt the minimum will ever be anywhere near as large as 60s on a
practical H_WATCHDOG implementation, so I don't think there is any
risk of the driver failing to probe.

Real software using the watchdog API will set a timeout to a smaller
value if it needs to.

60 seconds gives userland ample time to reconfigure the watchdog
without risk of it expiring in the midst of a bunch of ioctl(2) calls
before they reach the main loop.

> > diff --git a/drivers/watchdog/pseries-wdt.c b/drivers/watchdog/pseries-wdt.c
> > new file mode 100644
> > index ..cfe53587457d
> > --- /dev/null
> > +++ b/drivers/watchdog/pseries-wdt.c
> > @@ -0,0 +1,264 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2022 International Business Machines, Inc.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRV_NAME "pseries-wdt"
> > +
> > +/*
> > + * The PAPR's MSB->LSB bit ordering is 0->63.  These macros simplify
> > + * defining bitfields as described in the PAPR without needing to
> > + * transpose values to the more C-like 63->0 ordering.
> > + */
> > +#define SETFIELD(_v, _b, _e)   \
> > +   (((unsigned long)(_v) << PPC_BITLSHIFT(_e)) & PPC_BITMASK((_b), (_e)))
> > +#define GETFIELD(_v, _b, _e)   \
> > +   (((unsigned long)(_v) & PPC_BITMASK((_b), (_e))) >> PPC_BITLSHIFT(_e))
> 
> This will probably sound like a cranky maintainer rant, but ...,
> I really dislike these GETFIELD/SETFIELD macros.
> 
> I know you didn't invent them, but I would be much happier if you didn't
> use them.
> 
> I know they (slightly) simplify things when you're transcribing values
> from PAPR into the source, but that happens only once.
> 
> And then for the rest of eternity the source is harder to read because
> there's this ridiculous level of indirection through insane macros just
> to define some constants.
> 
> Anyone trying to use a debugger against this code will see a value in
> memory like 0x200 and have to sit down and work out which SETFIELD()
> macro it corresponds to.

Don't look at me, I never would have come up with them.  I got them
from Alexey :)

I will drop them.

> > +/*
> > + * The H_WATCHDOG hypercall first appears in PAPR v2.12 and is
> > + * described fully in sections 14.5 and 14.15.6.
> > + *
> > + *
> > + * H_WATCHDOG Input
> > + *
> > + * R4: "flags":
> > + *
> > + * Bits 48-55: "operation"
> > + *
> > + * 0x01  Start Watchdog
> > + * 0x02  Stop Watchdog
> > + * 0x03  Query Watchdog Capabilities
> > + */
> > +#define PSERIES_WDTF_OP(op)SETFIELD((op), 48, 55)
> > +#define PSERIES_WDTF_OP_START  PSERIES_WDTF_OP(0x1)
> > +#define PSERIES_WDTF_OP_STOP   PSERIES_WDTF_OP(0x2)
> > +#define PSERIES_WDTF_OP_QUERY  PSERIES_WDTF_OP(0x3)
>  
> eg, IMHO these are much more reader friendly:
> 
> #define PSERIES_WDTF_OP_START (1 << 8)
> #define 

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

2022-07-07 Thread Alexey Kardashevskiy




On 7/8/22 01:10, Jason Gunthorpe wrote:

On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:

Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though has added a coherency
capability check to the generic part of VFIO and essentially disabled
VFIO on PPC64; the similar story about iommu_group_dma_owner_claimed().

This adds an iommu_ops stub which reports support for cache
coherency. Because bus_set_iommu() triggers IOMMU probing of PCI devices,
this provides minimum code for the probing to not crash.

Because now we have to set iommu_ops to the system (bus_set_iommu() or
iommu_device_register()), this requires the POWERNV PCI setup to happen
after bus_register(_bus_type) which is postcore_initcall
TODO: check if it still works, read sha1, for more details:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5537fcb319d016ce387

Because setting the ops triggers probing, this does not work well with
iommu_group_add_device(), hence the move to iommu_probe_device().

Because iommu_probe_device() does not take the group (which is why
we had the helper in the first place), this adds
pci_controller_ops::device_group.

So, basically there is one iommu_device per PHB and devices are added to
groups indirectly via series of calls inside the IOMMU code.

pSeries is out of scope here (a minor fix needed for barely supported
platform in regard to VFIO).

The previous discussion is here:
https://patchwork.ozlabs.org/project/kvm-ppc/patch/20220701061751.1955857-1-...@ozlabs.ru/


I think this is basically OK, for what it is. It looks like there is
more some-day opportunity to make use of the core infrastructure though.


does it make sense to have this many callbacks, or
the generic IOMMU code can safely operate without some
(given I add some more checks for !NULL)? thanks,


I wouldn't worry about it..


@@ -1156,7 +1158,10 @@ int iommu_add_device(struct iommu_table_group 
*table_group, struct device *dev)
pr_debug("%s: Adding %s to iommu group %d\n",
 __func__, dev_name(dev),  iommu_group_id(table_group->group));
  
-	return iommu_group_add_device(table_group->group, dev);

+   ret = iommu_probe_device(dev);
+   dev_info(dev, "probed with %d\n", ret);


For another day, but it seems a bit strange to call iommu_probe_device() like 
this?
Shouldn't one of the existing call sites cover this? The one in
of_iommu.c perhaps?



It looks to me that of_iommu.c expects the iommu setup to happen before 
linux starts as linux looks for #iommu-cells or iommu-map properties in 
the device tree. The powernv firmware (aka skiboot) does not do this and 
it is linux which manages iommu groups.




+static bool spapr_tce_iommu_is_attach_deferred(struct device *dev)
+{
+   return false;
+}


I think you can NULL this op:

static bool iommu_is_attach_deferred(struct device *dev)
{
const struct iommu_ops *ops = dev_iommu_ops(dev);

if (ops->is_attach_deferred)
return ops->is_attach_deferred(dev);

return false;
}


+static struct iommu_group *spapr_tce_iommu_device_group(struct device *dev)
+{
+   struct pci_controller *hose;
+   struct pci_dev *pdev;
+
+   /* Weirdly iommu_device_register() assigns the same ops to all buses */
+   if (!dev_is_pci(dev))
+   return ERR_PTR(-EPERM);
+
+   pdev = to_pci_dev(dev);
+   hose = pdev->bus->sysdata;
+
+   if (!hose->controller_ops.device_group)
+   return ERR_PTR(-ENOENT);
+
+   return hose->controller_ops.device_group(hose, pdev);
+}


Is this missing a refcount get on the group?


+
+static int spapr_tce_iommu_attach_dev(struct iommu_domain *dom,
+ struct device *dev)
+{
+   return 0;
+}


It is important when this returns that the iommu translation is all
emptied. There should be no left over translations from the DMA API at
this point. I have no idea how power works in this regard, but it
should be explained why this is safe in a comment at a minimum.


> It will turn into a security problem to allow kernel mappings to leak
> past this point.
>

I've added for v2 checking for no valid mappings for a device (or, more 
precisely, in the associated iommu_group), this domain does not need 
checking, right?


In general, is "domain" something from hardware or it is a software 
concept? Thanks,




Jason


--
Alexey


Re: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0

2022-07-07 Thread Guenter Roeck
undation.org, keyri...@vger.kernel.org, net...@vger.kernel.org, 
k...@vger.kernel.org, da...@lists.linux.dev, linux...@kvack.org, 
accessrunner-gene...@lists.sourceforge.net, 
linux1394-de...@lists.sourceforge.net, linux-l...@vger.kernel.org, 
rds-de...@oss.oracle.com, linux-...@vger.kernel.org, d...@vger.kernel.org, 
intel-wired-...@lists.osuosl.org, linux-ser...@vger.kernel.org, 
devicet...@vger.kernel.org, linux-...@lists.01.org, 
osmocom-net-g...@lists.osmocom.org, appar...@lists.ubuntu.com, 
linux-r...@vger.kernel.org, linux-bca...@vger.kernel.org, 
linux-media...@lists.infradead.org, linux-te...@vger.kernel.org, 
linux-s...@vger.kernel.org, patc...@opensource.cirrus.com, 
linux-unio...@vger.kernel.org, linux-blueto...@vger.kernel.org, 
n...@lists.linux.dev, tipc-discuss...@lists.sourceforge.net, 
linuxppc-dev@lists.ozlabs.org, linux-bt...@vger.kernel.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


On Thu, Jul 07, 2022 at 10:08:33AM +0200, Greg KH wrote:

[ ... ]
> > 
> > Unverified Error/Warning (likely false positive, please contact us if 
> > interested):
> > 
> > arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code 
> > 'err'
> > drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced.
> > drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but 
> > dereferenced.
> > drivers/android/binder.c:353:25-35: ERROR: node -> proc is NULL but 
> > dereferenced.
> > drivers/android/binder.c:4888:16-20: ERROR: t is NULL but dereferenced.
> > drivers/base/regmap/regmap.c:1996:1: internal compiler error: in arc_ifcvt, 
> > at config/arc/arc.c:9637
> > drivers/char/random.c:869:1: internal compiler error: in arc_ifcvt, at 
> > config/arc/arc.c:9637
> > drivers/firmware/arm_scmi/clock.c:394:1: internal compiler error: in 
> > arc_ifcvt, at config/arc/arc.c:9637
> > drivers/firmware/arm_scmi/powercap.c:376:1: internal compiler error: in 
> > arc_ifcvt, at config/arc/arc.c:9637
> > drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_powertune.c:1214:1: 
> > internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637
> > drivers/gpu/drm/amd/display/dc/os_types.h: drm/drm_print.h is included more 
> > than once.
> > drivers/gpu/drm/bridge/ite-it66121.c:1398:1: internal compiler error: in 
> > arc_ifcvt, at config/arc/arc.c:9637
> > drivers/greybus/operation.c:617:1: internal compiler error: in arc_ifcvt, 
> > at config/arc/arc.c:9637
> 
> 
> 
> When the compiler crashes, why are you blaming all of these different
> mailing lists?  Perhaps you need to fix your compiler :)
> 

To be fair, it says above "likely false positive, please contact us
if interested". Also, the 32-bit build errors _are_ real, and the NULL
dereferences in the binder driver are at the very least suspicious.

Guenter


[PATCH v5] random: remove CONFIG_ARCH_RANDOM

2022-07-07 Thread Jason A. Donenfeld
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.

Later the thinking evolved. With a properly designed RNG, using RDRAND
values alone won't harm anything, even if the outputs are malicious.
Rather, the issue is whether those values are being *trusted* to be good
or not. And so a new set of options were introduced as the real
ones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu".
With these options, RDRAND is used, but it's not always credited. So in
the worst case, it does nothing, and in the best case, maybe it helps.

Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into the
center and became something certain platforms force-select.

The old options don't really help with much, and it's a bit odd to have
special handling for these instructions when the kernel can deal fine
with the existence or untrusted existence or broken existence or
non-existence of that CPU capability.

Simplify the situation by removing CONFIG_ARCH_RANDOM and using the
ordinary asm-generic fallback pattern instead, keeping the two options
that are actually used. For now it leaves "nordrand" for now, as the
removal of that will take a different route.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Michael Ellerman 
Cc: Alexander Gordeev 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Acked-by: Borislav Petkov 
Acked-by: Heiko Carstens 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Jason A. Donenfeld 
---
Changes v4->v5:
- Squelch warning on ARCH=um.
- Include asm-generic on arm instead of duplicating code.
Changes v3->v4:
- Use asm-generic for fallback.
Changes v2->v3:
- Keep compiling on archs with no ARCH_RANDOM.
Changes v1->v2:
- Get rid of nordrand change for now.

 arch/arm/include/asm/archrandom.h |  2 ++
 arch/arm64/Kconfig|  8 --
 arch/arm64/include/asm/archrandom.h   | 10 
 arch/arm64/kernel/cpufeature.c|  2 --
 arch/powerpc/Kconfig  |  3 ---
 arch/powerpc/include/asm/archrandom.h |  3 ---
 arch/powerpc/include/asm/machdep.h|  2 --
 arch/powerpc/platforms/microwatt/Kconfig  |  1 -
 arch/powerpc/platforms/powernv/Kconfig|  1 -
 arch/powerpc/platforms/pseries/Kconfig|  1 -
 arch/s390/Kconfig | 15 ---
 arch/s390/configs/zfcpdump_defconfig  |  1 -
 arch/s390/crypto/Makefile |  2 +-
 arch/s390/include/asm/archrandom.h|  3 ---
 arch/x86/Kconfig  |  9 ---
 arch/x86/include/asm/archrandom.h | 14 +++
 arch/x86/kernel/cpu/rdrand.c  |  2 --
 drivers/char/Kconfig  |  1 -
 drivers/char/hw_random/s390-trng.c|  9 ---
 include/asm-generic/Kbuild|  1 +
 include/asm-generic/archrandom.h  | 25 +++
 include/linux/random.h|  9 +--
 .../selftests/wireguard/qemu/kernel.config|  1 -
 23 files changed, 34 insertions(+), 91 deletions(-)
 create mode 100644 include/asm-generic/archrandom.h

diff --git a/arch/arm/include/asm/archrandom.h 
b/arch/arm/include/asm/archrandom.h
index a8e84ca5c2ee..cc4714eb1a75 100644
--- a/arch/arm/include/asm/archrandom.h
+++ b/arch/arm/include/asm/archrandom.h
@@ -7,4 +7,6 @@ static inline bool __init smccc_probe_trng(void)
return false;
 }
 
+#include 
+
 #endif /* _ASM_ARCHRANDOM_H */
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1652a9800ebe..1880f71c2547 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1858,14 +1858,6 @@ config ARM64_E0PD
 
  This option enables E0PD for TTBR1 where available.
 
-config ARCH_RANDOM
-   bool "Enable support for random number generation"
-   default y
-   help
- Random number generation (part of the ARMv8.5 Extensions)
- provides a high bandwidth, cryptographically secure
- hardware random number generator.
-
 config ARM64_AS_HAS_MTE
# Initial support for MTE went in binutils 2.32.0, checked with
# ".arch armv8.5-a+memtag" below. However, this was incomplete
diff --git a/arch/arm64/include/asm/archrandom.h 
b/arch/arm64/include/asm/archrandom.h
index 3a6b6d38c5b8..c3b9fa56af67 100644
--- a/arch/arm64/include/asm/archrandom.h
+++ b/arch/arm64/include/asm/archrandom.h
@@ -2,8 +2,6 @@
 #ifndef _ASM_ARCHRANDOM_H
 #define _ASM_ARCHRANDOM_H
 
-#ifdef CONFIG_ARCH_RANDOM
-
 #include 
 #include 
 #include 
@@ -167,12 +165,4 @@ arch_get_random_seed_long_early(unsigned long *v)
 }
 #define arch_get_random_seed_long_early arch_get_random_seed_long_early
 
-#else /* !CONFIG_ARCH_RANDOM */
-
-static inline bool __init smccc_probe_trng(void)
-{
-   return false;
-}
-
-#endif /* CONFIG_ARCH_RANDOM 

Re: [PATCH v2 3/4] powerpc: Remove asm/prom.h from asm/mpc52xx.h and asm/pci.h

2022-07-07 Thread kernel test robot
Hi Christophe,

I love your patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on mkp-scsi/for-next jejb-scsi/for-next linus/master 
v5.19-rc5 next-20220707]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we 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/Christophe-Leroy/video-fbdev-offb-Include-missing-linux-platform_device-h/20220707-222906
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-mpc8313_rdb_defconfig 
(https://download.01.org/0day-ci/archive/20220708/202207080653.rru2i2nn-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
66ae1d60bb278793fd651cece264699d522bab84)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://github.com/intel-lab-lkp/linux/commit/0e553b9abdcfd7c1f63b072e9d9280ce759c0c3c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Christophe-Leroy/video-fbdev-offb-Include-missing-linux-platform_device-h/20220707-222906
git checkout 0e553b9abdcfd7c1f63b072e9d9280ce759c0c3c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=powerpc SHELL=/bin/bash

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> arch/powerpc/kernel/prom.c:891:5: error: no previous prototype for function 
>> 'of_get_ibm_chip_id' [-Werror,-Wmissing-prototypes]
   int of_get_ibm_chip_id(struct device_node *np)
   ^
   arch/powerpc/kernel/prom.c:891:1: note: declare 'static' if the function is 
not intended to be used outside of this translation unit
   int of_get_ibm_chip_id(struct device_node *np)
   ^
   static 
   1 error generated.


vim +/of_get_ibm_chip_id +891 arch/powerpc/kernel/prom.c

b27652dd2174df1 Kevin Hao  2013-12-24  871  
9b6b563c0d2d25e Paul Mackerras 2005-10-06  872  /***
9b6b563c0d2d25e Paul Mackerras 2005-10-06  873   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  874   * New implementation 
of the OF "find" APIs, return a refcounted
9b6b563c0d2d25e Paul Mackerras 2005-10-06  875   * object, call 
of_node_put() when done.  The device tree and list
9b6b563c0d2d25e Paul Mackerras 2005-10-06  876   * are protected by a 
rw_lock.
9b6b563c0d2d25e Paul Mackerras 2005-10-06  877   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  878   * Note that property 
management will need some locking as well,
9b6b563c0d2d25e Paul Mackerras 2005-10-06  879   * this isn't dealt 
with yet.
9b6b563c0d2d25e Paul Mackerras 2005-10-06  880   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  881   ***/
9b6b563c0d2d25e Paul Mackerras 2005-10-06  882  
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  883  /**
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  884   * of_get_ibm_chip_id - 
Returns the IBM "chip-id" of a device
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  885   * @np: device node of 
the device
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  886   *
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  887   * This looks for a 
property "ibm,chip-id" in the node or any
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  888   * of its parents and 
returns its content, or -1 if it cannot
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  889   * be found.
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  890   */
b37193b71846858 Benjamin Herrenschmidt 2013-07-15 @891  int 
of_get_ibm_chip_id(struct device_node *np)
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  892  {
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  893  of_node_get(np);
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  894  while (np) {
1856f50c66dff0a Christophe Jaillet 2015-10-16  895  u32 
chip_id;
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  896  
1856f50c66dff0a Christophe Jaillet 2015-10-16  897  /*
1856f50c66dff0a Christophe Jaillet 2015-10-16  898   * 
Skiboot may produce memory nodes that contain more than one
1856f50c66dff0a Christophe Jaillet 2015-10-16  899   * cell 
in chip-id, we only read the first one here.
1856f50c66dff0a Christophe Jaillet 2015-10-16  900   */
1856f50c66dff0a Christophe Jaillet 2015-1

Re: [PATCH v2 3/4] powerpc: Remove asm/prom.h from asm/mpc52xx.h and asm/pci.h

2022-07-07 Thread kernel test robot
Hi Christophe,

I love your patch! Perhaps something to improve:

[auto build test WARNING on powerpc/next]
[also build test WARNING on mkp-scsi/for-next jejb-scsi/for-next linus/master 
v5.19-rc5 next-20220707]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we 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/Christophe-Leroy/video-fbdev-offb-Include-missing-linux-platform_device-h/20220707-222906
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-microwatt_defconfig 
(https://download.01.org/0day-ci/archive/20220708/202207080622.vqn3z1bl-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
66ae1d60bb278793fd651cece264699d522bab84)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://github.com/intel-lab-lkp/linux/commit/0e553b9abdcfd7c1f63b072e9d9280ce759c0c3c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Christophe-Leroy/video-fbdev-offb-Include-missing-linux-platform_device-h/20220707-222906
git checkout 0e553b9abdcfd7c1f63b072e9d9280ce759c0c3c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=powerpc SHELL=/bin/bash arch/powerpc/kernel/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> arch/powerpc/kernel/prom.c:891:5: warning: no previous prototype for 
>> function 'of_get_ibm_chip_id' [-Wmissing-prototypes]
   int of_get_ibm_chip_id(struct device_node *np)
   ^
   arch/powerpc/kernel/prom.c:891:1: note: declare 'static' if the function is 
not intended to be used outside of this translation unit
   int of_get_ibm_chip_id(struct device_node *np)
   ^
   static 
   1 warning generated.


vim +/of_get_ibm_chip_id +891 arch/powerpc/kernel/prom.c

b27652dd2174df1 Kevin Hao  2013-12-24  871  
9b6b563c0d2d25e Paul Mackerras 2005-10-06  872  /***
9b6b563c0d2d25e Paul Mackerras 2005-10-06  873   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  874   * New implementation 
of the OF "find" APIs, return a refcounted
9b6b563c0d2d25e Paul Mackerras 2005-10-06  875   * object, call 
of_node_put() when done.  The device tree and list
9b6b563c0d2d25e Paul Mackerras 2005-10-06  876   * are protected by a 
rw_lock.
9b6b563c0d2d25e Paul Mackerras 2005-10-06  877   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  878   * Note that property 
management will need some locking as well,
9b6b563c0d2d25e Paul Mackerras 2005-10-06  879   * this isn't dealt 
with yet.
9b6b563c0d2d25e Paul Mackerras 2005-10-06  880   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  881   ***/
9b6b563c0d2d25e Paul Mackerras 2005-10-06  882  
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  883  /**
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  884   * of_get_ibm_chip_id - 
Returns the IBM "chip-id" of a device
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  885   * @np: device node of 
the device
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  886   *
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  887   * This looks for a 
property "ibm,chip-id" in the node or any
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  888   * of its parents and 
returns its content, or -1 if it cannot
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  889   * be found.
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  890   */
b37193b71846858 Benjamin Herrenschmidt 2013-07-15 @891  int 
of_get_ibm_chip_id(struct device_node *np)
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  892  {
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  893  of_node_get(np);
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  894  while (np) {
1856f50c66dff0a Christophe Jaillet 2015-10-16  895  u32 
chip_id;
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  896  
1856f50c66dff0a Christophe Jaillet 2015-10-16  897  /*
1856f50c66dff0a Christophe Jaillet 2015-10-16  898   * 
Skiboot may produce memory nodes that contain more than one
1856f50c66dff0a Christophe Jaillet 2015-10-16  899   * cell 
in chip-id, we only read the first one here.
1856f50c66dff0a Christophe Jaillet 2015-10-16  900   *

Re: [PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-07-07 Thread Martin K. Petersen
On Fri, 24 Jun 2022 17:52:23 +0200, Arnd Bergmann wrote:

> From: Arnd Bergmann 
> 
> The virt_to_bus/bus_to_virt interface has been deprecated for
> decades. After Jakub Kicinski put a lot of work into cleaning out the
> network drivers using them, there are only a couple of other drivers
> left, which can all be removed or otherwise cleaned up, to remove the
> old interface for good.
> 
> [...]

Applied to 5.20/scsi-queue, thanks!

[1/3] scsi: BusLogic remove bus_to_virt
  https://git.kernel.org/mkp/scsi/c/9f7c2232e131
[2/3] scsi: dpt_i2o: remove obsolete driver
  https://git.kernel.org/mkp/scsi/c/b04e75a4a8a8

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v2 3/4] powerpc: Remove asm/prom.h from asm/mpc52xx.h and asm/pci.h

2022-07-07 Thread kernel test robot
Hi Christophe,

I love your patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on mkp-scsi/for-next jejb-scsi/for-next linus/master 
v5.19-rc5 next-20220707]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we 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/Christophe-Leroy/video-fbdev-offb-Include-missing-linux-platform_device-h/20220707-222906
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allnoconfig 
(https://download.01.org/0day-ci/archive/20220708/202207080212.nbriiauw-...@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/0e553b9abdcfd7c1f63b072e9d9280ce759c0c3c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Christophe-Leroy/video-fbdev-offb-Include-missing-linux-platform_device-h/20220707-222906
git checkout 0e553b9abdcfd7c1f63b072e9d9280ce759c0c3c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 
O=build_dir ARCH=powerpc SHELL=/bin/bash arch/powerpc/kernel/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> arch/powerpc/kernel/prom.c:891:5: error: no previous prototype for 
>> 'of_get_ibm_chip_id' [-Werror=missing-prototypes]
 891 | int of_get_ibm_chip_id(struct device_node *np)
 | ^~
   cc1: all warnings being treated as errors


vim +/of_get_ibm_chip_id +891 arch/powerpc/kernel/prom.c

b27652dd2174df1 Kevin Hao  2013-12-24  871  
9b6b563c0d2d25e Paul Mackerras 2005-10-06  872  /***
9b6b563c0d2d25e Paul Mackerras 2005-10-06  873   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  874   * New implementation 
of the OF "find" APIs, return a refcounted
9b6b563c0d2d25e Paul Mackerras 2005-10-06  875   * object, call 
of_node_put() when done.  The device tree and list
9b6b563c0d2d25e Paul Mackerras 2005-10-06  876   * are protected by a 
rw_lock.
9b6b563c0d2d25e Paul Mackerras 2005-10-06  877   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  878   * Note that property 
management will need some locking as well,
9b6b563c0d2d25e Paul Mackerras 2005-10-06  879   * this isn't dealt 
with yet.
9b6b563c0d2d25e Paul Mackerras 2005-10-06  880   *
9b6b563c0d2d25e Paul Mackerras 2005-10-06  881   ***/
9b6b563c0d2d25e Paul Mackerras 2005-10-06  882  
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  883  /**
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  884   * of_get_ibm_chip_id - 
Returns the IBM "chip-id" of a device
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  885   * @np: device node of 
the device
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  886   *
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  887   * This looks for a 
property "ibm,chip-id" in the node or any
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  888   * of its parents and 
returns its content, or -1 if it cannot
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  889   * be found.
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  890   */
b37193b71846858 Benjamin Herrenschmidt 2013-07-15 @891  int 
of_get_ibm_chip_id(struct device_node *np)
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  892  {
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  893  of_node_get(np);
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  894  while (np) {
1856f50c66dff0a Christophe Jaillet 2015-10-16  895  u32 
chip_id;
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  896  
1856f50c66dff0a Christophe Jaillet 2015-10-16  897  /*
1856f50c66dff0a Christophe Jaillet 2015-10-16  898   * 
Skiboot may produce memory nodes that contain more than one
1856f50c66dff0a Christophe Jaillet 2015-10-16  899   * cell 
in chip-id, we only read the first one here.
1856f50c66dff0a Christophe Jaillet 2015-10-16  900   */
1856f50c66dff0a Christophe Jaillet 2015-10-16  901  if 
(!of_property_read_u32(np, "ibm,chip-id", _id)) {
b37193b71846858 Benjamin Herrenschmidt 2013-07-15  902  
of_node_put(np);
1856f50c66dff0a Christophe Jaillet 2015-10-16  903  
return chip_id;
b37193b71846858 Benjamin Herrenschmidt 2

[PATCH v6 5/6] of: kexec: Refactor IMA buffer related functions to make them reusable

2022-07-07 Thread Stefan Berger
Refactor IMA buffer related functions to make them reusable for carrying
TPM logs across kexec.

Signed-off-by: Stefan Berger 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Mimi Zohar 

---
v6:
 - Add __init to get_kexec_buffer as suggested by Jonathan

v5:
 - Rebased on Jonathan McDowell's commit "b69a2afd5afc x86/kexec: Carry
   forward IMA measurement log on kexec"
v4:
 - Move debug output into setup_buffer()
---
 drivers/of/kexec.c | 126 ++---
 1 file changed, 74 insertions(+), 52 deletions(-)

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 548dd5b1b5c1..15a82b574f36 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -117,45 +117,57 @@ static int do_get_kexec_buffer(const void *prop, int len, 
unsigned long *addr,
 }
 
 #ifdef CONFIG_HAVE_IMA_KEXEC
-/**
- * ima_get_kexec_buffer - get IMA buffer from the previous kernel
- * @addr:  On successful return, set to point to the buffer contents.
- * @size:  On successful return, set to the buffer size.
- *
- * Return: 0 on success, negative errno on error.
- */
-int __init ima_get_kexec_buffer(void **addr, size_t *size)
+static int __init get_kexec_buffer(const char *name, unsigned long *addr,
+  size_t *size)
 {
int ret, len;
-   unsigned long tmp_addr;
unsigned long start_pfn, end_pfn;
-   size_t tmp_size;
const void *prop;
 
-   prop = of_get_property(of_chosen, "linux,ima-kexec-buffer", );
+   prop = of_get_property(of_chosen, name, );
if (!prop)
return -ENOENT;
 
-   ret = do_get_kexec_buffer(prop, len, _addr, _size);
+   ret = do_get_kexec_buffer(prop, len, addr, size);
if (ret)
return ret;
 
-   /* Do some sanity on the returned size for the ima-kexec buffer */
-   if (!tmp_size)
+   /* Do some sanity on the returned size for the kexec buffer */
+   if (!*size)
return -ENOENT;
 
/*
 * Calculate the PFNs for the buffer and ensure
 * they are with in addressable memory.
 */
-   start_pfn = PHYS_PFN(tmp_addr);
-   end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1);
+   start_pfn = PHYS_PFN(*addr);
+   end_pfn = PHYS_PFN(*addr + *size - 1);
if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) {
-   pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond memory\n",
-   tmp_addr, tmp_size);
+   pr_warn("%s buffer at 0x%lx, size = 0x%zx beyond memory\n",
+   name, *addr, *size);
return -EINVAL;
}
 
+   return 0;
+}
+
+/**
+ * ima_get_kexec_buffer - get IMA buffer from the previous kernel
+ * @addr:  On successful return, set to point to the buffer contents.
+ * @size:  On successful return, set to the buffer size.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int __init ima_get_kexec_buffer(void **addr, size_t *size)
+{
+   int ret;
+   unsigned long tmp_addr;
+   size_t tmp_size;
+
+   ret = get_kexec_buffer("linux,ima-kexec-buffer", _addr, _size);
+   if (ret)
+   return ret;
+
*addr = __va(tmp_addr);
*size = tmp_size;
 
@@ -188,72 +200,82 @@ int __init ima_free_kexec_buffer(void)
 }
 #endif
 
-/**
- * remove_ima_buffer - remove the IMA buffer property and reservation from @fdt
- *
- * @fdt: Flattened Device Tree to update
- * @chosen_node: Offset to the chosen node in the device tree
- *
- * The IMA measurement buffer is of no use to a subsequent kernel, so we always
- * remove it from the device tree.
- */
-static void remove_ima_buffer(void *fdt, int chosen_node)
+static int remove_buffer(void *fdt, int chosen_node, const char *name)
 {
int ret, len;
unsigned long addr;
size_t size;
const void *prop;
 
-   if (!IS_ENABLED(CONFIG_HAVE_IMA_KEXEC))
-   return;
-
-   prop = fdt_getprop(fdt, chosen_node, "linux,ima-kexec-buffer", );
+   prop = fdt_getprop(fdt, chosen_node, name, );
if (!prop)
-   return;
+   return -ENOENT;
 
ret = do_get_kexec_buffer(prop, len, , );
-   fdt_delprop(fdt, chosen_node, "linux,ima-kexec-buffer");
+   fdt_delprop(fdt, chosen_node, name);
if (ret)
-   return;
+   return ret;
 
ret = fdt_find_and_del_mem_rsv(fdt, addr, size);
if (!ret)
-   pr_debug("Removed old IMA buffer reservation.\n");
+   pr_debug("Remove old %s buffer reserveration", name);
+   return ret;
 }
 
-#ifdef CONFIG_IMA_KEXEC
 /**
- * setup_ima_buffer - add IMA buffer information to the fdt
- * @image: kexec image being loaded.
- * @fdt:   Flattened device tree for the next kernel.
- * @chosen_node:   Offset to the chosen node.
+ * remove_ima_buffer - remove the IMA buffer property and reservation from @fdt
  *
- * Return: 0 on success, or 

[PATCH v6 1/6] of: check previous kernel's ima-kexec-buffer against memory bounds

2022-07-07 Thread Stefan Berger
From: Vaibhav Jain 

Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:

$ sudo kexec --initrd initrd vmlinux --append='mem=16G'


 BUG: Unable to handle kernel data access on read at 0xc000c01fff7f
 Faulting instruction address: 0xc0837974
 Oops: Kernel access of bad area, sig: 11 [#1]

 NIP [c0837974] ima_restore_measurement_list+0x94/0x6c0
 LR [c083b55c] ima_load_kexec_buffer+0xac/0x160
 Call Trace:
 [c371fa80] [c083b55c] ima_load_kexec_buffer+0xac/0x160
 [c371fb00] [c20512c4] ima_init+0x80/0x108
 [c371fb70] [c20514dc] init_ima+0x4c/0x120
 [c371fbf0] [c0012240] do_one_initcall+0x60/0x2c0
 [c371fcc0] [c2004ad0] kernel_init_freeable+0x344/0x3ec
 [c371fda0] [c00128a4] kernel_init+0x34/0x1b0
 [c371fe10] [c000ce64] ret_from_kernel_thread+0x5c/0x64
 Instruction dump:
 f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc0 40810330
 7c0802a6 fb610198 7c9b2378 f80101d0  2c090001 40820614 e9240010
 ---[ end trace  ]---

Fix this issue by checking returned PFN range of previous kernel's
ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.

Fixes: 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous 
kernel")
Cc: Frank Rowand 
Cc: Prakhar Srivastava 
Cc: Lakshmi Ramasubramanian 
Cc: Thiago Jung Bauermann 
Cc: Rob Herring 
Cc: Ritesh Harjani 
Cc: Robin Murphy 
Signed-off-by: Vaibhav Jain 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220531041446.3334259-1-vaib...@linux.ibm.com
---
 drivers/of/kexec.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 8d374cc552be..91b04b04eec4 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -126,6 +126,7 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
 {
int ret, len;
unsigned long tmp_addr;
+   unsigned long start_pfn, end_pfn;
size_t tmp_size;
const void *prop;
 
@@ -140,6 +141,22 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
if (ret)
return ret;
 
+   /* Do some sanity on the returned size for the ima-kexec buffer */
+   if (!tmp_size)
+   return -ENOENT;
+
+   /*
+* Calculate the PFNs for the buffer and ensure
+* they are with in addressable memory.
+*/
+   start_pfn = PHYS_PFN(tmp_addr);
+   end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1);
+   if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) {
+   pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond memory\n",
+   tmp_addr, tmp_size);
+   return -EINVAL;
+   }
+
*addr = __va(tmp_addr);
*size = tmp_size;
 
-- 
2.35.1



[PATCH v6 6/6] tpm/kexec: Duplicate TPM measurement log in of-tree for kexec

2022-07-07 Thread Stefan Berger
The memory area of the TPM measurement log is currently not properly
duplicated for carrying it across kexec when an Open Firmware
Devicetree is used. Therefore, the contents of the log get corrupted.
Fix this for the kexec_file_load() syscall by allocating a buffer and
copying the contents of the existing log into it. The new buffer is
preserved across the kexec and a pointer to it is available when the new
kernel is started. To achieve this, store the allocated buffer's address
in the flattened device tree (fdt) under the name linux,tpm-kexec-buffer
and search for this entry early in the kernel startup before the TPM
subsystem starts up. Adjust the pointer in the of-tree stored under
linux,sml-base to point to this buffer holding the preserved log. The TPM
driver can then read the base address from this entry when making the log
available. Invalidate the log by removing 'linux,sml-base' from the
devicetree if anything goes wrong with updating the buffer.

Use subsys_initcall() to call the function to restore the buffer even if
the TPM subsystem or driver are not used. This allows the buffer to be
carried across the next kexec without involvement of the TPM subsystem
and ensures a valid buffer pointed to by the of-tree.

Use the subsys_initcall(), rather than an ealier initcall, since
page_is_ram() in get_kexec_buffer() only starts working at this stage.

Signed-off-by: Stefan Berger 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Eric Biederman 

---
v6:
 - Define prototype for tpm_add_kexec_buffer under same config options
   as drivers/of/kexec.c is compiled, provide inline function otherwise.
   (kernel test robot)

v4:
 - Added #include  due to parisc
 - Use phys_addr_t for physical address rather than void *
 - Remove linux,sml-base if the buffer cannot be updated after a kexec
 - Added __init to functions where possible
---
 drivers/of/kexec.c| 216 +-
 include/linux/kexec.h |   6 ++
 include/linux/of.h|   9 +-
 kernel/kexec_file.c   |   6 ++
 4 files changed, 234 insertions(+), 3 deletions(-)

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 15a82b574f36..dd926e057215 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define RNG_SEED_SIZE  128
 
@@ -116,7 +118,6 @@ static int do_get_kexec_buffer(const void *prop, int len, 
unsigned long *addr,
return 0;
 }
 
-#ifdef CONFIG_HAVE_IMA_KEXEC
 static int __init get_kexec_buffer(const char *name, unsigned long *addr,
   size_t *size)
 {
@@ -151,6 +152,7 @@ static int __init get_kexec_buffer(const char *name, 
unsigned long *addr,
return 0;
 }
 
+#ifdef CONFIG_HAVE_IMA_KEXEC
 /**
  * ima_get_kexec_buffer - get IMA buffer from the previous kernel
  * @addr:  On successful return, set to point to the buffer contents.
@@ -239,7 +241,6 @@ static void remove_ima_buffer(void *fdt, int chosen_node)
remove_buffer(fdt, chosen_node, "linux,ima-kexec-buffer");
 }
 
-#ifdef CONFIG_IMA_KEXEC
 static int setup_buffer(void *fdt, int chosen_node, const char *name,
phys_addr_t addr, size_t size)
 {
@@ -263,6 +264,7 @@ static int setup_buffer(void *fdt, int chosen_node, const 
char *name,
 
 }
 
+#ifdef CONFIG_IMA_KEXEC
 /**
  * setup_ima_buffer - add IMA buffer information to the fdt
  * @image: kexec image being loaded.
@@ -285,6 +287,213 @@ static inline int setup_ima_buffer(const struct kimage 
*image, void *fdt,
 }
 #endif /* CONFIG_IMA_KEXEC */
 
+/**
+ * tpm_get_kexec_buffer - get TPM log buffer from the previous kernel
+ * @phyaddr:   On successful return, set to physical address of buffer
+ * @size:  On successful return, set to the buffer size.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+static int __init tpm_get_kexec_buffer(phys_addr_t *phyaddr, size_t *size)
+{
+   unsigned long tmp_addr;
+   size_t tmp_size;
+   int ret;
+
+   ret = get_kexec_buffer("linux,tpm-kexec-buffer", _addr, _size);
+   if (ret)
+   return ret;
+
+   *phyaddr = (phys_addr_t)tmp_addr;
+   *size = tmp_size;
+
+   return 0;
+}
+
+/**
+ * tpm_of_remove_kexec_buffer - remove the linux,tpm-kexec-buffer node
+ */
+static int __init tpm_of_remove_kexec_buffer(void)
+{
+   struct property *prop;
+
+   prop = of_find_property(of_chosen, "linux,tpm-kexec-buffer", NULL);
+   if (!prop)
+   return -ENOENT;
+
+   return of_remove_property(of_chosen, prop);
+}
+
+/**
+ * remove_tpm_buffer - remove the TPM log buffer property and reservation from 
@fdt
+ *
+ * @fdt: Flattened Device Tree to update
+ * @chosen_node: Offset to the chosen node in the device tree
+ *
+ * The TPM log measurement buffer is of no use to a subsequent kernel, so we 
always
+ * remove it from the device tree.
+ */
+static void remove_tpm_buffer(void *fdt, int chosen_node)
+{
+   if 

[PATCH v6 4/6] tpm: of: Make of-tree specific function commonly available

2022-07-07 Thread Stefan Berger
Simplify tpm_read_log_of() by moving reusable parts of the code into
an inline function that makes it commonly available so it can be
used also for kexec support. Call the new of_tpm_get_sml_parameters()
function from the TPM Open Firmware driver.

Signed-off-by: Stefan Berger 
Cc: Jarkko Sakkinen 
Cc: Jason Gunthorpe 
Cc: Rob Herring 
Cc: Frank Rowand 

---
v4:
 - converted to inline function
---
 drivers/char/tpm/eventlog/of.c | 31 +--
 include/linux/tpm.h| 27 +++
 2 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/drivers/char/tpm/eventlog/of.c b/drivers/char/tpm/eventlog/of.c
index a9ce66d09a75..f9462d19632e 100644
--- a/drivers/char/tpm/eventlog/of.c
+++ b/drivers/char/tpm/eventlog/of.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "../tpm.h"
@@ -20,11 +21,10 @@
 int tpm_read_log_of(struct tpm_chip *chip)
 {
struct device_node *np;
-   const u32 *sizep;
-   const u64 *basep;
struct tpm_bios_log *log;
u32 size;
u64 base;
+   int ret;
 
log = >log;
if (chip->dev.parent && chip->dev.parent->of_node)
@@ -35,30 +35,9 @@ int tpm_read_log_of(struct tpm_chip *chip)
if (of_property_read_bool(np, "powered-while-suspended"))
chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
 
-   sizep = of_get_property(np, "linux,sml-size", NULL);
-   basep = of_get_property(np, "linux,sml-base", NULL);
-   if (sizep == NULL && basep == NULL)
-   return -ENODEV;
-   if (sizep == NULL || basep == NULL)
-   return -EIO;
-
-   /*
-* For both vtpm/tpm, firmware has log addr and log size in big
-* endian format. But in case of vtpm, there is a method called
-* sml-handover which is run during kernel init even before
-* device tree is setup. This sml-handover function takes care
-* of endianness and writes to sml-base and sml-size in little
-* endian format. For this reason, vtpm doesn't need conversion
-* but physical tpm needs the conversion.
-*/
-   if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
-   of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
-   size = be32_to_cpup((__force __be32 *)sizep);
-   base = be64_to_cpup((__force __be64 *)basep);
-   } else {
-   size = *sizep;
-   base = *basep;
-   }
+   ret = of_tpm_get_sml_parameters(np, , );
+   if (ret < 0)
+   return ret;
 
if (size == 0) {
dev_warn(>dev, "%s: Event log area empty\n", __func__);
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index dfeb25a0362d..b3dff255bc58 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -460,4 +460,31 @@ static inline struct tpm_chip *tpm_default_chip(void)
return NULL;
 }
 #endif
+
+#ifdef CONFIG_OF
+static inline int of_tpm_get_sml_parameters(struct device_node *np,
+   u64 *base, u32 *size)
+{
+   const u32 *sizep;
+   const u64 *basep;
+
+   sizep = of_get_property(np, "linux,sml-size", NULL);
+   basep = of_get_property(np, "linux,sml-base", NULL);
+   if (sizep == NULL && basep == NULL)
+   return -ENODEV;
+   if (sizep == NULL || basep == NULL)
+   return -EIO;
+
+   if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
+   of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
+   *size = be32_to_cpup((__force __be32 *)sizep);
+   *base = be64_to_cpup((__force __be64 *)basep);
+   } else {
+   *size = *sizep;
+   *base = *basep;
+   }
+   return 0;
+}
+#endif
+
 #endif
-- 
2.35.1



[PATCH v6 3/6] x86/kexec: Carry forward IMA measurement log on kexec

2022-07-07 Thread Stefan Berger
From: Jonathan McDowell 

On kexec file load, the Integrity Measurement Architecture (IMA)
subsystem may verify the IMA signature of the kernel and initramfs, and
measure it. The command line parameters passed to the kernel in the
kexec call may also be measured by IMA.

A remote attestation service can verify a TPM quote based on the TPM
event log, the IMA measurement list and the TPM PCR data. This can
be achieved only if the IMA measurement log is carried over from the
current kernel to the next kernel across the kexec call.

PowerPC and ARM64 both achieve this using device tree with a
"linux,ima-kexec-buffer" node. x86 platforms generally don't make use of
device tree, so use the setup_data mechanism to pass the IMA buffer to
the new kernel.

Signed-off-by: Jonathan McDowell 
Signed-off-by: Borislav Petkov 
Reviewed-by: Mimi Zohar  # IMA function definitions
Link: https://lore.kernel.org/r/YmKyvlF3my1yWTvK@noodles-fedora-PC23Y6EG
---
 arch/x86/Kconfig  |  1 +
 arch/x86/include/uapi/asm/bootparam.h |  9 
 arch/x86/kernel/e820.c|  6 +--
 arch/x86/kernel/kexec-bzimage64.c | 42 +-
 arch/x86/kernel/setup.c   | 63 +++
 drivers/of/kexec.c| 13 +++---
 include/linux/ima.h   |  5 +++
 include/linux/of.h|  2 -
 security/integrity/ima/ima_kexec.c|  2 +-
 9 files changed, 127 insertions(+), 16 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index be0b95e51df6..670e0edc074f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2033,6 +2033,7 @@ config KEXEC_FILE
bool "kexec file based system call"
select KEXEC_CORE
select BUILD_BIN2C
+   select HAVE_IMA_KEXEC if IMA
depends on X86_64
depends on CRYPTO=y
depends on CRYPTO_SHA256=y
diff --git a/arch/x86/include/uapi/asm/bootparam.h 
b/arch/x86/include/uapi/asm/bootparam.h
index bea5cdcdf532..ca0796ac4403 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -11,6 +11,7 @@
 #define SETUP_APPLE_PROPERTIES 5
 #define SETUP_JAILHOUSE6
 #define SETUP_CC_BLOB  7
+#define SETUP_IMA  8
 
 #define SETUP_INDIRECT (1<<31)
 
@@ -172,6 +173,14 @@ struct jailhouse_setup_data {
} __attribute__((packed)) v2;
 } __attribute__((packed));
 
+/*
+ * IMA buffer setup data information from the previous kernel during kexec
+ */
+struct ima_setup_data {
+   __u64 addr;
+   __u64 size;
+} __attribute__((packed));
+
 /* The so-called "zeropage" */
 struct boot_params {
struct screen_info screen_info; /* 0x000 */
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index f267205f2d5a..9dac24680ff8 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1017,10 +1017,10 @@ void __init e820__reserve_setup_data(void)
e820__range_update(pa_data, sizeof(*data)+data->len, 
E820_TYPE_RAM, E820_TYPE_RESERVED_KERN);
 
/*
-* SETUP_EFI is supplied by kexec and does not need to be
-* reserved.
+* SETUP_EFI and SETUP_IMA are supplied by kexec and do not need
+* to be reserved.
 */
-   if (data->type != SETUP_EFI)
+   if (data->type != SETUP_EFI && data->type != SETUP_IMA)
e820__range_update_kexec(pa_data,
 sizeof(*data) + data->len,
 E820_TYPE_RAM, 
E820_TYPE_RESERVED_KERN);
diff --git a/arch/x86/kernel/kexec-bzimage64.c 
b/arch/x86/kernel/kexec-bzimage64.c
index 170d0fd68b1f..c63974e94272 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -186,11 +186,38 @@ setup_efi_state(struct boot_params *params, unsigned long 
params_load_addr,
 }
 #endif /* CONFIG_EFI */
 
+static void
+setup_ima_state(const struct kimage *image, struct boot_params *params,
+   unsigned long params_load_addr,
+   unsigned int ima_setup_data_offset)
+{
+#ifdef CONFIG_IMA_KEXEC
+   struct setup_data *sd = (void *)params + ima_setup_data_offset;
+   unsigned long setup_data_phys;
+   struct ima_setup_data *ima;
+
+   if (!image->ima_buffer_size)
+   return;
+
+   sd->type = SETUP_IMA;
+   sd->len = sizeof(*ima);
+
+   ima = (void *)sd + sizeof(struct setup_data);
+   ima->addr = image->ima_buffer_addr;
+   ima->size = image->ima_buffer_size;
+
+   /* Add setup data */
+   setup_data_phys = params_load_addr + ima_setup_data_offset;
+   sd->next = params->hdr.setup_data;
+   params->hdr.setup_data = setup_data_phys;
+#endif /* CONFIG_IMA_KEXEC */
+}
+
 static int
 setup_boot_parameters(struct kimage *image, struct boot_params *params,
 

[PATCH v6 2/6] drivers: of: kexec ima: Support 32-bit platforms

2022-07-07 Thread Stefan Berger
From: Palmer Dabbelt 

RISC-V recently added kexec_file() support, which uses enables kexec
IMA.  We're the first 32-bit platform to support this, so we found a
build bug.

Acked-by: Rob Herring 
Signed-off-by: Palmer Dabbelt 
Reviewed-by: Mimi Zohar 
---
 drivers/of/kexec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 91b04b04eec4..c4f9b6655a2e 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -253,8 +253,8 @@ static int setup_ima_buffer(const struct kimage *image, 
void *fdt,
if (ret)
return -EINVAL;
 
-   pr_debug("IMA buffer at 0x%llx, size = 0x%zx\n",
-image->ima_buffer_addr, image->ima_buffer_size);
+   pr_debug("IMA buffer at 0x%pa, size = 0x%zx\n",
+>ima_buffer_addr, image->ima_buffer_size);
 
return 0;
 }
-- 
2.35.1



[PATCH v6 0/6] tpm: Preserve TPM measurement log across kexec (ppc64)

2022-07-07 Thread Stefan Berger
The of-tree subsystem does not currently preserve the IBM vTPM 1.2 and
vTPM 2.0 measurement logs across a kexec on PowerVM and PowerKVM. This
series fixes this for the kexec_file_load() syscall using the flattened
device tree (fdt) to carry the TPM measurement log's buffer across kexec.

   Stefan

v6:
 - Add __init to get_kexec_buffer as suggested by Jonathan
 - Fixed issue detected by kernel test robot

v5:
 - Rebased on 1 more patch that would otherwise create merge conflicts

v4:
 - Rebased on 2 patches that would otherwise create merge conflicts;
   posting these patches in this series with several tags removed so
   krobot can test the series already
 - Changes to individual patches documented in patch descripitons

v3:
 - Moved TPM Open Firmware related function to 
drivers/char/tpm/eventlog/tpm_of.c

v2:
 - rearranged patches
 - fixed compilation issues for x86


Jonathan McDowell (1):
  x86/kexec: Carry forward IMA measurement log on kexec

Palmer Dabbelt (1):
  drivers: of: kexec ima: Support 32-bit platforms

Stefan Berger (3):
  tpm: of: Make of-tree specific function commonly available
  of: kexec: Refactor IMA buffer related functions to make them reusable
  tpm/kexec: Duplicate TPM measurement log in of-tree for kexec

Vaibhav Jain (1):
  of: check previous kernel's ima-kexec-buffer against memory bounds

 arch/x86/Kconfig  |   1 +
 arch/x86/include/uapi/asm/bootparam.h |   9 +
 arch/x86/kernel/e820.c|   6 +-
 arch/x86/kernel/kexec-bzimage64.c |  42 +++-
 arch/x86/kernel/setup.c   |  63 +
 drivers/char/tpm/eventlog/of.c|  31 +--
 drivers/of/kexec.c| 342 ++
 include/linux/ima.h   |   5 +
 include/linux/kexec.h |   6 +
 include/linux/of.h|  11 +-
 include/linux/tpm.h   |  27 ++
 kernel/kexec_file.c   |   6 +
 security/integrity/ima/ima_kexec.c|   2 +-
 13 files changed, 469 insertions(+), 82 deletions(-)


base-commit: 88084a3df1672e131ddc1b4e39eeacfd39864acf
-- 
2.35.1



Re: [PATCH v5 5/6] of: kexec: Refactor IMA buffer related functions to make them reusable

2022-07-07 Thread Stefan Berger




On 7/7/22 10:47, Jonathan McDowell wrote:

On Wed, Jul 06, 2022 at 11:23:28AM -0400, Stefan Berger wrote:

Refactor IMA buffer related functions to make them reusable for carrying
TPM logs across kexec.

Signed-off-by: Stefan Berger 
Cc: Rob Herring 
Cc: Frank Rowand 
Cc: Mimi Zohar 

---
v5:
  - Rebased on Jonathan McDowell's commit "b69a2afd5afc x86/kexec: Carry
forward IMA measurement log on kexec"
v4:
  - Move debug output into setup_buffer()
---
  drivers/of/kexec.c | 125 ++---
  1 file changed, 73 insertions(+), 52 deletions(-)

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 548dd5b1b5c1..404a86bb3978 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -117,45 +117,56 @@ static int do_get_kexec_buffer(const void *prop, int len, 
unsigned long *addr,
  }
  
  #ifdef CONFIG_HAVE_IMA_KEXEC

-/**
- * ima_get_kexec_buffer - get IMA buffer from the previous kernel
- * @addr:  On successful return, set to point to the buffer contents.
- * @size:  On successful return, set to the buffer size.
- *
- * Return: 0 on success, negative errno on error.
- */
-int __init ima_get_kexec_buffer(void **addr, size_t *size)
+static int get_kexec_buffer(const char *name, unsigned long *addr, size_t 
*size)


I think this new function can + should be marked __init as well; it's
only called from the existing IMA functions and your new
tpm_get_kexec_buffer which is already __init.


Yes, right. Thanks.
   Stefan


Re: [PATCH v2 3/4] powerpc/pseries: register pseries-wdt device with platform bus

2022-07-07 Thread Scott Cheloha
On Fri, Jun 24, 2022 at 11:27:36PM +1000, Michael Ellerman wrote:
> Nathan Lynch  writes:
> > Scott Cheloha  writes:
> >> PAPR v2.12 defines a new hypercall, H_WATCHDOG.  The hypercall permits
> >> guest control of one or more virtual watchdog timers.
> ...
> >
> > Seems like we don't need pseries_wdt_pdev as it's unused elsewhere? But
> > that's quite minor.
> 
> It's minor but please drop it in the next version.

Dropped.


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

2022-07-07 Thread Scott Cheloha
On Fri, Jun 24, 2022 at 11:51:01PM +1000, Michael Ellerman wrote:
> Scott Cheloha  writes:
> ...
> > +
> > +static struct platform_driver pseries_wdt_driver = {
> > +   .driver = {
> > +   .name = DRV_NAME,
> > +   .owner = THIS_MODULE,
> 
> That owner assignment is not required.
> 
> It's set for you by platform_driver_register() via
> module_platform_driver().

Great, removed.


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

2022-07-07 Thread Jason Gunthorpe
On Thu, Jul 07, 2022 at 11:55:52PM +1000, Alexey Kardashevskiy wrote:
> Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
> uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
> the Type1 VFIO driver. Recent development though has added a coherency
> capability check to the generic part of VFIO and essentially disabled
> VFIO on PPC64; the similar story about iommu_group_dma_owner_claimed().
> 
> This adds an iommu_ops stub which reports support for cache
> coherency. Because bus_set_iommu() triggers IOMMU probing of PCI devices,
> this provides minimum code for the probing to not crash.
> 
> Because now we have to set iommu_ops to the system (bus_set_iommu() or
> iommu_device_register()), this requires the POWERNV PCI setup to happen
> after bus_register(_bus_type) which is postcore_initcall
> TODO: check if it still works, read sha1, for more details:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5537fcb319d016ce387
> 
> Because setting the ops triggers probing, this does not work well with
> iommu_group_add_device(), hence the move to iommu_probe_device().
> 
> Because iommu_probe_device() does not take the group (which is why
> we had the helper in the first place), this adds
> pci_controller_ops::device_group.
> 
> So, basically there is one iommu_device per PHB and devices are added to
> groups indirectly via series of calls inside the IOMMU code.
> 
> pSeries is out of scope here (a minor fix needed for barely supported
> platform in regard to VFIO).
> 
> The previous discussion is here:
> https://patchwork.ozlabs.org/project/kvm-ppc/patch/20220701061751.1955857-1-...@ozlabs.ru/

I think this is basically OK, for what it is. It looks like there is
more some-day opportunity to make use of the core infrastructure though.

> does it make sense to have this many callbacks, or
> the generic IOMMU code can safely operate without some
> (given I add some more checks for !NULL)? thanks,

I wouldn't worry about it..

> @@ -1156,7 +1158,10 @@ int iommu_add_device(struct iommu_table_group 
> *table_group, struct device *dev)
>   pr_debug("%s: Adding %s to iommu group %d\n",
>__func__, dev_name(dev),  iommu_group_id(table_group->group));
>  
> - return iommu_group_add_device(table_group->group, dev);
> + ret = iommu_probe_device(dev);
> + dev_info(dev, "probed with %d\n", ret);

For another day, but it seems a bit strange to call iommu_probe_device() like 
this?
Shouldn't one of the existing call sites cover this? The one in
of_iommu.c perhaps?

> +static bool spapr_tce_iommu_is_attach_deferred(struct device *dev)
> +{
> +   return false;
> +}

I think you can NULL this op:

static bool iommu_is_attach_deferred(struct device *dev)
{
const struct iommu_ops *ops = dev_iommu_ops(dev);

if (ops->is_attach_deferred)
return ops->is_attach_deferred(dev);

return false;
}

> +static struct iommu_group *spapr_tce_iommu_device_group(struct device *dev)
> +{
> + struct pci_controller *hose;
> + struct pci_dev *pdev;
> +
> + /* Weirdly iommu_device_register() assigns the same ops to all buses */
> + if (!dev_is_pci(dev))
> + return ERR_PTR(-EPERM);
> +
> + pdev = to_pci_dev(dev);
> + hose = pdev->bus->sysdata;
> +
> + if (!hose->controller_ops.device_group)
> + return ERR_PTR(-ENOENT);
> +
> + return hose->controller_ops.device_group(hose, pdev);
> +}

Is this missing a refcount get on the group?

> +
> +static int spapr_tce_iommu_attach_dev(struct iommu_domain *dom,
> +   struct device *dev)
> +{
> + return 0;
> +}

It is important when this returns that the iommu translation is all
emptied. There should be no left over translations from the DMA API at
this point. I have no idea how power works in this regard, but it
should be explained why this is safe in a comment at a minimum.

It will turn into a security problem to allow kernel mappings to leak
past this point.

Jason


[PATCH 3/3] powerpc/ppc-opcode: Define and use PPC_RAW_SETB()

2022-07-07 Thread Christophe Leroy
We have PPC_INST_SETB then build the 'setb' instruction in the
user.

Instead, define PPC_RAW_SETB() and use it.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/ppc-opcode.h | 2 +-
 arch/powerpc/lib/test_emulate_step.c  | 9 +++--
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
b/arch/powerpc/include/asm/ppc-opcode.h
index 5527a955fb4a..7b81b37a191e 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -290,7 +290,6 @@
 #define PPC_INST_STRING0x7c00042a
 #define PPC_INST_STRING_MASK   0xfc0007fe
 #define PPC_INST_STRING_GEN_MASK   0xfc00067e
-#define PPC_INST_SETB  0x7c000100
 #define PPC_INST_STSWI 0x7c0005aa
 #define PPC_INST_STSWX 0x7c00052a
 #define PPC_INST_TRECHKPT  0x7c0007dd
@@ -583,6 +582,7 @@
 #define PPC_RAW_BL(offset) (0x4801 | PPC_LI(offset))
 #define PPC_RAW_TW(t0, a, b)   (0x7f08 | ___PPC_RS(t0) | 
___PPC_RA(a) | ___PPC_RB(b))
 #define PPC_RAW_TRAP() PPC_RAW_TW(31, 0, 0)
+#define PPC_RAW_SETB(t, bfa)   (0x7c000100 | ___PPC_RT(t) | 
___PPC_RA((bfa) << 2))
 
 /* Deal with instructions that older assemblers aren't aware of */
 #definePPC_BCCTR_FLUSH stringify_in_c(.long 
PPC_INST_BCCTR_FLUSH)
diff --git a/arch/powerpc/lib/test_emulate_step.c 
b/arch/powerpc/lib/test_emulate_step.c
index f2e47be05e8c..23c7805fb7b3 100644
--- a/arch/powerpc/lib/test_emulate_step.c
+++ b/arch/powerpc/lib/test_emulate_step.c
@@ -53,9 +53,6 @@
ppc_inst_prefix(PPC_PREFIX_MLS | __PPC_PRFX_R(pr) | IMM_H(i), \
PPC_RAW_ADDI(t, a, i))
 
-#define TEST_SETB(t, bfa)   ppc_inst(PPC_INST_SETB | ___PPC_RT(t) | 
___PPC_RA((bfa & 0x7) << 2))
-
-
 static void __init init_pt_regs(struct pt_regs *regs)
 {
static unsigned long msr;
@@ -935,21 +932,21 @@ static struct compute_test compute_tests[] = {
.subtests = {
{
.descr = "BFA = 1, CR = GT",
-   .instr = TEST_SETB(20, 1),
+   .instr = ppc_inst(PPC_RAW_SETB(20, 1)),
.regs = {
.ccr = 0x400,
}
},
{
.descr = "BFA = 4, CR = LT",
-   .instr = TEST_SETB(20, 4),
+   .instr = ppc_inst(PPC_RAW_SETB(20, 4)),
.regs = {
.ccr = 0x8000,
}
},
{
.descr = "BFA = 5, CR = EQ",
-   .instr = TEST_SETB(20, 5),
+   .instr = ppc_inst(PPC_RAW_SETB(20, 5)),
.regs = {
.ccr = 0x200,
}
-- 
2.36.1



[PATCH 2/3] powerpc/ppc-opcode: Define and use PPC_RAW_TRAP() and PPC_RAW_TW()

2022-07-07 Thread Christophe Leroy
Add and use PPC_RAW_TRAP() instead of opencoding.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/ppc-opcode.h | 2 ++
 arch/powerpc/include/asm/probes.h | 3 ++-
 arch/powerpc/xmon/xmon.c  | 2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc-opcode.h 
b/arch/powerpc/include/asm/ppc-opcode.h
index 89beabf5325c..5527a955fb4a 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -581,6 +581,8 @@
 
 #define PPC_RAW_BRANCH(offset) (0x4800 | PPC_LI(offset))
 #define PPC_RAW_BL(offset) (0x4801 | PPC_LI(offset))
+#define PPC_RAW_TW(t0, a, b)   (0x7f08 | ___PPC_RS(t0) | 
___PPC_RA(a) | ___PPC_RB(b))
+#define PPC_RAW_TRAP() PPC_RAW_TW(31, 0, 0)
 
 /* Deal with instructions that older assemblers aren't aware of */
 #definePPC_BCCTR_FLUSH stringify_in_c(.long 
PPC_INST_BCCTR_FLUSH)
diff --git a/arch/powerpc/include/asm/probes.h 
b/arch/powerpc/include/asm/probes.h
index 00634e3145e7..e77a2ed7d938 100644
--- a/arch/powerpc/include/asm/probes.h
+++ b/arch/powerpc/include/asm/probes.h
@@ -9,8 +9,9 @@
  */
 #include 
 #include 
+#include 
 
-#define BREAKPOINT_INSTRUCTION 0x7fe8  /* trap */
+#define BREAKPOINT_INSTRUCTION PPC_RAW_TRAP()  /* trap */
 
 /* Trap definitions per ISA */
 #define IS_TW(instr)   (((instr) & 0xfc0007fe) == 0x7c08)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index f80c714f1d49..26ef3388c24c 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -116,7 +116,7 @@ struct bpt {
 static struct bpt bpts[NBPTS];
 static struct bpt dabr[HBP_NUM_MAX];
 static struct bpt *iabr;
-static unsigned bpinstr = 0x7fe8;  /* trap */
+static unsigned int bpinstr = PPC_RAW_TRAP();
 
 #define BP_NUM(bp) ((bp) - bpts + 1)
 
-- 
2.36.1



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

2022-07-07 Thread Christophe Leroy
ppc_opcode_t is just an u32. There is no point in hiding u32
behind such a typedef. Remove it.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/kprobes.h | 2 +-
 arch/powerpc/include/asm/probes.h  | 1 -
 arch/powerpc/include/asm/uprobes.h | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/kprobes.h 
b/arch/powerpc/include/asm/kprobes.h
index bab364152b29..c8e4b4fd4e33 100644
--- a/arch/powerpc/include/asm/kprobes.h
+++ b/arch/powerpc/include/asm/kprobes.h
@@ -29,7 +29,7 @@
 struct pt_regs;
 struct kprobe;
 
-typedef ppc_opcode_t kprobe_opcode_t;
+typedef u32 kprobe_opcode_t;
 
 extern kprobe_opcode_t optinsn_slot;
 
diff --git a/arch/powerpc/include/asm/probes.h 
b/arch/powerpc/include/asm/probes.h
index 6f66e358aa37..00634e3145e7 100644
--- a/arch/powerpc/include/asm/probes.h
+++ b/arch/powerpc/include/asm/probes.h
@@ -10,7 +10,6 @@
 #include 
 #include 
 
-typedef u32 ppc_opcode_t;
 #define BREAKPOINT_INSTRUCTION 0x7fe8  /* trap */
 
 /* Trap definitions per ISA */
diff --git a/arch/powerpc/include/asm/uprobes.h 
b/arch/powerpc/include/asm/uprobes.h
index a7ae1860115a..4fea116d3d37 100644
--- a/arch/powerpc/include/asm/uprobes.h
+++ b/arch/powerpc/include/asm/uprobes.h
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-typedef ppc_opcode_t uprobe_opcode_t;
+typedef u32 uprobe_opcode_t;
 
 #define MAX_UINSN_BYTES8
 #define UPROBE_XOL_SLOT_BYTES  (MAX_UINSN_BYTES)
-- 
2.36.1



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

2022-07-07 Thread Christophe Leroy
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.

It also means perf is reliant on the fragile logic in setup_cpu_spec()
which detects when we're using a logical PVR and copies back the PMU
related fields from the raw CPU entry. So lets check the PVR directly.

Suggested-by: Michael Ellerman 
Signed-off-by: Rashmica Gupta 
Reviewed-by: Madhavan Srinivasan 
[chleroy: Added power10 and fixed checkpatch issues]
Signed-off-by: Christophe Leroy 
Reviewed-and-tested-by: Athira Rajeev 
Reviewed-and-tested-By: Kajol Jain  [For 24x7 side changes]
---
v4:
- No change to the series
- Added additional Reviewed-by/Tested-by.
- Rebased
- Resending to get some CI result this time
---
 arch/powerpc/perf/e500-pmu.c| 9 +
 arch/powerpc/perf/e6500-pmu.c   | 5 +++--
 arch/powerpc/perf/hv-24x7.c | 6 +++---
 arch/powerpc/perf/mpc7450-pmu.c | 5 +++--
 arch/powerpc/perf/power10-pmu.c | 6 ++
 arch/powerpc/perf/power5+-pmu.c | 6 +++---
 arch/powerpc/perf/power5-pmu.c  | 5 +++--
 arch/powerpc/perf/power6-pmu.c  | 5 +++--
 arch/powerpc/perf/power7-pmu.c  | 7 ---
 arch/powerpc/perf/power8-pmu.c  | 5 +++--
 arch/powerpc/perf/power9-pmu.c  | 4 +---
 arch/powerpc/perf/ppc970-pmu.c  | 7 ---
 12 files changed, 37 insertions(+), 33 deletions(-)

diff --git a/arch/powerpc/perf/e500-pmu.c b/arch/powerpc/perf/e500-pmu.c
index a59c33bed32a..e3e1a68eb1d5 100644
--- a/arch/powerpc/perf/e500-pmu.c
+++ b/arch/powerpc/perf/e500-pmu.c
@@ -118,12 +118,13 @@ static struct fsl_emb_pmu e500_pmu = {
 
 static int init_e500_pmu(void)
 {
-   if (!cur_cpu_spec->oprofile_cpu_type)
-   return -ENODEV;
+   unsigned int pvr = mfspr(SPRN_PVR);
 
-   if (!strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e500mc"))
+   /* ec500mc */
+   if (PVR_VER(pvr) == PVR_VER_E500MC || PVR_VER(pvr) == PVR_VER_E5500)
num_events = 256;
-   else if (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e500"))
+   /* e500 */
+   else if (PVR_VER(pvr) != PVR_VER_E500V1 && PVR_VER(pvr) != 
PVR_VER_E500V2)
return -ENODEV;
 
return register_fsl_emb_pmu(_pmu);
diff --git a/arch/powerpc/perf/e6500-pmu.c b/arch/powerpc/perf/e6500-pmu.c
index 44ad65da82ed..bd779a2338f8 100644
--- a/arch/powerpc/perf/e6500-pmu.c
+++ b/arch/powerpc/perf/e6500-pmu.c
@@ -107,8 +107,9 @@ static struct fsl_emb_pmu e6500_pmu = {
 
 static int init_e6500_pmu(void)
 {
-   if (!cur_cpu_spec->oprofile_cpu_type ||
-   strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/e6500"))
+   unsigned int pvr = mfspr(SPRN_PVR);
+
+   if (PVR_VER(pvr) != PVR_VER_E6500)
return -ENODEV;
 
return register_fsl_emb_pmu(_pmu);
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index cf5406b31e27..33c23225fd54 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1718,16 +1718,16 @@ static int hv_24x7_init(void)
 {
int r;
unsigned long hret;
+   unsigned int pvr = mfspr(SPRN_PVR);
struct hv_perf_caps caps;
 
if (!firmware_has_feature(FW_FEATURE_LPAR)) {
pr_debug("not a virtualized system, not enabling\n");
return -ENODEV;
-   } else if (!cur_cpu_spec->oprofile_cpu_type)
-   return -ENODEV;
+   }
 
/* POWER8 only supports v1, while POWER9 only supports v2. */
-   if (!strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power8"))
+   if (PVR_VER(pvr) == PVR_POWER8)
interface_version = 1;
else {
interface_version = 2;
diff --git a/arch/powerpc/perf/mpc7450-pmu.c b/arch/powerpc/perf/mpc7450-pmu.c
index e39b15b79a83..552d51a925d3 100644
--- a/arch/powerpc/perf/mpc7450-pmu.c
+++ b/arch/powerpc/perf/mpc7450-pmu.c
@@ -417,8 +417,9 @@ struct power_pmu mpc7450_pmu = {
 
 static int __init init_mpc7450_pmu(void)
 {
-   if (!cur_cpu_spec->oprofile_cpu_type ||
-   strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
+   unsigned int pvr = mfspr(SPRN_PVR);
+
+   if (PVR_VER(pvr) != PVR_7450)
return -ENODEV;
 
return register_power_pmu(_pmu);
diff --git a/arch/powerpc/perf/power10-pmu.c b/arch/powerpc/perf/power10-pmu.c
index c6d51e7093cf..a6a72b762d55 100644
--- a/arch/powerpc/perf/power10-pmu.c
+++ b/arch/powerpc/perf/power10-pmu.c
@@ -597,12 +597,10 @@ int __init init_power10_pmu(void)
unsigned int pvr;
int rc;
 
-   /* Comes from cpu_specs[] */
-   if (!cur_cpu_spec->oprofile_cpu_type ||
-   strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power10"))
+   pvr = mfspr(SPRN_PVR);
+   if (PVR_VER(pvr) != PVR_POWER10)
return -ENODEV;
 
-   pvr = mfspr(SPRN_PVR);
/* Add the ppmu flag for power10 DD1 */

[PATCH v5 2/2] powerpc: Remove remaining parts of oprofile

2022-07-07 Thread Christophe Leroy
Commit 9850b6c69356 ("arch: powerpc: Remove oprofile") removed
oprofile.

Remove all remaining parts of it.

Signed-off-by: Christophe Leroy 
Acked-by: Viresh Kumar 
---
 arch/powerpc/include/asm/cputable.h   |  3 -
 arch/powerpc/kernel/cputable.c| 67 +--
 arch/powerpc/kernel/dt_cpu_ftrs.c |  4 --
 arch/powerpc/platforms/cell/spufs/spufs.h |  2 +-
 arch/powerpc/platforms/ps3/Kconfig|  2 +-
 5 files changed, 4 insertions(+), 74 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 549eb6dd146f..ae8c3e13cfce 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -70,9 +70,6 @@ struct cpu_spec {
/* Used to restore cpu setup on secondary processors and at resume */
cpu_restore_t   cpu_restore;
 
-   /* Used by oprofile userspace to select the right counters */
-   char*oprofile_cpu_type;
-
/* Name of processor class, for the ELF AT_PLATFORM entry */
char*platform;
 
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index a5dbfccd2047..d8e42ef750f1 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -149,7 +149,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type   = PPC_PMC_IBM,
.cpu_setup  = __setup_cpu_ppc970,
.cpu_restore= __restore_cpu_ppc970,
-   .oprofile_cpu_type  = "ppc64/970",
.platform   = "ppc970",
},
{   /* PPC970FX */
@@ -166,7 +165,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type   = PPC_PMC_IBM,
.cpu_setup  = __setup_cpu_ppc970,
.cpu_restore= __restore_cpu_ppc970,
-   .oprofile_cpu_type  = "ppc64/970",
.platform   = "ppc970",
},
{   /* PPC970MP DD1.0 - no DEEPNAP, use regular 970 init */
@@ -183,7 +181,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type   = PPC_PMC_IBM,
.cpu_setup  = __setup_cpu_ppc970,
.cpu_restore= __restore_cpu_ppc970,
-   .oprofile_cpu_type  = "ppc64/970MP",
.platform   = "ppc970",
},
{   /* PPC970MP */
@@ -200,7 +197,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pmc_type   = PPC_PMC_IBM,
.cpu_setup  = __setup_cpu_ppc970MP,
.cpu_restore= __restore_cpu_ppc970,
-   .oprofile_cpu_type  = "ppc64/970MP",
.platform   = "ppc970",
},
{   /* PPC970GX */
@@ -216,7 +212,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs   = 8,
.pmc_type   = PPC_PMC_IBM,
.cpu_setup  = __setup_cpu_ppc970,
-   .oprofile_cpu_type  = "ppc64/970",
.platform   = "ppc970",
},
{   /* Power5 GR */
@@ -230,7 +225,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize   = 128,
.num_pmcs   = 6,
.pmc_type   = PPC_PMC_IBM,
-   .oprofile_cpu_type  = "ppc64/power5",
.platform   = "power5",
},
{   /* Power5++ */
@@ -243,7 +237,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize   = 128,
.dcache_bsize   = 128,
.num_pmcs   = 6,
-   .oprofile_cpu_type  = "ppc64/power5++",
.platform   = "power5+",
},
{   /* Power5 GS */
@@ -257,7 +250,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize   = 128,
.num_pmcs   = 6,
.pmc_type   = PPC_PMC_IBM,
-   .oprofile_cpu_type  = "ppc64/power5+",
.platform   = "power5+",
},
{   /* POWER6 in P5+ mode; 2.04-compliant processor */
@@ -269,7 +261,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.mmu_features   = MMU_FTRS_POWER5,
.icache_bsize   = 128,
.dcache_bsize   = 128,
-   .oprofile_cpu_type  = "ppc64/ibm-compat-v1",
.platform   = "power5+",
},
{   /* Power6 */
@@ -284,7 +275,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize   = 128,
.num_pmcs   = 6,
   

[PATCH v2 4/4] powerpc: Finally remove unnecessary headers from asm/prom.h

2022-07-07 Thread Christophe Leroy
Remove all headers included from asm/prom.h which are not used
by asm/prom.h itself.

Declare struct device_node and struct property locally to
avoid including of.h

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/prom.h | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index 6f109b5cb84e..2e82820fbd64 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -12,16 +12,10 @@
  * Updates for PPC64 by Peter Bergner & David Engebretsen, IBM Corp.
  */
 #include 
-#include 
-#include 
 #include 
 
-/* These includes should be removed once implicit includes are cleaned up. */
-#include 
-#include 
-#include 
-#include 
-#include 
+struct device_node;
+struct property;
 
 #define OF_DT_BEGIN_NODE   0x1 /* Start of node, full name */
 #define OF_DT_END_NODE 0x2 /* End node */
-- 
2.36.1



[PATCH v2 3/4] powerpc: Remove asm/prom.h from asm/mpc52xx.h and asm/pci.h

2022-07-07 Thread Christophe Leroy
asm/pci.h and asm/mpc52xx.h don't need asm/prom.h

Declare struct device_node locally to avoid including of.h

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/mpc52xx.h | 3 ++-
 arch/powerpc/include/asm/pci.h | 1 -
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index ddd80aae1e32..5ea16a71c2f0 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -15,7 +15,6 @@
 
 #ifndef __ASSEMBLY__
 #include 
-#include 
 #include 
 #endif /* __ASSEMBLY__ */
 
@@ -268,6 +267,8 @@ struct mpc52xx_intr {
 
 #ifndef __ASSEMBLY__
 
+struct device_node;
+
 /* mpc52xx_common.c */
 extern void mpc5200_setup_xlb_arbiter(void);
 extern void mpc52xx_declare_of_platform_devices(void);
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 915d6ee4b40a..0f182074cdb7 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -14,7 +14,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 /* Return values for pci_controller_ops.probe_mode function */
-- 
2.36.1



[PATCH v2 2/4] scsi: cxlflash: Include missing linux/irqdomain.h

2022-07-07 Thread Christophe Leroy
powerpc's asm/prom.h brings some headers that it doesn't need itself.

Once those headers are removed from asm/prom.h, the following
errors occur:

  CC [M]  drivers/scsi/cxlflash/ocxl_hw.o
drivers/scsi/cxlflash/ocxl_hw.c: In function 'afu_map_irq':
drivers/scsi/cxlflash/ocxl_hw.c:195:16: error: implicit declaration of function 
'irq_create_mapping' [-Werror=implicit-function-declaration]
  195 | virq = irq_create_mapping(NULL, irq->hwirq);
  |^~
drivers/scsi/cxlflash/ocxl_hw.c:222:9: error: implicit declaration of function 
'irq_dispose_mapping' [-Werror=implicit-function-declaration]
  222 | irq_dispose_mapping(virq);
  | ^~~
drivers/scsi/cxlflash/ocxl_hw.c: In function 'afu_unmap_irq':
drivers/scsi/cxlflash/ocxl_hw.c:264:13: error: implicit declaration of function 
'irq_find_mapping'; did you mean 'is_cow_mapping'? 
[-Werror=implicit-function-declaration]
  264 | if (irq_find_mapping(NULL, irq->hwirq)) {
  | ^~~~
  | is_cow_mapping
cc1: some warnings being treated as errors

Fix it by including linux/irqdomain.h

Signed-off-by: Christophe Leroy 
---
 drivers/scsi/cxlflash/ocxl_hw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 244fc27215dc..631eda2d467e 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.36.1



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

2022-07-07 Thread Christophe Leroy
A lot of drivers were getting platform and of headers
indirectly via headers like asm/pci.h or asm/prom.h

Most of them were fixed during 5.19 cycle but a newissue was
introduced by commit 52b1b46c39ae ("of: Create platform devices
for OF framebuffers")

Include missing platform_device.h to allow cleaning asm/pci.h

Cc: Thomas Zimmermann 
Fixes: 52b1b46c39ae ("of: Create platform devices for OF framebuffers")
Signed-off-by: Christophe Leroy 
Acked-by: Helge Deller 
---
 drivers/video/fbdev/offb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index b1acb1ebebe9..91001990e351 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_PPC32
-- 
2.36.1



[PATCH v2] powerpc: Merge hardirq stack and softirq stack

2022-07-07 Thread Christophe Leroy
__do_IRQ() doesn't switch on hardirq stack if we are on softirq stack.

do_softirq() bail out early without doing anything when already in
an interrupt.

invoke_softirq() is on task_stack when it calls do_softirq_own_stack().

So there are neither situation where we switch from hardirq stack to
softirq stack nor from softirq stack to hardirq stack.

It is therefore not necessary to have two stacks because they are
never used at the same time.

Merge both stacks into a new one called normirq_ctx.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/irq.h |  3 +--
 arch/powerpc/kernel/irq.c  | 18 +++---
 arch/powerpc/kernel/process.c  |  6 +-
 arch/powerpc/kernel/setup_32.c |  6 ++
 arch/powerpc/kernel/setup_64.c |  6 ++
 5 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 5c1516a5ba8f..137909a6e0c1 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -49,8 +49,7 @@ extern void *mcheckirq_ctx[NR_CPUS];
 /*
  * Per-cpu stacks for handling hard and soft interrupts.
  */
-extern void *hardirq_ctx[NR_CPUS];
-extern void *softirq_ctx[NR_CPUS];
+extern void *normirq_ctx[NR_CPUS];
 
 void __do_IRQ(struct pt_regs *regs);
 extern void __init init_IRQ(void);
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index d50a1bd9..0ac0e7ddf8ac 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -274,15 +274,14 @@ static __always_inline void call_do_irq(struct pt_regs 
*regs, void *sp)
 void __do_IRQ(struct pt_regs *regs)
 {
struct pt_regs *old_regs = set_irq_regs(regs);
-   void *cursp, *irqsp, *sirqsp;
+   void *cursp, *irqsp;
 
/* Switch to the irq stack to handle this */
cursp = (void *)(current_stack_pointer & ~(THREAD_SIZE - 1));
-   irqsp = hardirq_ctx[raw_smp_processor_id()];
-   sirqsp = softirq_ctx[raw_smp_processor_id()];
+   irqsp = normirq_ctx[raw_smp_processor_id()];
 
/* Already there ? If not switch stack and call */
-   if (unlikely(cursp == irqsp || cursp == sirqsp))
+   if (unlikely(cursp == irqsp))
__do_irq(regs, current_stack_pointer);
else
call_do_irq(regs, irqsp);
@@ -305,10 +304,8 @@ static void __init vmap_irqstack_init(void)
 {
int i;
 
-   for_each_possible_cpu(i) {
-   softirq_ctx[i] = alloc_vm_stack();
-   hardirq_ctx[i] = alloc_vm_stack();
-   }
+   for_each_possible_cpu(i)
+   normirq_ctx[i] = alloc_vm_stack();
 }
 
 
@@ -330,12 +327,11 @@ void*dbgirq_ctx[NR_CPUS] __read_mostly;
 void *mcheckirq_ctx[NR_CPUS] __read_mostly;
 #endif
 
-void *softirq_ctx[NR_CPUS] __read_mostly;
-void *hardirq_ctx[NR_CPUS] __read_mostly;
+void *normirq_ctx[NR_CPUS] __read_mostly;
 
 void do_softirq_own_stack(void)
 {
-   call_do_softirq(softirq_ctx[smp_processor_id()]);
+   call_do_softirq(normirq_ctx[smp_processor_id()]);
 }
 
 irq_hw_number_t virq_to_hw(unsigned int virq)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 0fbda89cd1bb..c17c974e5723 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2089,11 +2089,7 @@ static inline int valid_irq_stack(unsigned long sp, 
struct task_struct *p,
unsigned long stack_page;
unsigned long cpu = task_cpu(p);
 
-   stack_page = (unsigned long)hardirq_ctx[cpu];
-   if (sp >= stack_page && sp <= stack_page + THREAD_SIZE - nbytes)
-   return 1;
-
-   stack_page = (unsigned long)softirq_ctx[cpu];
+   stack_page = (unsigned long)normirq_ctx[cpu];
if (sp >= stack_page && sp <= stack_page + THREAD_SIZE - nbytes)
return 1;
 
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 813261789303..cad0e4fbdd4b 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -158,10 +158,8 @@ void __init irqstack_early_init(void)
 
/* interrupt stacks must be in lowmem, we get that for free on ppc32
 * as the memblock is limited to lowmem by default */
-   for_each_possible_cpu(i) {
-   softirq_ctx[i] = alloc_stack();
-   hardirq_ctx[i] = alloc_stack();
-   }
+   for_each_possible_cpu(i)
+   normirq_ctx[i] = alloc_stack();
 }
 
 #ifdef CONFIG_VMAP_STACK
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 2b2d0b0fbb30..2fe727e01937 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -717,10 +717,8 @@ void __init irqstack_early_init(void)
 * cannot afford to take SLB misses on them. They are not
 * accessed in realmode.
 */
-   for_each_possible_cpu(i) {
-   softirq_ctx[i] = alloc_stack(limit, i);
-   hardirq_ctx[i] = alloc_stack(limit, i);
-   }
+   for_each_possible_cpu(i)

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

2022-07-07 Thread Alexey Kardashevskiy
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though has added a coherency
capability check to the generic part of VFIO and essentially disabled
VFIO on PPC64; the similar story about iommu_group_dma_owner_claimed().

This adds an iommu_ops stub which reports support for cache
coherency. Because bus_set_iommu() triggers IOMMU probing of PCI devices,
this provides minimum code for the probing to not crash.

Because now we have to set iommu_ops to the system (bus_set_iommu() or
iommu_device_register()), this requires the POWERNV PCI setup to happen
after bus_register(_bus_type) which is postcore_initcall
TODO: check if it still works, read sha1, for more details:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5537fcb319d016ce387

Because setting the ops triggers probing, this does not work well with
iommu_group_add_device(), hence the move to iommu_probe_device().

Because iommu_probe_device() does not take the group (which is why
we had the helper in the first place), this adds
pci_controller_ops::device_group.

So, basically there is one iommu_device per PHB and devices are added to
groups indirectly via series of calls inside the IOMMU code.

pSeries is out of scope here (a minor fix needed for barely supported
platform in regard to VFIO).

The previous discussion is here:
https://patchwork.ozlabs.org/project/kvm-ppc/patch/20220701061751.1955857-1-...@ozlabs.ru/

Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence")
Fixes: 70693f470848 ("vfio: Set DMA ownership for VFIO devices")
Cc: Oliver O'Halloran 
Cc: Robin Murphy 
Cc: Jason Gunthorpe 
Cc: Alex Williamson 
Cc: Daniel Henrique Barboza 
Cc: Fabiano Rosas 
Cc: Murilo Opsfelder Araujo 
Cc: Nicholas Piggin 
Signed-off-by: Alexey Kardashevskiy 
---


does it make sense to have this many callbacks, or
the generic IOMMU code can safely operate without some
(given I add some more checks for !NULL)? thanks,


---
 arch/powerpc/include/asm/iommu.h  |   2 +
 arch/powerpc/include/asm/pci-bridge.h |   7 ++
 arch/powerpc/kernel/iommu.c   | 106 +-
 arch/powerpc/kernel/pci-common.c  |   2 +-
 arch/powerpc/platforms/powernv/pci-ioda.c |  40 
 5 files changed, 155 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 7e29c73e3dd4..4bdae0ee29d0 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -215,6 +215,8 @@ extern long iommu_tce_xchg_no_kill(struct mm_struct *mm,
enum dma_data_direction *direction);
 extern void iommu_tce_kill(struct iommu_table *tbl,
unsigned long entry, unsigned long pages);
+
+extern const struct iommu_ops spapr_tce_iommu_ops;
 #else
 static inline void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number,
diff --git a/arch/powerpc/include/asm/pci-bridge.h 
b/arch/powerpc/include/asm/pci-bridge.h
index c85f901227c9..338a45b410b4 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct device_node;
 
@@ -44,6 +45,9 @@ struct pci_controller_ops {
 #endif
 
void(*shutdown)(struct pci_controller *hose);
+
+   struct iommu_group *(*device_group)(struct pci_controller *hose,
+   struct pci_dev *pdev);
 };
 
 /*
@@ -131,6 +135,9 @@ struct pci_controller {
struct irq_domain   *dev_domain;
struct irq_domain   *msi_domain;
struct fwnode_handle*fwnode;
+
+   /* iommu_ops support */
+   struct iommu_device iommu;
 };
 
 /* These are used for config access before all the PCI probing
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 7e56ddb3e0b9..c4c7eb596fef 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1138,6 +1138,8 @@ EXPORT_SYMBOL_GPL(iommu_release_ownership);
 
 int iommu_add_device(struct iommu_table_group *table_group, struct device *dev)
 {
+   int ret;
+
/*
 * The sysfs entries should be populated before
 * binding IOMMU group. If sysfs entries isn't
@@ -1156,7 +1158,10 @@ int iommu_add_device(struct iommu_table_group 
*table_group, struct device *dev)
pr_debug("%s: Adding %s to iommu group %d\n",
 __func__, dev_name(dev),  iommu_group_id(table_group->group));
 
-   return iommu_group_add_device(table_group->group, dev);
+   ret = iommu_probe_device(dev);
+   dev_info(dev, "probed with %d\n", ret);
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(iommu_add_device);
 
@@ -1176,4 +1181,103 @@ void iommu_del_device(struct device *dev)
iommu_group_remove_device(dev);
 }
 

Re: [PATCH/RFC] powerpc/module_64: allow .init_array constructors to run

2022-07-07 Thread Jan Stancek
On Thu, Jul 7, 2022 at 1:20 PM Christophe Leroy
 wrote:
>
>
>
> Le 17/08/2021 à 15:02, Jan Stancek a écrit :
> > gcov and kasan rely on compiler generated constructor code.
> > For modules, gcc-8 with gcov enabled generates .init_array section,
> > but on ppc64le it doesn't get executed. find_module_sections() never
> > finds .init_array section, because module_frob_arch_sections() renames
> > it to _init_array.
> >
> > Avoid renaming .init_array section, so do_mod_ctors() can use it.
> >
> > Cc: Michael Ellerman 
> > Cc: Benjamin Herrenschmidt 
> > Cc: Paul Mackerras 
> > Cc: Christophe Leroy 
> > Signed-off-by: Jan Stancek 
>
> Does commit d4be60fe66b7 ("powerpc/module_64: use module_init_section
> instead of patching names") fixes your issue ?

Yes, it does gcov for me. Thanks

>
> If not, please rebase and resubmit.
>
> Thanks
> Christophe
>
>
> > ---
> > I wasn't able to trace the comment:
> >"We don't handle .init for the moment: rename to _init"
> > to original patch (it pre-dates .git). I'm not sure if it
> > still applies today, so I limited patch to .init_array. This
> > fixes gcov for modules for me on ppc64le 5.14.0-rc6.
> >
> > Renaming issue is also mentioned in kasan patches here:
> >
> > https://patchwork.ozlabs.org/project/linuxppc-dev/cover/20210319144058.772525-1-dja@axtens
> >
> >   arch/powerpc/kernel/module_64.c | 10 +-
> >   1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kernel/module_64.c 
> > b/arch/powerpc/kernel/module_64.c
> > index 6baa676e7cb6..c604b13ea6bf 100644
> > --- a/arch/powerpc/kernel/module_64.c
> > +++ b/arch/powerpc/kernel/module_64.c
> > @@ -299,8 +299,16 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
> > sechdrs[i].sh_size);
> >
> >   /* We don't handle .init for the moment: rename to _init */
> > - while ((p = strstr(secstrings + sechdrs[i].sh_name, ".init")))
> > + while ((p = strstr(secstrings + sechdrs[i].sh_name, 
> > ".init"))) {
> > +#ifdef CONFIG_CONSTRUCTORS
> > + /* find_module_sections() needs .init_array intact */
> > + if (strstr(secstrings + sechdrs[i].sh_name,
> > + ".init_array")) {
> > + break;
> > + }
> > +#endif
> >   p[0] = '_';
> > + }
> >
> >   if (sechdrs[i].sh_type == SHT_SYMTAB)
> >   dedotify((void *)hdr + sechdrs[i].sh_offset,
>



Re: linux-next: manual merge of the random tree with the powerpc tree

2022-07-07 Thread Stephen Rothwell
Hi Jason,

On Thu, 7 Jul 2022 12:52:54 +0200 "Jason A. Donenfeld"  wrote:
>
> Oh darn. Any clever tricks to prevent the merge conflict from
> happening? Or is this trivial enough that we'll let Linus deal with
> it?

Just leave it for Linus, its pretty trivial.

-- 
Cheers,
Stephen Rothwell


pgpmVqXB8IZLL.pgp
Description: OpenPGP digital signature


Re: [PATCH/RFC] powerpc/module_64: allow .init_array constructors to run

2022-07-07 Thread Christophe Leroy




Le 17/08/2021 à 15:02, Jan Stancek a écrit :

gcov and kasan rely on compiler generated constructor code.
For modules, gcc-8 with gcov enabled generates .init_array section,
but on ppc64le it doesn't get executed. find_module_sections() never
finds .init_array section, because module_frob_arch_sections() renames
it to _init_array.

Avoid renaming .init_array section, so do_mod_ctors() can use it.

Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Christophe Leroy 
Signed-off-by: Jan Stancek 


Does commit d4be60fe66b7 ("powerpc/module_64: use module_init_section 
instead of patching names") fixes your issue ?


If not, please rebase and resubmit.

Thanks
Christophe



---
I wasn't able to trace the comment:
   "We don't handle .init for the moment: rename to _init"
to original patch (it pre-dates .git). I'm not sure if it
still applies today, so I limited patch to .init_array. This
fixes gcov for modules for me on ppc64le 5.14.0-rc6.

Renaming issue is also mentioned in kasan patches here:
   
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/20210319144058.772525-1-dja@axtens

  arch/powerpc/kernel/module_64.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 6baa676e7cb6..c604b13ea6bf 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -299,8 +299,16 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
  sechdrs[i].sh_size);
  
  		/* We don't handle .init for the moment: rename to _init */

-   while ((p = strstr(secstrings + sechdrs[i].sh_name, ".init")))
+   while ((p = strstr(secstrings + sechdrs[i].sh_name, ".init"))) {
+#ifdef CONFIG_CONSTRUCTORS
+   /* find_module_sections() needs .init_array intact */
+   if (strstr(secstrings + sechdrs[i].sh_name,
+   ".init_array")) {
+   break;
+   }
+#endif
p[0] = '_';
+   }
  
  		if (sechdrs[i].sh_type == SHT_SYMTAB)

dedotify((void *)hdr + sechdrs[i].sh_offset,


[Bug 213079] [bisected] IRQ problems and crashes on a PowerMac G5 with 5.12.3

2022-07-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213079

--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
(Luckily) I am no longer able to reproduce this. Re-tested on 5.19-rc5.

Perhaps the problem was also specific for this specific NVMe SSD. I swapped it
for another one and now I have not seen this issue so far.

I'll keep an eye on it and will close here if it stays like that for the next
few stable kernels.

-- 
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 213837] [bisected] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

2022-07-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213837

--- Comment #21 from Erhard F. (erhar...@mailbox.org) ---
(Luckily) I am no longer able to reproduce this. Re-tested on 5.19-rc5.

I'll keep an eye on it and will close here if it stays like that for the next
few stable kernels.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

Re: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0

2022-07-07 Thread Chen, Rong A

org, net...@vger.kernel.org, k...@vger.kernel.org, da...@lists.linux.dev, 
linux...@kvack.org, accessrunner-gene...@lists.sourceforge.net, 
linux1394-de...@lists.sourceforge.net, linux-l...@vger.kernel.org, 
rds-de...@oss.oracle.com, linux-...@vger.kernel.org, d...@vger.kernel.org, 
intel-wired-...@lists.osuosl.org, linux-ser...@vger.kernel.org, 
devicet...@vger.kernel.org, linux-...@lists.01.org, 
osmocom-net-g...@lists.osmocom.org, appar...@lists.ubuntu.com, 
linux-r...@vger.kernel.org, linux-bca...@vger.kernel.org, 
linux-media...@lists.infradead.org, linux-te...@vger.kernel.org, 
linux-s...@vger.kernel.org, patc...@opensource.cirrus.com, 
linux-unio...@vger.kernel.org, linux-blueto...@vger.kernel.org, 
n...@lists.linux.dev, tipc-discuss...@lists.sourceforge.net, 
linuxppc-dev@lists.ozlabs.org, linux-bt...@vger.kernel.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 




On 7/7/2022 4:08 PM, Greg KH wrote:

On Thu, Jul 07, 2022 at 02:56:34PM +0800, kernel test robot wrote:

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 088b9c375534d905a4d337c78db3b3bfbb52c4a0  Add linux-next specific 
files for 20220706

Error/Warning reports:

https://lore.kernel.org/linux-doc/202207070644.x48xoovs-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

Documentation/arm/google/chromebook-boot-flow.rst: WARNING: document isn't 
included in any toctree
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1108): undefined reference to 
`__aeabi_ddiv'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1124): undefined reference to 
`__aeabi_ui2d'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1164): undefined reference to 
`__aeabi_dmul'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1170): undefined reference to 
`__aeabi_dadd'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1180): undefined reference to 
`__aeabi_dsub'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1190): undefined reference to 
`__aeabi_d2uiz'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x162c): undefined reference to 
`__aeabi_d2iz'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x16b0): undefined reference to 
`__aeabi_i2d'
dc_dmub_srv.c:(.text+0x10f8): undefined reference to `__aeabi_ui2d'
dc_dmub_srv.c:(.text+0x464): undefined reference to `__floatunsidf'
dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x33c): undefined 
reference to `__floatunsidf'
drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: no previous 
prototype for 'pci_read' [-Wmissing-prototypes]
drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: no previous 
prototype for 'pci_write' [-Wmissing-prototypes]
drivers/vfio/vfio_iommu_type1.c:2141:35: warning: cast to smaller integer type 
'enum iommu_cap' from 'void *' [-Wvoid-pointer-to-enum-cast]
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x34c): 
undefined reference to `__floatunsidf'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x378): 
undefined reference to `__divdf3'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x38c): 
undefined reference to `__muldf3'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3a0): 
undefined reference to `__adddf3'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3b4): 
undefined reference to `__subdf3'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3d4): 
undefined reference to `__fixunsdfsi'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x750): 
undefined reference to `__fixdfsi'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x7c0): 
undefined reference to `__floatsidf'
powerpc-linux-ld: drivers/pci/endpoint/functions/pci-epf-vntb.c:174: undefined 
reference to `ntb_link_event'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x468): undefined reference to `__divdf3'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x46c): undefined reference to `__muldf3'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x470): undefined reference to `__adddf3'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x474): undefined reference to `__subdf3'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x478): undefined reference to 
`__fixunsdfsi'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x47c): undefined reference to `__fixdfsi'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x480): undefined reference to 
`__floatsidf'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x60c): undefined reference to 
`__floatunsidf'

Unverified Error/Warning (likely false positive, please contact us if 
interested):

arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code 'err'
drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced.
drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but 
dereferenced.
drivers/android/binder.c:353:25-35: ERROR: node -> proc is NULL but 
dereferenced.
drivers/android/binder.c:4888:16-20: ERROR: t is NULL but 

Re: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0

2022-07-07 Thread Greg KH
org, net...@vger.kernel.org, k...@vger.kernel.org, da...@lists.linux.dev, 
linux...@kvack.org, accessrunner-gene...@lists.sourceforge.net, 
linux1394-de...@lists.sourceforge.net, linux-l...@vger.kernel.org, 
rds-de...@oss.oracle.com, linux-...@vger.kernel.org, d...@vger.kernel.org, 
intel-wired-...@lists.osuosl.org, linux-ser...@vger.kernel.org, 
devicet...@vger.kernel.org, linux-...@lists.01.org, 
osmocom-net-g...@lists.osmocom.org, appar...@lists.ubuntu.com, 
linux-r...@vger.kernel.org, linux-bca...@vger.kernel.org, 
linux-media...@lists.infradead.org, linux-te...@vger.kernel.org, 
linux-s...@vger.kernel.org, patc...@opensource.cirrus.com, 
linux-unio...@vger.kernel.org, linux-blueto...@vger.kernel.org, 
n...@lists.linux.dev, tipc-discuss...@lists.sourceforge.net, 
linuxppc-dev@lists.ozlabs.org, linux-bt...@vger.kernel.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


On Thu, Jul 07, 2022 at 02:56:34PM +0800, kernel test robot wrote:
> tree/branch: 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 088b9c375534d905a4d337c78db3b3bfbb52c4a0  Add linux-next 
> specific files for 20220706
> 
> Error/Warning reports:
> 
> https://lore.kernel.org/linux-doc/202207070644.x48xoovs-...@intel.com
> 
> Error/Warning: (recently discovered and may have been fixed)
> 
> Documentation/arm/google/chromebook-boot-flow.rst: WARNING: document isn't 
> included in any toctree
> arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1108): undefined reference to 
> `__aeabi_ddiv'
> arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1124): undefined reference to 
> `__aeabi_ui2d'
> arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1164): undefined reference to 
> `__aeabi_dmul'
> arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1170): undefined reference to 
> `__aeabi_dadd'
> arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1180): undefined reference to 
> `__aeabi_dsub'
> arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1190): undefined reference to 
> `__aeabi_d2uiz'
> arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x162c): undefined reference to 
> `__aeabi_d2iz'
> arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x16b0): undefined reference to 
> `__aeabi_i2d'
> dc_dmub_srv.c:(.text+0x10f8): undefined reference to `__aeabi_ui2d'
> dc_dmub_srv.c:(.text+0x464): undefined reference to `__floatunsidf'
> dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x33c): undefined 
> reference to `__floatunsidf'
> drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: no previous 
> prototype for 'pci_read' [-Wmissing-prototypes]
> drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: no previous 
> prototype for 'pci_write' [-Wmissing-prototypes]
> drivers/vfio/vfio_iommu_type1.c:2141:35: warning: cast to smaller integer 
> type 'enum iommu_cap' from 'void *' [-Wvoid-pointer-to-enum-cast]
> mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x34c): 
> undefined reference to `__floatunsidf'
> mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x378): 
> undefined reference to `__divdf3'
> mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x38c): 
> undefined reference to `__muldf3'
> mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3a0): 
> undefined reference to `__adddf3'
> mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3b4): 
> undefined reference to `__subdf3'
> mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3d4): 
> undefined reference to `__fixunsdfsi'
> mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x750): 
> undefined reference to `__fixdfsi'
> mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x7c0): 
> undefined reference to `__floatsidf'
> powerpc-linux-ld: drivers/pci/endpoint/functions/pci-epf-vntb.c:174: 
> undefined reference to `ntb_link_event'
> xtensa-linux-ld: dc_dmub_srv.c:(.text+0x468): undefined reference to 
> `__divdf3'
> xtensa-linux-ld: dc_dmub_srv.c:(.text+0x46c): undefined reference to 
> `__muldf3'
> xtensa-linux-ld: dc_dmub_srv.c:(.text+0x470): undefined reference to 
> `__adddf3'
> xtensa-linux-ld: dc_dmub_srv.c:(.text+0x474): undefined reference to 
> `__subdf3'
> xtensa-linux-ld: dc_dmub_srv.c:(.text+0x478): undefined reference to 
> `__fixunsdfsi'
> xtensa-linux-ld: dc_dmub_srv.c:(.text+0x47c): undefined reference to 
> `__fixdfsi'
> xtensa-linux-ld: dc_dmub_srv.c:(.text+0x480): undefined reference to 
> `__floatsidf'
> xtensa-linux-ld: dc_dmub_srv.c:(.text+0x60c): undefined reference to 
> `__floatunsidf'
> 
> Unverified Error/Warning (likely false positive, please contact us if 
> interested):
> 
> arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code 
> 'err'
> drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced.
> drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but 
> dereferenced.
> 

[linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0

2022-07-07 Thread kernel test robot
l.org, da...@lists.linux.dev, Linux Memory Management List 
, accessrunner-gene...@lists.sourceforge.net, 
linux1394-de...@lists.sourceforge.net, linux-l...@vger.kernel.org, 
rds-de...@oss.oracle.com, linux-...@vger.kernel.org, d...@vger.kernel.org, 
intel-wired-...@lists.osuosl.org, linux-ser...@vger.kernel.org, 
devicet...@vger.kernel.org, linux-...@lists.01.org, 
osmocom-net-g...@lists.osmocom.org, appar...@lists.ubuntu.com, 
linux-r...@vger.kernel.org, linux-bca...@vger.kernel.org, 
linux-media...@lists.infradead.org, linux-te...@vger.kernel.org, 
linux-s...@vger.kernel.org, patc...@opensource.cirrus.com, 
linux-unio...@vger.kernel.org, linux-blueto...@vger.kernel.org, 
n...@lists.linux.dev, tipc-discuss...@lists.sourceforge.net, 
linuxppc-dev@lists.ozlabs.org, linux-bt...@vger.kernel.org
Errors-To: linuxppc-dev-bounces+archive=mail-archive@lists.ozlabs.org
Sender: "Linuxppc-dev" 


tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 088b9c375534d905a4d337c78db3b3bfbb52c4a0  Add linux-next specific 
files for 20220706

Error/Warning reports:

https://lore.kernel.org/linux-doc/202207070644.x48xoovs-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

Documentation/arm/google/chromebook-boot-flow.rst: WARNING: document isn't 
included in any toctree
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1108): undefined reference to 
`__aeabi_ddiv'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1124): undefined reference to 
`__aeabi_ui2d'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1164): undefined reference to 
`__aeabi_dmul'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1170): undefined reference to 
`__aeabi_dadd'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1180): undefined reference to 
`__aeabi_dsub'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1190): undefined reference to 
`__aeabi_d2uiz'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x162c): undefined reference to 
`__aeabi_d2iz'
arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x16b0): undefined reference to 
`__aeabi_i2d'
dc_dmub_srv.c:(.text+0x10f8): undefined reference to `__aeabi_ui2d'
dc_dmub_srv.c:(.text+0x464): undefined reference to `__floatunsidf'
dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x33c): undefined 
reference to `__floatunsidf'
drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: no previous 
prototype for 'pci_read' [-Wmissing-prototypes]
drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: no previous 
prototype for 'pci_write' [-Wmissing-prototypes]
drivers/vfio/vfio_iommu_type1.c:2141:35: warning: cast to smaller integer type 
'enum iommu_cap' from 'void *' [-Wvoid-pointer-to-enum-cast]
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x34c): 
undefined reference to `__floatunsidf'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x378): 
undefined reference to `__divdf3'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x38c): 
undefined reference to `__muldf3'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3a0): 
undefined reference to `__adddf3'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3b4): 
undefined reference to `__subdf3'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3d4): 
undefined reference to `__fixunsdfsi'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x750): 
undefined reference to `__fixdfsi'
mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x7c0): 
undefined reference to `__floatsidf'
powerpc-linux-ld: drivers/pci/endpoint/functions/pci-epf-vntb.c:174: undefined 
reference to `ntb_link_event'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x468): undefined reference to `__divdf3'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x46c): undefined reference to `__muldf3'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x470): undefined reference to `__adddf3'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x474): undefined reference to `__subdf3'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x478): undefined reference to 
`__fixunsdfsi'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x47c): undefined reference to `__fixdfsi'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x480): undefined reference to 
`__floatsidf'
xtensa-linux-ld: dc_dmub_srv.c:(.text+0x60c): undefined reference to 
`__floatunsidf'

Unverified Error/Warning (likely false positive, please contact us if 
interested):

arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code 'err'
drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced.
drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but 
dereferenced.
drivers/android/binder.c:353:25-35: ERROR: node -> proc is NULL but 
dereferenced.
drivers/android/binder.c:4888:16-20: ERROR: t is NULL but dereferenced.
drivers/base/regmap/regmap.c:1996:1: internal compiler error: in arc_ifcvt, at 
config/arc/arc.c:9637
drivers/char/random.c:869:1: 

Re: [PATCH] powerpc: e500: Fix compilation with gcc e500 compiler

2022-07-07 Thread Pali Rohár
On Thursday 07 July 2022 09:56:04 Christophe Leroy wrote:
> Le 04/07/2022 à 15:43, Arnd Bergmann a écrit :
> > On Mon, Jul 4, 2022 at 3:29 PM Pali Rohár  wrote:
> >>
> >> And still what to do with 4bf4f42a2feb ("powerpc/kbuild: Set default
> >> generic machine type for 32-bit compile")? I'm somehow lost there...
> > 
> > As far as I can tell, that is not needed, as long as every configuration
> > sets a specific -mcpu= option, the only reason it was required is that
> > there were some configs that relied on the compiler default, which
> > ended up being -mcpu=power8 or similar.
> > 
> 
> 
> Is there any link between this discussion and the following patch 
> submitted 3,5 years ago ?
> 
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20181226141511.3ag7uf6rvdgzl...@decadent.org.uk/
> 
> Thanks
> Christophe

Seems that above patch tried to fix same issue. I did not know about it.


Re: [PATCH] powerpc: e500: Fix compilation with gcc e500 compiler

2022-07-07 Thread Christophe Leroy


Le 04/07/2022 à 15:43, Arnd Bergmann a écrit :
> On Mon, Jul 4, 2022 at 3:29 PM Pali Rohár  wrote:
>>
>> And still what to do with 4bf4f42a2feb ("powerpc/kbuild: Set default
>> generic machine type for 32-bit compile")? I'm somehow lost there...
> 
> As far as I can tell, that is not needed, as long as every configuration
> sets a specific -mcpu= option, the only reason it was required is that
> there were some configs that relied on the compiler default, which
> ended up being -mcpu=power8 or similar.
> 


Is there any link between this discussion and the following patch 
submitted 3,5 years ago ?

https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20181226141511.3ag7uf6rvdgzl...@decadent.org.uk/

Thanks
Christophe

Re: [PATCH] pseries/hotplug: Add more delay in pseries_cpu_die while waiting for rtas-stop

2022-07-07 Thread Christophe Leroy


Le 06/12/2018 à 12:31, Gautham R. Shenoy a écrit :
> From: "Gautham R. Shenoy" 
> 
> Currently running DLPAR offline/online operations in a loop on a
> POWER9 system with SMT=off results in the following crash:
> 
> [  223.321032] cpu 112 (hwid 112) Ready to die...
> [  223.355963] Querying DEAD? cpu 113 (113) shows 2
> [  223.356233] cpu 114 (hwid 114) Ready to die...
> [  223.356236] cpu 113 (hwid 113) Ready to die...
> [  223.356241] Bad kernel stack pointer 1faf6ca0 at 1faf6d50
> [  223.356243] Oops: Bad kernel stack pointer, sig: 6 [#1]
> [  223.356244] LE SMP NR_CPUS=2048 NUMA pSeries
> [  223.356247] Modules linked in:
> [  223.356255] CPU: 114 PID: 0 Comm: swapper/114 Not tainted 4.20.0-rc3 #39
> [  223.356258] NIP:  1faf6d50 LR: 1faf6d50 CTR: 
> 1ec6d06c
> [  223.356259] REGS: c0001e5cbd30 TRAP: 0700   Not tainted  (4.20.0-rc3)
> [  223.356260] MSR:  80081000   CR: 2804  XER: 0020
> [  223.356263] CFAR: 1ec98590 IRQMASK: 80009033
> GPR00: 1faf6d50 1faf6ca0 1ed1c448 
> 0267e6a273c3
> GPR04:  00e0 dfe8 
> 1faf6d30
> GPR08: 1faf6d28 0267e6a273c3 1ec1b108 
> 
> GPR12: 01b6d998 c0001eb55080 c003a1b8bf90 
> 1eea3f40
> GPR16:  c006fda85100 c004c8b0 
> c13d5300
> GPR20: c006fda85300 0008 c19d2cf8 
> c13d6888
> GPR24: 0072 c13d688c 0002 
> c13d688c
> GPR28: c19cecf0 0390  
> 1faf6ca0
> [  223.356281] NIP [1faf6d50] 0x1faf6d50
> [  223.356281] LR [1faf6d50] 0x1faf6d50
> [  223.356282] Call Trace:
> [  223.356283] Instruction dump:
> [  223.356285]        
> 
> [  223.356286]        
> 
> [  223.356290] ---[ end trace f46a4e046b564d1f ]---
> 
> This is due to multiple offlined CPUs (CPU 113 and CPU 114 above)
> concurrently (within 3us) trying to make the rtas-call with the
> "stop-self" token, something that is prohibited by the PAPR.
> 
> The concurrent calls can happen as follows.
> 
>o In dlpar_offline_cpu() we prod an offline CPU X (offline due to
>  SMT=off) and loop for 25 tries in pseries_cpu_die() querying if
>  the target CPU X has been stopped in RTAS. After 25 tries, we
>  prints the message "Querying DEAD? cpu X (X) shows 2" and return
>  to dlpar_offline_cpu(). Note that at this point CPU X has not yet
>  called rtas with the "stop-self" token, but can do so anytime now.
> 
>o Back in dlpar_offline_cpu(), we prod the next offline CPU Y. CPU Y
>  promptly wakes up and calls RTAS with the "stop-self" token.
> 
>o Before RTAS can stop CPU Y, CPU X also calls RTAS with the
>  "stop-self" token.
> 
> The problem occurs due to the short number of tries (25) in
> pseries_cpu_die() which covers 90% of the cases. For the remaining 10%
> of the cases, it was observed that we would need to loop for a few
> hundred iterations before the target CPU calls rtas with "stop-self"
> token.Experiments show that each try takes roughly ~25us.
> 
> In this patch we fix the problem by increasing the number of tries
> from 25 to 4000 (which roughly corresponds to 100ms) before bailing
> out and declaring that we have failed to observe the target CPU call
> rtas-stop-self. This provides sufficient serialization to ensure that
> there no concurrent rtas calls with "stop-self" token.
> 
> Reported-by: Michael Bringmann 
> Signed-off-by: Gautham R. Shenoy 

This patch badly conflicts with 801980f64979 
("powerpc/pseries/hotplug-cpu: wait indefinitely for vCPU death")

Is it still applicable ? If so, please rebase and resubmit.

Thanks
Christophe

> ---
>   arch/powerpc/platforms/pseries/hotplug-cpu.c | 13 -
>   1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c 
> b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index 2f8e621..c913c44 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -214,14 +214,25 @@ static void pseries_cpu_die(unsigned int cpu)
>   msleep(1);
>   }
>   } else if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {
> + int max_tries = 4000; /* Roughly corresponds to 100ms */
> + u64 tb_before = mftb();
>   
> - for (tries = 0; tries < 25; tries++) {
> + for (tries = 0; tries < max_tries; tries++) {
>   cpu_status = smp_query_cpu_stopped(pcpu);
>   if (cpu_status == QCSS_STOPPED ||
>

Re: [PATCH 2/2] powerpc/kexec: avoid hard coding when automatically allocating mem for crashkernel

2022-07-07 Thread Christophe Leroy




Le 31/08/2018 à 09:30, Pingfan Liu a écrit :

If no start address is specified for crashkernel, the current program hard
code as: crashk_res.start = min(0x800ULL, (ppc64_rma_size / 2));
This limits the candidate memory region, and may cause failure while there
is enough mem for crashkernel. This patch suggests to find a suitable mem
chunk by memblock_find_in_range()


Seems like something more or less similar was done with commit 
7c5ed82b800d ("powerpc: Set crashkernel offset to mid of RMA region")


At least your patch conflicts with that commit, so if you think your 
patch is still relevant, please rebase and resubmit your series.


Thanks
Christophe



Signed-off-by: Pingfan Liu 
Cc: Benjamin Herrenschmidt 
Cc: Michael Ellerman 
Cc: Hari Bathini 
Cc: Mahesh Salgaonkar 
Cc: Anton Blanchard 
---
  arch/powerpc/kernel/machine_kexec.c | 24 +++-
  arch/powerpc/kernel/prom.c  |  7 +--
  2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/kernel/machine_kexec.c 
b/arch/powerpc/kernel/machine_kexec.c
index 63f5a93..78005bf 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -22,6 +22,9 @@
  #include 
  #include 
  #include 
+#include 
+
+#include "setup.h"
  
  void machine_kexec_mask_interrupts(void) {

unsigned int i;
@@ -117,6 +120,7 @@ void machine_kexec(struct kimage *image)
  void __init reserve_crashkernel(void)
  {
unsigned long long crash_size, crash_base;
+   phys_addr_t start, up_boundary;
int ret;
  
  	/* use common parsing */

@@ -146,22 +150,24 @@ void __init reserve_crashkernel(void)
  #else
if (!crashk_res.start) {
  #ifdef CONFIG_PPC64
-   /*
-* On 64bit we split the RMO in half but cap it at half of
-* a small SLB (128MB) since the crash kernel needs to place
-* itself and some stacks to be in the first segment.
-*/
-   crashk_res.start = min(0x800ULL, (ppc64_rma_size / 2));
+   up_boundary = min(ppc64_bolted_size(), ppc64_rma_size);
+   start = memblock_find_in_range(KDUMP_KERNELBASE, up_boundary,
+   crash_size, PAGE_SIZE);
+   if (start == 0) {
+   pr_err("Failed to reserve memory for crashkernel!\n");
+   crashk_res.start = crashk_res.end = 0;
+   return;
+   } else
+   crashk_res.start = start;
  #else
crashk_res.start = KDUMP_KERNELBASE;
  #endif
}
  
-	crash_base = PAGE_ALIGN(crashk_res.start);

-   if (crash_base != crashk_res.start) {
+   if (crashk_res.start != PAGE_ALIGN(crashk_res.start)) {
printk("Crash kernel base must be aligned to 0x%lx\n",
PAGE_SIZE);
-   crashk_res.start = crash_base;
+   crashk_res.start = PAGE_ALIGN(crashk_res.start);
}
  
  #endif

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index cae4a78..8b2ab99 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -688,6 +688,7 @@ static void tm_init(void) { }
  void __init early_init_devtree(void *params)
  {
phys_addr_t limit;
+   bool fadump_enabled = false;
  
  	DBG(" -> early_init_devtree(%p)\n", params);
  
@@ -737,9 +738,9 @@ void __init early_init_devtree(void *params)

 * If we fail to reserve memory for firmware-assisted dump then
 * fallback to kexec based kdump.
 */
-   if (fadump_reserve_mem() == 0)
+   if (fadump_reserve_mem() == 1)
+   fadump_enabled = true;
  #endif
-   reserve_crashkernel();
early_reserve_mem();
  
  	/* Ensure that total memory size is page-aligned. */

@@ -761,6 +762,8 @@ void __init early_init_devtree(void *params)
  
  	dt_cpu_ftrs_scan();

mmu_early_init_devtree();
+   if (!fadump_enabled)
+   reserve_crashkernel();
  
  	/* Retrieve CPU related informations from the flat tree

 * (altivec support, boot CPU ID, ...)


Re: [PATCH] powerpc/powernv: Map OPAL msglog in IOREMAP area

2022-07-07 Thread Christophe Leroy

Hi

Le 16/03/2017 à 07:17, Gavin Shan a écrit :

With OPAL msglog driver, there are two interfaces to retrieve the
firmware (skiboot) logs: /sys/firmware/opal/msglog and xmon "do"
command. The memory console header (descritpor) and output buffer
are resident in memory blocks whose addresses are greater than
0x3000. The memory blocks needn't be necessarily visible to
kernel. For example when the memory visible to kernel is limited
by "mem=768M" in bootargs. In this case, reading the memory console
header (descriptor) and its output buffer directly causes kernel
crash as the memory blocks aren't mapped in the linear area as the
driver assumed.

This reworks the driver to map the memory console header (descitpor)
and its output buffer as readonly in IOREMAP area as Michael Ellerman
suggested before. Also, the memory console descriptor are readed into
local descriptor so that we needn't care about its endian (big or little)
afterwards, until we need update the output position when dumping the
messages in the output buffer.

Signed-off-by: Gavin Shan 


This patch badly conflits when applying.

If it's still applicable, could you rebase and resubmit ?

Thanks
Christophe


---
  arch/powerpc/platforms/powernv/opal-msglog.c | 81 ++--
  1 file changed, 54 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-msglog.c 
b/arch/powerpc/platforms/powernv/opal-msglog.c
index 7a9cde0..0f2167f 100644
--- a/arch/powerpc/platforms/powernv/opal-msglog.c
+++ b/arch/powerpc/platforms/powernv/opal-msglog.c
@@ -18,38 +18,46 @@
  
  /* OPAL in-memory console. Defined in OPAL source at core/console.c */

  struct memcons {
-   __be64 magic;
+   unsigned long   magic;
  #define MEMCONS_MAGIC 0x6630696567726173L
-   __be64 obuf_phys;
-   __be64 ibuf_phys;
-   __be32 obuf_size;
-   __be32 ibuf_size;
-   __be32 out_pos;
+   unsigned long   obuf_phys;
+   unsigned long   ibuf_phys;
+   unsigned intobuf_size;
+   unsigned intibuf_size;
+   unsigned intout_pos;
  #define MEMCONS_OUT_POS_WRAP  0x8000u
  #define MEMCONS_OUT_POS_MASK  0x00ffu
-   __be32 in_prod;
-   __be32 in_cons;
+   unsigned intin_prod;
+   unsigned intin_cons;
  };
  
-static struct memcons *opal_memcons = NULL;

+static struct memcons opal_memcons;
+static void __iomem *opal_memcons_virt;
+static void __iomem *opal_memcons_obuf;
+
+#define OPAL_MEMCONS_GET_FIELD(field, accessor, converter, tmp)\
+   tmp = accessor(opal_memcons_virt +  \
+  offsetof(struct memcons, field));\
+   opal_memcons.field = converter(tmp)
  
  ssize_t opal_msglog_copy(char *to, loff_t pos, size_t count)

  {
-   const char *conbuf;
+   char *conbuf;
ssize_t ret;
size_t first_read = 0;
-   uint32_t out_pos, avail;
+   uint32_t out_pos, avail, val32;
  
-	if (!opal_memcons)

+   if (!opal_memcons_obuf)
return -ENODEV;
  
-	out_pos = be32_to_cpu(ACCESS_ONCE(opal_memcons->out_pos));

+   OPAL_MEMCONS_GET_FIELD(out_pos, __raw_readl, be32_to_cpu, val32);
+   out_pos = opal_memcons.out_pos;
  
  	/* Now we've read out_pos, put a barrier in before reading the new

 * data it points to in conbuf. */
smp_rmb();
  
-	conbuf = phys_to_virt(be64_to_cpu(opal_memcons->obuf_phys));

+   conbuf = opal_memcons_obuf;
  
  	/* When the buffer has wrapped, read from the out_pos marker to the end

 * of the buffer, and then read the remaining data as in the un-wrapped
@@ -57,7 +65,7 @@ ssize_t opal_msglog_copy(char *to, loff_t pos, size_t count)
if (out_pos & MEMCONS_OUT_POS_WRAP) {
  
  		out_pos &= MEMCONS_OUT_POS_MASK;

-   avail = be32_to_cpu(opal_memcons->obuf_size) - out_pos;
+   avail = opal_memcons.obuf_size - out_pos;
  
  		ret = memory_read_from_buffer(to, count, ,

conbuf + out_pos, avail);
@@ -75,7 +83,7 @@ ssize_t opal_msglog_copy(char *to, loff_t pos, size_t count)
}
  
  	/* Sanity check. The firmware should not do this to us. */

-   if (out_pos > be32_to_cpu(opal_memcons->obuf_size)) {
+   if (out_pos > opal_memcons.obuf_size) {
pr_err("OPAL: memory console corruption. Aborting read.\n");
return -EINVAL;
}
@@ -104,35 +112,54 @@ static struct bin_attribute opal_msglog_attr = {
  
  void __init opal_msglog_init(void)

  {
-   u64 mcaddr;
-   struct memcons *mc;
+   u64 val64;
+   u32 val32;
  
-	if (of_property_read_u64(opal_node, "ibm,opal-memcons", )) {

+   if (of_property_read_u64(opal_node, "ibm,opal-memcons", )) {
pr_warn("OPAL: Property ibm,opal-memcons not found, no message 
log\n");
return;
}
  
-	mc = phys_to_virt(mcaddr);

-   if (!mc) {
+   opal_memcons_virt = ioremap_prot(val64, sizeof(opal_memcons),
+  

[PATCH] KVM: PPC: Use the arg->size directly for kvm_vm_ioctl_create_spapr_tce

2022-07-07 Thread Deming Wang
Use arg->size directly may be better for code readability.Because, the
variable of size has not been found for special purpose  at present.
Also,We can reduce the use of a variable.

Signed-off-by: Deming Wang 
---
 arch/powerpc/kvm/book3s_64_vio.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index d6589c4fe889..5f74ffb88e82 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -294,14 +294,14 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvmppc_spapr_tce_table *stt = NULL;
struct kvmppc_spapr_tce_table *siter;
struct mm_struct *mm = kvm->mm;
-   unsigned long npages, size = args->size;
+   unsigned long npages;
int ret;
 
if (!args->size || args->page_shift < 12 || args->page_shift > 34 ||
(args->offset + args->size > (ULLONG_MAX >> args->page_shift)))
return -EINVAL;
 
-   npages = kvmppc_tce_pages(size);
+   npages = kvmppc_tce_pages(args->size);
ret = account_locked_vm(mm, kvmppc_stt_pages(npages), true);
if (ret)
return ret;
@@ -314,7 +314,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
stt->liobn = args->liobn;
stt->page_shift = args->page_shift;
stt->offset = args->offset;
-   stt->size = size;
+   stt->size = args->size;
stt->kvm = kvm;
mutex_init(>alloc_lock);
INIT_LIST_HEAD_RCU(>iommu_tables);
-- 
2.27.0



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

2022-07-07 Thread Christophe Leroy


Le 12/06/2022 à 23:34, Uwe Kleine-König a écrit :
> 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.
> 
> This is a preparation for making platform remove callbacks return void.
> 
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 7 +--
>   1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
> b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> index 968f5b727273..b2c24cab4b1e 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> @@ -755,11 +755,6 @@ static int mpc52xx_gpt_probe(struct platform_device 
> *ofdev)
>   return 0;
>   }
>   
> -static int mpc52xx_gpt_remove(struct platform_device *ofdev)
> -{
> - return -EBUSY;
> -}
> -
>   static const struct of_device_id mpc52xx_gpt_match[] = {
>   { .compatible = "fsl,mpc5200-gpt", },
>   
> @@ -772,10 +767,10 @@ static const struct of_device_id mpc52xx_gpt_match[] = {
>   static struct platform_driver mpc52xx_gpt_driver = {
>   .driver = {
>   .name = "mpc52xx-gpt",
> + .suppress_bind_attrs = true,
>   .of_match_table = mpc52xx_gpt_match,
>   },
>   .probe = mpc52xx_gpt_probe,
> - .remove = mpc52xx_gpt_remove,
>   };
>   
>   static int __init mpc52xx_gpt_init(void)
> 
> base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56

Re: [PATCH 3/3] powerpc/platforms/83xx/suspend: Remove write-only global variable

2022-07-07 Thread Christophe Leroy


Le 07/07/2022 à 08:14, Uwe Kleine-König a écrit :
> pmc_dev is only assigned in .probe(), otherwise the variable is unused.
> So drop this pointer that serves no purpose.
> 
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/platforms/83xx/suspend.c | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/83xx/suspend.c 
> b/arch/powerpc/platforms/83xx/suspend.c
> index 309f42ab63d4..3fa8979ac8a6 100644
> --- a/arch/powerpc/platforms/83xx/suspend.c
> +++ b/arch/powerpc/platforms/83xx/suspend.c
> @@ -100,7 +100,6 @@ struct pmc_type {
>   int has_deep_sleep;
>   };
>   
> -static struct platform_device *pmc_dev;
>   static int has_deep_sleep, deep_sleeping;
>   static int pmc_irq;
>   static struct mpc83xx_pmc __iomem *pmc_regs;
> @@ -356,7 +355,6 @@ static int pmc_probe(struct platform_device *ofdev)
>   
>   has_deep_sleep = type->has_deep_sleep;
>   immrbase = get_immrbase();
> - pmc_dev = ofdev;
>   
>   is_pci_agent = mpc83xx_is_pci_agent();
>   if (is_pci_agent < 0)

Re: [PATCH 2/3] powerpc/platforms/83xx/suspend: Prevent unloading the driver

2022-07-07 Thread Christophe Leroy


Le 07/07/2022 à 08:14, Uwe Kleine-König a écrit :
> Returning an error in .remove() doesn't prevent a driver from being
> unloaded. On unbind this only results in an error message, but the
> device is remove anyhow.
> 
> I guess the author's idea of just returning -EPERM in .remove() was to
> prevent unbinding a device. To achieve that set the suppress_bind_attrs
> driver property and drop the useless .remove callback.
> 
> This is a preparation for making platform remove callbacks return void.
> 
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Christophe Leroy 


> ---
>   arch/powerpc/platforms/83xx/suspend.c | 7 +--
>   1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/83xx/suspend.c 
> b/arch/powerpc/platforms/83xx/suspend.c
> index 30b7700a2c98..309f42ab63d4 100644
> --- a/arch/powerpc/platforms/83xx/suspend.c
> +++ b/arch/powerpc/platforms/83xx/suspend.c
> @@ -421,18 +421,13 @@ static int pmc_probe(struct platform_device *ofdev)
>   return ret;
>   }
>   
> -static int pmc_remove(struct platform_device *ofdev)
> -{
> - return -EPERM;
> -};
> -
>   static struct platform_driver pmc_driver = {
>   .driver = {
>   .name = "mpc83xx-pmc",
>   .of_match_table = pmc_match,
> + .suppress_bind_attrs = true,
>   },
>   .probe = pmc_probe,
> - .remove = pmc_remove
>   };
>   
>   builtin_platform_driver(pmc_driver);

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

2022-07-07 Thread Christophe Leroy


Le 07/07/2022 à 08:14, Uwe Kleine-König a écrit :
> By moving up pmc_types and pmc_match, the forward declaration for pmc_match
> can be dropped.
> 
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Christophe Leroy 

> ---
>   arch/powerpc/platforms/83xx/suspend.c | 43 +--
>   1 file changed, 21 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/83xx/suspend.c 
> b/arch/powerpc/platforms/83xx/suspend.c
> index 6d47a5b81485..30b7700a2c98 100644
> --- a/arch/powerpc/platforms/83xx/suspend.c
> +++ b/arch/powerpc/platforms/83xx/suspend.c
> @@ -319,7 +319,27 @@ static const struct platform_suspend_ops 
> mpc83xx_suspend_ops = {
>   .end = mpc83xx_suspend_end,
>   };
>   
> -static const struct of_device_id pmc_match[];
> +static struct pmc_type pmc_types[] = {
> + {
> + .has_deep_sleep = 1,
> + },
> + {
> + .has_deep_sleep = 0,
> + }
> +};
> +
> +static const struct of_device_id pmc_match[] = {
> + {
> + .compatible = "fsl,mpc8313-pmc",
> + .data = _types[0],
> + },
> + {
> + .compatible = "fsl,mpc8349-pmc",
> + .data = _types[1],
> + },
> + {}
> +};
> +
>   static int pmc_probe(struct platform_device *ofdev)
>   {
>   struct device_node *np = ofdev->dev.of_node;
> @@ -406,27 +426,6 @@ static int pmc_remove(struct platform_device *ofdev)
>   return -EPERM;
>   };
>   
> -static struct pmc_type pmc_types[] = {
> - {
> - .has_deep_sleep = 1,
> - },
> - {
> - .has_deep_sleep = 0,
> - }
> -};
> -
> -static const struct of_device_id pmc_match[] = {
> - {
> - .compatible = "fsl,mpc8313-pmc",
> - .data = _types[0],
> - },
> - {
> - .compatible = "fsl,mpc8349-pmc",
> - .data = _types[1],
> - },
> - {}
> -};
> -
>   static struct platform_driver pmc_driver = {
>   .driver = {
>   .name = "mpc83xx-pmc",
> 
> base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56

[PATCH v2] powerpc/code-patching: Speed up page mapping/unmapping on PPC32

2022-07-07 Thread Christophe Leroy
Since commit 591b4b268435 ("powerpc/code-patching: Pre-map patch area")
the patch area is premapped so intermediate page tables are already
allocated.

Use __set_pte_at() directly instead of the heavy map_kernel_page(),
at for unmapping just do a pte_clear() followed by a flush.

__set_pte_at() can be used directly without the filters in
set_pte_at() because we are mapping a normal page non executable.

Make sure gcc knows text_poke_area is page aligned in order to
optimise the flush.

This change reduces by 66% the time needed to activate ftrace on
an 8xx (588000 tb ticks instead of 1744000).

Don't perform the change on PPC64 for now, as it is problematic for
the time being.

Signed-off-by: Christophe Leroy 
---
v2: Only do it on PPC32 for now, mpe reported a problem on PPC64, see 
https://lore.kernel.org/lkml/165261053687.1047019.4165741740473209888.b4...@ellerman.id.au/T/#m9d91e820c43ebe56a72ad89403dac9eb270f5bb6
---
 arch/powerpc/lib/code-patching.c | 37 ++--
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 6edf0697a526..01b9f5dc79d6 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -94,17 +94,20 @@ void __init poking_init(void)
static_branch_enable(_init_done);
 }
 
+static unsigned long get_patch_pfn(void *addr)
+{
+   if (IS_ENABLED(CONFIG_MODULES) && is_vmalloc_or_module_addr(addr))
+   return vmalloc_to_pfn(addr);
+   else
+   return __pa_symbol(addr) >> PAGE_SHIFT;
+}
+
 /*
  * This can be called for kernel text or a module.
  */
 static int map_patch_area(void *addr, unsigned long text_poke_addr)
 {
-   unsigned long pfn;
-
-   if (IS_ENABLED(CONFIG_MODULES) && is_vmalloc_or_module_addr(addr))
-   pfn = vmalloc_to_pfn(addr);
-   else
-   pfn = __pa_symbol(addr) >> PAGE_SHIFT;
+   unsigned long pfn = get_patch_pfn(addr);
 
return map_kernel_page(text_poke_addr, (pfn << PAGE_SHIFT), 
PAGE_KERNEL);
 }
@@ -149,17 +152,29 @@ static int __do_patch_instruction(u32 *addr, ppc_inst_t 
instr)
int err;
u32 *patch_addr;
unsigned long text_poke_addr;
+   pte_t *pte;
+   unsigned long pfn = get_patch_pfn(addr);
 
-   text_poke_addr = (unsigned long)__this_cpu_read(text_poke_area)->addr;
+   text_poke_addr = (unsigned long)__this_cpu_read(text_poke_area)->addr & 
PAGE_MASK;
patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
 
-   err = map_patch_area(addr, text_poke_addr);
-   if (err)
-   return err;
+   if (IS_ENABLED(CONFIG_PPC32)) {
+   pte = virt_to_kpte(text_poke_addr);
+   __set_pte_at(_mm, text_poke_addr, pte, pfn_pte(pfn, 
PAGE_KERNEL), 0);
+   } else {
+   err = map_patch_area(addr, text_poke_addr);
+   if (err)
+   return err;
+   }
 
err = __patch_instruction(addr, instr, patch_addr);
 
-   unmap_patch_area(text_poke_addr);
+   if (IS_ENABLED(CONFIG_PPC32)) {
+   pte_clear(_mm, text_poke_addr, pte);
+   flush_tlb_kernel_range(text_poke_addr, text_poke_addr + 
PAGE_SIZE);
+   } else {
+   unmap_patch_area(text_poke_addr);
+   }
 
return err;
 }
-- 
2.36.1



linux-next: manual merge of the random tree with the powerpc tree

2022-07-07 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the random tree got a conflict in:

  arch/powerpc/Kconfig

between commit:

  cea9d62b64c9 ("powerpc: Kconfig: Replace tabs with whitespaces")

from the powerpc tree and commit:

  a2ff4b7600cd ("random: remove CONFIG_ARCH_RANDOM")

from the random tree.

I fixed it up (the latter removed some lines updated by the former) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpgzQIwTcNF2.pgp
Description: OpenPGP digital signature


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

2022-07-07 Thread Uwe Kleine-König
By moving up pmc_types and pmc_match, the forward declaration for pmc_match
can be dropped.

Signed-off-by: Uwe Kleine-König 
---
 arch/powerpc/platforms/83xx/suspend.c | 43 +--
 1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/suspend.c 
b/arch/powerpc/platforms/83xx/suspend.c
index 6d47a5b81485..30b7700a2c98 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -319,7 +319,27 @@ static const struct platform_suspend_ops 
mpc83xx_suspend_ops = {
.end = mpc83xx_suspend_end,
 };
 
-static const struct of_device_id pmc_match[];
+static struct pmc_type pmc_types[] = {
+   {
+   .has_deep_sleep = 1,
+   },
+   {
+   .has_deep_sleep = 0,
+   }
+};
+
+static const struct of_device_id pmc_match[] = {
+   {
+   .compatible = "fsl,mpc8313-pmc",
+   .data = _types[0],
+   },
+   {
+   .compatible = "fsl,mpc8349-pmc",
+   .data = _types[1],
+   },
+   {}
+};
+
 static int pmc_probe(struct platform_device *ofdev)
 {
struct device_node *np = ofdev->dev.of_node;
@@ -406,27 +426,6 @@ static int pmc_remove(struct platform_device *ofdev)
return -EPERM;
 };
 
-static struct pmc_type pmc_types[] = {
-   {
-   .has_deep_sleep = 1,
-   },
-   {
-   .has_deep_sleep = 0,
-   }
-};
-
-static const struct of_device_id pmc_match[] = {
-   {
-   .compatible = "fsl,mpc8313-pmc",
-   .data = _types[0],
-   },
-   {
-   .compatible = "fsl,mpc8349-pmc",
-   .data = _types[1],
-   },
-   {}
-};
-
 static struct platform_driver pmc_driver = {
.driver = {
.name = "mpc83xx-pmc",

base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56
-- 
2.36.1



[PATCH 3/3] powerpc/platforms/83xx/suspend: Remove write-only global variable

2022-07-07 Thread Uwe Kleine-König
pmc_dev is only assigned in .probe(), otherwise the variable is unused.
So drop this pointer that serves no purpose.

Signed-off-by: Uwe Kleine-König 
---
 arch/powerpc/platforms/83xx/suspend.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/suspend.c 
b/arch/powerpc/platforms/83xx/suspend.c
index 309f42ab63d4..3fa8979ac8a6 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -100,7 +100,6 @@ struct pmc_type {
int has_deep_sleep;
 };
 
-static struct platform_device *pmc_dev;
 static int has_deep_sleep, deep_sleeping;
 static int pmc_irq;
 static struct mpc83xx_pmc __iomem *pmc_regs;
@@ -356,7 +355,6 @@ static int pmc_probe(struct platform_device *ofdev)
 
has_deep_sleep = type->has_deep_sleep;
immrbase = get_immrbase();
-   pmc_dev = ofdev;
 
is_pci_agent = mpc83xx_is_pci_agent();
if (is_pci_agent < 0)
-- 
2.36.1



[PATCH 2/3] powerpc/platforms/83xx/suspend: Prevent unloading the driver

2022-07-07 Thread Uwe Kleine-König
Returning an error in .remove() doesn't prevent a driver from being
unloaded. On unbind this only results in an error message, but the
device is remove anyhow.

I guess the author's idea of just returning -EPERM in .remove() was to
prevent unbinding a device. To achieve that set the suppress_bind_attrs
driver property and drop the useless .remove callback.

This is a preparation for making platform remove callbacks return void.

Signed-off-by: Uwe Kleine-König 
---
 arch/powerpc/platforms/83xx/suspend.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/suspend.c 
b/arch/powerpc/platforms/83xx/suspend.c
index 30b7700a2c98..309f42ab63d4 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -421,18 +421,13 @@ static int pmc_probe(struct platform_device *ofdev)
return ret;
 }
 
-static int pmc_remove(struct platform_device *ofdev)
-{
-   return -EPERM;
-};
-
 static struct platform_driver pmc_driver = {
.driver = {
.name = "mpc83xx-pmc",
.of_match_table = pmc_match,
+   .suppress_bind_attrs = true,
},
.probe = pmc_probe,
-   .remove = pmc_remove
 };
 
 builtin_platform_driver(pmc_driver);
-- 
2.36.1