[PATCH v3] staging: wilc1000: Process WARN, INFO options of debug levels from user

[Chandra S Gorentla]

This patch enables setting the module's debug options WARN and INFO in the
debugfs file 'wilc_debug_level'.  This functionality allows the user to
enable logging of warnings and other information.  Before this change,
writes to this debugfs file set only one option - DEBUG.  Another option
that is enabled by default is ERR.

As a side effect, this patch removes the 'sparse' warning -
'warning: incorrect type in argument 2 (different address spaces)'.


Signed-off-by: Chandra S Gorentla 
---

Changes in v3: Added back a printk that was removed from v1

Changes in v2: Replaced copy_from_user and kstrtoint (added in v1) with
   kstrtouint_from_user

 drivers/staging/wilc1000/wilc_debugfs.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_debugfs.c 
b/drivers/staging/wilc1000/wilc_debugfs.c
index be2e901..ae11186 100644
--- a/drivers/staging/wilc1000/wilc_debugfs.c
+++ b/drivers/staging/wilc1000/wilc_debugfs.c
@@ -48,28 +48,19 @@ static ssize_t wilc_debug_level_read(struct file *file, 
char __user *userbuf, si
return simple_read_from_buffer(userbuf, count, ppos, buf, res);
 }
 
-static ssize_t wilc_debug_level_write(struct file *filp, const char *buf, 
size_t count, loff_t *ppos)
+static ssize_t wilc_debug_level_write(struct file *filp, const char __user 
*buf,
+   size_t count, loff_t *ppos)
 {
-   char buffer[128] = {};
int flag = 0;
+   int ret;
 
-   if (count > sizeof(buffer))
-   return -EINVAL;
-
-   if (copy_from_user(buffer, buf, count)) {
-   return -EFAULT;
-   }
-
-   flag = buffer[0] - '0';
-
-   if (flag > 0)
-   flag = DEBUG | ERR;
-   else if (flag < 0)
-   flag = 100;
+   ret = kstrtouint_from_user(buf, count, 16, &flag);
+   if (ret)
+   return ret;
 
if (flag > DBG_LEVEL_ALL) {
printk("%s, value (0x%08x) is out of range, stay previous flag 
(0x%08x)\n", __func__, flag, atomic_read(&DEBUG_LEVEL));
-   return -EFAULT;
+   return -EINVAL;
}
 
atomic_set(&DEBUG_LEVEL, (int)flag);
@@ -78,6 +69,7 @@ static ssize_t wilc_debug_level_write(struct file *filp, 
const char *buf, size_t
printk("Debug-level disabled\n");
else
printk("Debug-level enabled\n");
+
return count;
 }
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched: sync with the cfs_rq when changing sched class

[Byungchul Park]

On Thu, Aug 13, 2015 at 05:22:12PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 13, 2015 at 10:15:28AM +0800, Yuyang Du wrote:
> > On Thu, Aug 13, 2015 at 05:21:27PM +0900, Byungchul Park wrote:
> > > 
> > > yuyang said that switched_to don't need to consider task's load because it
> > > can have meaningless value. but i think considering task's load is better
> > > than leaving it unattended at all. and we can also use switched_to if we 
> > > consider task's load in switched_to.
> > 
> > when did I say "don't need to consider..."?
> > 
> > Doing more does not mean better, or just trivial. BTW, the task switched_to
> > does not have to be switched_from before. 
> 
> Correct, there's a few corner cases we need to consider.
> 
> However, I think we unconditionally call init_entity_runnable_average()
> on all tasks, regardless of their 'initial' sched class, so it should
> have a valid state.
> 
> Another thing to consider is the state being very stale, suppose it
> started live as FAIR, ran for a bit, got switched to !FAIR by means of
> sys_sched_setscheduler()/sys_sched_setattr() or similar, runs for a long
> time and for some reason gets switched back to FAIR, we need to age and
> or re-init things.

hello,

what do you think about this approch for solving this problem ?
it makes se's loads decay for detached periods for that rq. and i used
rq instead of cfs_rq because it does not have dependency to cfs_rq
any more.

---

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5b50082..8f5e2de 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1191,6 +1191,8 @@ struct load_weight {
  */
 struct sched_avg {
u64 last_update_time, load_sum;
+   u64 last_detached_time;
+   int last_detached_cpu;
u32 util_sum, period_contrib;
unsigned long load_avg, util_avg;
 };
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 72d13af..b2d22c8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -673,6 +673,8 @@ void init_entity_runnable_average(struct sched_entity *se)
struct sched_avg *sa = &se->avg;
 
sa->last_update_time = 0;
+   sa->last_detached_time = 0;
+   sa->last_detached_cpu = -1;
/*
 * sched_avg's period_contrib should be strictly less then 1024, so
 * we give it 1023 to make sure it is almost a period (1024us), and
@@ -2711,16 +2713,47 @@ static inline void update_load_avg(struct sched_entity 
*se, int update_tg)
 
 static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
 {
-   se->avg.last_update_time = cfs_rq->avg.last_update_time;
-   cfs_rq->avg.load_avg += se->avg.load_avg;
-   cfs_rq->avg.load_sum += se->avg.load_sum;
-   cfs_rq->avg.util_avg += se->avg.util_avg;
-   cfs_rq->avg.util_sum += se->avg.util_sum;
+   struct sched_avg *sa = &se->avg;
+   int cpu = sa->last_detached_cpu;
+   u64 delta;
+
+   if (cpu != -1) {
+   delta = rq_clock_task(cpu_rq(cpu)) - sa->last_detached_time;
+   /*
+* compute the number of period passed, where a period is 1 
msec,
+* since the entity had detached from the rq, and ignore 
decaying
+* delta which is less than a period for fast calculation.
+*/
+   delta >>= 20;
+   if (!delta)
+   goto do_attach;
+
+   sa->load_sum = decay_load(sa->load_sum, delta);
+   sa->util_sum = decay_load((u64)(sa->util_sum), delta);
+   sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX);
+   sa->util_avg = (sa->util_sum << SCHED_LOAD_SHIFT) / 
LOAD_AVG_MAX;
+   }
+
+do_attach:
+   sa->last_detached_cpu = -1;
+   sa->last_detached_time = 0;
+   sa->period_contrib = 0;
+
+   sa->last_update_time = cfs_rq->avg.last_update_time;
+   cfs_rq->avg.load_avg += sa->load_avg;
+   cfs_rq->avg.load_sum += sa->load_sum;
+   cfs_rq->avg.util_avg += sa->util_avg;
+   cfs_rq->avg.util_sum += sa->util_sum;
 }
 
 static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
 {
-   __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq_of(cfs_rq)),
+   int cpu = cpu_of(rq_of(cfs_rq));
+
+   se->avg.last_detached_cpu = cpu;
+   se->avg.last_detached_time = rq_clock_task(rq_of(cfs_rq));
+
+   __update_load_avg(cfs_rq->avg.last_update_time, cpu,
&se->avg, se->on_rq * scale_load_down(se->load.weight),
cfs_rq->curr == se, NULL);

> 
> I _think_ we can use last_update_time for that, but I've not looked too
> hard.
> 
> That is, age based on last_update_time, if all 0, reinit, or somesuch.
> 
> 
> The most common case of switched_from()/switched_to() is Priority
> Inheritance, and that typically results in very short lived stints as
> !FAIR and the avg data should be still accurate by the time we return.
> --
> To unsubscribe from 

Re: [PATCH] acpi, apei, arm64: APEI initial support for aarch64.

[Fu Wei]

Hi all
Add Tomasz Nowicki  in the loop

On 15 August 2015 at 02:27, Zhang, Jonathan Zhixiong
 wrote:
>
> On 8/14/2015 5:39 AM, Fu Wei wrote:
>>
>> Hi all,
>>
>> This patch depends on https://lkml.org/lkml/2015/8/8/169
>> [PATCH V11 4/5] arm64: apei: implement arch_apei_get_mem_attributes(),
>> which has been in the "next" branch of
>> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
>>
>> FYI
>> Thanks
>>
>> On 14 August 2015 at 20:35,   wrote:
>>>
>>> From: Tomasz Nowicki 
>>>
>>> This commit provides APEI arch-specific bits for aarch64
>>>
>>> Changelog:
>>>Fu Wei:
>>>  Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h.
>>>  Delete arch/arm64/kernel/apei.c.
>>>  Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff".
>>>
>>> Signed-off-by: Tomasz Nowicki 
>>> Signed-off-by: Fu Wei 
>>> ---
>>>   arch/arm64/Kconfig|  1 +
>>>   arch/arm64/include/asm/acpi.h | 11 +++
>>>   arch/arm64/kernel/acpi.c  |  4 
>>>   3 files changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 318175f..6144c9d 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -3,6 +3,7 @@ config ARM64
>>>  select ACPI_CCA_REQUIRED if ACPI
>>>  select ACPI_GENERIC_GSI if ACPI
>>>  select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>>> +   select HAVE_ACPI_APEI if ACPI
>>>  select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>>>  select ARCH_HAS_ELF_RANDOMIZE
>>>  select ARCH_HAS_GCOV_PROFILE_ALL
>>> diff --git a/arch/arm64/include/asm/acpi.h
>>> b/arch/arm64/include/asm/acpi.h
>>> index a17b623..ced6e25 100644
>>> --- a/arch/arm64/include/asm/acpi.h
>>> +++ b/arch/arm64/include/asm/acpi.h
>>> @@ -22,6 +22,7 @@
>>>   #ifdef CONFIG_ACPI_APEI
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #endif
>>>
>>>   /* Macros for consistency checks of the GICC subtable of MADT */
>>> @@ -52,6 +53,9 @@ typedef u64 phys_cpuid_t;
>>>   extern int acpi_disabled;
>>>   extern int acpi_noirq;
>>>   extern int acpi_pci_disabled;
>>> +#ifdef CONFIG_ACPI_APEI
>>> +extern int acpi_disable_cmcff;
>>> +#endif
>>>
>>>   static inline void disable_acpi(void)
>>>   {
>>> @@ -89,6 +93,13 @@ static inline bool acpi_has_cpu_in_madt(void)
>>>   static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>>>   void __init acpi_init_cpus(void);
>>>
>>> +#ifdef CONFIG_ACPI_APEI
>>> +static inline void arch_apei_flush_tlb_one(unsigned long addr)
>>> +{
>>> +   flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>>> +}
>>> +#endif
>>> +
>>>   #else
>>>   static inline void acpi_init_cpus(void) { }
>>>   #endif /* CONFIG_ACPI */
>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> index 19de753..bd1be9a 100644
>>> --- a/arch/arm64/kernel/acpi.c
>>> +++ b/arch/arm64/kernel/acpi.c
>>> @@ -36,6 +36,10 @@ EXPORT_SYMBOL(acpi_disabled);
>>>   int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ
>>> initialization */
>>>   EXPORT_SYMBOL(acpi_pci_disabled);
>>>
>>> +#ifdef CONFIG_ACPI_APEI
>>> +int acpi_disable_cmcff;
>>> +#endif
>>> +
>>>   static bool param_acpi_off __initdata;
>>>   static bool param_acpi_force __initdata;
>>>
>>> --
>>> 1.9.1
>>>
>>
>>
>>
> I tested this patch on an arm64 platform, the APEI functionalities
> work as expected.
>   Tested-by: Jonathan (Zhixiong) Zhang 
>
> --
> Jonathan (Zhixiong) Zhang
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

re

[Oda]

Did you get my previous message
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/5] PM / OPP: add a function to get the voltage for disabled OPPs

[Viresh Kumar]

On 14-08-15, 18:56, Javi Merino wrote:
> The OPP library is now used for power models to calculate the power
> that a device would consume at a specific OPP.  To do that, we use a
> simple power model which takes frequency and voltage as inputs.  We get
> the voltage and frequency from the OPP library.
> 
> The devfreq cooling device for the thermal framework controls temperature
> by disabling OPPs.  The power model needs to calculate the power that
> would be consumed if we reenabled the OPP.  dev_pm_opp_get_voltage()
> doesn't work for disabled OPPs.
> 
> Add a dev_pm_opp_get_voltage_always() that works both for enabled and
> disabled OPPs to be used by the power model.  The documentation for this
> function clearly states that you should use dev_pm_opp_get_voltage()
> instead unless you know what you're doing.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Signed-off-by: Javi Merino 
> ---
>  drivers/base/power/opp.c | 37 +
>  include/linux/pm_opp.h   |  7 +++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index 677fb2843553..b1a4216c7ec3 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -182,6 +182,43 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp 
> *opp)
>  EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage);
>  
>  /**
> + * dev_pm_opp_get_voltage_always() - Gets the voltage corresponding to an opp
> + * @opp: opp for which voltage has to be returned for
> + *
> + * This function is similar to dev_pm_opp_get_voltage() except that it
> + * works for disabled opps as well.  In most cases, you want to
> + * operate only on available opps so you should use
> + * dev_pm_opp_get_voltage() instead.
> + *
> + * Return: voltage in micro volt corresponding to the opp, else
> + * return 0
> + *
> + * Locking: This function must be called under rcu_read_lock(). opp is a rcu
> + * protected pointer. This means that opp which could have been fetched by
> + * opp_find_freq_{exact,ceil,floor} functions is valid as long as we are
> + * under RCU lock. The pointer returned by the opp_find_freq family must be
> + * used in the same section as the usage of this function with the pointer
> + * prior to unlocking with rcu_read_unlock() to maintain the integrity of the
> + * pointer.
> + */
> +unsigned long dev_pm_opp_get_voltage_always(struct dev_pm_opp *opp)
> +{
> + struct dev_pm_opp *tmp_opp;
> + unsigned long v = 0;
> +
> + opp_rcu_lockdep_assert();
> +
> + tmp_opp = rcu_dereference(opp);
> + if (unlikely(IS_ERR_OR_NULL(tmp_opp)))
> + pr_err("%s: Invalid parameters\n", __func__);
> + else
> + v = tmp_opp->u_volt;
> +
> + return v;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage_always);

I will rather update dev_pm_opp_get_voltage() and remove the
'available' check. There is no need for that.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v2] soc: qcom: smem: Fix errant private access

[Bjorn Andersson]

On Fri 14 Aug 21:56 PDT 2015, Andy Gross wrote:

> This patch corrects private partition item access.  Instead of falling back to
> global for instances where we have an actual host and remote partition 
> existing,
> return the results of the private lookup.
> 
> Signed-off-by: Andy Gross 

Thanks for finding this issue.

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] mtd: add SMEM parser for QCOM platforms

[Bjorn Andersson]

On Fri 14 Aug 17:46 PDT 2015, Mathieu Olivari wrote:

> On QCOM platforms using MTD devices storage (such as IPQ806x), SMEM is
> used to store partition layout. This new parser can now be used to read
> SMEM and use it to register an MTD layout according to its content.
> 

Nice to see another user of the smem code :)

> diff --git a/drivers/mtd/qcom_smem_part.c b/drivers/mtd/qcom_smem_part.c
[..]
> +
> +/* Processor/host identifier for the application processor */
> +#define SMEM_HOST_APPS   0

This makes me wonder if there will ever be an apps partition. I would
have picked QCOM_SMEM_HOST_ANY, but I don't know what future platforms
might hold for us.


And as a side note, I think I will propose that we rename that define
QCOM_SMEM_GLOBAL.

> +
> +/* SMEM items index */
> +#define SMEM_AARM_PARTITION_TABLE9
> +#define SMEM_BOOT_FLASH_TYPE 421
> +#define SMEM_BOOT_FLASH_BLOCK_SIZE   424
> +
> +/* SMEM Flash types */
> +#define SMEM_FLASH_NAND  2
> +#define SMEM_FLASH_SPI   6
> +
> +#define SMEM_PART_NAME_SZ16
> +#define SMEM_PARTS_MAX   32
> +
> +struct smem_partition {
> + char name[SMEM_PART_NAME_SZ];
> + __le32 start;
> + __le32 size;
> + __le32 attr;
> +};
> +
> +struct smem_partition_table {
> + u8 magic[8];
> + __le32 version;
> + __le32 len;
> + struct smem_partition parts[SMEM_PARTS_MAX];
> +};
> +
> +/* SMEM Magic values in partition table */
> +static const u8 SMEM_PTABLE_MAGIC[] = {
> + 0xaa, 0x73, 0xee, 0x55,
> + 0xdb, 0xbd, 0x5e, 0xe3,
> +};
> +
> +static int qcom_smem_get_flash_blksz(u64 **smem_blksz)

Instead of passing pointers around I think you should just make this
function return < 0 for errors and >= 0 for the requested data. You can
probably still have it as an int, as the current values are well below
the size of the int.

> +{
> + int ret;
> + size_t size;
> +
> + ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_BLOCK_SIZE,
> + (void **) smem_blksz, &size);
> +
> + if (ret < 0) {
> + pr_err("Unable to read flash blksz from SMEM\n");
> + return -ENOENT;
> + }
> +
> + if (size != sizeof(**smem_blksz)) {
> + pr_err("Invalid flash blksz size in SMEM\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int qcom_smem_get_flash_type(u64 **smem_flash_type)

Same as above.

> +{
> + int ret;
> + size_t size;
> +
> + ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_TYPE,
> + (void **) smem_flash_type, &size);
> +
> + if (ret < 0) {
> + pr_err("Unable to read flash type from SMEM\n");
> + return -ENOENT;
> + }
> +
> + if (size != sizeof(**smem_flash_type)) {
> + pr_err("Invalid flash type size in SMEM\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int qcom_smem_get_flash_partitions(struct smem_partition_table 
> **pparts)
> +{
> + int ret;
> + size_t size;
> +
> + ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_AARM_PARTITION_TABLE,
> + (void **) pparts, &size);
> +

If you don't care about the size just pass NULL as the last argument.

> + if (ret < 0) {
> + pr_err("Unable to read partition table from SMEM\n");
> + return -ENOENT;
> + }

I think it would be cleaner if you had this function check the magic and
version and then return the partition pointer. That is:

static smem_partition *qcom_smem_get_flash_partitions(size_t *count)


And make *count = le32_to_cpu(table->len); so you don't have to care
about that below.

(And use NULL or ERR_PTR for the error paths)

> +
> + return 0;
> +}
> +
> +static int of_dev_node_match(struct device *dev, void *data)
> +{
> + return dev->of_node == data;
> +}
> +
> +static bool is_spi_device(struct device_node *np)
> +{
> + struct device *dev;
> +
> + dev = bus_find_device(&spi_bus_type, NULL, np, of_dev_node_match);
> + if (!dev)
> + return false;
> +
> + put_device(dev);
> + return true;
> +}
> +
> +static int parse_qcom_smem_partitions(struct mtd_info *master,
> +   struct mtd_partition **pparts,
> +   struct mtd_part_parser_data *data)
> +{
> + struct smem_partition_table *smem_parts;
> + u64 *smem_flash_type, *smem_blksz;
> + struct mtd_partition *mtd_parts;
> + struct device_node *of_node = data->of_node;
> + int i, ret;
> +
> + /*
> +  * SMEM will only store the partition table of the boot device.
> +  * If this is not the boot device, do not return any partition.
> +  */

I guess this is the result of below checks, but it's not describing
what's actually done here. I think it should say "only parse
partitions on the specified memory type" or something like that.

Re: [PATCH] usb: core: hub: Removed some warnings generated by checkpatch.pl

[Lars Melin]

On 2015-08-15 11:41, Chase Metzger wrote:

Removed some checkpatch.pl warnings saying there was an unwanted space between
function names and their arguments.

Signed-off-by: Chase Metzger 
---
  drivers/usb/core/hub.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 38cb6d3..b9cab51 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4218,7 +4218,7 @@ static int hub_enable_device(struct usb_device *udev)
   * but it is still necessary to lock the port.
   */
  static int
-hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,
+hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
int retry_counter)
  {
struct usb_device   *hdev = hub->hdev;
@@ -4522,7 +4522,7 @@ fail:
  }

  static void
-check_highspeed (struct usb_hub *hub, struct usb_device *udev, int port1)
+check_highspeed(struct usb_hub *hub, struct usb_device *udev, int port1)
  {
struct usb_qualifier_descriptor *qual;
int status;
@@ -4530,11 +4530,11 @@ check_highspeed (struct usb_hub *hub, struct usb_device 
*udev, int port1)
if (udev->quirks & USB_QUIRK_DEVICE_QUALIFIER)
return;

-   qual = kmalloc (sizeof *qual, GFP_KERNEL);
+   qual = kmalloc(sizeof *qual, GFP_KERNEL);
if (qual == NULL)
return;

-   status = usb_get_descriptor (udev, USB_DT_DEVICE_QUALIFIER, 0,
+   status = usb_get_descriptor udev, USB_DT_DEVICE_QUALIFIER, 0,
qual, sizeof *qual);


If you had test compiled you would have got an unbalanced parenthesis 
error here. So you didn't test your patch..



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 5/5] regulator: Regulator driver for the Qualcomm RPM

[Bjorn Andersson]

On Fri 14 Aug 19:14 PDT 2015, Mark Brown wrote:

> On Fri, Aug 14, 2015 at 11:58:35AM -0500, Andy Gross wrote:
> > On Mon, Jul 27, 2015 at 08:20:33PM -0700, Bjorn Andersson wrote:
> > > Driver for regulators exposed by the Resource Power Manager (RPM) found
> > > in devices based on Qualcomm 8974 and newer platforms.
> 
> > > Reviewed-by: Mark Brown 
> > > Signed-off-by: Bjorn Andersson 
> 
> > Mark/Liam, can you please pick this up.  The dependencies for this have 
> > been merged
> > in by the arm/soc maintainers.
> 
> > Acked-by: Andy Gross 
> 
> Please submit any patches you think should be included in the upstream
> kernel using the process documented in SubmittingPatches.

I'm sorry, I thought I did and Andy's comment was to inform you that the
other 4 patches in this series have been merged.

Do you want me to resend this single patch on its own? Or is there
anything else you would like me to do with it?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch v2] soc: qcom: smem: Fix errant private access

[Andy Gross]

This patch corrects private partition item access.  Instead of falling back to
global for instances where we have an actual host and remote partition existing,
return the results of the private lookup.

Signed-off-by: Andy Gross 
---
 drivers/soc/qcom/smem.c |   18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index c809127..7fddf3b 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -264,10 +264,6 @@ static int qcom_smem_alloc_private(struct qcom_smem *smem,
size_t alloc_size;
void *p;
 
-   /* We're not going to find it if there's no matching partition */
-   if (host >= SMEM_HOST_COUNT || !smem->partitions[host])
-   return -ENOENT;
-
phdr = smem->partitions[host];
 
p = (void *)phdr + sizeof(*phdr);
@@ -377,8 +373,9 @@ int qcom_smem_alloc(unsigned host, unsigned item, size_t 
size)
if (ret)
return ret;
 
-   ret = qcom_smem_alloc_private(__smem, host, item, size);
-   if (ret == -ENOENT)
+   if (host < SMEM_HOST_COUNT && __smem->partitions[host])
+   ret = qcom_smem_alloc_private(__smem, host, item, size);
+   else
ret = qcom_smem_alloc_global(__smem, item, size);
 
hwspin_unlock_irqrestore(__smem->hwlock, &flags);
@@ -434,10 +431,6 @@ static int qcom_smem_get_private(struct qcom_smem *smem,
struct smem_private_entry *hdr;
void *p;
 
-   /* We're not going to find it if there's no matching partition */
-   if (host >= SMEM_HOST_COUNT || !smem->partitions[host])
-   return -ENOENT;
-
phdr = smem->partitions[host];
 
p = (void *)phdr + sizeof(*phdr);
@@ -490,8 +483,9 @@ int qcom_smem_get(unsigned host, unsigned item, void **ptr, 
size_t *size)
if (ret)
return ret;
 
-   ret = qcom_smem_get_private(__smem, host, item, ptr, size);
-   if (ret == -ENOENT)
+   if (host < SMEM_HOST_COUNT && __smem->partitions[host])
+   ret = qcom_smem_get_private(__smem, host, item, ptr, size);
+   else
ret = qcom_smem_get_global(__smem, item, ptr, size);
 
hwspin_unlock_irqrestore(__smem->hwlock, &flags);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/7] ARM: bcm2835: Add VC4 to the device tree.

[Stephen Warren]

On 08/12/2015 06:56 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt 

Patch description?


> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

>   arm-pmu {
>   compatible = "arm,arm1176-pmu";
>   };
> +
> + hdmi: brcm,vc4-hdmi@7e902000 {

It'd be nice to keep all the DT nodes with a reg property together, and
sorted in reg order.

As before, I think any DT node for a HW block that may-or-may-not-be
used based on board connectivity/features should be disabled in the SoC
.dtsi file, and enabled in the board's DT file if the feature is useful
for that board.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.

[Stephen Warren]

On 08/12/2015 06:56 PM, Eric Anholt wrote:
> We need to use it for getting video modes over HDMI.

> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

> + i2c2: i2c@7e805000 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e805000 0x1000>;
> + interrupts = <2 21>;
> + clocks = <&clk_i2c>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };

In an SoC .dtsi file, you'd typically write:

status = "disabled";

... in all nodes that represent IO controllers that interface to
external HW, so that board DT files can/must explicitly choose to enable
the device if it's actually in use on the board. Some systems might not
have HDMI and hence might not hook up the HDMI_SCL/SDA pads.

BCM2835-ARM-Peripherals.pdf states "Note that the BSC2 master is used
dedicated with the HDMI interface and should not be accessed by user
programs.". Does this imply the Linux kernel shouldn't be touching this
I2C controller; that the VC4 firmware might also be attempting to use
it? I wonder how any such sharing of the HW would work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] soc: qcom: smem: Fix errant private access

[Bjorn Andersson]

On Fri 14 Aug 20:56 PDT 2015, Andy Gross wrote:

> This patch corrects private partition item access.  Instead of falling back to
> global for instances where we have an actual host and remote partition 
> existing,
> return the results of the private lookup.
> 
> Signed-off-by: Andy Gross 
> ---
>  drivers/soc/qcom/smem.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 7c2c324c..6603201d 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -484,8 +484,9 @@ int qcom_smem_get(unsigned host, unsigned item, void 
> **ptr, size_t *size)
>   if (ret)
>   return ret;
>  
> - ret = qcom_smem_get_private(__smem, host, item, ptr, size);
> - if (ret == -ENOENT)
> + if (host < SMEM_HOST_COUNT && __smem->partitions[host])
> + ret = qcom_smem_get_private(__smem, host, item, ptr, size);
> + else
>   ret = qcom_smem_get_global(__smem, item, ptr, size);

Looks good, but you can drop the if statement in the beginning of the
qcom_smem_get_private() now.

Can you please also do the same change in the alloc path, to keep them
consistent?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Stephen Warren]

On 08/12/2015 06:56 PM, Eric Anholt wrote:
> This is the start of a full VC4 driver.  Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is).  However, this is enough for fbcon and bringing up X using
> xf86-video-modesetting.

> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig

> +config DRM_VC4
> + tristate "Broadcom VC4 Graphics"

> + help
> +   Choose this option if you have a system that has a Broadcom
> +   VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
> +
> +   This driver requires that "avoid_warnings=2" be present in
> +   the config.txt for the firmware, to keep it from smashing
> +   our display setup.

The need for "avoid_warnings=2" seems like it will trip people up. I
don't think it's in any config.txt I've seen. Can you expand more on that?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] SCSI fixes for 4.2-rc6

[James Bottomley]

This patch consists of 2 libfc fixes causing rare crashes, one iscsi one
causing a potential hang on shutdown, an I/O blocksize issue which
caused a regression and a memory leak in scsi-mq.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Bart Van Assche (2):
  libfc: Fix fc_fcp_cleanup_each_cmd()
  libfc: Fix fc_exch_recv_req() error path

John Soni Jose (1):
  libiscsi: Fix host busy blocking during connection teardown

Martin K. Petersen (1):
  sd: Fix maximum I/O size for BLOCK_PC requests

Tony Battersby (1):
  scsi: fix memory leak with scsi-mq

And the diffstat:

 block/blk-settings.c |  4 ++--
 drivers/scsi/libfc/fc_exch.c |  8 
 drivers/scsi/libfc/fc_fcp.c  | 19 +--
 drivers/scsi/libiscsi.c  | 25 ++---
 drivers/scsi/scsi_error.c|  2 +-
 drivers/scsi/scsi_lib.c  |  6 +++---
 drivers/scsi/sd.c|  6 +++---
 7 files changed, 32 insertions(+), 38 deletions(-)

With full diff below.

James

---

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 12600bf..e0057d0 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -241,8 +241,8 @@ EXPORT_SYMBOL(blk_queue_bounce_limit);
  * Description:
  *Enables a low level driver to set a hard upper limit,
  *max_hw_sectors, on the size of requests.  max_hw_sectors is set by
- *the device driver based upon the combined capabilities of I/O
- *controller and storage device.
+ *the device driver based upon the capabilities of the I/O
+ *controller.
  *
  *max_sectors is a soft limit imposed by the block layer for
  *filesystem type requests.  This value can be overridden on a
diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c
index 1b3a094..30f9ef0 100644
--- a/drivers/scsi/libfc/fc_exch.c
+++ b/drivers/scsi/libfc/fc_exch.c
@@ -733,8 +733,6 @@ static bool fc_invoke_resp(struct fc_exch *ep, struct 
fc_seq *sp,
if (resp) {
resp(sp, fp, arg);
res = true;
-   } else if (!IS_ERR(fp)) {
-   fc_frame_free(fp);
}
 
spin_lock_bh(&ep->ex_lock);
@@ -1596,7 +1594,8 @@ static void fc_exch_recv_seq_resp(struct fc_exch_mgr *mp, 
struct fc_frame *fp)
 * If new exch resp handler is valid then call that
 * first.
 */
-   fc_invoke_resp(ep, sp, fp);
+   if (!fc_invoke_resp(ep, sp, fp))
+   fc_frame_free(fp);
 
fc_exch_release(ep);
return;
@@ -1695,7 +1694,8 @@ static void fc_exch_abts_resp(struct fc_exch *ep, struct 
fc_frame *fp)
fc_exch_hold(ep);
if (!rc)
fc_exch_delete(ep);
-   fc_invoke_resp(ep, sp, fp);
+   if (!fc_invoke_resp(ep, sp, fp))
+   fc_frame_free(fp);
if (has_rec)
fc_exch_timer_set(ep, ep->r_a_tov);
fc_exch_release(ep);
diff --git a/drivers/scsi/libfc/fc_fcp.c b/drivers/scsi/libfc/fc_fcp.c
index c679594..2d5909c 100644
--- a/drivers/scsi/libfc/fc_fcp.c
+++ b/drivers/scsi/libfc/fc_fcp.c
@@ -1039,11 +1039,26 @@ restart:
fc_fcp_pkt_hold(fsp);
spin_unlock_irqrestore(&si->scsi_queue_lock, flags);
 
-   if (!fc_fcp_lock_pkt(fsp)) {
+   spin_lock_bh(&fsp->scsi_pkt_lock);
+   if (!(fsp->state & FC_SRB_COMPL)) {
+   fsp->state |= FC_SRB_COMPL;
+   /*
+* TODO: dropping scsi_pkt_lock and then reacquiring
+* again around fc_fcp_cleanup_cmd() is required,
+* since fc_fcp_cleanup_cmd() calls into
+* fc_seq_set_resp() and that func preempts cpu using
+* schedule. May be schedule and related code should be
+* removed instead of unlocking here to avoid scheduling
+* while atomic bug.
+*/
+   spin_unlock_bh(&fsp->scsi_pkt_lock);
+
fc_fcp_cleanup_cmd(fsp, error);
+
+   spin_lock_bh(&fsp->scsi_pkt_lock);
fc_io_compl(fsp);
-   fc_fcp_unlock_pkt(fsp);
}
+   spin_unlock_bh(&fsp->scsi_pkt_lock);
 
fc_fcp_pkt_release(fsp);
spin_lock_irqsave(&si->scsi_queue_lock, flags);
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 8053f24..98d9bb6 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2941,10 +2941,10 @@ void iscsi_conn_teardown(struct iscsi_cls_conn 
*cls_conn)
 {
struct iscsi_conn *conn = cls_conn->dd_data;
struct iscsi_session *session = conn->session;
-   unsigned long flags;
 
del_timer_sync(&conn->transport_timer);
 
+   mutex_lock(&session->eh_mutex);
spin_lock_bh(&session->frwd_lock);
co

[PATCH] usb: core: hub: Removed some warnings generated by checkpatch.pl

[Chase Metzger]

Removed some checkpatch.pl warnings saying there was an unwanted space between
function names and their arguments.

Signed-off-by: Chase Metzger 
---
 drivers/usb/core/hub.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 38cb6d3..b9cab51 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4218,7 +4218,7 @@ static int hub_enable_device(struct usb_device *udev)
  * but it is still necessary to lock the port.
  */
 static int
-hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,
+hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
int retry_counter)
 {
struct usb_device   *hdev = hub->hdev;
@@ -4522,7 +4522,7 @@ fail:
 }
 
 static void
-check_highspeed (struct usb_hub *hub, struct usb_device *udev, int port1)
+check_highspeed(struct usb_hub *hub, struct usb_device *udev, int port1)
 {
struct usb_qualifier_descriptor *qual;
int status;
@@ -4530,11 +4530,11 @@ check_highspeed (struct usb_hub *hub, struct usb_device 
*udev, int port1)
if (udev->quirks & USB_QUIRK_DEVICE_QUALIFIER)
return;
 
-   qual = kmalloc (sizeof *qual, GFP_KERNEL);
+   qual = kmalloc(sizeof *qual, GFP_KERNEL);
if (qual == NULL)
return;
 
-   status = usb_get_descriptor (udev, USB_DT_DEVICE_QUALIFIER, 0,
+   status = usb_get_descriptor udev, USB_DT_DEVICE_QUALIFIER, 0,
qual, sizeof *qual);
if (status == sizeof *qual) {
dev_info(&udev->dev, "not running at top speed; "
@@ -4550,7 +4550,7 @@ check_highspeed (struct usb_hub *hub, struct usb_device 
*udev, int port1)
 }
 
 static unsigned
-hub_power_remaining (struct usb_hub *hub)
+hub_power_remaining(struct usb_hub *hub)
 {
struct usb_device *hdev = hub->hdev;
int remaining;
@@ -4737,7 +4737,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
port1, u16 portstatus,
if (le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0200
&& udev->speed == USB_SPEED_FULL
&& highspeed_hubs != 0)
-   check_highspeed (hub, udev, port1);
+   check_highspeed(hub, udev, port1);
 
/* Store the parent's children[] pointer.  At this point
 * udev becomes globally accessible, although presumably
@@ -5111,7 +5111,7 @@ static const struct usb_device_id hub_id_table[] = {
 { }/* Terminating entry */
 };
 
-MODULE_DEVICE_TABLE (usb, hub_id_table);
+MODULE_DEVICE_TABLE(usb, hub_id_table);
 
 static struct usb_driver hub_driver = {
.name = "hub",
@@ -5223,7 +5223,7 @@ static int descriptors_changed(struct usb_device *udev,
changed = 1;
break;
}
-   if (memcmp (buf, udev->rawdescriptors[index], old_length)
+   if (memcmp(buf, udev->rawdescriptors[index], old_length)
!= 0) {
dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
index,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 2/4] serial: imx: add runtime pm support

[Eduardo Valentin]

This change introduces the runtime pm support on imx serial
driver. The objective is to be able to idle the uart
port whenever it is not in use while still being able
to wake it up when needed. The key changes in this patch are:
1. Move the clock handling to runtime pm. Both, ipg and per,
are now handled in the suspend and resume callbacks. Only
enabling and disabling the clocks are handled in runtime
suspend and resume, so we are able to use runtime pm
in IRQ context.
2. Clocks are prepared in probe and unprepared in remove,
so we do not need to prepare (may sleep) in runtime pm.
3. We mark the device activity based on uart and console
callbacks. Whenever the device is needed and we want to
access registers, we runtime_pm_get and then mark its
last usage when we are done. This is done also across
IRQs and DMA callbacks.
4. We reuse the infrastructure in place for suspend and
resume, so we do not need to redo wakeup configuration,
or context save and restore.

After this change, the clocks are still sane, in the sense
of having balanced clock prepare and enable.

Cc: Fabio Estevam 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/tty/serial/imx.c | 239 +--
 1 file changed, 191 insertions(+), 48 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 50abb60..d9ccf6b 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -39,6 +39,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -369,6 +372,7 @@ static void imx_stop_tx(struct uart_port *port)
if (sport->dma_is_enabled && sport->dma_is_txing)
return;
 
+   pm_runtime_get_sync(sport->port.dev);
temp = readl(port->membase + UCR1);
writel(temp & ~UCR1_TXMPTYEN, port->membase + UCR1);
 
@@ -386,6 +390,8 @@ static void imx_stop_tx(struct uart_port *port)
temp &= ~UCR4_TCEN;
writel(temp, port->membase + UCR4);
}
+   pm_runtime_mark_last_busy(sport->port.dev);
+   pm_runtime_put_autosuspend(sport->port.dev);
 }
 
 /*
@@ -405,12 +411,15 @@ static void imx_stop_rx(struct uart_port *port)
}
}
 
+   pm_runtime_get_sync(sport->port.dev);
temp = readl(sport->port.membase + UCR2);
writel(temp & ~UCR2_RXEN, sport->port.membase + UCR2);
 
/* disable the `Receiver Ready Interrrupt` */
temp = readl(sport->port.membase + UCR1);
writel(temp & ~UCR1_RRDYEN, sport->port.membase + UCR1);
+   pm_runtime_mark_last_busy(sport->port.dev);
+   pm_runtime_put_autosuspend(sport->port.dev);
 }
 
 /*
@@ -482,6 +491,7 @@ static void dma_tx_callback(void *data)
unsigned long flags;
unsigned long temp;
 
+   pm_runtime_get_sync(sport->port.dev);
spin_lock_irqsave(&sport->port.lock, flags);
 
dma_unmap_sg(sport->port.dev, sgl, sport->dma_tx_nents, DMA_TO_DEVICE);
@@ -506,13 +516,17 @@ static void dma_tx_callback(void *data)
if (waitqueue_active(&sport->dma_wait)) {
wake_up(&sport->dma_wait);
dev_dbg(sport->port.dev, "exit in %s.\n", __func__);
-   return;
+   goto mark_last;
}
 
spin_lock_irqsave(&sport->port.lock, flags);
if (!uart_circ_empty(xmit) && !uart_tx_stopped(&sport->port))
imx_dma_tx(sport);
spin_unlock_irqrestore(&sport->port.lock, flags);
+
+mark_last:
+   pm_runtime_mark_last_busy(sport->port.dev);
+   pm_runtime_put_autosuspend(sport->port.dev);
 }
 
 static void imx_dma_tx(struct imx_port *sport)
@@ -579,6 +593,7 @@ static void imx_start_tx(struct uart_port *port)
struct imx_port *sport = (struct imx_port *)port;
unsigned long temp;
 
+   pm_runtime_get_sync(sport->port.dev);
if (port->rs485.flags & SER_RS485_ENABLED) {
/* enable transmitter and shifter empty irq */
temp = readl(port->membase + UCR2);
@@ -606,14 +621,18 @@ static void imx_start_tx(struct uart_port *port)
temp &= ~UCR1_TDMAEN;
temp |= UCR1_TXMPTYEN;
writel(temp, sport->port.membase + UCR1);
-   return;
+   goto mark_last;
}
 
if (!uart_circ_empty(&port->state->xmit) &&
!uart_tx_stopped(port))
imx_dma_tx(sport);
-   return;
+   goto mark_last;
}
+
+mark_last:
+   pm_runtime_mark_last_busy(sport->port.dev);
+   pm_runtime_put_autosuspend(sport->port.dev);
 }
 
 static irqreturn_t imx_rtsint(int irq, void *dev_id)
@@ -622,6 +641,7 @@ static irqreturn_t imx_rtsint(int irq, void *dev_id)
unsigned int val;
unsigned long flags;
 
+   pm_runtime_get_sync(sport->p

[PATCHv4 1/4] serial: imx: add a flag to indicate we are in the suspend path

[Eduardo Valentin]

This is a simple flag that gets set across prepare and complete
callbacks in the suspend path. We the flag we may avoid
runtime pm idling at the same time.

Cc: Fabio Estevam 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/tty/serial/imx.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index fe3d41c..50abb60 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -218,6 +218,8 @@ struct imx_port {
wait_queue_head_t   dma_wait;
unsigned intsaved_reg[10];
boolcontext_saved;
+
+   boolis_suspending;
 };
 
 struct imx_port_ucrs {
@@ -2026,6 +2028,22 @@ static void serial_imx_enable_wakeup(struct imx_port 
*sport, bool on)
writel(val, sport->port.membase + UCR1);
 }
 
+static int serial_imx_prepare(struct device *dev)
+{
+   struct imx_port *sport = dev_get_drvdata(dev);
+
+   sport->is_suspending = true;
+
+   return 0;
+}
+
+static void serial_imx_complete(struct device *dev)
+{
+   struct imx_port *sport = dev_get_drvdata(dev);
+
+   sport->is_suspending = false;
+}
+
 static int imx_serial_port_suspend_noirq(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -2091,6 +2109,8 @@ static const struct dev_pm_ops imx_serial_port_pm_ops = {
.resume_noirq = imx_serial_port_resume_noirq,
.suspend = imx_serial_port_suspend,
.resume = imx_serial_port_resume,
+   .prepare = serial_imx_prepare,
+   .complete = serial_imx_complete,
 };
 
 static struct platform_driver serial_imx_driver = {
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Stephen Warren]

On 08/12/2015 06:56 PM, Eric Anholt wrote:

> diff --git a/MAINTAINERS b/MAINTAINERS

> +DRM DRIVERS FOR VC4
> +M:   Eric Anholt 
> +T:   git git://github.com/anholt/linux
> +S:   Maintained
> +F:   drivers/gpu/drm/vc4/*

S: Supported

?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 3/4] serial: imx: add pm_qos request

[Eduardo Valentin]

This change introduces pm_qos requests in the imx serial driver.
The idea is to skip deeper C-state in case we need a strict
latency requirement in the uart port. The latency is
computed based on the buffer size and the current baud rate.
We schedule a work queue to set the pm qos requirement.

Cc: Fabio Estevam 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 drivers/tty/serial/imx.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index d9ccf6b..24ed0fa 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -222,6 +223,10 @@ struct imx_port {
unsigned intsaved_reg[10];
boolcontext_saved;
 
+   struct pm_qos_request   pm_qos_request;
+   u32 latency;
+   u32 calc_latency;
+   struct work_struct  qos_work;
boolis_suspending;
 };
 
@@ -1320,6 +1325,14 @@ static void imx_flush_buffer(struct uart_port *port)
pm_runtime_put_autosuspend(sport->port.dev);
 }
 
+static void serial_imx_uart_qos_work(struct work_struct *work)
+{
+   struct imx_port *sport = container_of(work, struct imx_port,
+   qos_work);
+
+   pm_qos_update_request(&sport->pm_qos_request, sport->latency);
+}
+
 static void
 imx_set_termios(struct uart_port *port, struct ktermios *termios,
   struct ktermios *old)
@@ -1393,6 +1406,12 @@ imx_set_termios(struct uart_port *port, struct ktermios 
*termios,
baud = uart_get_baud_rate(port, termios, old, 50, port->uartclk / 16);
quot = uart_get_divisor(port, baud);
 
+   /* calculate wakeup latency constraint */
+   sport->calc_latency = (USEC_PER_SEC * sport->port.fifosize) /
+   (baud / 8);
+   sport->latency = sport->calc_latency;
+   schedule_work(&sport->qos_work);
+
spin_lock_irqsave(&sport->port.lock, flags);
 
sport->port.read_status_mask = 0;
@@ -2012,6 +2031,11 @@ static int serial_imx_probe(struct platform_device *pdev)
 
imx_ports[sport->port.line] = sport;
 
+   sport->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
+   sport->calc_latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
+   pm_qos_add_request(&sport->pm_qos_request, PM_QOS_CPU_DMA_LATENCY,
+  sport->latency);
+   INIT_WORK(&sport->qos_work, serial_imx_uart_qos_work);
platform_set_drvdata(pdev, sport);
 
device_init_wakeup(sport->port.dev, true);
@@ -2041,6 +2065,7 @@ static int serial_imx_remove(struct platform_device *pdev)
clk_unprepare(sport->clk_per);
clk_unprepare(sport->clk_ipg);
ret = uart_remove_one_port(&imx_reg, &sport->port);
+   pm_qos_remove_request(&sport->pm_qos_request);
device_init_wakeup(&pdev->dev, false);
 
return ret;
@@ -2119,6 +2144,8 @@ static int serial_imx_runtime_suspend(struct device *dev)
serial_imx_save_context(sport);
serial_imx_enable_wakeup(sport, true);
 
+   sport->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
+   schedule_work(&sport->qos_work);
clk_disable(sport->clk_per);
clk_disable(sport->clk_ipg);
 
@@ -2140,6 +2167,8 @@ static int serial_imx_runtime_resume(struct device *dev)
}
serial_imx_enable_wakeup(sport, false);
 
+   sport->latency = sport->calc_latency;
+   schedule_work(&sport->qos_work);
serial_imx_restore_context(sport);
 
return 0;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.

[Stephen Warren]

On 08/12/2015 06:56 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt 

This one definitely needs a patch description, since someone might not
know what a VC4 is, and "git log" won't show the text from the binding
doc itself. I'd suggest adding the initial paragraph of the binding doc
as the patch description, or more.

> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
> b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

> +Required properties for VC4:
> +- compatible:Should be "brcm,vc4"
> +- crtcs: List of references to pixelvalve scanout engines

s/references to/phandles of/ would be more typical DT language.

> +- hvss:  List of references to HVS video scalers
> +- encoders:  List of references to output encoders (HDMI, SDTV)

Would it make sense to make all those nodes child node of the vc4
object. That way, there's no need to have these lists of objects; they
can be automatically built up as the DT is enumerated. I know that e.g.
the NVIDIA Tegra host1x binding works this way, and I think it may have
been inspired by other similar cases.

Of course, this is only appropriate if the HW modules really are
logically children of the VC4 HW module. Perhaps they aren't. If they
aren't though, I wonder what this "vc4" module actually represents in HW?

> +Required properties for HDMI
> +- compatible:Should be "brcm,vc4-hdmi"
> +- reg:   Physical base address and length of the two register 
> ranges
> +   ("HDMI" and "HD")

I'd add "in that order" right before ")".

> +Example:
> +/ {
> + soc {

Minor nit: Examples often don't include any nodes "above" the nodes
whose bindings are being documented.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 4/4] serial: imx: use SET_*SYSTEM_PM_OPS helper functions

[Eduardo Valentin]

Instead of setting manually each field, use the helper functions
provided by the PM subsystem.

Signed-off-by: Eduardo Valentin 
---
 drivers/tty/serial/imx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 24ed0fa..bdda44d5 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2277,10 +2277,10 @@ static int imx_serial_port_resume(struct device *dev)
 static const struct dev_pm_ops imx_serial_port_pm_ops = {
SET_RUNTIME_PM_OPS(serial_imx_runtime_suspend,
   serial_imx_runtime_resume, NULL)
-   .suspend_noirq = imx_serial_port_suspend_noirq,
-   .resume_noirq = imx_serial_port_resume_noirq,
-   .suspend = imx_serial_port_suspend,
-   .resume = imx_serial_port_resume,
+   SET_SYSTEM_SLEEP_PM_OPS(imx_serial_port_suspend_noirq,
+   imx_serial_port_resume_noirq)
+   SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_serial_port_suspend,
+ imx_serial_port_resume)
.prepare = serial_imx_prepare,
.complete = serial_imx_complete,
 };
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 0/4] serial: imx: rework pm support and add runtime pm

[Eduardo Valentin]

Hello all,


This is version 3 of a patch series to introduce runtime pm in the imx serial
driver. The idea is to get runtime pm to handle ipg and per clocks, idling
the device when possible, configuring wakeups, and saving and restoring
context when needed.

A minor refactoring was needed to get things done. On top of it I am also
adding pm_qos support in the driver too.

Changelog:

V3->V4:
- Remove *dev from sport and reused sport->port.dev.
- Rebased on top of tty-testing (initial 4 patches were already applied by greg)

V3: https://lkml.org/lkml/2015/8/11/581

V2->V3:
- error checking handling on clk_*enable functions
- added a missing return
- moved some of the code from the runtime pm patch to the pm qos patch, which
were causing compilation issues.
V2: http://marc.info/?l=linux-pm&m=143925695931624&w=2

V1->V2:
- The difference now is that it is rebased on top of linux-next, given
that some of the work done in v1 was already sent.
V1: http://marc.info/?l=linux-pm&m=143914435605790&w=2

As always, comments are welcome.

BR,

Eduardo Valentin (4):
  serial: imx: add a flag to indicate we are in the suspend path
  serial: imx: add runtime pm support
  serial: imx: add pm_qos request
  serial: imx: use SET_*SYSTEM_PM_OPS helper functions

 drivers/tty/serial/imx.c | 296 ++-
 1 file changed, 244 insertions(+), 52 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 2/3] clk: Add a Raspberry Pi-specific clock driver.

[Stephen Warren]

On 08/13/2015 05:05 PM, Eric Anholt wrote:
> Unfortunately, the clock manager's registers are not accessible by the
> ARM, so we have to request that the firmware modify our clocks for us.
> 
> This driver only registers the clocks at the point they are requested
> by a client driver.  This is partially to support returning
> -EPROBE_DEFER when the firmware driver isn't supported yet, but it
> also avoids issues with disabling "unused" clocks due to them not yet
> being connected to their consumers in the DT.

> diff --git a/drivers/clk/clk-raspberrypi.c b/drivers/clk/clk-raspberrypi.c

> +static const struct {
> + const char *name;
> + int flags;
> +} rpi_clocks[] = {
> + [RPI_CLOCK_EMMC] = { "emmc", CLK_IS_ROOT },
> + [RPI_CLOCK_UART0] = { "uart0", CLK_IS_ROOT },
> + [RPI_CLOCK_ARM] = { "arm", CLK_IS_ROOT | CLK_IGNORE_UNUSED },
> + [RPI_CLOCK_CORE] = { "core", CLK_IS_ROOT | CLK_IGNORE_UNUSED },
> + [RPI_CLOCK_V3D] = { "v3d", CLK_IS_ROOT },
> + [RPI_CLOCK_H264] = { "h264", CLK_IS_ROOT },
> + [RPI_CLOCK_ISP] = { "isp", CLK_IS_ROOT },
> + [RPI_CLOCK_SDRAM] = { "sdram", CLK_IS_ROOT | CLK_IGNORE_UNUSED },
> + [RPI_CLOCK_PIXEL] = { "pixel", CLK_IS_ROOT | CLK_IGNORE_UNUSED },
> + [RPI_CLOCK_PWM] = { "pwm", CLK_IS_ROOT },
> +};
> +
> +struct rpi_firmware_clock {
> + /* Clock definitions in our static struct. */
> + const char *name;
> + int flags;

Are these duplicates of the values in rpi_clocks[]? Why not just store a
pointer to or index of the entry in that array?

> +static int rpi_clk_set_state(struct clk_hw *hw, bool on)
> +{
> + struct rpi_firmware_clock *rpi_clk =
> + container_of(hw, struct rpi_firmware_clock, hw);
> + u32 packet[2];
> + int ret;
> +
> + if (on == (rpi_clk->last_rate != 0))
> + return 0;

The overloading of last_rate to represent both rate information and
on/off status is slightly confusing. I would have expected this function
to clear last_rate to 0 when switching the clock off, and some specific
rate when turning a clock on. Is there some guarantee that the clock
core will always call recalc_rate() at certain times, thus ensuring that
last_rate is always accurate?

Wouldn't it be simpler to let last_rate always represent that actual
rate, and have a separate last_on or is_on field to represent the
enable/disable state?

> +static unsigned long rpi_clk_get_rate(struct clk_hw *hw,
> +   unsigned long parent_rate)
...
> + rpi_clk->last_rate = packet[1];

Since this is a query API, I wouldn't have expected it to have
side-effects like this. Don't we know what rate the clock runs at based
on the firmware's response in set_rate()?

> +static int rpi_clk_probe(struct platform_device *pdev)

> + onecell = devm_kmalloc(dev, sizeof(*onecell), GFP_KERNEL);
> + if (!onecell)
> + return -ENOMEM;
> + onecell->clk_num = ARRAY_SIZE(rpi_clocks);
> + onecell->clks = devm_kzalloc(dev, sizeof(*onecell->clks), GFP_KERNEL);

Don't you need to multiply the size by ARRAY_SIZE(rpi_clocks)? I assume
onecell->clks is an array with one entry per each of onecell->clk_num?
Yes, the for loop right after that allocation confirms this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched: sync with the cfs_rq when changing sched class

[Byungchul Park]

On Fri, Aug 14, 2015 at 08:59:02PM +0800, T. Zhou wrote:
> Hi,
> 
> On Thu, Aug 13, 2015 at 02:55:55PM +0900, byungchul.p...@lge.com wrote:
> > +static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> > sched_entity *se)
> > +{
> > +   se->avg.last_update_time = cfs_rq->avg.last_update_time;
> > +   cfs_rq->avg.load_avg += se->avg.load_avg;
> > +   cfs_rq->avg.load_sum += se->avg.load_sum;
> > +   cfs_rq->avg.util_avg += se->avg.util_avg;
> > +   cfs_rq->avg.util_sum += se->avg.util_sum;
> > +}
> 
> I see this function is used in enqueue_entity_load_avg() also.
> In tip tree code, enqueue_entity_load_avg() uses cfs_rq_clock_task()
> as se->last_update_time in migration condition.
> Here, you use cfs_rq->avg.last_update_time as se->last_update_time.
> If se->last_update_time is different, next decay may be different too.
> Just from inspecting code, maybe some reasonable there?

hello zhou,

update_cfs_rq_load_avg() would update cfs_rq->avg.last_update_time to now,
which is returned from cfs_rq_clock_task(). :)

thanks,
byungchul

> 
> Thanks
> > +static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct 
> > sched_entity *se)
> > +{
> > +   __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq_of(cfs_rq)),
> > +   &se->avg, se->on_rq * scale_load_down(se->load.weight),
> > +   cfs_rq->curr == se, NULL);
> > +
> > +   cfs_rq->avg.load_avg =
> > +   max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
> > +   cfs_rq->avg.load_sum =
> > +   max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
> > +   cfs_rq->avg.util_avg =
> > +   max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
> > +   cfs_rq->avg.util_sum =
> > +   max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
> > +}
> > +
> >  /* Add the load generated by se into cfs_rq's load average */
> >  static inline void
> >  enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > @@ -2717,27 +2742,20 @@ enqueue_entity_load_avg(struct cfs_rq *cfs_rq, 
> > struct sched_entity *se)
> > u64 now = cfs_rq_clock_task(cfs_rq);
> > int migrated = 0, decayed;
> >  
> > -   if (sa->last_update_time == 0) {
> > -   sa->last_update_time = now;
> > +   if (sa->last_update_time == 0)
> > migrated = 1;
> > -   }
> > -   else {
> > +   else
> > __update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
> > -   se->on_rq * scale_load_down(se->load.weight),
> > -   cfs_rq->curr == se, NULL);
> > -   }
> > +   se->on_rq * scale_load_down(se->load.weight),
> > +   cfs_rq->curr == se, NULL);
> >  
> > decayed = update_cfs_rq_load_avg(now, cfs_rq);
> >  
> > cfs_rq->runnable_load_avg += sa->load_avg;
> > cfs_rq->runnable_load_sum += sa->load_sum;
> >  
> > -   if (migrated) {
> > -   cfs_rq->avg.load_avg += sa->load_avg;
> > -   cfs_rq->avg.load_sum += sa->load_sum;
> > -   cfs_rq->avg.util_avg += sa->util_avg;
> > -   cfs_rq->avg.util_sum += sa->util_sum;
> > -   }
> > +   if (migrated)
> > +   attach_entity_load_avg(cfs_rq, se);
> >  
> > if (decayed || migrated)
> > update_tg_load_avg(cfs_rq, 0);
> > @@ -7911,17 +7929,7 @@ static void switched_from_fair(struct rq *rq, struct 
> > task_struct *p)
> >  
> >  #ifdef CONFIG_SMP
> > /* Catch up with the cfs_rq and remove our load when we leave */
> > -   __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq), &se->avg,
> > -   se->on_rq * scale_load_down(se->load.weight), cfs_rq->curr == 
> > se, NULL);
> > -
> > -   cfs_rq->avg.load_avg =
> > -   max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
> > -   cfs_rq->avg.load_sum =
> > -   max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
> > -   cfs_rq->avg.util_avg =
> > -   max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
> > -   cfs_rq->avg.util_sum =
> > -   max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
> > +   detach_entity_load_avg(cfs_rq, se);
> >  #endif
> >  }
> >  
> > @@ -7938,6 +7946,11 @@ static void switched_to_fair(struct rq *rq, struct 
> > task_struct *p)
> >  */
> > se->depth = se->parent ? se->parent->depth + 1 : 0;
> >  #endif
> > +
> > +#ifdef CONFIG_SMP
> > +   /* synchronize task with its cfs_rq */
> > +   attach_entity_load_avg(cfs_rq_of(&p->se), &p->se);
> > +#endif
> > if (!task_on_rq_queued(p))
> > return;
> >  
> > @@ -8023,16 +8036,7 @@ static void task_move_group_fair(struct task_struct 
> > *p, int queued)
> >  
> >  #ifdef CONFIG_SMP
> > /* synchronize task with its prev cfs_rq */
> > -   if (!queued)
> > -   __update_load_avg(cfs_rq->avg.last_update_time, 
> > cpu_of(rq_of(cfs_rq)),
> > -   &se->avg, se->on_rq * 
> > scale_load_down(se->load.weight),
> > -   cfs_rq->curr == se, NULL);
> > -
> > -

Re: [PATCH v5 3/3] ARM: bcm2835: Add DT for the firmware clocks driver.

[Stephen Warren]

On 08/13/2015 05:05 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt 
> Acked-by: Lee Jones 

A patch description might be nice, although admittedly the subject seems
clear enough.

> diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
> b/arch/arm/boot/dts/bcm2835-rpi.dtsi

> + firmware_clocks: firmware-clocks {
> + compatible = "raspberrypi,bcm2835-firmware-clocks";
> + #clock-cells = <1>;
> + raspberrypi,firmware = <&firmware>;
> + };

No need to resend for this, but just a background note: DT node names
usually contain a device type not a device identity, so "clocks" not
"firmware-clocks" would be typical.

This patch,
Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] soc: qcom: smem: Fix errant private access

[Andy Gross]

This patch corrects private partition item access.  Instead of falling back to
global for instances where we have an actual host and remote partition existing,
return the results of the private lookup.

Signed-off-by: Andy Gross 
---
 drivers/soc/qcom/smem.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 7c2c324c..6603201d 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -484,8 +484,9 @@ int qcom_smem_get(unsigned host, unsigned item, void **ptr, 
size_t *size)
if (ret)
return ret;
 
-   ret = qcom_smem_get_private(__smem, host, item, ptr, size);
-   if (ret == -ENOENT)
+   if (host < SMEM_HOST_COUNT && __smem->partitions[host])
+   ret = qcom_smem_get_private(__smem, host, item, ptr, size);
+   else
ret = qcom_smem_get_global(__smem, item, ptr, size);
 
hwspin_unlock_irqrestore(__smem->hwlock, &flags);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm: rpi: Device tree modifications for U-Boot

[Stephen Warren]

On 08/12/2015 07:21 AM, Simon Glass wrote:
> Hi Lucas,
> 
> On 11 August 2015 at 11:05, Lucas Stach  wrote:
>> Hi Simon,
>>
>> why did you send this to the Tegra ML?
>>
>> Am Dienstag, den 11.08.2015, 08:25 -0600 schrieb Simon Glass:
>>> This updates the device tree from the kernel version to something suitable
>>> for U-Boot:
>>>
>>> - Add stdout-path alias for console
>>> - Mark the /soc node to be available pre-relocation so that the early
>>> serial console works (we need the 'ranges' property to be available)
>>>
>>> Signed-off-by: Simon Glass 
>>> ---
>>>
>>>  arch/arm/boot/dts/bcm2835.dtsi | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
>>> index 301c73f..bd6bff6 100644
>>> --- a/arch/arm/boot/dts/bcm2835.dtsi
>>> +++ b/arch/arm/boot/dts/bcm2835.dtsi
>>> @@ -8,6 +8,7 @@
>>>
>>>   chosen {
>>>   bootargs = "earlyprintk console=ttyAMA0";
>>> + stdout-path = &uart;
>>>   };
>>>
>>>   soc {
>>> @@ -16,6 +17,7 @@
>>>   #size-cells = <1>;
>>>   ranges = <0x7e00 0x2000 0x0200>;
>>>   dma-ranges = <0x4000 0x 0x2000>;
>>> + u-boot,dm-pre-reloc;
>>
>> Why do you need this and why should upstream carry your favourite
>> bootloaders configuration? This is in no way hardware description.
> 
> I'm not sure how much you know about U-Boot, so let me know if you
> need more info.
> 
> U-Boot normally starts up by setting up its serial UART and displaying
> a banner message. At this stage typically only a few devices are
> initialised (e.g. maybe just the UART). It then relocates itself to
> the top of memory and starts up all the devices. It throws away any
> previous devices that it set up before relocation and starts again.
> 
> U-Boot uses a thing called driver model (dm) which handles driver
> binding and probing. Driver model has the device tree and would
> normally scan through it and create devices for everything it finds.
> 
> Before relocation we don't need every device. Also the CPU is often
> running slowly, perhaps without the cache enabled. SDRAM may not be
> available yet so space is short. We want to avoid starting up things
> that will not be used.
> 
> So this property indicates that the device is needed before relocation
> and should be set up by driver model. We need it to avoid a very slow
> and memory-hungry startup.
> 
> As to why upstream should accept it, my understanding of upstream is
> that people can send patches to it and in fact are encouraged to do
> so, to avoid misunderstandings and duplication. The device tree files
> are stored in Linux so any binding or source file changes should end
> up there. Otherwise the files tend to diverge and we end up with
> multiple bindings and multiple versions of the same source file.

On many platforms, we have U-Boot SPL running first, then the main
U-Boot. The main U-Boot binary contains both the code to do the
relocation and the binary that runs after relocation. It seems like it'd
be simpler to split these up into 3 binaries that each do a single job:

1) SPL, roughly as-is today (varying jobs depending on platform)

2) Relocator, which does nothing but work out where to copy U-Boot,
memcpy()s it there, relocates the image (if not PIE), and jumps to it.

3) The main U-Boot.

Item (2) above should be simple enough that it can use a very simple
debug mechanism rather like DEBUG_LL in the Linux kernel. Similar to
what Rob mentioned in his email.

Item (3) could use DM and DT/ACPI/... to get device information in a
complete non-hard-coded manner.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: core: Define regulator_set_voltage_triplet()

[Viresh Kumar]

On 14-08-15, 17:25, Mark Brown wrote:
> On Fri, Aug 14, 2015 at 05:30:55PM +0530, Viresh Kumar wrote:
> 
> > The OPP (Operating performance points) v2 bindings allows regulator
> > voltage to be supplied as a triplet of  voltages.
> 
> Looking at this I really don't understand why you tried to get me to
> review this via an IRC pastebin instead of following the normal patch
> submission process.  Please don't do that, it's not at all helpful.  IRC
> can be useful for interactive discussions or things that are really
> urgent, not for normal upstream code review.

Okay.

> > +static inline int regulator_set_voltage_triplet(struct regulator 
> > *regulator,
> > +   int target_uV, int min_uV,
> > +   int max_uV)
> 
> This seems awkward, these things are normally written as min <= target
> <= max but this is target, min, max.

Hmm..

> >  static inline int regulator_set_voltage_tol(struct regulator *regulator,
> > int new_uV, int tol_uV)
> >  {
> > -- 
> > 2.4.0
> 
> You've not added a stub for the new function.

This function will always be present as its not part of the #ifdef
CONFIG_REGULATOR region.

And so the stub isn't required.

Hopefully below version looks better ?

8<--
Message-Id: 
<3d0154d897bba396c5018cf3b3562871af4ca844.1439608146.git.viresh.ku...@linaro.org>
From: Viresh Kumar 
Date: Fri, 14 Aug 2015 15:06:10 +0530
Subject: [PATCH] regulator: core: Define regulator_set_voltage_triplet()

The OPP (Operating performance points) v2 bindings allows regulator
voltage to be supplied as a triplet of  voltages.

Add regulator_set_voltage_triplet() API in regulator core to support
that.

This first tries to set a voltage between the target voltage and the
upper limit, then fall back on the full range. The idea behind this is
to set regulator's voltage as close to the target voltage, as possible.

Based on regulator_set_voltage_tol().

Signed-off-by: Viresh Kumar 
---
 include/linux/regulator/consumer.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/regulator/consumer.h 
b/include/linux/regulator/consumer.h
index f8a689ed62a5..a6269c184b8c 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -552,6 +552,16 @@ static inline int regulator_count_voltages(struct 
regulator *regulator)
 }
 #endif
 
+static inline int regulator_set_voltage_triplet(struct regulator *regulator,
+   int min_uV, int target_uV,
+   int max_uV)
+{
+   if (!regulator_set_voltage(regulator, target_uV, max_uV))
+   return 0;
+
+   return regulator_set_voltage(regulator, min_uV, max_uV);
+}
+
 static inline int regulator_set_voltage_tol(struct regulator *regulator,
int new_uV, int tol_uV)
 {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ASoC: davinci-vcif: Use devm_snd_soc_register_component

[Vaishali Thakkar]

Use resource managed function devm_snd_soc_register_component for
component registration instead of snd_soc_register_component.

Also, remove davinci_vcif_remove as it is now redundant.

Signed-off-by: Vaishali Thakkar 
---
 sound/soc/davinci/davinci-vcif.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/sound/soc/davinci/davinci-vcif.c b/sound/soc/davinci/davinci-vcif.c
index fabd05f..c77d921 100644
--- a/sound/soc/davinci/davinci-vcif.c
+++ b/sound/soc/davinci/davinci-vcif.c
@@ -231,8 +231,9 @@ static int davinci_vcif_probe(struct platform_device *pdev)
 
dev_set_drvdata(&pdev->dev, davinci_vcif_dev);
 
-   ret = snd_soc_register_component(&pdev->dev, &davinci_vcif_component,
-&davinci_vcif_dai, 1);
+   ret = devm_snd_soc_register_component(&pdev->dev,
+ &davinci_vcif_component,
+ &davinci_vcif_dai, 1);
if (ret != 0) {
dev_err(&pdev->dev, "could not register dai\n");
return ret;
@@ -241,23 +242,14 @@ static int davinci_vcif_probe(struct platform_device 
*pdev)
ret = edma_pcm_platform_register(&pdev->dev);
if (ret) {
dev_err(&pdev->dev, "register PCM failed: %d\n", ret);
-   snd_soc_unregister_component(&pdev->dev);
return ret;
}
 
return 0;
 }
 
-static int davinci_vcif_remove(struct platform_device *pdev)
-{
-   snd_soc_unregister_component(&pdev->dev);
-
-   return 0;
-}
-
 static struct platform_driver davinci_vcif_driver = {
.probe  = davinci_vcif_probe,
-   .remove = davinci_vcif_remove,
.driver = {
.name   = "davinci-vcif",
},
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Applied "regmap: Fix integertypes for register address and value" to the regmap tree

[Mark Brown]

The patch

   regmap: Fix integertypes for register address and value

has been applied to the regmap tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 2f9b660b2128c92d66f18ac7fbd7c39a91cec159 Mon Sep 17 00:00:00 2001
From: Markus Pargmann 
Date: Wed, 12 Aug 2015 12:12:28 +0200
Subject: [PATCH] regmap: Fix integertypes for register address and value

These values are defined as unsigned int in the struct and are assigned
to int values.

This patch fixes the type to be unsigned int instead.

Signed-off-by: Markus Pargmann 
Signed-off-by: Mark Brown 
---
 drivers/base/regmap/regmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 7111d04..9b4badc 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1768,8 +1768,8 @@ static int _regmap_raw_multi_reg_write(struct regmap *map,
u8 = buf;
 
for (i = 0; i < num_regs; i++) {
-   int reg = regs[i].reg;
-   int val = regs[i].def;
+   unsigned int reg = regs[i].reg;
+   unsigned int val = regs[i].def;
trace_regmap_hw_write_start(map, reg, 1);
map->format.format_reg(u8, reg, map->reg_shift);
u8 += reg_bytes + pad_bytes;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Applied "regmap: fix typos in regmap.c" to the regmap tree

[Mark Brown]

The patch

   regmap: fix typos in regmap.c

has been applied to the regmap tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From b486afbd1baf796a9e4b793b2f9121c12e1469af Mon Sep 17 00:00:00 2001
From: Xiubo Li 
Date: Wed, 12 Aug 2015 15:02:19 +0800
Subject: [PATCH] regmap: fix typos in regmap.c

There are two typos in drivers/base/regmap/regmap.c, and they may
introduce some noise when checking new patches.

Signed-off-by: Xiubo Li 
Signed-off-by: Mark Brown 
---
 drivers/base/regmap/regmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 7111d04..cae3f26 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1740,7 +1740,7 @@ EXPORT_SYMBOL_GPL(regmap_bulk_write);
  *
  * the (register,newvalue) pairs in regs have not been formatted, but
  * they are all in the same page and have been changed to being page
- * relative. The page register has been written if that was neccessary.
+ * relative. The page register has been written if that was necessary.
  */
 static int _regmap_raw_multi_reg_write(struct regmap *map,
   const struct reg_default *regs,
@@ -2050,7 +2050,7 @@ static int _regmap_raw_read(struct regmap *map, unsigned 
int reg, void *val,
 
/*
 * Some buses or devices flag reads by setting the high bits in the
-* register addresss; since it's always the high bits for all
+* register address; since it's always the high bits for all
 * current formats we can do this here rather than in
 * formatting.  This may break if we get interesting formats.
 */
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Applied "regulator: core: Print at debug level on debugfs creation failure" to the regmap tree

[Mark Brown]

The patch

   regulator: core: Print at debug level on debugfs creation failure

has been applied to the regmap tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From ad3a942bd22fd40a0f4ddaf2759946ce945662af Mon Sep 17 00:00:00 2001
From: Stephen Boyd 
Date: Mon, 1 Jun 2015 18:47:55 -0700
Subject: [PATCH] regulator: core: Print at debug level on debugfs creation
 failure

Failure to create a debugfs node is not an error, but we print a
warning upon failure to create the node. Downgrade this to a
debug printk so that we're quiet here. This allows multiple
drivers to request a CPU's regulator so that CPUfreq and AVSish
drivers can coexist.

The downside of this approach is that whoever gets to debugfs first
the others who come later to not have any debugfs attributes associated
with them.

Signed-off-by: Stephen Boyd 
Signed-off-by: Mark Brown 
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c9f7201..c203f3e 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1240,7 +1240,7 @@ static struct regulator *create_regulator(struct 
regulator_dev *rdev,
regulator->debugfs = debugfs_create_dir(regulator->supply_name,
rdev->debugfs);
if (!regulator->debugfs) {
-   rdev_warn(rdev, "Failed to create debugfs directory\n");
+   rdev_dbg(rdev, "Failed to create debugfs directory\n");
} else {
debugfs_create_u32("uA_load", 0444, regulator->debugfs,
   ®ulator->uA_load);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Applied "regmap: Fix regmap_can_raw_write check" to the regmap tree

[Mark Brown]

The patch

   regmap: Fix regmap_can_raw_write check

has been applied to the regmap tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 07ea400e1b26726f21b2c2299d187d6eb7eb4324 Mon Sep 17 00:00:00 2001
From: Markus Pargmann 
Date: Wed, 12 Aug 2015 12:12:33 +0200
Subject: [PATCH] regmap: Fix regmap_can_raw_write check

This function is missing a check if map->bus->write is implemented. If
it is not implemented arbitrary raw writes are not possible.

Signed-off-by: Markus Pargmann 
Signed-off-by: Mark Brown 
---
 drivers/base/regmap/regmap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 7111d04..8e7208d 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1382,7 +1382,8 @@ int _regmap_raw_write(struct regmap *map, unsigned int 
reg,
  */
 bool regmap_can_raw_write(struct regmap *map)
 {
-   return map->bus && map->format.format_val && map->format.format_reg;
+   return map->bus && map->bus->write && map->format.format_val &&
+   map->format.format_reg;
 }
 EXPORT_SYMBOL_GPL(regmap_can_raw_write);
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 5/6] slimbus: Add support for 'clock-pause' feature

[Mark Brown]

On Mon, Aug 03, 2015 at 12:59:49AM -0600, Sagar Dharia wrote:

> @@ -459,6 +459,8 @@ int slim_register_controller(struct slim_controller *ctrl)
>   mutex_init(&ctrl->m_ctrl);
>   spin_lock_init(&ctrl->tx.lock);
>   spin_lock_init(&ctrl->rx.lock);
> + mutex_init(&ctrl->sched.m_reconf);
> + init_completion(&ctrl->sched.pause_comp);

Should there not be more interaction with the rest of the framework on
clock pauses - the bus will need to be started to do transfers for
example?

> +#include 
> +/**

Missing blank line.

> + * slim_ctrl_clk_pause: Called by slimbus controller to enter/exit 'clock 
> pause'

Is the controller the best place to initiate bus pausing?  It's
surprising to me that it would be, the bus being idle isn't something
that needs controller specific knowledge so I'd expect the framework to
have standard support for this.


signature.asc
Description: Digital signature

Re: [PATCH 14/20] regmap: Add raw_write/read checks for max_raw_write/read sizes

[Mark Brown]

On Wed, Aug 12, 2015 at 02:47:06PM +0200, Markus Pargmann wrote:
> On Wed, Aug 12, 2015 at 12:57:59PM +0100, Mark Brown wrote:
> > On Wed, Aug 12, 2015 at 12:12:39PM +0200, Markus Pargmann wrote:

> > > Check in regmap_raw_read() and regmap_raw_write() for correct maximum
> > > sizes of the operations. Return -E2BIG if this size is not supported
> > > because it is too big.

> > Why not just split the transaction up like your other changes did?

> My intention was to keep these raw functions as close to the actual
> hardware as possible also reporting proper error values. For
> transactions that are split up you could still use the bulk functions.

That's not what we do otherwise, and not what you yourself have done for
some of the other changes in the series like those around multi write.


signature.asc
Description: Digital signature

Re: [PATCH 00/20] Regmap max_raw_io and bmc150 SPI support

[Mark Brown]

On Wed, Aug 12, 2015 at 12:47:39PM +0200, Markus Pargmann wrote:

> Ok. I can try to separate them but there are lots of dependencies
> between the patches and most of them touch regmap.c so I thought it may
> be better to put it in one series.

No, just the opposite - it means there's much less structure to the
series as it just becomes a sequence of unrelated changes without
overall aim or common theme.


signature.asc
Description: Digital signature

Re: [PATCH v3 5/5] regulator: Regulator driver for the Qualcomm RPM

[Mark Brown]

On Fri, Aug 14, 2015 at 11:58:35AM -0500, Andy Gross wrote:
> On Mon, Jul 27, 2015 at 08:20:33PM -0700, Bjorn Andersson wrote:
> > Driver for regulators exposed by the Resource Power Manager (RPM) found
> > in devices based on Qualcomm 8974 and newer platforms.

> > Reviewed-by: Mark Brown 
> > Signed-off-by: Bjorn Andersson 

> Mark/Liam, can you please pick this up.  The dependencies for this have been 
> merged
> in by the arm/soc maintainers.

> Acked-by: Andy Gross 

Please submit any patches you think should be included in the upstream
kernel using the process documented in SubmittingPatches.


signature.asc
Description: Digital signature

Re: [PATCH V3 3/6] slimbus: Add messaging APIs to slimbus framework

[Mark Brown]

On Fri, Aug 14, 2015 at 07:25:25PM +0100, Mark Brown wrote:
> On Mon, Aug 03, 2015 at 12:59:47AM -0600, Sagar Dharia wrote:

> > +   sema_init(&ctrl->tx_sem, (ctrl->tx.n - 1));

> This sempahore counts the number of free slots in the statically
> allocated list of transfers we have allocated.  It would be good to see
> some discussion in the changelog as to why we've got this statically
> allocated pool rather than just dynamically allocating them as needed -
> I can see a performance argument there but it'd be good to have the
> thinking documented.

One other related thing here: we're keeping the buffers permanently
coherently mapped rather than only mapping them to the device as needed.
Is this the best approach?  On the one hand it increases the cost to the
CPU when setting things up and reading data back, on the other hand it
avoids mapping operations.

Since it's becoming part of the driver API with this it bears some
thought, it will be a little annoying (and fiddly) to change later.


signature.asc
Description: Digital signature

Re: [PATCH V3 3/6] slimbus: Add messaging APIs to slimbus framework

[Mark Brown]

On Mon, Aug 03, 2015 at 12:59:47AM -0600, Sagar Dharia wrote:

> + sema_init(&ctrl->tx_sem, (ctrl->tx.n - 1));

This sempahore counts the number of free slots in the statically
allocated list of transfers we have allocated.  It would be good to see
some discussion in the changelog as to why we've got this statically
allocated pool rather than just dynamically allocating them as needed -
I can see a performance argument there but it'd be good to have the
thinking documented.

> + buf = slim_get_tx(ctrl, txn, need_tid, async);
> + if (!buf)
> + return -ENOMEM;
> +
> + if (need_tid) {
> + spin_lock_irqsave(&ctrl->txn_lock, flags);
> + for (i = 0; i < ctrl->last_tid; i++) {
> + if (ctrl->tid_tbl[i] == NULL)
> + break;
> + }
> + if (i >= ctrl->last_tid) {
> + if (ctrl->last_tid == (SLIM_MAX_TIDS - 1)) {
> + spin_unlock_irqrestore(&ctrl->txn_lock, flags);
> + return -ENOMEM;

We don't undo slim_get_tx() here but the definition looks like we ought
to be returning the buffer we allocated.


signature.asc
Description: Digital signature

Re: [PATCH 09/20] regmap: _regmap_raw_write fix for busses without write()

[Mark Brown]

On Wed, Aug 12, 2015 at 03:05:18PM +0200, Markus Pargmann wrote:
> On Wed, Aug 12, 2015 at 01:34:06PM +0100, Mark Brown wrote:

> > > Yes right. On the other hand if bus->read() and bus->write() was not set
> > > in the init method (before this patch series) no formatting functions at
> > > all were assigned. So it was always ignored for bus->reg_read() and
> > > bus->reg_write()?!

> > I'm not sure what the "it" you're talking about here is, sorry.  There
> > are unsupported features in the API especially for cases that don't make
> > a huge amount of sense, the error handling isn't always complete.  It
> > sounds like you might be trying to support one of these nonsensical
> > cases - it's not obvious what raw I/O on a device where we don't know
> > the raw format of the device should mean or how anything could sensibly
> > use that.

> The bus and the regmap user are separate. So as a regmap user, I am not
> able to know if the bus the device is connected to actually supports raw
> reads/writes. At least it should not fail with a null pointer when using

You should generally have a pretty good idea simply by knowing which
device you're working with - unless you're writing generic code you know
which device you're working with and what it's capabilities are.  A
driver that doesn't know these things should never be trying to do raw
I/O, and a driver that is doing raw I/O clearly depends on having the
ability to get a bytestream to and from the device since that's what raw
I/O does.


signature.asc
Description: Digital signature

Re: [PATCH 1/3] spi: bitbang: Replace spinlock by mutex when calling chipselect

[Mark Brown]

On Wed, Aug 05, 2015 at 06:24:05PM +0800, Nicolas Boichat wrote:

> Anyway, the "safer" way to fix this would be to keep the
> prepare/unprepare functions, busy variable, and just protect it with a
> mutex instead of a spinlock...

OK, that seems reasonable.


signature.asc
Description: Digital signature

Re: [PATCH V3 0/6] Introduce framework for SLIMbus device drivers

[Mark Brown]

On Mon, Aug 03, 2015 at 12:59:44AM -0600, Sagar Dharia wrote:

> Sagar Dharia (6):
>   SLIMbus: Device management on SLIMbus
>   of/slimbus: OF helper for SLIMbus
>   slimbus: Add messaging APIs to slimbus framework
>   slim: qcom: Add Qualcomm Slimbus controller driver
>   slimbus: Add support for 'clock-pause' feature
>   slim: qcom: Add runtime-pm support using clock-pause feature

This looks pretty good overall but I did have a few fairly specific
comments that I've sent on some bits.  I see there are a number of users
of this API onn the CC list, it'd be really nice to see some more
participation from them on the review here - are you using this code, do
you have testing reports or any more specific comments on the code?


signature.asc
Description: Digital signature

Re: [PATCH V3 6/6] slim: qcom: Add runtime-pm support using clock-pause feature

[Mark Brown]

On Mon, Aug 03, 2015 at 12:59:50AM -0600, Sagar Dharia wrote:

> + if (cur_clk_state == SLIM_CLK_ENTERING_PAUSE) {
> + if (txn->mc != SLIM_MSG_MC_BEGIN_RECONFIGURATION &&
> + txn->mc != SLIM_MSG_MC_RECONFIGURE_NOW &&
> + txn->mc != SLIM_MSG_MC_NEXT_PAUSE_CLOCK)
> + return -EBUSY;
> + } else {
> + int ret = pm_runtime_get_sync(dev->dev);
> +
> + if (ret < 0) {

This is taking a runtime PM reference whenever we're about to start a
transfer - this is the sort of thing I was talking about expecting the
framework to do rather than individual drivers.

> + pm_runtime_set_suspended(dev->dev);
> + dev_err(dev->dev, "runtime-pm vote failed:%d\n", ret);
> + return ret;

If the get failed there should be no need to suspend the device, the
get() should leave us in a sensible state...

> +static int msm_slim_suspend(struct device *dev)
> +{
> + int ret = 0;
> +
> + if (!pm_runtime_enabled(dev) ||
> + (!pm_runtime_suspended(dev))) {
> + dev_dbg(dev, "system suspend");
> + ret = msm_slim_runtime_suspend(dev);
> + }
> + if (ret == -EISCONN) {
> + /**
> + * If the clock pause failed due to active channels, there is
> + * a possibility that some audio stream is active during suspend
> + * We dont want to return suspend failure in that case so that
> + * display and relevant components can still go to suspend.
> + * If there is some other error, then it should prevent
> + * system level suspend
> + */

Best mention that this is for the modem use case for Android's suspend
model since it's really surprising to see.


signature.asc
Description: Digital signature

Re: [PATCH V3 1/6] SLIMbus: Device management on SLIMbus

[Mark Brown]

On Mon, Aug 03, 2015 at 12:59:45AM -0600, Sagar Dharia wrote:

> + INIT_WORK(&sbw->wd, slim_report);
> + sbw->sb = sb;
> + sbw->report = report;
> + if (!queue_work(ctrl->wq, &sbw->wd))
> + kfree(sbw);

Should we not complain if we fail to schedule the work?

> +#define slim_device_attr_gr NULL
> +#define slim_device_uevent NULL
> +
> +static struct device_type slim_dev_type = {
> + .groups = slim_device_attr_gr,
> + .uevent = slim_device_uevent,

Why these NULL defines?  Just add the struct members as definitions are
added.

> + dev_set_name(&sbdev->dev, "%s", sbdev->name);
> + mutex_lock(&ctrl->m_ctrl);
> + list_add_tail(&sbdev->dev_list, &ctrl->devs);
> + mutex_unlock(&ctrl->m_ctrl);

Doesn't the driver model list of children of the controller give you
a list of devices connected to the controller?

> + /* Can't register until after driver model init */
> + if (WARN_ON(!slimbus_type.p)) {
> + ret = -EAGAIN;
> + goto out_list;
> + }

Shouldn't the core code handle this for us?


signature.asc
Description: Digital signature

Re: [PATCH 11/20] regmap: _regmap_raw_read: Add handling of busses without bus->read()

[Mark Brown]

On Wed, Aug 12, 2015 at 02:34:12PM +0200, Markus Pargmann wrote:

> Is -EINVAL the right thing to return or would you prefer -ENOTSUPP?

-ENOTSUPP is going to be better.


signature.asc
Description: Digital signature

Re: [PATCH V3 4/6] slim: qcom: Add Qualcomm Slimbus controller driver

[Mark Brown]

On Mon, Aug 03, 2015 at 12:59:48AM -0600, Sagar Dharia wrote:

> +/**
> + * Qualcomm slimbus controller may experience interference on the lines
> + * causing some early messages (e.g. logical-address assignment) to be
> + * NACKed. Retry after sometime (typically 1 superframe)
> + */
> +static void msm_slim_wait_retry(struct msm_slim_ctrl *dev)
> +{
> + int msec_per_frm = 0;
> + int sfr_per_sec;
> +
> + /* Wait for 1 superframe, or default time and then retry */
> + sfr_per_sec = dev->framer.superfreq /
> + (1 << (SLIM_MAX_CLK_GEAR - dev->ctrl.clkgear));
> + if (sfr_per_sec)
> + msec_per_frm = MSEC_PER_SEC / sfr_per_sec;
> + if (msec_per_frm < DEF_RETRY_MS)
> + msec_per_frm = DEF_RETRY_MS;
> + msleep(msec_per_frm);
> +}

This looks like logic which might be usefully pulled out to the
framework - I bet this isn't an issue unique to your controller, the
users (well, one user) look like cases where the bus might be
destabilised by devices powering up and trying to enumerate under less
than ideal electrical conditions which seems like something that's
likely to affect other hardware.

> + rclk = devm_clk_get(&pdev->dev, "core_clk");
> + if (IS_ERR(rclk)) {
> + /* unlikely that this is probe-defer */
> + dev_err(&pdev->dev, "rclk get failed:%ld\n", PTR_ERR(rclk));
> + devm_clk_put(&pdev->dev, hclk);

No need to call devm_clk_put() explicitly in your probe function.


signature.asc
Description: Digital signature

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

[Mark Brown]

On Mon, Jul 27, 2015 at 04:54:09PM +0530, Kishon Vijay Abraham I wrote:

> vsel_reg and enable_reg of the pbias regulator descriptor should actually
> have the offset from syscon. However after the pbias device tree node

I'm having a hard time understanding this statement, sorry.  What makes
you say that they "shouild actually have the offset from syscon"?  What
is the problem that this is supposed to fix?

> is moved as a child node of syscon, vsel_reg and enable_reg has the
> absolute address because of the address translation that happens while
> creating device from device tree node.
> So avoid using platform_get_resource and use of_get_address in order to
> get only the offset (untranslated address) and populate these in
> vsel_reg and enable_reg.

This sounds like we're going in the wrong direction, we're moving from a
more generic API to a firmware specific one.  Why is this a good fix?


signature.asc
Description: Digital signature

Re: [PATCH] regulator: core: Define regulator_set_voltage_triplet()

[Mark Brown]

On Fri, Aug 14, 2015 at 05:30:55PM +0530, Viresh Kumar wrote:

> The OPP (Operating performance points) v2 bindings allows regulator
> voltage to be supplied as a triplet of  voltages.

Looking at this I really don't understand why you tried to get me to
review this via an IRC pastebin instead of following the normal patch
submission process.  Please don't do that, it's not at all helpful.  IRC
can be useful for interactive discussions or things that are really
urgent, not for normal upstream code review.

> +static inline int regulator_set_voltage_triplet(struct regulator *regulator,
> + int target_uV, int min_uV,
> + int max_uV)

This seems awkward, these things are normally written as min <= target
<= max but this is target, min, max.

>  static inline int regulator_set_voltage_tol(struct regulator *regulator,
>   int new_uV, int tol_uV)
>  {
> -- 
> 2.4.0

You've not added a stub for the new function.


signature.asc
Description: Digital signature

Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory"

[Dan Williams]

On Fri, Aug 14, 2015 at 3:33 PM, Dan Williams  wrote:
> On Fri, Aug 14, 2015 at 3:06 PM, Jerome Glisse  wrote:
>> On Fri, Aug 14, 2015 at 02:52:15PM -0700, Dan Williams wrote:
>>> On Fri, Aug 14, 2015 at 2:37 PM, Jerome Glisse  wrote:
>>> > On Wed, Aug 12, 2015 at 11:50:05PM -0400, Dan Williams wrote:
> [..]
>>> > What is the rational for not updating max_pfn, max_low_pfn, ... ?
>>> >
>>>
>>> The idea is that this memory is not meant to be available to the page
>>> allocator and should not count as new memory capacity.  We're only
>>> hotplugging it to get struct page coverage.
>>
>> But this sounds bogus to me to rely on max_pfn to stay smaller than
>> first_dev_pfn.  For instance you might plug a device that register
>> dev memory and then some regular memory might be hotplug, effectively
>> updating max_pfn to a value bigger than first_dev_pfn.
>>
>
> True.
>
>> Also i do not think that the buddy allocator use max_pfn or max_low_pfn
>> to consider page/zone for allocation or not.
>
> Yes, I took it out with no effects.  I'll investigate further whether
> we should be touching those variables or not for this new usage.

Although it does not offer perfect protection if device memory is at a
physically lower address than RAM, skipping the update of these
variables does seem to be what we want.  For example /dev/mem would
fail to allow write access to persistent memory if it fails a
valid_phys_addr_range() check.  Since /dev/mem does not know how to
write to PMEM in a reliably persistent way, it should not treat a
PMEM-pfn like RAM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regmap: Add function check before called format_val

[Mark Brown]

On Thu, Aug 13, 2015 at 11:25:05PM +0800, Henry Chen wrote:
> On Wed, 2015-08-12 at 22:20 +0800, Daniel Kurtz wrote:

> > Making mtk_pmic-wrap into a regmap_bus makes a bit of sense
> > architecturally, too, since it is essentially just a bus for accessing
> > the registers of an off-chip PMIC.  The CPU sees a platform bus, but
> > the registers of the remote PMIC are accessed over a dedicated SPI
> > bus.

> Sorry, I'm afraid that I cannot do this right on init as you said last
> time. What do you think about regmap_bus, can you accept that way?

I don't have enough context from the above to understand what's going
on, sorry.  Implementing a bus for something that isn't actually a Linux
bus doesn't seem like the best idea though and in general what I'm
seeing of the discussion sounds like you're hacking around in driver
code to bodge around problems that are being seen rather than really
addressing things, the code I can see certainly looks like it just wants
to be implementing read and write operations for a single MFD.


signature.asc
Description: Digital signature

Re: [PATCH] Staging: vt6655: rf: fix C99 // comments coding style error

[Greg Kroah-Hartman]

On Fri, Aug 14, 2015 at 02:46:57PM -0400, Raphaël Beamonte wrote:
> Replace C99 // comments by /* comments */ to follow the kernel
> coding style.
> 
> Signed-off-by: Raphaël Beamonte 
> ---
>  drivers/staging/vt6655/rf.c | 535 
> ++--
>  1 file changed, 269 insertions(+), 266 deletions(-)

This doesn't apply to my staging-next branch of staging-git :(

Please rebase and resend.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] staging: wilc1000: Process WARN, INFO options of debug levels from user

[Greg KH]

On Fri, Aug 14, 2015 at 10:50:07PM +0530, Chandra S Gorentla wrote:
> This patch enables setting the module's debug options WARN and INFO in the
> debugfs file 'wilc_debug_level'.  This enables the user to enable logging
> of warning and other information.  Before this change writes to this
> debugfs file sets only one option DGB.  This is additional to the default
> option ERR. 
> 
> As a side effect, this patch removes the 'sparse' warning -
> 'warning: incorrect type in argument 2 (different address spaces)'.
> 
> Signed-off-by: Chandra S Gorentla 
> ---
>  drivers/staging/wilc1000/wilc_debugfs.c | 28 +---
>  1 file changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_debugfs.c 
> b/drivers/staging/wilc1000/wilc_debugfs.c
> index be2e901..23419d9 100644
> --- a/drivers/staging/wilc1000/wilc_debugfs.c
> +++ b/drivers/staging/wilc1000/wilc_debugfs.c
> @@ -48,29 +48,18 @@ static ssize_t wilc_debug_level_read(struct file *file, 
> char __user *userbuf, si
>   return simple_read_from_buffer(userbuf, count, ppos, buf, res);
>  }
>  
> -static ssize_t wilc_debug_level_write(struct file *filp, const char *buf, 
> size_t count, loff_t *ppos)
> +static ssize_t wilc_debug_level_write(struct file *filp, const char __user 
> *buf,
> + size_t count, loff_t *ppos)
>  {
> - char buffer[128] = {};
>   int flag = 0;
> + int ret;
>  
> - if (count > sizeof(buffer))
> - return -EINVAL;
> -
> - if (copy_from_user(buffer, buf, count)) {
> - return -EFAULT;
> - }
> -
> - flag = buffer[0] - '0';
> -
> - if (flag > 0)
> - flag = DEBUG | ERR;
> - else if (flag < 0)
> - flag = 100;
> + ret = kstrtouint_from_user(buf, count, 16, &flag);
> + if (ret)
> + return ret;
>  
> - if (flag > DBG_LEVEL_ALL) {
> - printk("%s, value (0x%08x) is out of range, stay previous flag 
> (0x%08x)\n", __func__, flag, atomic_read(&DEBUG_LEVEL));

Why did you remove this warning value?


> - return -EFAULT;

I agree, this should be changed to -EINVAL like you did, but please put
back the printk for now.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] RDMA/cma: fix IPv6 address resolution

[Doug Ledford]

On 08/13/2015 03:21 PM, Roland Dreier wrote:
> Reviewed-by: Roland Dreier  >
> 
> On Aug 13, 2015 12:19 PM, "Spencer Baugh"  > wrote:
>>
>> Resolving a link-local IPv6 address with an unspecified source address
>> was broken by commit 5462eddd7a, which prevented the IPv6 stack from
>> learning the scope id of the link-local IPv6 address, causing random
>> failures as the IP stack chose a random link to resolve the address on.
>>
>> This commit 5462eddd7a made us bail out of cma_check_linklocal early if
>> the address passed in was not an IPv6 link-local address. On the address
>> resolution path, the address passed in is the source address; if the
>> source address is the unspecified address, which is not link-local, we
>> will bail out early.
>>
>> This is mostly correct, but if the destination address is a link-local
>> address, then we will be following a link-local route, and we'll need to
>> tell the IPv6 stack what the scope id of the destination address is.
>> This used to be done by last line of cma_check_linklocal, which is
>> skipped when bailing out early:
>>
>> dev_addr->bound_dev_if = sin6->sin6_scope_id;
>>
>> (In cma_bind_addr, the sin6_scope_id of the source address is set to the
>> sin6_scope_id of the destination address, so this is correct)
>> This line is required in turn for the following line, L279 of
>> addr6_resolve, to actually inform the IPv6 stack of the scope id:
>>
>>   fl6.flowi6_oif = addr->bound_dev_if;
>>
>> Since we can only know we are in this failure case when we have access
>> to both the source IPv6 address and destination IPv6 address, we have to
>> deal with this further up the stack. So detect this failure case in
>> cma_bind_addr, and set bound_dev_if to the destination address scope id
>> to correct it.
>>
>> Signed-off-by: Spencer Baugh  >
>> ---
>>  drivers/infiniband/core/cma.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)

I've picked this up, thanks.


-- 
Doug Ledford 
  GPG KeyID: 0E572FDD




signature.asc
Description: OpenPGP digital signature

RE: [PATCH v4 0/7] Add spi-nor SPI transfer error handling

[beanhuo]

>Hello,

>with these patches SPI transfer errors are not silently ignored but rather 
>reported to spi-nor users.

>This should prevent silently dropping data to the floor in cases when the SPI 
>transfer fails and the failure is detected.

>It has been pointed out that MTD users do not handle the case when data is 
>read only partially so this version adds the last patch which handles this in 
>spi-nor.

>Thanks

>Michal
 Seems parallel nand read/write also has the same condition.

[PATCH] ASoC: rockchip: i2s: Adjust devm usage

[Vaishali Thakkar]

Remove use of snd_soc_unregister_component in remove function
as devm_snd_soc_register_component in probe function automatically
handles it.

Also, convert call of snd_dmaengine_pcm_register to managed resource
function devm_snd_dmaengine_pcm_register and remove usage of
snd_dmaengine_pcm_unregister in probe and remove functions.

Signed-off-by: Vaishali Thakkar 
---
 sound/soc/rockchip/rockchip_i2s.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index acb5be5..b936102 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -483,16 +483,14 @@ static int rockchip_i2s_probe(struct platform_device 
*pdev)
goto err_suspend;
}
 
-   ret = snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
+   ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
if (ret) {
dev_err(&pdev->dev, "Could not register PCM\n");
-   goto err_pcm_register;
+   return ret;
}
 
return 0;
 
-err_pcm_register:
-   snd_dmaengine_pcm_unregister(&pdev->dev);
 err_suspend:
if (!pm_runtime_status_suspended(&pdev->dev))
i2s_runtime_suspend(&pdev->dev);
@@ -512,8 +510,6 @@ static int rockchip_i2s_remove(struct platform_device *pdev)
 
clk_disable_unprepare(i2s->mclk);
clk_disable_unprepare(i2s->hclk);
-   snd_dmaengine_pcm_unregister(&pdev->dev);
-   snd_soc_unregister_component(&pdev->dev);
 
return 0;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: lustre: ptlrpc: add missing include directive

[Greg KH]

On Fri, Aug 14, 2015 at 12:57:06PM +0300, Ioan-Adrian Ratiu wrote:
> Without including ptlrpc_internal.h, GCC gives prototype warnings
> "pack_generic.c:642:5: warning: no previous prototype for ..."

It does?  What version of gcc give you that, I don't see that here.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] staging: lustre: fix static declarations in libcfs

[Greg Kroah-Hartman]

On Fri, Aug 14, 2015 at 04:00:31PM +0200, Maxime Lorrillere wrote:
> On vendredi 14 août 2015 à 11:28:35 (+0530), Sudip Mukherjee wrote
> > On Wed, Aug 12, 2015 at 11:51:04AM +0200, Maxime Lorrillere wrote:
> > > This patch fix the following sparse warnings in 
> > > libcfs/linux/linux-debug.c:
> > > >>> linux-debug.c:64:6: warning: symbol 'lnet_upcall' was not declared. 
> > > >>> Should it be static?
> > > >>> linux-debug.c:65:6: warning: symbol 'lnet_debug_log_upcall' was not 
> > > >>> declared. Should it be static?
> > > 
> > > Signed-off-by: Maxime Lorrillere 
> > > ---
> > You have not build tested.
> > 
> > WARNING: "lnet_debug_log_upcall" 
> > [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined!
> > WARNING: "lnet_upcall" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] 
> > undefined!
> 
> Sorry, I've only rebuild lustre separately.
> 
> Patch 2/2 builds fine, should I submit it separately ?

Yes please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH net] igb: Fix oops caused by missing queue pairing

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Shota Suzuki
> Sent: Tuesday, June 30, 2015 5:26 PM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
> Carolyn; Skidmore, Donald C; Vick, Matthew; Ronciak, John; Williams, Mitch
> A; intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Shota Suzuki
> Subject: [PATCH net] igb: Fix oops caused by missing queue pairing
> 
> When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
> set if adapter->rss_queues exceeds half of max_rss_queues in
> igb_init_queue_configuration().
> On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
> queues exceeds half of max_combined in igb_set_channels() when changing
> the number of queues by "ethtool -L".
> In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
> of adapter->msix_entries[], an overflow can occur in
> igb_set_interrupt_capability(), which in turn leads to an oops.
> 
> Fix this problem as follows:
>  - When changing the number of queues by "ethtool -L", set
>IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
>  - When increasing the size of q_vector, reallocate it appropriately.
>(With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)
> 
> Another possible way to fix this problem is to cap the queues at its
> initial number, which is the number of the initial online cpus. But this
> is not the optimal way because we cannnot increase queues when another
> cpu becomes online.
> 
> Note that before commit cd14ef54d25b ("igb: Change to use statically
> allocated array for MSIx entries"), this problem did not cause oops
> but just made the number of queues become 1 because of entering msi_only
> mode in igb_set_interrupt_capability().
> 
> Fixes: 907b7835799f ("igb: Add ethtool support to configure number of
> channels")
> Signed-off-by: Shota Suzuki 
> ---
> Although we might be able to additionally unset IGB_FLAG_QUEUE_PAIRS
> when it is not needed, this patch doesn't change existing behaviour
> because such a change is not a bug fix.
> 
>  drivers/net/ethernet/intel/igb/igb.h |  1 +
>  drivers/net/ethernet/intel/igb/igb_ethtool.c |  5 -
>  drivers/net/ethernet/intel/igb/igb_main.c| 16 ++--
>  3 files changed, 19 insertions(+), 3 deletions(-)

Tested-by: Aaron Brown 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 6/8] serial: imx: add runtime pm support

[Eduardo Valentin]

On Fri, Aug 14, 2015 at 05:23:12PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Aug 11, 2015 at 10:21:25AM -0700, Eduardo Valentin wrote:
> > This change introduces the runtime pm support on imx serial
> > driver. The objective is to be able to idle the uart
> > port whenever it is not in use while still being able
> > to wake it up when needed. The key changes in this patch are:
> > 1. Move the clock handling to runtime pm. Both, ipg and per,
> > are now handled in the suspend and resume callbacks. Only
> > enabling and disabling the clocks are handled in runtime
> > suspend and resume, so we are able to use runtime pm
> > in IRQ context.
> > 2. Clocks are prepared in probe and unprepared in remove,
> > so we do not need to prepare (may sleep) in runtime pm.
> > 3. We mark the device activity based on uart and console
> > callbacks. Whenever the device is needed and we want to
> > access registers, we runtime_pm_get and then mark its
> > last usage when we are done. This is done also across
> > IRQs and DMA callbacks.
> > 4. We reuse the infrastructure in place for suspend and
> > resume, so we do not need to redo wakeup configuration,
> > or context save and restore.
> > 
> > After this change, the clocks are still sane, in the sense
> > of having balanced clock prepare and enable.
> > 
> > Cc: Fabio Estevam 
> > Cc: Greg Kroah-Hartman 
> > Cc: Jiri Slaby 
> > Cc: linux-ser...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Eduardo Valentin 
> > ---
> >  drivers/tty/serial/imx.c | 224 
> > +--
> >  1 file changed, 178 insertions(+), 46 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> > index 50abb60..9447a55 100644
> > --- a/drivers/tty/serial/imx.c
> > +++ b/drivers/tty/serial/imx.c
> > @@ -39,6 +39,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -219,6 +222,7 @@ struct imx_port {
> > unsigned intsaved_reg[10];
> > boolcontext_saved;
> >  
> > +   struct device   *dev;
> 
> Do you really need this pointer?  Can't you get it from the platform
> device that you have access to that sport is the data?

Actually, not really. I can change the code to the one in sport. I will
be resending soon.

> 
> thanks,
> 
> greg k-h


signature.asc
Description: Digital signature

Re: [PATCH 1/2] Revert "block: remove artifical max_hw_sectors cap"

[Ed Cashin]

ACK.

On 08/13/2015 02:57 PM, Jeff Moyer wrote:

This reverts commit 34b48db66e08ca1c1bc07cf305d672ac940268dc.
That commit caused performance regressions for streaming I/O
workloads on a number of different storage devices, from
SATA disks to external RAID arrays.  It also managed to
trip up some buggy firmware in at least one drive, causing
data corruption.

The next patch will bump the default max_sectors_kb value to
1280, which will accommodate a 10-data-disk stripe write
with chunk size 128k.  In the testing I've done using iozone,
fio, and aio-stress, a value of 1280 does not show a big
performance difference from 512.  This will hopefully still
help the software RAID setup that Christoph saw the original
performance gains with while still not regressing other
storage configurations.

Signed-off-by: Jeff Moyer 
---
  block/blk-settings.c   | 4 +++-
  drivers/block/aoe/aoeblk.c | 2 +-
  include/linux/blkdev.h | 1 +
  3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/block/blk-settings.c b/block/blk-settings.c
index 12600bf..b160f89 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -257,7 +257,9 @@ void blk_limits_max_hw_sectors(struct queue_limits *limits, 
unsigned int max_hw_
   __func__, max_hw_sectors);
}
  
-	limits->max_sectors = limits->max_hw_sectors = max_hw_sectors;

+   limits->max_hw_sectors = max_hw_sectors;
+   limits->max_sectors = min_t(unsigned int, max_hw_sectors,
+   BLK_DEF_MAX_SECTORS);
  }
  EXPORT_SYMBOL(blk_limits_max_hw_sectors);
  
diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c

index 46c282f..dd73e1f 100644
--- a/drivers/block/aoe/aoeblk.c
+++ b/drivers/block/aoe/aoeblk.c
@@ -395,7 +395,7 @@ aoeblk_gdalloc(void *vp)
WARN_ON(d->flags & DEVFL_TKILL);
WARN_ON(d->gd);
WARN_ON(d->flags & DEVFL_UP);
-   blk_queue_max_hw_sectors(q, 1024);
+   blk_queue_max_hw_sectors(q, BLK_DEF_MAX_SECTORS);
q->backing_dev_info.name = "aoe";
q->backing_dev_info.ra_pages = READ_AHEAD / PAGE_CACHE_SIZE;
d->bufpool = mp;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d4068c1..1fd459e1 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1138,6 +1138,7 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t 
has_write_perm);
  enum blk_default_limits {
BLK_MAX_SEGMENTS= 128,
BLK_SAFE_MAX_SECTORS= 255,
+   BLK_DEF_MAX_SECTORS = 1024,
BLK_MAX_SEGMENT_SIZE= 65536,
BLK_SEG_BOUNDARY_MASK   = 0xUL,
  };


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] blk-mq: two fixes

[Ming Lei]

On Sun, Aug 9, 2015 at 3:41 PM, Ming Lei  wrote:
> Hi Jens,
>
> The 1st patch fixes one buffer overflow issue when reading
> sysfs file of hctx's pending.
>
> The 2nd patch fixes one race between timeout and request freeing,
> which also simplifies implementation of blk_mq_tag_to_rq() a lot.

Ping...


>  block/blk-flush.c| 15 ++-
>  block/blk-mq-sysfs.c | 25 ++---
>  block/blk-mq-tag.c   |  4 ++--
>  block/blk-mq-tag.h   | 12 
>  block/blk-mq.c   | 16 +---
>  block/blk.h  |  6 ++
>  6 files changed, 53 insertions(+), 25 deletions(-)
>
>
> thanks,
> Ming
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] thermal: cpu_cooling: fix lockdep problems in cpu_cooling

[Eduardo Valentin]

On Fri, Aug 14, 2015 at 11:25:56AM +0530, Viresh Kumar wrote:
> On 12-08-15, 15:22, Viresh Kumar wrote:
> > From: Russell King 
> > Fixes: 2dcd851fe4b4 ("thermal: cpu_cooling: Update always cpufreq policy 
> > with
> > Reviewed-by: Viresh Kumar 
> > Signed-off-by: Russell King 
> > Signed-off-by: Viresh Kumar 
> > ---
> > 
> > Hi Eduardo/Zhang,
> > 
> > This is 4.2-rc material, please apply soon.
> 
> Hey,
> 
> Please apply this one and drop
> 
> 8ad61f934e9e ("thermal: cpu_cooling: fix lockdep problems in
> cpu_cooling")

OK, I am having a looking at this.

> 
> -- 
> viresh


signature.asc
Description: Digital signature

Re: Switch nvdimm.git to the shared repository

[Stephen Rothwell]

Hi Dan,

On Fri, 14 Aug 2015 10:00:48 -0700 Dan Williams  
wrote:
>
> When you get a chance please switch the nvdimm.git repository in -next
> to our newly established shared repo.  I.e. switch from:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git 
> libnvdimm-for-next
> 
> ...to...:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-for-next

Done.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 00/84] 4.1.6-stable review

[Greg Kroah-Hartman]

On Fri, Aug 14, 2015 at 06:10:49PM -0600, Shuah Khan wrote:
> On 08/14/2015 11:41 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.1.6 release.
> > There are 84 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Aug 16 17:41:54 UTC 2015.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.1.6-rc1.gz
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] ARM: qcom: add SMEM device node to IPQ806x dts

[Mathieu Olivari]

SMEM is used on IPQ806x to store various board related information such
as boot device and flash partition layout. We'll declare it as a device
so we can make use of it thanks to the new SMEM soc driver.

Signed-off-by: Mathieu Olivari 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 8d366ae..85dbccf 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -55,7 +55,7 @@
no-map;
};
 
-   smem@4100 {
+   smem: smem@4100 {
reg = <0x4100 0x20>;
no-map;
};
@@ -341,4 +341,10 @@
 
#hwlock-cells = <1>;
};
+
+   smem {
+   compatible = "qcom,smem";
+   memory-region = <&smem>;
+   hwlocks = <&sfpb_mutex 3>;
+   };
 };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] mtd: add SMEM parser for QCOM platforms

[Mathieu Olivari]

On QCOM platforms using MTD devices storage (such as IPQ806x), SMEM is
used to store partition layout. This new parser can now be used to read
SMEM and use it to register an MTD layout according to its content.

Signed-off-by: Mathieu Olivari 
---
 drivers/mtd/Kconfig  |   7 ++
 drivers/mtd/Makefile |   1 +
 drivers/mtd/qcom_smem_part.c | 231 +++
 3 files changed, 239 insertions(+)
 create mode 100644 drivers/mtd/qcom_smem_part.c

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index a03ad29..debc887 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -155,6 +155,13 @@ config MTD_BCM47XX_PARTS
  This provides partitions parser for devices based on BCM47xx
  boards.
 
+config MTD_QCOM_SMEM_PARTS
+   tristate "QCOM SMEM partitioning support"
+   depends on QCOM_SMEM
+   help
+ This provides partitions parser for QCOM devices using SMEM
+ such as IPQ806x.
+
 comment "User Modules And Translation Layers"
 
 #
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 99bb9a1..b3c7de4 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MTD_AFS_PARTS)   += afs.o
 obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
 obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
 obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
+obj-$(CONFIG_MTD_QCOM_SMEM_PARTS) += qcom_smem_part.o
 
 # 'Users' - code which presents functionality to userspace.
 obj-$(CONFIG_MTD_BLKDEVS)  += mtd_blkdevs.o
diff --git a/drivers/mtd/qcom_smem_part.c b/drivers/mtd/qcom_smem_part.c
new file mode 100644
index 000..20fef5c
--- /dev/null
+++ b/drivers/mtd/qcom_smem_part.c
@@ -0,0 +1,231 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Processor/host identifier for the application processor */
+#define SMEM_HOST_APPS 0
+
+/* SMEM items index */
+#define SMEM_AARM_PARTITION_TABLE  9
+#define SMEM_BOOT_FLASH_TYPE   421
+#define SMEM_BOOT_FLASH_BLOCK_SIZE 424
+
+/* SMEM Flash types */
+#define SMEM_FLASH_NAND2
+#define SMEM_FLASH_SPI 6
+
+#define SMEM_PART_NAME_SZ  16
+#define SMEM_PARTS_MAX 32
+
+struct smem_partition {
+   char name[SMEM_PART_NAME_SZ];
+   __le32 start;
+   __le32 size;
+   __le32 attr;
+};
+
+struct smem_partition_table {
+   u8 magic[8];
+   __le32 version;
+   __le32 len;
+   struct smem_partition parts[SMEM_PARTS_MAX];
+};
+
+/* SMEM Magic values in partition table */
+static const u8 SMEM_PTABLE_MAGIC[] = {
+   0xaa, 0x73, 0xee, 0x55,
+   0xdb, 0xbd, 0x5e, 0xe3,
+};
+
+static int qcom_smem_get_flash_blksz(u64 **smem_blksz)
+{
+   int ret;
+   size_t size;
+
+   ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_BLOCK_SIZE,
+   (void **) smem_blksz, &size);
+
+   if (ret < 0) {
+   pr_err("Unable to read flash blksz from SMEM\n");
+   return -ENOENT;
+   }
+
+   if (size != sizeof(**smem_blksz)) {
+   pr_err("Invalid flash blksz size in SMEM\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int qcom_smem_get_flash_type(u64 **smem_flash_type)
+{
+   int ret;
+   size_t size;
+
+   ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_TYPE,
+   (void **) smem_flash_type, &size);
+
+   if (ret < 0) {
+   pr_err("Unable to read flash type from SMEM\n");
+   return -ENOENT;
+   }
+
+   if (size != sizeof(**smem_flash_type)) {
+   pr_err("Invalid flash type size in SMEM\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int qcom_smem_get_flash_partitions(struct smem_partition_table **pparts)
+{
+   int ret;
+   size_t size;
+
+   ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_AARM_PARTITION_TABLE,
+   (void **) pparts, &size);
+
+   if (ret < 0) {
+   pr_err("Unable to read partition table from SMEM\n");
+   return -ENOENT;
+   }
+
+   return 0;
+}
+
+static int of_dev_node_match(struct device *dev, void *data)
+{
+   return dev->of_node == data;
+}
+
+static bool is_spi_device(struct device_node *np)
+{
+   struct device *dev;
+
+   dev = bus_find

[PATCH 1/3] ARM: qcom: add SFPB nodes to IPQ806x dts

[Mathieu Olivari]

Add one new node to the ipq806x.dtsi file to declare & register the
hardware spinlock devices. This mechanism is required to be used by
other drivers such as SMEM.

Signed-off-by: Mathieu Olivari 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 9f727d8..8d366ae 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -329,5 +329,16 @@
#reset-cells = <1>;
};
 
+   sfpb_mutex_block: syscon@1200600 {
+   compatible = "syscon";
+   reg = <0x01200600 0x100>;
+   };
+   };
+
+   sfpb_mutex: sfpb-mutex {
+   compatible = "qcom,sfpb-mutex";
+   syscon = <&sfpb_mutex_block 4 4>;
+
+   #hwlock-cells = <1>;
};
 };
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] qcom: Add SMEM MTD parser

[Mathieu Olivari]

QCOM platforms such as IPQ806x are using SMEM to store their flash
layout. This patch set adds the DT nodes required to instanciate SMEM
on IPQ806x and add an MTD parser using it.

This change is based on the SMEM driver posted here:
*https://lkml.org/lkml/2015/7/27/1125

v2:
*Release the SPI device reference after looking it up (put_device())
*Represent SMEM data as __le32 rather than u32
*Move new DT nodes in their proper respective location
*Address readability concerns in MTD parser

Mathieu Olivari (3):
  ARM: qcom: add SFPB nodes to IPQ806x dts
  ARM: qcom: add SMEM device node to IPQ806x dts
  mtd: add SMEM parser for QCOM platforms

 arch/arm/boot/dts/qcom-ipq8064.dtsi |  23 +++-
 drivers/mtd/Kconfig |   7 ++
 drivers/mtd/Makefile|   1 +
 drivers/mtd/qcom_smem_part.c| 224 
 4 files changed, 254 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/qcom_smem_part.c

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 6/8] serial: imx: add runtime pm support

[Greg Kroah-Hartman]

On Tue, Aug 11, 2015 at 10:21:25AM -0700, Eduardo Valentin wrote:
> This change introduces the runtime pm support on imx serial
> driver. The objective is to be able to idle the uart
> port whenever it is not in use while still being able
> to wake it up when needed. The key changes in this patch are:
> 1. Move the clock handling to runtime pm. Both, ipg and per,
> are now handled in the suspend and resume callbacks. Only
> enabling and disabling the clocks are handled in runtime
> suspend and resume, so we are able to use runtime pm
> in IRQ context.
> 2. Clocks are prepared in probe and unprepared in remove,
> so we do not need to prepare (may sleep) in runtime pm.
> 3. We mark the device activity based on uart and console
> callbacks. Whenever the device is needed and we want to
> access registers, we runtime_pm_get and then mark its
> last usage when we are done. This is done also across
> IRQs and DMA callbacks.
> 4. We reuse the infrastructure in place for suspend and
> resume, so we do not need to redo wakeup configuration,
> or context save and restore.
> 
> After this change, the clocks are still sane, in the sense
> of having balanced clock prepare and enable.
> 
> Cc: Fabio Estevam 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/tty/serial/imx.c | 224 
> +--
>  1 file changed, 178 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 50abb60..9447a55 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -39,6 +39,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -219,6 +222,7 @@ struct imx_port {
>   unsigned intsaved_reg[10];
>   boolcontext_saved;
>  
> + struct device   *dev;

Do you really need this pointer?  Can't you get it from the platform
device that you have access to that sport is the data?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] KVM patches for 4.2-rc7

[Paolo Bonzini]

Linus,

The following changes since commit fc1a8126bf8095b10f5a79893f2d2b19227f88f2:

  KVM: MTRR: Use default type for non-MTRR-covered gfn before WARN_ON 
(2015-08-05 11:57:57 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to d7add05458084a5e3d65925764a02ca9c8202c1e:

  KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST 
(2015-08-07 13:28:03 +0200)


Just two very small & simple patches.


Haozhong Zhang (1):
  KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST

Paolo Bonzini (1):
  KVM: x86: zero IDT limit on entry to SMM

 arch/x86/kvm/x86.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] drivers/tty: make serial 8250_lpc18xx.c explicitly non-modular

[Greg Kroah-Hartman]

On Tue, Aug 11, 2015 at 02:05:44AM -0400, Paul Gortmaker wrote:
> [Re: [PATCH 5/5] drivers/tty: make serial 8250_lpc18xx.c explicitly 
> non-modular] On 10/08/2015 (Mon 20:42) Joachim Eastwood wrote:
> 
> > Hi Paul,
> > 
> > On 9 August 2015 at 02:51, Paul Gortmaker  
> > wrote:
> > > The Kconfig currently controlling compilation of this code is:
> > >
> > > 8250/Kconfig:config SERIAL_8250_LPC18XX
> > > 8250/Kconfig:bool "NXP LPC18xx/43xx serial port support"
> > >
> > > ...meaning that it currently is not being built as a module by anyone.
> > >
> > > Lets remove the modular code that is essentially orphaned, so that
> > > when reading the driver there is no doubt it is builtin-only.
> > 
> > The bool in KConfig is more or less a copy-paste mistake on my side. I
> > really meant for this driver to be buildable as module and it builds
> > just fine with 'm'.
> > 
> > Want me send a patch changing it to tristate or will you handle it?
> 
> I will do a v2 in the next day or so with collected ACKs and this patch
> replaced, unless Greg jumps in and indicates he'd like something
> different.

Nope, that would be fine with me, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 3/6] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel

[Jianwei Wang]

On Thu, Aug 13, 2015 at 8:23 AM, Thierry Reding
 wrote:
> On Wed, Jul 29, 2015 at 04:30:02PM +0800, Jianwei Wang wrote:
>> This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
>> simple panel driver.
>>
>> Signed-off-by: Alison Wang 
>> Signed-off-by: Xiubo Li 
>> Signed-off-by: Jianwei Wang 
>> Acked-by: Daniel Vetter 
>> ---
>>  .../bindings/panel/nec,nl4827hc19_05b.txt  |  7 ++
>>  drivers/gpu/drm/panel/panel-simple.c   | 26 
>> ++
>>  2 files changed, 33 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
>>
>> diff --git a/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt 
>> b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
>> new file mode 100644
>> index 000..20e9473
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
>> @@ -0,0 +1,7 @@
>> +NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
>> +
>> +Required properties:
>> +- compatible: should be "nec,nl4827hc19_05b"
>
> Underscores are deprecated in compatible strings, so I've applied this
> with "nec,nl4827hc19-05b".
>
> Thierry

Okay, thanks.

Jianwei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.10 00/35] 3.10.87-stable review

[Shuah Khan]

On 08/14/2015 11:44 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.87 release.
> There are 35 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 16 17:43:46 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.87-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.14 00/44] 3.14.51-stable review

[Shuah Khan]

On 08/14/2015 11:44 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.51 release.
> There are 44 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 16 17:43:53 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.14.51-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 00/84] 4.1.6-stable review

[Shuah Khan]

On 08/14/2015 11:41 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.1.6 release.
> There are 84 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Aug 16 17:41:54 UTC 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.1.6-rc1.gz
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] serial: 8250: Fix autoconfig_irq() to avoid race conditions

[gre...@linuxfoundation.org]

On Mon, Aug 10, 2015 at 12:15:40AM +, Taichi Kageyama wrote:
> The following race conditions can happen when a serial port is used
> as console.
> 
> Case1: CPU_B is used to detect an interrupt from a serial port,
>but it can have interrupts disabled during the waiting time.
> Case2: CPU_B clears UART_IER just after CPU_A sets UART_IER and then
>a serial port may not make an interrupt.
> Case3: CPU_A sets UART_IER just after CPU_B clears UART_IER.
>This is an unexpected behavior for serial8250_console_write().
> 
> CPU_A [autoconfig_irq]  |  CPU_B [serial8250_console_write]
> |---
> |
> probe_irq_on()  |  spin_lock_irqsave(&port->lock,)
> serial_outp(,UART_IER,0x0f) |  serial_out(,UART_IER,0)
> udelay(20); |  uart_console_write()
> probe_irq_off() |
> |  spin_unlock_irqrestore(&port->lock,)
> 
> Case1 and 2 can make autoconfig_irq() failed.
> In these cases, the console doesn't work in interrupt mode and
> "input overrun" (which can make operation mistakes) can happen
> on some systems. Especially in the Case1, It is known that the
> problem happens with high rate every boot once it occurs
> because the boot sequence is always almost same.
> 
> port mutex makes sure that the autoconfig operation is exclusive of
> any other concurrent HW access except by the console operation.
> console lock is required in autoconfig_irq().
> 
> Signed-off-by: Taichi Kageyama 
> Cc: Naoya Horiguchi 
> Reviewed-by: Peter Hurley 
> ---
>  drivers/tty/serial/8250/8250_core.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git v4.2-rc4.org/drivers/tty/serial/8250/8250_core.c 
> v4.2-rc4.work/drivers/tty/serial/8250/8250_core.c
> index 37fff12..ed1e23e 100644
> --- v4.2-rc4.org/drivers/tty/serial/8250/8250_core.c
> +++ v4.2-rc4.work/drivers/tty/serial/8250/8250_core.c
> @@ -1303,6 +1303,9 @@ static void autoconfig_irq(struct uart_8250_port *up)
>   inb_p(ICP);
>   }
>  
> + if (uart_console(port))
> + console_lock();
> +
>   /* forget possible initially masked and pending IRQ */
>   probe_irq_off(probe_irq_on());
>   save_mcr = serial_in(up, UART_MCR);
> @@ -1334,6 +1337,9 @@ static void autoconfig_irq(struct uart_8250_port *up)
>   if (port->flags & UPF_FOURPORT)
>   outb_p(save_ICP, ICP);
>  
> + if (uart_console(port))
> + console_unlock();
> +
>   port->irq = (irq > 0) ? irq : 0;
>  }

This doesn't apply to my tty-next tree at all.  Can you please rebase it
and resend?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: My email.

[Fei Lau]

Dear Friend, 

My name is Fei Kan Lau,a Senior staff with Bank of China U K.A late investor 
who bears the same last name with you has left a very huge sum with Our Bank 
for some years and no next of kin has come forward all these years for claim. 
Please get back to me as soon as possible for details if you are interested in 
my proposal. 

Best Regards, 

Fei Kan Lau.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: keystone: add a work around to handle asynchronous external abort

[santosh.shilim...@oracle.com]

On 8/14/15 2:53 PM, Murali Karicheri wrote:

On 08/14/2015 11:14 AM, santosh shilimkar wrote:

On 8/14/2015 7:09 AM, Russell King - ARM Linux wrote:

On Fri, Aug 14, 2015 at 10:04:41AM -0400, Murali Karicheri wrote:

On 08/11/2015 03:13 PM, Murali Karicheri wrote:

Currently on some devices, an asynchronous external abort exception
happens during boot up when exception handlers are enabled in kernel
before switching to user space. This patch adds a workaround to handle
this once during boot. Many customers are already using this
with out any issues and is required to workaround the above issue.

Signed-off-by: Murali Karicheri 
---
  arch/arm/mach-keystone/keystone.c | 26 ++
  1 file changed, 26 insertions(+)


[...]


+
+/*
+ * Add a one time exception handler to catch asynchronous
external
+ * abort
+ */
+hook_fault_code(17, keystone_async_ext_abort_fault, SIGBUS, 0,
+"async external abort handler");
  }

  static phys_addr_t keystone_virt_to_idmap(unsigned long x)


Can this be applied if it looks good?


What causes the abort?  We shouldn't be adding hacks like this to the
kernel without having the full picture...


Indeed. These external aborts are notorious and often hides dangerous
bugs. On OMAP as well many folks burn their had with it till the
interconnect handlers were added to detect those and hunt those
bugs.

In my experience such aborts happen outside ARM subsystem, either in
the interconnect or at the salve targets which are reported over
the ARM bus as async external aborts. And often these errors are
due to bad accesses/wrong accesses/un-clocked accesses at slaves.


We have spend some time already to debug the root cause. Do you have
idea on how this was hunted down on OMAP that we can learn from? The bad
address is NULL and it seems to happen very rarely and is not easily
reproducible. Don't want to put this workaround, but we couldn't track
it down either. So any help to debug this will be appreciated.


As RMK pointed out, try Lucas patch and see if it gives any useful
information to narrow it down.

On OMAP, fortunately interconnect has IRQ(s) which are hooked with
ARM subsystem. So the bus driver(drivers/bus/omap-l3*) was able to
handle those events and report the offenders.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] KVM: x86: fix edge EOI and IOAPIC reconfig race

[Paolo Bonzini]

On 14/08/2015 10:38, Radim Krčmář wrote:
>> How do you reproduce the bug?
> I run rhel4 (2.6.9) kernel on 2 VCPUs and frequently alternate
> smp_affinity of "timer".  The bug is hit within seconds.

Nice, I'll try to make a unit test for it on the plane. :)

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] Early batch of KVM changes for 4.3 merge window

[Paolo Bonzini]

Linus,

the merge window will likely coincide with my two-week vacation
across August and September.

Rather than hoping for an -rc8, I'm sending now what I have.  The
PPC and ARM parts might come a few days after the official end
of the merge window.

The uncommon name for the tag (you said you look at things like
that) is due to the other pull request that is in flight for 4.2.
You can see on kernel.org that I and the other maintainers before
me have always used this format to archive what is sent during the
merge window.  The pull request also matches the next branch of
the repository.

The following changes since commit 0da029ed7ee5fdf49a2a0e14160c3ebe9292:

  KVM: x86: rename quirk constants to KVM_X86_QUIRK_* (2015-07-23 08:24:42 
+0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-4.3-1

for you to fetch changes up to 4d283ec908e617fa28bcb06bce310206f0655d67:

  x86/kvm: Rename VMX's segment access rights defines (2015-08-15 00:47:13 
+0200)


A very small release for x86 and s390 KVM.

s390: timekeeping changes, cleanups and fixes

x86: support for Hyper-V MSRs to report crashes, and a bunch of cleanups.

One interesting feature that was planned for 4.3 (emulating the local
APIC in kernel while keeping the IOAPIC and 8254 in userspace) had to
be delayed because Intel complained about my reading of the manual.


Alex Williamson (1):
  KVM: MTRR: Use default type for non-MTRR-covered gfn before WARN_ON

Andrey Smetanin (4):
  kvm/x86: move Hyper-V MSR's/hypercall code into hyperv.c file
  kvm: introduce vcpu_debug = kvm_debug + vcpu context
  kvm/x86: added hyper-v crash msrs into kvm hyperv context
  kvm/x86: add sending hyper-v crash notification to user space

Andy Lutomirski (1):
  x86/kvm: Rename VMX's segment access rights defines

Christian Borntraeger (10):
  KVM: s390: add kvm stat counter for all diagnoses
  KVM: s390: Improve vcpu event debugging for diagnoses
  KVM: s390: VCPU_EVENT cleanup for prefix changes
  KVM: s390: add more debug data for the pfault diagnoses
  KVM: s390: Fixup interrupt vcpu event messages and levels
  KVM: s390: remove outdated documentation
  KVM: s390: improve debug feature usage
  KVM: s390: adapt debug entries for instruction handling
  KVM: s390: Provide global debug log
  KVM: s390: log capability enablement and vm attribute changes

David Hildenbrand (3):
  KVM: s390: filter space-switch events when PER is enforced
  KVM: s390: remove "from (user|kernel)" from irq injection messages
  KVM: s390: more irq names for trace events

Dominik Dingel (3):
  KVM: s390: propagate error from enable storage key
  KVM: s390: clean up cmma_enable check
  KVM: s390: only reset CMMA state if it was enabled before

Eugene Korenevsky (1):
  KVM: nVMX: VMX instructions: add checks for #GP/#SS exceptions

Fan Zhang (1):
  KVM: s390: host STP toleration for VMs

Mihai Donțu (1):
  kvm/x86: add support for MONITOR_TRAP_FLAG

Nicholas Krause (2):
  KVM: s390: Fix assumption that kvm_set_irq_routing is always run 
successfully
  kvm: x86: Fix error handling in the function kvm_lapic_sync_from_vapic

Paolo Bonzini (7):
  KVM: svm: handle KVM_X86_QUIRK_CD_NW_CLEARED in svm_get_mt_mask
  Merge tag 'kvm-s390-next-20150728' of 
git://git.kernel.org/.../kvms390/linux into kvm-next
  KVM: move code related to KVM_SET_BOOT_CPU_ID to x86
  KVM: x86: remove unnecessary memory barriers for shared MSRs
  KVM: document memory barriers for kvm->vcpus/kvm->online_vcpus
  KVM: x86: clean/fix memory barriers in irqchip_in_kernel
  Merge tag 'kvm-s390-next-20150812' of 
git://git.kernel.org/.../kvms390/linux into HEAD

Wei Huang (1):
  KVM: x86/vPMU: Fix unnecessary signed extension for AMD PERFCTRn

Xiao Guangrong (9):
  KVM: MMU: fix validation of mmio page fault
  KVM: MMU: move FNAME(is_rsvd_bits_set) to mmu.c
  KVM: MMU: introduce rsvd_bits_validate
  KVM: MMU: split reset_rsvds_bits_mask
  KVM: MMU: split reset_rsvds_bits_mask_ept
  KVM: MMU: introduce the framework to check zero bits on sptes
  KVM: MMU: introduce is_shadow_zero_bits_set()
  KVM: MMU: fully check zero bits for sptes
  KVM: VMX: drop ept misconfig check

 Documentation/s390/00-INDEX   |   2 -
 Documentation/s390/kvm.txt| 125 -
 Documentation/virtual/kvm/api.txt |   5 +
 arch/s390/include/asm/etr.h   |   3 +
 arch/s390/include/asm/kvm_host.h  |   4 +-
 arch/s390/kernel/time.c   |  16 +-
 arch/s390/kvm/diag.c  |  13 +-
 arch/s390/kvm/guestdbg.c  |  35 
 arch/s390/kvm/interrupt.c |  98 +-
 arch/s390/kvm/kvm-s390.c  | 114 ++--
 arch/s390/kvm/kvm-s390.h  |  11 +-
 arch/s390/kv

Re: [GIT PULL 00/19] phy: for 4.3

[Greg KH]

On Tue, Aug 11, 2015 at 09:26:59PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Please find the pull request for 4.3 merge window below. This contains a new
> NXP phy driver, extcon support and few fixes in phy-sun4i-usb driver and other
> trivial code cleanups.
> 
> Let me know if I have to change something.
> 
> Thanks
> Kishon
> 
> The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
> 
>   Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/phy-for-4.3

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

[Li Yang]

On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan  wrote:
> Hi Leo,
>
> Thanks for your review.
> About those two methods for DMA suspend that you have mentioned. We have a 
> lot of the discussions in other DMA driver like DMA for Freescale PowerPC.
>
> Finally, we think the device which used the DMA transmission service should 
> cancel the transmission service in its suspend.
> So DMA in suspend should be idle.

If that's the case you should clearly state this in the commit message
and in code, although I don't know if it is safe to make such
assumption.  There could be user of the DMA that doesn't track the
completion of transfers.

>
> Once the DMA in late_suspend is not be idle, we think some driver haven't 
> canceled the DMA transmission. So maybe something is error when other driver 
> in suspend.
>
> In the case, we should return failed to stop PM. DMA should not make a choice 
> for other drivers(which used DMA) to force stop DMA transmission.

The suspend entrance should be terminated by wakeup events and only
critical issues.  I don't think we should just terminate the suspend
entrance just because having on-going I/O without even try to stop it.

>
> Thanks.
>
> Best Regards,
> Yuan Yao
>
>> -Original Message-
>> From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li Yang
>> Sent: Friday, August 14, 2015 4:58 AM
>> To: Yuan Yao-B46683
>> Cc: Vinod Koul; ste...@agner.ch; Arnd Bergmann; Dan Williams;
>> dmaeng...@vger.kernel.org; lkml; linux-arm-ker...@lists.infradead.org; linux-
>> p...@vger.kernel.org
>> Subject: Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume
>> support
>>
>> On Tue, Jul 21, 2015 at 3:56 AM, Yuan Yao  wrote:
>> > This add power management suspend/resume support for the fsl-edma
>> > driver.
>> >
>> > eDMA acted as a basic function used by others. What it needs to do is
>> > the two steps below to support power management.
>> >
>> > In fsl_edma_suspend_late:
>> > Check whether the DMA chan is idle and if it is not idle, stop PM
>> > operation.
>>
>> You should try to quiesce the device on suspend instead of depending on 
>> itself
>> to be happen in idle and failing if it is not.
>>
>> Regards,
>> Leo



-- 
- Leo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] USB patches for v4.3 merge window

[Greg KH]

On Thu, Aug 13, 2015 at 09:26:50AM -0500, Felipe Balbi wrote:
> Hi Greg,
> 
> here's the big Gadget pull request. It contains 146 non-merge commits this
> time around.
> 
> All patches have been soaking in next for quite a while and have also been
> tested with the platforms I have around.
> 
> Let me know if you want anything to be changed.
> 
> cheers
> 
> The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f:
> 
>   Linux 4.2-rc4 (2015-07-26 12:26:21 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v4.3

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] doc: Add more workqueue functions to the documentation

[Randy Dunlap]

On 08/14/15 15:46, Tim Bird wrote:
> 
> 
> On 08/13/2015 04:45 PM, Jonathan Corbet wrote:
>> On Mon, 10 Aug 2015 15:16:16 -0700
>> Tim Bird  wrote:
>>
>>> There are some workqueue functions declared in workqueue.h, so include
>>> that in the workqueue section of the DocBook docs.
>>
>> Applied to the docs tree, thanks.
>>
>> It sure would be nice if changes like this were accompanied by a patch
>> fixing the additional warnings it drags in ... :)  In this case I've put
>> something together for workqueue.h and will send it off shortly.
> 
> My apologies.  
> 
> When I do 'make mandocs', the only messages from workqueue.h that I noticed
> were like the following:
> 
> Warn: meta author : no refentry/info/author
> queue_delayed_work
> Note: meta author : see http://docbook.sf.net/el/author
> queue_delayed_work
> Warn: meta author : no author data, so inserted a fixme
> queue_delayed_work
> Note: Writing queue_delayed_work.9
> 
> But there are over 4000 of these messages when I make mandocs, so I assumed
> ignoring them was OK.
> 
> Are these what you saw or was it something else?

These are the new warnings that I saw:

Warning(..//include/linux/workqueue.h:271): No description found for parameter 
'w'
Warning(..//include/linux/workqueue.h:271): Excess function parameter 'work' 
description in 'delayed_work_pending'
Warning(..//include/linux/workqueue.h:390): Excess function parameter 'args' 
description in 'alloc_workqueue'
Warning(..//include/linux/workqueue.h:411): Excess function parameter 'args' 
description in 'alloc_ordered_workqueue'

and Jon has already posted a patch for these.

> Do you know how to get rid of these messages?  
> 
> It's a bit of a pain rebuilding.  When I make a change, it rebuilds 
> everything.
> My build of mandocs takes 27 minutes and generates over 9000 messages.
> Somewhere in the middle of that must have been some other messages related to
> workqueue.h that I missed.
> 
> However, I'll try to fix build errors in the future.


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] net/bonding: enable LRO if one device supports it

[Jarod Wilson]

On 2015-08-14 2:56 AM, Michal Kubecek wrote:

On Thu, Aug 13, 2015 at 02:02:55PM -0400, Jarod Wilson wrote:

Currently, all bonding devices come up, and claim to have LRO support,
which ethtool will let you toggle on and off, even if none of the
underlying hardware devices actually support it. While the bonding driver
takes precautions for slaves that don't support all features, this is at
least a little bit misleading to users.

If we add NETIF_F_LRO to the NETIF_F_ONE_FOR_ALL flags in
netdev_features.h, then netdev_features_increment() will only enable LRO
if 1) its listed in the device's feature mask and 2) if there's actually a
slave present that supports the feature.

Note that this is going to require some follow-up patches, as not all LRO
capable device drivers are currently properly reporting LRO support in
their vlan_features, which is where the bonding driver picks up
device-specific features.

CC: "David S. Miller" 
CC: Jiri Pirko 
CC: Tom Herbert 
CC: Scott Feldman 
CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
  include/linux/netdev_features.h | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 9672781..6440bf1 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -159,7 +159,8 @@ enum {
   */
  #define NETIF_F_ONE_FOR_ALL   (NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ROBUST | \
 NETIF_F_SG | NETIF_F_HIGHDMA | \
-NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED)
+NETIF_F_FRAGLIST | NETIF_F_VLAN_CHALLENGED | \
+NETIF_F_LRO)

  /*
   * If one device doesn't support one of these features, then disable it
--


I don't think this is going to work the way you expect. Assume we have a
non-LRO eth1 and LRO capable eth2. If we enslave eth1 first, bond will
lose NETIF_F_LRO so that while enslaving eth2, bond_enslave() does run

if (!(bond_dev->features & NETIF_F_LRO))
dev_disable_lro(slave_dev);

and disable LRO on eth2 even before computing the bond features so that
in the end, all three interfaces end up with disabled LRO. If you add
the slaves in the opposite order, you end up with eth2 and bond having
LRO enabled. IMHO features should not depend on the order in which
slaves are added into the bond.


Crap, you're right. Hadn't tried inverting the order of added devices, 
as it didn't occur to me that it would make a difference.



You would need to remove the code quoted above to make things work the
way you want (or move it after the call to bond_compute_features() which
is effectively the same). But then the result would be even worse:
adding a LRO-capable slave to a bond having dev_disable_lro() called on
it would not disable LRO on that slave, possibly (or rather likely)
causing communication breakage.

I believe NETIF_F_LRO in its original sense should be only considered
for physical devices; even if it's not explicitely said in the commit
message, the logic behind fbe168ba91f7 ("net: generic dev_disable_lro()
stacked device handling") is that for stacked devices like bond or team,
NETIF_F_LRO means "allow slaves to use LRO if they can and want" while
its absence means "disable LRO on all slaves". If you wanted NETIF_F_LRO
for a bond to mean "there is at least one LRO capable slave", you would
need a new flag for the "LRO should be disabled for all lower devices"
state. I don't think it's worth the effort.


Yeah, my thinking was that it should mean "there's at least one lro 
capable slave". If we just leave things the way they are though, I think 
its confusing on the user side -- it was one of our QE people who 
reported confusion being able to toggle lro on a bond when none of the 
slaves supported it. And there's also the inconsistency among devices 
that support lro in their vlan_features. So I think *something* should 
still be done here to make things clearer and more consistent, but I'll 
have to ponder that next week, since its beyond quitting time on Friday 
already. :)


Oh, last thought: the comment above #define NETIF_F_ONE_FOR_ALL is 
partly to blame for my not thinking harder and trying inverted ordering 
of slave additions:


/*
 * If one device supports one of these features, then enable them
 * for all in netdev_increment_features.
 */

This clearly seems to fall down in the lro case. :)

--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/5] KVM: optimize userspace exits with a new ioctl

[Paolo Bonzini]

On 14/08/2015 12:08, Radim Krčmář wrote:
> v3:
>  * acked by Christian [1/5]
>  * use ioctl argument directly (unsigned long as flags) [4/5]
>  * precisely #ifdef arch-specific ioctls [5/5]
> v2:
>  * move request_exits debug counter patch right after introduction of
>KVM_REQ_EXIT [3/5]
>  * use vcpu ioctl instead of vm one [4/5]
>  * shrink kvm_user_exit from 64 to 32 bytes [4/5]
>  * new [5/5]
> 
> QEMU uses SIGUSR1 to force a userspace exit and also to queue an early
> exit before calling VCPU_RUN -- the signal is blocked in user space and
> temporarily unblocked in VCPU_RUN.
> The temporal unblocking by sigprocmask() in kvm_arch_vcpu_ioctl_run()
> takes a shared siglock, which leads to cacheline bouncing in NUMA
> systems.
> 
> This series allows the same with a new request bit and VM IOCTL that
> marks and kicks target VCPU, hence no need to unblock.
> 
> inl_from_{pmtimer,qemu} vmexit benchmark from kvm-unit-tests shows ~5%
> speedup for 1-4 VCPUs (300-2000 saved cycles) without noticeably
> regressing kernel VM exits.
> (Paolo did a quick run of older version of this series on a NUMA system
>  and the speedup was around 35% when utilizing more nodes.)
> 
> Radim Krčmář (5):
>   KVM: add kvm_has_request wrapper
>   KVM: add KVM_REQ_EXIT request for userspace exit
>   KVM: x86: add request_exits debug counter
>   KVM: add KVM_USER_EXIT vcpu ioctl for userspace exit
>   KVM: refactor asynchronous vcpu ioctl dispatch
> 
>  Documentation/virtual/kvm/api.txt | 25 +
>  arch/x86/include/asm/kvm_host.h   |  1 +
>  arch/x86/kvm/vmx.c|  4 ++--
>  arch/x86/kvm/x86.c| 23 +++
>  include/linux/kvm_host.h  | 15 +--
>  include/uapi/linux/kvm.h  |  4 
>  virt/kvm/kvm_main.c   | 15 ++-
>  7 files changed, 78 insertions(+), 9 deletions(-)
> 

Reviewed-by: Paolo Bonzini 

... however, we still need to decide what to do about machine-check
exceptions before enabling the capability, otherwise we'd need a new
KVM_CAP_USER_EXIT_MCE capability in the future.  So I'm holding up the
patches for now.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Intel-wired-lan] [PATCH v2] e1000e: Modify tx/rx configurations to avoid null pointer dereferences in e1000_open

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Jia-Ju Bai
> Sent: Wednesday, August 05, 2015 3:16 AM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse
> Cc: net...@vger.kernel.org; Jia-Ju Bai; intel-wired-...@lists.osuosl.org;
> linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH v2] e1000e: Modify tx/rx configurations
> to avoid null pointer dereferences in e1000_open
> 
> When e1000e_setup_rx_resources is failed in e1000_open,
> e1000e_free_tx_resources in "err_setup_rx" segment is executed.
> "writel(0, tx_ring->head)" statement in e1000_clean_tx_ring
> in e1000e_free_tx_resources will cause a null poonter dereference(crash),
> because "tx_ring->head" is only assigned in e1000_configure_tx
> in e1000_configure, but it is after e1000e_setup_rx_resources.
> 
> This patch moves head/tail register writing to e1000_configure_tx/rx,
> which can fix this problem. It is inspired by igb_configure_tx_ring
> in the igb driver.
> 
> Specially, thank Alexander Duyck for his valuable suggestion.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c |   24 ---
> -
>  1 file changed, 12 insertions(+), 12 deletions(-)

Tested-by: Aaron Brown 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Stéphane Marchesin]

On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
 wrote:
> On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>
>>
>> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
>> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
>> >>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you 
>> >>can
>> >>identify both lane count and reversal state without touching anything in 
>> >>the
>> >>link training code. i am yet to upstream my changes for CHT that i can 
>> >>share
>> >>if required that does the same in intel_dp_detect without touching any line
>> >>in link training path.
>> >With my current limited knowledge of the dp hotplug (and i915 driver) I
>> >am not sure we could detect the reversed state without trying to train 1
>> >lane only. I'd be glad to look at your changes and test them on my
>> >system if you think that could help having a cleaner solution.
>> >
>> >Cheers,
>> >Benjamin
>> No, what i recommended was to do link training but in intel_dp_detect. Since
>> USB Type C cable
>> also has its own lane count restriction (it can have different lane count
>> than the one supported
>> by panel) you might have to figure that out as well. so both reversal and
>> lane count detection
>> can be done outside the modeset path and keep the code free of type C
>> changes outside
>> detection path.
>>
>> Please find below the code to do the same. Do not waste time trying to apply
>> this directly on
>> nightly since this is based on a local tree and because this is pre- atomic
>> changes code, so you
>> might have to modify chv_upfront_link_train to work on top of the latest
>> nightly code. we
>> are supposed to upstream this and is in my todo list.
>>
>
> [original patch snipped...]
>
> Hi Sivakumar,
>
> So I managed to manually re-apply your patch on top of
> drm-intel-nightly, and tried to port it to make Broadwell working too.
> It works OK if the system is already boot without any external DP used.
> In this case, the detection works and I can see my external monitor
> working properly.
>
> However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
> understand why. I think I enabled all that is mentioned in the PRM to be
> able to train the DP link, but I am obviously missing something else.
> Can you have a look?
>

Hi Benjamin,

I would recommend against this approach. Some adapters will claim that
they recovered a clock even when it isn't on the lanes you enabled,
which means that the reversal detection doesn't always work. The only
reliable way to do this is to go talk to the Chrome OS EC (you can
find these patches later in the Chrome OS tree). It's not as generic,
but we might be able to abstract that logic, maybe.

Stéphane



> My patch is now:
>
> From 11e9c42f55ae27bd6e7b0168bf24d15082c7d517 Mon Sep 17 00:00:00 2001
> From: Durgadoss R 
> Date: Mon, 3 Aug 2015 11:51:16 -0400
> Subject: [PATCH] drm/i915: Enable Upfront link training for type-C DP support
>
> To support USB type C alternate DP mode, the display driver needs to know the
> number of lanes required by DP panel as well as number of lanes that can be
> supported by the type-C cable. Sometimes, the type-C cable may limit the
> bandwidth even if Panel can support more lanes. To address these scenarios,
> the display driver will start link training with max lanes, and if the link
> training fails, the driver then falls back to x2 lanes.
>
> * Since link training is done before modeset, planes are not enabled. Only
>   encoder and the its associated PLLs are enabled.
> * Once link training is done, the encoder and its PLLs are disabled; so that
>   the subsequent modeset is not aware of these changes.
> * As of now, this is tested only on CHV.
>
> Signed-off-by: Durgadoss R 
> [BT: add broadwell support and USB-C reverted state detection]
> Signed-off-by: Benjamin Tissoires 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 163 
> +++
>  drivers/gpu/drm/i915/intel_dp.c  |  22 -
>  drivers/gpu/drm/i915/intel_drv.h |   7 ++
>  3 files changed, 190 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 818f3a3..e8ddba0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15799,3 +15799,166 @@ void intel_modeset_preclose(struct drm_device *dev, 
> struct drm_file *file)
> spin_unlock_irq(&dev->event_lock);
> }
>  }
> +
> +static bool
> +intel_upfront_link_train_config(struct drm_device *dev,
> +   struct intel_dp *intel_dp,
> +   struct intel_crtc *crtc,
> +   uint8_t link_bw,
> +   uint8_t lane_count)
> +{
> +   struct drm_i915_private *dev_priv = dev->dev_private;
> +   struct intel_connector *connector = intel_dp->attached_connector;
> +   struct intel_encoder *encoder = conne

Re: [PATCH v5 0/7] Fifth revision of the performance improvement patch to the VMware balloon driver

[Philip Moltmann]

Hi,

will v5 1/7 - 7/7 be considered for Linux 4.2 ?

Philip

From: Philip P. Moltmann 
Sent: Thursday, August 6, 2015 3:17 PM
To: gre...@linuxfoundation.org
Cc: Philip Moltmann; dmitry.torok...@gmail.com; linux-kernel@vger.kernel.org; 
Xavier Deguillard; a...@linux-foundation.org; pv-driv...@vmware.com
Subject: [PATCH v5 0/7]  Fifth revision of the performance improvement patch to 
the VMware balloon driver

This is the fifth revision fo the path to the VMWare balloon driver. The 
original
was send to linux-kernel@vger.kernel.org on 4/14/15 10.29 am PST. Please refer 
to
the original change for an overview.

v1:
- Initial implementation
v2
- Address suggestions by Dmitry Totoknov
  - Use UINT_MAX as "infitite" rate instead of special casing -1
v3:
- Change commit comment for step 6 to better explain what impact ballooning has
  on the VM performance.
v4:
- Add missing include header  in step 3
v5:
- Moved to from git/torvalds/linux master to git/gregkh/char-misc char-misc-next
  (4816693286d4ff9219b1cc72c2ab9c589448ebcb) and remove already applied steps
  1/9 and 2/9. That changes the numbering of the patches. 3/9 is now 1/7, 4/9 is
  not 2/7, etc. There were no merge issues during this transition.

  Testing done: recompiled, installed, rebooted and make sure ballooning still
works

Thanks
Philip

Philip P. Moltmann (5):
  VMware balloon: Show capabilities of balloon and resulting
capabilities in the debug-fs node.
  VMware balloon: Do not limit the amount of frees and allocations in
non-sleep mode.
  VMware balloon: Support 2m page ballooning.
  VMware balloon: Treat init like reset
  VMware balloon: Enable notification via VMCI

Xavier Deguillard (2):
  VMware balloon: add batching to the vmw_balloon.
  VMware balloon: Update balloon target on each lock/unlock.

 drivers/misc/Kconfig   |   2 +-
 drivers/misc/vmw_balloon.c | 843 +++--
 2 files changed, 662 insertions(+), 183 deletions(-)

--
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [f2fs-dev] [PATCH 1/2] f2fs: increase the number of max hard links

[Jaegeuk Kim]

Change log from v1:
 o increase to the maximum since we have 32 bit structure

>From 448ffa6a623cae1c3537114b9d10f92d1ddf03f5 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Mon, 10 Aug 2015 15:01:12 -0700
Subject: [PATCH] f2fs: increase the number of max hard links

This patch increases the number of maximum hard links for one file.

Reviewed-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/f2fs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a55169a..00591f7 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -322,7 +322,7 @@ enum {
 */
 };
 
-#define F2FS_LINK_MAX  32000   /* maximum link count per file */
+#define F2FS_LINK_MAX  0x  /* maximum link count per file */
 
 #define MAX_DIR_RA_PAGES   4   /* maximum ra pages of dir */
 
-- 
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] f2fs: avoid garbage collecting already moved node blocks

[Jaegeuk Kim]

If node blocks were already moved, we don't need to move them again.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/gc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 81de28d8..0a5d573 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -396,14 +396,18 @@ static void gc_node_segment(struct f2fs_sb_info *sbi,
 {
bool initial = true;
struct f2fs_summary *entry;
+   block_t start_addr;
int off;
 
+   start_addr = START_BLOCK(sbi, segno);
+
 next_step:
entry = sum;
 
for (off = 0; off < sbi->blocks_per_seg; off++, entry++) {
nid_t nid = le32_to_cpu(entry->nid);
struct page *node_page;
+   struct node_info ni;
 
/* stop BG_GC if there is not enough free sections. */
if (gc_type == BG_GC && has_not_enough_free_secs(sbi, 0))
@@ -426,6 +430,12 @@ next_step:
continue;
}
 
+   get_node_info(sbi, nid, &ni);
+   if (ni.blk_addr != start_addr + off) {
+   f2fs_put_page(node_page, 1);
+   continue;
+   }
+
/* set page dirty and write it */
if (gc_type == FG_GC) {
f2fs_wait_on_page_writeback(node_page, NODE);
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] f2fs: handle failed bio allocation

[Jaegeuk Kim]

As the below comment of bio_alloc_bioset, f2fs can allocate multiple bios at the
same time. So, we can't guarantee that bio is allocated all the time.

"
 *   When @bs is not NULL, if %__GFP_WAIT is set then bio_alloc will always be
 *   able to allocate a bio. This is due to the mempool guarantees. To make this
 *   work, callers must never allocate more than 1 bio at a time from this pool.
 *   Callers that need to allocate more than 1 bio must always submit the
 *   previously allocated bio for IO before attempting to allocate a new one.
 *   Failure to do so can cause deadlocks under memory pressure.
"

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c|  3 +--
 fs/f2fs/f2fs.h| 15 +++
 fs/f2fs/segment.c | 14 +++---
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index cad9ebe..726e58b 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -90,8 +90,7 @@ static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, 
block_t blk_addr,
 {
struct bio *bio;
 
-   /* No failure on bio allocation */
-   bio = bio_alloc(GFP_NOIO, npages);
+   bio = f2fs_bio_alloc(npages);
 
bio->bi_bdev = sbi->sb->s_bdev;
bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(blk_addr);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 23bfc0c..a55169a 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_F2FS_CHECK_FS
 #define f2fs_bug_on(sbi, condition)BUG_ON(condition)
@@ -1253,6 +1254,20 @@ retry:
return entry;
 }
 
+static inline struct bio *f2fs_bio_alloc(int npages)
+{
+   struct bio *bio;
+
+   /* No failure on bio allocation */
+retry:
+   bio = bio_alloc(GFP_NOIO, npages);
+   if (!bio) {
+   cond_resched();
+   goto retry;
+   }
+   return bio;
+}
+
 static inline void f2fs_radix_tree_insert(struct radix_tree_root *root,
unsigned long index, void *item)
 {
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 1b42656..6d919fe 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -330,10 +330,12 @@ repeat:
return 0;
 
if (!llist_empty(&fcc->issue_list)) {
-   struct bio *bio = bio_alloc(GFP_NOIO, 0);
+   struct bio *bio;
struct flush_cmd *cmd, *next;
int ret;
 
+   bio = f2fs_bio_alloc(0);
+
fcc->dispatch_list = llist_del_all(&fcc->issue_list);
fcc->dispatch_list = llist_reverse_order(fcc->dispatch_list);
 
@@ -365,8 +367,14 @@ int f2fs_issue_flush(struct f2fs_sb_info *sbi)
if (test_opt(sbi, NOBARRIER))
return 0;
 
-   if (!test_opt(sbi, FLUSH_MERGE))
-   return blkdev_issue_flush(sbi->sb->s_bdev, GFP_KERNEL, NULL);
+   if (!test_opt(sbi, FLUSH_MERGE)) {
+   struct bio *bio = f2fs_bio_alloc(0);
+   int ret;
+
+   ret = submit_bio_wait(WRITE_FLUSH, bio);
+   bio_put(bio);
+   return ret;
+   }
 
init_completion(&cmd.wait);
 
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] sched/fair: Make utilization tracking cpu scale-invariant

[Dietmar Eggemann]

On 14/08/15 17:23, Morten Rasmussen wrote:
> From: Dietmar Eggemann 

[...]

> @@ -2596,7 +2597,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
> *sa,
>   }
>   }
>   if (running)
> - sa->util_sum += scaled_delta_w;
> + sa->util_sum = scale(scaled_delta_w, scale_cpu);


There is a small issue (using = instead of +=) with fatal consequences
for the utilization signal.

-- >8 --

Subject: [PATCH] sched/fair: Make utilization tracking cpu scale-invariant

Besides the existing frequency scale-invariance correction factor, apply
cpu scale-invariance correction factor to utilization tracking to
compensate for any differences in compute capacity. This could be due to
micro-architectural differences (i.e. instructions per seconds) between
cpus in HMP systems (e.g. big.LITTLE), and/or differences in the current
maximum frequency supported by individual cpus in SMP systems. In the
existing implementation utilization isn't comparable between cpus as it
is relative to the capacity of each individual cpu.

Each segment of the sched_avg.util_sum geometric series is now scaled
by the cpu performance factor too so the sched_avg.util_avg of each
sched entity will be invariant from the particular cpu of the HMP/SMP
system on which the sched entity is scheduled.

With this patch, the utilization of a cpu stays relative to the max cpu
performance of the fastest cpu in the system.

In contrast to utilization (sched_avg.util_sum), load
(sched_avg.load_sum) should not be scaled by compute capacity. The
utilization metric is based on running time which only makes sense when
cpus are _not_ fully utilized (utilization cannot go beyond 100% even if
more tasks are added), where load is runnable time which isn't limited
by the capacity of the cpu and therefore is a better metric for
overloaded scenarios. If we run two nice-0 busy loops on two cpus with
different compute capacity their load should be similar since their
compute demands are the same. We have to assume that the compute demand
of any task running on a fully utilized cpu (no spare cycles = 100%
utilization) is high and the same no matter of the compute capacity of
its current cpu, hence we shouldn't scale load by cpu capacity.

Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Signed-off-by: Dietmar Eggemann 
Signed-off-by: Morten Rasmussen 
---
 include/linux/sched.h | 2 +-
 kernel/sched/fair.c   | 7 ---
 kernel/sched/sched.h  | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index a15305117ace..78a93d716fcb 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1180,7 +1180,7 @@ struct load_weight {
  * 1) load_avg factors frequency scaling into the amount of time that a
  * sched_entity is runnable on a rq into its weight. For cfs_rq, it is the
  * aggregated such weights of all runnable and blocked sched_entities.
- * 2) util_avg factors frequency scaling into the amount of time
+ * 2) util_avg factors frequency and cpu scaling into the amount of time
  * that a sched_entity is running on a CPU, in the range [0..SCHED_LOAD_SCALE].
  * For cfs_rq, it is the aggregated such times of all runnable and
  * blocked sched_entities.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c72223a299a8..3321eb13e422 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2553,6 +2553,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
u32 contrib;
int delta_w, scaled_delta_w, decayed = 0;
unsigned long scale_freq = arch_scale_freq_capacity(NULL, cpu);
+   unsigned long scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
 
delta = now - sa->last_update_time;
/*
@@ -2596,7 +2597,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
}
}
if (running)
-   sa->util_sum += scaled_delta_w;
+   sa->util_sum += scale(scaled_delta_w, scale_cpu);
 
delta -= delta_w;
 
@@ -2620,7 +2621,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
cfs_rq->runnable_load_sum += weight * contrib;
}
if (running)
-   sa->util_sum += contrib;
+   sa->util_sum += scale(contrib, scale_cpu);
}
 
/* Remainder of delta accrued against u_0` */
@@ -2631,7 +2632,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
cfs_rq->runnable_load_sum += weight * scaled_delta;
}
if (running)
-   sa->util_sum += scaled_delta;
+   sa->util_sum += scale(scaled_delta, scale_cpu);
 
sa->period_contrib += delta;
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7e6f2506a402..50836a9301f9 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1406,7 +1406,7 @

Re: [PATCH v3 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

[Dmitry Torokhov]

Hi Sanchayan,

On Wed, Aug 05, 2015 at 02:25:51PM +0530, Sanchayan Maity wrote:
> The Colibri Vybrid VF50 module supports 4-wire touchscreens using
> FETs and ADC inputs. This driver uses the IIO consumer interface
> and relies on the vf610_adc driver based on the IIO framework.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  drivers/input/touchscreen/Kconfig   |  12 +
>  drivers/input/touchscreen/Makefile  |   1 +
>  drivers/input/touchscreen/colibri-vf50-ts.c | 404 
> 
>  3 files changed, 417 insertions(+)
>  create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 80f6386..28948ca 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
> To compile this driver as a module, choose M here: the
> module will be called zforce_ts.
>  
> +config TOUCHSCREEN_COLIBRI_VF50
> + tristate "Toradex Colibri on board touchscreen driver"
> + depends on GPIOLIB && IIO && VF610_ADC
> + help
> +   Say Y here if you have a Colibri VF50 and plan to use
> +   the on-board provided 4-wire touchscreen driver.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called colibri_vf50_ts.
> +
>  endif
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index 44deea7..93746a0 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900)   += w90p910_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_SX8654) += sx8654.o
>  obj-$(CONFIG_TOUCHSCREEN_TPS6507X)   += tps6507x-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50)   += colibri-vf50-ts.o
> diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c 
> b/drivers/input/touchscreen/colibri-vf50-ts.c
> new file mode 100644
> index 000..d7bc91a
> --- /dev/null
> +++ b/drivers/input/touchscreen/colibri-vf50-ts.c
> @@ -0,0 +1,404 @@
> +/* Copyright 2015 Toradex AG
> + *
> + * Toradex Colibri VF50 Touchscreen driver
> + *
> + * Originally authored by Stefan Agner for 3.0 kernel
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME "colibri-vf50-ts"
> +#define DRV_VERSION "1.0"
> +
> +#define VF_ADC_MAX ((1 << 12) - 1)
> +
> +#define COLI_TOUCH_MIN_DELAY_US 1000
> +#define COLI_TOUCH_MAX_DELAY_US 2000
> +
> +static int min_pressure = 200;
> +
> +struct vf50_touch_device {
> + struct platform_device  *pdev;
> + struct input_dev*ts_input;
> + struct iio_channel  *channels;
> + struct gpio_desc *gpio_xp;
> + struct gpio_desc *gpio_xm;
> + struct gpio_desc *gpio_yp;
> + struct gpio_desc *gpio_ym;
> + struct gpio_desc *gpio_pen_detect;
> + int pen_irq;
> + bool stop_touchscreen;
> +};
> +
> +/*
> + * Enables given plates and measures touch parameters using ADC
> + */
> +static int adc_ts_measure(struct iio_channel *channel,
> +   struct gpio_desc *plate_p, struct gpio_desc *plate_m)
> +{
> + int i, value = 0, val = 0;
> + int ret;
> +
> + gpiod_set_value(plate_p, 1);
> + gpiod_set_value(plate_m, 1);
> +
> + usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
> +
> + for (i = 0; i < 5; i++) {

Can we have a #define for 5?

> + ret = iio_read_channel_raw(channel, &val);
> + if (ret < 0) {
> + value = ret;
> + goto error_iio_read;
> + }
> +
> + value += val;
> + }
> +
> + value /= 5;
> +
> +error_iio_read:
> + gpiod_set_value(plate_p, 0);
> + gpiod_set_value(plate_m, 0);
> +
> + return value;
> +}
> +
> +/*
> + * Enable touch detection using falling edge detection on XM
> + */
> +static void vf50_ts_enable_touch_detection(struct vf50_touch_device *vf50_ts)
> +{
> + /* Enable plate YM (needs to be strong GND, high active) */
> + gpiod_set_value(vf50_ts->gpio_ym, 1);
> +
> + /*
> +  * Let the platform mux to idle state in order to enable
> +  * Pull-Up on GPIO
> +  */
> + pinctrl_pm_select_idle_state(&vf50_ts->pdev->dev);
> +}
> +
> +/*
> + * ADC touch screen sampling bottom half irq handler
> + */
> +static irqreturn_t vf50_ts_irq_bh(int irq, void *private)
> +{
> + struct vf50_touch_device *vf50_ts = (struct vf50_touch_device *)private;
> +

Re: [PATCH] doc: Add more workqueue functions to the documentation

[Tim Bird]

On 08/13/2015 04:45 PM, Jonathan Corbet wrote:
> On Mon, 10 Aug 2015 15:16:16 -0700
> Tim Bird  wrote:
> 
>> There are some workqueue functions declared in workqueue.h, so include
>> that in the workqueue section of the DocBook docs.
> 
> Applied to the docs tree, thanks.
> 
> It sure would be nice if changes like this were accompanied by a patch
> fixing the additional warnings it drags in ... :)  In this case I've put
> something together for workqueue.h and will send it off shortly.

My apologies.  

When I do 'make mandocs', the only messages from workqueue.h that I noticed
were like the following:

Warn: meta author : no refentry/info/author
queue_delayed_work
Note: meta author : see http://docbook.sf.net/el/author
queue_delayed_work
Warn: meta author : no author data, so inserted a fixme
queue_delayed_work
Note: Writing queue_delayed_work.9

But there are over 4000 of these messages when I make mandocs, so I assumed
ignoring them was OK.

Are these what you saw or was it something else?

Do you know how to get rid of these messages?  

It's a bit of a pain rebuilding.  When I make a change, it rebuilds everything.
My build of mandocs takes 27 minutes and generates over 9000 messages.
Somewhere in the middle of that must have been some other messages related to
workqueue.h that I missed.

However, I'll try to fix build errors in the future.

Thanks,
 -- Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 4.2-rc6 regression: RIP: e030:[] [] detach_if_pending+0x18/0x80

[Eric Dumazet]

On Sat, 2015-08-15 at 00:09 +0200, Sander Eikelenboom wrote:
> On 2015-08-13 00:41, Eric Dumazet wrote:
> > On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote:
> > 
> >> Thanks for the reminder, but luckily i was aware of that,
> >> seen enough of your replies asking for patches to be resubmitted
> >> against "the other tree" ;)
> >> Kernel with patch is currently running so fingers crossed.
> > 
> > Thanks for testing. I am definitely interested knowing your results.
> 
> Hmm it seems now commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af is 
> breaking things
> (have to test if a revert helps) i get this in some guests:


Yes, this was fixed by :
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

More hw_breakpoint scariness reduction

[Andy Lutomirski]

Would you all consider it acceptable to disallow watchpoints on per
cpu data entirely?  I can think of a *lot* of places where hitting #DB
when accessing per cpu data from entry asm would be bad.

Of course, actually implementing that might be less than entirely fun,
given that a cpu could be onlined after creating a watchpoint.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 1/2] arm64: apei: implement arch_apei_get_mem_attributes()

[Jonathan (Zhixiong) Zhang]

From: "Jonathan (Zhixiong) Zhang" 

Table 8 of UEFI 2.5 section 2.3.6.1 defines mappings from EFI
memory types to MAIR attribute encodings for arm64.

If the physical address has memory attributes defined by EFI
memmap as EFI_MEMORY_[UC|WC|WT], return approprate page protection
type according to the UEFI spec. Otherwise, return PAGE_KERNEL.

Reviewed-by: Catalin Marinas 
Acked-by: Hanjun Guo 
Signed-off-by: Jonathan (Zhixiong) Zhang 
Cc: Ingo Molnar 
Cc: Matt Fleming 
Cc: Hanjun Guo 
Cc: Will Deacon 
---
V2: Changed arm64's implementation of arch_apei_get_mem_attributes()
from inline function to out of line function, based on Ingo's
feedback.

 arch/arm64/include/asm/acpi.h |  5 +
 arch/arm64/kernel/acpi.c  | 29 +
 2 files changed, 34 insertions(+)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 406485ed110a..8084f3640006 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -92,4 +92,9 @@ static inline const char *acpi_get_enable_method(int cpu)
 {
return acpi_psci_present() ? "psci" : NULL;
 }
+
+#ifdef CONFIG_ACPI_APEI
+pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+#endif
+
 #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 19de7537e7d3..9f083606e5bf 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -29,6 +29,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_ACPI_APEI
+#include 
+#include 
+#endif
+
 int acpi_noirq = 1;/* skip ACPI IRQ initialization */
 int acpi_disabled = 1;
 EXPORT_SYMBOL(acpi_disabled);
@@ -230,3 +235,27 @@ void __init acpi_gic_init(void)
 
early_acpi_os_unmap_memory((char *)table, tbl_size);
 }
+
+#ifdef  CONFIG_ACPI_APEI
+pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+   /*
+* According to "Table 8 Map: EFI memory types to AArch64 memory
+* types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is
+* mapped to a corresponding MAIR attribute encoding.
+* The EFI memory attribute advises all possible capabilities
+* of a memory region. We use the most efficient capability.
+*/
+
+   u64 attr;
+
+   attr = efi_mem_attributes(addr);
+   if (attr & EFI_MEMORY_WB)
+   return PAGE_KERNEL;
+   if (attr & EFI_MEMORY_WT)
+   return __pgprot(PROT_NORMAL_WT);
+   if (attr & EFI_MEMORY_WC)
+   return __pgprot(PROT_NORMAL_NC);
+   return __pgprot(PROT_DEVICE_nGnRnE);
+}
+#endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory

[Jonathan (Zhixiong) Zhang]

From: "Jonathan (Zhixiong) Zhang" 

With ACPI APEI firmware first handling, generic hardware error
record is updated by firmware in GHES memory region. On an arm64
platform, firmware updates GHES memory region with uncached
access attribute, and then Linux reads stale data from cache.

With current code, GHES memory region is mapped with PAGE_KERNEL
based on the assumption that cache coherency of GHES memory region
is maintained by firmware on all platforms. This assumption is
not true for above mentioned arm64 platform.

Instead GHES memory region should be mapped with page protection type
according to what is returned from arch_apei_get_mem_attribute().

Acked-by: Borislav Petkov 
Signed-off-by: Jonathan (Zhixiong) Zhang 
---
 drivers/acpi/apei/ghes.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 23981ac1c6c2..f742335bd8bb 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -160,8 +160,10 @@ static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
unsigned long vaddr;
 
vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
-   ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
-  pfn << PAGE_SHIFT, PAGE_KERNEL);
+   ioremap_page_range(vaddr,
+  vaddr + PAGE_SIZE,
+  pfn << PAGE_SHIFT,
+  arch_apei_get_mem_attribute(pfn << PAGE_SHIFT));
 
return (void __iomem *)vaddr;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/