[PATCH v3 3/6] Documentation: Update documentation for UIO_MEM_PHYS_CACHE
This patch updates UIO documentation for new mem region type UIO_MEM_PHYS_CACHE. Signed-off-by: Ankit Jindal Signed-off-by: Tushar Jagad --- Documentation/DocBook/uio-howto.tmpl |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index bbe9c1f..baa9185 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -529,8 +529,9 @@ the memory region, it will show up in the corresponding sysfs node. int memtype: Required if the mapping is used. Set this to UIO_MEM_PHYS if you you have physical memory on your card to be mapped. Use UIO_MEM_LOGICAL for logical -memory (e.g. allocated with kmalloc()). There's also -UIO_MEM_VIRTUAL for virtual memory. +memory (e.g. allocated with kmalloc()). There are also +UIO_MEM_VIRTUAL for virtual memory, and +UIO_MEM_PHYS_CACHE for cacheable access to physical memory. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/6] uio: Add X-Gene QMTM UIO driver
The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
and Traffic manager) which is hardware based Queue or Ring
manager. This QMTM device can be used in conjunction with
other devices such as DMA Engine, Ethernet, Security Engine,
etc to assign work based on queues or rings.
This patch allows user space access to X-Gene QMTM device.
Signed-off-by: Ankit Jindal
Signed-off-by: Tushar Jagad
---
drivers/uio/Kconfig |8 ++
drivers/uio/Makefile |1 +
drivers/uio/uio_xgene_qmtm.c | 270 ++
3 files changed, 279 insertions(+)
create mode 100644 drivers/uio/uio_xgene_qmtm.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 5a90914..76b1858 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -135,4 +135,12 @@ config UIO_MF624
If you compile this as a module, it will be called uio_mf624.
+config UIO_XGENE_QMTM
+ tristate "Applied Micro X-Gene QMTM driver"
+ depends on OF
+ help
+ Userspace I/O interface for the X-Gene QMTM. The userspace part of
+ this driver will be available for download from the Applied Micro
+ web site (http://www.apm.com/).
+
endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index d3218bd..633eaa0 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
obj-$(CONFIG_UIO_NETX) += uio_netx.o
obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
obj-$(CONFIG_UIO_MF624) += uio_mf624.o
+obj-$(CONFIG_UIO_XGENE_QMTM) += uio_xgene_qmtm.o
diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
new file mode 100644
index 000..65467a1
--- /dev/null
+++ b/drivers/uio/uio_xgene_qmtm.c
@@ -0,0 +1,270 @@
+/*
+ * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver (uio_xgene_qmtm)
+ *
+ * This driver exports QMTM CSRs, Fabric and memory for queues to user-space
+ *
+ * Copyright (C) 2014 Applied Micro - http://www.apm.com/
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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
+#include
+#include
+
+#define DRV_NAME "qmtm_uio"
+#define DRV_VERSION "1.0"
+
+#define QMTM_CFG_MEM_RAM_SHUTDOWN 0xd070
+
+#define QMTM_DEFAULT_QSIZE 65536
+
+struct uio_qmtm_dev {
+ struct uio_info *info;
+ struct clk *qmtm_clk;
+};
+
+/* QMTM CSR read/write routine */
+static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32 offset,
+ u32 data)
+{
+ void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+ writel(data, addr + offset);
+}
+
+static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32 offset)
+{
+ void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+ return readl(addr + offset);
+}
+
+static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
+{
+ u32 val;
+ int wait = 1000;
+
+ /* reset the internal memory of the device */
+ qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
+
+ /* check whether device internal memory is out of reset or not */
+ while (wait--) {
+ val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
+
+ if (val != 0x)
+ return 0;
+
+ udelay(1);
+ }
+
+ return -ETIMEDOUT;
+}
+
+static int qmtm_probe(struct platform_device *pdev)
+{
+ struct uio_info *info;
+ struct uio_qmtm_dev *qmtm_dev;
+ struct resource *csr;
+ struct resource *fabric;
+ struct resource qpool;
+ unsigned int num_queues;
+ unsigned int devid;
+ phandle qpool_phandle;
+ struct device_node *qpool_node;
+ int ret;
+
+ qmtm_dev = devm_kzalloc(>dev, sizeof(struct uio_qmtm_dev),
+ GFP_KERNEL);
+ if (!qmtm_dev)
+ return -ENOMEM;
+
+ qmtm_dev->info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
+ if (!qmtm_dev->info)
+ return -ENOMEM;
+
+ /* Power on qmtm in case its not done as part of boot-loader */
+ qmtm_dev->qmtm_clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(qmtm_dev->qmtm_clk)) {
+ dev_err(>dev, "Failed to get clock\n");
+ ret = PTR_ERR(qmtm_dev->qmtm_clk);
+ return ret;
+ }
+
+ csr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!csr) {
+ ret = -ENODEV;
+
[PATCH v3 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
Currently, three types of mem regions are supported: UIO_MEM_PHYS,
UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
UIO driver export physcial memory to user space as non-cacheable
user memory. Typcially memory-mapped registers of a device are exported
to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
is not efficient if dma-capable devices are capable of maintaining coherency
with CPU caches.
This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
cacheable access to physical memory from user space.
Signed-off-by: Ankit Jindal
Signed-off-by: Tushar Jagad
---
drivers/uio/uio.c | 11 ---
include/linux/uio_driver.h |1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 97e6444..120a84b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -644,7 +644,7 @@ static const struct vm_operations_struct
uio_physical_vm_ops = {
#endif
};
-static int uio_mmap_physical(struct vm_area_struct *vma)
+static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
{
struct uio_device *idev = vma->vm_private_data;
int mi = uio_find_mem_index(vma);
@@ -659,7 +659,9 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
return -EINVAL;
vma->vm_ops = _physical_vm_ops;
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+ if (!cacheable)
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
/*
* We cannot use the vm_iomap_memory() helper here,
@@ -707,10 +709,13 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma)
switch (idev->info->mem[mi].memtype) {
case UIO_MEM_PHYS:
- return uio_mmap_physical(vma);
+ return uio_mmap_physical(vma, false);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
+ case UIO_MEM_PHYS_CACHE:
+ return uio_mmap_physical(vma, true);
+
default:
return -EINVAL;
}
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 1ad4724..40ca3f3 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -118,6 +118,7 @@ extern void uio_event_notify(struct uio_info *info);
#define UIO_MEM_PHYS 1
#define UIO_MEM_LOGICAL2
#define UIO_MEM_VIRTUAL 3
+#define UIO_MEM_PHYS_CACHE 4
/* defines for uio_port->porttype */
#define UIO_PORT_NONE 0
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/6] uio: code style cleanup
This patch fixes the indentation of switch-case block in uio driver.
Signed-off-by: Ankit Jindal
Signed-off-by: Tushar Jagad
---
drivers/uio/uio.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index a673e5b..97e6444 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -706,13 +706,13 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma)
}
switch (idev->info->mem[mi].memtype) {
- case UIO_MEM_PHYS:
- return uio_mmap_physical(vma);
- case UIO_MEM_LOGICAL:
- case UIO_MEM_VIRTUAL:
- return uio_mmap_logical(vma);
- default:
- return -EINVAL;
+ case UIO_MEM_PHYS:
+ return uio_mmap_physical(vma);
+ case UIO_MEM_LOGICAL:
+ case UIO_MEM_VIRTUAL:
+ return uio_mmap_logical(vma);
+ default:
+ return -EINVAL;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/6] MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver
Add entry to maintainer list for APM X-Gene QMTM UIO driver. Signed-off-by: Ankit Jindal Signed-off-by: Tushar Jagad --- MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5e7866a..138663f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -727,6 +727,13 @@ S: Supported F: drivers/net/ethernet/apm/xgene/ F: Documentation/devicetree/bindings/net/apm-xgene-enet.txt +APPLIED MICRO (APM) X-GENE QMTM UIO DRIVER +M: Ankit Jindal +M: Tushar Jagad +S: Supported +F: drivers/uio/uio_xgene_qmtm.c +F: Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt + APTINA CAMERA SENSOR PLL M: Laurent Pinchart L: linux-me...@vger.kernel.org -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver
This patch adds device tree binding documentation for
X-Gene QMTM UIO driver.
Signed-off-by: Ankit Jindal
Signed-off-by: Tushar Jagad
---
.../devicetree/bindings/uio/uio_xgene_qmtm.txt | 53
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
diff --git a/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
new file mode 100644
index 000..288ed92
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
@@ -0,0 +1,53 @@
+APM X-Gene QMTM UIO nodes
+
+The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
+and Traffic manager). It is a device for managing hardware queues.
+It also implements QoS among hardware queues hence term "traffic"
+manager is present in its name. QMTM UIO nodes are defined for user
+space access to this device using UIO framework.
+
+Required properties:
+- compatible: Should be "apm,xgene-qmtm"
+- reg: Address and length of the register set for the device. It contains the
+ information of registers in the same order as described by reg-names.
+- reg-names: Should contain the register set names
+ - "csr": QMTM control and status register address space.
+ - "fabric": QMTM memory mapped access to queue states.
+- qpool: Points to the phandle of the node defining memory location for
+creating QMTM queues. This could point either to the reserved-memory
+node (as-per reserved memory bindings) or to the node of on-chip
+SRAM etc. It is expected that size and location of qpool memory will
+be configurable via bootloader.
+- clocks: Reference to the clock entry.
+- num-queues: Number of queues under this QMTM device.
+- devid: QMTM identification number for the system having multiple QMTM
devices.
+This is used to form a unique id (a tuple of queue number and
+device id) for the queues belonging to this device.
+
+Example:
+ qmtm1_uio_qpool: qmtm1_uio_qpool {
+ reg = <0x0 0x0 0x0 0x0>
+ };
+
+ qmtm1clk: qmtmclk@1f20c000 {
+ compatible = "apm,xgene-device-clock";
+ clock-output-names = "qmtm1clk";
+ status = "ok";
+ };
+
+ qmtm1_uio: qmtm_uio@1f20 {
+ compatible = "apm,xgene-qmtm";
+ status = "disabled";
+ reg = <0x0 0x1f20 0x0 0x1>,
+ <0x0 0x1b00 0x0 0x40>;
+ reg-names = "csr", "fabric";
+ qpool = <_uio_qpool>;
+ clocks = < 0>;
+ num-queues = <0x400>;
+ devid = <1>;
+ };
+
+ /* Board-specific peripheral configurations */
+ _uio {
+ status = "ok";
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/6] UIO driver for APM X-Gene QMTM
This patchset enables user space access to APM X-Gene QMTM using UIO framework. The patchset also introduces new type UIO_MEM_PHYS_CACHE for mem regions because APM X-Gene QMTM device supports cache coherency with CPU caches. Changes since v2: - Formatting cleanups. - Remove qmtm_cleanup(). Changes since v1: - Factor-out formating related change in uio/uio.c as separate patch. - Use devm_xxx() APIs where appilicable. - Some cleanups and buggy loop fixed in qmtm_reset(). - Removed open and release functions. - Use phandle for specifying QMTM qpool resource. - Removed "uio" from the compatible string. - Added more information about QMTM in binding documentation. Ankit Jindal (6): uio: code style cleanup uio: Add new UIO_MEM_PHYS_CACHE type for mem regions Documentation: Update documentation for UIO_MEM_PHYS_CACHE uio: Add X-Gene QMTM UIO driver Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver Documentation/DocBook/uio-howto.tmpl |5 +- .../devicetree/bindings/uio/uio_xgene_qmtm.txt | 53 MAINTAINERS|7 + drivers/uio/Kconfig|8 + drivers/uio/Makefile |1 + drivers/uio/uio.c | 23 +- drivers/uio/uio_xgene_qmtm.c | 270 include/linux/uio_driver.h |1 + 8 files changed, 357 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt create mode 100644 drivers/uio/uio_xgene_qmtm.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 8/8] ARM: zynq: DT: Add pinctrl information
On 10/16/2014 07:11 PM, Soren Brinkmann wrote:
> Add pinctrl descriptions to the zc702 and zc706 device trees.
>
> Signed-off-by: Soren Brinkmann
> ---
> arch/arm/boot/dts/zynq-7000.dtsi | 8 ++-
> arch/arm/boot/dts/zynq-zc702.dts | 147
> +++
> arch/arm/boot/dts/zynq-zc706.dts | 126 +
> 3 files changed, 280 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
> b/arch/arm/boot/dts/zynq-7000.dtsi
> index 24036c440440..37d7fe36a129 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -238,7 +238,7 @@
> slcr: slcr@f800 {
> #address-cells = <1>;
> #size-cells = <1>;
> - compatible = "xlnx,zynq-slcr", "syscon";
> + compatible = "xlnx,zynq-slcr", "syscon", "simple-bus";
I expect that you have this here to be able to probe the driver.
slcr is not the bus.
You should be able just to probe child nodes.
Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/6] drivers: uio: Add X-Gene QMTM UIO driver
On 30 September 2014 11:35, Varka Bhadram wrote:
> I think *drivers* is not required in the commit message...
>
>
> On 09/30/2014 09:56 AM, Ankit Jindal wrote:
>>
>> The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
>> and Traffic manager) which is hardware based Queue or Ring
>> manager. This QMTM device can be used in conjunction with
>> other devices such as DMA Engine, Ethernet, Security Engine,
>> etc to assign work based on queues or rings.
>>
>> This patch allows user space access to X-Gene QMTM device.
>>
>> Signed-off-by: Ankit Jindal
>> Signed-off-by: Tushar Jagad
>> ---
>> drivers/uio/Kconfig |8 ++
>> drivers/uio/Makefile |1 +
>> drivers/uio/uio_xgene_qmtm.c | 278
>> ++
>> 3 files changed, 287 insertions(+)
>> create mode 100644 drivers/uio/uio_xgene_qmtm.c
>>
>> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
>> index 5a90914..76b1858 100644
>> --- a/drivers/uio/Kconfig
>> +++ b/drivers/uio/Kconfig
>> @@ -135,4 +135,12 @@ config UIO_MF624
>> If you compile this as a module, it will be called uio_mf624.
>> +config UIO_XGENE_QMTM
>> + tristate "Applied Micro X-Gene QMTM driver"
>> + depends on OF
>> + help
>> + Userspace I/O interface for the X-Gene QMTM. The userspace part
>> of
>> + this driver will be available for download from the Applied
>> Micro
>> + web site (http://www.apm.com/).
>> +
>> endif
>> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
>> index d3218bd..633eaa0 100644
>> --- a/drivers/uio/Makefile
>> +++ b/drivers/uio/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
>> obj-$(CONFIG_UIO_NETX)+= uio_netx.o
>> obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
>> obj-$(CONFIG_UIO_MF624) += uio_mf624.o
>> +obj-$(CONFIG_UIO_XGENE_QMTM) += uio_xgene_qmtm.o
>> diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
>> new file mode 100644
>> index 000..36d9000
>> --- /dev/null
>> +++ b/drivers/uio/uio_xgene_qmtm.c
>> @@ -0,0 +1,278 @@
>> +/*
>> + * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver
>> (uio_xgene_qmtm)
>> + *
>> + * This driver exports QMTM CSRs, Fabric and memory for queues to
>> user-space
>> + *
>> + * Copyright (C) 2014 Applied Micro - http://www.apm.com/
>> + * Copyright (C) 2014 Linaro Ltd.
>> + *
>> + * 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 "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; 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
>> +#include
>> +#include
>> +
>
>
> Headers in alphabetical order...?
>
> #include
> #include
>
> ...
>
>
>> +#define DRV_NAME "qmtm_uio"
>> +#define DRV_VERSION "1.0"
>> +
>> +#define QMTM_CFG_MEM_RAM_SHUTDOWN 0xd070
>> +
>> +#define QMTM_DEFAULT_QSIZE 65536
>> +
>> +struct uio_qmtm_dev {
>> + struct uio_info *info;
>> + struct clk *qmtm_clk;
>> +};
>> +
>> +/* QMTM CSR read/write routine */
>> +static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32
>> offset,
>> + u32 data)
>> +{
>> + void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
>> +
>> + writel(data, addr + offset);
>> +}
>> +
>> +static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32
>> offset)
>> +{
>> + void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
>> +
>> + return readl(addr + offset);
>> +}
>> +
>> +static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
>> +{
>> + u32 val;
>> + int wait = 1000;
>> +
>> + /* reset the internal memory of the device */
>> + qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
>> +
>> + /* check whether device internal memory is out of reset or not */
>> + while (1) {
>> + val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
>> +
>> + if (val != 0x)
>> + return 0;
>> +
>> + if (!wait--)
>> + return -EBUSY;
>> +
>> + udelay(1);
>> + }
>> +}
>> +
>> +static void qmtm_cleanup(struct platform_device *pdev,
>> + struct uio_qmtm_dev *qmtm_dev)
>> +{
>> + struct uio_info *info = qmtm_dev->info;
>> +
>> + uio_unregister_device(info);
>> +
>> + clk_disable_unprepare(qmtm_dev->qmtm_clk);
>> +}
>> +
>> +static int qmtm_probe(struct platform_device *pdev)
>> +{
>> + struct uio_info *info;
>> + struct uio_qmtm_dev *qmtm_dev;
>> +
Re: [PATCH v2 4/6] drivers: uio: Add X-Gene QMTM UIO driver
On 30 September 2014 11:05, Guenter Roeck wrote:
> On Tue, Sep 30, 2014 at 09:56:07AM +0530, Ankit Jindal wrote:
>> The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
>> and Traffic manager) which is hardware based Queue or Ring
>> manager. This QMTM device can be used in conjunction with
>> other devices such as DMA Engine, Ethernet, Security Engine,
>> etc to assign work based on queues or rings.
>>
>> This patch allows user space access to X-Gene QMTM device.
>>
>> Signed-off-by: Ankit Jindal
>> Signed-off-by: Tushar Jagad
>> ---
>> drivers/uio/Kconfig |8 ++
>> drivers/uio/Makefile |1 +
>> drivers/uio/uio_xgene_qmtm.c | 278
>> ++
>> 3 files changed, 287 insertions(+)
>> create mode 100644 drivers/uio/uio_xgene_qmtm.c
>>
>> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
>> index 5a90914..76b1858 100644
>> --- a/drivers/uio/Kconfig
>> +++ b/drivers/uio/Kconfig
>> @@ -135,4 +135,12 @@ config UIO_MF624
>>
>> If you compile this as a module, it will be called uio_mf624.
>>
>> +config UIO_XGENE_QMTM
>> + tristate "Applied Micro X-Gene QMTM driver"
>> + depends on OF
>> + help
>> + Userspace I/O interface for the X-Gene QMTM. The userspace part of
>> + this driver will be available for download from the Applied Micro
>> + web site (http://www.apm.com/).
>> +
>> endif
>> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
>> index d3218bd..633eaa0 100644
>> --- a/drivers/uio/Makefile
>> +++ b/drivers/uio/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
>> obj-$(CONFIG_UIO_NETX) += uio_netx.o
>> obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
>> obj-$(CONFIG_UIO_MF624) += uio_mf624.o
>> +obj-$(CONFIG_UIO_XGENE_QMTM) += uio_xgene_qmtm.o
>> diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
>> new file mode 100644
>> index 000..36d9000
>> --- /dev/null
>> +++ b/drivers/uio/uio_xgene_qmtm.c
>> @@ -0,0 +1,278 @@
>> +/*
>> + * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver (uio_xgene_qmtm)
>> + *
>> + * This driver exports QMTM CSRs, Fabric and memory for queues to user-space
>> + *
>> + * Copyright (C) 2014 Applied Micro - http://www.apm.com/
>> + * Copyright (C) 2014 Linaro Ltd.
>> + *
>> + * 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 "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; 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
>> +#include
>> +#include
>> +
>> +#define DRV_NAME "qmtm_uio"
>> +#define DRV_VERSION "1.0"
>> +
>> +#define QMTM_CFG_MEM_RAM_SHUTDOWN0xd070
>> +
>> +#define QMTM_DEFAULT_QSIZE 65536
>> +
>> +struct uio_qmtm_dev {
>> + struct uio_info *info;
>> + struct clk *qmtm_clk;
>> +};
>> +
>> +/* QMTM CSR read/write routine */
>> +static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32 offset,
>> + u32 data)
>> +{
>> + void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
>> +
>> + writel(data, addr + offset);
>> +}
>> +
>> +static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32 offset)
>> +{
>> + void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
>> +
>> + return readl(addr + offset);
>> +}
>> +
>> +static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
>> +{
>> + u32 val;
>> + int wait = 1000;
>> +
>> + /* reset the internal memory of the device */
>> + qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
>> +
>> + /* check whether device internal memory is out of reset or not */
>> + while (1) {
>
> Seems to me that
> while (wait--) {
> ...
> }
> return -EBUSY;
>
> would be much easier to understand.
>
> Also, not sure if EBUSY is really appropriate here.
> ETIMEDOUT, maybe ?
>
>> + val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
>> +
>> + if (val != 0x)
>> + return 0;
>> +
>> + if (!wait--)
>> + return -EBUSY;
>> +
>> + udelay(1);
>> + }
>> +}
>> +
>> +static void qmtm_cleanup(struct platform_device *pdev,
>> + struct uio_qmtm_dev *qmtm_dev)
>> +{
>> + struct uio_info *info = qmtm_dev->info;
>> +
>> + uio_unregister_device(info);
>> +
>> + clk_disable_unprepare(qmtm_dev->qmtm_clk);
>> +}
>> +
>> +static int qmtm_probe(struct platform_device *pdev)
>> +{
>> + struct uio_info *info;
>> + struct uio_qmtm_dev *qmtm_dev;
>> +
[PATCH v2] ARM: DT: apq8064: Add Support for SD Card Detect for ifc6410 board
This changes muxes in gpio26 pin to function as gpio and adds support
for sd card detect for apq8064 based IFC6410 board.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Srinivas Kandagatla
Signed-off-by: Pramod Gurav
---
Changes since v2:
- Replaced hardcode value with GPIO_ACTIVE_LOW
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index b396c83..e641001 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -1,4 +1,5 @@
#include "qcom-apq8064-v2.0.dtsi"
+#include
/ {
model = "Qualcomm APQ8064/IFC6410";
@@ -12,6 +13,14 @@
function = "gsbi1";
};
};
+
+ card_detect: card_detect {
+ mux {
+ pins = "gpio26";
+ function = "gpio";
+ bias-disable;
+ };
+ };
};
gsbi@1244 {
@@ -49,6 +58,9 @@
/* External micro SD card */
sdcc3: sdcc@1218 {
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_detect>;
+ cd-gpios= <_pinmux 26
GPIO_ACTIVE_LOW>;
};
/* WLAN */
sdcc4: sdcc@121c {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
On Mon, Oct 20, 2014 at 10:42 PM, Eric W. Biederman wrote: > Andy Lutomirski writes: > >> On Mon, Oct 20, 2014 at 9:49 PM, Eric W. Biederman >> wrote: >>> Andy Lutomirski writes: Possible solution: Ditch the pinning. That is, if you're outside a cgroupns (or you have a non-ns-confined cgroupfs mounted), then you can move a task in a cgroupns outside of its root cgroup. If you do this, then the task thinks its cgroup is something like "../foo" or "../../foo". >>> >>> Of the possible solutions that seems attractive to me, simply because >>> we sometimes want to allow clever things to occur. >>> >>> Does anyone know of a reason (beyond pretty printing) why we need >>> cgroupns to restrict the subset of cgroups processes can be in? >>> >>> I would expect permissions on the cgroup directories themselves, and >>> limited visiblilty would be (in general) to achieve the desired >>> visiblity. >> >> This makes the security impact of cgroupns very easy to understand, >> right? Because there really won't be any -- cgroupns only affects >> reads from /proc and what cgroupfs shows, but it doesn't change any >> actual cgroups, nor does it affect any cgroup *changes*. > > It seems like what we have described is chcgrouproot aka chroot for > cgroups. At which point I think there are potentially similar security > issues as for chroot. Can we confuse a setuid root process if we make > it's cgroup names look different. > > Of course the confusing root concern is handled by the usual namespace > security checks that are already present. I think that the chroot issues are mostly in two categories: setuid confusion (not an issue here as you described) and chroot escapes. cgroupns escapes aren't a big deal, I think -- admins should deny the confined task the right to write to cgroupfs outside its hierarchy, by setting cgroupfs permissions appropriately and/or avoiding mounting cgroupfs outside the hierarchy. > > I do wonder if we think of this as chcgrouproot if there is a simpler > implementation. Could be. I'll defer to Aditya for that one. > While we're at it, consider making setns for a cgroupns *not* change the caller's cgroup. Is there any reason it really needs to? >>> >>> setns doesn't but nsenter is going to need to change the cgroup >>> if the pinning requirement is kept. nsenenter is going to want to >>> change the cgroup if the pinning requirement is dropped. >>> >> >> It seems easy enough for nsenter to change the cgroup all by itself. > > Again. I don't think anyone has suggested or implemented anything > different. The current patchset seems to punt on this decision by just failing the setns call if the caller is outside the cgroup in question. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/6] ARM: cygnus: Initial support for Broadcom Cygnus SoC
On Monday 20 October 2014 15:59:45 Scott Branden wrote: > On 14-10-20 12:55 PM, Arnd Bergmann wrote: > > On Tuesday 14 October 2014 19:58:51 Scott Branden wrote: > >> if ARCH_BCM > >> > >> +menu "iProc SoC based Machine types" > >> + config ARCH_BCM_IPROC > >> + bool > >> + select ARM_GIC > >> + select CACHE_L2X0 > >> + select HAVE_ARM_SCU if SMP > >> + select HAVE_ARM_TWD if SMP > >> + select ARM_GLOBAL_TIMER > >> + > >> + select CLKSRC_MMIO > >> + select ARCH_REQUIRE_GPIOLIB > >> + select ARM_AMBA > >> + select PINCTRL > >> + help > >> + This enables support for systems based on Broadcom IPROC > >> architected SoCs. > >> + The IPROC complex contains one or more ARM CPUs along > >> with common > >> + core periperals. Application specific SoCs are created > >> by adding a > >> + uArchitecture containing peripherals outside of the > >> IPROC complex. > >> + Currently supported SoCs are Cygnus. > >> + > >> + config ARCH_BCM_CYGNUS > >> + bool "Broadcom Cygnus Support" if ARCH_MULTI_V7 > > > > You still have a three-level menu structure. Please fix. > > Hi Arnd, we have ARCH_BCM->ARCH_BCM_CYGNUS. > > ARCH_BCM_IPROC is silent and selected by ARCH_BCM_CYGNUS. This was the > change made between v3 and v5. > > Is there something else to be done here? > You have "Broadcom SoC Support" "iProc SoC based Machine types" "Broadcom Cygnus Support" Get rid of one of them. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/5] x86: Add a comment clarifying LDT context switching
On Mon, Oct 20, 2014 at 10:41 PM, Borislav Petkov wrote: > On Thu, Oct 16, 2014 at 09:21:42AM -0700, Andy Lutomirski wrote: >> I think it's the same as in the other case in switch_mm. leave_mm does >> cpumask_clear_cpu(cpu, mm_cpumask(active_mm)), and, once that has >> happened, modify_ldt won't send an IPI to this CPU. So, if leave_mm >> runs, and then another CPU calls modify_ldt on the mm that is in lazy >> mode here, it won't update our LDT register, so the LDT register and >> prev->context.ldt might not match. > > Ok, let me see if I can follow with an example: > > We call leave_mm() on, say, cpu 3 and mm_cpumask(active_mm) has cpu 3 and > 4 set. Then, on cpu 4 we call modify_ldt on that same mm and there in > alloc_ldt() we have this: > > if (!cpumask_equal(mm_cpumask(current->mm), >cpumask_of(smp_processor_id( > smp_call_function(flush_ldt, current->mm, 1); > > and since we've cleared cpu 3 from the cpumask, we don't flush_ldt() > on it and there you have the difference. > > Am I close? You're exactly correct, or at least you seem to understand it the way I do :) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
Andy Lutomirski writes: > On Mon, Oct 20, 2014 at 9:49 PM, Eric W. Biederman > wrote: >> Andy Lutomirski writes: >> >>> On Sun, Oct 19, 2014 at 9:55 PM, Eric W.Biederman >>> wrote: On October 19, 2014 1:26:29 PM CDT, Andy Lutomirski wrote: >> > Is the idea >that you want a privileged user wrt a cgroupns's userns to be able to >use this? If so: > >Yes, that current_cred() thing is bogus. (Actually, this is probably >exploitable right now if any cgroup.procs inode anywhere on the system >lets non-root write.) (Can we have some kernel debugging option that >makes any use of current_cred() in write(2) warn?) > >We really need a weaker version of may_ptrace for this kind of stuff. >Maybe the existing may_ptrace stuff is okay, actually. But this is >completely missing group checks, cap checks, capabilities wrt the >userns, etc. > >Also, I think that, if this version of the patchset allows non-init >userns to unshare cgroupns, then the issue of what permission is >needed to lock the cgroup hierarchy like that needs to be addressed, >because unshare(CLONE_NEWUSER|CLONE_NEWCGROUP) will effectively pin >the calling task with no permission required. Bolting on a fix later >will be a mess. I imagine the pinning would be like the userns. Ah but there is a potentially serious issue with the pinning. With pinning we can make it impossible for root to move us to a different cgroup. I am not certain how serious that is but it bears thinking about. If we don't implement pinning we should be able to implent everything with just filesystem mount options, and no new namespace required. Sigh. I am too tired tonight to see the end game in this. >>> >>> Possible solution: >>> >>> Ditch the pinning. That is, if you're outside a cgroupns (or you have >>> a non-ns-confined cgroupfs mounted), then you can move a task in a >>> cgroupns outside of its root cgroup. If you do this, then the task >>> thinks its cgroup is something like "../foo" or "../../foo". >> >> Of the possible solutions that seems attractive to me, simply because >> we sometimes want to allow clever things to occur. >> >> Does anyone know of a reason (beyond pretty printing) why we need >> cgroupns to restrict the subset of cgroups processes can be in? >> >> I would expect permissions on the cgroup directories themselves, and >> limited visiblilty would be (in general) to achieve the desired >> visiblity. > > This makes the security impact of cgroupns very easy to understand, > right? Because there really won't be any -- cgroupns only affects > reads from /proc and what cgroupfs shows, but it doesn't change any > actual cgroups, nor does it affect any cgroup *changes*. It seems like what we have described is chcgrouproot aka chroot for cgroups. At which point I think there are potentially similar security issues as for chroot. Can we confuse a setuid root process if we make it's cgroup names look different. Of course the confusing root concern is handled by the usual namespace security checks that are already present. I do wonder if we think of this as chcgrouproot if there is a simpler implementation. >>> While we're at it, consider making setns for a cgroupns *not* change >>> the caller's cgroup. Is there any reason it really needs to? >> >> setns doesn't but nsenter is going to need to change the cgroup >> if the pinning requirement is kept. nsenenter is going to want to >> change the cgroup if the pinning requirement is dropped. >> > > It seems easy enough for nsenter to change the cgroup all by itself. Again. I don't think anyone has suggested or implemented anything different. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi: storvsc: Force SPC-3 for Win8 Hosts or Later
This patch forces SPC-3 for Hyper-V disks on the VMBus. As Windows 10's
virtual SAS bus is SPC-3 compliant and there are no negative side effects
on forcing SPC-3 compliance for Win8 hosts, this patch enables SPC-3
compliance by forcing it on for hosts with versions later than Win8.
Forcing SPC-3 compliance for hosts earlier than Win10 also enables
TRIM support.
Suggested by: James Bottomley
Signed-off-by: Jeff Leung
---
drivers/scsi/storvsc_drv.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index ed0f899..afcc68e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1449,6 +1449,15 @@ static int storvsc_device_configure(struct scsi_device
*sdevice)
sdevice->no_write_same = 1;
+ /*
+* If the host is Win2k12 or later, we pretend to be SPC-3 compliant
+* and send RC16 which activates TRIM. We will only enable this on a
+* host with levels greater than VERSION_WIN8
+*/
+ if (vmbus_proto_version >= VERSION_WIN8) {
+ sdevice->scsi_level = SCSI_SPC_3;
+ }
+
return 0;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/5] x86: Add a comment clarifying LDT context switching
On Thu, Oct 16, 2014 at 09:21:42AM -0700, Andy Lutomirski wrote: > I think it's the same as in the other case in switch_mm. leave_mm does > cpumask_clear_cpu(cpu, mm_cpumask(active_mm)), and, once that has > happened, modify_ldt won't send an IPI to this CPU. So, if leave_mm > runs, and then another CPU calls modify_ldt on the mm that is in lazy > mode here, it won't update our LDT register, so the LDT register and > prev->context.ldt might not match. Ok, let me see if I can follow with an example: We call leave_mm() on, say, cpu 3 and mm_cpumask(active_mm) has cpu 3 and 4 set. Then, on cpu 4 we call modify_ldt on that same mm and there in alloc_ldt() we have this: if (!cpumask_equal(mm_cpumask(current->mm), cpumask_of(smp_processor_id( smp_call_function(flush_ldt, current->mm, 1); and since we've cleared cpu 3 from the cpumask, we don't flush_ldt() on it and there you have the difference. Am I close? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi: storvsc: Force SPC-3 for Win8 Hosts or Later
This patch forces SPC-3 for Hyper-V disks on the VMBus. As Windows 10's
virtual SAS bus is SPC-3 compliant and there are no negative side effects
on forcing SPC-3 compliance for Win8 hosts, this patch enables SPC-3
compliance by forcing it on for hosts with versions later than Win8.
Forcing SPC-3 compliance for hosts earlier than Win10 also enables
TRIM support.
Suggested by: James Bottomley
Signed-off-by: Jeff Leung
---
drivers/scsi/storvsc_drv.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index ed0f899..afcc68e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1449,6 +1449,15 @@ static int storvsc_device_configure(struct scsi_device
*sdevice)
sdevice->no_write_same = 1;
+ /*
+* If the host is Win2k12 or later, we pretend to be SPC-3 compliant
+* and send RC16 which activates TRIM. We will only enable this on a
+* host with levels greater than VERSION_WIN8
+*/
+ if (vmbus_proto_version >= VERSION_WIN8) {
+ sdevice->scsi_level = SCSI_SPC_3;
+ }
+
return 0;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] dirreadahead system call
- Original Message - > From: "Dave Chinner" > To: "Andreas Dilger" > Cc: "Abhijith Das" , "LKML" , > "linux-fsdevel" > , cluster-de...@redhat.com > Sent: Thursday, July 31, 2014 6:53:06 PM > Subject: Re: [RFC PATCH 0/2] dirreadahead system call > > On Thu, Jul 31, 2014 at 01:19:45PM +0200, Andreas Dilger wrote: > > On Jul 31, 2014, at 6:49, Dave Chinner wrote: > > > > > >> On Mon, Jul 28, 2014 at 03:19:31PM -0600, Andreas Dilger wrote: > > >>> On Jul 28, 2014, at 6:52 AM, Abhijith Das wrote: > > >>> OnJuly 26, 2014 12:27:19 AM "Andreas Dilger" wrote: > > Is there a time when this doesn't get called to prefetch entries in > > readdir() order? It isn't clear to me what benefit there is of > > returning > > the entries to userspace instead of just doing the statahead > > implicitly > > in the kernel? > > > > The Lustre client has had what we call "statahead" for a while, > > and similar to regular file readahead it detects the sequential access > > pattern for readdir() + stat() in readdir() order (taking into account > > if > > ".*" > > entries are being processed or not) and starts fetching the inode > > attributes asynchronously with a worker thread. > > >>> > > >>> Does this heuristic work well in practice? In the use case we were > > >>> trying to > > >>> address, a Samba server is aware beforehand if it is going to stat all > > >>> the > > >>> inodes in a directory. > > >> > > >> Typically this works well for us, because this is done by the Lustre > > >> client, so the statahead is hiding the network latency of the RPCs to > > >> fetch attributes from the server. I imagine the same could be seen with > > >> GFS2. I don't know if this approach would help very much for local > > >> filesystems because the latency is low. > > >> > > This syscall might be more useful if userspace called readdir() to get > > the dirents and then passed the kernel the list of inode numbers > > to prefetch before starting on the stat() calls. That way, userspace > > could generate an arbitrary list of inodes (e.g. names matching a > > regexp) and the kernel doesn't need to guess if every inode is needed. > > >>> > > >>> Were you thinking arbitrary inodes across the filesystem or just a > > >>> subset > > >>> from a directory? Arbitrary inodes may potentially throw up locking > > >>> issues. > > >> > > >> I was thinking about inodes returned from readdir(), but the syscall > > >> would be much more useful if it could handle arbitrary inodes. > > > > > > I'm not sure we can do that. The only way to safely identify a > > > specific inode in the filesystem from userspace is via a filehandle. > > > Plain inode numbers are susceptible to TOCTOU race conditions that > > > the kernel cannot resolve. Also, lookup by inode number bypasses > > > directory access permissions, so is not something we would expose > > > to arbitrary unprivileged users. > > > > None of these issues are relevant in the API that I'm thinking about. > > The syscall just passes the list of inode numbers to be prefetched > > into kernel memory, and then stat() is used to actually get the data into > > userspace (or whatever other operation is to be done on them), > > so there is no danger if the wrong inode is prefetched. If the inode > > number is bad the filesystem can just ignore it. > > Which means the filesystem has to treat the inode number as > potentially hostile. i.e. it can not be trusted to be correct and so > must take slow paths to validate the inode numbers. This adds > *significant* overhead to the readahead path for some filesystems: > readahead is only a win if it is low cost. > > For example, on XFS every untrusted inode number lookup requires an > inode btree lookup to validate the inode is actually valid on disk > and that is it allocated and has references. That lookup serialises > against inode allocation/freeing as well as other lookups. In > comparison, when using a trusted inode number from a directory > lookup within the kernel, we only need to do a couple of shift and > mask operations to convert it to a disk address and we are good to > go. > > i.e. the difference is at least 5 orders of magnitude higher CPU usage > for an "inode number readahead" syscall versus a "directory > readahead" syscall, it has significant serialisation issues and it > can stall other modification/lookups going on at the same time. > That's *horrible behaviour* for a speculative readahead operation, > but because the inodenumbers are untrusted, we can't avoid it. > > So, again, it's way more overhead than userspace just calling > stat() asycnhronously on many files at once as readdir/gentdents > returns dirents from the kernel to speed up cache population. > > That's my main issue with this patchset - it's implementing > something in kernelspace that can *easily* be done generically in > userspace without introducing all sorts of
RE: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
> Is it OK to replace a scsi_level of SCSI-2 with SCSI_SPC_3? Additionally is > it also OK to force > SCSI_SPC_3 on Hyper-V 2008? I would patch the driver accordingly to force the SPC-3 flag. For a Win2k8 host, I don't know what the side effects are, so it's safe to say it's not a good idea to Force SCSI_SPC_3
GPIO bindings guidelines (Was: Re: [PATCH v5 10/12] gpio: Support for unified device properties interface)
On Mon, Oct 20, 2014 at 11:26 PM, Arnd Bergmann wrote: > On Monday 20 October 2014 15:12:50 Alexandre Courbot wrote: >> On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann wrote: >> > On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote: >> >> On October 17, 2014 2:16:00 PM CEST, "Rafael J. Wysocki" >> >> wrote: >> >> >From: Mika Westerberg >> >> > >> >> >Some drivers need to deal with only firmware representation of its >> >> >GPIOs. An example would be a GPIO button array driver where each button >> >> >is described as a separate firmware node in device tree. Typically >> >> >these >> >> >child nodes do not have physical representation in the Linux device >> >> >model. >> >> > >> >> >In order to help device drivers to handle such firmware child nodes we >> >> >add dev[m]_get_named_gpiod_from_child() that takes a child firmware >> >> >node pointer as its second argument (the first one is the parent device >> >> >itself), finds the GPIO using whatever is the underlying firmware >> >> >method, and requests the GPIO properly. >> >> >> >> Could we also have a wrapper around this function without a "name" >> >> argument, >> >> using just the index? >> > >> > Expanding on this thought: I think we should mandate for new bindings >> > that they use either a name and no index, or an index but not name, >> >> I'm afraid this could forbid some useful use-cases, namely the ones >> where several GPIOs serve the same function (and are typically set >> together). We had a few patch proposals to handle such GPIO groups, >> and even though one was in pretty good shape the submitter did not >> push it until the end. :/ >> >> But my concern is that instead of having this: >> >> enable-gpio = < 0 GPIO_ACTIVE_HIGH>; >> value-gpios = < 1 GPIO_ACTIVE_HIGH ... 8 GPIO_ACTIVE_HIGH>; >> >> We would force this: >> >> enable-gpio = < 0 GPIO_ACTIVE_HIGH>; >> value0-gpio = < 1 GPIO_ACTIVE_HIGH>; >> ... >> value7-gpio = < 8 GPIO_ACTIVE_HIGH>; >> >> Or this: >> >> // First GPIO is enable, other GPIOs are value >> gpios = < 0 GPIO_ACTIVE_HIGH 1 GPIO_ACTIVE_HIGH ... 8 >> GPIO_ACTIVE_HIGH>; >> >> Most bindings don't need that much sophistication, and for these we >> should indeed make sure that they stick to using either the names or >> index (and in a consistent manner), but closing the possibility to use >> both together may bite us in the end. > > I would actually prefer the single-property case here, but I see your > point. Could we make it a strong suggestion rather than a mandatory > requirement for new bindings then? Definitely, and a very strong suggestion even. Having to use both names *and* index in GPIO properties should not be needed 99% of the time. > >> > and I also think that for named gpios, we should try to converge on a >> > common naming scheme. As discussed, we will probably want to support all >> > the existing ways to do this even with ACPI and with the unified >> > interface, but it doesn't have to be the obvious way. >> >> Personally, I like the idea that each GPIO has a function, so now that >> ACPI fully supports this I'd suggest the policy of using names for >> each GPIO (e.g. never use the fallback "gpios" or "gpio" property), >> and only ressort to indexes if several GPIOs happen to serve the same >> function. I know we haven't reached consensus about this so far, but >> it would be nice it we could discuss this point again in the light of >> the new ACPI capabilities and come with something to write as a >> guideline in the GPIO documentation. > > We have enforced naming things for the dmaengine binding, which has > just led to everyone calling things "rx" and "tx". My fear is that > if we start to enforce giving a name, we'd end up with lots of > drivers that use a "gpio-gpios" property or something silly. Checking the bindings is also part of the review process. :) Things like "gpio-gpios" should simply not be accepted to begin with. This sounds like a good chance to finally land some guidelines regarding GPIO bindings. Let's summarize the situation: - GPIO bindings can be defined using both DT and ACPI (both interfaces nicely abstracted by the interface introduced by this series) - Both firmware interfaces support indexed GPIOs - Both firmware interfaces support named GPIO properties, with an optional index (can we absolutely take this for granted on ACPI now?) - For DT bindings, both foo-gpio and foo-gpios are valid properties for the GPIO "foo". That's what we have now and need to maintain. However for new drivers we want to come with guidelines that will hopefully make things easier to review. Here are my thoughts on the topic: - GPIOs have a function, and this function should be the GPIO name. Thus now that ACPI supports named properties, all new GPIO properties *must* have an accurate, explicit name. - Indexes are only used if several GPIOs fulfill the same function (like parallel data lines). This situation should be exceptional. GPIOs not fulfilling the same function are in no way allowed
Re: powerpc: Wire up sys_bpf() syscall
I don't see any problems with it On 10/21/14, Michael Ellerman wrote: > On Tue, 2014-10-21 at 08:52 +0400, Denis Kirjanov wrote: >> We have a test suite under samples/bpf/ > > Thanks. > > I looked under tools/testing/selftests, could it move in there? > > cheers > > > -- Regards, Denis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Wire up sys_bpf() syscall
I don't see any problems with it On 10/21/14, Michael Ellerman wrote: > On Tue, 2014-10-21 at 08:52 +0400, Denis Kirjanov wrote: >> We have a test suite under samples/bpf/ > > Thanks. > > I looked under tools/testing/selftests, could it move in there? > > cheers > > > -- Regards, Denis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: kgdb: fix single stepping
I tried to verify kgdb in vanilla kernel on fast model, but it seems that
the single stepping with kgdb doesn't work correctly since its first
appearance at v3.15.
On v3.15, 'stepi' command after breaking the kernel at some breakpoint
steps forward to the next instruction, but the succeeding 'stepi' never
goes beyond that.
On v3.16, 'stepi' moves forward and stops at the next instruction just
after enable_dbg in el1_dbg, and never goes beyond that. This variance of
behavior seems to come in with the following patch in v3.16:
commit 2a2830703a23 ("arm64: debug: avoid accessing mdscr_el1 on fault
paths where possible")
This patch
(1) moves kgdb_disable_single_step() from 'c' command handling to single
step handler.
This makes sure that single stepping gets effective at every 's' command.
Please note that, under the current implementation, single step bit in
spsr, which is cleared by the first single stepping, will not be set
again for the consecutive 's' commands because single step bit in mdscr
is still kept on (that is, kernel_active_single_step() in
kgdb_arch_handle_exception() is true).
(2) re-implements kgdb_roundup_cpus() because the current implementation
enabled interrupts naively. See below.
(3) removes 'enable_dbg' in el1_dbg.
Single step bit in mdscr is turned on in do_handle_exception()->
kgdb_handle_expection() before returning to debugged context, and if
debug exception is enabled in el1_dbg, we will see unexpected single-
stepping in el1_dbg.
Since v3.18, the following patch does the same:
commit 1059c6bf8534 ("arm64: debug: don't re-enable debug exceptions
on return from el1_dbg)
(4) masks interrupts while single-stepping one instruction.
If an interrupt is caught during processing a single-stepping, debug
exception is unintentionally enabled by el1_irq's 'enable_dbg' before
returning to debugged context.
Thus, like in (2), we will see unexpected single-stepping in el1_irq.
Basically (1) and (2) are for v3.15, (3) and (4) for v3.1[67].
* issue fixed by (2):
Without (2), we would see another problem if a breakpoint is set at
interrupt-sensible places, like gic_handle_irq():
KGDB: re-enter error: breakpoint removed ffc81258
[ cut here ]
WARNING: CPU: 0 PID: 650 at kernel/debug/debug_core.c:435
kgdb_handle_exception+0x1dc/0x1f4()
Modules linked in:
CPU: 0 PID: 650 Comm: sh Not tainted 3.17.0-rc2+ #177
Call trace:
[] dump_backtrace+0x0/0x130
[] show_stack+0x10/0x1c
[] dump_stack+0x74/0xb8
[] warn_slowpath_common+0x8c/0xb4
[] warn_slowpath_null+0x14/0x20
[] kgdb_handle_exception+0x1d8/0x1f4
[] kgdb_brk_fn+0x18/0x28
[] brk_handler+0x9c/0xe8
[] do_debug_exception+0x3c/0xac
Exception stack(0xffc07e027650 to 0xffc07e027770)
...
[] el1_dbg+0x14/0x68
[] kgdb_cpu_enter+0x464/0x5c0
[] kgdb_handle_exception+0x190/0x1f4
[] kgdb_brk_fn+0x18/0x28
[] brk_handler+0x9c/0xe8
[] do_debug_exception+0x3c/0xac
Exception stack(0xffc07e027ac0 to 0xffc07e027be0)
...
[] el1_dbg+0x14/0x68
[] __handle_sysrq+0x11c/0x190
[] write_sysrq_trigger+0x4c/0x60
[] proc_reg_write+0x54/0x84
[] vfs_write+0x98/0x1c8
[] SyS_write+0x40/0xa0
Once some interrupt occurs, a breakpoint at gic_handle_irq() triggers kgdb.
Kgdb then calls kgdb_roundup_cpus() to sync with other cpus.
Current kgdb_roundup_cpus() unmasks interrupts temporarily to
use smp_call_function().
This eventually allows another interrupt to occur and likely results in
hitting a breakpoint at gic_handle_irq() again since debug exception is
always enabled in el1_irq.
We can avoid this issue by specifying "nokgdbroundup" in kernel parameter,
but this will also leave other cpus be in unknown state in terms of kgdb,
and may result in interfering with kgdb activity.
Signed-off-by: AKASHI Takahiro
---
arch/arm64/kernel/kgdb.c | 60 +++---
1 file changed, 46 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a0d10c5..81b5910 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -19,9 +19,13 @@
* along with this program. If not, see
Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
On Mon, Oct 20, 2014 at 9:49 PM, Eric W. Biederman wrote: > Andy Lutomirski writes: > >> On Sun, Oct 19, 2014 at 9:55 PM, Eric W.Biederman >> wrote: >>> >>> >>> On October 19, 2014 1:26:29 PM CDT, Andy Lutomirski >>> wrote: > Is the idea that you want a privileged user wrt a cgroupns's userns to be able to use this? If so: Yes, that current_cred() thing is bogus. (Actually, this is probably exploitable right now if any cgroup.procs inode anywhere on the system lets non-root write.) (Can we have some kernel debugging option that makes any use of current_cred() in write(2) warn?) We really need a weaker version of may_ptrace for this kind of stuff. Maybe the existing may_ptrace stuff is okay, actually. But this is completely missing group checks, cap checks, capabilities wrt the userns, etc. Also, I think that, if this version of the patchset allows non-init userns to unshare cgroupns, then the issue of what permission is needed to lock the cgroup hierarchy like that needs to be addressed, because unshare(CLONE_NEWUSER|CLONE_NEWCGROUP) will effectively pin the calling task with no permission required. Bolting on a fix later will be a mess. >>> >>> I imagine the pinning would be like the userns. >>> >>> Ah but there is a potentially serious issue with the pinning. >>> With pinning we can make it impossible for root to move us to a different >>> cgroup. >>> >>> I am not certain how serious that is but it bears thinking about. >>> If we don't implement pinning we should be able to implent everything with >>> just filesystem mount options, and no new namespace required. >>> >>> Sigh. >>> >>> I am too tired tonight to see the end game in this. >> >> Possible solution: >> >> Ditch the pinning. That is, if you're outside a cgroupns (or you have >> a non-ns-confined cgroupfs mounted), then you can move a task in a >> cgroupns outside of its root cgroup. If you do this, then the task >> thinks its cgroup is something like "../foo" or "../../foo". > > Of the possible solutions that seems attractive to me, simply because > we sometimes want to allow clever things to occur. > > Does anyone know of a reason (beyond pretty printing) why we need > cgroupns to restrict the subset of cgroups processes can be in? > > I would expect permissions on the cgroup directories themselves, and > limited visiblilty would be (in general) to achieve the desired > visiblity. This makes the security impact of cgroupns very easy to understand, right? Because there really won't be any -- cgroupns only affects reads from /proc and what cgroupfs shows, but it doesn't change any actual cgroups, nor does it affect any cgroup *changes*. > >> While we're at it, consider making setns for a cgroupns *not* change >> the caller's cgroup. Is there any reason it really needs to? > > setns doesn't but nsenter is going to need to change the cgroup > if the pinning requirement is kept. nsenenter is going to want to > change the cgroup if the pinning requirement is dropped. > It seems easy enough for nsenter to change the cgroup all by itself. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/2] x86_64: expand kernel stack to 16K
On 10/20/2014 07:00 PM, Dave Jones wrote: > On Fri, May 30, 2014 at 08:41:00AM -0700, Linus Torvalds wrote: > > On Fri, May 30, 2014 at 8:25 AM, H. Peter Anvin wrote: > > > > > > If we removed struct thread_info from the stack allocation then one > > > could do a guard page below the stack. Of course, we'd have to use IST > > > for #PF in that case, which makes it a non-production option. Why is thread_info in the stack allocation anyway? Every time I look at the entry asm, one (minor) thing that contributes to general brain-hurtingness / sense of horrified awe is the incomprehensible (to me) split between task_struct and thread_info. struct thread_info is at the bottom of the stack, right? If we don't want to merge it into task_struct, couldn't we stick it at the top of the stack instead? Anything that can overwrite the *top* of the stack gives trivial user-controlled CPL0 execution regardless. > > > > We could just have the guard page in between the stack and the > > thread_info, take a double fault, and then just map it back in on > > double fault. > > > > That would give us 8kB of "normal" stack, with a very loud fault - and > > then an extra 7kB or so of stack (whatever the size of thread-info is) > > - after the first time it traps. > > > > That said, it's still likely a non-production option due to the page > > table games we'd have to play at fork/clone time. What's wrong with vmalloc? Doesn't it already have guard pages? (Also, we have a shiny hardware dirty bit, so we could relatively cheaply check whether we're near the limit without any weird #PF-in-weird-context issues.) Also, muahaha, I've infected more people with the crazy idea that intentional double-faults are okay. Suckers! Soon I'll have Linux returning from interrupts with lret! (IIRC Windows used to do intentional *triple* faults on context switches, so this should be considered entirely sensible.) > > [thread necrophilia] > > So digging this back up, it occurs to me that after we bumped to 16K, > we never did anything like the debug stuff you suggested here. > > The reason I'm bringing this up, is that the last few weeks, I've been > seeing things like.. > > [27871.793753] trinity-c386 (28793) used greatest stack depth: 7728 bytes left > > So we're now eating past that first 8KB in some situations. > > Do we care ? Or shall we only start worrying if it gets even deeper ? I would *love* to have an immediate, loud failure when we overrun the stack. This will unavoidably increase the number of TLB misses, but that probably isn't so bad. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel, add bug_on_warn
Hi Prarit, (2014/10/21 9:54), Prarit Bhargava wrote: On 10/20/2014 06:24 PM, Andrew Morton wrote: On Mon, 20 Oct 2014 08:00:20 -0400 Prarit Bhargava wrote: There have been several times where I have had to rebuild a kernel to cause a panic when hitting a WARN() in the code in order to get a crash dump from a system. Sometimes this is easy to do, other times (such as in the case of a remote admin) it is not trivial to send new images to the user. A much easier method would be a switch to change the WARN() over to a BUG(). This makes debugging easier in that I can now test the actual image the WARN() was seen on and I do not have to engage in remote debugging. This patch adds a bug_on_warn kernel parameter, which calls BUG() in the warn_slowpath_common() path. The function will still print out the location of the warning. Successfully tested by me. Looks nice and simple and useful. However I suspect you're exclusively focussed on "I want a crash dump" and things haven't been fully thought through. - Do you have any example WARN->BUG console output at hand? I'd like to check for missing or duplicated info. Yep, here you go, with some additional annotation notes from me. The first line below is from the WARN_ON() to output the WARN_ON()'s location. After that, we hit the new BUG() call. WARNING: CPU: 27 PID: 3204 at /home/rhel7/redhat/debug/dummy-module/dummy-module.c:25 init_dummy+0x28/0x30 [dummy_module]() bug_on_warn set, calling BUG()... [ cut here ] kernel BUG at kernel/panic.c:434! invalid opcode: [#1] SMP Modules linked in: dummy_module(OE+) sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel igb iTCO_wdt aesni_intel iTCO_vendor_support lrw gf128mul sb_edac ptp edac_core glue_helper lpc_ich ioatdma pcspkr ablk_helper pps_core i2c_i801 mfd_core cryptd dca shpchp ipmi_si wmi ipmi_msghandler acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c sr_mod cdrom sd_mod mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper isci ttm drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod CPU: 27 PID: 3204 Comm: insmod Tainted: G OE 3.17.0+ #19 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.131329 11/11/2013 task: 880034e75160 ti: 8807fc5ac000 task.ti: 8807fc5ac000 RIP: 0010:[] [] warn_slowpath_common+0xc1/0xd0 RSP: 0018:8807fc5afc68 EFLAGS: 00010246 RAX: 0021 RBX: 8807fc5afcb0 RCX: RDX: RSI: 88081efee5f8 RDI: 88081efee5f8 RBP: 8807fc5afc98 R08: 0096 R09: R10: 0711 R11: 8807fc5af93e R12: a0424070 R13: 0019 R14: a0423068 R15: 0009 FS: 7f2d4b034740() GS:88081efe() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f2d4a99f3c0 CR3: 0007fd88b000 CR4: 001407e0 Stack: 8807fc5afcb8 8199f020 88080e396160 a0423040 a0425000 8807fc5afd08 81076be5 0008 a0424053 88070018 8807fc5afd18 Call Trace: [] ? dummy_greetings+0x40/0x40 [dummy_module] [] warn_slowpath_fmt+0x55/0x70 [] init_dummy+0x28/0x30 [dummy_module] [] do_one_initcall+0xd4/0x210 [] ? __vunmap+0xc2/0x110 [] load_module+0x16a9/0x1b30 [] ? store_uevent+0x70/0x70 [] ? copy_module_from_fd.isra.44+0x129/0x180 [] SyS_finit_module+0xa6/0xd0 [] system_call_fastpath+0x12/0x17 Code: c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 c7 c7 20 42 8a 81 31 c0 e8 fc 80 5e 00 eb 80 48 c7 c7 78 42 8a 81 31 c0 e8 ec 80 5e 00 <0f> 0b 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 RIP [] warn_slowpath_common+0xc1/0xd0 RSP ---[ end trace 428218934a12088b ]--- - Did you consider permitting this to be tweaked at runtime via /proc? Sometimes we get pesky WARNs at boot time and having runtime alteration would permit the user to prevent those from tripping a BUG. I did actually, but I was wondering how people liked the idea before I looked at the /proc implementation. It's pretty much the same as panic_on_oops, so it's not difficult to do. - Also, perhaps bug_on_warn should be single-shot: clear itself after it has triggered one BUG. Because once the kernel has gone WARN->BUG, it's probably messed up and is likely to trigger more WARNs. Also, the kernel might generate many WARNs for the same issue. Okay, I'll add that. When you update it, please CC me. Your patch works well as follows: WARNING: CPU: 3 PID: 468 at mm/page_alloc.c:4968 free_area_init_node+0x3fe/0x426() bug_on_warn set, calling BUG()... [ cut here
RE: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for do_adjtimex()
> -Original Message- > From: Jeff Epler [mailto:jep...@unpythonic.net] > Sent: Tuesday, October 21, 2014 12:02 PM > To: Thomas Shao > Cc: Thomas Gleixner; gre...@linuxfoundation.org; LKML; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; KY Srinivasan; John Stultz; Richard Cochran > Subject: Re: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for > do_adjtimex() > > On Tue, Oct 21, 2014 at 03:18:58AM +, Thomas Shao wrote: > > In some situation, the user is not able to enable guest VM to sync > > with external time source, like NTP. But the host is still synced with a > trusted time source. > > In this case, host-guest time synchronization is useful. > > It's interesting to imagine that a virtualization host could present a time > service to the guest *userspace*, even when the guest is not otherwise > exposed to the internet at large. This could take the form of an NTP server > on a private network, or as an implementation of a time source directly > usable by ntpd in the guest, for instance as an emulated serial port with > synthetic NEMA GPS signal + PPS signal, for instance. Yeah. There is already some guidance about how to setup a local NTP server. But it requires some additional efforts for IT admins. I don't think we need configure every host as a time source. Typically we could setup one server shared by the private network, and that server needs to be synced with upstream NTP server. I'm also thinking if NTPd could expose some interface to allow other application to directly provide time source for it to consume. In my opinion, emulating the ntp source should be very hard and error prone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Wire up sys_bpf() syscall
On Tue, 2014-10-21 at 08:52 +0400, Denis Kirjanov wrote: > We have a test suite under samples/bpf/ Thanks. I looked under tools/testing/selftests, could it move in there? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Wire up sys_bpf() syscall
We have a test suite under samples/bpf/ On 10/21/14, Michael Ellerman wrote: > On Fri, 2014-10-10 at 05:53:45 UTC, Pranith Kumar wrote: >> This patch wires up the new syscall sys_bpf() on powerpc. > > Is there a test suite we can run to verify it works? > > cheers > ___ > Linuxppc-dev mailing list > linuxppc-...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev -- Regards, Denis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv1 7/8] cgroup: cgroup namespace setns support
Andy Lutomirski writes: > On Sun, Oct 19, 2014 at 9:55 PM, Eric W.Biederman > wrote: >> >> >> On October 19, 2014 1:26:29 PM CDT, Andy Lutomirski >> wrote: >>> Is the idea >>>that you want a privileged user wrt a cgroupns's userns to be able to >>>use this? If so: >>> >>>Yes, that current_cred() thing is bogus. (Actually, this is probably >>>exploitable right now if any cgroup.procs inode anywhere on the system >>>lets non-root write.) (Can we have some kernel debugging option that >>>makes any use of current_cred() in write(2) warn?) >>> >>>We really need a weaker version of may_ptrace for this kind of stuff. >>>Maybe the existing may_ptrace stuff is okay, actually. But this is >>>completely missing group checks, cap checks, capabilities wrt the >>>userns, etc. >>> >>>Also, I think that, if this version of the patchset allows non-init >>>userns to unshare cgroupns, then the issue of what permission is >>>needed to lock the cgroup hierarchy like that needs to be addressed, >>>because unshare(CLONE_NEWUSER|CLONE_NEWCGROUP) will effectively pin >>>the calling task with no permission required. Bolting on a fix later >>>will be a mess. >> >> I imagine the pinning would be like the userns. >> >> Ah but there is a potentially serious issue with the pinning. >> With pinning we can make it impossible for root to move us to a different >> cgroup. >> >> I am not certain how serious that is but it bears thinking about. >> If we don't implement pinning we should be able to implent everything with >> just filesystem mount options, and no new namespace required. >> >> Sigh. >> >> I am too tired tonight to see the end game in this. > > Possible solution: > > Ditch the pinning. That is, if you're outside a cgroupns (or you have > a non-ns-confined cgroupfs mounted), then you can move a task in a > cgroupns outside of its root cgroup. If you do this, then the task > thinks its cgroup is something like "../foo" or "../../foo". Of the possible solutions that seems attractive to me, simply because we sometimes want to allow clever things to occur. Does anyone know of a reason (beyond pretty printing) why we need cgroupns to restrict the subset of cgroups processes can be in? I would expect permissions on the cgroup directories themselves, and limited visiblilty would be (in general) to achieve the desired visiblity. > While we're at it, consider making setns for a cgroupns *not* change > the caller's cgroup. Is there any reason it really needs to? setns doesn't but nsenter is going to need to change the cgroup if the pinning requirement is kept. nsenenter is going to want to change the cgroup if the pinning requirement is dropped. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: base: update cpu offline info when do hotplug
(2014/10/21 12:36), Neil Zhang wrote:
-Original Message-
From: Yasuaki Ishimatsu [mailto:isimatu.yasu...@jp.fujitsu.com]
Sent: 2014年10月21日 11:27
To: Neil Zhang; Dan Streetman
Cc: Greg KH; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: base: update cpu offline info when do hotplug
(2014/10/21 12:18), Neil Zhang wrote:
Yasuaki,
-Original Message-
From: Yasuaki Ishimatsu [mailto:isimatu.yasu...@jp.fujitsu.com]
Sent: 2014年10月21日 10:57
To: Dan Streetman; Neil Zhang
Cc: Greg KH; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: base: update cpu offline info when do
hotplug
Hi Neil and Dan,
(2014/10/21 2:02), Dan Streetman wrote:
On Mon, Oct 20, 2014 at 3:40 AM, Neil Zhang wrote:
Greg,
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: 2014年10月20日 14:48
To: Neil Zhang
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: base: update cpu offline info when do
hotplug
On Sun, Oct 19, 2014 at 11:39:23PM -0700, Neil Zhang wrote:
How much noise is this going to cause on a big/little system that
constantly hot unplug/plugs processors all of the time?
Can you explain more what kind of noise will be introduced on a
big/little
system?
Have you tested this on such a machine?
I didn't have such kind of machine on hand.
Can anyone has such machine to verify it?
Thanks!
I tested this on a ppc PowerVM system, using dlpar operations to
remove/add cpus.
Without this patch the cpu online nodes get out of sync with the
main online node (and the actual state of the cpus), because they
aren't updated as the cpus are brought up/down:
[root@br10p02 cpu]$ pwd
/sys/devices/system/cpu
[root@br10p02 cpu]$ cat online
0-39
[root@br10p02 cpu]$ for n in {0..47} ; do test $( cat cpu$n/online )
-eq 1 && echo -n "$n " ; done ; echo ""
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
26
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
How is the issue reproduced.
Here is a result on my x86 box with linux-3.18-rc1.
- before offline CPU
# cd /sys/devices/system/cpu/
# cat online
0-59
# for n in {0..59} ; do test $( cat cpu$n/online ) -eq 1 && echo -n
"$n " ; done ; echo ""
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
26 27 28
29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
52 53 54
55
56 57 58 59
- after offline CPU{1..59}
# for n in {1..59} ; do echo 0 > cpu$n/online; done # cat online
0
# for n in {0..59} ; do test $( cat cpu$n/online ) -eq 1 && echo -n
"$n " ; done ; echo ""
0
It seems that dev->offline is set to correct valute.
Please use an in kernel governor to up / down a core instead of sysfs
interface.
Thank you for the information. But I don't know the in kernel governor?
Could you point a documentation of it?
Simply means that you call cpu_down / cpu_up directly in kernel base on the
profiler.
I understood it.
When using sysfs, device_online/offline() changes dev->offline.
Therefore, this problem did not occur in my previous test.
Thanks,
Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
While with the patch, the cpu online nodes are kept up to date as
the cpus are brought up/down:
[root@br10p02 cpu]$ pwd
/sys/devices/system/cpu
[root@br10p02 cpu]$ cat online
0-39
[root@br10p02 cpu]$ for n in {0..47} ; do test $( cat cpu$n/online )
-eq 1 && echo -n "$n " ; done ; echo ""
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
26
27 28 29 30 31 32 33 34 35 36 37 38 39
Feel free to add
Tested-by: Dan Streetman
As I know IKS on arm will use cpu_suspend way to power down a core.
Are you sure that it also doesn't use that same functionality to
drop a
processor to save power?
As I know it use cpu_suspend to switch out a processor in IKS and
there is
no cpu hotplug notifier in this procedure.
Why do you need/want this notification? What are you going to do
with this
information that you don't already have?
The offline won't be updated if an in kernel hotplug governor plug
in / out
a core which cause the sysfs interface report a wrong status.
thanks,
greg k-h
Best Regards,
Neil Zhang
--
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Best Regards,
Neil Zhang
{.n + +% lzwm b 맲 r zX w {ay ʇڙ ,j
f h z w
j:+v w j m zZ+ ݢj" ! iO z v ^ m
nÆŠ Y&
Best Regards,
Neil Zhang
��칻 �&�~�&���+-��ݶ��w��˛���m�b��dz�ޖ)���w* jg��� �ݢj/���z�ޖ��2�ޙ���&�)ߡ�a���� �G���h��j:+v���w�٥>Wi�axPj�m
-�+��d�_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
On Sun, Oct 12, 2014 at 01:21:01AM +, KY Srinivasan wrote:
>
> > -Original Message-
> > From: Jeff Leung [mailto:jle...@v10networks.ca]
> > Sent: Saturday, October 11, 2014 1:22 PM
> >
> > > On the current release of Windows (windows 10), we are advertising
> > > SPC3 compliance.
> > > We are ok with declaring compliance to SPC3 in our drivers.
> > If you are going to declare SPC3 compliance in the drivers, are you going to
> > put in checks to ensure that SPC-3 compliance doesn't get accidentally
> > enabled for hypervisors below Win10?
> >
> > I do know for a fact that Ubuntu's kernels already force SPC3 compliance to
> > enable specific features such as TRIM on earlier versions of Hyper-V (Namely
> > Hyper-V 2012 and 2012 R2).
> You are right; Ubuntu has been carrying a patch that was doing just
> this and this has been working without any issues on many earlier
> versions of Windows. (2012 and 2012 R2). On windows 10 we don't need
> any changes in the Linux driver as the host itself is advertising SPC3
> compliance. Based on the testing we have done with Ubuntu, we are
> comfortable picking up that patch.
OK this seems to be the patch currently carried by Ubuntu:
>From ff2c5fa3fa9adf0b919b9425e71a8ba044c31a7d Mon Sep 17 00:00:00 2001
From: Andy Whitcroft
Date: Fri, 13 Sep 2013 17:49:16 +0100
Subject: [PATCH] scsi: hyper-v storsvc switch up to SPC-3
Suggested-By: James Bottomley
Signed-off-by: Andy Whitcroft
---
drivers/scsi/storvsc_drv.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 9969fa1..3903c8a 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1441,6 +1441,14 @@ static int storvsc_device_configure(struct scsi_device
*sdevice)
sdevice->no_write_same = 1;
+ /*
+* hyper-v lies about its capabilities indicating it is only SPC-2
+* compliant, but actually implements the core SPC-3 features.
+* If we pretend to be SPC-3, we send RC16 which activates trim and
+* will query the appropriate VPD pages to enable trim.
+*/
+ sdevice->scsi_level = SCSI_SPC_3;
+
return 0;
}
--
1.7.9.5
(Downloaded from
http://kernel.ubuntu.com/git?p=jsalisbury/stable/trusty/ubuntu-trusty.git;a=patch;h=ff2c5fa3fa9adf0b919b9425e71a8ba044c31a7d
).
I think it's unwise to override the scsi_level at this particular point
because you are going to do it for ALL Hyper-V "disks" (perhaps all
Hyper-V SCSI devices?)...
Here's the SCSI inquiry information reported by a USB 2 hard disk being
passed passed-through by one of my 2012 R2 hosts:
# sg_inq /dev/sdc
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=1
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=0
length=36 (0x24) Peripheral device type: disk
Vendor identification: MDT MD50
Product identification: 00AAKS-00TMA0
Product revision level:
Is it OK to replace a scsi_level of SCSI-2 with SCSI_SPC_3? Additionally
is it also OK to force SCSI_SPC_3 on Hyper-V 2008?
> > > NryزXvؖ){nlj{zX}zj:v zZzf~zwڢ)jyA
> > >
> > > i
> N?r??yb?X??ǧv?^?)Þº{.n?+{zX????ܨ}???Æ z?:+v???zZ+??+zf???h???~i???z? ?w?&?)ߢf??^jÇ«y?m??@A?a???
> 0??h???i
^^^ Where do these characters come from? I've occasionally seen them on
emails from other Microsoft folks posting to LKML too...
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] x86: Disentangle the vdso and clean it up
On Mon, Oct 20, 2014 at 3:41 PM, Andy Lutomirski wrote: > On Mon, Oct 20, 2014 at 3:03 PM, H. Peter Anvin wrote: >> On 10/20/2014 02:57 PM, Andy Lutomirski wrote: >>> >>> Should I send a replacement for patch 8 or should I let you merge 1-7 >>> and fold this into the followup series? >>> >> >> Please send a replacement. > > Sending in a sec. > > Also, this is really weird. Unless I'm completely nuts, lsl is faster > in KVM than it is on bare metal. This makes me wonder whether > something's suboptimal about the way that the GDT is set up. sgdt is > faster, too. This is Sandy Bridge E, one socket. The difference is > big enough that tracking it down might be a significant win on context > switches. Any hints? > This may just be a weird cpufreq artifact. I need to improve my test tools :/ --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Wire up sys_bpf() syscall
On Fri, 2014-10-10 at 05:53:45 UTC, Pranith Kumar wrote: > This patch wires up the new syscall sys_bpf() on powerpc. Is there a test suite we can run to verify it works? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call
Andy Lutomirski writes:
> On Mon, Oct 20, 2014 at 6:48 AM, David Drysdale wrote:
>> On Sun, Oct 19, 2014 at 1:20 AM, Eric W. Biederman
>> wrote:
>>> Andy Lutomirski writes:
>>>
[Added Eric Biederman, since I think your tree might be a reasonable
route forward for these patches.]
On Thu, Jun 5, 2014 at 6:40 AM, David Drysdale wrote:
> Resending, adding cc:linux-api.
>
> Also, it may help to add a little more background -- this patch is
> needed as a (small) part of implementing Capsicum in the Linux kernel.
>
> Capsicum is a security framework that has been present in FreeBSD since
> version 9.0 (Jan 2012), and is based on concepts from object-capability
> security [1].
>
> One of the features of Capsicum is capability mode, which locks down
> access to global namespaces such as the filesystem hierarchy. In
> capability mode, /proc is thus inaccessible and so fexecve(3) doesn't
> work -- hence the need for a kernel-space
I just found myself wanting this syscall for another reason: injecting
programs into sandboxes or otherwise heavily locked-down namespaces.
For example, I want to be able to reliably do something like nsenter
--namespace-flags-here toybox sh. Toybox's shell is unusual in that
it is more or less fully functional, so this should Just Work (tm),
except that the toybox binary might not exist in the namespace being
entered. If execveat were available, I could rig nsenter or a similar
tool to open it with O_CLOEXEC, enter the namespace, and then call
execveat.
Is there any reason that these patches can't be merged more or less as
is for 3.19?
>>>
>>> Yes. There is a silliness in how it implements fexecve. The fexecve
>>> case should be use the empty string "" not a NULL pointer to indication
>>> that. That change will then harmonize execveat with the other ...at
>>> system calls and simplify the code and remove a special case. I believe
>>> using the empty string "" requires implementing the AT_EMPTY_PATH flag.
>>
>> Good point -- I'll shift to "" + AT_EMPTY_PATH.
>
> Pending a better idea, I would also see if the patches can be changed
> to return an error if d_path ends up with an "(unreachable)" thing
> rather than failing inexplicably later on.
For my reference we are talking about
> @@ -1489,7 +1524,21 @@ static int do_execve_common(struct filename *filename,
> sched_exec();
>
> bprm->file = file;
> - bprm->filename = bprm->interp = filename->name;
> + if (filename && fd == AT_FDCWD) {
> + bprm->filename = filename->name;
> + } else {
> + pathbuf = kmalloc(PATH_MAX, GFP_TEMPORARY);
> + if (!pathbuf) {
> + retval = -ENOMEM;
> + goto out_unmark;
> + }
> + bprm->filename = d_path(>f_path, pathbuf, PATH_MAX);
> + if (IS_ERR(bprm->filename)) {
> + retval = PTR_ERR(bprm->filename);
> + goto out_unmark;
> + }
> + }
> + bprm->interp = bprm->filename;
>
> retval = bprm_mm_init(bprm);
> if (retval)
The interesting case for fexecve is when we either don't know what files
are present or we don't want to depend on which files are present.
As Al pointed out d_path really isn't the right solution. It fails when
printing /proc/self/fd/${fd}/${filename->name} would work, and the
"(deleted)" or "(unreachable)" strings are wrong.
The test for today's cases should be:
if ((filename->name[0] == '/') || fd == AT_FDCWD) {
bprm->filename = filename->name;
}
To handle the case where the file descriptor is relevant.
For the case where the file descriptor is relevant let me suggest
setting bprm->filename and bprm->interp to:
/dev/fd/${fd}/${filename->name}
It is more a description of what we have done but as a magic string it
is descriptive. Documetation/devices.txt documents that /dev/fd/ should
exist, making it an unambiguous path. Further these days the kernel
sets the device naming policy in dev, so I think we are strongly safe in
using that path in any event.
I think execveat is interesting in the kernel because the motivating
cases are the cases where anything except a static executable is
uninteresting.
Now it has been suggested creating a dupfs or a mini-proc. I think that
sounds like a nice companion, to the concept of a locked down root.
But I don't think it removes the need for execveat (because we still
have the case where we don't want to care what is mounted, and are happy
to use static executables).
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: vga and 64-bit memcpy's
On 13 September 2014 01:11, Linus Torvalds wrote: > On Fri, Sep 12, 2014 at 3:48 AM, Dave Airlie wrote: >> >> Well I'm not shocked that an SMI GPU is out of spec, just not sure how >> we can workaround it. > > Try just removing the > > #define scr_memcpyw(d, s, c) memcpy(d, s, c) > #define VT_BUF_HAVE_MEMCPYW > > (and perhaps MEMMOVEW case too) from the default implementation, and > see if doing things 16-bit words at a time using the fallbacks ends up > working. As Alan said, write combining might defeat that, but quite > frankly, we already do this for the MEMSETW case (probably because we > forgot, possibly because it's not as performance-sensitive) > > My gut feel is that we don't care deeply about performance here, > because (a) true text-modes are less common anyway and (b) true text > modes are pretty damn fast anyway compared to the more usual "write > the whole glyph as graphics" fbcon case. > > And *maybe* it works. And maybe that SMI GPU is a piece of shit that > isn't worth worrying about in VGA text-mode. Where the hell are they > found anyway? Sorry I let this fall off the planet, some huawei x86 server has this behaviour, works with RHEL5 32-bit, fails with RHEL6 64-bit. //#define scr_memcpyw(d, s, c) memcpy(d, s, c) //#define scr_memmovew(d, s, c) memmove(d, s, c) //#define VT_BUF_HAVE_MEMCPYW //#define VT_BUF_HAVE_MEMMOVEW was tested and found to work, just a question if we care enough to fix it I suppose. Dave. The info I have > >Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/5] CR4 handling improvements
On Mon, Oct 20, 2014 at 9:06 PM, Vince Weaver wrote: > On Tue, 14 Oct 2014, Andy Lutomirski wrote: > >> This little series tightens up rdpmc permissions. With it applied, >> rdpmc can only be used if a perf_event is actually mmapped. For now, >> this is only really useful for seccomp. > > So just to be difficult... > > I am aware of at least one group who is doing low-latency performance > measures using rdpmc on Linux. > > They start the counters manually by poking the MSRs directly (bypassing > perf_event_open()). > > They use rdpmc, grateful for the fact that currently CR4 is set up so they > can do this w/o patching the kernel. > > These patches of course would break this use case... ISTM it would be a lot better to use the perf subsystem for this. You can probably pin an event to a pmu. I don't know whether you can pin an event systemwide. I also don't know whether pinning an event will prevent perf from changing its value periodically, and it certainly doesn't magically make wraparound issues go away. It would be easy to add a new setting for rdpmc to deal with the PCE part. E.g. rdpmc = 2 could allow all tasks to use rdpmc regardless of whether they have an event mapped. (And I would have to re-add the static key. Sigh.) --Andy P.S. Hey, Intel, you forgot to add rdpmcp :-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 01/47] kernel: Add support for poweroff handler call chain
Various drivers implement architecture and/or device specific means to
remove power from the system. For the most part, those drivers set the
global variable pm_power_off to point to a function within the driver.
This mechanism has a number of drawbacks. Typically only one scheme
to remove power is supported (at least if pm_power_off is used).
At least in theory there can be multiple means remove power, some of
which may be less desirable. For example, some mechanisms may only
power off the CPU or the CPU card, while another may power off the
entire system. Others may really just execute a restart sequence
or drop into the ROM monitor. Using pm_power_off can also be racy
if the function pointer is set from a driver built as module, as the
driver may be in the process of being unloaded when pm_power_off is
called. If there are multiple poweroff handlers in the system, removing
a module with such a handler may inadvertently reset the pointer to
pm_power_off to NULL, leaving the system with no means to remove power.
Introduce a system poweroff handler call chain to solve the described
problems. This call chain is expected to be executed from the
architecture specific machine_power_off() function. Drivers providing
system poweroff functionality are expected to register with this call chain.
By using the priority field in the notifier block, callers can control
poweroff handler execution sequence and thus ensure that the poweroff
handler with the optimal capabilities to remove power for a given system
is called first.
Cc: Alan Cox
Cc: Alexander Graf
Cc: Andrew Morton
Cc: Geert Uytterhoeven
cc: Heiko Stuebner
Cc: Lee Jones
Cc: Len Brown
Cc: Pavel Machek
Cc: Philippe Rétornaz
Cc: Rafael J. Wysocki
Cc: Romain Perier
Signed-off-by: Guenter Roeck
---
v2:
- poweroff -> power_off
- Add defines for default priorities
- Use raw notifiers protected by spinlocks instead of atomic notifiers
- Add register_poweroff_handler_simple
- Add devm_register_power_off_handler
include/linux/pm.h | 22
kernel/power/Makefile | 1 +
kernel/power/poweroff_handler.c | 252
3 files changed, 275 insertions(+)
create mode 100644 kernel/power/poweroff_handler.c
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 383fd68..7e0cb36 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -34,7 +34,29 @@
extern void (*pm_power_off)(void);
extern void (*pm_power_off_prepare)(void);
+/*
+ * Callbacks to manage poweroff handlers
+ */
+
+struct notifier_block;
struct device; /* we have a circular dep with device.h */
+
+int register_power_off_handler(struct notifier_block *);
+int devm_register_power_off_handler(struct device *, struct notifier_block *);
+int register_power_off_handler_simple(void (*function)(void), int priority);
+int unregister_power_off_handler(struct notifier_block *);
+void do_kernel_power_off(void);
+bool have_kernel_power_off(void);
+
+/*
+ * Pre-defined poweroff handler priorities
+ */
+#define POWEROFF_PRIORITY_FALLBACK 0
+#define POWEROFF_PRIORITY_LOW 64
+#define POWEROFF_PRIORITY_DEFAULT 128
+#define POWEROFF_PRIORITY_HIGH 192
+#define POWEROFF_PRIORITY_HIGHEST 255
+
#ifdef CONFIG_VT_CONSOLE_SLEEP
extern void pm_vt_switch_required(struct device *dev, bool required);
extern void pm_vt_switch_unregister(struct device *dev);
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 29472bf..4d9f0c7 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -2,6 +2,7 @@
ccflags-$(CONFIG_PM_DEBUG) := -DDEBUG
obj-y += qos.o
+obj-y += poweroff_handler.o
obj-$(CONFIG_PM) += main.o
obj-$(CONFIG_VT_CONSOLE_SLEEP) += console.o
obj-$(CONFIG_FREEZER) += process.o
diff --git a/kernel/power/poweroff_handler.c b/kernel/power/poweroff_handler.c
new file mode 100644
index 000..aeb4736
--- /dev/null
+++ b/kernel/power/poweroff_handler.c
@@ -0,0 +1,252 @@
+/*
+ * linux/kernel/power/poweroff_handler.c - Poweroff handling functions
+ *
+ * Copyright (c) 2014 Guenter Roeck
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt)"poweroff: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Notifier list for kernel code which wants to be called
+ * to power off the system.
+ */
+static RAW_NOTIFIER_HEAD(power_off_handler_list);
+static DEFINE_SPINLOCK(power_off_handler_lock);
+
+/*
+ * Internal function to register poweroff notifier.
+ * Must be called with poweroff spinlock acquired.
+ */
+static int _register_power_off_handler(struct notifier_block *nb)
+{
+ return
Re: [PATCH] i8k: Ignore temperature sensors which report invalid values
On 10/20/2014 09:46 AM, Pali Rohár wrote:
Ok, I will describe my problem. Guenter, maybe you can find
another solution/fix for it.
Calling i8k_get_temp(3) on my laptop without I8K_TEMPERATURE_BUG
always returns value 193 (which is above I8K_MAX_TEMP).
When I8K_TEMPERATURE_BUG is enabled (by default) then
i8k_get_temp(3) returns value from prev[3] and store new value
I8K_TEMPERATURE_BUG to prev[3]. Value in prev[3] is initialized
to 0.
What I want to achieve is: when i8k_get_temp() for particular
sensor id always returns invalid value (> I8K_MAX_TEMP) then we
should totally ignore sensor with that id and do not export it
via hwmon.
My solution is: initialize prev[id] to I8K_MAX_TEMP, so on
invalid data first call to i8k_get_temp(id) returns I8K_MAX_TEMP.
Then in i8k_init_hwmon check if value is < I8K_MAX_TEMP and if
not ignore sensor id.
Guenter, it is clear now? Are you ok that we should ignore sensor
if always report value above I8K_MAX_TEMP? If you do not like my
solution/patch for it, can you specify how other can it be fixed?
I still don't see the point in initializing prev[].
Yes, I am ok with ignoring sensor values if the reported temperature
is above I8K_MAX_TEMP. I am just not sure if we should check against
I8K_MAX_TEMP or against, say, 192. Reason is that we do know that
the sensor can erroneously return 0x99 on some systems once in a
while. We would not want to ignore those sensors just because they
happen to report 0x99 during initialization.
So maybe make it
if (err >= 0 && err < 192)
and add a note before the first if(), explaining that higher values
suggest that there is no sensor attached.
Thanks,
Guenter
On Sunday 19 October 2014 17:13:29 Guenter Roeck wrote:
On 10/19/2014 07:46 AM, Pali Rohár wrote:
On some machines some temperature sensors report too high
values which are
What is "too high", and what is "some machines" ?
Would be great if you can be more specific.
invalid. When value is invalid function i8k_get_temp()
returns previous value and at next call it returns
I8K_MAX_TEMP.
With this patch also firt i8k_get_temp() call returns
I8K_MAX_TEMP and
fix ? Also, I am not entirely sure I understand what exactly
you are fixing here.
i8k_init_hwmon() will ignore all sensor ids which report
incorrect values.
Signed-off-by: Pali Rohár
---
drivers/char/i8k.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index 7272b08..bc327fa 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -298,7 +298,7 @@ static int i8k_get_temp(int sensor)
int temp;
#ifdef I8K_TEMPERATURE_BUG
- static int prev[4];
+ static int prev[4] = { I8K_MAX_TEMP, I8K_MAX_TEMP,
I8K_MAX_TEMP, I8K_MAX_TEMP };
I am not sure I understand what this change is expected to
accomplish. Please explain.
#endif
regs.ebx = sensor & 0xff;
rc = i8k_smm();
@@ -610,17 +610,17 @@ static int __init i8k_init_hwmon(void)
/* CPU temperature attributes, if temperature reading is
OK */ err = i8k_get_temp(0);
- if (err >= 0)
+ if (err >= 0 && err < I8K_MAX_TEMP)
I8K_MAX_TEMP is, at least in theory, a valid temperature, so
this should be "<=".
It would be important to understand what the "too high"
temperature is to possibly be able to distinguish it from the
buggy temperature that the code is trying to fix.
Thanks,
Guenter
i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP1;
/* check for additional temperature sensors */
err = i8k_get_temp(1);
- if (err >= 0)
+ if (err >= 0 && err < I8K_MAX_TEMP)
i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP2;
err = i8k_get_temp(2);
- if (err >= 0)
+ if (err >= 0 && err < I8K_MAX_TEMP)
i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP3;
err = i8k_get_temp(3);
- if (err >= 0)
+ if (err >= 0 && err < I8K_MAX_TEMP)
i8k_hwmon_flags |= I8K_HWMON_HAVE_TEMP4;
/* Left fan attributes, if left fan is present */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 02/47] memory: emif: Use API function to determine poweroff capability
Use have_kernel_power_off() to determine if the kernel is able
to power off the system.
Cc: Santosh Shilimkar
Signed-off-by: Guenter Roeck
---
v2:
- poweroff -> power_off
drivers/memory/emif.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 04644e7..874403a 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -1053,10 +1053,10 @@ static irqreturn_t emif_threaded_isr(int irq, void
*dev_id)
dev_emerg(emif->dev, "SDRAM temperature exceeds operating
limit.. Needs shut down!!!\n");
/* If we have Power OFF ability, use it, else try restarting */
- if (pm_power_off) {
+ if (have_kernel_power_off()) {
kernel_power_off();
} else {
- WARN(1, "FIXME: NO pm_power_off!!! trying restart\n");
+ WARN(1, "FIXME: NO kernel poweroff capability!!! trying
restart\n");
kernel_restart("SDRAM Over-temp Emergency restart");
}
return IRQ_HANDLED;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/47] m68k: Replace mach_power_off with pm_power_off
Replace mach_power_off with pm_power_off to simplify the subsequent
move of pm_power_off to generic code.
Cc: Geert Uytterhoeven
Cc: Greg Ungerer
Cc: Joshua Thompson
Acked-by: Geert Uytterhoeven
Signed-off-by: Guenter Roeck
---
v2:
- have_kernel_poweroff -> have_kernel_power_off
arch/m68k/emu/natfeat.c | 3 ++-
arch/m68k/include/asm/machdep.h | 1 -
arch/m68k/kernel/process.c | 5 +++--
arch/m68k/kernel/setup_mm.c | 1 -
arch/m68k/kernel/setup_no.c | 1 -
arch/m68k/mac/config.c | 3 ++-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/m68k/emu/natfeat.c b/arch/m68k/emu/natfeat.c
index 71b78ec..91e2ae7 100644
--- a/arch/m68k/emu/natfeat.c
+++ b/arch/m68k/emu/natfeat.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -90,5 +91,5 @@ void __init nf_init(void)
pr_info("NatFeats found (%s, %lu.%lu)\n", buf, version >> 16,
version & 0x);
- mach_power_off = nf_poweroff;
+ pm_power_off = nf_poweroff;
}
diff --git a/arch/m68k/include/asm/machdep.h b/arch/m68k/include/asm/machdep.h
index 953ca21..f9fac51 100644
--- a/arch/m68k/include/asm/machdep.h
+++ b/arch/m68k/include/asm/machdep.h
@@ -24,7 +24,6 @@ extern int (*mach_set_rtc_pll)(struct rtc_pll_info *);
extern int (*mach_set_clock_mmss)(unsigned long);
extern void (*mach_reset)( void );
extern void (*mach_halt)( void );
-extern void (*mach_power_off)( void );
extern unsigned long (*mach_hd_init) (unsigned long, unsigned long);
extern void (*mach_hd_setup)(char *, int *);
extern long mach_max_dma_address;
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index c55ff71..afe3d6e 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,8 +78,8 @@ void machine_halt(void)
void machine_power_off(void)
{
- if (mach_power_off)
- mach_power_off();
+ if (pm_power_off)
+ pm_power_off();
for (;;);
}
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 5b8ec4d..002fea6 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -96,7 +96,6 @@ EXPORT_SYMBOL(mach_get_rtc_pll);
EXPORT_SYMBOL(mach_set_rtc_pll);
void (*mach_reset)( void );
void (*mach_halt)( void );
-void (*mach_power_off)( void );
long mach_max_dma_address = 0x00ff; /* default set to the lower 16MB */
#ifdef CONFIG_HEARTBEAT
void (*mach_heartbeat) (int);
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 88c27d9..1520156 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -55,7 +55,6 @@ int (*mach_hwclk) (int, struct rtc_time*);
/* machine dependent reboot functions */
void (*mach_reset)(void);
void (*mach_halt)(void);
-void (*mach_power_off)(void);
#ifdef CONFIG_M68000
#if defined(CONFIG_M68328)
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index a471eab..677913ff 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
/* keyb */
#include
#include
@@ -159,7 +160,7 @@ void __init config_mac(void)
mach_set_clock_mmss = mac_set_clock_mmss;
mach_reset = mac_reset;
mach_halt = mac_poweroff;
- mach_power_off = mac_poweroff;
+ pm_power_off = mac_poweroff;
mach_max_dma_address = 0x;
#if defined(CONFIG_INPUT_M68K_BEEP) || defined(CONFIG_INPUT_M68K_BEEP_MODULE)
mach_beep = mac_mksound;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/47] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
Replace reference to pm_power_off (which is an implementation detail) and replace it with a more generic description of the driver's functionality. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Acked-by: Mark Rutland Acked-by: Andrew Lunn Signed-off-by: Guenter Roeck --- v2: Drop implementation details Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt index af25e77..c363d71 100644 --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt @@ -3,8 +3,7 @@ QNAP NAS devices have a microcontroller controlling the main power supply. This microcontroller is connected to UART1 of the Kirkwood and Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the -microcontroller to turn the power off. This driver adds a handler to -pm_power_off which is called to turn the power off. +microcontroller to turn the power off. Synology NAS devices use a similar scheme, but a different baud rate, 9600, and a different character, '1'. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 05/47] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
Devicetree bindings are supposed to be operating system independent and should thus not describe how a specific functionality is implemented in Linux. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Acked-by: Mark Rutland Signed-off-by: Guenter Roeck --- v2: No change Documentation/devicetree/bindings/mfd/as3722.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/as3722.txt b/Documentation/devicetree/bindings/mfd/as3722.txt index 4f64b2a..0b2a609 100644 --- a/Documentation/devicetree/bindings/mfd/as3722.txt +++ b/Documentation/devicetree/bindings/mfd/as3722.txt @@ -122,8 +122,7 @@ Following are properties of regulator subnode. Power-off: = -AS3722 supports the system power off by turning off all its rail. This -is provided through pm_power_off. +AS3722 supports the system power off by turning off all its rails. The device node should have the following properties to enable this functionality ams,system-power-controller: Boolean, to enable the power off functionality -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 09/47] mfd: palmas: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use devm_register_power_off_handler
- Use dev_warn instead of dev_err
drivers/mfd/palmas.c | 31 +--
include/linux/mfd/palmas.h | 3 +++
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..2fda979 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -425,20 +426,18 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
"ti,system-power-controller");
}
-static struct palmas *palmas_dev;
-static void palmas_power_off(void)
+static int palmas_power_off(struct notifier_block *this, unsigned long unused1,
+ void *unused2)
{
+ struct palmas *palmas = container_of(this, struct palmas, poweroff_nb);
unsigned int addr;
int ret, slave;
- if (!palmas_dev)
- return;
-
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE, PALMAS_DEV_CTRL);
ret = regmap_update_bits(
- palmas_dev->regmap[slave],
+ palmas->regmap[slave],
addr,
PALMAS_DEV_CTRL_DEV_ON,
0);
@@ -446,6 +445,8 @@ static void palmas_power_off(void)
if (ret)
pr_err("%s: Unable to write to DEV_CTRL_DEV_ON: %d\n",
__func__, ret);
+
+ return NOTIFY_DONE;
}
static unsigned int palmas_features = PALMAS_PMIC_FEATURE_SMPS10_BOOST;
@@ -668,9 +669,16 @@ no_irq:
ret = of_platform_populate(node, NULL, NULL, >dev);
if (ret < 0) {
goto err_irq;
- } else if (pdata->pm_off && !pm_power_off) {
- palmas_dev = palmas;
- pm_power_off = palmas_power_off;
+ } else if (pdata->pm_off) {
+ int ret2;
+
+ palmas->poweroff_nb.notifier_call = palmas_power_off;
+ palmas->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret2 = devm_register_power_off_handler(palmas->dev,
+ >poweroff_nb);
+ if (ret2)
+ dev_warn(palmas->dev,
+"Failed to register poweroff handler");
}
}
@@ -698,11 +706,6 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
i2c_unregister_device(palmas->i2c_clients[i]);
}
- if (palmas == palmas_dev) {
- pm_power_off = NULL;
- palmas_dev = NULL;
- }
-
return 0;
}
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index fb0390a..4715057 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#include
#include
@@ -68,6 +69,8 @@ struct palmas {
struct i2c_client *i2c_clients[PALMAS_NUM_CLIENTS];
struct regmap *regmap[PALMAS_NUM_CLIENTS];
+ struct notifier_block poweroff_nb;
+
/* Stored chip id */
int id;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/47] kernel: Move pm_power_off to common code
pm_power_off is defined for all architectures. Move it to common code.
Have all architectures call do_kernel_power_off instead of pm_power_off.
Some architectures point pm_power_off to machine_power_off. For those,
call do_kernel_power_off from machine_power_off instead.
Acked-by: David Vrabel
Acked-by: Geert Uytterhoeven
Acked-by: Hirokazu Takata
Acked-by: Jesper Nilsson
Acked-by: Max Filippov
Acked-by: Rafael J. Wysocki
Acked-by: Richard Weinberger
Acked-by: Xuetao Guan
Signed-off-by: Guenter Roeck
---
v2:
- do_kernel_poweroff -> do_kernel_power_off
- have_kernel_poweroff -> have_kernel_power_off
arch/alpha/kernel/process.c| 9 +++--
arch/arc/kernel/reset.c| 5 +
arch/arm/kernel/process.c | 5 +
arch/arm64/kernel/process.c| 5 +
arch/avr32/kernel/process.c| 6 +-
arch/blackfin/kernel/process.c | 3 ---
arch/blackfin/kernel/reboot.c | 2 ++
arch/c6x/kernel/process.c | 9 +
arch/cris/kernel/process.c | 4 +---
arch/frv/kernel/process.c | 5 ++---
arch/hexagon/kernel/reset.c| 5 ++---
arch/ia64/kernel/process.c | 5 +
arch/m32r/kernel/process.c | 8
arch/m68k/kernel/process.c | 6 +-
arch/metag/kernel/process.c| 6 +-
arch/microblaze/kernel/process.c | 3 ---
arch/microblaze/kernel/reset.c | 1 +
arch/mips/kernel/reset.c | 6 +-
arch/mn10300/kernel/process.c | 8 ++--
arch/openrisc/kernel/process.c | 8 +---
arch/parisc/kernel/process.c | 8
arch/powerpc/kernel/setup-common.c | 6 +++---
arch/s390/kernel/setup.c | 8 ++--
arch/score/kernel/process.c| 8
arch/sh/kernel/reboot.c| 6 +-
arch/sparc/kernel/process_32.c | 10 ++
arch/sparc/kernel/reboot.c | 8 ++--
arch/tile/kernel/reboot.c | 7 +++
arch/um/kernel/reboot.c| 2 --
arch/unicore32/kernel/process.c| 9 +
arch/x86/kernel/reboot.c | 11 +++
arch/x86/xen/enlighten.c | 3 +--
arch/xtensa/kernel/process.c | 4
drivers/parisc/power.c | 3 +--
kernel/power/poweroff_handler.c| 8
kernel/reboot.c| 4 ++--
36 files changed, 68 insertions(+), 146 deletions(-)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 1941a07..81c43f8 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -40,12 +41,6 @@
#include "proto.h"
#include "pci_impl.h"
-/*
- * Power off function, if any
- */
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL(pm_power_off);
-
#ifdef CONFIG_ALPHA_WTINT
/*
* Sleep the CPU.
@@ -184,6 +179,8 @@ machine_halt(void)
void
machine_power_off(void)
{
+ do_kernel_power_off();
+
common_shutdown(LINUX_REBOOT_CMD_POWER_OFF, NULL);
}
diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index 2768fa1..0758d9d 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -26,9 +26,6 @@ void machine_restart(char *__unused)
void machine_power_off(void)
{
- /* FIXME :: power off ??? */
+ do_kernel_power_off();
machine_halt();
}
-
-void (*pm_power_off) (void) = NULL;
-EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index fe972a2..aa3f656 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -117,8 +117,6 @@ void soft_restart(unsigned long addr)
/*
* Function pointers to optional machine specific functions
*/
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
@@ -205,8 +203,7 @@ void machine_power_off(void)
local_irq_disable();
smp_send_stop();
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
}
/*
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index c3065db..46a483a 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -68,8 +68,6 @@ void soft_restart(unsigned long addr)
/*
* Function pointers to optional machine specific functions
*/
-void (*pm_power_off)(void);
-EXPORT_SYMBOL_GPL(pm_power_off);
void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
@@ -129,8 +127,7 @@ void machine_power_off(void)
{
local_irq_disable();
smp_send_stop();
- if (pm_power_off)
- pm_power_off();
+ do_kernel_power_off();
}
/*
diff --git a/arch/avr32/kernel/process.c b/arch/avr32/kernel/process.c
index 42a53e74..529c1f6 100644
--- a/arch/avr32/kernel/process.c
+++ b/arch/avr32/kernel/process.c
@@ -23,9 +23,6 @@
#include
-void (*pm_power_off)(void);
[PATCH v2 10/47] mfd: axp20x: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with a low priority value of 64 to reflect that
the original code only sets pm_power_off if it was not already set.
Cc: Lee Jones
Cc: Samuel Ortiz
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify powroff handler priority
- Use devm_register_power_off_handler
- Use dev_warn instead of dev_err
drivers/mfd/axp20x.c | 30 --
include/linux/mfd/axp20x.h | 1 +
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 6231adb..9e6406c 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -17,7 +17,8 @@
#include
#include
#include
-#include
+#include
+#include
#include
#include
#include
@@ -150,11 +151,16 @@ static struct mfd_cell axp20x_cells[] = {
},
};
-static struct axp20x_dev *axp20x_pm_power_off;
-static void axp20x_power_off(void)
+static int axp20x_power_off(struct notifier_block *this, unsigned long unused1,
+ void *unused2)
+
{
- regmap_write(axp20x_pm_power_off->regmap, AXP20X_OFF_CTRL,
-AXP20X_OFF);
+ struct axp20x_dev *axp20x = container_of(this, struct axp20x_dev,
+poweroff_nb);
+
+ regmap_write(axp20x->regmap, AXP20X_OFF_CTRL, AXP20X_OFF);
+
+ return NOTIFY_DONE;
}
static int axp20x_i2c_probe(struct i2c_client *i2c,
@@ -204,10 +210,11 @@ static int axp20x_i2c_probe(struct i2c_client *i2c,
return ret;
}
- if (!pm_power_off) {
- axp20x_pm_power_off = axp20x;
- pm_power_off = axp20x_power_off;
- }
+ axp20x->poweroff_nb.notifier_call = axp20x_power_off;
+ axp20x->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = devm_register_power_off_handler(>dev, >poweroff_nb);
+ if (ret)
+ dev_warn(>dev, "failed to register poweroff handler\n");
dev_info(>dev, "AXP20X driver loaded\n");
@@ -218,11 +225,6 @@ static int axp20x_i2c_remove(struct i2c_client *i2c)
{
struct axp20x_dev *axp20x = i2c_get_clientdata(i2c);
- if (axp20x == axp20x_pm_power_off) {
- axp20x_pm_power_off = NULL;
- pm_power_off = NULL;
- }
-
mfd_remove_devices(axp20x->dev);
regmap_del_irq_chip(axp20x->i2c_client->irq, axp20x->regmap_irqc);
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index d0e31a2..8f23b39 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -175,6 +175,7 @@ struct axp20x_dev {
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irqc;
longvariant;
+ struct notifier_block poweroff_nb;
};
#endif /* __LINUX_MFD_AXP20X_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/47] mfd: retu: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Lee Jones
Cc: Samuel Ortiz
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use devm_register_power_off_handler
- Use dev_warn instead of dev_err
drivers/mfd/retu-mfd.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index 663f8a3..3c720cb 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -43,6 +45,7 @@ struct retu_dev {
struct device *dev;
struct mutexmutex;
struct regmap_irq_chip_data *irq_data;
+ struct notifier_block poweroff_nb;
};
static struct resource retu_pwrbutton_res[] = {
@@ -81,9 +84,6 @@ static struct regmap_irq_chip retu_irq_chip = {
.ack_base = RETU_REG_IDR,
};
-/* Retu device registered for the power off. */
-static struct retu_dev *retu_pm_power_off;
-
static struct resource tahvo_usb_res[] = {
{
.name = "tahvo-usb",
@@ -165,12 +165,14 @@ int retu_write(struct retu_dev *rdev, u8 reg, u16 data)
}
EXPORT_SYMBOL_GPL(retu_write);
-static void retu_power_off(void)
+static int retu_power_off(struct notifier_block *this, unsigned long unused1,
+ void *unused2)
{
- struct retu_dev *rdev = retu_pm_power_off;
+ struct retu_dev *rdev = container_of(this, struct retu_dev,
+poweroff_nb);
int reg;
- mutex_lock(_pm_power_off->mutex);
+ mutex_lock(>mutex);
/* Ignore power button state */
regmap_read(rdev->regmap, RETU_REG_CC1, );
@@ -183,7 +185,9 @@ static void retu_power_off(void)
for (;;)
cpu_relax();
- mutex_unlock(_pm_power_off->mutex);
+ mutex_unlock(>mutex);
+
+ return NOTIFY_DONE;
}
static int retu_regmap_read(void *context, const void *reg, size_t reg_size,
@@ -279,9 +283,14 @@ static int retu_probe(struct i2c_client *i2c, const struct
i2c_device_id *id)
return ret;
}
- if (i2c->addr == 1 && !pm_power_off) {
- retu_pm_power_off = rdev;
- pm_power_off = retu_power_off;
+ if (i2c->addr == 1) {
+ rdev->poweroff_nb.notifier_call = retu_power_off;
+ rdev->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = devm_register_power_off_handler(rdev->dev,
+ >poweroff_nb);
+ if (ret)
+ dev_warn(rdev->dev,
+"Failed to register poweroff handler\n");
}
return 0;
@@ -291,10 +300,6 @@ static int retu_remove(struct i2c_client *i2c)
{
struct retu_dev *rdev = i2c_get_clientdata(i2c);
- if (retu_pm_power_off == rdev) {
- pm_power_off = NULL;
- retu_pm_power_off = NULL;
- }
mfd_remove_devices(rdev->dev);
regmap_del_irq_chip(i2c->irq, rdev->irq_data);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 12/47] mfd: ab8500-sysctrl: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
sysctrl_dev is set prior to poweroff handler registration, and the
poweroff handler is unregistered prior to clearing sysrctrl_dev.
It is therefore not necessary to check if sysctrl_dev is NULL in the
poweroff handler, and the check was removed. Setting sysctrl_dev to NULL
in the remove function was also removed as unnecessary. With those changes,
devm_register_power_off_handler can be used to register the poeroff handler.
The now empty remove function was retained since the ab8500_restart function,
which is currently unused, would likely need some cleanup if it was ever used.
Cc: Linus Walleij
Cc: Lee Jones
Cc: Samuel Ortiz
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use devm_register_power_off_handler
- Use dev_warn instead of dev_err
- Since we use devm_register_power_off_handler,
we need to check if sysctrl_dev in the poweroff handler to avoid
a race condition on unload, so this check is no longer removed
drivers/mfd/ab8500-sysctrl.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
index 8e0dae5..dc634d5 100644
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -23,7 +24,8 @@
static struct device *sysctrl_dev;
-static void ab8500_power_off(void)
+static int ab8500_power_off(struct notifier_block *this, unsigned long unused1,
+ void *unused2)
{
sigset_t old;
sigset_t all;
@@ -36,7 +38,7 @@ static void ab8500_power_off(void)
if (sysctrl_dev == NULL) {
pr_err("%s: sysctrl not initialized\n", __func__);
- return;
+ return NOTIFY_DONE;
}
/*
@@ -83,8 +85,15 @@ shutdown:
AB8500_STW4500CTRL1_SWRESET4500N);
(void)sigprocmask(SIG_SETMASK, , NULL);
}
+
+ return NOTIFY_DONE;
}
+static struct notifier_block ab8500_poweroff_nb = {
+ .notifier_call = ab8500_power_off,
+ .priority = POWEROFF_PRIORITY_LOW,
+};
+
/*
* Use the AB WD to reset the platform. It will perform a hard
* reset instead of a soft reset. Write the reset reason to
@@ -185,6 +194,7 @@ static int ab8500_sysctrl_probe(struct platform_device
*pdev)
struct ab8500 *ab8500 = dev_get_drvdata(pdev->dev.parent);
struct ab8500_platform_data *plat;
struct ab8500_sysctrl_platform_data *pdata;
+ int err;
plat = dev_get_platdata(pdev->dev.parent);
@@ -193,8 +203,9 @@ static int ab8500_sysctrl_probe(struct platform_device
*pdev)
sysctrl_dev = >dev;
- if (!pm_power_off)
- pm_power_off = ab8500_power_off;
+ err = devm_register_power_off_handler(sysctrl_dev, _poweroff_nb);
+ if (err)
+ dev_warn(>dev, "Failed to register poweroff handler\n");
pdata = plat->sysctrl;
if (pdata) {
@@ -228,9 +239,6 @@ static int ab8500_sysctrl_remove(struct platform_device
*pdev)
{
sysctrl_dev = NULL;
- if (pm_power_off == ab8500_power_off)
- pm_power_off = NULL;
-
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 14/47] mfd: tps80031: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use dev_warn instead of dev_err
drivers/mfd/tps80031.c | 30 ++
include/linux/mfd/tps80031.h | 2 ++
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/tps80031.c b/drivers/mfd/tps80031.c
index ed6c5b0..926c62a 100644
--- a/drivers/mfd/tps80031.c
+++ b/drivers/mfd/tps80031.c
@@ -147,7 +147,6 @@ static const struct tps80031_pupd_data tps80031_pupds[] = {
[TPS80031_CTLI2C_SCL] = PUPD_DATA(4, 0, BIT(2)),
[TPS80031_CTLI2C_SDA] = PUPD_DATA(4, 0, BIT(3)),
};
-static struct tps80031 *tps80031_power_off_dev;
int tps80031_ext_power_req_config(struct device *dev,
unsigned long ext_ctrl_flag, int preq_bit,
@@ -209,11 +208,17 @@ int tps80031_ext_power_req_config(struct device *dev,
}
EXPORT_SYMBOL_GPL(tps80031_ext_power_req_config);
-static void tps80031_power_off(void)
+static int tps80031_power_off(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
{
- dev_info(tps80031_power_off_dev->dev, "switching off PMU\n");
- tps80031_write(tps80031_power_off_dev->dev, TPS80031_SLAVE_ID1,
- TPS80031_PHOENIX_DEV_ON, TPS80031_DEVOFF);
+ struct tps80031 *tps80031 = container_of(this, struct tps80031,
+poweroff_nb);
+
+ dev_info(tps80031->dev, "switching off PMU\n");
+ tps80031_write(tps80031->dev, TPS80031_SLAVE_ID1,
+ TPS80031_PHOENIX_DEV_ON, TPS80031_DEVOFF);
+
+ return NOTIFY_DONE;
}
static void tps80031_pupd_init(struct tps80031 *tps80031,
@@ -501,9 +506,13 @@ static int tps80031_probe(struct i2c_client *client,
goto fail_mfd_add;
}
- if (pdata->use_power_off && !pm_power_off) {
- tps80031_power_off_dev = tps80031;
- pm_power_off = tps80031_power_off;
+ if (pdata->use_power_off) {
+ tps80031->poweroff_nb.notifier_call = tps80031_power_off;
+ tps80031->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = register_power_off_handler(>poweroff_nb);
+ if (ret)
+ dev_warn(>dev,
+"Failed to register poweroff handler\n");
}
return 0;
@@ -523,10 +532,7 @@ static int tps80031_remove(struct i2c_client *client)
struct tps80031 *tps80031 = i2c_get_clientdata(client);
int i;
- if (tps80031_power_off_dev == tps80031) {
- tps80031_power_off_dev = NULL;
- pm_power_off = NULL;
- }
+ unregister_power_off_handler(>poweroff_nb);
mfd_remove_devices(tps80031->dev);
diff --git a/include/linux/mfd/tps80031.h b/include/linux/mfd/tps80031.h
index 2c75c9c..49bc006 100644
--- a/include/linux/mfd/tps80031.h
+++ b/include/linux/mfd/tps80031.h
@@ -24,6 +24,7 @@
#define __LINUX_MFD_TPS80031_H
#include
+#include
#include
/* Pull-ups/Pull-downs */
@@ -513,6 +514,7 @@ struct tps80031 {
struct i2c_client *clients[TPS80031_NUM_SLAVES];
struct regmap *regmap[TPS80031_NUM_SLAVES];
struct regmap_irq_chip_data *irq_data;
+ struct notifier_block poweroff_nb;
};
struct tps80031_pupd_init_data {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 16/47] mfd: tps6586x: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use dev_warn instead of dev_err
drivers/mfd/tps6586x.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index 8e1dbc4..01c2714 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -21,10 +21,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
@@ -133,6 +135,8 @@ struct tps6586x {
u32 irq_en;
u8 mask_reg[5];
struct irq_domain *irq_domain;
+
+ struct notifier_block poweroff_nb;
};
static inline struct tps6586x *dev_to_tps6586x(struct device *dev)
@@ -472,13 +476,18 @@ static const struct regmap_config tps6586x_regmap_config
= {
.cache_type = REGCACHE_RBTREE,
};
-static struct device *tps6586x_dev;
-static void tps6586x_power_off(void)
+static int tps6586x_power_off(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
{
- if (tps6586x_clr_bits(tps6586x_dev, TPS6586X_SUPPLYENE, EXITSLREQ_BIT))
- return;
+ struct tps6586x *tps6586x = container_of(this, struct tps6586x,
+poweroff_nb);
+
+ if (tps6586x_clr_bits(tps6586x->dev, TPS6586X_SUPPLYENE, EXITSLREQ_BIT))
+ return NOTIFY_DONE;
- tps6586x_set_bits(tps6586x_dev, TPS6586X_SUPPLYENE, SLEEP_MODE_BIT);
+ tps6586x_set_bits(tps6586x->dev, TPS6586X_SUPPLYENE, SLEEP_MODE_BIT);
+
+ return NOTIFY_DONE;
}
static void tps6586x_print_version(struct i2c_client *client, int version)
@@ -575,9 +584,13 @@ static int tps6586x_i2c_probe(struct i2c_client *client,
goto err_add_devs;
}
- if (pdata->pm_off && !pm_power_off) {
- tps6586x_dev = >dev;
- pm_power_off = tps6586x_power_off;
+ if (pdata->pm_off) {
+ tps6586x->poweroff_nb.notifier_call = tps6586x_power_off;
+ tps6586x->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = register_power_off_handler(>poweroff_nb);
+ if (ret)
+ dev_warn(>dev,
+"failed to register poweroff handler\n");
}
return 0;
@@ -594,6 +607,8 @@ static int tps6586x_i2c_remove(struct i2c_client *client)
{
struct tps6586x *tps6586x = i2c_get_clientdata(client);
+ unregister_power_off_handler(>poweroff_nb);
+
tps6586x_remove_subdevs(tps6586x);
mfd_remove_devices(tps6586x->dev);
if (client->irq)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 15/47] mfd: dm355evm_msp: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use dev_warn instead of dev_err
drivers/mfd/dm355evm_msp.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
index 4c826f7..3ec49a7 100644
--- a/drivers/mfd/dm355evm_msp.c
+++ b/drivers/mfd/dm355evm_msp.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -352,14 +354,22 @@ static void dm355evm_command(unsigned command)
command, status);
}
-static void dm355evm_power_off(void)
+static int dm355evm_power_off(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
{
dm355evm_command(MSP_COMMAND_POWEROFF);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block dm355evm_msp_poweroff_nb = {
+ .notifier_call = dm355evm_power_off,
+ .priority = POWEROFF_PRIORITY_LOW,
+};
+
static int dm355evm_msp_remove(struct i2c_client *client)
{
- pm_power_off = NULL;
+ unregister_power_off_handler(_msp_poweroff_nb);
msp430 = NULL;
return 0;
}
@@ -398,7 +408,9 @@ dm355evm_msp_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto fail;
/* PM hookup */
- pm_power_off = dm355evm_power_off;
+ status = register_power_off_handler(_msp_poweroff_nb);
+ if (status)
+ dev_warn(>dev, "Failed to register poweroff handler\n");
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 13/47] mfd: max8907: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Note that this patch fixes a problem on driver unload as side effect:
The old code did not restore or clean up pm_power_off on remove,
meaning the pointer was left in an undefined state.
Cc: Lee Jones
Cc: Samuel Ortiz
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use dev_warn instead of dev_err
drivers/mfd/max8907.c | 24 ++--
include/linux/mfd/max8907.h | 2 ++
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/max8907.c b/drivers/mfd/max8907.c
index 232749c..daacdbc 100644
--- a/drivers/mfd/max8907.c
+++ b/drivers/mfd/max8907.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -177,11 +178,16 @@ static const struct regmap_irq_chip max8907_rtc_irq_chip
= {
.num_irqs = ARRAY_SIZE(max8907_rtc_irqs),
};
-static struct max8907 *max8907_pm_off;
-static void max8907_power_off(void)
+static int max8907_power_off(struct notifier_block *this, unsigned long
unused1,
+void *unused2)
{
- regmap_update_bits(max8907_pm_off->regmap_gen, MAX8907_REG_RESET_CNFG,
+ struct max8907 *max8907 = container_of(this, struct max8907,
+ poweroff_nb);
+
+ regmap_update_bits(max8907->regmap_gen, MAX8907_REG_RESET_CNFG,
MAX8907_MASK_POWER_OFF, MAX8907_MASK_POWER_OFF);
+
+ return NOTIFY_DONE;
}
static int max8907_i2c_probe(struct i2c_client *i2c,
@@ -267,9 +273,13 @@ static int max8907_i2c_probe(struct i2c_client *i2c,
goto err_add_devices;
}
- if (pm_off && !pm_power_off) {
- max8907_pm_off = max8907;
- pm_power_off = max8907_power_off;
+ if (pm_off) {
+ max8907->poweroff_nb.notifier_call = max8907_power_off;
+ max8907->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = register_power_off_handler(>poweroff_nb);
+ if (ret)
+ dev_warn(>dev,
+"Failed to register poweroff handler");
}
return 0;
@@ -293,6 +303,8 @@ static int max8907_i2c_remove(struct i2c_client *i2c)
{
struct max8907 *max8907 = i2c_get_clientdata(i2c);
+ unregister_power_off_handler(>poweroff_nb);
+
mfd_remove_devices(max8907->dev);
regmap_del_irq_chip(max8907->i2c_gen->irq, max8907->irqc_rtc);
diff --git a/include/linux/mfd/max8907.h b/include/linux/mfd/max8907.h
index b06f7a6..016428e 100644
--- a/include/linux/mfd/max8907.h
+++ b/include/linux/mfd/max8907.h
@@ -13,6 +13,7 @@
#define __LINUX_MFD_MAX8907_H
#include
+#include
#include
#define MAX8907_GEN_I2C_ADDR (0x78 >> 1)
@@ -247,6 +248,7 @@ struct max8907 {
struct regmap_irq_chip_data *irqc_chg;
struct regmap_irq_chip_data *irqc_on_off;
struct regmap_irq_chip_data *irqc_rtc;
+ struct notifier_block poweroff_nb;
};
#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 22/47] power/reset: restart-poweroff: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register as poweroff handler of last resort since the driver
does not really power off the system but executes a restart.
Drop remove function since it is no longer needed.
Cc: Sebastian Reichel
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
Acked-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
v2:
- Use define to sepcify poweroff handler priority
- Use devm_register_power_off_handler
- Drop remove function since it is no longer needed
drivers/power/reset/restart-poweroff.c | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/power/reset/restart-poweroff.c
b/drivers/power/reset/restart-poweroff.c
index edd707e..e8f8e59 100644
--- a/drivers/power/reset/restart-poweroff.c
+++ b/drivers/power/reset/restart-poweroff.c
@@ -12,37 +12,31 @@
*/
#include
#include
+#include
#include
#include
#include
+#include
#include
-#include
-static void restart_poweroff_do_poweroff(void)
+static int restart_poweroff_do_poweroff(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
{
reboot_mode = REBOOT_HARD;
machine_restart(NULL);
-}
-
-static int restart_poweroff_probe(struct platform_device *pdev)
-{
- /* If a pm_power_off function has already been added, leave it alone */
- if (pm_power_off != NULL) {
- dev_err(>dev,
- "pm_power_off function already registered");
- return -EBUSY;
- }
- pm_power_off = _poweroff_do_poweroff;
- return 0;
+ return NOTIFY_DONE;
}
-static int restart_poweroff_remove(struct platform_device *pdev)
-{
- if (pm_power_off == _poweroff_do_poweroff)
- pm_power_off = NULL;
+static struct notifier_block restart_power_off_handler = {
+ .notifier_call = restart_poweroff_do_poweroff,
+ .priority = POWEROFF_PRIORITY_FALLBACK,
+};
- return 0;
+static int restart_poweroff_probe(struct platform_device *pdev)
+{
+ return devm_register_power_off_handler(>dev,
+ _power_off_handler);
}
static const struct of_device_id of_restart_poweroff_match[] = {
@@ -52,7 +46,6 @@ static const struct of_device_id of_restart_poweroff_match[]
= {
static struct platform_driver restart_poweroff_driver = {
.probe = restart_poweroff_probe,
- .remove = restart_poweroff_remove,
.driver = {
.name = "poweroff-restart",
.owner = THIS_MODULE,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 17/47] mfd: tps65910: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use dev_warn instead of dev_err
drivers/mfd/tps65910.c | 27 ++-
include/linux/mfd/tps65910.h | 3 +++
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 7612d89..88ea108 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -437,19 +439,20 @@ struct tps65910_board *tps65910_parse_dt(struct
i2c_client *client,
}
#endif
-static struct i2c_client *tps65910_i2c_client;
-static void tps65910_power_off(void)
+static int tps65910_power_off(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
{
- struct tps65910 *tps65910;
-
- tps65910 = dev_get_drvdata(_i2c_client->dev);
+ struct tps65910 *tps65910 = container_of(this, struct tps65910,
+poweroff_nb);
if (tps65910_reg_set_bits(tps65910, TPS65910_DEVCTRL,
DEVCTRL_PWR_OFF_MASK) < 0)
- return;
+ return NOTIFY_DONE;
tps65910_reg_clear_bits(tps65910, TPS65910_DEVCTRL,
DEVCTRL_DEV_ON_MASK);
+
+ return NOTIFY_DONE;
}
static int tps65910_i2c_probe(struct i2c_client *i2c,
@@ -505,9 +508,13 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
tps65910_ck32k_init(tps65910, pmic_plat_data);
tps65910_sleepinit(tps65910, pmic_plat_data);
- if (pmic_plat_data->pm_off && !pm_power_off) {
- tps65910_i2c_client = i2c;
- pm_power_off = tps65910_power_off;
+ if (pmic_plat_data->pm_off) {
+ tps65910->poweroff_nb.notifier_call = tps65910_power_off;
+ tps65910->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = register_power_off_handler(>poweroff_nb);
+ if (ret)
+ dev_warn(>dev,
+"failed to register poweroff handler\n");
}
ret = mfd_add_devices(tps65910->dev, -1,
@@ -527,6 +534,8 @@ static int tps65910_i2c_remove(struct i2c_client *i2c)
{
struct tps65910 *tps65910 = i2c_get_clientdata(i2c);
+ unregister_power_off_handler(>poweroff_nb);
+
tps65910_irq_exit(tps65910);
mfd_remove_devices(tps65910->dev);
diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
index 6483a6f..65cae2c 100644
--- a/include/linux/mfd/tps65910.h
+++ b/include/linux/mfd/tps65910.h
@@ -905,6 +905,9 @@ struct tps65910 {
/* IRQ Handling */
int chip_irq;
struct regmap_irq_chip_data *irq_data;
+
+ /* Poweroff handling */
+ struct notifier_block poweroff_nb;
};
struct tps65910_platform_data {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 18/47] mfd: twl4030-power: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Make twl4030_power_off static as it is only called from the twl4030-power
driver. Drop remove function as it is no longer needed.
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use dev_warn instead of dev_err
- Use devm_register_power_off_handler
- Drop remove function as it is no longer needed.
drivers/mfd/twl4030-power.c | 29 +++--
include/linux/i2c/twl.h | 1 -
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index cf92a6d..85e4aa4 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -25,9 +25,10 @@
*/
#include
-#include
+#include
#include
#include
+#include
#include
#include
@@ -611,7 +612,8 @@ twl4030_power_configure_resources(const struct
twl4030_power_data *pdata)
* After a successful execution, TWL shuts down the power to the SoC
* and all peripherals connected to it.
*/
-void twl4030_power_off(void)
+static int twl4030_power_off(struct notifier_block *this, unsigned long
unused1,
+void *unused2)
{
int err;
@@ -619,8 +621,15 @@ void twl4030_power_off(void)
TWL4030_PM_MASTER_P1_SW_EVENTS);
if (err)
pr_err("TWL4030 Unable to power off\n");
+
+ return NOTIFY_DONE;
}
+static struct notifier_block twl4030_poweroff_nb = {
+ .notifier_call = twl4030_power_off,
+ .priority = POWEROFF_PRIORITY_LOW,
+};
+
static bool twl4030_power_use_poweroff(const struct twl4030_power_data *pdata,
struct device_node *node)
{
@@ -839,7 +848,9 @@ static int twl4030_power_probe(struct platform_device *pdev)
}
/* Board has to be wired properly to use this feature */
- if (twl4030_power_use_poweroff(pdata, node) && !pm_power_off) {
+ if (twl4030_power_use_poweroff(pdata, node)) {
+ int ret;
+
/* Default for SEQ_OFFSYNC is set, lets ensure this */
err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, ,
TWL4030_PM_MASTER_CFG_P123_TRANSITION);
@@ -856,7 +867,11 @@ static int twl4030_power_probe(struct platform_device
*pdev)
}
}
- pm_power_off = twl4030_power_off;
+ ret = devm_register_power_off_handler(>dev,
+ _poweroff_nb);
+ if (ret)
+ dev_warn(>dev,
+"Failed to register poweroff handler\n");
}
relock:
@@ -870,11 +885,6 @@ relock:
return err;
}
-static int twl4030_power_remove(struct platform_device *pdev)
-{
- return 0;
-}
-
static struct platform_driver twl4030_power_driver = {
.driver = {
.name = "twl4030_power",
@@ -882,7 +892,6 @@ static struct platform_driver twl4030_power_driver = {
.of_match_table = of_match_ptr(twl4030_power_of_match),
},
.probe = twl4030_power_probe,
- .remove = twl4030_power_remove,
};
module_platform_driver(twl4030_power_driver);
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 8cfb50f..f8544f1 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -680,7 +680,6 @@ struct twl4030_power_data {
};
extern int twl4030_remove_script(u8 flags);
-extern void twl4030_power_off(void);
struct twl4030_codec_data {
unsigned int digimic_delay; /* in ms */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 23/47] power/reset: gpio-poweroff: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Other changes:
Drop note that there can not be an additional instance of this driver.
The original reason no longer applies, it should be obvious that there
can only be one instance of the driver if static variables are used to
reflect its state, and support for multiple instances can now be added
easily if needed by avoiding static variables.
Do not create an error message if another poweroff handler has already
been registered. This is perfectly normal and acceptable.
Drop remove function since it is no longer needed.
Cc: Sebastian Reichel
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
Acked-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
v2;
- Use define to specify poweroff handler priority
- Use devm_register_power_off_handler
- Drop remove function as it is no longer needed
drivers/power/reset/gpio-poweroff.c | 40 -
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/power/reset/gpio-poweroff.c
b/drivers/power/reset/gpio-poweroff.c
index ce849bc..5d35f13 100644
--- a/drivers/power/reset/gpio-poweroff.c
+++ b/drivers/power/reset/gpio-poweroff.c
@@ -14,18 +14,18 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
#include
-/*
- * Hold configuration here, cannot be more than one instance of the driver
- * since pm_power_off itself is global.
- */
static struct gpio_desc *reset_gpio;
-static void gpio_poweroff_do_poweroff(void)
+static int gpio_poweroff_do_poweroff(struct notifier_block *this,
+unsigned long unused1, void *unused2)
+
{
BUG_ON(!reset_gpio);
@@ -43,19 +43,19 @@ static void gpio_poweroff_do_poweroff(void)
mdelay(3000);
WARN_ON(1);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block gpio_poweroff_nb = {
+ .notifier_call = gpio_poweroff_do_poweroff,
+ .priority = POWEROFF_PRIORITY_LOW,
+};
+
static int gpio_poweroff_probe(struct platform_device *pdev)
{
bool input = false;
-
- /* If a pm_power_off function has already been added, leave it alone */
- if (pm_power_off != NULL) {
- dev_err(>dev,
- "%s: pm_power_off function already registered",
- __func__);
- return -EBUSY;
- }
+ int err;
reset_gpio = devm_gpiod_get(>dev, NULL);
if (IS_ERR(reset_gpio))
@@ -77,16 +77,11 @@ static int gpio_poweroff_probe(struct platform_device *pdev)
}
}
- pm_power_off = _poweroff_do_poweroff;
- return 0;
-}
-
-static int gpio_poweroff_remove(struct platform_device *pdev)
-{
- if (pm_power_off == _poweroff_do_poweroff)
- pm_power_off = NULL;
+ err = devm_register_power_off_handler(>dev, _poweroff_nb);
+ if (err)
+ dev_err(>dev, "Failed to register poweroff handler\n");
- return 0;
+ return err;
}
static const struct of_device_id of_gpio_poweroff_match[] = {
@@ -96,7 +91,6 @@ static const struct of_device_id of_gpio_poweroff_match[] = {
static struct platform_driver gpio_poweroff_driver = {
.probe = gpio_poweroff_probe,
- .remove = gpio_poweroff_remove,
.driver = {
.name = "poweroff-gpio",
.owner = THIS_MODULE,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 20/47] mfd: rn5t618: Register poweroff handler with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Beniamino Galvani
Signed-off-by: Guenter Roeck
---
v2: New patch
drivers/mfd/rn5t618.c | 32
include/linux/mfd/rn5t618.h | 2 ++
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index 6668571..045cd43 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
static const struct mfd_cell rn5t618_cells[] = {
@@ -47,16 +49,20 @@ static const struct regmap_config rn5t618_regmap_config = {
.cache_type = REGCACHE_RBTREE,
};
-static struct rn5t618 *rn5t618_pm_power_off;
-
-static void rn5t618_power_off(void)
+static int rn5t618_power_off(struct notifier_block *this,
+unsigned long unused1, void *unused2)
{
+ struct rn5t618 *rn5t618 = container_of(this, struct rn5t618,
+ poweroff_nb);
+
/* disable automatic repower-on */
- regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_REPCNT,
+ regmap_update_bits(rn5t618->regmap, RN5T618_REPCNT,
RN5T618_REPCNT_REPWRON, 0);
/* start power-off sequence */
- regmap_update_bits(rn5t618_pm_power_off->regmap, RN5T618_SLPCNT,
+ regmap_update_bits(rn5t618->regmap, RN5T618_SLPCNT,
RN5T618_SLPCNT_SWPWROFF, RN5T618_SLPCNT_SWPWROFF);
+
+ return NOTIFY_DONE;
}
static int rn5t618_i2c_probe(struct i2c_client *i2c,
@@ -85,23 +91,17 @@ static int rn5t618_i2c_probe(struct i2c_client *i2c,
return ret;
}
- if (!pm_power_off) {
- rn5t618_pm_power_off = priv;
- pm_power_off = rn5t618_power_off;
- }
+ priv->poweroff_nb.notifier_call = rn5t618_power_off;
+ priv->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = devm_register_power_off_handler(>dev, >poweroff_nb);
+ if (ret)
+ dev_warn(>dev, "Failed to register poweroff handler\n");
return 0;
}
static int rn5t618_i2c_remove(struct i2c_client *i2c)
{
- struct rn5t618 *priv = i2c_get_clientdata(i2c);
-
- if (priv == rn5t618_pm_power_off) {
- rn5t618_pm_power_off = NULL;
- pm_power_off = NULL;
- }
-
mfd_remove_devices(>dev);
return 0;
}
diff --git a/include/linux/mfd/rn5t618.h b/include/linux/mfd/rn5t618.h
index c72d534..3b0f0e6 100644
--- a/include/linux/mfd/rn5t618.h
+++ b/include/linux/mfd/rn5t618.h
@@ -14,6 +14,7 @@
#ifndef __LINUX_MFD_RN5T618_H
#define __LINUX_MFD_RN5T618_H
+#include
#include
#define RN5T618_LSIVER 0x00
@@ -223,6 +224,7 @@ enum {
struct rn5t618 {
struct regmap *regmap;
+ struct notifier_block poweroff_nb;
};
#endif /* __LINUX_MFD_RN5T618_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 29/47] power/reset: ltc2952-poweroff: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
sets pm_power_off only if it was not already set.
Signed-off-by: Guenter Roeck
---
v2: Added patch
drivers/power/reset/ltc2952-poweroff.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/power/reset/ltc2952-poweroff.c
b/drivers/power/reset/ltc2952-poweroff.c
index 116a1ce..da9abd2 100644
--- a/drivers/power/reset/ltc2952-poweroff.c
+++ b/drivers/power/reset/ltc2952-poweroff.c
@@ -80,6 +80,8 @@ struct ltc2952_poweroff_data {
* 2: kill
*/
struct gpio_desc *gpio[3];
+
+ struct notifier_block poweroff_nb;
};
static int ltc2952_poweroff_panic;
@@ -180,9 +182,13 @@ irq_ok:
return IRQ_HANDLED;
}
-static void ltc2952_poweroff_kill(void)
+static int ltc2952_poweroff_kill(struct notifier_block *this,
+unsigned long unused1, void *unused2)
+
{
gpiod_set_value(ltc2952_data->gpio[POWERPATH_IO_KILL], 1);
+
+ return NOTIFY_DONE;
}
static int ltc2952_poweroff_suspend(struct platform_device *pdev,
@@ -285,12 +291,7 @@ err_io:
static int ltc2952_poweroff_probe(struct platform_device *pdev)
{
- int ret;
-
- if (pm_power_off) {
- dev_err(>dev, "pm_power_off already registered");
- return -EBUSY;
- }
+ int i, ret;
ltc2952_data = kzalloc(sizeof(*ltc2952_data), GFP_KERNEL);
if (!ltc2952_data)
@@ -302,12 +303,20 @@ static int ltc2952_poweroff_probe(struct platform_device
*pdev)
if (ret)
goto err;
- pm_power_off = _poweroff_kill;
+ ltc2952_data->poweroff_nb.notifier_call = ltc2952_poweroff_kill;
+ ltc2952_data->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = register_power_off_handler(_data->poweroff_nb);
+ if (ret)
+ goto err_power;
dev_info(>dev, "probe successful\n");
return 0;
+err_power:
+ free_irq(ltc2952_data->virq, ltc2952_data);
+ for (i = 0; i < ARRAY_SIZE(ltc2952_data->gpio); i++)
+ gpiod_put(ltc2952_data->gpio[i]);
err:
kfree(ltc2952_data);
return ret;
@@ -317,7 +326,7 @@ static int ltc2952_poweroff_remove(struct platform_device
*pdev)
{
unsigned int i;
- pm_power_off = NULL;
+ unregister_power_off_handler(_data->poweroff_nb);
if (ltc2952_data) {
free_irq(ltc2952_data->virq, ltc2952_data);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] scsi: add try_rc16 blacklist flag
On Tue, Oct 14, 2014 at 09:08:28PM -0400, Martin K. Petersen wrote: > > "Sitsofe" == Sitsofe Wheeler writes: > > Sitsofe> Microsoft Hyper-V virtual disks currently only claim SPC-2 > Sitsofe> compliance causing the kernel skip checks for features such as > Sitsofe> thin provisioning even though the virtual disk advertises them. > > Last time around we identified this as a problem with Microsoft's > interpretation of the T10 SBC spec. And they promised that they are > going to fix that. OK but if we were happy to wait for Microsoft to fix the problem on the host why were the (broken and incomplete) BLIST_SKIP_VPD_PAGES patches committed to 3.17 rather than withdrawn? What's going to be done about those patches now? -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 28/47] power/reset: at91-poweroff: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Select default priority to reflect that the original code sets
pm_power_off unconditionally.
Signed-off-by: Guenter Roeck
---
v2: Added patch
drivers/power/reset/at91-poweroff.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/power/reset/at91-poweroff.c
b/drivers/power/reset/at91-poweroff.c
index c610003..ac49a83 100644
--- a/drivers/power/reset/at91-poweroff.c
+++ b/drivers/power/reset/at91-poweroff.c
@@ -12,8 +12,10 @@
#include
#include
+#include
#include
#include
+#include
#include
#define AT91_SHDW_CR 0x00/* Shut Down Control Register */
@@ -66,11 +68,19 @@ static void __init at91_wakeup_status(void)
pr_info("AT91: Wake-Up source: %s\n", reason);
}
-static void at91_poweroff(void)
+static int at91_poweroff(struct notifier_block *this, unsigned long unused1,
+void *unused2)
{
writel(AT91_SHDW_KEY | AT91_SHDW_SHDW, at91_shdwc_base + AT91_SHDW_CR);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block at91_poweroff_nb = {
+ .notifier_call = at91_poweroff,
+ .priority = POWEROFF_PRIORITY_DEFAULT,
+};
+
const enum wakeup_type at91_poweroff_get_wakeup_mode(struct device_node *np)
{
const char *pm;
@@ -134,9 +144,7 @@ static int at91_poweroff_probe(struct platform_device *pdev)
if (pdev->dev.of_node)
at91_poweroff_dt_set_wakeup_mode(pdev);
- pm_power_off = at91_poweroff;
-
- return 0;
+ return devm_register_power_off_handler(>dev, _poweroff_nb);
}
static struct of_device_id at91_poweroff_of_match[] = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 24/47] power/reset: as3722-poweroff: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Drop remove function since it is no longer needed.
Cc: Sebastian Reichel
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use devm_register_power_off_handler
- Drop remove function since it is no longer needed
drivers/power/reset/as3722-poweroff.c | 39 ++-
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/power/reset/as3722-poweroff.c
b/drivers/power/reset/as3722-poweroff.c
index 6849711..9f878e7 100644
--- a/drivers/power/reset/as3722-poweroff.c
+++ b/drivers/power/reset/as3722-poweroff.c
@@ -17,32 +17,33 @@
#include
#include
+#include
#include
#include
#include
+#include
#include
struct as3722_poweroff {
struct device *dev;
struct as3722 *as3722;
+ struct notifier_block poweroff_nb;
};
-static struct as3722_poweroff *as3722_pm_poweroff;
-
-static void as3722_pm_power_off(void)
+static int as3722_power_off(struct notifier_block *this, unsigned long unused1,
+ void *unused2)
{
+ struct as3722_poweroff *as3722_poweroff =
+ container_of(this, struct as3722_poweroff, poweroff_nb);
int ret;
- if (!as3722_pm_poweroff) {
- pr_err("AS3722 poweroff is not initialised\n");
- return;
- }
-
- ret = as3722_update_bits(as3722_pm_poweroff->as3722,
+ ret = as3722_update_bits(as3722_poweroff->as3722,
AS3722_RESET_CONTROL_REG, AS3722_POWER_OFF, AS3722_POWER_OFF);
if (ret < 0)
- dev_err(as3722_pm_poweroff->dev,
+ dev_err(as3722_poweroff->dev,
"RESET_CONTROL_REG update failed, %d\n", ret);
+
+ return NOTIFY_DONE;
}
static int as3722_poweroff_probe(struct platform_device *pdev)
@@ -63,20 +64,11 @@ static int as3722_poweroff_probe(struct platform_device
*pdev)
as3722_poweroff->as3722 = dev_get_drvdata(pdev->dev.parent);
as3722_poweroff->dev = >dev;
- as3722_pm_poweroff = as3722_poweroff;
- if (!pm_power_off)
- pm_power_off = as3722_pm_power_off;
-
- return 0;
-}
-
-static int as3722_poweroff_remove(struct platform_device *pdev)
-{
- if (pm_power_off == as3722_pm_power_off)
- pm_power_off = NULL;
- as3722_pm_poweroff = NULL;
+ as3722_poweroff->poweroff_nb.notifier_call = as3722_power_off;
+ as3722_poweroff->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
- return 0;
+ return devm_register_power_off_handler(>dev,
+ _poweroff->poweroff_nb);
}
static struct platform_driver as3722_poweroff_driver = {
@@ -85,7 +77,6 @@ static struct platform_driver as3722_poweroff_driver = {
.owner = THIS_MODULE,
},
.probe = as3722_poweroff_probe,
- .remove = as3722_poweroff_remove,
};
module_platform_driver(as3722_poweroff_driver);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 26/47] power/reset: msm-poweroff: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Select fallback priority since the code does not really poweroff
the system but resets it instead.
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Fix headline and description
- Merge with restart handler code now used in same driver
- Use dev_warn instead of dev_err
drivers/power/reset/msm-poweroff.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/power/reset/msm-poweroff.c
b/drivers/power/reset/msm-poweroff.c
index 4702efd..d44f332 100644
--- a/drivers/power/reset/msm-poweroff.c
+++ b/drivers/power/reset/msm-poweroff.c
@@ -19,10 +19,12 @@
#include
#include
#include
+#include
#include
#include
static void __iomem *msm_ps_hold;
+
static int do_msm_restart(struct notifier_block *nb, unsigned long action,
void *data)
{
@@ -37,11 +39,11 @@ static struct notifier_block restart_nb = {
.priority = 128,
};
-static void do_msm_poweroff(void)
-{
+static struct notifier_block msm_poweroff_nb = {
/* TODO: Add poweroff capability */
- do_msm_restart(_nb, 0, NULL);
-}
+ .notifier_call = do_msm_restart,
+ .priority = POWEROFF_PRIORITY_FALLBACK,
+};
static int msm_restart_probe(struct platform_device *pdev)
{
@@ -55,7 +57,8 @@ static int msm_restart_probe(struct platform_device *pdev)
register_restart_handler(_nb);
- pm_power_off = do_msm_poweroff;
+ if (register_power_off_handler(_poweroff_nb))
+ dev_warn(>dev, "Failed to register poweroff handler\n");
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 37/47] avr32: atngw100: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly.
Cc: Haavard Skinnemoen
Cc: Hans-Christian Egtvedt
Signed-off-by: Guenter Roeck
---
- Use define to specify poweroff handler priority
arch/avr32/boards/atngw100/mrmt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/avr32/boards/atngw100/mrmt.c
b/arch/avr32/boards/atngw100/mrmt.c
index 91146b4..833212e 100644
--- a/arch/avr32/boards/atngw100/mrmt.c
+++ b/arch/avr32/boards/atngw100/mrmt.c
@@ -274,7 +274,8 @@ static int __init mrmt1_init(void)
{
gpio_set_value( PIN_PWR_ON, 1 );/* Ensure PWR_ON is enabled */
- pm_power_off = mrmt_power_off;
+ register_power_off_handler_simple(mrmt_power_off,
+ POWEROFF_PRIORITY_DEFAULT);
/* Setup USARTS (other than console) */
at32_map_usart(2, 1, 0);/* USART 2: /dev/ttyS1, RMT1:DB9M */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 30/47] x86: iris: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with high priority to reflect that the original code
overwrites existing poweroff handlers.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use devm_register_power_off_handler
arch/x86/platform/iris/iris.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/x86/platform/iris/iris.c b/arch/x86/platform/iris/iris.c
index 4d171e8..dd36815 100644
--- a/arch/x86/platform/iris/iris.c
+++ b/arch/x86/platform/iris/iris.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
#include
@@ -47,15 +48,21 @@ static bool force;
module_param(force, bool, 0);
MODULE_PARM_DESC(force, "Set to one to force poweroff handler installation.");
-static void (*old_pm_power_off)(void);
-
-static void iris_power_off(void)
+static int iris_power_off(struct notifier_block *this, unsigned long unused1,
+ void *unused2)
{
outb(IRIS_GIO_PULSE, IRIS_GIO_OUTPUT);
msleep(850);
outb(IRIS_GIO_REST, IRIS_GIO_OUTPUT);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block iris_poweroff_nb = {
+ .notifier_call = iris_power_off,
+ .priority = POWEROFF_PRIORITY_HIGH,
+};
+
/*
* Before installing the power_off handler, try to make sure the OS is
* running on an Iris. Since Iris does not support DMI, this is done
@@ -65,20 +72,25 @@ static void iris_power_off(void)
static int iris_probe(struct platform_device *pdev)
{
unsigned char status = inb(IRIS_GIO_INPUT);
+ int ret;
+
if (status == IRIS_GIO_NODEV) {
printk(KERN_ERR "This machine does not seem to be an Iris. "
"Power off handler not installed.\n");
return -ENODEV;
}
- old_pm_power_off = pm_power_off;
- pm_power_off = _power_off;
+
+ ret = devm_register_power_off_handler(>dev, _poweroff_nb);
+ if (ret) {
+ dev_err(>dev, "Failed to register poweroff handler\n");
+ return ret;
+ }
printk(KERN_INFO "Iris power_off handler installed.\n");
return 0;
}
static int iris_remove(struct platform_device *pdev)
{
- pm_power_off = old_pm_power_off;
printk(KERN_INFO "Iris power_off handler uninstalled.\n");
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 34/47] acpi: Register poweroff handler with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with high priority to reflect that the driver explicitly
overrides existing poweroff handlers.
Cc: Rafael J. Wysocki
Cc: Len Brown
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use pr_warn instead of pr_err
drivers/acpi/sleep.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 05a31b5..1eba563 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -827,14 +829,22 @@ static void acpi_power_off_prepare(void)
acpi_disable_all_gpes();
}
-static void acpi_power_off(void)
+static int acpi_power_off(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
{
/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
printk(KERN_DEBUG "%s called\n", __func__);
local_irq_disable();
acpi_enter_sleep_state(ACPI_STATE_S5);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block acpi_poweroff_nb = {
+ .notifier_call = acpi_power_off,
+ .priority = POWEROFF_PRIORITY_HIGH,
+};
+
int __init acpi_sleep_init(void)
{
char supported[ACPI_S_STATE_COUNT * 3 + 1];
@@ -851,7 +861,8 @@ int __init acpi_sleep_init(void)
if (acpi_sleep_state_supported(ACPI_STATE_S5)) {
sleep_states[ACPI_STATE_S5] = 1;
pm_power_off_prepare = acpi_power_off_prepare;
- pm_power_off = acpi_power_off;
+ if (register_power_off_handler(_poweroff_nb))
+ pr_warn("acpi: Failed to register poweroff handler\n");
}
supported[0] = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 31/47] x86: apm: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with high priority to reflect that the original code
overwrites existing poweroff handlers.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Jiri Kosina
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
arch/x86/kernel/apm_32.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index 5848744..b03a65e 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -219,6 +219,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -981,7 +982,8 @@ recalc:
* on their first cpu.
*/
-static void apm_power_off(void)
+static int apm_power_off(struct notifier_block *this, unsigned long unused1,
+void *unused2)
{
/* Some bioses don't like being called from CPU != 0 */
if (apm_info.realmode_power_off) {
@@ -990,8 +992,14 @@ static void apm_power_off(void)
} else {
(void)set_system_power_state(APM_STATE_OFF);
}
+ return NOTIFY_DONE;
}
+static struct notifier_block apm_poweroff_nb = {
+ .notifier_call = apm_power_off,
+ .priority = POWEROFF_PRIORITY_HIGH,
+};
+
#ifdef CONFIG_APM_DO_ENABLE
/**
@@ -1847,8 +1855,11 @@ static int apm(void *unused)
}
/* Install our power off handler.. */
- if (power_off)
- pm_power_off = apm_power_off;
+ if (power_off) {
+ error = register_power_off_handler(_poweroff_nb);
+ if (error)
+ pr_err("apm: Failed to register poweroff handler\n");
+ }
if (num_online_cpus() == 1 || smp) {
#if defined(CONFIG_APM_DISPLAY_BLANK) && defined(CONFIG_VT)
@@ -2408,9 +2419,8 @@ static void __exit apm_exit(void)
apm_error("disengage power management", error);
}
misc_deregister(_device);
+ unregister_power_off_handler(_poweroff_nb);
remove_proc_entry("apm", NULL);
- if (power_off)
- pm_power_off = NULL;
if (kapmd_task) {
kthread_stop(kapmd_task);
kapmd_task = NULL;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 32/47] x86: olpc: Register xo1 poweroff handler with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with high priority to reflect that the driver
explicitly wants to override default poweroff handlers.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Signed-off-by: Guenter Roeck
---
v2: Use define to specify poweroff handler priority
arch/x86/platform/olpc/olpc-xo1-pm.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/x86/platform/olpc/olpc-xo1-pm.c
b/arch/x86/platform/olpc/olpc-xo1-pm.c
index a9acde7..a8e427f 100644
--- a/arch/x86/platform/olpc/olpc-xo1-pm.c
+++ b/arch/x86/platform/olpc/olpc-xo1-pm.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -92,7 +93,8 @@ asmlinkage __visible int xo1_do_sleep(u8 sleep_state)
return 0;
}
-static void xo1_power_off(void)
+static int xo1_power_off(struct notifier_block *this, unsigned long unused1,
+void *unused2)
{
printk(KERN_INFO "OLPC XO-1 power off sequence...\n");
@@ -108,8 +110,15 @@ static void xo1_power_off(void)
/* Write SLP_EN bit to start the machinery */
outl(0x2000, acpi_base + CS5536_PM1_CNT);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block xo1_poweroff_nb = {
+ .notifier_call = xo1_power_off,
+ .priority = POWEROFF_PRIORITY_HIGH,
+};
+
static int xo1_power_state_valid(suspend_state_t pm_state)
{
/* suspend-to-RAM only */
@@ -146,8 +155,12 @@ static int xo1_pm_probe(struct platform_device *pdev)
/* If we have both addresses, we can override the poweroff hook */
if (pms_base && acpi_base) {
+ err = register_power_off_handler(_poweroff_nb);
+ if (err) {
+ dev_err(>dev, "Failed to register poweroff
handler\n");
+ return err;
+ }
suspend_set_ops(_suspend_ops);
- pm_power_off = xo1_power_off;
printk(KERN_INFO "OLPC XO-1 support registered\n");
}
@@ -158,12 +171,13 @@ static int xo1_pm_remove(struct platform_device *pdev)
{
mfd_cell_disable(pdev);
+ unregister_power_off_handler(_poweroff_nb);
+
if (strcmp(pdev->name, "cs5535-pms") == 0)
pms_base = 0;
else if (strcmp(pdev->name, "olpc-xo1-pm-acpi") == 0)
acpi_base = 0;
- pm_power_off = NULL;
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
On Tue, Oct 14, 2014 at 09:06:37PM -0400, Martin K. Petersen wrote:
> > "Sitsofe" == Sitsofe Wheeler writes:
>
> Sitsofe> A previous patch attempted to add a quirk to workaround this
> Sitsofe> but the quirk was only enabled after the features had been
> Sitsofe> scanned for, wouldn't work for "small" disks
>
> What does that mean, exactly?
It means:
1. The committed patches never worked because the running of the code to
test whether the quirk should be enabled happened after the probing code
the quirk would have affected ran. So roughly:
bflag = 0;
if (feature || bflag) {
do_stuff();
}
if (matching_dev) {
bflag = 1; // Too late...
}
See https://lkml.org/lkml/2014/7/23/615 for prior details.
2. On top of the above, when a disk is "small" (has less than 2^32
sectors which is typically < 2 TBytes in size) READ CAPACITY(16) won't
be triggered. If READ CAPACITY(16) isn't triggered then the lbpme bytes
won't be checked, thin provisioning will never be enabled and the
committed patch would doubly not work for such disks.
Apologies for the delay in replying.
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 36/47] arm64: psci: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off directly. Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Guenter Roeck --- - Use define to specify poweroff handler priority arch/arm64/kernel/psci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c index 866c1c8..150ac1c 100644 --- a/arch/arm64/kernel/psci.c +++ b/arch/arm64/kernel/psci.c @@ -359,7 +359,8 @@ static int __init psci_0_2_init(struct device_node *np) arm_pm_restart = psci_sys_reset; - pm_power_off = psci_sys_poweroff; + register_power_off_handler_simple(psci_sys_poweroff, + POWEROFF_PRIORITY_DEFAULT); out_put_node: of_node_put(np); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 42/47] x86: lguest: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off directly. Cc: Rusty Russell Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Signed-off-by: Guenter Roeck --- - Use define to specify poweroff handler priority arch/x86/lguest/boot.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c index aae9413..913a95e 100644 --- a/arch/x86/lguest/boot.c +++ b/arch/x86/lguest/boot.c @@ -1441,7 +1441,8 @@ __init void lguest_init(void) * the Guest routine to power off, and the reboot hook to our restart * routine. */ - pm_power_off = lguest_power_off; + register_power_off_handler_simple(lguest_power_off, + POWEROFF_PRIORITY_DEFAULT); machine_ops.restart = lguest_restart; /* -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 38/47] ia64: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off directly. Register with low priority to reflect that the call is expected to be replaced at some point in the future. Cc: Tony Luck Cc: Fenghua Yu Signed-off-by: Guenter Roeck --- - Use define to specify poweroff handler priority arch/ia64/sn/kernel/setup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/ia64/sn/kernel/setup.c b/arch/ia64/sn/kernel/setup.c index 5f6b6b4..1888aeb 100644 --- a/arch/ia64/sn/kernel/setup.c +++ b/arch/ia64/sn/kernel/setup.c @@ -488,12 +488,13 @@ void __init sn_setup(char **cmdline_p) sn_timer_init(); /* -* set pm_power_off to a SAL call to allow +* set poweroff handler to a SAL call to allow * sn machines to power off. The SAL call can be replaced * by an ACPI interface call when ACPI is fully implemented * for sn. */ - pm_power_off = ia64_sn_power_down; + register_power_off_handler_simple(ia64_sn_power_down, + POWEROFF_PRIORITY_LOW); current->thread.flags |= IA64_THREAD_MIGRATION; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 41/47] sh: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly.
Signed-off-by: Guenter Roeck
---
- Use defines to specify poweroff handler priorities
arch/sh/boards/board-sh7785lcr.c | 3 ++-
arch/sh/boards/board-urquell.c | 3 ++-
arch/sh/boards/mach-highlander/setup.c | 3 ++-
arch/sh/boards/mach-landisk/setup.c| 3 ++-
arch/sh/boards/mach-r2d/setup.c| 3 ++-
arch/sh/boards/mach-sdk7786/setup.c| 3 ++-
6 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/sh/boards/board-sh7785lcr.c b/arch/sh/boards/board-sh7785lcr.c
index 2c4771e..ada9f6a 100644
--- a/arch/sh/boards/board-sh7785lcr.c
+++ b/arch/sh/boards/board-sh7785lcr.c
@@ -332,7 +332,8 @@ static void __init sh7785lcr_setup(char **cmdline_p)
printk(KERN_INFO "Renesas Technology Corp. R0P7785LC0011RL support.\n");
- pm_power_off = sh7785lcr_power_off;
+ register_power_off_handler_simple(sh7785lcr_power_off,
+ POWEROFF_PRIORITY_DEFAULT);
/* sm501 DRAM configuration */
sm501_reg = ioremap_nocache(SM107_REG_ADDR, SM501_DRAM_CONTROL);
diff --git a/arch/sh/boards/board-urquell.c b/arch/sh/boards/board-urquell.c
index b52abcc..2188fee 100644
--- a/arch/sh/boards/board-urquell.c
+++ b/arch/sh/boards/board-urquell.c
@@ -204,7 +204,8 @@ static void __init urquell_setup(char **cmdline_p)
{
printk(KERN_INFO "Renesas Technology Corp. Urquell support.\n");
- pm_power_off = urquell_power_off;
+ register_power_off_handler_simple(urquell_power_off,
+ POWEROFF_PRIORITY_DEFAULT);
register_smp_ops(_smp_ops);
}
diff --git a/arch/sh/boards/mach-highlander/setup.c
b/arch/sh/boards/mach-highlander/setup.c
index 4a52590..efb848a 100644
--- a/arch/sh/boards/mach-highlander/setup.c
+++ b/arch/sh/boards/mach-highlander/setup.c
@@ -385,7 +385,8 @@ static void __init highlander_setup(char **cmdline_p)
__raw_writew(__raw_readw(PA_IVDRCTL) | 0x01, PA_IVDRCTL); /*
Si13112 */
- pm_power_off = r7780rp_power_off;
+ register_power_off_handler_simple(r7780rp_power_off,
+ POWEROFF_PRIORITY_DEFAULT);
}
static unsigned char irl2irq[HL_NR_IRL];
diff --git a/arch/sh/boards/mach-landisk/setup.c
b/arch/sh/boards/mach-landisk/setup.c
index f1147ca..50d9388 100644
--- a/arch/sh/boards/mach-landisk/setup.c
+++ b/arch/sh/boards/mach-landisk/setup.c
@@ -89,7 +89,8 @@ static void __init landisk_setup(char **cmdline_p)
__raw_writeb(__raw_readb(PA_LED) | 0x03, PA_LED);
printk(KERN_INFO "I-O DATA DEVICE, INC. \"LANDISK Series\" support.\n");
- pm_power_off = landisk_power_off;
+ register_power_off_handler_simple(landisk_power_off,
+ POWEROFF_PRIORITY_DEFAULT);
}
/*
diff --git a/arch/sh/boards/mach-r2d/setup.c b/arch/sh/boards/mach-r2d/setup.c
index 4b98a52..28add25 100644
--- a/arch/sh/boards/mach-r2d/setup.c
+++ b/arch/sh/boards/mach-r2d/setup.c
@@ -279,7 +279,8 @@ static void __init rts7751r2d_setup(char **cmdline_p)
(ver >> 4) & 0xf, ver & 0xf);
__raw_writew(0x, PA_OUTPORT);
- pm_power_off = rts7751r2d_power_off;
+ register_power_off_handler_simple(rts7751r2d_power_off,
+ POWEROFF_PRIORITY_DEFAULT);
/* sm501 dram configuration:
* ColSizeX = 11 - External Memory Column Size: 256 words.
diff --git a/arch/sh/boards/mach-sdk7786/setup.c
b/arch/sh/boards/mach-sdk7786/setup.c
index c29268b..eee7b9c 100644
--- a/arch/sh/boards/mach-sdk7786/setup.c
+++ b/arch/sh/boards/mach-sdk7786/setup.c
@@ -252,7 +252,8 @@ static void __init sdk7786_setup(char **cmdline_p)
pr_info("\tPCB revision:\t%d\n", fpga_read_reg(PCBRR) & 0xf);
machine_ops.restart = sdk7786_restart;
- pm_power_off = sdk7786_power_off;
+ register_power_off_handler_simple(sdk7786_power_off,
+ POWEROFF_PRIORITY_DEFAULT);
register_smp_ops(_smp_ops);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 39/47] m68k: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly.
Cc: Geert Uytterhoeven
Cc: Joshua Thompson
Acked-by: Geert Uytterhoeven
Signed-off-by: Guenter Roeck
---
- Use defines to specify poweroff handler priorities
arch/m68k/emu/natfeat.c | 3 ++-
arch/m68k/mac/config.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/emu/natfeat.c b/arch/m68k/emu/natfeat.c
index 91e2ae7..b105681 100644
--- a/arch/m68k/emu/natfeat.c
+++ b/arch/m68k/emu/natfeat.c
@@ -91,5 +91,6 @@ void __init nf_init(void)
pr_info("NatFeats found (%s, %lu.%lu)\n", buf, version >> 16,
version & 0x);
- pm_power_off = nf_poweroff;
+ register_power_off_handler_simple(nf_poweroff,
+ POWEROFF_PRIORITY_DEFAULT);
}
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index 677913ff..07e853e 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -160,7 +160,8 @@ void __init config_mac(void)
mach_set_clock_mmss = mac_set_clock_mmss;
mach_reset = mac_reset;
mach_halt = mac_poweroff;
- pm_power_off = mac_poweroff;
+ register_power_off_handler_simple(mac_poweroff,
+ POWEROFF_PRIORITY_DEFAULT);
mach_max_dma_address = 0x;
#if defined(CONFIG_INPUT_M68K_BEEP) || defined(CONFIG_INPUT_M68K_BEEP_MODULE)
mach_beep = mac_mksound;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init: Remove CONFIG_INIT_FALLBACK
On 10/20/14 23:02, Andy Lutomirski wrote:
> On Mon, Oct 20, 2014 at 8:45 PM, Rob Landley wrote:
>> On 10/20/14 17:04, Andy Lutomirski wrote:
>>> --- a/init/main.c
>>> +++ b/init/main.c
>>> @@ -960,13 +960,8 @@ static int __ref kernel_init(void *unused)
>>> ret = run_init_process(execute_command);
>>> if (!ret)
>>> return 0;
>>> -#ifndef CONFIG_INIT_FALLBACK
>>> panic("Requested init %s failed (error %d).",
>>> execute_command, ret);
>>> -#else
>>> - pr_err("Failed to execute %s (error %d). Attempting
>>> defaults...\n",
>>> -execute_command, ret);
>>> -#endif
>>> }
>>> if (!try_to_run_init_process("/sbin/init") ||
>>> !try_to_run_init_process("/etc/init") ||
>>>
>>
>> Would you like to remove the try_to_run_init_process() stack of random
>> hardwired names that we can never reach if we panic, or do you just want
>> to remove the error message?
>>
>
> I'm confused. That code is reachable if there's no initramfs and
> init= is not specified.
Ah, I thought the purpose of the original patch was to make init=
required, but if not then fine.
/etc/init is still crazy, though.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 46/47] efi: Register poweroff handler with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority since the efi code states that
this is a poweroff handler of last resort.
Cc: Matt Fleming
Acked-by: Matt Fleming
Acked-by: Mark Salter
Signed-off-by: Guenter Roeck
---
- Use define to specify poweroff handler priority
drivers/firmware/efi/reboot.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/efi/reboot.c b/drivers/firmware/efi/reboot.c
index 9c59d1c..e1c4f7a 100644
--- a/drivers/firmware/efi/reboot.c
+++ b/drivers/firmware/efi/reboot.c
@@ -3,6 +3,8 @@
* Copyright (c) 2014 Red Hat, Inc., Mark Salter
*/
#include
+#include
+#include
#include
int efi_reboot_quirk_mode = -1;
@@ -38,19 +40,32 @@ bool __weak efi_poweroff_required(void)
return false;
}
-static void efi_power_off(void)
+static int efi_power_off(struct notifier_block *this,
+unsigned long unused1, void *unused2)
{
efi.reset_system(EFI_RESET_SHUTDOWN, EFI_SUCCESS, 0, NULL);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block efi_poweroff_nb = {
+ .notifier_call = efi_power_off,
+ .priority = POWEROFF_PRIORITY_LOW,
+};
+
static int __init efi_shutdown_init(void)
{
+ int ret = 0;
+
if (!efi_enabled(EFI_RUNTIME_SERVICES))
return -ENODEV;
- if (efi_poweroff_required())
- pm_power_off = efi_power_off;
+ if (efi_poweroff_required()) {
+ ret = register_power_off_handler(_poweroff_nb);
+ if (ret)
+ pr_err("efi: Failed to register poweroff handler\n");
+ }
- return 0;
+ return ret;
}
late_initcall(efi_shutdown_init);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 47/47] kernel: Remove pm_power_off
No users of pm_power_off are left, so it is safe to remove the function.
Cc: Rafael J. Wysocki
Cc: Pavel Machek
Cc: Len Brown
Acked-by: Rafael J. Wysocki
Signed-off-by: Guenter Roeck
---
v2: poweroff -> power_off
include/linux/pm.h | 1 -
kernel/power/poweroff_handler.c | 10 +-
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 7e0cb36..316271d 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -31,7 +31,6 @@
/*
* Callbacks for platform drivers to implement.
*/
-extern void (*pm_power_off)(void);
extern void (*pm_power_off_prepare)(void);
/*
diff --git a/kernel/power/poweroff_handler.c b/kernel/power/poweroff_handler.c
index 37f0b88..d2d164e 100644
--- a/kernel/power/poweroff_handler.c
+++ b/kernel/power/poweroff_handler.c
@@ -22,12 +22,6 @@
#include
/*
- * If set, calling this function will power off the system immediately.
- */
-void (*pm_power_off)(void);
-EXPORT_SYMBOL(pm_power_off);
-
-/*
* Notifier list for kernel code which wants to be called
* to power off the system.
*/
@@ -242,8 +236,6 @@ EXPORT_SYMBOL(devm_register_power_off_handler);
void do_kernel_power_off(void)
{
spin_lock(_off_handler_lock);
- if (pm_power_off)
- pm_power_off();
raw_notifier_call_chain(_off_handler_list, 0, NULL);
spin_unlock(_off_handler_lock);
}
@@ -255,6 +247,6 @@ void do_kernel_power_off(void)
*/
bool have_kernel_power_off(void)
{
- return pm_power_off != NULL || power_off_handler_list.head != NULL;
+ return power_off_handler_list.head != NULL;
}
EXPORT_SYMBOL(have_kernel_power_off);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 43/47] x86: ce4100: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off directly. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Signed-off-by: Guenter Roeck --- - Use define to specify poweroff handler priority arch/x86/platform/ce4100/ce4100.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/platform/ce4100/ce4100.c b/arch/x86/platform/ce4100/ce4100.c index 701fd58..379260e 100644 --- a/arch/x86/platform/ce4100/ce4100.c +++ b/arch/x86/platform/ce4100/ce4100.c @@ -164,5 +164,6 @@ void __init x86_ce4100_early_setup(void) */ reboot_type = BOOT_KBD; - pm_power_off = ce4100_power_off; + register_power_off_handler_simple(ce4100_power_off, + POWEROFF_PRIORITY_DEFAULT); } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 45/47] x86: pmc_atom: Register poweroff handler with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Signed-off-by: Guenter Roeck
---
- Use define to specify poweroff handler priority
- Use dev_warn instead of dev_err
arch/x86/kernel/pmc_atom.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/pmc_atom.c b/arch/x86/kernel/pmc_atom.c
index 0ee5025e..7799cdf 100644
--- a/arch/x86/kernel/pmc_atom.c
+++ b/arch/x86/kernel/pmc_atom.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -92,7 +94,8 @@ static inline void pmc_reg_write(struct pmc_dev *pmc, int
reg_offset, u32 val)
writel(val, pmc->regmap + reg_offset);
}
-static void pmc_power_off(void)
+static int pmc_power_off(struct notifier_block *this, unsigned long unused1,
+void *unused2)
{
u16 pm1_cnt_port;
u32 pm1_cnt_value;
@@ -107,8 +110,15 @@ static void pmc_power_off(void)
pm1_cnt_value |= SLEEP_ENABLE;
outl(pm1_cnt_value, pm1_cnt_port);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block pmc_poweroff_nb = {
+ .notifier_call = pmc_power_off,
+ .priority = POWEROFF_PRIORITY_LOW,
+};
+
static void pmc_hw_reg_setup(struct pmc_dev *pmc)
{
/*
@@ -252,8 +262,12 @@ static int pmc_setup_dev(struct pci_dev *pdev)
acpi_base_addr &= ACPI_BASE_ADDR_MASK;
/* Install power off function */
- if (acpi_base_addr != 0 && pm_power_off == NULL)
- pm_power_off = pmc_power_off;
+ if (acpi_base_addr != 0) {
+ ret = register_power_off_handler(_poweroff_nb);
+ if (ret)
+ dev_warn(>dev,
+"Failed to install poweroff handler\n");
+ }
pci_read_config_dword(pdev, PMC_BASE_ADDR_OFFSET, >base_addr);
pmc->base_addr &= PMC_BASE_ADDR_MASK;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 44/47] x86: intel-mid: Drop registration of dummy poweroff handlers
A dummy poweroff handler does not serve any purpose. Drop it.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Signed-off-by: Guenter Roeck
---
- Use define to specify poweroff handler priority
arch/x86/platform/intel-mid/intel-mid.c | 5 -
arch/x86/platform/intel-mid/mfld.c | 5 -
2 files changed, 10 deletions(-)
diff --git a/arch/x86/platform/intel-mid/intel-mid.c
b/arch/x86/platform/intel-mid/intel-mid.c
index 1bbedc4..4b70666 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -67,10 +67,6 @@ static void *(*get_intel_mid_ops[])(void) =
INTEL_MID_OPS_INIT;
enum intel_mid_cpu_type __intel_mid_cpu_chip;
EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
-static void intel_mid_power_off(void)
-{
-};
-
static void intel_mid_reboot(void)
{
intel_scu_ipc_simple_command(IPCMSG_COLD_BOOT, 0);
@@ -183,7 +179,6 @@ void __init x86_intel_mid_early_setup(void)
legacy_pic = _legacy_pic;
- pm_power_off = intel_mid_power_off;
machine_ops.emergency_restart = intel_mid_reboot;
/* Avoid searching for BIOS MP tables */
diff --git a/arch/x86/platform/intel-mid/mfld.c
b/arch/x86/platform/intel-mid/mfld.c
index 23381d2..cf6842f 100644
--- a/arch/x86/platform/intel-mid/mfld.c
+++ b/arch/x86/platform/intel-mid/mfld.c
@@ -23,10 +23,6 @@ static struct intel_mid_ops penwell_ops = {
.arch_setup = penwell_arch_setup,
};
-static void mfld_power_off(void)
-{
-}
-
static unsigned long __init mfld_calibrate_tsc(void)
{
unsigned long fast_calibrate;
@@ -61,7 +57,6 @@ static unsigned long __init mfld_calibrate_tsc(void)
static void __init penwell_arch_setup(void)
{
x86_platform.calibrate_tsc = mfld_calibrate_tsc;
- pm_power_off = mfld_power_off;
}
void *get_penwell_ops(void)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 40/47] mips: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly.
If there is an indication that there can be more than one poweroff handler,
use register_power_off_handler, otherwise use register_power_off_handler_simple
to register the poweroff handler.
If the poweroff handler only resets or stops the system, select the fallback
priority to indicate that the poweroff handler is one of last resort.
If the poweroff handler powers off the system, select the default priority,
unless the poweroff handler installation code suggests that there can be
more than one poweroff handler and the new handler is only installed
conditionally. In this case, install the handler with low priority.
Cc: Ralf Baechle
Cc: Maciej W. Rozycki
Signed-off-by: Guenter Roeck
---
- Use defines to specify poweroff handler priorities
arch/mips/alchemy/board-gpr.c | 3 ++-
arch/mips/alchemy/board-mtx1.c | 3 ++-
arch/mips/alchemy/board-xxs1500.c | 3 ++-
arch/mips/alchemy/devboards/platform.c | 17 +++--
arch/mips/ar7/setup.c | 3 ++-
arch/mips/ath79/setup.c| 3 ++-
arch/mips/bcm47xx/setup.c | 3 ++-
arch/mips/bcm63xx/setup.c | 3 ++-
arch/mips/cobalt/setup.c | 3 ++-
arch/mips/dec/setup.c | 3 ++-
arch/mips/emma/markeins/setup.c| 3 ++-
arch/mips/jz4740/reset.c | 3 ++-
arch/mips/lantiq/falcon/reset.c| 3 ++-
arch/mips/lantiq/xway/reset.c | 3 ++-
arch/mips/lasat/reset.c| 3 ++-
arch/mips/loongson/common/reset.c | 3 ++-
arch/mips/loongson1/common/reset.c | 3 ++-
arch/mips/mti-malta/malta-reset.c | 3 ++-
arch/mips/mti-sead3/sead3-reset.c | 3 ++-
arch/mips/netlogic/xlp/setup.c | 3 ++-
arch/mips/netlogic/xlr/setup.c | 3 ++-
arch/mips/pmcs-msp71xx/msp_setup.c | 3 ++-
arch/mips/pnx833x/common/setup.c | 3 ++-
arch/mips/ralink/reset.c | 3 ++-
arch/mips/rb532/setup.c| 3 ++-
arch/mips/sgi-ip22/ip22-reset.c| 3 ++-
arch/mips/sgi-ip27/ip27-reset.c| 3 ++-
arch/mips/sgi-ip32/ip32-reset.c| 3 ++-
arch/mips/sibyte/common/cfe.c | 3 ++-
arch/mips/sni/setup.c | 3 ++-
arch/mips/txx9/generic/setup.c | 3 ++-
arch/mips/vr41xx/common/pmu.c | 3 ++-
32 files changed, 77 insertions(+), 33 deletions(-)
diff --git a/arch/mips/alchemy/board-gpr.c b/arch/mips/alchemy/board-gpr.c
index acf9a2a..3e06384 100644
--- a/arch/mips/alchemy/board-gpr.c
+++ b/arch/mips/alchemy/board-gpr.c
@@ -89,7 +89,8 @@ void __init board_setup(void)
{
printk(KERN_INFO "Trapeze ITS GPR board\n");
- pm_power_off = gpr_power_off;
+ register_power_off_handler_simple(gpr_power_off,
+ POWEROFF_PRIORITY_FALLBACK);
_machine_halt = gpr_power_off;
_machine_restart = gpr_reset;
diff --git a/arch/mips/alchemy/board-mtx1.c b/arch/mips/alchemy/board-mtx1.c
index 1e3b102..4fd3cee 100644
--- a/arch/mips/alchemy/board-mtx1.c
+++ b/arch/mips/alchemy/board-mtx1.c
@@ -98,7 +98,8 @@ void __init board_setup(void)
alchemy_gpio_direction_output(211, 1); /* green on */
alchemy_gpio_direction_output(212, 0); /* red off */
- pm_power_off = mtx1_power_off;
+ register_power_off_handler_simple(mtx1_power_off,
+ POWEROFF_PRIORITY_FALLBACK);
_machine_halt = mtx1_power_off;
_machine_restart = mtx1_reset;
diff --git a/arch/mips/alchemy/board-xxs1500.c
b/arch/mips/alchemy/board-xxs1500.c
index 0fc53e0..92d6d28 100644
--- a/arch/mips/alchemy/board-xxs1500.c
+++ b/arch/mips/alchemy/board-xxs1500.c
@@ -79,7 +79,8 @@ void __init board_setup(void)
{
u32 pin_func;
- pm_power_off = xxs1500_power_off;
+ register_power_off_handler_simple(xxs1500_power_off,
+ POWEROFF_PRIORITY_FALLBACK);
_machine_halt = xxs1500_power_off;
_machine_restart = xxs1500_reset;
diff --git a/arch/mips/alchemy/devboards/platform.c
b/arch/mips/alchemy/devboards/platform.c
index be139a0..1e1722a 100644
--- a/arch/mips/alchemy/devboards/platform.c
+++ b/arch/mips/alchemy/devboards/platform.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -64,10 +65,22 @@ static void db1x_reset(char *c)
bcsr_write(BCSR_SYSTEM, 0);
}
+static int db1x_power_off_notify(struct notifier_block *this,
+unsigned long unused1, void *unused2)
+{
+ db1x_power_off();
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block db1x_poweroff_nb = {
+ .notifier_call = db1x_power_off_notify,
+ .priority = POWEROFF_PRIORITY_LOW,
+};
+
static int __init db1x_late_setup(void)
{
- if (!pm_power_off)
- pm_power_off = db1x_power_off;
+
[PATCH v2 33/47] staging: nvec: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with default priority since we don't know any better.
Cc: Julian Andres Klode
Cc: Marc Dietrich
Cc: Greg Kroah-Hartman
Acked-by: Greg Kroah-Hartman
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use dev_warn instead of dev_err
drivers/staging/nvec/nvec.c | 24 +++-
drivers/staging/nvec/nvec.h | 2 ++
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index a93208a..78b68a3 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -80,8 +81,6 @@ enum nvec_sleep_subcmds {
#define LID_SWITCH BIT(1)
#define PWR_BUTTON BIT(15)
-static struct nvec_chip *nvec_power_handle;
-
static const struct mfd_cell nvec_devices[] = {
{
.name = "nvec-kbd",
@@ -759,12 +758,17 @@ static void nvec_disable_i2c_slave(struct nvec_chip *nvec)
}
#endif
-static void nvec_power_off(void)
+static int nvec_power_off(struct notifier_block *this, unsigned long unused1,
+ void *unused2)
{
+ struct nvec_chip *nvec = container_of(this, struct nvec_chip,
+ poweroff_nb);
char ap_pwr_down[] = { NVEC_SLEEP, AP_PWR_DOWN };
- nvec_toggle_global_events(nvec_power_handle, false);
- nvec_write_async(nvec_power_handle, ap_pwr_down, 2);
+ nvec_toggle_global_events(nvec, false);
+ nvec_write_async(nvec, ap_pwr_down, 2);
+
+ return NOTIFY_DONE;
}
/*
@@ -878,8 +882,11 @@ static int tegra_nvec_probe(struct platform_device *pdev)
nvec->nvec_status_notifier.notifier_call = nvec_status_notifier;
nvec_register_notifier(nvec, >nvec_status_notifier, 0);
- nvec_power_handle = nvec;
- pm_power_off = nvec_power_off;
+ nvec->poweroff_nb.notifier_call = nvec_power_off;
+ nvec->poweroff_nb.priority = POWEROFF_PRIORITY_DEFAULT;
+ ret = register_power_off_handler(>poweroff_nb);
+ if (ret)
+ dev_warn(nvec->dev, "Failed to register poweroff handler\n");
/* Get Firmware Version */
msg = nvec_write_sync(nvec, get_firmware_version, 2);
@@ -914,13 +921,12 @@ static int tegra_nvec_remove(struct platform_device *pdev)
{
struct nvec_chip *nvec = platform_get_drvdata(pdev);
+ unregister_power_off_handler(>poweroff_nb);
nvec_toggle_global_events(nvec, false);
mfd_remove_devices(nvec->dev);
nvec_unregister_notifier(nvec, >nvec_status_notifier);
cancel_work_sync(>rx_work);
cancel_work_sync(>tx_work);
- /* FIXME: needs check wether nvec is responsible for power off */
- pm_power_off = NULL;
return 0;
}
diff --git a/drivers/staging/nvec/nvec.h b/drivers/staging/nvec/nvec.h
index e271375..e5ee2af 100644
--- a/drivers/staging/nvec/nvec.h
+++ b/drivers/staging/nvec/nvec.h
@@ -163,6 +163,8 @@ struct nvec_chip {
struct nvec_msg *last_sync_msg;
int state;
+
+ struct notifier_block poweroff_nb;
};
extern int nvec_write_async(struct nvec_chip *nvec, const unsigned char *data,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 35/47] arm: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Always use register_power_off_handler_simple as there is no
indication that more than one poweroff handler is registered.
If the poweroff handler only resets the system or puts the CPU in sleep mode,
select the fallback priority to indicate that the poweroff handler is one
of last resort. If the poweroff handler powers off the system, select the
default priority.
Cc: Russell King
Signed-off-by: Guenter Roeck
---
- Use defines to specify poweroff handler priorities
- Drop changes in arch/arm/mach-at91/setup.c (file removed upstream)
arch/arm/kernel/psci.c | 3 ++-
arch/arm/mach-at91/board-gsia18s.c | 3 ++-
arch/arm/mach-bcm/board_bcm2835.c | 3 ++-
arch/arm/mach-cns3xxx/cns3420vb.c | 3 ++-
arch/arm/mach-cns3xxx/core.c | 3 ++-
arch/arm/mach-highbank/highbank.c | 3 ++-
arch/arm/mach-imx/mach-mx31moboard.c | 3 ++-
arch/arm/mach-iop32x/em7210.c | 3 ++-
arch/arm/mach-iop32x/glantank.c| 3 ++-
arch/arm/mach-iop32x/iq31244.c | 3 ++-
arch/arm/mach-iop32x/n2100.c | 3 ++-
arch/arm/mach-ixp4xx/dsmg600-setup.c | 3 ++-
arch/arm/mach-ixp4xx/nas100d-setup.c | 3 ++-
arch/arm/mach-ixp4xx/nslu2-setup.c | 3 ++-
arch/arm/mach-omap2/board-omap3touchbook.c | 3 ++-
arch/arm/mach-orion5x/board-mss2.c | 3 ++-
arch/arm/mach-orion5x/dns323-setup.c | 9 ++---
arch/arm/mach-orion5x/kurobox_pro-setup.c | 3 ++-
arch/arm/mach-orion5x/ls-chl-setup.c | 3 ++-
arch/arm/mach-orion5x/ls_hgl-setup.c | 3 ++-
arch/arm/mach-orion5x/lsmini-setup.c | 3 ++-
arch/arm/mach-orion5x/mv2120-setup.c | 3 ++-
arch/arm/mach-orion5x/net2big-setup.c | 3 ++-
arch/arm/mach-orion5x/terastation_pro2-setup.c | 3 ++-
arch/arm/mach-orion5x/ts209-setup.c| 3 ++-
arch/arm/mach-orion5x/ts409-setup.c| 3 ++-
arch/arm/mach-pxa/corgi.c | 3 ++-
arch/arm/mach-pxa/mioa701.c| 3 ++-
arch/arm/mach-pxa/poodle.c | 3 ++-
arch/arm/mach-pxa/spitz.c | 3 ++-
arch/arm/mach-pxa/tosa.c | 3 ++-
arch/arm/mach-pxa/viper.c | 3 ++-
arch/arm/mach-pxa/z2.c | 7 ---
arch/arm/mach-pxa/zeus.c | 7 ---
arch/arm/mach-s3c24xx/mach-gta02.c | 3 ++-
arch/arm/mach-s3c24xx/mach-jive.c | 3 ++-
arch/arm/mach-s3c24xx/mach-vr1000.c| 3 ++-
arch/arm/mach-s3c64xx/mach-smartq.c| 3 ++-
arch/arm/mach-sa1100/generic.c | 3 ++-
arch/arm/mach-sa1100/simpad.c | 3 ++-
arch/arm/mach-u300/regulator.c | 3 ++-
arch/arm/mach-vt8500/vt8500.c | 3 ++-
arch/arm/xen/enlighten.c | 3 ++-
43 files changed, 94 insertions(+), 49 deletions(-)
diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
index f73891b..4917c99 100644
--- a/arch/arm/kernel/psci.c
+++ b/arch/arm/kernel/psci.c
@@ -264,7 +264,8 @@ static int psci_0_2_init(struct device_node *np)
arm_pm_restart = psci_sys_reset;
- pm_power_off = psci_sys_poweroff;
+ register_power_off_handler_simple(psci_sys_poweroff,
+ POWEROFF_PRIORITY_DEFAULT);
out_put_node:
of_node_put(np);
diff --git a/arch/arm/mach-at91/board-gsia18s.c
b/arch/arm/mach-at91/board-gsia18s.c
index bf5cc55..cb5d1c3 100644
--- a/arch/arm/mach-at91/board-gsia18s.c
+++ b/arch/arm/mach-at91/board-gsia18s.c
@@ -521,7 +521,8 @@ static void gsia18s_power_off(void)
static int __init gsia18s_power_off_init(void)
{
- pm_power_off = gsia18s_power_off;
+ register_power_off_handler_simple(gsia18s_power_off,
+ POWEROFF_PRIORITY_DEFAULT);
return 0;
}
diff --git a/arch/arm/mach-bcm/board_bcm2835.c
b/arch/arm/mach-bcm/board_bcm2835.c
index 70f2f39..307ebc1 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -111,7 +111,8 @@ static void __init bcm2835_init(void)
bcm2835_setup_restart();
if (wdt_regs)
- pm_power_off = bcm2835_power_off;
+ register_power_off_handler_simple(bcm2835_power_off,
+ POWEROFF_PRIORITY_FALLBACK);
bcm2835_init_clocks();
diff --git a/arch/arm/mach-cns3xxx/cns3420vb.c
b/arch/arm/mach-cns3xxx/cns3420vb.c
index 6428bcc7..3f48979 100644
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -224,7 +224,8 @@ static void __init cns3420_init(void)
cns3xxx_ahci_init();
cns3xxx_sdhci_init();
- pm_power_off = cns3xxx_power_off;
+
[PATCH v2 27/47] power/reset: vexpress-poweroff: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Select default priority to reflect that the original code sets
pm_power_off unconditionally.
Signed-off-by: Guenter Roeck
---
v2: Use define to specify poweroff handler priority
drivers/power/reset/vexpress-poweroff.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/power/reset/vexpress-poweroff.c
b/drivers/power/reset/vexpress-poweroff.c
index 4dc102e2..1ea2f2e 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -12,6 +12,7 @@
*/
#include
+#include
#include
#include
#include
@@ -36,11 +37,19 @@ static void vexpress_reset_do(struct device *dev, const
char *what)
static struct device *vexpress_power_off_device;
-static void vexpress_power_off(void)
+static int vexpress_power_off(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
{
vexpress_reset_do(vexpress_power_off_device, "power off");
+
+ return NOTIFY_DONE;
}
+static struct notifier_block vexpress_poweroff_nb = {
+ .notifier_call = vexpress_power_off,
+ .priority = POWEROFF_PRIORITY_DEFAULT,
+};
+
static struct device *vexpress_restart_device;
static void vexpress_restart(enum reboot_mode reboot_mode, const char *cmd)
@@ -92,6 +101,7 @@ static int vexpress_reset_probe(struct platform_device *pdev)
const struct of_device_id *match =
of_match_device(vexpress_reset_of_match, >dev);
struct regmap *regmap;
+ int ret;
if (match)
func = (enum vexpress_reset_func)match->data;
@@ -106,7 +116,12 @@ static int vexpress_reset_probe(struct platform_device
*pdev)
switch (func) {
case FUNC_SHUTDOWN:
vexpress_power_off_device = >dev;
- pm_power_off = vexpress_power_off;
+ ret = register_power_off_handler(_poweroff_nb);
+ if (ret) {
+ dev_err(>dev,
+ "Failed to register poweroff handler\n");
+ return ret;
+ }
break;
case FUNC_RESET:
if (!vexpress_restart_device)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 25/47] power/reset: qnap-poweroff: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with default priority to reflect that the original
code generates an error if another poweroff handler has already been
registered when the driver is loaded.
Drop remove function since it is no longer needed.
Cc: Sebastian Reichel
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
Acked-by: Andrew Lunn
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use devm_register_power_off_handler
- Drop remove function since it is no longer needed
drivers/power/reset/qnap-poweroff.c | 32
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/power/reset/qnap-poweroff.c
b/drivers/power/reset/qnap-poweroff.c
index a75db7f..da3d58a 100644
--- a/drivers/power/reset/qnap-poweroff.c
+++ b/drivers/power/reset/qnap-poweroff.c
@@ -16,7 +16,9 @@
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -55,7 +57,8 @@ static void __iomem *base;
static unsigned long tclk;
static const struct power_off_cfg *cfg;
-static void qnap_power_off(void)
+static int qnap_power_off(struct notifier_block *this, unsigned long unused1,
+ void *unused2)
{
const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
@@ -72,14 +75,20 @@ static void qnap_power_off(void)
/* send the power-off command to PIC */
writel(cfg->cmd, UART1_REG(TX));
+
+ return NOTIFY_DONE;
}
+static struct notifier_block qnap_poweroff_nb = {
+ .notifier_call = qnap_power_off,
+ .priority = POWEROFF_PRIORITY_DEFAULT,
+};
+
static int qnap_power_off_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct resource *res;
struct clk *clk;
- char symname[KSYM_NAME_LEN];
const struct of_device_id *match =
of_match_node(qnap_power_off_of_match_table, np);
@@ -106,28 +115,11 @@ static int qnap_power_off_probe(struct platform_device
*pdev)
tclk = clk_get_rate(clk);
- /* Check that nothing else has already setup a handler */
- if (pm_power_off) {
- lookup_symbol_name((ulong)pm_power_off, symname);
- dev_err(>dev,
- "pm_power_off already claimed %p %s",
- pm_power_off, symname);
- return -EBUSY;
- }
- pm_power_off = qnap_power_off;
-
- return 0;
-}
-
-static int qnap_power_off_remove(struct platform_device *pdev)
-{
- pm_power_off = NULL;
- return 0;
+ return devm_register_power_off_handler(>dev, _poweroff_nb);
}
static struct platform_driver qnap_power_off_driver = {
.probe = qnap_power_off_probe,
- .remove = qnap_power_off_remove,
.driver = {
.owner = THIS_MODULE,
.name = "qnap_power_off",
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 21/47] ipmi: Register with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with high priority to reflect that the original code
overwrites pm_power_off unconditionally.
Register poweroff handler after the ipmi system is ready, and unregister
it prior to cleanup. This avoids having to check for the ready variable
in the poweroff callback.
Reviewed-by: Corey Minyard
Signed-off-by: Guenter Roeck
---
v2:
- Use define to specify poweroff handler priority
- Use pr_warn instead of pr_err
- Call unregister_power_off_handler on exit only if not already unregistered
drivers/char/ipmi/ipmi_poweroff.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_poweroff.c
b/drivers/char/ipmi/ipmi_poweroff.c
index 9f2e3be..41067da 100644
--- a/drivers/char/ipmi/ipmi_poweroff.c
+++ b/drivers/char/ipmi/ipmi_poweroff.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -63,9 +64,6 @@ static ipmi_user_t ipmi_user;
static int ipmi_ifnum;
static void (*specific_poweroff_func)(ipmi_user_t user);
-/* Holds the old poweroff function so we can restore it on removal. */
-static void (*old_poweroff_func)(void);
-
static int set_param_ifnum(const char *val, struct kernel_param *kp)
{
int rv = param_set_int(val, kp);
@@ -544,15 +542,20 @@ static struct poweroff_function poweroff_functions[] = {
/* Called on a powerdown request. */
-static void ipmi_poweroff_function(void)
+static int ipmi_poweroff_function(struct notifier_block *this,
+ unsigned long unused1, void *unused2)
{
- if (!ready)
- return;
-
/* Use run-to-completion mode, since interrupts may be off. */
specific_poweroff_func(ipmi_user);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block ipmi_poweroff_nb = {
+ .notifier_call = ipmi_poweroff_function,
+ .priority = POWEROFF_PRIORITY_HIGH,
+};
+
/* Wait for an IPMI interface to be installed, the first one installed
will be grabbed by this code and used to perform the powerdown. */
static void ipmi_po_new_smi(int if_num, struct device *device)
@@ -631,9 +634,12 @@ static void ipmi_po_new_smi(int if_num, struct device
*device)
printk(KERN_INFO PFX "Found a %s style poweroff function\n",
poweroff_functions[i].platform_type);
specific_poweroff_func = poweroff_functions[i].poweroff_func;
- old_poweroff_func = pm_power_off;
- pm_power_off = ipmi_poweroff_function;
+
ready = 1;
+
+ rv = register_power_off_handler(_poweroff_nb);
+ if (rv)
+ pr_warn(PFX "failed to register poweroff handler\n");
}
static void ipmi_po_smi_gone(int if_num)
@@ -644,9 +650,10 @@ static void ipmi_po_smi_gone(int if_num)
if (ipmi_ifnum != if_num)
return;
+ unregister_power_off_handler(_poweroff_nb);
+
ready = 0;
ipmi_destroy_user(ipmi_user);
- pm_power_off = old_poweroff_func;
}
static struct ipmi_smi_watcher smi_watcher = {
@@ -733,11 +740,11 @@ static void __exit ipmi_poweroff_cleanup(void)
ipmi_smi_watcher_unregister(_watcher);
if (ready) {
+ unregister_power_off_handler(_poweroff_nb);
rv = ipmi_destroy_user(ipmi_user);
if (rv)
printk(KERN_ERR PFX "could not cleanup the IPMI"
" user: 0x%x\n", rv);
- pm_power_off = old_poweroff_func;
}
}
module_exit(ipmi_poweroff_cleanup);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 19/47] mfd: rk808: Register poweroff handler with kernel poweroff handler
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with low priority to reflect that the original code
only sets pm_power_off if it was not already set.
Cc: Chris Zhong
Cc: Zhang Qing
Signed-off-by: Guenter Roeck
---
v2:
- New patch
drivers/mfd/rk808.c | 30 --
include/linux/mfd/rk808.h | 2 ++
2 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index bd02150..7f07279 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#include
struct rk808_reg_data {
@@ -147,23 +149,19 @@ static struct regmap_irq_chip rk808_irq_chip = {
.init_ack_masked = true,
};
-static struct i2c_client *rk808_i2c_client;
-static void rk808_device_shutdown(void)
+static int rk808_device_shutdown(struct notifier_block *this,
+unsigned long unused1, void *unused2)
{
+ struct rk808 *rk808 = container_of(this, struct rk808, poweroff_nb);
int ret;
- struct rk808 *rk808 = i2c_get_clientdata(rk808_i2c_client);
-
- if (!rk808) {
- dev_warn(_i2c_client->dev,
-"have no rk808, so do nothing here\n");
- return;
- }
ret = regmap_update_bits(rk808->regmap,
RK808_DEVCTRL_REG,
DEV_OFF_RST, DEV_OFF_RST);
if (ret)
- dev_err(_i2c_client->dev, "power off error!\n");
+ dev_err(>i2c->dev, "power off error!\n");
+
+ return NOTIFY_DONE;
}
static int rk808_probe(struct i2c_client *client,
@@ -222,9 +220,14 @@ static int rk808_probe(struct i2c_client *client,
pm_off = of_property_read_bool(np,
"rockchip,system-power-controller");
- if (pm_off && !pm_power_off) {
- rk808_i2c_client = client;
- pm_power_off = rk808_device_shutdown;
+ if (pm_off) {
+ rk808->poweroff_nb.notifier_call = rk808_device_shutdown;
+ rk808->poweroff_nb.priority = POWEROFF_PRIORITY_LOW;
+ ret = devm_register_power_off_handler(>dev,
+ >poweroff_nb);
+ if (ret)
+ dev_warn(>dev,
+"Failed to register poweroff handler\n");
}
return 0;
@@ -240,7 +243,6 @@ static int rk808_remove(struct i2c_client *client)
regmap_del_irq_chip(client->irq, rk808->irq_data);
mfd_remove_devices(>dev);
- pm_power_off = NULL;
return 0;
}
diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index fb09312..abc80cc 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -19,6 +19,7 @@
#ifndef __LINUX_REGULATOR_rk808_H
#define __LINUX_REGULATOR_rk808_H
+#include
#include
#include
@@ -192,5 +193,6 @@ struct rk808 {
struct i2c_client *i2c;
struct regmap_irq_chip_data *irq_data;
struct regmap *regmap;
+ struct notifier_block poweroff_nb;
};
#endif /* __LINUX_REGULATOR_rk808_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/47] hibernate: Call have_kernel_power_off instead of checking pm_power_off
Poweroff handlers may now be installed with register_power_off_handler. Use the new API function have_kernel_power_off to determine if a poweroff handler has been installed. Cc: Rafael J. Wysocki Cc: Pavel Machek Cc: Len Brown Acked-by: Rafael J. Wysocki Signed-off-by: Guenter Roeck --- v2: - have_kernel_poweroff -> have_kernel_power_off kernel/power/hibernate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c index a9dfa79..69225b7 100644 --- a/kernel/power/hibernate.c +++ b/kernel/power/hibernate.c @@ -602,7 +602,7 @@ static void power_down(void) case HIBERNATION_PLATFORM: hibernation_platform_enter(); case HIBERNATION_SHUTDOWN: - if (pm_power_off) + if (have_kernel_power_off()) kernel_power_off(); break; #ifdef CONFIG_SUSPEND -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/47] kernel: Add support for poweroff handler call chain
Various drivers implement architecture and/or device specific means to remove power from the system. For the most part, those drivers set the global variable pm_power_off to point to a function within the driver. This mechanism has a number of drawbacks. Typically only one means to remove power is supported (at least if pm_power_off is used). At least in theory there can be multiple means to remove power, some of which may be less desirable. For example, one mechanism might power off the entire system through an I/O port or gpio pin, while another might power off a board by disabling its power controller. Other mechanisms may really just execute a restart sequence or drop into the ROM monitor, or put the CPU into sleep mode. Using pm_power_off can also be racy if the function pointer is set from a driver built as module, as the driver may be in the process of being unloaded when pm_power_off is called. If there are multiple poweroff handlers in the system, removing a module with such a handler may inadvertently reset the pointer to pm_power_off to NULL, leaving the system with no means to remove power. Introduce a system poweroff handler call chain to solve the described problems. This call chain is expected to be executed from the architecture specific machine_power_off() function. Drivers providing system poweroff functionality are expected to register with this call chain. By using the priority field in the notifier block, callers can control poweroff handler execution sequence and thus ensure that the poweroff handler with the optimal capabilities to remove power for a given system is called first. Patch 01/47 implements the poweroff handler API. Patches 02/47 to 04/47 are cleanup patches to prepare for the move of pm_power_off to a common location. Patches 05/47 to 07/47 remove references to pm_power_off from devicetree bindings descriptions. Patch 08/47 moves the pm_power_off variable from architecture code to kernel/reboot.c. Patches 09/47 to 34/47 convert various drivers to register with the kernel poweroff handler instead of setting pm_power_off directly. Patches 35/47 to 46/47 do the same for architecture code. Patch 47/47 finally removes pm_power_off. For the most part, the individual patches include explanations why specific priorities were chosen, at least if the selected priority is not the default priority. Subsystem and architecture maintainers are encouraged to have a look at the selected priorities and suggest improvements. I ran the final code through my normal build and qemu tests. Results are available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler' column. I also built all available configurations for arm, mips, powerpc, m68k, and sh architectures. The series is available in branch poweroff-handler of my repository at git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git. It is based on 3.18-rc1. A note on Cc: In the initial submission I had way too many Cc:, causing the patchset to be treated as spam by many mailers and mailing list handlers, which of course defeated the purpose. This time around I am cutting down the distribution list down significantly. My apologies to anyone I may have failed to copy this time around. Important changes since v1: - Rebased series to v3.18-rc1. - Use raw notifier with spinlock protection instead of atomic notifiers, since some poweroff handlers need to have interrupts enabled. - Renamed API functions from _poweroff to _power_off. - Added various Acks. - Build tested all configurations for arm, powerpc, and mips architectures. - Fixed two compile errors in mips patch. - Replaced dev_err and pr_err with dev_warn and pr_warn if an error is not fatal. - Provide managed resources API and use where appropriate. - Provide and use definitions for standard priorities. - Added patches to convert newly introduced poweroff handlers. - Various minor changes. Important changes since RFC: - Move API to new file kernel/power/power_off_handler.c. - Move pm_power_off pointer to kernel/power/power_off_handler.c. Call pm_power_off from do_kernel_power_off, and only call do_kernel_power_off from architecture code instead of calling both pm_power_off and do_kernel_power_off. - Provide additional API function register_power_off_handler_simple to simplify conversion of architecture code. - Provide additional API function have_kernel_power_off to check if a poweroff handler was installed. - Convert all drivers and architecture code to use the new API. - Remove pm_power_off as last patch of the series. Cc: Alan Cox Cc: Alexander Graf Cc: Andrew Morton Cc: Geert Uytterhoeven cc: Heiko Stuebner Cc: Lee Jones Cc: Len Brown Cc: Pavel Machek Cc: Rafael J. Wysocki Cc: Romain Perier Guenter Roeck (47): kernel: Add support for poweroff handler call chain memory: emif: Use API function to determine poweroff capability
[PATCH v2 06/47] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings
pm_power_off is an implementation detail. Replace it with a more generic description of the driver's functionality. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Acked-by: Mark Rutland Acked-by: Andrew Lunn Signed-off-by: Guenter Roeck --- v2: No change Documentation/devicetree/bindings/gpio/gpio-poweroff.txt | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt index d4eab92..c95a1a6 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt @@ -2,12 +2,12 @@ Driver a GPIO line that can be used to turn the power off. The driver supports both level triggered and edge triggered power off. At driver load time, the driver will request the given gpio line and -install a pm_power_off handler. If the optional properties 'input' is -not found, the GPIO line will be driven in the inactive +install a handler to power off the system. If the optional properties +'input' is not found, the GPIO line will be driven in the inactive state. Otherwise its configured as an input. -When the pm_power_off is called, the gpio is configured as an output, -and drive active, so triggering a level triggered power off +When the the poweroff handler is called, the gpio is configured as an +output, and drive active, so triggering a level triggered power off condition. This will also cause an inactive->active edge condition, so triggering positive edge triggered power off. After a delay of 100ms, the GPIO is set to inactive, thus causing an active->inactive edge, @@ -24,7 +24,7 @@ Required properties: Optional properties: - input : Initially configure the GPIO line as an input. Only reconfigure - it to an output when the pm_power_off function is called. If this optional + it to an output when the poweroff handler is called. If this optional property is not specified, the GPIO is initialized as an output in its inactive state. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/5] CR4 handling improvements
On Tue, 14 Oct 2014, Andy Lutomirski wrote: > This little series tightens up rdpmc permissions. With it applied, > rdpmc can only be used if a perf_event is actually mmapped. For now, > this is only really useful for seccomp. So just to be difficult... I am aware of at least one group who is doing low-latency performance measures using rdpmc on Linux. They start the counters manually by poking the MSRs directly (bypassing perf_event_open()). They use rdpmc, grateful for the fact that currently CR4 is set up so they can do this w/o patching the kernel. These patches of course would break this use case... Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for do_adjtimex()
> -Original Message- > From: John Stultz [mailto:john.stu...@linaro.org] > Sent: Tuesday, October 21, 2014 11:24 AM > To: Thomas Shao > Cc: Thomas Gleixner; gre...@linuxfoundation.org; LKML; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; KY Srinivasan; Richard Cochran > Subject: Re: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for > do_adjtimex() > > On Mon, Oct 20, 2014 at 8:18 PM, Thomas Shao > wrote: > > > >> -Original Message- > >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > >> ow...@vger.kernel.org] On Behalf Of Thomas Gleixner > >> Sent: Tuesday, October 21, 2014 2:41 AM > >> To: Thomas Shao > >> Cc: gre...@linuxfoundation.org; LKML; de...@linuxdriverproject.org; > >> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; KY > >> Srinivasan; John Stultz; Richard Cochran > >> Subject: Re: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for > >> do_adjtimex() > >> > >> On Mon, 20 Oct 2014, Thomas Gleixner wrote: > >> > >> > On Wed, 15 Oct 2014, Thomas Shao wrote: > >> > > >> > And again you forgot to cc John Stultz on this > >> > > >> > > Export do_adjtimex function for hyper-v Time Synchronization > >> > > component > >> > >> Aside of that, we really want to see the use case for this and how > >> you addressed the problems which were pointed out by various folks. > >> > > > > In some situation, the user is not able to enable guest VM to sync > > with external time source, like NTP. But the host is still synced with a > trusted time source. > > In this case, host-guest time synchronization is useful. Hyper-v host > > will send time sample to guest VM every 5 seconds. We will use these > > time samples to adjust guest VM time. > > > > I've got some feedbacks from Richard and Mike, including reference NTP > > implementation and do the adjustment in the host side. I've already > > referenced some NTP design in my patch. I would consider my patch as a > > simplified implementation. I've also considered the host side > > implementation. But in host, we can only set time but not gradually > > slew/adjust time, which is not acceptable for the time sync > > solution.We still recommend user to configure NTP on the guest, which > provides better accuracy. But if NTP is not applicable, this could be another > option. > > > >> I still do not have a consistent argument from you WHY you need to > >> abuse > >> do_adjtimex() to do that host - guest synchronization in the first place. > >> > > > > I need a function to gradually slew guest time. do_adjtimex() provides > > all the functionality. Also I could not find any other exposed func to > > do this. I'd like to hear any feedback from you for this. > > Do you have any protections from both your kernel module trying to slew > time if the guest is also running NTPd? That seems like it could cause some > strange behavior. Thanks John. I didn't find a way to detect whether NTPd is running in the hyper-v module. In http://doc.ntp.org/4.1.0/ntpd.htm, it mentioned: Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. In my implementation, I use 100ms as the threshold (maybe I should change to 128?). If the time difference is less than 100ms, I just do nothing. So, if NTPd is running, ideally it could keep the time drift less than 128, so the adjustment in my patch will not get triggered. And moreover, by default, the guest-host time sync is turn off. There is a module parameter to control it. We'll also document customer that do not turn on this if NTP is configured. > > thanks > -john
Re: [PATCH] init: Remove CONFIG_INIT_FALLBACK
On Mon, Oct 20, 2014 at 8:45 PM, Rob Landley wrote:
> On 10/20/14 17:04, Andy Lutomirski wrote:
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -960,13 +960,8 @@ static int __ref kernel_init(void *unused)
>> ret = run_init_process(execute_command);
>> if (!ret)
>> return 0;
>> -#ifndef CONFIG_INIT_FALLBACK
>> panic("Requested init %s failed (error %d).",
>> execute_command, ret);
>> -#else
>> - pr_err("Failed to execute %s (error %d). Attempting
>> defaults...\n",
>> -execute_command, ret);
>> -#endif
>> }
>> if (!try_to_run_init_process("/sbin/init") ||
>> !try_to_run_init_process("/etc/init") ||
>>
>
> Would you like to remove the try_to_run_init_process() stack of random
> hardwired names that we can never reach if we panic, or do you just want
> to remove the error message?
>
I'm confused. That code is reachable if there's no initramfs and
init= is not specified.
--Andy
> Confused,
>
> Rob
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for do_adjtimex()
On Tue, Oct 21, 2014 at 03:18:58AM +, Thomas Shao wrote: > In some situation, the user is not able to enable guest VM to sync with > external > time source, like NTP. But the host is still synced with a trusted time > source. > In this case, host-guest time synchronization is useful. It's interesting to imagine that a virtualization host could present a time service to the guest *userspace*, even when the guest is not otherwise exposed to the internet at large. This could take the form of an NTP server on a private network, or as an implementation of a time source directly usable by ntpd in the guest, for instance as an emulated serial port with synthetic NEMA GPS signal + PPS signal, for instance. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tools: fix incorrect header string
On 2014/10/16 22:55, Arnaldo Carvalho de Melo wrote: > Em Thu, Oct 16, 2014 at 11:21:13AM +0800, Wang Nan escreveu: >> On 2014/10/15 23:13, Arnaldo Carvalho de Melo wrote: >>> Em Wed, Oct 15, 2014 at 11:28:53AM +0800, Wang Nan escreveu: Commit fbe96f29 (perf tools: Make perf.data more self-descriptive) read '/proc/cpuinfo' to form cpu descriptor. For ARM, it finds 'Processor' field. It is correct when the patch merged, but due to commit b4b8f770 (ARM: kernel: update cpuinfo to print all online CPUs features), the corresponding information becomes 'model name' field. This patch simply corrects it. >>> >>> It doesn't :-) >>> >>> It makes it work with kernels >= b4b8f770, and fail with older kernels. >>> >>> We need to somehow figure out where the right information is regardless >>> of the kernel. >>> >>> - Arnaldo >>> >> >> However it is a real problem. Look at output on arm platform at the >> bottom of this mail, especially "cpudesc", "total memory" and "cmdline" >> field. > > Yeah, I haven't said it wasn't a problem, just that the proposed fix > wasn't enough. > > - Arnaldo > >> By further debugging I found that the real problem resides in return value >> checking >> when write header error. Please see my other patches: >> >> https://lkml.org/lkml/2014/10/15/612 >> https://lkml.org/lkml/2014/10/15/611 So what's your opinion on these two patches? >> >> I think at least one of them is required. >> >> Thanks. >> Signed-off-by: Wang Nan --- tools/perf/perf-sys.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/perf-sys.h b/tools/perf/perf-sys.h index 937e432..4293970 100644 --- a/tools/perf/perf-sys.h +++ b/tools/perf/perf-sys.h @@ -113,7 +113,7 @@ #define mb() ((void(*)(void))0x0fa0)() #define wmb() ((void(*)(void))0x0fa0)() #define rmb() ((void(*)(void))0x0fa0)() -#define CPUINFO_PROC "Processor" +#define CPUINFO_PROC "model name" #endif #ifdef __aarch64__ -- 1.8.4 >> >> >> >> bash-4.2# perf record ls >> ... >> [ perf record: Woken up 1 times to write data ] >> [ perf record: Captured and wrote 0.001 MB perf.data (~36 samples) ] >> bash-4.2# perf report --stdio --header >> Error: >> The perf.data file has no samples! >> # >> # captured on: Fri Sep 12 10:09:10 2014 >> # hostname : arma15el >> # os release : 3.17.0+ >> # perf version : 3.10.53 >> # arch : armv7l >> # nrcpus online : 4 >> # nrcpus avail : 1 >> # cpudesc : (null) >> # total memory : 0 kB >> # cmdline : >> # event : name = cycles, type = 0, config = 0x0, config1 = 0x0, config2 = >> 0x0, excl_usr = 0, excl_kern = 0, excl_host = 0, excl_guest = 1, precise_ip >> = 0 >> # pmu mappings: not available >> # >> # >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: storage: Convert usb_stor_dbg to return void
No caller or macro uses the return value so make it void.
Signed-off-by: Joe Perches
---
This change is associated to a desire to eventually
change printk to return void.
drivers/usb/storage/debug.c | 7 ++-
drivers/usb/storage/debug.h | 10 ++
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/storage/debug.c b/drivers/usb/storage/debug.c
index e08f647..05bc379 100644
--- a/drivers/usb/storage/debug.c
+++ b/drivers/usb/storage/debug.c
@@ -179,17 +179,14 @@ void usb_stor_show_sense(const struct us_data *us,
US_DEBUGPX("\n");
}
-int usb_stor_dbg(const struct us_data *us, const char *fmt, ...)
+void usb_stor_dbg(const struct us_data *us, const char *fmt, ...)
{
va_list args;
- int r;
va_start(args, fmt);
- r = dev_vprintk_emit(7, >pusb_dev->dev, fmt, args);
+ dev_vprintk_emit(7, >pusb_dev->dev, fmt, args);
va_end(args);
-
- return r;
}
EXPORT_SYMBOL_GPL(usb_stor_dbg);
diff --git a/drivers/usb/storage/debug.h b/drivers/usb/storage/debug.h
index b1273f0..f525203 100644
--- a/drivers/usb/storage/debug.h
+++ b/drivers/usb/storage/debug.h
@@ -50,15 +50,17 @@
void usb_stor_show_command(const struct us_data *us, struct scsi_cmnd *srb);
void usb_stor_show_sense(const struct us_data *us, unsigned char key,
unsigned char asc, unsigned char ascq);
-__printf(2, 3) int usb_stor_dbg(const struct us_data *us,
- const char *fmt, ...);
+__printf(2, 3) void usb_stor_dbg(const struct us_data *us,
+const char *fmt, ...);
#define US_DEBUGPX(fmt, ...) printk(fmt, ##__VA_ARGS__)
#define US_DEBUG(x)x
#else
__printf(2, 3)
-static inline int _usb_stor_dbg(const struct us_data *us,
- const char *fmt, ...) {return 1;}
+static inline void _usb_stor_dbg(const struct us_data *us,
+const char *fmt, ...)
+{
+}
#define usb_stor_dbg(us, fmt, ...) \
do { if (0) _usb_stor_dbg(us, fmt, ##__VA_ARGS__); } while (0)
#define US_DEBUGPX(fmt, ...) \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] kprobes: introduce ARCH_HANDLES_KPROBES_ON_FTRACE
(2014/10/20 19:59), Heiko Carstens wrote:
> Allow architectures to implement handling of kprobes on function
> tracer call sites on their own, without depending on common code.
>
> This patch removes the kprobes check if a kprobe is being placed
> on a function tracer call site and therefore gives full responsibility
> of handling this correctly to the architecture.
>
> This patch also introduces a user space visible change: if a kprobe
> is placed into the middle of an ftrace instruction the return value
> is changed from -EINVAL to -EILSEQ also for architectures which do
> not support KPROBES_ON_FTRACE.
> However in reality this change shouldn't matter at all.
Could you try to remove new kconfig by using a weak function?
This could be done with below functions:
In kernel/kprobes.c:
int __weak arch_check_ftrace_location(struct kprobe *p)
{
unsigned long ftrace_addr = ftrace_location((unsigned long)p->addr);
if (ftrace_addr) {
...
}
And in arch/s390/kernel/kprobes.c:
int arch_check_ftrace_location(struct kprobe *p)
{
return 0;
}
And in include/linux/kprobes.h
int arch_check_ftrace_location(struct kprobe *p);
Then, we don't need to add any macros or kconfigs.
Thank you,
>
> Signed-off-by: Heiko Carstens
> ---
> arch/Kconfig | 8
> kernel/kprobes.c | 36 +---
> 2 files changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 05d7a8a458d5..e1a8e0edf03f 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -85,6 +85,14 @@ config KPROBES_ON_FTRACE
>passing of pt_regs to function tracing, then kprobes can
>optimize on top of function tracing.
>
> +config ARCH_HANDLES_KPROBES_ON_FTRACE
> + def_bool n
> + help
> + If an architecture can handle kprobes on function tracer call
> + sites on own, then this option should be selected. This option
> + removes the check which otherwise prevents to set kprobes on
> + function tracer call sites.
> +
> config UPROBES
> def_bool n
> select PERCPU_RWSEM
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 3995f546d0f3..4b57fe9fbeb7 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1410,28 +1410,34 @@ static inline int check_kprobe_rereg(struct kprobe *p)
> return ret;
> }
>
> -static int check_kprobe_address_safe(struct kprobe *p,
> - struct module **probed_mod)
> +static int check_ftrace_location(struct kprobe *p)
> {
> - int ret = 0;
> unsigned long ftrace_addr;
>
> - /*
> - * If the address is located on a ftrace nop, set the
> - * breakpoint to the following instruction.
> - */
> ftrace_addr = ftrace_location((unsigned long)p->addr);
> - if (ftrace_addr) {
> -#ifdef CONFIG_KPROBES_ON_FTRACE
> - /* Given address is not on the instruction boundary */
> - if ((unsigned long)p->addr != ftrace_addr)
> - return -EILSEQ;
> + if (!ftrace_addr)
> + return 0;
> + /* Given address is not on the instruction boundary */
> + if ((unsigned long)p->addr != ftrace_addr)
> + return -EILSEQ;
> + /* If an architecture handles kprobes on ftrace, we're done */
> + if (IS_ENABLED(CONFIG_ARCH_HANDLES_KPROBES_ON_FTRACE))
> + return 0;
> + if (IS_ENABLED(CONFIG_KPROBES_ON_FTRACE)) {
> p->flags |= KPROBE_FLAG_FTRACE;
> -#else/* !CONFIG_KPROBES_ON_FTRACE */
> - return -EINVAL;
> -#endif
> + return 0;
> }
> + return -EINVAL;
> +}
> +
> +static int check_kprobe_address_safe(struct kprobe *p,
> + struct module **probed_mod)
> +{
> + int ret;
>
> + ret = check_ftrace_location(p);
> + if (ret)
> + return ret;
> jump_label_lock();
> preempt_disable();
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi/atmel: improve the system suspend/resume functions implementation
To make it cleaner, the system suspend/resume directly call
the runtime suspend/resume functions
and remove the wapper of CONFIG_PM_RUNTIME, CONFIG_PM_SLEEP.
Signed-off-by: Wenyou Yang
---
drivers/spi/spi-atmel.c | 61 ---
1 file changed, 26 insertions(+), 35 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 3f50014..6ed1893 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1451,11 +1451,30 @@ static int atmel_spi_remove(struct platform_device
*pdev)
}
#ifdef CONFIG_PM
-#ifdef CONFIG_PM_SLEEP
+static int atmel_spi_runtime_suspend(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct atmel_spi *as = spi_master_get_devdata(master);
+
+ clk_disable_unprepare(as->clk);
+ pinctrl_pm_select_sleep_state(dev);
+
+ return 0;
+}
+
+static int atmel_spi_runtime_resume(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct atmel_spi *as = spi_master_get_devdata(master);
+
+ pinctrl_pm_select_default_state(dev);
+
+ return clk_prepare_enable(as->clk);
+}
+
static int atmel_spi_suspend(struct device *dev)
{
- struct spi_master *master = dev_get_drvdata(dev);
- struct atmel_spi*as = spi_master_get_devdata(master);
+ struct spi_master *master = dev_get_drvdata(dev);
int ret;
/* Stop the queue running */
@@ -1465,23 +1484,19 @@ static int atmel_spi_suspend(struct device *dev)
return ret;
}
- if (!pm_runtime_suspended(dev)) {
- clk_disable_unprepare(as->clk);
- pinctrl_pm_select_sleep_state(dev);
- }
+ if (!pm_runtime_suspended(dev))
+ atmel_spi_runtime_suspend(dev);
return 0;
}
static int atmel_spi_resume(struct device *dev)
{
- struct spi_master *master = dev_get_drvdata(dev);
- struct atmel_spi*as = spi_master_get_devdata(master);
+ struct spi_master *master = dev_get_drvdata(dev);
int ret;
if (!pm_runtime_suspended(dev)) {
- pinctrl_pm_select_default_state(dev);
- ret = clk_prepare_enable(as->clk);
+ ret = atmel_spi_runtime_resume(dev);
if (ret)
return ret;
}
@@ -1493,30 +1508,6 @@ static int atmel_spi_resume(struct device *dev)
return ret;
}
-#endif
-
-#ifdef CONFIG_PM_RUNTIME
-static int atmel_spi_runtime_suspend(struct device *dev)
-{
- struct spi_master *master = dev_get_drvdata(dev);
- struct atmel_spi *as = spi_master_get_devdata(master);
-
- clk_disable_unprepare(as->clk);
- pinctrl_pm_select_sleep_state(dev);
-
- return 0;
-}
-
-static int atmel_spi_runtime_resume(struct device *dev)
-{
- struct spi_master *master = dev_get_drvdata(dev);
- struct atmel_spi *as = spi_master_get_devdata(master);
-
- pinctrl_pm_select_default_state(dev);
-
- return clk_prepare_enable(as->clk);
-}
-#endif
static const struct dev_pm_ops atmel_spi_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(atmel_spi_suspend, atmel_spi_resume)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/6] ARM: dts: add RK3288 suspend support
From: Chris Zhong
add pmu_intmem node for suspend, add global_pwroff pinctrl.
The pmu_intmem is used to store the resume code.
global_pwroff is held low level at work, it would be pull to high
when entering suspend. PMICs can get this singal, then shut down
some power rails. So please reference the global_pwroff pinctrl
as part of the PMIC config.
Signed-off-by: Tony Xie
Signed-off-by: Chris Zhong
---
Changes in v3: None
Changes in v2:
- put "rockchip,rk3288-pmu-sram" to first
arch/arm/boot/dts/rk3288.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..fcbe929 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -241,6 +241,11 @@
status = "disabled";
};
+ pmu_intmem@ff72 {
+ compatible = "rockchip,rk3288-pmu-sram", "mmio-sram";
+ reg = <0xff72 0x4000>;
+ };
+
pmu: power-management@ff73 {
compatible = "rockchip,rk3288-pmu", "syscon";
reg = <0xff73 0x100>;
@@ -421,6 +426,12 @@
bias-disable;
};
+ sleep {
+ global_pwroff: global-pwroff {
+ rockchip,pins = <0 0 RK_FUNC_1 _pull_none>;
+ };
+ };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <0 15 RK_FUNC_1
_pull_none>,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] init: Remove CONFIG_INIT_FALLBACK
On 10/20/14 17:04, Andy Lutomirski wrote:
> --- a/init/main.c
> +++ b/init/main.c
> @@ -960,13 +960,8 @@ static int __ref kernel_init(void *unused)
> ret = run_init_process(execute_command);
> if (!ret)
> return 0;
> -#ifndef CONFIG_INIT_FALLBACK
> panic("Requested init %s failed (error %d).",
> execute_command, ret);
> -#else
> - pr_err("Failed to execute %s (error %d). Attempting
> defaults...\n",
> -execute_command, ret);
> -#endif
> }
> if (!try_to_run_init_process("/sbin/init") ||
> !try_to_run_init_process("/etc/init") ||
>
Would you like to remove the try_to_run_init_process() stack of random
hardwired names that we can never reach if we panic, or do you just want
to remove the error message?
Confused,
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
