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

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

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

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

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

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

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

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

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

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

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

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

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

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':

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

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':

Re: srcu: BUG in __synchronize_srcu

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

Re: srcu: BUG in __synchronize_srcu

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 > >>

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

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

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

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

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

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 ++--

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

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 ++--

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

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

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

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

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

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

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

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

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

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

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

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 ---

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

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

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

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

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

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 ---

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

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 ---

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

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

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

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

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

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

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

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 ++--

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

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

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

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 +-

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

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

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

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 +-

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

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.

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

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.

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

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 +

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

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 +

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

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

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

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.

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

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

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

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.

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

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

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

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 ---

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

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 ---

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

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 |

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

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:

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

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 ---

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

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: > > $

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

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 > > real

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

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

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

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

[PATCH] ASoC: cs35l35: trivial fix to indentation

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

[PATCH] ASoC: cs35l35: trivial fix to indentation

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 PULL] KVM fixes for 4.11-rc2

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

[GIT PULL] KVM fixes for 4.11-rc2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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:

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

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:

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

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

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

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:

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

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:

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

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:

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

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:

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

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

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

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

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

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:

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

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:

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

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:

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

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:

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

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:

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

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:

<    1   2   3   4   5   6   >