date:20160331

The wake_up_all_idle_cpus API always wake up all the online
cpus, but sometimes we only want to wake up a set of cpus.

Use a generic function to wake up a group of cpus that is
specified by the cpumask parameter. This generic API can
benefit to the cases that only need to wake up a set of
cpus.

Signed-off-by: Lianwei Wang 
---
 drivers/cpuidle/cpuidle.c |  4 ++--
 include/linux/smp.h   |  4 ++--
 kernel/power/suspend.c|  2 +-
 kernel/smp.c  | 12 +++-
 4 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index f996efc56605..c2a85c89e276 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -301,7 +301,7 @@ void cpuidle_uninstall_idle_handler(void)
 {
if (enabled_devices) {
initialized = 0;
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus(cpu_online_mask);
}
 
/*
@@ -620,7 +620,7 @@ EXPORT_SYMBOL_GPL(cpuidle_register);
 static int cpuidle_latency_notify(struct notifier_block *b,
unsigned long l, void *v)
 {
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus(cpu_online_mask);
return NOTIFY_OK;
 }
 
diff --git a/include/linux/smp.h b/include/linux/smp.h
index c4414074bd88..ee9d087c4c9a 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -100,7 +100,7 @@ int smp_call_function_any(const struct cpumask *mask,
  smp_call_func_t func, void *info, int wait);
 
 void kick_all_cpus_sync(void);
-void wake_up_all_idle_cpus(void);
+void wake_up_idle_cpus(const struct cpumask *mask);
 
 /*
  * Generic and arch helpers
@@ -149,7 +149,7 @@ smp_call_function_any(const struct cpumask *mask, 
smp_call_func_t func,
 }
 
 static inline void kick_all_cpus_sync(void) {  }
-static inline void wake_up_all_idle_cpus(void) {  }
+static inline void wake_up_idle_cpus(const struct cpumask *mask) {  }
 
 #ifdef CONFIG_UP_LATE_INIT
 extern void __init up_late_init(void);
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 5b70d64b871e..a4176ab96b36 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -70,7 +70,7 @@ static void freeze_enter(void)
cpuidle_resume();
 
/* Push all the CPUs into the idle loop. */
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus(cpu_online_mask);
pr_debug("PM: suspend-to-idle\n");
/* Make the current CPU wait so it can enter the idle loop too. */
wait_event(suspend_freeze_wait_head,
diff --git a/kernel/smp.c b/kernel/smp.c
index 74165443c240..c2beecb5ef01 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -720,17 +720,19 @@ void kick_all_cpus_sync(void)
 EXPORT_SYMBOL_GPL(kick_all_cpus_sync);
 
 /**
- * wake_up_all_idle_cpus - break all cpus out of idle
- * wake_up_all_idle_cpus try to break all cpus which is in idle state even
+ * wake_up_idle_cpus - break a set of cpus out of idle
+ * @mask: The set of cpus to break out of idle
+ *
+ * wake_up_idle_cpus try to break a set of cpus which is in idle state even
  * including idle polling cpus, for non-idle cpus, we will do nothing
  * for them.
  */
-void wake_up_all_idle_cpus(void)
+void wake_up_idle_cpus(const struct cpumask *mask)
 {
int cpu;
 
preempt_disable();
-   for_each_online_cpu(cpu) {
+   for_each_cpu_and(cpu, mask, cpu_online_mask) {
if (cpu == smp_processor_id())
continue;
 
@@ -738,4 +740,4 @@ void wake_up_all_idle_cpus(void)
}
preempt_enable();
 }
-EXPORT_SYMBOL_GPL(wake_up_all_idle_cpus);
+EXPORT_SYMBOL_GPL(wake_up_idle_cpus);
-- 
1.9.1

[PATCH RESEND] smp: make wake up idle cpus more generic

The wake_up_all_idle_cpus API always wake up all the online
cpus, but sometimes we only want to wake up a set of cpus.

Use a generic function to wake up a group of cpus that is
specified by the cpumask parameter. This generic API can
benefit to the cases that only need to wake up a set of
cpus.

Signed-off-by: Lianwei Wang 
---
 drivers/cpuidle/cpuidle.c |  4 ++--
 include/linux/smp.h   |  4 ++--
 kernel/power/suspend.c|  2 +-
 kernel/smp.c  | 12 +++-
 4 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index f996efc56605..c2a85c89e276 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -301,7 +301,7 @@ void cpuidle_uninstall_idle_handler(void)
 {
if (enabled_devices) {
initialized = 0;
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus(cpu_online_mask);
}
 
/*
@@ -620,7 +620,7 @@ EXPORT_SYMBOL_GPL(cpuidle_register);
 static int cpuidle_latency_notify(struct notifier_block *b,
unsigned long l, void *v)
 {
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus(cpu_online_mask);
return NOTIFY_OK;
 }
 
diff --git a/include/linux/smp.h b/include/linux/smp.h
index c4414074bd88..ee9d087c4c9a 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -100,7 +100,7 @@ int smp_call_function_any(const struct cpumask *mask,
  smp_call_func_t func, void *info, int wait);
 
 void kick_all_cpus_sync(void);
-void wake_up_all_idle_cpus(void);
+void wake_up_idle_cpus(const struct cpumask *mask);
 
 /*
  * Generic and arch helpers
@@ -149,7 +149,7 @@ smp_call_function_any(const struct cpumask *mask, 
smp_call_func_t func,
 }
 
 static inline void kick_all_cpus_sync(void) {  }
-static inline void wake_up_all_idle_cpus(void) {  }
+static inline void wake_up_idle_cpus(const struct cpumask *mask) {  }
 
 #ifdef CONFIG_UP_LATE_INIT
 extern void __init up_late_init(void);
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 5b70d64b871e..a4176ab96b36 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -70,7 +70,7 @@ static void freeze_enter(void)
cpuidle_resume();
 
/* Push all the CPUs into the idle loop. */
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus(cpu_online_mask);
pr_debug("PM: suspend-to-idle\n");
/* Make the current CPU wait so it can enter the idle loop too. */
wait_event(suspend_freeze_wait_head,
diff --git a/kernel/smp.c b/kernel/smp.c
index 74165443c240..c2beecb5ef01 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -720,17 +720,19 @@ void kick_all_cpus_sync(void)
 EXPORT_SYMBOL_GPL(kick_all_cpus_sync);
 
 /**
- * wake_up_all_idle_cpus - break all cpus out of idle
- * wake_up_all_idle_cpus try to break all cpus which is in idle state even
+ * wake_up_idle_cpus - break a set of cpus out of idle
+ * @mask: The set of cpus to break out of idle
+ *
+ * wake_up_idle_cpus try to break a set of cpus which is in idle state even
  * including idle polling cpus, for non-idle cpus, we will do nothing
  * for them.
  */
-void wake_up_all_idle_cpus(void)
+void wake_up_idle_cpus(const struct cpumask *mask)
 {
int cpu;
 
preempt_disable();
-   for_each_online_cpu(cpu) {
+   for_each_cpu_and(cpu, mask, cpu_online_mask) {
if (cpu == smp_processor_id())
continue;
 
@@ -738,4 +740,4 @@ void wake_up_all_idle_cpus(void)
}
preempt_enable();
 }
-EXPORT_SYMBOL_GPL(wake_up_all_idle_cpus);
+EXPORT_SYMBOL_GPL(wake_up_idle_cpus);
-- 
1.9.1

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

2016-03-31 Thread Felipe Balbi


Hi,

Mark Brown  writes:
> On Thu, Mar 31, 2016 at 09:42:58AM +0300, Felipe Balbi wrote:
>> Baolin Wang  writes:
>
>> > I want to use bus structure to manage the charger device. Maybe choose
>> > class to manage them?
>
>> I guess a class would fit better in this case.
>
> IIRC Greg didn't want new classes?

good point. Still, this doesn't seem to fit a but_type IMO.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

2016-03-31 Thread Felipe Balbi


Hi,

Mark Brown  writes:
> On Thu, Mar 31, 2016 at 09:42:58AM +0300, Felipe Balbi wrote:
>> Baolin Wang  writes:
>
>> > I want to use bus structure to manage the charger device. Maybe choose
>> > class to manage them?
>
>> I guess a class would fit better in this case.
>
> IIRC Greg didn't want new classes?

good point. Still, this doesn't seem to fit a but_type IMO.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH V3 9/9] iommu/amd: Set AMD iommu callbacks for amba bus

From: Wan Zongshun 

AMD Uart DMA belongs to ACPI HID type device, and its driver
is basing on AMBA Bus, need also IOMMU support.

This patch is just to set the AMD iommu callbacks for amba bus.

Signed-off-by: Wan Zongshun 
---
 drivers/iommu/amd_iommu.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 713e7ea..c430c10 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2969,7 +2970,17 @@ static struct dma_map_ops amd_iommu_dma_ops = {
 
 int __init amd_iommu_init_api(void)
 {
-   return bus_set_iommu(_bus_type, _iommu_ops);
+   int err = 0;
+
+   err = bus_set_iommu(_bus_type, _iommu_ops);
+   if (err)
+   return err;
+#ifdef CONFIG_ARM_AMBA
+   err = bus_set_iommu(_bustype, _iommu_ops);
+   if (err)
+   return err;
+#endif
+   return 0;
 }
 
 int __init amd_iommu_init_dma_ops(void)
-- 
1.9.1

[PATCH V3 2/9] iommu/amd: Modify ivhd_header structure to support type 11h and 40h

From: Suravee Suthikulpanit 

This patch modifies the existing struct ivhd_header,
which currently only support IVHD type 0x10, to add
new fields from IVHD type 11h and 40h.

It also modifies the pointer calculation to allow
support for IVHD type 11h and 40h

Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu_init.c | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index dff1e01..22e078b 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -398,6 +398,22 @@ static void __init iommu_unmap_mmio_space(struct amd_iommu 
*iommu)
release_mem_region(iommu->mmio_phys, iommu->mmio_phys_end);
 }
 
+static inline u32 get_ivhd_header_size(struct ivhd_header *h)
+{
+   u32 size = 0;
+
+   switch (h->type) {
+   case 0x10:
+   size = 24;
+   break;
+   case 0x11:
+   case 0x40:
+   size = 40;
+   break;
+   }
+   return size;
+}
+
 /
  *
  * The functions below belong to the first pass of AMD IOMMU ACPI table
@@ -424,7 +440,14 @@ static int __init find_last_devid_from_ivhd(struct 
ivhd_header *h)
u8 *p = (void *)h, *end = (void *)h;
struct ivhd_entry *dev;
 
-   p += sizeof(*h);
+   u32 ivhd_size = get_ivhd_header_size(h);
+
+   if (!ivhd_size) {
+   pr_err("AMD-Vi: Unsupported IVHD type %#x\n", h->type);
+   return -EINVAL;
+   }
+
+   p += ivhd_size;
end += h->length;
 
while (p < end) {
@@ -789,6 +812,7 @@ static int __init init_iommu_from_acpi(struct amd_iommu 
*iommu,
u32 dev_i, ext_flags = 0;
bool alias = false;
struct ivhd_entry *e;
+   u32 ivhd_size;
int ret;
 
 
@@ -804,7 +828,14 @@ static int __init init_iommu_from_acpi(struct amd_iommu 
*iommu,
/*
 * Done. Now parse the device entries
 */
-   p += sizeof(struct ivhd_header);
+   ivhd_size = get_ivhd_header_size(h);
+   if (!ivhd_size) {
+   pr_err("AMD-Vi: Unsupported IVHD type %#x\n", h->type);
+   return -EINVAL;
+   }
+
+   p += ivhd_size;
+
end += h->length;
 
 
-- 
1.9.1

[PATCH V3 9/9] iommu/amd: Set AMD iommu callbacks for amba bus

From: Wan Zongshun 

AMD Uart DMA belongs to ACPI HID type device, and its driver
is basing on AMBA Bus, need also IOMMU support.

This patch is just to set the AMD iommu callbacks for amba bus.

Signed-off-by: Wan Zongshun 
---
 drivers/iommu/amd_iommu.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 713e7ea..c430c10 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2969,7 +2970,17 @@ static struct dma_map_ops amd_iommu_dma_ops = {
 
 int __init amd_iommu_init_api(void)
 {
-   return bus_set_iommu(_bus_type, _iommu_ops);
+   int err = 0;
+
+   err = bus_set_iommu(_bus_type, _iommu_ops);
+   if (err)
+   return err;
+#ifdef CONFIG_ARM_AMBA
+   err = bus_set_iommu(_bustype, _iommu_ops);
+   if (err)
+   return err;
+#endif
+   return 0;
 }
 
 int __init amd_iommu_init_dma_ops(void)
-- 
1.9.1

[PATCH V3 2/9] iommu/amd: Modify ivhd_header structure to support type 11h and 40h

From: Suravee Suthikulpanit 

This patch modifies the existing struct ivhd_header,
which currently only support IVHD type 0x10, to add
new fields from IVHD type 11h and 40h.

It also modifies the pointer calculation to allow
support for IVHD type 11h and 40h

Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu_init.c | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index dff1e01..22e078b 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -398,6 +398,22 @@ static void __init iommu_unmap_mmio_space(struct amd_iommu 
*iommu)
release_mem_region(iommu->mmio_phys, iommu->mmio_phys_end);
 }
 
+static inline u32 get_ivhd_header_size(struct ivhd_header *h)
+{
+   u32 size = 0;
+
+   switch (h->type) {
+   case 0x10:
+   size = 24;
+   break;
+   case 0x11:
+   case 0x40:
+   size = 40;
+   break;
+   }
+   return size;
+}
+
 /
  *
  * The functions below belong to the first pass of AMD IOMMU ACPI table
@@ -424,7 +440,14 @@ static int __init find_last_devid_from_ivhd(struct 
ivhd_header *h)
u8 *p = (void *)h, *end = (void *)h;
struct ivhd_entry *dev;
 
-   p += sizeof(*h);
+   u32 ivhd_size = get_ivhd_header_size(h);
+
+   if (!ivhd_size) {
+   pr_err("AMD-Vi: Unsupported IVHD type %#x\n", h->type);
+   return -EINVAL;
+   }
+
+   p += ivhd_size;
end += h->length;
 
while (p < end) {
@@ -789,6 +812,7 @@ static int __init init_iommu_from_acpi(struct amd_iommu 
*iommu,
u32 dev_i, ext_flags = 0;
bool alias = false;
struct ivhd_entry *e;
+   u32 ivhd_size;
int ret;
 
 
@@ -804,7 +828,14 @@ static int __init init_iommu_from_acpi(struct amd_iommu 
*iommu,
/*
 * Done. Now parse the device entries
 */
-   p += sizeof(struct ivhd_header);
+   ivhd_size = get_ivhd_header_size(h);
+   if (!ivhd_size) {
+   pr_err("AMD-Vi: Unsupported IVHD type %#x\n", h->type);
+   return -EINVAL;
+   }
+
+   p += ivhd_size;
+
end += h->length;
 
 
-- 
1.9.1

[PATCH V3 4/9] iommu/amd: Add new map for storing IVHD dev entry type HID

From: Wan Zongshun 

This patch introduces acpihid_map, which is used to store
the new IVHD device entry extracted from BIOS IVRS table.

It also provides a utility function add_acpi_hid_device(),
to add this types of devices to the map.

Signed-off-by: Wan Zongshun 
Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu.c   |   1 +
 drivers/iommu/amd_iommu_init.c  | 122 
 drivers/iommu/amd_iommu_types.h |  14 +
 3 files changed, 137 insertions(+)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 374c129..d8e59a8 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -72,6 +72,7 @@ static DEFINE_SPINLOCK(dev_data_list_lock);
 
 LIST_HEAD(ioapic_map);
 LIST_HEAD(hpet_map);
+LIST_HEAD(acpihid_map);
 
 /*
  * Domain for untranslated devices - only allocated
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 8f49612..e7ebfa2 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -60,6 +60,10 @@
 #define IVHD_DEV_SPECIAL   0x48
 #define IVHD_DEV_ACPI_HID  0xf0
 
+#define UID_NOT_PRESENT 0
+#define UID_IS_INTEGER  1
+#define UID_IS_CHARACTER2
+
 #define IVHD_SPECIAL_IOAPIC1
 #define IVHD_SPECIAL_HPET  2
 
@@ -116,6 +120,11 @@ struct ivhd_entry {
u16 devid;
u8 flags;
u32 ext;
+   u32 hidh;
+   u64 cid;
+   u8 uidf;
+   u8 uidl;
+   u8 uid;
 } __attribute__((packed));
 
 /*
@@ -224,8 +233,12 @@ enum iommu_init_state {
 #define EARLY_MAP_SIZE 4
 static struct devid_map __initdata early_ioapic_map[EARLY_MAP_SIZE];
 static struct devid_map __initdata early_hpet_map[EARLY_MAP_SIZE];
+static struct acpihid_map_entry __initdata early_acpihid_map[EARLY_MAP_SIZE];
+
 static int __initdata early_ioapic_map_size;
 static int __initdata early_hpet_map_size;
+static int __initdata early_acpihid_map_size;
+
 static bool __initdata cmdline_maps;
 
 static enum iommu_init_state init_state = IOMMU_START_STATE;
@@ -765,6 +778,42 @@ static int __init add_special_device(u8 type, u8 id, u16 
*devid, bool cmd_line)
return 0;
 }
 
+static int __init add_acpi_hid_device(u8 *hid, u8 *uid, u16 *devid,
+ bool cmd_line)
+{
+   struct acpihid_map_entry *entry;
+   struct list_head *list = _map;
+
+   list_for_each_entry(entry, list, list) {
+   if (strcmp(entry->hid, hid) ||
+   (*uid && *entry->uid && strcmp(entry->uid, uid)) ||
+   !entry->cmd_line)
+   continue;
+
+   pr_info("AMD-Vi: Command-line override for hid:%s uid:%s\n",
+   hid, uid);
+   *devid = entry->devid;
+   return 0;
+   }
+
+   entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+   if (!entry)
+   return -ENOMEM;
+
+   memcpy(entry->uid, uid, strlen(uid));
+   memcpy(entry->hid, hid, strlen(hid));
+   entry->devid = *devid;
+   entry->cmd_line = cmd_line;
+   entry->root_devid = (entry->devid & (~0x7));
+
+   pr_info("AMD-Vi:%s, add hid:%s, uid:%s, rdevid:%d\n",
+   entry->cmd_line ? "cmd" : "ivrs",
+   entry->hid, entry->uid, entry->root_devid);
+
+   list_add_tail(>list, list);
+   return 0;
+}
+
 static int __init add_early_maps(void)
 {
int i, ret;
@@ -787,6 +836,15 @@ static int __init add_early_maps(void)
return ret;
}
 
+   for (i = 0; i < early_acpihid_map_size; ++i) {
+   ret = add_acpi_hid_device(early_acpihid_map[i].hid,
+ early_acpihid_map[i].uid,
+ _acpihid_map[i].devid,
+ early_acpihid_map[i].cmd_line);
+   if (ret)
+   return ret;
+   }
+
return 0;
 }
 
@@ -1007,6 +1065,70 @@ static int __init init_iommu_from_acpi(struct amd_iommu 
*iommu,
 
break;
}
+   case IVHD_DEV_ACPI_HID: {
+   u16 devid;
+   u8 hid[ACPIHID_HID_LEN] = {0};
+   u8 uid[ACPIHID_UID_LEN] = {0};
+   int ret;
+
+   if (h->type != 0x40) {
+   pr_err(FW_BUG "Invalid IVHD device type %#x\n",
+  e->type);
+   break;
+   }
+
+   memcpy(hid, (u8 *)(>ext), ACPIHID_HID_LEN - 1);
+   hid[ACPIHID_HID_LEN - 1] = '\0';
+
+   if (!(*hid)) {
+   pr_err(FW_BUG "Invalid HID.\n");
+   break;
+

[PATCH V3 4/9] iommu/amd: Add new map for storing IVHD dev entry type HID

From: Wan Zongshun 

This patch introduces acpihid_map, which is used to store
the new IVHD device entry extracted from BIOS IVRS table.

It also provides a utility function add_acpi_hid_device(),
to add this types of devices to the map.

Signed-off-by: Wan Zongshun 
Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu.c   |   1 +
 drivers/iommu/amd_iommu_init.c  | 122 
 drivers/iommu/amd_iommu_types.h |  14 +
 3 files changed, 137 insertions(+)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 374c129..d8e59a8 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -72,6 +72,7 @@ static DEFINE_SPINLOCK(dev_data_list_lock);
 
 LIST_HEAD(ioapic_map);
 LIST_HEAD(hpet_map);
+LIST_HEAD(acpihid_map);
 
 /*
  * Domain for untranslated devices - only allocated
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 8f49612..e7ebfa2 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -60,6 +60,10 @@
 #define IVHD_DEV_SPECIAL   0x48
 #define IVHD_DEV_ACPI_HID  0xf0
 
+#define UID_NOT_PRESENT 0
+#define UID_IS_INTEGER  1
+#define UID_IS_CHARACTER2
+
 #define IVHD_SPECIAL_IOAPIC1
 #define IVHD_SPECIAL_HPET  2
 
@@ -116,6 +120,11 @@ struct ivhd_entry {
u16 devid;
u8 flags;
u32 ext;
+   u32 hidh;
+   u64 cid;
+   u8 uidf;
+   u8 uidl;
+   u8 uid;
 } __attribute__((packed));
 
 /*
@@ -224,8 +233,12 @@ enum iommu_init_state {
 #define EARLY_MAP_SIZE 4
 static struct devid_map __initdata early_ioapic_map[EARLY_MAP_SIZE];
 static struct devid_map __initdata early_hpet_map[EARLY_MAP_SIZE];
+static struct acpihid_map_entry __initdata early_acpihid_map[EARLY_MAP_SIZE];
+
 static int __initdata early_ioapic_map_size;
 static int __initdata early_hpet_map_size;
+static int __initdata early_acpihid_map_size;
+
 static bool __initdata cmdline_maps;
 
 static enum iommu_init_state init_state = IOMMU_START_STATE;
@@ -765,6 +778,42 @@ static int __init add_special_device(u8 type, u8 id, u16 
*devid, bool cmd_line)
return 0;
 }
 
+static int __init add_acpi_hid_device(u8 *hid, u8 *uid, u16 *devid,
+ bool cmd_line)
+{
+   struct acpihid_map_entry *entry;
+   struct list_head *list = _map;
+
+   list_for_each_entry(entry, list, list) {
+   if (strcmp(entry->hid, hid) ||
+   (*uid && *entry->uid && strcmp(entry->uid, uid)) ||
+   !entry->cmd_line)
+   continue;
+
+   pr_info("AMD-Vi: Command-line override for hid:%s uid:%s\n",
+   hid, uid);
+   *devid = entry->devid;
+   return 0;
+   }
+
+   entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+   if (!entry)
+   return -ENOMEM;
+
+   memcpy(entry->uid, uid, strlen(uid));
+   memcpy(entry->hid, hid, strlen(hid));
+   entry->devid = *devid;
+   entry->cmd_line = cmd_line;
+   entry->root_devid = (entry->devid & (~0x7));
+
+   pr_info("AMD-Vi:%s, add hid:%s, uid:%s, rdevid:%d\n",
+   entry->cmd_line ? "cmd" : "ivrs",
+   entry->hid, entry->uid, entry->root_devid);
+
+   list_add_tail(>list, list);
+   return 0;
+}
+
 static int __init add_early_maps(void)
 {
int i, ret;
@@ -787,6 +836,15 @@ static int __init add_early_maps(void)
return ret;
}
 
+   for (i = 0; i < early_acpihid_map_size; ++i) {
+   ret = add_acpi_hid_device(early_acpihid_map[i].hid,
+ early_acpihid_map[i].uid,
+ _acpihid_map[i].devid,
+ early_acpihid_map[i].cmd_line);
+   if (ret)
+   return ret;
+   }
+
return 0;
 }
 
@@ -1007,6 +1065,70 @@ static int __init init_iommu_from_acpi(struct amd_iommu 
*iommu,
 
break;
}
+   case IVHD_DEV_ACPI_HID: {
+   u16 devid;
+   u8 hid[ACPIHID_HID_LEN] = {0};
+   u8 uid[ACPIHID_UID_LEN] = {0};
+   int ret;
+
+   if (h->type != 0x40) {
+   pr_err(FW_BUG "Invalid IVHD device type %#x\n",
+  e->type);
+   break;
+   }
+
+   memcpy(hid, (u8 *)(>ext), ACPIHID_HID_LEN - 1);
+   hid[ACPIHID_HID_LEN - 1] = '\0';
+
+   if (!(*hid)) {
+   pr_err(FW_BUG "Invalid HID.\n");
+   break;
+   }
+
+   switch (e->uidf) {
+

[PATCH V3 0/9] iommu/amd: enable ACPI hardware ID device support

From: Wan Zongshun 

There are some devices indentified using ACPI HID format in AMD chip.
This patch series enable iommu support for those ACPI HID device, 
since the existing AMD iommu only supports PCI bus based device.

The latest public version of AMD IOMMU specification that describes
the support for IVHD type 40h and ACPI HID IVHD device type, 
implemented by this patch series, is available here:

http://support.amd.com/TechDocs/48882_IOMMU.pdf

The V2 added two new patches: patch 5 and patch 8 according to Joerg's
comments, there is a little modification in patch 6 to distinguish pci
and none pci.

The V3 added the fix for the booting issue Joerg experienced on the CZ
platform due to the IOMMU performance counter init code.

Suravee Suthikulpanit (4):
  iommu/amd: Adding Extended Feature Register check for PC support
  iommu/amd: Modify ivhd_header structure to support type 11h and 40h
  iommu/amd: Use the most comprehensive IVHD type that the driver can
support
  iommu/amd: Introduces ivrs_acpihid kernel parameter

Wan Zongshun (5):
  iommu/amd: Add new map for storing IVHD dev entry type HID
  iommu/amd: Make call-sites of get_device_id aware of its return value
  iommu/amd: Add iommu support for ACPI HID devices
  iommu/amd: Manage iommu_group for ACPI HID devices
  iommu/amd: Set AMD iommu callbacks for amba bus

 Documentation/kernel-parameters.txt |   7 +
 drivers/iommu/amd_iommu.c   | 167 +++---
 drivers/iommu/amd_iommu_init.c  | 329 +++-
 drivers/iommu/amd_iommu_types.h |  14 ++
 4 files changed, 457 insertions(+), 60 deletions(-)

-- 
1.9.1

[PATCH V3 0/9] iommu/amd: enable ACPI hardware ID device support

From: Wan Zongshun 

There are some devices indentified using ACPI HID format in AMD chip.
This patch series enable iommu support for those ACPI HID device, 
since the existing AMD iommu only supports PCI bus based device.

The latest public version of AMD IOMMU specification that describes
the support for IVHD type 40h and ACPI HID IVHD device type, 
implemented by this patch series, is available here:

http://support.amd.com/TechDocs/48882_IOMMU.pdf

The V2 added two new patches: patch 5 and patch 8 according to Joerg's
comments, there is a little modification in patch 6 to distinguish pci
and none pci.

The V3 added the fix for the booting issue Joerg experienced on the CZ
platform due to the IOMMU performance counter init code.

Suravee Suthikulpanit (4):
  iommu/amd: Adding Extended Feature Register check for PC support
  iommu/amd: Modify ivhd_header structure to support type 11h and 40h
  iommu/amd: Use the most comprehensive IVHD type that the driver can
support
  iommu/amd: Introduces ivrs_acpihid kernel parameter

Wan Zongshun (5):
  iommu/amd: Add new map for storing IVHD dev entry type HID
  iommu/amd: Make call-sites of get_device_id aware of its return value
  iommu/amd: Add iommu support for ACPI HID devices
  iommu/amd: Manage iommu_group for ACPI HID devices
  iommu/amd: Set AMD iommu callbacks for amba bus

 Documentation/kernel-parameters.txt |   7 +
 drivers/iommu/amd_iommu.c   | 167 +++---
 drivers/iommu/amd_iommu_init.c  | 329 +++-
 drivers/iommu/amd_iommu_types.h |  14 ++
 4 files changed, 457 insertions(+), 60 deletions(-)

-- 
1.9.1

Re: [PATCH] smp: make wake up idle cpus more generic

Sorry, my fault. I made a typo mistake when sending the patch. I will
fix it and resend the patch.

On Thu, Mar 31, 2016 at 1:24 AM, kbuild test robot <l...@intel.com> wrote:
> Hi Lianwei,
>
> [auto build test ERROR on pm/linux-next]
> [also build test ERROR on v4.6-rc1 next-20160331]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Lianwei-Wang/smp-make-wake-up-idle-cpus-more-generic/20160331-155548
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
> linux-next
> config: i386-randconfig-n0-201613 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
>drivers/cpuidle/cpuidle.c: In function 'cpuidle_latency_notify':
>>> drivers/cpuidle/cpuidle.c:623:37: error: expected ')' before ';' token
>  wake_up_idle_cpus((cpu_online_mask);
> ^
>>> drivers/cpuidle/cpuidle.c:625:1: error: expected ';' before '}' token
> }
> ^
>>> drivers/cpuidle/cpuidle.c:625:1: warning: no return statement in function 
>>> returning non-void [-Wreturn-type]
>
> vim +623 drivers/cpuidle/cpuidle.c
>
>617   * and then recalculate a new suitable C-state. Just do a cross-cpu 
> IPI; that
>618   * wakes them all right up.
>619   */
>620  static int cpuidle_latency_notify(struct notifier_block *b,
>621  unsigned long l, void *v)
>622  {
>  > 623  wake_up_idle_cpus((cpu_online_mask);
>624  return NOTIFY_OK;
>  > 625  }
>626
>627  static struct notifier_block cpuidle_latency_notifier = {
>628  .notifier_call = cpuidle_latency_notify,
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH] smp: make wake up idle cpus more generic

Sorry, my fault. I made a typo mistake when sending the patch. I will
fix it and resend the patch.

On Thu, Mar 31, 2016 at 1:24 AM, kbuild test robot  wrote:
> Hi Lianwei,
>
> [auto build test ERROR on pm/linux-next]
> [also build test ERROR on v4.6-rc1 next-20160331]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Lianwei-Wang/smp-make-wake-up-idle-cpus-more-generic/20160331-155548
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
> linux-next
> config: i386-randconfig-n0-201613 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
>drivers/cpuidle/cpuidle.c: In function 'cpuidle_latency_notify':
>>> drivers/cpuidle/cpuidle.c:623:37: error: expected ')' before ';' token
>  wake_up_idle_cpus((cpu_online_mask);
> ^
>>> drivers/cpuidle/cpuidle.c:625:1: error: expected ';' before '}' token
> }
> ^
>>> drivers/cpuidle/cpuidle.c:625:1: warning: no return statement in function 
>>> returning non-void [-Wreturn-type]
>
> vim +623 drivers/cpuidle/cpuidle.c
>
>617   * and then recalculate a new suitable C-state. Just do a cross-cpu 
> IPI; that
>618   * wakes them all right up.
>619   */
>620  static int cpuidle_latency_notify(struct notifier_block *b,
>621  unsigned long l, void *v)
>622  {
>  > 623  wake_up_idle_cpus((cpu_online_mask);
>624  return NOTIFY_OK;
>  > 625  }
>626
>627  static struct notifier_block cpuidle_latency_notifier = {
>628  .notifier_call = cpuidle_latency_notify,
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: Getting rid of inside_vm in intel8x0

2016-03-31 Thread Takashi Iwai

On Fri, 01 Apr 2016 00:26:18 +0200,
Luis R. Rodriguez wrote:
> 
> On Wed, Mar 30, 2016 at 08:07:04AM +0200, Takashi Iwai wrote:
> > On Tue, 29 Mar 2016 23:37:32 +0200,
> > Andy Lutomirski wrote:
> > > 
> > > Would it be possible to revert:
> > > 
> > > commit 228cf79376f13b98f2e1ac10586311312757675c
> > > Author: Konstantin Ozerkov 
> > > Date:   Wed Oct 26 19:11:01 2011 +0400
> > > 
> > > ALSA: intel8x0: Improve performance in virtual environment
> > > 
> > > Presumably one or more of the following is true:
> > > 
> > > a) The inside_vm == true case is just an optimization and should apply
> > > unconditionally.
> > > 
> > > b) The inside_vm == true case is incorrect and should be fixed or 
> > > disabled.
> > > 
> > > c) The inside_vm == true case is a special case that makes sense then
> > > IO is very very slow but doesn't make sense when IO is fast.  If so,
> > > why not literally measure the time that the IO takes and switch over
> > > to the "inside VM" path when IO is slow?
> 
> BTW can we simulate this on bare metal by throttling an IO bus, or
> perhaps mucking with the scheduler ?
> 
> I ask as I wonder if similar type of optimization may be useful
> to first simulate with other types of buses for other IO devices
> we might use in virtualization environments. If so, I'd be curious
> to know if similar type of optimizations might be possible for
> other sounds cards, or other IO devices.

There aren't so many sound devices requiring such a workaround.

> > More important condition is rather that the register updates of CIV
> > and PICB are atomic.
> 
> To help with this can you perhaps elaborate a bit more on what the code
> does? As I read it snd_intel8x0_pcm_pointer() gets a pointer to some
> sort of audio frame we are in and uses two values to see if we are
> going to be evaluating the right frame, we use an optimization of
> some sort to skip one check for virtual environments. We seem to need
> this given that on a virtual environment it is assumed that the sound
> card is emulated, and as such an IO read there is rather expensive.
> 
> Can you confirm and/or elaborate a bit more what this does ?
> 
> To try to help understand what is going on can you describe what CIV
> and PICB are exactly ?

CIV and PICB registers are a pair and we calculate the linear position
in a ring buffer from both two.  However, they are divorced sometimes
under stress, and the position calculated from such values may go
backward wrongly.  For avoiding it, there is the second read of the
PICB register and compare with the previous value, and loop until it
matches.  This check is skipped on VM.

> > This is satisfied mostly only on VM, and can't
> > be measured easily unlike the IO read speed.
> 
> Interesting, note the original patch claimed it was for KVM and
> Parallels hypervisor only, but since the code uses:
> 
> +#if defined(__i386__) || defined(__x86_64__)
> +   inside_vm = inside_vm || boot_cpu_has(X86_FEATURE_HYPERVISOR);
> +#endif
> 
> This makes it apply also to Xen as well, this makes this hack more
> broad, but does is it only applicable when an emulated device is
> used ? What about if a hypervisor is used and PCI passthrough is
> used ?

A good question.  Xen was added there at the time from positive
results by quick tests, but it might show an issue if it's running on
a very old chip with PCI passthrough.  But I'm not sure whether PCI
passthrough would work on such old chipsets at all.

> > > There are a pile of nonsensical "are we in a VM" checks of various
> > > sorts scattered throughout the kernel, they're all a mess to maintain
> > > (there are lots of kinds of VMs in the world, and Linux may not even
> > > know it's a guest), and, in most cases, it appears that the correct
> > > solution is to delete the checks.  I just removed a nasty one in the
> > > x86_32 entry asm, and this one is written in C so it should be a piece
> > > of cake :)
> > 
> > This cake looks sweet, but a worm is hidden behind the cream.
> > The loop in the code itself is already a kludge for the buggy hardware
> > where the inconsistent read happens not so often (only at the boundary
> > and in a racy way).  It would be nice if we can have a more reliably
> > way to know the hardware buggyness, but it's difficult,
> > unsurprisingly.
> 
> The concern here is setting precedents for VM cases sprinkled in the kernel.
> The assumption here is such special cases are really paper'ing over another
> type of issue, so its best to ultimately try to root cause the issue in
> a more generalized fashion.
 
Well, it's rather bare metal that shows the buggy behavior, thus we
need to paper over it.   In that sense, it's other way round; we don't
tune for VM.  The VM check we're discussing is rather for skipping the
strange workaround.

You may ask whether we can reduce the whole workaround instead.  It's
practically impossible.  We don't know which models doing so and which
not.  And, the

Re: Getting rid of inside_vm in intel8x0

2016-03-31 Thread Takashi Iwai

On Fri, 01 Apr 2016 00:26:18 +0200,
Luis R. Rodriguez wrote:
> 
> On Wed, Mar 30, 2016 at 08:07:04AM +0200, Takashi Iwai wrote:
> > On Tue, 29 Mar 2016 23:37:32 +0200,
> > Andy Lutomirski wrote:
> > > 
> > > Would it be possible to revert:
> > > 
> > > commit 228cf79376f13b98f2e1ac10586311312757675c
> > > Author: Konstantin Ozerkov 
> > > Date:   Wed Oct 26 19:11:01 2011 +0400
> > > 
> > > ALSA: intel8x0: Improve performance in virtual environment
> > > 
> > > Presumably one or more of the following is true:
> > > 
> > > a) The inside_vm == true case is just an optimization and should apply
> > > unconditionally.
> > > 
> > > b) The inside_vm == true case is incorrect and should be fixed or 
> > > disabled.
> > > 
> > > c) The inside_vm == true case is a special case that makes sense then
> > > IO is very very slow but doesn't make sense when IO is fast.  If so,
> > > why not literally measure the time that the IO takes and switch over
> > > to the "inside VM" path when IO is slow?
> 
> BTW can we simulate this on bare metal by throttling an IO bus, or
> perhaps mucking with the scheduler ?
> 
> I ask as I wonder if similar type of optimization may be useful
> to first simulate with other types of buses for other IO devices
> we might use in virtualization environments. If so, I'd be curious
> to know if similar type of optimizations might be possible for
> other sounds cards, or other IO devices.

There aren't so many sound devices requiring such a workaround.

> > More important condition is rather that the register updates of CIV
> > and PICB are atomic.
> 
> To help with this can you perhaps elaborate a bit more on what the code
> does? As I read it snd_intel8x0_pcm_pointer() gets a pointer to some
> sort of audio frame we are in and uses two values to see if we are
> going to be evaluating the right frame, we use an optimization of
> some sort to skip one check for virtual environments. We seem to need
> this given that on a virtual environment it is assumed that the sound
> card is emulated, and as such an IO read there is rather expensive.
> 
> Can you confirm and/or elaborate a bit more what this does ?
> 
> To try to help understand what is going on can you describe what CIV
> and PICB are exactly ?

CIV and PICB registers are a pair and we calculate the linear position
in a ring buffer from both two.  However, they are divorced sometimes
under stress, and the position calculated from such values may go
backward wrongly.  For avoiding it, there is the second read of the
PICB register and compare with the previous value, and loop until it
matches.  This check is skipped on VM.

> > This is satisfied mostly only on VM, and can't
> > be measured easily unlike the IO read speed.
> 
> Interesting, note the original patch claimed it was for KVM and
> Parallels hypervisor only, but since the code uses:
> 
> +#if defined(__i386__) || defined(__x86_64__)
> +   inside_vm = inside_vm || boot_cpu_has(X86_FEATURE_HYPERVISOR);
> +#endif
> 
> This makes it apply also to Xen as well, this makes this hack more
> broad, but does is it only applicable when an emulated device is
> used ? What about if a hypervisor is used and PCI passthrough is
> used ?

A good question.  Xen was added there at the time from positive
results by quick tests, but it might show an issue if it's running on
a very old chip with PCI passthrough.  But I'm not sure whether PCI
passthrough would work on such old chipsets at all.

> > > There are a pile of nonsensical "are we in a VM" checks of various
> > > sorts scattered throughout the kernel, they're all a mess to maintain
> > > (there are lots of kinds of VMs in the world, and Linux may not even
> > > know it's a guest), and, in most cases, it appears that the correct
> > > solution is to delete the checks.  I just removed a nasty one in the
> > > x86_32 entry asm, and this one is written in C so it should be a piece
> > > of cake :)
> > 
> > This cake looks sweet, but a worm is hidden behind the cream.
> > The loop in the code itself is already a kludge for the buggy hardware
> > where the inconsistent read happens not so often (only at the boundary
> > and in a racy way).  It would be nice if we can have a more reliably
> > way to know the hardware buggyness, but it's difficult,
> > unsurprisingly.
> 
> The concern here is setting precedents for VM cases sprinkled in the kernel.
> The assumption here is such special cases are really paper'ing over another
> type of issue, so its best to ultimately try to root cause the issue in
> a more generalized fashion.
 
Well, it's rather bare metal that shows the buggy behavior, thus we
need to paper over it.   In that sense, it's other way round; we don't
tune for VM.  The VM check we're discussing is rather for skipping the
strange workaround.

You may ask whether we can reduce the whole workaround instead.  It's
practically impossible.  We don't know which models doing so and which
not.  And, the hardware in question are

[PATCH V3 5/9] iommu/amd: Introduces ivrs_acpihid kernel parameter

From: Suravee Suthikulpanit 

This patch introduces a new kernel parameter, ivrs_acpihid.
This is used to override existing ACPI-HID IVHD device entry,
or add an entry in case it is missing in the IVHD.

Signed-off-by: Wan Zongshun 
Signed-off-by: Suravee Suthikulpanit 
---
 Documentation/kernel-parameters.txt |  7 +++
 drivers/iommu/amd_iommu_init.c  | 33 +
 2 files changed, 40 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index ecc74fa..8c881a5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1767,6 +1767,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
PCI device 00:14.0 write the parameter as:
ivrs_hpet[0]=00:14.0
 
+   ivrs_acpihid[HW,X86_64]
+   Provide an override to the ACPI-HID:UID<->DEVICE-ID
+   mapping provided in the IVRS ACPI table. For
+   example, to map UART-HID:UID AMD0020:0 to
+   PCI device 00:14.5 write the parameter as:
+   ivrs_acpihid[00:14.5]=AMD0020:0
+
js= [HW,JOY] Analog joystick
See Documentation/input/joystick.txt.
 
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index e7ebfa2..9e00341 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2477,10 +2477,43 @@ static int __init parse_ivrs_hpet(char *str)
return 1;
 }
 
+static int __init parse_ivrs_acpihid(char *str)
+{
+   u32 bus, dev, fn;
+   char *hid, *uid, *p;
+   char acpiid[ACPIHID_UID_LEN + ACPIHID_HID_LEN] = {0};
+   int ret, i;
+
+   ret = sscanf(str, "[%x:%x.%x]=%s", , , , acpiid);
+   if (ret != 4) {
+   pr_err("AMD-Vi: Invalid command line: ivrs_acpihid(%s)\n", str);
+   return 1;
+   }
+
+   p = acpiid;
+   hid = strsep(, ":");
+   uid = p;
+
+   if (!hid || !(*hid) || !uid) {
+   pr_err("AMD-Vi: Invalid command line: hid or uid\n");
+   return 1;
+   }
+
+   i = early_acpihid_map_size++;
+   memcpy(early_acpihid_map[i].hid, hid, strlen(hid));
+   memcpy(early_acpihid_map[i].uid, uid, strlen(uid));
+   early_acpihid_map[i].devid =
+   ((bus & 0xff) << 8) | ((dev & 0x1f) << 3) | (fn & 0x7);
+   early_acpihid_map[i].cmd_line   = true;
+
+   return 1;
+}
+
 __setup("amd_iommu_dump",  parse_amd_iommu_dump);
 __setup("amd_iommu=",  parse_amd_iommu_options);
 __setup("ivrs_ioapic", parse_ivrs_ioapic);
 __setup("ivrs_hpet",   parse_ivrs_hpet);
+__setup("ivrs_acpihid",parse_ivrs_acpihid);
 
 IOMMU_INIT_FINISH(amd_iommu_detect,
  gart_iommu_hole_init,
-- 
1.9.1

[PATCH V3 7/9] iommu/amd: Add iommu support for ACPI HID devices

From: Wan Zongshun 

Current IOMMU driver make assumption that the downstream devices are PCI.
With the newly added ACPI-HID IVHD device entry support, this is no
longer true. This patch is to add dev type check and to distinguish the
pci and acpihid device code path.

Signed-off-by: Wan Zongshun 
Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu.c | 69 ---
 1 file changed, 60 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 400867f..0df651a3 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -216,13 +217,60 @@ static struct iommu_dev_data *find_dev_data(u16 devid)
return dev_data;
 }
 
-static inline u16 get_device_id(struct device *dev)
+static inline int match_hid_uid(struct device *dev,
+   struct acpihid_map_entry *entry)
+{
+   const char *hid, *uid;
+
+   hid = acpi_device_hid(ACPI_COMPANION(dev));
+   uid = acpi_device_uid(ACPI_COMPANION(dev));
+
+   if (!hid || !(*hid))
+   return -ENODEV;
+
+   if (!uid || !(*uid))
+   return strcmp(hid, entry->hid);
+
+   if (!(*entry->uid))
+   return strcmp(hid, entry->hid);
+
+   return (strcmp(hid, entry->hid) || strcmp(uid, entry->uid));
+}
+
+static inline u16 get_pci_device_id(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
 
return PCI_DEVID(pdev->bus->number, pdev->devfn);
 }
 
+static inline int get_acpihid_device_id(struct device *dev,
+   struct acpihid_map_entry **entry)
+{
+   struct acpihid_map_entry *p;
+
+   list_for_each_entry(p, _map, list) {
+   if (!match_hid_uid(dev, p)) {
+   if (entry)
+   *entry = p;
+   return p->devid;
+   }
+   }
+   return -EINVAL;
+}
+
+static inline int get_device_id(struct device *dev)
+{
+   int devid;
+
+   if (dev_is_pci(dev))
+   devid = get_pci_device_id(dev);
+   else
+   devid = get_acpihid_device_id(dev, NULL);
+
+   return devid;
+}
+
 static struct iommu_dev_data *get_dev_data(struct device *dev)
 {
return dev->archdata.iommu;
@@ -303,10 +351,6 @@ static bool check_device(struct device *dev)
if (!dev || !dev->dma_mask)
return false;
 
-   /* No PCI device */
-   if (!dev_is_pci(dev))
-   return false;
-
devid = get_device_id(dev);
if (IS_ERR_VALUE(devid))
return false;
@@ -344,7 +388,6 @@ out:
 
 static int iommu_init_device(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
struct iommu_dev_data *dev_data;
int devid;
 
@@ -359,10 +402,10 @@ static int iommu_init_device(struct device *dev)
if (!dev_data)
return -ENOMEM;
 
-   if (pci_iommuv2_capable(pdev)) {
+   if (dev_is_pci(dev) && pci_iommuv2_capable(to_pci_dev(dev))) {
struct amd_iommu *iommu;
 
-   iommu  = amd_iommu_rlookup_table[dev_data->devid];
+   iommu = amd_iommu_rlookup_table[dev_data->devid];
dev_data->iommu_v2 = iommu->is_iommu_v2;
}
 
@@ -2239,13 +2282,17 @@ static bool pci_pri_tlp_required(struct pci_dev *pdev)
 static int attach_device(struct device *dev,
 struct protection_domain *domain)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
+   struct pci_dev *pdev;
struct iommu_dev_data *dev_data;
unsigned long flags;
int ret;
 
dev_data = get_dev_data(dev);
 
+   if (!dev_is_pci(dev))
+   goto skip_ats_check;
+
+   pdev = to_pci_dev(dev);
if (domain->flags & PD_IOMMUV2_MASK) {
if (!dev_data->passthrough)
return -EINVAL;
@@ -2264,6 +2311,7 @@ static int attach_device(struct device *dev,
dev_data->ats.qdep= pci_ats_queue_depth(pdev);
}
 
+skip_ats_check:
write_lock_irqsave(_iommu_devtable_lock, flags);
ret = __attach_device(dev_data, domain);
write_unlock_irqrestore(_iommu_devtable_lock, flags);
@@ -2320,6 +2368,9 @@ static void detach_device(struct device *dev)
__detach_device(dev_data);
write_unlock_irqrestore(_iommu_devtable_lock, flags);
 
+   if (!dev_is_pci(dev))
+   return;
+
if (domain->flags & PD_IOMMUV2_MASK && dev_data->iommu_v2)
pdev_iommuv2_disable(to_pci_dev(dev));
else if (dev_data->ats.enabled)
-- 
1.9.1

[PATCH V3 6/9] iommu/amd: Make call-sites of get_device_id aware of its return value

From: Wan Zongshun 

This patch is to make the call-sites of get_device_id aware of its
return value.

Signed-off-by: Wan Zongshun 
---
 drivers/iommu/amd_iommu.c | 51 +--
 1 file changed, 41 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index d8e59a8..400867f 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -279,9 +279,11 @@ static void init_unity_mappings_for_device(struct device 
*dev,
   struct dma_ops_domain *dma_dom)
 {
struct unity_map_entry *e;
-   u16 devid;
+   int devid;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
 
list_for_each_entry(e, _iommu_unity_map, list) {
if (!(devid >= e->devid_start && devid <= e->devid_end))
@@ -296,7 +298,7 @@ static void init_unity_mappings_for_device(struct device 
*dev,
  */
 static bool check_device(struct device *dev)
 {
-   u16 devid;
+   int devid;
 
if (!dev || !dev->dma_mask)
return false;
@@ -306,6 +308,8 @@ static bool check_device(struct device *dev)
return false;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return false;
 
/* Out of our scope? */
if (devid > amd_iommu_last_bdf)
@@ -342,11 +346,16 @@ static int iommu_init_device(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct iommu_dev_data *dev_data;
+   int devid;
 
if (dev->archdata.iommu)
return 0;
 
-   dev_data = find_dev_data(get_device_id(dev));
+   devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return devid;
+
+   dev_data = find_dev_data(devid);
if (!dev_data)
return -ENOMEM;
 
@@ -367,9 +376,13 @@ static int iommu_init_device(struct device *dev)
 
 static void iommu_ignore_device(struct device *dev)
 {
-   u16 devid, alias;
+   u16 alias;
+   int devid;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
+
alias = amd_iommu_alias_table[devid];
 
memset(_iommu_dev_table[devid], 0, sizeof(struct dev_table_entry));
@@ -381,8 +394,14 @@ static void iommu_ignore_device(struct device *dev)
 
 static void iommu_uninit_device(struct device *dev)
 {
-   struct iommu_dev_data *dev_data = search_dev_data(get_device_id(dev));
+   int devid;
+   struct iommu_dev_data *dev_data;
+
+   devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
 
+   dev_data = search_dev_data(devid);
if (!dev_data)
return;
 
@@ -2314,13 +2333,15 @@ static int amd_iommu_add_device(struct device *dev)
struct iommu_dev_data *dev_data;
struct iommu_domain *domain;
struct amd_iommu *iommu;
-   u16 devid;
-   int ret;
+   int ret, devid;
 
if (!check_device(dev) || get_dev_data(dev))
return 0;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return devid;
+
iommu = amd_iommu_rlookup_table[devid];
 
ret = iommu_init_device(dev);
@@ -2358,12 +2379,15 @@ out:
 static void amd_iommu_remove_device(struct device *dev)
 {
struct amd_iommu *iommu;
-   u16 devid;
+   int devid;
 
if (!check_device(dev))
return;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
+
iommu = amd_iommu_rlookup_table[devid];
 
iommu_uninit_device(dev);
@@ -3035,12 +3059,14 @@ static void amd_iommu_detach_device(struct iommu_domain 
*dom,
 {
struct iommu_dev_data *dev_data = dev->archdata.iommu;
struct amd_iommu *iommu;
-   u16 devid;
+   int devid;
 
if (!check_device(dev))
return;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
 
if (dev_data->domain != NULL)
detach_device(dev);
@@ -3158,9 +3184,11 @@ static void amd_iommu_get_dm_regions(struct device *dev,
 struct list_head *head)
 {
struct unity_map_entry *entry;
-   u16 devid;
+   int devid;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
 
list_for_each_entry(entry, _iommu_unity_map, list) {
struct iommu_dm_region *region;
@@ -3862,6 +3890,9 @@ static struct irq_domain *get_irq_domain(struct 
irq_alloc_info *info)
case X86_IRQ_ALLOC_TYPE_MSI:
case X86_IRQ_ALLOC_TYPE_MSIX:
devid = get_device_id(>msi_dev->dev);
+   if (IS_ERR_VALUE(devid))
+   return NULL;
+
iommu = amd_iommu_rlookup_table[devid];
if

[PATCH V3 5/9] iommu/amd: Introduces ivrs_acpihid kernel parameter

From: Suravee Suthikulpanit 

This patch introduces a new kernel parameter, ivrs_acpihid.
This is used to override existing ACPI-HID IVHD device entry,
or add an entry in case it is missing in the IVHD.

Signed-off-by: Wan Zongshun 
Signed-off-by: Suravee Suthikulpanit 
---
 Documentation/kernel-parameters.txt |  7 +++
 drivers/iommu/amd_iommu_init.c  | 33 +
 2 files changed, 40 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index ecc74fa..8c881a5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1767,6 +1767,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
PCI device 00:14.0 write the parameter as:
ivrs_hpet[0]=00:14.0
 
+   ivrs_acpihid[HW,X86_64]
+   Provide an override to the ACPI-HID:UID<->DEVICE-ID
+   mapping provided in the IVRS ACPI table. For
+   example, to map UART-HID:UID AMD0020:0 to
+   PCI device 00:14.5 write the parameter as:
+   ivrs_acpihid[00:14.5]=AMD0020:0
+
js= [HW,JOY] Analog joystick
See Documentation/input/joystick.txt.
 
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index e7ebfa2..9e00341 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2477,10 +2477,43 @@ static int __init parse_ivrs_hpet(char *str)
return 1;
 }
 
+static int __init parse_ivrs_acpihid(char *str)
+{
+   u32 bus, dev, fn;
+   char *hid, *uid, *p;
+   char acpiid[ACPIHID_UID_LEN + ACPIHID_HID_LEN] = {0};
+   int ret, i;
+
+   ret = sscanf(str, "[%x:%x.%x]=%s", , , , acpiid);
+   if (ret != 4) {
+   pr_err("AMD-Vi: Invalid command line: ivrs_acpihid(%s)\n", str);
+   return 1;
+   }
+
+   p = acpiid;
+   hid = strsep(, ":");
+   uid = p;
+
+   if (!hid || !(*hid) || !uid) {
+   pr_err("AMD-Vi: Invalid command line: hid or uid\n");
+   return 1;
+   }
+
+   i = early_acpihid_map_size++;
+   memcpy(early_acpihid_map[i].hid, hid, strlen(hid));
+   memcpy(early_acpihid_map[i].uid, uid, strlen(uid));
+   early_acpihid_map[i].devid =
+   ((bus & 0xff) << 8) | ((dev & 0x1f) << 3) | (fn & 0x7);
+   early_acpihid_map[i].cmd_line   = true;
+
+   return 1;
+}
+
 __setup("amd_iommu_dump",  parse_amd_iommu_dump);
 __setup("amd_iommu=",  parse_amd_iommu_options);
 __setup("ivrs_ioapic", parse_ivrs_ioapic);
 __setup("ivrs_hpet",   parse_ivrs_hpet);
+__setup("ivrs_acpihid",parse_ivrs_acpihid);
 
 IOMMU_INIT_FINISH(amd_iommu_detect,
  gart_iommu_hole_init,
-- 
1.9.1

[PATCH V3 7/9] iommu/amd: Add iommu support for ACPI HID devices

From: Wan Zongshun 

Current IOMMU driver make assumption that the downstream devices are PCI.
With the newly added ACPI-HID IVHD device entry support, this is no
longer true. This patch is to add dev type check and to distinguish the
pci and acpihid device code path.

Signed-off-by: Wan Zongshun 
Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu.c | 69 ---
 1 file changed, 60 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 400867f..0df651a3 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -216,13 +217,60 @@ static struct iommu_dev_data *find_dev_data(u16 devid)
return dev_data;
 }
 
-static inline u16 get_device_id(struct device *dev)
+static inline int match_hid_uid(struct device *dev,
+   struct acpihid_map_entry *entry)
+{
+   const char *hid, *uid;
+
+   hid = acpi_device_hid(ACPI_COMPANION(dev));
+   uid = acpi_device_uid(ACPI_COMPANION(dev));
+
+   if (!hid || !(*hid))
+   return -ENODEV;
+
+   if (!uid || !(*uid))
+   return strcmp(hid, entry->hid);
+
+   if (!(*entry->uid))
+   return strcmp(hid, entry->hid);
+
+   return (strcmp(hid, entry->hid) || strcmp(uid, entry->uid));
+}
+
+static inline u16 get_pci_device_id(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
 
return PCI_DEVID(pdev->bus->number, pdev->devfn);
 }
 
+static inline int get_acpihid_device_id(struct device *dev,
+   struct acpihid_map_entry **entry)
+{
+   struct acpihid_map_entry *p;
+
+   list_for_each_entry(p, _map, list) {
+   if (!match_hid_uid(dev, p)) {
+   if (entry)
+   *entry = p;
+   return p->devid;
+   }
+   }
+   return -EINVAL;
+}
+
+static inline int get_device_id(struct device *dev)
+{
+   int devid;
+
+   if (dev_is_pci(dev))
+   devid = get_pci_device_id(dev);
+   else
+   devid = get_acpihid_device_id(dev, NULL);
+
+   return devid;
+}
+
 static struct iommu_dev_data *get_dev_data(struct device *dev)
 {
return dev->archdata.iommu;
@@ -303,10 +351,6 @@ static bool check_device(struct device *dev)
if (!dev || !dev->dma_mask)
return false;
 
-   /* No PCI device */
-   if (!dev_is_pci(dev))
-   return false;
-
devid = get_device_id(dev);
if (IS_ERR_VALUE(devid))
return false;
@@ -344,7 +388,6 @@ out:
 
 static int iommu_init_device(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
struct iommu_dev_data *dev_data;
int devid;
 
@@ -359,10 +402,10 @@ static int iommu_init_device(struct device *dev)
if (!dev_data)
return -ENOMEM;
 
-   if (pci_iommuv2_capable(pdev)) {
+   if (dev_is_pci(dev) && pci_iommuv2_capable(to_pci_dev(dev))) {
struct amd_iommu *iommu;
 
-   iommu  = amd_iommu_rlookup_table[dev_data->devid];
+   iommu = amd_iommu_rlookup_table[dev_data->devid];
dev_data->iommu_v2 = iommu->is_iommu_v2;
}
 
@@ -2239,13 +2282,17 @@ static bool pci_pri_tlp_required(struct pci_dev *pdev)
 static int attach_device(struct device *dev,
 struct protection_domain *domain)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
+   struct pci_dev *pdev;
struct iommu_dev_data *dev_data;
unsigned long flags;
int ret;
 
dev_data = get_dev_data(dev);
 
+   if (!dev_is_pci(dev))
+   goto skip_ats_check;
+
+   pdev = to_pci_dev(dev);
if (domain->flags & PD_IOMMUV2_MASK) {
if (!dev_data->passthrough)
return -EINVAL;
@@ -2264,6 +2311,7 @@ static int attach_device(struct device *dev,
dev_data->ats.qdep= pci_ats_queue_depth(pdev);
}
 
+skip_ats_check:
write_lock_irqsave(_iommu_devtable_lock, flags);
ret = __attach_device(dev_data, domain);
write_unlock_irqrestore(_iommu_devtable_lock, flags);
@@ -2320,6 +2368,9 @@ static void detach_device(struct device *dev)
__detach_device(dev_data);
write_unlock_irqrestore(_iommu_devtable_lock, flags);
 
+   if (!dev_is_pci(dev))
+   return;
+
if (domain->flags & PD_IOMMUV2_MASK && dev_data->iommu_v2)
pdev_iommuv2_disable(to_pci_dev(dev));
else if (dev_data->ats.enabled)
-- 
1.9.1

[PATCH V3 6/9] iommu/amd: Make call-sites of get_device_id aware of its return value

From: Wan Zongshun 

This patch is to make the call-sites of get_device_id aware of its
return value.

Signed-off-by: Wan Zongshun 
---
 drivers/iommu/amd_iommu.c | 51 +--
 1 file changed, 41 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index d8e59a8..400867f 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -279,9 +279,11 @@ static void init_unity_mappings_for_device(struct device 
*dev,
   struct dma_ops_domain *dma_dom)
 {
struct unity_map_entry *e;
-   u16 devid;
+   int devid;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
 
list_for_each_entry(e, _iommu_unity_map, list) {
if (!(devid >= e->devid_start && devid <= e->devid_end))
@@ -296,7 +298,7 @@ static void init_unity_mappings_for_device(struct device 
*dev,
  */
 static bool check_device(struct device *dev)
 {
-   u16 devid;
+   int devid;
 
if (!dev || !dev->dma_mask)
return false;
@@ -306,6 +308,8 @@ static bool check_device(struct device *dev)
return false;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return false;
 
/* Out of our scope? */
if (devid > amd_iommu_last_bdf)
@@ -342,11 +346,16 @@ static int iommu_init_device(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct iommu_dev_data *dev_data;
+   int devid;
 
if (dev->archdata.iommu)
return 0;
 
-   dev_data = find_dev_data(get_device_id(dev));
+   devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return devid;
+
+   dev_data = find_dev_data(devid);
if (!dev_data)
return -ENOMEM;
 
@@ -367,9 +376,13 @@ static int iommu_init_device(struct device *dev)
 
 static void iommu_ignore_device(struct device *dev)
 {
-   u16 devid, alias;
+   u16 alias;
+   int devid;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
+
alias = amd_iommu_alias_table[devid];
 
memset(_iommu_dev_table[devid], 0, sizeof(struct dev_table_entry));
@@ -381,8 +394,14 @@ static void iommu_ignore_device(struct device *dev)
 
 static void iommu_uninit_device(struct device *dev)
 {
-   struct iommu_dev_data *dev_data = search_dev_data(get_device_id(dev));
+   int devid;
+   struct iommu_dev_data *dev_data;
+
+   devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
 
+   dev_data = search_dev_data(devid);
if (!dev_data)
return;
 
@@ -2314,13 +2333,15 @@ static int amd_iommu_add_device(struct device *dev)
struct iommu_dev_data *dev_data;
struct iommu_domain *domain;
struct amd_iommu *iommu;
-   u16 devid;
-   int ret;
+   int ret, devid;
 
if (!check_device(dev) || get_dev_data(dev))
return 0;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return devid;
+
iommu = amd_iommu_rlookup_table[devid];
 
ret = iommu_init_device(dev);
@@ -2358,12 +2379,15 @@ out:
 static void amd_iommu_remove_device(struct device *dev)
 {
struct amd_iommu *iommu;
-   u16 devid;
+   int devid;
 
if (!check_device(dev))
return;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
+
iommu = amd_iommu_rlookup_table[devid];
 
iommu_uninit_device(dev);
@@ -3035,12 +3059,14 @@ static void amd_iommu_detach_device(struct iommu_domain 
*dom,
 {
struct iommu_dev_data *dev_data = dev->archdata.iommu;
struct amd_iommu *iommu;
-   u16 devid;
+   int devid;
 
if (!check_device(dev))
return;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
 
if (dev_data->domain != NULL)
detach_device(dev);
@@ -3158,9 +3184,11 @@ static void amd_iommu_get_dm_regions(struct device *dev,
 struct list_head *head)
 {
struct unity_map_entry *entry;
-   u16 devid;
+   int devid;
 
devid = get_device_id(dev);
+   if (IS_ERR_VALUE(devid))
+   return;
 
list_for_each_entry(entry, _iommu_unity_map, list) {
struct iommu_dm_region *region;
@@ -3862,6 +3890,9 @@ static struct irq_domain *get_irq_domain(struct 
irq_alloc_info *info)
case X86_IRQ_ALLOC_TYPE_MSI:
case X86_IRQ_ALLOC_TYPE_MSIX:
devid = get_device_id(>msi_dev->dev);
+   if (IS_ERR_VALUE(devid))
+   return NULL;
+
iommu = amd_iommu_rlookup_table[devid];
if (iommu)
return

[PATCH V3 8/9] iommu/amd: Manage iommu_group for ACPI HID devices

From: Wan Zongshun 

This patch creates a new function for finding or creating an IOMMU
group for acpihid(ACPI Hardware ID) device.

The acpihid devices with the same devid will be put into same group and
there will have the same domain id and share the same page table.

Signed-off-by: Wan Zongshun 
---
 drivers/iommu/amd_iommu.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 0df651a3..713e7ea 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -276,6 +276,29 @@ static struct iommu_dev_data *get_dev_data(struct device 
*dev)
return dev->archdata.iommu;
 }
 
+/*
+* Find or create an IOMMU group for a acpihid device.
+*/
+static struct iommu_group *acpihid_device_group(struct device *dev)
+{
+   struct acpihid_map_entry *p, *entry = NULL;
+   u16 devid;
+
+   devid = get_acpihid_device_id(dev, );
+   if (devid < 0)
+   return ERR_PTR(devid);
+
+   list_for_each_entry(p, _map, list) {
+   if ((devid == p->devid) && p->group)
+   entry->group = p->group;
+   }
+
+   if (!entry->group)
+   entry->group = generic_device_group(dev);
+
+   return entry->group;
+}
+
 static bool pci_iommuv2_capable(struct pci_dev *pdev)
 {
static const int caps[] = {
@@ -2445,6 +2468,14 @@ static void amd_iommu_remove_device(struct device *dev)
iommu_completion_wait(iommu);
 }
 
+static struct iommu_group *amd_iommu_device_group(struct device *dev)
+{
+   if (dev_is_pci(dev))
+   return pci_device_group(dev);
+
+   return acpihid_device_group(dev);
+}
+
 /*
  *
  * The next functions belong to the dma_ops mapping/unmapping code.
@@ -3286,7 +3317,7 @@ static const struct iommu_ops amd_iommu_ops = {
.iova_to_phys = amd_iommu_iova_to_phys,
.add_device = amd_iommu_add_device,
.remove_device = amd_iommu_remove_device,
-   .device_group = pci_device_group,
+   .device_group = amd_iommu_device_group,
.get_dm_regions = amd_iommu_get_dm_regions,
.put_dm_regions = amd_iommu_put_dm_regions,
.pgsize_bitmap  = AMD_IOMMU_PGSIZES,
-- 
1.9.1

[PATCH V3 8/9] iommu/amd: Manage iommu_group for ACPI HID devices

From: Wan Zongshun 

This patch creates a new function for finding or creating an IOMMU
group for acpihid(ACPI Hardware ID) device.

The acpihid devices with the same devid will be put into same group and
there will have the same domain id and share the same page table.

Signed-off-by: Wan Zongshun 
---
 drivers/iommu/amd_iommu.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 0df651a3..713e7ea 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -276,6 +276,29 @@ static struct iommu_dev_data *get_dev_data(struct device 
*dev)
return dev->archdata.iommu;
 }
 
+/*
+* Find or create an IOMMU group for a acpihid device.
+*/
+static struct iommu_group *acpihid_device_group(struct device *dev)
+{
+   struct acpihid_map_entry *p, *entry = NULL;
+   u16 devid;
+
+   devid = get_acpihid_device_id(dev, );
+   if (devid < 0)
+   return ERR_PTR(devid);
+
+   list_for_each_entry(p, _map, list) {
+   if ((devid == p->devid) && p->group)
+   entry->group = p->group;
+   }
+
+   if (!entry->group)
+   entry->group = generic_device_group(dev);
+
+   return entry->group;
+}
+
 static bool pci_iommuv2_capable(struct pci_dev *pdev)
 {
static const int caps[] = {
@@ -2445,6 +2468,14 @@ static void amd_iommu_remove_device(struct device *dev)
iommu_completion_wait(iommu);
 }
 
+static struct iommu_group *amd_iommu_device_group(struct device *dev)
+{
+   if (dev_is_pci(dev))
+   return pci_device_group(dev);
+
+   return acpihid_device_group(dev);
+}
+
 /*
  *
  * The next functions belong to the dma_ops mapping/unmapping code.
@@ -3286,7 +3317,7 @@ static const struct iommu_ops amd_iommu_ops = {
.iova_to_phys = amd_iommu_iova_to_phys,
.add_device = amd_iommu_add_device,
.remove_device = amd_iommu_remove_device,
-   .device_group = pci_device_group,
+   .device_group = amd_iommu_device_group,
.get_dm_regions = amd_iommu_get_dm_regions,
.put_dm_regions = amd_iommu_put_dm_regions,
.pgsize_bitmap  = AMD_IOMMU_PGSIZES,
-- 
1.9.1

[PATCH V3 3/9] iommu/amd: Use the most comprehensive IVHD type that the driver can support

From: Suravee Suthikulpanit 

The IVRS in more recent AMD system usually contains multiple
IVHD block types (e.g. 0x10, 0x11, and 0x40) for each IOMMU.
The newer IVHD types provide more information (e.g. new features
specified in the IOMMU spec), while maintain compatibility with
the older IVHD type.

Having multiple IVHD type allows older IOMMU drivers to still function
(e.g. using the older IVHD type 0x10) while the newer IOMMU driver can use
the newer IVHD types (e.g. 0x11 and 0x40). Therefore, the IOMMU driver
should only make use of the newest IVHD type that it can support.

This patch adds new logic to determine the highest level of IVHD type
it can support, and use it throughout the to initialize the driver.
This requires adding another pass to the IVRS parsing to determine
appropriate IVHD type (see function get_highest_supported_ivhd_type())
before parsing the contents.

[Vincent: fix the build error of IVHD_DEV_ACPI_HID flag not found]

Signed-off-by: Wan Zongshun 
Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu_init.c | 107 ++---
 1 file changed, 78 insertions(+), 29 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 22e078b..8f49612 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -44,7 +44,7 @@
  */
 #define IVRS_HEADER_LENGTH 48
 
-#define ACPI_IVHD_TYPE  0x10
+#define ACPI_IVHD_TYPE_MAX_SUPPORTED   0x40
 #define ACPI_IVMD_TYPE_ALL  0x20
 #define ACPI_IVMD_TYPE  0x21
 #define ACPI_IVMD_TYPE_RANGE0x22
@@ -58,6 +58,7 @@
 #define IVHD_DEV_EXT_SELECT 0x46
 #define IVHD_DEV_EXT_SELECT_RANGE   0x47
 #define IVHD_DEV_SPECIAL   0x48
+#define IVHD_DEV_ACPI_HID  0xf0
 
 #define IVHD_SPECIAL_IOAPIC1
 #define IVHD_SPECIAL_HPET  2
@@ -137,6 +138,7 @@ bool amd_iommu_irq_remap __read_mostly;
 
 static bool amd_iommu_detected;
 static bool __initdata amd_iommu_disabled;
+static int amd_iommu_target_ivhd_type;
 
 u16 amd_iommu_last_bdf;/* largest PCI device id we have
   to handle */
@@ -428,7 +430,15 @@ static inline u32 get_ivhd_header_size(struct ivhd_header 
*h)
  */
 static inline int ivhd_entry_length(u8 *ivhd)
 {
-   return 0x04 << (*ivhd >> 6);
+   u32 type = ((struct ivhd_entry *)ivhd)->type;
+
+   if (type < 0x80) {
+   return 0x04 << (*ivhd >> 6);
+   } else if (type == IVHD_DEV_ACPI_HID) {
+   /* For ACPI_HID, offset 21 is uid len */
+   return *((u8 *)ivhd + 21) + 22;
+   }
+   return 0;
 }
 
 /*
@@ -475,6 +485,22 @@ static int __init find_last_devid_from_ivhd(struct 
ivhd_header *h)
return 0;
 }
 
+static int __init check_ivrs_checksum(struct acpi_table_header *table)
+{
+   int i;
+   u8 checksum = 0, *p = (u8 *)table;
+
+   for (i = 0; i < table->length; ++i)
+   checksum += p[i];
+   if (checksum != 0) {
+   /* ACPI table corrupt */
+   pr_err(FW_BUG "AMD-Vi: IVRS invalid checksum\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
 /*
  * Iterate over all IVHD entries in the ACPI table and find the highest device
  * id which we need to handle. This is the first of three functions which parse
@@ -482,31 +508,19 @@ static int __init find_last_devid_from_ivhd(struct 
ivhd_header *h)
  */
 static int __init find_last_devid_acpi(struct acpi_table_header *table)
 {
-   int i;
-   u8 checksum = 0, *p = (u8 *)table, *end = (u8 *)table;
+   u8 *p = (u8 *)table, *end = (u8 *)table;
struct ivhd_header *h;
 
-   /*
-* Validate checksum here so we don't need to do it when
-* we actually parse the table
-*/
-   for (i = 0; i < table->length; ++i)
-   checksum += p[i];
-   if (checksum != 0)
-   /* ACPI table corrupt */
-   return -ENODEV;
-
p += IVRS_HEADER_LENGTH;
 
end += table->length;
while (p < end) {
h = (struct ivhd_header *)p;
-   switch (h->type) {
-   case ACPI_IVHD_TYPE:
-   find_last_devid_from_ivhd(h);
-   break;
-   default:
-   break;
+   if (h->type == amd_iommu_target_ivhd_type) {
+   int ret = find_last_devid_from_ivhd(h);
+
+   if (ret)
+   return ret;
}
p += h->length;
}
@@ -1164,6 +1178,32 @@ static int __init init_iommu_one(struct amd_iommu 
*iommu, struct ivhd_header *h)
return 0;
 }
 
+/**
+ * get_highest_supported_ivhd_type - Look up the appropriate IVHD type
+ * @ivrs  Pointer to the IVRS

[PATCH V3 1/9] iommu/amd: Adding Extended Feature Register check for PC support

From: Suravee Suthikulpanit 

The IVHD header type 11h and 40h introduce the PCSup bit in
the EFR Register Image bit fileds. This should be used to
determine the IOMMU performance support instead of relying
on the PNCounters and PNBanks.

Note also that the PNCouters and PNBanks bits in the IOMMU
attributes field of IVHD headers type 11h are incorrectly
programmed on some systems.

So, we should not rely on it to determine the performance
counter/banks size. Instead, these values should be read
from the MMIO Offset 0030h IOMMU Extended Feature Register.

Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu_init.c | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index bf4959f..dff1e01 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -99,7 +99,11 @@ struct ivhd_header {
u64 mmio_phys;
u16 pci_seg;
u16 info;
-   u32 efr;
+   u32 efr_attr;
+
+   /* Following only valid on IVHD type 11h and 40h */
+   u64 efr_reg; /* Exact copy of MMIO_EXT_FEATURES */
+   u64 res;
 } __attribute__((packed));
 
 /*
@@ -1078,13 +1082,25 @@ static int __init init_iommu_one(struct amd_iommu 
*iommu, struct ivhd_header *h)
iommu->pci_seg = h->pci_seg;
iommu->mmio_phys = h->mmio_phys;
 
-   /* Check if IVHD EFR contains proper max banks/counters */
-   if ((h->efr != 0) &&
-   ((h->efr & (0xF << 13)) != 0) &&
-   ((h->efr & (0x3F << 17)) != 0)) {
-   iommu->mmio_phys_end = MMIO_REG_END_OFFSET;
-   } else {
-   iommu->mmio_phys_end = MMIO_CNTR_CONF_OFFSET;
+   switch (h->type) {
+   case 0x10:
+   /* Check if IVHD EFR contains proper max banks/counters */
+   if ((h->efr_attr != 0) &&
+   ((h->efr_attr & (0xF << 13)) != 0) &&
+   ((h->efr_attr & (0x3F << 17)) != 0))
+   iommu->mmio_phys_end = MMIO_REG_END_OFFSET;
+   else
+   iommu->mmio_phys_end = MMIO_CNTR_CONF_OFFSET;
+   break;
+   case 0x11:
+   case 0x40:
+   if (h->efr_reg & (1 << 9))
+   iommu->mmio_phys_end = MMIO_REG_END_OFFSET;
+   else
+   iommu->mmio_phys_end = MMIO_CNTR_CONF_OFFSET;
+   break;
+   default:
+   return -EINVAL;
}
 
iommu->mmio_base = iommu_map_mmio_space(iommu->mmio_phys,
-- 
1.9.1

[PATCH V3 3/9] iommu/amd: Use the most comprehensive IVHD type that the driver can support

From: Suravee Suthikulpanit 

The IVRS in more recent AMD system usually contains multiple
IVHD block types (e.g. 0x10, 0x11, and 0x40) for each IOMMU.
The newer IVHD types provide more information (e.g. new features
specified in the IOMMU spec), while maintain compatibility with
the older IVHD type.

Having multiple IVHD type allows older IOMMU drivers to still function
(e.g. using the older IVHD type 0x10) while the newer IOMMU driver can use
the newer IVHD types (e.g. 0x11 and 0x40). Therefore, the IOMMU driver
should only make use of the newest IVHD type that it can support.

This patch adds new logic to determine the highest level of IVHD type
it can support, and use it throughout the to initialize the driver.
This requires adding another pass to the IVRS parsing to determine
appropriate IVHD type (see function get_highest_supported_ivhd_type())
before parsing the contents.

[Vincent: fix the build error of IVHD_DEV_ACPI_HID flag not found]

Signed-off-by: Wan Zongshun 
Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu_init.c | 107 ++---
 1 file changed, 78 insertions(+), 29 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 22e078b..8f49612 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -44,7 +44,7 @@
  */
 #define IVRS_HEADER_LENGTH 48
 
-#define ACPI_IVHD_TYPE  0x10
+#define ACPI_IVHD_TYPE_MAX_SUPPORTED   0x40
 #define ACPI_IVMD_TYPE_ALL  0x20
 #define ACPI_IVMD_TYPE  0x21
 #define ACPI_IVMD_TYPE_RANGE0x22
@@ -58,6 +58,7 @@
 #define IVHD_DEV_EXT_SELECT 0x46
 #define IVHD_DEV_EXT_SELECT_RANGE   0x47
 #define IVHD_DEV_SPECIAL   0x48
+#define IVHD_DEV_ACPI_HID  0xf0
 
 #define IVHD_SPECIAL_IOAPIC1
 #define IVHD_SPECIAL_HPET  2
@@ -137,6 +138,7 @@ bool amd_iommu_irq_remap __read_mostly;
 
 static bool amd_iommu_detected;
 static bool __initdata amd_iommu_disabled;
+static int amd_iommu_target_ivhd_type;
 
 u16 amd_iommu_last_bdf;/* largest PCI device id we have
   to handle */
@@ -428,7 +430,15 @@ static inline u32 get_ivhd_header_size(struct ivhd_header 
*h)
  */
 static inline int ivhd_entry_length(u8 *ivhd)
 {
-   return 0x04 << (*ivhd >> 6);
+   u32 type = ((struct ivhd_entry *)ivhd)->type;
+
+   if (type < 0x80) {
+   return 0x04 << (*ivhd >> 6);
+   } else if (type == IVHD_DEV_ACPI_HID) {
+   /* For ACPI_HID, offset 21 is uid len */
+   return *((u8 *)ivhd + 21) + 22;
+   }
+   return 0;
 }
 
 /*
@@ -475,6 +485,22 @@ static int __init find_last_devid_from_ivhd(struct 
ivhd_header *h)
return 0;
 }
 
+static int __init check_ivrs_checksum(struct acpi_table_header *table)
+{
+   int i;
+   u8 checksum = 0, *p = (u8 *)table;
+
+   for (i = 0; i < table->length; ++i)
+   checksum += p[i];
+   if (checksum != 0) {
+   /* ACPI table corrupt */
+   pr_err(FW_BUG "AMD-Vi: IVRS invalid checksum\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
 /*
  * Iterate over all IVHD entries in the ACPI table and find the highest device
  * id which we need to handle. This is the first of three functions which parse
@@ -482,31 +508,19 @@ static int __init find_last_devid_from_ivhd(struct 
ivhd_header *h)
  */
 static int __init find_last_devid_acpi(struct acpi_table_header *table)
 {
-   int i;
-   u8 checksum = 0, *p = (u8 *)table, *end = (u8 *)table;
+   u8 *p = (u8 *)table, *end = (u8 *)table;
struct ivhd_header *h;
 
-   /*
-* Validate checksum here so we don't need to do it when
-* we actually parse the table
-*/
-   for (i = 0; i < table->length; ++i)
-   checksum += p[i];
-   if (checksum != 0)
-   /* ACPI table corrupt */
-   return -ENODEV;
-
p += IVRS_HEADER_LENGTH;
 
end += table->length;
while (p < end) {
h = (struct ivhd_header *)p;
-   switch (h->type) {
-   case ACPI_IVHD_TYPE:
-   find_last_devid_from_ivhd(h);
-   break;
-   default:
-   break;
+   if (h->type == amd_iommu_target_ivhd_type) {
+   int ret = find_last_devid_from_ivhd(h);
+
+   if (ret)
+   return ret;
}
p += h->length;
}
@@ -1164,6 +1178,32 @@ static int __init init_iommu_one(struct amd_iommu 
*iommu, struct ivhd_header *h)
return 0;
 }
 
+/**
+ * get_highest_supported_ivhd_type - Look up the appropriate IVHD type
+ * @ivrs  Pointer to the IVRS header
+ *
+ * This function search through all IVDB of the maximum supported IVHD

[PATCH V3 1/9] iommu/amd: Adding Extended Feature Register check for PC support

From: Suravee Suthikulpanit 

The IVHD header type 11h and 40h introduce the PCSup bit in
the EFR Register Image bit fileds. This should be used to
determine the IOMMU performance support instead of relying
on the PNCounters and PNBanks.

Note also that the PNCouters and PNBanks bits in the IOMMU
attributes field of IVHD headers type 11h are incorrectly
programmed on some systems.

So, we should not rely on it to determine the performance
counter/banks size. Instead, these values should be read
from the MMIO Offset 0030h IOMMU Extended Feature Register.

Signed-off-by: Suravee Suthikulpanit 
---
 drivers/iommu/amd_iommu_init.c | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index bf4959f..dff1e01 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -99,7 +99,11 @@ struct ivhd_header {
u64 mmio_phys;
u16 pci_seg;
u16 info;
-   u32 efr;
+   u32 efr_attr;
+
+   /* Following only valid on IVHD type 11h and 40h */
+   u64 efr_reg; /* Exact copy of MMIO_EXT_FEATURES */
+   u64 res;
 } __attribute__((packed));
 
 /*
@@ -1078,13 +1082,25 @@ static int __init init_iommu_one(struct amd_iommu 
*iommu, struct ivhd_header *h)
iommu->pci_seg = h->pci_seg;
iommu->mmio_phys = h->mmio_phys;
 
-   /* Check if IVHD EFR contains proper max banks/counters */
-   if ((h->efr != 0) &&
-   ((h->efr & (0xF << 13)) != 0) &&
-   ((h->efr & (0x3F << 17)) != 0)) {
-   iommu->mmio_phys_end = MMIO_REG_END_OFFSET;
-   } else {
-   iommu->mmio_phys_end = MMIO_CNTR_CONF_OFFSET;
+   switch (h->type) {
+   case 0x10:
+   /* Check if IVHD EFR contains proper max banks/counters */
+   if ((h->efr_attr != 0) &&
+   ((h->efr_attr & (0xF << 13)) != 0) &&
+   ((h->efr_attr & (0x3F << 17)) != 0))
+   iommu->mmio_phys_end = MMIO_REG_END_OFFSET;
+   else
+   iommu->mmio_phys_end = MMIO_CNTR_CONF_OFFSET;
+   break;
+   case 0x11:
+   case 0x40:
+   if (h->efr_reg & (1 << 9))
+   iommu->mmio_phys_end = MMIO_REG_END_OFFSET;
+   else
+   iommu->mmio_phys_end = MMIO_CNTR_CONF_OFFSET;
+   break;
+   default:
+   return -EINVAL;
}
 
iommu->mmio_base = iommu_map_mmio_space(iommu->mmio_phys,
-- 
1.9.1

[PATCH] autofs: don't stuck in a loop if vfs_write returns an error

2016-03-31 Thread Andrey Vagin

From: Andrey Vagin 

__vfs_write() returns a negative value in a error case.

Cc: Ian Kent 
Signed-off-by: Andrey Vagin 
---
 fs/autofs4/waitq.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
index 0146d91..631f155 100644
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -66,11 +66,12 @@ static int autofs4_write(struct autofs_sb_info *sbi,
set_fs(KERNEL_DS);
 
mutex_lock(>pipe_mutex);
-   wr = __vfs_write(file, data, bytes, >f_pos);
-   while (bytes && wr) {
+   while (bytes) {
+   wr = __vfs_write(file, data, bytes, >f_pos);
+   if (wr <= 0)
+   break;
data += wr;
bytes -= wr;
-   wr = __vfs_write(file, data, bytes, >f_pos);
}
mutex_unlock(>pipe_mutex);
 
-- 
2.5.0

[PATCH] autofs: don't stuck in a loop if vfs_write returns an error

2016-03-31 Thread Andrey Vagin

From: Andrey Vagin 

__vfs_write() returns a negative value in a error case.

Cc: Ian Kent 
Signed-off-by: Andrey Vagin 
---
 fs/autofs4/waitq.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
index 0146d91..631f155 100644
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -66,11 +66,12 @@ static int autofs4_write(struct autofs_sb_info *sbi,
set_fs(KERNEL_DS);
 
mutex_lock(>pipe_mutex);
-   wr = __vfs_write(file, data, bytes, >f_pos);
-   while (bytes && wr) {
+   while (bytes) {
+   wr = __vfs_write(file, data, bytes, >f_pos);
+   if (wr <= 0)
+   break;
data += wr;
bytes -= wr;
-   wr = __vfs_write(file, data, bytes, >f_pos);
}
mutex_unlock(>pipe_mutex);
 
-- 
2.5.0

RE: [RFC PATCH 02/10] acpi: install SSDT tables from initrd

Hi,

IMO, there is already a similar function upstreamed:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c85cc81
Could it work for your use case?

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Octavian Purdila
> Subject: [RFC PATCH 02/10] acpi: install SSDT tables from initrd
> 
> This patch allows loading user defined SSDTs from the first,
> uncompressed, initrd. The SSDT aml code must be stored in files under
> the /kernel/firmware/acpi/overlay path.
> 
> Signed-off-by: Octavian Purdila 
> ---
>  Documentation/acpi/ssdt-overlays.txt | 94
> 
>  drivers/acpi/bus.c   | 63 
>  2 files changed, 157 insertions(+)
>  create mode 100644 Documentation/acpi/ssdt-overlays.txt
> 
> diff --git a/Documentation/acpi/ssdt-overlays.txt b/Documentation/acpi/ssdt-
> overlays.txt
> new file mode 100644
> index 000..a94c3f9
> --- /dev/null
> +++ b/Documentation/acpi/ssdt-overlays.txt
> @@ -0,0 +1,94 @@
> +
> +In order to support ACPI open-ended hardware configurations (e.g.
> development
> +boards) we need a way to augment the ACPI configuration provided by the
> firmware
> +image. A common example is connecting sensors on I2C / SPI buses on
> development
> +boards.
> +
> +Although this can be accomplished by creating a kernel platform driver or
> +recompiling the firmware image with updated ACPI tables, neither is 
> practical:
> +the former proliferates board specific kernel code while the latter requires
> +access to firmware tools which are often not publicly available.
> +
> +Because ACPI supports external references in AML code a more practical
> +way to augment firmware ACPI configuration is by dynamically loading
> +user defined SSDT tables that contain the board specific information.
> +
> +For example, to enumerate a Bosch BMA222E accelerometer on the I2C bus
> of the
> +Minnowboard MAX development board exposed via the LSE connector [1],
> the
> +following ASL code can be used:
> +
> +DefinitionBlock ("minnowmax.aml", "SSDT", 1, "Vendor", "Accel", 0x0003)
> +{
> +External (\_SB.I2C6, DeviceObj)
> +
> +Scope (\_SB.I2C6)
> +{
> +Device (STAC)
> +{
> +Name (_ADR, Zero)
> +Name (_HID, "BMA222E")
> +
> +Method (_CRS, 0, Serialized)
> +{
> +Name (RBUF, ResourceTemplate ()
> +{
> +I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
> +  AddressingMode7Bit, "\\_SB.I2C6", 0x00,
> +  ResourceConsumer, ,)
> +GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x,
> + "\\_SB.GPO2", 0x00, ResourceConsumer, , )
> +{ // Pin list
> +0
> +}
> +})
> +Return (RBUF)
> +}
> +}
> +}
> +}
> +
> +which can then be compiled to AML binary format:
> +
> +$ iasl minnowmax.asl
> +
> +Intel ACPI Component Architecture
> +ASL Optimizing Compiler version 20140214-64 [Mar 29 2014]
> +Copyright (c) 2000 - 2014 Intel Corporation
> +
> +ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords
> +AML Output:minnowmax.aml - 165 bytes, 6 named objects, 1 executable
> opcodes
> +
> +[1]
> http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Co
> nnector_.28Top.29
> +
> +The resulting AML code can then be loaded by the kernel using one of the
> methods
> +below.
> +
> +== Loading ACPI SSDTs from initrd ==
> +
> +This option allows loading of user defined SSDTs from initrd and it is useful
> +when the system does not support EFI or when there is not enough EFI
> storage.
> +
> +It works in a similar way with initrd based ACPI tables overrides: SSDT aml
> code
> +must be placed in the first, uncompressed, initrd under the
> +"kernel/firmware/acpi/overlay" path. We use a different path than the initrd
> +tables override to avoid conflicts with the override feature.
> +
> +Multiple files can be used and this will translate in loading multiple
> +tables. Only tables with the SSDT signature will be loaded.
> +
> +Here is an example:
> +
> +# Add the raw ACPI tables to an uncompressed cpio archive.
> +# They must be put into a /kernel/firmware/acpi/overlay directory inside the
> +# cpio archive.
> +# The uncompressed cpio archive must be the first.
> +# Other, typically compressed cpio archives, must be
> +# concatenated on top of the uncompressed one.
> +mkdir -p kernel/firmware/acpi
> +cp ssdt.aml kernel/firmware/acpi
> +
> +# Create the uncompressed cpio archive and concatenate the original initrd
> +# on top:
> +find kernel | cpio -H newc --create > /boot/instrumented_initrd
> +cat /boot/initrd >>/boot/instrumented_initrd
> +
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index

RE: [RFC PATCH 02/10] acpi: install SSDT tables from initrd

Hi,

IMO, there is already a similar function upstreamed:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c85cc81
Could it work for your use case?

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Octavian Purdila
> Subject: [RFC PATCH 02/10] acpi: install SSDT tables from initrd
> 
> This patch allows loading user defined SSDTs from the first,
> uncompressed, initrd. The SSDT aml code must be stored in files under
> the /kernel/firmware/acpi/overlay path.
> 
> Signed-off-by: Octavian Purdila 
> ---
>  Documentation/acpi/ssdt-overlays.txt | 94
> 
>  drivers/acpi/bus.c   | 63 
>  2 files changed, 157 insertions(+)
>  create mode 100644 Documentation/acpi/ssdt-overlays.txt
> 
> diff --git a/Documentation/acpi/ssdt-overlays.txt b/Documentation/acpi/ssdt-
> overlays.txt
> new file mode 100644
> index 000..a94c3f9
> --- /dev/null
> +++ b/Documentation/acpi/ssdt-overlays.txt
> @@ -0,0 +1,94 @@
> +
> +In order to support ACPI open-ended hardware configurations (e.g.
> development
> +boards) we need a way to augment the ACPI configuration provided by the
> firmware
> +image. A common example is connecting sensors on I2C / SPI buses on
> development
> +boards.
> +
> +Although this can be accomplished by creating a kernel platform driver or
> +recompiling the firmware image with updated ACPI tables, neither is 
> practical:
> +the former proliferates board specific kernel code while the latter requires
> +access to firmware tools which are often not publicly available.
> +
> +Because ACPI supports external references in AML code a more practical
> +way to augment firmware ACPI configuration is by dynamically loading
> +user defined SSDT tables that contain the board specific information.
> +
> +For example, to enumerate a Bosch BMA222E accelerometer on the I2C bus
> of the
> +Minnowboard MAX development board exposed via the LSE connector [1],
> the
> +following ASL code can be used:
> +
> +DefinitionBlock ("minnowmax.aml", "SSDT", 1, "Vendor", "Accel", 0x0003)
> +{
> +External (\_SB.I2C6, DeviceObj)
> +
> +Scope (\_SB.I2C6)
> +{
> +Device (STAC)
> +{
> +Name (_ADR, Zero)
> +Name (_HID, "BMA222E")
> +
> +Method (_CRS, 0, Serialized)
> +{
> +Name (RBUF, ResourceTemplate ()
> +{
> +I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
> +  AddressingMode7Bit, "\\_SB.I2C6", 0x00,
> +  ResourceConsumer, ,)
> +GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x,
> + "\\_SB.GPO2", 0x00, ResourceConsumer, , )
> +{ // Pin list
> +0
> +}
> +})
> +Return (RBUF)
> +}
> +}
> +}
> +}
> +
> +which can then be compiled to AML binary format:
> +
> +$ iasl minnowmax.asl
> +
> +Intel ACPI Component Architecture
> +ASL Optimizing Compiler version 20140214-64 [Mar 29 2014]
> +Copyright (c) 2000 - 2014 Intel Corporation
> +
> +ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords
> +AML Output:minnowmax.aml - 165 bytes, 6 named objects, 1 executable
> opcodes
> +
> +[1]
> http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Co
> nnector_.28Top.29
> +
> +The resulting AML code can then be loaded by the kernel using one of the
> methods
> +below.
> +
> +== Loading ACPI SSDTs from initrd ==
> +
> +This option allows loading of user defined SSDTs from initrd and it is useful
> +when the system does not support EFI or when there is not enough EFI
> storage.
> +
> +It works in a similar way with initrd based ACPI tables overrides: SSDT aml
> code
> +must be placed in the first, uncompressed, initrd under the
> +"kernel/firmware/acpi/overlay" path. We use a different path than the initrd
> +tables override to avoid conflicts with the override feature.
> +
> +Multiple files can be used and this will translate in loading multiple
> +tables. Only tables with the SSDT signature will be loaded.
> +
> +Here is an example:
> +
> +# Add the raw ACPI tables to an uncompressed cpio archive.
> +# They must be put into a /kernel/firmware/acpi/overlay directory inside the
> +# cpio archive.
> +# The uncompressed cpio archive must be the first.
> +# Other, typically compressed cpio archives, must be
> +# concatenated on top of the uncompressed one.
> +mkdir -p kernel/firmware/acpi
> +cp ssdt.aml kernel/firmware/acpi
> +
> +# Create the uncompressed cpio archive and concatenate the original initrd
> +# on top:
> +find kernel | cpio -H newc --create > /boot/instrumented_initrd
> +cat /boot/initrd >>/boot/instrumented_initrd
> +
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 891c42d..5e0d076 100644
> ---

Re: [PATCHSET v3][RFC] Make background writeback not suck

2016-03-31 Thread Dave Chinner

On Thu, Mar 31, 2016 at 09:29:30PM -0600, Jens Axboe wrote:
> On 03/31/2016 06:56 PM, Dave Chinner wrote:
> >I'm not changing the host kernels - it's a production machine and so
> >it runs long uptime testing of stable kernels.  (e.g. catch slow
> >memory leaks, etc). So if you've disabled throttling in the guest, I
> >can't test the throttling changes.
> 
> Right, that'd definitely hide the problem for you. I'll see if I can
> get it in a reproducible state and take it from there.
> 
> On your host, you said it's SCSI backed, but what does the device look like?

HW RAID 0 w/ 1GB FBWC (dell h710, IIRC) of 2x200GB SATA SSDs
(actually 256GB, but 25% of each is left as spare, unused space).
Sustains about 35,000 random 4k write IOPS, up to 70k read IOPS.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCHSET v3][RFC] Make background writeback not suck

2016-03-31 Thread Dave Chinner

On Thu, Mar 31, 2016 at 09:29:30PM -0600, Jens Axboe wrote:
> On 03/31/2016 06:56 PM, Dave Chinner wrote:
> >I'm not changing the host kernels - it's a production machine and so
> >it runs long uptime testing of stable kernels.  (e.g. catch slow
> >memory leaks, etc). So if you've disabled throttling in the guest, I
> >can't test the throttling changes.
> 
> Right, that'd definitely hide the problem for you. I'll see if I can
> get it in a reproducible state and take it from there.
> 
> On your host, you said it's SCSI backed, but what does the device look like?

HW RAID 0 w/ 1GB FBWC (dell h710, IIRC) of 2x200GB SATA SSDs
(actually 256GB, but 25% of each is left as spare, unused space).
Sustains about 35,000 random 4k write IOPS, up to 70k read IOPS.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

RE: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

Hi,

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Octavian Purdila
> Subject: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs
> 
> Add support for acpi_user_table configfs items that allows the user to
> load new tables. The data attributes contains the table data and once it
> is filled from userspace the table is loaded and ACPI devices are
> enumerated.
[Lv Zheng] 
We've been considering to implement this facility before.
The 2 alternative solutions are:
1. implement LOAD/UNLOAD ioctl for /sys/kernel/debug/acpi/acpidbg - this will 
be useful for extracting AML byte stream from kernel to be used by a userspace 
disassembler.
2. transition /sys/firmware/acpi/tables/xxx into directory and implement 
/sys/firmware/acpi/tables/load, /sys/firmware/acpi/tables/unload - this should 
be able to meet your requirement.

So my first question is:
Why do you use configfs rather than the existing mechanisms?

> 
> Signed-off-by: Octavian Purdila 
> ---
>  Documentation/ABI/testing/configfs-acpi |  16 +
>  Documentation/acpi/ssdt-overlays.txt|  14 +
>  drivers/acpi/configfs.c | 104 
> 
>  3 files changed, 134 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/configfs-acpi
> b/Documentation/ABI/testing/configfs-acpi
> index 0c806aa..34a205e 100644
> --- a/Documentation/ABI/testing/configfs-acpi
> +++ b/Documentation/ABI/testing/configfs-acpi
> @@ -5,3 +5,19 @@ Contact: linux-a...@vger.kernel.org
>  Description:
>   This represents the ACPI subsystem entry point directory. It
>   contains sub-groups corresponding to ACPI configurable
> options.
> +
> +What:/config/acpi/table
> +Date:April 2016
> +KernelVersion:   4.6
> +Description:
> +
> + This group contains the configuration for user defined ACPI
> + tables. The attributes of a user define table are:
> +
> + data - a binary write only attribute that the user can use to
> +fill in the ACPI aml definitions. Once the aml data is
> +written to this file and the file is closed the table
> +will be loaded and ACPI device will be enumerated. To
> +check if the operation is successful the user must check
> +the error code for close(). If the operation is
> +successful, subsequent writes to this attribute will 
> fail.
> diff --git a/Documentation/acpi/ssdt-overlays.txt b/Documentation/acpi/ssdt-
> overlays.txt
> index 7c588be..a88a2ce 100644
> --- a/Documentation/acpi/ssdt-overlays.txt
> +++ b/Documentation/acpi/ssdt-overlays.txt
> @@ -158,3 +158,17 @@ tmp=$(mktemp)
>  /bin/echo -ne "\007\000\000\000" | cat - $filename > $tmp
>  dd if=$tmp of="$EFIVARFS/$name-$guid" bs=$(stat -c %s $tmp)
>  rm $tmp
> +
> +== Loading ACPI SSDTs from configfs ==
> +
> +This option allows loading of user defined SSDTs from userspace via the
> configfs
> +interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs
> must be
> +mounted. In the following examples, we assume that configfs has been
> mounted in
> +/config.
> +
> +New tables can be loading by creating new directories in /config/acpi/table/
> and
> +writing the SSDT aml code in the data attribute:
> +
> +cd /config/acpi/table
> +mkdir my_ssdt
> +cat ~/ssdt.aml > my_ssdt/data
[Lv Zheng] 
Good to see the table as a directory.
So that we can put more attributes under it.

Thanks
-Lv

> diff --git a/drivers/acpi/configfs.c b/drivers/acpi/configfs.c
> index 96aa3d8..3a194806 100644
> --- a/drivers/acpi/configfs.c
> +++ b/drivers/acpi/configfs.c
> @@ -13,6 +13,104 @@
>  #include 
>  #include 
> 
> +static struct config_group *acpi_table_group;
> +
> +struct acpi_user_table {
> + struct config_item cfg;
> + struct acpi_table_header *table;
> +};
> +
> +static ssize_t acpi_table_data_write(struct config_item *cfg,
> +  const void *data, size_t size)
> +{
> + struct acpi_table_header *header = (struct acpi_table_header *)data;
> + struct acpi_user_table *table;
> + int ret;
> +
> + table = container_of(cfg, struct acpi_user_table, cfg);
> +
> + if (table->table) {
> + pr_err("ACPI configfs table: table already loaded\n");
> + return -EBUSY;
> + }
> +
> + if (header->length != size) {
> + pr_err("ACPI configfs table: invalid table length\n");
> + return -EINVAL;
> + }
> +
> + if (memcmp(header->signature, ACPI_SIG_SSDT, 4)) {
> + pr_err("ACPI configfs table: invalid table signature\n");
> + return -EINVAL;
> + }
> +
> + table = container_of(cfg, struct acpi_user_table, cfg);
> +
> + table->table = kmemdup(header, header->length, GFP_KERNEL);
> + if (!table->table)
> + return

RE: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

Hi,

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Octavian Purdila
> Subject: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs
> 
> Add support for acpi_user_table configfs items that allows the user to
> load new tables. The data attributes contains the table data and once it
> is filled from userspace the table is loaded and ACPI devices are
> enumerated.
[Lv Zheng] 
We've been considering to implement this facility before.
The 2 alternative solutions are:
1. implement LOAD/UNLOAD ioctl for /sys/kernel/debug/acpi/acpidbg - this will 
be useful for extracting AML byte stream from kernel to be used by a userspace 
disassembler.
2. transition /sys/firmware/acpi/tables/xxx into directory and implement 
/sys/firmware/acpi/tables/load, /sys/firmware/acpi/tables/unload - this should 
be able to meet your requirement.

So my first question is:
Why do you use configfs rather than the existing mechanisms?

> 
> Signed-off-by: Octavian Purdila 
> ---
>  Documentation/ABI/testing/configfs-acpi |  16 +
>  Documentation/acpi/ssdt-overlays.txt|  14 +
>  drivers/acpi/configfs.c | 104 
> 
>  3 files changed, 134 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/configfs-acpi
> b/Documentation/ABI/testing/configfs-acpi
> index 0c806aa..34a205e 100644
> --- a/Documentation/ABI/testing/configfs-acpi
> +++ b/Documentation/ABI/testing/configfs-acpi
> @@ -5,3 +5,19 @@ Contact: linux-a...@vger.kernel.org
>  Description:
>   This represents the ACPI subsystem entry point directory. It
>   contains sub-groups corresponding to ACPI configurable
> options.
> +
> +What:/config/acpi/table
> +Date:April 2016
> +KernelVersion:   4.6
> +Description:
> +
> + This group contains the configuration for user defined ACPI
> + tables. The attributes of a user define table are:
> +
> + data - a binary write only attribute that the user can use to
> +fill in the ACPI aml definitions. Once the aml data is
> +written to this file and the file is closed the table
> +will be loaded and ACPI device will be enumerated. To
> +check if the operation is successful the user must check
> +the error code for close(). If the operation is
> +successful, subsequent writes to this attribute will 
> fail.
> diff --git a/Documentation/acpi/ssdt-overlays.txt b/Documentation/acpi/ssdt-
> overlays.txt
> index 7c588be..a88a2ce 100644
> --- a/Documentation/acpi/ssdt-overlays.txt
> +++ b/Documentation/acpi/ssdt-overlays.txt
> @@ -158,3 +158,17 @@ tmp=$(mktemp)
>  /bin/echo -ne "\007\000\000\000" | cat - $filename > $tmp
>  dd if=$tmp of="$EFIVARFS/$name-$guid" bs=$(stat -c %s $tmp)
>  rm $tmp
> +
> +== Loading ACPI SSDTs from configfs ==
> +
> +This option allows loading of user defined SSDTs from userspace via the
> configfs
> +interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs
> must be
> +mounted. In the following examples, we assume that configfs has been
> mounted in
> +/config.
> +
> +New tables can be loading by creating new directories in /config/acpi/table/
> and
> +writing the SSDT aml code in the data attribute:
> +
> +cd /config/acpi/table
> +mkdir my_ssdt
> +cat ~/ssdt.aml > my_ssdt/data
[Lv Zheng] 
Good to see the table as a directory.
So that we can put more attributes under it.

Thanks
-Lv

> diff --git a/drivers/acpi/configfs.c b/drivers/acpi/configfs.c
> index 96aa3d8..3a194806 100644
> --- a/drivers/acpi/configfs.c
> +++ b/drivers/acpi/configfs.c
> @@ -13,6 +13,104 @@
>  #include 
>  #include 
> 
> +static struct config_group *acpi_table_group;
> +
> +struct acpi_user_table {
> + struct config_item cfg;
> + struct acpi_table_header *table;
> +};
> +
> +static ssize_t acpi_table_data_write(struct config_item *cfg,
> +  const void *data, size_t size)
> +{
> + struct acpi_table_header *header = (struct acpi_table_header *)data;
> + struct acpi_user_table *table;
> + int ret;
> +
> + table = container_of(cfg, struct acpi_user_table, cfg);
> +
> + if (table->table) {
> + pr_err("ACPI configfs table: table already loaded\n");
> + return -EBUSY;
> + }
> +
> + if (header->length != size) {
> + pr_err("ACPI configfs table: invalid table length\n");
> + return -EINVAL;
> + }
> +
> + if (memcmp(header->signature, ACPI_SIG_SSDT, 4)) {
> + pr_err("ACPI configfs table: invalid table signature\n");
> + return -EINVAL;
> + }
> +
> + table = container_of(cfg, struct acpi_user_table, cfg);
> +
> + table->table = kmemdup(header, header->length, GFP_KERNEL);
> + if (!table->table)
> + return -ENOMEM;
> +
> + ret =

Re: [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu

2016-03-31 Thread Jason Wang



On 04/01/2016 10:55 AM, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 10:13 +0800, Jason Wang wrote:
>
>
>> The problem is we want to support busy polling for tun. This needs
>> napi_id to be passed to tun socket by sk_mark_napi_id() during
>> tun_net_xmit(). But before reaching this, XPS will set sender_cpu will
>> make us can't see correct napi_id.
>>
> Looks like napi_id should have precedence then ?

But then when busy polling is enabled, we may still hit the issue before
commit 2bd82484bb4c5db1d5dc983ac7c409b2782e0154? So looks like sometimes
(e.g for tun), we need both two fields.

>
> Only forwarding should allow the field to be cleared to allow XPS to do
> its job.
>
> Maybe skb_sender_cpu_clear() was removed too early (commit
> 64d4e3431e686dc37ce388ba531c4c4e866fb141)

Not sure I get you, but this will clear napi_id too.

> Look, it is 8pm here, I am pretty sure a solution can be found,
> but I am also need to take a break, I started at 3am today...
>
>
>

Re: [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu

2016-03-31 Thread Jason Wang



On 04/01/2016 10:55 AM, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 10:13 +0800, Jason Wang wrote:
>
>
>> The problem is we want to support busy polling for tun. This needs
>> napi_id to be passed to tun socket by sk_mark_napi_id() during
>> tun_net_xmit(). But before reaching this, XPS will set sender_cpu will
>> make us can't see correct napi_id.
>>
> Looks like napi_id should have precedence then ?

But then when busy polling is enabled, we may still hit the issue before
commit 2bd82484bb4c5db1d5dc983ac7c409b2782e0154? So looks like sometimes
(e.g for tun), we need both two fields.

>
> Only forwarding should allow the field to be cleared to allow XPS to do
> its job.
>
> Maybe skb_sender_cpu_clear() was removed too early (commit
> 64d4e3431e686dc37ce388ba531c4c4e866fb141)

Not sure I get you, but this will clear napi_id too.

> Look, it is 8pm here, I am pretty sure a solution can be found,
> but I am also need to take a break, I started at 3am today...
>
>
>

[PATCH] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq

2016-03-31 Thread Len Brown

From: Len Brown 

For x86 processors with APERF/MPERF and TSC,
return meaningful and consistent MHz in
/proc/cpuinfo and
/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

MHz is computed like so:

MHz = base_MHz * delta_APERF / delta_MPERF

MHz is the average frequency of the busy processor
over a measurement interval.  The interval is
defined to be the time between successive reads
of the frequency on that processor, whether from
/proc/cpuinfo or from sysfs cpufreq/scaling_cur_freq.
As with previous methods of calculating MHz,
idle time is excluded.

base_MHz above is from TSC calibration global "cpu_khz".

This x86 native method to calculate MHz returns a meaningful result
no matter if P-states are controlled by hardware or firmware
and/or the Linux cpufreq sub-system is/is-not installed.

Note that frequent or concurrent reads of /proc/cpuinfo
or sysfs cpufreq/scaling_cur_freq will shorten the
measurement interval seen by each reader.  The code
mitigates that issue by caching results for 100ms.

Discerning users are encouraged to take advantage of
the turbostat(8) utility, which can gracefully handle
concurrent measurement intervals of arbitrary length.

Signed-off-by: Len Brown 
---
 arch/x86/kernel/cpu/Makefile |  1 +
 arch/x86/kernel/cpu/aperfmperf.c | 76 
 arch/x86/kernel/cpu/proc.c   |  4 ++-
 drivers/cpufreq/cpufreq.c|  7 +++-
 include/linux/cpufreq.h  | 13 +++
 5 files changed, 99 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/kernel/cpu/aperfmperf.c

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 4a8697f..821e31a 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -20,6 +20,7 @@ obj-y := intel_cacheinfo.o scattered.o 
topology.o
 obj-y  += common.o
 obj-y  += rdrand.o
 obj-y  += match.o
+obj-y  += aperfmperf.o
 
 obj-$(CONFIG_PROC_FS)  += proc.o
 obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
new file mode 100644
index 000..9380102
--- /dev/null
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -0,0 +1,76 @@
+/*
+ * x86 APERF/MPERF KHz calculation
+ * Used by /proc/cpuinfo and /sys/.../cpufreq/scaling_cur_freq
+ *
+ * Copyright (C) 2015 Intel Corp.
+ * Author: Len Brown 
+ *
+ * This file is licensed under GPLv2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct aperfmperf_sample {
+   unsigned int khz;
+   unsigned long jiffies;
+   unsigned long long aperf;
+   unsigned long long mperf;
+};
+
+static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
+
+/*
+ * aperfmperf_snapshot_khz()
+ * On the current CPU, snapshot APERF, MPERF, and jiffies
+ * unless we already did it within 100ms
+ * calculate kHz, save snapshot
+ */
+static void aperfmperf_snapshot_khz(void *dummy)
+{
+   unsigned long long aperf, aperf_delta;
+   unsigned long long mperf, mperf_delta;
+   unsigned long long numerator;
+   struct aperfmperf_sample *s = _cpu_var(samples);
+
+   /* Cache KHz for 100 ms */
+   if (time_before(jiffies, s->jiffies + HZ/10))
+   goto out;
+
+   rdmsrl(MSR_IA32_APERF, aperf);
+   rdmsrl(MSR_IA32_MPERF, mperf);
+
+   aperf_delta = aperf - s->aperf;
+   mperf_delta = mperf - s->mperf;
+
+   /*
+* There is no architectural guarantee that MPERF
+* increments faster than we can read it.
+*/
+   if (mperf_delta == 0)
+   goto out;
+
+   numerator = cpu_khz * aperf_delta;
+   s->khz = div64_u64(numerator, mperf_delta);
+   s->jiffies = jiffies;
+   s->aperf = aperf;
+   s->mperf = mperf;
+
+out:
+   put_cpu_var(samples);
+}
+
+unsigned int aperfmperf_khz_on_cpu(int cpu)
+{
+   if (!cpu_khz)
+   return 0;
+
+   if (!boot_cpu_has(X86_FEATURE_APERFMPERF))
+   return 0;
+
+   smp_call_function_single(cpu, aperfmperf_snapshot_khz, NULL, 1);
+
+   return per_cpu(samples.khz, cpu);
+}
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 18ca99f..44507c0 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -78,9 +78,11 @@ static int show_cpuinfo(struct seq_file *m, void *v)
seq_printf(m, "microcode\t: 0x%x\n", c->microcode);
 
if (cpu_has(c, X86_FEATURE_TSC)) {
-   unsigned int freq = cpufreq_quick_get(cpu);
+   unsigned int freq = aperfmperf_khz_on_cpu(cpu);
 
if (!freq)
+   freq = cpufreq_quick_get(cpu);
+   if (!freq)
freq = cpu_khz;
seq_printf(m, "cpu MHz\t\t: %u.%03u\n",
   freq / 1000, (freq % 1000));
diff --git a/drivers/cpufreq/cpufreq.c

[PATCH] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq

2016-03-31 Thread Len Brown

From: Len Brown 

For x86 processors with APERF/MPERF and TSC,
return meaningful and consistent MHz in
/proc/cpuinfo and
/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

MHz is computed like so:

MHz = base_MHz * delta_APERF / delta_MPERF

MHz is the average frequency of the busy processor
over a measurement interval.  The interval is
defined to be the time between successive reads
of the frequency on that processor, whether from
/proc/cpuinfo or from sysfs cpufreq/scaling_cur_freq.
As with previous methods of calculating MHz,
idle time is excluded.

base_MHz above is from TSC calibration global "cpu_khz".

This x86 native method to calculate MHz returns a meaningful result
no matter if P-states are controlled by hardware or firmware
and/or the Linux cpufreq sub-system is/is-not installed.

Note that frequent or concurrent reads of /proc/cpuinfo
or sysfs cpufreq/scaling_cur_freq will shorten the
measurement interval seen by each reader.  The code
mitigates that issue by caching results for 100ms.

Discerning users are encouraged to take advantage of
the turbostat(8) utility, which can gracefully handle
concurrent measurement intervals of arbitrary length.

Signed-off-by: Len Brown 
---
 arch/x86/kernel/cpu/Makefile |  1 +
 arch/x86/kernel/cpu/aperfmperf.c | 76 
 arch/x86/kernel/cpu/proc.c   |  4 ++-
 drivers/cpufreq/cpufreq.c|  7 +++-
 include/linux/cpufreq.h  | 13 +++
 5 files changed, 99 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/kernel/cpu/aperfmperf.c

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 4a8697f..821e31a 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -20,6 +20,7 @@ obj-y := intel_cacheinfo.o scattered.o 
topology.o
 obj-y  += common.o
 obj-y  += rdrand.o
 obj-y  += match.o
+obj-y  += aperfmperf.o
 
 obj-$(CONFIG_PROC_FS)  += proc.o
 obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
new file mode 100644
index 000..9380102
--- /dev/null
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -0,0 +1,76 @@
+/*
+ * x86 APERF/MPERF KHz calculation
+ * Used by /proc/cpuinfo and /sys/.../cpufreq/scaling_cur_freq
+ *
+ * Copyright (C) 2015 Intel Corp.
+ * Author: Len Brown 
+ *
+ * This file is licensed under GPLv2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct aperfmperf_sample {
+   unsigned int khz;
+   unsigned long jiffies;
+   unsigned long long aperf;
+   unsigned long long mperf;
+};
+
+static DEFINE_PER_CPU(struct aperfmperf_sample, samples);
+
+/*
+ * aperfmperf_snapshot_khz()
+ * On the current CPU, snapshot APERF, MPERF, and jiffies
+ * unless we already did it within 100ms
+ * calculate kHz, save snapshot
+ */
+static void aperfmperf_snapshot_khz(void *dummy)
+{
+   unsigned long long aperf, aperf_delta;
+   unsigned long long mperf, mperf_delta;
+   unsigned long long numerator;
+   struct aperfmperf_sample *s = _cpu_var(samples);
+
+   /* Cache KHz for 100 ms */
+   if (time_before(jiffies, s->jiffies + HZ/10))
+   goto out;
+
+   rdmsrl(MSR_IA32_APERF, aperf);
+   rdmsrl(MSR_IA32_MPERF, mperf);
+
+   aperf_delta = aperf - s->aperf;
+   mperf_delta = mperf - s->mperf;
+
+   /*
+* There is no architectural guarantee that MPERF
+* increments faster than we can read it.
+*/
+   if (mperf_delta == 0)
+   goto out;
+
+   numerator = cpu_khz * aperf_delta;
+   s->khz = div64_u64(numerator, mperf_delta);
+   s->jiffies = jiffies;
+   s->aperf = aperf;
+   s->mperf = mperf;
+
+out:
+   put_cpu_var(samples);
+}
+
+unsigned int aperfmperf_khz_on_cpu(int cpu)
+{
+   if (!cpu_khz)
+   return 0;
+
+   if (!boot_cpu_has(X86_FEATURE_APERFMPERF))
+   return 0;
+
+   smp_call_function_single(cpu, aperfmperf_snapshot_khz, NULL, 1);
+
+   return per_cpu(samples.khz, cpu);
+}
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 18ca99f..44507c0 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -78,9 +78,11 @@ static int show_cpuinfo(struct seq_file *m, void *v)
seq_printf(m, "microcode\t: 0x%x\n", c->microcode);
 
if (cpu_has(c, X86_FEATURE_TSC)) {
-   unsigned int freq = cpufreq_quick_get(cpu);
+   unsigned int freq = aperfmperf_khz_on_cpu(cpu);
 
if (!freq)
+   freq = cpufreq_quick_get(cpu);
+   if (!freq)
freq = cpu_khz;
seq_printf(m, "cpu MHz\t\t: %u.%03u\n",
   freq / 1000, (freq % 1000));
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b87596b..7fcd090 100644
---

linux-next: Tree for Apr 1

2016-03-31 Thread Stephen Rothwell

Hi all,

Changes since 20160331:

My fixes tree contains:

  perf tools: Fix build break on powerpc

The qcom tree gained a build failure so I used the version from
next-20160331.

The pm tree gained a build failure so I used the verison from
next-20160331.

The gpio tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1899
 1637 files changed, 67661 insertions(+), 46594 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c05c2ec96bb8 Merge branch 'parisc-4.6-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging fixes/master (6c020251498e perf tools: Fix build break on powerpc)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (f86b8892a1b7 ARC: Don't source 
drivers/pci/pcie/Kconfig ourselves)
Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (79f4223257bf net: usb: cdc_ncm: adding Telit LE910 V2 
mobile broadband card)
Merging ipsec/master (215276c0147e xfrm: Reset encapsulation field of the skb 
before transformation)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (2acd84648554 rtlwifi: fix gcc-6 indentation 
warning)
Merging mac80211/master (ad8ec957f693 wext: unregister_pernet_subsys() on 
notifier registration failure)
Merging sound-current/for-linus (836b34a935ab ALSA: usb-audio: Fix double-free 
in error paths after snd_usb_add_audio_stream() call)
Merging pci-current/for-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging driver-core.current/driver-core-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging tty.current/tty-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging usb.current/usb-linus (5a07975ad0a3 USB: digi_acceleport: do sanity 
checking for the number of ports)
Merging usb-gadget-fixes/fixes (7e8ac87a4474 usb: phy: qcom-8x16: fix regulator 
API abuse)
Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging char-misc.current/char-misc-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging input-current/for-linus (162f98dea487 Input: gtco - fix crash on 
detecting device without endpoints)
Merging crypto-current/master (e54358915d0a PKCS#7: pkcs7_validate_trust(): 
initialize the _trusted output argument)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl err

linux-next: Tree for Apr 1

2016-03-31 Thread Stephen Rothwell

Hi all,

Changes since 20160331:

My fixes tree contains:

  perf tools: Fix build break on powerpc

The qcom tree gained a build failure so I used the version from
next-20160331.

The pm tree gained a build failure so I used the verison from
next-20160331.

The gpio tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1899
 1637 files changed, 67661 insertions(+), 46594 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c05c2ec96bb8 Merge branch 'parisc-4.6-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging fixes/master (6c020251498e perf tools: Fix build break on powerpc)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (f86b8892a1b7 ARC: Don't source 
drivers/pci/pcie/Kconfig ourselves)
Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (79f4223257bf net: usb: cdc_ncm: adding Telit LE910 V2 
mobile broadband card)
Merging ipsec/master (215276c0147e xfrm: Reset encapsulation field of the skb 
before transformation)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (2acd84648554 rtlwifi: fix gcc-6 indentation 
warning)
Merging mac80211/master (ad8ec957f693 wext: unregister_pernet_subsys() on 
notifier registration failure)
Merging sound-current/for-linus (836b34a935ab ALSA: usb-audio: Fix double-free 
in error paths after snd_usb_add_audio_stream() call)
Merging pci-current/for-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging driver-core.current/driver-core-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging tty.current/tty-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging usb.current/usb-linus (5a07975ad0a3 USB: digi_acceleport: do sanity 
checking for the number of ports)
Merging usb-gadget-fixes/fixes (7e8ac87a4474 usb: phy: qcom-8x16: fix regulator 
API abuse)
Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging char-misc.current/char-misc-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging input-current/for-linus (162f98dea487 Input: gtco - fix crash on 
detecting device without endpoints)
Merging crypto-current/master (e54358915d0a PKCS#7: pkcs7_validate_trust(): 
initialize the _trusted output argument)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl err

Re: [media 2/8] NXP tda2014x & Newport Media nm120/130/131 tuner (PXQ3PE)

Hi Буди,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-s5-04011138 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
 HEAD a28878c9675f849df56f4623c33ca431f03e240a builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> make[4]: *** No rule to make target 'drivers/media/tuners/qm1d1c004x.c', 
>> needed by 'drivers/media/tuners/qm1d1c004x.o'.
   make[4]: Target '__build' not remade because of errors.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [media 2/8] NXP tda2014x & Newport Media nm120/130/131 tuner (PXQ3PE)

Hi Буди,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-s5-04011138 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
 HEAD a28878c9675f849df56f4623c33ca431f03e240a builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> make[4]: *** No rule to make target 'drivers/media/tuners/qm1d1c004x.c', 
>> needed by 'drivers/media/tuners/qm1d1c004x.o'.
   make[4]: Target '__build' not remade because of errors.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [media 7/8] PCIE bridge driver for PT3 & PX-Q3PE

Hi Буди,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media/pci/ptx/pxq3pe_pci.c: In function 'pxq3pe_remove':
   drivers/media/pci/ptx/pxq3pe_pci.c:484:3: error: implicit declaration of 
function 'vfree' [-Werror=implicit-function-declaration]
  vfree(p->sBuf);
  ^
   drivers/media/pci/ptx/pxq3pe_pci.c: In function 'pxq3pe_probe':
   drivers/media/pci/ptx/pxq3pe_pci.c:536:14: error: implicit declaration of 
function 'vzalloc' [-Werror=implicit-function-declaration]
  p->sBuf  = vzalloc(p->sBufSize);
 ^
>> drivers/media/pci/ptx/pxq3pe_pci.c:536:12: warning: assignment makes pointer 
>> from integer without a cast [-Wint-conversion]
  p->sBuf  = vzalloc(p->sBufSize);
   ^
   cc1: some warnings being treated as errors

vim +536 drivers/media/pci/ptx/pxq3pe_pci.c

   478  if (c->dma.dat)
   479  pci_free_consistent(card->pdev, c->dma.sz, c->dma.dat, 
c->dma.adr);
   480  for (i = 0; i < card->adapn; i++) {
   481  struct ptx_adap *adap   = >adap[i];
   482  struct pxq3pe_adap  *p  = adap->priv;
   483  
 > 484  vfree(p->sBuf);
   485  }
   486  if (c->bar)
   487  pci_iounmap(pdev, c->bar);
   488  ptx_unregister_adap(card);
   489  }
   490  
   491  static const struct i2c_algorithm pxq3pe_algo = {
   492  .functionality  = ptx_i2c_func,
   493  .master_xfer= pxq3pe_xfr,
   494  };
   495  
   496  static int pxq3pe_probe(struct pci_dev *pdev, const struct 
pci_device_id *pci_id)
   497  {
   498  struct ptx_subdev_info  pxq3pe_subdev_info[] = {
   499  {SYS_ISDBT, 0x20, TC90522_MODNAME, 0x10, NM131_MODNAME},
   500  {SYS_ISDBS, 0x22, TC90522_MODNAME, 0x11, 
TDA2014X_MODNAME},
   501  {SYS_ISDBT, 0x24, TC90522_MODNAME, 0x12, NM131_MODNAME},
   502  {SYS_ISDBS, 0x26, TC90522_MODNAME, 0x13, 
TDA2014X_MODNAME},
   503  {SYS_ISDBT, 0x28, TC90522_MODNAME, 0x14, NM131_MODNAME},
   504  {SYS_ISDBS, 0x2A, TC90522_MODNAME, 0x15, 
TDA2014X_MODNAME},
   505  {SYS_ISDBT, 0x2C, TC90522_MODNAME, 0x16, NM131_MODNAME},
   506  {SYS_ISDBS, 0x2E, TC90522_MODNAME, 0x17, 
TDA2014X_MODNAME},
   507  };
   508  struct ptx_card *card   = ptx_alloc(pdev, 
KBUILD_MODNAME, ARRAY_SIZE(pxq3pe_subdev_info),
   509  sizeof(struct 
pxq3pe_card), sizeof(struct pxq3pe_adap), pxq3pe_lnb);
   510  struct pxq3pe_card  *c;
   511  u8  regctl  = 0xA0,
   512  i;
   513  u16 cfg;
   514  int err = !card || pci_read_config_word(pdev, 
PCI_COMMAND, );
   515  
   516  if (err)
   517  return ptx_abort(pdev, pxq3pe_remove, err, "Memory/PCI 
error, card=%p", card);
   518  c   = card->priv;
   519  if (!(cfg & PCI_COMMAND_MASTER)) {
   520  pci_set_master(pdev);
   521  pci_read_config_word(pdev, PCI_COMMAND, );
   522  if (!(cfg & PCI_COMMAND_MASTER))
   523  return ptx_abort(pdev, pxq3pe_remove, -EIO, 
"Bus Mastering is disabled");
   524  }
   525  c->bar  = pci_iomap(pdev, 0, 0);
   526  if (!c->bar)
   527  return ptx_abort(pdev, pxq3pe_remove, -EIO, "I/O map 
failed");
   528  if (ptx_i2c_add_adapter(card, _algo))
   529  return ptx_abort(pdev, pxq3pe_remove, -EIO, "Cannot add 
I2C");
   530  
   531  for (i = 0; i < card->adapn; i++) {
   532  struct ptx_adap *adap   = >adap[i];
   533  struct pxq3pe_adap  *p  = adap->priv;
   534  
   535  p->sBufSize = PTX_TS_SIZE * 100 << 9;
 > 536  p->sBuf = vzalloc(p->sBufSize);
   537  if (!p->sBuf)
   538  return ptx_abort(pdev, pxq3pe_remove, -ENOMEM, 
"No memory for stream buffer");
   539  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [media 7/8] PCIE bridge driver for PT3 & PX-Q3PE

Hi Буди,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/media/pci/ptx/pxq3pe_pci.c: In function 'pxq3pe_remove':
   drivers/media/pci/ptx/pxq3pe_pci.c:484:3: error: implicit declaration of 
function 'vfree' [-Werror=implicit-function-declaration]
  vfree(p->sBuf);
  ^
   drivers/media/pci/ptx/pxq3pe_pci.c: In function 'pxq3pe_probe':
   drivers/media/pci/ptx/pxq3pe_pci.c:536:14: error: implicit declaration of 
function 'vzalloc' [-Werror=implicit-function-declaration]
  p->sBuf  = vzalloc(p->sBufSize);
 ^
>> drivers/media/pci/ptx/pxq3pe_pci.c:536:12: warning: assignment makes pointer 
>> from integer without a cast [-Wint-conversion]
  p->sBuf  = vzalloc(p->sBufSize);
   ^
   cc1: some warnings being treated as errors

vim +536 drivers/media/pci/ptx/pxq3pe_pci.c

   478  if (c->dma.dat)
   479  pci_free_consistent(card->pdev, c->dma.sz, c->dma.dat, 
c->dma.adr);
   480  for (i = 0; i < card->adapn; i++) {
   481  struct ptx_adap *adap   = >adap[i];
   482  struct pxq3pe_adap  *p  = adap->priv;
   483  
 > 484  vfree(p->sBuf);
   485  }
   486  if (c->bar)
   487  pci_iounmap(pdev, c->bar);
   488  ptx_unregister_adap(card);
   489  }
   490  
   491  static const struct i2c_algorithm pxq3pe_algo = {
   492  .functionality  = ptx_i2c_func,
   493  .master_xfer= pxq3pe_xfr,
   494  };
   495  
   496  static int pxq3pe_probe(struct pci_dev *pdev, const struct 
pci_device_id *pci_id)
   497  {
   498  struct ptx_subdev_info  pxq3pe_subdev_info[] = {
   499  {SYS_ISDBT, 0x20, TC90522_MODNAME, 0x10, NM131_MODNAME},
   500  {SYS_ISDBS, 0x22, TC90522_MODNAME, 0x11, 
TDA2014X_MODNAME},
   501  {SYS_ISDBT, 0x24, TC90522_MODNAME, 0x12, NM131_MODNAME},
   502  {SYS_ISDBS, 0x26, TC90522_MODNAME, 0x13, 
TDA2014X_MODNAME},
   503  {SYS_ISDBT, 0x28, TC90522_MODNAME, 0x14, NM131_MODNAME},
   504  {SYS_ISDBS, 0x2A, TC90522_MODNAME, 0x15, 
TDA2014X_MODNAME},
   505  {SYS_ISDBT, 0x2C, TC90522_MODNAME, 0x16, NM131_MODNAME},
   506  {SYS_ISDBS, 0x2E, TC90522_MODNAME, 0x17, 
TDA2014X_MODNAME},
   507  };
   508  struct ptx_card *card   = ptx_alloc(pdev, 
KBUILD_MODNAME, ARRAY_SIZE(pxq3pe_subdev_info),
   509  sizeof(struct 
pxq3pe_card), sizeof(struct pxq3pe_adap), pxq3pe_lnb);
   510  struct pxq3pe_card  *c;
   511  u8  regctl  = 0xA0,
   512  i;
   513  u16 cfg;
   514  int err = !card || pci_read_config_word(pdev, 
PCI_COMMAND, );
   515  
   516  if (err)
   517  return ptx_abort(pdev, pxq3pe_remove, err, "Memory/PCI 
error, card=%p", card);
   518  c   = card->priv;
   519  if (!(cfg & PCI_COMMAND_MASTER)) {
   520  pci_set_master(pdev);
   521  pci_read_config_word(pdev, PCI_COMMAND, );
   522  if (!(cfg & PCI_COMMAND_MASTER))
   523  return ptx_abort(pdev, pxq3pe_remove, -EIO, 
"Bus Mastering is disabled");
   524  }
   525  c->bar  = pci_iomap(pdev, 0, 0);
   526  if (!c->bar)
   527  return ptx_abort(pdev, pxq3pe_remove, -EIO, "I/O map 
failed");
   528  if (ptx_i2c_add_adapter(card, _algo))
   529  return ptx_abort(pdev, pxq3pe_remove, -EIO, "Cannot add 
I2C");
   530  
   531  for (i = 0; i < card->adapn; i++) {
   532  struct ptx_adap *adap   = >adap[i];
   533  struct pxq3pe_adap  *p  = adap->priv;
   534  
   535  p->sBufSize = PTX_TS_SIZE * 100 << 9;
 > 536  p->sBuf = vzalloc(p->sBufSize);
   537  if (!p->sBuf)
   538  return ptx_abort(pdev, pxq3pe_remove, -ENOMEM, 
"No memory for stream buffer");
   539  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [media 2/8] NXP tda2014x & Newport Media nm120/130/131 tuner (PXQ3PE)

Hi Буди,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-s0-04011126 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
 HEAD a28878c9675f849df56f4623c33ca431f03e240a builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> make[4]: *** No rule to make target 'drivers/media/tuners/qm1d1c004x.o', 
>> needed by 'drivers/media/tuners/built-in.o'.
   make[4]: Target '__build' not remade because of errors.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [media 2/8] NXP tda2014x & Newport Media nm120/130/131 tuner (PXQ3PE)

Hi Буди,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-s0-04011126 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
 HEAD a28878c9675f849df56f4623c33ca431f03e240a builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> make[4]: *** No rule to make target 'drivers/media/tuners/qm1d1c004x.o', 
>> needed by 'drivers/media/tuners/built-in.o'.
   make[4]: Target '__build' not remade because of errors.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[git pull] drm fixes

2016-03-31 Thread Dave Airlie


Hi Linus,

Nothing too crazy in here, a bunch of AMD fixes/quirks,
two msm, some rockchip fixes, and a udl warning fix,
along with one locking fix for displayport that seems
to fix some dodgy monitors.

Thanks,
Dave.

The following changes since commit c05c2ec96bb8b7310da1055c7b9d786a3ec6dc0c:

  Merge branch 'parisc-4.6-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux (2016-03-31 
07:55:14 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 72b9ff0612ad8fc969b910cd00ac16b57a1a9ba4:

  drm/udl: Use unlocked gem unreferencing (2016-04-01 13:22:33 +1000)


Alex Deucher (3):
  drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5
  drm/radeon: add another R7 370 quirk
  drm/radeon: add a dpm quirk for all R7 370 parts

Borislav Petkov (1):
  drm/amd: Beef up ACP Kconfig menu text

Daniel Vetter (1):
  drm/udl: Use unlocked gem unreferencing

Dave Airlie (3):
  Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'msm-fixes-4.6-rc1' of 
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge branch 'drm-rockchip-next-fixes-2016-03-28' of 
https://github.com/markyzq/kernel-drm-rockchip into drm-fixes

Douglas Anderson (3):
  drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path
  drm/rockchip: vop: Fix vop crtc cleanup
  drm/rockchip: dw_hdmi: Don't call platform_set_drvdata()

John Keeping (2):
  drm/rockchip: vop: fix crtc size in plane check
  drm/rockchip: cancel pending vblanks on close

Michel Dänzer (2):
  drm/radeon: Don't move pinned BOs
  drm/amdgpu: Don't move pinned BOs

Rob Clark (3):
  drm/msm: fix bug after preclose removal
  drm/msm: fix typo in the !COMMON_CLK case
  drm/dp: move hw_mutex up the call stack

Tomeu Vizoso (2):
  drm/rockchip: vop: Don't reject empty modesets
  drm/rockchip: vop: Disable planes when disabling CRTC

 drivers/gpu/drm/amd/acp/Kconfig |  8 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  4 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  6 +++
 drivers/gpu/drm/drm_dp_helper.c | 27 ++
 drivers/gpu/drm/msm/hdmi/hdmi.h |  2 +-
 drivers/gpu/drm/msm/msm_drv.c   |  3 --
 drivers/gpu/drm/msm/msm_kms.h   |  1 -
 drivers/gpu/drm/radeon/radeon_object.c  |  4 ++
 drivers/gpu/drm/radeon/radeon_ttm.c |  6 +++
 drivers/gpu/drm/radeon/si_dpm.c |  6 +++
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 22 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 79 -
 drivers/gpu/drm/udl/udl_fb.c|  2 +-
 drivers/gpu/drm/udl/udl_gem.c   |  2 +-
 16 files changed, 152 insertions(+), 34 deletions(-)

[git pull] drm fixes

2016-03-31 Thread Dave Airlie


Hi Linus,

Nothing too crazy in here, a bunch of AMD fixes/quirks,
two msm, some rockchip fixes, and a udl warning fix,
along with one locking fix for displayport that seems
to fix some dodgy monitors.

Thanks,
Dave.

The following changes since commit c05c2ec96bb8b7310da1055c7b9d786a3ec6dc0c:

  Merge branch 'parisc-4.6-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux (2016-03-31 
07:55:14 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 72b9ff0612ad8fc969b910cd00ac16b57a1a9ba4:

  drm/udl: Use unlocked gem unreferencing (2016-04-01 13:22:33 +1000)


Alex Deucher (3):
  drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5
  drm/radeon: add another R7 370 quirk
  drm/radeon: add a dpm quirk for all R7 370 parts

Borislav Petkov (1):
  drm/amd: Beef up ACP Kconfig menu text

Daniel Vetter (1):
  drm/udl: Use unlocked gem unreferencing

Dave Airlie (3):
  Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'msm-fixes-4.6-rc1' of 
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge branch 'drm-rockchip-next-fixes-2016-03-28' of 
https://github.com/markyzq/kernel-drm-rockchip into drm-fixes

Douglas Anderson (3):
  drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path
  drm/rockchip: vop: Fix vop crtc cleanup
  drm/rockchip: dw_hdmi: Don't call platform_set_drvdata()

John Keeping (2):
  drm/rockchip: vop: fix crtc size in plane check
  drm/rockchip: cancel pending vblanks on close

Michel Dänzer (2):
  drm/radeon: Don't move pinned BOs
  drm/amdgpu: Don't move pinned BOs

Rob Clark (3):
  drm/msm: fix bug after preclose removal
  drm/msm: fix typo in the !COMMON_CLK case
  drm/dp: move hw_mutex up the call stack

Tomeu Vizoso (2):
  drm/rockchip: vop: Don't reject empty modesets
  drm/rockchip: vop: Disable planes when disabling CRTC

 drivers/gpu/drm/amd/acp/Kconfig |  8 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  4 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  6 +++
 drivers/gpu/drm/drm_dp_helper.c | 27 ++
 drivers/gpu/drm/msm/hdmi/hdmi.h |  2 +-
 drivers/gpu/drm/msm/msm_drv.c   |  3 --
 drivers/gpu/drm/msm/msm_kms.h   |  1 -
 drivers/gpu/drm/radeon/radeon_object.c  |  4 ++
 drivers/gpu/drm/radeon/radeon_ttm.c |  6 +++
 drivers/gpu/drm/radeon/si_dpm.c |  6 +++
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 22 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 79 -
 drivers/gpu/drm/udl/udl_fb.c|  2 +-
 drivers/gpu/drm/udl/udl_gem.c   |  2 +-
 16 files changed, 152 insertions(+), 34 deletions(-)

Re: Re: [PATCH] zram: revive swap_slot_free_notify

2016-03-31 Thread Kyeongdon Kim

On Mon, Mar 28, 2016 at 11:30:56PM +0900, Minchan Kim wrote:
> On Fri, Mar 18, 2016 at 04:58:31PM +0900, Minchan Kim wrote:
>>  "remove compressed copy from zram in-memory"
>> applied swap_slot_free_notify call in *end_swap_bio_read* to
>> remove duplicated memory between zram and memory.
>>
>> However, with introducing rw_page in zram <8c7f01025f7b>
>> "zram: implement rw_page operation of zram", it became void
>> because rw_page doesn't need bio.
>>
>> This patch restores the function for rw_page.
>>
>> Signed-off-by: Minchan Kim 
>> ---
>> mm/page_io.c | 93
> 
>> 1 file changed, 50 insertions(+), 43 deletions(-)
>>
>> diff --git a/mm/page_io.c b/mm/page_io.c
>> index ff74e512f029..18aac7819cc9 100644
>> --- a/mm/page_io.c
>> +++ b/mm/page_io.c
>> @@ -66,6 +66,54 @@ void end_swap_bio_write(struct bio *bio)
>> bio_put(bio);
>> }
>>
>> +static void swap_slot_free_notify(struct page *page)
>> +{
>> + struct swap_info_struct *sis;
>> + struct gendisk *disk;
>> +
>> + /*
>> + * There is no guarantee that the page is in swap cache - the software
>> + * suspend code (at least) uses end_swap_bio_read() against a non-
>> + * swapcache page. So we must check PG_swapcache before proceeding with
>> + * this optimization.
>> + */
>> + if (unlikely(!PageSwapCache(page)))
>> + return;
>> +
>> + sis = page_swap_info(page);
>> + if (!(sis->flags & SWP_BLKDEV))
>> + return;
>> +
>> + /*
>> + * The swap subsystem performs lazy swap slot freeing,
>> + * expecting that the page will be swapped out again.
>> + * So we can avoid an unnecessary write if the page
>> + * isn't redirtied.
>> + * This is good for real swap storage because we can
>> + * reduce unnecessary I/O and enhance wear-leveling
>> + * if an SSD is used as the as swap device.
>> + * But if in-memory swap device (eg zram) is used,
>> + * this causes a duplicated copy between uncompressed
>> + * data in VM-owned memory and compressed data in
>> + * zram-owned memory. So let's free zram-owned memory
>> + * and make the VM-owned decompressed page *dirty*,
>> + * so the page should be swapped out somewhere again if
>> + * we again wish to reclaim it.
>> + */
>> + disk = sis->bdev->bd_disk;
>> + if (disk->fops->swap_slot_free_notify) {
>> + swp_entry_t entry;
>> + unsigned long offset;
>> +
>> + entry.val = page_private(page);
>> + offset = swp_offset(entry);
>> +
>> + SetPageDirty(page);
>> + disk->fops->swap_slot_free_notify(sis->bdev,
>> + offset);
>> + }
>> +}
>> +
>> static void end_swap_bio_read(struct bio *bio)
>> {
>> struct page *page = bio->bi_io_vec[0].bv_page;
>> @@ -81,49 +129,7 @@ static void end_swap_bio_read(struct bio *bio)
>> }
>>
>> SetPageUptodate(page);
>> -
>> - /*
>> - * There is no guarantee that the page is in swap cache - the software
>> - * suspend code (at least) uses end_swap_bio_read() against a non-
>> - * swapcache page. So we must check PG_swapcache before proceeding with
>> - * this optimization.
>> - */
>> - if (likely(PageSwapCache(page))) {
>> - struct swap_info_struct *sis;
>> -
>> - sis = page_swap_info(page);
>> - if (sis->flags & SWP_BLKDEV) {
>> - /*
>> - * The swap subsystem performs lazy swap slot freeing,
>> - * expecting that the page will be swapped out again.
>> - * So we can avoid an unnecessary write if the page
>> - * isn't redirtied.
>> - * This is good for real swap storage because we can
>> - * reduce unnecessary I/O and enhance wear-leveling
>> - * if an SSD is used as the as swap device.
>> - * But if in-memory swap device (eg zram) is used,
>> - * this causes a duplicated copy between uncompressed
>> - * data in VM-owned memory and compressed data in
>> - * zram-owned memory. So let's free zram-owned memory
>> - * and make the VM-owned decompressed page *dirty*,
>> - * so the page should be swapped out somewhere again if
>> - * we again wish to reclaim it.
>> - */
>> - struct gendisk *disk = sis->bdev->bd_disk;
>> - if (disk->fops->swap_slot_free_notify) {
>> - swp_entry_t entry;
>> - unsigned long offset;
>> -
>> - entry.val = page_private(page);
>> - offset = swp_offset(entry);
>> -
>> - SetPageDirty(page);
>> - disk->fops->swap_slot_free_notify(sis->bdev,
>> - offset);
>> - }
>> - }
>> - }
>> -
>> + swap_slot_free_notify(page);
>> out:
>> unlock_page(page);
>> bio_put(bio);
>> @@ -347,6 +353,7 @@ int swap_readpage(struct page *page)
>>
>> ret = bdev_read_page(sis->bdev, swap_page_sector(page), page);
>> if (!ret) {
>> + swap_slot_free_notify(page);
>> count_vm_event(PSWPIN);
>> return 0;
>> }
>> --
>> 1.9.1
>>
> 
> Kyeongdon, Could you try this patch?
> 
> From 09497ba48f5621cd2737f72ac4d15e6b3e5e3d14 Mon Sep 17 00:00:00 2001
> From: Minchan Kim 
> Date: Mon, 28 Mar 2016 23:08:14 +0900
> Subject: [PATCH] mm: call swap_slot_free_notify with holding page lock
> 
> Kyeongdon reported below error which is BUG_ON(!PageSwapCache(page))
> in page_swap_info.
> The reason is that page_endio in rw_page unlocks the

Re: Re: [PATCH] zram: revive swap_slot_free_notify

2016-03-31 Thread Kyeongdon Kim

On Mon, Mar 28, 2016 at 11:30:56PM +0900, Minchan Kim wrote:
> On Fri, Mar 18, 2016 at 04:58:31PM +0900, Minchan Kim wrote:
>>  "remove compressed copy from zram in-memory"
>> applied swap_slot_free_notify call in *end_swap_bio_read* to
>> remove duplicated memory between zram and memory.
>>
>> However, with introducing rw_page in zram <8c7f01025f7b>
>> "zram: implement rw_page operation of zram", it became void
>> because rw_page doesn't need bio.
>>
>> This patch restores the function for rw_page.
>>
>> Signed-off-by: Minchan Kim 
>> ---
>> mm/page_io.c | 93
> 
>> 1 file changed, 50 insertions(+), 43 deletions(-)
>>
>> diff --git a/mm/page_io.c b/mm/page_io.c
>> index ff74e512f029..18aac7819cc9 100644
>> --- a/mm/page_io.c
>> +++ b/mm/page_io.c
>> @@ -66,6 +66,54 @@ void end_swap_bio_write(struct bio *bio)
>> bio_put(bio);
>> }
>>
>> +static void swap_slot_free_notify(struct page *page)
>> +{
>> + struct swap_info_struct *sis;
>> + struct gendisk *disk;
>> +
>> + /*
>> + * There is no guarantee that the page is in swap cache - the software
>> + * suspend code (at least) uses end_swap_bio_read() against a non-
>> + * swapcache page. So we must check PG_swapcache before proceeding with
>> + * this optimization.
>> + */
>> + if (unlikely(!PageSwapCache(page)))
>> + return;
>> +
>> + sis = page_swap_info(page);
>> + if (!(sis->flags & SWP_BLKDEV))
>> + return;
>> +
>> + /*
>> + * The swap subsystem performs lazy swap slot freeing,
>> + * expecting that the page will be swapped out again.
>> + * So we can avoid an unnecessary write if the page
>> + * isn't redirtied.
>> + * This is good for real swap storage because we can
>> + * reduce unnecessary I/O and enhance wear-leveling
>> + * if an SSD is used as the as swap device.
>> + * But if in-memory swap device (eg zram) is used,
>> + * this causes a duplicated copy between uncompressed
>> + * data in VM-owned memory and compressed data in
>> + * zram-owned memory. So let's free zram-owned memory
>> + * and make the VM-owned decompressed page *dirty*,
>> + * so the page should be swapped out somewhere again if
>> + * we again wish to reclaim it.
>> + */
>> + disk = sis->bdev->bd_disk;
>> + if (disk->fops->swap_slot_free_notify) {
>> + swp_entry_t entry;
>> + unsigned long offset;
>> +
>> + entry.val = page_private(page);
>> + offset = swp_offset(entry);
>> +
>> + SetPageDirty(page);
>> + disk->fops->swap_slot_free_notify(sis->bdev,
>> + offset);
>> + }
>> +}
>> +
>> static void end_swap_bio_read(struct bio *bio)
>> {
>> struct page *page = bio->bi_io_vec[0].bv_page;
>> @@ -81,49 +129,7 @@ static void end_swap_bio_read(struct bio *bio)
>> }
>>
>> SetPageUptodate(page);
>> -
>> - /*
>> - * There is no guarantee that the page is in swap cache - the software
>> - * suspend code (at least) uses end_swap_bio_read() against a non-
>> - * swapcache page. So we must check PG_swapcache before proceeding with
>> - * this optimization.
>> - */
>> - if (likely(PageSwapCache(page))) {
>> - struct swap_info_struct *sis;
>> -
>> - sis = page_swap_info(page);
>> - if (sis->flags & SWP_BLKDEV) {
>> - /*
>> - * The swap subsystem performs lazy swap slot freeing,
>> - * expecting that the page will be swapped out again.
>> - * So we can avoid an unnecessary write if the page
>> - * isn't redirtied.
>> - * This is good for real swap storage because we can
>> - * reduce unnecessary I/O and enhance wear-leveling
>> - * if an SSD is used as the as swap device.
>> - * But if in-memory swap device (eg zram) is used,
>> - * this causes a duplicated copy between uncompressed
>> - * data in VM-owned memory and compressed data in
>> - * zram-owned memory. So let's free zram-owned memory
>> - * and make the VM-owned decompressed page *dirty*,
>> - * so the page should be swapped out somewhere again if
>> - * we again wish to reclaim it.
>> - */
>> - struct gendisk *disk = sis->bdev->bd_disk;
>> - if (disk->fops->swap_slot_free_notify) {
>> - swp_entry_t entry;
>> - unsigned long offset;
>> -
>> - entry.val = page_private(page);
>> - offset = swp_offset(entry);
>> -
>> - SetPageDirty(page);
>> - disk->fops->swap_slot_free_notify(sis->bdev,
>> - offset);
>> - }
>> - }
>> - }
>> -
>> + swap_slot_free_notify(page);
>> out:
>> unlock_page(page);
>> bio_put(bio);
>> @@ -347,6 +353,7 @@ int swap_readpage(struct page *page)
>>
>> ret = bdev_read_page(sis->bdev, swap_page_sector(page), page);
>> if (!ret) {
>> + swap_slot_free_notify(page);
>> count_vm_event(PSWPIN);
>> return 0;
>> }
>> --
>> 1.9.1
>>
> 
> Kyeongdon, Could you try this patch?
> 
> From 09497ba48f5621cd2737f72ac4d15e6b3e5e3d14 Mon Sep 17 00:00:00 2001
> From: Minchan Kim 
> Date: Mon, 28 Mar 2016 23:08:14 +0900
> Subject: [PATCH] mm: call swap_slot_free_notify with holding page lock
> 
> Kyeongdon reported below error which is BUG_ON(!PageSwapCache(page))
> in page_swap_info.
> The reason is that page_endio in rw_page unlocks the page if read I/O
> is completed so we need

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

2016-03-31 Thread Rajesh Bhagat



> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]
> Sent: Thursday, March 31, 2016 8:07 PM
> To: Rajesh Bhagat 
> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Sriram Dash 
> Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI
> commmand timeout
> 
> On 31.03.2016 06:51, Rajesh Bhagat wrote:
> >
> >
> >
> > Hello Mathias,
> >
> > Thanks a lot for your support.
> >
> > Attached patch is working and allows the completion handler to be
> > called. And resume operation completes and shell comes back (but with lot of
> errors).
> >
> > Now, some other points which needs our attention here are:
> > 1. usb core hub code is not checking the error status of hcd->driver-
> >reset_device(xhci_discover_or_reset_device)
> >  and continues considering reset_device was successful (and causes 
> > other issues).
> Hence, a check is needed on return
> >  value of reset_device and proper action is required on it.
> > 2. Even if above return value is checked and reset_device status is used. 
> > USB core
> hub retries for N times which is not
> >  required in this case as adding to the resume operation time. But if 
> > in this case
> we return -ENOTCONN instead of -EINVAL
> >  from hcd->driver->reset_device(xhci_discover_or_reset_device), code 
> > returns
> early and doesn't retry.
> >
> > Proposed Solution for above with your suggested patches is as below:
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> > 7cad1fa..efeba31 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -2807,13 +2807,17 @@ done:
> >  struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> >
> >  update_devnum(udev, 0);
> > -   /* The xHC may think the device is already reset,
> > -* so ignore the status.
> > +   /*
> > +* check the status of resetting the device and 
> > update
> > +* the udev status.
> >   */
> >  if (hcd->driver->reset_device)
> > -   hcd->driver->reset_device(hcd, udev);
> > +   status =
> > + hcd->driver->reset_device(hcd, udev);
> >
> > -   usb_set_device_state(udev, USB_STATE_DEFAULT);
> > +   if (status == 0)
> > +   usb_set_device_state(udev, 
> > USB_STATE_DEFAULT);
> > +   else
> > +   usb_set_device_state(udev,
> > + USB_STATE_NOTATTACHED);
> >  }
> >  } else {
> >  if (udev)
> > diff --git a/drivers/usb/host/xhci-ring.c
> > b/drivers/usb/host/xhci-ring.c index b3a0a22..9427175f 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -310,6 +310,10 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
> >  return -ESHUTDOWN;
> >  }
> >
> > +   /* writing the CMD_RING_ABORT bit should create a command completion
> > +* event, add a command completion timeout for it as well
> > +*/
> > +   mod_timer(>cmd_timer, jiffies +
> > + XHCI_CMD_DEFAULT_TIMEOUT);
> >  return 0;
> >   }
> >
> > @@ -1243,6 +1247,7 @@ void xhci_handle_command_timeout(unsigned long data)
> >  int ret;
> >  unsigned long flags;
> >  u64 hw_ring_state;
> > +   u32 old_status;
> >  struct xhci_command *cur_cmd = NULL;
> >  xhci = (struct xhci_hcd *) data;
> >
> > @@ -1250,6 +1255,7 @@ void xhci_handle_command_timeout(unsigned long data)
> >  spin_lock_irqsave(>lock, flags);
> >  if (xhci->current_cmd) {
> >  cur_cmd = xhci->current_cmd;
> > +   old_status = cur_cmd->status;
> >  cur_cmd->status = COMP_CMD_ABORT;
> >  }
> >
> > @@ -1272,7 +1278,15 @@ void xhci_handle_command_timeout(unsigned long
> data)
> >  }
> >  /* command timeout on stopped ring, ring can't be aborted */
> >  xhci_dbg(xhci, "Command timeout on stopped ring\n");
> > -   xhci_handle_stopped_cmd_ring(xhci, xhci->current_cmd);
> > +
> > +   /* is this the second timeout for the same command? ring wont 
> > restart */
> > +   if (old_status == COMP_CMD_ABORT) {
> > +   xhci_err(xhci, "Abort timeout, Fail to restart cmd ring\n");
> > +   xhci_cleanup_command_queue(xhci);
> > +   /* everything else here to halt, cleanup, free etc kill xhc */
> > +   } else
> > +   xhci_handle_stopped_cmd_ring(xhci, xhci->current_cmd);
> > +
> >  spin_unlock_irqrestore(>lock, flags);
> >  return;
> >   }
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index
> >

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

2016-03-31 Thread Rajesh Bhagat



> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]
> Sent: Thursday, March 31, 2016 8:07 PM
> To: Rajesh Bhagat 
> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Sriram Dash 
> Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI
> commmand timeout
> 
> On 31.03.2016 06:51, Rajesh Bhagat wrote:
> >
> >
> >
> > Hello Mathias,
> >
> > Thanks a lot for your support.
> >
> > Attached patch is working and allows the completion handler to be
> > called. And resume operation completes and shell comes back (but with lot of
> errors).
> >
> > Now, some other points which needs our attention here are:
> > 1. usb core hub code is not checking the error status of hcd->driver-
> >reset_device(xhci_discover_or_reset_device)
> >  and continues considering reset_device was successful (and causes 
> > other issues).
> Hence, a check is needed on return
> >  value of reset_device and proper action is required on it.
> > 2. Even if above return value is checked and reset_device status is used. 
> > USB core
> hub retries for N times which is not
> >  required in this case as adding to the resume operation time. But if 
> > in this case
> we return -ENOTCONN instead of -EINVAL
> >  from hcd->driver->reset_device(xhci_discover_or_reset_device), code 
> > returns
> early and doesn't retry.
> >
> > Proposed Solution for above with your suggested patches is as below:
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> > 7cad1fa..efeba31 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -2807,13 +2807,17 @@ done:
> >  struct usb_hcd *hcd = bus_to_hcd(udev->bus);
> >
> >  update_devnum(udev, 0);
> > -   /* The xHC may think the device is already reset,
> > -* so ignore the status.
> > +   /*
> > +* check the status of resetting the device and 
> > update
> > +* the udev status.
> >   */
> >  if (hcd->driver->reset_device)
> > -   hcd->driver->reset_device(hcd, udev);
> > +   status =
> > + hcd->driver->reset_device(hcd, udev);
> >
> > -   usb_set_device_state(udev, USB_STATE_DEFAULT);
> > +   if (status == 0)
> > +   usb_set_device_state(udev, 
> > USB_STATE_DEFAULT);
> > +   else
> > +   usb_set_device_state(udev,
> > + USB_STATE_NOTATTACHED);
> >  }
> >  } else {
> >  if (udev)
> > diff --git a/drivers/usb/host/xhci-ring.c
> > b/drivers/usb/host/xhci-ring.c index b3a0a22..9427175f 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -310,6 +310,10 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
> >  return -ESHUTDOWN;
> >  }
> >
> > +   /* writing the CMD_RING_ABORT bit should create a command completion
> > +* event, add a command completion timeout for it as well
> > +*/
> > +   mod_timer(>cmd_timer, jiffies +
> > + XHCI_CMD_DEFAULT_TIMEOUT);
> >  return 0;
> >   }
> >
> > @@ -1243,6 +1247,7 @@ void xhci_handle_command_timeout(unsigned long data)
> >  int ret;
> >  unsigned long flags;
> >  u64 hw_ring_state;
> > +   u32 old_status;
> >  struct xhci_command *cur_cmd = NULL;
> >  xhci = (struct xhci_hcd *) data;
> >
> > @@ -1250,6 +1255,7 @@ void xhci_handle_command_timeout(unsigned long data)
> >  spin_lock_irqsave(>lock, flags);
> >  if (xhci->current_cmd) {
> >  cur_cmd = xhci->current_cmd;
> > +   old_status = cur_cmd->status;
> >  cur_cmd->status = COMP_CMD_ABORT;
> >  }
> >
> > @@ -1272,7 +1278,15 @@ void xhci_handle_command_timeout(unsigned long
> data)
> >  }
> >  /* command timeout on stopped ring, ring can't be aborted */
> >  xhci_dbg(xhci, "Command timeout on stopped ring\n");
> > -   xhci_handle_stopped_cmd_ring(xhci, xhci->current_cmd);
> > +
> > +   /* is this the second timeout for the same command? ring wont 
> > restart */
> > +   if (old_status == COMP_CMD_ABORT) {
> > +   xhci_err(xhci, "Abort timeout, Fail to restart cmd ring\n");
> > +   xhci_cleanup_command_queue(xhci);
> > +   /* everything else here to halt, cleanup, free etc kill xhc */
> > +   } else
> > +   xhci_handle_stopped_cmd_ring(xhci, xhci->current_cmd);
> > +
> >  spin_unlock_irqrestore(>lock, flags);
> >  return;
> >   }
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index
> > c502c22..bd18966 100644
> > ---

[PATCH] perf tools: Fix build errors on tsc functions for archs other than x86

2016-03-31 Thread He Kuang

Build errors on aarch64:

  libperf.a(libperf-in.o): In function `convert_timestamp':
  util/jitdump.c:356: undefined reference to `tsc_to_perf_time'
  collect2: error: ld returned 1 exit status
  Makefile.perf:347: recipe for target 'perf' failed
  make[1]: *** [perf] Error 1
  Makefile:68: recipe for target 'all' failed
  make: *** [all] Error 2

Since tsc conversion functions were moved out from arch dir, move
'tsc.h' out from x86 dir to make it possible to compile for other archs.

Signed-off-by: He Kuang 
---
 tools/perf/arch/x86/util/tsc.c |  1 -
 tools/perf/arch/x86/util/tsc.h | 17 -
 tools/perf/util/Build  |  3 +--
 tools/perf/util/tsc.h  | 11 ++-
 4 files changed, 11 insertions(+), 21 deletions(-)
 delete mode 100644 tools/perf/arch/x86/util/tsc.h

diff --git a/tools/perf/arch/x86/util/tsc.c b/tools/perf/arch/x86/util/tsc.c
index 70ff7c1..357f1b1 100644
--- a/tools/perf/arch/x86/util/tsc.c
+++ b/tools/perf/arch/x86/util/tsc.c
@@ -7,7 +7,6 @@
 #include 
 #include "../../util/debug.h"
 #include "../../util/tsc.h"
-#include "tsc.h"
 
 int perf_read_tsc_conversion(const struct perf_event_mmap_page *pc,
 struct perf_tsc_conversion *tc)
diff --git a/tools/perf/arch/x86/util/tsc.h b/tools/perf/arch/x86/util/tsc.h
deleted file mode 100644
index 2edc4d3..000
--- a/tools/perf/arch/x86/util/tsc.h
+++ /dev/null
@@ -1,17 +0,0 @@
-#ifndef TOOLS_PERF_ARCH_X86_UTIL_TSC_H__
-#define TOOLS_PERF_ARCH_X86_UTIL_TSC_H__
-
-#include 
-
-struct perf_tsc_conversion {
-   u16 time_shift;
-   u32 time_mult;
-   u64 time_zero;
-};
-
-struct perf_event_mmap_page;
-
-int perf_read_tsc_conversion(const struct perf_event_mmap_page *pc,
-struct perf_tsc_conversion *tc);
-
-#endif /* TOOLS_PERF_ARCH_X86_UTIL_TSC_H__ */
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index da48fd8..85ceff3 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -69,8 +69,7 @@ libperf-y += stat-shadow.o
 libperf-y += record.o
 libperf-y += srcline.o
 libperf-y += data.o
-libperf-$(CONFIG_X86) += tsc.o
-libperf-$(CONFIG_AUXTRACE) += tsc.o
+libperf-y += tsc.o
 libperf-y += cloexec.o
 libperf-y += thread-stack.o
 libperf-$(CONFIG_AUXTRACE) += auxtrace.o
diff --git a/tools/perf/util/tsc.h b/tools/perf/util/tsc.h
index 280ddc0..d5b11e2 100644
--- a/tools/perf/util/tsc.h
+++ b/tools/perf/util/tsc.h
@@ -4,7 +4,16 @@
 #include 
 
 #include "event.h"
-#include "../arch/x86/util/tsc.h"
+
+struct perf_tsc_conversion {
+   u16 time_shift;
+   u32 time_mult;
+   u64 time_zero;
+};
+struct perf_event_mmap_page;
+
+int perf_read_tsc_conversion(const struct perf_event_mmap_page *pc,
+struct perf_tsc_conversion *tc);
 
 u64 perf_time_to_tsc(u64 ns, struct perf_tsc_conversion *tc);
 u64 tsc_to_perf_time(u64 cyc, struct perf_tsc_conversion *tc);
-- 
1.8.5.2

[PATCH] perf tools: Fix build errors on tsc functions for archs other than x86

2016-03-31 Thread He Kuang

Build errors on aarch64:

  libperf.a(libperf-in.o): In function `convert_timestamp':
  util/jitdump.c:356: undefined reference to `tsc_to_perf_time'
  collect2: error: ld returned 1 exit status
  Makefile.perf:347: recipe for target 'perf' failed
  make[1]: *** [perf] Error 1
  Makefile:68: recipe for target 'all' failed
  make: *** [all] Error 2

Since tsc conversion functions were moved out from arch dir, move
'tsc.h' out from x86 dir to make it possible to compile for other archs.

Signed-off-by: He Kuang 
---
 tools/perf/arch/x86/util/tsc.c |  1 -
 tools/perf/arch/x86/util/tsc.h | 17 -
 tools/perf/util/Build  |  3 +--
 tools/perf/util/tsc.h  | 11 ++-
 4 files changed, 11 insertions(+), 21 deletions(-)
 delete mode 100644 tools/perf/arch/x86/util/tsc.h

diff --git a/tools/perf/arch/x86/util/tsc.c b/tools/perf/arch/x86/util/tsc.c
index 70ff7c1..357f1b1 100644
--- a/tools/perf/arch/x86/util/tsc.c
+++ b/tools/perf/arch/x86/util/tsc.c
@@ -7,7 +7,6 @@
 #include 
 #include "../../util/debug.h"
 #include "../../util/tsc.h"
-#include "tsc.h"
 
 int perf_read_tsc_conversion(const struct perf_event_mmap_page *pc,
 struct perf_tsc_conversion *tc)
diff --git a/tools/perf/arch/x86/util/tsc.h b/tools/perf/arch/x86/util/tsc.h
deleted file mode 100644
index 2edc4d3..000
--- a/tools/perf/arch/x86/util/tsc.h
+++ /dev/null
@@ -1,17 +0,0 @@
-#ifndef TOOLS_PERF_ARCH_X86_UTIL_TSC_H__
-#define TOOLS_PERF_ARCH_X86_UTIL_TSC_H__
-
-#include 
-
-struct perf_tsc_conversion {
-   u16 time_shift;
-   u32 time_mult;
-   u64 time_zero;
-};
-
-struct perf_event_mmap_page;
-
-int perf_read_tsc_conversion(const struct perf_event_mmap_page *pc,
-struct perf_tsc_conversion *tc);
-
-#endif /* TOOLS_PERF_ARCH_X86_UTIL_TSC_H__ */
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index da48fd8..85ceff3 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -69,8 +69,7 @@ libperf-y += stat-shadow.o
 libperf-y += record.o
 libperf-y += srcline.o
 libperf-y += data.o
-libperf-$(CONFIG_X86) += tsc.o
-libperf-$(CONFIG_AUXTRACE) += tsc.o
+libperf-y += tsc.o
 libperf-y += cloexec.o
 libperf-y += thread-stack.o
 libperf-$(CONFIG_AUXTRACE) += auxtrace.o
diff --git a/tools/perf/util/tsc.h b/tools/perf/util/tsc.h
index 280ddc0..d5b11e2 100644
--- a/tools/perf/util/tsc.h
+++ b/tools/perf/util/tsc.h
@@ -4,7 +4,16 @@
 #include 
 
 #include "event.h"
-#include "../arch/x86/util/tsc.h"
+
+struct perf_tsc_conversion {
+   u16 time_shift;
+   u32 time_mult;
+   u64 time_zero;
+};
+struct perf_event_mmap_page;
+
+int perf_read_tsc_conversion(const struct perf_event_mmap_page *pc,
+struct perf_tsc_conversion *tc);
 
 u64 perf_time_to_tsc(u64 ns, struct perf_tsc_conversion *tc);
 u64 tsc_to_perf_time(u64 cyc, struct perf_tsc_conversion *tc);
-- 
1.8.5.2

Re: [PATCH v3 0/3] Rockchip: rk3399: Add core dtsi for rk3399

2016-03-31 Thread Xing Zheng


Hi Heiko,
I also updated some clock patches for RK3399 recently, and I will 
continue to update clock patches_V7 in future.

Please note them. :-)

Thanks.

On 2016年04月01日 11:23, Heiko Stuebner wrote:

Hi Jianqun,

Am Freitag, 1. April 2016, 10:55:09 schrieb jay.xu:

After talking with xing, we plan to summit dtsi after xing's patches are
applied,
and I will update the patch for rk3399 core dtsi quickly

Not sure if you have seen it, but I picked up Xing's most recent clock
patches already [0]. So go ahead when you have time :-)


Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.7-clk/next



On 2016年04月01日 05:48, Heiko Stuebner wrote:

Hi Jianqun,

Am Dienstag, 1. März 2016, 14:39:58 schrieb Jianqun Xu:

There is the new SoCs from Rockchip which named rk3399, the
patches are added to support them.

is this still valid or does it need an update?
The clock-series from Xing saw changes, so I'm guessing the devicetree
side might also need some update?

Especially an actual board-file would be nice ;-) .


Thanks
Heiko







--
- Xing Zheng

Re: [PATCH v3 0/3] Rockchip: rk3399: Add core dtsi for rk3399

2016-03-31 Thread Xing Zheng


Hi Heiko,
I also updated some clock patches for RK3399 recently, and I will 
continue to update clock patches_V7 in future.

Please note them. :-)

Thanks.

On 2016年04月01日 11:23, Heiko Stuebner wrote:

Hi Jianqun,

Am Freitag, 1. April 2016, 10:55:09 schrieb jay.xu:

After talking with xing, we plan to summit dtsi after xing's patches are
applied,
and I will update the patch for rk3399 core dtsi quickly

Not sure if you have seen it, but I picked up Xing's most recent clock
patches already [0]. So go ahead when you have time :-)


Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.7-clk/next



On 2016年04月01日 05:48, Heiko Stuebner wrote:

Hi Jianqun,

Am Dienstag, 1. März 2016, 14:39:58 schrieb Jianqun Xu:

There is the new SoCs from Rockchip which named rk3399, the
patches are added to support them.

is this still valid or does it need an update?
The clock-series from Xing saw changes, so I'm guessing the devicetree
side might also need some update?

Especially an actual board-file would be nice ;-) .


Thanks
Heiko







--
- Xing Zheng

Re: linux-next: manual merge of the tty tree with the tty.current tree

2016-03-31 Thread Greg KH

On Thu, Mar 31, 2016 at 05:23:27PM -0700, Peter Hurley wrote:
> On Sun, Feb 7, 2016 at 6:21 PM, Greg KH  wrote:
> > On Mon, Feb 08, 2016 at 01:16:29PM +1100, Stephen Rothwell wrote:
> >> Hi Greg,
> >>
> >> Today's linux-next merge of the tty tree got a conflict in:
> >>
> >>   drivers/tty/tty_io.c
> >>
> >> between commit:
> >>
> >>   e9036d066236 ("tty: Drop krefs for interrupted tty lock")
> >>
> >> from the tty.current tree and commit:
> >>
> >>   d6203d0c7b73 ("tty: Refactor tty_open()")
> >>
> >> from the tty tree.
> >>
> >> I fixed it up (I think - see below) and can carry the fix as necessary
> >> (no action is required).
> >>
> >> --
> >> Cheers,
> >> Stephen Rothwell
> >>
> >> diff --cc drivers/tty/tty_io.c
> >> index a7eacef1bd22,8d26ed79bb4c..
> >> --- a/drivers/tty/tty_io.c
> >> +++ b/drivers/tty/tty_io.c
> >> @@@ -2004,6 -2009,69 +2009,68 @@@ static struct tty_driver *tty_lookup_dr
> >>   }
> >>
> >>   /**
> >> +  *  tty_open_by_driver  -   open a tty device
> >> +  *  @device: dev_t of device to open
> >> +  *  @inode: inode of device file
> >> +  *  @filp: file pointer to tty
> >> +  *
> >> +  *  Performs the driver lookup, checks for a reopen, or otherwise
> >> +  *  performs the first-time tty initialization.
> >> +  *
> >> +  *  Returns the locked initialized or re-opened _struct
> >> +  *
> >> +  *  Claims the global tty_mutex to serialize:
> >> +  *- concurrent first-time tty initialization
> >> +  *- concurrent tty driver removal w/ lookup
> >> +  *- concurrent tty removal from driver table
> >> +  */
> >> + static struct tty_struct *tty_open_by_driver(dev_t device, struct inode 
> >> *inode,
> >> +  struct file *filp)
> >> + {
> >> + struct tty_struct *tty;
> >> + struct tty_driver *driver = NULL;
> >> + int index = -1;
> >> + int retval;
> >> +
> >> + mutex_lock(_mutex);
> >> + driver = tty_lookup_driver(device, filp, );
> >> + if (IS_ERR(driver)) {
> >> + mutex_unlock(_mutex);
> >> + return ERR_CAST(driver);
> >> + }
> >> +
> >> + /* check whether we're reopening an existing tty */
> >> + tty = tty_driver_lookup_tty(driver, inode, index);
> >> + if (IS_ERR(tty)) {
> >> + mutex_unlock(_mutex);
> >> + goto out;
> >> + }
> >> +
> >> + if (tty) {
> >> + mutex_unlock(_mutex);
> >> + retval = tty_lock_interruptible(tty);
> >> ++tty_kref_put(tty);  /* drop kref from 
> >> tty_driver_lookup_tty() */
> >> + if (retval) {
> >> + if (retval == -EINTR)
> >> + retval = -ERESTARTSYS;
> >> + tty = ERR_PTR(retval);
> >> + goto out;
> >> + }
> >>  -/* safe to drop the kref from tty_driver_lookup_tty() */
> >>  -tty_kref_put(tty);
> >> + retval = tty_reopen(tty);
> >> + if (retval < 0) {
> >> + tty_unlock(tty);
> >> + tty = ERR_PTR(retval);
> >> + }
> >> + } else { /* Returns with the tty_lock held for now */
> >> + tty = tty_init_dev(driver, index);
> >> + mutex_unlock(_mutex);
> >> + }
> >> + out:
> >> + tty_driver_kref_put(driver);
> >> + return tty;
> >> + }
> >> +
> >> + /**
> >>*  tty_open-   open a tty device
> >>*  @inode: inode of device file
> >>*  @filp: file pointer to tty
> >
> > Peter warned me this was going to happen...
> >
> > Peter, is the merge above correct?
> 
> Greg, this merge correction did not make it into 4.6-rc1.
> 
> Was I supposed to send a separate patch for this merge change?
> Should I now?

The patch you sent should be fine, thanks.

greg k-h

Re: linux-next: manual merge of the tty tree with the tty.current tree

2016-03-31 Thread Greg KH

On Thu, Mar 31, 2016 at 05:23:27PM -0700, Peter Hurley wrote:
> On Sun, Feb 7, 2016 at 6:21 PM, Greg KH  wrote:
> > On Mon, Feb 08, 2016 at 01:16:29PM +1100, Stephen Rothwell wrote:
> >> Hi Greg,
> >>
> >> Today's linux-next merge of the tty tree got a conflict in:
> >>
> >>   drivers/tty/tty_io.c
> >>
> >> between commit:
> >>
> >>   e9036d066236 ("tty: Drop krefs for interrupted tty lock")
> >>
> >> from the tty.current tree and commit:
> >>
> >>   d6203d0c7b73 ("tty: Refactor tty_open()")
> >>
> >> from the tty tree.
> >>
> >> I fixed it up (I think - see below) and can carry the fix as necessary
> >> (no action is required).
> >>
> >> --
> >> Cheers,
> >> Stephen Rothwell
> >>
> >> diff --cc drivers/tty/tty_io.c
> >> index a7eacef1bd22,8d26ed79bb4c..
> >> --- a/drivers/tty/tty_io.c
> >> +++ b/drivers/tty/tty_io.c
> >> @@@ -2004,6 -2009,69 +2009,68 @@@ static struct tty_driver *tty_lookup_dr
> >>   }
> >>
> >>   /**
> >> +  *  tty_open_by_driver  -   open a tty device
> >> +  *  @device: dev_t of device to open
> >> +  *  @inode: inode of device file
> >> +  *  @filp: file pointer to tty
> >> +  *
> >> +  *  Performs the driver lookup, checks for a reopen, or otherwise
> >> +  *  performs the first-time tty initialization.
> >> +  *
> >> +  *  Returns the locked initialized or re-opened _struct
> >> +  *
> >> +  *  Claims the global tty_mutex to serialize:
> >> +  *- concurrent first-time tty initialization
> >> +  *- concurrent tty driver removal w/ lookup
> >> +  *- concurrent tty removal from driver table
> >> +  */
> >> + static struct tty_struct *tty_open_by_driver(dev_t device, struct inode 
> >> *inode,
> >> +  struct file *filp)
> >> + {
> >> + struct tty_struct *tty;
> >> + struct tty_driver *driver = NULL;
> >> + int index = -1;
> >> + int retval;
> >> +
> >> + mutex_lock(_mutex);
> >> + driver = tty_lookup_driver(device, filp, );
> >> + if (IS_ERR(driver)) {
> >> + mutex_unlock(_mutex);
> >> + return ERR_CAST(driver);
> >> + }
> >> +
> >> + /* check whether we're reopening an existing tty */
> >> + tty = tty_driver_lookup_tty(driver, inode, index);
> >> + if (IS_ERR(tty)) {
> >> + mutex_unlock(_mutex);
> >> + goto out;
> >> + }
> >> +
> >> + if (tty) {
> >> + mutex_unlock(_mutex);
> >> + retval = tty_lock_interruptible(tty);
> >> ++tty_kref_put(tty);  /* drop kref from 
> >> tty_driver_lookup_tty() */
> >> + if (retval) {
> >> + if (retval == -EINTR)
> >> + retval = -ERESTARTSYS;
> >> + tty = ERR_PTR(retval);
> >> + goto out;
> >> + }
> >>  -/* safe to drop the kref from tty_driver_lookup_tty() */
> >>  -tty_kref_put(tty);
> >> + retval = tty_reopen(tty);
> >> + if (retval < 0) {
> >> + tty_unlock(tty);
> >> + tty = ERR_PTR(retval);
> >> + }
> >> + } else { /* Returns with the tty_lock held for now */
> >> + tty = tty_init_dev(driver, index);
> >> + mutex_unlock(_mutex);
> >> + }
> >> + out:
> >> + tty_driver_kref_put(driver);
> >> + return tty;
> >> + }
> >> +
> >> + /**
> >>*  tty_open-   open a tty device
> >>*  @inode: inode of device file
> >>*  @filp: file pointer to tty
> >
> > Peter warned me this was going to happen...
> >
> > Peter, is the merge above correct?
> 
> Greg, this merge correction did not make it into 4.6-rc1.
> 
> Was I supposed to send a separate patch for this merge change?
> Should I now?

The patch you sent should be fine, thanks.

greg k-h

Re: [media 7/8] PCIE bridge driver for PT3 & PX-Q3PE

Hi Буди,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
base:   git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/media/pci/ptx/ptx_common.c:187:536: error: 'KBUILD_MODNAME' 
>> undeclared here (not in a function)
>> drivers/media/pci/ptx/ptx_common.c:187:551: error: expected ',' or ';' 
>> before string constant

vim +/KBUILD_MODNAME +187 drivers/media/pci/ptx/ptx_common.c

   181  pci_release_regions(card->pdev);
   182  pci_set_drvdata(card->pdev, NULL);
   183  pci_disable_device(card->pdev);
   184  kfree(card);
   185  }
   186  
 > 187  DVB_DEFINE_MOD_OPT_ADAPTER_NR(adap_no);
   188  int ptx_register_adap(struct ptx_card *card, const struct 
ptx_subdev_info *info,
   189  int (*thread)(void *), int (*dma)(struct 
ptx_adap *, bool))
   190  {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [media 7/8] PCIE bridge driver for PT3 & PX-Q3PE

Hi Буди,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/info-are-ma/DVB-driver-for-Earthsoft-PT3-PLEX-PX-Q3PE-ISDB-S-T-PCIE-cards-PX-BCUD-ISDB-S-USB-dongle/20160401-034740
base:   git://linuxtv.org/media_tree.git master
config: i386-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/media/pci/ptx/ptx_common.c:187:536: error: 'KBUILD_MODNAME' 
>> undeclared here (not in a function)
>> drivers/media/pci/ptx/ptx_common.c:187:551: error: expected ',' or ';' 
>> before string constant

vim +/KBUILD_MODNAME +187 drivers/media/pci/ptx/ptx_common.c

   181  pci_release_regions(card->pdev);
   182  pci_set_drvdata(card->pdev, NULL);
   183  pci_disable_device(card->pdev);
   184  kfree(card);
   185  }
   186  
 > 187  DVB_DEFINE_MOD_OPT_ADAPTER_NR(adap_no);
   188  int ptx_register_adap(struct ptx_card *card, const struct 
ptx_subdev_info *info,
   189  int (*thread)(void *), int (*dma)(struct 
ptx_adap *, bool))
   190  {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCHSET v3][RFC] Make background writeback not suck


On 03/31/2016 09:29 PM, Jens Axboe wrote:

I can't seem to reproduce this at all. On an nvme device, I get a
fairly steady 60K/sec file creation rate, and we're nowhere near
being IO bound. So the throttling has no effect at all.


That's too slow to show the stalls - your likely concurrency bound
in allocation by the default AG count (4) from mkfs. Use mkfs.xfs -d
agcount=32 so that every thread works in it's own AG.


That's the key, with that I get 300-400K ops/sec instead. I'll run some
testing with this tomorrow and see what I can find, it did one full run
now and I didn't see any issues, but I need to run it at various
settings and see if I can find the issue.


No stalls seen, I get the same performance with it disabled and with it 
enabled, at both default settings, and lower ones (wb_percent=20). 
Looking at iostat, we don't drive a lot of depth, so it makes sense, 
even with the throttling we're doing essentially the same amount of IO.


What does 'nr_requests' say for your virtio_blk device? Looks like 
virtio_blk has a queue_depth setting, but it's not set by default, and 
then it uses the free entries in the ring. But I don't know what that is...


--
Jens Axboe

Re: [PATCHSET v3][RFC] Make background writeback not suck


On 03/31/2016 09:29 PM, Jens Axboe wrote:

I can't seem to reproduce this at all. On an nvme device, I get a
fairly steady 60K/sec file creation rate, and we're nowhere near
being IO bound. So the throttling has no effect at all.


That's too slow to show the stalls - your likely concurrency bound
in allocation by the default AG count (4) from mkfs. Use mkfs.xfs -d
agcount=32 so that every thread works in it's own AG.


That's the key, with that I get 300-400K ops/sec instead. I'll run some
testing with this tomorrow and see what I can find, it did one full run
now and I didn't see any issues, but I need to run it at various
settings and see if I can find the issue.


No stalls seen, I get the same performance with it disabled and with it 
enabled, at both default settings, and lower ones (wb_percent=20). 
Looking at iostat, we don't drive a lot of depth, so it makes sense, 
even with the throttling we're doing essentially the same amount of IO.


What does 'nr_requests' say for your virtio_blk device? Looks like 
virtio_blk has a queue_depth setting, but it's not set by default, and 
then it uses the free entries in the ring. But I don't know what that is...


--
Jens Axboe

Re: [PATCHSET v3][RFC] Make background writeback not suck


On 03/31/2016 09:29 PM, Jens Axboe wrote:

I'm not changing the host kernels - it's a production machine and so
it runs long uptime testing of stable kernels.  (e.g. catch slow
memory leaks, etc). So if you've disabled throttling in the guest, I
can't test the throttling changes.


Right, that'd definitely hide the problem for you. I'll see if I can get
it in a reproducible state and take it from there.


Though on the guest, if you could try with just this one applied:

http://git.kernel.dk/cgit/linux-block/commit/?h=wb-buf-throttle=f21fb0e42c7347bd639a17341dcd3f72c1a30d29

I'd appreciate it. It won't disable the throttling in the guest, just 
treat META and PRIO a bit differently.


--
Jens Axboe

Re: [PATCHSET v3][RFC] Make background writeback not suck


On 03/31/2016 09:29 PM, Jens Axboe wrote:

I'm not changing the host kernels - it's a production machine and so
it runs long uptime testing of stable kernels.  (e.g. catch slow
memory leaks, etc). So if you've disabled throttling in the guest, I
can't test the throttling changes.


Right, that'd definitely hide the problem for you. I'll see if I can get
it in a reproducible state and take it from there.


Though on the guest, if you could try with just this one applied:

http://git.kernel.dk/cgit/linux-block/commit/?h=wb-buf-throttle=f21fb0e42c7347bd639a17341dcd3f72c1a30d29

I'd appreciate it. It won't disable the throttling in the guest, just 
treat META and PRIO a bit differently.


--
Jens Axboe

[v7, 2/5] soc: fsl: add GUTS driver for QorIQ platforms

The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.

This patch adds GUTS driver to manage and access global utilities
block.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
---
 drivers/soc/Kconfig  |   2 +-
 drivers/soc/fsl/Kconfig  |   8 
 drivers/soc/fsl/Makefile |   1 +
 drivers/soc/fsl/guts.c   | 119 +++
 include/linux/fsl/guts.h |  98 +++---
 5 files changed, 179 insertions(+), 49 deletions(-)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/guts.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/bcm/Kconfig"
 source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+   bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct guts {
+   struct ccsr_guts __iomem *regs;
+   bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+   u32 svr = 0;
+
+   if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+   svr =  mfspr(SPRN_SVR);
+#endif
+   return svr;
+   }
+
+   if (guts->little_endian)
+   svr = ioread32(>regs->svr);
+   else
+   svr = ioread32be(>regs->svr);
+
+   return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+   /* For T4 & B4 Series SOCs */
+   { .compatible = "fsl,qoriq-device-config-1.0", },
+   /* For P Series SOCs */
+   { .compatible = "fsl,qoriq-device-config-2.0", },
+   { .compatible = "fsl,p1010-guts", },
+   { .compatible = "fsl,p1020-guts", },
+   { .compatible = "fsl,p1021-guts", },
+   { .compatible = "fsl,p1022-guts", },
+   { .compatible = "fsl,p1023-guts", },
+   { .compatible = "fsl,p2020-guts", },
+   /* For BSC Series SOCs */
+   { .compatible = "fsl,bsc9131-guts", },
+   { .compatible = "fsl,bsc9132-guts", },
+   /* For MPC85xx Series SOCs */
+   { .compatible = "fsl,mpc8536-guts", },
+   { .compatible = "fsl,mpc8544-guts", },
+   { .compatible = "fsl,mpc8548-guts", },
+   { .compatible = "fsl,mpc8568-guts", },
+   { .compatible = "fsl,mpc8569-guts", },
+   { .compatible = "fsl,mpc8572-guts", },
+   /* For Layerscape Series SOCs */
+   { .compatible = "fsl,ls1021a-dcfg", },
+   { .compatible = "fsl,ls1043a-dcfg", },
+   { .compatible = "fsl,ls2080a-dcfg", },
+   {}
+};
+
+int fsl_guts_init(void)
+{
+   struct device_node *np;
+

[v7, 2/5] soc: fsl: add GUTS driver for QorIQ platforms

The global utilities block controls power management, I/O device
enabling, power-onreset(POR) configuration monitoring, alternate
function selection for multiplexed signals,and clock control.

This patch adds GUTS driver to manage and access global utilities
block.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- Added this patch
Changes for v5:
- Modified copyright info
- Changed MODULE_LICENSE to GPL
- Changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL
- Made FSL_GUTS user-invisible
- Added a complete compatible list for GUTS
- Stored guts info in file-scope variable
- Added mfspr() getting SVR
- Redefined GUTS APIs
- Called fsl_guts_init rather than using platform driver
- Removed useless parentheses
- Removed useless 'extern' key words
Changes for v6:
- Made guts thread safe in fsl_guts_init
Changes for v7:
- Removed 'ifdef' for function declaration in guts.h
---
 drivers/soc/Kconfig  |   2 +-
 drivers/soc/fsl/Kconfig  |   8 
 drivers/soc/fsl/Makefile |   1 +
 drivers/soc/fsl/guts.c   | 119 +++
 include/linux/fsl/guts.h |  98 +++---
 5 files changed, 179 insertions(+), 49 deletions(-)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/guts.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..7106463 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,7 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/bcm/Kconfig"
 source "drivers/soc/brcmstb/Kconfig"
-source "drivers/soc/fsl/qe/Kconfig"
+source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/rockchip/Kconfig"
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
new file mode 100644
index 000..b313759
--- /dev/null
+++ b/drivers/soc/fsl/Kconfig
@@ -0,0 +1,8 @@
+#
+# Freescale SOC drivers
+#
+
+source "drivers/soc/fsl/qe/Kconfig"
+
+config FSL_GUTS
+   bool
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 203307f..02afb7f 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_QUICC_ENGINE) += qe/
 obj-$(CONFIG_CPM)  += qe/
+obj-$(CONFIG_FSL_GUTS) += guts.o
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
new file mode 100644
index 000..fa155e6
--- /dev/null
+++ b/drivers/soc/fsl/guts.c
@@ -0,0 +1,119 @@
+/*
+ * Freescale QorIQ Platforms GUTS Driver
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct guts {
+   struct ccsr_guts __iomem *regs;
+   bool little_endian;
+};
+
+static struct guts *guts;
+static DEFINE_MUTEX(guts_lock);
+
+u32 fsl_guts_get_svr(void)
+{
+   u32 svr = 0;
+
+   if (!guts || !guts->regs) {
+#ifdef CONFIG_PPC
+   svr =  mfspr(SPRN_SVR);
+#endif
+   return svr;
+   }
+
+   if (guts->little_endian)
+   svr = ioread32(>regs->svr);
+   else
+   svr = ioread32be(>regs->svr);
+
+   return svr;
+}
+EXPORT_SYMBOL(fsl_guts_get_svr);
+
+/*
+ * Table for matching compatible strings, for device tree
+ * guts node, for Freescale QorIQ SOCs.
+ */
+static const struct of_device_id guts_of_match[] = {
+   /* For T4 & B4 Series SOCs */
+   { .compatible = "fsl,qoriq-device-config-1.0", },
+   /* For P Series SOCs */
+   { .compatible = "fsl,qoriq-device-config-2.0", },
+   { .compatible = "fsl,p1010-guts", },
+   { .compatible = "fsl,p1020-guts", },
+   { .compatible = "fsl,p1021-guts", },
+   { .compatible = "fsl,p1022-guts", },
+   { .compatible = "fsl,p1023-guts", },
+   { .compatible = "fsl,p2020-guts", },
+   /* For BSC Series SOCs */
+   { .compatible = "fsl,bsc9131-guts", },
+   { .compatible = "fsl,bsc9132-guts", },
+   /* For MPC85xx Series SOCs */
+   { .compatible = "fsl,mpc8536-guts", },
+   { .compatible = "fsl,mpc8544-guts", },
+   { .compatible = "fsl,mpc8548-guts", },
+   { .compatible = "fsl,mpc8568-guts", },
+   { .compatible = "fsl,mpc8569-guts", },
+   { .compatible = "fsl,mpc8572-guts", },
+   /* For Layerscape Series SOCs */
+   { .compatible = "fsl,ls1021a-dcfg", },
+   { .compatible = "fsl,ls1043a-dcfg", },
+   { .compatible = "fsl,ls2080a-dcfg", },
+   {}
+};
+
+int fsl_guts_init(void)
+{
+   struct device_node *np;
+   int ret;
+
+

Re: [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization

2016-03-31 Thread Guenter Roeck


On 03/31/2016 06:33 PM, Greg Ungerer wrote:

On 01/04/16 10:53, Guenter Roeck wrote:

On Fri, Apr 01, 2016 at 10:29:11AM +1000, Greg Ungerer wrote:

Hi Guenter,

On 01/04/16 01:11, Guenter Roeck wrote:

Since commit ff2b13592299 ("gpio: make the gpiochip a real device"),
attempts to add a gpio chip prior to gpiolib initialization cause
the system to crash. This happens because gpio_bus_type has not been
registered yet. Defer creating gpio devices until after gpiolib has
been initialized to fix the problem.

Cc: Greg Ungerer 
Cc: Alexandre Courbot 
Fixes: ff2b13592299 ("gpio: make the gpiochip a real device")
Signed-off-by: Guenter Roeck 


Thanks for putting these patches together.
I can now boot all my boards again with them applied :-)

But, I am seeing an issue on one of my targets during boot:

...
Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 
1911260446275 ns
[ cut here ]
WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31 0x000da0e6
sysfs: cannot create duplicate filename '/bus/gpio'
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-rc1-dirty #1
Stack from 0383de38:
 0383de38 0021f692 00027eb0 03841000 002134f2 038261b0 0382f688 00111c1e
 00027efe 0021ccc4 001f 000da0e6 0009  0383de74 0021cc91
 0383de90 0383df8c 000da0e6 0021ccc4 001f 0021cc91 03841000 002134f2
 038261b0 0382f688  000da1f0 038261b0 002134f2 0382f688 0382f688
 00111d86 0382f688  0382f688 0382f688 0382f680 0024fe84 0002118e
 0383df8c 0382f688 00112094 0382f688  0013f5dc 0382f680 0001
Call Trace:
  ...
---[ end trace 013025e2024d8831 ]---
[ cut here ]
WARNING: CPU: 0 PID: 1 at lib/kobject.c:240 0x00111fc0
kobject_add_internal failed for gpio with -EEXIST, don't try to register things 
with the same name in the same directory.
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Tainted: GW   4.6.0-rc1-dirty #1
Stack from 0383de68:
 0383de68 0021f692 00027eb0 ffef 0382f688  0382f688 00111a26
 00027efe 0021f817 00f0 00111fc0 0009  0383dea4 0021f8cd
 0383dec0 0383df8c 00111fc0 0021f817 00f0 0021f8cd 002069e9 002134f2
 0382f688 0382f680 0024fe84 0002118e 0383df8c 0382f688 00112094 0382f688
  0013f5dc 0382f680 0001 001f 002600de 00265950 0002118e
 0383df8c 002600f2 0024fe84 0001 002600de 00265950 0002118e 00021274
Call Trace:
...
---[ end trace 013025e2024d8832 ]---
gpiolib: could not register GPIO bus type
NET: Registered protocol family 16


Probably coldfire ?

arch/m68k/coldfire/gpio.c:


Yes, that is the one.



static struct bus_type mcfgpio_subsys = {
 .name   = "gpio",
.dev_name   = "gpio",
};

No idea what to do about that. Can that bus be renamed ?


Yeah, it could. But is it even necessary at all now?

I am thinking I could remove the subsys_system_register(_subsys, NULL)
call from that coldfire/gpio.c. Doing that certainly cleans up the
boot. There was nothing much under the old coldfire /sys/gpio other than
the standard devices/drivers/etc. And the new gpio api ofcourse has all
that as well.


Sure, if that works for you.

Guenter


Regards
Greg



The boot otherwise continues and is successful.


Thanks for testing!

Guenter


Regards
Greg



---
  drivers/gpio/gpiolib.c | 98 ++
  1 file changed, 67 insertions(+), 31 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f1531070814d..8bb24dc8dc3d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -68,6 +68,7 @@ LIST_HEAD(gpio_devices);
  static void gpiochip_free_hogs(struct gpio_chip *chip);
  static void gpiochip_irqchip_remove(struct gpio_chip *gpiochip);

+static bool gpiolib_initialized;

  static inline void desc_set_label(struct gpio_desc *d, const char *label)
  {
@@ -445,6 +446,58 @@ static void gpiodevice_release(struct device *dev)
kfree(gdev);
  }

+static int gpiochip_setup_dev(struct gpio_device *gdev)
+{
+   int status;
+
+   cdev_init(>chrdev, _fileops);
+   gdev->chrdev.owner = THIS_MODULE;
+   gdev->chrdev.kobj.parent = >dev.kobj;
+   gdev->dev.devt = MKDEV(MAJOR(gpio_devt), gdev->id);
+   status = cdev_add(>chrdev, gdev->dev.devt, 1);
+   if (status < 0)
+   chip_warn(gdev->chip, "failed to add char device %d:%d\n",
+ MAJOR(gpio_devt), gdev->id);
+   else
+   chip_dbg(gdev->chip, "added GPIO chardev (%d:%d)\n",
+MAJOR(gpio_devt), gdev->id);
+   status = device_add(>dev);
+   if (status)
+   goto err_remove_chardev;
+
+   status =

Re: [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization

2016-03-31 Thread Guenter Roeck


On 03/31/2016 06:33 PM, Greg Ungerer wrote:

On 01/04/16 10:53, Guenter Roeck wrote:

On Fri, Apr 01, 2016 at 10:29:11AM +1000, Greg Ungerer wrote:

Hi Guenter,

On 01/04/16 01:11, Guenter Roeck wrote:

Since commit ff2b13592299 ("gpio: make the gpiochip a real device"),
attempts to add a gpio chip prior to gpiolib initialization cause
the system to crash. This happens because gpio_bus_type has not been
registered yet. Defer creating gpio devices until after gpiolib has
been initialized to fix the problem.

Cc: Greg Ungerer 
Cc: Alexandre Courbot 
Fixes: ff2b13592299 ("gpio: make the gpiochip a real device")
Signed-off-by: Guenter Roeck 


Thanks for putting these patches together.
I can now boot all my boards again with them applied :-)

But, I am seeing an issue on one of my targets during boot:

...
Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 
1911260446275 ns
[ cut here ]
WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31 0x000da0e6
sysfs: cannot create duplicate filename '/bus/gpio'
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-rc1-dirty #1
Stack from 0383de38:
 0383de38 0021f692 00027eb0 03841000 002134f2 038261b0 0382f688 00111c1e
 00027efe 0021ccc4 001f 000da0e6 0009  0383de74 0021cc91
 0383de90 0383df8c 000da0e6 0021ccc4 001f 0021cc91 03841000 002134f2
 038261b0 0382f688  000da1f0 038261b0 002134f2 0382f688 0382f688
 00111d86 0382f688  0382f688 0382f688 0382f680 0024fe84 0002118e
 0383df8c 0382f688 00112094 0382f688  0013f5dc 0382f680 0001
Call Trace:
  ...
---[ end trace 013025e2024d8831 ]---
[ cut here ]
WARNING: CPU: 0 PID: 1 at lib/kobject.c:240 0x00111fc0
kobject_add_internal failed for gpio with -EEXIST, don't try to register things 
with the same name in the same directory.
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Tainted: GW   4.6.0-rc1-dirty #1
Stack from 0383de68:
 0383de68 0021f692 00027eb0 ffef 0382f688  0382f688 00111a26
 00027efe 0021f817 00f0 00111fc0 0009  0383dea4 0021f8cd
 0383dec0 0383df8c 00111fc0 0021f817 00f0 0021f8cd 002069e9 002134f2
 0382f688 0382f680 0024fe84 0002118e 0383df8c 0382f688 00112094 0382f688
  0013f5dc 0382f680 0001 001f 002600de 00265950 0002118e
 0383df8c 002600f2 0024fe84 0001 002600de 00265950 0002118e 00021274
Call Trace:
...
---[ end trace 013025e2024d8832 ]---
gpiolib: could not register GPIO bus type
NET: Registered protocol family 16


Probably coldfire ?

arch/m68k/coldfire/gpio.c:


Yes, that is the one.



static struct bus_type mcfgpio_subsys = {
 .name   = "gpio",
.dev_name   = "gpio",
};

No idea what to do about that. Can that bus be renamed ?


Yeah, it could. But is it even necessary at all now?

I am thinking I could remove the subsys_system_register(_subsys, NULL)
call from that coldfire/gpio.c. Doing that certainly cleans up the
boot. There was nothing much under the old coldfire /sys/gpio other than
the standard devices/drivers/etc. And the new gpio api ofcourse has all
that as well.


Sure, if that works for you.

Guenter


Regards
Greg



The boot otherwise continues and is successful.


Thanks for testing!

Guenter


Regards
Greg



---
  drivers/gpio/gpiolib.c | 98 ++
  1 file changed, 67 insertions(+), 31 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f1531070814d..8bb24dc8dc3d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -68,6 +68,7 @@ LIST_HEAD(gpio_devices);
  static void gpiochip_free_hogs(struct gpio_chip *chip);
  static void gpiochip_irqchip_remove(struct gpio_chip *gpiochip);

+static bool gpiolib_initialized;

  static inline void desc_set_label(struct gpio_desc *d, const char *label)
  {
@@ -445,6 +446,58 @@ static void gpiodevice_release(struct device *dev)
kfree(gdev);
  }

+static int gpiochip_setup_dev(struct gpio_device *gdev)
+{
+   int status;
+
+   cdev_init(>chrdev, _fileops);
+   gdev->chrdev.owner = THIS_MODULE;
+   gdev->chrdev.kobj.parent = >dev.kobj;
+   gdev->dev.devt = MKDEV(MAJOR(gpio_devt), gdev->id);
+   status = cdev_add(>chrdev, gdev->dev.devt, 1);
+   if (status < 0)
+   chip_warn(gdev->chip, "failed to add char device %d:%d\n",
+ MAJOR(gpio_devt), gdev->id);
+   else
+   chip_dbg(gdev->chip, "added GPIO chardev (%d:%d)\n",
+MAJOR(gpio_devt), gdev->id);
+   status = device_add(>dev);
+   if (status)
+   goto err_remove_chardev;
+
+   status = gpiochip_sysfs_register(gdev);
+   if (status)
+

Re: [PATCH v2] vfs: constify arguments to utime family of system calls

2016-03-31 Thread Al Viro

On Thu, Mar 31, 2016 at 09:24:57PM -0500, Eric Biggers wrote:

> I feel it's a small improvement as it reduces the chance of bugs.  However, if
> you look at all the system calls, they are, in general, inconsistent about 
> using
> 'const'.  So may be right that changing just a few isn't worthwhile.

It might very well be worth doing a full series, though - after all,
they are not hard to grep for ((COMPAT_)?SYSCALL_DEFINE[0-6] would get
you almost all of them, with rest consisting of weird shit in arch/*
that more often than not would be better off switched to SYSCALL_DEFINE).

The reason why it's worth doing completely or not at all is that partial
series will serve as an invitation to the alt.sex.masturbation.commit.count
crowd, with the usual quality of output...

Re: [PATCH v2] vfs: constify arguments to utime family of system calls

2016-03-31 Thread Al Viro

On Thu, Mar 31, 2016 at 09:24:57PM -0500, Eric Biggers wrote:

> I feel it's a small improvement as it reduces the chance of bugs.  However, if
> you look at all the system calls, they are, in general, inconsistent about 
> using
> 'const'.  So may be right that changing just a few isn't worthwhile.

It might very well be worth doing a full series, though - after all,
they are not hard to grep for ((COMPAT_)?SYSCALL_DEFINE[0-6] would get
you almost all of them, with rest consisting of weird shit in arch/*
that more often than not would be better off switched to SYSCALL_DEFINE).

The reason why it's worth doing completely or not at all is that partial
series will serve as an invitation to the alt.sex.masturbation.commit.count
crowd, with the usual quality of output...

Re: [PATCHSET v3][RFC] Make background writeback not suck

On 03/31/2016 06:56 PM, Dave Chinner wrote:

On Thu, Mar 31, 2016 at 10:21:04AM -0600, Jens Axboe wrote:

On 03/31/2016 08:29 AM, Jens Axboe wrote:

What I see in these performance dips is the XFS transaction
subsystem stalling *completely* - instead of running at a steady
state of around 350,000 transactions/s, there are *zero*
transactions running for periods of up to ten seconds. This
co-incides with the CPU usage falling to almost zero as well.
AFAICT, the only thing that is running when the filesystem stalls
like this is memory reclaim.

I'll take a look at this, stalls should definitely not be occurring. How
much memory does the box have?

I can't seem to reproduce this at all. On an nvme device, I get a
fairly steady 60K/sec file creation rate, and we're nowhere near
being IO bound. So the throttling has no effect at all.

That's too slow to show the stalls - your likely concurrency bound
in allocation by the default AG count (4) from mkfs. Use mkfs.xfs -d
agcount=32 so that every thread works in it's own AG.

That's the key, with that I get 300-400K ops/sec instead. I'll run some
testing with this tomorrow and see what I can find, it did one full run
now and I didn't see any issues, but I need to run it at various
settings and see if I can find the issue.

On a raid0 on 4 flash devices, I get something that looks more IO
bound, for some reason. Still no impact of the throttling, however.
But given that your setup is this:

virtio in guest, XFS direct IO -> no-op -> scsi in host.

we do potentially have two throttling points, which we don't want.
Is both the guest and the host running the new code, or just the
guest?

Just the guest. Host is running a 4.2.x kernel, IIRC.

In any case, can I talk you into trying with two patches on top of
the current code? It's the two newest patches here:

https://urldefense.proofpoint.com/v2/url?u=http-3A__git.kernel.dk_cgit_linux-2Dblock_log_-3Fh-3Dwb-2Dbuf-2Dthrottle=CwIBAg=5VD0RTtNlTh3ycd41b3MUw=cK1a7KivzZRh1fKQMjSm2A=68CEi93IKLje5aOoxk1y9HMe_HF9pAhzxJGTmTZ7_DY=NeYNPvJa3VdF_EEsL8VqAQzJ4UycbXZ5PzHihwZAc_A=

The first treats REQ_META|REQ_PRIO like they should be treated, like
high priority IO. The second disables throttling for virtual
devices, so we only throttle on the backend. The latter should
probably be the other way around, but we need some way of conveying
that information to the backend.

I'm not changing the host kernels - it's a production machine and so
it runs long uptime testing of stable kernels. (e.g. catch slow
memory leaks, etc). So if you've disabled throttling in the guest, I
can't test the throttling changes.

Right, that'd definitely hide the problem for you. I'll see if I can get
it in a reproducible state and take it from there.

On your host, you said it's SCSI backed, but what does the device look like?

--
Jens Axboe

[RFC PATCH] genirq: Change the non-balanced irq to balance irq when the cpu of the irq bounded off line

2016-03-31 Thread MaJun

From: Ma Jun 

When the CPU of a non-balanced irq bounded is off line, the irq will be 
migrated to other CPUs,
usually the first cpu on-line.

We can suppose the situation if a system has more than one non-balanced irq.
At extreme case, these irqs will be migrated to the same CPU and will cause the 
CPU run with high irq pressure, even make the system die.

So, I think maybe we need to change the non-balanced irq to a irq can be
balanced to avoid the problem descried above.

Maybe this is not a good solution for this problem, please offer me some
suggestion if you have a better one.

Signed-off-by: Ma Jun 
---
 kernel/irq/cpuhotplug.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c
index 011f8c4..80d54a5 100644
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -30,6 +30,8 @@ static bool migrate_one_irq(struct irq_desc *desc)
return false;
 
if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
+   if (irq_settings_has_no_balance_set(desc))
+   irqd_clear(d, IRQD_NO_BALANCING);
affinity = cpu_online_mask;
ret = true;
}
-- 
1.7.1

[RFC PATCH] genirq: Change the non-balanced irq to balance irq when the cpu of the irq bounded off line

2016-03-31 Thread MaJun

From: Ma Jun 

When the CPU of a non-balanced irq bounded is off line, the irq will be 
migrated to other CPUs,
usually the first cpu on-line.

We can suppose the situation if a system has more than one non-balanced irq.
At extreme case, these irqs will be migrated to the same CPU and will cause the 
CPU run with high irq pressure, even make the system die.

So, I think maybe we need to change the non-balanced irq to a irq can be
balanced to avoid the problem descried above.

Maybe this is not a good solution for this problem, please offer me some
suggestion if you have a better one.

Signed-off-by: Ma Jun 
---
 kernel/irq/cpuhotplug.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c
index 011f8c4..80d54a5 100644
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -30,6 +30,8 @@ static bool migrate_one_irq(struct irq_desc *desc)
return false;
 
if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
+   if (irq_settings_has_no_balance_set(desc))
+   irqd_clear(d, IRQD_NO_BALANCING);
affinity = cpu_online_mask;
ret = true;
}
-- 
1.7.1

Re: [PATCHSET v3][RFC] Make background writeback not suck

On 03/31/2016 06:56 PM, Dave Chinner wrote:

On Thu, Mar 31, 2016 at 10:21:04AM -0600, Jens Axboe wrote:

On 03/31/2016 08:29 AM, Jens Axboe wrote:

I'll take a look at this, stalls should definitely not be occurring. How
much memory does the box have?

I can't seem to reproduce this at all. On an nvme device, I get a
fairly steady 60K/sec file creation rate, and we're nowhere near
being IO bound. So the throttling has no effect at all.

That's too slow to show the stalls - your likely concurrency bound
in allocation by the default AG count (4) from mkfs. Use mkfs.xfs -d
agcount=32 so that every thread works in it's own AG.

On a raid0 on 4 flash devices, I get something that looks more IO
bound, for some reason. Still no impact of the throttling, however.
But given that your setup is this:

virtio in guest, XFS direct IO -> no-op -> scsi in host.

we do potentially have two throttling points, which we don't want.
Is both the guest and the host running the new code, or just the
guest?

Just the guest. Host is running a 4.2.x kernel, IIRC.

In any case, can I talk you into trying with two patches on top of
the current code? It's the two newest patches here:

Right, that'd definitely hide the problem for you. I'll see if I can get
it in a reproducible state and take it from there.

On your host, you said it's SCSI backed, but what does the device look like?

--
Jens Axboe

Re: [PATCHSET v3][RFC] Make background writeback not suck


On 03/31/2016 06:46 PM, Dave Chinner wrote:

On Thu, Mar 31, 2016 at 08:29:35AM -0600, Jens Axboe wrote:

On 03/31/2016 02:24 AM, Dave Chinner wrote:

On Wed, Mar 30, 2016 at 09:07:48AM -0600, Jens Axboe wrote:

Hi,

This patchset isn't as much a final solution, as it's demonstration
of what I believe is a huge issue. Since the dawn of time, our
background buffered writeback has sucked. When we do background
buffered writeback, it should have little impact on foreground
activity. That's the definition of background activity... But for as
long as I can remember, heavy buffered writers has not behaved like
that. For instance, if I do something like this:

$ dd if=/dev/zero of=foo bs=1M count=10k

on my laptop, and then try and start chrome, it basically won't start
before the buffered writeback is done. Or, for server oriented
workloads, where installation of a big RPM (or similar) adversely
impacts data base reads or sync writes. When that happens, I get people
yelling at me.

Last time I posted this, I used flash storage as the example. But
this works equally well on rotating storage. Let's run a test case
that writes a lot. This test writes 50 files, each 100M, on XFS on
a regular hard drive. While this happens, we attempt to read
another file with fio.

Writers:

$ time (./write-files ; sync)
real1m6.304s
user0m0.020s
sys 0m12.210s


Great. So a basic IO tests looks good - let's through something more
complex at it. Say, a benchmark I've been using for years to stress
the Io subsystem, the filesystem and memory reclaim all at the same
time: a concurent fsmark inode creation test.
(first google hit https://lkml.org/lkml/2013/9/10/46)


Is that how you are invoking it as well same arguments?


Yes. And the VM is exactly the same, too - 16p/16GB RAM. Cut down
version of the script I use:

#!/bin/bash

QUOTA=
MKFSOPTS=
NFILES=10
DEV=/dev/vdc
LOGBSIZE=256k
FSMARK=/home/dave/src/fs_mark-3.3/fs_mark
MNT=/mnt/scratch

while [ $# -gt 0 ]; do
 case "$1" in
 -q) QUOTA="uquota,gquota,pquota" ;;
 -N) NFILES=$2 ; shift ;;
 -d) DEV=$2 ; shift ;;
 -l) LOGBSIZE=$2; shift ;;
 --) shift ; break ;;
 esac
 shift
done
MKFSOPTS="$MKFSOPTS $*"

echo QUOTA=$QUOTA
echo MKFSOPTS=$MKFSOPTS
echo DEV=$DEV

sudo umount $MNT > /dev/null 2>&1
sudo mkfs.xfs -f $MKFSOPTS $DEV
sudo mount -o nobarrier,logbsize=$LOGBSIZE,$QUOTA $DEV $MNT
sudo chmod 777 $MNT
sudo sh -c "echo 1 > /proc/sys/fs/xfs/stats_clear"
time $FSMARK  -D  1  -S0  -n  $NFILES  -s  0  -L  32 \
 -d  $MNT/0  -d  $MNT/1 \
 -d  $MNT/2  -d  $MNT/3 \
 -d  $MNT/4  -d  $MNT/5 \
 -d  $MNT/6  -d  $MNT/7 \
 -d  $MNT/8  -d  $MNT/9 \
 -d  $MNT/10  -d  $MNT/11 \
 -d  $MNT/12  -d  $MNT/13 \
 -d  $MNT/14  -d  $MNT/15 \
 | tee >(stats --trim-outliers | tail -1 1>&2)
sync
sudo umount /mnt/scratch


Perfect, thanks!


The above was run without scsi-mq, and with using the deadline scheduler,
results with CFQ are similary depressing for this test. So IO scheduling
is in place for this test, it's not pure blk-mq without scheduling.


virtio in guest, XFS direct IO -> no-op -> scsi in host.


That has write back caching enabled on the guest, correct?


No. It uses virtio,cache=none (that's the "XFS Direct IO" bit above).
Sorry for not being clear about that.


That's fine, it's one less worry if that's not the case. So if you cat 
the 'write_cache' file in the virtioblk sysfs block queue/ directory, it 
says 'write through'? Just want to confirm that we got that propagated 
correctly.



--
Jens Axboe

Re: [PATCHSET v3][RFC] Make background writeback not suck


On 03/31/2016 06:46 PM, Dave Chinner wrote:

On Thu, Mar 31, 2016 at 08:29:35AM -0600, Jens Axboe wrote:

On 03/31/2016 02:24 AM, Dave Chinner wrote:

On Wed, Mar 30, 2016 at 09:07:48AM -0600, Jens Axboe wrote:

Hi,

This patchset isn't as much a final solution, as it's demonstration
of what I believe is a huge issue. Since the dawn of time, our
background buffered writeback has sucked. When we do background
buffered writeback, it should have little impact on foreground
activity. That's the definition of background activity... But for as
long as I can remember, heavy buffered writers has not behaved like
that. For instance, if I do something like this:

$ dd if=/dev/zero of=foo bs=1M count=10k

on my laptop, and then try and start chrome, it basically won't start
before the buffered writeback is done. Or, for server oriented
workloads, where installation of a big RPM (or similar) adversely
impacts data base reads or sync writes. When that happens, I get people
yelling at me.

Last time I posted this, I used flash storage as the example. But
this works equally well on rotating storage. Let's run a test case
that writes a lot. This test writes 50 files, each 100M, on XFS on
a regular hard drive. While this happens, we attempt to read
another file with fio.

Writers:

$ time (./write-files ; sync)
real1m6.304s
user0m0.020s
sys 0m12.210s


Great. So a basic IO tests looks good - let's through something more
complex at it. Say, a benchmark I've been using for years to stress
the Io subsystem, the filesystem and memory reclaim all at the same
time: a concurent fsmark inode creation test.
(first google hit https://lkml.org/lkml/2013/9/10/46)


Is that how you are invoking it as well same arguments?


Yes. And the VM is exactly the same, too - 16p/16GB RAM. Cut down
version of the script I use:

#!/bin/bash

QUOTA=
MKFSOPTS=
NFILES=10
DEV=/dev/vdc
LOGBSIZE=256k
FSMARK=/home/dave/src/fs_mark-3.3/fs_mark
MNT=/mnt/scratch

while [ $# -gt 0 ]; do
 case "$1" in
 -q) QUOTA="uquota,gquota,pquota" ;;
 -N) NFILES=$2 ; shift ;;
 -d) DEV=$2 ; shift ;;
 -l) LOGBSIZE=$2; shift ;;
 --) shift ; break ;;
 esac
 shift
done
MKFSOPTS="$MKFSOPTS $*"

echo QUOTA=$QUOTA
echo MKFSOPTS=$MKFSOPTS
echo DEV=$DEV

sudo umount $MNT > /dev/null 2>&1
sudo mkfs.xfs -f $MKFSOPTS $DEV
sudo mount -o nobarrier,logbsize=$LOGBSIZE,$QUOTA $DEV $MNT
sudo chmod 777 $MNT
sudo sh -c "echo 1 > /proc/sys/fs/xfs/stats_clear"
time $FSMARK  -D  1  -S0  -n  $NFILES  -s  0  -L  32 \
 -d  $MNT/0  -d  $MNT/1 \
 -d  $MNT/2  -d  $MNT/3 \
 -d  $MNT/4  -d  $MNT/5 \
 -d  $MNT/6  -d  $MNT/7 \
 -d  $MNT/8  -d  $MNT/9 \
 -d  $MNT/10  -d  $MNT/11 \
 -d  $MNT/12  -d  $MNT/13 \
 -d  $MNT/14  -d  $MNT/15 \
 | tee >(stats --trim-outliers | tail -1 1>&2)
sync
sudo umount /mnt/scratch


Perfect, thanks!


The above was run without scsi-mq, and with using the deadline scheduler,
results with CFQ are similary depressing for this test. So IO scheduling
is in place for this test, it's not pure blk-mq without scheduling.


virtio in guest, XFS direct IO -> no-op -> scsi in host.


That has write back caching enabled on the guest, correct?


No. It uses virtio,cache=none (that's the "XFS Direct IO" bit above).
Sorry for not being clear about that.


That's fine, it's one less worry if that's not the case. So if you cat 
the 'write_cache' file in the virtioblk sysfs block queue/ directory, it 
says 'write through'? Just want to confirm that we got that propagated 
correctly.



--
Jens Axboe

Re: [PATCH v3 0/3] Rockchip: rk3399: Add core dtsi for rk3399

2016-03-31 Thread Heiko Stuebner

Hi Jianqun,

Am Freitag, 1. April 2016, 10:55:09 schrieb jay.xu:
> After talking with xing, we plan to summit dtsi after xing's patches are
> applied,
> and I will update the patch for rk3399 core dtsi quickly

Not sure if you have seen it, but I picked up Xing's most recent clock 
patches already [0]. So go ahead when you have time :-)


Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.7-clk/next


> On 2016年04月01日 05:48, Heiko Stuebner wrote:
> > Hi Jianqun,
> > 
> > Am Dienstag, 1. März 2016, 14:39:58 schrieb Jianqun Xu:
> >> There is the new SoCs from Rockchip which named rk3399, the
> >> patches are added to support them.
> > 
> > is this still valid or does it need an update?
> > The clock-series from Xing saw changes, so I'm guessing the devicetree
> > side might also need some update?
> > 
> > Especially an actual board-file would be nice ;-) .
> > 
> > 
> > Thanks
> > Heiko

[PATCH] ftrace: filter: Match dot symbols when searching functions on ppc64.

2016-03-31 Thread Thiago Jung Bauermann

In the ppc64 big endian ABI, function symbols point to function
descriptors. The symbols which point to the function entry points
have a dot in front of the function name. Consequently, when the
ftrace filter mechanism searches for the symbol corresponding to
an entry point address, it gets the dot symbol.

As a result, ftrace filter users have to be aware of this ABI detail on
ppc64 and prepend a dot to the function name when setting the filter.

The perf probe command insulates the user from this by ignoring the dot
in front of the symbol name when matching function names to symbols,
but the sysfs interface does not. This patch makes the ftrace filter
mechanism do the same when searching symbols.

Fixes the following failure in ftracetest's kprobe_ftrace.tc:

  .../kprobe_ftrace.tc: line 9: echo: write error: Invalid argument

That failure is on this line of kprobe_ftrace.tc:

  echo _do_fork > set_ftrace_filter

This is because there's no _do_fork entry in the functions list:

  # cat available_filter_functions | grep _do_fork
  ._do_fork

This change introduces no regressions on the perf and ftracetest
testsuite results.

Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Michael Ellerman 
Signed-off-by: Thiago Jung Bauermann 
---
 arch/powerpc/include/asm/ftrace.h |  9 +
 kernel/trace/ftrace.c | 13 +
 2 files changed, 22 insertions(+)

diff --git a/arch/powerpc/include/asm/ftrace.h 
b/arch/powerpc/include/asm/ftrace.h
index 50ca7585abe2..68f1858796c6 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -58,6 +58,15 @@ struct dyn_arch_ftrace {
struct module *mod;
 };
 #endif /*  CONFIG_DYNAMIC_FTRACE */
+
+#if CONFIG_PPC64 && (!defined(_CALL_ELF) || _CALL_ELF != 2)
+#define ARCH_HAS_FTRACE_MATCH_ADJUST
+static inline void arch_ftrace_match_adjust(char **str, char *search)
+{
+   if ((*str)[0] == '.' && search[0] != '.')
+   (*str)++;
+}
+#endif /* CONFIG_PPC64 && (!defined(_CALL_ELF) || _CALL_ELF != 2) */
 #endif /* __ASSEMBLY__ */
 
 #ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index b1870fbd2b67..e806c2a3b7a8 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3444,11 +3444,24 @@ struct ftrace_glob {
int type;
 };
 
+#ifndef ARCH_HAS_FTRACE_MATCH_ADJUST
+/*
+ * If symbols in an architecture don't correspond exactly to the user-visible
+ * name of what they represent, it is possible to define this function to
+ * perform the necessary adjustments.
+*/
+static inline void arch_ftrace_match_adjust(char **str, char *search)
+{
+}
+#endif
+
 static int ftrace_match(char *str, struct ftrace_glob *g)
 {
int matched = 0;
int slen;
 
+   arch_ftrace_match_adjust(, g->search);
+
switch (g->type) {
case MATCH_FULL:
if (strcmp(str, g->search) == 0)
-- 
1.9.1

Re: [PATCH v3 0/3] Rockchip: rk3399: Add core dtsi for rk3399

2016-03-31 Thread Heiko Stuebner

Hi Jianqun,

Am Freitag, 1. April 2016, 10:55:09 schrieb jay.xu:
> After talking with xing, we plan to summit dtsi after xing's patches are
> applied,
> and I will update the patch for rk3399 core dtsi quickly

Not sure if you have seen it, but I picked up Xing's most recent clock 
patches already [0]. So go ahead when you have time :-)


Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.7-clk/next


> On 2016年04月01日 05:48, Heiko Stuebner wrote:
> > Hi Jianqun,
> > 
> > Am Dienstag, 1. März 2016, 14:39:58 schrieb Jianqun Xu:
> >> There is the new SoCs from Rockchip which named rk3399, the
> >> patches are added to support them.
> > 
> > is this still valid or does it need an update?
> > The clock-series from Xing saw changes, so I'm guessing the devicetree
> > side might also need some update?
> > 
> > Especially an actual board-file would be nice ;-) .
> > 
> > 
> > Thanks
> > Heiko

[PATCH] ftrace: filter: Match dot symbols when searching functions on ppc64.

2016-03-31 Thread Thiago Jung Bauermann

In the ppc64 big endian ABI, function symbols point to function
descriptors. The symbols which point to the function entry points
have a dot in front of the function name. Consequently, when the
ftrace filter mechanism searches for the symbol corresponding to
an entry point address, it gets the dot symbol.

As a result, ftrace filter users have to be aware of this ABI detail on
ppc64 and prepend a dot to the function name when setting the filter.

The perf probe command insulates the user from this by ignoring the dot
in front of the symbol name when matching function names to symbols,
but the sysfs interface does not. This patch makes the ftrace filter
mechanism do the same when searching symbols.

Fixes the following failure in ftracetest's kprobe_ftrace.tc:

  .../kprobe_ftrace.tc: line 9: echo: write error: Invalid argument

That failure is on this line of kprobe_ftrace.tc:

  echo _do_fork > set_ftrace_filter

This is because there's no _do_fork entry in the functions list:

  # cat available_filter_functions | grep _do_fork
  ._do_fork

This change introduces no regressions on the perf and ftracetest
testsuite results.

Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Michael Ellerman 
Signed-off-by: Thiago Jung Bauermann 
---
 arch/powerpc/include/asm/ftrace.h |  9 +
 kernel/trace/ftrace.c | 13 +
 2 files changed, 22 insertions(+)

diff --git a/arch/powerpc/include/asm/ftrace.h 
b/arch/powerpc/include/asm/ftrace.h
index 50ca7585abe2..68f1858796c6 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -58,6 +58,15 @@ struct dyn_arch_ftrace {
struct module *mod;
 };
 #endif /*  CONFIG_DYNAMIC_FTRACE */
+
+#if CONFIG_PPC64 && (!defined(_CALL_ELF) || _CALL_ELF != 2)
+#define ARCH_HAS_FTRACE_MATCH_ADJUST
+static inline void arch_ftrace_match_adjust(char **str, char *search)
+{
+   if ((*str)[0] == '.' && search[0] != '.')
+   (*str)++;
+}
+#endif /* CONFIG_PPC64 && (!defined(_CALL_ELF) || _CALL_ELF != 2) */
 #endif /* __ASSEMBLY__ */
 
 #ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index b1870fbd2b67..e806c2a3b7a8 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3444,11 +3444,24 @@ struct ftrace_glob {
int type;
 };
 
+#ifndef ARCH_HAS_FTRACE_MATCH_ADJUST
+/*
+ * If symbols in an architecture don't correspond exactly to the user-visible
+ * name of what they represent, it is possible to define this function to
+ * perform the necessary adjustments.
+*/
+static inline void arch_ftrace_match_adjust(char **str, char *search)
+{
+}
+#endif
+
 static int ftrace_match(char *str, struct ftrace_glob *g)
 {
int matched = 0;
int slen;
 
+   arch_ftrace_match_adjust(, g->search);
+
switch (g->type) {
case MATCH_FULL:
if (strcmp(str, g->search) == 0)
-- 
1.9.1

Re: [PATCH] Implement leftpad syscall

Hi David,

[auto build test ERROR on v4.6-rc1]
[also build test ERROR on next-20160331]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Richard-Weinberger/Implement-leftpad-syscall/20160401-063620
config: microblaze-mmu_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=microblaze 

All errors (new ones prefixed by >>):

   kernel/sys.c: In function 'SYSC_leftpad':
>> kernel/sys.c:2441:2: error: implicit declaration of function 'strlen_user' 
>> [-Werror=implicit-function-declaration]
 size_t len = strlen_user(src);
 ^
   cc1: some warnings being treated as errors

vim +/strlen_user +2441 kernel/sys.c

  2435  
  2436  
  2437  SYSCALL_DEFINE4(leftpad, char *, src, char, pad, char *, dst, size_t, 
dst_len)
  2438  {
  2439  char *buf;
  2440  long ret;
> 2441  size_t len = strlen_user(src);
  2442  size_t pad_len = dst_len - len;
  2443  
  2444  if (dst_len <= len || dst_len > 4096) {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] Implement leftpad syscall

Hi David,

[auto build test ERROR on v4.6-rc1]
[also build test ERROR on next-20160331]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Richard-Weinberger/Implement-leftpad-syscall/20160401-063620
config: microblaze-mmu_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=microblaze 

All errors (new ones prefixed by >>):

   kernel/sys.c: In function 'SYSC_leftpad':
>> kernel/sys.c:2441:2: error: implicit declaration of function 'strlen_user' 
>> [-Werror=implicit-function-declaration]
 size_t len = strlen_user(src);
 ^
   cc1: some warnings being treated as errors

vim +/strlen_user +2441 kernel/sys.c

  2435  
  2436  
  2437  SYSCALL_DEFINE4(leftpad, char *, src, char, pad, char *, dst, size_t, 
dst_len)
  2438  {
  2439  char *buf;
  2440  long ret;
> 2441  size_t len = strlen_user(src);
  2442  size_t pad_len = dst_len - len;
  2443  
  2444  if (dst_len <= len || dst_len > 4096) {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[v7, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
numbers break down the ADMA data transfer.

Signed-off-by: Yangbo Lu 
Acked-by: Ulf Hansson 
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
---
 drivers/mmc/host/Kconfig  |  1 +
 drivers/mmc/host/sdhci-of-esdhc.c | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 04feea8..5743b05 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -142,6 +142,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+   select FSL_GUTS
help
  This selects the Freescale eSDHC controller support.
 
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d35..68cc020 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include "sdhci-pltfm.h"
 #include "sdhci-esdhc.h"
@@ -28,6 +30,8 @@
 struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+   u32 soc_ver;
+   u8 soc_rev;
 };
 
 /**
@@ -73,6 +77,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
 static u16 esdhc_readw_fixup(struct sdhci_host *host,
 int spec_reg, u32 value)
 {
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
 
@@ -80,6 +86,13 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0x;
else
ret = (value >> shift) & 0x;
+
+   /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+* vendor version and spec version information.
+*/
+   if ((spec_reg == SDHCI_HOST_VERSION) &&
+   (esdhc->soc_ver == SVR_T4240) && (esdhc->soc_rev <= 0x20))
+   ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
 }
 
@@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev, 
struct sdhci_host *host)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
u16 host_ver;
+   u32 svr;
 
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
 
+   fsl_guts_init();
+   svr = fsl_guts_get_svr();
+   if (svr) {
+   esdhc->soc_ver = SVR_SOC_VER(svr);
+   esdhc->soc_rev = SVR_REV(svr);
+   } else {
+   dev_err(>dev, "Failed to get SVR value!\n");
+   }
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
 SDHCI_VENDOR_VER_SHIFT;
-- 
2.1.0.27.g96db324

[v7, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.

Signed-off-by: Yangbo Lu 
Acked-by: Wolfram Sang 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include ' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
---
 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
 drivers/clk/clk-qoriq.c   | 3 +--
 drivers/i2c/busses/i2c-mpc.c  | 2 +-
 drivers/iommu/fsl_pamu.c  | 3 +--
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
 6 files changed, 7 insertions(+), 9 deletions(-)
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 _GLOBAL(__e500_icache_setup)
mfspr   r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1148,8 +1149,6 @@ bad_args:
 }
 
 #ifdef CONFIG_PPC
-#include 
-
 static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
(SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 
 #define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
 #include "fsl_pamu.h"
 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 /* define indexes for each operation mapping scenario */
 #define OMI_QMAN0x00
 #define OMI_FMAN0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #ifdef CONFIG_PPC
 #include 
-#include 
 #endif
 #include 
 #include 
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
  * (at your option) any later version.
  */
 
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
 
 #define SVR_REV(svr)   ((svr) & 0xFF)  /* SOC design resision */
 #define SVR_MAJ(svr)   (((svr) >>  4) & 0xF)   /* Major revision field*/
-- 
2.1.0.27.g96db324

[v7, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

Move mpc85xx.h to include/linux/fsl and rename it to svr.h as
a common header file. It has been used for mpc85xx and it will
be used for ARM-based SoC as well.

Signed-off-by: Yangbo Lu 
Acked-by: Wolfram Sang 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Changed to Move mpc85xx.h to include/linux/fsl/
- Adjusted '#include ' position in file
Changes for v6:
- None
Changes for v7:
- Added 'Acked-by: Wolfram Sang' for I2C part
- Also applied to arch/powerpc/kernel/cpu_setup_fsl_booke.S
---
 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
 drivers/clk/clk-qoriq.c   | 3 +--
 drivers/i2c/busses/i2c-mpc.c  | 2 +-
 drivers/iommu/fsl_pamu.c  | 3 +--
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h | 4 ++--
 6 files changed, 7 insertions(+), 9 deletions(-)
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 462aed9..2b0284e 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -13,13 +13,13 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 _GLOBAL(__e500_icache_setup)
mfspr   r0, SPRN_L1CSR1
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 7bc1c45..fc7f722 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1148,8 +1149,6 @@ bad_args:
 }
 
 #ifdef CONFIG_PPC
-#include 
-
 static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10,/* P2040 1.0 */
(SVR_P2040 << 8) | 0x11,/* P2040 1.1 */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 48ecffe..600704c 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -27,9 +27,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 
 #define DRV_NAME "mpc-i2c"
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index a34355f..af8fb27 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -21,11 +21,10 @@
 #include "fsl_pamu.h"
 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 /* define indexes for each operation mapping scenario */
 #define OMI_QMAN0x00
 #define OMI_FMAN0x01
diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index d2f917a..2224b10 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -86,11 +86,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #ifdef CONFIG_PPC
 #include 
-#include 
 #endif
 #include 
 #include 
diff --git a/arch/powerpc/include/asm/mpc85xx.h b/include/linux/fsl/svr.h
similarity index 97%
rename from arch/powerpc/include/asm/mpc85xx.h
rename to include/linux/fsl/svr.h
index 213f3a8..8d13836 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/include/linux/fsl/svr.h
@@ -9,8 +9,8 @@
  * (at your option) any later version.
  */
 
-#ifndef __ASM_PPC_MPC85XX_H
-#define __ASM_PPC_MPC85XX_H
+#ifndef FSL_SVR_H
+#define FSL_SVR_H
 
 #define SVR_REV(svr)   ((svr) & 0xFF)  /* SOC design resision */
 #define SVR_MAJ(svr)   (((svr) >>  4) & 0xF)   /* Major revision field*/
-- 
2.1.0.27.g96db324

[v7, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to get SVR(System
version register). And fix host version to avoid that incorrect version
numbers break down the ADMA data transfer.

Signed-off-by: Yangbo Lu 
Acked-by: Ulf Hansson 
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
---
 drivers/mmc/host/Kconfig  |  1 +
 drivers/mmc/host/sdhci-of-esdhc.c | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 04feea8..5743b05 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -142,6 +142,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+   select FSL_GUTS
help
  This selects the Freescale eSDHC controller support.
 
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d35..68cc020 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include "sdhci-pltfm.h"
 #include "sdhci-esdhc.h"
@@ -28,6 +30,8 @@
 struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+   u32 soc_ver;
+   u8 soc_rev;
 };
 
 /**
@@ -73,6 +77,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
 static u16 esdhc_readw_fixup(struct sdhci_host *host,
 int spec_reg, u32 value)
 {
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
 
@@ -80,6 +86,13 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0x;
else
ret = (value >> shift) & 0x;
+
+   /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+* vendor version and spec version information.
+*/
+   if ((spec_reg == SDHCI_HOST_VERSION) &&
+   (esdhc->soc_ver == SVR_T4240) && (esdhc->soc_rev <= 0x20))
+   ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
 }
 
@@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device *pdev, 
struct sdhci_host *host)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_esdhc *esdhc;
u16 host_ver;
+   u32 svr;
 
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
 
+   fsl_guts_init();
+   svr = fsl_guts_get_svr();
+   if (svr) {
+   esdhc->soc_ver = SVR_SOC_VER(svr);
+   esdhc->soc_rev = SVR_REV(svr);
+   } else {
+   dev_err(>dev, "Failed to get SVR value!\n");
+   }
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
 SDHCI_VENDOR_VER_SHIFT;
-- 
2.1.0.27.g96db324

[v7, 3/5] dt: move guts devicetree doc out of powerpc directory

Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
---
 Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
 1 file changed, 3 insertions(+)
 rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt 
b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
  - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
 
+ - little-endian : Indicates that the global utilities block is little
+   endian. The default is big endian.
+
 Examples:
global-utilities@e {/* global utilities block */
compatible = "fsl,mpc8548-guts";
-- 
2.1.0.27.g96db324

[v7, 3/5] dt: move guts devicetree doc out of powerpc directory

Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
since it's used by not only PowerPC but also ARM. And add a specification
for 'little-endian' property.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- Added this patch
Changes for v5:
- Modified the description for little-endian property
Changes for v6:
- None
Changes for v7:
- None
---
 Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
 1 file changed, 3 insertions(+)
 rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt 
b/Documentation/devicetree/bindings/soc/fsl/guts.txt
similarity index 91%
rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
index b71b203..07adca9 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
@@ -25,6 +25,9 @@ Recommended properties:
  - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
 
+ - little-endian : Indicates that the global utilities block is little
+   endian. The default is big endian.
+
 Examples:
global-utilities@e {/* global utilities block */
compatible = "fsl,mpc8548-guts";
-- 
2.1.0.27.g96db324

[v7, 1/5] ARM64: dts: ls2080a: add device configuration node

Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <>;
};
 
+   dcfg: dcfg@1e0 {
+   compatible = "fsl,ls2080a-dcfg", "syscon";
+   reg = <0x0 0x1e0 0x0 0x1>;
+   little-endian;
+   };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
-- 
2.1.0.27.g96db324

[v7, 0/5] Fix eSDHC host version register bug

This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.

So, the first three patches are to add the GUTS driver.
The following two patches are to enable GUTS driver support to get SVR in eSDHC
driver and fix host version for T4240.

Yangbo Lu (5):
  ARM64: dts: ls2080a: add device configuration node
  soc: fsl: add GUTS driver for QorIQ platforms
  dt: move guts devicetree doc out of powerpc directory
  powerpc/fsl: move mpc85xx.h to include/linux/fsl
  mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

 .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 ++
 arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
 drivers/clk/clk-qoriq.c|   3 +-
 drivers/i2c/busses/i2c-mpc.c   |   2 +-
 drivers/iommu/fsl_pamu.c   |   3 +-
 drivers/mmc/host/Kconfig   |   1 +
 drivers/mmc/host/sdhci-of-esdhc.c  |  23 
 drivers/net/ethernet/freescale/gianfar.c   |   2 +-
 drivers/soc/Kconfig|   2 +-
 drivers/soc/fsl/Kconfig|   8 ++
 drivers/soc/fsl/Makefile   |   1 +
 drivers/soc/fsl/guts.c | 119 +
 include/linux/fsl/guts.h   |  98 -
 .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
 15 files changed, 219 insertions(+), 58 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/guts.c
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

-- 
2.1.0.27.g96db324

[v7, 1/5] ARM64: dts: ls2080a: add device configuration node

Add the dts node for device configuration unit that provides
general purpose configuration and status for the device.

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- Added this patch
Changes for v6:
- None
Changes for v7:
- None
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 9d746c6..8724cf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -191,6 +191,12 @@
clocks = <>;
};
 
+   dcfg: dcfg@1e0 {
+   compatible = "fsl,ls2080a-dcfg", "syscon";
+   reg = <0x0 0x1e0 0x0 0x1>;
+   little-endian;
+   };
+
serial0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
-- 
2.1.0.27.g96db324

[v7, 0/5] Fix eSDHC host version register bug

This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
eSDHC controller. To get the SoC version and revision, it's needed to add the
GUTS driver to access the global utilities registers.

So, the first three patches are to add the GUTS driver.
The following two patches are to enable GUTS driver support to get SVR in eSDHC
driver and fix host version for T4240.

Yangbo Lu (5):
  ARM64: dts: ls2080a: add device configuration node
  soc: fsl: add GUTS driver for QorIQ platforms
  dt: move guts devicetree doc out of powerpc directory
  powerpc/fsl: move mpc85xx.h to include/linux/fsl
  mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

 .../bindings/{powerpc => soc}/fsl/guts.txt |   3 +
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   6 ++
 arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   2 +-
 drivers/clk/clk-qoriq.c|   3 +-
 drivers/i2c/busses/i2c-mpc.c   |   2 +-
 drivers/iommu/fsl_pamu.c   |   3 +-
 drivers/mmc/host/Kconfig   |   1 +
 drivers/mmc/host/sdhci-of-esdhc.c  |  23 
 drivers/net/ethernet/freescale/gianfar.c   |   2 +-
 drivers/soc/Kconfig|   2 +-
 drivers/soc/fsl/Kconfig|   8 ++
 drivers/soc/fsl/Makefile   |   1 +
 drivers/soc/fsl/guts.c | 119 +
 include/linux/fsl/guts.h   |  98 -
 .../asm/mpc85xx.h => include/linux/fsl/svr.h   |   4 +-
 15 files changed, 219 insertions(+), 58 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
 create mode 100644 drivers/soc/fsl/Kconfig
 create mode 100644 drivers/soc/fsl/guts.c
 rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)

-- 
2.1.0.27.g96db324

Re: [PATCH 4/4] mtd: provide helper to prepare buffers for DMA operations

Hi Boris,

[auto build test ERROR on spi/for-next]
[also build test ERROR on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/scatterlist-sg_table-from-virtual-pointer/20160331-203118
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi for-next
config: m32r-m32104ut_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/mtd/super.h:17:0,
from fs/romfs/storage.c:13:
>> include/linux/mtd/mtd.h:426:10: error: expected ';', ',' or ')' before 'enum'
 enum dma_data_direction dir)
 ^
   include/linux/mtd/mtd.h: In function 'mtd_unmap_buf':
>> include/linux/mtd/mtd.h:434:2: warning: 'return' with a value, in function 
>> returning void
 return -ENOTSUPP;
 ^
   fs/romfs/storage.c: At top level:
   include/linux/mtd/mtd.h:431:13: warning: 'mtd_unmap_buf' defined but not 
used [-Wunused-function]
static void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
^
--
   In file included from include/linux/mtd/super.h:17:0,
from fs/romfs/super.c:72:
>> include/linux/mtd/mtd.h:426:10: error: expected ';', ',' or ')' before 'enum'
 enum dma_data_direction dir)
 ^
   include/linux/mtd/mtd.h: In function 'mtd_unmap_buf':
>> include/linux/mtd/mtd.h:434:2: warning: 'return' with a value, in function 
>> returning void
 return -ENOTSUPP;
 ^
   fs/romfs/super.c: At top level:
   include/linux/mtd/mtd.h:431:13: warning: 'mtd_unmap_buf' defined but not 
used [-Wunused-function]
static void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
^

vim +426 include/linux/mtd/mtd.h

   420 struct sg_table *sgt, enum dma_data_direction dir);
   421  #else
   422  static inline int mtd_map_buf(struct mtd_info *mtd, struct device *dev,
   423struct sg_table *sgt, const void *buf,
   424size_t len,
   425const struct sg_constraints *constraints
 > 426enum dma_data_direction dir)
   427  {
   428  return -ENOTSUPP;
   429  }
   430  
   431  static void mtd_unmap_buf(struct mtd_info *mtd, struct device *dev,
   432struct sg_table *sgt, enum dma_data_direction 
dir)
   433  {
 > 434  return -ENOTSUPP;
   435  }
   436  #endif
   437  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 4/4] mtd: provide helper to prepare buffers for DMA operations