[PATCH] kernel/extable.c: mark core_kernel_text notrace

[Marcin Nowakowski]

core_kernel_text is used by MIPS in its function graph trace processing,
so having this method traced leads to an infinite set of recursive calls
such as:

[2.972075] Call Trace:
[2.972111]
[2.976731] [<80506584>] ftrace_return_to_handler+0x50/0x128
[2.983379] [<8045478c>] core_kernel_text+0x10/0x1b8
[2.989146] [<804119b8>] prepare_ftrace_return+0x6c/0x114
[2.995402] [<80411b2c>] ftrace_graph_caller+0x20/0x44
[3.001362] [<80411b60>] return_to_handler+0x10/0x30
[3.007159] [<80411b50>] return_to_handler+0x0/0x30
[3.012827] [<80411b50>] return_to_handler+0x0/0x30
[3.018621] [<804e589c>] ftrace_ops_no_ops+0x114/0x1bc
[3.024602] [<8045478c>] core_kernel_text+0x10/0x1b8
[3.030377] [<8045478c>] core_kernel_text+0x10/0x1b8
[3.036140] [<8045478c>] core_kernel_text+0x10/0x1b8
[3.041915] [<804e589c>] ftrace_ops_no_ops+0x114/0x1bc
[3.047923] [<8045478c>] core_kernel_text+0x10/0x1b8
[3.053682] [<804119b8>] prepare_ftrace_return+0x6c/0x114
[3.059938] [<80411b2c>] ftrace_graph_caller+0x20/0x44
(...)

Mark the function notrace to avoid it being traced.

Signed-off-by: Marcin Nowakowski 
---
 kernel/extable.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/extable.c b/kernel/extable.c
index 2676d7f..4efaf26 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -70,7 +70,7 @@ static inline int init_kernel_text(unsigned long addr)
return 0;
 }
 
-int core_kernel_text(unsigned long addr)
+int notrace core_kernel_text(unsigned long addr)
 {
if (addr >= (unsigned long)_stext &&
addr < (unsigned long)_etext)
-- 
2.7.4

[PATCH v2] acpi: handle the acpi hotplug schedule error

[Lee, Chun-Yi]

Kernel should decrements the reference count of acpi device
when the scheduling of acpi hotplug work is failed, and
evaluates _OST to notify BIOS the failure.

v2:
To simplify the code. (Andy Shevchenko)

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Michal Hocko 
Reviewed-by: Andy Shevchenko 
Signed-off-by: "Lee, Chun-Yi" 
---
 drivers/acpi/bus.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..91adb71 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -427,12 +427,17 @@ static void acpi_bus_notify(acpi_handle handle, u32 type, 
void *data)
(driver->flags & ACPI_DRIVER_ALL_NOTIFY_EVENTS))
driver->ops.notify(adev, type);
 
-   if (hotplug_event && ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
-   return;
+   if (hotplug_event) {
+   if (ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
+   return;
+   goto err_put_device;
+   }
 
acpi_bus_put_acpi_device(adev);
return;
 
+ err_put_device:
+   acpi_bus_put_acpi_device(adev);
  err:
acpi_evaluate_ost(handle, type, ost_code, NULL);
 }
-- 
2.10.2

Re: [RFC PATCH v2 1/3] drm: atmel-hlcdc: add support for 8-bit color lookup table mode

[Daniel Vetter]

On Tue, Jun 20, 2017 at 11:55:01AM +0200, Peter Rosin wrote:
> On 2017-06-20 11:40, Daniel Vetter wrote:
> > On Sat, Jun 17, 2017 at 07:48:02PM +0200, Peter Rosin wrote:
> >> All layers of all supported chips support this, the only variable is the
> >> base address of the lookup table in the register map.
> >>
> >> Signed-off-by: Peter Rosin 
> > 
> > As Boris said, pls use the new color manager stuff for atomic drivers, and
> > then use the helper to implement the legacy kms LUT support on top of it,
> > it's drm_atomic_helper_legacy_gamma_set().
> > -Daniel
> 
> Hmm, I don't see how this comment applies to this patch? Isn't this
> patch good as is, because I thought I already did wire this up with
> the drm_atomic_helper_legacy_gamma_set helper as requested?
> (sure, v3 has a register offset tweak, but that's just a detail)
> 
> I totally agree that 2/3 and 3/3 are ugly and I am working on that, but
> if 1/3 is also not in the right direction I'd like to know ASAP. Thanks!

Sorry, I must have mixed up your patches. This one here indeed looks like
it does things properly. For this one here:

Acked-by: Daniel Vetter 

Cheers, Daniel

> 
> Cheers,
> peda
> 
> > 
> >> ---
> >>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  5 +
> >>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 13 +++
> >>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 16 ++
> >>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 29 
> >> +
> >>  4 files changed, 63 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> index 5348985..694adcc 100644
> >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> @@ -429,6 +429,8 @@ static const struct drm_crtc_funcs 
> >> atmel_hlcdc_crtc_funcs = {
> >>.atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
> >>.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
> >>.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
> >> +  .set_property = drm_atomic_helper_crtc_set_property,
> >> +  .gamma_set = drm_atomic_helper_legacy_gamma_set,
> >>  };
> >>  
> >>  int atmel_hlcdc_crtc_create(struct drm_device *dev)
> >> @@ -484,6 +486,9 @@ int atmel_hlcdc_crtc_create(struct drm_device *dev)
> >>drm_crtc_helper_add(&crtc->base, &lcdc_crtc_helper_funcs);
> >>drm_crtc_vblank_reset(&crtc->base);
> >>  
> >> +  drm_mode_crtc_set_gamma_size(&crtc->base, ATMEL_HLCDC_CLUT_SIZE);
> >> +  drm_crtc_enable_color_mgmt(&crtc->base, 0, false, 
> >> ATMEL_HLCDC_CLUT_SIZE);
> >> +
> >>dc->crtc = &crtc->base;
> >>  
> >>return 0;
> >> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> >> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> index 30dbffd..4f6ef07 100644
> >> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> @@ -42,6 +42,7 @@ static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_at91sam9n12_layers[] = {
> >>.default_color = 3,
> >>.general_config = 4,
> >>},
> >> +  .clut_offset = 0x400,
> >>},
> >>  };
> >>  
> >> @@ -73,6 +74,7 @@ static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_at91sam9x5_layers[] = {
> >>.disc_pos = 5,
> >>.disc_size = 6,
> >>},
> >> +  .clut_offset = 0x400,
> >>},
> >>{
> >>.name = "overlay1",
> >> @@ -91,6 +93,7 @@ static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_at91sam9x5_layers[] = {
> >>.chroma_key_mask = 8,
> >>.general_config = 9,
> >>},
> >> +  .clut_offset = 0x800,
> >>},
> >>{
> >>.name = "high-end-overlay",
> >> @@ -112,6 +115,7 @@ static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_at91sam9x5_layers[] = {
> >>.scaler_config = 13,
> >>.csc = 14,
> >>},
> >> +  .clut_offset = 0x1000,
> >>},
> >>{
> >>.name = "cursor",
> >> @@ -131,6 +135,7 @@ static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_at91sam9x5_layers[] = {
> >>.chroma_key_mask = 8,
> >>.general_config = 9,
> >>},
> >> +  .clut_offset = 0x1400,
> >>},
> >>  };
> >>  
> >> @@ -162,6 +167,7 @@ static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_sama5d3_layers[] = {
> >>.disc_pos = 5,
> >>.disc_size = 6,
> >>},
> >> +  .clut_offset = 0x600,
> >>},
> >>{
> >>.name = "overlay1",
> >> @@ -180,6 +186,7 @@ static const struct atmel_hlcdc_layer_desc 
> >> atmel_hlcdc_sama5d3_layers[] = {
> >>.chroma_key_mask = 8,
> >>.general_config = 9,
> >>},
> >> +  .clut_offset = 0xa

Re: [PATCH 3.10 268/268] mm: larger stack guard gap, between vmas

[Hugh Dickins]

On Mon, 19 Jun 2017, Willy Tarreau wrote:

> From: Hugh Dickins 
> 
> commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

Some of these suggested adjustments below are just what comparing mine
and yours showed up, and I'm being anal in passing them on e.g. I do
like your blank line in mm.h, but Michal chose to leave it out, and
I think that the closer we keep these sources to each other,
the less trouble we shall have patching on top in future.

Which is particularly true in expand_upwards() and expand_downwards()
(and you're thinking of backporting Helge's TASK_SIZE enhancement
on top of that, though I don't think it's strictly necessary for a
stable tree).  Your patch is not wrong there: though odd to be trying
anon_vma_prepare() twice in expand_downwards(), and tiresome to have
to unlock at each error exit.  But I'd already decided in one of our
internal trees just to factor in some of Konstantin's change, that
made the ordering much more sensible there, and the two more like
each other; so recommend that 3.10 do the same, keeping it closer
to the final 4.12 code.  But you may have different priorities and
disagree with that: just suggesting.

And there is the possibility that we shall want another patch or
two on top there.  I've left a question as to whether we should be
comparing anon_vmas.  And there's a potential (but I think ignorable)
locking issue, in the case of an architecture that supports both
VM_GROWSUP and VM_GROWSDOWN: if they expand towards each other at the
same instant, they could gobble up the gap between them (they almost
certainly have different anon_vmas, so the anon_vma locking does not
protect against that).  When it gets to updating the vma tree, it is
careful to use page_table_lock to maintain the consistency of the
tree in such a case, but maybe we should do that earlier.

Then there's the FOLL_MLOCK thing, and the WARN_ON (phew, remembered
in time that you don't have VM_WARN_ON) - but keep in mind that I
have not even built this tree, let alone tested it.

Sorry if I'm being annoying, Willy: you must be heartily sick of
these patches by now!  Or, being a longtime longterm maintainer,
perhaps it's all joy for you ;-?

Hugh

diff -purN 310n/include/linux/mm.h 310h/include/linux/mm.h
--- 310n/include/linux/mm.h 2017-06-20 16:50:29.809546868 -0700
+++ 310h/include/linux/mm.h 2017-06-20 19:52:59.359942133 -0700
@@ -1595,7 +1595,6 @@ unsigned long ra_submit(struct file_ra_s
struct file *filp);
 
 extern unsigned long stack_guard_gap;
-
 /* Generic expand stack which grows the stack according to GROWS{UP,DOWN} */
 extern int expand_stack(struct vm_area_struct *vma, unsigned long address);
 
diff -purN 310n/mm/memory.c 310h/mm/memory.c
--- 310n/mm/memory.c2017-06-20 16:50:29.809546868 -0700
+++ 310h/mm/memory.c2017-06-20 19:57:14.537573559 -0700
@@ -1821,9 +1821,6 @@ long __get_user_pages(struct task_struct
int ret;
unsigned int fault_flags = 0;
 
-   /* mlock all present pages, but do not fault in 
new pages */
-   if (foll_flags & FOLL_MLOCK)
-   goto next_page;
if (foll_flags & FOLL_WRITE)
fault_flags |= FAULT_FLAG_WRITE;
if (nonblocking)
diff -purN 310n/mm/mmap.c 310h/mm/mmap.c
--- 310n/mm/mmap.c  2017-06-20 16:50:29.809546868 -0700
+++ 310h/mm/mmap.c  2017-06-20 20:48:08.409202485 -0700
@@ -892,7 +892,7 @@ again:  remove_next = 1 + (end > next->
else if (next)
vma_gap_update(next);
else
-   mm->highest_vm_end = end;
+   WARN_ON(mm->highest_vm_end != vm_end_gap(vma));
}
if (insert && file)
uprobe_mmap(insert);
@@ -2123,48 +2123,39 @@ int expand_upwards(struct vm_area_struct
 {
struct vm_area_struct *next;
unsigned long gap_addr;
-   int error;
+   int error = 0;
 
if (!(vma->vm_flags & VM_GROWSUP))
return -EFAULT;
 
-   /*
-* We must make sure the anon_vma is allocated
-* so that the anon_vma locking is not a noop.
-*/
-   if (unlikely(anon_vma_prepare(vma)))
-   return -ENOMEM;
-   vma_lock_anon_vma(vma);
-
-   /*
-* vma->vm_start/vm_end cannot change under us because the caller
-* is required to hold the mmap_sem in read mode.  We need the
-* anon_vma lock to serialize against concurrent expand_stacks.
-* Also guard against wrapping around to address 0.
-*/
+   /* Guard against wrapping around to address 0. */
address &= PAGE_MASK;
address += PAGE_SIZE;
-   if (!address) {
-   vma_unlock_anon_vma(vma);
+   if (!address)
return -ENO

Re: [PATCH v2] PM / Domains: Call driver's noirq callbacks

[Mikko Perttunen]

On 20.06.2017 17:18, Ulf Hansson wrote:

On 20 June 2017 at 15:38, Mikko Perttunen  wrote:

Currently genpd installs its own suspend_noirq, resume_noirq,
and poweroff_noirq callbacks, but never calls down to the driver's
corresponding callbacks. Add these calls.

Signed-off-by: Mikko Perttunen 
---
v2:
- Moved pm_generic_suspend_noirq to before pm_runtime_force_suspend,
  and correspondingly pm_generic_resume_noirq after
  pm_runtime_force_resume
- Added new pm_genpd_poweroff_noirq callback that is identical to
  pm_genpd_suspend_noirq but calls the appropriate driver callback

 drivers/base/power/domain.c | 50 -
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index d3f1d96f75e9..b070ee58186d 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -919,6 +919,10 @@ static int pm_genpd_suspend_noirq(struct device *dev)
if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
return 0;

+   ret = pm_generic_suspend_noirq(dev);
+   if (ret)
+   return ret;
+
if (genpd->dev_ops.stop && genpd->dev_ops.start) {
ret = pm_runtime_force_suspend(dev);
if (ret)
@@ -961,6 +965,10 @@ static int pm_genpd_resume_noirq(struct device *dev)
if (genpd->dev_ops.stop && genpd->dev_ops.start)
ret = pm_runtime_force_resume(dev);

+   ret = pm_generic_resume_noirq(dev);
+   if (ret)
+   return ret;
+
return ret;
 }

@@ -1015,6 +1023,46 @@ static int pm_genpd_thaw_noirq(struct device *dev)
 }

 /**
+ * pm_genpd_poweroff_noirq - Completion of hibernation of device in an
+ *   I/O PM domain.
+ * @dev: Device to poweroff.
+ *
+ * Stop the device and remove power from the domain if all devices in it have
+ * been stopped.
+ */
+static int pm_genpd_poweroff_noirq(struct device *dev)
+{
+   struct generic_pm_domain *genpd;
+   int ret;
+
+   dev_dbg(dev, "%s()\n", __func__);
+
+   genpd = dev_to_genpd(dev);
+   if (IS_ERR(genpd))
+   return -EINVAL;
+
+   if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
+   return 0;
+
+   ret = pm_generic_poweroff_noirq(dev);


The only difference between  pm_genpd_suspend_noirq() and
pm_genpd_poweroff_noirq() is the above line. Can we re-factor the code
so we avoid open code here, please.


I wasn't sure if the functions' complexity warranted adding a helper 
function, but sure, I'll refactor this with a helper function.





+   if (ret)
+   return ret;
+
+   if (genpd->dev_ops.stop && genpd->dev_ops.start) {
+   ret = pm_runtime_force_suspend(dev);
+   if (ret)
+   return ret;
+   }
+
+   genpd_lock(genpd);
+   genpd->suspended_count++;
+   genpd_sync_power_off(genpd, true, 0);
+   genpd_unlock(genpd);
+
+   return 0;
+}
+
+/**
  * pm_genpd_restore_noirq - Start of restore of device in an I/O PM domain.
  * @dev: Device to resume.
  *
@@ -1493,7 +1541,7 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
genpd->domain.ops.resume_noirq = pm_genpd_resume_noirq;
genpd->domain.ops.freeze_noirq = pm_genpd_freeze_noirq;
genpd->domain.ops.thaw_noirq = pm_genpd_thaw_noirq;
-   genpd->domain.ops.poweroff_noirq = pm_genpd_suspend_noirq;
+   genpd->domain.ops.poweroff_noirq = pm_genpd_poweroff_noirq;
genpd->domain.ops.restore_noirq = pm_genpd_restore_noirq;


The pm_genpd_restore_noirq() doesn't invokes the lower level
->restore_noirq() callbacks. If you are going to change that for the
*poweroff* callback, certainly we should change that also for the
*restore* callbacks as well. Don't you think?

Moreover, what about the freeze and thaw callbacks, should these also
walk the lower level callbacks?


Yes, I'll add the calls to the rest of the ops as well.

Thanks,
Mikko.




genpd->domain.ops.complete = pm_genpd_complete;

--
2.1.4



Kind regards
Uffe

[PATCH 0/2] platform/x86: add const to thermal_cooling_device_ops structures

[Bhumika Goyal]

Declare thermal_cooling_device_ops structures as const.

Bhumika Goyal (2):
  acerhdf: add const to thermal_cooling_device_ops structure
  intel_menlow: add const to thermal_cooling_device_ops structure

 drivers/platform/x86/acerhdf.c  | 2 +-
 drivers/platform/x86/intel_menlow.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.7.4

[PATCH 2/2] intel_menlow: add const to thermal_cooling_device_ops structure

[Bhumika Goyal]

Declare thermal_cooling_device_ops structure as const as it is only passed
as an argument to the function thermal_cooling_device_register and this
argument is of type const. So, declare the structure as const.

Signed-off-by: Bhumika Goyal 
---
 drivers/platform/x86/intel_menlow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_menlow.c 
b/drivers/platform/x86/intel_menlow.c
index cbe0102..ef9b0af 100644
--- a/drivers/platform/x86/intel_menlow.c
+++ b/drivers/platform/x86/intel_menlow.c
@@ -142,7 +142,7 @@ static int memory_set_cur_bandwidth(struct 
thermal_cooling_device *cdev,
return 0;
 }
 
-static struct thermal_cooling_device_ops memory_cooling_ops = {
+static const struct thermal_cooling_device_ops memory_cooling_ops = {
.get_max_state = memory_get_max_bandwidth,
.get_cur_state = memory_get_cur_bandwidth,
.set_cur_state = memory_set_cur_bandwidth,
-- 
2.7.4

Re: [PATCH] drm: armada: make of_device_ids const.

[Daniel Vetter]

On Tue, Jun 20, 2017 at 10:44:33AM +0530, Arvind Yadav wrote:
> of_device_ids are not supposed to change at runtime. All functions
> working with of_device_ids provided by  work with const
> of_device_ids. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>8836   744   09580256c 
> drivers/gpu/drm/armada/armada_crtc.o
> 
> File size after constify armada_lcd_of_match:
>text  data bss dec hex filename
>9220   328   09548254c 
> drivers/gpu/drm/armada/armada_crtc.o
> 
> Signed-off-by: Arvind Yadav 

Applied to drm-misc-next, thanks.
-Daniel

> ---
>  drivers/gpu/drm/armada/armada_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 4fe19fd..94b76bd 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -1364,7 +1364,7 @@ static int armada_lcd_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> -static struct of_device_id armada_lcd_of_match[] = {
> +static const struct of_device_id armada_lcd_of_match[] = {
>   {
>   .compatible = "marvell,dove-lcd",
>   .data   = &armada510_ops,
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/2] acerhdf: add const to thermal_cooling_device_ops structure

[Bhumika Goyal]

Declare thermal_cooling_device_ops structure as const as it is only passed
as an argument to the function thermal_cooling_device_register and this
argument is of type const. So, declare the structure as const.

Signed-off-by: Bhumika Goyal 
---
 drivers/platform/x86/acerhdf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 2acdb0d..ea22591 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -557,7 +557,7 @@ static int acerhdf_set_cur_state(struct 
thermal_cooling_device *cdev,
 }
 
 /* bind fan callbacks to fan device */
-static struct thermal_cooling_device_ops acerhdf_cooling_ops = {
+static const struct thermal_cooling_device_ops acerhdf_cooling_ops = {
.get_max_state = acerhdf_get_max_state,
.get_cur_state = acerhdf_get_cur_state,
.set_cur_state = acerhdf_set_cur_state,
-- 
2.7.4

[PATCH] drm/udl: Make page_flip asynchronous

[Dawid Kurek]

In page_flip vblank is sent with no delay. Driver does not know when the
actual update is present on the display and has no means for getting
this information from a device. It is practically impossible to say
exactly *when* as there is also i.e. a usb delay.

When we are unable to determine when the vblank actually happens we may
assume it will behave accordingly, i.e. it will present frames with
proper timing. In the worst case scenario it should take up to duration
of one frame (we may get new frame in the device just after presenting
current one so we would need to wait for the whole frame).

Because of the asynchronous nature of the delay we need to synchronize:
 * read/write vrefresh/page_flip data when changing mode and
   preparing/executing vblank
 * USB requests to prevent interleaved access to URBs for two different
   frame buffers

All those changes are backports from ChromeOS:
  1. https://chromium-review.googlesource.com/250622
  2. https://chromium-review.googlesource.com/249450
  partially, only change in udl_modeset.c for 'udl_flip_queue'
  3. https://chromium-review.googlesource.com/321378
  4. https://chromium-review.googlesource.com/324119
+ fixes for checkpatch and latest drm changes

Cc: h...@chromium.org
Cc: marc...@chromium.org
Cc: za...@chromium.org
Cc: db...@google.com
Signed-off-by: Dawid Kurek 
---
 drivers/gpu/drm/udl/udl_drv.h |   4 +
 drivers/gpu/drm/udl/udl_fb.c  |  28 ---
 drivers/gpu/drm/udl/udl_main.c|   3 +
 drivers/gpu/drm/udl/udl_modeset.c | 160 ++
 4 files changed, 171 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 2a75ab8..b93fb8d 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -47,6 +47,7 @@ struct urb_list {
 };
 
 struct udl_fbdev;
+struct udl_flip_queue;
 
 struct udl_device {
struct device *dev;
@@ -66,6 +67,9 @@ struct udl_device {
atomic_t bytes_identical; /* saved effort with backbuffer comparison */
atomic_t bytes_sent; /* to usb, after compression including overhead */
atomic_t cpu_kcycles_used; /* transpired during pixel processing */
+
+   struct udl_flip_queue *flip_queue;
+   struct mutex transfer_lock; /* to serialize transfers */
 };
 
 struct udl_gem_object {
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 4a65003..6dd9a49 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -82,7 +82,7 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, int 
y,
 {
struct drm_device *dev = fb->base.dev;
struct udl_device *udl = dev->dev_private;
-   int i, ret;
+   int i, ret = 0;
char *cmd;
cycles_t start_cycles, end_cycles;
int bytes_sent = 0;
@@ -91,18 +91,22 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
int aligned_x;
int bpp = fb->base.format->cpp[0];
 
+   mutex_lock(&udl->transfer_lock);
+
if (!fb->active_16)
-   return 0;
+   goto out;
 
if (!fb->obj->vmapping) {
ret = udl_gem_vmap(fb->obj);
if (ret == -ENOMEM) {
DRM_ERROR("failed to vmap fb\n");
-   return 0;
+   ret = 0;
+   goto out;
}
if (!fb->obj->vmapping) {
DRM_ERROR("failed to vmapping\n");
-   return 0;
+   ret = 0;
+   goto out;
}
}
 
@@ -112,14 +116,18 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
 
if ((width <= 0) ||
(x + width > fb->base.width) ||
-   (y + height > fb->base.height))
-   return -EINVAL;
+   (y + height > fb->base.height)) {
+   ret = -EINVAL;
+   goto out;
+   }
 
start_cycles = get_cycles();
 
urb = udl_get_urb(dev);
-   if (!urb)
-   return 0;
+   if (!urb) {
+   ret = 0;
+   goto out;
+   }
cmd = urb->transfer_buffer;
 
for (i = y; i < y + height ; i++) {
@@ -151,7 +159,9 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
>> 10)), /* Kcycles */
   &udl->cpu_kcycles_used);
 
-   return 0;
+out:
+   mutex_unlock(&udl->transfer_lock);
+   return ret;
 }
 
 static int udl_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index a9d93b8..d376233 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -319,6 +319,8 @@ int udl_driver_load(struct drm_device *dev, unsigned long 
flags)
if (!udl)
return -ENOMEM;
 
+   mutex_init(&udl->transfer_lock);
+
udl->udev = ud

Re: [PATCH v3 2/2] acpi, gicv3-its, numa: Adding numa node mapping for gic-its units

[Jayachandran C]

On Wed, Jun 21, 2017 at 11:45:43AM +0530, Ganapatrao Kulkarni wrote:
> Add code to parse SRAT ITS Affinity sub table as defined in ACPI 6.2
> Later in per device probe, ITS devices are mapped to
> numa node using ITS id to proximity domain mapping.
> 
> Signed-off-by: Ganapatrao Kulkarni 
> ---
>  drivers/irqchip/irq-gic-v3-its.c | 80 
> +++-
>  1 file changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
> b/drivers/irqchip/irq-gic-v3-its.c
> index 45ea1933..88cfb32 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1833,6 +1833,82 @@ static int __init its_of_probe(struct device_node 
> *node)
>  
>  #define ACPI_GICV3_ITS_MEM_SIZE (SZ_128K)
>  
> +#ifdef CONFIG_ACPI_NUMA
> +struct its_srat_map {
> + u32 numa_node;  /* numa node id */
> + u32 its_id;  /* GIC ITS ID */
> +};
> +
> +static struct its_srat_map its_srat_maps[MAX_NUMNODES] __initdata = {
> + [0 ... MAX_NUMNODES - 1] = {NUMA_NO_NODE, UINT_MAX} };
> +
> +static int its_in_srat __initdata;
> +
> +static int __init
> +acpi_get_its_numa_node(u32 its_id)
> +{
> + int i;
> +
> + for (i = 0; i < its_in_srat; i++) {
> + if (its_id == its_srat_maps[i].its_id)
> + return its_srat_maps[i].numa_node;
> + }
> + return NUMA_NO_NODE;
> +}
> +
> +static int __init
> +gic_acpi_parse_srat_its(struct acpi_subtable_header *header,
> +  const unsigned long end)
> +{
> + int pxm, node;
> + struct acpi_srat_its_affinity *its_affinity;
> +
> + its_affinity = (struct acpi_srat_its_affinity *)header;
> + if (!its_affinity)
> + return -EINVAL;
> +
> + if (its_affinity->header.length <
> + sizeof(struct acpi_srat_its_affinity)) {
> + pr_err("SRAT:ITS: Invalid SRAT header length: %d\n",
> + its_affinity->header.length);

The original driver does not use pr_fmt properly, it may be worth
fixing that up rather than having prefixes, here...

> + return -EINVAL;
> + }
> +
> + if (its_in_srat >= MAX_NUMNODES) {
> + pr_err("SRAT:ITS: ITS devices exceeding max count[%d]\n",
> + MAX_NUMNODES);
> + return -EINVAL;
> + }
> +
> + pxm = its_affinity->proximity_domain;
> + node = acpi_map_pxm_to_node(pxm);
> +
> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> + pr_err("SRAT:ITS: Invalid numa node %d\n", node);

here.

> + return -EINVAL;
> + }
> +
> + its_srat_maps[its_in_srat].numa_node = node;
> + its_srat_maps[its_in_srat].its_id = its_affinity->its_id;
> + its_in_srat++;
> + pr_info("ACPI: NUMA: SRAT: ITS: PXM %d -> ITS_ID %d -> NODE %d\n",
> + pxm, its_affinity->its_id, node);

also here.

> +
> + return 0;
> +}
> +
> +static int __init acpi_table_parse_srat_its(void)
> +{
> + return acpi_table_parse_entries(ACPI_SIG_SRAT,
> + sizeof(struct acpi_table_srat),
> + ACPI_SRAT_TYPE_GIC_ITS_AFFINITY,
> + gic_acpi_parse_srat_its, 0);
> +}
> +#else
> +#define acpi_table_parse_srat_its()  do { } while (0)

The function implementation returns a value, but this does not, it is
better to be consistent here.

> +#define acpi_get_its_numa_node(its_id)   NUMA_NO_NODE
> +#endif
> +
>  static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header 
> *header,
> const unsigned long end)
>  {
> @@ -1861,7 +1937,8 @@ static int __init gic_acpi_parse_madt_its(struct 
> acpi_subtable_header *header,
>   goto dom_err;
>   }
>  
> - err = its_probe_one(&res, dom_handle, NUMA_NO_NODE);
> + err = its_probe_one(&res, dom_handle,
> + acpi_get_its_numa_node(its_entry->translation_id));
>   if (!err)
>   return 0;
>  
> @@ -1873,6 +1950,7 @@ static int __init gic_acpi_parse_madt_its(struct 
> acpi_subtable_header *header,
>  
>  static void __init its_acpi_probe(void)
>  {
> + acpi_table_parse_srat_its();
>   acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> gic_acpi_parse_madt_its, 0);
>  }

JC.

[NOT-FOR-MERGE V8 4/6] soc: qcom: rpmpd: Add support for get/set performance state

[Viresh Kumar]

From: Rajendra Nayak 

THIS IS TEST CODE, SHOULDN'T BE MERGED.

With genpd now expecting powerdomain drivers supporting performance
state to support get/set performance state callbacks, add support for it
in the rpmpd driver.

NOT-signed-off-by: Rajendra Nayak 
NOT-signed-off-by: Viresh Kumar 
---
 drivers/soc/qcom/rpmpd.c | 100 +++
 1 file changed, 100 insertions(+)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index d34d9c363815..7ef81429c5c5 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -101,6 +101,20 @@ struct rpmpd_desc {
size_t num_pds;
 };
 
+enum rpmpd_levels {
+   NONE,
+   LOWER,  /* SVS2 */
+   LOW,/* SVS */
+   NOMINAL,/* NOMINAL */
+   HIGH,   /* Turbo */
+   MAX_LEVEL,
+};
+
+struct rpmpd_freq_map {
+   struct rpmpd *pd;
+   unsigned long freq[MAX_LEVEL];
+};
+
 static DEFINE_MUTEX(rpmpd_lock);
 
 /* msm8996 RPM powerdomains */
@@ -126,6 +140,47 @@ static const struct rpmpd_desc msm8996_desc = {
.num_pds = ARRAY_SIZE(msm8996_rpmpds),
 };
 
+enum msm8996_devices {
+   SDHCI,
+   UFS,
+   PCIE,
+   USB3,
+};
+
+static struct rpmpd_freq_map msm8996_rpmpd_freq_map[] = {
+   [SDHCI] = {
+   .pd = &msm8996_vddcx,
+   .freq[LOWER] = 1920,
+   .freq[LOW] = 2,
+   .freq[NOMINAL] = 4,
+   },
+   [UFS] = {
+   .pd = &msm8996_vddcx,
+   .freq[LOWER] = 1920,
+   .freq[LOW] = 1,
+   .freq[NOMINAL] = 2,
+   .freq[HIGH] = 24000,
+   },
+   [PCIE] = {
+   .pd = &msm8996_vddcx,
+   .freq[LOWER] = 1011000,
+   },
+   [USB3] = {
+   .pd = &msm8996_vddcx,
+   .freq[LOWER] = 6000,
+   .freq[LOW] = 12000,
+   .freq[NOMINAL] = 15000,
+   },
+};
+
+static const struct of_device_id rpmpd_performance_table[] = {
+   { .compatible = "qcom,sdhci-msm-v4", .data = (void *)SDHCI },
+   { .compatible = "qcom,ufshc", .data = (void *)UFS },
+   { .compatible = "qcom,pcie-msm8996", .data = (void *)PCIE },
+   { .compatible = "qcom,dwc3", .data = (void *)USB3 },
+   { }
+};
+
 static const struct of_device_id rpmpd_match_table[] = {
{ .compatible = "qcom,rpmpd-msm8996", .data = &msm8996_desc },
{ }
@@ -230,6 +285,49 @@ static int rpmpd_power_off(struct generic_pm_domain 
*domain)
return ret;
 }
 
+static int rpmpd_set_performance(struct generic_pm_domain *domain,
+unsigned int state)
+{
+   int ret = 0;
+   struct rpmpd *pd = domain_to_rpmpd(domain);
+
+   mutex_lock(&rpmpd_lock);
+
+   pd->corner = state;
+
+   if (!pd->enabled && (pd->key != KEY_FLOOR_CORNER))
+   goto out;
+
+   ret = rpmpd_aggregate_corner(pd);
+
+out:
+   mutex_unlock(&rpmpd_lock);
+
+   return ret;
+}
+
+
+static int rpmpd_get_performance(struct device *dev, unsigned long rate)
+{
+   int i;
+   unsigned long index;
+   const struct of_device_id *id;
+
+   if (!rate)
+   return 0;
+
+   id = of_match_device(rpmpd_performance_table, dev);
+   if (!id)
+   return -EINVAL;
+
+   index = (unsigned long)id->data;
+   for (i = 0; i < MAX_LEVEL; i++)
+   if (msm8996_rpmpd_freq_map[index].freq[i] >= rate)
+   return i;
+
+   return MAX_LEVEL;
+}
+
 static int rpmpd_probe(struct platform_device *pdev)
 {
int i;
@@ -267,6 +365,8 @@ static int rpmpd_probe(struct platform_device *pdev)
rpmpds[i]->rpm = rpm;
rpmpds[i]->pd.power_off = rpmpd_power_off;
rpmpds[i]->pd.power_on = rpmpd_power_on;
+   rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
+   rpmpds[i]->pd.get_performance_state = rpmpd_get_performance;
pm_genpd_init(&rpmpds[i]->pd, NULL, true);
 
data->domains[i] = &rpmpds[i]->pd;
-- 
2.13.0.71.gd7076ec9c9cb

[PATCH V8 0/6] PM / Domains: Power domain performance states

[Viresh Kumar]

Hi,

Some platforms have the capability to configure the performance state of
their power domains. The process of configuring the performance state is
pretty much platform dependent and we may need to work with a wide range
of configurables.  For some platforms, like Qcom, it can be a positive
integer value alone, while in other cases it can be voltage levels, etc.

The power-domain framework until now was only designed for the idle
state management of the device and this needs to change in order to
reuse the power-domain framework for active state management of the
devices.

The first patch updates the genpd framework to supply new APIs to
support active state management and the second patch uses them from the
OPP core.

Rest of the patches [3-6/6] are included just to show how user drivers
would end up using the new APIs and these patches aren't there to get
merged and are marked clearly like that.

The ideal way is still to get the relation between device and domain
states via the DT instead of platform code, but that can be done
incrementally later once we have some users for it upstream.

This is currently tested by:
- me by hacking the kernel a bit with virtual power-domains for the dual
  A15 exynos platform. I have also tested the complex cases where the
  device's parent power domain doesn't have set_performance_state()
  callback set, but parents of that domains have it. Lockdep configs
  were enabled for these tests.
- Rajendra Nayak, on msm8996 platform (Qcom) with MMC controller.

Thanks Rajendra for helping me testing this out.

Pushed here as well:

https://git.linaro.org/people/viresh.kumar/linux.git/log/?h=opp/genpd-performance-state

Rebased on: 4.12-rc6 + some OPP core changes [1] and [2].

V7->V8:
- Ulf helped a lot in reviewing V7 and pointed out couple of issues,
  specially in locking while dealing with a hierarchy of power domains.
- All those locking issues are sorted out now, even for the complex
  cases.
- genpd_lookup_dev() is used in pm_genpd_has_performance_state() to make
  sure we have a valid genpd available for the device.
- Validation of performance state callbacks isn't done anymore in
  pm_genpd_init() as it gets called very early and the binding of
  subdomains to their parent domains happens later. This is handled in
  pm_genpd_has_performance_state() now, which is called from user
  drivers.
- User driver changes (not to be merged) are included for the first time
  here, to demonstrate how changes would look finally.

V6->V7:
- Almost a rewrite, only two patches against 9 in earlier version.
- No bindings updated now and domain's performance state aren't passed
  via DT for now (until we know how users are going to use it).
- We also skipped the QoS framework completely and new APIs are provided
  directly by genpd.

V5->V6:
- Use freq/voltage in OPP table as it is for power domain and don't
  create "domain-performance-level" property
- Create new "power-domain-opp" property for the devices.
- Take care of domain providers that provide multiple domains and extend
  "operating-points-v2" property to contain a list of phandles
- Update code according to those bindings.

V4->V5:
- Only 3 patches were resent and 2 of them are Acked from Ulf.

V3->V4:
- Use OPP table for genpd devices as well.
- Add struct device to genpd, in order to reuse OPP infrastructure.
- Based over: https://marc.info/?l=linux-kernel&m=148972988002317&w=2
- Fixed examples in DT document to have voltage in target,min,max order.

V2->V3:
- Based over latest pm/linux-next
- Bindings and code are merged together
- Lots of updates in bindings
  - the performance-states node is present within the power-domain now,
instead of its phandle.
  - performance-level property is replaced by "reg".
  - domain-performance-state property of the consumers contain an
integer value now instead of phandle.
- Lots of updates to the code as well
  - Patch "PM / QOS: Add default case to the switch" is merged with
other patches and the code is changed a bit as well.
  - Don't pass 'type' to dev_pm_qos_add_notifier(), rather handle all
notifiers with a single list. A new patch is added for that.
  - The OPP framework patch can be applied now and has proper SoB from
me.
  - Dropped "PM / domain: Save/restore performance state at runtime
suspend/resume".
  - Drop all WARN().
  - Tested-by Rajendra nayak.

V1->V2:
- Based over latest pm/linux-next
- It is mostly a resend of what is sent earlier as this series hasn't
  got any reviews so far and Rafael suggested that its better I resend
  it.
- Only the 4/6 patch got an update, which was shared earlier as reply to
  V1 as well. It has got several fixes for taking care of power domain
  hierarchy, etc.

--
viresh

[1] https://marc.info/?l=linux-kernel&m=149499607030364&w=2
[2] https://marc.info/?l=linux-kernel&m=149795317123259&w=2

Rajendra Nayak (4):
  soc: qcom: rpmpd: Add a powerdomain driver to model cx/mx powerdomains
  soc: qcom: rpmpd: Add suppor

[PATCH V8 1/6] PM / Domains: Add support to select performance-state of domains

[Viresh Kumar]

Some platforms have the capability to configure the performance state of
their Power Domains. The performance levels are identified by positive
integer values, a lower value represents lower performance state.

This patch adds a new genpd API: pm_genpd_update_performance_state().
The caller passes the affected device and the frequency representing its
next DVFS state.

The power domains get two new callbacks:

- get_performance_state(): This is called by the genpd core to retrieve
  the performance state (integer value) corresponding to a target
  frequency for the device. This state is used by the genpd core to find
  the highest requested state by all the devices powered by a domain.

- set_performance_state(): The highest state retrieved from above
  interface is then passed to this callback to finally program the
  performance state of the power domain.

The power domains can avoid supplying these callbacks, if they don't
support setting performance-states.

A power domain may have only get_performance_state() callback, if it
doesn't have the capability of changing the performance state itself but
someone in its parent hierarchy has.

A power domain may have only set_performance_state(), if it doesn't have
any direct devices below it but subdomains. And so the
get_performance_state() will never get called from the core.

The more common case would be to have both the callbacks set.

Another API, pm_genpd_has_performance_state(), is also added to let
other parts of the kernel check if the power domain of a device supports
performance-states or not. This could have been done from
pm_genpd_update_performance_state() as well, but that routine gets
called every time we do DVFS for the device and it wouldn't be optimal
in that case.

Note that, the performance level as returned by
->get_performance_state() for the parent domain of a device is used for
all domains in parent hierarchy.

Tested-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
---
 drivers/base/power/domain.c | 223 
 include/linux/pm_domain.h   |  22 +
 2 files changed, 245 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 71c95ad808d5..d506be9ff1f7 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -466,6 +466,229 @@ static int genpd_dev_pm_qos_notifier(struct 
notifier_block *nb,
return NOTIFY_DONE;
 }
 
+/*
+ * Returns true if anyone in genpd's parent hierarchy has
+ * set_performance_state() set.
+ */
+static bool genpd_has_set_performance_state(struct generic_pm_domain *genpd)
+{
+   struct gpd_link *link;
+
+   if (genpd->set_performance_state)
+   return true;
+
+   list_for_each_entry(link, &genpd->slave_links, slave_node) {
+   if (genpd_has_set_performance_state(link->master))
+   return true;
+   }
+
+   return false;
+}
+
+/**
+ * pm_genpd_has_performance_state - Checks if power domain does performance
+ * state management.
+ *
+ * @dev: Device whose power domain is getting inquired.
+ *
+ * This must be called by the user drivers, before they start calling
+ * pm_genpd_update_performance_state(), to guarantee that all dependencies are
+ * met and the device's genpd supports performance states.
+ *
+ * It is assumed that the user driver guarantees that the genpd wouldn't be
+ * detached while this routine is getting called.
+ *
+ * Returns "true" if device's genpd supports performance states, "false"
+ * otherwise.
+ */
+bool pm_genpd_has_performance_state(struct device *dev)
+{
+   struct generic_pm_domain *genpd = genpd_lookup_dev(dev);
+
+   /* The parent domain must have set get_performance_state() */
+   if (!IS_ERR(genpd) && genpd->get_performance_state) {
+   if (genpd_has_set_performance_state(genpd))
+   return true;
+
+   /*
+* A genpd with ->get_performance_state() callback must also
+* allow setting performance state.
+*/
+   dev_err(dev, "genpd doesn't support setting performance 
state\n");
+   }
+
+   return false;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_has_performance_state);
+
+/*
+ * Re-evaluate performance state of a power domain. Finds the highest requested
+ * performance state by the devices and subdomains within the power domain and
+ * then tries to change its performance state. If the power domain doesn't have
+ * a set_performance_state() callback, then we move the request to its parent
+ * power domain.
+ *
+ * Locking: Access (or update) to device's "pd_data->performance_state" field
+ * happens only with parent domain's lock held. Subdomains have their
+ * "genpd->performance_state" protected with their own lock (and they are the
+ * only user of this field) and their per-parent-domain
+ * "link->performance_state" field is protected with individual parent power
+ * domain's lock and is only accessed/updat

[PATCH V8 2/6] PM / OPP: Support updating performance state of device's power domains

[Viresh Kumar]

The genpd framework now provides an API to request device's power
domain to update its performance state based on a particular target
frequency for the device.

Use that interface from the OPP core for devices whose power domains
support performance states.

Note that the current implementation is restricted to the case where the
device doesn't have separate regulators for itself. We shouldn't
over engineer the code before we have real use case for them. We can
always come back and add more code to support such cases later on.

Tested-by: Rajendra Nayak 
Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/core.c | 48 ++-
 drivers/base/power/opp/opp.h  |  2 ++
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index a8cc14fd8ae4..ef623afcc5fd 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "opp.h"
@@ -535,6 +536,42 @@ _generic_set_opp_clk_only(struct device *dev, struct clk 
*clk,
return ret;
 }
 
+static inline int
+_generic_set_opp_domain(struct device *dev, struct clk *clk,
+   unsigned long old_freq, unsigned long freq)
+{
+   int ret;
+
+   /* Scaling up? Scale domain performance state before frequency */
+   if (freq > old_freq) {
+   ret = pm_genpd_update_performance_state(dev, freq);
+   if (ret)
+   return ret;
+   }
+
+   ret = _generic_set_opp_clk_only(dev, clk, old_freq, freq);
+   if (ret)
+   goto restore_domain_state;
+
+   /* Scaling down? Scale domain performance state after frequency */
+   if (freq < old_freq) {
+   ret = pm_genpd_update_performance_state(dev, freq);
+   if (ret)
+   goto restore_freq;
+   }
+
+   return 0;
+
+restore_freq:
+   if (_generic_set_opp_clk_only(dev, clk, freq, old_freq))
+   dev_err(dev, "%s: failed to restore old-freq (%lu Hz)\n",
+   __func__, old_freq);
+restore_domain_state:
+   pm_genpd_update_performance_state(dev, old_freq);
+
+   return ret;
+}
+
 static int _generic_set_opp_regulator(const struct opp_table *opp_table,
  struct device *dev,
  unsigned long old_freq,
@@ -653,7 +690,14 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
 
/* Only frequency scaling */
if (!opp_table->regulators) {
-   ret = _generic_set_opp_clk_only(dev, clk, old_freq, freq);
+   /*
+* We don't support devices with both regulator and
+* domain performance-state for now.
+*/
+   if (opp_table->genpd_performance_state)
+   ret = _generic_set_opp_domain(dev, clk, old_freq, freq);
+   else
+   ret = _generic_set_opp_clk_only(dev, clk, old_freq, 
freq);
} else if (!opp_table->set_opp) {
ret = _generic_set_opp_regulator(opp_table, dev, old_freq, freq,
 IS_ERR(old_opp) ? NULL : 
old_opp->supplies,
@@ -755,6 +799,8 @@ static struct opp_table *_allocate_opp_table(struct device 
*dev)
ret);
}
 
+   opp_table->genpd_performance_state = 
pm_genpd_has_performance_state(dev);
+
BLOCKING_INIT_NOTIFIER_HEAD(&opp_table->head);
INIT_LIST_HEAD(&opp_table->opp_list);
mutex_init(&opp_table->lock);
diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index 166eef990599..1efa253e1934 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -135,6 +135,7 @@ enum opp_table_access {
  * @clk: Device's clock handle
  * @regulators: Supply regulators
  * @regulator_count: Number of power supply regulators
+ * @genpd_performance_state: Device's power domain support performance state.
  * @set_opp: Platform specific set_opp callback
  * @set_opp_data: Data to be passed to set_opp callback
  * @dentry:debugfs dentry pointer of the real device directory (not links).
@@ -170,6 +171,7 @@ struct opp_table {
struct clk *clk;
struct regulator **regulators;
unsigned int regulator_count;
+   bool genpd_performance_state;
 
int (*set_opp)(struct dev_pm_set_opp_data *data);
struct dev_pm_set_opp_data *set_opp_data;
-- 
2.13.0.71.gd7076ec9c9cb

Re: linux-next: build warning after merge of the file-locks tree

[Stephen Rothwell]

Hi Jeff,

On Wed, 21 Jun 2017 10:30:52 +1000 Stephen Rothwell  
wrote:
>
> After merging the file-locks tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> fs/jfs/jfs_metapage.c: In function 'force_metapage':
> fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 
> 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
>   write_one_page(page);
>   ^
> fs/jfs/jfs_metapage.c: In function 'release_metapage':
> fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 
> 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
> write_one_page(page);
> ^
> 
> Introduced by commit
> 
>   ee6b2b8e0a8f ("mm: drop "wait" parameter from write_one_page()")

This is fixed up by commit

  f0423ddc1cf6 ("JFS: do not ignore return code from write_one_page()")

in the akpm-current tree.

-- 
Cheers,
Stephen Rothwell

[NOT-FOR-MERGE V8 6/6] remoteproc: qcom: q6v5: Vote for proxy powerdomain performance state

[Viresh Kumar]

From: Rajendra Nayak 

THIS IS TEST CODE, SHOULDN'T BE MERGED.

This patch just demonstrates the usage of pm_genpd_update_performance_state()
api in cases where users need to set performance state of a powerdomain without
having to do it via the OPP framework.

q6v5 remoteproc driver needs to proxy vote for performance states of multiple
powerdomains (but we currently only demonstate how it can be done for
one powerdomain, as there is no way to associate multiple powerdomains
to a device at this time) while it loads the firmware, and then releases
the vote, once the firmware is up and can vote for itself.

This is not a functional patch since rpmpd driver only supports msm8996
and there is no msm8996 support in the q6v5 remoteproc driver at this
point in mainline.

This patch is not tested as well.

NOT-signed-off-by: Rajendra Nayak 
NOT-signed-off-by: Viresh Kumar 
---
 drivers/remoteproc/qcom_q6v5_pil.c | 20 +---
 drivers/soc/qcom/rpmpd.c   |  5 +
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index 8fd697a3cf8f..47c9dad98ee8 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -152,6 +153,8 @@ struct q6v5 {
void *mpss_region;
size_t mpss_size;
 
+   bool has_perf_state;
+
struct qcom_rproc_subdev smd_subdev;
 };
 
@@ -603,11 +606,12 @@ static int q6v5_start(struct rproc *rproc)
struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
int ret;
 
-   ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
-   qproc->proxy_reg_count);
-   if (ret) {
-   dev_err(qproc->dev, "failed to enable proxy supplies\n");
-   return ret;
+   if (qproc->has_perf_state) {
+   ret = pm_genpd_update_performance_state(qproc->dev, INT_MAX);
+   if (ret) {
+   dev_err(qproc->dev, "Failed to set performance 
state.\n");
+   return ret;
+   }
}
 
ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
@@ -671,8 +675,8 @@ static int q6v5_start(struct rproc *rproc)
 
q6v5_clk_disable(qproc->dev, qproc->proxy_clks,
 qproc->proxy_clk_count);
-   q6v5_regulator_disable(qproc, qproc->proxy_regs,
-  qproc->proxy_reg_count);
+   if (qproc->has_perf_state)
+   pm_genpd_update_performance_state(qproc->dev, 0);
 
return 0;
 
@@ -1043,6 +1047,8 @@ static int q6v5_probe(struct platform_device *pdev)
if (ret)
goto free_rproc;
 
+   qproc->has_perf_state = pm_genpd_has_performance_state(&qproc->dev);
+
return 0;
 
 free_rproc:
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 7ef81429c5c5..b1af1442ebe9 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -145,6 +145,7 @@ enum msm8996_devices {
UFS,
PCIE,
USB3,
+   Q6V5_PIL,
 };
 
 static struct rpmpd_freq_map msm8996_rpmpd_freq_map[] = {
@@ -171,6 +172,10 @@ static struct rpmpd_freq_map msm8996_rpmpd_freq_map[] = {
.freq[LOW] = 12000,
.freq[NOMINAL] = 15000,
},
+   [Q6V5_PIL] = {
+   .pd = &msm8996_vddcx,
+   .freq[HIGH] = INT_MAX,
+   },
 };
 
 static const struct of_device_id rpmpd_performance_table[] = {
-- 
2.13.0.71.gd7076ec9c9cb

[PATCH] thermal/intel_powerclamp: add const to thermal_cooling_device_ops structure

[Bhumika Goyal]

Declare thermal_cooling_device_ops structure as const as it is only passed
as an argument to the function thermal_cooling_device_register and this
argument is of type const. So, declare the structure as const.

Signed-off-by: Bhumika Goyal 
---
 drivers/thermal/intel_powerclamp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/intel_powerclamp.c 
b/drivers/thermal/intel_powerclamp.c
index d718cd1..e4c68b7 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -659,7 +659,7 @@ static int powerclamp_set_cur_state(struct 
thermal_cooling_device *cdev,
 }
 
 /* bind to generic thermal layer as cooling device*/
-static struct thermal_cooling_device_ops powerclamp_cooling_ops = {
+static const struct thermal_cooling_device_ops powerclamp_cooling_ops = {
.get_max_state = powerclamp_get_max_state,
.get_cur_state = powerclamp_get_cur_state,
.set_cur_state = powerclamp_set_cur_state,
-- 
2.7.4

[NOT-FOR-MERGE V8 5/6] mmc: sdhci-msm: Adapt the driver to use OPPs to set clocks/performance state

[Viresh Kumar]

From: Rajendra Nayak 

THIS IS TEST CODE, SHOULDN'T BE MERGED.

SDHCI driver needs to set a performance state along with scaling its
clocks. Modify the driver to use the newly introducded powerdomain
performance state based OPPs to scale clocks as well as set an
appropriate powerdomain performance state.

The patch also adds OPPs for sdhci device on msm8996.

The changes have to be validated by populating similar OPP tables
on all other devices which use the sdhci driver. This is for now
validated only on msm8996 and with missing OPP tables for other
devices is known to break those platforms.

NOT-signed-off-by: Rajendra Nayak 
NOT-signed-off-by: Viresh Kumar 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 ++
 drivers/clk/qcom/gcc-msm8996.c|  8 +++
 drivers/mmc/host/sdhci-msm.c  | 39 ++-
 3 files changed, 67 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 1fec06285f38..2cabdba93e0e 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -431,8 +431,42 @@
 <&gcc GCC_SDCC2_APPS_CLK>,
 <&xo_board>;
 bus-width = <4>;
+   power-domains = <&rpmpd 0>;
+   operating-points-v2 = <&sdhc_opp_table>;
 };
 
+   sdhc_opp_table: opp_table {
+   compatible = "operating-points-v2";
+
+   opp@40 {
+   opp-hz = /bits/ 64 <40>;
+   };
+
+   opp@2000 {
+   opp-hz = /bits/ 64 <2000>;
+   };
+
+   opp@2500 {
+   opp-hz = /bits/ 64 <2500>;
+   };
+
+   opp@5000 {
+   opp-hz = /bits/ 64 <5000>;
+   };
+
+   opp@9600 {
+   opp-hz = /bits/ 64 <9600>;
+   };
+
+   opp@19200 {
+   opp-hz = /bits/ 64 <19200>;
+   };
+
+   opp@38400 {
+   opp-hz = /bits/ 64 <38400>;
+   };
+   };
+
msmgpio: pinctrl@101 {
compatible = "qcom,msm8996-pinctrl";
reg = <0x0101 0x30>;
diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index 8abc200d4fd3..9eb23063e78f 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -460,7 +460,7 @@ static struct clk_rcg2 sdcc1_apps_clk_src = {
.name = "sdcc1_apps_clk_src",
.parent_names = gcc_xo_gpll0_gpll4_gpll0_early_div,
.num_parents = 4,
-   .ops = &clk_rcg2_floor_ops,
+   .ops = &clk_rcg2_ops,
},
 };
 
@@ -505,7 +505,7 @@ static struct clk_rcg2 sdcc2_apps_clk_src = {
.name = "sdcc2_apps_clk_src",
.parent_names = gcc_xo_gpll0_gpll4,
.num_parents = 3,
-   .ops = &clk_rcg2_floor_ops,
+   .ops = &clk_rcg2_ops,
},
 };
 
@@ -519,7 +519,7 @@ static struct clk_rcg2 sdcc3_apps_clk_src = {
.name = "sdcc3_apps_clk_src",
.parent_names = gcc_xo_gpll0_gpll4,
.num_parents = 3,
-   .ops = &clk_rcg2_floor_ops,
+   .ops = &clk_rcg2_ops,
},
 };
 
@@ -543,7 +543,7 @@ static struct clk_rcg2 sdcc4_apps_clk_src = {
.name = "sdcc4_apps_clk_src",
.parent_names = gcc_xo_gpll0,
.num_parents = 2,
-   .ops = &clk_rcg2_floor_ops,
+   .ops = &clk_rcg2_ops,
},
 };
 
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 9d601dc0d646..2dfa4d58e113 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sdhci-pltfm.h"
 
@@ -131,6 +132,7 @@ struct sdhci_msm_host {
struct clk *pclk;   /* SDHC peripheral bus clock */
struct clk *bus_clk;/* SDHC bus voter clock */
struct clk *xo_clk; /* TCXO clk needed for FLL feature of cm_dll*/
+   struct opp_table *opp_table;
unsigned long clk_rate;
struct mmc_host *mmc;
bool use_14lpp_dll_reset;
@@ -140,7 +142,7 @@ struct sdhci_msm_host {
bool use_cdclp533;
 };
 
-static unsigned int msm_get_clock_rate_for_bus_mode(struct sdhci_host *host,
+static long unsigned int msm_get_clock_rate_for_bus_mode(struct sdhci_host 
*host,
unsigned int clock)
 

[NOT-FOR-MERGE V8 3/6] soc: qcom: rpmpd: Add a powerdomain driver to model cx/mx powerdomains

[Viresh Kumar]

From: Rajendra Nayak 

THIS IS TEST CODE, SHOULDN'T BE MERGED.

The cx/mx powerdomains just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.

Add data for all powerdomains on msm8996.

NOT-signed-off-by: Rajendra Nayak 
NOT-signed-off-by: Viresh Kumar 
---
 .../devicetree/bindings/power/qcom,rpmpd.txt   |  10 +
 arch/arm64/boot/dts/qcom/msm8996.dtsi  |   5 +
 drivers/soc/qcom/Kconfig   |   9 +
 drivers/soc/qcom/Makefile  |   1 +
 drivers/soc/qcom/rpmpd.c   | 307 +
 5 files changed, 332 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt
 create mode 100644 drivers/soc/qcom/rpmpd.c

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt 
b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
new file mode 100644
index ..8b48ce57a563
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -0,0 +1,10 @@
+Qualcomm RPM Powerdomains
+
+* For RPM powerdomains, we communicate a performance state to RPM
+which then translates it into a corresponding voltage on a rail
+
+Required Properties:
+ - compatible: Should be one of the following
+   * qcom,rpmpd-msm8996: RPM Powerdomain for the msm8996 family of SoC
+ - power-domain-cells: number of cells in power domain specifier
+   must be 1.
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 9bc9c857a000..1fec06285f38 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -412,6 +412,11 @@
status = "disabled";
};
 
+   rpmpd: qcom,rpmpd {
+   compatible = "qcom,rpmpd-msm8996", "qcom,rpmpd";
+   #power-domain-cells = <1>;
+   };
+
sdhc2: sdhci@74a4900 {
 status = "disabled";
 compatible = "qcom,sdhci-msm-v4";
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 9fca977ef18d..3892148be3c3 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -24,6 +24,15 @@ config QCOM_PM
  modes. It interface with various system drivers to put the cores in
  low power modes.
 
+config QCOM_RPMPD
+   tristate "Qualcomm RPM Powerdomain driver"
+   depends on MFD_QCOM_RPM && QCOM_SMD_RPM
+   help
+ QCOM RPM powerdomain driver to support powerdomain with
+ performance states. The driver communicates a performance state
+ value to RPM which then translates it into corresponding voltage
+ for the voltage rail.
+
 config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 414f0de274fa..f7c3edfa6de8 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
 obj-$(CONFIG_QCOM_SMP2P)   += smp2p.o
 obj-$(CONFIG_QCOM_SMSM)+= smsm.o
 obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
+obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
new file mode 100644
index ..d34d9c363815
--- /dev/null
+++ b/drivers/soc/qcom/rpmpd.c
@@ -0,0 +1,307 @@
+/*
+ * Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
+
+/* Resource types */
+#define RPMPD_SMPA 0x61706d73
+#define RPMPD_LDOA 0x616f646c
+
+/* Operation Keys */
+#define KEY_CORNER 0x6e726f63 /* corn */
+#define KEY_ENABLE 0x6e657773 /* swen */
+#define KEY_FLOOR_CORNER   0x636676   /* vfc */
+
+#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
+   static struct rpmpd _platform##_##_active;  \
+   static struct rpmpd _platform##_##_name = { \
+   .pd = { .name = #_name, },  \
+   .peer = &_platform##_##_active, \
+   .res_type = 

RE: [PATCH 9/9] clk: imx: add imx7ulp clk driver

[A.s. Dong]

> -Original Message-
> From: Stephen Boyd [mailto:sb...@codeaurora.org]
> Sent: Wednesday, June 21, 2017 4:42 AM
> To: Dong Aisheng
> Cc: A.s. Dong; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; mturque...@baylibre.com;
> shawn...@kernel.org; Anson Huang; Jacky Bai
> Subject: Re: [PATCH 9/9] clk: imx: add imx7ulp clk driver
> 
> On 06/20, Dong Aisheng wrote:
> > On Mon, Jun 19, 2017 at 07:01:19PM -0700, Stephen Boyd wrote:
> > >
> > > Any reason why it can't be a platform driver? If not, please add
> > > some comment explaining why.
> > >
> >
> > Timer is using it at early stage. GIC seems not although standard
> > binding claim possible clock requirement.
> > Others still not sure.
> >
> > What your suggestion?
> > Convert timer to platform driver and make clock as platform driver as
> well?
> >
> 
> The timer can't be a platform driver because it would be too late. The
> clock driver could register whatever clks are required for the timer/GIC
> in a CLK_OF_DECLARE_DRIVER hook, and then leave the rest to a platform
> driver. This way we get some of the device driver framework in this code.
> 

Okay, I could try it. Thanks.

One thing is that TPM clock has a lot parents and parents having parents,
as well as PIT timer. So I may need enable more than half clocks in
CLK_OF_DECLARE_DRIVER hook.

BTW, What's benefit to convert into two parts of probe?
I'm not quite if I already get it all, can you help clarify it?

Regards
Dong Aisheng

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

[Thomas Gleixner]

On Fri, 16 Jun 2017, Tom Lendacky wrote:
> diff --git a/arch/x86/include/asm/mem_encrypt.h 
> b/arch/x86/include/asm/mem_encrypt.h
> index a105796..988b336 100644
> --- a/arch/x86/include/asm/mem_encrypt.h
> +++ b/arch/x86/include/asm/mem_encrypt.h
> @@ -15,16 +15,24 @@
>  
>  #ifndef __ASSEMBLY__
>  
> +#include 
> +
>  #ifdef CONFIG_AMD_MEM_ENCRYPT
>  
>  extern unsigned long sme_me_mask;
>  
> +void __init sme_enable(void);
> +
>  #else/* !CONFIG_AMD_MEM_ENCRYPT */
>  
>  #define sme_me_mask  0UL
>  
> +static inline void __init sme_enable(void) { }
> +
>  #endif   /* CONFIG_AMD_MEM_ENCRYPT */
>  
> +unsigned long sme_get_me_mask(void);

Why is this an unconditional function? Isn't the mask simply 0 when the MEM
ENCRYPT support is disabled?

> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index 6225550..ef12729 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -78,7 +78,29 @@ startup_64:
>   call__startup_64
>   popq%rsi
>  
> - movq$(early_top_pgt - __START_KERNEL_map), %rax
> + /*
> +  * Encrypt the kernel if SME is active.
> +  * The real_mode_data address is in %rsi and that register can be
> +  * clobbered by the called function so be sure to save it.
> +  */
> + push%rsi
> + callsme_encrypt_kernel
> + pop %rsi

That does not make any sense. Neither the call to sme_encrypt_kernel() nor
the following call to sme_get_me_mask().

__startup_64() is already C code, so why can't you simply call that from
__startup_64() in C and return the mask from there?

> @@ -98,7 +120,20 @@ ENTRY(secondary_startup_64)
>   /* Sanitize CPU configuration */
>   call verify_cpu
>  
> - movq$(init_top_pgt - __START_KERNEL_map), %rax
> + /*
> +  * Get the SME encryption mask.
> +  *  The encryption mask will be returned in %rax so we do an ADD
> +  *  below to be sure that the encryption mask is part of the
> +  *  value that will stored in %cr3.
> +  *
> +  * The real_mode_data address is in %rsi and that register can be
> +  * clobbered by the called function so be sure to save it.
> +  */
> + push%rsi
> + callsme_get_me_mask
> + pop %rsi

Do we really need a call here? The mask is established at this point, so
it's either 0 when the encryption stuff is not compiled in or it can be
retrieved from a variable which is accessible at this point.

> +
> + addq$(init_top_pgt - __START_KERNEL_map), %rax
>  1:
>  
>   /* Enable PAE mode, PGE and LA57 */

Thanks,

tglx

Re: [RFC v2 05/12] powerpc: Implementation for sys_mprotect_pkey() system call.

[Aneesh Kumar K.V]

Ram Pai  writes:



>
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +
>  /*
>   * This file is included by linux/mman.h, so we can't use cacl_vm_prot_bits()
>   * here.  How important is the optimization?
>   */
> -static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot,
> - unsigned long pkey)
> -{
> - return (prot & PROT_SAO) ? VM_SAO : 0;
> -}
> -#define arch_calc_vm_prot_bits(prot, pkey) arch_calc_vm_prot_bits(prot, pkey)
> +#define arch_calc_vm_prot_bits(prot, key) ( \
> + ((prot) & PROT_SAO ? VM_SAO : 0) |  \
> + pkey_to_vmflag_bits(key))
> +#define arch_vm_get_page_prot(vm_flags) __pgprot(   \
> + ((vm_flags) & VM_SAO ? _PAGE_SAO : 0) | \
> + vmflag_to_page_pkey_bits(vm_flags))

Can we avoid converting static inline back to macors ? They loose type checking.
> +
> +#else /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +
> +#define arch_calc_vm_prot_bits(prot, key) (  \
> + ((prot) & PROT_SAO ? VM_SAO : 0))
> +#define arch_vm_get_page_prot(vm_flags) __pgprot(\
> + ((vm_flags) & VM_SAO ? _PAGE_SAO : 0))
> +
> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
>
> -static inline pgprot_t arch_vm_get_page_prot(unsigned long vm_flags)
> -{
> - return (vm_flags & VM_SAO) ? __pgprot(_PAGE_SAO) : __pgprot(0);
> -}
> -#define arch_vm_get_page_prot(vm_flags) arch_vm_get_page_prot(vm_flags)
>
>  static inline bool arch_validate_prot(unsigned long prot)
>  {

-aneesh

Re: [PATCH v4 3/3] x86/build: Specify stack alignment for clang

[Ingo Molnar]

* Matthias Kaehlcke  wrote:

> El Tue, Jun 20, 2017 at 11:20:54AM +0200 Ingo Molnar ha dit:
> 
> > 
> > * Matthias Kaehlcke  wrote:
> > 
> > > Ingo didn't like the duplication and suggested the use of a variable, 
> > > which 
> > > kinda implies a check for the compiler name.
> > 
> > I don't think it implies that: why cannot cc_stack_align_opt probe for the 
> > compiler option and use whichever is available, without hard-coding the 
> > compiler 
> > name?
> 
> We could do this:
> 
> ifneq ($(call __cc-option, $(CC), -mno-sse, -mpreferred-stack-boundary=3,),)
> cc_stack_align_opt := -mpreferred-stack-boundary
> endif
> ifneq ($(call cc-option, -mstack-alignment=3,),)
> cc_stack_align_opt := -mstack-alignment
> endif

The principle Looks good to me - but I'd make the second probing an 'else' 
branch, 
i.e. probe for a suitable compiler option until we find one. That would also 
not 
burden the GCC build with probing for different compiler options.

Please also add a comment in the code that explains that the first option is a 
GCC 
option and the second one is a Clang-ism.

> Since this solution also won't win a beauty price please let me know
> if it is acceptable before respinning the patch or if you have other
> suggestions.

This one already looks a lot cleaner to me than any of the previous ones.

Thanks,

Ingo

Re: [PATCH 3.10 268/268] mm: larger stack guard gap, between vmas

[Willy Tarreau]

On Wed, Jun 21, 2017 at 12:05:07AM -0700, Hugh Dickins wrote:
> On Mon, 19 Jun 2017, Willy Tarreau wrote:
> 
> > From: Hugh Dickins 
> > 
> > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.
> 
> Some of these suggested adjustments below are just what comparing mine
> and yours showed up, and I'm being anal in passing them on e.g. I do
> like your blank line in mm.h, but Michal chose to leave it out, and
> I think that the closer we keep these sources to each other,
> the less trouble we shall have patching on top in future.

I totally agree, that's what I generally focus on as well.

> Which is particularly true in expand_upwards() and expand_downwards()
> (and you're thinking of backporting Helge's TASK_SIZE enhancement
> on top of that, though I don't think it's strictly necessary for a
> stable tree).

I thought it was a fix for a corner case on PARISC, so just in case
I'd rather stick as close as possible to mainline : at least we want
to ensure the same bugs are met everywhere so that we can benefit
from developers' help when issues are met.

> Your patch is not wrong there: though odd to be trying
> anon_vma_prepare() twice in expand_downwards(),

Ah crap, the second one is a leftover from initial code that I missed.

> and tiresome to have to unlock at each error exit.

Oh I'm seeing that you could move it later, I wasn't sure about this
one. Thanks. I think I did the same stuff in the 3.16 backport.

> But I'd already decided in one of our
> internal trees just to factor in some of Konstantin's change, that
> made the ordering much more sensible there, and the two more like
> each other; so recommend that 3.10 do the same, keeping it closer
> to the final 4.12 code.  But you may have different priorities and
> disagree with that: just suggesting.

No, I perfectly agree with you. As I mentionned, my patches were
proposals based on what I understood from the code, I'm really glad
to receive your help and fixes here!

> And there is the possibility that we shall want another patch or
> two on top there.  I've left a question as to whether we should be
> comparing anon_vmas.  And there's a potential (but I think ignorable)
> locking issue, in the case of an architecture that supports both
> VM_GROWSUP and VM_GROWSDOWN: if they expand towards each other at the
> same instant, they could gobble up the gap between them (they almost
> certainly have different anon_vmas, so the anon_vma locking does not
> protect against that).  When it gets to updating the vma tree, it is
> careful to use page_table_lock to maintain the consistency of the
> tree in such a case, but maybe we should do that earlier.

OK.

> Then there's the FOLL_MLOCK thing, and the WARN_ON (phew, remembered
> in time that you don't have VM_WARN_ON) - but keep in mind that I
> have not even built this tree, let alone tested it.

I'll take care of building it, don't worry.

> Sorry if I'm being annoying, Willy: you must be heartily sick of
> these patches by now!  Or, being a longtime longterm maintainer,
> perhaps it's all joy for you ;-?

No, rest assured it's never a full joy :-)  But it's much better
when I get help from the people who know how this stuff works than
when I have to invent the backport by myself!

Thanks a lot, I'll include your patch and will test it again. And
yes, I intend to merge Helge's fix once it lands into mainline (maybe
it is right now, I didn't check) and possibly other ones you might be
working on depending on various feedback.

Willy

Re: [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

[Thomas Gleixner]

On Fri, 16 Jun 2017, Tom Lendacky wrote:
>  
> +#ifndef pgprot_encrypted
> +#define pgprot_encrypted(prot)   (prot)
> +#endif
> +
> +#ifndef pgprot_decrypted

That looks wrong. It's not decrypted it's rather unencrypted, right?

Thanks,

tglx

Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Gerd Hoffmann]

  Hi,

> We don't support cursor for console vnc. Ideally console vnc should
> be
> used by admin for configuration or during maintenance, which refresh
> primary surface at low refresh rate, 10 fps.

But you surely want a mouse pointer for the admin?
You render it directly to the primary surface then I guess?

> Right we need to know this at device initialization time for both
> cases
> to initialize VGACommonState structure for that device

Why do you need a VGACommonState?

> and also need
> NONE to decide whether to init console vnc or not. We have a
> mechanism
> to disable console vnc path and we recommend to disable it for better
> performance.

Hmm, maybe we should have a ioctl to configure the refresh rate, or a
ioctl to allow qemu ask for a refresh when needed?

qemu can throttle the display update rate, which for example happens in
case no vnc client is connected.  qemu updates the display only once
every few seconds then.

cheers,
  Gerd

Re: [PATCH] staging/lustre: echo_client.c - fix sparse warning: cast removes address space of expression

[Tordek]

Hi, List

I don't want to be a bother but should I be doing something different
when submitting patches? I know it's minor but it's a simple change
and it's received no response after two weeks; not even a rejection.

Cheers
--
Tordek

On 8 June 2017 at 02:35, Guillermo O. Freschi  wrote:
> The function only cares about the value of the pointer, not the contents
> of the pointed-to data. Adding a `__force` annotation to the cast
> removes this warning.
>
> Signed-off-by: Guillermo O. Freschi 
> ---
>  drivers/staging/lustre/lustre/obdecho/echo_client.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/obdecho/echo_client.c 
> b/drivers/staging/lustre/lustre/obdecho/echo_client.c
> index d4768311cf92..1757714c56a0 100644
> --- a/drivers/staging/lustre/lustre/obdecho/echo_client.c
> +++ b/drivers/staging/lustre/lustre/obdecho/echo_client.c
> @@ -1428,7 +1428,7 @@ static int echo_client_brw_ioctl(const struct lu_env 
> *env, int rw,
> oa->o_valid &= ~OBD_MD_FLHANDLE;
>
> /* OFD/obdfilter works only via prep/commit */
> -   test_mode = (long)data->ioc_pbuf1;
> +   test_mode = (__force long)data->ioc_pbuf1;
> if (test_mode == 1)
> async = 0;
>
> --
> 2.11.0
>

Re: [PATCH 3.18 32/32] mm: larger stack guard gap, between vmas

[Willy Tarreau]

On Tue, Jun 20, 2017 at 11:10:56PM -0700, Hugh Dickins wrote:
> On Wed, 21 Jun 2017, Willy Tarreau wrote:
> > On Tue, Jun 20, 2017 at 10:49:16PM -0700, Hugh Dickins wrote:
> > > On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote:
> > > 
> > > > 3.18-stable review patch.  If anyone has any objections, please let me 
> > > > know.
> > > > 
> > > > --
> > > > 
> > > > From: Hugh Dickins 
> > > > 
> > > > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.
> > > 
> > > Here's a few adjustments to the 3.18 patch: no doubt you'll have
> > > already sorted out any build errors (and I have to confess that
> > > I haven't even tried to build this); and the VM_WARN_ON line (as
> > > in 4.4) only fixes a highly unlikely error; but those FOLL_MLOCK
> > > lines in mm/gup.c were mistaken, and do need to be deleted.
> > 
> > Are you sure ? The test on the FOLL_MLOCK flag remains present in
> > 4.11 and mainline :
> > 
> > /* mlock all present pages, but do not fault in new pages */
> > if ((*flags & (FOLL_POPULATE | FOLL_MLOCK)) == FOLL_MLOCK)
> > return -ENOENT;
> > 
> > And this test was present although different in 3.18 as well :
> > 
> > /* For mlock, just skip the stack guard page. */
> > if ((*flags & FOLL_MLOCK) &&
> > (stack_guard_page_start(vma, address) ||
> >  stack_guard_page_end(vma, address + PAGE_SIZE)))
> > 
> > So by removing it we're totally removing any test on FOLL_MLOCK. That
> > might be the correct fix, but I'm just a bit surprized since the mainline
> > patch doesn't remove it, and only removes the test on FOLL_POPULATE.
> 
> I think I'm sure :)  Please take another look, the intention of those
> two FOLL_MLOCK tests is completely different.  One of them is about
> the mlock2() syscall (I think), which wants not to fault in every
> page at syscall time; and the other is about stack guard pages
> bogusly included in the vma extents, which must not be faulted in.
> The stack guard pages are no longer included in the vma extents,
> so we can just delete those lines (note the "&&" in the condition);
> but we don't want mlock() to stop faulting its pages in.
> 
> Makes sense now, or am I tired and confused?

Your explanation sounds pretty fine to me, so I agree with you :-)

Thanks!
Willy

Re: [PATCH 2/2] xen/input: add multi-touch support

[Dmitry Torokhov]

On Thu, Jun 08, 2017 at 09:45:18AM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
> 
> On 06/07/2017 07:56 PM, Dmitry Torokhov wrote:
> >On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
> >>Hi, Dmitry!
> >>
> >>On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
> >>>On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
> 
> On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
> >On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
> >>Hi, Dmitry!
> >>
> >>On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
> >>>Hi Oleksandr,
> >>>
> >>>On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko 
> >>>wrote:
> From: Oleksandr Andrushchenko 
> 
> Extend xen_kbdfront to provide multi-touch support
> to unprivileged domains.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> 
> ---
>   drivers/input/misc/xen-kbdfront.c | 142 
>  +-
>   1 file changed, 140 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 01c27b4c3288..e5d064aaa237 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -17,6 +17,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
> @@ -34,11 +35,14 @@
>   struct xenkbd_info {
>   struct input_dev *kbd;
>   struct input_dev *ptr;
> + struct input_dev *mtouch;
>   struct xenkbd_page *page;
>   int gref;
>   int irq;
>   struct xenbus_device *xbdev;
>   char phys[32];
> + /* current MT slot/contact ID we are injecting events in */
> + int mtouch_cur_contact_id;
>   };
>   enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>   MODULE_PARM_DESC(ptr_size,
>   "Pointing device width, height in pixels (default 800,600)");
> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT 
> };
> +module_param_array(mtouch_size, int, NULL, 0444);
> +MODULE_PARM_DESC(ptr_size,
> + "Multi-touch device width, height in pixels (default 800,600)");
> +
> >>>Why do you need separate module parameters for multi-touch device?
> >>please see below
>   static int xenkbd_remove(struct xenbus_device *);
>   static int xenkbd_connect_backend(struct xenbus_device *, struct 
>  xenkbd_info *);
>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void 
> *dev_id)
>   input_report_rel(dev, REL_WHEEL,
>    -event->pos.rel_z);
>   break;
> + case XENKBD_TYPE_MTOUCH:
> + dev = info->mtouch;
> + if (unlikely(!dev))
> + break;
> + if (unlikely(event->mtouch.contact_id !=
> + info->mtouch_cur_contact_id)) {
> >>>Why is this unlikely? Does contact ID changes once in 1000 packets or
> >>>even less?
> >>Mu assumption was that regardless of the fact that we are multi-touch
> >>device still single touches will come in more frequently
> >>But I can remove *unlikely* if my assumption is not correct
> >I think the normal expectation is that "unlikely" is supposed for
> >something that happens once in a blue moon, so I'd rather remove it.
> >
> agree, removed "unlikely"
> + info->mtouch_cur_contact_id =
> + event->mtouch.contact_id;
> + input_mt_slot(dev, 
> event->mtouch.contact_id);
> + }
> + switch (event->mtouch.event_type) {
> + case XENKBD_MT_EV_DOWN:
> + input_mt_report_slot_state(dev, 
> MT_TOOL_FINGER,
> +true);
> >Should we establish tool event? We have MT_TOOL_PEN, etc.
> I think that for multi-touch MT_TOOL_FINGER is enough
> any reason we would also want MT_TOOL_PEN here?
> >>>Why would not you? Let's say you have a drawing application running in
> >>>guest that can make use of tool types. Why would not yo

KASAN related bug in crypto/asymmetric_keys/public_key.c:96

[Peter Teoh]

I got the following dump during startup (4.11.0 stable):

[1.353688] registered taskstats version 1
[1.353974] Loading compiled-in X.509 certificates
[1.354582] [ cut here ]
[1.354904] kernel BUG at crypto/asymmetric_keys/public_key.c:96!
[1.355319] invalid opcode:  [#1] SMP KASAN
[1.355628] Modules linked in:
[1.355843] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0syz #10
[1.356266] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[1.356901] task: 88006c538000 task.stack: 88006c54
[1.357308] RIP: 0010:public_key_verify_signature+0x772/0x9b0
[1.357698] RSP: :88006c547840 EFLAGS: 00010297
[1.358053] RAX: 88006c538000 RBX: 88006a46e9c0 RCX: 0005
[1.358537] RDX:  RSI: 88006a46e9c0 RDI: 88006a46de70
[1.359013] RBP: 88006c547a18 R08: ed000d48dd93 R09: ed000d48dd93
[1.359488] R10:  R11: ed000d48dd94 R12: dc00
[1.359962] R13: 88006a46de70 R14: 82ba4440 R15: 11000d8a8f0e
[1.360442] FS:  () GS:88006d00()
knlGS:
[1.360986] CS:  0010 DS:  ES:  CR0: 80050033
[1.361376] CR2:  CR3: 0300d000 CR4: 06f0
[1.361855] DR0:  DR1:  DR2: 
[1.362333] DR3:  DR6: fffe0ff0 DR7: 0400
[1.362914] Call Trace:
[1.363092]  ? public_key_describe+0xd0/0xd0
[1.363390]  ? kasan_slab_free+0x89/0xc0
[1.363660]  ? crypto_larval_destroy+0x110/0x150
[1.363977]  ? kfree+0x96/0x1b0
[1.364195]  ? crypto_larval_destroy+0x110/0x150
[1.364513]  ? crypto_larval_wait+0x1e0/0x1e0
[1.364813]  ? crypto_larval_kill+0x16f/0x1d0
[1.365113]  ? kasan_unpoison_shadow+0x35/0x50
[1.365418]  ? kasan_kmalloc+0xad/0xe0
[1.365678]  x509_check_for_self_signed+0x324/0x520
[1.366012]  x509_cert_parse+0x4b6/0x670
[1.366295]  x509_key_preparse+0x69/0x860
[1.366573]  ? __printk_safe_exit+0xe/0x20
[1.366856]  asymmetric_key_preparse+0xd3/0x1b0
[1.367166]  ? memset+0x31/0x40
[1.367385]  ? asymmetric_key_free_preparse+0x190/0x190
[1.367743]  key_create_or_update+0x365/0xa00
[1.368043]  ? key_type_lookup+0xe0/0xe0
[1.368314]  ? vprintk_default+0x74/0xf0
[1.368584]  ? vprintk_func+0x4c/0x90
[1.368839]  ? printk+0xbe/0xf2
[1.369059]  load_system_certificate_list+0x1ab/0x240
[1.369402]  ? system_trusted_keyring_init+0x9d/0x9d
[1.369755]  do_one_initcall+0xb9/0x280
[1.370030]  ? initcall_blacklisted+0x1b0/0x1b0
[1.370344]  ? parse_args+0x228/0xb60
[1.370607]  kernel_init_freeable+0x528/0x612
[1.370937]  ? start_kernel+0x70b/0x70b
[1.371215]  ? compat_start_thread+0x80/0x80
[1.371544]  ? rest_init+0xb0/0xb0
[1.371805]  kernel_init+0x18/0x180
[1.372055]  ? rest_init+0xb0/0xb0
[1.372300]  ret_from_fork+0x2c/0x40
[1.372610] Code: ff ff e8 52 8a 8a ff 48 8b bd 50 fe ff ff e8 66
77 b1 ff e9 58 fb ff ff e8 3c 8a 8a ff 0f 0b e8 35 8a 8a ff 0f 0b e8
2e 8a 8a ff <0f> 0b e8 27 8a 8a ff 0f 0b e8 20 8a 8a ff 41 bd f4 ff ff
ff e9
[1.374192] RIP: public_key_verify_signature+0x772/0x9b0 RSP:
88006c547840
[1.374840] ---[ end trace 6fefa18a45f0fc9e ]---
[1.375242] Kernel panic - not syncing: Fatal exception
[1.375736] Kernel Offset: disabled
[1.376026] ---[ end Kernel panic - not syncing: Fatal exception


Tracing into public_key.c:

 94 BUG_ON(!pkey);
 95 BUG_ON(!sig);
 96 BUG_ON(!sig->digest);
 97 BUG_ON(!sig->s);
 98

There is no check on the digest and length being zero anywhere.   And
not sure where is the right place to intialize if any.

Is this a bug?  Thanks.

[PATCH v3] writeback: Rework wb_[dec|inc]_stat family of functions

[Nikolay Borisov]

Currently the writeback statistics code uses a percpu counters to hold
various statistics. Furthermore we have 2 families of functions - those which
disable local irq and those which doesn't and whose names begin with
double underscore. However, they both end up calling __add_wb_stats which in
turn calls percpu_counter_add_batch which is already irq-safe.

Exploiting this fact allows to eliminated the __wb_* functions since they don't
add any further protection than we already have. Furthermore, refactor
the wb_* function to call __add_wb_stat directly without the irq-disabling
dance. This will likely result in better runtime of code which deals with
modifying the stat counters.

While at it also document why percpu_counter_add_batch is in fact preempt and
irq-safe since at least 3 people got confused.

Signed-off-by: Nikolay Borisov 
---

Changes since v2: 
* Fixed build failure reported by kbuild test robot
* Explicitly document that percpu_counter_add_batch is preempt/irq safe
 fs/fs-writeback.c   |  8 
 include/linux/backing-dev.h | 24 ++--
 lib/percpu_counter.c|  7 +++
 mm/page-writeback.c | 10 +-
 4 files changed, 18 insertions(+), 31 deletions(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 63ee2940775c..309364aab2a5 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -380,8 +380,8 @@ static void inode_switch_wbs_work_fn(struct work_struct 
*work)
struct page *page = radix_tree_deref_slot_protected(slot,
&mapping->tree_lock);
if (likely(page) && PageDirty(page)) {
-   __dec_wb_stat(old_wb, WB_RECLAIMABLE);
-   __inc_wb_stat(new_wb, WB_RECLAIMABLE);
+   dec_wb_stat(old_wb, WB_RECLAIMABLE);
+   inc_wb_stat(new_wb, WB_RECLAIMABLE);
}
}
 
@@ -391,8 +391,8 @@ static void inode_switch_wbs_work_fn(struct work_struct 
*work)
&mapping->tree_lock);
if (likely(page)) {
WARN_ON_ONCE(!PageWriteback(page));
-   __dec_wb_stat(old_wb, WB_WRITEBACK);
-   __inc_wb_stat(new_wb, WB_WRITEBACK);
+   dec_wb_stat(old_wb, WB_WRITEBACK);
+   inc_wb_stat(new_wb, WB_WRITEBACK);
}
}
 
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index ace73f96eb1e..e9c967b86054 100644
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -69,34 +69,14 @@ static inline void __add_wb_stat(struct bdi_writeback *wb,
percpu_counter_add_batch(&wb->stat[item], amount, WB_STAT_BATCH);
 }
 
-static inline void __inc_wb_stat(struct bdi_writeback *wb,
-enum wb_stat_item item)
-{
-   __add_wb_stat(wb, item, 1);
-}
-
 static inline void inc_wb_stat(struct bdi_writeback *wb, enum wb_stat_item 
item)
 {
-   unsigned long flags;
-
-   local_irq_save(flags);
-   __inc_wb_stat(wb, item);
-   local_irq_restore(flags);
-}
-
-static inline void __dec_wb_stat(struct bdi_writeback *wb,
-enum wb_stat_item item)
-{
-   __add_wb_stat(wb, item, -1);
+   __add_wb_stat(wb, item, 1);
 }
 
 static inline void dec_wb_stat(struct bdi_writeback *wb, enum wb_stat_item 
item)
 {
-   unsigned long flags;
-
-   local_irq_save(flags);
-   __dec_wb_stat(wb, item);
-   local_irq_restore(flags);
+   __add_wb_stat(wb, item, -1);
 }
 
 static inline s64 wb_stat(struct bdi_writeback *wb, enum wb_stat_item item)
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index 8ee7e5ec21be..3bf4a9984f4c 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -72,6 +72,13 @@ void percpu_counter_set(struct percpu_counter *fbc, s64 
amount)
 }
 EXPORT_SYMBOL(percpu_counter_set);
 
+/**
+ * This function is both preempt and irq safe. The former is due to explicit
+ * preemption disable. The latter is guaranteed by the fact that the slow path
+ * is explicitly protected by an irq-safe spinlock whereas the fast patch uses
+ * this_cpu_add which is irq-safe by definition. Hence there is no need muck
+ * with irq state before calling this one
+ */
 void percpu_counter_add_batch(struct percpu_counter *fbc, s64 amount, s32 
batch)
 {
s64 count;
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 143c1c25d680..b7451891959a 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -601,7 +601,7 @@ static inline void __wb_writeout_inc(struct bdi_writeback 
*wb)
 {
struct wb_domain *cgdom;
 
-   __inc_wb_stat(wb, WB_WRITTEN);
+   inc_wb_stat(wb, WB_WRITTEN);
wb_domain_writeout_inc(&global_wb_domain, &wb->completions,
   wb->bdi->max_prop_frac);
 
@@ -2437,8 +2437,8 @@ void account_page_dirtied

Re: [RFC v2 07/12] powerpc: Macro the mask used for checking DSI exception

[Aneesh Kumar K.V]

Ram Pai  writes:

> Replace the magic number used to check for DSI exception
> with a meaningful value.
>
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/reg.h   | 9 -
>  arch/powerpc/kernel/exceptions-64s.S | 2 +-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 7e50e47..2dcb8a1 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -272,16 +272,23 @@
>  #define SPRN_DAR 0x013   /* Data Address Register */
>  #define SPRN_DBCR0x136   /* e300 Data Breakpoint Control Reg */
>  #define SPRN_DSISR   0x012   /* Data Storage Interrupt Status Register */
> +#define   DSISR_BIT320x8000  /* not defined */
>  #define   DSISR_NOHPTE   0x4000  /* no translation found 
> */
> +#define   DSISR_PAGEATTR_CONFLT  0x2000  /* page attribute 
> conflict */
> +#define   DSISR_BIT350x1000  /* not defined */
>  #define   DSISR_PROTFAULT0x0800  /* protection fault */
>  #define   DSISR_BADACCESS0x0400  /* bad access to CI or G */
>  #define   DSISR_ISSTORE  0x0200  /* access was a store */
>  #define   DSISR_DABRMATCH0x0040  /* hit data breakpoint */
> -#define   DSISR_NOSEGMENT0x0020  /* SLB miss */
>  #define   DSISR_KEYFAULT 0x0020  /* Key fault */
> +#define   DSISR_BIT430x0010  /* not defined */
>  #define   DSISR_UNSUPP_MMU   0x0008  /* Unsupported MMU config */
>  #define   DSISR_SET_RC   0x0004  /* Failed setting of 
> R/C bits */
>  #define   DSISR_PGDIRFAULT  0x0002  /* Fault on page directory */
> +#define   DSISR_PAGE_FAULT_MASK (DSISR_BIT32 | \
> + DSISR_PAGEATTR_CONFLT | \
> + DSISR_BADACCESS |   \
> + DSISR_BIT43)
>  #define SPRN_TBRL0x10C   /* Time Base Read Lower Register (user, R/O) */
>  #define SPRN_TBRU0x10D   /* Time Base Read Upper Register (user, R/O) */
>  #define SPRN_CIR 0x11B   /* Chip Information Register (hyper, R/0) */
> diff --git a/arch/powerpc/kernel/exceptions-64s.S 
> b/arch/powerpc/kernel/exceptions-64s.S
> index ae418b8..3fd0528 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -1411,7 +1411,7 @@ USE_TEXT_SECTION()
>   .balign IFETCH_ALIGN_BYTES
>  do_hash_page:
>  #ifdef CONFIG_PPC_STD_MMU_64
> - andis.  r0,r4,0xa410/* weird error? */
> + andis.  r0,r4,DSISR_PAGE_FAULT_MASK@h
>   bne-handle_page_fault   /* if not, try to insert a HPTE */
>   andis.  r0,r4,DSISR_DABRMATCH@h
>   bne-handle_dabr_fault


Thanks for doing this. I always wondered what that 0xa410 indicates. Now
tha it is documented, I am wondering are those the only DSISR values
that we want to check early ? You also added few bit positions that is
expected to carry value 0 ? But then excluded BIT35. Any reason ?

-aneesh

[PATCH v2 2/2] i2c: Add Spreadtrum I2C controller driver

[Baolin Wang]

This patch adds the I2C controller driver for Spreadtrum platform.

Signed-off-by: Baolin Wang 
---
Changes since v1:
 - Power on I2C device in probe().
 - Remove redundant macros and usb __maybe_unused.
 - Remove redundant 'of_match_ptr'.
 - Modify return values and check the return value for 'clk_prepare_enable'.
---
 drivers/i2c/busses/Kconfig|   10 +
 drivers/i2c/busses/Makefile   |1 +
 drivers/i2c/busses/i2c-sprd.c |  696 +
 3 files changed, 707 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-sprd.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 8adc0f1..dfbc301 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -877,6 +877,16 @@ config I2C_SIRF
  This driver can also be built as a module.  If so, the module
  will be called i2c-sirf.
 
+config I2C_SPRD
+   tristate "Spreadtrum I2C interface"
+   depends on ARCH_SPRD
+   help
+ If you say yes to this option, support will be included for the
+ Spreadtrum I2C interface.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-sprd.
+
 config I2C_ST
tristate "STMicroelectronics SSC I2C support"
depends on ARCH_STI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 30b6085..dd46c21 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_I2C_SH7760)  += i2c-sh7760.o
 obj-$(CONFIG_I2C_SH_MOBILE)+= i2c-sh_mobile.o
 obj-$(CONFIG_I2C_SIMTEC)   += i2c-simtec.o
 obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o
+obj-$(CONFIG_I2C_SPRD) += i2c-sprd.o
 obj-$(CONFIG_I2C_ST)   += i2c-st.o
 obj-$(CONFIG_I2C_STM32F4)  += i2c-stm32f4.o
 obj-$(CONFIG_I2C_STU300)   += i2c-stu300.o
diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
new file mode 100644
index 000..6ae73e71
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -0,0 +1,696 @@
+/*
+ * Copyright (C) 2017 Spreadtrum Communications Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define I2C_CTL0x0
+#define I2C_ADDR_CFG   0x4
+#define I2C_COUNT  0x8
+#define I2C_RX 0xC
+#define I2C_TX 0x10
+#define I2C_STATUS 0x14
+#define I2C_HSMODE_CFG 0x18
+#define I2C_VERSION0x1C
+#define ADDR_DVD0  0x20
+#define ADDR_DVD1  0x24
+#define ADDR_STA0_DVD  0x28
+#define ADDR_RST   0x2C
+
+/* I2C_CTL */
+#define STP_EN BIT(20)
+#define FIFO_AF_LVL16
+#define FIFO_AE_LVL12
+#define I2C_DMA_EN BIT(11)
+#define FULL_INTEN BIT(10)
+#define EMPTY_INTENBIT(9)
+#define I2C_DVD_OPTBIT(8)
+#define I2C_OUT_OPTBIT(7)
+#define I2C_TRIM_OPT   BIT(6)
+#define I2C_HS_MODEBIT(4)
+#define I2C_MODE   BIT(3)
+#define I2C_EN BIT(2)
+#define I2C_INT_EN BIT(1)
+#define I2C_START  BIT(0)
+
+/* I2C_STATUS */
+#define SDA_IN BIT(21)
+#define SCL_IN BIT(20)
+#define FIFO_FULL  BIT(4)
+#define FIFO_EMPTY BIT(3)
+#define I2C_INTBIT(2)
+#define I2C_RX_ACK BIT(1)
+#define I2C_BUSY   BIT(0)
+
+/* ADDR_RST */
+#define I2C_RSTBIT(0)
+
+#define I2C_FIFO_DEEP  12
+#define I2C_FIFO_FULL_THLD 15
+#define I2C_FIFO_EMPTY_THLD4
+#define I2C_DATA_STEP  8
+#define SPRD_I2C_TIMEOUT   (msecs_to_jiffies(1000))
+
+/* timeout (ms) for pm runtime autosuspend */
+#define SPRD_I2C_PM_TIMEOUT1000
+
+/* SPRD i2c data structure */
+struct sprd_i2c {
+   struct i2c_adapter adap;
+   struct device *dev;
+   void __iomem *base;
+   struct i2c_msg *msg;
+   struct clk *clk;
+   unsigned int src_clk;
+   unsigned int bus_freq;
+   struct completion complete;
+   u8 *buf;
+   u16 count;
+   int irq;
+   int err;
+};
+
+static void sprd_i2c_dump_reg(struct sprd_i2c *i2c_dev)
+{
+   dev_err(&i2c_dev->adap.dev, ": ==dump i2c-%d reg===\n",
+   i2c_dev->adap.nr);
+   dev_err(&i2c_dev->adap.dev, ": I2C_CTRL:0x%x\n",
+

[PATCH v2 1/2] dt-bindings: i2c: Add Spreadtrum I2C controller documentation

[Baolin Wang]

This patch adds the binding documentation for Spreadtrum I2C
controller device.

Signed-off-by: Baolin Wang 
---
Changes since v1:
 - No updates.
---
 Documentation/devicetree/bindings/i2c/i2c-sprd.txt |   31 
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sprd.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-sprd.txt 
b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
new file mode 100644
index 000..f285e5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-sprd.txt
@@ -0,0 +1,31 @@
+I2C for Spreadtrum platforms
+
+Required properties:
+- compatible: Should be "sprd,r8p0-i2c".
+- reg: Specify the physical base address of the controller and length
+  of memory mapped region.
+- interrupts: Should contain I2C interrupt.
+- clock-names: Should contain following entries:
+  "i2c" for I2C clock,
+  "source" for I2C source (parent) clock,
+  "enable" for I2C module enable clock.
+- clocks: Should contain a clock specifier for each entry in clock-names.
+- clock-frequency: Constains desired I2C bus clock frequency in Hz.
+- #address-cells: Should be 1 to describe address cells for I2C device address.
+- #size-cells: Should be 0 means no size cell for I2C device address.
+
+Optional properties:
+- Child nodes conforming to I2C bus binding
+
+Examples:
+i2c0: i2c@7050 {
+   compatible = "sprd,r8p0-i2c";
+   reg = <0 0x7050 0 0x1000>;
+   interrupts = ;
+   clock-names = "i2c", "source", "enable";
+   clocks = <&clk_i2c3>, <&ext_26m>, <&clk_ap_apb_gates 11>;
+   clock-frequency = <40>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+};
+
-- 
1.7.9.5

Re: [PATCH 1/6] ARM: dts: rockchip: add basic dtsi file for RK3229 SoC

[Huang, Tao]

Hi Jacob and Heiko:
On 2017年06月21日 12:11, Jacob Chen wrote:
> Hi,
>
> 2017-06-20 18:48 GMT+08:00 Heiko Stübner  >:
> > Hi Frank,
> >
> > Am Dienstag, 20. Juni 2017, 15:13:00 CEST schrieb Frank Wang:
> >> Hi Heiko,
> >>
> >> On 2017/6/19 20:30, Heiko Stübner wrote:
> >> > Hi Frank,
> >> >
> >> > Am Montag, 19. Juni 2017, 18:34:27 CEST schrieb Frank Wang:
> >> >> On 2017/6/18 2:12, Heiko Stuebner wrote:
> >> >>> Am Donnerstag, 15. Juni 2017, 15:16:15 CEST schrieb Frank Wang:
> >>  Due to some tiny differences between RK3228 and RK3229, this patch
> >>  adds a basic dtsi file which includes a new CPU opp table and PSCI
> >>  brought up support for RK3229.
> >> 
> >>  Signed-off-by: Frank Wang >
> >> >
> >> > [...]
> >> >
> >>  +psci {
> >>  +compatible = "arm,psci-1.0", "arm,psci-0.2";
> >>  +method = "smc";
> >>  +};
> >>  +};
> >>  +
> >>  +&cpu0 {
> >>  +enable-method = "psci";
> >>  +};
> >> >>>
> >> >>> Hmm, I don't really understand this.
> >> >>> What method of core-bringup does the rk3228 use? In the current
> >> >>> rk322x.dtsi there is no enable-method at all defined.
> >> >>
> >> >> For non-security, the same with rk3036 SoC, we use rk3036-smp
> method to
> >> >> bring-up cores, and for security, we use arm-psci method.
> >> >> As security become more and more important and required, we
> would prefer
> >> >> using arm-psci method, and it is also an easy way to use.
> >> >>
> >> >>> So is the rk3228 firmware using a different method than the rk3229?
> >> >>
> >> >> No, they are the same. How about I move these changes to
> rk322x.dtsi?
> >> >
> >> > yep, that is what I was getting at with my question ;-)
> >> >
> >> >>> And out of curiosity as this is a arm32 without atf, is the psci
> >> >>> implementation (for uboot?) you're using available somewhere?
> >> >>
> >> >> Ah, it is included in op-tee :-)
> >> >
> >> > Is that super secret or will this be part of the official op-tee [0]
> >> > at some point (Similar to the ATF stuff on arm64)?
> >>
> >> Hmm, the op-tee itself must keep secure, but the psci part in it can be
> >> extracted to public, although it may have a bit of secure risk.
> >> Due to Rockchip have amended the frame of op-tee to support psci,
> we can
> >> try to upstream these changes to official op-tee or push them to source
> >> codes of Rockchip in git-hub.
> >
> > I just want to make sure, people can actually create a working system
> > with this, as there is mainline u-boot support for the rk3228/rk3229 in
> > the works - hopefully also with SPL support later on.
> > So I'm wondering how this is supposed to be setup?
> >
> > On arm64 we now have the SPL load the ATF, which in turn loads
> uboot, so I
> > guess the mechanism for the op-tee would be somehow similar? And
> there all
> > necessary components are available to build everything from source.
> >
> > I really don't care about all the other super-secret stuff happening in
> > that op-tee thingy, but I really want people to be able to build a
> complete
> > firmware on their machine, without having to rely on arbitary binary
> blobs.
> >
> > Which is something companies adopting Rockchip socs seem to rely on
> > a lot these days ;-) .
> >
> >
> > One alternative I can think of, would be to also create a u-boot psci
> > implementation for arm32, like sunxi [0] and others use for example.
> > That way people could choose where their psci should come from (u-boot
> > itself or the op-tee).
> >
> >
> > Heiko
> >
> > [0]
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/psci.c
> >
> >>
> >>
> >> BR.
> >> Frank
> >>
> >> > Heiko
> >> >
> >> > [0]https://github.com/OP-TEE/optee_os/tree/master/core/arch/arm
> >
> >
>
> 😀 Implement psci in upstream u-boot  sounds a good idea. 
>
> I don't like the bundled solution, like if I want  to enable  power
> management in my board,  i have to use OP-TEE, then i have to use
> vendor u-boot, then vendor kernel, rootfs, tools..
>
No. The kernel only depends on PSCI. Anyone can implement PSCI firmware
through
OPTEE/Trusty/U-Boot/UEFI or other open source implementation. We don't limit
people use vendor software or not. As Frank said, we will open source
OPTEE which
support PSCI for our chips.
BTW people can implement SMP/suspend function builtin in kernel as
usual. We just
hope use PSCI by default, so we can support TEE more easy as arm64.

Re: [PATCH v4] irqchip/gicv3-its: Avoid memory over allocation for ITEs

[Marc Zyngier]

On 21/06/17 02:22, Shanker Donthineni wrote:
> Hi Marc,
> 
> On 05/06/2017 06:25 AM, Marc Zyngier wrote:
>> On Fri, May 05 2017 at 11:04:22 pm BST, Shanker Donthineni 
>>  wrote:
>>> Hi Marc,
>>>
>>>
>>> On 05/02/2017 11:16 AM, Marc Zyngier wrote:
 On Sun, Apr 30 2017 at  3:36:15 pm BST, Shanker Donthineni 
  wrote:
> We are always allocating extra 255Bytes of memory to handle ITE
> physical address alignment requirement. The kmalloc() satisfies
> the ITE alignment since the ITS driver is requesting a minimum
> size of ITS_ITT_ALIGN bytes.
>
> Let's try to allocate the exact amount of memory that is required
> for ITEs to avoid wastage.
>
> Signed-off-by: Shanker Donthineni 
> ---
> Changes:
> v2: removed 'Change-Id: Ia8084189833f2081ff13c392deb5070c46a64038' from 
> commit.
> v3: changed from IITE to ITE.
> v3: removed fallback since kmalloc() guarantees the right alignment.
>
>  drivers/irqchip/irq-gic-v3-its.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
> b/drivers/irqchip/irq-gic-v3-its.c
> index 45ea1933..72e56f03 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -261,7 +261,6 @@ static struct its_collection 
> *its_build_mapd_cmd(struct its_cmd_block *cmd,
>   u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites);
>  
>   itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt);
> - itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN);
>  
>   its_encode_cmd(cmd, GITS_CMD_MAPD);
>   its_encode_devid(cmd, desc->its_mapd_cmd.dev->device_id);
> @@ -1329,13 +1328,14 @@ static struct its_device 
> *its_create_device(struct its_node *its, u32 dev_id,
>*/
>   nr_ites = max(2UL, roundup_pow_of_two(nvecs));
>   sz = nr_ites * its->ite_size;
> - sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
> + sz = max(sz, ITS_ITT_ALIGN);
>   itt = kzalloc(sz, GFP_KERNEL);
>   lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis);
>   if (lpi_map)
>   col_map = kzalloc(sizeof(*col_map) * nr_lpis, GFP_KERNEL);
>  
> - if (!dev || !itt || !lpi_map || !col_map) {
> + if (!dev || !itt || !lpi_map || !col_map ||
> + !IS_ALIGNED(virt_to_phys(itt), ITS_ITT_ALIGN)) {
>   kfree(dev);
>   kfree(itt);
>   kfree(lpi_map);
 I'm confused. Either the alignment is guaranteed (and you should
 document why it is so), or it is not, and we need to handle the
 non-alignment (instead of failing).
>>>
>>> Sorry for confusion, alignment is guaranteed by kmalloc(), added a
>>> check for readability purpose only can be removed.
>>
>> My question still remains. Where exactly is that alignment guarantee
>> documented and enforced? I can't see anything giving that certainty.
>>
> 
> The internal implementation of kmalloc() uses the slab/slub feature
> to allocate memory from 2^N size pool. Linux kernel maintains the
> fixed size of kmem_cache pools to serve the kmalloc(), It allocates
> minimum size of 128Bytes and maximum size depends on the system
> configuration and memory availability. In fact SMMUv3 driver has a
> similar requirement and absolutely there no problem using kmalloc()
> to meet the address alignment requirement.
> 
> Call trace:
> kmalloc()
>   kmalloc_slab() --> convert size to kmem_cache
>   slab_alloc()   ---> allocate 2^N size kmem_cache object
>
> root@null-8cfdf006971f:~# cat /proc/slabinfo | grep kmall
> dma-kmalloc-131072 0  0 13107248 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-65536  0  0  6553688 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-32768  0  0  32768   168 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-16384  0  0  16384   328 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-8192   0  0   8192   324 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-4096   0  0   4096   322 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-2048   0  0   2048   321 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-1024   0  0   1024   641 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-512  128128512  1281 : tunables000 : 
> slabdata  1  1  0
> dma-kmalloc-2560  0256  2561 : tunables000 : 
> slabdata  0  0  0
> dma-kmalloc-128  512512128  5121 : tunables000 : 
> slabdata  1  1  0
> kmalloc-131072 4  4 13107248 : tunables000 : 
> slabdata  1  1  0
> kmalloc-65536376376  6

[PATCH v2] tpm: consolidate the TPM startup code

[Jarkko Sakkinen]

Consolidated all the "manual" TPM startup code to a single function
in order to make code flows a bit cleaner and migrate to tpm_buf.

Signed-off-by: Jarkko Sakkinen 
---
v2: startup type is u16 (not u32)
 drivers/char/tpm/tpm-interface.c | 67 +---
 drivers/char/tpm/tpm.h   |  6 +---
 drivers/char/tpm/tpm2-cmd.c  | 32 +--
 3 files changed, 44 insertions(+), 61 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index d2b4df6d9894..3123a6e44687 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -540,6 +540,47 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct 
tpm_space *space,
 }
 EXPORT_SYMBOL_GPL(tpm_transmit_cmd);
 
+#define TPM_ORD_STARTUP 153
+#define TPM_ST_CLEAR 1
+
+/**
+ * tpm_startup - turn on the TPM
+ * @chip: TPM chip to use
+ *
+ * Normally the firmware should start the TPM. This function is provided as a
+ * workaround if this does not happen. A legal case for this could be for
+ * example when a TPM emulator is used.
+ *
+ * Return: same as tpm_transmit_cmd()
+ */
+int tpm_startup(struct tpm_chip *chip)
+{
+   struct tpm_buf buf;
+   int rc;
+
+   dev_info(&chip->dev, "starting up the TPM manually\n");
+
+   if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+   rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_STARTUP);
+   if (rc < 0)
+   return rc;
+
+   tpm_buf_append_u16(&buf, TPM2_SU_CLEAR);
+   } else {
+   rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_STARTUP);
+   if (rc < 0)
+   return rc;
+
+   tpm_buf_append_u16(&buf, TPM_ST_CLEAR);
+   }
+
+   rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
+ "attempting to start the TPM");
+
+   tpm_buf_destroy(&buf);
+   return rc;
+}
+
 #define TPM_DIGEST_SIZE 20
 #define TPM_RET_CODE_IDX 6
 #define TPM_INTERNAL_RESULT_SIZE 200
@@ -586,27 +627,6 @@ ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, 
cap_t *cap,
 }
 EXPORT_SYMBOL_GPL(tpm_getcap);
 
-#define TPM_ORD_STARTUP 153
-#define TPM_ST_CLEAR cpu_to_be16(1)
-#define TPM_ST_STATE cpu_to_be16(2)
-#define TPM_ST_DEACTIVATED cpu_to_be16(3)
-static const struct tpm_input_header tpm_startup_header = {
-   .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
-   .length = cpu_to_be32(12),
-   .ordinal = cpu_to_be32(TPM_ORD_STARTUP)
-};
-
-static int tpm_startup(struct tpm_chip *chip, __be16 startup_type)
-{
-   struct tpm_cmd_t start_cmd;
-   start_cmd.header.in = tpm_startup_header;
-
-   start_cmd.params.startup_in.startup_type = startup_type;
-   return tpm_transmit_cmd(chip, NULL, &start_cmd,
-   TPM_INTERNAL_RESULT_SIZE, 0,
-   0, "attempting to start the TPM");
-}
-
 int tpm_get_timeouts(struct tpm_chip *chip)
 {
cap_t cap;
@@ -636,10 +656,7 @@ int tpm_get_timeouts(struct tpm_chip *chip)
rc = tpm_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap, NULL,
sizeof(cap.timeout));
if (rc == TPM_ERR_INVALID_POSTINIT) {
-   /* The TPM is not started, we are the first to talk to it.
-  Execute a startup command. */
-   dev_info(&chip->dev, "Issuing TPM_STARTUP\n");
-   if (tpm_startup(chip, TPM_ST_CLEAR))
+   if (tpm_startup(chip))
return rc;
 
rc = tpm_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap,
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index d9835b31f652..1f9094f03151 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -371,16 +371,11 @@ struct tpm_getrandom_in {
__be32 num_bytes;
 } __packed;
 
-struct tpm_startup_in {
-   __be16  startup_type;
-} __packed;
-
 typedef union {
struct  tpm_pcrread_in  pcrread_in;
struct  tpm_pcrread_out pcrread_out;
struct  tpm_getrandom_in getrandom_in;
struct  tpm_getrandom_out getrandom_out;
-   struct tpm_startup_in startup_in;
 } tpm_cmd_params;
 
 struct tpm_cmd_t {
@@ -506,6 +501,7 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct 
tpm_space *space,
 const void *buf, size_t bufsiz,
 size_t min_rsp_body_length, unsigned int flags,
 const char *desc);
+int tpm_startup(struct tpm_chip *chip);
 ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
   const char *desc, size_t min_cap_length);
 int tpm_get_timeouts(struct tpm_chip *);
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 3a9964326279..1962c9b15cd5 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -779,36 +779,6 @@ ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 
property_id,  u32 *value,
 }
 EXPORT_

Re: [PATCH] HID: multitouch: Add support for Google Rose Touchpad

[Benjamin Tissoires]

On Jun 21 2017 or thereabouts, Wei-Ning Huang wrote:
> Add Google Rose Touchpad USB PID and required quirks.
> 
> Signed-off-by: Wei-Ning Huang 
> ---

Looks good to me

Reviewed-by: Benjamin Tissoires 

>  drivers/hid/hid-ids.h|  3 +++
>  drivers/hid/hid-multitouch.c | 12 
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 8ca1e8ce0af2..91c4a89615d7 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -425,6 +425,9 @@
>  #define USB_VENDOR_ID_GOODTOUCH  0x1aad
>  #define USB_DEVICE_ID_GOODTOUCH_000f 0x000f
>  
> +#define USB_VENDOR_ID_GOOGLE 0x18d1
> +#define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE  0x5028
> +
>  #define USB_VENDOR_ID_GOTOP  0x08f2
>  #define USB_DEVICE_ID_SUPER_Q2   0x007f
>  #define USB_DEVICE_ID_GOGOPEN0x00ce
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 24d5b6deb571..5052aca8b984 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -161,6 +161,7 @@ static void mt_post_parse(struct mt_device *td);
>  #define MT_CLS_GENERALTOUCH_PWT_TENFINGERS   0x0109
>  #define MT_CLS_LG0x010a
>  #define MT_CLS_VTL   0x0110
> +#define MT_CLS_GOOGLE0x0111
>  
>  #define MT_DEFAULT_MAXCONTACT10
>  #define MT_MAX_MAXCONTACT250
> @@ -278,6 +279,12 @@ static struct mt_class mt_classes[] = {
>   MT_QUIRK_CONTACT_CNT_ACCURATE |
>   MT_QUIRK_FORCE_GET_FEATURE,
>   },
> + { .name = MT_CLS_GOOGLE,
> + .quirks = MT_QUIRK_ALWAYS_VALID |
> + MT_QUIRK_CONTACT_CNT_ACCURATE |
> + MT_QUIRK_SLOT_IS_CONTACTID |
> + MT_QUIRK_HOVERING
> + },
>   { }
>  };
>  
> @@ -1569,6 +1576,11 @@ static const struct hid_device_id mt_devices[] = {
>   MT_USB_DEVICE(USB_VENDOR_ID_XIROKU,
>   USB_DEVICE_ID_XIROKU_CSR2) },
>  
> + /* Google MT devices */
> + { .driver_data = MT_CLS_GOOGLE,
> + HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, USB_VENDOR_ID_GOOGLE,
> + USB_DEVICE_ID_GOOGLE_TOUCH_ROSE) },
> +
>   /* Generic MT device */
>   { HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH, HID_ANY_ID, HID_ANY_ID) 
> },
>  
> -- 
> 2.12.2
> 

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Gerd Hoffmann]

  Hi,

> We already have VFIO_DEVICE_GET_INFO which returns:
> 
> struct vfio_device_info {
> __u32   argsz;
> __u32   flags;
> #define VFIO_DEVICE_FLAGS_RESET (1 << 0)/* Device supports
> reset */
> #define VFIO_DEVICE_FLAGS_PCI   (1 << 1)/* vfio-pci device */
> #define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform
> device */
> #define VFIO_DEVICE_FLAGS_AMBA  (1 << 3)/* vfio-amba device
> */
> #define VFIO_DEVICE_FLAGS_CCW   (1 << 4)/* vfio-ccw device */
> __u32   num_regions;/* Max region index + 1 */
> __u32   num_irqs;   /* Max IRQ index + 1 */
> };
> 
> We could use two flag bits to indicate dmabuf or graphics region
> support.

That works too.

> > Then this to query the plane:
> > 
> > struct vfio_device_gfx_query_plane {
> > __u32 argsz;
> > __u32 flags;
> > struct vfio_device_gfx_plane_info plane_info;  /* out */
> > __u32 plane_type;  /* in  */
> > };
> 
> I'm not sure why we're using an enum for something that can currently
> be defined with 2 bits,

We can reuse the DRM_PLANE_TYPE_* then.

>  seems like this would be another good use of
> flags.  We could even embed an enum into the flags if we want to
> leave some expansion room, 4 bits maybe?  Also, I was imagining that
> a
> device could support multiple graphics regions, that's where
> specifying
> the "id" as a region index seemed useful.

Hmm, yes, possibly for multihead configurations.  But I guess for
proper multihead support we would need more than just an region id.

Or do you have something else in mind?

> > With the generation we can also do something different:  Pass in
> > plane_type and generation, and have VFIO_DEVICE_GET_DMABUF_FD
> > return
> > an error in case the generation doesn't match.  In that case it
> > doesn't
> > make much sense any more to have a separate plane_info struct,
> > which
> > was added so we don't have to duplicate things in query-plane and
> > get-
> > dmabuf ioctl structs.
> 
> I'm not sure I understand how this works for a region, the region is
> always the current generation, how can the user ever be sure the
> plane_info matches what is exposed in the region?

generation will change each time the plane configuration (not content)
changes.  Typically that will be on video mode switches.  In the dmabuf
case also on pageflips.

cheers,
  Gerd

Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

[Thomas Gleixner]

On Fri, 16 Jun 2017, Tom Lendacky wrote:
> Currently there is a check if the address being mapped is in the ISA
> range (is_ISA_range()), and if it is then phys_to_virt() is used to
> perform the mapping.  When SME is active, however, this will result
> in the mapping having the encryption bit set when it is expected that
> an ioremap() should not have the encryption bit set. So only use the
> phys_to_virt() function if SME is not active
> 
> Reviewed-by: Borislav Petkov 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/mm/ioremap.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 4c1b5fd..a382ba9 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -106,9 +107,11 @@ static void __iomem *__ioremap_caller(resource_size_t 
> phys_addr,
>   }
>  
>   /*
> -  * Don't remap the low PCI/ISA area, it's always mapped..
> +  * Don't remap the low PCI/ISA area, it's always mapped.
> +  *   But if SME is active, skip this so that the encryption bit
> +  *   doesn't get set.
>*/
> - if (is_ISA_range(phys_addr, last_addr))
> + if (is_ISA_range(phys_addr, last_addr) && !sme_active())
>   return (__force void __iomem *)phys_to_virt(phys_addr);

More thoughts about that.

Making this conditional on !sme_active() is not the best idea. I'd rather
remove that whole thing and make it unconditional so the code pathes get
always exercised and any subtle wreckage is detected on a broader base and
not only on that hard to access and debug SME capable machine owned by Joe
User.

Thanks,

tglx

Re: [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Daniel Vetter]

On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> totally obsolete.
> 
> I think the gamma_store can end up invalid on error. But the way I read
> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
> this pesky legacy fbdev stuff be any better?
> 
> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
> it saves it to the gamma_store which should already be up to date with what
> .gamma_get would return and is thus a nop. So, zap it.

Removing drm_fb_helper_save_lut_atomic should be a separate patch I
think.
 
> Signed-off-by: Peter Rosin 

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 131 
> 
>  1 file changed, 40 insertions(+), 91 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 574af01..cc2d55d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -229,22 +229,6 @@ int drm_fb_helper_remove_one_connector(struct 
> drm_fb_helper *fb_helper,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
>  
> -static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct 
> drm_fb_helper *helper)
> -{
> - uint16_t *r_base, *g_base, *b_base;
> - int i;
> -
> - if (helper->funcs->gamma_get == NULL)
> - return;
> -
> - r_base = crtc->gamma_store;
> - g_base = r_base + crtc->gamma_size;
> - b_base = g_base + crtc->gamma_size;
> -
> - for (i = 0; i < crtc->gamma_size; i++)
> - helper->funcs->gamma_get(crtc, &r_base[i], &g_base[i], 
> &b_base[i], i);
> -}
> -
>  static void drm_fb_helper_restore_lut_atomic(struct drm_crtc *crtc)
>  {
>   uint16_t *r_base, *g_base, *b_base;
> @@ -285,7 +269,6 @@ int drm_fb_helper_debug_enter(struct fb_info *info)
>   if (drm_drv_uses_atomic_modeset(mode_set->crtc->dev))
>   continue;
>  
> - drm_fb_helper_save_lut_atomic(mode_set->crtc, helper);
>   funcs->mode_set_base_atomic(mode_set->crtc,
>   mode_set->fb,
>   mode_set->x,
> @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct 
> drm_fb_helper *fb_helper,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>  
> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> -  u16 blue, u16 regno, struct fb_info *info)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct drm_framebuffer *fb = fb_helper->fb;
> -
> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) {

This case here seems gone, and it was also the pièce de résistance when I
tried tackling fbdev lut support. As far as I understand this stuff we do
not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
pointless. But I'm honestly not really clear.

I think removing this case should also be a separate patch, and I'd very
much prefer that someone with some fbdev-clue would ack it.

> - u32 *palette;
> - u32 value;
> - /* place color in psuedopalette */
> - if (regno > 16)
> - return -EINVAL;
> - palette = (u32 *)info->pseudo_palette;
> - red >>= (16 - info->var.red.length);
> - green >>= (16 - info->var.green.length);
> - blue >>= (16 - info->var.blue.length);
> - value = (red << info->var.red.offset) |
> - (green << info->var.green.offset) |
> - (blue << info->var.blue.offset);
> - if (info->var.transp.length > 0) {
> - u32 mask = (1 << info->var.transp.length) - 1;
> -
> - mask <<= info->var.transp.offset;
> - value |= mask;
> - }
> - palette[regno] = value;
> - return 0;
> - }
> -
> - /*
> -  * The driver really shouldn't advertise pseudo/directcolor
> -  * visuals if it can't deal with the palette.
> -  */
> - if (WARN_ON(!fb_helper->funcs->gamma_set ||
> - !fb_helper->funcs->gamma_get))
> - return -EINVAL;
> -
> - WARN_ON(fb->format->cpp[0] != 1);
> -
> - fb_helper->funcs->gamma_set(crtc, red, green, blue, regno);
> -
> - return 0;
> -}
> -
>  /**
>   * drm_fb_helper_setcmap - implementation for &fb_ops.fb_setcmap
>   * @cmap: cmap to set
> @@ -1220,51 +1159,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> struct fb_info *info)
>  {
>   struct drm_fb_helper *fb_helper = info->par;
>   struct drm_device *dev = fb_helper->dev;
> - const struct drm_crtc_helper_funcs *crtc_funcs;
> - u16 *red, *green, *blue, *transp;
> + struct drm_modeset_acquire_ctx ctx;
>   struct drm_crtc *crtc;
> - int i, j, rc = 0;
> - int

Re: [PATCH 00/11] improve the fb_setcmap helper

[Daniel Vetter]

On Tue, Jun 20, 2017 at 09:25:24PM +0200, Peter Rosin wrote:
> Hi!
> 
> While trying to get CLUT support for the atmel_hlcdc driver, and
> specifically for the emulated fbdev interface, I received some
> push-back that my feeble in-driver attempts should be solved
> by the core. This is my attempt to do it right.
> 
> Boris and Daniel, was this approximately what you had in mind?

Yeah, this is awesome. I tried to do it a few times myself, but always
failed (also due to lack of real use-case on my side).

> I have obviously not tested all of this with more than a compile,
> but the first patch is enough to make the atmel-hlcdc driver
> do what I need. The rest is just lots of removals and cleanup
> made possible by the improved core.

If it works for you it's imo good enough. Not sure anyone else really
cares about fbdev lut support at all. I have a few comments on the first
patch, but once that's sorted, and once we have given driver maintainers
enough time to ack I think I'll merge the entire pile into drm-misc.

Nice work, thanks for doing it.

Cheers, Daniel

> Please test, I would not be surprised if I have fouled up some
> bit-manipulation somewhere in this mostly mechanical change...
> 
> Cheers,
> peda
> 
> Peter Rosin (11):
>   drm/fb-helper: do a generic fb_setcmap helper in terms of crtc
> .gamma_set
>   drm: amd: remove dead code and pointless local lut storage
>   drm: ast: remove dead code and pointless local lut storage
>   drm: cirrus: remove dead code and pointless local lut storage
>   dmr: gma500: remove dead code and pointless local lut storage
>   drm: i915: remove dead code and pointless local lut storage
>   drm: mgag200: remove dead code and pointless local lut storage
>   drm: nouveau: remove dead code and pointless local lut storage
>   drm: radeon: remove dead code and pointless local lut storage
>   drm: stm: remove dead code and pointless local lut storage
>   drm: remove unused and redundant callbacks
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  24 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|   1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  27 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  27 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  27 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  27 ++
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c|  23 -
>  drivers/gpu/drm/ast/ast_drv.h   |   1 -
>  drivers/gpu/drm/ast/ast_fb.c|  20 -
>  drivers/gpu/drm/ast/ast_mode.c  |  26 ++
>  drivers/gpu/drm/cirrus/cirrus_drv.h |   8 --
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |   2 -
>  drivers/gpu/drm/cirrus/cirrus_mode.c|  71 ---
>  drivers/gpu/drm/drm_fb_helper.c | 131 
> +---
>  drivers/gpu/drm/gma500/framebuffer.c|  22 -
>  drivers/gpu/drm/gma500/gma_display.c|  32 +++
>  drivers/gpu/drm/gma500/psb_intel_display.c  |   7 +-
>  drivers/gpu/drm/gma500/psb_intel_drv.h  |   1 -
>  drivers/gpu/drm/i915/intel_drv.h|   1 -
>  drivers/gpu/drm/i915/intel_fbdev.c  |  31 ---
>  drivers/gpu/drm/mgag200/mgag200_drv.h   |   5 --
>  drivers/gpu/drm/mgag200/mgag200_fb.c|   2 -
>  drivers/gpu/drm/mgag200/mgag200_mode.c  |  62 -
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c |  26 ++
>  drivers/gpu/drm/nouveau/nouveau_crtc.h  |   3 -
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c |  22 -
>  drivers/gpu/drm/nouveau/nv50_display.c  |  39 +++--
>  drivers/gpu/drm/radeon/atombios_crtc.c  |   1 -
>  drivers/gpu/drm/radeon/radeon_connectors.c  |   7 +-
>  drivers/gpu/drm/radeon/radeon_display.c |  71 ++-
>  drivers/gpu/drm/radeon/radeon_fb.c  |   2 -
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c |   1 -
>  drivers/gpu/drm/stm/ltdc.c  |  12 ---
>  drivers/gpu/drm/stm/ltdc.h  |   1 -
>  include/drm/drm_fb_helper.h |  32 ---
>  include/drm/drm_modeset_helper_vtables.h|  16 
>  36 files changed, 171 insertions(+), 640 deletions(-)
> 
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: linux-next: build failure after merge of the gpio tree

[Linus Walleij]

On Wed, Jun 21, 2017 at 8:09 AM, Stephen Rothwell  wrote:

> It looks like those '(' ')' chars are not what they seem ...

No the owls are not what they seem. I went in and fixed the
unicode weirdness, thanks!

Pretty hard to see this one since I can't see it.

Yours,
Linus Walleij

[RFC PATCH v3] acpi: indicate to platform when hot remove returns busy

[Lee, Chun-Yi]

In hotplug logic, it always indicates non-specific failure to
platform through _OST when handing acpi hot-remove event failed. Then
platform terminates the hot-remove process but it can not identify
the reason.

Base on current hot-remove code, there have two situations that it
returns busy:
 - OSPM try to offline an individual device, but the device offline
   function returns busy.
 - When the ejection event is applied to an "not offlined yet" container.
   OSPM send kobject change event to userspace and returns busy.

Both of them will returns -EBUSY to acpi device hotplug function then
hotplug function indicates non-specific failure to platform just like
any other error, e.g. -ENODEV or -EIO.

The benefit to platform for identifying the OS busy state is that
platform can be applied different approach to handle the busy but
not just terminate the hot-remove process by unknown reason. For
example, platform can wait for a while then triggers hot-remove
again.

This RFC patch adds one more parameter to the handler function of
acpi generic hotplug event to give the function a chance to propose
the return code of _OST. In this case, it sets ost return code to
ACPI_OST_SC_DEVICE_BUSY when the acpi hot remove function returns
-EBUSY.

v3:
Removed redundant 'else' in acpi_ost_status_code(). (Andy Shevchenko)

v2:
Do not overwrite ost code in acpi_generic_hotplug_event(). Move
the "error code to ost code" logic to a help function. (Andy Shevchenko)

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Andy Shevchenko 
Cc: Michal Hocko 
Signed-off-by: "Lee, Chun-Yi" 
---
 drivers/acpi/scan.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 3a10d7573477..41f5065190c7 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -384,6 +384,20 @@ static int acpi_generic_hotplug_event(struct acpi_device 
*adev, u32 type)
return -EINVAL;
 }
 
+static int acpi_ost_status_code(u32 src, int error)
+{
+   switch (src) {
+   case ACPI_NOTIFY_EJECT_REQUEST:
+   case ACPI_OST_EC_OSPM_EJECT:
+   if (error == -EPERM)
+   return ACPI_OST_SC_EJECT_NOT_SUPPORTED;
+   if (error == -EBUSY)
+   return ACPI_OST_SC_DEVICE_BUSY;
+   break;
+   }
+   return error ? ACPI_OST_SC_NON_SPECIFIC_FAILURE : ACPI_OST_SC_SUCCESS;
+}
+
 void acpi_device_hotplug(struct acpi_device *adev, u32 src)
 {
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
@@ -404,10 +418,6 @@ void acpi_device_hotplug(struct acpi_device *adev, u32 src)
error = dock_notify(adev, src);
} else if (adev->flags.hotplug_notify) {
error = acpi_generic_hotplug_event(adev, src);
-   if (error == -EPERM) {
-   ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
-   goto err_out;
-   }
} else {
int (*notify)(struct acpi_device *, u32);
 
@@ -423,9 +433,8 @@ void acpi_device_hotplug(struct acpi_device *adev, u32 src)
else
goto out;
}
-   if (!error)
-   ost_code = ACPI_OST_SC_SUCCESS;
 
+   ost_code = acpi_ost_status_code(src, error);
  err_out:
acpi_evaluate_ost(adev->handle, src, ost_code, NULL);
 
-- 
2.12.0

Re: [PATCH 1/2] efi: Process MEMATTR table only if EFI_MEMMAP

[Ard Biesheuvel]

On 20 June 2017 at 22:14, Daniel Kiper  wrote:
> Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
>
> In theory we can check EFI_PARAVIRT too, however,
> EFI_MEMMAP looks more generic and covers more cases.
>
> Signed-off-by: Daniel Kiper 

Reviewed-by: Ard Biesheuvel 

> ---
>  drivers/firmware/efi/efi.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index b372aad..045d6d3 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -528,7 +528,8 @@ int __init efi_config_parse_tables(void *config_tables, 
> int count, int sz,
> }
> }
>
> -   efi_memattr_init();
> +   if (efi_enabled(EFI_MEMMAP))
> +   efi_memattr_init();
>
> /* Parse the EFI Properties table if it exists */
> if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
> --
> 1.7.10.4
>

Re: [PATCH v5 1/4] ARM: dts: at91: sama5d2_xplained: enable ADTRG pin

[Nicolas Ferre]

On 20/06/2017 at 18:55, Jonathan Cameron wrote:
> On Thu, 15 Jun 2017 16:24:54 +0300
> Eugen Hristev  wrote:
> 
>> Enable pinctrl for ADTRG pin (PD31) for ADC hardware trigger support.
>>
>> Signed-off-by: Eugen Hristev 
>> Acked-by: Ludovic Desroches 
> The driver changes are on their way upstream.
> 
> Acked-by: Jonathan Cameron 

Thanks Jonathan,

Acked-by: Nicolas Ferre 

Eugen, note that we may need to wait for 4.14 as our changes for 4.13
are already queued in arm-soc...

Best regards,

>> ---
>>  arch/arm/boot/dts/at91-sama5d2_xplained.dts | 16 +++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts 
>> b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
>> index 0bef9e0..04754b1 100644
>> --- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
>> +++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
>> @@ -303,7 +303,7 @@
>>  vddana-supply = <&vdd_3v3_lp_reg>;
>>  vref-supply = <&vdd_3v3_lp_reg>;
>>  pinctrl-names = "default";
>> -pinctrl-0 = <&pinctrl_adc_default>;
>> +pinctrl-0 = <&pinctrl_adc_default 
>> &pinctrl_adtrg_default>;
>>  status = "okay";
>>  };
>>  
>> @@ -322,6 +322,20 @@
>>  bias-disable;
>>  };
>>  
>> +/*
>> + * The ADTRG pin can work on any edge type.
>> + * In here it's being pulled up, so need to
>> + * connect it to ground to get an edge e.g.
>> + * Trigger can be configured on falling, rise
>> + * or any edge, and the pull-up can be changed
>> + * to pull-down or left floating according to
>> + * needs.
>> + */
>> +pinctrl_adtrg_default: adtrg_default {
>> +pinmux = ;
>> +bias-pull-up;
>> +};
>> +
>>  pinctrl_charger_chglev: charger_chglev {
>>  pinmux = ;
>>  bias-disable;
> 
> 


-- 
Nicolas Ferre

[PATCH 2/2] arm: dts: mt7623: fixup binding violation missing reset in ethernet node

[sean.wang]

From: Sean Wang 

fix up binding violation where the reset property is required
additionally.

Cc: John Crispin 
Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 2202c40..2eca877 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -782,6 +782,10 @@
 <ðsys CLK_ETHSYS_GP2>,
 <&apmixedsys CLK_APMIXED_TRGPLL>;
clock-names = "ethif", "esw", "gp1", "gp2", "trgpll";
+   resets = <ðsys MT2701_ETHSYS_FE_RST>,
+<ðsys MT2701_ETHSYS_GMAC_RST>,
+<ðsys MT2701_ETHSYS_PPE_RST>;
+   reset-names = "fe", "gmac", "ppe";
power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
mediatek,ethsys = <ðsys>;
mediatek,pctl = <&syscfg_pctl_a>;
-- 
2.7.4

[PATCH 1/2] dt-bindings: net: mediatek: update documentation for reset signals

[sean.wang]

From: Sean Wang 

Since there's no user for the property reset inside the ethernet node
for current supported MediaTek SoCs and boards, so it should be safe to
update reset property in the bindings to introduce more reset signals as
corresponding that commit 7c2adaf11036 ("reset: mediatek: Add MT2701 ethsys
reset controller include file") did in order to be referenced them from
within a devicetree file.

Cc: John Crispin 
Signed-off-by: Sean Wang 
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index c7194e8..4eea17e 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -15,8 +15,10 @@ Required properties:
 - clock-names: the names of the clock listed in the clocks property. These are
"ethif", "esw", "gp2", "gp1"
 - power-domains: phandle to the power domain that the ethernet is part of
-- resets: Should contain a phandle to the ethsys reset signal
-- reset-names: Should contain the reset signal name "eth"
+- resets: Should contain phandles to the ethsys reset signals
+- reset-names: Should contain the names of reset signal listed in the resets
+   property
+   These are "fe", "gmac" and "ppe"
 - mediatek,ethsys: phandle to the syscon node that handles the port setup
 - mediatek,pctl: phandle to the syscon node that handles the ports slew rate
and driver current
-- 
2.7.4

[PATCH 0/2] fixed ethernet binding violation for reset signal

[sean.wang]

From: Sean Wang 

Fixed binding violation and also updated related binding documentation to
reflect the reset signals the MediaTek Ethernet requires.

Sean Wang (2):
  dt-bindings: net: mediatek: update documentation for reset signals
  arm: dts: mt7623: fixup binding violation missing reset in ethernet
node

 Documentation/devicetree/bindings/net/mediatek-net.txt | 6 --
 arch/arm/boot/dts/mt7623.dtsi  | 4 
 2 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.7.4

Re: [PATCH v5 3/4] ARM: dts: at91: sama5d2: add ADC hw trigger edge type

[Nicolas Ferre]

On 20/06/2017 at 18:56, Jonathan Cameron wrote:
> On Thu, 15 Jun 2017 16:24:56 +0300
> Eugen Hristev  wrote:
> 
>> Added ADTRG edge type property as interrupt edge type value
>>
>> Signed-off-by: Eugen Hristev 
>> Acked-by: Ludovic Desroches 
> Driver support heading upstream.
> 
> Acked-by: Jonathan Cameron 

Thanks,

Acked-by: Nicolas Ferre 

>> ---
>>   Changes in v4:
>>  - Modified bindings to be similar with interrupts
>>
>>  arch/arm/boot/dts/sama5d2.dtsi | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
>> index 8067c71..483a387 100644
>> --- a/arch/arm/boot/dts/sama5d2.dtsi
>> +++ b/arch/arm/boot/dts/sama5d2.dtsi
>> @@ -1267,6 +1267,7 @@
>>  atmel,min-sample-rate-hz = <20>;
>>  atmel,max-sample-rate-hz = <2000>;
>>  atmel,startup-time-ms = <4>;
>> +atmel,trigger-edge-type = 
>> ;
>>  status = "disabled";
>>  };
>>  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Nicolas Ferre

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Pavel Machek]

Hi!

> > I agree with that but not the android guys. They seem to mandate an RTC
> > that can store time from 01/01/1970. I don't know much more than that
> > because they never cared to explain why that was actually necessary
> > (apart from a laconic "this will result in a bad user experience")
> > 
> > I think tglx had a plan for offsetting the time at some point so 32-bit
> > platform can pass 2038 properly.
> 
> Yes, but there are still quite some issues to solve there:
> 
>  1) How do you tell the system that it should apply the offset in the
>   first place, i.e at boot time before NTP or any other mechanism can
>   correct it?

I'd not do offset. Instead, I'd select a threshold (perhaps year of
release of given kernel?) and

if (rtc_time < year_of_release_of_kernel)
   rtc_time += 0x1;

Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
seen in some drivers.

>  2) Deal with creative vendors who have their own idea about the 'start
>   of the epoch'

If someone uses different threshold, well, there will be
confusion. But only for users that have their rtc set to the past,
which is quite unusual.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

[Ard Biesheuvel]

On 20 June 2017 at 22:14, Daniel Kiper  wrote:
> Current approach, wholesale efi struct initialization from efi_xen, is not
> good. Usually if new member is defined then it is properly initialized in
> drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it happened
> a few times until now. So, let's initialize only efi struct members used by
> Xen to avoid such issues in the future.
>
> Signed-off-by: Daniel Kiper 

Acked-by: Ard Biesheuvel 

> ---
>  arch/x86/xen/efi.c |   45 -
>  1 file changed, 12 insertions(+), 33 deletions(-)
>
> diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
> index 30bb2e8..01b9faf 100644
> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -54,38 +54,6 @@
> .tables = EFI_INVALID_TABLE_ADDR  /* Initialized later. */
>  };
>
> -static const struct efi efi_xen __initconst = {
> -   .systab   = NULL, /* Initialized later. */
> -   .runtime_version  = 0,/* Initialized later. */
> -   .mps  = EFI_INVALID_TABLE_ADDR,
> -   .acpi = EFI_INVALID_TABLE_ADDR,
> -   .acpi20   = EFI_INVALID_TABLE_ADDR,
> -   .smbios   = EFI_INVALID_TABLE_ADDR,
> -   .smbios3  = EFI_INVALID_TABLE_ADDR,
> -   .sal_systab   = EFI_INVALID_TABLE_ADDR,
> -   .boot_info= EFI_INVALID_TABLE_ADDR,
> -   .hcdp = EFI_INVALID_TABLE_ADDR,
> -   .uga  = EFI_INVALID_TABLE_ADDR,
> -   .uv_systab= EFI_INVALID_TABLE_ADDR,
> -   .fw_vendor= EFI_INVALID_TABLE_ADDR,
> -   .runtime  = EFI_INVALID_TABLE_ADDR,
> -   .config_table = EFI_INVALID_TABLE_ADDR,
> -   .get_time = xen_efi_get_time,
> -   .set_time = xen_efi_set_time,
> -   .get_wakeup_time  = xen_efi_get_wakeup_time,
> -   .set_wakeup_time  = xen_efi_set_wakeup_time,
> -   .get_variable = xen_efi_get_variable,
> -   .get_next_variable= xen_efi_get_next_variable,
> -   .set_variable = xen_efi_set_variable,
> -   .query_variable_info  = xen_efi_query_variable_info,
> -   .update_capsule   = xen_efi_update_capsule,
> -   .query_capsule_caps   = xen_efi_query_capsule_caps,
> -   .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
> -   .reset_system = xen_efi_reset_system,
> -   .set_virtual_address_map  = NULL, /* Not used under Xen. */
> -   .flags= 0 /* Initialized later. */
> -};
> -
>  static efi_system_table_t __init *xen_efi_probe(void)
>  {
> struct xen_platform_op op = {
> @@ -102,7 +70,18 @@ static efi_system_table_t __init *xen_efi_probe(void)
>
> /* Here we know that Xen runs on EFI platform. */
>
> -   efi = efi_xen;
> +   efi.get_time = xen_efi_get_time;
> +   efi.set_time = xen_efi_set_time;
> +   efi.get_wakeup_time = xen_efi_get_wakeup_time;
> +   efi.set_wakeup_time = xen_efi_set_wakeup_time;
> +   efi.get_variable = xen_efi_get_variable;
> +   efi.get_next_variable = xen_efi_get_next_variable;
> +   efi.set_variable = xen_efi_set_variable;
> +   efi.query_variable_info = xen_efi_query_variable_info;
> +   efi.update_capsule = xen_efi_update_capsule;
> +   efi.query_capsule_caps = xen_efi_query_capsule_caps;
> +   efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
> +   efi.reset_system = xen_efi_reset_system;
>
> efi_systab_xen.tables = info->cfg.addr;
> efi_systab_xen.nr_tables = info->cfg.nent;
> --
> 1.7.10.4
>

Re: [PATCH v4 4/6] irqchip: irq-mvebu-icu: new driver for Marvell ICU

[Marc Zyngier]

Hi Thomas,

On 20/06/17 15:07, Thomas Petazzoni wrote:
> The Marvell ICU unit is found in the CP110 block of the Marvell Armada
> 7K and 8K SoCs. It collects the wired interrupts of the devices located
> in the CP110 and turns them into SPI interrupts in the GIC located in
> the AP806 side of the SoC, by using a memory transaction.
> 
> Until now, the ICU was configured in a static fashion by the firmware,
> and Linux was relying on this static configuration. By having Linux
> configure the ICU, we are more flexible, and we can allocate dynamically
> the GIC SPI interrupts only for devices that are actually in use.
> 
> The driver was initially written by Hanna Hawa .
> 
> Signed-off-by: Thomas Petazzoni 
> ---
>  drivers/irqchip/Kconfig|   3 +
>  drivers/irqchip/Makefile   |   1 +
>  drivers/irqchip/irq-mvebu-icu.c| 291 
> +
>  .../dt-bindings/interrupt-controller/mvebu-icu.h   |  15 ++
>  4 files changed, 310 insertions(+)
>  create mode 100644 drivers/irqchip/irq-mvebu-icu.c
>  create mode 100644 include/dt-bindings/interrupt-controller/mvebu-icu.h
> 
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index e527ee5..676232a 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -271,6 +271,9 @@ config IRQ_MXS
>  config MVEBU_GICP
>   bool
>  
> +config MVEBU_ICU
> + bool
> +
>  config MVEBU_ODMI
>   bool
>   select GENERIC_MSI_IRQ_DOMAIN
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 11eb858..18fa5fa 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -70,6 +70,7 @@ obj-$(CONFIG_INGENIC_IRQ)   += irq-ingenic.o
>  obj-$(CONFIG_IMX_GPCV2)  += irq-imx-gpcv2.o
>  obj-$(CONFIG_PIC32_EVIC) += irq-pic32-evic.o
>  obj-$(CONFIG_MVEBU_GICP) += irq-mvebu-gicp.o
> +obj-$(CONFIG_MVEBU_ICU)  += irq-mvebu-icu.o
>  obj-$(CONFIG_MVEBU_ODMI) += irq-mvebu-odmi.o
>  obj-$(CONFIG_MVEBU_PIC)  += irq-mvebu-pic.o
>  obj-$(CONFIG_LS_SCFG_MSI)+= irq-ls-scfg-msi.o
> diff --git a/drivers/irqchip/irq-mvebu-icu.c b/drivers/irqchip/irq-mvebu-icu.c
> new file mode 100644
> index 000..efc80ee
> --- /dev/null
> +++ b/drivers/irqchip/irq-mvebu-icu.c
> @@ -0,0 +1,291 @@
> +/*
> + * Copyright (C) 2017 Marvell
> + *
> + * Hanna Hawa 
> + * Thomas Petazzoni 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "irq-mvebu-gicp.h"
> +
> +/* ICU registers */
> +#define ICU_SETSPI_NSR_AL0x10
> +#define ICU_SETSPI_NSR_AH0x14
> +#define ICU_CLRSPI_NSR_AL0x18
> +#define ICU_CLRSPI_NSR_AH0x1c
> +#define ICU_INT_CFG(x)  (0x100 + 4 * (x))
> +#define   ICU_INT_ENABLE BIT(24)
> +#define   ICU_IS_EDGEBIT(28)
> +#define   ICU_GROUP_SHIFT29
> +
> +/* ICU definitions */
> +#define ICU_MAX_IRQS 207
> +#define ICU_SATA0_ICU_ID 109
> +#define ICU_SATA1_ICU_ID 107
> +
> +struct mvebu_icu {
> + struct irq_chip irq_chip;
> + void __iomem *base;
> + struct irq_domain *domain;
> + struct device *dev;
> +};
> +
> +struct mvebu_icu_irq_data {
> + struct mvebu_icu *icu;
> + unsigned int icu_group;
> + unsigned int type;
> +};
> +
> +static void mvebu_icu_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> +{
> + struct irq_data *d = irq_get_irq_data(desc->irq);
> + struct mvebu_icu_irq_data *icu_irqd = d->chip_data;
> + struct mvebu_icu *icu = icu_irqd->icu;
> + unsigned int icu_int;
> +
> + if (msg->address_lo) {

As mention in the previous thread, this needs to check address_hi as well.

> + /* Configure the ICU with irq number & type */
> + icu_int = msg->data | ICU_INT_ENABLE;
> + if (icu_irqd->type & IRQ_TYPE_EDGE_RISING)
> + icu_int |= ICU_IS_EDGE;
> + icu_int |= icu_irqd->icu_group << ICU_GROUP_SHIFT;
> + } else {
> + /* De-configure the ICU */
> + icu_int = 0;
> + }
> +
> + writel_relaxed(icu_int, icu->base + ICU_INT_CFG(d->hwirq));
> +
> + /*
> +  * The SATA unit has 2 ports, and a dedicated ICU entry per
> +  * port. The ahci sata driver supports only one irq interrupt
> +  * per SATA unit. To solve this conflict, we configure the 2
> +  * SATA wired interrupts in the south bridge into 1 GIC
> +  * interrupt in the north bridge. Even if only a single port
> +  * is enabled, if sata node is enabled, both interrupts are
> +  * configured (regardless of which port is actually in use).
> +  */

Re: [PATCH v4 5/6] arm64: marvell: enable ICU and GICP drivers

[Marc Zyngier]

On 20/06/17 15:07, Thomas Petazzoni wrote:
> This commit enables the newly introduced Marvell GICP and ICUs driver
> for the 64-bit Marvell EBU platforms.
> 
> Signed-off-by: Thomas Petazzoni 
> ---
>  arch/arm64/Kconfig.platforms | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4afcffc..bf3b505 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -106,6 +106,8 @@ config ARCH_MVEBU
>   select ARMADA_AP806_SYSCON
>   select ARMADA_CP110_SYSCON
>   select ARMADA_37XX_CLK
> + select MVEBU_GICP
> + select MVEBU_ICU
>   select MVEBU_ODMI
>   select MVEBU_PIC
>   help
> 

Acked-by: Marc Zyngier 

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v2 1/6] [media] s5p-jpeg: Reset the Codec before doing a soft reset

[Andrzej Pietrasiewicz]

Hi Thierry,

W dniu 12.06.2017 o 19:13, Thierry Escande pisze:

From: Abhilash Kesavan 

This patch resets the encoding and decoding register bits before doing a
soft reset.


Here are my thoughts after consulting the documentation:



Signed-off-by: Tony K Nadackal 
Signed-off-by: Thierry Escande 
---
  drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index a1d823a..9ad8f6d 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base)
unsigned int reg;
  
  	reg = readl(base + EXYNOS4_JPEG_CNTL_REG);

+   writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE),
+  base + EXYNOS4_JPEG_CNTL_REG);


Indeed, if encoding/decoding "back-to-back", the bits this patch touches
should be reset.

The doc also says, that "Soft reset is asserted to all registers
of JPEG except soft reset bit itself", so, theoretically speaking,
the changes in this patch are redundant. Instead, the doc says,
these bits have to be reset after servicing the interrupt for current image
and before programming the hardware to perform the next en/decoding.
And indeed, the first thing that both ENCODE and DECODE paths
of exynos4_jpeg_device_run() do is calling sw reset.

If, however, you can show that the changes in the patch discussed here
are in fact necessary (that's the very difference between theory and 
practise...),
I will readily ack it.

Andrzej

Re: [PATCH v3 01/11] x86/mm: Don't reenter flush_tlb_func_common()

[Thomas Gleixner]

On Tue, 20 Jun 2017, Andy Lutomirski wrote:
> Nadav noticed the reentrancy issue in a different context, but
> neither of us realized that it caused a problem yet.
> 
> Cc: Nadav Amit 
> Cc: Dave Hansen 
> Reported-by: "Levin, Alexander (Sasha Levin)" 
> Fixes: 3d28ebceaffa ("x86/mm: Rework lazy TLB to track the actual loaded mm")
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Thomas Gleixner 

Re: [PATCH v3 03/11] x86/mm: Remove reset_lazy_tlbstate()

[Thomas Gleixner]

On Tue, 20 Jun 2017, Andy Lutomirski wrote:

> The only call site also calls idle_task_exit(), and idle_task_exit()
> puts us into a clean state by explicitly switching to init_mm.
> 
> Reviewed-by: Rik van Riel 
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Thomas Gleixner 

Re: [PATCH v3 02/11] x86/ldt: Simplify LDT switching logic

[Thomas Gleixner]

On Tue, 20 Jun 2017, Andy Lutomirski wrote:
> When we redo lazy mode to stop flush IPIs without switching to
> init_mm, though, the current logic would become incorrect: it will
> be possible to have real_prev == next but nonetheless have a stale
> LDT descriptor.
> 
> Simplify the code to update LDTR if either the previous or the next
> mm has an LDT, i.e. effectively restore the historical logic..
> While we're at it, clean up the code by moving all the ifdeffery to
> a header where it belongs.
> 
> Acked-by: Rik van Riel 
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Thomas Gleixner 

Re: [PATCH v3 2/2] PCI: iproc: add device shutdown for PCI RC

[Oza Oza]

On Thu, Jun 15, 2017 at 7:11 PM, Bjorn Helgaas  wrote:
> On Wed, Jun 14, 2017 at 10:24:11AM +0530, Oza Oza wrote:
>> On Tue, Jun 13, 2017 at 5:13 AM, Bjorn Helgaas  wrote:
>> > On Sun, Jun 11, 2017 at 09:35:38AM +0530, Oza Pawandeep wrote:
>> >> PERST# must be asserted around ~500ms before
>> >> the reboot is applied.
>> >>
>> >> During soft reset (e.g., "reboot" from Linux) on some iProc based SoCs
>> >> LCPLL clock and PERST both goes off simultaneously.
>> >> This will cause certain Endpoints Intel NVMe not get detected, upon
>> >> next boot sequence.
>> >>
>> >> This happens because; Endpoint is expecting the clock for some amount of
>> >> time after PERST is asserted, which is not happening in our case
>> >> (Compare to Intel X86 boards, will have clocks running).
>> >> this cause NVMe to behave in undefined way.
>> >
>> > This doesn't smell right.  The description makes this sound like a
>> > band-aid that happens to "solve" a problem with one particular device.
>> > It doesn't sound like this is making iProc adhere to something in the
>> > PCIe spec.
>> >
>> > Is there some PCIe spec timing requirement that tells you about this
>> > 500ms number?  Please include the reference if so.
>>
>> On chip PLL which sources the reference clock to the device gets reset
>> when soft reset is applied; the soft reset also asserts PERST#.
>> This simultaneous assertion of reset and clock being lost is a problem
>> with some NVME cards.
>> The delay is added to keep clock alive while PERST gets asserted.
>> The time delay number can be set to a number that will allow the NVME
>> device to go into reset state.
>> 500 ms delay is picked for that reason only, which is long enough to
>> get EP into reset correctly.
>
> This doesn't really tell me anything new.
>
> We're talking about the protocol on the link between the RC and the
> endpoint.  That *should* be completely specified by the PCIe spec.  If
> there's some requirement that the clock keep running after PERST is
> asserted, that should be in the spec.
>
> If it's not in the spec, and an endpoint relies on it, the endpoint is
> non-compliant, and we'll likely see similar issues with that endpoint
> on other platforms.
>
> If we need a workaround for a specific endpoint, that might be OK; the
> world isn't perfect.  But if that's the case, we should include more
> specifics about the device, e.g., vendor/device IDs and "lspci -vv"
> output.
>

This is specifically happening with Intel P3700 400 gb series.
http://ark.intel.com/products/79625/Intel-SSD-DC-P3700-Series-400GB-2_5in-PCIe-3_0-20nm-MLC

but on Intel board you will not find this problem, because ref clock
is supplied by
on-board oscillator.

But our board(s) do not have clock coming from on-board,
rather it is derived from PLL coming from SOC.

Besides, PCI spec does not stipulate about such timings.
In-fact it does not tell us, whether PCIe device should consider
refclk to be available or not to be.
500 ms is just based on the observation and taken as safe margin.

So, this is partly because of the Endpoint behavior and partly due to the
way our boards are designed.

with the same SSD, we will not see this issue on x86 boards, or
even any other ARM based boards, who supplies there ref clock by
on-bard oscillator,
so in case of reboot, ref clock does not go off.

please also refer to the link below which stipulate on clk being
active after PERST being asserted.
http://www.eetimes.com/document.asp?doc_id=1279299

Product: Intel P3700 400 gb SSD
Vendor ID: 8086
Device ID: 0953.

I am sorry, but we have made replacement order of those disks, so I
dont have lspci -vv output.
but hope that above information is sufficient.

>> >> Essentially clock will remain alive for 500ms with PERST# = 0
>> >> before reboot.
>> >
>> >> This patch adds platform shutdown where it should be
>> >> called in device_shutdown while reboot command is issued.
>> >>
>> >> So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
>> >> followed by RC shutdown is called, which issues safe PERST
>> >> assertion.
>> >>
>> >> Signed-off-by: Oza Pawandeep 
>> >> Reviewed-by: Ray Jui 
>> >> Reviewed-by: Scott Branden 
>> >>
>> >> diff --git a/drivers/pci/host/pcie-iproc-platform.c 
>> >> b/drivers/pci/host/pcie-iproc-platform.c
>> >> index 90d2bdd..9512960 100644
>> >> --- a/drivers/pci/host/pcie-iproc-platform.c
>> >> +++ b/drivers/pci/host/pcie-iproc-platform.c
>> >> @@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct 
>> >> platform_device *pdev)
>> >>   return iproc_pcie_remove(pcie);
>> >>  }
>> >>
>> >> +static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)
>> >> +{
>> >> + struct iproc_pcie *pcie = platform_get_drvdata(pdev);
>> >> +
>> >> + iproc_pcie_shutdown(pcie);
>> >> +}
>> >> +
>> >>  static struct platform_driver iproc_pcie_pltfm_driver = {
>> >>   .driver = {
>> >>   .name = "iproc-pcie",
>> >> @@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct 
>> >> platfor

Re: [PATCH v3 04/11] x86/mm: Give each mm TLB flush generation a unique ID

[Thomas Gleixner]

On Tue, 20 Jun 2017, Andy Lutomirski wrote:

> This adds two new variables to mmu_context_t: ctx_id and tlb_gen.
> ctx_id uniquely identifies the mm_struct and will never be reused.
> For a given mm_struct (and hence ctx_id), tlb_gen is a monotonic
> count of the number of times that a TLB flush has been requested.
> The pair (ctx_id, tlb_gen) can be used as an identifier for TLB
> flush actions and will be used in subsequent patches to reliably
> determine whether all needed TLB flushes have occurred on a given
> CPU.
> 
> This patch is split out for ease of review.  By itself, it has no
> real effect other than creating and updating the new variables.

Thanks for splitting this apart!

> 
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Thomas Gleixner 

Re: [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Michel Dänzer]

On 21/06/17 04:38 PM, Daniel Vetter wrote:
> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
>> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
>> totally obsolete.
>>
>> I think the gamma_store can end up invalid on error. But the way I read
>> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
>> this pesky legacy fbdev stuff be any better?
>>
>> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
>> it saves it to the gamma_store which should already be up to date with what
>> .gamma_get would return and is thus a nop. So, zap it.
> 
> Removing drm_fb_helper_save_lut_atomic should be a separate patch I
> think.
>  
>> Signed-off-by: Peter Rosin 

[...]

>> @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct 
>> drm_fb_helper *fb_helper,
>>  }
>>  EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>>  
>> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>> - u16 blue, u16 regno, struct fb_info *info)
>> -{
>> -struct drm_fb_helper *fb_helper = info->par;
>> -struct drm_framebuffer *fb = fb_helper->fb;
>> -
>> -if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> 
> This case here seems gone, and it was also the pièce de résistance when I
> tried tackling fbdev lut support. As far as I understand this stuff we do
> not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
> pointless. But I'm honestly not really clear.
> 
> I think removing this case should also be a separate patch, and I'd very
> much prefer that someone with some fbdev-clue would ack it.

No need for anyone with fbdev-clue, just run fbset -i. :) fbcon uses a
TRUECOLOR visual at depths > 8.


> It's a pre-existing bug, but should we also try to restore the fbdev lut
> in drm_fb_helper_restore_fbdev_mode_unlocked()? Would be yet another bug,
> but might be relevant for your use-case. Just try to run both an fbdev
> application and some kms-native thing, and then SIGKILL the native kms
> app.
> 
> But since pre-existing not really required, and probably too much effort.

I suspect something like that indeed needs to be done though. E.g.
killing Xorg results in fbcon continuing to use the LUT set by Xorg.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH V4 0/2] Add support for OCC command/response interface

[Shilpasri G Bhat]

In P9, OCC(On Chip Controller) can be sent commands inband via shared
memory based command response interface.  This patch adds a platform
driver to support the OCC command-response interface.

The skiboot patch for the interface is posted here:
https://lists.ozlabs.org/pipermail/skiboot/2017-June/007705.html

Shilpasri G Bhat (2):
  powerpc/powernv: Get a unique token for async completions
  powerpc/powernv : Add support for OPAL-OCC command/response interface

 arch/powerpc/include/asm/opal-api.h|  41 +++-
 arch/powerpc/include/asm/opal.h|   4 +
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-async.c|  46 
 arch/powerpc/platforms/powernv/opal-occ.c  | 313 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   8 +
 7 files changed, 413 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c

-- 
1.8.3.1

[PATCH V4 1/2] powerpc/powernv: Get a unique token for async completions

[Shilpasri G Bhat]

This patch adds support to get a unique token for async completion
requests. This will be used for creating non-repititive request
handles for consecutive requests in OPAL-OCC command/response
interface.

Signed-off-by: Shilpasri G Bhat 
---
- No changes from V3

 arch/powerpc/include/asm/opal.h |  1 +
 arch/powerpc/platforms/powernv/opal-async.c | 46 +
 2 files changed, 47 insertions(+)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 588fb1c..03ed493 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -293,6 +293,7 @@ extern int opal_message_notifier_unregister(enum 
opal_msg_type msg_type,
 
 extern int __opal_async_get_token(void);
 extern int opal_async_get_token_interruptible(void);
+extern int opal_async_get_unique_token_interruptible(int last_token);
 extern int __opal_async_release_token(int token);
 extern int opal_async_release_token(int token);
 extern int opal_async_wait_response(uint64_t token, struct opal_msg *msg);
diff --git a/arch/powerpc/platforms/powernv/opal-async.c 
b/arch/powerpc/platforms/powernv/opal-async.c
index 83bebee..8caeea2 100644
--- a/arch/powerpc/platforms/powernv/opal-async.c
+++ b/arch/powerpc/platforms/powernv/opal-async.c
@@ -73,6 +73,52 @@ int opal_async_get_token_interruptible(void)
 }
 EXPORT_SYMBOL_GPL(opal_async_get_token_interruptible);
 
+static int __opal_async_get_new_token(int last_token)
+{
+   unsigned long flags;
+   int token;
+
+   spin_lock_irqsave(&opal_async_comp_lock, flags);
+   token = find_next_bit(opal_async_complete_map, opal_max_async_tokens,
+ last_token + 1);
+   if (token >= opal_max_async_tokens) {
+   token = find_first_bit(opal_async_complete_map,
+  opal_max_async_tokens);
+   if (token >= opal_max_async_tokens || token == last_token) {
+   token = -EBUSY;
+   goto out;
+   }
+   }
+
+   pr_debug("%s token = %d\n", __func__, token);
+   if (__test_and_set_bit(token, opal_async_token_map)) {
+   token = -EBUSY;
+   goto out;
+   }
+
+   __clear_bit(token, opal_async_complete_map);
+
+out:
+   spin_unlock_irqrestore(&opal_async_comp_lock, flags);
+   return token;
+}
+
+int opal_async_get_unique_token_interruptible(int last_token)
+{
+   int token;
+
+   /* Wait until a token is available */
+   if (down_interruptible(&opal_async_sem))
+   return -ERESTARTSYS;
+
+   token = __opal_async_get_new_token(last_token);
+   if (token < 0)
+   up(&opal_async_sem);
+
+   return token;
+}
+EXPORT_SYMBOL_GPL(opal_async_get_unique_token_interruptible);
+
 int __opal_async_release_token(int token)
 {
unsigned long flags;
-- 
1.8.3.1

[PATCH V4 2/2] powerpc/powernv : Add support for OPAL-OCC command/response interface

[Shilpasri G Bhat]

In P9, OCC (On-Chip-Controller) supports shared memory based
commad-response interface. Within the shared memory there is an OPAL
command buffer and OCC response buffer that can be used to send
inband commands to OCC. This patch adds a platform driver to support
the command/response interface between OCC and the host.

Signed-off-by: Shilpasri G Bhat 
---
- Hold occ->cmd_in_progress in read()
- Reset occ->rsp_consumed if copy_to_user() fails

 arch/powerpc/include/asm/opal-api.h|  41 +++-
 arch/powerpc/include/asm/opal.h|   3 +
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-occ.c  | 313 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   8 +
 6 files changed, 366 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index cb3e624..011d86c 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -42,6 +42,10 @@
 #define OPAL_I2C_STOP_ERR  -24
 #define OPAL_XIVE_PROVISIONING -31
 #define OPAL_XIVE_FREE_ACTIVE  -32
+#define OPAL_OCC_INVALID_STATE -33
+#define OPAL_OCC_BUSY  -34
+#define OPAL_OCC_CMD_TIMEOUT   -35
+#define OPAL_OCC_RSP_MISMATCH  -36
 
 /* API Tokens (in r0) */
 #define OPAL_INVALID_CALL -1
@@ -190,7 +194,8 @@
 #define OPAL_NPU_INIT_CONTEXT  146
 #define OPAL_NPU_DESTROY_CONTEXT   147
 #define OPAL_NPU_MAP_LPAR  148
-#define OPAL_LAST  148
+#define OPAL_OCC_COMMAND   149
+#define OPAL_LAST  149
 
 /* Device tree flags */
 
@@ -829,6 +834,40 @@ struct opal_prd_msg_header {
 
 struct opal_prd_msg;
 
+enum occ_cmd {
+   OCC_CMD_AMESTER_PASS_THRU = 0,
+   OCC_CMD_CLEAR_SENSOR_DATA,
+   OCC_CMD_SET_POWER_CAP,
+   OCC_CMD_SET_POWER_SHIFTING_RATIO,
+   OCC_CMD_SELECT_SENSOR_GROUPS,
+   OCC_CMD_LAST
+};
+
+struct opal_occ_cmd_rsp_msg {
+   __be64 cdata;
+   __be64 rdata;
+   __be16 cdata_size;
+   __be16 rdata_size;
+   u8 cmd;
+   u8 request_id;
+   u8 status;
+};
+
+struct opal_occ_cmd_data {
+   __be16 size;
+   u8 cmd;
+   u8 data[];
+};
+
+struct opal_occ_rsp_data {
+   __be16 size;
+   u8 status;
+   u8 data[];
+};
+
+#define MAX_OPAL_CMD_DATA_LENGTH4090
+#define MAX_OCC_RSP_DATA_LENGTH 8698
+
 #define OCC_RESET   0
 #define OCC_LOAD1
 #define OCC_THROTTLE2
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 03ed493..e55ed79 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -346,6 +346,9 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 
 void opal_wake_poller(void);
 
+int64_t opal_occ_command(int chip_id, struct opal_occ_cmd_rsp_msg *msg,
+bool retry);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index b5d98cb..f5f0902 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o
+obj-y  += opal-kmsg.o opal-occ.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-occ.c 
b/arch/powerpc/platforms/powernv/opal-occ.c
new file mode 100644
index 000..b346724
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-occ.c
@@ -0,0 +1,313 @@
+/*
+ * Copyright IBM Corporation 2017
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) "opal-occ: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct occ {
+   struct miscdevice dev;
+   struct opal_occ_rsp_data *rsp;
+   atomic_t session;
+   atomic_t cmd_in_progress;
+   atomic_t rsp_consumed;
+   int id;

[PATCH RESEND 4/7] [media] cx25821: use MEDIA_REVISION instead of KERNEL_VERSION

[Johannes Thumshirn]

Use MEDIA_REVISION instead of KERNEL_VERSION to encode the
CX25821_VERSION_CODE.

Signed-off-by: Johannes Thumshirn 
---
 drivers/media/pci/cx25821/cx25821.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/cx25821/cx25821.h 
b/drivers/media/pci/cx25821/cx25821.h
index 0f20e89b0cde..7fea6b07cf19 100644
--- a/drivers/media/pci/cx25821/cx25821.h
+++ b/drivers/media/pci/cx25821/cx25821.h
@@ -41,7 +41,7 @@
 #include 
 #include 
 
-#define CX25821_VERSION_CODE KERNEL_VERSION(0, 0, 106)
+#define CX25821_VERSION_CODE MEDIA_REVISION(0, 0, 106)
 
 #define UNSET (-1U)
 #define NO_SYNC_LINE (-1U)
-- 
2.12.3

[PATCH RESEND 1/7] [media] media: introduce MEDIA_REVISION macro

[Johannes Thumshirn]

Currently the media code abuses the KERNEL_VERSION macro to encode a
version triplet.

Introduce a MEDIA_REVISION macro to get rid of the confusing and
creative KERNEL_VERSION usage in the media subsystem.

Signed-off-by: Johannes Thumshirn 
---
 include/uapi/linux/media.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4890787731b8..25e2ae4432bd 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -30,7 +30,9 @@
 #include 
 #include 
 
-#define MEDIA_API_VERSION  KERNEL_VERSION(0, 1, 0)
+#define MEDIA_REVISION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
+
+#define MEDIA_API_VERSION  MEDIA_REVISION(0, 1, 0)
 
 struct media_device_info {
char driver[16];
-- 
2.12.3

[PATCH RESEND 0/7] Introduce MEDIA_VERSION to end KENREL_VERSION abuse in media

[Johannes Thumshirn]

Currently the media subsystem has a very creative abuse of the
KERNEL_VERSION macro to encode an arbitrary version triplet for media
drivers and device hardware revisions.

This series introduces a new macro called MEDIA_REVISION which encodes
a version triplet like KERNEL_VERSION does, but clearly has media
centric semantics and doesn't fool someone into thinking specific
parts are defined for a specific kernel version only like in out of
tree drivers.

Johannes Thumshirn (7):
  [media] media: introduce MEDIA_REVISION macro
  video: fbdev: don't use KERNEL_VERSION macro for MEDIA_REVISION
  [media] media: document the use of MEDIA_REVISION instead of
KERNEL_VERSION
  [media] cx25821: use MEDIA_REVISION instead of KERNEL_VERSION
  [media] media: s3c-camif: Use MEDIA_REVISON instead of KERNEL_VERSION
  [media] media: bcm2048: use MEDIA_REVISION isntead of KERNEL_VERSION
  staging/atomisp: use MEDIA_VERSION instead of KERNEL_VERSION

 Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst| 2 +-
 Documentation/media/uapi/mediactl/media-ioc-device-info.rst | 4 ++--
 Documentation/media/uapi/v4l/vidioc-querycap.rst| 6 +++---
 drivers/media/pci/cx25821/cx25821.h | 2 +-
 drivers/media/platform/s3c-camif/camif-core.c   | 2 +-
 drivers/staging/media/atomisp/include/linux/atomisp.h   | 6 +++---
 drivers/staging/media/bcm2048/radio-bcm2048.c   | 2 +-
 drivers/video/fbdev/matrox/matroxfb_base.c  | 3 ++-
 include/media/media-device.h| 5 ++---
 include/uapi/linux/media.h  | 4 +++-
 10 files changed, 19 insertions(+), 17 deletions(-)

-- 
2.12.3

[PATCH RESEND 6/7] [media] media: bcm2048: use MEDIA_REVISION isntead of KERNEL_VERSION

[Johannes Thumshirn]

Use MEDIA_REVISION isntead of KERNEL_VERSION to encode the bcm2048
driver version.

Signed-off-by: Johannes Thumshirn 
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 38f72d069e27..ffe9b63cbf59 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -48,7 +48,7 @@
 /* driver definitions */
 #define BCM2048_DRIVER_AUTHOR  "Eero Nurkkala "
 #define BCM2048_DRIVER_NAMEBCM2048_NAME
-#define BCM2048_DRIVER_VERSION KERNEL_VERSION(0, 0, 1)
+#define BCM2048_DRIVER_VERSION MEDIA_REVISION(0, 0, 1)
 #define BCM2048_DRIVER_CARD"Broadcom bcm2048 FM Radio Receiver"
 #define BCM2048_DRIVER_DESC"I2C driver for BCM2048 FM Radio Receiver"
 
-- 
2.12.3

linux-next: Tree for Jun 21

[Stephen Rothwell]

Hi all,

Changes since 20170620:

New tree: dma-mapping-hch

The file-locks tree gained a conflict against the uuid tree.

The v4l-dvb tree gained a build failure so I used the version from
next-20170620.

The net-next tree gained conflicts against the net and pci trees.

The spi-nor tree gained a build failure so I used the version from
next-20170620.

The block tree gained conflicts against the btrfs-kdave, file-locks and
pci trees.

The tip tree gained a conflict against the jc_docs tree.

The scsi tree gained a conflict against the block tree.

The gpio tree gained a build failure so I used the version from
next-20170620.

The kspp tree gained a conflict against the file-locks tree.

Non-merge commits (relative to Linus' tree): 8130
 8021 files changed, 641386 insertions(+), 160016 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (9705596d08ac Merge tag 'clk-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (ff85a1a80e00 kconfig: Check for libncurses before 
menuconfig)
Merging arc-current/for-curr (45c7d002f207 ARC: defconfig: Cleanup from old 
Kconfig options)
Merging arm-current/fixes (d360a687d995 ARM: 8682/1: V7M: Set cacheid iff 
DminLine or IminLine is nonzero)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (bf05fc25f268 powerpc/perf: Fix oops when kthread 
execs user process)
Merging sparc/master (d8f431a0de40 Merge branch 
'sparc-Suppressing-version-generation-failed-warnings-in-sparc')
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (b4846fc3c855 igmp: add a missing spin_lock_init())
Merging ipsec/master (e747f64336fc xfrm: NULL dereference on allocation failure)
Merging netfilter/master (4b1f0d33db7d net: ipmr: Fix some mroute forwarding 
issues in vrf's)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (4b153ca989a9 Merge tag 'mac80211-for-davem-2017-06-16' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (c7ecb9068e67 ALSA: hda - Apply quirks to 
Broxton-T, too)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (3c2993b8c614 Linux 4.12-rc4)
Merging usb.current/usb-linus (dec08194ffec xhci: Limit USB2 port wake support 
for AMD Promontory hosts)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: f

[PATCH RESEND 5/7] [media] media: s3c-camif: Use MEDIA_REVISON instead of KERNEL_VERSION

[Johannes Thumshirn]

Use MEDIA_REVISON instead of KERNEL_VERSION to encode the driver
version.

Signed-off-by: Johannes Thumshirn 
---
 drivers/media/platform/s3c-camif/camif-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s3c-camif/camif-core.c 
b/drivers/media/platform/s3c-camif/camif-core.c
index ec4001970313..98bd5719fdf5 100644
--- a/drivers/media/platform/s3c-camif/camif-core.c
+++ b/drivers/media/platform/s3c-camif/camif-core.c
@@ -317,7 +317,7 @@ static int camif_media_dev_init(struct camif_dev *camif)
 ip_rev == S3C6410_CAMIF_IP_REV ? "6410" : "244X");
strlcpy(md->bus_info, "platform", sizeof(md->bus_info));
md->hw_revision = ip_rev;
-   md->driver_version = KERNEL_VERSION(1, 0, 0);
+   md->driver_version = MEDIA_REVISION(1, 0, 0);
 
md->dev = camif->dev;
 
-- 
2.12.3

[PATCH RESEND 7/7] staging/atomisp: use MEDIA_VERSION instead of KERNEL_VERSION

[Johannes Thumshirn]

Use MEDIA_VERSION instead of KERNEL_VERSION to encode the driver
version of the Atom ISP driver.

Signed-off-by: Johannes Thumshirn 
---
 drivers/staging/media/atomisp/include/linux/atomisp.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/atomisp/include/linux/atomisp.h 
b/drivers/staging/media/atomisp/include/linux/atomisp.h
index 35865462ccf9..0b664ee6f825 100644
--- a/drivers/staging/media/atomisp/include/linux/atomisp.h
+++ b/drivers/staging/media/atomisp/include/linux/atomisp.h
@@ -30,9 +30,9 @@
 
 /* struct media_device_info.driver_version */
 #define ATOMISP_CSS_VERSION_MASK   0x00ff
-#define ATOMISP_CSS_VERSION_15 KERNEL_VERSION(1, 5, 0)
-#define ATOMISP_CSS_VERSION_20 KERNEL_VERSION(2, 0, 0)
-#define ATOMISP_CSS_VERSION_21 KERNEL_VERSION(2, 1, 0)
+#define ATOMISP_CSS_VERSION_15 MEDIA_REVISION(1, 5, 0)
+#define ATOMISP_CSS_VERSION_20 MEDIA_REVISION(2, 0, 0)
+#define ATOMISP_CSS_VERSION_21 MEDIA_REVISION(2, 1, 0)
 
 /* struct media_device_info.hw_revision */
 #define ATOMISP_HW_REVISION_MASK   0xff00
-- 
2.12.3

Re: [PATCH v2 1/2] DT: pinctrl: Add binding documentation for Spreadtrum pin controller

[Baolin Wang]

On 20 June 2017 at 17:31, Linus Walleij  wrote:
> On Tue, Jun 13, 2017 at 5:15 AM, Baolin Wang  
> wrote:
>
>> I forgot one most important reason why we can not use the "sleep" state. As 
>> I explained
>> above, the sleep related configuration will bind with the pin's sleep mode. 
>> If we set the
>> pin's sleep mode as AP_SLEEP, then we can select "sleep" state when AP 
>> system goes into
>> deep sleep mode by issuing "pinctrl_force_sleep()" in pinctrl suspend 
>> function.
>>
>> But if we set the pin's sleep mode as PUBCP_SLEEP and pubcp system doesn't 
>> run linux kernel
>> (it run another thread OS), then we can not select "sleep" state since the 
>> AP system does
>> not go into deep sleep mode (AP system run linux kernel OS).
>
> Allright yes it makes sense, and also there are systems that just go into
> "hardware sleep" and just put the pin into some pre-programmed mode.
>
> I'm a bit back-and-forth. I didn't mean that some code would actually
> switch the state to "sleep" when we go to sleep, I meant that when
> the system configures "default" mode it should also look up and
> program the "sleep" mode, but this approach with a special property
> is just another way of achieveing the same thing.
>
> But then we should add a whole slew of sleep states.
>
> I was thinking whether we could avoid having a special DT property
> by parsing ahead to states we do not currently use and programming
> that into the sleep mode registers.

Yes, for most scenarios, it can work with the "sleep" state to set
sleep-related config. But for our Spreadtrum platform scenario (I do
not know if there are other platforms need this feature), we can not
select the "sleep" state when pubcp system goes into deep sleep mode
but ap system does not go into deep sleep mode. So I think we still
need these "sleep-bias-pull-up", "sleep-bias-pull-down",
"sleep-input-enable" and "sleep-output-enable" properties.

-- 
Baolin.wang
Best Regards

Re: [Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

[Andrew Cooper]

On 20/06/2017 21:14, Daniel Kiper wrote:
> Current approach, wholesale efi struct initialization from efi_xen, is not
> good. Usually if new member is defined then it is properly initialized in
> drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it happened
> a few times until now. So, let's initialize only efi struct members used by
> Xen to avoid such issues in the future.
>
> Signed-off-by: Daniel Kiper 
> ---
>  arch/x86/xen/efi.c |   45 -
>  1 file changed, 12 insertions(+), 33 deletions(-)
>
> diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
> index 30bb2e8..01b9faf 100644
> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -54,38 +54,6 @@
>   .tables = EFI_INVALID_TABLE_ADDR  /* Initialized later. */
>  };
>  
> -static const struct efi efi_xen __initconst = {
> - .systab   = NULL, /* Initialized later. */
> - .runtime_version  = 0,/* Initialized later. */
> - .mps  = EFI_INVALID_TABLE_ADDR,
> - .acpi = EFI_INVALID_TABLE_ADDR,
> - .acpi20   = EFI_INVALID_TABLE_ADDR,
> - .smbios   = EFI_INVALID_TABLE_ADDR,
> - .smbios3  = EFI_INVALID_TABLE_ADDR,
> - .sal_systab   = EFI_INVALID_TABLE_ADDR,
> - .boot_info= EFI_INVALID_TABLE_ADDR,
> - .hcdp = EFI_INVALID_TABLE_ADDR,
> - .uga  = EFI_INVALID_TABLE_ADDR,
> - .uv_systab= EFI_INVALID_TABLE_ADDR,
> - .fw_vendor= EFI_INVALID_TABLE_ADDR,
> - .runtime  = EFI_INVALID_TABLE_ADDR,
> - .config_table = EFI_INVALID_TABLE_ADDR,
> - .get_time = xen_efi_get_time,
> - .set_time = xen_efi_set_time,
> - .get_wakeup_time  = xen_efi_get_wakeup_time,
> - .set_wakeup_time  = xen_efi_set_wakeup_time,
> - .get_variable = xen_efi_get_variable,
> - .get_next_variable= xen_efi_get_next_variable,
> - .set_variable = xen_efi_set_variable,
> - .query_variable_info  = xen_efi_query_variable_info,
> - .update_capsule   = xen_efi_update_capsule,
> - .query_capsule_caps   = xen_efi_query_capsule_caps,
> - .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
> - .reset_system = xen_efi_reset_system,
> - .set_virtual_address_map  = NULL, /* Not used under Xen. */
> - .flags= 0 /* Initialized later. */
> -};
> -
>  static efi_system_table_t __init *xen_efi_probe(void)
>  {
>   struct xen_platform_op op = {
> @@ -102,7 +70,18 @@ static efi_system_table_t __init *xen_efi_probe(void)
>  
>   /* Here we know that Xen runs on EFI platform. */
>  
> - efi = efi_xen;
> + efi.get_time = xen_efi_get_time;
> + efi.set_time = xen_efi_set_time;
> + efi.get_wakeup_time = xen_efi_get_wakeup_time;
> + efi.set_wakeup_time = xen_efi_set_wakeup_time;
> + efi.get_variable = xen_efi_get_variable;
> + efi.get_next_variable = xen_efi_get_next_variable;
> + efi.set_variable = xen_efi_set_variable;
> + efi.query_variable_info = xen_efi_query_variable_info;
> + efi.update_capsule = xen_efi_update_capsule;
> + efi.query_capsule_caps = xen_efi_query_capsule_caps;
> + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
> + efi.reset_system = xen_efi_reset_system;

This presumably means that the system default values are already present
in efi at the point that we overwrite some Xen specifics?

If so, surely you need to retain the clobbering of set_virtual_address_map ?

~Andrew

[PATCH RESEND 0/4] mediatek: pwm driver add MT2712/MT7622 support

[Zhi Mao]

pwm driver add MT2712/MT7622 support, fix clock control issue.
dtsi file will be upload latter, after the clock define is ready.

Zhi Mao (4):
  pwm: kconfig: modify mediatek information
  pwm: mediatek: fix clk issue
  pwm: bindings: add MT2712/MT7622 information
  pwm: mediatek: add MT2712/MT7622 support

 .../devicetree/bindings/pwm/pwm-mediatek.txt   |6 +-
 drivers/pwm/Kconfig|2 +-
 drivers/pwm/pwm-mediatek.c |  132 ++--
 3 files changed, 100 insertions(+), 40 deletions(-)

[PATCH RESEND 3/4] pwm: bindings: add MT2712/MT7622 information

[Zhi Mao]

add MT2712/MT7622 pwm information

Signed-off-by: Zhi Mao 
---
 .../devicetree/bindings/pwm/pwm-mediatek.txt   |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt 
b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index 54c59b0..ef8bd3c 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -2,6 +2,8 @@ MediaTek PWM controller
 
 Required properties:
  - compatible: should be "mediatek,-pwm":
+   - "mediatek,mt2712-pwm": found on mt2712 SoC.
+   - "mediatek,mt7622-pwm": found on mt7622 SoC.
- "mediatek,mt7623-pwm": found on mt7623 SoC.
  - reg: physical base address and length of the controller's registers.
  - #pwm-cells: must be 2. See pwm.txt in this directory for a description of
@@ -10,7 +12,9 @@ Required properties:
  - clock-names: must contain the following:
- "top": the top clock generator
- "main": clock used by the PWM core
-   - "pwm1-5": the five per PWM clocks
+   - "pwm1-8": the eight per PWM clocks for mt2712
+   - "pwm1-6": the six per PWM clocks for mt7622
+   - "pwm1-5": the five per PWM clocks for mt7623
  - pinctrl-names: Must contain a "default" entry.
  - pinctrl-0: One property must exist for each entry in pinctrl-names.
See pinctrl/pinctrl-bindings.txt for details of the property values.
-- 
1.7.9.5

[PATCH RESEND 4/4] pwm: mediatek: add MT2712/MT7622 support

[Zhi Mao]

support multiple chip(MT2712, MT7622, MT7623)

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |   63 +++-
 1 file changed, 51 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index c803ff6..d520356 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,8 @@
 #define PWMDWIDTH  0x2c
 #define PWMTHRES   0x30
 
+#define PWM_CLK_DIV_MAX7
+
 enum {
MTK_CLK_MAIN = 0,
MTK_CLK_TOP,
@@ -38,11 +41,19 @@ enum {
MTK_CLK_PWM3,
MTK_CLK_PWM4,
MTK_CLK_PWM5,
+   MTK_CLK_PWM6,
+   MTK_CLK_PWM7,
+   MTK_CLK_PWM8,
MTK_CLK_MAX,
 };
 
-static const char * const mtk_pwm_clk_name[] = {
-   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5"
+static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
+   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4",
+   "pwm5", "pwm6", "pwm7", "pwm8"
+};
+
+struct mtk_com_pwm_data {
+   unsigned int pwm_nums;
 };
 
 /**
@@ -55,6 +66,11 @@ struct mtk_pwm_chip {
struct pwm_chip chip;
void __iomem *regs;
struct clk *clks[MTK_CLK_MAX];
+   const struct mtk_com_pwm_data *data;
+};
+
+static const unsigned long mtk_pwm_com_reg[] = {
+   0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
 };
 
 static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct pwm_chip *chip)
@@ -99,14 +115,14 @@ static void mtk_pwm_clk_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
 static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
unsigned int offset)
 {
-   return readl(chip->regs + 0x10 + (num * 0x40) + offset);
+   return readl(chip->regs + mtk_pwm_com_reg[num] + offset);
 }
 
 static inline void mtk_pwm_writel(struct mtk_pwm_chip *chip,
  unsigned int num, unsigned int offset,
  u32 value)
 {
-   writel(value, chip->regs + 0x10 + (num * 0x40) + offset);
+   writel(value, chip->regs + mtk_pwm_com_reg[num] + offset);
 }
 
 static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -125,8 +141,10 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
clkdiv++;
}
 
-   if (clkdiv > 7)
+   if (clkdiv > PWM_CLK_DIV_MAX) {
+   dev_err(chip->dev, "period %d not supported\n", period_ns);
return -EINVAL;
+   }
 
mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
@@ -181,23 +199,28 @@ static int mtk_pwm_probe(struct platform_device *pdev)
if (!pc)
return -ENOMEM;
 
+   pc->data = of_device_get_match_data(&pdev->dev);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pc->regs = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(pc->regs))
return PTR_ERR(pc->regs);
 
-   for (i = 0; i < MTK_CLK_MAX; i++) {
+   for (i = 0; i < pc->data->pwm_nums + 2; i++) {
pc->clks[i] = devm_clk_get(&pdev->dev, mtk_pwm_clk_name[i]);
-   if (IS_ERR(pc->clks[i]))
+   if (IS_ERR(pc->clks[i])) {
+   dev_err(&pdev->dev, "[PWM] clock: %s fail: %ld\n",
+   mtk_pwm_clk_name[i], PTR_ERR(pc->clks[i]));
return PTR_ERR(pc->clks[i]);
+   }
}
 
-   platform_set_drvdata(pdev, pc);
-
pc->chip.dev = &pdev->dev;
pc->chip.ops = &mtk_pwm_ops;
pc->chip.base = -1;
-   pc->chip.npwm = 5;
+   pc->chip.npwm = pc->data->pwm_nums;
+
+   platform_set_drvdata(pdev, pc);
 
ret = pwmchip_add(&pc->chip);
if (ret < 0) {
@@ -215,9 +238,25 @@ static int mtk_pwm_remove(struct platform_device *pdev)
return pwmchip_remove(&pc->chip);
 }
 
+/*==*/
+static const struct mtk_com_pwm_data mt2712_pwm_data = {
+   .pwm_nums = 8,
+};
+
+static const struct mtk_com_pwm_data mt7622_pwm_data = {
+   .pwm_nums = 6,
+};
+
+static const struct mtk_com_pwm_data mt7623_pwm_data = {
+   .pwm_nums = 5,
+};
+/*==*/
+
 static const struct of_device_id mtk_pwm_of_match[] = {
-   { .compatible = "mediatek,mt7623-pwm" },
-   { }
+   {.compatible = "mediatek,mt2712-pwm", .data = &mt2712_pwm_data},
+   {.compatible = "mediatek,mt7622-pwm", .data = &mt7622_pwm_data},
+   {.compatible = "mediatek,mt7623-pwm", .data = &mt7623_pwm_data},
+   {},
 };
 MODULE_DEVICE_TABLE(of, mtk_pwm_of_match);
 
-- 
1.7.9.5

[PATCH RESEND 1/4] pwm: kconfig: modify mediatek information

[Zhi Mao]

modify mediatek information

Signed-off-by: Zhi Mao 
---
 drivers/pwm/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 313c107..45cdf2a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -300,7 +300,7 @@ config PWM_MEDIATEK
  Generic PWM framework driver for Mediatek ARM SoC.
 
  To compile this driver as a module, choose M here: the module
- will be called pwm-mxs.
+ will be called pwm-mediatek.
 
 config PWM_MXS
tristate "Freescale MXS PWM support"
-- 
1.7.9.5

[PATCH RESEND 2/4] pwm: mediatek: fix clk issue

[Zhi Mao]

1.fix clock control
 - prepare top/main clk in mtk_pwm_probe() function,
   it will increase power consumption
   and in original code these clocks is only prepeare but never enabled
 - pwm clock should be enabled before setting pwm registers
   in function: mtk_pwm_config()

2.fix pwm source clock selection
 - in original code, the pwm output frequency is not correct
   when set bit<3>=1 to PWMCON register.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |   69 +++-
 1 file changed, 43 insertions(+), 26 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 5c11bc7..c803ff6 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -2,6 +2,7 @@
  * Mediatek Pulse Width Modulator driver
  *
  * Copyright (C) 2015 John Crispin 
+ * Copyright (C) 2017 Zhi Mao 
  *
  * This file is licensed under the terms of the GNU General Public
  * License version 2. This program is licensed "as is" without any
@@ -61,6 +62,40 @@ static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct 
pwm_chip *chip)
return container_of(chip, struct mtk_pwm_chip, chip);
 }
 
+static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+   struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+   int ret = 0;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
+   if (ret < 0)
+   return ret;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_MAIN]);
+   if (ret < 0) {
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   if (ret < 0) {
+   clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+   return ret;
+   }
+
+   return ret;
+}
+
+static void mtk_pwm_clk_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+   struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+
+   clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+}
+
 static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
unsigned int offset)
 {
@@ -81,6 +116,8 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
u32 resolution, clkdiv = 0;
 
+   mtk_pwm_clk_enable(chip, pwm);
+
resolution = NSEC_PER_SEC / clk_get_rate(clk);
 
while (period_ns / resolution > 8191) {
@@ -91,10 +128,12 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (clkdiv > 7)
return -EINVAL;
 
-   mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | BIT(3) | clkdiv);
+   mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
 
+   mtk_pwm_clk_disable(chip, pwm);
+
return 0;
 }
 
@@ -102,11 +141,8 @@ static int mtk_pwm_enable(struct pwm_chip *chip, struct 
pwm_device *pwm)
 {
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
u32 value;
-   int ret;
 
-   ret = clk_prepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
-   if (ret < 0)
-   return ret;
+   mtk_pwm_clk_enable(chip, pwm);
 
value = readl(pc->regs);
value |= BIT(pwm->hwpwm);
@@ -124,7 +160,7 @@ static void mtk_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
value &= ~BIT(pwm->hwpwm);
writel(value, pc->regs);
 
-   clk_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   mtk_pwm_clk_disable(chip, pwm);
 }
 
 static const struct pwm_ops mtk_pwm_ops = {
@@ -156,14 +192,6 @@ static int mtk_pwm_probe(struct platform_device *pdev)
return PTR_ERR(pc->clks[i]);
}
 
-   ret = clk_prepare(pc->clks[MTK_CLK_TOP]);
-   if (ret < 0)
-   return ret;
-
-   ret = clk_prepare(pc->clks[MTK_CLK_MAIN]);
-   if (ret < 0)
-   goto disable_clk_top;
-
platform_set_drvdata(pdev, pc);
 
pc->chip.dev = &pdev->dev;
@@ -174,26 +202,15 @@ static int mtk_pwm_probe(struct platform_device *pdev)
ret = pwmchip_add(&pc->chip);
if (ret < 0) {
dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
-   goto disable_clk_main;
+   return ret;
}
 
return 0;
-
-disable_clk_main:
-   clk_unprepare(pc->clks[MTK_CLK_MAIN]);
-disable_clk_top:
-   clk_unprepare(pc->clks[MTK_CLK_TOP]);
-
-   return ret;
 }
 
 static int mtk_pwm_remove(struct platform_device *pdev)
 {
struct mtk_pwm_chip *pc = platform_get_drvdata(pdev);
-   unsigned int i;
-
-   for 

[PATCH RESEND 2/7] video: fbdev: don't use KERNEL_VERSION macro for MEDIA_REVISION

[Johannes Thumshirn]

Don't use the KERNEL_VERSION() macro for the v4l2 capabilities, use
MEDIA_REVISION instead.

Signed-off-by: Johannes Thumshirn 
---
 drivers/video/fbdev/matrox/matroxfb_base.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c 
b/drivers/video/fbdev/matrox/matroxfb_base.c
index 11eb094396ae..eb92a325033c 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -113,6 +113,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_PPC_PMAC
 #include 
@@ -1091,7 +1092,7 @@ static int matroxfb_ioctl(struct fb_info *info,
strcpy(r.driver, "matroxfb");
strcpy(r.card, "Matrox");
sprintf(r.bus_info, "PCI:%s", 
pci_name(minfo->pcidev));
-   r.version = KERNEL_VERSION(1,0,0);
+   r.version = MEDIA_REVISION(1, 0, 0);
r.capabilities = V4L2_CAP_VIDEO_OUTPUT;
if (copy_to_user(argp, &r, sizeof(r)))
return -EFAULT;
-- 
2.12.3

[PATCH RESEND 3/7] [media] media: document the use of MEDIA_REVISION instead of KERNEL_VERSION

[Johannes Thumshirn]

Update the documentation to introduce the use of MEDIA_REVISON instead
of KERNEL_VERSION for the verison triplets of a media drivers hardware
revision or driver version.

Signed-off-by: Johannes Thumshirn 
---
 Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst| 2 +-
 Documentation/media/uapi/mediactl/media-ioc-device-info.rst | 4 ++--
 Documentation/media/uapi/v4l/vidioc-querycap.rst| 6 +++---
 include/media/media-device.h| 5 ++---
 4 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
index a0e961f11017..749054f11c77 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
@@ -56,7 +56,7 @@ returns the information to the application. The ioctl never 
fails.
:ref:`cec-capabilities`.
 * - __u32
   - ``version``
-  - CEC Framework API version, formatted with the ``KERNEL_VERSION()``
+  - CEC Framework API version, formatted with the ``MEDIA_REVISION()``
macro.
 
 
diff --git a/Documentation/media/uapi/mediactl/media-ioc-device-info.rst 
b/Documentation/media/uapi/mediactl/media-ioc-device-info.rst
index f690f9afc470..7a18cb6dbe84 100644
--- a/Documentation/media/uapi/mediactl/media-ioc-device-info.rst
+++ b/Documentation/media/uapi/mediactl/media-ioc-device-info.rst
@@ -96,7 +96,7 @@ ioctl never fails.
 
-  ``media_version``
 
-   -  Media API version, formatted with the ``KERNEL_VERSION()`` macro.
+   -  Media API version, formatted with the ``MEDIA_REVISION()`` macro.
 
 -  .. row 6
 
@@ -113,7 +113,7 @@ ioctl never fails.
-  ``driver_version``
 
-  Media device driver version, formatted with the
- ``KERNEL_VERSION()`` macro. Together with the ``driver`` field
+ ``MEDIA_REVISION()`` macro. Together with the ``driver`` field
  this identifies a particular driver.
 
 -  .. row 8
diff --git a/Documentation/media/uapi/v4l/vidioc-querycap.rst 
b/Documentation/media/uapi/v4l/vidioc-querycap.rst
index 12e0d9a63cd8..b66d9caa7211 100644
--- a/Documentation/media/uapi/v4l/vidioc-querycap.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querycap.rst
@@ -90,13 +90,13 @@ specification the ioctl returns an ``EINVAL`` error code.
example, a stable or distribution-modified kernel uses the V4L2
stack from a newer kernel.
 
-   The version number is formatted using the ``KERNEL_VERSION()``
+   The version number is formatted using the ``MEDIA_REVISION()``
macro:
 * - :cspan:`2`
 
-   ``#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))``
+   ``#define MEDIA_REVISION(a,b,c) (((a) << 16) + ((b) << 8) + (c))``
 
-   ``__u32 version = KERNEL_VERSION(0, 8, 1);``
+   ``__u32 version = MEDIA_REVISION(0, 8, 1);``
 
``printf ("Version: %u.%u.%u\\n",``
 
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 6896266031b9..6b3057266ad1 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -247,9 +247,9 @@ void media_device_cleanup(struct media_device *mdev);
  *
  *  - &media_entity.hw_revision is the hardware device revision in a
  *driver-specific format. When possible the revision should be formatted
- *with the KERNEL_VERSION() macro.
+ *with the MEDIA_REVISION() macro.
  *
- *  - &media_entity.driver_version is formatted with the KERNEL_VERSION()
+ *  - &media_entity.driver_version is formatted with the MEDIA_REVISION()
  *macro. The version minor must be incremented when new features are added
  *to the userspace API without breaking binary compatibility. The version
  *major must be incremented when binary compatibility is broken.
@@ -265,7 +265,6 @@ void media_device_cleanup(struct media_device *mdev);
 int __must_check __media_device_register(struct media_device *mdev,
 struct module *owner);
 
-
 /**
  * media_device_register() - Registers a media device element
  *
-- 
2.12.3

Re: [Nouveau] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Daniel Vetter]

On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
> On 21/06/17 04:38 PM, Daniel Vetter wrote:
> > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
> >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> >> totally obsolete.
> >>
> >> I think the gamma_store can end up invalid on error. But the way I read
> >> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
> >> this pesky legacy fbdev stuff be any better?
> >>
> >> drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
> >> it saves it to the gamma_store which should already be up to date with what
> >> .gamma_get would return and is thus a nop. So, zap it.
> > 
> > Removing drm_fb_helper_save_lut_atomic should be a separate patch I
> > think.
> >  
> >> Signed-off-by: Peter Rosin 
> 
> [...]
> 
> >> @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct 
> >> drm_fb_helper *fb_helper,
> >>  }
> >>  EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
> >>  
> >> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> >> -   u16 blue, u16 regno, struct fb_info *info)
> >> -{
> >> -  struct drm_fb_helper *fb_helper = info->par;
> >> -  struct drm_framebuffer *fb = fb_helper->fb;
> >> -
> >> -  if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> > 
> > This case here seems gone, and it was also the pièce de résistance when I
> > tried tackling fbdev lut support. As far as I understand this stuff we do
> > not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
> > pointless. But I'm honestly not really clear.
> > 
> > I think removing this case should also be a separate patch, and I'd very
> > much prefer that someone with some fbdev-clue would ack it.
> 
> No need for anyone with fbdev-clue, just run fbset -i. :) fbcon uses a
> TRUECOLOR visual at depths > 8.

Then I understand even less what exactly this code does ... Should we keep
it? Is it just pure cargo-cult? Only needed when we'd change the color
depth of the fbdev buffer, which we never do at runtime?

> > It's a pre-existing bug, but should we also try to restore the fbdev lut
> > in drm_fb_helper_restore_fbdev_mode_unlocked()? Would be yet another bug,
> > but might be relevant for your use-case. Just try to run both an fbdev
> > application and some kms-native thing, and then SIGKILL the native kms
> > app.
> > 
> > But since pre-existing not really required, and probably too much effort.
> 
> I suspect something like that indeed needs to be done though. E.g.
> killing Xorg results in fbcon continuing to use the LUT set by Xorg.

Ok, the only trouble with that is atomic kms locking, which requires that
we can only do 1 commit per lock-holding time, and also
drm_modeset_lock_all is an evil hack and needs to be phased out. Two
solutions:

- We just update the lut after we've dropped the locks again in
  restore_fbdev_mode.
- We need both a legacy path, in restore_fbdev_mode_legacy, and an atomic
  path in restore_fbdev_mode_atomic. The latter cannot use the gamme_set
  callback, since that would call drm_atomic_helper_legacy_gamma_set for
  atomic drivers, which would result in two calls to drm_atomic_commit in
  one critical sections. Instead that needs to open-code the logic in
  drm_atomic_helper_legacy_gamma_set and integrate it into the overall
  fbdev restore commit.

The 2nd option is a bit more typing, but much cleaner. It also fits better
into some of the refactoring plans I have (I want to get rid of
drm_modeset_lock_all in the fbdev emulation). And has the benefit of
giving drivers a bit more complex fbdev emulation atomic commits, which
would be good for testing I think.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v10 3/3] arm64/syscalls: Check address limit on user-mode return

[Catalin Marinas]

On Wed, Jun 14, 2017 at 06:12:03PM -0700, Thomas Garnier wrote:
> Ensure the address limit is a user-mode segment before returning to
> user-mode. Otherwise a process can corrupt kernel-mode memory and
> elevate privileges [1].
> 
> The set_fs function sets the TIF_SETFS flag to force a slow path on
> return. In the slow path, the address limit is checked to be USER_DS if
> needed.
> 
> [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=990
> 
> Signed-off-by: Thomas Garnier 
> ---
> v10 redesigns the change to use work flags on set_fs as recommended by
> Linus and agreed by others.
> 
> Based on next-20170609
> ---
>  arch/arm64/include/asm/thread_info.h | 4 +++-
>  arch/arm64/include/asm/uaccess.h | 3 +++
>  arch/arm64/kernel/signal.c   | 5 +
>  3 files changed, 11 insertions(+), 1 deletion(-)

For arm64:

Reviewed-by: Catalin Marinas 

Re: [PATCH v4 20/28] ARM: owl: Implement CPU enable-method for S500

[Arnd Bergmann]

On Tue, Jun 6, 2017 at 2:54 AM, Andreas Färber  wrote:
> Allow to bring up CPU1.
>
> Based on LeMaker linux-actions tree.
>
> Signed-off-by: Andreas Färber 
> ---
>  v3 -> v4: Unchanged
>
>  v3: new
>
>  arch/arm/mach-actions/Makefile  |   3 +
>  arch/arm/mach-actions/headsmp.S |  68 
>  arch/arm/mach-actions/platsmp.c | 166 
> 

I now see build errors in linux-next:

/git/arm-soc/arch/arm/mach-actions/platsmp.c: In function 'write_pen_release':
/git/arm-soc/arch/arm/mach-actions/platsmp.c:39:2: error:
'pen_release' undeclared (first use in this function); did you mean
'seq_release'?
  pen_release = val;
  ^~~
  seq_release
/git/arm-soc/arch/arm/mach-actions/platsmp.c:39:2: note: each
undeclared identifier is reported only once for each function it
appears in
/git/arm-soc/arch/arm/mach-actions/platsmp.c: In function
's500_wakeup_secondary':
/git/arm-soc/arch/arm/mach-actions/platsmp.c:79:2: error: implicit
declaration of function 'dsb_sev'
[-Werror=implicit-function-declaration]
  dsb_sev();
  ^~~
/git/arm-soc/arch/arm/mach-actions/platsmp.c: In function
's500_smp_boot_secondary':
/git/arm-soc/arch/arm/mach-actions/platsmp.c:108:7: error:
'pen_release' undeclared (first use in this function); did you mean
'seq_release'?


> +static DEFINE_SPINLOCK(boot_lock);
> +
> +static void write_pen_release(int val)
> +{
> +   pen_release = val;
> +   smp_wmb();
> +   __cpuc_flush_dcache_area((void *)&pen_release, sizeof(pen_release));
> +   outer_clean_range(__pa(&pen_release), __pa(&pen_release + 1));
> +}
> +
> +static void s500_smp_secondary_init(unsigned int cpu)
> +{
> +   /*
> +* let the primary processor know we're out of the
> +* pen, then head off into the C entry point
> +*/
> +   write_pen_release(-1);
> +
> +   spin_lock(&boot_lock);
> +   spin_unlock(&boot_lock);
> +}
> +
> +void owl_secondary_startup(void);
> +
> +static int s500_wakeup_secondary(unsigned int cpu)
> +{
> +   if (cpu > 3)
> +   return -EINVAL;
> +
> +   switch (cpu) {
> +   case 2:
> +   case 3:
> +   /* CPU2/3 are power-gated */
> +   return -EINVAL;
> +   }
> +
> +   /* wait for CPUx to run to WFE instruction */
> +   udelay(200);
> +
> +   writel(virt_to_phys(owl_secondary_startup),
> +  timer_base_addr + OWL_CPU1_ADDR + (cpu - 1) * 4);
> +   writel(OWL_CPUx_FLAG_BOOT,
> +  timer_base_addr + OWL_CPU1_FLAG + (cpu - 1) * 4);
> +
> +   dsb_sev();
> +   mb();
> +
> +   return 0;
> +}
> +
> +static int s500_smp_boot_secondary(unsigned int cpu, struct task_struct 
> *idle)
> +{
> +   unsigned long timeout;
> +   int ret;
> +
> +   ret = s500_wakeup_secondary(cpu);
> +   if (ret)
> +   return ret;
> +
> +   udelay(10);
> +
> +   spin_lock(&boot_lock);
> +
> +   /*
> +* The secondary processor is waiting to be released from
> +* the holding pen - release it, then wait for it to flag
> +* that it has been released by resetting pen_release.
> +*/
> +   write_pen_release(cpu_logical_map(cpu));
> +   smp_send_reschedule(cpu);
> +
> +   timeout = jiffies + (1 * HZ);
> +   while (time_before(jiffies, timeout)) {
> +   if (pen_release == -1)
> +   break;
> +   }
> +
> +   writel(0, timer_base_addr + OWL_CPU1_ADDR + (cpu - 1) * 4);
> +   writel(0, timer_base_addr + OWL_CPU1_FLAG + (cpu - 1) * 4);
> +
> +   spin_unlock(&boot_lock);
> +
> +   return pen_release != -1 ? -ENOSYS : 0;
> +}

This looks more complicated than necessary. Why do you need the holding
pen when you have a register to start up the CPU?

Arnd

Re: [PATCH v2] perf: libdw support for powerpc [ping]

[Milian Wolff]

On Mittwoch, 21. Juni 2017 03:07:39 CEST Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 15, 2017 at 10:46:16AM +0200, Milian Wolff escreveu:
> > On Tuesday, June 13, 2017 5:55:09 PM CEST Ravi Bangoria wrote:
> > Just a quick question: Have you guys applied my recent patch:
> > 
> > commit 5ea0416f51cc93436bbe497c62ab49fd9cb245b6
> > Author: Milian Wolff 
> > Date:   Thu Jun 1 23:00:21 2017 +0200
> > 
> > perf report: Include partial stacks unwound with libdw
> > 
> > So far the whole stack was thrown away when any error occurred before
> > the maximum stack depth was unwound. This is actually a very common
> > scenario though. The stacks that got unwound so far are still
> > interesting. This removes a large chunk of differences when comparing
> > perf script output for libunwind and libdw perf unwinding.
> > 
> > If not, then this could explain the issue you are seeing.
> 
> Hi Millian, can I take this as an Acked-by or Tested-by?

I have no access to any PowerPC hardware. In principle the code looks fine, 
but that's all I can say here.

Cheers

-- 
Milian Wolff | milian.wo...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

Re: [PATCH] drm/arm: hdlcd: remove unused variables

[Liviu Dudau]

Hi Arnd,

On Tue, Jun 20, 2017 at 10:30:38PM +0200, Arnd Bergmann wrote:
> The last rework left behind two unused variables:
> 
> drm/arm/hdlcd_crtc.c: In function 'hdlcd_plane_atomic_update':
> drm/arm/hdlcd_crtc.c:264:13: warning: unused variable 'src_y' 
> [-Wunused-variable]
> drm/arm/hdlcd_crtc.c:264:6: warning: unused variable 'src_x' 
> [-Wunused-variable]
> 
> This removes them.

Thanks for the patch! Acked-by: Liviu Dudau 

This is starting to get embarrassing :) I'm not sure why I didn't see the 
warnings when
I did my builds, but I would like to make changes so that in the future I can 
catch
situations like this. Do you change the flags of the default make 
multi_v7_defconfig?

I will apply the patch to the HLDCD tree and send Dave an updated pull request.

Best regards,
Liviu

> 
> Fixes: b2ae06ae9834 ("drm/arm: hdlcd: Use CMA helper for plane buffer address 
> calculation")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 0128ebd318f5..d67b6f15e8b8 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -261,7 +261,7 @@ static void hdlcd_plane_atomic_update(struct drm_plane 
> *plane,
>  {
>   struct drm_framebuffer *fb = plane->state->fb;
>   struct hdlcd_drm_private *hdlcd;
> - u32 src_x, src_y, dest_h;
> + u32 dest_h;
>   dma_addr_t scanout_start;
>  
>   if (!fb)
> -- 
> 2.9.0
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

Re: [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

[Borislav Petkov]

On Wed, Jun 21, 2017 at 09:18:59AM +0200, Thomas Gleixner wrote:
> That looks wrong. It's not decrypted it's rather unencrypted, right?

Yeah, it previous versions of the patchset, "decrypted" and
"unencrypted" were both present so we settled on "decrypted" for the
nomenclature.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH RESEND] Calling check_system_tsc_reliable() before unsynchronized_tsc()

[Zhenzhong Duan]

unsynchronized_tsc() checks value of tsc_clocksource_reliable which is set by
check_system_tsc_reliable(). It's better to move check_system_tsc_reliable() at
front.

Though X86_FEATURE_CONSTANT_TSC is usually set for TSC reliable system, just in
case.

Signed-off-by: Zhenzhong Duan 
---
 arch/x86/kernel/tsc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 714dfba..a316bdd 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1412,11 +1412,11 @@ void __init tsc_init(void)
 
use_tsc_delay();
 
+   check_system_tsc_reliable();
+
if (unsynchronized_tsc())
mark_tsc_unstable("TSCs unsynchronized");
 
-   check_system_tsc_reliable();
-
detect_art();
 }
 
-- 
1.7.3

Re: [PATCH v3 05/11] x86/mm: Track the TLB's tlb_gen and update the flushing algorithm

[Thomas Gleixner]

On Tue, 20 Jun 2017, Andy Lutomirski wrote:
>  struct flush_tlb_info {
> + /*
> +  * We support several kinds of flushes.
> +  *
> +  * - Fully flush a single mm.  flush_mm will be set, flush_end will be

flush_mm is the *mm member in the struct, right? You might rename that as a
preparatory step so comments and implementation match.

> +  *   TLB_FLUSH_ALL, and new_tlb_gen will be the tlb_gen to which the
> +  *   IPI sender is trying to catch us up.
> +  *
> +  * - Partially flush a single mm.  flush_mm will be set, flush_start
> +  *   and flush_end will indicate the range, and new_tlb_gen will be
> +  *   set such that the changes between generation new_tlb_gen-1 and
> +  *   new_tlb_gen are entirely contained in the indicated range.
> +  *
> +  * - Fully flush all mms whose tlb_gens have been updated.  flush_mm
> +  *   will be NULL, flush_end will be TLB_FLUSH_ALL, and new_tlb_gen
> +  *   will be zero.
> +  */
>   struct mm_struct *mm;
>   unsigned long start;
>   unsigned long end;
> + u64 new_tlb_gen;

Nit. While at it could you please make that struct tabular aligned as we
usually do in x86?

>  static void flush_tlb_func_common(const struct flush_tlb_info *f,
> bool local, enum tlb_flush_reason reason)
>  {
> + struct mm_struct *loaded_mm = this_cpu_read(cpu_tlbstate.loaded_mm);
> +
> + /*
> +  * Our memory ordering requirement is that any TLB fills that
> +  * happen after we flush the TLB are ordered after we read
> +  * active_mm's tlb_gen.  We don't need any explicit barrier
> +  * because all x86 flush operations are serializing and the
> +  * atomic64_read operation won't be reordered by the compiler.
> +  */

Can you please move the comment above the loaded_mm assignment? 

> + u64 mm_tlb_gen = atomic64_read(&loaded_mm->context.tlb_gen);
> + u64 local_tlb_gen = this_cpu_read(cpu_tlbstate.ctxs[0].tlb_gen);
> +
>   /* This code cannot presently handle being reentered. */
>   VM_WARN_ON(!irqs_disabled());
>  
> + VM_WARN_ON(this_cpu_read(cpu_tlbstate.ctxs[0].ctx_id) !=
> +loaded_mm->context.ctx_id);
> +
>   if (this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK) {
> + /*
> +  * leave_mm() is adequate to handle any type of flush, and
> +  * we would prefer not to receive further IPIs.

While I know what you mean, it might be useful to have a more elaborate
explanation why this prevents new IPIs.

> +  */
>   leave_mm(smp_processor_id());
>   return;
>   }
>  
> - if (f->end == TLB_FLUSH_ALL) {
> - local_flush_tlb();
> - if (local)
> - count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
> - trace_tlb_flush(reason, TLB_FLUSH_ALL);
> - } else {
> + if (local_tlb_gen == mm_tlb_gen) {
> + /*
> +  * There's nothing to do: we're already up to date.  This can
> +  * happen if two concurrent flushes happen -- the first IPI to
> +  * be handled can catch us all the way up, leaving no work for
> +  * the second IPI to be handled.

That not restricted to IPIs, right? A local flush / IPI combo can do that
as well.

Other than those nits;

Reviewed-by: Thomas Gleixner 

Re: [Qemu-devel] [PATCH v11 4/6] mm: function to offer a page block on the free list

[Wei Wang]

On 06/21/2017 01:29 AM, Rik van Riel wrote:

On Tue, 2017-06-20 at 18:49 +0200, David Hildenbrand wrote:

On 20.06.2017 18:44, Rik van Riel wrote:

Nitesh Lal (on the CC list) is working on a way
to efficiently batch recently freed pages for
free page hinting to the hypervisor.

If that is done efficiently enough (eg. with
MADV_FREE on the hypervisor side for lazy freeing,
and lazy later re-use of the pages), do we still
need the harder to use batch interface from this
patch?


David's opinion incoming:

No, I think proper free page hinting would be the optimum solution,
if
done right. This would avoid the batch interface and even turn
virtio-balloon in some sense useless.

I agree with that.  Let me go into some more detail of
what Nitesh is implementing:

1) In arch_free_page, the being-freed page is added
to a per-cpu set of freed pages.


I got some questions here:

1. Are the pages managed one by one on the per-CPU set?
For example, when there are 2 adjacent pages, are they still
put as two nodes on the per-CPU list? or the buddy algorithm
will be re-implemented on the per-CPU list as well?

2. Looks like this will be added to the common free function.
Normally, people may not need the free page hint, do they
need to carry the added burden?



2) Once that set is full, arch_free_pages goes into a
slow path, which:
2a) Iterates over the set of freed pages, and
2b) Checks whether they are still free, and


The pages that have been double checked as "free"
pages here and added to the list for the hypervisor can
also be immediately used.



2c) Adds the still free pages to a list that is
to be passed to the hypervisor, to be MADV_FREEd.
2d) Makes that hypercall.

Meanwhile all arch_alloc_pages has to do is make sure it
does not allocate a page while it is currently being
MADV_FREEd on the hypervisor side.


Is this proposed to replace the balloon driver?



The code Wei is working on looks like it could be
suitable for steps (2c) and (2d) above. Nitesh already
has code for steps 1 through 2b.



May I know the advantages of the added steps? Thanks.

Best,
Wei

Re: [Nouveau] [PATCH 01/11] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Michel Dänzer]

On 21/06/17 05:14 PM, Daniel Vetter wrote:
> On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
>> On 21/06/17 04:38 PM, Daniel Vetter wrote:
>>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
 This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
 totally obsolete.

 I think the gamma_store can end up invalid on error. But the way I read
 it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
 this pesky legacy fbdev stuff be any better?

 drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However,
 it saves it to the gamma_store which should already be up to date with what
 .gamma_get would return and is thus a nop. So, zap it.
>>>
>>> Removing drm_fb_helper_save_lut_atomic should be a separate patch I
>>> think.
>>>  
 Signed-off-by: Peter Rosin 
>>
>> [...]
>>
 @@ -1167,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct 
 drm_fb_helper *fb_helper,
  }
  EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
  
 -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
 -   u16 blue, u16 regno, struct fb_info *info)
 -{
 -  struct drm_fb_helper *fb_helper = info->par;
 -  struct drm_framebuffer *fb = fb_helper->fb;
 -
 -  if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
>>>
>>> This case here seems gone, and it was also the pièce de résistance when I
>>> tried tackling fbdev lut support. As far as I understand this stuff we do
>>> not support FB_VISUAL_TRUECOLOR palette, and all that bitshifting here is
>>> pointless. But I'm honestly not really clear.
>>>
>>> I think removing this case should also be a separate patch, and I'd very
>>> much prefer that someone with some fbdev-clue would ack it.
>>
>> No need for anyone with fbdev-clue, just run fbset -i. :)

Adding Bartlomiej and the linux-fbdev list, just in case I'm wrong below.


>> fbcon uses a TRUECOLOR visual at depths > 8.
> 
> Then I understand even less what exactly this code does ... Should we keep
> it?

I think we need it. It updates the entries of info->pseudo_palette,
which is kind of a pseudocolor palette mapping 16 indices to pixel
values to write to the framebuffer.

If the setcolreg hook is removed, the setcmap hook needs to do this instead.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

[Alexandre Belloni]

On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> Hi!
> 
> > > I agree with that but not the android guys. They seem to mandate an RTC
> > > that can store time from 01/01/1970. I don't know much more than that
> > > because they never cared to explain why that was actually necessary
> > > (apart from a laconic "this will result in a bad user experience")
> > > 
> > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > platform can pass 2038 properly.
> > 
> > Yes, but there are still quite some issues to solve there:
> > 
> >  1) How do you tell the system that it should apply the offset in the
> > first place, i.e at boot time before NTP or any other mechanism 
> > can
> > correct it?
> 
> I'd not do offset. Instead, I'd select a threshold (perhaps year of
> release of given kernel?) and
> 
>   if (rtc_time < year_of_release_of_kernel)
>  rtc_time += 0x1;
> 
> Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> seen in some drivers.
> 
> >  2) Deal with creative vendors who have their own idea about the 'start
> > of the epoch'
> 
> If someone uses different threshold, well, there will be
> confusion. But only for users that have their rtc set to the past,
> which is quite unusual.
> 

Or not, having an RTC set in the past is actually quite common. I'd find
it weird to have a new device boot and be set to a date in the future.

Also note that the threshold or offset thing may seem like a good idea
but fails with many RTCs because of how they handle leap years.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v7 20/36] x86, mpparse: Use memremap to map the mpf and mpc data

[Borislav Petkov]

On Fri, Jun 16, 2017 at 01:53:38PM -0500, Tom Lendacky wrote:
> The SMP MP-table is built by UEFI and placed in memory in a decrypted
> state. These tables are accessed using a mix of early_memremap(),
> early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses
> to use early_memremap()/early_memunmap(). This allows for proper setting
> of the encryption mask so that the data can be successfully accessed when
> SME is active.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/kernel/mpparse.c |   98 
> -
>  1 file changed, 70 insertions(+), 28 deletions(-)

Reviewed-by: Borislav Petkov 

Please put the conversion to pr_fmt() on the TODO list for later.

Thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v2] input: cros_ec_keyb: Report wakeup events

[jeffy]

Hi guys,

On 04/05/2017 09:20 AM, jeffy wrote:

Hi dmitry,

On 04/04/2017 06:41 AM, Dmitry Torokhov wrote:

On Mon, Apr 03, 2017 at 01:53:53PM -0700, Brian Norris wrote:

+ others

On Mon, Apr 03, 2017 at 11:43:36AM -0700, Dmitry Torokhov wrote:

On Sun, Apr 02, 2017 at 08:07:39AM +0800, Jeffy Chen wrote:

Report wakeup events when process events.

Signed-off-by: Jeffy Chen 
---

Changes in v2:
Remove unneeded dts changes.

  drivers/input/keyboard/cros_ec_keyb.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 6a250d6..a93d55f 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -286,6 +286,9 @@ static int cros_ec_keyb_work(struct
notifier_block *nb,
  return NOTIFY_DONE;
  }

+if (device_may_wakeup(ckdev->dev))
+pm_wakeup_event(ckdev->dev, 0);
+
  return NOTIFY_OK;
  }

@@ -632,6 +635,12 @@ static int cros_ec_keyb_probe(struct
platform_device *pdev)
  return err;
  }

+err = device_init_wakeup(dev, 1);


I would prefer if we did not mark cros_ec devices as wakeup sources
unconditionally. Your original patch series was better (except it
failed
to parse the "wakeup-source" property that you introduced.


I'm curious, why is this keyboard device different than any other
keyboard
device? I see several other drivers in drivers/input/keyboard/ that
do an
unconditional 'device_init_wakeup(..., 1)'. Keyboards tend to be wakeup
devices...


If we did something before it does not mean we should continue doing
this forever. I think providing an option to mark device as wakeup
capable should be left to the platform.


right, so i'll add this:
+   device_init_wakeup(dev,
+   device_property_read_bool(dev, "wakeup-source"));





Also, what's the idea behind sub-devices vs. the main cros-ec device
reporting
wakeups? Right now, we have this in drivers/mfd/cros_ec.c:

static irqreturn_t ec_irq_thread(int irq, void *data)
{
 struct cros_ec_device *ec_dev = data;
 int ret;

 if (device_may_wakeup(ec_dev->dev))
 pm_wakeup_event(ec_dev->dev, 0);

 ret = cros_ec_get_next_event(ec_dev);
 if (ret > 0)
 blocking_notifier_call_chain(&ec_dev->event_notifier,
  0, ec_dev);
 return IRQ_HANDLED;
}

But now, we're going to start double-reporting wakeups? Is that
expected?


the double-reporting wakeup could be harmless, but i saw we added a wake 
mask in our 4.4 kernel(for non-wake events):

if (device_may_wakeup(ec_dev->dev) && wake_event)
pm_wakeup_event(ec_dev->dev, 0);

maybe we can do something similar to filter out wakeup events already 
handled by sub devices?




No, and not always (below).



I think we have a similar overlap with the RTC driver (which is being
upstreamed now?):

https://lkml.org/lkml/2017/2/14/658
[PATCH v3 3/4] rtc: cros-ec: add cros-ec-rtc driver.

except that also goes through the trouble of enabling/disabling
wakeup for the
EC IRQ. It seems to me (though I haven't dug in thoroughly) like the
main MFD shouldn't really be doing the wakeup reporting at all, and we
should depend on the sub-devices to do this. (i.e., the current patchset
is a step in the right direction, but it's not 100%.)

Anyway, I could be wrong about the above, but I think we should make
sure there's a consistent answer across the drivers tree.


Hm, it appears we have quite a mess. SPI-based EC declares entire EC as
wakeup source (unconditionally I must add; we do mention "wakeup-source"
in binding document at least). I2C-based EC does not call
device_init_wakeup() at all, presumably that is what caused the calls to
be added into sub-drivers.

hmmm, it looks like the i2c-based ec also do this, but through i2c-core:

if (of_get_property(node, "wakeup-source", NULL))
info.flags |= I2C_CLIENT_WAKE;
...
if (client->flags & I2C_CLIENT_WAKE) {
device_init_wakeup(&client->dev, true);

exynos5250-spring.dts:
cros_ec: embedded-controller@1e {
compatible = "google,cros-ec-i2c";
...
wakeup-source;

and the binding document said we need to add wakeup-source for cros ec spi:
Documentation/devicetree/bindings/mfd/cros-ec.txt

spi@131b {
ec@0 {
compatible = "google,cros-ec-spi";
reg = <0x0>;
interrupts = <14 0>;
interrupt-parent = <&wakeup_eint>;
wakeup-source;


so do we need to add wakeup-source property support in cros_ec_spi? or 
maybe even in spi core(like i2c core)?


We need to resolve this one way or another. You probably do not want to
wake up any time you move your device (accelerometer or other sensors),
so I would try to move this property into individual devices, and try to
come up with a reasonable binding.

Re: [PATCH v2] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

[Maxime Ripard]

On Tue, Jun 13, 2017 at 09:53:31PM +1000, Jonathan Liu wrote:
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
> >> @@ -0,0 +1,163 @@
> >> +/*
> >> + * Copyright (C) 2017 Jonathan Liu
> >> + *
> >> + * Jonathan Liu 
> >
> > Is it?
> 
> I could add you to the copyright since you did the old one. But the
> implementation is different.
> I intend to rework this I2C driver to use the FIFO more to avoid
> splitting larger transfers > 16 bytes and do the transfer in a single
> command. Would you like to be added to the copyright?

You took some code that you didn't create, and added some more
stuff. The copyright on the initial code remains, and it has nothing
to do with whether the author wants it or not, (s)he should be
mentionned, along with you of course.

> >> +? SUN4I_HDMI_DDC_CMD_IMPLICIT_READ
> >> +: SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE,
> >> +hdmi->base + SUN4I_HDMI_DDC_CMD_REG);
> >> +
> >> + reg = readl(hdmi->base + SUN4I_HDMI_DDC_CTRL_REG);
> >> + writel(reg | SUN4I_HDMI_DDC_CTRL_START_CMD,
> >> +hdmi->base + SUN4I_HDMI_DDC_CTRL_REG);
> >> +
> >> + if (!(msg->flags & I2C_M_RD)) {
> >> + for (i = 0; i < count; i++) {
> >> + writeb(*msg->buf++, hdmi->base
> >> ++ SUN4I_HDMI_DDC_FIFO_DATA_REG);
> >
> > writesb?
> I intend to rework the FIFO handling so will need to continue using writeb.

Then you'll change it when you'll rework it. Before then, you can use
writesb.

> >
> >> + --msg->len;
> >> + }
> >> + }
> >> +
> >> + if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_DDC_CTRL_REG,
> >> +reg,
> >> +!(reg & SUN4I_HDMI_DDC_CTRL_START_CMD),
> >> +100, 10))
> >> + return -EIO;
> >> +
> >> + reg = readl(hdmi->base + SUN4I_HDMI_DDC_INTERRUPT_STATUS_REG);
> >> + reg &= ~SUN4I_HDMI_DDC_INTERRUPT_STATUS_FIFO_REQUEST;
> I want to check all the other bits that are set if there are errors.

Same thing here: you'll change it when that happens.

> >
> > You don't need to use that mask.
> >
> >> + if (reg != SUN4I_HDMI_DDC_INTERRUPT_STATUS_TRANSFER_COMPLETE)
> >> + return -EIO;
> >
> > !(reg & SUN4I_HDMI_DDC_INTERRUPT_STATUS_TRANSFER_COMPLETE) would be enough.
> I want to check all the other bits that are set if there are errors.

Same thing here.

> >
> >> +
> >> + if (msg->flags & I2C_M_RD) {
> >> + for (i = 0; i < count; i++) {
> >> + *msg->buf++ = readb(hdmi->base
> >> + + SUN4I_HDMI_DDC_FIFO_DATA_REG);
> >
> > readsb ?
> I am reworking the FIFO handling so I will need to continue to use readb.

Same thing here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH] iwlwifi: mvm: add const to thermal_cooling_device_ops structure

[Bhumika Goyal]

Declare thermal_cooling_device_ops structure as const as it is only passed
as an argument to the function thermal_cooling_device_register and this
argument is of type const. So, declare the structure as const.

Signed-off-by: Bhumika Goyal 
---
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 453a785..0b5a177 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -813,7 +813,7 @@ static int iwl_mvm_tcool_set_cur_state(struct 
thermal_cooling_device *cdev,
return ret;
 }
 
-static struct thermal_cooling_device_ops tcooling_ops = {
+static const struct thermal_cooling_device_ops tcooling_ops = {
.get_max_state = iwl_mvm_tcool_get_max_state,
.get_cur_state = iwl_mvm_tcool_get_cur_state,
.set_cur_state = iwl_mvm_tcool_set_cur_state,
-- 
2.7.4

Re: [PATCH] drm/arm: hdlcd: remove unused variables

[Arnd Bergmann]

On Wed, Jun 21, 2017 at 10:16 AM, Liviu Dudau  wrote:
> Hi Arnd,
>
> On Tue, Jun 20, 2017 at 10:30:38PM +0200, Arnd Bergmann wrote:
>> The last rework left behind two unused variables:
>>
>> drm/arm/hdlcd_crtc.c: In function 'hdlcd_plane_atomic_update':
>> drm/arm/hdlcd_crtc.c:264:13: warning: unused variable 'src_y' 
>> [-Wunused-variable]
>> drm/arm/hdlcd_crtc.c:264:6: warning: unused variable 'src_x' 
>> [-Wunused-variable]
>>
>> This removes them.
>
> Thanks for the patch! Acked-by: Liviu Dudau 
>
> This is starting to get embarrassing :) I'm not sure why I didn't see the 
> warnings when
> I did my builds, but I would like to make changes so that in the future I can 
> catch
> situations like this. Do you change the flags of the default make 
> multi_v7_defconfig?

I mainly do randconfig testing, which catches a lot of bugs that you don't
see in the defconfig build. My general recommendation is to build-test on
ARM allmodconfig and x86 allmodconfig, and to ensure that all new code
gets enabled with CONFIG_COMPILE_TEST in those builds.

> I will apply the patch to the HLDCD tree and send Dave an updated pull 
> request.

Ok, thanks!

  Arnd

Re: [PATCH v3 2/2] acpi, gicv3-its, numa: Adding numa node mapping for gic-its units

[Marc Zyngier]

On 21/06/17 08:09, Jayachandran C wrote:
> On Wed, Jun 21, 2017 at 11:45:43AM +0530, Ganapatrao Kulkarni wrote:
>> Add code to parse SRAT ITS Affinity sub table as defined in ACPI 6.2
>> Later in per device probe, ITS devices are mapped to
>> numa node using ITS id to proximity domain mapping.
>>
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>  drivers/irqchip/irq-gic-v3-its.c | 80 
>> +++-
>>  1 file changed, 79 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index 45ea1933..88cfb32 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -1833,6 +1833,82 @@ static int __init its_of_probe(struct device_node 
>> *node)
>>  
>>  #define ACPI_GICV3_ITS_MEM_SIZE (SZ_128K)
>>  
>> +#ifdef CONFIG_ACPI_NUMA
>> +struct its_srat_map {
>> +u32 numa_node;  /* numa node id */
>> +u32 its_id;  /* GIC ITS ID */
>> +};
>> +
>> +static struct its_srat_map its_srat_maps[MAX_NUMNODES] __initdata = {
>> +[0 ... MAX_NUMNODES - 1] = {NUMA_NO_NODE, UINT_MAX} };
>> +
>> +static int its_in_srat __initdata;
>> +
>> +static int __init
>> +acpi_get_its_numa_node(u32 its_id)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < its_in_srat; i++) {
>> +if (its_id == its_srat_maps[i].its_id)
>> +return its_srat_maps[i].numa_node;
>> +}
>> +return NUMA_NO_NODE;
>> +}
>> +
>> +static int __init
>> +gic_acpi_parse_srat_its(struct acpi_subtable_header *header,
>> + const unsigned long end)
>> +{
>> +int pxm, node;
>> +struct acpi_srat_its_affinity *its_affinity;
>> +
>> +its_affinity = (struct acpi_srat_its_affinity *)header;
>> +if (!its_affinity)
>> +return -EINVAL;
>> +
>> +if (its_affinity->header.length <
>> +sizeof(struct acpi_srat_its_affinity)) {
>> +pr_err("SRAT:ITS: Invalid SRAT header length: %d\n",
>> +its_affinity->header.length);
> 
> The original driver does not use pr_fmt properly, it may be worth
> fixing that up rather than having prefixes, here...

Irrespective of what the "proper" usage is, this kind of cleanup doesn't
belong in this series. Feel free to submit a separate patch.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v3 01/11] x86/mm: Don't reenter flush_tlb_func_common()

[Borislav Petkov]

On Tue, Jun 20, 2017 at 10:22:07PM -0700, Andy Lutomirski wrote:
> It was historically possible to have two concurrent TLB flushes
> targetting the same CPU: one initiated locally and one initiated
> remotely.  This can now cause an OOPS in leave_mm() at
> arch/x86/mm/tlb.c:47:
> 
> if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
> BUG();
> 
> with this call trace:
>  flush_tlb_func_local arch/x86/mm/tlb.c:239 [inline]
>  flush_tlb_mm_range+0x26d/0x370 arch/x86/mm/tlb.c:317

These line numbers would most likely mean nothing soon. I think you
should rather explain why the bug can happen so that future lookers at
that code can find the spot...

> 
> Without reentrancy, this OOPS is impossible: leave_mm() is only
> called if we're not in TLBSTATE_OK, but then we're unexpectedly
> in TLBSTATE_OK in leave_mm().
> 
> This can be caused by flush_tlb_func_remote() happening between
> the two checks and calling leave_mm(), resulting in two consecutive
> leave_mm() calls on the same CPU with no intervening switch_mm()
> calls.

...like this, for example. That should be more future-code-changes-proof.

> We never saw this OOPS before because the old leave_mm()
> implementation didn't put us back in TLBSTATE_OK, so the assertion
> didn't fire.
> 
> Nadav noticed the reentrancy issue in a different context, but
> neither of us realized that it caused a problem yet.
> 
> Cc: Nadav Amit 
> Cc: Dave Hansen 
> Reported-by: "Levin, Alexander (Sasha Levin)" 
> Fixes: 3d28ebceaffa ("x86/mm: Rework lazy TLB to track the actual loaded mm")
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/mm/tlb.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 2a5e851f2035..f06239c6919f 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -208,6 +208,9 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
> mm_struct *next,
>  static void flush_tlb_func_common(const struct flush_tlb_info *f,
> bool local, enum tlb_flush_reason reason)
>  {
> + /* This code cannot presently handle being reentered. */
> + VM_WARN_ON(!irqs_disabled());
> +
>   if (this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK) {
>   leave_mm(smp_processor_id());
>   return;
> @@ -313,8 +316,12 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned 
> long start,
>   info.end = TLB_FLUSH_ALL;
>   }
>  
> - if (mm == this_cpu_read(cpu_tlbstate.loaded_mm))
> + if (mm == this_cpu_read(cpu_tlbstate.loaded_mm)) {
> + local_irq_disable();
>   flush_tlb_func_local(&info, TLB_LOCAL_MM_SHOOTDOWN);
> + local_irq_enable();
> + }

I'm assuming this is going away in a future patch, as disabling IRQs
around a TLB flush is kinda expensive. I guess I'll see if I continue
reading...

:)

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v3] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

[Maxime Ripard]

On Thu, Jun 15, 2017 at 01:29:33AM +1000, Jonathan Liu wrote:
> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
> "As in the general case the DDC bus is accessible by the kernel at the I2C
> level, drivers must make all reasonable efforts to expose it as an I2C
> adapter and use drm_get_edid() instead of abusing this function."
> 
> Exposing the DDC bus as an I2C adapter is more beneficial as it can be used
> for purposes other than reading the EDID such as modifying the EDID or
> using the HDMI DDC pins as an I2C bus through the I2C dev interface from
> userspace (e.g. i2c-tools).
> 
> Implement this for A10s.
> 
> Signed-off-by: Jonathan Liu 
> ---
> Changes for v3:
>  - Explain why drm_do_get_edid should be used and why it's better to expose it
>as an I2C adapter in commit message
>  - Reorder bit defines in descending order for consistency
>  - Keep old unused macros instead of removing them
>  - The v2 algorithm split large transfers into 16 byte transfers but this may
>cause a large single write to be treated as multiple writes causing data
>corruption. The algorithm has been reworked to not split larger transfers
>and make more use of the FIFO to avoid this.
>  - Moved the creation of the DDC clock from sun4i_hdmi_enc.c to
>sun4i_hdmi_i2c.c
>  - Reformatted code
>  - Instead of masking bits that we don't want to check for errors, explicitly
>check the error bits
>  - Clear error bits at start of transfer in case of error from previous 
> transfer
>  - Poll for completion of FIFO clear after setting FIFO clear bit
> 
> Changes for v2:
>  - Rebased against Maxime's sunxi-drm/for-next branch
>  - Fix up error paths in sun4i_hdmi_bind so that the I2C adapter is deleted if
>any of the calls after the I2C adapter is created fails
>  - Remove unnecessary includes in sun4i_hdmi_i2c.c
> 
>  drivers/gpu/drm/sun4i/Makefile |   1 +
>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |  21 
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 101 ++-
>  drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 220 
> +
>  4 files changed, 253 insertions(+), 90 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
> 
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index e29fd3a2ba9c..43c753cafc88 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -2,6 +2,7 @@ sun4i-drm-y += sun4i_drv.o
>  sun4i-drm-y += sun4i_framebuffer.o
>  
>  sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
> +sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
>  
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> index 2f2f2ff1ea63..018af9cbb593 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> @@ -96,6 +96,7 @@
>  #define SUN4I_HDMI_DDC_CTRL_ENABLE   BIT(31)
>  #define SUN4I_HDMI_DDC_CTRL_START_CMDBIT(30)
>  #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_MASKBIT(8)
> +#define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_WRITE   (1 << 8)
>  #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_READ(0 << 8)
>  #define SUN4I_HDMI_DDC_CTRL_RESETBIT(0)
>  
> @@ -105,14 +106,30 @@
>  #define SUN4I_HDMI_DDC_ADDR_OFFSET(off)  (((off) & 0xff) << 8)
>  #define SUN4I_HDMI_DDC_ADDR_SLAVE(addr)  ((addr) & 0xff)
>  
> +#define SUN4I_HDMI_DDC_INT_STATUS_REG0x50c
> +#define SUN4I_HDMI_DDC_INT_STATUS_ILLEGAL_FIFO_OPERATION BIT(7)
> +#define SUN4I_HDMI_DDC_INT_STATUS_DDC_RX_FIFO_UNDERFLOW  BIT(6)
> +#define SUN4I_HDMI_DDC_INT_STATUS_DDC_TX_FIFO_UNDERFLOW  BIT(5)
> +#define SUN4I_HDMI_DDC_INT_STATUS_FIFO_REQUEST   BIT(4)
> +#define SUN4I_HDMI_DDC_INT_STATUS_ARBITRATION_ERROR  BIT(3)
> +#define SUN4I_HDMI_DDC_INT_STATUS_ACK_ERROR  BIT(2)
> +#define SUN4I_HDMI_DDC_INT_STATUS_BUS_ERROR  BIT(1)
> +#define SUN4I_HDMI_DDC_INT_STATUS_TRANSFER_COMPLETE  BIT(0)
> +
>  #define SUN4I_HDMI_DDC_FIFO_CTRL_REG 0x510
>  #define SUN4I_HDMI_DDC_FIFO_CTRL_CLEAR   BIT(31)
>  
> +#define SUN4I_HDMI_DDC_FIFO_STATUS_REG   0x514
> +#define SUN4I_HDMI_DDC_FIFO_STATUS_FULL  BIT(6)
> +#define SUN4I_HDMI_DDC_FIFO_STATUS_EMPTY BIT(5)
> +

The indentation of those bits and the ones above are weird, please
check them.

>  #define SUN4I_HDMI_DDC_FIFO_DATA_REG 0x518
>  #define SUN4I_HDMI_DDC_BYTE_COUNT_REG0x51c
>  
>  #define SUN4I_HDMI_DDC_CMD_REG   0x520
>  #define SUN4I_HDMI_DDC_CMD_EXPLICIT_EDDC_READ6
> +#define SUN4I_HDMI_DDC_CMD_IMPLICIT_READ 5
> +#define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE3
>  
>  #define SUN4I_HDMI_DDC_CLK_REG   0x528
>  #define SUN4I_HDMI_DDC_CLK_M(m)  (((m) & 0x7) << 3)
> @@ -123,6 +140,7 @@
>  #define SUN4I_HDMI_DDC_LINE_CTRL_SCL_ENABLE  BIT(8)
>  
>  #define SUN4I_HDMI_DDC_FIFO_SIZE 16
> +#define SUN4I_HDMI_DDC_