LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2] ASoC: fsl-asoc-card: Get "extal" clock rate by clk_get_rate
From: Nicolin Chen @ 2020-08-10  8:37 UTC (permalink / raw)
  To: Shengjiu Wang
  Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
	perex, broonie, festevam, linux-kernel
In-Reply-To: <1597047103-6863-1-git-send-email-shengjiu.wang@nxp.com>

On Mon, Aug 10, 2020 at 04:11:43PM +0800, Shengjiu Wang wrote:
> On some platform(.e.g. i.MX8QM MEK), the "extal" clock is different
> with the mclk of codec, then the clock rate is also different.
> So it is better to get clock rate of "extal" rate by clk_get_rate,
> don't reuse the clock rate of mclk.
> 
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> changes in v2
> - add defer probe handler
> 
>  sound/soc/fsl/fsl-asoc-card.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> index 52adedc03245..32f8f756e6bb 100644
> --- a/sound/soc/fsl/fsl-asoc-card.c
> +++ b/sound/soc/fsl/fsl-asoc-card.c
> @@ -696,6 +696,17 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
>  			goto asrc_fail;
>  		}
>  	} else if (of_node_name_eq(cpu_np, "esai")) {
> +		struct clk *esai_clk = clk_get(&cpu_pdev->dev, "extal");
> +
> +		if (!IS_ERR(esai_clk)) {
> +			priv->cpu_priv.sysclk_freq[TX] = clk_get_rate(esai_clk);
> +			priv->cpu_priv.sysclk_freq[RX] = clk_get_rate(esai_clk);

Will it break existing imx-audio-cs42888 on older i.MX platforms?
'cause it overwrites cpu_priv.sysclk_freq[] that are set in "card
configurations" section.

^ permalink raw reply

* Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"
From: Christian Zigotzky @ 2020-08-10  8:45 UTC (permalink / raw)
  To: Aneesh Kumar K.V
  Cc: Olof Johansson, Darren Stevens, linuxppc-dev, mad skateman,
	R.T.Dickinson
In-Reply-To: <bc1975fb-23df-09c2-540a-c13b39ad56c5@xenosoft.de>

Hello Aneesh,

I tested the new kernel today and unfortunately it doesn't run very well.

I have only one core (1 physical processor; 1 core; 2 threads) instead 
of two cores (1 physical processor; 2 cores; 2 threads) so the system is 
slower.

Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt

Could you please check the updates?

Thanks,
Christian


On 10 August 2020 at 09:56 am, Christian Zigotzky wrote:
> Hello Aneesh,
>
> The Nemo board boots with your patch but unfortunately I don't see any 
> boot messages anymore.
>
> Please find attached the kernel config.
>
> Thanks,
> Christian
>
>
> On 09 August 2020 at 5:49 pm, Christian Zigotzky wrote:
>> Hello Aneesh,
>>
>> Many thanks for your fast response and thanks a lot for your patch!
>> I will patch and compile a new git kernel tomorrow. I am looking 
>> forward to the result.
>>
>> Have a nice day!
>>
>> Cheers,
>> Christian
>>
>>> On 9. Aug 2020, at 17:11, Aneesh Kumar K.V 
>>> <aneesh.kumar@linux.ibm.com> wrote:
>>>
>>> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>>>
>>>>> On 8/9/20 8:04 PM, Aneesh Kumar K.V wrote:
>>>>> On 8/9/20 7:42 PM, Christian Zigotzky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the
>>>>>> latest Git kernel anymore after the commit "powerpc/book3s64/pkeys:
>>>>>> Simplify pkey disable branch" [2].
>>>>>>
>>>>>> I bisected today [3].
>>>>>>
>>>>>> Result: powerpc/book3s64/pkeys: Simplify pkey disable branch
>>>>>> (a4678d4b477c3d2901f101986ca01406f3b7eaea) [2] is the first bad 
>>>>>> commit.
>>>>>>
>>>>>> Unfortunately I wasn't able to revert the first bad commit. The 
>>>>>> first
>>>>>> bad commit depends on many other commits, which unfortunately I 
>>>>>> don't
>>>>>> know. I tried to remove the modifications of the files from the 
>>>>>> first
>>>>>> bad commit but without any success. There are just too many 
>>>>>> dependencies.
>>>>>>
>>>>>> Additionally I reverted the commit "selftests/powerpc: Fix pkey
>>>>>> syscall redefinitions" [4] and compiled a new kernel but without any
>>>>>> success.
>>>>>>
>>>>>> Could you please check the first bad commit?
>>>>>>
>>>>>> Thanks,
>>>>>> Christian
>>>>>>
>>>>>
>>>>> Can you share a successful boot log of the system so that i can 
>>>>> double
>>>>> check the cpu_feature and mmu_feature reported ? I am looking for
>>>>> details similar to below.
>>>>>
>>>>> [    0.000000] cpu_features      = 0x0001c07f8f5f91a7
>>>>> [    0.000000]   possible        = 0x0001fbffcf5fb1a7
>>>>> [    0.000000]   always          = 0x00000003800081a1
>>>>> [    0.000000] cpu_user_features = 0xdc0065c2 0xefe00000
>>>>> [    0.000000] mmu_features      = 0x7c006001
>>>>> [    0.000000] firmware_features = 0x0000001fc45bfc57
>>>>> [    0.000000] vmalloc start     = 0xc008000000000000
>>>>> [    0.000000] IO start          = 0xc00a000000000000
>>>>> [    0.000000] vmemmap start     = 0xc00c000000000000
>>>>>
>>>>>
>>>>> IIUC this is P5+? (ISA 2.04). On that pkey should be marked 
>>>>> disabled via
>>>>>
>>>>> static int scan_pkey_feature(void)
>>>>> {
>>>>>      int ret;
>>>>>      int pkeys_total = 0;
>>>>>
>>>>>      ....
>>>>>
>>>>>      /*
>>>>>       * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
>>>>>       */
>>>>>      if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
>>>>>          return 0;
>>>>>
>>>>>
>>>>> }
>>>>>
>>>>> Can you boot with CONFIG_PPC_MEM_KEYS=n ?
>>>>
>>>> Can you try this change on top of master?
>>>>
>>>>
>>>> modified   arch/powerpc/mm/book3s64/pkeys.c
>>>> @@ -215,10 +215,6 @@ void __init pkey_early_init_devtree(void)
>>>>
>>>>       pr_info("Enabling pkeys with max key count %d\n", num_pkey);
>>>>   out:
>>>> -    /*
>>>> -     * Setup uamor on boot cpu
>>>> -     */
>>>> -    mtspr(SPRN_UAMOR, default_uamor);
>>>>
>>>>       return;
>>>>   }
>>>>
>>> Full patch with better description.
>>>
>>> commit 919a177bcdaf1eaeaeecc0d0f50a688629d7b5df
>>> Author: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>> Date:   Sun Aug 9 20:37:38 2020 +0530
>>>
>>>     powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne 
>>> X1000)
>>>
>>>     On p6 and before we should avoid updating UAMOR SPRN. This resulted
>>>     in boot failure on Nemo board.
>>>
>>>     Fixes: 269e829f48a0 ("powerpc/book3s64/pkey: Disable pkey on 
>>> POWER6 and before")
>>>     Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>>>     Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>>
>>> diff --git a/arch/powerpc/mm/book3s64/pkeys.c 
>>> b/arch/powerpc/mm/book3s64/pkeys.c
>>> index 69a6b87f2bb4..b1d091a97611 100644
>>> --- a/arch/powerpc/mm/book3s64/pkeys.c
>>> +++ b/arch/powerpc/mm/book3s64/pkeys.c
>>> @@ -73,12 +73,6 @@ static int scan_pkey_feature(void)
>>>     if (early_radix_enabled())
>>>         return 0;
>>>
>>> -    /*
>>> -     * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
>>> -     */
>>> -    if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
>>> -        return 0;
>>> -
>>>     ret = of_scan_flat_dt(dt_scan_storage_keys, &pkeys_total);
>>>     if (ret == 0) {
>>>         /*
>>> @@ -124,6 +118,12 @@ void __init pkey_early_init_devtree(void)
>>>              __builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)
>>>                 != (sizeof(u64) * BITS_PER_BYTE));
>>>
>>> +    /*
>>> +     * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
>>> +     */
>>> +    if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
>>> +        return;
>>> +
>>>     /* scan the device tree for pkey feature */
>>>     pkeys_total = scan_pkey_feature();
>>>     if (!pkeys_total)
>


^ permalink raw reply

* [PATCH] recordmcount: Fix build failure on non arm64
From: Christophe Leroy @ 2020-08-10  8:48 UTC (permalink / raw)
  To: Gregory Herrero, Steven Rostedt, Catalin Marinas
  Cc: linuxppc-dev, linux-kernel, linux-arm-kernel

Commit ea0eada45632 leads to the following build failure on powerpc:

  HOSTCC  scripts/recordmcount
scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
scripts/recordmcount.c:440: error: for each function it appears in.)
make[2]: *** [scripts/recordmcount] Error 1

Make sure R_AARCH64_CALL26 is always defined.

Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.")
Cc: Gregory Herrero <gregory.herrero@oracle.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
 scripts/recordmcount.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index e59022b3f125..b9c2ee7ab43f 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -42,6 +42,8 @@
 #define R_ARM_THM_CALL		10
 #define R_ARM_CALL		28
 
+#define R_AARCH64_CALL26	283
+
 static int fd_map;	/* File descriptor for file being modified. */
 static int mmap_failed; /* Boolean flag. */
 static char gpfx;	/* prefix for global symbol name (sometimes '_') */
-- 
2.25.0


^ permalink raw reply related

* Re: [PATCH v2] ASoC: fsl-asoc-card: Get "extal" clock rate by clk_get_rate
From: Shengjiu Wang @ 2020-08-10  8:50 UTC (permalink / raw)
  To: Nicolin Chen
  Cc: Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
	Takashi Iwai, Liam Girdwood, Mark Brown, linuxppc-dev,
	linux-kernel
In-Reply-To: <20200810083728.GA7560@Asurada-Nvidia>

On Mon, Aug 10, 2020 at 4:39 PM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Mon, Aug 10, 2020 at 04:11:43PM +0800, Shengjiu Wang wrote:
> > On some platform(.e.g. i.MX8QM MEK), the "extal" clock is different
> > with the mclk of codec, then the clock rate is also different.
> > So it is better to get clock rate of "extal" rate by clk_get_rate,
> > don't reuse the clock rate of mclk.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > changes in v2
> > - add defer probe handler
> >
> >  sound/soc/fsl/fsl-asoc-card.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> > index 52adedc03245..32f8f756e6bb 100644
> > --- a/sound/soc/fsl/fsl-asoc-card.c
> > +++ b/sound/soc/fsl/fsl-asoc-card.c
> > @@ -696,6 +696,17 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> >                       goto asrc_fail;
> >               }
> >       } else if (of_node_name_eq(cpu_np, "esai")) {
> > +             struct clk *esai_clk = clk_get(&cpu_pdev->dev, "extal");
> > +
> > +             if (!IS_ERR(esai_clk)) {
> > +                     priv->cpu_priv.sysclk_freq[TX] = clk_get_rate(esai_clk);
> > +                     priv->cpu_priv.sysclk_freq[RX] = clk_get_rate(esai_clk);
>
> Will it break existing imx-audio-cs42888 on older i.MX platforms?
> 'cause it overwrites cpu_priv.sysclk_freq[] that are set in "card
> configurations" section.

Tested,  no break for imx6.

best regards
wang shengjiu

^ permalink raw reply

* [PATCHv5 1/2] powerpc/pseries: group lmb operation and memblock's
From: Pingfan Liu @ 2020-08-10  8:52 UTC (permalink / raw)
  To: linuxppc-dev
  Cc: Nathan Lynch, kexec, Pingfan Liu, Nathan Fontenot, Laurent Dufour,
	Hari Bathini

This patch prepares for the incoming patch which swaps the order of
KOBJ_ADD/REMOVE uevent and dt's updating.

The dt updating should come after lmb operations, and before
__remove_memory()/__add_memory().  Accordingly, grouping all lmb operations
before the memblock's.

Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: kexec@lists.infradead.org
---
v4 -> v5: fix the miss of clearing DRCONF_MEM_ASSIGNED in a failure path
 arch/powerpc/platforms/pseries/hotplug-memory.c | 28 +++++++++++++++++--------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 5d545b7..46cbcd1 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -355,7 +355,8 @@ static int dlpar_add_lmb(struct drmem_lmb *);
 static int dlpar_remove_lmb(struct drmem_lmb *lmb)
 {
 	unsigned long block_sz;
-	int rc;
+	phys_addr_t base_addr;
+	int rc, nid;
 
 	if (!lmb_is_removable(lmb))
 		return -EINVAL;
@@ -364,17 +365,19 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)
 	if (rc)
 		return rc;
 
+	base_addr = lmb->base_addr;
+	nid = lmb->nid;
 	block_sz = pseries_memory_block_size();
 
-	__remove_memory(lmb->nid, lmb->base_addr, block_sz);
-
-	/* Update memory regions for memory remove */
-	memblock_remove(lmb->base_addr, block_sz);
-
 	invalidate_lmb_associativity_index(lmb);
 	lmb_clear_nid(lmb);
 	lmb->flags &= ~DRCONF_MEM_ASSIGNED;
 
+	__remove_memory(nid, base_addr, block_sz);
+
+	/* Update memory regions for memory remove */
+	memblock_remove(base_addr, block_sz);
+
 	return 0;
 }
 
@@ -603,22 +606,29 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 	}
 
 	lmb_set_nid(lmb);
+	lmb->flags |= DRCONF_MEM_ASSIGNED;
+
 	block_sz = memory_block_size_bytes();
 
 	/* Add the memory */
 	rc = __add_memory(lmb->nid, lmb->base_addr, block_sz);
 	if (rc) {
 		invalidate_lmb_associativity_index(lmb);
+		lmb_clear_nid(lmb);
+		lmb->flags &= ~DRCONF_MEM_ASSIGNED;
 		return rc;
 	}
 
 	rc = dlpar_online_lmb(lmb);
 	if (rc) {
-		__remove_memory(lmb->nid, lmb->base_addr, block_sz);
+		int nid = lmb->nid;
+		phys_addr_t base_addr = lmb->base_addr;
+
 		invalidate_lmb_associativity_index(lmb);
 		lmb_clear_nid(lmb);
-	} else {
-		lmb->flags |= DRCONF_MEM_ASSIGNED;
+		lmb->flags &= ~DRCONF_MEM_ASSIGNED;
+
+		__remove_memory(nid, base_addr, block_sz);
 	}
 
 	return rc;
-- 
2.7.5


^ permalink raw reply related

* [PATCHv5 2/2] powerpc/pseries: update device tree before ejecting hotplug uevents
From: Pingfan Liu @ 2020-08-10  8:52 UTC (permalink / raw)
  To: linuxppc-dev
  Cc: Nathan Lynch, kexec, Pingfan Liu, Nathan Fontenot, Laurent Dufour,
	Hari Bathini
In-Reply-To: <1597049570-19536-1-git-send-email-kernelfans@gmail.com>

A bug is observed on pseries by taking the following steps on rhel:
-1. drmgr -c mem -r -q 5
-2. echo c > /proc/sysrq-trigger

And then, the failure looks like:
kdump: saving to /sysroot//var/crash/127.0.0.1-2020-01-16-02:06:14/
kdump: saving vmcore-dmesg.txt
kdump: saving vmcore-dmesg.txt complete
kdump: saving vmcore
 Checking for memory holes                         : [  0.0 %] /                   Checking for memory holes                         : [100.0 %] |                   Excluding unnecessary pages                       : [100.0 %] \                   Copying data                                      : [  0.3 %] -          eta: 38s[   44.337636] hash-mmu: mm: Hashing failure ! EA=0x7fffba400000 access=0x8000000000000004 current=makedumpfile
[   44.337663] hash-mmu:     trap=0x300 vsid=0x13a109c ssize=1 base psize=2 psize 2 pte=0xc000000050000504
[   44.337677] hash-mmu: mm: Hashing failure ! EA=0x7fffba400000 access=0x8000000000000004 current=makedumpfile
[   44.337692] hash-mmu:     trap=0x300 vsid=0x13a109c ssize=1 base psize=2 psize 2 pte=0xc000000050000504
[   44.337708] makedumpfile[469]: unhandled signal 7 at 00007fffba400000 nip 00007fffbbc4d7fc lr 000000011356ca3c code 2
[   44.338548] Core dump to |/bin/false pipe failed
/lib/kdump-lib-initramfs.sh: line 98:   469 Bus error               $CORE_COLLECTOR /proc/vmcore $_mp/$KDUMP_PATH/$HOST_IP-$DATEDIR/vmcore-incomplete
kdump: saving vmcore failed

* Root cause *
  After analyzing, it turns out that in the current implementation,
when hot-removing lmb, the KOBJ_REMOVE event ejects before the dt updating as
the code __remove_memory() comes before drmem_update_dt().
So in kdump kernel, when read_from_oldmem() resorts to
pSeries_lpar_hpte_insert() to install hpte, but fails with -2 due to
non-exist pfn. And finally, low_hash_fault() raise SIGBUS to process, as it
can be observed "Bus error"

From a viewpoint of listener and publisher, the publisher notifies the
listener before data is ready.  This introduces a problem where udev
launches kexec-tools (due to KOBJ_REMOVE) and loads a stale dt before
updating. And in capture kernel, makedumpfile will access the memory based
on the stale dt info, and hit a SIGBUS error due to an un-existed lmb.

* Fix *
This bug is introduced by commit 063b8b1251fd
("powerpc/pseries/memory-hotplug: Only update DT once per memory DLPAR
request"), which tried to combine all the dt updating into one.

To fix this issue, meanwhile not to introduce a quadratic runtime
complexity by the model:
  dlpar_memory_add_by_count
    for_each_drmem_lmb             <--
      dlpar_add_lmb
        drmem_update_dt(_v1|_v2)
          for_each_drmem_lmb       <--
The dt should still be only updated once, and just before the last memory
online/offline event is ejected to user space. Achieve this by tracing the
num of lmb added or removed.

Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: kexec@lists.infradead.org
---
v4 -> v5: change dlpar_add_lmb()/dlpar_remove_lmb() prototype to report
          whether dt is updated successfully.
          Fix a condition boundary check bug
v3 -> v4: resolve a quadratic runtime complexity issue.
          This series is applied on next-test branch
 arch/powerpc/platforms/pseries/hotplug-memory.c | 102 +++++++++++++++++++-----
 1 file changed, 80 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 46cbcd1..1567d9f 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -350,13 +350,22 @@ static bool lmb_is_removable(struct drmem_lmb *lmb)
 	return true;
 }
 
-static int dlpar_add_lmb(struct drmem_lmb *);
+enum dt_update_status {
+	DT_NOUPDATE,
+	DT_TOUPDATE,
+	DT_UPDATED,
+};
+
+/* "*dt_update" returns DT_UPDATED if updated */
+static int dlpar_add_lmb(struct drmem_lmb *lmb,
+		enum dt_update_status *dt_update);
 
-static int dlpar_remove_lmb(struct drmem_lmb *lmb)
+static int dlpar_remove_lmb(struct drmem_lmb *lmb,
+		enum dt_update_status *dt_update)
 {
 	unsigned long block_sz;
 	phys_addr_t base_addr;
-	int rc, nid;
+	int rc, ret, nid;
 
 	if (!lmb_is_removable(lmb))
 		return -EINVAL;
@@ -372,6 +381,13 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)
 	invalidate_lmb_associativity_index(lmb);
 	lmb_clear_nid(lmb);
 	lmb->flags &= ~DRCONF_MEM_ASSIGNED;
+	if (*dt_update) {
+		ret = drmem_update_dt();
+		if (ret)
+			pr_warn("%s fail to update dt, but continue\n", __func__);
+		else
+			*dt_update = DT_UPDATED;
+	}
 
 	__remove_memory(nid, base_addr, block_sz);
 
@@ -387,6 +403,7 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
 	int lmbs_removed = 0;
 	int lmbs_available = 0;
 	int rc;
+	enum dt_update_status dt_update = DT_NOUPDATE;
 
 	pr_info("Attempting to hot-remove %d LMB(s)\n", lmbs_to_remove);
 
@@ -409,7 +426,11 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
 	}
 
 	for_each_drmem_lmb(lmb) {
-		rc = dlpar_remove_lmb(lmb);
+
+		/* combine dt updating for all LMBs */
+		if (lmbs_to_remove - lmbs_removed <= 1)
+			dt_update = DT_TOUPDATE;
+		rc = dlpar_remove_lmb(lmb, &dt_update);
 		if (rc)
 			continue;
 
@@ -424,13 +445,17 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
 	}
 
 	if (lmbs_removed != lmbs_to_remove) {
+		enum dt_update_status rollback_dt_update = DT_NOUPDATE;
+
 		pr_err("Memory hot-remove failed, adding LMB's back\n");
 
 		for_each_drmem_lmb(lmb) {
 			if (!drmem_lmb_reserved(lmb))
 				continue;
 
-			rc = dlpar_add_lmb(lmb);
+			if (--lmbs_removed == 0 && dt_update == DT_UPDATED)
+				rollback_dt_update = DT_TOUPDATE;
+			rc = dlpar_add_lmb(lmb, &rollback_dt_update);
 			if (rc)
 				pr_err("Failed to add LMB back, drc index %x\n",
 				       lmb->drc_index);
@@ -458,6 +483,7 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
 
 static int dlpar_memory_remove_by_index(u32 drc_index)
 {
+	enum dt_update_status dt_update = DT_TOUPDATE;
 	struct drmem_lmb *lmb;
 	int lmb_found;
 	int rc;
@@ -468,7 +494,7 @@ static int dlpar_memory_remove_by_index(u32 drc_index)
 	for_each_drmem_lmb(lmb) {
 		if (lmb->drc_index == drc_index) {
 			lmb_found = 1;
-			rc = dlpar_remove_lmb(lmb);
+			rc = dlpar_remove_lmb(lmb, &dt_update);
 			if (!rc)
 				dlpar_release_drc(lmb->drc_index);
 
@@ -490,6 +516,7 @@ static int dlpar_memory_remove_by_index(u32 drc_index)
 
 static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
 {
+	enum dt_update_status dt_update = DT_NOUPDATE;
 	struct drmem_lmb *lmb, *start_lmb, *end_lmb;
 	int lmbs_available = 0;
 	int rc;
@@ -519,7 +546,9 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
 		if (!(lmb->flags & DRCONF_MEM_ASSIGNED))
 			continue;
 
-		rc = dlpar_remove_lmb(lmb);
+		if (lmb == end_lmb)
+			dt_update = DT_TOUPDATE;
+		rc = dlpar_remove_lmb(lmb, &dt_update);
 		if (rc)
 			break;
 
@@ -527,14 +556,16 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
 	}
 
 	if (rc) {
-		pr_err("Memory indexed-count-remove failed, adding any removed LMBs\n");
+		enum dt_update_status rollback_dt_update = DT_NOUPDATE;
 
+		pr_err("Memory indexed-count-remove failed, adding any removed LMBs\n");
 
 		for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
 			if (!drmem_lmb_reserved(lmb))
 				continue;
-
-			rc = dlpar_add_lmb(lmb);
+			if (lmb == end_lmb && dt_update == DT_UPDATED)
+				rollback_dt_update = DT_TOUPDATE;
+			rc = dlpar_add_lmb(lmb, &rollback_dt_update);
 			if (rc)
 				pr_err("Failed to add LMB, drc index %x\n",
 				       lmb->drc_index);
@@ -572,7 +603,7 @@ static inline int dlpar_memory_remove(struct pseries_hp_errorlog *hp_elog)
 {
 	return -EOPNOTSUPP;
 }
-static int dlpar_remove_lmb(struct drmem_lmb *lmb)
+static int dlpar_remove_lmb(struct drmem_lmb *lmb, bool dt_update)
 {
 	return -EOPNOTSUPP;
 }
@@ -591,10 +622,11 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
 }
 #endif /* CONFIG_MEMORY_HOTREMOVE */
 
-static int dlpar_add_lmb(struct drmem_lmb *lmb)
+static int dlpar_add_lmb(struct drmem_lmb *lmb,
+		enum dt_update_status *dt_update)
 {
 	unsigned long block_sz;
-	int rc;
+	int rc, ret;
 
 	if (lmb->flags & DRCONF_MEM_ASSIGNED)
 		return -EINVAL;
@@ -607,6 +639,13 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 
 	lmb_set_nid(lmb);
 	lmb->flags |= DRCONF_MEM_ASSIGNED;
+	if (*dt_update) {
+		ret = drmem_update_dt();
+		if (ret)
+			pr_warn("%s fail to update dt, but continue\n", __func__);
+		else
+			*dt_update = DT_UPDATED;
+	}
 
 	block_sz = memory_block_size_bytes();
 
@@ -616,6 +655,8 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 		invalidate_lmb_associativity_index(lmb);
 		lmb_clear_nid(lmb);
 		lmb->flags &= ~DRCONF_MEM_ASSIGNED;
+		if (*dt_update == DT_UPDATED)
+			drmem_update_dt();
 		return rc;
 	}
 
@@ -627,7 +668,11 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 		invalidate_lmb_associativity_index(lmb);
 		lmb_clear_nid(lmb);
 		lmb->flags &= ~DRCONF_MEM_ASSIGNED;
-
+		if (*dt_update == DT_UPDATED) {
+			ret = drmem_update_dt();
+			if (ret)
+				pr_warn("%s fail to update dt during rollback, but continue\n", __func__);
+		}
 		__remove_memory(nid, base_addr, block_sz);
 	}
 
@@ -636,6 +681,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 
 static int dlpar_memory_add_by_count(u32 lmbs_to_add)
 {
+	enum dt_update_status dt_update = DT_NOUPDATE;
 	struct drmem_lmb *lmb;
 	int lmbs_available = 0;
 	int lmbs_added = 0;
@@ -666,7 +712,9 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
 		if (rc)
 			continue;
 
-		rc = dlpar_add_lmb(lmb);
+		if (lmbs_to_add - lmbs_added <= 1)
+			dt_update = DT_TOUPDATE;
+		rc = dlpar_add_lmb(lmb, &dt_update);
 		if (rc) {
 			dlpar_release_drc(lmb->drc_index);
 			continue;
@@ -683,13 +731,18 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
 	}
 
 	if (lmbs_added != lmbs_to_add) {
+		enum dt_update_status rollback_dt_update = DT_NOUPDATE;
+
 		pr_err("Memory hot-add failed, removing any added LMBs\n");
 
 		for_each_drmem_lmb(lmb) {
 			if (!drmem_lmb_reserved(lmb))
 				continue;
 
-			rc = dlpar_remove_lmb(lmb);
+			if (--lmbs_added == 0 && dt_update == DT_UPDATED)
+				rollback_dt_update = DT_TOUPDATE;
+
+			rc = dlpar_remove_lmb(lmb, &rollback_dt_update);
 			if (rc)
 				pr_err("Failed to remove LMB, drc index %x\n",
 				       lmb->drc_index);
@@ -716,6 +769,7 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
 
 static int dlpar_memory_add_by_index(u32 drc_index)
 {
+	enum dt_update_status dt_update = DT_TOUPDATE;
 	struct drmem_lmb *lmb;
 	int rc, lmb_found;
 
@@ -727,7 +781,7 @@ static int dlpar_memory_add_by_index(u32 drc_index)
 			lmb_found = 1;
 			rc = dlpar_acquire_drc(lmb->drc_index);
 			if (!rc) {
-				rc = dlpar_add_lmb(lmb);
+				rc = dlpar_add_lmb(lmb, &dt_update);
 				if (rc)
 					dlpar_release_drc(lmb->drc_index);
 			}
@@ -750,6 +804,7 @@ static int dlpar_memory_add_by_index(u32 drc_index)
 
 static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
 {
+	enum dt_update_status dt_update = DT_NOUPDATE;
 	struct drmem_lmb *lmb, *start_lmb, *end_lmb;
 	int lmbs_available = 0;
 	int rc;
@@ -783,7 +838,9 @@ static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
 		if (rc)
 			break;
 
-		rc = dlpar_add_lmb(lmb);
+		if (lmb == end_lmb)
+			dt_update = DT_TOUPDATE;
+		rc = dlpar_add_lmb(lmb, &dt_update);
 		if (rc) {
 			dlpar_release_drc(lmb->drc_index);
 			break;
@@ -796,10 +853,14 @@ static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
 		pr_err("Memory indexed-count-add failed, removing any added LMBs\n");
 
 		for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
+			enum dt_update_status rollback_dt_update = DT_NOUPDATE;
+
 			if (!drmem_lmb_reserved(lmb))
 				continue;
 
-			rc = dlpar_remove_lmb(lmb);
+			if (lmb == end_lmb && dt_update == DT_UPDATED)
+				rollback_dt_update = DT_TOUPDATE;
+			rc = dlpar_remove_lmb(lmb, &rollback_dt_update);
 			if (rc)
 				pr_err("Failed to remove LMB, drc index %x\n",
 				       lmb->drc_index);
@@ -879,9 +940,6 @@ int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
 		break;
 	}
 
-	if (!rc)
-		rc = drmem_update_dt();
-
 	unlock_device_hotplug();
 	return rc;
 }
-- 
2.7.5


^ permalink raw reply related

* Re: [PATCH] ASoC: fsl_sai: Add -EPROBE_DEFER check for regmap init
From: Shengjiu Wang @ 2020-08-10  8:53 UTC (permalink / raw)
  To: Nicolin Chen
  Cc: Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
	Takashi Iwai, Liam Girdwood, Mark Brown, linuxppc-dev,
	linux-kernel
In-Reply-To: <20200810080018.GA13408@Asurada-Nvidia>

On Mon, Aug 10, 2020 at 4:02 PM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Fri, Aug 07, 2020 at 05:14:42PM +0800, Shengjiu Wang wrote:
> > Regmap initialization may return -EPROBE_DEFER for clock
> > may not be ready, so check -EPROBE_DEFER error type before
> > start another Regmap initialization.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> >  sound/soc/fsl/fsl_sai.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > index a22562f2df47..eb933fe9b6d1 100644
> > --- a/sound/soc/fsl/fsl_sai.c
> > +++ b/sound/soc/fsl/fsl_sai.c
> > @@ -927,7 +927,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
> >                       "bus", base, &fsl_sai_regmap_config);
> >
> >       /* Compatible with old DTB cases */
> > -     if (IS_ERR(sai->regmap))
> > +     if (IS_ERR(sai->regmap) && PTR_ERR(sai->regmap) != -EPROBE_DEFER)
> >               sai->regmap = devm_regmap_init_mmio_clk(&pdev->dev,
> >                               "sai", base, &fsl_sai_regmap_config);
> >       if (IS_ERR(sai->regmap)) {
>
> In that case, might need a !EPROBE_DEFER check for this
> fallback devm_regmap_init_mmio_clk at "sai" clock too?

No, I think it is ok for this fallback to return directly with
EPROBE_DEFER.

best regards
wang shengjiu

^ permalink raw reply

* Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"
From: Aneesh Kumar K.V @ 2020-08-10  8:58 UTC (permalink / raw)
  To: Christian Zigotzky
  Cc: Olof Johansson, Darren Stevens, linuxppc-dev, mad skateman,
	R.T.Dickinson
In-Reply-To: <51482c70-1007-1202-9ed1-2d174c1e923f@xenosoft.de>

On 8/10/20 2:15 PM, Christian Zigotzky wrote:
> Hello Aneesh,
> 
> I tested the new kernel today and unfortunately it doesn't run very well.
> 
> I have only one core (1 physical processor; 1 core; 2 threads) instead 
> of two cores (1 physical processor; 2 cores; 2 threads) so the system is 
> slower.
> 
> Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt
> 
> Could you please check the updates?


modified   arch/powerpc/mm/book3s64/hash_utils.c
@@ -1116,7 +1116,8 @@ void hash__early_init_mmu_secondary(void)
  		tlbiel_all();

  #ifdef CONFIG_PPC_MEM_KEYS
-	mtspr(SPRN_UAMOR, default_uamor);
+	if (mmu_has_feature(MMU_FTR_PKEY))
+		mtspr(SPRN_UAMOR, default_uamor);
  #endif
  }
  #endif /* CONFIG_SMP */



-aneesh

^ permalink raw reply

* Re: [PATCH] arch/powerpc: use simple i2c probe function
From: Wolfram Sang @ 2020-08-10  9:36 UTC (permalink / raw)
  To: Stephen Kitt
  Cc: linux-kernel, Scott Wood, Paul Mackerras, linux-i2c, linuxppc-dev
In-Reply-To: <20200807152713.381588-1-steve@sk2.org>

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Fri, Aug 07, 2020 at 05:27:13PM +0200, Stephen Kitt wrote:
> The i2c probe functions here don't use the id information provided in
> their second argument, so the single-parameter i2c probe function
> ("probe_new") can be used instead.
> 
> This avoids scanning the identifier tables during probes.
> 
> Signed-off-by: Stephen Kitt <steve@sk2.org>

This is useful, helps deprecating the old probe method:

Acked-by: Wolfram Sang <wsa@kernel.org>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply

* Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"
From: Christian Zigotzky @ 2020-08-10 10:22 UTC (permalink / raw)
  To: Aneesh Kumar K.V
  Cc: Olof Johansson, Darren Stevens, linuxppc-dev, mad skateman,
	R.T.Dickinson
In-Reply-To: <9688335c-d7d0-9eaa-22c6-511e708e0d2a@linux.ibm.com>

Am 10.08.20 um 10:58 schrieb Aneesh Kumar K.V:
> On 8/10/20 2:15 PM, Christian Zigotzky wrote:
>> Hello Aneesh,
>>
>> I tested the new kernel today and unfortunately it doesn't run very 
>> well.
>>
>> I have only one core (1 physical processor; 1 core; 2 threads) 
>> instead of two cores (1 physical processor; 2 cores; 2 threads) so 
>> the system is slower.
>>
>> Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt
>>
>> Could you please check the updates?
>
>
> modified   arch/powerpc/mm/book3s64/hash_utils.c
> @@ -1116,7 +1116,8 @@ void hash__early_init_mmu_secondary(void)
>          tlbiel_all();
>
>  #ifdef CONFIG_PPC_MEM_KEYS
> -    mtspr(SPRN_UAMOR, default_uamor);
> +    if (mmu_has_feature(MMU_FTR_PKEY))
> +        mtspr(SPRN_UAMOR, default_uamor);
>  #endif
>  }
>  #endif /* CONFIG_SMP */
>
>
>
> -aneesh
Hello Aneesh,

Your modifications work! I have 2 cores again and I can see the boot 
messages.

Thanks a lot!

Cheers,
Christian

^ permalink raw reply

* [PATCH] powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne X1000)
From: Aneesh Kumar K.V @ 2020-08-10 10:26 UTC (permalink / raw)
  To: linuxppc-dev, mpe; +Cc: Aneesh Kumar K.V, Christian Zigotzky

On p6 and before we should avoid updating UAMOR SPRN. This resulted
in boot failure on Nemo board.

Fixes: 269e829f48a0 ("powerpc/book3s64/pkey: Disable pkey on POWER6 and before")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
 arch/powerpc/mm/book3s64/hash_utils.c |  5 ++---
 arch/powerpc/mm/book3s64/pkeys.c      | 12 ++++++------
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
index 1478fceeb683..1da9dbba9217 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -1115,9 +1115,8 @@ void hash__early_init_mmu_secondary(void)
 			&& cpu_has_feature(CPU_FTR_HVMODE))
 		tlbiel_all();
 
-#ifdef CONFIG_PPC_MEM_KEYS
-	mtspr(SPRN_UAMOR, default_uamor);
-#endif
+	if (IS_ENABLED(CONFIG_PPC_MEM_KEYS) && mmu_has_feature(MMU_FTR_PKEY))
+		mtspr(SPRN_UAMOR, default_uamor);
 }
 #endif /* CONFIG_SMP */
 
diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
index 69a6b87f2bb4..b1d091a97611 100644
--- a/arch/powerpc/mm/book3s64/pkeys.c
+++ b/arch/powerpc/mm/book3s64/pkeys.c
@@ -73,12 +73,6 @@ static int scan_pkey_feature(void)
 	if (early_radix_enabled())
 		return 0;
 
-	/*
-	 * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
-	 */
-	if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
-		return 0;
-
 	ret = of_scan_flat_dt(dt_scan_storage_keys, &pkeys_total);
 	if (ret == 0) {
 		/*
@@ -124,6 +118,12 @@ void __init pkey_early_init_devtree(void)
 		     __builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)
 				!= (sizeof(u64) * BITS_PER_BYTE));
 
+	/*
+	 * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
+	 */
+	if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
+		return;
+
 	/* scan the device tree for pkey feature */
 	pkeys_total = scan_pkey_feature();
 	if (!pkeys_total)
-- 
2.26.2


^ permalink raw reply related

* Re: [PATCH] recordmcount: Fix build failure on non arm64
From: Catalin Marinas @ 2020-08-10 12:18 UTC (permalink / raw)
  To: Gregory Herrero
  Cc: linux-arm-kernel, linuxppc-dev, Steven Rostedt, linux-kernel
In-Reply-To: <20200810091730.GA3099@ltoracle>

On Mon, Aug 10, 2020 at 11:17:30AM +0200, Gregory Herrero wrote:
> On Mon, Aug 10, 2020 at 08:48:22AM +0000, Christophe Leroy wrote:
> > Commit ea0eada45632 leads to the following build failure on powerpc:
> > 
> >   HOSTCC  scripts/recordmcount
> > scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
> > scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
> > scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
> > scripts/recordmcount.c:440: error: for each function it appears in.)
> > make[2]: *** [scripts/recordmcount] Error 1
> > 
> > Make sure R_AARCH64_CALL26 is always defined.
> > 
> Oops, thanks for fixing this.
> 
> Acked-by: Gregory Herrero <gregory.herrero@oracle.com>

Thanks. I'll queue it via the arm64 tree (as I did with the previous
fix) but I'll wait a bit for Steve to ack it.

-- 
Catalin

^ permalink raw reply

* [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
From: Christian Zigotzky @ 2020-08-10 13:01 UTC (permalink / raw)
  To: Aneesh Kumar K.V
  Cc: Darren Stevens, R.T.Dickinson, kvm-ppc@vger.kernel.org,
	mad skateman, Olof Johansson, linuxppc-dev
In-Reply-To: <9688335c-d7d0-9eaa-22c6-511e708e0d2a@linux.ibm.com>

Hello,

Just for info. The latest git kernel doesn't work with a virtio_gpu anymore.

QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 
1024 -kernel uImage -drive 
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic 
user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga -device 
virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb 
-device usb-audio,bus=newusb.0 -smp 4

Error messages:

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc0000000000c7324
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted 
5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1
Workqueue: events .virtio_gpu_dequeue_ctrl_func
NIP:  c0000000000c7324 LR: c0000000000c72e4 CTR: c000000000462930
REGS: c00000003dba75e0 TRAP: 0300   Not tainted 
(5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty)
MSR:  0000000090029000 <CE,EE,ME>  CR: 24002288  XER: 00000000
DEAR: 0000000000000010 ESR: 0000000000000000 IRQMASK: 0
GPR00: c0000000000c6188 c00000003dba7870 c0000000017f2300 c00000003d893010
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000000
GPR08: 0000000000000000 0000000000000000 0000000000000000 7f7f7f7f7f7f7f7f
GPR12: 0000000024002284 c00000003fff9200 c00000000008c3a0 c0000000061566c0
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000001 0000000000110000 0000000000000000 0000000000000000
GPR28: c00000003d893010 0000000000000000 0000000000000000 c00000003d893010
NIP [c0000000000c7324] .dma_direct_unmap_sg+0x4c/0xd8
LR [c0000000000c72e4] .dma_direct_unmap_sg+0xc/0xd8
Call Trace:
[c00000003dba7870] [c00000003dba7950] 0xc00000003dba7950 (unreliable)
[c00000003dba7920] [c0000000000c6188] .dma_unmap_sg_attrs+0x5c/0x98
[c00000003dba79d0] [c0000000005cd438] .drm_gem_shmem_free_object+0x98/0xcc
[c00000003dba7a50] [c0000000006af5b4] .virtio_gpu_cleanup_object+0xc8/0xd4
[c00000003dba7ad0] [c0000000006ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30
[c00000003dba7b40] [c0000000006adab8] 
.virtio_gpu_dequeue_ctrl_func+0x208/0x28c
[c00000003dba7c10] [c000000000086b70] .process_one_work+0x1a4/0x258
[c00000003dba7cb0] [c0000000000870f4] .worker_thread+0x214/0x284
[c00000003dba7d70] [c00000000008c4f0] .kthread+0x150/0x158
[c00000003dba7e20] [c00000000000082c] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
f821ff51 7cb82b78 7cdb3378 4e000000 7cfa3b78 3bc00000 7f9ec000 41fc0014
382100b0 81810008 7d808120 48bc1ba8 <e93d0010> ebfc0248 833d0018 7fff4850
---[ end trace f28d194d9f0955a8 ]---

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0 
(slots), used 0 (slots)

----

The kernel 5.8 works without any problems in this virtual machine.

Could you please check the latest updates?

Thanks,
Christian

^ permalink raw reply

* Re: [PATCH] powerpc/papr_scm: Make access mode of 'perf_stats' attribute file to '0400'
From: Michael Ellerman @ 2020-08-10 13:12 UTC (permalink / raw)
  To: Vaibhav Jain, linuxppc-dev, linux-nvdimm
  Cc: Santosh Sivaraj, Aneesh Kumar K . V, Oliver O'Halloran,
	Vaibhav Jain, Dan Williams, Ira Weiny
In-Reply-To: <20200807123146.11037-1-vaibhav@linux.ibm.com>

Vaibhav Jain <vaibhav@linux.ibm.com> writes:
> The newly introduced 'perf_stats' attribute uses the default access
> mode of 0444 letting non-root users access performance stats of an
> nvdimm and potentially force the kernel into issuing large number of
> expensive HCALLs. Since the information exposed by this attribute
> cannot be cached hence its better to ward of access to this attribute
> from non-root users.
>
> Hence this patch updates the access-mode of 'perf_stats' sysfs
> attribute file to 0400 to make it only readable to root-users.

Or should we ratelimit it?

Fixes: ??

> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>

cheers


^ permalink raw reply

* Re: [PATCH] recordmcount: Fix build failure on non arm64
From: Steven Rostedt @ 2020-08-10 13:27 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: linux-arm-kernel, Gregory Herrero, linuxppc-dev, linux-kernel
In-Reply-To: <20200810121855.GD9480@gaia>

On Mon, 10 Aug 2020 13:18:55 +0100
Catalin Marinas <catalin.marinas@arm.com> wrote:

> > Oops, thanks for fixing this.
> > 
> > Acked-by: Gregory Herrero <gregory.herrero@oracle.com>  
> 
> Thanks. I'll queue it via the arm64 tree (as I did with the previous
> fix) but I'll wait a bit for Steve to ack it.

Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

-- Steve

^ permalink raw reply

* Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
From: Herbert Xu @ 2020-08-10 13:45 UTC (permalink / raw)
  To: Van Leeuwen, Pascal
  Cc: Andrei Botila, Andrei Botila, linux-s390@vger.kernel.org,
	Antoine Tenart, x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@axis.com, linux-crypto@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, David S. Miller,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <CY4PR0401MB36528610C3ABF802F8CBF35FC3440@CY4PR0401MB3652.namprd04.prod.outlook.com>

On Mon, Aug 10, 2020 at 10:20:20AM +0000, Van Leeuwen, Pascal wrote:
>
> With all due respect, but this makes no sense.

I agree.  This is a lot of churn for no gain.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: [PATCH] recordmcount: Fix build failure on non arm64
From: Catalin Marinas @ 2020-08-10 14:26 UTC (permalink / raw)
  To: Gregory Herrero, Steven Rostedt (VMware), Christophe Leroy
  Cc: linuxppc-dev, Will Deacon, linux-kernel, linux-arm-kernel
In-Reply-To: <5ca1be21fa6ebf73203b45fd9aadd2bafb5e6b15.1597049145.git.christophe.leroy@csgroup.eu>

On Mon, 10 Aug 2020 08:48:22 +0000 (UTC), Christophe Leroy wrote:
> Commit ea0eada45632 leads to the following build failure on powerpc:
> 
>   HOSTCC  scripts/recordmcount
> scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
> scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
> scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
> scripts/recordmcount.c:440: error: for each function it appears in.)
> make[2]: *** [scripts/recordmcount] Error 1
> 
> [...]

Applied to arm64 (for-next/core), thanks!

[1/1] recordmcount: Fix build failure on non arm64
      https://git.kernel.org/arm64/c/3df14264ad99

-- 
Catalin


^ permalink raw reply

* [PATCH] Documentation/features: refresh powerpc arch support files
From: Tobias Klauser @ 2020-08-10 10:09 UTC (permalink / raw)
  To: Jonathan Corbet; +Cc: linuxppc-dev, Nicholas Piggin, linux-doc

Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
Implement queued spinlocks and rwlocks").

Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
 Documentation/features/locking/queued-rwlocks/arch-support.txt  | 2 +-
 .../features/locking/queued-spinlocks/arch-support.txt          | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt
index 5c6bcfcf8e1f..4dd5e554873f 100644
--- a/Documentation/features/locking/queued-rwlocks/arch-support.txt
+++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt
@@ -22,7 +22,7 @@
     |       nios2: | TODO |
     |    openrisc: |  ok  |
     |      parisc: | TODO |
-    |     powerpc: | TODO |
+    |     powerpc: |  ok  |
     |       riscv: | TODO |
     |        s390: | TODO |
     |          sh: | TODO |
diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt
index b55e420a34ea..b16d4f71e5ce 100644
--- a/Documentation/features/locking/queued-spinlocks/arch-support.txt
+++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt
@@ -22,7 +22,7 @@
     |       nios2: | TODO |
     |    openrisc: |  ok  |
     |      parisc: | TODO |
-    |     powerpc: | TODO |
+    |     powerpc: |  ok  |
     |       riscv: | TODO |
     |        s390: | TODO |
     |          sh: | TODO |
-- 
2.27.0


^ permalink raw reply related

* Re: [PATCH] Documentation/features: refresh powerpc arch support files
From: Christophe Leroy @ 2020-08-10 15:09 UTC (permalink / raw)
  To: Tobias Klauser, Jonathan Corbet; +Cc: linuxppc-dev, Nicholas Piggin, linux-doc
In-Reply-To: <20200810100906.3805-1-tklauser@distanz.ch>



Le 10/08/2020 à 12:09, Tobias Klauser a écrit :
> Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
> Implement queued spinlocks and rwlocks").
> 
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
>   Documentation/features/locking/queued-rwlocks/arch-support.txt  | 2 +-
>   .../features/locking/queued-spinlocks/arch-support.txt          | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt
> index 5c6bcfcf8e1f..4dd5e554873f 100644
> --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt
> +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt
> @@ -22,7 +22,7 @@
>       |       nios2: | TODO |
>       |    openrisc: |  ok  |
>       |      parisc: | TODO |
> -    |     powerpc: | TODO |
> +    |     powerpc: |  ok  |

In your commit log you are refering to a commit titled "powerpc/64s:"

Are you sure it is now OK for all powerpc, not only for book3s/64 as 
suggested by yout text ?

Christophe

>       |       riscv: | TODO |
>       |        s390: | TODO |
>       |          sh: | TODO |
> diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt
> index b55e420a34ea..b16d4f71e5ce 100644
> --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt
> +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt
> @@ -22,7 +22,7 @@
>       |       nios2: | TODO |
>       |    openrisc: |  ok  |
>       |      parisc: | TODO |
> -    |     powerpc: | TODO |
> +    |     powerpc: |  ok  |
>       |       riscv: | TODO |
>       |        s390: | TODO |
>       |          sh: | TODO |
> 

^ permalink raw reply

* Re: [PATCH] Documentation/features: refresh powerpc arch support files
From: Tobias Klauser @ 2020-08-10 15:36 UTC (permalink / raw)
  To: Christophe Leroy
  Cc: linux-doc, linuxppc-dev, Nicholas Piggin, Jonathan Corbet
In-Reply-To: <4b6b65e8-ec79-ebf0-0ab5-7b48182584f1@csgroup.eu>

On 2020-08-10 at 17:09:51 +0200, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
> 
> 
> Le 10/08/2020 à 12:09, Tobias Klauser a écrit :
> > Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
> > Implement queued spinlocks and rwlocks").
> > 
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> > ---
> >   Documentation/features/locking/queued-rwlocks/arch-support.txt  | 2 +-
> >   .../features/locking/queued-spinlocks/arch-support.txt          | 2 +-
> >   2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt
> > index 5c6bcfcf8e1f..4dd5e554873f 100644
> > --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt
> > +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt
> > @@ -22,7 +22,7 @@
> >       |       nios2: | TODO |
> >       |    openrisc: |  ok  |
> >       |      parisc: | TODO |
> > -    |     powerpc: | TODO |
> > +    |     powerpc: |  ok  |
> 
> In your commit log you are refering to a commit titled "powerpc/64s:"
> 
> Are you sure it is now OK for all powerpc, not only for book3s/64 as
> suggested by yout text ?

The change was generated by running
Documentation/features/scripts/features-refresh.sh
Sorry, I should have mentioned this in the commit message. I noticed the
updated features for powerpc after updating the RISC-V supported
features [1].

[1] https://lore.kernel.org/linux-riscv/20200810095000.32092-1-tklauser@distanz.ch/T/#u

AFAIK, the features-refresh.sh script has no way of distinguishing
between different types of an architecture. It just checks for the
respective Kconfig symbols listed in the
Documentation/features/**/arch-support.txt files in all arch/**/Kconfig
files and updates the feature to "ok" if it finds the Kconfig symbol.

^ permalink raw reply

* Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
From: Eric Biggers @ 2020-08-10 17:03 UTC (permalink / raw)
  To: Horia Geantă
  Cc: Andrei Botila (OSS), Andrei Botila, Herbert Xu,
	Van Leeuwen, Pascal, Antoine Tenart, linux-s390@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@axis.com, linux-crypto@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, David S. Miller,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <fd3e5862-3357-7dfc-6c75-30086ab19f82@nxp.com>

On Mon, Aug 10, 2020 at 05:33:39PM +0300, Horia Geantă wrote:
> On 8/10/2020 4:45 PM, Herbert Xu wrote:
> > On Mon, Aug 10, 2020 at 10:20:20AM +0000, Van Leeuwen, Pascal wrote:
> >>
> >> With all due respect, but this makes no sense.
> > 
> > I agree.  This is a lot of churn for no gain.
> > 
> I would say the gain is that all skcipher algorithms would behave the same
> when input length equals zero - i.e. treat the request as a no-op.
> 
> We can't say "no input" has any meaning to the other skcipher algorithms,
> but the convention is to accept this case and just return 0.
> I don't see why XTS has to be handled differently.
> 

CTS also rejects empty inputs.

The rule it follows is just that all input lengths >= blocksize are allowed.
Input lengths < blocksize aren't allowed.

- Eric

^ permalink raw reply

* Re: [PATCH] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
From: Nathan Lynch @ 2020-08-10 20:03 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: tyreld, cheloha, Laurent Dufour, linuxppc-dev
In-Reply-To: <87tuxl1ant.fsf@mpe.ellerman.id.au>

Michael Ellerman <mpe@ellerman.id.au> writes:
> One thought, which I possibly should not put in writing, is that we
> could use the alignment of the pointer as a poor man's substitute for a
> counter, eg:
>
> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb)
> +{
> +	if (lmb % PAGE_SIZE == 0)
> +		cond_resched();
> +
> +	return ++lmb;
> +}
>
> I think the lmbs are allocated in a block, so I think that will work.
> Maybe PAGE_SIZE is not the right size to use, but you get the idea.
>
> Gross I know, but might be OK as short term solution?

OK, looking into this.

^ permalink raw reply

* Re: [PATCH] ASoC: fsl_sai: Add -EPROBE_DEFER check for regmap init
From: Nicolin Chen @ 2020-08-10 23:11 UTC (permalink / raw)
  To: Shengjiu Wang
  Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
	perex, broonie, festevam, linux-kernel
In-Reply-To: <1596791682-4311-1-git-send-email-shengjiu.wang@nxp.com>

On Fri, Aug 07, 2020 at 05:14:42PM +0800, Shengjiu Wang wrote:
> Regmap initialization may return -EPROBE_DEFER for clock
> may not be ready, so check -EPROBE_DEFER error type before
> start another Regmap initialization.
> 
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>

Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>

^ permalink raw reply

* Re: [PATCH v2] ASoC: fsl-asoc-card: Get "extal" clock rate by clk_get_rate
From: Nicolin Chen @ 2020-08-10 23:13 UTC (permalink / raw)
  To: Shengjiu Wang
  Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, lgirdwood,
	perex, broonie, festevam, linux-kernel
In-Reply-To: <1597047103-6863-1-git-send-email-shengjiu.wang@nxp.com>

On Mon, Aug 10, 2020 at 04:11:43PM +0800, Shengjiu Wang wrote:
> On some platform(.e.g. i.MX8QM MEK), the "extal" clock is different
> with the mclk of codec, then the clock rate is also different.
> So it is better to get clock rate of "extal" rate by clk_get_rate,
> don't reuse the clock rate of mclk.
> 
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>

Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>

^ permalink raw reply

* Re: [PATCH] recordmcount: Fix build failure on non arm64
From: Gregory Herrero @ 2020-08-10  9:17 UTC (permalink / raw)
  To: Christophe Leroy
  Cc: linux-arm-kernel, Catalin Marinas, linuxppc-dev, linux-kernel,
	Steven Rostedt
In-Reply-To: <5ca1be21fa6ebf73203b45fd9aadd2bafb5e6b15.1597049145.git.christophe.leroy@csgroup.eu>

Hi Christophe,

On Mon, Aug 10, 2020 at 08:48:22AM +0000, Christophe Leroy wrote:
> Commit ea0eada45632 leads to the following build failure on powerpc:
> 
>   HOSTCC  scripts/recordmcount
> scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
> scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
> scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
> scripts/recordmcount.c:440: error: for each function it appears in.)
> make[2]: *** [scripts/recordmcount] Error 1
> 
> Make sure R_AARCH64_CALL26 is always defined.
> 
Oops, thanks for fixing this.

Acked-by: Gregory Herrero <gregory.herrero@oracle.com>

Greg

> Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.")
> Cc: Gregory Herrero <gregory.herrero@oracle.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
>  scripts/recordmcount.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
> index e59022b3f125..b9c2ee7ab43f 100644
> --- a/scripts/recordmcount.c
> +++ b/scripts/recordmcount.c
> @@ -42,6 +42,8 @@
>  #define R_ARM_THM_CALL		10
>  #define R_ARM_CALL		28
>  
> +#define R_AARCH64_CALL26	283
> +
>  static int fd_map;	/* File descriptor for file being modified. */
>  static int mmap_failed; /* Boolean flag. */
>  static char gpfx;	/* prefix for global symbol name (sometimes '_') */
> -- 
> 2.25.0
> 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox