[PATCH v2 RESEND] usb: gadget: provide interface for legacy gadgets to get UDC name

[Marek Szyprowski]

Since commit 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb: gadget:
udc-core: independent registration of gadgets and gadget drivers") gadget
drivers can not assume that UDC drivers are already available on their
initialization. This broke the HACK, which was used in gadgetfs driver,
to get UDC controller name. This patch removes this hack and replaces it
by additional function in the UDC core (which is usefully only for legacy
drivers, please don't use it in the new code).

Reported-by: Vegard Nossum 
Signed-off-by: Marek Szyprowski 
Tested-by: Vegard Nossum 
---
changelog:
v2:
- properly report udc gagdet driver name instead of udc device name

v1: https://lkml.org/lkml/2016/2/8/176
- initial version
---
 drivers/usb/gadget/legacy/inode.c | 29 ++---
 drivers/usb/gadget/udc/udc-core.c | 33 +
 include/linux/usb/gadget.h|  1 +
 3 files changed, 36 insertions(+), 27 deletions(-)

diff --git a/drivers/usb/gadget/legacy/inode.c 
b/drivers/usb/gadget/legacy/inode.c
index 7e179f81d05c..7a62a2f7bc18 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -227,7 +227,7 @@ static void put_ep (struct ep_data *data)
  * implicitly, starting with the driver name and then endpoint names.
  */
 
-static const char *CHIP;
+static char CHIP[32];
 
 /*--*/
 
@@ -1697,28 +1697,6 @@ static struct usb_gadget_driver gadgetfs_driver = {
 };
 
 /*--*/
-
-static void gadgetfs_nop(struct usb_gadget *arg) { }
-
-static int gadgetfs_probe(struct usb_gadget *gadget,
-   struct usb_gadget_driver *driver)
-{
-   CHIP = gadget->name;
-   return -EISNAM;
-}
-
-static struct usb_gadget_driver probe_driver = {
-   .max_speed  = USB_SPEED_HIGH,
-   .bind   = gadgetfs_probe,
-   .unbind = gadgetfs_nop,
-   .setup  = (void *)gadgetfs_nop,
-   .disconnect = gadgetfs_nop,
-   .driver = {
-   .name   = "nop",
-   },
-};
-
-
 /* DEVICE INITIALIZATION
  *
  * fd = open ("/dev/gadget/$CHIP", O_RDWR)
@@ -1968,10 +1946,7 @@ gadgetfs_fill_super (struct super_block *sb, void *opts, 
int silent)
if (the_device)
return -ESRCH;
 
-   /* fake probe to determine $CHIP */
-   CHIP = NULL;
-   usb_gadget_probe_driver(_driver);
-   if (!CHIP)
+   if (usb_get_gadget_udc_name(CHIP, sizeof(CHIP)) != 0)
return -ENODEV;
 
/* superblock */
diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index fd73a3ea07c2..4bde2e110e44 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -442,6 +442,39 @@ err1:
 EXPORT_SYMBOL_GPL(usb_add_gadget_udc_release);
 
 /**
+ * usb_get_gadget_udc_name - get the name of the first UDC controller
+ * @dst_name
+ * @len
+ * This functions returns the name of the first UDC controller in the system.
+ * Please note that this interface is usefull only for legacy drivers which
+ * assume that there is only one UDC controller in the system and they need to
+ * get its name before initialization. There is no guarantee that the UDC
+ * of the returned name will be still available, when gadget driver registers
+ * itself.
+ *
+ * Returns zero on success, negative errno otherwise.
+ */
+int usb_get_gadget_udc_name(char *dst_name, int len)
+{
+   struct usb_udc *udc;
+   int ret = -ENODEV;
+
+   mutex_lock(_lock);
+   list_for_each_entry(udc, _list, list) {
+   const char *name = udc->gadget->name;
+   /* For now we take the first one */
+   if (!udc->driver && strlen(name) + 1 <= len) {
+   strcpy(dst_name, name);
+   ret = 0;
+   break;
+   }
+   }
+   mutex_unlock(_lock);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(usb_get_gadget_udc_name);
+
+/**
  * usb_add_gadget_udc - adds a new gadget to the udc class driver list
  * @parent: the parent device to this udc. Usually the controller
  * driver's device.
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index d82d0068872b..0a8f08302a34 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1126,6 +1126,7 @@ extern int usb_add_gadget_udc_release(struct device 
*parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
 extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget 
*gadget);
 extern void usb_del_gadget_udc(struct usb_gadget *gadget);
+extern int usb_get_gadget_udc_name(char *dst_name, int len);
 
 /*-*/
 
-- 
1.9.2

[PATCH v2 RESEND] usb: gadget: provide interface for legacy gadgets to get UDC name

[Marek Szyprowski]

Since commit 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb: gadget:
udc-core: independent registration of gadgets and gadget drivers") gadget
drivers can not assume that UDC drivers are already available on their
initialization. This broke the HACK, which was used in gadgetfs driver,
to get UDC controller name. This patch removes this hack and replaces it
by additional function in the UDC core (which is usefully only for legacy
drivers, please don't use it in the new code).

Reported-by: Vegard Nossum 
Signed-off-by: Marek Szyprowski 
Tested-by: Vegard Nossum 
---
changelog:
v2:
- properly report udc gagdet driver name instead of udc device name

v1: https://lkml.org/lkml/2016/2/8/176
- initial version
---
 drivers/usb/gadget/legacy/inode.c | 29 ++---
 drivers/usb/gadget/udc/udc-core.c | 33 +
 include/linux/usb/gadget.h|  1 +
 3 files changed, 36 insertions(+), 27 deletions(-)

diff --git a/drivers/usb/gadget/legacy/inode.c 
b/drivers/usb/gadget/legacy/inode.c
index 7e179f81d05c..7a62a2f7bc18 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -227,7 +227,7 @@ static void put_ep (struct ep_data *data)
  * implicitly, starting with the driver name and then endpoint names.
  */
 
-static const char *CHIP;
+static char CHIP[32];
 
 /*--*/
 
@@ -1697,28 +1697,6 @@ static struct usb_gadget_driver gadgetfs_driver = {
 };
 
 /*--*/
-
-static void gadgetfs_nop(struct usb_gadget *arg) { }
-
-static int gadgetfs_probe(struct usb_gadget *gadget,
-   struct usb_gadget_driver *driver)
-{
-   CHIP = gadget->name;
-   return -EISNAM;
-}
-
-static struct usb_gadget_driver probe_driver = {
-   .max_speed  = USB_SPEED_HIGH,
-   .bind   = gadgetfs_probe,
-   .unbind = gadgetfs_nop,
-   .setup  = (void *)gadgetfs_nop,
-   .disconnect = gadgetfs_nop,
-   .driver = {
-   .name   = "nop",
-   },
-};
-
-
 /* DEVICE INITIALIZATION
  *
  * fd = open ("/dev/gadget/$CHIP", O_RDWR)
@@ -1968,10 +1946,7 @@ gadgetfs_fill_super (struct super_block *sb, void *opts, 
int silent)
if (the_device)
return -ESRCH;
 
-   /* fake probe to determine $CHIP */
-   CHIP = NULL;
-   usb_gadget_probe_driver(_driver);
-   if (!CHIP)
+   if (usb_get_gadget_udc_name(CHIP, sizeof(CHIP)) != 0)
return -ENODEV;
 
/* superblock */
diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index fd73a3ea07c2..4bde2e110e44 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -442,6 +442,39 @@ err1:
 EXPORT_SYMBOL_GPL(usb_add_gadget_udc_release);
 
 /**
+ * usb_get_gadget_udc_name - get the name of the first UDC controller
+ * @dst_name
+ * @len
+ * This functions returns the name of the first UDC controller in the system.
+ * Please note that this interface is usefull only for legacy drivers which
+ * assume that there is only one UDC controller in the system and they need to
+ * get its name before initialization. There is no guarantee that the UDC
+ * of the returned name will be still available, when gadget driver registers
+ * itself.
+ *
+ * Returns zero on success, negative errno otherwise.
+ */
+int usb_get_gadget_udc_name(char *dst_name, int len)
+{
+   struct usb_udc *udc;
+   int ret = -ENODEV;
+
+   mutex_lock(_lock);
+   list_for_each_entry(udc, _list, list) {
+   const char *name = udc->gadget->name;
+   /* For now we take the first one */
+   if (!udc->driver && strlen(name) + 1 <= len) {
+   strcpy(dst_name, name);
+   ret = 0;
+   break;
+   }
+   }
+   mutex_unlock(_lock);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(usb_get_gadget_udc_name);
+
+/**
  * usb_add_gadget_udc - adds a new gadget to the udc class driver list
  * @parent: the parent device to this udc. Usually the controller
  * driver's device.
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index d82d0068872b..0a8f08302a34 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1126,6 +1126,7 @@ extern int usb_add_gadget_udc_release(struct device 
*parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
 extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget 
*gadget);
 extern void usb_del_gadget_udc(struct usb_gadget *gadget);
+extern int usb_get_gadget_udc_name(char *dst_name, int len);
 
 /*-*/
 
-- 
1.9.2

[PATCH RESEND] usb: gadget: gadgetfs: unregister gadget only if it got successfully registered

[Marek Szyprowski]

Gadgetfs driver called usb_gadget_unregister_driver unconditionally, even
if it didn't register it earlier due to other failures. This patch fixes
this.

Reported-by: Vegard Nossum 
Signed-off-by: Marek Szyprowski 
Tested-by: Vegard Nossum 
---
 drivers/usb/gadget/legacy/inode.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/legacy/inode.c 
b/drivers/usb/gadget/legacy/inode.c
index 7a62a2f7bc18..cde6a2133c90 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -130,7 +130,8 @@ struct dev_data {
setup_can_stall : 1,
setup_out_ready : 1,
setup_out_error : 1,
-   setup_abort : 1;
+   setup_abort : 1,
+   gadget_registered : 1;
unsignedsetup_wLength;
 
/* the rest is basically write-once */
@@ -1179,7 +1180,8 @@ dev_release (struct inode *inode, struct file *fd)
 
/* closing ep0 === shutdown all */
 
-   usb_gadget_unregister_driver (_driver);
+   if (dev->gadget_registered)
+   usb_gadget_unregister_driver (_driver);
 
/* at this point "good" hardware has disconnected the
 * device from USB; the host won't see it any more.
@@ -1825,6 +1827,7 @@ dev_config (struct file *fd, const char __user *buf, 
size_t len, loff_t *ptr)
 * kick in after the ep0 descriptor is closed.
 */
value = len;
+   dev->gadget_registered = true;
}
return value;
 
-- 
1.9.2

[PATCH RESEND] usb: gadget: gadgetfs: unregister gadget only if it got successfully registered

[Marek Szyprowski]

Gadgetfs driver called usb_gadget_unregister_driver unconditionally, even
if it didn't register it earlier due to other failures. This patch fixes
this.

Reported-by: Vegard Nossum 
Signed-off-by: Marek Szyprowski 
Tested-by: Vegard Nossum 
---
 drivers/usb/gadget/legacy/inode.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/legacy/inode.c 
b/drivers/usb/gadget/legacy/inode.c
index 7a62a2f7bc18..cde6a2133c90 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -130,7 +130,8 @@ struct dev_data {
setup_can_stall : 1,
setup_out_ready : 1,
setup_out_error : 1,
-   setup_abort : 1;
+   setup_abort : 1,
+   gadget_registered : 1;
unsignedsetup_wLength;
 
/* the rest is basically write-once */
@@ -1179,7 +1180,8 @@ dev_release (struct inode *inode, struct file *fd)
 
/* closing ep0 === shutdown all */
 
-   usb_gadget_unregister_driver (_driver);
+   if (dev->gadget_registered)
+   usb_gadget_unregister_driver (_driver);
 
/* at this point "good" hardware has disconnected the
 * device from USB; the host won't see it any more.
@@ -1825,6 +1827,7 @@ dev_config (struct file *fd, const char __user *buf, 
size_t len, loff_t *ptr)
 * kick in after the ep0 descriptor is closed.
 */
value = len;
+   dev->gadget_registered = true;
}
return value;
 
-- 
1.9.2

Re: [PATCH v1 5/8] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

[Joonsoo Kim]

2016-02-17 3:37 GMT+09:00 Alexander Potapenko :
> On Mon, Feb 1, 2016 at 3:55 AM, Joonsoo Kim  wrote:
>> On Thu, Jan 28, 2016 at 02:27:44PM +0100, Alexander Potapenko wrote:
>>> On Thu, Jan 28, 2016 at 1:51 PM, Alexander Potapenko  
>>> wrote:
>>> >
>>> > On Jan 28, 2016 8:40 AM, "Joonsoo Kim"  wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> On Wed, Jan 27, 2016 at 07:25:10PM +0100, Alexander Potapenko wrote:
>>> >> > Stack depot will allow KASAN store allocation/deallocation stack traces
>>> >> > for memory chunks. The stack traces are stored in a hash table and
>>> >> > referenced by handles which reside in the kasan_alloc_meta and
>>> >> > kasan_free_meta structures in the allocated memory chunks.
>>> >>
>>> >> Looks really nice!
>>> >>
>>> >> Could it be more generalized to be used by other feature that need to
>>> >> store stack trace such as tracepoint or page owner?
>>> > Certainly yes, but see below.
>>> >
>>> >> If it could be, there is one more requirement.
>>> >> I understand the fact that entry is never removed from depot makes things
>>> >> very simpler, but, for general usecases, it's better to use reference
>>> >> count
>>> >> and allow to remove. Is it possible?
>>> > For our use case reference counting is not really necessary, and it would
>>> > introduce unwanted contention.
>>
>> Okay.
>>
>>> > There are two possible options, each having its advantages and drawbacks: 
>>> > we
>>> > can let the clients store the refcounters directly in their stacks (more
>>> > universal, but harder to use for the clients), or keep the counters in the
>>> > depot but add an API that does not change them (easier for the clients, 
>>> > but
>>> > potentially error-prone).
>>> > I'd say it's better to actually find at least one more user for the stack
>>> > depot in order to understand the requirements, and refactor the code after
>>> > that.
>>
>> I re-think the page owner case and it also may not need refcount.
>> For now, just moving this stuff to /lib would be helpful for other future 
>> user.
> I agree this code may need to be moved to /lib someday, but I wouldn't
> hurry with that.
> Right now it is quite KASAN-specific, and it's unclear yet whether
> anyone else is going to use it.
> I suggest we keep it in mm/kasan for now, and factor the common parts
> into /lib when the need arises.

Please consider it one more time. I really have a plan to use it on page owner,
because using page owner requires too many memory for stack trace and
it changes system behaviour a lot.

Page owner uses following structure to store stack trace.

struct page_ext {
unsigned long flags;
#ifdef CONFIG_PAGE_OWNER
unsigned int order;
gfp_t gfp_mask;
unsigned int nr_entries;
int last_migrate_reason;
unsigned long trace_entries[8];
#endif
};

Using stack depot in page owner would be straight forward if stack depot
is in /lib. It is possible to move it when needed but it requires moving
a file and it would not be desirable.

>> BTW, is there any performance number? I guess that it could affect
>> the performance.
> I've compared the performance of KASAN with SLAB allocator on a small
> synthetic benchmark in two modes: with stack depot enabled and with
> kasan_save_stack() unconditionally returning 0.
> In the former case 8% more time was spent in the kernel than in the latter 
> case.
>
> If I am not mistaking, for SLUB allocator the bookkeeping (enabled
> with the slub_debug=UZ boot options) take only 1.5 time, so the
> difference is worth looking into (at least before we switch SLUB to
> stack depot).

Okay.

Re: [PATCH v1 5/8] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

[Joonsoo Kim]

2016-02-17 3:37 GMT+09:00 Alexander Potapenko :
> On Mon, Feb 1, 2016 at 3:55 AM, Joonsoo Kim  wrote:
>> On Thu, Jan 28, 2016 at 02:27:44PM +0100, Alexander Potapenko wrote:
>>> On Thu, Jan 28, 2016 at 1:51 PM, Alexander Potapenko  
>>> wrote:
>>> >
>>> > On Jan 28, 2016 8:40 AM, "Joonsoo Kim"  wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> On Wed, Jan 27, 2016 at 07:25:10PM +0100, Alexander Potapenko wrote:
>>> >> > Stack depot will allow KASAN store allocation/deallocation stack traces
>>> >> > for memory chunks. The stack traces are stored in a hash table and
>>> >> > referenced by handles which reside in the kasan_alloc_meta and
>>> >> > kasan_free_meta structures in the allocated memory chunks.
>>> >>
>>> >> Looks really nice!
>>> >>
>>> >> Could it be more generalized to be used by other feature that need to
>>> >> store stack trace such as tracepoint or page owner?
>>> > Certainly yes, but see below.
>>> >
>>> >> If it could be, there is one more requirement.
>>> >> I understand the fact that entry is never removed from depot makes things
>>> >> very simpler, but, for general usecases, it's better to use reference
>>> >> count
>>> >> and allow to remove. Is it possible?
>>> > For our use case reference counting is not really necessary, and it would
>>> > introduce unwanted contention.
>>
>> Okay.
>>
>>> > There are two possible options, each having its advantages and drawbacks: 
>>> > we
>>> > can let the clients store the refcounters directly in their stacks (more
>>> > universal, but harder to use for the clients), or keep the counters in the
>>> > depot but add an API that does not change them (easier for the clients, 
>>> > but
>>> > potentially error-prone).
>>> > I'd say it's better to actually find at least one more user for the stack
>>> > depot in order to understand the requirements, and refactor the code after
>>> > that.
>>
>> I re-think the page owner case and it also may not need refcount.
>> For now, just moving this stuff to /lib would be helpful for other future 
>> user.
> I agree this code may need to be moved to /lib someday, but I wouldn't
> hurry with that.
> Right now it is quite KASAN-specific, and it's unclear yet whether
> anyone else is going to use it.
> I suggest we keep it in mm/kasan for now, and factor the common parts
> into /lib when the need arises.

Please consider it one more time. I really have a plan to use it on page owner,
because using page owner requires too many memory for stack trace and
it changes system behaviour a lot.

Page owner uses following structure to store stack trace.

struct page_ext {
unsigned long flags;
#ifdef CONFIG_PAGE_OWNER
unsigned int order;
gfp_t gfp_mask;
unsigned int nr_entries;
int last_migrate_reason;
unsigned long trace_entries[8];
#endif
};

Using stack depot in page owner would be straight forward if stack depot
is in /lib. It is possible to move it when needed but it requires moving
a file and it would not be desirable.

>> BTW, is there any performance number? I guess that it could affect
>> the performance.
> I've compared the performance of KASAN with SLAB allocator on a small
> synthetic benchmark in two modes: with stack depot enabled and with
> kasan_save_stack() unconditionally returning 0.
> In the former case 8% more time was spent in the kernel than in the latter 
> case.
>
> If I am not mistaking, for SLUB allocator the bookkeeping (enabled
> with the slub_debug=UZ boot options) take only 1.5 time, so the
> difference is worth looking into (at least before we switch SLUB to
> stack depot).

Okay.

Re: [PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

[Ingo Molnar]

* Bryan O'Donoghue  wrote:

> Currently when setting up an IMR around the kernel's .text area we lock
> that IMR, preventing further modification. While superficially this appears
> to be the right thing to do, in fact this doesn't account for a legitimate
> change in the memory map such as when executing a new kernel via kexec.
> 
> In such a scenario a second kernel can have a different size and location
> to it's predecessor and can view some of the memory occupied by it's
> predecessor as legitimately usable DMA RAM. If this RAM were then
> subsequently allocated to DMA agents within the system it could conceivably
> trigger an IMR violation.
> 
> This patch fixes the this potential situation by keeping the kernel's .text
> section IMR lock bit false by default, thus ensuring that a user of the
> system will have kexec just work without having to pass special parameters
> on the kernel command line to influence the state of the kernel's IMR. If a
> user so desires then it is possible to explicitly set the lock bit to true.
> 
> The new parameter is kernel_imr and this may be set to kernel_imr=locked or
> kernel_imr=unlocked.
> 
> Signed-off-by: Bryan O'Donoghue 
> Reported-by: Andy Shevchenko 
> ---
>  Documentation/kernel-parameters.txt |  7 +++
>  arch/x86/platform/intel-quark/imr.c | 39 
> +++--
>  2 files changed, 40 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 9a53c92..1aad1d2 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1359,6 +1359,13 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   hardware thread id mappings.
>   Format: :
>  
> + kernel_imr= [X86, INTEL_IMR] Control the lock bit for the Isolated
> + Memory Region protecting the kernel's .text section on
> + X86 architectures that support IMRs such as Quark X1000.
> + When an IMR lock bit is set it is not possible to unset
> + it without a CPU reset.
> + Format : {locked | unlocked (default) }
> +
>   keep_bootcon[KNL]
>   Do not unregister boot console at start. This is only
>   useful for debugging when something happens in the 
> window
> diff --git a/arch/x86/platform/intel-quark/imr.c 
> b/arch/x86/platform/intel-quark/imr.c
> index c61b6c3..8249f65 100644
> --- a/arch/x86/platform/intel-quark/imr.c
> +++ b/arch/x86/platform/intel-quark/imr.c
> @@ -37,6 +37,7 @@
>  struct imr_device {
>   struct dentry   *file;
>   boolinit;
> + boolkernel_imr_locked;
>   struct mutexlock;
>   int max_imr;
>   int reg_base;
> @@ -568,10 +569,15 @@ static inline int imr_clear(int reg)
>   * BIOS and Grub both setup IMRs around compressed kernel, initrd memory
>   * that need to be removed before the kernel hands out one of the IMR
>   * encased addresses to a downstream DMA agent such as the SD or Ethernet.
> + * Additionally if the current kernel is executing via kexec then we need to
> + * tear down the IMR the previous kernel had setup.
> + *
>   * IMRs on Galileo are setup to immediately reset the system on violation.
>   * As a result if you're running a root filesystem from SD - you'll need
>   * the boot-time IMRs torn down or you'll find seemingly random resets when
> - * using your filesystem.
> + * using your filesystem; similarly if you're doing a kexec boot of Linux 
> then
> + * its required to sanitize the memory map with-respect to the previous IMR
> + * settings.
>   *
>   * @idev:pointer to imr_device structure.
>   * @return:
> @@ -592,14 +598,20 @@ static void __init imr_fixup_memmap(struct imr_device 
> *idev)
>   end = (unsigned long)__end_rodata - 1;
>  
>   /*
> -  * Setup a locked IMR around the physical extent of the kernel
> -  * from the beginning of the .text secton to the end of the
> -  * .rodata section as one physically contiguous block.
> +  * Setup an IMR around the physical extent of the kernel from the
> +  * beginning of the .text section to the end of the .rodata section
> +  * as one physically contiguous block.
>*
>* We don't round up @size since it is already PAGE_SIZE aligned.
>* See vmlinux.lds.S for details.
> +  *
> +  * By default this IMR is unlocked to enable subsequent kernels booted
> +  * by kexec to tear down the IMR we are setting up below. Its possible
> +  * to set this IMR to the locked state by passing kernel_imr=locked on
> +  * the kernel command line.
>*/
> - ret = imr_add_range(base, size, IMR_CPU, IMR_CPU, true);
> +

Re: [PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

[Ingo Molnar]

* Bryan O'Donoghue  wrote:

> Currently when setting up an IMR around the kernel's .text area we lock
> that IMR, preventing further modification. While superficially this appears
> to be the right thing to do, in fact this doesn't account for a legitimate
> change in the memory map such as when executing a new kernel via kexec.
> 
> In such a scenario a second kernel can have a different size and location
> to it's predecessor and can view some of the memory occupied by it's
> predecessor as legitimately usable DMA RAM. If this RAM were then
> subsequently allocated to DMA agents within the system it could conceivably
> trigger an IMR violation.
> 
> This patch fixes the this potential situation by keeping the kernel's .text
> section IMR lock bit false by default, thus ensuring that a user of the
> system will have kexec just work without having to pass special parameters
> on the kernel command line to influence the state of the kernel's IMR. If a
> user so desires then it is possible to explicitly set the lock bit to true.
> 
> The new parameter is kernel_imr and this may be set to kernel_imr=locked or
> kernel_imr=unlocked.
> 
> Signed-off-by: Bryan O'Donoghue 
> Reported-by: Andy Shevchenko 
> ---
>  Documentation/kernel-parameters.txt |  7 +++
>  arch/x86/platform/intel-quark/imr.c | 39 
> +++--
>  2 files changed, 40 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 9a53c92..1aad1d2 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1359,6 +1359,13 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   hardware thread id mappings.
>   Format: :
>  
> + kernel_imr= [X86, INTEL_IMR] Control the lock bit for the Isolated
> + Memory Region protecting the kernel's .text section on
> + X86 architectures that support IMRs such as Quark X1000.
> + When an IMR lock bit is set it is not possible to unset
> + it without a CPU reset.
> + Format : {locked | unlocked (default) }
> +
>   keep_bootcon[KNL]
>   Do not unregister boot console at start. This is only
>   useful for debugging when something happens in the 
> window
> diff --git a/arch/x86/platform/intel-quark/imr.c 
> b/arch/x86/platform/intel-quark/imr.c
> index c61b6c3..8249f65 100644
> --- a/arch/x86/platform/intel-quark/imr.c
> +++ b/arch/x86/platform/intel-quark/imr.c
> @@ -37,6 +37,7 @@
>  struct imr_device {
>   struct dentry   *file;
>   boolinit;
> + boolkernel_imr_locked;
>   struct mutexlock;
>   int max_imr;
>   int reg_base;
> @@ -568,10 +569,15 @@ static inline int imr_clear(int reg)
>   * BIOS and Grub both setup IMRs around compressed kernel, initrd memory
>   * that need to be removed before the kernel hands out one of the IMR
>   * encased addresses to a downstream DMA agent such as the SD or Ethernet.
> + * Additionally if the current kernel is executing via kexec then we need to
> + * tear down the IMR the previous kernel had setup.
> + *
>   * IMRs on Galileo are setup to immediately reset the system on violation.
>   * As a result if you're running a root filesystem from SD - you'll need
>   * the boot-time IMRs torn down or you'll find seemingly random resets when
> - * using your filesystem.
> + * using your filesystem; similarly if you're doing a kexec boot of Linux 
> then
> + * its required to sanitize the memory map with-respect to the previous IMR
> + * settings.
>   *
>   * @idev:pointer to imr_device structure.
>   * @return:
> @@ -592,14 +598,20 @@ static void __init imr_fixup_memmap(struct imr_device 
> *idev)
>   end = (unsigned long)__end_rodata - 1;
>  
>   /*
> -  * Setup a locked IMR around the physical extent of the kernel
> -  * from the beginning of the .text secton to the end of the
> -  * .rodata section as one physically contiguous block.
> +  * Setup an IMR around the physical extent of the kernel from the
> +  * beginning of the .text section to the end of the .rodata section
> +  * as one physically contiguous block.
>*
>* We don't round up @size since it is already PAGE_SIZE aligned.
>* See vmlinux.lds.S for details.
> +  *
> +  * By default this IMR is unlocked to enable subsequent kernels booted
> +  * by kexec to tear down the IMR we are setting up below. Its possible
> +  * to set this IMR to the locked state by passing kernel_imr=locked on
> +  * the kernel command line.
>*/
> - ret = imr_add_range(base, size, IMR_CPU, IMR_CPU, true);
> + ret = imr_add_range(base, size, IMR_CPU, IMR_CPU,
> + 

Re: [PATCH] lightnvm: generalize rrpc ppa calculations

[Matias Bjørling]

On 02/17/2016 12:00 PM, Javier González wrote:
> In rrpc, some calculations assume a certain configuration (e.g., 1 LUN,
> 1 sector per page). The reason behind this was that we have used a simple
> configuration in QEMU to test core features generally in LightNVM, and
> concretely in rrpc. This patch relaxes these assumptions and generalizes
> calculations in order to support real hardware. Note that more complex
> configurations in QEMU, that allow to simulate this hardware, are also
> pushed into the qemu-nvme repository implementing LightNVM support,
> available under the Open-Channel SSD project in github [1].
> 
> [1] https://github.com/OpenChannelSSD/qemu-nvme
> 
> Signed-off-by: Javier González 
> ---
>  drivers/lightnvm/rrpc.c | 45 -
>  drivers/lightnvm/rrpc.h |  9 +
>  2 files changed, 37 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
> index 775bf6c2..f366c78 100644
> --- a/drivers/lightnvm/rrpc.c
> +++ b/drivers/lightnvm/rrpc.c
> @@ -38,7 +38,7 @@ static void rrpc_page_invalidate(struct rrpc *rrpc, struct 
> rrpc_addr *a)
>  
>   spin_lock(>lock);
>  
> - div_u64_rem(a->addr, rrpc->dev->pgs_per_blk, _offset);
> + div_u64_rem(a->addr, rrpc->dev->sec_per_blk, _offset);
>   WARN_ON(test_and_set_bit(pg_offset, rblk->invalid_pages));
>   rblk->nr_invalid_pages++;
>  
> @@ -113,14 +113,24 @@ static void rrpc_discard(struct rrpc *rrpc, struct bio 
> *bio)
>  
>  static int block_is_full(struct rrpc *rrpc, struct rrpc_block *rblk)
>  {
> - return (rblk->next_page == rrpc->dev->pgs_per_blk);
> + return (rblk->next_page == rrpc->dev->sec_per_blk);
>  }
>  
> +/* Calculate relative addr for the given block, considering instantiated 
> LUNs */
> +static u64 block_to_rel_addr(struct rrpc *rrpc, struct rrpc_block *rblk)
> +{
> + struct nvm_block *blk = rblk->parent;
> + int lun_blk = blk->id % (rrpc->dev->blks_per_lun * rrpc->nr_luns);
> +
> + return lun_blk * rrpc->dev->sec_per_blk;
> +}
> +
> +/* Calculate global addr for the given block */
>  static u64 block_to_addr(struct rrpc *rrpc, struct rrpc_block *rblk)
>  {
>   struct nvm_block *blk = rblk->parent;
>  
> - return blk->id * rrpc->dev->pgs_per_blk;
> + return blk->id * rrpc->dev->sec_per_blk;
>  }
>  
>  static struct ppa_addr linear_to_generic_addr(struct nvm_dev *dev,
> @@ -136,7 +146,7 @@ static struct ppa_addr linear_to_generic_addr(struct 
> nvm_dev *dev,
>   l.g.sec = secs;
>  
>   sector_div(ppa, dev->sec_per_pg);
> - div_u64_rem(ppa, dev->sec_per_blk, );
> + div_u64_rem(ppa, dev->pgs_per_blk, );
>   l.g.pg = pgs;
>  
>   sector_div(ppa, dev->pgs_per_blk);
> @@ -191,12 +201,12 @@ static struct rrpc_block *rrpc_get_blk(struct rrpc 
> *rrpc, struct rrpc_lun *rlun,
>   return NULL;
>   }
>  
> - rblk = >blocks[blk->id];
> + rblk = rrpc_get_rblk(rlun, blk->id);
>   list_add_tail(>list, >open_list);
>   spin_unlock(>lock);
>  
>   blk->priv = rblk;
> - bitmap_zero(rblk->invalid_pages, rrpc->dev->pgs_per_blk);
> + bitmap_zero(rblk->invalid_pages, rrpc->dev->sec_per_blk);
>   rblk->next_page = 0;
>   rblk->nr_invalid_pages = 0;
>   atomic_set(>data_cmnt_size, 0);
> @@ -286,11 +296,11 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, 
> struct rrpc_block *rblk)
>   struct bio *bio;
>   struct page *page;
>   int slot;
> - int nr_pgs_per_blk = rrpc->dev->pgs_per_blk;
> + int nr_sec_per_blk = rrpc->dev->sec_per_blk;
>   u64 phys_addr;
>   DECLARE_COMPLETION_ONSTACK(wait);
>  
> - if (bitmap_full(rblk->invalid_pages, nr_pgs_per_blk))
> + if (bitmap_full(rblk->invalid_pages, nr_sec_per_blk))
>   return 0;
>  
>   bio = bio_alloc(GFP_NOIO, 1);
> @@ -306,10 +316,10 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, 
> struct rrpc_block *rblk)
>   }
>  
>   while ((slot = find_first_zero_bit(rblk->invalid_pages,
> - nr_pgs_per_blk)) < nr_pgs_per_blk) {
> + nr_sec_per_blk)) < nr_sec_per_blk) {
>  
>   /* Lock laddr */
> - phys_addr = (rblk->parent->id * nr_pgs_per_blk) + slot;
> + phys_addr = rblk->parent->id * nr_sec_per_blk + slot;
>  
>  try:
>   spin_lock(>rev_lock);
> @@ -381,7 +391,7 @@ finished:
>   mempool_free(page, rrpc->page_pool);
>   bio_put(bio);
>  
> - if (!bitmap_full(rblk->invalid_pages, nr_pgs_per_blk)) {
> + if (!bitmap_full(rblk->invalid_pages, nr_sec_per_blk)) {
>   pr_err("nvm: failed to garbage collect block\n");
>   return -EIO;
>   }
> @@ -677,7 +687,7 @@ static void rrpc_end_io_write(struct rrpc *rrpc, struct 
> rrpc_rq *rrqd,
>   lun = rblk->parent->lun;
>  
>   cmnt_size = atomic_inc_return(>data_cmnt_size);
> -  

Re: [PATCH] lightnvm: generalize rrpc ppa calculations

[Matias Bjørling]

On 02/17/2016 12:00 PM, Javier González wrote:
> In rrpc, some calculations assume a certain configuration (e.g., 1 LUN,
> 1 sector per page). The reason behind this was that we have used a simple
> configuration in QEMU to test core features generally in LightNVM, and
> concretely in rrpc. This patch relaxes these assumptions and generalizes
> calculations in order to support real hardware. Note that more complex
> configurations in QEMU, that allow to simulate this hardware, are also
> pushed into the qemu-nvme repository implementing LightNVM support,
> available under the Open-Channel SSD project in github [1].
> 
> [1] https://github.com/OpenChannelSSD/qemu-nvme
> 
> Signed-off-by: Javier González 
> ---
>  drivers/lightnvm/rrpc.c | 45 -
>  drivers/lightnvm/rrpc.h |  9 +
>  2 files changed, 37 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
> index 775bf6c2..f366c78 100644
> --- a/drivers/lightnvm/rrpc.c
> +++ b/drivers/lightnvm/rrpc.c
> @@ -38,7 +38,7 @@ static void rrpc_page_invalidate(struct rrpc *rrpc, struct 
> rrpc_addr *a)
>  
>   spin_lock(>lock);
>  
> - div_u64_rem(a->addr, rrpc->dev->pgs_per_blk, _offset);
> + div_u64_rem(a->addr, rrpc->dev->sec_per_blk, _offset);
>   WARN_ON(test_and_set_bit(pg_offset, rblk->invalid_pages));
>   rblk->nr_invalid_pages++;
>  
> @@ -113,14 +113,24 @@ static void rrpc_discard(struct rrpc *rrpc, struct bio 
> *bio)
>  
>  static int block_is_full(struct rrpc *rrpc, struct rrpc_block *rblk)
>  {
> - return (rblk->next_page == rrpc->dev->pgs_per_blk);
> + return (rblk->next_page == rrpc->dev->sec_per_blk);
>  }
>  
> +/* Calculate relative addr for the given block, considering instantiated 
> LUNs */
> +static u64 block_to_rel_addr(struct rrpc *rrpc, struct rrpc_block *rblk)
> +{
> + struct nvm_block *blk = rblk->parent;
> + int lun_blk = blk->id % (rrpc->dev->blks_per_lun * rrpc->nr_luns);
> +
> + return lun_blk * rrpc->dev->sec_per_blk;
> +}
> +
> +/* Calculate global addr for the given block */
>  static u64 block_to_addr(struct rrpc *rrpc, struct rrpc_block *rblk)
>  {
>   struct nvm_block *blk = rblk->parent;
>  
> - return blk->id * rrpc->dev->pgs_per_blk;
> + return blk->id * rrpc->dev->sec_per_blk;
>  }
>  
>  static struct ppa_addr linear_to_generic_addr(struct nvm_dev *dev,
> @@ -136,7 +146,7 @@ static struct ppa_addr linear_to_generic_addr(struct 
> nvm_dev *dev,
>   l.g.sec = secs;
>  
>   sector_div(ppa, dev->sec_per_pg);
> - div_u64_rem(ppa, dev->sec_per_blk, );
> + div_u64_rem(ppa, dev->pgs_per_blk, );
>   l.g.pg = pgs;
>  
>   sector_div(ppa, dev->pgs_per_blk);
> @@ -191,12 +201,12 @@ static struct rrpc_block *rrpc_get_blk(struct rrpc 
> *rrpc, struct rrpc_lun *rlun,
>   return NULL;
>   }
>  
> - rblk = >blocks[blk->id];
> + rblk = rrpc_get_rblk(rlun, blk->id);
>   list_add_tail(>list, >open_list);
>   spin_unlock(>lock);
>  
>   blk->priv = rblk;
> - bitmap_zero(rblk->invalid_pages, rrpc->dev->pgs_per_blk);
> + bitmap_zero(rblk->invalid_pages, rrpc->dev->sec_per_blk);
>   rblk->next_page = 0;
>   rblk->nr_invalid_pages = 0;
>   atomic_set(>data_cmnt_size, 0);
> @@ -286,11 +296,11 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, 
> struct rrpc_block *rblk)
>   struct bio *bio;
>   struct page *page;
>   int slot;
> - int nr_pgs_per_blk = rrpc->dev->pgs_per_blk;
> + int nr_sec_per_blk = rrpc->dev->sec_per_blk;
>   u64 phys_addr;
>   DECLARE_COMPLETION_ONSTACK(wait);
>  
> - if (bitmap_full(rblk->invalid_pages, nr_pgs_per_blk))
> + if (bitmap_full(rblk->invalid_pages, nr_sec_per_blk))
>   return 0;
>  
>   bio = bio_alloc(GFP_NOIO, 1);
> @@ -306,10 +316,10 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, 
> struct rrpc_block *rblk)
>   }
>  
>   while ((slot = find_first_zero_bit(rblk->invalid_pages,
> - nr_pgs_per_blk)) < nr_pgs_per_blk) {
> + nr_sec_per_blk)) < nr_sec_per_blk) {
>  
>   /* Lock laddr */
> - phys_addr = (rblk->parent->id * nr_pgs_per_blk) + slot;
> + phys_addr = rblk->parent->id * nr_sec_per_blk + slot;
>  
>  try:
>   spin_lock(>rev_lock);
> @@ -381,7 +391,7 @@ finished:
>   mempool_free(page, rrpc->page_pool);
>   bio_put(bio);
>  
> - if (!bitmap_full(rblk->invalid_pages, nr_pgs_per_blk)) {
> + if (!bitmap_full(rblk->invalid_pages, nr_sec_per_blk)) {
>   pr_err("nvm: failed to garbage collect block\n");
>   return -EIO;
>   }
> @@ -677,7 +687,7 @@ static void rrpc_end_io_write(struct rrpc *rrpc, struct 
> rrpc_rq *rrqd,
>   lun = rblk->parent->lun;
>  
>   cmnt_size = atomic_inc_return(>data_cmnt_size);
> - if 

[PATCH v2] serial: xuartps: Enable OF earlycon support

[Michal Simek]

Support early console setup via DT for all listed compatible strings.
Remove EARLYCON_DECLARE which was done by:
"Use common framework for earlycon declarations"
(sha1: 2eaa790989e03900298ad24f77f1086dbbc1aebd)
when OF_EARLYCON_DECLARE is defined.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Separate serial patch from others
- Remove EARLYCON_DECLARE and use the same earlycon name with different
  compatible string as was pointed by Peter Hurley
- Extend commit message

 drivers/tty/serial/xilinx_uartps.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 131a3117fbbb..cd46e64c4255 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1077,7 +1077,9 @@ static int __init cdns_early_console_setup(struct 
earlycon_device *device,
 
return 0;
 }
-EARLYCON_DECLARE(cdns, cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);
 
 /**
  * cdns_uart_console_write - perform write operation
-- 
1.9.1

[PATCH v2] serial: xuartps: Enable OF earlycon support

[Michal Simek]

Support early console setup via DT for all listed compatible strings.
Remove EARLYCON_DECLARE which was done by:
"Use common framework for earlycon declarations"
(sha1: 2eaa790989e03900298ad24f77f1086dbbc1aebd)
when OF_EARLYCON_DECLARE is defined.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Separate serial patch from others
- Remove EARLYCON_DECLARE and use the same earlycon name with different
  compatible string as was pointed by Peter Hurley
- Extend commit message

 drivers/tty/serial/xilinx_uartps.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index 131a3117fbbb..cd46e64c4255 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1077,7 +1077,9 @@ static int __init cdns_early_console_setup(struct 
earlycon_device *device,
 
return 0;
 }
-EARLYCON_DECLARE(cdns, cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);
 
 /**
  * cdns_uart_console_write - perform write operation
-- 
1.9.1

Re: [PATCH] ovl: fix working on distributed fs as lower layer

[Nikolay Borisov]

On 01/31/2016 03:22 PM, Konstantin Khlebnikov wrote:
> This adds missing .d_select_inode into alternative dentry_operations.
> 
> Signed-off-by: Konstantin Khlebnikov 
> Fixes: 7c03b5d45b8e ("ovl: allow distributed fs as lower layer")
> Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and 
> f_inode to the underlay")
> ---
>  fs/overlayfs/super.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index e6ae59c7119c..1a354840f262 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -343,6 +343,7 @@ static const struct dentry_operations 
> ovl_dentry_operations = {
>  
>  static const struct dentry_operations ovl_reval_dentry_operations = {
>   .d_release = ovl_dentry_release,
> + .d_select_inode = ovl_d_select_inode,
>   .d_revalidate = ovl_dentry_revalidate,
>   .d_weak_revalidate = ovl_dentry_weak_revalidate,
>  };

I wish I had seen this patch earlier than
https://marc.info/?l=linux-unionfs=145494313009959


Reviewed-by: Nikolay Borisov 
Tested-by: Nikolay Borisov 

Re: [PATCH] ovl: fix working on distributed fs as lower layer

[Nikolay Borisov]

On 01/31/2016 03:22 PM, Konstantin Khlebnikov wrote:
> This adds missing .d_select_inode into alternative dentry_operations.
> 
> Signed-off-by: Konstantin Khlebnikov 
> Fixes: 7c03b5d45b8e ("ovl: allow distributed fs as lower layer")
> Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and 
> f_inode to the underlay")
> ---
>  fs/overlayfs/super.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index e6ae59c7119c..1a354840f262 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -343,6 +343,7 @@ static const struct dentry_operations 
> ovl_dentry_operations = {
>  
>  static const struct dentry_operations ovl_reval_dentry_operations = {
>   .d_release = ovl_dentry_release,
> + .d_select_inode = ovl_d_select_inode,
>   .d_revalidate = ovl_dentry_revalidate,
>   .d_weak_revalidate = ovl_dentry_weak_revalidate,
>  };

I wish I had seen this patch earlier than
https://marc.info/?l=linux-unionfs=145494313009959


Reviewed-by: Nikolay Borisov 
Tested-by: Nikolay Borisov 

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

[Yakir Yang]

Hi Mark,

Thanks for your apply ;)

- Yakir

On 02/18/2016 02:12 PM, Mark yao wrote:

On 2016年01月29日 14:42, Yakir Yang wrote:

Here are a brief introduction to Innosilicon HDMI IP:
   - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant 
transmitter

   - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
   - Digital video interface supports a pixel size of 24, 30, 36, 
48bits color depth in RGB
   - S/PDIF output supports PCM, Dolby Digital, DTS digital audio 
transmission

 (32-192kHz Fs) using IEC60958 and IEC 61937
   - The EDID and CEC function are also supported by Innosilicon HDMI 
Transmitter Controlle


Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause 
driver

   default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() 
(ZhengYang)

 - if (data->enc_out_format == data->enc_out_format) {
 + if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
  - MODULE_LICENSE("GPL");
  + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's 
rockchip-mipi driver (Caeser)


Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc 
transfer (Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" 
function (Russell)


Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop 
mode

configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS 
function

- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

Yakir Yang (2):
   drm/rockchip: hdmi: add Innosilicon HDMI support
   dt-bindings: add document for Innosilicon HDMI on Rockchip platform

  .../display/rockchip/inno_hdmi-rockchip.txt|  50 ++
  drivers/gpu/drm/rockchip/Kconfig   |   8 +
  drivers/gpu/drm/rockchip/Makefile  |   1 +
  drivers/gpu/drm/rockchip/inno_hdmi.c   | 939 
+

  drivers/gpu/drm/rockchip/inno_hdmi.h   | 362 
  5 files changed, 1360 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt

  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h



Applied to my branch :-) .

Thanks.

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

[Yakir Yang]

Hi Mark,

Thanks for your apply ;)

- Yakir

On 02/18/2016 02:12 PM, Mark yao wrote:

On 2016年01月29日 14:42, Yakir Yang wrote:

Here are a brief introduction to Innosilicon HDMI IP:
   - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant 
transmitter

   - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
   - Digital video interface supports a pixel size of 24, 30, 36, 
48bits color depth in RGB
   - S/PDIF output supports PCM, Dolby Digital, DTS digital audio 
transmission

 (32-192kHz Fs) using IEC60958 and IEC 61937
   - The EDID and CEC function are also supported by Innosilicon HDMI 
Transmitter Controlle


Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause 
driver

   default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() 
(ZhengYang)

 - if (data->enc_out_format == data->enc_out_format) {
 + if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
  - MODULE_LICENSE("GPL");
  + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's 
rockchip-mipi driver (Caeser)


Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc 
transfer (Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" 
function (Russell)


Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop 
mode

configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS 
function

- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

Yakir Yang (2):
   drm/rockchip: hdmi: add Innosilicon HDMI support
   dt-bindings: add document for Innosilicon HDMI on Rockchip platform

  .../display/rockchip/inno_hdmi-rockchip.txt|  50 ++
  drivers/gpu/drm/rockchip/Kconfig   |   8 +
  drivers/gpu/drm/rockchip/Makefile  |   1 +
  drivers/gpu/drm/rockchip/inno_hdmi.c   | 939 
+

  drivers/gpu/drm/rockchip/inno_hdmi.h   | 362 
  5 files changed, 1360 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt

  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h



Applied to my branch :-) .

Thanks.

письмо от Екатерины

[Крылова Дарья]

Приветствую Вас.

У Вас нет заказов,  телефоны молчат?

Есть от всего этого отличное средство - наш сервис поиска клиентов.

Обращайтесь не стесняйтесь 796 11 363521

письмо от Екатерины

[Крылова Дарья]

Приветствую Вас.

У Вас нет заказов,  телефоны молчат?

Есть от всего этого отличное средство - наш сервис поиска клиентов.

Обращайтесь не стесняйтесь 796 11 363521

Re: [patch 07/11] x86/perf/uncore: Track packages not per cpu data

[Ingo Molnar]

* Andi Kleen  wrote:

> > Do you have any data to back that up or is that just "believe" ?
> 
> I've seen systems with discontiguous apic ids before.
> 
> It is obvious if you consider setups with node hotplug.
> 
> BTW reading this thread you don't seem interested in any code review 
> feedback, 
> attacking everyone, [...]

I've not seen Thomas attack anyone in this thread - I've seen him getting 
rightfully grumpy at sub-par code quality of the Intel uncore driver...

> [...] not bothering to look up data sheets, not understanding the hardware 
> you're changing the driver for, etc. Why do you even bother to post the 
> patches?

Stop these personal attacks and stop insulting people why try to clean up the 
mess 
you made of a driver!

Thomas found real bugs in the driver and presented a much cleaner model for 
representing uncore PMUs, which results in nice simplifications:

   2 files changed, 139 insertions(+), 220 deletions(-)

if these changes survive review and testing then they are very much 'worth it', 
and that fact should be apparent to you as well.

Thanks,

Ingo

Re: [patch 07/11] x86/perf/uncore: Track packages not per cpu data

[Ingo Molnar]

* Andi Kleen  wrote:

> > Do you have any data to back that up or is that just "believe" ?
> 
> I've seen systems with discontiguous apic ids before.
> 
> It is obvious if you consider setups with node hotplug.
> 
> BTW reading this thread you don't seem interested in any code review 
> feedback, 
> attacking everyone, [...]

I've not seen Thomas attack anyone in this thread - I've seen him getting 
rightfully grumpy at sub-par code quality of the Intel uncore driver...

> [...] not bothering to look up data sheets, not understanding the hardware 
> you're changing the driver for, etc. Why do you even bother to post the 
> patches?

Stop these personal attacks and stop insulting people why try to clean up the 
mess 
you made of a driver!

Thomas found real bugs in the driver and presented a much cleaner model for 
representing uncore PMUs, which results in nice simplifications:

   2 files changed, 139 insertions(+), 220 deletions(-)

if these changes survive review and testing then they are very much 'worth it', 
and that fact should be apparent to you as well.

Thanks,

Ingo

Re: [PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems

[Ohad Ben-Cohen]

On Sun, Feb 14, 2016 at 3:35 AM, Bjorn Andersson
 wrote:
>
> Add myself as co-maintainer for the remote processor related subsystems,
> as agreed with Ohad.
>
> Signed-off-by: Bjorn Andersson 

Thank you Bjorn for the help!

Acked-by: Ohad Ben-Cohen 

> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4ebe2e886d36..f51056b02fcd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4989,6 +4989,7 @@ F:include/linux/hw_random.h
>
>  HARDWARE SPINLOCK CORE
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  S: Maintained
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
>  F: Documentation/hwspinlock.txt
> @@ -9170,6 +9171,7 @@ F:include/linux/regmap.h
>
>  REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
>  S: Maintained
>  F: drivers/remoteproc/
> @@ -9178,6 +9180,7 @@ F:include/linux/remoteproc.h
>
>  REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
>  S: Maintained
>  F: drivers/rpmsg/
> --
> 2.5.0
>

Re: [PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems

[Ohad Ben-Cohen]

On Sun, Feb 14, 2016 at 3:35 AM, Bjorn Andersson
 wrote:
>
> Add myself as co-maintainer for the remote processor related subsystems,
> as agreed with Ohad.
>
> Signed-off-by: Bjorn Andersson 

Thank you Bjorn for the help!

Acked-by: Ohad Ben-Cohen 

> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4ebe2e886d36..f51056b02fcd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4989,6 +4989,7 @@ F:include/linux/hw_random.h
>
>  HARDWARE SPINLOCK CORE
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  S: Maintained
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
>  F: Documentation/hwspinlock.txt
> @@ -9170,6 +9171,7 @@ F:include/linux/regmap.h
>
>  REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
>  S: Maintained
>  F: drivers/remoteproc/
> @@ -9178,6 +9180,7 @@ F:include/linux/remoteproc.h
>
>  REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
>  M: Ohad Ben-Cohen 
> +M: Bjorn Andersson 
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
>  S: Maintained
>  F: drivers/rpmsg/
> --
> 2.5.0
>

Re: [RFC][PATCH 12/12] perf: Collapse and fix event_function_call() users

[Peter Zijlstra]

On Wed, Feb 17, 2016 at 05:38:43PM -0500, Sasha Levin wrote:
> Hey Peter,
> 
> I seem to be hitting a warning added by this patch:
> 
> [  258.890172] WARNING: CPU: 5 PID: 14801 at kernel/events/core.c:226 
> event_function+0x3a7/0x550()

Yes, I've been chasing this one for the past few days.

I have a bunch of traces that make absolutely no sense what so ever, and
a patch that appears to make it go away, but I'm not confident.

I'll cleanup and share what I have.

Re: [RFC][PATCH 12/12] perf: Collapse and fix event_function_call() users

[Peter Zijlstra]

On Wed, Feb 17, 2016 at 05:38:43PM -0500, Sasha Levin wrote:
> Hey Peter,
> 
> I seem to be hitting a warning added by this patch:
> 
> [  258.890172] WARNING: CPU: 5 PID: 14801 at kernel/events/core.c:226 
> event_function+0x3a7/0x550()

Yes, I've been chasing this one for the past few days.

I have a bunch of traces that make absolutely no sense what so ever, and
a patch that appears to make it go away, but I'm not confident.

I'll cleanup and share what I have.

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

[Joonsoo Kim]

2016-02-16 10:16 GMT+09:00 Steven Rostedt :
> On Tue, 16 Feb 2016 09:47:20 +0900
> Joonsoo Kim  wrote:
>
>> > They return true when CONFIG_TRACEPOINTS is configured in and the
>> > tracepoint is enabled, and false otherwise.
>>
>> This implementation is what you proposed before. Please refer below
>> link and source.
>>
>> https://lkml.org/lkml/2015/12/9/699
>> arch/x86/include/asm/msr.h
>
> That was a year ago, how am I suppose to remember ;-)

I think you are smart enough to remember. :)
I will add it on commit description on next spin.

>>
>> There is header file dependency problem between mm.h and tracepoint.h.
>> page_ref.h should be included in mm.h and tracepoint.h cannot
>> be included in this case.
>
> Ah, OK, I forgot about that. I'll take another look at it again.
>
> A lot happened since then, that's all a fog to me.

Okay. Please let me know result of another look.

Thanks.

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

[Joonsoo Kim]

2016-02-16 10:16 GMT+09:00 Steven Rostedt :
> On Tue, 16 Feb 2016 09:47:20 +0900
> Joonsoo Kim  wrote:
>
>> > They return true when CONFIG_TRACEPOINTS is configured in and the
>> > tracepoint is enabled, and false otherwise.
>>
>> This implementation is what you proposed before. Please refer below
>> link and source.
>>
>> https://lkml.org/lkml/2015/12/9/699
>> arch/x86/include/asm/msr.h
>
> That was a year ago, how am I suppose to remember ;-)

I think you are smart enough to remember. :)
I will add it on commit description on next spin.

>>
>> There is header file dependency problem between mm.h and tracepoint.h.
>> page_ref.h should be included in mm.h and tracepoint.h cannot
>> be included in this case.
>
> Ah, OK, I forgot about that. I'll take another look at it again.
>
> A lot happened since then, that's all a fog to me.

Okay. Please let me know result of another look.

Thanks.

Re: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

[Keerthy]

Hi Paul,

On Thursday 18 February 2016 12:12 PM, Paul Walmsley wrote:

Hi Keerthy

On Thu, 18 Feb 2016, Keerthy wrote:


The patch adds rtc hwmod. RTC module The RTC module is physically
present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
disabled. A secure RTC is used instead on these devices, where needed.
. Hence adding it selectively using a seprate list to get RTC Module
functional on the other am43x SoCs used on am437x-gp-evm and
am437x-sk-evm.

Signed-off-by: Keerthy 
---

No Public TRM is available for AM438x SoC as of now.

  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894..fcffaf8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
__initdata = {
NULL,
  };

+static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
+   _l4_wkup__rtc,
+   NULL,
+};
+
  int __init am43xx_hwmod_init(void)
  {
+   int ret;
+
omap_hwmod_am43xx_reg();
omap_hwmod_init();
-   return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+   ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+
+   if (!(of_machine_is_compatible("ti,am438x")))
+   ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
+
+   return ret;
  }


Could you please invert the test of this case such that the RTC hwmod is
only registered on AM43xx SoCs where it is specifically known to be
enabled?

That way, if another AM43xx SoC comes out that doesn't have the RTC
module, it won't inadvertently be registered.  This seems like a safer
approach.


I get your point but currently only am438x SoC has RTC disabled forever.
So i checked negating am438x. I can add a check with am4372 here and 
register for only those SoCs.


I will resend a v2 in a while.

Thanks for the quick response.

Best Regards,
Keerthy



- Paul

Re: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

[Keerthy]

Hi Paul,

On Thursday 18 February 2016 12:12 PM, Paul Walmsley wrote:

Hi Keerthy

On Thu, 18 Feb 2016, Keerthy wrote:


The patch adds rtc hwmod. RTC module The RTC module is physically
present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
disabled. A secure RTC is used instead on these devices, where needed.
. Hence adding it selectively using a seprate list to get RTC Module
functional on the other am43x SoCs used on am437x-gp-evm and
am437x-sk-evm.

Signed-off-by: Keerthy 
---

No Public TRM is available for AM438x SoC as of now.

  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894..fcffaf8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
__initdata = {
NULL,
  };

+static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
+   _l4_wkup__rtc,
+   NULL,
+};
+
  int __init am43xx_hwmod_init(void)
  {
+   int ret;
+
omap_hwmod_am43xx_reg();
omap_hwmod_init();
-   return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+   ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+
+   if (!(of_machine_is_compatible("ti,am438x")))
+   ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
+
+   return ret;
  }


Could you please invert the test of this case such that the RTC hwmod is
only registered on AM43xx SoCs where it is specifically known to be
enabled?

That way, if another AM43xx SoC comes out that doesn't have the RTC
module, it won't inadvertently be registered.  This seems like a safer
approach.


I get your point but currently only am438x SoC has RTC disabled forever.
So i checked negating am438x. I can add a check with am4372 here and 
register for only those SoCs.


I will resend a v2 in a while.

Thanks for the quick response.

Best Regards,
Keerthy



- Paul

[PATCH v3 1/1] ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list

[John Dahlstrom]

Some Lenovo ideapad models lack a physical rfkill switch.
On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK,
ideapad-laptop would wrongly report all radios as blocked by
hardware which caused wireless network connections to fail.

Add these models without an rfkill switch to the no_hw_rfkill list.

Signed-off-by: John Dahlstrom 
Cc: 
---
 Relevant kernel versions: 4.5-rc4, 4.4.2, 4.3.5, 4.1.18, 3.18.27

 Test configuration
  Hardware: Lenovo ideapad Y700 Touch-15ISK
  Kernel version: 4.4.2

 Patch changelog
  v2 split patch between Touch and non-Touch devices
  v3 undo patch split and limit summary to 72 characters

 drivers/platform/x86/ideapad-laptop.c |   14 ++
 1 file changed, 14 insertions(+)

--- a/drivers/platform/x86/ideapad-laptop.c 2016-02-14 15:05:20.0 
-0600
+++ b/drivers/platform/x86/ideapad-laptop.c 2016-02-16 03:54:48.484423725 
-0600
@@ -864,4 +864,18 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo G50-30"),
},
+   },
+   {
+   .ident = "Lenovo ideapad Y700-15ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
Y700-15ISK"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad Y700 Touch-15ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700 
Touch-15ISK"),
+   },
},
{

[PATCH v3 1/1] ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list

[John Dahlstrom]

Some Lenovo ideapad models lack a physical rfkill switch.
On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK,
ideapad-laptop would wrongly report all radios as blocked by
hardware which caused wireless network connections to fail.

Add these models without an rfkill switch to the no_hw_rfkill list.

Signed-off-by: John Dahlstrom 
Cc: 
---
 Relevant kernel versions: 4.5-rc4, 4.4.2, 4.3.5, 4.1.18, 3.18.27

 Test configuration
  Hardware: Lenovo ideapad Y700 Touch-15ISK
  Kernel version: 4.4.2

 Patch changelog
  v2 split patch between Touch and non-Touch devices
  v3 undo patch split and limit summary to 72 characters

 drivers/platform/x86/ideapad-laptop.c |   14 ++
 1 file changed, 14 insertions(+)

--- a/drivers/platform/x86/ideapad-laptop.c 2016-02-14 15:05:20.0 
-0600
+++ b/drivers/platform/x86/ideapad-laptop.c 2016-02-16 03:54:48.484423725 
-0600
@@ -864,4 +864,18 @@ static const struct dmi_system_id no_hw_rfkill_list[] = {
DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo G50-30"),
},
+   },
+   {
+   .ident = "Lenovo ideapad Y700-15ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
Y700-15ISK"),
+   },
+   },
+   {
+   .ident = "Lenovo ideapad Y700 Touch-15ISK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad Y700 
Touch-15ISK"),
+   },
},
{

Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure()

[Hannes Reinecke]

On 02/16/2016 05:56 PM, John Garry wrote:
> On 16/02/2016 15:33, Hannes Reinecke wrote:
>> On 02/16/2016 01:22 PM, John Garry wrote:
>>> In high-datarate aging tests, it is found that
>>> the SCSI framework can periodically
>>> issue lu resets to the device. This is because scsi
>>> commands begin to timeout. It is found that TASK SET
>>> FULL may be returned many times for the same command,
>>> causing the timeouts.
>>> To overcome this, the queue depth for the device needs
>>> to be reduced to 64 (from 256, set in
>>> sas_slave_configure()).
>>>
>> Hmm. TASK SET FULL should cause the queue depth to be reduced
>> automatically, no?
>>
>> Cheers,
>>
>> Hannes
>>
> 
> I need to double-check if Task set full reduces the depth, I don't
> think it does.
> 
> Regardless I found we were getting a combination of commands being
> retried due to Task Set Full and also SAS_QUEUE_FULL errors. For
> sure the SAS_QUEUE_FULL task errors reduce the queue depth in
> scsi_track_queue_full(). However I found it to be very slow in
> tracking, and we were getting commands timing out before the queue
> depth fell enough.
> 
> It would be nice to change default queue depth in
> sas_slave_configure() to a lower value so we can avoid this patch,
> but I am not sure if other vendor's HBA performance would be
> affected. From looking at the history of sas_slave_configure(), it
> would seem the value of 256 was inherited from mpt2sas driver, so
> I'm not sure.
> 
Well, the classical thing would be to associate each request tag
with a SAS task; or, in your case, associate each slot index with a
request tag.
You probably would need to reserve some slots for TMFs, ie you'd
need to decrease the resulting ->can_queue variable by that.
But once you've done that you shouldn't hit any QUEUE_FULL issues,
as the block layer will ensure that no tags will be reused while the
command is in flight.
Plus this is something you really need to be doing if you ever
consider moving to scsi-mq ...

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 5/6] hisi_sas: add hisi_sas_slave_configure()

[Hannes Reinecke]

On 02/16/2016 05:56 PM, John Garry wrote:
> On 16/02/2016 15:33, Hannes Reinecke wrote:
>> On 02/16/2016 01:22 PM, John Garry wrote:
>>> In high-datarate aging tests, it is found that
>>> the SCSI framework can periodically
>>> issue lu resets to the device. This is because scsi
>>> commands begin to timeout. It is found that TASK SET
>>> FULL may be returned many times for the same command,
>>> causing the timeouts.
>>> To overcome this, the queue depth for the device needs
>>> to be reduced to 64 (from 256, set in
>>> sas_slave_configure()).
>>>
>> Hmm. TASK SET FULL should cause the queue depth to be reduced
>> automatically, no?
>>
>> Cheers,
>>
>> Hannes
>>
> 
> I need to double-check if Task set full reduces the depth, I don't
> think it does.
> 
> Regardless I found we were getting a combination of commands being
> retried due to Task Set Full and also SAS_QUEUE_FULL errors. For
> sure the SAS_QUEUE_FULL task errors reduce the queue depth in
> scsi_track_queue_full(). However I found it to be very slow in
> tracking, and we were getting commands timing out before the queue
> depth fell enough.
> 
> It would be nice to change default queue depth in
> sas_slave_configure() to a lower value so we can avoid this patch,
> but I am not sure if other vendor's HBA performance would be
> affected. From looking at the history of sas_slave_configure(), it
> would seem the value of 256 was inherited from mpt2sas driver, so
> I'm not sure.
> 
Well, the classical thing would be to associate each request tag
with a SAS task; or, in your case, associate each slot index with a
request tag.
You probably would need to reserve some slots for TMFs, ie you'd
need to decrease the resulting ->can_queue variable by that.
But once you've done that you shouldn't hit any QUEUE_FULL issues,
as the block layer will ensure that no tags will be reused while the
command is in flight.
Plus this is something you really need to be doing if you ever
consider moving to scsi-mq ...

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: call_usermodehelper in containers

[Ian Kent]

On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote:
> On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote:
> > On 2016/02/18 11:57, Eric W. Biederman wrote:
> > > 
> > > Ccing The containers list because a related discussion is
> > > happening
> > > there
> > > and somehow this thread has never made it there.
> > > 
> > > Ian Kent  writes:
> > > 
> > > > On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote:
> > > > > On 11/15, Eric W. Biederman wrote:
> > > > > > 
> > > > > > I don't understand that one.  Having a preforked thread with
> > > > > > the
> > > > > > proper
> > > > > > environment that can act like kthreadd in terms of spawning
> > > > > > user
> > > > > > mode
> > > > > > helpers works and is simple.
> > > > 
> > > > Forgive me replying to such an old thread but ...
> > > > 
> > > > After realizing workqueues can't be used to pre-create threads
> > > > to
> > > > run
> > > > usermode helpers I've returned to look at this.
> > > 
> > > If someone can wind up with a good implementation I will be happy.
> > > 
> > > > > Can't we ask ->child_reaper to create the non-daemonized
> > > > > kernel
> > > > > thread
> > > > > with the "right" ->nsproxy, ->fs, etc?
> > > > 
> > > > Eric, do you think this approach would be sufficient too?
> > > > 
> > > > Probably wouldn't be quite right for user namespaces but should
> > > > provide
> > > > what's needed for other cases?
> > > > 
> > > > It certainly has the advantage of not having to maintain a
> > > > plague
> > > > of
> > > > processes waiting around to execute helpers.
> > > 
> > > That certainly sounds attractive.  Especially for the case of
> > > everyone
> > > who wants to set a core pattern in a container.
> > > 
> > > I am fuzzy on all of the details right now, but what I do remember
> > > is
> > > that in the kernel the user mode helper concepts when they
> > > attempted
> > > to
> > > scrub a processes environment were quite error prone until we
> > > managed to
> > > get kthreadd(pid 2) on the scene which always had a clean
> > > environment.
> > > 
> > > If we are going to tie this kind of thing to the pid namespace I
> > > recommend simplying denying it if you are in a user namespace
> > > without
> > > an approrpriate pid namespace.  AKA simply not allowing thigns to
> > > be
> > > setup
> > > if current->pid_ns->user_ns != current->user_ns.
> > > 
> > Can't be handled by simple capability like CAP_SYS_USERMODEHELPER ?
> > 
> > User_ns check seems not to allow core-dump-cather in host will not
> > work if user_ns is used.
> 
> I don't think so but I'm not sure.
> 
> The approach I was talking about assumes the init process of the
> caller
> (say within a container, corresponding to ->child_reaper) is an
> appropriate template for umh thread execution.
> 
> But I don't think that covers the case where unshare has created
> different namespaces, like a mount namespace for example.
> 
> The current workqueue sub system can't be used to pre-create a thread
> to
> be used for umh execution so, either is needs changes or yet another
> mechanism needs to be implemented.
> 
> For uses other than core dumping capturing a reference to the struct
> pid
> of the environment init process and using that as an execution
> template
> should be sufficient and takes care of environment existence problems
> with some extra checks, not to mention eliminating the need for a
> potentially huge number of kernel threads needing to be created to
> provide execution templates.
> 
> Where to store this and how to access it when needed is another
> problem.
> 
> Not sure a usermode helper capability is the right thing either as I
> thought one important use of user namespaces was to allow unprivileged
> users to perform operations they otherwise can't.
> 
> Maybe a CAP_SYS_USERNSCOREDUMP or similar would be sensible 
> 
> Still an appropriate execution template would be needed and IIUC we
> can't trust getting that from within a user created namespace
> environment.

Perhaps, if a struct cred could be captured at some appropriate time
that could be used to cater for user namespaces.

Eric, do you think that would be possible to do without allowing users
to circumvent security?

> 
> > 
> > Thanks,
> > -Kame

Re: call_usermodehelper in containers

[Ian Kent]

On Thu, 2016-02-18 at 14:36 +0800, Ian Kent wrote:
> On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote:
> > On 2016/02/18 11:57, Eric W. Biederman wrote:
> > > 
> > > Ccing The containers list because a related discussion is
> > > happening
> > > there
> > > and somehow this thread has never made it there.
> > > 
> > > Ian Kent  writes:
> > > 
> > > > On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote:
> > > > > On 11/15, Eric W. Biederman wrote:
> > > > > > 
> > > > > > I don't understand that one.  Having a preforked thread with
> > > > > > the
> > > > > > proper
> > > > > > environment that can act like kthreadd in terms of spawning
> > > > > > user
> > > > > > mode
> > > > > > helpers works and is simple.
> > > > 
> > > > Forgive me replying to such an old thread but ...
> > > > 
> > > > After realizing workqueues can't be used to pre-create threads
> > > > to
> > > > run
> > > > usermode helpers I've returned to look at this.
> > > 
> > > If someone can wind up with a good implementation I will be happy.
> > > 
> > > > > Can't we ask ->child_reaper to create the non-daemonized
> > > > > kernel
> > > > > thread
> > > > > with the "right" ->nsproxy, ->fs, etc?
> > > > 
> > > > Eric, do you think this approach would be sufficient too?
> > > > 
> > > > Probably wouldn't be quite right for user namespaces but should
> > > > provide
> > > > what's needed for other cases?
> > > > 
> > > > It certainly has the advantage of not having to maintain a
> > > > plague
> > > > of
> > > > processes waiting around to execute helpers.
> > > 
> > > That certainly sounds attractive.  Especially for the case of
> > > everyone
> > > who wants to set a core pattern in a container.
> > > 
> > > I am fuzzy on all of the details right now, but what I do remember
> > > is
> > > that in the kernel the user mode helper concepts when they
> > > attempted
> > > to
> > > scrub a processes environment were quite error prone until we
> > > managed to
> > > get kthreadd(pid 2) on the scene which always had a clean
> > > environment.
> > > 
> > > If we are going to tie this kind of thing to the pid namespace I
> > > recommend simplying denying it if you are in a user namespace
> > > without
> > > an approrpriate pid namespace.  AKA simply not allowing thigns to
> > > be
> > > setup
> > > if current->pid_ns->user_ns != current->user_ns.
> > > 
> > Can't be handled by simple capability like CAP_SYS_USERMODEHELPER ?
> > 
> > User_ns check seems not to allow core-dump-cather in host will not
> > work if user_ns is used.
> 
> I don't think so but I'm not sure.
> 
> The approach I was talking about assumes the init process of the
> caller
> (say within a container, corresponding to ->child_reaper) is an
> appropriate template for umh thread execution.
> 
> But I don't think that covers the case where unshare has created
> different namespaces, like a mount namespace for example.
> 
> The current workqueue sub system can't be used to pre-create a thread
> to
> be used for umh execution so, either is needs changes or yet another
> mechanism needs to be implemented.
> 
> For uses other than core dumping capturing a reference to the struct
> pid
> of the environment init process and using that as an execution
> template
> should be sufficient and takes care of environment existence problems
> with some extra checks, not to mention eliminating the need for a
> potentially huge number of kernel threads needing to be created to
> provide execution templates.
> 
> Where to store this and how to access it when needed is another
> problem.
> 
> Not sure a usermode helper capability is the right thing either as I
> thought one important use of user namespaces was to allow unprivileged
> users to perform operations they otherwise can't.
> 
> Maybe a CAP_SYS_USERNSCOREDUMP or similar would be sensible 
> 
> Still an appropriate execution template would be needed and IIUC we
> can't trust getting that from within a user created namespace
> environment.

Perhaps, if a struct cred could be captured at some appropriate time
that could be used to cater for user namespaces.

Eric, do you think that would be possible to do without allowing users
to circumvent security?

> 
> > 
> > Thanks,
> > -Kame

linux-next: Tree for Feb 18

[Stephen Rothwell]

Hi all,

Changes since 20160217:

The mvebu tree gained a conflict against the arm-soc tree.

The net-next tree gained a build failure so I used the version from
next-20160217.

The crypto tree lost its build failure.

The block tree gained a conflict against Linus' tree.

The char-misc tree gained a conflict against the integrity tree.

The aio tree still had a build failure so I used the version from
next-20160111.

Non-merge commits (relative to Linus' tree): 5361
 4513 files changed, 189566 insertions(+), 85676 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (2850713576e8 Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7)
Merging arm-current/fixes (e972c37459c8 ARM: 8519/1: ICST: try other dividends 
than 1)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (c777e2a8b654 powerpc/mm: Fix Multi hit ERAT cause 
by recent THP update)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (ca0bb0798022 Add sun4v_wdt watchdog driver)
Merging net/master (79be1a1c9090 phy: marvell: Fix and unify reg-init behavior)
Merging ipsec/master (aac8d3c282e0 qmi_wwan: add "4G LTE usb-modem U901")
Merging ipvs/master (848a21e064c1 netfilter: ipvs: handle 
ip_vs_fill_iph_skb_off failure)
Merging wireless-drivers/master (c699404db182 Merge tag 
'iwlwifi-for-kalle-2016-02-15' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (212c5a5e6ba6 mac80211: minstrel: Change expected 
throughput unit back to Kbps)
Merging sound-current/for-linus (13d5e5d4725c ALSA: seq: Fix double port list 
deletion)
Merging pci-current/for-linus (9837da2124c3 Revert "PCI, x86: Implement 
pcibios_alloc_irq() and pcibios_free_irq()")
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (18558cae0272 Linux 4.5-rc4)
Merging usb-gadget-fixes/fixes (6a4290cc28be usb: dwc3: gadget: set the OTG 
flag in dwc3 gadget driver.)
Merging usb-serial-fixes/usb-linus (18558cae0272 Linux 4.5-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (388f7b1d6e8c Linux 4.5-rc3)
Merging char-misc.current/char-misc-linus (18558cae0272 Linux 4.5-rc4)
Merging input-current/for-linus (ff84dabe3c6e Input: colibri-vf50-ts - add 
missing #include )
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs mo

linux-next: Tree for Feb 18

[Stephen Rothwell]

Hi all,

Changes since 20160217:

The mvebu tree gained a conflict against the arm-soc tree.

The net-next tree gained a build failure so I used the version from
next-20160217.

The crypto tree lost its build failure.

The block tree gained a conflict against Linus' tree.

The char-misc tree gained a conflict against the integrity tree.

The aio tree still had a build failure so I used the version from
next-20160111.

Non-merge commits (relative to Linus' tree): 5361
 4513 files changed, 189566 insertions(+), 85676 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (2850713576e8 Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7)
Merging arm-current/fixes (e972c37459c8 ARM: 8519/1: ICST: try other dividends 
than 1)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (c777e2a8b654 powerpc/mm: Fix Multi hit ERAT cause 
by recent THP update)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (ca0bb0798022 Add sun4v_wdt watchdog driver)
Merging net/master (79be1a1c9090 phy: marvell: Fix and unify reg-init behavior)
Merging ipsec/master (aac8d3c282e0 qmi_wwan: add "4G LTE usb-modem U901")
Merging ipvs/master (848a21e064c1 netfilter: ipvs: handle 
ip_vs_fill_iph_skb_off failure)
Merging wireless-drivers/master (c699404db182 Merge tag 
'iwlwifi-for-kalle-2016-02-15' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (212c5a5e6ba6 mac80211: minstrel: Change expected 
throughput unit back to Kbps)
Merging sound-current/for-linus (13d5e5d4725c ALSA: seq: Fix double port list 
deletion)
Merging pci-current/for-linus (9837da2124c3 Revert "PCI, x86: Implement 
pcibios_alloc_irq() and pcibios_free_irq()")
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (18558cae0272 Linux 4.5-rc4)
Merging usb-gadget-fixes/fixes (6a4290cc28be usb: dwc3: gadget: set the OTG 
flag in dwc3 gadget driver.)
Merging usb-serial-fixes/usb-linus (18558cae0272 Linux 4.5-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (388f7b1d6e8c Linux 4.5-rc3)
Merging char-misc.current/char-misc-linus (18558cae0272 Linux 4.5-rc4)
Merging input-current/for-linus (ff84dabe3c6e Input: colibri-vf50-ts - add 
missing #include )
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs mo

Re: [PATCH v8 3/3] tty: 8250_omap: Use software emulated RS485 direction control

[Ильяс Гасанов]

Also, forgot to mention that if serial8250_em485_init is called not
upon uart startup but elsewhere (upon port register for example), and
em485 is set, serial8250_do_startup should call
serial8250_em485_rts_after_send, or else RTS might be in wrong state
whenever the port device is opened, making it impossible to receive
data through RTS-controlled RS232<->RS485 hardware converters.


Regards,
Ilyas G.

Re: [PATCH v8 3/3] tty: 8250_omap: Use software emulated RS485 direction control

[Ильяс Гасанов]

Also, forgot to mention that if serial8250_em485_init is called not
upon uart startup but elsewhere (upon port register for example), and
em485 is set, serial8250_do_startup should call
serial8250_em485_rts_after_send, or else RTS might be in wrong state
whenever the port device is opened, making it impossible to receive
data through RTS-controlled RS232<->RS485 hardware converters.


Regards,
Ilyas G.

RE: [PATCH] PCI: imx6:don't sleep in atomic context

[Sharma, Sanjeev]

-Original Message-
From: Bjorn Helgaas [mailto:helg...@kernel.org] 
Sent: Thursday, January 07, 2016 3:35 AM
To: Sharma, Sanjeev
Cc: richard@freescale.com; l.st...@pengutronix.de; bhelg...@google.com; 
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
linux-kernel@vger.kernel.org; David Mueller
Subject: Re: [PATCH] PCI: imx6:don't sleep in atomic context

Hi Sanjeev,

On Mon, Nov 09, 2015 at 04:18:00PM +0530, Sanjeev Sharma wrote:
> If additional PCIe switch get connected between the host and the 
> NIC,the kernel crashes with "BUG:
> scheduling while atomic". To handle this we need to call mdelay() 
> instead of usleep_range().
> 
> For more detail please refer bugzilla.kernel.org, Bug
> 100031
> 
> Signed-off-by: Sanjeev Sharma 
> Signed-off-by: David Mueller 

I'm dropping this for now because we've been kicking around the same solution 
(with tweaks to the mdelay amount) since June, but no progress on the *real* 
issue, which is that imx6_pcie_link_up() should never wait; it should simply 
return the link status.

I'm pretty sure the amount of time I've spent looking into this would have been 
enough to make some progress on that underlying issue.

Bjorn

Ok ! please share the change you are planning to implement. 

Sanjeev Sharma 
> ---
>  drivers/pci/host/pci-imx6.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c 
> index 233a196..9769b13 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -499,7 +499,7 @@ static int imx6_pcie_link_up(struct pcie_port *pp)
>* Wait a little bit, then re-check if the link finished
>* the training.
>*/
> - usleep_range(1000, 2000);
> + mdelay(1000);
>   }
>   /*
>* From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> --
> 1.7.11.7
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 
> in the body of a message to majord...@vger.kernel.org More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] PCI: imx6:don't sleep in atomic context

[Sharma, Sanjeev]

-Original Message-
From: Bjorn Helgaas [mailto:helg...@kernel.org] 
Sent: Thursday, January 07, 2016 3:35 AM
To: Sharma, Sanjeev
Cc: richard@freescale.com; l.st...@pengutronix.de; bhelg...@google.com; 
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
linux-kernel@vger.kernel.org; David Mueller
Subject: Re: [PATCH] PCI: imx6:don't sleep in atomic context

Hi Sanjeev,

On Mon, Nov 09, 2015 at 04:18:00PM +0530, Sanjeev Sharma wrote:
> If additional PCIe switch get connected between the host and the 
> NIC,the kernel crashes with "BUG:
> scheduling while atomic". To handle this we need to call mdelay() 
> instead of usleep_range().
> 
> For more detail please refer bugzilla.kernel.org, Bug
> 100031
> 
> Signed-off-by: Sanjeev Sharma 
> Signed-off-by: David Mueller 

I'm dropping this for now because we've been kicking around the same solution 
(with tweaks to the mdelay amount) since June, but no progress on the *real* 
issue, which is that imx6_pcie_link_up() should never wait; it should simply 
return the link status.

I'm pretty sure the amount of time I've spent looking into this would have been 
enough to make some progress on that underlying issue.

Bjorn

Ok ! please share the change you are planning to implement. 

Sanjeev Sharma 
> ---
>  drivers/pci/host/pci-imx6.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c 
> index 233a196..9769b13 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -499,7 +499,7 @@ static int imx6_pcie_link_up(struct pcie_port *pp)
>* Wait a little bit, then re-check if the link finished
>* the training.
>*/
> - usleep_range(1000, 2000);
> + mdelay(1000);
>   }
>   /*
>* From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> --
> 1.7.11.7
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 
> in the body of a message to majord...@vger.kernel.org More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] hisi_sas: use slot abort in v1 hw

[Hannes Reinecke]

On 02/16/2016 05:13 PM, John Garry wrote:
> On 16/02/2016 15:31, Hannes Reinecke wrote:
>> On 02/16/2016 01:22 PM, John Garry wrote:
>>> When TRANS_TX_CREDIT_TIMEOUT_ERR or
>>> TRANS_TX_CLOSE_NORMAL_ERR errors occur for a
>>> command, the command should be re-attempted.
>>>
>>> Signed-off-by: John Garry 
>>> ---
>>>   drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 22 ++
>>>   1 file changed, 18 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
>>> b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
>>> index ce5f65d..34f71a1c 100644
>>> --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
>>> +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
>>> @@ -1118,9 +1118,8 @@ static int prep_ssp_v1_hw(struct hisi_hba
>>> *hisi_hba,
>>>   }
>>>
>>>   /* by default, task resp is complete */
>>> -static void slot_err_v1_hw(struct hisi_hba *hisi_hba,
>>> -   struct sas_task *task,
>>> -   struct hisi_sas_slot *slot)
>>> +static void slot_err_v1_hw(struct hisi_hba *hisi_hba, struct
>>> sas_task *task,
>>> +   struct hisi_sas_slot *slot, int *abort_slot)
>>>   {
>>>   struct task_status_struct *ts = >task_status;
>>>   struct hisi_sas_err_record_v1 *err_record =
>>> slot->status_buffer;
>>> @@ -1212,6 +1211,14 @@ static void slot_err_v1_hw(struct hisi_hba
>>> *hisi_hba,
>>>   ts->stat = SAS_NAK_R_ERR;
>>>   break;
>>>   }
>>> +case TRANS_TX_CREDIT_TIMEOUT_ERR:
>>> +case TRANS_TX_CLOSE_NORMAL_ERR:
>>> +{
>>> +/* This will request a retry */
>>> +ts->stat = SAS_QUEUE_FULL;
>>> +++(*abort_slot);
>>> +break;
>>> +}
>>>   default:
>>>   {
>>>   ts->stat = SAM_STAT_CHECK_CONDITION;
>>> @@ -1317,8 +1324,14 @@ static int slot_complete_v1_hw(struct
>>> hisi_hba *hisi_hba,
>>>
>>>   if (cmplt_hdr_data & CMPLT_HDR_ERR_RCRD_XFRD_MSK &&
>>>   !(cmplt_hdr_data & CMPLT_HDR_RSPNS_XFRD_MSK)) {
>>> +int abort_slot = 0;
>>>
>>> -slot_err_v1_hw(hisi_hba, task, slot);
>>> +slot_err_v1_hw(hisi_hba, task, slot,  _slot);
>>> +if (unlikely(abort_slot)) {
>>> +queue_work(hisi_hba->wq, >abort_slot);
>>> +sts = ts->stat;
>>> +goto out_1;
>>> +}
>>>   goto out;
>>>   }
>>>
>> What is the 'abort_slot' variable for?
>> Currently it's just a counter, no?
>> So why the weird pointer passing?
>>
>> And it does feel weird. Apparently the driver does get a message,
>> but still has to abort the command. Why?
>> Isn't the message an indicator that the command has been aborted?
>>
>> Cheers,
>>
>> Hannes
>>
> 
> I'll paste some more code for convenience and to help clarify:
> 
> static int slot_complete_v1_hw(struct hisi_hba *hisi_hba,
>struct hisi_sas_slot *slot, int abort)
> {
> ...
> 
> if (cmplt_hdr_data & CMPLT_HDR_ERR_RCRD_XFRD_MSK &&
> !(cmplt_hdr_data & CMPLT_HDR_RSPNS_XFRD_MSK)) {
> int abort_slot = 0;
> 
> slot_err_v1_hw(hisi_hba, task, slot,  _slot);
> if (unlikely(abort_slot)) { /* check if we need to abort the
> task */
> queue_work(hisi_hba->wq, >abort_slot);
> sts = ts->stat;
> goto out_1;
> }
> goto out;
> }
> 
>  ...
> 
> out:
> if (sas_dev && sas_dev->running_req)
> sas_dev->running_req--;
> 
> hisi_sas_slot_task_free(hisi_hba, task, slot);
> sts = ts->stat;
> 
> if (task->task_done)
> task->task_done(task);
> out_1:
> 
> return sts;
> }
> 
> Variable abort_slot is really a boolean flag which can be set in
> slot_err_v1_hw(). When error TRANS_TX_CREDIT_TIMEOUT_ERR or
> TRANS_TX_CLOSE_NORMAL_ERR occurs in the slot, abort_slot is set. In
> this case we don't immediately complete the task (goto out and call
> hisi_sas_slot_task_free() and task->task_done()), but instead queue
> the task to be aborted in the device before completing (call
> queue_work() and then goto out_1).
So why not make slot_err_vi_hw() a boolean and have abort_slot as
the return value?

> When hisi_sas_slot_abort() [patch #2] runs in the workqueue for the
> task, it first aborts the task in the device with a TMF, and then
> completes the task. Finally the status (SAS_QUEUE_FULL) is passed
> back to SCSI framework, which will request a retry for the scsi
> command.
> 
> This is the method our hw people recommended to handle these types
> of errors.
> 
Ok, sure, that does explain it.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 3/6] hisi_sas: use slot abort in v1 hw

[Hannes Reinecke]

On 02/16/2016 05:13 PM, John Garry wrote:
> On 16/02/2016 15:31, Hannes Reinecke wrote:
>> On 02/16/2016 01:22 PM, John Garry wrote:
>>> When TRANS_TX_CREDIT_TIMEOUT_ERR or
>>> TRANS_TX_CLOSE_NORMAL_ERR errors occur for a
>>> command, the command should be re-attempted.
>>>
>>> Signed-off-by: John Garry 
>>> ---
>>>   drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 22 ++
>>>   1 file changed, 18 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
>>> b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
>>> index ce5f65d..34f71a1c 100644
>>> --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
>>> +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
>>> @@ -1118,9 +1118,8 @@ static int prep_ssp_v1_hw(struct hisi_hba
>>> *hisi_hba,
>>>   }
>>>
>>>   /* by default, task resp is complete */
>>> -static void slot_err_v1_hw(struct hisi_hba *hisi_hba,
>>> -   struct sas_task *task,
>>> -   struct hisi_sas_slot *slot)
>>> +static void slot_err_v1_hw(struct hisi_hba *hisi_hba, struct
>>> sas_task *task,
>>> +   struct hisi_sas_slot *slot, int *abort_slot)
>>>   {
>>>   struct task_status_struct *ts = >task_status;
>>>   struct hisi_sas_err_record_v1 *err_record =
>>> slot->status_buffer;
>>> @@ -1212,6 +1211,14 @@ static void slot_err_v1_hw(struct hisi_hba
>>> *hisi_hba,
>>>   ts->stat = SAS_NAK_R_ERR;
>>>   break;
>>>   }
>>> +case TRANS_TX_CREDIT_TIMEOUT_ERR:
>>> +case TRANS_TX_CLOSE_NORMAL_ERR:
>>> +{
>>> +/* This will request a retry */
>>> +ts->stat = SAS_QUEUE_FULL;
>>> +++(*abort_slot);
>>> +break;
>>> +}
>>>   default:
>>>   {
>>>   ts->stat = SAM_STAT_CHECK_CONDITION;
>>> @@ -1317,8 +1324,14 @@ static int slot_complete_v1_hw(struct
>>> hisi_hba *hisi_hba,
>>>
>>>   if (cmplt_hdr_data & CMPLT_HDR_ERR_RCRD_XFRD_MSK &&
>>>   !(cmplt_hdr_data & CMPLT_HDR_RSPNS_XFRD_MSK)) {
>>> +int abort_slot = 0;
>>>
>>> -slot_err_v1_hw(hisi_hba, task, slot);
>>> +slot_err_v1_hw(hisi_hba, task, slot,  _slot);
>>> +if (unlikely(abort_slot)) {
>>> +queue_work(hisi_hba->wq, >abort_slot);
>>> +sts = ts->stat;
>>> +goto out_1;
>>> +}
>>>   goto out;
>>>   }
>>>
>> What is the 'abort_slot' variable for?
>> Currently it's just a counter, no?
>> So why the weird pointer passing?
>>
>> And it does feel weird. Apparently the driver does get a message,
>> but still has to abort the command. Why?
>> Isn't the message an indicator that the command has been aborted?
>>
>> Cheers,
>>
>> Hannes
>>
> 
> I'll paste some more code for convenience and to help clarify:
> 
> static int slot_complete_v1_hw(struct hisi_hba *hisi_hba,
>struct hisi_sas_slot *slot, int abort)
> {
> ...
> 
> if (cmplt_hdr_data & CMPLT_HDR_ERR_RCRD_XFRD_MSK &&
> !(cmplt_hdr_data & CMPLT_HDR_RSPNS_XFRD_MSK)) {
> int abort_slot = 0;
> 
> slot_err_v1_hw(hisi_hba, task, slot,  _slot);
> if (unlikely(abort_slot)) { /* check if we need to abort the
> task */
> queue_work(hisi_hba->wq, >abort_slot);
> sts = ts->stat;
> goto out_1;
> }
> goto out;
> }
> 
>  ...
> 
> out:
> if (sas_dev && sas_dev->running_req)
> sas_dev->running_req--;
> 
> hisi_sas_slot_task_free(hisi_hba, task, slot);
> sts = ts->stat;
> 
> if (task->task_done)
> task->task_done(task);
> out_1:
> 
> return sts;
> }
> 
> Variable abort_slot is really a boolean flag which can be set in
> slot_err_v1_hw(). When error TRANS_TX_CREDIT_TIMEOUT_ERR or
> TRANS_TX_CLOSE_NORMAL_ERR occurs in the slot, abort_slot is set. In
> this case we don't immediately complete the task (goto out and call
> hisi_sas_slot_task_free() and task->task_done()), but instead queue
> the task to be aborted in the device before completing (call
> queue_work() and then goto out_1).
So why not make slot_err_vi_hw() a boolean and have abort_slot as
the return value?

> When hisi_sas_slot_abort() [patch #2] runs in the workqueue for the
> task, it first aborts the task in the device with a TMF, and then
> completes the task. Finally the status (SAS_QUEUE_FULL) is passed
> back to SCSI framework, which will request a retry for the scsi
> command.
> 
> This is the method our hw people recommended to handle these types
> of errors.
> 
Ok, sure, that does explain it.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

[Felipe Balbi]

Hi,

Oliver Neukum  writes:
>> Oliver Neukum  writes:
>> >> > The API to user space. That is the point. We cannot break user space.
>> >> > Once this sysfs API is upstream we are stuck with it.
>> >> 
>> >> yeah, in fact I have been wondering if sysfs is the best interface to
>> >
>> > That is the discussion we must have.
>> >
>> >> userspace. I talked with Heikki a few days back about this; I was
>> >> wondering if something like what the NFC folks did with netlink would be
>> >> better here.
>> >
>> > I doubt that, because the main user is likely to be udev scripts.
>> 
>> I'm entirely sure about this. I think it's not too far-fetched to think
>
> What exactly are you sure about about?

heh, missed a NOT there :-)

>> that, eventually, we will need an actual stack exposed for the CC pin.
>
> The raw CC pin? What about the timing requirement?

well, not the _raw_ CC pin, but a situation where the microcontroller
handling CC pin is "dumb", in the sense that it provides an interface
for us to request/start arbitrary transactions. That will, in turn,
shift the actual bits on the CC pin. Or something along these lines.

An example would be the alternate mode thing. CC microcontroller doesn't
have to know what are the available alternate modes, but it needs to be
able to tell processor what request is coming from the other end.

I guess what I'm trying to say is that CC microcontroller might not be
the one controlling the multiplexer which switches USB pins to another
function. IOW:

Change to alternate mode X message
 CC microcontroller interrupts CPU
  read status to get X
   change multiplexer

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

[Felipe Balbi]

Hi,

Oliver Neukum  writes:
>> Oliver Neukum  writes:
>> >> > The API to user space. That is the point. We cannot break user space.
>> >> > Once this sysfs API is upstream we are stuck with it.
>> >> 
>> >> yeah, in fact I have been wondering if sysfs is the best interface to
>> >
>> > That is the discussion we must have.
>> >
>> >> userspace. I talked with Heikki a few days back about this; I was
>> >> wondering if something like what the NFC folks did with netlink would be
>> >> better here.
>> >
>> > I doubt that, because the main user is likely to be udev scripts.
>> 
>> I'm entirely sure about this. I think it's not too far-fetched to think
>
> What exactly are you sure about about?

heh, missed a NOT there :-)

>> that, eventually, we will need an actual stack exposed for the CC pin.
>
> The raw CC pin? What about the timing requirement?

well, not the _raw_ CC pin, but a situation where the microcontroller
handling CC pin is "dumb", in the sense that it provides an interface
for us to request/start arbitrary transactions. That will, in turn,
shift the actual bits on the CC pin. Or something along these lines.

An example would be the alternate mode thing. CC microcontroller doesn't
have to know what are the available alternate modes, but it needs to be
able to tell processor what request is coming from the other end.

I guess what I'm trying to say is that CC microcontroller might not be
the one controlling the multiplexer which switches USB pins to another
function. IOW:

Change to alternate mode X message
 CC microcontroller interrupts CPU
  read status to get X
   change multiplexer

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

[Paul Walmsley]

Hi Franklin

On Wed, 17 Feb 2016, Franklin S Cooper Jr. wrote:

> On 08/31/2015 10:51 AM, Paul Walmsley wrote:
> > On Thu, 16 Jul 2015, R, Vignesh wrote:
> >> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
> >>> On Wed, 3 Jun 2015, Vignesh R wrote:
> >>>
>  Add hwmod entries for the PWMSS on DRA7.
> 
>  Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
>  equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
>  As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
>  clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
>  L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
> >>> Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
> >>> HSPCLKDIV a separate divider after the divide-by-2 you mention above?
> >> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
> >> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
> >> the clock input for PWMSS. This will be updated in TRM soon.
> > OK
> >
>  --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>  +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>  @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
>   },
>   };
>   
>  +/* pwmss  */
>  +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
>  +.rev_offs   = 0x0,
>  +.sysc_offs  = 0x4,
>  +.sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
> >>> This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
> >>> RESETSTATUS bit.  There is a SOFTRESET bit. 
> >>>
> >>> Could you please confirm whether this is intentional?
> >> sorry my bad... I will change this in v3.
> > OK
> >
>  +/* ecap0 */
>  +struct omap_hwmod dra7xx_ecap0_hwmod = {
>  +.name   = "ecap0",
>  +.class  = _ecap_hwmod_class,
>  +.clkdm_name = "l4per2_clkdm",
>  +.main_clk   = "l4_root_clk_div",
> >>> Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
> >>> there appears to be a local "mini-PRCM" for the PWMSS which implements 
> >>> clock gating and reports back on the status of what I'd guess is the 
> >>> local 
> >>> clock gating FSM.
> >>>
> >>> So from that point of view, you should probably create a clock driver 
> >>> that 
> >>> manages both the clock gate request bit and the FSM status bit.  It 
> >>> should 
> >>> be something that can be reused for the other PWMSS IP blocks.  Then 
> >>> you'd create per-IP block clock nodes and set the main_clk to point to 
> >>> that node.
> >> Since, this register is within the config space of PWMSS, the individual
> >> gating and reporting for the modules within PWMSS
> >> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
> >> the sole function this driver is doing). It has been the same since
> >> am335x. Adding new clock nodes will result in driver changes and also
> >> changes to am335x, am437x (and other platforms) hwmod files. It also
> >> involves adding new nodes to clocks.dtsi and it will be difficult to
> >> maintain backward compatibility for older platforms. Is it not better to
> >> keep this as is, in order to maintain consistency (with am335x, am437x
> >> etc) and also that these clock bits are within IP's config space?
> > It's certainly possible that we as maintainers didn't look closely enough 
> > at the AM33xx data for the PWMSS when we merged it.  But if that's 
> > incorrect too, then now is the time to fix this.  Otherwise it will never 
> > get fixed, since each new group of people patching this code will keep 
> > punting it off to the indeterminate future.
> >
> > In terms of hwmod data: based on the register maps in sections 29.4.3, 
> > 29.3.3, and 29.2.3 of SPRUHZ6, none of these subdevices are hwmod devices.  
> > They don't support the Highlander OCP registers, they have no individual 
> > PRCM registers or register bitfields, and all of the idle and status 
> > reporting is to the PWMSS top-level IP block itself.  So it looks to me 
> > like the eCAP, eQEP, and ePWM modules should be registered via DT, rather 
> > than via hwmod.  It looks like you can get away with using the 
> > "simple-bus" abstraction, but you might ultimately have to define 
> > something custom here.  However, the PWMSS top level subsystem, described 
> > in section 29.1, does have the OCP registers, sideband signals, etc., and 
> > thus should remain a hwmod-registered device (via DT).
> >
> > In terms of the clock data: based on section 29.1.4, section 29.1.5.2, 
> > figure 29-3, and table 29-4, there are several clock gating control bits.  
> > These should be modeled as clock nodes in the Linux common clock 
> > framework.  Furthermore these registers are located inside the PWMSS 
> > subsystem itself, and are only accessible when the PWMSS IP block is 
> > functional in a PM runtime point of view: i.e., 

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

[Paul Walmsley]

Hi Franklin

On Wed, 17 Feb 2016, Franklin S Cooper Jr. wrote:

> On 08/31/2015 10:51 AM, Paul Walmsley wrote:
> > On Thu, 16 Jul 2015, R, Vignesh wrote:
> >> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
> >>> On Wed, 3 Jun 2015, Vignesh R wrote:
> >>>
>  Add hwmod entries for the PWMSS on DRA7.
> 
>  Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
>  equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
>  As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
>  clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
>  L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
> >>> Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
> >>> HSPCLKDIV a separate divider after the divide-by-2 you mention above?
> >> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
> >> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
> >> the clock input for PWMSS. This will be updated in TRM soon.
> > OK
> >
>  --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>  +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>  @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
>   },
>   };
>   
>  +/* pwmss  */
>  +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
>  +.rev_offs   = 0x0,
>  +.sysc_offs  = 0x4,
>  +.sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
> >>> This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
> >>> RESETSTATUS bit.  There is a SOFTRESET bit. 
> >>>
> >>> Could you please confirm whether this is intentional?
> >> sorry my bad... I will change this in v3.
> > OK
> >
>  +/* ecap0 */
>  +struct omap_hwmod dra7xx_ecap0_hwmod = {
>  +.name   = "ecap0",
>  +.class  = _ecap_hwmod_class,
>  +.clkdm_name = "l4per2_clkdm",
>  +.main_clk   = "l4_root_clk_div",
> >>> Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
> >>> there appears to be a local "mini-PRCM" for the PWMSS which implements 
> >>> clock gating and reports back on the status of what I'd guess is the 
> >>> local 
> >>> clock gating FSM.
> >>>
> >>> So from that point of view, you should probably create a clock driver 
> >>> that 
> >>> manages both the clock gate request bit and the FSM status bit.  It 
> >>> should 
> >>> be something that can be reused for the other PWMSS IP blocks.  Then 
> >>> you'd create per-IP block clock nodes and set the main_clk to point to 
> >>> that node.
> >> Since, this register is within the config space of PWMSS, the individual
> >> gating and reporting for the modules within PWMSS
> >> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
> >> the sole function this driver is doing). It has been the same since
> >> am335x. Adding new clock nodes will result in driver changes and also
> >> changes to am335x, am437x (and other platforms) hwmod files. It also
> >> involves adding new nodes to clocks.dtsi and it will be difficult to
> >> maintain backward compatibility for older platforms. Is it not better to
> >> keep this as is, in order to maintain consistency (with am335x, am437x
> >> etc) and also that these clock bits are within IP's config space?
> > It's certainly possible that we as maintainers didn't look closely enough 
> > at the AM33xx data for the PWMSS when we merged it.  But if that's 
> > incorrect too, then now is the time to fix this.  Otherwise it will never 
> > get fixed, since each new group of people patching this code will keep 
> > punting it off to the indeterminate future.
> >
> > In terms of hwmod data: based on the register maps in sections 29.4.3, 
> > 29.3.3, and 29.2.3 of SPRUHZ6, none of these subdevices are hwmod devices.  
> > They don't support the Highlander OCP registers, they have no individual 
> > PRCM registers or register bitfields, and all of the idle and status 
> > reporting is to the PWMSS top-level IP block itself.  So it looks to me 
> > like the eCAP, eQEP, and ePWM modules should be registered via DT, rather 
> > than via hwmod.  It looks like you can get away with using the 
> > "simple-bus" abstraction, but you might ultimately have to define 
> > something custom here.  However, the PWMSS top level subsystem, described 
> > in section 29.1, does have the OCP registers, sideband signals, etc., and 
> > thus should remain a hwmod-registered device (via DT).
> >
> > In terms of the clock data: based on section 29.1.4, section 29.1.5.2, 
> > figure 29-3, and table 29-4, there are several clock gating control bits.  
> > These should be modeled as clock nodes in the Linux common clock 
> > framework.  Furthermore these registers are located inside the PWMSS 
> > subsystem itself, and are only accessible when the PWMSS IP block is 
> > functional in a PM runtime point of view: i.e., 

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

[Kirill A. Shutemov]

On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> Sebastian Ott  wrote:
> 
> > [   59.875935] [ cut here ]
> > [   59.875937] kernel BUG at mm/huge_memory.c:2884!
> > [   59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP 
> > DEBUG_PAGEALLOC
> > [   59.875986] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan 
> > ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr 
> > ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 
> > sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t 
> > vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
> > [   59.876033] CPU: 2 PID: 5402 Comm: git Tainted: GW   
> > 4.4.0-07794-ga4eff16-dirty #77
> > [   59.876036] task: d2312948 ti: cfecc000 task.ti: 
> > cfecc000
> > [   59.876039] Krnl PSW : 0704d0018000 002bf3aa 
> > (__split_huge_pmd_locked+0x562/0xa10)
> > [   59.876045]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 
> > PM:0 EA:3
> >Krnl GPRS: 01a7a1cf 03d10177c000 
> > 00044068 5df00215
> > [   59.876051]0001 0001 
> >  774e6900
> > [   59.876054]03ff5200 6d403b10 
> > 6e1eb800 03ff51f0
> > [   59.876058]03d10177c000 00715190 
> > 002bf234 cfecfb58
> > [   59.876068] Krnl Code: 002bf39c: d507d010a000clc 
> > 16(8,%%r13),0(%%r10)
> >   002bf3a2: a7840004brc 
> > 8,2bf3aa
> >  #002bf3a6: a7f40001brc 
> > 15,2bf3a8
> >  >002bf3aa: 91407440tm  
> > 1088(%%r7),64
> >   002bf3ae: a7840208brc 
> > 8,2bf7be
> >   002bf3b2: a7f401e9brc 
> > 15,2bf784
> >   002bf3b6: 9104a006tm  
> > 6(%%r10),4
> >   002bf3ba: a7740004brc 
> > 7,2bf3c2
> > [   59.876089] Call Trace:
> > [   59.876092] ([<002bf234>] __split_huge_pmd_locked+0x3ec/0xa10)
> > [   59.876095]  [<002c4310>] __split_huge_pmd+0x118/0x218
> > [   59.876099]  [<002810e8>] unmap_single_vma+0x2d8/0xb40
> > [   59.876102]  [<00282d66>] zap_page_range+0x116/0x318
> > [   59.876105]  [<0029b834>] SyS_madvise+0x23c/0x5e8
> > [   59.876108]  [<006f9f56>] system_call+0xd6/0x258
> > [   59.876111]  [<03ff9bbfd282>] 0x3ff9bbfd282
> > [   59.876113] INFO: lockdep is turned off.
> > [   59.876115] Last Breaking-Event-Address:
> > [   59.876118]  [<002bf3a6>] __split_huge_pmd_locked+0x55e/0xa10
> 
> The BUG at mm/huge_memory.c:2884 is interesting, it's the 
> BUG_ON(!pte_none(*pte))
> check in __split_huge_pmd_locked(). Obviously we expect the pre-allocated
> pagetables to be empty, but in collapse_huge_page() we deposit the original
> pagetable instead of allocating a new (empty) one. This saves an allocation,
> which is good, but doesn't that mean that if such a collapsed hugepage will
> ever be split, we will always run into the BUG_ON(!pte_none(*pte)), or one
> of the two other VM_BUG_ONs in mm/huge_memory.c that check the same?
> 
> This behavior is not new, it was the same before the THP rework, so I do not
> assume that it is related to the current problems, maybe with the exception
> of this specific crash. I never saw the BUG at mm/huge_memory.c:2884 myself,
> and the other crashes probably cannot be explained with this. Maybe I am
> also missing something, but I do not see how collapse_huge_page() and the
> (non-empty) pgtable deposit there can work out with the 
> BUG_ON(!pte_none(*pte))
> checks. Any thoughts?

I don't think there's a problem: ptes in the pgtable are cleared with
pte_clear() in __collapse_huge_page_copy().

-- 
 Kirill A. Shutemov

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

[Kirill A. Shutemov]

On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> Sebastian Ott  wrote:
> 
> > [   59.875935] [ cut here ]
> > [   59.875937] kernel BUG at mm/huge_memory.c:2884!
> > [   59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP 
> > DEBUG_PAGEALLOC
> > [   59.875986] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan 
> > ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr 
> > ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 
> > sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t 
> > vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
> > [   59.876033] CPU: 2 PID: 5402 Comm: git Tainted: GW   
> > 4.4.0-07794-ga4eff16-dirty #77
> > [   59.876036] task: d2312948 ti: cfecc000 task.ti: 
> > cfecc000
> > [   59.876039] Krnl PSW : 0704d0018000 002bf3aa 
> > (__split_huge_pmd_locked+0x562/0xa10)
> > [   59.876045]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 
> > PM:0 EA:3
> >Krnl GPRS: 01a7a1cf 03d10177c000 
> > 00044068 5df00215
> > [   59.876051]0001 0001 
> >  774e6900
> > [   59.876054]03ff5200 6d403b10 
> > 6e1eb800 03ff51f0
> > [   59.876058]03d10177c000 00715190 
> > 002bf234 cfecfb58
> > [   59.876068] Krnl Code: 002bf39c: d507d010a000clc 
> > 16(8,%%r13),0(%%r10)
> >   002bf3a2: a7840004brc 
> > 8,2bf3aa
> >  #002bf3a6: a7f40001brc 
> > 15,2bf3a8
> >  >002bf3aa: 91407440tm  
> > 1088(%%r7),64
> >   002bf3ae: a7840208brc 
> > 8,2bf7be
> >   002bf3b2: a7f401e9brc 
> > 15,2bf784
> >   002bf3b6: 9104a006tm  
> > 6(%%r10),4
> >   002bf3ba: a7740004brc 
> > 7,2bf3c2
> > [   59.876089] Call Trace:
> > [   59.876092] ([<002bf234>] __split_huge_pmd_locked+0x3ec/0xa10)
> > [   59.876095]  [<002c4310>] __split_huge_pmd+0x118/0x218
> > [   59.876099]  [<002810e8>] unmap_single_vma+0x2d8/0xb40
> > [   59.876102]  [<00282d66>] zap_page_range+0x116/0x318
> > [   59.876105]  [<0029b834>] SyS_madvise+0x23c/0x5e8
> > [   59.876108]  [<006f9f56>] system_call+0xd6/0x258
> > [   59.876111]  [<03ff9bbfd282>] 0x3ff9bbfd282
> > [   59.876113] INFO: lockdep is turned off.
> > [   59.876115] Last Breaking-Event-Address:
> > [   59.876118]  [<002bf3a6>] __split_huge_pmd_locked+0x55e/0xa10
> 
> The BUG at mm/huge_memory.c:2884 is interesting, it's the 
> BUG_ON(!pte_none(*pte))
> check in __split_huge_pmd_locked(). Obviously we expect the pre-allocated
> pagetables to be empty, but in collapse_huge_page() we deposit the original
> pagetable instead of allocating a new (empty) one. This saves an allocation,
> which is good, but doesn't that mean that if such a collapsed hugepage will
> ever be split, we will always run into the BUG_ON(!pte_none(*pte)), or one
> of the two other VM_BUG_ONs in mm/huge_memory.c that check the same?
> 
> This behavior is not new, it was the same before the THP rework, so I do not
> assume that it is related to the current problems, maybe with the exception
> of this specific crash. I never saw the BUG at mm/huge_memory.c:2884 myself,
> and the other crashes probably cannot be explained with this. Maybe I am
> also missing something, but I do not see how collapse_huge_page() and the
> (non-empty) pgtable deposit there can work out with the 
> BUG_ON(!pte_none(*pte))
> checks. Any thoughts?

I don't think there's a problem: ptes in the pgtable are cleared with
pte_clear() in __collapse_huge_page_copy().

-- 
 Kirill A. Shutemov

Re: V4L docs and docbook

[Hans Verkuil]

Hi Jon,

On 02/17/2016 10:52 PM, Jonathan Corbet wrote:
> Hey, Mauro,
> 
> There's been a conversation going on that I keep meaning to bring you
> into.  In short, there's a fair amount of interest in improving our
> formatted kernel documentation, and, in particular, making it easier to
> write; I'd like to be sure that work doesn't leave media behind.
> 
> Work pushed by Daniel Vetter and company has been aiming toward the
> ability to use a lightweight markup language in the in-source kerneldoc
> comments.  Initially Markdown was targeted; the most likely choice now
> looks like ReStructuredText, though no decision has been made.  I've been
> pushing for moving all of our formatted documentation to whatever markup
> we use, leaving DocBook behind.  There are, I think, a lot of good
> reasons to want to do that, including consistency between the template
> files and the in-source comments, ease of authoring, and a less unwieldy
> toolchain.

I looked at ReStructuredText and it looks like it will be a pain to convert
the media DocBook code to that, and the main reason is the poor table support.
The syntax for that looks very painful and the media DocBook is full of tables.

BTW, my daily build scripts also rebuilds the media spec and it is available
here: https://hverkuil.home.xs4all.nl/spec/media.html

Also missing in ReStructuredText seems to be support for formulas (see for
example the Colorspaces section in the spec), although to be fair standard
DocBook doesn't do a great job at that either.

Now, I hate DocBook so going to something easier would certainly be nice,
but I think it is going to be a difficult task.

Someone would have to prove that going to another formatting tool will
produce good results for our documentation. We can certainly give a few
representative sections of our doc to someone to convert, and if that
looks OK, then the full conversion can be done.

We have (and still are) put a lot of effort into our documentation and
we would like to keep the same level of quality.

Regards,

Hans

> 
> Various proof-of-concept patches have gone around showing that this idea
> seems to be feasible.  The latest discussion is at:
> 
>   http://thread.gmane.org/gmane.linux.documentation/35773
> 
> The media community has a lot of investment in DocBook documentation.
> Converting to another markup form is relatively easy, and it's something
> I would be willing to help with when the time comes.  But it occurred to
> me that I should probably ask what you all think of this.
> 
> There is no flag day here; there's no reason to rip out the current
> DocBook-based build infrastructure as long as somebody's using it.  But
> it would be nice to get rid of it eventually and work toward the creation
> of a more integrated set of kernel documentation.
> 
> So...is this an idea that fills you with horror, or does it maybe have
> some appeal?  Do you have any questions?
> 
> One other question I had for you was: which of the allegedly supported
> output formats are important to you?
> 
> Thanks,
> 
> jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: V4L docs and docbook

[Hans Verkuil]

Hi Jon,

On 02/17/2016 10:52 PM, Jonathan Corbet wrote:
> Hey, Mauro,
> 
> There's been a conversation going on that I keep meaning to bring you
> into.  In short, there's a fair amount of interest in improving our
> formatted kernel documentation, and, in particular, making it easier to
> write; I'd like to be sure that work doesn't leave media behind.
> 
> Work pushed by Daniel Vetter and company has been aiming toward the
> ability to use a lightweight markup language in the in-source kerneldoc
> comments.  Initially Markdown was targeted; the most likely choice now
> looks like ReStructuredText, though no decision has been made.  I've been
> pushing for moving all of our formatted documentation to whatever markup
> we use, leaving DocBook behind.  There are, I think, a lot of good
> reasons to want to do that, including consistency between the template
> files and the in-source comments, ease of authoring, and a less unwieldy
> toolchain.

I looked at ReStructuredText and it looks like it will be a pain to convert
the media DocBook code to that, and the main reason is the poor table support.
The syntax for that looks very painful and the media DocBook is full of tables.

BTW, my daily build scripts also rebuilds the media spec and it is available
here: https://hverkuil.home.xs4all.nl/spec/media.html

Also missing in ReStructuredText seems to be support for formulas (see for
example the Colorspaces section in the spec), although to be fair standard
DocBook doesn't do a great job at that either.

Now, I hate DocBook so going to something easier would certainly be nice,
but I think it is going to be a difficult task.

Someone would have to prove that going to another formatting tool will
produce good results for our documentation. We can certainly give a few
representative sections of our doc to someone to convert, and if that
looks OK, then the full conversion can be done.

We have (and still are) put a lot of effort into our documentation and
we would like to keep the same level of quality.

Regards,

Hans

> 
> Various proof-of-concept patches have gone around showing that this idea
> seems to be feasible.  The latest discussion is at:
> 
>   http://thread.gmane.org/gmane.linux.documentation/35773
> 
> The media community has a lot of investment in DocBook documentation.
> Converting to another markup form is relatively easy, and it's something
> I would be willing to help with when the time comes.  But it occurred to
> me that I should probably ask what you all think of this.
> 
> There is no flag day here; there's no reason to rip out the current
> DocBook-based build infrastructure as long as somebody's using it.  But
> it would be nice to get rid of it eventually and work toward the creation
> of a more integrated set of kernel documentation.
> 
> So...is this an idea that fills you with horror, or does it maybe have
> some appeal?  Do you have any questions?
> 
> One other question I had for you was: which of the allegedly supported
> output formats are important to you?
> 
> Thanks,
> 
> jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan()

[Xishi Qiu]

On 2016/2/17 8:35, David Rientjes wrote:

> On Tue, 16 Feb 2016, Greg Kroah-Hartman wrote:
> 
>> On Tue, Feb 16, 2016 at 05:37:05PM +0800, Xishi Qiu wrote:
>>> Currently tasksize in lowmem_scan() only calculate rss, and not include 
>>> swap.
>>> But usually smart phones enable zram, so swap space actually use ram.
>>
>> Yes, but does that matter for this type of calculation?  I need an ack
>> from the android team before I could ever take such a core change to
>> this code...
>>
> 
> The calculation proposed in this patch is the same as the generic oom 
> killer, it's an estimate of the amount of memory that will be freed if it 
> is killed and can exit.  This is better than simply get_mm_rss().
> 
> However, I think we seriously need to re-consider the implementation of 
> the lowmem killer entirely.  It currently abuses the use of TIF_MEMDIE, 
> which should ideally only be set for one thread on the system since it 
> allows unbounded access to global memory reserves.
> 

Hi David,

Does somebody do the work of re-implementation of the lowmem killer entirely
now? Could you give me some details? e.g. when and how?

Here are another two questions.
1) lmk has several lowmem thresholds, it's "lowmem_minfree[]", and the value is
static definition, so is it reasonable for different memory size(e.g. 
2G/3G/4G...)
of smart phones?
2) There are many adjustable arguments in /proc/sys/vm/, and the default value
maybe not benefit for smart phones, so any suggestions?

Thanks,
Xishi Qiu

> It also abuses the user-visible /proc/self/oom_score_adj tunable: this 
> tunable is used by the generic oom killer to bias or discount a proportion 
> of memory from a process's usage.  This is the only supported semantic of 
> the tunable.  The lowmem killer uses it as a strict prioritization, so any 
> process with oom_score_adj higher than another process is preferred for 
> kill, REGARDLESS of memory usage.  This leads to priority inversion, the 
> user is unable to always define the same process to be killed by the 
> generic oom killer and the lowmem killer.  This is what happens when a 
> tunable with a very clear and defined purpose is used for other reasons.
> 
> I'd seriously consider not accepting any additional hacks on top of this 
> code until the implementation is rewritten.
> 
> .
> 

Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem_scan()

[Xishi Qiu]

On 2016/2/17 8:35, David Rientjes wrote:

> On Tue, 16 Feb 2016, Greg Kroah-Hartman wrote:
> 
>> On Tue, Feb 16, 2016 at 05:37:05PM +0800, Xishi Qiu wrote:
>>> Currently tasksize in lowmem_scan() only calculate rss, and not include 
>>> swap.
>>> But usually smart phones enable zram, so swap space actually use ram.
>>
>> Yes, but does that matter for this type of calculation?  I need an ack
>> from the android team before I could ever take such a core change to
>> this code...
>>
> 
> The calculation proposed in this patch is the same as the generic oom 
> killer, it's an estimate of the amount of memory that will be freed if it 
> is killed and can exit.  This is better than simply get_mm_rss().
> 
> However, I think we seriously need to re-consider the implementation of 
> the lowmem killer entirely.  It currently abuses the use of TIF_MEMDIE, 
> which should ideally only be set for one thread on the system since it 
> allows unbounded access to global memory reserves.
> 

Hi David,

Does somebody do the work of re-implementation of the lowmem killer entirely
now? Could you give me some details? e.g. when and how?

Here are another two questions.
1) lmk has several lowmem thresholds, it's "lowmem_minfree[]", and the value is
static definition, so is it reasonable for different memory size(e.g. 
2G/3G/4G...)
of smart phones?
2) There are many adjustable arguments in /proc/sys/vm/, and the default value
maybe not benefit for smart phones, so any suggestions?

Thanks,
Xishi Qiu

> It also abuses the user-visible /proc/self/oom_score_adj tunable: this 
> tunable is used by the generic oom killer to bias or discount a proportion 
> of memory from a process's usage.  This is the only supported semantic of 
> the tunable.  The lowmem killer uses it as a strict prioritization, so any 
> process with oom_score_adj higher than another process is preferred for 
> kill, REGARDLESS of memory usage.  This leads to priority inversion, the 
> user is unable to always define the same process to be killed by the 
> generic oom killer and the lowmem killer.  This is what happens when a 
> tunable with a very clear and defined purpose is used for other reasons.
> 
> I'd seriously consider not accepting any additional hacks on top of this 
> code until the implementation is rewritten.
> 
> .
> 

Re: [tip:x86/urgent] hpet: Drop stale URLs

[Andreas Mohr]

Hi,

On Wed, Feb 17, 2016 at 04:14:54AM -0800, tip-bot for Michael S. Tsirkin wrote:
> Commit-ID:  4e7f9df25874cedbbc604a5c5c2e7a6efe662387
> Gitweb: http://git.kernel.org/tip/4e7f9df25874cedbbc604a5c5c2e7a6efe662387
> Author: Michael S. Tsirkin 
> AuthorDate: Thu, 11 Feb 2016 01:05:01 +0200
> Committer:  Ingo Molnar 
> CommitDate: Wed, 17 Feb 2016 09:39:56 +0100
> 
> hpet: Drop stale URLs
> 
> Looks like the HPET spec at intel.com got moved.
> It isn't hard to find so drop the link, just mention
> the revision assumed.

While URLs unfortunately often are less permanent than possibly intended
(details see useful entire sub content of
"Aw: Re: Checkout hangs on invalid external URL"
  http://svn.haxx.se/users/archive-2015-11/0027.shtml)
and thus too often need to be updated or even removed as a consequence,
I feel that once an URL as a very reliable reference has been lost,
naming of a file likely is the next most reliable fallback reference
(to at least have feeding into an Internet search engine
as the next fallback step).
An alternative/second reference
would have been listing the full title of this existing document, too.

Thus I'm questioning whether the exact file name
should in fact be removed here (at 3 locations even) by this commit,
while at least usefully adding
a (albeit somewhat weak) reference of "revision 1".

>  The High Precision Event Timer (HPET) hardware follows a specification
> -by Intel and Microsoft which can be found at
> -
> - http://www.intel.com/hardwaredesign/hpetspec_1.pdf
> +by Intel and Microsoft, revision 1.


Oh, and I noticed as a curiosity (or so I thought)
that this cleanup-style work is (to be made?) part of "x86/urgent",
which I didn't expect to be defined as topically related.

Thanks,

Andreas Mohr

Re: [tip:x86/urgent] hpet: Drop stale URLs

[Andreas Mohr]

Hi,

On Wed, Feb 17, 2016 at 04:14:54AM -0800, tip-bot for Michael S. Tsirkin wrote:
> Commit-ID:  4e7f9df25874cedbbc604a5c5c2e7a6efe662387
> Gitweb: http://git.kernel.org/tip/4e7f9df25874cedbbc604a5c5c2e7a6efe662387
> Author: Michael S. Tsirkin 
> AuthorDate: Thu, 11 Feb 2016 01:05:01 +0200
> Committer:  Ingo Molnar 
> CommitDate: Wed, 17 Feb 2016 09:39:56 +0100
> 
> hpet: Drop stale URLs
> 
> Looks like the HPET spec at intel.com got moved.
> It isn't hard to find so drop the link, just mention
> the revision assumed.

While URLs unfortunately often are less permanent than possibly intended
(details see useful entire sub content of
"Aw: Re: Checkout hangs on invalid external URL"
  http://svn.haxx.se/users/archive-2015-11/0027.shtml)
and thus too often need to be updated or even removed as a consequence,
I feel that once an URL as a very reliable reference has been lost,
naming of a file likely is the next most reliable fallback reference
(to at least have feeding into an Internet search engine
as the next fallback step).
An alternative/second reference
would have been listing the full title of this existing document, too.

Thus I'm questioning whether the exact file name
should in fact be removed here (at 3 locations even) by this commit,
while at least usefully adding
a (albeit somewhat weak) reference of "revision 1".

>  The High Precision Event Timer (HPET) hardware follows a specification
> -by Intel and Microsoft which can be found at
> -
> - http://www.intel.com/hardwaredesign/hpetspec_1.pdf
> +by Intel and Microsoft, revision 1.


Oh, and I noticed as a curiosity (or so I thought)
that this cleanup-style work is (to be made?) part of "x86/urgent",
which I didn't expect to be defined as topically related.

Thanks,

Andreas Mohr

Re: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

[Paul Walmsley]

Hi Keerthy

On Thu, 18 Feb 2016, Keerthy wrote:

> The patch adds rtc hwmod. RTC module The RTC module is physically
> present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
> disabled. A secure RTC is used instead on these devices, where needed.
> . Hence adding it selectively using a seprate list to get RTC Module
> functional on the other am43x SoCs used on am437x-gp-evm and
> am437x-sk-evm.
> 
> Signed-off-by: Keerthy 
> ---
> 
> No Public TRM is available for AM438x SoC as of now.
> 
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> index e97a894..fcffaf8 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> @@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if 
> *am43xx_hwmod_ocp_ifs[] __initdata = {
>   NULL,
>  };
>  
> +static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
> + _l4_wkup__rtc,
> + NULL,
> +};
> +
>  int __init am43xx_hwmod_init(void)
>  {
> + int ret;
> +
>   omap_hwmod_am43xx_reg();
>   omap_hwmod_init();
> - return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
> + ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
> +
> + if (!(of_machine_is_compatible("ti,am438x")))
> + ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
> +
> + return ret;
>  }

Could you please invert the test of this case such that the RTC hwmod is 
only registered on AM43xx SoCs where it is specifically known to be 
enabled?

That way, if another AM43xx SoC comes out that doesn't have the RTC 
module, it won't inadvertently be registered.  This seems like a safer 
approach.

- Paul

Re: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod

[Paul Walmsley]

Hi Keerthy

On Thu, 18 Feb 2016, Keerthy wrote:

> The patch adds rtc hwmod. RTC module The RTC module is physically
> present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
> disabled. A secure RTC is used instead on these devices, where needed.
> . Hence adding it selectively using a seprate list to get RTC Module
> functional on the other am43x SoCs used on am437x-gp-evm and
> am437x-sk-evm.
> 
> Signed-off-by: Keerthy 
> ---
> 
> No Public TRM is available for AM438x SoC as of now.
> 
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> index e97a894..fcffaf8 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> @@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if 
> *am43xx_hwmod_ocp_ifs[] __initdata = {
>   NULL,
>  };
>  
> +static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
> + _l4_wkup__rtc,
> + NULL,
> +};
> +
>  int __init am43xx_hwmod_init(void)
>  {
> + int ret;
> +
>   omap_hwmod_am43xx_reg();
>   omap_hwmod_init();
> - return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
> + ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
> +
> + if (!(of_machine_is_compatible("ti,am438x")))
> + ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
> +
> + return ret;
>  }

Could you please invert the test of this case such that the RTC hwmod is 
only registered on AM43xx SoCs where it is specifically known to be 
enabled?

That way, if another AM43xx SoC comes out that doesn't have the RTC 
module, it won't inadvertently be registered.  This seems like a safer 
approach.

- Paul

[PATCH v3 1/5] soc: qcom: smd: Introduce callback setter

[Bjorn Andersson]

From: Bjorn Andersson 

Introduce a setter for the callback function pointer to clarify the
locking around the operation and to reduce some duplication.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c   | 25 +
 include/linux/soc/qcom/smd.h |  4 +++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 498fd0581a45..c357842b92e1 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -186,7 +186,7 @@ struct qcom_smd_channel {
int fifo_size;
 
void *bounce_buffer;
-   int (*cb)(struct qcom_smd_device *, const void *, size_t);
+   qcom_smd_cb_t cb;
 
spinlock_t recv_lock;
 
@@ -378,6 +378,19 @@ static void qcom_smd_channel_reset(struct qcom_smd_channel 
*channel)
 }
 
 /*
+ * Set the callback for a channel, with appropriate locking
+ */
+static void qcom_smd_channel_set_callback(struct qcom_smd_channel *channel,
+ qcom_smd_cb_t cb)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>recv_lock, flags);
+   channel->cb = cb;
+   spin_unlock_irqrestore(>recv_lock, flags);
+};
+
+/*
  * Calculate the amount of data available in the rx fifo
  */
 static size_t qcom_smd_channel_get_rx_avail(struct qcom_smd_channel *channel)
@@ -814,8 +827,7 @@ static int qcom_smd_dev_probe(struct device *dev)
if (!channel->bounce_buffer)
return -ENOMEM;
 
-   channel->cb = qsdrv->callback;
-
+   qcom_smd_channel_set_callback(channel, qsdrv->callback);
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENING);
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENED);
@@ -831,7 +843,7 @@ static int qcom_smd_dev_probe(struct device *dev)
 err:
dev_err(>dev, "probe failed\n");
 
-   channel->cb = NULL;
+   qcom_smd_channel_set_callback(channel, NULL);
kfree(channel->bounce_buffer);
channel->bounce_buffer = NULL;
 
@@ -850,16 +862,13 @@ static int qcom_smd_dev_remove(struct device *dev)
struct qcom_smd_device *qsdev = to_smd_device(dev);
struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
struct qcom_smd_channel *channel = qsdev->channel;
-   unsigned long flags;
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSING);
 
/*
 * Make sure we don't race with the code receiving data.
 */
-   spin_lock_irqsave(>recv_lock, flags);
-   channel->cb = NULL;
-   spin_unlock_irqrestore(>recv_lock, flags);
+   qcom_smd_channel_set_callback(channel, NULL);
 
/* Wake up any sleepers in qcom_smd_send() */
wake_up_interruptible(>fblockread_event);
diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
index d0cb6d189a0a..65a64fcdb1aa 100644
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -26,6 +26,8 @@ struct qcom_smd_device {
struct qcom_smd_channel *channel;
 };
 
+typedef int (*qcom_smd_cb_t)(struct qcom_smd_device *, const void *, size_t);
+
 /**
  * struct qcom_smd_driver - smd driver struct
  * @driver:underlying device driver
@@ -42,7 +44,7 @@ struct qcom_smd_driver {
 
int (*probe)(struct qcom_smd_device *dev);
void (*remove)(struct qcom_smd_device *dev);
-   int (*callback)(struct qcom_smd_device *, const void *, size_t);
+   qcom_smd_cb_t callback;
 };
 
 int qcom_smd_driver_register(struct qcom_smd_driver *drv);
-- 
2.5.0

[PATCH v3 1/5] soc: qcom: smd: Introduce callback setter

[Bjorn Andersson]

From: Bjorn Andersson 

Introduce a setter for the callback function pointer to clarify the
locking around the operation and to reduce some duplication.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c   | 25 +
 include/linux/soc/qcom/smd.h |  4 +++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 498fd0581a45..c357842b92e1 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -186,7 +186,7 @@ struct qcom_smd_channel {
int fifo_size;
 
void *bounce_buffer;
-   int (*cb)(struct qcom_smd_device *, const void *, size_t);
+   qcom_smd_cb_t cb;
 
spinlock_t recv_lock;
 
@@ -378,6 +378,19 @@ static void qcom_smd_channel_reset(struct qcom_smd_channel 
*channel)
 }
 
 /*
+ * Set the callback for a channel, with appropriate locking
+ */
+static void qcom_smd_channel_set_callback(struct qcom_smd_channel *channel,
+ qcom_smd_cb_t cb)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>recv_lock, flags);
+   channel->cb = cb;
+   spin_unlock_irqrestore(>recv_lock, flags);
+};
+
+/*
  * Calculate the amount of data available in the rx fifo
  */
 static size_t qcom_smd_channel_get_rx_avail(struct qcom_smd_channel *channel)
@@ -814,8 +827,7 @@ static int qcom_smd_dev_probe(struct device *dev)
if (!channel->bounce_buffer)
return -ENOMEM;
 
-   channel->cb = qsdrv->callback;
-
+   qcom_smd_channel_set_callback(channel, qsdrv->callback);
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENING);
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENED);
@@ -831,7 +843,7 @@ static int qcom_smd_dev_probe(struct device *dev)
 err:
dev_err(>dev, "probe failed\n");
 
-   channel->cb = NULL;
+   qcom_smd_channel_set_callback(channel, NULL);
kfree(channel->bounce_buffer);
channel->bounce_buffer = NULL;
 
@@ -850,16 +862,13 @@ static int qcom_smd_dev_remove(struct device *dev)
struct qcom_smd_device *qsdev = to_smd_device(dev);
struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
struct qcom_smd_channel *channel = qsdev->channel;
-   unsigned long flags;
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSING);
 
/*
 * Make sure we don't race with the code receiving data.
 */
-   spin_lock_irqsave(>recv_lock, flags);
-   channel->cb = NULL;
-   spin_unlock_irqrestore(>recv_lock, flags);
+   qcom_smd_channel_set_callback(channel, NULL);
 
/* Wake up any sleepers in qcom_smd_send() */
wake_up_interruptible(>fblockread_event);
diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
index d0cb6d189a0a..65a64fcdb1aa 100644
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -26,6 +26,8 @@ struct qcom_smd_device {
struct qcom_smd_channel *channel;
 };
 
+typedef int (*qcom_smd_cb_t)(struct qcom_smd_device *, const void *, size_t);
+
 /**
  * struct qcom_smd_driver - smd driver struct
  * @driver:underlying device driver
@@ -42,7 +44,7 @@ struct qcom_smd_driver {
 
int (*probe)(struct qcom_smd_device *dev);
void (*remove)(struct qcom_smd_device *dev);
-   int (*callback)(struct qcom_smd_device *, const void *, size_t);
+   qcom_smd_cb_t callback;
 };
 
 int qcom_smd_driver_register(struct qcom_smd_driver *drv);
-- 
2.5.0

[PATCH v3 2/5] soc: qcom: smd: Split discovery and state change work

[Bjorn Andersson]

From: Bjorn Andersson 

Split the two steps of channel discovery and state change handling into
two different workers. This allows for new channels to be found while
we're are probing, which is required as we introduce multi-channel
support.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- channels_lock is kept as spinlock
- qcom_smd_edge_intr() is smarter about which worker to kick

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 58 +++---
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index c357842b92e1..e8972ddfee85 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -106,9 +106,9 @@ static const struct {
  * @channels:  list of all channels detected on this edge
  * @channels_lock: guard for modifications of @channels
  * @allocated: array of bitmaps representing already allocated channels
- * @need_rescan:   flag that the @work needs to scan smem for new channels
  * @smem_available:last available amount of smem triggering a channel scan
- * @work:  work item for edge house keeping
+ * @scan_work: work item for discovering new channels
+ * @state_work:work item for edge state changes
  */
 struct qcom_smd_edge {
struct qcom_smd *smd;
@@ -127,10 +127,10 @@ struct qcom_smd_edge {
 
DECLARE_BITMAP(allocated[SMD_ALLOC_TBL_COUNT], SMD_ALLOC_TBL_SIZE);
 
-   bool need_rescan;
unsigned smem_available;
 
-   struct work_struct work;
+   struct work_struct scan_work;
+   struct work_struct state_work;
 };
 
 /*
@@ -614,7 +614,8 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
struct qcom_smd_edge *edge = data;
struct qcom_smd_channel *channel;
unsigned available;
-   bool kick_worker = false;
+   bool kick_scanner = false;
+   bool kick_state = false;
 
/*
 * Handle state changes or data on each of the channels on this edge
@@ -622,7 +623,7 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
spin_lock(>channels_lock);
list_for_each_entry(channel, >channels, list) {
spin_lock(>recv_lock);
-   kick_worker |= qcom_smd_channel_intr(channel);
+   kick_state |= qcom_smd_channel_intr(channel);
spin_unlock(>recv_lock);
}
spin_unlock(>channels_lock);
@@ -635,12 +636,13 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
available = qcom_smem_get_free_space(edge->remote_pid);
if (available != edge->smem_available) {
edge->smem_available = available;
-   edge->need_rescan = true;
-   kick_worker = true;
+   kick_scanner = true;
}
 
-   if (kick_worker)
-   schedule_work(>work);
+   if (kick_scanner)
+   schedule_work(>scan_work);
+   if (kick_state)
+   schedule_work(>state_work);
 
return IRQ_HANDLED;
 }
@@ -1098,8 +1100,9 @@ free_name_and_channel:
  * qcom_smd_create_channel() to create representations of these and add
  * them to the edge's list of channels.
  */
-static void qcom_discover_channels(struct qcom_smd_edge *edge)
+static void qcom_channel_scan_worker(struct work_struct *work)
 {
+   struct qcom_smd_edge *edge = container_of(work, struct qcom_smd_edge, 
scan_work);
struct qcom_smd_alloc_entry *alloc_tbl;
struct qcom_smd_alloc_entry *entry;
struct qcom_smd_channel *channel;
@@ -1152,7 +1155,7 @@ static void qcom_discover_channels(struct qcom_smd_edge 
*edge)
}
}
 
-   schedule_work(>work);
+   schedule_work(>state_work);
 }
 
 /*
@@ -1160,29 +1163,23 @@ static void qcom_discover_channels(struct qcom_smd_edge 
*edge)
  * then scans all registered channels for state changes that should be handled
  * by creating or destroying smd client devices for the registered channels.
  *
- * LOCKING: edge->channels_lock is not needed to be held during the traversal
- * of the channels list as it's done synchronously with the only writer.
+ * LOCKING: edge->channels_lock only needs to cover the list operations, as the
+ * worker is killed before any channels are deallocated
  */
 static void qcom_channel_state_worker(struct work_struct *work)
 {
struct qcom_smd_channel *channel;
struct qcom_smd_edge *edge = container_of(work,
  struct qcom_smd_edge,
- work);
+ state_work);
unsigned remote_state;
-
-   /*
-* Rescan smem if we have reason to belive that there are new channels.
-*/
-   if (edge->need_rescan) {
- 

[PATCH v3 2/5] soc: qcom: smd: Split discovery and state change work

[Bjorn Andersson]

From: Bjorn Andersson 

Split the two steps of channel discovery and state change handling into
two different workers. This allows for new channels to be found while
we're are probing, which is required as we introduce multi-channel
support.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- channels_lock is kept as spinlock
- qcom_smd_edge_intr() is smarter about which worker to kick

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 58 +++---
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index c357842b92e1..e8972ddfee85 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -106,9 +106,9 @@ static const struct {
  * @channels:  list of all channels detected on this edge
  * @channels_lock: guard for modifications of @channels
  * @allocated: array of bitmaps representing already allocated channels
- * @need_rescan:   flag that the @work needs to scan smem for new channels
  * @smem_available:last available amount of smem triggering a channel scan
- * @work:  work item for edge house keeping
+ * @scan_work: work item for discovering new channels
+ * @state_work:work item for edge state changes
  */
 struct qcom_smd_edge {
struct qcom_smd *smd;
@@ -127,10 +127,10 @@ struct qcom_smd_edge {
 
DECLARE_BITMAP(allocated[SMD_ALLOC_TBL_COUNT], SMD_ALLOC_TBL_SIZE);
 
-   bool need_rescan;
unsigned smem_available;
 
-   struct work_struct work;
+   struct work_struct scan_work;
+   struct work_struct state_work;
 };
 
 /*
@@ -614,7 +614,8 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
struct qcom_smd_edge *edge = data;
struct qcom_smd_channel *channel;
unsigned available;
-   bool kick_worker = false;
+   bool kick_scanner = false;
+   bool kick_state = false;
 
/*
 * Handle state changes or data on each of the channels on this edge
@@ -622,7 +623,7 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
spin_lock(>channels_lock);
list_for_each_entry(channel, >channels, list) {
spin_lock(>recv_lock);
-   kick_worker |= qcom_smd_channel_intr(channel);
+   kick_state |= qcom_smd_channel_intr(channel);
spin_unlock(>recv_lock);
}
spin_unlock(>channels_lock);
@@ -635,12 +636,13 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
available = qcom_smem_get_free_space(edge->remote_pid);
if (available != edge->smem_available) {
edge->smem_available = available;
-   edge->need_rescan = true;
-   kick_worker = true;
+   kick_scanner = true;
}
 
-   if (kick_worker)
-   schedule_work(>work);
+   if (kick_scanner)
+   schedule_work(>scan_work);
+   if (kick_state)
+   schedule_work(>state_work);
 
return IRQ_HANDLED;
 }
@@ -1098,8 +1100,9 @@ free_name_and_channel:
  * qcom_smd_create_channel() to create representations of these and add
  * them to the edge's list of channels.
  */
-static void qcom_discover_channels(struct qcom_smd_edge *edge)
+static void qcom_channel_scan_worker(struct work_struct *work)
 {
+   struct qcom_smd_edge *edge = container_of(work, struct qcom_smd_edge, 
scan_work);
struct qcom_smd_alloc_entry *alloc_tbl;
struct qcom_smd_alloc_entry *entry;
struct qcom_smd_channel *channel;
@@ -1152,7 +1155,7 @@ static void qcom_discover_channels(struct qcom_smd_edge 
*edge)
}
}
 
-   schedule_work(>work);
+   schedule_work(>state_work);
 }
 
 /*
@@ -1160,29 +1163,23 @@ static void qcom_discover_channels(struct qcom_smd_edge 
*edge)
  * then scans all registered channels for state changes that should be handled
  * by creating or destroying smd client devices for the registered channels.
  *
- * LOCKING: edge->channels_lock is not needed to be held during the traversal
- * of the channels list as it's done synchronously with the only writer.
+ * LOCKING: edge->channels_lock only needs to cover the list operations, as the
+ * worker is killed before any channels are deallocated
  */
 static void qcom_channel_state_worker(struct work_struct *work)
 {
struct qcom_smd_channel *channel;
struct qcom_smd_edge *edge = container_of(work,
  struct qcom_smd_edge,
- work);
+ state_work);
unsigned remote_state;
-
-   /*
-* Rescan smem if we have reason to belive that there are new channels.
-*/
-   if (edge->need_rescan) {
-   edge->need_rescan = false;
-   qcom_discover_channels(edge);
-

[PATCH v3 4/5] soc: qcom: smd: Support multiple channels per sdev

[Bjorn Andersson]

From: Bjorn Andersson 

This patch allows chaining additional channels to a SMD device, enabling
implementation of multi-channel SMD devies - like Bluetooth.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index d253e5cc233f..c3fa0fd724f7 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -193,6 +193,7 @@ struct qcom_smd_channel {
int pkt_size;
 
struct list_head list;
+   struct list_head dev_list;
 };
 
 /**
@@ -887,6 +888,8 @@ static int qcom_smd_dev_remove(struct device *dev)
struct qcom_smd_device *qsdev = to_smd_device(dev);
struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
struct qcom_smd_channel *channel = qsdev->channel;
+   struct qcom_smd_channel *tmp;
+   struct qcom_smd_channel *ch;
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSING);
 
@@ -906,10 +909,14 @@ static int qcom_smd_dev_remove(struct device *dev)
qsdrv->remove(qsdev);
 
/*
-* The client is now gone, cleanup and reset the channel state.
+* The client is now gone, close and release all channels associated
+* with this sdev
 */
-   channel->qsdev = NULL;
-   qcom_smd_channel_close(channel);
+   list_for_each_entry_safe(ch, tmp, >dev_list, dev_list) {
+   qcom_smd_channel_close(ch);
+   list_del(>dev_list);
+   ch->qsdev = NULL;
+   }
 
return 0;
 }
@@ -1056,6 +1063,7 @@ static struct qcom_smd_channel 
*qcom_smd_create_channel(struct qcom_smd_edge *ed
if (!channel)
return ERR_PTR(-ENOMEM);
 
+   INIT_LIST_HEAD(>dev_list);
channel->edge = edge;
channel->name = devm_kstrdup(smd->dev, name, GFP_KERNEL);
if (!channel->name)
-- 
2.5.0

[PATCH v3 5/5] soc: qcom: smd: Support opening additional channels

[Bjorn Andersson]

From: Bjorn Andersson 

With the qcom_smd_open_channel() API we allow SMD devices to open
additional SMD channels, to allow implementation of multi-channel SMD
devices - like Bluetooth.

Channels are opened from the same edge as the calling SMD device is tied
to.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- channels_lock is spinlock

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c   | 76 
 include/linux/soc/qcom/smd.h |  4 +++
 2 files changed, 80 insertions(+)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index c3fa0fd724f7..b6434c4be86a 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -129,6 +129,8 @@ struct qcom_smd_edge {
 
unsigned smem_available;
 
+   wait_queue_head_t new_channel_event;
+
struct work_struct scan_work;
struct work_struct state_work;
 };
@@ -1042,6 +1044,77 @@ void qcom_smd_driver_unregister(struct qcom_smd_driver 
*qsdrv)
 }
 EXPORT_SYMBOL(qcom_smd_driver_unregister);
 
+static struct qcom_smd_channel *
+qcom_smd_find_channel(struct qcom_smd_edge *edge, const char *name)
+{
+   struct qcom_smd_channel *channel;
+   struct qcom_smd_channel *ret = NULL;
+   unsigned long flags;
+   unsigned state;
+
+   spin_lock_irqsave(>channels_lock, flags);
+   list_for_each_entry(channel, >channels, list) {
+   if (strcmp(channel->name, name))
+   continue;
+
+   state = GET_RX_CHANNEL_INFO(channel, state);
+   if (state != SMD_CHANNEL_OPENING &&
+   state != SMD_CHANNEL_OPENED)
+   continue;
+
+   ret = channel;
+   break;
+   }
+   spin_unlock_irqrestore(>channels_lock, flags);
+
+   return ret;
+}
+
+/**
+ * qcom_smd_open_channel() - claim additional channels on the same edge
+ * @sdev:  smd_device handle
+ * @name:  channel name
+ * @cb:callback method to use for incoming data
+ *
+ * Returns a channel handle on success, or -EPROBE_DEFER if the channel isn't
+ * ready.
+ */
+struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev,
+  const char *name,
+  qcom_smd_cb_t cb)
+{
+   struct qcom_smd_channel *channel;
+   struct qcom_smd_edge *edge = sdev->channel->edge;
+   int ret;
+
+   /* Wait up to HZ for the channel to appear */
+   ret = wait_event_interruptible_timeout(edge->new_channel_event,
+   (channel = qcom_smd_find_channel(edge, name)) != NULL,
+   HZ);
+   if (!ret)
+   return ERR_PTR(-ETIMEDOUT);
+
+   if (channel->state != SMD_CHANNEL_CLOSED) {
+   dev_err(>dev, "channel %s is busy\n", channel->name);
+   return ERR_PTR(-EBUSY);
+   }
+
+   channel->qsdev = sdev;
+   ret = qcom_smd_channel_open(channel, cb);
+   if (ret) {
+   channel->qsdev = NULL;
+   return ERR_PTR(ret);
+   }
+
+   /*
+* Append the list of channel to the channels associated with the sdev
+*/
+   list_add_tail(>dev_list, >channel->dev_list);
+
+   return channel;
+}
+EXPORT_SYMBOL(qcom_smd_open_channel);
+
 /*
  * Allocate the qcom_smd_channel object for a newly found smd channel,
  * retrieving and validating the smem items involved.
@@ -1178,6 +1251,8 @@ static void qcom_channel_scan_worker(struct work_struct 
*work)
 
dev_dbg(smd->dev, "new channel found: '%s'\n", 
channel->name);
set_bit(i, edge->allocated[tbl]);
+
+   wake_up_interruptible(>new_channel_event);
}
}
 
@@ -1341,6 +1416,7 @@ static int qcom_smd_probe(struct platform_device *pdev)
for_each_available_child_of_node(pdev->dev.of_node, node) {
edge = >edges[i++];
edge->smd = smd;
+   init_waitqueue_head(>new_channel_event);
 
ret = qcom_smd_parse_edge(>dev, node, edge);
if (ret)
diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
index 65a64fcdb1aa..bd51c8a9d807 100644
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -56,4 +56,8 @@ void qcom_smd_driver_unregister(struct qcom_smd_driver *drv);
 
 int qcom_smd_send(struct qcom_smd_channel *channel, const void *data, int len);
 
+struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev,
+  const char *name,
+  qcom_smd_cb_t cb);
+
 #endif
-- 
2.5.0

[PATCH v3 3/5] soc: qcom: smd: Refactor channel open and close handling

[Bjorn Andersson]

From: Bjorn Andersson 

Refactor opening and closing of channels into two separate functions
instead of open coding this in the various places.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 62 --
 1 file changed, 40 insertions(+), 22 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index e8972ddfee85..d253e5cc233f 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -808,18 +808,12 @@ static int qcom_smd_dev_match(struct device *dev, struct 
device_driver *drv)
 }
 
 /*
- * Probe the smd client.
- *
- * The remote side have indicated that it want the channel to be opened, so
- * complete the state handshake and probe our client driver.
+ * Helper for opening a channel
  */
-static int qcom_smd_dev_probe(struct device *dev)
+static int qcom_smd_channel_open(struct qcom_smd_channel *channel,
+qcom_smd_cb_t cb)
 {
-   struct qcom_smd_device *qsdev = to_smd_device(dev);
-   struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
-   struct qcom_smd_channel *channel = qsdev->channel;
size_t bb_size;
-   int ret;
 
/*
 * Packets are maximum 4k, but reduce if the fifo is smaller
@@ -829,11 +823,44 @@ static int qcom_smd_dev_probe(struct device *dev)
if (!channel->bounce_buffer)
return -ENOMEM;
 
-   qcom_smd_channel_set_callback(channel, qsdrv->callback);
+   qcom_smd_channel_set_callback(channel, cb);
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENING);
-
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENED);
 
+   return 0;
+}
+
+/*
+ * Helper for closing and resetting a channel
+ */
+static void qcom_smd_channel_close(struct qcom_smd_channel *channel)
+{
+   qcom_smd_channel_set_callback(channel, NULL);
+
+   kfree(channel->bounce_buffer);
+   channel->bounce_buffer = NULL;
+
+   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
+   qcom_smd_channel_reset(channel);
+}
+
+/*
+ * Probe the smd client.
+ *
+ * The remote side have indicated that it want the channel to be opened, so
+ * complete the state handshake and probe our client driver.
+ */
+static int qcom_smd_dev_probe(struct device *dev)
+{
+   struct qcom_smd_device *qsdev = to_smd_device(dev);
+   struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
+   struct qcom_smd_channel *channel = qsdev->channel;
+   int ret;
+
+   ret = qcom_smd_channel_open(channel, qsdrv->callback);
+   if (ret)
+   return ret;
+
ret = qsdrv->probe(qsdev);
if (ret)
goto err;
@@ -845,11 +872,7 @@ static int qcom_smd_dev_probe(struct device *dev)
 err:
dev_err(>dev, "probe failed\n");
 
-   qcom_smd_channel_set_callback(channel, NULL);
-   kfree(channel->bounce_buffer);
-   channel->bounce_buffer = NULL;
-
-   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
+   qcom_smd_channel_close(channel);
return ret;
 }
 
@@ -886,12 +909,7 @@ static int qcom_smd_dev_remove(struct device *dev)
 * The client is now gone, cleanup and reset the channel state.
 */
channel->qsdev = NULL;
-   kfree(channel->bounce_buffer);
-   channel->bounce_buffer = NULL;
-
-   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
-
-   qcom_smd_channel_reset(channel);
+   qcom_smd_channel_close(channel);
 
return 0;
 }
-- 
2.5.0

[PATCH v3 4/5] soc: qcom: smd: Support multiple channels per sdev

[Bjorn Andersson]

From: Bjorn Andersson 

This patch allows chaining additional channels to a SMD device, enabling
implementation of multi-channel SMD devies - like Bluetooth.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index d253e5cc233f..c3fa0fd724f7 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -193,6 +193,7 @@ struct qcom_smd_channel {
int pkt_size;
 
struct list_head list;
+   struct list_head dev_list;
 };
 
 /**
@@ -887,6 +888,8 @@ static int qcom_smd_dev_remove(struct device *dev)
struct qcom_smd_device *qsdev = to_smd_device(dev);
struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
struct qcom_smd_channel *channel = qsdev->channel;
+   struct qcom_smd_channel *tmp;
+   struct qcom_smd_channel *ch;
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSING);
 
@@ -906,10 +909,14 @@ static int qcom_smd_dev_remove(struct device *dev)
qsdrv->remove(qsdev);
 
/*
-* The client is now gone, cleanup and reset the channel state.
+* The client is now gone, close and release all channels associated
+* with this sdev
 */
-   channel->qsdev = NULL;
-   qcom_smd_channel_close(channel);
+   list_for_each_entry_safe(ch, tmp, >dev_list, dev_list) {
+   qcom_smd_channel_close(ch);
+   list_del(>dev_list);
+   ch->qsdev = NULL;
+   }
 
return 0;
 }
@@ -1056,6 +1063,7 @@ static struct qcom_smd_channel 
*qcom_smd_create_channel(struct qcom_smd_edge *ed
if (!channel)
return ERR_PTR(-ENOMEM);
 
+   INIT_LIST_HEAD(>dev_list);
channel->edge = edge;
channel->name = devm_kstrdup(smd->dev, name, GFP_KERNEL);
if (!channel->name)
-- 
2.5.0

[PATCH v3 5/5] soc: qcom: smd: Support opening additional channels

[Bjorn Andersson]

From: Bjorn Andersson 

With the qcom_smd_open_channel() API we allow SMD devices to open
additional SMD channels, to allow implementation of multi-channel SMD
devices - like Bluetooth.

Channels are opened from the same edge as the calling SMD device is tied
to.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- channels_lock is spinlock

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c   | 76 
 include/linux/soc/qcom/smd.h |  4 +++
 2 files changed, 80 insertions(+)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index c3fa0fd724f7..b6434c4be86a 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -129,6 +129,8 @@ struct qcom_smd_edge {
 
unsigned smem_available;
 
+   wait_queue_head_t new_channel_event;
+
struct work_struct scan_work;
struct work_struct state_work;
 };
@@ -1042,6 +1044,77 @@ void qcom_smd_driver_unregister(struct qcom_smd_driver 
*qsdrv)
 }
 EXPORT_SYMBOL(qcom_smd_driver_unregister);
 
+static struct qcom_smd_channel *
+qcom_smd_find_channel(struct qcom_smd_edge *edge, const char *name)
+{
+   struct qcom_smd_channel *channel;
+   struct qcom_smd_channel *ret = NULL;
+   unsigned long flags;
+   unsigned state;
+
+   spin_lock_irqsave(>channels_lock, flags);
+   list_for_each_entry(channel, >channels, list) {
+   if (strcmp(channel->name, name))
+   continue;
+
+   state = GET_RX_CHANNEL_INFO(channel, state);
+   if (state != SMD_CHANNEL_OPENING &&
+   state != SMD_CHANNEL_OPENED)
+   continue;
+
+   ret = channel;
+   break;
+   }
+   spin_unlock_irqrestore(>channels_lock, flags);
+
+   return ret;
+}
+
+/**
+ * qcom_smd_open_channel() - claim additional channels on the same edge
+ * @sdev:  smd_device handle
+ * @name:  channel name
+ * @cb:callback method to use for incoming data
+ *
+ * Returns a channel handle on success, or -EPROBE_DEFER if the channel isn't
+ * ready.
+ */
+struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev,
+  const char *name,
+  qcom_smd_cb_t cb)
+{
+   struct qcom_smd_channel *channel;
+   struct qcom_smd_edge *edge = sdev->channel->edge;
+   int ret;
+
+   /* Wait up to HZ for the channel to appear */
+   ret = wait_event_interruptible_timeout(edge->new_channel_event,
+   (channel = qcom_smd_find_channel(edge, name)) != NULL,
+   HZ);
+   if (!ret)
+   return ERR_PTR(-ETIMEDOUT);
+
+   if (channel->state != SMD_CHANNEL_CLOSED) {
+   dev_err(>dev, "channel %s is busy\n", channel->name);
+   return ERR_PTR(-EBUSY);
+   }
+
+   channel->qsdev = sdev;
+   ret = qcom_smd_channel_open(channel, cb);
+   if (ret) {
+   channel->qsdev = NULL;
+   return ERR_PTR(ret);
+   }
+
+   /*
+* Append the list of channel to the channels associated with the sdev
+*/
+   list_add_tail(>dev_list, >channel->dev_list);
+
+   return channel;
+}
+EXPORT_SYMBOL(qcom_smd_open_channel);
+
 /*
  * Allocate the qcom_smd_channel object for a newly found smd channel,
  * retrieving and validating the smem items involved.
@@ -1178,6 +1251,8 @@ static void qcom_channel_scan_worker(struct work_struct 
*work)
 
dev_dbg(smd->dev, "new channel found: '%s'\n", 
channel->name);
set_bit(i, edge->allocated[tbl]);
+
+   wake_up_interruptible(>new_channel_event);
}
}
 
@@ -1341,6 +1416,7 @@ static int qcom_smd_probe(struct platform_device *pdev)
for_each_available_child_of_node(pdev->dev.of_node, node) {
edge = >edges[i++];
edge->smd = smd;
+   init_waitqueue_head(>new_channel_event);
 
ret = qcom_smd_parse_edge(>dev, node, edge);
if (ret)
diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
index 65a64fcdb1aa..bd51c8a9d807 100644
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -56,4 +56,8 @@ void qcom_smd_driver_unregister(struct qcom_smd_driver *drv);
 
 int qcom_smd_send(struct qcom_smd_channel *channel, const void *data, int len);
 
+struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev,
+  const char *name,
+  qcom_smd_cb_t cb);
+
 #endif
-- 
2.5.0

[PATCH v3 3/5] soc: qcom: smd: Refactor channel open and close handling

[Bjorn Andersson]

From: Bjorn Andersson 

Refactor opening and closing of channels into two separate functions
instead of open coding this in the various places.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 62 --
 1 file changed, 40 insertions(+), 22 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index e8972ddfee85..d253e5cc233f 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -808,18 +808,12 @@ static int qcom_smd_dev_match(struct device *dev, struct 
device_driver *drv)
 }
 
 /*
- * Probe the smd client.
- *
- * The remote side have indicated that it want the channel to be opened, so
- * complete the state handshake and probe our client driver.
+ * Helper for opening a channel
  */
-static int qcom_smd_dev_probe(struct device *dev)
+static int qcom_smd_channel_open(struct qcom_smd_channel *channel,
+qcom_smd_cb_t cb)
 {
-   struct qcom_smd_device *qsdev = to_smd_device(dev);
-   struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
-   struct qcom_smd_channel *channel = qsdev->channel;
size_t bb_size;
-   int ret;
 
/*
 * Packets are maximum 4k, but reduce if the fifo is smaller
@@ -829,11 +823,44 @@ static int qcom_smd_dev_probe(struct device *dev)
if (!channel->bounce_buffer)
return -ENOMEM;
 
-   qcom_smd_channel_set_callback(channel, qsdrv->callback);
+   qcom_smd_channel_set_callback(channel, cb);
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENING);
-
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENED);
 
+   return 0;
+}
+
+/*
+ * Helper for closing and resetting a channel
+ */
+static void qcom_smd_channel_close(struct qcom_smd_channel *channel)
+{
+   qcom_smd_channel_set_callback(channel, NULL);
+
+   kfree(channel->bounce_buffer);
+   channel->bounce_buffer = NULL;
+
+   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
+   qcom_smd_channel_reset(channel);
+}
+
+/*
+ * Probe the smd client.
+ *
+ * The remote side have indicated that it want the channel to be opened, so
+ * complete the state handshake and probe our client driver.
+ */
+static int qcom_smd_dev_probe(struct device *dev)
+{
+   struct qcom_smd_device *qsdev = to_smd_device(dev);
+   struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
+   struct qcom_smd_channel *channel = qsdev->channel;
+   int ret;
+
+   ret = qcom_smd_channel_open(channel, qsdrv->callback);
+   if (ret)
+   return ret;
+
ret = qsdrv->probe(qsdev);
if (ret)
goto err;
@@ -845,11 +872,7 @@ static int qcom_smd_dev_probe(struct device *dev)
 err:
dev_err(>dev, "probe failed\n");
 
-   qcom_smd_channel_set_callback(channel, NULL);
-   kfree(channel->bounce_buffer);
-   channel->bounce_buffer = NULL;
-
-   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
+   qcom_smd_channel_close(channel);
return ret;
 }
 
@@ -886,12 +909,7 @@ static int qcom_smd_dev_remove(struct device *dev)
 * The client is now gone, cleanup and reset the channel state.
 */
channel->qsdev = NULL;
-   kfree(channel->bounce_buffer);
-   channel->bounce_buffer = NULL;
-
-   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
-
-   qcom_smd_channel_reset(channel);
+   qcom_smd_channel_close(channel);
 
return 0;
 }
-- 
2.5.0

[PATCH v3 0/5] Qualcomm SMD multi-channel client support

[Bjorn Andersson]

After trying to avoid implementing multi-channel support in SMD in v1 of
the HCI driver for Qualcomm WCNSS BT, this new version includes the
necessary SMD refactoring and additon of an API that allows SMD devices
to call back into the SMD core to acquire additonal channels.

The additional channels are tied to the existing SMD device and the life
cycle of the new channel will be tied to, and affect, the original
channel.

Changes since v2:
- rwlock is replaced by spinlock
- smarter kicking of the two workers

Bjorn Andersson (5):
  soc: qcom: smd: Introduce callback setter
  soc: qcom: smd: Split discovery and state change work
  soc: qcom: smd: Refactor channel open and close handling
  soc: qcom: smd: Support multiple channels per sdev
  soc: qcom: smd: Support opening additional channels

 drivers/soc/qcom/smd.c   | 229 ---
 include/linux/soc/qcom/smd.h |   8 +-
 2 files changed, 179 insertions(+), 58 deletions(-)

-- 
2.5.0

[PATCH v3 0/5] Qualcomm SMD multi-channel client support

[Bjorn Andersson]

After trying to avoid implementing multi-channel support in SMD in v1 of
the HCI driver for Qualcomm WCNSS BT, this new version includes the
necessary SMD refactoring and additon of an API that allows SMD devices
to call back into the SMD core to acquire additonal channels.

The additional channels are tied to the existing SMD device and the life
cycle of the new channel will be tied to, and affect, the original
channel.

Changes since v2:
- rwlock is replaced by spinlock
- smarter kicking of the two workers

Bjorn Andersson (5):
  soc: qcom: smd: Introduce callback setter
  soc: qcom: smd: Split discovery and state change work
  soc: qcom: smd: Refactor channel open and close handling
  soc: qcom: smd: Support multiple channels per sdev
  soc: qcom: smd: Support opening additional channels

 drivers/soc/qcom/smd.c   | 229 ---
 include/linux/soc/qcom/smd.h |   8 +-
 2 files changed, 179 insertions(+), 58 deletions(-)

-- 
2.5.0

Re: call_usermodehelper in containers

[Ian Kent]

On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote:
> On 2016/02/18 11:57, Eric W. Biederman wrote:
> > 
> > Ccing The containers list because a related discussion is happening
> > there
> > and somehow this thread has never made it there.
> > 
> > Ian Kent  writes:
> > 
> > > On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote:
> > > > On 11/15, Eric W. Biederman wrote:
> > > > > 
> > > > > I don't understand that one.  Having a preforked thread with
> > > > > the
> > > > > proper
> > > > > environment that can act like kthreadd in terms of spawning
> > > > > user
> > > > > mode
> > > > > helpers works and is simple.
> > > 
> > > Forgive me replying to such an old thread but ...
> > > 
> > > After realizing workqueues can't be used to pre-create threads to
> > > run
> > > usermode helpers I've returned to look at this.
> > 
> > If someone can wind up with a good implementation I will be happy.
> > 
> > > > Can't we ask ->child_reaper to create the non-daemonized kernel
> > > > thread
> > > > with the "right" ->nsproxy, ->fs, etc?
> > > 
> > > Eric, do you think this approach would be sufficient too?
> > > 
> > > Probably wouldn't be quite right for user namespaces but should
> > > provide
> > > what's needed for other cases?
> > > 
> > > It certainly has the advantage of not having to maintain a plague
> > > of
> > > processes waiting around to execute helpers.
> > 
> > That certainly sounds attractive.  Especially for the case of
> > everyone
> > who wants to set a core pattern in a container.
> > 
> > I am fuzzy on all of the details right now, but what I do remember
> > is
> > that in the kernel the user mode helper concepts when they attempted
> > to
> > scrub a processes environment were quite error prone until we
> > managed to
> > get kthreadd(pid 2) on the scene which always had a clean
> > environment.
> > 
> > If we are going to tie this kind of thing to the pid namespace I
> > recommend simplying denying it if you are in a user namespace
> > without
> > an approrpriate pid namespace.  AKA simply not allowing thigns to be
> > setup
> > if current->pid_ns->user_ns != current->user_ns.
> > 
> Can't be handled by simple capability like CAP_SYS_USERMODEHELPER ?
> 
> User_ns check seems not to allow core-dump-cather in host will not
> work if user_ns is used.

I don't think so but I'm not sure.

The approach I was talking about assumes the init process of the caller
(say within a container, corresponding to ->child_reaper) is an
appropriate template for umh thread execution.

But I don't think that covers the case where unshare has created
different namespaces, like a mount namespace for example.

The current workqueue sub system can't be used to pre-create a thread to
be used for umh execution so, either is needs changes or yet another
mechanism needs to be implemented.

For uses other than core dumping capturing a reference to the struct pid
of the environment init process and using that as an execution template
should be sufficient and takes care of environment existence problems
with some extra checks, not to mention eliminating the need for a
potentially huge number of kernel threads needing to be created to
provide execution templates.

Where to store this and how to access it when needed is another problem.

Not sure a usermode helper capability is the right thing either as I
thought one important use of user namespaces was to allow unprivileged
users to perform operations they otherwise can't.

Maybe a CAP_SYS_USERNSCOREDUMP or similar would be sensible 

Still an appropriate execution template would be needed and IIUC we
can't trust getting that from within a user created namespace
environment.

> 
> Thanks,
> -Kame
> 

Re: call_usermodehelper in containers

[Ian Kent]

On Thu, 2016-02-18 at 12:43 +0900, Kamezawa Hiroyuki wrote:
> On 2016/02/18 11:57, Eric W. Biederman wrote:
> > 
> > Ccing The containers list because a related discussion is happening
> > there
> > and somehow this thread has never made it there.
> > 
> > Ian Kent  writes:
> > 
> > > On Mon, 2013-11-18 at 18:28 +0100, Oleg Nesterov wrote:
> > > > On 11/15, Eric W. Biederman wrote:
> > > > > 
> > > > > I don't understand that one.  Having a preforked thread with
> > > > > the
> > > > > proper
> > > > > environment that can act like kthreadd in terms of spawning
> > > > > user
> > > > > mode
> > > > > helpers works and is simple.
> > > 
> > > Forgive me replying to such an old thread but ...
> > > 
> > > After realizing workqueues can't be used to pre-create threads to
> > > run
> > > usermode helpers I've returned to look at this.
> > 
> > If someone can wind up with a good implementation I will be happy.
> > 
> > > > Can't we ask ->child_reaper to create the non-daemonized kernel
> > > > thread
> > > > with the "right" ->nsproxy, ->fs, etc?
> > > 
> > > Eric, do you think this approach would be sufficient too?
> > > 
> > > Probably wouldn't be quite right for user namespaces but should
> > > provide
> > > what's needed for other cases?
> > > 
> > > It certainly has the advantage of not having to maintain a plague
> > > of
> > > processes waiting around to execute helpers.
> > 
> > That certainly sounds attractive.  Especially for the case of
> > everyone
> > who wants to set a core pattern in a container.
> > 
> > I am fuzzy on all of the details right now, but what I do remember
> > is
> > that in the kernel the user mode helper concepts when they attempted
> > to
> > scrub a processes environment were quite error prone until we
> > managed to
> > get kthreadd(pid 2) on the scene which always had a clean
> > environment.
> > 
> > If we are going to tie this kind of thing to the pid namespace I
> > recommend simplying denying it if you are in a user namespace
> > without
> > an approrpriate pid namespace.  AKA simply not allowing thigns to be
> > setup
> > if current->pid_ns->user_ns != current->user_ns.
> > 
> Can't be handled by simple capability like CAP_SYS_USERMODEHELPER ?
> 
> User_ns check seems not to allow core-dump-cather in host will not
> work if user_ns is used.

I don't think so but I'm not sure.

The approach I was talking about assumes the init process of the caller
(say within a container, corresponding to ->child_reaper) is an
appropriate template for umh thread execution.

But I don't think that covers the case where unshare has created
different namespaces, like a mount namespace for example.

The current workqueue sub system can't be used to pre-create a thread to
be used for umh execution so, either is needs changes or yet another
mechanism needs to be implemented.

For uses other than core dumping capturing a reference to the struct pid
of the environment init process and using that as an execution template
should be sufficient and takes care of environment existence problems
with some extra checks, not to mention eliminating the need for a
potentially huge number of kernel threads needing to be created to
provide execution templates.

Where to store this and how to access it when needed is another problem.

Not sure a usermode helper capability is the right thing either as I
thought one important use of user namespaces was to allow unprivileged
users to perform operations they otherwise can't.

Maybe a CAP_SYS_USERNSCOREDUMP or similar would be sensible 

Still an appropriate execution template would be needed and IIUC we
can't trust getting that from within a user created namespace
environment.

> 
> Thanks,
> -Kame
> 

[RESEND PATCH v3] isdn: divamnt: use y2038-safe ktime_get_ts64() for trace data timestamps

[Alison Schofield]

divamnt stores a start_time at module init and uses it to calculate
elapsed time. The elapsed time, stored in secs and usecs, is part of
the trace data the driver maintains for the DIVA Server ISDN cards.
No change to the format of that time data is required.

To avoid overflow on 32-bit systems use ktime_get_ts64() to return
the elapsed monotonic time since system boot.

This is a change from real to monotonic time. Since the driver only
stores elapsed time, monotonic time is sufficient and more robust
against real time clock changes. These new monotonic values can be
more useful for debugging because they can be easily compared to
other monotonic timestamps.

Note elaspsed time values will now start at system boot time rather
than module load time, so they will differ slightly from previously
reported values.

Remove declaration and init of previously unused time constants:
start_sec, start_usec.

Signed-off-by: Alison Schofield 
Reviewed-by: Arnd Bergmann 
---
Changes in v3:
  - use elapsed time since system boot in place of
elapsed time since module load
  - commit message updated
  - changelog updated

Changes in v2:
 - switched to monotonic time
 - removed the unused time constants
 - changelog updated


 drivers/isdn/hardware/eicon/debug.c   |  4 
 drivers/isdn/hardware/eicon/divamnt.c | 30 ++
 2 files changed, 6 insertions(+), 28 deletions(-)

diff --git a/drivers/isdn/hardware/eicon/debug.c 
b/drivers/isdn/hardware/eicon/debug.c
index b5226af..576b7b4 100644
--- a/drivers/isdn/hardware/eicon/debug.c
+++ b/drivers/isdn/hardware/eicon/debug.c
@@ -192,8 +192,6 @@ static diva_os_spin_lock_t dbg_q_lock;
 static diva_os_spin_lock_t dbg_adapter_lock;
 static int dbg_q_busy;
 static volatile dword  dbg_sequence;
-static dword   start_sec;
-static dword   start_usec;
 
 /*
   INTERFACE:
@@ -215,8 +213,6 @@ int diva_maint_init(byte *base, unsigned long length, int 
do_init) {
 
dbg_base = base;
 
-   diva_os_get_time(_sec, _usec);
-
*(dword *)base  = (dword)DBG_MAGIC; /* Store Magic */
base   += sizeof(dword);
length -= sizeof(dword);
diff --git a/drivers/isdn/hardware/eicon/divamnt.c 
b/drivers/isdn/hardware/eicon/divamnt.c
index 48db08d..0de29b7b 100644
--- a/drivers/isdn/hardware/eicon/divamnt.c
+++ b/drivers/isdn/hardware/eicon/divamnt.c
@@ -45,7 +45,6 @@ char *DRIVERRELEASE_MNT = "2.0";
 
 static wait_queue_head_t msgwaitq;
 static unsigned long opened;
-static struct timeval start_time;
 
 extern int mntfunc_init(int *, void **, unsigned long);
 extern void mntfunc_finit(void);
@@ -88,28 +87,12 @@ int diva_os_copy_from_user(void *os_handle, void *dst, 
const void __user *src,
  */
 void diva_os_get_time(dword *sec, dword *usec)
 {
-   struct timeval tv;
-
-   do_gettimeofday();
-
-   if (tv.tv_sec > start_time.tv_sec) {
-   if (start_time.tv_usec > tv.tv_usec) {
-   tv.tv_sec--;
-   tv.tv_usec += 100;
-   }
-   *sec = (dword) (tv.tv_sec - start_time.tv_sec);
-   *usec = (dword) (tv.tv_usec - start_time.tv_usec);
-   } else if (tv.tv_sec == start_time.tv_sec) {
-   *sec = 0;
-   if (start_time.tv_usec < tv.tv_usec) {
-   *usec = (dword) (tv.tv_usec - start_time.tv_usec);
-   } else {
-   *usec = 0;
-   }
-   } else {
-   *sec = (dword) tv.tv_sec;
-   *usec = (dword) tv.tv_usec;
-   }
+   struct timespec64 time;
+
+   ktime_get_ts64();
+
+   *sec = (dword) time.tv_sec;
+   *usec = (dword) (time.tv_nsec / NSEC_PER_USEC);
 }
 
 /*
@@ -213,7 +196,6 @@ static int __init maint_init(void)
int ret = 0;
void *buffer = NULL;
 
-   do_gettimeofday(_time);
init_waitqueue_head();
 
printk(KERN_INFO "%s\n", DRIVERNAME);
-- 
2.1.4

[RESEND PATCH v3] isdn: divamnt: use y2038-safe ktime_get_ts64() for trace data timestamps

[Alison Schofield]

divamnt stores a start_time at module init and uses it to calculate
elapsed time. The elapsed time, stored in secs and usecs, is part of
the trace data the driver maintains for the DIVA Server ISDN cards.
No change to the format of that time data is required.

To avoid overflow on 32-bit systems use ktime_get_ts64() to return
the elapsed monotonic time since system boot.

This is a change from real to monotonic time. Since the driver only
stores elapsed time, monotonic time is sufficient and more robust
against real time clock changes. These new monotonic values can be
more useful for debugging because they can be easily compared to
other monotonic timestamps.

Note elaspsed time values will now start at system boot time rather
than module load time, so they will differ slightly from previously
reported values.

Remove declaration and init of previously unused time constants:
start_sec, start_usec.

Signed-off-by: Alison Schofield 
Reviewed-by: Arnd Bergmann 
---
Changes in v3:
  - use elapsed time since system boot in place of
elapsed time since module load
  - commit message updated
  - changelog updated

Changes in v2:
 - switched to monotonic time
 - removed the unused time constants
 - changelog updated


 drivers/isdn/hardware/eicon/debug.c   |  4 
 drivers/isdn/hardware/eicon/divamnt.c | 30 ++
 2 files changed, 6 insertions(+), 28 deletions(-)

diff --git a/drivers/isdn/hardware/eicon/debug.c 
b/drivers/isdn/hardware/eicon/debug.c
index b5226af..576b7b4 100644
--- a/drivers/isdn/hardware/eicon/debug.c
+++ b/drivers/isdn/hardware/eicon/debug.c
@@ -192,8 +192,6 @@ static diva_os_spin_lock_t dbg_q_lock;
 static diva_os_spin_lock_t dbg_adapter_lock;
 static int dbg_q_busy;
 static volatile dword  dbg_sequence;
-static dword   start_sec;
-static dword   start_usec;
 
 /*
   INTERFACE:
@@ -215,8 +213,6 @@ int diva_maint_init(byte *base, unsigned long length, int 
do_init) {
 
dbg_base = base;
 
-   diva_os_get_time(_sec, _usec);
-
*(dword *)base  = (dword)DBG_MAGIC; /* Store Magic */
base   += sizeof(dword);
length -= sizeof(dword);
diff --git a/drivers/isdn/hardware/eicon/divamnt.c 
b/drivers/isdn/hardware/eicon/divamnt.c
index 48db08d..0de29b7b 100644
--- a/drivers/isdn/hardware/eicon/divamnt.c
+++ b/drivers/isdn/hardware/eicon/divamnt.c
@@ -45,7 +45,6 @@ char *DRIVERRELEASE_MNT = "2.0";
 
 static wait_queue_head_t msgwaitq;
 static unsigned long opened;
-static struct timeval start_time;
 
 extern int mntfunc_init(int *, void **, unsigned long);
 extern void mntfunc_finit(void);
@@ -88,28 +87,12 @@ int diva_os_copy_from_user(void *os_handle, void *dst, 
const void __user *src,
  */
 void diva_os_get_time(dword *sec, dword *usec)
 {
-   struct timeval tv;
-
-   do_gettimeofday();
-
-   if (tv.tv_sec > start_time.tv_sec) {
-   if (start_time.tv_usec > tv.tv_usec) {
-   tv.tv_sec--;
-   tv.tv_usec += 100;
-   }
-   *sec = (dword) (tv.tv_sec - start_time.tv_sec);
-   *usec = (dword) (tv.tv_usec - start_time.tv_usec);
-   } else if (tv.tv_sec == start_time.tv_sec) {
-   *sec = 0;
-   if (start_time.tv_usec < tv.tv_usec) {
-   *usec = (dword) (tv.tv_usec - start_time.tv_usec);
-   } else {
-   *usec = 0;
-   }
-   } else {
-   *sec = (dword) tv.tv_sec;
-   *usec = (dword) tv.tv_usec;
-   }
+   struct timespec64 time;
+
+   ktime_get_ts64();
+
+   *sec = (dword) time.tv_sec;
+   *usec = (dword) (time.tv_nsec / NSEC_PER_USEC);
 }
 
 /*
@@ -213,7 +196,6 @@ static int __init maint_init(void)
int ret = 0;
void *buffer = NULL;
 
-   do_gettimeofday(_time);
init_waitqueue_head();
 
printk(KERN_INFO "%s\n", DRIVERNAME);
-- 
2.1.4

Re: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

[Viresh Kumar]

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Add cooling properties to all CPUs (suggested by Viresh).
> ---
>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 24 
>  1 file changed, 24 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420

[Viresh Kumar]

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Add cooling properties to all CPUs (suggested by Viresh).
> ---
>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 24 
>  1 file changed, 24 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load

[Viresh Kumar]

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
> be easily overheated when launching eight CPU-intensive tasks:
>   thermal thermal_zone3: critical temperature reached(121 C),shutting down
> 
> This seems to be specific to Odroid XU3-Lite board which officially
> supports lower frequencies than regular XU3 or XU4. When working at
> maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
> longer time, the fan fails to cool down the board and it reaches
> critical temperature.
> 
> Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching last
> interrupt-driven trip-point (70 degrees of Celsius) start passive
> cooling in polling mode (slowing CPU by 2 steps). When reaching 85
> degrees of Celsius, start slowing even more, down to 600 MHz.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Use polling mode for passive cooling (number of configurable trip
>points in TMU exceeded).
> 
> 2. Adjust the values (temperature and cooling levels).
> ---
>  arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 46 
> ++-
>  1 file changed, 45 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load

[Viresh Kumar]

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
> be easily overheated when launching eight CPU-intensive tasks:
>   thermal thermal_zone3: critical temperature reached(121 C),shutting down
> 
> This seems to be specific to Odroid XU3-Lite board which officially
> supports lower frequencies than regular XU3 or XU4. When working at
> maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
> longer time, the fan fails to cool down the board and it reaches
> critical temperature.
> 
> Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching last
> interrupt-driven trip-point (70 degrees of Celsius) start passive
> cooling in polling mode (slowing CPU by 2 steps). When reaching 85
> degrees of Celsius, start slowing even more, down to 600 MHz.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Use polling mode for passive cooling (number of configurable trip
>points in TMU exceeded).
> 
> 2. Adjust the values (temperature and cooling levels).
> ---
>  arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 46 
> ++-
>  1 file changed, 45 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 2/3] ARM: dts: Add cooling levels for CPUs on exynos5422/5800

[Viresh Kumar]

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for 
> LITTLE
> and 18 steps for big core (200-1700 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Add cooling properties to all CPUs (suggested by Viresh).
> ---
>  arch/arm/boot/dts/exynos5422-cpus.dtsi | 24 
>  1 file changed, 24 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 2/3] ARM: dts: Add cooling levels for CPUs on exynos5422/5800

[Viresh Kumar]

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for 
> LITTLE
> and 18 steps for big core (200-1700 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Add cooling properties to all CPUs (suggested by Viresh).
> ---
>  arch/arm/boot/dts/exynos5422-cpus.dtsi | 24 
>  1 file changed, 24 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 12/12] cpufreq: governor: Narrow down the dbs_data_mutex coverage

[Viresh Kumar]

On 18-02-16, 02:38, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Since cpufreq_governor_dbs() is now always called with policy->rwsem
> held, it cannot be executed twice in parallel for the same policy.
> Thus it is not necessary to hold dbs_data_mutex around the invocations
> of cpufreq_governor_start/stop/limits() from it as those functions
> never modify any data that can be shared between different policies.
> 
> However, cpufreq_governor_dbs() may be executed twice in parallal
> for different policies using the same gov->gdbs_data object and
> dbs_data_mutex is still necessary to protect that object against
> concurrent updates.
> 
> For this reason, narrow down the dbs_data_mutex locking to
> cpufreq_governor_init/exit() where it is needed and rename the
> mutex to gov_dbs_data_mutex to reflect its purpose.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_governor.c |   53 
> ++---
>  1 file changed, 27 insertions(+), 26 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -24,7 +24,7 @@
>  
>  static DEFINE_PER_CPU(struct cpu_dbs_info, cpu_dbs);
>  
> -static DEFINE_MUTEX(dbs_data_mutex);
> +static DEFINE_MUTEX(gov_dbs_data_mutex);
>  
>  /* Common sysfs tunables */
>  /**
> @@ -422,10 +422,10 @@ static void free_policy_dbs_info(struct
>  static int cpufreq_governor_init(struct cpufreq_policy *policy)
>  {
>   struct dbs_governor *gov = dbs_governor_of(policy);
> - struct dbs_data *dbs_data = gov->gdbs_data;
> + struct dbs_data *dbs_data;
>   struct policy_dbs_info *policy_dbs;
>   unsigned int latency;
> - int ret;
> + int ret = 0;
>  
>   /* State should be equivalent to EXIT */
>   if (policy->governor_data)
> @@ -435,6 +435,10 @@ static int cpufreq_governor_init(struct
>   if (!policy_dbs)
>   return -ENOMEM;
>  
> + /* Protect gov->gdbs_data against concurrent updates. */
> + mutex_lock(_dbs_data_mutex);
> +
> + dbs_data = gov->gdbs_data;
>   if (dbs_data) {
>   if (WARN_ON(have_governor_per_policy())) {
>   ret = -EINVAL;
> @@ -447,8 +451,7 @@ static int cpufreq_governor_init(struct
>   dbs_data->usage_count++;
>   list_add(_dbs->list, _data->policy_dbs_list);
>   mutex_unlock(_data->mutex);
> -
> - return 0;
> + goto out;
>   }
>  
>   dbs_data = kzalloc(sizeof(*dbs_data), GFP_KERNEL);
> @@ -488,10 +491,14 @@ static int cpufreq_governor_init(struct
>   ret = kobject_init_and_add(_data->kobj, >kobj_type,
>  get_governor_parent_kobj(policy),
>  "%s", gov->gov.name);
> - if (!ret)
> - return 0;
> + if (ret)
> + goto err;
>  
> - /* Failure, so roll back. */
> +out:
> + mutex_unlock(_dbs_data_mutex);
> + return ret;
> +
> +err:

This has turned into an ugly maze, really. I think it would be much
better if we sacrifice a bit on consistency in the code, and move the
locks in cpufreq_governor_dbs() around invocations to
cpufreq_governor_init(). Or maybe create a
__cpufreq_governor_init(), or whatever.

That routine is hardly readably anymore.

-- 
viresh

Re: [PATCH 12/12] cpufreq: governor: Narrow down the dbs_data_mutex coverage

[Viresh Kumar]

On 18-02-16, 02:38, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Since cpufreq_governor_dbs() is now always called with policy->rwsem
> held, it cannot be executed twice in parallel for the same policy.
> Thus it is not necessary to hold dbs_data_mutex around the invocations
> of cpufreq_governor_start/stop/limits() from it as those functions
> never modify any data that can be shared between different policies.
> 
> However, cpufreq_governor_dbs() may be executed twice in parallal
> for different policies using the same gov->gdbs_data object and
> dbs_data_mutex is still necessary to protect that object against
> concurrent updates.
> 
> For this reason, narrow down the dbs_data_mutex locking to
> cpufreq_governor_init/exit() where it is needed and rename the
> mutex to gov_dbs_data_mutex to reflect its purpose.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_governor.c |   53 
> ++---
>  1 file changed, 27 insertions(+), 26 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -24,7 +24,7 @@
>  
>  static DEFINE_PER_CPU(struct cpu_dbs_info, cpu_dbs);
>  
> -static DEFINE_MUTEX(dbs_data_mutex);
> +static DEFINE_MUTEX(gov_dbs_data_mutex);
>  
>  /* Common sysfs tunables */
>  /**
> @@ -422,10 +422,10 @@ static void free_policy_dbs_info(struct
>  static int cpufreq_governor_init(struct cpufreq_policy *policy)
>  {
>   struct dbs_governor *gov = dbs_governor_of(policy);
> - struct dbs_data *dbs_data = gov->gdbs_data;
> + struct dbs_data *dbs_data;
>   struct policy_dbs_info *policy_dbs;
>   unsigned int latency;
> - int ret;
> + int ret = 0;
>  
>   /* State should be equivalent to EXIT */
>   if (policy->governor_data)
> @@ -435,6 +435,10 @@ static int cpufreq_governor_init(struct
>   if (!policy_dbs)
>   return -ENOMEM;
>  
> + /* Protect gov->gdbs_data against concurrent updates. */
> + mutex_lock(_dbs_data_mutex);
> +
> + dbs_data = gov->gdbs_data;
>   if (dbs_data) {
>   if (WARN_ON(have_governor_per_policy())) {
>   ret = -EINVAL;
> @@ -447,8 +451,7 @@ static int cpufreq_governor_init(struct
>   dbs_data->usage_count++;
>   list_add(_dbs->list, _data->policy_dbs_list);
>   mutex_unlock(_data->mutex);
> -
> - return 0;
> + goto out;
>   }
>  
>   dbs_data = kzalloc(sizeof(*dbs_data), GFP_KERNEL);
> @@ -488,10 +491,14 @@ static int cpufreq_governor_init(struct
>   ret = kobject_init_and_add(_data->kobj, >kobj_type,
>  get_governor_parent_kobj(policy),
>  "%s", gov->gov.name);
> - if (!ret)
> - return 0;
> + if (ret)
> + goto err;
>  
> - /* Failure, so roll back. */
> +out:
> + mutex_unlock(_dbs_data_mutex);
> + return ret;
> +
> +err:

This has turned into an ugly maze, really. I think it would be much
better if we sacrifice a bit on consistency in the code, and move the
locks in cpufreq_governor_dbs() around invocations to
cpufreq_governor_init(). Or maybe create a
__cpufreq_governor_init(), or whatever.

That routine is hardly readably anymore.

-- 
viresh

Re: [PATCH 07/54] perf tools: Enable BPF object configure syntax

[Wangnan (F)]

On 2016/2/12 22:09, Jiri Olsa wrote:

On Fri, Feb 05, 2016 at 02:01:32PM +, Wang Nan wrote:

SNIP


  }
  |
-PE_BPF_SOURCE
+PE_BPF_SOURCE opt_event_config
  {
struct parse_events_evlist *data = _data;
struct list_head *list;
  
  	ALLOC_LIST(list);

-   ABORT_ON(parse_events_load_bpf(data, list, $1, true));
+   ABORT_ON(parse_events_load_bpf(data, list, $1, true, $2));
+   parse_events__free_terms($2);
$$ = list;
  }
  
+opt_event_config:

+'/' event_config '/'
+{
+   $$ = $2;
+}
+|
+{
+   $$ = NULL;
+}

can't judge the bpf part, but for the parser part:

Acked-by: Jiri Olsa 


You have already acked this patch before :)

Thank you.

Re: [PATCH 07/54] perf tools: Enable BPF object configure syntax

[Wangnan (F)]

On 2016/2/12 22:09, Jiri Olsa wrote:

On Fri, Feb 05, 2016 at 02:01:32PM +, Wang Nan wrote:

SNIP


  }
  |
-PE_BPF_SOURCE
+PE_BPF_SOURCE opt_event_config
  {
struct parse_events_evlist *data = _data;
struct list_head *list;
  
  	ALLOC_LIST(list);

-   ABORT_ON(parse_events_load_bpf(data, list, $1, true));
+   ABORT_ON(parse_events_load_bpf(data, list, $1, true, $2));
+   parse_events__free_terms($2);
$$ = list;
  }
  
+opt_event_config:

+'/' event_config '/'
+{
+   $$ = $2;
+}
+|
+{
+   $$ = NULL;
+}

can't judge the bpf part, but for the parser part:

Acked-by: Jiri Olsa 


You have already acked this patch before :)

Thank you.

Re: [PATCH 1/4] block: bio: introduce helpers to get the 1st and last bvec

[Ming Lei]

Hi Kent,

Thanks for your review.

On Thu, Feb 18, 2016 at 12:24 PM, Kent Overstreet
 wrote:
> On Mon, Feb 15, 2016 at 05:42:12PM +0800, Ming Lei wrote:
>> Cc Kent and Keith.
>>
>> Follows another version which should be more efficient.
>> Kent and Keith, I appreciate much if you may give a review on it.
>>
>> diff --git a/include/linux/bio.h b/include/linux/bio.h
>> index 56d2db8..ef45fec 100644
>> --- a/include/linux/bio.h
>> +++ b/include/linux/bio.h
>> @@ -278,11 +278,21 @@ static inline void bio_get_first_bvec(struct bio *bio, 
>> struct bio_vec *bv)
>>   */
>>  static inline void bio_get_last_bvec(struct bio *bio, struct bio_vec *bv)
>>  {
>> - struct bvec_iter iter;
>> + struct bvec_iter iter = bio->bi_iter;
>> + int idx;
>> +
>> + bio_advance_iter(bio, , iter.bi_size);
>> +
>> + WARN_ON(!iter.bi_idx && !iter.bi_bvec_done);
>> +
>> + if (!iter.bi_bvec_done)
>> + idx = iter.bi_idx - 1;
>> + else/* in the middle of bvec */
>> + idx = iter.bi_idx;
>>
>> - bio_for_each_segment(*bv, bio, iter)
>> - if (bv->bv_len == iter.bi_size)
>> - break;
>> + *bv = bio->bi_io_vec[idx];
>> + if (iter.bi_bvec_done)
>> + bv->bv_len = iter.bi_bvec_done;
>>  }
>
> It can't be done correctly without a loop.

As we discussed in gtalk, the only case this patch can't cope with
is that one single bvec doesn't use up the remained io vector,
but it can be handled by putting the following code at the
function entry:

if (!bio_multiple_segments(bio)) {
   *bv = bio_iovec(bio);
   return;
}

>
> The reason is that if the bio was split in the middle of a segment, bv->bv_len
> on the last biovec will be larger than what's actually used by the bio (it's
> being shared between the two splits!).

The last two lines in this helper should handle the situation.

>
> You have to iterate over all the biovecs so that you can see where
> bi_iter->bi_size ends.

I understand your concern is that this patch may not be much more
efficient than bio_for_each_segment().

IMO, one win of the patch is that 16bytes bvec copy is saved for all
vectors, and another 'win' is to just run bvec_iter_advance() once(
like move the outside for loop inside).

I will run some benchmark to see if there is any performance
difference between the two patches.

Thanks,
Ming

Re: [PATCH 1/4] block: bio: introduce helpers to get the 1st and last bvec

[Ming Lei]

Hi Kent,

Thanks for your review.

On Thu, Feb 18, 2016 at 12:24 PM, Kent Overstreet
 wrote:
> On Mon, Feb 15, 2016 at 05:42:12PM +0800, Ming Lei wrote:
>> Cc Kent and Keith.
>>
>> Follows another version which should be more efficient.
>> Kent and Keith, I appreciate much if you may give a review on it.
>>
>> diff --git a/include/linux/bio.h b/include/linux/bio.h
>> index 56d2db8..ef45fec 100644
>> --- a/include/linux/bio.h
>> +++ b/include/linux/bio.h
>> @@ -278,11 +278,21 @@ static inline void bio_get_first_bvec(struct bio *bio, 
>> struct bio_vec *bv)
>>   */
>>  static inline void bio_get_last_bvec(struct bio *bio, struct bio_vec *bv)
>>  {
>> - struct bvec_iter iter;
>> + struct bvec_iter iter = bio->bi_iter;
>> + int idx;
>> +
>> + bio_advance_iter(bio, , iter.bi_size);
>> +
>> + WARN_ON(!iter.bi_idx && !iter.bi_bvec_done);
>> +
>> + if (!iter.bi_bvec_done)
>> + idx = iter.bi_idx - 1;
>> + else/* in the middle of bvec */
>> + idx = iter.bi_idx;
>>
>> - bio_for_each_segment(*bv, bio, iter)
>> - if (bv->bv_len == iter.bi_size)
>> - break;
>> + *bv = bio->bi_io_vec[idx];
>> + if (iter.bi_bvec_done)
>> + bv->bv_len = iter.bi_bvec_done;
>>  }
>
> It can't be done correctly without a loop.

As we discussed in gtalk, the only case this patch can't cope with
is that one single bvec doesn't use up the remained io vector,
but it can be handled by putting the following code at the
function entry:

if (!bio_multiple_segments(bio)) {
   *bv = bio_iovec(bio);
   return;
}

>
> The reason is that if the bio was split in the middle of a segment, bv->bv_len
> on the last biovec will be larger than what's actually used by the bio (it's
> being shared between the two splits!).

The last two lines in this helper should handle the situation.

>
> You have to iterate over all the biovecs so that you can see where
> bi_iter->bi_size ends.

I understand your concern is that this patch may not be much more
efficient than bio_for_each_segment().

IMO, one win of the patch is that 16bytes bvec copy is saved for all
vectors, and another 'win' is to just run bvec_iter_advance() once(
like move the outside for loop inside).

I will run some benchmark to see if there is any performance
difference between the two patches.

Thanks,
Ming

Re: [PATCH] regulator: s2mps11: Use local variable for number of regulators

[Andi Shyti]

Thanks,

> Remove the s2mps11_info.rdev_num because it is not used outside of
> probe.
> 
> Suggested-by: Andi Shyti 
> Signed-off-by: Krzysztof Kozlowski 

Reviewed-by: Andi Shyti 

Andi

Re: [PATCH] regulator: s2mps11: Use local variable for number of regulators

[Andi Shyti]

Thanks,

> Remove the s2mps11_info.rdev_num because it is not used outside of
> probe.
> 
> Suggested-by: Andi Shyti 
> Signed-off-by: Krzysztof Kozlowski 

Reviewed-by: Andi Shyti 

Andi

[PATCH v2] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

[Wenyou Yang]

From: Josh Wu 

For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they
need the HSMC clock to be enabled to work.
The NFC is a sub feature for current nand driver, it can be disabled.
But if HSMC clock is controlled by NFC, so disable NFC will also
disable the HSMC clock. then, it will make the PMECC fail to work.

So the solution is to move the HSMC clock out of NFC to nand node.
When nand driver probed, it will check whether the chip has HSMC,
if yes then it will require a HSMC clock.

Signed-off-by: Josh Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v2:
 - add missing .has_hsmc_clk assignment for sama5d2_caps.

 .../devicetree/bindings/mtd/atmel-nand.txt |4 +-
 drivers/mtd/nand/atmel_nand.c  |   44 ++--
 2 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt 
b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index d53aba9..29bee7c 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -15,6 +15,7 @@ Required properties:
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
+- clocks: phandle to the peripheral clock
 
 - gpios : specifies the gpio pins to control the NAND device. detect is an
   optional gpio and may be set to 0 if not present.
@@ -43,7 +44,6 @@ Required properties:
 - reg : should specify the address and size used for NFC command registers,
 NFC registers and NFC SRAM. NFC SRAM address and size can be absent
 if don't want to use it.
-- clocks: phandle to the peripheral clock
 Optional properties:
 - atmel,write-by-sram: boolean to enable NFC write by SRAM.
 
@@ -100,13 +100,13 @@ nand0: nand@4000 {
compatible = "atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
+   clocks = <_clk>
ranges;
 ...
 nfc@7000 {
compatible = "atmel,sama5d3-nfc";
#address-cells = <1>;
#size-cells = <1>;
-   clocks = <_clk>
reg = <
0x7000 0x1000   /* NFC Command Registers */
0xc000 0x0070   /* NFC HSMC regs */
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 20cbaab..26518b0 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
 struct atmel_nand_caps {
bool pmecc_correct_erase_page;
uint8_t pmecc_max_correction;
+   bool has_hsmc_clk;
 };
 
 struct atmel_nand_nfc_caps {
@@ -106,8 +107,6 @@ struct atmel_nfc {
booluse_nfc_sram;
boolwrite_by_sram;
 
-   struct clk  *clk;
-
boolis_initialized;
struct completion   comp_ready;
struct completion   comp_cmd_done;
@@ -132,6 +131,7 @@ struct atmel_nand_host {
struct dma_chan *dma_chan;
 
struct atmel_nfc*nfc;
+   struct clk  *clk;
 
const struct atmel_nand_caps*caps;
boolhas_pmecc;
@@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
nand_chip->IO_ADDR_R = host->io_base;
nand_chip->IO_ADDR_W = host->io_base;
 
+   if (host->caps->has_hsmc_clk) {
+   host->clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(host->clk)) {
+   dev_err(>dev, "HSMC clock is missing, update your 
Device Tree");
+   res = PTR_ERR(host->clk);
+   goto err_nand_ioremap;
+   }
+
+   res = clk_prepare_enable(host->clk);
+   if (res)
+   goto err_nand_ioremap;
+   }
+
if (nand_nfc.is_initialized) {
/* NFC driver is probed and initialized */
host->nfc = _nfc;
@@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
if (host->dma_chan)
dma_release_channel(host->dma_chan);
 
+   if (!IS_ERR(host->clk))
+   clk_disable_unprepare(host->clk);
+
platform_driver_unregister(_nand_nfc_driver);
 
return 0;
@@ -2334,11 +2350,13 @@ static int atmel_nand_remove(struct platform_device 
*pdev)
 static const struct atmel_nand_caps at91rm9200_caps = {
.pmecc_correct_erase_page = false,
.pmecc_max_correction = 24,
+   .has_hsmc_clk = false,
 };
 
 static const struct atmel_nand_caps sama5d4_caps = {
.pmecc_correct_erase_page = true,
.pmecc_max_correction = 24,
+   .has_hsmc_clk = true,
 };
 
 /*
@@ -2348,6 +2366,7 @@ static const struct 

[PATCH v2] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

[Wenyou Yang]

From: Josh Wu 

For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they
need the HSMC clock to be enabled to work.
The NFC is a sub feature for current nand driver, it can be disabled.
But if HSMC clock is controlled by NFC, so disable NFC will also
disable the HSMC clock. then, it will make the PMECC fail to work.

So the solution is to move the HSMC clock out of NFC to nand node.
When nand driver probed, it will check whether the chip has HSMC,
if yes then it will require a HSMC clock.

Signed-off-by: Josh Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v2:
 - add missing .has_hsmc_clk assignment for sama5d2_caps.

 .../devicetree/bindings/mtd/atmel-nand.txt |4 +-
 drivers/mtd/nand/atmel_nand.c  |   44 ++--
 2 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt 
b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index d53aba9..29bee7c 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -15,6 +15,7 @@ Required properties:
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
+- clocks: phandle to the peripheral clock
 
 - gpios : specifies the gpio pins to control the NAND device. detect is an
   optional gpio and may be set to 0 if not present.
@@ -43,7 +44,6 @@ Required properties:
 - reg : should specify the address and size used for NFC command registers,
 NFC registers and NFC SRAM. NFC SRAM address and size can be absent
 if don't want to use it.
-- clocks: phandle to the peripheral clock
 Optional properties:
 - atmel,write-by-sram: boolean to enable NFC write by SRAM.
 
@@ -100,13 +100,13 @@ nand0: nand@4000 {
compatible = "atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
+   clocks = <_clk>
ranges;
 ...
 nfc@7000 {
compatible = "atmel,sama5d3-nfc";
#address-cells = <1>;
#size-cells = <1>;
-   clocks = <_clk>
reg = <
0x7000 0x1000   /* NFC Command Registers */
0xc000 0x0070   /* NFC HSMC regs */
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 20cbaab..26518b0 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
 struct atmel_nand_caps {
bool pmecc_correct_erase_page;
uint8_t pmecc_max_correction;
+   bool has_hsmc_clk;
 };
 
 struct atmel_nand_nfc_caps {
@@ -106,8 +107,6 @@ struct atmel_nfc {
booluse_nfc_sram;
boolwrite_by_sram;
 
-   struct clk  *clk;
-
boolis_initialized;
struct completion   comp_ready;
struct completion   comp_cmd_done;
@@ -132,6 +131,7 @@ struct atmel_nand_host {
struct dma_chan *dma_chan;
 
struct atmel_nfc*nfc;
+   struct clk  *clk;
 
const struct atmel_nand_caps*caps;
boolhas_pmecc;
@@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
nand_chip->IO_ADDR_R = host->io_base;
nand_chip->IO_ADDR_W = host->io_base;
 
+   if (host->caps->has_hsmc_clk) {
+   host->clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(host->clk)) {
+   dev_err(>dev, "HSMC clock is missing, update your 
Device Tree");
+   res = PTR_ERR(host->clk);
+   goto err_nand_ioremap;
+   }
+
+   res = clk_prepare_enable(host->clk);
+   if (res)
+   goto err_nand_ioremap;
+   }
+
if (nand_nfc.is_initialized) {
/* NFC driver is probed and initialized */
host->nfc = _nfc;
@@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
if (host->dma_chan)
dma_release_channel(host->dma_chan);
 
+   if (!IS_ERR(host->clk))
+   clk_disable_unprepare(host->clk);
+
platform_driver_unregister(_nand_nfc_driver);
 
return 0;
@@ -2334,11 +2350,13 @@ static int atmel_nand_remove(struct platform_device 
*pdev)
 static const struct atmel_nand_caps at91rm9200_caps = {
.pmecc_correct_erase_page = false,
.pmecc_max_correction = 24,
+   .has_hsmc_clk = false,
 };
 
 static const struct atmel_nand_caps sama5d4_caps = {
.pmecc_correct_erase_page = true,
.pmecc_max_correction = 24,
+   .has_hsmc_clk = true,
 };
 
 /*
@@ -2348,6 +2366,7 @@ static const struct atmel_nand_caps sama5d4_caps = {
 static const struct atmel_nand_caps 

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

[Mark yao]

On 2016年01月29日 14:42, Yakir Yang wrote:

Here are a brief introduction to Innosilicon HDMI IP:
   - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
   - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
   - Digital video interface supports a pixel size of 24, 30, 36, 48bits color 
depth in RGB
   - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
 (32-192kHz Fs) using IEC60958 and IEC 61937
   - The EDID and CEC function are also supported by Innosilicon HDMI 
Transmitter Controlle

Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause driver
   default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
 - if (data->enc_out_format == data->enc_out_format) {
 + if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
  - MODULE_LICENSE("GPL");
  + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
(Caeser)

Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer 
(Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)

Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

Yakir Yang (2):
   drm/rockchip: hdmi: add Innosilicon HDMI support
   dt-bindings: add document for Innosilicon HDMI on Rockchip platform

  .../display/rockchip/inno_hdmi-rockchip.txt|  50 ++
  drivers/gpu/drm/rockchip/Kconfig   |   8 +
  drivers/gpu/drm/rockchip/Makefile  |   1 +
  drivers/gpu/drm/rockchip/inno_hdmi.c   | 939 +
  drivers/gpu/drm/rockchip/inno_hdmi.h   | 362 
  5 files changed, 1360 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h



Applied to my branch :-) .

Thanks.

--
Ｍark Yao

Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver

[Mark yao]

On 2016年01月29日 14:42, Yakir Yang wrote:

Here are a brief introduction to Innosilicon HDMI IP:
   - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
   - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
   - Digital video interface supports a pixel size of 24, 30, 36, 48bits color 
depth in RGB
   - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
 (32-192kHz Fs) using IEC60958 and IEC 61937
   - The EDID and CEC function are also supported by Innosilicon HDMI 
Transmitter Controlle

Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause driver
   default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
 - if (data->enc_out_format == data->enc_out_format) {
 + if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
  - MODULE_LICENSE("GPL");
  + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver 
(Caeser)

Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer 
(Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)

Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

Yakir Yang (2):
   drm/rockchip: hdmi: add Innosilicon HDMI support
   dt-bindings: add document for Innosilicon HDMI on Rockchip platform

  .../display/rockchip/inno_hdmi-rockchip.txt|  50 ++
  drivers/gpu/drm/rockchip/Kconfig   |   8 +
  drivers/gpu/drm/rockchip/Makefile  |   1 +
  drivers/gpu/drm/rockchip/inno_hdmi.c   | 939 +
  drivers/gpu/drm/rockchip/inno_hdmi.h   | 362 
  5 files changed, 1360 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h



Applied to my branch :-) .

Thanks.

--
Ｍark Yao

Re: [PATCH 11/12] cpufreq: governor: Make dbs_data_mutex static

[Viresh Kumar]

On 18-02-16, 02:33, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> That mutex is only used by cpufreq_governor_dbs() and it doesn't
> need to be exported to modules, so make it static and drop the
> export incantation.
> 
> No functional changes.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_governor.c |3 +--
>  drivers/cpufreq/cpufreq_governor.h |1 -
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -24,8 +24,7 @@
>  
>  static DEFINE_PER_CPU(struct cpu_dbs_info, cpu_dbs);
>  
> -DEFINE_MUTEX(dbs_data_mutex);
> -EXPORT_SYMBOL_GPL(dbs_data_mutex);
> +static DEFINE_MUTEX(dbs_data_mutex);
>  
>  /* Common sysfs tunables */
>  /**
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.h
> @@ -178,7 +178,6 @@ struct od_ops {
>   unsigned int freq_next, unsigned int relation);
>  };
>  
> -extern struct mutex dbs_data_mutex;
>  unsigned int dbs_update(struct cpufreq_policy *policy);
>  int cpufreq_governor_dbs(struct cpufreq_policy *policy, unsigned int event);
>  void od_register_powersave_bias_handler(unsigned int (*f)


Acked-by: Viresh Kumar 
-- 
viresh

Re: [PATCH 11/12] cpufreq: governor: Make dbs_data_mutex static

[Viresh Kumar]

On 18-02-16, 02:33, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> That mutex is only used by cpufreq_governor_dbs() and it doesn't
> need to be exported to modules, so make it static and drop the
> export incantation.
> 
> No functional changes.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_governor.c |3 +--
>  drivers/cpufreq/cpufreq_governor.h |1 -
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -24,8 +24,7 @@
>  
>  static DEFINE_PER_CPU(struct cpu_dbs_info, cpu_dbs);
>  
> -DEFINE_MUTEX(dbs_data_mutex);
> -EXPORT_SYMBOL_GPL(dbs_data_mutex);
> +static DEFINE_MUTEX(dbs_data_mutex);
>  
>  /* Common sysfs tunables */
>  /**
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.h
> @@ -178,7 +178,6 @@ struct od_ops {
>   unsigned int freq_next, unsigned int relation);
>  };
>  
> -extern struct mutex dbs_data_mutex;
>  unsigned int dbs_update(struct cpufreq_policy *policy);
>  int cpufreq_governor_dbs(struct cpufreq_policy *policy, unsigned int event);
>  void od_register_powersave_bias_handler(unsigned int (*f)


Acked-by: Viresh Kumar 
-- 
viresh

Re: [PATCH 10/12] cpufreq: governor: Relocate definitions of tuners structures

[Viresh Kumar]

On 18-02-16, 02:32, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Move the definitions of struct od_dbs_tuners and struct cs_dbs_tuners
> from the common governor header to the ondemand and conservative
> governor code, respectively, as they don't need to be in the common
> header any more.
> 
> No functional changes.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_conservative.c |5 +
>  drivers/cpufreq/cpufreq_governor.h |   10 --
>  drivers/cpufreq/cpufreq_ondemand.c |4 
>  3 files changed, 9 insertions(+), 10 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 10/12] cpufreq: governor: Relocate definitions of tuners structures

[Viresh Kumar]

On 18-02-16, 02:32, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Move the definitions of struct od_dbs_tuners and struct cs_dbs_tuners
> from the common governor header to the ondemand and conservative
> governor code, respectively, as they don't need to be in the common
> header any more.
> 
> No functional changes.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_conservative.c |5 +
>  drivers/cpufreq/cpufreq_governor.h |   10 --
>  drivers/cpufreq/cpufreq_ondemand.c |4 
>  3 files changed, 9 insertions(+), 10 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 9/12] cpufreq: governor: Move per-CPU data to the common code

[Viresh Kumar]

On 18-02-16, 02:31, Rafael J. Wysocki wrote:
> @@ -464,21 +455,24 @@ static void od_set_powersave_bias(unsign
>  
>   get_online_cpus();
>   for_each_online_cpu(cpu) {
> + struct cpufreq_policy *policy;
>   struct policy_dbs_info *policy_dbs;
> + struct dbs_data *dbs_data;
> + struct od_dbs_tuners *od_tuners;
>  
>   if (cpumask_test_cpu(cpu, ))
>   continue;
>  
> - policy_dbs = per_cpu(od_cpu_dbs_info, cpu).cdbs.policy_dbs;
> + policy = cpufreq_cpu_get_raw(cpu);

This is surely racy, as this might get called while governors are
getting exchanged. But this is racy today as well.

We should be using the list of policies present with the governors
here, with dbs_data->lock or something like that.


Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 9/12] cpufreq: governor: Move per-CPU data to the common code

[Viresh Kumar]

On 18-02-16, 02:31, Rafael J. Wysocki wrote:
> @@ -464,21 +455,24 @@ static void od_set_powersave_bias(unsign
>  
>   get_online_cpus();
>   for_each_online_cpu(cpu) {
> + struct cpufreq_policy *policy;
>   struct policy_dbs_info *policy_dbs;
> + struct dbs_data *dbs_data;
> + struct od_dbs_tuners *od_tuners;
>  
>   if (cpumask_test_cpu(cpu, ))
>   continue;
>  
> - policy_dbs = per_cpu(od_cpu_dbs_info, cpu).cdbs.policy_dbs;
> + policy = cpufreq_cpu_get_raw(cpu);

This is surely racy, as this might get called while governors are
getting exchanged. But this is racy today as well.

We should be using the list of policies present with the governors
here, with dbs_data->lock or something like that.


Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 8/12] cpufreq: governor: Make governor private data per-policy

[Viresh Kumar]

On 18-02-16, 02:30, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Some fields in struct od_cpu_dbs_info_s and struct cs_cpu_dbs_info_s
> are only used for a limited set of CPUs.  Namely, if a policy is
> shared between multiple CPUs, those fields will only be used for one
> of them (policy->cpu).  This means that they really are per-policy
> rather than per-CPU and holding room for them in per-CPU data
> structures is generally wasteful.  Also moving those fields into
> per-policy data structures will allow some significant simplifications
> to be made going forward.
> 
> For this reason, introduce struct cs_policy_dbs_info and
> struct od_policy_dbs_info to hold those fields.  Define each of the
> new structures as an extension of struct policy_dbs_info (such that
> struct policy_dbs_info is embedded in each of them) and introduce
> new ->alloc and ->free governor callbacks to allocate and free
> those structures, respectively, such that ->alloc() will return
> a pointer to the struct policy_dbs_info embedded in the allocated
> data structure and ->free() will take that pointer as its argument.
> 
> With that, modify the code accessing the data fields in question
> in per-CPU data objects to look for them in the new structures
> via the struct policy_dbs_info pointer available to it and drop
> them from struct od_cpu_dbs_info_s and struct cs_cpu_dbs_info_s.

Fantastic, that's what I just suggested in the previous patch :)


Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 8/12] cpufreq: governor: Make governor private data per-policy

[Viresh Kumar]

On 18-02-16, 02:30, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Some fields in struct od_cpu_dbs_info_s and struct cs_cpu_dbs_info_s
> are only used for a limited set of CPUs.  Namely, if a policy is
> shared between multiple CPUs, those fields will only be used for one
> of them (policy->cpu).  This means that they really are per-policy
> rather than per-CPU and holding room for them in per-CPU data
> structures is generally wasteful.  Also moving those fields into
> per-policy data structures will allow some significant simplifications
> to be made going forward.
> 
> For this reason, introduce struct cs_policy_dbs_info and
> struct od_policy_dbs_info to hold those fields.  Define each of the
> new structures as an extension of struct policy_dbs_info (such that
> struct policy_dbs_info is embedded in each of them) and introduce
> new ->alloc and ->free governor callbacks to allocate and free
> those structures, respectively, such that ->alloc() will return
> a pointer to the struct policy_dbs_info embedded in the allocated
> data structure and ->free() will take that pointer as its argument.
> 
> With that, modify the code accessing the data fields in question
> in per-CPU data objects to look for them in the new structures
> via the struct policy_dbs_info pointer available to it and drop
> them from struct od_cpu_dbs_info_s and struct cs_cpu_dbs_info_s.

Fantastic, that's what I just suggested in the previous patch :)


Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH RESEND v3] asus-nb-wmi: add wapf=4 quirk for ASUS X75VD

[Oleksandr Natalenko]

Thanks for your patience ;).

On середа, 17 лютого 2016 р. 21:23:45 EET Darren Hart wrote:
> On Wed, Feb 17, 2016 at 01:35:46PM +0200, Oleksandr Natalenko wrote:
> > Wi-Fi on ASUS X75VD laptop does not work unless asus_nb_wmi module
> > is loaded with wapf=4 option. Add quirk for this.
> > 
> > Signed-off-by: Oleksandr Natalenko 
> 
> Queued to testing, thanks.

Re: [PATCH RESEND v3] asus-nb-wmi: add wapf=4 quirk for ASUS X75VD

[Oleksandr Natalenko]

Thanks for your patience ;).

On середа, 17 лютого 2016 р. 21:23:45 EET Darren Hart wrote:
> On Wed, Feb 17, 2016 at 01:35:46PM +0200, Oleksandr Natalenko wrote:
> > Wi-Fi on ASUS X75VD laptop does not work unless asus_nb_wmi module
> > is loaded with wapf=4 option. Add quirk for this.
> > 
> > Signed-off-by: Oleksandr Natalenko 
> 
> Queued to testing, thanks.