Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] soc: imx: gpc: de-register power domains only if initialized
From: Stefan Agner @ 2018-01-07 13:49 UTC (permalink / raw)
  To: linux-arm-kernel

If power domain information are missing in the device tree, no
power domains get initialized. However, imx_gpc_remove tries to
remove power domains always in the old DT binding case. Only
remove power domains when imx_gpc_probe initialized them in
first place.

Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver")
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
 drivers/soc/imx/gpc.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 53f7275d6cbd..62bb724726d9 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -470,13 +470,21 @@ static int imx_gpc_probe(struct platform_device *pdev)
 
 static int imx_gpc_remove(struct platform_device *pdev)
 {
+	struct device_node *pgc_node;
 	int ret;
 
+	pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc");
+
+	/* bail out if DT too old and doesn't provide the necessary info */
+	if (!of_property_read_bool(pdev->dev.of_node, "#power-domain-cells") &&
+	    !pgc_node)
+		return 0;
+
 	/*
 	 * If the old DT binding is used the toplevel driver needs to
 	 * de-register the power domains
 	 */
-	if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
+	if (!pgc_node) {
 		of_genpd_del_provider(pdev->dev.of_node);
 
 		ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
-- 
2.15.1

^ permalink raw reply related

* [PATCH v6 10/10] clocksource: timer-dm: Check prescaler value
From: Keerthy @ 2018-01-07 15:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180104224713.GA11557@lenoch>



On 1/5/2018 4:17 AM, Ladislav Michl wrote:
> On Tue, Jan 02, 2018 at 03:39:59PM +0530, Keerthy wrote:
>> From: Ladislav Michl <ladis@linux-mips.org>
>>
>> Invalid prescaler value is silently ignored. Fix that
>> by returning -EINVAL in such case. As invalid value
>> disabled use of the prescaler, use -1 explicitely for
>> that purpose.
>>
>> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
>> ---
>>   drivers/clocksource/timer-dm.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
>> index 60db173..01a9cb0 100644
>> --- a/drivers/clocksource/timer-dm.c
>> +++ b/drivers/clocksource/timer-dm.c
>> @@ -672,6 +672,9 @@ int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler)
>>   	if (prescaler >= 0x00 && prescaler <= 0x07) {
>>   		l |= OMAP_TIMER_CTRL_PRE;
>>   		l |= prescaler << 2;
>> +	} else {
>> +		if (prescaler != -1)
>> +			return -EINVAL;
> 
> Argh... This is actually wrong, as it leaves timer enabled.
> I suggest simply dropping this patch and I'll rethink whole
> approach a bit later (and better).

Okay. I hope the rest 9 patches work well for you.

> 
>>   	}
>>   	omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
>>   
> 
> Sorry for the noise,
> 	ladis
> 

^ permalink raw reply

* [PATCH v6 00/10] omap: dmtimer: Move driver out of plat-omap
From: Keerthy @ 2018-01-07 15:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1514887799-24605-1-git-send-email-j-keerthy@ti.com>



On 1/2/2018 3:39 PM, Keerthy wrote:
> The series moves dmtimer out of plat-omap to drivers/clocksource.
> The series also does a bunch of changes to pwm-omap-dmtimer code
> to adapt to the driver migration and clean up plat specific
> pdata-quirks and use the dmtimer platform data.
> 
> Boot tested on DRA7-EVM and AM437X-GP-EVM.
> Compile tested omap1_defconfig.
> 
> This is based on top of linux-next branch.
> 
> This is tested on on IGEPv2 (OMAP3430 based) by Ladis.

Daniel/Theirry,

Let me know if you have any comments on this migration series.
Patch 10/10 from Ladis can be dropped as he plans to rework on that.

Regards,
Keerthy

> 
> Changes from V5:
> 
>    * Added couple of fixes from Ladis for  pwm-dmtimer.
> 
> Changes from v4:
> 
>    * Made OMAP_DM_TIMER config option silent.
>    * Changed the driver name to timer-dm.c
> 
> Changes from v3:
> 
>    * Reverted to v2 approach of using dev_get_platdata to fetch dmtimer ops.
> 
> Changes from V2:
> 
>    * Wrapped the inline functions in header file under OMAP2PLUS
>    * Added a new of helper function to fetch plat_data from of node.
> 
> Keerthy (8):
>    clocksource: dmtimer: Remove all the exports
>    arm: omap: timer: Wrap the inline functions under OMAP2PLUS define
>    arm: omap: Move dmtimer.h out of plat-omap
>    arm: OMAP: Move dmtimer driver out of plat-omap to drivers under
>      clocksource
>    dmtimer: Add timer ops to the platform data structure
>    clocksource: dmtimer: Populate the timer ops to the pdata
>    pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
>    arm: omap: pdata-quirks: Remove unused timer pdata
> 
> Ladislav Michl (2):
>    clocksource: timer-dm: Hook device platform data if not already
>      assigned
>    clocksource: timer-dm: Check prescaler value
> 
>   arch/arm/mach-omap1/pm.c                           |  2 +-
>   arch/arm/mach-omap1/timer.c                        |  2 +-
>   arch/arm/mach-omap2/omap_hwmod_2420_data.c         |  2 +-
>   arch/arm/mach-omap2/omap_hwmod_2430_data.c         |  2 +-
>   arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  2 +-
>   arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |  2 +-
>   arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |  2 +-
>   arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |  2 +-
>   arch/arm/mach-omap2/omap_hwmod_7xx_data.c          |  2 +-
>   arch/arm/mach-omap2/omap_hwmod_81xx_data.c         |  2 +-
>   arch/arm/mach-omap2/pdata-quirks.c                 | 32 -----------
>   arch/arm/mach-omap2/timer.c                        |  2 +-
>   arch/arm/plat-omap/Kconfig                         |  6 --
>   arch/arm/plat-omap/Makefile                        |  1 -
>   drivers/clocksource/Kconfig                        |  3 +
>   drivers/clocksource/Makefile                       |  1 +
>   .../dmtimer.c => drivers/clocksource/timer-dm.c    | 67 +++++++++++-----------
>   drivers/pwm/pwm-omap-dmtimer.c                     | 39 +++++++------
>   .../include/plat => include/clocksource}/dmtimer.h |  8 ++-
>   include/linux/platform_data/dmtimer-omap.h         | 38 ++++++++++++
>   20 files changed, 117 insertions(+), 100 deletions(-)
>   rename arch/arm/plat-omap/dmtimer.c => drivers/clocksource/timer-dm.c (94%)
>   rename {arch/arm/plat-omap/include/plat => include/clocksource}/dmtimer.h (97%)
> 

^ permalink raw reply

* [PATCH 6/7] arm64: allwinner: h6: add the basical Allwinner H6 DTSI file
From: Philippe Ombredanne @ 2018-01-07 16:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180106050910.48070-1-icenowy@aosc.io>

On Sat, Jan 6, 2018 at 6:09 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> Allwinner H6 is a new SoC with Cortex-A53 cores from Allwinner, with its
> memory map fully reworked and some high-speed peripherals (PCIe, USB
> 3.0) introduced.
>
> This commit adds the basical DTSI file of it, including the clock
> support and UART support.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 214 +++++++++++++++++++++++++++
>  1 file changed, 214 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> new file mode 100644
> index 000000000000..482f5cb64d07
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -0,0 +1,214 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */

Icenowy,
This is a very long legalese indeed!
Do you mind using the new concise SPDX tags instead here and in the
rest of your patch?
See Thomas doc [1]
Thanks!

[1] https://lkml.org/lkml/2017/12/28/323
-- 
Cordially
Philippe Ombredanne

^ permalink raw reply

* [PATCH v2 1/2] mtd: spi-nor: cadence-quadspi: Refactor indirect read/write sequence.
From: Cyrille Pitchen @ 2018-01-07 18:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171229091103.14436-2-vigneshr@ti.com>

Le 29/12/2017 ? 10:11, Vignesh R a ?crit?:
> Move configuring of indirect read/write start address to
> cqspi_indirect_*_execute() function and rename cqspi_indirect_*_setup()
> function. This will help to reuse cqspi_indirect_*_setup() function for
> supporting direct access mode.
> 
> Signed-off-by: Vignesh R <vigneshr@ti.com>

Applied to the spi-nor/next branch of linux-mtd after removing the one
too many empty line in cqspi_read_setup() (see below).

Thanks!

> ---
> 
> v2: No changes.
> 
>  drivers/mtd/spi-nor/cadence-quadspi.c | 27 ++++++++++++---------------
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
> index 75a2bc447a99..becc7d714ab8 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -450,8 +450,7 @@ static int cqspi_command_write_addr(struct spi_nor *nor,
>  	return cqspi_exec_flash_cmd(cqspi, reg);
>  }
>  
> -static int cqspi_indirect_read_setup(struct spi_nor *nor,
> -				     const unsigned int from_addr)
> +static int cqspi_read_setup(struct spi_nor *nor)
>  {
>  	struct cqspi_flash_pdata *f_pdata = nor->priv;
>  	struct cqspi_st *cqspi = f_pdata->cqspi;
> @@ -459,7 +458,6 @@ static int cqspi_indirect_read_setup(struct spi_nor *nor,
>  	unsigned int dummy_clk = 0;
>  	unsigned int reg;
>  
> -	writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
> 

removed the above empty line ;)
 
>  	reg = nor->read_opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB;
>  	reg |= cqspi_calc_rdreg(nor, nor->read_opcode);
> @@ -493,8 +491,8 @@ static int cqspi_indirect_read_setup(struct spi_nor *nor,
>  	return 0;
>  }
>  
> -static int cqspi_indirect_read_execute(struct spi_nor *nor,
> -				       u8 *rxbuf, const unsigned n_rx)
> +static int cqspi_indirect_read_execute(struct spi_nor *nor, u8 *rxbuf,
> +				       loff_t from_addr, const size_t n_rx)
>  {
>  	struct cqspi_flash_pdata *f_pdata = nor->priv;
>  	struct cqspi_st *cqspi = f_pdata->cqspi;
> @@ -504,6 +502,7 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor,
>  	unsigned int bytes_to_read = 0;
>  	int ret = 0;
>  
> +	writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
>  	writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES);
>  
>  	/* Clear all interrupts. */
> @@ -570,8 +569,7 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor,
>  	return ret;
>  }
>  
> -static int cqspi_indirect_write_setup(struct spi_nor *nor,
> -				      const unsigned int to_addr)
> +static int cqspi_write_setup(struct spi_nor *nor)
>  {
>  	unsigned int reg;
>  	struct cqspi_flash_pdata *f_pdata = nor->priv;
> @@ -584,8 +582,6 @@ static int cqspi_indirect_write_setup(struct spi_nor *nor,
>  	reg = cqspi_calc_rdreg(nor, nor->program_opcode);
>  	writel(reg, reg_base + CQSPI_REG_RD_INSTR);
>  
> -	writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR);
> -
>  	reg = readl(reg_base + CQSPI_REG_SIZE);
>  	reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
>  	reg |= (nor->addr_width - 1);
> @@ -593,8 +589,8 @@ static int cqspi_indirect_write_setup(struct spi_nor *nor,
>  	return 0;
>  }
>  
> -static int cqspi_indirect_write_execute(struct spi_nor *nor,
> -					const u8 *txbuf, const unsigned n_tx)
> +static int cqspi_indirect_write_execute(struct spi_nor *nor, loff_t to_addr,
> +					const u8 *txbuf, const size_t n_tx)
>  {
>  	const unsigned int page_size = nor->page_size;
>  	struct cqspi_flash_pdata *f_pdata = nor->priv;
> @@ -604,6 +600,7 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor,
>  	unsigned int write_bytes;
>  	int ret;
>  
> +	writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR);
>  	writel(remaining, reg_base + CQSPI_REG_INDIRECTWRBYTES);
>  
>  	/* Clear all interrupts. */
> @@ -900,11 +897,11 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
>  	if (ret)
>  		return ret;
>  
> -	ret = cqspi_indirect_write_setup(nor, to);
> +	ret = cqspi_write_setup(nor);
>  	if (ret)
>  		return ret;
>  
> -	ret = cqspi_indirect_write_execute(nor, buf, len);
> +	ret = cqspi_indirect_write_execute(nor, to, buf, len);
>  	if (ret)
>  		return ret;
>  
> @@ -920,11 +917,11 @@ static ssize_t cqspi_read(struct spi_nor *nor, loff_t from,
>  	if (ret)
>  		return ret;
>  
> -	ret = cqspi_indirect_read_setup(nor, from);
> +	ret = cqspi_read_setup(nor);
>  	if (ret)
>  		return ret;
>  
> -	ret = cqspi_indirect_read_execute(nor, buf, len);
> +	ret = cqspi_indirect_read_execute(nor, buf, from, len);
>  	if (ret)
>  		return ret;
>  
> 

^ permalink raw reply

* [PATCH v2 2/2] mtd: spi-nor: cadence-quadspi: Add support for direct access mode
From: Cyrille Pitchen @ 2018-01-07 18:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171229091103.14436-3-vigneshr@ti.com>

Le 29/12/2017 ? 10:11, Vignesh R a ?crit?:
> Cadence QSPI controller provides direct access mode through which flash
> can be accessed in a memory-mapped IO mode. This enables read/write to
> flash using memcpy*() functions. This mode provides higher throughput
> for both read/write operations when compared to current indirect mode of
> operation.
> 
> This patch therefore adds support to use QSPI in direct mode. If the
> window reserved in SoC's memory map for MMIO access is less that of
> flash size(like on most SoCFPGA variants), then the driver falls back
> to indirect mode of operation.
> 
> On TI's 66AK2G SoC, with ARM running at 600MHz and QSPI at 96MHz
> switching to direct mode improves read throughput from 3MB/s to 8MB/s.
> 
> Signed-off-by: Vignesh R <vigneshr@ti.com>

Applied to the spi-nor/next branch of linux-mtd

Thanks!

> ---
> 
> v2: enable direct access controller during controller init.
> 
>  drivers/mtd/spi-nor/cadence-quadspi.c | 31 +++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
> index becc7d714ab8..f693a57ebbd6 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -58,6 +58,7 @@ struct cqspi_flash_pdata {
>  	u8		data_width;
>  	u8		cs;
>  	bool		registered;
> +	bool		use_direct_mode;
>  };
>  
>  struct cqspi_st {
> @@ -68,6 +69,7 @@ struct cqspi_st {
>  
>  	void __iomem		*iobase;
>  	void __iomem		*ahb_base;
> +	resource_size_t		ahb_size;
>  	struct completion	transfer_complete;
>  	struct mutex		bus_mutex;
>  
> @@ -103,6 +105,7 @@ struct cqspi_st {
>  /* Register map */
>  #define CQSPI_REG_CONFIG			0x00
>  #define CQSPI_REG_CONFIG_ENABLE_MASK		BIT(0)
> +#define CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL	BIT(7)
>  #define CQSPI_REG_CONFIG_DECODE_MASK		BIT(9)
>  #define CQSPI_REG_CONFIG_CHIPSELECT_LSB		10
>  #define CQSPI_REG_CONFIG_DMA_MASK		BIT(15)
> @@ -891,6 +894,8 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read)
>  static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
>  			   size_t len, const u_char *buf)
>  {
> +	struct cqspi_flash_pdata *f_pdata = nor->priv;
> +	struct cqspi_st *cqspi = f_pdata->cqspi;
>  	int ret;
>  
>  	ret = cqspi_set_protocol(nor, 0);
> @@ -901,7 +906,10 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
>  	if (ret)
>  		return ret;
>  
> -	ret = cqspi_indirect_write_execute(nor, to, buf, len);
> +	if (f_pdata->use_direct_mode)
> +		memcpy_toio(cqspi->ahb_base + to, buf, len);
> +	else
> +		ret = cqspi_indirect_write_execute(nor, to, buf, len);
>  	if (ret)
>  		return ret;
>  
> @@ -911,6 +919,8 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
>  static ssize_t cqspi_read(struct spi_nor *nor, loff_t from,
>  			  size_t len, u_char *buf)
>  {
> +	struct cqspi_flash_pdata *f_pdata = nor->priv;
> +	struct cqspi_st *cqspi = f_pdata->cqspi;
>  	int ret;
>  
>  	ret = cqspi_set_protocol(nor, 1);
> @@ -921,7 +931,10 @@ static ssize_t cqspi_read(struct spi_nor *nor, loff_t from,
>  	if (ret)
>  		return ret;
>  
> -	ret = cqspi_indirect_read_execute(nor, buf, from, len);
> +	if (f_pdata->use_direct_mode)
> +		memcpy_fromio(buf, cqspi->ahb_base + from, len);
> +	else
> +		ret = cqspi_indirect_read_execute(nor, buf, from, len);
>  	if (ret)
>  		return ret;
>  
> @@ -1056,6 +1069,8 @@ static int cqspi_of_get_pdata(struct platform_device *pdev)
>  
>  static void cqspi_controller_init(struct cqspi_st *cqspi)
>  {
> +	u32 reg;
> +
>  	cqspi_controller_enable(cqspi, 0);
>  
>  	/* Configure the remap address register, no remap */
> @@ -1078,6 +1093,11 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
>  	writel(cqspi->fifo_depth * cqspi->fifo_width / 8,
>  	       cqspi->iobase + CQSPI_REG_INDIRECTWRWATERMARK);
>  
> +	/* Enable Direct Access Controller */
> +	reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
> +	reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
> +	writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
> +
>  	cqspi_controller_enable(cqspi, 1);
>  }
>  
> @@ -1153,6 +1173,12 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
>  			goto err;
>  
>  		f_pdata->registered = true;
> +
> +		if (mtd->size <= cqspi->ahb_size) {
> +			f_pdata->use_direct_mode = true;
> +			dev_dbg(nor->dev, "using direct mode for %s\n",
> +				mtd->name);
> +		}
>  	}
>  
>  	return 0;
> @@ -1212,6 +1238,7 @@ static int cqspi_probe(struct platform_device *pdev)
>  		dev_err(dev, "Cannot remap AHB address.\n");
>  		return PTR_ERR(cqspi->ahb_base);
>  	}
> +	cqspi->ahb_size = resource_size(res_ahb);
>  
>  	init_completion(&cqspi->transfer_complete);
>  
> 

^ permalink raw reply

* [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT
From: Daniel Lezcano @ 2018-01-07 18:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180105143006.5369-4-alexandre.belloni@free-electrons.com>

On 05/01/2018 15:30, Alexandre Belloni wrote:
> With the new TCB clocksource driver, atmel platforms are now able to boot
> without the PIT driver. Allow unselecting it.
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>  drivers/clocksource/Kconfig | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 5609572e0236..55ccfa0ba63b 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -381,7 +381,14 @@ config ARMV7M_SYSTICK
>  
>  config ATMEL_PIT
>  	select TIMER_OF if OF
> -	def_bool SOC_AT91SAM9 || SOC_SAMA5
> +	bool "Atmel Periodic Interval Timer (PIT)"
> +	depends on SOC_AT91SAM9 || SOC_SAMA5
> +	default SOC_AT91SAM9 || SOC_SAMA5
> +	help
> +	  Select this to get a clocksource based on the Atmel Periodic Interval
> +	  Timer. It has a relatively low resolution and the TC Block clocksource
> +	  should be preferred.
> +	  It also provides a clock event device.

Please conform to the format:

config ATMEL_PIT
	bool "Atmel Periodic Interval Timer (PIT)" if COMPILE_TEST
	select ...
	help
	    bla bla

and select ATMEL_PIT from the platform's Kconfig.


>  config ATMEL_ST
>  	bool "Atmel ST timer support" if COMPILE_TEST
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

^ permalink raw reply

* [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT
From: Alexandre Belloni @ 2018-01-07 18:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <64398ab7-fbc6-0313-ccc6-51ff02d087e6@linaro.org>

On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote:
> On 05/01/2018 15:30, Alexandre Belloni wrote:
> > With the new TCB clocksource driver, atmel platforms are now able to boot
> > without the PIT driver. Allow unselecting it.
> > 
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > ---
> >  drivers/clocksource/Kconfig | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index 5609572e0236..55ccfa0ba63b 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -381,7 +381,14 @@ config ARMV7M_SYSTICK
> >  
> >  config ATMEL_PIT
> >  	select TIMER_OF if OF
> > -	def_bool SOC_AT91SAM9 || SOC_SAMA5
> > +	bool "Atmel Periodic Interval Timer (PIT)"
> > +	depends on SOC_AT91SAM9 || SOC_SAMA5
> > +	default SOC_AT91SAM9 || SOC_SAMA5
> > +	help
> > +	  Select this to get a clocksource based on the Atmel Periodic Interval
> > +	  Timer. It has a relatively low resolution and the TC Block clocksource
> > +	  should be preferred.
> > +	  It also provides a clock event device.
> 
> Please conform to the format:
> 
> config ATMEL_PIT
> 	bool "Atmel Periodic Interval Timer (PIT)" if COMPILE_TEST
> 	select ...
> 	help
> 	    bla bla
> 
> and select ATMEL_PIT from the platform's Kconfig.
> 

Well, the goal is actually to allow people to unselect it so we don't
want the platform to select it.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [arm-platforms:kvm-arm64/haslr 17/22] arch/arm/kvm/../../../virt/kvm/arm/mmu.c:754:33: error: 'VA_BITS' undeclared; did you mean 'NMI_BITS'?
From: kbuild test robot @ 2018-01-07 19:03 UTC (permalink / raw)
  To: linux-arm-kernel

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/haslr
head:   b6f07d796000cff9e69657e2369c1adbad6a72a2
commit: 326f33852915935d41ade2e8f55fbed2cdfaabe3 [17/22] KVM: arm/arm64: Move HYP IO VAs to the "idmap" range
config: arm-axm55xx_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout 326f33852915935d41ade2e8f55fbed2cdfaabe3
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from include/linux/kernel.h:11:0,
                    from include/asm-generic/bug.h:18,
                    from arch/arm/include/asm/bug.h:60,
                    from include/linux/bug.h:5,
                    from include/linux/mmdebug.h:5,
                    from include/linux/mm.h:9,
                    from include/linux/mman.h:5,
                    from arch/arm/kvm/../../../virt/kvm/arm/mmu.c:19:
   arch/arm/kvm/../../../virt/kvm/arm/mmu.c: In function 'create_hyp_io_mappings':
>> arch/arm/kvm/../../../virt/kvm/arm/mmu.c:754:33: error: 'VA_BITS' undeclared (first use in this function); did you mean 'NMI_BITS'?
     if ((base ^ io_map_base) & BIT(VA_BITS - 1)) {
                                    ^
   include/linux/bitops.h:7:28: note: in definition of macro 'BIT'
    #define BIT(nr)   (1UL << (nr))
                               ^~
   arch/arm/kvm/../../../virt/kvm/arm/mmu.c:754:33: note: each undeclared identifier is reported only once for each function it appears in
     if ((base ^ io_map_base) & BIT(VA_BITS - 1)) {
                                    ^
   include/linux/bitops.h:7:28: note: in definition of macro 'BIT'
    #define BIT(nr)   (1UL << (nr))
                               ^~

vim +754 arch/arm/kvm/../../../virt/kvm/arm/mmu.c

   717	
   718	/**
   719	 * create_hyp_io_mappings - Map IO into both kernel and HYP
   720	 * @phys_addr:	The physical start address which gets mapped
   721	 * @size:	Size of the region being mapped
   722	 * @kaddr:	Kernel VA for this mapping
   723	 * @haddr:	HYP VA for this mapping
   724	 *
   725	 * The resulting HYP VA is completely unrelated to the kernel VA.
   726	 */
   727	int create_hyp_io_mappings(phys_addr_t phys_addr, size_t size,
   728				   void __iomem **kaddr,
   729				   void __iomem **haddr)
   730	{
   731		pgd_t *pgd = hyp_pgd;
   732		unsigned long base;
   733		int ret;
   734	
   735		*kaddr = ioremap(phys_addr, size);
   736		if (!*kaddr)
   737			return -ENOMEM;
   738	
   739		if (is_kernel_in_hyp_mode()) {
   740			*haddr = *kaddr;
   741			return 0;
   742		}
   743	
   744		mutex_lock(&io_map_lock);
   745	
   746		base = io_map_base - size;
   747		base &= ~(size - 1);
   748	
   749		/*
   750		 * Verify that BIT(VA_BITS - 1) hasn't been flipped by
   751		 * allocating the new area, as it would indicate we've
   752		 * overflowed the idmap/IO address range.
   753		 */
 > 754		if ((base ^ io_map_base) & BIT(VA_BITS - 1)) {
   755			ret = -ENOMEM;
   756			goto out;
   757		}
   758	
   759		if (__kvm_cpu_uses_extended_idmap())
   760			pgd = boot_hyp_pgd;
   761	
   762		ret = __create_hyp_mappings(pgd, base, base + size,
   763					     __phys_to_pfn(phys_addr), PAGE_HYP_DEVICE);
   764	
   765		if (!ret) {
   766			*haddr = (void __iomem *)base;
   767			io_map_base = base;
   768		}
   769	
   770	out:
   771		mutex_unlock(&io_map_lock);
   772	
   773		if (ret) {
   774			iounmap(*kaddr);
   775			*kaddr = NULL;
   776		}
   777	
   778		return ret;
   779	}
   780	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 20369 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180108/25c1278e/attachment-0001.gz>

^ permalink raw reply

* [PATCH v6 10/10] clocksource: timer-dm: Check prescaler value
From: Ladislav Michl @ 2018-01-07 19:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <f743a25e-d29e-8693-f2c6-87d2f648d613@ti.com>

On Sun, Jan 07, 2018 at 09:26:44PM +0530, Keerthy wrote:
> On 1/5/2018 4:17 AM, Ladislav Michl wrote:
> > On Tue, Jan 02, 2018 at 03:39:59PM +0530, Keerthy wrote:
> > > From: Ladislav Michl <ladis@linux-mips.org>
> > > 
> > > Invalid prescaler value is silently ignored. Fix that
> > > by returning -EINVAL in such case. As invalid value
> > > disabled use of the prescaler, use -1 explicitely for
> > > that purpose.
> > > 
> > > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > > ---
> > >   drivers/clocksource/timer-dm.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
> > > index 60db173..01a9cb0 100644
> > > --- a/drivers/clocksource/timer-dm.c
> > > +++ b/drivers/clocksource/timer-dm.c
> > > @@ -672,6 +672,9 @@ int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler)
> > >   	if (prescaler >= 0x00 && prescaler <= 0x07) {
> > >   		l |= OMAP_TIMER_CTRL_PRE;
> > >   		l |= prescaler << 2;
> > > +	} else {
> > > +		if (prescaler != -1)
> > > +			return -EINVAL;
> > 
> > Argh... This is actually wrong, as it leaves timer enabled.
> > I suggest simply dropping this patch and I'll rethink whole
> > approach a bit later (and better).
> 
> Okay. I hope the rest 9 patches work well for you.

Yes. I rebased event capture patches on top of this serie (based on
linux-next) and will post them during next week for review. Fixed
patch will be included (note, it is not really needed for your serie
as noone is calling this function).

> > 
> > >   	}
> > >   	omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
> > 
> > Sorry for the noise,
> > 	ladis
> > 

^ permalink raw reply

* [PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Martin Blumenstingl @ 2018-01-07 20:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-4-yixun.lan@amlogic.com>

Hi Yixun,

On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan <yixun.lan@amlogic.com> wrote:
> Describe the pinctrl info for the UART controller which is found
> in the Meson-AXG SoCs.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 97 ++++++++++++++++++++++++++++++
>  1 file changed, 97 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 644d0f9eaf8c..1eb45781c850 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -448,6 +448,70 @@
>                                                 function = "spi1";
>                                         };
>                                 };
> +
> +                               uart_a_pins: uart_a {
> +                                       mux {
> +                                               groups = "uart_tx_a",
> +                                                       "uart_rx_a";
> +                                               function = "uart_a";
> +                                       };
> +                               };
> +
> +                               uart_a_cts_rts_pins: uart_a_cts_rts {
> +                                       mux {
> +                                               groups = "uart_cts_a",
> +                                                       "uart_rts_a";
> +                                               function = "uart_a";
> +                                       };
> +                               };
> +
> +                               uart_b_x_pins: uart_b_x {
> +                                       mux {
> +                                               groups = "uart_tx_b_x",
> +                                                       "uart_rx_b_x";
> +                                               function = "uart_b";
> +                                       };
> +                               };
> +
> +                               uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
> +                                       mux {
> +                                               groups = "uart_cts_b_x",
> +                                                       "uart_rts_b_x";
> +                                               function = "uart_b";
> +                                       };
> +                               };
> +
> +                               uart_b_z_pins: uart_b_z {
> +                                       mux {
> +                                               groups = "uart_tx_b_z",
> +                                                       "uart_rx_b_z";
> +                                               function = "uart_b";
> +                                       };
> +                               };
> +
> +                               uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
> +                                       mux {
> +                                               groups = "uart_cts_b_z",
> +                                                       "uart_rts_b_z";
> +                                               function = "uart_b";
> +                                       };
> +                               };
> +
> +                               uart_ao_b_z_pins: uart_ao_b_z {
> +                                       mux {
> +                                               groups = "uart_ao_tx_b_z",
> +                                                       "uart_ao_rx_b_z";
> +                                               function = "uart_ao_b_gpioz";
(the following question just came up while I was looking at this
patch, but I guess it's more a question towards the pinctrl driver)
the name of the function looks a bit "weird" since below you are also
using "uart_ao_b"
did you choose "uart_ao_b_gpioz" here because we cannot have the same
function name for the periphs and AO pinctrl or is there some other
reason?

I am asking because I would have expected it to look like this:
    groups = "uart_ao_tx_b_z", "uart_ao_rx_b_z";
    function = "uart_ao_b";

(same for the cts/rts pins below)

> +                                       };
> +                               };
> +
> +                               uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts {
> +                                       mux {
> +                                               groups = "uart_ao_cts_b_z",
> +                                                       "uart_ao_rts_b_z";
> +                                               function = "uart_ao_b_gpioz";
> +                                       };
> +                               };
>                         };
>                 };
>
> @@ -492,12 +556,45 @@
>                                         gpio-ranges = <&pinctrl_aobus 0 0 15>;
>                                 };
>
> +
did you add this additional newline on purpose?
>                                 remote_input_ao_pins: remote_input_ao {
>                                         mux {
>                                                 groups = "remote_input_ao";
>                                                 function = "remote_input_ao";
>                                         };
>                                 };
> +
> +                               uart_ao_a_pins: uart_ao_a {
> +                                       mux {
> +                                               groups = "uart_ao_tx_a",
> +                                                       "uart_ao_rx_a";
> +                                               function = "uart_ao_a";
> +                                       };
> +                               };
> +
> +                               uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
> +                                       mux {
> +                                               groups = "uart_ao_cts_a",
> +                                                       "uart_ao_rts_a";
> +                                               function = "uart_ao_a";
> +                                       };
> +                               };
> +
> +                               uart_ao_b_pins: uart_ao_b {
> +                                       mux {
> +                                               groups = "uart_ao_tx_b",
> +                                                       "uart_ao_rx_b";
> +                                               function = "uart_ao_b";
> +                                       };
> +                               };
> +
> +                               uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
> +                                       mux {
> +                                               groups = "uart_ao_cts_b",
> +                                                       "uart_ao_rts_b";
> +                                               function = "uart_ao_b";
> +                                       };
> +                               };
>                         };
>
>                         pwm_AO_ab: pwm at 7000 {
> --
> 2.15.1
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

Regards
Martin

^ permalink raw reply

* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2018-01-07 20:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103215206.5d85b41b@bbrezillon>

Boris Brezillon <boris.brezillon@free-electrons.com> writes:

> On Wed, 3 Jan 2018 21:10:28 +0100
> Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
>> Hm, that's weird. Can you try with the old driver (pxa3xx)?
Ah you're right, my NAND was damaged ...

> Alternatively, you can type 'nand bad' from uboot to check if it
> detects the same bad blocks.
Mmmh no, the SPL is barebox in my case. Do you have a command in linux or
barebox to do the same thing ?

Cheers.

-- 
Robert

^ permalink raw reply

* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2018-01-07 21:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <874lnxcrsq.fsf@belgarion.home>

Hi Robert,

On Sun, 07 Jan 2018 21:55:33 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:

> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> 
> > On Wed, 3 Jan 2018 21:10:28 +0100
> > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:  
> >> Hm, that's weird. Can you try with the old driver (pxa3xx)?  
> Ah you're right, my NAND was damaged ...
> 
> > Alternatively, you can type 'nand bad' from uboot to check if it
> > detects the same bad blocks.  
> Mmmh no, the SPL is barebox in my case. Do you have a command in
> linux or barebox to do the same thing ?

Not sure, but nand -i should do the trick.
https://www.barebox.org/doc/latest/commands/hwmanip/nand.html

But I am not sure this is still relevant now we know the NAND was
damaged by the previous experiments (sorry about that). Can you put the
NAND in a clean state and report us if it is still failing?

Thanks for your help,
Miqu?l

^ permalink raw reply

* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2018-01-07 21:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180107220911.31844b3a@xps13>

On Sun, 7 Jan 2018 22:09:11 +0100
Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:

> Hi Robert,
> 
> On Sun, 07 Jan 2018 21:55:33 +0100
> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> 
> > Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> >   
> > > On Wed, 3 Jan 2018 21:10:28 +0100
> > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:    
> > >> Hm, that's weird. Can you try with the old driver (pxa3xx)?    
> > Ah you're right, my NAND was damaged ...
> >   
> > > Alternatively, you can type 'nand bad' from uboot to check if it
> > > detects the same bad blocks.    
> > Mmmh no, the SPL is barebox in my case. Do you have a command in
> > linux or barebox to do the same thing ?  
> 
> Not sure, but nand -i should do the trick.
> https://www.barebox.org/doc/latest/commands/hwmanip/nand.html
> 
> But I am not sure this is still relevant now we know the NAND was
> damaged by the previous experiments (sorry about that). Can you put the
> NAND in a clean state and report us if it is still failing?

In order to do that you'll have to scrub the blocks storing the BBT, and
I'm not sure barebox supports that. Linux does not, for sure, so if you
want to forcibly erase bad blocks from linux, you'll have to comment
these lines [1].

[1]http://elixir.free-electrons.com/linux/v4.15-rc6/source/drivers/mtd/nand/nand_base.c#L3056

^ permalink raw reply

* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2018-01-07 21:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180107221911.51115566@bbrezillon>

On Sun, 7 Jan 2018 22:19:11 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

> On Sun, 7 Jan 2018 22:09:11 +0100
> Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:
> 
> > Hi Robert,
> > 
> > On Sun, 07 Jan 2018 21:55:33 +0100
> > Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> >   
> > > Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> > >     
> > > > On Wed, 3 Jan 2018 21:10:28 +0100
> > > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:      
> > > >> Hm, that's weird. Can you try with the old driver (pxa3xx)?      
> > > Ah you're right, my NAND was damaged ...
> > >     
> > > > Alternatively, you can type 'nand bad' from uboot to check if it
> > > > detects the same bad blocks.      
> > > Mmmh no, the SPL is barebox in my case. Do you have a command in
> > > linux or barebox to do the same thing ?    
> > 
> > Not sure, but nand -i should do the trick.
> > https://www.barebox.org/doc/latest/commands/hwmanip/nand.html
> > 
> > But I am not sure this is still relevant now we know the NAND was
> > damaged by the previous experiments (sorry about that). Can you put the
> > NAND in a clean state and report us if it is still failing?  
> 
> In order to do that you'll have to scrub the blocks storing the BBT, and
> I'm not sure barebox supports that. Linux does not, for sure, so if you
> want to forcibly erase bad blocks from linux, you'll have to comment
> these lines [1].

Apparently there's a "nand -g <offs>" command to mark a block good in
barebox. After doing that you should be able to erase the blocks storing
the BBT (it should be placed in the last 2 blocks of the NAND).

> 
> [1]http://elixir.free-electrons.com/linux/v4.15-rc6/source/drivers/mtd/nand/nand_base.c#L3056

^ permalink raw reply

* [PATCH v2 1/5] dt-bindings: mtd: add Marvell NAND controller documentation
From: Miquel RAYNAL @ 2018-01-07 21:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171220210511.ty2e7mkiktvn4een@rob-hp-laptop>

Hi Rob,

On Wed, 20 Dec 2017 15:05:11 -0600
Rob Herring <robh@kernel.org> wrote:

> On Tue, Dec 19, 2017 at 02:29:38PM +0100, Miquel Raynal wrote:
> > Document the legacy and the new bindings for Marvell NAND
> > controller.
> > 
> > The pxa3xx_nand.c driver does only support legacy bindings, which
> > are incomplete and inaccurate. A rework of this controller (called
> > marvell_nand.c) does support both.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
> >  .../devicetree/bindings/mtd/marvell-nand.txt       | 123
> > +++++++++++++++++++++ 1 file changed, 123 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/mtd/marvell-nand.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/marvell-nand.txt
> > b/Documentation/devicetree/bindings/mtd/marvell-nand.txt new file
> > mode 100644 index 000000000000..aa6a1ed045b2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/marvell-nand.txt
> > @@ -0,0 +1,123 @@
> > +Marvell NAND Flash Controller (NFC)
> > +
> > +Required properties:
> > +- compatible: can be one of the following:
> > +    * "marvell,armada-8k-nand-controller"
> > +    * "marvell,armada370-nand-controller"
> > +    * "marvell,pxa3xx-nand-controller"
> > +    * "marvell,armada-8k-nand" (deprecated)
> > +    * "marvell,armada370-nand" (deprecated)
> > +    * "marvell,pxa3xx-nand" (deprecated)
> > +  Compatibles marked deprecated support only the old bindings
> > described
> > +  at the bottom.
> > +- reg: NAND flash controller memory area.
> > +- #address-cells: shall be set to 1. Encode the NAND CS.
> > +- #size-cells: shall be set to 0.
> > +- interrupts: shall define the NAND controller interrupt.
> > +- clocks: shall reference the NAND controller clock.
> > +- marvell,system-controller: Set to retrieve the syscon node that
> > handles
> > +  NAND controller related registers (only required with the
> > +  "marvell,armada-8k-nand[-controller]" compatibles).
> > +
> > +Optional properties:
> > +- label: see partition.txt. New platforms shall omit this property.
> > +- dmas: shall reference DMA channel associated to the NAND
> > controller.
> > +  This property is only used with
> > "marvell,pxa3xx-nand[-controller]"
> > +  compatible strings.
> > +- dma-names: shall be "rxtx".
> > +  This property is only used with
> > "marvell,pxa3xx-nand[-controller]"
> > +  compatible strings.
> > +
> > +Optional children nodes:
> > +Children nodes represent the available NAND chips.
> > +
> > +Required properties:
> > +- reg: shall contain the native Chip Select ids (0-3)
> > +- marvell,rb: shall contain the native Ready/Busy ids (0-1)  
> 
> We already have at least 2 other <vendor>,rb properties. Let's not
> add a 3rd and make a common one instead.

I switched to "nand-rb", added this property in nand.txt (in another
commit) and updated all the DT accordingly.

> 
> > +
> > +Optional properties:
> > +- marvell,nand-keep-config: orders the driver not to take the
> > timings
> > +  from the core and leaving them completely untouched. Bootloader
> > +  timings will then be used.
> > +- label: MTD name.
> > +- nand-on-flash-bbt: see nand.txt.
> > +- nand-ecc-mode: see nand.txt. Will use hardware ECC if not
> > specified. +- nand-ecc-algo: see nand.txt. This property may be
> > added when using
> > +  hardware ECC for clarification but will be ignored by the driver
> > +  because ECC mode is chosen depending on the page size and the
> > strength
> > +  required by the NAND chip. This value may be overwritten with
> > +  nand-ecc-strength property.  
> 
> If not used, then drop it.

Well, nand-ecc-algo will be useful when not using the ECC
engine, so it cannot be removed. I tried to explain better the
situation.

> 
> > +- nand-ecc-strength: see nand.txt.
> > +- nand-ecc-step-size: see nand.txt. This has no effect and will be
> > +  ignored by the driver when using hardware ECC because Marvell's
> > NAND
> > +  flash controller does use fixed strength (1-bit for Hamming,
> > 16-bit
> > +  for BCH), so the step size will shrink or grow in order to fit
> > the
> > +  required strength. Step sizes are not completely random for all
> > and
> > +  follow certain patterns described in AN-379, "Marvell SoC NFC
> > ECC".  
> 
> Same here.

The comment about being ignored was not accurate, I simply removed
that part.

Thanks,
Miqu?l

^ permalink raw reply

* [PATCH v2 2/5] mtd: nand: add reworked Marvell NAND controller driver
From: Miquel RAYNAL @ 2018-01-07 21:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171221111428.0aa3e65e@bbrezillon>

Hi Boris,

On Thu, 21 Dec 2017 11:14:28 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

> Hi Miquel,
> 
> On Tue, 19 Dec 2017 14:29:39 +0100
> Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> 
> > Add marvell_nand driver which aims at replacing the existing
> > pxa3xx_nand driver.
> > 
> > The new driver intends to be easier to understand and follows the
> > brand new NAND framework rules by implementing hooks for every
> > pattern the controller might support and referencing them inside a
> > parser object that will be given to the core at each ->exec_op()
> > call.
> > 
> > Raw accessors are implemented, useful to test/debug
> > memory/filesystem corruptions. Userspace binaries contained in the
> > mtd-utils package may now be used and their output trusted.
> > 
> > Timings may not be kept from the bootloader anymore, the timings
> > used for instance in U-Boot were not optimal and it supposed to
> > have NAND support (and initialized) in the bootloader.  
> 
> Hm, AFAIR the old driver was able to dynamically adjust the timings
> when the NAND was ONFI compliant.
> 
> > 
> > Thanks to the improved timings, implementation of ONFI mode 5
> > support (with EDO managed by adding a delay on data sampling),
> > merging the commands together and optimizing writes in the command
> > registers, the new driver may achieve faster throughputs in both
> > directions. Measurements show an improvement of about +23% read
> > throughput and +24% write throughput. These measurements have been
> > done with an Armada-385-DB-AP (4kiB NAND pages forced in 4-bit
> > strength BCH ECC correction) using the userspace tool 'flash_speed'
> > from the MTD test suite.
> > 
> > Besides these important topics, the new driver addresses several
> > unsolved known issues in the old driver which:
> > - did not work with ECC soft neither with ECC none ;
> > - relied on naked read/write (which is unchanged) while the NFCv1
> >   embedded in the pxa3xx platforms do not implement it, so several
> >   NAND commands did not actually ever work without any notice (like
> >   reading the ONFI PARAM_PAGE or SET/GET_FEATURES) ;
> > - wrote the OOB data correctly, but was not able to read it
> > correctly past the first OOB data chunk ;
> > - did not displayed ECC bytes ;  
> 
> 	    ^display
> 
> and I'm not even sure display is the right term here. How about
> 'retrieve'.
> 
> > - used device tree bindings that did not allow more than one NAND
> > chip, and did not allow to choose the correct chip select if not
> >   incrementing from 0. Plus, the Ready/Busy line used had to be 0.
> > 
> > Old device tree bindings are still supported but deprecated. A more
> > hierarchical view has to be used to keep the controller and the NAND
> > chip structures clearly separated both inside the device tree and
> > also in the driver code.
> > 
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > Tested-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
> > Tested-by: Willy Tarreau <w@1wt.eu>
> > ---


I made all the changes you requested, let me the time to do further
tests and I will send a v3.

Thanks,
Miqu?l

^ permalink raw reply

* [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
From: Eric Anholt @ 2018-01-07 22:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515332212-23593-1-git-send-email-stefan.wahren@i2se.com>

Stefan Wahren <stefan.wahren@i2se.com> writes:

> This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.
>
> The DT clean up could trigger an endless deferred probe of DWC2 USB driver
> on the Raspberry Pi 2/3. So revert the change until we fixed the probing
> issue.

Why's that?  I found that I needed to enable the generic no-op phy
driver, but other than that it was fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180107/0a765b0b/attachment.sig>

^ permalink raw reply

* [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul
From: Rafael J. Wysocki @ 2018-01-07 23:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <AM3PR04MB131556AF9BDE24E071A51300F51D0@AM3PR04MB1315.eurprd04.prod.outlook.com>

On Saturday, January 6, 2018 4:05:41 AM CET Anson Huang wrote:
> Hi, Rafael
> 
> Best Regards!
> Anson Huang
> 
> 
> > -----Original Message-----
> > From: rjwysocki at gmail.com [mailto:rjwysocki at gmail.com] On Behalf Of Rafael
> > J. Wysocki
> > Sent: 2018-01-05 8:21 PM
> > To: Anson Huang <anson.huang@nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; Linux
> > PM <linux-pm@vger.kernel.org>; Linux Kernel Mailing List <linux-
> > kernel at vger.kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> > <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> > Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> > Russell King - ARM Linux <linux@armlinux.org.uk>; Rafael J. Wysocki
> > <rjw@rjwysocki.net>; Viresh Kumar <viresh.kumar@linaro.org>; Jacky Bai
> > <ping.bai@nxp.com>; A.s. Dong <aisheng.dong@nxp.com>
> > Subject: Re: [PATCH 2/2] cpufreq: imx6q: add 696MHz operating point for
> > i.mx6ul
> > 
> > On Tue, Jan 2, 2018 at 6:07 PM, Anson Huang <Anson.Huang@nxp.com> wrote:
> > > Add 696MHz operating point for i.MX6UL, only for those parts with
> > > speed grading fuse set to 2b'10 supports 696MHz operating point, so,
> > > speed grading check is also added for i.MX6UL in this patch, the clock
> > > tree for each operating point are as below:
> > >
> > > 696MHz:
> > >     pll1                       696000000
> > >        pll1_bypass             696000000
> > >           pll1_sys             696000000
> > >              pll1_sw           696000000
> > >                 arm            696000000
> > > 528MHz:
> > >     pll2                       528000000
> > >        pll2_bypass             528000000
> > >           pll2_bus             528000000
> > >              ca7_secondary_sel 528000000
> > >                 step           528000000
> > >                    pll1_sw     528000000
> > >                       arm      528000000
> > > 396MHz:
> > >     pll2_pfd2_396m             396000000
> > >        ca7_secondary_sel       396000000
> > >           step                 396000000
> > >              pll1_sw           396000000
> > >                 arm            396000000
> > > 198MHz:
> > >     pll2_pfd2_396m             396000000
> > >        ca7_secondary_sel       396000000
> > >           step                 396000000
> > >              pll1_sw           396000000
> > >                 arm            198000000
> > >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > 
> > This doesn't apply for me and in a nontrivial way.
> > 
> > What kernel is it against?
> 
> I did it based on linux-next, it should be on linux-next-pm branch, I redo
> the patch set V2 based on linux-next-pm, also redo the test,
> sorry for the inconvenience.

But you didn't add the Reviewed-by: tags from Fabio to them.

Was that on purpose or by mistake?

Thanks,
Rafael

^ permalink raw reply

* [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks
From: Jon Masters @ 2018-01-08  0:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515157961-20963-8-git-send-email-will.deacon@arm.com>

On 01/05/2018 08:12 AM, Will Deacon wrote:

> Aliasing attacks against CPU branch predictors can allow an attacker to
> redirect speculative control flow on some CPUs and potentially divulge
> information from one context to another.
> 
> This patch adds initial skeleton code behind a new Kconfig option to
> enable implementation-specific mitigations against these attacks for
> CPUs that are affected.

Thanks to Qualcomm for the (typically prompt and immediate) followup. As
a reminder to the other usual server suspects (all of whom we've spoken
with about mitigations for this so we know there things coming), I'm
expecting to see your patches for this hit the list within the next 48
hours. You know who you are, and I'll be doing the rounds over the next
24 hours to check your status as to when you'll be posting these.

Thanks,

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

^ permalink raw reply

* soc: imx: gpcv2: removing and probing fails
From: Andrey Smirnov @ 2018-01-08  0:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <3f836677c6e98aaf01bc1ac8c3410083@agner.ch>

On Sun, Jan 7, 2018 at 2:48 AM, Stefan Agner <stefan@agner.ch> wrote:
> Hi Andrew,
>
> I noticed that the driver fails when removing and probing again. As far
> as I can see due to duplicate add of the platform devices.
>
> As far as I can tell the driver should register the remove callback and
> do a platform_device_unregister on the newly created platform devices.
> However, as far as I can tell we don't hold on to a reference to them...
> I guess we could keep references in imx_gpcv2_probe, but maybe there is
> an easier way?

Stefan:

Good catch and sorry for the inconvenience. I just spent a little bit
of time repro-ing this and it looks like there are two separate bugs,
actually. First one, as you correctly pointed out, is due to
re-registration of pm-domain platform drivers. That, however, should
only result in a WARNING and a failed driver probing, not in a killed
init due to BUG. So the second one, that BUG message in the stack
trace, is due to the fact that I incorrectly provide statically
allocated data via dev.platform_data and it ends up being kfree'd in
platform_device_release().

IMHO, this driver isn't really meant to be removed, so the simplest
solution to the first problem would be to specify
"imx_gpc_driver.driver.suppress_bind_attrs = true" and remove any
option to remove the driver, but I don't know if that's acceptable or
not.

Shawn, would the above be acceptable upstream?

Solution for bug #2 is trivial and I'll send patches for both once we
agree how to fix #1.

Thanks,
Andrey Smirnov

P.S: Also, since I based my code on gpc.c, I suspect that driver will
have exactly the same problem (I'll do some experiments to confirm)

^ permalink raw reply

* [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions
From: Yang, Wenyou @ 2018-01-08  0:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <81cadb76-8c67-9289-1375-2d4a55a4adfa@users.sourceforge.net>



On 2018/1/6 4:55, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 5 Jan 2018 21:45:04 +0100
>
> Omit an extra message for a memory allocation failure in these functions.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---

Acked-by: Wenyou Yang <wenyou.yang@microchip.com>
>   drivers/mtd/nand/atmel/nand-controller.c | 8 ++------
>   1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
> index 90a71a56bc23..a41b999229c9 100644
> --- a/drivers/mtd/nand/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/atmel/nand-controller.c
> @@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
>   		mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
>   					   "%s:nand.%d", dev_name(nc->dev),
>   					   nand->cs[0].id);
> -		if (!mtd->name) {
> -			dev_err(nc->dev, "Failed to allocate mtd->name\n");
> +		if (!mtd->name)
>   			return -ENOMEM;
> -		}
>   	}
>   
>   	ret = nand_scan_tail(mtd);
> @@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
>   	nand = devm_kzalloc(nc->dev,
>   			    sizeof(*nand) + (numcs * sizeof(*nand->cs)),
>   			    GFP_KERNEL);
> -	if (!nand) {
> -		dev_err(nc->dev, "Failed to allocate NAND object\n");
> +	if (!nand)
>   		return ERR_PTR(-ENOMEM);
> -	}
>   
>   	nand->numcs = numcs;
>   

Best Regards,
Wenyou Yang

^ permalink raw reply

* [PATCH] arm: omap2: timer: fix a kmemleak caused in omap_get_timer_dt
From: Qi Hou @ 2018-01-08  1:08 UTC (permalink / raw)
  To: linux-arm-kernel

When more than one GP timers are used as kernel system timers and the
corresponding nodes in device-tree are marked with the same "disabled"
property, then the "attr" field of the property will be initialized
more than once as the property being added to sys file system via
__of_add_property_sysfs().

In __of_add_property_sysfs(), the "name" field of pp->attr.attr is set
directly to the return value of safe_name(), without taking care of
whether it's already a valid pointer to a memory block. If it is, its
old value will always be overwritten by the new one and the memory block
allocated before will a "ghost", then a kmemleak happened.

That the same "disabled" property being added to different nodes of device
tree would cause that kind of kmemleak overhead, at leat once.

To fix it, allocate the property dynamically, and delete static one.

Signed-off-by: Qi Hou <qi.hou@windriver.com>
---
 arch/arm/mach-omap2/timer.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ece09c9..0e6109b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -156,12 +156,6 @@ static struct clock_event_device clockevent_gpt = {
 	.tick_resume		= omap2_gp_timer_shutdown,
 };
 
-static struct property device_disabled = {
-	.name = "status",
-	.length = sizeof("disabled"),
-	.value = "disabled",
-};
-
 static const struct of_device_id omap_timer_match[] __initconst = {
 	{ .compatible = "ti,omap2420-timer", },
 	{ .compatible = "ti,omap3430-timer", },
@@ -203,8 +197,17 @@ static struct device_node * __init omap_get_timer_dt(const struct of_device_id *
 				  of_get_property(np, "ti,timer-secure", NULL)))
 			continue;
 
-		if (!of_device_is_compatible(np, "ti,omap-counter32k"))
-			of_add_property(np, &device_disabled);
+		if (!of_device_is_compatible(np, "ti,omap-counter32k")) {
+			struct property *prop;
+
+			prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+			if (!prop)
+				return -ENOMEM;
+			prop->name = "status";
+			prop->length = sizeof("disabled");
+			prop->value = "disabled";
+			of_add_property(np, prop);
+		}
 		return np;
 	}
 
-- 
2.7.4

^ permalink raw reply related

* [PATCH 2/7] ARM: dts: imx6ul: update i.MX 6UltraLite iomux headers
From: Andy Duan @ 2018-01-08  1:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180105164505.uzv7nu3r6awuyxzu@rob-hp-laptop>

From: Rob Herring <robh@kernel.org> Sent: Saturday, January 06, 2018 12:45 AM
>To: Stefan Agner <stefan@agner.ch>
>Cc: shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
><fabio.estevam@nxp.com>; mark.rutland at arm.com; linux-arm-
>kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-
>kernel at vger.kernel.org; Andy Duan <fugang.duan@nxp.com>
>Subject: Re: [PATCH 2/7] ARM: dts: imx6ul: update i.MX 6UltraLite iomux
>headers
>
>On Tue, Jan 02, 2018 at 05:42:18PM +0100, Stefan Agner wrote:
>> From: Fugang Duan <fugang.duan@nxp.com>
>>
>> Update i.MX 6UltraLite IOMUXC pin defines.
>
>That's obvious reading the diff. The commit message should tell me why.
>They were wrong?
>
Yes, the previous iomux header parts of pin setting were wrong, which was generated by IOMUX tool during SOC bringup.
The updated header correct the wrong pin setting.

>>
>> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>

^ permalink raw reply

* [PATCH v7 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC
From: zhangfei @ 2018-01-08  1:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180106095117.67907-1-liwei213@huawei.com>

Hi, Wei


On 2018?01?06? 17:51, Li Wei wrote:
> This patchset adds driver support for UFS for Hi3660 SoC. It is verified on HiKey960 board.
Usually here should list the change compared with the last change set, 
to make it easier
to reviewer, who may pay more attention to the differences.

For example
v7:xxx //change since v6
v6:xxx // change since v5



> Li Wei (5):
>    scsi: ufs: add Hisilicon ufs driver code
>    dt-bindings: scsi: ufs: add document for hisi-ufs
>    arm64: dts: add ufs dts node
>    arm64: defconfig: enable configs for Hisilicon ufs
>    arm64: defconfig: enable f2fs and squashfs
>
>   Documentation/devicetree/bindings/ufs/ufs-hisi.txt |  43 ++
>   arch/arm64/boot/dts/hisilicon/hi3660.dtsi          |  20 +
>   arch/arm64/configs/defconfig                       |  11 +
>   drivers/scsi/ufs/Kconfig                           |   9 +
>   drivers/scsi/ufs/Makefile                          |   1 +
>   drivers/scsi/ufs/ufs-hisi.c                        | 621 +++++++++++++++++++++
>   drivers/scsi/ufs/ufs-hisi.h                        | 116 ++++
>   7 files changed, 821 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>   create mode 100644 drivers/scsi/ufs/ufs-hisi.c
>   create mode 100644 drivers/scsi/ufs/ufs-hisi.h
>

^ 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