[PATCH v5 0/2] firmware: add driver data API

Greg, This v5 drops the driver porting examples in light of the fact simple cases do not yet benefit from use of the newer API. The API is purposely introduced bare bones so new features are easier to review. This v5 embraces the proposed "driver data" name, extends documentation to cover the

[PATCH v5 2/2] test: add new driver_data load tester

This adds a load tester driver test_driver_data a for the new extensible driver_data loader API, part of firmware_class. This test driver enables you to build your tests in userspace by exposing knobs of the exported API to userspace and enables a trigger action to mimic a one time use of the

[tip:WIP.sched/core 138/170] arch/mips/paravirt/paravirt-smp.c:106:25: note: in expansion of macro '__KSTK_TOS'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/core head: 4906e0da940c919f1669c365cb2e1434bd0cbbe9 commit: 239a7a08abab3068f29746f53d65c834c1c63579 [138/170] sched/headers: Split out of config: mips-mips_paravirt_defconfig (attached as .config) compiler:

[tip:WIP.sched/core 138/170] arch/mips/paravirt/paravirt-smp.c:106:25: note: in expansion of macro '__KSTK_TOS'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/core head: 4906e0da940c919f1669c365cb2e1434bd0cbbe9 commit: 239a7a08abab3068f29746f53d65c834c1c63579 [138/170] sched/headers: Split out of config: mips-mips_paravirt_defconfig (attached as .config) compiler:

Re: [RFC/PATCH] arm64: Rename macro arguments to silence sparse

On 02/06/2017 05:01 PM, Stephen Boyd wrote: > When I compile files with sparse, I get these sorts of warnings: > > arch/arm64/include/asm/lse.h:14:28: warning: Unknown escape 'l' > arch/arm64/include/asm/lse.h:14:37: warning: Unknown escape 'l' > arch/arm64/include/asm/alternative.h:172:28:

Re: [RFC PATCH] perf/stat: Add --disable-hwdt

Ok, here's something (as replies to this message) which looks much more decent. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [RFC PATCH] perf/stat: Add --disable-hwdt

Ok, here's something (as replies to this message) which looks much more decent. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [RFC/PATCH] arm64: Rename macro arguments to silence sparse

On 02/06/2017 05:01 PM, Stephen Boyd wrote: > When I compile files with sparse, I get these sorts of warnings: > > arch/arm64/include/asm/lse.h:14:28: warning: Unknown escape 'l' > arch/arm64/include/asm/lse.h:14:37: warning: Unknown escape 'l' > arch/arm64/include/asm/alternative.h:172:28:

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

On Sat, 4 Feb 2017 01:09:49 +0530 "Naveen N. Rao" wrote: > Hi Michael, > Thanks for the review! I'll defer to Anju on most of the aspects, but... > > On 2017/02/01 09:53PM, Michael Ellerman wrote: > > Anju T Sudhakar writes: > > > > >

Re: [PATCH V3 3/4] arch/powerpc: Implement Optprobes

On Sat, 4 Feb 2017 01:09:49 +0530 "Naveen N. Rao" wrote: > Hi Michael, > Thanks for the review! I'll defer to Anju on most of the aspects, but... > > On 2017/02/01 09:53PM, Michael Ellerman wrote: > > Anju T Sudhakar writes: > > > > > +static void optimized_callback(struct optimized_kprobe

Re: [PATCH v2] Input: xpad - restore LED state after device resume

On Mon, Feb 06, 2017 at 04:58:38PM -0800, Cameron Gutman wrote: > Set the LED_CORE_SUSPENDRESUME flag on our LED device so the > LED state will be automatically restored by LED core on resume. > > Since Xbox One pads stop flashing only when reinitialized, we'll > send them the initialization

Re: [PATCH v2] Input: xpad - restore LED state after device resume

On Mon, Feb 06, 2017 at 04:58:38PM -0800, Cameron Gutman wrote: > Set the LED_CORE_SUSPENDRESUME flag on our LED device so the > LED state will be automatically restored by LED core on resume. > > Since Xbox One pads stop flashing only when reinitialized, we'll > send them the initialization

Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div

On 02/06, Florian Fainelli wrote: > On 02/06/2017 02:59 PM, Stephen Boyd wrote: > > On 02/03, Florian Fainelli wrote: > >> > >> We already have another piece of drive code that manipulates registers > >> in the Bus Interface Unit located in drivers/soc/bcm/brcmstb/biuctrl.c > >> and which has

Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div

On 02/06, Florian Fainelli wrote: > On 02/06/2017 02:59 PM, Stephen Boyd wrote: > > On 02/03, Florian Fainelli wrote: > >> > >> We already have another piece of drive code that manipulates registers > >> in the Bus Interface Unit located in drivers/soc/bcm/brcmstb/biuctrl.c > >> and which has

Re: [PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support

On 02/06, Chris Packham wrote: > On 07/02/17 12:14, Stephen Boyd wrote: > > On 02/03, Chris Packham wrote: > >> The initial implementation in commit e120c17a70e5 ("clk: mvebu: support > >> for 98DX3236 SoC") hardcoded a fixed value for the main PLL frequency. > >> Port code from the Marvell

Re: [PATCH 4/4] clk: mvebu: Expand mv98dx3236-core-clock support

On 02/06, Chris Packham wrote: > On 07/02/17 12:14, Stephen Boyd wrote: > > On 02/03, Chris Packham wrote: > >> The initial implementation in commit e120c17a70e5 ("clk: mvebu: support > >> for 98DX3236 SoC") hardcoded a fixed value for the main PLL frequency. > >> Port code from the Marvell

[RFC/PATCH] arm64: Rename macro arguments to silence sparse

When I compile files with sparse, I get these sorts of warnings: arch/arm64/include/asm/lse.h:14:28: warning: Unknown escape 'l' arch/arm64/include/asm/lse.h:14:37: warning: Unknown escape 'l' arch/arm64/include/asm/alternative.h:172:28: warning: Unknown escape 'o' This is because sparse is

[RFC/PATCH] arm64: Rename macro arguments to silence sparse

When I compile files with sparse, I get these sorts of warnings: arch/arm64/include/asm/lse.h:14:28: warning: Unknown escape 'l' arch/arm64/include/asm/lse.h:14:37: warning: Unknown escape 'l' arch/arm64/include/asm/alternative.h:172:28: warning: Unknown escape 'o' This is because sparse is

[PATCH v2] Input: xpad - restore LED state after device resume

Set the LED_CORE_SUSPENDRESUME flag on our LED device so the LED state will be automatically restored by LED core on resume. Since Xbox One pads stop flashing only when reinitialized, we'll send them the initialization packet so they calm down too. Signed-off-by: Cameron Gutman

[PATCH v2] Input: xpad - restore LED state after device resume

Set the LED_CORE_SUSPENDRESUME flag on our LED device so the LED state will be automatically restored by LED core on resume. Since Xbox One pads stop flashing only when reinitialized, we'll send them the initialization packet so they calm down too. Signed-off-by: Cameron Gutman --- Sending this

[PATCH v9 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

This patch adds thermal driver for ZTE's zx2967 family. Signed-off-by: Baoyou Xie --- drivers/thermal/Kconfig | 8 ++ drivers/thermal/Makefile | 1 + drivers/thermal/zx2967_thermal.c | 258 +++ 3 files changed, 267

[PATCH v9 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture

Add the zx2967 thermal drivers as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4e81e2b..2a84440 100644 ---

[PATCH v9 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

This patch adds thermal driver for ZTE's zx2967 family. Signed-off-by: Baoyou Xie --- drivers/thermal/Kconfig | 8 ++ drivers/thermal/Makefile | 1 + drivers/thermal/zx2967_thermal.c | 258 +++ 3 files changed, 267 insertions(+) create

[PATCH v9 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture

Add the zx2967 thermal drivers as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4e81e2b..2a84440 100644 --- a/MAINTAINERS +++

[PATCH v9 1/3] dt: bindings: add documentation for zx2967 family thermal sensor

This patch adds dt-binding documentation for zx2967 family thermal sensor. Signed-off-by: Baoyou Xie Acked-by: Rob Herring Reviewed-by: Shawn Guo --- .../devicetree/bindings/thermal/zx2967-thermal.txt | 116 + 1

[PATCH v9 1/3] dt: bindings: add documentation for zx2967 family thermal sensor

This patch adds dt-binding documentation for zx2967 family thermal sensor. Signed-off-by: Baoyou Xie Acked-by: Rob Herring Reviewed-by: Shawn Guo --- .../devicetree/bindings/thermal/zx2967-thermal.txt | 116 + 1 file changed, 116 insertions(+) create mode 100644

Re: Linux 4.10-rc7

On Mon, Feb 6, 2017 at 4:22 PM, Dave Jones wrote: > On Mon, Feb 06, 2017 at 09:19:24AM +0100, Christoph Hellwig wrote: > > > > Double mnt_want_write, no idea why lockdep isn't reporting that for me. > > Fix below: > > Yep, seems to do the trick. > > Tested-by: Dave

Re: [PATCH 5/5] regulator: core: lower severity level of message about using dummy supplies

On Sun, Feb 05, 2017 at 05:12:46PM +0100, Mark Brown wrote: > On Sat, Feb 04, 2017 at 09:45:02AM -0800, Dmitry Torokhov wrote: > > On Sat, Feb 04, 2017 at 12:48:19PM +0100, Mark Brown wrote: > > > > It really shouldn't be either of these things, at least on DT systems. > > > But it definitely

Re: Linux 4.10-rc7

On Mon, Feb 6, 2017 at 4:22 PM, Dave Jones wrote: > On Mon, Feb 06, 2017 at 09:19:24AM +0100, Christoph Hellwig wrote: > > > > Double mnt_want_write, no idea why lockdep isn't reporting that for me. > > Fix below: > > Yep, seems to do the trick. > > Tested-by: Dave Jones Christop, mind

Re: [PATCH 5/5] regulator: core: lower severity level of message about using dummy supplies

On Sun, Feb 05, 2017 at 05:12:46PM +0100, Mark Brown wrote: > On Sat, Feb 04, 2017 at 09:45:02AM -0800, Dmitry Torokhov wrote: > > On Sat, Feb 04, 2017 at 12:48:19PM +0100, Mark Brown wrote: > > > > It really shouldn't be either of these things, at least on DT systems. > > > But it definitely

Re: [PATCH v2 1/3] perf tools: Use offset instead of dwarfnum in register table.

On Mon, 6 Feb 2017 13:02:29 + Will Deacon wrote: > On Sat, Feb 04, 2017 at 05:03:20PM +0800, Hekuang wrote: > > hi > > > > 在 2017/2/3 21:00, Will Deacon 写道: > > >On Fri, Feb 03, 2017 at 11:06:05AM +, He Kuang wrote: > > >>This patch changes the 'dwarfnum' to

Re: [PATCH v2 1/3] perf tools: Use offset instead of dwarfnum in register table.

On Mon, 6 Feb 2017 13:02:29 + Will Deacon wrote: > On Sat, Feb 04, 2017 at 05:03:20PM +0800, Hekuang wrote: > > hi > > > > 在 2017/2/3 21:00, Will Deacon 写道: > > >On Fri, Feb 03, 2017 at 11:06:05AM +, He Kuang wrote: > > >>This patch changes the 'dwarfnum' to 'offset' in register table,

Re: modules: mark __inittest/__exittest as __maybe_unused

+++ Arnd Bergmann [01/02/17 18:00 +0100]: clang warns about unused inline functions by default: arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' [-Wunused-function] arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' [-Wunused-function]

Re: modules: mark __inittest/__exittest as __maybe_unused

+++ Arnd Bergmann [01/02/17 18:00 +0100]: clang warns about unused inline functions by default: arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' [-Wunused-function] arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' [-Wunused-function]

Re: [PATCH 4/4] regulator: core: make bulk API support optional supplies

On Mon, Feb 06, 2017 at 04:21:18PM -0800, Bjorn Andersson wrote: > On Fri 03 Feb 15:16 PST 2017, Dmitry Torokhov wrote: > > > Make it possible to use the bulk API with optional supplies, by allowing > > the consumer to marking supplies as optional in the regulator_bulk_data. > > > > Based on

Re: [PATCH 4/4] regulator: core: make bulk API support optional supplies

On Mon, Feb 06, 2017 at 04:21:18PM -0800, Bjorn Andersson wrote: > On Fri 03 Feb 15:16 PST 2017, Dmitry Torokhov wrote: > > > Make it possible to use the bulk API with optional supplies, by allowing > > the consumer to marking supplies as optional in the regulator_bulk_data. > > > > Based on

Re: [Regression 4.7-rc1] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl

On 1/9/17 6:28 AM, David Sterba wrote: > On Fri, Jan 06, 2017 at 12:22:34PM -0500, Joseph Salisbury wrote: >> A kernel bug report was opened against Ubuntu [0]. This bug was fixed >> by the following commit in v4.7-rc1: >> >> commit 4c63c2454eff996c5e27991221106eb511f7db38 >> >> Author: Luke

Re: [Regression 4.7-rc1] btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl

On 1/9/17 6:28 AM, David Sterba wrote: > On Fri, Jan 06, 2017 at 12:22:34PM -0500, Joseph Salisbury wrote: >> A kernel bug report was opened against Ubuntu [0]. This bug was fixed >> by the following commit in v4.7-rc1: >> >> commit 4c63c2454eff996c5e27991221106eb511f7db38 >> >> Author: Luke

Re: [PATCH v6 1/4] mm/migration: make isolate_movable_page() return int type

On Fri, Feb 03, 2017 at 03:59:27PM +0800, Yisheng Xie wrote: > Change the return type of isolate_movable_page() from bool to int. It > will return 0 when isolate movable page successfully, and return -EBUSY > when it isolates failed. > > There is no functional change within this patch but

[tip:WIP.sched/core 138/170] arch/mips/loongson64/loongson-3/smp.c:393:32: note: in expansion of macro '__KSTK_TOS'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/core head: 8b88220c2b48c511c3dc8210d92a1d99d180dd69 commit: b8dca9f8769ff647742c30f21f5fab0b6a591578 [138/170] sched/headers: Split out of config: mips-loongson3_defconfig (attached as .config) compiler:

Re: [PATCH v6 1/4] mm/migration: make isolate_movable_page() return int type

On Fri, Feb 03, 2017 at 03:59:27PM +0800, Yisheng Xie wrote: > Change the return type of isolate_movable_page() from bool to int. It > will return 0 when isolate movable page successfully, and return -EBUSY > when it isolates failed. > > There is no functional change within this patch but

[tip:WIP.sched/core 138/170] arch/mips/loongson64/loongson-3/smp.c:393:32: note: in expansion of macro '__KSTK_TOS'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/core head: 8b88220c2b48c511c3dc8210d92a1d99d180dd69 commit: b8dca9f8769ff647742c30f21f5fab0b6a591578 [138/170] sched/headers: Split out of config: mips-loongson3_defconfig (attached as .config) compiler:

Re: [PATCH] scripts/spelling.txt: fix incorrect typo-words

On Mon, 2017-02-06 at 12:34 -0700, Ross Zwisler wrote: > Fix up some incorrect typo-words. Heh. Thanks. Spelling corrections that aren't spelled correctly aren't worth much. > diff --git a/scripts/spelling.txt b/scripts/spelling.txt [] > @@ -632,7 +632,7 @@ libaries||libraries >

Re: [PATCH] scripts/spelling.txt: fix incorrect typo-words

On Mon, 2017-02-06 at 12:34 -0700, Ross Zwisler wrote: > Fix up some incorrect typo-words. Heh. Thanks. Spelling corrections that aren't spelled correctly aren't worth much. > diff --git a/scripts/spelling.txt b/scripts/spelling.txt [] > @@ -632,7 +632,7 @@ libaries||libraries >

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

On Mon, Feb 6, 2017 at 3:27 PM, Luck, Tony wrote: >> cgroup mode gives a per-CPU breakdown of event and running time, the >> tool aggregates it into running time vs event count. Both per-cpu >> breakdown and the aggregate are useful. >> >> Piggy-backing on perf's cgroup mode

Re: [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec()

On Fri, Feb 3, 2017 at 1:20 PM, Luis R. Rodriguez wrote: > When we igmpv3_add_delrec() we kzalloc the pmc, but when users > calligmpv3_del_delrec() we never free the pmc. This was caught > by the following kmemleak splat: > > unreferenced object 0x99666ff43b40 (size

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

On Mon, Feb 6, 2017 at 3:27 PM, Luck, Tony wrote: >> cgroup mode gives a per-CPU breakdown of event and running time, the >> tool aggregates it into running time vs event count. Both per-cpu >> breakdown and the aggregate are useful. >> >> Piggy-backing on perf's cgroup mode would give us all the

Re: [RFC] igmp: address pmc kmemleak from on igmpv3_del_delrec()

On Fri, Feb 3, 2017 at 1:20 PM, Luis R. Rodriguez wrote: > When we igmpv3_add_delrec() we kzalloc the pmc, but when users > calligmpv3_del_delrec() we never free the pmc. This was caught > by the following kmemleak splat: > > unreferenced object 0x99666ff43b40 (size 192): > comm

[PATCHv3 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

There are multiple architectures that support CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX. These options also now have the ability to be turned off at runtime. Move these to an architecture independent location and make these options def_bool y for almost all of those arches. Signed-off-by:

[PATCHv3 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common

There are multiple architectures that support CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX. These options also now have the ability to be turned off at runtime. Move these to an architecture independent location and make these options def_bool y for almost all of those arches. Signed-off-by:

[PATCHv3 0/2] Hardening configs refactor/rename

Hi, This is v3 of my series to rename/refactor CONFIG_DEBUG_RODATA and CONFIG_DEBUG_SET_MODULE_RONX. Among other objections, there shouldn't be 'debug' in the name since these provide necessary kernel protection. v3 mostly focuses on changing how the Kconfig dependencies work for the refactor.

[PATCHv3 0/2] Hardening configs refactor/rename

Hi, This is v3 of my series to rename/refactor CONFIG_DEBUG_RODATA and CONFIG_DEBUG_SET_MODULE_RONX. Among other objections, there shouldn't be 'debug' in the name since these provide necessary kernel protection. v3 mostly focuses on changing how the Kconfig dependencies work for the refactor.

[PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

Both of these options are poorly named. The features they provide are necessary for system security and should not be considered debug only. Change the names to CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX to better describe what these options do. Signed-off-by: Laura Abbott

[PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

Both of these options are poorly named. The features they provide are necessary for system security and should not be considered debug only. Change the names to CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX to better describe what these options do. Signed-off-by: Laura Abbott --- v3:

Re: Linux 4.10-rc7

On Mon, Feb 06, 2017 at 09:19:24AM +0100, Christoph Hellwig wrote: > On Mon, Feb 06, 2017 at 01:00:32AM -0500, Dave Jones wrote: > > This one smells funny to me. > > Double mnt_want_write, no idea why lockdep isn't reporting that for me. > Fix below: Yep, seems to do the trick. Tested-by:

Re: [PATCH] slub: make sysfs directories for memcg sub-caches optional

On Sat, 4 Feb 2017 09:52:03 -0500 Tejun Heo wrote: > SLUB creates a per-cache directory under /sys/kernel/slab which hosts > a bunch of debug files. Usually, there aren't that many caches on a > system and this doesn't really matter; however, if memcg is in use, > each cache

Re: Linux 4.10-rc7

On Mon, Feb 06, 2017 at 09:19:24AM +0100, Christoph Hellwig wrote: > On Mon, Feb 06, 2017 at 01:00:32AM -0500, Dave Jones wrote: > > This one smells funny to me. > > Double mnt_want_write, no idea why lockdep isn't reporting that for me. > Fix below: Yep, seems to do the trick. Tested-by:

Re: [PATCH] slub: make sysfs directories for memcg sub-caches optional

On Sat, 4 Feb 2017 09:52:03 -0500 Tejun Heo wrote: > SLUB creates a per-cache directory under /sys/kernel/slab which hosts > a bunch of debug files. Usually, there aren't that many caches on a > system and this doesn't really matter; however, if memcg is in use, > each cache can have per-cgroup

Re: [PATCH 4/4] regulator: core: make bulk API support optional supplies

On Fri 03 Feb 15:16 PST 2017, Dmitry Torokhov wrote: > Make it possible to use the bulk API with optional supplies, by allowing > the consumer to marking supplies as optional in the regulator_bulk_data. > > Based on earlier patch by Bjorn Andersson > Hi Dmitry,

Re: [PATCH 4/4] regulator: core: make bulk API support optional supplies

On Fri 03 Feb 15:16 PST 2017, Dmitry Torokhov wrote: > Make it possible to use the bulk API with optional supplies, by allowing > the consumer to marking supplies as optional in the regulator_bulk_data. > > Based on earlier patch by Bjorn Andersson > Hi Dmitry, Rather than fixing my broken

Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote: > On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig wrote: > > Dan, > > > > can you please quote your emails? I can't find any content > > inbetween all these quotes. > > Sorry, I'm using gmail, but I'll switch to attaching

Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote: > On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig wrote: > > Dan, > > > > can you please quote your emails? I can't find any content > > inbetween all these quotes. > > Sorry, I'm using gmail, but I'll switch to attaching the logs. > >

Re: [PATCH v1 2/2] clk: rockchip: describe clk_gmac using the new muxgrf type on rk3328

Hi Elaine, Am Montag, 6. Februar 2017, 10:50:35 CET schrieb Elaine Zhang: > With the newly introduced clk type for muxes in the grf we now can > describe some missing clocks, like the clk_gmac2io and clk_gmac2phy > that selects between clk_mac2io_src and gmac_clkin based on a bit > set in the

Re: [PATCH v1 2/2] clk: rockchip: describe clk_gmac using the new muxgrf type on rk3328

Hi Elaine, Am Montag, 6. Februar 2017, 10:50:35 CET schrieb Elaine Zhang: > With the newly introduced clk type for muxes in the grf we now can > describe some missing clocks, like the clk_gmac2io and clk_gmac2phy > that selects between clk_mac2io_src and gmac_clkin based on a bit > set in the

Re: [PATCH net-next 1/4] net: mv643xx_eth: Do not clobber PHY link outside of state machine

On Mon, Feb 06, 2017 at 03:55:20PM -0800, Florian Fainelli wrote: > Calling phy_read_status() means that we may call into > genphy_read_status() which in turn will use genphy_update_link() which > can make changes to phydev->link outside of the state machine's state > transitions. This is an

Re: [PATCH net-next 1/4] net: mv643xx_eth: Do not clobber PHY link outside of state machine

On Mon, Feb 06, 2017 at 03:55:20PM -0800, Florian Fainelli wrote: > Calling phy_read_status() means that we may call into > genphy_read_status() which in turn will use genphy_update_link() which > can make changes to phydev->link outside of the state machine's state > transitions. This is an

Re: [PATCH net-next 4/4] net: dsa: Do not clobber PHY link outside of state machine

On Mon, Feb 06, 2017 at 03:55:23PM -0800, Florian Fainelli wrote: > Calling phy_read_status() means that we may call into > genphy_read_status() which in turn will use genphy_update_link() which > can make changes to phydev->link outside of the state machine's state > transitions. This is an

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2017-02-06 at 16:52 -0500, J. Bruce Fields wrote: > On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote: > > On Mon, 2017-02-06 at 09:50 -0500, Theodore Ts'o wrote: > > > On Sun, Feb 05, 2017 at 10:46:23PM -0800, James Bottomley wrote: > > > > Yes, I know the problem. However,

Re: [PATCH net-next 4/4] net: dsa: Do not clobber PHY link outside of state machine

On Mon, Feb 06, 2017 at 03:55:23PM -0800, Florian Fainelli wrote: > Calling phy_read_status() means that we may call into > genphy_read_status() which in turn will use genphy_update_link() which > can make changes to phydev->link outside of the state machine's state > transitions. This is an

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

On Mon, 2017-02-06 at 16:52 -0500, J. Bruce Fields wrote: > On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote: > > On Mon, 2017-02-06 at 09:50 -0500, Theodore Ts'o wrote: > > > On Sun, Feb 05, 2017 at 10:46:23PM -0800, James Bottomley wrote: > > > > Yes, I know the problem. However,

Re: [PATCH] namei: Remove unlikely annotation for revalidate check in lookup_fast()

On Mon, Feb 06, 2017 at 05:17:35PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > The likely/unlikely profiler showed that the unlikely around the > dentry->d_flags & DCACHE_OP_REVALIDATE was wrong 95% of the time. Adding > trace_printk()s, it revealed

Re: [RESEND PATCH 1/1] usb: dwc2: add multiple clock handling

Hi Frank, Am Sonntag, 5. Februar 2017, 10:51:01 CET schrieb Frank Wang: > Originally, dwc2 just handle one clock named otg, however, it may have > two or more clock need to manage for some new SoCs, so this adds > change clk to clk's array of dwc2_hsotg to handle more clocks operation. > >

Re: [PATCH] namei: Remove unlikely annotation for revalidate check in lookup_fast()

On Mon, Feb 06, 2017 at 05:17:35PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > The likely/unlikely profiler showed that the unlikely around the > dentry->d_flags & DCACHE_OP_REVALIDATE was wrong 95% of the time. Adding > trace_printk()s, it revealed that the dentry ops had

Re: [RESEND PATCH 1/1] usb: dwc2: add multiple clock handling

Hi Frank, Am Sonntag, 5. Februar 2017, 10:51:01 CET schrieb Frank Wang: > Originally, dwc2 just handle one clock named otg, however, it may have > two or more clock need to manage for some new SoCs, so this adds > change clk to clk's array of dwc2_hsotg to handle more clocks operation. > >

Re: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86_64

On Mon, Feb 06, 2017 at 06:47:43PM +0100, Luis R. Rodriguez wrote: > Do we have any test units which can kick off regularly to test against > such type of regression in the future or is it not worth it? Yap, it is called: build new kernel and boot it the box :-) I always try to build and boot

Re: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86_64

On Mon, Feb 06, 2017 at 06:47:43PM +0100, Luis R. Rodriguez wrote: > Do we have any test units which can kick off regularly to test against > such type of regression in the future or is it not worth it? Yap, it is called: build new kernel and boot it the box :-) I always try to build and boot

Re: [PATCH 1/2] sigaltstack: support SS_AUTODISARM for CONFIG_COMPAT

On Mon, 6 Feb 2017 12:30:38 +0300 Stas Sergeev wrote: > 05.02.2017 21:31, Andy Lutomirski __: > > On Sun, Feb 5, 2017 at 2:12 AM, Stas Sergeev wrote: > >> Currently SS_AUTODISARM is not supported in compatibility > >> mode, but does not return -EINVAL either.

Re: [PATCH v2] serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt

On 02/06/2017 03:30 PM, Douglas Anderson wrote: On a Rockchip rk3399-based board during suspend/resume testing, we found that we could get the console UART into a state where it would print this to the console a lot: serial8250: too much work for irq42 Followed eventually by: NMI

Re: [PATCH 1/2] sigaltstack: support SS_AUTODISARM for CONFIG_COMPAT

On Mon, 6 Feb 2017 12:30:38 +0300 Stas Sergeev wrote: > 05.02.2017 21:31, Andy Lutomirski __: > > On Sun, Feb 5, 2017 at 2:12 AM, Stas Sergeev wrote: > >> Currently SS_AUTODISARM is not supported in compatibility > >> mode, but does not return -EINVAL either. This makes dosemu > >>

Re: [PATCH v2] serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt

On 02/06/2017 03:30 PM, Douglas Anderson wrote: On a Rockchip rk3399-based board during suspend/resume testing, we found that we could get the console UART into a state where it would print this to the console a lot: serial8250: too much work for irq42 Followed eventually by: NMI

[PATCH] perf symbols: take in account symfs setting when reading file build ID

After 5baecbc 'perf symbols: we can now read separate debug-info files based on a build ID' and when --symfs option is used perf failed to pick up symbols for file with the same name between host and sysroot specified by --symfs option. One can see message like this: bin/bash with build id

[PATCH] perf symbols: take in account symfs setting when reading file build ID

After 5baecbc 'perf symbols: we can now read separate debug-info files based on a build ID' and when --symfs option is used perf failed to pick up symbols for file with the same name between host and sysroot specified by --symfs option. One can see message like this: bin/bash with build id

[PATCH net-next 1/4] net: mv643xx_eth: Do not clobber PHY link outside of state machine

Calling phy_read_status() means that we may call into genphy_read_status() which in turn will use genphy_update_link() which can make changes to phydev->link outside of the state machine's state transitions. This is an invalid behavior that is now caught as of 811a919135b9 ("phy state machine:

[PATCH net-next 0/4] net: Incorrect use of phy_read_status()

Hi all, This patch series removes incorrect uses of phy_read_status() which can clobber the PHY device link while we are executing with the state machine running. greth was potentially another candidate, but it does funky stuff with auto-negotation that I am still trying to understand. Florian

[PATCH net-next 1/4] net: mv643xx_eth: Do not clobber PHY link outside of state machine

Calling phy_read_status() means that we may call into genphy_read_status() which in turn will use genphy_update_link() which can make changes to phydev->link outside of the state machine's state transitions. This is an invalid behavior that is now caught as of 811a919135b9 ("phy state machine:

[PATCH net-next 0/4] net: Incorrect use of phy_read_status()

Hi all, This patch series removes incorrect uses of phy_read_status() which can clobber the PHY device link while we are executing with the state machine running. greth was potentially another candidate, but it does funky stuff with auto-negotation that I am still trying to understand. Florian

[PATCH net-next 4/4] net: dsa: Do not clobber PHY link outside of state machine

Calling phy_read_status() means that we may call into genphy_read_status() which in turn will use genphy_update_link() which can make changes to phydev->link outside of the state machine's state transitions. This is an invalid behavior that is now caught as of 811a919135b9 ("phy state machine:

[PATCH net-next 2/4] net: pxa168_eth: Do not clobber PHY link outside of state machine

Calling phy_read_status() means that we may call into genphy_read_status() which in turn will use genphy_update_link() which can make changes to phydev->link outside of the state machine's state transitions. This is an invalid behavior that is now caught as of 811a919135b9 ("phy state machine:

[PATCH net-next 3/4] net: netcp: Do not clobber PHY link outside of state machine

Calling phy_read_status() means that we may call into genphy_read_status() which in turn will use genphy_update_link() which can make changes to phydev->link outside of the state machine's state transitions. This is an invalid behavior that is now caught as off 811a919135b9 ("phy state machine:

Re: [RESEND PATCH 0/1] add multiple clock handling for dwc2 driver

Hi Frank, Am Montag, 6. Februar 2017, 09:40:35 CET schrieb Frank Wang: > On 2017/2/5 17:41, Heiko Stuebner wrote: > > Am Sonntag, 5. Februar 2017, 10:51:00 CET schrieb Frank Wang: > >> The original posting on Jan 19th have not received any responses, so I > >> resend them. > >> > >> The Current

[PATCH net-next 4/4] net: dsa: Do not clobber PHY link outside of state machine

Calling phy_read_status() means that we may call into genphy_read_status() which in turn will use genphy_update_link() which can make changes to phydev->link outside of the state machine's state transitions. This is an invalid behavior that is now caught as of 811a919135b9 ("phy state machine:

[PATCH net-next 2/4] net: pxa168_eth: Do not clobber PHY link outside of state machine

Calling phy_read_status() means that we may call into genphy_read_status() which in turn will use genphy_update_link() which can make changes to phydev->link outside of the state machine's state transitions. This is an invalid behavior that is now caught as of 811a919135b9 ("phy state machine:

[PATCH net-next 3/4] net: netcp: Do not clobber PHY link outside of state machine

Calling phy_read_status() means that we may call into genphy_read_status() which in turn will use genphy_update_link() which can make changes to phydev->link outside of the state machine's state transitions. This is an invalid behavior that is now caught as off 811a919135b9 ("phy state machine:

Re: [RESEND PATCH 0/1] add multiple clock handling for dwc2 driver

Hi Frank, Am Montag, 6. Februar 2017, 09:40:35 CET schrieb Frank Wang: > On 2017/2/5 17:41, Heiko Stuebner wrote: > > Am Sonntag, 5. Februar 2017, 10:51:00 CET schrieb Frank Wang: > >> The original posting on Jan 19th have not received any responses, so I > >> resend them. > >> > >> The Current

RE: [Intel-wired-lan] [PATCH] net: intel: i40evf: use new api ethtool_{get|set}_link_ksettings

> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Philippe Reynes > Sent: Saturday, February 04, 2017 2:49 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: net...@vger.kernel.org;

RE: [Intel-wired-lan] [PATCH] net: intel: i40evf: use new api ethtool_{get|set}_link_ksettings

> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Philippe Reynes > Sent: Saturday, February 04, 2017 2:49 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- >

Re: [v2,2/5] userfaultfd: non-cooperative: add event for memory unmaps

On Sun, 5 Feb 2017 10:46:29 -0800 Guenter Roeck wrote: > On Fri, Jan 27, 2017 at 08:44:30PM +0200, Mike Rapoport wrote: > > When a non-cooperative userfaultfd monitor copies pages in the background, > > it may encounter regions that were already unmapped. Addition of > >

Re: [v2,2/5] userfaultfd: non-cooperative: add event for memory unmaps

On Sun, 5 Feb 2017 10:46:29 -0800 Guenter Roeck wrote: > On Fri, Jan 27, 2017 at 08:44:30PM +0200, Mike Rapoport wrote: > > When a non-cooperative userfaultfd monitor copies pages in the background, > > it may encounter regions that were already unmapped. Addition of > > UFFD_EVENT_UNMAP allows

Re: [PATCH] gpio: dwapb: Add support for next generation of X-Gene SoC

Resend with plain text. Hi Linus, On Mon, Feb 6, 2017 at 2:21 AM, Linus Walleij wrote: > On Tue, Jan 31, 2017 at 8:43 PM, Hoan Tran wrote: > >> Next generation of X-Gene SoC's GPIO hardware register map is very >> similar to DW GPIO. It only differs

Re: [PATCH] gpio: dwapb: Add support for next generation of X-Gene SoC

Resend with plain text. Hi Linus, On Mon, Feb 6, 2017 at 2:21 AM, Linus Walleij wrote: > On Tue, Jan 31, 2017 at 8:43 PM, Hoan Tran wrote: > >> Next generation of X-Gene SoC's GPIO hardware register map is very >> similar to DW GPIO. It only differs by a few register addresses. >> This patch

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