Re: [PATCH 04/20] arm-nommu: use generic dma_noncoherent_ops

On Fri, May 11, 2018 at 09:59:29AM +0200, Christoph Hellwig wrote: > Switch to the generic noncoherent direct mapping implementation for > the nommu dma map implementation. > > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig| 1 + > arch/arm/Kconfig

Re: [PATCH 04/20] arm-nommu: use generic dma_noncoherent_ops

On Fri, May 11, 2018 at 09:59:29AM +0200, Christoph Hellwig wrote: > Switch to the generic noncoherent direct mapping implementation for > the nommu dma map implementation. > > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig| 1 + > arch/arm/Kconfig|

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote: > Hi Russell, > > On 10 May 2018 at 02:40, Russell King - ARM Linux <li...@armlinux.org.uk> > wrote: > > This does not leak information from other namespaces because of the > > uniqueness of the glob

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote: > Hi Russell, > > On 10 May 2018 at 02:40, Russell King - ARM Linux > wrote: > > This does not leak information from other namespaces because of the > > uniqueness of the global PID. However, what i

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

On Wed, May 09, 2018 at 09:35:07PM -0500, Eric W. Biederman wrote: > Mathieu Poirier writes: > > > On Tue, May 08, 2018 at 11:59:38PM -0500, Eric W. Biederman wrote: > >> Kim Phillips writes: > >> > >> > This patch is in the context of allowing

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

On Wed, May 09, 2018 at 09:35:07PM -0500, Eric W. Biederman wrote: > Mathieu Poirier writes: > > > On Tue, May 08, 2018 at 11:59:38PM -0500, Eric W. Biederman wrote: > >> Kim Phillips writes: > >> > >> > This patch is in the context of allowing the Coresight h/w > >> > trace driver suite to be

Re: [PATCH] bpf, arm32: Correct check_imm24

On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote: > imm24 is signed, so the right range is: > [-(2<<(24 - 1)), (2<<(24 - 1)) - 1] 2 << (24 - 1) is the same as 1 << 24. > -#define check_imm(bits, imm) do {\ > - if imm) > 0) && ((imm) >> (bits))) ||

Re: [PATCH] bpf, arm32: Correct check_imm24

On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote: > imm24 is signed, so the right range is: > [-(2<<(24 - 1)), (2<<(24 - 1)) - 1] 2 << (24 - 1) is the same as 1 << 24. > -#define check_imm(bits, imm) do {\ > - if imm) > 0) && ((imm) >> (bits))) ||

Re: [PATCH v2 2/4] ARM: amba: Fix race condition with driver_override

On Thu, Apr 26, 2018 at 10:45:49AM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > On Thu, Apr 26, 2018 at 10:35 AM, Greg Kroah-Hartman > wrote: > > On Thu, Apr 26, 2018 at 09:40:08AM +0200, Geert Uytterhoeven wrote: > >> On Thu, Apr 26, 2018 at 9:04 AM, Greg

Re: [PATCH v2 2/4] ARM: amba: Fix race condition with driver_override

On Thu, Apr 26, 2018 at 10:45:49AM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > On Thu, Apr 26, 2018 at 10:35 AM, Greg Kroah-Hartman > wrote: > > On Thu, Apr 26, 2018 at 09:40:08AM +0200, Geert Uytterhoeven wrote: > >> On Thu, Apr 26, 2018 at 9:04 AM, Greg Kroah-Hartman > >> wrote: > >> > On

Re: [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

On Wed, May 09, 2018 at 07:06:28AM +0200, Oleksij Rempel wrote: > On Tue, May 08, 2018 at 01:40:33PM +0100, Russell King - ARM Linux wrote: > > On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote: > > > One of the Freescale recommended sequences for power off with e

Re: [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

On Wed, May 09, 2018 at 07:06:28AM +0200, Oleksij Rempel wrote: > On Tue, May 08, 2018 at 01:40:33PM +0100, Russell King - ARM Linux wrote: > > On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote: > > > One of the Freescale recommended sequences for power off with e

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

On Sat, May 05, 2018 at 10:52:42PM +0200, Andrew Lunn wrote: > On Sat, May 05, 2018 at 01:38:31PM -0700, Florian Fainelli wrote: > > On May 4, 2018 10:14:25 AM PDT, Andrew Lunn wrote: > > >On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote: > > >> On 05/04/2018 06:56

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

On Sat, May 05, 2018 at 10:52:42PM +0200, Andrew Lunn wrote: > On Sat, May 05, 2018 at 01:38:31PM -0700, Florian Fainelli wrote: > > On May 4, 2018 10:14:25 AM PDT, Andrew Lunn wrote: > > >On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote: > > >> On 05/04/2018 06:56 AM, Antoine

Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

On Sat, May 05, 2018 at 01:35:34PM -0700, Florian Fainelli wrote: > On May 4, 2018 8:21:03 AM PDT, Antoine Tenart > wrote: > >When computing the bitrate using values read from an SFP module EEPROM, > >we use the nominal BR plus BR,min and BR,max to determine the >

Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

On Sat, May 05, 2018 at 01:35:34PM -0700, Florian Fainelli wrote: > On May 4, 2018 8:21:03 AM PDT, Antoine Tenart > wrote: > >When computing the bitrate using values read from an SFP module EEPROM, > >we use the nominal BR plus BR,min and BR,max to determine the > >boundaries. But in some cases

Re: [PATCH v9 01/12] ARM: Allow this header to be included by assembly files

@gmail.com> > Signed-off-by: Mylène Josserand <mylene.josser...@bootlin.com> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> Thanks. > --- > arch/arm/include/asm/cputype.h | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/arch/a

Re: [PATCH v9 01/12] ARM: Allow this header to be included by assembly files

ource files, so this this commit adds > that capability to the arm architecture version so that the constants > don't need to be defined in multiple places. > > Signed-off-by: Doug Berger > Signed-off-by: Florian Fainelli > Signed-off-by: Mylène Josserand Acked-by: Russell King Thank

Re: [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote: > One of the Freescale recommended sequences for power off with external > PMIC is the following: > ... > 3. SoC is programming PMIC for power off when standby is asserted. > 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC

Re: [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote: > One of the Freescale recommended sequences for power off with external > PMIC is the following: > ... > 3. SoC is programming PMIC for power off when standby is asserted. > 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC

Re: [PATCH net-next v2 06/13] phy: add 2.5G SGMII mode to the phy_mode enum

On Fri, May 04, 2018 at 03:56:36PM +0200, Antoine Tenart wrote: > This patch adds one more generic PHY mode to the phy_mode enum, to allow > configuring generic PHYs to the 2.5G SGMII mode by using the set_mode > callback. > > Signed-off-by: Antoine Tenart > Acked-by:

Re: [PATCH net-next v2 06/13] phy: add 2.5G SGMII mode to the phy_mode enum

On Fri, May 04, 2018 at 03:56:36PM +0200, Antoine Tenart wrote: > This patch adds one more generic PHY mode to the phy_mode enum, to allow > configuring generic PHYs to the 2.5G SGMII mode by using the set_mode > callback. > > Signed-off-by: Antoine Tenart > Acked-by: Kishon Vijay Abraham I

Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

want to be lazy about that!) Practically, we're talking about SerDes Ethernet, where the bit rate is no lower than 100Mbps [*], which will always have a frequency well above this cut-off. So, I don't have any problem with your approach to setting the minimum to zero. Therefore, Acked-by: R

Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

!) Practically, we're talking about SerDes Ethernet, where the bit rate is no lower than 100Mbps [*], which will always have a frequency well above this cut-off. So, I don't have any problem with your approach to setting the minimum to zero. Therefore, Acked-by: Russell King Please send me the

Re: [PATCH net] net: phy: sfp: fix the BR,min computation

On Fri, May 04, 2018 at 05:10:54PM +0200, Antoine Tenart wrote: > In an SFP EEPROM values can be read to get information about a given SFP > module. One of those is the bitrate, which can be determined using a > nominal bitrate in addition with min and max values (in %). The SFP code > currently

Re: [PATCH net] net: phy: sfp: fix the BR,min computation

On Fri, May 04, 2018 at 05:10:54PM +0200, Antoine Tenart wrote: > In an SFP EEPROM values can be read to get information about a given SFP > module. One of those is the bitrate, which can be determined using a > nominal bitrate in addition with min and max values (in %). The SFP code > currently

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

> removed. This patch adds a warning when registering an SFP cage which do > not have its tx_disable pin wired or available. > > Signed-off-by: Antoine Tenart <antoine.ten...@bootlin.com> Looks fine, thanks. Acked-by: Russell King <rmk+ker...@armlinux.org.uk> > --- > d

Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available

> removed. This patch adds a warning when registering an SFP cage which do > not have its tx_disable pin wired or available. > > Signed-off-by: Antoine Tenart Looks fine, thanks. Acked-by: Russell King > --- > drivers/net/phy/sfp.c | 9 + > 1 file changed, 9 insertion

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote: > SFP connectors can be solder on a board without having any of their pins > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > and the overall link status reporting is left to other layers. > > In order to

Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors

On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote: > SFP connectors can be solder on a board without having any of their pins > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed, > and the overall link status reporting is left to other layers. > > In order to

Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote: > Hi, > > This is the 3rd version of bugfix series for kprobes on arm. > This series fixes 4 different issues which I found. > > - Fix to use smp_processor_id() after disabling preemption. > - Prohibit probing on

Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote: > Hi, > > This is the 3rd version of bugfix series for kprobes on arm. > This series fixes 4 different issues which I found. > > - Fix to use smp_processor_id() after disabling preemption. > - Prohibit probing on

Re: [PATCH v7 05/11] ARM: smp: Add initialization of CNTVOFF

On Fri, Apr 20, 2018 at 11:10:16PM +0200, Mylène Josserand wrote: > The CNTVOFF register from arch timer is uninitialized. > It should be done by the bootloader but it is currently not the case, > even for boot CPU because this SoC is booting in secure mode. > It leads to an random offset value

Re: [PATCH v7 05/11] ARM: smp: Add initialization of CNTVOFF

On Fri, Apr 20, 2018 at 11:10:16PM +0200, Mylène Josserand wrote: > The CNTVOFF register from arch timer is uninitialized. > It should be done by the bootloader but it is currently not the case, > even for boot CPU because this SoC is booting in secure mode. > It leads to an random offset value

Re: noveau vs arm dma ops

for the I2S audio driver, and I suspect is wrong - I doubt that the I2S sub-device itself does any DMA what so ever. 8<=== From: Russell King <rmk+ker...@armlinux.org.uk> Subject: drm: bridge: dw-hdmi: Negotiate dma mask with DMA API DMA drivers are supposed to negotiate the DMA mask with

Re: noveau vs arm dma ops

for the I2S audio driver, and I suspect is wrong - I doubt that the I2S sub-device itself does any DMA what so ever. 8<=== From: Russell King Subject: drm: bridge: dw-hdmi: Negotiate dma mask with DMA API DMA drivers are supposed to negotiate the DMA mask with the DMA API, but this was missin

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote: > On arm that doesn't work. The iommu api seems like a good fit, except > the dma-api tends to get in the way a bit (drm/msm apparently has > similar problems like tegra), and if you need contiguous memory > dma_alloc_coherent is the

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote: > On arm that doesn't work. The iommu api seems like a good fit, except > the dma-api tends to get in the way a bit (drm/msm apparently has > similar problems like tegra), and if you need contiguous memory > dma_alloc_coherent is the

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > - dma api hides the cache flushing requirements from us. GPUs love > > non-snooped access, and worse give userspace control over that. We want > > a strict

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > - dma api hides the cache flushing requirements from us. GPUs love > > non-snooped access, and worse give userspace control over that. We want > > a strict

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote: > [discussion about this patch, which should have been cced to the iommu > and linux-arm-kernel lists, but wasn't: > https://www.spinics.net/lists/dri-devel/msg173630.html] > > On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote: > [discussion about this patch, which should have been cced to the iommu > and linux-arm-kernel lists, but wasn't: > https://www.spinics.net/lists/dri-devel/msg173630.html] > > On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On Tue, Apr 24, 2018 at 09:25:44PM +0300, Jyri Sarha wrote: > On 24/04/18 20:06, Russell King - ARM Linux wrote: > > On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote: > >> On 24/04/18 13:14, Peter Rosin wrote: > >>> On 2018-04-24 10:08, Russell King - ARM L

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On Tue, Apr 24, 2018 at 09:25:44PM +0300, Jyri Sarha wrote: > On 24/04/18 20:06, Russell King - ARM Linux wrote: > > On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote: > >> On 24/04/18 13:14, Peter Rosin wrote: > >>> On 2018-04-24 10:08, Russell King - ARM L

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote: > On 24/04/18 13:14, Peter Rosin wrote: > > On 2018-04-24 10:08, Russell King - ARM Linux wrote: > >> On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote: > >>> On 2018-04-23 18:08, Russell King -

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote: > On 24/04/18 13:14, Peter Rosin wrote: > > On 2018-04-24 10:08, Russell King - ARM Linux wrote: > >> On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote: > >>> On 2018-04-23 18:08, Russell King -

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote: > On 2018-04-23 18:08, Russell King - ARM Linux wrote: > > On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote: > >> static int tda998x_remove(struct i2c_client *client) > >> { > >> - compo

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote: > On 2018-04-23 18:08, Russell King - ARM Linux wrote: > > On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote: > >> static int tda998x_remove(struct i2c_client *client) > >> { > >> - compo

Re: [PATCH] serial: mvebu-uart: Fix local flags handling on termios update

On Mon, Apr 23, 2018 at 04:04:06PM +0100, Russell King - ARM Linux wrote: > On Sun, Apr 22, 2018 at 08:58:04PM +0100, Russell King - ARM Linux wrote: > > On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote: > > > On Sun, 22 Apr 2018 16:55:16 +0100 > > > R

Re: [PATCH] serial: mvebu-uart: Fix local flags handling on termios update

On Mon, Apr 23, 2018 at 04:04:06PM +0100, Russell King - ARM Linux wrote: > On Sun, Apr 22, 2018 at 08:58:04PM +0100, Russell King - ARM Linux wrote: > > On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote: > > > On Sun, 22 Apr 2018 16:55:16 +0100 > > > Russ

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote: > static int tda998x_remove(struct i2c_client *client) > { > - component_del(>dev, _ops); > + struct device *dev = >dev; > + struct tda998x_bridge *bridge = dev_get_drvdata(dev); > + > + drm_bridge_remove(>bridge); > +

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote: > static int tda998x_remove(struct i2c_client *client) > { > - component_del(>dev, _ops); > + struct device *dev = >dev; > + struct tda998x_bridge *bridge = dev_get_drvdata(dev); > + > + drm_bridge_remove(>bridge); > +

Re: [PATCH] serial: mvebu-uart: Fix local flags handling on termios update

On Sun, Apr 22, 2018 at 08:58:04PM +0100, Russell King - ARM Linux wrote: > On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote: > > On Sun, 22 Apr 2018 16:55:16 +0100 > > Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > > > > > On Sun, Ap

Re: [PATCH] serial: mvebu-uart: Fix local flags handling on termios update

On Sun, Apr 22, 2018 at 08:58:04PM +0100, Russell King - ARM Linux wrote: > On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote: > > On Sun, 22 Apr 2018 16:55:16 +0100 > > Russell King - ARM Linux wrote: > > > > > On Sun, Apr 22, 2018 at 01:33:

Re: [PATCH] serial: mvebu-uart: Fix local flags handling on termios update

On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote: > On Sun, 22 Apr 2018 16:55:16 +0100 > Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > > > On Sun, Apr 22, 2018 at 01:33:46PM +0100, Marc Zyngier wrote: > > > Commit 68a0db1d7da2 reworked the

Re: [PATCH] serial: mvebu-uart: Fix local flags handling on termios update

On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote: > On Sun, 22 Apr 2018 16:55:16 +0100 > Russell King - ARM Linux wrote: > > > On Sun, Apr 22, 2018 at 01:33:46PM +0100, Marc Zyngier wrote: > > > Commit 68a0db1d7da2 reworked the baud rate selection, but al

Re: [PATCH] serial: mvebu-uart: Fix local flags handling on termios update

On Sun, Apr 22, 2018 at 01:33:46PM +0100, Marc Zyngier wrote: > Commit 68a0db1d7da2 reworked the baud rate selection, but also added > a (not so) subtle change in the way the local flags (c_lflag in the > termios structure) are handled, forcing the new flags to always be the > same as the old

Re: [PATCH] serial: mvebu-uart: Fix local flags handling on termios update

On Sun, Apr 22, 2018 at 01:33:46PM +0100, Marc Zyngier wrote: > Commit 68a0db1d7da2 reworked the baud rate selection, but also added > a (not so) subtle change in the way the local flags (c_lflag in the > termios structure) are handled, forcing the new flags to always be the > same as the old

Re: [PATCH] ARM: dts: imx6qdl-cubox-i: Move card-detect GPIO to 1.5 SOM devices only

On Sun, Apr 22, 2018 at 04:21:51PM +0200, Paul Kocialkowski wrote: > The Solid-Run CuBox-i lower board used in the first generation of > CuBox-i devices feature a hinged micro SD card slot, that does not have > card-detect capability. Since the card-detect GPIO was specified in the > common

Re: [PATCH] ARM: dts: imx6qdl-cubox-i: Move card-detect GPIO to 1.5 SOM devices only

On Sun, Apr 22, 2018 at 04:21:51PM +0200, Paul Kocialkowski wrote: > The Solid-Run CuBox-i lower board used in the first generation of > CuBox-i devices feature a hinged micro SD card slot, that does not have > card-detect capability. Since the card-detect GPIO was specified in the > common

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

t; And the winner is: > >> >> > >> >> ee333554fed5a986a90bb097ac7f9d6f05bf is the first bad commit > >> >> commit ee333554fed55555a986a90bb097ac7f9d6f05bf > >> >> Author: Jinbum Park <jinb.pa...@gmail.com> > >> >> Date

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

gt; > >> >> ee333554fed5a986a90bb097ac7f9d6f05bf is the first bad commit > >> >> commit ee333554fed5a986a90bb097ac7f9d6f05bf > >> >> Author: Jinbum Park > >> >> Date: Tue Mar 6 01:39:24 2018 +0100 > >> > ... > >>

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

On Thu, Apr 19, 2018 at 06:27:51PM +0200, Peter Rosin wrote: > This makes this driver work with all(?) drivers that are not > componentized and instead expect to connect to a panel/bridge. That > said, the only one tested is atmel_hlcdc. > > This hooks the relevant work function previously called

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

On Thu, Apr 19, 2018 at 06:27:51PM +0200, Peter Rosin wrote: > This makes this driver work with all(?) drivers that are not > componentized and instead expect to connect to a panel/bridge. That > said, the only one tested is atmel_hlcdc. > > This hooks the relevant work function previously called

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

On Fri, Apr 20, 2018 at 12:49:42PM +0200, Peter Rosin wrote: > On 2018-04-20 12:41, kbuild test robot wrote: > > Hi Peter, > > > > I love your patch! Yet something to improve: > > Yup, right you are! > > > [auto build test ERROR on drm/drm-next] > > [also build test ERROR on v4.17-rc1

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

On Fri, Apr 20, 2018 at 12:49:42PM +0200, Peter Rosin wrote: > On 2018-04-20 12:41, kbuild test robot wrote: > > Hi Peter, > > > > I love your patch! Yet something to improve: > > Yup, right you are! > > > [auto build test ERROR on drm/drm-next] > > [also build test ERROR on v4.17-rc1

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

On Fri, Apr 20, 2018 at 01:06:49PM +0300, Laurent Pinchart wrote: > Hi Peter, > > Thank you for the patch. > > On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote: > > This makes this driver work with all(?) drivers that are not > > componentized and instead expect to connect to a

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

On Fri, Apr 20, 2018 at 01:06:49PM +0300, Laurent Pinchart wrote: > Hi Peter, > > Thank you for the patch. > > On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote: > > This makes this driver work with all(?) drivers that are not > > componentized and instead expect to connect to a

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

On Wed, Apr 18, 2018 at 06:54:42PM +0100, Russell King wrote: > On Wed, Apr 18, 2018 at 01:31:55PM +1000, Stephen Rothwell wrote: > > Hi Russell, > > > > After merging the arm-current tree, today's linux-next build > > (lots of configs) failed like this: > > >

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

On Wed, Apr 18, 2018 at 06:54:42PM +0100, Russell King wrote: > On Wed, Apr 18, 2018 at 01:31:55PM +1000, Stephen Rothwell wrote: > > Hi Russell, > > > > After merging the arm-current tree, today's linux-next build > > (lots of configs) failed like this: > > >

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

ess maybe the sed expression isn't working for you. The sed expression should end up producing output such as: -0xc09138c4 +0xc0f30694 and that's it, two values, one preceded by a + and the other by a -. -- Russell King ARM architecture Linux Kernel maintainer

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

ess maybe the sed expression isn't working for you. The sed expression should end up producing output such as: -0xc09138c4 +0xc0f30694 and that's it, two values, one preceded by a + and the other by a -. -- Russell King ARM architecture Linux Kernel maintainer

Re: [PATCH] Replace unnecessary perl with sed, printf, and the shell $(( )) operator.

On Wed, Apr 11, 2018 at 08:38:37PM -0500, Rob Landley wrote: > You can build a kernel in a cross compiling environment that doesn't have perl > in the $PATH. Commit 429f7a062e3b broke that for 32 bit arm. Fix it. > > Signed-off-by: Rob Landley > --- > >

Re: [PATCH] Replace unnecessary perl with sed, printf, and the shell $(( )) operator.

On Wed, Apr 11, 2018 at 08:38:37PM -0500, Rob Landley wrote: > You can build a kernel in a cross compiling environment that doesn't have perl > in the $PATH. Commit 429f7a062e3b broke that for 32 bit arm. Fix it. > > Signed-off-by: Rob Landley > --- > > arch/arm/boot/compressed/Makefile |9

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote: > > > > Most uses I've seen do nothing more than use the FPE_xyz value to > > format diagnostic messages while dying. I struggled to find code that > > made

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote: > On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote: > > > > Most uses I've seen do nothing more than use the FPE_xyz value to > > format diagnostic messages while dying. I struggled to find code that > > made a meaningful

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 07:35:38PM +0100, Dave Martin wrote: > If that's the case though, I don't see how a userspace testsuite is > hitting this code path. Maybe I've misunderstood the context of this > thread. It isn't hitting this exact case. The userspace testsuite is hitting an entirely

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 07:35:38PM +0100, Dave Martin wrote: > If that's the case though, I don't see how a userspace testsuite is > hitting this code path. Maybe I've misunderstood the context of this > thread. It isn't hitting this exact case. The userspace testsuite is hitting an entirely

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 06:08:28PM +0100, Dave Martin wrote: > On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote: > > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux > > <li...@armlinux.org.uk> wrote: > > > > > > Yes, it does solve the

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Fri, Apr 13, 2018 at 06:08:28PM +0100, Dave Martin wrote: > On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote: > > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux > > wrote: > > > > > > Yes, it does solve the problem at hand with strace

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 10:22:15AM -0700, Linus Torvalds wrote: > On Thu, Apr 12, 2018 at 10:20 AM, Russell King - ARM Linux > <li...@armlinux.org.uk> wrote: > > > > This file was created to contain FPE_FIXME, by the "signal/arm: Document > > conflicts with SI_

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 10:22:15AM -0700, Linus Torvalds wrote: > On Thu, Apr 12, 2018 at 10:20 AM, Russell King - ARM Linux > wrote: > > > > This file was created to contain FPE_FIXME, by the "signal/arm: Document > > conflicts with SI_USER and SIGFPE

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 09:50:26AM -0700, Linus Torvalds wrote: > Does this attached patch perhaps fix the ARM case? > > It just uses FPE_FLTUNK as the default si_code for SIGFPE, which seems > sane enough. And then gets rid of FPE_FIXME, which should resolve the > nasty case. > > Hmm? Entirely

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 09:50:26AM -0700, Linus Torvalds wrote: > Does this attached patch perhaps fix the ARM case? > > It just uses FPE_FLTUNK as the default si_code for SIGFPE, which seems > sane enough. And then gets rid of FPE_FIXME, which should resolve the > nasty case. > > Hmm? Entirely

Re: [PATCH] tda998x: Check ref count before invoking drm_connector_cleanup in unbind

On Thu, Apr 12, 2018 at 03:42:32PM +0100, Ayan Kumar Halder wrote: > In a situation when the reference count of the drm connector is greater than > 1, > the unbind function should not invoke drm_connector_cleanup as this will lead > to an inconsistent state where the

Re: [PATCH] tda998x: Check ref count before invoking drm_connector_cleanup in unbind

On Thu, Apr 12, 2018 at 03:42:32PM +0100, Ayan Kumar Halder wrote: > In a situation when the reference count of the drm connector is greater than > 1, > the unbind function should not invoke drm_connector_cleanup as this will lead > to an inconsistent state where the

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 03:49:28PM +0300, Dmitry V. Levin wrote: > The "KERNEL BUG" diagnostics I was talking about was added to strace yesterday > as a part of workaround commit, see > https://github.com/strace/strace/commit/34c7794cc16e2511eda7b1d5767c655a83b17309 > Before that change the test

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 03:49:28PM +0300, Dmitry V. Levin wrote: > The "KERNEL BUG" diagnostics I was talking about was added to strace yesterday > as a part of workaround commit, see > https://github.com/strace/strace/commit/34c7794cc16e2511eda7b1d5767c655a83b17309 > Before that change the test

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 02:03:14PM +0300, Dmitry V. Levin wrote: > On Thu, Apr 12, 2018 at 10:58:11AM +0100, Russell King - ARM Linux wrote: > > On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote: > > > A similar commit v4.16-rc1~159^2~37 > > > (&quo

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 02:03:14PM +0300, Dmitry V. Levin wrote: > On Thu, Apr 12, 2018 at 10:58:11AM +0100, Russell King - ARM Linux wrote: > > On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote: > > > A similar commit v4.16-rc1~159^2~37 > > > (&quo

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote: > A similar commit v4.16-rc1~159^2~37 > ("signal/arm: Document conflicts with SI_USER and SIGFPE") must have > introduced a similar ABI regression to compat arm. So, could you explain how can this change cause a regression?

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote: > A similar commit v4.16-rc1~159^2~37 > ("signal/arm: Document conflicts with SI_USER and SIGFPE") must have > introduced a similar ABI regression to compat arm. So, could you explain how can this change cause a regression?

Re: [PATCH v2 0/4] ARM: amba: driver_override improvements and fixes

On Tue, Apr 10, 2018 at 03:21:42PM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > This patch series contains improvements to driver_override handling in > the AMBA bus driver, including two bugfixes that are based on similar > fixes for the PCI and platform buses, and which Todd Kjos would

Re: [PATCH v2 0/4] ARM: amba: driver_override improvements and fixes

On Tue, Apr 10, 2018 at 03:21:42PM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > This patch series contains improvements to driver_override handling in > the AMBA bus driver, including two bugfixes that are based on similar > fixes for the PCI and platform buses, and which Todd Kjos would

Re: [PATCH] drm/i2c: tda998x: Remove VLA usage

On Tue, Apr 10, 2018 at 02:52:35PM -0700, Laura Abbott wrote: > On 04/09/2018 03:21 PM, Russell King - ARM Linux wrote: > >On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote: > >>There's an ongoing effort to remove VLAs[1] from the kernel to eventually > >

Re: [PATCH] drm/i2c: tda998x: Remove VLA usage

On Tue, Apr 10, 2018 at 02:52:35PM -0700, Laura Abbott wrote: > On 04/09/2018 03:21 PM, Russell King - ARM Linux wrote: > >On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote: > >>There's an ongoing effort to remove VLAs[1] from the kernel to eventually > >

Re: [PATCH] drm/i2c: tda998x: Remove VLA usage

On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. The vla in reg_write_range is based on the length of data > passed. The one use of a non-constant size for this range is bounded by > the size

Re: [PATCH] drm/i2c: tda998x: Remove VLA usage

On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. The vla in reg_write_range is based on the length of data > passed. The one use of a non-constant size for this range is bounded by > the size

Re: [PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc

On Mon, Apr 09, 2018 at 01:44:22PM +0200, Peter Rosin wrote: > On 2018-04-09 13:17, Russell King - ARM Linux wrote: > > On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote: > >> During this, I found that the tda998x driver never sets the format in > >> the c

Re: [PATCH 0/5] Add tda998x (HDMI) support to atmel-hlcdc

On Mon, Apr 09, 2018 at 01:44:22PM +0200, Peter Rosin wrote: > On 2018-04-09 13:17, Russell King - ARM Linux wrote: > > On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote: > >> During this, I found that the tda998x driver never sets the format in > >> the c

<    7   8   9   10   11   12   13   14   15   16   >