RE: [PATCH 1/2] fsl/fman: propagate dma_ops
> -Original Message-
> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> On Behalf Of Geert Uytterhoeven
> Sent: Monday, June 26, 2017 7:24 PM
> To: Madalin-cristian Bucur
> Cc: net...@vger.kernel.org; David S. Miller ;
> linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH 1/2] fsl/fman: propagate dma_ops
>
> Hi Madalin,
>
> On Mon, Jun 26, 2017 at 4:55 PM, Madalin-cristian Bucur
> wrote:
> >> -Original Message-
> >> From: geert.uytterhoe...@gmail.com
> [mailto:geert.uytterhoe...@gmail.com]
> >> On Behalf Of Geert Uytterhoeven
> >> Sent: Monday, June 26, 2017 10:49 AM
> >> To: Madalin-cristian Bucur
> >> Cc: net...@vger.kernel.org; David S. Miller ;
> >> linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> >> Subject: Re: [PATCH 1/2] fsl/fman: propagate dma_ops
> >>
> > On Mon, Jun 19, 2017 at 5:04 PM, Madalin Bucur
> >> wrote:
> >> > Make sure dma_ops are set, to be later used by the Ethernet driver.
> >> >
> >> > Signed-off-by: Madalin Bucur
> >> > ---
> >> > drivers/net/ethernet/freescale/fman/mac.c | 2 ++
> >> > 1 file changed, 2 insertions(+)
> >> >
> >> > diff --git a/drivers/net/ethernet/freescale/fman/mac.c
> >> b/drivers/net/ethernet/freescale/fman/mac.c
> >> > index 0b31f85..6e67d22f 100644
> >> > --- a/drivers/net/ethernet/freescale/fman/mac.c
> >> > +++ b/drivers/net/ethernet/freescale/fman/mac.c
> >> > @@ -623,6 +623,8 @@ static struct platform_device
> >> *dpaa_eth_add_device(int fman_id,
> >> > goto no_mem;
> >> > }
> >> >
> >> > + set_dma_ops(&pdev->dev, get_dma_ops(priv->dev));
> >> > +
> >>
> >> When compile-testing with f NO_DMA=y:
> >>
> >> drivers/net/ethernet/freescale/fman/mac.c: In function
> >> ‘dpaa_eth_add_device’:
> >> drivers/net/ethernet/freescale/fman/mac.c:626: error: implicit
> >> declaration of function ‘set_dma_ops’
> >>
> >> Reverting commit 5567e989198b5a8d fixes this regression in v4.12-rc7.
> >>
> >> Why is this change needed?
> >> There's no single other call to the DMA API in this file?
> >
> > We're setting here the dma_ops that are later used in the other
> driver/patch.
> > The problem is we now depend upon DMA but do not explicitly declare it:
> >
> > < HAS_DMA'
> > in its Kconfig>>
>
> Sure. But only if the driver really uses DMA.
> I can stick a set_dma_ops() call in whatever driver, but that doesn't
> mean it will
> suddenly use DMA.
> Why does the FMan driver suddenly has a dependency on DMA, if it doesn't
> use DMA?
>
> > I'll need to add this to the FMan driver Kconfig.
>
> Why does the FMan driver need this?
> Why can't his call be done in the driver that uses the DMA APIO?
The DPAA Ethernet driver makes use of DMA ops. It used to get them from
an API call (arch_setup_dma_ops) that was not exported. The DPAA Ethernet
that makes use of the FMan devices does not get the dma_ops as it does not
probe neither as an OF platform device nor thorough ACPI. It probes as a
platform device based on information prepared by the FMan driver. What the
FMan change [1] does is supplement the information shared with the Ethernet
driver with the dma_ops that the FMan driver gets during OF probing. There
are no scenarios one can use the DPAA drivers with NO_DMA, as far as I know.
For general info on the DPAA drivers please refer to the documentation
found in Documentation/networking/dpaa.txt. For the probing of the Ethernet
driver see change [2] and dpaa_eth_add_device() in fsl/fman, dpaa_eth_probe()
in dpaa_eth.
[1] 5567e989198b5a8d fsl/fman: propagate dma_ops
[2] fb52728a9294d97d dpaa_eth: reuse the dma_ops provided by the FMan MAC device
> 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
Thanks,
Madalin
RE: [PATCH] fsl/fman: add dependency on HAS_DMA
> -Original Message-
> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> On Behalf Of Geert Uytterhoeven
> Sent: Monday, June 26, 2017 7:17 PM
> To: Fabio Estevam
> Cc: Madalin-cristian Bucur ;
> net...@vger.kernel.org; David S. Miller ; linuxppc-
> d...@lists.ozlabs.org; linux-kernel
> Subject: Re: [PATCH] fsl/fman: add dependency on HAS_DMA
>
> On Mon, Jun 26, 2017 at 5:20 PM, Fabio Estevam wrote:
> > On Mon, Jun 26, 2017 at 12:12 PM, Madalin Bucur
> wrote:
> >> A previous commit inserted a dependency on DMA API that requires
> >> HAS_DMA to be added in Kconfig.
> >
> > It would be nice to specify the commit that caused this.
>
> That would be commit 5567e989198b5a8d ("fsl/fman: propagate dma_ops").
>
> However, none of the fman code uses any DMA API calls, so IMHO
> the set_dma_ops() should be done somewhere else.
The Ethernet driver is making use of the DMA ops set here.
> 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
[PATCH] tty: New RISC-V SBI console driver
The RISC-V ISA defines a simple console that is availiable via SBI calls
on all systems. This patch adds a driver for this console interface
that can act as both a target for early printk and as the system
console.
Signed-off-by: Palmer Dabbelt
---
drivers/tty/hvc/Kconfig | 11 +
drivers/tty/hvc/Makefile | 1 +
drivers/tty/hvc/hvc_sbi.c | 103 ++
3 files changed, 115 insertions(+)
create mode 100644 drivers/tty/hvc/hvc_sbi.c
diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
index 574da15fe618..ce610fd1982c 100644
--- a/drivers/tty/hvc/Kconfig
+++ b/drivers/tty/hvc/Kconfig
@@ -97,6 +97,17 @@ config HVC_BFIN_JTAG
the HVC driver. If you don't have JTAG, then you probably don't
want this option.
+config HVC_SBI
+ bool "SBI console support"
+ depends on RISCV
+ select HVC_DRIVER
+ default y
+ help
+ This enables support for console output via RISC-V SBI calls, which
+ is normally used only during boot to output printk.
+
+ If you don't know what do to here, say Y.
+
config HVCS
tristate "IBM Hypervisor Virtual Console Server support"
depends on PPC_PSERIES && HVC_CONSOLE
diff --git a/drivers/tty/hvc/Makefile b/drivers/tty/hvc/Makefile
index 6a2702be76d1..2d63bfe4a96b 100644
--- a/drivers/tty/hvc/Makefile
+++ b/drivers/tty/hvc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_HVC_IUCV)+= hvc_iucv.o
obj-$(CONFIG_HVC_UDBG) += hvc_udbg.o
obj-$(CONFIG_HVC_BFIN_JTAG)+= hvc_bfin_jtag.o
obj-$(CONFIG_HVCS) += hvcs.o
+obj-$(CONFIG_HVC_SBI) += hvc_sbi.o
diff --git a/drivers/tty/hvc/hvc_sbi.c b/drivers/tty/hvc/hvc_sbi.c
new file mode 100644
index ..98114cbd85f1
--- /dev/null
+++ b/drivers/tty/hvc/hvc_sbi.c
@@ -0,0 +1,103 @@
+/*
+ * RISC-V SBI interface to hvc_console.c
+ * based on drivers-tty/hvc/hvc_udbg.c
+ *
+ * Copyright (C) 2008 David Gibson, IBM Corporation
+ * Copyright (C) 2012 Regents of the University of California
+ * Copyright (C) 2017 SiFive
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation, version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "hvc_console.h"
+
+static int hvc_sbi_tty_put(uint32_t vtermno, const char *buf, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++)
+ sbi_console_putchar(buf[i]);
+
+ return i;
+}
+
+static int hvc_sbi_tty_get(uint32_t vtermno, char *buf, int count)
+{
+ int i, c;
+
+ for (i = 0; i < count; i++) {
+ if ((c = sbi_console_getchar()) < 0)
+ break;
+ buf[i] = c;
+ }
+
+ return i;
+}
+
+static const struct hv_ops hvc_sbi_ops = {
+ .get_chars = hvc_sbi_tty_get,
+ .put_chars = hvc_sbi_tty_put,
+};
+
+static int __init hvc_sbi_init(void)
+{
+ return PTR_ERR_OR_ZERO(hvc_alloc(0, 0, &hvc_sbi_ops, 16));
+}
+device_initcall(hvc_sbi_init);
+
+static int __init hvc_sbi_console_init(void)
+{
+ hvc_instantiate(0, 0, &hvc_sbi_ops);
+ add_preferred_console("hvc", 0, NULL);
+
+ return 0;
+}
+console_initcall(hvc_sbi_console_init);
+
+#ifdef CONFIG_EARLY_PRINTK
+static void sbi_console_write(struct console *co, const char *buf,
+ unsigned int n)
+{
+ int i;
+
+ for (i = 0; i < n; ++i) {
+ if (buf[i] == '\n')
+ sbi_console_putchar('\r');
+ sbi_console_putchar(buf[i]);
+ }
+}
+
+static struct console early_console_dev __initdata = {
+ .name = "early",
+ .write = sbi_console_write,
+ .flags = CON_PRINTBUFFER | CON_BOOT,
+ .index = -1
+};
+
+static int __init setup_early_printk(char *str)
+{
+ if (early_console == NULL) {
+ early_console = &early_console_dev;
+ register_console(early_console);
+ }
+ return 0;
+}
+early_param("earlyprintk", setup_early_printk);
+#endif
--
2.13.0
Re: [PATCH V5] powerpc/powernv : Add support for OPAL-OCC command/response interface
On Mon, 2017-06-26 at 11:02 +0530, Shilpasri G Bhat wrote:
> In P9, OCC (On-Chip-Controller) supports shared memory based
> commad-response interface. Within the shared memory there is an OPAL
> command buffer and OCC response buffer that can be used to send
> inband commands to OCC. This patch adds a platform driver to support
> the command/response interface between OCC and the host.
>
I feel obliged to check that an occ request_id can be zero, I'm sure
its fine - just have to ask, zero is so often special.
I should also point out I don't know must about how the OCC works or
anything so I would be best if there were other eyes on this.
Provided zero is an ok request_id:
Reviewed-by: Cyril Bur
> Signed-off-by: Shilpasri G Bhat
> ---
> The skiboot patch for the interface is posted here:
> https://lists.ozlabs.org/pipermail/skiboot/2017-June/007960.html
>
> Changes from V4:
> - Add token as a parameter to the opal_occ_command()
> - Use per-occ counter for command request_id instead of using async
> token.
>
> arch/powerpc/include/asm/opal-api.h| 41 +++-
> arch/powerpc/include/asm/opal.h| 3 +
> arch/powerpc/platforms/powernv/Makefile| 2 +-
> arch/powerpc/platforms/powernv/opal-occ.c | 303
> +
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
> arch/powerpc/platforms/powernv/opal.c | 8 +
> 6 files changed, 356 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c
>
> diff --git a/arch/powerpc/include/asm/opal-api.h
> b/arch/powerpc/include/asm/opal-api.h
> index cb3e624..011d86c 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -42,6 +42,10 @@
> #define OPAL_I2C_STOP_ERR-24
> #define OPAL_XIVE_PROVISIONING -31
> #define OPAL_XIVE_FREE_ACTIVE-32
> +#define OPAL_OCC_INVALID_STATE -33
> +#define OPAL_OCC_BUSY-34
> +#define OPAL_OCC_CMD_TIMEOUT -35
> +#define OPAL_OCC_RSP_MISMATCH-36
>
> /* API Tokens (in r0) */
> #define OPAL_INVALID_CALL -1
> @@ -190,7 +194,8 @@
> #define OPAL_NPU_INIT_CONTEXT146
> #define OPAL_NPU_DESTROY_CONTEXT 147
> #define OPAL_NPU_MAP_LPAR148
> -#define OPAL_LAST148
> +#define OPAL_OCC_COMMAND 149
> +#define OPAL_LAST149
>
> /* Device tree flags */
>
> @@ -829,6 +834,40 @@ struct opal_prd_msg_header {
>
> struct opal_prd_msg;
>
> +enum occ_cmd {
> + OCC_CMD_AMESTER_PASS_THRU = 0,
> + OCC_CMD_CLEAR_SENSOR_DATA,
> + OCC_CMD_SET_POWER_CAP,
> + OCC_CMD_SET_POWER_SHIFTING_RATIO,
> + OCC_CMD_SELECT_SENSOR_GROUPS,
> + OCC_CMD_LAST
> +};
> +
> +struct opal_occ_cmd_rsp_msg {
> + __be64 cdata;
> + __be64 rdata;
> + __be16 cdata_size;
> + __be16 rdata_size;
> + u8 cmd;
> + u8 request_id;
> + u8 status;
> +};
> +
> +struct opal_occ_cmd_data {
> + __be16 size;
> + u8 cmd;
> + u8 data[];
> +};
> +
> +struct opal_occ_rsp_data {
> + __be16 size;
> + u8 status;
> + u8 data[];
> +};
> +
> +#define MAX_OPAL_CMD_DATA_LENGTH4090
> +#define MAX_OCC_RSP_DATA_LENGTH 8698
> +
> #define OCC_RESET 0
> #define OCC_LOAD1
> #define OCC_THROTTLE2
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index 03ed493..84659bd 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -346,6 +346,9 @@ static inline int opal_get_async_rc(struct opal_msg msg)
>
> void opal_wake_poller(void);
>
> +int64_t opal_occ_command(int chip_id, struct opal_occ_cmd_rsp_msg *msg,
> + int token, bool retry);
> +
> #endif /* __ASSEMBLY__ */
>
> #endif /* _ASM_POWERPC_OPAL_H */
> diff --git a/arch/powerpc/platforms/powernv/Makefile
> b/arch/powerpc/platforms/powernv/Makefile
> index b5d98cb..f5f0902 100644
> --- a/arch/powerpc/platforms/powernv/Makefile
> +++ b/arch/powerpc/platforms/powernv/Makefile
> @@ -2,7 +2,7 @@ obj-y += setup.o opal-wrappers.o opal.o
> opal-async.o idle.o
> obj-y+= opal-rtc.o opal-nvram.o opal-lpc.o
> opal-flash.o
> obj-y+= rng.o opal-elog.o opal-dump.o
> opal-sysparam.o opal-sensor.o
> obj-y+= opal-msglog.o opal-hmi.o opal-power.o
> opal-irqchip.o
> -obj-y+= opal-kmsg.o
> +obj-y+= opal-kmsg.o opal-occ.o
>
> obj-$(CONFIG_SMP)+= smp.o subcore.o subcore-asm.o
> obj-$(CONFIG_PCI)+= pci.o pci-ioda.o npu-dma.o
> diff --git a/arch/powerpc/platforms/powernv/opal-occ.c
> b/arch/powerpc/platforms/powernv/opal-occ.c
> new file mode 100644
> index 000..440304f
> --- /dev/null
> +++ b/arch/powerpc/platforms/powernv
[RESEND PATCH] powerpc/modules: Introduce new stub code for SHN_LIVEPATCH symbols
R_PPC64_REL24 relocation type is used for a function call, where the
function symbol address is resolved and stub code (a.k.a trampoline)
is constructed to jump into the global entry of the function. The
caller is responsible for setting up the TOC of the called function
before branching and NOP is expected after every branch, which gets
replaced with an instruction to restore the callers TOC from the
stack on return.
SHN_LIVEPATCH symbols with R_PPC64_REL24 relocation type might not
adhere to nop instruction after a branch. The reason being called
function was local to the callee and the instruction sequence
generated does not stores and restores the TOC value onto the stack
of the calling function, which is right. The calling function instead
uses the localentry (function entry + 0x8) to jump into the function
and returns without the need for store/restoring the TOC, as both of
the functions were in the same compilation unit.
When such functions become global because they are livepatched and
every call to the function, re-directs the callee to the patched
version in the module. Every branch from the livepatch module, to
previously local function turns out to be a jump into the kernel
code but with the code sequence remains that of the localentry. This
leads to error while trying to access the function with an assumption,
of being local to the calling function:
insmod: ERROR: could not insert module ./kpatch-meminfo-string.ko: Invalid
module format
Jun 13 02:10:47 ubuntu kernel: [ 37.774292] module_64: kpatch_meminfo_string:
REL24 -1152921504749690968 out of range!
SHN_LIVEPATCH symbols + R_PPC64_REL24 type relocations can be handled
by introducing a new stub code sequence, instead of regular module stub
code. Where stub takes care of storing and restoring the Link Register/TOC
onto the stack of the livepatched function and restores them upon
return from the called function.
Signed-off-by: Kamalesh Babulal
Cc: Michael Ellerman
Cc: Balbir Singh
Cc: Josh Poimboeuf
Cc: Jessica Yu
Cc: Ananth N Mavinakayanahalli
Cc: Aravinda Prasad
Cc: live-patch...@vger.kernel.org
---
Resending the patch with minor editing of commit message and have added
more developers to cc list.
arch/powerpc/kernel/module_64.c | 55 -
1 file changed, 44 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..52ded0f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -102,10 +102,16 @@ static unsigned int local_entry_offset(const Elf64_Sym
*sym)
jump, actually, to reset r2 (TOC+0x8000). */
struct ppc64_stub_entry
{
- /* 28 byte jump instruction sequence (7 instructions). We only
-* need 6 instructions on ABIv2 but we always allocate 7 so
-* so we don't have to modify the trampoline load instruction. */
- u32 jump[7];
+ /* 28 byte jump instruction sequence (7 instructions) and only
+* 6 instructions are needed on ABIv2 to create trampoline.
+* Trampoline for livepatch symbol needs extra 7 instructions
+* to save and restore LR, TOC values.
+*
+* To accommodate extra instructions required for livepatch
+* entry, we allocate 15 instructions so we don't have to
+* modify the trampoline load instruction.
+*/
+ u32 jump[15];
/* Used by ftrace to identify stubs */
u32 magic;
/* Data for the above code */
@@ -131,7 +137,7 @@ static u32 ppc64_stub_insns[] = {
0x396b, /* addir11,r11, */
/* Save current r2 value in magic place on the stack. */
0xf841|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
- 0xe98b0020, /* ld r12,32(r11) */
+ 0xe98b0040, /* ld r12,64(r11) */
#ifdef PPC64_ELF_ABI_v1
/* Set up new r2 from function descriptor */
0xe84b0028, /* ld r2,40(r11) */
@@ -140,6 +146,24 @@ static u32 ppc64_stub_insns[] = {
0x4e800420 /* bctr */
};
+static u32 ppc64_klp_stub_insns[] = {
+ 0x3d62, /* addis r11,r2,*/
+ 0x396b, /* addir11,r11,*/
+ 0x7c0802a6, /* mflrr0 */
+ 0xf8010010, /* std r0,16(r1)*/
+ /* Save current r2 value in magic place on the stack. */
+ 0xf841|R2_STACK_OFFSET, /* std r2,R2_STACK_OFFSET(r1) */
+ 0xe98b0040, /* ld r12,64(r11) */
+ 0xf821ffe1, /* stdur1,-32(r1) */
+ 0x7d8903a6, /* mtctr r12 */
+ 0x4e800421, /* bctrl*/
+ 0x38210020, /* addir1,r1,32
Re: [PATCH v3 4/6] powerpc/mm: Add devmap support for ppc64
kbuild test robot writes: > Hi Oliver, > > [auto build test ERROR on powerpc/next] > [also build test ERROR on v4.12-rc6 next-20170623] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Oliver-O-Halloran/mm-x86-Add-ARCH_HAS_ZONE_DEVICE-to-Kconfig/20170625-102522 > base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next > config: powerpc-defconfig (attached as .config) > compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 > reproduce: > wget > https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=powerpc > > All errors (new ones prefixed by >>): > >mm/gup.c: In function '__gup_device_huge_pud': >>> mm/gup.c:1329:14: error: implicit declaration of function 'pud_pfn' >>> [-Werror=implicit-function-declaration] > fault_pfn = pud_pfn(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT); > ^~~ >cc1: some warnings being treated as errors The key here is that CONFIG_TRANSPARENT_HUGEPAGE=n. So this needs to be fixed before I can merge this. I think the problem is just that pud_pfn() is inside #ifdef CONFIG_TRANSPARENT_HUGEPAGE but shouldn't be. cheers
Re: powerpc/32: Avoid miscompilation w/GCC 4.6.3 - don't inline copy_to/from_user()
On Mon, 2017-06-26 at 13:34:15 UTC, Michael Ellerman wrote:
> Larry Finger reported that his Powerbook G4 was no longer booting with
> v4.12-rc,
> userspace was up but giving weird errors such as:
>
> udevd[64]: starting version 175
> udevd[64]: Unable to receive ctrl message: Bad address.
> modprobe: chdir(4.12-rc1): No such file or directory
>
> He bisected the problem to commit 3448890c32c3 ("powerpc: get rid of zeroing,
> switch to RAW_COPY_USER").
>
> Al identified that the problem is actually a miscompilation by GCC 4.6.3,
> which
> is exposed by the above commit.
>
> Al also pointed out that inlining copy_to/from_user() is probably of little or
> no benefit, which is correct. Using Anton's copy_to_user benchmark, with a
> pathological single byte copy, we see a small increase in performance
> by *removing* inlining:
>
> Before (inlined):
> # time ./copy_to_user -w -l 1 -i 1000 ( x 3 )
> real0m22.063s
> real0m22.059s
> real0m22.076s
>
> After:
> # time ./copy_to_user -w -l 1 -i 1000 ( x 3 )
> real0m21.325s
> real0m21.299s
> real0m21.364s
>
> So as a small performance improvement and to avoid the miscompilation, drop
> inlining copy_to/from_user() on 32-bit.
>
> Fixes: 3448890c32c3 ("powerpc: get rid of zeroing, switch to RAW_COPY_USER")
> Reported-by: Larry Finger
> Suggested-by: Al Viro
> Signed-off-by: Michael Ellerman
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/d6bd8194e2867e85ac2de63486d3b8
cheers
Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper
On Sun, Jun 25, 2017 at 11:02:58PM -0500, Benjamin Herrenschmidt wrote: > On Mon, 2017-06-26 at 09:03 +1000, Balbir Singh wrote: > > On Wed, 2017-06-21 at 18:39 -0700, Ram Pai wrote: > > > Introduce set_hidx_slot() which sets the (H_PAGE_F_SECOND|H_PAGE_F_GIX) > > > bits at the appropriate location in the PTE of 4K PTE. In the > > > case of 64K PTE, it sets the bits in the second part of the PTE. Though > > > the implementation for the former just needs the slot parameter, it does > > > take some additional parameters to keep the prototype consistent. > > > > > > This function will come in handy as we work towards re-arranging the > > > bits in the later patches. > > The name somewhat sucks. Something like pte_set_hash_slot() or > something like that would be much more meaningful. ok. pte_set_hash_slot() sounds good. RP
Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper
On Mon, Jun 26, 2017 at 09:03:18AM +1000, Balbir Singh wrote:
> On Wed, 2017-06-21 at 18:39 -0700, Ram Pai wrote:
> > Introduce set_hidx_slot() which sets the (H_PAGE_F_SECOND|H_PAGE_F_GIX)
> > bits at the appropriate location in the PTE of 4K PTE. In the
> > case of 64K PTE, it sets the bits in the second part of the PTE. Though
> > the implementation for the former just needs the slot parameter, it does
> > take some additional parameters to keep the prototype consistent.
> >
> > This function will come in handy as we work towards re-arranging the
> > bits in the later patches.
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc/include/asm/book3s/64/hash-4k.h | 7 +++
> > arch/powerpc/include/asm/book3s/64/hash-64k.h | 16
> > 2 files changed, 23 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > index 9c2c8f1..cef644c 100644
> > --- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > +++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > @@ -55,6 +55,13 @@ static inline int hash__hugepd_ok(hugepd_t hpd)
> > }
> > #endif
> >
> > +static inline unsigned long set_hidx_slot(pte_t *ptep, real_pte_t rpte,
> > + unsigned int subpg_index, unsigned long slot)
> > +{
> > + return (slot << H_PAGE_F_GIX_SHIFT) &
> > + (H_PAGE_F_SECOND | H_PAGE_F_GIX);
> > +}
> > +
>
> A comment on top would help explain that 4k and 64k are different, 64k
> is a new layout.
ok.
>
> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >
> > static inline char *get_hpte_slot_array(pmd_t *pmdp)
> > diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h
> > b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> > index 3f49941..4bac70a 100644
> > --- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
> > +++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> > @@ -75,6 +75,22 @@ static inline unsigned long __rpte_to_hidx(real_pte_t
> > rpte, unsigned long index)
> > return (pte_val(rpte.pte) >> H_PAGE_F_GIX_SHIFT) & 0xf;
> > }
> >
> > +static inline unsigned long set_hidx_slot(pte_t *ptep, real_pte_t rpte,
> > + unsigned int subpg_index, unsigned long slot)
> > +{
> > + unsigned long *hidxp = (unsigned long *)(ptep + PTRS_PER_PTE);
> > +
> > + rpte.hidx &= ~(0xfUL << (subpg_index << 2));
> > + *hidxp = rpte.hidx | (slot << (subpg_index << 2));
> > + /*
> > +* Avoid race with __real_pte()
> > +* hidx must be committed to memory before committing
> > +* the pte.
> > +*/
> > + smp_wmb();
>
> Whats the other paired barrier, is it in set_pte()?
__real_pte() reads the hidx. The smp_rmb() is in that function.
>
> > + return 0x0UL;
> > +}
>
> We return 0 here and slot information for 4k pages, it is not that
> clear
We return 0 here and commit the 4k-hpte hidx.
RP
Re: clean up and modularize arch dma_mapping interface V2
On 06/26/2017 02:47 AM, Christoph Hellwig wrote: On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote: I think we still need to do it. For example we have a bunch new "funky" cases. I have no plan to do away with the selection - I just want a better interface than the current one. I agree we need better interface than the current one. Like Benjamin mentioned cases for powerpc , sparc also need some special treatment for ATU IOMMU depending on device's DMA mask. For sparc, I am in process of enabling one or more dedicated IOTSB (I/O Translation Storage Buffer) per PCI BDF (contrary to current design where all PCI device under root complex share a 32bit and/or 64bit IOTSB depending on 32bit and/or 64bit DMA). I am planning to use DMA set mask APIs as hook where based on device's dma mask values (dma_mask and coherent_dma_mask) one or more IOTSB resource will be allocated (and released [1]). Without set_dma_mask ops, I can still rely on HAVE_ARCH_DMA_SET_MASK and dma_supported() that allows me to distinguish if device is setting its streaming dma_mask and coherent_dma_mask respectively. -Tushar [1] By default, every PCI BDF will have one dedicated 32bit IOTSB. This is to support default case where some device drivers even don't bother to set DMA mask but instead are fine with default 32bit mask. A 64bit IOTSB will be allocated when device request 64bit dma_mask. However if device wants 64bit dma mask for both coherent and non-coherent, a default 32bit IOTSB will be released as well. Wasting an IOTSB is not a good idea because there is a hard limit on max number of IOTSB per guest domain per root complex. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64
On 6/26/2017 2:43 PM, Arnd Bergmann wrote:
This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which
I find rather confusing, as only about one in five drivers wants this
behavior.
I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures,
but rather use the same logic that we have for readq/writeq in
io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h, adding
{lo_hi,hi_lo}_{ioread,iowrite}{,be} to the same files, and provide
the {ioread,iowrite}{,be} macros only if they have not been defined
at that point.
Thanks Arnd. Yes, I'm already reworking this patchset to do exactly that.
Logan
Re: [PATCH] kernel/power/suspend: use CONFIG_HAVE_SET_MEMORY for include condition
On Monday, June 26, 2017 01:34:52 PM Balbir Singh wrote: > On Sat, Jun 3, 2017 at 11:27 PM, Pavel Machek wrote: > > On Sat 2017-06-03 20:52:32, Balbir Singh wrote: > >> Kbuild reported a build failure when CONFIG_STRICT_KERNEL_RWX was > >> enabled on powerpc. We don't yet have ARCH_HAS_SET_MEMORY and ppc32 > >> saw a build failure. > >> > >> fixes(50327dd kernel/power/snapshot.c: use set_memory.h header) > >> > >> I've only done a basic compile test with a config that has > >> hibernation enabled. > >> > >> Cc: "Rafael J. Wysocki" > >> Cc: Len Brown > > Acked-by: Pavel Machek > > Ping. Could we please pick this up? it breaks any attempt to support > STRICT_KERNEL_RWX on powerpc Yes, I'm going to pick it up for 4.13. Thanks, Rafael
Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64
> +u64 ioread64(void __iomem *addr)
> +{
> + u64 low, high;
> +
> + low = ioread32(addr);
> + high = ioread32(addr + sizeof(u32));
> + return low | (high << 32);
> +}
> +u64 ioread64be(void __iomem *addr)
> +{
> + u64 low, high;
> +
> + low = ioread32be(addr + sizeof(u32));
> + high = ioread32be(addr);
> + return low | (high << 32);
> +}
> +#endif
This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which
I find rather confusing, as only about one in five drivers wants this
behavior.
I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures,
but rather use the same logic that we have for readq/writeq in
io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h, adding
{lo_hi,hi_lo}_{ioread,iowrite}{,be} to the same files, and provide
the {ioread,iowrite}{,be} macros only if they have not been defined
at that point.
Arnd
Re: [PATCH 00/17] cxlflash: LUN provisioning support and miscellaneous fixes
Uma, > This patch series contains miscellaneous fixes and several > enhancements such as LUN provisioning support, WS16 unmap and AFU > debug capabilities. Applied to 4.13/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
On Mon, Jun 26, 2017 at 6:04 AM, Michael Ellerman wrote: > Kees Cook writes: > >> On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman >> wrote: >>> Kees Cook writes: >>> Now that explicitly executed loaders are loaded in the mmap region, position PIE binaries lower in the address space to avoid possible collisions with mmap or stack regions. For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit address space for 32-bit pointers. >>> >>> The change log and subject are a bit out of whack with the actual patch >>> because previously we used 512MB. >>> >>> How about? >>> >>> powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB >>> >>> Now that explicitly executed loaders are loaded in the mmap region, >>> we have more freedom to decide where we position PIE binaries in the >>> address space to avoid possible collisions with mmap or stack regions. >>> >>> For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit >>> address space for 32-bit pointers. On 32-bit use 4MB. >> >> Good idea, thanks. I'll resend the series with the commit logs updated. >> >>> Is there any particular reasoning behind the 4MB value on 32-bit? >> >> So, I've dug around a bit on this, and I *think* the rationale is to >> avoid mapping a possible 4MB page table entry when it won't be using >> at least a portion near the lower end (NULL address area covered >> blocked by mmap_min_addr). It seems to be mainly tradition, though. > > OK, that is obscure, especially for CPUs that don't have a 4MB page > size. But consistency across arches is probably best regardless. Yeah, I like being not "close" to the NULL address, though the definition of "close" has been various values like 64K (mmap_min_addr) and 1M (x86 BIOS junk and new stack-gap size). 4MB is above even that, so, I think we're fine there. It's what Windows has used, so it's familiar and any new attack methodologies would at least be shared across OSes and architectures, so we should "notice" any problem with the value, and then we can adjust it if we need to. -Kees -- Kees Cook Pixel Security
[PATCH v2] powerpc/powernv: Enable PCI peer-to-peer
P9 has support for PCI peer-to-peer, enabling a device to write in the
mmio space of another device directly, without interrupting the CPU.
This patch adds support for it on powernv, by adding a new API to be
called by drivers. The pnv_pci_set_p2p(...) call configures an
'initiator', i.e the device which will issue the mmio operation, and a
'target', i.e. the device on the receiving side.
P9 really only supports mmio stores for the time being (loads are only
supported if the 2 devices are under the same PHBs), but that's
expected to change in the future, so the API allows to define both
load and store operations.
/* PCI p2p descriptor */
#define OPAL_PCI_P2P_ENABLE 0x1
#define OPAL_PCI_P2P_LOAD 0x2
#define OPAL_PCI_P2P_STORE 0x4
int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target,
uint64_t desc)
It uses a new OPAL call, as the configuration magic is done on the
PHBs by skiboot.
Signed-off-by: Frederic Barrat
---
Requires skiboot patch:
http://patchwork.ozlabs.org/patch/780813/
Changelog:
- change of API
- allow disabling of p2p setting
arch/powerpc/include/asm/opal-api.h| 8 ++-
arch/powerpc/include/asm/opal.h| 3 ++
arch/powerpc/include/asm/pnv-pci.h | 2 +
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
arch/powerpc/platforms/powernv/pci-ioda.c | 3 +-
arch/powerpc/platforms/powernv/pci.c | 68 ++
arch/powerpc/platforms/powernv/pci.h | 4 ++
7 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index cb3e6242a78c..2b068550b106 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -190,7 +190,8 @@
#define OPAL_NPU_INIT_CONTEXT 146
#define OPAL_NPU_DESTROY_CONTEXT 147
#define OPAL_NPU_MAP_LPAR 148
-#define OPAL_LAST 148
+#define OPAL_PCI_SET_P2P 149
+#define OPAL_LAST 149
/* Device tree flags */
@@ -1003,6 +1004,11 @@ enum {
XIVE_DUMP_EMU_STATE = 5,
};
+/* PCI p2p descriptor */
+#define OPAL_PCI_P2P_ENABLE0x1
+#define OPAL_PCI_P2P_LOAD 0x2
+#define OPAL_PCI_P2P_STORE 0x4
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 588fb1c23af9..9c099fa9bb4e 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -267,6 +267,9 @@ int64_t opal_xive_allocate_irq(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);
+int64_t opal_pci_set_p2p(uint64_t phb_init, uint64_t phb_target,
+ uint64_t desc, uint16_t pe_number);
+
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
diff --git a/arch/powerpc/include/asm/pnv-pci.h
b/arch/powerpc/include/asm/pnv-pci.h
index de9681034353..59a548909d0b 100644
--- a/arch/powerpc/include/asm/pnv-pci.h
+++ b/arch/powerpc/include/asm/pnv-pci.h
@@ -26,6 +26,8 @@ extern int pnv_pci_get_presence_state(uint64_t id, uint8_t
*state);
extern int pnv_pci_get_power_state(uint64_t id, uint8_t *state);
extern int pnv_pci_set_power_state(uint64_t id, uint8_t state,
struct opal_msg *msg);
+extern int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target,
+ uint64_t desc);
int pnv_phb_to_cxl_mode(struct pci_dev *dev, uint64_t mode);
int pnv_cxl_ioda_msi_setup(struct pci_dev *dev, unsigned int hwirq,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index f620572f891f..cf629d2d89d9 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -310,3 +310,4 @@ OPAL_CALL(opal_xive_dump, OPAL_XIVE_DUMP);
OPAL_CALL(opal_npu_init_context, OPAL_NPU_INIT_CONTEXT);
OPAL_CALL(opal_npu_destroy_context,OPAL_NPU_DESTROY_CONTEXT);
OPAL_CALL(opal_npu_map_lpar, OPAL_NPU_MAP_LPAR);
+OPAL_CALL(opal_pci_set_p2p,OPAL_PCI_SET_P2P);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 283caf1070c9..ebb24ddf17c3 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1408,7 +1408,6 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev,
u16 num_vfs)
static long pnv_pci_ioda2_unset_window(struct iommu_table_group *table_group,
int num);
-static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable);
Re: ps3 linux: os_area_queue_work_handler: Could not update FLASH ROM
Hi Sombat, On 06/26/2017 02:26 AM, Sombat Tragolgosol wrote: > 1) Is it normal for os_area_queue_work_handler: Could not update FLASH ROM? You should try to find the exact cause of the error. It could be due to a corrupted os-area. > 2) My Date time is not correct. Is the problem is not able to update os-area > data? > > Here below is my rtc time problem. > > RTC time is not proper value (lower than it should be). > (For GameOS , Date-Time is OK.) > > Here is what I've tried >1) lv1_get_rtc gets 205943663 (11 Jul 1976) >2) saved_params.rtc_diff always is 946684800 > (205943663+946684800) = 11 Jul 2006 >So every time, my Linux is booted, my year says 2006 and causes problem > on clock skew. >3) if I add 345746286 to rtc in read_rtc function in > arch/powerpc/platforms/ps3/time.c and > drivers/rtc/rtc-ps3.c > (205943663+946684800+345746286) = 25 Jun 2017 >My boot time and date is acceptable for my temporary use. > >Do you have any proper solution? I don't want to modify source for my one > rtc time problem? Your problem is that the os-area database value is wrong and is not being set. The RTC hardware of the PS3 cannot be reset, so each OS (game-os and Linux) needs to maintain a difference between the hardware RTC value and the value it uses for time. A read-only copy of the game-os diff is put at os_area_params.rtc_diff. You can read that with 'ps3-flash-util --game-time'. For Linux we keep that difference in the os-area database (db_area_offset + OS_AREA_DB_OWNER_LINUX + OS_AREA_DB_KEY_RTC_DIFF). See: https://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-docs/PlatformSpecificUtilities.html First you should try to set the os-area value with 'ps3-rtc-init --force'. Look at the ps3-rtc-init source to see how to set the rtc diff value yourself: https://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-utils.git/tree/ps3-rtc-init.in#n69 Maybe you need to re-format the os-area database 'ps3-flash-util db-format'. Make a backup first. See '** backup flash data **' here: https://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-howto/ps3-boot-recovery-howto.txt -Geoff
RE: [PATCH] powerpc/32: Avoid miscompilation w/GCC 4.6.3 - don't inline copy_to/from_user()
From: Michael Ellerman > Sent: 26 June 2017 14:34 .. > Al also pointed out that inlining copy_to/from_user() is probably of little or > no benefit, which is correct ... I was a bit horrified at the x86-64 versions of copy_to/from_user() as well. With code that (tries to) error kernel pointers that cross stack frame boundaries I'm fairly sure they expand to a lot of code. I also suspect the cost of that kernel address check is not insignificant especially if it has to walk down several stack frames. (Never mind what happens to code compiled without stack frames.) David
Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64
Hi Jyri, Thanks for the ack. However, I'm reworking this patch set to use the include/linux/io-64-nonatomic* headers which will explicitly devolve into two 32-bit transfers. It's not clear whether this is appropriate for the tilcdc driver as it was never setup to use 32-bit transfers (unlike the others I had patched). If you think it's ok, I can still patch this driver to use the non-atomic headers. Otherwise I can leave it out. Please let me know. Thanks, Logan On 26/06/17 02:55 AM, Jyri Sarha wrote: > Acked-by: Jyri Sarha > > And thanks! > >> --- >> drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 -- >> 1 file changed, 6 deletions(-) >> >> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h >> b/drivers/gpu/drm/tilcdc/tilcdc_regs.h >> index e9ce725698a9..0b901405f30a 100644 >> --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h >> +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h >> @@ -133,13 +133,7 @@ static inline void tilcdc_write64(struct drm_device >> *dev, u32 reg, u64 data) >> struct tilcdc_drm_private *priv = dev->dev_private; >> void __iomem *addr = priv->mmio + reg; >> >> -#ifdef iowrite64 >> iowrite64(data, addr); >> -#else >> -__iowmb(); >> -/* This compiles to strd (=64-bit write) on ARM7 */ >> -*(u64 __force *)addr = __cpu_to_le64(data); >> -#endif >> } >> >> static inline u32 tilcdc_read(struct drm_device *dev, u32 reg) >> >
Re: [PATCH 1/2] fsl/fman: propagate dma_ops
Hi Madalin,
On Mon, Jun 26, 2017 at 4:55 PM, Madalin-cristian Bucur
wrote:
>> -Original Message-
>> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
>> On Behalf Of Geert Uytterhoeven
>> Sent: Monday, June 26, 2017 10:49 AM
>> To: Madalin-cristian Bucur
>> Cc: net...@vger.kernel.org; David S. Miller ;
>> linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
>> Subject: Re: [PATCH 1/2] fsl/fman: propagate dma_ops
>>
> On Mon, Jun 19, 2017 at 5:04 PM, Madalin Bucur
>> wrote:
>> > Make sure dma_ops are set, to be later used by the Ethernet driver.
>> >
>> > Signed-off-by: Madalin Bucur
>> > ---
>> > drivers/net/ethernet/freescale/fman/mac.c | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > diff --git a/drivers/net/ethernet/freescale/fman/mac.c
>> b/drivers/net/ethernet/freescale/fman/mac.c
>> > index 0b31f85..6e67d22f 100644
>> > --- a/drivers/net/ethernet/freescale/fman/mac.c
>> > +++ b/drivers/net/ethernet/freescale/fman/mac.c
>> > @@ -623,6 +623,8 @@ static struct platform_device
>> *dpaa_eth_add_device(int fman_id,
>> > goto no_mem;
>> > }
>> >
>> > + set_dma_ops(&pdev->dev, get_dma_ops(priv->dev));
>> > +
>>
>> When compile-testing with f NO_DMA=y:
>>
>> drivers/net/ethernet/freescale/fman/mac.c: In function
>> ‘dpaa_eth_add_device’:
>> drivers/net/ethernet/freescale/fman/mac.c:626: error: implicit
>> declaration of function ‘set_dma_ops’
>>
>> Reverting commit 5567e989198b5a8d fixes this regression in v4.12-rc7.
>>
>> Why is this change needed?
>> There's no single other call to the DMA API in this file?
>
> We're setting here the dma_ops that are later used in the other driver/patch.
> The problem is we now depend upon DMA but do not explicitly declare it:
>
> < in its Kconfig>>
Sure. But only if the driver really uses DMA.
I can stick a set_dma_ops() call in whatever driver, but that doesn't
mean it will
suddenly use DMA.
Why does the FMan driver suddenly has a dependency on DMA, if it doesn't
use DMA?
> I'll need to add this to the FMan driver Kconfig.
Why does the FMan driver need this?
Why can't his call be done in the driver that uses the DMA APIO?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [PATCH] fsl/fman: add dependency on HAS_DMA
On Mon, Jun 26, 2017 at 5:20 PM, Fabio Estevam wrote:
> On Mon, Jun 26, 2017 at 12:12 PM, Madalin Bucur wrote:
>> A previous commit inserted a dependency on DMA API that requires
>> HAS_DMA to be added in Kconfig.
>
> It would be nice to specify the commit that caused this.
That would be commit 5567e989198b5a8d ("fsl/fman: propagate dma_ops").
However, none of the fman code uses any DMA API calls, so IMHO
the set_dma_ops() should be done somewhere else.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
RE: [PATCH] soc/qman: Sleep instead of stuck hacking jiffies.
From: Karim Eshapa
> Sent: 25 June 2017 16:14
> Use msleep() instead of stucking with
> long delay will be more efficient.
...
> --- a/drivers/soc/fsl/qbman/qman.c
> +++ b/drivers/soc/fsl/qbman/qman.c
> @@ -1084,11 +1084,7 @@ static int drain_mr_fqrni(struct qm_portal *p)
>* entries well before the ring has been fully consumed, so
>* we're being *really* paranoid here.
>*/
> - u64 now, then = jiffies;
> -
> - do {
> - now = jiffies;
> - } while ((then + 1) > now);
> + msleep(1);
...
How is that in any way equivalent?
If HZ is 1000 the old code loops for 10 seconds.
If HZ is 250 (common for some distros) it loops for 40 seconds.
Clearly both are horrid, but it isn't at all clear that a 1ms sleep
is performing the same job.
My guess is that this code is never called, and broken if actually called.
David
RE: [PATCH] fsl/fman: add dependency on HAS_DMA
> -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Monday, June 26, 2017 6:21 PM > To: Madalin-cristian Bucur > Cc: net...@vger.kernel.org; David S. Miller ; Geert > Uytterhoeven ; linuxppc-dev@lists.ozlabs.org; linux- > kernel > Subject: Re: [PATCH] fsl/fman: add dependency on HAS_DMA > > On Mon, Jun 26, 2017 at 12:12 PM, Madalin Bucur > wrote: > > A previous commit inserted a dependency on DMA API that requires > > HAS_DMA to be added in Kconfig. > > It would be nice to specify the commit that caused this. Sent v2, thanks. Madalin
[PATCH v2] fsl/fman: add dependency on HAS_DMA
A previous commit (5567e989198b5a8d) inserted a dependency on DMA API that requires HAS_DMA to be added in Kconfig. Signed-off-by: Madalin Bucur --- drivers/net/ethernet/freescale/fman/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig index dc0850b..8870a9a 100644 --- a/drivers/net/ethernet/freescale/fman/Kconfig +++ b/drivers/net/ethernet/freescale/fman/Kconfig @@ -2,6 +2,7 @@ config FSL_FMAN tristate "FMan support" depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST select GENERIC_ALLOCATOR + depends on HAS_DMA select PHYLIB default n help -- 2.1.0
Re: [PATCH] fsl/fman: add dependency on HAS_DMA
On Mon, Jun 26, 2017 at 12:12 PM, Madalin Bucur wrote: > A previous commit inserted a dependency on DMA API that requires > HAS_DMA to be added in Kconfig. It would be nice to specify the commit that caused this.
[PATCH] fsl/fman: add dependency on HAS_DMA
A previous commit inserted a dependency on DMA API that requires HAS_DMA to be added in Kconfig. Signed-off-by: Madalin Bucur --- drivers/net/ethernet/freescale/fman/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig index dc0850b..8870a9a 100644 --- a/drivers/net/ethernet/freescale/fman/Kconfig +++ b/drivers/net/ethernet/freescale/fman/Kconfig @@ -2,6 +2,7 @@ config FSL_FMAN tristate "FMan support" depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST select GENERIC_ALLOCATOR + depends on HAS_DMA select PHYLIB default n help -- 2.1.0
RE: [PATCH 1/2] fsl/fman: propagate dma_ops
> -Original Message-
> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> On Behalf Of Geert Uytterhoeven
> Sent: Monday, June 26, 2017 10:49 AM
> To: Madalin-cristian Bucur
> Cc: net...@vger.kernel.org; David S. Miller ;
> linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH 1/2] fsl/fman: propagate dma_ops
>
> Hi Madalin,
>
> On Mon, Jun 19, 2017 at 5:04 PM, Madalin Bucur
> wrote:
> > Make sure dma_ops are set, to be later used by the Ethernet driver.
> >
> > Signed-off-by: Madalin Bucur
> > ---
> > drivers/net/ethernet/freescale/fman/mac.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/freescale/fman/mac.c
> b/drivers/net/ethernet/freescale/fman/mac.c
> > index 0b31f85..6e67d22f 100644
> > --- a/drivers/net/ethernet/freescale/fman/mac.c
> > +++ b/drivers/net/ethernet/freescale/fman/mac.c
> > @@ -623,6 +623,8 @@ static struct platform_device
> *dpaa_eth_add_device(int fman_id,
> > goto no_mem;
> > }
> >
> > + set_dma_ops(&pdev->dev, get_dma_ops(priv->dev));
> > +
>
> When compile-testing with f NO_DMA=y:
>
> drivers/net/ethernet/freescale/fman/mac.c: In function
> ‘dpaa_eth_add_device’:
> drivers/net/ethernet/freescale/fman/mac.c:626: error: implicit
> declaration of function ‘set_dma_ops’
>
> Reverting commit 5567e989198b5a8d fixes this regression in v4.12-rc7.
>
> Why is this change needed?
> There's no single other call to the DMA API in this file?
We're setting here the dma_ops that are later used in the other driver/patch.
The problem is we now depend upon DMA but do not explicitly declare it:
<>
I'll need to add this to the FMan driver Kconfig.
> If it's really needed, can't set_dma_ops() be called from the driver that
> needs it, cfr. your other patch "[PATCH 2/2] dpaa_eth: reuse the dma_ops
> provided by the FMan MAC device"?
>
> Thanks!
>
> 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
Thanks,
Madalin
[PATCH V7 2/2] powerpc/numa: Update CPU topology when VPHN enabled
powerpc/numa: Correct the currently broken capability to set the
topology for shared CPUs in LPARs. At boot time for shared CPU
lpars, the topology for each shared CPU is set to node zero, however,
this is now updated correctly using the Virtual Processor Home Node
(VPHN) capabilities information provided by the pHyp.
Also, update initialization checks for device-tree attributes to
independently recognize PRRN or VPHN usage.
Signed-off-by: Michael Bringmann
---
Changes in V7:
-- Fix a conditional compile bug.
---
arch/powerpc/include/asm/topology.h | 17 +++
arch/powerpc/mm/numa.c | 64 +++---
arch/powerpc/platforms/pseries/dlpar.c |2 +
arch/powerpc/platforms/pseries/hotplug-cpu.c |2 +
4 files changed, 78 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index 03f64f2..0b0089c 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -93,6 +93,23 @@ static inline int prrn_is_enabled(void)
}
#endif /* CONFIG_NUMA && CONFIG_PPC_SPLPAR */
+#if defined(CONFIG_HOTPLUG_CPU)
+#if defined(CONFIG_NUMA) && defined(CONFIG_PPC_SPLPAR)
+extern int timed_topology_update(int nsecs);
+#else
+static int timed_topology_update(int nsecs)
+{
+ return 0;
+}
+#endif /* CONFIG_NUMA && CONFIG_PPC_SPLPAR */
+#endif /* CONFIG_HOTPLUG_CPU */
+
+#if defined(CONFIG_PPC_SPLPAR)
+extern void shared_topology_update(void);
+#else
+#defineshared_topology_update()0
+#endif /* CONFIG_PPC_SPLPAR */
+
#include
#ifdef CONFIG_SMP
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 0746d93..cf5992d 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -935,7 +936,7 @@ void __init initmem_init(void)
/*
* Reduce the possible NUMA nodes to the online NUMA nodes,
-* since we do not support node hotplug. This ensures that we
+* since we do not support node hotplug. This ensures that we
* lower the maximum NUMA node ID to what is actually present.
*/
nodes_and(node_possible_map, node_possible_map, node_online_map);
@@ -1179,11 +1180,32 @@ struct topology_update_data {
int new_nid;
};
+#defineTOPOLOGY_DEF_TIMER_SECS 60
+
static u8 vphn_cpu_change_counts[NR_CPUS][MAX_DISTANCE_REF_POINTS];
static cpumask_t cpu_associativity_changes_mask;
static int vphn_enabled;
static int prrn_enabled;
static void reset_topology_timer(void);
+static int topology_timer_secs = TOPOLOGY_DEF_TIMER_SECS;
+static int topology_inited;
+static int topology_update_needed;
+
+/*
+ * Change polling interval for associativity changes.
+ */
+int timed_topology_update(int nsecs)
+{
+ if (nsecs > 0)
+ topology_timer_secs = nsecs;
+ else
+ topology_timer_secs = TOPOLOGY_DEF_TIMER_SECS;
+
+ if (vphn_enabled)
+ reset_topology_timer();
+
+ return 0;
+}
/*
* Store the current values of the associativity change counters in the
@@ -1277,6 +1299,12 @@ static long vphn_get_associativity(unsigned long cpu,
"hcall_vphn() experienced a hardware fault "
"preventing VPHN. Disabling polling...\n");
stop_topology_update();
+ break;
+ case H_SUCCESS:
+ printk(KERN_INFO
+ "VPHN hcall succeeded. Reset polling...\n");
+ timed_topology_update(0);
+ break;
}
return rc;
@@ -1354,8 +1382,11 @@ int numa_update_cpu_topology(bool cpus_locked)
struct device *dev;
int weight, new_nid, i = 0;
- if (!prrn_enabled && !vphn_enabled)
+ if (!prrn_enabled && !vphn_enabled) {
+ if (!topology_inited)
+ topology_update_needed = 1;
return 0;
+ }
weight = cpumask_weight(&cpu_associativity_changes_mask);
if (!weight)
@@ -1394,6 +1425,8 @@ int numa_update_cpu_topology(bool cpus_locked)
cpumask_andnot(&cpu_associativity_changes_mask,
&cpu_associativity_changes_mask,
cpu_sibling_mask(cpu));
+ pr_info("Assoc chg gives same node %d for cpu%d\n",
+ new_nid, cpu);
cpu = cpu_last_thread_sibling(cpu);
continue;
}
@@ -1410,6 +1443,9 @@ int numa_update_cpu_topology(bool cpus_locked)
cpu = cpu_last_thread_sibling(cpu);
}
+ if (i)
+ updates[i-1].next = NULL;
+
pr_debug("Topology update for the following CPUs:\n");
if (cpumask_weight(&updated_cpus)) {
for (ud = &updates[0]; u
[PATCH V7 1/2] powerpc/hotplug: Ensure enough nodes avail for operations
powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU
or memory resources, it may occur that the new resources are to be
inserted into nodes that were not used for these resources at bootup.
In the kernel, any node that is used must be defined and initialized
at boot. In order to meet both needs, this patch adds a new kernel
command line option (numnodes=) for use by the PowerPC architecture-
specific code that defines the maximum number of nodes that the kernel
will ever need in its current hardware environment. The boot code that
initializes nodes for PowerPC will read this value and use it to ensure
that all of the desired nodes are setup in the 'node_possible_map', and
elsewhere.
Signed-off-by: Michael Bringmann
---
---
arch/powerpc/mm/numa.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index e6f742d..0746d93 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -60,10 +60,27 @@
static int n_mem_addr_cells, n_mem_size_cells;
static int form1_affinity;
+#define TOPOLOGY_DEF_NUM_NODES 0
#define MAX_DISTANCE_REF_POINTS 4
static int distance_ref_points_depth;
static const __be32 *distance_ref_points;
static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
+static int topology_num_nodes = TOPOLOGY_DEF_NUM_NODES;
+
+/*
+ * Topology-related early parameters
+ */
+static int __init early_num_nodes(char *p)
+{
+ if (!p)
+ return 1;
+
+ topology_num_nodes = memparse(p, &p);
+ dbg("topology num nodes = 0x%d\n", topology_num_nodes);
+
+ return 0;
+}
+early_param("numnodes", early_num_nodes);
/*
* Allocate node_to_cpumask_map based on number of available nodes
@@ -892,6 +909,18 @@ static void __init setup_node_data(int nid, u64 start_pfn,
u64 end_pfn)
NODE_DATA(nid)->node_spanned_pages = spanned_pages;
}
+static void __init setup_min_nodes(void)
+{
+ int i, l = topology_num_nodes;
+
+ for (i = 0; i < l; i++) {
+ if (!node_possible(i)) {
+ setup_node_data(i, 0, 0);
+ node_set(i, node_possible_map);
+ }
+ }
+}
+
void __init initmem_init(void)
{
int nid, cpu;
@@ -911,6 +940,8 @@ void __init initmem_init(void)
*/
nodes_and(node_possible_map, node_possible_map, node_online_map);
+ setup_min_nodes();
+
for_each_online_node(nid) {
unsigned long start_pfn, end_pfn;
Subject: [PATCH V7 0/2] powerpc/dlpar: Correct display of hot-add/hot-remove CPUs and memory
On Power systems with shared configurations of CPUs and memory, there are some issues with association of additional CPUs and memory to nodes when hot-adding resources. These patches address some of those problems. powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be defined and initialized at boot. In order to meet both needs, this patch adds a new kernel command line option (numnodes=) for use by the PowerPC architecture-specific code that defines the maximum number of nodes that the kernel will ever need in its current hardware environment. The boot code that initializes nodes for PowerPC will read this value and use it to ensure that all of the desired nodes are setup in the 'node_possible_map', and elsewhere. powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities information provided by the pHyp. The VPHN handling in Linux is disabled, if PRRN handling is present. Signed-off-by: Michael Bringmann Michael Bringmann (2): powerpc/hotplug: Add option to define max nodes allowing dynamic growth of resources. powerpc/numa: Update CPU topology when VPHN enabled --- Changes in V7: -- Fix conditional compile bug.
[PATCH 2/2] powerpc/fadump: use kstrtoint to handle sysfs store
Currently sysfs store handlers in fadump use if buf[0] == 'char'.
This means input "100foo" is interpreted as '1' and "01" as '0'.
Change to kstrtoint so leading zeroes and the like is handled in
expected way.
Signed-off-by: Michal Suchanek
---
arch/powerpc/kernel/fadump.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 5a7355381dac..241eff0b5f76 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1161,10 +1161,15 @@ static ssize_t fadump_release_memory_store(struct
kobject *kobj,
struct kobj_attribute *attr,
const char *buf, size_t count)
{
+ int input = -1;
+
if (!fw_dump.dump_active)
return -EPERM;
- if (buf[0] == '1') {
+ if (kstrtoint(buf, 0, &input))
+ return -EINVAL;
+
+ if (input == 1) {
/*
* Take away the '/proc/vmcore'. We are releasing the dump
* memory, hence it will not be valid anymore.
@@ -1198,21 +1203,25 @@ static ssize_t fadump_register_store(struct kobject
*kobj,
const char *buf, size_t count)
{
int ret = 0;
+ int input = -1;
if (!fw_dump.fadump_enabled || fdm_active)
return -EPERM;
+ if (kstrtoint(buf, 0, &input))
+ return -EINVAL;
+
mutex_lock(&fadump_mutex);
- switch (buf[0]) {
- case '0':
+ switch (input) {
+ case 0:
if (fw_dump.dump_registered == 0) {
goto unlock_out;
}
/* Un-register Firmware-assisted dump */
fadump_unregister_dump(&fdm);
break;
- case '1':
+ case 1:
if (fw_dump.dump_registered == 1) {
goto unlock_out;
}
--
2.10.2
[PATCH 1/2] powerpc/fadump: return 0 on re-registration
When fadump is already registered return success.
Currently EEXIST is returned which is difficult to handle race-free in
userspace when shell scripts are used. If multiple writers are trying to
write '1' there is no difference in whichever succeeds so just return 0
to all.
Signed-off-by: Michal Suchanek
---
arch/powerpc/kernel/fadump.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 436aedf195ab..5a7355381dac 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1214,7 +1214,6 @@ static ssize_t fadump_register_store(struct kobject *kobj,
break;
case '1':
if (fw_dump.dump_registered == 1) {
- ret = -EEXIST;
goto unlock_out;
}
/* Register Firmware-assisted dump */
--
2.10.2
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3
Larry Finger writes:
> On 06/23/2017 03:29 PM, Al Viro wrote:
>> On Fri, Jun 23, 2017 at 01:49:16PM -0500, Larry Finger wrote:
>>
BTW, could you try to check what happens if you kill the
if (__builtin_constant_p(n) && (n <= 8))
bits in raw_copy_{to,from}_user()? The usefulness of those (in
__copy_from_user()
originally) had always been dubious and the things are simpler without
them.
If _that_ turns out to cure breakage, I would be very surprised, though.
>>> Sorry I was gone so long. Installing jessie on this box resulted in a crash
>>> on boot. Lubuntu 14.04 yielded a desktop with a functioning cursor, but
>>> nothing else. Finally, Ubuntu 12.04 resulted in a working system. I hate
>>> Unity, but I guess I'm stuck for now.
>>
>> Ho-hum... Jessie is 3.16, so whatever is crashing there, it's something
>> different... Ubuntu 12.04 is what, 3.2?
>>
>>> I know how easy it is to screw up a long bisection by booting the wrong
>>> kernel. To help that problem and to work around the yaconf/yboot nonsense on
>>> the MAC, my /etc/yaconf has always had generic kernel stanzas with only
>>> default, old, and original kernels mentioned. From there I use a local
>>> script to finish a kernel installation by moving the default links to the
>>> old ones and creating the new default links pointing to the current kernel.
>>> With those long-tested scripts, I'm sure that I am booting the one I want.
>>>
>>> With the new installation, kernel 4.12-rc6 failed, as did 3448890c with the
>>> backported 46f401c4 added.
>>>
>>> Replacing "if (__builtin_constant_p(n) && (n <= 8))" with "if (0)" had no
>>> effect.
>>
>> OK, that simplifies things a bit. Just to make sure we are on the same page:
>>
>> * f2ed8bebee69 + cherry-pick of 46f401c4 boots (Ubuntu 12.04 userland)
>> * 3448890c32c3 + cherry-pick of 46f401c4 fails (Ubuntu 12.04 userland), ditto
>>with removal of constant-size bits in raw_copy_..._user(). Failure
>> appears
>>to be on udev getting EFAULT on some syscalls.
>> * straight Ubuntu 12.04 works
>> * jessie crashes on boot.
>
> I made a break through. If I turn off inline copy to/from users for 32-bit
> ppc
> with the following patch, then the system boots:
>
> diff --git a/arch/powerpc/include/asm/uaccess.h
> b/arch/powerpc/include/asm/uaccess.h
> index 5c0d8a8cdae5..1e6a8723f497 100644
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -267,12 +267,7 @@ do {
> \
> extern unsigned long __copy_tofrom_user(void __user *to,
> const void __user *from, unsigned long size);
>
> -#ifndef __powerpc64__
> -
> -#define INLINE_COPY_FROM_USER
> -#define INLINE_COPY_TO_USE
> -
> -#else /* __powerpc64__ */
> +#ifdef __powerpc64__
>
> static inline unsigned long
> raw_copy_in_user(void __user *to, const void __user *from, unsigned long n)
Thanks for debugging this.
I just sent a fix based on the above. Let me know if it doesn't work for
you.
cheers
Re: gcc 4.6.3 miscompile on ppc32 (was Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3)
Al Viro writes:
> On Sun, Jun 25, 2017 at 04:44:09PM -0500, Segher Boessenkool wrote:
>
>> Do you have a short stand-alone testcase? 4.6 is ancient, of course, but
>> the actual problem may still exist in more recent compilers (if it _is_
>> a compiler problem; if it's not, you *really* want to know :-) )
>
> Enjoy. At least 6.3 doesn't step into that. Look for mtctr in the resulting
> asm...
>
> cat <<'EOF' >a.c
...
I pointed creduce at that and got the version below, which I'm pretty
sure still exhibits the weird mtctr behaviour.
cheers
# cat input.c
struct {
void *iov_base;
unsigned iov_len;
} * c;
long v;
void *a;
int b;
unsigned bar();
foo(unsigned p1) {
unsigned d, e = p1;
if (p1 == 0)
goto out;
if (p1 > 4)
goto out;
if (__builtin_expect(!!(0, v && a), 1))
e = bar();
if (e)
barf(e);
if (e)
goto out;
d = 0;
for (; d < p1; d++) {
int f = c[d].iov_len;
if (__builtin_expect(c[d].iov_base && f, 0))
b = 4;
}
out:;
}
$ cat output.s
.file "input.c"
# rs6000/powerpc options: -mcpu=powerpc -msdata=data -G 8
# GNU C (GCC) version 4.6.3 (powerpc64-linux)
# compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.2
# ...
# Compiler executable checksum: 4b51a6b899110d06c9e3310ac66ad26c
.section".text"
.align 2
.globl foo
.type foo, @function
foo:
cmpwi 0,3,0 # tmp169, p1
stwu 1,-16(1)#,,
mflr 0 #,
stw 0,20(1) #,
beq- 0,.L9 #
cmplwi 7,3,4 #, tmp170, p1
bgt- 7,.L9 #
lis 9,v@ha # tmp172,
lwz 0,v@l(9) # v, v
cmpwi 7,0,0 #, tmp174, v
beq- 7,.L3 #
lis 9,a@ha # tmp176,
lwz 0,a@l(9) # a, a
cmpwi 7,0,0 #, tmp178, a
beq- 7,.L3 #
bl bar #
cmpwi 0,3,0 # tmp179, e
beq+ 0,.L4 #
.L3:
bl barf #
b .L9#
.L4:
lis 8,0x2000 #,
lis 9,c@ha # tmp181,
mtctr 8 # tmp192,
lwz 11,c@l(9)# c, c.3
lis 10,b@ha # tmp190,
li 9,0 # ivtmp.12,
li 0,4 # tmp191,
.L6:
lwzx 7,11,9 # MEM[base: c.3_14, index: ivtmp.12_25, offset: 0B],
MEM[base: c.3_14, index: ivtmp.12_25, offset: 0B]
add 8,11,9 # tmp182, c.3, ivtmp.12
lwz 8,4(8) # MEM[base: D.1310_21, offset: 4B], D.1287
cmpwi 7,7,0 #, tmp184, MEM[base: c.3_14, index: ivtmp.12_25,
offset: 0B]
beq+ 7,.L5 #
cmpwi 7,8,0 #, tmp185, D.1287
beq+ 7,.L5 #
stw 0,b@l(10)# b, tmp191
.L5:
addi 9,9,8 # ivtmp.12, ivtmp.12,
bdnz .L6 #
.L2:
.L9:
lwz 0,20(1) #,
addi 1,1,16 #,,
mtlr 0 #,
blr #
.size foo,.-foo
.globl b
.globl a
.globl v
.globl c
.section.sbss,"aw",@nobits
.align 2
.type b, @object
.size b, 4
b:
.zero 4
.type a, @object
.size a, 4
a:
.zero 4
.type v, @object
.size v, 4
v:
.zero 4
.type c, @object
.size c, 4
c:
.zero 4
.ident "GCC: (GNU) 4.6.3"
.section.note.GNU-stack,"",@progbits
[PATCH] powerpc/32: Avoid miscompilation w/GCC 4.6.3 - don't inline copy_to/from_user()
Larry Finger reported that his Powerbook G4 was no longer booting with v4.12-rc,
userspace was up but giving weird errors such as:
udevd[64]: starting version 175
udevd[64]: Unable to receive ctrl message: Bad address.
modprobe: chdir(4.12-rc1): No such file or directory
He bisected the problem to commit 3448890c32c3 ("powerpc: get rid of zeroing,
switch to RAW_COPY_USER").
Al identified that the problem is actually a miscompilation by GCC 4.6.3, which
is exposed by the above commit.
Al also pointed out that inlining copy_to/from_user() is probably of little or
no benefit, which is correct. Using Anton's copy_to_user benchmark, with a
pathological single byte copy, we see a small increase in performance
by *removing* inlining:
Before (inlined):
# time ./copy_to_user -w -l 1 -i 1000 ( x 3 )
real 0m22.063s
real 0m22.059s
real 0m22.076s
After:
# time ./copy_to_user -w -l 1 -i 1000 ( x 3 )
real 0m21.325s
real 0m21.299s
real 0m21.364s
So as a small performance improvement and to avoid the miscompilation, drop
inlining copy_to/from_user() on 32-bit.
Fixes: 3448890c32c3 ("powerpc: get rid of zeroing, switch to RAW_COPY_USER")
Reported-by: Larry Finger
Suggested-by: Al Viro
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/uaccess.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index 5c0d8a8cdae5..41e88d3ce36b 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -267,13 +267,7 @@ do {
\
extern unsigned long __copy_tofrom_user(void __user *to,
const void __user *from, unsigned long size);
-#ifndef __powerpc64__
-
-#define INLINE_COPY_FROM_USER
-#define INLINE_COPY_TO_USER
-
-#else /* __powerpc64__ */
-
+#ifdef __powerpc64__
static inline unsigned long
raw_copy_in_user(void __user *to, const void __user *from, unsigned long n)
{
--
2.7.4
Re: [PATCH] powerpc/ipic: Support edge on IRQ0
Index 48 equals IRQ0 in developpers manual
Am 26.06.2017 um 14:46 schrieb Michael Ellerman:
Scott Wood writes:
External IRQ0 has the same capabilities as the other IRQ1-7 and is
handled by the same register IPIC_SEPNR. When this register is not
specified for "ack" in "ipic_info", you cannot configure this IRQ as
IRQ_TYPE_EDGE_FALLING. This oversight was probably due to the
non-contiguous hwirq numbering of IRQ0 in the IPIC.
I don't know this code at all, but nothing in the diff says "IRQ0" to
me?
cheers
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index f267ee0afc08..16f1edd78c40 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -315,6 +315,7 @@ static struct ipic_info ipic_info[] = {
.prio_mask = 7,
},
[48] = {
+ .ack= IPIC_SEPNR,
.mask = IPIC_SEMSR,
.prio = IPIC_SMPRR_A,
.force = IPIC_SEFCR,
--
2.11.0
--
i. A.
Jürgen Schindele
Softwareentwicklung
PSI Nentec GmbH
Greschbachstraße 12
76229 Karlsruhe
Deutschland
Telefon: +49 721 94249-51
Telefax: +49 721 94249-10
schind...@nentec.de
www.nentec.de
Geschäftsführung: Klaus Becker, Roland Knapp
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 107658
Diese E-Mail enthält vertrauliche oder rechtlich geschützte Informationen. Wenn
Sie nicht der vorgesehene Empfänger sind, informieren Sie bitte sofort den
Absender und löschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail
oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet.
The information contained in this message is confidential or protected by law.
If you are not the intended recipient, please contact the sender and delete
this message. Any unauthorised copying of this message or unauthorised
distribution of the information contained herein is prohibited.
Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
Kees Cook writes: > On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman > wrote: >> Kees Cook writes: >> >>> Now that explicitly executed loaders are loaded in the mmap region, >>> position PIE binaries lower in the address space to avoid possible >>> collisions with mmap or stack regions. For 64-bit, align to 4GB to >>> allow runtimes to use the entire 32-bit address space for 32-bit >>> pointers. >> >> The change log and subject are a bit out of whack with the actual patch >> because previously we used 512MB. >> >> How about? >> >> powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB >> >> Now that explicitly executed loaders are loaded in the mmap region, >> we have more freedom to decide where we position PIE binaries in the >> address space to avoid possible collisions with mmap or stack regions. >> >> For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit >> address space for 32-bit pointers. On 32-bit use 4MB. > > Good idea, thanks. I'll resend the series with the commit logs updated. > >> Is there any particular reasoning behind the 4MB value on 32-bit? > > So, I've dug around a bit on this, and I *think* the rationale is to > avoid mapping a possible 4MB page table entry when it won't be using > at least a portion near the lower end (NULL address area covered > blocked by mmap_min_addr). It seems to be mainly tradition, though. OK, that is obscure, especially for CPUs that don't have a 4MB page size. But consistency across arches is probably best regardless. cheers
Re: [PATCH] powerpc/smp: Do not BUG_ON if invalid CPU during kick
Santosh Sivaraj writes:
> During secondary start, we do not need to BUG_ON if an invalid CPU number
> is passed. We alreay print an error if secondary cannot be started, so
^
d
> just return an error instead.
>
> Signed-off-by: Santosh Sivaraj
> ---
> arch/powerpc/kernel/smp.c| 3 ++-
> arch/powerpc/platforms/cell/smp.c| 3 ++-
> arch/powerpc/platforms/powernv/smp.c | 3 ++-
> arch/powerpc/platforms/pseries/smp.c | 3 ++-
This looks good to me ...
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index df2a416..05bf583 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -112,7 +112,8 @@ int smp_generic_cpu_bootable(unsigned int nr)
> #ifdef CONFIG_PPC64
> int smp_generic_kick_cpu(int nr)
> {
> - BUG_ON(nr < 0 || nr >= NR_CPUS);
> + if (nr < 0 || nr >= NR_CPUS)
> + return -EINVAL;
Except that these checks should all use nr_cpu_ids AFAICS.
I think they were just written before nr_cpu_ids existed.
Can you send me an incremental patch to switch them to nr_cpu_ids?
cheers
Re: [PATCH] powerpc/ipic: Support edge on IRQ0
Scott Wood writes:
> External IRQ0 has the same capabilities as the other IRQ1-7 and is
> handled by the same register IPIC_SEPNR. When this register is not
> specified for "ack" in "ipic_info", you cannot configure this IRQ as
> IRQ_TYPE_EDGE_FALLING. This oversight was probably due to the
> non-contiguous hwirq numbering of IRQ0 in the IPIC.
I don't know this code at all, but nothing in the diff says "IRQ0" to
me?
cheers
> diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
> index f267ee0afc08..16f1edd78c40 100644
> --- a/arch/powerpc/sysdev/ipic.c
> +++ b/arch/powerpc/sysdev/ipic.c
> @@ -315,6 +315,7 @@ static struct ipic_info ipic_info[] = {
> .prio_mask = 7,
> },
> [48] = {
> + .ack= IPIC_SEPNR,
> .mask = IPIC_SEMSR,
> .prio = IPIC_SMPRR_A,
> .force = IPIC_SEFCR,
> --
> 2.11.0
Re: [PATCH] powerpc/sysfs: Expose MMCR2 spr in sysfs
Madhavan Srinivasan writes: > Monitor Mode Control Register 2 (MMCR2) is a 64-bit > register that contains 9-bit control fields for > controlling the operation of PMC1 - PMC6. Patch > to expose the MMCR2 spr in sysfs. > > Signed-off-by: Madhavan Srinivasan > --- > arch/powerpc/kernel/sysfs.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c > index 4437c70c7c2b..587eb3a7b5da 100644 > --- a/arch/powerpc/kernel/sysfs.c > +++ b/arch/powerpc/kernel/sysfs.c > @@ -482,6 +482,7 @@ SYSFS_PMCSETUP(pmc7, SPRN_PMC7); > SYSFS_PMCSETUP(pmc8, SPRN_PMC8); > > SYSFS_PMCSETUP(mmcra, SPRN_MMCRA); > +SYSFS_PMCSETUP(mmcr2, SPRN_MMCR2); We already have it under an #ifdef: #ifdef HAS_PPC_PMC_G4 SYSFS_PMCSETUP(mmcr2, SPRN_MMCR2); #endif Can you reuse that somehow, or rework the #ifdefs. cheers
ps3 linux: os_area_queue_work_handler: Could not update FLASH ROM
Dear Sir, I'd like to have help and ask some. 1) Is it normal for os_area_queue_work_handler: Could not update FLASH ROM? 2) My Date time is not correct. Is the problem is not able to update os-area data? Here below is my rtc time problem. RTC time is not proper value (lower than it should be). (For GameOS , Date-Time is OK.) Here is what I've tried 1) lv1_get_rtc gets 205943663 (11 Jul 1976) 2) saved_params.rtc_diff always is 946684800 (205943663+946684800) = 11 Jul 2006 So every time, my Linux is booted, my year says 2006 and causes problem on clock skew. 3) if I add 345746286 to rtc in read_rtc function in arch/powerpc/platforms/ps3/time.c and drivers/rtc/rtc-ps3.c (205943663+946684800+345746286) = 25 Jun 2017 My boot time and date is acceptable for my temporary use. Do you have any proper solution? I don't want to modify source for my one rtc time problem? Best regards, Sombat T.
Re: [PATCH v5 2/2] powerpc/fadump: update documentation about 'fadump_append=' parameter
Hello, On Tue, 20 Jun 2017 21:14:08 +0530 Hari Bathini wrote: > On Friday 09 June 2017 05:34 PM, Michal Suchánek wrote: > > On Thu, 8 Jun 2017 23:30:37 +0530 > > Hari Bathini wrote: > >> On Monday 15 May 2017 02:59 PM, Michal Suchánek wrote: > >>> On Mon, 15 May 2017 12:59:46 +0530 > >>> Hari Bathini wrote: > On Friday 12 May 2017 09:12 PM, Michal Suchánek wrote: > > On Fri, 12 May 2017 15:15:33 +0530 > > Hari Bathini wrote: > >> On Thursday 11 May 2017 06:46 PM, Michal Suchánek wrote: > >>> On Thu, 11 May 2017 02:00:11 +0530 > >>> Hari Bathini wrote: > On Wednesday 10 May 2017 09:31 PM, Michal Suchánek wrote: > > On Wed, 03 May 2017 23:52:52 +0530 > > Hari Bathini wrote: > > > >> With the introduction of 'fadump_append=' parameter to pass > >> additional parameters to fadump (capture) kernel, update > >> documentation about it. > >> > >> Signed-off-by: Hari Bathini > >> --- > >> > >> > > Writing your own deficient parser for comma separated > > arguments when perfectly fine parser for space separated > > quoted arguments exists in the kernel and the bootloader > > does not seem like a good idea to me. > Couple of things that prompted me for v5 are: > 1. Using parse_early_options() limits the kind of > parameters that can be passed to fadump capture kernel. > Passing parameters like systemd.unit= & udev.childern.max= > has no effect with v4. Updating > boot_command_line parameter, when fadump is active, > seems a better alternative. > > 2. Passing space-separated quoted arguments is not > working as intended with lilo. Updating bootloader with the > below entry in /etc/lilo.conf file results in a missing > append entry in /etc/yaboot.conf file. > > append = "quiet sysrq=1 insmod=sym53c8xx > insmod=ipr crashkernel=512M-:256M fadump_append=\"nr_cpus=1 > numa=off udev.children-max=2\"" > >>> Meaning that a script that emulates LILO semantics on top of > >>> yaboot which is completely capable of passing qouted space > >>> separated arguments fails. IMHO it is more reasonable to fix > >>> the script or whatever adaptation layer or use yaboot > >>> directly than working around bug in said script by > >>> introducing a new argument parser in the kernel. > >>> > >>> > >> The intention with this patch is to replace > >> > >> "root=/dev/sda2 ro fadump_append=nr_cpus=1,numa=off > >> crashkernel=1024M" > >> > >> with > >> > >> "root=/dev/sda2 ro nr_cpus=1 numa=off crashkernel=1024M" > >> > >> when kernel is booting for dump capture. > >> While parse_args() is making parsing relatively easy, the main > >> idea is to replace parameters as above when fadump capture kernel > >> is booting. The code is relatively complicated to replace > >> parameters using space-separated > >> quoted string even though parse_args() may parse them easily. > >> Comma-separated > >> list was easier to implement and seemed less error prone for > >> replacing parameters. > > > > You can still do that relatively easily. parse_args() gives you the > > content of fadump_capture argument. You should probably add a > > variant that gives you also the position of the fadump_capture > > argument in case user specified it multiple times - picking the > > wrong one would cause errors. > > There is no denying that this can be done with the use of > parse_args() function. > But my contention is a custom parser is no more error prone, > considering it only has to search/replace commas in > fadump_extra_args= till the first occurrence of space/nul, without > having to deal with the naunces of parse_args() function. If you do that you 1) introduce new parser which is error-prone even for not very complex parsers 2) does not handle quoting properly meaning that a) the passed arguments cannot include a comma (which is the case for many existing kernel parameters) b) your parser, parse_args and any parser analyzing the commandline before you replace the arguments do not agree on the content and length of the fadump_extra_args argument 3) you introduce completely new syntax for arguments which the user has to research and understand for no good reason > Also, to > get the last occurence, could use something like > get_last_crashkernel() instead of adding a variant to parse_args(). Why are you talking about last occurence all the time? Does that mean that if user specifies fadump_extra_args in both the 'default' and 'extra' kernel arguments to the grub configuration script only the one from 'extra' arguments will be expanded and the on from 'default' arguments will be just left there? Why? > > > Then you can
Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64
On 06/22/17 19:48, Logan Gunthorpe wrote: > Now that we can expect iowrite64 to always exist the hack is no longer > necessary so we just call iowrite64 directly. > > Signed-off-by: Logan Gunthorpe > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: David Airlie Acked-by: Jyri Sarha And thanks! > --- > drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h > b/drivers/gpu/drm/tilcdc/tilcdc_regs.h > index e9ce725698a9..0b901405f30a 100644 > --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h > +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h > @@ -133,13 +133,7 @@ static inline void tilcdc_write64(struct drm_device > *dev, u32 reg, u64 data) > struct tilcdc_drm_private *priv = dev->dev_private; > void __iomem *addr = priv->mmio + reg; > > -#ifdef iowrite64 > iowrite64(data, addr); > -#else > - __iowmb(); > - /* This compiles to strd (=64-bit write) on ARM7 */ > - *(u64 __force *)addr = __cpu_to_le64(data); > -#endif > } > > static inline u32 tilcdc_read(struct drm_device *dev, u32 reg) >
Re: [PATCH 1/1] futex: remove duplicated code and fix UB
On Mon, Jun 26, 2017 at 02:02:31PM +0200, Jiri Slaby wrote:
> On 06/23/2017, 09:51 AM, Thomas Gleixner wrote:
> > On Wed, 21 Jun 2017, Jiri Slaby wrote:
> >> diff --git a/arch/arm64/include/asm/futex.h
> >> b/arch/arm64/include/asm/futex.h
> >> index f32b42e8725d..5bb2fd4674e7 100644
> >> --- a/arch/arm64/include/asm/futex.h
> >> +++ b/arch/arm64/include/asm/futex.h
> >> @@ -48,20 +48,10 @@ do {
> >> \
> >> } while (0)
> >>
> >> static inline int
> >> -futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
> >
> > That unsigned int seems to be a change from the arm64 tree in next. It's
> > not upstream and it'll cause a (easy to resolve) conflict.
>
> Ugh, I thought the arm64 is in upstream already. Note that this patch
> just takes what is in this arm64 fix and makes it effective for all
> architectures. So I will wait with v2 until it merges upstream.
>
> So, Will, will you incorporate Thomas' comments into your arm64 fix?
I wasn't planning to (it's already queued and I think they're just cosmetic
changes). The easiest thing is probably for you to make the changes in the
generic version when you post v2.
Will
Re: [PATCH 1/1] futex: remove duplicated code and fix UB
On 06/23/2017, 09:51 AM, Thomas Gleixner wrote:
> On Wed, 21 Jun 2017, Jiri Slaby wrote:
>> diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
>> index f32b42e8725d..5bb2fd4674e7 100644
>> --- a/arch/arm64/include/asm/futex.h
>> +++ b/arch/arm64/include/asm/futex.h
>> @@ -48,20 +48,10 @@ do {
>> \
>> } while (0)
>>
>> static inline int
>> -futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
>
> That unsigned int seems to be a change from the arm64 tree in next. It's
> not upstream and it'll cause a (easy to resolve) conflict.
Ugh, I thought the arm64 is in upstream already. Note that this patch
just takes what is in this arm64 fix and makes it effective for all
architectures. So I will wait with v2 until it merges upstream.
So, Will, will you incorporate Thomas' comments into your arm64 fix?
...
> Yes, we probably can't change that anymore, but at least we should make it
> very explicit and add a comment to that effect.
Something like this or do you want a comment yet?
unsigned int op = (encoded_op & 0x7000) >> 28;
unsigned int cmp =(encoded_op & 0x0f00) >> 24;
int oparg = sign_extend32((encoded_op & 0x00fff000) >> 12, 12);
int cmparg = sign_extend32(encoded_op & 0x0fff, 12);
thanks,
--
js
suse labs
Re: [V3] cxl: Fixes for Coherent Accelerator Interface Architecture 2.0
On Tue, 2017-06-13 at 15:41:05 UTC, Christophe Lombard wrote: > A previous set of patches "cxl: Add support for Coherent Accelerator > Interface Architecture 2.0" has introduced a new support for the CAPI > cards. These patches have been tested on Simulation environment and > quite a bit of them have been tested on real hardware. > > This patch brings new fixes after a series of tests carried out on > new equipment: > * Add POWER9 definition. > * Re-enable any masked interrupts when the AFU is not activated after > resetting the AFU. > * Remove the api cxl_is_psl8/9 which is no longer useful. > * Do not dump CAPI1 registers. > * Rewrite cxl_is_page_fault() function. > * Do not register slb callack on P9. > > Signed-off-by: Christophe Lombard > Acked-by: Frederic Barrat Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/797625deaedd9a0621376817db2813 cheers
Re: [PATCH 1/7] drm/tilcdc: don't use volatile with iowrite64
On 06/22/17 19:48, Logan Gunthorpe wrote:
> This is a prep patch for adding a universal iowrite64.
>
> The patch is to prevent compiler warnings when we add iowrite64 that
> would occur because there is an unnecessary volatile in this driver.
>
> Signed-off-by: Logan Gunthorpe
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: David Airlie
Acked-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_regs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> index 9d528c0a67a4..e9ce725698a9 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> @@ -131,14 +131,14 @@ static inline void tilcdc_write(struct drm_device *dev,
> u32 reg, u32 data)
> static inline void tilcdc_write64(struct drm_device *dev, u32 reg, u64 data)
> {
> struct tilcdc_drm_private *priv = dev->dev_private;
> - volatile void __iomem *addr = priv->mmio + reg;
> + void __iomem *addr = priv->mmio + reg;
>
> #ifdef iowrite64
> iowrite64(data, addr);
> #else
> __iowmb();
> /* This compiles to strd (=64-bit write) on ARM7 */
> - *(volatile u64 __force *)addr = __cpu_to_le64(data);
> + *(u64 __force *)addr = __cpu_to_le64(data);
> #endif
> }
>
>
Re: clean up and modularize arch dma_mapping interface V2
On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote: > I think we still need to do it. For example we have a bunch new "funky" > cases. I have no plan to do away with the selection - I just want a better interface than the current one.
Re: [PATCH 1/2] fsl/fman: propagate dma_ops
Hi Madalin,
On Mon, Jun 19, 2017 at 5:04 PM, Madalin Bucur wrote:
> Make sure dma_ops are set, to be later used by the Ethernet driver.
>
> Signed-off-by: Madalin Bucur
> ---
> drivers/net/ethernet/freescale/fman/mac.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/fman/mac.c
> b/drivers/net/ethernet/freescale/fman/mac.c
> index 0b31f85..6e67d22f 100644
> --- a/drivers/net/ethernet/freescale/fman/mac.c
> +++ b/drivers/net/ethernet/freescale/fman/mac.c
> @@ -623,6 +623,8 @@ static struct platform_device *dpaa_eth_add_device(int
> fman_id,
> goto no_mem;
> }
>
> + set_dma_ops(&pdev->dev, get_dma_ops(priv->dev));
> +
When compile-testing with f NO_DMA=y:
drivers/net/ethernet/freescale/fman/mac.c: In function
‘dpaa_eth_add_device’:
drivers/net/ethernet/freescale/fman/mac.c:626: error: implicit
declaration of function ‘set_dma_ops’
Reverting commit 5567e989198b5a8d fixes this regression in v4.12-rc7.
Why is this change needed?
There's no single other call to the DMA API in this file?
If it's really needed, can't set_dma_ops() be called from the driver that
needs it, cfr. your other patch "[PATCH 2/2] dpaa_eth: reuse the dma_ops
provided by the FMan MAC device"?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: new dma-mapping tree, was Re: clean up and modularize arch dma_mapping interface V2
On Wed, Jun 21, 2017 at 03:32:39PM +0200, Marek Szyprowski wrote: > linux-next > was a side effect of that. I think that for now it can be dropped in favor > of > Christoph's tree. I can also do some review and help in maintainers work if > needed, although I was recently busy with other stuff. > > Christoph: Could you add me to your MAINTAINERS patch, so further > dma-mapping > related patches hopefully will be also CC: to me? I've added you as a co-maintainer, thanks!
