Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [GIT PULL] ARM: at91: DT for 5.4
From: Arnd Bergmann @ 2019-09-03 14:14 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: linux-kernel@vger.kernel.org, Ludovic Desroches, SoC Team,
	arm-soc, Olof Johansson, Linux ARM
In-Reply-To: <20190825202642.GA18853@piout.net>

On Sun, Aug 25, 2019 at 10:26 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
>
> ----------------------------------------------------------------
> AT91 DT for 5.4
>
>  - style cleanup for at91sam9x5 based boards
>  - avoid colliding node and property names
>
Pulled into arm/dt, thanks!

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v6 3/3] soc: fsl: add RCPM driver
From: Pavel Machek @ 2019-09-03 14:12 UTC (permalink / raw)
  To: Ran Wang
  Cc: Mark Rutland, Biwen Li, Len Brown, Greg Kroah-Hartman,
	linux-pm@vger.kernel.org, Rafael J . Wysocki,
	linux-kernel@vger.kernel.org, Leo Li, devicetree@vger.kernel.org,
	Rob Herring, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB8PR04MB6826A9EA5D9232D55FE8BDEFF1AA0@DB8PR04MB6826.eurprd04.prod.outlook.com>


[-- Attachment #1.1: Type: text/plain, Size: 531 bytes --]

Hi!

> > +	/* Begin with first registered wakeup source */
> > +	ws = wakeup_source_get_start(&idx);
> 
> Since I have mad some change in this version, could you please take a look on this.
> If it's OK to you, I would re-add 'Acked-by: Pavel Machek <pavel@ucw.cz> '

I'm sorry, I'm a bit busy at the moment and this is not really my
area.

Best regards,
								Pavel
								
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL 6/7] i.MX arm64 device tree update for 5.4
From: Arnd Bergmann @ 2019-09-03 14:12 UTC (permalink / raw)
  To: Shawn Guo
  Cc: Stefan Agner, Li Yang, SoC Team, arm-soc, NXP Linux Team,
	Sascha Hauer, Fabio Estevam, Linux ARM
In-Reply-To: <20190825153237.28829-6-shawnguo@kernel.org>

On Sun, Aug 25, 2019 at 5:33 PM Shawn Guo <shawnguo@kernel.org> wrote:
> ----------------------------------------------------------------
> i.MX arm64 device tree update for 5.4:
>  - New board support: i.MX8MQ Nitrogen8m, Hummingboard Pulse,
>    PICO-PI-IMX8M, i.MX8QXP AI_ML, and LS1046A FRWY board.
>  - Add gpio-ranges for GPIO devices on i.MX8MQ and i.MX8MM.
>  - Update OPP table according to latest data sheet and add opp-suspend
>    to OPP table for i.MX8MQ and i.MX8MM.
>  - Add IDEL states for i.MX8MM SoC.
>  - Correct I2C clock divider for Layerscape SoCs.
>  - Add series alias and LPUART baud clock for i.MX8QXP SoC.
>  - Add MIPI D-PHY device for i.MX8MQ and enable it on imx8mq-librem5
>    board.
>  - Enable USB1 and Type-C support for i.MX8MM EVK board.
>  - Add Thermal Monitor Unit support for LS1028A SoC.
>  - Misc small update and correction on Layerscape and i.MX8 support.
>

Pulled into arm/dt, thanks!

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL 5/7] i.MX arm32 device tree changes for 5.4
From: Arnd Bergmann @ 2019-09-03 14:10 UTC (permalink / raw)
  To: Shawn Guo
  Cc: Stefan Agner, Li Yang, SoC Team, arm-soc, NXP Linux Team,
	Sascha Hauer, Fabio Estevam, Linux ARM
In-Reply-To: <20190825153237.28829-5-shawnguo@kernel.org>

On Sun, Aug 25, 2019 at 5:33 PM Shawn Guo <shawnguo@kernel.org> wrote:
>

> ----------------------------------------------------------------
> i.MX arm32 device tree changes for 5.4:
>  - New board support: ZII i.MX7 RMU2, Kontron i.MX6UL N6310, and
>    PHYTEC phyBOARD-Segin based on i.MX6ULL.
>  - A series from Andrey Smirnov to update vf610-zii boards on I2C
>    pinmux, switch watchdog, GPIO expander IRQ.
>  - Move GIC node into soc node for i.MX6 SoCs.
>  - Add OV5645 camera support for imx6qdl-wandboard board.
>  - Drop unneeded snvs_pwrkey node for imx7d-zii-rpu2 and imx7-colibri.
>  - Use simple-mfd instead of simple-bus for i.MX6 ANATOP.
>  - Move the native-mode property inside the display-timings node for
>    various i.MX25 and i.MX27 boards.
>  - Add EDMA devices for i.MX7ULP SoC.
>  - A series from Stefan Riedmueller to update imx6ul-phytec-segin board
>    on various devices.
>  - Use OF graph to describe the display for opos6uldev board.
>  - Misc random updates on i.MX7/6 boards.

Pulled into arm/dt, thanks!

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL 4/7] i.MX device tree update with new clocks
From: Arnd Bergmann @ 2019-09-03 14:08 UTC (permalink / raw)
  To: Shawn Guo
  Cc: Stephen Boyd, Stefan Agner, Li Yang, SoC Team, arm-soc,
	NXP Linux Team, Sascha Hauer, Fabio Estevam, Linux ARM
In-Reply-To: <20190825153237.28829-4-shawnguo@kernel.org>

On Sun, Aug 25, 2019 at 5:33 PM Shawn Guo <shawnguo@kernel.org> wrote:
>
> Hi,
>
> This is the device tree update with new clocks, so clock commit
> 6ad7cb7122ce ("clk: imx8: Add DSP related clocks") gets pulled in here
> as dependency, from i.MX clock branch I sent to Stephen.  Please
> consider to pull, thanks!


Pulled into arm/dt, and added a branch for the dependency. Thanks,

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v3] drm/mcde: Fix DSI transfers
From: Stephan Gerhold @ 2019-09-03 14:05 UTC (permalink / raw)
  To: Linus Walleij
  Cc: kbuild test robot, Maxime Ripard, Maarten Lankhorst, dri-devel,
	Sean Paul, linux-arm-kernel
In-Reply-To: <20190903081129.19617-1-linus.walleij@linaro.org>

On Tue, Sep 03, 2019 at 10:11:29AM +0200, Linus Walleij wrote:
> There were bugs in the DSI transfer (read and write) function
> as it was only tested with displays ever needing a single byte
> to be written. Fixed it up and tested so we can now write
> messages of up to 16 bytes and read up to 4 bytes from the
> display.
> 
> Tested with a Sony ACX424AKP display: this display now self-
> identifies and can control backlight in command mode.
> 
> Reported-by: kbuild test robot <lkp@intel.com>
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v2->v3:
> - Fix an error message to indicate reading error rather than
>   writing error.
> - Use the local variable for underflow print.
> - Collected Stephan's reviewed-by.
> ChangeLog v1->v2:
> - Fix a print modifier for dev_err() found by the build robot.
> ---
>  drivers/gpu/drm/mcde/mcde_dsi.c | 70 ++++++++++++++++++++++-----------
>  1 file changed, 47 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index 07f7090d08b3..cd261c266f35 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -178,22 +178,26 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
>  	const u32 loop_delay_us = 10; /* us */
>  	const u8 *tx = msg->tx_buf;
>  	u32 loop_counter;
> -	size_t txlen;
> +	size_t txlen = msg->tx_len;
> +	size_t rxlen = msg->rx_len;
>  	u32 val;
>  	int ret;
>  	int i;
>  
> -	txlen = msg->tx_len;
> -	if (txlen > 12) {
> +	if (txlen > 16) {
>  		dev_err(d->dev,
> -			"dunno how to write more than 12 bytes yet\n");
> +			"dunno how to write more than 16 bytes yet\n");
> +		return -EIO;
> +	}
> +	if (rxlen > 4) {
> +		dev_err(d->dev,
> +			"dunno how to read more than 4 bytes yet\n");
>  		return -EIO;
>  	}
>  
>  	dev_dbg(d->dev,
> -		"message to channel %d, %zd bytes",
> -		msg->channel,
> -		txlen);
> +		"message to channel %d, write %zd bytes read %zd bytes\n",
> +		msg->channel, txlen, rxlen);
>  
>  	/* Command "nature" */
>  	if (MCDE_DSI_HOST_IS_READ(msg->type))
> @@ -210,9 +214,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
>  	if (mipi_dsi_packet_format_is_long(msg->type))
>  		val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT;
>  	val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT;
> -	/* Add one to the length for the MIPI DCS command */
> -	val |= txlen
> -		<< DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
> +	val |= txlen << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
>  	val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN;
>  	val |= msg->type << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT;
>  	writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS);
> @@ -249,17 +251,36 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
>  	writel(1, d->regs + DSI_DIRECT_CMD_SEND);
>  
>  	loop_counter = 1000 * 1000 / loop_delay_us;
> -	while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> -		 DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
> -	       && --loop_counter)
> -		usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> -
> -	if (!loop_counter) {
> -		dev_err(d->dev, "DSI write timeout!\n");
> -		return -ETIME;
> +	if (MCDE_DSI_HOST_IS_READ(msg->type)) {
> +		/* Read command */
> +		while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> +			 (DSI_DIRECT_CMD_STS_READ_COMPLETED |
> +			  DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR))
> +		       && --loop_counter)
> +			usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> +		if (!loop_counter) {
> +			dev_err(d->dev, "DSI write timeout!\n");

It looks like you changed the wrong message.
This one is the "read timeout",

> +			return -ETIME;
> +		}
> +	} else {
> +		/* Writing only */
> +		while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> +			 DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
> +		       && --loop_counter)
> +			usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> +
> +		if (!loop_counter) {
> +			dev_err(d->dev, "DSI read timeout!\n");

and this one the "write timeout".

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH bpf-next] arm64: bpf: optimize modulo operation
From: Daniel Borkmann @ 2019-09-03 14:05 UTC (permalink / raw)
  To: jerinj, netdev, Alexei Starovoitov, Zi Shen Lim, Catalin Marinas,
	Will Deacon, Martin KaFai Lau, Song Liu, Yonghong Song,
	open list:BPF JIT for ARM64,
	moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), open list
In-Reply-To: <20190902061448.28252-1-jerinj@marvell.com>

On 9/2/19 8:14 AM, jerinj@marvell.com wrote:
> From: Jerin Jacob <jerinj@marvell.com>
> 
> Optimize modulo operation instruction generation by
> using single MSUB instruction vs MUL followed by SUB
> instruction scheme.
> 
> Signed-off-by: Jerin Jacob <jerinj@marvell.com>

Applied, thanks!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL 3/7] i.MX DT bindings update for 5.4
From: Arnd Bergmann @ 2019-09-03 14:04 UTC (permalink / raw)
  To: Shawn Guo
  Cc: Stefan Agner, Li Yang, SoC Team, arm-soc, NXP Linux Team,
	Sascha Hauer, Fabio Estevam, Linux ARM
In-Reply-To: <20190825153237.28829-3-shawnguo@kernel.org>

On Sun, Aug 25, 2019 at 5:33 PM Shawn Guo <shawnguo@kernel.org> wrote:
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
>   Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-bindings-5.4
>
> for you to fetch changes up to 8d5fc0b95fd1542c575ac64457bd17d74a206497:
>
>   dt-bindings: arm: fsl: Add Kontron i.MX6UL N6310 compatibles (2019-08-24 22:44:48 +0200)
>
> ----------------------------------------------------------------
> i.MX DT bindings update for 5.4
>  - Add SoC bindings for i.MX8MN.
>  - Add board bindings for pico-pi-imx8m, Hummingboard Pulse, imx8mq
>    nitrogen, i.MX8QXP AI_ML, ls1046a-frwy etc.
>  - Add vendor prefix for Anvo-Systems and Einfochips.
>  - Update LPUART bindings for i.MX8QXP clock requirement.
>  - Update imx-weim bindings for optional burst clock mode support.
>  - Update EEPROM bindings for Anvo ANV32E61W device support.

Pulled into arm/dt, thanks!

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL] ARM: aspeed: devicetree changes for 5.4
From: Arnd Bergmann @ 2019-09-03 14:03 UTC (permalink / raw)
  To: Joel Stanley; +Cc: Andrew Jeffery, SoC Team, arm, Linux ARM, linux-aspeed
In-Reply-To: <CACPK8XfKHpNYXNE_VRaLeGUQa7-hkmUS0nsPfaeSLE4sckKFHg@mail.gmail.com>

On Sun, Aug 25, 2019 at 4:10 PM Joel Stanley <joel@jms.id.au> wrote:
> ----------------------------------------------------------------
> ASPEED device tree updates for 5.4
>
> New machines:
>
>  - Facebook Wedge100, Wedge40 and Minipack
>  - Lenovo Hr855xg2
>  - Wistron Mihawk
>
> There's a few other updates, notably some changes to to use the newly
> added SDHCI driver.

Pulled into arm/dt, thanks!

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL 2/2] dts changes for omap variants for v5.4
From: Arnd Bergmann @ 2019-09-03 14:01 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <pull-1566599057-142651@atomide.com-2>

On Sat, Aug 24, 2019 at 12:24 AM Tony Lindgren <tony@atomide.com> wrote:
> ----------------------------------------------------------------
> dts changes for omap variants for v5.4
>
> Remove regulator-boot-off properties that we never had in the mainline
> kernel so they won't do anything. We add stdout-path for gta04, and
> make am335x-boneblue use am335x-osd335x-common.dtsi file.

Pulled into arm/dt, thanks!

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL] arm64: mediatek: dts64 updates for v5.4
From: Arnd Bergmann @ 2019-09-03 14:00 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: SoC Team, arm-soc, moderated list:ARM/Mediatek SoC support,
	Hsin-Hsiung Wang, Mars Cheng,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <def8fb77-fce4-097d-7ae2-8c4670bc09c1@gmail.com>

On Fri, Aug 23, 2019 at 6:42 PM Matthias Brugger <matthias.bgg@gmail.com> wrote:
>   dt-bindings: irq: mtk, sysirq: add support for mt6779 (2019-08-23 17:50:07 +0200)
>
> ----------------------------------------------------------------
> mt8183:
> - fix pwrap interrupt number
> - add i2c notes
>
> dt-bindings:
> - add compatible for mt6779
> - add mt6779 uart and sysirq compatible

Pulled into arm/dt, thanks!

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL] arm: mediatek: dts32 updates for v5.4
From: Arnd Bergmann @ 2019-09-03 13:59 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: SoC Team, arm-soc, moderated list:ARM/Mediatek SoC support,
	Ryder Lee, linux-arm-kernel@lists.infradead.org
In-Reply-To: <e236f659-2851-21b8-1873-314cd72ed6be@gmail.com>

On Fri, Aug 23, 2019 at 6:40 PM Matthias Brugger <matthias.bgg@gmail.com> wrote:

>
>   https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
> tags/v5.3-next-dts32
>
> for you to fetch changes up to cc212241df0b8975bb0e6d7f9028405a9c664e49:
>
>   arm: dts: mediatek: add basic support for MT7629 SoC (2019-08-22 11:22:17 +0200)
>
> ----------------------------------------------------------------
> add support for the mt7629 reference board
>

Pulled into arm/dt, thanks!

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL] Allwinner Device Tree Changes for 5.4
From: Arnd Bergmann @ 2019-09-03 13:57 UTC (permalink / raw)
  To: Maxime Ripard; +Cc: SoC Team, arm-soc, Chen-Yu Tsai, Linux ARM
In-Reply-To: <d97e6252-9dd7-4cf5-a3cf-56f78b0ca455.lettre@localhost>

On Fri, Aug 23, 2019 at 4:38 PM Maxime Ripard <mripard@kernel.org> wrote:

> ----------------------------------------------------------------
> Allwinner DT changes for 5.4
>
> Our usual pile of patches for the next release, which include mostly:
>   - More fixes thanks to the DT validation using the YAML bindings
>   - IR receiver support on the H6
>   - SPDIF support on the H6
>   - I2C Support on the H6
>   - CSI support on the A20
>   - RTC support on the H6
>   - New Boards: Lichee Zero Plus, Tanix TX6, A64-Olinuxino-eMMC

Pulled into arm/dt, thanks!

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PULL 5/5] Renesas DT binding updates for v5.4 (take two)
From: Arnd Bergmann @ 2019-09-03 13:55 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Simon Horman, Magnus Damm, Linux-Renesas, arm-soc, arm-soc,
	Linux ARM
In-Reply-To: <20190823123643.18799-6-geert+renesas@glider.be>

On Fri, Aug 23, 2019 at 2:37 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> The following changes since commit 8cb7ec14188649cf2151464050413e2814fd7cf1:
>
>   dt-bindings: can: rcar_can: Complete documentation for RZ/G2[EM] (2019-07-29 15:36:39 +0200)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dt-bindings-for-v5.4-tag2
>
> for you to fetch changes up to 7ac2d56f783d6d546e89a4e44fb46532667aa7a5:
>
>   dt-bindings: can: rcar_can: document r8a77470 support (2019-08-23 14:25:05 +0200)
>
> ----------------------------------------------------------------
> Renesas DT binding updates for v5.4 (take two)
>
>   - Renesas DT binding doc filename cleanups,
>   - R-Car Gen3 and RZ/G1 updates for the R-Car CAN and CANFD DT
>     bindings.

Pulled into arm/dt, thanks!

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PULL 3/5] Renesas ARM64 DT updates for v5.4 (take two)
From: Arnd Bergmann @ 2019-09-03 13:53 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Simon Horman, Magnus Damm, Linux-Renesas, arm-soc, arm-soc,
	Linux ARM
In-Reply-To: <20190823123643.18799-4-geert+renesas@glider.be>

On Fri, Aug 23, 2019 at 2:36 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> The following changes since commit 0a05b3d7fee511de8a1c9dffc3d86f1df55e1737:
>
>   arm64: dts: renesas: ulcb: Sort nodes (2019-07-30 11:25:35 +0200)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm64-dt-for-v5.4-tag2
>
> for you to fetch changes up to 38290431d56d7d3928ac89e9f8d3d6b3c8df4c6e:
>
>   arm64: dts: renesas: Update 'vsps' properties for readability (2019-08-21 14:18:56 +0200)
>
> ----------------------------------------------------------------
> Renesas ARM64 DT updates for v5.4 (take two)
>
>   - Sort nodes in various SoC and board DTSes,
>   - HDMI sound for HiHope RZ/G2M and R-Car M3-N Salvator-X(S) boards,
>   - Limit EtherAVB to 100Mbps on the Ebisu and Draak boards,
>   - Small fixes and improvements.
>


Pulled into arm/dt, thanks!

     Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 3/8] mips: compat: vdso: Use legacy syscalls as fallback
From: Paul Burton @ 2019-09-03 13:52 UTC (permalink / raw)
  To: Vincenzo Frascino
  Cc: linux-arch@vger.kernel.org, luto@kernel.org,
	catalin.marinas@arm.com, 0x7f454c46@gmail.com,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	linux-kselftest@vger.kernel.org, tglx@linutronix.de,
	salyzyn@android.com, will@kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190830135902.20861-4-vincenzo.frascino@arm.com>

Hi Vincenzo,

On Fri, Aug 30, 2019 at 02:58:57PM +0100, Vincenzo Frascino wrote:
> The generic VDSO implementation uses the Y2038 safe clock_gettime64() and
> clock_getres_time64() syscalls as fallback for 32bit VDSO. This breaks
> seccomp setups because these syscalls might be not (yet) allowed.
> 
> Implement the 32bit variants which use the legacy syscalls and select the
> variant in the core library.
> 
> The 64bit time variants are not removed because they are required for the
> time64 based vdso accessors.
> 
> Cc: Paul Burton <paul.burton@mips.com>
> Fixes: 00b26474c2f1 ("lib/vdso: Provide generic VDSO implementation")
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>

How would you like this to be applied? I'd be happy to apply this one to
mips-next, where commit 24640f233b46 ("mips: Add support for generic
vDSO") added the file being modified here. Otherwise:

    Acked-by: Paul Burton <paul.burton@mips.com>

Thanks,
    Paul

> ---
>  arch/mips/include/asm/vdso/gettimeofday.h | 45 +++++++++++++++++++++++
>  arch/mips/vdso/config-n32-o32-env.c       |  1 +
>  2 files changed, 46 insertions(+)
> 
> diff --git a/arch/mips/include/asm/vdso/gettimeofday.h b/arch/mips/include/asm/vdso/gettimeofday.h
> index c59fe08b0347..e78462e8ca2e 100644
> --- a/arch/mips/include/asm/vdso/gettimeofday.h
> +++ b/arch/mips/include/asm/vdso/gettimeofday.h
> @@ -105,6 +105,51 @@ static __always_inline int clock_getres_fallback(
>  	return error ? -ret : ret;
>  }
>  
> +#if _MIPS_SIM != _MIPS_SIM_ABI64
> +
> +#define VDSO_HAS_32BIT_FALLBACK	1
> +
> +static __always_inline long clock_gettime32_fallback(
> +					clockid_t _clkid,
> +					struct old_timespec32 *_ts)
> +{
> +	register struct old_timespec32 *ts asm("a1") = _ts;
> +	register clockid_t clkid asm("a0") = _clkid;
> +	register long ret asm("v0");
> +	register long nr asm("v0") = __NR_clock_gettime;
> +	register long error asm("a3");
> +
> +	asm volatile(
> +	"       syscall\n"
> +	: "=r" (ret), "=r" (error)
> +	: "r" (clkid), "r" (ts), "r" (nr)
> +	: "$1", "$3", "$8", "$9", "$10", "$11", "$12", "$13",
> +	  "$14", "$15", "$24", "$25", "hi", "lo", "memory");
> +
> +	return error ? -ret : ret;
> +}
> +
> +static __always_inline int clock_getres32_fallback(
> +					clockid_t _clkid,
> +					struct old_timespec32 *_ts)
> +{
> +	register struct old_timespec32 *ts asm("a1") = _ts;
> +	register clockid_t clkid asm("a0") = _clkid;
> +	register long ret asm("v0");
> +	register long nr asm("v0") = __NR_clock_getres;
> +	register long error asm("a3");
> +
> +	asm volatile(
> +	"       syscall\n"
> +	: "=r" (ret), "=r" (error)
> +	: "r" (clkid), "r" (ts), "r" (nr)
> +	: "$1", "$3", "$8", "$9", "$10", "$11", "$12", "$13",
> +	  "$14", "$15", "$24", "$25", "hi", "lo", "memory");
> +
> +	return error ? -ret : ret;
> +}
> +#endif
> +
>  #ifdef CONFIG_CSRC_R4K
>  
>  static __always_inline u64 read_r4k_count(void)
> diff --git a/arch/mips/vdso/config-n32-o32-env.c b/arch/mips/vdso/config-n32-o32-env.c
> index 7f8d957abd4a..0011a632aef2 100644
> --- a/arch/mips/vdso/config-n32-o32-env.c
> +++ b/arch/mips/vdso/config-n32-o32-env.c
> @@ -10,6 +10,7 @@
>   */
>  #undef CONFIG_64BIT
>  
> +#define BUILD_VDSO32
>  #define CONFIG_32BIT 1
>  #define CONFIG_GENERIC_ATOMIC64 1
>  #define BUILD_VDSO32_64
> -- 
> 2.23.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 1/1] soc: qcom: geni: Provide parameter error checking
From: Lee Jones @ 2019-09-03 13:50 UTC (permalink / raw)
  To: agross
  Cc: linux-arm-msm, Lee Jones, linux-kernel, linux-arm-kernel,
	bjorn.andersson

When booting with ACPI, the Geni Serial Engine is not set as the I2C/SPI
parent and thus, the wrapper (parent device) is unassigned.  This causes
the kernel to crash with a null dereference error.

Fixes: 8bc529b25354 ("soc: qcom: geni: Add support for ACPI")
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Since we are already at -rc7 this patch should be processed ASAP - thank you.

drivers/soc/qcom/qcom-geni-se.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
index d5cf953b4337..7d622ea1274e 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -630,6 +630,9 @@ int geni_se_tx_dma_prep(struct geni_se *se, void *buf, size_t len,
 	struct geni_wrapper *wrapper = se->wrapper;
 	u32 val;
 
+	if (!wrapper)
+		return -EINVAL;
+
 	*iova = dma_map_single(wrapper->dev, buf, len, DMA_TO_DEVICE);
 	if (dma_mapping_error(wrapper->dev, *iova))
 		return -EIO;
@@ -663,6 +666,9 @@ int geni_se_rx_dma_prep(struct geni_se *se, void *buf, size_t len,
 	struct geni_wrapper *wrapper = se->wrapper;
 	u32 val;
 
+	if (!wrapper)
+		return -EINVAL;
+
 	*iova = dma_map_single(wrapper->dev, buf, len, DMA_FROM_DEVICE);
 	if (dma_mapping_error(wrapper->dev, *iova))
 		return -EIO;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-09-03 13:50 UTC (permalink / raw)
  To: Adam Ford
  Cc: Rob Herring, devicetree, Tony Lindgren, p.zabel,
	Santosh Shilimkar, Linux-OMAP, arm-soc
In-Reply-To: <CAHCN7xKNSj_DW+Gcbpy4ehphBYCbJw9mSATOcWzT7ZcZR81r6g@mail.gmail.com>

On 03/09/2019 16:19, Adam Ford wrote:
> On Tue, Sep 3, 2019 at 2:26 AM Tero Kristo <t-kristo@ti.com> wrote:
>>
>> On 02/09/2019 16:39, Rob Herring wrote:
>>> On Fri, Aug 30, 2019 at 03:18:07PM +0300, Tero Kristo wrote:
>>>> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
>>>> of these will act as a power domain controller and potentially as a reset
>>>> provider.
>>>>
>>>
>>> Converting this to schema would be nice.
>>
>> Do you have documentation about schema somewhere? Basically what I need
>> to do to fix this.
>>
>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>>    .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
>>>
>>> bindings/reset/
>>
>> I did not put this under reset, because this is basically a
>> multi-purpose function. Reset just happens to be the first functionality
>> it is going to provide. It will be followed by power domain support
>> later on.
>>
>> Any thoughts?
>>
>>>
>>>>    1 file changed, 31 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> new file mode 100644
>>>> index 000000000000..7c7527c37734
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> @@ -0,0 +1,31 @@
>>>> +OMAP PRM instance bindings
>>>> +
>>>> +Power and Reset Manager is an IP block on OMAP family of devices which
>>>> +handle the power domains and their current state, and provide reset
>>>> +handling for the domains and/or separate IP blocks under the power domain
>>>> +hierarchy.
>>>> +
>>>> +Required properties:
>>>> +- compatible:       Must be one of:
>>>> +            "ti,am3-prm-inst"
> 
> Would it make sense to call it am33 instead of am3?  The AM35xx is
> different than AM33.

Well, am35xx is effectively just a variant of omap3, they just named it 
funnily. Same for dra7 vs. am57xx. Also, bindings of type "ti,am3-*" 
exist for other am33xx functionality already.

-Tero

> 
>>>> +            "ti,am4-prm-inst"
>>>> +            "ti,omap4-prm-inst"
>>>> +            "ti,omap5-prm-inst"
>>>> +            "ti,dra7-prm-inst"
>>>
>>> '-inst' seems a bit redundant.
>>
>> ti,xyz-prm is already reserved by the parent node of all these.
>>
>> The hierarchy is basically like this (omap4 as example):
>>
>> prm: prm@4a306000 {
>>     compatible = "ti,omap4-prm";
>>     ...
>>
>>     prm_dsp: prm@400 {
>>       compatible = "ti,omap4-prm-inst";
>>       ...
>>     };
>>
>>     prm_device: prm@1b00 {
>>       compatible = "ti,omap4-prm-inst";
>>       ...
>>     };
>>
>>     ...
>> };
>>
>>
>>
>>>
>>>> +- reg:              Contains PRM instance register address range
>>>> +            (base address and length)
>>>> +
>>>> +Optional properties:
>>>> +- #reset-cells:     Should be 1 if the PRM instance in question supports resets.
>>>> +- clocks:   Associated clocks for the reset signals if any. Certain reset
>>>> +            signals can't be toggled properly without functional clock
>>>> +            being active for them.
>>>> +
>>>> +Example:
>>>> +
>>>> +prm_dsp2: prm@1b00 {
>>>
>>> reset-controller@...
>>
>> Well, as said, the same node is going to be also power domain provider
>> later on...
>>
>>>
>>>> +    compatible = "ti,dra7-prm-inst";
>>>> +    reg = <0x1b00 0x40>;
>>>> +    #reset-cells = <1>;
>>>> +    clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>;
>>>> +};
>>>> --
>>>> 2.17.1
>>>>
>>>> --
>>>
>>
> 
> adam
>> --

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PULL 1/5] Renesas ARM DT updates for v5.4
From: Arnd Bergmann @ 2019-09-03 13:36 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Simon Horman, Magnus Damm, Linux-Renesas, arm-soc, arm-soc,
	Linux ARM
In-Reply-To: <20190823123643.18799-2-geert+renesas@glider.be>

On Fri, Aug 23, 2019 at 2:37 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
>   Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-dt-for-v5.4-tag1
>
> for you to fetch changes up to 57012813f1ba82412cdcc3665b04d4353b357378:
>
>   ARM: dts: r8a77470: Add PMU device node (2019-08-21 10:28:57 +0200)
>
> ----------------------------------------------------------------
> Renesas ARM DT updates for v5.4
>
>   - Fix HSCIF PM Domain on R-Car H1,
>   - PMU support for RZ/G1C.
>

Pulled into arm/dt, thanks!

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Philipp Zabel @ 2019-09-03 13:25 UTC (permalink / raw)
  To: Tony Lindgren, Tero Kristo
  Cc: Rob Herring, linux-omap, Santosh Shilimkar,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	devicetree
In-Reply-To: <20190903131632.GL52127@atomide.com>

Hi Tony,

On Tue, 2019-09-03 at 06:16 -0700, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [190903 08:15]:
> > On 03/09/2019 11:10, Rob Herring wrote:
> > > I prefer that bindings be complete as possible even if driver support
> > > is not there yet. Adding power domain support may only mean adding
> > > '#power-domain-cells'.
> > > 
> > > The location is fine then.
> > 
> > Yeah, I assume just adding power-domain-cells should be enough. I am not too
> > sure before I start trying this out though so did not want to add it yet.
> 
> Should we call the device tree node name power-controller instead of
> reset controller though? Most of the PRM instances do not have a
> separate rstctrl reset control functionality.
> 
> Anybody got better any better naming in mind?

power-controller seems fine to me, that is their primary function.

regards
Philipp

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Adam Ford @ 2019-09-03 13:19 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Rob Herring, devicetree, Tony Lindgren, p.zabel,
	Santosh Shilimkar, Linux-OMAP, arm-soc
In-Reply-To: <e8d700cd-8f3c-5cea-a022-b20a595fc1e1@ti.com>

On Tue, Sep 3, 2019 at 2:26 AM Tero Kristo <t-kristo@ti.com> wrote:
>
> On 02/09/2019 16:39, Rob Herring wrote:
> > On Fri, Aug 30, 2019 at 03:18:07PM +0300, Tero Kristo wrote:
> >> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
> >> of these will act as a power domain controller and potentially as a reset
> >> provider.
> >>
> >
> > Converting this to schema would be nice.
>
> Do you have documentation about schema somewhere? Basically what I need
> to do to fix this.
>
> >
> >> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> >> ---
> >>   .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
> >
> > bindings/reset/
>
> I did not put this under reset, because this is basically a
> multi-purpose function. Reset just happens to be the first functionality
> it is going to provide. It will be followed by power domain support
> later on.
>
> Any thoughts?
>
> >
> >>   1 file changed, 31 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >> new file mode 100644
> >> index 000000000000..7c7527c37734
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> >> @@ -0,0 +1,31 @@
> >> +OMAP PRM instance bindings
> >> +
> >> +Power and Reset Manager is an IP block on OMAP family of devices which
> >> +handle the power domains and their current state, and provide reset
> >> +handling for the domains and/or separate IP blocks under the power domain
> >> +hierarchy.
> >> +
> >> +Required properties:
> >> +- compatible:       Must be one of:
> >> +            "ti,am3-prm-inst"

Would it make sense to call it am33 instead of am3?  The AM35xx is
different than AM33.

> >> +            "ti,am4-prm-inst"
> >> +            "ti,omap4-prm-inst"
> >> +            "ti,omap5-prm-inst"
> >> +            "ti,dra7-prm-inst"
> >
> > '-inst' seems a bit redundant.
>
> ti,xyz-prm is already reserved by the parent node of all these.
>
> The hierarchy is basically like this (omap4 as example):
>
> prm: prm@4a306000 {
>    compatible = "ti,omap4-prm";
>    ...
>
>    prm_dsp: prm@400 {
>      compatible = "ti,omap4-prm-inst";
>      ...
>    };
>
>    prm_device: prm@1b00 {
>      compatible = "ti,omap4-prm-inst";
>      ...
>    };
>
>    ...
> };
>
>
>
> >
> >> +- reg:              Contains PRM instance register address range
> >> +            (base address and length)
> >> +
> >> +Optional properties:
> >> +- #reset-cells:     Should be 1 if the PRM instance in question supports resets.
> >> +- clocks:   Associated clocks for the reset signals if any. Certain reset
> >> +            signals can't be toggled properly without functional clock
> >> +            being active for them.
> >> +
> >> +Example:
> >> +
> >> +prm_dsp2: prm@1b00 {
> >
> > reset-controller@...
>
> Well, as said, the same node is going to be also power domain provider
> later on...
>
> >
> >> +    compatible = "ti,dra7-prm-inst";
> >> +    reg = <0x1b00 0x40>;
> >> +    #reset-cells = <1>;
> >> +    clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>;
> >> +};
> >> --
> >> 2.17.1
> >>
> >> --
> >
>

adam
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL] arm64: dts: Amlogic updates for v5.4
From: Arnd Bergmann @ 2019-09-03 13:18 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: open list:ARM/Amlogic Meson SoC support, SoC Team, arm-soc,
	Linux ARM
In-Reply-To: <7hr25fbi4v.fsf@baylibre.com>

On Wed, Aug 21, 2019 at 12:13 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> Arnd, Olof,
>
> Below is a regular round of DT updates for the 64-bit Amlogic SoCs.
>
> Of note is a set of clock patches I've merged in from a stable tag
> (already merged into clk-next.)  This was needed for some new IDs added
> for the handful of new SoCs we've added this cycle.

Ok, pulled into arm/dt, thanks!

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCHv3 01/10] dt-bindings: omap: add new binding for PRM instances
From: Tony Lindgren @ 2019-09-03 13:16 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Rob Herring, devicetree, Philipp Zabel, Santosh Shilimkar,
	linux-omap,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <7c2c8a4d-d24e-ceec-afc1-04cdc4d5d952@ti.com>

* Tero Kristo <t-kristo@ti.com> [190903 08:15]:
> On 03/09/2019 11:10, Rob Herring wrote:
> > I prefer that bindings be complete as possible even if driver support
> > is not there yet. Adding power domain support may only mean adding
> > '#power-domain-cells'.
> > 
> > The location is fine then.
> 
> Yeah, I assume just adding power-domain-cells should be enough. I am not too
> sure before I start trying this out though so did not want to add it yet.

Should we call the device tree node name power-controller instead of
reset controller though? Most of the PRM instances do not have a
separate rstctrl reset control functionality.

Anybody got better any better naming in mind?

Regards,

Tony



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL] ARM: dts: Amlogic updates for v5.4
From: Arnd Bergmann @ 2019-09-03 13:14 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: Martin Blumenstingl, open list:ARM/Amlogic Meson SoC support,
	SoC Team, arm-soc, Linux ARM
In-Reply-To: <7hzhk3bi96.fsf@baylibre.com>

On Wed, Aug 21, 2019 at 12:10 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> ARM: dts: Amlogic updates for v5.4
>
> Highlights
> - odroid-c1: use MAC address from efuse
> - add VDD_EE regulator to several boards
>
Pulled into arm/dt, thanks!

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [GIT PULL 1/2] SoCFPGA DTS updates for v5.4
From: Arnd Bergmann @ 2019-09-03 13:11 UTC (permalink / raw)
  To: Dinh Nguyen; +Cc: SoC Team, arm-soc, Linux ARM
In-Reply-To: <20190819141659.26414-1-dinguyen@kernel.org>

On Mon, Aug 19, 2019 at 4:17 PM Dinh Nguyen <dinguyen@kernel.org> wrote:
> SoCFPGA DTS updates for v5.4
> - Add reset properties for various peripherals
>         - QSPI OCP and DMA on Arria10
>         - DMA on Agilex/Stratix10
> - Update NAND controller bindings to match driver update
> - Add NAND controller to Stratix10
> - VINING FPGA board fixups
>         - Update button mapping
>         - Adjust GMAC1 clock and TXD skew settings
> - Add missing reset-names for dma controller
>


Pulled into arm/dt, thanks!

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox