Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Steve Longerbeam]

On 03/11/2017 12:26 PM, Pavel Machek wrote:

Hi!


I tend to agree with that.


I agree as well.

This is in line with how existing drivers behave, too.



Well, sounds like there is consensus on this topic. I guess I'll
go ahead and remove the control inheritance support. I suppose
having a control appear in two places (subdev and video nodes) can
be confusing.


I guess that's way to go. It is impossible to change userland APIs
once the patch is merged...


Ok, not including myself, it's now 4 in favor of removing, 1 against...

Steve

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Steve Longerbeam]

On 03/11/2017 12:26 PM, Pavel Machek wrote:

Hi!


I tend to agree with that.


I agree as well.

This is in line with how existing drivers behave, too.



Well, sounds like there is consensus on this topic. I guess I'll
go ahead and remove the control inheritance support. I suppose
having a control appear in two places (subdev and video nodes) can
be confusing.


I guess that's way to go. It is impossible to change userland APIs
once the patch is merged...


Ok, not including myself, it's now 4 in favor of removing, 1 against...

Steve

Re: [PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval

[Steve Longerbeam]

On 03/11/2017 05:41 AM, Sakari Ailus wrote:

Hi Steve,

On Thu, Mar 09, 2017 at 08:52:58PM -0800, Steve Longerbeam wrote:

If the pads on both sides of a link specify a frame interval, then
those frame intervals should match. Create the exported function
v4l2_subdev_link_validate_frame_interval() to verify this. This
function can be called in a subdevice's media_entity_operations
or v4l2_subdev_pad_ops link_validate callbacks.

Signed-off-by: Steve Longerbeam 


If your only goal is to configure frame dropping on a sub-device, I suggest
to implement s_frame_interval() on the pads of that sub-device only. The
frames are then dropped according to the configured frame rates between the
sink and source pads. Say, configuring sink for 1/30 s and source 1/15 would
drop half of the incoming frames.

Considering that supporting specific frame interval on most sub-devices adds
no value or is not the interface through which it the frame rate configured,
I think it is overkill to change the link validation to expect otherwise.



Well, while I think this function might still have validity in the 
future, I do agree with you that a subdev that has no control over

frame rate has no business implementing the get|set ops.

In the imx-media subdevs, the only one that can affect frame rate (via
frame skipping) is the CSI. So I'll go ahead and remove the
[gs]_frame_interval ops from the others. I can remove this patch as
a result.


Steve

Re: [PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval

[Steve Longerbeam]

On 03/11/2017 05:41 AM, Sakari Ailus wrote:

Hi Steve,

On Thu, Mar 09, 2017 at 08:52:58PM -0800, Steve Longerbeam wrote:

If the pads on both sides of a link specify a frame interval, then
those frame intervals should match. Create the exported function
v4l2_subdev_link_validate_frame_interval() to verify this. This
function can be called in a subdevice's media_entity_operations
or v4l2_subdev_pad_ops link_validate callbacks.

Signed-off-by: Steve Longerbeam 


If your only goal is to configure frame dropping on a sub-device, I suggest
to implement s_frame_interval() on the pads of that sub-device only. The
frames are then dropped according to the configured frame rates between the
sink and source pads. Say, configuring sink for 1/30 s and source 1/15 would
drop half of the incoming frames.

Considering that supporting specific frame interval on most sub-devices adds
no value or is not the interface through which it the frame rate configured,
I think it is overkill to change the link validation to expect otherwise.



Well, while I think this function might still have validity in the 
future, I do agree with you that a subdev that has no control over

frame rate has no business implementing the get|set ops.

In the imx-media subdevs, the only one that can affect frame rate (via
frame skipping) is the CSI. So I'll go ahead and remove the
[gs]_frame_interval ops from the others. I can remove this patch as
a result.


Steve

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Pavel Machek]

Hi!

> >>I tend to agree with that.
> >
> >I agree as well.
> >
> >This is in line with how existing drivers behave, too.
> 
> 
> Well, sounds like there is consensus on this topic. I guess I'll
> go ahead and remove the control inheritance support. I suppose
> having a control appear in two places (subdev and video nodes) can
> be confusing.

I guess that's way to go. It is impossible to change userland APIs
once the patch is merged...
Pavel

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

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Pavel Machek]

Hi!

> >>I tend to agree with that.
> >
> >I agree as well.
> >
> >This is in line with how existing drivers behave, too.
> 
> 
> Well, sounds like there is consensus on this topic. I guess I'll
> go ahead and remove the control inheritance support. I suppose
> having a control appear in two places (subdev and video nodes) can
> be confusing.

I guess that's way to go. It is impossible to change userland APIs
once the patch is merged...
Pavel

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

[PATCH] ARM: tegra: Select SOC_TEGRA_PMC to fix linking error

[Krzysztof Kozlowski]

It is possible to create a ARMv7 config with ARCH_TEGRA but without any
SoC specific flavors.  Such configs fails because mach-tegra/pm.c is
compiled always and it references SOC_TEGRA_PMC driver:

arch/arm/mach-tegra/built-in.o: In function `tegra_pm_set':
arch/arm/mach-tegra/pm.c:188: undefined reference to 
`tegra_pmc_enter_suspend_mode'

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mach-tegra/Kconfig | 1 +
 drivers/soc/tegra/Kconfig   | 4 
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 329f01c5b6f8..eabf101979cc 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -13,5 +13,6 @@ menuconfig ARCH_TEGRA
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
select SOC_BUS
+   select SOC_TEGRA_PMC
help
  This enables support for NVIDIA Tegra based systems.
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 208d6edb3fdb..cfde6d666d4b 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -12,7 +12,6 @@ config ARCH_TEGRA_2x_SOC
select PINCTRL_TEGRA20
select PL310_ERRATA_727915 if CACHE_L2X0
select PL310_ERRATA_769419 if CACHE_L2X0
-   select SOC_TEGRA_PMC
select TEGRA_TIMER
help
  Support for NVIDIA Tegra AP20 and T20 processors, based on the
@@ -24,7 +23,6 @@ config ARCH_TEGRA_3x_SOC
select ARM_ERRATA_764369 if SMP
select PINCTRL_TEGRA30
select PL310_ERRATA_769419 if CACHE_L2X0
-   select SOC_TEGRA_PMC
select TEGRA_TIMER
help
  Support for NVIDIA Tegra T30 processor family, based on the
@@ -35,7 +33,6 @@ config ARCH_TEGRA_114_SOC
select ARM_ERRATA_798181 if SMP
select HAVE_ARM_ARCH_TIMER
select PINCTRL_TEGRA114
-   select SOC_TEGRA_PMC
select TEGRA_TIMER
help
  Support for NVIDIA Tegra T114 processor family, based on the
@@ -45,7 +42,6 @@ config ARCH_TEGRA_124_SOC
bool "Enable support for Tegra124 family"
select HAVE_ARM_ARCH_TIMER
select PINCTRL_TEGRA124
-   select SOC_TEGRA_PMC
select TEGRA_TIMER
help
  Support for NVIDIA Tegra T124 processor family, based on the
-- 
2.9.3

[PATCH] ARM: tegra: Select SOC_TEGRA_PMC to fix linking error

[Krzysztof Kozlowski]

It is possible to create a ARMv7 config with ARCH_TEGRA but without any
SoC specific flavors.  Such configs fails because mach-tegra/pm.c is
compiled always and it references SOC_TEGRA_PMC driver:

arch/arm/mach-tegra/built-in.o: In function `tegra_pm_set':
arch/arm/mach-tegra/pm.c:188: undefined reference to 
`tegra_pmc_enter_suspend_mode'

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mach-tegra/Kconfig | 1 +
 drivers/soc/tegra/Kconfig   | 4 
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 329f01c5b6f8..eabf101979cc 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -13,5 +13,6 @@ menuconfig ARCH_TEGRA
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
select SOC_BUS
+   select SOC_TEGRA_PMC
help
  This enables support for NVIDIA Tegra based systems.
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 208d6edb3fdb..cfde6d666d4b 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -12,7 +12,6 @@ config ARCH_TEGRA_2x_SOC
select PINCTRL_TEGRA20
select PL310_ERRATA_727915 if CACHE_L2X0
select PL310_ERRATA_769419 if CACHE_L2X0
-   select SOC_TEGRA_PMC
select TEGRA_TIMER
help
  Support for NVIDIA Tegra AP20 and T20 processors, based on the
@@ -24,7 +23,6 @@ config ARCH_TEGRA_3x_SOC
select ARM_ERRATA_764369 if SMP
select PINCTRL_TEGRA30
select PL310_ERRATA_769419 if CACHE_L2X0
-   select SOC_TEGRA_PMC
select TEGRA_TIMER
help
  Support for NVIDIA Tegra T30 processor family, based on the
@@ -35,7 +33,6 @@ config ARCH_TEGRA_114_SOC
select ARM_ERRATA_798181 if SMP
select HAVE_ARM_ARCH_TIMER
select PINCTRL_TEGRA114
-   select SOC_TEGRA_PMC
select TEGRA_TIMER
help
  Support for NVIDIA Tegra T114 processor family, based on the
@@ -45,7 +42,6 @@ config ARCH_TEGRA_124_SOC
bool "Enable support for Tegra124 family"
select HAVE_ARM_ARCH_TIMER
select PINCTRL_TEGRA124
-   select SOC_TEGRA_PMC
select TEGRA_TIMER
help
  Support for NVIDIA Tegra T124 processor family, based on the
-- 
2.9.3

Re: srcu: BUG in __synchronize_srcu

[Paul E. McKenney]

On Sat, Mar 11, 2017 at 02:25:14PM +, Mathieu Desnoyers wrote:
> - On Mar 10, 2017, at 5:26 PM, Paul E. McKenney 
> paul...@linux.vnet.ibm.com wrote:
> 
> > On Fri, Mar 10, 2017 at 08:29:55PM +0100, Andrey Konovalov wrote:
> >> On Fri, Mar 10, 2017 at 8:28 PM, Andrey Konovalov  
> >> wrote:
> >> > Hi,
> >> >
> >> > I've got the following error report while fuzzing the kernel with
> >> > syzkaller on an arm64 board.
> >> 
> >> This also happened on x86 a few times during fuzzing, however it
> >> wasn't reproducible.
> >> 
> >> >
> >> > On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8).
> >> >
> >> > A reproducer and .config are attached.
> >> >
> >> > The bug happens while executing the following syzkaller program in a 
> >> > loop.
> >> > While it looks kvm-related, it might be that kvm just stresses the
> >> > srcu subsystem.
> >> >
> >> > mmap(&(0x7f00/0xfff000)=nil, (0xfff000), 0x3, 0x32,
> >> > 0x, 0x0)
> >> > r0 = openat$kvm(0xff9c,
> >> > &(0x7fa05000)="2f6465762f6b766d00", 0x0, 0x0)
> >> > ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
> >> >
> >> > [ cut here ]
> >> > kernel BUG at kernel/rcu/srcu.c:436!
> > 
> > This is on v4.10, correct?
> 
> No, as stated above, this is on linux-next as of March 8, 2017.
> 
> I'm currently looking at the diff of kernel/rcu/srcu.c between v4.10 and
> next-20170310. There are a few changes there.

OK, I must have ended up in the wrong place -- I found line 436 to be
a comment, which caused me to guess a different version.

> One of them is the introduction of the new srcu algorithm with separate
> lock vs unlock counters, which simplifies read lock/unlock by removing the
> sequence counter.
> 
> Another change that directly impacts __synchronize_rcu() (near the
> BUG()) is bc138e7a "srcu: Allow mid-boot use of synchronize_srcu()".
> 
> Odds are that this change introduce an unforeseen scenario that
> skips awaiting for completion later after boot than expected. It
> might be worthwhile to review it closely once more.

SRCU is under active development, so yes, bugs are likely.  I will take
another look.

At the very least, a READ_ONCE() on rcu_scheduler_active would be good.
And that fastpath is removed entirely in later commits not yet pushed out,
so maybe rearranging or combining commits might be helpful.  Though it
would of course still be good to identify the bug in case it is something
subtle that persists.

Thanx, Paul

> Thoughts ?
> 
> Thanks,
> 
> Mathieu
> 
> > 
> >> > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> >> > Modules linked in: meson_drm drm_kms_helper drm dwmac_generic realtek
> >> > dwmac_meson8b stmmac_platform stmmac meson_rng rng_core meson_gxbb_wdt
> >> > ipv6
> >> > CPU: 3 PID: 4250 Comm: a.out Not tainted 
> >> > 4.11.0-rc1-next-20170308-xc2-dirty #3
> >> > Hardware name: Hardkernel ODROID-C2 (DT)
> >> > task: 800063699700 task.stack: 800063cfc000
> >> > PC is at[] __synchronize_srcu+0x3d0/0x470
> >> > kernel/rcu/srcu.c:412
> >> > LR is at[] __synchronize_srcu+0x130/0x470
> >> > kernel/rcu/srcu.c:434
> >> > pc : [] lr : [] pstate: 8145
> >> > sp : 800063cffb00
> >> > x29: 800063cffb00 x28: 80005b1d6e00
> >> > x27: 1fffe4000156b242 x26: 800063cffb70
> >> > x25: 1fffe4000156b23b x24: 2ab591d8
> >> > x23: 29dbf000 x22: 2ab591a0
> >> > x21: 2ab59210 x20: 800063cffb70
> >> > x19: 2ab59190 x18: 0a03
> >> > x17: 944f3950 x16: 2811f818
> >> > x15:  x14: 0007
> >> > x13: 0002 x12: 
> >> > x11: 0040 x10: 1fffe400014b568c
> >> > x9 : 2ab29000 x8 : 0007
> >> > x7 : 0001 x6 : 
> >> > x5 : 0040 x4 : 0003
> >> > x3 : 2ab59208 x2 : 1fffe4000156b243
> >> > x1 :  x0 : 80005e71fb70
> >> >
> >> > Process a.out (pid: 4250, stack limit = 0x800063cfc000)
> >> > Stack: (0x800063cffb00 to 0x800063d0)
> >> > fb00: 800063cffbd0 2821a480 2ab59190 1b63adc0
> >> > fb20: dfff2000 2ab59190 80004b9a8a00 197351bc
> >> > fb40: 80004b9a8de0  800060cad328 80005b1d6e00
> >> > fb60: 80004b9a8a00 197351bc 80004f5e7b70 28217968
> >> > fb80: 8001 dead4ead00010001 dfff2000 
> >> > fba0: 2ab4c4b0   29b0b358
> >> > fbc0: 800063cffbc0 800063cffbc0 800063cffbf0 283ffd20
> >> > fbe0: 80005b1d6e00 0140 800063cffc50 283aedfc
> >> > fc00: 80004b9a8a00 80004b9a8a00 80004b9a8d78 0001
> >> > fc20: 02a6 80004f406780 80004b9a8aa0 

Re: srcu: BUG in __synchronize_srcu

[Paul E. McKenney]

On Sat, Mar 11, 2017 at 02:25:14PM +, Mathieu Desnoyers wrote:
> - On Mar 10, 2017, at 5:26 PM, Paul E. McKenney 
> paul...@linux.vnet.ibm.com wrote:
> 
> > On Fri, Mar 10, 2017 at 08:29:55PM +0100, Andrey Konovalov wrote:
> >> On Fri, Mar 10, 2017 at 8:28 PM, Andrey Konovalov  
> >> wrote:
> >> > Hi,
> >> >
> >> > I've got the following error report while fuzzing the kernel with
> >> > syzkaller on an arm64 board.
> >> 
> >> This also happened on x86 a few times during fuzzing, however it
> >> wasn't reproducible.
> >> 
> >> >
> >> > On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8).
> >> >
> >> > A reproducer and .config are attached.
> >> >
> >> > The bug happens while executing the following syzkaller program in a 
> >> > loop.
> >> > While it looks kvm-related, it might be that kvm just stresses the
> >> > srcu subsystem.
> >> >
> >> > mmap(&(0x7f00/0xfff000)=nil, (0xfff000), 0x3, 0x32,
> >> > 0x, 0x0)
> >> > r0 = openat$kvm(0xff9c,
> >> > &(0x7fa05000)="2f6465762f6b766d00", 0x0, 0x0)
> >> > ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)
> >> >
> >> > [ cut here ]
> >> > kernel BUG at kernel/rcu/srcu.c:436!
> > 
> > This is on v4.10, correct?
> 
> No, as stated above, this is on linux-next as of March 8, 2017.
> 
> I'm currently looking at the diff of kernel/rcu/srcu.c between v4.10 and
> next-20170310. There are a few changes there.

OK, I must have ended up in the wrong place -- I found line 436 to be
a comment, which caused me to guess a different version.

> One of them is the introduction of the new srcu algorithm with separate
> lock vs unlock counters, which simplifies read lock/unlock by removing the
> sequence counter.
> 
> Another change that directly impacts __synchronize_rcu() (near the
> BUG()) is bc138e7a "srcu: Allow mid-boot use of synchronize_srcu()".
> 
> Odds are that this change introduce an unforeseen scenario that
> skips awaiting for completion later after boot than expected. It
> might be worthwhile to review it closely once more.

SRCU is under active development, so yes, bugs are likely.  I will take
another look.

At the very least, a READ_ONCE() on rcu_scheduler_active would be good.
And that fastpath is removed entirely in later commits not yet pushed out,
so maybe rearranging or combining commits might be helpful.  Though it
would of course still be good to identify the bug in case it is something
subtle that persists.

Thanx, Paul

> Thoughts ?
> 
> Thanks,
> 
> Mathieu
> 
> > 
> >> > Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> >> > Modules linked in: meson_drm drm_kms_helper drm dwmac_generic realtek
> >> > dwmac_meson8b stmmac_platform stmmac meson_rng rng_core meson_gxbb_wdt
> >> > ipv6
> >> > CPU: 3 PID: 4250 Comm: a.out Not tainted 
> >> > 4.11.0-rc1-next-20170308-xc2-dirty #3
> >> > Hardware name: Hardkernel ODROID-C2 (DT)
> >> > task: 800063699700 task.stack: 800063cfc000
> >> > PC is at[] __synchronize_srcu+0x3d0/0x470
> >> > kernel/rcu/srcu.c:412
> >> > LR is at[] __synchronize_srcu+0x130/0x470
> >> > kernel/rcu/srcu.c:434
> >> > pc : [] lr : [] pstate: 8145
> >> > sp : 800063cffb00
> >> > x29: 800063cffb00 x28: 80005b1d6e00
> >> > x27: 1fffe4000156b242 x26: 800063cffb70
> >> > x25: 1fffe4000156b23b x24: 2ab591d8
> >> > x23: 29dbf000 x22: 2ab591a0
> >> > x21: 2ab59210 x20: 800063cffb70
> >> > x19: 2ab59190 x18: 0a03
> >> > x17: 944f3950 x16: 2811f818
> >> > x15:  x14: 0007
> >> > x13: 0002 x12: 
> >> > x11: 0040 x10: 1fffe400014b568c
> >> > x9 : 2ab29000 x8 : 0007
> >> > x7 : 0001 x6 : 
> >> > x5 : 0040 x4 : 0003
> >> > x3 : 2ab59208 x2 : 1fffe4000156b243
> >> > x1 :  x0 : 80005e71fb70
> >> >
> >> > Process a.out (pid: 4250, stack limit = 0x800063cfc000)
> >> > Stack: (0x800063cffb00 to 0x800063d0)
> >> > fb00: 800063cffbd0 2821a480 2ab59190 1b63adc0
> >> > fb20: dfff2000 2ab59190 80004b9a8a00 197351bc
> >> > fb40: 80004b9a8de0  800060cad328 80005b1d6e00
> >> > fb60: 80004b9a8a00 197351bc 80004f5e7b70 28217968
> >> > fb80: 8001 dead4ead00010001 dfff2000 
> >> > fba0: 2ab4c4b0   29b0b358
> >> > fbc0: 800063cffbc0 800063cffbc0 800063cffbf0 283ffd20
> >> > fbe0: 80005b1d6e00 0140 800063cffc50 283aedfc
> >> > fc00: 80004b9a8a00 80004b9a8a00 80004b9a8d78 0001
> >> > fc20: 02a6 80004f406780 80004b9a8aa0 800063699ac8
> >> > 

[PATCH v3 4/5] mfd: exynos-lpass: Use common soc/exynos-regs-pmu.h header

[Krzysztof Kozlowski]

The MFD-specific header will go away because it duplicates defines from
exynos-regs-pmu.h.

Reported-by: kbuild test robot 
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/mfd/exynos-lpass.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index 2e064fb8826f..8bebad92a385 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -18,11 +18,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* LPASS Top register definitions */
@@ -83,7 +83,7 @@ static void exynos_lpass_enable(struct exynos_lpass *lpass)
 
/* Activate related PADs from retention state */
regmap_write(lpass->pmu, EXYNOS5433_PAD_RETENTION_AUD_OPTION,
-EXYNOS5433_PAD_INITIATE_WAKEUP_FROM_LOWPWR);
+EXYNOS_WAKEUP_FROM_LOWPWR);
 
exynos_lpass_core_sw_reset(lpass, LPASS_I2S_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_DMA_SW_RESET);
-- 
2.9.3

[PATCH v3 4/5] mfd: exynos-lpass: Use common soc/exynos-regs-pmu.h header

[Krzysztof Kozlowski]

The MFD-specific header will go away because it duplicates defines from
exynos-regs-pmu.h.

Reported-by: kbuild test robot 
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/mfd/exynos-lpass.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/exynos-lpass.c b/drivers/mfd/exynos-lpass.c
index 2e064fb8826f..8bebad92a385 100644
--- a/drivers/mfd/exynos-lpass.c
+++ b/drivers/mfd/exynos-lpass.c
@@ -18,11 +18,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* LPASS Top register definitions */
@@ -83,7 +83,7 @@ static void exynos_lpass_enable(struct exynos_lpass *lpass)
 
/* Activate related PADs from retention state */
regmap_write(lpass->pmu, EXYNOS5433_PAD_RETENTION_AUD_OPTION,
-EXYNOS5433_PAD_INITIATE_WAKEUP_FROM_LOWPWR);
+EXYNOS_WAKEUP_FROM_LOWPWR);
 
exynos_lpass_core_sw_reset(lpass, LPASS_I2S_SW_RESET);
exynos_lpass_core_sw_reset(lpass, LPASS_DMA_SW_RESET);
-- 
2.9.3

[PATCH v3 3/5] phy: exynos-mipi-video: Use consistent method to address phy registers

[Krzysztof Kozlowski]

Exynos4 MIPI phy registers are defined with macro calculating the offset
for given phyN.  Use the same method for Exynos5420 to be consistent.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/phy/phy-exynos-mipi-video.c | 20 ++--
 include/linux/soc/samsung/exynos-regs-pmu.h |  4 +---
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index d7fe1f8c3ac8..acef1d92691e 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -110,46 +110,46 @@ static const struct mipi_phy_device_desc 
exynos5420_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_CSIS0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM0,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY0_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_S_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY0_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
}, {
/* EXYNOS_MIPI_PHY_ID_DSIM0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS0,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY0_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_M_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY0_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
}, {
/* EXYNOS_MIPI_PHY_ID_CSIS1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM1,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY1_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_S_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY1_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(1),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
}, {
/* EXYNOS_MIPI_PHY_ID_DSIM1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS1,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY1_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_M_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY1_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(1),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
}, {
/* EXYNOS_MIPI_PHY_ID_CSIS2 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_NONE,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY2_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(2),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_S_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY2_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(2),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
},
},
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h 
b/include/linux/soc/samsung/exynos-regs-pmu.h
index 4ee54b3fcd57..c261ed927e1e 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -505,9 +505,7 @@
((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
 
 #define EXYNOS5420_USBDRD1_PHY_CONTROL 0x0708
-#define EXYNOS5420_MIPI_PHY0_CONTROL   0x0714
-#define EXYNOS5420_MIPI_PHY1_CONTROL   0x0718
-#define EXYNOS5420_MIPI_PHY2_CONTROL   0x071C
+#define EXYNOS5420_MIPI_PHY_CONTROL(n) (0x0714 + (n) * 
4)
 #define EXYNOS5420_DPTX_PHY_CONTROL0x0728
 #define EXYNOS5420_ARM_CORE2_SYS_PWR_REG   0x1020
 #define EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG 0x1024
-- 
2.9.3

[PATCH v3 3/5] phy: exynos-mipi-video: Use consistent method to address phy registers

[Krzysztof Kozlowski]

Exynos4 MIPI phy registers are defined with macro calculating the offset
for given phyN.  Use the same method for Exynos5420 to be consistent.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/phy/phy-exynos-mipi-video.c | 20 ++--
 include/linux/soc/samsung/exynos-regs-pmu.h |  4 +---
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index d7fe1f8c3ac8..acef1d92691e 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -110,46 +110,46 @@ static const struct mipi_phy_device_desc 
exynos5420_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_CSIS0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM0,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY0_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_S_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY0_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
}, {
/* EXYNOS_MIPI_PHY_ID_DSIM0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS0,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY0_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_M_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY0_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
}, {
/* EXYNOS_MIPI_PHY_ID_CSIS1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM1,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY1_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_S_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY1_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(1),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
}, {
/* EXYNOS_MIPI_PHY_ID_DSIM1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS1,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY1_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_M_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY1_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(1),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
}, {
/* EXYNOS_MIPI_PHY_ID_CSIS2 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_NONE,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5420_MIPI_PHY2_CONTROL,
+   .enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(2),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS5_MIPI_PHY_S_RESETN,
-   .resetn_reg = EXYNOS5420_MIPI_PHY2_CONTROL,
+   .resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(2),
.resetn_map = EXYNOS_MIPI_REGMAP_PMU,
},
},
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h 
b/include/linux/soc/samsung/exynos-regs-pmu.h
index 4ee54b3fcd57..c261ed927e1e 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -505,9 +505,7 @@
((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
 
 #define EXYNOS5420_USBDRD1_PHY_CONTROL 0x0708
-#define EXYNOS5420_MIPI_PHY0_CONTROL   0x0714
-#define EXYNOS5420_MIPI_PHY1_CONTROL   0x0718
-#define EXYNOS5420_MIPI_PHY2_CONTROL   0x071C
+#define EXYNOS5420_MIPI_PHY_CONTROL(n) (0x0714 + (n) * 
4)
 #define EXYNOS5420_DPTX_PHY_CONTROL0x0728
 #define EXYNOS5420_ARM_CORE2_SYS_PWR_REG   0x1020
 #define EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG 0x1024
-- 
2.9.3

[PATCH v3 1/5] phy: exynos4: Remove duplicated defines of PHY register defines

[Krzysztof Kozlowski]

Phy drivers access PMU region through regmap provided by exynos-pmu
driver.   However there is no need to duplicate defines for PMU
registers.  Instead just use whatever is defined in exynos-regs-pmu.h.

Additionally MIPI PHY registers for Exynos5433 start from the same
address as Exynos4 and Exynos5250 so re-use existing defines.

This reduces number of defines and allows removal of one header file.

Suggested-by: Marek Szyprowski 
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
---
 drivers/phy/phy-exynos-mipi-video.c | 12 ++--
 include/linux/mfd/syscon/exynos4-pmu.h  | 21 -
 include/linux/mfd/syscon/exynos5-pmu.h  |  3 ---
 include/linux/soc/samsung/exynos-regs-pmu.h |  9 -
 4 files changed, 14 insertions(+), 31 deletions(-)
 delete mode 100644 include/linux/mfd/syscon/exynos4-pmu.h

diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index 6bee04cc4d53..d7fe1f8c3ac8 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -21,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 enum exynos_mipi_phy_id {
@@ -173,7 +173,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_CSIS0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM0,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY0_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(0),
.resetn_reg = EXYNOS5433_SYSREG_CAM0_MIPI_DPHY_CON,
@@ -182,7 +182,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_DSIM0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS0,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY0_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(0),
.resetn_reg = EXYNOS5433_SYSREG_DISP_MIPI_PHY,
@@ -191,7 +191,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_CSIS1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_NONE,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY1_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(1),
.resetn_reg = EXYNOS5433_SYSREG_CAM0_MIPI_DPHY_CON,
@@ -200,7 +200,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_DSIM1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_NONE,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY1_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(1),
.resetn_reg = EXYNOS5433_SYSREG_DISP_MIPI_PHY,
@@ -209,7 +209,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_CSIS2 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_NONE,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY2_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(2),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(0),
.resetn_reg = EXYNOS5433_SYSREG_CAM1_MIPI_DPHY_CON,
diff --git a/include/linux/mfd/syscon/exynos4-pmu.h 
b/include/linux/mfd/syscon/exynos4-pmu.h
deleted file mode 100644
index 278b1b1549e9..
--- a/include/linux/mfd/syscon/exynos4-pmu.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Copyright (C) 2015 Samsung Electronics Co., Ltd.
- *
- * 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.
- */
-
-#ifndef _LINUX_MFD_SYSCON_PMU_EXYNOS4_H_
-#define _LINUX_MFD_SYSCON_PMU_EXYNOS4_H_
-
-/* Exynos4 PMU register definitions */
-
-/* MIPI_PHYn_CONTROL register offset: n = 0..1 */
-#define EXYNOS4_MIPI_PHY_CONTROL(n)(0x710 + (n) * 4)
-#define 

[PATCH v3 1/5] phy: exynos4: Remove duplicated defines of PHY register defines

[Krzysztof Kozlowski]

Phy drivers access PMU region through regmap provided by exynos-pmu
driver.   However there is no need to duplicate defines for PMU
registers.  Instead just use whatever is defined in exynos-regs-pmu.h.

Additionally MIPI PHY registers for Exynos5433 start from the same
address as Exynos4 and Exynos5250 so re-use existing defines.

This reduces number of defines and allows removal of one header file.

Suggested-by: Marek Szyprowski 
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
---
 drivers/phy/phy-exynos-mipi-video.c | 12 ++--
 include/linux/mfd/syscon/exynos4-pmu.h  | 21 -
 include/linux/mfd/syscon/exynos5-pmu.h  |  3 ---
 include/linux/soc/samsung/exynos-regs-pmu.h |  9 -
 4 files changed, 14 insertions(+), 31 deletions(-)
 delete mode 100644 include/linux/mfd/syscon/exynos4-pmu.h

diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index 6bee04cc4d53..d7fe1f8c3ac8 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -21,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 enum exynos_mipi_phy_id {
@@ -173,7 +173,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_CSIS0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM0,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY0_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(0),
.resetn_reg = EXYNOS5433_SYSREG_CAM0_MIPI_DPHY_CON,
@@ -182,7 +182,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_DSIM0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS0,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY0_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(0),
.resetn_reg = EXYNOS5433_SYSREG_DISP_MIPI_PHY,
@@ -191,7 +191,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_CSIS1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_NONE,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY1_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(1),
.resetn_reg = EXYNOS5433_SYSREG_CAM0_MIPI_DPHY_CON,
@@ -200,7 +200,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_DSIM1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_NONE,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY1_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(1),
.resetn_reg = EXYNOS5433_SYSREG_DISP_MIPI_PHY,
@@ -209,7 +209,7 @@ static const struct mipi_phy_device_desc 
exynos5433_mipi_phy = {
/* EXYNOS_MIPI_PHY_ID_CSIS2 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_NONE,
.enable_val = EXYNOS5_PHY_ENABLE,
-   .enable_reg = EXYNOS5433_MIPI_PHY2_CONTROL,
+   .enable_reg = EXYNOS4_MIPI_PHY_CONTROL(2),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = BIT(0),
.resetn_reg = EXYNOS5433_SYSREG_CAM1_MIPI_DPHY_CON,
diff --git a/include/linux/mfd/syscon/exynos4-pmu.h 
b/include/linux/mfd/syscon/exynos4-pmu.h
deleted file mode 100644
index 278b1b1549e9..
--- a/include/linux/mfd/syscon/exynos4-pmu.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Copyright (C) 2015 Samsung Electronics Co., Ltd.
- *
- * 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.
- */
-
-#ifndef _LINUX_MFD_SYSCON_PMU_EXYNOS4_H_
-#define _LINUX_MFD_SYSCON_PMU_EXYNOS4_H_
-
-/* Exynos4 PMU register definitions */
-
-/* MIPI_PHYn_CONTROL register offset: n = 0..1 */
-#define EXYNOS4_MIPI_PHY_CONTROL(n)(0x710 + (n) * 4)
-#define EXYNOS4_MIPI_PHY_ENABLE(1 << 0)
-#define EXYNOS4_MIPI_PHY_SRESETN 

[PATCH v3 2/5] phy: exynos5: Remove duplicated defines of PHY register defines

[Krzysztof Kozlowski]

Phy drivers access PMU region through regmap provided by exynos-pmu
driver.   However there is no need to duplicate defines for PMU
registers.  Instead just use whatever is defined in exynos-regs-pmu.h.

This reduces number of defines and allows removal of one header.

Suggested-by: Marek Szyprowski 
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
---
 drivers/phy/phy-exynos-dp-video.c   |  1 +
 drivers/phy/phy-exynos5-usbdrd.c|  1 +
 include/linux/mfd/syscon/exynos5-pmu.h  | 27 ---
 include/linux/soc/samsung/exynos-regs-pmu.h |  8 
 4 files changed, 10 insertions(+), 27 deletions(-)

diff --git a/drivers/phy/phy-exynos-dp-video.c 
b/drivers/phy/phy-exynos-dp-video.c
index 34b06154e5d9..d72193188980 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct exynos_dp_video_phy_drvdata {
u32 phy_ctrl_offset;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 07ed608905ac..7c896d0cda18 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Exynos USB PHY registers */
 #define EXYNOS5_FSEL_9MHZ6 0x0
diff --git a/include/linux/mfd/syscon/exynos5-pmu.h 
b/include/linux/mfd/syscon/exynos5-pmu.h
index 77c93551ee58..0a4ddabc395e 100644
--- a/include/linux/mfd/syscon/exynos5-pmu.h
+++ b/include/linux/mfd/syscon/exynos5-pmu.h
@@ -12,33 +12,6 @@
 #ifndef _LINUX_MFD_SYSCON_PMU_EXYNOS5_H_
 #define _LINUX_MFD_SYSCON_PMU_EXYNOS5_H_
 
-/* Exynos5 PMU register definitions */
-#define EXYNOS5_HDMI_PHY_CONTROL   (0x700)
-#define EXYNOS5_USBDRD_PHY_CONTROL (0x704)
-
-/* Exynos5250 specific register definitions */
-#define EXYNOS5_USBHOST_PHY_CONTROL(0x708)
-#define EXYNOS5_EFNAND_PHY_CONTROL (0x70c)
-#define EXYNOS5_MIPI_PHY0_CONTROL  (0x710)
-#define EXYNOS5_MIPI_PHY1_CONTROL  (0x714)
-#define EXYNOS5_ADC_PHY_CONTROL(0x718)
-#define EXYNOS5_MTCADC_PHY_CONTROL (0x71c)
-#define EXYNOS5_DPTX_PHY_CONTROL   (0x720)
-#define EXYNOS5_SATA_PHY_CONTROL   (0x724)
-
-/* Exynos5420 specific register definitions */
-#define EXYNOS5420_USBDRD1_PHY_CONTROL (0x708)
-#define EXYNOS5420_USBHOST_PHY_CONTROL (0x70c)
-#define EXYNOS5420_MIPI_PHY0_CONTROL   (0x714)
-#define EXYNOS5420_MIPI_PHY1_CONTROL   (0x718)
-#define EXYNOS5420_MIPI_PHY2_CONTROL   (0x71c)
-#define EXYNOS5420_ADC_PHY_CONTROL (0x720)
-#define EXYNOS5420_MTCADC_PHY_CONTROL  (0x724)
-#define EXYNOS5420_DPTX_PHY_CONTROL(0x728)
-
-/* Exynos5433 specific register definitions */
-#define EXYNOS5433_USBHOST30_PHY_CONTROL   (0x728)
-
 #define EXYNOS5_PHY_ENABLE BIT(0)
 #define EXYNOS5_MIPI_PHY_S_RESETN  BIT(1)
 #define EXYNOS5_MIPI_PHY_M_RESETN  BIT(2)
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h 
b/include/linux/soc/samsung/exynos-regs-pmu.h
index e57d75889a09..4ee54b3fcd57 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -349,6 +349,8 @@
 
 #define EXYNOS5_AUTO_WDTRESET_DISABLE  0x0408
 #define EXYNOS5_MASK_WDTRESET_REQUEST  0x040C
+#define EXYNOS5_USBDRD_PHY_CONTROL 0x0704
+#define EXYNOS5_DPTX_PHY_CONTROL   0x0720
 
 #define EXYNOS5_USE_RETENTION  BIT(4)
 #define EXYNOS5_SYS_WDTRESET   (1 << 20)
@@ -502,6 +504,11 @@
 #define EXYNOS5420_KFC_CORE_RESET(_nr) \
((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
 
+#define EXYNOS5420_USBDRD1_PHY_CONTROL 0x0708
+#define EXYNOS5420_MIPI_PHY0_CONTROL   0x0714
+#define EXYNOS5420_MIPI_PHY1_CONTROL   0x0718
+#define EXYNOS5420_MIPI_PHY2_CONTROL   0x071C
+#define EXYNOS5420_DPTX_PHY_CONTROL0x0728
 #define EXYNOS5420_ARM_CORE2_SYS_PWR_REG   0x1020
 #define EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG 0x1024
 #define EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG   0x1028
@@ -639,6 +646,7 @@
 | EXYNOS5420_KFC_USE_STANDBY_WFI3)
 
 /* For EXYNOS5433 */
+#define EXYNOS5433_USBHOST30_PHY_CONTROL   (0x0728)
 #define EXYNOS5433_PAD_RETENTION_AUD_OPTION(0x3028)
 #define EXYNOS5433_PAD_RETENTION_MMC2_OPTION   (0x30C8)
 #define EXYNOS5433_PAD_RETENTION_TOP_OPTION(0x3108)
-- 
2.9.3

[PATCH v3 5/5] phy: exynos: Use one define for enable bit

[Krzysztof Kozlowski]

There is no need for separate defines for Exynos4 and Exynos5 phy enable
bit and MIPI phy reset bits.  In both cases there are the same so
simplify it.

This reduces number of defines and allows removal of one header file.

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
---
 drivers/phy/phy-exynos-dp-video.c   |  5 ++--
 drivers/phy/phy-exynos-mipi-video.c | 39 ++---
 drivers/phy/phy-exynos5-usbdrd.c|  5 ++--
 include/linux/mfd/syscon/exynos5-pmu.h  | 22 
 include/linux/soc/samsung/exynos-regs-pmu.h |  3 ++-
 5 files changed, 25 insertions(+), 49 deletions(-)
 delete mode 100644 include/linux/mfd/syscon/exynos5-pmu.h

diff --git a/drivers/phy/phy-exynos-dp-video.c 
b/drivers/phy/phy-exynos-dp-video.c
index d72193188980..bb3279dbf88c 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -37,7 +36,7 @@ static int exynos_dp_video_phy_power_on(struct phy *phy)
 
/* Disable power isolation on DP-PHY */
return regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
- EXYNOS5_PHY_ENABLE, EXYNOS5_PHY_ENABLE);
+ EXYNOS4_PHY_ENABLE, EXYNOS4_PHY_ENABLE);
 }
 
 static int exynos_dp_video_phy_power_off(struct phy *phy)
@@ -46,7 +45,7 @@ static int exynos_dp_video_phy_power_off(struct phy *phy)
 
/* Enable power isolation on DP-PHY */
return regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
- EXYNOS5_PHY_ENABLE, 0);
+ EXYNOS4_PHY_ENABLE, 0);
 }
 
 static const struct phy_ops exynos_dp_video_phy_ops = {
diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index acef1d92691e..c198886f80a3 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -64,7 +63,7 @@ static const struct mipi_phy_device_desc s5pv210_mipi_phy = {
{
/* EXYNOS_MIPI_PHY_ID_CSIS0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM0,
-   .enable_val = EXYNOS4_MIPI_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS4_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS4_MIPI_PHY_SRESETN,
@@ -73,7 +72,7 @@ static const struct mipi_phy_device_desc s5pv210_mipi_phy = {
}, {
/* EXYNOS_MIPI_PHY_ID_DSIM0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS0,
-   .enable_val = EXYNOS4_MIPI_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS4_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS4_MIPI_PHY_MRESETN,
@@ -82,7 +81,7 @@ static const struct mipi_phy_device_desc s5pv210_mipi_phy = {
}, {
/* EXYNOS_MIPI_PHY_ID_CSIS1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM1,
-   .enable_val = EXYNOS4_MIPI_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS4_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS4_MIPI_PHY_SRESETN,
@@ -91,7 +90,7 @@ static const struct mipi_phy_device_desc s5pv210_mipi_phy = {
}, {
/* EXYNOS_MIPI_PHY_ID_DSIM1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS1,
-   .enable_val = EXYNOS4_MIPI_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS4_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS4_MIPI_PHY_MRESETN,
@@ -109,46 +108,46 @@ static const struct mipi_phy_device_desc 
exynos5420_mipi_phy = {
{
/* EXYNOS_MIPI_PHY_ID_CSIS0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM0,
-   .enable_val = EXYNOS5_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
-   .resetn_val = EXYNOS5_MIPI_PHY_S_RESETN,
+   .resetn_val = EXYNOS4_MIPI_PHY_SRESETN,
.resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
   

[PATCH v3 2/5] phy: exynos5: Remove duplicated defines of PHY register defines

[Krzysztof Kozlowski]

Phy drivers access PMU region through regmap provided by exynos-pmu
driver.   However there is no need to duplicate defines for PMU
registers.  Instead just use whatever is defined in exynos-regs-pmu.h.

This reduces number of defines and allows removal of one header.

Suggested-by: Marek Szyprowski 
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
---
 drivers/phy/phy-exynos-dp-video.c   |  1 +
 drivers/phy/phy-exynos5-usbdrd.c|  1 +
 include/linux/mfd/syscon/exynos5-pmu.h  | 27 ---
 include/linux/soc/samsung/exynos-regs-pmu.h |  8 
 4 files changed, 10 insertions(+), 27 deletions(-)

diff --git a/drivers/phy/phy-exynos-dp-video.c 
b/drivers/phy/phy-exynos-dp-video.c
index 34b06154e5d9..d72193188980 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct exynos_dp_video_phy_drvdata {
u32 phy_ctrl_offset;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 07ed608905ac..7c896d0cda18 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Exynos USB PHY registers */
 #define EXYNOS5_FSEL_9MHZ6 0x0
diff --git a/include/linux/mfd/syscon/exynos5-pmu.h 
b/include/linux/mfd/syscon/exynos5-pmu.h
index 77c93551ee58..0a4ddabc395e 100644
--- a/include/linux/mfd/syscon/exynos5-pmu.h
+++ b/include/linux/mfd/syscon/exynos5-pmu.h
@@ -12,33 +12,6 @@
 #ifndef _LINUX_MFD_SYSCON_PMU_EXYNOS5_H_
 #define _LINUX_MFD_SYSCON_PMU_EXYNOS5_H_
 
-/* Exynos5 PMU register definitions */
-#define EXYNOS5_HDMI_PHY_CONTROL   (0x700)
-#define EXYNOS5_USBDRD_PHY_CONTROL (0x704)
-
-/* Exynos5250 specific register definitions */
-#define EXYNOS5_USBHOST_PHY_CONTROL(0x708)
-#define EXYNOS5_EFNAND_PHY_CONTROL (0x70c)
-#define EXYNOS5_MIPI_PHY0_CONTROL  (0x710)
-#define EXYNOS5_MIPI_PHY1_CONTROL  (0x714)
-#define EXYNOS5_ADC_PHY_CONTROL(0x718)
-#define EXYNOS5_MTCADC_PHY_CONTROL (0x71c)
-#define EXYNOS5_DPTX_PHY_CONTROL   (0x720)
-#define EXYNOS5_SATA_PHY_CONTROL   (0x724)
-
-/* Exynos5420 specific register definitions */
-#define EXYNOS5420_USBDRD1_PHY_CONTROL (0x708)
-#define EXYNOS5420_USBHOST_PHY_CONTROL (0x70c)
-#define EXYNOS5420_MIPI_PHY0_CONTROL   (0x714)
-#define EXYNOS5420_MIPI_PHY1_CONTROL   (0x718)
-#define EXYNOS5420_MIPI_PHY2_CONTROL   (0x71c)
-#define EXYNOS5420_ADC_PHY_CONTROL (0x720)
-#define EXYNOS5420_MTCADC_PHY_CONTROL  (0x724)
-#define EXYNOS5420_DPTX_PHY_CONTROL(0x728)
-
-/* Exynos5433 specific register definitions */
-#define EXYNOS5433_USBHOST30_PHY_CONTROL   (0x728)
-
 #define EXYNOS5_PHY_ENABLE BIT(0)
 #define EXYNOS5_MIPI_PHY_S_RESETN  BIT(1)
 #define EXYNOS5_MIPI_PHY_M_RESETN  BIT(2)
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h 
b/include/linux/soc/samsung/exynos-regs-pmu.h
index e57d75889a09..4ee54b3fcd57 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -349,6 +349,8 @@
 
 #define EXYNOS5_AUTO_WDTRESET_DISABLE  0x0408
 #define EXYNOS5_MASK_WDTRESET_REQUEST  0x040C
+#define EXYNOS5_USBDRD_PHY_CONTROL 0x0704
+#define EXYNOS5_DPTX_PHY_CONTROL   0x0720
 
 #define EXYNOS5_USE_RETENTION  BIT(4)
 #define EXYNOS5_SYS_WDTRESET   (1 << 20)
@@ -502,6 +504,11 @@
 #define EXYNOS5420_KFC_CORE_RESET(_nr) \
((EXYNOS5420_KFC_CORE_RESET0 | EXYNOS5420_KFC_ETM_RESET0) << (_nr))
 
+#define EXYNOS5420_USBDRD1_PHY_CONTROL 0x0708
+#define EXYNOS5420_MIPI_PHY0_CONTROL   0x0714
+#define EXYNOS5420_MIPI_PHY1_CONTROL   0x0718
+#define EXYNOS5420_MIPI_PHY2_CONTROL   0x071C
+#define EXYNOS5420_DPTX_PHY_CONTROL0x0728
 #define EXYNOS5420_ARM_CORE2_SYS_PWR_REG   0x1020
 #define EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG 0x1024
 #define EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG   0x1028
@@ -639,6 +646,7 @@
 | EXYNOS5420_KFC_USE_STANDBY_WFI3)
 
 /* For EXYNOS5433 */
+#define EXYNOS5433_USBHOST30_PHY_CONTROL   (0x0728)
 #define EXYNOS5433_PAD_RETENTION_AUD_OPTION(0x3028)
 #define EXYNOS5433_PAD_RETENTION_MMC2_OPTION   (0x30C8)
 #define EXYNOS5433_PAD_RETENTION_TOP_OPTION(0x3108)
-- 
2.9.3

[PATCH v3 5/5] phy: exynos: Use one define for enable bit

[Krzysztof Kozlowski]

There is no need for separate defines for Exynos4 and Exynos5 phy enable
bit and MIPI phy reset bits.  In both cases there are the same so
simplify it.

This reduces number of defines and allows removal of one header file.

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
---
 drivers/phy/phy-exynos-dp-video.c   |  5 ++--
 drivers/phy/phy-exynos-mipi-video.c | 39 ++---
 drivers/phy/phy-exynos5-usbdrd.c|  5 ++--
 include/linux/mfd/syscon/exynos5-pmu.h  | 22 
 include/linux/soc/samsung/exynos-regs-pmu.h |  3 ++-
 5 files changed, 25 insertions(+), 49 deletions(-)
 delete mode 100644 include/linux/mfd/syscon/exynos5-pmu.h

diff --git a/drivers/phy/phy-exynos-dp-video.c 
b/drivers/phy/phy-exynos-dp-video.c
index d72193188980..bb3279dbf88c 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -37,7 +36,7 @@ static int exynos_dp_video_phy_power_on(struct phy *phy)
 
/* Disable power isolation on DP-PHY */
return regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
- EXYNOS5_PHY_ENABLE, EXYNOS5_PHY_ENABLE);
+ EXYNOS4_PHY_ENABLE, EXYNOS4_PHY_ENABLE);
 }
 
 static int exynos_dp_video_phy_power_off(struct phy *phy)
@@ -46,7 +45,7 @@ static int exynos_dp_video_phy_power_off(struct phy *phy)
 
/* Enable power isolation on DP-PHY */
return regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
- EXYNOS5_PHY_ENABLE, 0);
+ EXYNOS4_PHY_ENABLE, 0);
 }
 
 static const struct phy_ops exynos_dp_video_phy_ops = {
diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index acef1d92691e..c198886f80a3 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -64,7 +63,7 @@ static const struct mipi_phy_device_desc s5pv210_mipi_phy = {
{
/* EXYNOS_MIPI_PHY_ID_CSIS0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM0,
-   .enable_val = EXYNOS4_MIPI_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS4_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS4_MIPI_PHY_SRESETN,
@@ -73,7 +72,7 @@ static const struct mipi_phy_device_desc s5pv210_mipi_phy = {
}, {
/* EXYNOS_MIPI_PHY_ID_DSIM0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS0,
-   .enable_val = EXYNOS4_MIPI_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS4_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS4_MIPI_PHY_MRESETN,
@@ -82,7 +81,7 @@ static const struct mipi_phy_device_desc s5pv210_mipi_phy = {
}, {
/* EXYNOS_MIPI_PHY_ID_CSIS1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM1,
-   .enable_val = EXYNOS4_MIPI_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS4_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS4_MIPI_PHY_SRESETN,
@@ -91,7 +90,7 @@ static const struct mipi_phy_device_desc s5pv210_mipi_phy = {
}, {
/* EXYNOS_MIPI_PHY_ID_DSIM1 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_CSIS1,
-   .enable_val = EXYNOS4_MIPI_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS4_MIPI_PHY_CONTROL(1),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
.resetn_val = EXYNOS4_MIPI_PHY_MRESETN,
@@ -109,46 +108,46 @@ static const struct mipi_phy_device_desc 
exynos5420_mipi_phy = {
{
/* EXYNOS_MIPI_PHY_ID_CSIS0 */
.coupled_phy_id = EXYNOS_MIPI_PHY_ID_DSIM0,
-   .enable_val = EXYNOS5_PHY_ENABLE,
+   .enable_val = EXYNOS4_PHY_ENABLE,
.enable_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.enable_map = EXYNOS_MIPI_REGMAP_PMU,
-   .resetn_val = EXYNOS5_MIPI_PHY_S_RESETN,
+   .resetn_val = EXYNOS4_MIPI_PHY_SRESETN,
.resetn_reg = EXYNOS5420_MIPI_PHY_CONTROL(0),
.resetn_map = 

[PATCH v3 0/5] phy/mfd/soc: exynos: Header cleanup

[Krzysztof Kozlowski]

Suggested by Marek, continuation of cleanup of PMU register defines
in headers.
Let's keep all of them in include/linux/soc/samsung/exynos-regs-pmu.h.

Everything is bisectable but should go in through one tree.
It can go through phy tree - in that case 4/5 (added in v3) needs Lee's
ack. For the rest - samsung-soc ack is given by me.
I can also take it through samsung-soc - please let me know.


Changes since v2:
=
1. Rebase wasn't done properly (and MFD Exynos LPASS is not build by exynos
   defconfig) so Kbuild test robot reported issue. New patch 4/5.

Changes since v1:
=
1. Rebase - dependencies should be already in.
2. Add Lee's acks.


Best regards,
Krzysztof



Krzysztof Kozlowski (5):
  phy: exynos4: Remove duplicated defines of PHY register defines
  phy: exynos5: Remove duplicated defines of PHY register defines
  phy: exynos-mipi-video: Use consistent method to address phy registers
  mfd: exynos-lpass: Use common soc/exynos-regs-pmu.h header
  phy: exynos: Use one define for enable bit

 drivers/mfd/exynos-lpass.c  |  4 +-
 drivers/phy/phy-exynos-dp-video.c   |  6 +--
 drivers/phy/phy-exynos-mipi-video.c | 71 ++---
 drivers/phy/phy-exynos5-usbdrd.c|  6 +--
 include/linux/mfd/syscon/exynos4-pmu.h  | 21 -
 include/linux/mfd/syscon/exynos5-pmu.h  | 52 -
 include/linux/soc/samsung/exynos-regs-pmu.h | 16 ++-
 7 files changed, 58 insertions(+), 118 deletions(-)
 delete mode 100644 include/linux/mfd/syscon/exynos4-pmu.h
 delete mode 100644 include/linux/mfd/syscon/exynos5-pmu.h

-- 
2.9.3

[PATCH v3 0/5] phy/mfd/soc: exynos: Header cleanup

[Krzysztof Kozlowski]

Suggested by Marek, continuation of cleanup of PMU register defines
in headers.
Let's keep all of them in include/linux/soc/samsung/exynos-regs-pmu.h.

Everything is bisectable but should go in through one tree.
It can go through phy tree - in that case 4/5 (added in v3) needs Lee's
ack. For the rest - samsung-soc ack is given by me.
I can also take it through samsung-soc - please let me know.


Changes since v2:
=
1. Rebase wasn't done properly (and MFD Exynos LPASS is not build by exynos
   defconfig) so Kbuild test robot reported issue. New patch 4/5.

Changes since v1:
=
1. Rebase - dependencies should be already in.
2. Add Lee's acks.


Best regards,
Krzysztof



Krzysztof Kozlowski (5):
  phy: exynos4: Remove duplicated defines of PHY register defines
  phy: exynos5: Remove duplicated defines of PHY register defines
  phy: exynos-mipi-video: Use consistent method to address phy registers
  mfd: exynos-lpass: Use common soc/exynos-regs-pmu.h header
  phy: exynos: Use one define for enable bit

 drivers/mfd/exynos-lpass.c  |  4 +-
 drivers/phy/phy-exynos-dp-video.c   |  6 +--
 drivers/phy/phy-exynos-mipi-video.c | 71 ++---
 drivers/phy/phy-exynos5-usbdrd.c|  6 +--
 include/linux/mfd/syscon/exynos4-pmu.h  | 21 -
 include/linux/mfd/syscon/exynos5-pmu.h  | 52 -
 include/linux/soc/samsung/exynos-regs-pmu.h | 16 ++-
 7 files changed, 58 insertions(+), 118 deletions(-)
 delete mode 100644 include/linux/mfd/syscon/exynos4-pmu.h
 delete mode 100644 include/linux/mfd/syscon/exynos5-pmu.h

-- 
2.9.3

[PATCH] staging: atomisp: remove redundant check for client being null

[Colin King]

From: Colin Ian King 

The previous statement checks if client is null, so the null check
when assigning dev is redundant and can be removed.

Detected by CoverityScan, CID#1416555 ("Logically Dead Code")

Signed-off-by: Colin Ian King 
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 65513ca..2929492 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -354,7 +354,7 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
if (!client)
return NULL;
 
-   dev = client ? >dev : NULL;
+   dev = >dev;
 
for (i=0; i < MAX_SUBDEVS && gmin_subdevs[i].subdev; i++)
;
-- 
2.10.2

[PATCH] staging: atomisp: remove redundant check for client being null

[Colin King]

From: Colin Ian King 

The previous statement checks if client is null, so the null check
when assigning dev is redundant and can be removed.

Detected by CoverityScan, CID#1416555 ("Logically Dead Code")

Signed-off-by: Colin Ian King 
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 65513ca..2929492 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -354,7 +354,7 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
if (!client)
return NULL;
 
-   dev = client ? >dev : NULL;
+   dev = >dev;
 
for (i=0; i < MAX_SUBDEVS && gmin_subdevs[i].subdev; i++)
;
-- 
2.10.2

[PATCH v15 1/9] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl

[Kyle Huey]

Use the SYSCALL_DEFINE2 macro instead of manually defining it.

Signed-off-by: Kyle Huey 
---
 arch/x86/kernel/process_64.c | 3 ++-
 arch/x86/um/syscalls_64.c| 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index d6b784a5520d..9a72612b25ee 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -32,16 +32,17 @@
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
@@ -616,17 +617,17 @@ long do_arch_prctl(struct task_struct *task, int code, 
unsigned long addr)
default:
ret = -EINVAL;
break;
}
 
return ret;
 }
 
-long sys_arch_prctl(int code, unsigned long addr)
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, addr)
 {
return do_arch_prctl(current, code, addr);
 }
 
 unsigned long KSTK_ESP(struct task_struct *task)
 {
return task_pt_regs(task)->sp;
 }
diff --git a/arch/x86/um/syscalls_64.c b/arch/x86/um/syscalls_64.c
index 10d907098c26..2041acd77e73 100644
--- a/arch/x86/um/syscalls_64.c
+++ b/arch/x86/um/syscalls_64.c
@@ -2,16 +2,17 @@
  * Copyright (C) 2003 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
  * Copyright 2003 PathScale, Inc.
  *
  * Licensed under the GPL
  */
 
 #include 
 #include 
+#include 
 #include 
 #include  /* XXX This should get the constants from libc */
 #include 
 
 long arch_prctl(struct task_struct *task, int code, unsigned long __user *addr)
 {
unsigned long *ptr = addr, tmp;
long ret;
@@ -68,17 +69,17 @@ long arch_prctl(struct task_struct *task, int code, 
unsigned long __user *addr)
case ARCH_GET_GS:
ret = put_user(tmp, addr);
break;
}
 
return ret;
 }
 
-long sys_arch_prctl(int code, unsigned long addr)
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, addr)
 {
return arch_prctl(current, code, (unsigned long __user *) addr);
 }
 
 void arch_switch_to(struct task_struct *to)
 {
if ((to->thread.arch.fs == 0) || (to->mm == NULL))
return;
-- 
2.11.0

[PATCH v15 1/9] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl

[Kyle Huey]

Use the SYSCALL_DEFINE2 macro instead of manually defining it.

Signed-off-by: Kyle Huey 
---
 arch/x86/kernel/process_64.c | 3 ++-
 arch/x86/um/syscalls_64.c| 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index d6b784a5520d..9a72612b25ee 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -32,16 +32,17 @@
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
@@ -616,17 +617,17 @@ long do_arch_prctl(struct task_struct *task, int code, 
unsigned long addr)
default:
ret = -EINVAL;
break;
}
 
return ret;
 }
 
-long sys_arch_prctl(int code, unsigned long addr)
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, addr)
 {
return do_arch_prctl(current, code, addr);
 }
 
 unsigned long KSTK_ESP(struct task_struct *task)
 {
return task_pt_regs(task)->sp;
 }
diff --git a/arch/x86/um/syscalls_64.c b/arch/x86/um/syscalls_64.c
index 10d907098c26..2041acd77e73 100644
--- a/arch/x86/um/syscalls_64.c
+++ b/arch/x86/um/syscalls_64.c
@@ -2,16 +2,17 @@
  * Copyright (C) 2003 - 2007 Jeff Dike (jdike@{addtoit,linux.intel}.com)
  * Copyright 2003 PathScale, Inc.
  *
  * Licensed under the GPL
  */
 
 #include 
 #include 
+#include 
 #include 
 #include  /* XXX This should get the constants from libc */
 #include 
 
 long arch_prctl(struct task_struct *task, int code, unsigned long __user *addr)
 {
unsigned long *ptr = addr, tmp;
long ret;
@@ -68,17 +69,17 @@ long arch_prctl(struct task_struct *task, int code, 
unsigned long __user *addr)
case ARCH_GET_GS:
ret = put_user(tmp, addr);
break;
}
 
return ret;
 }
 
-long sys_arch_prctl(int code, unsigned long addr)
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, addr)
 {
return arch_prctl(current, code, (unsigned long __user *) addr);
 }
 
 void arch_switch_to(struct task_struct *to)
 {
if ((to->thread.arch.fs == 0) || (to->mm == NULL))
return;
-- 
2.11.0

[PATCH v15 9/9] x86/arch_prctl: Rename 'code' argument to 'option'

[Kyle Huey]

arch_prctl arbitrarily changed prctl's 'option' to 'code'. Now that we're
adding additional options, fix that.

Signed-off-by: Kyle Huey 
---
 arch/um/include/shared/os.h   |  2 +-
 arch/x86/include/asm/proto.h  |  4 ++--
 arch/x86/kernel/process.c |  4 ++--
 arch/x86/kernel/process_32.c  |  4 ++--
 arch/x86/kernel/process_64.c  | 14 +++---
 arch/x86/um/asm/ptrace.h  |  2 +-
 arch/x86/um/os-Linux/prctl.c  |  4 ++--
 arch/x86/um/syscalls_32.c |  2 +-
 arch/x86/um/syscalls_64.c | 13 +++--
 include/linux/compat.h|  2 +-
 tools/testing/selftests/x86/cpuid_fault.c |  4 ++--
 11 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index 2b47e0e8d414..fbabca435e7f 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -298,17 +298,17 @@ extern void os_set_ioignore(void);
 
 /* sigio.c */
 extern int add_sigio_fd(int fd);
 extern int ignore_sigio_fd(int fd);
 extern void maybe_sigio_broken(int fd, int read);
 extern void sigio_broken(int fd, int read);
 
 /* sys-x86_64/prctl.c */
-extern int os_arch_prctl(int pid, int code, unsigned long *arg2);
+extern int os_arch_prctl(int pid, int option, unsigned long *arg2);
 
 /* tty.c */
 extern int get_pty(void);
 
 /* sys-$ARCH/task_size.c */
 extern unsigned long os_get_top_address(void);
 
 long syscall(long number, ...);
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index 99836d9a893a..8d3964fc5f91 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -4,17 +4,17 @@
 #include 
 
 /* misc architecture specific prototypes */
 
 void syscall_init(void);
 
 #ifdef CONFIG_X86_64
 void entry_SYSCALL_64(void);
-long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2);
+long do_arch_prctl_64(struct task_struct *task, int option, unsigned long 
arg2);
 #endif
 
 #ifdef CONFIG_X86_32
 void entry_INT80_32(void);
 void entry_SYSENTER_32(void);
 void __begin_SYSENTER_singlestep_region(void);
 void __end_SYSENTER_singlestep_region(void);
 #endif
@@ -26,12 +26,12 @@ void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
 #endif
 
 void x86_configure_nx(void);
 void x86_report_nx(void);
 
 extern int reboot_force;
 
-long do_arch_prctl_common(struct task_struct *task, int code,
+long do_arch_prctl_common(struct task_struct *task, int option,
  unsigned long cpuid_enabled);
 
 #endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 37b512493b25..0bb88428cbf2 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -612,20 +612,20 @@ unsigned long get_wchan(struct task_struct *p)
fp = READ_ONCE_NOCHECK(*(unsigned long *)fp);
} while (count++ < 16 && p->state != TASK_RUNNING);
 
 out:
put_task_stack(p);
return ret;
 }
 
-long do_arch_prctl_common(struct task_struct *task, int code,
+long do_arch_prctl_common(struct task_struct *task, int option,
  unsigned long cpuid_enabled)
 {
-   switch (code) {
+   switch (option) {
case ARCH_GET_CPUID:
return get_cpuid_mode();
case ARCH_SET_CPUID:
return set_cpuid_mode(task, cpuid_enabled);
}
 
return -EINVAL;
 }
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index cead0bd41678..ff40e74c9181 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -302,12 +302,12 @@ __switch_to(struct task_struct *prev_p, struct 
task_struct *next_p)
this_cpu_write(current_task, next_p);
 
/* Load the Intel cache allocation PQR MSR. */
intel_rdt_sched_in();
 
return prev_p;
 }
 
-SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+SYSCALL_DEFINE2(arch_prctl, int, option, unsigned long, arg2)
 {
-   return do_arch_prctl_common(current, code, arg2);
+   return do_arch_prctl_common(current, option, arg2);
 }
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index e6749cb2c96d..ea1a6180bf39 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -543,23 +543,23 @@ static long prctl_map_vdso(const struct vdso_image 
*image, unsigned long addr)
ret = map_vdso_once(image, addr);
if (ret)
return ret;
 
return (long)image->size;
 }
 #endif
 
-long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2)
+long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2)
 {
int ret = 0;
int doit = task == current;
int cpu;
 
-   switch (code) {
+   switch (option) {
case ARCH_SET_GS:
if (arg2 >= TASK_SIZE_MAX)
return 

[PATCH v15 9/9] x86/arch_prctl: Rename 'code' argument to 'option'

[Kyle Huey]

arch_prctl arbitrarily changed prctl's 'option' to 'code'. Now that we're
adding additional options, fix that.

Signed-off-by: Kyle Huey 
---
 arch/um/include/shared/os.h   |  2 +-
 arch/x86/include/asm/proto.h  |  4 ++--
 arch/x86/kernel/process.c |  4 ++--
 arch/x86/kernel/process_32.c  |  4 ++--
 arch/x86/kernel/process_64.c  | 14 +++---
 arch/x86/um/asm/ptrace.h  |  2 +-
 arch/x86/um/os-Linux/prctl.c  |  4 ++--
 arch/x86/um/syscalls_32.c |  2 +-
 arch/x86/um/syscalls_64.c | 13 +++--
 include/linux/compat.h|  2 +-
 tools/testing/selftests/x86/cpuid_fault.c |  4 ++--
 11 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index 2b47e0e8d414..fbabca435e7f 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -298,17 +298,17 @@ extern void os_set_ioignore(void);
 
 /* sigio.c */
 extern int add_sigio_fd(int fd);
 extern int ignore_sigio_fd(int fd);
 extern void maybe_sigio_broken(int fd, int read);
 extern void sigio_broken(int fd, int read);
 
 /* sys-x86_64/prctl.c */
-extern int os_arch_prctl(int pid, int code, unsigned long *arg2);
+extern int os_arch_prctl(int pid, int option, unsigned long *arg2);
 
 /* tty.c */
 extern int get_pty(void);
 
 /* sys-$ARCH/task_size.c */
 extern unsigned long os_get_top_address(void);
 
 long syscall(long number, ...);
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index 99836d9a893a..8d3964fc5f91 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -4,17 +4,17 @@
 #include 
 
 /* misc architecture specific prototypes */
 
 void syscall_init(void);
 
 #ifdef CONFIG_X86_64
 void entry_SYSCALL_64(void);
-long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2);
+long do_arch_prctl_64(struct task_struct *task, int option, unsigned long 
arg2);
 #endif
 
 #ifdef CONFIG_X86_32
 void entry_INT80_32(void);
 void entry_SYSENTER_32(void);
 void __begin_SYSENTER_singlestep_region(void);
 void __end_SYSENTER_singlestep_region(void);
 #endif
@@ -26,12 +26,12 @@ void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
 #endif
 
 void x86_configure_nx(void);
 void x86_report_nx(void);
 
 extern int reboot_force;
 
-long do_arch_prctl_common(struct task_struct *task, int code,
+long do_arch_prctl_common(struct task_struct *task, int option,
  unsigned long cpuid_enabled);
 
 #endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 37b512493b25..0bb88428cbf2 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -612,20 +612,20 @@ unsigned long get_wchan(struct task_struct *p)
fp = READ_ONCE_NOCHECK(*(unsigned long *)fp);
} while (count++ < 16 && p->state != TASK_RUNNING);
 
 out:
put_task_stack(p);
return ret;
 }
 
-long do_arch_prctl_common(struct task_struct *task, int code,
+long do_arch_prctl_common(struct task_struct *task, int option,
  unsigned long cpuid_enabled)
 {
-   switch (code) {
+   switch (option) {
case ARCH_GET_CPUID:
return get_cpuid_mode();
case ARCH_SET_CPUID:
return set_cpuid_mode(task, cpuid_enabled);
}
 
return -EINVAL;
 }
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index cead0bd41678..ff40e74c9181 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -302,12 +302,12 @@ __switch_to(struct task_struct *prev_p, struct 
task_struct *next_p)
this_cpu_write(current_task, next_p);
 
/* Load the Intel cache allocation PQR MSR. */
intel_rdt_sched_in();
 
return prev_p;
 }
 
-SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+SYSCALL_DEFINE2(arch_prctl, int, option, unsigned long, arg2)
 {
-   return do_arch_prctl_common(current, code, arg2);
+   return do_arch_prctl_common(current, option, arg2);
 }
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index e6749cb2c96d..ea1a6180bf39 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -543,23 +543,23 @@ static long prctl_map_vdso(const struct vdso_image 
*image, unsigned long addr)
ret = map_vdso_once(image, addr);
if (ret)
return ret;
 
return (long)image->size;
 }
 #endif
 
-long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2)
+long do_arch_prctl_64(struct task_struct *task, int option, unsigned long arg2)
 {
int ret = 0;
int doit = task == current;
int cpu;
 
-   switch (code) {
+   switch (option) {
case ARCH_SET_GS:
if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
  

[PATCH v15 6/9] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

[Kyle Huey]

Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
When enabled, the processor will fault on attempts to execute the CPUID
instruction with CPL>0. Exposing this feature to userspace will allow a
ptracer to trap and emulate the CPUID instruction.

When supported, this feature is controlled by toggling bit 0 of
MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of
https://bugzilla.kernel.org/attachment.cgi?id=243991

Implement a new pair of arch_prctls, available on both x86-32 and x86-64.

ARCH_GET_CPUID: Returns the current CPUID state, either 0 if CPUID faulting
is enabled (and thus the CPUID instruction is not available) or 1 if
CPUID faulting is not enabled.

ARCH_SET_CPUID: Set the CPUID state to the second argument. If
cpuid_enabled is 0 CPUID faulting will be activated, otherwise it will
be deactivated. Returns ENODEV if CPUID faulting is not supported on
this system.

The state of the CPUID faulting flag is propagated across forks, but reset
upon exec.

Signed-off-by: Kyle Huey 
---
 arch/x86/include/asm/msr-index.h   |  3 ++
 arch/x86/include/asm/processor.h   |  2 +
 arch/x86/include/asm/thread_info.h |  6 ++-
 arch/x86/include/uapi/asm/prctl.h  |  9 +
 arch/x86/kernel/cpu/intel.c|  7 
 arch/x86/kernel/process.c  | 78 ++
 fs/exec.c  |  1 +
 include/linux/thread_info.h|  4 ++
 8 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 33524291b708..af1bec636b1e 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -53,16 +53,19 @@
 #define NHM_C1_AUTO_DEMOTE (1UL << 26)
 #define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
 #define SNB_C1_AUTO_UNDEMOTE   (1UL << 27)
 #define SNB_C3_AUTO_UNDEMOTE   (1UL << 28)
 
 #define MSR_MTRRcap0x00fe
 #define MSR_IA32_BBL_CR_CTL0x0119
 #define MSR_IA32_BBL_CR_CTL3   0x011e
+#define MSR_MISC_FEATURES_ENABLES  0x0140
+#define MSR_MISC_FEATURES_ENABLES_CPUID_FAULT_BIT  0
+#define MSR_MISC_FEATURES_ENABLES_CPUID_FAULT  
BIT_ULL(MSR_MISC_FEATURES_ENABLES_CPUID_FAULT_BIT)
 
 #define MSR_IA32_SYSENTER_CS   0x0174
 #define MSR_IA32_SYSENTER_ESP  0x0175
 #define MSR_IA32_SYSENTER_EIP  0x0176
 
 #define MSR_IA32_MCG_CAP   0x0179
 #define MSR_IA32_MCG_STATUS0x017a
 #define MSR_IA32_MCG_CTL   0x017b
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index f385eca5407a..a80c1b3997ed 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -879,16 +879,18 @@ extern void start_thread(struct pt_regs *regs, unsigned 
long new_ip,
 
 /* Get/set a process' ability to use the timestamp counter instruction */
 #define GET_TSC_CTL(adr)   get_tsc_mode((adr))
 #define SET_TSC_CTL(val)   set_tsc_mode((val))
 
 extern int get_tsc_mode(unsigned long adr);
 extern int set_tsc_mode(unsigned int val);
 
+DECLARE_PER_CPU(u64, msr_misc_features_shadow);
+
 /* Register/unregister a process' MPX related resource */
 #define MPX_ENABLE_MANAGEMENT()mpx_enable_management()
 #define MPX_DISABLE_MANAGEMENT()   mpx_disable_management()
 
 #ifdef CONFIG_X86_INTEL_MPX
 extern int mpx_enable_management(void);
 extern int mpx_disable_management(void);
 #else
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index ad6f5eb07a95..9fc44b95f7cb 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -82,16 +82,17 @@ struct thread_info {
 #define TIF_SIGPENDING 2   /* signal pending */
 #define TIF_NEED_RESCHED   3   /* rescheduling necessary */
 #define TIF_SINGLESTEP 4   /* reenable singlestep on user return*/
 #define TIF_SYSCALL_EMU6   /* syscall emulation active */
 #define TIF_SYSCALL_AUDIT  7   /* syscall auditing active */
 #define TIF_SECCOMP8   /* secure computing */
 #define TIF_USER_RETURN_NOTIFY 11  /* notify kernel of userspace return */
 #define TIF_UPROBE 12  /* breakpointed or singlestepping */
+#define TIF_NOCPUID15  /* CPUID is not accessible in userland 
*/
 #define TIF_NOTSC  16  /* TSC is not accessible in userland */
 #define TIF_IA32   17  /* IA32 compatibility process */
 #define TIF_NOHZ   19  /* in adaptive nohz mode */
 #define TIF_MEMDIE 20  /* is terminating due to OOM killer */
 #define TIF_POLLING_NRFLAG 21  /* idle is polling for TIF_NEED_RESCHED 
*/
 #define TIF_IO_BITMAP  22  /* uses I/O bitmap */
 #define TIF_FORCED_TF  24  /* true if TF in eflags 

[PATCH v15 7/9] x86/arch_prctl: Selftest for ARCH_[GET|SET]_CPUID

[Kyle Huey]

Test disabling and reenabling the cpuid instruction via the new arch_prctl
ARCH_SET_CPUID, retrieving the current state via ARCH_GET_CPUID, and the
expected behaviors across fork() and exec().

Signed-off-by: Kyle Huey 
---
 tools/testing/selftests/x86/Makefile  |   4 +-
 tools/testing/selftests/x86/cpuid_fault.c | 251 ++
 2 files changed, 253 insertions(+), 2 deletions(-)
 create mode 100644 tools/testing/selftests/x86/cpuid_fault.c

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index 38e0a9ca5d71..642df3b40ef9 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -1,17 +1,17 @@
-all:
+ll:
 
 include ../lib.mk
 
 .PHONY: all all_32 all_64 warn_32bit_failure clean
 
 TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt 
ptrace_syscall test_mremap_vdso \
check_initial_reg_state sigreturn ldt_gdt iopl 
mpx-mini-test ioperm \
-   protection_keys test_vdso
+   protection_keys test_vdso cpuid_fault
 TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso 
unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \
vdso_restorer
 TARGETS_C_64BIT_ONLY := fsgsbase sysret_rip
 
 TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
 TARGETS_C_64BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_64BIT_ONLY)
 BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
diff --git a/tools/testing/selftests/x86/cpuid_fault.c 
b/tools/testing/selftests/x86/cpuid_fault.c
new file mode 100644
index ..36963e170fed
--- /dev/null
+++ b/tools/testing/selftests/x86/cpuid_fault.c
@@ -0,0 +1,251 @@
+
+/*
+ * Tests for arch_prctl(ARCH_GET_CPUID, ...) / arch_prctl(ARCH_SET_CPUID, ...)
+ *
+ * Basic test to test behaviour of ARCH_GET_CPUID and ARCH_SET_CPUID
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+#define ARCH_GET_CPUID 0x1005
+#define ARCH_SET_CPUID 0x1006
+#ifdef __x86_64__
+#define SYS_arch_prctl 158
+#else
+#define SYS_arch_prctl 384
+#endif
+*/
+
+const char *cpuid_names[] = {
+   [0] = "[cpuid disabled]",
+   [1] = "[cpuid enabled]",
+};
+
+int arch_prctl(int code, unsigned long arg2)
+{
+   return syscall(SYS_arch_prctl, code, arg2);
+}
+
+int cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
+ unsigned int *edx)
+{
+   return __get_cpuid(0, eax, ebx, ecx, edx);
+}
+
+int do_child_exec_test(int eax, int ebx, int ecx, int edx)
+{
+   int cpuid_val = 0, child = 0, status = 0;
+
+   printf("arch_prctl(ARCH_GET_CPUID); ");
+
+   cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+   if (cpuid_val < 0)
+   errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+   printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+   if (cpuid_val != 0)
+   errx(1, "How did cpuid get re-enabled on fork?");
+
+   child = fork();
+   if (child == 0) {
+   cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+   if (cpuid_val < 0)
+   errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+   printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+   if (cpuid_val != 0)
+   errx(1, "How did cpuid get re-enabled on fork?");
+
+   printf("exec\n");
+   execl("/proc/self/exe", "cpuid-fault", "-early-return", NULL);
+   }
+
+   if (child != waitpid(child, , 0))
+   errx(1, "waitpid failed!?");
+
+   if (WEXITSTATUS(status) != 0)
+   errx(1, "Execed child exited abnormally");
+
+   return 0;
+}
+
+int child_received_signal;
+
+void child_sigsegv_cb(int sig)
+{
+   int cpuid_val = 0;
+
+   child_received_signal = 1;
+   printf("[ SIG_SEGV ]\n");
+   printf("arch_prctl(ARCH_GET_CPUID); ");
+
+   cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+   if (cpuid_val < 0)
+   errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+   printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+   printf("arch_prctl(ARCH_SET_CPUID, 1)\n");
+   if (arch_prctl(ARCH_SET_CPUID, 1) != 0)
+   exit(errno);
+
+   printf("cpuid() == ");
+}
+
+int do_child_test(void)
+{
+   unsigned int eax = 0, ebx = 0, ecx = 0, edx = 0;
+
+   signal(SIGSEGV, child_sigsegv_cb);
+
+   /* the child starts out with cpuid disabled, the signal handler
+* attempts to enable and retry
+*/
+   printf("cpuid() == ");
+   cpuid(, , , );
+   printf("{%x, %x, %x, %x}\n", eax, ebx, ecx, edx);
+   return child_received_signal ? 0 : 42;
+}
+
+int signal_count;
+
+void sigsegv_cb(int sig)
+{
+   int cpuid_val = 0;
+
+   signal_count++;
+   printf("[ SIG_SEGV ]\n");
+   

[PATCH v15 6/9] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

[Kyle Huey]

Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
When enabled, the processor will fault on attempts to execute the CPUID
instruction with CPL>0. Exposing this feature to userspace will allow a
ptracer to trap and emulate the CPUID instruction.

When supported, this feature is controlled by toggling bit 0 of
MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of
https://bugzilla.kernel.org/attachment.cgi?id=243991

Implement a new pair of arch_prctls, available on both x86-32 and x86-64.

ARCH_GET_CPUID: Returns the current CPUID state, either 0 if CPUID faulting
is enabled (and thus the CPUID instruction is not available) or 1 if
CPUID faulting is not enabled.

ARCH_SET_CPUID: Set the CPUID state to the second argument. If
cpuid_enabled is 0 CPUID faulting will be activated, otherwise it will
be deactivated. Returns ENODEV if CPUID faulting is not supported on
this system.

The state of the CPUID faulting flag is propagated across forks, but reset
upon exec.

Signed-off-by: Kyle Huey 
---
 arch/x86/include/asm/msr-index.h   |  3 ++
 arch/x86/include/asm/processor.h   |  2 +
 arch/x86/include/asm/thread_info.h |  6 ++-
 arch/x86/include/uapi/asm/prctl.h  |  9 +
 arch/x86/kernel/cpu/intel.c|  7 
 arch/x86/kernel/process.c  | 78 ++
 fs/exec.c  |  1 +
 include/linux/thread_info.h|  4 ++
 8 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 33524291b708..af1bec636b1e 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -53,16 +53,19 @@
 #define NHM_C1_AUTO_DEMOTE (1UL << 26)
 #define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
 #define SNB_C1_AUTO_UNDEMOTE   (1UL << 27)
 #define SNB_C3_AUTO_UNDEMOTE   (1UL << 28)
 
 #define MSR_MTRRcap0x00fe
 #define MSR_IA32_BBL_CR_CTL0x0119
 #define MSR_IA32_BBL_CR_CTL3   0x011e
+#define MSR_MISC_FEATURES_ENABLES  0x0140
+#define MSR_MISC_FEATURES_ENABLES_CPUID_FAULT_BIT  0
+#define MSR_MISC_FEATURES_ENABLES_CPUID_FAULT  
BIT_ULL(MSR_MISC_FEATURES_ENABLES_CPUID_FAULT_BIT)
 
 #define MSR_IA32_SYSENTER_CS   0x0174
 #define MSR_IA32_SYSENTER_ESP  0x0175
 #define MSR_IA32_SYSENTER_EIP  0x0176
 
 #define MSR_IA32_MCG_CAP   0x0179
 #define MSR_IA32_MCG_STATUS0x017a
 #define MSR_IA32_MCG_CTL   0x017b
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index f385eca5407a..a80c1b3997ed 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -879,16 +879,18 @@ extern void start_thread(struct pt_regs *regs, unsigned 
long new_ip,
 
 /* Get/set a process' ability to use the timestamp counter instruction */
 #define GET_TSC_CTL(adr)   get_tsc_mode((adr))
 #define SET_TSC_CTL(val)   set_tsc_mode((val))
 
 extern int get_tsc_mode(unsigned long adr);
 extern int set_tsc_mode(unsigned int val);
 
+DECLARE_PER_CPU(u64, msr_misc_features_shadow);
+
 /* Register/unregister a process' MPX related resource */
 #define MPX_ENABLE_MANAGEMENT()mpx_enable_management()
 #define MPX_DISABLE_MANAGEMENT()   mpx_disable_management()
 
 #ifdef CONFIG_X86_INTEL_MPX
 extern int mpx_enable_management(void);
 extern int mpx_disable_management(void);
 #else
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index ad6f5eb07a95..9fc44b95f7cb 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -82,16 +82,17 @@ struct thread_info {
 #define TIF_SIGPENDING 2   /* signal pending */
 #define TIF_NEED_RESCHED   3   /* rescheduling necessary */
 #define TIF_SINGLESTEP 4   /* reenable singlestep on user return*/
 #define TIF_SYSCALL_EMU6   /* syscall emulation active */
 #define TIF_SYSCALL_AUDIT  7   /* syscall auditing active */
 #define TIF_SECCOMP8   /* secure computing */
 #define TIF_USER_RETURN_NOTIFY 11  /* notify kernel of userspace return */
 #define TIF_UPROBE 12  /* breakpointed or singlestepping */
+#define TIF_NOCPUID15  /* CPUID is not accessible in userland 
*/
 #define TIF_NOTSC  16  /* TSC is not accessible in userland */
 #define TIF_IA32   17  /* IA32 compatibility process */
 #define TIF_NOHZ   19  /* in adaptive nohz mode */
 #define TIF_MEMDIE 20  /* is terminating due to OOM killer */
 #define TIF_POLLING_NRFLAG 21  /* idle is polling for TIF_NEED_RESCHED 
*/
 #define TIF_IO_BITMAP  22  /* uses I/O bitmap */
 #define TIF_FORCED_TF  24  /* true if TF in eflags artificially */
 #define 

[PATCH v15 7/9] x86/arch_prctl: Selftest for ARCH_[GET|SET]_CPUID

[Kyle Huey]

Test disabling and reenabling the cpuid instruction via the new arch_prctl
ARCH_SET_CPUID, retrieving the current state via ARCH_GET_CPUID, and the
expected behaviors across fork() and exec().

Signed-off-by: Kyle Huey 
---
 tools/testing/selftests/x86/Makefile  |   4 +-
 tools/testing/selftests/x86/cpuid_fault.c | 251 ++
 2 files changed, 253 insertions(+), 2 deletions(-)
 create mode 100644 tools/testing/selftests/x86/cpuid_fault.c

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index 38e0a9ca5d71..642df3b40ef9 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -1,17 +1,17 @@
-all:
+ll:
 
 include ../lib.mk
 
 .PHONY: all all_32 all_64 warn_32bit_failure clean
 
 TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt 
ptrace_syscall test_mremap_vdso \
check_initial_reg_state sigreturn ldt_gdt iopl 
mpx-mini-test ioperm \
-   protection_keys test_vdso
+   protection_keys test_vdso cpuid_fault
 TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso 
unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \
vdso_restorer
 TARGETS_C_64BIT_ONLY := fsgsbase sysret_rip
 
 TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
 TARGETS_C_64BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_64BIT_ONLY)
 BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
diff --git a/tools/testing/selftests/x86/cpuid_fault.c 
b/tools/testing/selftests/x86/cpuid_fault.c
new file mode 100644
index ..36963e170fed
--- /dev/null
+++ b/tools/testing/selftests/x86/cpuid_fault.c
@@ -0,0 +1,251 @@
+
+/*
+ * Tests for arch_prctl(ARCH_GET_CPUID, ...) / arch_prctl(ARCH_SET_CPUID, ...)
+ *
+ * Basic test to test behaviour of ARCH_GET_CPUID and ARCH_SET_CPUID
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+#define ARCH_GET_CPUID 0x1005
+#define ARCH_SET_CPUID 0x1006
+#ifdef __x86_64__
+#define SYS_arch_prctl 158
+#else
+#define SYS_arch_prctl 384
+#endif
+*/
+
+const char *cpuid_names[] = {
+   [0] = "[cpuid disabled]",
+   [1] = "[cpuid enabled]",
+};
+
+int arch_prctl(int code, unsigned long arg2)
+{
+   return syscall(SYS_arch_prctl, code, arg2);
+}
+
+int cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
+ unsigned int *edx)
+{
+   return __get_cpuid(0, eax, ebx, ecx, edx);
+}
+
+int do_child_exec_test(int eax, int ebx, int ecx, int edx)
+{
+   int cpuid_val = 0, child = 0, status = 0;
+
+   printf("arch_prctl(ARCH_GET_CPUID); ");
+
+   cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+   if (cpuid_val < 0)
+   errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+   printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+   if (cpuid_val != 0)
+   errx(1, "How did cpuid get re-enabled on fork?");
+
+   child = fork();
+   if (child == 0) {
+   cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+   if (cpuid_val < 0)
+   errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+   printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+   if (cpuid_val != 0)
+   errx(1, "How did cpuid get re-enabled on fork?");
+
+   printf("exec\n");
+   execl("/proc/self/exe", "cpuid-fault", "-early-return", NULL);
+   }
+
+   if (child != waitpid(child, , 0))
+   errx(1, "waitpid failed!?");
+
+   if (WEXITSTATUS(status) != 0)
+   errx(1, "Execed child exited abnormally");
+
+   return 0;
+}
+
+int child_received_signal;
+
+void child_sigsegv_cb(int sig)
+{
+   int cpuid_val = 0;
+
+   child_received_signal = 1;
+   printf("[ SIG_SEGV ]\n");
+   printf("arch_prctl(ARCH_GET_CPUID); ");
+
+   cpuid_val = arch_prctl(ARCH_GET_CPUID, 0);
+   if (cpuid_val < 0)
+   errx(1, "ARCH_GET_CPUID fails now, but not before?");
+
+   printf("cpuid_val == %s\n", cpuid_names[cpuid_val]);
+   printf("arch_prctl(ARCH_SET_CPUID, 1)\n");
+   if (arch_prctl(ARCH_SET_CPUID, 1) != 0)
+   exit(errno);
+
+   printf("cpuid() == ");
+}
+
+int do_child_test(void)
+{
+   unsigned int eax = 0, ebx = 0, ecx = 0, edx = 0;
+
+   signal(SIGSEGV, child_sigsegv_cb);
+
+   /* the child starts out with cpuid disabled, the signal handler
+* attempts to enable and retry
+*/
+   printf("cpuid() == ");
+   cpuid(, , , );
+   printf("{%x, %x, %x, %x}\n", eax, ebx, ecx, edx);
+   return child_received_signal ? 0 : 42;
+}
+
+int signal_count;
+
+void sigsegv_cb(int sig)
+{
+   int cpuid_val = 0;
+
+   signal_count++;
+   printf("[ SIG_SEGV ]\n");
+   printf("arch_prctl(ARCH_GET_CPUID); ");
+
+  

[PATCH v15 8/9] KVM: x86: virtualize cpuid faulting

[Kyle Huey]

Hardware support for faulting on the cpuid instruction is not required to
emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant
MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a
cpuid-induced VM exit checks the cpuid faulting state and the CPL.
kvm_require_cpl is even kind enough to inject the GP fault for us.

Signed-off-by: Kyle Huey 
Reviewed-by: David Matlack 
---
 arch/x86/include/asm/kvm_host.h |  2 ++
 arch/x86/kvm/cpuid.c|  3 +++
 arch/x86/kvm/cpuid.h| 11 +++
 arch/x86/kvm/emulate.c  |  7 +++
 arch/x86/kvm/x86.c  | 26 ++
 5 files changed, 49 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 74ef58c8ff53..df0c2bd970a4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -607,16 +607,18 @@ struct kvm_vcpu_arch {
u64 pat;
 
unsigned switch_db_regs;
unsigned long db[KVM_NR_DB_REGS];
unsigned long dr6;
unsigned long dr7;
unsigned long eff_db[KVM_NR_DB_REGS];
unsigned long guest_debug_dr7;
+   u64 msr_platform_info;
+   u64 msr_misc_features_enables;
 
u64 mcg_cap;
u64 mcg_status;
u64 mcg_ctl;
u64 mcg_ext_ctl;
u64 *mce_banks;
 
/* Cache MMIO info */
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index efde6cc50875..cb560a509041 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -871,16 +871,19 @@ void kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, 
u32 *ecx, u32 *edx)
trace_kvm_cpuid(function, *eax, *ebx, *ecx, *edx);
 }
 EXPORT_SYMBOL_GPL(kvm_cpuid);
 
 int kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
 {
u32 eax, ebx, ecx, edx;
 
+   if (cpuid_fault_enabled(vcpu) && !kvm_require_cpl(vcpu, 0))
+   return;
+
eax = kvm_register_read(vcpu, VCPU_REGS_RAX);
ecx = kvm_register_read(vcpu, VCPU_REGS_RCX);
kvm_cpuid(vcpu, , , , );
kvm_register_write(vcpu, VCPU_REGS_RAX, eax);
kvm_register_write(vcpu, VCPU_REGS_RBX, ebx);
kvm_register_write(vcpu, VCPU_REGS_RCX, ecx);
kvm_register_write(vcpu, VCPU_REGS_RDX, edx);
return kvm_skip_emulated_instruction(vcpu);
diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index 35058c2c0eea..a6fd40aade7c 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -200,9 +200,20 @@ static inline int guest_cpuid_stepping(struct kvm_vcpu 
*vcpu)
 
best = kvm_find_cpuid_entry(vcpu, 0x1, 0);
if (!best)
return -1;
 
return x86_stepping(best->eax);
 }
 
+static inline bool supports_cpuid_fault(struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.msr_platform_info & MSR_PLATFORM_INFO_CPUID_FAULT;
+}
+
+static inline bool cpuid_fault_enabled(struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.msr_misc_features_enables &
+ MSR_MISC_FEATURES_ENABLES_CPUID_FAULT;
+}
+
 #endif
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 45c7306c8780..6a2ea945d01f 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3849,16 +3849,23 @@ static int em_sti(struct x86_emulate_ctxt *ctxt)
ctxt->interruptibility = KVM_X86_SHADOW_INT_STI;
ctxt->eflags |= X86_EFLAGS_IF;
return X86EMUL_CONTINUE;
 }
 
 static int em_cpuid(struct x86_emulate_ctxt *ctxt)
 {
u32 eax, ebx, ecx, edx;
+   u64 msr = 0;
+
+   ctxt->ops->get_msr(ctxt, MSR_MISC_FEATURES_ENABLES, );
+   if (msr & MSR_MISC_FEATURES_ENABLES_CPUID_FAULT &&
+   ctxt->ops->cpl(ctxt)) {
+   return emulate_gp(ctxt, 0);
+   }
 
eax = reg_read(ctxt, VCPU_REGS_RAX);
ecx = reg_read(ctxt, VCPU_REGS_RCX);
ctxt->ops->get_cpuid(ctxt, , , , );
*reg_write(ctxt, VCPU_REGS_RAX) = eax;
*reg_write(ctxt, VCPU_REGS_RBX) = ebx;
*reg_write(ctxt, VCPU_REGS_RCX) = ecx;
*reg_write(ctxt, VCPU_REGS_RDX) = edx;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1faf620a6fdc..16d2082d85fb 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1003,16 +1003,18 @@ static u32 emulated_msrs[] = {
 
MSR_IA32_TSC_ADJUST,
MSR_IA32_TSCDEADLINE,
MSR_IA32_MISC_ENABLE,
MSR_IA32_MCG_STATUS,
MSR_IA32_MCG_CTL,
MSR_IA32_MCG_EXT_CTL,
MSR_IA32_SMBASE,
+   MSR_PLATFORM_INFO,
+   MSR_MISC_FEATURES_ENABLES,
 };
 
 static unsigned num_emulated_msrs;
 
 bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
 {
if (efer & efer_reserved_bits)
return false;
@@ -2326,16 +2328,31 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
return 1;
vcpu->arch.osvw.length = data;
break;
case MSR_AMD64_OSVW_STATUS:
if 

[PATCH v15 8/9] KVM: x86: virtualize cpuid faulting

[Kyle Huey]

Hardware support for faulting on the cpuid instruction is not required to
emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant
MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a
cpuid-induced VM exit checks the cpuid faulting state and the CPL.
kvm_require_cpl is even kind enough to inject the GP fault for us.

Signed-off-by: Kyle Huey 
Reviewed-by: David Matlack 
---
 arch/x86/include/asm/kvm_host.h |  2 ++
 arch/x86/kvm/cpuid.c|  3 +++
 arch/x86/kvm/cpuid.h| 11 +++
 arch/x86/kvm/emulate.c  |  7 +++
 arch/x86/kvm/x86.c  | 26 ++
 5 files changed, 49 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 74ef58c8ff53..df0c2bd970a4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -607,16 +607,18 @@ struct kvm_vcpu_arch {
u64 pat;
 
unsigned switch_db_regs;
unsigned long db[KVM_NR_DB_REGS];
unsigned long dr6;
unsigned long dr7;
unsigned long eff_db[KVM_NR_DB_REGS];
unsigned long guest_debug_dr7;
+   u64 msr_platform_info;
+   u64 msr_misc_features_enables;
 
u64 mcg_cap;
u64 mcg_status;
u64 mcg_ctl;
u64 mcg_ext_ctl;
u64 *mce_banks;
 
/* Cache MMIO info */
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index efde6cc50875..cb560a509041 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -871,16 +871,19 @@ void kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, 
u32 *ecx, u32 *edx)
trace_kvm_cpuid(function, *eax, *ebx, *ecx, *edx);
 }
 EXPORT_SYMBOL_GPL(kvm_cpuid);
 
 int kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
 {
u32 eax, ebx, ecx, edx;
 
+   if (cpuid_fault_enabled(vcpu) && !kvm_require_cpl(vcpu, 0))
+   return;
+
eax = kvm_register_read(vcpu, VCPU_REGS_RAX);
ecx = kvm_register_read(vcpu, VCPU_REGS_RCX);
kvm_cpuid(vcpu, , , , );
kvm_register_write(vcpu, VCPU_REGS_RAX, eax);
kvm_register_write(vcpu, VCPU_REGS_RBX, ebx);
kvm_register_write(vcpu, VCPU_REGS_RCX, ecx);
kvm_register_write(vcpu, VCPU_REGS_RDX, edx);
return kvm_skip_emulated_instruction(vcpu);
diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index 35058c2c0eea..a6fd40aade7c 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -200,9 +200,20 @@ static inline int guest_cpuid_stepping(struct kvm_vcpu 
*vcpu)
 
best = kvm_find_cpuid_entry(vcpu, 0x1, 0);
if (!best)
return -1;
 
return x86_stepping(best->eax);
 }
 
+static inline bool supports_cpuid_fault(struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.msr_platform_info & MSR_PLATFORM_INFO_CPUID_FAULT;
+}
+
+static inline bool cpuid_fault_enabled(struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.msr_misc_features_enables &
+ MSR_MISC_FEATURES_ENABLES_CPUID_FAULT;
+}
+
 #endif
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 45c7306c8780..6a2ea945d01f 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3849,16 +3849,23 @@ static int em_sti(struct x86_emulate_ctxt *ctxt)
ctxt->interruptibility = KVM_X86_SHADOW_INT_STI;
ctxt->eflags |= X86_EFLAGS_IF;
return X86EMUL_CONTINUE;
 }
 
 static int em_cpuid(struct x86_emulate_ctxt *ctxt)
 {
u32 eax, ebx, ecx, edx;
+   u64 msr = 0;
+
+   ctxt->ops->get_msr(ctxt, MSR_MISC_FEATURES_ENABLES, );
+   if (msr & MSR_MISC_FEATURES_ENABLES_CPUID_FAULT &&
+   ctxt->ops->cpl(ctxt)) {
+   return emulate_gp(ctxt, 0);
+   }
 
eax = reg_read(ctxt, VCPU_REGS_RAX);
ecx = reg_read(ctxt, VCPU_REGS_RCX);
ctxt->ops->get_cpuid(ctxt, , , , );
*reg_write(ctxt, VCPU_REGS_RAX) = eax;
*reg_write(ctxt, VCPU_REGS_RBX) = ebx;
*reg_write(ctxt, VCPU_REGS_RCX) = ecx;
*reg_write(ctxt, VCPU_REGS_RDX) = edx;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1faf620a6fdc..16d2082d85fb 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1003,16 +1003,18 @@ static u32 emulated_msrs[] = {
 
MSR_IA32_TSC_ADJUST,
MSR_IA32_TSCDEADLINE,
MSR_IA32_MISC_ENABLE,
MSR_IA32_MCG_STATUS,
MSR_IA32_MCG_CTL,
MSR_IA32_MCG_EXT_CTL,
MSR_IA32_SMBASE,
+   MSR_PLATFORM_INFO,
+   MSR_MISC_FEATURES_ENABLES,
 };
 
 static unsigned num_emulated_msrs;
 
 bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
 {
if (efer & efer_reserved_bits)
return false;
@@ -2326,16 +2328,31 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
return 1;
vcpu->arch.osvw.length = data;
break;
case MSR_AMD64_OSVW_STATUS:
if (!guest_cpuid_has_osvw(vcpu))
return 

[PATCH v15 4/9] x86/syscalls/32: Wire up arch_prctl on x86-32

[Kyle Huey]

Hook up arch_prctl to call do_arch_prctl() on x86-32, and in 32 bit compat
mode on x86-64. This allows us to have arch_prctls that are not specific to
64 bits.

On UML, simply stub out this syscall.

Signed-off-by: Kyle Huey 
---
 arch/x86/entry/syscalls/syscall_32.tbl | 1 +
 arch/x86/kernel/process_32.c   | 7 +++
 arch/x86/kernel/process_64.c   | 7 +++
 arch/x86/um/Makefile   | 2 +-
 arch/x86/um/syscalls_32.c  | 7 +++
 include/linux/compat.h | 2 ++
 6 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/um/syscalls_32.c

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 9ba050fe47f3..0af59fa789ea 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -385,8 +385,9 @@
 376i386mlock2  sys_mlock2
 377i386copy_file_range sys_copy_file_range
 378i386preadv2 sys_preadv2 
compat_sys_preadv2
 379i386pwritev2sys_pwritev2
compat_sys_pwritev2
 380i386pkey_mprotect   sys_pkey_mprotect
 381i386pkey_alloc  sys_pkey_alloc
 382i386pkey_free   sys_pkey_free
 383i386statx   sys_statx
+384i386arch_prctl  sys_arch_prctl  
compat_sys_arch_prctl
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 4c818f8bc135..cead0bd41678 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -32,16 +32,17 @@
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #ifdef CONFIG_MATH_EMULATION
 #include 
@@ -51,16 +52,17 @@
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 void __show_regs(struct pt_regs *regs, int all)
 {
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
unsigned long d0, d1, d2, d3, d6, d7;
unsigned long sp;
unsigned short ss, gs;
 
@@ -299,8 +301,13 @@ __switch_to(struct task_struct *prev_p, struct task_struct 
*next_p)
 
this_cpu_write(current_task, next_p);
 
/* Load the Intel cache allocation PQR MSR. */
intel_rdt_sched_in();
 
return prev_p;
 }
+
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+   return do_arch_prctl_common(current, code, arg2);
+}
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index beec7d70acf2..e6749cb2c96d 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -630,12 +630,19 @@ SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, 
arg2)
 
ret = do_arch_prctl_64(current, code, arg2);
if (ret == -EINVAL)
ret = do_arch_prctl_common(current, code, arg2);
 
return ret;
 }
 
+#ifdef CONFIG_IA32_EMULATION
+COMPAT_SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+   return do_arch_prctl_common(current, code, arg2);
+}
+#endif
+
 unsigned long KSTK_ESP(struct task_struct *task)
 {
return task_pt_regs(task)->sp;
 }
diff --git a/arch/x86/um/Makefile b/arch/x86/um/Makefile
index e7e7055a8658..69f0827d5f53 100644
--- a/arch/x86/um/Makefile
+++ b/arch/x86/um/Makefile
@@ -11,17 +11,17 @@ endif
 obj-y = bug.o bugs_$(BITS).o delay.o fault.o ldt.o \
ptrace_$(BITS).o ptrace_user.o setjmp_$(BITS).o signal.o \
stub_$(BITS).o stub_segv.o \
sys_call_table_$(BITS).o sysrq_$(BITS).o tls_$(BITS).o \
mem_$(BITS).o subarch.o os-$(OS)/
 
 ifeq ($(CONFIG_X86_32),y)
 
-obj-y += checksum_32.o
+obj-y += checksum_32.o syscalls_32.o
 obj-$(CONFIG_ELF_CORE) += elfcore.o
 
 subarch-y = ../lib/string_32.o ../lib/atomic64_32.o ../lib/atomic64_cx8_32.o
 subarch-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += ../lib/rwsem.o
 
 else
 
 obj-y += syscalls_64.o vdso/
diff --git a/arch/x86/um/syscalls_32.c b/arch/x86/um/syscalls_32.c
new file mode 100644
index ..ccf0598c3fc0
--- /dev/null
+++ b/arch/x86/um/syscalls_32.c
@@ -0,0 +1,7 @@
+#include 
+#include 
+
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+   return -EINVAL;
+}
diff --git a/include/linux/compat.h b/include/linux/compat.h
index aef47be2a5c1..890f4284a5fd 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -718,16 +718,18 @@ int __compat_save_altstack(compat_stack_t __user *, 
unsigned long);
 } while (0);
 
 asmlinkage long compat_sys_sched_rr_get_interval(compat_pid_t pid,
 struct compat_timespec __user 
*interval);
 
 asmlinkage long compat_sys_fanotify_mark(int, unsigned int, __u32, __u32,
int, const char __user *);
 
+asmlinkage long compat_sys_arch_prctl(int code, unsigned 

[PATCH v15 4/9] x86/syscalls/32: Wire up arch_prctl on x86-32

[Kyle Huey]

Hook up arch_prctl to call do_arch_prctl() on x86-32, and in 32 bit compat
mode on x86-64. This allows us to have arch_prctls that are not specific to
64 bits.

On UML, simply stub out this syscall.

Signed-off-by: Kyle Huey 
---
 arch/x86/entry/syscalls/syscall_32.tbl | 1 +
 arch/x86/kernel/process_32.c   | 7 +++
 arch/x86/kernel/process_64.c   | 7 +++
 arch/x86/um/Makefile   | 2 +-
 arch/x86/um/syscalls_32.c  | 7 +++
 include/linux/compat.h | 2 ++
 6 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/um/syscalls_32.c

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index 9ba050fe47f3..0af59fa789ea 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -385,8 +385,9 @@
 376i386mlock2  sys_mlock2
 377i386copy_file_range sys_copy_file_range
 378i386preadv2 sys_preadv2 
compat_sys_preadv2
 379i386pwritev2sys_pwritev2
compat_sys_pwritev2
 380i386pkey_mprotect   sys_pkey_mprotect
 381i386pkey_alloc  sys_pkey_alloc
 382i386pkey_free   sys_pkey_free
 383i386statx   sys_statx
+384i386arch_prctl  sys_arch_prctl  
compat_sys_arch_prctl
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 4c818f8bc135..cead0bd41678 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -32,16 +32,17 @@
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #ifdef CONFIG_MATH_EMULATION
 #include 
@@ -51,16 +52,17 @@
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 void __show_regs(struct pt_regs *regs, int all)
 {
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
unsigned long d0, d1, d2, d3, d6, d7;
unsigned long sp;
unsigned short ss, gs;
 
@@ -299,8 +301,13 @@ __switch_to(struct task_struct *prev_p, struct task_struct 
*next_p)
 
this_cpu_write(current_task, next_p);
 
/* Load the Intel cache allocation PQR MSR. */
intel_rdt_sched_in();
 
return prev_p;
 }
+
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+   return do_arch_prctl_common(current, code, arg2);
+}
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index beec7d70acf2..e6749cb2c96d 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -630,12 +630,19 @@ SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, 
arg2)
 
ret = do_arch_prctl_64(current, code, arg2);
if (ret == -EINVAL)
ret = do_arch_prctl_common(current, code, arg2);
 
return ret;
 }
 
+#ifdef CONFIG_IA32_EMULATION
+COMPAT_SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+   return do_arch_prctl_common(current, code, arg2);
+}
+#endif
+
 unsigned long KSTK_ESP(struct task_struct *task)
 {
return task_pt_regs(task)->sp;
 }
diff --git a/arch/x86/um/Makefile b/arch/x86/um/Makefile
index e7e7055a8658..69f0827d5f53 100644
--- a/arch/x86/um/Makefile
+++ b/arch/x86/um/Makefile
@@ -11,17 +11,17 @@ endif
 obj-y = bug.o bugs_$(BITS).o delay.o fault.o ldt.o \
ptrace_$(BITS).o ptrace_user.o setjmp_$(BITS).o signal.o \
stub_$(BITS).o stub_segv.o \
sys_call_table_$(BITS).o sysrq_$(BITS).o tls_$(BITS).o \
mem_$(BITS).o subarch.o os-$(OS)/
 
 ifeq ($(CONFIG_X86_32),y)
 
-obj-y += checksum_32.o
+obj-y += checksum_32.o syscalls_32.o
 obj-$(CONFIG_ELF_CORE) += elfcore.o
 
 subarch-y = ../lib/string_32.o ../lib/atomic64_32.o ../lib/atomic64_cx8_32.o
 subarch-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += ../lib/rwsem.o
 
 else
 
 obj-y += syscalls_64.o vdso/
diff --git a/arch/x86/um/syscalls_32.c b/arch/x86/um/syscalls_32.c
new file mode 100644
index ..ccf0598c3fc0
--- /dev/null
+++ b/arch/x86/um/syscalls_32.c
@@ -0,0 +1,7 @@
+#include 
+#include 
+
+SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
+{
+   return -EINVAL;
+}
diff --git a/include/linux/compat.h b/include/linux/compat.h
index aef47be2a5c1..890f4284a5fd 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -718,16 +718,18 @@ int __compat_save_altstack(compat_stack_t __user *, 
unsigned long);
 } while (0);
 
 asmlinkage long compat_sys_sched_rr_get_interval(compat_pid_t pid,
 struct compat_timespec __user 
*interval);
 
 asmlinkage long compat_sys_fanotify_mark(int, unsigned int, __u32, __u32,
int, const char __user *);
 
+asmlinkage long compat_sys_arch_prctl(int code, unsigned long arg2);
+
 /*
  

[PATCH v15 0/9] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

[Kyle Huey]

rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by providing constant results.

Newer Intel CPUs (Ivy Bridge and later) can fault when CPUID is executed at
CPL > 0. Expose this capability to userspace as a new pair of arch_prctls,
ARCH_GET_CPUID and ARCH_SET_CPUID.

Since v14:
All: rebased onto x86/process, which contains the switch_to_xtra
improvements

Patch 4: x86/syscalls/32: Wire up arch_prctl on x86-32
- the new arch_prctl is now syscall number 384, because that was
  available

Patch 5: x86/cpufeature: Detect CPUID faulting support
- the newly added probe_xeon_phi_r3mwait is called from
  init_intel_misc_features

[PATCH v15 5/9] x86/cpufeature: Detect CPUID faulting support

[Kyle Huey]

Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
When enabled, the processor will fault on attempts to execute the CPUID
instruction with CPL>0. This will allow a ptracer to emulate the CPUID
instruction.

Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
documented in detail in Section 2.3.2 of
https://bugzilla.kernel.org/attachment.cgi?id=243991

Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.

Signed-off-by: Kyle Huey 
Reviewed-by: Borislav Petkov 
---
 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/include/asm/msr-index.h   |  2 ++
 arch/x86/kernel/cpu/intel.c| 14 +-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index b04bb6dfed7f..0fe00446f9ca 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -182,16 +182,17 @@
 
 /*
  * Auxiliary flags: Linux defined - For features scattered in various
  * CPUID levels like 0x6, 0xA etc, word 7.
  *
  * Reuse free bits when adding new feature flags!
  */
 #define X86_FEATURE_RING3MWAIT ( 7*32+ 0) /* Ring 3 MONITOR/MWAIT */
+#define X86_FEATURE_CPUID_FAULT ( 7*32+ 1) /* Intel CPUID faulting */
 #define X86_FEATURE_CPB( 7*32+ 2) /* AMD Core Performance 
Boost */
 #define X86_FEATURE_EPB( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS 
support */
 #define X86_FEATURE_CAT_L3 ( 7*32+ 4) /* Cache Allocation Technology L3 */
 #define X86_FEATURE_CAT_L2 ( 7*32+ 5) /* Cache Allocation Technology L2 */
 #define X86_FEATURE_CDP_L3 ( 7*32+ 6) /* Code and Data Prioritization L3 */
 
 #define X86_FEATURE_HW_PSTATE  ( 7*32+ 8) /* AMD HW-PState */
 #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 4c928f332f8f..33524291b708 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -40,16 +40,18 @@
 
 #define MSR_PPIN_CTL   0x004e
 #define MSR_PPIN   0x004f
 
 #define MSR_IA32_PERFCTR0  0x00c1
 #define MSR_IA32_PERFCTR1  0x00c2
 #define MSR_FSB_FREQ   0x00cd
 #define MSR_PLATFORM_INFO  0x00ce
+#define MSR_PLATFORM_INFO_CPUID_FAULT_BIT  31
+#define MSR_PLATFORM_INFO_CPUID_FAULT  
BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
 
 #define MSR_PKG_CST_CONFIG_CONTROL 0x00e2
 #define NHM_C3_AUTO_DEMOTE (1UL << 25)
 #define NHM_C1_AUTO_DEMOTE (1UL << 26)
 #define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
 #define SNB_C1_AUTO_UNDEMOTE   (1UL << 27)
 #define SNB_C3_AUTO_UNDEMOTE   (1UL << 28)
 
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 063197771b8d..e006c6b54cad 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -483,16 +483,28 @@ static void intel_bsp_resume(struct cpuinfo_x86 *c)
 {
/*
 * MSR_IA32_ENERGY_PERF_BIAS is lost across suspend/resume,
 * so reinitialize it properly like during bootup:
 */
init_intel_energy_perf(c);
 }
 
+static void init_intel_misc_features(struct cpuinfo_x86 *c)
+{
+   u64 msr;
+
+   if (!rdmsrl_safe(MSR_PLATFORM_INFO, )) {
+   if (msr & MSR_PLATFORM_INFO_CPUID_FAULT)
+   set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
+   }
+
+   probe_xeon_phi_r3mwait(c);
+}
+
 static void init_intel(struct cpuinfo_x86 *c)
 {
unsigned int l2 = 0;
 
early_init_intel(c);
 
intel_workarounds(c);
 
@@ -597,17 +609,17 @@ static void init_intel(struct cpuinfo_x86 *c)
/* Work around errata */
srat_detect_node(c);
 
if (cpu_has(c, X86_FEATURE_VMX))
detect_vmx_virtcap(c);
 
init_intel_energy_perf(c);
 
-   probe_xeon_phi_r3mwait(c);
+   init_intel_misc_features(c);
 }
 
 #ifdef CONFIG_X86_32
 static unsigned int intel_size_cache(struct cpuinfo_x86 *c, unsigned int size)
 {
/*
 * Intel PIII Tualatin. This comes in two flavours.
 * One has 256kb of cache, the other 512. We have no way
-- 
2.11.0

[PATCH v15 0/9] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

[Kyle Huey]

rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by providing constant results.

Newer Intel CPUs (Ivy Bridge and later) can fault when CPUID is executed at
CPL > 0. Expose this capability to userspace as a new pair of arch_prctls,
ARCH_GET_CPUID and ARCH_SET_CPUID.

Since v14:
All: rebased onto x86/process, which contains the switch_to_xtra
improvements

Patch 4: x86/syscalls/32: Wire up arch_prctl on x86-32
- the new arch_prctl is now syscall number 384, because that was
  available

Patch 5: x86/cpufeature: Detect CPUID faulting support
- the newly added probe_xeon_phi_r3mwait is called from
  init_intel_misc_features

[PATCH v15 5/9] x86/cpufeature: Detect CPUID faulting support

[Kyle Huey]

Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
When enabled, the processor will fault on attempts to execute the CPUID
instruction with CPL>0. This will allow a ptracer to emulate the CPUID
instruction.

Bit 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
documented in detail in Section 2.3.2 of
https://bugzilla.kernel.org/attachment.cgi?id=243991

Detect support for this feature and expose it as X86_FEATURE_CPUID_FAULT.

Signed-off-by: Kyle Huey 
Reviewed-by: Borislav Petkov 
---
 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/include/asm/msr-index.h   |  2 ++
 arch/x86/kernel/cpu/intel.c| 14 +-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index b04bb6dfed7f..0fe00446f9ca 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -182,16 +182,17 @@
 
 /*
  * Auxiliary flags: Linux defined - For features scattered in various
  * CPUID levels like 0x6, 0xA etc, word 7.
  *
  * Reuse free bits when adding new feature flags!
  */
 #define X86_FEATURE_RING3MWAIT ( 7*32+ 0) /* Ring 3 MONITOR/MWAIT */
+#define X86_FEATURE_CPUID_FAULT ( 7*32+ 1) /* Intel CPUID faulting */
 #define X86_FEATURE_CPB( 7*32+ 2) /* AMD Core Performance 
Boost */
 #define X86_FEATURE_EPB( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS 
support */
 #define X86_FEATURE_CAT_L3 ( 7*32+ 4) /* Cache Allocation Technology L3 */
 #define X86_FEATURE_CAT_L2 ( 7*32+ 5) /* Cache Allocation Technology L2 */
 #define X86_FEATURE_CDP_L3 ( 7*32+ 6) /* Code and Data Prioritization L3 */
 
 #define X86_FEATURE_HW_PSTATE  ( 7*32+ 8) /* AMD HW-PState */
 #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 4c928f332f8f..33524291b708 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -40,16 +40,18 @@
 
 #define MSR_PPIN_CTL   0x004e
 #define MSR_PPIN   0x004f
 
 #define MSR_IA32_PERFCTR0  0x00c1
 #define MSR_IA32_PERFCTR1  0x00c2
 #define MSR_FSB_FREQ   0x00cd
 #define MSR_PLATFORM_INFO  0x00ce
+#define MSR_PLATFORM_INFO_CPUID_FAULT_BIT  31
+#define MSR_PLATFORM_INFO_CPUID_FAULT  
BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
 
 #define MSR_PKG_CST_CONFIG_CONTROL 0x00e2
 #define NHM_C3_AUTO_DEMOTE (1UL << 25)
 #define NHM_C1_AUTO_DEMOTE (1UL << 26)
 #define ATM_LNC_C6_AUTO_DEMOTE (1UL << 25)
 #define SNB_C1_AUTO_UNDEMOTE   (1UL << 27)
 #define SNB_C3_AUTO_UNDEMOTE   (1UL << 28)
 
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 063197771b8d..e006c6b54cad 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -483,16 +483,28 @@ static void intel_bsp_resume(struct cpuinfo_x86 *c)
 {
/*
 * MSR_IA32_ENERGY_PERF_BIAS is lost across suspend/resume,
 * so reinitialize it properly like during bootup:
 */
init_intel_energy_perf(c);
 }
 
+static void init_intel_misc_features(struct cpuinfo_x86 *c)
+{
+   u64 msr;
+
+   if (!rdmsrl_safe(MSR_PLATFORM_INFO, )) {
+   if (msr & MSR_PLATFORM_INFO_CPUID_FAULT)
+   set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
+   }
+
+   probe_xeon_phi_r3mwait(c);
+}
+
 static void init_intel(struct cpuinfo_x86 *c)
 {
unsigned int l2 = 0;
 
early_init_intel(c);
 
intel_workarounds(c);
 
@@ -597,17 +609,17 @@ static void init_intel(struct cpuinfo_x86 *c)
/* Work around errata */
srat_detect_node(c);
 
if (cpu_has(c, X86_FEATURE_VMX))
detect_vmx_virtcap(c);
 
init_intel_energy_perf(c);
 
-   probe_xeon_phi_r3mwait(c);
+   init_intel_misc_features(c);
 }
 
 #ifdef CONFIG_X86_32
 static unsigned int intel_size_cache(struct cpuinfo_x86 *c, unsigned int size)
 {
/*
 * Intel PIII Tualatin. This comes in two flavours.
 * One has 256kb of cache, the other 512. We have no way
-- 
2.11.0

[PATCH v15 2/9] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64

[Kyle Huey]

In order to introduce new arch_prctls that are not 64 bit only, rename the
existing 64 bit implementation to do_arch_prctl_64(). Also rename the second
argument to arch_prctl(), which will no longer always be an address.

Signed-off-by: Kyle Huey 
Reviewed-by: Andy Lutomirski 
---
 arch/um/include/shared/os.h  |  2 +-
 arch/x86/include/asm/proto.h |  3 +--
 arch/x86/kernel/process_64.c | 32 +---
 arch/x86/kernel/ptrace.c |  8 
 arch/x86/um/os-Linux/prctl.c |  4 ++--
 arch/x86/um/syscalls_64.c| 12 ++--
 6 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index de5d572225f3..2b47e0e8d414 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -298,17 +298,17 @@ extern void os_set_ioignore(void);
 
 /* sigio.c */
 extern int add_sigio_fd(int fd);
 extern int ignore_sigio_fd(int fd);
 extern void maybe_sigio_broken(int fd, int read);
 extern void sigio_broken(int fd, int read);
 
 /* sys-x86_64/prctl.c */
-extern int os_arch_prctl(int pid, int code, unsigned long *addr);
+extern int os_arch_prctl(int pid, int code, unsigned long *arg2);
 
 /* tty.c */
 extern int get_pty(void);
 
 /* sys-$ARCH/task_size.c */
 extern unsigned long os_get_top_address(void);
 
 long syscall(long number, ...);
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index 9b9b30b19441..f8e9194e100c 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -4,16 +4,17 @@
 #include 
 
 /* misc architecture specific prototypes */
 
 void syscall_init(void);
 
 #ifdef CONFIG_X86_64
 void entry_SYSCALL_64(void);
+long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2);
 #endif
 
 #ifdef CONFIG_X86_32
 void entry_INT80_32(void);
 void entry_SYSENTER_32(void);
 void __begin_SYSENTER_singlestep_region(void);
 void __end_SYSENTER_singlestep_region(void);
 #endif
@@ -25,11 +26,9 @@ void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
 #endif
 
 void x86_configure_nx(void);
 void x86_report_nx(void);
 
 extern int reboot_force;
 
-long do_arch_prctl(struct task_struct *task, int code, unsigned long addr);
-
 #endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 9a72612b25ee..4c139922c2fb 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -200,17 +200,17 @@ int copy_thread_tls(unsigned long clone_flags, unsigned 
long sp,
 */
if (clone_flags & CLONE_SETTLS) {
 #ifdef CONFIG_IA32_EMULATION
if (in_ia32_syscall())
err = do_set_thread_area(p, -1,
(struct user_desc __user *)tls, 0);
else
 #endif
-   err = do_arch_prctl(p, ARCH_SET_FS, tls);
+   err = do_arch_prctl_64(p, ARCH_SET_FS, tls);
if (err)
goto out;
}
err = 0;
 out:
if (err && p->thread.io_bitmap_ptr) {
kfree(p->thread.io_bitmap_ptr);
p->thread.io_bitmap_max = 0;
@@ -543,91 +543,93 @@ static long prctl_map_vdso(const struct vdso_image 
*image, unsigned long addr)
ret = map_vdso_once(image, addr);
if (ret)
return ret;
 
return (long)image->size;
 }
 #endif
 
-long do_arch_prctl(struct task_struct *task, int code, unsigned long addr)
+long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2)
 {
int ret = 0;
int doit = task == current;
int cpu;
 
switch (code) {
case ARCH_SET_GS:
-   if (addr >= TASK_SIZE_MAX)
+   if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
cpu = get_cpu();
task->thread.gsindex = 0;
-   task->thread.gsbase = addr;
+   task->thread.gsbase = arg2;
if (doit) {
load_gs_index(0);
-   ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, addr);
+   ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, arg2);
}
put_cpu();
break;
case ARCH_SET_FS:
/* Not strictly needed for fs, but do it for symmetry
   with gs */
-   if (addr >= TASK_SIZE_MAX)
+   if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
cpu = get_cpu();
task->thread.fsindex = 0;
-   task->thread.fsbase = addr;
+   task->thread.fsbase = arg2;
if (doit) {
/* set the selector to 0 to not confuse __switch_to */
loadsegment(fs, 0);
-   ret = wrmsrl_safe(MSR_FS_BASE, addr);
+   ret = wrmsrl_safe(MSR_FS_BASE, arg2);
}
 

[PATCH v15 3/9] x86/arch_prctl: Add do_arch_prctl_common

[Kyle Huey]

Add do_arch_prctl_common() to handle arch_prctls that are not specific to 64
bit mode. Call it from the syscall entry point, but not any of the other
callsites in the kernel, which all want one of the existing 64 bit only
arch_prctls.

Signed-off-by: Kyle Huey 
---
 arch/x86/include/asm/proto.h | 3 +++
 arch/x86/kernel/process.c| 6 ++
 arch/x86/kernel/process_64.c | 8 +++-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index f8e9194e100c..99836d9a893a 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -26,9 +26,12 @@ void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
 #endif
 
 void x86_configure_nx(void);
 void x86_report_nx(void);
 
 extern int reboot_force;
 
+long do_arch_prctl_common(struct task_struct *task, int code,
+ unsigned long cpuid_enabled);
+
 #endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 366db7782fc6..25bf542dfcdd 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -540,8 +540,14 @@ unsigned long get_wchan(struct task_struct *p)
}
fp = READ_ONCE_NOCHECK(*(unsigned long *)fp);
} while (count++ < 16 && p->state != TASK_RUNNING);
 
 out:
put_task_stack(p);
return ret;
 }
+
+long do_arch_prctl_common(struct task_struct *task, int code,
+ unsigned long cpuid_enabled)
+{
+   return -EINVAL;
+}
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 4c139922c2fb..beec7d70acf2 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -621,15 +621,21 @@ long do_arch_prctl_64(struct task_struct *task, int code, 
unsigned long arg2)
break;
}
 
return ret;
 }
 
 SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
 {
-   return do_arch_prctl_64(current, code, arg2);
+   long ret;
+
+   ret = do_arch_prctl_64(current, code, arg2);
+   if (ret == -EINVAL)
+   ret = do_arch_prctl_common(current, code, arg2);
+
+   return ret;
 }
 
 unsigned long KSTK_ESP(struct task_struct *task)
 {
return task_pt_regs(task)->sp;
 }
-- 
2.11.0

[PATCH v15 2/9] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64

[Kyle Huey]

In order to introduce new arch_prctls that are not 64 bit only, rename the
existing 64 bit implementation to do_arch_prctl_64(). Also rename the second
argument to arch_prctl(), which will no longer always be an address.

Signed-off-by: Kyle Huey 
Reviewed-by: Andy Lutomirski 
---
 arch/um/include/shared/os.h  |  2 +-
 arch/x86/include/asm/proto.h |  3 +--
 arch/x86/kernel/process_64.c | 32 +---
 arch/x86/kernel/ptrace.c |  8 
 arch/x86/um/os-Linux/prctl.c |  4 ++--
 arch/x86/um/syscalls_64.c| 12 ++--
 6 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/arch/um/include/shared/os.h b/arch/um/include/shared/os.h
index de5d572225f3..2b47e0e8d414 100644
--- a/arch/um/include/shared/os.h
+++ b/arch/um/include/shared/os.h
@@ -298,17 +298,17 @@ extern void os_set_ioignore(void);
 
 /* sigio.c */
 extern int add_sigio_fd(int fd);
 extern int ignore_sigio_fd(int fd);
 extern void maybe_sigio_broken(int fd, int read);
 extern void sigio_broken(int fd, int read);
 
 /* sys-x86_64/prctl.c */
-extern int os_arch_prctl(int pid, int code, unsigned long *addr);
+extern int os_arch_prctl(int pid, int code, unsigned long *arg2);
 
 /* tty.c */
 extern int get_pty(void);
 
 /* sys-$ARCH/task_size.c */
 extern unsigned long os_get_top_address(void);
 
 long syscall(long number, ...);
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index 9b9b30b19441..f8e9194e100c 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -4,16 +4,17 @@
 #include 
 
 /* misc architecture specific prototypes */
 
 void syscall_init(void);
 
 #ifdef CONFIG_X86_64
 void entry_SYSCALL_64(void);
+long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2);
 #endif
 
 #ifdef CONFIG_X86_32
 void entry_INT80_32(void);
 void entry_SYSENTER_32(void);
 void __begin_SYSENTER_singlestep_region(void);
 void __end_SYSENTER_singlestep_region(void);
 #endif
@@ -25,11 +26,9 @@ void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
 #endif
 
 void x86_configure_nx(void);
 void x86_report_nx(void);
 
 extern int reboot_force;
 
-long do_arch_prctl(struct task_struct *task, int code, unsigned long addr);
-
 #endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 9a72612b25ee..4c139922c2fb 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -200,17 +200,17 @@ int copy_thread_tls(unsigned long clone_flags, unsigned 
long sp,
 */
if (clone_flags & CLONE_SETTLS) {
 #ifdef CONFIG_IA32_EMULATION
if (in_ia32_syscall())
err = do_set_thread_area(p, -1,
(struct user_desc __user *)tls, 0);
else
 #endif
-   err = do_arch_prctl(p, ARCH_SET_FS, tls);
+   err = do_arch_prctl_64(p, ARCH_SET_FS, tls);
if (err)
goto out;
}
err = 0;
 out:
if (err && p->thread.io_bitmap_ptr) {
kfree(p->thread.io_bitmap_ptr);
p->thread.io_bitmap_max = 0;
@@ -543,91 +543,93 @@ static long prctl_map_vdso(const struct vdso_image 
*image, unsigned long addr)
ret = map_vdso_once(image, addr);
if (ret)
return ret;
 
return (long)image->size;
 }
 #endif
 
-long do_arch_prctl(struct task_struct *task, int code, unsigned long addr)
+long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2)
 {
int ret = 0;
int doit = task == current;
int cpu;
 
switch (code) {
case ARCH_SET_GS:
-   if (addr >= TASK_SIZE_MAX)
+   if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
cpu = get_cpu();
task->thread.gsindex = 0;
-   task->thread.gsbase = addr;
+   task->thread.gsbase = arg2;
if (doit) {
load_gs_index(0);
-   ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, addr);
+   ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, arg2);
}
put_cpu();
break;
case ARCH_SET_FS:
/* Not strictly needed for fs, but do it for symmetry
   with gs */
-   if (addr >= TASK_SIZE_MAX)
+   if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
cpu = get_cpu();
task->thread.fsindex = 0;
-   task->thread.fsbase = addr;
+   task->thread.fsbase = arg2;
if (doit) {
/* set the selector to 0 to not confuse __switch_to */
loadsegment(fs, 0);
-   ret = wrmsrl_safe(MSR_FS_BASE, addr);
+   ret = wrmsrl_safe(MSR_FS_BASE, arg2);
}
put_cpu();
   

[PATCH v15 3/9] x86/arch_prctl: Add do_arch_prctl_common

[Kyle Huey]

Add do_arch_prctl_common() to handle arch_prctls that are not specific to 64
bit mode. Call it from the syscall entry point, but not any of the other
callsites in the kernel, which all want one of the existing 64 bit only
arch_prctls.

Signed-off-by: Kyle Huey 
---
 arch/x86/include/asm/proto.h | 3 +++
 arch/x86/kernel/process.c| 6 ++
 arch/x86/kernel/process_64.c | 8 +++-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index f8e9194e100c..99836d9a893a 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -26,9 +26,12 @@ void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
 #endif
 
 void x86_configure_nx(void);
 void x86_report_nx(void);
 
 extern int reboot_force;
 
+long do_arch_prctl_common(struct task_struct *task, int code,
+ unsigned long cpuid_enabled);
+
 #endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 366db7782fc6..25bf542dfcdd 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -540,8 +540,14 @@ unsigned long get_wchan(struct task_struct *p)
}
fp = READ_ONCE_NOCHECK(*(unsigned long *)fp);
} while (count++ < 16 && p->state != TASK_RUNNING);
 
 out:
put_task_stack(p);
return ret;
 }
+
+long do_arch_prctl_common(struct task_struct *task, int code,
+ unsigned long cpuid_enabled)
+{
+   return -EINVAL;
+}
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 4c139922c2fb..beec7d70acf2 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -621,15 +621,21 @@ long do_arch_prctl_64(struct task_struct *task, int code, 
unsigned long arg2)
break;
}
 
return ret;
 }
 
 SYSCALL_DEFINE2(arch_prctl, int, code, unsigned long, arg2)
 {
-   return do_arch_prctl_64(current, code, arg2);
+   long ret;
+
+   ret = do_arch_prctl_64(current, code, arg2);
+   if (ret == -EINVAL)
+   ret = do_arch_prctl_common(current, code, arg2);
+
+   return ret;
 }
 
 unsigned long KSTK_ESP(struct task_struct *task)
 {
return task_pt_regs(task)->sp;
 }
-- 
2.11.0

[PATCH] staging: atomisp: clean up return logic, remove redunant code

[Colin King]

From: Colin Ian King 

There is no need to check if ret is non-zero, remove this
redundant check and just return the error status from the call
to mt9m114_write_reg_array.

Detected by CoverityScan, CID#1416577 ("Identical code for
different branches")

Signed-off-by: Colin Ian King 
---
 drivers/staging/media/atomisp/i2c/mt9m114.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c 
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index 8762124..a555aec 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -444,12 +444,8 @@ static int mt9m114_set_suspend(struct v4l2_subdev *sd)
 static int mt9m114_init_common(struct v4l2_subdev *sd)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
-   int ret;
 
-   ret = mt9m114_write_reg_array(client, mt9m114_common, PRE_POLLING);
-   if (ret)
-   return ret;
-   return ret;
+   return mt9m114_write_reg_array(client, mt9m114_common, PRE_POLLING);
 }
 
 static int power_ctrl(struct v4l2_subdev *sd, bool flag)
-- 
2.10.2

[PATCH] staging: atomisp: clean up return logic, remove redunant code

[Colin King]

From: Colin Ian King 

There is no need to check if ret is non-zero, remove this
redundant check and just return the error status from the call
to mt9m114_write_reg_array.

Detected by CoverityScan, CID#1416577 ("Identical code for
different branches")

Signed-off-by: Colin Ian King 
---
 drivers/staging/media/atomisp/i2c/mt9m114.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.c 
b/drivers/staging/media/atomisp/i2c/mt9m114.c
index 8762124..a555aec 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.c
@@ -444,12 +444,8 @@ static int mt9m114_set_suspend(struct v4l2_subdev *sd)
 static int mt9m114_init_common(struct v4l2_subdev *sd)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
-   int ret;
 
-   ret = mt9m114_write_reg_array(client, mt9m114_common, PRE_POLLING);
-   if (ret)
-   return ret;
-   return ret;
+   return mt9m114_write_reg_array(client, mt9m114_common, PRE_POLLING);
 }
 
 static int power_ctrl(struct v4l2_subdev *sd, bool flag)
-- 
2.10.2

Re: [PATCH] statx: optimize copy of struct statx to userspace

[David Howells]

Eric Biggers  wrote:

> From: Eric Biggers 
> 
> I found that statx() was significantly slower than stat().  As a
> microbenchmark, I compared 10,000,000 invocations of fstat() on a tmpfs
> file to the same with statx() passed a NULL path:
> 
>   $ time ./stat_benchmark
> 
>   real0m1.464s
>   user0m0.275s
>   sys 0m1.187s
> 
>   $ time ./statx_benchmark
> 
>   real0m5.530s
>   user0m0.281s
>   sys 0m5.247s
> 
> statx is expected to be a little slower than stat because struct statx
> is larger than struct stat, but not by *that* much.  It turns out that
> most of the overhead was in copying struct statx to userspace,
> apparently mostly in all the stac/clac instructions that got generated
> for each __put_user() call.  (This was on x86_64, but some other
> architectures, e.g. arm64, have something similar now too.)
> 
> stat() instead initializes its struct on the stack and copies it to
> userspace with a single call to copy_to_user().  This turns out to be
> much faster, and changing statx to do this makes it almost as fast as
> stat:
> 
>   $ time ./statx_benchmark
> 
>   real0m1.573s
>   user0m0.229s
>   sys 0m1.344s
> 
> Signed-off-by: Eric Biggers 

Acked-by: David Howells 

Re: [PATCH] statx: optimize copy of struct statx to userspace

[David Howells]

Eric Biggers  wrote:

> From: Eric Biggers 
> 
> I found that statx() was significantly slower than stat().  As a
> microbenchmark, I compared 10,000,000 invocations of fstat() on a tmpfs
> file to the same with statx() passed a NULL path:
> 
>   $ time ./stat_benchmark
> 
>   real0m1.464s
>   user0m0.275s
>   sys 0m1.187s
> 
>   $ time ./statx_benchmark
> 
>   real0m5.530s
>   user0m0.281s
>   sys 0m5.247s
> 
> statx is expected to be a little slower than stat because struct statx
> is larger than struct stat, but not by *that* much.  It turns out that
> most of the overhead was in copying struct statx to userspace,
> apparently mostly in all the stac/clac instructions that got generated
> for each __put_user() call.  (This was on x86_64, but some other
> architectures, e.g. arm64, have something similar now too.)
> 
> stat() instead initializes its struct on the stack and copies it to
> userspace with a single call to copy_to_user().  This turns out to be
> much faster, and changing statx to do this makes it almost as fast as
> stat:
> 
>   $ time ./statx_benchmark
> 
>   real0m1.573s
>   user0m0.229s
>   sys 0m1.344s
> 
> Signed-off-by: Eric Biggers 

Acked-by: David Howells 

Re: [PATCH] statx: remove incorrect part of vfs_statx() comment

[David Howells]

Eric Biggers  wrote:

> From: Eric Biggers 
> 
> request_mask and query_flags are function arguments, not passed in
> struct kstat.  So remove the part of the comment which claims otherwise.
> This was apparently left over from an earlier version of the statx
> patch.
> 
> Signed-off-by: Eric Biggers 

Acked-by: David Howells 

Re: [PATCH] statx: remove incorrect part of vfs_statx() comment

[David Howells]

Eric Biggers  wrote:

> From: Eric Biggers 
> 
> request_mask and query_flags are function arguments, not passed in
> struct kstat.  So remove the part of the comment which claims otherwise.
> This was apparently left over from an earlier version of the statx
> patch.
> 
> Signed-off-by: Eric Biggers 

Acked-by: David Howells 

[PATCH] ASoC: cs35l35: trivial fix to indentation

[Colin King]

From: Colin Ian King 

Remove extraneous tab to correct the nesting level indentation

Detected by CoverityScan, CID#1416584 ("Nesting level does
not match indentation")

Signed-off-by: Colin Ian King 
---
 sound/soc/codecs/cs35l35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/cs35l35.c b/sound/soc/codecs/cs35l35.c
index 260ed42..43d33f4 100644
--- a/sound/soc/codecs/cs35l35.c
+++ b/sound/soc/codecs/cs35l35.c
@@ -1370,7 +1370,8 @@ static int cs35l35_i2c_probe(struct i2c_client 
*i2c_client,
 
for (i = 0; i < ARRAY_SIZE(cs35l35_supplies); i++)
cs35l35->supplies[i].supply = cs35l35_supplies[i];
-   cs35l35->num_supplies = ARRAY_SIZE(cs35l35_supplies);
+
+   cs35l35->num_supplies = ARRAY_SIZE(cs35l35_supplies);
 
ret = devm_regulator_bulk_get(_client->dev,
cs35l35->num_supplies,
-- 
2.10.2

[PATCH] ASoC: cs35l35: trivial fix to indentation

[Colin King]

From: Colin Ian King 

Remove extraneous tab to correct the nesting level indentation

Detected by CoverityScan, CID#1416584 ("Nesting level does
not match indentation")

Signed-off-by: Colin Ian King 
---
 sound/soc/codecs/cs35l35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/cs35l35.c b/sound/soc/codecs/cs35l35.c
index 260ed42..43d33f4 100644
--- a/sound/soc/codecs/cs35l35.c
+++ b/sound/soc/codecs/cs35l35.c
@@ -1370,7 +1370,8 @@ static int cs35l35_i2c_probe(struct i2c_client 
*i2c_client,
 
for (i = 0; i < ARRAY_SIZE(cs35l35_supplies); i++)
cs35l35->supplies[i].supply = cs35l35_supplies[i];
-   cs35l35->num_supplies = ARRAY_SIZE(cs35l35_supplies);
+
+   cs35l35->num_supplies = ARRAY_SIZE(cs35l35_supplies);
 
ret = devm_regulator_bulk_get(_client->dev,
cs35l35->num_supplies,
-- 
2.10.2

[GIT PULL] KVM fixes for 4.11-rc2

[Radim Krčmář]

Linus,

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

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

for you to fetch changes up to 6a29b512cf1ebc2ceff6dbc1a256dbde3e259a2b:

  Merge tag 'kvm-arm-for-4.11-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm (2017-03-09 
15:48:42 +0100)


KVM fixes for v4.11-rc2

ARM updates from Marc Zyngier:
 "vgic updates:
  - Honour disabling the ITS
  - Don't deadlock when deactivating own interrupts via MMIO
  - Correctly expose the lact of IRQ/FIQ bypass on GICv3

  I/O virtualization:
  - Make KVM_CAP_NR_MEMSLOTS big enough for large guests with
many PCIe devices

  General bug fixes:
  - Gracefully handle exception generated with syndroms that
the host doesn't understand
  - Properly invalidate TLBs on VHE systems"

x86:
 - improvements in emulation of VMCLEAR, VMX MSR bitmaps, and VCPU reset


Andre Przywara (1):
  KVM: arm/arm64: VGIC: Fix command handling while ITS being disabled

Jim Mattson (1):
  kvm: nVMX: VMCLEAR should not cause the vCPU to shut down

Jintack Lim (1):
  KVM: arm/arm64: Let vcpu thread modify its own active state

Linu Cherian (4):
  KVM: Add documentation for KVM_CAP_NR_MEMSLOTS
  KVM: arm/arm64: Enable KVM_CAP_NR_MEMSLOTS on arm/arm64
  KVM: arm/arm64: Remove KVM_PRIVATE_MEM_SLOTS definition that are unused
  KVM: arm64: Increase number of user memslots to 512

Marc Zyngier (2):
  arm64: KVM: VHE: Clear HCR_TGE when invalidating guest TLBs
  KVM: arm/arm64: vgic-v3: Don't pretend to support IRQ/FIQ bypass

Mark Rutland (2):
  arm: KVM: Survive unknown traps from guests
  arm64: KVM: Survive unknown traps from guests

Radim Krčmář (2):
  KVM: nVMX: do not warn when MSR bitmap address is not backed
  Merge tag 'kvm-arm-for-4.11-rc2' of git://git.kernel.org/.../kvmarm/kvmarm

Wanpeng Li (1):
  KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset

 Documentation/virtual/kvm/api.txt  |   4 ++
 arch/arm/include/asm/kvm_arm.h |   1 +
 arch/arm/include/asm/kvm_host.h|   1 -
 arch/arm/kvm/arm.c |   3 +
 arch/arm/kvm/handle_exit.c |  19 ---
 arch/arm64/include/asm/kvm_host.h  |   3 +-
 arch/arm64/kvm/handle_exit.c   |  19 ---
 arch/arm64/kvm/hyp/tlb.c   |  64 +++---
 arch/x86/kvm/vmx.c |  30 +++---
 include/linux/irqchip/arm-gic-v3.h |   2 +
 virt/kvm/arm/vgic/vgic-its.c   | 109 ++---
 virt/kvm/arm/vgic/vgic-mmio.c  |  32 ---
 virt/kvm/arm/vgic/vgic-v3.c|   5 +-
 13 files changed, 191 insertions(+), 101 deletions(-)

[GIT PULL] KVM fixes for 4.11-rc2

[Radim Krčmář]

Linus,

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

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

for you to fetch changes up to 6a29b512cf1ebc2ceff6dbc1a256dbde3e259a2b:

  Merge tag 'kvm-arm-for-4.11-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm (2017-03-09 
15:48:42 +0100)


KVM fixes for v4.11-rc2

ARM updates from Marc Zyngier:
 "vgic updates:
  - Honour disabling the ITS
  - Don't deadlock when deactivating own interrupts via MMIO
  - Correctly expose the lact of IRQ/FIQ bypass on GICv3

  I/O virtualization:
  - Make KVM_CAP_NR_MEMSLOTS big enough for large guests with
many PCIe devices

  General bug fixes:
  - Gracefully handle exception generated with syndroms that
the host doesn't understand
  - Properly invalidate TLBs on VHE systems"

x86:
 - improvements in emulation of VMCLEAR, VMX MSR bitmaps, and VCPU reset


Andre Przywara (1):
  KVM: arm/arm64: VGIC: Fix command handling while ITS being disabled

Jim Mattson (1):
  kvm: nVMX: VMCLEAR should not cause the vCPU to shut down

Jintack Lim (1):
  KVM: arm/arm64: Let vcpu thread modify its own active state

Linu Cherian (4):
  KVM: Add documentation for KVM_CAP_NR_MEMSLOTS
  KVM: arm/arm64: Enable KVM_CAP_NR_MEMSLOTS on arm/arm64
  KVM: arm/arm64: Remove KVM_PRIVATE_MEM_SLOTS definition that are unused
  KVM: arm64: Increase number of user memslots to 512

Marc Zyngier (2):
  arm64: KVM: VHE: Clear HCR_TGE when invalidating guest TLBs
  KVM: arm/arm64: vgic-v3: Don't pretend to support IRQ/FIQ bypass

Mark Rutland (2):
  arm: KVM: Survive unknown traps from guests
  arm64: KVM: Survive unknown traps from guests

Radim Krčmář (2):
  KVM: nVMX: do not warn when MSR bitmap address is not backed
  Merge tag 'kvm-arm-for-4.11-rc2' of git://git.kernel.org/.../kvmarm/kvmarm

Wanpeng Li (1):
  KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset

 Documentation/virtual/kvm/api.txt  |   4 ++
 arch/arm/include/asm/kvm_arm.h |   1 +
 arch/arm/include/asm/kvm_host.h|   1 -
 arch/arm/kvm/arm.c |   3 +
 arch/arm/kvm/handle_exit.c |  19 ---
 arch/arm64/include/asm/kvm_host.h  |   3 +-
 arch/arm64/kvm/handle_exit.c   |  19 ---
 arch/arm64/kvm/hyp/tlb.c   |  64 +++---
 arch/x86/kvm/vmx.c |  30 +++---
 include/linux/irqchip/arm-gic-v3.h |   2 +
 virt/kvm/arm/vgic/vgic-its.c   | 109 ++---
 virt/kvm/arm/vgic/vgic-mmio.c  |  32 ---
 virt/kvm/arm/vgic/vgic-v3.c|   5 +-
 13 files changed, 191 insertions(+), 101 deletions(-)

[PATCH] dm cache: handle kmalloc failure allocating background_tracker struct

[Colin King]

From: Colin Ian King 

currently there is no kmalloc failure check on the allocation of
the background_tracker struct variable b, and so a null return
will lead to a null pointer deference error. Add null check and move
the failure debug message and NULL return so that the two allocation
errors can share the same error exit path.

Detected by CoverityScan, CID#1416587 ("Dereference null return value")

Signed-off-by: Colin Ian King 
---
 drivers/md/dm-cache-background-tracker.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm-cache-background-tracker.c 
b/drivers/md/dm-cache-background-tracker.c
index 9b1afdf..d27edbcc 100644
--- a/drivers/md/dm-cache-background-tracker.c
+++ b/drivers/md/dm-cache-background-tracker.c
@@ -33,6 +33,8 @@ struct background_tracker *btracker_create(unsigned max_work)
 {
struct background_tracker *b = kmalloc(sizeof(*b), GFP_KERNEL);
 
+   if (!b)
+   goto err;
b->max_work = max_work;
atomic_set(>pending_promotes, 0);
atomic_set(>pending_writebacks, 0);
@@ -44,12 +46,15 @@ struct background_tracker *btracker_create(unsigned 
max_work)
b->pending = RB_ROOT;
b->work_cache = KMEM_CACHE(bt_work, 0);
if (!b->work_cache) {
-   DMERR("couldn't create mempool for background work items");
kfree(b);
-   b = NULL;
+   goto err;
}
 
return b;
+err:
+   DMERR("couldn't create mempool for background work items");
+   return NULL;
+
 }
 EXPORT_SYMBOL_GPL(btracker_create);
 
-- 
2.10.2

[PATCH] dm cache: handle kmalloc failure allocating background_tracker struct

[Colin King]

From: Colin Ian King 

currently there is no kmalloc failure check on the allocation of
the background_tracker struct variable b, and so a null return
will lead to a null pointer deference error. Add null check and move
the failure debug message and NULL return so that the two allocation
errors can share the same error exit path.

Detected by CoverityScan, CID#1416587 ("Dereference null return value")

Signed-off-by: Colin Ian King 
---
 drivers/md/dm-cache-background-tracker.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm-cache-background-tracker.c 
b/drivers/md/dm-cache-background-tracker.c
index 9b1afdf..d27edbcc 100644
--- a/drivers/md/dm-cache-background-tracker.c
+++ b/drivers/md/dm-cache-background-tracker.c
@@ -33,6 +33,8 @@ struct background_tracker *btracker_create(unsigned max_work)
 {
struct background_tracker *b = kmalloc(sizeof(*b), GFP_KERNEL);
 
+   if (!b)
+   goto err;
b->max_work = max_work;
atomic_set(>pending_promotes, 0);
atomic_set(>pending_writebacks, 0);
@@ -44,12 +46,15 @@ struct background_tracker *btracker_create(unsigned 
max_work)
b->pending = RB_ROOT;
b->work_cache = KMEM_CACHE(bt_work, 0);
if (!b->work_cache) {
-   DMERR("couldn't create mempool for background work items");
kfree(b);
-   b = NULL;
+   goto err;
}
 
return b;
+err:
+   DMERR("couldn't create mempool for background work items");
+   return NULL;
+
 }
 EXPORT_SYMBOL_GPL(btracker_create);
 
-- 
2.10.2

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Steve Longerbeam]

On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:

On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:



On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:

I really don't think expecting the user to understand and configure
the pipeline is a sane way forward.  Think about it - should the
user need to know that, because they have a bayer-only CSI data
source, that there is only one path possible, and if they try to
configure a different path, then things will just error out?

For the case of imx219 connected to iMX6, it really is as simple as
"there is only one possible path" and all the complexity of the media
interfaces/subdevs is completely unnecessary.  Every other block in
the graph is just noise.

The fact is that these dot graphs show a complex picture, but reality
is somewhat different - there's only relatively few paths available
depending on the connected source and the rest of the paths are
completely useless.



I totally disagree there. Raw bayer requires passthrough yes, but for
all other media bus formats on a mipi csi-2 bus, and all other media
bus formats on 8-bit parallel buses, the conersion pipelines can be
used for scaling, CSC, rotation, and motion-compensated de-interlacing.


... which only makes sense _if_ your source can produce those formats.
We don't actually disagree on that.

Let me re-state.  If the source can _only_ produce bayer, then there is
_only_ _one_ possible path, and all the overhead of the media controller
stuff is totally unnecessary.

Or, are you going to tell me that the user should have the right to
configure paths through the iMX6 hardware that are not permitted by the
iMX6 manuals for the data format being produced by the sensor?



Russell, I'm not following you. The imx6 pipelines allow for many
different sources, not just the inx219 that only outputs bayer. You
seem to be saying that those other pipelines should not be present
because they don't support raw bayer.

Steve

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Steve Longerbeam]

On 03/11/2017 10:59 AM, Russell King - ARM Linux wrote:

On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:



On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:

I really don't think expecting the user to understand and configure
the pipeline is a sane way forward.  Think about it - should the
user need to know that, because they have a bayer-only CSI data
source, that there is only one path possible, and if they try to
configure a different path, then things will just error out?

For the case of imx219 connected to iMX6, it really is as simple as
"there is only one possible path" and all the complexity of the media
interfaces/subdevs is completely unnecessary.  Every other block in
the graph is just noise.

The fact is that these dot graphs show a complex picture, but reality
is somewhat different - there's only relatively few paths available
depending on the connected source and the rest of the paths are
completely useless.



I totally disagree there. Raw bayer requires passthrough yes, but for
all other media bus formats on a mipi csi-2 bus, and all other media
bus formats on 8-bit parallel buses, the conersion pipelines can be
used for scaling, CSC, rotation, and motion-compensated de-interlacing.


... which only makes sense _if_ your source can produce those formats.
We don't actually disagree on that.

Let me re-state.  If the source can _only_ produce bayer, then there is
_only_ _one_ possible path, and all the overhead of the media controller
stuff is totally unnecessary.

Or, are you going to tell me that the user should have the right to
configure paths through the iMX6 hardware that are not permitted by the
iMX6 manuals for the data format being produced by the sensor?



Russell, I'm not following you. The imx6 pipelines allow for many
different sources, not just the inx219 that only outputs bayer. You
seem to be saying that those other pipelines should not be present
because they don't support raw bayer.

Steve

[PATCH 3/7] regulator: max8660: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops (except max8660_dcdc_ops) are not modified
so can be made const for code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/max8660.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index b87f62dd484e..a6183425f27d 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -194,7 +194,7 @@ static int max8660_ldo5_set_voltage_sel(struct 
regulator_dev *rdev,
return max8660_write(max8660, MAX8660_VCC1, 0xff, 0xc0);
 }
 
-static struct regulator_ops max8660_ldo5_ops = {
+static const struct regulator_ops max8660_ldo5_ops = {
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
.set_voltage_sel = max8660_ldo5_set_voltage_sel,
@@ -252,7 +252,7 @@ static int max8660_ldo67_set_voltage_sel(struct 
regulator_dev *rdev,
 selector << 4);
 }
 
-static struct regulator_ops max8660_ldo67_ops = {
+static const struct regulator_ops max8660_ldo67_ops = {
.is_enabled = max8660_ldo67_is_enabled,
.enable = max8660_ldo67_enable,
.disable = max8660_ldo67_disable,
-- 
2.9.3

[PATCH 3/7] regulator: max8660: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops (except max8660_dcdc_ops) are not modified
so can be made const for code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/max8660.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/max8660.c b/drivers/regulator/max8660.c
index b87f62dd484e..a6183425f27d 100644
--- a/drivers/regulator/max8660.c
+++ b/drivers/regulator/max8660.c
@@ -194,7 +194,7 @@ static int max8660_ldo5_set_voltage_sel(struct 
regulator_dev *rdev,
return max8660_write(max8660, MAX8660_VCC1, 0xff, 0xc0);
 }
 
-static struct regulator_ops max8660_ldo5_ops = {
+static const struct regulator_ops max8660_ldo5_ops = {
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
.set_voltage_sel = max8660_ldo5_set_voltage_sel,
@@ -252,7 +252,7 @@ static int max8660_ldo67_set_voltage_sel(struct 
regulator_dev *rdev,
 selector << 4);
 }
 
-static struct regulator_ops max8660_ldo67_ops = {
+static const struct regulator_ops max8660_ldo67_ops = {
.is_enabled = max8660_ldo67_is_enabled,
.enable = max8660_ldo67_enable,
.disable = max8660_ldo67_disable,
-- 
2.9.3

[PATCH 5/7] regulator: s2mps11: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s2mps11.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index d838e77dd947..7726b874e539 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -238,7 +238,7 @@ static int s2mps11_set_ramp_delay(struct regulator_dev 
*rdev, int ramp_delay)
  1 << enable_shift, 0);
 }
 
-static struct regulator_ops s2mps11_ldo_ops = {
+static const struct regulator_ops s2mps11_ldo_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -249,7 +249,7 @@ static struct regulator_ops s2mps11_ldo_ops = {
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
 };
 
-static struct regulator_ops s2mps11_buck_ops = {
+static const struct regulator_ops s2mps11_buck_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -392,7 +392,7 @@ static const struct regulator_desc s2mps11_regulators[] = {
regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV),
 };
 
-static struct regulator_ops s2mps14_reg_ops;
+static const struct regulator_ops s2mps14_reg_ops;
 
 #define regulator_desc_s2mps13_ldo(num, min, step, min_sel) {  \
.name   = "LDO"#num,\
@@ -599,7 +599,7 @@ static int s2mps14_regulator_set_suspend_disable(struct 
regulator_dev *rdev)
rdev->desc->enable_mask, state);
 }
 
-static struct regulator_ops s2mps14_reg_ops = {
+static const struct regulator_ops s2mps14_reg_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -681,7 +681,7 @@ static const struct regulator_desc s2mps14_regulators[] = {
S2MPS14_BUCK1235_START_SEL),
 };
 
-static struct regulator_ops s2mps15_reg_ldo_ops = {
+static const struct regulator_ops s2mps15_reg_ldo_ops = {
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
.is_enabled = regulator_is_enabled_regmap,
@@ -691,7 +691,7 @@ static struct regulator_ops s2mps15_reg_ldo_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
 };
 
-static struct regulator_ops s2mps15_reg_buck_ops = {
+static const struct regulator_ops s2mps15_reg_buck_ops = {
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
.is_enabled = regulator_is_enabled_regmap,
@@ -886,7 +886,7 @@ static int s2mpu02_set_ramp_delay(struct regulator_dev 
*rdev, int ramp_delay)
  ramp_val << ramp_shift);
 }
 
-static struct regulator_ops s2mpu02_ldo_ops = {
+static const struct regulator_ops s2mpu02_ldo_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -898,7 +898,7 @@ static struct regulator_ops s2mpu02_ldo_ops = {
.set_suspend_disable= s2mps14_regulator_set_suspend_disable,
 };
 
-static struct regulator_ops s2mpu02_buck_ops = {
+static const struct regulator_ops s2mpu02_buck_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
-- 
2.9.3

[PATCH 5/7] regulator: s2mps11: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s2mps11.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index d838e77dd947..7726b874e539 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -238,7 +238,7 @@ static int s2mps11_set_ramp_delay(struct regulator_dev 
*rdev, int ramp_delay)
  1 << enable_shift, 0);
 }
 
-static struct regulator_ops s2mps11_ldo_ops = {
+static const struct regulator_ops s2mps11_ldo_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -249,7 +249,7 @@ static struct regulator_ops s2mps11_ldo_ops = {
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
 };
 
-static struct regulator_ops s2mps11_buck_ops = {
+static const struct regulator_ops s2mps11_buck_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -392,7 +392,7 @@ static const struct regulator_desc s2mps11_regulators[] = {
regulator_desc_s2mps11_buck67810(10, MIN_750_MV, STEP_12_5_MV),
 };
 
-static struct regulator_ops s2mps14_reg_ops;
+static const struct regulator_ops s2mps14_reg_ops;
 
 #define regulator_desc_s2mps13_ldo(num, min, step, min_sel) {  \
.name   = "LDO"#num,\
@@ -599,7 +599,7 @@ static int s2mps14_regulator_set_suspend_disable(struct 
regulator_dev *rdev)
rdev->desc->enable_mask, state);
 }
 
-static struct regulator_ops s2mps14_reg_ops = {
+static const struct regulator_ops s2mps14_reg_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -681,7 +681,7 @@ static const struct regulator_desc s2mps14_regulators[] = {
S2MPS14_BUCK1235_START_SEL),
 };
 
-static struct regulator_ops s2mps15_reg_ldo_ops = {
+static const struct regulator_ops s2mps15_reg_ldo_ops = {
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
.is_enabled = regulator_is_enabled_regmap,
@@ -691,7 +691,7 @@ static struct regulator_ops s2mps15_reg_ldo_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
 };
 
-static struct regulator_ops s2mps15_reg_buck_ops = {
+static const struct regulator_ops s2mps15_reg_buck_ops = {
.list_voltage   = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
.is_enabled = regulator_is_enabled_regmap,
@@ -886,7 +886,7 @@ static int s2mpu02_set_ramp_delay(struct regulator_dev 
*rdev, int ramp_delay)
  ramp_val << ramp_shift);
 }
 
-static struct regulator_ops s2mpu02_ldo_ops = {
+static const struct regulator_ops s2mpu02_ldo_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -898,7 +898,7 @@ static struct regulator_ops s2mpu02_ldo_ops = {
.set_suspend_disable= s2mps14_regulator_set_suspend_disable,
 };
 
-static struct regulator_ops s2mpu02_buck_ops = {
+static const struct regulator_ops s2mpu02_buck_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
-- 
2.9.3

[PATCH 6/7] regulator: s5m8767: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s5m8767.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 27343e1c43ef..383cd7533721 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -357,7 +357,7 @@ static int s5m8767_set_voltage_time_sel(struct 
regulator_dev *rdev,
return 0;
 }
 
-static struct regulator_ops s5m8767_ops = {
+static const struct regulator_ops s5m8767_ops = {
.list_voltage   = regulator_list_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
@@ -367,7 +367,7 @@ static struct regulator_ops s5m8767_ops = {
.set_voltage_time_sel   = s5m8767_set_voltage_time_sel,
 };
 
-static struct regulator_ops s5m8767_buck78_ops = {
+static const struct regulator_ops s5m8767_buck78_ops = {
.list_voltage   = regulator_list_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
-- 
2.9.3

[PATCH 2/7] regulator: max77693: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/max77693-regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/max77693-regulator.c 
b/drivers/regulator/max77693-regulator.c
index 3fce67982682..e7000e777292 100644
--- a/drivers/regulator/max77693-regulator.c
+++ b/drivers/regulator/max77693-regulator.c
@@ -150,7 +150,7 @@ static const struct regulator_ops max77693_safeout_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
 };
 
-static struct regulator_ops max77693_charger_ops = {
+static const struct regulator_ops max77693_charger_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
-- 
2.9.3

[PATCH 4/7] regulator: s2mpa01: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s2mpa01.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index 38ee97a085f9..77db69587f05 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -213,7 +213,7 @@ static int s2mpa01_set_ramp_delay(struct regulator_dev 
*rdev, int ramp_delay)
  1 << enable_shift, 0);
 }
 
-static struct regulator_ops s2mpa01_ldo_ops = {
+static const struct regulator_ops s2mpa01_ldo_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -224,7 +224,7 @@ static struct regulator_ops s2mpa01_ldo_ops = {
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
 };
 
-static struct regulator_ops s2mpa01_buck_ops = {
+static const struct regulator_ops s2mpa01_buck_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
-- 
2.9.3

[PATCH 7/7] regulator: s2mpa01: Fix inconsistent indenting

[Krzysztof Kozlowski]

Broken indenting makes code more difficult to read and brings
confusion. Fix warning reported by Smatch:
s2mpa01.c:362 s2mpa01_pmic_probe() warn: inconsistent indenting

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s2mpa01.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index 77db69587f05..48f0ca90743c 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -359,11 +359,11 @@ static int s2mpa01_pmic_probe(struct platform_device 
*pdev)
if (iodev->dev->of_node) {
reg_np = of_get_child_by_name(iodev->dev->of_node,
"regulators");
-   if (!reg_np) {
-   dev_err(>dev,
-   "could not find regulators sub-node\n");
-   return -EINVAL;
-   }
+   if (!reg_np) {
+   dev_err(>dev,
+   "could not find regulators sub-node\n");
+   return -EINVAL;
+   }
 
of_regulator_match(>dev, reg_np, rdata,
S2MPA01_REGULATOR_MAX);
-- 
2.9.3

[PATCH 6/7] regulator: s5m8767: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s5m8767.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 27343e1c43ef..383cd7533721 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -357,7 +357,7 @@ static int s5m8767_set_voltage_time_sel(struct 
regulator_dev *rdev,
return 0;
 }
 
-static struct regulator_ops s5m8767_ops = {
+static const struct regulator_ops s5m8767_ops = {
.list_voltage   = regulator_list_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
@@ -367,7 +367,7 @@ static struct regulator_ops s5m8767_ops = {
.set_voltage_time_sel   = s5m8767_set_voltage_time_sel,
 };
 
-static struct regulator_ops s5m8767_buck78_ops = {
+static const struct regulator_ops s5m8767_buck78_ops = {
.list_voltage   = regulator_list_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
-- 
2.9.3

[PATCH 2/7] regulator: max77693: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/max77693-regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/max77693-regulator.c 
b/drivers/regulator/max77693-regulator.c
index 3fce67982682..e7000e777292 100644
--- a/drivers/regulator/max77693-regulator.c
+++ b/drivers/regulator/max77693-regulator.c
@@ -150,7 +150,7 @@ static const struct regulator_ops max77693_safeout_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
 };
 
-static struct regulator_ops max77693_charger_ops = {
+static const struct regulator_ops max77693_charger_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
-- 
2.9.3

[PATCH 4/7] regulator: s2mpa01: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s2mpa01.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index 38ee97a085f9..77db69587f05 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -213,7 +213,7 @@ static int s2mpa01_set_ramp_delay(struct regulator_dev 
*rdev, int ramp_delay)
  1 << enable_shift, 0);
 }
 
-static struct regulator_ops s2mpa01_ldo_ops = {
+static const struct regulator_ops s2mpa01_ldo_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
@@ -224,7 +224,7 @@ static struct regulator_ops s2mpa01_ldo_ops = {
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
 };
 
-static struct regulator_ops s2mpa01_buck_ops = {
+static const struct regulator_ops s2mpa01_buck_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
-- 
2.9.3

[PATCH 7/7] regulator: s2mpa01: Fix inconsistent indenting

[Krzysztof Kozlowski]

Broken indenting makes code more difficult to read and brings
confusion. Fix warning reported by Smatch:
s2mpa01.c:362 s2mpa01_pmic_probe() warn: inconsistent indenting

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s2mpa01.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
index 77db69587f05..48f0ca90743c 100644
--- a/drivers/regulator/s2mpa01.c
+++ b/drivers/regulator/s2mpa01.c
@@ -359,11 +359,11 @@ static int s2mpa01_pmic_probe(struct platform_device 
*pdev)
if (iodev->dev->of_node) {
reg_np = of_get_child_by_name(iodev->dev->of_node,
"regulators");
-   if (!reg_np) {
-   dev_err(>dev,
-   "could not find regulators sub-node\n");
-   return -EINVAL;
-   }
+   if (!reg_np) {
+   dev_err(>dev,
+   "could not find regulators sub-node\n");
+   return -EINVAL;
+   }
 
of_regulator_match(>dev, reg_np, rdata,
S2MPA01_REGULATOR_MAX);
-- 
2.9.3

[PATCH 1/7] regulator: max1586: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/max1586.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 2c1228d5796a..6779c2b53674 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -126,14 +126,14 @@ static int max1586_v6_set_voltage_sel(struct 
regulator_dev *rdev,
  * The Maxim 1586 controls V3 and V6 voltages, but offers no way of reading 
back
  * the set up value.
  */
-static struct regulator_ops max1586_v3_ops = {
+static const struct regulator_ops max1586_v3_ops = {
.get_voltage_sel = max1586_v3_get_voltage_sel,
.set_voltage_sel = max1586_v3_set_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
 };
 
-static struct regulator_ops max1586_v6_ops = {
+static const struct regulator_ops max1586_v6_ops = {
.get_voltage_sel = max1586_v6_get_voltage_sel,
.set_voltage_sel = max1586_v6_set_voltage_sel,
.list_voltage = regulator_list_voltage_table,
-- 
2.9.3

[PATCH 1/7] regulator: max1586: Constify regulator_ops

[Krzysztof Kozlowski]

Static struct regulator_ops is not modified so can be made const for
code safeness.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/max1586.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 2c1228d5796a..6779c2b53674 100644
--- a/drivers/regulator/max1586.c
+++ b/drivers/regulator/max1586.c
@@ -126,14 +126,14 @@ static int max1586_v6_set_voltage_sel(struct 
regulator_dev *rdev,
  * The Maxim 1586 controls V3 and V6 voltages, but offers no way of reading 
back
  * the set up value.
  */
-static struct regulator_ops max1586_v3_ops = {
+static const struct regulator_ops max1586_v3_ops = {
.get_voltage_sel = max1586_v3_get_voltage_sel,
.set_voltage_sel = max1586_v3_set_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
 };
 
-static struct regulator_ops max1586_v6_ops = {
+static const struct regulator_ops max1586_v6_ops = {
.get_voltage_sel = max1586_v6_get_voltage_sel,
.set_voltage_sel = max1586_v6_set_voltage_sel,
.list_voltage = regulator_list_voltage_table,
-- 
2.9.3

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Steve Longerbeam]

On 03/11/2017 10:51 AM, Russell King - ARM Linux wrote:

On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote:

On 03/11/2017 03:39 AM, Hans Verkuil wrote:

It's fine to use an internal event as long as the end-user doesn't
see it. But if you lose vsyncs, then you never capture another frame,
right?


No, that's not correct. By loss of vertical sync, I mean the IPU
captures portions of two different frames, resulting in a permanent
"split image", with one frame containing portions of two consecutive
images. Or, the video rolls continuously, if you remember the old CRT
television sets of yore, it's the same rolling effect.


I have seen that rolling effect, but the iMX6 regains correct sync
within one complete "roll" just fine here with IMX219.  However, it
has always recovered.

So, I don't think there's a problem with the iMX6 part of the
processing, and so I don't think we should cripple the iMX6 capture
drivers for this problem.


And there is no crippling going on. Measuring the frame intervals
adds very little overhead.

Steve

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Steve Longerbeam]

On 03/11/2017 10:51 AM, Russell King - ARM Linux wrote:

On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote:

On 03/11/2017 03:39 AM, Hans Verkuil wrote:

It's fine to use an internal event as long as the end-user doesn't
see it. But if you lose vsyncs, then you never capture another frame,
right?


No, that's not correct. By loss of vertical sync, I mean the IPU
captures portions of two different frames, resulting in a permanent
"split image", with one frame containing portions of two consecutive
images. Or, the video rolls continuously, if you remember the old CRT
television sets of yore, it's the same rolling effect.


I have seen that rolling effect, but the iMX6 regains correct sync
within one complete "roll" just fine here with IMX219.  However, it
has always recovered.

So, I don't think there's a problem with the iMX6 part of the
processing, and so I don't think we should cripple the iMX6 capture
drivers for this problem.


And there is no crippling going on. Measuring the frame intervals
adds very little overhead.

Steve

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> 
> 
> On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
> >I really don't think expecting the user to understand and configure
> >the pipeline is a sane way forward.  Think about it - should the
> >user need to know that, because they have a bayer-only CSI data
> >source, that there is only one path possible, and if they try to
> >configure a different path, then things will just error out?
> >
> >For the case of imx219 connected to iMX6, it really is as simple as
> >"there is only one possible path" and all the complexity of the media
> >interfaces/subdevs is completely unnecessary.  Every other block in
> >the graph is just noise.
> >
> >The fact is that these dot graphs show a complex picture, but reality
> >is somewhat different - there's only relatively few paths available
> >depending on the connected source and the rest of the paths are
> >completely useless.
> >
> 
> I totally disagree there. Raw bayer requires passthrough yes, but for
> all other media bus formats on a mipi csi-2 bus, and all other media
> bus formats on 8-bit parallel buses, the conersion pipelines can be
> used for scaling, CSC, rotation, and motion-compensated de-interlacing.

... which only makes sense _if_ your source can produce those formats.
We don't actually disagree on that.

Let me re-state.  If the source can _only_ produce bayer, then there is
_only_ _one_ possible path, and all the overhead of the media controller
stuff is totally unnecessary.

Or, are you going to tell me that the user should have the right to
configure paths through the iMX6 hardware that are not permitted by the
iMX6 manuals for the data format being produced by the sensor?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Sat, Mar 11, 2017 at 10:54:55AM -0800, Steve Longerbeam wrote:
> 
> 
> On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:
> >I really don't think expecting the user to understand and configure
> >the pipeline is a sane way forward.  Think about it - should the
> >user need to know that, because they have a bayer-only CSI data
> >source, that there is only one path possible, and if they try to
> >configure a different path, then things will just error out?
> >
> >For the case of imx219 connected to iMX6, it really is as simple as
> >"there is only one possible path" and all the complexity of the media
> >interfaces/subdevs is completely unnecessary.  Every other block in
> >the graph is just noise.
> >
> >The fact is that these dot graphs show a complex picture, but reality
> >is somewhat different - there's only relatively few paths available
> >depending on the connected source and the rest of the paths are
> >completely useless.
> >
> 
> I totally disagree there. Raw bayer requires passthrough yes, but for
> all other media bus formats on a mipi csi-2 bus, and all other media
> bus formats on 8-bit parallel buses, the conersion pipelines can be
> used for scaling, CSC, rotation, and motion-compensated de-interlacing.

... which only makes sense _if_ your source can produce those formats.
We don't actually disagree on that.

Let me re-state.  If the source can _only_ produce bayer, then there is
_only_ _one_ possible path, and all the overhead of the media controller
stuff is totally unnecessary.

Or, are you going to tell me that the user should have the right to
configure paths through the iMX6 hardware that are not permitted by the
iMX6 manuals for the data format being produced by the sensor?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Steve Longerbeam]

On 03/11/2017 10:51 AM, Russell King - ARM Linux wrote:

On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote:

On 03/11/2017 03:39 AM, Hans Verkuil wrote:

It's fine to use an internal event as long as the end-user doesn't
see it. But if you lose vsyncs, then you never capture another frame,
right?


No, that's not correct. By loss of vertical sync, I mean the IPU
captures portions of two different frames, resulting in a permanent
"split image", with one frame containing portions of two consecutive
images. Or, the video rolls continuously, if you remember the old CRT
television sets of yore, it's the same rolling effect.


I have seen that rolling effect, but the iMX6 regains correct sync
within one complete "roll" just fine here with IMX219.  However, it
has always recovered.


I've seen permanent split images, and rolling that continues for
minutes.




So, I don't think there's a problem with the iMX6 part of the
processing, and so I don't think we should cripple the iMX6 capture
drivers for this problem.

It seems to me that the problem is with the source.


The the problem is almost surely in the CSI. It's handling of the
bt.656 sync codes is broken in some way.

Steve

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Steve Longerbeam]

On 03/11/2017 10:51 AM, Russell King - ARM Linux wrote:

On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote:

On 03/11/2017 03:39 AM, Hans Verkuil wrote:

It's fine to use an internal event as long as the end-user doesn't
see it. But if you lose vsyncs, then you never capture another frame,
right?


No, that's not correct. By loss of vertical sync, I mean the IPU
captures portions of two different frames, resulting in a permanent
"split image", with one frame containing portions of two consecutive
images. Or, the video rolls continuously, if you remember the old CRT
television sets of yore, it's the same rolling effect.


I have seen that rolling effect, but the iMX6 regains correct sync
within one complete "roll" just fine here with IMX219.  However, it
has always recovered.


I've seen permanent split images, and rolling that continues for
minutes.




So, I don't think there's a problem with the iMX6 part of the
processing, and so I don't think we should cripple the iMX6 capture
drivers for this problem.

It seems to me that the problem is with the source.


The the problem is almost surely in the CSI. It's handling of the
bt.656 sync codes is broken in some way.

Steve

Re: [PATCH v1 10/10] staging: iio: gyro: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 18:48, Jonathan Cameron wrote:
> On 11/03/17 14:26, simran singhal wrote:
>> Remove & from function pointers to conform to the style found elsewhere
>> in the file.  Done using the following semantic patch
>>
>> // 
>> @r@
>> identifier f;
>> @@
>>
>> f(...) { ... }
>> @@
>> identifier r.f;
>> @@
>>
>> - 
>> + f
>> // 
>>
>> Signed-off-by: simran singhal 
> Again, I couldn't identify any other function pointers in this file
> so have amended the patch description to reflect that.
> 
> I also added a note that will hopefully prevent anyone seeing
> this patch deciding to send me the several hundred patches it
> 'might' - I haven't checked - take to clean up the whole subsystem.
> 
> Thanks for the whole series.
> 
> Applied to the togreg branhc of iio.git and pushed out as testing.
I spoke to soon. Something odd going on with kernel.org wrt to my
connection to it at least.   Will try to push out again later.

Jonathan
> 
> Jonathan
>> ---
>>  drivers/staging/iio/gyro/adis16060_core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
>> b/drivers/staging/iio/gyro/adis16060_core.c
>> index ab816a2..c9d46e7 100644
>> --- a/drivers/staging/iio/gyro/adis16060_core.c
>> +++ b/drivers/staging/iio/gyro/adis16060_core.c
>> @@ -117,7 +117,7 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>  }
>>  
>>  static const struct iio_info adis16060_info = {
>> -.read_raw = _read_raw,
>> +.read_raw = adis16060_read_raw,
>>  .driver_module = THIS_MODULE,
>>  };
>>  
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v1 10/10] staging: iio: gyro: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 18:48, Jonathan Cameron wrote:
> On 11/03/17 14:26, simran singhal wrote:
>> Remove & from function pointers to conform to the style found elsewhere
>> in the file.  Done using the following semantic patch
>>
>> // 
>> @r@
>> identifier f;
>> @@
>>
>> f(...) { ... }
>> @@
>> identifier r.f;
>> @@
>>
>> - 
>> + f
>> // 
>>
>> Signed-off-by: simran singhal 
> Again, I couldn't identify any other function pointers in this file
> so have amended the patch description to reflect that.
> 
> I also added a note that will hopefully prevent anyone seeing
> this patch deciding to send me the several hundred patches it
> 'might' - I haven't checked - take to clean up the whole subsystem.
> 
> Thanks for the whole series.
> 
> Applied to the togreg branhc of iio.git and pushed out as testing.
I spoke to soon. Something odd going on with kernel.org wrt to my
connection to it at least.   Will try to push out again later.

Jonathan
> 
> Jonathan
>> ---
>>  drivers/staging/iio/gyro/adis16060_core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
>> b/drivers/staging/iio/gyro/adis16060_core.c
>> index ab816a2..c9d46e7 100644
>> --- a/drivers/staging/iio/gyro/adis16060_core.c
>> +++ b/drivers/staging/iio/gyro/adis16060_core.c
>> @@ -117,7 +117,7 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>  }
>>  
>>  static const struct iio_info adis16060_info = {
>> -.read_raw = _read_raw,
>> +.read_raw = adis16060_read_raw,
>>  .driver_module = THIS_MODULE,
>>  };
>>  
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Steve Longerbeam]

On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:

On Sat, Mar 11, 2017 at 10:08:23AM -0800, Steve Longerbeam wrote:

On 03/11/2017 07:32 AM, Sakari Ailus wrote:

Hi Mauro and Hans,

On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote:

Em Sat, 11 Mar 2017 12:32:43 +0100
Hans Verkuil  escreveu:


On 10/03/17 16:09, Mauro Carvalho Chehab wrote:

Em Fri, 10 Mar 2017 13:54:28 +0100
Hans Verkuil  escreveu:


Devices that have complex pipeline that do essentially require using the
Media controller interface to configure them are out of that scope.



Way too much of how the MC devices should be used is in the minds of developers.
There is a major lack for good detailed documentation, utilities, compliance
test (really needed!) and libv4l plugins.


Unfortunately, we merged an incomplete MC support at the Kernel. We knew
all the problems with MC-based drivers and V4L2 applications by the time
it was developed, and we requested Nokia developers (with was sponsoring MC
develoment, on that time) to work on a solution to allow standard V4L2
applications to work with MC based boards.

Unfortunately, we took the decision to merge MC without that, because
Nokia was giving up on Linux development, and we didn't want to lose the
2 years of discussions and work around it, as Nokia employers were leaving
the company. Also, on that time, there was already some patches floating
around adding backward support via libv4l. Unfortunately, those patches
were never finished.

The net result is that MC was merged with some huge gaps, including
the lack of a proper solution for a generic V4L2 program to work
with V4L2 devices that use the subdev API.

That was not that bad by then, as MC was used only on cell phones
that run custom-made applications.

The reallity changed, as now, we have lots of low cost SoC based
boards, used for all sort of purposes. So, we need a quick solution
for it.

In other words, while that would be acceptable support special apps
on really embedded systems, it is *not OK* for general purpose SoC
harware[1].

[1] I'm calling "general purpose SoC harware" those ARM boards
like Raspberry Pi that are shipped to the mass and used by a wide
range of hobbyists and other people that just wants to run Linux on
ARM. It is possible to buy such boards for a very cheap price,
making them to be used not only on special projects, where a custom
made application could be interesting, but also for a lot of
users that just want to run Linux on a low cost ARM board, while
keeping using standard V4L2 apps, like "camorama".

That's perhaps one of the reasons why it took a long time for us to
start receiving drivers upstream for such hardware: it is quite
intimidating and not logical to require developers to implement
on their drivers 2 complex APIs (MC, subdev) for those
hardware that most users won't care. From user's perspective,
being able to support generic applications like "camorama" and
"zbar" is all they want.

In summary, I'm pretty sure we need to support standard V4L2
applications on boards like Raspberry Pi and those low-cost
SoC-based boards that are shipped to end users.


Anyway, regarding this specific patch and for this MC-aware driver: no, you
shouldn't inherit controls from subdevs. It defeats the purpose.


Sorry, but I don't agree with that. The subdev API is an optional API
(and even the MC API can be optional).

I see the rationale for using MC and subdev APIs on cell phones,
ISV and other embedded hardware, as it will allow fine-tuning
the driver's support to allow providing the required quality for
certain custom-made applications. but on general SoC hardware,
supporting standard V4L2 applications is a need.

Ok, perhaps supporting both subdev API and V4L2 API at the same
time doesn't make much sense. We could disable one in favor of the
other, either at compilation time or at runtime.


Right. If the subdev API is disabled, then you have to inherit the subdev
controls in the bridge driver (how else would you be able to access them?).
And that's the usual case.

If you do have the subdev API enabled, AND you use the MC, then the
intention clearly is to give userspace full control and inheriting controls
no longer makes any sense (and is highly confusing IMHO).


I tend to agree with that.


I agree as well.

This is in line with how existing drivers behave, too.


Well, sounds like there is consensus on this topic. I guess I'll
go ahead and remove the control inheritance support. I suppose
having a control appear in two places (subdev and video nodes) can
be confusing.


I would say _don't_ do that until there are tools/libraries in place
that are able to support controlling subdevs, otherwise it's just
going to be another reason for me to walk away from this stuff, and
stick with a version that does work sensibly.


As for the configurability vs. ease-of-use debate, I added the
control inheritance to make it a little easier on the 

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Steve Longerbeam]

On 03/11/2017 10:45 AM, Russell King - ARM Linux wrote:

On Sat, Mar 11, 2017 at 10:08:23AM -0800, Steve Longerbeam wrote:

On 03/11/2017 07:32 AM, Sakari Ailus wrote:

Hi Mauro and Hans,

On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote:

Em Sat, 11 Mar 2017 12:32:43 +0100
Hans Verkuil  escreveu:


On 10/03/17 16:09, Mauro Carvalho Chehab wrote:

Em Fri, 10 Mar 2017 13:54:28 +0100
Hans Verkuil  escreveu:


Devices that have complex pipeline that do essentially require using the
Media controller interface to configure them are out of that scope.



Way too much of how the MC devices should be used is in the minds of developers.
There is a major lack for good detailed documentation, utilities, compliance
test (really needed!) and libv4l plugins.


Unfortunately, we merged an incomplete MC support at the Kernel. We knew
all the problems with MC-based drivers and V4L2 applications by the time
it was developed, and we requested Nokia developers (with was sponsoring MC
develoment, on that time) to work on a solution to allow standard V4L2
applications to work with MC based boards.

Unfortunately, we took the decision to merge MC without that, because
Nokia was giving up on Linux development, and we didn't want to lose the
2 years of discussions and work around it, as Nokia employers were leaving
the company. Also, on that time, there was already some patches floating
around adding backward support via libv4l. Unfortunately, those patches
were never finished.

The net result is that MC was merged with some huge gaps, including
the lack of a proper solution for a generic V4L2 program to work
with V4L2 devices that use the subdev API.

That was not that bad by then, as MC was used only on cell phones
that run custom-made applications.

The reallity changed, as now, we have lots of low cost SoC based
boards, used for all sort of purposes. So, we need a quick solution
for it.

In other words, while that would be acceptable support special apps
on really embedded systems, it is *not OK* for general purpose SoC
harware[1].

[1] I'm calling "general purpose SoC harware" those ARM boards
like Raspberry Pi that are shipped to the mass and used by a wide
range of hobbyists and other people that just wants to run Linux on
ARM. It is possible to buy such boards for a very cheap price,
making them to be used not only on special projects, where a custom
made application could be interesting, but also for a lot of
users that just want to run Linux on a low cost ARM board, while
keeping using standard V4L2 apps, like "camorama".

That's perhaps one of the reasons why it took a long time for us to
start receiving drivers upstream for such hardware: it is quite
intimidating and not logical to require developers to implement
on their drivers 2 complex APIs (MC, subdev) for those
hardware that most users won't care. From user's perspective,
being able to support generic applications like "camorama" and
"zbar" is all they want.

In summary, I'm pretty sure we need to support standard V4L2
applications on boards like Raspberry Pi and those low-cost
SoC-based boards that are shipped to end users.


Anyway, regarding this specific patch and for this MC-aware driver: no, you
shouldn't inherit controls from subdevs. It defeats the purpose.


Sorry, but I don't agree with that. The subdev API is an optional API
(and even the MC API can be optional).

I see the rationale for using MC and subdev APIs on cell phones,
ISV and other embedded hardware, as it will allow fine-tuning
the driver's support to allow providing the required quality for
certain custom-made applications. but on general SoC hardware,
supporting standard V4L2 applications is a need.

Ok, perhaps supporting both subdev API and V4L2 API at the same
time doesn't make much sense. We could disable one in favor of the
other, either at compilation time or at runtime.


Right. If the subdev API is disabled, then you have to inherit the subdev
controls in the bridge driver (how else would you be able to access them?).
And that's the usual case.

If you do have the subdev API enabled, AND you use the MC, then the
intention clearly is to give userspace full control and inheriting controls
no longer makes any sense (and is highly confusing IMHO).


I tend to agree with that.


I agree as well.

This is in line with how existing drivers behave, too.


Well, sounds like there is consensus on this topic. I guess I'll
go ahead and remove the control inheritance support. I suppose
having a control appear in two places (subdev and video nodes) can
be confusing.


I would say _don't_ do that until there are tools/libraries in place
that are able to support controlling subdevs, otherwise it's just
going to be another reason for me to walk away from this stuff, and
stick with a version that does work sensibly.


As for the configurability vs. ease-of-use debate, I added the
control inheritance to make it a little easier on the user, but,
as the dot graphs below will 

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Russell King - ARM Linux]

On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote:
> On 03/11/2017 03:39 AM, Hans Verkuil wrote:
> >It's fine to use an internal event as long as the end-user doesn't
> >see it. But if you lose vsyncs, then you never capture another frame,
> >right?
> 
> No, that's not correct. By loss of vertical sync, I mean the IPU
> captures portions of two different frames, resulting in a permanent
> "split image", with one frame containing portions of two consecutive
> images. Or, the video rolls continuously, if you remember the old CRT
> television sets of yore, it's the same rolling effect.

I have seen that rolling effect, but the iMX6 regains correct sync
within one complete "roll" just fine here with IMX219.  However, it
has always recovered.

So, I don't think there's a problem with the iMX6 part of the
processing, and so I don't think we should cripple the iMX6 capture
drivers for this problem.

It seems to me that the problem is with the source.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Russell King - ARM Linux]

On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote:
> On 03/11/2017 03:39 AM, Hans Verkuil wrote:
> >It's fine to use an internal event as long as the end-user doesn't
> >see it. But if you lose vsyncs, then you never capture another frame,
> >right?
> 
> No, that's not correct. By loss of vertical sync, I mean the IPU
> captures portions of two different frames, resulting in a permanent
> "split image", with one frame containing portions of two consecutive
> images. Or, the video rolls continuously, if you remember the old CRT
> television sets of yore, it's the same rolling effect.

I have seen that rolling effect, but the iMX6 regains correct sync
within one complete "roll" just fine here with IMX219.  However, it
has always recovered.

So, I don't think there's a problem with the iMX6 part of the
processing, and so I don't think we should cripple the iMX6 capture
drivers for this problem.

It seems to me that the problem is with the source.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v1 10/10] staging: iio: gyro: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Again, I couldn't identify any other function pointers in this file
so have amended the patch description to reflect that.

I also added a note that will hopefully prevent anyone seeing
this patch deciding to send me the several hundred patches it
'might' - I haven't checked - take to clean up the whole subsystem.

Thanks for the whole series.

Applied to the togreg branhc of iio.git and pushed out as testing.

Jonathan
> ---
>  drivers/staging/iio/gyro/adis16060_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
> b/drivers/staging/iio/gyro/adis16060_core.c
> index ab816a2..c9d46e7 100644
> --- a/drivers/staging/iio/gyro/adis16060_core.c
> +++ b/drivers/staging/iio/gyro/adis16060_core.c
> @@ -117,7 +117,7 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>  }
>  
>  static const struct iio_info adis16060_info = {
> - .read_raw = _read_raw,
> + .read_raw = adis16060_read_raw,
>   .driver_module = THIS_MODULE,
>  };
>  
> 

Re: [PATCH v1 10/10] staging: iio: gyro: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Again, I couldn't identify any other function pointers in this file
so have amended the patch description to reflect that.

I also added a note that will hopefully prevent anyone seeing
this patch deciding to send me the several hundred patches it
'might' - I haven't checked - take to clean up the whole subsystem.

Thanks for the whole series.

Applied to the togreg branhc of iio.git and pushed out as testing.

Jonathan
> ---
>  drivers/staging/iio/gyro/adis16060_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
> b/drivers/staging/iio/gyro/adis16060_core.c
> index ab816a2..c9d46e7 100644
> --- a/drivers/staging/iio/gyro/adis16060_core.c
> +++ b/drivers/staging/iio/gyro/adis16060_core.c
> @@ -117,7 +117,7 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>  }
>  
>  static const struct iio_info adis16060_info = {
> - .read_raw = _read_raw,
> + .read_raw = adis16060_read_raw,
>   .driver_module = THIS_MODULE,
>  };
>  
> 

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Sat, Mar 11, 2017 at 10:08:23AM -0800, Steve Longerbeam wrote:
> On 03/11/2017 07:32 AM, Sakari Ailus wrote:
> >Hi Mauro and Hans,
> >
> >On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote:
> >>Em Sat, 11 Mar 2017 12:32:43 +0100
> >>Hans Verkuil  escreveu:
> >>
> >>>On 10/03/17 16:09, Mauro Carvalho Chehab wrote:
> Em Fri, 10 Mar 2017 13:54:28 +0100
> Hans Verkuil  escreveu:
> 
> >>Devices that have complex pipeline that do essentially require using the
> >>Media controller interface to configure them are out of that scope.
> >>
> >
> >Way too much of how the MC devices should be used is in the minds of 
> >developers.
> >There is a major lack for good detailed documentation, utilities, 
> >compliance
> >test (really needed!) and libv4l plugins.
> 
> Unfortunately, we merged an incomplete MC support at the Kernel. We knew
> all the problems with MC-based drivers and V4L2 applications by the time
> it was developed, and we requested Nokia developers (with was sponsoring 
> MC
> develoment, on that time) to work on a solution to allow standard V4L2
> applications to work with MC based boards.
> 
> Unfortunately, we took the decision to merge MC without that, because
> Nokia was giving up on Linux development, and we didn't want to lose the
> 2 years of discussions and work around it, as Nokia employers were leaving
> the company. Also, on that time, there was already some patches floating
> around adding backward support via libv4l. Unfortunately, those patches
> were never finished.
> 
> The net result is that MC was merged with some huge gaps, including
> the lack of a proper solution for a generic V4L2 program to work
> with V4L2 devices that use the subdev API.
> 
> That was not that bad by then, as MC was used only on cell phones
> that run custom-made applications.
> 
> The reallity changed, as now, we have lots of low cost SoC based
> boards, used for all sort of purposes. So, we need a quick solution
> for it.
> 
> In other words, while that would be acceptable support special apps
> on really embedded systems, it is *not OK* for general purpose SoC
> harware[1].
> 
> [1] I'm calling "general purpose SoC harware" those ARM boards
> like Raspberry Pi that are shipped to the mass and used by a wide
> range of hobbyists and other people that just wants to run Linux on
> ARM. It is possible to buy such boards for a very cheap price,
> making them to be used not only on special projects, where a custom
> made application could be interesting, but also for a lot of
> users that just want to run Linux on a low cost ARM board, while
> keeping using standard V4L2 apps, like "camorama".
> 
> That's perhaps one of the reasons why it took a long time for us to
> start receiving drivers upstream for such hardware: it is quite
> intimidating and not logical to require developers to implement
> on their drivers 2 complex APIs (MC, subdev) for those
> hardware that most users won't care. From user's perspective,
> being able to support generic applications like "camorama" and
> "zbar" is all they want.
> 
> In summary, I'm pretty sure we need to support standard V4L2
> applications on boards like Raspberry Pi and those low-cost
> SoC-based boards that are shipped to end users.
> 
> >Anyway, regarding this specific patch and for this MC-aware driver: no, 
> >you
> >shouldn't inherit controls from subdevs. It defeats the purpose.
> 
> Sorry, but I don't agree with that. The subdev API is an optional API
> (and even the MC API can be optional).
> 
> I see the rationale for using MC and subdev APIs on cell phones,
> ISV and other embedded hardware, as it will allow fine-tuning
> the driver's support to allow providing the required quality for
> certain custom-made applications. but on general SoC hardware,
> supporting standard V4L2 applications is a need.
> 
> Ok, perhaps supporting both subdev API and V4L2 API at the same
> time doesn't make much sense. We could disable one in favor of the
> other, either at compilation time or at runtime.
> >>>
> >>>Right. If the subdev API is disabled, then you have to inherit the subdev
> >>>controls in the bridge driver (how else would you be able to access them?).
> >>>And that's the usual case.
> >>>
> >>>If you do have the subdev API enabled, AND you use the MC, then the
> >>>intention clearly is to give userspace full control and inheriting controls
> >>>no longer makes any sense (and is highly confusing IMHO).
> >>
> >>I tend to agree with that.
> >
> >I agree as well.
> >
> >This is in line with how existing drivers behave, too.
> 
> Well, sounds like there is consensus on this topic. I guess I'll
> go 

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Sat, Mar 11, 2017 at 10:08:23AM -0800, Steve Longerbeam wrote:
> On 03/11/2017 07:32 AM, Sakari Ailus wrote:
> >Hi Mauro and Hans,
> >
> >On Sat, Mar 11, 2017 at 10:14:08AM -0300, Mauro Carvalho Chehab wrote:
> >>Em Sat, 11 Mar 2017 12:32:43 +0100
> >>Hans Verkuil  escreveu:
> >>
> >>>On 10/03/17 16:09, Mauro Carvalho Chehab wrote:
> Em Fri, 10 Mar 2017 13:54:28 +0100
> Hans Verkuil  escreveu:
> 
> >>Devices that have complex pipeline that do essentially require using the
> >>Media controller interface to configure them are out of that scope.
> >>
> >
> >Way too much of how the MC devices should be used is in the minds of 
> >developers.
> >There is a major lack for good detailed documentation, utilities, 
> >compliance
> >test (really needed!) and libv4l plugins.
> 
> Unfortunately, we merged an incomplete MC support at the Kernel. We knew
> all the problems with MC-based drivers and V4L2 applications by the time
> it was developed, and we requested Nokia developers (with was sponsoring 
> MC
> develoment, on that time) to work on a solution to allow standard V4L2
> applications to work with MC based boards.
> 
> Unfortunately, we took the decision to merge MC without that, because
> Nokia was giving up on Linux development, and we didn't want to lose the
> 2 years of discussions and work around it, as Nokia employers were leaving
> the company. Also, on that time, there was already some patches floating
> around adding backward support via libv4l. Unfortunately, those patches
> were never finished.
> 
> The net result is that MC was merged with some huge gaps, including
> the lack of a proper solution for a generic V4L2 program to work
> with V4L2 devices that use the subdev API.
> 
> That was not that bad by then, as MC was used only on cell phones
> that run custom-made applications.
> 
> The reallity changed, as now, we have lots of low cost SoC based
> boards, used for all sort of purposes. So, we need a quick solution
> for it.
> 
> In other words, while that would be acceptable support special apps
> on really embedded systems, it is *not OK* for general purpose SoC
> harware[1].
> 
> [1] I'm calling "general purpose SoC harware" those ARM boards
> like Raspberry Pi that are shipped to the mass and used by a wide
> range of hobbyists and other people that just wants to run Linux on
> ARM. It is possible to buy such boards for a very cheap price,
> making them to be used not only on special projects, where a custom
> made application could be interesting, but also for a lot of
> users that just want to run Linux on a low cost ARM board, while
> keeping using standard V4L2 apps, like "camorama".
> 
> That's perhaps one of the reasons why it took a long time for us to
> start receiving drivers upstream for such hardware: it is quite
> intimidating and not logical to require developers to implement
> on their drivers 2 complex APIs (MC, subdev) for those
> hardware that most users won't care. From user's perspective,
> being able to support generic applications like "camorama" and
> "zbar" is all they want.
> 
> In summary, I'm pretty sure we need to support standard V4L2
> applications on boards like Raspberry Pi and those low-cost
> SoC-based boards that are shipped to end users.
> 
> >Anyway, regarding this specific patch and for this MC-aware driver: no, 
> >you
> >shouldn't inherit controls from subdevs. It defeats the purpose.
> 
> Sorry, but I don't agree with that. The subdev API is an optional API
> (and even the MC API can be optional).
> 
> I see the rationale for using MC and subdev APIs on cell phones,
> ISV and other embedded hardware, as it will allow fine-tuning
> the driver's support to allow providing the required quality for
> certain custom-made applications. but on general SoC hardware,
> supporting standard V4L2 applications is a need.
> 
> Ok, perhaps supporting both subdev API and V4L2 API at the same
> time doesn't make much sense. We could disable one in favor of the
> other, either at compilation time or at runtime.
> >>>
> >>>Right. If the subdev API is disabled, then you have to inherit the subdev
> >>>controls in the bridge driver (how else would you be able to access them?).
> >>>And that's the usual case.
> >>>
> >>>If you do have the subdev API enabled, AND you use the MC, then the
> >>>intention clearly is to give userspace full control and inheriting controls
> >>>no longer makes any sense (and is highly confusing IMHO).
> >>
> >>I tend to agree with that.
> >
> >I agree as well.
> >
> >This is in line with how existing drivers behave, too.
> 
> Well, sounds like there is consensus on this topic. I guess I'll
> go ahead and remove the control inheritance 

Re: [PATCH v1 05/10] staging: iio: adis16240: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Applied.
> ---
>  drivers/staging/iio/accel/adis16240.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16240.c 
> b/drivers/staging/iio/accel/adis16240.c
> index 27d7f6a..37a29dc 100644
> --- a/drivers/staging/iio/accel/adis16240.c
> +++ b/drivers/staging/iio/accel/adis16240.c
> @@ -373,8 +373,8 @@ static const struct attribute_group 
> adis16240_attribute_group = {
>  
>  static const struct iio_info adis16240_info = {
>   .attrs = _attribute_group,
> - .read_raw = _read_raw,
> - .write_raw = _write_raw,
> + .read_raw = adis16240_read_raw,
> + .write_raw = adis16240_write_raw,
>   .update_scan_mode = adis_update_scan_mode,
>   .driver_module = THIS_MODULE,
>  };
> 

Re: [PATCH v1 05/10] staging: iio: adis16240: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Applied.
> ---
>  drivers/staging/iio/accel/adis16240.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16240.c 
> b/drivers/staging/iio/accel/adis16240.c
> index 27d7f6a..37a29dc 100644
> --- a/drivers/staging/iio/accel/adis16240.c
> +++ b/drivers/staging/iio/accel/adis16240.c
> @@ -373,8 +373,8 @@ static const struct attribute_group 
> adis16240_attribute_group = {
>  
>  static const struct iio_info adis16240_info = {
>   .attrs = _attribute_group,
> - .read_raw = _read_raw,
> - .write_raw = _write_raw,
> + .read_raw = adis16240_read_raw,
> + .write_raw = adis16240_write_raw,
>   .update_scan_mode = adis_update_scan_mode,
>   .driver_module = THIS_MODULE,
>  };
> 

Re: [PATCH v1 09/10] staging: iio: resolver: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Given there aren't any other functional pointers in some the ad2s90
I have amended the patch title to reflect that we are changing
this to have consistency across drivers in the wider subsystem.

Far as I'm concerned, it's nice to tidy up.  I'm not (currently)
advocating a tree wide sweep for these as the churn would be excessive
but it's not a bad thing to do in the staging drivers in my opinion!

Thanks,

Jonathan
> ---
>  drivers/staging/iio/resolver/ad2s1200.c | 2 +-
>  drivers/staging/iio/resolver/ad2s90.c   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/resolver/ad2s1200.c 
> b/drivers/staging/iio/resolver/ad2s1200.c
> index 82b2d88..a37e199 100644
> --- a/drivers/staging/iio/resolver/ad2s1200.c
> +++ b/drivers/staging/iio/resolver/ad2s1200.c
> @@ -97,7 +97,7 @@ static const struct iio_chan_spec ad2s1200_channels[] = {
>  };
>  
>  static const struct iio_info ad2s1200_info = {
> - .read_raw = _read_raw,
> + .read_raw = ad2s1200_read_raw,
>   .driver_module = THIS_MODULE,
>  };
>  
> diff --git a/drivers/staging/iio/resolver/ad2s90.c 
> b/drivers/staging/iio/resolver/ad2s90.c
> index 5b1c0db..b227090 100644
> --- a/drivers/staging/iio/resolver/ad2s90.c
> +++ b/drivers/staging/iio/resolver/ad2s90.c
> @@ -47,7 +47,7 @@ static int ad2s90_read_raw(struct iio_dev *indio_dev,
>  }
>  
>  static const struct iio_info ad2s90_info = {
> - .read_raw = _read_raw,
> + .read_raw = ad2s90_read_raw,
>   .driver_module = THIS_MODULE,
>  };
>  
> 

Re: [PATCH v1 09/10] staging: iio: resolver: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Given there aren't any other functional pointers in some the ad2s90
I have amended the patch title to reflect that we are changing
this to have consistency across drivers in the wider subsystem.

Far as I'm concerned, it's nice to tidy up.  I'm not (currently)
advocating a tree wide sweep for these as the churn would be excessive
but it's not a bad thing to do in the staging drivers in my opinion!

Thanks,

Jonathan
> ---
>  drivers/staging/iio/resolver/ad2s1200.c | 2 +-
>  drivers/staging/iio/resolver/ad2s90.c   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/resolver/ad2s1200.c 
> b/drivers/staging/iio/resolver/ad2s1200.c
> index 82b2d88..a37e199 100644
> --- a/drivers/staging/iio/resolver/ad2s1200.c
> +++ b/drivers/staging/iio/resolver/ad2s1200.c
> @@ -97,7 +97,7 @@ static const struct iio_chan_spec ad2s1200_channels[] = {
>  };
>  
>  static const struct iio_info ad2s1200_info = {
> - .read_raw = _read_raw,
> + .read_raw = ad2s1200_read_raw,
>   .driver_module = THIS_MODULE,
>  };
>  
> diff --git a/drivers/staging/iio/resolver/ad2s90.c 
> b/drivers/staging/iio/resolver/ad2s90.c
> index 5b1c0db..b227090 100644
> --- a/drivers/staging/iio/resolver/ad2s90.c
> +++ b/drivers/staging/iio/resolver/ad2s90.c
> @@ -47,7 +47,7 @@ static int ad2s90_read_raw(struct iio_dev *indio_dev,
>  }
>  
>  static const struct iio_info ad2s90_info = {
> - .read_raw = _read_raw,
> + .read_raw = ad2s90_read_raw,
>   .driver_module = THIS_MODULE,
>  };
>  
> 

[GIT PULL] module.h --> extable.h fixup for arch/score

[Paul Gortmaker]

Linus, please pull to get a small fixup for arch/score.

It seems that Guenter is the only one on the planet doing builds for
arch/score  -- we don't have compile coverage for it in linux-next or in
the kbuild-bot either.  Guenter couldn't even recall where he got his
toolchain, but was kind enough to share it with me so I could validate
this change and also add arch/score to my build coverage.

I sat on this a bit in case there was any other fallout in other arch
dirs, but since this still seems to be the only one, I might as well
send it on its way.

Thanks,
Paul.
---

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git tags/extable-fix

for you to fetch changes up to 0acf611997d9d05dbfb559c3c6e379c861eb5957:

  score: Fix implicit includes now failing build after extable change 
(2017-03-11 11:57:21 -0500)


Fixup for arch/score after extable.h introduction


Guenter Roeck (1):
  score: Fix implicit includes now failing build after extable change

 arch/score/kernel/traps.c | 1 +
 arch/score/mm/extable.c   | 2 ++
 2 files changed, 3 insertions(+)

[GIT PULL] module.h --> extable.h fixup for arch/score

[Paul Gortmaker]

Linus, please pull to get a small fixup for arch/score.

It seems that Guenter is the only one on the planet doing builds for
arch/score  -- we don't have compile coverage for it in linux-next or in
the kbuild-bot either.  Guenter couldn't even recall where he got his
toolchain, but was kind enough to share it with me so I could validate
this change and also add arch/score to my build coverage.

I sat on this a bit in case there was any other fallout in other arch
dirs, but since this still seems to be the only one, I might as well
send it on its way.

Thanks,
Paul.
---

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git tags/extable-fix

for you to fetch changes up to 0acf611997d9d05dbfb559c3c6e379c861eb5957:

  score: Fix implicit includes now failing build after extable change 
(2017-03-11 11:57:21 -0500)


Fixup for arch/score after extable.h introduction


Guenter Roeck (1):
  score: Fix implicit includes now failing build after extable change

 arch/score/kernel/traps.c | 1 +
 arch/score/mm/extable.c   | 2 ++
 2 files changed, 3 insertions(+)

Re: [PATCH v1 08/10] staging: iio: adis16203: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Applied.
> ---
>  drivers/staging/iio/accel/adis16203.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16203.c 
> b/drivers/staging/iio/accel/adis16203.c
> index 68189ad..b59755a 100644
> --- a/drivers/staging/iio/accel/adis16203.c
> +++ b/drivers/staging/iio/accel/adis16203.c
> @@ -233,8 +233,8 @@ static const struct iio_chan_spec adis16203_channels[] = {
>  };
>  
>  static const struct iio_info adis16203_info = {
> - .read_raw = _read_raw,
> - .write_raw = _write_raw,
> + .read_raw = adis16203_read_raw,
> + .write_raw = adis16203_write_raw,
>   .update_scan_mode = adis_update_scan_mode,
>   .driver_module = THIS_MODULE,
>  };
> 

Re: [PATCH v1 08/10] staging: iio: adis16203: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Applied.
> ---
>  drivers/staging/iio/accel/adis16203.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16203.c 
> b/drivers/staging/iio/accel/adis16203.c
> index 68189ad..b59755a 100644
> --- a/drivers/staging/iio/accel/adis16203.c
> +++ b/drivers/staging/iio/accel/adis16203.c
> @@ -233,8 +233,8 @@ static const struct iio_chan_spec adis16203_channels[] = {
>  };
>  
>  static const struct iio_info adis16203_info = {
> - .read_raw = _read_raw,
> - .write_raw = _write_raw,
> + .read_raw = adis16203_read_raw,
> + .write_raw = adis16203_write_raw,
>   .update_scan_mode = adis_update_scan_mode,
>   .driver_module = THIS_MODULE,
>  };
> 

Re: [PATCH v1 07/10] staging: iio: adis16209: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Applied.
> ---
>  drivers/staging/iio/accel/adis16209.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index 8ff537f..56bc2ac 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16209_channels[] = {
>  };
>  
>  static const struct iio_info adis16209_info = {
> - .read_raw = _read_raw,
> - .write_raw = _write_raw,
> + .read_raw = adis16209_read_raw,
> + .write_raw = adis16209_write_raw,
>   .update_scan_mode = adis_update_scan_mode,
>   .driver_module = THIS_MODULE,
>  };
> 

Re: [PATCH v1 07/10] staging: iio: adis16209: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Applied.
> ---
>  drivers/staging/iio/accel/adis16209.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index 8ff537f..56bc2ac 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16209_channels[] = {
>  };
>  
>  static const struct iio_info adis16209_info = {
> - .read_raw = _read_raw,
> - .write_raw = _write_raw,
> + .read_raw = adis16209_read_raw,
> + .write_raw = adis16209_write_raw,
>   .update_scan_mode = adis_update_scan_mode,
>   .driver_module = THIS_MODULE,
>  };
> 

Re: [PATCH v1 06/10] staging: iio: adis16201: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Applied.
> ---
>  drivers/staging/iio/accel/adis16201.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16201.c 
> b/drivers/staging/iio/accel/adis16201.c
> index d6c8658..7565268 100644
> --- a/drivers/staging/iio/accel/adis16201.c
> +++ b/drivers/staging/iio/accel/adis16201.c
> @@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16201_channels[] = {
>  };
>  
>  static const struct iio_info adis16201_info = {
> - .read_raw = _read_raw,
> - .write_raw = _write_raw,
> + .read_raw = adis16201_read_raw,
> + .write_raw = adis16201_write_raw,
>   .update_scan_mode = adis_update_scan_mode,
>   .driver_module = THIS_MODULE,
>  };
> 

Re: [PATCH v1 06/10] staging: iio: adis16201: Remove exceptional & on function name

[Jonathan Cameron]

On 11/03/17 14:26, simran singhal wrote:
> Remove & from function pointers to conform to the style found elsewhere
> in the file.  Done using the following semantic patch
> 
> // 
> @r@
> identifier f;
> @@
> 
> f(...) { ... }
> @@
> identifier r.f;
> @@
> 
> - 
> + f
> // 
> 
> Signed-off-by: simran singhal 
Applied.
> ---
>  drivers/staging/iio/accel/adis16201.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16201.c 
> b/drivers/staging/iio/accel/adis16201.c
> index d6c8658..7565268 100644
> --- a/drivers/staging/iio/accel/adis16201.c
> +++ b/drivers/staging/iio/accel/adis16201.c
> @@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16201_channels[] = {
>  };
>  
>  static const struct iio_info adis16201_info = {
> - .read_raw = _read_raw,
> - .write_raw = _write_raw,
> + .read_raw = adis16201_read_raw,
> + .write_raw = adis16201_write_raw,
>   .update_scan_mode = adis_update_scan_mode,
>   .driver_module = THIS_MODULE,
>  };
>