* [PATCH v2 10/29] sh: add statx system call
From: Arnd Bergmann @ 2019-01-18 16:18 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel, linux-arch
Cc: dalias, linux-ia64, linux-sh, catalin.marinas, will.deacon,
jcmvbkbc, deepa.kernel, hpa, sparclinux, linux-s390, deller, x86,
linux, mingo, geert, firoz.khan, mattst88, fenghua.yu,
Arnd Bergmann, heiko.carstens, linux-fsdevel, linux-m68k, luto,
tglx, linux-arm-kernel, monstr, tony.luck, linux-parisc, netdev,
linux-mips, paul.burton, ebiederm, linux-alpha, schwidefsky, akpm,
linuxppc-dev, davem
In-Reply-To: <20190118161835.2259170-1-arnd@arndb.de>
statx is available on almost all other architectures but
got missed on sh, so add it now.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/sh/kernel/syscalls/syscall.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sh/kernel/syscalls/syscall.tbl b/arch/sh/kernel/syscalls/syscall.tbl
index 21ec75288562..a70db013dbc7 100644
--- a/arch/sh/kernel/syscalls/syscall.tbl
+++ b/arch/sh/kernel/syscalls/syscall.tbl
@@ -390,3 +390,4 @@
380 common copy_file_range sys_copy_file_range
381 common preadv2 sys_preadv2
382 common pwritev2 sys_pwritev2
+383 common statx sys_statx
--
2.20.0
^ permalink raw reply related
* [PATCH v2 02/29] ia64: add statx and io_pgetevents syscalls
From: Arnd Bergmann @ 2019-01-18 16:18 UTC (permalink / raw)
To: y2038, linux-api, linux-kernel, linux-arch
Cc: dalias, linux-ia64, linux-sh, catalin.marinas, will.deacon,
jcmvbkbc, deepa.kernel, hpa, sparclinux, linux-s390, deller, x86,
linux, mingo, geert, firoz.khan, mattst88, fenghua.yu,
Arnd Bergmann, heiko.carstens, linux-fsdevel, linux-m68k, luto,
tglx, linux-arm-kernel, monstr, tony.luck, linux-parisc, netdev,
linux-mips, paul.burton, ebiederm, linux-alpha, schwidefsky, akpm,
linuxppc-dev, davem
In-Reply-To: <20190118161835.2259170-1-arnd@arndb.de>
All architectures should implement these two, so assign numbers
and hook them up on ia64.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/ia64/kernel/syscalls/syscall.tbl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl
index e97caf51be42..52585281205b 100644
--- a/arch/ia64/kernel/syscalls/syscall.tbl
+++ b/arch/ia64/kernel/syscalls/syscall.tbl
@@ -335,3 +335,5 @@
323 common copy_file_range sys_copy_file_range
324 common preadv2 sys_preadv2
325 common pwritev2 sys_pwritev2
+326 common statx sys_statx
+327 common io_pgetevents sys_io_pgetevents
--
2.20.0
^ permalink raw reply related
* Re: use generic DMA mapping code in powerpc V4
From: Christian Zigotzky @ 2019-01-18 15:06 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev
In-Reply-To: <20190118125500.GA15657@lst.de>
Hello Christoph,
I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your
Git powerpc-dma.6-debug today.
Unfortunately I don't see any error messages (kernel ring buffer) and I
don't have a RS232 serial null modem cable to get them.
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH] powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM
From: Sasha Levin @ 2019-01-18 14:51 UTC (permalink / raw)
To: Breno Leitao; +Cc: mikey, linuxppc-dev, stable, gregkh
In-Reply-To: <bc20e375-09a0-1672-f61c-f90375c31a61@debian.org>
On Thu, Jan 17, 2019 at 09:49:05AM -0200, Breno Leitao wrote:
>hi Sasha,
>
>On 1/16/19 11:35 AM, Sasha Levin wrote:
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a "Fixes:" tag,
>> fixing commit: e1c3743e1a20 powerpc/tm: Set MSR[TS] just prior to recheckpoint.
>>
>> The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93, v4.9.150.
>>
>> v4.20.2: Failed to apply! Possible dependencies:
>> Unable to calculate
>>
>> v4.19.15: Failed to apply! Possible dependencies:
>> Unable to calculate
>>
>> v4.14.93: Failed to apply! Possible dependencies:
>> 0d60619e1c0c ("powerpc: Add missing prototype for sys_debug_setcontext()")
>> 67b464a89c21 ("powerpc/32: Mark both tmp variables as unused")
>> 6f5b9f018f4c ("powerpc/tm: Unset MSR[TS] if not recheckpointing")
>> b53875c4b4f2 ("powerpc: Add missing prototypes for sys_sigreturn() & sys_rt_sigreturn()")
>> bf7fb32dd5fc ("powerpc: Add missing prototypes for ppc_select() & ppc_fadvise64_64()")
>> f3675644e172 ("powerpc/syscalls: signal_{32, 64} - switch to SYSCALL_DEFINE")
>>
>> v4.9.150: Failed to apply! Possible dependencies:
>> 0d60619e1c0c ("powerpc: Add missing prototype for sys_debug_setcontext()")
>> 67b464a89c21 ("powerpc/32: Mark both tmp variables as unused")
>> 6f5b9f018f4c ("powerpc/tm: Unset MSR[TS] if not recheckpointing")
>> b53875c4b4f2 ("powerpc: Add missing prototypes for sys_sigreturn() & sys_rt_sigreturn()")
>> bf7fb32dd5fc ("powerpc: Add missing prototypes for ppc_select() & ppc_fadvise64_64()")
>> f3675644e172 ("powerpc/syscalls: signal_{32, 64} - switch to SYSCALL_DEFINE")
>>
>>
>> How should we proceed with this patch?
>
>I understand that the commit that this patch fixes is not integrated into
>stable tree.
>
>I think it does not need to make stable at this moment, thus.
The commit it fixes (e1c3743e1a20) exists in all 4.9+ stable trees as it
itself was tagged for stable.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH] powerpc: chrp: Use of_node_is_type to access device_type
From: Rob Herring @ 2019-01-18 14:35 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Paul Mackerras, linux-kernel, kbuild test robot
Commit 8ce5f8415753 ("of: Remove struct device_node.type pointer")
removed struct device_node.type pointer, but the conversion to use
of_node_is_type() accessor was missed in chrp_init_IRQ().
Fixes: 8ce5f8415753 ("of: Remove struct device_node.type pointer")
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
Michael, I see you just sent a PR of fixes. I can send this to Linus if
you prefer.
arch/powerpc/platforms/chrp/setup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
index e66644e0fb40..9438fa0fc355 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -538,8 +538,7 @@ static void __init chrp_init_IRQ(void)
/* see if there is a keyboard in the device tree
with a parent of type "adb" */
for_each_node_by_name(kbd, "keyboard")
- if (kbd->parent && kbd->parent->type
- && strcmp(kbd->parent->type, "adb") == 0)
+ if (of_node_is_type(kbd->parent, "adb"))
break;
of_node_put(kbd);
if (kbd)
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers
From: Viorel Suman @ 2019-01-18 13:16 UTC (permalink / raw)
To: robh@kernel.org, nicoleotsuka@gmail.com
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, lgirdwood@gmail.com, S.j. Wang,
linux-kernel@vger.kernel.org, Daniel Baluta, tiwai@suse.com,
viorel.suman@gmail.com, Fabio Estevam, broonie@kernel.org,
dl-linux-imx, Cosmin Samoila, perex@perex.cz,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190117161804.GA5760@bogus>
Hi Rob, Nicolin, All,
On Jo, 2019-01-17 at 10:18 -0600, Rob Herring wrote:
> On Thu, Jan 17, 2019 at 12:46:25PM +0000, Viorel Suman wrote:
> >
> > The patchset adds NXP Audio Mixer (AUDMIX) device and machine
> > drivers and related DT bindings documentation.
> >
> > Changes since V2:
> > 1. Moved "dais" node from machine driver DTS node to device driver
> > DTS node
> > as suggested by Rob.
> That was not what I suggested. You still have a virtual node which
> looks to me to be unnecessary.
To me removing virtual node implies that AUDMIX machine driver (imx-
audmix.c + virtual node) shall be removed and machine driver code
merged into device driver (fsl_audmix.c + device node) - please let me
know if my understanding is wrong.
The implication is that this makes AUDMIX device driver bounded to a
particular DAI type of interface - SAI. The original intention is to
keep AUDMIX device driver DAI-agnostic.
Indeed, currently the connection between AUDMIX and SAI IP blocks in
i.MX8QM and i.MX8QXP is fixed inside the SoC, but on other platforms we
may expect AUDMIX to be connected inside the SoC to other IP blocks -
to ESAI interface for instance.
At this moment it's a bit difficult for me to evaluate how critical is
to keep the device driver DAI-agnostic, so if you think it's better to
go now with a SAI bounded AUDMIX device driver - please confirm, I'll
merge machine driver code into device driver.
Thank you,
Viorel
>
> >
> >
> > Changes since V1:
> > 1. Original patch split into distinct patches for the device driver
> > and
> > DT binding documentation.
> > 2. Replaced AMIX with AUDMIX in both code and file names as it
> > looks more
> > RM-compliant.
> > 3. Removed polarity control from CPU DAI driver as suggested by
> > Nicolin.
> > 4. Added machine driver and related DT binding documentation.
> >
> > Viorel Suman (4):
> > ASoC: fsl: Add Audio Mixer CPU DAI driver
> > ASoC: add fsl_audmix DT binding documentation
> > ASoC: fsl: Add Audio Mixer machine driver
> > ASoC: add imx-audmix DT binding documentation
> >
> > .../devicetree/bindings/sound/fsl,audmix.txt | 50 ++
> > .../devicetree/bindings/sound/imx-audmix.txt | 18 +
> > sound/soc/fsl/Kconfig | 16 +
> > sound/soc/fsl/Makefile | 5 +
> > sound/soc/fsl/fsl_audmix.c | 551
> > +++++++++++++++++++++
> > sound/soc/fsl/fsl_audmix.h | 102 ++++
> > sound/soc/fsl/imx-audmix.c | 334
> > +++++++++++++
> > 7 files changed, 1076 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/sound/fsl,audmix.txt
> > create mode 100644 Documentation/devicetree/bindings/sound/imx-
> > audmix.txt
> > create mode 100644 sound/soc/fsl/fsl_audmix.c
> > create mode 100644 sound/soc/fsl/fsl_audmix.h
> > create mode 100644 sound/soc/fsl/imx-audmix.c
> >
^ permalink raw reply
* Re: use generic DMA mapping code in powerpc V4
From: Christoph Hellwig @ 2019-01-18 12:55 UTC (permalink / raw)
To: Christian Zigotzky
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <eceebeda-0e18-00f6-06e7-def2eb0aa961@xenosoft.de>
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
On Fri, Jan 18, 2019 at 01:46:46PM +0100, Christian Zigotzky wrote:
> Sorry, it's not possible to patch
> '257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried it
> manually but without any success.
Weird:
hch@carbon:~/work/linux$ git checkout 257002094bc5935dd63207a380d9698ab81f0775
HEAD is now at 257002094bc5 powerpc/dma: use the dma-direct allocator for coherent platforms
hch@carbon:~/work/linux$ patch -p1 < dbg.diff
patching file kernel/dma/direct.c
I've pushed the result to
git://git.infradead.org/users/hch/misc.git
as a new powerpc-dma.6-debug branch
[-- Attachment #2: dbg.diff --]
[-- Type: text/x-patch, Size: 746 bytes --]
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
page = NULL;
}
}
- if (!page)
+ if (!page) {
page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
+ if (!page)
+ pr_warn("failed to allocate memory with gfp 0x%x\n", gfp);
+ }
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
__free_pages(page, page_order);
@@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
}
}
+ if (!page) {
+ pr_warn("failed to allocate DMA memory!\n");
+ dump_stack();
+ }
return page;
}
^ permalink raw reply related
* Re: use generic DMA mapping code in powerpc V4
From: Christian Zigotzky @ 2019-01-18 12:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev
In-Reply-To: <20190118121810.GA13327@lst.de>
Sorry, it's not possible to patch
'257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried
it manually but without any success.
-- Christian
On 18 January 2019 at 1:18PM, Christoph Hellwig wrote:
> On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout 257002094bc5935dd63207a380d9698ab81f0775
>>
>>
>> I get the following error message with your patch:
> Hmm. Did I attached the wrong patch? Here is the one I want and just
> applied to that revision:
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 355d16acee6d..e46c9b64ec0d 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> page = NULL;
> }
> }
> - if (!page)
> + if (!page) {
> page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
> + if (!page)
> + pr_warn("failed to allocate memory with gfp 0x%x\n", gfp);
> + }
>
> if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> __free_pages(page, page_order);
> @@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> }
> }
>
> + if (!page) {
> + pr_warn("failed to allocate DMA memory!\n");
> + dump_stack();
> + }
> return page;
> }
>
>
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.0-3 tag
From: Michael Ellerman @ 2019-01-18 12:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jason, maddy, linux-kernel, Arnaldo Carvalho de Melo, leitao,
fbarrat, linuxppc-dev, dan.carpenter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Linus,
Please pull some more powerpc fixes for 5.0:
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.0-3
for you to fetch changes up to 7bea7ac0ca0121798f3618d16201ca4dc4e67a00:
powerpc/syscalls: Fix syscall tracing (2019-01-15 21:32:25 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.0 #3
A couple of weeks of fixes.
There's one fix for an oops on Power9 machines with Open CAPI adapters.
And a fix for probable memory corruption in some of the new NPU code, caught by
smatch though and not seen in the wild.
Plus a few other minor fixes.
There's one non-fix which is the perf_regs change. That was sent during the
merge window but I accidentally only merged the first of two patches in the
series. It's been in linux-next so hopefully doesn't conflict with anything in
acme's tree.
Thanks to:
Alexey Kardashevskiy, Andrew Donnellan, Breno Leitao, Christian Lamparter,
Christophe Leroy, Dan Carpenter, Frederic Barrat, Greg Kurz, Jason A.
Donenfeld, Madhavan Srinivasan.
- ------------------------------------------------------------------
Breno Leitao (1):
powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM
Christophe Leroy (1):
powerpc/8xx: fix setting of pagetable for Abatron BDI debug tool.
Dan Carpenter (1):
powerpc/powernv/npu: Allocate enough memory in pnv_try_setup_npu_table_group()
Frederic Barrat (1):
powerpc/powernv/npu: Fix oops in pnv_try_setup_npu_table_group()
Jason A. Donenfeld (1):
powerpc/pseries: Fix build break due to pnv_npu2_init()
Madhavan Srinivasan (1):
powerpc/perf: Update perf_regs structure to include MMCRA
Michael Ellerman (2):
powerpc/4xx/ocm: Fix fix for phys_addr_t printf warnings
powerpc/syscalls: Fix syscall tracing
arch/powerpc/include/uapi/asm/perf_regs.h | 1 +
arch/powerpc/kernel/head_8xx.S | 3 ++-
arch/powerpc/kernel/signal_64.c | 7 ++++---
arch/powerpc/kernel/trace/ftrace.c | 7 -------
arch/powerpc/perf/perf_regs.c | 6 ++++++
arch/powerpc/platforms/4xx/ocm.c | 6 +++---
arch/powerpc/platforms/powernv/npu-dma.c | 2 +-
arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
arch/powerpc/platforms/pseries/pci.c | 2 ++
tools/arch/powerpc/include/uapi/asm/perf_regs.h | 1 +
tools/perf/arch/powerpc/include/perf_regs.h | 3 ++-
tools/perf/arch/powerpc/util/perf_regs.c | 1 +
12 files changed, 25 insertions(+), 17 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJcQcoIAAoJEFHr6jzI4aWA4SkP/ibxCnRlUIJUmMZSD7qeQan9
iV8Duht2BXjUrTrhU2F8PQ20SeKi9Bp5mMUJ96fh0bOeuc+VK375x4bqKyXb1buP
L/zMEDQFWtKOYRE/8wMsA3xdD7x69z/E7gpzEJMEX9SpWALTRBrMiSI3adqLM4vI
ri17SPIJxvJQ85qGOymBWWgN7FSjIXtOm8Dlp2aSJ3rTi6AirQQXIdbZtl9fMtgv
cu7mmF7Vs6BvyThUSPUvCSY6ilWVOcwNV/Zg9KVwMpCHh07U9cbWNv6bp0sa64j0
yavmIYZeRflTEJ7NI6EzBMCws0nNBytWfxWkSeSobQT2Rnpx3ColMMAy035E+EGU
NVxrbrV9J4PtDo87RWUNGLSodUNgcg6rW/Zhvlt5PpSh4WOQopOYKmWS1tYqLP9S
o1EEkZ/vrAkM0syPBrdgMEV2Qzz5xuE7LOZPZNCeQyfUUGeUgLuc77i1BVjcBQ/4
/5PmkHdMw3iG65UJ1IGT4GLHiHmjWyZqrdCw0/bpHaIlNaC5/Jx3ZenJdVbTiEhv
h5c3+cWZPk6ILfvFqzrUuRJVM3Z3Ta4+uHA9yruQZZOgfkx8CADDxsSwSMhYqa6R
R7zVVoQO6JdwRlrwPe35IzppAiWjVrUJMOqbbGBp2/YcpEpUw2tMJDeFhSglrYQL
YFZw+ENrBcoqwduu0xDI
=BgXi
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/64s: Add slb_full_bitmap rather than hard-coding U32_MAX
From: Michael Ellerman @ 2019-01-18 12:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, npiggin
In-Reply-To: <20190117163017.GS14180@gate.crashing.org>
Segher Boessenkool <segher@kernel.crashing.org> writes:
> On Thu, Jan 17, 2019 at 11:13:26PM +1100, Michael Ellerman wrote:
>> The recent rewrite of the SLB code into C included the assumption that
>> all CPUs we run on have at least 32 SLB entries. This is currently
>> true but a bit fragile as the SLB size is actually defined by the
>> device tree and so could theoretically change at any time.
>
> It also is guaranteed by the architecture, since at least 2.02, FWIW.
True. Actually 2.00 says at least 32.
Unfortunately we don't live in a world where "the architecture
guarantees it" has any bearing on reality :)
But given it *should* always be at least 32 maybe I should optimise for
that case. We could use a static key to skip the U32_MAX comparison and
go down the else path.
cheers
^ permalink raw reply
* Re: use generic DMA mapping code in powerpc V4
From: Christoph Hellwig @ 2019-01-18 12:18 UTC (permalink / raw)
To: Christian Zigotzky
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <a2ca0118-5915-8b1c-7cfa-71cb4b43eaa6@xenosoft.de>
On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 257002094bc5935dd63207a380d9698ab81f0775
>
>
> I get the following error message with your patch:
Hmm. Did I attached the wrong patch? Here is the one I want and just
applied to that revision:
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
page = NULL;
}
}
- if (!page)
+ if (!page) {
page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
+ if (!page)
+ pr_warn("failed to allocate memory with gfp 0x%x\n", gfp);
+ }
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
__free_pages(page, page_order);
@@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
}
}
+ if (!page) {
+ pr_warn("failed to allocate DMA memory!\n");
+ dump_stack();
+ }
return page;
}
^ permalink raw reply related
* Re: use generic DMA mapping code in powerpc V4
From: Christian Zigotzky @ 2019-01-18 12:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev
In-Reply-To: <20190118112842.GA9115@lst.de>
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 257002094bc5935dd63207a380d9698ab81f0775
I get the following error message with your patch:
patching file a/kernel/dma/direct.c
Hunk #1 FAILED at 118.
Hunk #2 FAILED at 139.
2 out of 2 hunks FAILED -- saving rejects to file a/kernel/dma/direct.c.rej
-- Christian
On 18 January 2019 at 12:28PM, Christoph Hellwig wrote:
> On Fri, Jan 18, 2019 at 12:10:26PM +0100, Christian Zigotzky wrote:
>> For which commit?
> On top of 257002094bc5935dd63207a380d9698ab81f0775, that is the first
> one you identified as breaking the detection of the SATA disks.
>
^ permalink raw reply
* [PATCH 2/3] dma-mapping: don't BUG when calling dma_map_resource on RAM
From: Christoph Hellwig @ 2019-01-18 11:37 UTC (permalink / raw)
To: Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Niklas Söderlund
Cc: Robin Murphy, Russell King, linux-kernel, iommu,
Mauro Carvalho Chehab, linuxppc-dev, linux-arm-kernel,
linux-media
In-Reply-To: <20190118113727.3270-1-hch@lst.de>
Use WARN_ON_ONCE to print a stack trace and return a proper error
code instead.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
include/linux/dma-mapping.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 9842085e6774..b904d55247ab 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -353,7 +353,8 @@ static inline dma_addr_t dma_map_resource(struct device *dev,
BUG_ON(!valid_dma_direction(dir));
/* Don't allow RAM to be mapped */
- BUG_ON(pfn_valid(PHYS_PFN(phys_addr)));
+ if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr))))
+ return DMA_MAPPING_ERROR;
if (dma_is_direct(ops))
addr = dma_direct_map_resource(dev, phys_addr, size, dir, attrs);
--
2.20.1
^ permalink raw reply related
* [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource
From: Christoph Hellwig @ 2019-01-18 11:37 UTC (permalink / raw)
To: Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Niklas Söderlund
Cc: Russell King, linux-kernel, iommu, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, linuxppc-dev, linux-arm-kernel,
linux-media
In-Reply-To: <20190118113727.3270-1-hch@lst.de>
vb2_dc_get_userptr pokes into arm direct mapping details to get the
resemblance of a dma address for a a physical address that does is
not backed by a page struct. Not only is this not portable to other
architectures with dma direct mapping offsets, but also not to uses
of IOMMUs of any kind. Switch to the proper dma_map_resource /
dma_unmap_resource interface instead.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
.../common/videobuf2/videobuf2-dma-contig.c | 41 ++++---------------
1 file changed, 9 insertions(+), 32 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index aff0ab7bf83d..82389aead6ed 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -439,42 +439,14 @@ static void vb2_dc_put_userptr(void *buf_priv)
set_page_dirty_lock(pages[i]);
sg_free_table(sgt);
kfree(sgt);
+ } else {
+ dma_unmap_resource(buf->dev, buf->dma_addr, buf->size,
+ buf->dma_dir, 0);
}
vb2_destroy_framevec(buf->vec);
kfree(buf);
}
-/*
- * For some kind of reserved memory there might be no struct page available,
- * so all that can be done to support such 'pages' is to try to convert
- * pfn to dma address or at the last resort just assume that
- * dma address == physical address (like it has been assumed in earlier version
- * of videobuf2-dma-contig
- */
-
-#ifdef __arch_pfn_to_dma
-static inline dma_addr_t vb2_dc_pfn_to_dma(struct device *dev, unsigned long pfn)
-{
- return (dma_addr_t)__arch_pfn_to_dma(dev, pfn);
-}
-#elif defined(__pfn_to_bus)
-static inline dma_addr_t vb2_dc_pfn_to_dma(struct device *dev, unsigned long pfn)
-{
- return (dma_addr_t)__pfn_to_bus(pfn);
-}
-#elif defined(__pfn_to_phys)
-static inline dma_addr_t vb2_dc_pfn_to_dma(struct device *dev, unsigned long pfn)
-{
- return (dma_addr_t)__pfn_to_phys(pfn);
-}
-#else
-static inline dma_addr_t vb2_dc_pfn_to_dma(struct device *dev, unsigned long pfn)
-{
- /* really, we cannot do anything better at this point */
- return (dma_addr_t)(pfn) << PAGE_SHIFT;
-}
-#endif
-
static void *vb2_dc_get_userptr(struct device *dev, unsigned long vaddr,
unsigned long size, enum dma_data_direction dma_dir)
{
@@ -528,7 +500,12 @@ static void *vb2_dc_get_userptr(struct device *dev, unsigned long vaddr,
for (i = 1; i < n_pages; i++)
if (nums[i-1] + 1 != nums[i])
goto fail_pfnvec;
- buf->dma_addr = vb2_dc_pfn_to_dma(buf->dev, nums[0]);
+ buf->dma_addr = dma_map_resource(buf->dev,
+ __pfn_to_phys(nums[0]), size, buf->dma_dir, 0);
+ if (dma_mapping_error(buf->dev, buf->dma_addr)) {
+ ret = -ENOMEM;
+ goto fail_pfnvec;
+ }
goto out;
}
--
2.20.1
^ permalink raw reply related
* fix a layering violation in videobuf2 and improve dma_map_resource v2
From: Christoph Hellwig @ 2019-01-18 11:37 UTC (permalink / raw)
To: Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Niklas Söderlund
Cc: Russell King, linux-kernel, iommu, Mauro Carvalho Chehab,
linuxppc-dev, linux-arm-kernel, linux-media
Hi all,
this series fixes a rather gross layering violation in videobuf2, which
pokes into arm DMA mapping internals to get a DMA address for memory that
does not have a page structure, and to do so fixes up the dma_map_resource
implementation to not provide a somewhat dangerous default and improve
the error handling.
Changes since v1:
- don't apply bus offsets in dma_direct_map_resource
^ permalink raw reply
* [PATCH 1/3] dma-mapping: remove the default map_resource implementation
From: Christoph Hellwig @ 2019-01-18 11:37 UTC (permalink / raw)
To: Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Niklas Söderlund
Cc: Russell King, linux-kernel, iommu, Mauro Carvalho Chehab,
linuxppc-dev, linux-arm-kernel, linux-media
In-Reply-To: <20190118113727.3270-1-hch@lst.de>
Instead provide a proper implementation in the direct mapping code, and
also wire it up for arm and powerpc, leaving an error return for all the
IOMMU or virtual mapping instances for which we'd have to wire up an
actual implementation
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 2 ++
arch/powerpc/kernel/dma-swiotlb.c | 1 +
arch/powerpc/kernel/dma.c | 1 +
include/linux/dma-mapping.h | 12 +++++++-----
kernel/dma/direct.c | 14 ++++++++++++++
5 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f1e2922e447c..3c8534904209 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -188,6 +188,7 @@ const struct dma_map_ops arm_dma_ops = {
.unmap_page = arm_dma_unmap_page,
.map_sg = arm_dma_map_sg,
.unmap_sg = arm_dma_unmap_sg,
+ .map_resource = dma_direct_map_resource,
.sync_single_for_cpu = arm_dma_sync_single_for_cpu,
.sync_single_for_device = arm_dma_sync_single_for_device,
.sync_sg_for_cpu = arm_dma_sync_sg_for_cpu,
@@ -211,6 +212,7 @@ const struct dma_map_ops arm_coherent_dma_ops = {
.get_sgtable = arm_dma_get_sgtable,
.map_page = arm_coherent_dma_map_page,
.map_sg = arm_dma_map_sg,
+ .map_resource = dma_direct_map_resource,
.dma_supported = arm_dma_supported,
};
EXPORT_SYMBOL(arm_coherent_dma_ops);
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index 7d5fc9751622..fbb2506a414e 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -55,6 +55,7 @@ const struct dma_map_ops powerpc_swiotlb_dma_ops = {
.dma_supported = swiotlb_dma_supported,
.map_page = dma_direct_map_page,
.unmap_page = dma_direct_unmap_page,
+ .map_resource = dma_direct_map_resource,
.sync_single_for_cpu = dma_direct_sync_single_for_cpu,
.sync_single_for_device = dma_direct_sync_single_for_device,
.sync_sg_for_cpu = dma_direct_sync_sg_for_cpu,
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index b1903ebb2e9c..258b9e8ebb99 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -273,6 +273,7 @@ const struct dma_map_ops dma_nommu_ops = {
.dma_supported = dma_nommu_dma_supported,
.map_page = dma_nommu_map_page,
.unmap_page = dma_nommu_unmap_page,
+ .map_resource = dma_direct_map_resource,
.get_required_mask = dma_nommu_get_required_mask,
#ifdef CONFIG_NOT_COHERENT_CACHE
.sync_single_for_cpu = dma_nommu_sync_single,
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f6ded992c183..9842085e6774 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -208,6 +208,8 @@ dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
unsigned long attrs);
int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
enum dma_data_direction dir, unsigned long attrs);
+dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
defined(CONFIG_SWIOTLB)
@@ -346,19 +348,19 @@ static inline dma_addr_t dma_map_resource(struct device *dev,
unsigned long attrs)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
- dma_addr_t addr;
+ dma_addr_t addr = DMA_MAPPING_ERROR;
BUG_ON(!valid_dma_direction(dir));
/* Don't allow RAM to be mapped */
BUG_ON(pfn_valid(PHYS_PFN(phys_addr)));
- addr = phys_addr;
- if (ops && ops->map_resource)
+ if (dma_is_direct(ops))
+ addr = dma_direct_map_resource(dev, phys_addr, size, dir, attrs);
+ else if (ops->map_resource)
addr = ops->map_resource(dev, phys_addr, size, dir, attrs);
debug_dma_map_resource(dev, phys_addr, size, dir, addr);
-
return addr;
}
@@ -369,7 +371,7 @@ static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
const struct dma_map_ops *ops = get_dma_ops(dev);
BUG_ON(!valid_dma_direction(dir));
- if (ops && ops->unmap_resource)
+ if (!dma_is_direct(ops) && ops->unmap_resource)
ops->unmap_resource(dev, addr, size, dir, attrs);
debug_dma_unmap_resource(dev, addr, size, dir);
}
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..25bd19974223 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -356,6 +356,20 @@ int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
}
EXPORT_SYMBOL(dma_direct_map_sg);
+dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ dma_addr_t dma_addr = paddr;
+
+ if (unlikely(!dma_direct_possible(dev, dma_addr, size))) {
+ report_addr(dev, dma_addr, size);
+ return DMA_MAPPING_ERROR;
+ }
+
+ return dma_addr;
+}
+EXPORT_SYMBOL(dma_direct_map_resource);
+
/*
* Because 32-bit DMA masks are so common we expect every architecture to be
* able to satisfy them - either by not supporting more physical memory, or by
--
2.20.1
^ permalink raw reply related
* Re: use generic DMA mapping code in powerpc V4
From: Christoph Hellwig @ 2019-01-18 11:28 UTC (permalink / raw)
To: Christian Zigotzky
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <871403f2-fa7d-de15-89eb-070432e15c69@xenosoft.de>
On Fri, Jan 18, 2019 at 12:10:26PM +0100, Christian Zigotzky wrote:
> For which commit?
On top of 257002094bc5935dd63207a380d9698ab81f0775, that is the first
one you identified as breaking the detection of the SATA disks.
^ permalink raw reply
* Re: use generic DMA mapping code in powerpc V4
From: Christian Zigotzky @ 2019-01-18 11:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev
In-Reply-To: <20190118083539.GA30479@lst.de>
For which commit?
-- Christian
On 18 January 2019 at 09:35AM, Christoph Hellwig wrote:
> Hi Christian,
>
> can you check if the debug printks in this patch trigger?
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 355d16acee6d..e46c9b64ec0d 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> page = NULL;
> }
> }
> - if (!page)
> + if (!page) {
> page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
> + if (!page)
> + pr_warn("failed to allocate memory with gfp 0x%x\n", gfp);
> + }
>
> if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> __free_pages(page, page_order);
> @@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> }
> }
>
> + if (!page) {
> + pr_warn("failed to allocate DMA memory!\n");
> + dump_stack();
> + }
> return page;
> }
>
>
^ permalink raw reply
* Re: [PATCH] media: fsl-viu: Use proper check for presence of {out, in}_be32()
From: Geert Uytterhoeven @ 2019-01-18 10:45 UTC (permalink / raw)
To: Hans Verkuil
Cc: Arnd Bergmann, Linux Kernel Mailing List, Paul Mackerras,
Mauro Carvalho Chehab, linuxppc-dev, Linux Media Mailing List
In-Reply-To: <d30d5bcd-8719-ac59-adf5-08c9576be759@xs4all.nl>
Hi Hans,
On Fri, Jan 18, 2019 at 11:08 AM Hans Verkuil <hverkuil@xs4all.nl> wrote:
> This patch is still in my patchwork todo list, and I wonder who will pick this up,
> especially the change to arch/powerpc/include/asm/io.h.
I think the powerpc tree makes most sense.
> Wouldn't it be easier to just fix this in fsl-viu.c only by doing this:
>
> #ifndef CONFIG_PPC
> #ifndef out_be32
> #define out_be32(v, a) iowrite32be(a, (void __iomem *)v)
> #endif
> #ifndef in_be32
> #define in_be32(a) ioread32be((void __iomem *)a)
> #endif
> #endif
>
> Basically just your patch, but without removing #ifndef CONFIG_PPC.
>
> That way there is no need to touch arch/powerpc/include/asm/io.h.
While I agree that avoids touching the powerpc tree, it doesn't solve
the problem
in the long run.
All drivers using e.g. out_be32() would need an extra check for CONFIG_PPC
to enable compile-testing. The same is true when handling this in asm-generic.
> On 6/15/18 10:10 AM, Hans Verkuil wrote:
> > On 08/06/18 11:48, Geert Uytterhoeven wrote:
> >> When compile-testing on m68k or microblaze:
> >>
> >> drivers/media/platform/fsl-viu.c:41:1: warning: "out_be32" redefined
> >> drivers/media/platform/fsl-viu.c:42:1: warning: "in_be32" redefined
> >>
> >> Fix this by replacing the check for PowerPC by checks for the presence
> >> of {out,in}_be32().
> >>
> >> As PowerPC implements the be32 accessors using inline functions instead
> >> of macros, identity definions are added for all accessors to make the
> >> above checks work.
> >>
> >> Fixes: 29d750686331a1a9 ("media: fsl-viu: allow building it with COMPILE_TEST")
> >> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
> >
> > Should this go through the media tree or powerpc tree? Either way works for me.
> >
> > Regards,
> >
> > Hans
> >
> >> ---
> >> Compile-tested on m68k, microblaze, and powerpc.
> >> Assembler output before/after compared for powerpc.
> >> ---
> >> arch/powerpc/include/asm/io.h | 14 ++++++++++++++
> >> drivers/media/platform/fsl-viu.c | 4 +++-
> >> 2 files changed, 17 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> >> index e0331e7545685c5f..3741183ae09349f1 100644
> >> --- a/arch/powerpc/include/asm/io.h
> >> +++ b/arch/powerpc/include/asm/io.h
> >> @@ -222,6 +222,20 @@ static inline void out_be64(volatile u64 __iomem *addr, u64 val)
> >> #endif
> >> #endif /* __powerpc64__ */
> >>
> >> +#define in_be16 in_be16
> >> +#define in_be32 in_be32
> >> +#define in_be64 in_be64
> >> +#define in_le16 in_le16
> >> +#define in_le32 in_le32
> >> +#define in_le64 in_le64
> >> +
> >> +#define out_be16 out_be16
> >> +#define out_be32 out_be32
> >> +#define out_be64 out_be64
> >> +#define out_le16 out_le16
> >> +#define out_le32 out_le32
> >> +#define out_le64 out_le64
> >> +
> >> /*
> >> * Low level IO stream instructions are defined out of line for now
> >> */
> >> diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
> >> index e41510ce69a40815..5d5e030c9c980647 100644
> >> --- a/drivers/media/platform/fsl-viu.c
> >> +++ b/drivers/media/platform/fsl-viu.c
> >> @@ -37,8 +37,10 @@
> >> #define VIU_VERSION "0.5.1"
> >>
> >> /* Allow building this driver with COMPILE_TEST */
> >> -#ifndef CONFIG_PPC
> >> +#ifndef out_be32
> >> #define out_be32(v, a) iowrite32be(a, (void __iomem *)v)
> >> +#endif
> >> +#ifndef in_be32
> >> #define in_be32(a) ioread32be((void __iomem *)a)
> >> #endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] media: fsl-viu: Use proper check for presence of {out,in}_be32()
From: Hans Verkuil @ 2019-01-18 10:07 UTC (permalink / raw)
To: Geert Uytterhoeven, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Mauro Carvalho Chehab
Cc: linuxppc-dev, linux-kernel, Arnd Bergmann, linux-media
In-Reply-To: <5948eb0d-410d-5bc6-a0f3-ffcaa4b3f975@xs4all.nl>
Hi Geert,
This patch is still in my patchwork todo list, and I wonder who will pick this up,
especially the change to arch/powerpc/include/asm/io.h.
Wouldn't it be easier to just fix this in fsl-viu.c only by doing this:
#ifndef CONFIG_PPC
#ifndef out_be32
#define out_be32(v, a) iowrite32be(a, (void __iomem *)v)
#endif
#ifndef in_be32
#define in_be32(a) ioread32be((void __iomem *)a)
#endif
#endif
Basically just your patch, but without removing #ifndef CONFIG_PPC.
That way there is no need to touch arch/powerpc/include/asm/io.h.
Regards,
Hans
On 6/15/18 10:10 AM, Hans Verkuil wrote:
> On 08/06/18 11:48, Geert Uytterhoeven wrote:
>> When compile-testing on m68k or microblaze:
>>
>> drivers/media/platform/fsl-viu.c:41:1: warning: "out_be32" redefined
>> drivers/media/platform/fsl-viu.c:42:1: warning: "in_be32" redefined
>>
>> Fix this by replacing the check for PowerPC by checks for the presence
>> of {out,in}_be32().
>>
>> As PowerPC implements the be32 accessors using inline functions instead
>> of macros, identity definions are added for all accessors to make the
>> above checks work.
>>
>> Fixes: 29d750686331a1a9 ("media: fsl-viu: allow building it with COMPILE_TEST")
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
>
> Should this go through the media tree or powerpc tree? Either way works for me.
>
> Regards,
>
> Hans
>
>> ---
>> Compile-tested on m68k, microblaze, and powerpc.
>> Assembler output before/after compared for powerpc.
>> ---
>> arch/powerpc/include/asm/io.h | 14 ++++++++++++++
>> drivers/media/platform/fsl-viu.c | 4 +++-
>> 2 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
>> index e0331e7545685c5f..3741183ae09349f1 100644
>> --- a/arch/powerpc/include/asm/io.h
>> +++ b/arch/powerpc/include/asm/io.h
>> @@ -222,6 +222,20 @@ static inline void out_be64(volatile u64 __iomem *addr, u64 val)
>> #endif
>> #endif /* __powerpc64__ */
>>
>> +#define in_be16 in_be16
>> +#define in_be32 in_be32
>> +#define in_be64 in_be64
>> +#define in_le16 in_le16
>> +#define in_le32 in_le32
>> +#define in_le64 in_le64
>> +
>> +#define out_be16 out_be16
>> +#define out_be32 out_be32
>> +#define out_be64 out_be64
>> +#define out_le16 out_le16
>> +#define out_le32 out_le32
>> +#define out_le64 out_le64
>> +
>> /*
>> * Low level IO stream instructions are defined out of line for now
>> */
>> diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
>> index e41510ce69a40815..5d5e030c9c980647 100644
>> --- a/drivers/media/platform/fsl-viu.c
>> +++ b/drivers/media/platform/fsl-viu.c
>> @@ -37,8 +37,10 @@
>> #define VIU_VERSION "0.5.1"
>>
>> /* Allow building this driver with COMPILE_TEST */
>> -#ifndef CONFIG_PPC
>> +#ifndef out_be32
>> #define out_be32(v, a) iowrite32be(a, (void __iomem *)v)
>> +#endif
>> +#ifndef in_be32
>> #define in_be32(a) ioread32be((void __iomem *)a)
>> #endif
>>
>>
>
>
^ permalink raw reply
* Re: G5 Quad hangs early on 4.20.2 / 5.0-rc2+
From: Mathieu Malaterre @ 2019-01-18 10:09 UTC (permalink / raw)
To: Tobias Ulmer; +Cc: Rob Herring, linuxppc-dev
In-Reply-To: <20190118005124.oktx5nebsyy47zbg@atom2.tmux.org>
On Fri, Jan 18, 2019 at 1:53 AM Tobias Ulmer <tobiasu@tmux.org> wrote:
>
> On Fri, Jan 18, 2019 at 09:32:07AM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2019-01-17 at 10:42 +0100, Tobias Ulmer wrote:
> > > On Wed, Jan 16, 2019 at 12:15:14PM +1100, Benjamin Herrenschmidt wrote:
> > > > On Tue, 2019-01-15 at 23:49 +0100, Tobias Ulmer wrote:
> > > > > Hi,
> > > > >
> > > > > both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
> > > > >
> > > > > Surely I'm not the first to run into this, but I couldn't find any
> > > > > discussion or bug report. Sorry if you're already aware.
> > > > >
> > > > > You can see it hang here (5.0 rc2+, 4.20.2 is nearly identical) until
> > > > > the watchdog triggers a reboot:
> > > > >
> > > > > https://i.imgur.com/UiCVRuG.jpg
> > > > >
> ...
> > I'll be back on monday or tuesday, let me know where you got up to then
> > and I'll take it from there. Also email me your .config please.
>
>
> Hi,
>
> this was caused by 5c63e407aaabb0464236cfc6279a2d79aede7073
> (fbdev: Convert to using %pOFn instead of device_node.name)
See:
https://patchwork.kernel.org/patch/10750931/
> name can't be NULL into offb_init_fb, there's a printk and the call to
> offb_init_palette_hacks where name is matched against OF device names.
>
> With the partial revert below, both 5.0-rc2+ and 4.20 are happy.
>
> diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
> index 31f769d67195..77c0a2f45b3b 100644
> --- a/drivers/video/fbdev/offb.c
> +++ b/drivers/video/fbdev/offb.c
> @@ -419,13 +419,9 @@ static void __init offb_init_fb(const char *name,
> var = &info->var;
> info->par = par;
>
> - if (name) {
> - strcpy(fix->id, "OFfb ");
> - strncat(fix->id, name, sizeof(fix->id) - sizeof("OFfb "));
> - fix->id[sizeof(fix->id) - 1] = '\0';
> - } else
> - snprintf(fix->id, sizeof(fix->id), "OFfb %pOFn", dp);
> -
> + strcpy(fix->id, "OFfb ");
> + strncat(fix->id, name, sizeof(fix->id) - sizeof("OFfb "));
> + fix->id[sizeof(fix->id) - 1] = '\0';
>
> var->xres = var->xres_virtual = width;
> var->yres = var->yres_virtual = height;
> @@ -648,7 +644,7 @@ static void __init offb_init_nodriver(struct device_node *dp, int no_real_node)
> /* kludge for valkyrie */
> if (strcmp(dp->name, "valkyrie") == 0)
> address += 0x1000;
> - offb_init_fb(no_real_node ? "bootx" : NULL,
> + offb_init_fb(no_real_node ? "bootx" : dp->name,
> width, height, depth, pitch, address,
> foreign_endian, no_real_node ? NULL : dp);
> }
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Remove duplicate header
From: Souptick Joarder @ 2019-01-18 10:04 UTC (permalink / raw)
To: Sabyasachi Gupta
Cc: Brajeswar Ghosh, linux-kernel, npiggin, paulus, oohall, msuchanek,
linuxppc-dev, haren
In-Reply-To: <5c40a8fd.1c69fb81.e4b1b.8f85@mx.google.com>
On Thu, Jan 17, 2019 at 9:40 PM Sabyasachi Gupta
<sabyasachi.linux@gmail.com> wrote:
>
> Remove linux/printk.h which is included more than once.
>
> Signed-off-by: Sabyasachi Gupta <sabyasachi.linux@gmail.com>
Acked-by: Souptick Joarder <jrdr.linux@gmail.com>
> ---
> arch/powerpc/platforms/powernv/opal.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
> index beed86f..802de0d 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -26,7 +26,6 @@
> #include <linux/memblock.h>
> #include <linux/kthread.h>
> #include <linux/freezer.h>
> -#include <linux/printk.h>
> #include <linux/kmsg_dump.h>
> #include <linux/console.h>
> #include <linux/sched/debug.h>
> --
> 2.7.4
>
^ permalink raw reply
* Re: G5 Quad hangs early on 4.20.2 / 5.0-rc2+
From: Tobias Ulmer @ 2019-01-18 9:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20190118022241.GA21381@blackberry>
On Fri, Jan 18, 2019 at 01:22:41PM +1100, Paul Mackerras wrote:
> On Tue, Jan 15, 2019 at 11:49:45PM +0100, Tobias Ulmer wrote:
> > Hi,
> >
> > both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
>
> Interesting, I just built v4.20 with g5_defconfig for my quad and it
> booted just fine. I'll try Linus' latest.
>
> It could be config-related; could you send me your .config (off-list)?
>
> Paul.
dmesg: http://ix.io/1yAB
config: http://ix.io/1yAC
Have fun :)
^ permalink raw reply
* Re: [PATCH 3/3] videobuf2: replace a layering violation with dma_map_resource
From: Marek Szyprowski @ 2019-01-18 9:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Niklas Söderlund, Pawel Osciak, linux-kernel, Kyungmin Park,
Russell King, iommu, Mauro Carvalho Chehab, linuxppc-dev,
linux-arm-kernel, linux-media
In-Reply-To: <20190117172152.GA32292@lst.de>
Hi Christoph,
On 2019-01-17 18:21, Christoph Hellwig wrote:
> On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote:
>> On 2019-01-11 19:17, Christoph Hellwig wrote:
>>> vb2_dc_get_userptr pokes into arm direct mapping details to get the
>>> resemblance of a dma address for a a physical address that does is
>>> not backed by a page struct. Not only is this not portable to other
>>> architectures with dma direct mapping offsets, but also not to uses
>>> of IOMMUs of any kind. Switch to the proper dma_map_resource /
>>> dma_unmap_resource interface instead.
>>>
>>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> There are checks for IOMMU presence in other places in vb2-dma-contig,
>> so it was used only when no IOMMU is available, but I agree that the
>> hacky code should be replaced by a generic code if possible.
>>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> V4L2 pipeline works fine on older Exynos-based boards with CMA and IOMMU
>> disabled.
> Do you know if these rely on the offsets? E.g. would they still work
> with the patch below applied on top. That would keep the map_resource
> semantics as-is as solve the issue pointed out by Robin for now.
AFAIK that code was only used for sharing buffers between hardware
modules that are a part of the same SoC, usually implemented as platform
devices. AFAIR this never worked for devices on different buses. So far
I wasn't aware on ANY which would require an offset for the DMA access.
The first version of videobuf2-dc code even incorrectly used paddr
instead of dma_addr as a buffer 'address' returned to the client
drivers, because in case of those SoC this was exactly the same (see
commits 472af2b05bdefcaee7e754e22cbf131110017ad6 and
ba7fcb0c954921534707f08ebc4d8beeb2eb17e7).
> If not I can only think of a flag to bypass the offseting for now, but
> that would be pretty ugly. Or go for the long-term solution of
> discovering the relationship between the two devices, as done by the
> PCIe P2P code..
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 8e0359b04957..25bd19974223 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -359,7 +359,7 @@ EXPORT_SYMBOL(dma_direct_map_sg);
> dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
> size_t size, enum dma_data_direction dir, unsigned long attrs)
> {
> - dma_addr_t dma_addr = phys_to_dma(dev, paddr);
> + dma_addr_t dma_addr = paddr;
>
> if (unlikely(!dma_direct_possible(dev, dma_addr, size))) {
> report_addr(dev, dma_addr, size);
>
>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()
From: Heiko Carstens @ 2019-01-18 8:43 UTC (permalink / raw)
To: Mike Rapoport
Cc: Rich Felker, linux-ia64, devicetree, Catalin Marinas, x86,
linux-mips, Max Filippov, Guo Ren, sparclinux, Christoph Hellwig,
linux-s390, linux-c6x-dev, Yoshinori Sato, Richard Weinberger,
linux-sh, Russell King, kasan-dev, Geert Uytterhoeven,
Mark Salter, Dennis Zhou, Matt Turner, linux-snps-arc,
uclinux-h8-devel, Petr Mladek, linux-xtensa, linux-alpha,
linux-um, linux-m68k, Rob Herring, Greentime Hu, xen-devel,
Stafford Horne, Guan Xuetao, linux-arm-kernel, Michal Simek,
Tony Luck, linux-mm, Greg Kroah-Hartman, linux-usb, linux-kernel,
Paul Burton, Vineet Gupta, Andrew Morton, linuxppc-dev,
David S. Miller, openrisc
In-Reply-To: <1547646261-32535-20-git-send-email-rppt@linux.ibm.com>
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
...
> diff --git a/arch/s390/numa/toptree.c b/arch/s390/numa/toptree.c
> index 71a608c..0118c77 100644
> --- a/arch/s390/numa/toptree.c
> +++ b/arch/s390/numa/toptree.c
> @@ -31,10 +31,14 @@ struct toptree __ref *toptree_alloc(int level, int id)
> {
> struct toptree *res;
>
> - if (slab_is_available())
> + if (slab_is_available()) {
> res = kzalloc(sizeof(*res), GFP_KERNEL);
> - else
> + } else {
> res = memblock_alloc(sizeof(*res), 8);
> + if (!res)
> + panic("%s: Failed to allocate %zu bytes align=0x%x\n",
> + __func__, sizeof(*res), 8);
> + }
> if (!res)
> return res;
Please remove this hunk, since the code _should_ be able to handle
allocation failures anyway (see end of quoted code).
Otherwise for the s390 bits:
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox