[PATCH] powerpc/xive: Fix bogus error code returned by OPAL
There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call
to return the 32-bit value 0x when OPAL has run out of IRQs.
Unfortunatelty, OPAL return values are signed 64-bit entities and
errors are supposed to be negative. If that happens, the linux code
confusingly treats 0x as a valid IRQ number and panics at some
point.
A fix was recently merged in skiboot:
e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()")
but we need a workaround anyway to support older skiboots already
in the field.
Internally convert 0x to OPAL_RESOURCE which is the usual error
returned upon resource exhaustion.
Cc: sta...@vger.kernel.org # v4.12+
Signed-off-by: Greg Kurz
Reviewed-by: Cédric Le Goater
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/156821713818.1985334.14123187368108582810.st...@bahia.lan
(cherry picked from commit 6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8,
groug: fix arch/powerpc/platforms/powernv/opal-wrappers.S instead of
non-existing arch/powerpc/platforms/powernv/opal-call.c)
Signed-off-by: Greg Kurz
---
This is for 4.14 and 4.19.
arch/powerpc/include/asm/opal.h|2 +-
arch/powerpc/platforms/powernv/opal-wrappers.S |2 +-
arch/powerpc/sysdev/xive/native.c | 11 +++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 8eb3ebca02df..163970c56e2f 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -266,7 +266,7 @@ int64_t opal_xive_get_vp_info(uint64_t vp,
int64_t opal_xive_set_vp_info(uint64_t vp,
uint64_t flags,
uint64_t report_cl_pair);
-int64_t opal_xive_allocate_irq(uint32_t chip_id);
+int64_t opal_xive_allocate_irq_raw(uint32_t chip_id);
int64_t opal_xive_free_irq(uint32_t girq);
int64_t opal_xive_sync(uint32_t type, uint32_t id);
int64_t opal_xive_dump(uint32_t type, uint32_t id);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 8c1ede2d3f7e..b12a75a0ee8b 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -301,7 +301,7 @@ OPAL_CALL(opal_xive_set_queue_info,
OPAL_XIVE_SET_QUEUE_INFO);
OPAL_CALL(opal_xive_donate_page, OPAL_XIVE_DONATE_PAGE);
OPAL_CALL(opal_xive_alloc_vp_block,OPAL_XIVE_ALLOCATE_VP_BLOCK);
OPAL_CALL(opal_xive_free_vp_block, OPAL_XIVE_FREE_VP_BLOCK);
-OPAL_CALL(opal_xive_allocate_irq, OPAL_XIVE_ALLOCATE_IRQ);
+OPAL_CALL(opal_xive_allocate_irq_raw, OPAL_XIVE_ALLOCATE_IRQ);
OPAL_CALL(opal_xive_free_irq, OPAL_XIVE_FREE_IRQ);
OPAL_CALL(opal_xive_get_vp_info, OPAL_XIVE_GET_VP_INFO);
OPAL_CALL(opal_xive_set_vp_info, OPAL_XIVE_SET_VP_INFO);
diff --git a/arch/powerpc/sysdev/xive/native.c
b/arch/powerpc/sysdev/xive/native.c
index 0f89ee557b04..aac61374afeb 100644
--- a/arch/powerpc/sysdev/xive/native.c
+++ b/arch/powerpc/sysdev/xive/native.c
@@ -234,6 +234,17 @@ static bool xive_native_match(struct device_node *node)
return of_device_is_compatible(node, "ibm,opal-xive-vc");
}
+static s64 opal_xive_allocate_irq(u32 chip_id)
+{
+ s64 irq = opal_xive_allocate_irq_raw(chip_id);
+
+ /*
+* Old versions of skiboot can incorrectly return 0x to
+* indicate no space, fix it up here.
+*/
+ return irq == 0x ? OPAL_RESOURCE : irq;
+}
+
#ifdef CONFIG_SMP
static int xive_native_get_ipi(unsigned int cpu, struct xive_cpu *xc)
{
Re: [PATCH V3 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
On 09/21/2019 09:30 PM, kbuild test robot wrote:
> Hi Anshuman,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3 next-20190919]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-for-architecture-exported-page-table-helpers/20190920-143746
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 7.4.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=ia64
> :: branch date: 3 hours ago
> :: commit date: 3 hours ago
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> All error/warnings (new ones prefixed by >>):
>
>In file included from include/asm-generic/pgtable-nopud.h:8:0,
> from arch/ia64/include/asm/pgtable.h:591,
> from include/linux/mm.h:99,
> from include/linux/highmem.h:8,
> from mm/arch_pgtable_test.c:14:
>mm/arch_pgtable_test.c: In function 'pud_clear_tests':
>>> include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration
>>> of function '__pgd'; did you mean '__p4d'?
>>> [-Werror=implicit-function-declaration]
> #define __pud(x)((pud_t) { __pgd(x) })
>^
>>> mm/arch_pgtable_test.c:162:8: note: in expansion of macro '__pud'
> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
>^
>>> include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces
>>> around initializer [-Wmissing-braces]
> #define __pud(x)((pud_t) { __pgd(x) })
> ^
>>> mm/arch_pgtable_test.c:162:8: note: in expansion of macro '__pud'
> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
>^
>cc1: some warnings being treated as errors
>
> #
> https://github.com/0day-ci/linux/commit/49047f93b076974eefa5b019311bd3b734d61f8c
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 49047f93b076974eefa5b019311bd3b734d61f8c
> vim +47 include/asm-generic/pgtable-nop4d-hack.h
>
> 30ec842660bd0d Kirill A. Shutemov 2017-03-09 45
> 30ec842660bd0d Kirill A. Shutemov 2017-03-09 46 #define pud_val(x)
> (pgd_val((x).pgd))
> 30ec842660bd0d Kirill A. Shutemov 2017-03-09 @47 #define __pud(x)
> ((pud_t) { __pgd(x) })
I had mentioned about this build failure in the cover letter. The same
problem also exists on arm32 platform.
- Anshuman
Re: [PATCH v5 05/12] powerpc/eeh: EEH for pSeries hot plug
On Thu, Sep 19, 2019 at 03:28:40PM -0500, Nathan Lynch wrote: > Hello Sam, > > Sam Bobroff writes: > > On PowerNV and pSeries, devices currently acquire EEH support from > > several different places: Boot-time devices from eeh_probe_devices() > > and eeh_addr_cache_build(), Virtual Function devices from the pcibios > > bus add device hooks and hot plugged devices from pci_hp_add_devices() > > (with other platforms using other methods as well). Unfortunately, > > pSeries machines currently discover hot plugged devices using > > pci_rescan_bus(), not pci_hp_add_devices(), and so those devices do > > not receive EEH support. > > > > Rather than adding another case for pci_rescan_bus(), this change > > widens the scope of the pcibios bus add device hooks so that they can > > handle all devices. As a side effect this also supports devices > > discovered after manually rescanning via /sys/bus/pci/rescan. > > > > Note that on PowerNV, this change allows the EEH subsystem to become > > enabled after boot as long as it has not been forced off, which was > > not previously possible (it was already possible on pSeries). > > With this change, I get a crash (use after free by the looks of it) when > I remove and then add a pci device in qemu: > > $ qemu-system-ppc64 -M pseries -append 'debug console=hvc0' \ > -nographic -vga none -m 1G,slots=32,maxmem=1024G -smp 2 \ > -kernel vmlinux -initrd ~/b/br/ppc64le-initramfs/images/rootfs.cpio \ > -nic model=e1000 > > ... > > # echo 1 > /sys/devices/pci:00/:00:00.0/remove ; \ > echo 1 > /sys/devices/pci:00/pci_bus/:00/rescan > > pci :00:00.0: Removing from iommu group 0 > pci :00:00.0: [8086:100e] type 00 class 0x02 > pci :00:00.0: reg 0x10: [mem 0x20008000-0x20008001] > pci :00:00.0: reg 0x14: [io 0x10040-0x1007f] > pci :00:00.0: reg 0x30: [mem 0x20008004-0x20008007 pref] > pci :00:00.0: Adding to iommu group 0 > pci :00:00.0: BAR 6: assigned [mem 0x20008000-0x20008003 pref] > pci :00:00.0: BAR 0: assigned [mem 0x20008004-0x20008005] > pci :00:00.0: BAR 1: assigned [io 0x1-0x1003f] > e1000 :00:00.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56 > e1000 :00:00.0 eth0: Intel(R) PRO/1000 Network Connection > pci :00:00.0: Removing from iommu group 0 > pci :00:00.0: [8086:100e] type 00 class 0x02 > pci :00:00.0: reg 0x10: [mem 0x20008004-0x20008005] > pci :00:00.0: reg 0x14: [io 0x1-0x1003f] > pci :00:00.0: reg 0x30: [mem 0x20008004-0x20008007 pref] > pci :00:00.0: BAR 6: assigned [mem 0x20008000-0x20008003 pref] > pci :00:00.0: BAR 0: assigned [mem 0x20008004-0x20008005] > pci :00:00.0: BAR 1: assigned [io 0x1-0x1003f] > BUG: Unable to handle kernel data access at 0x6b6b6b6b6b6b6bfb > Faulting instruction address: 0xc0597270 > Oops: Kernel access of bad area, sig: 11 [#1] > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > Modules linked in: > CPU: 0 PID: 2464 Comm: pci-probe-vs-cp Not tainted > 5.3.0-rc2-00092-gf381d5711f09 #76 > NIP: c0597270 LR: c0599470 CTR: c02030b0 > REGS: c0003ee4f650 TRAP: 0380 Not tainted > (5.3.0-rc2-00092-gf381d5711f09) > MSR: 80009033 CR: 24002442 XER: > CFAR: c059946c IRQMASK: 0 > GPR00: c0599470 c0003ee4f8e0 c3317a00 6b6b6b6b6b6b6b6b > GPR04: c1d0fa38 221a64979a66f870 > GPR08: c347b398 c336e070 > GPR12: 2000 c406 > GPR16: 100a78d8 7fffe9fdff96 100a7898 > GPR20: 100e0ff0 100e0fe8 > GPR24: 01002ae50260 c1d0fa38 6b6b6b6b6b6b6b6b > GPR28: fff2 c1d0fa38 c3118c18 > NIP [c0597270] kernfs_find_ns+0x50/0x3d0 > LR [c0599470] kernfs_remove_by_name_ns+0x60/0xe0 > Call Trace: > [c0003ee4f8e0] [c020950c] lockdep_hardirqs_on+0x10c/0x210 > (unreliable) > [c0003ee4f970] [c0599470] kernfs_remove_by_name_ns+0x60/0xe0 > [c0003ee4fa00] [c059ca08] sysfs_remove_file_ns+0x28/0x40 > [c0003ee4fa20] [c0cbd70c] device_remove_file+0x2c/0x40 > [c0003ee4fa40] [c0051480] eeh_sysfs_remove_device+0x50/0xf0 > [c0003ee4fa80] [c004a594] eeh_add_device_late.part.7+0x84/0x220 > [c0003ee4fb00] [c00e94f0] pseries_pcibios_bus_add_device+0x60/0xb0 > [c0003ee4fb70] [c006fc40] pcibios_bus_add_device+0x40/0x60 > [c0003ee4fb90] [c0bc5220] pci_bus_add_device+0x30/0x100 > [c0003ee4fc00] [c0bc5344] pci_bus_add_devices+0x54/0xb0 > [c0003ee4fc40] [c0bca058] pci_rescan_bus+0x48/0x70 > [c0003ee4fc70] [c0bd9adc] dev_bus_rescan_store+0xcc/0x100 >
Re: [PATCH] powerpc/crashkernel: take mem option into account
On Wed, Sep 18, 2019 at 7:23 PM Michael Ellerman wrote:
>
> Pingfan Liu writes:
> > Cc Kexec list. And keep the original content.
> >
> > On Thu, Sep 12, 2019 at 10:50 AM Pingfan Liu wrote:
> >>
> >> 'mem=" option is an easy way to put high pressure on memory during some
> >> test. Hence in stead of total mem, the effective usable memory size
>^ ^
>instead"actual" would be clearer
>
> I think adding: "after applying the memory limit"
>
> would help here.
>
> >> should be considered when reserving mem for crashkernel. Otherwise
> >> the boot up may experience oom issue.
> ^
> OOM
> >>
> >> E.g passing
> >> crashkernel="2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G", and
> >> mem=5G on a 256G machine.
>
> Spelling out the behaviour before and after would help here, eg:
>
> .. "would reserve 4G prior to the change and 512M afterward."
>
Thanks for kindly review. I will update the commit based on your suggestion.
>
> >> Signed-off-by: Pingfan Liu
> >> Cc: Hari Bathini
> >> Cc: Michael Ellerman
> >> To: linuxppc-dev@lists.ozlabs.org
> >> ---
> >> v1 -> v2: fix the printk info about the total mem
> >> arch/powerpc/kernel/machine_kexec.c | 7 ---
> >> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/powerpc/kernel/machine_kexec.c
> >> b/arch/powerpc/kernel/machine_kexec.c
> >> index c4ed328..eec96dc 100644
> >> --- a/arch/powerpc/kernel/machine_kexec.c
> >> +++ b/arch/powerpc/kernel/machine_kexec.c
> >> @@ -114,11 +114,12 @@ void machine_kexec(struct kimage *image)
> >>
> >> void __init reserve_crashkernel(void)
> >> {
> >> - unsigned long long crash_size, crash_base;
> >> + unsigned long long crash_size, crash_base, total_mem_sz;
> >> int ret;
> >>
> >> + total_mem_sz = memory_limit ? memory_limit :
> >> memblock_phys_mem_size();
> >> /* use common parsing */
> >> - ret = parse_crashkernel(boot_command_line,
> >> memblock_phys_mem_size(),
> >> + ret = parse_crashkernel(boot_command_line, total_mem_sz,
> >> &crash_size, &crash_base);
>
> I think this change makes sense. But we have multiple arches that
> implement similar logic, and I wonder if we should keep them all the
> same.
>
> eg:
>
> arch/arm/kernel/setup.c:ret =
> parse_crashkernel(boot_command_line, total_mem,
> arch/arm64/mm/init.c: ret =
> parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> arch/ia64/kernel/setup.c: ret =
> parse_crashkernel(boot_command_line, total,
> arch/mips/kernel/setup.c: ret =
> parse_crashkernel(boot_command_line, total_mem,
> arch/powerpc/kernel/fadump.c: ret =
> parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> arch/powerpc/kernel/machine_kexec.c:ret =
> parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> arch/s390/kernel/setup.c: rc =
> parse_crashkernel(boot_command_line, memory_end, &crash_size,
> arch/sh/kernel/machine_kexec.c: ret =
> parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> arch/x86/kernel/setup.c:ret =
> parse_crashkernel(boot_command_line, total_mem, &crash_size, &crash_base);
>
>
> From a quick glance most of them don't seem to take the memory limit
> into account.
>
> So I guess the question is do we want all arches to implement the same
> behaviour or do we think it doesn't matter if they differ in details
> like this?
On powerpc, the current code make fadump/kdump a higher priority than
"mem=" option, as the notes in fadump_reserve_mem() says
"
/*
* Calculate the memory boundary.
* If memory_limit is less than actual memory boundary then reserve
* the memory for fadump beyond the memory_limit and adjust the
* memory_limit accordingly, so that the running kernel can run with
* specified memory_limit.
*/
"
While on other archs, they pack "mem=" info into memblock before
calling memblock_phys_mem_size(). So when parse_crashkernel() calls
memblock_phys_mem_size(), the "mem=" takes effect.
E.g for x86 in arch/x86/kernel/e820.c
static int __init parse_memopt(char *p)
{
...
e820__range_remove(mem_size, ULLONG_MAX - mem_size, E820_TYPE_RAM, 1);
// this pack the "mem=" info into e820, and is finally feed to
memblock
}
Thanks,
Pingfan
Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware
On 2019/9/22 6:38, Paul Burton wrote: > Hi Yunsheng, > > On Tue, Sep 17, 2019 at 08:48:54PM +0800, Yunsheng Lin wrote: >> When passing the return value of dev_to_node() to cpumask_of_node() >> without checking if the device's node id is NUMA_NO_NODE, there is >> global-out-of-bounds detected by KASAN. >> >> From the discussion [1], NUMA_NO_NODE really means no node affinity, >> which also means all cpus should be usable. So the cpumask_of_node() >> should always return all cpus online when user passes the node id as >> NUMA_NO_NODE, just like similar semantic that page allocator handles >> NUMA_NO_NODE. >> >> But we cannot really copy the page allocator logic. Simply because the >> page allocator doesn't enforce the near node affinity. It just picks it >> up as a preferred node but then it is free to fallback to any other numa >> node. This is not the case here and node_to_cpumask_map will only restrict >> to the particular node's cpus which would have really non deterministic >> behavior depending on where the code is executed. So in fact we really >> want to return cpu_online_mask for NUMA_NO_NODE. >> >> Also there is a debugging version of node_to_cpumask_map() for x86 and >> arm64, which is only used when CONFIG_DEBUG_PER_CPU_MAPS is defined, this >> patch changes it to handle NUMA_NO_NODE as normal node_to_cpumask_map(). >> >> [1] https://lore.kernel.org/patchwork/patch/1125789/ >> Signed-off-by: Yunsheng Lin >> Suggested-by: Michal Hocko >> Acked-by: Michal Hocko > > If you end up sending another revision then I think it would be worth > replacing -1 with NUMA_NO_NODE in > arch/mips/include/asm/mach-ip27/topology.h for consistency, but in any > case: Perhaps it is better to replace -1 with NUMA_NO_NODE along with cpu_all_mask -> cpu_online_mask change if the cpu_all_mask -> cpu_online_mask change is reasonable. Anyway, will do that if there is another version needed. > > Acked-by: Paul Burton # MIPS bits Thanks for that. > > Thanks, > Paul > >> --- >> V6: Drop the cpu_all_mask -> cpu_online_mask change for it seems a >> little controversial, may need deeper investigation, and rebased >> on the latest linux-next. >> V5: Drop unsigned "fix" change for x86/arm64, and change comment log >> according to Michal's comment. >> V4: Have all these changes in a single patch. >> V3: Change to only handle NUMA_NO_NODE, and return cpu_online_mask >> for NUMA_NO_NODE case, and change the commit log to better justify >> the change. >> V2: make the node id checking change to other arches too. >> --- >> arch/arm64/include/asm/numa.h| 3 +++ >> arch/arm64/mm/numa.c | 3 +++ >> arch/mips/include/asm/mach-loongson64/topology.h | 4 +++- >> arch/s390/include/asm/topology.h | 3 +++ >> arch/x86/include/asm/topology.h | 3 +++ >> arch/x86/mm/numa.c | 3 +++ >> 6 files changed, 18 insertions(+), 1 deletion(-) > > . >
[Bug 195755] rcu_sched detected stalls on CPUs/tasks: (detected by 0, t=6302 jiffies, g=11405, c=11404, q=1880), ppc64, G5
https://bugzilla.kernel.org/show_bug.cgi?id=195755 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEEDINFO|CLOSED Resolution|--- |OBSOLETE --- Comment #26 from Erhard F. (erhar...@mailbox.org) --- Have not seen this again on the G5 7,2 since kernel 5.2.x, nor 5.3.x. Will close the bug for now and hopefully it does not return. ;) -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH AUTOSEL 4.19 089/128] ASoC: fsl_ssi: Fix clock control issue in master mode
From: Shengjiu Wang
[ Upstream commit 696d05225cebffd172008d212657be90e823eac0 ]
The test case is
arecord -Dhw:0 -d 10 -f S16_LE -r 48000 -c 2 temp.wav &
aplay -Dhw:0 -d 30 -f S16_LE -r 48000 -c 2 test.wav
There will be error after end of arecord:
aplay: pcm_write:2051: write error: Input/output error
Capture and Playback work in parallel in master mode, one
substream stops, the other substream is impacted, the
reason is that clock is disabled wrongly.
The clock's reference count is not increased when second
substream starts, the hw_param() function returns in the
beginning because first substream is enabled, then in end
of first substream, the hw_free() disables the clock.
This patch is to move the clock enablement to the place
before checking of the device enablement in hw_param().
Signed-off-by: Shengjiu Wang
Link:
https://lore.kernel.org/r/1567012817-12625-1-git-send-email-shengjiu.w...@nxp.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/fsl_ssi.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 0a648229e6430..bc1372c5f3243 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -799,15 +799,6 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream
*substream,
u32 wl = SSI_SxCCR_WL(sample_size);
int ret;
- /*
-* SSI is properly configured if it is enabled and running in
-* the synchronous mode; Note that AC97 mode is an exception
-* that should set separate configurations for STCCR and SRCCR
-* despite running in the synchronous mode.
-*/
- if (ssi->streams && ssi->synchronous)
- return 0;
-
if (fsl_ssi_is_i2s_master(ssi)) {
ret = fsl_ssi_set_bclk(substream, dai, hw_params);
if (ret)
@@ -823,6 +814,15 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream
*substream,
}
}
+ /*
+* SSI is properly configured if it is enabled and running in
+* the synchronous mode; Note that AC97 mode is an exception
+* that should set separate configurations for STCCR and SRCCR
+* despite running in the synchronous mode.
+*/
+ if (ssi->streams && ssi->synchronous)
+ return 0;
+
if (!fsl_ssi_is_ac97(ssi)) {
/*
* Keep the ssi->i2s_net intact while having a local variable
--
2.20.1
[PATCH AUTOSEL 5.2 129/185] ASoC: fsl_ssi: Fix clock control issue in master mode
From: Shengjiu Wang
[ Upstream commit 696d05225cebffd172008d212657be90e823eac0 ]
The test case is
arecord -Dhw:0 -d 10 -f S16_LE -r 48000 -c 2 temp.wav &
aplay -Dhw:0 -d 30 -f S16_LE -r 48000 -c 2 test.wav
There will be error after end of arecord:
aplay: pcm_write:2051: write error: Input/output error
Capture and Playback work in parallel in master mode, one
substream stops, the other substream is impacted, the
reason is that clock is disabled wrongly.
The clock's reference count is not increased when second
substream starts, the hw_param() function returns in the
beginning because first substream is enabled, then in end
of first substream, the hw_free() disables the clock.
This patch is to move the clock enablement to the place
before checking of the device enablement in hw_param().
Signed-off-by: Shengjiu Wang
Link:
https://lore.kernel.org/r/1567012817-12625-1-git-send-email-shengjiu.w...@nxp.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/fsl_ssi.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 09b2967befd96..d83be26d64467 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -799,15 +799,6 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream
*substream,
u32 wl = SSI_SxCCR_WL(sample_size);
int ret;
- /*
-* SSI is properly configured if it is enabled and running in
-* the synchronous mode; Note that AC97 mode is an exception
-* that should set separate configurations for STCCR and SRCCR
-* despite running in the synchronous mode.
-*/
- if (ssi->streams && ssi->synchronous)
- return 0;
-
if (fsl_ssi_is_i2s_master(ssi)) {
ret = fsl_ssi_set_bclk(substream, dai, hw_params);
if (ret)
@@ -823,6 +814,15 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream
*substream,
}
}
+ /*
+* SSI is properly configured if it is enabled and running in
+* the synchronous mode; Note that AC97 mode is an exception
+* that should set separate configurations for STCCR and SRCCR
+* despite running in the synchronous mode.
+*/
+ if (ssi->streams && ssi->synchronous)
+ return 0;
+
if (!fsl_ssi_is_ac97(ssi)) {
/*
* Keep the ssi->i2s_net intact while having a local variable
--
2.20.1
[PATCH AUTOSEL 5.2 087/185] powerpc/Makefile: Always pass --synthetic to nm if supported
From: Michael Ellerman [ Upstream commit 117acf5c29dd89e4c86761c365b9724dba0d9763 ] Back in 2004 we added logic to arch/ppc64/Makefile to pass the --synthetic option to nm, if it was supported by nm. Then in 2005 when arch/ppc64 and arch/ppc were merged, the logic to add --synthetic was moved inside an #ifdef CONFIG_PPC64 block within arch/powerpc/Makefile, and has remained there since. That was fine, though crufty, until recently when a change to init/Kconfig added a config time check that uses $(NM). On powerpc that leads to an infinite loop because Kconfig uses $(NM) to calculate some values, then the powerpc Makefile changes $(NM), which Kconfig notices and restarts. The original commit that added --synthetic simply said: On new toolchains we need to use nm --synthetic or we miss code symbols. And the nm man page says that the --synthetic option causes nm to: Include synthetic symbols in the output. These are special symbols created by the linker for various purposes. So it seems safe to always pass --synthetic if nm supports it, ie. on 32-bit and 64-bit, it just means 32-bit kernels might have more symbols reported (and in practice I see no extra symbols). Making it unconditional avoids the #ifdef CONFIG_PPC64, which in turn avoids the infinite loop. Debugged-by: Peter Collingbourne Signed-off-by: Michael Ellerman Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/powerpc/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index c345b79414a96..403f7e193833a 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -39,13 +39,11 @@ endif uname := $(shell uname -m) KBUILD_DEFCONFIG := $(if $(filter ppc%,$(uname)),$(uname),ppc64)_defconfig -ifdef CONFIG_PPC64 new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' > /dev/null; then echo y; else echo n; fi) ifeq ($(new_nm),y) NM := $(NM) --synthetic endif -endif # BITS is used as extension for files which are available in a 32 bit # and a 64 bit version to simplify shared Makefiles. -- 2.20.1
[PATCH AUTOSEL 5.3 143/203] ASoC: fsl_ssi: Fix clock control issue in master mode
From: Shengjiu Wang
[ Upstream commit 696d05225cebffd172008d212657be90e823eac0 ]
The test case is
arecord -Dhw:0 -d 10 -f S16_LE -r 48000 -c 2 temp.wav &
aplay -Dhw:0 -d 30 -f S16_LE -r 48000 -c 2 test.wav
There will be error after end of arecord:
aplay: pcm_write:2051: write error: Input/output error
Capture and Playback work in parallel in master mode, one
substream stops, the other substream is impacted, the
reason is that clock is disabled wrongly.
The clock's reference count is not increased when second
substream starts, the hw_param() function returns in the
beginning because first substream is enabled, then in end
of first substream, the hw_free() disables the clock.
This patch is to move the clock enablement to the place
before checking of the device enablement in hw_param().
Signed-off-by: Shengjiu Wang
Link:
https://lore.kernel.org/r/1567012817-12625-1-git-send-email-shengjiu.w...@nxp.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/fsl_ssi.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index fa862af25c1a3..085855f9b08d4 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -799,15 +799,6 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream
*substream,
u32 wl = SSI_SxCCR_WL(sample_size);
int ret;
- /*
-* SSI is properly configured if it is enabled and running in
-* the synchronous mode; Note that AC97 mode is an exception
-* that should set separate configurations for STCCR and SRCCR
-* despite running in the synchronous mode.
-*/
- if (ssi->streams && ssi->synchronous)
- return 0;
-
if (fsl_ssi_is_i2s_master(ssi)) {
ret = fsl_ssi_set_bclk(substream, dai, hw_params);
if (ret)
@@ -823,6 +814,15 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream
*substream,
}
}
+ /*
+* SSI is properly configured if it is enabled and running in
+* the synchronous mode; Note that AC97 mode is an exception
+* that should set separate configurations for STCCR and SRCCR
+* despite running in the synchronous mode.
+*/
+ if (ssi->streams && ssi->synchronous)
+ return 0;
+
if (!fsl_ssi_is_ac97(ssi)) {
/*
* Keep the ssi->i2s_net intact while having a local variable
--
2.20.1
[PATCH AUTOSEL 5.3 097/203] powerpc/Makefile: Always pass --synthetic to nm if supported
From: Michael Ellerman [ Upstream commit 117acf5c29dd89e4c86761c365b9724dba0d9763 ] Back in 2004 we added logic to arch/ppc64/Makefile to pass the --synthetic option to nm, if it was supported by nm. Then in 2005 when arch/ppc64 and arch/ppc were merged, the logic to add --synthetic was moved inside an #ifdef CONFIG_PPC64 block within arch/powerpc/Makefile, and has remained there since. That was fine, though crufty, until recently when a change to init/Kconfig added a config time check that uses $(NM). On powerpc that leads to an infinite loop because Kconfig uses $(NM) to calculate some values, then the powerpc Makefile changes $(NM), which Kconfig notices and restarts. The original commit that added --synthetic simply said: On new toolchains we need to use nm --synthetic or we miss code symbols. And the nm man page says that the --synthetic option causes nm to: Include synthetic symbols in the output. These are special symbols created by the linker for various purposes. So it seems safe to always pass --synthetic if nm supports it, ie. on 32-bit and 64-bit, it just means 32-bit kernels might have more symbols reported (and in practice I see no extra symbols). Making it unconditional avoids the #ifdef CONFIG_PPC64, which in turn avoids the infinite loop. Debugged-by: Peter Collingbourne Signed-off-by: Michael Ellerman Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/powerpc/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index c345b79414a96..403f7e193833a 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -39,13 +39,11 @@ endif uname := $(shell uname -m) KBUILD_DEFCONFIG := $(if $(filter ppc%,$(uname)),$(uname),ppc64)_defconfig -ifdef CONFIG_PPC64 new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' > /dev/null; then echo y; else echo n; fi) ifeq ($(new_nm),y) NM := $(NM) --synthetic endif -endif # BITS is used as extension for files which are available in a 32 bit # and a 64 bit version to simplify shared Makefiles. -- 2.20.1
Re: "Pick the right alignment default when creating dax devices" failed to build on powerpc
On 21 September 2019 4:31:16 am AEST, Dan Williams wrote: >On Fri, Sep 20, 2019 at 11:18 AM Qian Cai wrote: >> >> On Fri, 2019-09-20 at 19:55 +0530, Aneesh Kumar K.V wrote: >> > Qian Cai writes: >> > >> > > The linux-next commit "libnvdimm/dax: Pick the right alignment >default when >> > > creating dax devices" causes powerpc failed to build with this >config. Reverted >> > > it fixed the issue. >> > > >> > > ERROR: "hash__has_transparent_hugepage" >[drivers/nvdimm/libnvdimm.ko] undefined! >> > > ERROR: "radix__has_transparent_hugepage" >[drivers/nvdimm/libnvdimm.ko] >> > > undefined! >> > > make[1]: *** [scripts/Makefile.modpost:93: __modpost] Error 1 >> > > make: *** [Makefile:1305: modules] Error 2 >> > > >> > > [1] https://patchwork.kernel.org/patch/11133445/ >> > > [2] >https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config >> > >> > Sorry for breaking the build. How about? >> >> It works fine. > >Thanks, but let's delay "libnvdimm/dax: Pick the right alignment >default when creating dax devices" until after -rc1 to allow Michael >time to ack/nak this new export. Thanks Dan. It looks fine to me: Acked-by: Michael Ellerman cheers -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
