Re: [PATCH] kbuild: fix header installation under fakechroot environment

Hi Richard, 2017-06-15 17:36 GMT+09:00 Richard Genoud : > Since commit fcc8487d477a ("uapi: export all headers under uapi > directories") fakechroot make bindeb-pkg fails, mismatching files for > directories: > touch: cannot touch 'usr/include/video/uvesafb.h/.install':

Re: [PATCH] kbuild: fix header installation under fakechroot environment

Hi Richard, 2017-06-15 17:36 GMT+09:00 Richard Genoud : > Since commit fcc8487d477a ("uapi: export all headers under uapi > directories") fakechroot make bindeb-pkg fails, mismatching files for > directories: > touch: cannot touch 'usr/include/video/uvesafb.h/.install': Not a > directory > >

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski wrote: > On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu wrote: >> On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote: >>> On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote:

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski wrote: > On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu wrote: >> On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote: >>> On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote: On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote: > On Thu,

Re: [PATCH] autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL

On Thu, Jun 15 2017, Andrew Morton wrote: > On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown wrote: > >> >> If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL >> ioctl, autofs4_d_automount() will return >>ERR_PTR(status) >> with that status to follow_automount(),

Re: [PATCH] autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL

On Thu, Jun 15 2017, Andrew Morton wrote: > On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown wrote: > >> >> If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL >> ioctl, autofs4_d_automount() will return >>ERR_PTR(status) >> with that status to follow_automount(), which will then >>

linux-next: build failure after merge of the sound-asoc tree

; ^ Caused by commit c3a3d3c41b74 ("ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'") I have used the sound-asoc tree from next-20170615 for today. -- Cheers, Stephen Rothwell

linux-next: build failure after merge of the sound-asoc tree

; ^ Caused by commit c3a3d3c41b74 ("ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'") I have used the sound-asoc tree from next-20170615 for today. -- Cheers, Stephen Rothwell

Re: [PATCH] Convert multiple netdev_info messages to netdev_dbg

On Thu, 2017-06-15 at 18:49 -0700, Jay Vosburgh wrote: > Joe Perches wrote: > > > On Thu, 2017-06-15 at 19:14 +0100, Michael J Dilmore wrote: > > > Multiple netdev_info messages clutter kernel output. Also add netdev_dbg > > > for packets per slave. > > > > [] > > > diff

Re: [PATCH] Convert multiple netdev_info messages to netdev_dbg

On Thu, 2017-06-15 at 18:49 -0700, Jay Vosburgh wrote: > Joe Perches wrote: > > > On Thu, 2017-06-15 at 19:14 +0100, Michael J Dilmore wrote: > > > Multiple netdev_info messages clutter kernel output. Also add netdev_dbg > > > for packets per slave. > > > > [] > > > diff --git

Re: [PATCH 2/3] printk/console: Clean up logic around fallback console

On (06/15/17 17:31), Petr Mladek wrote: [..] > > diff --git a/include/linux/console.h b/include/linux/console.h > > index b8920a031a3e..a2525e0d7605 100644 > > --- a/include/linux/console.h > > +++ b/include/linux/console.h > > @@ -127,7 +127,7 @@ static inline int con_debug_leave(void) > > */ >

Re: [PATCH 2/3] printk/console: Clean up logic around fallback console

On (06/15/17 17:31), Petr Mladek wrote: [..] > > diff --git a/include/linux/console.h b/include/linux/console.h > > index b8920a031a3e..a2525e0d7605 100644 > > --- a/include/linux/console.h > > +++ b/include/linux/console.h > > @@ -127,7 +127,7 @@ static inline int con_debug_leave(void) > > */ >

Re: [PATCH 3/3] printk/console: Always have a preferred console

On (06/15/17 16:54), Petr Mladek wrote: > On Wed 2017-06-14 18:11:28, Sergey Senozhatsky wrote: > > On (06/13/17 14:54), Petr Mladek wrote: > > > > > This patch modifies the code that enables the configured consoles. > > > It sets the CON_CONSDEV flag also when we register the first > > >

Re: [PATCH 3/3] printk/console: Always have a preferred console

On (06/15/17 16:54), Petr Mladek wrote: > On Wed 2017-06-14 18:11:28, Sergey Senozhatsky wrote: > > On (06/13/17 14:54), Petr Mladek wrote: > > > > > This patch modifies the code that enables the configured consoles. > > > It sets the CON_CONSDEV flag also when we register the first > > >

Re: [PATCH] MIPS: Make individual platforms select ARCH_MIGHT_HAVE_PC_SERIO

On Mon, 5 Jun 2017, Florian Fainelli wrote: > Out of the many MIPS platforms only 3 appear to be actually using an > I8042 keyboard controller: SGI, JAZZ and LOOGSON64, remove > ARCH_MIGHT_HAVE_PC_SERIO from the top-level MIPS Kconfig symbol and move > it down to those platforms that need it.

Re: [PATCH] MIPS: Make individual platforms select ARCH_MIGHT_HAVE_PC_SERIO

On Mon, 5 Jun 2017, Florian Fainelli wrote: > Out of the many MIPS platforms only 3 appear to be actually using an > I8042 keyboard controller: SGI, JAZZ and LOOGSON64, remove > ARCH_MIGHT_HAVE_PC_SERIO from the top-level MIPS Kconfig symbol and move > it down to those platforms that need it.

Re: [PATCH] Convert multiple netdev_info messages to netdev_dbg

Joe Perches wrote: >On Thu, 2017-06-15 at 19:14 +0100, Michael J Dilmore wrote: >> Multiple netdev_info messages clutter kernel output. Also add netdev_dbg for >> packets per slave. >[] >> diff --git a/drivers/net/bonding/bond_options.c >> b/drivers/net/bonding/bond_options.c

Re: [PATCH] Convert multiple netdev_info messages to netdev_dbg

Joe Perches wrote: >On Thu, 2017-06-15 at 19:14 +0100, Michael J Dilmore wrote: >> Multiple netdev_info messages clutter kernel output. Also add netdev_dbg for >> packets per slave. >[] >> diff --git a/drivers/net/bonding/bond_options.c >> b/drivers/net/bonding/bond_options.c >[] >> @@ -9,6

[PATCH] kernel/kallsyms: replace all_var with IS_ENABLED(CONFIG_KALLSYMS_ALL)

The "all_var" looks like a variable, but is actually a macro. Use IS_ENABLED(CONFIG_KALLSYMS_ALL) for clarification. Signed-off-by: Masahiro Yamada --- kernel/kallsyms.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git

[PATCH] kernel/kallsyms: replace all_var with IS_ENABLED(CONFIG_KALLSYMS_ALL)

The "all_var" looks like a variable, but is actually a macro. Use IS_ENABLED(CONFIG_KALLSYMS_ALL) for clarification. Signed-off-by: Masahiro Yamada --- kernel/kallsyms.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c index

Re: [PATCH v5 0/4] of: remove *phandle properties from expanded device tree

On 06/15/17 17:06, Benjamin Herrenschmidt wrote: > On Fri, 2017-06-09 at 22:47 -0700, frowand.l...@gmail.com wrote: >> From: Frank Rowand >> >> Remove "phandle" and "linux,phandle" properties from the internal >> device tree. The phandle will still be in the struct

Re: [PATCH v5 0/4] of: remove *phandle properties from expanded device tree

On 06/15/17 17:06, Benjamin Herrenschmidt wrote: > On Fri, 2017-06-09 at 22:47 -0700, frowand.l...@gmail.com wrote: >> From: Frank Rowand >> >> Remove "phandle" and "linux,phandle" properties from the internal >> device tree. The phandle will still be in the struct device_node >> phandle field.

linux-next: build failure after merge of the kspp tree

Hi Kees, After merging the kspp tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/bitmap.h:8:0, from include/linux/cpumask.h:11, from arch/x86/include/asm/cpumask.h:4, from

linux-next: build failure after merge of the kspp tree

Hi Kees, After merging the kspp tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/bitmap.h:8:0, from include/linux/cpumask.h:11, from arch/x86/include/asm/cpumask.h:4, from

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

Hi Kees, On Thu, 15 Jun 2017 17:35:43 -0700 Kees Cook wrote: > > Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it). And that just made it in time for today's linux-next. I have removed the patches from Andrew's tree. -- Cheers, Stephen

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

Hi Kees, On Thu, 15 Jun 2017 17:35:43 -0700 Kees Cook wrote: > > Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it). And that just made it in time for today's linux-next. I have removed the patches from Andrew's tree. -- Cheers, Stephen Rothwell

Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c

Hi Michael, On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman wrote: > > "Rowand, Frank" writes: > > > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem > > [mailto:abdha...@linux.vnet.ibm.com] wrote: > >> > >> On Thu, 2017-06-15 at 11:30 +0530,

Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c

Hi Michael, On Fri, 16 Jun 2017 10:57:22 +1000 Michael Ellerman wrote: > > "Rowand, Frank" writes: > > > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem > > [mailto:abdha...@linux.vnet.ibm.com] wrote: > >> > >> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote: > >>> > >>>

Re: [PATCH v4 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On 2017/6/13 5:28, Alexander Duyck wrote: > On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong > wrote: ... >> /** >> + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit >> + * @dev: PCI device to query >> + * >> + * If possible clear relaxed ordering

Re: [PATCH v4 2/3] PCI: Enable PCIe Relaxed Ordering if supported

On 2017/6/13 5:28, Alexander Duyck wrote: > On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong > wrote: ... >> /** >> + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit >> + * @dev: PCI device to query >> + * >> + * If possible clear relaxed ordering >> + */ >> +int

linux-next: manual merge of the drm-tegra tree with the drm tree

Hi Thierry, Today's linux-next merge of the drm-tegra tree got a conflict in: Documentation/gpu/index.rst between commit: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111") from the drm tree and commit: fa6d095eb23a ("drm/tegra: Add driver documentation") from the drm-tegra

linux-next: manual merge of the drm-tegra tree with the drm tree

Hi Thierry, Today's linux-next merge of the drm-tegra tree got a conflict in: Documentation/gpu/index.rst between commit: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111") from the drm tree and commit: fa6d095eb23a ("drm/tegra: Add driver documentation") from the drm-tegra

[PATCH v3 1/2] tcp: md5: add an address prefix for key lookup

This allows the keys used for TCP MD5 signature to be used for whole range of addresses, specified with a prefix length, instead of only one address as it currently is. Signed-off-by: Bob Gilligan Signed-off-by: Eric Mowat Signed-off-by: Ivan Delalande

[PATCH v3 1/2] tcp: md5: add an address prefix for key lookup

This allows the keys used for TCP MD5 signature to be used for whole range of addresses, specified with a prefix length, instead of only one address as it currently is. Signed-off-by: Bob Gilligan Signed-off-by: Eric Mowat Signed-off-by: Ivan Delalande --- include/net/tcp.h | 6 +++--

[PATCH v3 2/2] tcp: md5: add TCP_MD5SIG_EXT socket option to set a key address prefix

Replace first padding in the tcp_md5sig structure with a new flag field and address prefix length so it can be specified when configuring a new key for TCP MD5 signature. The tcpm_flags field will only be used if the socket option is TCP_MD5SIG_EXT to avoid breaking existing programs, and

[PATCH v3 2/2] tcp: md5: add TCP_MD5SIG_EXT socket option to set a key address prefix

Replace first padding in the tcp_md5sig structure with a new flag field and address prefix length so it can be specified when configuring a new key for TCP MD5 signature. The tcpm_flags field will only be used if the socket option is TCP_MD5SIG_EXT to avoid breaking existing programs, and

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

On Thu, Jun 15, 2017 at 10:56:29AM -0700, Paul E. McKenney wrote: [...] > > > > > > FWLIW, I agree. There was a smb_mb() in RT-linux's equivalent of > > > swait_activate(). > > > > > > https://www.spinics.net/lists/linux-rt-users/msg10340.html > > > > > > If the barrier goes in swait_active()

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

On Thu, Jun 15, 2017 at 10:56:29AM -0700, Paul E. McKenney wrote: [...] > > > > > > FWLIW, I agree. There was a smb_mb() in RT-linux's equivalent of > > > swait_activate(). > > > > > > https://www.spinics.net/lists/linux-rt-users/msg10340.html > > > > > > If the barrier goes in swait_active()

RE: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c

"Rowand, Frank" writes: > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem > [mailto:abdha...@linux.vnet.ibm.com] wrote: >> >> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote: >>> Hi, >>> >>> linux-next fails to boot on powerpc Bare-metal with these warnings. >>>

RE: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c

"Rowand, Frank" writes: > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem > [mailto:abdha...@linux.vnet.ibm.com] wrote: >> >> On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote: >>> Hi, >>> >>> linux-next fails to boot on powerpc Bare-metal with these warnings. >>> >>> machine booted fine

Re: Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 15:03:17, David Rientjes wrote: > > On Thu, 15 Jun 2017, Michal Hocko wrote: > > > > > > Yes, quite a bit in testing. > > > > > > > > One oom kill shows the system to be oom: > > > > > > > > [22999.488705] Node 0 Normal free:90484kB min:90500kB ... > > > >

Re: Re: [patch] mm, oom: prevent additional oom kills before memory is freed

Michal Hocko wrote: > On Thu 15-06-17 15:03:17, David Rientjes wrote: > > On Thu, 15 Jun 2017, Michal Hocko wrote: > > > > > > Yes, quite a bit in testing. > > > > > > > > One oom kill shows the system to be oom: > > > > > > > > [22999.488705] Node 0 Normal free:90484kB min:90500kB ... > > > >

RE: [PATCH] PCI: imx6: add regulator support

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Friday, June 16, 2017 5:06 AM > To: Quentin Schulz > Cc: Richard Zhu ; l.st...@pengutronix.de; > bhelg...@google.com; robh...@kernel.org;

RE: [PATCH] PCI: imx6: add regulator support

> -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Friday, June 16, 2017 5:06 AM > To: Quentin Schulz > Cc: Richard Zhu ; l.st...@pengutronix.de; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > thomas.petazz...@free-electrons.com;

Re: [PATCH v3 1/3] kbuild: Add __cc-option macro

2017-06-16 2:37 GMT+09:00 Matthias Kaehlcke : > cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines > whether an option is supported or not. This is fine for options used to > build the kernel itself, however some components like the x86 boot code > use a

Re: [PATCH v3 1/3] kbuild: Add __cc-option macro

2017-06-16 2:37 GMT+09:00 Matthias Kaehlcke : > cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines > whether an option is supported or not. This is fine for options used to > build the kernel itself, however some components like the x86 boot code > use a different set of flags. >

Re: [RFC v2 1/2] swait: add idle variants which don't contribute to load average

On Thu, Jun 15, 2017 at 11:48:19AM -0700, Luis R. Rodriguez wrote: > There are cases where folks are using an interruptible swait when > using kthreads. This is rather confusing given you'd expect > interruptible waits to be -- interruptible, but kthreads are not > interruptible ! The reason for

Re: [RFC v2 1/2] swait: add idle variants which don't contribute to load average

On Thu, Jun 15, 2017 at 11:48:19AM -0700, Luis R. Rodriguez wrote: > There are cases where folks are using an interruptible swait when > using kthreads. This is rather confusing given you'd expect > interruptible waits to be -- interruptible, but kthreads are not > interruptible ! The reason for

Re: [PATCH 4.11 00/13] 4.11.6-stable review

On 06/15/2017 10:54 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.11.6 release. There are 13 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.11 00/13] 4.11.6-stable review

On 06/15/2017 10:54 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.11.6 release. There are 13 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/46] 4.4.73-stable review

On 06/15/2017 10:52 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.73 release. There are 46 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/46] 4.4.73-stable review

On 06/15/2017 10:52 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.73 release. There are 46 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 000/108] 4.9.33-stable review

On 06/15/2017 10:52 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.33 release. There are 108 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 000/108] 4.9.33-stable review

On 06/15/2017 10:52 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.33 release. There are 108 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

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

On Thu, Jun 15, 2017 at 5:05 PM, Daniel Micay wrote: > On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote: >> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton >> wrote: >> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook >> >

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

On Thu, Jun 15, 2017 at 5:05 PM, Daniel Micay wrote: > On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote: >> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton >> wrote: >> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook >> > wrote: >> > >> > > > > Caused by commit >> > > > > >> > > > >

Re: [PATCH net-next] net: dsa: add cross-chip multicast support

On 06/15/2017 01:14 PM, Vivien Didelot wrote: > Similarly to how cross-chip VLAN works, define a bitmap of multicast > group members for a switch, now including its DSA ports, so that > multicast traffic can be sent to all switches of the fabric. > > A switch may drop the frames if no user port

Re: [PATCH net-next] net: dsa: add cross-chip multicast support

On 06/15/2017 01:14 PM, Vivien Didelot wrote: > Similarly to how cross-chip VLAN works, define a bitmap of multicast > group members for a switch, now including its DSA ports, so that > multicast traffic can be sent to all switches of the fabric. > > A switch may drop the frames if no user port

Re: [PATCH] Unexport LANG env variable

Hi Alexey, 2017-06-14 22:11 GMT+09:00 Alexey Brodkin : > Hi Michal, > > On Wed, 2017-06-14 at 15:02 +0200, Michal Marek wrote: >> Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a): >> > >> > In those cases when we parse output of standard utilities like readelf >> > etc

Re: [PATCH] Unexport LANG env variable

Hi Alexey, 2017-06-14 22:11 GMT+09:00 Alexey Brodkin : > Hi Michal, > > On Wed, 2017-06-14 at 15:02 +0200, Michal Marek wrote: >> Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a): >> > >> > In those cases when we parse output of standard utilities like readelf >> > etc we rely on a particular

[PATCH] Support PTP Stick and Touchpad device

From: Masaki Ota - Support PTP Stick and Touchpad device. - This Touchpad is Precision Touchpad(PTP), and Stick Pointer data is the same as Mouse. - Stick Pointer works as Mouse. Signed-off-by: Masaki Ota --- drivers/hid/hid-ids.h| 2 ++

[PATCH] Support PTP Stick and Touchpad device

From: Masaki Ota - Support PTP Stick and Touchpad device. - This Touchpad is Precision Touchpad(PTP), and Stick Pointer data is the same as Mouse. - Stick Pointer works as Mouse. Signed-off-by: Masaki Ota --- drivers/hid/hid-ids.h| 2 ++ drivers/hid/hid-multitouch.c | 23

Re: [PATCH 11/35] hexagon: defconfig: Cleanup from old Kconfig options

On Thu, Jun 08, 2017 at 06:10:22PM +0200, Krzysztof Kozlowski wrote: > Remove old, dead Kconfig options (in order appearing in this commit): > - EXPERIMENTAL is gone since v3.9; > - NETDEV_1000 and NETDEV_1: commit f860b0522f65 ("drivers/net: >Kconfig and Makefile cleanup"); NET_ETHERNET

Re: [PATCH 11/35] hexagon: defconfig: Cleanup from old Kconfig options

On Thu, Jun 08, 2017 at 06:10:22PM +0200, Krzysztof Kozlowski wrote: > Remove old, dead Kconfig options (in order appearing in this commit): > - EXPERIMENTAL is gone since v3.9; > - NETDEV_1000 and NETDEV_1: commit f860b0522f65 ("drivers/net: >Kconfig and Makefile cleanup"); NET_ETHERNET

Re: [PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

On Thu, Jun 08, 2017 at 03:25:56PM +0200, Christoph Hellwig wrote: > This implementation is simply bogus - hexagon only has a simple > direct mapped DMA implementation and thus doesn't care about the > address. > > Signed-off-by: Christoph Hellwig > --- >

Re: [PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

On Thu, Jun 08, 2017 at 03:25:56PM +0200, Christoph Hellwig wrote: > This implementation is simply bogus - hexagon only has a simple > direct mapped DMA implementation and thus doesn't care about the > address. > > Signed-off-by: Christoph Hellwig > --- > arch/hexagon/include/asm/dma-mapping.h

Re: [PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

On Thu, Jun 08, 2017 at 03:25:42PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > arch/hexagon/include/asm/dma-mapping.h | 2 -- > arch/hexagon/kernel/dma.c | 12 +--- > arch/hexagon/kernel/hexagon_ksyms.c| 1 - > 3 files

Re: [PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

On Thu, Jun 08, 2017 at 03:25:42PM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > arch/hexagon/include/asm/dma-mapping.h | 2 -- > arch/hexagon/kernel/dma.c | 12 +--- > arch/hexagon/kernel/hexagon_ksyms.c| 1 - > 3 files changed, 9

[no subject]

[no subject]

Re: [PATCH v5 0/4] of: remove *phandle properties from expanded device tree

On Fri, 2017-06-09 at 22:47 -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Remove "phandle" and "linux,phandle" properties from the internal > device tree.  The phandle will still be in the struct device_node > phandle field. > > This is to resolve the

Re: [PATCH v5 0/4] of: remove *phandle properties from expanded device tree

On Fri, 2017-06-09 at 22:47 -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Remove "phandle" and "linux,phandle" properties from the internal > device tree.  The phandle will still be in the struct device_node > phandle field. > > This is to resolve the issue found by Stephen Boyd

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

On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote: > On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton > wrote: > > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook > > wrote: > > > > > > > Caused by commit > > > > > > > > > > 088a5ecf7581

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

On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote: > On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton > wrote: > > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook > > wrote: > > > > > > > Caused by commit > > > > > > > > > > 088a5ecf7581 ("include/linux/string.h: add the option of > > > > >

Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c

On Thu, 2017-06-15 at 17:06 +, Rowand, Frank wrote: > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem > [mailto:abdha...@linux.vnet.ibm.com] wrote: > > > > On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote: > > > Hi, > > > > > > linux-next fails to boot on powerpc Bare-metal with

Re: [Oops][next-20170614][] powerpc boot fails with WARNING: CPU: 12 PID: 0 at mm/memblock.c

On Thu, 2017-06-15 at 17:06 +, Rowand, Frank wrote: > On Thursday, June 15, 2017 2:25 AM, Abdul Haleem > [mailto:abdha...@linux.vnet.ibm.com] wrote: > > > > On Thu, 2017-06-15 at 11:30 +0530, Abdul Haleem wrote: > > > Hi, > > > > > > linux-next fails to boot on powerpc Bare-metal with

RE: [PATCH net-next] net: dsa: add cross-chip multicast support

On 06/15/2017 1:15 PM, Vivien Didelot wrote: > Similarly to how cross-chip VLAN works, define a bitmap of multicast group > members for a switch, now including its DSA ports, so that multicast traffic > can be sent to all switches of the fabric. > > A switch may drop the frames if no user port is

RE: [PATCH net-next] net: dsa: add cross-chip multicast support

On 06/15/2017 1:15 PM, Vivien Didelot wrote: > Similarly to how cross-chip VLAN works, define a bitmap of multicast group > members for a switch, now including its DSA ports, so that multicast traffic > can be sent to all switches of the fabric. > > A switch may drop the frames if no user port is

Re: [PATCH v3 2/2] arm64: dts: add sp804 timer node for Hi3660

On Thu, Jun 15, 2017 at 09:00:58PM +0100, Wei Xu wrote: [...] > Since the dts part is not depended on the driver and Guodong has put this > into another > patch set[1], I will pick up that one. > Thanks! > > [1]: https://lkml.org/lkml/2017/6/14/1049 Yeah, thanks for picking up from Guodong's

Re: [PATCH v3 2/2] arm64: dts: add sp804 timer node for Hi3660

On Thu, Jun 15, 2017 at 09:00:58PM +0100, Wei Xu wrote: [...] > Since the dts part is not depended on the driver and Guodong has put this > into another > patch set[1], I will pick up that one. > Thanks! > > [1]: https://lkml.org/lkml/2017/6/14/1049 Yeah, thanks for picking up from Guodong's

[PATCH] dmaengine: pl330: Delete unused functions

The functions _queue_empty(), _emit_ADDH(), _emit_NOP(), _emit_STZ() and _emit_WFE() are not used. Delete them. Signed-off-by: Matthias Kaehlcke --- drivers/dma/pl330.c | 67 - 1 file changed, 67 deletions(-) diff --git

[PATCH] dmaengine: pl330: Delete unused functions

The functions _queue_empty(), _emit_ADDH(), _emit_NOP(), _emit_STZ() and _emit_WFE() are not used. Delete them. Signed-off-by: Matthias Kaehlcke --- drivers/dma/pl330.c | 67 - 1 file changed, 67 deletions(-) diff --git a/drivers/dma/pl330.c

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

On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton wrote: > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote: > >> >> Caused by commit >> >> >> >> 088a5ecf7581 ("include/linux/string.h: add the option of fortified >> >> string.h functions") >>

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

On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton wrote: > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook wrote: > >> >> Caused by commit >> >> >> >> 088a5ecf7581 ("include/linux/string.h: add the option of fortified >> >> string.h functions") >> >> >> >> We really need to fix all the known

Re: [RFC v2 0/2] swait: add idle to make idle-hacks on kthreads explicit

On Fri, Jun 16, 2017 at 01:26:19AM +0200, Luis R. Rodriguez wrote: > On Thu, Jun 15, 2017 at 02:57:17PM -0700, Paul E. McKenney wrote: > > On Thu, Jun 15, 2017 at 11:48:18AM -0700, Luis R. Rodriguez wrote: > > > While reviewing RCU's interruptible swaits I noticed signals were actually > > > not

Re: [RFC v2 0/2] swait: add idle to make idle-hacks on kthreads explicit

On Fri, Jun 16, 2017 at 01:26:19AM +0200, Luis R. Rodriguez wrote: > On Thu, Jun 15, 2017 at 02:57:17PM -0700, Paul E. McKenney wrote: > > On Thu, Jun 15, 2017 at 11:48:18AM -0700, Luis R. Rodriguez wrote: > > > While reviewing RCU's interruptible swaits I noticed signals were actually > > > not

Re: [PATCH v10 4/5] i2c: aspeed: added driver for Aspeed I2C

On Sun, Jun 4, 2017 at 10:02 PM, Andrew Jeffery wrote: > On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote: >> Added initial master support for Aspeed I2C controller. Supports >> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. >> >> Signed-off-by:

Re: [PATCH v10 4/5] i2c: aspeed: added driver for Aspeed I2C

On Sun, Jun 4, 2017 at 10:02 PM, Andrew Jeffery wrote: > On Fri, 2017-06-02 at 18:29 -0700, Brendan Higgins wrote: >> Added initial master support for Aspeed I2C controller. Supports >> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed. >> >> Signed-off-by: Brendan Higgins > > I

Re: xgetbv nondeterminism

On 06/15/2017 03:18 PM, Andy Lutomirski wrote: >> As you pointed out, if you are using XSAVEC's compaction features by >> leaving bits unset in the requested feature bitmap registers, you have >> no idea how much data XSAVEC will write, unless you read XINUSE with >> XGETBV. But, you can get

Re: xgetbv nondeterminism

On 06/15/2017 03:18 PM, Andy Lutomirski wrote: >> As you pointed out, if you are using XSAVEC's compaction features by >> leaving bits unset in the requested feature bitmap registers, you have >> no idea how much data XSAVEC will write, unless you read XINUSE with >> XGETBV. But, you can get

Re: [PATCH] autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL

On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown wrote: > > If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL > ioctl, autofs4_d_automount() will return >ERR_PTR(status) > with that status to follow_automount(), which will then > dereference an invalid pointer. > >

Re: [PATCH] autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL

On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown wrote: > > If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL > ioctl, autofs4_d_automount() will return >ERR_PTR(status) > with that status to follow_automount(), which will then > dereference an invalid pointer. > > So treat a

[PATCH v2 6/6 squash] drm/vc4: Fixup for the drm core async changes.

With this squashed in, the vc4 patch is: Reviewed-by: Eric Anholt Signed-off-by: Eric Anholt --- Without this, the cursor never moved :) drivers/gpu/drm/vc4/vc4_plane.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu wrote: > On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote: >> On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote: >>> On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote:

[PATCH v2 6/6 squash] drm/vc4: Fixup for the drm core async changes.

With this squashed in, the vc4 patch is: Reviewed-by: Eric Anholt Signed-off-by: Eric Anholt --- Without this, the cursor never moved :) drivers/gpu/drm/vc4/vc4_plane.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c

Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu wrote: > On Thu, Jun 15, 2017 at 3:45 PM, Andy Lutomirski wrote: >> On Thu, Jun 15, 2017 at 3:40 PM, H.J. Lu wrote: >>> On Thu, Jun 15, 2017 at 3:18 PM, Andy Lutomirski wrote: On Thu, Jun 15, 2017 at 7:33 AM, Dave Hansen wrote: > On 06/14/2017

Re: [RFC v2 0/2] swait: add idle to make idle-hacks on kthreads explicit

On Thu, Jun 15, 2017 at 02:57:17PM -0700, Paul E. McKenney wrote: > On Thu, Jun 15, 2017 at 11:48:18AM -0700, Luis R. Rodriguez wrote: > > While reviewing RCU's interruptible swaits I noticed signals were actually > > not expected. Paul explained that the reason signals are not expected is > > we

Re: [RFC v2 0/2] swait: add idle to make idle-hacks on kthreads explicit

On Thu, Jun 15, 2017 at 02:57:17PM -0700, Paul E. McKenney wrote: > On Thu, Jun 15, 2017 at 11:48:18AM -0700, Luis R. Rodriguez wrote: > > While reviewing RCU's interruptible swaits I noticed signals were actually > > not expected. Paul explained that the reason signals are not expected is > > we

Re: [PATCH 1/3] ARM: Generalize fncpy implementation

On 06/15/2017 04:21 PM, Florian Fainelli wrote: > ARM's fncpy implementation is actually suitable for a large number of > platforms since the only assumption it makes is just the function's > alignment (8 bytes) which also happens to fulfil other architectures, > including but not limited to

Re: [PATCH 1/3] ARM: Generalize fncpy implementation

On 06/15/2017 04:21 PM, Florian Fainelli wrote: > ARM's fncpy implementation is actually suitable for a large number of > platforms since the only assumption it makes is just the function's > alignment (8 bytes) which also happens to fulfil other architectures, > including but not limited to

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