Re: [PATCH 1/2] irqdomain: add support for creating a continous mapping
On 11/03/2014 11:18 PM, Scott Wood wrote: > Is it really necessary for the virqs to be contiguous? How is the > availability of multiple MSIs communicated to the driver? Is there an > example of a driver that currently uses multiple MSIs? I used this in PCI and after enabling 2^x, I allocated an continuous block starting at virq. There is no way of communicating this in any other way. The first irq number is saved in pci_dev->irq and the remaining have to follow. Take a look at drivers/ata/ahci.c and you will see: - pci_msi_vec_count() for number of irqs - pci_enable_msi_block() to allocate the number of irqs - pci_enable_msi() (no X) - ahci_host_activate() does request_threaded_irq() for pdev->irq and loops "number of ports" times which matches number of number of irqs (or is less then). Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] of/platform: Move platform devices under /sys/devices/platform
Currently the devices created by drivers/of/platform.c get created at the root of /sys/devices. This goes against the typical pattern for sysfs where the top level /sys/devices structure contains categories of devices, and the structure of devices is placed below that. To fix this, make the code in drivers/of/platform.c follow the drivers/base/platform.c behaviour, and use &platform_bus as the default parent for all new platform_devices and amba_devices. This change has been discussed for a long time, but nobody has actually acted on it. Userspace code that expects to find devices under a fixed /sys/devices/... path will be affected. It isn't /supposed/ to do that, but if anyone complains then I'll add a default-off workaround option to put them back into the root. Signed-off-by: Grant Likely Cc: Rob Herring Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Benjamin Herrenschmidt --- drivers/of/platform.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 3b64d0bf5bba..7c6771986c06 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -138,7 +138,7 @@ struct platform_device *of_device_alloc(struct device_node *np, } dev->dev.of_node = of_node_get(np); - dev->dev.parent = parent; + dev->dev.parent = parent ? : &platform_bus; if (bus_id) dev_set_name(&dev->dev, "%s", bus_id); @@ -291,7 +291,7 @@ static struct amba_device *of_amba_device_create(struct device_node *node, /* setup generic device info */ dev->dev.of_node = of_node_get(node); - dev->dev.parent = parent; + dev->dev.parent = parent ? : &platform_bus; dev->dev.platform_data = platform_data; if (bus_id) dev_set_name(&dev->dev, "%s", bus_id); -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] DT: add MDIO node for FMan node
From: Shaohui Xie
This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
Signed-off-by: Shaohui Xie
---
based on http://patchwork.ozlabs.org/patch/390351/
for 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
.../devicetree/bindings/powerpc/fsl/fman.txt | 69 ++
1 file changed, 69 insertions(+)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
index da8e5f2..83c2f14 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
@@ -7,6 +7,7 @@ CONTENTS
- FMan MURAM Node
- FMan dTSEC/XGEC/mEMAC Node
- FMan IEEE 1588 Node
+ - FMan MDIO Node
- Example
=
@@ -352,6 +353,67 @@ ptp-timer@fe000 {
};
=
+FMan MDIO Node
+
+DESCRIPTION
+
+The MDIO is a bus to which the PHY devices are connected.
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type:
+ Definition: A standard property.
+ Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
+ Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
+ Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
+ FMan v3.
+
+- reg
+ Usage: required
+ Value type:
+ Definition: A standard property.
+
+- bus-frequency
+ Usage: optional
+ Value type:
+ Definition: Default MDIO bus clock speed.
+
+- interrupts
+ Usage: optional
+ Value type:
+ Definition: MDIO controller event interrupts.
+
+- type
+ Usage: required for FMan v3
+ Value type:
+ Definition: A standard property.
+ FMan v3 has internal MDIO for internal PCS(Physical Coding
+ Sublayer) PHYs and external MDIO for external PHYs.
+ The settings and programming routines for internal/external
+ MDIO are different. Must include "internal" for internal MDIO,
+ must include "external" for external MDIO.
+
+EXAMPLE
+
+Example for FMan v2:
+
+mdio@f1000 {
+ compatible = "fsl,fman-xmdio";
+ reg = <0xf1000 0x1000>;
+};
+
+Example for FMan v3:
+
+mdio@fd000 {
+ compatible = "fsl,fman-memac-mdio";
+ reg = <0xfd000 0x1000>;
+ bus-frequency = <250>;
+ type = "external";
+};
+
+=
Example
fman@40 {
@@ -526,4 +588,11 @@ fman@40 {
compatible = "fsl,fman-ptp-timer";
reg = <0xfe000 0x1000>;
};
+
+ mdio@fd000 {
+ compatible = "fsl,fman-memac-mdio";
+ reg = <0xfd000 0x1000>;
+ bus-frequency = <250>;
+ type = "external";
+ };
};
--
1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of/platform: Move platform devices under /sys/devices/platform
On Tue, 2014-11-04 at 10:45 +, Grant Likely wrote: > Currently the devices created by drivers/of/platform.c get created at > the root of /sys/devices. This goes against the typical pattern for > sysfs where the top level /sys/devices structure contains categories of > devices, and the structure of devices is placed below that. To fix this, > make the code in drivers/of/platform.c follow the drivers/base/platform.c > behaviour, and use &platform_bus as the default parent for all new > platform_devices and amba_devices. > > This change has been discussed for a long time, but nobody has actually > acted on it. Userspace code that expects to find devices under a fixed > /sys/devices/... path will be affected. It isn't /supposed/ to do that, > but if anyone complains then I'll add a default-off workaround option to > put them back into the root. Ack ! Cheers, Ben. > > Signed-off-by: Grant Likely > Cc: Rob Herring > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman > Cc: Benjamin Herrenschmidt > --- > drivers/of/platform.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/of/platform.c b/drivers/of/platform.c > index 3b64d0bf5bba..7c6771986c06 100644 > --- a/drivers/of/platform.c > +++ b/drivers/of/platform.c > @@ -138,7 +138,7 @@ struct platform_device *of_device_alloc(struct > device_node *np, > } > > dev->dev.of_node = of_node_get(np); > - dev->dev.parent = parent; > + dev->dev.parent = parent ? : &platform_bus; > > if (bus_id) > dev_set_name(&dev->dev, "%s", bus_id); > @@ -291,7 +291,7 @@ static struct amba_device *of_amba_device_create(struct > device_node *node, > > /* setup generic device info */ > dev->dev.of_node = of_node_get(node); > - dev->dev.parent = parent; > + dev->dev.parent = parent ? : &platform_bus; > dev->dev.platform_data = platform_data; > if (bus_id) > dev_set_name(&dev->dev, "%s", bus_id); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of/platform: Move platform devices under /sys/devices/platform
On Tue, Nov 04, 2014 at 10:45:20AM +, Grant Likely wrote: > Currently the devices created by drivers/of/platform.c get created at > the root of /sys/devices. This goes against the typical pattern for > sysfs where the top level /sys/devices structure contains categories of > devices, and the structure of devices is placed below that. To fix this, > make the code in drivers/of/platform.c follow the drivers/base/platform.c > behaviour, and use &platform_bus as the default parent for all new > platform_devices and amba_devices. > > This change has been discussed for a long time, but nobody has actually > acted on it. Userspace code that expects to find devices under a fixed > /sys/devices/... path will be affected. It isn't /supposed/ to do that, > but if anyone complains then I'll add a default-off workaround option to > put them back into the root. > > Signed-off-by: Grant Likely > Cc: Rob Herring > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman Acked-by: Greg Kroah-Hartman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
On Oct 31, 2014, at 2:24 AM, qiang.z...@freescale.com wrote:
> On Oct 30, 2014, at 9:37 AM, Kumar Gala wrote:
>
>
>> -Original Message-
>> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>> Sent: Thursday, October 30, 2014 9:37 PM
>> To: Zhao Qiang-B45475
>> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood
>> Scott-B07421; Xie Xiaobo-R63061
>> Subject: Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to
>> drivers/soc
>>
>>
>> On Oct 30, 2014, at 2:31 AM, Zhao Qiang wrote:
>>
>>> LS1 is arm cpu and it has qe ip block.
>>> move qe code from platform directory to public directory.
>>>
>>> QE is an IP block integrates several comunications peripheral
>>> controllers. It can implement a variety of applications, such as uart,
>>> usb and tdm and so on.
>>>
>>> Signed-off-by: Zhao Qiang
>>> ---
>>> Changes for v2:
>>> - move code to driver/soc
>>> Changes for v3:
>>> - change drivers/soc/qe to drivers/soc/fsl-qe
>>>
>>> arch/powerpc/Kconfig | 2 -
>>> arch/powerpc/platforms/83xx/km83xx.c | 4 +-
>>> arch/powerpc/platforms/83xx/misc.c | 2 +-
>>> arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
>>> arch/powerpc/platforms/85xx/common.c | 2 +-
>>> arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
>>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
>>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
>>> arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
>>> arch/powerpc/platforms/Kconfig | 19 -
>>> arch/powerpc/sysdev/Makefile | 1 -
>>> arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
>>> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
>>> drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
>>> drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
>>> drivers/soc/Kconfig| 2 +
>>> drivers/soc/Makefile | 1 +
>>> drivers/soc/fsl-qe/Kconfig | 45
>> ++
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile | 0
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c| 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c | 4 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.h | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_io.c | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/ucc.c | 6 +--
>>> .../qe_lib => drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
>>> .../qe_lib => drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/usb.c | 4 +-
>>> drivers/spi/spi-fsl-cpm.c | 2 +-
>>> drivers/tty/serial/ucc_uart.c | 2 +-
>>> drivers/usb/gadget/fsl_qe_udc.c| 2 +-
>>> drivers/usb/host/fhci-hcd.c| 2 +-
>>> drivers/usb/host/fhci-hub.c| 2 +-
>>> drivers/usb/host/fhci-sched.c | 2 +-
>>> drivers/usb/host/fhci.h| 4 +-
>>> .../include/asm => include/linux/fsl}/immap_qe.h | 0
>>> .../powerpc/include/asm => include/linux/fsl}/qe.h | 2 +-
>>> .../include/asm => include/linux/fsl}/qe_ic.h | 0
>>> .../include/asm => include/linux/fsl}/ucc.h| 4 +-
>>> .../include/asm => include/linux/fsl}/ucc_fast.h | 6 +--
>>> .../include/asm => include/linux/fsl}/ucc_slow.h | 6 +--
>>> 44 files changed, 112 insertions(+), 113 deletions(-) delete mode
>>> 100644 arch/powerpc/sysdev/qe_lib/Kconfig
>>> create mode 100644 drivers/soc/fsl-qe/Kconfig rename
>>> {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile (100%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c (99%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c (99%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c
>>> (99%) rename {arch/powerpc/sysdev/qe_lib =>
>>> drivers/soc/fsl-qe}/qe_ic.h (98%) rename {arch/powerpc/sysdev/qe_lib
>>> => drivers/soc/fsl-qe}/qe_io.c (99%) rename
>>> {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc.c (98%) rename
>>> {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc_fast.c (98%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc_slow.c
>>> (98%) rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/usb.c
>>> (96%) rename {arch/powerpc/include/asm =>
>>> include/linux/fsl}/immap_qe.h (100%) rename {arch/powerpc/include/asm
>>> => include/linux/fsl}/qe.h (99%) rename {arch/powerpc/include/asm =>
>>> include/linux/fsl}/qe_ic.h (100%) rename {arch/powerpc/include/asm =>
>>> include/lin
[RFC PATCH] make CONFIG_STRICT_DEVMEM a core non-debug feature
Most, but not all, architectures supporting CONFIG_STRICT_DEVMEM treat it as a debug feature - although its function is pretty much the opposite of debug. This patch deletes all architecture-specific config options and moves the option to core code, as a non-debug option. Signed-off-by: Leif Lindholm --- Apologies for wide distribution, but this is a bit invasive, if trivial. arch/Kconfig |3 +++ arch/arm/Kconfig |1 + arch/arm/Kconfig.debug | 14 -- arch/arm64/Kconfig |1 + arch/arm64/Kconfig.debug | 14 -- arch/powerpc/Kconfig |1 + arch/powerpc/Kconfig.debug | 12 arch/s390/Kconfig|1 + arch/s390/Kconfig.debug | 12 arch/tile/Kconfig|4 +--- arch/unicore32/Kconfig |1 + arch/unicore32/Kconfig.debug | 14 -- arch/x86/Kconfig |1 + arch/x86/Kconfig.debug | 17 - drivers/char/Kconfig | 16 15 files changed, 26 insertions(+), 86 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 05d7a8a..e5f4f03 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -484,6 +484,9 @@ config HAVE_IRQ_EXIT_ON_IRQ_STACK This spares a stack switch and improves cache usage on softirq processing. +config HAVE_ARCH_RESTRICTED_DEVMEM + bool + # # ABI hall of shame # diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 89c4b5c..e04910f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -30,6 +30,7 @@ config ARM select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT) select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL select HAVE_ARCH_KGDB + select HAVE_ARCH_RESTRICTED_DEVMEM if MMU select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT) select HAVE_ARCH_TRACEHOOK select HAVE_BPF_JIT diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index d8f6a2e..2a02a7d 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -14,20 +14,6 @@ config ARM_PTDUMP kernel. If in doubt, say "N" -config STRICT_DEVMEM - bool "Filter access to /dev/mem" - depends on MMU - ---help--- - If this option is disabled, you allow userspace (root) access to all - of memory, including kernel and userspace memory. Accidental - access to this is obviously disastrous, but specific access can - be used by people debugging the kernel. - - If this option is switched on, the /dev/mem file only allows - userspace access to memory mapped peripherals. - - If in doubt, say Y. - # RMK wants arm kernels compiled with frame pointers or stack unwinding. # If you know what you are doing and are willing to live without stack # traces, you can get a slightly smaller kernel by setting this option to diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 9532f8d..90abbb2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -37,6 +37,7 @@ config ARM64 select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_KGDB + select HAVE_ARCH_RESTRICTED_DEVMEM if MMU select HAVE_ARCH_TRACEHOOK select HAVE_BPF_JIT select HAVE_C_RECORDMCOUNT diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug index 0a12933..d0036dd 100644 --- a/arch/arm64/Kconfig.debug +++ b/arch/arm64/Kconfig.debug @@ -6,20 +6,6 @@ config FRAME_POINTER bool default y -config STRICT_DEVMEM - bool "Filter access to /dev/mem" - depends on MMU - help - If this option is disabled, you allow userspace (root) access to all - of memory, including kernel and userspace memory. Accidental - access to this is obviously disastrous, but specific access can - be used by people debugging the kernel. - - If this option is switched on, the /dev/mem file only allows - userspace access to memory mapped peripherals. - - If in doubt, say Y. - config PID_IN_CONTEXTIDR bool "Write the current PID to the CONTEXTIDR register" help diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 88eace4..cd35068 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -148,6 +148,7 @@ config PPC select HAVE_ARCH_AUDITSYSCALL select ARCH_SUPPORTS_ATOMIC_RMW select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN + select HAVE_ARCH_RESTRICTED_DEVMEM config GENERIC_CSUM def_bool CPU_LITTLE_ENDIAN diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug index ec2e40f..6f11382 100644 --- a/arch/powerpc/Kconfig.debug +++ b/arch/powerpc/Kconfig.debug @@ -334,18 +334,6 @@ config PPC_EARLY_DEBUG_CPM_ADDR platform probing is done, all platforms selected must share the same address. -config STRICT_DEVMEM - def_bool y -
Re: [RFC PATCH] make CONFIG_STRICT_DEVMEM a core non-debug feature
On Tue, Nov 4, 2014 at 9:23 AM, Leif Lindholm wrote: > Most, but not all, architectures supporting CONFIG_STRICT_DEVMEM treat > it as a debug feature - although its function is pretty much the > opposite of debug. > > This patch deletes all architecture-specific config options and moves > the option to core code, as a non-debug option. > > Signed-off-by: Leif Lindholm > --- > Apologies for wide distribution, but this is a bit invasive, > if trivial. > > arch/Kconfig |3 +++ > arch/arm/Kconfig |1 + > arch/arm/Kconfig.debug | 14 -- > arch/arm64/Kconfig |1 + > arch/arm64/Kconfig.debug | 14 -- > arch/powerpc/Kconfig |1 + > arch/powerpc/Kconfig.debug | 12 > arch/s390/Kconfig|1 + > arch/s390/Kconfig.debug | 12 > arch/tile/Kconfig|4 +--- > arch/unicore32/Kconfig |1 + > arch/unicore32/Kconfig.debug | 14 -- > arch/x86/Kconfig |1 + > arch/x86/Kconfig.debug | 17 - > drivers/char/Kconfig | 16 > 15 files changed, 26 insertions(+), 86 deletions(-) > > diff --git a/arch/Kconfig b/arch/Kconfig > index 05d7a8a..e5f4f03 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -484,6 +484,9 @@ config HAVE_IRQ_EXIT_ON_IRQ_STACK > This spares a stack switch and improves cache usage on softirq > processing. > > +config HAVE_ARCH_RESTRICTED_DEVMEM > + bool > + > # > # ABI hall of shame > # > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 89c4b5c..e04910f 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -30,6 +30,7 @@ config ARM > select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT) > select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL > select HAVE_ARCH_KGDB > + select HAVE_ARCH_RESTRICTED_DEVMEM if MMU > select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT) > select HAVE_ARCH_TRACEHOOK > select HAVE_BPF_JIT > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index d8f6a2e..2a02a7d 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -14,20 +14,6 @@ config ARM_PTDUMP > kernel. > If in doubt, say "N" > > -config STRICT_DEVMEM > - bool "Filter access to /dev/mem" > - depends on MMU > - ---help--- > - If this option is disabled, you allow userspace (root) access to all > - of memory, including kernel and userspace memory. Accidental > - access to this is obviously disastrous, but specific access can > - be used by people debugging the kernel. > - > - If this option is switched on, the /dev/mem file only allows > - userspace access to memory mapped peripherals. > - > - If in doubt, say Y. > - > # RMK wants arm kernels compiled with frame pointers or stack unwinding. > # If you know what you are doing and are willing to live without stack > # traces, you can get a slightly smaller kernel by setting this option to > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 9532f8d..90abbb2 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -37,6 +37,7 @@ config ARM64 > select HAVE_ARCH_AUDITSYSCALL > select HAVE_ARCH_JUMP_LABEL > select HAVE_ARCH_KGDB > + select HAVE_ARCH_RESTRICTED_DEVMEM if MMU > select HAVE_ARCH_TRACEHOOK > select HAVE_BPF_JIT > select HAVE_C_RECORDMCOUNT > diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug > index 0a12933..d0036dd 100644 > --- a/arch/arm64/Kconfig.debug > +++ b/arch/arm64/Kconfig.debug > @@ -6,20 +6,6 @@ config FRAME_POINTER > bool > default y > > -config STRICT_DEVMEM > - bool "Filter access to /dev/mem" > - depends on MMU > - help > - If this option is disabled, you allow userspace (root) access to all > - of memory, including kernel and userspace memory. Accidental > - access to this is obviously disastrous, but specific access can > - be used by people debugging the kernel. > - > - If this option is switched on, the /dev/mem file only allows > - userspace access to memory mapped peripherals. > - > - If in doubt, say Y. > - > config PID_IN_CONTEXTIDR > bool "Write the current PID to the CONTEXTIDR register" > help > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 88eace4..cd35068 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -148,6 +148,7 @@ config PPC > select HAVE_ARCH_AUDITSYSCALL > select ARCH_SUPPORTS_ATOMIC_RMW > select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN > + select HAVE_ARCH_RESTRICTED_DEVMEM > > config GENERIC_CSUM > def_bool CPU_LITTLE_ENDIAN > diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kcon
Re: [RFC PATCH] make CONFIG_STRICT_DEVMEM a core non-debug feature
On Tue, Nov 04, 2014 at 10:43:00AM -0800, Kees Cook wrote: > > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig > > index efefd12..39f7817 100644 > > --- a/drivers/char/Kconfig > > +++ b/drivers/char/Kconfig > > @@ -6,6 +6,22 @@ menu "Character devices" > > > > source "drivers/tty/Kconfig" > > > > +config STRICT_DEVMEM > > + bool "Reduced access to /dev/mem" > > + depends on HAVE_ARCH_RESTRICTED_DEVMEM > > + default y > > + help > > + If this option is disabled, you allow userspace (root) access to > > all > > + of memory, including kernel and userspace memory. Accidental > > + access to this is obviously disastrous, but specific access can > > + be used by people debugging the kernel. > > + > > + If this option is switched on, the /dev/mem file restricts > > userspace > > + access to an architecture-specific subset of the physical address > > + space. > > Great consolidation, thanks! I would probably expand this help text a > bit to include some of details mentioned in the x86 portion of the > option. For example: > > > If this option is switched on, the /dev/mem file restricts userspace > access to an architecture-specific subset of the physical address > space. For example on x86, PCI space and BIOS code and data > regions. This is sufficient for things like dosemu and non-KMS > Xorg and all common users of /dev/mem. I considered doing that, but didn't want to risk listing too many details of one architecture, and too few of others. One alternative would be to add a devmem.txt somewhere in Documentation, listing the behaviours on different architectures (this would also be a good place to describe restrictions on types of mappings and suchlike). The help message could then contain a mention of that file. Would that work for you? I really don't have a strong opinion however, and would be happy to go along with whatever the most people would like to see. / Leif ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] make CONFIG_STRICT_DEVMEM a core non-debug feature
On Tue, Nov 4, 2014 at 11:59 AM, Leif Lindholm wrote: > On Tue, Nov 04, 2014 at 10:43:00AM -0800, Kees Cook wrote: >> > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig >> > index efefd12..39f7817 100644 >> > --- a/drivers/char/Kconfig >> > +++ b/drivers/char/Kconfig >> > @@ -6,6 +6,22 @@ menu "Character devices" >> > >> > source "drivers/tty/Kconfig" >> > >> > +config STRICT_DEVMEM >> > + bool "Reduced access to /dev/mem" >> > + depends on HAVE_ARCH_RESTRICTED_DEVMEM >> > + default y >> > + help >> > + If this option is disabled, you allow userspace (root) access to >> > all >> > + of memory, including kernel and userspace memory. Accidental >> > + access to this is obviously disastrous, but specific access can >> > + be used by people debugging the kernel. >> > + >> > + If this option is switched on, the /dev/mem file restricts >> > userspace >> > + access to an architecture-specific subset of the physical address >> > + space. >> >> Great consolidation, thanks! I would probably expand this help text a >> bit to include some of details mentioned in the x86 portion of the >> option. For example: >> >> >> If this option is switched on, the /dev/mem file restricts userspace >> access to an architecture-specific subset of the physical address >> space. For example on x86, PCI space and BIOS code and data >> regions. This is sufficient for things like dosemu and non-KMS >> Xorg and all common users of /dev/mem. > > I considered doing that, but didn't want to risk listing too many > details of one architecture, and too few of others. Well, the others only say "memory mapped peripherals", so that's what I was suggesting adding the x86 language: it was the most detailed about what that would really mean to the end-user. > One alternative would be to add a devmem.txt somewhere in > Documentation, listing the behaviours on different architectures (this > would also be a good place to describe restrictions on types of > mappings and suchlike). The help message could then contain a mention > of that file. Would that work for you? That's fine too, but feels like overkill to me. Just adding the x86 example to the common help text seemed like a reasonable consolidation of the existing help texts. I just didn't want to lose detail when dropping the x86 text. > I really don't have a strong opinion however, and would be happy to go > along with whatever the most people would like to see. Either way, I'm all for the consolidation. :) -Kees -- Kees Cook Chrome OS Security ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] make CONFIG_STRICT_DEVMEM a core non-debug feature
On Tue, Nov 04, 2014 at 12:02:32PM -0800, Kees Cook wrote: > > I considered doing that, but didn't want to risk listing too many > > details of one architecture, and too few of others. > > Well, the others only say "memory mapped peripherals", so that's what > I was suggesting adding the x86 language: it was the most detailed > about what that would really mean to the end-user. The problem is that this currently isn't strictly speaking true for some architectures (at least not arm*). Without a standardised memory map, we are exposing mapping anything not system RAM. (Patches related to that will follow later this month.) / Leif ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add ppc64 hard lockup detector support
The hard lockup detector uses a PMU event as a periodic NMI to
detect if we are stuck (where stuck means no timer interrupts have
occurred).
Ben's rework of the ppc64 soft disable code has made ppc64 PMU
exceptions a partial NMI. They can get disabled if an external
interrupt comes in, but otherwise PMU interrupts will fire in
interrupt disabled regions.
We disable the hard lockup detector by default for a few reasons:
- It breaks userspace event based branches on POWER8.
- It is likely to produce false positives on KVM guests.
- Since PMCs can only count to 2^31, counting cycles means we might
take multiple PMU exceptions per second per hardware thread even
if our hard lockup timeout is 10 seconds.
It can be enabled via a boot option, or via procfs.
Signed-off-by: Anton Blanchard
---
arch/Kconfig | 2 +-
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/nmi.h | 4
arch/powerpc/kernel/setup_64.c | 20
4 files changed, 26 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/include/asm/nmi.h
diff --git a/arch/Kconfig b/arch/Kconfig
index 05d7a8a..a8551b0 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -32,7 +32,7 @@ config HAVE_OPROFILE
config OPROFILE_NMI_TIMER
def_bool y
- depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
+ depends on (PERF_EVENTS && HAVE_PERF_EVENTS_NMI) && !PPC
config KPROBES
bool "Kprobes"
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 88eace4..03791c4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -148,6 +148,7 @@ config PPC
select HAVE_ARCH_AUDITSYSCALL
select ARCH_SUPPORTS_ATOMIC_RMW
select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
+ select HAVE_PERF_EVENTS_NMI if PPC64
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/nmi.h b/arch/powerpc/include/asm/nmi.h
new file mode 100644
index 000..ff1ccb3
--- /dev/null
+++ b/arch/powerpc/include/asm/nmi.h
@@ -0,0 +1,4 @@
+#ifndef _ASM_NMI_H
+#define _ASM_NMI_H
+
+#endif /* _ASM_NMI_H */
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 1b56320..c368397 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -781,3 +782,22 @@ unsigned long memory_block_size_bytes(void)
struct ppc_pci_io ppc_pci_io;
EXPORT_SYMBOL(ppc_pci_io);
#endif
+
+#ifdef CONFIG_HARDLOCKUP_DETECTOR
+u64 hw_nmi_get_sample_period(int watchdog_thresh)
+{
+ return ppc_proc_freq * watchdog_thresh;
+}
+
+/*
+ * The hardlockup detector breaks PMU event based branches and is likely
+ * to get false positives in KVM guests, so disable it by default.
+ */
+static int __init disable_hardlockup_detector(void)
+{
+ watchdog_enable_hardlockup_detector(false);
+
+ return 0;
+}
+early_initcall(disable_hardlockup_detector);
+#endif
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the iommu tree
Hi Joerg,
After merging the iommu tree, today's linux-next build (powerpc
pc64_defconfig) failed like this:
In file included from arch/powerpc/platforms/powernv/pci.c:33:0:
arch/powerpc/include/asm/iommu.h:140:12: error: conflicting types for
'iommu_map_sg'
extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
^
In file included from arch/powerpc/platforms/powernv/pci.c:23:0:
include/linux/iommu.h:311:22: note: previous definition of 'iommu_map_sg' was
here
static inline size_t iommu_map_sg(struct iommu_domain *domain,
^
Caused by commit 315786ebbf4a ("iommu: Add iommu_map_sg() function").
Grep is your friend ...
I have used the iommu tree from next-20141104 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpEwgb8fm1KU.pgp
Description: OpenPGP digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: Convert power off logic to pm_power_off topic branch
On Mon, 2014-11-03 at 21:11 -0800, Guenter Roeck wrote: > On 11/03/2014 08:47 PM, Michael Ellerman wrote: > > I've put the pm_power_off patch in a topic branch: > > > > > > https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=topic/pm-power-off > Excellent. > > Right now all I can do is to wait for Rafael. He was not happy with earlier > versions > of the series and did not yet comment on the most recent version. Since we > are already > at 3.18-rc3 without making real progress, it may well be that the series is > going > to miss 3.19. OK. I'll merge the powerpc bits for 3.19 anyway, so if your stuff misses 3.19 then it will be even simpler for 3.20. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Add INA220 to device tree for supported boards
Including: P3041DS P5020DS P5040DS B4QDS
Signed-off-by: Jia Hongtao
---
arch/powerpc/boot/dts/b4qds.dtsi | 12
arch/powerpc/boot/dts/p3041ds.dts | 20
arch/powerpc/boot/dts/p5020ds.dts | 20
arch/powerpc/boot/dts/p5040ds.dts | 20
4 files changed, 72 insertions(+)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index bccc986..e5bde0b 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -153,6 +153,18 @@
};
};
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+
+ ina220@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+ };
+
i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/p3041ds.dts
b/arch/powerpc/boot/dts/p3041ds.dts
index 2fed3bc..394ea9c 100644
--- a/arch/powerpc/boot/dts/p3041ds.dts
+++ b/arch/powerpc/boot/dts/p3041ds.dts
@@ -98,6 +98,26 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ ina220@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+ ina220@41 {
+ compatible = "ti,ina220";
+ reg = <0x41>;
+ shunt-resistor = <1000>;
+ };
+ ina220@44 {
+ compatible = "ti,ina220";
+ reg = <0x44>;
+ shunt-resistor = <1000>;
+ };
+ ina220@45 {
+ compatible = "ti,ina220";
+ reg = <0x45>;
+ shunt-resistor = <1000>;
+ };
adt7461@4c {
compatible = "adi,adt7461";
reg = <0x4c>;
diff --git a/arch/powerpc/boot/dts/p5020ds.dts
b/arch/powerpc/boot/dts/p5020ds.dts
index 2869fea..b7f3057 100644
--- a/arch/powerpc/boot/dts/p5020ds.dts
+++ b/arch/powerpc/boot/dts/p5020ds.dts
@@ -98,6 +98,26 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ ina220@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+ ina220@41 {
+ compatible = "ti,ina220";
+ reg = <0x41>;
+ shunt-resistor = <1000>;
+ };
+ ina220@44 {
+ compatible = "ti,ina220";
+ reg = <0x44>;
+ shunt-resistor = <1000>;
+ };
+ ina220@45 {
+ compatible = "ti,ina220";
+ reg = <0x45>;
+ shunt-resistor = <1000>;
+ };
adt7461@4c {
compatible = "adi,adt7461";
reg = <0x4c>;
diff --git a/arch/powerpc/boot/dts/p5040ds.dts
b/arch/powerpc/boot/dts/p5040ds.dts
index 860b5cc..7e04bf4 100644
--- a/arch/powerpc/boot/dts/p5040ds.dts
+++ b/arch/powerpc/boot/dts/p5040ds.dts
@@ -95,6 +95,26 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ ina220@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+ ina220@41 {
+ compatible = "ti,ina220";
+ reg = <0x41>;
+ shunt-resistor = <1000>;
+ };
+ ina220@44 {
+ compatible =
[PATCH 1/2] powerpc: Add ADT7461 to device tree for supported boards
Including: T104xRDB T208xQDS B4QDS
Signed-off-by: Jia Hongtao
---
arch/powerpc/boot/dts/b4qds.dtsi| 11 +++
arch/powerpc/boot/dts/t104xrdb.dtsi | 7 +++
arch/powerpc/boot/dts/t208xqds.dtsi | 11 +++
3 files changed, 29 insertions(+)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index 8b47edc..bccc986 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -152,6 +152,17 @@
reg = <0x68>;
};
};
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ };
};
};
diff --git a/arch/powerpc/boot/dts/t104xrdb.dtsi
b/arch/powerpc/boot/dts/t104xrdb.dtsi
index 1cf0f3c..187add8 100644
--- a/arch/powerpc/boot/dts/t104xrdb.dtsi
+++ b/arch/powerpc/boot/dts/t104xrdb.dtsi
@@ -83,6 +83,13 @@
};
};
+ i2c@118000 {
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ };
+
i2c@118100 {
pca9546@77 {
compatible = "nxp,pca9546";
diff --git a/arch/powerpc/boot/dts/t208xqds.dtsi
b/arch/powerpc/boot/dts/t208xqds.dtsi
index 555dc6e..5906183 100644
--- a/arch/powerpc/boot/dts/t208xqds.dtsi
+++ b/arch/powerpc/boot/dts/t208xqds.dtsi
@@ -169,6 +169,17 @@
shunt-resistor = <1000>;
};
};
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ };
};
};
--
2.1.0.27.g96db324
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
