Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v4 3/4] watchdog/aspeed: add support for dual boot
From: Guenter Roeck @ 2019-08-31 15:01 UTC (permalink / raw)
  To: Ivan Mikhaylov
  Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
	Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
	Rob Herring, Joel Stanley, Wim Van Sebroeck, linux-arm-kernel
In-Reply-To: <20190828102402.13155-4-i.mikhaylov@yadro.com>

On Wed, Aug 28, 2019 at 01:24:01PM +0300, Ivan Mikhaylov wrote:
> Set WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION into WDT_CLEAR_TIMEOUT_STATUS
> to clear out boot code source and re-enable access to the primary SPI flash
> chip while booted via wdt2 from the alternate chip.
> 
> AST2400 datasheet says:
> "In the 2nd flash booting mode, all the address mapping to CS0# would be
> re-directed to CS1#. And CS0# is not accessible under this mode. To access
> CS0#, firmware should clear the 2nd boot mode register in the WDT2 status
> register WDT30.bit[1]."
> 
> Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  drivers/watchdog/aspeed_wdt.c | 65 ++++++++++++++++++++++++++++++++++-
>  1 file changed, 64 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index cc71861e033a..125dbd349b00 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -53,6 +53,8 @@ MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
>  #define   WDT_CTRL_ENABLE		BIT(0)
>  #define WDT_TIMEOUT_STATUS	0x10
>  #define   WDT_TIMEOUT_STATUS_BOOT_SECONDARY	BIT(1)
> +#define WDT_CLEAR_TIMEOUT_STATUS	0x14
> +#define   WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION	BIT(0)
>  
>  /*
>   * WDT_RESET_WIDTH controls the characteristics of the external pulse (if
> @@ -165,6 +167,60 @@ static int aspeed_wdt_restart(struct watchdog_device *wdd,
>  	return 0;
>  }
>  
> +/* access_cs0 shows if cs0 is accessible, hence the reverted bit */
> +static ssize_t access_cs0_show(struct device *dev,
> +			       struct device_attribute *attr, char *buf)
> +{
> +	struct aspeed_wdt *wdt = dev_get_drvdata(dev);
> +	u32 status = readl(wdt->base + WDT_TIMEOUT_STATUS);
> +
> +	return sprintf(buf, "%u\n",
> +		      !(status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY));
> +}
> +
> +static ssize_t access_cs0_store(struct device *dev,
> +				struct device_attribute *attr, const char *buf,
> +				size_t size)
> +{
> +	struct aspeed_wdt *wdt = dev_get_drvdata(dev);
> +	unsigned long val;
> +
> +	if (kstrtoul(buf, 10, &val))
> +		return -EINVAL;
> +
> +	if (val)
> +		writel(WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION,
> +		       wdt->base + WDT_CLEAR_TIMEOUT_STATUS);
> +
> +	return size;
> +}
> +
> +/*
> + * This attribute exists only if the system has booted from the alternate
> + * flash with 'alt-boot' option.
> + *
> + * At alternate flash the 'access_cs0' sysfs node provides:
> + *   ast2400: a way to get access to the primary SPI flash chip at CS0
> + *            after booting from the alternate chip at CS1.
> + *   ast2500: a way to restore the normal address mapping from
> + *            (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
> + *
> + * Clearing the boot code selection and timeout counter also resets to the
> + * initial state the chip select line mapping. When the SoC is in normal
> + * mapping state (i.e. booted from CS0), clearing those bits does nothing for
> + * both versions of the SoC. For alternate boot mode (booted from CS1 due to
> + * wdt2 expiration) the behavior differs as described above.
> + *
> + * This option can be used with wdt2 (watchdog1) only.
> + */
> +static DEVICE_ATTR_RW(access_cs0);
> +
> +static struct attribute *bswitch_attrs[] = {
> +	&dev_attr_access_cs0.attr,
> +	NULL
> +};
> +ATTRIBUTE_GROUPS(bswitch);
> +
>  static const struct watchdog_ops aspeed_wdt_ops = {
>  	.start		= aspeed_wdt_start,
>  	.stop		= aspeed_wdt_stop,
> @@ -306,9 +362,16 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
>  	}
>  
>  	status = readl(wdt->base + WDT_TIMEOUT_STATUS);
> -	if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
> +	if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
>  		wdt->wdd.bootstatus = WDIOF_CARDRESET;
>  
> +		if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
> +		    of_device_is_compatible(np, "aspeed,ast2500-wdt"))
> +			wdt->wdd.groups = bswitch_groups;
> +	}
> +
> +	dev_set_drvdata(dev, wdt);
> +
>  	return devm_watchdog_register_device(dev, &wdt->wdd);
>  }
>  

_______________________________________________
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 v4 4/4] aspeed/watchdog: Add access_cs0 option for alt-boot
From: Guenter Roeck @ 2019-08-31 15:01 UTC (permalink / raw)
  To: Ivan Mikhaylov
  Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
	Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
	Rob Herring, Joel Stanley, Wim Van Sebroeck, linux-arm-kernel
In-Reply-To: <20190828102402.13155-5-i.mikhaylov@yadro.com>

On Wed, Aug 28, 2019 at 01:24:02PM +0300, Ivan Mikhaylov wrote:
> The option for the ast2400/2500 to get access to CS0 at runtime.
> 
> Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  .../ABI/testing/sysfs-class-watchdog          | 34 +++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-watchdog b/Documentation/ABI/testing/sysfs-class-watchdog
> index 6317ade5ad19..675f9b537661 100644
> --- a/Documentation/ABI/testing/sysfs-class-watchdog
> +++ b/Documentation/ABI/testing/sysfs-class-watchdog
> @@ -72,3 +72,37 @@ Description:
>  		It is a read/write file. When read, the currently assigned
>  		pretimeout governor is returned.  When written, it sets
>  		the pretimeout governor.
> +
> +What:		/sys/class/watchdog/watchdog1/access_cs0
> +Date:		August 2019
> +Contact:	Ivan Mikhaylov <i.mikhaylov@yadro.com>,
> +		Alexander Amelkin <a.amelkin@yadro.com>
> +Description:
> +		It is a read/write file. This attribute exists only if the
> +		system has booted from the alternate flash chip due to
> +		expiration of a watchdog timer of AST2400/AST2500 when
> +		alternate boot function was enabled with 'aspeed,alt-boot'
> +		devicetree option for that watchdog or with an appropriate
> +		h/w strapping (for WDT2 only).
> +
> +		At alternate flash the 'access_cs0' sysfs node provides:
> +			ast2400: a way to get access to the primary SPI flash
> +				chip at CS0 after booting from the alternate
> +				chip at CS1.
> +			ast2500: a way to restore the normal address mapping
> +				from (CS0->CS1, CS1->CS0) to (CS0->CS0,
> +				CS1->CS1).
> +
> +		Clearing the boot code selection and timeout counter also
> +		resets to the initial state the chip select line mapping. When
> +		the SoC is in normal mapping state (i.e. booted from CS0),
> +		clearing those bits does nothing for both versions of the SoC.
> +		For alternate boot mode (booted from CS1 due to wdt2
> +		expiration) the behavior differs as described above.
> +
> +		This option can be used with wdt2 (watchdog1) only.
> +
> +		When read, the current status of the boot code selection is
> +		shown. When written with any non-zero value, it clears
> +		the boot code selection and the timeout counter, which results
> +		in chipselect reset for AST2400/AST2500.

_______________________________________________
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 8/9] mips: numa: check the node id consistently for mips ip27
From: Paul Burton @ 2019-08-31 15:45 UTC (permalink / raw)
  To: Yunsheng Lin
  Cc: dalias@libc.org, linux-sh@vger.kernel.org, peterz@infradead.org,
	catalin.marinas@arm.com, dave.hansen@linux.intel.com,
	heiko.carstens@de.ibm.com, linuxarm@huawei.com,
	jiaxun.yang@flygoat.com, linux-mips@vger.kernel.org,
	mwb@linux.vnet.ibm.com, paulus@samba.org, hpa@zytor.com,
	sparclinux@vger.kernel.org, chenhc@lemote.com, will@kernel.org,
	cai@lca.pw, linux-s390@vger.kernel.org,
	ysato@users.sourceforge.jp, mpe@ellerman.id.au, x86@kernel.org,
	rppt@linux.ibm.com, borntraeger@de.ibm.com, dledford@redhat.com,
	mingo@redhat.com, jeffrey.t.kirsher@intel.com,
	benh@kernel.crashing.org, jhogan@kernel.org,
	nfont@linux.vnet.ibm.com, mattst88@gmail.com, len.brown@intel.com,
	gor@linux.ibm.com, anshuman.khandual@arm.com, bp@alien8.de,
	luto@kernel.org, tglx@linutronix.de,
	naveen.n.rao@linux.vnet.ibm.com,
	linux-arm-kernel@lists.infradead.org, rth@twiddle.net,
	axboe@kernel.dk, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	tbogendoerfer@suse.de, linux-alpha@vger.kernel.org,
	ink@jurassic.park.msu.ru, akpm@linux-foundation.org,
	robin.murphy@arm.com, davem@davemloft.net
In-Reply-To: <1567231103-13237-9-git-send-email-linyunsheng@huawei.com>

Hi Yunsheng,

On Sat, Aug 31, 2019 at 01:58:22PM +0800, Yunsheng Lin wrote:
> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
> of proximity domain is optional, as below:
> 
> This optional object is used to describe proximity domain
> associations within a machine. _PXM evaluates to an integer
> that identifies a device as belonging to a Proximity Domain
> defined in the System Resource Affinity Table (SRAT).
> 
> Since mips ip27 uses hub_data instead of node_to_cpumask_map,
> this patch checks node id with the below case before returning
> &hub_data(node)->h_cpus:
> 1. if node_id >= MAX_COMPACT_NODES, return cpu_none_mask
> 2. if node_id < 0, return cpu_online_mask
> 3. if hub_data(node) is NULL, return cpu_online_mask
> 
> [1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf

Similar to David's comment on the sparc patch, these systems don't use
ACPI so I don't see from your commit message why this change would be
relevant.

This same comment applies to patch 9 too.

Thanks,
    Paul

> 
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
>  arch/mips/include/asm/mach-ip27/topology.h | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/mips/include/asm/mach-ip27/topology.h b/arch/mips/include/asm/mach-ip27/topology.h
> index 965f079..914a55a 100644
> --- a/arch/mips/include/asm/mach-ip27/topology.h
> +++ b/arch/mips/include/asm/mach-ip27/topology.h
> @@ -15,9 +15,18 @@ struct cpuinfo_ip27 {
>  extern struct cpuinfo_ip27 sn_cpu_info[NR_CPUS];
>  
>  #define cpu_to_node(cpu)	(sn_cpu_info[(cpu)].p_nodeid)
> -#define cpumask_of_node(node)	((node) == -1 ?				\
> -				 cpu_all_mask :				\
> -				 &hub_data(node)->h_cpus)
> +
> +static inline const struct cpumask *cpumask_of_node(int node)
> +{
> +	if (node >= MAX_COMPACT_NODES)
> +		return cpu_none_mask;
> +
> +	if (node < 0 || !hub_data(node))
> +		return cpu_online_mask;
> +
> +	return &hub_data(node)->h_cpus;
> +}
> +
>  struct pci_bus;
>  extern int pcibus_to_node(struct pci_bus *);
>  
> -- 
> 2.8.1
> 

_______________________________________________
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 2/9] x86: numa: check the node id consistently for x86
From: Peter Zijlstra @ 2019-08-31 16:12 UTC (permalink / raw)
  To: Yunsheng Lin
  Cc: dalias, linux-sh, catalin.marinas, dave.hansen, heiko.carstens,
	linuxarm, jiaxun.yang, linux-mips, mwb, paulus, hpa, sparclinux,
	chenhc, will, cai, linux-s390, ysato, mpe, x86, rppt, borntraeger,
	dledford, mingo, jeffrey.t.kirsher, benh, jhogan, nfont, mattst88,
	len.brown, gor, anshuman.khandual, bp, luto, tglx, naveen.n.rao,
	linux-arm-kernel, rth, axboe, linuxppc-dev, linux-kernel, ralf,
	tbogendoerfer, paul.burton, linux-alpha, ink, akpm, robin.murphy,
	davem
In-Reply-To: <4d89c688-49e4-a2aa-32ee-65e36edcd913@huawei.com>

On Sat, Aug 31, 2019 at 06:09:39PM +0800, Yunsheng Lin wrote:
> 
> 
> On 2019/8/31 16:55, Peter Zijlstra wrote:
> > On Sat, Aug 31, 2019 at 01:58:16PM +0800, Yunsheng Lin wrote:
> >> According to Section 6.2.14 from ACPI spec 6.3 [1], the setting
> >> of proximity domain is optional, as below:
> >>
> >> This optional object is used to describe proximity domain
> >> associations within a machine. _PXM evaluates to an integer
> >> that identifies a device as belonging to a Proximity Domain
> >> defined in the System Resource Affinity Table (SRAT).
> > 
> > That's just words.. what does it actually mean?
> 
> It means the dev_to_node(dev) may return -1 if the bios does not
> implement the proximity domain feature, user may use that value
> to call cpumask_of_node and cpumask_of_node does not protect itself
> from node id being -1, which causes out of bound access.

> >> @@ -69,6 +69,12 @@ extern const struct cpumask *cpumask_of_node(int node);
> >>  /* Returns a pointer to the cpumask of CPUs on Node 'node'. */
> >>  static inline const struct cpumask *cpumask_of_node(int node)
> >>  {
> >> +	if (node >= nr_node_ids)
> >> +		return cpu_none_mask;
> >> +
> >> +	if (node < 0 || !node_to_cpumask_map[node])
> >> +		return cpu_online_mask;
> >> +
> >>  	return node_to_cpumask_map[node];
> >>  }
> >>  #endif
> > 
> > I _reallly_ hate this. Users are expected to use valid numa ids. Now
> > we're adding all this checking to all users. Why do we want to do that?
> 
> As above, the dev_to_node(dev) may return -1.
> 
> > 
> > Using '(unsigned)node >= nr_nods_ids' is an error.
> 
> 'node >= nr_node_ids' can be dropped if all user is expected to not call
> cpumask_of_node with node id greater or equal to nr_nods_ids.

you copied my typo :-)

> From what I can see, the problem can be fixed in three place:
> 1. Make user dev_to_node return a valid node id even when proximity
>    domain is not set by bios(or node id set by buggy bios is not valid),
>    which may need info from the numa system to make sure it will return
>    a valid node.
> 
> 2. User that call cpumask_of_node should ensure the node id is valid
>    before calling cpumask_of_node, and user also need some info to
>    make ensure node id is valid.
> 
> 3. Make sure cpumask_of_node deal with invalid node id as this patchset.
> 
> Which one do you prefer to make sure node id is valid, or do you
> have any better idea?
> 
> Any detail advice and suggestion will be very helpful, thanks.

1) because even it is not set, the device really does belong to a node.
It is impossible a device will have magic uniform access to memory when
CPUs cannot.

2) is already true today, cpumask_of_node() requires a valid node_id.

3) is just wrong and increases overhead for everyone.

_______________________________________________
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 19/26] arm64: remove __iounmap
From: Will Deacon @ 2019-08-31 16:29 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-ia64, linux-sh, linux-kernel, Guo Ren, sparclinux,
	linux-riscv, Vincent Chen, linux-arch, linux-s390, linux-hexagon,
	x86, linux-snps-arc, linux-xtensa, Arnd Bergmann, linux-m68k,
	openrisc, Greentime Hu, linux-mtd, Guan Xuetao, linux-arm-kernel,
	Michal Simek, linux-parisc, linux-mips, linux-alpha, nios2-dev
In-Reply-To: <20190830160515.GC26887@lst.de>

Hi Christoph,

On Fri, Aug 30, 2019 at 06:05:15PM +0200, Christoph Hellwig wrote:
> On Mon, Aug 19, 2019 at 08:36:02AM +0100, Will Deacon wrote:
> > On Sat, Aug 17, 2019 at 09:32:46AM +0200, Christoph Hellwig wrote:
> > > No need to indirect iounmap for arm64.
> > > 
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > ---
> > >  arch/arm64/include/asm/io.h | 3 +--
> > >  arch/arm64/mm/ioremap.c     | 4 ++--
> > >  2 files changed, 3 insertions(+), 4 deletions(-)
> > 
> > Not sure why we did it like this...
> > 
> > Acked-by: Will Deacon <will@kernel.org>
> 
> Can you just pick this one up through the arm64 tree for 5.4?

Unfortunately, it doesn't apply because the tree you've based it on has
removed ioremap_wt(). If you send a version based on mainline, I can
queue it.

Cheers,

Will

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

^ permalink raw reply

* Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
From: skodde @ 2019-08-31 17:19 UTC (permalink / raw)
  To: Ard Biesheuvel, Mark Rutland; +Cc: linux-efi, linux-arm-kernel
In-Reply-To: <CAJrUJt_hJJChKviBG5jvkUhv=OJrGPWpxF9aBB=S8-mL4URFOA@mail.gmail.com>

On Thu, Aug 15, 2019 at 8:17 AM skodde <skodde@gmail.com> wrote:
> On Thu, Aug 15, 2019 at 7:21 AM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> > On Thu, 15 Aug 2019 at 14:03, Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote:
> > > > The kernel boots fine with that option disabled, but strangely
> > > > presents the same error when disabling only CONFIG_RANDOMIZE_BASE.
> > >
> > > That shouldn't be possible, given the IS_ENABLED(CONFIG_RANDOMIZE_BASE)
> > > guard around the efi_get_random_bytes() call, so something sounds wrong.
> > >
> > > Maybe there's a problem with stale objects. If you're not doing so
> > > already, could you try a clean build with CONFIG_RANDOMIZE_BASE
> > > deselected?
> > >
> > Also, can you try booting with the nokaslr command line option added?
>
> You were right, I haven't tried with nokaslr, but it worked fine by
> rebuilding the kernel after a distclean with CONFIG_RANDOMIZE_BASE
> disabled and CONFIG_GCC_PLUGIN_STACKLEAK enabled. That's what I was
> expecting the first time and this is the reason why I mentioned it.
> I've been recompiling too many times, sorry about that.
>
> Anyhow, the main issue is the efi_get_random_bytes() fail with
> CONFIG_GCC_PLUGIN_STACKLEAK enabled, and that's still valid.

Now the configuration that was working on 5.8 fails on 5.11 (haven't
tried 5.9 or 5.10):

 - CONFIG_GCC_PLUGIN_STACKLEAK=n && CONFIG_RANDOMIZE_BASE=y (working on 5.8)

Loading Linux 5.2.11-00015-g0cc3335a89ac ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: efi_get_random_bytes() failed
EFI stub: ERROR: Failed to relocate kernel
Error: Image at 00079560000 start failed: Load Error
Unloading driver at 0x00079560000


 - CONFIG_GCC_PLUGIN_STACKLEAK=n && CONFIG_RANDOMIZE_BASE=y && nokaslr

Loading Linux 5.2.11-00015-g0cc3335a89ac ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: KASLR disabled on kernel command line
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
EFI stub: ERROR: Unable to construct new device tree.
EFI stub: ERROR: Failed to update FDT and exit boot services
Error: Image at 00079561000 start failed: Load Error
Unloading driver at 0x00079561000


After getting back to the bootloader, loading a known working kernel
fails (but it works fine after a reboot):

Loading Linux 5.2.8-00016-ga0d5f389a536 ...

Synchronous Exception at 0x00000000B652157C
PC 0x0000B652157C
PC 0x0000B65226B4
PC 0x0000B6522EE0
PC 0x0000B646BB10
PC 0x0000B6468580
PC 0x0000B6524600
PC 0x0000B6420078
PC 0x0000B6485CFC
PC 0x0000B64849B4
PC 0x0000B648586C
PC 0x0000B64849B4
PC 0x0000B6485E68
PC 0x0000B6485EC0
PC 0x0000B647C5C8
PC 0x0000B647C2C8
PC 0x0000B647C658
PC 0x0000B647C2C8
PC 0x0000B64784A8
PC 0x0000B646F1FC
PC 0x0000B6485CFC
PC 0x0000B64849B4
PC 0x0000B648586C
PC 0x0000B64849B4
PC 0x0000B6483C94
PC 0x0000B64785A4
PC 0x0000B6478794
PC 0x0000B647880C
PC 0x0000B652532C
PC 0x00003F95B714 (0x00003F952000+0x00009714) [ 1] DxeCore.dll
PC 0x0000B66CC440 (0x0000B66B9000+0x00013440) [ 2] UiApp.dll
PC 0x0000B66CCD8C (0x0000B66B9000+0x00013D8C) [ 2] UiApp.dll
PC 0x0000BF73D880 (0x0000BF729000+0x00014880) [ 3] SetupBrowser.dll
PC 0x0000BF737BFC (0x0000BF729000+0x0000EBFC) [ 3] SetupBrowser.dll
PC 0x0000B66C2700 (0x0000B66B9000+0x00009700) [ 4] UiApp.dll
PC 0x00003F95B714 (0x00003F952000+0x00009714) [ 5] DxeCore.dll
PC 0x0000BF71AEBC (0x0000BF711000+0x00009EBC) [ 6] BdsDxe.dll
PC 0x0000BF721C8C (0x0000BF711000+0x00010C8C) [ 6] BdsDxe.dll
PC 0x00003F95F470 (0x00003F952000+0x0000D470) [ 7] DxeCore.dll
[ 1] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
[ 2] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
[ 3] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe/DEBUG/SetupBrowser.dll
[ 4] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
[ 5] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
[ 6] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll
[ 7] /home/skodde/macchiatobin/edk/uefi-marvell/Build/Armada80x0McBin-AARCH64/RELEASE_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll

  X0 0xAFAFAFAFAFAFAFAF   X1 0x0000000000008000   X2
0xFFFFFFFFFFEFFFFF   X3 0x0000000000008000
  X4 0x00000000B6530000   X5 0x00000000B652CAE0   X6
0x000000007B4FE000   X7 0x00000000B6468258
  X8 0x0000000000001000   X9 0x0000000000000002  X10
0xFFFFFFFFFFFFFFFF  X11 0x00000000B648A182
 X12 0x00000000B6489FAC  X13 0x00000000B648A15C  X14
0x0000000000000014  X15 0x00000000000000FF
 X16 0x0000000000001510  X17 0x00000000B5A3AA40  X18
0x000000000000005C  X19 0x0000000000000401
 X20 0x0000000000000001  X21 0x000000002D3C2808  X22
0x00000000B652CAB0  X23 0x000000006DB08FA4
 X24 0x0000000000000000  X25 0x000000007A96E000  X26
0x000000000000000F  X27 0x0000000000000FFF
 X28 0x00000000B646B000   FP 0x000000003F950BD0   LR 0x00000000B65226B4

  V0 0x0000000000000000 4049C00000000000   V1 0x0000000000000000
3FE0000000000000
  V2 0x0000000000000000 40D1AD0000000000   V3 0xFFBFDFDF6FEFFFDF
FFFFFFFFFFEFFED5
  V4 0xF7FFF5EF41FBEFFF FFFFBFFFFFFFFFBC   V5 0xFFFFFFFFAFB8FFFB
FFBFFFFFD7FFDDF6
  V6 0x8BFFB1B7FFFB7FFE F7EFFFFFFFFFFFFF   V7 0x7BFFFFBF55FFD7D7
FFFFFFFFDB7FFFFF
  V8 0x0000000000000000 FFFFFFFFFFDDFF9F   V9 0x0000000000000000
FFFEFBF3976793FF
 V10 0x0000000000000000 FFFFFFFFFF7FFFDF  V11 0x0000000000000000
F77FFEFDFFFFF3FF
 V12 0x0000000000000000 FFFFFFFF3D554FFF  V13 0x0000000000000000
FFFFFFFFBDE0EABF
 V14 0x0000000000000000 FFFFFFFFE7EEFFAD  V15 0x0000000000000000
FFDFFFFF7DFEFFFB
 V16 0xEEA8FDDFFFFFDFFF FFFFFFFFB7FE56FF  V17 0xBF3B955BDBFFFFFF
FFF7F9EFFFFFBFFF
 V18 0x7FBFFDEF7FEBFFAF FFFFFFBF8FEFFFDF  V19 0xFEBFFF7FFFFDFFFF
FFFFFFFFF5FF7DF5
 V20 0xFFFFFFFFFFFFFFFF FFFFFFFFC7ED54FF  V21 0xF7FFFEEEFFFFFF7F
DAFEFFDFFFF7FBF5
 V22 0xFBE6FFFFFFFFFFFF FFFFFFFFFFFFFFFF  V23 0xFFF5FFFFFF7FFFFF
FFFFFFFFFFFFFF7F
 V24 0xFFFFFFFF7FFEFFFF FFFFEF7FFFFFFFFF  V25 0xEB8EFFF7FFFFF7FE
FFFFFFFFFD7FFFFD
 V26 0x3FFFFDFFFFFF5FFF FFCF7EFFFFFFFFFF  V27 0xAFBFFEF9FFFFFFFF
DDFBBFFBBDC4BE5F
 V28 0xFFFFFFDFFFF7EFDF 9DCD7CF3FFFFFFCF  V29 0xDFFFFFFFFFFFFFFF
BAF7D6FE7FFFDFFF
 V30 0xDFF7FFFFFFBFFFFD FFFFDFFFFFFFFFFF  V31 0xCA4F7F47DAF7DBFB
FFFFFFFFFFF76E77

  SP 0x000000003F950BD0  ELR 0x00000000B652157C  SPSR 0x60000209  FPSR
0x00000010
 ESR 0x96000004          FAR 0xAFAFAFAFAFAFAFBF

 ESR : EC 0x25  IL 0x1  ISS 0x00000004

Data abort: Translation fault, zeroth level

Stack dump:
  000003F950AD0: 000000003F950C70 000000003F96454C FFFFFFFFFF7FFFDF
0000000000000000
  000003F950AF0: 000000003F950C90 000000003F96454C 000000003F950B60
00000000BF6F9EAC
  000003F950B10: 00000000B91B4398 00000000BE909498 000000003F950B30
000000003F95F5D4
  000003F950B30: 000000003F950B60 000000003F960758 000000003F97407C
000000003F95F5D4
  000003F950B50: 000000003F950B80 D7AB00003F960910 000000003F950B80
000000003F9612DC
  000003F950B70: 000000004201DB9E 000000003F974078 000000003F950BA0
000000003F961364
  000003F950B90: 000000003F974070 0000000000000000 000000003F950BD0
000000003F96323C
  000003F950BB0: 000000003F950BD0 000000003F960B14 000000003F976618
000000007B50DFFF
> 000003F950BD0: 000000003F950C10 00000000B65226B4 00000000B5A3E8A0 00000000B5A3E8A0
  000003F950BF0: 0000000000000000 00000000000CEC80 0000000000000000
0000000000001000
  000003F950C10: 000000003F950C70 00000000B6522EE0 00000000000CEC80
00000000B5A3E8A0
  000003F950C30: 0000000000000000 0000000000001000 000000007A96E000
0000000000000000
  000003F950C50: 0000000000007FFF 000000000000000F 0000000000001000
00000000B646B000
  000003F950C70: 000000003F950CD0 00000000B646BB10 0000000000000000
0000000000000BA1
  000003F950C90: 0000000000000000 00000000B5A3E8A0 000000007A96E000
0000000000000FFF
  000003F950CB0: 0000000000BA0A00 0000000000000001 0000000000001000
000000003F95F5D4
ASSERT [ArmCpuDxe]
/home/skodde/macchiatobin/edk/uefi-marvell/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(271):
((BOOLEAN)(0==1))


 - CONFIG_GCC_PLUGIN_STACKLEAK=y && CONFIG_RANDOMIZE_BASE=n

Loading Linux 5.2.11-00015-g0cc3335a89ac ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd081]
[...]

All good here.

This time I did a distclean before each build.


Thanks

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

^ permalink raw reply

* [PATCH] spi: ep93xx: Repair SPI CS lookup tables
From: Alexander Sverdlin @ 2019-08-31 18:04 UTC (permalink / raw)
  To: Linus Walleij, Mark Brown, linux-arm-kernel, linux-gpio,
	linux-spi
  Cc: Hartley Sweeten, Alexander Sverdlin, Russell King, stable,
	Lukasz Majewski

The actual device name of the SPI controller being registered on EP93xx is
"spi0" (as seen by gpiod_find_lookup_table()). This patch fixes all
relevant lookup tables and the following failure (seen on EDB9302):

ep93xx-spi ep93xx-spi.0: failed to register SPI master
ep93xx-spi: probe of ep93xx-spi.0 failed with error -22

Fixes: 1dfbf334f1236 ("spi: ep93xx: Convert to use CS GPIO descriptors")
Cc: stable@vger.kernel.org
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
 arch/arm/mach-ep93xx/edb93xx.c       | 2 +-
 arch/arm/mach-ep93xx/simone.c        | 2 +-
 arch/arm/mach-ep93xx/ts72xx.c        | 4 ++--
 arch/arm/mach-ep93xx/vision_ep9307.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index 1f0da76a39de..7b7280c21ee0 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c
@@ -103,7 +103,7 @@ static struct spi_board_info edb93xx_spi_board_info[] __initdata = {
 };
 
 static struct gpiod_lookup_table edb93xx_spi_cs_gpio_table = {
-	.dev_id = "ep93xx-spi.0",
+	.dev_id = "spi0",
 	.table = {
 		GPIO_LOOKUP("A", 6, "cs", GPIO_ACTIVE_LOW),
 		{ },
diff --git a/arch/arm/mach-ep93xx/simone.c b/arch/arm/mach-ep93xx/simone.c
index e2658e22bba1..8a53b74dc4b2 100644
--- a/arch/arm/mach-ep93xx/simone.c
+++ b/arch/arm/mach-ep93xx/simone.c
@@ -73,7 +73,7 @@ static struct spi_board_info simone_spi_devices[] __initdata = {
  * v1.3 parts will still work, since the signal on SFRMOUT is automatic.
  */
 static struct gpiod_lookup_table simone_spi_cs_gpio_table = {
-	.dev_id = "ep93xx-spi.0",
+	.dev_id = "spi0",
 	.table = {
 		GPIO_LOOKUP("A", 1, "cs", GPIO_ACTIVE_LOW),
 		{ },
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 582e06e104fd..e0e1b11032f1 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -267,7 +267,7 @@ static struct spi_board_info bk3_spi_board_info[] __initdata = {
  * goes through CPLD
  */
 static struct gpiod_lookup_table bk3_spi_cs_gpio_table = {
-	.dev_id = "ep93xx-spi.0",
+	.dev_id = "spi0",
 	.table = {
 		GPIO_LOOKUP("F", 3, "cs", GPIO_ACTIVE_LOW),
 		{ },
@@ -316,7 +316,7 @@ static struct spi_board_info ts72xx_spi_devices[] __initdata = {
 };
 
 static struct gpiod_lookup_table ts72xx_spi_cs_gpio_table = {
-	.dev_id = "ep93xx-spi.0",
+	.dev_id = "spi0",
 	.table = {
 		/* DIO_17 */
 		GPIO_LOOKUP("F", 2, "cs", GPIO_ACTIVE_LOW),
diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
index a88a1d807b32..cbcba3136d74 100644
--- a/arch/arm/mach-ep93xx/vision_ep9307.c
+++ b/arch/arm/mach-ep93xx/vision_ep9307.c
@@ -242,7 +242,7 @@ static struct spi_board_info vision_spi_board_info[] __initdata = {
 };
 
 static struct gpiod_lookup_table vision_spi_cs_gpio_table = {
-	.dev_id = "ep93xx-spi.0",
+	.dev_id = "spi0",
 	.table = {
 		GPIO_LOOKUP_IDX("A", 6, "cs", 0, GPIO_ACTIVE_LOW),
 		GPIO_LOOKUP_IDX("A", 7, "cs", 1, GPIO_ACTIVE_LOW),
-- 
2.21.0


_______________________________________________
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: [PATCH v2 7/9] sparc64: numa: check the node id consistently for sparc64
From: David Miller @ 2019-08-31 20:02 UTC (permalink / raw)
  To: linyunsheng
  Cc: dalias, linux-sh, peterz, catalin.marinas, dave.hansen,
	heiko.carstens, linuxarm, jiaxun.yang, linux-mips, mwb, paulus,
	hpa, sparclinux, chenhc, will, cai, linux-s390, ysato, mpe, x86,
	rppt, borntraeger, dledford, mingo, jeffrey.t.kirsher, benh,
	jhogan, nfont, mattst88, len.brown, gor, anshuman.khandual, bp,
	luto, tglx, naveen.n.rao, linux-arm-kernel, rth, axboe,
	linuxppc-dev, linux-kernel, ralf, tbogendoerfer, paul.burton,
	linux-alpha, ink, akpm, robin.murphy
In-Reply-To: <0195eb73-99ae-fec2-3e11-2cb9e6677926@huawei.com>

From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Sat, 31 Aug 2019 16:57:04 +0800

> Did you mean sparc64 system does not has ACPI, the device's node id will
> not specified by ACPI, so the ACPI is unrelated here?

Yes, sparc64 never has and never will have ACPI.

This is also true for several other platforms where you have made this
change.

The assumption of your entire patch set is that the semantics of the
NUMA node ID are somehow completely defined by ACPI semantics.  Which
is not true.

_______________________________________________
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 v1 1/1] ARM: dts: rockchip: set crypto default disabled on rk3288
From: Heiko Stuebner @ 2019-08-31 23:04 UTC (permalink / raw)
  To: Elon Zhang
  Cc: mark.rutland, devicetree, linux-kernel, linux-rockchip, robh+dt,
	linux-arm-kernel
In-Reply-To: <3b9cbffa-291e-fc95-bce6-5b24f5fd860d@rock-chips.com>

Hi Elon,

Am Donnerstag, 29. August 2019, 13:31:00 CEST schrieb Elon Zhang:
> On 8/27/2019 22:28, Heiko Stuebner wrote:
> > Am Dienstag, 27. August 2019, 09:14:39 CEST schrieb Elon Zhang:
> >> Not every board needs to enable crypto node, so the node should
> >> be set default disabled in rk3288.dtsi and enabled in specific
> >> board dts file.
> > Can you give a bit more rationale here? There would need to be a very
> > specific reason because of the following:
> >
> > The crypto module is not wired to some board-specific components,
> > so its usability does not depend on the specific board at all.
> > Instead every board can just use it out of the box and the devicetree
> > is supposed to describe the hardware and is _not_ meant as a space
> > for user configuration.
> 
> Right for almost all normal hardware modules but the crypto module was 
> designed
> 
> for secure world. As a result,  the crypto module will become 
> inaccessible for linux kernel if secure world enable it.
> 
> We plan to enable the crypto module in secure world so we should set 
> crypto module default disabled in linux kernel.

ok ... I'm halfway convinced ;-) .

The big thing I want to see is that secure setting in the actual firmware.
Aka right now you probably have that in your Rockchip-specific ATF fork
and I really want to see the relevant change for public uboot or ATF.

I don't necessarily require it to be fully merged before taking this, but
I really want to see the change either on a mailing list or atf gerrit
instance [that makes the crypto engine secure only].

Rationale behind this is that we don't care very much about private stuff
that the general ecosystem doesn't benefit from.


Thanks
Heiko


> > So in fact the status property should probably go away completely from
> > the crypto node, as it's usable out of the box in all cases.
> >
> >
> > Heiko
> >
> >
> >
> >> Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
> >> ---
> >>   arch/arm/boot/dts/rk3288.dtsi | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> >> index cc893e154fe5..d509aa24177c 100644
> >> --- a/arch/arm/boot/dts/rk3288.dtsi
> >> +++ b/arch/arm/boot/dts/rk3288.dtsi
> >> @@ -984,7 +984,7 @@
> >>   		clock-names = "aclk", "hclk", "sclk", "apb_pclk";
> >>   		resets = <&cru SRST_CRYPTO>;
> >>   		reset-names = "crypto-rst";
> >> -		status = "okay";
> >> +		status = "disabled";
> >>   	};
> >>   
> >>   	iep_mmu: iommu@ff900800 {
> >>
> >
> >
> >
> >
> >
> >
> 
> 
> 





_______________________________________________
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 1/4] x86: kdump: move reserve_crashkernel_low() into crash_core.c
From: kbuild test robot @ 2019-08-31 23:12 UTC (permalink / raw)
  To: Chen Zhou
  Cc: horms, Chen Zhou, catalin.marinas, bhsharma, dyoung, kexec,
	linux-kernel, mingo, james.morse, kbuild-all, guohanjun, tglx,
	will, linux-arm-kernel
In-Reply-To: <20190830071200.56169-2-chenzhou10@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

Hi Chen,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc6 next-20190830]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Chen-Zhou/support-reserving-crashkernel-above-4G-on-arm64-kdump/20190901-053351
config: x86_64-randconfig-s0-09010004 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   ld: kernel/crash_core.o: in function `reserve_crashkernel_low':
>> kernel/crash_core.c:354: undefined reference to `crashk_low_res'
>> ld: kernel/crash_core.c:355: undefined reference to `crashk_low_res'

vim +354 kernel/crash_core.c

   296	
   297	int __init reserve_crashkernel_low(void)
   298	{
   299	#if defined(CONFIG_X86_64) || defined(CONFIG_ARM64)
   300		unsigned long long base, low_base = 0, low_size = 0;
   301		unsigned long total_low_mem;
   302		int ret;
   303	
   304		total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
   305	
   306		/* crashkernel=Y,low */
   307		ret = parse_crashkernel_low(boot_command_line, total_low_mem, &low_size,
   308				&base);
   309		if (ret) {
   310	#ifdef CONFIG_X86_64
   311			/*
   312			 * two parts from lib/swiotlb.c:
   313			 * -swiotlb size: user-specified with swiotlb= or default.
   314			 *
   315			 * -swiotlb overflow buffer: now hardcoded to 32k. We round it
   316			 * to 8M for other buffers that may need to stay low too. Also
   317			 * make sure we allocate enough extra low memory so that we
   318			 * don't run out of DMA buffers for 32-bit devices.
   319			 */
   320			low_size = max(swiotlb_size_or_default() + (8UL << 20),
   321					256UL << 20);
   322	#else
   323			/*
   324			 * in arm64, reserve low memory if and only if crashkernel=X,low
   325			 * specified.
   326			 */
   327			return -EINVAL;
   328	#endif
   329		} else {
   330			/* passed with crashkernel=0,low ? */
   331			if (!low_size)
   332				return 0;
   333		}
   334	
   335		low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
   336		if (!low_base) {
   337			pr_err("Cannot reserve %ldMB crashkernel low memory, please try smaller size.\n",
   338			       (unsigned long)(low_size >> 20));
   339			return -ENOMEM;
   340		}
   341	
   342		ret = memblock_reserve(low_base, low_size);
   343		if (ret) {
   344			pr_err("%s: Error reserving crashkernel low memblock.\n",
   345					__func__);
   346			return ret;
   347		}
   348	
   349		pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System low RAM: %ldMB)\n",
   350			(unsigned long)(low_size >> 20),
   351			(unsigned long)(low_base >> 20),
   352			(unsigned long)(total_low_mem >> 20));
   353	
 > 354		crashk_low_res.start = low_base;
 > 355		crashk_low_res.end   = low_base + low_size - 1;
   356	#endif
   357		return 0;
   358	}
   359	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35598 bytes --]

[-- Attachment #3: 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: [PATCH v6 1/4] x86: kdump: move reserve_crashkernel_low() into crash_core.c
From: kbuild test robot @ 2019-08-31 23:48 UTC (permalink / raw)
  To: Chen Zhou
  Cc: horms, Chen Zhou, catalin.marinas, bhsharma, dyoung, kexec,
	linux-kernel, mingo, james.morse, kbuild-all, guohanjun, tglx,
	will, linux-arm-kernel
In-Reply-To: <20190830071200.56169-2-chenzhou10@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 10243 bytes --]

Hi Chen,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc6 next-20190830]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Chen-Zhou/support-reserving-crashkernel-above-4G-on-arm64-kdump/20190901-053351
config: um-i386_defconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=um SUBARCH=i386

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   In file included from include/linux/crash_core.h:9:0,
                    from kernel//printk/printk.c:37:
   arch/x86/include/asm/kexec.h: In function 'crash_setup_regs':
   arch/x86/include/asm/kexec.h:88:46: error: 'struct pt_regs' has no member named 'bx'
      asm volatile("movl %%ebx,%0" : "=m"(newregs->bx));
                                                 ^~
   arch/x86/include/asm/kexec.h:89:46: error: 'struct pt_regs' has no member named 'cx'
      asm volatile("movl %%ecx,%0" : "=m"(newregs->cx));
                                                 ^~
   arch/x86/include/asm/kexec.h:90:46: error: 'struct pt_regs' has no member named 'dx'
      asm volatile("movl %%edx,%0" : "=m"(newregs->dx));
                                                 ^~
   arch/x86/include/asm/kexec.h:91:46: error: 'struct pt_regs' has no member named 'si'
      asm volatile("movl %%esi,%0" : "=m"(newregs->si));
                                                 ^~
   arch/x86/include/asm/kexec.h:92:46: error: 'struct pt_regs' has no member named 'di'
      asm volatile("movl %%edi,%0" : "=m"(newregs->di));
                                                 ^~
   arch/x86/include/asm/kexec.h:93:46: error: 'struct pt_regs' has no member named 'bp'
      asm volatile("movl %%ebp,%0" : "=m"(newregs->bp));
                                                 ^~
   arch/x86/include/asm/kexec.h:94:46: error: 'struct pt_regs' has no member named 'ax'
      asm volatile("movl %%eax,%0" : "=m"(newregs->ax));
                                                 ^~
   arch/x86/include/asm/kexec.h:95:46: error: 'struct pt_regs' has no member named 'sp'
      asm volatile("movl %%esp,%0" : "=m"(newregs->sp));
                                                 ^~
   arch/x86/include/asm/kexec.h:96:49: error: 'struct pt_regs' has no member named 'ss'
      asm volatile("movl %%ss, %%eax;" :"=a"(newregs->ss));
                                                    ^~
   arch/x86/include/asm/kexec.h:97:49: error: 'struct pt_regs' has no member named 'cs'
      asm volatile("movl %%cs, %%eax;" :"=a"(newregs->cs));
                                                    ^~
>> arch/x86/include/asm/kexec.h:98:49: error: 'struct pt_regs' has no member named 'ds'
      asm volatile("movl %%ds, %%eax;" :"=a"(newregs->ds));
                                                    ^~
>> arch/x86/include/asm/kexec.h:99:51: error: 'struct pt_regs' has no member named 'es'; did you mean 'regs'?
      asm volatile("movl %%es, %%eax;" :"=a"(newregs->es));
                                                      ^~
                                                      regs
   arch/x86/include/asm/kexec.h:100:47: error: 'struct pt_regs' has no member named 'flags'
      asm volatile("pushfl; popl %0" :"=m"(newregs->flags));
                                                  ^~
   arch/x86/include/asm/kexec.h:122:10: error: 'struct pt_regs' has no member named 'ip'
      newregs->ip = _THIS_IP_;
             ^~

vim +98 arch/x86/include/asm/kexec.h

dd5f726076cc76 arch/x86/include/asm/kexec.h Vivek Goyal      2014-08-08   75  
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   76  /*
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   77   * This function is responsible for capturing register states if coming
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   78   * via panic otherwise just fix up the ss and sp if coming via kernel
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   79   * mode exception.
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   80   */
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   81  static inline void crash_setup_regs(struct pt_regs *newregs,
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   82  				    struct pt_regs *oldregs)
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   83  {
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   84  	if (oldregs) {
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   85  		memcpy(newregs, oldregs, sizeof(*newregs));
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   86  	} else {
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30   87  #ifdef CONFIG_X86_32
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23   88  		asm volatile("movl %%ebx,%0" : "=m"(newregs->bx));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23   89  		asm volatile("movl %%ecx,%0" : "=m"(newregs->cx));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23   90  		asm volatile("movl %%edx,%0" : "=m"(newregs->dx));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23   91  		asm volatile("movl %%esi,%0" : "=m"(newregs->si));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23   92  		asm volatile("movl %%edi,%0" : "=m"(newregs->di));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23   93  		asm volatile("movl %%ebp,%0" : "=m"(newregs->bp));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23   94  		asm volatile("movl %%eax,%0" : "=m"(newregs->ax));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  @95  		asm volatile("movl %%esp,%0" : "=m"(newregs->sp));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  @96  		asm volatile("movl %%ss, %%eax;" :"=a"(newregs->ss));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23   97  		asm volatile("movl %%cs, %%eax;" :"=a"(newregs->cs));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  @98  		asm volatile("movl %%ds, %%eax;" :"=a"(newregs->ds));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  @99  		asm volatile("movl %%es, %%eax;" :"=a"(newregs->es));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  100  		asm volatile("pushfl; popl %0" :"=m"(newregs->flags));
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30  101  #else
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  102  		asm volatile("movq %%rbx,%0" : "=m"(newregs->bx));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  103  		asm volatile("movq %%rcx,%0" : "=m"(newregs->cx));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  104  		asm volatile("movq %%rdx,%0" : "=m"(newregs->dx));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  105  		asm volatile("movq %%rsi,%0" : "=m"(newregs->si));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  106  		asm volatile("movq %%rdi,%0" : "=m"(newregs->di));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  107  		asm volatile("movq %%rbp,%0" : "=m"(newregs->bp));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  108  		asm volatile("movq %%rax,%0" : "=m"(newregs->ax));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  109  		asm volatile("movq %%rsp,%0" : "=m"(newregs->sp));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  110  		asm volatile("movq %%r8,%0" : "=m"(newregs->r8));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  111  		asm volatile("movq %%r9,%0" : "=m"(newregs->r9));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  112  		asm volatile("movq %%r10,%0" : "=m"(newregs->r10));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  113  		asm volatile("movq %%r11,%0" : "=m"(newregs->r11));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  114  		asm volatile("movq %%r12,%0" : "=m"(newregs->r12));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  115  		asm volatile("movq %%r13,%0" : "=m"(newregs->r13));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  116  		asm volatile("movq %%r14,%0" : "=m"(newregs->r14));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  117  		asm volatile("movq %%r15,%0" : "=m"(newregs->r15));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  118  		asm volatile("movl %%ss, %%eax;" :"=a"(newregs->ss));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  119  		asm volatile("movl %%cs, %%eax;" :"=a"(newregs->cs));
b69a3f9dc0bbdb include/asm-x86/kexec.h      Joe Perches      2008-03-23  120  		asm volatile("pushfq; popq %0" :"=m"(newregs->flags));
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30  121  #endif
de0d22e50cd3d5 arch/x86/include/asm/kexec.h Nick Desaulniers 2018-10-30  122  		newregs->ip = _THIS_IP_;
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30  123  	}
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30  124  }
3c233d1334ffc8 include/asm-x86/kexec.h      Harvey Harrison  2008-01-30  125  

:::::: The code at line 98 was first introduced by commit
:::::: b69a3f9dc0bbdbf9278ac5bc8d4b6347c11a701b include/asm-x86/kexec.h: checkpatch cleanups - formatting only

:::::: TO: Joe Perches <joe@perches.com>
:::::: CC: Ingo Molnar <mingo@elte.hu>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 8454 bytes --]

[-- Attachment #3: 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: [PATCH v5 01/18] thermal: sun8i: add thermal driver for h6
From: Ondřej Jirman @ 2019-09-01  2:06 UTC (permalink / raw)
  To: Yangtao Li
  Cc: mark.rutland, devicetree, linux-pm, maxime.ripard, gregkh,
	daniel.lezcano, linux-kernel, edubezval, wens, robh+dt,
	Jonathan.Cameron, mchehab+samsung, rui.zhang, davem,
	linux-arm-kernel
In-Reply-To: <20190810052829.6032-2-tiny.windzz@gmail.com>

Hello Yangtao,

On Sat, Aug 10, 2019 at 05:28:12AM +0000, Yangtao Li wrote:
> This patch adds the support for allwinner thermal sensor, within
> allwinner SoC. It will register sensors for thermal framework
> and use device tree to bind cooling device.
> 
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> ---
>  MAINTAINERS                     |   7 +
>  drivers/thermal/Kconfig         |  14 ++
>  drivers/thermal/Makefile        |   1 +
>  drivers/thermal/sun8i_thermal.c | 399 ++++++++++++++++++++++++++++++++
>  4 files changed, 421 insertions(+)
>  create mode 100644 drivers/thermal/sun8i_thermal.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 47800d32cfbc..89dc43f4064d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -682,6 +682,13 @@ L:	linux-crypto@vger.kernel.org
>  S:	Maintained
>  F:	drivers/crypto/sunxi-ss/
>  
> +ALLWINNER THERMAL DRIVER
> +M:	Yangtao Li <tiny.windzz@gmail.com>
> +L:	linux-pm@vger.kernel.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> +F:	drivers/thermal/sun8i_thermal.c
> +
>  ALLWINNER VPU DRIVER
>  M:	Maxime Ripard <maxime.ripard@bootlin.com>
>  M:	Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 9966364a6deb..f8b73b32b92d 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -262,6 +262,20 @@ config SPEAR_THERMAL
>  	  Enable this to plug the SPEAr thermal sensor driver into the Linux
>  	  thermal framework.
>  
> +config SUN8I_THERMAL
> +	tristate "Allwinner sun8i thermal driver"
> +	depends on ARCH_SUNXI || COMPILE_TEST
> +	depends on HAS_IOMEM
> +	depends on NVMEM
> +	depends on OF
> +	depends on RESET_CONTROLLER
> +	help
> +	  Support for the sun8i thermal sensor driver into the Linux thermal
> +	  framework.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called sun8i-thermal.
> +
>  config ROCKCHIP_THERMAL
>  	tristate "Rockchip thermal driver"
>  	depends on ARCH_ROCKCHIP || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 74a37c7f847a..fa6f8b206281 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -31,6 +31,7 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>  obj-y				+= broadcom/
>  obj-$(CONFIG_THERMAL_MMIO)		+= thermal_mmio.o
>  obj-$(CONFIG_SPEAR_THERMAL)	+= spear_thermal.o
> +obj-$(CONFIG_SUN8I_THERMAL)     += sun8i_thermal.o
>  obj-$(CONFIG_ROCKCHIP_THERMAL)	+= rockchip_thermal.o
>  obj-$(CONFIG_RCAR_THERMAL)	+= rcar_thermal.o
>  obj-$(CONFIG_RCAR_GEN3_THERMAL)	+= rcar_gen3_thermal.o
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> new file mode 100644
> index 000000000000..2ce36fa3fec3
> --- /dev/null
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -0,0 +1,399 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Thermal sensor driver for Allwinner SOC
> + * Copyright (C) 2019 Yangtao Li
> + *
> + * Based on the work of Icenowy Zheng <icenowy@aosc.io>
> + * Based on the work of Ondrej Jirman <megous@megous.com>
> + * Based on the work of Josef Gajdusek <atx@atx.name>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/device.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +#include <linux/thermal.h>
> +
> +#define MAX_SENSOR_NUM	4
> +
> +#define SUN50I_H6_SENSOR_NUM	2
> +#define SUN50I_H6_OFFSET	-2794
> +#define SUN50I_H6_SCALE		-67
> +
> +#define FT_TEMP_MASK				GENMASK(11, 0)
> +#define TEMP_CALIB_MASK				GENMASK(11, 0)
> +#define TEMP_TO_REG				672
> +#define CALIBRATE_DEFAULT			0x800
> +
> +#define SUN50I_THS_CTRL0			0x00
> +#define SUN50I_H6_THS_ENABLE			0x04
> +#define SUN50I_H6_THS_PC			0x08
> +#define SUN50I_H6_THS_DIC			0x10
> +#define SUN50I_H6_THS_DIS			0x20
> +#define SUN50I_H6_THS_MFC			0x30
> +#define SUN50I_H6_THS_TEMP_CALIB		0xa0
> +#define SUN50I_H6_THS_TEMP_DATA			0xc0
> +
> +#define SUN50I_THS_CTRL0_T_ACQ(x)		((GENMASK(15, 0) & (x)) << 16)
> +#define SUN50I_THS_FILTER_EN			BIT(2)
> +#define SUN50I_THS_FILTER_TYPE(x)		(GENMASK(1, 0) & (x))
> +#define SUN50I_H6_THS_PC_TEMP_PERIOD(x)		((GENMASK(19, 0) & (x)) << 12)
> +#define SUN50I_H6_THS_DATA_IRQ_STS(x)		BIT(x)
> +
> +/* millidegree celsius */
> +#define SUN50I_H6_FT_DEVIATION			7000
> +
> +struct ths_device;
> +
> +struct tsensor {
> +	struct ths_device		*tmdev;
> +	struct thermal_zone_device	*tzd;
> +	int				id;
> +};
> +
> +struct ths_device {
> +	struct device				*dev;
> +	struct regmap				*regmap;
> +	struct reset_control			*reset;
> +	struct clk				*bus_clk;
> +	struct tsensor				sensor[MAX_SENSOR_NUM];
> +};
> +
> +/* Temp Unit: millidegree Celsius */
> +static int sun8i_ths_reg2temp(struct ths_device *tmdev,
> +			      int reg)
> +{
> +	return (reg + SUN50I_H6_OFFSET) * SUN50I_H6_SCALE;
> +}
> +
> +static int sun8i_ths_get_temp(void *data, int *temp)
> +{
> +	struct tsensor *s = data;
> +	struct ths_device *tmdev = s->tmdev;
> +	int val;
> +
> +	regmap_read(tmdev->regmap, SUN50I_H6_THS_TEMP_DATA +
> +		    0x4 * s->id, &val);
> +
> +	/* ths have no data yet */
> +	if (!val)
> +		return -EAGAIN;
> +
> +	*temp = sun8i_ths_reg2temp(tmdev, val);
> +	/*
> +	 * XX - According to the original sdk, there are some platforms(rarely)
> +	 * that add a fixed offset value after calculating the temperature
> +	 * value. We can't simply put it on the formula for calculating the
> +	 * temperature above, because the formula for calculating the
> +	 * temperature above is also used when the sensor is calibrated. If
> +	 * do this, the correct calibration formula is hard to know.
> +	 */
> +	*temp += SUN50I_H6_FT_DEVIATION;
> +
> +	return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops ths_ops = {
> +	.get_temp = sun8i_ths_get_temp,
> +};
> +
> +static const struct regmap_config config = {
> +	.reg_bits = 32,
> +	.val_bits = 32,
> +	.reg_stride = 4,
> +	.fast_io = true,
> +};
> +
> +static irqreturn_t sun50i_h6_irq_thread(int irq, void *data)
> +{
> +	struct ths_device *tmdev = data;
> +	int i, state;
> +
> +	regmap_read(tmdev->regmap, SUN50I_H6_THS_DIS, &state);
> +
> +	for (i = 0; i < SUN50I_H6_SENSOR_NUM; i++) {
> +
> +		if (state & SUN50I_H6_THS_DATA_IRQ_STS(i)) {
> +			/* clear data irq pending */
> +			regmap_write(tmdev->regmap, SUN50I_H6_THS_DIS,
> +				     SUN50I_H6_THS_DATA_IRQ_STS(i));
> +
> +			thermal_zone_device_update(tmdev->sensor[i].tzd,
> +						   THERMAL_EVENT_UNSPECIFIED);
> +		}
> +	}
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int sun50i_ths_calibrate(struct ths_device *tmdev)
> +{
> +	struct nvmem_cell *calcell;
> +	struct device *dev = tmdev->dev;
> +	u16 *caldata;
> +	size_t callen;
> +	int ft_temp;
> +	int i, ret = 0;
> +
> +	calcell = devm_nvmem_cell_get(dev, "calib");
> +	if (IS_ERR(calcell)) {
> +		if (PTR_ERR(calcell) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +		/*
> +		 * Even if the external calibration data stored in sid is
> +		 * not accessible, the THS hardware can still work, although
> +		 * the data won't be so accurate.
> +		 *
> +		 * The default value of calibration register is 0x800 for
> +		 * every sensor, and the calibration value is usually 0x7xx
> +		 * or 0x8xx, so they won't be away from the default value
> +		 * for a lot.
> +		 *
> +		 * So here we do not return error if the calibartion data is
> +		 * not available, except the probe needs deferring.
> +		 */
> +		goto out;
> +	}
> +
> +	caldata = nvmem_cell_read(calcell, &callen);
> +	if (IS_ERR(caldata)) {
> +		ret = PTR_ERR(caldata);
> +		goto out;
> +	}
> +
> +	if (!caldata[0] || callen < 2 + 2 * SUN50I_H6_SENSOR_NUM) {
> +		ret = -EINVAL;
> +		goto out_free;
> +	}
> +
> +	/*
> +	 * efuse layout:
> +	 *
> +	 *	0   11  16	 32
> +	 *	+-------+-------+-------+
> +	 *	|temp|  |sensor0|sensor1|
> +	 *	+-------+-------+-------+
> +	 *
> +	 * The calibration data on the H6 is the ambient temperature and
> +	 * sensor values that are filled during the factory test stage.
> +	 *
> +	 * The unit of stored FT temperature is 0.1 degreee celusis.
> +	 * Through the stored ambient temperature and the data read
> +	 * by the sensor, after a certain calculation, the calibration
> +	 * value to be compensated can be obtained.
> +	 */
> +	ft_temp = caldata[0] & FT_TEMP_MASK;
> +
> +	for (i = 0; i < SUN50I_H6_SENSOR_NUM; i++) {
> +		int reg = (int)caldata[i + 1];
> +		int sensor_temp = sun8i_ths_reg2temp(tmdev, reg);
> +		int delta, cdata, offset;
> +
> +		/*
> +		 * To calculate the calibration value:
> +		 *
> +		 * X(in Celsius) = Ts - ft_temp
> +		 * delta = X * 10000 / TEMP_TO_REG
> +		 * cdata = CALIBRATE_DEFAULT - delta
> +		 *
> +		 * cdata: calibration value
> +		 */
> +		delta = (sensor_temp - ft_temp * 100) * 10 / TEMP_TO_REG;
> +		cdata = CALIBRATE_DEFAULT - delta;
> +		if (cdata & ~TEMP_CALIB_MASK) {
> +			/*
> +			 * Calibration value more than 12-bit, but calibration
> +			 * register is 12-bit. In this case, ths hardware can
> +			 * still work without calibration, although the data
> +			 * won't be so accurate.
> +			 */
> +			dev_warn(dev, "sensor%d is not calibrated.\n", i);
> +
> +			continue;
> +		}
> +
> +		offset = (i % 2) << 4;
> +		regmap_update_bits(tmdev->regmap,
> +				   SUN50I_H6_THS_TEMP_CALIB + ((i >> 1) * 4),
> +				   0xfff << offset,
> +				   cdata << offset);
> +	}
> +
> +out_free:
> +	kfree(caldata);
> +out:
> +	return ret;
> +}
> +
> +static int sun8i_ths_resource_init(struct ths_device *tmdev)
> +{
> +	struct device *dev = tmdev->dev;
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct resource *mem;
> +	void __iomem *base;
> +	int ret;
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	base = devm_ioremap_resource(dev, mem);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	tmdev->regmap = devm_regmap_init_mmio(dev, base, &config);
> +	if (IS_ERR(tmdev->regmap))
> +		return PTR_ERR(tmdev->regmap);
> +
> +	tmdev->reset = devm_reset_control_get(dev, 0);
> +	if (IS_ERR(tmdev->reset))
> +		return PTR_ERR(tmdev->reset);
> +
> +	tmdev->bus_clk = devm_clk_get(&pdev->dev, "bus");
> +	if (IS_ERR(tmdev->bus_clk))
> +		return PTR_ERR(tmdev->bus_clk);
> +
> +	ret = reset_control_deassert(tmdev->reset);
> +	if (ret)
> +		return ret;
> +
> +	ret = clk_prepare_enable(tmdev->bus_clk);
> +	if (ret)
> +		goto assert_reset;
> +
> +	ret = sun50i_ths_calibrate(tmdev);
> +	if (ret)
> +		goto bus_disable;
> +
> +	return 0;
> +
> +bus_disable:
> +	clk_disable_unprepare(tmdev->bus_clk);
> +assert_reset:
> +	reset_control_assert(tmdev->reset);
> +
> +	return ret;
> +}
> +
> +static int sun50i_h6_thermal_init(struct ths_device *tmdev)
> +{
> +	int val;
> +
> +	/*
> +	 * clkin = 24MHz
> +	 * T acquire = clkin / (x + 1)
> +	 *           = 20us
> +	 */

I suggest something along the lines of:

        /*                                                                                                                                                                                             
         * T_acq = 20us                                                                                                                                                                                
         * clkin = 24MHz                                                                                                                                                                               
         *                                                                                                                                                                                             
         * x = T_acq * clkin - 1                                                                                                                                                                       
         *   = 479                                                                                                                                                                                     
         */       

Makes it much more clear how the value in SUN50I_THS_CTRL0_T_ACQ was
arrived at and how to calculate a new one.

> +	regmap_write(tmdev->regmap, SUN50I_THS_CTRL0,
> +		     SUN50I_THS_CTRL0_T_ACQ(479));
> +	/* average over 4 samples */
> +	regmap_write(tmdev->regmap, SUN50I_H6_THS_MFC,
> +		     SUN50I_THS_FILTER_EN |
> +		     SUN50I_THS_FILTER_TYPE(1));
> +	/* period = (x + 1) * 4096 / clkin; ~10ms */

As above, here I suggest:

        /*
         * clkin = 24MHz
         * filter_samples = 4
         * period = 0.25s
         *
         * x = period * clkin / 4096 / filter_samples - 1
         *   = 365
         */

Also please change this to 365 from 58. I think 4 readings per second are
enough. Certainly, 25 are a bit too much.

> +	regmap_write(tmdev->regmap, SUN50I_H6_THS_PC,
> +		     SUN50I_H6_THS_PC_TEMP_PERIOD(58));
> +	/* enable sensor */
> +	val = GENMASK(SUN50I_H6_SENSOR_NUM - 1, 0);
> +	regmap_write(tmdev->regmap, SUN50I_H6_THS_ENABLE, val);
> +	/* thermal data interrupt enable */
> +	val = GENMASK(SUN50I_H6_SENSOR_NUM - 1, 0);
> +	regmap_write(tmdev->regmap, SUN50I_H6_THS_DIC, val);
> +
> +	return 0;
> +}
> +
> +static int sun8i_ths_register(struct ths_device *tmdev)
> +{
> +	struct thermal_zone_device *tzd;
> +	int i;
> +
> +	for (i = 0; i < SUN50I_H6_SENSOR_NUM; i++) {
> +		tmdev->sensor[i].tmdev = tmdev;
> +		tmdev->sensor[i].id = i;
> +		tmdev->sensor[i].tzd =
> +			devm_thermal_zone_of_sensor_register(tmdev->dev,
> +							     i,
> +							     &tmdev->sensor[i],
> +							     &ths_ops);
> +		if (IS_ERR(tmdev->sensor[i].tzd))
> +			return PTR_ERR(tzd);

This should return PTR_ERR(tmdev->sensor[i].tzd). Otherwise this succeeds even
if tz registration fails, and you get NULL pointer exception tryin to udpate
nonexisting tz from the interrupt handler.

regards,
	Ondrej

> +	}
> +
> +	return 0;
> +}
> +
> +static int sun8i_ths_probe(struct platform_device *pdev)
> +{
> +	struct ths_device *tmdev;
> +	struct device *dev = &pdev->dev;
> +	int ret, irq;
> +
> +	tmdev = devm_kzalloc(dev, sizeof(*tmdev), GFP_KERNEL);
> +	if (!tmdev)
> +		return -ENOMEM;
> +
> +	tmdev->dev = dev;
> +	platform_set_drvdata(pdev, tmdev);
> +
> +	ret = sun8i_ths_resource_init(tmdev);
> +	if (ret)
> +		return ret;
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0)
> +		return irq;
> +
> +	ret = sun50i_h6_thermal_init(tmdev);
> +	if (ret)
> +		return ret;
> +
> +	ret = sun8i_ths_register(tmdev);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * Avoid entering the interrupt handler, the thermal device is not
> +	 * registered yet, we deffer the registration of the interrupt to
> +	 * the end.
> +	 */
> +	ret = devm_request_threaded_irq(dev, irq, NULL,
> +					sun50i_h6_irq_thread,
> +					IRQF_ONESHOT, "ths", tmdev);
> +	if (ret)
> +		return ret;
> +
> +	return ret;
> +}
> +
> +static int sun8i_ths_remove(struct platform_device *pdev)
> +{
> +	struct ths_device *tmdev = platform_get_drvdata(pdev);
> +
> +	clk_disable_unprepare(tmdev->bus_clk);
> +	reset_control_assert(tmdev->reset);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id of_ths_match[] = {
> +	{ .compatible = "allwinner,sun50i-h6-ths"},
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, of_ths_match);
> +
> +static struct platform_driver ths_driver = {
> +	.probe = sun8i_ths_probe,
> +	.remove = sun8i_ths_remove,
> +	.driver = {
> +		.name = "sun8i-thermal",
> +		.of_match_table = of_ths_match,
> +	},
> +};
> +module_platform_driver(ths_driver);
> +
> +MODULE_DESCRIPTION("Thermal sensor driver for Allwinner SOC");
> +MODULE_LICENSE("GPL v2");
> -- 
> 2.17.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
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 1/1] arm64: dts: rockchip: Add support for TB-96AI board
From: Heiko Stuebner @ 2019-09-01  4:36 UTC (permalink / raw)
  To: Elon Zhang
  Cc: mark.rutland, devicetree, linux-kernel, linux-rockchip, robh+dt,
	manivannan.sadhasivam, linux-arm-kernel
In-Reply-To: <20190805015755.26017-1-zhangzj@rock-chips.com>

Hi Elon,

Am Montag, 5. August 2019, 03:57:55 CEST schrieb Elon Zhang:
> Add devicetree support for RK3399Pro TB-96AI board, one of
> the 96Boards family.
> 
> The TB-96AI board is a 96Boards Compute SOM design, launched
> by Linaro, Rockchip and Beiqicloud.
> 
> More information can be obtained from the following websites:
> 1.https://www.96boards.org/product/tb-96ai/
> 2.http://t.rock-chips.com/
> 3.http://www.beiqicloud.com/
> 
> This patch add basic node for the board and support booting up
> to Fedora.
> 
> Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
> ---
> changes since v1:
> - remove needless node
> - using a standard LED formats for 96Boards
> 
>  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>  .../boot/dts/rockchip/rk3399pro-tb-96ai.dts   | 560 ++++++++++++++++++
>  2 files changed, 561 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 5f2687acbf94..3d6c8d4363b5 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -27,3 +27,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-tb-96ai.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
> new file mode 100644
> index 000000000000..767b37b854ba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
> @@ -0,0 +1,560 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
> + */
> +
> +/dts-v1/;
> +#include "rk3399pro.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> +	compatible = "beiqi,rk3399pro-tb-96ai", "rockchip,rk3399pro";
> +
> +	chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	xin32k: xin32k {
> +		compatible = "fixed-clock";
> +		clock-frequency = <32768>;
> +		clock-output-names = "xin32k";
> +		#clock-cells = <0>;
> +	};

I would guess this 32kHz clock does originate from the rk809 below?
If so please simply adjust the clock-output-names in it, so that
it sources correctly.

> +
> +	vcc5v0_sys: vccsys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +	};

Please always try to construct a full regulator tree.
(see debugfs/regulator/regulator_summary)

Part of me doesn't want to believe that vcc5v0_sys is
the root regulator getting the outside power supply ;-) .


> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&work_led1>,<&work_led2>,<&work_led3>;
> +
> +		work_led1 {
> +			gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> +			label = "system_work_led1";
> +			retain-state-suspended;
> +		};
> +
> +		work_led2 {
> +			gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
> +			label = "system_work_led2";
> +			retain-state-suspended;
> +		};
> +
> +		work_led3 {
> +			gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
> +			label = "system_work_led3";
> +			retain-state-suspended;
> +		};
> +	};
> +};
> +
> +&cpu_l0 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l1 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l2 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l3 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_b0 {
> +	cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&cpu_b1 {
> +	cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&emmc_phy {
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	status = "okay";
> +	i2c-scl-rising-time-ns = <180>;
> +	i2c-scl-falling-time-ns = <30>;
> +	clock-frequency = <400000>;
> +
> +	rk809: pmic@20 {
> +		compatible = "rockchip,rk809";
> +		reg = <0x20>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <RK_PC2 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default", "pmic-sleep",
> +				"pmic-power-off", "pmic-reset";
> +		pinctrl-0 = <&pmic_int_l>;
> +		pinctrl-1 = <&soc_slppin_slp>, <&rk809_slppin_slp>;
> +		pinctrl-2 = <&soc_slppin_gpio>, <&rk809_slppin_pwrdn>;
> +		pinctrl-3 = <&soc_slppin_gpio>,<&rk809_slppin_null>;
> +		rockchip,system-power-controller;
> +		pmic-reset-func = <1>;

That is not part of the binding I think

> +		wakeup-source;
> +		#clock-cells = <1>;
> +		clock-output-names = "rk808-clkout1", "rk808-clkout2";
> +
> +		vcc1-supply = <&vcc5v0_sys>;
> +		vcc2-supply = <&vcc5v0_sys>;
> +		vcc3-supply = <&vcc5v0_sys>;
> +		vcc4-supply = <&vcc5v0_sys>;
> +		vcc5-supply = <&vcc_buck5>;
> +		vcc6-supply = <&vcc_buck5>;
> +		vcc7-supply = <&vcc3v3_sys>;
> +		vcc8-supply = <&vcc3v3_sys>;
> +		vcc9-supply = <&vcc5v0_sys>;
> +
> +		pwrkey {
> +			status = "okay";
> +		};
> +
> +		rtc {
> +			status = "okay";
> +		};

There is no binding for either pwrkey nor rtc subnodes and
I think the rtc device is just created  in any case, so you should just
drop these nodes.


> +		pinctrl_rk8xx: pinctrl_rk8xx {
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +
> +			rk809_slppin_null: rk809_slppin_null {
> +				pins = "gpio_slp";
> +				function = "pin_fun0";
> +			};
> +
> +			rk809_slppin_slp: rk809_slppin_slp {
> +				pins = "gpio_slp";
> +				function = "pin_fun1";
> +			};
> +
> +			rk809_slppin_pwrdn: rk809_slppin_pwrdn {
> +				pins = "gpio_slp";
> +				function = "pin_fun2";
> +			};
> +
> +			rk809_slppin_rst: rk809_slppin_rst {
> +				pins = "gpio_slp";
> +				function = "pin_fun3";
> +			};
> +		};

There is a binding for rk805 pinctrl, but it looks way different than this.
Please adapt and if necessary submit binding+code for rk809 first.

See Documentation/devicetree/bindings/pinctrl/pinctrl-rk805.txt
for reference.


> +		regulators {
> +			vdd_center: DCDC_REG1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vdd_center";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <900000>;
> +				};
> +			};
> +
> +			vdd_cpu_l: DCDC_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <750000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vdd_cpu_l";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_ddr: DCDC_REG3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-name = "vcc_ddr";
> +				regulator-initial-mode = <0x2>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc3v3_sys: DCDC_REG4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vcc3v3_sys";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3300000>;
> +				};
> +			};
> +
> +			vcc_buck5: DCDC_REG5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <2200000>;
> +				regulator-max-microvolt = <2200000>;
> +				regulator-name = "vcc_buck5";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <2200000>;
> +				};
> +			};
> +
> +			vcca_0v9: LDO_REG1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-name = "vcca_0v9";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8: LDO_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +
> +				regulator-name = "vcc_1v8";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vcc0v9_soc: LDO_REG3 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +
> +				regulator-name = "vcc0v9_soc";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <900000>;
> +				};
> +			};
> +
> +			vcca_1v8: LDO_REG4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +
> +				regulator-name = "vcca_1v8";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd1v5_dvp: LDO_REG5 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1500000>;
> +				regulator-max-microvolt = <1500000>;
> +
> +				regulator-name = "vdd1v5_dvp";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v5: LDO_REG6 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1500000>;
> +				regulator-max-microvolt = <1500000>;
> +
> +				regulator-name = "vcc_1v5";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_3v0: LDO_REG7 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3000000>;
> +				regulator-max-microvolt = <3000000>;
> +
> +				regulator-name = "vcc_3v0";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vccio_sd: LDO_REG8 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +
> +				regulator-name = "vccio_sd";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3300000>;
> +				};
> +			};
> +
> +			vcc_sd: LDO_REG9 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +
> +				regulator-name = "vcc_sd";
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3300000>;
> +				};
> +			};
> +
> +			vcc5v0_usb: SWITCH_REG1 {
> +				regulator-min-microvolt = <5000000>;
> +				regulator-max-microvolt = <5000000>;
> +
> +				regulator-name = "vcc5v0_usb";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vccio_3v3: SWITCH_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +
> +				regulator-name = "vccio_3v3";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +	};
> +
> +	vdd_cpu_b: regulator@1c {
> +		compatible = "fcs,fan53555";
> +		reg = <0x1c>;
> +		vin-supply = <&vcc5v0_sys>;
> +		pinctrl-0 = <&vsel1_gpio>;
> +		vsel-gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;

I don't think there is a vsel-gpios propety specified yet and the
fan53555 driver cannot handle that pin yet.
You could change that ;-)

> +		regulator-name = "vdd_cpu_b";
> +		regulator-min-microvolt = <712500>;
> +		regulator-max-microvolt = <1500000>;
> +		regulator-ramp-delay = <2300>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-initial-state = <3>;
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vdd_gpu: regulator@10 {
> +		compatible = "fcs,fan53555";
> +		status = "okay";
> +		reg = <0x10>;
> +		vin-supply = <&vcc5v0_sys>;
> +		pinctrl-0 = <&vsel2_gpio>;
> +		vsel-gpios = <&gpio1 RK_PB6 GPIO_ACTIVE_HIGH>;
> +		regulator-name = "vdd_gpu";
> +		regulator-min-microvolt = <735000>;
> +		regulator-max-microvolt = <1400000>;
> +		regulator-ramp-delay = <2300>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c8 {
> +	status = "okay";
> +	i2c-scl-rising-time-ns = <345>;
> +	i2c-scl-falling-time-ns = <11>;
> +	clock-frequency = <100000>;
> +};
> +
> +&io_domains {
> +	status = "okay";
> +	bt656-supply = <&vcca_1v8>; /* APIO2_VDD */
> +	audio-supply = <&vcca_1v8>; /* APIO5_VDD */
> +	sdmmc-supply = <&vccio_sd>; /* SDMMC0_VDD */
> +	gpio1830-supply = <&vcc_1v8>; /* APIO4_VDD */
> +};
> +
> +&pinctrl {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&npu_ref_clk>;
> +
> +	leds {
> +		work_led1: work_led1 {
> +			rockchip,pins =
> +				<2 5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		work_led2: work_led2 {
> +			rockchip,pins =
> +				<2 4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		work_led3: work_led3 {
> +			rockchip,pins =
> +				<2 3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	npu_clk {
> +		npu_ref_clk: npu-ref-clk {
> +			rockchip,pins =
> +				<0 RK_PA2 1 &pcfg_pull_none>;
> +		};
> +	};
> +
> +	pmic {
> +		pmic_int_l: pmic-int-l {
> +			rockchip,pins =
> +				<1 RK_PC2 0 &pcfg_pull_up>;
> +		};
> +
> +		soc_slppin_gpio: soc-slppin-gpio {
> +			rockchip,pins =
> +				<1 RK_PA5 0 &pcfg_output_low>;
> +		};
> +
> +		soc_slppin_slp: soc-slppin-slp {
> +			rockchip,pins =
> +				<1 RK_PA5 1 &pcfg_pull_down>;
> +		};
> +
> +		vsel1_gpio: vsel1-gpio {
> +			rockchip,pins =
> +				<1 RK_PC1 0 &pcfg_pull_down>;
> +		};
> +
> +		vsel2_gpio: vsel2-gpio {
> +			rockchip,pins =
> +				<1 RK_PB6 0 &pcfg_pull_down>;
> +		};
> +	};
> +
> +	usb3 {
> +		usb3_host_en: usb3-host-en {
> +			rockchip,pins =
> +				<2 RK_PA2 RK_FUNC_GPIO &pcfg_output_high>;
> +		};
> +	};
> +};
> +
> +&pmu_io_domains {
> +	status = "okay";
> +	pmu1830-supply = <&vcc_1v8>;
> +};
> +
> +&pwm0 {
> +	status = "okay";
> +};
> +
> +&pwm2 {
> +	status = "okay";
> +};
> +
> +&saradc {
> +	status = "okay";
> +	vref-supply = <&vcc_1v8>;
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	mmc-hs400-1_8v;
> +	non-removable;
> +	keep-power-in-suspend;
> +	mmc-hs400-enhanced-strobe;
> +	status = "okay";
> +};
> +
> +&tcphy1 {
> +	status = "okay";
> +};
> +
> +&tsadc {
> +	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
> +	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> +	status = "okay";
> +};
> +
> +&u2phy1 {
> +	status = "okay";
> +
> +	u2phy1_otg: otg-port {
> +		status = "okay";
> +	};
> +
> +	u2phy1_host: host-port {
> +		phy-supply = <&vcc5v0_usb>;
> +		status = "okay";
> +	};
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_xfer &uart0_cts>;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&uart4 {
> +	status = "okay";
> +};
> +
> +&usb_host0_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host1_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host0_ohci {
> +	status = "okay";
> +};
> +
> +&usb_host1_ohci {
> +	status = "okay";
> +};
> +
> +&usbdrd3_1 {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb3_host_en>;
> +};
> +
> +&usbdrd_dwc3_0 {
> +	status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> +	snps,dis-u3-autosuspend-quirk;

This property is neither part of the dwc3 driver,
nor the dwc3 devicetree binding.

> +	status = "okay";
> +};
> +
> 


Heiko



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

^ permalink raw reply

* [GIT PULL] Qualcomm ARM64 Defconfig updates for 5.4
From: Andy Gross @ 2019-09-01  5:54 UTC (permalink / raw)
  To: arm
  Cc: Arnd Bergmann, linux-arm-msm, Bjorn Andersson, Kevin Hilman,
	Olof Johansson, linux-arm-kernel

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/qcom/linux.git tags/qcom-arm64-defconfig-for-5.4

for you to fetch changes up to fcee7de608a2e4cb3481fd224b11242427d8ec28:

  arm64: defconfig: Enable CPU clock drivers for Qualcomm msm8916 (2019-09-01 00:42:53 -0500)

----------------------------------------------------------------
Qualcomm ARM64 Based defconfig Updates for v5.4

* Enable Qualcomm MSM8916 clock drivers
* Add DRM_MSM to ARCH_QCOM defconfigs
* Enable Qualcomm SM8150 clock and pinctrl drivers

----------------------------------------------------------------
Jordan Crouse (1):
      arm64: defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM

Marc Gonzalez (1):
      arm64: defconfig: Enable CPU clock drivers for Qualcomm msm8916

Vinod Koul (1):
      arm64: defconfig: Enable SM8150 GCC and pinctrl driver

 arch/arm64/configs/defconfig | 5 +++++
 1 file changed, 5 insertions(+)

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

^ permalink raw reply

* [GIT PULL] Qualcomm ARM64 DT updates for 5.4
From: Andy Gross @ 2019-09-01  5:54 UTC (permalink / raw)
  To: arm
  Cc: Arnd Bergmann, linux-arm-msm, Bjorn Andersson, Kevin Hilman,
	Olof Johansson, linux-arm-kernel
In-Reply-To: <1567317285-8555-1-git-send-email-agross@kernel.org>

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/qcom/linux.git tags/qcom-arm64-for-5.4

for you to fetch changes up to 1dd70853f8131f1674c4496b1d24de7251cad42c:

  arm64: dts: sdm845: Add parent clock for rpmhcc (2019-08-26 17:43:23 -0700)

----------------------------------------------------------------
Qualcomm ARM64 Updates for v5.4

* Add Lenovo Miix 630, HP Envy x2, and Asus Novago TP370QL support
* Assorted cleanups for SDM845 nodes
* Add video nodes, cpu coefficients, adsp, csdp, and
  fastrpc nodes for SDM845
* Add coresight for MSM8996, SDM845, and MSM8998
* Misc cleanups on QCS404 and PMS405
* Update memory map for QCS404
* Add wifi rails, update WCSS clocks, and add ADS unit names on QCS404
* Add Longcheer and Samsung Galaxy A3U/A5U support
* Add initial support for SM8150 and PM8150

----------------------------------------------------------------
Bjorn Andersson (3):
      arm64: dts: qcom: msm8996: Rename smmu nodes
      arm64: dts: qcom: qcs404-evb: Mark WCSS clocks protected
      arm64: dts: qcom: qcs404: Update memory map to v3

Geert Uytterhoeven (1):
      arm64: dts: qcom: sdm845-cheza: Spelling s/conenctors/connectors/

Govind Singh (1):
      arm64: dts: qcom: qcs404: Add wifi rails in QCS404 dt node for proxy votes

Jeffrey Hugo (4):
      arm64: dts: qcom: Add Lenovo Miix 630
      arm64: dts: qcom: Add HP Envy x2
      arm64: dts: qcom: Add Asus NovaGo TP370QL
      arm64: dts: qcom: msm8998: Node ordering, address cleanups

Malathi Gottam (1):
      arm64: dts: sdm845: Add video nodes

Matthias Kaehlcke (1):
      arm64: dts: sdm845: Add dynamic CPU power coefficients

Sai Prakash Ranjan (3):
      arm64: dts: sdm845: Add device node for Last level cache controller
      arm64: dts: qcom: sdm845: Add Coresight support
      arm64: dts: qcom: msm8998: Add Coresight support

Srinivas Kandagatla (1):
      arm64: sdm845: add adsp and cdsp fastrpc nodes

Stanimir Varbanov (1):
      arm64: dts: qcom: msm8996: Add Venus video codec DT node

Stephan Gerhold (4):
      dt-bindings: vendor-prefixes: Add Longcheer Technology Co., Ltd.
      dt-bindings: qcom: Document bindings for new MSM8916 devices
      arm64: dts: qcom: Add device tree for Samsung Galaxy A3U/A5U
      arm64: dts: qcom: Add device tree for Longcheer L8150

Thara Gopinath (1):
      arm64: dts: qcom: Extend AOSS QMP node

Vinod Koul (17):
      arm64: dts: qcom: sdm845: Add unit name to soc node
      arm64: dts: qcom: sdm845: remove unnecessary properties for dsi nodes
      arm64: dts: qcom: sdm845: remove unit name for thermal trip points
      arm64: dts: qcom: sdm845-cheza: remove macro from unit name
      arm64: dts: qcom: sdm845: remove macro from unit name
      arm64: dts: qcom: pms405: add unit name adc nodes
      arm64: dts: qcom: pms405: remove reduandant properties
      arm64: dts: qcom: qcs404: remove unit name for thermal trip points
      arm64: dts: qcom: sm8150: Add base dts file
      arm64: dts: qcom: pm8150: Add base dts file
      arm64: dts: qcom: pm8150b: Add base dts file
      arm64: dts: qcom: pm8150l: Add base dts file
      arm64: dts: qcom: sm8150-mtp: Add base dts file
      arm64: dts: qcom: sm8150-mtp: Add regulators
      arm64: dts: qcom: sm8150: Add reserved-memory regions
      arm64: dts: qcom: sm8150: Add apps shared nodes
      arm64: dts: sdm845: Add parent clock for rpmhcc

Vivek Gautam (1):
      arm64: dts: qcom: msm8996: Add Coresight support

 Documentation/devicetree/bindings/arm/qcom.yaml    |   8 +
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 arch/arm64/boot/dts/qcom/Makefile                  |   7 +
 .../boot/dts/qcom/msm8916-longcheer-l8150.dts      | 228 +++++++
 .../dts/qcom/msm8916-samsung-a2015-common.dtsi     | 236 +++++++
 .../boot/dts/qcom/msm8916-samsung-a3u-eur.dts      |  10 +
 .../boot/dts/qcom/msm8916-samsung-a5u-eur.dts      |  10 +
 arch/arm64/boot/dts/qcom/msm8996.dtsi              | 544 +++++++++++++++-
 .../boot/dts/qcom/msm8998-asus-novago-tp370ql.dts  |  47 ++
 arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi    | 240 +++++++
 arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dts    |  30 +
 .../boot/dts/qcom/msm8998-lenovo-miix-630.dts      |  30 +
 arch/arm64/boot/dts/qcom/msm8998.dtsi              | 689 +++++++++++++++++----
 arch/arm64/boot/dts/qcom/pm8150.dtsi               |  97 +++
 arch/arm64/boot/dts/qcom/pm8150b.dtsi              |  86 +++
 arch/arm64/boot/dts/qcom/pm8150l.dtsi              |  80 +++
 arch/arm64/boot/dts/qcom/pm8998.dtsi               |   2 +-
 arch/arm64/boot/dts/qcom/pms405.dtsi               |  16 +-
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi           |   7 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi               |  60 +-
 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi         |  12 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi               | 646 +++++++++++++++++--
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts            | 375 +++++++++++
 arch/arm64/boot/dts/qcom/sm8150.dtsi               | 482 ++++++++++++++
 24 files changed, 3735 insertions(+), 209 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-samsung-a3u-eur.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-samsung-a5u-eur.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dts
 create mode 100644 arch/arm64/boot/dts/qcom/pm8150.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8150b.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8150l.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sm8150-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sm8150.dtsi

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

^ permalink raw reply

* [GIT PULL] Qualcomm Defconfig updates for 5.4
From: Andy Gross @ 2019-09-01  5:54 UTC (permalink / raw)
  To: arm
  Cc: Arnd Bergmann, linux-arm-msm, Bjorn Andersson, Kevin Hilman,
	Olof Johansson, linux-arm-kernel
In-Reply-To: <1567317285-8555-1-git-send-email-agross@kernel.org>

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/qcom/linux.git tags/qcom-defconfig-for-5.4

for you to fetch changes up to 1cd3e52a07b86cf03079e05968d1a2641b6261c4:

  ARM: multi_v7_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM (2019-09-01 00:37:54 -0500)

----------------------------------------------------------------
Qualcomm ARM Based defconfig Updates for v5.4

* Add DRM_MSM to ARCH_QCOM defconfigs

----------------------------------------------------------------
Andy Gross (1):
      ARM: multi_v7_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM

Jordan Crouse (1):
      ARM: qcom_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM

 arch/arm/configs/multi_v7_defconfig | 1 +
 arch/arm/configs/qcom_defconfig     | 1 +
 2 files changed, 2 insertions(+)

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

^ permalink raw reply

* [GIT PULL] Qualcomm Driver updates for 5.4
From: Andy Gross @ 2019-09-01  5:54 UTC (permalink / raw)
  To: arm
  Cc: Arnd Bergmann, linux-arm-msm, Bjorn Andersson, Kevin Hilman,
	Olof Johansson, linux-arm-kernel
In-Reply-To: <1567317285-8555-1-git-send-email-agross@kernel.org>

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/qcom/linux.git tags/qcom-drivers-for-5.4

for you to fetch changes up to 1709510221c57fd566479c228434ff9edd6435be:

  soc: qcom: aoss: Add AOSS QMP support (2019-08-21 15:59:44 -0700)

----------------------------------------------------------------
Qualcomm ARM Based Driver Updates for v5.4

* Add AOSS QMP support
* Various fixups for Qualcomm SCM
* Add socinfo driver
* Add SoC serial number attribute and associated APIs
* Add SM8150 and SC7180 support in Qualcomm SCM
* Fixup max processor count in SMEM

----------------------------------------------------------------
Bjorn Andersson (2):
      base: soc: Add serial_number attribute to soc
      soc: qcom: socinfo: Annotate switch cases with fall through

Imran Khan (1):
      soc: qcom: Add socinfo driver

Sibi Sankar (5):
      soc: qcom: smem: Update max processor count
      dt-bindings: firmware: scm: re-order compatible list
      dt-bindings: firmware: scm: Add SM8150 and SC7180 support
      dt-bindings: soc: qcom: aoss: Add SM8150 and SC7180 support
      soc: qcom: aoss: Add AOSS QMP support

Stephen Boyd (3):
      firmware: qcom_scm: Use proper types for dma mappings
      firmware: qcom_scm: Fix some typos in docs and printks
      firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem()

Thara Gopinath (1):
      soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.

Vaishali Thakkar (2):
      soc: qcom: socinfo: Expose custom attributes
      soc: qcom: socinfo: Expose image information

Vinod Koul (1):
      base: soc: Export soc_device_register/unregister APIs

 Documentation/ABI/testing/sysfs-devices-soc        |   7 +
 .../devicetree/bindings/firmware/qcom,scm.txt      |   4 +-
 .../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt |   5 +-
 drivers/base/soc.c                                 |   9 +
 drivers/firmware/qcom_scm.c                        |  47 +-
 drivers/soc/qcom/Kconfig                           |   8 +
 drivers/soc/qcom/Makefile                          |   1 +
 drivers/soc/qcom/qcom_aoss.c                       | 133 ++++++
 drivers/soc/qcom/smem.c                            |  11 +-
 drivers/soc/qcom/socinfo.c                         | 476 +++++++++++++++++++++
 include/linux/qcom_scm.h                           |   9 +-
 include/linux/sys_soc.h                            |   1 +
 12 files changed, 681 insertions(+), 30 deletions(-)
 create mode 100644 drivers/soc/qcom/socinfo.c

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

^ permalink raw reply

* [PATCH v5 3/3] PCI: layerscape: Add LS1028a support
From: Xiaowei Bao @ 2019-09-01  7:41 UTC (permalink / raw)
  To: robh+dt, mark.rutland, shawnguo, leoyang.li, minghuan.Lian,
	mingkai.hu, roy.zang, lorenzo.pieralisi, linux-pci, devicetree,
	linux-kernel, linux-arm-kernel, linuxppc-dev
  Cc: bhelgaas, Hou Zhiqiang, Xiaowei Bao
In-Reply-To: <20190901074134.24455-1-xiaowei.bao@nxp.com>

Add support for the LS1028a PCIe controller.

Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
v2:
 - No change.
v3:
 - Reuse the ls2088 driver data structurt.
v4:
 - No change.
v5:
 - No change.

 drivers/pci/controller/dwc/pci-layerscape.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 3a5fa26..f24f79a 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -263,6 +263,7 @@ static const struct ls_pcie_drvdata ls2088_drvdata = {
 static const struct of_device_id ls_pcie_of_match[] = {
 	{ .compatible = "fsl,ls1012a-pcie", .data = &ls1046_drvdata },
 	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
+	{ .compatible = "fsl,ls1028a-pcie", .data = &ls2088_drvdata },
 	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
 	{ .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
 	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
-- 
2.9.5


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

^ permalink raw reply related

* [PATCH v5 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl, ls1028a-pcie"
From: Xiaowei Bao @ 2019-09-01  7:41 UTC (permalink / raw)
  To: robh+dt, mark.rutland, shawnguo, leoyang.li, minghuan.Lian,
	mingkai.hu, roy.zang, lorenzo.pieralisi, linux-pci, devicetree,
	linux-kernel, linux-arm-kernel, linuxppc-dev
  Cc: bhelgaas, Hou Zhiqiang, Xiaowei Bao

Add the PCIe compatible string for LS1028A

Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v2:
 - No change.
v3:
 - No change.
v4:
 - No change.
v5:
 - No change.

 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index e20ceaa..99a386e 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -21,6 +21,7 @@ Required properties:
         "fsl,ls1046a-pcie"
         "fsl,ls1043a-pcie"
         "fsl,ls1012a-pcie"
+        "fsl,ls1028a-pcie"
   EP mode:
 	"fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
 - reg: base addresses and lengths of the PCIe controller register blocks.
-- 
2.9.5


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

^ permalink raw reply related

* [PATCH v5 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
From: Xiaowei Bao @ 2019-09-01  7:41 UTC (permalink / raw)
  To: robh+dt, mark.rutland, shawnguo, leoyang.li, minghuan.Lian,
	mingkai.hu, roy.zang, lorenzo.pieralisi, linux-pci, devicetree,
	linux-kernel, linux-arm-kernel, linuxppc-dev
  Cc: bhelgaas, Hou Zhiqiang, Xiaowei Bao
In-Reply-To: <20190901074134.24455-1-xiaowei.bao@nxp.com>

LS1028a implements 2 PCIe 3.0 controllers.

Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
v2:
 - Fix up the legacy INTx allocate failed issue.
v3:
 - No change.
v4:
 - Remove the num-lanes property.
v5:
 - Add the num-viewport property.

 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52 ++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 72b9a75..c043b1d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -625,6 +625,58 @@
 			};
 		};
 
+		pcie@3400000 {
+			compatible = "fsl,ls1028a-pcie";
+			reg = <0x00 0x03400000 0x0 0x00100000   /* controller registers */
+			       0x80 0x00000000 0x0 0x00002000>; /* configuration space */
+			reg-names = "regs", "config";
+			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */
+			interrupt-names = "pme", "aer";
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			num-viewport = <6>;
+			bus-range = <0x0 0xff>;
+			ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000   /* downstream I/O */
+				  0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+			msi-parent = <&its>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		pcie@3500000 {
+			compatible = "fsl,ls1028a-pcie";
+			reg = <0x00 0x03500000 0x0 0x00100000   /* controller registers */
+			       0x88 0x00000000 0x0 0x00002000>; /* configuration space */
+			reg-names = "regs", "config";
+			interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "pme", "aer";
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			num-viewport = <6>;
+			bus-range = <0x0 0xff>;
+			ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0 0x00010000   /* downstream I/O */
+				  0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+			msi-parent = <&its>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 2 &gic 0 0 GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 3 &gic 0 0 GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 4 &gic 0 0 GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
 		pcie@1f0000000 { /* Integrated Endpoint Root Complex */
 			compatible = "pci-host-ecam-generic";
 			reg = <0x01 0xf0000000 0x0 0x100000>;
-- 
2.9.5


_______________________________________________
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: [PATCH 24/26] riscv: use the generic ioremap code
From: Christoph Hellwig @ 2019-09-01  8:02 UTC (permalink / raw)
  To: Paul Walmsley
  Cc: linux-ia64, linux-sh, linux-kernel, Guo Ren, sparclinux,
	linux-riscv, Vincent Chen, Christoph Hellwig, linux-arch,
	linux-s390, linux-hexagon, x86, linux-snps-arc, linux-xtensa,
	Arnd Bergmann, linux-m68k, openrisc, Greentime Hu, nios2-dev,
	Guan Xuetao, linux-arm-kernel, Michal Simek, linux-parisc,
	linux-mips, linux-alpha, linux-mtd
In-Reply-To: <alpine.DEB.2.21.9999.1908171421560.4130@viisi.sifive.com>

On Sat, Aug 17, 2019 at 02:22:15PM -0700, Paul Walmsley wrote:
> Reviewed-by: Paul Walmsley <paul.walmsley@sifive.com>
> Tested-by: Paul Walmsley <paul.walmsley@sifive.com> # rv32, rv64 boot
> Acked-by: Paul Walmsley <paul.walmsley@sifive.com> # arch/riscv

Can you also take a look at the patch adding the generic code?

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

^ permalink raw reply

* Re: [RESEND PATCH 1/1] rtc: sun6i: Allow using as wakeup source from suspend
From: Alexandre Belloni @ 2019-09-01  9:02 UTC (permalink / raw)
  To: Alejandro González
  Cc: linux-rtc, a.zummo, maxime.ripard, linux-sunxi, linux-kernel,
	wens, linux-arm-kernel
In-Reply-To: <20190821210056.11995-1-alejandro.gonzalez.correo@gmail.com>

On 21/08/2019 23:00:56+0200, Alejandro González wrote:
> This patch allows userspace to set up wakeup alarms on any RTC handled by the
> sun6i driver, and adds the necessary PM operations to allow resuming from
> suspend when the configured wakeup alarm fires a IRQ. Of course, that the
> device actually resumes depends on the suspend state and how a particular
> hardware reacts to it, but that is out of scope for this patch.
> 
> I've tested these changes on a Pine H64 model B, which contains a
> Allwinner H6 SoC, with the help of CONFIG_PM_TEST_SUSPEND kernel option.
> These are the interesting outputs from the kernel and commands which
> show that it works. As every RTC handled by this driver is largely the
> same, I think that it shouldn't introduce any regression on other SoCs,
> but I may be wrong.
> 
> [    1.092705] PM: test RTC wakeup from 'freeze' suspend
> [    1.098230] PM: suspend entry (s2idle)
> [    1.212907] PM: suspend devices took 0.080 seconds
> (The SoC freezes for some seconds)
> [    3.197604] PM: resume devices took 0.104 seconds
> [    3.215937] PM: suspend exit
> 
> [    1.092812] PM: test RTC wakeup from 'mem' suspend
> [    1.098089] PM: suspend entry (deep)
> [    1.102033] PM: suspend exit
> [    1.105205] PM: suspend test failed, error -22
> 
> In any case, the RTC alarm interrupt gets fired as exptected:
> 
> $ echo +5 > /sys/class/rtc/rtc0/wakealarm && sleep 5 && grep rtc /proc/interrupts
>  29:          1          0          0          0     GICv2 133 Level     7000000.rtc
> 
> Signed-off-by: Alejandro González <alejandro.gonzalez.correo@gmail.com>
> ---
>  drivers/rtc/rtc-sun6i.c | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
Applied, thanks.

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
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] drm: dw-hdmi-i2s: enable audio clock in audio_startup
From: Jonas Karlman @ 2019-09-01 10:03 UTC (permalink / raw)
  To: Cheng-Yi Chiang, linux-kernel@vger.kernel.org
  Cc: Jernej Skrabec, alsa-devel@alsa-project.org, tzungbi@chromium.org,
	zhengxing@rock-chips.com, kuninori.morimoto.gx@renesas.com,
	linux-rockchip@lists.infradead.org, airlied@linux.ie,
	jeffy.chen@rock-chips.com, dianders@chromium.org,
	dri-devel@lists.freedesktop.org, cain.cai@rock-chips.com,
	Neil Armstrong, a.hajda@samsung.com, eddie.cai@rock-chips.com,
	Laurent.pinchart@ideasonboard.com, daniel@ffwll.ch,
	enric.balletbo@collabora.com, dgreid@chromium.org,
	sam@ravnborg.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190829042957.150929-1-cychiang@chromium.org>

On 2019-08-29 06:29, Cheng-Yi Chiang wrote:
> In the designware databook, the sequence of enabling audio clock and
> setting format is not clearly specified.
> Currently, audio clock is enabled in the end of hw_param ops after
> setting format.
>
> On some monitors, there is a possibility that audio does not come out.
> Fix this by enabling audio clock in audio_startup ops
> before hw_param ops setting format.
>
> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> index 5cbb71a866d5..08b4adbb1ddc 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -69,6 +69,14 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
>  	hdmi_write(audio, conf0, HDMI_AUD_CONF0);
>  	hdmi_write(audio, conf1, HDMI_AUD_CONF1);
>  
> +	return 0;
> +}
> +
> +static int dw_hdmi_i2s_audio_startup(struct device *dev, void *data)
> +{
> +	struct dw_hdmi_i2s_audio_data *audio = data;
> +	struct dw_hdmi *hdmi = audio->hdmi;
> +
>  	dw_hdmi_audio_enable(hdmi);
>  
>  	return 0;
> @@ -105,6 +113,7 @@ static int dw_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
>  }
>  
>  static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
> +	.audio_startup = dw_hdmi_i2s_audio_startup,

A small white space nit, there should be a tab and not space to align the equal sign above.
Also this patch do not cleanly apply to drm-misc-next or linux-next after
fc1ca6e01d0a "drm/bridge: dw-hdmi-i2s: add .get_eld support" was merged.

This patch does fix an issue I have observed on my Rockchip devices where audio would not always
came out after switching between audio streams having different rate and channels parameters.
I used to carry [1] to fix that issue, but this seems like a more sane fix.

[1] https://github.com/Kwiboo/linux-rockchip/commit/4862e4044532b8b480fa3a0faddc197586623808

With above fixed,

Reviewed-by: Jonas Karlman <jonas@kwiboo.se>

Regards,
Jonas

>  	.hw_params	= dw_hdmi_i2s_hw_params,
>  	.audio_shutdown	= dw_hdmi_i2s_audio_shutdown,
>  	.get_dai_id	= dw_hdmi_i2s_get_dai_id,


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

^ permalink raw reply

* [PATCH] iio: adc: meson_saradc: Fix memory allocation order
From: Remi Pommarel @ 2019-09-01 10:54 UTC (permalink / raw)
  To: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald-Stadler, Kevin Hilman
  Cc: Neil Armstrong, Martin Blumenstingl, Elie Roudninski,
	linux-kernel, linux-iio, Remi Pommarel, linux-amlogic,
	linux-arm-kernel

meson_saradc's irq handler uses priv->regmap so make sure that it is
allocated before the irq get enabled.

This also fixes crash when CONFIG_DEBUG_SHIRQ is enabled, as device
managed resources are freed in the inverted order they had been
allocated, priv->regmap was freed before the spurious fake irq that
CONFIG_DEBUG_SHIRQ adds called the handler.

Reported-by: Elie Roudninski <xademax@gmail.com>
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
---
 drivers/iio/adc/meson_saradc.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 7b28d045d271..7b27306330a3 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -1219,6 +1219,11 @@ static int meson_sar_adc_probe(struct platform_device *pdev)
 	if (IS_ERR(base))
 		return PTR_ERR(base);
 
+	priv->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+					     priv->param->regmap_config);
+	if (IS_ERR(priv->regmap))
+		return PTR_ERR(priv->regmap);
+
 	irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
 	if (!irq)
 		return -EINVAL;
@@ -1228,11 +1233,6 @@ static int meson_sar_adc_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	priv->regmap = devm_regmap_init_mmio(&pdev->dev, base,
-					     priv->param->regmap_config);
-	if (IS_ERR(priv->regmap))
-		return PTR_ERR(priv->regmap);
-
 	priv->clkin = devm_clk_get(&pdev->dev, "clkin");
 	if (IS_ERR(priv->clkin)) {
 		dev_err(&pdev->dev, "failed to get clkin\n");
-- 
2.20.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

* [PATCH] PCI: Remove unused includes and superfluous struct declaration
From: Krzysztof Wilczynski @ 2019-09-01 11:25 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: devicetree, Lorenzo Pieralisi, Jingoo Han, Joerg Roedel,
	linux-pci, linux-kernel, iommu, Rob Herring, Thomas Petazzoni,
	Gustavo Pimentel, Frank Rowand, linux-arm-kernel

Remove <linux/pci.h> and <linux/msi.h> from being included
directly as part of the include/linux/of_pci.h, and remove
superfluous declaration of struct of_phandle_args.

Move users of include <linux/of_pci.h> to include <linux/pci.h>
and <linux/msi.h> directly rather than rely on both being
included transitively through <linux/of_pci.h>.

Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
---
 drivers/iommu/of_iommu.c                          | 2 ++
 drivers/pci/controller/dwc/pcie-designware-host.c | 1 +
 drivers/pci/controller/pci-aardvark.c             | 1 +
 drivers/pci/pci.c                                 | 1 +
 drivers/pci/probe.c                               | 1 +
 include/linux/of_pci.h                            | 4 +---
 6 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 614a93aa5305..026ad2b29dcd 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -8,6 +8,8 @@
 #include <linux/export.h>
 #include <linux/iommu.h>
 #include <linux/limits.h>
+#include <linux/pci.h>
+#include <linux/msi.h>
 #include <linux/of.h>
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index d3156446ff27..7a9bef993e57 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -10,6 +10,7 @@
 
 #include <linux/irqchip/chained_irq.h>
 #include <linux/irqdomain.h>
+#include <linux/msi.h>
 #include <linux/of_address.h>
 #include <linux/of_pci.h>
 #include <linux/pci_regs.h>
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index fc0fe4d4de49..3a05f6ca95b0 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -16,6 +16,7 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 #include <linux/platform_device.h>
+#include <linux/msi.h>
 #include <linux/of_address.h>
 #include <linux/of_pci.h>
 
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 484e35349565..571e7e00984b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -13,6 +13,7 @@
 #include <linux/delay.h>
 #include <linux/dmi.h>
 #include <linux/init.h>
+#include <linux/msi.h>
 #include <linux/of.h>
 #include <linux/of_pci.h>
 #include <linux/pci.h>
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 169943f17a4c..11b11a652d18 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -7,6 +7,7 @@
 #include <linux/delay.h>
 #include <linux/init.h>
 #include <linux/pci.h>
+#include <linux/msi.h>
 #include <linux/of_device.h>
 #include <linux/of_pci.h>
 #include <linux/pci_hotplug.h>
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 21a89c4880fa..7929b4c0e886 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -2,11 +2,9 @@
 #ifndef __OF_PCI_H
 #define __OF_PCI_H
 
-#include <linux/pci.h>
-#include <linux/msi.h>
+#include <linux/types.h>
 
 struct pci_dev;
-struct of_phandle_args;
 struct device_node;
 
 #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_PCI)
-- 
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 related


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