Re: Regression with arm in next with stack protector

On Tue, Mar 27, 2018 at 10:04:10AM +0100, Russell King - ARM Linux wrote: > On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote: > > Hi, > > > > Looks like commit 5638790dadae ("zboot: fix stack protector in > > compressed boot phase") breaks booti

Re: Regression with arm in next with stack protector

On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote: > Hi, > > Looks like commit 5638790dadae ("zboot: fix stack protector in > compressed boot phase") breaks booting on arm. > > This is all I get from the bootloader on omap3: > > Starting kernel ... > > data abort > pc :

Re: Regression with arm in next with stack protector

On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote: > Hi, > > Looks like commit 5638790dadae ("zboot: fix stack protector in > compressed boot phase") breaks booting on arm. > > This is all I get from the bootloader on omap3: > > Starting kernel ... > > data abort > pc :

Re: [PATCH 1/5] bus: arm-cci: use asm unreachable

On Wed, Mar 21, 2018 at 12:02:02AM +0100, Stefan Agner wrote: > Mixing asm and C code is not recommended in a naked function by > gcc and leads to an error when using clang: > drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked > function is not supported > unreachable(); >

Re: [PATCH 1/5] bus: arm-cci: use asm unreachable

On Wed, Mar 21, 2018 at 12:02:02AM +0100, Stefan Agner wrote: > Mixing asm and C code is not recommended in a naked function by > gcc and leads to an error when using clang: > drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked > function is not supported > unreachable(); >

Re: [PATCH 5/5] ARM: add support for building ARM kernel with clang

On Wed, Mar 21, 2018 at 12:02:06AM +0100, Stefan Agner wrote: > Use cc-options call for compiler options which are not available > in clang. With this patch an ARMv7 multi platform kernel can be > successfully build using clang (tested with version 5.0.1). > > Based-on-patches-by: Behan Webster

Re: [PATCH 5/5] ARM: add support for building ARM kernel with clang

On Wed, Mar 21, 2018 at 12:02:06AM +0100, Stefan Agner wrote: > Use cc-options call for compiler options which are not available > in clang. With this patch an ARMv7 multi platform kernel can be > successfully build using clang (tested with version 5.0.1). > > Based-on-patches-by: Behan Webster

Re: [PATCH 3/5] ARM: trusted_foundations: do not use naked function

On Wed, Mar 21, 2018 at 12:02:04AM +0100, Stefan Agner wrote: > As documented in GCC naked functions should only use Basic asm > syntax. The Extended asm or mixture of Basic asm and "C" code is > not guaranteed. Currently this works because it was hard coded > to follow and check GCC behavior for

Re: [PATCH 3/5] ARM: trusted_foundations: do not use naked function

On Wed, Mar 21, 2018 at 12:02:04AM +0100, Stefan Agner wrote: > As documented in GCC naked functions should only use Basic asm > syntax. The Extended asm or mixture of Basic asm and "C" code is > not guaranteed. Currently this works because it was hard coded > to follow and check GCC behavior for

Re: [PATCH] arm: dts: hummingboard2: convert onboard audio to simple-audio-card

On Mon, Mar 19, 2018 at 09:53:26AM -0400, Matt Porter wrote: > The HB2 onboard audio currently makes use of the imx-audio-sgtl5000 > binding. This binding does not support auxiliary audio devices such > as external amplifiers. The simple-audio-card binding does support > this property which allows

Re: [PATCH] arm: dts: hummingboard2: convert onboard audio to simple-audio-card

On Mon, Mar 19, 2018 at 09:53:26AM -0400, Matt Porter wrote: > The HB2 onboard audio currently makes use of the imx-audio-sgtl5000 > binding. This binding does not support auxiliary audio devices such > as external amplifiers. The simple-audio-card binding does support > this property which allows

Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

<antoine.ten...@bootlin.com>; Russell King - ARM Linux > > <li...@armlinux.org.uk>; da...@davemloft.net; kis...@ti.com; > > gregory.clem...@bootlin.com; ja...@lakedaemon.net; > > sebastian.hesselba...@gmail.com; net...@vger.kernel.org; linux- > > ker...@vg

Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 01:19:24PM +, Stefan Chulski wrote: > > > > -Original Message- > > From: Andrew Lunn [mailto:and...@lunn.ch] > > Sent: Monday, March 19, 2018 3:08 PM > > To: Stefan Chulski > > Cc: Antoine Tenart ; Russell King - ARM

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 02:10:09PM +0100, Antoine Tenart wrote: > Hi Andrew, > > On Mon, Mar 19, 2018 at 01:59:53PM +0100, Andrew Lunn wrote: > > > > If they don't have PHYs, how are the connected to the outside world? > > On 7k/8k you have the following scheme for 10G only interfaces: > >

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 02:10:09PM +0100, Antoine Tenart wrote: > Hi Andrew, > > On Mon, Mar 19, 2018 at 01:59:53PM +0100, Andrew Lunn wrote: > > > > If they don't have PHYs, how are the connected to the outside world? > > On 7k/8k you have the following scheme for 10G only interfaces: > >

Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 01:01:07PM +, Yan Markman wrote: > The DTS-patch for this board (in "old" format) is attached > > > Yan Markman > Tel. 05-44732819 > > > -Original Message- > From: Stefan Chulski > Sent: Monday, March 19, 2018 2:

Re: [EXT] Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 01:01:07PM +, Yan Markman wrote: > The DTS-patch for this board (in "old" format) is attached > > > Yan Markman > Tel. 05-44732819 > > > -Original Message- > From: Stefan Chulski > Sent: Monday, March 19, 201

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 09:52:52AM +0100, Antoine Tenart wrote: > Hi Russell, > > On Fri, Mar 16, 2018 at 03:53:07PM +, Russell King - ARM Linux wrote: > > On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote: > > > The PHY mode 10GKR can use in-band negotiat

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Mon, Mar 19, 2018 at 09:52:52AM +0100, Antoine Tenart wrote: > Hi Russell, > > On Fri, Mar 16, 2018 at 03:53:07PM +, Russell King - ARM Linux wrote: > > On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote: > > > The PHY mode 10GKR can use in-band negotiat

Re: [PATCH 1/7] 2 1-byte checks more safer for memory_is_poisoned_16

On Sun, Mar 18, 2018 at 08:53:36PM +0800, Abbott Liu wrote: > Because in some architecture(eg. arm) instruction set, non-aligned > access support is not very well, so 2 1-byte checks is more > safer than 1 2-byte check. The impact on performance is small > because 16-byte accesses are not too

Re: [PATCH 1/7] 2 1-byte checks more safer for memory_is_poisoned_16

On Sun, Mar 18, 2018 at 08:53:36PM +0800, Abbott Liu wrote: > Because in some architecture(eg. arm) instruction set, non-aligned > access support is not very well, so 2 1-byte checks is more > safer than 1 2-byte check. The impact on performance is small > because 16-byte accesses are not too

Re: [PATCH net-next 03/10] net: mvpp2: phylink support

On Fri, Mar 16, 2018 at 11:33:44AM +0100, Antoine Tenart wrote: > +static void mvpp2_phylink_validate(struct net_device *dev, > +unsigned long *supported, > +struct phylink_link_state *state) > +{ > +

Re: [PATCH net-next 03/10] net: mvpp2: phylink support

On Fri, Mar 16, 2018 at 11:33:44AM +0100, Antoine Tenart wrote: > +static void mvpp2_phylink_validate(struct net_device *dev, > +unsigned long *supported, > +struct phylink_link_state *state) > +{ > +

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote: > The PHY mode 10GKR can use in-band negotiation. This patches allows this > mode to be used with MLO_AN_INBAND in phylink. > > Signed-off-by: Antoine Tenart > --- > drivers/net/phy/phylink.c | 3 ++- >

Re: [PATCH net-next 02/10] net: phy: phylink: allow 10GKR interface to use in-band negotiation

On Fri, Mar 16, 2018 at 11:33:43AM +0100, Antoine Tenart wrote: > The PHY mode 10GKR can use in-band negotiation. This patches allows this > mode to be used with MLO_AN_INBAND in phylink. > > Signed-off-by: Antoine Tenart > --- > drivers/net/phy/phylink.c | 3 ++- > 1 file changed, 2

Re: [PATCH] arm: mm: Kconfig: Disable KUSER_HELPERS in ARMv6 or later as default

On Tue, Mar 06, 2018 at 08:22:41PM +0900, Jinbum Park wrote: > Codes for KUSER_HELPERS can be abused as ROP gadaget, > So that It's better to disable that as if possible. > > Since over ARMv6 has ldrex/strex at user-space, > NEED_KUSER_HELPERS is not selected for over ARMv6. > > But, Even though

Re: [PATCH] arm: mm: Kconfig: Disable KUSER_HELPERS in ARMv6 or later as default

On Tue, Mar 06, 2018 at 08:22:41PM +0900, Jinbum Park wrote: > Codes for KUSER_HELPERS can be abused as ROP gadaget, > So that It's better to disable that as if possible. > > Since over ARMv6 has ldrex/strex at user-space, > NEED_KUSER_HELPERS is not selected for over ARMv6. > > But, Even though

Re: [PATCH] drm/bridge/synopsys: dw-hdmi: Fix memleak in __dw_hdmi_remove

On Mon, Mar 05, 2018 at 03:45:55PM +0800, Jeffy Chen wrote: > The platform_device_register_full() will allocate dma_mask for > hdmi->audio, so we should free before platform_device_unregister(). > > Reported by kmemleak: > unreferenced object 0xffc0ef70ff00 (size 128): > comm "kworker/4:1",

Re: [PATCH] drm/bridge/synopsys: dw-hdmi: Fix memleak in __dw_hdmi_remove

On Mon, Mar 05, 2018 at 03:45:55PM +0800, Jeffy Chen wrote: > The platform_device_register_full() will allocate dma_mask for > hdmi->audio, so we should free before platform_device_unregister(). > > Reported by kmemleak: > unreferenced object 0xffc0ef70ff00 (size 128): > comm "kworker/4:1",

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Sat, Mar 03, 2018 at 06:25:17PM +0200, Andy Shevchenko wrote: > On Fri, Mar 2, 2018 at 6:28 PM, Mark Rutland <mark.rutl...@arm.com> wrote: > > On Fri, Mar 02, 2018 at 03:32:22PM +, Russell King - ARM Linux wrote: > >> How do we break this status quo and

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Sat, Mar 03, 2018 at 06:25:17PM +0200, Andy Shevchenko wrote: > On Fri, Mar 2, 2018 at 6:28 PM, Mark Rutland wrote: > > On Fri, Mar 02, 2018 at 03:32:22PM +, Russell King - ARM Linux wrote: > >> How do we break this status quo and finally solve the IRQ 0 and > >&

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

On Fri, Mar 02, 2018 at 08:22:52AM -0600, Andrew F. Davis wrote: > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > > index 84e5a9d..f0fab26 100644 > > --- a/drivers/gpio/gpiolib-of.c > > +++ b/drivers/gpio/gpiolib-of.c > > @@ -241,29 +241,17 @@ struct gpio_desc

Re: [alsa-devel] regression v4.16 on Nokia N900: sound does not work

On Fri, Mar 02, 2018 at 08:22:52AM -0600, Andrew F. Davis wrote: > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > > index 84e5a9d..f0fab26 100644 > > --- a/drivers/gpio/gpiolib-of.c > > +++ b/drivers/gpio/gpiolib-of.c > > @@ -241,29 +241,17 @@ struct gpio_desc

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 05:09:01PM +0300, Dan Carpenter wrote: > On Fri, Mar 02, 2018 at 02:58:54PM +0100, Wolfram Sang wrote: > > > > > It needs platform maintainers to be motivated to fix it, and one way to > > > provide that motivation is for subsystem maintainers to say no to patches > > >

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 05:09:01PM +0300, Dan Carpenter wrote: > On Fri, Mar 02, 2018 at 02:58:54PM +0100, Wolfram Sang wrote: > > > > > It needs platform maintainers to be motivated to fix it, and one way to > > > provide that motivation is for subsystem maintainers to say no to patches > > >

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 01:46:47PM +0100, Wolfram Sang wrote: > > So, maybe some words why I accepted this patch. > > On Fri, Mar 02, 2018 at 11:19:31AM +, Russell King - ARM Linux wrote: > > Note that there have been patches proposed to make platform_get_irq() > >

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 01:46:47PM +0100, Wolfram Sang wrote: > > So, maybe some words why I accepted this patch. > > On Fri, Mar 02, 2018 at 11:19:31AM +, Russell King - ARM Linux wrote: > > Note that there have been patches proposed to make platform_get_irq() > >

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 03:26:56PM +0300, Dan Carpenter wrote: > Ok, but in that case the original code is still wrong because it returns > early with success. I guess it could be changed to: > > if (irq <= 0) > return -ENXIO; What if platform_get_irq() returns -EPROBE_DEFER

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 03:26:56PM +0300, Dan Carpenter wrote: > Ok, but in that case the original code is still wrong because it returns > early with success. I guess it could be changed to: > > if (irq <= 0) > return -ENXIO; What if platform_get_irq() returns -EPROBE_DEFER

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 02:49:09PM +0300, Dan Carpenter wrote: > On Fri, Mar 02, 2018 at 11:19:31AM +, Russell King - ARM Linux wrote: > > On Thu, Mar 01, 2018 at 09:34:44PM +0100, Krzysztof Kozlowski wrote: > > > Interrupt number 0 (returned by platform_get_irq()) mi

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 02:49:09PM +0300, Dan Carpenter wrote: > On Fri, Mar 02, 2018 at 11:19:31AM +, Russell King - ARM Linux wrote: > > On Thu, Mar 01, 2018 at 09:34:44PM +0100, Krzysztof Kozlowski wrote: > > > Interrupt number 0 (returned by platform_get_irq()) mi

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Thu, Mar 01, 2018 at 09:34:44PM +0100, Krzysztof Kozlowski wrote: > Interrupt number 0 (returned by platform_get_irq()) might be a valid IRQ > so do not treat it as an error. If interrupt 0 was configured, the driver > would exit the probe early, before finishing initialization, but with >

Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Thu, Mar 01, 2018 at 09:34:44PM +0100, Krzysztof Kozlowski wrote: > Interrupt number 0 (returned by platform_get_irq()) might be a valid IRQ > so do not treat it as an error. If interrupt 0 was configured, the driver > would exit the probe early, before finishing initialization, but with >

Re: [PATCH] clk: don't call __of_clk_get_by_name() unnecessarily from clk_get()

t(struct device *dev, const char > >*con_id) > > const char *dev_id = dev ? dev_name(dev) : NULL; > > struct clk *clk; > >-if (dev) { > >+if (dev && dev->of_node) { > > clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id);

Re: [PATCH] clk: don't call __of_clk_get_by_name() unnecessarily from clk_get()

>-if (dev) { > >+if (dev && dev->of_node) { > > clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id); > > if (!IS_ERR(clk) || PTR_ERR(clk) == -EPROBE_DEFER) > > return clk; > > > > Shouldn't you

Re: [PATCHv2] arch/arm/Kconfig: default ARM_MODULE_PLTS to 'y'

On Wed, Jan 31, 2018 at 09:19:11PM +0100, Anders Roxell wrote: > While testing multi_v7_defconfig with LOCKDEP enabled, the kernel > fails to load simple modules, as reported by kselftest: > > [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation > 28 out of range (0xbf046044 ->

Re: [PATCHv2] arch/arm/Kconfig: default ARM_MODULE_PLTS to 'y'

On Wed, Jan 31, 2018 at 09:19:11PM +0100, Anders Roxell wrote: > While testing multi_v7_defconfig with LOCKDEP enabled, the kernel > fails to load simple modules, as reported by kselftest: > > [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation > 28 out of range (0xbf046044 ->

Re: [PATCH] arch/arm/Kconfig: enable ARM_MODULE_PLTS when LOCKDEP=y

On Wed, Jan 31, 2018 at 12:25:33PM +0100, Arnd Bergmann wrote: > On Tue, Jan 30, 2018 at 12:57 AM, Russell King - ARM Linux > <li...@armlinux.org.uk> wrote: > > On Tue, Jan 30, 2018 at 12:49:00AM +0100, Anders Roxell wrote: > >> While testing multi_v7_defconfig with

Re: [PATCH] arch/arm/Kconfig: enable ARM_MODULE_PLTS when LOCKDEP=y

On Wed, Jan 31, 2018 at 12:25:33PM +0100, Arnd Bergmann wrote: > On Tue, Jan 30, 2018 at 12:57 AM, Russell King - ARM Linux > wrote: > > On Tue, Jan 30, 2018 at 12:49:00AM +0100, Anders Roxell wrote: > >> While testing multi_v7_defconfig with LOCKDEP enabled, the kernel >

Re: [PATCH v2 08/16] arm/arm64: KVM: Advertise SMCCC v1.1

rc Zyngier <marc.zyng...@arm.com> > --- > Documentation/virtual/kvm/arm/psci.txt | 12 +++- > arch/arm/kvm/handle_exit.c | 2 +- > arch/arm64/kvm/handle_exit.c | 2 +- > include/kvm/arm_psci.h | 2 +- > include/linux/arm-smccc.

Re: [PATCH v2 08/16] arm/arm64: KVM: Advertise SMCCC v1.1

-off-by: Marc Zyngier > --- > Documentation/virtual/kvm/arm/psci.txt | 12 +++- > arch/arm/kvm/handle_exit.c | 2 +- > arch/arm64/kvm/handle_exit.c | 2 +- > include/kvm/arm_psci.h | 2 +- > include/linux/arm-smccc.h |

Re: [PATCH] arch/arm/Kconfig: enable ARM_MODULE_PLTS when LOCKDEP=y

On Tue, Jan 30, 2018 at 12:49:00AM +0100, Anders Roxell wrote: > While testing multi_v7_defconfig with LOCKDEP enabled, the kernel > fails to load simple modules, as reported by kselftest: > > [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation > 28 out of range (0xbf046044 ->

Re: [PATCH] arch/arm/Kconfig: enable ARM_MODULE_PLTS when LOCKDEP=y

On Tue, Jan 30, 2018 at 12:49:00AM +0100, Anders Roxell wrote: > While testing multi_v7_defconfig with LOCKDEP enabled, the kernel > fails to load simple modules, as reported by kselftest: > > [ 34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation > 28 out of range (0xbf046044 ->

Re: [RFC 1/2] arm: cacheflush syscall: process only pages that are in the memory

On Fri, Jan 26, 2018 at 02:30:47PM +0100, Marek Szyprowski wrote: > Hi Russell, > > On 2018-01-26 12:32, Russell King - ARM Linux wrote: > >On Fri, Jan 26, 2018 at 12:14:40PM +0100, Marek Szyprowski wrote: > >>glibc in calls cacheflush syscall on the whole textrels sect

Re: [RFC 1/2] arm: cacheflush syscall: process only pages that are in the memory

On Fri, Jan 26, 2018 at 02:30:47PM +0100, Marek Szyprowski wrote: > Hi Russell, > > On 2018-01-26 12:32, Russell King - ARM Linux wrote: > >On Fri, Jan 26, 2018 at 12:14:40PM +0100, Marek Szyprowski wrote: > >>glibc in calls cacheflush syscall on the whole textrels sect

Re: [RFC 1/2] arm: cacheflush syscall: process only pages that are in the memory

On Fri, Jan 26, 2018 at 12:14:40PM +0100, Marek Szyprowski wrote: > glibc in calls cacheflush syscall on the whole textrels section of the > relocated binaries. However, relocation usually doesn't touch all pages > of that section, so not all of them are read to memory when calling this > syscall.

Re: [RFC 1/2] arm: cacheflush syscall: process only pages that are in the memory

On Fri, Jan 26, 2018 at 12:14:40PM +0100, Marek Szyprowski wrote: > glibc in calls cacheflush syscall on the whole textrels section of the > relocated binaries. However, relocation usually doesn't touch all pages > of that section, so not all of them are read to memory when calling this > syscall.

Re: tip/master falls off NOP cliff with KPTI under KVM

pmost 3 patches. > > tglx Found it: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/pti Thanks, Thomas! -- Dexuan

Re: tip/master falls off NOP cliff with KPTI under KVM

tglx Found it: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/pti Thanks, Thomas! -- Dexuan

Re: tip/master falls off NOP cliff with KPTI under KVM

On Wed, Jan 10, 2018 at 2:53 PM, Woodhouse, David wrote: > On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote: >> >> Bisection points to >> >> f3433c1010c6af61c9897f0f0447f81b991feac1 is the first bad commit >> commit

Re: tip/master falls off NOP cliff with KPTI under KVM

On Wed, Jan 10, 2018 at 2:53 PM, Woodhouse, David wrote: > On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote: >> >> Bisection points to >> >> f3433c1010c6af61c9897f0f0447f81b991feac1 is the first bad commit >> commit f3433c1010c6af61c9897f0f0447f81b991feac1 >>

Re: [PATCH] arm64: Stop printing the virtual memory layout

On Thu, Jan 18, 2018 at 12:01:31PM -0800, Florian Fainelli wrote: > On 12/19/2017 11:28 AM, Laura Abbott wrote: > > Printing kernel addresses should be done in limited circumstances, mostly > > for debugging purposes. Printing out the virtual memory layout at every > > kernel bootup doesn't really

Re: [PATCH] arm64: Stop printing the virtual memory layout

On Thu, Jan 18, 2018 at 12:01:31PM -0800, Florian Fainelli wrote: > On 12/19/2017 11:28 AM, Laura Abbott wrote: > > Printing kernel addresses should be done in limited circumstances, mostly > > for debugging purposes. Printing out the virtual memory layout at every > > kernel bootup doesn't really

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 10:45:10AM -0600, Eric W. Biederman wrote: > Russell King - ARM Linux <li...@armlinux.org.uk> writes: > >From your description there still seems to be an association with an > instruction so I don't know if I would really call the signal > asynchro

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 10:45:10AM -0600, Eric W. Biederman wrote: > Russell King - ARM Linux writes: > >From your description there still seems to be an association with an > instruction so I don't know if I would really call the signal > asynchronous. It sounds like the excep

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 03:37:31PM +, Dave Martin wrote: > On Wed, Jan 17, 2018 at 12:37:52PM +, Russell King - ARM Linux wrote: > > On Wed, Jan 17, 2018 at 12:15:05PM +, Dave Martin wrote: > > > On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 03:37:31PM +, Dave Martin wrote: > On Wed, Jan 17, 2018 at 12:37:52PM +, Russell King - ARM Linux wrote: > > On Wed, Jan 17, 2018 at 12:15:05PM +, Dave Martin wrote: > > > On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 12:15:05PM +, Dave Martin wrote: > On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King - ARM Linux wrote: > > On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote: > > > I will keep FPE_FIXME as a place holder until th

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Wed, Jan 17, 2018 at 12:15:05PM +, Dave Martin wrote: > On Wed, Jan 17, 2018 at 11:57:09AM +, Russell King - ARM Linux wrote: > > On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote: > > > I will keep FPE_FIXME as a place holder until th

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote: > I will keep FPE_FIXME as a place holder until this gets sorted out. > > There is a second issue I am looking at in this location, > and maybe I don't have to address it now. But it looks like the code is > calling send_sig_info

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

On Tue, Jan 16, 2018 at 04:28:50PM -0600, Eric W. Biederman wrote: > I will keep FPE_FIXME as a place holder until this gets sorted out. > > There is a second issue I am looking at in this location, > and maybe I don't have to address it now. But it looks like the code is > calling send_sig_info

Re: [PATCH] ARM: make memzero optimization smarter

On Tue, Jan 16, 2018 at 11:07:34PM -0500, Nicolas Pitre wrote: > On Tue, 16 Jan 2018, Arnd Bergmann wrote: > > > On Tue, Jan 16, 2018 at 6:10 PM, Nicolas Pitre > > wrote: > > > On Tue, 16 Jan 2018, Arnd Bergmann wrote: > > > > > >> However, we can avoid this class of

Re: [PATCH] ARM: make memzero optimization smarter

On Tue, Jan 16, 2018 at 11:07:34PM -0500, Nicolas Pitre wrote: > On Tue, 16 Jan 2018, Arnd Bergmann wrote: > > > On Tue, Jan 16, 2018 at 6:10 PM, Nicolas Pitre > > wrote: > > > On Tue, 16 Jan 2018, Arnd Bergmann wrote: > > > > > >> However, we can avoid this class of bogus warnings for the

Re: [PATCH net-next v5 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

On Fri, Jan 12, 2018 at 08:51:26AM +0100, Antoine Tenart wrote: > Hi all, > > This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2 > driver. In order to use it, the 2.5 SGMII mode is added in the Marvell > common PHY driver (cp110-comphy). > > This was tested on a mcbin. > > All

Re: [PATCH net-next v5 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

On Fri, Jan 12, 2018 at 08:51:26AM +0100, Antoine Tenart wrote: > Hi all, > > This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2 > driver. In order to use it, the 2.5 SGMII mode is added in the Marvell > common PHY driver (cp110-comphy). > > This was tested on a mcbin. > > All

Re: [PATCH 08/11] signal/arm: Document conflicts with SI_USER and SIGFPE

On Thu, Jan 11, 2018 at 06:59:37PM -0600, Eric W. Biederman wrote: > Setting si_code to 0 results in a userspace seeing an si_code of 0. > This is the same si_code as SI_USER. Posix and common sense requires > that SI_USER not be a signal specific si_code. As such this use of 0 > for the si_code

Re: [PATCH 08/11] signal/arm: Document conflicts with SI_USER and SIGFPE

On Thu, Jan 11, 2018 at 06:59:37PM -0600, Eric W. Biederman wrote: > Setting si_code to 0 results in a userspace seeing an si_code of 0. > This is the same si_code as SI_USER. Posix and common sense requires > that SI_USER not be a signal specific si_code. As such this use of 0 > for the si_code

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

pace control. That by itself is not sufficient for > attack (per current understanding) [3], but it is a necessary > pre-condition. So 'hygiene' refers to cleaning up those suspect > pointers regardless of whether they are usable as a gadget. > > These patches are also be available

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

pace control. That by itself is not sufficient for > attack (per current understanding) [3], but it is a necessary > pre-condition. So 'hygiene' refers to cleaning up those suspect > pointers regardless of whether they are usable as a gadget. > > These patches are also be available

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Thu, Jan 11, 2018 at 05:00:03PM +0100, Geert Uytterhoeven wrote: > On Thu, Jan 11, 2018 at 4:54 PM, Geert Uytterhoeven > <ge...@linux-m68k.org> wrote: > > On Thu, Jan 11, 2018 at 4:53 PM, Russell King - ARM Linux > > <li...@armlinux.org.uk> wrote: > >> O

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Thu, Jan 11, 2018 at 05:00:03PM +0100, Geert Uytterhoeven wrote: > On Thu, Jan 11, 2018 at 4:54 PM, Geert Uytterhoeven > wrote: > > On Thu, Jan 11, 2018 at 4:53 PM, Russell King - ARM Linux > > wrote: > >> On Thu, Jan 11, 2018 at 10:48:35AM -0500, David Mill

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Thu, Jan 11, 2018 at 10:48:35AM -0500, David Miller wrote: > From: Geert Uytterhoeven > Date: Tue, 9 Jan 2018 12:11:21 +0100 > > > In case of success, the return values of (__)phy_write() and > > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while >

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Thu, Jan 11, 2018 at 10:48:35AM -0500, David Miller wrote: > From: Geert Uytterhoeven > Date: Tue, 9 Jan 2018 12:11:21 +0100 > > > In case of success, the return values of (__)phy_write() and > > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while > > (__)phy_modify()

Re: [PATCH 34/38] arm: Implement thread_struct whitelist for hardened usercopy

his patch is wrong and will introduce a regression. Thanks. > > Cc: Russell King <li...@armlinux.org.uk> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Cc: "Peter Zijlstra (Intel)" <pet...@infradead.org&g

Re: [PATCH 34/38] arm: Implement thread_struct whitelist for hardened usercopy

his patch is wrong and will introduce a regression. Thanks. > > Cc: Russell King > Cc: Ingo Molnar > Cc: Christian Borntraeger > Cc: "Peter Zijlstra (Intel)" > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Kees Cook > --- > arch/arm/Kconfig

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 07:25:40PM +0100, Geert Uytterhoeven wrote: > Hi Russell, > > On Tue, Jan 9, 2018 at 3:22 PM, Russell King - ARM Linux > <li...@armlinux.org.uk> wrote: > > On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote: > >> On Tue, Jan 09

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 07:25:40PM +0100, Geert Uytterhoeven wrote: > Hi Russell, > > On Tue, Jan 9, 2018 at 3:22 PM, Russell King - ARM Linux > wrote: > > On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote: > >> On Tue, Jan 09, 2018 at 12:11:21PM +010

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 03:48:13PM +0100, Andrew Lunn wrote: > > > I took a quick look at the uses of phy_modify(). I don't see any uses > > > of the return code other than as an error indicator. So having it > > > return 0 on success seems like a better fix. > > > > I'd like to avoid that,

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 03:48:13PM +0100, Andrew Lunn wrote: > > > I took a quick look at the uses of phy_modify(). I don't see any uses > > > of the return code other than as an error indicator. So having it > > > return 0 on success seems like a better fix. > > > > I'd like to avoid that,

Re: [PATCH] ARM: locomo: fix free dev incorrectly

On Tue, Jan 09, 2018 at 10:37:55PM +0800, Xiongwei Song wrote: > In function locomo_init_one_child, If kzalloc call is failed for dev we > would goto out label, then call kfree for dev, however, dev is NULL, we > shouldn't do this. kfree() internally checks for NULL pointers so callers don't have

Re: [PATCH] ARM: locomo: fix free dev incorrectly

On Tue, Jan 09, 2018 at 10:37:55PM +0800, Xiongwei Song wrote: > In function locomo_init_one_child, If kzalloc call is failed for dev we > would goto out label, then call kfree for dev, however, dev is NULL, we > shouldn't do this. kfree() internally checks for NULL pointers so callers don't have

Re: [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support

On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote: > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses > nearly the same code path. Sorry, also... > @@ -4668,6 +4692,10 @@ static void

Re: [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support

On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote: > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses > nearly the same code path. Sorry, also... > @@ -4668,6 +4692,10 @@ static void

Re: [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support

On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote: > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses > nearly the same code path. For 2500Base-X, do you report a speed of 2500Mbps through

Re: [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support

On Tue, Jan 09, 2018 at 09:59:45AM +0100, Antoine Tenart wrote: > This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 > driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses > nearly the same code path. For 2500Base-X, do you report a speed of 2500Mbps through

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote: > On Tue, Jan 09, 2018 at 12:11:21PM +0100, Geert Uytterhoeven wrote: > > In case of success, the return values of (__)phy_write() and > > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while > > (__)phy_modify() returns

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

On Tue, Jan 09, 2018 at 03:10:08PM +0100, Andrew Lunn wrote: > On Tue, Jan 09, 2018 at 12:11:21PM +0100, Geert Uytterhoeven wrote: > > In case of success, the return values of (__)phy_write() and > > (__)phy_modify() are not compatible: (__)phy_write() returns 0, while > > (__)phy_modify() returns

Re: [V4, 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

On Fri, Jan 05, 2018 at 02:05:26PM +0100, Alexandre Belloni wrote: > Hi, > > I'm definitively late to the party but... > > On 17/11/2017 at 11:00:33 +0100, Thomas Gleixner wrote: > > +2. Style: > > + > > + The SPDX license identifier is added in form of a comment. The comment > > + style

Re: [V4, 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

On Fri, Jan 05, 2018 at 02:05:26PM +0100, Alexandre Belloni wrote: > Hi, > > I'm definitively late to the party but... > > On 17/11/2017 at 11:00:33 +0100, Thomas Gleixner wrote: > > +2. Style: > > + > > + The SPDX license identifier is added in form of a comment. The comment > > + style

Re: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)

On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote: > Great, thanks! Bonus question, if someone is using any of the affected > devices in AArch32, should we be expecting to see ARM/Linux changes as > well, that is, is there a plan to come up with a kpti implementation

<    9   10   11   12   13   14   15   16   17   18   >