Re: [PATCH resend v2] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data

[Peter Hurley]

Hi Cyrill,

On 04/07/2016 05:53 AM, Cyrill Gorcunov wrote:
> Currently when we checkpoint PTY connections we ignore data queued inside
> read buffer of ldisk, such data is barely lost after the restore. So we
> would like to have an ability to dump and restore it.

Do you want to be able to restore the exact state (like column and
newline markers)?

I'm wondering if a for-purpose checkpoint/restore ioctl would be more
appropriate?

A generic peek() may find other uses which could make future improvements
difficult.

Plus this ioctl() is only reading the 4k line discipline read buffer, and
not the tty buffers which could contain up to another 8k of unprocessed
input.


> Here is a new ioctl code which simply copies data from read buffer into
> the userspace without any additional processing (just like terminal is
> sitting in a raw mode).
> 
> The idea behind is when we checkpointing PTY pairs we peek this unread
> data into images on disk and on restore phase we find the linked peer
> and write it back thus reading peer will see it in read buffer.

Have you frozen every process with either end open? I could see how this would
be easy for an entire process group but what if the processes are unrelated?
How do you ensure you have the correct linked peer with multiple devpts 
instances?


> I tried several approaches (including simply reuse of canon_copy_from_read_buf
> and copy_from_read_buf) but it makes code more complicated, so I end up
> in plain copying of buffer data.
> 
> Strictly speaking, we could try handle it inside CRIU itself, as
> Peter Hurley proposed (switch terminal to raw mode, read data,
> and return original termios back) but in this case we may hit
> the scenario when we read data and failed to restore it back
> (due to any error) leaving the task we're dumping without
> read buffer, thus peeking data looks like be the only
> safe way.

Code comments below.


> v2:
>  - Use @char in ioctl definition.
> 
> Signed-off-by: Cyrill Gorcunov 
> CC: Jiri Slaby 
> CC: Peter Hurley 
> CC: Greg Kroah-Hartman 
> CC: Andrey Vagin 
> CC: Pavel Emelianov 
> CC: Vladimir Davydov 
> CC: Konstantin Khorenko 
> ---
>  drivers/tty/n_tty.c   |   22 ++
>  include/uapi/asm-generic/ioctls.h |1 +
>  2 files changed, 23 insertions(+)
> 
> Index: linux-ml.git/drivers/tty/n_tty.c
> ===
> --- linux-ml.git.orig/drivers/tty/n_tty.c
> +++ linux-ml.git/drivers/tty/n_tty.c
> @@ -2420,6 +2420,26 @@ static unsigned long inq_canon(struct n_
>   return nr;
>  }
>  
> +static ssize_t n_tty_peek_raw(struct tty_struct *tty, unsigned char __user 
> *buf)

function name is redundant; n_tty_peek() is sufficient.

Needs a buffer-length parameter; could return the size required to completely
copy the ldisc read buffer, if smaller than required.


> +{
> + struct n_tty_data *ldata = tty->disc_data;
> + ssize_t retval;
> +
> + if (!mutex_trylock(>atomic_read_lock))
> + return -EAGAIN;
> +
> + down_read(>termios_rwsem);

Why take these two locks if parallel operations are not expected?
Conversely, I would expect this to assert current state is TASK_TRACED.

Assuming the other pty end is halted, this ioctl would also need to
wait for the input kworker to stop:

--- >% ---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index a946e49..744cb87 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -614,3 +614,8 @@ bool tty_buffer_cancel_work(struct tty_port *port)
 {
return cancel_work_sync(>buf.work);
 }
+
+void tty_buffer_flush_work(struct tty_port *port)
+{
+   flush_work(>buf.work);
+}
diff --git a/include/linux/tty.h b/include/linux/tty.h
index bf1bcdb..a541132 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -480,6 +480,7 @@ extern void tty_buffer_init(struct tty_port *port);
 extern void tty_buffer_set_lock_subclass(struct tty_port *port);
 extern bool tty_buffer_restart_work(struct tty_port *port);
 extern bool tty_buffer_cancel_work(struct tty_port *port);
+extern void tty_buffer_flush_work(struct tty_port *port);
 extern speed_t tty_termios_baud_rate(struct ktermios *termios);
 extern speed_t tty_termios_input_baud_rate(struct ktermios *termios);
 extern void tty_termios_encode_baud_rate(struct ktermios *termios,





tty_buffer_flush_work(tty->port);

> + retval = read_cnt(ldata);
> + if (retval) {
> + const unsigned char *from = read_buf_addr(ldata, 
> ldata->read_tail);
> + if (copy_to_user(buf, from, retval))
> + retval = -EFAULT;
> + }
> + up_read(>termios_rwsem);
> + mutex_unlock(>atomic_read_lock);
> + return retval;
> +}
> +
>  static int n_tty_ioctl(struct tty_struct *tty, 

Re: [PATCH resend v2] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data

[Peter Hurley]

Hi Cyrill,

On 04/07/2016 05:53 AM, Cyrill Gorcunov wrote:
> Currently when we checkpoint PTY connections we ignore data queued inside
> read buffer of ldisk, such data is barely lost after the restore. So we
> would like to have an ability to dump and restore it.

Do you want to be able to restore the exact state (like column and
newline markers)?

I'm wondering if a for-purpose checkpoint/restore ioctl would be more
appropriate?

A generic peek() may find other uses which could make future improvements
difficult.

Plus this ioctl() is only reading the 4k line discipline read buffer, and
not the tty buffers which could contain up to another 8k of unprocessed
input.


> Here is a new ioctl code which simply copies data from read buffer into
> the userspace without any additional processing (just like terminal is
> sitting in a raw mode).
> 
> The idea behind is when we checkpointing PTY pairs we peek this unread
> data into images on disk and on restore phase we find the linked peer
> and write it back thus reading peer will see it in read buffer.

Have you frozen every process with either end open? I could see how this would
be easy for an entire process group but what if the processes are unrelated?
How do you ensure you have the correct linked peer with multiple devpts 
instances?


> I tried several approaches (including simply reuse of canon_copy_from_read_buf
> and copy_from_read_buf) but it makes code more complicated, so I end up
> in plain copying of buffer data.
> 
> Strictly speaking, we could try handle it inside CRIU itself, as
> Peter Hurley proposed (switch terminal to raw mode, read data,
> and return original termios back) but in this case we may hit
> the scenario when we read data and failed to restore it back
> (due to any error) leaving the task we're dumping without
> read buffer, thus peeking data looks like be the only
> safe way.

Code comments below.


> v2:
>  - Use @char in ioctl definition.
> 
> Signed-off-by: Cyrill Gorcunov 
> CC: Jiri Slaby 
> CC: Peter Hurley 
> CC: Greg Kroah-Hartman 
> CC: Andrey Vagin 
> CC: Pavel Emelianov 
> CC: Vladimir Davydov 
> CC: Konstantin Khorenko 
> ---
>  drivers/tty/n_tty.c   |   22 ++
>  include/uapi/asm-generic/ioctls.h |1 +
>  2 files changed, 23 insertions(+)
> 
> Index: linux-ml.git/drivers/tty/n_tty.c
> ===
> --- linux-ml.git.orig/drivers/tty/n_tty.c
> +++ linux-ml.git/drivers/tty/n_tty.c
> @@ -2420,6 +2420,26 @@ static unsigned long inq_canon(struct n_
>   return nr;
>  }
>  
> +static ssize_t n_tty_peek_raw(struct tty_struct *tty, unsigned char __user 
> *buf)

function name is redundant; n_tty_peek() is sufficient.

Needs a buffer-length parameter; could return the size required to completely
copy the ldisc read buffer, if smaller than required.


> +{
> + struct n_tty_data *ldata = tty->disc_data;
> + ssize_t retval;
> +
> + if (!mutex_trylock(>atomic_read_lock))
> + return -EAGAIN;
> +
> + down_read(>termios_rwsem);

Why take these two locks if parallel operations are not expected?
Conversely, I would expect this to assert current state is TASK_TRACED.

Assuming the other pty end is halted, this ioctl would also need to
wait for the input kworker to stop:

--- >% ---
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index a946e49..744cb87 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -614,3 +614,8 @@ bool tty_buffer_cancel_work(struct tty_port *port)
 {
return cancel_work_sync(>buf.work);
 }
+
+void tty_buffer_flush_work(struct tty_port *port)
+{
+   flush_work(>buf.work);
+}
diff --git a/include/linux/tty.h b/include/linux/tty.h
index bf1bcdb..a541132 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -480,6 +480,7 @@ extern void tty_buffer_init(struct tty_port *port);
 extern void tty_buffer_set_lock_subclass(struct tty_port *port);
 extern bool tty_buffer_restart_work(struct tty_port *port);
 extern bool tty_buffer_cancel_work(struct tty_port *port);
+extern void tty_buffer_flush_work(struct tty_port *port);
 extern speed_t tty_termios_baud_rate(struct ktermios *termios);
 extern speed_t tty_termios_input_baud_rate(struct ktermios *termios);
 extern void tty_termios_encode_baud_rate(struct ktermios *termios,





tty_buffer_flush_work(tty->port);

> + retval = read_cnt(ldata);
> + if (retval) {
> + const unsigned char *from = read_buf_addr(ldata, 
> ldata->read_tail);
> + if (copy_to_user(buf, from, retval))
> + retval = -EFAULT;
> + }
> + up_read(>termios_rwsem);
> + mutex_unlock(>atomic_read_lock);
> + return retval;
> +}
> +
>  static int n_tty_ioctl(struct tty_struct *tty, struct file *file,
>  unsigned int cmd, unsigned long arg)
>  {
> @@ -2437,6 +2457,8 @@ static int n_tty_ioctl(struct tty_struct
>   retval = 

Re: [PATCH 03/10] mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race

[Anshuman Khandual]

On 04/07/2016 02:56 PM, Balbir Singh wrote:
> 
> On 07/04/16 15:37, Anshuman Khandual wrote:
>> > follow_huge_(pmd|pud|pgd) functions are used to walk the page table and
>> > fetch the page struct during 'follow_page_mask' call. There are possible
>> > race conditions faced by these functions which arise out of simultaneous
>> > calls of move_pages() and freeing of huge pages. This was fixed partly
>> > by the previous commit e66f17ff7177 ("mm/hugetlb: take page table lock
>> > in follow_huge_pmd()") for only PMD based huge pages.
>> > 
>> > After implementing similar logic, functions like follow_huge_(pud|pgd)
>> > are now safe from above mentioned race conditions and also can support
>> > FOLL_GET. Generic version of the function 'follow_huge_addr' has been
>> > left as it is and its upto the architecture to decide on it.
>> > 
>> > Signed-off-by: Anshuman Khandual 
>> > ---
>> >  include/linux/mm.h | 33 +++
>> >  mm/hugetlb.c   | 67 
>> > ++
>> >  2 files changed, 91 insertions(+), 9 deletions(-)
>> > 
>> > diff --git a/include/linux/mm.h b/include/linux/mm.h
>> > index ffcff53..734182a 100644
>> > --- a/include/linux/mm.h
>> > +++ b/include/linux/mm.h
>> > @@ -1751,6 +1751,19 @@ static inline void pgtable_page_dtor(struct page 
>> > *page)
>> >NULL: pte_offset_kernel(pmd, address))
>> >  
>> >  #if USE_SPLIT_PMD_PTLOCKS
> Do we still use USE_SPLIT_PMD_PTLOCKS? I think its good enough. with pgd's
> we are likely to use the same locks and the split nature may not be really
> split.
> 

Sorry Balbir, did not get what you asked. Can you please elaborate on
this ?

Re: [PATCH 03/10] mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race

[Anshuman Khandual]

On 04/07/2016 02:56 PM, Balbir Singh wrote:
> 
> On 07/04/16 15:37, Anshuman Khandual wrote:
>> > follow_huge_(pmd|pud|pgd) functions are used to walk the page table and
>> > fetch the page struct during 'follow_page_mask' call. There are possible
>> > race conditions faced by these functions which arise out of simultaneous
>> > calls of move_pages() and freeing of huge pages. This was fixed partly
>> > by the previous commit e66f17ff7177 ("mm/hugetlb: take page table lock
>> > in follow_huge_pmd()") for only PMD based huge pages.
>> > 
>> > After implementing similar logic, functions like follow_huge_(pud|pgd)
>> > are now safe from above mentioned race conditions and also can support
>> > FOLL_GET. Generic version of the function 'follow_huge_addr' has been
>> > left as it is and its upto the architecture to decide on it.
>> > 
>> > Signed-off-by: Anshuman Khandual 
>> > ---
>> >  include/linux/mm.h | 33 +++
>> >  mm/hugetlb.c   | 67 
>> > ++
>> >  2 files changed, 91 insertions(+), 9 deletions(-)
>> > 
>> > diff --git a/include/linux/mm.h b/include/linux/mm.h
>> > index ffcff53..734182a 100644
>> > --- a/include/linux/mm.h
>> > +++ b/include/linux/mm.h
>> > @@ -1751,6 +1751,19 @@ static inline void pgtable_page_dtor(struct page 
>> > *page)
>> >NULL: pte_offset_kernel(pmd, address))
>> >  
>> >  #if USE_SPLIT_PMD_PTLOCKS
> Do we still use USE_SPLIT_PMD_PTLOCKS? I think its good enough. with pgd's
> we are likely to use the same locks and the split nature may not be really
> split.
> 

Sorry Balbir, did not get what you asked. Can you please elaborate on
this ?

Re: [PATCH 2/2] powerpc/drivers: Add driver for operator panel on FSP machines

[Andrew Donnellan]

On 11/04/16 11:41, Suraj Jitindar Singh wrote:

Implement new character device driver to allow access from user space
to the 2x16 character operator panel display present on powernv machines.


Specifically, on IBM Power Systems machines with FSPs (see comments below).


This will allow status information to be presented on the display which
is visible to a user.

The driver implements a 32 character buffer which a user can read/write
by accessing the device (/dev/oppanel). This buffer is then displayed on
the operator panel display. Any attempt to write past the 32nd position
will have no effect and attempts to write more than 32 characters will be
truncated. Valid characters are ascii: '.', '/', ':', '0-9', 'a-z',
'A-Z'. All other characters are considered invalid and will be replaced
with '.'.


For reference, the ASCII character whitelist is enforced by skiboot, not 
by the driver (see 
https://github.com/open-power/skiboot/blob/master/hw/fsp/fsp-op-panel.c#L217). 
It's been included ever since the first public release of skiboot, so 
this statement is true for all machines at present, though theoretically 
might not be true in future skiboots or alternative OPAL implementations 
(should someone be crazy enough to write one).



A write call past the 32nd character will return zero characters
written. A write call will not clear the display and it is up to the
user to put spaces (' ') where blank space is required. The device may
only be accessed by a single process at a time.

Signed-off-by: Suraj Jitindar Singh 


I reviewed an earlier version of this patch internally and Suraj has 
fixed a bunch of issues which I raised. I'm not hugely experienced with 
this, but all the obvious things I noticed have gone, so...


Reviewed-by: Andrew Donnellan 

A couple of minor nitpicks below.


diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 3ec0766..8c91edf 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -178,6 +178,20 @@ config IBM_BSR
  of threads across a large system which avoids bouncing a cacheline
  between several cores on a system

+config IBM_OP_PANEL
+   tristate "IBM POWER Operator Panel Display support"
+   depends on PPC_POWERNV
+   default m
+   help
+ If you say Y here, a special character device node /dev/oppanel will


Add commas: "node, /dev/oppanel, will"


diff --git a/drivers/char/op-panel-powernv.c b/drivers/char/op-panel-powernv.c
new file mode 100644
index 000..cc72c5d
--- /dev/null
+++ b/drivers/char/op-panel-powernv.c

[...]

+/*
+ * This driver creates a character device (/dev/oppanel) which exposes the
+ * operator panel display (2x16 character display) on IBM pSeries machines.


I'd prefer "IBM Power Systems machines with FSPs" so as to avoid 
confusion with the Linux pseries platform, to be in line with current 
IBM branding, and to emphasise that it's only FSP machines (the Power 
Systems LC models are not).


Hmm, perhaps also mention that in the Kconfig description too?

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: [PATCH 2/2] powerpc/drivers: Add driver for operator panel on FSP machines

[Andrew Donnellan]

On 11/04/16 11:41, Suraj Jitindar Singh wrote:

Implement new character device driver to allow access from user space
to the 2x16 character operator panel display present on powernv machines.


Specifically, on IBM Power Systems machines with FSPs (see comments below).


This will allow status information to be presented on the display which
is visible to a user.

The driver implements a 32 character buffer which a user can read/write
by accessing the device (/dev/oppanel). This buffer is then displayed on
the operator panel display. Any attempt to write past the 32nd position
will have no effect and attempts to write more than 32 characters will be
truncated. Valid characters are ascii: '.', '/', ':', '0-9', 'a-z',
'A-Z'. All other characters are considered invalid and will be replaced
with '.'.


For reference, the ASCII character whitelist is enforced by skiboot, not 
by the driver (see 
https://github.com/open-power/skiboot/blob/master/hw/fsp/fsp-op-panel.c#L217). 
It's been included ever since the first public release of skiboot, so 
this statement is true for all machines at present, though theoretically 
might not be true in future skiboots or alternative OPAL implementations 
(should someone be crazy enough to write one).



A write call past the 32nd character will return zero characters
written. A write call will not clear the display and it is up to the
user to put spaces (' ') where blank space is required. The device may
only be accessed by a single process at a time.

Signed-off-by: Suraj Jitindar Singh 


I reviewed an earlier version of this patch internally and Suraj has 
fixed a bunch of issues which I raised. I'm not hugely experienced with 
this, but all the obvious things I noticed have gone, so...


Reviewed-by: Andrew Donnellan 

A couple of minor nitpicks below.


diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 3ec0766..8c91edf 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -178,6 +178,20 @@ config IBM_BSR
  of threads across a large system which avoids bouncing a cacheline
  between several cores on a system

+config IBM_OP_PANEL
+   tristate "IBM POWER Operator Panel Display support"
+   depends on PPC_POWERNV
+   default m
+   help
+ If you say Y here, a special character device node /dev/oppanel will


Add commas: "node, /dev/oppanel, will"


diff --git a/drivers/char/op-panel-powernv.c b/drivers/char/op-panel-powernv.c
new file mode 100644
index 000..cc72c5d
--- /dev/null
+++ b/drivers/char/op-panel-powernv.c

[...]

+/*
+ * This driver creates a character device (/dev/oppanel) which exposes the
+ * operator panel display (2x16 character display) on IBM pSeries machines.


I'd prefer "IBM Power Systems machines with FSPs" so as to avoid 
confusion with the Linux pseries platform, to be in line with current 
IBM branding, and to emphasise that it's only FSP machines (the Power 
Systems LC models are not).


Hmm, perhaps also mention that in the Kconfig description too?

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: [PATCH v5 6/9] irqchip/gic-v3: Parse and export virtual GIC information

[Hanjun Guo]

On 2016/4/4 19:37, Julien Grall wrote:

Fill up the recently introduced gic_kvm_info with the hardware
information used for virtualization.

Signed-off-by: Julien Grall 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 

---
 Changes in v5:
 - Remove the alignment check for GICV. It's already done in the
 KVM code.
 - Fix initialization of KVM with ACPI.

 Changes in v4:
 - Change the flow to call gic_kvm_set_info only when all the
 mandatory information are valid.
 - Remove unecessary code in ACPI parsing (the virtual control
 interface doesn't exist for GICv3).
 - Rework commit message
 - Rework the ACPI support as it didn't collect hardware info for
 virtualization when there is more than 1 redistributor region

 Changes in v3:
 - Add ACPI support

 Changes in v2:
 - Use 0 rather than a negative value to know when the maintenance IRQ
 is not present.
 - Use resource for vcpu and vctrl
---
  drivers/irqchip/irq-gic-v3.c   | 110 -
  include/linux/irqchip/arm-gic-common.h |   1 +
  2 files changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 50e87e6..08afbfe 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -28,6 +28,7 @@
  #include 

  #include 
+#include 
  #include 

  #include 
@@ -56,6 +57,8 @@ struct gic_chip_data {
  static struct gic_chip_data gic_data __read_mostly;
  static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;

+static struct gic_kvm_info gic_v3_kvm_info;
+
  #define gic_data_rdist()  (this_cpu_ptr(gic_data.rdists.rdist))
  #define gic_data_rdist_rd_base()  (gic_data_rdist()->rd_base)
  #define gic_data_rdist_sgi_base() (gic_data_rdist_rd_base() + SZ_64K)
@@ -901,6 +904,30 @@ static int __init gic_validate_dist_version(void __iomem 
*dist_base)
return 0;
  }

+static void __init gic_of_setup_kvm_info(struct device_node *node)
+{
+   int ret;
+   struct resource r;
+   u32 gicv_idx;
+
+   gic_v3_kvm_info.type = GIC_V3;
+
+   gic_v3_kvm_info.maint_irq = irq_of_parse_and_map(node, 0);
+   if (!gic_v3_kvm_info.maint_irq)
+   return;
+
+   if (of_property_read_u32(node, "#redistributor-regions",
+_idx))
+   gicv_idx = 1;
+
+   gicv_idx += 3;  /* Also skip GICD, GICC, GICH */
+   ret = of_address_to_resource(node, gicv_idx, );
+   if (!ret)
+   gic_v3_kvm_info.vcpu = r;
+
+   gic_set_kvm_info(_v3_kvm_info);
+}
+
  static int __init gic_of_init(struct device_node *node, struct device_node 
*parent)
  {
void __iomem *dist_base;
@@ -952,8 +979,10 @@ static int __init gic_of_init(struct device_node *node, 
struct device_node *pare

err = gic_init_bases(dist_base, rdist_regs, nr_redist_regions,
 redist_stride, >fwnode);
-   if (!err)
+   if (!err) {
+   gic_of_setup_kvm_info(node);
return 0;
+   }

  out_unmap_rdist:
for (i = 0; i < nr_redist_regions; i++)
@@ -974,6 +1003,9 @@ static struct
struct redist_region *redist_regs;
u32 nr_redist_regions;
bool single_redist;
+   u32 maint_irq;
+   int maint_irq_mode;
+   phys_addr_t vcpu_base;
  } acpi_data __initdata;

  static void __init
@@ -1110,7 +1142,81 @@ static bool __init acpi_validate_gic_table(struct 
acpi_subtable_header *header,
return true;
  }

+static int __init gic_acpi_parse_virt_madt_gicc(struct acpi_subtable_header 
*header,
+   const unsigned long end)
+{
+   struct acpi_madt_generic_interrupt *gicc =
+   (struct acpi_madt_generic_interrupt *)header;
+   int maint_irq_mode;
+   static int first_madt = true;
+
+   maint_irq_mode = (gicc->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
+   ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
+
+   if (first_madt) {
+   first_madt = false;
+
+   acpi_data.maint_irq = gicc->vgic_interrupt;
+   acpi_data.maint_irq_mode = maint_irq_mode;
+   acpi_data.vcpu_base = gicc->gicv_base_address;
+
+   return 0;
+   }
+
+   /*
+* The maintenance interrupt and GICV should be the same for every CPU
+*/
+   if ((acpi_data.maint_irq != gicc->vgic_interrupt) ||
+   (acpi_data.maint_irq_mode != maint_irq_mode) ||
+   (acpi_data.vcpu_base != gicc->gicv_base_address))
+   return -EINVAL;
+
+   return 0;
+}
+
+static bool __init gic_acpi_collect_virt_info(void)
+{
+   int count;
+
+   count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+ 

Re: [PATCH v5 6/9] irqchip/gic-v3: Parse and export virtual GIC information

[Hanjun Guo]

On 2016/4/4 19:37, Julien Grall wrote:

Fill up the recently introduced gic_kvm_info with the hardware
information used for virtualization.

Signed-off-by: Julien Grall 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 

---
 Changes in v5:
 - Remove the alignment check for GICV. It's already done in the
 KVM code.
 - Fix initialization of KVM with ACPI.

 Changes in v4:
 - Change the flow to call gic_kvm_set_info only when all the
 mandatory information are valid.
 - Remove unecessary code in ACPI parsing (the virtual control
 interface doesn't exist for GICv3).
 - Rework commit message
 - Rework the ACPI support as it didn't collect hardware info for
 virtualization when there is more than 1 redistributor region

 Changes in v3:
 - Add ACPI support

 Changes in v2:
 - Use 0 rather than a negative value to know when the maintenance IRQ
 is not present.
 - Use resource for vcpu and vctrl
---
  drivers/irqchip/irq-gic-v3.c   | 110 -
  include/linux/irqchip/arm-gic-common.h |   1 +
  2 files changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 50e87e6..08afbfe 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -28,6 +28,7 @@
  #include 

  #include 
+#include 
  #include 

  #include 
@@ -56,6 +57,8 @@ struct gic_chip_data {
  static struct gic_chip_data gic_data __read_mostly;
  static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;

+static struct gic_kvm_info gic_v3_kvm_info;
+
  #define gic_data_rdist()  (this_cpu_ptr(gic_data.rdists.rdist))
  #define gic_data_rdist_rd_base()  (gic_data_rdist()->rd_base)
  #define gic_data_rdist_sgi_base() (gic_data_rdist_rd_base() + SZ_64K)
@@ -901,6 +904,30 @@ static int __init gic_validate_dist_version(void __iomem 
*dist_base)
return 0;
  }

+static void __init gic_of_setup_kvm_info(struct device_node *node)
+{
+   int ret;
+   struct resource r;
+   u32 gicv_idx;
+
+   gic_v3_kvm_info.type = GIC_V3;
+
+   gic_v3_kvm_info.maint_irq = irq_of_parse_and_map(node, 0);
+   if (!gic_v3_kvm_info.maint_irq)
+   return;
+
+   if (of_property_read_u32(node, "#redistributor-regions",
+_idx))
+   gicv_idx = 1;
+
+   gicv_idx += 3;  /* Also skip GICD, GICC, GICH */
+   ret = of_address_to_resource(node, gicv_idx, );
+   if (!ret)
+   gic_v3_kvm_info.vcpu = r;
+
+   gic_set_kvm_info(_v3_kvm_info);
+}
+
  static int __init gic_of_init(struct device_node *node, struct device_node 
*parent)
  {
void __iomem *dist_base;
@@ -952,8 +979,10 @@ static int __init gic_of_init(struct device_node *node, 
struct device_node *pare

err = gic_init_bases(dist_base, rdist_regs, nr_redist_regions,
 redist_stride, >fwnode);
-   if (!err)
+   if (!err) {
+   gic_of_setup_kvm_info(node);
return 0;
+   }

  out_unmap_rdist:
for (i = 0; i < nr_redist_regions; i++)
@@ -974,6 +1003,9 @@ static struct
struct redist_region *redist_regs;
u32 nr_redist_regions;
bool single_redist;
+   u32 maint_irq;
+   int maint_irq_mode;
+   phys_addr_t vcpu_base;
  } acpi_data __initdata;

  static void __init
@@ -1110,7 +1142,81 @@ static bool __init acpi_validate_gic_table(struct 
acpi_subtable_header *header,
return true;
  }

+static int __init gic_acpi_parse_virt_madt_gicc(struct acpi_subtable_header 
*header,
+   const unsigned long end)
+{
+   struct acpi_madt_generic_interrupt *gicc =
+   (struct acpi_madt_generic_interrupt *)header;
+   int maint_irq_mode;
+   static int first_madt = true;
+
+   maint_irq_mode = (gicc->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
+   ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
+
+   if (first_madt) {
+   first_madt = false;
+
+   acpi_data.maint_irq = gicc->vgic_interrupt;
+   acpi_data.maint_irq_mode = maint_irq_mode;
+   acpi_data.vcpu_base = gicc->gicv_base_address;
+
+   return 0;
+   }
+
+   /*
+* The maintenance interrupt and GICV should be the same for every CPU
+*/
+   if ((acpi_data.maint_irq != gicc->vgic_interrupt) ||
+   (acpi_data.maint_irq_mode != maint_irq_mode) ||
+   (acpi_data.vcpu_base != gicc->gicv_base_address))
+   return -EINVAL;
+
+   return 0;
+}
+
+static bool __init gic_acpi_collect_virt_info(void)
+{
+   int count;
+
+   count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+ gic_acpi_parse_virt_madt_gicc, 0);
+
+   return (count > 0);
+}
+
  

Re: [PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

[kbuild test robot]

Hi Andi,

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

url:
https://github.com/0day-ci/linux/commits/Andi-Kleen/audit-Don-t-spam-logs-with-SECCOMP_KILL-RET_ERRNO-by-default/20160411-122005
base:   git://git.infradead.org/users/pcmoore/audit next
config: i386-randconfig-r0-201615 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> kernel/built-in.o:(.data+0xf3c): undefined reference to `audit_log_seccomp'

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


.config.gz
Description: Binary data

Re: [PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

[kbuild test robot]

Hi Andi,

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

url:
https://github.com/0day-ci/linux/commits/Andi-Kleen/audit-Don-t-spam-logs-with-SECCOMP_KILL-RET_ERRNO-by-default/20160411-122005
base:   git://git.infradead.org/users/pcmoore/audit next
config: i386-randconfig-r0-201615 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> kernel/built-in.o:(.data+0xf3c): undefined reference to `audit_log_seccomp'

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


.config.gz
Description: Binary data

Re: [PATCH 02/10] mm/hugetlb: Add PGD based implementation awareness

[Anshuman Khandual]

On 04/07/2016 02:34 PM, Balbir Singh wrote:
> 
> 
> On 07/04/16 15:37, Anshuman Khandual wrote:
>> Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like
>> 'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB
>> page implementation at the PGD level. This is also true for functions
>> like 'follow_page_mask' which is called from move_pages() system call.
>> This lack of PGD level huge page support prohibits some architectures
>> to use these generic HugeTLB functions.
>>
> 
> From what I know of move_pages(), it will always call follow_page_mask()
> with FOLL_GET (I could be wrong here) and the implementation below
> returns NULL for follow_huge_pgd().

You are right. This patch makes ARCH_WANT_GENERAL_HUGETLB functions aware
of PGD implementation so that we can do all transactions on 16GB pages
using these function instead of the present arch overrides. But that also
requires follow_page_mask() changes for every other access to the page
than the migrate_pages() usage.

But yes, we dont support migrate_pages() on PGD based pages yet, hence
it just returns NULL in that case. May be the commit message needs to
reflect this.

> 
>> This change adds the required PGD based implementation awareness and
>> with that, more architectures like POWER which implements 16GB pages
>> at the PGD level along with the 16MB pages at the PMD level can now
>> use ARCH_WANT_GENERAL_HUGETLB config option.
>>
>> Signed-off-by: Anshuman Khandual 
>> ---
>>  include/linux/hugetlb.h |  3 +++
>>  mm/gup.c|  6 ++
>>  mm/hugetlb.c| 20 
>>  3 files changed, 29 insertions(+)
>>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 7d953c2..71832e1 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -115,6 +115,8 @@ struct page *follow_huge_pmd(struct mm_struct *mm, 
>> unsigned long address,
>>  pmd_t *pmd, int flags);
>>  struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
>>  pud_t *pud, int flags);
>> +struct page *follow_huge_pgd(struct mm_struct *mm, unsigned long address,
>> +pgd_t *pgd, int flags);
>>  int pmd_huge(pmd_t pmd);
>>  int pud_huge(pud_t pmd);
>>  unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
>> @@ -143,6 +145,7 @@ static inline void hugetlb_show_meminfo(void)
>>  }
>>  #define follow_huge_pmd(mm, addr, pmd, flags)   NULL
>>  #define follow_huge_pud(mm, addr, pud, flags)   NULL
>> +#define follow_huge_pgd(mm, addr, pgd, flags)   NULL
>>  #define prepare_hugepage_range(file, addr, len) (-EINVAL)
>>  #define pmd_huge(x) 0
>>  #define pud_huge(x) 0
>> diff --git a/mm/gup.c b/mm/gup.c
>> index fb87aea..9bac78c 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -234,6 +234,12 @@ struct page *follow_page_mask(struct vm_area_struct 
>> *vma,
>>  pgd = pgd_offset(mm, address);
>>  if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
>>  return no_page_table(vma, flags);
>> +if (pgd_huge(*pgd) && vma->vm_flags & VM_HUGETLB) {
>> +page = follow_huge_pgd(mm, address, pgd, flags);
>> +if (page)
>> +return page;
>> +return no_page_table(vma, flags);
> This will return NULL as well?

That right, no_page_table() returns NULL for FOLL_GET when we fall through
after failing on follow_huge_pgd().

>> +}
>>  
>>  pud = pud_offset(pgd, address);
>>  if (pud_none(*pud))
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 19d0d08..5ea3158 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -4250,6 +4250,11 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
>>  pte_t *pte = NULL;
>>  
>>  pgd = pgd_offset(mm, addr);
>> +if (sz == PGDIR_SIZE) {
>> +pte = (pte_t *)pgd;
>> +goto huge_pgd;
>> +}
>> +
> 
> No allocation for a pgd slot - right?

No, its already allocated for the mm during creation.

Re: [PATCH 02/10] mm/hugetlb: Add PGD based implementation awareness

[Anshuman Khandual]

On 04/07/2016 02:34 PM, Balbir Singh wrote:
> 
> 
> On 07/04/16 15:37, Anshuman Khandual wrote:
>> Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like
>> 'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB
>> page implementation at the PGD level. This is also true for functions
>> like 'follow_page_mask' which is called from move_pages() system call.
>> This lack of PGD level huge page support prohibits some architectures
>> to use these generic HugeTLB functions.
>>
> 
> From what I know of move_pages(), it will always call follow_page_mask()
> with FOLL_GET (I could be wrong here) and the implementation below
> returns NULL for follow_huge_pgd().

You are right. This patch makes ARCH_WANT_GENERAL_HUGETLB functions aware
of PGD implementation so that we can do all transactions on 16GB pages
using these function instead of the present arch overrides. But that also
requires follow_page_mask() changes for every other access to the page
than the migrate_pages() usage.

But yes, we dont support migrate_pages() on PGD based pages yet, hence
it just returns NULL in that case. May be the commit message needs to
reflect this.

> 
>> This change adds the required PGD based implementation awareness and
>> with that, more architectures like POWER which implements 16GB pages
>> at the PGD level along with the 16MB pages at the PMD level can now
>> use ARCH_WANT_GENERAL_HUGETLB config option.
>>
>> Signed-off-by: Anshuman Khandual 
>> ---
>>  include/linux/hugetlb.h |  3 +++
>>  mm/gup.c|  6 ++
>>  mm/hugetlb.c| 20 
>>  3 files changed, 29 insertions(+)
>>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 7d953c2..71832e1 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -115,6 +115,8 @@ struct page *follow_huge_pmd(struct mm_struct *mm, 
>> unsigned long address,
>>  pmd_t *pmd, int flags);
>>  struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
>>  pud_t *pud, int flags);
>> +struct page *follow_huge_pgd(struct mm_struct *mm, unsigned long address,
>> +pgd_t *pgd, int flags);
>>  int pmd_huge(pmd_t pmd);
>>  int pud_huge(pud_t pmd);
>>  unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
>> @@ -143,6 +145,7 @@ static inline void hugetlb_show_meminfo(void)
>>  }
>>  #define follow_huge_pmd(mm, addr, pmd, flags)   NULL
>>  #define follow_huge_pud(mm, addr, pud, flags)   NULL
>> +#define follow_huge_pgd(mm, addr, pgd, flags)   NULL
>>  #define prepare_hugepage_range(file, addr, len) (-EINVAL)
>>  #define pmd_huge(x) 0
>>  #define pud_huge(x) 0
>> diff --git a/mm/gup.c b/mm/gup.c
>> index fb87aea..9bac78c 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -234,6 +234,12 @@ struct page *follow_page_mask(struct vm_area_struct 
>> *vma,
>>  pgd = pgd_offset(mm, address);
>>  if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
>>  return no_page_table(vma, flags);
>> +if (pgd_huge(*pgd) && vma->vm_flags & VM_HUGETLB) {
>> +page = follow_huge_pgd(mm, address, pgd, flags);
>> +if (page)
>> +return page;
>> +return no_page_table(vma, flags);
> This will return NULL as well?

That right, no_page_table() returns NULL for FOLL_GET when we fall through
after failing on follow_huge_pgd().

>> +}
>>  
>>  pud = pud_offset(pgd, address);
>>  if (pud_none(*pud))
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 19d0d08..5ea3158 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -4250,6 +4250,11 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
>>  pte_t *pte = NULL;
>>  
>>  pgd = pgd_offset(mm, addr);
>> +if (sz == PGDIR_SIZE) {
>> +pte = (pte_t *)pgd;
>> +goto huge_pgd;
>> +}
>> +
> 
> No allocation for a pgd slot - right?

No, its already allocated for the mm during creation.

Re: [PATCH] drivers/usb/gadget/udc/r8a66597-udc.c: Deinline pipe_change, save 2176 bytes

[Felipe Balbi]

Hi,

Denys Vlasenko  writes:
> This function compiles to 298 bytes of machine code, has ~10 callsites.

fair enough

> This is a USB 2.0 device, USB 2.0 is limited to 35 MB/s, so should be

it's not limited to 35MB/sec, sorry. USB 2.0 has a theoretical maximum
of 60MB/sec. But 44MB/sec is what people consider 'possible'. I've
gotten to 41MB/sec with g_mas_storage gadget.

> almost never CPU bound.
>
> No need to optimize for speed this agressively.
>
> Signed-off-by: Denys Vlasenko 
> CC: Felipe Balbi 
> CC: linux-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
>  drivers/usb/gadget/udc/r8a66597-udc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/r8a66597-udc.c 
> b/drivers/usb/gadget/udc/r8a66597-udc.c
> index baa0609..1d79a47 100644
> --- a/drivers/usb/gadget/udc/r8a66597-udc.c
> +++ b/drivers/usb/gadget/udc/r8a66597-udc.c
> @@ -296,7 +296,7 @@ static void r8a66597_change_curpipe(struct r8a66597 
> *r8a66597, u16 pipenum,
>   } while ((tmp & mask) != loop);
>  }
>  
> -static inline void pipe_change(struct r8a66597 *r8a66597, u16 pipenum)
> +static void pipe_change(struct r8a66597 *r8a66597, u16 pipenum)
>  {
>   struct r8a66597_ep *ep = r8a66597->pipenum2ep[pipenum];
>  
> -- 
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] drivers/usb/gadget/udc/r8a66597-udc.c: Deinline pipe_change, save 2176 bytes

[Felipe Balbi]

Hi,

Denys Vlasenko  writes:
> This function compiles to 298 bytes of machine code, has ~10 callsites.

fair enough

> This is a USB 2.0 device, USB 2.0 is limited to 35 MB/s, so should be

it's not limited to 35MB/sec, sorry. USB 2.0 has a theoretical maximum
of 60MB/sec. But 44MB/sec is what people consider 'possible'. I've
gotten to 41MB/sec with g_mas_storage gadget.

> almost never CPU bound.
>
> No need to optimize for speed this agressively.
>
> Signed-off-by: Denys Vlasenko 
> CC: Felipe Balbi 
> CC: linux-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> ---
>  drivers/usb/gadget/udc/r8a66597-udc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/r8a66597-udc.c 
> b/drivers/usb/gadget/udc/r8a66597-udc.c
> index baa0609..1d79a47 100644
> --- a/drivers/usb/gadget/udc/r8a66597-udc.c
> +++ b/drivers/usb/gadget/udc/r8a66597-udc.c
> @@ -296,7 +296,7 @@ static void r8a66597_change_curpipe(struct r8a66597 
> *r8a66597, u16 pipenum,
>   } while ((tmp & mask) != loop);
>  }
>  
> -static inline void pipe_change(struct r8a66597 *r8a66597, u16 pipenum)
> +static void pipe_change(struct r8a66597 *r8a66597, u16 pipenum)
>  {
>   struct r8a66597_ep *ep = r8a66597->pipenum2ep[pipenum];
>  
> -- 
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v5 5/9] irqchip/gic-v3: Gather all ACPI specific data in a single structure

[Hanjun Guo]

+cc Tomasz,

On 2016/4/4 19:37, Julien Grall wrote:

The ACPI code requires to use global variales in order to collect
information from the tables.

To make clear those variables are ACPI specific, gather all of them in a
single structure.

Furthermore, even if some of the variables are not marked with
__initdata, they are all only used during the initialization. Therefore,
the new variable, which hold the structure, can be marked with
__initdata.

Signed-off-by: Julien Grall 

---
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 

 Changes in v4:
 - Rework commit message

 Changes in v3:
 - Patch added
---
  drivers/irqchip/irq-gic-v3.c | 60 
  1 file changed, 33 insertions(+), 27 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 5b7d3c2..50e87e6 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -968,19 +968,22 @@ out_unmap_dist:
  IRQCHIP_DECLARE(gic_v3, "arm,gic-v3", gic_of_init);

  #ifdef CONFIG_ACPI
-static void __iomem *dist_base;
-static struct redist_region *redist_regs __initdata;
-static u32 nr_redist_regions __initdata;
-static bool single_redist;
+static struct
+{
+   void __iomem *dist_base;
+   struct redist_region *redist_regs;
+   u32 nr_redist_regions;
+   bool single_redist;
+} acpi_data __initdata;

  static void __init
  gic_acpi_register_redist(phys_addr_t phys_base, void __iomem *redist_base)
  {
static int count = 0;

-   redist_regs[count].phys_base = phys_base;
-   redist_regs[count].redist_base = redist_base;
-   redist_regs[count].single_redist = single_redist;
+   acpi_data.redist_regs[count].phys_base = phys_base;
+   acpi_data.redist_regs[count].redist_base = redist_base;
+   acpi_data.redist_regs[count].single_redist = acpi_data.single_redist;
count++;
  }

@@ -1008,7 +1011,7 @@ gic_acpi_parse_madt_gicc(struct acpi_subtable_header 
*header,
  {
struct acpi_madt_generic_interrupt *gicc =
(struct acpi_madt_generic_interrupt *)header;
-   u32 reg = readl_relaxed(dist_base + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
+   u32 reg = readl_relaxed(acpi_data.dist_base + GICD_PIDR2) & 
GIC_PIDR2_ARCH_MASK;
u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
void __iomem *redist_base;

@@ -1025,7 +1028,7 @@ static int __init gic_acpi_collect_gicr_base(void)
acpi_tbl_entry_handler redist_parser;
enum acpi_madt_type type;

-   if (single_redist) {
+   if (acpi_data.single_redist) {
type = ACPI_MADT_TYPE_GENERIC_INTERRUPT;
redist_parser = gic_acpi_parse_madt_gicc;
} else {
@@ -1076,14 +1079,14 @@ static int __init gic_acpi_count_gicr_regions(void)
count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR,
  gic_acpi_match_gicr, 0);
if (count > 0) {
-   single_redist = false;
+   acpi_data.single_redist = false;
return count;
}

count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
  gic_acpi_match_gicc, 0);
if (count > 0)
-   single_redist = true;
+   acpi_data.single_redist = true;

return count;
  }
@@ -1103,7 +1106,7 @@ static bool __init acpi_validate_gic_table(struct 
acpi_subtable_header *header,
if (count <= 0)
return false;

-   nr_redist_regions = count;
+   acpi_data.nr_redist_regions = count;
return true;
  }

@@ -1114,25 +1117,28 @@ gic_acpi_init(struct acpi_subtable_header *header, 
const unsigned long end)
  {
struct acpi_madt_generic_distributor *dist;
struct fwnode_handle *domain_handle;
+   size_t size;
int i, err;

/* Get distributor base address */
dist = (struct acpi_madt_generic_distributor *)header;
-   dist_base = ioremap(dist->base_address, ACPI_GICV3_DIST_MEM_SIZE);
-   if (!dist_base) {
+   acpi_data.dist_base = ioremap(dist->base_address,
+ ACPI_GICV3_DIST_MEM_SIZE);
+   if (!acpi_data.dist_base) {
pr_err("Unable to map GICD registers\n");
return -ENOMEM;
}

-   err = gic_validate_dist_version(dist_base);
+   err = gic_validate_dist_version(acpi_data.dist_base);
if (err) {
-   pr_err("No distributor detected at @%p, giving up", dist_base);
+   pr_err("No distributor detected at @%p, giving up",
+  acpi_data.dist_base);
goto out_dist_unmap;
}

-   redist_regs = kzalloc(sizeof(*redist_regs) * nr_redist_regions,
- GFP_KERNEL);
-   if (!redist_regs) {
+  

Re: [PATCH v5 5/9] irqchip/gic-v3: Gather all ACPI specific data in a single structure

[Hanjun Guo]

+cc Tomasz,

On 2016/4/4 19:37, Julien Grall wrote:

The ACPI code requires to use global variales in order to collect
information from the tables.

To make clear those variables are ACPI specific, gather all of them in a
single structure.

Furthermore, even if some of the variables are not marked with
__initdata, they are all only used during the initialization. Therefore,
the new variable, which hold the structure, can be marked with
__initdata.

Signed-off-by: Julien Grall 

---
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 

 Changes in v4:
 - Rework commit message

 Changes in v3:
 - Patch added
---
  drivers/irqchip/irq-gic-v3.c | 60 
  1 file changed, 33 insertions(+), 27 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 5b7d3c2..50e87e6 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -968,19 +968,22 @@ out_unmap_dist:
  IRQCHIP_DECLARE(gic_v3, "arm,gic-v3", gic_of_init);

  #ifdef CONFIG_ACPI
-static void __iomem *dist_base;
-static struct redist_region *redist_regs __initdata;
-static u32 nr_redist_regions __initdata;
-static bool single_redist;
+static struct
+{
+   void __iomem *dist_base;
+   struct redist_region *redist_regs;
+   u32 nr_redist_regions;
+   bool single_redist;
+} acpi_data __initdata;

  static void __init
  gic_acpi_register_redist(phys_addr_t phys_base, void __iomem *redist_base)
  {
static int count = 0;

-   redist_regs[count].phys_base = phys_base;
-   redist_regs[count].redist_base = redist_base;
-   redist_regs[count].single_redist = single_redist;
+   acpi_data.redist_regs[count].phys_base = phys_base;
+   acpi_data.redist_regs[count].redist_base = redist_base;
+   acpi_data.redist_regs[count].single_redist = acpi_data.single_redist;
count++;
  }

@@ -1008,7 +1011,7 @@ gic_acpi_parse_madt_gicc(struct acpi_subtable_header 
*header,
  {
struct acpi_madt_generic_interrupt *gicc =
(struct acpi_madt_generic_interrupt *)header;
-   u32 reg = readl_relaxed(dist_base + GICD_PIDR2) & GIC_PIDR2_ARCH_MASK;
+   u32 reg = readl_relaxed(acpi_data.dist_base + GICD_PIDR2) & 
GIC_PIDR2_ARCH_MASK;
u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
void __iomem *redist_base;

@@ -1025,7 +1028,7 @@ static int __init gic_acpi_collect_gicr_base(void)
acpi_tbl_entry_handler redist_parser;
enum acpi_madt_type type;

-   if (single_redist) {
+   if (acpi_data.single_redist) {
type = ACPI_MADT_TYPE_GENERIC_INTERRUPT;
redist_parser = gic_acpi_parse_madt_gicc;
} else {
@@ -1076,14 +1079,14 @@ static int __init gic_acpi_count_gicr_regions(void)
count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR,
  gic_acpi_match_gicr, 0);
if (count > 0) {
-   single_redist = false;
+   acpi_data.single_redist = false;
return count;
}

count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
  gic_acpi_match_gicc, 0);
if (count > 0)
-   single_redist = true;
+   acpi_data.single_redist = true;

return count;
  }
@@ -1103,7 +1106,7 @@ static bool __init acpi_validate_gic_table(struct 
acpi_subtable_header *header,
if (count <= 0)
return false;

-   nr_redist_regions = count;
+   acpi_data.nr_redist_regions = count;
return true;
  }

@@ -1114,25 +1117,28 @@ gic_acpi_init(struct acpi_subtable_header *header, 
const unsigned long end)
  {
struct acpi_madt_generic_distributor *dist;
struct fwnode_handle *domain_handle;
+   size_t size;
int i, err;

/* Get distributor base address */
dist = (struct acpi_madt_generic_distributor *)header;
-   dist_base = ioremap(dist->base_address, ACPI_GICV3_DIST_MEM_SIZE);
-   if (!dist_base) {
+   acpi_data.dist_base = ioremap(dist->base_address,
+ ACPI_GICV3_DIST_MEM_SIZE);
+   if (!acpi_data.dist_base) {
pr_err("Unable to map GICD registers\n");
return -ENOMEM;
}

-   err = gic_validate_dist_version(dist_base);
+   err = gic_validate_dist_version(acpi_data.dist_base);
if (err) {
-   pr_err("No distributor detected at @%p, giving up", dist_base);
+   pr_err("No distributor detected at @%p, giving up",
+  acpi_data.dist_base);
goto out_dist_unmap;
}

-   redist_regs = kzalloc(sizeof(*redist_regs) * nr_redist_regions,
- GFP_KERNEL);
-   if (!redist_regs) {
+   size = sizeof(*acpi_data.redist_regs) * acpi_data.nr_redist_regions;
+   

Re: [PATCH v3 4/5] scsi: rename SCSI_MAX_{SG, SG_CHAIN}_SEGMENTS

[Ming Lin]

On Tue, Apr 5, 2016 at 7:55 AM, Tejun Heo  wrote:
> On Mon, Apr 04, 2016 at 02:48:10PM -0700, Ming Lin wrote:
>> From: Ming Lin 
>>
>> Rename SCSI_MAX_SG_SEGMENTS to SG_CHUNK_SIZE, which means the amount
>> we fit into a single scatterlist chunk.
>>
>> Rename SCSI_MAX_SG_CHAIN_SEGMENTS to SG_MAX_SEGMENTS.
>>
>> Will move these 2 generic definitions to scatterlist.h later.
>>
>> Reviewed-by: Christoph Hellwig 
>> Acked-by: Bart Van Assche  (for ib_srp changes)
>> Signed-off-by: Ming Lin 
>
> For libata,
>
> Acked-by: Tejun Heo 

Hi James,

Are we ready to merge it?

Thanks,
Ming

Re: [PATCH v3 4/5] scsi: rename SCSI_MAX_{SG, SG_CHAIN}_SEGMENTS

[Ming Lin]

On Tue, Apr 5, 2016 at 7:55 AM, Tejun Heo  wrote:
> On Mon, Apr 04, 2016 at 02:48:10PM -0700, Ming Lin wrote:
>> From: Ming Lin 
>>
>> Rename SCSI_MAX_SG_SEGMENTS to SG_CHUNK_SIZE, which means the amount
>> we fit into a single scatterlist chunk.
>>
>> Rename SCSI_MAX_SG_CHAIN_SEGMENTS to SG_MAX_SEGMENTS.
>>
>> Will move these 2 generic definitions to scatterlist.h later.
>>
>> Reviewed-by: Christoph Hellwig 
>> Acked-by: Bart Van Assche  (for ib_srp changes)
>> Signed-off-by: Ming Lin 
>
> For libata,
>
> Acked-by: Tejun Heo 

Hi James,

Are we ready to merge it?

Thanks,
Ming

Re: HVMLite / PVHv2 - using x86 EFI boot entry

[Juergen Gross]

On 08/04/16 22:40, Luis R. Rodriguez wrote:
> On Wed, Apr 06, 2016 at 10:40:08AM +0100, David Vrabel wrote:
>> On 06/04/16 03:40, Luis R. Rodriguez wrote:
>>>
>>> * You don't need full EFI emulation
>>
>> I think needing any EFI emulation inside Xen (which is where it would
>> need to be for dom0) is not suitable because of the increase in
>> hypervisor ABI.
> 
> Is this because of timing on architecture / design of HVMLite, or
> a general position that the complexity to deal with EFI emulation
> is too much for Xen's taste ?

The Xen hypervisor should be as small as possible. Adding an EFI
emulator will be adding quite some code. This should be done after a
very thorough evaluation only.

> ARM already went the EFI entry way for domU -- it went the OVMF route,
> would such a possibility be possible for x86 domU HVMLite ? If not why
> not, I mean it would seem to make sense to at least mimic the same type
> of early boot environment, and perhaps there are some lessons to be
> learned from that effort too.

The final solution must be appropriate for dom0, too. So don't try
to limit the discussion to domU. If dom0 isn't going to be acceptable
there will no need to discuss domU.

> Are there some lessons to be learned with ARM's effort? What are they?
> If that could be re-done again with any type of cleaner path, what
> could that be that could help the x86 side ?
> 
> Although emulating EFI may require work, some folks have pointed out
> that the amount of work may not be that much. If that is done can
> we instead rely on the same code to replace OVMF to support both
> Xen ARM and Xen HVMLite on x86 ? What would be the pros / cons of
> this ?
> 
>> I also still do not understand your objection to the current tiny stub.
> 
> Its more of a hypothetical -- can an EFI entry be used instead given
> it already does exactly what the new small entry does ? Its also rather
> odd to add a new entry without evaluating fully a possible alternative
> that would provide the same exact mechanism.

The interface isn't the new entry only. It should be evaluated how much
of the early EFI boot path would be common to the HVMlite one. What
would be gained by using the same entry but having two different boot
paths after it? You still need a way to distinguish between bare metal
EFI and HVMlite. And Xen needs a way to find out whether a kernel is
supporting HVMlite to boot it in the correct mode.

> A full technical unbiased evaluation of the different approaches is what I'd
> hope we could strive to achieve through discussion and peer review, thinking
> and prioritizing ultimately what is best to minimize the impact on Linux
> and also help take advantage of the best features possible through both
> means. Thinking long term, not immediate short term.

Sure.


Juergen

Re: HVMLite / PVHv2 - using x86 EFI boot entry

[Juergen Gross]

On 08/04/16 22:40, Luis R. Rodriguez wrote:
> On Wed, Apr 06, 2016 at 10:40:08AM +0100, David Vrabel wrote:
>> On 06/04/16 03:40, Luis R. Rodriguez wrote:
>>>
>>> * You don't need full EFI emulation
>>
>> I think needing any EFI emulation inside Xen (which is where it would
>> need to be for dom0) is not suitable because of the increase in
>> hypervisor ABI.
> 
> Is this because of timing on architecture / design of HVMLite, or
> a general position that the complexity to deal with EFI emulation
> is too much for Xen's taste ?

The Xen hypervisor should be as small as possible. Adding an EFI
emulator will be adding quite some code. This should be done after a
very thorough evaluation only.

> ARM already went the EFI entry way for domU -- it went the OVMF route,
> would such a possibility be possible for x86 domU HVMLite ? If not why
> not, I mean it would seem to make sense to at least mimic the same type
> of early boot environment, and perhaps there are some lessons to be
> learned from that effort too.

The final solution must be appropriate for dom0, too. So don't try
to limit the discussion to domU. If dom0 isn't going to be acceptable
there will no need to discuss domU.

> Are there some lessons to be learned with ARM's effort? What are they?
> If that could be re-done again with any type of cleaner path, what
> could that be that could help the x86 side ?
> 
> Although emulating EFI may require work, some folks have pointed out
> that the amount of work may not be that much. If that is done can
> we instead rely on the same code to replace OVMF to support both
> Xen ARM and Xen HVMLite on x86 ? What would be the pros / cons of
> this ?
> 
>> I also still do not understand your objection to the current tiny stub.
> 
> Its more of a hypothetical -- can an EFI entry be used instead given
> it already does exactly what the new small entry does ? Its also rather
> odd to add a new entry without evaluating fully a possible alternative
> that would provide the same exact mechanism.

The interface isn't the new entry only. It should be evaluated how much
of the early EFI boot path would be common to the HVMlite one. What
would be gained by using the same entry but having two different boot
paths after it? You still need a way to distinguish between bare metal
EFI and HVMlite. And Xen needs a way to find out whether a kernel is
supporting HVMlite to boot it in the correct mode.

> A full technical unbiased evaluation of the different approaches is what I'd
> hope we could strive to achieve through discussion and peer review, thinking
> and prioritizing ultimately what is best to minimize the impact on Linux
> and also help take advantage of the best features possible through both
> means. Thinking long term, not immediate short term.

Sure.


Juergen

Re: [PATCH] usb: core: buffer: avoid NULL pointer dereferrence

[Felipe Balbi]

Hi,

chunfeng yun  writes:
> On Fri, 2016-04-08 at 07:07 -0700, Greg Kroah-Hartman wrote:
>> On Fri, Apr 08, 2016 at 05:08:03PM +0800, Chunfeng Yun wrote:
>> > NULL pointer dereferrence will happen when class driver
>> > wants to allocate zero length buffer and pool_max[0]
>> > can't be used, so skip reserved pool in this case.
>> 
>> Why would a driver want to allocate a 0 length buffer?  What driver does
>> this?
> It's misc/usbtest.c

that'll do what you ask it to do with the userspace tool testusb. Are
you trying to pass a size of 0 ?

>> Shouldn't we fix that issue instead?
> I don't know which way is better, but it seems simple to fix it up in
> buffer.c 

I think we should, really, avoid a 0-length allocation, but passing a
size of 0 to testusb isn't very good either ;-) How are you calling
testusb ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: core: buffer: avoid NULL pointer dereferrence

[Felipe Balbi]

Hi,

chunfeng yun  writes:
> On Fri, 2016-04-08 at 07:07 -0700, Greg Kroah-Hartman wrote:
>> On Fri, Apr 08, 2016 at 05:08:03PM +0800, Chunfeng Yun wrote:
>> > NULL pointer dereferrence will happen when class driver
>> > wants to allocate zero length buffer and pool_max[0]
>> > can't be used, so skip reserved pool in this case.
>> 
>> Why would a driver want to allocate a 0 length buffer?  What driver does
>> this?
> It's misc/usbtest.c

that'll do what you ask it to do with the userspace tool testusb. Are
you trying to pass a size of 0 ?

>> Shouldn't we fix that issue instead?
> I don't know which way is better, but it seems simple to fix it up in
> buffer.c 

I think we should, really, avoid a 0-length allocation, but passing a
size of 0 to testusb isn't very good either ;-) How are you calling
testusb ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] checkpatch: Improve missing break for switch/case tests

[Joe Perches]

On Sun, 2016-04-10 at 19:26 -0700, Joe Perches wrote:
> The current switch/case test doesn't handle ... case labels like:
> 
>   switch (foo) {
>   case bar ... baz:
>   etc...
>   }
> 
> Add a specific regex for that form and the default label.
> Use the regex where a case label is tested.

Please ignore, the patch is defective as
it has too many false positives.

Re: [PATCH] checkpatch: Improve missing break for switch/case tests

[Joe Perches]

On Sun, 2016-04-10 at 19:26 -0700, Joe Perches wrote:
> The current switch/case test doesn't handle ... case labels like:
> 
>   switch (foo) {
>   case bar ... baz:
>   etc...
>   }
> 
> Add a specific regex for that form and the default label.
> Use the regex where a case label is tested.

Please ignore, the patch is defective as
it has too many false positives.

[PATCH] clk: sunxi: Use resource_size

[Vaishali Thakkar]

Use the function resource_size instaed of explicit computation.

Problem found using Coccinelle.

Signed-off-by: Vaishali Thakkar 
---
 drivers/clk/sunxi/clk-sun9i-mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi/clk-sun9i-mmc.c 
b/drivers/clk/sunxi/clk-sun9i-mmc.c
index 028dd83..7167373 100644
--- a/drivers/clk/sunxi/clk-sun9i-mmc.c
+++ b/drivers/clk/sunxi/clk-sun9i-mmc.c
@@ -106,7 +106,7 @@ static int sun9i_a80_mmc_config_clk_probe(struct 
platform_device *pdev)
 
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
/* one clock/reset pair per word */
-   count = DIV_ROUND_UP((r->end - r->start + 1), SUN9I_MMC_WIDTH);
+   count = DIV_ROUND_UP((resource_size(r)), SUN9I_MMC_WIDTH);
data->membase = devm_ioremap_resource(>dev, r);
if (IS_ERR(data->membase))
return PTR_ERR(data->membase);
-- 
2.1.4

Re: sched: tweak select_idle_sibling to look for idle threads

[Mike Galbraith]

On Sun, 2016-04-10 at 15:55 -0400, Chris Mason wrote:
> On Sun, Apr 10, 2016 at 12:04:21PM +0200, Mike Galbraith wrote:
> > On Sat, 2016-04-09 at 15:05 -0400, Chris Mason wrote:
> > 
> > > This does preserve the existing logic to prefer idle cores over idle
> > > CPU threads, and includes some tests to try and avoid the idle scan when 
> > > we're
> > > actually better off sharing a non-idle CPU with someone else.
> > 
> > My box says the "oh nevermind" checks aren't selective enough, tbench
> > dropped 4% at clients=cores, and 2% at clients=threads.
> 
> Ok, I was able to reproduce this by stuffing tbench_srv and tbench onto
> just socket 0.  Version 2 below fixes things for me, but I'm hoping
> someone can suggest a way to get task_hot() buddy checks without the rq
> lock.
> 
> I haven't run this on production loads yet, but our 4.0 patch for this
> uses task_hot(), so I'd expect it to be on par.  If this doesn't fix it
> for you, I'll dig up a similar machine on Monday.

My box stopped caring.  I personally would be reluctant to apply it
without a "you asked for it" button or a large pile of benchmark
results.  Lock banging or not, full scan existing makes me nervous.

-Mike

[PATCH] clk: sunxi: Use resource_size

[Vaishali Thakkar]

Use the function resource_size instaed of explicit computation.

Problem found using Coccinelle.

Signed-off-by: Vaishali Thakkar 
---
 drivers/clk/sunxi/clk-sun9i-mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi/clk-sun9i-mmc.c 
b/drivers/clk/sunxi/clk-sun9i-mmc.c
index 028dd83..7167373 100644
--- a/drivers/clk/sunxi/clk-sun9i-mmc.c
+++ b/drivers/clk/sunxi/clk-sun9i-mmc.c
@@ -106,7 +106,7 @@ static int sun9i_a80_mmc_config_clk_probe(struct 
platform_device *pdev)
 
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
/* one clock/reset pair per word */
-   count = DIV_ROUND_UP((r->end - r->start + 1), SUN9I_MMC_WIDTH);
+   count = DIV_ROUND_UP((resource_size(r)), SUN9I_MMC_WIDTH);
data->membase = devm_ioremap_resource(>dev, r);
if (IS_ERR(data->membase))
return PTR_ERR(data->membase);
-- 
2.1.4

Re: sched: tweak select_idle_sibling to look for idle threads

[Mike Galbraith]

On Sun, 2016-04-10 at 15:55 -0400, Chris Mason wrote:
> On Sun, Apr 10, 2016 at 12:04:21PM +0200, Mike Galbraith wrote:
> > On Sat, 2016-04-09 at 15:05 -0400, Chris Mason wrote:
> > 
> > > This does preserve the existing logic to prefer idle cores over idle
> > > CPU threads, and includes some tests to try and avoid the idle scan when 
> > > we're
> > > actually better off sharing a non-idle CPU with someone else.
> > 
> > My box says the "oh nevermind" checks aren't selective enough, tbench
> > dropped 4% at clients=cores, and 2% at clients=threads.
> 
> Ok, I was able to reproduce this by stuffing tbench_srv and tbench onto
> just socket 0.  Version 2 below fixes things for me, but I'm hoping
> someone can suggest a way to get task_hot() buddy checks without the rq
> lock.
> 
> I haven't run this on production loads yet, but our 4.0 patch for this
> uses task_hot(), so I'd expect it to be on par.  If this doesn't fix it
> for you, I'll dig up a similar machine on Monday.

My box stopped caring.  I personally would be reluctant to apply it
without a "you asked for it" button or a large pile of benchmark
results.  Lock banging or not, full scan existing makes me nervous.

-Mike

Re: [PATCH] drivers/infiniband/hw/nes/nes_verbs.c: Deinline nes_free_qp_mem, save 1072 bytes

[Leon Romanovsky]

On Fri, Apr 08, 2016 at 08:58:42PM +0200, Denys Vlasenko wrote:
> This function compiles to 550 bytes of machine code.
> Three callsites, all in nes_create_qp.

I agree with you, the functions which calls below and after this
function are not optimized for speed and there is no need to inline
this function.

I have two requests from you.
1)
Can you please change title to be more convenient?
[PATCH] drivers/infiniband/hw/nes/nes_verbs.c: Deinline nes_free_qp_mem, save 
1072 bytes
--->
[PATCH] IB/nes: Deinline nes_free_qp_mem

2) Add bloat-o-meter output to the commit message.

And after that feel free to add my RB tag.

Reviewed-By: Leon Romanovsky 


signature.asc
Description: Digital signature

Re: [PATCH] drivers/infiniband/hw/nes/nes_verbs.c: Deinline nes_free_qp_mem, save 1072 bytes

[Leon Romanovsky]

On Fri, Apr 08, 2016 at 08:58:42PM +0200, Denys Vlasenko wrote:
> This function compiles to 550 bytes of machine code.
> Three callsites, all in nes_create_qp.

I agree with you, the functions which calls below and after this
function are not optimized for speed and there is no need to inline
this function.

I have two requests from you.
1)
Can you please change title to be more convenient?
[PATCH] drivers/infiniband/hw/nes/nes_verbs.c: Deinline nes_free_qp_mem, save 
1072 bytes
--->
[PATCH] IB/nes: Deinline nes_free_qp_mem

2) Add bloat-o-meter output to the commit message.

And after that feel free to add my RB tag.

Reviewed-By: Leon Romanovsky 


signature.asc
Description: Digital signature

[PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

[Andi Kleen]

From: Andi Kleen 

When I run chrome on my opensuse system every time I open
a new tab the system log is spammed with:

audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857
comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e
syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5

This happens because chrome uses SECCOMP for its sandbox,
and for some reason always reaches a SECCOMP_KILL or more likely
SECCOMP_RET_ERRNO in the rule set.

The seccomp auditing was originally added by Eric with

commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31
Author: Eric Paris 
Date:   Tue Jan 3 14:23:05 2012 -0500

seccomp: audit abnormal end to a process due to seccomp

The audit system likes to collect information about processes that end
abnormally (SIGSEGV) as this may me useful intrusion detection 
information.
This patch adds audit support to collect information when seccomp
forces a task to exit because of misbehavior in a similar way.

I don't have any other syscall auditing enabled,
just the standard user space auditing used by the systemd
and PAM userland. So basic auditing is alwas enabled,
but no other kernel auditing.

Add a sysctl to enable this unconditional behavior with default
to off. This replaces an earlier patch that simply checked
whether syscall auditing was on, but Paul Moore preferred
this more elaborate approach.

v2: Use correct ifdef that checks for CONFIG_SECCOMP too.
Signed-off-by: Andi Kleen 
---
 Documentation/sysctl/kernel.txt |  9 +
 include/linux/audit.h   |  4 +++-
 kernel/seccomp.c|  4 
 kernel/sysctl.c | 11 +++
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 57653a4..abc6ef9 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -21,6 +21,7 @@ show up in /proc/sys/kernel:
 - acct
 - acpi_video_flags
 - auto_msgmni
+- audit_log_seccomp
 - bootloader_type   [ X86 only ]
 - bootloader_version[ X86 only ]
 - callhome  [ S390 only ]
@@ -129,6 +130,14 @@ upon memory add/remove or upon ipc namespace 
creation/removal.
 Echoing "1" into this file enabled msgmni automatic recomputing.
 Echoing "0" turned it off. auto_msgmni default value was 1.
 
+==
+
+audit_log_seccomp
+
+When this variable is set to 1 every SECCOMP_KILL/SECCOMP_RET_ERRNO
+results in an audit log. This is generally a bad idea because
+it leads to a audit message every time Chrome opens a new tab.
+Defaults to 0.
 
 ==
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index e38e3fc..c7787ba 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -315,9 +315,11 @@ static inline void audit_inode_child(struct inode *parent,
 }
 void audit_core_dumps(long signr);
 
+extern int audit_log_seccomp;
+
 static inline void audit_seccomp(unsigned long syscall, long signr, int code)
 {
-   if (!audit_enabled)
+   if (!audit_enabled || !audit_log_seccomp)
return;
 
/* Force a record to be reported if a signal was delivered. */
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index e1e5a35..09a8b03 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -25,6 +25,10 @@
 #include 
 #endif
 
+#ifdef CONFIG_AUDIT
+int audit_log_seccomp __read_mostly = 0;
+#endif
+
 #ifdef CONFIG_SECCOMP_FILTER
 #include 
 #include 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 725587f..997377d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -529,6 +530,16 @@ static struct ctl_table kern_table[] = {
.proc_handler   = proc_dointvec,
},
 #endif
+#if defined(CONFIG_AUDIT) && defined(CONFIG_SECCOMP)
+   {
+   .procname   = "audit-log-seccomp",
+   .data   = _log_seccomp,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+
+#endif
{
.procname   = "print-fatal-signals",
.data   = _fatal_signals,
-- 
2.7.4

[PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

[Andi Kleen]

From: Andi Kleen 

When I run chrome on my opensuse system every time I open
a new tab the system log is spammed with:

audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857
comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e
syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5

This happens because chrome uses SECCOMP for its sandbox,
and for some reason always reaches a SECCOMP_KILL or more likely
SECCOMP_RET_ERRNO in the rule set.

The seccomp auditing was originally added by Eric with

commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31
Author: Eric Paris 
Date:   Tue Jan 3 14:23:05 2012 -0500

seccomp: audit abnormal end to a process due to seccomp

The audit system likes to collect information about processes that end
abnormally (SIGSEGV) as this may me useful intrusion detection 
information.
This patch adds audit support to collect information when seccomp
forces a task to exit because of misbehavior in a similar way.

I don't have any other syscall auditing enabled,
just the standard user space auditing used by the systemd
and PAM userland. So basic auditing is alwas enabled,
but no other kernel auditing.

Add a sysctl to enable this unconditional behavior with default
to off. This replaces an earlier patch that simply checked
whether syscall auditing was on, but Paul Moore preferred
this more elaborate approach.

v2: Use correct ifdef that checks for CONFIG_SECCOMP too.
Signed-off-by: Andi Kleen 
---
 Documentation/sysctl/kernel.txt |  9 +
 include/linux/audit.h   |  4 +++-
 kernel/seccomp.c|  4 
 kernel/sysctl.c | 11 +++
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 57653a4..abc6ef9 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -21,6 +21,7 @@ show up in /proc/sys/kernel:
 - acct
 - acpi_video_flags
 - auto_msgmni
+- audit_log_seccomp
 - bootloader_type   [ X86 only ]
 - bootloader_version[ X86 only ]
 - callhome  [ S390 only ]
@@ -129,6 +130,14 @@ upon memory add/remove or upon ipc namespace 
creation/removal.
 Echoing "1" into this file enabled msgmni automatic recomputing.
 Echoing "0" turned it off. auto_msgmni default value was 1.
 
+==
+
+audit_log_seccomp
+
+When this variable is set to 1 every SECCOMP_KILL/SECCOMP_RET_ERRNO
+results in an audit log. This is generally a bad idea because
+it leads to a audit message every time Chrome opens a new tab.
+Defaults to 0.
 
 ==
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index e38e3fc..c7787ba 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -315,9 +315,11 @@ static inline void audit_inode_child(struct inode *parent,
 }
 void audit_core_dumps(long signr);
 
+extern int audit_log_seccomp;
+
 static inline void audit_seccomp(unsigned long syscall, long signr, int code)
 {
-   if (!audit_enabled)
+   if (!audit_enabled || !audit_log_seccomp)
return;
 
/* Force a record to be reported if a signal was delivered. */
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index e1e5a35..09a8b03 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -25,6 +25,10 @@
 #include 
 #endif
 
+#ifdef CONFIG_AUDIT
+int audit_log_seccomp __read_mostly = 0;
+#endif
+
 #ifdef CONFIG_SECCOMP_FILTER
 #include 
 #include 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 725587f..997377d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -529,6 +530,16 @@ static struct ctl_table kern_table[] = {
.proc_handler   = proc_dointvec,
},
 #endif
+#if defined(CONFIG_AUDIT) && defined(CONFIG_SECCOMP)
+   {
+   .procname   = "audit-log-seccomp",
+   .data   = _log_seccomp,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+
+#endif
{
.procname   = "print-fatal-signals",
.data   = _fatal_signals,
-- 
2.7.4

Re: [PATCH 0/2] perf probe fixes for ppc64le

[Michael Ellerman]

On Sat, 2016-04-09 at 19:12 +0530, Naveen N. Rao wrote:
> 
> I suppose this boils down to the quirkiness of ABIv2. Though, in 
> reality, I don't think most users will notice. As I stated above, users 
> will most likely start with the disassembly or debuginfo and this patch 
> ensures there are actually no surprises there.

Yeah it's unfortunate that we have to handle these two cases differently.

But I think you've chosen the right trade off.

When we are just given the name we *must not* use the global entry point,
otherwise the probes will often not hit - because most calls go to the local
entry point and skip the global entry point entirely.

When we're given a name and offset, it's less confusing if we use the global
entry point as the base for the offset calculation.

So for the concept:

Acked-by: Michael Ellerman 

I don't really know this part of the perf code enough to give you an ack for the
actual changes, I'll leave that to the perf maintainers.

cheers

Re: [PATCH 0/2] perf probe fixes for ppc64le

[Michael Ellerman]

On Sat, 2016-04-09 at 19:12 +0530, Naveen N. Rao wrote:
> 
> I suppose this boils down to the quirkiness of ABIv2. Though, in 
> reality, I don't think most users will notice. As I stated above, users 
> will most likely start with the disassembly or debuginfo and this patch 
> ensures there are actually no surprises there.

Yeah it's unfortunate that we have to handle these two cases differently.

But I think you've chosen the right trade off.

When we are just given the name we *must not* use the global entry point,
otherwise the probes will often not hit - because most calls go to the local
entry point and skip the global entry point entirely.

When we're given a name and offset, it's less confusing if we use the global
entry point as the base for the offset calculation.

So for the concept:

Acked-by: Michael Ellerman 

I don't really know this part of the perf code enough to give you an ack for the
actual changes, I'll leave that to the perf maintainers.

cheers

RE: [PATCH v6 2/2] btmrvl: add platform specific wakeup interrupt support

[Amitkumar Karwar]

Hi Marcel,

> From: Marcel Holtmann [mailto:mar...@holtmann.org]
> Sent: Friday, April 08, 2016 10:40 PM
> To: Amitkumar Karwar
> Cc: linux-blueto...@vger.kernel.org; Nishant Sarmukadam;
> wnhu...@chromium.com; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Xinming Hu
> Subject: Re: [PATCH v6 2/2] btmrvl: add platform specific wakeup
> interrupt support
> 
> Hi Amitkumar,
> 
> > On some arm-based platforms, we need to configure platform specific
> > parameters by device tree node and we need define our node as a child
> > node of parent SDIO host controller.
> > This patch parses these parameters from device tree. It includes
> > calibration data download to firmware, wakeup pin configured to
> > firmware, and soc specific wakeup interrupt pin.
> >
> > Signed-off-by: Xinming Hu 
> > Signed-off-by: Amitkumar Karwar 
> > ---
> > drivers/bluetooth/btmrvl_drv.h  | 11 ++
> > drivers/bluetooth/btmrvl_main.c | 33 +
> > drivers/bluetooth/btmrvl_sdio.c | 79
> > +
> > drivers/bluetooth/btmrvl_sdio.h |  6 
> > 4 files changed, 115 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btmrvl_drv.h
> > b/drivers/bluetooth/btmrvl_drv.h index 0590473..f742384 100644
> > --- a/drivers/bluetooth/btmrvl_drv.h
> > +++ b/drivers/bluetooth/btmrvl_drv.h
> > @@ -23,6 +23,17 @@
> > #include 
> > #include 
> > #include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> >
> > #define BTM_HEADER_LEN  4
> > #define BTM_UPLD_SIZE   2312
> > diff --git a/drivers/bluetooth/btmrvl_main.c
> > b/drivers/bluetooth/btmrvl_main.c index f25a825..25343ef 100644
> > --- a/drivers/bluetooth/btmrvl_main.c
> > +++ b/drivers/bluetooth/btmrvl_main.c
> > @@ -510,34 +510,39 @@ static int btmrvl_download_cal_data(struct
> > btmrvl_private *priv, static int btmrvl_check_device_tree(struct
> > btmrvl_private *priv) {
> > struct device_node *dt_node;
> > +   struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
> > u8 cal_data[BT_CAL_HDR_LEN + BT_CAL_DATA_SIZE];
> > -   int ret;
> > -   u32 val;
> > +   int ret = 0;
> > +   u16 gpio, gap;
> > +
> > +   if (card->plt_of_node) {
> > +   dt_node = card->plt_of_node;
> > +   ret = of_property_read_u16(dt_node, "btmrvl,wakeup-pin",
> > +  );
> > +   if (ret)
> > +   gpio = (priv->btmrvl_dev.gpio_gap & 0xff00) >> 8;
> > +
> > +   ret = of_property_read_u16(dt_node, "btmrvl,wakeup-gap",
> > +  );
> > +   if (ret)
> > +   gap = (u8)(priv->btmrvl_dev.gpio_gap & 0x00ff);
> >
> > -   for_each_compatible_node(dt_node, NULL, "btmrvl,cfgdata") {
> > -   ret = of_property_read_u32(dt_node, "btmrvl,gpio-gap",
> );
> > -   if (!ret)
> > -   priv->btmrvl_dev.gpio_gap = val;
> > +   priv->btmrvl_dev.gpio_gap = (gpio << 8) + gap;
> >
> > ret = of_property_read_u8_array(dt_node, "btmrvl,cal-data",
> > cal_data + BT_CAL_HDR_LEN,
> > BT_CAL_DATA_SIZE);
> > -   if (ret) {
> > -   of_node_put(dt_node);
> > +   if (ret)
> > return ret;
> > -   }
> >
> > BT_DBG("Use cal data from device tree");
> > ret = btmrvl_download_cal_data(priv, cal_data,
> >BT_CAL_DATA_SIZE);
> > -   if (ret) {
> > +   if (ret)
> > BT_ERR("Fail to download calibrate data");
> > -   of_node_put(dt_node);
> > -   return ret;
> > -   }
> > }
> >
> > -   return 0;
> > +   return ret;
> > }
> >
> > static int btmrvl_setup(struct hci_dev *hdev) diff --git
> > a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
> > index 6ed8acf..c714040 100644
> > --- a/drivers/bluetooth/btmrvl_sdio.c
> > +++ b/drivers/bluetooth/btmrvl_sdio.c
> > @@ -52,6 +52,68 @@ static struct memory_type_mapping
> mem_type_mapping_tbl[] = {
> > {"EXTLAST", NULL, 0, 0xFE},
> > };
> >
> > +static const struct of_device_id btmrvl_sdio_of_match_table[] = {
> > +   { .compatible = "marvell,sd8897-bt" },
> > +   { .compatible = "marvell,sd8997-bt" },
> > +   { }
> > +};
> 
> is this agreed upon by the DT maintainer? I only want to merge this
> patch if we have agreement.
> 

Please hold on for this patch. Rob Herring had suggested to use Linux kernel's 
generic wake irq handling. We found out it's not suitable for us. We will 
discuss it with Rob.

Regards,
Amitkumar

RE: [PATCH v6 2/2] btmrvl: add platform specific wakeup interrupt support

[Amitkumar Karwar]

Hi Marcel,

> From: Marcel Holtmann [mailto:mar...@holtmann.org]
> Sent: Friday, April 08, 2016 10:40 PM
> To: Amitkumar Karwar
> Cc: linux-blueto...@vger.kernel.org; Nishant Sarmukadam;
> wnhu...@chromium.com; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Xinming Hu
> Subject: Re: [PATCH v6 2/2] btmrvl: add platform specific wakeup
> interrupt support
> 
> Hi Amitkumar,
> 
> > On some arm-based platforms, we need to configure platform specific
> > parameters by device tree node and we need define our node as a child
> > node of parent SDIO host controller.
> > This patch parses these parameters from device tree. It includes
> > calibration data download to firmware, wakeup pin configured to
> > firmware, and soc specific wakeup interrupt pin.
> >
> > Signed-off-by: Xinming Hu 
> > Signed-off-by: Amitkumar Karwar 
> > ---
> > drivers/bluetooth/btmrvl_drv.h  | 11 ++
> > drivers/bluetooth/btmrvl_main.c | 33 +
> > drivers/bluetooth/btmrvl_sdio.c | 79
> > +
> > drivers/bluetooth/btmrvl_sdio.h |  6 
> > 4 files changed, 115 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btmrvl_drv.h
> > b/drivers/bluetooth/btmrvl_drv.h index 0590473..f742384 100644
> > --- a/drivers/bluetooth/btmrvl_drv.h
> > +++ b/drivers/bluetooth/btmrvl_drv.h
> > @@ -23,6 +23,17 @@
> > #include 
> > #include 
> > #include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> >
> > #define BTM_HEADER_LEN  4
> > #define BTM_UPLD_SIZE   2312
> > diff --git a/drivers/bluetooth/btmrvl_main.c
> > b/drivers/bluetooth/btmrvl_main.c index f25a825..25343ef 100644
> > --- a/drivers/bluetooth/btmrvl_main.c
> > +++ b/drivers/bluetooth/btmrvl_main.c
> > @@ -510,34 +510,39 @@ static int btmrvl_download_cal_data(struct
> > btmrvl_private *priv, static int btmrvl_check_device_tree(struct
> > btmrvl_private *priv) {
> > struct device_node *dt_node;
> > +   struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
> > u8 cal_data[BT_CAL_HDR_LEN + BT_CAL_DATA_SIZE];
> > -   int ret;
> > -   u32 val;
> > +   int ret = 0;
> > +   u16 gpio, gap;
> > +
> > +   if (card->plt_of_node) {
> > +   dt_node = card->plt_of_node;
> > +   ret = of_property_read_u16(dt_node, "btmrvl,wakeup-pin",
> > +  );
> > +   if (ret)
> > +   gpio = (priv->btmrvl_dev.gpio_gap & 0xff00) >> 8;
> > +
> > +   ret = of_property_read_u16(dt_node, "btmrvl,wakeup-gap",
> > +  );
> > +   if (ret)
> > +   gap = (u8)(priv->btmrvl_dev.gpio_gap & 0x00ff);
> >
> > -   for_each_compatible_node(dt_node, NULL, "btmrvl,cfgdata") {
> > -   ret = of_property_read_u32(dt_node, "btmrvl,gpio-gap",
> );
> > -   if (!ret)
> > -   priv->btmrvl_dev.gpio_gap = val;
> > +   priv->btmrvl_dev.gpio_gap = (gpio << 8) + gap;
> >
> > ret = of_property_read_u8_array(dt_node, "btmrvl,cal-data",
> > cal_data + BT_CAL_HDR_LEN,
> > BT_CAL_DATA_SIZE);
> > -   if (ret) {
> > -   of_node_put(dt_node);
> > +   if (ret)
> > return ret;
> > -   }
> >
> > BT_DBG("Use cal data from device tree");
> > ret = btmrvl_download_cal_data(priv, cal_data,
> >BT_CAL_DATA_SIZE);
> > -   if (ret) {
> > +   if (ret)
> > BT_ERR("Fail to download calibrate data");
> > -   of_node_put(dt_node);
> > -   return ret;
> > -   }
> > }
> >
> > -   return 0;
> > +   return ret;
> > }
> >
> > static int btmrvl_setup(struct hci_dev *hdev) diff --git
> > a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
> > index 6ed8acf..c714040 100644
> > --- a/drivers/bluetooth/btmrvl_sdio.c
> > +++ b/drivers/bluetooth/btmrvl_sdio.c
> > @@ -52,6 +52,68 @@ static struct memory_type_mapping
> mem_type_mapping_tbl[] = {
> > {"EXTLAST", NULL, 0, 0xFE},
> > };
> >
> > +static const struct of_device_id btmrvl_sdio_of_match_table[] = {
> > +   { .compatible = "marvell,sd8897-bt" },
> > +   { .compatible = "marvell,sd8997-bt" },
> > +   { }
> > +};
> 
> is this agreed upon by the DT maintainer? I only want to merge this
> patch if we have agreement.
> 

Please hold on for this patch. Rob Herring had suggested to use Linux kernel's 
generic wake irq handling. We found out it's not suitable for us. We will 
discuss it with Rob.

Regards,
Amitkumar

Re: [PATCH 3/3] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO pinctrl in non-ACPI system

[kbuild test robot]

Hi Tan,

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

url:
https://github.com/0day-ci/linux/commits/Tan-Jui-Nee/pinctrl-broxton-enable-platform-device-in-the-absent-of-ACPI-enumeration/20160411-105542
config: x86_64-randconfig-n0-0431 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

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

   drivers/mfd/lpc_ich.c:204:22: error: invalid application of 'sizeof' to 
incomplete type 'struct pinctrl_pin_desc'
 .pdata_size = sizeof(apl_pinctrl_pdata),
 ^
   drivers/mfd/lpc_ich.c: In function 'lpc_ich_misc':
   drivers/mfd/lpc_ich.c:1146:4: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
   apl_pinctrl_pdata.name = kasprintf(GFP_KERNEL, "%u",
   ^
   drivers/mfd/lpc_ich.c:1148:4: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
   if (apl_pinctrl_pdata.name)
   ^
   drivers/mfd/lpc_ich.c:1148:4: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
   In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from drivers/mfd/lpc_ich.c:63:
>> include/linux/compiler.h:150:17: error: invalid use of undefined type 
>> 'struct pinctrl_pin_desc'
  static struct ftrace_branch_data   \
^
   include/linux/compiler.h:145:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^
>> drivers/mfd/lpc_ich.c:1148:4: note: in expansion of macro 'if'
   if (apl_pinctrl_pdata.name)
   ^
   drivers/mfd/lpc_ich.c:1158:7: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
  apl_pinctrl_pdata.name, ret);
  ^
   drivers/mfd/lpc_ich.c:1160:4: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
   kfree(apl_pinctrl_pdata.name);
   ^

vim +150 include/linux/compiler.h

2bcd521a Steven Rostedt 2008-11-21  144   */
ab3c9c68 Linus Torvalds 2009-04-07  145  #define if(cond, ...) __trace_if( 
(cond , ## __VA_ARGS__) )
ab3c9c68 Linus Torvalds 2009-04-07  146  #define __trace_if(cond) \
ab3c9c68 Linus Torvalds 2009-04-07  147 if 
(__builtin_constant_p((cond)) ? !!(cond) :   \
2bcd521a Steven Rostedt 2008-11-21  148 ({  
\
2bcd521a Steven Rostedt 2008-11-21  149 int __r;
\
2bcd521a Steven Rostedt 2008-11-21 @150 static struct 
ftrace_branch_data\
2bcd521a Steven Rostedt 2008-11-21  151 
__attribute__((__aligned__(4))) \
2bcd521a Steven Rostedt 2008-11-21  152 
__attribute__((section("_ftrace_branch")))  \
2bcd521a Steven Rostedt 2008-11-21  153 __f = { 
\

:: The code at line 150 was first introduced by commit
:: 2bcd521a684cc94befbe2ce7d5b613c841b0d304 trace: profile all if 
conditionals

:: TO: Steven Rostedt 
:: CC: Ingo Molnar 

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


.config.gz
Description: Binary data

Re: [PATCH 3/3] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO pinctrl in non-ACPI system

[kbuild test robot]

Hi Tan,

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

url:
https://github.com/0day-ci/linux/commits/Tan-Jui-Nee/pinctrl-broxton-enable-platform-device-in-the-absent-of-ACPI-enumeration/20160411-105542
config: x86_64-randconfig-n0-0431 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

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

   drivers/mfd/lpc_ich.c:204:22: error: invalid application of 'sizeof' to 
incomplete type 'struct pinctrl_pin_desc'
 .pdata_size = sizeof(apl_pinctrl_pdata),
 ^
   drivers/mfd/lpc_ich.c: In function 'lpc_ich_misc':
   drivers/mfd/lpc_ich.c:1146:4: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
   apl_pinctrl_pdata.name = kasprintf(GFP_KERNEL, "%u",
   ^
   drivers/mfd/lpc_ich.c:1148:4: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
   if (apl_pinctrl_pdata.name)
   ^
   drivers/mfd/lpc_ich.c:1148:4: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
   In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from drivers/mfd/lpc_ich.c:63:
>> include/linux/compiler.h:150:17: error: invalid use of undefined type 
>> 'struct pinctrl_pin_desc'
  static struct ftrace_branch_data   \
^
   include/linux/compiler.h:145:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^
>> drivers/mfd/lpc_ich.c:1148:4: note: in expansion of macro 'if'
   if (apl_pinctrl_pdata.name)
   ^
   drivers/mfd/lpc_ich.c:1158:7: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
  apl_pinctrl_pdata.name, ret);
  ^
   drivers/mfd/lpc_ich.c:1160:4: error: invalid use of undefined type 'struct 
pinctrl_pin_desc'
   kfree(apl_pinctrl_pdata.name);
   ^

vim +150 include/linux/compiler.h

2bcd521a Steven Rostedt 2008-11-21  144   */
ab3c9c68 Linus Torvalds 2009-04-07  145  #define if(cond, ...) __trace_if( 
(cond , ## __VA_ARGS__) )
ab3c9c68 Linus Torvalds 2009-04-07  146  #define __trace_if(cond) \
ab3c9c68 Linus Torvalds 2009-04-07  147 if 
(__builtin_constant_p((cond)) ? !!(cond) :   \
2bcd521a Steven Rostedt 2008-11-21  148 ({  
\
2bcd521a Steven Rostedt 2008-11-21  149 int __r;
\
2bcd521a Steven Rostedt 2008-11-21 @150 static struct 
ftrace_branch_data\
2bcd521a Steven Rostedt 2008-11-21  151 
__attribute__((__aligned__(4))) \
2bcd521a Steven Rostedt 2008-11-21  152 
__attribute__((section("_ftrace_branch")))  \
2bcd521a Steven Rostedt 2008-11-21  153 __f = { 
\

:: The code at line 150 was first introduced by commit
:: 2bcd521a684cc94befbe2ce7d5b613c841b0d304 trace: profile all if 
conditionals

:: TO: Steven Rostedt 
:: CC: Ingo Molnar 

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


.config.gz
Description: Binary data

Re: Odroid XU4 deadlock

[Anand Moon]

Hi Krzysztof,

On 9 April 2016 at 16:30, Krzysztof Kozlowski  wrote:
> On Fri, Apr 8, 2016 at 5:36 PM, Anand Moon  wrote:
>> hi Javier,
>>
>> On 8 April 2016 at 20:25, Javier Martinez Canillas
>>  wrote:
>>> Hello Anand,
>>>
>>> On 04/08/2016 09:51 AM, Anand Moon wrote:
 Hi All,

 I am observing this deadlock or warning on my Odroid XU4.
 I thinks the is related to clk from exynos5_i2c_xfer  
 clk_prepare_enable
 but I am not able to figure out which clk.

>>>
>>> By reading your logs, it seems the problem is a possible ABBA deadlock since
>>> the S3C RTC driver grabs the prepare_lock and then the regmap->lock, and the
>>> CPUFreq driver leads to the locks being grabbed in the inverse order.
>
> First of all this is not a deadlock. Yet. :) This is just lockdep
> report of possible deadlock. This is deadlock:
> http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/13/steps/Boot%20odroid/logs/serial
>
> ...and I believe it is the same as the report from lockdep. Which
> means that this report truly a predicted deadlock. There are minor
> differences between deadlock on my board and report from Anand but
> still the same devices are involved. In Anands report the involved
> S2MPS11 regulator and S2MPS11 clock use the same regmap. In my case
> one path comes from S5M RTC which uses different regmap than S2MPS11
> clock. This is the difference which puzzles me.
>
> Anyway this is known issue. In case of my board mentioned deadlock
> happens only on multi_v7 on around 15% of boots. I noticed it around
> v4.4 and it happens still.
>
>>>
 [   11.640221] ==
 [   11.646343] [ INFO: possible circular locking dependency detected ]
 [   11.652590] 4.6.0-rc2-xu4ml #35 Not tainted
 [   11.656749] ---
 [   11.662992] kworker/1:1/85 is trying to acquire lock:
 [   11.668010]  (prepare_lock){+.+...}, at: []
 clk_prepare_lock+0x50/0xf8
 [   11.675375]
 [   11.675375] but task is already holding lock:
 [   11.681185]  (sec_core:428:(regmap)->lock){+.+...}, at:
 [] regmap_read+0x2c/0x5c
 [   11.689417]
 [   11.689417] which lock already depends on the new lock.
 [   11.689417]
 [   11.697561]
 [   11.697561] the existing dependency chain (in reverse order) is:
 [   11.705008]
 [   11.705008] -> #1 (sec_core:428:(regmap)->lock){+.+...}:
 [   11.710467][] regmap_update_bits_base+0x30/0x70
 [   11.716545][] s2mps11_clk_prepare+0x30/0x38
 [   11.722262][] clk_core_prepare+0x98/0xbc
 [   11.727711][] clk_prepare+0x1c/0x2c
 [   11.732734][] s3c_rtc_probe+0x2d0/0x43c
>>>
>>> the S3C RTC driver tries to prepare the RTC source clock S2MPS11_CLK_AP
>>> and that leads to the prepare_lock to be held and then the regmap->lock
>>> since s2mps11_clk_prepare() calls regmap_update_bits().
>>>
 [   11.738108][] platform_drv_probe+0x4c/0xb0
 [   11.743749][] driver_probe_device+0x20c/0x2b8
 [   11.749641][] bus_for_each_drv+0x60/0x94
 [   11.755103][] __device_attach+0xb4/0x118
 [   11.760558][] bus_probe_device+0x88/0x90
 [   11.766020][] deferred_probe_work_func+0x6c/0x9c
 [   11.772169][] process_one_work+0x1a8/0x514
 [   11.777806][] worker_thread+0x38/0x56c
 [   11.783082][] kthread+0xf4/0x10c
 [   11.787847][] ret_from_fork+0x14/0x24
 [   11.793050]
 [   11.793050] -> #0 (prepare_lock){+.+...}:
 [   11.797212][] mutex_lock_nested+0x78/0x4dc
 [   11.802845][] clk_prepare_lock+0x50/0xf8
 [   11.808304][] clk_unprepare+0x1c/0x2c
 [   11.813499][] exynos5_i2c_xfer+0x1dc/0x304
>>>
>>> and here the locks are grabbed in the inverse order, since the regulator
>>> driver uses regmap read (grabbing the regmap->lock) and then a clock is
>>> prepared in exynos5_i2c_xfer.
>>>
 [   11.819129][] __i2c_transfer+0x13c/0x278
 [   11.824589][] i2c_transfer+0x94/0xc4
 [   11.829701][] regmap_i2c_read+0x48/0x64
 [   11.835074][] _regmap_raw_read+0xb4/0x114
 [   11.840630][] _regmap_bus_read+0x24/0x58
 [   11.846084][] _regmap_read+0x60/0xb8
 [   11.851201][] regmap_read+0x3c/0x5c
 [   11.856224][] 
 regulator_get_voltage_sel_regmap+0x20/0x54
 [   11.863109][] _regulator_get_voltage+0x20/0xb8
 [   11.863141][] _regulator_do_set_voltage+0x240/0x370
 [   11.863173][] 
 regulator_set_voltage_unlocked+0xcc/0x230
 [   11.863205][] regulator_set_voltage+0x28/0x54
 [   11.863234][] _set_opp_voltage+0x30/0x98
 [   11.863264][] dev_pm_opp_set_rate+0x1e0/0x540
 [   11.863337]   

Re: [PATCH v3 00/16] Support non-lru page migration

[Minchan Kim]

On Mon, Apr 04, 2016 at 03:17:18PM +0200, John Einar Reitan wrote:
> On Wed, Mar 30, 2016 at 04:11:59PM +0900, Minchan Kim wrote:
> > Recently, I got many reports about perfermance degradation
> > in embedded system(Android mobile phone, webOS TV and so on)
> > and failed to fork easily.
> > 
> > The problem was fragmentation caused by zram and GPU driver
> > pages. Their pages cannot be migrated so compaction cannot
> > work well, either so reclaimer ends up shrinking all of working
> > set pages. It made system very slow and even to fail to fork
> > easily.
> > 
> > Other pain point is that they cannot work with CMA.
> > Most of CMA memory space could be idle(ie, it could be used
> > for movable pages unless driver is using) but if driver(i.e.,
> > zram) cannot migrate his page, that memory space could be
> > wasted. In our product which has big CMA memory, it reclaims
> > zones too exccessively although there are lots of free space
> > in CMA so system was very slow easily.
> > 
> > To solve these problem, this patch try to add facility to
> > migrate non-lru pages via introducing new friend functions
> > of migratepage in address_space_operation and new page flags.
> > 
> > (isolate_page, putback_page)
> > (PG_movable, PG_isolated)
> > 
> > For details, please read description in
> > "mm/compaction: support non-lru movable page migration".
> 
> Thanks, this mirrors what we see with the ARM Mali GPU drivers too.
> 
> One thing with the current design which worries me is the potential
> for multiple calls due to many separated pages being migrated.
> On GPUs (or any other device) which has an IOMMU and L2 cache, which
> isn't coherent with the CPU, we must do L2 cache flush & invalidation
> per page. I guess batching pages isn't easily possible?
> 

Hmm, I think it seems to cause many code stirring but surely worth
to work. So, IMMO, it would be better to add such feature after soft
landing of current work.

Anyway, I will Cc'ed you in next revision.

Thanks.

Re: Odroid XU4 deadlock

[Anand Moon]

Hi Krzysztof,

On 9 April 2016 at 16:30, Krzysztof Kozlowski  wrote:
> On Fri, Apr 8, 2016 at 5:36 PM, Anand Moon  wrote:
>> hi Javier,
>>
>> On 8 April 2016 at 20:25, Javier Martinez Canillas
>>  wrote:
>>> Hello Anand,
>>>
>>> On 04/08/2016 09:51 AM, Anand Moon wrote:
 Hi All,

 I am observing this deadlock or warning on my Odroid XU4.
 I thinks the is related to clk from exynos5_i2c_xfer  
 clk_prepare_enable
 but I am not able to figure out which clk.

>>>
>>> By reading your logs, it seems the problem is a possible ABBA deadlock since
>>> the S3C RTC driver grabs the prepare_lock and then the regmap->lock, and the
>>> CPUFreq driver leads to the locks being grabbed in the inverse order.
>
> First of all this is not a deadlock. Yet. :) This is just lockdep
> report of possible deadlock. This is deadlock:
> http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/13/steps/Boot%20odroid/logs/serial
>
> ...and I believe it is the same as the report from lockdep. Which
> means that this report truly a predicted deadlock. There are minor
> differences between deadlock on my board and report from Anand but
> still the same devices are involved. In Anands report the involved
> S2MPS11 regulator and S2MPS11 clock use the same regmap. In my case
> one path comes from S5M RTC which uses different regmap than S2MPS11
> clock. This is the difference which puzzles me.
>
> Anyway this is known issue. In case of my board mentioned deadlock
> happens only on multi_v7 on around 15% of boots. I noticed it around
> v4.4 and it happens still.
>
>>>
 [   11.640221] ==
 [   11.646343] [ INFO: possible circular locking dependency detected ]
 [   11.652590] 4.6.0-rc2-xu4ml #35 Not tainted
 [   11.656749] ---
 [   11.662992] kworker/1:1/85 is trying to acquire lock:
 [   11.668010]  (prepare_lock){+.+...}, at: []
 clk_prepare_lock+0x50/0xf8
 [   11.675375]
 [   11.675375] but task is already holding lock:
 [   11.681185]  (sec_core:428:(regmap)->lock){+.+...}, at:
 [] regmap_read+0x2c/0x5c
 [   11.689417]
 [   11.689417] which lock already depends on the new lock.
 [   11.689417]
 [   11.697561]
 [   11.697561] the existing dependency chain (in reverse order) is:
 [   11.705008]
 [   11.705008] -> #1 (sec_core:428:(regmap)->lock){+.+...}:
 [   11.710467][] regmap_update_bits_base+0x30/0x70
 [   11.716545][] s2mps11_clk_prepare+0x30/0x38
 [   11.722262][] clk_core_prepare+0x98/0xbc
 [   11.727711][] clk_prepare+0x1c/0x2c
 [   11.732734][] s3c_rtc_probe+0x2d0/0x43c
>>>
>>> the S3C RTC driver tries to prepare the RTC source clock S2MPS11_CLK_AP
>>> and that leads to the prepare_lock to be held and then the regmap->lock
>>> since s2mps11_clk_prepare() calls regmap_update_bits().
>>>
 [   11.738108][] platform_drv_probe+0x4c/0xb0
 [   11.743749][] driver_probe_device+0x20c/0x2b8
 [   11.749641][] bus_for_each_drv+0x60/0x94
 [   11.755103][] __device_attach+0xb4/0x118
 [   11.760558][] bus_probe_device+0x88/0x90
 [   11.766020][] deferred_probe_work_func+0x6c/0x9c
 [   11.772169][] process_one_work+0x1a8/0x514
 [   11.777806][] worker_thread+0x38/0x56c
 [   11.783082][] kthread+0xf4/0x10c
 [   11.787847][] ret_from_fork+0x14/0x24
 [   11.793050]
 [   11.793050] -> #0 (prepare_lock){+.+...}:
 [   11.797212][] mutex_lock_nested+0x78/0x4dc
 [   11.802845][] clk_prepare_lock+0x50/0xf8
 [   11.808304][] clk_unprepare+0x1c/0x2c
 [   11.813499][] exynos5_i2c_xfer+0x1dc/0x304
>>>
>>> and here the locks are grabbed in the inverse order, since the regulator
>>> driver uses regmap read (grabbing the regmap->lock) and then a clock is
>>> prepared in exynos5_i2c_xfer.
>>>
 [   11.819129][] __i2c_transfer+0x13c/0x278
 [   11.824589][] i2c_transfer+0x94/0xc4
 [   11.829701][] regmap_i2c_read+0x48/0x64
 [   11.835074][] _regmap_raw_read+0xb4/0x114
 [   11.840630][] _regmap_bus_read+0x24/0x58
 [   11.846084][] _regmap_read+0x60/0xb8
 [   11.851201][] regmap_read+0x3c/0x5c
 [   11.856224][] 
 regulator_get_voltage_sel_regmap+0x20/0x54
 [   11.863109][] _regulator_get_voltage+0x20/0xb8
 [   11.863141][] _regulator_do_set_voltage+0x240/0x370
 [   11.863173][] 
 regulator_set_voltage_unlocked+0xcc/0x230
 [   11.863205][] regulator_set_voltage+0x28/0x54
 [   11.863234][] _set_opp_voltage+0x30/0x98
 [   11.863264][] dev_pm_opp_set_rate+0x1e0/0x540
 [   11.863337][] __cpufreq_driver_target+0x168/0x290
 [   11.863375][] 

Re: [PATCH v3 00/16] Support non-lru page migration

[Minchan Kim]

On Mon, Apr 04, 2016 at 03:17:18PM +0200, John Einar Reitan wrote:
> On Wed, Mar 30, 2016 at 04:11:59PM +0900, Minchan Kim wrote:
> > Recently, I got many reports about perfermance degradation
> > in embedded system(Android mobile phone, webOS TV and so on)
> > and failed to fork easily.
> > 
> > The problem was fragmentation caused by zram and GPU driver
> > pages. Their pages cannot be migrated so compaction cannot
> > work well, either so reclaimer ends up shrinking all of working
> > set pages. It made system very slow and even to fail to fork
> > easily.
> > 
> > Other pain point is that they cannot work with CMA.
> > Most of CMA memory space could be idle(ie, it could be used
> > for movable pages unless driver is using) but if driver(i.e.,
> > zram) cannot migrate his page, that memory space could be
> > wasted. In our product which has big CMA memory, it reclaims
> > zones too exccessively although there are lots of free space
> > in CMA so system was very slow easily.
> > 
> > To solve these problem, this patch try to add facility to
> > migrate non-lru pages via introducing new friend functions
> > of migratepage in address_space_operation and new page flags.
> > 
> > (isolate_page, putback_page)
> > (PG_movable, PG_isolated)
> > 
> > For details, please read description in
> > "mm/compaction: support non-lru movable page migration".
> 
> Thanks, this mirrors what we see with the ARM Mali GPU drivers too.
> 
> One thing with the current design which worries me is the potential
> for multiple calls due to many separated pages being migrated.
> On GPUs (or any other device) which has an IOMMU and L2 cache, which
> isn't coherent with the CPU, we must do L2 cache flush & invalidation
> per page. I guess batching pages isn't easily possible?
> 

Hmm, I think it seems to cause many code stirring but surely worth
to work. So, IMMO, it would be better to add such feature after soft
landing of current work.

Anyway, I will Cc'ed you in next revision.

Thanks.

Re: [PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

[kbuild test robot]

Hi Andi,

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

url:
https://github.com/0day-ci/linux/commits/Andi-Kleen/audit-Don-t-spam-logs-with-SECCOMP_KILL-RET_ERRNO-by-default/20160411-122005
base:   git://git.infradead.org/users/pcmoore/audit next
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

>> kernel/sysctl.c:524:13: error: 'audit_log_seccomp' undeclared here (not in a 
>> function)
  .data  = _log_seccomp,
^

vim +/audit_log_seccomp +524 kernel/sysctl.c

   518  .proc_handler   = proc_dointvec,
   519  },
   520  #endif
   521  #ifdef CONFIG_AUDIT
   522  {
   523  .procname   = "audit-log-seccomp",
 > 524  .data   = _log_seccomp,
   525  .maxlen = sizeof(int),
   526  .mode   = 0644,
   527  .proc_handler   = proc_dointvec,

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


.config.gz
Description: Binary data

Re: [PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

[kbuild test robot]

Hi Andi,

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

url:
https://github.com/0day-ci/linux/commits/Andi-Kleen/audit-Don-t-spam-logs-with-SECCOMP_KILL-RET_ERRNO-by-default/20160411-122005
base:   git://git.infradead.org/users/pcmoore/audit next
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

>> kernel/sysctl.c:524:13: error: 'audit_log_seccomp' undeclared here (not in a 
>> function)
  .data  = _log_seccomp,
^

vim +/audit_log_seccomp +524 kernel/sysctl.c

   518  .proc_handler   = proc_dointvec,
   519  },
   520  #endif
   521  #ifdef CONFIG_AUDIT
   522  {
   523  .procname   = "audit-log-seccomp",
 > 524  .data   = _log_seccomp,
   525  .maxlen = sizeof(int),
   526  .mode   = 0644,
   527  .proc_handler   = proc_dointvec,

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


.config.gz
Description: Binary data

Re: [PATCH v3 04/16] mm/balloon: use general movable page feature into balloon

[Minchan Kim]

On Tue, Apr 05, 2016 at 02:03:05PM +0200, Vlastimil Babka wrote:
> On 03/30/2016 09:12 AM, Minchan Kim wrote:
> >Now, VM has a feature to migrate non-lru movable pages so
> >balloon doesn't need custom migration hooks in migrate.c
> >and compact.c. Instead, this patch implements page->mapping
> >->{isolate|migrate|putback} functions.
> >
> >With that, we could remove hooks for ballooning in general
> >migration functions and make balloon compaction simple.
> >
> >Cc: virtualizat...@lists.linux-foundation.org
> >Cc: Rafael Aquini 
> >Cc: Konstantin Khlebnikov 
> >Signed-off-by: Gioh Kim 
> >Signed-off-by: Minchan Kim 
> 
> I'm not familiar with the inode and pseudofs stuff, so just some
> things I noticed:
> 
> >-#define PAGE_MOVABLE_MAPCOUNT_VALUE (-255)
> >+#define PAGE_MOVABLE_MAPCOUNT_VALUE (-256)
> >+#define PAGE_BALLOON_MAPCOUNT_VALUE PAGE_MOVABLE_MAPCOUNT_VALUE
> >
> >  static inline int PageMovable(struct page *page)
> >  {
> >-return ((test_bit(PG_movable, &(page)->flags) &&
> >-atomic_read(>_mapcount) == PAGE_MOVABLE_MAPCOUNT_VALUE)
> >-|| PageBalloon(page));
> >+return (test_bit(PG_movable, &(page)->flags) &&
> >+atomic_read(>_mapcount) == PAGE_MOVABLE_MAPCOUNT_VALUE);
> >  }
> >
> >  /* Caller should hold a PG_lock */
> >@@ -645,6 +626,35 @@ static inline void __ClearPageMovable(struct page *page)
> >
> >  PAGEFLAG(Isolated, isolated, PF_ANY);
> >
> >+static inline int PageBalloon(struct page *page)
> >+{
> >+return atomic_read(>_mapcount) == PAGE_BALLOON_MAPCOUNT_VALUE
> >+&& PagePrivate2(page);
> >+}
> 
> Hmm so you are now using PG_private_2 flag here, but it's not
> documented. Also the only caller of PageBalloon() seems to be
> stable_page_flags(). Which will now report all movable pages with
> PG_private_2 as KPF_BALOON. Seems like an overkill and also not
> reliable. Could it test e.g. page->mapping instead?

Thanks for pointing out.
I will not use page->_mapcount in next version so it should be okay.

> 
> Or maybe if we manage to get rid of PAGE_MOVABLE_MAPCOUNT_VALUE, we
> can keep PAGE_BALLOON_MAPCOUNT_VALUE to simply distinguish balloon
> pages for stable_page_flags().

Yeb.

> 
> >@@ -1033,7 +1019,7 @@ static int __unmap_and_move(struct page *page, struct 
> >page *newpage,
> >  out:
> > /* If migration is successful, move newpage to right list */
> > if (rc == MIGRATEPAGE_SUCCESS) {
> >-if (unlikely(__is_movable_balloon_page(newpage)))
> >+if (unlikely(PageMovable(newpage)))
> > put_page(newpage);
> > else
> > putback_lru_page(newpage);
> 
> Hmm shouldn't the condition have been changed to
> 
> if (unlikely(__is_movable_balloon_page(newpage)) || PageMovable(newpage)
> 
> by patch 02/16? And this patch should be just removing the
> balloon-specific check? Otherwise it seems like between patches 02
> and 04, other kinds of PageMovable pages were unnecessarily/wrongly
> routed through putback_lru_page()?

Fixed.

> 
> >diff --git a/mm/vmscan.c b/mm/vmscan.c
> >index d82196244340..c7696a2e11c7 100644
> >--- a/mm/vmscan.c
> >+++ b/mm/vmscan.c
> >@@ -1254,7 +1254,7 @@ unsigned long reclaim_clean_pages_from_list(struct 
> >zone *zone,
> >
> > list_for_each_entry_safe(page, next, page_list, lru) {
> > if (page_is_file_cache(page) && !PageDirty(page) &&
> >-!isolated_balloon_page(page)) {
> >+!PageIsolated(page)) {
> > ClearPageActive(page);
> > list_move(>lru, _pages);
> > }
> 
> This looks like the same comment as above at first glance. But
> looking closer, it's even weirder. isolated_balloon_page() was
> simply PageBalloon() after d6d86c0a7f8dd... weird already. You
> replace it with check for !PageIsolated() which looks like a more
> correct check, so ok. Except the potential false positive with
> PG_owner_priv_1.

I will change it next version so it shouldn't be a problem.
Thanks for the review!

Re: [PATCH v3 04/16] mm/balloon: use general movable page feature into balloon

[Minchan Kim]

On Tue, Apr 05, 2016 at 02:03:05PM +0200, Vlastimil Babka wrote:
> On 03/30/2016 09:12 AM, Minchan Kim wrote:
> >Now, VM has a feature to migrate non-lru movable pages so
> >balloon doesn't need custom migration hooks in migrate.c
> >and compact.c. Instead, this patch implements page->mapping
> >->{isolate|migrate|putback} functions.
> >
> >With that, we could remove hooks for ballooning in general
> >migration functions and make balloon compaction simple.
> >
> >Cc: virtualizat...@lists.linux-foundation.org
> >Cc: Rafael Aquini 
> >Cc: Konstantin Khlebnikov 
> >Signed-off-by: Gioh Kim 
> >Signed-off-by: Minchan Kim 
> 
> I'm not familiar with the inode and pseudofs stuff, so just some
> things I noticed:
> 
> >-#define PAGE_MOVABLE_MAPCOUNT_VALUE (-255)
> >+#define PAGE_MOVABLE_MAPCOUNT_VALUE (-256)
> >+#define PAGE_BALLOON_MAPCOUNT_VALUE PAGE_MOVABLE_MAPCOUNT_VALUE
> >
> >  static inline int PageMovable(struct page *page)
> >  {
> >-return ((test_bit(PG_movable, &(page)->flags) &&
> >-atomic_read(>_mapcount) == PAGE_MOVABLE_MAPCOUNT_VALUE)
> >-|| PageBalloon(page));
> >+return (test_bit(PG_movable, &(page)->flags) &&
> >+atomic_read(>_mapcount) == PAGE_MOVABLE_MAPCOUNT_VALUE);
> >  }
> >
> >  /* Caller should hold a PG_lock */
> >@@ -645,6 +626,35 @@ static inline void __ClearPageMovable(struct page *page)
> >
> >  PAGEFLAG(Isolated, isolated, PF_ANY);
> >
> >+static inline int PageBalloon(struct page *page)
> >+{
> >+return atomic_read(>_mapcount) == PAGE_BALLOON_MAPCOUNT_VALUE
> >+&& PagePrivate2(page);
> >+}
> 
> Hmm so you are now using PG_private_2 flag here, but it's not
> documented. Also the only caller of PageBalloon() seems to be
> stable_page_flags(). Which will now report all movable pages with
> PG_private_2 as KPF_BALOON. Seems like an overkill and also not
> reliable. Could it test e.g. page->mapping instead?

Thanks for pointing out.
I will not use page->_mapcount in next version so it should be okay.

> 
> Or maybe if we manage to get rid of PAGE_MOVABLE_MAPCOUNT_VALUE, we
> can keep PAGE_BALLOON_MAPCOUNT_VALUE to simply distinguish balloon
> pages for stable_page_flags().

Yeb.

> 
> >@@ -1033,7 +1019,7 @@ static int __unmap_and_move(struct page *page, struct 
> >page *newpage,
> >  out:
> > /* If migration is successful, move newpage to right list */
> > if (rc == MIGRATEPAGE_SUCCESS) {
> >-if (unlikely(__is_movable_balloon_page(newpage)))
> >+if (unlikely(PageMovable(newpage)))
> > put_page(newpage);
> > else
> > putback_lru_page(newpage);
> 
> Hmm shouldn't the condition have been changed to
> 
> if (unlikely(__is_movable_balloon_page(newpage)) || PageMovable(newpage)
> 
> by patch 02/16? And this patch should be just removing the
> balloon-specific check? Otherwise it seems like between patches 02
> and 04, other kinds of PageMovable pages were unnecessarily/wrongly
> routed through putback_lru_page()?

Fixed.

> 
> >diff --git a/mm/vmscan.c b/mm/vmscan.c
> >index d82196244340..c7696a2e11c7 100644
> >--- a/mm/vmscan.c
> >+++ b/mm/vmscan.c
> >@@ -1254,7 +1254,7 @@ unsigned long reclaim_clean_pages_from_list(struct 
> >zone *zone,
> >
> > list_for_each_entry_safe(page, next, page_list, lru) {
> > if (page_is_file_cache(page) && !PageDirty(page) &&
> >-!isolated_balloon_page(page)) {
> >+!PageIsolated(page)) {
> > ClearPageActive(page);
> > list_move(>lru, _pages);
> > }
> 
> This looks like the same comment as above at first glance. But
> looking closer, it's even weirder. isolated_balloon_page() was
> simply PageBalloon() after d6d86c0a7f8dd... weird already. You
> replace it with check for !PageIsolated() which looks like a more
> correct check, so ok. Except the potential false positive with
> PG_owner_priv_1.

I will change it next version so it shouldn't be a problem.
Thanks for the review!

[PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

[Andi Kleen]

From: Andi Kleen 

When I run chrome on my opensuse system every time I open
a new tab the system log is spammed with:

audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857
comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e
syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5

This happens because chrome uses SECCOMP for its sandbox,
and for some reason always reaches a SECCOMP_KILL or more likely
SECCOMP_RET_ERRNO in the rule set.

The seccomp auditing was originally added by Eric with

commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31
Author: Eric Paris 
Date:   Tue Jan 3 14:23:05 2012 -0500

seccomp: audit abnormal end to a process due to seccomp

The audit system likes to collect information about processes that end
abnormally (SIGSEGV) as this may me useful intrusion detection 
information.
This patch adds audit support to collect information when seccomp
forces a task to exit because of misbehavior in a similar way.

I don't have any other syscall auditing enabled,
just the standard user space auditing used by the systemd
and PAM userland. So basic auditing is alwas enabled,
but no other kernel auditing.

Add a sysctl to enable this unconditional behavior with default
to off. This replaces an earlier patch that simply checked
whether syscall auditing was on, but Paul Moore preferred
this more elaborate approach.

Signed-off-by: Andi Kleen 
---
 Documentation/sysctl/kernel.txt |  9 +
 include/linux/audit.h   |  4 +++-
 kernel/seccomp.c|  4 
 kernel/sysctl.c | 11 +++
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 57653a4..abc6ef9 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -21,6 +21,7 @@ show up in /proc/sys/kernel:
 - acct
 - acpi_video_flags
 - auto_msgmni
+- audit_log_seccomp
 - bootloader_type   [ X86 only ]
 - bootloader_version[ X86 only ]
 - callhome  [ S390 only ]
@@ -129,6 +130,14 @@ upon memory add/remove or upon ipc namespace 
creation/removal.
 Echoing "1" into this file enabled msgmni automatic recomputing.
 Echoing "0" turned it off. auto_msgmni default value was 1.
 
+==
+
+audit_log_seccomp
+
+When this variable is set to 1 every SECCOMP_KILL/SECCOMP_RET_ERRNO
+results in an audit log. This is generally a bad idea because
+it leads to a audit message every time Chrome opens a new tab.
+Defaults to 0.
 
 ==
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index e38e3fc..c7787ba 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -315,9 +315,11 @@ static inline void audit_inode_child(struct inode *parent,
 }
 void audit_core_dumps(long signr);
 
+extern int audit_log_seccomp;
+
 static inline void audit_seccomp(unsigned long syscall, long signr, int code)
 {
-   if (!audit_enabled)
+   if (!audit_enabled || !audit_log_seccomp)
return;
 
/* Force a record to be reported if a signal was delivered. */
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index e1e5a35..09a8b03 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -25,6 +25,10 @@
 #include 
 #endif
 
+#ifdef CONFIG_AUDIT
+int audit_log_seccomp __read_mostly = 0;
+#endif
+
 #ifdef CONFIG_SECCOMP_FILTER
 #include 
 #include 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 725587f..0c7611e 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -529,6 +530,16 @@ static struct ctl_table kern_table[] = {
.proc_handler   = proc_dointvec,
},
 #endif
+#ifdef CONFIG_AUDIT
+   {
+   .procname   = "audit-log-seccomp",
+   .data   = _log_seccomp,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+
+#endif
{
.procname   = "print-fatal-signals",
.data   = _fatal_signals,
-- 
2.7.4

[PATCH] audit: Don't spam logs with SECCOMP_KILL/RET_ERRNO by default

[Andi Kleen]

From: Andi Kleen 

When I run chrome on my opensuse system every time I open
a new tab the system log is spammed with:

audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857
comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e
syscall=273 compat=0 ip=0x7fe27c11a444 code=0x5

This happens because chrome uses SECCOMP for its sandbox,
and for some reason always reaches a SECCOMP_KILL or more likely
SECCOMP_RET_ERRNO in the rule set.

The seccomp auditing was originally added by Eric with

commit 85e7bac33b8d5edafc4e219c7dfdb3d48e0b4e31
Author: Eric Paris 
Date:   Tue Jan 3 14:23:05 2012 -0500

seccomp: audit abnormal end to a process due to seccomp

The audit system likes to collect information about processes that end
abnormally (SIGSEGV) as this may me useful intrusion detection 
information.
This patch adds audit support to collect information when seccomp
forces a task to exit because of misbehavior in a similar way.

I don't have any other syscall auditing enabled,
just the standard user space auditing used by the systemd
and PAM userland. So basic auditing is alwas enabled,
but no other kernel auditing.

Add a sysctl to enable this unconditional behavior with default
to off. This replaces an earlier patch that simply checked
whether syscall auditing was on, but Paul Moore preferred
this more elaborate approach.

Signed-off-by: Andi Kleen 
---
 Documentation/sysctl/kernel.txt |  9 +
 include/linux/audit.h   |  4 +++-
 kernel/seccomp.c|  4 
 kernel/sysctl.c | 11 +++
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 57653a4..abc6ef9 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -21,6 +21,7 @@ show up in /proc/sys/kernel:
 - acct
 - acpi_video_flags
 - auto_msgmni
+- audit_log_seccomp
 - bootloader_type   [ X86 only ]
 - bootloader_version[ X86 only ]
 - callhome  [ S390 only ]
@@ -129,6 +130,14 @@ upon memory add/remove or upon ipc namespace 
creation/removal.
 Echoing "1" into this file enabled msgmni automatic recomputing.
 Echoing "0" turned it off. auto_msgmni default value was 1.
 
+==
+
+audit_log_seccomp
+
+When this variable is set to 1 every SECCOMP_KILL/SECCOMP_RET_ERRNO
+results in an audit log. This is generally a bad idea because
+it leads to a audit message every time Chrome opens a new tab.
+Defaults to 0.
 
 ==
 
diff --git a/include/linux/audit.h b/include/linux/audit.h
index e38e3fc..c7787ba 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -315,9 +315,11 @@ static inline void audit_inode_child(struct inode *parent,
 }
 void audit_core_dumps(long signr);
 
+extern int audit_log_seccomp;
+
 static inline void audit_seccomp(unsigned long syscall, long signr, int code)
 {
-   if (!audit_enabled)
+   if (!audit_enabled || !audit_log_seccomp)
return;
 
/* Force a record to be reported if a signal was delivered. */
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index e1e5a35..09a8b03 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -25,6 +25,10 @@
 #include 
 #endif
 
+#ifdef CONFIG_AUDIT
+int audit_log_seccomp __read_mostly = 0;
+#endif
+
 #ifdef CONFIG_SECCOMP_FILTER
 #include 
 #include 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 725587f..0c7611e 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -529,6 +530,16 @@ static struct ctl_table kern_table[] = {
.proc_handler   = proc_dointvec,
},
 #endif
+#ifdef CONFIG_AUDIT
+   {
+   .procname   = "audit-log-seccomp",
+   .data   = _log_seccomp,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec,
+   },
+
+#endif
{
.procname   = "print-fatal-signals",
.data   = _fatal_signals,
-- 
2.7.4

Re: [PATCH 0/7] PM / devfreq: Add NoCP devfreq-event and support busfreq on exyno5422-odroidxu3

[Chanwoo Choi]

Dear all,

On 2016년 04월 08일 14:00, Chanwoo Choi wrote:
> This patchset support the AMBA bus frequency scaling on Exynos5422-based
> Odroid-XU3 board. But, this series only support the bus frequency scaling
> for INT (Internal) block using VDD_INT power line.
> 
> Also, to support the bus frequency scaling for Exynos542x SoC,
> Exynos542x SoC has the specific 'NoC (Network on Chip) Probe' device
> to measure the transfered data traffic on NoC (Network on Chip)
> instead of PPMU (Platform Performance Monitoring Unit). NoC Probe device
> provide the utilization for INT block of Exynos542x SoC.
> 
> The generic exynos-bus frequency driver uses the 'NoC Probe' devfreq-event
> device (drivers/devfreq/event/exynos-nocp.c) without any modification.
> Just add the phandle of 'NoC Probe' dt node to bus dt node.
> 
> Depend on:
> This patchset depends on patch[1] which support the generic exynos-bus
> frequency driver.
> 
> [1] https://lkml.org/lkml/2016/4/8/14
> - [PATCH v8 00/20] PM / devferq: Add generic exynos bus frequency driver and 
> new passive governor

The dependency of these patch-set is changed from patches[1] to patches[2].
Because patches[1] has the possible recursive locking issue. Patches[2] fix 
this issue.

[2] http://www.spinics.net/lists/arm-kernel/msg495976.html
- [PATCH v9 00/20] PM / devferq: Add generic exynos bus frequency driver and 
new passive governor

[snip]

Best Regards,
Chanwoo Choi

Re: [PATCH 0/7] PM / devfreq: Add NoCP devfreq-event and support busfreq on exyno5422-odroidxu3

[Chanwoo Choi]

Dear all,

On 2016년 04월 08일 14:00, Chanwoo Choi wrote:
> This patchset support the AMBA bus frequency scaling on Exynos5422-based
> Odroid-XU3 board. But, this series only support the bus frequency scaling
> for INT (Internal) block using VDD_INT power line.
> 
> Also, to support the bus frequency scaling for Exynos542x SoC,
> Exynos542x SoC has the specific 'NoC (Network on Chip) Probe' device
> to measure the transfered data traffic on NoC (Network on Chip)
> instead of PPMU (Platform Performance Monitoring Unit). NoC Probe device
> provide the utilization for INT block of Exynos542x SoC.
> 
> The generic exynos-bus frequency driver uses the 'NoC Probe' devfreq-event
> device (drivers/devfreq/event/exynos-nocp.c) without any modification.
> Just add the phandle of 'NoC Probe' dt node to bus dt node.
> 
> Depend on:
> This patchset depends on patch[1] which support the generic exynos-bus
> frequency driver.
> 
> [1] https://lkml.org/lkml/2016/4/8/14
> - [PATCH v8 00/20] PM / devferq: Add generic exynos bus frequency driver and 
> new passive governor

The dependency of these patch-set is changed from patches[1] to patches[2].
Because patches[1] has the possible recursive locking issue. Patches[2] fix 
this issue.

[2] http://www.spinics.net/lists/arm-kernel/msg495976.html
- [PATCH v9 00/20] PM / devferq: Add generic exynos bus frequency driver and 
new passive governor

[snip]

Best Regards,
Chanwoo Choi

linux-next: Tree for Apr 11

[Stephen Rothwell]

Hi all,

Changes since 20160408:

The akpm-current tree still had its build failure for which I applied
a patch.

Non-merge commits (relative to Linus' tree): 2971
 2781 files changed, 115585 insertions(+), 69801 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (5b5b7fd185e9 Merge branch 'parisc-4.6-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (0dee6c82c2aa ARC: [plat-axs103] Enable loop block 
devices)
Merging arm-current/fixes (208fae5c3b94 ARM: 8550/1: protect idiv patching 
against undefined gcc behavior)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (49dd48dafec6 sh_eth: re-enable-E-MAC interrupts in 
sh_eth_set_ringparam())
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (76e6abb5798a nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (b4203ff5464d ALSA: usb-audio: Add a quirk for 
Plantronics BT300)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging tty.current/tty-linus (5e00bbfbc5ec tty: Fix merge of "tty: Refactor 
tty_open()")
Merging usb.current/usb-linus (5b5b7fd185e9 Merge branch 'parisc-4.6-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging usb-gadget-fixes/fixes (adf9a3ab90eb usb: dwc3: keystone: drop dma_mask 
configuration)
Merging usb-serial-fixes/usb-linus (d48d5691ebf8 USB: option: add "D-Link 
DWM-221 B1" device id)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (53c43c5ca133 Revert "Staging: olpc_dcon: 
Remove obsolete driver")
Merging char-misc.current/char-misc-linus (053f78d35995 Merge tag 
'lkdtm-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 
into char-misc-linus)
Merging input-current/for-linus (7eb5ca09e48e Input: clarify we want 
BTN_TOOL_ on proximity)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging 

linux-next: Tree for Apr 11

[Stephen Rothwell]

Hi all,

Changes since 20160408:

The akpm-current tree still had its build failure for which I applied
a patch.

Non-merge commits (relative to Linus' tree): 2971
 2781 files changed, 115585 insertions(+), 69801 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (5b5b7fd185e9 Merge branch 'parisc-4.6-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (0dee6c82c2aa ARC: [plat-axs103] Enable loop block 
devices)
Merging arm-current/fixes (208fae5c3b94 ARM: 8550/1: protect idiv patching 
against undefined gcc behavior)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (49dd48dafec6 sh_eth: re-enable-E-MAC interrupts in 
sh_eth_set_ringparam())
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (76e6abb5798a nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (b4203ff5464d ALSA: usb-audio: Add a quirk for 
Plantronics BT300)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging tty.current/tty-linus (5e00bbfbc5ec tty: Fix merge of "tty: Refactor 
tty_open()")
Merging usb.current/usb-linus (5b5b7fd185e9 Merge branch 'parisc-4.6-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging usb-gadget-fixes/fixes (adf9a3ab90eb usb: dwc3: keystone: drop dma_mask 
configuration)
Merging usb-serial-fixes/usb-linus (d48d5691ebf8 USB: option: add "D-Link 
DWM-221 B1" device id)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (53c43c5ca133 Revert "Staging: olpc_dcon: 
Remove obsolete driver")
Merging char-misc.current/char-misc-linus (053f78d35995 Merge tag 
'lkdtm-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 
into char-misc-linus)
Merging input-current/for-linus (7eb5ca09e48e Input: clarify we want 
BTN_TOOL_ on proximity)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging 

Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

[Andi Kleen]

On Sun, Apr 10, 2016 at 10:30:10PM -0400, Paul Moore wrote:
> On Sun, Apr 10, 2016 at 6:31 PM, Andi Kleen  wrote:
> > On Sun, Apr 10, 2016 at 06:17:53PM -0400, Paul Moore wrote:
> >> On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen  wrote:
> >> >> What kernel version are you using?  I believe we fixed that in Linux
> >> >> 4.5 with the following:
> >> >
> >> > This is 4.6-rc2.
> >> >>
> >> >>   commit 96368701e1c89057bbf39222e965161c68a85b4b
> >> >>   From: Paul Moore 
> >> >>   Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500)
> >> >>
> >> >>   audit: force seccomp event logging to honor the audit_enabled flag
> >> >
> >> > No you didn't fix it because audit_enabled is always enabled by systemd
> >> > for user space auditing, see the original description of my patch.
> >>
> >> [NOTE: adding the audit list to the CC line]
> >
> > This mailing list is marked subscriber only in MAINTAINERS so I
> > intentionally didn't add it. It's unlikely that my emails
> > will make it through.
> 
> Steve Grubb checks it on a regular basis and approves anything
> remotely audit related.  Please make use of it in the future; it's
> listed in MAINTAINERS for a reason.

Nothing has appeared by now. A mailing list that does not allow
real time discussion is fairly useless. 

Dropped again.

> >> If you are interested, I started tracking this issue at the link below:
> >>
> >>  * https://github.com/linux-audit/audit-kernel/issues/13
> >
> > Making it a sysctl is fine for me as long as it is disabled by default
> > so that user space doesn't need to be modified to make seccomp
> > stop spamming.
> >
> > Audit should always be opt-in, not opt-out.
> 
> From my perspective, you, or rather systemd in your case, is opting in
> by enabling audit.

It wants an audit channel, but not random kernel subsystems
unconditionally spamming the logs. If it wanted the later it would
set audit rules.

> 
> > However I think making it conditional on syscall auditing like
> > in my patch is equivalent and much simpler.
> >
> > If you really insist on the sysctl I can send patch.
> 
> As I said earlier, I haven't given this a lot of thought as of yet,
> but so far I like the sysctl approach much more than the patch you
> sent earlier.

Ok I'm sending an updated patch.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

[Andi Kleen]

On Sun, Apr 10, 2016 at 10:30:10PM -0400, Paul Moore wrote:
> On Sun, Apr 10, 2016 at 6:31 PM, Andi Kleen  wrote:
> > On Sun, Apr 10, 2016 at 06:17:53PM -0400, Paul Moore wrote:
> >> On Sat, Apr 9, 2016 at 10:41 PM, Andi Kleen  wrote:
> >> >> What kernel version are you using?  I believe we fixed that in Linux
> >> >> 4.5 with the following:
> >> >
> >> > This is 4.6-rc2.
> >> >>
> >> >>   commit 96368701e1c89057bbf39222e965161c68a85b4b
> >> >>   From: Paul Moore 
> >> >>   Date: Wed, 13 Jan 2016 10:18:55 -0400 (09:18 -0500)
> >> >>
> >> >>   audit: force seccomp event logging to honor the audit_enabled flag
> >> >
> >> > No you didn't fix it because audit_enabled is always enabled by systemd
> >> > for user space auditing, see the original description of my patch.
> >>
> >> [NOTE: adding the audit list to the CC line]
> >
> > This mailing list is marked subscriber only in MAINTAINERS so I
> > intentionally didn't add it. It's unlikely that my emails
> > will make it through.
> 
> Steve Grubb checks it on a regular basis and approves anything
> remotely audit related.  Please make use of it in the future; it's
> listed in MAINTAINERS for a reason.

Nothing has appeared by now. A mailing list that does not allow
real time discussion is fairly useless. 

Dropped again.

> >> If you are interested, I started tracking this issue at the link below:
> >>
> >>  * https://github.com/linux-audit/audit-kernel/issues/13
> >
> > Making it a sysctl is fine for me as long as it is disabled by default
> > so that user space doesn't need to be modified to make seccomp
> > stop spamming.
> >
> > Audit should always be opt-in, not opt-out.
> 
> From my perspective, you, or rather systemd in your case, is opting in
> by enabling audit.

It wants an audit channel, but not random kernel subsystems
unconditionally spamming the logs. If it wanted the later it would
set audit rules.

> 
> > However I think making it conditional on syscall auditing like
> > in my patch is equivalent and much simpler.
> >
> > If you really insist on the sysctl I can send patch.
> 
> As I said earlier, I haven't given this a lot of thought as of yet,
> but so far I like the sysctl approach much more than the patch you
> sent earlier.

Ok I'm sending an updated patch.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.

Re: [PATCH] scripts/gdb: Use $(abspath ...) instead of $(shell cd ... && pwd)

[Jan Kiszka]

On 2016-04-08 02:16, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Avoid forking off a shell to resolve the absolute path of the output
> directory when make's builtin $(abspath ...) function will do an
> adequate job.
> 
> Signed-off-by: Thierry Reding 
> ---
>  scripts/gdb/linux/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/gdb/linux/Makefile b/scripts/gdb/linux/Makefile
> index 6cf1ecf61057..d8b88e22e16a 100644
> --- a/scripts/gdb/linux/Makefile
> +++ b/scripts/gdb/linux/Makefile
> @@ -1,6 +1,6 @@
>  always := gdb-scripts
>  
> -SRCTREE := $(shell cd $(srctree) && /bin/pwd)
> +SRCTREE := $(abspath $(srctree))
>  
>  $(obj)/gdb-scripts:
>  ifneq ($(KBUILD_SRC),)
> 

Thanks, good cleanup. Queued.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

RE: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

[Chakravarty, Souvik K]

> -Original Message-
> From: Zha, Qipeng
> Sent: Monday, April 11, 2016 7:34 AM
> To: Darren Hart ; Aubrey Li
> ; Chakravarty, Souvik K
> 
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] platform:x86 decouple telemetry driver from the
> optional IPC resources
> 
> >> Currently the optional IPC resources prevent telemetry driver from
> >> probing if these resources are not in ACPI table. This patch
> >> decouples telemetry driver from these optional resources, so that
> >> telemetry driver has dependency only on the necessary ACPI resources.
> >>
> >> Signed-off-by: Aubrey Li 
> 
> >Given the impact to their recent contributions, I'm looking for reviews from
> Qipeng and Souvik before I merge this.
> 
> >Qipeng, as the listed maintainer for these two files, I particularly need to
> hear from you.
> 
> >Thanks,
> 
> Hi Darren,  I think this is a reasonable solution for such issue.
> Thanks Aubrey for this fixing patch.

We went over this internally once. So OK from my POV.

[PATCH v9 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Chanwoo Choi]

This patch adds the documentation for generic exynos bus frequency
driver.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: MyungJoo Ham 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 95 ++
 1 file changed, 95 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
new file mode 100644
index ..78171b918e3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -0,0 +1,95 @@
+* Generic Exynos Bus frequency device
+
+The Samsung Exynos SoC has many buses for data transfer between DRAM
+and sub-blocks in SoC. Most Exynos SoCs share the common architecture
+for buses. Generally, each bus of Exynos SoC includes a source clock
+and a power line, which are able to change the clock frequency
+of the bus in runtime. To monitor the usage of each bus in runtime,
+the driver uses the PPMU (Platform Performance Monitoring Unit), which
+is able to measure the current load of sub-blocks.
+
+There are a little different composition among Exynos SoC because each Exynos
+SoC has different sub-blocks. Therefore, shch difference should be specified
+in devicetree file instead of each device driver. In result, this driver
+is able to support the bus frequency for all Exynos SoCs.
+
+Required properties for bus device:
+- compatible: Should be "samsung,exynos-bus".
+- clock-names : the name of clock used by the bus, "bus".
+- clocks : phandles for clock specified in "clock-names" property.
+- operating-points-v2: the OPP table including frequency/voltage information
+  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- vdd-supply: the regulator to provide the buses with the voltage.
+- devfreq-events: the devfreq-event device to monitor the current utilization
+  of buses.
+
+Optional properties for bus device:
+- exynos,saturation-ratio: the percentage value which is used to calibrate
+   the performance count against total cycle count.
+- exynos,voltage-tolerance: the percentage value for bus voltage tolerance
+   which is used to calculate the max voltage.
+
+Example1:
+   Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
+   power line (regulator). The MIF (Memory Interface) AXI bus is used to
+   transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
+
+   - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+
+   - MIF bus's frequency/voltage table
+   ---
+   |Lv| Freq   | Voltage |
+   ---
+   |L1| 5  |80   |
+   |L2| 10 |80   |
+   |L3| 134000 |80   |
+   |L4| 20 |825000   |
+   |L5| 40 |875000   |
+   ---
+
+Example2 :
+   The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
+   is listed below:
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = <_dmc CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <80>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <80>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <80>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <825000>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <875000>;
+   };
+   };
+
+   Usage case to handle the frequency and voltage of bus on runtime
+   in exynos3250-rinato.dts is listed below:
+
+   _dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;  /* VDD_MIF */
+   status = "okay";
+   };
-- 
1.9.1

Re: [PATCH] scripts/gdb: Use $(abspath ...) instead of $(shell cd ... && pwd)

[Jan Kiszka]

On 2016-04-08 02:16, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Avoid forking off a shell to resolve the absolute path of the output
> directory when make's builtin $(abspath ...) function will do an
> adequate job.
> 
> Signed-off-by: Thierry Reding 
> ---
>  scripts/gdb/linux/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/gdb/linux/Makefile b/scripts/gdb/linux/Makefile
> index 6cf1ecf61057..d8b88e22e16a 100644
> --- a/scripts/gdb/linux/Makefile
> +++ b/scripts/gdb/linux/Makefile
> @@ -1,6 +1,6 @@
>  always := gdb-scripts
>  
> -SRCTREE := $(shell cd $(srctree) && /bin/pwd)
> +SRCTREE := $(abspath $(srctree))
>  
>  $(obj)/gdb-scripts:
>  ifneq ($(KBUILD_SRC),)
> 

Thanks, good cleanup. Queued.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

RE: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

[Chakravarty, Souvik K]

> -Original Message-
> From: Zha, Qipeng
> Sent: Monday, April 11, 2016 7:34 AM
> To: Darren Hart ; Aubrey Li
> ; Chakravarty, Souvik K
> 
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] platform:x86 decouple telemetry driver from the
> optional IPC resources
> 
> >> Currently the optional IPC resources prevent telemetry driver from
> >> probing if these resources are not in ACPI table. This patch
> >> decouples telemetry driver from these optional resources, so that
> >> telemetry driver has dependency only on the necessary ACPI resources.
> >>
> >> Signed-off-by: Aubrey Li 
> 
> >Given the impact to their recent contributions, I'm looking for reviews from
> Qipeng and Souvik before I merge this.
> 
> >Qipeng, as the listed maintainer for these two files, I particularly need to
> hear from you.
> 
> >Thanks,
> 
> Hi Darren,  I think this is a reasonable solution for such issue.
> Thanks Aubrey for this fixing patch.

We went over this internally once. So OK from my POV.

[PATCH v9 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver

[Chanwoo Choi]

This patch adds the documentation for generic exynos bus frequency
driver.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: MyungJoo Ham 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 95 ++
 1 file changed, 95 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
new file mode 100644
index ..78171b918e3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -0,0 +1,95 @@
+* Generic Exynos Bus frequency device
+
+The Samsung Exynos SoC has many buses for data transfer between DRAM
+and sub-blocks in SoC. Most Exynos SoCs share the common architecture
+for buses. Generally, each bus of Exynos SoC includes a source clock
+and a power line, which are able to change the clock frequency
+of the bus in runtime. To monitor the usage of each bus in runtime,
+the driver uses the PPMU (Platform Performance Monitoring Unit), which
+is able to measure the current load of sub-blocks.
+
+There are a little different composition among Exynos SoC because each Exynos
+SoC has different sub-blocks. Therefore, shch difference should be specified
+in devicetree file instead of each device driver. In result, this driver
+is able to support the bus frequency for all Exynos SoCs.
+
+Required properties for bus device:
+- compatible: Should be "samsung,exynos-bus".
+- clock-names : the name of clock used by the bus, "bus".
+- clocks : phandles for clock specified in "clock-names" property.
+- operating-points-v2: the OPP table including frequency/voltage information
+  to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- vdd-supply: the regulator to provide the buses with the voltage.
+- devfreq-events: the devfreq-event device to monitor the current utilization
+  of buses.
+
+Optional properties for bus device:
+- exynos,saturation-ratio: the percentage value which is used to calibrate
+   the performance count against total cycle count.
+- exynos,voltage-tolerance: the percentage value for bus voltage tolerance
+   which is used to calculate the max voltage.
+
+Example1:
+   Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
+   power line (regulator). The MIF (Memory Interface) AXI bus is used to
+   transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
+
+   - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+
+   - MIF bus's frequency/voltage table
+   ---
+   |Lv| Freq   | Voltage |
+   ---
+   |L1| 5  |80   |
+   |L2| 10 |80   |
+   |L3| 134000 |80   |
+   |L4| 20 |825000   |
+   |L5| 40 |875000   |
+   ---
+
+Example2 :
+   The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
+   is listed below:
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = <_dmc CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <80>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <80>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <80>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <825000>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <875000>;
+   };
+   };
+
+   Usage case to handle the frequency and voltage of bus on runtime
+   in exynos3250-rinato.dts is listed below:
+
+   _dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;  /* VDD_MIF */
+   status = "okay";
+   };
-- 
1.9.1

[PATCH v9 10/20] MAINTAINERS: Add samsung bus frequency driver entry

[Chanwoo Choi]

This patch adds the 'BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS' entry to review 
the
patches as maintainer. I can access the all datasheet of Exynos SoC and test it
on some Exynos-based board. Patches will be picked up by DEVFREQ maintainer
on devfreq git repository.

Signed-off-by: Chanwoo Choi 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c32f8a3d6c4..4cdef4d9ba29 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3539,6 +3539,15 @@ F:   drivers/devfreq/devfreq-event.c
 F: include/linux/devfreq-event.h
 F: Documentation/devicetree/bindings/devfreq/event/
 
+BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
+M: Chanwoo Choi 
+L: linux...@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
+S: Maintained
+F: drivers/devfreq/exynos-bus.c
+F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+
 DEVICE NUMBER REGISTRY
 M: Torben Mathiasen 
 W: http://lanana.org/docs/device-list/index.html
-- 
1.9.1

[PATCH v9 10/20] MAINTAINERS: Add samsung bus frequency driver entry

[Chanwoo Choi]

This patch adds the 'BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS' entry to review 
the
patches as maintainer. I can access the all datasheet of Exynos SoC and test it
on some Exynos-based board. Patches will be picked up by DEVFREQ maintainer
on devfreq git repository.

Signed-off-by: Chanwoo Choi 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c32f8a3d6c4..4cdef4d9ba29 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3539,6 +3539,15 @@ F:   drivers/devfreq/devfreq-event.c
 F: include/linux/devfreq-event.h
 F: Documentation/devicetree/bindings/devfreq/event/
 
+BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
+M: Chanwoo Choi 
+L: linux...@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
+S: Maintained
+F: drivers/devfreq/exynos-bus.c
+F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+
 DEVICE NUMBER REGISTRY
 M: Torben Mathiasen 
 W: http://lanana.org/docs/device-list/index.html
-- 
1.9.1

[PATCH v9 03/20] PM / devfreq: Add devfreq_get_devfreq_by_phandle()

[Chanwoo Choi]

This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
which can find the instance of devfreq device by using phandle ("devfreq").

Signed-off-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham 
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
---
 drivers/devfreq/devfreq.c | 44 
 include/linux/devfreq.h   |  9 +
 2 files changed, 53 insertions(+)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 984c5e9e7bdd..20a9422c2552 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "governor.h"
 
 static struct class *devfreq_class;
@@ -639,6 +640,49 @@ struct devfreq *devm_devfreq_add_device(struct device *dev,
 }
 EXPORT_SYMBOL(devm_devfreq_add_device);
 
+#ifdef CONFIG_OF
+/*
+ * devfreq_get_devfreq_by_phandle - Get the devfreq device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of devfreq
+ *
+ * return the instance of devfreq device
+ */
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+   struct device_node *node;
+   struct devfreq *devfreq;
+
+   if (!dev)
+   return ERR_PTR(-EINVAL);
+
+   if (!dev->of_node)
+   return ERR_PTR(-EINVAL);
+
+   node = of_parse_phandle(dev->of_node, "devfreq", index);
+   if (!node)
+   return ERR_PTR(-ENODEV);
+
+   mutex_lock(_list_lock);
+   list_for_each_entry(devfreq, _list, node) {
+   if (devfreq->dev.parent
+   && devfreq->dev.parent->of_node == node) {
+   mutex_unlock(_list_lock);
+   return devfreq;
+   }
+   }
+   mutex_unlock(_list_lock);
+
+   return ERR_PTR(-EPROBE_DEFER);
+}
+#else
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif /* CONFIG_OF */
+EXPORT_SYMBOL_GPL(devfreq_get_devfreq_by_phandle);
+
 /**
  * devm_devfreq_remove_device() - Resource-managed devfreq_remove_device()
  * @dev:   the device to add devfreq feature.
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 6fa02a20eb63..aa0b8424ebc3 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -208,6 +208,9 @@ extern int devm_devfreq_register_opp_notifier(struct device 
*dev,
 extern void devm_devfreq_unregister_opp_notifier(struct device *dev,
struct devfreq *devfreq);
 
+extern struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev,
+   int index);
+
 /**
  * devfreq_update_stats() - update the last_status pointer in struct devfreq
  * @df:the devfreq instance whose status needs updating
@@ -307,6 +310,12 @@ static inline void 
devm_devfreq_unregister_opp_notifier(struct device *dev,
 {
 }
 
+static inline struct devfreq *devfreq_get_devfreq_by_phandle(struct device 
*dev,
+   int index)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline int devfreq_update_stats(struct devfreq *df)
 {
return -EINVAL;
-- 
1.9.1

Re: [PATCH 4.4 153/210] scripts/gdb: account for changes in module data structure

[Jan Kiszka]

On 2016-04-10 11:36, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Jan Kiszka 
> 
> commit ad4db3b24a93e52a92ad8f9b0273a9416f202c23 upstream.
> 
> Commit 7523e4dc5057 ("module: use a structure to encapsulate layout.")
> factored out the module_layout structure.  Adjust the symbol loader and
> the lsmod command to this.

Unless the referenced commit is also in the 4.4 queue (seems unlikely,
though), this patch must not go to that stable branch as it only
addresses a 4.5 change. So please drop.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[PATCH v9 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[Chanwoo Choi]

This patch adds the generic exynos bus frequency driver for AMBA AXI bus
of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
have the common architecture for bus between DRAM and sub-blocks in SoC.
This driver can support the generic bus frequency driver for Exynos SoCs.

In devicetree, Each bus block has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.

Signed-off-by: Chanwoo Choi 
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
Signed-off-by: MyungJoo Ham 
---
 drivers/devfreq/Kconfig  |  15 ++
 drivers/devfreq/Makefile |   1 +
 drivers/devfreq/exynos-bus.c | 443 +++
 3 files changed, 459 insertions(+)
 create mode 100644 drivers/devfreq/exynos-bus.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 4de78c552251..cedda8f1e5eb 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
 
 comment "DEVFREQ Drivers"
 
+config ARM_EXYNOS_BUS_DEVFREQ
+   bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
+   depends on ARCH_EXYNOS
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select DEVFREQ_EVENT_EXYNOS_PPMU
+   select PM_DEVFREQ_EVENT
+   select PM_OPP
+   help
+ This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
+ Memory bus has one more group of memory bus (e.g, MIF and INT block).
+ Each memory bus group could contain many memoby bus block. It reads
+ PPMU counters of memory controllers by using DEVFREQ-event device
+ and adjusts the operating frequencies and voltages with OPP support.
+ This does not yet operate with optimal voltages.
+
 config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && 
!ARCH_MULTIPLATFORM
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 5134f9ee983d..8af8aaf922a8 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
 obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
 
 # DEVFREQ Drivers
+obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
 obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos/
 obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos/
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
new file mode 100644
index ..137de6196af3
--- /dev/null
+++ b/drivers/devfreq/exynos-bus.c
@@ -0,0 +1,443 @@
+/*
+ * Generic Exynos Bus frequency driver with DEVFREQ Framework
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi 
+ *
+ * This driver support Exynos Bus frequency feature by using
+ * DEVFREQ framework and is based on drivers/devfreq/exynos/exynos4_bus.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_SATURATION_RATIO   40
+#define DEFAULT_VOLTAGE_TOLERANCE  2
+
+struct exynos_bus {
+   struct device *dev;
+
+   struct devfreq *devfreq;
+   struct devfreq_event_dev **edev;
+   unsigned int edev_count;
+   struct mutex lock;
+
+   struct dev_pm_opp *curr_opp;
+
+   struct regulator *regulator;
+   struct clk *clk;
+   unsigned int voltage_tolerance;
+   unsigned int ratio;
+};
+
+/*
+ * Control the devfreq-event device to get the current state of bus
+ */
+#define exynos_bus_ops_edev(ops)   \
+static int exynos_bus_##ops(struct exynos_bus *bus)\
+{  \
+   int i, ret; \
+   \
+   for (i = 0; i < bus->edev_count; i++) { \
+   if (!bus->edev[i])  \
+   continue;   \
+   ret = devfreq_event_##ops(bus->edev[i]);\
+   if (ret < 0)\
+   return ret; \
+   }   \
+   \
+   return 0;   \
+}

Re: [PATCH 0/7] PM / devfreq: Add NoCP devfreq-event and support busfreq on exyno5422-odroidxu3

[Chanwoo Choi]

Hi Anand,

On 2016년 04월 11일 13:01, Anand Moon wrote:
> Hi Chanwoo,
> 
> On 11 April 2016 at 07:46, Chanwoo Choi  wrote:
>> Hi Anand,
>>
>> On 2016년 04월 09일 03:24, Chanwoo Choi wrote:
>>> Hi Anand,
>>>
>>> On Sat, Apr 9, 2016 at 3:11 AM, Anand Moon  wrote:
 Hi Chanwoo,

>>
>> [snip]
>>
>

 I am observing following deadlock. Both on Odroid U3 and Odroid XU4.
>>>
>>> Thanks for your test. I'll test it again and fix it.
>>
>> This possible recursive locking is fixed with following diff:
>>
>> Thanks for your report. I'll fix it on next patchset[1] (v9).
>> [1] https://lkml.org/lkml/2016/4/8/14
>>
>>
>> diff --git a/drivers/devfreq/governor_passive.c 
>> b/drivers/devfreq/governor_passive.c
>> index 28a9ae32d330..a4b0b02ee797 100644
>> --- a/drivers/devfreq/governor_passive.c
>> +++ b/drivers/devfreq/governor_passive.c
>> @@ -102,7 +102,7 @@ static int update_devfreq_passive(struct devfreq 
>> *devfreq, unsigned long freq)
>> if (!devfreq->governor)
>> return -EINVAL;
>>
>> -   mutex_lock(>lock);
>> +   mutex_lock_nested(>lock, SINGLE_DEPTH_NESTING);
>>
>> ret = devfreq->governor->get_target_freq(devfreq, );
>> if (ret < 0)
>>
>> Best Regards,
>> Chanwoo Choi
>>
> 
> Thanks you for these patches on devfreq.
> These changes fix the warning.
> 
> Tested-by: Anand Moon 
> 
> Tested on Odroid XU4 and Odroid U3.

Thanks for your test and report.

Best Regards,
Chanwoo Choi

[PATCH v9 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato

[Chanwoo Choi]

This patch adds the bus device-tree nodes of INT (internal) block
to enable the bus frequency scaling. The following sub-blocks share
the VDD_INT power source:
- LEFTBUS (parent device)
- RIGHTBUS
- PERIL
- LCD0
- FSYS
- MCUISP / ISP
- MFC

The LEFTBUS is parent device with devfreq ondemand governor
and the rest of devices depend on the LEFTBUS device.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 41 +
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 9710e79e10a0..09444897b416 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -154,6 +154,47 @@
status = "okay";
 };
 
+_leftbus {
+   devfreq-events = <_leftbus_3>, <_rightbus_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
+_rightbus {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_lcd0 {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_fsys {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_mcuisp {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_isp {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_peril {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_mfc {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
-- 
1.9.1

Re: [PATCH 0/7] PM / devfreq: Add NoCP devfreq-event and support busfreq on exyno5422-odroidxu3

[Anand Moon]

Hi Chanwoo,

On 11 April 2016 at 07:46, Chanwoo Choi  wrote:
> Hi Anand,
>
> On 2016년 04월 09일 03:24, Chanwoo Choi wrote:
>> Hi Anand,
>>
>> On Sat, Apr 9, 2016 at 3:11 AM, Anand Moon  wrote:
>>> Hi Chanwoo,
>>>
>
> [snip]
>

>>>
>>> I am observing following deadlock. Both on Odroid U3 and Odroid XU4.
>>
>> Thanks for your test. I'll test it again and fix it.
>
> This possible recursive locking is fixed with following diff:
>
> Thanks for your report. I'll fix it on next patchset[1] (v9).
> [1] https://lkml.org/lkml/2016/4/8/14
>
>
> diff --git a/drivers/devfreq/governor_passive.c 
> b/drivers/devfreq/governor_passive.c
> index 28a9ae32d330..a4b0b02ee797 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -102,7 +102,7 @@ static int update_devfreq_passive(struct devfreq 
> *devfreq, unsigned long freq)
> if (!devfreq->governor)
> return -EINVAL;
>
> -   mutex_lock(>lock);
> +   mutex_lock_nested(>lock, SINGLE_DEPTH_NESTING);
>
> ret = devfreq->governor->get_target_freq(devfreq, );
> if (ret < 0)
>
> Best Regards,
> Chanwoo Choi
>

Thanks you for these patches on devfreq.
These changes fix the warning.

Tested-by: Anand Moon 

Tested on Odroid XU4 and Odroid U3.

Best Regards
-Anand Moon

[PATCH v9 11/20] ARM: dts: Add DMC bus node for Exynos3250

[Chanwoo Choi]

This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 SoC.
The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
SDRAM devices. The bus includes the OPP tables and the source clock for DMC
block.

Following list specifies the detailed relation between the clock and DMC block:
- The source clock of DMC block : div_dmc

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: MyungJoo Ham 
---
 arch/arm/boot/dts/exynos3250.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 137f9015d4e8..1ae72c4fa55e 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -688,6 +688,40 @@
clock-names = "ppmu";
status = "disabled";
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = <_dmc CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <80>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <80>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <80>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <825000>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <875000>;
+   };
+   };
};
 };
 
-- 
1.9.1

[PATCH v9 03/20] PM / devfreq: Add devfreq_get_devfreq_by_phandle()

[Chanwoo Choi]

This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
which can find the instance of devfreq device by using phandle ("devfreq").

Signed-off-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham 
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
---
 drivers/devfreq/devfreq.c | 44 
 include/linux/devfreq.h   |  9 +
 2 files changed, 53 insertions(+)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 984c5e9e7bdd..20a9422c2552 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "governor.h"
 
 static struct class *devfreq_class;
@@ -639,6 +640,49 @@ struct devfreq *devm_devfreq_add_device(struct device *dev,
 }
 EXPORT_SYMBOL(devm_devfreq_add_device);
 
+#ifdef CONFIG_OF
+/*
+ * devfreq_get_devfreq_by_phandle - Get the devfreq device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of devfreq
+ *
+ * return the instance of devfreq device
+ */
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+   struct device_node *node;
+   struct devfreq *devfreq;
+
+   if (!dev)
+   return ERR_PTR(-EINVAL);
+
+   if (!dev->of_node)
+   return ERR_PTR(-EINVAL);
+
+   node = of_parse_phandle(dev->of_node, "devfreq", index);
+   if (!node)
+   return ERR_PTR(-ENODEV);
+
+   mutex_lock(_list_lock);
+   list_for_each_entry(devfreq, _list, node) {
+   if (devfreq->dev.parent
+   && devfreq->dev.parent->of_node == node) {
+   mutex_unlock(_list_lock);
+   return devfreq;
+   }
+   }
+   mutex_unlock(_list_lock);
+
+   return ERR_PTR(-EPROBE_DEFER);
+}
+#else
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif /* CONFIG_OF */
+EXPORT_SYMBOL_GPL(devfreq_get_devfreq_by_phandle);
+
 /**
  * devm_devfreq_remove_device() - Resource-managed devfreq_remove_device()
  * @dev:   the device to add devfreq feature.
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 6fa02a20eb63..aa0b8424ebc3 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -208,6 +208,9 @@ extern int devm_devfreq_register_opp_notifier(struct device 
*dev,
 extern void devm_devfreq_unregister_opp_notifier(struct device *dev,
struct devfreq *devfreq);
 
+extern struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev,
+   int index);
+
 /**
  * devfreq_update_stats() - update the last_status pointer in struct devfreq
  * @df:the devfreq instance whose status needs updating
@@ -307,6 +310,12 @@ static inline void 
devm_devfreq_unregister_opp_notifier(struct device *dev,
 {
 }
 
+static inline struct devfreq *devfreq_get_devfreq_by_phandle(struct device 
*dev,
+   int index)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline int devfreq_update_stats(struct devfreq *df)
 {
return -EINVAL;
-- 
1.9.1

Re: [PATCH 4.4 153/210] scripts/gdb: account for changes in module data structure

[Jan Kiszka]

On 2016-04-10 11:36, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Jan Kiszka 
> 
> commit ad4db3b24a93e52a92ad8f9b0273a9416f202c23 upstream.
> 
> Commit 7523e4dc5057 ("module: use a structure to encapsulate layout.")
> factored out the module_layout structure.  Adjust the symbol loader and
> the lsmod command to this.

Unless the referenced commit is also in the 4.4 queue (seems unlikely,
though), this patch must not go to that stable branch as it only
addresses a 4.5 change. So please drop.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[PATCH v9 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[Chanwoo Choi]

This patch adds the generic exynos bus frequency driver for AMBA AXI bus
of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
have the common architecture for bus between DRAM and sub-blocks in SoC.
This driver can support the generic bus frequency driver for Exynos SoCs.

In devicetree, Each bus block has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.

Signed-off-by: Chanwoo Choi 
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
Signed-off-by: MyungJoo Ham 
---
 drivers/devfreq/Kconfig  |  15 ++
 drivers/devfreq/Makefile |   1 +
 drivers/devfreq/exynos-bus.c | 443 +++
 3 files changed, 459 insertions(+)
 create mode 100644 drivers/devfreq/exynos-bus.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 4de78c552251..cedda8f1e5eb 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
 
 comment "DEVFREQ Drivers"
 
+config ARM_EXYNOS_BUS_DEVFREQ
+   bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
+   depends on ARCH_EXYNOS
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select DEVFREQ_EVENT_EXYNOS_PPMU
+   select PM_DEVFREQ_EVENT
+   select PM_OPP
+   help
+ This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
+ Memory bus has one more group of memory bus (e.g, MIF and INT block).
+ Each memory bus group could contain many memoby bus block. It reads
+ PPMU counters of memory controllers by using DEVFREQ-event device
+ and adjusts the operating frequencies and voltages with OPP support.
+ This does not yet operate with optimal voltages.
+
 config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && 
!ARCH_MULTIPLATFORM
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 5134f9ee983d..8af8aaf922a8 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
 obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
 
 # DEVFREQ Drivers
+obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
 obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos/
 obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos/
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
new file mode 100644
index ..137de6196af3
--- /dev/null
+++ b/drivers/devfreq/exynos-bus.c
@@ -0,0 +1,443 @@
+/*
+ * Generic Exynos Bus frequency driver with DEVFREQ Framework
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi 
+ *
+ * This driver support Exynos Bus frequency feature by using
+ * DEVFREQ framework and is based on drivers/devfreq/exynos/exynos4_bus.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_SATURATION_RATIO   40
+#define DEFAULT_VOLTAGE_TOLERANCE  2
+
+struct exynos_bus {
+   struct device *dev;
+
+   struct devfreq *devfreq;
+   struct devfreq_event_dev **edev;
+   unsigned int edev_count;
+   struct mutex lock;
+
+   struct dev_pm_opp *curr_opp;
+
+   struct regulator *regulator;
+   struct clk *clk;
+   unsigned int voltage_tolerance;
+   unsigned int ratio;
+};
+
+/*
+ * Control the devfreq-event device to get the current state of bus
+ */
+#define exynos_bus_ops_edev(ops)   \
+static int exynos_bus_##ops(struct exynos_bus *bus)\
+{  \
+   int i, ret; \
+   \
+   for (i = 0; i < bus->edev_count; i++) { \
+   if (!bus->edev[i])  \
+   continue;   \
+   ret = devfreq_event_##ops(bus->edev[i]);\
+   if (ret < 0)\
+   return ret; \
+   }   \
+   \
+   return 0;   \
+}
+exynos_bus_ops_edev(enable_edev);
+exynos_bus_ops_edev(disable_edev);
+exynos_bus_ops_edev(set_event);
+
+static int exynos_bus_get_event(struct 

Re: [PATCH 0/7] PM / devfreq: Add NoCP devfreq-event and support busfreq on exyno5422-odroidxu3

[Chanwoo Choi]

Hi Anand,

On 2016년 04월 11일 13:01, Anand Moon wrote:
> Hi Chanwoo,
> 
> On 11 April 2016 at 07:46, Chanwoo Choi  wrote:
>> Hi Anand,
>>
>> On 2016년 04월 09일 03:24, Chanwoo Choi wrote:
>>> Hi Anand,
>>>
>>> On Sat, Apr 9, 2016 at 3:11 AM, Anand Moon  wrote:
 Hi Chanwoo,

>>
>> [snip]
>>
>

 I am observing following deadlock. Both on Odroid U3 and Odroid XU4.
>>>
>>> Thanks for your test. I'll test it again and fix it.
>>
>> This possible recursive locking is fixed with following diff:
>>
>> Thanks for your report. I'll fix it on next patchset[1] (v9).
>> [1] https://lkml.org/lkml/2016/4/8/14
>>
>>
>> diff --git a/drivers/devfreq/governor_passive.c 
>> b/drivers/devfreq/governor_passive.c
>> index 28a9ae32d330..a4b0b02ee797 100644
>> --- a/drivers/devfreq/governor_passive.c
>> +++ b/drivers/devfreq/governor_passive.c
>> @@ -102,7 +102,7 @@ static int update_devfreq_passive(struct devfreq 
>> *devfreq, unsigned long freq)
>> if (!devfreq->governor)
>> return -EINVAL;
>>
>> -   mutex_lock(>lock);
>> +   mutex_lock_nested(>lock, SINGLE_DEPTH_NESTING);
>>
>> ret = devfreq->governor->get_target_freq(devfreq, );
>> if (ret < 0)
>>
>> Best Regards,
>> Chanwoo Choi
>>
> 
> Thanks you for these patches on devfreq.
> These changes fix the warning.
> 
> Tested-by: Anand Moon 
> 
> Tested on Odroid XU4 and Odroid U3.

Thanks for your test and report.

Best Regards,
Chanwoo Choi

[PATCH v9 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato

[Chanwoo Choi]

This patch adds the bus device-tree nodes of INT (internal) block
to enable the bus frequency scaling. The following sub-blocks share
the VDD_INT power source:
- LEFTBUS (parent device)
- RIGHTBUS
- PERIL
- LCD0
- FSYS
- MCUISP / ISP
- MFC

The LEFTBUS is parent device with devfreq ondemand governor
and the rest of devices depend on the LEFTBUS device.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 41 +
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 9710e79e10a0..09444897b416 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -154,6 +154,47 @@
status = "okay";
 };
 
+_leftbus {
+   devfreq-events = <_leftbus_3>, <_rightbus_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
+_rightbus {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_lcd0 {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_fsys {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_mcuisp {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_isp {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_peril {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
+_mfc {
+   devfreq = <_leftbus>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
-- 
1.9.1

Re: [PATCH 0/7] PM / devfreq: Add NoCP devfreq-event and support busfreq on exyno5422-odroidxu3

[Anand Moon]

Hi Chanwoo,

On 11 April 2016 at 07:46, Chanwoo Choi  wrote:
> Hi Anand,
>
> On 2016년 04월 09일 03:24, Chanwoo Choi wrote:
>> Hi Anand,
>>
>> On Sat, Apr 9, 2016 at 3:11 AM, Anand Moon  wrote:
>>> Hi Chanwoo,
>>>
>
> [snip]
>

>>>
>>> I am observing following deadlock. Both on Odroid U3 and Odroid XU4.
>>
>> Thanks for your test. I'll test it again and fix it.
>
> This possible recursive locking is fixed with following diff:
>
> Thanks for your report. I'll fix it on next patchset[1] (v9).
> [1] https://lkml.org/lkml/2016/4/8/14
>
>
> diff --git a/drivers/devfreq/governor_passive.c 
> b/drivers/devfreq/governor_passive.c
> index 28a9ae32d330..a4b0b02ee797 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -102,7 +102,7 @@ static int update_devfreq_passive(struct devfreq 
> *devfreq, unsigned long freq)
> if (!devfreq->governor)
> return -EINVAL;
>
> -   mutex_lock(>lock);
> +   mutex_lock_nested(>lock, SINGLE_DEPTH_NESTING);
>
> ret = devfreq->governor->get_target_freq(devfreq, );
> if (ret < 0)
>
> Best Regards,
> Chanwoo Choi
>

Thanks you for these patches on devfreq.
These changes fix the warning.

Tested-by: Anand Moon 

Tested on Odroid XU4 and Odroid U3.

Best Regards
-Anand Moon

[PATCH v9 11/20] ARM: dts: Add DMC bus node for Exynos3250

[Chanwoo Choi]

This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 SoC.
The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
SDRAM devices. The bus includes the OPP tables and the source clock for DMC
block.

Following list specifies the detailed relation between the clock and DMC block:
- The source clock of DMC block : div_dmc

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: MyungJoo Ham 
---
 arch/arm/boot/dts/exynos3250.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 137f9015d4e8..1ae72c4fa55e 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -688,6 +688,40 @@
clock-names = "ppmu";
status = "disabled";
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = <_dmc CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <80>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <80>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <80>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <825000>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <875000>;
+   };
+   };
};
 };
 
-- 
1.9.1

[PATCH v9 16/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4210

[Chanwoo Choi]

This patch adds the bus nodes for Exynos4210 SoC. Exynos4210 SoC has
one power line for all buses to translate data between DRAM and sub-blocks.

Following list specifies the detailed relation between DRAM and sub-blocks:
- DMC/ACP clock for DMC (Dynamic Memory Controller)
- ACLK200 clock for LCD0
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD0/LCD1
- ACLK133 clock for FSYS/GPS
- GDL/GDR clock for LEFTBUS/RIGHTBUS
- SCLK_MFC clock for MFC

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210.dtsi | 159 ++
 1 file changed, 159 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index c1cb8df6da07..2d9b02967105 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -257,6 +257,165 @@
power-domains = <_lcd1>;
#iommu-cells = <0>;
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_acp: bus_acp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACP>;
+   clock-names = "bus";
+   operating-points-v2 = <_acp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_peri: bus_peri {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK100>;
+   clock-names = "bus";
+   operating-points-v2 = <_peri_opp_table>;
+   status = "disabled";
+   };
+
+   bus_fsys: bus_fsys {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK133>;
+   clock-names = "bus";
+   operating-points-v2 = <_fsys_opp_table>;
+   status = "disabled";
+   };
+
+   bus_display: bus_display {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK160>;
+   clock-names = "bus";
+   operating-points-v2 = <_display_opp_table>;
+   status = "disabled";
+   };
+
+   bus_lcd0: bus_lcd0 {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK200>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_leftbus: bus_leftbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDL>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_rightbus: bus_rightbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDR>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mfc: bus_mfc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_SCLK_MFC>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <1025000>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <105>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <115>;
+   };
+   };
+
+   bus_acp_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   };
+   };
+
+   bus_peri_opp_table: opp_table3 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@500 {
+   opp-hz = /bits/ 64 <500>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   };
+   };
+
+   bus_fsys_opp_table: opp_table4 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1000 {
+   

[PATCH v9 12/20] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk

[Chanwoo Choi]

This patch adds the DMC (Dynamic Memory Controller) bus frequency node
which includes the devfreq-events and regulator properties. The bus
frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
with ondemand governor.

The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
the DMC block.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: MyungJoo Ham 
---
 arch/arm/boot/dts/exynos3250-monk.dts   | 6 ++
 arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index 9e2840b59ae8..1fd7ecb5c415 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -156,6 +156,12 @@
};
 };
 
+_dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 1f102f3a1ab1..5175bd7e015f 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -147,6 +147,12 @@
};
 };
 
+_dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
-- 
1.9.1

[PATCH v9 12/20] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk

[Chanwoo Choi]

This patch adds the DMC (Dynamic Memory Controller) bus frequency node
which includes the devfreq-events and regulator properties. The bus
frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
with ondemand governor.

The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
the DMC block.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: MyungJoo Ham 
---
 arch/arm/boot/dts/exynos3250-monk.dts   | 6 ++
 arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index 9e2840b59ae8..1fd7ecb5c415 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -156,6 +156,12 @@
};
 };
 
+_dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 1f102f3a1ab1..5175bd7e015f 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -147,6 +147,12 @@
};
 };
 
+_dmc {
+   devfreq-events = <_dmc0_3>, <_dmc1_3>;
+   vdd-supply = <_reg>;
+   status = "okay";
+};
+
  {
cpu0-supply = <_reg>;
 };
-- 
1.9.1

[PATCH v9 16/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4210

[Chanwoo Choi]

This patch adds the bus nodes for Exynos4210 SoC. Exynos4210 SoC has
one power line for all buses to translate data between DRAM and sub-blocks.

Following list specifies the detailed relation between DRAM and sub-blocks:
- DMC/ACP clock for DMC (Dynamic Memory Controller)
- ACLK200 clock for LCD0
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD0/LCD1
- ACLK133 clock for FSYS/GPS
- GDL/GDR clock for LEFTBUS/RIGHTBUS
- SCLK_MFC clock for MFC

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210.dtsi | 159 ++
 1 file changed, 159 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index c1cb8df6da07..2d9b02967105 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -257,6 +257,165 @@
power-domains = <_lcd1>;
#iommu-cells = <0>;
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_acp: bus_acp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACP>;
+   clock-names = "bus";
+   operating-points-v2 = <_acp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_peri: bus_peri {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK100>;
+   clock-names = "bus";
+   operating-points-v2 = <_peri_opp_table>;
+   status = "disabled";
+   };
+
+   bus_fsys: bus_fsys {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK133>;
+   clock-names = "bus";
+   operating-points-v2 = <_fsys_opp_table>;
+   status = "disabled";
+   };
+
+   bus_display: bus_display {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK160>;
+   clock-names = "bus";
+   operating-points-v2 = <_display_opp_table>;
+   status = "disabled";
+   };
+
+   bus_lcd0: bus_lcd0 {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK200>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_leftbus: bus_leftbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDL>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_rightbus: bus_rightbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDR>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mfc: bus_mfc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_SCLK_MFC>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <1025000>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <105>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <115>;
+   };
+   };
+
+   bus_acp_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   };
+   };
+
+   bus_peri_opp_table: opp_table3 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@500 {
+   opp-hz = /bits/ 64 <500>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   };
+   };
+
+   bus_fsys_opp_table: opp_table4 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1000 {
+   opp-hz = /bits/ 64 

[PATCH v9 04/20] PM / devfreq: Add new DEVFREQ_TRANSITION_NOTIFIER notifier

[Chanwoo Choi]

This patch adds the new DEVFREQ_TRANSITION_NOTIFIER notifier to send
the notification when the frequency of device is changed.
This notifier has two state as following:
- DEVFREQ_PRECHANGE  : Notify it before chaning the frequency of device
- DEVFREQ_POSTCHANGE : Notify it after changed the frequency of device

And this patch adds the resourced-managed function to release the resource
automatically when error happen.

Signed-off-by: Chanwoo Choi 
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
Signed-off-by: MyungJoo Ham 
---
 drivers/devfreq/devfreq.c | 163 +-
 include/linux/devfreq.h   |  59 -
 2 files changed, 220 insertions(+), 2 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 20a9422c2552..1d6c803804d5 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -189,6 +189,29 @@ static struct devfreq_governor 
*find_devfreq_governor(const char *name)
return ERR_PTR(-ENODEV);
 }
 
+static int devfreq_notify_transition(struct devfreq *devfreq,
+   struct devfreq_freqs *freqs, unsigned int state)
+{
+   if (!devfreq)
+   return -EINVAL;
+
+   switch (state) {
+   case DEVFREQ_PRECHANGE:
+   srcu_notifier_call_chain(>transition_notifier_list,
+   DEVFREQ_PRECHANGE, freqs);
+   break;
+
+   case DEVFREQ_POSTCHANGE:
+   srcu_notifier_call_chain(>transition_notifier_list,
+   DEVFREQ_POSTCHANGE, freqs);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /* Load monitoring helper functions for governors use */
 
 /**
@@ -200,7 +223,8 @@ static struct devfreq_governor *find_devfreq_governor(const 
char *name)
  */
 int update_devfreq(struct devfreq *devfreq)
 {
-   unsigned long freq;
+   struct devfreq_freqs freqs;
+   unsigned long freq, cur_freq;
int err = 0;
u32 flags = 0;
 
@@ -234,10 +258,22 @@ int update_devfreq(struct devfreq *devfreq)
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}
 
+   if (devfreq->profile->get_cur_freq)
+   devfreq->profile->get_cur_freq(devfreq->dev.parent, _freq);
+   else
+   cur_freq = devfreq->previous_freq;
+
+   freqs.old = cur_freq;
+   freqs.new = freq;
+   devfreq_notify_transition(devfreq, , DEVFREQ_PRECHANGE);
+
err = devfreq->profile->target(devfreq->dev.parent, , flags);
if (err)
return err;
 
+   freqs.new = freq;
+   devfreq_notify_transition(devfreq, , DEVFREQ_POSTCHANGE);
+
if (devfreq->profile->freq_table)
if (devfreq_update_status(devfreq, freq))
dev_err(>dev,
@@ -542,6 +578,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
goto err_out;
}
 
+   srcu_init_notifier_head(>transition_notifier_list);
+
mutex_unlock(>lock);
 
mutex_lock(_list_lock);
@@ -1310,6 +1348,129 @@ void devm_devfreq_unregister_opp_notifier(struct device 
*dev,
 }
 EXPORT_SYMBOL(devm_devfreq_unregister_opp_notifier);
 
+/**
+ * devfreq_register_notifier() - Register a driver with devfreq
+ * @devfreq:   The devfreq object.
+ * @nb:The notifier block to register.
+ * @list:  DEVFREQ_TRANSITION_NOTIFIER.
+ */
+int devfreq_register_notifier(struct devfreq *devfreq,
+   struct notifier_block *nb,
+   unsigned int list)
+{
+   int ret = 0;
+
+   if (!devfreq)
+   return -EINVAL;
+
+   switch (list) {
+   case DEVFREQ_TRANSITION_NOTIFIER:
+   ret = srcu_notifier_chain_register(
+   >transition_notifier_list, nb);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(devfreq_register_notifier);
+
+/*
+ * devfreq_unregister_notifier() - Unregister a driver with devfreq
+ * @devfreq:   The devfreq object.
+ * @nb:The notifier block to be unregistered.
+ * @list:  DEVFREQ_TRANSITION_NOTIFIER.
+ */
+int devfreq_unregister_notifier(struct devfreq *devfreq,
+   struct notifier_block *nb,
+   unsigned int list)
+{
+   int ret = 0;
+
+   if (!devfreq)
+   return -EINVAL;
+
+   switch (list) {
+   case DEVFREQ_TRANSITION_NOTIFIER:
+   ret = srcu_notifier_chain_unregister(
+   >transition_notifier_list, nb);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+
+   return ret;
+}

[PATCH v9 04/20] PM / devfreq: Add new DEVFREQ_TRANSITION_NOTIFIER notifier

[Chanwoo Choi]

This patch adds the new DEVFREQ_TRANSITION_NOTIFIER notifier to send
the notification when the frequency of device is changed.
This notifier has two state as following:
- DEVFREQ_PRECHANGE  : Notify it before chaning the frequency of device
- DEVFREQ_POSTCHANGE : Notify it after changed the frequency of device

And this patch adds the resourced-managed function to release the resource
automatically when error happen.

Signed-off-by: Chanwoo Choi 
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
Signed-off-by: MyungJoo Ham 
---
 drivers/devfreq/devfreq.c | 163 +-
 include/linux/devfreq.h   |  59 -
 2 files changed, 220 insertions(+), 2 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 20a9422c2552..1d6c803804d5 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -189,6 +189,29 @@ static struct devfreq_governor 
*find_devfreq_governor(const char *name)
return ERR_PTR(-ENODEV);
 }
 
+static int devfreq_notify_transition(struct devfreq *devfreq,
+   struct devfreq_freqs *freqs, unsigned int state)
+{
+   if (!devfreq)
+   return -EINVAL;
+
+   switch (state) {
+   case DEVFREQ_PRECHANGE:
+   srcu_notifier_call_chain(>transition_notifier_list,
+   DEVFREQ_PRECHANGE, freqs);
+   break;
+
+   case DEVFREQ_POSTCHANGE:
+   srcu_notifier_call_chain(>transition_notifier_list,
+   DEVFREQ_POSTCHANGE, freqs);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /* Load monitoring helper functions for governors use */
 
 /**
@@ -200,7 +223,8 @@ static struct devfreq_governor *find_devfreq_governor(const 
char *name)
  */
 int update_devfreq(struct devfreq *devfreq)
 {
-   unsigned long freq;
+   struct devfreq_freqs freqs;
+   unsigned long freq, cur_freq;
int err = 0;
u32 flags = 0;
 
@@ -234,10 +258,22 @@ int update_devfreq(struct devfreq *devfreq)
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}
 
+   if (devfreq->profile->get_cur_freq)
+   devfreq->profile->get_cur_freq(devfreq->dev.parent, _freq);
+   else
+   cur_freq = devfreq->previous_freq;
+
+   freqs.old = cur_freq;
+   freqs.new = freq;
+   devfreq_notify_transition(devfreq, , DEVFREQ_PRECHANGE);
+
err = devfreq->profile->target(devfreq->dev.parent, , flags);
if (err)
return err;
 
+   freqs.new = freq;
+   devfreq_notify_transition(devfreq, , DEVFREQ_POSTCHANGE);
+
if (devfreq->profile->freq_table)
if (devfreq_update_status(devfreq, freq))
dev_err(>dev,
@@ -542,6 +578,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
goto err_out;
}
 
+   srcu_init_notifier_head(>transition_notifier_list);
+
mutex_unlock(>lock);
 
mutex_lock(_list_lock);
@@ -1310,6 +1348,129 @@ void devm_devfreq_unregister_opp_notifier(struct device 
*dev,
 }
 EXPORT_SYMBOL(devm_devfreq_unregister_opp_notifier);
 
+/**
+ * devfreq_register_notifier() - Register a driver with devfreq
+ * @devfreq:   The devfreq object.
+ * @nb:The notifier block to register.
+ * @list:  DEVFREQ_TRANSITION_NOTIFIER.
+ */
+int devfreq_register_notifier(struct devfreq *devfreq,
+   struct notifier_block *nb,
+   unsigned int list)
+{
+   int ret = 0;
+
+   if (!devfreq)
+   return -EINVAL;
+
+   switch (list) {
+   case DEVFREQ_TRANSITION_NOTIFIER:
+   ret = srcu_notifier_chain_register(
+   >transition_notifier_list, nb);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(devfreq_register_notifier);
+
+/*
+ * devfreq_unregister_notifier() - Unregister a driver with devfreq
+ * @devfreq:   The devfreq object.
+ * @nb:The notifier block to be unregistered.
+ * @list:  DEVFREQ_TRANSITION_NOTIFIER.
+ */
+int devfreq_unregister_notifier(struct devfreq *devfreq,
+   struct notifier_block *nb,
+   unsigned int list)
+{
+   int ret = 0;
+
+   if (!devfreq)
+   return -EINVAL;
+
+   switch (list) {
+   case DEVFREQ_TRANSITION_NOTIFIER:
+   ret = srcu_notifier_chain_unregister(
+   >transition_notifier_list, nb);
+   break;
+   default:
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(devfreq_unregister_notifier);
+
+struct devfreq_notifier_devres {
+   struct devfreq *devfreq;
+   struct 

[PATCH v9 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Chanwoo Choi]

This patch-set includes the two features as following. The generic exynos bus
frequency driver is able to support almost Exynos SoCs for bus frequency
scaling. And the new passive governor is able to make the dependency on
between devices for frequency/voltage scaling. I had posted the patch-set[1]
with the similiar concept. This is is revised version for exynos bus frequency.
- Generic exynos bus frequency driver
- New passive governor of DEVFREQ framework
[1] https://lkml.org/lkml/2015/1/7/872
: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver

Changes from v8:
(https://lkml.org/lkml/2016/4/8/14)
- Fix possible recursive locking issue by using mutex_lock_nested()

Changes from v7:
(https://lkml.org/lkml/2016/3/31/308)
- Use IS_ERR() instead of IS_ERR_OR_NULL() macro
- Add signed-off-by/acked-by tag of DEVFREQ maintainer
- Fix the comment in governor_passive.c

Changes from v6:
(https://lkml.org/lkml/2016/3/27/187)
- Patch1/2 add signed-off-by tag from DEVFREQ Maintainer (Myungjoo Ham)
- Drop patch5 (PM / devfreq: Add governer type with unique number)
- Add missing description about the transition_notifier_list in struct devfreq
- Remove the passive governor code from devfreq.c core driver. Instead, passive
  governor uses the DEVFREQ_GOV_START/STOP signal to register/unregister the
  DEVFREQ_TRANSITION_NOTIFIER between the parent devfreq device and passive
  devfreq device.
- Add the author (myungjoo@samsung.com) of passive governor 
- Add 'struct devfreq_passive_data' to pass the devfreq instance of parent.

Changes from v5:
(https://lkml.org/lkml/2016/3/24/5)
- Rebase the patch-set on Linux v4.6-rc1
- Add Tested-by tag from Markus Reichl 
- Add Tested-by tag from Anand Moon 

Changes from v4:
(https://lkml.org/lkml/2015/12/14/43)
- Add new DEVFREQ_TRANSITION_NOTIFIER notifier. The passive
  devfreq device recevie the changed frequency of parent
  devfreq device through DEVFREQ_TRANSITION_NOTIFIER.
- Add governor type to identify thme using the defined constant
- Modify the passive governor using the DEVFREQ_TRANSITION_NOTIFIER notifier.
- Fix the RCU locking probrlm (Reported-by: Tobias Jakobi)
- Fix the debugfs error during the kernel booting (Reported-by: Tobias Jakobi)
- The Device Tree patches have got Reviewed-by tag from Exynos SoC Maintainer
  (Krzysztof Kozlowski )

Changes from v3:
(https://lkml.org/lkml/2015/12/11/75)
- Add the reviewed-by tag from Krzysztof Kozlowski (patch2/3/13/14/15/16/17)
- Fix typo of the description on patch14
- Modify the subject and description of patch17
- Reorder the 'bus_xxx' device tree node alphabetically in 
  both exynos3250-rinato/monk.dts and exynos4412-trats/odroidu3

Changes from v2:
(https://lkml.org/lkml/2015/12/8/869)
- Fix typo on documentation
- Modify the more appropriate sentence on patch description
- Add the detailed description about both parent and passive bus device
- Modify the DMC frequency for Exynos4x12 DMC bus (200MHz -> 267MHz)
- Modify the voltage of 200MHz was included in Exynos3250 DMC bus (800mV -> 
825mV)
- Rename OPP nodes as 'opp@'
- Delete the duplicate 'opp-microvolt' property of passive devfreq device
- Reorder the 'bus_xxx' device tree node alphabetically in 
exynos3250-rinato/monk.dts
- Reorder the 'bus_xxx' device tree node alphabetically in 
exynos4412-trats/odroidu3
- Add new exynos4412-ppmu-common.dtsi to remove the duplicate PPMU dt node
  on rinato/monk/trats2/odroid-u3 board
- Add the log message if bus device is registered to devfreq framework 
successfully
- Add the reviewed-by tag from Krzysztof Kozlowski
- Add the tested-by tag from Anand Moon on Odroid U3
- Add 'SAMSUNG BUS FREQUENCY DRIVER' entry to MAINTAINERS

Changes from v1:
(https://lkml.org/lkml/2015/11/26/260)
- Check whether the instance of regulator is NULL or not
  when executing regulator_disable() because of only parent
  devfreq device has the regulator instance. After fixing it,
  the wake-up from suspend state is well working. (patch1)
- Fix bug which checks 'bus-clk' instead of 'bus->regulator'
  after calling devm_clk_get() (on patch1)
- Update the documentation to remove the description about
  DEVFREQ-EVENT subsystem (on patch2)
- Add the full name of DMC (Dynamic Memory Controller) (on patch2)
- Modify the detailed correlation of buses for Exynos3250
  on documentation (patch2)
- Add the MFC bus node for Exynos3250 (on patch11, patch12)
- Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
- Add the PPMU node for exynos4412-odroidu3
- Add the support of bus frequency for exynos4412-odroidu3


[Description]
Detailed descirption for patch-set:
1. Add generic exynos bus frequency driver
: This patch-set adds the generic exynos bus frequency driver for AXI bus
of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
architecture for bus between DRAM and sub-blocks in SoC.

 There are the different buses according to Exynos SoC 

[PATCH v9 13/20] ARM: dts: Add bus nodes using VDD_INT for Exynos3250

[Chanwoo Choi]

This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
Exynos3250 has following AXI buses to translate data between
DRAM and sub-blocks.

Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK400 clock for MCUISP
- ACLK266 clock for ISP
- ACLK200 clock for FSYS
- ACLK160 clock for LCD0
- ACLK100 clock for PERIL
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250.dtsi | 147 ++
 1 file changed, 147 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 1ae72c4fa55e..b5157492a422 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -722,6 +722,153 @@
opp-microvolt = <875000>;
};
};
+
+   bus_leftbus: bus_leftbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDL>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_rightbus: bus_rightbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDR>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_lcd0: bus_lcd0 {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_160>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_fsys: bus_fsys {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_200>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mcuisp: bus_mcuisp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_400_MCUISP>;
+   clock-names = "bus";
+   operating-points-v2 = <_mcuisp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_isp: bus_isp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_266>;
+   clock-names = "bus";
+   operating-points-v2 = <_isp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_peril: bus_peril {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_100>;
+   clock-names = "bus";
+   operating-points-v2 = <_peril_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mfc: bus_mfc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_SCLK_MFC>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_leftbus_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <90>;
+   };
+   opp@8000 {
+   opp-hz = /bits/ 64 <8000>;
+   opp-microvolt = <90>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <100>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <100>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <100>;
+   };
+   };
+
+   bus_mcuisp_opp_table: opp_table3 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+  

[PATCH v9 13/20] ARM: dts: Add bus nodes using VDD_INT for Exynos3250

[Chanwoo Choi]

This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
Exynos3250 has following AXI buses to translate data between
DRAM and sub-blocks.

Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK400 clock for MCUISP
- ACLK266 clock for ISP
- ACLK200 clock for FSYS
- ACLK160 clock for LCD0
- ACLK100 clock for PERIL
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250.dtsi | 147 ++
 1 file changed, 147 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 1ae72c4fa55e..b5157492a422 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -722,6 +722,153 @@
opp-microvolt = <875000>;
};
};
+
+   bus_leftbus: bus_leftbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDL>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_rightbus: bus_rightbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDR>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_lcd0: bus_lcd0 {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_160>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_fsys: bus_fsys {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_200>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mcuisp: bus_mcuisp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_400_MCUISP>;
+   clock-names = "bus";
+   operating-points-v2 = <_mcuisp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_isp: bus_isp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_266>;
+   clock-names = "bus";
+   operating-points-v2 = <_isp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_peril: bus_peril {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACLK_100>;
+   clock-names = "bus";
+   operating-points-v2 = <_peril_opp_table>;
+   status = "disabled";
+   };
+
+   bus_mfc: bus_mfc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_SCLK_MFC>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   status = "disabled";
+   };
+
+   bus_leftbus_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   opp-microvolt = <90>;
+   };
+   opp@8000 {
+   opp-hz = /bits/ 64 <8000>;
+   opp-microvolt = <90>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <100>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <100>;
+   };
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <100>;
+   };
+   };
+
+   bus_mcuisp_opp_table: opp_table3 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   };
+   

[PATCH v9 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Chanwoo Choi]

This patch-set includes the two features as following. The generic exynos bus
frequency driver is able to support almost Exynos SoCs for bus frequency
scaling. And the new passive governor is able to make the dependency on
between devices for frequency/voltage scaling. I had posted the patch-set[1]
with the similiar concept. This is is revised version for exynos bus frequency.
- Generic exynos bus frequency driver
- New passive governor of DEVFREQ framework
[1] https://lkml.org/lkml/2015/1/7/872
: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver

Changes from v8:
(https://lkml.org/lkml/2016/4/8/14)
- Fix possible recursive locking issue by using mutex_lock_nested()

Changes from v7:
(https://lkml.org/lkml/2016/3/31/308)
- Use IS_ERR() instead of IS_ERR_OR_NULL() macro
- Add signed-off-by/acked-by tag of DEVFREQ maintainer
- Fix the comment in governor_passive.c

Changes from v6:
(https://lkml.org/lkml/2016/3/27/187)
- Patch1/2 add signed-off-by tag from DEVFREQ Maintainer (Myungjoo Ham)
- Drop patch5 (PM / devfreq: Add governer type with unique number)
- Add missing description about the transition_notifier_list in struct devfreq
- Remove the passive governor code from devfreq.c core driver. Instead, passive
  governor uses the DEVFREQ_GOV_START/STOP signal to register/unregister the
  DEVFREQ_TRANSITION_NOTIFIER between the parent devfreq device and passive
  devfreq device.
- Add the author (myungjoo@samsung.com) of passive governor 
- Add 'struct devfreq_passive_data' to pass the devfreq instance of parent.

Changes from v5:
(https://lkml.org/lkml/2016/3/24/5)
- Rebase the patch-set on Linux v4.6-rc1
- Add Tested-by tag from Markus Reichl 
- Add Tested-by tag from Anand Moon 

Changes from v4:
(https://lkml.org/lkml/2015/12/14/43)
- Add new DEVFREQ_TRANSITION_NOTIFIER notifier. The passive
  devfreq device recevie the changed frequency of parent
  devfreq device through DEVFREQ_TRANSITION_NOTIFIER.
- Add governor type to identify thme using the defined constant
- Modify the passive governor using the DEVFREQ_TRANSITION_NOTIFIER notifier.
- Fix the RCU locking probrlm (Reported-by: Tobias Jakobi)
- Fix the debugfs error during the kernel booting (Reported-by: Tobias Jakobi)
- The Device Tree patches have got Reviewed-by tag from Exynos SoC Maintainer
  (Krzysztof Kozlowski )

Changes from v3:
(https://lkml.org/lkml/2015/12/11/75)
- Add the reviewed-by tag from Krzysztof Kozlowski (patch2/3/13/14/15/16/17)
- Fix typo of the description on patch14
- Modify the subject and description of patch17
- Reorder the 'bus_xxx' device tree node alphabetically in 
  both exynos3250-rinato/monk.dts and exynos4412-trats/odroidu3

Changes from v2:
(https://lkml.org/lkml/2015/12/8/869)
- Fix typo on documentation
- Modify the more appropriate sentence on patch description
- Add the detailed description about both parent and passive bus device
- Modify the DMC frequency for Exynos4x12 DMC bus (200MHz -> 267MHz)
- Modify the voltage of 200MHz was included in Exynos3250 DMC bus (800mV -> 
825mV)
- Rename OPP nodes as 'opp@'
- Delete the duplicate 'opp-microvolt' property of passive devfreq device
- Reorder the 'bus_xxx' device tree node alphabetically in 
exynos3250-rinato/monk.dts
- Reorder the 'bus_xxx' device tree node alphabetically in 
exynos4412-trats/odroidu3
- Add new exynos4412-ppmu-common.dtsi to remove the duplicate PPMU dt node
  on rinato/monk/trats2/odroid-u3 board
- Add the log message if bus device is registered to devfreq framework 
successfully
- Add the reviewed-by tag from Krzysztof Kozlowski
- Add the tested-by tag from Anand Moon on Odroid U3
- Add 'SAMSUNG BUS FREQUENCY DRIVER' entry to MAINTAINERS

Changes from v1:
(https://lkml.org/lkml/2015/11/26/260)
- Check whether the instance of regulator is NULL or not
  when executing regulator_disable() because of only parent
  devfreq device has the regulator instance. After fixing it,
  the wake-up from suspend state is well working. (patch1)
- Fix bug which checks 'bus-clk' instead of 'bus->regulator'
  after calling devm_clk_get() (on patch1)
- Update the documentation to remove the description about
  DEVFREQ-EVENT subsystem (on patch2)
- Add the full name of DMC (Dynamic Memory Controller) (on patch2)
- Modify the detailed correlation of buses for Exynos3250
  on documentation (patch2)
- Add the MFC bus node for Exynos3250 (on patch11, patch12)
- Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
- Add the PPMU node for exynos4412-odroidu3
- Add the support of bus frequency for exynos4412-odroidu3


[Description]
Detailed descirption for patch-set:
1. Add generic exynos bus frequency driver
: This patch-set adds the generic exynos bus frequency driver for AXI bus
of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
architecture for bus between DRAM and sub-blocks in SoC.

 There are the different buses according to Exynos SoC because Exynos SoC
has the differnt sub-blocks and bus speed. In spite of 

Re: [PATCH v9 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Chanwoo Choi]

Dear Myungjoo and Krzysztof,

This patch-set already get the acked-by or signed-off-by tag
from Exynos SoC and DEVFREQ maintainer except for patch10.

If there is no comment, could you pick this patch-set?

Best Regards,
Chanwoo Choi


On 2016년 04월 11일 12:57, Chanwoo Choi wrote:
> This patch-set includes the two features as following. The generic exynos bus
> frequency driver is able to support almost Exynos SoCs for bus frequency
> scaling. And the new passive governor is able to make the dependency on
> between devices for frequency/voltage scaling. I had posted the patch-set[1]
> with the similiar concept. This is is revised version for exynos bus 
> frequency.
> - Generic exynos bus frequency driver
> - New passive governor of DEVFREQ framework
> [1] https://lkml.org/lkml/2015/1/7/872
> : [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
> 
> Changes from v8:
> (https://lkml.org/lkml/2016/4/8/14)
> - Fix possible recursive locking issue by using mutex_lock_nested()
> 
> Changes from v7:
> (https://lkml.org/lkml/2016/3/31/308)
> - Use IS_ERR() instead of IS_ERR_OR_NULL() macro
> - Add signed-off-by/acked-by tag of DEVFREQ maintainer
> - Fix the comment in governor_passive.c
> 
> Changes from v6:
> (https://lkml.org/lkml/2016/3/27/187)
> - Patch1/2 add signed-off-by tag from DEVFREQ Maintainer (Myungjoo Ham)
> - Drop patch5 (PM / devfreq: Add governer type with unique number)
> - Add missing description about the transition_notifier_list in struct devfreq
> - Remove the passive governor code from devfreq.c core driver. Instead, 
> passive
>   governor uses the DEVFREQ_GOV_START/STOP signal to register/unregister the
>   DEVFREQ_TRANSITION_NOTIFIER between the parent devfreq device and passive
>   devfreq device.
> - Add the author (myungjoo@samsung.com) of passive governor 
> - Add 'struct devfreq_passive_data' to pass the devfreq instance of parent.
> 
> Changes from v5:
> (https://lkml.org/lkml/2016/3/24/5)
> - Rebase the patch-set on Linux v4.6-rc1
> - Add Tested-by tag from Markus Reichl 
> - Add Tested-by tag from Anand Moon 
> 
> Changes from v4:
> (https://lkml.org/lkml/2015/12/14/43)
> - Add new DEVFREQ_TRANSITION_NOTIFIER notifier. The passive
>   devfreq device recevie the changed frequency of parent
>   devfreq device through DEVFREQ_TRANSITION_NOTIFIER.
> - Add governor type to identify thme using the defined constant
> - Modify the passive governor using the DEVFREQ_TRANSITION_NOTIFIER notifier.
> - Fix the RCU locking probrlm (Reported-by: Tobias Jakobi)
> - Fix the debugfs error during the kernel booting (Reported-by: Tobias Jakobi)
> - The Device Tree patches have got Reviewed-by tag from Exynos SoC Maintainer
>   (Krzysztof Kozlowski )
> 
> Changes from v3:
> (https://lkml.org/lkml/2015/12/11/75)
> - Add the reviewed-by tag from Krzysztof Kozlowski (patch2/3/13/14/15/16/17)
> - Fix typo of the description on patch14
> - Modify the subject and description of patch17
> - Reorder the 'bus_xxx' device tree node alphabetically in 
>   both exynos3250-rinato/monk.dts and exynos4412-trats/odroidu3
> 
> Changes from v2:
> (https://lkml.org/lkml/2015/12/8/869)
> - Fix typo on documentation
> - Modify the more appropriate sentence on patch description
> - Add the detailed description about both parent and passive bus device
> - Modify the DMC frequency for Exynos4x12 DMC bus (200MHz -> 267MHz)
> - Modify the voltage of 200MHz was included in Exynos3250 DMC bus (800mV -> 
> 825mV)
> - Rename OPP nodes as 'opp@'
> - Delete the duplicate 'opp-microvolt' property of passive devfreq device
> - Reorder the 'bus_xxx' device tree node alphabetically in 
> exynos3250-rinato/monk.dts
> - Reorder the 'bus_xxx' device tree node alphabetically in 
> exynos4412-trats/odroidu3
> - Add new exynos4412-ppmu-common.dtsi to remove the duplicate PPMU dt node
>   on rinato/monk/trats2/odroid-u3 board
> - Add the log message if bus device is registered to devfreq framework 
> successfully
> - Add the reviewed-by tag from Krzysztof Kozlowski
> - Add the tested-by tag from Anand Moon on Odroid U3
> - Add 'SAMSUNG BUS FREQUENCY DRIVER' entry to MAINTAINERS
> 
> Changes from v1:
> (https://lkml.org/lkml/2015/11/26/260)
> - Check whether the instance of regulator is NULL or not
>   when executing regulator_disable() because of only parent
>   devfreq device has the regulator instance. After fixing it,
>   the wake-up from suspend state is well working. (patch1)
> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>   after calling devm_clk_get() (on patch1)
> - Update the documentation to remove the description about
>   DEVFREQ-EVENT subsystem (on patch2)
> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
> - Modify the detailed correlation of buses for Exynos3250
>   on documentation (patch2)
> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
> - Fix the duplicate frequency of bus_display 

Re: [PATCH v9 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

[Chanwoo Choi]

Dear Myungjoo and Krzysztof,

This patch-set already get the acked-by or signed-off-by tag
from Exynos SoC and DEVFREQ maintainer except for patch10.

If there is no comment, could you pick this patch-set?

Best Regards,
Chanwoo Choi


On 2016년 04월 11일 12:57, Chanwoo Choi wrote:
> This patch-set includes the two features as following. The generic exynos bus
> frequency driver is able to support almost Exynos SoCs for bus frequency
> scaling. And the new passive governor is able to make the dependency on
> between devices for frequency/voltage scaling. I had posted the patch-set[1]
> with the similiar concept. This is is revised version for exynos bus 
> frequency.
> - Generic exynos bus frequency driver
> - New passive governor of DEVFREQ framework
> [1] https://lkml.org/lkml/2015/1/7/872
> : [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
> 
> Changes from v8:
> (https://lkml.org/lkml/2016/4/8/14)
> - Fix possible recursive locking issue by using mutex_lock_nested()
> 
> Changes from v7:
> (https://lkml.org/lkml/2016/3/31/308)
> - Use IS_ERR() instead of IS_ERR_OR_NULL() macro
> - Add signed-off-by/acked-by tag of DEVFREQ maintainer
> - Fix the comment in governor_passive.c
> 
> Changes from v6:
> (https://lkml.org/lkml/2016/3/27/187)
> - Patch1/2 add signed-off-by tag from DEVFREQ Maintainer (Myungjoo Ham)
> - Drop patch5 (PM / devfreq: Add governer type with unique number)
> - Add missing description about the transition_notifier_list in struct devfreq
> - Remove the passive governor code from devfreq.c core driver. Instead, 
> passive
>   governor uses the DEVFREQ_GOV_START/STOP signal to register/unregister the
>   DEVFREQ_TRANSITION_NOTIFIER between the parent devfreq device and passive
>   devfreq device.
> - Add the author (myungjoo@samsung.com) of passive governor 
> - Add 'struct devfreq_passive_data' to pass the devfreq instance of parent.
> 
> Changes from v5:
> (https://lkml.org/lkml/2016/3/24/5)
> - Rebase the patch-set on Linux v4.6-rc1
> - Add Tested-by tag from Markus Reichl 
> - Add Tested-by tag from Anand Moon 
> 
> Changes from v4:
> (https://lkml.org/lkml/2015/12/14/43)
> - Add new DEVFREQ_TRANSITION_NOTIFIER notifier. The passive
>   devfreq device recevie the changed frequency of parent
>   devfreq device through DEVFREQ_TRANSITION_NOTIFIER.
> - Add governor type to identify thme using the defined constant
> - Modify the passive governor using the DEVFREQ_TRANSITION_NOTIFIER notifier.
> - Fix the RCU locking probrlm (Reported-by: Tobias Jakobi)
> - Fix the debugfs error during the kernel booting (Reported-by: Tobias Jakobi)
> - The Device Tree patches have got Reviewed-by tag from Exynos SoC Maintainer
>   (Krzysztof Kozlowski )
> 
> Changes from v3:
> (https://lkml.org/lkml/2015/12/11/75)
> - Add the reviewed-by tag from Krzysztof Kozlowski (patch2/3/13/14/15/16/17)
> - Fix typo of the description on patch14
> - Modify the subject and description of patch17
> - Reorder the 'bus_xxx' device tree node alphabetically in 
>   both exynos3250-rinato/monk.dts and exynos4412-trats/odroidu3
> 
> Changes from v2:
> (https://lkml.org/lkml/2015/12/8/869)
> - Fix typo on documentation
> - Modify the more appropriate sentence on patch description
> - Add the detailed description about both parent and passive bus device
> - Modify the DMC frequency for Exynos4x12 DMC bus (200MHz -> 267MHz)
> - Modify the voltage of 200MHz was included in Exynos3250 DMC bus (800mV -> 
> 825mV)
> - Rename OPP nodes as 'opp@'
> - Delete the duplicate 'opp-microvolt' property of passive devfreq device
> - Reorder the 'bus_xxx' device tree node alphabetically in 
> exynos3250-rinato/monk.dts
> - Reorder the 'bus_xxx' device tree node alphabetically in 
> exynos4412-trats/odroidu3
> - Add new exynos4412-ppmu-common.dtsi to remove the duplicate PPMU dt node
>   on rinato/monk/trats2/odroid-u3 board
> - Add the log message if bus device is registered to devfreq framework 
> successfully
> - Add the reviewed-by tag from Krzysztof Kozlowski
> - Add the tested-by tag from Anand Moon on Odroid U3
> - Add 'SAMSUNG BUS FREQUENCY DRIVER' entry to MAINTAINERS
> 
> Changes from v1:
> (https://lkml.org/lkml/2015/11/26/260)
> - Check whether the instance of regulator is NULL or not
>   when executing regulator_disable() because of only parent
>   devfreq device has the regulator instance. After fixing it,
>   the wake-up from suspend state is well working. (patch1)
> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>   after calling devm_clk_get() (on patch1)
> - Update the documentation to remove the description about
>   DEVFREQ-EVENT subsystem (on patch2)
> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
> - Modify the detailed correlation of buses for Exynos3250
>   on documentation (patch2)
> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
> - Add the PPMU node for exynos4412-odroidu3
> - Add 

[PATCH v9 09/20] PM / devfreq: exynos: Remove unused exynos4/5 busfreq driver

[Chanwoo Choi]

This patch removes the unused exynos4/5 busfreq driver. Instead,
generic exynos-bus frequency driver support the all Exynos SoCs.

Signed-off-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham 
---
 drivers/devfreq/Kconfig  |   22 -
 drivers/devfreq/Makefile |2 -
 drivers/devfreq/exynos/Makefile  |3 -
 drivers/devfreq/exynos/exynos4_bus.c | 1055 --
 drivers/devfreq/exynos/exynos4_bus.h |  110 
 drivers/devfreq/exynos/exynos5_bus.c |  431 --
 drivers/devfreq/exynos/exynos_ppmu.c |  119 
 drivers/devfreq/exynos/exynos_ppmu.h |   86 ---
 8 files changed, 1828 deletions(-)
 delete mode 100644 drivers/devfreq/exynos/Makefile
 delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
 delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
 delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
 delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
 delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 30e1daf1c827..78dac0e9da11 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -90,28 +90,6 @@ config ARM_EXYNOS_BUS_DEVFREQ
  and adjusts the operating frequencies and voltages with OPP support.
  This does not yet operate with optimal voltages.
 
-config ARM_EXYNOS4_BUS_DEVFREQ
-   bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
-   depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && 
!ARCH_MULTIPLATFORM
-   select DEVFREQ_GOV_SIMPLE_ONDEMAND
-   select PM_OPP
-   help
- This adds the DEVFREQ driver for Exynos4210 memory bus (vdd_int)
- and Exynos4212/4412 memory interface and bus (vdd_mif + vdd_int).
- It reads PPMU counters of memory controllers and adjusts
- the operating frequencies and voltages with OPP support.
- This does not yet operate with optimal voltages.
-
-config ARM_EXYNOS5_BUS_DEVFREQ
-   tristate "ARM Exynos5250 Bus DEVFREQ Driver"
-   depends on SOC_EXYNOS5250
-   select DEVFREQ_GOV_SIMPLE_ONDEMAND
-   select PM_OPP
-   help
- This adds the DEVFREQ driver for Exynos5250 bus interface (vdd_int).
- It reads PPMU counters of memory controllers and adjusts the
- operating frequencies and voltages with OPP support.
-
 config ARM_TEGRA_DEVFREQ
tristate "Tegra DEVFREQ Driver"
depends on ARCH_TEGRA_124_SOC
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 2633087d5c63..09f11d9d40d5 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -8,8 +8,6 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)   += governor_passive.o
 
 # DEVFREQ Drivers
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos/
-obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos/
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
 
 # DEVFREQ Event Drivers
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
deleted file mode 100644
index 49bc9175f923..
--- a/drivers/devfreq/exynos/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# Exynos DEVFREQ Drivers
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos_ppmu.o exynos4_bus.o
-obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos4_bus.c 
b/drivers/devfreq/exynos/exynos4_bus.c
deleted file mode 100644
index da9509205169..
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ /dev/null
@@ -1,1055 +0,0 @@
-/* drivers/devfreq/exynos4210_memorybus.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- * MyungJoo Ham 
- *
- * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
- * This version supports EXYNOS4210 only. This changes bus frequencies
- * and vddint voltages. Exynos4412/4212 should be able to be supported
- * with minor modifications.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "exynos_ppmu.h"
-#include "exynos4_bus.h"
-
-#define MAX_SAFEVOLT   120 /* 1.2V */
-
-enum exynos4_busf_type {
-   TYPE_BUSF_EXYNOS4210,
-   TYPE_BUSF_EXYNOS4x12,
-};
-
-/* Assume that the bus is saturated if the utilization is 40% */
-#define BUS_SATURATION_RATIO   40
-
-enum busclk_level_idx {
-   LV_0 = 0,
-   LV_1,
-   LV_2,
-   LV_3,
-   LV_4,
-   _LV_END
-};
-
-enum exynos_ppmu_idx {
-   PPMU_DMC0,
-   PPMU_DMC1,
-   PPMU_END,
-};
-
-#define EX4210_LV_MAX  LV_2
-#define EX4x12_LV_MAX  LV_4
-#define 

Re: [PATCH v2] kvm-pr: manage single-step mode

[David Gibson]

On Fri,  8 Apr 2016 18:05:00 +0200
Laurent Vivier  wrote:

> Until now, when we connect gdb to the QEMU gdb-server, the
> single-step mode is not managed.
> 
> This patch adds this, only for kvm-pr:
> 
> If KVM_GUESTDBG_SINGLESTEP is set, we enable single-step trace bit in the
> MSR (MSR_SE) just before the __kvmppc_vcpu_run(), and disable it just after.
> In kvmppc_handle_exit_pr, instead of routing the interrupt to
> the guest, we return to host, with KVM_EXIT_DEBUG reason.
> 
> Signed-off-by: Laurent Vivier 

Reviewed-by: David Gibson 

> ---
> v2: split BOOK3S_INTERRUPT_MACHINE_CHECK and BOOK3S_INTERRUPT_TRACE
> 
>  arch/powerpc/kvm/book3s_pr.c | 32 +++-
>  1 file changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index 95bceca..8129b0d 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -882,6 +882,24 @@ void kvmppc_set_fscr(struct kvm_vcpu *vcpu, u64 fscr)
>  }
>  #endif
>  
> +static void kvmppc_setup_debug(struct kvm_vcpu *vcpu)
> +{
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + u64 msr = kvmppc_get_msr(vcpu);
> +
> + kvmppc_set_msr(vcpu, msr | MSR_SE);
> + }
> +}
> +
> +static void kvmppc_clear_debug(struct kvm_vcpu *vcpu)
> +{
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + u64 msr = kvmppc_get_msr(vcpu);
> +
> + kvmppc_set_msr(vcpu, msr & ~MSR_SE);
> + }
> +}
> +
>  int kvmppc_handle_exit_pr(struct kvm_run *run, struct kvm_vcpu *vcpu,
> unsigned int exit_nr)
>  {
> @@ -1207,10 +1225,18 @@ program_interrupt:
>   break;
>  #endif
>   case BOOK3S_INTERRUPT_MACHINE_CHECK:
> - case BOOK3S_INTERRUPT_TRACE:
>   kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
>   r = RESUME_GUEST;
>   break;
> + case BOOK3S_INTERRUPT_TRACE:
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + run->exit_reason = KVM_EXIT_DEBUG;
> + r = RESUME_HOST;
> + } else {
> + kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
> + r = RESUME_GUEST;
> + }
> + break;
>   default:
>   {
>   ulong shadow_srr1 = vcpu->arch.shadow_srr1;
> @@ -1479,6 +1505,8 @@ static int kvmppc_vcpu_run_pr(struct kvm_run *kvm_run, 
> struct kvm_vcpu *vcpu)
>   goto out;
>   }
>  
> + kvmppc_setup_debug(vcpu);
> +
>   /*
>* Interrupts could be timers for the guest which we have to inject
>* again, so let's postpone them until we're in the guest and if we
> @@ -1501,6 +1529,8 @@ static int kvmppc_vcpu_run_pr(struct kvm_run *kvm_run, 
> struct kvm_vcpu *vcpu)
>  
>   ret = __kvmppc_vcpu_run(kvm_run, vcpu);
>  
> + kvmppc_clear_debug(vcpu);
> +
>   /* No need for kvm_guest_exit. It's done in handle_exit.
>  We also get here with interrupts enabled. */
>  
> -- 
> 2.5.5
> 


-- 
David Gibson 
Senior Software Engineer, Virtualization, Red Hat


pgpkFXj1k88pQ.pgp
Description: OpenPGP digital signature

[PATCH v9 07/20] PM / devfreq: exynos: Update documentation for bus devices using passive governor

[Chanwoo Choi]

This patch updates the documentation for passive bus devices and adds the
detailed example of Exynos3250.

Signed-off-by: Chanwoo Choi 
Acked-by: MyungJoo Ham 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 250 -
 1 file changed, 247 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index 78171b918e3f..03f13d38f1a1 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -8,22 +8,46 @@ of the bus in runtime. To monitor the usage of each bus in 
runtime,
 the driver uses the PPMU (Platform Performance Monitoring Unit), which
 is able to measure the current load of sub-blocks.
 
+The Exynos SoC includes the various sub-blocks which have the each AXI bus.
+The each AXI bus has the owned source clock but, has not the only owned
+power line. The power line might be shared among one more sub-blocks.
+So, we can divide into two type of device as the role of each sub-block.
+There are two type of bus devices as following:
+- parent bus device
+- passive bus device
+
+Basically, parent and passive bus device share the same power line.
+The parent bus device can only change the voltage of shared power line
+and the rest bus devices (passive bus device) depend on the decision of
+the parent bus device. If there are three blocks which share the VDD_xxx
+power line, Only one block should be parent device and then the rest blocks
+should depend on the parent device as passive device.
+
+   VDD_xxx |--- A block (parent)
+   |--- B block (passive)
+   |--- C block (passive)
+
 There are a little different composition among Exynos SoC because each Exynos
 SoC has different sub-blocks. Therefore, shch difference should be specified
 in devicetree file instead of each device driver. In result, this driver
 is able to support the bus frequency for all Exynos SoCs.
 
-Required properties for bus device:
+Required properties for all bus devices:
 - compatible: Should be "samsung,exynos-bus".
 - clock-names : the name of clock used by the bus, "bus".
 - clocks : phandles for clock specified in "clock-names" property.
 - operating-points-v2: the OPP table including frequency/voltage information
   to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+
+Required properties only for parent bus device:
 - vdd-supply: the regulator to provide the buses with the voltage.
 - devfreq-events: the devfreq-event device to monitor the current utilization
   of buses.
 
-Optional properties for bus device:
+Required properties only for passive bus device:
+- devfreq: the parent bus device.
+
+Optional properties only for parent bus device:
 - exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
 - exynos,voltage-tolerance: the percentage value for bus voltage tolerance
@@ -34,7 +58,20 @@ Example1:
power line (regulator). The MIF (Memory Interface) AXI bus is used to
transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
 
-   - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+   - MIF (Memory Interface) block
+   : VDD_MIF |--- DMC (Dynamic Memory Controller)
+
+   - INT (Internal) block
+   : VDD_INT |--- LEFTBUS (parent device)
+ |--- PERIL
+ |--- MFC
+ |--- G3D
+ |--- RIGHTBUS
+ |--- FSYS
+ |--- LCD0
+ |--- PERIR
+ |--- ISP
+ |--- CAM
 
- MIF bus's frequency/voltage table
---
@@ -47,6 +84,24 @@ Example1:
|L5| 40 |875000   |
---
 
+   - INT bus's frequency/voltage table
+   --
+   |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL  ||VDD_INT |
+   | name|   |LCD0|   |   |   |||
+   | |   |FSYS|   |   |   |||
+   | |   |MFC |   |   |   |||
+   --
+   |Mode |*parent|passive |passive|passive|passive|||
+   --
+   |Lv   |Frequency   ||Voltage |
+   --
+   |L1   |5  |5   |5  |5  |5  ||90  |
+   |L2   |8  |8   |8  |8  |8  ||90  |
+   |L3   |10 |10  |10 |10 |10 ||100 |
+   |L4   |134000 |134000  |20 |20 |   ||100 |
+   |L5   |20 |20  |40 |30 |   ||100 |
+   

[PATCH v9 09/20] PM / devfreq: exynos: Remove unused exynos4/5 busfreq driver

[Chanwoo Choi]

This patch removes the unused exynos4/5 busfreq driver. Instead,
generic exynos-bus frequency driver support the all Exynos SoCs.

Signed-off-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham 
---
 drivers/devfreq/Kconfig  |   22 -
 drivers/devfreq/Makefile |2 -
 drivers/devfreq/exynos/Makefile  |3 -
 drivers/devfreq/exynos/exynos4_bus.c | 1055 --
 drivers/devfreq/exynos/exynos4_bus.h |  110 
 drivers/devfreq/exynos/exynos5_bus.c |  431 --
 drivers/devfreq/exynos/exynos_ppmu.c |  119 
 drivers/devfreq/exynos/exynos_ppmu.h |   86 ---
 8 files changed, 1828 deletions(-)
 delete mode 100644 drivers/devfreq/exynos/Makefile
 delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
 delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
 delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
 delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
 delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 30e1daf1c827..78dac0e9da11 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -90,28 +90,6 @@ config ARM_EXYNOS_BUS_DEVFREQ
  and adjusts the operating frequencies and voltages with OPP support.
  This does not yet operate with optimal voltages.
 
-config ARM_EXYNOS4_BUS_DEVFREQ
-   bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
-   depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && 
!ARCH_MULTIPLATFORM
-   select DEVFREQ_GOV_SIMPLE_ONDEMAND
-   select PM_OPP
-   help
- This adds the DEVFREQ driver for Exynos4210 memory bus (vdd_int)
- and Exynos4212/4412 memory interface and bus (vdd_mif + vdd_int).
- It reads PPMU counters of memory controllers and adjusts
- the operating frequencies and voltages with OPP support.
- This does not yet operate with optimal voltages.
-
-config ARM_EXYNOS5_BUS_DEVFREQ
-   tristate "ARM Exynos5250 Bus DEVFREQ Driver"
-   depends on SOC_EXYNOS5250
-   select DEVFREQ_GOV_SIMPLE_ONDEMAND
-   select PM_OPP
-   help
- This adds the DEVFREQ driver for Exynos5250 bus interface (vdd_int).
- It reads PPMU counters of memory controllers and adjusts the
- operating frequencies and voltages with OPP support.
-
 config ARM_TEGRA_DEVFREQ
tristate "Tegra DEVFREQ Driver"
depends on ARCH_TEGRA_124_SOC
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 2633087d5c63..09f11d9d40d5 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -8,8 +8,6 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)   += governor_passive.o
 
 # DEVFREQ Drivers
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos/
-obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos/
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
 
 # DEVFREQ Event Drivers
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
deleted file mode 100644
index 49bc9175f923..
--- a/drivers/devfreq/exynos/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# Exynos DEVFREQ Drivers
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos_ppmu.o exynos4_bus.o
-obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)  += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos4_bus.c 
b/drivers/devfreq/exynos/exynos4_bus.c
deleted file mode 100644
index da9509205169..
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ /dev/null
@@ -1,1055 +0,0 @@
-/* drivers/devfreq/exynos4210_memorybus.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- * MyungJoo Ham 
- *
- * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
- * This version supports EXYNOS4210 only. This changes bus frequencies
- * and vddint voltages. Exynos4412/4212 should be able to be supported
- * with minor modifications.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "exynos_ppmu.h"
-#include "exynos4_bus.h"
-
-#define MAX_SAFEVOLT   120 /* 1.2V */
-
-enum exynos4_busf_type {
-   TYPE_BUSF_EXYNOS4210,
-   TYPE_BUSF_EXYNOS4x12,
-};
-
-/* Assume that the bus is saturated if the utilization is 40% */
-#define BUS_SATURATION_RATIO   40
-
-enum busclk_level_idx {
-   LV_0 = 0,
-   LV_1,
-   LV_2,
-   LV_3,
-   LV_4,
-   _LV_END
-};
-
-enum exynos_ppmu_idx {
-   PPMU_DMC0,
-   PPMU_DMC1,
-   PPMU_END,
-};
-
-#define EX4210_LV_MAX  LV_2
-#define EX4x12_LV_MAX  LV_4
-#define EX4210_LV_NUM  (LV_2 + 1)
-#define EX4x12_LV_NUM  (LV_4 + 1)
-
-/**
- * struct 

Re: [PATCH v2] kvm-pr: manage single-step mode

[David Gibson]

On Fri,  8 Apr 2016 18:05:00 +0200
Laurent Vivier  wrote:

> Until now, when we connect gdb to the QEMU gdb-server, the
> single-step mode is not managed.
> 
> This patch adds this, only for kvm-pr:
> 
> If KVM_GUESTDBG_SINGLESTEP is set, we enable single-step trace bit in the
> MSR (MSR_SE) just before the __kvmppc_vcpu_run(), and disable it just after.
> In kvmppc_handle_exit_pr, instead of routing the interrupt to
> the guest, we return to host, with KVM_EXIT_DEBUG reason.
> 
> Signed-off-by: Laurent Vivier 

Reviewed-by: David Gibson 

> ---
> v2: split BOOK3S_INTERRUPT_MACHINE_CHECK and BOOK3S_INTERRUPT_TRACE
> 
>  arch/powerpc/kvm/book3s_pr.c | 32 +++-
>  1 file changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index 95bceca..8129b0d 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -882,6 +882,24 @@ void kvmppc_set_fscr(struct kvm_vcpu *vcpu, u64 fscr)
>  }
>  #endif
>  
> +static void kvmppc_setup_debug(struct kvm_vcpu *vcpu)
> +{
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + u64 msr = kvmppc_get_msr(vcpu);
> +
> + kvmppc_set_msr(vcpu, msr | MSR_SE);
> + }
> +}
> +
> +static void kvmppc_clear_debug(struct kvm_vcpu *vcpu)
> +{
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + u64 msr = kvmppc_get_msr(vcpu);
> +
> + kvmppc_set_msr(vcpu, msr & ~MSR_SE);
> + }
> +}
> +
>  int kvmppc_handle_exit_pr(struct kvm_run *run, struct kvm_vcpu *vcpu,
> unsigned int exit_nr)
>  {
> @@ -1207,10 +1225,18 @@ program_interrupt:
>   break;
>  #endif
>   case BOOK3S_INTERRUPT_MACHINE_CHECK:
> - case BOOK3S_INTERRUPT_TRACE:
>   kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
>   r = RESUME_GUEST;
>   break;
> + case BOOK3S_INTERRUPT_TRACE:
> + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
> + run->exit_reason = KVM_EXIT_DEBUG;
> + r = RESUME_HOST;
> + } else {
> + kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
> + r = RESUME_GUEST;
> + }
> + break;
>   default:
>   {
>   ulong shadow_srr1 = vcpu->arch.shadow_srr1;
> @@ -1479,6 +1505,8 @@ static int kvmppc_vcpu_run_pr(struct kvm_run *kvm_run, 
> struct kvm_vcpu *vcpu)
>   goto out;
>   }
>  
> + kvmppc_setup_debug(vcpu);
> +
>   /*
>* Interrupts could be timers for the guest which we have to inject
>* again, so let's postpone them until we're in the guest and if we
> @@ -1501,6 +1529,8 @@ static int kvmppc_vcpu_run_pr(struct kvm_run *kvm_run, 
> struct kvm_vcpu *vcpu)
>  
>   ret = __kvmppc_vcpu_run(kvm_run, vcpu);
>  
> + kvmppc_clear_debug(vcpu);
> +
>   /* No need for kvm_guest_exit. It's done in handle_exit.
>  We also get here with interrupts enabled. */
>  
> -- 
> 2.5.5
> 


-- 
David Gibson 
Senior Software Engineer, Virtualization, Red Hat


pgpkFXj1k88pQ.pgp
Description: OpenPGP digital signature

[PATCH v9 07/20] PM / devfreq: exynos: Update documentation for bus devices using passive governor

[Chanwoo Choi]

This patch updates the documentation for passive bus devices and adds the
detailed example of Exynos3250.

Signed-off-by: Chanwoo Choi 
Acked-by: MyungJoo Ham 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 250 -
 1 file changed, 247 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index 78171b918e3f..03f13d38f1a1 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -8,22 +8,46 @@ of the bus in runtime. To monitor the usage of each bus in 
runtime,
 the driver uses the PPMU (Platform Performance Monitoring Unit), which
 is able to measure the current load of sub-blocks.
 
+The Exynos SoC includes the various sub-blocks which have the each AXI bus.
+The each AXI bus has the owned source clock but, has not the only owned
+power line. The power line might be shared among one more sub-blocks.
+So, we can divide into two type of device as the role of each sub-block.
+There are two type of bus devices as following:
+- parent bus device
+- passive bus device
+
+Basically, parent and passive bus device share the same power line.
+The parent bus device can only change the voltage of shared power line
+and the rest bus devices (passive bus device) depend on the decision of
+the parent bus device. If there are three blocks which share the VDD_xxx
+power line, Only one block should be parent device and then the rest blocks
+should depend on the parent device as passive device.
+
+   VDD_xxx |--- A block (parent)
+   |--- B block (passive)
+   |--- C block (passive)
+
 There are a little different composition among Exynos SoC because each Exynos
 SoC has different sub-blocks. Therefore, shch difference should be specified
 in devicetree file instead of each device driver. In result, this driver
 is able to support the bus frequency for all Exynos SoCs.
 
-Required properties for bus device:
+Required properties for all bus devices:
 - compatible: Should be "samsung,exynos-bus".
 - clock-names : the name of clock used by the bus, "bus".
 - clocks : phandles for clock specified in "clock-names" property.
 - operating-points-v2: the OPP table including frequency/voltage information
   to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+
+Required properties only for parent bus device:
 - vdd-supply: the regulator to provide the buses with the voltage.
 - devfreq-events: the devfreq-event device to monitor the current utilization
   of buses.
 
-Optional properties for bus device:
+Required properties only for passive bus device:
+- devfreq: the parent bus device.
+
+Optional properties only for parent bus device:
 - exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
 - exynos,voltage-tolerance: the percentage value for bus voltage tolerance
@@ -34,7 +58,20 @@ Example1:
power line (regulator). The MIF (Memory Interface) AXI bus is used to
transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
 
-   - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+   - MIF (Memory Interface) block
+   : VDD_MIF |--- DMC (Dynamic Memory Controller)
+
+   - INT (Internal) block
+   : VDD_INT |--- LEFTBUS (parent device)
+ |--- PERIL
+ |--- MFC
+ |--- G3D
+ |--- RIGHTBUS
+ |--- FSYS
+ |--- LCD0
+ |--- PERIR
+ |--- ISP
+ |--- CAM
 
- MIF bus's frequency/voltage table
---
@@ -47,6 +84,24 @@ Example1:
|L5| 40 |875000   |
---
 
+   - INT bus's frequency/voltage table
+   --
+   |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL  ||VDD_INT |
+   | name|   |LCD0|   |   |   |||
+   | |   |FSYS|   |   |   |||
+   | |   |MFC |   |   |   |||
+   --
+   |Mode |*parent|passive |passive|passive|passive|||
+   --
+   |Lv   |Frequency   ||Voltage |
+   --
+   |L1   |5  |5   |5  |5  |5  ||90  |
+   |L2   |8  |8   |8  |8  |8  ||90  |
+   |L3   |10 |10  |10 |10 |10 ||100 |
+   |L4   |134000 |134000  |20 |20 |   ||100 |
+   |L5   |20 |20  |40 |30 |   ||100 |
+   

[PATCH v9 14/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12

[Chanwoo Choi]

This patch adds the bus nodes using VDD_MIF for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data
between DRAM and DMC/ACP/C2C.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
---
 arch/arm/boot/dts/exynos4x12.dtsi | 68 +++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index 84a23f962946..99a0f4ca3d47 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -281,6 +281,74 @@
clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
#iommu-cells = <0>;
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_acp: bus_acp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACP>;
+   clock-names = "bus";
+   operating-points-v2 = <_acp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_c2c: bus_c2c {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_C2C>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <90>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <90>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   opp-microvolt = <90>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <95>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <105>;
+   };
+   };
+
+   bus_acp_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   };
+   };
 };
 
  {
-- 
1.9.1

[PATCH v9 06/20] PM / devfreq: exynos: Add support of bus frequency of sub-blocks using passive governor

[Chanwoo Choi]

This patch adds the support of bus frequency feature for sub-blocks which share
the one power line. If each bus depends on the power line, each bus is not able
to change the voltage by oneself. To optimize the power-consumption on runtime,
some buses using the same power line should change the source clock and
regulator at the same time. So, this patch uses the passive governor to support
the bus frequency for all buses which sharing the one power line.

For example,

Exynos3250 include the two power line for AXI buses as following:
: VDD_MIF : MIF (Memory Interface) provide the DMC (Dynamic Memory Controller)
  with the power (regulator).
: VDD_INT : INT (Internal) provide the various sub-blocks with the power
  (regulator).

Each bus is included in as follwoing block. In the case of VDD_MIF, only DMC bus
use the power line. So, there is no any depencency between buese. But, in the
case of VDD_INT, various buses share the one power line of VDD_INT. We need to
make the depenency between buses. When using passive governor, there is no
problem to support the bus frequency as DVFS for all buses. One bus should be
operated as the parent bus device which gathering the current load of INT block
and then decides the new frequency with some governors except of passive
governor. After deciding the new frequency by the parent bus device, the rest
bus devices will change the each source clock according to new frequency of the
parent bus device.

- MIF (Memory Interface) block
: VDD_MIF |--- DMC

- INT (Internal) block
: VDD_INT |--- LEFTBUS (parent)
  |--- PERIL
  |--- MFC
  |--- G3D
  |--- RIGHTBUS
  |--- FSYS
  |--- LCD0
  |--- PERIR
  |--- ISP
  |--- CAM

Signed-off-by: Chanwoo Choi 
[tjakobi: Reported debugfs error during booting and cw00.choi fix it.]
Reported-by: Tobias Jakobi 
Signed-off-by: MyungJoo Ham 
---
 drivers/devfreq/Kconfig  |   1 +
 drivers/devfreq/exynos-bus.c | 219 ++-
 2 files changed, 174 insertions(+), 46 deletions(-)

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index d260cd0219f6..30e1daf1c827 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -78,6 +78,7 @@ config ARM_EXYNOS_BUS_DEVFREQ
bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
depends on ARCH_EXYNOS
select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select DEVFREQ_GOV_PASSIVE
select DEVFREQ_EVENT_EXYNOS_PPMU
select PM_DEVFREQ_EVENT
select PM_OPP
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 137de6196af3..50fe1a16c574 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -1,7 +1,7 @@
 /*
  * Generic Exynos Bus frequency driver with DEVFREQ Framework
  *
- * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
  * Author : Chanwoo Choi 
  *
  * This driver support Exynos Bus frequency feature by using
@@ -93,7 +93,7 @@ static int exynos_bus_get_event(struct exynos_bus *bus,
 }
 
 /*
- * Must necessary function for devfreq governor
+ * Must necessary function for devfreq simple-ondemand governor
  */
 static int exynos_bus_target(struct device *dev, unsigned long *freq, u32 
flags)
 {
@@ -202,59 +202,81 @@ static void exynos_bus_exit(struct device *dev)
regulator_disable(bus->regulator);
 
dev_pm_opp_of_remove_table(dev);
+   clk_disable_unprepare(bus->clk);
 }
 
-static int exynos_bus_parse_of(struct device_node *np,
- struct exynos_bus *bus)
+/*
+ * Must necessary function for devfreq passive governor
+ */
+static int exynos_bus_passive_target(struct device *dev, unsigned long *freq,
+   u32 flags)
 {
-   struct device *dev = bus->dev;
-   unsigned long rate;
-   int i, ret, count, size;
+   struct exynos_bus *bus = dev_get_drvdata(dev);
+   struct dev_pm_opp *new_opp;
+   unsigned long old_freq, new_freq;
+   int ret = 0;
 
-   /* Get the clock to provide each bus with source clock */
-   bus->clk = devm_clk_get(dev, "bus");
-   if (IS_ERR(bus->clk)) {
-   dev_err(dev, "failed to get bus clock\n");
-   return PTR_ERR(bus->clk);
+   /* Get new opp-bus instance according to new bus clock */
+   rcu_read_lock();
+   new_opp = devfreq_recommended_opp(dev, freq, flags);
+   if (IS_ERR(new_opp)) {
+   dev_err(dev, "failed to get recommended opp instance\n");
+   rcu_read_unlock();
+   return PTR_ERR(new_opp);
}
 
-   ret = clk_prepare_enable(bus->clk);
-   if (ret < 0) {
-   dev_err(dev, "failed to get enable clock\n");
-   return ret;
-   }
+   new_freq = dev_pm_opp_get_freq(new_opp);
+  

[PATCH v9 08/20] PM / devfreq: exynos: Add the detailed correlation between sub-blocks and power line

[Chanwoo Choi]

This patch adds the detailed corrleation between sub-blocks and power line
for Exynos3250, Exynos4210 and Exynos4x12.

Signed-off-by: Chanwoo Choi 
Acked-by: MyungJoo Ham 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index 03f13d38f1a1..b098fa2ba5d4 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -53,6 +53,57 @@ Optional properties only for parent bus device:
 - exynos,voltage-tolerance: the percentage value for bus voltage tolerance
which is used to calculate the max voltage.
 
+Detailed correlation between sub-blocks and power line according to Exynos SoC:
+- In case of Exynos3250, there are two power line as following:
+   VDD_MIF |--- DMC
+
+   VDD_INT |--- LEFTBUS (parent device)
+   |--- PERIL
+   |--- MFC
+   |--- G3D
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- FSYS
+   |--- LCD0
+   |--- PERIR
+   |--- ISP
+   |--- CAM
+
+- In case of Exynos4210, there is one power line as following:
+   VDD_INT |--- DMC (parent device)
+   |--- LEFTBUS
+   |--- PERIL
+   |--- MFC(L)
+   |--- G3D
+   |--- TV
+   |--- LCD0
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- MFC(R)
+   |--- CAM
+   |--- FSYS
+   |--- GPS
+   |--- LCD0
+   |--- LCD1
+
+- In case of Exynos4x12, there are two power line as following:
+   VDD_MIF |--- DMC
+
+   VDD_INT |--- LEFTBUS (parent device)
+   |--- PERIL
+   |--- MFC(L)
+   |--- G3D
+   |--- TV
+   |--- IMAGE
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- MFC(R)
+   |--- CAM
+   |--- FSYS
+   |--- GPS
+   |--- LCD0
+   |--- ISP
+
 Example1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
-- 
1.9.1

[PATCH v9 14/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12

[Chanwoo Choi]

This patch adds the bus nodes using VDD_MIF for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data
between DRAM and DMC/ACP/C2C.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
[m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
---
 arch/arm/boot/dts/exynos4x12.dtsi | 68 +++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index 84a23f962946..99a0f4ca3d47 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -281,6 +281,74 @@
clocks = < CLK_SMMU_LITE1>, < CLK_FIMC_LITE1>;
#iommu-cells = <0>;
};
+
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_acp: bus_acp {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_ACP>;
+   clock-names = "bus";
+   operating-points-v2 = <_acp_opp_table>;
+   status = "disabled";
+   };
+
+   bus_c2c: bus_c2c {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_C2C>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <90>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   opp-microvolt = <90>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   opp-microvolt = <90>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-microvolt = <95>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <105>;
+   };
+   };
+
+   bus_acp_opp_table: opp_table2 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   };
+   opp@13400 {
+   opp-hz = /bits/ 64 <13400>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   };
+   opp@26700 {
+   opp-hz = /bits/ 64 <26700>;
+   };
+   };
 };
 
  {
-- 
1.9.1

[PATCH v9 06/20] PM / devfreq: exynos: Add support of bus frequency of sub-blocks using passive governor

[Chanwoo Choi]

This patch adds the support of bus frequency feature for sub-blocks which share
the one power line. If each bus depends on the power line, each bus is not able
to change the voltage by oneself. To optimize the power-consumption on runtime,
some buses using the same power line should change the source clock and
regulator at the same time. So, this patch uses the passive governor to support
the bus frequency for all buses which sharing the one power line.

For example,

Exynos3250 include the two power line for AXI buses as following:
: VDD_MIF : MIF (Memory Interface) provide the DMC (Dynamic Memory Controller)
  with the power (regulator).
: VDD_INT : INT (Internal) provide the various sub-blocks with the power
  (regulator).

Each bus is included in as follwoing block. In the case of VDD_MIF, only DMC bus
use the power line. So, there is no any depencency between buese. But, in the
case of VDD_INT, various buses share the one power line of VDD_INT. We need to
make the depenency between buses. When using passive governor, there is no
problem to support the bus frequency as DVFS for all buses. One bus should be
operated as the parent bus device which gathering the current load of INT block
and then decides the new frequency with some governors except of passive
governor. After deciding the new frequency by the parent bus device, the rest
bus devices will change the each source clock according to new frequency of the
parent bus device.

- MIF (Memory Interface) block
: VDD_MIF |--- DMC

- INT (Internal) block
: VDD_INT |--- LEFTBUS (parent)
  |--- PERIL
  |--- MFC
  |--- G3D
  |--- RIGHTBUS
  |--- FSYS
  |--- LCD0
  |--- PERIR
  |--- ISP
  |--- CAM

Signed-off-by: Chanwoo Choi 
[tjakobi: Reported debugfs error during booting and cw00.choi fix it.]
Reported-by: Tobias Jakobi 
Signed-off-by: MyungJoo Ham 
---
 drivers/devfreq/Kconfig  |   1 +
 drivers/devfreq/exynos-bus.c | 219 ++-
 2 files changed, 174 insertions(+), 46 deletions(-)

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index d260cd0219f6..30e1daf1c827 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -78,6 +78,7 @@ config ARM_EXYNOS_BUS_DEVFREQ
bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
depends on ARCH_EXYNOS
select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select DEVFREQ_GOV_PASSIVE
select DEVFREQ_EVENT_EXYNOS_PPMU
select PM_DEVFREQ_EVENT
select PM_OPP
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 137de6196af3..50fe1a16c574 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -1,7 +1,7 @@
 /*
  * Generic Exynos Bus frequency driver with DEVFREQ Framework
  *
- * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
  * Author : Chanwoo Choi 
  *
  * This driver support Exynos Bus frequency feature by using
@@ -93,7 +93,7 @@ static int exynos_bus_get_event(struct exynos_bus *bus,
 }
 
 /*
- * Must necessary function for devfreq governor
+ * Must necessary function for devfreq simple-ondemand governor
  */
 static int exynos_bus_target(struct device *dev, unsigned long *freq, u32 
flags)
 {
@@ -202,59 +202,81 @@ static void exynos_bus_exit(struct device *dev)
regulator_disable(bus->regulator);
 
dev_pm_opp_of_remove_table(dev);
+   clk_disable_unprepare(bus->clk);
 }
 
-static int exynos_bus_parse_of(struct device_node *np,
- struct exynos_bus *bus)
+/*
+ * Must necessary function for devfreq passive governor
+ */
+static int exynos_bus_passive_target(struct device *dev, unsigned long *freq,
+   u32 flags)
 {
-   struct device *dev = bus->dev;
-   unsigned long rate;
-   int i, ret, count, size;
+   struct exynos_bus *bus = dev_get_drvdata(dev);
+   struct dev_pm_opp *new_opp;
+   unsigned long old_freq, new_freq;
+   int ret = 0;
 
-   /* Get the clock to provide each bus with source clock */
-   bus->clk = devm_clk_get(dev, "bus");
-   if (IS_ERR(bus->clk)) {
-   dev_err(dev, "failed to get bus clock\n");
-   return PTR_ERR(bus->clk);
+   /* Get new opp-bus instance according to new bus clock */
+   rcu_read_lock();
+   new_opp = devfreq_recommended_opp(dev, freq, flags);
+   if (IS_ERR(new_opp)) {
+   dev_err(dev, "failed to get recommended opp instance\n");
+   rcu_read_unlock();
+   return PTR_ERR(new_opp);
}
 
-   ret = clk_prepare_enable(bus->clk);
-   if (ret < 0) {
-   dev_err(dev, "failed to get enable clock\n");
-   return ret;
-   }
+   new_freq = dev_pm_opp_get_freq(new_opp);
+   old_freq = dev_pm_opp_get_freq(bus->curr_opp);
+   rcu_read_unlock();
 
-   /* Get the 

[PATCH v9 08/20] PM / devfreq: exynos: Add the detailed correlation between sub-blocks and power line

[Chanwoo Choi]

This patch adds the detailed corrleation between sub-blocks and power line
for Exynos3250, Exynos4210 and Exynos4x12.

Signed-off-by: Chanwoo Choi 
Acked-by: MyungJoo Ham 
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index 03f13d38f1a1..b098fa2ba5d4 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -53,6 +53,57 @@ Optional properties only for parent bus device:
 - exynos,voltage-tolerance: the percentage value for bus voltage tolerance
which is used to calculate the max voltage.
 
+Detailed correlation between sub-blocks and power line according to Exynos SoC:
+- In case of Exynos3250, there are two power line as following:
+   VDD_MIF |--- DMC
+
+   VDD_INT |--- LEFTBUS (parent device)
+   |--- PERIL
+   |--- MFC
+   |--- G3D
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- FSYS
+   |--- LCD0
+   |--- PERIR
+   |--- ISP
+   |--- CAM
+
+- In case of Exynos4210, there is one power line as following:
+   VDD_INT |--- DMC (parent device)
+   |--- LEFTBUS
+   |--- PERIL
+   |--- MFC(L)
+   |--- G3D
+   |--- TV
+   |--- LCD0
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- MFC(R)
+   |--- CAM
+   |--- FSYS
+   |--- GPS
+   |--- LCD0
+   |--- LCD1
+
+- In case of Exynos4x12, there are two power line as following:
+   VDD_MIF |--- DMC
+
+   VDD_INT |--- LEFTBUS (parent device)
+   |--- PERIL
+   |--- MFC(L)
+   |--- G3D
+   |--- TV
+   |--- IMAGE
+   |--- RIGHTBUS
+   |--- PERIR
+   |--- MFC(R)
+   |--- CAM
+   |--- FSYS
+   |--- GPS
+   |--- LCD0
+   |--- ISP
+
 Example1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
-- 
1.9.1