Re: Please pull 'merge' branch of 5xxx tree
Hi Ben, On Thu, 25 Oct 2012 22:41:13 +0200 Anatolij Gustschin ag...@denx.de wrote: Hi Ben, please pull three mpc5200 fixes for 3.7: Ping. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/85xx: p1022ds: Use NULL instead of 0 for pointers
The third argument for of_get_property() is a pointer, hence pass
NULL instead of 0.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/powerpc/platforms/85xx/p1022_ds.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 8fb1257..7328b8d 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -249,7 +249,7 @@ static void p1022ds_set_monitor_port(enum
fsl_diu_monitor_port port)
goto exit;
}
- iprop = of_get_property(law_node, fsl,num-laws, 0);
+ iprop = of_get_property(law_node, fsl,num-laws, NULL);
if (!iprop) {
pr_err(p1022ds: LAW node is missing fsl,num-laws property\n);
goto exit;
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/pseries: pci: Use NULL instead of 0 for pointers
The third argument for of_get_property() is a pointer, hence pass
NULL instead of 0.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
This code is in a '#if 0' section, but I went ahead with the patch as
this is the only location in kernel where of_get_property is passed 0
as the third argument. If this function is not going to be used again,
then we may consider removing the code altogether.
arch/powerpc/platforms/pseries/pci.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pci.c
b/arch/powerpc/platforms/pseries/pci.c
index 56b864d..0b580f4 100644
--- a/arch/powerpc/platforms/pseries/pci.c
+++ b/arch/powerpc/platforms/pseries/pci.c
@@ -40,7 +40,8 @@ void pcibios_name_device(struct pci_dev *dev)
*/
dn = pci_device_to_OF_node(dev);
if (dn) {
- const char *loc_code = of_get_property(dn, ibm,loc-code, 0);
+ const char *loc_code = of_get_property(dn, ibm,loc-code,
+ NULL);
if (loc_code) {
int loc_len = strlen(loc_code);
if (loc_len sizeof(dev-dev.name)) {
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
On 11/20/2012 02:55 PM, Wen Congyang wrote:
At 11/20/2012 02:22 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
In order to review this patch, I should dig sparse memory codes in
advance. But I have some confuse of codes. Why need encode/decode mem
map instead of set mem_map to ms-section_mem_map directly?
The memmap is aligned, and the low bits are zero. We store some information
in these bits. So we need to encode/decode memmap here.
Hi Congyang,
Thanks for you reponse. But I mean why return (unsigned long)(mem_map -
(section_nr_to_pfn(pnum))); in function sparse_encode_mem_map, and then
return ((struct page *)coded_mem_map) + section_nr_to_pfn(pnum); in
funtion sparse_decode_mem_map instead of just store mem_map in
ms-section_mep_map directly.
Regards,
Jaegeuk
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section *ms)
{
-/*
- * XXX: Freeing memmap with vmemmap is not implement yet.
- * This should be removed later.
- */
-return -EBUSY;
+int ret = -EINVAL;
+
+if (!valid_section(ms))
+return ret;
+
+ret = unregister_memory_section(ms);
+
+return ret;
}
#else
static int __remove_section(struct zone *zone, struct mem_section *ms)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 065/493] i2c: remove use of __devexit_p
On Mon, Nov 19, 2012 at 11:50 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Reviewed-by: Shubhrajyoti D shubhrajy...@ti.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 207/493] i2c: remove use of __devinit
Hi Bill, On Mon, 19 Nov 2012 13:22:36 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Can you please point me/us to the discussion explaining the rationale behind this move, and the explanation of what will be done exactly? While I can easily understand that we want to drop CONFIG_HOTPLUG and always enable hot-plug support, I don't see where we are going with removing __devinit annotations and the like. Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 11/12] memory-hotplug: remove sysfs file of node
At 11/19/2012 06:08 PM, Yasuaki Ishimatsu Wrote:
Hi Wen,
This patch cannot be applied, if I apply latest acpi framework's patch-set:
https://lkml.org/lkml/2012/11/15/21
Because acpi_memory_disable_device() is gone by the patch-set.
The patchset is not for pm tree, so I don't apply the patchset in pm tree
before generating this patchset.
Thanks
Wen Congyang
I updated the patch and attached it on the mail.
2012/11/01 18:44, Wen Congyang wrote:
This patch introduces a new function try_offline_node() to
remove sysfs file of node when all memory sections of this
node are removed. If some memory sections of this node are
not removed, this function does nothing.
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
drivers/acpi/acpi_memhotplug.c | 8 +-
include/linux/memory_hotplug.h | 2 +-
mm/memory_hotplug.c| 58
--
3 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 24c807f..0780f99 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -310,7 +310,9 @@ static int acpi_memory_disable_device(struct
acpi_memory_device *mem_device)
{
int result;
struct acpi_memory_info *info, *n;
+int node;
+node = acpi_get_node(mem_device-device-handle);
/*
* Ask the VM to offline this memory range.
@@ -318,7 +320,11 @@ static int acpi_memory_disable_device(struct
acpi_memory_device *mem_device)
*/
list_for_each_entry_safe(info, n, mem_device-res_list, list) {
if (info-enabled) {
-result = remove_memory(info-start_addr, info-length);
+if (node 0)
+node = memory_add_physaddr_to_nid(
+info-start_addr);
+result = remove_memory(node, info-start_addr,
+info-length);
if (result)
return result;
}
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index d4c4402..7b4cfe6 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -231,7 +231,7 @@ extern int arch_add_memory(int nid, u64 start, u64 size);
extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
extern int offline_memory_block(struct memory_block *mem);
extern bool is_memblock_offlined(struct memory_block *mem);
-extern int remove_memory(u64 start, u64 size);
+extern int remove_memory(int node, u64 start, u64 size);
extern int sparse_add_one_section(struct zone *zone, unsigned long
start_pfn,
int nr_pages);
extern void sparse_remove_one_section(struct zone *zone, struct
mem_section *ms);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 7bcced0..d965da3 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -29,6 +29,7 @@
#include linux/suspend.h
#include linux/mm_inline.h
#include linux/firmware-map.h
+#include linux/stop_machine.h
#include asm/tlbflush.h
@@ -1299,7 +1300,58 @@ static int is_memblock_offlined_cb(struct
memory_block *mem, void *arg)
return ret;
}
-int __ref remove_memory(u64 start, u64 size)
+static int check_cpu_on_node(void *data)
+{
+struct pglist_data *pgdat = data;
+int cpu;
+
+for_each_present_cpu(cpu) {
+if (cpu_to_node(cpu) == pgdat-node_id)
+/*
+ * the cpu on this node isn't removed, and we can't
+ * offline this node.
+ */
+return -EBUSY;
+}
+
+return 0;
+}
+
+/* offline the node if all memory sections of this node are removed */
+static void try_offline_node(int nid)
+{
+unsigned long start_pfn = NODE_DATA(nid)-node_start_pfn;
+unsigned long end_pfn = start_pfn + NODE_DATA(nid)-node_spanned_pages;
+unsigned long pfn;
+
+for (pfn = start_pfn; pfn end_pfn; pfn += PAGES_PER_SECTION) {
+unsigned long section_nr = pfn_to_section_nr(pfn);
+
+if (!present_section_nr(section_nr))
+continue;
+
+if (pfn_to_nid(pfn) != nid)
+continue;
+
+/*
+ * some memory sections of this node are not removed, and we
+ * can't offline node now.
+ */
+return;
+}
+
+if (stop_machine(check_cpu_on_node,
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
At 11/20/2012 02:58 PM, Jaegeuk Hanse Wrote:
On 11/20/2012 02:55 PM, Wen Congyang wrote:
At 11/20/2012 02:22 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
In order to review this patch, I should dig sparse memory codes in
advance. But I have some confuse of codes. Why need encode/decode mem
map instead of set mem_map to ms-section_mem_map directly?
The memmap is aligned, and the low bits are zero. We store some
information
in these bits. So we need to encode/decode memmap here.
Hi Congyang,
Thanks for you reponse. But I mean why return (unsigned long)(mem_map -
(section_nr_to_pfn(pnum))); in function sparse_encode_mem_map, and then
return ((struct page *)coded_mem_map) + section_nr_to_pfn(pnum); in
funtion sparse_decode_mem_map instead of just store mem_map in
ms-section_mep_map directly.
I don't know why. I try to find the reason, but I don't find any
place to use the pfn stored in the mem_map except in the decode
function. Maybe the designer doesn't want us to access the mem_map
directly.
Thanks
Wen Congyang
Regards,
Jaegeuk
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section
*ms)
{
-/*
- * XXX: Freeing memmap with vmemmap is not implement yet.
- * This should be removed later.
- */
-return -EBUSY;
+int ret = -EINVAL;
+
+if (!valid_section(ms))
+return ret;
+
+ret = unregister_memory_section(ms);
+
+return ret;
}
#else
static int __remove_section(struct zone *zone, struct mem_section
*ms)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 119/493] usb: remove use of __devexit_p
On 11/19/2012 07:21 PM, Bill Pemberton :
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Alexander Shishkin alexander.shish...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
Cc: Li Yang le...@freescale.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Wan ZongShun mcuos@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
[..]
drivers/usb/host/ehci-atmel.c| 2 +-
drivers/usb/host/ohci-at91.c | 2 +-
For Atmel:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
[..]
diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x00/c67x00-drv.c
index 6f3b6e2..855d538 100644
--- a/drivers/usb/c67x00/c67x00-drv.c
+++ b/drivers/usb/c67x00/c67x00-drv.c
@@ -219,7 +219,7 @@ static int __devexit c67x00_drv_remove(struct
platform_device *pdev)
static struct platform_driver c67x00_driver = {
.probe = c67x00_drv_probe,
- .remove = __devexit_p(c67x00_drv_remove),
+ .remove = c67x00_drv_remove,
.driver = {
.owner = THIS_MODULE,
.name = c67x00,
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 0f5ca4b..5659730 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -252,7 +252,7 @@ MODULE_DEVICE_TABLE(of, ci13xxx_imx_dt_ids);
static struct platform_driver ci13xxx_imx_driver = {
.probe = ci13xxx_imx_probe,
- .remove = __devexit_p(ci13xxx_imx_remove),
+ .remove = ci13xxx_imx_remove,
.driver = {
.name = imx_usb,
.owner = THIS_MODULE,
diff --git a/drivers/usb/chipidea/ci13xxx_msm.c
b/drivers/usb/chipidea/ci13xxx_msm.c
index b01feb3..406c5af 100644
--- a/drivers/usb/chipidea/ci13xxx_msm.c
+++ b/drivers/usb/chipidea/ci13xxx_msm.c
@@ -89,7 +89,7 @@ static int __devexit ci13xxx_msm_remove(struct
platform_device *pdev)
static struct platform_driver ci13xxx_msm_driver = {
.probe = ci13xxx_msm_probe,
- .remove = __devexit_p(ci13xxx_msm_remove),
+ .remove = ci13xxx_msm_remove,
.driver = { .name = msm_hsusb, },
};
diff --git a/drivers/usb/chipidea/ci13xxx_pci.c
b/drivers/usb/chipidea/ci13xxx_pci.c
index 918e149..e1cb2fb 100644
--- a/drivers/usb/chipidea/ci13xxx_pci.c
+++ b/drivers/usb/chipidea/ci13xxx_pci.c
@@ -147,7 +147,7 @@ static struct pci_driver ci13xxx_pci_driver = {
.name = UDC_DRIVER_NAME,
.id_table = ci13xxx_pci_id_table,
.probe= ci13xxx_pci_probe,
- .remove = __devexit_p(ci13xxx_pci_remove),
+ .remove = ci13xxx_pci_remove,
};
module_pci_driver(ci13xxx_pci_driver);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index f69d029..46f23f2 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -523,7 +523,7 @@ static int __devexit ci_hdrc_remove(struct
platform_device *pdev)
static struct platform_driver ci_hdrc_driver = {
.probe = ci_hdrc_probe,
- .remove = __devexit_p(ci_hdrc_remove),
+ .remove = ci_hdrc_remove,
.driver = {
.name = ci_hdrc,
},
diff --git a/drivers/usb/chipidea/usbmisc_imx6q.c
b/drivers/usb/chipidea/usbmisc_imx6q.c
index 416e3fc..81238a4 100644
--- a/drivers/usb/chipidea/usbmisc_imx6q.c
+++ b/drivers/usb/chipidea/usbmisc_imx6q.c
@@ -136,7 +136,7 @@ static int __devexit usbmisc_imx6q_remove(struct
platform_device *pdev)
static struct platform_driver usbmisc_imx6q_driver = {
.probe = usbmisc_imx6q_probe,
- .remove = __devexit_p(usbmisc_imx6q_remove),
+ .remove = usbmisc_imx6q_remove,
.driver = {
.name = usbmisc_imx6q,
.owner = THIS_MODULE,
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index e71a62a..1a02442 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -583,7 +583,7 @@ static int __devexit dwc3_remove(struct platform_device
*pdev)
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
- .remove = __devexit_p(dwc3_remove),
+ .remove = dwc3_remove,
.driver = {
.name = dwc3,
},
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index dc35c54..19a9818 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -196,7 +196,7 @@ MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
static struct platform_driver dwc3_exynos_driver = {
.probe = dwc3_exynos_probe,
- .remove = __devexit_p(dwc3_exynos_remove),
+ .remove =
Re: [PATCH 161/493] tty: remove use of __devinit
On 11/19/2012 07:21 PM, Bill Pemberton :
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Jiri Slaby jirisl...@gmail.com
Cc: Alan Cox a...@linux.intel.com
Cc: Tobias Klauser tklau...@distanz.ch
Cc: Lucas Tavares luca...@linux.vnet.ibm.com
Cc: David S. Miller da...@davemloft.net
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Tony Prisk li...@prisktech.co.nz
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ser...@vger.kernel.org
Cc: nios2-...@sopc.et.ntust.edu.tw
Cc: linux-i...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
drivers/tty/serial/atmel_serial.c | 6 +++---
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index 0244acf..444b544 100644
--- a/drivers/tty/cyclades.c
+++ b/drivers/tty/cyclades.c
@@ -3099,7 +3099,7 @@ static const struct tty_port_operations cyz_port_ops = {
* -
*/
-static int __devinit cy_init_card(struct cyclades_card *cinfo)
+static int cy_init_card(struct cyclades_card *cinfo)
{
struct cyclades_port *info;
unsigned int channel, port;
@@ -3196,7 +3196,7 @@ static int __devinit cy_init_card(struct cyclades_card
*cinfo)
/* initialize chips on Cyclom-Y card -- return number of valid
chips (which is number of ports/4) */
-static unsigned short __devinit cyy_init_card(void __iomem *true_base_addr,
+static unsigned short cyy_init_card(void __iomem *true_base_addr,
int index)
{
unsigned int chip_number;
@@ -3405,7 +3405,7 @@ static int __init cy_detect_isa(void)
}/* cy_detect_isa */
#ifdef CONFIG_PCI
-static inline int __devinit cyc_isfwstr(const char *str, unsigned int size)
+static inline int cyc_isfwstr(const char *str, unsigned int size)
{
unsigned int a;
@@ -3420,7 +3420,7 @@ static inline int __devinit cyc_isfwstr(const char
*str, unsigned int size)
return 0;
}
-static inline void __devinit cyz_fpga_copy(void __iomem *fpga, const u8
*data,
+static inline void cyz_fpga_copy(void __iomem *fpga, const u8 *data,
unsigned int size)
{
for (; size 0; size--) {
@@ -3429,7 +3429,7 @@ static inline void __devinit cyz_fpga_copy(void __iomem
*fpga, const u8 *data,
}
}
-static void __devinit plx_init(struct pci_dev *pdev, int irq,
+static void plx_init(struct pci_dev *pdev, int irq,
struct RUNTIME_9060 __iomem *addr)
{
/* Reset PLX */
@@ -3449,7 +3449,7 @@ static void __devinit plx_init(struct pci_dev *pdev,
int irq,
pci_write_config_byte(pdev, PCI_INTERRUPT_LINE, irq);
}
-static int __devinit __cyz_load_fw(const struct firmware *fw,
+static int __cyz_load_fw(const struct firmware *fw,
const char *name, const u32 mailbox, void __iomem *base,
void __iomem *fpga)
{
@@ -3526,7 +3526,7 @@ static int __devinit __cyz_load_fw(const struct
firmware *fw,
return 0;
}
-static int __devinit cyz_load_fw(struct pci_dev *pdev, void __iomem
*base_addr,
+static int cyz_load_fw(struct pci_dev *pdev, void __iomem *base_addr,
struct RUNTIME_9060 __iomem *ctl_addr, int irq)
{
const struct firmware *fw;
@@ -3692,7 +3692,7 @@ err:
return retval;
}
-static int __devinit cy_pci_probe(struct pci_dev *pdev,
+static int cy_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct cyclades_card *card;
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index 4ab936b..65d4320 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -699,7 +699,7 @@ static const struct tty_port_operations
ehv_bc_tty_port_ops = {
.shutdown = ehv_bc_tty_port_shutdown,
};
-static int __devinit ehv_bc_tty_probe(struct platform_device *pdev)
+static int ehv_bc_tty_probe(struct platform_device *pdev)
{
struct device_node *np = pdev-dev.of_node;
struct ehv_bc_data *bc;
diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index f39337f..5ddd6f5 100644
--- a/drivers/tty/hvc/hvc_opal.c
+++ b/drivers/tty/hvc/hvc_opal.c
@@ -161,7 +161,7 @@ static const struct hv_ops hvc_opal_hvsi_ops = {
.tiocmset = hvc_opal_hvsi_tiocmset,
};
-static int __devinit hvc_opal_probe(struct platform_device *dev)
+static int hvc_opal_probe(struct platform_device *dev)
{
const struct hv_ops *ops;
struct hvc_struct *hp;
diff --git a/drivers/tty/hvc/hvc_vio.c b/drivers/tty/hvc/hvc_vio.c
index 1a5894c..f7333e3 100644
--- a/drivers/tty/hvc/hvc_vio.c
+++ b/drivers/tty/hvc/hvc_vio.c
@@ -293,7 +293,7 @@ static int udbg_hvc_getc(void)
}
}
-static int __devinit hvc_vio_probe(struct vio_dev *vdev,
+static int
Re: [PATCH 161/493] tty: remove use of __devinit
On 2012-11-19 at 19:21:50 +0100, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Jiri Slaby jirisl...@gmail.com Cc: Alan Cox a...@linux.intel.com Cc: Tobias Klauser tklau...@distanz.ch Cc: Lucas Tavares luca...@linux.vnet.ibm.com Cc: David S. Miller da...@davemloft.net Cc: Peter Korsgaard jac...@sunsite.dk Cc: Tony Prisk li...@prisktech.co.nz Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ser...@vger.kernel.org Cc: nios2-...@sopc.et.ntust.edu.tw Cc: linux-i...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- [...] drivers/tty/serial/altera_jtaguart.c| 2 +- drivers/tty/serial/altera_uart.c| 2 +- Acked-by: Tobias Klauser tklau...@distanz.ch ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 429/493] tty: remove use of __devexit
On 2012-11-19 at 19:26:18 +0100, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Jiri Slaby jirisl...@gmail.com Cc: Alan Cox a...@linux.intel.com Cc: Tobias Klauser tklau...@distanz.ch Cc: Lucas Tavares luca...@linux.vnet.ibm.com Cc: David Brown dav...@codeaurora.org Cc: Daniel Walker dwal...@fifo99.com Cc: Bryan Huntsman bry...@codeaurora.org Cc: David S. Miller da...@davemloft.net Cc: Peter Korsgaard jac...@sunsite.dk Cc: Tony Prisk li...@prisktech.co.nz Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ser...@vger.kernel.org Cc: nios2-...@sopc.et.ntust.edu.tw Cc: uclinux-dist-de...@blackfin.uclinux.org Cc: linux-arm-...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- [...] drivers/tty/serial/altera_jtaguart.c| 2 +- drivers/tty/serial/altera_uart.c| 2 +- Acked-by: Tobias Klauser tklau...@distanz.ch ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] perf/powerpc: Use uapi/unistd.h to fix build error
On 11/08/2012 12:48 AM, Sukadev Bhattiprolu wrote: From b8beef080260c1625c8f801105504a82005295e5 Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com Date: Wed, 31 Oct 2012 11:21:28 -0700 Subject: [PATCH 1/4] perf/powerpc: Use uapi/unistd.h to fix build error Use the 'unistd.h' from arch/powerpc/include/uapi to build the perf tool. Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com Without this patch, I couldn't build perf on powerpc, with 3.7.0-rc2 Tested-by: Suzuki K. Poulose suz...@in.ibm.com Thanks Suzuki --- tools/perf/perf.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/perf/perf.h b/tools/perf/perf.h index 054182e..f4952da 100644 --- a/tools/perf/perf.h +++ b/tools/perf/perf.h @@ -26,7 +26,7 @@ void get_term_dimensions(struct winsize *ws); #endif #ifdef __powerpc__ -#include ../../arch/powerpc/include/asm/unistd.h +#include ../../arch/powerpc/include/uapi/asm/unistd.h #define rmb() asm volatile (sync ::: memory) #define cpu_relax() asm volatile ( ::: memory); #define CPUINFO_PROC cpu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
On 11/20/2012 05:37 PM, Wen Congyang wrote:
At 11/20/2012 02:58 PM, Jaegeuk Hanse Wrote:
On 11/20/2012 02:55 PM, Wen Congyang wrote:
At 11/20/2012 02:22 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
In order to review this patch, I should dig sparse memory codes in
advance. But I have some confuse of codes. Why need encode/decode mem
map instead of set mem_map to ms-section_mem_map directly?
The memmap is aligned, and the low bits are zero. We store some
information
in these bits. So we need to encode/decode memmap here.
Hi Congyang,
Thanks for you reponse. But I mean why return (unsigned long)(mem_map -
(section_nr_to_pfn(pnum))); in function sparse_encode_mem_map, and then
return ((struct page *)coded_mem_map) + section_nr_to_pfn(pnum); in
funtion sparse_decode_mem_map instead of just store mem_map in
ms-section_mep_map directly.
I don't know why. I try to find the reason, but I don't find any
place to use the pfn stored in the mem_map except in the decode
function. Maybe the designer doesn't want us to access the mem_map
directly.
It seems that mem_map is per node, but pfn is real pfn.
you can check __page_to_pfn.
Thanks
Wen Congyang
Regards,
Jaegeuk
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section
*ms)
{
-/*
- * XXX: Freeing memmap with vmemmap is not implement yet.
- * This should be removed later.
- */
-return -EBUSY;
+int ret = -EINVAL;
+
+if (!valid_section(ms))
+return ret;
+
+ret = unregister_memory_section(ms);
+
+return ret;
}
#else
static int __remove_section(struct zone *zone, struct mem_section
*ms)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I have a question about these sparse vmemmap memory related patches. Hot
add memory need allocated vmemmap pages, but this time is allocated by
buddy system. How can gurantee virtual address is continuous to the
address allocated before? If not continuous, page_to_pfn and pfn_to_page
can't work correctly.
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid, struct zone
*zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section *ms)
{
- /*
-* XXX: Freeing memmap with vmemmap is not implement yet.
-* This should be removed later.
-*/
- return -EBUSY;
+ int ret = -EINVAL;
+
+ if (!valid_section(ms))
+ return ret;
+
+ ret = unregister_memory_section(ms);
+
+ return ret;
}
#else
static int __remove_section(struct zone *zone, struct mem_section *ms)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
On Tue, 2012-11-20 at 18:20 +1100, Benjamin Herrenschmidt wrote: On Fri, 2010-07-23 at 14:56 +0100, Ben Hutchings wrote: commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 PCI: MSI: Remove unsafe and unnecessary hardware access changed read_msi_msg_desc() to return the last MSI message written instead of reading it from the device, since it may be called while the device is in a reduced power state. Looks reasonable... Jesse ? [...] So reasonable that it was committed a couple of years ago! Where did you dredge this from? Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 207/493] i2c: remove use of __devinit
On Tue, 20 Nov 2012 13:23:42 +, Russell King - ARM Linux wrote: On Tue, Nov 20, 2012 at 09:20:46AM +0100, Jean Delvare wrote: Hi Bill, On Mon, 19 Nov 2012 13:22:36 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Can you please point me/us to the discussion explaining the rationale behind this move, and the explanation of what will be done exactly? While I can easily understand that we want to drop CONFIG_HOTPLUG and always enable hot-plug support, I don't see where we are going with removing __devinit annotations and the like. It's actually very simple to understand. 1. CONFIG_HOTPLUG is going away; it's already defined to always be 'Y'. 2. This means that the the devinit sections will not be discarded anymore. 3. As a result, there's no point the devinit sections existing anymore. 4. As there's no devinit sections, the __devinit marker is entirely redundant and useless. Ah, yes, very simple indeed. Not sure how I managed to not understand it earlier today. Thanks for explaining. The reason this is being done is because the benefit to cost ratio of this is far too high; it's well proven that people constantly get these markings wrong, and with most kernels having had hotplug enabled anyway, it's not providing much in the way of space saving benefit over the number of section conflicts it causes. So, it's been decided a few years ago that this is Yes, I completely agree. going to happen, with that justification, and it's been accepted by 300 odd kernel developers in at least one kernel summit when it was talked Probably that was one I didn't attend to, as I can't remember this discussion. about... and it's been mentioned on mailing lists several times. Maybe LKML, which I don't read. So I wasn't aware of the plan before seeing Bill's patches. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 065/493] i2c: remove use of __devexit_p
On Mon, 19 Nov 2012 13:20:14 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. As mentioned on the lm-sensors list for hwmon patches already, I think it would be much clearer to not split __devexit, __devexit_p, __devinit etc. removal into separate patches. One patch per subsystem would be easier to review and apply. If patches grow too large then you'd rather split in a different direction, for example drivers/i2c/muxes vs. drivers/i2c/busses or even grouped by related bus drivers (see entries I2C OVER PARALLEL PORT and I2C/SMBUS CONTROLLER DRIVERS FOR PC in MAINTAINERS for examples of meaningful groups.) -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 207/493] i2c: remove use of __devinit
On Tue, Nov 20, 2012 at 09:20:46AM +0100, Jean Delvare wrote: Hi Bill, On Mon, 19 Nov 2012 13:22:36 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Can you please point me/us to the discussion explaining the rationale behind this move, and the explanation of what will be done exactly? While I can easily understand that we want to drop CONFIG_HOTPLUG and always enable hot-plug support, I don't see where we are going with removing __devinit annotations and the like. It's actually very simple to understand. 1. CONFIG_HOTPLUG is going away; it's already defined to always be 'Y'. 2. This means that the the devinit sections will not be discarded anymore. 3. As a result, there's no point the devinit sections existing anymore. 4. As there's no devinit sections, the __devinit marker is entirely redundant and useless. The reason this is being done is because the benefit to cost ratio of this is far too high; it's well proven that people constantly get these markings wrong, and with most kernels having had hotplug enabled anyway, it's not providing much in the way of space saving benefit over the number of section conflicts it causes. So, it's been decided a few years ago that this is going to happen, with that justification, and it's been accepted by 300 odd kernel developers in at least one kernel summit when it was talked about... and it's been mentioned on mailing lists several times. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
This patchset provides the Freescale PAMU (Peripheral Access Management Unit) driver and the corresponding IOMMU API implementation. PAMU is the IOMMU present on Freescale QorIQ platforms. PAMU can authorize memory access, remap the memory address, and remap the I/O transaction type. This set consists of the following patches: 1. Addition of new field in the device (powerpc) archdata structure for storing iommu domain information pointer. This pointer is stored when the device is attached to a particular iommu domain. 2. Add PAMU bypass enable register to the ccsr_guts structure. 3. Addition of domain attributes required by the PAMU driver IOMMU API. 4. PAMU driver and IOMMU API implementation. This patch set is based on the next branch of the iommu git tree maintained by Joerg. Varun Sethi (4): store iommu domain pointer in device archdata structure. Add PAMU bypass enable register to ccsr_guts structure. Add attributes for fsl PAMU driver. FSL PAMU driver. arch/powerpc/include/asm/device.h |4 + arch/powerpc/include/asm/fsl_guts.h |4 +- drivers/iommu/Kconfig |8 + drivers/iommu/Makefile |1 + drivers/iommu/fsl_pamu.c| 1152 +++ drivers/iommu/fsl_pamu.h| 398 ++ drivers/iommu/fsl_pamu_domain.c | 978 + drivers/iommu/fsl_pamu_domain.h | 102 include/linux/iommu.h | 43 +++ 9 files changed, 2680 insertions(+), 1 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h -- 1.7.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4 v2] iommu/fsl: Store iommu domain information pointer in archdata.
Add a new field in the device (powerpc) archdata structure for storing iommu
domain
information pointer. This pointer is stored when the device is attached to a
particular
domain.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/include/asm/device.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 77e97dd..6dc79fe 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -28,6 +28,10 @@ struct dev_archdata {
void*iommu_table_base;
} dma_data;
+ /* IOMMU domain information pointer. This would be set
+* when this device is attached to an iommu_domain.
+*/
+ void*iommu_domain;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] iommu/fsl: Add PAMU bypass enable register to ccsr_guts structure.
PAMU bypass enable register added to the ccsr_guts structure.
Signed-off-by: Timur Tabi ti...@freescale.com
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
arch/powerpc/include/asm/fsl_guts.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_guts.h
b/arch/powerpc/include/asm/fsl_guts.h
index aa4c488..bb208eb 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -69,7 +69,9 @@ struct ccsr_guts {
u8 res0c4[0x224 - 0xc4];
__be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
__be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
- u8 res22c[0x800 - 0x22c];
+ u8 res22c[0x604 - 0x22c];
+ __be32 pamubypenr; /* 0x.604 - PAMU bypass enable register */
+ u8 res608[0x800 - 0x608];
__be32 clkdvdr;/* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
__be32 ircr; /* 0x.0900 - Infrared Control Register */
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
Added the following domain attributes required by FSL PAMU driver:
1. Subwindows field added to the iommu domain geometry attribute.
2. Added new iommu stash attribute, which allows setting of the
LIODN specific stash id parameter through IOMMU API.
3. Added an attribute for enabling/disabling DMA to a particular
memory window.
Signed-off-by: Varun Sethi varun.se...@freescale.com
---
changes in v5:
- Updated description of the subwindows field.
changes in v4:
- Updated comment explaining subwindows(as mentioned by Scott).
change in v3:
-renamed the stash attribute targets
include/linux/iommu.h | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f3b99e1..7ca1cda 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -44,6 +44,41 @@ struct iommu_domain_geometry {
dma_addr_t aperture_start; /* First address that can be mapped*/
dma_addr_t aperture_end; /* Last address that can be mapped */
bool force_aperture; /* DMA only allowed in mappable range? */
+
+ /*
+* A geometry mapping can be created in one of the following ways
+* for an IOMMU:
+* 1. A single contiguous window
+* 2. Through arbritary paging throughout the aperture.
+* 3. Using multiple subwindows
+*
+* In absence of arbritary paging, subwindows allow for supporting
+* physically discontiguous mappings.
+*
+* This attribute indicates number of DMA subwindows supported by
+* the geometry. If there is a single window that maps the entire
+* geometry, attribute must be set to 1. A value of 0 implies
+* that this mechanism is not used at all(normal paging is used).
+* Value other than* 0 or 1 indicates the actual number of
+* subwindows.
+*/
+ u32 subwindows;
+};
+
+/* cache stash targets */
+#define IOMMU_ATTR_CACHE_L1 1
+#define IOMMU_ATTR_CACHE_L2 2
+#define IOMMU_ATTR_CACHE_L3 3
+
+/* This attribute corresponds to IOMMUs capable of generating
+ * a stash transaction. A stash transaction is typically a
+ * hardware initiated prefetch of data from memory to cache.
+ * This attribute allows configuring stashig specific parameters
+ * in the IOMMU hardware.
+ */
+struct iommu_stash_attribute {
+ u32 cpu;/* cpu number */
+ u32 cache; /* cache to stash to: L1,L2,L3 */
};
struct iommu_domain {
@@ -60,6 +95,14 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ /* Set the IOMMU hardware stashing
+* parameters.
+*/
+ DOMAIN_ATTR_STASH,
+ /* Explicity enable/disable DMA for a
+ * particular memory window.
+ */
+ DOMAIN_ATTR_ENABLE,
};
#ifdef CONFIG_IOMMU_API
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 119/493] usb: remove use of __devexit_p
Nicolas == Nicolas Ferre nicolas.fe...@atmel.com writes: Nicolas On 11/19/2012 07:21 PM, Bill Pemberton : CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Peter Korsgaard jac...@sunsite.dk Cc: Alexander Shishkin alexander.shish...@linux.intel.com Cc: Felipe Balbi ba...@ti.com Cc: Li Yang le...@freescale.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Wan ZongShun mcuos@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: linux-...@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Nicolas [..] drivers/usb/host/ehci-atmel.c| 2 +- drivers/usb/host/ohci-at91.c | 2 +- Nicolas For Atmel: Nicolas Acked-by: Nicolas Ferre nicolas.fe...@atmel.com For c67x00 and g_hid: Acked-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 429/493] tty: remove use of __devexit
On Mon, Nov 19, 2012 at 01:26:18PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu --- drivers/tty/serial/msm_serial.c | 2 +- drivers/tty/serial/msm_serial_hs.c | 2 +- Acked-by: David Brown dav...@codeaurora.org -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 158/493] video: remove use of __devinit
On Mon, Nov 19, 2012 at 01:21:47PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu --- drivers/video/msm/mddi.c | 6 +- Acked-by: David Brown dav...@codeaurora.org -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] vfio powerpc: enabled and supported on powernv platform
On Tue, 2012-11-20 at 11:48 +1100, Alexey Kardashevskiy wrote:
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.
The platform dependent part includes IOMMU initialization
and handling.
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan, only POWERNV
platform is supported at the moment.
Also the patch implements an VFIO-IOMMU driver which
manages DMA mapping/unmapping requests coming from
the client (now QEMU). It also returns a DMA window
information to let the guest initialize the device tree
for a guest OS properly. Although this driver has been
tested only on POWERNV, it should work on any platform
supporting TCE tables.
To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config
option.
Cc: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h |6 +
arch/powerpc/kernel/iommu.c | 140 +++
arch/powerpc/platforms/powernv/pci.c | 135 +++
drivers/iommu/Kconfig|8 ++
drivers/vfio/Kconfig |6 +
drivers/vfio/Makefile|1 +
drivers/vfio/vfio_iommu_spapr_tce.c | 247
++
include/linux/vfio.h | 20 +++
8 files changed, 563 insertions(+)
create mode 100644 drivers/vfio/vfio_iommu_spapr_tce.c
diff --git a/arch/powerpc/include/asm/iommu.h
b/arch/powerpc/include/asm/iommu.h
index cbfe678..5ba66cb 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -64,30 +64,33 @@ struct iommu_pool {
} cacheline_aligned_in_smp;
struct iommu_table {
unsigned long it_busno; /* Bus number this table belongs to */
unsigned long it_size; /* Size of iommu table in entries */
unsigned long it_offset;/* Offset into global table */
unsigned long it_base; /* mapped address of tce table */
unsigned long it_index; /* which iommu table this is */
unsigned long it_type; /* type: PCI or Virtual Bus */
unsigned long it_blocksize; /* Entries in each block (cacheline) */
unsigned long poolsize;
unsigned long nr_pools;
struct iommu_pool large_pool;
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map; /* A simple allocation bitmap for now */
+#ifdef CONFIG_IOMMU_API
+ struct iommu_group *it_group;
+#endif
};
struct scatterlist;
static inline void set_iommu_table_base(struct device *dev, void *base)
{
dev-archdata.dma_data.iommu_table_base = base;
}
static inline void *get_iommu_table_base(struct device *dev)
{
return dev-archdata.dma_data.iommu_table_base;
}
/* Frees table for an individual device node */
@@ -135,17 +138,20 @@ static inline void pci_iommu_init(void) { }
extern void alloc_dart_table(void);
#if defined(CONFIG_PPC64) defined(CONFIG_PM)
static inline void iommu_save(void)
{
if (ppc_md.iommu_save)
ppc_md.iommu_save();
}
static inline void iommu_restore(void)
{
if (ppc_md.iommu_restore)
ppc_md.iommu_restore();
}
#endif
+extern long iommu_put_tces(struct iommu_table *tbl, unsigned long entry,
uint64_t tce,
+ enum dma_data_direction direction, unsigned long pages);
+
#endif /* __KERNEL__ */
#endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index ff5a6ce..94f614b 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -32,30 +32,31 @@
#include linux/dma-mapping.h
#include linux/bitmap.h
#include linux/iommu-helper.h
#include linux/crash_dump.h
#include linux/hash.h
#include linux/fault-inject.h
#include linux/pci.h
#include asm/io.h
#include asm/prom.h
#include asm/iommu.h
#include asm/pci-bridge.h
#include asm/machdep.h
#include asm/kdump.h
#include asm/fadump.h
#include asm/vio.h
+#include asm/tce.h
#define DBG(...)
static int novmerge;
static void __iommu_free(struct iommu_table *, dma_addr_t, unsigned int);
static int __init setup_iommu(char *str)
{
if (!strcmp(str, novmerge))
novmerge = 1;
else if (!strcmp(str, vmerge))
novmerge = 0;
return 1;
}
@@ -844,15 +845,154 @@ void *iommu_alloc_coherent(struct device *dev, struct
iommu_table *tbl,
}
void iommu_free_coherent(struct iommu_table *tbl, size_t size,
void *vaddr, dma_addr_t dma_handle)
{
if (tbl) {
unsigned int nio_pages;
size = PAGE_ALIGN(size);
nio_pages = size IOMMU_PAGE_SHIFT;
iommu_free(tbl, dma_handle, nio_pages);
size =
Re: perf: POWER-event translation questions
On 09.11.12 11:26:26, Stephane Eranian wrote:
On Thu, Nov 8, 2012 at 2:10 AM, Sukadev Bhattiprolu
suka...@linux.vnet.ibm.com wrote:
2. Can we allow hyphens in the {name} token (please see my change to
util/parse-events.l below). With this change, I can run:
The current code does not support this but Andi fixed that in his HSW patch
and I use it for the PEBS-LL patch series as well.
perf stat -e cpu/cmplu-stall-bru /tmp/nop
without any changes to the user level tool (parse-events.l) I have
tested some common cases, not sure if it will break something :-)
But ...
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index c87efc1..1967bb2 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -80,7 +80,7 @@ event [^,{}/]+
num_dec[0-9]+
num_hex0x[a-fA-F0-9]+
num_raw_hex[a-fA-F0-9]+
-name [a-zA-Z_*?][a-zA-Z0-9_*?]*
+name [-a-zA-Z_*?][-a-zA-Z0-9_*?]*
^
... I wouldn't allow hyphens at the beginning of a name.
And, I am wondering if parsing reserved names like 'cpu-cycles' works
too, e.g. cpu/cpu-cycles-foobar/. There are many reserved words in the
lexer with hyphens in it. This might cause unexpected problems.
-Robert
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 159/493] usb: remove use of __devinit
On Mon, 19 Nov 2012, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu For all the __devinit* annotations and all the EHCI, OHCI, and UHCI drivers: Acked-by: Alan Stern st...@rowland.harvard.edu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4 v5] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
Varun Sethi wrote:
diff --git a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h
new file mode 100644
index 000..6d32fb5
--- /dev/null
+++ b/drivers/iommu/fsl_pamu.h
@@ -0,0 +1,398 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ */
+
+#ifndef __FSL_PAMU_H
+#define __FSL_PAMU_H
+
+/* Bit Field macros
+ * v = bit field variable; m = mask, m##_SHIFT = shift, x = value to load
+ */
+#define set_bf(v, m, x) (v = ((v) ~(m)) | (((x)
(m##_SHIFT)) (m)))
+#define get_bf(v, m) (((v) (m)) (m##_SHIFT))
+
+/* PAMU CCSR space */
+#define PAMU_PGC 0x /* Allows all peripheral accesses */
+#define PAMU_PE 0x4000 /* enable PAMU*/
+
+/* PAMU_OFFSET to the next pamu space in ccsr */
+#define PAMU_OFFSET 0x1000
+
+#define PAMU_MMAP_REGS_BASE 0
+
+struct pamu_mmap_regs {
+ u32 ppbah;
+ u32 ppbal;
+ u32 pplah;
+ u32 pplal;
+ u32 spbah;
+ u32 spbal;
+ u32 splah;
+ u32 splal;
+ u32 obah;
+ u32 obal;
+ u32 olah;
+ u32 olal;
+};
+
+/* PAMU Error Registers */
+#define PAMU_POES1 0x0040
+#define PAMU_POES2 0x0044
+#define PAMU_POEAH 0x0048
+#define PAMU_POEAL 0x004C
+#define PAMU_AVS1 0x0050
+#define PAMU_AVS1_AV0x1
+#define PAMU_AVS1_OTV 0x6
+#define PAMU_AVS1_APV 0x78
+#define PAMU_AVS1_WAV 0x380
+#define PAMU_AVS1_LAV 0x1c00
+#define PAMU_AVS1_GCV 0x2000
+#define PAMU_AVS1_PDV 0x4000
+#define PAMU_AV_MASK(PAMU_AVS1_AV | PAMU_AVS1_OTV | PAMU_AVS1_APV |
PAMU_AVS1_WAV \
+ | PAMU_AVS1_LAV | PAMU_AVS1_GCV | PAMU_AVS1_PDV)
+#define PAMU_AVS1_LIODN_SHIFT 16
+#define PAMU_LAV_LIODN_NOT_IN_PPAACT 0x400
I think you can move most of macros in this .h file into one of the .c files.
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
new file mode 100644
index 000..d473447
--- /dev/null
+++ b/drivers/iommu/fsl_pamu_domain.c
The code in this file is generally hard to read because you
1) have very few comments
2) you have a lot of expressions that span several lines, like this one:
if ((iova = geom_attr-aperture_start
iova geom_attr-aperture_end - 1
size = geom_size)
!align_check) {
Try adding a few more comments (e.g. each function should be commented)
and maybe try to break up a few of these lines.
@@ -0,0 +1,978 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Author: Varun Sethi varun.se...@freescale.com
+ *
+ */
+
+#define pr_fmt(fmt)fsl-pamu-domain: %s: fmt, __func__
You don't use this macro.
+
+#include linux/init.h
+#include linux/iommu.h
+#include linux/notifier.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/types.h
+#include linux/mm.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/of_platform.h
+#include linux/bootmem.h
+#include linux/err.h
+#include asm/io.h
+#include asm/bitops.h
+
+#include fsl_pamu_domain.h
+
+/* This bitmap advertises the page sizes supported by PAMU hardware
+ * to the IOMMU API.
+ */
+#define FSL_PAMU_PGSIZES (~0xFFFUL)
+
+/* global spinlock that needs to be held while
+ * configuring PAMU.
+ */
+static DEFINE_SPINLOCK(iommu_lock);
+
+static struct kmem_cache *fsl_pamu_domain_cache;
+static struct kmem_cache *iommu_devinfo_cache;
+static DEFINE_SPINLOCK(device_domain_lock);
+
+int __init iommu_init_mempool(void)
+{
+
+ fsl_pamu_domain_cache = kmem_cache_create(fsl_pamu_domain,
+
Re: [PATCH] cpuidle: Measure idle state durations with monotonic clock
On Wednesday, November 14, 2012 05:56:30 PM Julius Werner wrote:
Many cpuidle drivers measure their time spent in an idle state by
reading the wallclock time before and after idling and calculating the
difference. This leads to erroneous results when the wallclock time gets
updated by another processor in the meantime, adding that clock
adjustment to the idle state's time counter.
If the clock adjustment was negative, the result is even worse due to an
erroneous cast from int to unsigned long long of the last_residency
variable. The negative 32 bit integer will zero-extend and result in a
forward time jump of roughly four billion milliseconds or 1.3 hours on
the idle state residency counter.
This patch changes all affected cpuidle drivers to either use the
monotonic clock for their measurements or make use of the generic time
measurement wrapper in cpuidle.c, which was already working correctly.
Some superfluous CLIs/STIs in the ACPI code are removed (interrupts
should always already be disabled before entering the idle function, and
not get reenabled until the generic wrapper has performed its second
measurement). It also removes the erroneous cast, making sure that
negative residency values are applied correctly even though they should
not appear anymore.
Signed-off-by: Julius Werner jwer...@chromium.org
Len, I need your ACK on intel_idle change in this patch if you agree with it.
Thanks,
Rafael
---
arch/powerpc/platforms/pseries/processor_idle.c |4 +-
drivers/acpi/processor_idle.c | 57 +-
drivers/cpuidle/cpuidle.c |3 +-
drivers/idle/intel_idle.c | 14 +-
4 files changed, 7 insertions(+), 71 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
index 45d00e5..4d806b4 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -36,7 +36,7 @@ static struct cpuidle_state *cpuidle_state_table;
static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t
*kt_before)
{
- *kt_before = ktime_get_real();
+ *kt_before = ktime_get();
*in_purr = mfspr(SPRN_PURR);
/*
* Indicate to the HV that we are idle. Now would be
@@ -50,7 +50,7 @@ static inline s64 idle_loop_epilog(unsigned long in_purr,
ktime_t kt_before)
get_lppaca()-wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
get_lppaca()-idle = 0;
- return ktime_to_us(ktime_sub(ktime_get_real(), kt_before));
+ return ktime_to_us(ktime_sub(ktime_get(), kt_before));
}
static int snooze_loop(struct cpuidle_device *dev,
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index e8086c7..f1a5da4 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -735,31 +735,18 @@ static inline void acpi_idle_do_entry(struct
acpi_processor_cx *cx)
static int acpi_idle_enter_c1(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
- ktime_t kt1, kt2;
- s64 idle_time;
struct acpi_processor *pr;
struct cpuidle_state_usage *state_usage = dev-states_usage[index];
struct acpi_processor_cx *cx = cpuidle_get_statedata(state_usage);
pr = __this_cpu_read(processors);
- dev-last_residency = 0;
if (unlikely(!pr))
return -EINVAL;
- local_irq_disable();
-
-
lapic_timer_state_broadcast(pr, cx, 1);
- kt1 = ktime_get_real();
acpi_idle_do_entry(cx);
- kt2 = ktime_get_real();
- idle_time = ktime_to_us(ktime_sub(kt2, kt1));
-
- /* Update device last_residency*/
- dev-last_residency = (int)idle_time;
- local_irq_enable();
lapic_timer_state_broadcast(pr, cx, 0);
return index;
@@ -806,19 +793,12 @@ static int acpi_idle_enter_simple(struct cpuidle_device
*dev,
struct acpi_processor *pr;
struct cpuidle_state_usage *state_usage = dev-states_usage[index];
struct acpi_processor_cx *cx = cpuidle_get_statedata(state_usage);
- ktime_t kt1, kt2;
- s64 idle_time_ns;
- s64 idle_time;
pr = __this_cpu_read(processors);
- dev-last_residency = 0;
if (unlikely(!pr))
return -EINVAL;
- local_irq_disable();
-
-
if (cx-entry_method != ACPI_CSTATE_FFH) {
current_thread_info()-status = ~TS_POLLING;
/*
@@ -829,7 +809,6 @@ static int acpi_idle_enter_simple(struct cpuidle_device
*dev,
if (unlikely(need_resched())) {
current_thread_info()-status |= TS_POLLING;
- local_irq_enable();
return -EINVAL;
}
}
@@ -843,22 +822,12 @@ static int acpi_idle_enter_simple(struct cpuidle_device
*dev,
if (cx-type ==
Re: Please pull 'merge' branch of 5xxx tree
On Tue, 2012-11-20 at 09:27 +0100, Anatolij Gustschin wrote: Hi Ben, On Thu, 25 Oct 2012 22:41:13 +0200 Anatolij Gustschin ag...@denx.de wrote: Hi Ben, please pull three mpc5200 fixes for 3.7: Ping. Sorry, missed that, dunno whether it's too late, I'll try. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
At 11/20/2012 07:16 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I have a question about these sparse vmemmap memory related patches. Hot
add memory need allocated vmemmap pages, but this time is allocated by
buddy system. How can gurantee virtual address is continuous to the
address allocated before? If not continuous, page_to_pfn and pfn_to_page
can't work correctly.
vmemmap has its virtual address range:
ea00 - eaff (=40 bits) virtual memory map (1TB)
We allocate memory from buddy system to store struct page, and its virtual
address isn't in this range. So we should update the page table:
kmalloc_section_memmap()
sparse_mem_map_populate()
pfn_to_page() // get the virtual address in the vmemmap range
vmemmap_populate() // we update page table here
When we use vmemmap, page_to_pfn() always returns address in the vmemmap
range, not the address that kmalloc() returns. So the virtual address
is continuous.
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section *ms)
{
-/*
- * XXX: Freeing memmap with vmemmap is not implement yet.
- * This should be removed later.
- */
-return -EBUSY;
+int ret = -EINVAL;
+
+if (!valid_section(ms))
+return ret;
+
+ret = unregister_memory_section(ms);
+
+return ret;
}
#else
static int __remove_section(struct zone *zone, struct mem_section *ms)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
On 11/21/2012 11:05 AM, Wen Congyang wrote:
At 11/20/2012 07:16 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I have a question about these sparse vmemmap memory related patches. Hot
add memory need allocated vmemmap pages, but this time is allocated by
buddy system. How can gurantee virtual address is continuous to the
address allocated before? If not continuous, page_to_pfn and pfn_to_page
can't work correctly.
vmemmap has its virtual address range:
ea00 - eaff (=40 bits) virtual memory map (1TB)
We allocate memory from buddy system to store struct page, and its virtual
address isn't in this range. So we should update the page table:
kmalloc_section_memmap()
sparse_mem_map_populate()
pfn_to_page() // get the virtual address in the vmemmap range
vmemmap_populate() // we update page table here
When we use vmemmap, page_to_pfn() always returns address in the vmemmap
range, not the address that kmalloc() returns. So the virtual address
is continuous.
Hi Congyang,
Another question about memory hotplug. During hot remove memory, it will
also call memblock_remove to remove related memblock.
memblock_remove()
__memblock_remove()
memblock_isolate_range()
memblock_remove_region()
But memblock_isolate_range() only record fully contained regions,
regions which are partial overlapped just be splitted instead of record.
So these partial overlapped regions can't be removed. Where I miss?
Regards,
Jaegeuk
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section *ms)
{
-/*
- * XXX: Freeing memmap with vmemmap is not implement yet.
- * This should be removed later.
- */
-return -EBUSY;
+int ret = -EINVAL;
+
+if (!valid_section(ms))
+return ret;
+
+ret = unregister_memory_section(ms);
+
+return ret;
}
#else
static int __remove_section(struct zone *zone, struct mem_section *ms)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
At 11/21/2012 12:22 PM, Jaegeuk Hanse Wrote:
On 11/21/2012 11:05 AM, Wen Congyang wrote:
At 11/20/2012 07:16 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I have a question about these sparse vmemmap memory related patches. Hot
add memory need allocated vmemmap pages, but this time is allocated by
buddy system. How can gurantee virtual address is continuous to the
address allocated before? If not continuous, page_to_pfn and pfn_to_page
can't work correctly.
vmemmap has its virtual address range:
ea00 - eaff (=40 bits) virtual memory map (1TB)
We allocate memory from buddy system to store struct page, and its
virtual
address isn't in this range. So we should update the page table:
kmalloc_section_memmap()
sparse_mem_map_populate()
pfn_to_page() // get the virtual address in the vmemmap range
vmemmap_populate() // we update page table here
When we use vmemmap, page_to_pfn() always returns address in the vmemmap
range, not the address that kmalloc() returns. So the virtual address
is continuous.
Hi Congyang,
Another question about memory hotplug. During hot remove memory, it will
also call memblock_remove to remove related memblock.
IIRC, we don't touch memblock when hot-add/hot-remove memory. memblock is
only used for bootmem allocator. I think it isn't used after booting.
memblock_remove()
__memblock_remove()
memblock_isolate_range()
memblock_remove_region()
But memblock_isolate_range() only record fully contained regions,
regions which are partial overlapped just be splitted instead of record.
So these partial overlapped regions can't be removed. Where I miss?
No, memblock_isolate_range() can deal with partial overlapped region.
=
if (rbase base) {
/*
* @rgn intersects from below. Split and continue
* to process the next region - the new top half.
*/
rgn-base = base;
rgn-size -= base - rbase;
type-total_size -= base - rbase;
memblock_insert_region(type, i, rbase, base - rbase,
memblock_get_region_node(rgn));
} else if (rend end) {
/*
* @rgn intersects from above. Split and redo the
* current region - the new bottom half.
*/
rgn-base = end;
rgn-size -= end - rbase;
type-total_size -= end - rbase;
memblock_insert_region(type, i--, rbase, end - rbase,
memblock_get_region_node(rgn));
=
If the region is partial overlapped region, we will split the old region into
two regions. After doing this, it is full contained region now.
Thanks
Wen Congyang
Regards,
Jaegeuk
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section
*ms)
{
-/*
- * XXX: Freeing memmap with vmemmap is not implement yet.
- * This should be removed later.
- */
-return -EBUSY;
+int ret = -EINVAL;
+
+if (!valid_section(ms))
+return ret;
+
+ret = unregister_memory_section(ms);
+
+return ret;
}
#else
static int __remove_section(struct zone *zone, struct mem_section
*ms)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are small 52xx fixes that Anatolij asked me to pull a while back and that I completely missed. The stuff is local to that platform code, and was in next for a while, so it should still go into 3.7. Thanks, Ben. The following changes since commit 8c23f406c6d86808726ace580657186bc3b44587: Merge git://git.kernel.org/pub/scm/virt/kvm/kvm (2012-11-01 08:27:02 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to d6dc24613c222f9057131ccbd5264a10bcba9f97: Merge remote-tracking branch 'agust/merge' into merge (2012-11-21 13:24:49 +1100) Anatolij Gustschin (1): powerpc/mpc5200: move lpbfifo node and fix its interrupt property Benjamin Herrenschmidt (1): Merge remote-tracking branch 'agust/merge' into merge Eric Millbrandt (1): powerpc/pcm030: add pcm030-audio-fabric to dts Wolfram Sang (1): powerpc: 52xx: nop out unsupported critical IRQs arch/powerpc/boot/dts/mpc5200b.dtsi |6 ++ arch/powerpc/boot/dts/o2d.dtsi|6 -- arch/powerpc/boot/dts/pcm030.dts |7 ++- arch/powerpc/platforms/52xx/mpc52xx_pic.c |9 + 4 files changed, 17 insertions(+), 11 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
On 11/21/2012 12:42 PM, Wen Congyang wrote:
At 11/21/2012 12:22 PM, Jaegeuk Hanse Wrote:
On 11/21/2012 11:05 AM, Wen Congyang wrote:
At 11/20/2012 07:16 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I have a question about these sparse vmemmap memory related patches. Hot
add memory need allocated vmemmap pages, but this time is allocated by
buddy system. How can gurantee virtual address is continuous to the
address allocated before? If not continuous, page_to_pfn and pfn_to_page
can't work correctly.
vmemmap has its virtual address range:
ea00 - eaff (=40 bits) virtual memory map (1TB)
We allocate memory from buddy system to store struct page, and its
virtual
address isn't in this range. So we should update the page table:
kmalloc_section_memmap()
sparse_mem_map_populate()
pfn_to_page() // get the virtual address in the vmemmap range
vmemmap_populate() // we update page table here
When we use vmemmap, page_to_pfn() always returns address in the vmemmap
range, not the address that kmalloc() returns. So the virtual address
is continuous.
Hi Congyang,
Another question about memory hotplug. During hot remove memory, it will
also call memblock_remove to remove related memblock.
IIRC, we don't touch memblock when hot-add/hot-remove memory. memblock is
only used for bootmem allocator. I think it isn't used after booting.
In IBM pseries servers.
pseries_remove_memory()
pseries_remove_memblock()
memblock_remove()
Furthermore, memblock is set to record available memory ranges get from
e820 map(you can check it in memblock_x86_fill()) in x86 case, after
hot-remove memory, this range of memory can't be available, why not
remove them as pseries servers' codes do.
memblock_remove()
__memblock_remove()memory-hotplug: unregister memory section on
SPARSEMEM_VMEMMAP
memblock_isolate_range()
memblock_remove_region()
But memblock_isolate_range() only record fully contained regions,
regions which are partial overlapped just be splitted instead of record.
So these partial overlapped regions can't be removed. Where I miss?
No, memblock_isolate_range() can deal with partial overlapped region.
=
if (rbase base) {
/*
* @rgn intersects from below. Split and continue
* to process the next region - the new top half.
*/
rgn-base = base;
rgn-size -= base - rbase;
type-total_size -= base - rbase;
memblock_insert_region(type, i, rbase, base - rbase,
memblock_get_region_node(rgn));
} else if (rend end) {
/*
* @rgn intersects from above. Split and redo the
* current region - the new bottom half.
*/
rgn-base = end;
rgn-size -= end - rbase;
type-total_size -= end - rbase;
memblock_insert_region(type, i--, rbase, end - rbase,
memblock_get_region_node(rgn));
=
If the region is partial overlapped region, we will split the old region into
two regions. After doing this, it is full contained region now.
You are right, I misunderstand the codes.
Thanks
Wen Congyang
Regards,
Jaegeuk
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section
*ms)
{
-/*
- * XXX: Freeing memmap with vmemmap is not implement yet.
- * This should be removed later.
- */
-return -EBUSY;
+int ret = -EINVAL;
+
+if (!valid_section(ms))
+return ret;
+
+ret =
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
At 11/21/2012 01:03 PM, Jaegeuk Hanse Wrote:
On 11/21/2012 12:42 PM, Wen Congyang wrote:
At 11/21/2012 12:22 PM, Jaegeuk Hanse Wrote:
On 11/21/2012 11:05 AM, Wen Congyang wrote:
At 11/20/2012 07:16 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I have a question about these sparse vmemmap memory related
patches. Hot
add memory need allocated vmemmap pages, but this time is allocated by
buddy system. How can gurantee virtual address is continuous to the
address allocated before? If not continuous, page_to_pfn and
pfn_to_page
can't work correctly.
vmemmap has its virtual address range:
ea00 - eaff (=40 bits) virtual memory map (1TB)
We allocate memory from buddy system to store struct page, and its
virtual
address isn't in this range. So we should update the page table:
kmalloc_section_memmap()
sparse_mem_map_populate()
pfn_to_page() // get the virtual address in the vmemmap range
vmemmap_populate() // we update page table here
When we use vmemmap, page_to_pfn() always returns address in the
vmemmap
range, not the address that kmalloc() returns. So the virtual address
is continuous.
Hi Congyang,
Another question about memory hotplug. During hot remove memory, it will
also call memblock_remove to remove related memblock.
IIRC, we don't touch memblock when hot-add/hot-remove memory. memblock is
only used for bootmem allocator. I think it isn't used after booting.
In IBM pseries servers.
pseries_remove_memory()
pseries_remove_memblock()
memblock_remove()
Furthermore, memblock is set to record available memory ranges get from
e820 map(you can check it in memblock_x86_fill()) in x86 case, after
hot-remove memory, this range of memory can't be available, why not
remove them as pseries servers' codes do.
Oh, it is powerpc, and I don't read this code. I will check it now.
Thanks for pointing it out.
Wen Congyang
memblock_remove()
__memblock_remove()memory-hotplug: unregister memory
section on SPARSEMEM_VMEMMAP
memblock_isolate_range()
memblock_remove_region()
But memblock_isolate_range() only record fully contained regions,
regions which are partial overlapped just be splitted instead of record.
So these partial overlapped regions can't be removed. Where I miss?
No, memblock_isolate_range() can deal with partial overlapped region.
=
if (rbase base) {
/*
* @rgn intersects from below. Split and continue
* to process the next region - the new top half.
*/
rgn-base = base;
rgn-size -= base - rbase;
type-total_size -= base - rbase;
memblock_insert_region(type, i, rbase, base - rbase,
memblock_get_region_node(rgn));
} else if (rend end) {
/*
* @rgn intersects from above. Split and redo the
* current region - the new bottom half.
*/
rgn-base = end;
rgn-size -= end - rbase;
type-total_size -= end - rbase;
memblock_insert_region(type, i--, rbase, end - rbase,
memblock_get_region_node(rgn));
=
If the region is partial overlapped region, we will split the old
region into
two regions. After doing this, it is full contained region now.
You are right, I misunderstand the codes.
Thanks
Wen Congyang
Regards,
Jaegeuk
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int __remove_section(struct zone *zone, struct mem_section
*ms)
{
-/*
- * XXX: Freeing memmap with vmemmap is not implement yet.
- * This should be removed later.
- */
-return -EBUSY;
+int ret = -EINVAL;
+
+if (!valid_section(ms))
+return ret;
+
+
Re: [PATCH v3 06/12] memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
At 11/21/2012 01:03 PM, Jaegeuk Hanse Wrote:
On 11/21/2012 12:42 PM, Wen Congyang wrote:
At 11/21/2012 12:22 PM, Jaegeuk Hanse Wrote:
On 11/21/2012 11:05 AM, Wen Congyang wrote:
At 11/20/2012 07:16 PM, Jaegeuk Hanse Wrote:
On 11/01/2012 05:44 PM, Wen Congyang wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Currently __remove_section for SPARSEMEM_VMEMMAP does nothing. But
even if
we use SPARSEMEM_VMEMMAP, we can unregister the memory_section.
So the patch add unregister_memory_section() into __remove_section().
Hi Yasuaki,
I have a question about these sparse vmemmap memory related
patches. Hot
add memory need allocated vmemmap pages, but this time is allocated by
buddy system. How can gurantee virtual address is continuous to the
address allocated before? If not continuous, page_to_pfn and
pfn_to_page
can't work correctly.
vmemmap has its virtual address range:
ea00 - eaff (=40 bits) virtual memory map (1TB)
We allocate memory from buddy system to store struct page, and its
virtual
address isn't in this range. So we should update the page table:
kmalloc_section_memmap()
sparse_mem_map_populate()
pfn_to_page() // get the virtual address in the vmemmap range
vmemmap_populate() // we update page table here
When we use vmemmap, page_to_pfn() always returns address in the
vmemmap
range, not the address that kmalloc() returns. So the virtual address
is continuous.
Hi Congyang,
Another question about memory hotplug. During hot remove memory, it will
also call memblock_remove to remove related memblock.
IIRC, we don't touch memblock when hot-add/hot-remove memory. memblock is
only used for bootmem allocator. I think it isn't used after booting.
In IBM pseries servers.
pseries_remove_memory()
pseries_remove_memblock()
memblock_remove()
It seems that pseries servers don't use ACPI(ACPI is only supported for
ia64 and x86 now. arm will be supported in the furture).
I am not ppc expert, and I don't know why we touch memblock when hotadding
memory in ppc case. But IIRC, we don't need memblock after the machine has
booted up in x86 case. So there is no need to touch it when hotadd/hotremove
the memory in x86 case.
Thanks
Wen Congyang
Furthermore, memblock is set to record available memory ranges get from
e820 map(you can check it in memblock_x86_fill()) in x86 case, after
hot-remove memory, this range of memory can't be available, why not
remove them as pseries servers' codes do.
memblock_remove()
__memblock_remove()memory-hotplug: unregister memory
section on SPARSEMEM_VMEMMAP
memblock_isolate_range()
memblock_remove_region()
But memblock_isolate_range() only record fully contained regions,
regions which are partial overlapped just be splitted instead of record.
So these partial overlapped regions can't be removed. Where I miss?
No, memblock_isolate_range() can deal with partial overlapped region.
=
if (rbase base) {
/*
* @rgn intersects from below. Split and continue
* to process the next region - the new top half.
*/
rgn-base = base;
rgn-size -= base - rbase;
type-total_size -= base - rbase;
memblock_insert_region(type, i, rbase, base - rbase,
memblock_get_region_node(rgn));
} else if (rend end) {
/*
* @rgn intersects from above. Split and redo the
* current region - the new bottom half.
*/
rgn-base = end;
rgn-size -= end - rbase;
type-total_size -= end - rbase;
memblock_insert_region(type, i--, rbase, end - rbase,
memblock_get_region_node(rgn));
=
If the region is partial overlapped region, we will split the old
region into
two regions. After doing this, it is full contained region now.
You are right, I misunderstand the codes.
Thanks
Wen Congyang
Regards,
Jaegeuk
Thanks
Wen Congyang
Regards,
Jaegeuk
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
mm/memory_hotplug.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index ca07433..66a79a7 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -286,11 +286,14 @@ static int __meminit __add_section(int nid,
struct zone *zone,
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static int
