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

2022-06-01 Thread Alexey Kardashevskiy




On 6/2/22 00:48, Scott Cheloha wrote:

On Wed, May 25, 2022 at 04:35:11PM +1000, Alexey Kardashevskiy wrote:


On 5/21/22 04:35, Scott Cheloha wrote:

PAPR v2.12 defines a new hypercall, H_WATCHDOG.  The hypercall permits
guest control of one or more virtual watchdog timers.  The timers have
millisecond granularity.  The guest is terminated when a timer
expires.

This patch adds a watchdog driver for these timers, "pseries-wdt".

pseries_wdt_probe() currently assumes the existence of only one
platform device and always assigns it watchdogNumber 1.  If we ever
expose more than one timer to userspace we will need to devise a way
to assign a distinct watchdogNumber to each platform device at device
registration time.


This one should go before 4/4 in the series for bisectability.

What is platform_device_register_simple("pseries-wdt",...) going to do
without the driver?


This is a chicken-and-egg problem without an obvious solution.  A
device without a driver is a body without a soul.  A driver without a
device is a ghost without a machine.

... or something like that, don't quote me :)

Absent some very compelling reasoning, I would like to keep the
current order.  It feels logical to me to keep the powerpc/pseries
patches adjacent and prior to the watchdog driver patch.


Signed-off-by: Scott Cheloha 
---
   .../watchdog/watchdog-parameters.rst  |  12 +
   drivers/watchdog/Kconfig  |   8 +
   drivers/watchdog/Makefile |   1 +
   drivers/watchdog/pseries-wdt.c| 337 ++
   4 files changed, 358 insertions(+)
   create mode 100644 drivers/watchdog/pseries-wdt.c

diff --git a/Documentation/watchdog/watchdog-parameters.rst 
b/Documentation/watchdog/watchdog-parameters.rst
index 223c99361a30..4ffe725e796c 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: 1 (power off), 2 (restart),
+   3 (dump and restart). (default=2)
+timeout:
+   Initial watchdog timeout in seconds. (default=60)
+nowayout:
+   Watchdog cannot be stopped once started.
+   (default=kernel config parameter)
+
+-
+
   rc32434_wdt:
   timeout:
Watchdog timeout value, in seconds (default=20)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c4e82a8d863f..06b412603f3e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1932,6 +1932,14 @@ config MEN_A21_WDT
   # PPC64 Architecture
+config PSERIES_WDT
+   tristate "POWER Architecture Platform Watchdog Timer"
+   depends on PPC_PSERIES
+   select WATCHDOG_CORE
+   help
+ Driver for virtual watchdog timers provided by PAPR
+ hypervisors (e.g. PowerVM, KVM).
+
   config WATCHDOG_RTAS
tristate "RTAS watchdog"
depends on PPC_RTAS
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f7da867e8782..f35660409f17 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -184,6 +184,7 @@ obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
   obj-$(CONFIG_MEN_A21_WDT) += mena21_wdt.o
   # PPC64 Architecture
+obj-$(CONFIG_PSERIES_WDT) += pseries-wdt.o
   obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
   # S390 Architecture
diff --git a/drivers/watchdog/pseries-wdt.c b/drivers/watchdog/pseries-wdt.c
new file mode 100644
index ..f41bc4d3b7a2
--- /dev/null
+++ b/drivers/watchdog/pseries-wdt.c
@@ -0,0 +1,337 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022 International Business Machines, Inc.
+ */
+
+#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))
+
+/*
+ * H_WATCHDOG Hypercall Input
+ *
+ * R4: "flags":
+ *
+ * A 64-bit value structured as follows:
+ *
+ * Bits 0-46: Reserved (must be zero).
+ */
+#define PSERIES_WDTF_RESERVED  PPC_BITMASK(0, 46)
+
+/*
+ * Bit 47: "leaveOtherWatchdogsRunningOnTimeout"
+ *
+ * 0  Stop outstanding watchdogs on timeout.
+ * 1  Leave outstanding watchdogs running on timeout.
+ */
+#define PSERIES_WDTF_LEAVE_OTHER   PPC_BIT(47)
+
+/*
+ * Bits 48-55: "operation"
+ *
+ * 0x01  Start Watchdog
+ * 0x02  Stop Watchdog
+ * 0x03  Query Watchdog Capabilities
+ * 0x04  Query 

Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()

2022-06-01 Thread Jordan Niethe
On Thu, Jun 2, 2022 at 2:22 AM Segher Boessenkool
 wrote:
>
> On Wed, Jun 01, 2022 at 08:43:01PM +1000, Michael Ellerman wrote:
> > Segher Boessenkool  writes:
> > > Hi!
> > >
> > > On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
> > >> More problematically it doesn't compile at all with GCC 12, due to the
> > >> fact that it returns the char buffer declared inside the macro:
> > >
> > > It returns a pointer to a buffer on stack.  It is not valid C to access
> > > that buffer after the function has returned (and indeed it does not
> > > work, in general).
> >
> > It's a statement expression though, not a function. So it doesn't return
> > as such, that would be obviously wrong.
>
> Yes, wrong language, my bad.  But luckily it doesn't matter if this is a
> function or not anyway: the question is about scopes and lifetimes :-)
>
> > But I'm not a language lawyer, so presumably it's not valid to refer to
> > the variable after it's gone out of scope.
> >
> > Although we do use that same pattern in many places where the value of
> > the expression is a scalar type.
>
> It's an object with automatic storage duration.  Its lifetime ends when
> the scope is left, which is at the end of the statement expression, so
> before the object is used.
>
> The value of the expression can be used just fine, sure, but the object
> it points to has ceased to exist, so dereferencing that pointer is
> undefined behaviour.
>
> > >> A simpler solution is to just print the value as an unsigned long. For
> > >> normal instructions the output is identical. For prefixed instructions
> > >> the value is printed as a single 64-bit quantity, whereas previously the
> > >> low half was printed first. But that is good enough for debug output,
> > >> especially as prefixed instructions will be rare in practice.
> > >
> > > Prefixed insns might be somewhat rare currently, but it will not stay
> > > that way.
> >
> > These are all printing kernel instructions, not userspace. I should have
> > said that in the change log.
>
> Ah!  In that case, it will take quite a bit longer before you will see
> many prefixed insns, sure.
>
> > The kernel doesn't build for -mcpu=power10 because we haven't done any
> > changes for pcrel.
> >
> > We will do that one day, but not soon.
>
> Yeah, pcrel is the big hitter currently.  But with the extra opcode
> space we have now, maybe something else will show up that even the
> kernel will use.  I cannot predict the future very well :-)
>
> > > It is not hard to fix the problem here?  The only tricky part is that
> > > ppc_inst_as_ulong swaps the two halves for LE, for as far as I can see
> > > no reason at all :-(
> > >
> > > If it didn't it would be easy to detect prefixed insns (because they
> > > then are guaranteed to be > 0x), and it is easy to print them
> > > with a space between the two opcodes, with a utility function:
> > >
> > > void print_insn_bytes_nicely(unsigned long insn)
> > > {
> > > if (insn > 0x)
> > > printf("%08x ", insn >> 32);
> > > printf("%08x", insn & 0x);
> > > }
> >
> > We don't want to do that because it can lead to interleaving messages
> > between different CPUs in the kernel log.
>
> Yuck.
>
> void print_insn_bytes_nicely(unsigned long insn)
> {
> if (insn > 0x)
> printf("%08x ", insn >> 32, insn & 0x);
> else
> printf("%08x", insn & 0x);
> }
>
> But it makes things much less enticing, alright.
>
> > In the medium term there's some changes to printk that might land soon
> > (printbuf), which would mean we could more easily define a custom printk
> > formatter for printing prefixed instructions.
>
> Yeah :-)
>
> What about the more fundamental thing?  Have the order of the two halves
> of a prefixed insn as ulong not depend on endianness?  It really is two
> opcodes, and the prefixed one is first, always, even in LE.
The reason would be the value of as ulong is then used to write a
prefixed instruction to
memory with std.
If both endiannesses had the halves the same one of them would store
the suffix in front of the prefix.
>
>
> Segher


Re: [PATCH v2 2/4] of: dynamic: add of_property_alloc() and of_property_free()

2022-06-01 Thread Tyrel Datwyler
On 6/1/22 01:17, Clément Léger wrote:
> Add function which allows to dynamically allocate and free properties.
> Use this function internally for all code that used the same logic
> (mainly __of_prop_dup()).
> 
> Signed-off-by: Clément Léger 
> ---
>  drivers/of/dynamic.c| 82 -
>  drivers/of/of_private.h | 21 ++-
>  include/linux/of.h  | 14 +++
>  3 files changed, 82 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> index cd3821a6444f..c0dcbea31d28 100644
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -313,9 +313,7 @@ static void property_list_free(struct property *prop_list)
> 
>   for (prop = prop_list; prop != NULL; prop = next) {
>   next = prop->next;
> - kfree(prop->name);
> - kfree(prop->value);
> - kfree(prop);
> + of_property_free(prop);
>   }
>  }
> 
> @@ -367,48 +365,66 @@ void of_node_release(struct kobject *kobj)
>  }
> 
>  /**
> - * __of_prop_dup - Copy a property dynamically.
> - * @prop:Property to copy
> + * of_property_free - Free a property allocated dynamically.
> + * @prop:Property to be freed
> + */
> +void of_property_free(const struct property *prop)
> +{
> + if (!of_property_check_flag(prop, OF_DYNAMIC))
> + return;
> +

This looks wrong to me. From what I understand the value data is allocated as
trailing memory that is part of the property allocation itself. (ie. prop =
kzalloc(sizeof(*prop) + len, allocflags)). So, kfree(prop) should also take care
of the trailing value data. Calling kfree(prop->value) is bogus since
prop->value wasn't dynamically allocated on its own.

Also, this condition will always fail. You explicitly set prop->value = prop + 1
in alloc.

Maybe I need to go back and look at v1 again.

-Tyrel

> + if (prop->value != prop + 1)
> + kfree(prop->value);
> +
> + kfree(prop->name);
> + kfree(prop);
> +}
> +EXPORT_SYMBOL(of_property_free);
> +
> +/**
> + * of_property_alloc - Allocate a property dynamically.
> + * @name:Name of the new property
> + * @value:   Value that will be copied into the new property value or NULL
> + *   if only @len allocation is needed.
> + * @len: Length of new property value and if @value is provided, the
> + *   length of the value to be copied
>   * @allocflags:  Allocation flags (typically pass GFP_KERNEL)
>   *
> - * Copy a property by dynamically allocating the memory of both the
> + * Create a property by dynamically allocating the memory of both the
>   * property structure and the property name & contents. The property's
>   * flags have the OF_DYNAMIC bit set so that we can differentiate between
>   * dynamically allocated properties and not.
>   *
>   * Return: The newly allocated property or NULL on out of memory error.
>   */
> -struct property *__of_prop_dup(const struct property *prop, gfp_t allocflags)
> +struct property *of_property_alloc(const char *name, const void *value,
> +size_t len, gfp_t allocflags)
>  {
> - struct property *new;
> + struct property *prop;
> 
> - new = kzalloc(sizeof(*new), allocflags);
> - if (!new)
> + prop = kzalloc(sizeof(*prop) + len, allocflags);
> + if (!prop)
>   return NULL;
> 
> - /*
> -  * NOTE: There is no check for zero length value.
> -  * In case of a boolean property, this will allocate a value
> -  * of zero bytes. We do this to work around the use
> -  * of of_get_property() calls on boolean values.
> -  */
> - new->name = kstrdup(prop->name, allocflags);
> - new->value = kmemdup(prop->value, prop->length, allocflags);
> - new->length = prop->length;
> - if (!new->name || !new->value)
> - goto err_free;
> -
> - /* mark the property as dynamic */
> - of_property_set_flag(new, OF_DYNAMIC);
> -
> - return new;
> -
> - err_free:
> - kfree(new->name);
> - kfree(new->value);
> - kfree(new);
> + prop->name = kstrdup(name, allocflags);
> + if (!prop->name)
> + goto out_err;
> +
> + prop->value = prop + 1;
> + if (value)
> + memcpy(prop->value, value, len);
> +
> + prop->length = len;
> + of_property_set_flag(prop, OF_DYNAMIC);
> +
> + return prop;
> +
> +out_err:
> + of_property_free(prop);
> +
>   return NULL;
>  }
> +EXPORT_SYMBOL(of_property_alloc);
> 
>  /**
>   * __of_node_dup() - Duplicate or create an empty device node dynamically.
> @@ -447,9 +463,7 @@ struct device_node *__of_node_dup(const struct 
> device_node *np,
>   if (!new_pp)
>   goto err_prop;
>   if (__of_add_property(node, new_pp)) {
> - kfree(new_pp->name);
> - kfree(new_pp->value);
> - kfree(new_pp);
> +  

Re: [PATCH 1/3] of: dynamic: add of_property_alloc() and of_property_free()

2022-06-01 Thread Tyrel Datwyler
On 5/5/22 12:37, Rob Herring wrote:
> On Wed, May 04, 2022 at 05:40:31PM +0200, Clément Léger wrote:
>> Add function which allows to dynamically allocate and free properties.
>> Use this function internally for all code that used the same logic
>> (mainly __of_prop_dup()).
>>
>> Signed-off-by: Clément Léger 
>> ---
>>  drivers/of/dynamic.c | 101 ++-
>>  include/linux/of.h   |  16 +++
>>  2 files changed, 88 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
>> index cd3821a6444f..e8700e509d2e 100644
>> --- a/drivers/of/dynamic.c
>> +++ b/drivers/of/dynamic.c
>> @@ -313,9 +313,7 @@ static void property_list_free(struct property 
>> *prop_list)
>>  
>>  for (prop = prop_list; prop != NULL; prop = next) {
>>  next = prop->next;
>> -kfree(prop->name);
>> -kfree(prop->value);
>> -kfree(prop);
>> +of_property_free(prop);
>>  }
>>  }
>>  
>> @@ -367,48 +365,95 @@ void of_node_release(struct kobject *kobj)
>>  }
>>  
>>  /**
>> - * __of_prop_dup - Copy a property dynamically.
>> - * @prop:   Property to copy
>> + * of_property_free - Free a property allocated dynamically.
>> + * @prop:   Property to be freed
>> + */
>> +void of_property_free(const struct property *prop)
>> +{
>> +kfree(prop->value);
>> +kfree(prop->name);
>> +kfree(prop);
>> +}
>> +EXPORT_SYMBOL(of_property_free);
>> +
>> +/**
>> + * of_property_alloc - Allocate a property dynamically.
>> + * @name:   Name of the new property
>> + * @value:  Value that will be copied into the new property value
>> + * @value_len:  length of @value to be copied into the new property 
>> value
>> + * @len:Length of new property value, must be greater than @value_len
> 
> What's the usecase for the lengths being different? That doesn't seem 
> like a common case, so perhaps handle it with a NULL value and 
> non-zero length. Then the caller has to deal with populating 
> prop->value.
> 
>>   * @allocflags: Allocation flags (typically pass GFP_KERNEL)
>>   *
>> - * Copy a property by dynamically allocating the memory of both the
>> + * Create a property by dynamically allocating the memory of both the
>>   * property structure and the property name & contents. The property's
>>   * flags have the OF_DYNAMIC bit set so that we can differentiate between
>>   * dynamically allocated properties and not.
>>   *
>>   * Return: The newly allocated property or NULL on out of memory error.
>>   */
>> -struct property *__of_prop_dup(const struct property *prop, gfp_t 
>> allocflags)
>> +struct property *of_property_alloc(const char *name, const void *value,
>> +   int value_len, int len, gfp_t allocflags)
>>  {
>> -struct property *new;
>> +int alloc_len = len;
>> +struct property *prop;
>> +
>> +if (len < value_len)
>> +return NULL;
>>  
>> -new = kzalloc(sizeof(*new), allocflags);
>> -if (!new)
>> +prop = kzalloc(sizeof(*prop), allocflags);
>> +if (!prop)
>>  return NULL;
>>  
>> +prop->name = kstrdup(name, allocflags);
>> +if (!prop->name)
>> +goto out_err;
>> +
>>  /*
>> - * NOTE: There is no check for zero length value.
>> - * In case of a boolean property, this will allocate a value
>> - * of zero bytes. We do this to work around the use
>> - * of of_get_property() calls on boolean values.
>> + * Even if the property has no value, it must be set to a
>> + * non-null value since of_get_property() is used to check
>> + * some values that might or not have a values (ranges for
>> + * instance). Moreover, when the node is released, prop->value
>> + * is kfreed so the memory must come from kmalloc.
> 
> Allowing for NULL value didn't turn out well...
> 
> We know that we can do the kfree because OF_DYNAMIC is set IIRC...
> 
> If we do 1 allocation for prop and value, then we can test 
> for "prop->value == prop + 1" to determine if we need to free or not.

If its a single allocation do we even need a test? Doesn't kfree(prop) take care
of the property and the trailing memory allocated for the value?

-Tyrel

> 
>>   */
>> -new->name = kstrdup(prop->name, allocflags);
>> -new->value = kmemdup(prop->value, prop->length, allocflags);
>> -new->length = prop->length;
>> -if (!new->name || !new->value)
>> -goto err_free;
>> +if (!alloc_len)
>> +alloc_len = 1;
>>  
>> -/* mark the property as dynamic */
>> -of_property_set_flag(new, OF_DYNAMIC);
>> +prop->value = kzalloc(alloc_len, allocflags);
>> +if (!prop->value)
>> +goto out_err;
>>  
>> -return new;
>> +if (value)
>> +memcpy(prop->value, value, value_len);
>> +
>> +prop->length = len;
>> +of_property_set_flag(prop, OF_DYNAMIC);
>> +
>> +return prop;
>> +
>> +out_err:
>> +of_property_free(prop);
>>  

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

2022-06-01 Thread Nathan Chancellor
On Wed, Jun 01, 2022 at 08:21:41PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 01, 2022 at 11:11:57AM -0700, Nathan Chancellor wrote:
> > On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote:
> > > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> > > > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote:
> > > > > Can you send me the full dmesg and the content of
> > > > > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
> > > > 
> > > > Sure thing, they are attached! If there is anything else I can provide
> > > > or test, I am more than happy to do so.
> > > 
> > > Nothing interesting.  But the performance numbers almost look like
> > > swiotlb=force got ignored before (even if I can't explain why).
> > 
> > I was able to get my performance back with this diff but I don't know if
> > this is a hack or a proper fix in the context of the series.
> 
> This looks good, but needs a little tweak.  I'd go for this variant of
> it:

Tested-by: Nathan Chancellor 

Thanks a lot for the quick fix!

> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index dfa1de89dc944..cb50f8d383606 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -192,7 +192,7 @@ void __init swiotlb_update_mem_attributes(void)
>  }
>  
>  static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t 
> start,
> - unsigned long nslabs, bool late_alloc)
> + unsigned long nslabs, unsigned int flags, bool late_alloc)
>  {
>   void *vaddr = phys_to_virt(start);
>   unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> @@ -203,8 +203,7 @@ static void swiotlb_init_io_tlb_mem(struct io_tlb_mem 
> *mem, phys_addr_t start,
>   mem->index = 0;
>   mem->late_alloc = late_alloc;
>  
> - if (swiotlb_force_bounce)
> - mem->force_bounce = true;
> + mem->force_bounce = swiotlb_force_bounce || (flags & SWIOTLB_FORCE);
>  
>   spin_lock_init(>lock);
>   for (i = 0; i < mem->nslabs; i++) {
> @@ -275,8 +274,7 @@ void __init swiotlb_init_remap(bool addressing_limit, 
> unsigned int flags,
>   panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
>  
> - swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
> - mem->force_bounce = flags & SWIOTLB_FORCE;
> + swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, flags, false);
>  
>   if (flags & SWIOTLB_VERBOSE)
>   swiotlb_print_info();
> @@ -348,7 +346,7 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
>  
>   set_memory_decrypted((unsigned long)vstart,
>(nslabs << IO_TLB_SHIFT) >> PAGE_SHIFT);
> - swiotlb_init_io_tlb_mem(mem, virt_to_phys(vstart), nslabs, true);
> + swiotlb_init_io_tlb_mem(mem, virt_to_phys(vstart), nslabs, 0, true);
>  
>   swiotlb_print_info();
>   return 0;
> @@ -835,8 +833,8 @@ static int rmem_swiotlb_device_init(struct reserved_mem 
> *rmem,
>  
>   set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
>rmem->size >> PAGE_SHIFT);
> - swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
> - mem->force_bounce = true;
> + swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, SWIOTLB_FORCE,
> + false);
>   mem->for_alloc = true;
>  
>   rmem->priv = mem;
> 

Cheers,
Nathan


[PATCH 0/3] asm-generic: fix misconversion of {uid,gid}_t

2022-06-01 Thread Masahiro Yamada
I accidentally broke android binder.h:
  https://lore.kernel.org/all/20220601010017.2639048-1-cmlla...@google.com/

I checked my previous conversions, and found some more.
(at least, the sparc one seems fatal.)



Masahiro Yamada (3):
  mips: use __kernel_{uid,gid}32_t in uapi/asm/stat.h
  powerpc: use __kernel_{uid,gid}32_t in uapi/asm/stat.h
  sparc: fix mis-use of __kernel_{uid,gid}_t in uapi/asm/stat.h

 arch/mips/include/uapi/asm/stat.h| 12 ++--
 arch/powerpc/include/uapi/asm/stat.h |  4 ++--
 arch/sparc/include/uapi/asm/stat.h   |  4 ++--
 3 files changed, 10 insertions(+), 10 deletions(-)

-- 
2.32.0



Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

2022-06-01 Thread Christoph Hellwig
On Wed, Jun 01, 2022 at 11:11:57AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote:
> > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> > > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote:
> > > > Can you send me the full dmesg and the content of
> > > > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
> > > 
> > > Sure thing, they are attached! If there is anything else I can provide
> > > or test, I am more than happy to do so.
> > 
> > Nothing interesting.  But the performance numbers almost look like
> > swiotlb=force got ignored before (even if I can't explain why).
> 
> I was able to get my performance back with this diff but I don't know if
> this is a hack or a proper fix in the context of the series.

This looks good, but needs a little tweak.  I'd go for this variant of
it:


diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index dfa1de89dc944..cb50f8d383606 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -192,7 +192,7 @@ void __init swiotlb_update_mem_attributes(void)
 }
 
 static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start,
-   unsigned long nslabs, bool late_alloc)
+   unsigned long nslabs, unsigned int flags, bool late_alloc)
 {
void *vaddr = phys_to_virt(start);
unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
@@ -203,8 +203,7 @@ static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, 
phys_addr_t start,
mem->index = 0;
mem->late_alloc = late_alloc;
 
-   if (swiotlb_force_bounce)
-   mem->force_bounce = true;
+   mem->force_bounce = swiotlb_force_bounce || (flags & SWIOTLB_FORCE);
 
spin_lock_init(>lock);
for (i = 0; i < mem->nslabs; i++) {
@@ -275,8 +274,7 @@ void __init swiotlb_init_remap(bool addressing_limit, 
unsigned int flags,
panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
  __func__, alloc_size, PAGE_SIZE);
 
-   swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
-   mem->force_bounce = flags & SWIOTLB_FORCE;
+   swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, flags, false);
 
if (flags & SWIOTLB_VERBOSE)
swiotlb_print_info();
@@ -348,7 +346,7 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
 
set_memory_decrypted((unsigned long)vstart,
 (nslabs << IO_TLB_SHIFT) >> PAGE_SHIFT);
-   swiotlb_init_io_tlb_mem(mem, virt_to_phys(vstart), nslabs, true);
+   swiotlb_init_io_tlb_mem(mem, virt_to_phys(vstart), nslabs, 0, true);
 
swiotlb_print_info();
return 0;
@@ -835,8 +833,8 @@ static int rmem_swiotlb_device_init(struct reserved_mem 
*rmem,
 
set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
 rmem->size >> PAGE_SHIFT);
-   swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
-   mem->force_bounce = true;
+   swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, SWIOTLB_FORCE,
+   false);
mem->for_alloc = true;
 
rmem->priv = mem;



[PATCH 2/3] powerpc: use __kernel_{uid,gid}32_t in uapi/asm/stat.h

2022-06-01 Thread Masahiro Yamada
Commit c01013a2f8dd ("powerpc: add asm/stat.h to UAPI compile-test
coverage") converted as follows:

  uid_t  -->  __kernel_uid_t
  gid_t  -->  __kernel_gid_t

The bit width of __kernel_{uid,gid}_t is 16 or 32-bits depending on
architectures.

PPC uses 32-bits for them as in include/uapi/asm-generic/posix_types.h,
so the previous conversion is probably fine, but let's stick to the
arch-independent conversion just in case.

The safe replacements across all architectures are:

  uid_t  -->  __kernel_uid32_t
  gid_t  -->  __kernel_gid32_t

as defined in include/linux/types.h.

A similar issue was reported for the android binder. [1]

[1]: https://lore.kernel.org/all/20220601010017.2639048-1-cmlla...@google.com/

Fixes: c01013a2f8dd ("powerpc: add asm/stat.h to UAPI compile-test coverage")
Signed-off-by: Masahiro Yamada 
---

 arch/powerpc/include/uapi/asm/stat.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/uapi/asm/stat.h 
b/arch/powerpc/include/uapi/asm/stat.h
index a28c9a1201fa..d50901664239 100644
--- a/arch/powerpc/include/uapi/asm/stat.h
+++ b/arch/powerpc/include/uapi/asm/stat.h
@@ -37,8 +37,8 @@ struct stat {
__kernel_mode_t st_mode;
unsigned short  st_nlink;
 #endif
-   __kernel_uid_t  st_uid;
-   __kernel_gid_t  st_gid;
+   __kernel_uid32_t st_uid;
+   __kernel_gid32_t st_gid;
unsigned long   st_rdev;
longst_size;
unsigned long   st_blksize;
-- 
2.32.0



Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

2022-06-01 Thread Nathan Chancellor
On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote:
> > > Can you send me the full dmesg and the content of
> > > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
> > 
> > Sure thing, they are attached! If there is anything else I can provide
> > or test, I am more than happy to do so.
> 
> Nothing interesting.  But the performance numbers almost look like
> swiotlb=force got ignored before (even if I can't explain why).

I was able to get my performance back with this diff but I don't know if
this is a hack or a proper fix in the context of the series.

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index dfa1de89dc94..0bfb2fe3d8c5 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -276,7 +276,7 @@ void __init swiotlb_init_remap(bool addressing_limit, 
unsigned int flags,
  __func__, alloc_size, PAGE_SIZE);
 
swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
-   mem->force_bounce = flags & SWIOTLB_FORCE;
+   mem->force_bounce = swiotlb_force_bounce || (flags & SWIOTLB_FORCE);
 
if (flags & SWIOTLB_VERBOSE)
swiotlb_print_info();

> Do you get a similar performance with the new kernel without
> swiotlb=force as the old one with that argument by any chance?

I'll see if I can test that, as I am not sure I have control over those
cmdline arguments.

Cheers,
Nathan


Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

2022-06-01 Thread Christoph Hellwig
On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote:
> > Can you send me the full dmesg and the content of
> > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
> 
> Sure thing, they are attached! If there is anything else I can provide
> or test, I am more than happy to do so.

Nothing interesting.  But the performance numbers almost look like
swiotlb=force got ignored before (even if I can't explain why).
Do you get a similar performance with the new kernel without
swiotlb=force as the old one with that argument by any chance?



Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

2022-06-01 Thread Nathan Chancellor
On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote:
> Can you send me the full dmesg and the content of
> /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?

Sure thing, they are attached! If there is anything else I can provide
or test, I am more than happy to do so.

Cheers,
Nathan
# cat /sys/kernel/debug/swiotlb/io_tlb_nslabs
32768

# dmesg
[0.00] Linux version 
5.18.0-rc3-microsoft-standard-WSL2-8-ga3e230926708 
(nathan@dev-arch.thelio-3990X) (gcc (GCC) 12.1.0, GNU ld (GNU Binutils) 2.38) 
#1 SMP PREEMPT_DYNAMIC Wed Jun 1 10:38:34 MST 2022
[0.00] Command line: initrd=\initrd.img panic=-1 nr_cpus=8 
swiotlb=force earlycon=uart8250,io,0x3f8,115200 console=hvc0 debug 
pty.legacy_count=0
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'compacted' format.
[0.00] signal: max sigframe size: 1776
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x000e-0x000e0fff] reserved
[0.00] BIOS-e820: [mem 0x0010-0x001f] ACPI data
[0.00] BIOS-e820: [mem 0x0020-0xf7ff] usable
[0.00] BIOS-e820: [mem 0x0001-0x000407ff] usable
[0.00] earlycon: uart8250 at I/O port 0x3f8 (options '115200')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] NX (Execute Disable) protection: active
[0.00] DMI not present or invalid.
[0.00] Hypervisor detected: Microsoft Hyper-V
[0.00] Hyper-V: privilege flags low 0xae7f, high 0x3b8030, hints 0xc2c, 
misc 0xe0bed7b6
[0.00] Hyper-V: Host Build 10.0.22000.708-0-0
[0.00] Hyper-V: Nested features: 0x4a
[0.00] Hyper-V: LAPIC Timer Frequency: 0x1e8480
[0.00] Hyper-V: Using hypercall for remote TLB flush
[0.00] clocksource: hyperv_clocksource_tsc_page: mask: 
0x max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[0.05] tsc: Detected 3800.008 MHz processor
[0.001901] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.004593] e820: remove [mem 0x000a-0x000f] usable
[0.006806] last_pfn = 0x408000 max_arch_pfn = 0x4
[0.009042] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.011760] last_pfn = 0xf8000 max_arch_pfn = 0x4
[0.013959] Using GB pages for direct mapping
[0.015749] RAMDISK: [mem 0x0371f000-0x03779fff]
[0.017616] ACPI: Early table checksum verification disabled
[0.019854] ACPI: RSDP 0x000E 24 (v02 VRTUAL)
[0.022162] ACPI: XSDT 0x0010 44 (v01 VRTUAL MICROSFT 
0001 MSFT 0001)
[0.025624] ACPI: FACP 0x00101000 000114 (v06 VRTUAL MICROSFT 
0001 MSFT 0001)
[0.029022] ACPI: DSDT 0x001011B8 01E184 (v02 MSFTVM DSDT01   
0001 MSFT 0500)
[0.032413] ACPI: FACS 0x00101114 40
[0.034280] ACPI: OEM0 0x00101154 64 (v01 VRTUAL MICROSFT 
0001 MSFT 0001)
[0.037699] ACPI: SRAT 0x0011F33C 000330 (v02 VRTUAL MICROSFT 
0001 MSFT 0001)
[0.041089] ACPI: APIC 0x0011F66C 88 (v04 VRTUAL MICROSFT 
0001 MSFT 0001)
[0.044475] ACPI: Reserving FACP table memory at [mem 0x101000-0x101113]
[0.047159] ACPI: Reserving DSDT table memory at [mem 0x1011b8-0x11f33b]
[0.049905] ACPI: Reserving FACS table memory at [mem 0x101114-0x101153]
[0.052693] ACPI: Reserving OEM0 table memory at [mem 0x101154-0x1011b7]
[0.055404] ACPI: Reserving SRAT table memory at [mem 0x11f33c-0x11f66b]
[0.058040] ACPI: Reserving APIC table memory at [mem 0x11f66c-0x11f6f3]
[0.061078] Zone ranges:
[0.062074]   DMA  [mem 0x1000-0x00ff]
[0.066106]   DMA32[mem 0x0100-0x]
[0.068763]   Normal   [mem 0x0001-0x000407ff]
[0.071235]   Device   empty
[0.072384] Movable zone start for each node
[0.074058] Early memory node ranges
[0.075515]   node   0: [mem 0x1000-0x0009]
[0.077979]   node   0: [mem 0x0020-0xf7ff]
[0.080483]   node   0: [mem 0x0001-0x000407ff]
[0.082980] Initmem setup node 0 [mem 0x1000-0x000407ff]
[0.085954] On node 0, zone DMA: 1 pages in unavailable ranges
[0.085972] On node 0, zone DMA: 352 

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

2022-06-01 Thread Christoph Hellwig
Can you send me the full dmesg and the content of
/sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?

Thanks!


Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

2022-06-01 Thread Nathan Chancellor
Hi Christoph,

On Mon, Apr 04, 2022 at 07:05:53AM +0200, Christoph Hellwig wrote:
> Pass a bool to pass if swiotlb needs to be enabled based on the
> addressing needs and replace the verbose argument with a set of
> flags, including one to force enable bounce buffering.
> 
> Note that this patch removes the possibility to force xen-swiotlb
> use using swiotlb=force on the command line on x86 (arm and arm64
> never supported that), but this interface will be restored shortly.
> 
> Signed-off-by: Christoph Hellwig 

I bisected a performance regression in WSL2 to this change as commit
c6af2aa9ffc9 ("swiotlb: make the swiotlb_init interface more useful") in
mainline (bisect log below). I initially noticed it because accessing the
Windows filesystem through the /mnt/c mount is about 40x slower if I am doing
my math right based on the benchmarks below.

Before:

$ uname -r; and hyperfine "ls -l /mnt/c/Users/natec/Downloads"
5.18.0-rc3-microsoft-standard-WSL2-8-ga3e230926708
Benchmark 1: ls -l /mnt/c/Users/natec/Downloads
  Time (mean ± σ): 564.5 ms ±  24.1 ms[User: 2.5 ms, System: 130.3 ms]
  Range (min … max):   510.2 ms … 588.0 ms10 runs

After

$ uname -r; and hyperfine "ls -l /mnt/c/Users/natec/Downloads"
5.18.0-rc3-microsoft-standard-WSL2-9-gc6af2aa9ffc9
Benchmark 1: ls -l /mnt/c/Users/natec/Downloads
  Time (mean ± σ): 23.282 s ±  1.220 s[User: 0.013 s, System: 0.101 s]
  Range (min … max):   21.793 s … 25.317 s10 runs

I do see 'swiotlb=force' on the cmdline:

$ cat /proc/cmdline
initrd=\initrd.img panic=-1 nr_cpus=8 swiotlb=force 
earlycon=uart8250,io,0x3f8,115200 console=hvc0 debug pty.legacy_count=0

/mnt/c appears to be a 9p mount, not sure if that is relevant here:

$ mount &| grep /mnt/c
drvfs on /mnt/c type 9p 
(rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=262144,trans=virtio)

If there is any other information I can provide, please let me know.

Cheers,
Nathan

# bad: [700170bf6b4d773e328fa54ebb70ba444007c702] Merge tag 'nfs-for-5.19-1' of 
git://git.linux-nfs.org/projects/anna/linux-nfs
# good: [4b0986a3613c92f4ec1bdc7f60ec66fea135991f] Linux 5.18
git bisect start '700170bf6b4d773e328fa54ebb70ba444007c702' 'v5.18'
# good: [86c87bea6b42100c67418af690919c44de6ede6e] Merge tag 
'devicetree-for-5.19' of 
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
git bisect good 86c87bea6b42100c67418af690919c44de6ede6e
# bad: [ae862183285cbb2ef9032770d98ffa9becffe9d5] Merge tag 'arm-dt-5.19' of 
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect bad ae862183285cbb2ef9032770d98ffa9becffe9d5
# good: [2518f226c60d8e04d18ba4295500a5b0b8ac7659] Merge tag 
'drm-next-2022-05-25' of git://anongit.freedesktop.org/drm/drm
git bisect good 2518f226c60d8e04d18ba4295500a5b0b8ac7659
# bad: [babf0bb978e3c9fce6c4eba6b744c8754fd43d8e] Merge tag 
'xfs-5.19-for-linus' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect bad babf0bb978e3c9fce6c4eba6b744c8754fd43d8e
# good: [beed983621fbdfd291e6e3a0cdc4d10517e60af8] ASoC: Intel: avs: Machine 
board registration
git bisect good beed983621fbdfd291e6e3a0cdc4d10517e60af8
# good: [fbe86daca0ba878b04fa241b85e26e54d17d4229] Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect good fbe86daca0ba878b04fa241b85e26e54d17d4229
# good: [166afc45ed5523298541fd0297f9ad585cc2708c] Merge tag 
'reflink-speedups-5.19_2022-04-28' of 
git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into 
xfs-5.19-for-next
git bisect good 166afc45ed5523298541fd0297f9ad585cc2708c
# bad: [e375780b631a5fc2a61a3b4fa12429255361a31e] Merge tag 
'fsnotify_for_v5.19-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect bad e375780b631a5fc2a61a3b4fa12429255361a31e
# bad: [4a37f3dd9a83186cb88d44808ab35b78375082c9] dma-direct: don't 
over-decrypt memory
git bisect bad 4a37f3dd9a83186cb88d44808ab35b78375082c9
# bad: [742519538e6b07250c8085bbff4bd358bc03bf16] swiotlb: pass a gfp_mask 
argument to swiotlb_init_late
git bisect bad 742519538e6b07250c8085bbff4bd358bc03bf16
# good: [9bbe7a7fc126e3d14fefa4b035854aba080926d9] arm/xen: don't check for 
xen_initial_domain() in xen_create_contiguous_region
git bisect good 9bbe7a7fc126e3d14fefa4b035854aba080926d9
# good: [a3e230926708125205ffd06d3dc2175a8263ae7e] x86: centralize setting 
SWIOTLB_FORCE when guest memory encryption is enabled
git bisect good a3e230926708125205ffd06d3dc2175a8263ae7e
# bad: [8ba2ed1be90fc210126f68186564707478552c95] swiotlb: add a SWIOTLB_ANY 
flag to lift the low memory restriction
git bisect bad 8ba2ed1be90fc210126f68186564707478552c95
# bad: [c6af2aa9ffc9763826607bc2664ef3ea4475ed18] swiotlb: make the 
swiotlb_init interface more useful
git bisect bad c6af2aa9ffc9763826607bc2664ef3ea4475ed18
# first bad commit: [c6af2aa9ffc9763826607bc2664ef3ea4475ed18] swiotlb: make 
the swiotlb_init interface more useful


Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()

2022-06-01 Thread Segher Boessenkool
On Wed, Jun 01, 2022 at 08:43:01PM +1000, Michael Ellerman wrote:
> Segher Boessenkool  writes:
> > Hi!
> >
> > On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
> >> More problematically it doesn't compile at all with GCC 12, due to the
> >> fact that it returns the char buffer declared inside the macro:
> >
> > It returns a pointer to a buffer on stack.  It is not valid C to access
> > that buffer after the function has returned (and indeed it does not
> > work, in general).
> 
> It's a statement expression though, not a function. So it doesn't return
> as such, that would be obviously wrong.

Yes, wrong language, my bad.  But luckily it doesn't matter if this is a
function or not anyway: the question is about scopes and lifetimes :-)

> But I'm not a language lawyer, so presumably it's not valid to refer to
> the variable after it's gone out of scope.
> 
> Although we do use that same pattern in many places where the value of
> the expression is a scalar type.

It's an object with automatic storage duration.  Its lifetime ends when
the scope is left, which is at the end of the statement expression, so
before the object is used.

The value of the expression can be used just fine, sure, but the object
it points to has ceased to exist, so dereferencing that pointer is
undefined behaviour.

> >> A simpler solution is to just print the value as an unsigned long. For
> >> normal instructions the output is identical. For prefixed instructions
> >> the value is printed as a single 64-bit quantity, whereas previously the
> >> low half was printed first. But that is good enough for debug output,
> >> especially as prefixed instructions will be rare in practice.
> >
> > Prefixed insns might be somewhat rare currently, but it will not stay
> > that way.
> 
> These are all printing kernel instructions, not userspace. I should have
> said that in the change log.

Ah!  In that case, it will take quite a bit longer before you will see
many prefixed insns, sure.

> The kernel doesn't build for -mcpu=power10 because we haven't done any
> changes for pcrel.
> 
> We will do that one day, but not soon.

Yeah, pcrel is the big hitter currently.  But with the extra opcode
space we have now, maybe something else will show up that even the
kernel will use.  I cannot predict the future very well :-)

> > It is not hard to fix the problem here?  The only tricky part is that
> > ppc_inst_as_ulong swaps the two halves for LE, for as far as I can see
> > no reason at all :-(
> >
> > If it didn't it would be easy to detect prefixed insns (because they
> > then are guaranteed to be > 0x), and it is easy to print them
> > with a space between the two opcodes, with a utility function:
> >
> > void print_insn_bytes_nicely(unsigned long insn)
> > {
> > if (insn > 0x)
> > printf("%08x ", insn >> 32);
> > printf("%08x", insn & 0x);
> > }
> 
> We don't want to do that because it can lead to interleaving messages
> between different CPUs in the kernel log.

Yuck.

void print_insn_bytes_nicely(unsigned long insn)
{
if (insn > 0x)
printf("%08x ", insn >> 32, insn & 0x);
else
printf("%08x", insn & 0x);
}

But it makes things much less enticing, alright.

> In the medium term there's some changes to printk that might land soon
> (printbuf), which would mean we could more easily define a custom printk
> formatter for printing prefixed instructions.

Yeah :-)

What about the more fundamental thing?  Have the order of the two halves
of a prefixed insn as ulong not depend on endianness?  It really is two
opcodes, and the prefixed one is first, always, even in LE.


Segher


Re: [PATCH 1/6] powerpc: Add ZERO_GPRS macros for register clears

2022-06-01 Thread Segher Boessenkool
Hi!

On Wed, Jun 01, 2022 at 03:48:45PM +1000, Rohan McLure wrote:
> +.macro BINOP_REGS op, rhs, start, end
> + .Lreg=\start
> + .rept (\end - \start + 1)
> + \op .Lreg, \rhs
> + .Lreg=.Lreg+1
> + .endr
> +.endm

This is for unary operations, not binary operations (there is only one
item on the RHS).  You can in principle put a string "a,b" in the rhs
parameter, but in practice you need a or b to depend on the loop counter
as well, so even such trickiness won't do.  Make the naming less
confusing, maybe?  Or don't have an unused extra level of abstraction in
the first place :-)


Segher


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

2022-06-01 Thread Scott Cheloha
On Wed, Jun 01, 2022 at 08:45:03AM -0700, Guenter Roeck wrote:
> On 6/1/22 08:07, Scott Cheloha wrote:
> [ ... ]
> > > > > +static unsigned long action = PSERIES_WDTF_ACTION_HARD_RESTART;
> > > > > +
> > > > > +static int action_get(char *buf, const struct kernel_param *kp)
> > > > > +{
> > > > > +    int val;
> > > > > +
> > > > > +    switch (action) {
> > > > > +    case PSERIES_WDTF_ACTION_HARD_POWEROFF:
> > > > > +    val = 1;
> > > > > +    break;
> > > > > +    case PSERIES_WDTF_ACTION_HARD_RESTART:
> > > > > +    val = 2;
> > > > > +    break;
> > > > > +    case PSERIES_WDTF_ACTION_DUMP_RESTART:
> > > > > +    val = 3;
> > > > > +    break;
> > > > > +    default:
> > > > > +    return -EINVAL;
> > > > > +    }
> > > > > +    return sprintf(buf, "%d\n", val);
> > > > > +}
> > > > > +
> > > > > +static int action_set(const char *val, const struct kernel_param *kp)
> > > > > +{
> > > > > +    int choice;
> > > > > +
> > > > > +    if (kstrtoint(val, 10, ))
> > > > > +    return -EINVAL;
> > > > > +    switch (choice) {
> > > > > +    case 1:
> > > > > +    action = PSERIES_WDTF_ACTION_HARD_POWEROFF;
> > > > > +    return 0;
> > > > > +    case 2:
> > > > > +    action = PSERIES_WDTF_ACTION_HARD_RESTART;
> > > > > +    return 0;
> > > > > +    case 3:
> > > > > +    action = PSERIES_WDTF_ACTION_DUMP_RESTART;
> > > > > +    return 0;
> > > > > +    }
> > > > > +    return -EINVAL;
> > > > > +}
> > > > > +
> > > > > +static const struct kernel_param_ops action_ops = {
> > > > > +    .get = action_get,
> > > > > +    .set = action_set,
> > > > > +};
> > > > > +module_param_cb(action, _ops, NULL, 0444);
> > > > 
> > > > 
> > > > 0644 here and below?
> > > > 
> > > 
> > > That would make the module parameters have to be runtime
> > > configurable, which does not make sense at least for
> > > the two parameters below.
> > 
> > Agreed.
> > 
> > > I don't know though if it is really valuable to have all the
> > > above code instead of just
> > > storing the action numbers and doing the conversion to action
> > > once in the probe function. The above code really only
> > > makes sense if the action is changeable during runtime and more
> > > is done that just converting it to another value.
> > 
> > Having a setter that runs exactly once during module attach is
> > obvious.  We need a corresponding .get() method to convert on the way
> > out anyway.
> > 
> 
> Why would a get method be needed if the module parameter is just kept as-is ?

In my original plan they weren't kept as-is.  They were converted on
the way in and on the way out.

> > I don't see any upside to moving the action_set() code into
> > pseries_wdt_probe() aside from maybe shaving a few SLOC.  The module
> > is already very compact.
> 
> I disagree. The get method is unnecessary. The module parameter values (1..3)
> add unnecessary complexity. It could as well be 0..2, making it easier to 
> convert.

Yes, we could do that.

> The actual action could be stored in struct pseries_wdt, or converted using 
> something
> like
> 
> u8 pseries_actions[] = {
>   PSERIES_WDTF_ACTION_HARD_POWEROFF,
>   PSERIES_WDTF_ACTION_HARD_RESTART,
>   PSERIES_WDTF_ACTION_DUMP_RESTART
> };
> 
>   flags = pseries_actions[action] | PSERIES_WDTF_OP_START;
> 
> or, alternatively, in probe
> 
>   if (action > 2)
>   return -EINVAL;
>   pw->action = pseries_actions[action];
> and, in the start function,
>   flags = pw->action | PSERIES_WDTF_OP_START;

I like this, we'll go with this.

> That not only reduces code size but also improves readability.
> get/set methods are useful, but should be limited to cases where they
> are really needed, ie do something besides converting values. You could argue
> that you want to be able to change the reboot method on the fly, by making
> the module parameter writeable, but then the .set method should actually
> change the method accordingly and not just convert values. And even then
> I'd argue that it would be better not to convert the 'action' value itself
> but to keep it at 0, 1, 2 (or 1, 2, 3 if you prefer) and use param_get_uint
> (or param_get_ulong) for the get method.

Okay, that makes sense.

> Regarding max_timeout, we have calculations such as
> 
>   unsigned int t = wdd->timeout * 1000;
> 
> in the assumption that timeouts larger than UINT_MAX/1000 seconds (or ~50 
> days)
> don't really make much sense. watchdog_timeout_invalid() will also return 
> -EINVAL
> if the provided timeout value is larger than UINT_MAX / 1000.

Oh, I see.  Changed in v2.


Re: [PATCH] powerpc/kasan: Force thread size increase with KASAN

2022-06-01 Thread Christophe Leroy


Le 01/06/2022 à 16:31, Michael Ellerman a écrit :
> KASAN causes increased stack usage, which can lead to stack overflows.
> 
> The logic in Kconfig to suggest a larger default doesn't work if a user
> has CONFIG_EXPERT enabled and has an existing .config with a smaller
> value.
> 
> Follow the lead of x86 and arm64, and force the thread size to be
> increased when KASAN is enabled.
> 
> That also has the effect of enlarging the stack for 64-bit KASAN builds,
> which is also desirable.
> 
> Fixes: edbadaf06710 ("powerpc/kasan: Fix stack overflow by increasing 
> THREAD_SHIFT")
> Reported-by: Erhard Furtner 
> Reported-by: Christophe Leroy 
> Signed-off-by: Michael Ellerman 
> ---
>   arch/powerpc/Kconfig   | 1 -
>   arch/powerpc/include/asm/thread_info.h | 9 +++--
>   2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 54dbbb1d4b36..b1760d615bb7 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -790,7 +790,6 @@ config THREAD_SHIFT
>   range 13 15
>   default "15" if PPC_256K_PAGES
>   default "14" if PPC64
> - default "14" if KASAN
>   default "13"
>   help
> Used to define the stack size. The default is almost always what you
> diff --git a/arch/powerpc/include/asm/thread_info.h 
> b/arch/powerpc/include/asm/thread_info.h
> index 125328d1b980..c9735f93f8e6 100644
> --- a/arch/powerpc/include/asm/thread_info.h
> +++ b/arch/powerpc/include/asm/thread_info.h
> @@ -14,12 +14,17 @@
>   
>   #ifdef __KERNEL__
>   
> -#if defined(CONFIG_VMAP_STACK) && CONFIG_THREAD_SHIFT < PAGE_SHIFT
> -#define THREAD_SHIFT PAGE_SHIFT
> +#ifdef CONFIG_KASAN
> +#define THREAD_SHIFT (CONFIG_THREAD_SHIFT + 1)
>   #else
>   #define THREAD_SHIFTCONFIG_THREAD_SHIFT
>   #endif
>   
> +#if defined(CONFIG_VMAP_STACK) && THREAD_SHIFT < PAGE_SHIFT
> +#undef THREAD_SHIFT

I dislike this undef.

I would was done

#ifdef CONFIG_KASAN
#define MIN_THREAD_SHIFT(CONFIG_THREAD_SHIFT + 1)
#else
#define MIN_THREAD_SHIFTCONFIG_THREAD_SHIFT
#endif

#if defined(CONFIG_VMAP_STACK) && MIN_THREAD_SHIFT < PAGE_SHIFT
#define THREAD_SHIFTPAGE_SHIFT
#else
#define THREAD_SHIFTMIN_THREAD_SHIFT
#endif


> +#define THREAD_SHIFT PAGE_SHIFT
> +#endif
> +
>   #define THREAD_SIZE (1 << THREAD_SHIFT)
>   
>   /*

[PATCH 0/2] Disabling NMI watchdog during LPM's memory transfer

2022-06-01 Thread Laurent Dufour
When a partition is transferred, once it arrives at the destination node,
the partition is active but much of its memory must be transferred from the
start node.

It depends on the activity in the partition, but the more CPU the partition
has, the more memory to be transferred is likely to be. This causes latency
when accessing pages that need to be transferred, and often, for large
partitions, it triggers the NMI watchdog.

The NMI watchdog causes the CPU stack to dump where it appears to be
stuck. In this case, it does not bring much information since it can happen
during any memory access of the kernel.

In addition, the NMI interrupt mechanism is not secure and can generate a
dump system in the event that the interruption is taken while MSR[RI]=0.

Given how often hard lockups are detected when transferring large
partitions, it seems best to disable the watchdog NMI until the memory
transfer from the start node is complete.

The first patch in this series waits for the memory transfer to complete,
the second disables the watchdog NMI just before stopping the CPUs and
reactivates it when the memory transfer is complete.

Laurent Dufour (2):
  powerpc/mobility: Wait for memory transfer to complete
  powerpc/mobility: disabling hard lockup watchdog during LPM

 arch/powerpc/platforms/pseries/mobility.c | 40 +--
 1 file changed, 38 insertions(+), 2 deletions(-)

-- 
2.36.1



[PATCH 2/2] powerpc/mobility: disabling hard lockup watchdog during LPM

2022-06-01 Thread Laurent Dufour
Disabling the Hard Lockup Watchdog until the memory transfer is complete.

This avoids hard lockup seen while the memory is still in progress when the
system is heavily loaded and a lot of pages are still not transferred on
the arrival side.

Signed-off-by: Laurent Dufour 
---
 arch/powerpc/platforms/pseries/mobility.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/platforms/pseries/mobility.c 
b/arch/powerpc/platforms/pseries/mobility.c
index 55612a1b07d6..061d4faefefb 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -701,6 +701,9 @@ static int pseries_migrate_partition(u64 handle)
 
vas_migration_handler(VAS_SUSPEND);
 
+   pr_debug("Disabling the NMI watchdog\n");
+   watchdog_nmi_stop();
+
ret = pseries_suspend(handle);
if (ret == 0) {
post_mobility_fixup();
@@ -708,6 +711,9 @@ static int pseries_migrate_partition(u64 handle)
} else
pseries_cancel_migration(handle, ret);
 
+   pr_debug("Enabling the NMI watchdog again\n");
+   watchdog_nmi_start();
+
vas_migration_handler(VAS_RESUME);
 
return ret;
-- 
2.36.1



[PATCH 1/2] powerpc/mobility: Wait for memory transfer to complete

2022-06-01 Thread Laurent Dufour
In pseries_migration_partition(), loop until the memory transfer is
complete. This way the calling drmgr process will not exit earlier,
allowing callbacks to be run only once the migration is fully completed.

This will also allow to manage the NMI watchdog state in the next commits.

Signed-off-by: Laurent Dufour 
---
 arch/powerpc/platforms/pseries/mobility.c | 34 +--
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/mobility.c 
b/arch/powerpc/platforms/pseries/mobility.c
index 78f3f74c7056..55612a1b07d6 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -427,6 +427,35 @@ static int wait_for_vasi_session_suspending(u64 handle)
return ret;
 }
 
+static void wait_for_vasi_session_completed(u64 handle)
+{
+   unsigned long state = 0;
+   int ret;
+
+   pr_info("waiting for memory transfert to complete...\n");
+   /*
+* Wait for transition from H_VASI_RESUMED to
+* H_VASI_COMPLETED. Treat anything else as an error.
+*/
+   while (true) {
+   ret = poll_vasi_state(handle, );
+
+   if (ret || state == H_VASI_COMPLETED)
+   break;
+
+   if (state != H_VASI_RESUMED) {
+   pr_err("unexpected H_VASI_STATE result %lu\n", state);
+   ret = -EIO;
+   break;
+   }
+
+   msleep(500);
+   }
+
+   pr_info("memory transfert completed (ret:%d state:%ld).\n",
+   ret, state);
+}
+
 static void prod_single(unsigned int target_cpu)
 {
long hvrc;
@@ -673,9 +702,10 @@ static int pseries_migrate_partition(u64 handle)
vas_migration_handler(VAS_SUSPEND);
 
ret = pseries_suspend(handle);
-   if (ret == 0)
+   if (ret == 0) {
post_mobility_fixup();
-   else
+   wait_for_vasi_session_completed(handle);
+   } else
pseries_cancel_migration(handle, ret);
 
vas_migration_handler(VAS_RESUME);
-- 
2.36.1



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

2022-06-01 Thread Guenter Roeck

On 6/1/22 08:07, Scott Cheloha wrote:
[ ... ]

+static unsigned long action = PSERIES_WDTF_ACTION_HARD_RESTART;
+
+static int action_get(char *buf, const struct kernel_param *kp)
+{
+    int val;
+
+    switch (action) {
+    case PSERIES_WDTF_ACTION_HARD_POWEROFF:
+    val = 1;
+    break;
+    case PSERIES_WDTF_ACTION_HARD_RESTART:
+    val = 2;
+    break;
+    case PSERIES_WDTF_ACTION_DUMP_RESTART:
+    val = 3;
+    break;
+    default:
+    return -EINVAL;
+    }
+    return sprintf(buf, "%d\n", val);
+}
+
+static int action_set(const char *val, const struct kernel_param *kp)
+{
+    int choice;
+
+    if (kstrtoint(val, 10, ))
+    return -EINVAL;
+    switch (choice) {
+    case 1:
+    action = PSERIES_WDTF_ACTION_HARD_POWEROFF;
+    return 0;
+    case 2:
+    action = PSERIES_WDTF_ACTION_HARD_RESTART;
+    return 0;
+    case 3:
+    action = PSERIES_WDTF_ACTION_DUMP_RESTART;
+    return 0;
+    }
+    return -EINVAL;
+}
+
+static const struct kernel_param_ops action_ops = {
+    .get = action_get,
+    .set = action_set,
+};
+module_param_cb(action, _ops, NULL, 0444);



0644 here and below?



That would make the module parameters have to be runtime
configurable, which does not make sense at least for
the two parameters below.


Agreed.


I don't know though if it is really valuable to have all the
above code instead of just
storing the action numbers and doing the conversion to action
once in the probe function. The above code really only
makes sense if the action is changeable during runtime and more
is done that just converting it to another value.


Having a setter that runs exactly once during module attach is
obvious.  We need a corresponding .get() method to convert on the way
out anyway.



Why would a get method be needed if the module parameter is just kept as-is ?


I don't see any upside to moving the action_set() code into
pseries_wdt_probe() aside from maybe shaving a few SLOC.  The module
is already very compact.



I disagree. The get method is unnecessary. The module parameter values (1..3)
add unnecessary complexity. It could as well be 0..2, making it easier to 
convert.
The actual action could be stored in struct pseries_wdt, or converted using 
something
like

u8 pseries_actions[] = {
PSERIES_WDTF_ACTION_HARD_POWEROFF,
PSERIES_WDTF_ACTION_HARD_RESTART,
PSERIES_WDTF_ACTION_DUMP_RESTART
};

flags = pseries_actions[action] | PSERIES_WDTF_OP_START;

or, alternatively, in probe

if (action > 2)
return -EINVAL;
pw->action = pseries_actions[action];
and, in the start function,
flags = pw->action | PSERIES_WDTF_OP_START;

That not only reduces code size but also improves readability.
get/set methods are useful, but should be limited to cases where they
are really needed, ie do something besides converting values. You could argue
that you want to be able to change the reboot method on the fly, by making
the module parameter writeable, but then the .set method should actually
change the method accordingly and not just convert values. And even then
I'd argue that it would be better not to convert the 'action' value itself
but to keep it at 0, 1, 2 (or 1, 2, 3 if you prefer) and use param_get_uint
(or param_get_ulong) for the get method.

Regarding max_timeout, we have calculations such as

unsigned int t = wdd->timeout * 1000;

in the assumption that timeouts larger than UINT_MAX/1000 seconds (or ~50 days)
don't really make much sense. watchdog_timeout_invalid() will also return 
-EINVAL
if the provided timeout value is larger than UINT_MAX / 1000.

Guenter


Re: [PATCH] powerpc/irq: Increase stack_overflow detection limit when KASAN is enabled

2022-06-01 Thread Christophe Leroy


Le 31/05/2022 à 08:21, Michael Ellerman a écrit :
> Christophe Leroy  writes:
>> When KASAN is enabled, as shown by the Oops below, the 2k limit is not
>> enough to allow stack dump after a stack overflow detection when
>> CONFIG_DEBUG_STACKOVERFLOW is selected:
>>
>>  do_IRQ: stack overflow: 1984
>>  CPU: 0 PID: 126 Comm: systemd-udevd Not tainted 5.18.0-gentoo-PMacG4 #1
>>  Call Trace:
>>  Oops: Kernel stack overflow, sig: 11 [#1]
>>  BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
>>  Modules linked in: sr_mod cdrom radeon(+) ohci_pci(+) hwmon 
>> i2c_algo_bit drm_ttm_helper ttm drm_dp_helper snd_aoa_i2sbus 
>> snd_aoa_soundbus snd_pcm ehci_pci snd_timer ohci_hcd snd ssb ehci_hcd 
>> 8250_pci soundcore drm_kms_helper pcmcia 8250 pcmcia_core syscopyarea 
>> usbcore sysfillrect 8250_base sysimgblt serial_mctrl_gpio fb_sys_fops 
>> usb_common pkcs8_key_parser fuse drm drm_panel_orientation_quirks configfs
>>  CPU: 0 PID: 126 Comm: systemd-udevd Not tainted 5.18.0-gentoo-PMacG4 #1
>>  NIP:  c02e5558 LR: c07eb3bc CTR: c07f46a8
>>  REGS: e7fe9f50 TRAP:    Not tainted  (5.18.0-gentoo-PMacG4)
>>  MSR:  1032   CR: 44a14824  XER: 2000
>>
>>  GPR00: c07eb3bc eaa1c000 c26baea0 eaa1c0a0 0008  c07eb3bc 
>> eaa1c010
>>  GPR08: eaa1c0a8 04f3f3f3 f1f1f1f1 c07f4c84 44a14824 0080f7e4 0005 
>> 0010
>>  GPR16: 0025 eaa1c154 eaa1c158 c0dbad64 0020 fd543810 eaa1c0a0 
>> eaa1c29e
>>  GPR24: c0dbad44 c0db8740 05ff fd543802 eaa1c150 c0c9a3c0 eaa1c0a0 
>> c0c9a3c0
>>  NIP [c02e5558] kasan_check_range+0xc/0x2b4
>>  LR [c07eb3bc] format_decode+0x80/0x604
>>  Call Trace:
>>  [eaa1c000] [c07eb3bc] format_decode+0x80/0x604 (unreliable)
>>  [eaa1c070] [c07f4dac] vsnprintf+0x128/0x938
>>  [eaa1c110] [c07f5788] sprintf+0xa0/0xc0
>>  [eaa1c180] [c0154c1c] __sprint_symbol.constprop.0+0x170/0x198
>>  [eaa1c230] [c07ee71c] symbol_string+0xf8/0x260
>>  [eaa1c430] [c07f46d0] pointer+0x15c/0x710
>>  [eaa1c4b0] [c07f4fbc] vsnprintf+0x338/0x938
>>  [eaa1c550] [c00e8fa0] vprintk_store+0x2a8/0x678
>>  [eaa1c690] [c00e94e4] vprintk_emit+0x174/0x378
>>  [eaa1c6d0] [c00ea008] _printk+0x9c/0xc0
>>  [eaa1c750] [c000ca94] show_stack+0x21c/0x260
>>  [eaa1c7a0] [c07d0bd4] dump_stack_lvl+0x60/0x90
>>  [eaa1c7c0] [c0009234] __do_IRQ+0x170/0x174
>>  [eaa1c800] [c0009258] do_IRQ+0x20/0x34
>>  [eaa1c820] [c00045b4] HardwareInterrupt_virt+0x108/0x10c
> 
> Is this actually caused by KASAN? There's no stack frames in there that
> are KASAN related AFAICS.
> 
> Seems like the 2K limit is never going to be enough even if KASAN is not
> enabled. Presumably we just haven't noticed because we don't trigger the
> check unless KASAN is enabled.

I made some test on PPC32.

Without KASAN, I can call dump_stack() until the stack has at least 1120
  bytes available on stack.

With KASAN I can call dump_stack() until the stack has at least 2096 
bytes available on stack.

> 
>> ...
>>
>> Increase the limit to 3k when KASAN is enabled.
>>
>> While at it remove the 'inline' keywork for check_stack_overflow().
>> This function is called only once so it will be inlined regardless.
> 
> I'd rather that was a separate change, in case it has some unintended
> affect.
> 
>> Reported-by: Erhard Furtner 
>> Cc: Arnd Bergmann 
>> Signed-off-by: Christophe Leroy 
>> ---
>>   arch/powerpc/kernel/irq.c | 16 ++--
>>   1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
>> index 873e6dffb868..5ff4cf69fc2f 100644
>> --- a/arch/powerpc/kernel/irq.c
>> +++ b/arch/powerpc/kernel/irq.c
>> @@ -53,6 +53,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   
>>   #include 
>>   #include 
>> @@ -184,7 +185,7 @@ u64 arch_irq_stat_cpu(unsigned int cpu)
>>  return sum;
>>   }
>>   
>> -static inline void check_stack_overflow(void)
>> +static void check_stack_overflow(void)
>>   {
>>  long sp;
>>   
>> @@ -193,11 +194,14 @@ static inline void check_stack_overflow(void)
>>
> 
> Wouldn't it be cleaner to just do:
> 
> #ifdef CONFIG_KASAN
> #define STACK_CHECK_LIMIT (3 * 1024)
> #else
> #define STACK_CHECK_LIMIT (2 * 1024)
> #endif
> 
>>  sp = current_stack_pointer & (THREAD_SIZE - 1);
>>   
>> -/* check for stack overflow: is there less than 2KB free? */
>> -if (unlikely(sp < 2048)) {
>   
> + if (unlikely(sp < STACK_CHECK_LIMIT)) {
>   
> And then the code could stay as it is?
> 
> cheers
> 
>> -pr_err("do_IRQ: stack overflow: %ld\n", sp);
>> -dump_stack();
>> -}
>> +/* check for stack overflow: is there less than 2/3KB free? */
>> +if (!IS_ENABLED(KASAN) && likely(sp >= SZ_2K))
>> +return;
>> +if (IS_ENABLED(KASAN) && likely(sp >= SZ_2K + SZ_1K))
>> +return;
>> +
>> +pr_err("do_IRQ: stack overflow: %ld\n", sp);
>> +dump_stack();
>>   }

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

2022-06-01 Thread Scott Cheloha
On Wed, May 25, 2022 at 12:52:09AM -0700, Guenter Roeck wrote:
> On 5/24/22 23:35, Alexey Kardashevskiy wrote:
> > 
> > On 5/21/22 04:35, Scott Cheloha wrote:
> > > PAPR v2.12 defines a new hypercall, H_WATCHDOG.  The hypercall permits
> > > guest control of one or more virtual watchdog timers.  The timers have
> > > millisecond granularity.  The guest is terminated when a timer
> > > expires.
> > > 
> > > This patch adds a watchdog driver for these timers, "pseries-wdt".
> > > 
> > > pseries_wdt_probe() currently assumes the existence of only one
> > > platform device and always assigns it watchdogNumber 1.  If we ever
> > > expose more than one timer to userspace we will need to devise a way
> > > to assign a distinct watchdogNumber to each platform device at device
> > > registration time.
> > 
> > This one should go before 4/4 in the series for bisectability.
> > 
> > What is platform_device_register_simple("pseries-wdt",...) going to do 
> > without the driver?
> > 
> > > 
> > > Signed-off-by: Scott Cheloha 
> > > ---
> > >   .../watchdog/watchdog-parameters.rst  |  12 +
> > >   drivers/watchdog/Kconfig  |   8 +
> > >   drivers/watchdog/Makefile |   1 +
> > >   drivers/watchdog/pseries-wdt.c    | 337 ++
> > >   4 files changed, 358 insertions(+)
> > >   create mode 100644 drivers/watchdog/pseries-wdt.c
> > > 
> > > diff --git a/Documentation/watchdog/watchdog-parameters.rst 
> > > b/Documentation/watchdog/watchdog-parameters.rst
> > > index 223c99361a30..4ffe725e796c 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: 1 (power off), 2 (restart),
> > > +    3 (dump and restart). (default=2)
> > > +    timeout:
> > > +    Initial watchdog timeout in seconds. (default=60)
> > > +    nowayout:
> > > +    Watchdog cannot be stopped once started.
> > > +    (default=kernel config parameter)
> > > +
> > > +-
> > > +
> > >   rc32434_wdt:
> > >   timeout:
> > >   Watchdog timeout value, in seconds (default=20)
> > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > > index c4e82a8d863f..06b412603f3e 100644
> > > --- a/drivers/watchdog/Kconfig
> > > +++ b/drivers/watchdog/Kconfig
> > > @@ -1932,6 +1932,14 @@ config MEN_A21_WDT
> > >   # PPC64 Architecture
> > > +config PSERIES_WDT
> > > +    tristate "POWER Architecture Platform Watchdog Timer"
> > > +    depends on PPC_PSERIES
> > > +    select WATCHDOG_CORE
> > > +    help
> > > +  Driver for virtual watchdog timers provided by PAPR
> > > +  hypervisors (e.g. PowerVM, KVM).
> > > +
> > >   config WATCHDOG_RTAS
> > >   tristate "RTAS watchdog"
> > >   depends on PPC_RTAS
> > > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > > index f7da867e8782..f35660409f17 100644
> > > --- a/drivers/watchdog/Makefile
> > > +++ b/drivers/watchdog/Makefile
> > > @@ -184,6 +184,7 @@ obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
> > >   obj-$(CONFIG_MEN_A21_WDT) += mena21_wdt.o
> > >   # PPC64 Architecture
> > > +obj-$(CONFIG_PSERIES_WDT) += pseries-wdt.o
> > >   obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
> > >   # S390 Architecture
> > > diff --git a/drivers/watchdog/pseries-wdt.c 
> > > b/drivers/watchdog/pseries-wdt.c
> > > new file mode 100644
> > > index ..f41bc4d3b7a2
> > > --- /dev/null
> > > +++ b/drivers/watchdog/pseries-wdt.c
> > > @@ -0,0 +1,337 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (c) 2022 International Business Machines, Inc.
> > > + */
> > > +
> > > +#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))
> > > +
> > > +/*
> > > + * H_WATCHDOG Hypercall Input
> > > + *
> > > + * R4: "flags":
> > > + *
> > > + * A 64-bit value structured as follows:
> > > + *
> > > + * Bits 0-46: Reserved (must be zero).
> > > + */
> > > +#define PSERIES_WDTF_RESERVED    PPC_BITMASK(0, 46)
> > > +
> > > +/*
> > > + * Bit 47: "leaveOtherWatchdogsRunningOnTimeout"
> > > + *
> > > + * 0  Stop outstanding watchdogs on timeout.
> > > + * 1  Leave 

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

2022-06-01 Thread Scott Cheloha
On Wed, May 25, 2022 at 04:35:11PM +1000, Alexey Kardashevskiy wrote:
> 
> On 5/21/22 04:35, Scott Cheloha wrote:
> > PAPR v2.12 defines a new hypercall, H_WATCHDOG.  The hypercall permits
> > guest control of one or more virtual watchdog timers.  The timers have
> > millisecond granularity.  The guest is terminated when a timer
> > expires.
> > 
> > This patch adds a watchdog driver for these timers, "pseries-wdt".
> > 
> > pseries_wdt_probe() currently assumes the existence of only one
> > platform device and always assigns it watchdogNumber 1.  If we ever
> > expose more than one timer to userspace we will need to devise a way
> > to assign a distinct watchdogNumber to each platform device at device
> > registration time.
> 
> This one should go before 4/4 in the series for bisectability.
> 
> What is platform_device_register_simple("pseries-wdt",...) going to do
> without the driver?

This is a chicken-and-egg problem without an obvious solution.  A
device without a driver is a body without a soul.  A driver without a
device is a ghost without a machine.

... or something like that, don't quote me :)

Absent some very compelling reasoning, I would like to keep the
current order.  It feels logical to me to keep the powerpc/pseries
patches adjacent and prior to the watchdog driver patch.

> > Signed-off-by: Scott Cheloha 
> > ---
> >   .../watchdog/watchdog-parameters.rst  |  12 +
> >   drivers/watchdog/Kconfig  |   8 +
> >   drivers/watchdog/Makefile |   1 +
> >   drivers/watchdog/pseries-wdt.c| 337 ++
> >   4 files changed, 358 insertions(+)
> >   create mode 100644 drivers/watchdog/pseries-wdt.c
> > 
> > diff --git a/Documentation/watchdog/watchdog-parameters.rst 
> > b/Documentation/watchdog/watchdog-parameters.rst
> > index 223c99361a30..4ffe725e796c 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: 1 (power off), 2 (restart),
> > +   3 (dump and restart). (default=2)
> > +timeout:
> > +   Initial watchdog timeout in seconds. (default=60)
> > +nowayout:
> > +   Watchdog cannot be stopped once started.
> > +   (default=kernel config parameter)
> > +
> > +-
> > +
> >   rc32434_wdt:
> >   timeout:
> > Watchdog timeout value, in seconds (default=20)
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index c4e82a8d863f..06b412603f3e 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -1932,6 +1932,14 @@ config MEN_A21_WDT
> >   # PPC64 Architecture
> > +config PSERIES_WDT
> > +   tristate "POWER Architecture Platform Watchdog Timer"
> > +   depends on PPC_PSERIES
> > +   select WATCHDOG_CORE
> > +   help
> > + Driver for virtual watchdog timers provided by PAPR
> > + hypervisors (e.g. PowerVM, KVM).
> > +
> >   config WATCHDOG_RTAS
> > tristate "RTAS watchdog"
> > depends on PPC_RTAS
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index f7da867e8782..f35660409f17 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -184,6 +184,7 @@ obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
> >   obj-$(CONFIG_MEN_A21_WDT) += mena21_wdt.o
> >   # PPC64 Architecture
> > +obj-$(CONFIG_PSERIES_WDT) += pseries-wdt.o
> >   obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
> >   # S390 Architecture
> > diff --git a/drivers/watchdog/pseries-wdt.c b/drivers/watchdog/pseries-wdt.c
> > new file mode 100644
> > index ..f41bc4d3b7a2
> > --- /dev/null
> > +++ b/drivers/watchdog/pseries-wdt.c
> > @@ -0,0 +1,337 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2022 International Business Machines, Inc.
> > + */
> > +
> > +#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))
> > +
> > +/*
> > + * H_WATCHDOG Hypercall Input
> > + *
> > + * R4: "flags":
> > + *
> > + * A 64-bit value structured as follows:
> > + *
> > + * Bits 0-46: Reserved (must be zero).
> > + */
> > +#define PSERIES_WDTF_RESERVED  PPC_BITMASK(0, 46)
> > +
> > +/*
> > + * Bit 47: "leaveOtherWatchdogsRunningOnTimeout"
> > + *
> > + *

Re: [PATCH 2/6] powerpc: Provide syscall wrapper

2022-06-01 Thread Christophe Leroy


Le 01/06/2022 à 07:48, Rohan McLure a écrit :
> [Vous ne recevez pas souvent de courriers de la part de 
> rmcl...@linux.ibm.com. Découvrez pourquoi cela peut être important à 
> l'adresse https://aka.ms/LearnAboutSenderIdentification.]
> 
> Syscall wrapper implemented as per s390, x86, arm64, providing the
> option for gprs to be cleared on entry to the kernel, reducing caller
> influence influence on speculation within syscall routine. The wrapper
> is a macro that emits syscall handler implementations with parameters
> passed by stack pointer.
> 
> For platforms supporting this syscall wrapper, emit symbols with usual
> in-register parameters (`sys...`) to support calls to syscall handlers
> from within the kernel.
> 
> Syscalls are wrapped on all platforms except Cell processor. SPUs require
> access syscall prototypes which are omitted with ARCH_HAS_SYSCALL_WRAPPER
> enabled.
> 

Also wondering why I get duplicated syscall functions. Shouldn't the 
sys_ ones go away once we implement the __powerpc_sys_ ones ?

c001e9a0 :
c001e9a0:   94 21 ff b0 stwur1,-80(r1)
c001e9a4:   7c 08 02 a6 mflrr0
c001e9a8:   38 a0 00 40 li  r5,64
c001e9ac:   38 80 00 00 li  r4,0
c001e9b0:   38 61 00 08 addir3,r1,8
c001e9b4:   90 01 00 54 stw r0,84(r1)
c001e9b8:   4b ff 6d 55 bl  c001570c 
c001e9bc:   38 61 00 08 addir3,r1,8
c001e9c0:   39 20 00 11 li  r9,17
c001e9c4:   91 21 00 1c stw r9,28(r1)
c001e9c8:   4b ff fb 31 bl  c001e4f8 
c001e9cc:   80 01 00 54 lwz r0,84(r1)
c001e9d0:   38 21 00 50 addir1,r1,80
c001e9d4:   7c 08 03 a6 mtlrr0
c001e9d8:   4e 80 00 20 blr

c001e9dc <__powerpc_sys_fork>:
c001e9dc:   94 21 ff b0 stwur1,-80(r1)
c001e9e0:   7c 08 02 a6 mflrr0
c001e9e4:   38 a0 00 40 li  r5,64
c001e9e8:   38 80 00 00 li  r4,0
c001e9ec:   38 61 00 08 addir3,r1,8
c001e9f0:   90 01 00 54 stw r0,84(r1)
c001e9f4:   4b ff 6d 19 bl  c001570c 
c001e9f8:   38 61 00 08 addir3,r1,8
c001e9fc:   39 20 00 11 li  r9,17
c001ea00:   91 21 00 1c stw r9,28(r1)
c001ea04:   4b ff fa f5 bl  c001e4f8 
c001ea08:   80 01 00 54 lwz r0,84(r1)
c001ea0c:   38 21 00 50 addir1,r1,80
c001ea10:   7c 08 03 a6 mtlrr0
c001ea14:   4e 80 00 20 blr

c001ea18 :
c001ea18:   94 21 ff b0 stwur1,-80(r1)
c001ea1c:   7c 08 02 a6 mflrr0
c001ea20:   38 a0 00 38 li  r5,56
c001ea24:   38 80 00 00 li  r4,0
c001ea28:   38 61 00 10 addir3,r1,16
c001ea2c:   90 01 00 54 stw r0,84(r1)
c001ea30:   4b ff 6c dd bl  c001570c 
c001ea34:   38 61 00 08 addir3,r1,8
c001ea38:   39 40 00 00 li  r10,0
c001ea3c:   39 60 41 00 li  r11,16640
c001ea40:   39 20 00 11 li  r9,17
c001ea44:   91 41 00 08 stw r10,8(r1)
c001ea48:   91 61 00 0c stw r11,12(r1)
c001ea4c:   91 21 00 1c stw r9,28(r1)
c001ea50:   4b ff fa a9 bl  c001e4f8 
c001ea54:   80 01 00 54 lwz r0,84(r1)
c001ea58:   38 21 00 50 addir1,r1,80
c001ea5c:   7c 08 03 a6 mtlrr0
c001ea60:   4e 80 00 20 blr

c001ea64 <__powerpc_sys_vfork>:
c001ea64:   94 21 ff b0 stwur1,-80(r1)
c001ea68:   7c 08 02 a6 mflrr0
c001ea6c:   38 a0 00 38 li  r5,56
c001ea70:   38 80 00 00 li  r4,0
c001ea74:   38 61 00 10 addir3,r1,16
c001ea78:   90 01 00 54 stw r0,84(r1)
c001ea7c:   4b ff 6c 91 bl  c001570c 
c001ea80:   38 61 00 08 addir3,r1,8
c001ea84:   39 40 00 00 li  r10,0
c001ea88:   39 60 41 00 li  r11,16640
c001ea8c:   39 20 00 11 li  r9,17
c001ea90:   91 41 00 08 stw r10,8(r1)
c001ea94:   91 61 00 0c stw r11,12(r1)
c001ea98:   91 21 00 1c stw r9,28(r1)
c001ea9c:   4b ff fa 5d bl  c001e4f8 
c001eaa0:   80 01 00 54 lwz r0,84(r1)
c001eaa4:   38 21 00 50 addir1,r1,80
c001eaa8:   7c 08 03 a6 mtlrr0
c001eaac:   4e 80 00 20 blr



Christophe


> Co-developed-by: Andrew Donnellan 
> Signed-off-by: Andrew Donnellan 
> Signed-off-by: Rohan McLure 
> ---
>   arch/powerpc/Kconfig   |  1 +
>   arch/powerpc/include/asm/interrupt.h   |  3 +-
>   arch/powerpc/include/asm/syscall_wrapper.h | 92 ++
>   arch/powerpc/include/asm/syscalls.h| 83 +--
>   arch/powerpc/kernel/entry_32.S |  6 +-
>   arch/powerpc/kernel/interrupt.c| 35 
>   arch/powerpc/kernel/interrupt_64.S | 30 +++
>   arch/powerpc/kernel/sys_ppc32.c| 50 +++-
>   arch/powerpc/kernel/syscalls.c  

[PATCH] powerpc/kasan: Force thread size increase with KASAN

2022-06-01 Thread Michael Ellerman
KASAN causes increased stack usage, which can lead to stack overflows.

The logic in Kconfig to suggest a larger default doesn't work if a user
has CONFIG_EXPERT enabled and has an existing .config with a smaller
value.

Follow the lead of x86 and arm64, and force the thread size to be
increased when KASAN is enabled.

That also has the effect of enlarging the stack for 64-bit KASAN builds,
which is also desirable.

Fixes: edbadaf06710 ("powerpc/kasan: Fix stack overflow by increasing 
THREAD_SHIFT")
Reported-by: Erhard Furtner 
Reported-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Kconfig   | 1 -
 arch/powerpc/include/asm/thread_info.h | 9 +++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 54dbbb1d4b36..b1760d615bb7 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -790,7 +790,6 @@ config THREAD_SHIFT
range 13 15
default "15" if PPC_256K_PAGES
default "14" if PPC64
-   default "14" if KASAN
default "13"
help
  Used to define the stack size. The default is almost always what you
diff --git a/arch/powerpc/include/asm/thread_info.h 
b/arch/powerpc/include/asm/thread_info.h
index 125328d1b980..c9735f93f8e6 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -14,12 +14,17 @@
 
 #ifdef __KERNEL__
 
-#if defined(CONFIG_VMAP_STACK) && CONFIG_THREAD_SHIFT < PAGE_SHIFT
-#define THREAD_SHIFT   PAGE_SHIFT
+#ifdef CONFIG_KASAN
+#define THREAD_SHIFT   (CONFIG_THREAD_SHIFT + 1)
 #else
 #define THREAD_SHIFT   CONFIG_THREAD_SHIFT
 #endif
 
+#if defined(CONFIG_VMAP_STACK) && THREAD_SHIFT < PAGE_SHIFT
+#undef THREAD_SHIFT
+#define THREAD_SHIFT   PAGE_SHIFT
+#endif
+
 #define THREAD_SIZE(1 << THREAD_SHIFT)
 
 /*
-- 
2.35.3



[PATCH AUTOSEL 4.9 10/11] macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled

2022-06-01 Thread Sasha Levin
From: Finn Thain 

[ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ]

drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): undefined reference to `input_event'
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init':
via-pmu-event.c:(.init.text+0x20): undefined reference to 
`input_allocate_device'
via-pmu-event.c:(.init.text+0xc4): undefined reference to 
`input_register_device'
via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device'
make[1]: *** [Makefile:1155: vmlinux] Error 1
make: *** [Makefile:350: __build_one_by_one] Error 2

Don't call into the input subsystem unless CONFIG_INPUT is built-in.

Reported-by: kernel test robot 
Signed-off-by: Finn Thain 
Tested-by: Randy Dunlap 
Reviewed-by: Christophe Leroy 
Acked-by: Randy Dunlap 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fth...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/Kconfig   | 4 
 drivers/macintosh/Makefile  | 3 ++-
 drivers/macintosh/via-pmu.c | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index d28690f6e262..9e226e143473 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -87,6 +87,10 @@ config ADB_PMU
  this device; you should do so if your machine is one of those
  mentioned above.
 
+config ADB_PMU_EVENT
+   def_bool y
+   depends on ADB_PMU && INPUT=y
+
 config ADB_PMU_LED
bool "Support for the Power/iBook front LED"
depends on ADB_PMU
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 383ba920085b..8513c8aa2faf 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -11,7 +11,8 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN) += mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
 obj-$(CONFIG_ANSLCD)   += ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)  += via-pmu.o via-pmu-event.o
+obj-$(CONFIG_ADB_PMU)  += via-pmu.o
+obj-$(CONFIG_ADB_PMU_EVENT)+= via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)  += via-pmu-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)   += via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA) += via-cuda.o
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 32c696799300..9bdb7d2055b1 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1439,7 +1439,7 @@ pmu_handle_data(unsigned char *data, int len)
pmu_pass_intr(data, len);
/* len == 6 is probably a bad check. But how do I
 * know what PMU versions send what events here? */
-   if (len == 6) {
+   if (IS_ENABLED(CONFIG_ADB_PMU_EVENT) && len == 6) {
via_pmu_event(PMU_EVT_POWER, !!(data[1]&8));
via_pmu_event(PMU_EVT_LID, data[1]&1);
}
-- 
2.35.1



[PATCH AUTOSEL 4.9 09/11] powerpc/xics: fix refcount leak in icp_opal_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ]

The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/xics/icp-opal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/sysdev/xics/icp-opal.c 
b/arch/powerpc/sysdev/xics/icp-opal.c
index b53f80f0b4d8..80a4fa6dcc55 100644
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -199,6 +199,7 @@ int icp_opal_init(void)
 
printk("XICS: Using OPAL ICP fallbacks\n");
 
+   of_node_put(np);
return 0;
 }
 
-- 
2.35.1



[PATCH AUTOSEL 4.14 12/14] macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled

2022-06-01 Thread Sasha Levin
From: Finn Thain 

[ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ]

drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): undefined reference to `input_event'
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init':
via-pmu-event.c:(.init.text+0x20): undefined reference to 
`input_allocate_device'
via-pmu-event.c:(.init.text+0xc4): undefined reference to 
`input_register_device'
via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device'
make[1]: *** [Makefile:1155: vmlinux] Error 1
make: *** [Makefile:350: __build_one_by_one] Error 2

Don't call into the input subsystem unless CONFIG_INPUT is built-in.

Reported-by: kernel test robot 
Signed-off-by: Finn Thain 
Tested-by: Randy Dunlap 
Reviewed-by: Christophe Leroy 
Acked-by: Randy Dunlap 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fth...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/Kconfig   | 4 
 drivers/macintosh/Makefile  | 3 ++-
 drivers/macintosh/via-pmu.c | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 97a420c11eed..5e47d91da519 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -77,6 +77,10 @@ config ADB_PMU
  this device; you should do so if your machine is one of those
  mentioned above.
 
+config ADB_PMU_EVENT
+   def_bool y
+   depends on ADB_PMU && INPUT=y
+
 config ADB_PMU_LED
bool "Support for the Power/iBook front LED"
depends on ADB_PMU
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index ee803638e595..ff099c7d4edd 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -12,7 +12,8 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN) += mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
 obj-$(CONFIG_ANSLCD)   += ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)  += via-pmu.o via-pmu-event.o
+obj-$(CONFIG_ADB_PMU)  += via-pmu.o
+obj-$(CONFIG_ADB_PMU_EVENT)+= via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)  += via-pmu-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)   += via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA) += via-cuda.o
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index f6e040fcad9a..9d6828f49779 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1440,7 +1440,7 @@ pmu_handle_data(unsigned char *data, int len)
pmu_pass_intr(data, len);
/* len == 6 is probably a bad check. But how do I
 * know what PMU versions send what events here? */
-   if (len == 6) {
+   if (IS_ENABLED(CONFIG_ADB_PMU_EVENT) && len == 6) {
via_pmu_event(PMU_EVT_POWER, !!(data[1]&8));
via_pmu_event(PMU_EVT_LID, data[1]&1);
}
-- 
2.35.1



[PATCH AUTOSEL 4.14 11/14] powerpc/xics: fix refcount leak in icp_opal_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ]

The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/xics/icp-opal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/sysdev/xics/icp-opal.c 
b/arch/powerpc/sysdev/xics/icp-opal.c
index c71d2ea42627..3c9dd871491e 100644
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -199,6 +199,7 @@ int icp_opal_init(void)
 
printk("XICS: Using OPAL ICP fallbacks\n");
 
+   of_node_put(np);
return 0;
 }
 
-- 
2.35.1



[PATCH AUTOSEL 4.19 13/15] macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled

2022-06-01 Thread Sasha Levin
From: Finn Thain 

[ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ]

drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): undefined reference to `input_event'
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init':
via-pmu-event.c:(.init.text+0x20): undefined reference to 
`input_allocate_device'
via-pmu-event.c:(.init.text+0xc4): undefined reference to 
`input_register_device'
via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device'
make[1]: *** [Makefile:1155: vmlinux] Error 1
make: *** [Makefile:350: __build_one_by_one] Error 2

Don't call into the input subsystem unless CONFIG_INPUT is built-in.

Reported-by: kernel test robot 
Signed-off-by: Finn Thain 
Tested-by: Randy Dunlap 
Reviewed-by: Christophe Leroy 
Acked-by: Randy Dunlap 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fth...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/Kconfig   | 4 
 drivers/macintosh/Makefile  | 3 ++-
 drivers/macintosh/via-pmu.c | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 47c350cdfb12..a316624742f6 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -66,6 +66,10 @@ config ADB_PMU
  this device; you should do so if your machine is one of those
  mentioned above.
 
+config ADB_PMU_EVENT
+   def_bool y
+   depends on ADB_PMU && INPUT=y
+
 config ADB_PMU_LED
bool "Support for the Power/iBook front LED"
depends on PPC_PMAC && ADB_PMU
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 49819b1b6f20..712edcb3e0b0 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -12,7 +12,8 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN) += mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
 obj-$(CONFIG_ANSLCD)   += ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)  += via-pmu.o via-pmu-event.o
+obj-$(CONFIG_ADB_PMU)  += via-pmu.o
+obj-$(CONFIG_ADB_PMU_EVENT)+= via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)  += via-pmu-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)   += via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA) += via-cuda.o
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index d72c450aebe5..50299d68ddfc 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1464,7 +1464,7 @@ pmu_handle_data(unsigned char *data, int len)
pmu_pass_intr(data, len);
/* len == 6 is probably a bad check. But how do I
 * know what PMU versions send what events here? */
-   if (len == 6) {
+   if (IS_ENABLED(CONFIG_ADB_PMU_EVENT) && len == 6) {
via_pmu_event(PMU_EVT_POWER, !!(data[1]&8));
via_pmu_event(PMU_EVT_LID, data[1]&1);
}
-- 
2.35.1



[PATCH AUTOSEL 4.19 12/15] powerpc/xics: fix refcount leak in icp_opal_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ]

The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/xics/icp-opal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/sysdev/xics/icp-opal.c 
b/arch/powerpc/sysdev/xics/icp-opal.c
index e3e52cf035a9..672d8aedae12 100644
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -199,6 +199,7 @@ int icp_opal_init(void)
 
printk("XICS: Using OPAL ICP fallbacks\n");
 
+   of_node_put(np);
return 0;
 }
 
-- 
2.35.1



[PATCH AUTOSEL 5.4 18/20] powerpc/iommu: Add missing of_node_put in iommu_init_early_dart

2022-06-01 Thread Sasha Levin
From: Peng Wu 

[ Upstream commit 57b742a5b8945118022973e6416b71351df512fb ]

The device_node pointer is returned by of_find_compatible_node
with refcount incremented. We should use of_node_put() to avoid
the refcount leak.

Signed-off-by: Peng Wu 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220425081245.21705-1-wupen...@huawei.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/dart_iommu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index 6b4a34b36d98..8ff9bcfe4b8d 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -403,9 +403,10 @@ void __init iommu_init_early_dart(struct 
pci_controller_ops *controller_ops)
}
 
/* Initialize the DART HW */
-   if (dart_init(dn) != 0)
+   if (dart_init(dn) != 0) {
+   of_node_put(dn);
return;
-
+   }
/*
 * U4 supports a DART bypass, we use it for 64-bit capable devices to
 * improve performance.  However, that only works for devices connected
@@ -418,6 +419,7 @@ void __init iommu_init_early_dart(struct pci_controller_ops 
*controller_ops)
 
/* Setup pci_dma ops */
set_pci_dma_ops(_iommu_ops);
+   of_node_put(dn);
 }
 
 #ifdef CONFIG_PM
-- 
2.35.1



[PATCH AUTOSEL 5.4 17/20] macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled

2022-06-01 Thread Sasha Levin
From: Finn Thain 

[ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ]

drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): undefined reference to `input_event'
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init':
via-pmu-event.c:(.init.text+0x20): undefined reference to 
`input_allocate_device'
via-pmu-event.c:(.init.text+0xc4): undefined reference to 
`input_register_device'
via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device'
make[1]: *** [Makefile:1155: vmlinux] Error 1
make: *** [Makefile:350: __build_one_by_one] Error 2

Don't call into the input subsystem unless CONFIG_INPUT is built-in.

Reported-by: kernel test robot 
Signed-off-by: Finn Thain 
Tested-by: Randy Dunlap 
Reviewed-by: Christophe Leroy 
Acked-by: Randy Dunlap 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fth...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/Kconfig   | 4 
 drivers/macintosh/Makefile  | 3 ++-
 drivers/macintosh/via-pmu.c | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 574e122ae105..abaf1401cca6 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -67,6 +67,10 @@ config ADB_PMU
  this device; you should do so if your machine is one of those
  mentioned above.
 
+config ADB_PMU_EVENT
+   def_bool y
+   depends on ADB_PMU && INPUT=y
+
 config ADB_PMU_LED
bool "Support for the Power/iBook front LED"
depends on PPC_PMAC && ADB_PMU
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 49819b1b6f20..712edcb3e0b0 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -12,7 +12,8 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN) += mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
 obj-$(CONFIG_ANSLCD)   += ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)  += via-pmu.o via-pmu-event.o
+obj-$(CONFIG_ADB_PMU)  += via-pmu.o
+obj-$(CONFIG_ADB_PMU_EVENT)+= via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)  += via-pmu-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)   += via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA) += via-cuda.o
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 21d532a78fa4..d8b6ac2ec313 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1464,7 +1464,7 @@ pmu_handle_data(unsigned char *data, int len)
pmu_pass_intr(data, len);
/* len == 6 is probably a bad check. But how do I
 * know what PMU versions send what events here? */
-   if (len == 6) {
+   if (IS_ENABLED(CONFIG_ADB_PMU_EVENT) && len == 6) {
via_pmu_event(PMU_EVT_POWER, !!(data[1]&8));
via_pmu_event(PMU_EVT_LID, data[1]&1);
}
-- 
2.35.1



[PATCH AUTOSEL 5.4 16/20] powerpc/powernv: fix missing of_node_put in uv_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 3ffa9fd471f57f365bc54fc87824c530422f64a5 ]

of_find_compatible_node() returns node pointer with refcount incremented,
use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220407090043.2491854-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/ultravisor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/powernv/ultravisor.c 
b/arch/powerpc/platforms/powernv/ultravisor.c
index e4a00ad06f9d..67c8c4b2d8b1 100644
--- a/arch/powerpc/platforms/powernv/ultravisor.c
+++ b/arch/powerpc/platforms/powernv/ultravisor.c
@@ -55,6 +55,7 @@ static int __init uv_init(void)
return -ENODEV;
 
uv_memcons = memcons_init(node, "memcons");
+   of_node_put(node);
if (!uv_memcons)
return -ENOENT;
 
-- 
2.35.1



[PATCH AUTOSEL 5.4 15/20] powerpc/xics: fix refcount leak in icp_opal_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ]

The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/xics/icp-opal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/sysdev/xics/icp-opal.c 
b/arch/powerpc/sysdev/xics/icp-opal.c
index 68fd2540b093..7fa520efcefa 100644
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -195,6 +195,7 @@ int icp_opal_init(void)
 
printk("XICS: Using OPAL ICP fallbacks\n");
 
+   of_node_put(np);
return 0;
 }
 
-- 
2.35.1



[PATCH AUTOSEL 5.4 08/20] powerpc/fadump: Fix fadump to work with a different endian capture kernel

2022-06-01 Thread Sasha Levin
From: Hari Bathini 

[ Upstream commit b74196af372f7cb4902179009265fe63ac81824f ]

Dump capture would fail if capture kernel is not of the endianess as the
production kernel, because the in-memory data structure (struct
opal_fadump_mem_struct) shared across production kernel and capture
kernel assumes the same endianess for both the kernels, which doesn't
have to be true always. Fix it by having a well-defined endianess for
struct opal_fadump_mem_struct.

Signed-off-by: Hari Bathini 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/161902744901.86147.14719228311655123526.stgit@hbathini
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal-fadump.c | 94 +++-
 arch/powerpc/platforms/powernv/opal-fadump.h | 10 +--
 2 files changed, 57 insertions(+), 47 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c 
b/arch/powerpc/platforms/powernv/opal-fadump.c
index d361d37d975f..f5cea068f0bd 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.c
+++ b/arch/powerpc/platforms/powernv/opal-fadump.c
@@ -60,7 +60,7 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, 
u64 node)
addr = be64_to_cpu(addr);
pr_debug("Kernel metadata addr: %llx\n", addr);
opal_fdm_active = (void *)addr;
-   if (opal_fdm_active->registered_regions == 0)
+   if (be16_to_cpu(opal_fdm_active->registered_regions) == 0)
return;
 
ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_BOOT_MEM, );
@@ -95,17 +95,17 @@ static int opal_fadump_unregister(struct fw_dump 
*fadump_conf);
 static void opal_fadump_update_config(struct fw_dump *fadump_conf,
  const struct opal_fadump_mem_struct *fdm)
 {
-   pr_debug("Boot memory regions count: %d\n", fdm->region_cnt);
+   pr_debug("Boot memory regions count: %d\n", 
be16_to_cpu(fdm->region_cnt));
 
/*
 * The destination address of the first boot memory region is the
 * destination address of boot memory regions.
 */
-   fadump_conf->boot_mem_dest_addr = fdm->rgn[0].dest;
+   fadump_conf->boot_mem_dest_addr = be64_to_cpu(fdm->rgn[0].dest);
pr_debug("Destination address of boot memory regions: %#016llx\n",
 fadump_conf->boot_mem_dest_addr);
 
-   fadump_conf->fadumphdr_addr = fdm->fadumphdr_addr;
+   fadump_conf->fadumphdr_addr = be64_to_cpu(fdm->fadumphdr_addr);
 }
 
 /*
@@ -126,9 +126,9 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
fadump_conf->boot_memory_size = 0;
 
pr_debug("Boot memory regions:\n");
-   for (i = 0; i < fdm->region_cnt; i++) {
-   base = fdm->rgn[i].src;
-   size = fdm->rgn[i].size;
+   for (i = 0; i < be16_to_cpu(fdm->region_cnt); i++) {
+   base = be64_to_cpu(fdm->rgn[i].src);
+   size = be64_to_cpu(fdm->rgn[i].size);
pr_debug("\t[%03d] base: 0x%lx, size: 0x%lx\n", i, base, size);
 
fadump_conf->boot_mem_addr[i] = base;
@@ -143,7 +143,7 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Start address of reserve dump area (permanent reservation) for
 * re-registering FADump after dump capture.
 */
-   fadump_conf->reserve_dump_area_start = fdm->rgn[0].dest;
+   fadump_conf->reserve_dump_area_start = be64_to_cpu(fdm->rgn[0].dest);
 
/*
 * Rarely, but it can so happen that system crashes before all
@@ -155,13 +155,14 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Hope the memory that could not be preserved only has pages
 * that are usually filtered out while saving the vmcore.
 */
-   if (fdm->region_cnt > fdm->registered_regions) {
+   if (be16_to_cpu(fdm->region_cnt) > 
be16_to_cpu(fdm->registered_regions)) {
pr_warn("Not all memory regions were saved!!!\n");
pr_warn("  Unsaved memory regions:\n");
-   i = fdm->registered_regions;
-   while (i < fdm->region_cnt) {
+   i = be16_to_cpu(fdm->registered_regions);
+   while (i < be16_to_cpu(fdm->region_cnt)) {
pr_warn("\t[%03d] base: 0x%llx, size: 0x%llx\n",
-   i, fdm->rgn[i].src, fdm->rgn[i].size);
+   i, be64_to_cpu(fdm->rgn[i].src),
+   be64_to_cpu(fdm->rgn[i].size));
i++;
}
 
@@ -170,7 +171,7 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
}
 
fadump_conf->boot_mem_top = (fadump_conf->boot_memory_size + hole_size);
-   fadump_conf->boot_mem_regs_cnt = fdm->region_cnt;
+   fadump_conf->boot_mem_regs_cnt = be16_to_cpu(fdm->region_cnt);
opal_fadump_update_config(fadump_conf, fdm);
 }
 
@@ -178,35 +179,38 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 static void 

[PATCH AUTOSEL 5.10 24/26] powerpc/iommu: Add missing of_node_put in iommu_init_early_dart

2022-06-01 Thread Sasha Levin
From: Peng Wu 

[ Upstream commit 57b742a5b8945118022973e6416b71351df512fb ]

The device_node pointer is returned by of_find_compatible_node
with refcount incremented. We should use of_node_put() to avoid
the refcount leak.

Signed-off-by: Peng Wu 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220425081245.21705-1-wupen...@huawei.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/dart_iommu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index 6b4a34b36d98..8ff9bcfe4b8d 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -403,9 +403,10 @@ void __init iommu_init_early_dart(struct 
pci_controller_ops *controller_ops)
}
 
/* Initialize the DART HW */
-   if (dart_init(dn) != 0)
+   if (dart_init(dn) != 0) {
+   of_node_put(dn);
return;
-
+   }
/*
 * U4 supports a DART bypass, we use it for 64-bit capable devices to
 * improve performance.  However, that only works for devices connected
@@ -418,6 +419,7 @@ void __init iommu_init_early_dart(struct pci_controller_ops 
*controller_ops)
 
/* Setup pci_dma ops */
set_pci_dma_ops(_iommu_ops);
+   of_node_put(dn);
 }
 
 #ifdef CONFIG_PM
-- 
2.35.1



[PATCH AUTOSEL 5.10 23/26] macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled

2022-06-01 Thread Sasha Levin
From: Finn Thain 

[ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ]

drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): undefined reference to `input_event'
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init':
via-pmu-event.c:(.init.text+0x20): undefined reference to 
`input_allocate_device'
via-pmu-event.c:(.init.text+0xc4): undefined reference to 
`input_register_device'
via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device'
make[1]: *** [Makefile:1155: vmlinux] Error 1
make: *** [Makefile:350: __build_one_by_one] Error 2

Don't call into the input subsystem unless CONFIG_INPUT is built-in.

Reported-by: kernel test robot 
Signed-off-by: Finn Thain 
Tested-by: Randy Dunlap 
Reviewed-by: Christophe Leroy 
Acked-by: Randy Dunlap 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fth...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/Kconfig   | 4 
 drivers/macintosh/Makefile  | 3 ++-
 drivers/macintosh/via-pmu.c | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 5cdc361da37c..3942db15a2b8 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -67,6 +67,10 @@ config ADB_PMU
  this device; you should do so if your machine is one of those
  mentioned above.
 
+config ADB_PMU_EVENT
+   def_bool y
+   depends on ADB_PMU && INPUT=y
+
 config ADB_PMU_LED
bool "Support for the Power/iBook front LED"
depends on PPC_PMAC && ADB_PMU
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 49819b1b6f20..712edcb3e0b0 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -12,7 +12,8 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN) += mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
 obj-$(CONFIG_ANSLCD)   += ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)  += via-pmu.o via-pmu-event.o
+obj-$(CONFIG_ADB_PMU)  += via-pmu.o
+obj-$(CONFIG_ADB_PMU_EVENT)+= via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)  += via-pmu-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)   += via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA) += via-cuda.o
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 73e6ae88fafd..aae6328b2429 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1460,7 +1460,7 @@ pmu_handle_data(unsigned char *data, int len)
pmu_pass_intr(data, len);
/* len == 6 is probably a bad check. But how do I
 * know what PMU versions send what events here? */
-   if (len == 6) {
+   if (IS_ENABLED(CONFIG_ADB_PMU_EVENT) && len == 6) {
via_pmu_event(PMU_EVT_POWER, !!(data[1]&8));
via_pmu_event(PMU_EVT_LID, data[1]&1);
}
-- 
2.35.1



[PATCH AUTOSEL 5.10 22/26] powerpc/powernv: fix missing of_node_put in uv_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 3ffa9fd471f57f365bc54fc87824c530422f64a5 ]

of_find_compatible_node() returns node pointer with refcount incremented,
use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220407090043.2491854-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/ultravisor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/powernv/ultravisor.c 
b/arch/powerpc/platforms/powernv/ultravisor.c
index e4a00ad06f9d..67c8c4b2d8b1 100644
--- a/arch/powerpc/platforms/powernv/ultravisor.c
+++ b/arch/powerpc/platforms/powernv/ultravisor.c
@@ -55,6 +55,7 @@ static int __init uv_init(void)
return -ENODEV;
 
uv_memcons = memcons_init(node, "memcons");
+   of_node_put(node);
if (!uv_memcons)
return -ENOENT;
 
-- 
2.35.1



[PATCH AUTOSEL 5.10 21/26] powerpc/xics: fix refcount leak in icp_opal_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ]

The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/xics/icp-opal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/sysdev/xics/icp-opal.c 
b/arch/powerpc/sysdev/xics/icp-opal.c
index 68fd2540b093..7fa520efcefa 100644
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -195,6 +195,7 @@ int icp_opal_init(void)
 
printk("XICS: Using OPAL ICP fallbacks\n");
 
+   of_node_put(np);
return 0;
 }
 
-- 
2.35.1



[PATCH AUTOSEL 5.10 20/26] powerpc/powernv/vas: Assign real address to rx_fifo in vas_rx_win_attr

2022-06-01 Thread Sasha Levin
From: Haren Myneni 

[ Upstream commit c127d130f6d59fa81701f6b04023cf7cd1972fb3 ]

In init_winctx_regs(), __pa() is called on winctx->rx_fifo and this
function is called to initialize registers for receive and fault
windows. But the real address is passed in winctx->rx_fifo for
receive windows and the virtual address for fault windows which
causes errors with DEBUG_VIRTUAL enabled. Fixes this issue by
assigning only real address to rx_fifo in vas_rx_win_attr struct
for both receive and fault windows.

Reported-by: Michael Ellerman 
Signed-off-by: Haren Myneni 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/338e958c7ab8f3b266fa794a1f80f99b9671829e.ca...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/asm/vas.h  | 2 +-
 arch/powerpc/platforms/powernv/vas-fault.c  | 2 +-
 arch/powerpc/platforms/powernv/vas-window.c | 4 ++--
 arch/powerpc/platforms/powernv/vas.h| 2 +-
 drivers/crypto/nx/nx-common-powernv.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index e33f80b0ea81..47062b457049 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -52,7 +52,7 @@ enum vas_cop_type {
  * Receive window attributes specified by the (in-kernel) owner of window.
  */
 struct vas_rx_win_attr {
-   void *rx_fifo;
+   u64 rx_fifo;
int rx_fifo_size;
int wcreds_max;
 
diff --git a/arch/powerpc/platforms/powernv/vas-fault.c 
b/arch/powerpc/platforms/powernv/vas-fault.c
index 3d21fce254b7..dd9c23c09781 100644
--- a/arch/powerpc/platforms/powernv/vas-fault.c
+++ b/arch/powerpc/platforms/powernv/vas-fault.c
@@ -352,7 +352,7 @@ int vas_setup_fault_window(struct vas_instance *vinst)
vas_init_rx_win_attr(, VAS_COP_TYPE_FAULT);
 
attr.rx_fifo_size = vinst->fault_fifo_size;
-   attr.rx_fifo = vinst->fault_fifo;
+   attr.rx_fifo = __pa(vinst->fault_fifo);
 
/*
 * Max creds is based on number of CRBs can fit in the FIFO.
diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 7ba0840fc3b5..3a86cdd5ae6c 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -403,7 +403,7 @@ static void init_winctx_regs(struct vas_window *window,
 *
 * See also: Design note in function header.
 */
-   val = __pa(winctx->rx_fifo);
+   val = winctx->rx_fifo;
val = SET_FIELD(VAS_PAGE_MIGRATION_SELECT, val, 0);
write_hvwc_reg(window, VREG(LFIFO_BAR), val);
 
@@ -737,7 +737,7 @@ static void init_winctx_for_rxwin(struct vas_window *rxwin,
 */
winctx->fifo_disable = true;
winctx->intr_disable = true;
-   winctx->rx_fifo = NULL;
+   winctx->rx_fifo = 0;
}
 
winctx->lnotify_lpid = rxattr->lnotify_lpid;
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index 70f793e8f6cc..1f6e73809205 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -383,7 +383,7 @@ struct vas_window {
  * is a container for the register fields in the window context.
  */
 struct vas_winctx {
-   void *rx_fifo;
+   u64 rx_fifo;
int rx_fifo_size;
int wcreds_max;
int rsvd_txbuf_count;
diff --git a/drivers/crypto/nx/nx-common-powernv.c 
b/drivers/crypto/nx/nx-common-powernv.c
index 13c65deda8e9..8a4f10bb3fcd 100644
--- a/drivers/crypto/nx/nx-common-powernv.c
+++ b/drivers/crypto/nx/nx-common-powernv.c
@@ -827,7 +827,7 @@ static int __init vas_cfg_coproc_info(struct device_node 
*dn, int chip_id,
goto err_out;
 
vas_init_rx_win_attr(, coproc->ct);
-   rxattr.rx_fifo = (void *)rx_fifo;
+   rxattr.rx_fifo = rx_fifo;
rxattr.rx_fifo_size = fifo_size;
rxattr.lnotify_lpid = lpid;
rxattr.lnotify_pid = pid;
-- 
2.35.1



[PATCH AUTOSEL 5.10 12/26] powerpc/fadump: Fix fadump to work with a different endian capture kernel

2022-06-01 Thread Sasha Levin
From: Hari Bathini 

[ Upstream commit b74196af372f7cb4902179009265fe63ac81824f ]

Dump capture would fail if capture kernel is not of the endianess as the
production kernel, because the in-memory data structure (struct
opal_fadump_mem_struct) shared across production kernel and capture
kernel assumes the same endianess for both the kernels, which doesn't
have to be true always. Fix it by having a well-defined endianess for
struct opal_fadump_mem_struct.

Signed-off-by: Hari Bathini 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/161902744901.86147.14719228311655123526.stgit@hbathini
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal-fadump.c | 94 +++-
 arch/powerpc/platforms/powernv/opal-fadump.h | 10 +--
 2 files changed, 57 insertions(+), 47 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c 
b/arch/powerpc/platforms/powernv/opal-fadump.c
index 9a360ced663b..e23a51a05f99 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.c
+++ b/arch/powerpc/platforms/powernv/opal-fadump.c
@@ -60,7 +60,7 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, 
u64 node)
addr = be64_to_cpu(addr);
pr_debug("Kernel metadata addr: %llx\n", addr);
opal_fdm_active = (void *)addr;
-   if (opal_fdm_active->registered_regions == 0)
+   if (be16_to_cpu(opal_fdm_active->registered_regions) == 0)
return;
 
ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_BOOT_MEM, );
@@ -95,17 +95,17 @@ static int opal_fadump_unregister(struct fw_dump 
*fadump_conf);
 static void opal_fadump_update_config(struct fw_dump *fadump_conf,
  const struct opal_fadump_mem_struct *fdm)
 {
-   pr_debug("Boot memory regions count: %d\n", fdm->region_cnt);
+   pr_debug("Boot memory regions count: %d\n", 
be16_to_cpu(fdm->region_cnt));
 
/*
 * The destination address of the first boot memory region is the
 * destination address of boot memory regions.
 */
-   fadump_conf->boot_mem_dest_addr = fdm->rgn[0].dest;
+   fadump_conf->boot_mem_dest_addr = be64_to_cpu(fdm->rgn[0].dest);
pr_debug("Destination address of boot memory regions: %#016llx\n",
 fadump_conf->boot_mem_dest_addr);
 
-   fadump_conf->fadumphdr_addr = fdm->fadumphdr_addr;
+   fadump_conf->fadumphdr_addr = be64_to_cpu(fdm->fadumphdr_addr);
 }
 
 /*
@@ -126,9 +126,9 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
fadump_conf->boot_memory_size = 0;
 
pr_debug("Boot memory regions:\n");
-   for (i = 0; i < fdm->region_cnt; i++) {
-   base = fdm->rgn[i].src;
-   size = fdm->rgn[i].size;
+   for (i = 0; i < be16_to_cpu(fdm->region_cnt); i++) {
+   base = be64_to_cpu(fdm->rgn[i].src);
+   size = be64_to_cpu(fdm->rgn[i].size);
pr_debug("\t[%03d] base: 0x%lx, size: 0x%lx\n", i, base, size);
 
fadump_conf->boot_mem_addr[i] = base;
@@ -143,7 +143,7 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Start address of reserve dump area (permanent reservation) for
 * re-registering FADump after dump capture.
 */
-   fadump_conf->reserve_dump_area_start = fdm->rgn[0].dest;
+   fadump_conf->reserve_dump_area_start = be64_to_cpu(fdm->rgn[0].dest);
 
/*
 * Rarely, but it can so happen that system crashes before all
@@ -155,13 +155,14 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Hope the memory that could not be preserved only has pages
 * that are usually filtered out while saving the vmcore.
 */
-   if (fdm->region_cnt > fdm->registered_regions) {
+   if (be16_to_cpu(fdm->region_cnt) > 
be16_to_cpu(fdm->registered_regions)) {
pr_warn("Not all memory regions were saved!!!\n");
pr_warn("  Unsaved memory regions:\n");
-   i = fdm->registered_regions;
-   while (i < fdm->region_cnt) {
+   i = be16_to_cpu(fdm->registered_regions);
+   while (i < be16_to_cpu(fdm->region_cnt)) {
pr_warn("\t[%03d] base: 0x%llx, size: 0x%llx\n",
-   i, fdm->rgn[i].src, fdm->rgn[i].size);
+   i, be64_to_cpu(fdm->rgn[i].src),
+   be64_to_cpu(fdm->rgn[i].size));
i++;
}
 
@@ -170,7 +171,7 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
}
 
fadump_conf->boot_mem_top = (fadump_conf->boot_memory_size + hole_size);
-   fadump_conf->boot_mem_regs_cnt = fdm->region_cnt;
+   fadump_conf->boot_mem_regs_cnt = be16_to_cpu(fdm->region_cnt);
opal_fadump_update_config(fadump_conf, fdm);
 }
 
@@ -178,35 +179,38 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 static void 

[PATCH AUTOSEL 5.15 33/37] powerpc/iommu: Add missing of_node_put in iommu_init_early_dart

2022-06-01 Thread Sasha Levin
From: Peng Wu 

[ Upstream commit 57b742a5b8945118022973e6416b71351df512fb ]

The device_node pointer is returned by of_find_compatible_node
with refcount incremented. We should use of_node_put() to avoid
the refcount leak.

Signed-off-by: Peng Wu 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220425081245.21705-1-wupen...@huawei.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/dart_iommu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index 1d33b7a5ea83..dc774b204c06 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -404,9 +404,10 @@ void __init iommu_init_early_dart(struct 
pci_controller_ops *controller_ops)
}
 
/* Initialize the DART HW */
-   if (dart_init(dn) != 0)
+   if (dart_init(dn) != 0) {
+   of_node_put(dn);
return;
-
+   }
/*
 * U4 supports a DART bypass, we use it for 64-bit capable devices to
 * improve performance.  However, that only works for devices connected
@@ -419,6 +420,7 @@ void __init iommu_init_early_dart(struct pci_controller_ops 
*controller_ops)
 
/* Setup pci_dma ops */
set_pci_dma_ops(_iommu_ops);
+   of_node_put(dn);
 }
 
 #ifdef CONFIG_PM
-- 
2.35.1



[PATCH AUTOSEL 5.15 32/37] macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled

2022-06-01 Thread Sasha Levin
From: Finn Thain 

[ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ]

drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): undefined reference to `input_event'
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init':
via-pmu-event.c:(.init.text+0x20): undefined reference to 
`input_allocate_device'
via-pmu-event.c:(.init.text+0xc4): undefined reference to 
`input_register_device'
via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device'
make[1]: *** [Makefile:1155: vmlinux] Error 1
make: *** [Makefile:350: __build_one_by_one] Error 2

Don't call into the input subsystem unless CONFIG_INPUT is built-in.

Reported-by: kernel test robot 
Signed-off-by: Finn Thain 
Tested-by: Randy Dunlap 
Reviewed-by: Christophe Leroy 
Acked-by: Randy Dunlap 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fth...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/Kconfig   | 4 
 drivers/macintosh/Makefile  | 3 ++-
 drivers/macintosh/via-pmu.c | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 5cdc361da37c..3942db15a2b8 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -67,6 +67,10 @@ config ADB_PMU
  this device; you should do so if your machine is one of those
  mentioned above.
 
+config ADB_PMU_EVENT
+   def_bool y
+   depends on ADB_PMU && INPUT=y
+
 config ADB_PMU_LED
bool "Support for the Power/iBook front LED"
depends on PPC_PMAC && ADB_PMU
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 49819b1b6f20..712edcb3e0b0 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -12,7 +12,8 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN) += mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
 obj-$(CONFIG_ANSLCD)   += ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)  += via-pmu.o via-pmu-event.o
+obj-$(CONFIG_ADB_PMU)  += via-pmu.o
+obj-$(CONFIG_ADB_PMU_EVENT)+= via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)  += via-pmu-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)   += via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA) += via-cuda.o
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 4b98bc26a94b..2109129ea1bb 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1459,7 +1459,7 @@ pmu_handle_data(unsigned char *data, int len)
pmu_pass_intr(data, len);
/* len == 6 is probably a bad check. But how do I
 * know what PMU versions send what events here? */
-   if (len == 6) {
+   if (IS_ENABLED(CONFIG_ADB_PMU_EVENT) && len == 6) {
via_pmu_event(PMU_EVT_POWER, !!(data[1]&8));
via_pmu_event(PMU_EVT_LID, data[1]&1);
}
-- 
2.35.1



[PATCH AUTOSEL 5.15 31/37] powerpc/powernv: fix missing of_node_put in uv_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 3ffa9fd471f57f365bc54fc87824c530422f64a5 ]

of_find_compatible_node() returns node pointer with refcount incremented,
use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220407090043.2491854-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/ultravisor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/powernv/ultravisor.c 
b/arch/powerpc/platforms/powernv/ultravisor.c
index e4a00ad06f9d..67c8c4b2d8b1 100644
--- a/arch/powerpc/platforms/powernv/ultravisor.c
+++ b/arch/powerpc/platforms/powernv/ultravisor.c
@@ -55,6 +55,7 @@ static int __init uv_init(void)
return -ENODEV;
 
uv_memcons = memcons_init(node, "memcons");
+   of_node_put(node);
if (!uv_memcons)
return -ENOENT;
 
-- 
2.35.1



[PATCH AUTOSEL 5.15 30/37] powerpc/xics: fix refcount leak in icp_opal_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ]

The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/xics/icp-opal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/sysdev/xics/icp-opal.c 
b/arch/powerpc/sysdev/xics/icp-opal.c
index 675d708863d5..db0452e7c351 100644
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -196,6 +196,7 @@ int icp_opal_init(void)
 
printk("XICS: Using OPAL ICP fallbacks\n");
 
+   of_node_put(np);
return 0;
 }
 
-- 
2.35.1



[PATCH AUTOSEL 5.15 29/37] powerpc/powernv/vas: Assign real address to rx_fifo in vas_rx_win_attr

2022-06-01 Thread Sasha Levin
From: Haren Myneni 

[ Upstream commit c127d130f6d59fa81701f6b04023cf7cd1972fb3 ]

In init_winctx_regs(), __pa() is called on winctx->rx_fifo and this
function is called to initialize registers for receive and fault
windows. But the real address is passed in winctx->rx_fifo for
receive windows and the virtual address for fault windows which
causes errors with DEBUG_VIRTUAL enabled. Fixes this issue by
assigning only real address to rx_fifo in vas_rx_win_attr struct
for both receive and fault windows.

Reported-by: Michael Ellerman 
Signed-off-by: Haren Myneni 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/338e958c7ab8f3b266fa794a1f80f99b9671829e.ca...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/asm/vas.h  | 2 +-
 arch/powerpc/platforms/powernv/vas-fault.c  | 2 +-
 arch/powerpc/platforms/powernv/vas-window.c | 4 ++--
 arch/powerpc/platforms/powernv/vas.h| 2 +-
 drivers/crypto/nx/nx-common-powernv.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index 57573d9c1e09..56834a8a1465 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -112,7 +112,7 @@ static inline void vas_user_win_add_mm_context(struct 
vas_user_win_ref *ref)
  * Receive window attributes specified by the (in-kernel) owner of window.
  */
 struct vas_rx_win_attr {
-   void *rx_fifo;
+   u64 rx_fifo;
int rx_fifo_size;
int wcreds_max;
 
diff --git a/arch/powerpc/platforms/powernv/vas-fault.c 
b/arch/powerpc/platforms/powernv/vas-fault.c
index a7aabc18039e..c1bfad56447d 100644
--- a/arch/powerpc/platforms/powernv/vas-fault.c
+++ b/arch/powerpc/platforms/powernv/vas-fault.c
@@ -216,7 +216,7 @@ int vas_setup_fault_window(struct vas_instance *vinst)
vas_init_rx_win_attr(, VAS_COP_TYPE_FAULT);
 
attr.rx_fifo_size = vinst->fault_fifo_size;
-   attr.rx_fifo = vinst->fault_fifo;
+   attr.rx_fifo = __pa(vinst->fault_fifo);
 
/*
 * Max creds is based on number of CRBs can fit in the FIFO.
diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 0f8d39fbf2b2..0072682531d8 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -404,7 +404,7 @@ static void init_winctx_regs(struct pnv_vas_window *window,
 *
 * See also: Design note in function header.
 */
-   val = __pa(winctx->rx_fifo);
+   val = winctx->rx_fifo;
val = SET_FIELD(VAS_PAGE_MIGRATION_SELECT, val, 0);
write_hvwc_reg(window, VREG(LFIFO_BAR), val);
 
@@ -739,7 +739,7 @@ static void init_winctx_for_rxwin(struct pnv_vas_window 
*rxwin,
 */
winctx->fifo_disable = true;
winctx->intr_disable = true;
-   winctx->rx_fifo = NULL;
+   winctx->rx_fifo = 0;
}
 
winctx->lnotify_lpid = rxattr->lnotify_lpid;
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index 8bb08e395de0..08d9d3d5a22b 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -376,7 +376,7 @@ struct pnv_vas_window {
  * is a container for the register fields in the window context.
  */
 struct vas_winctx {
-   void *rx_fifo;
+   u64 rx_fifo;
int rx_fifo_size;
int wcreds_max;
int rsvd_txbuf_count;
diff --git a/drivers/crypto/nx/nx-common-powernv.c 
b/drivers/crypto/nx/nx-common-powernv.c
index 32a036ada5d0..f418817c0f43 100644
--- a/drivers/crypto/nx/nx-common-powernv.c
+++ b/drivers/crypto/nx/nx-common-powernv.c
@@ -827,7 +827,7 @@ static int __init vas_cfg_coproc_info(struct device_node 
*dn, int chip_id,
goto err_out;
 
vas_init_rx_win_attr(, coproc->ct);
-   rxattr.rx_fifo = (void *)rx_fifo;
+   rxattr.rx_fifo = rx_fifo;
rxattr.rx_fifo_size = fifo_size;
rxattr.lnotify_lpid = lpid;
rxattr.lnotify_pid = pid;
-- 
2.35.1



[PATCH AUTOSEL 5.15 26/37] KVM: PPC: Book3S HV Nested: L2 LPCR should inherit L1 LPES setting

2022-06-01 Thread Sasha Levin
From: Nicholas Piggin 

[ Upstream commit 2852ebfa10afdcefff35ec72c8da97141df9845c ]

The L1 should not be able to adjust LPES mode for the L2. Setting LPES
if the L0 needs it clear would cause external interrupts to be sent to
L2 and missed by the L0.

Clearing LPES when it may be set, as typically happens with XIVE enabled
could cause a performance issue despite having no native XIVE support in
the guest, because it will cause mediated interrupts for the L2 to be
taken in HV mode, which then have to be injected.

Signed-off-by: Nicholas Piggin 
Reviewed-by: Fabiano Rosas 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220303053315.1056880-7-npig...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kvm/book3s_hv.c| 4 
 arch/powerpc/kvm/book3s_hv_nested.c | 3 +--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 7fa685711669..eba77096c443 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -5235,6 +5235,10 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
kvm->arch.host_lpcr = lpcr = mfspr(SPRN_LPCR);
lpcr &= LPCR_PECE | LPCR_LPES;
} else {
+   /*
+* The L2 LPES mode will be set by the L0 according to whether
+* or not it needs to take external interrupts in HV mode.
+*/
lpcr = 0;
}
lpcr |= (4UL << LPCR_DPFD_SH) | LPCR_HDICE |
diff --git a/arch/powerpc/kvm/book3s_hv_nested.c 
b/arch/powerpc/kvm/book3s_hv_nested.c
index 6c4e0e93105f..ddea14e5cb5e 100644
--- a/arch/powerpc/kvm/book3s_hv_nested.c
+++ b/arch/powerpc/kvm/book3s_hv_nested.c
@@ -261,8 +261,7 @@ static void load_l2_hv_regs(struct kvm_vcpu *vcpu,
/*
 * Don't let L1 change LPCR bits for the L2 except these:
 */
-   mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD |
-   LPCR_LPES | LPCR_MER;
+   mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD | LPCR_MER;
 
/*
 * Additional filtering is required depending on hardware
-- 
2.35.1



[PATCH AUTOSEL 5.15 24/37] powerpc/rtas: Keep MSR[RI] set when calling RTAS

2022-06-01 Thread Sasha Levin
From: Laurent Dufour 

[ Upstream commit b6b1c3ce06ca438eb24e0f45bf0e63ecad0369f5 ]

RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32-bit big
endian mode (MSR[SF,LE] unset).

The change in MSR is done in enter_rtas() in a relatively complex way,
since the MSR value could be hardcoded.

Furthermore, a panic has been reported when hitting the watchdog interrupt
while running in RTAS, this leads to the following stack trace:

  watchdog: CPU 24 Hard LOCKUP
  watchdog: CPU 24 TB:997512652051031, last heartbeat TB:997504470175378 
(15980ms ago)
  ...
  Supported: No, Unreleased kernel
  CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: GE  X
5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 
0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
  NIP:  1fb41050 LR: 1fb4104c CTR: 
  REGS: cfc33d60 TRAP: 0100   Tainted: GE  X 
(5.14.21-150400.71.1.bz196362_2-default)
  MSR:  82981000   CR: 4882  XER: 20040020
  CFAR: 011c IRQMASK: 1
  GPR00: 0003  0001 50dc
  GPR04: 1ffb6100 0020 0001 1fb09010
  GPR08: 2000   
  GPR12: 8004072a40a8 cff8b680 0007 0034
  GPR16: 1fbf6e94 1fbf6d84 1fbd1db0 1fb3f008
  GPR20: 1fb41018  017f f68f
  GPR24: 1fb18fe8 1fb3e000 1fb1adc0 1fb1cf40
  GPR28: 1fb26000 1fb460f0 1fb17f18 1fb17000
  NIP [1fb41050] 0x1fb41050
  LR [1fb4104c] 0x1fb4104c
  Call Trace:
  Instruction dump:
         
         
  Oops: Unrecoverable System Reset, sig: 6 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  ...
  Supported: No, Unreleased kernel
  CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: GE  X
5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 
0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
  NIP:  1fb41050 LR: 1fb4104c CTR: 
  REGS: cfc33d60 TRAP: 0100   Tainted: GE  X 
(5.14.21-150400.71.1.bz196362_2-default)
  MSR:  82981000   CR: 4882  XER: 20040020
  CFAR: 011c IRQMASK: 1
  GPR00: 0003  0001 50dc
  GPR04: 1ffb6100 0020 0001 1fb09010
  GPR08: 2000   
  GPR12: 8004072a40a8 cff8b680 0007 0034
  GPR16: 1fbf6e94 1fbf6d84 1fbd1db0 1fb3f008
  GPR20: 1fb41018  017f f68f
  GPR24: 1fb18fe8 1fb3e000 1fb1adc0 1fb1cf40
  GPR28: 1fb26000 1fb460f0 1fb17f18 1fb17000
  NIP [1fb41050] 0x1fb41050
  LR [1fb4104c] 0x1fb4104c
  Call Trace:
  Instruction dump:
         
         
  ---[ end trace 3ddec07f638c34a2 ]---

This happens because MSR[RI] is unset when entering RTAS but there is no
valid reason to not set it here.

RTAS is expected to be called with MSR[RI] as specified in PAPR+ section
"7.2.1 Machine State":

  R1–7.2.1–9. If called with MSR[RI] equal to 1, then RTAS must protect
  its own critical regions from recursion by setting the MSR[RI] bit to
  0 when in the critical regions.

Fixing this by reviewing the way MSR is compute before calling RTAS. Now a
hardcoded value meaning real mode, 32 bits big endian mode and Recoverable
Interrupt is loaded. In the case MSR[S] is set, it will remain set while
entering RTAS as only urfid can unset it (thanks Fabiano).

In addition a check is added in do_enter_rtas() to detect calls made with
MSR[RI] unset, as we are forcing it on later.

This patch has been tested on the following machines:
Power KVM Guest
  P8 S822L (host Ubuntu kernel 5.11.0-49-generic)
PowerVM LPAR
  P8 9119-MME (FW860.A1)
  p9 9008-22L (FW950.00)
  P10 9080-HEX (FW1010.00)

Suggested-by: Nicholas Piggin 
Signed-off-by: Laurent Dufour 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220504101244.12107-1-lduf...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/entry_64.S | 24 
 arch/powerpc/kernel/rtas.c |  9 +
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 70cff7b49e17..07a1448146e2 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ 

[PATCH AUTOSEL 5.15 17/37] powerpc/fadump: Fix fadump to work with a different endian capture kernel

2022-06-01 Thread Sasha Levin
From: Hari Bathini 

[ Upstream commit b74196af372f7cb4902179009265fe63ac81824f ]

Dump capture would fail if capture kernel is not of the endianess as the
production kernel, because the in-memory data structure (struct
opal_fadump_mem_struct) shared across production kernel and capture
kernel assumes the same endianess for both the kernels, which doesn't
have to be true always. Fix it by having a well-defined endianess for
struct opal_fadump_mem_struct.

Signed-off-by: Hari Bathini 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/161902744901.86147.14719228311655123526.stgit@hbathini
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal-fadump.c | 94 +++-
 arch/powerpc/platforms/powernv/opal-fadump.h | 10 +--
 2 files changed, 57 insertions(+), 47 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c 
b/arch/powerpc/platforms/powernv/opal-fadump.c
index 9a360ced663b..e23a51a05f99 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.c
+++ b/arch/powerpc/platforms/powernv/opal-fadump.c
@@ -60,7 +60,7 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, 
u64 node)
addr = be64_to_cpu(addr);
pr_debug("Kernel metadata addr: %llx\n", addr);
opal_fdm_active = (void *)addr;
-   if (opal_fdm_active->registered_regions == 0)
+   if (be16_to_cpu(opal_fdm_active->registered_regions) == 0)
return;
 
ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_BOOT_MEM, );
@@ -95,17 +95,17 @@ static int opal_fadump_unregister(struct fw_dump 
*fadump_conf);
 static void opal_fadump_update_config(struct fw_dump *fadump_conf,
  const struct opal_fadump_mem_struct *fdm)
 {
-   pr_debug("Boot memory regions count: %d\n", fdm->region_cnt);
+   pr_debug("Boot memory regions count: %d\n", 
be16_to_cpu(fdm->region_cnt));
 
/*
 * The destination address of the first boot memory region is the
 * destination address of boot memory regions.
 */
-   fadump_conf->boot_mem_dest_addr = fdm->rgn[0].dest;
+   fadump_conf->boot_mem_dest_addr = be64_to_cpu(fdm->rgn[0].dest);
pr_debug("Destination address of boot memory regions: %#016llx\n",
 fadump_conf->boot_mem_dest_addr);
 
-   fadump_conf->fadumphdr_addr = fdm->fadumphdr_addr;
+   fadump_conf->fadumphdr_addr = be64_to_cpu(fdm->fadumphdr_addr);
 }
 
 /*
@@ -126,9 +126,9 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
fadump_conf->boot_memory_size = 0;
 
pr_debug("Boot memory regions:\n");
-   for (i = 0; i < fdm->region_cnt; i++) {
-   base = fdm->rgn[i].src;
-   size = fdm->rgn[i].size;
+   for (i = 0; i < be16_to_cpu(fdm->region_cnt); i++) {
+   base = be64_to_cpu(fdm->rgn[i].src);
+   size = be64_to_cpu(fdm->rgn[i].size);
pr_debug("\t[%03d] base: 0x%lx, size: 0x%lx\n", i, base, size);
 
fadump_conf->boot_mem_addr[i] = base;
@@ -143,7 +143,7 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Start address of reserve dump area (permanent reservation) for
 * re-registering FADump after dump capture.
 */
-   fadump_conf->reserve_dump_area_start = fdm->rgn[0].dest;
+   fadump_conf->reserve_dump_area_start = be64_to_cpu(fdm->rgn[0].dest);
 
/*
 * Rarely, but it can so happen that system crashes before all
@@ -155,13 +155,14 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Hope the memory that could not be preserved only has pages
 * that are usually filtered out while saving the vmcore.
 */
-   if (fdm->region_cnt > fdm->registered_regions) {
+   if (be16_to_cpu(fdm->region_cnt) > 
be16_to_cpu(fdm->registered_regions)) {
pr_warn("Not all memory regions were saved!!!\n");
pr_warn("  Unsaved memory regions:\n");
-   i = fdm->registered_regions;
-   while (i < fdm->region_cnt) {
+   i = be16_to_cpu(fdm->registered_regions);
+   while (i < be16_to_cpu(fdm->region_cnt)) {
pr_warn("\t[%03d] base: 0x%llx, size: 0x%llx\n",
-   i, fdm->rgn[i].src, fdm->rgn[i].size);
+   i, be64_to_cpu(fdm->rgn[i].src),
+   be64_to_cpu(fdm->rgn[i].size));
i++;
}
 
@@ -170,7 +171,7 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
}
 
fadump_conf->boot_mem_top = (fadump_conf->boot_memory_size + hole_size);
-   fadump_conf->boot_mem_regs_cnt = fdm->region_cnt;
+   fadump_conf->boot_mem_regs_cnt = be16_to_cpu(fdm->region_cnt);
opal_fadump_update_config(fadump_conf, fdm);
 }
 
@@ -178,35 +179,38 @@ static void opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 static void 

[PATCH AUTOSEL 5.17 42/48] powerpc/iommu: Add missing of_node_put in iommu_init_early_dart

2022-06-01 Thread Sasha Levin
From: Peng Wu 

[ Upstream commit 57b742a5b8945118022973e6416b71351df512fb ]

The device_node pointer is returned by of_find_compatible_node
with refcount incremented. We should use of_node_put() to avoid
the refcount leak.

Signed-off-by: Peng Wu 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220425081245.21705-1-wupen...@huawei.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/dart_iommu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index be6b99b1b352..9a02aed886a0 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -404,9 +404,10 @@ void __init iommu_init_early_dart(struct 
pci_controller_ops *controller_ops)
}
 
/* Initialize the DART HW */
-   if (dart_init(dn) != 0)
+   if (dart_init(dn) != 0) {
+   of_node_put(dn);
return;
-
+   }
/*
 * U4 supports a DART bypass, we use it for 64-bit capable devices to
 * improve performance.  However, that only works for devices connected
@@ -419,6 +420,7 @@ void __init iommu_init_early_dart(struct pci_controller_ops 
*controller_ops)
 
/* Setup pci_dma ops */
set_pci_dma_ops(_iommu_ops);
+   of_node_put(dn);
 }
 
 #ifdef CONFIG_PM
-- 
2.35.1



[PATCH AUTOSEL 5.17 41/48] macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled

2022-06-01 Thread Sasha Levin
From: Finn Thain 

[ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ]

drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): undefined reference to `input_event'
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init':
via-pmu-event.c:(.init.text+0x20): undefined reference to 
`input_allocate_device'
via-pmu-event.c:(.init.text+0xc4): undefined reference to 
`input_register_device'
via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device'
make[1]: *** [Makefile:1155: vmlinux] Error 1
make: *** [Makefile:350: __build_one_by_one] Error 2

Don't call into the input subsystem unless CONFIG_INPUT is built-in.

Reported-by: kernel test robot 
Signed-off-by: Finn Thain 
Tested-by: Randy Dunlap 
Reviewed-by: Christophe Leroy 
Acked-by: Randy Dunlap 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fth...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/Kconfig   | 4 
 drivers/macintosh/Makefile  | 3 ++-
 drivers/macintosh/via-pmu.c | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 5cdc361da37c..3942db15a2b8 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -67,6 +67,10 @@ config ADB_PMU
  this device; you should do so if your machine is one of those
  mentioned above.
 
+config ADB_PMU_EVENT
+   def_bool y
+   depends on ADB_PMU && INPUT=y
+
 config ADB_PMU_LED
bool "Support for the Power/iBook front LED"
depends on PPC_PMAC && ADB_PMU
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 49819b1b6f20..712edcb3e0b0 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -12,7 +12,8 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN) += mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
 obj-$(CONFIG_ANSLCD)   += ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)  += via-pmu.o via-pmu-event.o
+obj-$(CONFIG_ADB_PMU)  += via-pmu.o
+obj-$(CONFIG_ADB_PMU_EVENT)+= via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)  += via-pmu-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)   += via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA) += via-cuda.o
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 4b98bc26a94b..2109129ea1bb 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1459,7 +1459,7 @@ pmu_handle_data(unsigned char *data, int len)
pmu_pass_intr(data, len);
/* len == 6 is probably a bad check. But how do I
 * know what PMU versions send what events here? */
-   if (len == 6) {
+   if (IS_ENABLED(CONFIG_ADB_PMU_EVENT) && len == 6) {
via_pmu_event(PMU_EVT_POWER, !!(data[1]&8));
via_pmu_event(PMU_EVT_LID, data[1]&1);
}
-- 
2.35.1



[PATCH AUTOSEL 5.17 40/48] powerpc/powernv: fix missing of_node_put in uv_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 3ffa9fd471f57f365bc54fc87824c530422f64a5 ]

of_find_compatible_node() returns node pointer with refcount incremented,
use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220407090043.2491854-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/ultravisor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/powernv/ultravisor.c 
b/arch/powerpc/platforms/powernv/ultravisor.c
index e4a00ad06f9d..67c8c4b2d8b1 100644
--- a/arch/powerpc/platforms/powernv/ultravisor.c
+++ b/arch/powerpc/platforms/powernv/ultravisor.c
@@ -55,6 +55,7 @@ static int __init uv_init(void)
return -ENODEV;
 
uv_memcons = memcons_init(node, "memcons");
+   of_node_put(node);
if (!uv_memcons)
return -ENOENT;
 
-- 
2.35.1



[PATCH AUTOSEL 5.17 39/48] powerpc/xics: fix refcount leak in icp_opal_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ]

The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/xics/icp-opal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/sysdev/xics/icp-opal.c 
b/arch/powerpc/sysdev/xics/icp-opal.c
index bda4c32582d9..4dae624b9f2f 100644
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -196,6 +196,7 @@ int __init icp_opal_init(void)
 
printk("XICS: Using OPAL ICP fallbacks\n");
 
+   of_node_put(np);
return 0;
 }
 
-- 
2.35.1



[PATCH AUTOSEL 5.17 38/48] powerpc/powernv/vas: Assign real address to rx_fifo in vas_rx_win_attr

2022-06-01 Thread Sasha Levin
From: Haren Myneni 

[ Upstream commit c127d130f6d59fa81701f6b04023cf7cd1972fb3 ]

In init_winctx_regs(), __pa() is called on winctx->rx_fifo and this
function is called to initialize registers for receive and fault
windows. But the real address is passed in winctx->rx_fifo for
receive windows and the virtual address for fault windows which
causes errors with DEBUG_VIRTUAL enabled. Fixes this issue by
assigning only real address to rx_fifo in vas_rx_win_attr struct
for both receive and fault windows.

Reported-by: Michael Ellerman 
Signed-off-by: Haren Myneni 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/338e958c7ab8f3b266fa794a1f80f99b9671829e.ca...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/asm/vas.h  | 2 +-
 arch/powerpc/platforms/powernv/vas-fault.c  | 2 +-
 arch/powerpc/platforms/powernv/vas-window.c | 4 ++--
 arch/powerpc/platforms/powernv/vas.h| 2 +-
 drivers/crypto/nx/nx-common-powernv.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index 57573d9c1e09..56834a8a1465 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -112,7 +112,7 @@ static inline void vas_user_win_add_mm_context(struct 
vas_user_win_ref *ref)
  * Receive window attributes specified by the (in-kernel) owner of window.
  */
 struct vas_rx_win_attr {
-   void *rx_fifo;
+   u64 rx_fifo;
int rx_fifo_size;
int wcreds_max;
 
diff --git a/arch/powerpc/platforms/powernv/vas-fault.c 
b/arch/powerpc/platforms/powernv/vas-fault.c
index a7aabc18039e..c1bfad56447d 100644
--- a/arch/powerpc/platforms/powernv/vas-fault.c
+++ b/arch/powerpc/platforms/powernv/vas-fault.c
@@ -216,7 +216,7 @@ int vas_setup_fault_window(struct vas_instance *vinst)
vas_init_rx_win_attr(, VAS_COP_TYPE_FAULT);
 
attr.rx_fifo_size = vinst->fault_fifo_size;
-   attr.rx_fifo = vinst->fault_fifo;
+   attr.rx_fifo = __pa(vinst->fault_fifo);
 
/*
 * Max creds is based on number of CRBs can fit in the FIFO.
diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 0f8d39fbf2b2..0072682531d8 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -404,7 +404,7 @@ static void init_winctx_regs(struct pnv_vas_window *window,
 *
 * See also: Design note in function header.
 */
-   val = __pa(winctx->rx_fifo);
+   val = winctx->rx_fifo;
val = SET_FIELD(VAS_PAGE_MIGRATION_SELECT, val, 0);
write_hvwc_reg(window, VREG(LFIFO_BAR), val);
 
@@ -739,7 +739,7 @@ static void init_winctx_for_rxwin(struct pnv_vas_window 
*rxwin,
 */
winctx->fifo_disable = true;
winctx->intr_disable = true;
-   winctx->rx_fifo = NULL;
+   winctx->rx_fifo = 0;
}
 
winctx->lnotify_lpid = rxattr->lnotify_lpid;
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index 8bb08e395de0..08d9d3d5a22b 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -376,7 +376,7 @@ struct pnv_vas_window {
  * is a container for the register fields in the window context.
  */
 struct vas_winctx {
-   void *rx_fifo;
+   u64 rx_fifo;
int rx_fifo_size;
int wcreds_max;
int rsvd_txbuf_count;
diff --git a/drivers/crypto/nx/nx-common-powernv.c 
b/drivers/crypto/nx/nx-common-powernv.c
index 32a036ada5d0..f418817c0f43 100644
--- a/drivers/crypto/nx/nx-common-powernv.c
+++ b/drivers/crypto/nx/nx-common-powernv.c
@@ -827,7 +827,7 @@ static int __init vas_cfg_coproc_info(struct device_node 
*dn, int chip_id,
goto err_out;
 
vas_init_rx_win_attr(, coproc->ct);
-   rxattr.rx_fifo = (void *)rx_fifo;
+   rxattr.rx_fifo = rx_fifo;
rxattr.rx_fifo_size = fifo_size;
rxattr.lnotify_lpid = lpid;
rxattr.lnotify_pid = pid;
-- 
2.35.1



[PATCH AUTOSEL 5.17 32/48] KVM: PPC: Book3S HV Nested: L2 LPCR should inherit L1 LPES setting

2022-06-01 Thread Sasha Levin
From: Nicholas Piggin 

[ Upstream commit 2852ebfa10afdcefff35ec72c8da97141df9845c ]

The L1 should not be able to adjust LPES mode for the L2. Setting LPES
if the L0 needs it clear would cause external interrupts to be sent to
L2 and missed by the L0.

Clearing LPES when it may be set, as typically happens with XIVE enabled
could cause a performance issue despite having no native XIVE support in
the guest, because it will cause mediated interrupts for the L2 to be
taken in HV mode, which then have to be injected.

Signed-off-by: Nicholas Piggin 
Reviewed-by: Fabiano Rosas 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220303053315.1056880-7-npig...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kvm/book3s_hv.c| 4 
 arch/powerpc/kvm/book3s_hv_nested.c | 3 +--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 316f61a4cb59..0da8c0df768d 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -5289,6 +5289,10 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
kvm->arch.host_lpcr = lpcr = mfspr(SPRN_LPCR);
lpcr &= LPCR_PECE | LPCR_LPES;
} else {
+   /*
+* The L2 LPES mode will be set by the L0 according to whether
+* or not it needs to take external interrupts in HV mode.
+*/
lpcr = 0;
}
lpcr |= (4UL << LPCR_DPFD_SH) | LPCR_HDICE |
diff --git a/arch/powerpc/kvm/book3s_hv_nested.c 
b/arch/powerpc/kvm/book3s_hv_nested.c
index 9d373f8963ee..58e05a9122ac 100644
--- a/arch/powerpc/kvm/book3s_hv_nested.c
+++ b/arch/powerpc/kvm/book3s_hv_nested.c
@@ -261,8 +261,7 @@ static void load_l2_hv_regs(struct kvm_vcpu *vcpu,
/*
 * Don't let L1 change LPCR bits for the L2 except these:
 */
-   mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD |
-   LPCR_LPES | LPCR_MER;
+   mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD | LPCR_MER;
 
/*
 * Additional filtering is required depending on hardware
-- 
2.35.1



[PATCH AUTOSEL 5.17 29/48] powerpc/rtas: Keep MSR[RI] set when calling RTAS

2022-06-01 Thread Sasha Levin
From: Laurent Dufour 

[ Upstream commit b6b1c3ce06ca438eb24e0f45bf0e63ecad0369f5 ]

RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32-bit big
endian mode (MSR[SF,LE] unset).

The change in MSR is done in enter_rtas() in a relatively complex way,
since the MSR value could be hardcoded.

Furthermore, a panic has been reported when hitting the watchdog interrupt
while running in RTAS, this leads to the following stack trace:

  watchdog: CPU 24 Hard LOCKUP
  watchdog: CPU 24 TB:997512652051031, last heartbeat TB:997504470175378 
(15980ms ago)
  ...
  Supported: No, Unreleased kernel
  CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: GE  X
5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 
0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
  NIP:  1fb41050 LR: 1fb4104c CTR: 
  REGS: cfc33d60 TRAP: 0100   Tainted: GE  X 
(5.14.21-150400.71.1.bz196362_2-default)
  MSR:  82981000   CR: 4882  XER: 20040020
  CFAR: 011c IRQMASK: 1
  GPR00: 0003  0001 50dc
  GPR04: 1ffb6100 0020 0001 1fb09010
  GPR08: 2000   
  GPR12: 8004072a40a8 cff8b680 0007 0034
  GPR16: 1fbf6e94 1fbf6d84 1fbd1db0 1fb3f008
  GPR20: 1fb41018  017f f68f
  GPR24: 1fb18fe8 1fb3e000 1fb1adc0 1fb1cf40
  GPR28: 1fb26000 1fb460f0 1fb17f18 1fb17000
  NIP [1fb41050] 0x1fb41050
  LR [1fb4104c] 0x1fb4104c
  Call Trace:
  Instruction dump:
         
         
  Oops: Unrecoverable System Reset, sig: 6 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  ...
  Supported: No, Unreleased kernel
  CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: GE  X
5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 
0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
  NIP:  1fb41050 LR: 1fb4104c CTR: 
  REGS: cfc33d60 TRAP: 0100   Tainted: GE  X 
(5.14.21-150400.71.1.bz196362_2-default)
  MSR:  82981000   CR: 4882  XER: 20040020
  CFAR: 011c IRQMASK: 1
  GPR00: 0003  0001 50dc
  GPR04: 1ffb6100 0020 0001 1fb09010
  GPR08: 2000   
  GPR12: 8004072a40a8 cff8b680 0007 0034
  GPR16: 1fbf6e94 1fbf6d84 1fbd1db0 1fb3f008
  GPR20: 1fb41018  017f f68f
  GPR24: 1fb18fe8 1fb3e000 1fb1adc0 1fb1cf40
  GPR28: 1fb26000 1fb460f0 1fb17f18 1fb17000
  NIP [1fb41050] 0x1fb41050
  LR [1fb4104c] 0x1fb4104c
  Call Trace:
  Instruction dump:
         
         
  ---[ end trace 3ddec07f638c34a2 ]---

This happens because MSR[RI] is unset when entering RTAS but there is no
valid reason to not set it here.

RTAS is expected to be called with MSR[RI] as specified in PAPR+ section
"7.2.1 Machine State":

  R1–7.2.1–9. If called with MSR[RI] equal to 1, then RTAS must protect
  its own critical regions from recursion by setting the MSR[RI] bit to
  0 when in the critical regions.

Fixing this by reviewing the way MSR is compute before calling RTAS. Now a
hardcoded value meaning real mode, 32 bits big endian mode and Recoverable
Interrupt is loaded. In the case MSR[S] is set, it will remain set while
entering RTAS as only urfid can unset it (thanks Fabiano).

In addition a check is added in do_enter_rtas() to detect calls made with
MSR[RI] unset, as we are forcing it on later.

This patch has been tested on the following machines:
Power KVM Guest
  P8 S822L (host Ubuntu kernel 5.11.0-49-generic)
PowerVM LPAR
  P8 9119-MME (FW860.A1)
  p9 9008-22L (FW950.00)
  P10 9080-HEX (FW1010.00)

Suggested-by: Nicholas Piggin 
Signed-off-by: Laurent Dufour 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220504101244.12107-1-lduf...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/entry_64.S | 24 
 arch/powerpc/kernel/rtas.c |  9 +
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9581906b5ee9..da18f83ef883 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ 

[PATCH AUTOSEL 5.17 20/48] powerpc/fadump: Fix fadump to work with a different endian capture kernel

2022-06-01 Thread Sasha Levin
From: Hari Bathini 

[ Upstream commit b74196af372f7cb4902179009265fe63ac81824f ]

Dump capture would fail if capture kernel is not of the endianess as the
production kernel, because the in-memory data structure (struct
opal_fadump_mem_struct) shared across production kernel and capture
kernel assumes the same endianess for both the kernels, which doesn't
have to be true always. Fix it by having a well-defined endianess for
struct opal_fadump_mem_struct.

Signed-off-by: Hari Bathini 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/161902744901.86147.14719228311655123526.stgit@hbathini
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal-fadump.c | 94 +++-
 arch/powerpc/platforms/powernv/opal-fadump.h | 10 +--
 2 files changed, 57 insertions(+), 47 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c 
b/arch/powerpc/platforms/powernv/opal-fadump.c
index c8ad057c7221..9d74d3950a52 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.c
+++ b/arch/powerpc/platforms/powernv/opal-fadump.c
@@ -60,7 +60,7 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, 
u64 node)
addr = be64_to_cpu(addr);
pr_debug("Kernel metadata addr: %llx\n", addr);
opal_fdm_active = (void *)addr;
-   if (opal_fdm_active->registered_regions == 0)
+   if (be16_to_cpu(opal_fdm_active->registered_regions) == 0)
return;
 
ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_BOOT_MEM, );
@@ -95,17 +95,17 @@ static int opal_fadump_unregister(struct fw_dump 
*fadump_conf);
 static void opal_fadump_update_config(struct fw_dump *fadump_conf,
  const struct opal_fadump_mem_struct *fdm)
 {
-   pr_debug("Boot memory regions count: %d\n", fdm->region_cnt);
+   pr_debug("Boot memory regions count: %d\n", 
be16_to_cpu(fdm->region_cnt));
 
/*
 * The destination address of the first boot memory region is the
 * destination address of boot memory regions.
 */
-   fadump_conf->boot_mem_dest_addr = fdm->rgn[0].dest;
+   fadump_conf->boot_mem_dest_addr = be64_to_cpu(fdm->rgn[0].dest);
pr_debug("Destination address of boot memory regions: %#016llx\n",
 fadump_conf->boot_mem_dest_addr);
 
-   fadump_conf->fadumphdr_addr = fdm->fadumphdr_addr;
+   fadump_conf->fadumphdr_addr = be64_to_cpu(fdm->fadumphdr_addr);
 }
 
 /*
@@ -126,9 +126,9 @@ static void __init opal_fadump_get_config(struct fw_dump 
*fadump_conf,
fadump_conf->boot_memory_size = 0;
 
pr_debug("Boot memory regions:\n");
-   for (i = 0; i < fdm->region_cnt; i++) {
-   base = fdm->rgn[i].src;
-   size = fdm->rgn[i].size;
+   for (i = 0; i < be16_to_cpu(fdm->region_cnt); i++) {
+   base = be64_to_cpu(fdm->rgn[i].src);
+   size = be64_to_cpu(fdm->rgn[i].size);
pr_debug("\t[%03d] base: 0x%lx, size: 0x%lx\n", i, base, size);
 
fadump_conf->boot_mem_addr[i] = base;
@@ -143,7 +143,7 @@ static void __init opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Start address of reserve dump area (permanent reservation) for
 * re-registering FADump after dump capture.
 */
-   fadump_conf->reserve_dump_area_start = fdm->rgn[0].dest;
+   fadump_conf->reserve_dump_area_start = be64_to_cpu(fdm->rgn[0].dest);
 
/*
 * Rarely, but it can so happen that system crashes before all
@@ -155,13 +155,14 @@ static void __init opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Hope the memory that could not be preserved only has pages
 * that are usually filtered out while saving the vmcore.
 */
-   if (fdm->region_cnt > fdm->registered_regions) {
+   if (be16_to_cpu(fdm->region_cnt) > 
be16_to_cpu(fdm->registered_regions)) {
pr_warn("Not all memory regions were saved!!!\n");
pr_warn("  Unsaved memory regions:\n");
-   i = fdm->registered_regions;
-   while (i < fdm->region_cnt) {
+   i = be16_to_cpu(fdm->registered_regions);
+   while (i < be16_to_cpu(fdm->region_cnt)) {
pr_warn("\t[%03d] base: 0x%llx, size: 0x%llx\n",
-   i, fdm->rgn[i].src, fdm->rgn[i].size);
+   i, be64_to_cpu(fdm->rgn[i].src),
+   be64_to_cpu(fdm->rgn[i].size));
i++;
}
 
@@ -170,7 +171,7 @@ static void __init opal_fadump_get_config(struct fw_dump 
*fadump_conf,
}
 
fadump_conf->boot_mem_top = (fadump_conf->boot_memory_size + hole_size);
-   fadump_conf->boot_mem_regs_cnt = fdm->region_cnt;
+   fadump_conf->boot_mem_regs_cnt = be16_to_cpu(fdm->region_cnt);
opal_fadump_update_config(fadump_conf, fdm);
 }
 
@@ -178,35 +179,38 @@ static void __init opal_fadump_get_config(struct 

[PATCH AUTOSEL 5.18 43/49] powerpc/iommu: Add missing of_node_put in iommu_init_early_dart

2022-06-01 Thread Sasha Levin
From: Peng Wu 

[ Upstream commit 57b742a5b8945118022973e6416b71351df512fb ]

The device_node pointer is returned by of_find_compatible_node
with refcount incremented. We should use of_node_put() to avoid
the refcount leak.

Signed-off-by: Peng Wu 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220425081245.21705-1-wupen...@huawei.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/dart_iommu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index be6b99b1b352..9a02aed886a0 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -404,9 +404,10 @@ void __init iommu_init_early_dart(struct 
pci_controller_ops *controller_ops)
}
 
/* Initialize the DART HW */
-   if (dart_init(dn) != 0)
+   if (dart_init(dn) != 0) {
+   of_node_put(dn);
return;
-
+   }
/*
 * U4 supports a DART bypass, we use it for 64-bit capable devices to
 * improve performance.  However, that only works for devices connected
@@ -419,6 +420,7 @@ void __init iommu_init_early_dart(struct pci_controller_ops 
*controller_ops)
 
/* Setup pci_dma ops */
set_pci_dma_ops(_iommu_ops);
+   of_node_put(dn);
 }
 
 #ifdef CONFIG_PM
-- 
2.35.1



[PATCH AUTOSEL 5.18 42/49] macintosh/via-pmu: Fix build failure when CONFIG_INPUT is disabled

2022-06-01 Thread Sasha Levin
From: Finn Thain 

[ Upstream commit 86ce436e30d86327c9f5260f718104ae7b21f506 ]

drivers/macintosh/via-pmu-event.o: In function `via_pmu_event':
via-pmu-event.c:(.text+0x44): undefined reference to `input_event'
via-pmu-event.c:(.text+0x68): undefined reference to `input_event'
via-pmu-event.c:(.text+0x94): undefined reference to `input_event'
via-pmu-event.c:(.text+0xb8): undefined reference to `input_event'
drivers/macintosh/via-pmu-event.o: In function `via_pmu_event_init':
via-pmu-event.c:(.init.text+0x20): undefined reference to 
`input_allocate_device'
via-pmu-event.c:(.init.text+0xc4): undefined reference to 
`input_register_device'
via-pmu-event.c:(.init.text+0xd4): undefined reference to `input_free_device'
make[1]: *** [Makefile:1155: vmlinux] Error 1
make: *** [Makefile:350: __build_one_by_one] Error 2

Don't call into the input subsystem unless CONFIG_INPUT is built-in.

Reported-by: kernel test robot 
Signed-off-by: Finn Thain 
Tested-by: Randy Dunlap 
Reviewed-by: Christophe Leroy 
Acked-by: Randy Dunlap 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/5edbe76ce68227f71e09af4614cc4c1bd61c7ec8.1649326292.git.fth...@linux-m68k.org
Signed-off-by: Sasha Levin 
---
 drivers/macintosh/Kconfig   | 4 
 drivers/macintosh/Makefile  | 3 ++-
 drivers/macintosh/via-pmu.c | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 5cdc361da37c..3942db15a2b8 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -67,6 +67,10 @@ config ADB_PMU
  this device; you should do so if your machine is one of those
  mentioned above.
 
+config ADB_PMU_EVENT
+   def_bool y
+   depends on ADB_PMU && INPUT=y
+
 config ADB_PMU_LED
bool "Support for the Power/iBook front LED"
depends on PPC_PMAC && ADB_PMU
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 49819b1b6f20..712edcb3e0b0 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -12,7 +12,8 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN) += mac_hid.o
 obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
 obj-$(CONFIG_ANSLCD)   += ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)  += via-pmu.o via-pmu-event.o
+obj-$(CONFIG_ADB_PMU)  += via-pmu.o
+obj-$(CONFIG_ADB_PMU_EVENT)+= via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)  += via-pmu-led.o
 obj-$(CONFIG_PMAC_BACKLIGHT)   += via-pmu-backlight.o
 obj-$(CONFIG_ADB_CUDA) += via-cuda.o
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 4b98bc26a94b..2109129ea1bb 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -1459,7 +1459,7 @@ pmu_handle_data(unsigned char *data, int len)
pmu_pass_intr(data, len);
/* len == 6 is probably a bad check. But how do I
 * know what PMU versions send what events here? */
-   if (len == 6) {
+   if (IS_ENABLED(CONFIG_ADB_PMU_EVENT) && len == 6) {
via_pmu_event(PMU_EVT_POWER, !!(data[1]&8));
via_pmu_event(PMU_EVT_LID, data[1]&1);
}
-- 
2.35.1



[PATCH AUTOSEL 5.18 41/49] powerpc/powernv: fix missing of_node_put in uv_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 3ffa9fd471f57f365bc54fc87824c530422f64a5 ]

of_find_compatible_node() returns node pointer with refcount incremented,
use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220407090043.2491854-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/ultravisor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/powernv/ultravisor.c 
b/arch/powerpc/platforms/powernv/ultravisor.c
index e4a00ad06f9d..67c8c4b2d8b1 100644
--- a/arch/powerpc/platforms/powernv/ultravisor.c
+++ b/arch/powerpc/platforms/powernv/ultravisor.c
@@ -55,6 +55,7 @@ static int __init uv_init(void)
return -ENODEV;
 
uv_memcons = memcons_init(node, "memcons");
+   of_node_put(node);
if (!uv_memcons)
return -ENOENT;
 
-- 
2.35.1



[PATCH AUTOSEL 5.18 40/49] powerpc/xics: fix refcount leak in icp_opal_init()

2022-06-01 Thread Sasha Levin
From: Lv Ruyi 

[ Upstream commit 5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9 ]

The of_find_compatible_node() function returns a node pointer with
refcount incremented, use of_node_put() on it when done.

Reported-by: Zeal Robot 
Signed-off-by: Lv Ruyi 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.r...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/powerpc/sysdev/xics/icp-opal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/sysdev/xics/icp-opal.c 
b/arch/powerpc/sysdev/xics/icp-opal.c
index bda4c32582d9..4dae624b9f2f 100644
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -196,6 +196,7 @@ int __init icp_opal_init(void)
 
printk("XICS: Using OPAL ICP fallbacks\n");
 
+   of_node_put(np);
return 0;
 }
 
-- 
2.35.1



[PATCH AUTOSEL 5.18 39/49] powerpc/powernv/vas: Assign real address to rx_fifo in vas_rx_win_attr

2022-06-01 Thread Sasha Levin
From: Haren Myneni 

[ Upstream commit c127d130f6d59fa81701f6b04023cf7cd1972fb3 ]

In init_winctx_regs(), __pa() is called on winctx->rx_fifo and this
function is called to initialize registers for receive and fault
windows. But the real address is passed in winctx->rx_fifo for
receive windows and the virtual address for fault windows which
causes errors with DEBUG_VIRTUAL enabled. Fixes this issue by
assigning only real address to rx_fifo in vas_rx_win_attr struct
for both receive and fault windows.

Reported-by: Michael Ellerman 
Signed-off-by: Haren Myneni 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/338e958c7ab8f3b266fa794a1f80f99b9671829e.ca...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/include/asm/vas.h  | 2 +-
 arch/powerpc/platforms/powernv/vas-fault.c  | 2 +-
 arch/powerpc/platforms/powernv/vas-window.c | 4 ++--
 arch/powerpc/platforms/powernv/vas.h| 2 +-
 drivers/crypto/nx/nx-common-powernv.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index 83afcb6c194b..c36f71e01c0f 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -126,7 +126,7 @@ static inline void vas_user_win_add_mm_context(struct 
vas_user_win_ref *ref)
  * Receive window attributes specified by the (in-kernel) owner of window.
  */
 struct vas_rx_win_attr {
-   void *rx_fifo;
+   u64 rx_fifo;
int rx_fifo_size;
int wcreds_max;
 
diff --git a/arch/powerpc/platforms/powernv/vas-fault.c 
b/arch/powerpc/platforms/powernv/vas-fault.c
index a7aabc18039e..c1bfad56447d 100644
--- a/arch/powerpc/platforms/powernv/vas-fault.c
+++ b/arch/powerpc/platforms/powernv/vas-fault.c
@@ -216,7 +216,7 @@ int vas_setup_fault_window(struct vas_instance *vinst)
vas_init_rx_win_attr(, VAS_COP_TYPE_FAULT);
 
attr.rx_fifo_size = vinst->fault_fifo_size;
-   attr.rx_fifo = vinst->fault_fifo;
+   attr.rx_fifo = __pa(vinst->fault_fifo);
 
/*
 * Max creds is based on number of CRBs can fit in the FIFO.
diff --git a/arch/powerpc/platforms/powernv/vas-window.c 
b/arch/powerpc/platforms/powernv/vas-window.c
index 0f8d39fbf2b2..0072682531d8 100644
--- a/arch/powerpc/platforms/powernv/vas-window.c
+++ b/arch/powerpc/platforms/powernv/vas-window.c
@@ -404,7 +404,7 @@ static void init_winctx_regs(struct pnv_vas_window *window,
 *
 * See also: Design note in function header.
 */
-   val = __pa(winctx->rx_fifo);
+   val = winctx->rx_fifo;
val = SET_FIELD(VAS_PAGE_MIGRATION_SELECT, val, 0);
write_hvwc_reg(window, VREG(LFIFO_BAR), val);
 
@@ -739,7 +739,7 @@ static void init_winctx_for_rxwin(struct pnv_vas_window 
*rxwin,
 */
winctx->fifo_disable = true;
winctx->intr_disable = true;
-   winctx->rx_fifo = NULL;
+   winctx->rx_fifo = 0;
}
 
winctx->lnotify_lpid = rxattr->lnotify_lpid;
diff --git a/arch/powerpc/platforms/powernv/vas.h 
b/arch/powerpc/platforms/powernv/vas.h
index 8bb08e395de0..08d9d3d5a22b 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -376,7 +376,7 @@ struct pnv_vas_window {
  * is a container for the register fields in the window context.
  */
 struct vas_winctx {
-   void *rx_fifo;
+   u64 rx_fifo;
int rx_fifo_size;
int wcreds_max;
int rsvd_txbuf_count;
diff --git a/drivers/crypto/nx/nx-common-powernv.c 
b/drivers/crypto/nx/nx-common-powernv.c
index 32a036ada5d0..f418817c0f43 100644
--- a/drivers/crypto/nx/nx-common-powernv.c
+++ b/drivers/crypto/nx/nx-common-powernv.c
@@ -827,7 +827,7 @@ static int __init vas_cfg_coproc_info(struct device_node 
*dn, int chip_id,
goto err_out;
 
vas_init_rx_win_attr(, coproc->ct);
-   rxattr.rx_fifo = (void *)rx_fifo;
+   rxattr.rx_fifo = rx_fifo;
rxattr.rx_fifo_size = fifo_size;
rxattr.lnotify_lpid = lpid;
rxattr.lnotify_pid = pid;
-- 
2.35.1



[PATCH AUTOSEL 5.18 33/49] KVM: PPC: Book3S HV Nested: L2 LPCR should inherit L1 LPES setting

2022-06-01 Thread Sasha Levin
From: Nicholas Piggin 

[ Upstream commit 2852ebfa10afdcefff35ec72c8da97141df9845c ]

The L1 should not be able to adjust LPES mode for the L2. Setting LPES
if the L0 needs it clear would cause external interrupts to be sent to
L2 and missed by the L0.

Clearing LPES when it may be set, as typically happens with XIVE enabled
could cause a performance issue despite having no native XIVE support in
the guest, because it will cause mediated interrupts for the L2 to be
taken in HV mode, which then have to be injected.

Signed-off-by: Nicholas Piggin 
Reviewed-by: Fabiano Rosas 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220303053315.1056880-7-npig...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kvm/book3s_hv.c| 4 
 arch/powerpc/kvm/book3s_hv_nested.c | 3 +--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 6fa518f6501d..43af871383c2 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -5283,6 +5283,10 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
kvm->arch.host_lpcr = lpcr = mfspr(SPRN_LPCR);
lpcr &= LPCR_PECE | LPCR_LPES;
} else {
+   /*
+* The L2 LPES mode will be set by the L0 according to whether
+* or not it needs to take external interrupts in HV mode.
+*/
lpcr = 0;
}
lpcr |= (4UL << LPCR_DPFD_SH) | LPCR_HDICE |
diff --git a/arch/powerpc/kvm/book3s_hv_nested.c 
b/arch/powerpc/kvm/book3s_hv_nested.c
index c943a051c6e7..265bb30a0af2 100644
--- a/arch/powerpc/kvm/book3s_hv_nested.c
+++ b/arch/powerpc/kvm/book3s_hv_nested.c
@@ -261,8 +261,7 @@ static void load_l2_hv_regs(struct kvm_vcpu *vcpu,
/*
 * Don't let L1 change LPCR bits for the L2 except these:
 */
-   mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD |
-   LPCR_LPES | LPCR_MER;
+   mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD | LPCR_MER;
 
/*
 * Additional filtering is required depending on hardware
-- 
2.35.1



[PATCH AUTOSEL 5.18 30/49] powerpc/rtas: Keep MSR[RI] set when calling RTAS

2022-06-01 Thread Sasha Levin
From: Laurent Dufour 

[ Upstream commit b6b1c3ce06ca438eb24e0f45bf0e63ecad0369f5 ]

RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32-bit big
endian mode (MSR[SF,LE] unset).

The change in MSR is done in enter_rtas() in a relatively complex way,
since the MSR value could be hardcoded.

Furthermore, a panic has been reported when hitting the watchdog interrupt
while running in RTAS, this leads to the following stack trace:

  watchdog: CPU 24 Hard LOCKUP
  watchdog: CPU 24 TB:997512652051031, last heartbeat TB:997504470175378 
(15980ms ago)
  ...
  Supported: No, Unreleased kernel
  CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: GE  X
5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 
0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
  NIP:  1fb41050 LR: 1fb4104c CTR: 
  REGS: cfc33d60 TRAP: 0100   Tainted: GE  X 
(5.14.21-150400.71.1.bz196362_2-default)
  MSR:  82981000   CR: 4882  XER: 20040020
  CFAR: 011c IRQMASK: 1
  GPR00: 0003  0001 50dc
  GPR04: 1ffb6100 0020 0001 1fb09010
  GPR08: 2000   
  GPR12: 8004072a40a8 cff8b680 0007 0034
  GPR16: 1fbf6e94 1fbf6d84 1fbd1db0 1fb3f008
  GPR20: 1fb41018  017f f68f
  GPR24: 1fb18fe8 1fb3e000 1fb1adc0 1fb1cf40
  GPR28: 1fb26000 1fb460f0 1fb17f18 1fb17000
  NIP [1fb41050] 0x1fb41050
  LR [1fb4104c] 0x1fb4104c
  Call Trace:
  Instruction dump:
         
         
  Oops: Unrecoverable System Reset, sig: 6 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  ...
  Supported: No, Unreleased kernel
  CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: GE  X
5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 
0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c
  NIP:  1fb41050 LR: 1fb4104c CTR: 
  REGS: cfc33d60 TRAP: 0100   Tainted: GE  X 
(5.14.21-150400.71.1.bz196362_2-default)
  MSR:  82981000   CR: 4882  XER: 20040020
  CFAR: 011c IRQMASK: 1
  GPR00: 0003  0001 50dc
  GPR04: 1ffb6100 0020 0001 1fb09010
  GPR08: 2000   
  GPR12: 8004072a40a8 cff8b680 0007 0034
  GPR16: 1fbf6e94 1fbf6d84 1fbd1db0 1fb3f008
  GPR20: 1fb41018  017f f68f
  GPR24: 1fb18fe8 1fb3e000 1fb1adc0 1fb1cf40
  GPR28: 1fb26000 1fb460f0 1fb17f18 1fb17000
  NIP [1fb41050] 0x1fb41050
  LR [1fb4104c] 0x1fb4104c
  Call Trace:
  Instruction dump:
         
         
  ---[ end trace 3ddec07f638c34a2 ]---

This happens because MSR[RI] is unset when entering RTAS but there is no
valid reason to not set it here.

RTAS is expected to be called with MSR[RI] as specified in PAPR+ section
"7.2.1 Machine State":

  R1–7.2.1–9. If called with MSR[RI] equal to 1, then RTAS must protect
  its own critical regions from recursion by setting the MSR[RI] bit to
  0 when in the critical regions.

Fixing this by reviewing the way MSR is compute before calling RTAS. Now a
hardcoded value meaning real mode, 32 bits big endian mode and Recoverable
Interrupt is loaded. In the case MSR[S] is set, it will remain set while
entering RTAS as only urfid can unset it (thanks Fabiano).

In addition a check is added in do_enter_rtas() to detect calls made with
MSR[RI] unset, as we are forcing it on later.

This patch has been tested on the following machines:
Power KVM Guest
  P8 S822L (host Ubuntu kernel 5.11.0-49-generic)
PowerVM LPAR
  P8 9119-MME (FW860.A1)
  p9 9008-22L (FW950.00)
  P10 9080-HEX (FW1010.00)

Suggested-by: Nicholas Piggin 
Signed-off-by: Laurent Dufour 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220504101244.12107-1-lduf...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/entry_64.S | 24 
 arch/powerpc/kernel/rtas.c |  9 +
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9581906b5ee9..da18f83ef883 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ 

[PATCH AUTOSEL 5.18 20/49] powerpc/fadump: Fix fadump to work with a different endian capture kernel

2022-06-01 Thread Sasha Levin
From: Hari Bathini 

[ Upstream commit b74196af372f7cb4902179009265fe63ac81824f ]

Dump capture would fail if capture kernel is not of the endianess as the
production kernel, because the in-memory data structure (struct
opal_fadump_mem_struct) shared across production kernel and capture
kernel assumes the same endianess for both the kernels, which doesn't
have to be true always. Fix it by having a well-defined endianess for
struct opal_fadump_mem_struct.

Signed-off-by: Hari Bathini 
Signed-off-by: Michael Ellerman 
Link: 
https://lore.kernel.org/r/161902744901.86147.14719228311655123526.stgit@hbathini
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal-fadump.c | 94 +++-
 arch/powerpc/platforms/powernv/opal-fadump.h | 10 +--
 2 files changed, 57 insertions(+), 47 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-fadump.c 
b/arch/powerpc/platforms/powernv/opal-fadump.c
index c8ad057c7221..9d74d3950a52 100644
--- a/arch/powerpc/platforms/powernv/opal-fadump.c
+++ b/arch/powerpc/platforms/powernv/opal-fadump.c
@@ -60,7 +60,7 @@ void __init opal_fadump_dt_scan(struct fw_dump *fadump_conf, 
u64 node)
addr = be64_to_cpu(addr);
pr_debug("Kernel metadata addr: %llx\n", addr);
opal_fdm_active = (void *)addr;
-   if (opal_fdm_active->registered_regions == 0)
+   if (be16_to_cpu(opal_fdm_active->registered_regions) == 0)
return;
 
ret = opal_mpipl_query_tag(OPAL_MPIPL_TAG_BOOT_MEM, );
@@ -95,17 +95,17 @@ static int opal_fadump_unregister(struct fw_dump 
*fadump_conf);
 static void opal_fadump_update_config(struct fw_dump *fadump_conf,
  const struct opal_fadump_mem_struct *fdm)
 {
-   pr_debug("Boot memory regions count: %d\n", fdm->region_cnt);
+   pr_debug("Boot memory regions count: %d\n", 
be16_to_cpu(fdm->region_cnt));
 
/*
 * The destination address of the first boot memory region is the
 * destination address of boot memory regions.
 */
-   fadump_conf->boot_mem_dest_addr = fdm->rgn[0].dest;
+   fadump_conf->boot_mem_dest_addr = be64_to_cpu(fdm->rgn[0].dest);
pr_debug("Destination address of boot memory regions: %#016llx\n",
 fadump_conf->boot_mem_dest_addr);
 
-   fadump_conf->fadumphdr_addr = fdm->fadumphdr_addr;
+   fadump_conf->fadumphdr_addr = be64_to_cpu(fdm->fadumphdr_addr);
 }
 
 /*
@@ -126,9 +126,9 @@ static void __init opal_fadump_get_config(struct fw_dump 
*fadump_conf,
fadump_conf->boot_memory_size = 0;
 
pr_debug("Boot memory regions:\n");
-   for (i = 0; i < fdm->region_cnt; i++) {
-   base = fdm->rgn[i].src;
-   size = fdm->rgn[i].size;
+   for (i = 0; i < be16_to_cpu(fdm->region_cnt); i++) {
+   base = be64_to_cpu(fdm->rgn[i].src);
+   size = be64_to_cpu(fdm->rgn[i].size);
pr_debug("\t[%03d] base: 0x%lx, size: 0x%lx\n", i, base, size);
 
fadump_conf->boot_mem_addr[i] = base;
@@ -143,7 +143,7 @@ static void __init opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Start address of reserve dump area (permanent reservation) for
 * re-registering FADump after dump capture.
 */
-   fadump_conf->reserve_dump_area_start = fdm->rgn[0].dest;
+   fadump_conf->reserve_dump_area_start = be64_to_cpu(fdm->rgn[0].dest);
 
/*
 * Rarely, but it can so happen that system crashes before all
@@ -155,13 +155,14 @@ static void __init opal_fadump_get_config(struct fw_dump 
*fadump_conf,
 * Hope the memory that could not be preserved only has pages
 * that are usually filtered out while saving the vmcore.
 */
-   if (fdm->region_cnt > fdm->registered_regions) {
+   if (be16_to_cpu(fdm->region_cnt) > 
be16_to_cpu(fdm->registered_regions)) {
pr_warn("Not all memory regions were saved!!!\n");
pr_warn("  Unsaved memory regions:\n");
-   i = fdm->registered_regions;
-   while (i < fdm->region_cnt) {
+   i = be16_to_cpu(fdm->registered_regions);
+   while (i < be16_to_cpu(fdm->region_cnt)) {
pr_warn("\t[%03d] base: 0x%llx, size: 0x%llx\n",
-   i, fdm->rgn[i].src, fdm->rgn[i].size);
+   i, be64_to_cpu(fdm->rgn[i].src),
+   be64_to_cpu(fdm->rgn[i].size));
i++;
}
 
@@ -170,7 +171,7 @@ static void __init opal_fadump_get_config(struct fw_dump 
*fadump_conf,
}
 
fadump_conf->boot_mem_top = (fadump_conf->boot_memory_size + hole_size);
-   fadump_conf->boot_mem_regs_cnt = fdm->region_cnt;
+   fadump_conf->boot_mem_regs_cnt = be16_to_cpu(fdm->region_cnt);
opal_fadump_update_config(fadump_conf, fdm);
 }
 
@@ -178,35 +179,38 @@ static void __init opal_fadump_get_config(struct 

Re: [PATCH] ASoC: fsl: Check before clk_put() not needed

2022-06-01 Thread Sascha Hauer
On Wed, Jun 01, 2022 at 06:14:29AM -0700, Yihao Han wrote:
> clk_put() already checks the clk ptr using !clk and IS_ERR()
> so there is no need to check it again before calling it.
> 
> Signed-off-by: Yihao Han 
> ---
>  sound/soc/fsl/imx-sgtl5000.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
> index 580a0d963f0e..16a281820186 100644
> --- a/sound/soc/fsl/imx-sgtl5000.c
> +++ b/sound/soc/fsl/imx-sgtl5000.c
> @@ -185,8 +185,7 @@ static int imx_sgtl5000_probe(struct platform_device 
> *pdev)
>  put_device:
>   put_device(_dev->dev);
>  fail:
> - if (data && !IS_ERR(data->codec_clk))
> - clk_put(data->codec_clk);
> + clk_put(data->codec_clk);

The fail label is used before data is initialized, so the if (data)
check is really needed.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


[PATCH] ASoC: fsl: Check before clk_put() not needed

2022-06-01 Thread Yihao Han
clk_put() already checks the clk ptr using !clk and IS_ERR()
so there is no need to check it again before calling it.

Signed-off-by: Yihao Han 
---
 sound/soc/fsl/imx-sgtl5000.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index 580a0d963f0e..16a281820186 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -185,8 +185,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
 put_device:
put_device(_dev->dev);
 fail:
-   if (data && !IS_ERR(data->codec_clk))
-   clk_put(data->codec_clk);
+   clk_put(data->codec_clk);
of_node_put(ssi_np);
of_node_put(codec_np);
 
-- 
2.17.1



Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-06-01 Thread Rob Herring
On Tue, May 31, 2022 at 06:29:38PM +0200, Christian Zigotzky wrote:
> 
> 
> > On 31. May 2022, at 15:46, Rob Herring  wrote:
> > 
> > On Mon, May 30, 2022 at 12:26 AM Christian Zigotzky
> >  wrote:
> >> 
> >>> On 27 May 2022 at 04:23 pm, Rob Herring wrote:
> >>> The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
> >>> resources to a child platform device. Can you try the following
> >>> change:
> >>> 
> >>> diff --git a/drivers/usb/host/fsl-mph-dr-of.c 
> >>> b/drivers/usb/host/fsl-mph-dr-of.c
> >>> index 44a7e58a26e3..47d9b7be60da 100644
> >>> --- a/drivers/usb/host/fsl-mph-dr-of.c
> >>> +++ b/drivers/usb/host/fsl-mph-dr-of.c
> >>> @@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
> >>> const char *name, int id)
> >>>  {
> >>> struct platform_device *pdev;
> >>> -   const struct resource *res = ofdev->resource;
> >>> -   unsigned int num = ofdev->num_resources;
> >>> int retval;
> >>> 
> >>> pdev = platform_device_alloc(name, id);
> >>> @@ -106,11 +104,7 @@ static struct platform_device 
> >>> *fsl_usb2_device_register(
> >>> if (retval)
> >>> goto error;
> >>> 
> >>> -   if (num) {
> >>> -   retval = platform_device_add_resources(pdev, res, num);
> >>> -   if (retval)
> >>> -   goto error;
> >>> -   }
> >>> +   pdev->dev.of_node = ofdev->dev.of_node;
> >>> 
> >>> retval = platform_device_add(pdev);
> >>> if (retval)
> >> Hello Rob,
> >> 
> >> Thanks a lot for your patch! Unfortunately, this leads to a boot loop.
> >> Do you have another idea?
> > 
> > Do you have a dmesg log?
> 
> From the boot loop?

Yes.

> 
> > 
> > The other way to fix is creating a IRQ resource and adding it to the
> > child device resources.
> 
> Good idea.

Not really. I'd rather have the child device just point to the DT node, 
but that doesn't seem to work for some drivers and I want to understand 
why.

Rob


Re: [PATCH 2/6] powerpc: Provide syscall wrapper

2022-06-01 Thread kernel test robot
Hi Rohan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v5.18]
[also build test ERROR on next-20220601]
[cannot apply to powerpc/next scottwood/next]
[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]

url:
https://github.com/intel-lab-lkp/linux/commits/Rohan-McLure/powerpc-Add-ZERO_GPRS-macros-for-register-clears/20220601-135400
base:4b0986a3613c92f4ec1bdc7f60ec66fea135991f
config: powerpc64-allnoconfig 
(https://download.01.org/0day-ci/archive/20220601/202206012020.14r31w6c-...@intel.com/config)
compiler: powerpc64-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/c3efdfac99806b0d7ef4ee781283404448addc69
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Rohan-McLure/powerpc-Add-ZERO_GPRS-macros-for-register-clears/20220601-135400
git checkout c3efdfac99806b0d7ef4ee781283404448addc69
# 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 >>):

   In file included from include/linux/syscalls.h:98,
from arch/powerpc/kernel/signal_64.c:23:
>> arch/powerpc/include/asm/syscall_wrapper.h:78:14: error: no previous 
>> prototype for 'sys_rt_sigreturn' [-Werror=missing-prototypes]
  78 | long sys_##sname(void)   
   \
 |  ^~~~
   arch/powerpc/kernel/signal_64.c:736:1: note: in expansion of macro 
'SYSCALL_DEFINE0'
 736 | SYSCALL_DEFINE0(rt_sigreturn)
 | ^~~
   cc1: all warnings being treated as errors


vim +/sys_rt_sigreturn +78 arch/powerpc/include/asm/syscall_wrapper.h

49  
50  #define __SYSCALL_DEFINEx(x, name, ...) 
\
51  asmlinkage long __powerpc_sys##name(const struct pt_regs 
*regs);\
52  ALLOW_ERROR_INJECTION(__powerpc_sys##name, ERRNO);  
\
53  long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)); 
\
54  static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)); 
\
55  static inline long 
__do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));  \
56  asmlinkage long __powerpc_sys##name(const struct pt_regs *regs) 
\
57  {   
\
58  return 
__se_sys##name(SC_POWERPC_REGS_TO_ARGS(x,__VA_ARGS__));  \
59  }   
\
60  long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))  
\
61  {   
\
62  return __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));  
\
63  }   
\
64  static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))  
\
65  {   
\
66  long ret = 
__do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));  \
67  __MAP(x,__SC_TEST,__VA_ARGS__); 
\
68  __PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__));   
\
69  return ret; 
\
70  }   
\
71  static inline long 
__do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
72  
73  #define SYSCALL_DEFINE0(sname)  
\
74  SYSCALL_METADATA(_##sname, 0);  
\
75  long sys_##name(void);  
\
76  asmlinkage long __powerpc_sys_##sname(const struct pt_regs 
*__unused);  \
77  ALLOW_ERROR_INJECTION(__powerpc_sys_##sname, ERRNO);
\
  > 78  long sys_##sname(void)  
\
79  {   
\
80  retu

Re: [PATCH] powerpc/64: Drop ppc_inst_as_str()

2022-06-01 Thread Michael Ellerman
Segher Boessenkool  writes:
> Hi!
>
> On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote:
>> More problematically it doesn't compile at all with GCC 12, due to the
>> fact that it returns the char buffer declared inside the macro:
>
> It returns a pointer to a buffer on stack.  It is not valid C to access
> that buffer after the function has returned (and indeed it does not
> work, in general).

It's a statement expression though, not a function. So it doesn't return
as such, that would be obviously wrong.

But I'm not a language lawyer, so presumably it's not valid to refer to
the variable after it's gone out of scope.

Although we do use that same pattern in many places where the value of
the expression is a scalar type.

>> A simpler solution is to just print the value as an unsigned long. For
>> normal instructions the output is identical. For prefixed instructions
>> the value is printed as a single 64-bit quantity, whereas previously the
>> low half was printed first. But that is good enough for debug output,
>> especially as prefixed instructions will be rare in practice.
>
> Prefixed insns might be somewhat rare currently, but it will not stay
> that way.

These are all printing kernel instructions, not userspace. I should have
said that in the change log.

The kernel doesn't build for -mcpu=power10 because we haven't done any
changes for pcrel.

We will do that one day, but not soon.

> It is not hard to fix the problem here?  The only tricky part is that
> ppc_inst_as_ulong swaps the two halves for LE, for as far as I can see
> no reason at all :-(
>
> If it didn't it would be easy to detect prefixed insns (because they
> then are guaranteed to be > 0x), and it is easy to print them
> with a space between the two opcodes, with a utility function:
>
> void print_insn_bytes_nicely(unsigned long insn)
> {
>   if (insn > 0x)
>   printf("%08x ", insn >> 32);
>   printf("%08x", insn & 0x);
> }

We don't want to do that because it can lead to interleaving messages
between different CPUs in the kernel log.

In the medium term there's some changes to printk that might land soon
(printbuf), which would mean we could more easily define a custom printk
formatter for printing prefixed instructions.

cheers


Re: [PATCH 2/6] powerpc: Provide syscall wrapper

2022-06-01 Thread kernel test robot
Hi Rohan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v5.18]
[also build test ERROR on next-20220601]
[cannot apply to powerpc/next scottwood/next]
[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]

url:
https://github.com/intel-lab-lkp/linux/commits/Rohan-McLure/powerpc-Add-ZERO_GPRS-macros-for-register-clears/20220601-135400
base:4b0986a3613c92f4ec1bdc7f60ec66fea135991f
config: powerpc-allnoconfig 
(https://download.01.org/0day-ci/archive/20220601/202206011740.fugdnwnm-...@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/c3efdfac99806b0d7ef4ee781283404448addc69
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Rohan-McLure/powerpc-Add-ZERO_GPRS-macros-for-register-clears/20220601-135400
git checkout c3efdfac99806b0d7ef4ee781283404448addc69
# 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/ fs/ kernel/ mm/

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

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/syscalls.h:98,
from arch/powerpc/kernel/syscalls.c:19:
>> arch/powerpc/include/asm/syscall_wrapper.h:78:14: error: no previous 
>> prototype for 'sys_switch_endian' [-Werror=missing-prototypes]
  78 | long sys_##sname(void)   
   \
 |  ^~~~
   arch/powerpc/kernel/syscalls.c:114:1: note: in expansion of macro 
'SYSCALL_DEFINE0'
 114 | SYSCALL_DEFINE0(switch_endian)
 | ^~~
   cc1: all warnings being treated as errors
--
   kernel/fork.c:163:13: warning: no previous prototype for 
'arch_release_task_struct' [-Wmissing-prototypes]
 163 | void __weak arch_release_task_struct(struct task_struct *tsk)
 | ^~~~
   kernel/fork.c:854:20: warning: no previous prototype for 
'arch_task_cache_init' [-Wmissing-prototypes]
 854 | void __init __weak arch_task_cache_init(void) { }
 |^~~~
   In file included from include/linux/syscalls.h:98,
from kernel/fork.c:55:
>> arch/powerpc/include/asm/syscall_wrapper.h:78:14: warning: no previous 
>> prototype for 'sys_fork' [-Wmissing-prototypes]
  78 | long sys_##sname(void)   
   \
 |  ^~~~
   kernel/fork.c:2695:1: note: in expansion of macro 'SYSCALL_DEFINE0'
2695 | SYSCALL_DEFINE0(fork)
 | ^~~
>> arch/powerpc/include/asm/syscall_wrapper.h:78:14: warning: no previous 
>> prototype for 'sys_vfork' [-Wmissing-prototypes]
  78 | long sys_##sname(void)   
   \
 |  ^~~~
   kernel/fork.c:2711:1: note: in expansion of macro 'SYSCALL_DEFINE0'
2711 | SYSCALL_DEFINE0(vfork)
 | ^~~
--
   In file included from include/linux/syscalls.h:98,
from kernel/signal.c:30:
>> arch/powerpc/include/asm/syscall_wrapper.h:78:14: warning: no previous 
>> prototype for 'sys_restart_syscall' [-Wmissing-prototypes]
  78 | long sys_##sname(void)   
   \
 |  ^~~~
   kernel/signal.c:3004:1: note: in expansion of macro 'SYSCALL_DEFINE0'
3004 | SYSCALL_DEFINE0(restart_syscall)
 | ^~~
>> arch/powerpc/include/asm/syscall_wrapper.h:78:14: warning: no previous 
>> prototype for 'sys_sgetmask' [-Wmissing-prototypes]
  78 | long sys_##sname(void)   
   \
 |  ^~~~
   kernel/signal.c:4568:1: note: in expansion of macro 'SYSCALL_DEFINE0'
4568 | SYSCALL_DEFINE0(sgetmask)
 | ^~~
>> arch/powerpc/include/asm/syscall_wrapper.h:78:14: warning: no previous 
>> prototype for 'sys_pause' [-Wmissing-prototypes]
  78 | long sys_##sname(void)   
   \
 |  ^~~~
   kernel/signal.c:4607:1: note: in expansion of macro 'SYSCALL_DEFINE0'
4607 | SYSCALL_DEFINE0(pause)
 | ^~~
--
   In file included from include/linux/compat.h:34,
from kernel/sys.c:47:
&

[PATCH 2/3] ASoC: fsl_sai: convert to dev_err_probe

2022-06-01 Thread Marco Felsch
Make use of the new macro to get device defered information for free
and to cleanup the code a bit. No functional changes.

Signed-off-by: Marco Felsch 
---
 sound/soc/fsl/fsl_sai.c | 33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index a7637d602f3c..3e54f1f71c1e 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1034,21 +1034,15 @@ static int fsl_sai_probe(struct platform_device *pdev)
}
 
sai->regmap = devm_regmap_init_mmio(dev, base, _sai_regmap_config);
-   if (IS_ERR(sai->regmap)) {
-   dev_err(dev, "regmap init failed\n");
-   return PTR_ERR(sai->regmap);
-   }
+   if (IS_ERR(sai->regmap))
+   return dev_err_probe(dev, PTR_ERR(sai->regmap), "regmap init 
failed\n");
 
sai->bus_clk = devm_clk_get(dev, "bus");
/* Compatible with old DTB cases */
if (IS_ERR(sai->bus_clk) && PTR_ERR(sai->bus_clk) != -EPROBE_DEFER)
sai->bus_clk = devm_clk_get(dev, "sai");
-   if (IS_ERR(sai->bus_clk)) {
-   dev_err(dev, "failed to get bus clock: %ld\n",
-   PTR_ERR(sai->bus_clk));
-   /* -EPROBE_DEFER */
-   return PTR_ERR(sai->bus_clk);
-   }
+   if (IS_ERR(sai->bus_clk))
+   return dev_err_probe(dev, PTR_ERR(sai->bus_clk), "failed to get 
bus clock\n");
 
for (i = 1; i < FSL_SAI_MCLK_MAX; i++) {
sprintf(tmp, "mclk%d", i);
@@ -1067,14 +1061,12 @@ static int fsl_sai_probe(struct platform_device *pdev)
 
irq = platform_get_irq(pdev, 0);
if (irq < 0)
-   return irq;
+   return dev_err_probe(dev, irq, "failed to get the irq\n");
 
ret = devm_request_irq(dev, irq, fsl_sai_isr, IRQF_SHARED,
   np->name, sai);
-   if (ret) {
-   dev_err(dev, "failed to claim irq %u\n", irq);
-   return ret;
-   }
+   if (ret)
+   return dev_err_probe(dev, ret, "failed to claim irq %u\n", irq);
 
memcpy(>cpu_dai_drv, _sai_dai_template,
   sizeof(fsl_sai_dai_template));
@@ -1089,8 +1081,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
if (of_find_property(np, "fsl,sai-synchronous-rx", NULL) &&
of_find_property(np, "fsl,sai-asynchronous", NULL)) {
/* error out if both synchronous and asynchronous are present */
-   dev_err(dev, "invalid binding for synchronous mode\n");
-   return -EINVAL;
+   return dev_err_probe(dev, -EINVAL, "invalid binding for 
synchronous mode\n");
}
 
if (of_find_property(np, "fsl,sai-synchronous-rx", NULL)) {
@@ -1109,14 +1100,12 @@ static int fsl_sai_probe(struct platform_device *pdev)
if (of_find_property(np, "fsl,sai-mclk-direction-output", NULL) &&
of_device_is_compatible(np, "fsl,imx6ul-sai")) {
gpr = 
syscon_regmap_lookup_by_compatible("fsl,imx6ul-iomuxc-gpr");
-   if (IS_ERR(gpr)) {
-   dev_err(dev, "cannot find iomuxc registers\n");
-   return PTR_ERR(gpr);
-   }
+   if (IS_ERR(gpr))
+   return dev_err_probe(dev, PTR_ERR(gpr), "cannot find 
iomuxc registers\n");
 
index = of_alias_get_id(np, "sai");
if (index < 0)
-   return index;
+   return dev_err_probe(dev, index, "cannot find sai 
aliases\n");
 
regmap_update_bits(gpr, IOMUXC_GPR1, MCLK_DIR(index),
   MCLK_DIR(index));
-- 
2.30.2



[PATCH 1/3] ASoC: fsl_sai: use local device pointer

2022-06-01 Thread Marco Felsch
Use a local variable to dereference the device pointer once and use the
local variable in further calls. No functional changes.

Signed-off-by: Marco Felsch 
---
 sound/soc/fsl/fsl_sai.c | 53 +
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index fa950dde5310..a7637d602f3c 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1004,6 +1004,7 @@ static int fsl_sai_runtime_resume(struct device *dev);
 static int fsl_sai_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
+   struct device *dev = >dev;
struct fsl_sai *sai;
struct regmap *gpr;
struct resource *res;
@@ -1012,12 +1013,12 @@ static int fsl_sai_probe(struct platform_device *pdev)
int irq, ret, i;
int index;
 
-   sai = devm_kzalloc(>dev, sizeof(*sai), GFP_KERNEL);
+   sai = devm_kzalloc(dev, sizeof(*sai), GFP_KERNEL);
if (!sai)
return -ENOMEM;
 
sai->pdev = pdev;
-   sai->soc_data = of_device_get_match_data(>dev);
+   sai->soc_data = of_device_get_match_data(dev);
 
sai->is_lsb_first = of_property_read_bool(np, "lsb-first");
 
@@ -1032,18 +1033,18 @@ static int fsl_sai_probe(struct platform_device *pdev)
ARRAY_SIZE(fsl_sai_reg_defaults_ofs8);
}
 
-   sai->regmap = devm_regmap_init_mmio(>dev, base, 
_sai_regmap_config);
+   sai->regmap = devm_regmap_init_mmio(dev, base, _sai_regmap_config);
if (IS_ERR(sai->regmap)) {
-   dev_err(>dev, "regmap init failed\n");
+   dev_err(dev, "regmap init failed\n");
return PTR_ERR(sai->regmap);
}
 
-   sai->bus_clk = devm_clk_get(>dev, "bus");
+   sai->bus_clk = devm_clk_get(dev, "bus");
/* Compatible with old DTB cases */
if (IS_ERR(sai->bus_clk) && PTR_ERR(sai->bus_clk) != -EPROBE_DEFER)
-   sai->bus_clk = devm_clk_get(>dev, "sai");
+   sai->bus_clk = devm_clk_get(dev, "sai");
if (IS_ERR(sai->bus_clk)) {
-   dev_err(>dev, "failed to get bus clock: %ld\n",
+   dev_err(dev, "failed to get bus clock: %ld\n",
PTR_ERR(sai->bus_clk));
/* -EPROBE_DEFER */
return PTR_ERR(sai->bus_clk);
@@ -1051,9 +1052,9 @@ static int fsl_sai_probe(struct platform_device *pdev)
 
for (i = 1; i < FSL_SAI_MCLK_MAX; i++) {
sprintf(tmp, "mclk%d", i);
-   sai->mclk_clk[i] = devm_clk_get(>dev, tmp);
+   sai->mclk_clk[i] = devm_clk_get(dev, tmp);
if (IS_ERR(sai->mclk_clk[i])) {
-   dev_err(>dev, "failed to get mclk%d clock: %ld\n",
+   dev_err(dev, "failed to get mclk%d clock: %ld\n",
i + 1, PTR_ERR(sai->mclk_clk[i]));
sai->mclk_clk[i] = NULL;
}
@@ -1068,10 +1069,10 @@ static int fsl_sai_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
 
-   ret = devm_request_irq(>dev, irq, fsl_sai_isr, IRQF_SHARED,
+   ret = devm_request_irq(dev, irq, fsl_sai_isr, IRQF_SHARED,
   np->name, sai);
if (ret) {
-   dev_err(>dev, "failed to claim irq %u\n", irq);
+   dev_err(dev, "failed to claim irq %u\n", irq);
return ret;
}
 
@@ -1088,7 +1089,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
if (of_find_property(np, "fsl,sai-synchronous-rx", NULL) &&
of_find_property(np, "fsl,sai-asynchronous", NULL)) {
/* error out if both synchronous and asynchronous are present */
-   dev_err(>dev, "invalid binding for synchronous mode\n");
+   dev_err(dev, "invalid binding for synchronous mode\n");
return -EINVAL;
}
 
@@ -1109,7 +1110,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
of_device_is_compatible(np, "fsl,imx6ul-sai")) {
gpr = 
syscon_regmap_lookup_by_compatible("fsl,imx6ul-iomuxc-gpr");
if (IS_ERR(gpr)) {
-   dev_err(>dev, "cannot find iomuxc registers\n");
+   dev_err(dev, "cannot find iomuxc registers\n");
return PTR_ERR(gpr);
}
 
@@ -1127,23 +1128,23 @@ static int fsl_sai_probe(struct platform_device *pdev)
sai->dma_params_tx.maxburst = FSL_SAI_MAXBURST_TX;
 
platform_set_drvdata(pdev, sai);
-   pm_runtime_enable(>dev);
-   if (!pm_runtime_enabled(>dev)) {
-   ret = fsl_sai_runtime_resume(>dev);
+   pm_runtime_enable(dev);
+   if (!pm_runtime_enabled(dev)) {
+   ret = fsl_sai_runtime_resume(dev);
if (ret)
goto err_pm_disable;
}
 
-   

[PATCH 3/3] ASoC: fsl_sai: add error message in case of missing imx-pcm-dma support

2022-06-01 Thread Marco Felsch
If the imx-pcm-dma is required we need to have the module enabled. For
all NXP/FSL sound cards using the ASoC architecture this is the case but
in case of using the simple-audio-card sound card this isn't the case.

In such case the driver probe fails silently and the card isn't
available. It took a while to find the missing Kconfig. Make this easier
for others by printing a error if this the module isn't available but
required by the HW.

Signed-off-by: Marco Felsch 
---
 sound/soc/fsl/fsl_sai.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 3e54f1f71c1e..2371da814b09 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1152,8 +1152,11 @@ static int fsl_sai_probe(struct platform_device *pdev)
 */
if (sai->soc_data->use_imx_pcm) {
ret = imx_pcm_dma_init(pdev);
-   if (ret)
+   if (ret) {
+   if (!IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_DMA))
+   dev_err(dev, "Error: You must enable the 
imx-pcm-dma support!\n");
goto err_pm_get_sync;
+   }
} else {
ret = devm_snd_dmaengine_pcm_register(dev, NULL, 0);
if (ret)
-- 
2.30.2



Re: [PATCH 2/6] powerpc: Provide syscall wrapper

2022-06-01 Thread kernel test robot
Hi Rohan,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on v5.18]
[also build test WARNING on next-20220601]
[cannot apply to powerpc/next scottwood/next]
[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]

url:
https://github.com/intel-lab-lkp/linux/commits/Rohan-McLure/powerpc-Add-ZERO_GPRS-macros-for-register-clears/20220601-135400
base:4b0986a3613c92f4ec1bdc7f60ec66fea135991f
config: powerpc-allyesconfig 
(https://download.01.org/0day-ci/archive/20220601/202206011624.srj0dsyf-...@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/c3efdfac99806b0d7ef4ee781283404448addc69
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Rohan-McLure/powerpc-Add-ZERO_GPRS-macros-for-register-clears/20220601-135400
git checkout c3efdfac99806b0d7ef4ee781283404448addc69
# 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 warnings (new ones prefixed by >>):

   In file included from include/linux/syscalls.h:98,
from arch/powerpc/kernel/syscalls.c:19:
>> arch/powerpc/include/asm/syscall_wrapper.h:78:14: warning: no previous 
>> prototype for 'sys_switch_endian' [-Wmissing-prototypes]
  78 | long sys_##sname(void)   
   \
 |  ^~~~
   arch/powerpc/kernel/syscalls.c:114:1: note: in expansion of macro 
'SYSCALL_DEFINE0'
 114 | SYSCALL_DEFINE0(switch_endian)
 | ^~~


vim +/sys_switch_endian +78 arch/powerpc/include/asm/syscall_wrapper.h

49  
50  #define __SYSCALL_DEFINEx(x, name, ...) 
\
51  asmlinkage long __powerpc_sys##name(const struct pt_regs 
*regs);\
52  ALLOW_ERROR_INJECTION(__powerpc_sys##name, ERRNO);  
\
53  long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)); 
\
54  static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__)); 
\
55  static inline long 
__do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));  \
56  asmlinkage long __powerpc_sys##name(const struct pt_regs *regs) 
\
57  {   
\
58  return 
__se_sys##name(SC_POWERPC_REGS_TO_ARGS(x,__VA_ARGS__));  \
59  }   
\
60  long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))  
\
61  {   
\
62  return __do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));  
\
63  }   
\
64  static long __se_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))  
\
65  {   
\
66  long ret = 
__do_sys##name(__MAP(x,__SC_CAST,__VA_ARGS__));  \
67  __MAP(x,__SC_TEST,__VA_ARGS__); 
\
68  __PROTECT(x, ret,__MAP(x,__SC_ARGS,__VA_ARGS__));   
\
69  return ret; 
\
70  }   
\
71  static inline long 
__do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
72  
73  #define SYSCALL_DEFINE0(sname)  
\
74  SYSCALL_METADATA(_##sname, 0);  
\
75  long sys_##name(void);  
\
76  asmlinkage long __powerpc_sys_##sname(const struct pt_regs 
*__unused);  \
77  ALLOW_ERROR_INJECTION(__powerpc_sys_##sname, ERRNO);
\
  > 78  long sys_##sname(void)  
\
79  {   
\
80  return __powerpc_sys_##sname(NULL); 

Re: [PATCH 6/6] powerpc/64s: Clear gprs on interrupt routine entry

2022-06-01 Thread Christophe Leroy


Le 01/06/2022 à 07:48, Rohan McLure a écrit :
> Zero GPRS r0, r2-r11, r14-r31, on entry into the kernel for all
> other interrupt sources to limit influence of user-space values
> in potential speculation gadgets. The remaining gprs are overwritten by
> entry macros to interrupt handlers, irrespective of whether or not a
> given handler consumes these register values.
> 
> Prior to this commit, r14-r31 are restored on a per-interrupt basis at
> exit, but now they are always restored. Remove explicit REST_NVGPRS
> invocations on interrupt entry and simplify exit logic.
> 
> Signed-off-by: Rohan McLure 
> ---
>   arch/powerpc/kernel/exceptions-64s.S | 19 +++
>   arch/powerpc/kernel/interrupt_64.S   |  9 ++---
>   2 files changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/exceptions-64s.S 
> b/arch/powerpc/kernel/exceptions-64s.S
> index 102896fc6a86..8e2c1c924a4d 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -502,6 +502,7 @@ DEFINE_FIXED_SYMBOL(\name\()_common_real, text)
>   std r10,0(r1)   /* make stack chain pointer */
>   std r0,GPR0(r1) /* save r0 in stackframe*/
>   std r10,GPR1(r1)/* save r1 in stackframe*/
> + ZERO_GPR(0)
>   
>   /* Mark our [H]SRRs valid for return */
>   li  r10,1
> @@ -538,14 +539,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>   ld  r10,IAREA+EX_R10(r13)
>   std r9,GPR9(r1)
>   std r10,GPR10(r1)
> + ZERO_GPRS(9, 10)
>   ld  r9,IAREA+EX_R11(r13)/* move r11 - r13 to stackframe */
>   ld  r10,IAREA+EX_R12(r13)
>   ld  r11,IAREA+EX_R13(r13)
>   std r9,GPR11(r1)
>   std r10,GPR12(r1)
>   std r11,GPR13(r1)
> + ZERO_GPR(11) /* keep r12 ([H]SRR1/MSR), r13 (PACA) for interrupt 
> routine */
>   
>   SAVE_NVGPRS(r1)
> + ZERO_NVGPRS()
>   
>   .if IDAR
>   .if IISIDE
> @@ -577,8 +581,9 @@ BEGIN_FTR_SECTION
>   END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
>   ld  r10,IAREA+EX_CTR(r13)
>   std r10,_CTR(r1)
> - std r2,GPR2(r1) /* save r2 in stackframe*/
> + SAVE_GPR(2, r1) /* save r2 in stackframe*/
>   SAVE_GPRS(3, 8, r1) /* save r3 - r8 in stackframe   */
> + ZERO_GPRS(2, 8)

What's the point in clearing r2 whereas it will be overwritten just below ?

>   mflrr9  /* Get LR, later save to stack  */
>   ld  r2,PACATOC(r13) /* get kernel TOC into r2   */
>   std r9,_LINK(r1)
> @@ -696,6 +701,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
>   mtlrr9
>   ld  r9,_CCR(r1)
>   mtcrr9
> + REST_NVGPRS(r1)
>   REST_GPRS(2, 13, r1)
>   REST_GPR(0, r1)
>   /* restore original r1. */
> @@ -1368,11 +1374,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
>   b   interrupt_return_srr
>   
>   1:  bl  do_break
> - /*
> -  * do_break() may have changed the NV GPRS while handling a breakpoint.
> -  * If so, we need to restore them with their updated values.
> -  */
> - REST_NVGPRS(r1)
>   b   interrupt_return_srr
>   
>   
> @@ -1598,7 +1599,6 @@ EXC_COMMON_BEGIN(alignment_common)
>   GEN_COMMON alignment
>   addir3,r1,STACK_FRAME_OVERHEAD
>   bl  alignment_exception
> - REST_NVGPRS(r1) /* instruction emulation may change GPRs */
>   b   interrupt_return_srr
>   
>   
> @@ -1708,7 +1708,6 @@ EXC_COMMON_BEGIN(program_check_common)
>   .Ldo_program_check:
>   addir3,r1,STACK_FRAME_OVERHEAD
>   bl  program_check_exception
> - REST_NVGPRS(r1) /* instruction emulation may change GPRs */
>   b   interrupt_return_srr
>   
>   
> @@ -2139,7 +2138,6 @@ EXC_COMMON_BEGIN(emulation_assist_common)
>   GEN_COMMON emulation_assist
>   addir3,r1,STACK_FRAME_OVERHEAD
>   bl  emulation_assist_interrupt
> - REST_NVGPRS(r1) /* instruction emulation may change GPRs */
>   b   interrupt_return_hsrr
>   
>   
> @@ -2457,7 +2455,6 @@ EXC_COMMON_BEGIN(facility_unavailable_common)
>   GEN_COMMON facility_unavailable
>   addir3,r1,STACK_FRAME_OVERHEAD
>   bl  facility_unavailable_exception
> - REST_NVGPRS(r1) /* instruction emulation may change GPRs */
>   b   interrupt_return_srr
>   
>   
> @@ -2485,7 +2482,6 @@ EXC_COMMON_BEGIN(h_facility_unavailable_common)
>   GEN_COMMON h_facility_unavailable
>   addir3,r1,STACK_FRAME_OVERHEAD
>   bl  facility_unavailable_exception
> - REST_NVGPRS(r1) /* XXX Shouldn't be necessary in practice */
>   b   interrupt_return_hsrr
>   
>   
> @@ -2711,7 +2707,6 @@ EXC_COMMON_BEGIN(altivec_assist_common)
>   addir3,r1,STACK_FRAME_OVERHEAD
>   #ifdef CONFIG_ALTIVEC
>   bl  altivec_assist_exception
> - REST_NVGPRS(r1) /* 

Re: [PATCH 3/6] powerpc: Make syscalls save and restore gprs

2022-06-01 Thread Christophe Leroy


Le 01/06/2022 à 07:48, Rohan McLure a écrit :
> [Vous ne recevez pas souvent de courriers de la part de 
> rmcl...@linux.ibm.com. Découvrez pourquoi cela peut être important à 
> l'adresse https://aka.ms/LearnAboutSenderIdentification.]
> 
> Clears user state in gprs to reduce the influence of user registers on
> speculation within kernel syscall handlers.
> 
> Remove conditional branches on result of `syscall_exit_prepare` to
> restore non-volatile gprs, as these registers are always cleared and
> hence always must be restored.

Did you measure the implied performance loss ? That must be heavy.

In patch 2 it is said that clearing registers is optional. I can't see 
it as an option here. Some PPC32 are not impacted by speculative 
problems, could we activate that big hammer only when required ?

> 
> Signed-off-by: Rohan McLure 
> ---
>   arch/powerpc/kernel/interrupt_64.S | 12 +---
>   1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/interrupt_64.S 
> b/arch/powerpc/kernel/interrupt_64.S
> index b11c2bd84827..e601ed999798 100644
> --- a/arch/powerpc/kernel/interrupt_64.S
> +++ b/arch/powerpc/kernel/interrupt_64.S
> @@ -108,6 +108,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>   * but this is the best we can do.
>   */
> 
> +   ZERO_GPRS(5, 12)
> +   ZERO_NVGPRS()
> +
>  /* Calling convention has r3 = orig r0, r4 = regs */
>  mr  r3,r0
>  bl  system_call_exception
> @@ -138,6 +141,7 @@ BEGIN_FTR_SECTION
>  HMT_MEDIUM_LOW
>   END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> 
> +   REST_NVGPRS(r1)
>  cmpdi   r3,0
>  bne .Lsyscall_vectored_\name\()_restore_regs
> 
> @@ -180,7 +184,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>  ld  r4,_LINK(r1)
>  ld  r5,_XER(r1)
> 
> -   REST_NVGPRS(r1)
>  ld  r0,GPR0(r1)
>  mtcrr2
>  mtctr   r3
> @@ -308,6 +311,9 @@ END_BTB_FLUSH_SECTION
>  wrteei  1
>   #endif
> 
> +   ZERO_GPRS(5, 12)
> +   ZERO_NVGPRS()
> +
>  /* Calling convention has r3 = orig r0, r4 = regs */
>  mr  r3,r0
>  bl  system_call_exception
> @@ -350,6 +356,7 @@ BEGIN_FTR_SECTION
>  stdcx.  r0,0,r1 /* to clear the reservation */
>   END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
> 
> +   REST_NVGPRS(r1)
>  cmpdi   r3,0
>  bne .Lsyscall_restore_regs
>  /* Zero volatile regs that may contain sensitive kernel data */
> @@ -377,7 +384,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>   .Lsyscall_restore_regs:
>  ld  r3,_CTR(r1)
>  ld  r4,_XER(r1)
> -   REST_NVGPRS(r1)
>  mtctr   r3
>  mtspr   SPRN_XER,r4
>  REST_GPR(0, r1)
> @@ -445,7 +451,7 @@ _ASM_NOKPROBE_SYMBOL(interrupt_return_\srr\()_user)
>  bl  interrupt_exit_user_prepare
>  cmpdi   r3,0
>  bne-.Lrestore_nvgprs_\srr
> -.Lrestore_nvgprs_\srr\()_cont:
> +   .Lrestore_nvgprs_\srr\()_cont:
>  std r1,PACA_EXIT_SAVE_R1(r13) /* save r1 for restart */
>   #ifdef CONFIG_PPC_BOOK3S
>   .Linterrupt_return_\srr\()_user_rst_start:
> --
> 2.34.1
> 

Re: [PATCH 2/6] powerpc: Provide syscall wrapper

2022-06-01 Thread Christophe Leroy


Le 01/06/2022 à 07:48, Rohan McLure a écrit :
> [Vous ne recevez pas souvent de courriers de la part de 
> rmcl...@linux.ibm.com. Découvrez pourquoi cela peut être important à 
> l'adresse https://aka.ms/LearnAboutSenderIdentification.]
> 
> Syscall wrapper implemented as per s390, x86, arm64, providing the
> option for gprs to be cleared on entry to the kernel, reducing caller
> influence influence on speculation within syscall routine. The wrapper
> is a macro that emits syscall handler implementations with parameters
> passed by stack pointer.

Passing parameters by stack is going to be sub-optimal. Did you make any 
measurement of the implied performance degradation ? We usually use the 
null_syscall selftest for that everytime we touch syscall entries/exits.

Why going via stack ? The main advantage of a RISC processor like 
powerpc is that, unlike x86, there are enough registers to avoid going 
through memory. RISC processors are optimised with three operands 
operations and many registers, and usually have slow memory in return.

> 
> For platforms supporting this syscall wrapper, emit symbols with usual
> in-register parameters (`sys...`) to support calls to syscall handlers
> from within the kernel.
> 
> Syscalls are wrapped on all platforms except Cell processor. SPUs require
> access syscall prototypes which are omitted with ARCH_HAS_SYSCALL_WRAPPER
> enabled.
This commit message isn't very clear, please describe in more details 
what is done, how and why.

> 
> Co-developed-by: Andrew Donnellan 
> Signed-off-by: Andrew Donnellan 
> Signed-off-by: Rohan McLure 
> ---
>   arch/powerpc/Kconfig   |  1 +
>   arch/powerpc/include/asm/interrupt.h   |  3 +-
>   arch/powerpc/include/asm/syscall_wrapper.h | 92 ++
>   arch/powerpc/include/asm/syscalls.h| 83 +--
>   arch/powerpc/kernel/entry_32.S |  6 +-
>   arch/powerpc/kernel/interrupt.c| 35 
>   arch/powerpc/kernel/interrupt_64.S | 30 +++
>   arch/powerpc/kernel/sys_ppc32.c| 50 +++-
>   arch/powerpc/kernel/syscalls.c | 19 +++--
>   arch/powerpc/kernel/systbl.S   | 21 +
>   arch/powerpc/kernel/vdso.c |  2 +
>   11 files changed, 255 insertions(+), 87 deletions(-)
>   create mode 100644 arch/powerpc/include/asm/syscall_wrapper.h
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 174edabb74fa..e58287a70061 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -137,6 +137,7 @@ config PPC
>  select ARCH_HAS_STRICT_KERNEL_RWX   if (PPC_BOOK3S || PPC_8xx || 
> 40x) && !HIBERNATION
>  select ARCH_HAS_STRICT_KERNEL_RWX   if FSL_BOOKE && !HIBERNATION 
> && !RANDOMIZE_BASE
>  select ARCH_HAS_STRICT_MODULE_RWX   if ARCH_HAS_STRICT_KERNEL_RWX
> +   select ARCH_HAS_SYSCALL_WRAPPER if !SPU_BASE
>  select ARCH_HAS_TICK_BROADCAST  if 
> GENERIC_CLOCKEVENTS_BROADCAST
>  select ARCH_HAS_UACCESS_FLUSHCACHE
>  select ARCH_HAS_UBSAN_SANITIZE_ALL
> diff --git a/arch/powerpc/include/asm/interrupt.h 
> b/arch/powerpc/include/asm/interrupt.h
> index f964ef5c57d8..8e8949e4db7a 100644
> --- a/arch/powerpc/include/asm/interrupt.h
> +++ b/arch/powerpc/include/asm/interrupt.h
> @@ -636,8 +636,7 @@ static inline void interrupt_cond_local_irq_enable(struct 
> pt_regs *regs)
>  local_irq_enable();
>   }
> 
> -long system_call_exception(long r3, long r4, long r5, long r6, long r7, long 
> r8,
> -  unsigned long r0, struct pt_regs *regs);
> +long system_call_exception(unsigned long r0, struct pt_regs *regs);
>   notrace unsigned long syscall_exit_prepare(unsigned long r3, struct pt_regs 
> *regs, long scv);
>   notrace unsigned long interrupt_exit_user_prepare(struct pt_regs *regs);
>   notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs);
> diff --git a/arch/powerpc/include/asm/syscall_wrapper.h 
> b/arch/powerpc/include/asm/syscall_wrapper.h
> new file mode 100644
> index ..23da22b081e4
> --- /dev/null
> +++ b/arch/powerpc/include/asm/syscall_wrapper.h
> @@ -0,0 +1,92 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * syscall_wrapper.h - powerpc specific wrappers to syscall definitions
> + *
> + * Based on arch/{x86,arm64}/include/asm/syscall_wrapper.h
> + */
> +
> +#ifndef __ASM_SYSCALL_WRAPPER_H
> +#define __ASM_SYSCALL_WRAPPER_H
> +
> +struct pt_regs;
> +
> +#define SC_POWERPC_REGS_TO_ARGS(x, ...)\
> +   __MAP(x,__SC_ARGS   \
> + ,,regs->gpr[3],,regs->gpr[4],,regs->gpr[5]\
> + ,,regs->gpr[6],,regs->gpr[7],,regs->gpr[8])
> +
> +#ifdef CONFIG_COMPAT
> +
> +#define COMPAT_SYSCALL_DEFINEx(x, name, ...) 
>   \
> +   asmlinkage long __powerpc_compat_sys##name(const struct 

Re: [PATCH 1/6] powerpc: Add ZERO_GPRS macros for register clears

2022-06-01 Thread Christophe Leroy


Le 01/06/2022 à 07:48, Rohan McLure a écrit :
> [You don't often get email from rmcl...@linux.ibm.com. Learn why this is 
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Macros for restoring saving registers to and from the stack exist.
> Provide a macro for simply zeroing a range of gprs, or an individual
> gpr.
> 
> Signed-off-by: Rohan McLure 
> ---
>   arch/powerpc/include/asm/ppc_asm.h | 17 +
>   1 file changed, 17 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/ppc_asm.h 
> b/arch/powerpc/include/asm/ppc_asm.h
> index 4dea2d963738..3fb37a9767f7 100644
> --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -33,6 +33,19 @@
>  .endr
>   .endm
> 
> +/*
> + * Simplification of OP_REGS, for an arbitrary right hand operand.
> + *
> + *   op  reg, rhs

You call it "BINOP" but it is rare to have a binary operation with only 
two operands. Another name could be more appropriate ?
Or keep it as BINOP if you see another future use ? In that case have 
the 3 operands, then 'li r, 0' is same as 'addi r, 0, 0'

> + */
> +.macro BINOP_REGS op, rhs, start, end
> +   .Lreg=\start
> +   .rept (\end - \start + 1)
> +   \op .Lreg, \rhs
> +   .Lreg=.Lreg+1
> +   .endr
> +.endm
> +
>   /*
>* Macros for storing registers into and loading registers from
>* exception frames.
> @@ -49,6 +62,10 @@
>   #define REST_NVGPRS(base)  REST_GPRS(13, 31, base)
>   #endif
> 
> +#define ZERO_GPRS(start, end)  BINOP_REGS li, 0, start, end
> +#define ZERO_NVGPRS()  ZERO_GPRS(14, 31)
> +#define ZERO_GPR(n)ZERO_GPRS(n, n)

Maybe it would be more explicit to use ZEROIZE_

> +
>   #define SAVE_GPR(n, base)  SAVE_GPRS(n, n, base)
>   #define REST_GPR(n, base)  REST_GPRS(n, n, base)
> 
> --
> 2.34.1
> 

[PATCH] PCI/ERR: handle disconnected devices in report_error_detected

2022-06-01 Thread Christoph Hellwig
When a device is already unplugged by pciehp by the time that the AER
handler is invoked, the PCIe device will lready be in the
pci_channel_io_perm_failure state.  In that case we should simply
return PCI_ERS_RESULT_DISCONNECT instead of trying to do a state
transition that will fail.

Also untangle the state transition failure from the lack of methods to
improve the debugging output in case it will happen ever again.

Signed-off-by: Christoph Hellwig 
---
 drivers/pci/pcie/err.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 0c5a143025af4..59c90d04a609a 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -55,10 +55,14 @@ static int report_error_detected(struct pci_dev *dev,
 
device_lock(>dev);
pdrv = dev->driver;
-   if (!pci_dev_set_io_state(dev, state) ||
-   !pdrv ||
-   !pdrv->err_handler ||
-   !pdrv->err_handler->error_detected) {
+   if (pci_dev_is_disconnected(dev)) {
+   vote = PCI_ERS_RESULT_DISCONNECT;
+   } else if (!pci_dev_set_io_state(dev, state)) {
+   pci_info(dev, "can't recover (state transition %u -> %u 
invalid)\n",
+   dev->error_state, state);
+   vote = PCI_ERS_RESULT_NONE;
+   } else if (!pdrv || !pdrv->err_handler ||
+  !pdrv->err_handler->error_detected) {
/*
 * If any device in the subtree does not have an error_detected
 * callback, PCI_ERS_RESULT_NO_AER_DRIVER prevents subsequent
-- 
2.30.2