Re: [PATCH] 8250-men-mcb: add support for 16z025 and 16z057

2018-02-27 Thread Michael Moese
Hi,
Thanks for your comments. Let me briefly respond.

On Tue, Feb 27, 2018 at 07:57:34PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 27, 2018 at 5:31 PM, Michael Moese  wrote:
> > -   else if  (strncmp(mdev->bus->name, "F216", 4) == 0)
> > +   else if (strncmp(mdev->bus->name, "F216", 4) == 0)
> 
> What's changed?
There were two spaces after that if.

> > +   switch (mdev->id) {
> > +   case MEN_UART_ID_Z125:
> > +   num_ports = 1U;
> > +   break;
> > +   case MEN_UART_ID_Z025:
> > +   num_ports = readb(membase) >> 4;
> > +   break;
> > +   case MEN_UART_ID_Z057:
> > +   num_ports = 4U;
> > +   break;
> > +   default:
> > +   dev_err(>dev, "no supported device!\n");
> > +   return -ENODEV;
> > +   }
> 
> (1)
> 
> > +   data[i].uart.port.mapbase = (unsigned long) mem->start
> > +   + (i * MEN_UART_MEM_SIZE);
> 
> Redundant parens.
Well, let me remove them. Gonna do a v2 anyway.

> 
> > +   switch (mdev->id) {
> > +   case MEN_UART_ID_Z125:
> > +   num_ports = 1U;
> > +   break;
> > +   case MEN_UART_ID_Z025:
> > +   num_ports = readb(data[0].uart.port.membase) >> 4;
> > +   break;
> > +   case MEN_UART_ID_Z057:
> > +   num_ports = 4U;
> > +   break;
> > +   default:
> > +   dev_err(>dev, "no supported device!\n");
> > +   return;
> > +   }
> 
> Can you deduplicate this with (1)?
Well, that sounds like a good idea. Will do this.

> -- 
> With Best Regards,
> Andy Shevchenko

Thanks,
Michael
-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [PATCH] 8250-men-mcb: add support for 16z025 and 16z057

2018-02-27 Thread Michael Moese
Hi,
Thanks for your comments. Let me briefly respond.

On Tue, Feb 27, 2018 at 07:57:34PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 27, 2018 at 5:31 PM, Michael Moese  wrote:
> > -   else if  (strncmp(mdev->bus->name, "F216", 4) == 0)
> > +   else if (strncmp(mdev->bus->name, "F216", 4) == 0)
> 
> What's changed?
There were two spaces after that if.

> > +   switch (mdev->id) {
> > +   case MEN_UART_ID_Z125:
> > +   num_ports = 1U;
> > +   break;
> > +   case MEN_UART_ID_Z025:
> > +   num_ports = readb(membase) >> 4;
> > +   break;
> > +   case MEN_UART_ID_Z057:
> > +   num_ports = 4U;
> > +   break;
> > +   default:
> > +   dev_err(>dev, "no supported device!\n");
> > +   return -ENODEV;
> > +   }
> 
> (1)
> 
> > +   data[i].uart.port.mapbase = (unsigned long) mem->start
> > +   + (i * MEN_UART_MEM_SIZE);
> 
> Redundant parens.
Well, let me remove them. Gonna do a v2 anyway.

> 
> > +   switch (mdev->id) {
> > +   case MEN_UART_ID_Z125:
> > +   num_ports = 1U;
> > +   break;
> > +   case MEN_UART_ID_Z025:
> > +   num_ports = readb(data[0].uart.port.membase) >> 4;
> > +   break;
> > +   case MEN_UART_ID_Z057:
> > +   num_ports = 4U;
> > +   break;
> > +   default:
> > +   dev_err(>dev, "no supported device!\n");
> > +   return;
> > +   }
> 
> Can you deduplicate this with (1)?
Well, that sounds like a good idea. Will do this.

> -- 
> With Best Regards,
> Andy Shevchenko

Thanks,
Michael
-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume

2018-02-27 Thread Felipe Balbi

Hi,

Roger Quadros  writes:
> In the following test we get stuck by sleeping forever in _dwc3_set_mode()
> after which dual-role switching doesn't work.
>
> On dra7-evm's dual-role port,
> - Load g_zero gadget driver and enumerate to host
> - suspend to mem
> - disconnect USB cable to host and connect otg cable with Pen drive in it.
> - resume system
> - we sleep indefinitely in _dwc3_set_mode due to.
>   dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->
>   dwc3_gadget_stop()->wait_event_lock_irq()
>
> Let's clear the DWC3_EP_END_TRANSFER_PENDING flag on all endpoints
> so we don't wait in dwc3_gadget_stop().
>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/dwc3/gadget.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 2bda4eb..0a360da 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -3273,6 +3273,20 @@ int dwc3_gadget_init(struct dwc3 *dwc)
>  
>  void dwc3_gadget_exit(struct dwc3 *dwc)
>  {
> + int epnum;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>lock, flags);
> + for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
> + struct dwc3_ep  *dep = dwc->eps[epnum];
> +
> + if (!dep)
> + continue;
> +
> + dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING;
> + }
> + spin_unlock_irqrestore(>lock, flags);
> +
>   usb_del_gadget_udc(>gadget);
>   dwc3_gadget_free_endpoints(dwc);

free endpoints is a better place for this. It's already going to free
the memory anyway. Might as well clear all flags to 0 there.

-- 
balbi


signature.asc
Description: PGP signature


Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume

2018-02-27 Thread Felipe Balbi

Hi,

Roger Quadros  writes:
> In the following test we get stuck by sleeping forever in _dwc3_set_mode()
> after which dual-role switching doesn't work.
>
> On dra7-evm's dual-role port,
> - Load g_zero gadget driver and enumerate to host
> - suspend to mem
> - disconnect USB cable to host and connect otg cable with Pen drive in it.
> - resume system
> - we sleep indefinitely in _dwc3_set_mode due to.
>   dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->
>   dwc3_gadget_stop()->wait_event_lock_irq()
>
> Let's clear the DWC3_EP_END_TRANSFER_PENDING flag on all endpoints
> so we don't wait in dwc3_gadget_stop().
>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/dwc3/gadget.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 2bda4eb..0a360da 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -3273,6 +3273,20 @@ int dwc3_gadget_init(struct dwc3 *dwc)
>  
>  void dwc3_gadget_exit(struct dwc3 *dwc)
>  {
> + int epnum;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>lock, flags);
> + for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
> + struct dwc3_ep  *dep = dwc->eps[epnum];
> +
> + if (!dep)
> + continue;
> +
> + dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING;
> + }
> + spin_unlock_irqrestore(>lock, flags);
> +
>   usb_del_gadget_udc(>gadget);
>   dwc3_gadget_free_endpoints(dwc);

free endpoints is a better place for this. It's already going to free
the memory anyway. Might as well clear all flags to 0 there.

-- 
balbi


signature.asc
Description: PGP signature


Re: [PATCH 0/3] STM32 Extended TrustZone Protection driver

2018-02-27 Thread Benjamin Gaignard
2018-02-27 20:46 GMT+01:00 Robin Murphy :
> On 27/02/18 19:16, Benjamin Gaignard wrote:
>>
>> 2018-02-27 18:11 GMT+01:00 Mark Rutland :
>>>
>>> On Tue, Feb 27, 2018 at 03:09:23PM +0100, Benjamin Gaignard wrote:

 On early boot stages STM32MP1 platform is able to dedicate some hardware
 blocks
 to a secure OS running in TrustZone.
 We need to avoid using those hardware blocks on non-secure context (i.e.
 kernel)
 because read/write access will all be discarded.

 Extended TrustZone Protection driver register itself as listener of
 BUS_NOTIFY_BIND_DRIVER and check, given the device address, if the
 hardware block
 could be used in a Linux context. If not it returns NOTIFY_BAD to driver
 core
 to stop driver probing.
>>>
>>>
>>> Huh?
>>>
>>> If these devices are not usable from the non-secure side, why are they
>>> not removed form the DT (or marked disabled)?
>>>
>>> In other cases, where resources are carved out for the secure side (e.g.
>>> DRAM carveouts), that's how we handle things.
>>>
>>
>> That true you can parse and disable a device a boot time but if DT doesn't
>> exactly reflect etzpc status bits we will in trouble when try to get
>> access to
>> the device.
>
>
> Well, yes. If the DT doesn't correctly represent the hardware, things will
> probably go wrong; that's hardly a novel concept, and it's certainly not
> unique to this particular SoC.
>
>> Changing the DT is a software protection while etzpc is an hardware
>> protection
>> so we need to check it anyway.
>
>
> There are several in-tree DT and code examples where devices are marked as
> disabled on certain boards/SoC variants/etc. because attempting to access
> them can abort/lock up/trigger a secure watchdog reset/etc. The only
> "special" thing in this particular situation is apparently that this device
> even allows its secure configuration to be probed from the non-secure side
> at all.
>
> Implementing a boardfile so that you can "check" the DT makes very little
> sense to me; Linux is not a firmware validation suite.

It is not about to "check" the DT but if Linux could get access to the hardware.
Hardware block assignment to secure or non-secure world could change at runtime
for example I2C block could be manage by secure OS for a trusted
application and when
it have finish "release" the it for Linux. I don't think that could be
done by changing DT.

I think that dhecking hardware blocks status bits before probe them is
also more robust than let
each driver discover at probe time that it hardware isn't responding.

Benjamin

>
> Robin.


Re: [PATCH 0/3] STM32 Extended TrustZone Protection driver

2018-02-27 Thread Benjamin Gaignard
2018-02-27 20:46 GMT+01:00 Robin Murphy :
> On 27/02/18 19:16, Benjamin Gaignard wrote:
>>
>> 2018-02-27 18:11 GMT+01:00 Mark Rutland :
>>>
>>> On Tue, Feb 27, 2018 at 03:09:23PM +0100, Benjamin Gaignard wrote:

 On early boot stages STM32MP1 platform is able to dedicate some hardware
 blocks
 to a secure OS running in TrustZone.
 We need to avoid using those hardware blocks on non-secure context (i.e.
 kernel)
 because read/write access will all be discarded.

 Extended TrustZone Protection driver register itself as listener of
 BUS_NOTIFY_BIND_DRIVER and check, given the device address, if the
 hardware block
 could be used in a Linux context. If not it returns NOTIFY_BAD to driver
 core
 to stop driver probing.
>>>
>>>
>>> Huh?
>>>
>>> If these devices are not usable from the non-secure side, why are they
>>> not removed form the DT (or marked disabled)?
>>>
>>> In other cases, where resources are carved out for the secure side (e.g.
>>> DRAM carveouts), that's how we handle things.
>>>
>>
>> That true you can parse and disable a device a boot time but if DT doesn't
>> exactly reflect etzpc status bits we will in trouble when try to get
>> access to
>> the device.
>
>
> Well, yes. If the DT doesn't correctly represent the hardware, things will
> probably go wrong; that's hardly a novel concept, and it's certainly not
> unique to this particular SoC.
>
>> Changing the DT is a software protection while etzpc is an hardware
>> protection
>> so we need to check it anyway.
>
>
> There are several in-tree DT and code examples where devices are marked as
> disabled on certain boards/SoC variants/etc. because attempting to access
> them can abort/lock up/trigger a secure watchdog reset/etc. The only
> "special" thing in this particular situation is apparently that this device
> even allows its secure configuration to be probed from the non-secure side
> at all.
>
> Implementing a boardfile so that you can "check" the DT makes very little
> sense to me; Linux is not a firmware validation suite.

It is not about to "check" the DT but if Linux could get access to the hardware.
Hardware block assignment to secure or non-secure world could change at runtime
for example I2C block could be manage by secure OS for a trusted
application and when
it have finish "release" the it for Linux. I don't think that could be
done by changing DT.

I think that dhecking hardware blocks status bits before probe them is
also more robust than let
each driver discover at probe time that it hardware isn't responding.

Benjamin

>
> Robin.


[RFC 4/4] trace_uprobe: Fix multiple update of same semaphores

2018-02-27 Thread Ravi Bangoria
For tiny binaries/libraries, different mmap regions points to
the same file portion. In such cases, we may increment semaphore
multiple times. But while de-registration, semaphore will get
decremented only once, leaving semaphore > 0 even if no one is
tracing on that marker.

Ensure increment and decrement happens in sync by keeping list
of mms in trace_uprobe. Increment semaphore only if mm is not
present in the list and decrement only if mm is present in the
list.

Example

  # echo "p:sdt_tick/loop2 /tmp/tick:0x6e4 *0x10036" > uprobe_events

Before patch:

  # echo 1 > events/sdt_tick/loop2/enable
  # ./Workspace/sdt_prog/tick &
  # dd if=/proc//mem bs=1 count=1 skip=268566582 2>/dev/null | xxd
000: 02   .

  # echo 0 > events/sdt_tick/loop2/enable
  # dd if=/proc//mem bs=1 count=1 skip=268566582 2>/dev/null | xxd
000: 01   .

After patch:

  # echo 1 > events/sdt_tick/loop2/enable
  # ./Workspace/sdt_prog/tick &
  # dd if=/proc//mem bs=1 count=1 skip=268566582 2>/dev/null | xxd
000: 01   .

  # echo 0 > events/sdt_tick/loop2/enable
  # dd if=/proc//mem bs=1 count=1 skip=268566582 2>/dev/null | xxd
000: 00   .

Signed-off-by: Ravi Bangoria 
---
 kernel/trace/trace_uprobe.c | 105 ++--
 1 file changed, 102 insertions(+), 3 deletions(-)

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index d14aafc..3f1e8bd 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -49,6 +49,11 @@ struct trace_uprobe_filter {
struct list_headperf_events;
 };
 
+struct sdt_mm_list {
+   struct mm_struct *mm;
+   struct sdt_mm_list *next;
+};
+
 /*
  * uprobe event core functions
  */
@@ -60,6 +65,8 @@ struct trace_uprobe {
char*filename;
unsigned long   offset;
unsigned long   sdt_offset; /* sdt semaphore offset */
+   struct sdt_mm_list  *sml;
+   struct rw_semaphore sml_rw_sem;
unsigned long   nhit;
struct trace_probe  tp;
 };
@@ -273,6 +280,7 @@ static inline bool is_ret_probe(struct trace_uprobe *tu)
if (is_ret)
tu->consumer.ret_handler = uretprobe_dispatcher;
init_trace_uprobe_filter(>filter);
+   init_rwsem(>sml_rw_sem);
return tu;
 
 error:
@@ -953,6 +961,75 @@ static bool sdt_valid_vma(struct trace_uprobe *tu, struct 
vm_area_struct *vma)
return 0;
 }
 
+static bool sdt_check_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
+{
+   struct sdt_mm_list *tmp = tu->sml;
+
+   if (!tu->sml || !mm)
+   return false;
+
+   while (tmp) {
+   if (tmp->mm == mm)
+   return true;
+   tmp = tmp->next;
+   }
+
+   return false;
+}
+
+static void sdt_add_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
+{
+   struct sdt_mm_list *tmp;
+
+   tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
+   if (!tmp) {
+   pr_info("sdt_add_mm_list failed.\n");
+   return;
+   }
+   tmp->mm = mm;
+   tmp->next = tu->sml;
+   tu->sml = tmp;
+}
+
+static void sdt_del_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
+{
+   struct sdt_mm_list *prev, *curr;
+
+   if (!tu->sml)
+   return;
+
+   if (tu->sml->mm == mm) {
+   curr = tu->sml;
+   tu->sml = tu->sml->next;
+   kfree(curr);
+   return;
+   }
+
+   prev = tu->sml;
+   curr = tu->sml->next;
+   while (curr) {
+   if (curr->mm == mm) {
+   prev->next = curr->next;
+   kfree(curr);
+   return;
+   }
+   prev = curr;
+   curr = curr->next;
+   }
+}
+
+static void sdt_flush_mm_list(struct trace_uprobe *tu)
+{
+   struct sdt_mm_list *next, *curr = tu->sml;
+
+   while (curr) {
+   next = curr->next;
+   kfree(curr);
+   curr = next;
+   }
+   tu->sml = NULL;
+}
+
 /*
  * TODO: Adding this defination in include/linux/uprobes.h throws
  * warnings about address_sapce. Adding it here for the time being.
@@ -970,20 +1047,26 @@ static void sdt_increment_sem(struct trace_uprobe *tu)
if (IS_ERR(info))
goto out;
 
+   down_write(>sml_rw_sem);
while (info) {
down_write(>mm->mmap_sem);
vma = sdt_find_vma(info->mm, tu);
if (!vma)
goto cont;
 
+   if (sdt_check_mm_list(tu, info->mm))
+   goto cont;
+
vaddr = offset_to_vaddr(vma, tu->sdt_offset);
-   

[RFC 4/4] trace_uprobe: Fix multiple update of same semaphores

2018-02-27 Thread Ravi Bangoria
For tiny binaries/libraries, different mmap regions points to
the same file portion. In such cases, we may increment semaphore
multiple times. But while de-registration, semaphore will get
decremented only once, leaving semaphore > 0 even if no one is
tracing on that marker.

Ensure increment and decrement happens in sync by keeping list
of mms in trace_uprobe. Increment semaphore only if mm is not
present in the list and decrement only if mm is present in the
list.

Example

  # echo "p:sdt_tick/loop2 /tmp/tick:0x6e4 *0x10036" > uprobe_events

Before patch:

  # echo 1 > events/sdt_tick/loop2/enable
  # ./Workspace/sdt_prog/tick &
  # dd if=/proc//mem bs=1 count=1 skip=268566582 2>/dev/null | xxd
000: 02   .

  # echo 0 > events/sdt_tick/loop2/enable
  # dd if=/proc//mem bs=1 count=1 skip=268566582 2>/dev/null | xxd
000: 01   .

After patch:

  # echo 1 > events/sdt_tick/loop2/enable
  # ./Workspace/sdt_prog/tick &
  # dd if=/proc//mem bs=1 count=1 skip=268566582 2>/dev/null | xxd
000: 01   .

  # echo 0 > events/sdt_tick/loop2/enable
  # dd if=/proc//mem bs=1 count=1 skip=268566582 2>/dev/null | xxd
000: 00   .

Signed-off-by: Ravi Bangoria 
---
 kernel/trace/trace_uprobe.c | 105 ++--
 1 file changed, 102 insertions(+), 3 deletions(-)

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index d14aafc..3f1e8bd 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -49,6 +49,11 @@ struct trace_uprobe_filter {
struct list_headperf_events;
 };
 
+struct sdt_mm_list {
+   struct mm_struct *mm;
+   struct sdt_mm_list *next;
+};
+
 /*
  * uprobe event core functions
  */
@@ -60,6 +65,8 @@ struct trace_uprobe {
char*filename;
unsigned long   offset;
unsigned long   sdt_offset; /* sdt semaphore offset */
+   struct sdt_mm_list  *sml;
+   struct rw_semaphore sml_rw_sem;
unsigned long   nhit;
struct trace_probe  tp;
 };
@@ -273,6 +280,7 @@ static inline bool is_ret_probe(struct trace_uprobe *tu)
if (is_ret)
tu->consumer.ret_handler = uretprobe_dispatcher;
init_trace_uprobe_filter(>filter);
+   init_rwsem(>sml_rw_sem);
return tu;
 
 error:
@@ -953,6 +961,75 @@ static bool sdt_valid_vma(struct trace_uprobe *tu, struct 
vm_area_struct *vma)
return 0;
 }
 
+static bool sdt_check_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
+{
+   struct sdt_mm_list *tmp = tu->sml;
+
+   if (!tu->sml || !mm)
+   return false;
+
+   while (tmp) {
+   if (tmp->mm == mm)
+   return true;
+   tmp = tmp->next;
+   }
+
+   return false;
+}
+
+static void sdt_add_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
+{
+   struct sdt_mm_list *tmp;
+
+   tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
+   if (!tmp) {
+   pr_info("sdt_add_mm_list failed.\n");
+   return;
+   }
+   tmp->mm = mm;
+   tmp->next = tu->sml;
+   tu->sml = tmp;
+}
+
+static void sdt_del_mm_list(struct trace_uprobe *tu, struct mm_struct *mm)
+{
+   struct sdt_mm_list *prev, *curr;
+
+   if (!tu->sml)
+   return;
+
+   if (tu->sml->mm == mm) {
+   curr = tu->sml;
+   tu->sml = tu->sml->next;
+   kfree(curr);
+   return;
+   }
+
+   prev = tu->sml;
+   curr = tu->sml->next;
+   while (curr) {
+   if (curr->mm == mm) {
+   prev->next = curr->next;
+   kfree(curr);
+   return;
+   }
+   prev = curr;
+   curr = curr->next;
+   }
+}
+
+static void sdt_flush_mm_list(struct trace_uprobe *tu)
+{
+   struct sdt_mm_list *next, *curr = tu->sml;
+
+   while (curr) {
+   next = curr->next;
+   kfree(curr);
+   curr = next;
+   }
+   tu->sml = NULL;
+}
+
 /*
  * TODO: Adding this defination in include/linux/uprobes.h throws
  * warnings about address_sapce. Adding it here for the time being.
@@ -970,20 +1047,26 @@ static void sdt_increment_sem(struct trace_uprobe *tu)
if (IS_ERR(info))
goto out;
 
+   down_write(>sml_rw_sem);
while (info) {
down_write(>mm->mmap_sem);
vma = sdt_find_vma(info->mm, tu);
if (!vma)
goto cont;
 
+   if (sdt_check_mm_list(tu, info->mm))
+   goto cont;
+
vaddr = offset_to_vaddr(vma, tu->sdt_offset);
-   sdt_update_sem(info->mm, 

[RFC 3/4] trace_uprobe: Support SDT markers having semaphore

2018-02-27 Thread Ravi Bangoria
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. These markers are added by developer at
important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. If this computaion is quite more, execution of it can be
ommited by runtime if() condition when no one is tracing on the marker:

if (semaphore > 0) {
Execute marker instructions;
}   

Default value of semaphore is 0. Tracer has to increment the semaphore
before recording on a marker and decrement it at the end of tracing.

Implement the semaphore flip logic in trace_uprobe, leaving core uprobe
infrastructure as is, except one new callback from uprobe_mmap() to
trace_uprobe.

There are two major scenarios while enabling the marker,
 1. Trace already running process. In this case, find all suitable
processes and increment the semaphore value in them.
 2. Trace is already enabled when target binary is executed. In this
case, all mmaps will get notified to trace_uprobe and trace_uprobe
will increment the semaphore if corresponding uprobe is enabled.

At the time of disabling probes, decrement semaphore in all existing
target processes.

Signed-off-by: Ravi Bangoria 
---
 include/linux/uprobes.h |   2 +
 kernel/events/uprobes.c |   5 ++
 kernel/trace/trace_uprobe.c | 145 
 3 files changed, 152 insertions(+)

diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 06c169e..04e9d57 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -121,6 +121,8 @@ struct uprobe_map_info {
unsigned long vaddr;
 };
 
+extern void (*uprobe_mmap_callback)(struct vm_area_struct *vma);
+
 extern int set_swbp(struct arch_uprobe *aup, struct mm_struct *mm, unsigned 
long vaddr);
 extern int set_orig_insn(struct arch_uprobe *aup, struct mm_struct *mm, 
unsigned long vaddr);
 extern bool is_swbp_insn(uprobe_opcode_t *insn);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 56dd7af..81d8aaf 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1051,6 +1051,8 @@ static void build_probe_list(struct inode *inode,
spin_unlock(_treelock);
 }
 
+void (*uprobe_mmap_callback)(struct vm_area_struct *vma) = NULL;
+
 /*
  * Called from mmap_region/vma_adjust with mm->mmap_sem acquired.
  *
@@ -1063,6 +1065,9 @@ int uprobe_mmap(struct vm_area_struct *vma)
struct uprobe *uprobe, *u;
struct inode *inode;
 
+   if (vma->vm_flags & VM_WRITE && uprobe_mmap_callback)
+   uprobe_mmap_callback(vma);
+
if (no_uprobe_events() || !valid_vma(vma, true))
return 0;
 
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 40592e7b..d14aafc 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "trace_probe.h"
 
@@ -58,6 +59,7 @@ struct trace_uprobe {
struct inode*inode;
char*filename;
unsigned long   offset;
+   unsigned long   sdt_offset; /* sdt semaphore offset */
unsigned long   nhit;
struct trace_probe  tp;
 };
@@ -502,6 +504,16 @@ static int create_trace_uprobe(int argc, char **argv)
for (i = 0; i < argc && i < MAX_TRACE_ARGS; i++) {
struct probe_arg *parg = >tp.args[i];
 
+   /* This is not really an argument. */
+   if (argv[i][0] == '*') {
+   ret = kstrtoul(&(argv[i][1]), 0, >sdt_offset);
+   if (ret) {
+   pr_info("Invalid semaphore address.\n");
+   goto error;
+   }
+   continue;
+   }
+
/* Increment count for freeing args in error case */
tu->tp.nr_args++;
 
@@ -894,6 +906,131 @@ static void uretprobe_trace_func(struct trace_uprobe *tu, 
unsigned long func,
return trace_handle_return(s);
 }
 
+static bool sdt_valid_vma(struct trace_uprobe *tu, struct vm_area_struct *vma)
+{
+   unsigned long vaddr = offset_to_vaddr(vma, tu->sdt_offset);
+
+   return tu->sdt_offset &&
+   vma->vm_file &&
+   file_inode(vma->vm_file) == tu->inode &&
+   vma->vm_flags & VM_WRITE &&
+   vma->vm_start <= vaddr &&
+   vma->vm_end > vaddr;
+}
+
+static struct vm_area_struct *
+sdt_find_vma(struct mm_struct *mm, struct trace_uprobe *tu)
+{
+   struct vm_area_struct *tmp;
+
+   for (tmp = mm->mmap; tmp != NULL; tmp = tmp->vm_next)
+   if (sdt_valid_vma(tu, tmp))
+   return 

[RFC 3/4] trace_uprobe: Support SDT markers having semaphore

2018-02-27 Thread Ravi Bangoria
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. These markers are added by developer at
important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. If this computaion is quite more, execution of it can be
ommited by runtime if() condition when no one is tracing on the marker:

if (semaphore > 0) {
Execute marker instructions;
}   

Default value of semaphore is 0. Tracer has to increment the semaphore
before recording on a marker and decrement it at the end of tracing.

Implement the semaphore flip logic in trace_uprobe, leaving core uprobe
infrastructure as is, except one new callback from uprobe_mmap() to
trace_uprobe.

There are two major scenarios while enabling the marker,
 1. Trace already running process. In this case, find all suitable
processes and increment the semaphore value in them.
 2. Trace is already enabled when target binary is executed. In this
case, all mmaps will get notified to trace_uprobe and trace_uprobe
will increment the semaphore if corresponding uprobe is enabled.

At the time of disabling probes, decrement semaphore in all existing
target processes.

Signed-off-by: Ravi Bangoria 
---
 include/linux/uprobes.h |   2 +
 kernel/events/uprobes.c |   5 ++
 kernel/trace/trace_uprobe.c | 145 
 3 files changed, 152 insertions(+)

diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 06c169e..04e9d57 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -121,6 +121,8 @@ struct uprobe_map_info {
unsigned long vaddr;
 };
 
+extern void (*uprobe_mmap_callback)(struct vm_area_struct *vma);
+
 extern int set_swbp(struct arch_uprobe *aup, struct mm_struct *mm, unsigned 
long vaddr);
 extern int set_orig_insn(struct arch_uprobe *aup, struct mm_struct *mm, 
unsigned long vaddr);
 extern bool is_swbp_insn(uprobe_opcode_t *insn);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 56dd7af..81d8aaf 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1051,6 +1051,8 @@ static void build_probe_list(struct inode *inode,
spin_unlock(_treelock);
 }
 
+void (*uprobe_mmap_callback)(struct vm_area_struct *vma) = NULL;
+
 /*
  * Called from mmap_region/vma_adjust with mm->mmap_sem acquired.
  *
@@ -1063,6 +1065,9 @@ int uprobe_mmap(struct vm_area_struct *vma)
struct uprobe *uprobe, *u;
struct inode *inode;
 
+   if (vma->vm_flags & VM_WRITE && uprobe_mmap_callback)
+   uprobe_mmap_callback(vma);
+
if (no_uprobe_events() || !valid_vma(vma, true))
return 0;
 
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 40592e7b..d14aafc 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "trace_probe.h"
 
@@ -58,6 +59,7 @@ struct trace_uprobe {
struct inode*inode;
char*filename;
unsigned long   offset;
+   unsigned long   sdt_offset; /* sdt semaphore offset */
unsigned long   nhit;
struct trace_probe  tp;
 };
@@ -502,6 +504,16 @@ static int create_trace_uprobe(int argc, char **argv)
for (i = 0; i < argc && i < MAX_TRACE_ARGS; i++) {
struct probe_arg *parg = >tp.args[i];
 
+   /* This is not really an argument. */
+   if (argv[i][0] == '*') {
+   ret = kstrtoul(&(argv[i][1]), 0, >sdt_offset);
+   if (ret) {
+   pr_info("Invalid semaphore address.\n");
+   goto error;
+   }
+   continue;
+   }
+
/* Increment count for freeing args in error case */
tu->tp.nr_args++;
 
@@ -894,6 +906,131 @@ static void uretprobe_trace_func(struct trace_uprobe *tu, 
unsigned long func,
return trace_handle_return(s);
 }
 
+static bool sdt_valid_vma(struct trace_uprobe *tu, struct vm_area_struct *vma)
+{
+   unsigned long vaddr = offset_to_vaddr(vma, tu->sdt_offset);
+
+   return tu->sdt_offset &&
+   vma->vm_file &&
+   file_inode(vma->vm_file) == tu->inode &&
+   vma->vm_flags & VM_WRITE &&
+   vma->vm_start <= vaddr &&
+   vma->vm_end > vaddr;
+}
+
+static struct vm_area_struct *
+sdt_find_vma(struct mm_struct *mm, struct trace_uprobe *tu)
+{
+   struct vm_area_struct *tmp;
+
+   for (tmp = mm->mmap; tmp != NULL; tmp = tmp->vm_next)
+   if (sdt_valid_vma(tu, tmp))
+   return tmp;
+
+   return NULL;
+}
+

[RFC 2/4] Uprobe: Export few functions / data structures

2018-02-27 Thread Ravi Bangoria
These functions and data structures will be used by other files
in later patches.

Signed-off-by: Ravi Bangoria 
---
 include/linux/uprobes.h | 23 +++
 kernel/events/uprobes.c | 20 ++--
 2 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 0a294e9..06c169e 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -115,6 +115,12 @@ struct uprobes_state {
struct xol_area *xol_area;
 };
 
+struct uprobe_map_info {
+   struct uprobe_map_info *next;
+   struct mm_struct *mm;
+   unsigned long vaddr;
+};
+
 extern int set_swbp(struct arch_uprobe *aup, struct mm_struct *mm, unsigned 
long vaddr);
 extern int set_orig_insn(struct arch_uprobe *aup, struct mm_struct *mm, 
unsigned long vaddr);
 extern bool is_swbp_insn(uprobe_opcode_t *insn);
@@ -149,6 +155,11 @@ struct uprobes_state {
 extern bool arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs);
 extern void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
 void *src, unsigned long len);
+unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset);
+void copy_from_page(struct page *page, unsigned long vaddr, void *dst, int 
len);
+void copy_to_page(struct page *page, unsigned long vaddr, const void *src, int 
len);
+struct uprobe_map_info *free_uprobe_map_info(struct uprobe_map_info *info);
+
 #else /* !CONFIG_UPROBES */
 struct uprobes_state {
 };
@@ -203,5 +214,17 @@ static inline void uprobe_copy_process(struct task_struct 
*t, unsigned long flag
 static inline void uprobe_clear_state(struct mm_struct *mm)
 {
 }
+unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
+{
+}
+void copy_from_page(struct page *page, unsigned long vaddr, void *dst, int len)
+{
+}
+void copy_to_page(struct page *page, unsigned long vaddr, const void *src, int 
len)
+{
+}
+struct uprobe_map_info *free_uprobe_map_info(struct uprobe_map_info *info)
+{
+}
 #endif /* !CONFIG_UPROBES */
 #endif /* _LINUX_UPROBES_H */
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index fcce25dd..56dd7af 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -130,7 +130,7 @@ static bool valid_vma(struct vm_area_struct *vma, bool 
is_register)
return vma->vm_file && (vma->vm_flags & flags) == VM_MAYEXEC;
 }
 
-static unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
+unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
 {
return vma->vm_start + offset - ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
 }
@@ -240,14 +240,14 @@ bool __weak is_trap_insn(uprobe_opcode_t *insn)
return is_swbp_insn(insn);
 }
 
-static void copy_from_page(struct page *page, unsigned long vaddr, void *dst, 
int len)
+void copy_from_page(struct page *page, unsigned long vaddr, void *dst, int len)
 {
void *kaddr = kmap_atomic(page);
memcpy(dst, kaddr + (vaddr & ~PAGE_MASK), len);
kunmap_atomic(kaddr);
 }
 
-static void copy_to_page(struct page *page, unsigned long vaddr, const void 
*src, int len)
+void copy_to_page(struct page *page, unsigned long vaddr, const void *src, int 
len)
 {
void *kaddr = kmap_atomic(page);
memcpy(kaddr + (vaddr & ~PAGE_MASK), src, len);
@@ -705,23 +705,15 @@ static void delete_uprobe(struct uprobe *uprobe)
put_uprobe(uprobe);
 }
 
-struct uprobe_map_info {
-   struct uprobe_map_info *next;
-   struct mm_struct *mm;
-   unsigned long vaddr;
-};
-
-static inline struct uprobe_map_info *
-free_uprobe_map_info(struct uprobe_map_info *info)
+struct uprobe_map_info *free_uprobe_map_info(struct uprobe_map_info *info)
 {
struct uprobe_map_info *next = info->next;
kfree(info);
return next;
 }
 
-static struct uprobe_map_info *
-build_uprobe_map_info(struct address_space *mapping, loff_t offset,
- bool is_register)
+struct uprobe_map_info *build_uprobe_map_info(struct address_space *mapping,
+ loff_t offset, bool is_register)
 {
unsigned long pgoff = offset >> PAGE_SHIFT;
struct vm_area_struct *vma;
-- 
1.8.3.1



[RFC 2/4] Uprobe: Export few functions / data structures

2018-02-27 Thread Ravi Bangoria
These functions and data structures will be used by other files
in later patches.

Signed-off-by: Ravi Bangoria 
---
 include/linux/uprobes.h | 23 +++
 kernel/events/uprobes.c | 20 ++--
 2 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 0a294e9..06c169e 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -115,6 +115,12 @@ struct uprobes_state {
struct xol_area *xol_area;
 };
 
+struct uprobe_map_info {
+   struct uprobe_map_info *next;
+   struct mm_struct *mm;
+   unsigned long vaddr;
+};
+
 extern int set_swbp(struct arch_uprobe *aup, struct mm_struct *mm, unsigned 
long vaddr);
 extern int set_orig_insn(struct arch_uprobe *aup, struct mm_struct *mm, 
unsigned long vaddr);
 extern bool is_swbp_insn(uprobe_opcode_t *insn);
@@ -149,6 +155,11 @@ struct uprobes_state {
 extern bool arch_uprobe_ignore(struct arch_uprobe *aup, struct pt_regs *regs);
 extern void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
 void *src, unsigned long len);
+unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset);
+void copy_from_page(struct page *page, unsigned long vaddr, void *dst, int 
len);
+void copy_to_page(struct page *page, unsigned long vaddr, const void *src, int 
len);
+struct uprobe_map_info *free_uprobe_map_info(struct uprobe_map_info *info);
+
 #else /* !CONFIG_UPROBES */
 struct uprobes_state {
 };
@@ -203,5 +214,17 @@ static inline void uprobe_copy_process(struct task_struct 
*t, unsigned long flag
 static inline void uprobe_clear_state(struct mm_struct *mm)
 {
 }
+unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
+{
+}
+void copy_from_page(struct page *page, unsigned long vaddr, void *dst, int len)
+{
+}
+void copy_to_page(struct page *page, unsigned long vaddr, const void *src, int 
len)
+{
+}
+struct uprobe_map_info *free_uprobe_map_info(struct uprobe_map_info *info)
+{
+}
 #endif /* !CONFIG_UPROBES */
 #endif /* _LINUX_UPROBES_H */
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index fcce25dd..56dd7af 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -130,7 +130,7 @@ static bool valid_vma(struct vm_area_struct *vma, bool 
is_register)
return vma->vm_file && (vma->vm_flags & flags) == VM_MAYEXEC;
 }
 
-static unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
+unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
 {
return vma->vm_start + offset - ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
 }
@@ -240,14 +240,14 @@ bool __weak is_trap_insn(uprobe_opcode_t *insn)
return is_swbp_insn(insn);
 }
 
-static void copy_from_page(struct page *page, unsigned long vaddr, void *dst, 
int len)
+void copy_from_page(struct page *page, unsigned long vaddr, void *dst, int len)
 {
void *kaddr = kmap_atomic(page);
memcpy(dst, kaddr + (vaddr & ~PAGE_MASK), len);
kunmap_atomic(kaddr);
 }
 
-static void copy_to_page(struct page *page, unsigned long vaddr, const void 
*src, int len)
+void copy_to_page(struct page *page, unsigned long vaddr, const void *src, int 
len)
 {
void *kaddr = kmap_atomic(page);
memcpy(kaddr + (vaddr & ~PAGE_MASK), src, len);
@@ -705,23 +705,15 @@ static void delete_uprobe(struct uprobe *uprobe)
put_uprobe(uprobe);
 }
 
-struct uprobe_map_info {
-   struct uprobe_map_info *next;
-   struct mm_struct *mm;
-   unsigned long vaddr;
-};
-
-static inline struct uprobe_map_info *
-free_uprobe_map_info(struct uprobe_map_info *info)
+struct uprobe_map_info *free_uprobe_map_info(struct uprobe_map_info *info)
 {
struct uprobe_map_info *next = info->next;
kfree(info);
return next;
 }
 
-static struct uprobe_map_info *
-build_uprobe_map_info(struct address_space *mapping, loff_t offset,
- bool is_register)
+struct uprobe_map_info *build_uprobe_map_info(struct address_space *mapping,
+ loff_t offset, bool is_register)
 {
unsigned long pgoff = offset >> PAGE_SHIFT;
struct vm_area_struct *vma;
-- 
1.8.3.1



[RFC 1/4] Uprobe: Rename map_info to uprobe_map_info

2018-02-27 Thread Ravi Bangoria
map_info is very generic name, rename it to uprobe_map_info.
Renaming will help to export this structure outside of the
file.

Signed-off-by: Ravi Bangoria 
---
 kernel/events/uprobes.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 267f6ef..fcce25dd 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -705,27 +705,29 @@ static void delete_uprobe(struct uprobe *uprobe)
put_uprobe(uprobe);
 }
 
-struct map_info {
-   struct map_info *next;
+struct uprobe_map_info {
+   struct uprobe_map_info *next;
struct mm_struct *mm;
unsigned long vaddr;
 };
 
-static inline struct map_info *free_map_info(struct map_info *info)
+static inline struct uprobe_map_info *
+free_uprobe_map_info(struct uprobe_map_info *info)
 {
-   struct map_info *next = info->next;
+   struct uprobe_map_info *next = info->next;
kfree(info);
return next;
 }
 
-static struct map_info *
-build_map_info(struct address_space *mapping, loff_t offset, bool is_register)
+static struct uprobe_map_info *
+build_uprobe_map_info(struct address_space *mapping, loff_t offset,
+ bool is_register)
 {
unsigned long pgoff = offset >> PAGE_SHIFT;
struct vm_area_struct *vma;
-   struct map_info *curr = NULL;
-   struct map_info *prev = NULL;
-   struct map_info *info;
+   struct uprobe_map_info *curr = NULL;
+   struct uprobe_map_info *prev = NULL;
+   struct uprobe_map_info *info;
int more = 0;
 
  again:
@@ -739,7 +741,7 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
 * Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion 
through
 * reclaim. This is optimistic, no harm done if it 
fails.
 */
-   prev = kmalloc(sizeof(struct map_info),
+   prev = kmalloc(sizeof(struct uprobe_map_info),
GFP_NOWAIT | __GFP_NOMEMALLOC | 
__GFP_NOWARN);
if (prev)
prev->next = NULL;
@@ -772,7 +774,7 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
}
 
do {
-   info = kmalloc(sizeof(struct map_info), GFP_KERNEL);
+   info = kmalloc(sizeof(struct uprobe_map_info), GFP_KERNEL);
if (!info) {
curr = ERR_PTR(-ENOMEM);
goto out;
@@ -784,7 +786,7 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
goto again;
  out:
while (prev)
-   prev = free_map_info(prev);
+   prev = free_uprobe_map_info(prev);
return curr;
 }
 
@@ -792,11 +794,11 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
 register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
 {
bool is_register = !!new;
-   struct map_info *info;
+   struct uprobe_map_info *info;
int err = 0;
 
percpu_down_write(_mmap_sem);
-   info = build_map_info(uprobe->inode->i_mapping,
+   info = build_uprobe_map_info(uprobe->inode->i_mapping,
uprobe->offset, is_register);
if (IS_ERR(info)) {
err = PTR_ERR(info);
@@ -835,7 +837,7 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
up_write(>mmap_sem);
  free:
mmput(mm);
-   info = free_map_info(info);
+   info = free_uprobe_map_info(info);
}
  out:
percpu_up_write(_mmap_sem);
-- 
1.8.3.1



[RFC 1/4] Uprobe: Rename map_info to uprobe_map_info

2018-02-27 Thread Ravi Bangoria
map_info is very generic name, rename it to uprobe_map_info.
Renaming will help to export this structure outside of the
file.

Signed-off-by: Ravi Bangoria 
---
 kernel/events/uprobes.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 267f6ef..fcce25dd 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -705,27 +705,29 @@ static void delete_uprobe(struct uprobe *uprobe)
put_uprobe(uprobe);
 }
 
-struct map_info {
-   struct map_info *next;
+struct uprobe_map_info {
+   struct uprobe_map_info *next;
struct mm_struct *mm;
unsigned long vaddr;
 };
 
-static inline struct map_info *free_map_info(struct map_info *info)
+static inline struct uprobe_map_info *
+free_uprobe_map_info(struct uprobe_map_info *info)
 {
-   struct map_info *next = info->next;
+   struct uprobe_map_info *next = info->next;
kfree(info);
return next;
 }
 
-static struct map_info *
-build_map_info(struct address_space *mapping, loff_t offset, bool is_register)
+static struct uprobe_map_info *
+build_uprobe_map_info(struct address_space *mapping, loff_t offset,
+ bool is_register)
 {
unsigned long pgoff = offset >> PAGE_SHIFT;
struct vm_area_struct *vma;
-   struct map_info *curr = NULL;
-   struct map_info *prev = NULL;
-   struct map_info *info;
+   struct uprobe_map_info *curr = NULL;
+   struct uprobe_map_info *prev = NULL;
+   struct uprobe_map_info *info;
int more = 0;
 
  again:
@@ -739,7 +741,7 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
 * Needs GFP_NOWAIT to avoid i_mmap_rwsem recursion 
through
 * reclaim. This is optimistic, no harm done if it 
fails.
 */
-   prev = kmalloc(sizeof(struct map_info),
+   prev = kmalloc(sizeof(struct uprobe_map_info),
GFP_NOWAIT | __GFP_NOMEMALLOC | 
__GFP_NOWARN);
if (prev)
prev->next = NULL;
@@ -772,7 +774,7 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
}
 
do {
-   info = kmalloc(sizeof(struct map_info), GFP_KERNEL);
+   info = kmalloc(sizeof(struct uprobe_map_info), GFP_KERNEL);
if (!info) {
curr = ERR_PTR(-ENOMEM);
goto out;
@@ -784,7 +786,7 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
goto again;
  out:
while (prev)
-   prev = free_map_info(prev);
+   prev = free_uprobe_map_info(prev);
return curr;
 }
 
@@ -792,11 +794,11 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
 register_for_each_vma(struct uprobe *uprobe, struct uprobe_consumer *new)
 {
bool is_register = !!new;
-   struct map_info *info;
+   struct uprobe_map_info *info;
int err = 0;
 
percpu_down_write(_mmap_sem);
-   info = build_map_info(uprobe->inode->i_mapping,
+   info = build_uprobe_map_info(uprobe->inode->i_mapping,
uprobe->offset, is_register);
if (IS_ERR(info)) {
err = PTR_ERR(info);
@@ -835,7 +837,7 @@ static inline struct map_info *free_map_info(struct 
map_info *info)
up_write(>mmap_sem);
  free:
mmput(mm);
-   info = free_map_info(info);
+   info = free_uprobe_map_info(info);
}
  out:
percpu_up_write(_mmap_sem);
-- 
1.8.3.1



[RFC 0/4] trace_uprobe: Support SDT markers having semaphore

2018-02-27 Thread Ravi Bangoria
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. These markers are added by developer at
important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. If this computaion is quite more, execution of it can be
ommited by runtime if() condition when no one is tracing on the marker:

if (semaphore > 0) {
Execute marker instructions;
}

Default value of semaphore is 0. Tracer has to increment the semaphore
before recording on a marker and decrement it at the end of tracing.

Currently, perf tool has limited supports for SDT markers. I.e. it
can not trace markers surrounded by semaphore. Also, it's not easy
to add semaphore flip logic in userspace tool like perf, so basic
idea for this patchset is to add semaphore flip logic in the
trace_uprobe infrastructure. Ex,[2]

  # cat tick.c
... 
for (i = 0; i < 100; i++) {
DTRACE_PROBE1(tick, loop1, i);
if (TICK_LOOP2_ENABLED()) {
DTRACE_PROBE1(tick, loop2, i); 
}
printf("hi: %d\n", i); 
sleep(1);
}   
... 

Here tick:loop1 is marker without semaphore where as tick:loop2 is
surrounded by semaphore.


  # perf buildid-cache --add /tmp/tick
  # perf probe sdt_tick:loop1
  # perf probe sdt_tick:loop2

  # perf stat -e sdt_tick:loop1,sdt_tick:loop2 -- /tmp/tick
  hi: 0
  hi: 1
  hi: 2
  ^C
  Performance counter stats for '/tmp/tick':
 3  sdt_tick:loop1
 0  sdt_tick:loop2
 2.747086086 seconds time elapsed


Perf failed to record data for tick:loop2. Same experiment with this
patch series:


  # readelf -n ./tick
  Provider: tick
  Name: loop2
  ... Semaphore: 0x10020036

  # readelf -SW ./tick | grep probes
  [25] .probes   PROGBITS10020034 010034


Semaphore offset is 0x10036. I don't have educated 'perf probe'
about semaphore. So instead of using 'perf probe' command, I'm
manually adding entry in the /uprobe_events file.
Special char * denotes semaphore offset.


  # echo "p:sdt_tick/loop2 /tmp/tick:0x6e4 *0x10036" > uprobe_events

  # perf stat -e sdt_tick:loop2 -- /tmp/tick
  hi: 0
  hi: 1
  hi: 2
  hi: 3
  ^C
  Performance counter stats for '/tmp/tick':
  4  sdt_tick:loop2 
 
 3.359047827 seconds time elapsed


Feedback?

TODO:
 - Educate perf tool about semaphore.
 - perf_event_open() now suppoers {k,u}probe event creation[3]. If we
   can supply semaphore offset in perf_event_attr, perf_event_open()
   can be educated to probe SDT marker having semaphore. Though, both
   config1 and config2 are already being used for uprobe and I don't
   see any other attribute which I can use for semaphore offset. Can
   we introduce one more config there? config3?

[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
[2] https://github.com/iovisor/bcc/issues/327#issuecomment-200576506
[3] https://lkml.org/lkml/2017/12/6/976


Ravi Bangoria (4):
  Uprobe: Rename map_info to uprobe_map_info
  Uprobe: Export few functions / data structures
  trace_uprobe: Support SDT markers having semaphore
  trace_uprobe: Fix multiple update of same semaphores

 include/linux/uprobes.h |  25 +
 kernel/events/uprobes.c |  43 
 kernel/trace/trace_uprobe.c | 244 
 3 files changed, 290 insertions(+), 22 deletions(-)

-- 
1.8.3.1



[RFC 0/4] trace_uprobe: Support SDT markers having semaphore

2018-02-27 Thread Ravi Bangoria
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. These markers are added by developer at
important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. If this computaion is quite more, execution of it can be
ommited by runtime if() condition when no one is tracing on the marker:

if (semaphore > 0) {
Execute marker instructions;
}

Default value of semaphore is 0. Tracer has to increment the semaphore
before recording on a marker and decrement it at the end of tracing.

Currently, perf tool has limited supports for SDT markers. I.e. it
can not trace markers surrounded by semaphore. Also, it's not easy
to add semaphore flip logic in userspace tool like perf, so basic
idea for this patchset is to add semaphore flip logic in the
trace_uprobe infrastructure. Ex,[2]

  # cat tick.c
... 
for (i = 0; i < 100; i++) {
DTRACE_PROBE1(tick, loop1, i);
if (TICK_LOOP2_ENABLED()) {
DTRACE_PROBE1(tick, loop2, i); 
}
printf("hi: %d\n", i); 
sleep(1);
}   
... 

Here tick:loop1 is marker without semaphore where as tick:loop2 is
surrounded by semaphore.


  # perf buildid-cache --add /tmp/tick
  # perf probe sdt_tick:loop1
  # perf probe sdt_tick:loop2

  # perf stat -e sdt_tick:loop1,sdt_tick:loop2 -- /tmp/tick
  hi: 0
  hi: 1
  hi: 2
  ^C
  Performance counter stats for '/tmp/tick':
 3  sdt_tick:loop1
 0  sdt_tick:loop2
 2.747086086 seconds time elapsed


Perf failed to record data for tick:loop2. Same experiment with this
patch series:


  # readelf -n ./tick
  Provider: tick
  Name: loop2
  ... Semaphore: 0x10020036

  # readelf -SW ./tick | grep probes
  [25] .probes   PROGBITS10020034 010034


Semaphore offset is 0x10036. I don't have educated 'perf probe'
about semaphore. So instead of using 'perf probe' command, I'm
manually adding entry in the /uprobe_events file.
Special char * denotes semaphore offset.


  # echo "p:sdt_tick/loop2 /tmp/tick:0x6e4 *0x10036" > uprobe_events

  # perf stat -e sdt_tick:loop2 -- /tmp/tick
  hi: 0
  hi: 1
  hi: 2
  hi: 3
  ^C
  Performance counter stats for '/tmp/tick':
  4  sdt_tick:loop2 
 
 3.359047827 seconds time elapsed


Feedback?

TODO:
 - Educate perf tool about semaphore.
 - perf_event_open() now suppoers {k,u}probe event creation[3]. If we
   can supply semaphore offset in perf_event_attr, perf_event_open()
   can be educated to probe SDT marker having semaphore. Though, both
   config1 and config2 are already being used for uprobe and I don't
   see any other attribute which I can use for semaphore offset. Can
   we introduce one more config there? config3?

[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
[2] https://github.com/iovisor/bcc/issues/327#issuecomment-200576506
[3] https://lkml.org/lkml/2017/12/6/976


Ravi Bangoria (4):
  Uprobe: Rename map_info to uprobe_map_info
  Uprobe: Export few functions / data structures
  trace_uprobe: Support SDT markers having semaphore
  trace_uprobe: Fix multiple update of same semaphores

 include/linux/uprobes.h |  25 +
 kernel/events/uprobes.c |  43 
 kernel/trace/trace_uprobe.c | 244 
 3 files changed, 290 insertions(+), 22 deletions(-)

-- 
1.8.3.1



Re: [PATCH v2 4/4] pintcrl: support bias-disable of generic and special pins simultaneously

2018-02-27 Thread Zhiyong Tao
On Wed, 2018-02-28 at 15:33 +0800, Sean Wang wrote:
> On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> > For generic pins, parameter "arg" is 0 or 1.
> > For special pins, bias-disable is set by R0R1,
> > so we need transmited "00" to set bias-disable
> > When we set "bias-disable" as high-z property,
> > the parameter should be "MTK_PUPD_SET_R1R0_00".
> > 
> > Signed-off-by: Zhiyong Tao 
> > ---
> >  drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > index 3cf384f..e88ba04 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > @@ -301,8 +301,17 @@ static int mtk_pconf_set_pull_select(struct 
> > mtk_pinctrl *pctl,
> >  * resistor bit, so we need this special handle.
> >  */
> > if (pctl->devdata->spec_pull_set) {
> > -   ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
> > -   pin, pctl->devdata->port_align, isup, arg);
> > +   if (enable) {
> > +   ret = pctl->devdata->spec_pull_set(
> > +   mtk_get_regmap(pctl, pin), pin,
> > +   pctl->devdata->port_align, isup,
> > +   arg);
> > +   } else {
> > +   ret = pctl->devdata->spec_pull_set(
> > +   mtk_get_regmap(pctl, pin), pin,
> > +   pctl->devdata->port_align, isup,
> > +   MTK_PUPD_SET_R1R0_00);
> > +   }
> 
> 
> it looks like you can use as following snippet with reusing original
> logic and less effort on maintaining these common code (?)
==> Thanks for your suggestion very much. It seems better.
I will change it in v3.
> 
> 
> if (pctl->devdata->spec_pull_set) {
>   + if (!enable)
>   +   arg = MTK_PUPD_SET_R1R0_00;
> 
>   ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
>   pin, pctl->devdata->port_align, isup, arg);
> 
> 
> Also, it's better to add more comments to such kind of special path for
> allowing future SoCs to follow and extend more easily.

==> Thanks for your suggestion very much. I will add more comments here.
> 
> > if (!ret)
> > return 0;
> > }
> 
> 




Re: [PATCH v2 4/4] pintcrl: support bias-disable of generic and special pins simultaneously

2018-02-27 Thread Zhiyong Tao
On Wed, 2018-02-28 at 15:33 +0800, Sean Wang wrote:
> On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> > For generic pins, parameter "arg" is 0 or 1.
> > For special pins, bias-disable is set by R0R1,
> > so we need transmited "00" to set bias-disable
> > When we set "bias-disable" as high-z property,
> > the parameter should be "MTK_PUPD_SET_R1R0_00".
> > 
> > Signed-off-by: Zhiyong Tao 
> > ---
> >  drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > index 3cf384f..e88ba04 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > @@ -301,8 +301,17 @@ static int mtk_pconf_set_pull_select(struct 
> > mtk_pinctrl *pctl,
> >  * resistor bit, so we need this special handle.
> >  */
> > if (pctl->devdata->spec_pull_set) {
> > -   ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
> > -   pin, pctl->devdata->port_align, isup, arg);
> > +   if (enable) {
> > +   ret = pctl->devdata->spec_pull_set(
> > +   mtk_get_regmap(pctl, pin), pin,
> > +   pctl->devdata->port_align, isup,
> > +   arg);
> > +   } else {
> > +   ret = pctl->devdata->spec_pull_set(
> > +   mtk_get_regmap(pctl, pin), pin,
> > +   pctl->devdata->port_align, isup,
> > +   MTK_PUPD_SET_R1R0_00);
> > +   }
> 
> 
> it looks like you can use as following snippet with reusing original
> logic and less effort on maintaining these common code (?)
==> Thanks for your suggestion very much. It seems better.
I will change it in v3.
> 
> 
> if (pctl->devdata->spec_pull_set) {
>   + if (!enable)
>   +   arg = MTK_PUPD_SET_R1R0_00;
> 
>   ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
>   pin, pctl->devdata->port_align, isup, arg);
> 
> 
> Also, it's better to add more comments to such kind of special path for
> allowing future SoCs to follow and extend more easily.

==> Thanks for your suggestion very much. I will add more comments here.
> 
> > if (!ret)
> > return 0;
> > }
> 
> 




Re: [PATCH v2 1/4] arm64: dts: mt2712: add pintcrl file

2018-02-27 Thread Zhiyong Tao
On Wed, 2018-02-28 at 14:42 +0800, Sean Wang wrote:
> On Mon, 2018-02-26 at 16:33 +0800, Zhiyong Tao wrote:
> > This patch adds pinctrl file for mt2712.
> > 
> > Signed-off-by: Zhiyong Tao 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1129 
> > +
> >  1 file changed, 1129 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h 
> > b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> > new file mode 100644
> > index 000..44f8ca2
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> > @@ -0,0 +1,1129 @@
> > +/*
> > + * Copyright (C) 2015 MediaTek Inc.
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> 
> suggest to consider more on using SPDX identifiers

==> Thanks for your suggestion.
We will use SPDX identifiers in V3.

> 
> > +#ifndef __DTS_MT2712_PINFUNC_H
> > +#define __DTS_MT2712_PINFUNC_H
> > +
> > +#include 
> > +
> > +#define MT2712_PIN_0_EINT0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
> > +#define MT2712_PIN_0_EINT0__FUNC_EINT0 (MTK_PIN_NO(0) | 1)
> > +#define MT2712_PIN_0_EINT0__FUNC_MBIST_DIAG_SCANOUT (MTK_PIN_NO(0) | 2)
> > +#define MT2712_PIN_0_EINT0__FUNC_DSIA_TE (MTK_PIN_NO(0) | 3)
> > +#define MT2712_PIN_0_EINT0__FUNC_DSIC_TE (MTK_PIN_NO(0) | 4)
> > +#define MT2712_PIN_0_EINT0__FUNC_DIN_D3 (MTK_PIN_NO(0) | 5)
> > +#define MT2712_PIN_0_EINT0__FUNC_PURE_HW_PROTECT (MTK_PIN_NO(0) | 6)
> > +
> > +#define MT2712_PIN_1_EINT1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
> > +#define MT2712_PIN_1_EINT1__FUNC_EINT1 (MTK_PIN_NO(1) | 1)
> > +#define MT2712_PIN_1_EINT1__FUNC_IR_IN (MTK_PIN_NO(1) | 2)
> > +#define MT2712_PIN_1_EINT1__FUNC_DSIB_TE (MTK_PIN_NO(1) | 3)
> > +#define MT2712_PIN_1_EINT1__FUNC_DSID_TE (MTK_PIN_NO(1) | 4)
> > +#define MT2712_PIN_1_EINT1__FUNC_DIN_D4 (MTK_PIN_NO(1) | 5)
> > +
> > +#define MT2712_PIN_2_EINT2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
> > +#define MT2712_PIN_2_EINT2__FUNC_EINT2 (MTK_PIN_NO(2) | 1)
> > +#define MT2712_PIN_2_EINT2__FUNC_IR_IN (MTK_PIN_NO(2) | 2)
> > +#define MT2712_PIN_2_EINT2__FUNC_LCM_RST1 (MTK_PIN_NO(2) | 3)
> > +#define MT2712_PIN_2_EINT2__FUNC_DIN_D5 (MTK_PIN_NO(2) | 5)
> > +
> > +#define MT2712_PIN_3_EINT3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
> > +#define MT2712_PIN_3_EINT3__FUNC_EINT3 (MTK_PIN_NO(3) | 1)
> > +#define MT2712_PIN_3_EINT3__FUNC_IR_IN (MTK_PIN_NO(3) | 2)
> > +#define MT2712_PIN_3_EINT3__FUNC_LCM_RST0 (MTK_PIN_NO(3) | 3)
> > +#define MT2712_PIN_3_EINT3__FUNC_DIN_D6 (MTK_PIN_NO(3) | 5)
> > +
> > +#define MT2712_PIN_4_PWM0__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
> > +#define MT2712_PIN_4_PWM0__FUNC_PWM0 (MTK_PIN_NO(4) | 1)
> > +#define MT2712_PIN_4_PWM0__FUNC_DISP0_PWM (MTK_PIN_NO(4) | 2)
> > +#define MT2712_PIN_4_PWM0__FUNC_DISP1_PWM (MTK_PIN_NO(4) | 3)
> > +#define MT2712_PIN_4_PWM0__FUNC_DIN_CLK (MTK_PIN_NO(4) | 5)
> > +
> > +#define MT2712_PIN_5_PWM1__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
> > +#define MT2712_PIN_5_PWM1__FUNC_PWM1 (MTK_PIN_NO(5) | 1)
> > +#define MT2712_PIN_5_PWM1__FUNC_DISP1_PWM (MTK_PIN_NO(5) | 2)
> > +#define MT2712_PIN_5_PWM1__FUNC_DISP0_PWM (MTK_PIN_NO(5) | 3)
> > +#define MT2712_PIN_5_PWM1__FUNC_DIN_VSYNC (MTK_PIN_NO(5) | 5)
> > +
> > +#define MT2712_PIN_6_PWM2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
> > +#define MT2712_PIN_6_PWM2__FUNC_PWM2 (MTK_PIN_NO(6) | 1)
> > +#define MT2712_PIN_6_PWM2__FUNC_DISP0_PWM (MTK_PIN_NO(6) | 2)
> > +#define MT2712_PIN_6_PWM2__FUNC_DISP1_PWM (MTK_PIN_NO(6) | 3)
> > +#define MT2712_PIN_6_PWM2__FUNC_DISP2_PWM (MTK_PIN_NO(6) | 4)
> > +#define MT2712_PIN_6_PWM2__FUNC_DIN_HSYNC (MTK_PIN_NO(6) | 5)
> > +
> > +#define MT2712_PIN_7_PWM3__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
> > +#define MT2712_PIN_7_PWM3__FUNC_PWM3 (MTK_PIN_NO(7) | 1)
> > +#define MT2712_PIN_7_PWM3__FUNC_DISP1_PWM (MTK_PIN_NO(7) | 2)
> > +#define MT2712_PIN_7_PWM3__FUNC_DISP0_PWM (MTK_PIN_NO(7) | 3)
> > +#define MT2712_PIN_7_PWM3__FUNC_LCM_RST2 (MTK_PIN_NO(7) | 4)
> > +#define MT2712_PIN_7_PWM3__FUNC_DIN_D0 (MTK_PIN_NO(7) | 5)
> > +
> > +#define MT2712_PIN_8_PWM4__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
> > +#define MT2712_PIN_8_PWM4__FUNC_PWM4 (MTK_PIN_NO(8) | 1)
> > +#define MT2712_PIN_8_PWM4__FUNC_DISP0_PWM (MTK_PIN_NO(8) | 2)
> > +#define MT2712_PIN_8_PWM4__FUNC_DISP1_PWM (MTK_PIN_NO(8) | 3)
> > +#define MT2712_PIN_8_PWM4__FUNC_DSIA_TE (MTK_PIN_NO(8) | 4)
> > +#define MT2712_PIN_8_PWM4__FUNC_DIN_D1 (MTK_PIN_NO(8) | 5)
> > +
> > +#define MT2712_PIN_9_PWM5__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
> > +#define MT2712_PIN_9_PWM5__FUNC_PWM5 (MTK_PIN_NO(9) | 1)
> > +#define 

Re: [PATCH v2 1/4] arm64: dts: mt2712: add pintcrl file

2018-02-27 Thread Zhiyong Tao
On Wed, 2018-02-28 at 14:42 +0800, Sean Wang wrote:
> On Mon, 2018-02-26 at 16:33 +0800, Zhiyong Tao wrote:
> > This patch adds pinctrl file for mt2712.
> > 
> > Signed-off-by: Zhiyong Tao 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1129 
> > +
> >  1 file changed, 1129 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h 
> > b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> > new file mode 100644
> > index 000..44f8ca2
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> > @@ -0,0 +1,1129 @@
> > +/*
> > + * Copyright (C) 2015 MediaTek Inc.
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> 
> suggest to consider more on using SPDX identifiers

==> Thanks for your suggestion.
We will use SPDX identifiers in V3.

> 
> > +#ifndef __DTS_MT2712_PINFUNC_H
> > +#define __DTS_MT2712_PINFUNC_H
> > +
> > +#include 
> > +
> > +#define MT2712_PIN_0_EINT0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
> > +#define MT2712_PIN_0_EINT0__FUNC_EINT0 (MTK_PIN_NO(0) | 1)
> > +#define MT2712_PIN_0_EINT0__FUNC_MBIST_DIAG_SCANOUT (MTK_PIN_NO(0) | 2)
> > +#define MT2712_PIN_0_EINT0__FUNC_DSIA_TE (MTK_PIN_NO(0) | 3)
> > +#define MT2712_PIN_0_EINT0__FUNC_DSIC_TE (MTK_PIN_NO(0) | 4)
> > +#define MT2712_PIN_0_EINT0__FUNC_DIN_D3 (MTK_PIN_NO(0) | 5)
> > +#define MT2712_PIN_0_EINT0__FUNC_PURE_HW_PROTECT (MTK_PIN_NO(0) | 6)
> > +
> > +#define MT2712_PIN_1_EINT1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
> > +#define MT2712_PIN_1_EINT1__FUNC_EINT1 (MTK_PIN_NO(1) | 1)
> > +#define MT2712_PIN_1_EINT1__FUNC_IR_IN (MTK_PIN_NO(1) | 2)
> > +#define MT2712_PIN_1_EINT1__FUNC_DSIB_TE (MTK_PIN_NO(1) | 3)
> > +#define MT2712_PIN_1_EINT1__FUNC_DSID_TE (MTK_PIN_NO(1) | 4)
> > +#define MT2712_PIN_1_EINT1__FUNC_DIN_D4 (MTK_PIN_NO(1) | 5)
> > +
> > +#define MT2712_PIN_2_EINT2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
> > +#define MT2712_PIN_2_EINT2__FUNC_EINT2 (MTK_PIN_NO(2) | 1)
> > +#define MT2712_PIN_2_EINT2__FUNC_IR_IN (MTK_PIN_NO(2) | 2)
> > +#define MT2712_PIN_2_EINT2__FUNC_LCM_RST1 (MTK_PIN_NO(2) | 3)
> > +#define MT2712_PIN_2_EINT2__FUNC_DIN_D5 (MTK_PIN_NO(2) | 5)
> > +
> > +#define MT2712_PIN_3_EINT3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
> > +#define MT2712_PIN_3_EINT3__FUNC_EINT3 (MTK_PIN_NO(3) | 1)
> > +#define MT2712_PIN_3_EINT3__FUNC_IR_IN (MTK_PIN_NO(3) | 2)
> > +#define MT2712_PIN_3_EINT3__FUNC_LCM_RST0 (MTK_PIN_NO(3) | 3)
> > +#define MT2712_PIN_3_EINT3__FUNC_DIN_D6 (MTK_PIN_NO(3) | 5)
> > +
> > +#define MT2712_PIN_4_PWM0__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
> > +#define MT2712_PIN_4_PWM0__FUNC_PWM0 (MTK_PIN_NO(4) | 1)
> > +#define MT2712_PIN_4_PWM0__FUNC_DISP0_PWM (MTK_PIN_NO(4) | 2)
> > +#define MT2712_PIN_4_PWM0__FUNC_DISP1_PWM (MTK_PIN_NO(4) | 3)
> > +#define MT2712_PIN_4_PWM0__FUNC_DIN_CLK (MTK_PIN_NO(4) | 5)
> > +
> > +#define MT2712_PIN_5_PWM1__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
> > +#define MT2712_PIN_5_PWM1__FUNC_PWM1 (MTK_PIN_NO(5) | 1)
> > +#define MT2712_PIN_5_PWM1__FUNC_DISP1_PWM (MTK_PIN_NO(5) | 2)
> > +#define MT2712_PIN_5_PWM1__FUNC_DISP0_PWM (MTK_PIN_NO(5) | 3)
> > +#define MT2712_PIN_5_PWM1__FUNC_DIN_VSYNC (MTK_PIN_NO(5) | 5)
> > +
> > +#define MT2712_PIN_6_PWM2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
> > +#define MT2712_PIN_6_PWM2__FUNC_PWM2 (MTK_PIN_NO(6) | 1)
> > +#define MT2712_PIN_6_PWM2__FUNC_DISP0_PWM (MTK_PIN_NO(6) | 2)
> > +#define MT2712_PIN_6_PWM2__FUNC_DISP1_PWM (MTK_PIN_NO(6) | 3)
> > +#define MT2712_PIN_6_PWM2__FUNC_DISP2_PWM (MTK_PIN_NO(6) | 4)
> > +#define MT2712_PIN_6_PWM2__FUNC_DIN_HSYNC (MTK_PIN_NO(6) | 5)
> > +
> > +#define MT2712_PIN_7_PWM3__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
> > +#define MT2712_PIN_7_PWM3__FUNC_PWM3 (MTK_PIN_NO(7) | 1)
> > +#define MT2712_PIN_7_PWM3__FUNC_DISP1_PWM (MTK_PIN_NO(7) | 2)
> > +#define MT2712_PIN_7_PWM3__FUNC_DISP0_PWM (MTK_PIN_NO(7) | 3)
> > +#define MT2712_PIN_7_PWM3__FUNC_LCM_RST2 (MTK_PIN_NO(7) | 4)
> > +#define MT2712_PIN_7_PWM3__FUNC_DIN_D0 (MTK_PIN_NO(7) | 5)
> > +
> > +#define MT2712_PIN_8_PWM4__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
> > +#define MT2712_PIN_8_PWM4__FUNC_PWM4 (MTK_PIN_NO(8) | 1)
> > +#define MT2712_PIN_8_PWM4__FUNC_DISP0_PWM (MTK_PIN_NO(8) | 2)
> > +#define MT2712_PIN_8_PWM4__FUNC_DISP1_PWM (MTK_PIN_NO(8) | 3)
> > +#define MT2712_PIN_8_PWM4__FUNC_DSIA_TE (MTK_PIN_NO(8) | 4)
> > +#define MT2712_PIN_8_PWM4__FUNC_DIN_D1 (MTK_PIN_NO(8) | 5)
> > +
> > +#define MT2712_PIN_9_PWM5__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
> > +#define MT2712_PIN_9_PWM5__FUNC_PWM5 (MTK_PIN_NO(9) | 1)
> > +#define MT2712_PIN_9_PWM5__FUNC_DISP1_PWM 

RE: [PATCH 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems

2018-02-27 Thread Gaku Inami
Hi

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org 
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Morten Rasmussen
> Sent: Friday, February 16, 2018 1:21 AM
> To: pet...@infradead.org; mi...@redhat.com
> Cc: valentin.schnei...@arm.com; dietmar.eggem...@arm.com; 
> vincent.guit...@linaro.org; linux-kernel@vger.kernel.org;
> Morten Rasmussen 
> Subject: [PATCH 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric 
> capacity systems
> 

> 
> The patches have been tested on:
>1. Arm Juno (r0): 2+4 Cortex A57/A53
>2. Hikey960: 4+4 Cortex A73/A53
> 
> Test case:
> Big cpus are always kept busy. Pin a shorter running sysbench tasks to
> big cpus, while creating a longer running set of unpinned sysbench
> tasks.

Tested-by: Gaku Inami 

I tested as same in other SoC. It looks fine.

The patches have been tested on:
   3. Renesas R-Car H3 : 4+4 Cortex A57/A53

Results:
Single runs with completion time of each task
R-Car H3 (tip)
total time:  0.9415s
total time:  0.9582s
total time:  1.3275s
total time:  1.6752s

R-Car H3 (misfit)
total time:  0.9312s
total time:  0.9429s
total time:  0.9525s
total time:  0.9660s

10 run summary (tracking longest running task for each run)
R-Car H3
avg max
tip 1.6752  1.6753
misfit  0.9890  1.0204

Regards,
Inami


RE: [PATCH 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems

2018-02-27 Thread Gaku Inami
Hi

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org 
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Morten Rasmussen
> Sent: Friday, February 16, 2018 1:21 AM
> To: pet...@infradead.org; mi...@redhat.com
> Cc: valentin.schnei...@arm.com; dietmar.eggem...@arm.com; 
> vincent.guit...@linaro.org; linux-kernel@vger.kernel.org;
> Morten Rasmussen 
> Subject: [PATCH 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric 
> capacity systems
> 

> 
> The patches have been tested on:
>1. Arm Juno (r0): 2+4 Cortex A57/A53
>2. Hikey960: 4+4 Cortex A73/A53
> 
> Test case:
> Big cpus are always kept busy. Pin a shorter running sysbench tasks to
> big cpus, while creating a longer running set of unpinned sysbench
> tasks.

Tested-by: Gaku Inami 

I tested as same in other SoC. It looks fine.

The patches have been tested on:
   3. Renesas R-Car H3 : 4+4 Cortex A57/A53

Results:
Single runs with completion time of each task
R-Car H3 (tip)
total time:  0.9415s
total time:  0.9582s
total time:  1.3275s
total time:  1.6752s

R-Car H3 (misfit)
total time:  0.9312s
total time:  0.9429s
total time:  0.9525s
total time:  0.9660s

10 run summary (tracking longest running task for each run)
R-Car H3
avg max
tip 1.6752  1.6753
misfit  0.9890  1.0204

Regards,
Inami


Re: [PATCH v2 3/4] pinctrl: add mt2712 pinctrl driver

2018-02-27 Thread Zhiyong Tao
On Wed, 2018-02-28 at 15:14 +0800, Sean Wang wrote:
> Hi, Zhiyong
> 
> all seems better than v1, but some nitpicking is addressed as below 
> 
>   Sean
> 
> On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> > The commit includes mt2712 pinctrl driver.
> > 
> > Signed-off-by: Zhiyong Tao 
> > ---
> >  drivers/pinctrl/mediatek/Kconfig  |7 +
> >  drivers/pinctrl/mediatek/Makefile |1 +
> >  drivers/pinctrl/mediatek/pinctrl-mt2712.c |  639 
> >  drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1973 
> > +
> >  4 files changed, 2620 insertions(+)
> >  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
> >  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> > 
> > diff --git a/drivers/pinctrl/mediatek/Kconfig 
> > b/drivers/pinctrl/mediatek/Kconfig
> > index 3e59874..b24bc76 100644
> > --- a/drivers/pinctrl/mediatek/Kconfig
> > +++ b/drivers/pinctrl/mediatek/Kconfig
> > @@ -32,6 +32,13 @@ config PINCTRL_MT8127
> > select PINCTRL_MTK
> >  
> >  # For ARMv8 SoCs
> > +config PINCTRL_MT2712
> > +   bool "Mediatek MT2712 pin control"
> 
> 
> should be MediaTek for normal
==> Thanks for your suggestion. We will correct it in v3.
> 
> > +   depends on OF
> > +   depends on ARM64 || COMPILE_TEST
> > +   default ARM64 && ARCH_MEDIATEK
> > +   select PINCTRL_MTK
> > +
> >  config PINCTRL_MT7622
> > bool "MediaTek MT7622 pin control"
> > depends on OF
> > diff --git a/drivers/pinctrl/mediatek/Makefile 
> > b/drivers/pinctrl/mediatek/Makefile
> > index ed7d2b2..7959e77 100644
> > --- a/drivers/pinctrl/mediatek/Makefile
> > +++ b/drivers/pinctrl/mediatek/Makefile
> > @@ -4,6 +4,7 @@ obj-$(CONFIG_PINCTRL_MTK)   += pinctrl-mtk-common.o
> >  
> >  # SoC Drivers
> >  obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
> > +obj-$(CONFIG_PINCTRL_MT2712)   += pinctrl-mt2712.o
> >  obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
> >  obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
> >  obj-$(CONFIG_PINCTRL_MT7622)   += pinctrl-mt7622.o
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c 
> > b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> > new file mode 100644
> > index 000..b6ae71b
> > --- /dev/null
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> > @@ -0,0 +1,639 @@
> > +/*
> > + * Copyright (c) 2014-2015 MediaTek Inc.
> > + * Author: Hongzhou.Yang 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> 
> suggest to consider more on using SPDX identifiers and
> using right data for both fields Copyright and Author
==> Thanks for your suggestion. We will correct it in v3.
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "pinctrl-mtk-common.h"
> > +#include "pinctrl-mtk-mt2712.h"
> > +
> 
> <...>
> 
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h 
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> > new file mode 100644
> > index 000..71f4190
> > --- /dev/null
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> > @@ -0,0 +1,1973 @@
> > +/*
> > + * Copyright (C) 2015 MediaTek Inc.
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> 
> Ditto 
> 
> > +#ifndef PINCTRL_MTK_MT2712_H
> > +#define PINCTRL_MTK_MT2712_H
> > +
> 
> <...>
> 
> > +
> > +#endif /* __PINCTRL_MTK_MT2712_H */
> 
> 




Re: [PATCH v2 3/4] pinctrl: add mt2712 pinctrl driver

2018-02-27 Thread Zhiyong Tao
On Wed, 2018-02-28 at 15:14 +0800, Sean Wang wrote:
> Hi, Zhiyong
> 
> all seems better than v1, but some nitpicking is addressed as below 
> 
>   Sean
> 
> On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> > The commit includes mt2712 pinctrl driver.
> > 
> > Signed-off-by: Zhiyong Tao 
> > ---
> >  drivers/pinctrl/mediatek/Kconfig  |7 +
> >  drivers/pinctrl/mediatek/Makefile |1 +
> >  drivers/pinctrl/mediatek/pinctrl-mt2712.c |  639 
> >  drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1973 
> > +
> >  4 files changed, 2620 insertions(+)
> >  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
> >  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> > 
> > diff --git a/drivers/pinctrl/mediatek/Kconfig 
> > b/drivers/pinctrl/mediatek/Kconfig
> > index 3e59874..b24bc76 100644
> > --- a/drivers/pinctrl/mediatek/Kconfig
> > +++ b/drivers/pinctrl/mediatek/Kconfig
> > @@ -32,6 +32,13 @@ config PINCTRL_MT8127
> > select PINCTRL_MTK
> >  
> >  # For ARMv8 SoCs
> > +config PINCTRL_MT2712
> > +   bool "Mediatek MT2712 pin control"
> 
> 
> should be MediaTek for normal
==> Thanks for your suggestion. We will correct it in v3.
> 
> > +   depends on OF
> > +   depends on ARM64 || COMPILE_TEST
> > +   default ARM64 && ARCH_MEDIATEK
> > +   select PINCTRL_MTK
> > +
> >  config PINCTRL_MT7622
> > bool "MediaTek MT7622 pin control"
> > depends on OF
> > diff --git a/drivers/pinctrl/mediatek/Makefile 
> > b/drivers/pinctrl/mediatek/Makefile
> > index ed7d2b2..7959e77 100644
> > --- a/drivers/pinctrl/mediatek/Makefile
> > +++ b/drivers/pinctrl/mediatek/Makefile
> > @@ -4,6 +4,7 @@ obj-$(CONFIG_PINCTRL_MTK)   += pinctrl-mtk-common.o
> >  
> >  # SoC Drivers
> >  obj-$(CONFIG_PINCTRL_MT2701)   += pinctrl-mt2701.o
> > +obj-$(CONFIG_PINCTRL_MT2712)   += pinctrl-mt2712.o
> >  obj-$(CONFIG_PINCTRL_MT8135)   += pinctrl-mt8135.o
> >  obj-$(CONFIG_PINCTRL_MT8127)   += pinctrl-mt8127.o
> >  obj-$(CONFIG_PINCTRL_MT7622)   += pinctrl-mt7622.o
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c 
> > b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> > new file mode 100644
> > index 000..b6ae71b
> > --- /dev/null
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> > @@ -0,0 +1,639 @@
> > +/*
> > + * Copyright (c) 2014-2015 MediaTek Inc.
> > + * Author: Hongzhou.Yang 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> 
> suggest to consider more on using SPDX identifiers and
> using right data for both fields Copyright and Author
==> Thanks for your suggestion. We will correct it in v3.
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "pinctrl-mtk-common.h"
> > +#include "pinctrl-mtk-mt2712.h"
> > +
> 
> <...>
> 
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h 
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> > new file mode 100644
> > index 000..71f4190
> > --- /dev/null
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> > @@ -0,0 +1,1973 @@
> > +/*
> > + * Copyright (C) 2015 MediaTek Inc.
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> 
> Ditto 
> 
> > +#ifndef PINCTRL_MTK_MT2712_H
> > +#define PINCTRL_MTK_MT2712_H
> > +
> 
> <...>
> 
> > +
> > +#endif /* __PINCTRL_MTK_MT2712_H */
> 
> 




[PATCH] hwmon: g762: handle cleanup with devm_add_action

2018-02-27 Thread Peng Hao
Simplify code and use devm_add_action() to handle cleanup.

Signed-off-by: Peng Hao 
---
 drivers/hwmon/g762.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
index 6d1208b..48e60d8 100644
--- a/drivers/hwmon/g762.c
+++ b/drivers/hwmon/g762.c
@@ -128,7 +128,6 @@ enum g762_regs {
 G762_REG_FAN_CMD2_GEAR_MODE_1)) >> 2))
 
 struct g762_data {
-   struct device *hwmon_dev;
struct i2c_client *client;
struct clk *clk;
 
@@ -1051,9 +1050,17 @@ static inline int g762_fan_init(struct device *dev)
 data->fan_cmd1);
 }
 
+static void g762_remove(void *data)
+{
+   struct g762_data *g762 = data;
+   struct i2c_client *client = g762->client;
+
+   g762_of_clock_disable(client);
+}
 static int g762_probe(struct i2c_client *client, const struct i2c_device_id 
*id)
 {
struct device *dev = >dev;
+   struct device *hwmon_dev;
struct g762_data *data;
int ret;
 
@@ -1086,10 +1093,12 @@ static int g762_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
if (ret)
goto clock_dis;
 
-   data->hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
-   data, g762_groups);
-   if (IS_ERR(data->hwmon_dev)) {
-   ret = PTR_ERR(data->hwmon_dev);
+   devm_add_action(dev, g762_remove, data);
+
+   hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
+  data, g762_groups);
+   if (IS_ERR(hwmon_dev)) {
+   ret = PTR_ERR(hwmon_dev);
goto clock_dis;
}
 
@@ -1101,23 +1110,12 @@ static int g762_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
return ret;
 }
 
-static int g762_remove(struct i2c_client *client)
-{
-   struct g762_data *data = i2c_get_clientdata(client);
-
-   hwmon_device_unregister(data->hwmon_dev);
-   g762_of_clock_disable(client);
-
-   return 0;
-}
-
 static struct i2c_driver g762_driver = {
.driver = {
.name = DRVNAME,
.of_match_table = of_match_ptr(g762_dt_match),
},
.probe= g762_probe,
-   .remove   = g762_remove,
.id_table = g762_id,
 };
 
-- 
1.8.3.1



[PATCH] hwmon: g762: handle cleanup with devm_add_action

2018-02-27 Thread Peng Hao
Simplify code and use devm_add_action() to handle cleanup.

Signed-off-by: Peng Hao 
---
 drivers/hwmon/g762.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
index 6d1208b..48e60d8 100644
--- a/drivers/hwmon/g762.c
+++ b/drivers/hwmon/g762.c
@@ -128,7 +128,6 @@ enum g762_regs {
 G762_REG_FAN_CMD2_GEAR_MODE_1)) >> 2))
 
 struct g762_data {
-   struct device *hwmon_dev;
struct i2c_client *client;
struct clk *clk;
 
@@ -1051,9 +1050,17 @@ static inline int g762_fan_init(struct device *dev)
 data->fan_cmd1);
 }
 
+static void g762_remove(void *data)
+{
+   struct g762_data *g762 = data;
+   struct i2c_client *client = g762->client;
+
+   g762_of_clock_disable(client);
+}
 static int g762_probe(struct i2c_client *client, const struct i2c_device_id 
*id)
 {
struct device *dev = >dev;
+   struct device *hwmon_dev;
struct g762_data *data;
int ret;
 
@@ -1086,10 +1093,12 @@ static int g762_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
if (ret)
goto clock_dis;
 
-   data->hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
-   data, g762_groups);
-   if (IS_ERR(data->hwmon_dev)) {
-   ret = PTR_ERR(data->hwmon_dev);
+   devm_add_action(dev, g762_remove, data);
+
+   hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
+  data, g762_groups);
+   if (IS_ERR(hwmon_dev)) {
+   ret = PTR_ERR(hwmon_dev);
goto clock_dis;
}
 
@@ -1101,23 +1110,12 @@ static int g762_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
return ret;
 }
 
-static int g762_remove(struct i2c_client *client)
-{
-   struct g762_data *data = i2c_get_clientdata(client);
-
-   hwmon_device_unregister(data->hwmon_dev);
-   g762_of_clock_disable(client);
-
-   return 0;
-}
-
 static struct i2c_driver g762_driver = {
.driver = {
.name = DRVNAME,
.of_match_table = of_match_ptr(g762_dt_match),
},
.probe= g762_probe,
-   .remove   = g762_remove,
.id_table = g762_id,
 };
 
-- 
1.8.3.1



Re: [PATCH v2 06/16] drm/sun4i: Don't process LVDS if TCON doesn't support it

2018-02-27 Thread Maxime Ripard
On Tue, Feb 27, 2018 at 11:26:51PM +0100, Jernej Skrabec wrote:
> TCON checks for LVDS properties even if it doesn't support it. Add a
> check to skip that part of the code if TCON doesn't support channel 0.
> 
> Signed-off-by: Jernej Skrabec 

I have already sent a similar patch here:
https://lists.freedesktop.org/archives/dri-devel/2018-February/15.html

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v2 06/16] drm/sun4i: Don't process LVDS if TCON doesn't support it

2018-02-27 Thread Maxime Ripard
On Tue, Feb 27, 2018 at 11:26:51PM +0100, Jernej Skrabec wrote:
> TCON checks for LVDS properties even if it doesn't support it. Add a
> check to skip that part of the code if TCON doesn't support channel 0.
> 
> Signed-off-by: Jernej Skrabec 

I have already sent a similar patch here:
https://lists.freedesktop.org/archives/dri-devel/2018-February/15.html

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v2 01/16] clk: sunxi-ng: Add check for minimal rate to NM PLLs

2018-02-27 Thread Maxime Ripard
Hi,

On Tue, Feb 27, 2018 at 11:26:46PM +0100, Jernej Skrabec wrote:
> Some NM PLLs doesn't work well when their output clock rate is set below
> certain rate.
> 
> Add support for that constrain.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/clk/sunxi-ng/ccu_nm.c | 11 +++
>  drivers/clk/sunxi-ng/ccu_nm.h | 27 +++
>  2 files changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
> index a16de092bf94..7fc743c78c1b 100644
> --- a/drivers/clk/sunxi-ng/ccu_nm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nm.c
> @@ -20,7 +20,7 @@ struct _ccu_nm {
>  };
>  
>  static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
> -  struct _ccu_nm *nm)
> +  unsigned long min_rate, struct _ccu_nm *nm)
>  {
>   unsigned long best_rate = 0;
>   unsigned long best_n = 0, best_m = 0;
> @@ -30,7 +30,7 @@ static void ccu_nm_find_best(unsigned long parent, unsigned 
> long rate,
>   for (_m = nm->min_m; _m <= nm->max_m; _m++) {
>   unsigned long tmp_rate = parent * _n  / _m;
>  
> - if (tmp_rate > rate)
> + if (tmp_rate > rate || tmp_rate < min_rate)
>   continue;
>  
>   if ((rate - tmp_rate) < (rate - best_rate)) {
> @@ -117,6 +117,9 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned 
> long rate,
>   if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
>   rate *= nm->fixed_post_div;
>  
> + if (rate < nm->min_rate)
> + rate = nm->min_rate;
> +

I guess you can just return there. There's no point in trying to find
the factors at this point, since the minimum should be a value that
can be reached.

>   if (ccu_frac_helper_has_rate(>common, >frac, rate)) {
>   if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
>   rate /= nm->fixed_post_div;
> @@ -134,7 +137,7 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned 
> long rate,
>   _nm.min_m = 1;
>   _nm.max_m = nm->m.max ?: 1 << nm->m.width;
>  
> - ccu_nm_find_best(*parent_rate, rate, &_nm);
> + ccu_nm_find_best(*parent_rate, rate, nm->min_rate, &_nm);

Therefore, you don't need to change the prototype there either.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v2 01/16] clk: sunxi-ng: Add check for minimal rate to NM PLLs

2018-02-27 Thread Maxime Ripard
Hi,

On Tue, Feb 27, 2018 at 11:26:46PM +0100, Jernej Skrabec wrote:
> Some NM PLLs doesn't work well when their output clock rate is set below
> certain rate.
> 
> Add support for that constrain.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/clk/sunxi-ng/ccu_nm.c | 11 +++
>  drivers/clk/sunxi-ng/ccu_nm.h | 27 +++
>  2 files changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
> index a16de092bf94..7fc743c78c1b 100644
> --- a/drivers/clk/sunxi-ng/ccu_nm.c
> +++ b/drivers/clk/sunxi-ng/ccu_nm.c
> @@ -20,7 +20,7 @@ struct _ccu_nm {
>  };
>  
>  static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
> -  struct _ccu_nm *nm)
> +  unsigned long min_rate, struct _ccu_nm *nm)
>  {
>   unsigned long best_rate = 0;
>   unsigned long best_n = 0, best_m = 0;
> @@ -30,7 +30,7 @@ static void ccu_nm_find_best(unsigned long parent, unsigned 
> long rate,
>   for (_m = nm->min_m; _m <= nm->max_m; _m++) {
>   unsigned long tmp_rate = parent * _n  / _m;
>  
> - if (tmp_rate > rate)
> + if (tmp_rate > rate || tmp_rate < min_rate)
>   continue;
>  
>   if ((rate - tmp_rate) < (rate - best_rate)) {
> @@ -117,6 +117,9 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned 
> long rate,
>   if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
>   rate *= nm->fixed_post_div;
>  
> + if (rate < nm->min_rate)
> + rate = nm->min_rate;
> +

I guess you can just return there. There's no point in trying to find
the factors at this point, since the minimum should be a value that
can be reached.

>   if (ccu_frac_helper_has_rate(>common, >frac, rate)) {
>   if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
>   rate /= nm->fixed_post_div;
> @@ -134,7 +137,7 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned 
> long rate,
>   _nm.min_m = 1;
>   _nm.max_m = nm->m.max ?: 1 << nm->m.width;
>  
> - ccu_nm_find_best(*parent_rate, rate, &_nm);
> + ccu_nm_find_best(*parent_rate, rate, nm->min_rate, &_nm);

Therefore, you don't need to change the prototype there either.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature


Re: [PATCH v2 4/4] pintcrl: support bias-disable of generic and special pins simultaneously

2018-02-27 Thread Sean Wang
On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> For generic pins, parameter "arg" is 0 or 1.
> For special pins, bias-disable is set by R0R1,
> so we need transmited "00" to set bias-disable
> When we set "bias-disable" as high-z property,
> the parameter should be "MTK_PUPD_SET_R1R0_00".
> 
> Signed-off-by: Zhiyong Tao 
> ---
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index 3cf384f..e88ba04 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> @@ -301,8 +301,17 @@ static int mtk_pconf_set_pull_select(struct mtk_pinctrl 
> *pctl,
>* resistor bit, so we need this special handle.
>*/
>   if (pctl->devdata->spec_pull_set) {
> - ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
> - pin, pctl->devdata->port_align, isup, arg);
> + if (enable) {
> + ret = pctl->devdata->spec_pull_set(
> + mtk_get_regmap(pctl, pin), pin,
> + pctl->devdata->port_align, isup,
> + arg);
> + } else {
> + ret = pctl->devdata->spec_pull_set(
> + mtk_get_regmap(pctl, pin), pin,
> + pctl->devdata->port_align, isup,
> + MTK_PUPD_SET_R1R0_00);
> + }


it looks like you can use as following snippet with reusing original
logic and less effort on maintaining these common code (?)


if (pctl->devdata->spec_pull_set) {
+ if (!enable)
+   arg = MTK_PUPD_SET_R1R0_00;

ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
pin, pctl->devdata->port_align, isup, arg);


Also, it's better to add more comments to such kind of special path for
allowing future SoCs to follow and extend more easily.

>   if (!ret)
>   return 0;
>   }




Re: [PATCH v2 4/4] pintcrl: support bias-disable of generic and special pins simultaneously

2018-02-27 Thread Sean Wang
On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> For generic pins, parameter "arg" is 0 or 1.
> For special pins, bias-disable is set by R0R1,
> so we need transmited "00" to set bias-disable
> When we set "bias-disable" as high-z property,
> the parameter should be "MTK_PUPD_SET_R1R0_00".
> 
> Signed-off-by: Zhiyong Tao 
> ---
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index 3cf384f..e88ba04 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> @@ -301,8 +301,17 @@ static int mtk_pconf_set_pull_select(struct mtk_pinctrl 
> *pctl,
>* resistor bit, so we need this special handle.
>*/
>   if (pctl->devdata->spec_pull_set) {
> - ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
> - pin, pctl->devdata->port_align, isup, arg);
> + if (enable) {
> + ret = pctl->devdata->spec_pull_set(
> + mtk_get_regmap(pctl, pin), pin,
> + pctl->devdata->port_align, isup,
> + arg);
> + } else {
> + ret = pctl->devdata->spec_pull_set(
> + mtk_get_regmap(pctl, pin), pin,
> + pctl->devdata->port_align, isup,
> + MTK_PUPD_SET_R1R0_00);
> + }


it looks like you can use as following snippet with reusing original
logic and less effort on maintaining these common code (?)


if (pctl->devdata->spec_pull_set) {
+ if (!enable)
+   arg = MTK_PUPD_SET_R1R0_00;

ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
pin, pctl->devdata->port_align, isup, arg);


Also, it's better to add more comments to such kind of special path for
allowing future SoCs to follow and extend more easily.

>   if (!ret)
>   return 0;
>   }




Re: [PATCH] ALSA: control: Fix a bunch of whitespace errors

2018-02-27 Thread Takashi Iwai
On Tue, 27 Feb 2018 18:29:54 +0100,
Richard Fitzgerald wrote:
> 
> Remove a bunch of trailing whitespace errors. They are
> fairly annoying if you have your editor set to strip trailing
> whitespace because you find you've introduced more changes
> than you were trying to make.
> 
> Signed-off-by: Richard Fitzgerald 

Applied, thanks.


Takashi


Re: [PATCH] ALSA: control: Fix a bunch of whitespace errors

2018-02-27 Thread Takashi Iwai
On Tue, 27 Feb 2018 18:29:54 +0100,
Richard Fitzgerald wrote:
> 
> Remove a bunch of trailing whitespace errors. They are
> fairly annoying if you have your editor set to strip trailing
> whitespace because you find you've introduced more changes
> than you were trying to make.
> 
> Signed-off-by: Richard Fitzgerald 

Applied, thanks.


Takashi


Re: [RFC PATCH] Take mmap_min_addr into account while choosing unmapped address for x86-64.

2018-02-27 Thread Michal Hocko
On Tue 27-02-18 16:27:29, Ilya Smith wrote:
> > 
> > mmap_min_addr handling is a bit mess... As you say, we would return
> > EPERM rather than ENOMEM which can be confusing but depleting the
> > address space like that is quite unlikely on 64b unless I am missing.
> > It is good to be in sync here with the generic implementation though,
> > IMO.
> > 
> 
> If we take a look on mm/mmap.c:
> #ifndef HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
> unsigned long
> arch_get_unmapped_area_topdown(
> …
>   if (len > TASK_SIZE - mmap_min_addr)
>   return -ENOMEM;
> …
>   info.low_limit = max(PAGE_SIZE, mmap_min_addr);
> 
> And this one looks like a generic implementation.
> But for many other architectures like arch/parisc/kernel/sys_parisc.c 
> or arch/x86/kernel/sys_x86_64.c
> 
>   info.low_limit = PAGE_SIZE;

Yeah, this is what I meant when saying that mmap_min_addr is a bit of a
mess. I am wondering whether the low_limit should be checked inside
vm_unmapped_area. We would still need some mmap_min_addr handling at
arch_get_unmapped_area_topdown layer which is still suboptimal but I do
not see an easy way around without reworking how the arch specific parts
are implemented currently.
-- 
Michal Hocko
SUSE Labs


Re: [RFC PATCH] Take mmap_min_addr into account while choosing unmapped address for x86-64.

2018-02-27 Thread Michal Hocko
On Tue 27-02-18 16:27:29, Ilya Smith wrote:
> > 
> > mmap_min_addr handling is a bit mess... As you say, we would return
> > EPERM rather than ENOMEM which can be confusing but depleting the
> > address space like that is quite unlikely on 64b unless I am missing.
> > It is good to be in sync here with the generic implementation though,
> > IMO.
> > 
> 
> If we take a look on mm/mmap.c:
> #ifndef HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
> unsigned long
> arch_get_unmapped_area_topdown(
> …
>   if (len > TASK_SIZE - mmap_min_addr)
>   return -ENOMEM;
> …
>   info.low_limit = max(PAGE_SIZE, mmap_min_addr);
> 
> And this one looks like a generic implementation.
> But for many other architectures like arch/parisc/kernel/sys_parisc.c 
> or arch/x86/kernel/sys_x86_64.c
> 
>   info.low_limit = PAGE_SIZE;

Yeah, this is what I meant when saying that mmap_min_addr is a bit of a
mess. I am wondering whether the low_limit should be checked inside
vm_unmapped_area. We would still need some mmap_min_addr handling at
arch_get_unmapped_area_topdown layer which is still suboptimal but I do
not see an easy way around without reworking how the arch specific parts
are implemented currently.
-- 
Michal Hocko
SUSE Labs


Re: [PATCH v2 3/4] pinctrl: add mt2712 pinctrl driver

2018-02-27 Thread Sean Wang

Hi, Zhiyong

all seems better than v1, but some nitpicking is addressed as below 

Sean

On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> The commit includes mt2712 pinctrl driver.
> 
> Signed-off-by: Zhiyong Tao 
> ---
>  drivers/pinctrl/mediatek/Kconfig  |7 +
>  drivers/pinctrl/mediatek/Makefile |1 +
>  drivers/pinctrl/mediatek/pinctrl-mt2712.c |  639 
>  drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1973 
> +
>  4 files changed, 2620 insertions(+)
>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> 
> diff --git a/drivers/pinctrl/mediatek/Kconfig 
> b/drivers/pinctrl/mediatek/Kconfig
> index 3e59874..b24bc76 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -32,6 +32,13 @@ config PINCTRL_MT8127
>   select PINCTRL_MTK
>  
>  # For ARMv8 SoCs
> +config PINCTRL_MT2712
> + bool "Mediatek MT2712 pin control"


should be MediaTek for normal

> + depends on OF
> + depends on ARM64 || COMPILE_TEST
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK
> +
>  config PINCTRL_MT7622
>   bool "MediaTek MT7622 pin control"
>   depends on OF
> diff --git a/drivers/pinctrl/mediatek/Makefile 
> b/drivers/pinctrl/mediatek/Makefile
> index ed7d2b2..7959e77 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_PINCTRL_MTK) += pinctrl-mtk-common.o
>  
>  # SoC Drivers
>  obj-$(CONFIG_PINCTRL_MT2701) += pinctrl-mt2701.o
> +obj-$(CONFIG_PINCTRL_MT2712) += pinctrl-mt2712.o
>  obj-$(CONFIG_PINCTRL_MT8135) += pinctrl-mt8135.o
>  obj-$(CONFIG_PINCTRL_MT8127) += pinctrl-mt8127.o
>  obj-$(CONFIG_PINCTRL_MT7622) += pinctrl-mt7622.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c 
> b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> new file mode 100644
> index 000..b6ae71b
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> @@ -0,0 +1,639 @@
> +/*
> + * Copyright (c) 2014-2015 MediaTek Inc.
> + * Author: Hongzhou.Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +

suggest to consider more on using SPDX identifiers and
using right data for both fields Copyright and Author

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-mtk-common.h"
> +#include "pinctrl-mtk-mt2712.h"
> +

<...>

> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h 
> b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> new file mode 100644
> index 000..71f4190
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> @@ -0,0 +1,1973 @@
> +/*
> + * Copyright (C) 2015 MediaTek Inc.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */

Ditto 

> +#ifndef PINCTRL_MTK_MT2712_H
> +#define PINCTRL_MTK_MT2712_H
> +

<...>

> +
> +#endif /* __PINCTRL_MTK_MT2712_H */




Re: [PATCH v2 3/4] pinctrl: add mt2712 pinctrl driver

2018-02-27 Thread Sean Wang

Hi, Zhiyong

all seems better than v1, but some nitpicking is addressed as below 

Sean

On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote:
> The commit includes mt2712 pinctrl driver.
> 
> Signed-off-by: Zhiyong Tao 
> ---
>  drivers/pinctrl/mediatek/Kconfig  |7 +
>  drivers/pinctrl/mediatek/Makefile |1 +
>  drivers/pinctrl/mediatek/pinctrl-mt2712.c |  639 
>  drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1973 
> +
>  4 files changed, 2620 insertions(+)
>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> 
> diff --git a/drivers/pinctrl/mediatek/Kconfig 
> b/drivers/pinctrl/mediatek/Kconfig
> index 3e59874..b24bc76 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -32,6 +32,13 @@ config PINCTRL_MT8127
>   select PINCTRL_MTK
>  
>  # For ARMv8 SoCs
> +config PINCTRL_MT2712
> + bool "Mediatek MT2712 pin control"


should be MediaTek for normal

> + depends on OF
> + depends on ARM64 || COMPILE_TEST
> + default ARM64 && ARCH_MEDIATEK
> + select PINCTRL_MTK
> +
>  config PINCTRL_MT7622
>   bool "MediaTek MT7622 pin control"
>   depends on OF
> diff --git a/drivers/pinctrl/mediatek/Makefile 
> b/drivers/pinctrl/mediatek/Makefile
> index ed7d2b2..7959e77 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_PINCTRL_MTK) += pinctrl-mtk-common.o
>  
>  # SoC Drivers
>  obj-$(CONFIG_PINCTRL_MT2701) += pinctrl-mt2701.o
> +obj-$(CONFIG_PINCTRL_MT2712) += pinctrl-mt2712.o
>  obj-$(CONFIG_PINCTRL_MT8135) += pinctrl-mt8135.o
>  obj-$(CONFIG_PINCTRL_MT8127) += pinctrl-mt8127.o
>  obj-$(CONFIG_PINCTRL_MT7622) += pinctrl-mt7622.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c 
> b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> new file mode 100644
> index 000..b6ae71b
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
> @@ -0,0 +1,639 @@
> +/*
> + * Copyright (c) 2014-2015 MediaTek Inc.
> + * Author: Hongzhou.Yang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +

suggest to consider more on using SPDX identifiers and
using right data for both fields Copyright and Author

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-mtk-common.h"
> +#include "pinctrl-mtk-mt2712.h"
> +

<...>

> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h 
> b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> new file mode 100644
> index 000..71f4190
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
> @@ -0,0 +1,1973 @@
> +/*
> + * Copyright (C) 2015 MediaTek Inc.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */

Ditto 

> +#ifndef PINCTRL_MTK_MT2712_H
> +#define PINCTRL_MTK_MT2712_H
> +

<...>

> +
> +#endif /* __PINCTRL_MTK_MT2712_H */




Re: [PATCH 4.14 00/54] 4.14.23-stable review

2018-02-27 Thread Greg Kroah-Hartman
On Tue, Feb 27, 2018 at 03:12:02PM -0800, Guenter Roeck wrote:
> On Tue, Feb 27, 2018 at 07:36:18PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Feb 27, 2018 at 06:38:59AM -0800, Guenter Roeck wrote:
> > > On 02/27/2018 05:08 AM, Greg Kroah-Hartman wrote:
> > > > On Tue, Feb 27, 2018 at 02:59:39AM -0800, Guenter Roeck wrote:
> > > > > On 02/26/2018 12:21 PM, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 4.14.23 
> > > > > > release.
> > > > > > There are 54 patches in this series, all will be posted as a 
> > > > > > response
> > > > > > to this one.  If anyone has any issues with these being applied, 
> > > > > > please
> > > > > > let me know.
> > > > > > 
> > > > > > Responses should be made by Wed Feb 28 20:21:22 UTC 2018.
> > > > > > Anything received after that time might be too late.
> > > > > > 
> > > > > 
> > > > > microblaze, m32r:
> > > > > 
> > > > > include/linux/byteorder/big_endian.h:8:2: warning: #warning 
> > > > > inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
> > > > >   #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
> > > > >^~~
> > > > > /opt/buildbot/slave/stable-queue-4.14/build/lib/find_bit.c:176:15: 
> > > > > error: redefinition of ‘find_next_zero_bit_le’
> > > > > 
> > > > > v4.15 is also affected (m32r builds in v4.15, though, for some 
> > > > > reason).
> > > > 
> > > > This sounds like Arnd's Kbuild change 101110f6271c ("Kbuild: always
> > > > define endianess in kconfig.h")
> > > > 
> > > > Does this problem also show up in Linus's tree?
> > > > 
> > > > Arnd, any ideas?
> > > > 
> > > 
> > > Missing for m32r: c95f121142a41c951fd62683a5574f2a7b37c573
> > > Missing for microblaze: 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f
> > 
> > Thanks, both queued up, and I've pushed out new 4.14.y and 4.15.y trees.
> > 
> All builds are confirmed clean. Tested:
> 
> v3.18.96-13-g98f6a49
> v4.4.118-22-ge62da23
> v4.9.84-40-g8a6c3b0
> v4.14.22-57-g02ee682
> v4.15.6-66-g53e92b3

Wonderful, thanks for testing all of this and letting me know.

greg k-h


Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

2018-02-27 Thread Pavel Emelyanov
On 02/27/2018 05:18 AM, Dmitry V. Levin wrote:
> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
>> On 02/21/2018 03:44 AM, Andrew Morton wrote:
>>> On Tue,  9 Jan 2018 08:30:49 +0200 Mike Rapoport  
>>> wrote:
>>>
 This patches introduces new process_vmsplice system call that combines
 functionality of process_vm_read and vmsplice.
>>>
>>> All seems fairly strightforward.  The big question is: do we know that
>>> people will actually use this, and get sufficient value from it to
>>> justify its addition?
>>
>> Yes, that's what bothers us a lot too :) I've tried to start with finding 
>> out if anyone 
>> used the sys_read/write_process_vm() calls, but failed :( Does anybody know 
>> how popular
>> these syscalls are?
> 
> Well, process_vm_readv itself is quite popular, it's used by debuggers 
> nowadays,
> see e.g.
> $ strace -qq -esignal=none -eprocess_vm_readv strace -qq -o/dev/null cat 
> /dev/null

I see. Well, yes, this use-case will not benefit much from remote splice. How 
about more
interactive debug by, say, gdb? It may attach, then splice all the memory, then 
analyze
the victim code/data w/o copying it to its address space?

-- Pavel


Re: [PATCH 4.14 00/54] 4.14.23-stable review

2018-02-27 Thread Greg Kroah-Hartman
On Tue, Feb 27, 2018 at 03:12:02PM -0800, Guenter Roeck wrote:
> On Tue, Feb 27, 2018 at 07:36:18PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Feb 27, 2018 at 06:38:59AM -0800, Guenter Roeck wrote:
> > > On 02/27/2018 05:08 AM, Greg Kroah-Hartman wrote:
> > > > On Tue, Feb 27, 2018 at 02:59:39AM -0800, Guenter Roeck wrote:
> > > > > On 02/26/2018 12:21 PM, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 4.14.23 
> > > > > > release.
> > > > > > There are 54 patches in this series, all will be posted as a 
> > > > > > response
> > > > > > to this one.  If anyone has any issues with these being applied, 
> > > > > > please
> > > > > > let me know.
> > > > > > 
> > > > > > Responses should be made by Wed Feb 28 20:21:22 UTC 2018.
> > > > > > Anything received after that time might be too late.
> > > > > > 
> > > > > 
> > > > > microblaze, m32r:
> > > > > 
> > > > > include/linux/byteorder/big_endian.h:8:2: warning: #warning 
> > > > > inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
> > > > >   #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
> > > > >^~~
> > > > > /opt/buildbot/slave/stable-queue-4.14/build/lib/find_bit.c:176:15: 
> > > > > error: redefinition of ‘find_next_zero_bit_le’
> > > > > 
> > > > > v4.15 is also affected (m32r builds in v4.15, though, for some 
> > > > > reason).
> > > > 
> > > > This sounds like Arnd's Kbuild change 101110f6271c ("Kbuild: always
> > > > define endianess in kconfig.h")
> > > > 
> > > > Does this problem also show up in Linus's tree?
> > > > 
> > > > Arnd, any ideas?
> > > > 
> > > 
> > > Missing for m32r: c95f121142a41c951fd62683a5574f2a7b37c573
> > > Missing for microblaze: 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f
> > 
> > Thanks, both queued up, and I've pushed out new 4.14.y and 4.15.y trees.
> > 
> All builds are confirmed clean. Tested:
> 
> v3.18.96-13-g98f6a49
> v4.4.118-22-ge62da23
> v4.9.84-40-g8a6c3b0
> v4.14.22-57-g02ee682
> v4.15.6-66-g53e92b3

Wonderful, thanks for testing all of this and letting me know.

greg k-h


Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

2018-02-27 Thread Pavel Emelyanov
On 02/27/2018 05:18 AM, Dmitry V. Levin wrote:
> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
>> On 02/21/2018 03:44 AM, Andrew Morton wrote:
>>> On Tue,  9 Jan 2018 08:30:49 +0200 Mike Rapoport  
>>> wrote:
>>>
 This patches introduces new process_vmsplice system call that combines
 functionality of process_vm_read and vmsplice.
>>>
>>> All seems fairly strightforward.  The big question is: do we know that
>>> people will actually use this, and get sufficient value from it to
>>> justify its addition?
>>
>> Yes, that's what bothers us a lot too :) I've tried to start with finding 
>> out if anyone 
>> used the sys_read/write_process_vm() calls, but failed :( Does anybody know 
>> how popular
>> these syscalls are?
> 
> Well, process_vm_readv itself is quite popular, it's used by debuggers 
> nowadays,
> see e.g.
> $ strace -qq -esignal=none -eprocess_vm_readv strace -qq -o/dev/null cat 
> /dev/null

I see. Well, yes, this use-case will not benefit much from remote splice. How 
about more
interactive debug by, say, gdb? It may attach, then splice all the memory, then 
analyze
the victim code/data w/o copying it to its address space?

-- Pavel


Re: [PATCH v2 07/11] firmware: split firmware fallback functionality into its own file

2018-02-27 Thread Greg KH
On Tue, Feb 27, 2018 at 09:33:28PM -0800, Kees Cook wrote:
> On Tue, Feb 27, 2018 at 5:28 PM, Luis R. Rodriguez  wrote:
> > On Tue, Feb 27, 2018 at 03:14:53PM -0800, Kees Cook wrote:
> >> On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez  
> >> wrote:
> >> > The firmware fallback code is optional. Split that code out to help
> >> > distinguish the fallback functionlity from othere core firmware loader
> >> > features. This should make it easier to maintain and review code
> >> > changes.
> >> >
> >> > The reason for keeping the configuration onto a table which is built-in
> >> > if you enable firmware loading is so that we can later enable the kernel
> >> > after subsequent patches to tweak this configuration, even if the
> >> > firmware loader is modular.
> >> >
> >> > This introduces no functional changes.
> >> >
> >> > Signed-off-by: Luis R. Rodriguez 
> >> > ---
> >> >  drivers/base/Makefile  |   4 +-
> >> >  drivers/base/firmware_fallback.c   | 661 +++
> >> >  drivers/base/firmware_fallback.h   |  61 +++
> >> >  drivers/base/firmware_fallback_table.c |  29 ++
> >> >  drivers/base/firmware_loader.c | 803 
> >> > +
> >> >  drivers/base/firmware_loader.h | 115 +
> >> >  6 files changed, 874 insertions(+), 799 deletions(-)
> >> >  create mode 100644 drivers/base/firmware_fallback.c
> >> >  create mode 100644 drivers/base/firmware_fallback.h
> >> >  create mode 100644 drivers/base/firmware_fallback_table.c
> >> >  create mode 100644 drivers/base/firmware_loader.h
> >>
> >> Does it make sense to have a separate subdirectory for firmware
> >> instead? I did this _ stuff with lkdtm and have regretted it. (I'm
> >> likely going to make a subdirectory for it this cycle...)
> >
> > Sure, the only eyesore is that drivers/base/firmware.c what is that for?
> >
> > drivers/base/firmware_loader/ ok?
> 
> Yeah? Seems fine to me. Greg, do you have thoughts on this?

I don't care :)


Re: [PATCH v2 07/11] firmware: split firmware fallback functionality into its own file

2018-02-27 Thread Greg KH
On Tue, Feb 27, 2018 at 09:33:28PM -0800, Kees Cook wrote:
> On Tue, Feb 27, 2018 at 5:28 PM, Luis R. Rodriguez  wrote:
> > On Tue, Feb 27, 2018 at 03:14:53PM -0800, Kees Cook wrote:
> >> On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez  
> >> wrote:
> >> > The firmware fallback code is optional. Split that code out to help
> >> > distinguish the fallback functionlity from othere core firmware loader
> >> > features. This should make it easier to maintain and review code
> >> > changes.
> >> >
> >> > The reason for keeping the configuration onto a table which is built-in
> >> > if you enable firmware loading is so that we can later enable the kernel
> >> > after subsequent patches to tweak this configuration, even if the
> >> > firmware loader is modular.
> >> >
> >> > This introduces no functional changes.
> >> >
> >> > Signed-off-by: Luis R. Rodriguez 
> >> > ---
> >> >  drivers/base/Makefile  |   4 +-
> >> >  drivers/base/firmware_fallback.c   | 661 +++
> >> >  drivers/base/firmware_fallback.h   |  61 +++
> >> >  drivers/base/firmware_fallback_table.c |  29 ++
> >> >  drivers/base/firmware_loader.c | 803 
> >> > +
> >> >  drivers/base/firmware_loader.h | 115 +
> >> >  6 files changed, 874 insertions(+), 799 deletions(-)
> >> >  create mode 100644 drivers/base/firmware_fallback.c
> >> >  create mode 100644 drivers/base/firmware_fallback.h
> >> >  create mode 100644 drivers/base/firmware_fallback_table.c
> >> >  create mode 100644 drivers/base/firmware_loader.h
> >>
> >> Does it make sense to have a separate subdirectory for firmware
> >> instead? I did this _ stuff with lkdtm and have regretted it. (I'm
> >> likely going to make a subdirectory for it this cycle...)
> >
> > Sure, the only eyesore is that drivers/base/firmware.c what is that for?
> >
> > drivers/base/firmware_loader/ ok?
> 
> Yeah? Seems fine to me. Greg, do you have thoughts on this?

I don't care :)


[PATCH] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

2018-02-27 Thread Yisheng Xie
ashmem_mutex may create a chain of dependencies like:

CPU0CPU1
 mmap syscall   ioctl syscall
 -> mmap_sem (acquired) -> ashmem_ioctl
 -> ashmem_mmap-> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire)   -> copy_from_user
  -> mmap_sem (try to acquire)

There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.

[1] https://www.spinics.net/lists/kernel/msg2733200.html

Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin 
ioctls)
Reported-by: syzbot+d7a918a7a8e1c952b...@syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie 
---
 drivers/staging/android/ashmem.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 6dbba5a..8c55706 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -702,16 +702,14 @@ static int ashmem_pin_unpin(struct ashmem_area *asma, 
unsigned long cmd,
size_t pgstart, pgend;
int ret = -EINVAL;
 
+   if (unlikely(copy_from_user(, p, sizeof(pin
+   return -EFAULT;
+
mutex_lock(_mutex);
 
if (unlikely(!asma->file))
goto out_unlock;
 
-   if (unlikely(copy_from_user(, p, sizeof(pin {
-   ret = -EFAULT;
-   goto out_unlock;
-   }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
-- 
1.7.12.4



[PATCH] staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

2018-02-27 Thread Yisheng Xie
ashmem_mutex may create a chain of dependencies like:

CPU0CPU1
 mmap syscall   ioctl syscall
 -> mmap_sem (acquired) -> ashmem_ioctl
 -> ashmem_mmap-> ashmem_mutex (acquired)
-> ashmem_mutex (try to acquire)   -> copy_from_user
  -> mmap_sem (try to acquire)

There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.

[1] https://www.spinics.net/lists/kernel/msg2733200.html

Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin 
ioctls)
Reported-by: syzbot+d7a918a7a8e1c952b...@syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie 
---
 drivers/staging/android/ashmem.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 6dbba5a..8c55706 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -702,16 +702,14 @@ static int ashmem_pin_unpin(struct ashmem_area *asma, 
unsigned long cmd,
size_t pgstart, pgend;
int ret = -EINVAL;
 
+   if (unlikely(copy_from_user(, p, sizeof(pin
+   return -EFAULT;
+
mutex_lock(_mutex);
 
if (unlikely(!asma->file))
goto out_unlock;
 
-   if (unlikely(copy_from_user(, p, sizeof(pin {
-   ret = -EFAULT;
-   goto out_unlock;
-   }
-
/* per custom, you can pass zero for len to mean "everything onward" */
if (!pin.len)
pin.len = PAGE_ALIGN(asma->size) - pin.offset;
-- 
1.7.12.4



Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations

2018-02-27 Thread Aneesh Kumar K.V

I also noticed that the slice mask printing use wrong variables now. I
guess this should take care of it

diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index fef3f36b0b73..6b3575c39668 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -535,8 +535,6 @@ unsigned long slice_get_unmapped_area(unsigned long addr, 
unsigned long len,
 * already
 */
maskp = slice_mask_for_size(mm, psize);
-   slice_print_mask(" good_mask", _mask);
-
/*
 * Here "good" means slices that are already the right page size,
 * "compat" means slices that have a compatible page size (i.e.
@@ -569,6 +567,8 @@ unsigned long slice_get_unmapped_area(unsigned long addr, 
unsigned long len,
{
slice_copy_mask(_mask, maskp, high_slices);
}
+   slice_print_mask(" good_mask", _mask);
+   slice_print_mask(" compat_mask", compat_maskp);
 
/* First check hint if it's valid or if we have MAP_FIXED */
if (addr || fixed) {
@@ -646,7 +646,7 @@ unsigned long slice_get_unmapped_area(unsigned long addr, 
unsigned long len,
 
slice_range_to_mask(addr, len, _mask, high_slices);
slice_dbg(" found potential area at 0x%lx\n", addr);
-   slice_print_mask(" mask", maskp);
+   slice_print_mask(" mask", _mask);
 
  convert:
slice_andnot_mask(_mask, _mask, _mask, 
high_slices);
@@ -836,13 +836,6 @@ int is_hugepage_only_range(struct mm_struct *mm, unsigned 
long addr,
return !slice_check_range_fits(mm, , addr, len);
}
 #endif
-
-#if 0 /* too verbose */
-   slice_dbg("is_hugepage_only_range(mm=%p, addr=%lx, len=%lx)\n",
-mm, addr, len);
-   slice_print_mask(" mask", );
-   slice_print_mask(" available", );
-#endif
return !slice_check_range_fits(mm, maskp, addr, len);
 }
 #endif



Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations

2018-02-27 Thread Aneesh Kumar K.V

I also noticed that the slice mask printing use wrong variables now. I
guess this should take care of it

diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index fef3f36b0b73..6b3575c39668 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -535,8 +535,6 @@ unsigned long slice_get_unmapped_area(unsigned long addr, 
unsigned long len,
 * already
 */
maskp = slice_mask_for_size(mm, psize);
-   slice_print_mask(" good_mask", _mask);
-
/*
 * Here "good" means slices that are already the right page size,
 * "compat" means slices that have a compatible page size (i.e.
@@ -569,6 +567,8 @@ unsigned long slice_get_unmapped_area(unsigned long addr, 
unsigned long len,
{
slice_copy_mask(_mask, maskp, high_slices);
}
+   slice_print_mask(" good_mask", _mask);
+   slice_print_mask(" compat_mask", compat_maskp);
 
/* First check hint if it's valid or if we have MAP_FIXED */
if (addr || fixed) {
@@ -646,7 +646,7 @@ unsigned long slice_get_unmapped_area(unsigned long addr, 
unsigned long len,
 
slice_range_to_mask(addr, len, _mask, high_slices);
slice_dbg(" found potential area at 0x%lx\n", addr);
-   slice_print_mask(" mask", maskp);
+   slice_print_mask(" mask", _mask);
 
  convert:
slice_andnot_mask(_mask, _mask, _mask, 
high_slices);
@@ -836,13 +836,6 @@ int is_hugepage_only_range(struct mm_struct *mm, unsigned 
long addr,
return !slice_check_range_fits(mm, , addr, len);
}
 #endif
-
-#if 0 /* too verbose */
-   slice_dbg("is_hugepage_only_range(mm=%p, addr=%lx, len=%lx)\n",
-mm, addr, len);
-   slice_print_mask(" mask", );
-   slice_print_mask(" available", );
-#endif
return !slice_check_range_fits(mm, maskp, addr, len);
 }
 #endif



[PATCH v2] nvme-multipath: fix sysfs dangerously created links

2018-02-27 Thread Baegjae Sung
If multipathing is enabled, each NVMe subsystem creates a head
namespace (e.g., nvme0n1) and multiple private namespaces
(e.g., nvme0c0n1 and nvme0c1n1) in sysfs. When creating links for
private namespaces, links of head namespace are used, so the
namespace creation order must be followed (e.g., nvme0n1 ->
nvme0c1n1). If the order is not followed, links of sysfs will be
incomplete or kernel panic will occur.

The kernel panic was:
  kernel BUG at fs/sysfs/symlink.c:27!
  Call Trace:
nvme_mpath_add_disk_links+0x5d/0x80 [nvme_core]
nvme_validate_ns+0x5c2/0x850 [nvme_core]
nvme_scan_work+0x1af/0x2d0 [nvme_core]

Correct order
Context A Context B
nvme0n1
nvme0c0n1 nvme0c1n1

Incorrect order
Context A Context B
  nvme0c1n1
nvme0n1
nvme0c0n1

The nvme_mpath_add_disk (for creating head namespace) is called
just before the nvme_mpath_add_disk_links (for creating private
namespaces). In nvme_mpath_add_disk, the first context acquires
the lock of subsystem and creates a head namespace, and other
contexts do nothing by checking GENHD_FL_UP of a head namespace
after waiting to acquire the lock. We verified the code with or
without multipathing using three vendors of dual-port NVMe SSDs.

Signed-off-by: Baegjae Sung 
---
 drivers/nvme/host/core.c  | 12 +++-
 drivers/nvme/host/multipath.c | 15 ++-
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 0fe7ea35c221..817e5e2766da 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2844,7 +2844,7 @@ static struct nvme_ns_head *nvme_alloc_ns_head(struct 
nvme_ctrl *ctrl,
 }
 
 static int nvme_init_ns_head(struct nvme_ns *ns, unsigned nsid,
-   struct nvme_id_ns *id, bool *new)
+   struct nvme_id_ns *id)
 {
struct nvme_ctrl *ctrl = ns->ctrl;
bool is_shared = id->nmic & (1 << 0);
@@ -2860,8 +2860,6 @@ static int nvme_init_ns_head(struct nvme_ns *ns, unsigned 
nsid,
ret = PTR_ERR(head);
goto out_unlock;
}
-
-   *new = true;
} else {
struct nvme_ns_ids ids;
 
@@ -2873,8 +2871,6 @@ static int nvme_init_ns_head(struct nvme_ns *ns, unsigned 
nsid,
ret = -EINVAL;
goto out_unlock;
}
-
-   *new = false;
}
 
list_add_tail(>siblings, >list);
@@ -2945,7 +2941,6 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, 
unsigned nsid)
struct nvme_id_ns *id;
char disk_name[DISK_NAME_LEN];
int node = dev_to_node(ctrl->dev), flags = GENHD_FL_EXT_DEVT;
-   bool new = true;
 
ns = kzalloc_node(sizeof(*ns), GFP_KERNEL, node);
if (!ns)
@@ -2971,7 +2966,7 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, 
unsigned nsid)
if (id->ncap == 0)
goto out_free_id;
 
-   if (nvme_init_ns_head(ns, nsid, id, ))
+   if (nvme_init_ns_head(ns, nsid, id))
goto out_free_id;
nvme_setup_streams_ns(ctrl, ns);

@@ -3037,8 +3032,7 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, 
unsigned nsid)
pr_warn("%s: failed to register lightnvm sysfs group for 
identification\n",
ns->disk->disk_name);
 
-   if (new)
-   nvme_mpath_add_disk(ns->head);
+   nvme_mpath_add_disk(ns->head);
nvme_mpath_add_disk_links(ns);
return;
  out_unlink_ns:
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 3b211d9e58b8..b7e5c6db4d92 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -198,11 +198,16 @@ void nvme_mpath_add_disk(struct nvme_ns_head *head)
 {
if (!head->disk)
return;
-   device_add_disk(>subsys->dev, head->disk);
-   if (sysfs_create_group(_to_dev(head->disk)->kobj,
-   _ns_id_attr_group))
-   pr_warn("%s: failed to create sysfs group for identification\n",
-   head->disk->disk_name);
+
+   mutex_lock(>subsys->lock);
+   if (!(head->disk->flags & GENHD_FL_UP)) {
+   device_add_disk(>subsys->dev, head->disk);
+   if (sysfs_create_group(_to_dev(head->disk)->kobj,
+   _ns_id_attr_group))
+   pr_warn("%s: failed to create sysfs group for 
identification\n",
+   head->disk->disk_name);
+   }
+   mutex_unlock(>subsys->lock);
 }
 
 void nvme_mpath_add_disk_links(struct nvme_ns *ns)
-- 
2.16.2



[PATCH v2] nvme-multipath: fix sysfs dangerously created links

2018-02-27 Thread Baegjae Sung
If multipathing is enabled, each NVMe subsystem creates a head
namespace (e.g., nvme0n1) and multiple private namespaces
(e.g., nvme0c0n1 and nvme0c1n1) in sysfs. When creating links for
private namespaces, links of head namespace are used, so the
namespace creation order must be followed (e.g., nvme0n1 ->
nvme0c1n1). If the order is not followed, links of sysfs will be
incomplete or kernel panic will occur.

The kernel panic was:
  kernel BUG at fs/sysfs/symlink.c:27!
  Call Trace:
nvme_mpath_add_disk_links+0x5d/0x80 [nvme_core]
nvme_validate_ns+0x5c2/0x850 [nvme_core]
nvme_scan_work+0x1af/0x2d0 [nvme_core]

Correct order
Context A Context B
nvme0n1
nvme0c0n1 nvme0c1n1

Incorrect order
Context A Context B
  nvme0c1n1
nvme0n1
nvme0c0n1

The nvme_mpath_add_disk (for creating head namespace) is called
just before the nvme_mpath_add_disk_links (for creating private
namespaces). In nvme_mpath_add_disk, the first context acquires
the lock of subsystem and creates a head namespace, and other
contexts do nothing by checking GENHD_FL_UP of a head namespace
after waiting to acquire the lock. We verified the code with or
without multipathing using three vendors of dual-port NVMe SSDs.

Signed-off-by: Baegjae Sung 
---
 drivers/nvme/host/core.c  | 12 +++-
 drivers/nvme/host/multipath.c | 15 ++-
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 0fe7ea35c221..817e5e2766da 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2844,7 +2844,7 @@ static struct nvme_ns_head *nvme_alloc_ns_head(struct 
nvme_ctrl *ctrl,
 }
 
 static int nvme_init_ns_head(struct nvme_ns *ns, unsigned nsid,
-   struct nvme_id_ns *id, bool *new)
+   struct nvme_id_ns *id)
 {
struct nvme_ctrl *ctrl = ns->ctrl;
bool is_shared = id->nmic & (1 << 0);
@@ -2860,8 +2860,6 @@ static int nvme_init_ns_head(struct nvme_ns *ns, unsigned 
nsid,
ret = PTR_ERR(head);
goto out_unlock;
}
-
-   *new = true;
} else {
struct nvme_ns_ids ids;
 
@@ -2873,8 +2871,6 @@ static int nvme_init_ns_head(struct nvme_ns *ns, unsigned 
nsid,
ret = -EINVAL;
goto out_unlock;
}
-
-   *new = false;
}
 
list_add_tail(>siblings, >list);
@@ -2945,7 +2941,6 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, 
unsigned nsid)
struct nvme_id_ns *id;
char disk_name[DISK_NAME_LEN];
int node = dev_to_node(ctrl->dev), flags = GENHD_FL_EXT_DEVT;
-   bool new = true;
 
ns = kzalloc_node(sizeof(*ns), GFP_KERNEL, node);
if (!ns)
@@ -2971,7 +2966,7 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, 
unsigned nsid)
if (id->ncap == 0)
goto out_free_id;
 
-   if (nvme_init_ns_head(ns, nsid, id, ))
+   if (nvme_init_ns_head(ns, nsid, id))
goto out_free_id;
nvme_setup_streams_ns(ctrl, ns);

@@ -3037,8 +3032,7 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, 
unsigned nsid)
pr_warn("%s: failed to register lightnvm sysfs group for 
identification\n",
ns->disk->disk_name);
 
-   if (new)
-   nvme_mpath_add_disk(ns->head);
+   nvme_mpath_add_disk(ns->head);
nvme_mpath_add_disk_links(ns);
return;
  out_unlink_ns:
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 3b211d9e58b8..b7e5c6db4d92 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -198,11 +198,16 @@ void nvme_mpath_add_disk(struct nvme_ns_head *head)
 {
if (!head->disk)
return;
-   device_add_disk(>subsys->dev, head->disk);
-   if (sysfs_create_group(_to_dev(head->disk)->kobj,
-   _ns_id_attr_group))
-   pr_warn("%s: failed to create sysfs group for identification\n",
-   head->disk->disk_name);
+
+   mutex_lock(>subsys->lock);
+   if (!(head->disk->flags & GENHD_FL_UP)) {
+   device_add_disk(>subsys->dev, head->disk);
+   if (sysfs_create_group(_to_dev(head->disk)->kobj,
+   _ns_id_attr_group))
+   pr_warn("%s: failed to create sysfs group for 
identification\n",
+   head->disk->disk_name);
+   }
+   mutex_unlock(>subsys->lock);
 }
 
 void nvme_mpath_add_disk_links(struct nvme_ns *ns)
-- 
2.16.2



Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

2018-02-27 Thread Mikko Perttunen

On 02/28/2018 08:12 AM, Rajkumar Rampelli wrote:


On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 
+

  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer

new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It 
uses the
+generic PWM interface and can be used on SoCs as along as the SoC 
supports

+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan 
speed using
+PWM module and Tachometer controller. It requests period value 
through PWM
+capture interface to Tachometer and measures the Rotations per 
minute using
+received period value. It exposes the Fan speed in RPM to the user 
space by

+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
    If you say yes here you get support for the temperature
    and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
    comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    += wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o
    obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
    ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c

new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify it

+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but 
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of 
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
License for

+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct 
device_attribute *attr,

+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture result;
+    int err;
+    unsigned int rpm = 0;
+
+    err = pwm_capture(pwm, , 0);
+    if (err < 0) {
+    dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+    return err;
+    }
+
+    if (result.period)
+    rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+    result.period);
+
+    return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+    _dev_attr_rpm.dev_attr.attr,
+    NULL,
+};


"rpm" is not a standard hwmon sysfs attribute. If you don't provide
a single 

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

2018-02-27 Thread Mikko Perttunen

On 02/28/2018 08:12 AM, Rajkumar Rampelli wrote:


On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 
+

  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer

new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It 
uses the
+generic PWM interface and can be used on SoCs as along as the SoC 
supports

+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan 
speed using
+PWM module and Tachometer controller. It requests period value 
through PWM
+capture interface to Tachometer and measures the Rotations per 
minute using
+received period value. It exposes the Fan speed in RPM to the user 
space by

+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
    If you say yes here you get support for the temperature
    and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
    comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    += wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o
    obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
    ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c

new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or 
modify it

+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but 
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of 
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
License for

+ * more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct 
device_attribute *attr,

+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture result;
+    int err;
+    unsigned int rpm = 0;
+
+    err = pwm_capture(pwm, , 0);
+    if (err < 0) {
+    dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+    return err;
+    }
+
+    if (result.period)
+    rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+    result.period);
+
+    return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+    _dev_attr_rpm.dev_attr.attr,
+    NULL,
+};


"rpm" is not a standard hwmon sysfs attribute. If you don't provide
a single standard hwmon sysfs attribute, having a 

[PATCH] Documentation: Update ncurses package names for menuconfig

2018-02-27 Thread Arvind Prasanna
The package name is ncurses-devel for Redhat based distros
and libncurses-devel for Debian based distros.

Signed-off-by: Arvind Prasanna 
---
 scripts/kconfig/lxdialog/check-lxdialog.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh 
b/scripts/kconfig/lxdialog/check-lxdialog.sh
index a10bd9d..4353e40 100755
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -55,7 +55,8 @@ EOF
echo " *** required header files."1>&2
echo " *** 'make menuconfig' requires the ncurses libraries." 1>&2
echo " *** "  1>&2
-   echo " *** Install ncurses (ncurses-devel) and try again."1>&2
+   echo " *** Install ncurses (ncurses-devel or libncurses-dev   1>&2
+  *** depending on your distribution) and try again."1>&2
echo " *** "  1>&2
exit 1
fi
-- 
2.7.4



[PATCH] Documentation: Update ncurses package names for menuconfig

2018-02-27 Thread Arvind Prasanna
The package name is ncurses-devel for Redhat based distros
and libncurses-devel for Debian based distros.

Signed-off-by: Arvind Prasanna 
---
 scripts/kconfig/lxdialog/check-lxdialog.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh 
b/scripts/kconfig/lxdialog/check-lxdialog.sh
index a10bd9d..4353e40 100755
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -55,7 +55,8 @@ EOF
echo " *** required header files."1>&2
echo " *** 'make menuconfig' requires the ncurses libraries." 1>&2
echo " *** "  1>&2
-   echo " *** Install ncurses (ncurses-devel) and try again."1>&2
+   echo " *** Install ncurses (ncurses-devel or libncurses-dev   1>&2
+  *** depending on your distribution) and try again."1>&2
echo " *** "  1>&2
exit 1
fi
-- 
2.7.4



Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations

2018-02-27 Thread Aneesh Kumar K.V



On 02/28/2018 12:23 PM, Nicholas Piggin wrote:

On Tue, 27 Feb 2018 18:11:07 +0530
"Aneesh Kumar K.V"  wrote:


Nicholas Piggin  writes:


On Tue, 27 Feb 2018 14:31:07 +0530
"Aneesh Kumar K.V"  wrote:
  

Christophe Leroy  writes:
   

The number of high slices a process might use now depends on its
address space size, and what allocation address it has requested.

This patch uses that limit throughout call chains where possible,
rather than use the fixed SLICE_NUM_HIGH for bitmap operations.
This saves some cost for processes that don't use very large address
spaces.


I haven't really looked at the final code. One of the issue we had was
with the below scenario.

mmap(addr, len) where addr < 128TB and addr+len > 128TB  We want to make
sure we build the mask such that we don't find the addr available.


We should run it through the mmap regression tests. I *think* we moved
all of that logic from the slice code to get_ummapped_area before going
in to slices. I may have missed something though, it would be good to
have more eyes on it.
  


mmap(-1,...) failed with the test. Something like below fix it

@@ -756,7 +770,7 @@ void slice_set_user_psize(struct mm_struct *mm, unsigned 
int psize)
 mm->context.low_slices_psize = lpsizes;
  
 hpsizes = mm->context.high_slices_psize;

-   high_slices = GET_HIGH_SLICE_INDEX(mm->context.slb_addr_limit);
+   high_slices = SLICE_NUM_HIGH;
 for (i = 0; i < high_slices; i++) {
 mask_index = i & 0x1;
 index = i >> 1;

I guess for everything in the mm_context_t, we should compute it till
SLICE_NUM_HIGH. The reason for failure was, even though we recompute the
slice mask cached in mm_context on slb_addr_limit, it was still derived
from the high_slices_psizes which was computed with lower value.


Okay thanks for catching that Aneesh. I guess that's a slow path so it
should be okay. Christophe if you're taking care of the series can you
fold it in? Otherwise I'll do that after yours gets merged.



should we also compute the mm_context_t.slice_mask using SLICE_NUM_HIGH 
and skip the recalc_slice_mask_cache when we change the addr limit?


-aneesh



Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations

2018-02-27 Thread Aneesh Kumar K.V



On 02/28/2018 12:23 PM, Nicholas Piggin wrote:

On Tue, 27 Feb 2018 18:11:07 +0530
"Aneesh Kumar K.V"  wrote:


Nicholas Piggin  writes:


On Tue, 27 Feb 2018 14:31:07 +0530
"Aneesh Kumar K.V"  wrote:
  

Christophe Leroy  writes:
   

The number of high slices a process might use now depends on its
address space size, and what allocation address it has requested.

This patch uses that limit throughout call chains where possible,
rather than use the fixed SLICE_NUM_HIGH for bitmap operations.
This saves some cost for processes that don't use very large address
spaces.


I haven't really looked at the final code. One of the issue we had was
with the below scenario.

mmap(addr, len) where addr < 128TB and addr+len > 128TB  We want to make
sure we build the mask such that we don't find the addr available.


We should run it through the mmap regression tests. I *think* we moved
all of that logic from the slice code to get_ummapped_area before going
in to slices. I may have missed something though, it would be good to
have more eyes on it.
  


mmap(-1,...) failed with the test. Something like below fix it

@@ -756,7 +770,7 @@ void slice_set_user_psize(struct mm_struct *mm, unsigned 
int psize)
 mm->context.low_slices_psize = lpsizes;
  
 hpsizes = mm->context.high_slices_psize;

-   high_slices = GET_HIGH_SLICE_INDEX(mm->context.slb_addr_limit);
+   high_slices = SLICE_NUM_HIGH;
 for (i = 0; i < high_slices; i++) {
 mask_index = i & 0x1;
 index = i >> 1;

I guess for everything in the mm_context_t, we should compute it till
SLICE_NUM_HIGH. The reason for failure was, even though we recompute the
slice mask cached in mm_context on slb_addr_limit, it was still derived
from the high_slices_psizes which was computed with lower value.


Okay thanks for catching that Aneesh. I guess that's a slow path so it
should be okay. Christophe if you're taking care of the series can you
fold it in? Otherwise I'll do that after yours gets merged.



should we also compute the mm_context_t.slice_mask using SLICE_NUM_HIGH 
and skip the recalc_slice_mask_cache when we change the addr limit?


-aneesh



Re: [PATCH RESEND v5 2/2] KVM: X86: Allow userspace to define the microcode version

2018-02-27 Thread Paolo Bonzini
On 28/02/2018 07:03, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> Linux (among the others) has checks to make sure that certain features 
> aren't enabled on a certain family/model/stepping if the microcode version 
> isn't greater than or equal to a known good version.
> 
> By exposing the real microcode version, we're preventing buggy guests that
> don't check that they are running virtualized (i.e., they should trust the
> hypervisor) from disabling features that are effectively not buggy.
> 
> Suggested-by: Filippo Sironi 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Liran Alon 
> Cc: Nadav Amit 
> Cc: Borislav Petkov 
> Cc: Tom Lendacky 
> Signed-off-by: Wanpeng Li 
> ---
> v4 -> v5:
>  * microcode_version be u64 and initialized suitable, remote hte shifts
> v3 -> v4:
>  * add the shifts back
> v2 -> v3:
>  * remove the shifts
>  * add the MSR_IA32_UCODE_REV version to the "feature MSRs"
> v1 -> v2:
>  * add MSR_IA32_UCODE_REV to emulated_msrs
> 
>  arch/x86/include/asm/kvm_host.h |  1 +
>  arch/x86/kvm/svm.c  |  4 +---
>  arch/x86/kvm/vmx.c  |  1 +
>  arch/x86/kvm/x86.c  | 11 +--
>  4 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 938d453..df6720f 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
>   u64 smi_count;
>   bool tpr_access_reporting;
>   u64 ia32_xss;
> + u64 microcode_version;
>  
>   /*
>* Paging state of the vcpu
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index f874798..312f33f 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1907,6 +1907,7 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
> init_event)
>   u32 dummy;
>   u32 eax = 1;
>  
> + vcpu->arch.microcode_version = 0x0165;
>   svm->spec_ctrl = 0;
>  
>   if (!init_event) {
> @@ -3962,9 +3963,6 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>  
>   msr_info->data = svm->spec_ctrl;
>   break;
> - case MSR_IA32_UCODE_REV:
> - msr_info->data = 0x0165;
> - break;
>   case MSR_F15H_IC_CFG: {
>  
>   int family, model;
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 9968906..2cdbea7 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -5781,6 +5781,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool 
> init_event)
>   vmx->rmode.vm86_active = 0;
>   vmx->spec_ctrl = 0;
>  
> + vcpu->arch.microcode_version = 0x1ULL;
>   vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
>   kvm_set_cr8(vcpu, 0);
>  
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index efc8554..5c93cbc 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1058,6 +1058,7 @@ static unsigned num_emulated_msrs;
>  static u32 msr_based_features[] = {
>   MSR_IA32_ARCH_CAPABILITIES,
>   MSR_F10H_DECFG,
> + MSR_IA32_UCODE_REV,
>  };
>  
>  static unsigned int num_msr_based_features;
> @@ -1065,6 +1066,9 @@ static unsigned int num_msr_based_features;
>  static int kvm_get_msr_feature(struct kvm_msr_entry *msr)
>  {
>   switch (msr->index) {
> + case MSR_IA32_UCODE_REV:
> + rdmsrl(msr->index, msr->data);
> + break;
>   default:
>   if (kvm_x86_ops->get_msr_feature(msr))
>   return 1;
> @@ -2260,7 +2264,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>  
>   switch (msr) {
>   case MSR_AMD64_NB_CFG:
> - case MSR_IA32_UCODE_REV:
>   case MSR_IA32_UCODE_WRITE:
>   case MSR_VM_HSAVE_PA:
>   case MSR_AMD64_PATCH_LOADER:
> @@ -2268,6 +2271,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   case MSR_AMD64_DC_CFG:
>   break;
>  
> + case MSR_IA32_UCODE_REV:
> + if (msr_info->host_initiated)
> + vcpu->arch.microcode_version = data;
> + break;
>   case MSR_EFER:
>   return set_efer(vcpu, data);
>   case MSR_K7_HWCR:
> @@ -2563,7 +2570,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   msr_info->data = 0;
>   break;
>   case MSR_IA32_UCODE_REV:
> - msr_info->data = 0x1ULL;
> + msr_info->data = vcpu->arch.microcode_version;
>   break;
>   case MSR_MTRRcap:
>   case 0x200 ... 0x2ff:
> 

Reviewed-by: Paolo Bonzini 


Re: [PATCH RESEND v5 2/2] KVM: X86: Allow userspace to define the microcode version

2018-02-27 Thread Paolo Bonzini
On 28/02/2018 07:03, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> Linux (among the others) has checks to make sure that certain features 
> aren't enabled on a certain family/model/stepping if the microcode version 
> isn't greater than or equal to a known good version.
> 
> By exposing the real microcode version, we're preventing buggy guests that
> don't check that they are running virtualized (i.e., they should trust the
> hypervisor) from disabling features that are effectively not buggy.
> 
> Suggested-by: Filippo Sironi 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Liran Alon 
> Cc: Nadav Amit 
> Cc: Borislav Petkov 
> Cc: Tom Lendacky 
> Signed-off-by: Wanpeng Li 
> ---
> v4 -> v5:
>  * microcode_version be u64 and initialized suitable, remote hte shifts
> v3 -> v4:
>  * add the shifts back
> v2 -> v3:
>  * remove the shifts
>  * add the MSR_IA32_UCODE_REV version to the "feature MSRs"
> v1 -> v2:
>  * add MSR_IA32_UCODE_REV to emulated_msrs
> 
>  arch/x86/include/asm/kvm_host.h |  1 +
>  arch/x86/kvm/svm.c  |  4 +---
>  arch/x86/kvm/vmx.c  |  1 +
>  arch/x86/kvm/x86.c  | 11 +--
>  4 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 938d453..df6720f 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -507,6 +507,7 @@ struct kvm_vcpu_arch {
>   u64 smi_count;
>   bool tpr_access_reporting;
>   u64 ia32_xss;
> + u64 microcode_version;
>  
>   /*
>* Paging state of the vcpu
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index f874798..312f33f 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1907,6 +1907,7 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
> init_event)
>   u32 dummy;
>   u32 eax = 1;
>  
> + vcpu->arch.microcode_version = 0x0165;
>   svm->spec_ctrl = 0;
>  
>   if (!init_event) {
> @@ -3962,9 +3963,6 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>  
>   msr_info->data = svm->spec_ctrl;
>   break;
> - case MSR_IA32_UCODE_REV:
> - msr_info->data = 0x0165;
> - break;
>   case MSR_F15H_IC_CFG: {
>  
>   int family, model;
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 9968906..2cdbea7 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -5781,6 +5781,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool 
> init_event)
>   vmx->rmode.vm86_active = 0;
>   vmx->spec_ctrl = 0;
>  
> + vcpu->arch.microcode_version = 0x1ULL;
>   vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
>   kvm_set_cr8(vcpu, 0);
>  
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index efc8554..5c93cbc 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1058,6 +1058,7 @@ static unsigned num_emulated_msrs;
>  static u32 msr_based_features[] = {
>   MSR_IA32_ARCH_CAPABILITIES,
>   MSR_F10H_DECFG,
> + MSR_IA32_UCODE_REV,
>  };
>  
>  static unsigned int num_msr_based_features;
> @@ -1065,6 +1066,9 @@ static unsigned int num_msr_based_features;
>  static int kvm_get_msr_feature(struct kvm_msr_entry *msr)
>  {
>   switch (msr->index) {
> + case MSR_IA32_UCODE_REV:
> + rdmsrl(msr->index, msr->data);
> + break;
>   default:
>   if (kvm_x86_ops->get_msr_feature(msr))
>   return 1;
> @@ -2260,7 +2264,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>  
>   switch (msr) {
>   case MSR_AMD64_NB_CFG:
> - case MSR_IA32_UCODE_REV:
>   case MSR_IA32_UCODE_WRITE:
>   case MSR_VM_HSAVE_PA:
>   case MSR_AMD64_PATCH_LOADER:
> @@ -2268,6 +2271,10 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   case MSR_AMD64_DC_CFG:
>   break;
>  
> + case MSR_IA32_UCODE_REV:
> + if (msr_info->host_initiated)
> + vcpu->arch.microcode_version = data;
> + break;
>   case MSR_EFER:
>   return set_efer(vcpu, data);
>   case MSR_K7_HWCR:
> @@ -2563,7 +2570,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   msr_info->data = 0;
>   break;
>   case MSR_IA32_UCODE_REV:
> - msr_info->data = 0x1ULL;
> + msr_info->data = vcpu->arch.microcode_version;
>   break;
>   case MSR_MTRRcap:
>   case 0x200 ... 0x2ff:
> 

Reviewed-by: Paolo Bonzini 


[PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

2018-02-27 Thread Monk Liu
under below scenario the obj->fence would refer to a wild pointer:

1,call reservation_object_reserved_shared
2,call reservation_object_add_shared_fence
3,call reservation_object_reserved_shared
4,call reservation_object_add_shared_fence

in step 1, staged is allocated,

in step 2, code path will go reservation_object_add_shared_replace()
and obj->fence would be assigned as staged (through RCU_INIT_POINTER)

in step 3, obj->staged will be freed(by simple kfree),
which make obj->fence point to a wild pointer...

in step 4, code path will go reservation_object_add_shared_inplace()
and inside it the @fobj (which equals to @obj->staged, set by above steps)
is already a wild pointer

should remov the kfree on staged in reservation_object_reserve_shared()

Change-Id: If7c01f1b4be3d3d8a81efa90216841f79ab1fc1c
Signed-off-by: Monk Liu 
---
 drivers/dma-buf/reservation.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 375de41..b473ccc 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -74,12 +74,9 @@ int reservation_object_reserve_shared(struct 
reservation_object *obj)
old = reservation_object_get_list(obj);
 
if (old && old->shared_max) {
-   if (old->shared_count < old->shared_max) {
-   /* perform an in-place update */
-   kfree(obj->staged);
-   obj->staged = NULL;
+   if (old->shared_count < old->shared_max)
return 0;
-   } else
+   else
max = old->shared_max * 2;
} else
max = 4;
-- 
2.7.4



[PATCH] dma-buf/reservation: shouldn't kfree staged when slot available

2018-02-27 Thread Monk Liu
under below scenario the obj->fence would refer to a wild pointer:

1,call reservation_object_reserved_shared
2,call reservation_object_add_shared_fence
3,call reservation_object_reserved_shared
4,call reservation_object_add_shared_fence

in step 1, staged is allocated,

in step 2, code path will go reservation_object_add_shared_replace()
and obj->fence would be assigned as staged (through RCU_INIT_POINTER)

in step 3, obj->staged will be freed(by simple kfree),
which make obj->fence point to a wild pointer...

in step 4, code path will go reservation_object_add_shared_inplace()
and inside it the @fobj (which equals to @obj->staged, set by above steps)
is already a wild pointer

should remov the kfree on staged in reservation_object_reserve_shared()

Change-Id: If7c01f1b4be3d3d8a81efa90216841f79ab1fc1c
Signed-off-by: Monk Liu 
---
 drivers/dma-buf/reservation.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 375de41..b473ccc 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -74,12 +74,9 @@ int reservation_object_reserve_shared(struct 
reservation_object *obj)
old = reservation_object_get_list(obj);
 
if (old && old->shared_max) {
-   if (old->shared_count < old->shared_max) {
-   /* perform an in-place update */
-   kfree(obj->staged);
-   obj->staged = NULL;
+   if (old->shared_count < old->shared_max)
return 0;
-   } else
+   else
max = old->shared_max * 2;
} else
max = 4;
-- 
2.7.4



Re: [PATCH RESEND v5 1/2] KVM: X86: Introduce kvm_get_msr_feature()

2018-02-27 Thread Paolo Bonzini
On 28/02/2018 07:03, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> Introduce kvm_get_msr_feature() to handle the msrs which are supported 
> by different vendors and sharing the same emulation logic.
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Liran Alon 
> Cc: Nadav Amit 
> Cc: Borislav Petkov 
> Cc: Tom Lendacky 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/x86.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index d4985a9..efc8554 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1062,13 +1062,25 @@ static u32 msr_based_features[] = {
>  
>  static unsigned int num_msr_based_features;
>  
> +static int kvm_get_msr_feature(struct kvm_msr_entry *msr)
> +{
> + switch (msr->index) {
> + default:
> + if (kvm_x86_ops->get_msr_feature(msr))
> + return 1;
> + }
> + return 0;
> +}
> +
>  static int do_get_msr_feature(struct kvm_vcpu *vcpu, unsigned index, u64 
> *data)
>  {
>   struct kvm_msr_entry msr;
> + int r;
>  
>   msr.index = index;
> - if (kvm_x86_ops->get_msr_feature())
> - return 1;
> + r = kvm_get_msr_feature();
> + if (r)
> + return r;
>  
>   *data = msr.data;
>  
> @@ -4538,7 +4550,7 @@ static void kvm_init_msr_list(void)
>   struct kvm_msr_entry msr;
>  
>   msr.index = msr_based_features[i];
> - if (kvm_x86_ops->get_msr_feature())
> + if (kvm_get_msr_feature())
>   continue;
>  
>   if (j < i)
> 

Reviewed-by: Paolo Bonzini 


Re: [PATCH RESEND v5 1/2] KVM: X86: Introduce kvm_get_msr_feature()

2018-02-27 Thread Paolo Bonzini
On 28/02/2018 07:03, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> Introduce kvm_get_msr_feature() to handle the msrs which are supported 
> by different vendors and sharing the same emulation logic.
> 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Liran Alon 
> Cc: Nadav Amit 
> Cc: Borislav Petkov 
> Cc: Tom Lendacky 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kvm/x86.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index d4985a9..efc8554 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1062,13 +1062,25 @@ static u32 msr_based_features[] = {
>  
>  static unsigned int num_msr_based_features;
>  
> +static int kvm_get_msr_feature(struct kvm_msr_entry *msr)
> +{
> + switch (msr->index) {
> + default:
> + if (kvm_x86_ops->get_msr_feature(msr))
> + return 1;
> + }
> + return 0;
> +}
> +
>  static int do_get_msr_feature(struct kvm_vcpu *vcpu, unsigned index, u64 
> *data)
>  {
>   struct kvm_msr_entry msr;
> + int r;
>  
>   msr.index = index;
> - if (kvm_x86_ops->get_msr_feature())
> - return 1;
> + r = kvm_get_msr_feature();
> + if (r)
> + return r;
>  
>   *data = msr.data;
>  
> @@ -4538,7 +4550,7 @@ static void kvm_init_msr_list(void)
>   struct kvm_msr_entry msr;
>  
>   msr.index = msr_based_features[i];
> - if (kvm_x86_ops->get_msr_feature())
> + if (kvm_get_msr_feature())
>   continue;
>  
>   if (j < i)
> 

Reviewed-by: Paolo Bonzini 


Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations

2018-02-27 Thread Nicholas Piggin
On Tue, 27 Feb 2018 18:11:07 +0530
"Aneesh Kumar K.V"  wrote:

> Nicholas Piggin  writes:
> 
> > On Tue, 27 Feb 2018 14:31:07 +0530
> > "Aneesh Kumar K.V"  wrote:
> >  
> >> Christophe Leroy  writes:
> >>   
> >> > The number of high slices a process might use now depends on its
> >> > address space size, and what allocation address it has requested.
> >> >
> >> > This patch uses that limit throughout call chains where possible,
> >> > rather than use the fixed SLICE_NUM_HIGH for bitmap operations.
> >> > This saves some cost for processes that don't use very large address
> >> > spaces.
> >> 
> >> I haven't really looked at the final code. One of the issue we had was
> >> with the below scenario.
> >> 
> >> mmap(addr, len) where addr < 128TB and addr+len > 128TB  We want to make
> >> sure we build the mask such that we don't find the addr available.  
> >
> > We should run it through the mmap regression tests. I *think* we moved
> > all of that logic from the slice code to get_ummapped_area before going
> > in to slices. I may have missed something though, it would be good to
> > have more eyes on it.
> >  
> 
> mmap(-1,...) failed with the test. Something like below fix it
> 
> @@ -756,7 +770,7 @@ void slice_set_user_psize(struct mm_struct *mm, unsigned 
> int psize)
> mm->context.low_slices_psize = lpsizes;
>  
> hpsizes = mm->context.high_slices_psize;
> -   high_slices = GET_HIGH_SLICE_INDEX(mm->context.slb_addr_limit);
> +   high_slices = SLICE_NUM_HIGH;
> for (i = 0; i < high_slices; i++) {
> mask_index = i & 0x1;
> index = i >> 1;
> 
> I guess for everything in the mm_context_t, we should compute it till
> SLICE_NUM_HIGH. The reason for failure was, even though we recompute the
> slice mask cached in mm_context on slb_addr_limit, it was still derived
> from the high_slices_psizes which was computed with lower value.

Okay thanks for catching that Aneesh. I guess that's a slow path so it
should be okay. Christophe if you're taking care of the series can you
fold it in? Otherwise I'll do that after yours gets merged.

Thanks,
Nick



Re: [RFC REBASED 5/5] powerpc/mm/slice: use the dynamic high slice size to limit bitmap operations

2018-02-27 Thread Nicholas Piggin
On Tue, 27 Feb 2018 18:11:07 +0530
"Aneesh Kumar K.V"  wrote:

> Nicholas Piggin  writes:
> 
> > On Tue, 27 Feb 2018 14:31:07 +0530
> > "Aneesh Kumar K.V"  wrote:
> >  
> >> Christophe Leroy  writes:
> >>   
> >> > The number of high slices a process might use now depends on its
> >> > address space size, and what allocation address it has requested.
> >> >
> >> > This patch uses that limit throughout call chains where possible,
> >> > rather than use the fixed SLICE_NUM_HIGH for bitmap operations.
> >> > This saves some cost for processes that don't use very large address
> >> > spaces.
> >> 
> >> I haven't really looked at the final code. One of the issue we had was
> >> with the below scenario.
> >> 
> >> mmap(addr, len) where addr < 128TB and addr+len > 128TB  We want to make
> >> sure we build the mask such that we don't find the addr available.  
> >
> > We should run it through the mmap regression tests. I *think* we moved
> > all of that logic from the slice code to get_ummapped_area before going
> > in to slices. I may have missed something though, it would be good to
> > have more eyes on it.
> >  
> 
> mmap(-1,...) failed with the test. Something like below fix it
> 
> @@ -756,7 +770,7 @@ void slice_set_user_psize(struct mm_struct *mm, unsigned 
> int psize)
> mm->context.low_slices_psize = lpsizes;
>  
> hpsizes = mm->context.high_slices_psize;
> -   high_slices = GET_HIGH_SLICE_INDEX(mm->context.slb_addr_limit);
> +   high_slices = SLICE_NUM_HIGH;
> for (i = 0; i < high_slices; i++) {
> mask_index = i & 0x1;
> index = i >> 1;
> 
> I guess for everything in the mm_context_t, we should compute it till
> SLICE_NUM_HIGH. The reason for failure was, even though we recompute the
> slice mask cached in mm_context on slb_addr_limit, it was still derived
> from the high_slices_psizes which was computed with lower value.

Okay thanks for catching that Aneesh. I guess that's a slow path so it
should be okay. Christophe if you're taking care of the series can you
fold it in? Otherwise I'll do that after yours gets merged.

Thanks,
Nick



[PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches

2018-02-27 Thread Alex Hung
OEM strings are defined by each OEM and they contain customized and
useful OEM information. Supporting it provides more flexible uses of
the dmi_matches function.

Signed-off-by: Alex Hung 
---
 drivers/firmware/dmi_scan.c | 11 +--
 include/linux/mod_devicetable.h |  1 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index e763e14..c712e66 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -775,7 +775,15 @@ static bool dmi_matches(const struct dmi_system_id *dmi)
int s = dmi->matches[i].slot;
if (s == DMI_NONE)
break;
-   if (dmi_ident[s]) {
+   if (s == DMI_OEM_STRING) {
+   /* DMI_OEM_STRING must be exact match */
+   const struct dmi_device *valid;
+
+   valid = dmi_find_device(DMI_DEV_TYPE_OEM_STRING,
+   dmi->matches[i].substr, NULL);
+   if (valid)
+   continue;
+   } else if (dmi_ident[s]) {
if (dmi->matches[i].exact_match) {
if (!strcmp(dmi_ident[s],
dmi->matches[i].substr))
@@ -786,7 +794,6 @@ static bool dmi_matches(const struct dmi_system_id *dmi)
continue;
}
}
-
/* No match */
return false;
}
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 48fb2b4..7d361be 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -502,6 +502,7 @@ enum dmi_field {
DMI_CHASSIS_SERIAL,
DMI_CHASSIS_ASSET_TAG,
DMI_STRING_MAX,
+   DMI_OEM_STRING, /* special case - will not be in dmi_ident */
 };
 
 struct dmi_strmatch {
-- 
2.7.4



[PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches

2018-02-27 Thread Alex Hung
OEM strings are defined by each OEM and they contain customized and
useful OEM information. Supporting it provides more flexible uses of
the dmi_matches function.

Signed-off-by: Alex Hung 
---
 drivers/firmware/dmi_scan.c | 11 +--
 include/linux/mod_devicetable.h |  1 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index e763e14..c712e66 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -775,7 +775,15 @@ static bool dmi_matches(const struct dmi_system_id *dmi)
int s = dmi->matches[i].slot;
if (s == DMI_NONE)
break;
-   if (dmi_ident[s]) {
+   if (s == DMI_OEM_STRING) {
+   /* DMI_OEM_STRING must be exact match */
+   const struct dmi_device *valid;
+
+   valid = dmi_find_device(DMI_DEV_TYPE_OEM_STRING,
+   dmi->matches[i].substr, NULL);
+   if (valid)
+   continue;
+   } else if (dmi_ident[s]) {
if (dmi->matches[i].exact_match) {
if (!strcmp(dmi_ident[s],
dmi->matches[i].substr))
@@ -786,7 +794,6 @@ static bool dmi_matches(const struct dmi_system_id *dmi)
continue;
}
}
-
/* No match */
return false;
}
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 48fb2b4..7d361be 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -502,6 +502,7 @@ enum dmi_field {
DMI_CHASSIS_SERIAL,
DMI_CHASSIS_ASSET_TAG,
DMI_STRING_MAX,
+   DMI_OEM_STRING, /* special case - will not be in dmi_ident */
 };
 
 struct dmi_strmatch {
-- 
2.7.4



maybe a bug in SELinux: security_context_to_sid_core

2018-02-27 Thread Zhang, Ning A
Hi,

Before SELinux is initialized, get scontext by secid by using:

security_secctx_to_secid() may return wrong numbe

eg:
security_secctx_to_secid("devnull", strlen("devnull"), );

sid here will be 1

because:

in security_context_to_sid_core:

...
if (!ss_initialized) {
int i;

for (i = 1; i < SECINITSID_NUM; i++) {
if (!strcmp(initial_sid_to_string[i],
scontext)) {
*sid = i;
return 0;
}
}
*sid = SECINITSID_KERNEL;
return 0;
}
...

and SECINITSID_DEVNULL equals to SECINITSID_NUM, and it will never get
right secid for "devnull".

is this by design or bug?

BR.
Ning.

maybe a bug in SELinux: security_context_to_sid_core

2018-02-27 Thread Zhang, Ning A
Hi,

Before SELinux is initialized, get scontext by secid by using:

security_secctx_to_secid() may return wrong numbe

eg:
security_secctx_to_secid("devnull", strlen("devnull"), );

sid here will be 1

because:

in security_context_to_sid_core:

...
if (!ss_initialized) {
int i;

for (i = 1; i < SECINITSID_NUM; i++) {
if (!strcmp(initial_sid_to_string[i],
scontext)) {
*sid = i;
return 0;
}
}
*sid = SECINITSID_KERNEL;
return 0;
}
...

and SECINITSID_DEVNULL equals to SECINITSID_NUM, and it will never get
right secid for "devnull".

is this by design or bug?

BR.
Ning.

Re: [PATCH] staging:r8188eu: use lib80211 CCMP decrypt

2018-02-27 Thread Dan Carpenter
Hm...  Sorry.  I was looking at the wrong code.

I was looking at aes_decipher() instead of rtw_aes_decrypt().  The
aes_decipher() was acceptable style (although, it's of course good that
you deleted it).  rtw_aes_decrypt() was always really really awful.

That's fine then.  Sorry again.

regards,
dan carpenter



Re: [PATCH] staging:r8188eu: use lib80211 CCMP decrypt

2018-02-27 Thread Dan Carpenter
Hm...  Sorry.  I was looking at the wrong code.

I was looking at aes_decipher() instead of rtw_aes_decrypt().  The
aes_decipher() was acceptable style (although, it's of course good that
you deleted it).  rtw_aes_decrypt() was always really really awful.

That's fine then.  Sorry again.

regards,
dan carpenter



[PATCH] nios2: Use read_persistent_clock64() instead of read_persistent_clock()

2018-02-27 Thread Baolin Wang
Since struct timespec is not y2038 safe on 32bit machines, this patch
converts read_persistent_clock() to read_persistent_clock64() using
struct timespec64, as well as converting mktime() to mktime64().

Signed-off-by: Baolin Wang 
---
 arch/nios2/kernel/time.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index 20e8620..ab88b6d 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -336,9 +336,9 @@ static int __init nios2_time_init(struct device_node *timer)
return ret;
 }
 
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
-   ts->tv_sec = mktime(2007, 1, 1, 0, 0, 0);
+   ts->tv_sec = mktime64(2007, 1, 1, 0, 0, 0);
ts->tv_nsec = 0;
 }
 
-- 
1.7.9.5



[PATCH] nios2: Use read_persistent_clock64() instead of read_persistent_clock()

2018-02-27 Thread Baolin Wang
Since struct timespec is not y2038 safe on 32bit machines, this patch
converts read_persistent_clock() to read_persistent_clock64() using
struct timespec64, as well as converting mktime() to mktime64().

Signed-off-by: Baolin Wang 
---
 arch/nios2/kernel/time.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index 20e8620..ab88b6d 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -336,9 +336,9 @@ static int __init nios2_time_init(struct device_node *timer)
return ret;
 }
 
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
-   ts->tv_sec = mktime(2007, 1, 1, 0, 0, 0);
+   ts->tv_sec = mktime64(2007, 1, 1, 0, 0, 0);
ts->tv_nsec = 0;
 }
 
-- 
1.7.9.5



Re: [PATCH v2 1/4] arm64: dts: mt2712: add pintcrl file

2018-02-27 Thread Sean Wang
On Mon, 2018-02-26 at 16:33 +0800, Zhiyong Tao wrote:
> This patch adds pinctrl file for mt2712.
> 
> Signed-off-by: Zhiyong Tao 
> ---
>  arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1129 
> +
>  1 file changed, 1129 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h 
> b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> new file mode 100644
> index 000..44f8ca2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> @@ -0,0 +1,1129 @@
> +/*
> + * Copyright (C) 2015 MediaTek Inc.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */

suggest to consider more on using SPDX identifiers

> +#ifndef __DTS_MT2712_PINFUNC_H
> +#define __DTS_MT2712_PINFUNC_H
> +
> +#include 
> +
> +#define MT2712_PIN_0_EINT0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
> +#define MT2712_PIN_0_EINT0__FUNC_EINT0 (MTK_PIN_NO(0) | 1)
> +#define MT2712_PIN_0_EINT0__FUNC_MBIST_DIAG_SCANOUT (MTK_PIN_NO(0) | 2)
> +#define MT2712_PIN_0_EINT0__FUNC_DSIA_TE (MTK_PIN_NO(0) | 3)
> +#define MT2712_PIN_0_EINT0__FUNC_DSIC_TE (MTK_PIN_NO(0) | 4)
> +#define MT2712_PIN_0_EINT0__FUNC_DIN_D3 (MTK_PIN_NO(0) | 5)
> +#define MT2712_PIN_0_EINT0__FUNC_PURE_HW_PROTECT (MTK_PIN_NO(0) | 6)
> +
> +#define MT2712_PIN_1_EINT1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
> +#define MT2712_PIN_1_EINT1__FUNC_EINT1 (MTK_PIN_NO(1) | 1)
> +#define MT2712_PIN_1_EINT1__FUNC_IR_IN (MTK_PIN_NO(1) | 2)
> +#define MT2712_PIN_1_EINT1__FUNC_DSIB_TE (MTK_PIN_NO(1) | 3)
> +#define MT2712_PIN_1_EINT1__FUNC_DSID_TE (MTK_PIN_NO(1) | 4)
> +#define MT2712_PIN_1_EINT1__FUNC_DIN_D4 (MTK_PIN_NO(1) | 5)
> +
> +#define MT2712_PIN_2_EINT2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
> +#define MT2712_PIN_2_EINT2__FUNC_EINT2 (MTK_PIN_NO(2) | 1)
> +#define MT2712_PIN_2_EINT2__FUNC_IR_IN (MTK_PIN_NO(2) | 2)
> +#define MT2712_PIN_2_EINT2__FUNC_LCM_RST1 (MTK_PIN_NO(2) | 3)
> +#define MT2712_PIN_2_EINT2__FUNC_DIN_D5 (MTK_PIN_NO(2) | 5)
> +
> +#define MT2712_PIN_3_EINT3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
> +#define MT2712_PIN_3_EINT3__FUNC_EINT3 (MTK_PIN_NO(3) | 1)
> +#define MT2712_PIN_3_EINT3__FUNC_IR_IN (MTK_PIN_NO(3) | 2)
> +#define MT2712_PIN_3_EINT3__FUNC_LCM_RST0 (MTK_PIN_NO(3) | 3)
> +#define MT2712_PIN_3_EINT3__FUNC_DIN_D6 (MTK_PIN_NO(3) | 5)
> +
> +#define MT2712_PIN_4_PWM0__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
> +#define MT2712_PIN_4_PWM0__FUNC_PWM0 (MTK_PIN_NO(4) | 1)
> +#define MT2712_PIN_4_PWM0__FUNC_DISP0_PWM (MTK_PIN_NO(4) | 2)
> +#define MT2712_PIN_4_PWM0__FUNC_DISP1_PWM (MTK_PIN_NO(4) | 3)
> +#define MT2712_PIN_4_PWM0__FUNC_DIN_CLK (MTK_PIN_NO(4) | 5)
> +
> +#define MT2712_PIN_5_PWM1__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
> +#define MT2712_PIN_5_PWM1__FUNC_PWM1 (MTK_PIN_NO(5) | 1)
> +#define MT2712_PIN_5_PWM1__FUNC_DISP1_PWM (MTK_PIN_NO(5) | 2)
> +#define MT2712_PIN_5_PWM1__FUNC_DISP0_PWM (MTK_PIN_NO(5) | 3)
> +#define MT2712_PIN_5_PWM1__FUNC_DIN_VSYNC (MTK_PIN_NO(5) | 5)
> +
> +#define MT2712_PIN_6_PWM2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
> +#define MT2712_PIN_6_PWM2__FUNC_PWM2 (MTK_PIN_NO(6) | 1)
> +#define MT2712_PIN_6_PWM2__FUNC_DISP0_PWM (MTK_PIN_NO(6) | 2)
> +#define MT2712_PIN_6_PWM2__FUNC_DISP1_PWM (MTK_PIN_NO(6) | 3)
> +#define MT2712_PIN_6_PWM2__FUNC_DISP2_PWM (MTK_PIN_NO(6) | 4)
> +#define MT2712_PIN_6_PWM2__FUNC_DIN_HSYNC (MTK_PIN_NO(6) | 5)
> +
> +#define MT2712_PIN_7_PWM3__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
> +#define MT2712_PIN_7_PWM3__FUNC_PWM3 (MTK_PIN_NO(7) | 1)
> +#define MT2712_PIN_7_PWM3__FUNC_DISP1_PWM (MTK_PIN_NO(7) | 2)
> +#define MT2712_PIN_7_PWM3__FUNC_DISP0_PWM (MTK_PIN_NO(7) | 3)
> +#define MT2712_PIN_7_PWM3__FUNC_LCM_RST2 (MTK_PIN_NO(7) | 4)
> +#define MT2712_PIN_7_PWM3__FUNC_DIN_D0 (MTK_PIN_NO(7) | 5)
> +
> +#define MT2712_PIN_8_PWM4__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
> +#define MT2712_PIN_8_PWM4__FUNC_PWM4 (MTK_PIN_NO(8) | 1)
> +#define MT2712_PIN_8_PWM4__FUNC_DISP0_PWM (MTK_PIN_NO(8) | 2)
> +#define MT2712_PIN_8_PWM4__FUNC_DISP1_PWM (MTK_PIN_NO(8) | 3)
> +#define MT2712_PIN_8_PWM4__FUNC_DSIA_TE (MTK_PIN_NO(8) | 4)
> +#define MT2712_PIN_8_PWM4__FUNC_DIN_D1 (MTK_PIN_NO(8) | 5)
> +
> +#define MT2712_PIN_9_PWM5__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
> +#define MT2712_PIN_9_PWM5__FUNC_PWM5 (MTK_PIN_NO(9) | 1)
> +#define MT2712_PIN_9_PWM5__FUNC_DISP1_PWM (MTK_PIN_NO(9) | 2)
> +#define MT2712_PIN_9_PWM5__FUNC_DISP0_PWM (MTK_PIN_NO(9) | 3)
> +#define MT2712_PIN_9_PWM5__FUNC_DSIB_TE (MTK_PIN_NO(9) | 4)
> +#define MT2712_PIN_9_PWM5__FUNC_DIN_D2 (MTK_PIN_NO(9) | 5)
> +
> +#define MT2712_PIN_10_PWM6__FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
> +#define 

Re: [PATCH v2 1/4] arm64: dts: mt2712: add pintcrl file

2018-02-27 Thread Sean Wang
On Mon, 2018-02-26 at 16:33 +0800, Zhiyong Tao wrote:
> This patch adds pinctrl file for mt2712.
> 
> Signed-off-by: Zhiyong Tao 
> ---
>  arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1129 
> +
>  1 file changed, 1129 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h 
> b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> new file mode 100644
> index 000..44f8ca2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h
> @@ -0,0 +1,1129 @@
> +/*
> + * Copyright (C) 2015 MediaTek Inc.
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */

suggest to consider more on using SPDX identifiers

> +#ifndef __DTS_MT2712_PINFUNC_H
> +#define __DTS_MT2712_PINFUNC_H
> +
> +#include 
> +
> +#define MT2712_PIN_0_EINT0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
> +#define MT2712_PIN_0_EINT0__FUNC_EINT0 (MTK_PIN_NO(0) | 1)
> +#define MT2712_PIN_0_EINT0__FUNC_MBIST_DIAG_SCANOUT (MTK_PIN_NO(0) | 2)
> +#define MT2712_PIN_0_EINT0__FUNC_DSIA_TE (MTK_PIN_NO(0) | 3)
> +#define MT2712_PIN_0_EINT0__FUNC_DSIC_TE (MTK_PIN_NO(0) | 4)
> +#define MT2712_PIN_0_EINT0__FUNC_DIN_D3 (MTK_PIN_NO(0) | 5)
> +#define MT2712_PIN_0_EINT0__FUNC_PURE_HW_PROTECT (MTK_PIN_NO(0) | 6)
> +
> +#define MT2712_PIN_1_EINT1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
> +#define MT2712_PIN_1_EINT1__FUNC_EINT1 (MTK_PIN_NO(1) | 1)
> +#define MT2712_PIN_1_EINT1__FUNC_IR_IN (MTK_PIN_NO(1) | 2)
> +#define MT2712_PIN_1_EINT1__FUNC_DSIB_TE (MTK_PIN_NO(1) | 3)
> +#define MT2712_PIN_1_EINT1__FUNC_DSID_TE (MTK_PIN_NO(1) | 4)
> +#define MT2712_PIN_1_EINT1__FUNC_DIN_D4 (MTK_PIN_NO(1) | 5)
> +
> +#define MT2712_PIN_2_EINT2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
> +#define MT2712_PIN_2_EINT2__FUNC_EINT2 (MTK_PIN_NO(2) | 1)
> +#define MT2712_PIN_2_EINT2__FUNC_IR_IN (MTK_PIN_NO(2) | 2)
> +#define MT2712_PIN_2_EINT2__FUNC_LCM_RST1 (MTK_PIN_NO(2) | 3)
> +#define MT2712_PIN_2_EINT2__FUNC_DIN_D5 (MTK_PIN_NO(2) | 5)
> +
> +#define MT2712_PIN_3_EINT3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
> +#define MT2712_PIN_3_EINT3__FUNC_EINT3 (MTK_PIN_NO(3) | 1)
> +#define MT2712_PIN_3_EINT3__FUNC_IR_IN (MTK_PIN_NO(3) | 2)
> +#define MT2712_PIN_3_EINT3__FUNC_LCM_RST0 (MTK_PIN_NO(3) | 3)
> +#define MT2712_PIN_3_EINT3__FUNC_DIN_D6 (MTK_PIN_NO(3) | 5)
> +
> +#define MT2712_PIN_4_PWM0__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
> +#define MT2712_PIN_4_PWM0__FUNC_PWM0 (MTK_PIN_NO(4) | 1)
> +#define MT2712_PIN_4_PWM0__FUNC_DISP0_PWM (MTK_PIN_NO(4) | 2)
> +#define MT2712_PIN_4_PWM0__FUNC_DISP1_PWM (MTK_PIN_NO(4) | 3)
> +#define MT2712_PIN_4_PWM0__FUNC_DIN_CLK (MTK_PIN_NO(4) | 5)
> +
> +#define MT2712_PIN_5_PWM1__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
> +#define MT2712_PIN_5_PWM1__FUNC_PWM1 (MTK_PIN_NO(5) | 1)
> +#define MT2712_PIN_5_PWM1__FUNC_DISP1_PWM (MTK_PIN_NO(5) | 2)
> +#define MT2712_PIN_5_PWM1__FUNC_DISP0_PWM (MTK_PIN_NO(5) | 3)
> +#define MT2712_PIN_5_PWM1__FUNC_DIN_VSYNC (MTK_PIN_NO(5) | 5)
> +
> +#define MT2712_PIN_6_PWM2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
> +#define MT2712_PIN_6_PWM2__FUNC_PWM2 (MTK_PIN_NO(6) | 1)
> +#define MT2712_PIN_6_PWM2__FUNC_DISP0_PWM (MTK_PIN_NO(6) | 2)
> +#define MT2712_PIN_6_PWM2__FUNC_DISP1_PWM (MTK_PIN_NO(6) | 3)
> +#define MT2712_PIN_6_PWM2__FUNC_DISP2_PWM (MTK_PIN_NO(6) | 4)
> +#define MT2712_PIN_6_PWM2__FUNC_DIN_HSYNC (MTK_PIN_NO(6) | 5)
> +
> +#define MT2712_PIN_7_PWM3__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
> +#define MT2712_PIN_7_PWM3__FUNC_PWM3 (MTK_PIN_NO(7) | 1)
> +#define MT2712_PIN_7_PWM3__FUNC_DISP1_PWM (MTK_PIN_NO(7) | 2)
> +#define MT2712_PIN_7_PWM3__FUNC_DISP0_PWM (MTK_PIN_NO(7) | 3)
> +#define MT2712_PIN_7_PWM3__FUNC_LCM_RST2 (MTK_PIN_NO(7) | 4)
> +#define MT2712_PIN_7_PWM3__FUNC_DIN_D0 (MTK_PIN_NO(7) | 5)
> +
> +#define MT2712_PIN_8_PWM4__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
> +#define MT2712_PIN_8_PWM4__FUNC_PWM4 (MTK_PIN_NO(8) | 1)
> +#define MT2712_PIN_8_PWM4__FUNC_DISP0_PWM (MTK_PIN_NO(8) | 2)
> +#define MT2712_PIN_8_PWM4__FUNC_DISP1_PWM (MTK_PIN_NO(8) | 3)
> +#define MT2712_PIN_8_PWM4__FUNC_DSIA_TE (MTK_PIN_NO(8) | 4)
> +#define MT2712_PIN_8_PWM4__FUNC_DIN_D1 (MTK_PIN_NO(8) | 5)
> +
> +#define MT2712_PIN_9_PWM5__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
> +#define MT2712_PIN_9_PWM5__FUNC_PWM5 (MTK_PIN_NO(9) | 1)
> +#define MT2712_PIN_9_PWM5__FUNC_DISP1_PWM (MTK_PIN_NO(9) | 2)
> +#define MT2712_PIN_9_PWM5__FUNC_DISP0_PWM (MTK_PIN_NO(9) | 3)
> +#define MT2712_PIN_9_PWM5__FUNC_DSIB_TE (MTK_PIN_NO(9) | 4)
> +#define MT2712_PIN_9_PWM5__FUNC_DIN_D2 (MTK_PIN_NO(9) | 5)
> +
> +#define MT2712_PIN_10_PWM6__FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
> +#define MT2712_PIN_10_PWM6__FUNC_PWM6 

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

2018-02-27 Thread Andrzej Hajda
On 27.02.2018 22:24, Rob Herring wrote:
> On Wed, Feb 21, 2018 at 2:55 AM, Andrzej Hajda  wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> v4:
>> - added missing reg property in connector's port node (Krzysztof)
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 
>> --
>>  1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> index f604f6b1a9c2..2ed506df94d0 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> @@ -817,9 +817,22 @@
>> clocks = <_system_controller 0>;
>> clock-names = "xtal";
>>
>> -   port {
>> -   mhl_to_hdmi: endpoint {
>> -   remote-endpoint = <_to_mhl>;
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port@0 {
>> +   reg = <0>;
>> +   mhl_to_hdmi: endpoint {
>> +   remote-endpoint = <_to_mhl>;
>> +   };
>> +   };
>> +
>> +   port@1 {
>> +   reg = <1>;
>> +   mhl_to_musb_con: endpoint {
>> +   remote-endpoint = <_con_to_mhl>;
>> +   };
> These ports are mutually exclusive, right? If so, it should be 1 port
> with 2 endpoints. Ports should represent independent data flows.
> Something muxed or replicated (1 to many connection) should be be
> endpoints.

No, this is HDMI -> MHL bridge, so port 0 is HDMI input, and port 1 is
MHL output.

Regards
Andrzej

>
> Rob
>
>
>



Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

2018-02-27 Thread Andrzej Hajda
On 27.02.2018 22:24, Rob Herring wrote:
> On Wed, Feb 21, 2018 at 2:55 AM, Andrzej Hajda  wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> v4:
>> - added missing reg property in connector's port node (Krzysztof)
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 
>> --
>>  1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> index f604f6b1a9c2..2ed506df94d0 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> @@ -817,9 +817,22 @@
>> clocks = <_system_controller 0>;
>> clock-names = "xtal";
>>
>> -   port {
>> -   mhl_to_hdmi: endpoint {
>> -   remote-endpoint = <_to_mhl>;
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port@0 {
>> +   reg = <0>;
>> +   mhl_to_hdmi: endpoint {
>> +   remote-endpoint = <_to_mhl>;
>> +   };
>> +   };
>> +
>> +   port@1 {
>> +   reg = <1>;
>> +   mhl_to_musb_con: endpoint {
>> +   remote-endpoint = <_con_to_mhl>;
>> +   };
> These ports are mutually exclusive, right? If so, it should be 1 port
> with 2 endpoints. Ports should represent independent data flows.
> Something muxed or replicated (1 to many connection) should be be
> endpoints.

No, this is HDMI -> MHL bridge, so port 0 is HDMI input, and port 1 is
MHL output.

Regards
Andrzej

>
> Rob
>
>
>



Re: [PATCH] ARM: davinci: fix the GPIO lookup for omapl138-hawk

2018-02-27 Thread Sekhar Nori
On Tuesday 27 February 2018 05:44 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that
> mmc can correctly lookup the wp and cp gpios.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  arch/arm/mach-davinci/board-omapl138-hawk.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c 
> b/arch/arm/mach-davinci/board-omapl138-hawk.c
> index a3e78074be70..62eb7d668890 100644
> --- a/arch/arm/mach-davinci/board-omapl138-hawk.c
> +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
> @@ -127,8 +127,8 @@ static struct gpiod_lookup_table mmc_gpios_table = {
>   .dev_id = "da830-mmc.0",
>   .table = {
>   /* CD: gpio3_12: gpio60: chip 1 contains gpio range 32-63*/
> - GPIO_LOOKUP("davinci_gpio.1", 28, "cd", GPIO_ACTIVE_LOW),
> - GPIO_LOOKUP("davinci_gpio.1", 29, "wp", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("davinci_gpio.0", 28, "cd", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("davinci_gpio.0", 29, "wp", GPIO_ACTIVE_LOW),

Hmm, shouldn't this just be "davinci_gpio" since we use .id = -1 in
da8xx_gpio_device?

Also:

Fixes: c69f43fb4f26 ("ARM: davinci: hawk: use gpio descriptor for mmc pins")

Thanks,
Sekhar


Re: [PATCH] ARM: davinci: fix the GPIO lookup for omapl138-hawk

2018-02-27 Thread Sekhar Nori
On Tuesday 27 February 2018 05:44 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that
> mmc can correctly lookup the wp and cp gpios.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  arch/arm/mach-davinci/board-omapl138-hawk.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c 
> b/arch/arm/mach-davinci/board-omapl138-hawk.c
> index a3e78074be70..62eb7d668890 100644
> --- a/arch/arm/mach-davinci/board-omapl138-hawk.c
> +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
> @@ -127,8 +127,8 @@ static struct gpiod_lookup_table mmc_gpios_table = {
>   .dev_id = "da830-mmc.0",
>   .table = {
>   /* CD: gpio3_12: gpio60: chip 1 contains gpio range 32-63*/
> - GPIO_LOOKUP("davinci_gpio.1", 28, "cd", GPIO_ACTIVE_LOW),
> - GPIO_LOOKUP("davinci_gpio.1", 29, "wp", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("davinci_gpio.0", 28, "cd", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("davinci_gpio.0", 29, "wp", GPIO_ACTIVE_LOW),

Hmm, shouldn't this just be "davinci_gpio" since we use .id = -1 in
da8xx_gpio_device?

Also:

Fixes: c69f43fb4f26 ("ARM: davinci: hawk: use gpio descriptor for mmc pins")

Thanks,
Sekhar


[PATCH v2 6/6] MAINTAINERS: Add entry for Jailhouse

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Signed-off-by: Jan Kiszka 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..4b889f282c77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7521,6 +7521,13 @@ Q:   
http://patchwork.linuxtv.org/project/linux-media/list/
 S: Maintained
 F: drivers/media/dvb-frontends/ix2505v*
 
+JAILHOUSE HYPERVISOR INTERFACE
+M: Jan Kiszka 
+L: jailhouse-...@googlegroups.com
+S: Maintained
+F: arch/x86/kernel/jailhouse.c
+F: arch/x86/include/asm/jailhouse_para.h
+
 JC42.4 TEMPERATURE SENSOR DRIVER
 M: Guenter Roeck 
 L: linux-hw...@vger.kernel.org
-- 
2.13.6



[PATCH v2 6/6] MAINTAINERS: Add entry for Jailhouse

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Signed-off-by: Jan Kiszka 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..4b889f282c77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7521,6 +7521,13 @@ Q:   
http://patchwork.linuxtv.org/project/linux-media/list/
 S: Maintained
 F: drivers/media/dvb-frontends/ix2505v*
 
+JAILHOUSE HYPERVISOR INTERFACE
+M: Jan Kiszka 
+L: jailhouse-...@googlegroups.com
+S: Maintained
+F: arch/x86/kernel/jailhouse.c
+F: arch/x86/include/asm/jailhouse_para.h
+
 JC42.4 TEMPERATURE SENSOR DRIVER
 M: Guenter Roeck 
 L: linux-hw...@vger.kernel.org
-- 
2.13.6



[PATCH v2 5/6] x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.

Saves some bytes in the Jailhouse non-root kernel.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig  | 6 +-
 arch/x86/kernel/Makefile  | 2 +-
 arch/x86/kernel/cpu/amd.c | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 63e85e7da12e..5b0ac52e357a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2643,7 +2643,7 @@ config PCI_DIRECT
 config PCI_MMCONFIG
bool "Support mmconfig PCI config space access" if X86_64
default y
-   depends on PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY || 
X86_64)
+   depends on PCI && (ACPI || SFI || JAILHOUSE_GUEST) && (PCI_GOMMCONFIG 
|| PCI_GOANY || X86_64)
 
 config PCI_OLPC
def_bool y
@@ -2658,6 +2658,10 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
+config MMCONF_FAM10H
+   def_bool y
+   depends on PCI_MMCONFIG && ACPI
+
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 29786c87e864..73ccf80c09a2 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -146,6 +146,6 @@ ifeq ($(CONFIG_X86_64),y)
obj-$(CONFIG_GART_IOMMU)+= amd_gart_64.o aperture_64.o
obj-$(CONFIG_CALGARY_IOMMU) += pci-calgary_64.o tce_64.o
 
-   obj-$(CONFIG_PCI_MMCONFIG)  += mmconf-fam10h_64.o
+   obj-$(CONFIG_MMCONF_FAM10H) += mmconf-fam10h_64.o
obj-y   += vsmp_64.o
 endif
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index f0e6456ca7d3..12bc0a1139da 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -716,7 +716,7 @@ static void init_amd_k8(struct cpuinfo_x86 *c)
 
 static void init_amd_gh(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_MMCONF_FAM10H
/* do this for boot cpu */
if (c == _cpu_data)
check_enable_amd_mmconf_dmi();
-- 
2.13.6



[PATCH v2 5/6] x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.

Saves some bytes in the Jailhouse non-root kernel.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig  | 6 +-
 arch/x86/kernel/Makefile  | 2 +-
 arch/x86/kernel/cpu/amd.c | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 63e85e7da12e..5b0ac52e357a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2643,7 +2643,7 @@ config PCI_DIRECT
 config PCI_MMCONFIG
bool "Support mmconfig PCI config space access" if X86_64
default y
-   depends on PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY || 
X86_64)
+   depends on PCI && (ACPI || SFI || JAILHOUSE_GUEST) && (PCI_GOMMCONFIG 
|| PCI_GOANY || X86_64)
 
 config PCI_OLPC
def_bool y
@@ -2658,6 +2658,10 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
+config MMCONF_FAM10H
+   def_bool y
+   depends on PCI_MMCONFIG && ACPI
+
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 29786c87e864..73ccf80c09a2 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -146,6 +146,6 @@ ifeq ($(CONFIG_X86_64),y)
obj-$(CONFIG_GART_IOMMU)+= amd_gart_64.o aperture_64.o
obj-$(CONFIG_CALGARY_IOMMU) += pci-calgary_64.o tce_64.o
 
-   obj-$(CONFIG_PCI_MMCONFIG)  += mmconf-fam10h_64.o
+   obj-$(CONFIG_MMCONF_FAM10H) += mmconf-fam10h_64.o
obj-y   += vsmp_64.o
 endif
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index f0e6456ca7d3..12bc0a1139da 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -716,7 +716,7 @@ static void init_amd_k8(struct cpuinfo_x86 *c)
 
 static void init_amd_gh(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_MMCONF_FAM10H
/* do this for boot cpu */
if (c == _cpu_data)
check_enable_amd_mmconf_dmi();
-- 
2.13.6



[PATCH v2 3/6] x86/jailhouse: Enable PCI mmconfig access in inmates

2018-02-27 Thread Jan Kiszka
From: Otavio Pontes 

Use the PCI mmconfig base address exported by jailhouse in boot
parameters in order to access the memory mapped PCI configuration space.

Signed-off-by: Otavio Pontes 
[Jan: rebased, fixed !CONFIG_PCI_MMCONFIG]
Signed-off-by: Jan Kiszka 
---
 arch/x86/include/asm/pci_x86.h | 2 ++
 arch/x86/kernel/jailhouse.c| 7 +++
 arch/x86/pci/mmconfig-shared.c | 4 ++--
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index eb66fa9cd0fc..959d618dbb17 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -151,6 +151,8 @@ extern int pci_mmconfig_insert(struct device *dev, u16 seg, 
u8 start, u8 end,
   phys_addr_t addr);
 extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
 extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+extern struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+   int end, u64 addr);
 
 extern struct list_head pci_mmcfg_list;
 
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index b68fd895235a..7fe2a73da0b3 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -124,6 +124,13 @@ static int __init jailhouse_pci_arch_init(void)
if (pcibios_last_bus < 0)
pcibios_last_bus = 0xff;
 
+#ifdef CONFIG_PCI_MMCONFIG
+   if (setup_data.pci_mmconfig_base) {
+   pci_mmconfig_add(0, 0, 0xff, setup_data.pci_mmconfig_base);
+   pci_mmcfg_arch_init();
+   }
+#endif
+
return 0;
 }
 
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 96684d0adcf9..0e590272366b 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -94,8 +94,8 @@ static struct pci_mmcfg_region *pci_mmconfig_alloc(int 
segment, int start,
return new;
 }
 
-static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
-   int end, u64 addr)
+struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+int end, u64 addr)
 {
struct pci_mmcfg_region *new;
 
-- 
2.13.6



[PATCH v2 3/6] x86/jailhouse: Enable PCI mmconfig access in inmates

2018-02-27 Thread Jan Kiszka
From: Otavio Pontes 

Use the PCI mmconfig base address exported by jailhouse in boot
parameters in order to access the memory mapped PCI configuration space.

Signed-off-by: Otavio Pontes 
[Jan: rebased, fixed !CONFIG_PCI_MMCONFIG]
Signed-off-by: Jan Kiszka 
---
 arch/x86/include/asm/pci_x86.h | 2 ++
 arch/x86/kernel/jailhouse.c| 7 +++
 arch/x86/pci/mmconfig-shared.c | 4 ++--
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index eb66fa9cd0fc..959d618dbb17 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -151,6 +151,8 @@ extern int pci_mmconfig_insert(struct device *dev, u16 seg, 
u8 start, u8 end,
   phys_addr_t addr);
 extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
 extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+extern struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+   int end, u64 addr);
 
 extern struct list_head pci_mmcfg_list;
 
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index b68fd895235a..7fe2a73da0b3 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -124,6 +124,13 @@ static int __init jailhouse_pci_arch_init(void)
if (pcibios_last_bus < 0)
pcibios_last_bus = 0xff;
 
+#ifdef CONFIG_PCI_MMCONFIG
+   if (setup_data.pci_mmconfig_base) {
+   pci_mmconfig_add(0, 0, 0xff, setup_data.pci_mmconfig_base);
+   pci_mmcfg_arch_init();
+   }
+#endif
+
return 0;
 }
 
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 96684d0adcf9..0e590272366b 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -94,8 +94,8 @@ static struct pci_mmcfg_region *pci_mmconfig_alloc(int 
segment, int start,
return new;
 }
 
-static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
-   int end, u64 addr)
+struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+int end, u64 addr)
 {
struct pci_mmcfg_region *new;
 
-- 
2.13.6



[PATCH v2 1/6] jailhouse: Provide detection for non-x86 systems

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.

CC: Rob Herring 
CC: Mark Rutland 
Signed-off-by: Jan Kiszka 
---
 Documentation/devicetree/bindings/jailhouse.txt |  8 
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 include/linux/hypervisor.h  | 17 +++--
 3 files changed, 24 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

diff --git a/Documentation/devicetree/bindings/jailhouse.txt 
b/Documentation/devicetree/bindings/jailhouse.txt
new file mode 100644
index ..2901c25ff340
--- /dev/null
+++ b/Documentation/devicetree/bindings/jailhouse.txt
@@ -0,0 +1,8 @@
+Jailhouse non-root cell device tree bindings
+
+
+When running in a non-root Jailhouse cell (partition), the device tree of this
+platform shall have a top-level "hypervisor" node with the following
+properties:
+
+- compatible = "jailhouse,cell"
diff --git a/arch/x86/include/asm/jailhouse_para.h 
b/arch/x86/include/asm/jailhouse_para.h
index 875b54376689..b885a961a150 100644
--- a/arch/x86/include/asm/jailhouse_para.h
+++ b/arch/x86/include/asm/jailhouse_para.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL2.0 */
 
 /*
- * Jailhouse paravirt_ops implementation
+ * Jailhouse paravirt detection
  *
  * Copyright (c) Siemens AG, 2015-2017
  *
diff --git a/include/linux/hypervisor.h b/include/linux/hypervisor.h
index b19563f9a8eb..fc08b433c856 100644
--- a/include/linux/hypervisor.h
+++ b/include/linux/hypervisor.h
@@ -8,15 +8,28 @@
  */
 
 #ifdef CONFIG_X86
+
+#include 
 #include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
x86_platform.hyper.pin_vcpu(cpu);
 }
-#else
+
+#else /* !CONFIG_X86 */
+
+#include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
 }
-#endif
+
+static inline bool jailhouse_paravirt(void)
+{
+   return of_find_compatible_node(NULL, NULL, "jailhouse,cell");
+}
+
+#endif /* !CONFIG_X86 */
 
 #endif /* __LINUX_HYPEVISOR_H */
-- 
2.13.6



[PATCH v2 1/6] jailhouse: Provide detection for non-x86 systems

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.

CC: Rob Herring 
CC: Mark Rutland 
Signed-off-by: Jan Kiszka 
---
 Documentation/devicetree/bindings/jailhouse.txt |  8 
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 include/linux/hypervisor.h  | 17 +++--
 3 files changed, 24 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

diff --git a/Documentation/devicetree/bindings/jailhouse.txt 
b/Documentation/devicetree/bindings/jailhouse.txt
new file mode 100644
index ..2901c25ff340
--- /dev/null
+++ b/Documentation/devicetree/bindings/jailhouse.txt
@@ -0,0 +1,8 @@
+Jailhouse non-root cell device tree bindings
+
+
+When running in a non-root Jailhouse cell (partition), the device tree of this
+platform shall have a top-level "hypervisor" node with the following
+properties:
+
+- compatible = "jailhouse,cell"
diff --git a/arch/x86/include/asm/jailhouse_para.h 
b/arch/x86/include/asm/jailhouse_para.h
index 875b54376689..b885a961a150 100644
--- a/arch/x86/include/asm/jailhouse_para.h
+++ b/arch/x86/include/asm/jailhouse_para.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL2.0 */
 
 /*
- * Jailhouse paravirt_ops implementation
+ * Jailhouse paravirt detection
  *
  * Copyright (c) Siemens AG, 2015-2017
  *
diff --git a/include/linux/hypervisor.h b/include/linux/hypervisor.h
index b19563f9a8eb..fc08b433c856 100644
--- a/include/linux/hypervisor.h
+++ b/include/linux/hypervisor.h
@@ -8,15 +8,28 @@
  */
 
 #ifdef CONFIG_X86
+
+#include 
 #include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
x86_platform.hyper.pin_vcpu(cpu);
 }
-#else
+
+#else /* !CONFIG_X86 */
+
+#include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
 }
-#endif
+
+static inline bool jailhouse_paravirt(void)
+{
+   return of_find_compatible_node(NULL, NULL, "jailhouse,cell");
+}
+
+#endif /* !CONFIG_X86 */
 
 #endif /* __LINUX_HYPEVISOR_H */
-- 
2.13.6



[PATCH v2 0/6] jailhouse: Enhance secondary Jailhouse guest support /wrt PCI

2018-02-27 Thread Jan Kiszka
Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest
is currently pending in the tip tree. This builds on top and enhances
the PCI support for x86 and also ARM guests (ARM[64] does not require
platform patches and works already).

Key elements of this series are:
 - detection of Jailhouse via device tree hypervisor node
 - function-level PCI scan if Jailhouse is detected
 - MMCONFIG support for x86 guests

As most changes affect x86, I would suggest to route the series also via
tip after the necessary acks are collected.

Changes in v2:
 - adjusted commit log and include ordering in patch 2
 - rebased over Linus master

Jan

[1] https://lkml.org/lkml/2017/11/27/125
[2] http://jailhouse-project.org

CC: Benedikt Spranger 
CC: Mark Rutland 
CC: Otavio Pontes 
CC: Rob Herring 

Jan Kiszka (5):
  jailhouse: Provide detection for non-x86 systems
  PCI: Scan all functions when running over Jailhouse
  x86: Consolidate PCI_MMCONFIG configs
  x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI
  MAINTAINERS: Add entry for Jailhouse

Otavio Pontes (1):
  x86/jailhouse: Enable PCI mmconfig access in inmates

 Documentation/devicetree/bindings/jailhouse.txt |  8 
 MAINTAINERS |  7 +++
 arch/x86/Kconfig| 11 ++-
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 arch/x86/include/asm/pci_x86.h  |  2 ++
 arch/x86/kernel/Makefile|  2 +-
 arch/x86/kernel/cpu/amd.c   |  2 +-
 arch/x86/kernel/jailhouse.c |  7 +++
 arch/x86/pci/legacy.c   |  4 +++-
 arch/x86/pci/mmconfig-shared.c  |  4 ++--
 drivers/pci/probe.c |  4 +++-
 include/linux/hypervisor.h  | 17 +++--
 12 files changed, 56 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

-- 
2.13.6



[PATCH v2 4/6] x86: Consolidate PCI_MMCONFIG configs

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Not sure if those two worked by design or just by chance so far. In any
case, it's at least cleaner and clearer to express this in a single
config statement.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb7f43f23521..63e85e7da12e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2641,8 +2641,9 @@ config PCI_DIRECT
depends on PCI && (X86_64 || (PCI_GODIRECT || PCI_GOANY || PCI_GOOLPC 
|| PCI_GOMMCONFIG))
 
 config PCI_MMCONFIG
-   def_bool y
-   depends on X86_32 && PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || 
PCI_GOANY)
+   bool "Support mmconfig PCI config space access" if X86_64
+   default y
+   depends on PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY || 
X86_64)
 
 config PCI_OLPC
def_bool y
@@ -2657,10 +2658,6 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
-config PCI_MMCONFIG
-   bool "Support mmconfig PCI config space access"
-   depends on X86_64 && PCI && ACPI
-
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
-- 
2.13.6



[PATCH v2 0/6] jailhouse: Enhance secondary Jailhouse guest support /wrt PCI

2018-02-27 Thread Jan Kiszka
Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest
is currently pending in the tip tree. This builds on top and enhances
the PCI support for x86 and also ARM guests (ARM[64] does not require
platform patches and works already).

Key elements of this series are:
 - detection of Jailhouse via device tree hypervisor node
 - function-level PCI scan if Jailhouse is detected
 - MMCONFIG support for x86 guests

As most changes affect x86, I would suggest to route the series also via
tip after the necessary acks are collected.

Changes in v2:
 - adjusted commit log and include ordering in patch 2
 - rebased over Linus master

Jan

[1] https://lkml.org/lkml/2017/11/27/125
[2] http://jailhouse-project.org

CC: Benedikt Spranger 
CC: Mark Rutland 
CC: Otavio Pontes 
CC: Rob Herring 

Jan Kiszka (5):
  jailhouse: Provide detection for non-x86 systems
  PCI: Scan all functions when running over Jailhouse
  x86: Consolidate PCI_MMCONFIG configs
  x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI
  MAINTAINERS: Add entry for Jailhouse

Otavio Pontes (1):
  x86/jailhouse: Enable PCI mmconfig access in inmates

 Documentation/devicetree/bindings/jailhouse.txt |  8 
 MAINTAINERS |  7 +++
 arch/x86/Kconfig| 11 ++-
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 arch/x86/include/asm/pci_x86.h  |  2 ++
 arch/x86/kernel/Makefile|  2 +-
 arch/x86/kernel/cpu/amd.c   |  2 +-
 arch/x86/kernel/jailhouse.c |  7 +++
 arch/x86/pci/legacy.c   |  4 +++-
 arch/x86/pci/mmconfig-shared.c  |  4 ++--
 drivers/pci/probe.c |  4 +++-
 include/linux/hypervisor.h  | 17 +++--
 12 files changed, 56 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

-- 
2.13.6



[PATCH v2 4/6] x86: Consolidate PCI_MMCONFIG configs

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Not sure if those two worked by design or just by chance so far. In any
case, it's at least cleaner and clearer to express this in a single
config statement.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb7f43f23521..63e85e7da12e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2641,8 +2641,9 @@ config PCI_DIRECT
depends on PCI && (X86_64 || (PCI_GODIRECT || PCI_GOANY || PCI_GOOLPC 
|| PCI_GOMMCONFIG))
 
 config PCI_MMCONFIG
-   def_bool y
-   depends on X86_32 && PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || 
PCI_GOANY)
+   bool "Support mmconfig PCI config space access" if X86_64
+   default y
+   depends on PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY || 
X86_64)
 
 config PCI_OLPC
def_bool y
@@ -2657,10 +2658,6 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
-config PCI_MMCONFIG
-   bool "Support mmconfig PCI config space access"
-   depends on X86_64 && PCI && ACPI
-
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
-- 
2.13.6



[PATCH v2 2/6] PCI: Scan all functions when running over Jailhouse

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Per PCIe r4.0, sec 7.5.1.1.9, multi-function devices are required to
have a function 0.  Therefore, Linux scans for devices at function 0
(devfn 0/8/16/...) and only scans for other functions if function 0
has its Multi-Function Device bit set or ARI or SR-IOV indicate
there are more functions.

The Jailhouse hypervisor may pass individual functions of a
multi-function device to a guest without passing function 0, which
means a Linux guest won't find them.

Change Linux PCI probing so it scans all function numbers when
running as a guest over Jailhouse.

This is technically prohibited by the spec, so it is possible that
PCI devices without the Multi-Function Device bit set may have
unexpected behavior in response to this probe.

Based on patch by Benedikt Spranger, adding Jailhouse probing to avoid
changing the behavior in the absence of the hypervisor.

CC: Benedikt Spranger 
Signed-off-by: Jan Kiszka 
Acked-by: Bjorn Helgaas 
---
 arch/x86/pci/legacy.c | 4 +++-
 drivers/pci/probe.c   | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/legacy.c b/arch/x86/pci/legacy.c
index 1cb01abcb1be..dfbe6ac38830 100644
--- a/arch/x86/pci/legacy.c
+++ b/arch/x86/pci/legacy.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -34,13 +35,14 @@ int __init pci_legacy_init(void)
 
 void pcibios_scan_specific_bus(int busn)
 {
+   int stride = jailhouse_paravirt() ? 1 : 8;
int devfn;
u32 l;
 
if (pci_find_bus(0, busn))
return;
 
-   for (devfn = 0; devfn < 256; devfn += 8) {
+   for (devfn = 0; devfn < 256; devfn += stride) {
if (!raw_pci_read(0, busn, devfn, PCI_VENDOR_ID, 2, ) &&
l != 0x && l != 0x) {
DBG("Found device at %02x:%02x [%04x]\n", busn, devfn, 
l);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef5377438a1e..ce728251ae36 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "pci.h"
@@ -2517,6 +2518,7 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
  unsigned int available_buses)
 {
unsigned int used_buses, normal_bridges = 0, hotplug_bridges = 0;
+   unsigned int stride = jailhouse_paravirt() ? 1 : 8;
unsigned int start = bus->busn_res.start;
unsigned int devfn, cmax, max = start;
struct pci_dev *dev;
@@ -2524,7 +2526,7 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
dev_dbg(>dev, "scanning bus\n");
 
/* Go find them, Rover! */
-   for (devfn = 0; devfn < 0x100; devfn += 8)
+   for (devfn = 0; devfn < 0x100; devfn += stride)
pci_scan_slot(bus, devfn);
 
/* Reserve buses for SR-IOV capability */
-- 
2.13.6



[PATCH v2 2/6] PCI: Scan all functions when running over Jailhouse

2018-02-27 Thread Jan Kiszka
From: Jan Kiszka 

Per PCIe r4.0, sec 7.5.1.1.9, multi-function devices are required to
have a function 0.  Therefore, Linux scans for devices at function 0
(devfn 0/8/16/...) and only scans for other functions if function 0
has its Multi-Function Device bit set or ARI or SR-IOV indicate
there are more functions.

The Jailhouse hypervisor may pass individual functions of a
multi-function device to a guest without passing function 0, which
means a Linux guest won't find them.

Change Linux PCI probing so it scans all function numbers when
running as a guest over Jailhouse.

This is technically prohibited by the spec, so it is possible that
PCI devices without the Multi-Function Device bit set may have
unexpected behavior in response to this probe.

Based on patch by Benedikt Spranger, adding Jailhouse probing to avoid
changing the behavior in the absence of the hypervisor.

CC: Benedikt Spranger 
Signed-off-by: Jan Kiszka 
Acked-by: Bjorn Helgaas 
---
 arch/x86/pci/legacy.c | 4 +++-
 drivers/pci/probe.c   | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/legacy.c b/arch/x86/pci/legacy.c
index 1cb01abcb1be..dfbe6ac38830 100644
--- a/arch/x86/pci/legacy.c
+++ b/arch/x86/pci/legacy.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -34,13 +35,14 @@ int __init pci_legacy_init(void)
 
 void pcibios_scan_specific_bus(int busn)
 {
+   int stride = jailhouse_paravirt() ? 1 : 8;
int devfn;
u32 l;
 
if (pci_find_bus(0, busn))
return;
 
-   for (devfn = 0; devfn < 256; devfn += 8) {
+   for (devfn = 0; devfn < 256; devfn += stride) {
if (!raw_pci_read(0, busn, devfn, PCI_VENDOR_ID, 2, ) &&
l != 0x && l != 0x) {
DBG("Found device at %02x:%02x [%04x]\n", busn, devfn, 
l);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef5377438a1e..ce728251ae36 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "pci.h"
@@ -2517,6 +2518,7 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
  unsigned int available_buses)
 {
unsigned int used_buses, normal_bridges = 0, hotplug_bridges = 0;
+   unsigned int stride = jailhouse_paravirt() ? 1 : 8;
unsigned int start = bus->busn_res.start;
unsigned int devfn, cmax, max = start;
struct pci_dev *dev;
@@ -2524,7 +2526,7 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
dev_dbg(>dev, "scanning bus\n");
 
/* Go find them, Rover! */
-   for (devfn = 0; devfn < 0x100; devfn += 8)
+   for (devfn = 0; devfn < 0x100; devfn += stride)
pci_scan_slot(bus, devfn);
 
/* Reserve buses for SR-IOV capability */
-- 
2.13.6



Re: [alsa-devel] [PATCH 0/1] Re: Applied "ASoC: topology: Fix logical inversion in set_link_hw_format()" to the asoc tree

2018-02-27 Thread Pierre-Louis Bossart

On 2/27/18 12:33 PM, Kirill Marinushkin wrote:

Hello Mark, Pierre-Louis, Pan, Liam,

As there are too much open questions regarding the bclk and fsync inversion in
set_link_hw_format(), I would like to suggest the alternative solution.

This solution will fit both use-cases:

* existing use-cases (Broadwell, etc.)
* new use-cases (Sound Open Firmware, etc.)

The solution includes 1 patch for linux + 1 patch for alsa-lib.
I will send them to this mailing thread.


That looks acceptable to me, Xiuli can you test with with the matching 
change in the SOF topology macros (we can keep the 'slave' in M4 files 
but expand to 'codec_slave' in the .conf to avoid making this exception 
visible).




Signed-off-by: Kirill Marinushkin 
Cc: Mark Brown 
Cc: Pierre-Louis Bossart 
Cc: Pan Xiuli 
Cc: Liam Girdwood 
Cc: linux-kernel@vger.kernel.org
Cc: alsa-de...@alsa-project.org

Kirill Marinushkin (1):
   ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()

  include/uapi/sound/asoc.h | 16 ++--
  sound/soc/soc-topology.c  | 12 +++-
  2 files changed, 21 insertions(+), 7 deletions(-)





Re: [PATCH 1/2] ARM: dts: imx6: RDU2: Add RAVE SP device

2018-02-27 Thread Shawn Guo
On Mon, Feb 26, 2018 at 06:49:41AM -0800, Andrey Smirnov wrote:
> With MFD and watchdog drivers for RAVE SP device support added by
> 538ee27290fa ("mfd: Add driver for RAVE Supervisory Processor") and
> c3bb33345721 ("watchdog: Add RAVE SP watchdog driver") add
> corresponding DT node for RDU2.
> 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Shawn Guo 
> Cc: Fabio Estevam 
> Cc: Guenter Roeck 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi 
> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> index 72f52fcecee1..460931089509 100644
> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> @@ -305,6 +305,17 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_uart4>;
>   status = "okay";
> +
> + rave-sp {
> + compatible = "zii,rave-sp-rdu2";
> + current-speed = <100>;
> + status = "okay";

The okay status is to flip the state of devices that are initially
disabled.  I think it's unnecessary for the case here.

> +
> + watchdog {
> + compatible = "zii,rave-sp-watchdog";
> + status = "okay";

Ditto

Shawn

> + };
> + };
>  };
>  
>   {
> -- 
> 2.14.3
> 


Re: [alsa-devel] [PATCH 0/1] Re: Applied "ASoC: topology: Fix logical inversion in set_link_hw_format()" to the asoc tree

2018-02-27 Thread Pierre-Louis Bossart

On 2/27/18 12:33 PM, Kirill Marinushkin wrote:

Hello Mark, Pierre-Louis, Pan, Liam,

As there are too much open questions regarding the bclk and fsync inversion in
set_link_hw_format(), I would like to suggest the alternative solution.

This solution will fit both use-cases:

* existing use-cases (Broadwell, etc.)
* new use-cases (Sound Open Firmware, etc.)

The solution includes 1 patch for linux + 1 patch for alsa-lib.
I will send them to this mailing thread.


That looks acceptable to me, Xiuli can you test with with the matching 
change in the SOF topology macros (we can keep the 'slave' in M4 files 
but expand to 'codec_slave' in the .conf to avoid making this exception 
visible).




Signed-off-by: Kirill Marinushkin 
Cc: Mark Brown 
Cc: Pierre-Louis Bossart 
Cc: Pan Xiuli 
Cc: Liam Girdwood 
Cc: linux-kernel@vger.kernel.org
Cc: alsa-de...@alsa-project.org

Kirill Marinushkin (1):
   ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()

  include/uapi/sound/asoc.h | 16 ++--
  sound/soc/soc-topology.c  | 12 +++-
  2 files changed, 21 insertions(+), 7 deletions(-)





Re: [PATCH 1/2] ARM: dts: imx6: RDU2: Add RAVE SP device

2018-02-27 Thread Shawn Guo
On Mon, Feb 26, 2018 at 06:49:41AM -0800, Andrey Smirnov wrote:
> With MFD and watchdog drivers for RAVE SP device support added by
> 538ee27290fa ("mfd: Add driver for RAVE Supervisory Processor") and
> c3bb33345721 ("watchdog: Add RAVE SP watchdog driver") add
> corresponding DT node for RDU2.
> 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Shawn Guo 
> Cc: Fabio Estevam 
> Cc: Guenter Roeck 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi 
> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> index 72f52fcecee1..460931089509 100644
> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> @@ -305,6 +305,17 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_uart4>;
>   status = "okay";
> +
> + rave-sp {
> + compatible = "zii,rave-sp-rdu2";
> + current-speed = <100>;
> + status = "okay";

The okay status is to flip the state of devices that are initially
disabled.  I think it's unnecessary for the case here.

> +
> + watchdog {
> + compatible = "zii,rave-sp-watchdog";
> + status = "okay";

Ditto

Shawn

> + };
> + };
>  };
>  
>   {
> -- 
> 2.14.3
> 


Re: [PATCH] init/Kconfig: make CHECKPOINT_RESTORE select PROC_PAGE_MONITOR

2018-02-27 Thread kbuild test robot
Hi Mike,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc3 next-20180227]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mike-Rapoport/init-Kconfig-make-CHECKPOINT_RESTORE-select-PROC_PAGE_MONITOR/20180228-112508
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

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

warning: (CHECKPOINT_RESTORE && HWPOISON_INJECT && MEM_SOFT_DIRTY) selects 
PROC_PAGE_MONITOR which has unmet direct dependencies (PROC_FS && MMU)
   fs/proc/page.c: In function 'stable_page_flags':
>> fs/proc/page.c:182:36: error: 'PG_mlocked' undeclared (first use in this 
>> function); did you mean 'PG_locked'?
 u |= kpf_copy_bit(k, KPF_MLOCKED, PG_mlocked);
   ^~
   PG_locked
   fs/proc/page.c:182:36: note: each undeclared identifier is reported only 
once for each function it appears in

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


.config.gz
Description: application/gzip


Re: [PATCH] init/Kconfig: make CHECKPOINT_RESTORE select PROC_PAGE_MONITOR

2018-02-27 Thread kbuild test robot
Hi Mike,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc3 next-20180227]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Mike-Rapoport/init-Kconfig-make-CHECKPOINT_RESTORE-select-PROC_PAGE_MONITOR/20180228-112508
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

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

warning: (CHECKPOINT_RESTORE && HWPOISON_INJECT && MEM_SOFT_DIRTY) selects 
PROC_PAGE_MONITOR which has unmet direct dependencies (PROC_FS && MMU)
   fs/proc/page.c: In function 'stable_page_flags':
>> fs/proc/page.c:182:36: error: 'PG_mlocked' undeclared (first use in this 
>> function); did you mean 'PG_locked'?
 u |= kpf_copy_bit(k, KPF_MLOCKED, PG_mlocked);
   ^~
   PG_locked
   fs/proc/page.c:182:36: note: each undeclared identifier is reported only 
once for each function it appears in

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


.config.gz
Description: application/gzip


[PATCH] m68k: Use read_persistent_clock64() instead of read_persistent_clock()

2018-02-27 Thread Baolin Wang
Since struct timespec is not y2038 safe on 32bit machines, this patch
converts read_persistent_clock() to read_persistent_clock64() using
struct timespec64, as well as converting mktime() to mktime64().

Signed-off-by: Baolin Wang 
---
 arch/m68k/kernel/time.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 87160b4..8cd79c9 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -71,7 +71,7 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
return IRQ_HANDLED;
 }
 
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
struct rtc_time time;
ts->tv_sec = 0;
@@ -82,7 +82,7 @@ void read_persistent_clock(struct timespec *ts)
 
if ((time.tm_year += 1900) < 1970)
time.tm_year += 100;
-   ts->tv_sec = mktime(time.tm_year, time.tm_mon, time.tm_mday,
+   ts->tv_sec = mktime64(time.tm_year, time.tm_mon, time.tm_mday,
  time.tm_hour, time.tm_min, time.tm_sec);
}
 }
-- 
1.7.9.5



[PATCH] m68k: Use read_persistent_clock64() instead of read_persistent_clock()

2018-02-27 Thread Baolin Wang
Since struct timespec is not y2038 safe on 32bit machines, this patch
converts read_persistent_clock() to read_persistent_clock64() using
struct timespec64, as well as converting mktime() to mktime64().

Signed-off-by: Baolin Wang 
---
 arch/m68k/kernel/time.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 87160b4..8cd79c9 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -71,7 +71,7 @@ static irqreturn_t timer_interrupt(int irq, void *dummy)
return IRQ_HANDLED;
 }
 
-void read_persistent_clock(struct timespec *ts)
+void read_persistent_clock64(struct timespec64 *ts)
 {
struct rtc_time time;
ts->tv_sec = 0;
@@ -82,7 +82,7 @@ void read_persistent_clock(struct timespec *ts)
 
if ((time.tm_year += 1900) < 1970)
time.tm_year += 100;
-   ts->tv_sec = mktime(time.tm_year, time.tm_mon, time.tm_mday,
+   ts->tv_sec = mktime64(time.tm_year, time.tm_mon, time.tm_mday,
  time.tm_hour, time.tm_min, time.tm_sec);
}
 }
-- 
1.7.9.5



  1   2   3   4   5   6   7   8   9   10   >