RE: [PATCH] ia64: define ioremap_uc()

>> All architectures now need ioremap_uc(), ia64 seems defines >> this already through its ioremap_nocache() and it already >> ensures it *only* uses UC. >> >> Reported-by: 0 day bot >> Signed-off-by: Luis R. Rodriguez > > *Poke* Luis, Thanks for the reminder. Applied.

RE: [PATCH] ia64: define ioremap_uc()

>> All architectures now need ioremap_uc(), ia64 seems defines >> this already through its ioremap_nocache() and it already >> ensures it *only* uses UC. >> >> Reported-by: 0 day bot >> Signed-off-by: Luis R. Rodriguez > > *Poke* Luis, Thanks for the reminder. Applied. -Tony

Re: [PATCH] clk: sunxi: Remove use of VLAIS

On 03/08, Maxime Ripard wrote: > On Fri, Mar 04, 2016 at 09:18:41AM -0800, Stephen Boyd wrote: > > Oh right. Let's hope third time is the last. > > > > ---8<--- > > From: Stephen Boyd > > Subject: [PATCH] clk: sunxi: Remove use of variable length array > > > > Using an

Re: [PATCH] clk: sunxi: Remove use of VLAIS

On 03/08, Maxime Ripard wrote: > On Fri, Mar 04, 2016 at 09:18:41AM -0800, Stephen Boyd wrote: > > Oh right. Let's hope third time is the last. > > > > ---8<--- > > From: Stephen Boyd > > Subject: [PATCH] clk: sunxi: Remove use of variable length array > > > > Using an array allocated on the

Re: [PATCH 0/4] Remove un-needed 'major' registration when alloc_disk(0) is used.

On Tue, Mar 15 2016, Ross Zwisler wrote: > On Thu, Mar 10, 2016 at 08:59:28AM +1100, NeilBrown wrote: >> When alloc_disk(0) is used, the ->major number is ignored and >> irrelevant. Yet several drivers register a major number anyway. >> >> This series of patches removes the pointless

Re: [PATCH 0/4] Remove un-needed 'major' registration when alloc_disk(0) is used.

On Tue, Mar 15 2016, Ross Zwisler wrote: > On Thu, Mar 10, 2016 at 08:59:28AM +1100, NeilBrown wrote: >> When alloc_disk(0) is used, the ->major number is ignored and >> irrelevant. Yet several drivers register a major number anyway. >> >> This series of patches removes the pointless

Re: [PATCH] ia64: define ioremap_uc()

On Mon, 7 Mar 2016 12:34:54 -0800 "Luis R. Rodriguez" wrote: > All architectures now need ioremap_uc(), ia64 seems defines > this already through its ioremap_nocache() and it already > ensures it *only* uses UC. > > Reported-by: 0 day bot > Signed-off-by: Luis R. Rodriguez

Re: [PATCH] ia64: define ioremap_uc()

On Mon, 7 Mar 2016 12:34:54 -0800 "Luis R. Rodriguez" wrote: > All architectures now need ioremap_uc(), ia64 seems defines > this already through its ioremap_nocache() and it already > ensures it *only* uses UC. > > Reported-by: 0 day bot > Signed-off-by: Luis R. Rodriguez > --- > > Note,

[RFT] iommu/amd: use subsys_initcall() on amdv2 iommu

We need to ensure amd iommu v2 initializes before driver uses such as drivers/gpu/drm/amd/amdkfd/kfd_module.c, to do this make its init routine a subsys_initcall() which ensures its load init is called first than modules when built-in. Signed-off-by: Luis R. Rodriguez --- Can

Re: [PATCH] drivers/firmware/broadcom/bcm47xx_nvram.c: fix incorrect __ioread32_copy

On 03/15, Aaro Koskinen wrote: > Commit 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use > __ioread32_copy() instead of open-coding") switched to use a generic > copy functions, but failed to notice that the header pointer is > updated between the two copies, resulting in bogus data

Re: [PATCH v17 2/6] ARM: socfpga: add bindings document for fpga bridge drivers

On Sat, 5 Mar 2016, Rob Herring wrote: > > +Example: > > + hps_fpgabridge0: fpgabridge@ff40 { > > No underscores. > > fpga-bridge@... Hi Rob, The dtc is not letting me compile if I use a hyphen in the label. I think we have to use hyphens in the node names and underscores in the labels.

[RFT] iommu/amd: use subsys_initcall() on amdv2 iommu

We need to ensure amd iommu v2 initializes before driver uses such as drivers/gpu/drm/amd/amdkfd/kfd_module.c, to do this make its init routine a subsys_initcall() which ensures its load init is called first than modules when built-in. Signed-off-by: Luis R. Rodriguez --- Can someone test if

Re: [PATCH] drivers/firmware/broadcom/bcm47xx_nvram.c: fix incorrect __ioread32_copy

On 03/15, Aaro Koskinen wrote: > Commit 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use > __ioread32_copy() instead of open-coding") switched to use a generic > copy functions, but failed to notice that the header pointer is > updated between the two copies, resulting in bogus data

Re: [PATCH v17 2/6] ARM: socfpga: add bindings document for fpga bridge drivers

On Sat, 5 Mar 2016, Rob Herring wrote: > > +Example: > > + hps_fpgabridge0: fpgabridge@ff40 { > > No underscores. > > fpga-bridge@... Hi Rob, The dtc is not letting me compile if I use a hyphen in the label. I think we have to use hyphens in the node names and underscores in the labels.

Re: [PATCH v2] devpts: Make ptmx be owned by the userns owner as a fallback

Quoting Andy Lutomirski (l...@kernel.org): > New devpts instances have ptmx owned by the inner uid and gid 0. > > For container-style namespaces (LXC, etc), this should have no > effect, this is fine. > > For sandbox-style namespaces (xdg-app and similar), this is > problematic -- there may not

Re: [PATCH v2] devpts: Make ptmx be owned by the userns owner as a fallback

Quoting Andy Lutomirski (l...@kernel.org): > New devpts instances have ptmx owned by the inner uid and gid 0. > > For container-style namespaces (LXC, etc), this should have no > effect, this is fine. > > For sandbox-style namespaces (xdg-app and similar), this is > problematic -- there may not

Re: [PATCH 2/2] iio: mma8452: use runtime pm instead of device specific autosleep

On 14/03/16 11:26, Martin Kepplinger wrote: > What is this autosleep? > --- > It slows down the device after x seconds of inactivity. The thing is, we have > really achieved almost the same by runtime pm. > > differnces are: > > autosleep > * uses more power during

Re: [PATCH 2/2] iio: mma8452: use runtime pm instead of device specific autosleep

On 14/03/16 11:26, Martin Kepplinger wrote: > What is this autosleep? > --- > It slows down the device after x seconds of inactivity. The thing is, we have > really achieved almost the same by runtime pm. > > differnces are: > > autosleep > * uses more power during

Re: [PATCH] ia64: define ioremap_uc()

On Mon, Mar 07, 2016 at 12:34:54PM -0800, Luis R. Rodriguez wrote: > All architectures now need ioremap_uc(), ia64 seems defines > this already through its ioremap_nocache() and it already > ensures it *only* uses UC. > > Reported-by: 0 day bot > Signed-off-by: Luis R. Rodriguez

Re: [PATCH] ia64: define ioremap_uc()

On Mon, Mar 07, 2016 at 12:34:54PM -0800, Luis R. Rodriguez wrote: > All architectures now need ioremap_uc(), ia64 seems defines > this already through its ioremap_nocache() and it already > ensures it *only* uses UC. > > Reported-by: 0 day bot > Signed-off-by: Luis R. Rodriguez *Poke* Luis

Re: [PATCH 1/2] iio: mma8452: add i2c_device_id for mma8451

On 14/03/16 11:33, Martin Kepplinger wrote: > This was forgotten about and is added for consistency now > > Signed-off-by: Martin Kepplinger > --- > I'm sorry, I messed up the first patch. Understandable though, given > it's complexity. Took me a disturbingly long time to

Re: [PATCH 1/2] iio: mma8452: add i2c_device_id for mma8451

On 14/03/16 11:33, Martin Kepplinger wrote: > This was forgotten about and is added for consistency now > > Signed-off-by: Martin Kepplinger > --- > I'm sorry, I messed up the first patch. Understandable though, given > it's complexity. Took me a disturbingly long time to notice what was wrong.

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

alues") > > > > > > This is due to a bug in the powerpc __get_user_check() macro (the return > > > value is defined to be "unsigned long" which is only 32 bits on a 32 > > > bit platform). > > > > m68k allmodconfig and all defs of m3

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

alues") > > > > > > This is due to a bug in the powerpc __get_user_check() macro (the return > > > value is defined to be "unsigned long" which is only 32 bits on a 32 > > > bit platform). > > > > m68k allmodconfig and all defs of m3

Re: linux-next: Tree for Mar 14 (mips qemu failure bisected)

Hi Guenter, On 15/03/2016 05:26, Guenter Roeck wrote: On Mon, Mar 14, 2016 at 07:37:29AM -0700, Guenter Roeck wrote: On Mon, Mar 14, 2016 at 05:40:37PM +1100, Stephen Rothwell wrote: Hi all, Changes since 20160311: The vfs tree gained a conflict against Linus' tree. I also applied a patch

Re: linux-next: Tree for Mar 14 (mips qemu failure bisected)

Hi Guenter, On 15/03/2016 05:26, Guenter Roeck wrote: On Mon, Mar 14, 2016 at 07:37:29AM -0700, Guenter Roeck wrote: On Mon, Mar 14, 2016 at 05:40:37PM +1100, Stephen Rothwell wrote: Hi all, Changes since 20160311: The vfs tree gained a conflict against Linus' tree. I also applied a patch

Re: [PATCH 1/5] ftrace perf: Check sample types only for sampling events

On Tue, Mar 15, 2016 at 04:06:46PM -0400, Steven Rostedt wrote: > On Wed, 9 Mar 2016 21:46:41 +0100 > Jiri Olsa wrote: > > > Currently we check sample type for ftrace:function event > > even if it's not created as sampling event. That prevents > > creating ftrace_function

Re: [PATCH 1/5] ftrace perf: Check sample types only for sampling events

On Tue, Mar 15, 2016 at 04:06:46PM -0400, Steven Rostedt wrote: > On Wed, 9 Mar 2016 21:46:41 +0100 > Jiri Olsa wrote: > > > Currently we check sample type for ftrace:function event > > even if it's not created as sampling event. That prevents > > creating ftrace_function event in counting

Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update()

On Tue, Mar 15, 2016 at 02:45:45PM -0700, Michael Turquette wrote: > Quoting Peter Zijlstra (2016-03-15 14:14:48) > > On Sun, Mar 13, 2016 at 10:22:05PM -0700, Michael Turquette wrote: > > > cpufreq_trigger_update() was introduced in "cpufreq: Rework the > > > scheduler hooks for triggering

Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update()

On Tue, Mar 15, 2016 at 02:45:45PM -0700, Michael Turquette wrote: > Quoting Peter Zijlstra (2016-03-15 14:14:48) > > On Sun, Mar 13, 2016 at 10:22:05PM -0700, Michael Turquette wrote: > > > cpufreq_trigger_update() was introduced in "cpufreq: Rework the > > > scheduler hooks for triggering

Re: [PATCH] staging/comedi/dt282x: avoid integer overflow warning

On Tuesday 15 March 2016 21:35:40 Hartley Sweeten wrote: > On Monday, March 14, 2016 3:48 PM, Arnd Bergmann wrote: > > gcc-6 warns about passing negative signed integer into swab16() > > in the dt282x driver: > > > > > The warning makes sense, though the code is correct as far as I > > can

RE: [PATCH] staging/comedi/dt282x: avoid integer overflow warning

On Monday, March 14, 2016 3:48 PM, Arnd Bergmann wrote: > gcc-6 warns about passing negative signed integer into swab16() > in the dt282x driver: > The warning makes sense, though the code is correct as far as I > can tell. > > This disambiguates the operation by making the constant expressions

Re: [PATCH] staging/comedi/dt282x: avoid integer overflow warning

On Tuesday 15 March 2016 21:35:40 Hartley Sweeten wrote: > On Monday, March 14, 2016 3:48 PM, Arnd Bergmann wrote: > > gcc-6 warns about passing negative signed integer into swab16() > > in the dt282x driver: > > > > > The warning makes sense, though the code is correct as far as I > > can

RE: [PATCH] staging/comedi/dt282x: avoid integer overflow warning

On Monday, March 14, 2016 3:48 PM, Arnd Bergmann wrote: > gcc-6 warns about passing negative signed integer into swab16() > in the dt282x driver: > The warning makes sense, though the code is correct as far as I > can tell. > > This disambiguates the operation by making the constant expressions

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On Tue, Mar 15, 2016 at 02:40:43PM -0700, Michael Turquette wrote: > Quoting Peter Zijlstra (2016-03-15 14:20:47) > > On Sun, Mar 13, 2016 at 10:22:08PM -0700, Michael Turquette wrote: > > > With the addition of the global cfs capacity margin helpers in patch, > > > "sched/cpufreq: new cfs

Re: [PATCH] qla2xxx: avoid maybe_uninitialized warning

On Tue, 2016-03-15 at 22:40 +0100, Arnd Bergmann wrote: > The qlt_check_reserve_free_req() function produces an incorrect > warning when CONFIG_PROFILE_ANNOTATED_BRANCHES is set: > > drivers/scsi/qla2xxx/qla_target.c: In function > 'qlt_check_reserve_free_req': >

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On Tue, Mar 15, 2016 at 02:40:43PM -0700, Michael Turquette wrote: > Quoting Peter Zijlstra (2016-03-15 14:20:47) > > On Sun, Mar 13, 2016 at 10:22:08PM -0700, Michael Turquette wrote: > > > With the addition of the global cfs capacity margin helpers in patch, > > > "sched/cpufreq: new cfs

Re: [PATCH] qla2xxx: avoid maybe_uninitialized warning

On Tue, 2016-03-15 at 22:40 +0100, Arnd Bergmann wrote: > The qlt_check_reserve_free_req() function produces an incorrect > warning when CONFIG_PROFILE_ANNOTATED_BRANCHES is set: > > drivers/scsi/qla2xxx/qla_target.c: In function > 'qlt_check_reserve_free_req': >

[PATCH] net: mvneta: bm: clarify dependencies

MVNETA_BM has a dependency on MVNETA, so we can only select the former if the latter is enabled. However, the code dependency is the reverse: The mvneta module can call into the mvneta_bm module, so mvneta cannot be a built-in if mvneta_bm is a module, or we get a link error:

[PATCH] net: mvneta: bm: clarify dependencies

MVNETA_BM has a dependency on MVNETA, so we can only select the former if the latter is enabled. However, the code dependency is the reverse: The mvneta module can call into the mvneta_bm module, so mvneta cannot be a built-in if mvneta_bm is a module, or we get a link error:

[PATCH] drivers/firmware/broadcom/bcm47xx_nvram.c: fix incorrect __ioread32_copy

Commit 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use __ioread32_copy() instead of open-coding") switched to use a generic copy functions, but failed to notice that the header pointer is updated between the two copies, resulting in bogus data being copied in the latter one. Fix by

[PATCH] drivers/firmware/broadcom/bcm47xx_nvram.c: fix incorrect __ioread32_copy

Commit 1f330c327900 ("drivers/firmware/broadcom/bcm47xx_nvram.c: use __ioread32_copy() instead of open-coding") switched to use a generic copy functions, but failed to notice that the header pointer is updated between the two copies, resulting in bogus data being copied in the latter one. Fix by

[PATCH] memstick: r592: avoid gcc-6 warning

The r592 driver relies on behavior of the DMA mapping API that is normally observed but not guaranteed by the API. Instead it uses a runtime check to fail transfers if the API ever behaves differently. When CONFIG_NEED_SG_DMA_LENGTH is not set, one of the checks turns into a comparison of a

[PATCH] memstick: r592: avoid gcc-6 warning

The r592 driver relies on behavior of the DMA mapping API that is normally observed but not guaranteed by the API. Instead it uses a runtime check to fail transfers if the API ever behaves differently. When CONFIG_NEED_SG_DMA_LENGTH is not set, one of the checks turns into a comparison of a

Re: [ANNOUNCE] 3.14.64-rt67

On Mon, Mar 14, 2016 at 11:49 AM, Steven Rostedt wrote: > > Dear RT Folks, > > 3.14 release on PI(E) Day! > > I'm pleased to announce the 3.14.64-rt67 stable release. Testing this with what is largely a x86-64 defconfig but with RT_FULL, I now see: root@dell760-paul:~#

Re: [ANNOUNCE] 3.14.64-rt67

On Mon, Mar 14, 2016 at 11:49 AM, Steven Rostedt wrote: > > Dear RT Folks, > > 3.14 release on PI(E) Day! > > I'm pleased to announce the 3.14.64-rt67 stable release. Testing this with what is largely a x86-64 defconfig but with RT_FULL, I now see: root@dell760-paul:~# dmesg|grep NOH [

[PATCH] rtc: asm9260: remove incorrect __init/__exit annotations

The probe and remove callbacks of the platform driver are marked __init and __exit, respectively. However, this is not a correct way to annotate them, as it will result in those sections to be discarded at link time or after boot, while we can actually call them again based on manual unbinding, or

[PATCH] rtc: asm9260: remove incorrect __init/__exit annotations

The probe and remove callbacks of the platform driver are marked __init and __exit, respectively. However, this is not a correct way to annotate them, as it will result in those sections to be discarded at link time or after boot, while we can actually call them again based on manual unbinding, or

Re: [PATCH 2/8] sched/fair: add margin to utilization update

On Tue, Mar 15, 2016 at 02:28:48PM -0700, Michael Turquette wrote: > Quoting Peter Zijlstra (2016-03-15 14:16:14) > > On Sun, Mar 13, 2016 at 10:22:06PM -0700, Michael Turquette wrote: > > > @@ -2840,6 +2853,8 @@ static inline void update_load_avg(struct > > > sched_entity *se, int update_tg) > >

Re: [PATCH 2/8] sched/fair: add margin to utilization update

On Tue, Mar 15, 2016 at 02:28:48PM -0700, Michael Turquette wrote: > Quoting Peter Zijlstra (2016-03-15 14:16:14) > > On Sun, Mar 13, 2016 at 10:22:06PM -0700, Michael Turquette wrote: > > > @@ -2840,6 +2853,8 @@ static inline void update_load_avg(struct > > > sched_entity *se, int update_tg) > >

[PATCH] ASoC: rt5616: add I2C dependency

The rt5616 codec registers itself as an i2c driver, but can be enabled even when i2c is turned off, which leads to a build error: codecs/rt5616.c:1419:1: error: data definition has no type or storage class [-Werror] module_i2c_driver(rt5616_i2c_driver); This adds an explicit Kconfig

[PATCH] ASoC: rt5616: add I2C dependency

The rt5616 codec registers itself as an i2c driver, but can be enabled even when i2c is turned off, which leads to a build error: codecs/rt5616.c:1419:1: error: data definition has no type or storage class [-Werror] module_i2c_driver(rt5616_i2c_driver); This adds an explicit Kconfig

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

On Sun, Mar 13, 2016 at 10:22:12PM -0700, Michael Turquette wrote: > +++ b/kernel/sched/sched.h > @@ -1368,7 +1368,21 @@ static inline int hrtick_enabled(struct rq *rq) > #ifdef CONFIG_SMP > extern void sched_avg_update(struct rq *rq); > > -#ifndef arch_scale_freq_capacity > +#ifdef

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

On Sun, Mar 13, 2016 at 10:22:12PM -0700, Michael Turquette wrote: > +++ b/kernel/sched/sched.h > @@ -1368,7 +1368,21 @@ static inline int hrtick_enabled(struct rq *rq) > #ifdef CONFIG_SMP > extern void sched_avg_update(struct rq *rq); > > -#ifndef arch_scale_freq_capacity > +#ifdef

[PATCH] qla2xxx: avoid maybe_uninitialized warning

The qlt_check_reserve_free_req() function produces an incorrect warning when CONFIG_PROFILE_ANNOTATED_BRANCHES is set: drivers/scsi/qla2xxx/qla_target.c: In function 'qlt_check_reserve_free_req': drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt_in' may be used uninitialized in this function

[PATCH] qla2xxx: avoid maybe_uninitialized warning

The qlt_check_reserve_free_req() function produces an incorrect warning when CONFIG_PROFILE_ANNOTATED_BRANCHES is set: drivers/scsi/qla2xxx/qla_target.c: In function 'qlt_check_reserve_free_req': drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt_in' may be used uninitialized in this function

Re: [PATCH] kbuild: Add option to turn incompatible pointer check into error

Dne 15.3.2016 v 22:34 Michal Marek napsal(a): > Dne 8.3.2016 v 10:19 Ingo Molnar napsal(a): >> Note that there will be a few build failures triggered by this, for example >> this >> fix from linux-next is needed: >> >>> commit db9b60400f9253c25ae639797df2d0ff7a35d9d8 >>> Author: Sudip Mukherjee

Re: [PATCH] kbuild: Add option to turn incompatible pointer check into error

Dne 15.3.2016 v 22:34 Michal Marek napsal(a): > Dne 8.3.2016 v 10:19 Ingo Molnar napsal(a): >> Note that there will be a few build failures triggered by this, for example >> this >> fix from linux-next is needed: >> >>> commit db9b60400f9253c25ae639797df2d0ff7a35d9d8 >>> Author: Sudip Mukherjee

[PATCH] aio: rewrite aio_thread_op_foo_at to avoid 64-bit get_user

Most architectures cannot access 64-bit integers using get_user or __get_user, so we get a build error in the new aio_thread_op_foo_at function: fs/built-in.o: In function `aio_thread_op_foo_at': aio.c:(.text+0x252de): undefined reference to `__get_user_bad' aio.c:(.text+0x252e4): undefined

[PATCH] aio: rewrite aio_thread_op_foo_at to avoid 64-bit get_user

Most architectures cannot access 64-bit integers using get_user or __get_user, so we get a build error in the new aio_thread_op_foo_at function: fs/built-in.o: In function `aio_thread_op_foo_at': aio.c:(.text+0x252de): undefined reference to `__get_user_bad' aio.c:(.text+0x252e4): undefined

[PATCH] iommu: provide of_xlate pointer unconditionally

iommu drivers that support the standard DT bindings use a of_xlate callback pointer, but that is only part of struct iommu_ops when CONFIG_OF_IOMMU is enabled, leading to build errors in randconfig builds when that is not provided: drivers/iommu/mtk_iommu.c:497:2: error: unknown field 'of_xlate'

[PATCH] iommu: provide of_xlate pointer unconditionally

iommu drivers that support the standard DT bindings use a of_xlate callback pointer, but that is only part of struct iommu_ops when CONFIG_OF_IOMMU is enabled, leading to build errors in randconfig builds when that is not provided: drivers/iommu/mtk_iommu.c:497:2: error: unknown field 'of_xlate'

[PATCH] tpm_crb: drop struct resource res from struct crb_priv

The iomem resource is needed only temporarily so it is better to pass it on instead of storing it permanently. Named the variable as io_res so that the code better documents itself. Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm_crb.c | 29

[PATCH] tpm_crb: drop struct resource res from struct crb_priv

The iomem resource is needed only temporarily so it is better to pass it on instead of storing it permanently. Named the variable as io_res so that the code better documents itself. Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm_crb.c | 29 - 1 file changed,

[PATCH] ARM: davinci: only use NVMEM when available

The davinci platform contains code that calls into the nvmem subsystem, but that might be a loadable module, causing a link error: arch/arm/mach-davinci/built-in.o: In function `davinci_get_mac_addr': :(.text+0x1088): undefined reference to `nvmem_device_read' arch/arm/mach-davinci/built-in.o: In

[PATCH] ARM: davinci: only use NVMEM when available

The davinci platform contains code that calls into the nvmem subsystem, but that might be a loadable module, causing a link error: arch/arm/mach-davinci/built-in.o: In function `davinci_get_mac_addr': :(.text+0x1088): undefined reference to `nvmem_device_read' arch/arm/mach-davinci/built-in.o: In

Re: [PATCH] kbuild: Add option to turn incompatible pointer check into error

Dne 8.3.2016 v 10:19 Ingo Molnar napsal(a): > > * Thomas Gleixner wrote: > >> On Tue, 8 Mar 2016, Daniel Wagner wrote: >> >>> From: Daniel Wagner >>> >>> With the introduction of the simple wait API we have two very >>> similar APIs in the

Re: [PATCH] kbuild: Add option to turn incompatible pointer check into error

Dne 8.3.2016 v 10:19 Ingo Molnar napsal(a): > > * Thomas Gleixner wrote: > >> On Tue, 8 Mar 2016, Daniel Wagner wrote: >> >>> From: Daniel Wagner >>> >>> With the introduction of the simple wait API we have two very >>> similar APIs in the kernel. For example wake_up() and swake_up() >>> is

Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support

On Sun, Mar 13, 2016 at 10:22:11PM -0700, Michael Turquette wrote: > +static DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE; > + > +unsigned long cpufreq_scale_freq_capacity(struct sched_domain *sd, int cpu) > +{ > + return per_cpu(freq_scale, cpu); > +} These should be in

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

On 03/15/2016 02:04 PM, Aaron Conole wrote: The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous.

Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support

On Sun, Mar 13, 2016 at 10:22:11PM -0700, Michael Turquette wrote: > +static DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE; > + > +unsigned long cpufreq_scale_freq_capacity(struct sched_domain *sd, int cpu) > +{ > + return per_cpu(freq_scale, cpu); > +} These should be in

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

On 03/15/2016 02:04 PM, Aaron Conole wrote: The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous.

Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support

On Tue, Mar 15, 2016 at 01:19:17PM -0700, Michael Turquette wrote: > That's what I had in mind. I guess that some day there will be a need to > select implementations at run-time for both cpufreq (e.g. different > cpufreq drivers might implement arch_scale_freq_capacity) and for the >

Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support

On Tue, Mar 15, 2016 at 01:19:17PM -0700, Michael Turquette wrote: > That's what I had in mind. I guess that some day there will be a need to > select implementations at run-time for both cpufreq (e.g. different > cpufreq drivers might implement arch_scale_freq_capacity) and for the >

Re: [PATCH 6/8] cpufreq/schedutil: sum per-sched class utilization

On Sun, Mar 13, 2016 at 10:22:10PM -0700, Michael Turquette wrote: > +static unsigned long sugov_sum_total_util(struct sugov_cpu *sg_cpu) > +{ > + enum sched_class_util sc; > + > + /* sum the utilization of all sched classes */ > + sg_cpu->total_util = 0; > + for (sc = 0; sc <

[PATCH] ARM: pxa/raumfeld: use PROPERTY_ENTRY_INTEGER to define props

gcc-6.0 notices that the use of the property_entry in this file that was recently introduced cannot work right, as we initialize the wrong field: raumfeld.c:387:3: error: the address of 'raumfeld_rotary_encoder_steps' will always evaluate as 'true' [-Werror=address] DEV_PROP_U32, 1,

Re: [PATCH 6/8] cpufreq/schedutil: sum per-sched class utilization

On Sun, Mar 13, 2016 at 10:22:10PM -0700, Michael Turquette wrote: > +static unsigned long sugov_sum_total_util(struct sugov_cpu *sg_cpu) > +{ > + enum sched_class_util sc; > + > + /* sum the utilization of all sched classes */ > + sg_cpu->total_util = 0; > + for (sc = 0; sc <

[PATCH] ARM: pxa/raumfeld: use PROPERTY_ENTRY_INTEGER to define props

gcc-6.0 notices that the use of the property_entry in this file that was recently introduced cannot work right, as we initialize the wrong field: raumfeld.c:387:3: error: the address of 'raumfeld_rotary_encoder_steps' will always evaluate as 'true' [-Werror=address] DEV_PROP_U32, 1,

Re: [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

On Mon, Mar 14, 2016 at 09:11:16PM -0600, Toshi Kani wrote: > On Tue, 2016-03-15 at 01:29 +0100, Luis R. Rodriguez wrote: > > I like this approach more as it stuff more PAT setup on its own type > > of calls, but: > > > > On Sat, Mar 12, 2016 at 12:55:44PM +0100, Borislav Petkov wrote: > > > diff

Re: [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

On Mon, Mar 14, 2016 at 09:11:16PM -0600, Toshi Kani wrote: > On Tue, 2016-03-15 at 01:29 +0100, Luis R. Rodriguez wrote: > > I like this approach more as it stuff more PAT setup on its own type > > of calls, but: > > > > On Sat, Mar 12, 2016 at 12:55:44PM +0100, Borislav Petkov wrote: > > > diff

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 01:43:01PM -0700, Linus Torvalds wrote: > Put another way: this is not about theoretical leaks - because those > are totally irrelevant (in theory, the original discard writer had > access to all that stale data anyway). This is about making it a > practical interface that

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 01:43:01PM -0700, Linus Torvalds wrote: > Put another way: this is not about theoretical leaks - because those > are totally irrelevant (in theory, the original discard writer had > access to all that stale data anyway). This is about making it a > practical interface that

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

> "KY" == KY Srinivasan writes: KY> Till recently I had not. However, we do support publishing wwn in KY> the guest and some customers wanted this. That is the reason I am KY> attaching FC transport and working through the issues. With this KY> change, I now have wwn

Re: [PATCH 1/1] scsi: storvsc: Support manual scan of FC hosts on Hyper-V

> "KY" == KY Srinivasan writes: KY> Till recently I had not. However, we do support publishing wwn in KY> the guest and some customers wanted this. That is the reason I am KY> attaching FC transport and working through the issues. With this KY> change, I now have wwn names published in the

Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util

On Sun, Mar 13, 2016 at 10:22:09PM -0700, Michael Turquette wrote: > +++ b/include/linux/sched.h > @@ -2362,15 +2362,25 @@ extern u64 scheduler_tick_max_deferment(void); > static inline bool sched_can_stop_tick(void) { return false; } > #endif > > +enum sched_class_util { > + cfs_util, > +

Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util

On Sun, Mar 13, 2016 at 10:22:09PM -0700, Michael Turquette wrote: > +++ b/include/linux/sched.h > @@ -2362,15 +2362,25 @@ extern u64 scheduler_tick_max_deferment(void); > static inline bool sched_can_stop_tick(void) { return false; } > #endif > > +enum sched_class_util { > + cfs_util, > +

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On Sun, Mar 13, 2016 at 10:22:08PM -0700, Michael Turquette wrote: > With the addition of the global cfs capacity margin helpers in patch, > "sched/cpufreq: new cfs capacity margin helpers", we can now export > sysfs tunables from the schedutil governor. This allows privileged users > to tune the

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On Sun, Mar 13, 2016 at 10:22:08PM -0700, Michael Turquette wrote: > With the addition of the global cfs capacity margin helpers in patch, > "sched/cpufreq: new cfs capacity margin helpers", we can now export > sysfs tunables from the schedutil governor. This allows privileged users > to tune the

Re: [patch] Input: synaptics-rmi4 - using logical instead of bitwise AND

On 03/15/2016 12:11 AM, Dan Carpenter wrote: There is a typo so we have && instead of &. Fixes: ff8f83708b3e ('Input: synaptics-rmi4 - add support for 2D sensors and F11') Signed-off-by: Dan Carpenter Acked-by: Andrew Duggan diff --git

Re: [patch] Input: synaptics-rmi4 - using logical instead of bitwise AND

On 03/15/2016 12:11 AM, Dan Carpenter wrote: There is a typo so we have && instead of &. Fixes: ff8f83708b3e ('Input: synaptics-rmi4 - add support for 2D sensors and F11') Signed-off-by: Dan Carpenter Acked-by: Andrew Duggan diff --git a/drivers/input/rmi4/rmi_f11.c

Re: [PATCH 2/8] sched/fair: add margin to utilization update

On Sun, Mar 13, 2016 at 10:22:06PM -0700, Michael Turquette wrote: > @@ -2840,6 +2853,8 @@ static inline void update_load_avg(struct sched_entity > *se, int update_tg) > > if (cpu == smp_processor_id() && >cfs == cfs_rq) { > unsigned long max = rq->cpu_capacity_orig; > +

Re: [PATCH 2/8] sched/fair: add margin to utilization update

On Sun, Mar 13, 2016 at 10:22:06PM -0700, Michael Turquette wrote: > @@ -2840,6 +2853,8 @@ static inline void update_load_avg(struct sched_entity > *se, int update_tg) > > if (cpu == smp_processor_id() && >cfs == cfs_rq) { > unsigned long max = rq->cpu_capacity_orig; > +

Re: [PATCH 3/8] sched/cpufreq: new cfs capacity margin helpers

On Sun, Mar 13, 2016 at 10:22:07PM -0700, Michael Turquette wrote: > +/** > + * cpufreq_set_cfs_capacity_margin - Set global cfs enqueue capacity margin > + * @margin: new capacity margin > + * > + * margin is a percentage of capacity that is applied to the current > + * utilization when selecting

Re: [PATCH 3/8] sched/cpufreq: new cfs capacity margin helpers

On Sun, Mar 13, 2016 at 10:22:07PM -0700, Michael Turquette wrote: > +/** > + * cpufreq_set_cfs_capacity_margin - Set global cfs enqueue capacity margin > + * @margin: new capacity margin > + * > + * margin is a percentage of capacity that is applied to the current > + * utilization when selecting

Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update()

On Sun, Mar 13, 2016 at 10:22:05PM -0700, Michael Turquette wrote: > cpufreq_trigger_update() was introduced in "cpufreq: Rework the > scheduler hooks for triggering updates"[0]. Consensus is that this > helper is not needed and removing it will aid in experimenting with > deadline and rt capacity

Re: [PATCH 1/8] sched/cpufreq: remove cpufreq_trigger_update()

On Sun, Mar 13, 2016 at 10:22:05PM -0700, Michael Turquette wrote: > cpufreq_trigger_update() was introduced in "cpufreq: Rework the > scheduler hooks for triggering updates"[0]. Consensus is that this > helper is not needed and removing it will aid in experimenting with > deadline and rt capacity

[PATCH] Remove v850 from linux/elf-em.h

From: Rob Landley The v850 port was removed by commits f606ddf42fd4 and 07a887d399b8 in 2008. These #defines are not used in the current kernel. Signed-off-by: Rob Landley --- include/uapi/linux/elf-em.h |3 --- 1 file changed, 3 deletions(-) diff

[PATCH] Remove v850 from linux/elf-em.h

From: Rob Landley The v850 port was removed by commits f606ddf42fd4 and 07a887d399b8 in 2008. These #defines are not used in the current kernel. Signed-off-by: Rob Landley --- include/uapi/linux/elf-em.h |3 --- 1 file changed, 3 deletions(-) diff --git a/include/uapi/linux/elf-em.h

Re: [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

On Tue, 2016-03-15 at 12:00 +0100, Borislav Petkov wrote: > On Mon, Mar 14, 2016 at 03:37:23PM -0600, Toshi Kani wrote: > > Your patch is a simplified version of mine.  So, yes, it fixes the > > Paul's issue, but it does not address other issues that my patchset > > also addressed.  In specific, I

Re: [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

On Tue, 2016-03-15 at 12:00 +0100, Borislav Petkov wrote: > On Mon, Mar 14, 2016 at 03:37:23PM -0600, Toshi Kani wrote: > > Your patch is a simplified version of mine.  So, yes, it fixes the > > Paul's issue, but it does not address other issues that my patchset > > also addressed.  In specific, I

<    1   2   3   4   5   6   7   8   9   10   >