LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v3 05/16] dt-bindings: usb: usb-hcd: Add generic "usb-phy" property
From: Martin Blumenstingl @ 2020-10-20 19:34 UTC (permalink / raw)
  To: Serge Semin
  Cc: Neil Armstrong, Bjorn Andersson, Pavel Parkhomenko, Rob Herring,
	Kevin Hilman, Krzysztof Kozlowski, Andy Gross, linux-snps-arc,
	devicetree, Mathias Nyman, Lad Prabhakar, Alexey Malahov,
	Rob Herring, linux-arm-kernel, Roger Quadros, Felipe Balbi,
	Greg Kroah-Hartman, Yoshihiro Shimoda, linux-usb, linux-mips,
	Serge Semin, linux-kernel, Manu Gautam, linuxppc-dev
In-Reply-To: <20201020112101.19077-6-Sergey.Semin@baikalelectronics.ru>

On Tue, Oct 20, 2020 at 1:21 PM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> Even though the Generic PHY framework is the more preferable way of
> setting the USB PHY up, there are still many dts-files and DT bindings
> which rely on having the legacy "usb-phy" specified to attach particular
> USB PHYs to USB cores. Let's have the "usb-phy" property described in
> the generic USB HCD binding file so it would be validated against the
> nodes in which it's specified. Mark the property as deprecated to
> discourage the developers from using it.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

^ permalink raw reply

* Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
From: Laurent Vivier @ 2020-10-20 18:42 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-kernel, linux-m68k, Geert Uytterhoeven, linux-serial,
	Paul Mackerras, linuxppc-dev, Joshua Thompson
In-Reply-To: <20201020183246.GA912431@kroah.com>

Le 20/10/2020 à 20:32, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 08:19:26PM +0200, Laurent Vivier wrote:
>> Le 20/10/2020 à 19:37, Greg KH a écrit :
>>> On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
>>>> Le 20/10/2020 à 18:28, Greg KH a écrit :
>>>>> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
>>>>>> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
>>>>>> if kernel is built for Mac but not on a Mac.
>>>>>>
>>>>>> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
>>>>>> ---
>>>>>>  drivers/tty/serial/pmac_zilog.c | 11 +++++++++++
>>>>>>  1 file changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
>>>>>> index 063484b22523..d1d2e55983c3 100644
>>>>>> --- a/drivers/tty/serial/pmac_zilog.c
>>>>>> +++ b/drivers/tty/serial/pmac_zilog.c
>>>>>> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
>>>>>>  static int __init init_pmz(void)
>>>>>>  {
>>>>>>  	int rc, i;
>>>>>> +
>>>>>> +#ifdef CONFIG_MAC
>>>>>> +	if (!MACH_IS_MAC)
>>>>>> +		return -ENODEV;
>>>>>> +#endif
>>>>>
>>>>> Why is the #ifdef needed?
>>>>>
>>>>> We don't like putting #ifdef in .c files for good reasons.  Can you make
>>>>> the api check for this work with and without that #ifdef needed?
>>>>
>>>> The #ifdef is needed because this file can be compiled for PowerMac and
>>>> m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
>>>> #ifdef.
>>>>
>>>> We need the MAC_IS_MAC because the same kernel can be used with several
>>>> m68k machines, so the init_pmz can be called on a m68k machine without
>>>> the zilog device (it's a multi-targets kernel).
>>>>
>>>> You can check it's the good way to do by looking inside:
>>>>
>>>>     drivers/video/fbdev/valkyriefb.c +317
>>>>     drivers/macintosh/adb.c +316
>>>>
>>>> That are two files used by both, mac and pmac.
>>>
>>> Why not fix it to work properly like other arch checks are done
>> I would be happy to do the same.
>>
>>> Put it in a .h file and do the #ifdef there.  Why is this "special"?
>>
>> I don't know.
>>
>> Do you mean something like:
>>
>> drivers/tty/serial/pmac_zilog.h
>> ...
>> #ifndef MACH_IS_MAC
>> #define MACH_IS_MAC (0)
>> #endif
>> ...
>>
>> drivers/tty/serial/pmac_zilog.c
>> ...
>> static int __init pmz_console_init(void)
>> {
>>         if (!MACH_IS_MAC)
>>                 return -ENODEV;
>> ...
> 
> Yup, that would be a good start, but why is the pmac_zilog.h file
> responsible for this?  Shouldn't this be in some arch-specific file
> somewhere?

For m68k, MACH_IS_MAC is defined in arch/m68k/include/asm/setup.h

If I want to define it for any other archs I don't know in which file we
can put it.

But as m68k mac is only sharing drivers with pmac perhaps we can put
this in arch/powerpc/include/asm/setup.h?

Thanks,
Laurent


^ permalink raw reply

* Re: mm: Question about the use of 'accessed' flags and pte_young() helper
From: Johannes Weiner @ 2020-10-20 18:33 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: linux-kernel@vger.kernel.org, Nicholas Piggin, linux-mm,
	linuxppc-dev@lists.ozlabs.org, Aneesh Kumar K.V
In-Reply-To: <ed3d1e19-b18b-d10e-2c86-0fb7ce3a431d@suse.cz>

On Tue, Oct 20, 2020 at 05:52:07PM +0200, Vlastimil Babka wrote:
> On 10/8/20 11:49 AM, Christophe Leroy wrote:
> > In a 10 years old commit
> > (https://github.com/linuxppc/linux/commit/d069cb4373fe0d451357c4d3769623a7564dfa9f), powerpc 8xx has
> > made the handling of PTE accessed bit conditional to CONFIG_SWAP.
> > Since then, this has been extended to some other powerpc variants.
> > 
> > That commit means that when CONFIG_SWAP is not selected, the accessed bit is not set by SW TLB miss
> > handlers, leading to pte_young() returning garbage, or should I say possibly returning false
> > allthough a page has been accessed since its access flag was reset.
> > 
> > Looking at various mm/ places, pte_young() is used independent of CONFIG_SWAP
> > 
> > Is it still valid the not manage accessed flags when CONFIG_SWAP is not selected ?
> 
> AFAIK it's wrong, reclaim needs it to detect accessed pages on inactive
> list, via page_referenced(), including file pages (page cache) where
> CONFIG_SWAP plays no role. Maybe it was different 10 years ago.

Yes, we require this bit for properly aging mmapped file pages. The
underlying assumption in the referenced commit is incorrect.

> > If yes, should pte_young() always return true in that case ?
> 
> It should best work as intended. If not possible, true is maybe better, as
> false will lead to inactive file list thrashing.

An unconditional true will cause mmapped file pages to be permanently
mlocked / unevictable.

Either way will break some workloads. The only good answer is the
truth :-)

^ permalink raw reply

* Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
From: Greg KH @ 2020-10-20 18:32 UTC (permalink / raw)
  To: Laurent Vivier
  Cc: linux-kernel, linux-m68k, Geert Uytterhoeven, linux-serial,
	Paul Mackerras, linuxppc-dev, Joshua Thompson
In-Reply-To: <387fd2aa-b181-c41f-0581-0a7e79a44e41@vivier.eu>

On Tue, Oct 20, 2020 at 08:19:26PM +0200, Laurent Vivier wrote:
> Le 20/10/2020 à 19:37, Greg KH a écrit :
> > On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
> >> Le 20/10/2020 à 18:28, Greg KH a écrit :
> >>> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
> >>>> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
> >>>> if kernel is built for Mac but not on a Mac.
> >>>>
> >>>> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
> >>>> ---
> >>>>  drivers/tty/serial/pmac_zilog.c | 11 +++++++++++
> >>>>  1 file changed, 11 insertions(+)
> >>>>
> >>>> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
> >>>> index 063484b22523..d1d2e55983c3 100644
> >>>> --- a/drivers/tty/serial/pmac_zilog.c
> >>>> +++ b/drivers/tty/serial/pmac_zilog.c
> >>>> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
> >>>>  static int __init init_pmz(void)
> >>>>  {
> >>>>  	int rc, i;
> >>>> +
> >>>> +#ifdef CONFIG_MAC
> >>>> +	if (!MACH_IS_MAC)
> >>>> +		return -ENODEV;
> >>>> +#endif
> >>>
> >>> Why is the #ifdef needed?
> >>>
> >>> We don't like putting #ifdef in .c files for good reasons.  Can you make
> >>> the api check for this work with and without that #ifdef needed?
> >>
> >> The #ifdef is needed because this file can be compiled for PowerMac and
> >> m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
> >> #ifdef.
> >>
> >> We need the MAC_IS_MAC because the same kernel can be used with several
> >> m68k machines, so the init_pmz can be called on a m68k machine without
> >> the zilog device (it's a multi-targets kernel).
> >>
> >> You can check it's the good way to do by looking inside:
> >>
> >>     drivers/video/fbdev/valkyriefb.c +317
> >>     drivers/macintosh/adb.c +316
> >>
> >> That are two files used by both, mac and pmac.
> > 
> > Why not fix it to work properly like other arch checks are done
> I would be happy to do the same.
> 
> > Put it in a .h file and do the #ifdef there.  Why is this "special"?
> 
> I don't know.
> 
> Do you mean something like:
> 
> drivers/tty/serial/pmac_zilog.h
> ...
> #ifndef MACH_IS_MAC
> #define MACH_IS_MAC (0)
> #endif
> ...
> 
> drivers/tty/serial/pmac_zilog.c
> ...
> static int __init pmz_console_init(void)
> {
>         if (!MACH_IS_MAC)
>                 return -ENODEV;
> ...

Yup, that would be a good start, but why is the pmac_zilog.h file
responsible for this?  Shouldn't this be in some arch-specific file
somewhere?

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
From: Laurent Vivier @ 2020-10-20 18:19 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-kernel, linux-m68k, Geert Uytterhoeven, linux-serial,
	Paul Mackerras, linuxppc-dev, Joshua Thompson
In-Reply-To: <20201020173745.GA882703@kroah.com>

Le 20/10/2020 à 19:37, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
>> Le 20/10/2020 à 18:28, Greg KH a écrit :
>>> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
>>>> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
>>>> if kernel is built for Mac but not on a Mac.
>>>>
>>>> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
>>>> ---
>>>>  drivers/tty/serial/pmac_zilog.c | 11 +++++++++++
>>>>  1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
>>>> index 063484b22523..d1d2e55983c3 100644
>>>> --- a/drivers/tty/serial/pmac_zilog.c
>>>> +++ b/drivers/tty/serial/pmac_zilog.c
>>>> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
>>>>  static int __init init_pmz(void)
>>>>  {
>>>>  	int rc, i;
>>>> +
>>>> +#ifdef CONFIG_MAC
>>>> +	if (!MACH_IS_MAC)
>>>> +		return -ENODEV;
>>>> +#endif
>>>
>>> Why is the #ifdef needed?
>>>
>>> We don't like putting #ifdef in .c files for good reasons.  Can you make
>>> the api check for this work with and without that #ifdef needed?
>>
>> The #ifdef is needed because this file can be compiled for PowerMac and
>> m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
>> #ifdef.
>>
>> We need the MAC_IS_MAC because the same kernel can be used with several
>> m68k machines, so the init_pmz can be called on a m68k machine without
>> the zilog device (it's a multi-targets kernel).
>>
>> You can check it's the good way to do by looking inside:
>>
>>     drivers/video/fbdev/valkyriefb.c +317
>>     drivers/macintosh/adb.c +316
>>
>> That are two files used by both, mac and pmac.
> 
> Why not fix it to work properly like other arch checks are done
I would be happy to do the same.

> Put it in a .h file and do the #ifdef there.  Why is this "special"?

I don't know.

Do you mean something like:

drivers/tty/serial/pmac_zilog.h
...
#ifndef MACH_IS_MAC
#define MACH_IS_MAC (0)
#endif
...

drivers/tty/serial/pmac_zilog.c
...
static int __init pmz_console_init(void)
{
        if (!MACH_IS_MAC)
                return -ENODEV;
...

Thanks,
Laurent

^ permalink raw reply

* Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
From: Greg KH @ 2020-10-20 17:37 UTC (permalink / raw)
  To: Laurent Vivier
  Cc: linux-kernel, linux-m68k, Geert Uytterhoeven, linux-serial,
	Paul Mackerras, linuxppc-dev, Joshua Thompson
In-Reply-To: <468bbbef-4745-3b16-b6f4-30b46ebcdc33@vivier.eu>

On Tue, Oct 20, 2020 at 06:37:41PM +0200, Laurent Vivier wrote:
> Le 20/10/2020 à 18:28, Greg KH a écrit :
> > On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
> >> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
> >> if kernel is built for Mac but not on a Mac.
> >>
> >> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
> >> ---
> >>  drivers/tty/serial/pmac_zilog.c | 11 +++++++++++
> >>  1 file changed, 11 insertions(+)
> >>
> >> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
> >> index 063484b22523..d1d2e55983c3 100644
> >> --- a/drivers/tty/serial/pmac_zilog.c
> >> +++ b/drivers/tty/serial/pmac_zilog.c
> >> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
> >>  static int __init init_pmz(void)
> >>  {
> >>  	int rc, i;
> >> +
> >> +#ifdef CONFIG_MAC
> >> +	if (!MACH_IS_MAC)
> >> +		return -ENODEV;
> >> +#endif
> > 
> > Why is the #ifdef needed?
> > 
> > We don't like putting #ifdef in .c files for good reasons.  Can you make
> > the api check for this work with and without that #ifdef needed?
> 
> The #ifdef is needed because this file can be compiled for PowerMac and
> m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
> #ifdef.
> 
> We need the MAC_IS_MAC because the same kernel can be used with several
> m68k machines, so the init_pmz can be called on a m68k machine without
> the zilog device (it's a multi-targets kernel).
> 
> You can check it's the good way to do by looking inside:
> 
>     drivers/video/fbdev/valkyriefb.c +317
>     drivers/macintosh/adb.c +316
> 
> That are two files used by both, mac and pmac.

Why not fix it to work properly like other arch checks are done?

Put it in a .h file and do the #ifdef there.  Why is this "special"?

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
From: Laurent Vivier @ 2020-10-20 16:37 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-kernel, linux-m68k, Geert Uytterhoeven, linux-serial,
	Paul Mackerras, linuxppc-dev, Joshua Thompson
In-Reply-To: <20201020162844.GA865546@kroah.com>

Le 20/10/2020 à 18:28, Greg KH a écrit :
> On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
>> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
>> if kernel is built for Mac but not on a Mac.
>>
>> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
>> ---
>>  drivers/tty/serial/pmac_zilog.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
>> index 063484b22523..d1d2e55983c3 100644
>> --- a/drivers/tty/serial/pmac_zilog.c
>> +++ b/drivers/tty/serial/pmac_zilog.c
>> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
>>  static int __init init_pmz(void)
>>  {
>>  	int rc, i;
>> +
>> +#ifdef CONFIG_MAC
>> +	if (!MACH_IS_MAC)
>> +		return -ENODEV;
>> +#endif
> 
> Why is the #ifdef needed?
> 
> We don't like putting #ifdef in .c files for good reasons.  Can you make
> the api check for this work with and without that #ifdef needed?

The #ifdef is needed because this file can be compiled for PowerMac and
m68k Mac. For PowerMac, the MACH_IS_MAC is not defined, so we need the
#ifdef.

We need the MAC_IS_MAC because the same kernel can be used with several
m68k machines, so the init_pmz can be called on a m68k machine without
the zilog device (it's a multi-targets kernel).

You can check it's the good way to do by looking inside:

    drivers/video/fbdev/valkyriefb.c +317
    drivers/macintosh/adb.c +316

That are two files used by both, mac and pmac.

Thanks,
Laurent

^ permalink raw reply

* [PATCH] serial: pmac_zilog: don't init if zilog is not available
From: Laurent Vivier @ 2020-10-20 16:23 UTC (permalink / raw)
  To: linux-kernel
  Cc: Laurent Vivier, linux-m68k, Paul Mackerras, linux-serial,
	Geert Uytterhoeven, linuxppc-dev, Joshua Thompson

We can avoid to probe for the Zilog device (and generate ugly kernel warning)
if kernel is built for Mac but not on a Mac.

Signed-off-by: Laurent Vivier <laurent@vivier.eu>
---
 drivers/tty/serial/pmac_zilog.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
index 063484b22523..d1d2e55983c3 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
 static int __init init_pmz(void)
 {
 	int rc, i;
+
+#ifdef CONFIG_MAC
+	if (!MACH_IS_MAC)
+		return -ENODEV;
+#endif
+
 	printk(KERN_INFO "%s\n", version);
 
 	/* 
@@ -2034,6 +2040,11 @@ static int __init pmz_console_setup(struct console *co, char *options)
 
 static int __init pmz_console_init(void)
 {
+#ifdef CONFIG_MAC
+	if (!MACH_IS_MAC)
+		return -ENODEV;
+#endif
+
 	/* Probe ports */
 	pmz_probe();
 
-- 
2.26.2


^ permalink raw reply related

* Re: [PATCH] serial: pmac_zilog: don't init if zilog is not available
From: Greg KH @ 2020-10-20 16:28 UTC (permalink / raw)
  To: Laurent Vivier
  Cc: linux-kernel, linux-m68k, Geert Uytterhoeven, linux-serial,
	Paul Mackerras, linuxppc-dev, Joshua Thompson
In-Reply-To: <20201020162303.1730562-1-laurent@vivier.eu>

On Tue, Oct 20, 2020 at 06:23:03PM +0200, Laurent Vivier wrote:
> We can avoid to probe for the Zilog device (and generate ugly kernel warning)
> if kernel is built for Mac but not on a Mac.
> 
> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
> ---
>  drivers/tty/serial/pmac_zilog.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
> index 063484b22523..d1d2e55983c3 100644
> --- a/drivers/tty/serial/pmac_zilog.c
> +++ b/drivers/tty/serial/pmac_zilog.c
> @@ -1867,6 +1867,12 @@ static struct platform_driver pmz_driver = {
>  static int __init init_pmz(void)
>  {
>  	int rc, i;
> +
> +#ifdef CONFIG_MAC
> +	if (!MACH_IS_MAC)
> +		return -ENODEV;
> +#endif

Why is the #ifdef needed?

We don't like putting #ifdef in .c files for good reasons.  Can you make
the api check for this work with and without that #ifdef needed?

thanks,

greg k-h

^ permalink raw reply

* Re: mm: Question about the use of 'accessed' flags and pte_young() helper
From: Vlastimil Babka @ 2020-10-20 15:52 UTC (permalink / raw)
  To: Christophe Leroy, linux-mm, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, Aneesh Kumar K.V, Nicholas Piggin,
	Johannes Weiner
In-Reply-To: <31ef1305-1fd4-8159-a2ca-e9968a568ff0@csgroup.eu>

On 10/8/20 11:49 AM, Christophe Leroy wrote:
> In a 10 years old commit
> (https://github.com/linuxppc/linux/commit/d069cb4373fe0d451357c4d3769623a7564dfa9f), powerpc 8xx has
> made the handling of PTE accessed bit conditional to CONFIG_SWAP.
> Since then, this has been extended to some other powerpc variants.
> 
> That commit means that when CONFIG_SWAP is not selected, the accessed bit is not set by SW TLB miss
> handlers, leading to pte_young() returning garbage, or should I say possibly returning false
> allthough a page has been accessed since its access flag was reset.
> 
> Looking at various mm/ places, pte_young() is used independent of CONFIG_SWAP
> 
> Is it still valid the not manage accessed flags when CONFIG_SWAP is not selected ?

AFAIK it's wrong, reclaim needs it to detect accessed pages on inactive list, 
via page_referenced(), including file pages (page cache) where CONFIG_SWAP plays 
no role. Maybe it was different 10 years ago.

> If yes, should pte_young() always return true in that case ?

It should best work as intended. If not possible, true is maybe better, as false 
will lead to inactive file list thrashing.

> While we are at it, I'm wondering whether powerpc should redefine arch_faults_on_old_pte()
> On some variants of powerpc, accessed flag is managed by HW. On others, it is managed by SW TLB miss
> handlers via page fault handling.
> 
> Thanks
> Christophe
> 


^ permalink raw reply

* Re: [PATCH v3 09/16] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
From: Rob Herring @ 2020-10-20 15:40 UTC (permalink / raw)
  To: Serge Semin
  Cc: Neil Armstrong, linux-mips, Pavel Parkhomenko, Kevin Hilman,
	Krzysztof Kozlowski, Andy Gross, linux-snps-arc, devicetree,
	Mathias Nyman, Martin Blumenstingl, Lad Prabhakar, Alexey Malahov,
	Rob Herring, Bjorn Andersson, linux-arm-kernel, Roger Quadros,
	Felipe Balbi, Greg Kroah-Hartman, Yoshihiro Shimoda, linux-usb,
	linux-kernel, Serge Semin, Manu Gautam, linuxppc-dev
In-Reply-To: <20201020112101.19077-10-Sergey.Semin@baikalelectronics.ru>

On Tue, 20 Oct 2020 14:20:54 +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
> 
> Note we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
>   the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
>   clock-names instead of the ones from the Databook.
> 
> Changelog v3:
> - Apply usb-xhci.yaml# schema only if the controller is supposed to work
>   as either host or otg.
> ---
>  .../devicetree/bindings/usb/dwc3.txt          | 125 --------
>  .../devicetree/bindings/usb/snps,dwc3.yaml    | 302 ++++++++++++++++++
>  2 files changed, 302 insertions(+), 125 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
>  create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH 15/29] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
From: Krzysztof Kozlowski @ 2020-10-20 12:38 UTC (permalink / raw)
  To: Serge Semin
  Cc: Felipe Balbi, Florian Fainelli, Greg Kroah-Hartman, linux-usb,
	linux-kernel, Serge Semin, devicetree, Rob Herring,
	Paul Mackerras, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20201020115959.2658-16-Sergey.Semin@baikalelectronics.ru>

On Tue, Oct 20, 2020 at 02:59:45PM +0300, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
> nodes are correctly named.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>  arch/powerpc/boot/dts/akebono.dts | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Acked-by: Krzysztof Kozlowski <krzk@kernel.org>

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCH v2 0/2] Fixes for coregroup
From: Michael Ellerman @ 2020-10-20 12:23 UTC (permalink / raw)
  To: Michael Ellerman, Srikar Dronamraju
  Cc: Nathan Lynch, Gautham R Shenoy, Qian Cai, LKML, Ingo Molnar,
	Peter Zijlstra, linuxppc-dev, Valentin Schneider
In-Reply-To: <20201019042716.106234-1-srikar@linux.vnet.ibm.com>

On Mon, 19 Oct 2020 09:57:14 +0530, Srikar Dronamraju wrote:
> These patches fixes problems introduced by the coregroup patches.
> The first patch we remove a redundant variable.
> Second patch allows to boot with CONFIG_CPUMASK_OFFSTACK enabled.
> 
> Changelog v1->v2:
> https://lore.kernel.org/linuxppc-dev/20201008034240.34059-1-srikar@linux.vnet.ibm.com/t/#u
> 1. 1st patch was not part of previous posting.
> 2. Updated 2nd patch based on comments from Michael Ellerman
> 
> [...]

Applied to powerpc/fixes.

[1/2] powerpc/smp: Remove unnecessary variable
      https://git.kernel.org/powerpc/c/966730a6e8524c1b5fe64358e5884605cab6ccb3
[2/2] powerpc/smp: Use GFP_ATOMIC while allocating tmp mask
      https://git.kernel.org/powerpc/c/84dbf66c63472069e5eb40b810731367618cd8b5

cheers

^ permalink raw reply

* Re: [PATCH 1/2] powerpc: Fix user data corruption with P9N DD2.1 VSX CI load workaround emulation
From: Michael Ellerman @ 2020-10-20 12:23 UTC (permalink / raw)
  To: Michael Neuling, mpe; +Cc: linuxppc-dev
In-Reply-To: <20201013043741.743413-1-mikey@neuling.org>

On Tue, 13 Oct 2020 15:37:40 +1100, Michael Neuling wrote:
> __get_user_atomic_128_aligned() stores to kaddr using stvx which is a
> VMX store instruction, hence kaddr must be 16 byte aligned otherwise
> the store won't occur as expected.
> 
> Unfortunately when we call __get_user_atomic_128_aligned() in
> p9_hmi_special_emu(), the buffer we pass as kaddr (ie. vbuf) isn't
> guaranteed to be 16B aligned. This means that the write to vbuf in
> __get_user_atomic_128_aligned() has the bottom bits of the address
> truncated. This results in other local variables being
> overwritten. Also vbuf will not contain the correct data which results
> in the userspace emulation being wrong and hence user data corruption.
> 
> [...]

Applied to powerpc/fixes.

[1/2] powerpc: Fix undetected data corruption with P9N DD2.1 VSX CI load emulation
      https://git.kernel.org/powerpc/c/1da4a0272c5469169f78cd76cf175ff984f52f06
[2/2] selftests/powerpc: Make alignment handler test P9N DD2.1 vector CI load workaround
      https://git.kernel.org/powerpc/c/d1781f23704707d350b8c9006e2bdf5394bf91b2

cheers

^ permalink raw reply

* Re: [PATCH v2] powerpc/powernv/dump: Fix race while processing OPAL dump
From: Michael Ellerman @ 2020-10-20 12:23 UTC (permalink / raw)
  To: linuxppc-dev, Vasant Hegde; +Cc: Mahesh Salgaonkar
In-Reply-To: <20201017164210.264619-1-hegdevasant@linux.vnet.ibm.com>

On Sat, 17 Oct 2020 22:12:10 +0530, Vasant Hegde wrote:
> Every dump reported by OPAL is exported to userspace through a sysfs
> interface and notified using kobject_uevent(). The userspace daemon
> (opal_errd) then reads the dump and acknowledges that the dump is
> saved safely to disk. Once acknowledged the kernel removes the
> respective sysfs file entry causing respective resources to be
> released including kobject.
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/powernv/dump: Fix race while processing OPAL dump
      https://git.kernel.org/powerpc/c/0a43ae3e2beb77e3481d812834d33abe270768ab

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/powernv/dump: Handle multiple writes to ack attribute
From: Michael Ellerman @ 2020-10-20 12:23 UTC (permalink / raw)
  To: linuxppc-dev, Vasant Hegde; +Cc: Aneesh Kumar K . V, Mahesh Salgaonkar
In-Reply-To: <20201017164236.264713-1-hegdevasant@linux.vnet.ibm.com>

On Sat, 17 Oct 2020 22:12:36 +0530, Vasant Hegde wrote:
> Even though we use self removing sysfs helper, we still need
> to make sure we do the final kobject delete conditionally.
> sysfs_remove_file_self() will handle parallel calls to remove
> the sysfs attribute file and returns true only in the caller
> that removed the attribute file. The other parallel callers
> are returned false. Do the final kobject delete checking
> the return value of sysfs_remove_file_self().

Applied to powerpc/fixes.

[1/1] powerpc/powernv/dump: Handle multiple writes to ack attribute
      https://git.kernel.org/powerpc/c/358ab796ce78ba271a6ff82834183ffb2cb68c4c

cheers

^ permalink raw reply

* Re: [PATCH v2 3/3] powerpc: Fix update form addressing in inline assembly
From: Segher Boessenkool @ 2020-10-20 12:16 UTC (permalink / raw)
  To: Christophe Leroy
  Cc: linux-kernel, mathieu.desnoyers, Paul Mackerras, linuxppc-dev
In-Reply-To: <fcff4199459890d107a06dbc39c52668ccd0921b.1603179582.git.christophe.leroy@csgroup.eu>

Hi!

On Tue, Oct 20, 2020 at 07:40:09AM +0000, Christophe Leroy wrote:
> In several places, inline assembly uses the "%Un" modifier
> to enable the use of instruction with update form addressing,
> but the associated "<>" constraint is missing.
> 
> As mentioned in previous patch, this fails with gcc 4.9, so
> "<>" can't be used directly.
> 
> Use UPD_CONSTR macro everywhere %Un modifier is used.
> 
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

Oh well, it will be easy enough to remove this wart later, so

Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>

> --- a/arch/powerpc/include/asm/book3s/32/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
> @@ -525,7 +525,7 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		stw%U0%X0 %2,%0\n\
>  		eieio\n\
>  		stw%U1%X1 %L2,%1"
> -	: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
> +	: "=m"UPD_CONSTR (*ptep), "=m"UPD_CONSTR (*((unsigned char *)ptep+4))
>  	: "r" (pte) : "memory");

Here it would pre-increment ptep+4.  That can never be something useful
afaics?  The order the two operands are (either or not) pre-modified in
the asm is not specified (GCC does not parse the asm template, by
design), so I fail to see how this could ever work.

> --- a/arch/powerpc/include/asm/nohash/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
> @@ -200,7 +200,7 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
>  			stw%U0%X0 %2,%0\n\
>  			eieio\n\
>  			stw%U1%X1 %L2,%1"
> -		: "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
> +		: "=m"UPD_CONSTR (*ptep), "=m"UPD_CONSTR (*((unsigned char *)ptep+4))
>  		: "r" (pte) : "memory");

Same here.

The rest looks fine.


Segher

^ permalink raw reply

* [PATCH 15/29] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
From: Serge Semin @ 2020-10-20 11:59 UTC (permalink / raw)
  To: Felipe Balbi, Krzysztof Kozlowski, Florian Fainelli, Rob Herring,
	Greg Kroah-Hartman, Michael Ellerman, Benjamin Herrenschmidt,
	Paul Mackerras
  Cc: devicetree, linux-usb, linux-kernel, Serge Semin, Serge Semin,
	linuxppc-dev, linux-arm-kernel
In-Reply-To: <20201020115959.2658-1-Sergey.Semin@baikalelectronics.ru>

In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 arch/powerpc/boot/dts/akebono.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/akebono.dts b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@30000010000 {
 			interrupts = <93 2>;
 		};
 
-		EHCI0: ehci@30010000000 {
+		EHCI0: usb@30010000000 {
 			compatible = "ibm,476gtr-ehci", "generic-ehci";
 			reg = <0x300 0x10000000 0x0 0x10000>;
 			interrupt-parent = <&MPIC>;
@@ -140,14 +140,14 @@ SD0: sd@30000000000 {
 			interrupt-parent = <&MPIC>;
 		};
 
-		OHCI0: ohci@30010010000 {
+		OHCI0: usb@30010010000 {
 			compatible = "ibm,476gtr-ohci", "generic-ohci";
 			reg = <0x300 0x10010000 0x0 0x10000>;
 			interrupt-parent = <&MPIC>;
 			interrupts = <89 1>;
 			};
 
-		OHCI1: ohci@30010020000 {
+		OHCI1: usb@30010020000 {
 			compatible = "ibm,476gtr-ohci", "generic-ohci";
 			reg = <0x300 0x10020000 0x0 0x10000>;
 			interrupt-parent = <&MPIC>;
-- 
2.27.0


^ permalink raw reply related

* [PATCH 00/29] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
From: Serge Semin @ 2020-10-20 11:59 UTC (permalink / raw)
  To: Felipe Balbi, Krzysztof Kozlowski, Florian Fainelli, Rob Herring,
	Greg Kroah-Hartman
  Cc: Andrew Lunn, Amelie Delaunay, Tony Lindgren, Patrice Chotard,
	Paul Cercueil, Paul Mackerras, linux-stm32, Alexandre Torgue,
	Khuong Dinh, linux-samsung-soc, Gregory Clement, Rafal Milecki,
	Alexey Brodkin, Wei Xu, Chen-Yu Tsai, Andy Gross,
	bcm-kernel-feedback-list, linux-arm-msm, linux-snps-arc,
	Sebastian Hesselbarth, devicetree, Jason Cooper, linux-omap,
	Hauke Mehrtens, linuxppc-dev, Maxime Ripard, Vladimir Zapolskiy,
	linux-mediatek, Santosh Shilimkar, Matthias Brugger,
	Benoit Cousson, Bjorn Andersson, linux-arm-kernel,
	Thomas Bogendoerfer, linux-mips, Vineet Gupta, linux-usb,
	linux-kernel, Serge Semin, Li Yang, Serge Semin, Kukjin Kim,
	Maxime Coquelin, Shawn Guo

As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].

Firstly as Krzysztof suggested we've removed a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in the controller driver and
in all the DTS files, which have been unfortunate to define such nodes.

Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.

Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.

Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.

[1] Link: https://lore.kernel.org/linux-usb/20201014101402.18271-1-Sergey.Semin@baikalelectronics.ru/
Changelog v0:
- As Krzysztof suggested I've created a script which checked whether the
  node names had been also updated in all the depended dts files. As a
  result I found two more files which should have been also modified:
  arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
  arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.

Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Rafal Milecki <zajec5@gmail.com>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Khuong Dinh <khuong@os.amperecomputing.com>
Cc: Andy Gross <agross@kernel.org>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Amelie Delaunay <amelie.delaunay@st.com>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@bootlin.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Li Yang <leoyang.li@nxp.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-snps-arc@lists.infradead.org
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Serge Semin (29):
  usb: dwc3: Discard synopsys,dwc3 compatibility string
  arm: dts: keystone: Correct DWC USB3 compatible string
  arm: dts: am437x: Correct DWC USB3 compatible string
  arm: dts: exynos: Correct DWC USB3 compatible string
  arm64: dts: amlogic: meson-g12: Set FL-adj property value
  arc: dts: Harmonize EHCI/OHCI DT nodes name
  arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
  arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
  arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
  arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
  arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
  mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
  mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
  mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
  powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
  arm: dts: bcm5301x: Harmonize xHCI DT nodes name
  arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
  arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name
  arm: dts: exynos: Harmonize DWC USB3 DT nodes name
  arm: dts: keystone: Harmonize DWC USB3 DT nodes name
  arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
  arm: dts: omap5: Harmonize DWC USB3 DT nodes name
  arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
  arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
  arm64: dts: apm: Harmonize DWC USB3 DT nodes name
  arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
  arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
  arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
  arm64: dts: qcom: Harmonize DWC USB3 DT nodes name

 arch/arc/boot/dts/axc003.dtsi                     | 4 ++--
 arch/arc/boot/dts/axc003_idu.dtsi                 | 4 ++--
 arch/arc/boot/dts/axs10x_mb.dtsi                  | 4 ++--
 arch/arc/boot/dts/hsdk.dts                        | 4 ++--
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi              | 2 +-
 arch/arm/boot/dts/am437x-l4.dtsi                  | 4 ++--
 arch/arm/boot/dts/armada-375.dtsi                 | 2 +-
 arch/arm/boot/dts/bcm5301x.dtsi                   | 6 +++---
 arch/arm/boot/dts/bcm53573.dtsi                   | 4 ++--
 arch/arm/boot/dts/exynos5250.dtsi                 | 4 ++--
 arch/arm/boot/dts/exynos54xx.dtsi                 | 4 ++--
 arch/arm/boot/dts/hisi-x5hd2.dtsi                 | 4 ++--
 arch/arm/boot/dts/keystone-k2e.dtsi               | 6 +++---
 arch/arm/boot/dts/keystone.dtsi                   | 4 ++--
 arch/arm/boot/dts/lpc18xx.dtsi                    | 4 ++--
 arch/arm/boot/dts/ls1021a.dtsi                    | 2 +-
 arch/arm/boot/dts/omap5-l4.dtsi                   | 2 +-
 arch/arm/boot/dts/stih407-family.dtsi             | 2 +-
 arch/arm/boot/dts/stm32mp151.dtsi                 | 4 ++--
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi      | 2 +-
 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +-
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi        | 4 ++--
 arch/arm64/boot/dts/apm/apm-storm.dtsi            | 6 +++---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi        | 4 ++--
 arch/arm64/boot/dts/exynos/exynos7.dtsi           | 2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi    | 4 ++--
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi    | 6 +++---
 arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi    | 4 ++--
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi    | 4 ++--
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi         | 2 +-
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi    | 4 ++--
 arch/arm64/boot/dts/hisilicon/hip06.dtsi          | 4 ++--
 arch/arm64/boot/dts/hisilicon/hip07.dtsi          | 4 ++--
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi     | 4 ++--
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi      | 4 ++--
 arch/arm64/boot/dts/qcom/ipq8074.dtsi             | 4 ++--
 arch/arm64/boot/dts/qcom/msm8996.dtsi             | 4 ++--
 arch/arm64/boot/dts/qcom/msm8998.dtsi             | 2 +-
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi          | 2 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi              | 4 ++--
 arch/arm64/boot/dts/qcom/sc7180.dtsi              | 2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi              | 4 ++--
 arch/arm64/boot/dts/qcom/sm8150.dtsi              | 2 +-
 arch/mips/boot/dts/ingenic/jz4740.dtsi            | 2 +-
 arch/mips/boot/dts/ingenic/jz4770.dtsi            | 2 +-
 arch/mips/boot/dts/mti/sead3.dts                  | 2 +-
 arch/mips/boot/dts/ralink/mt7628a.dtsi            | 2 +-
 arch/powerpc/boot/dts/akebono.dts                 | 6 +++---
 drivers/usb/dwc3/core.c                           | 3 ---
 49 files changed, 84 insertions(+), 87 deletions(-)

-- 
2.27.0


^ permalink raw reply

* Re: [PATCH 3/3] powerpc: Fix pre-update addressing in inline assembly
From: Segher Boessenkool @ 2020-10-20 11:51 UTC (permalink / raw)
  To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <ff158583-4e25-a5e6-5131-359423037e4f@csgroup.eu>

On Tue, Oct 20, 2020 at 09:44:33AM +0200, Christophe Leroy wrote:
> Le 19/10/2020 à 22:24, Segher Boessenkool a écrit :
> >>but the associated "<>" constraint is missing.
> >
> >But that is just fine.  Pointless, sure, but not a bug.
> 
> Most of those are from prehistoric code. So at some point in time it was 
> effective. Then one day GCC changed it's way and they became pointless. So, 
> not a software bug, but still a regression at some point.
> 
> >>Use UPD_CONSTR macro everywhere %Un modifier is used.
> >
> >Eww.  My poor stomach.
> 
> There are not that many :)

Heh, your pain threshold is much higher than mine I guess :-)

> >Have you verified that update form is *correct* in all these, and that
> >we even *want* this there?
> 
> I can't see anything that would militate against it, do you ?
> 
> I guess if the elders have put %Us there, it was wanted.

On old CPUs, update form load/stores actually executed faster than a
"normal" memory access and an addi (or plain add).  But on more recent
stuff it mostly saves code size.  Which is nice of course, and can speed
up your code a bit, in theory at least.

It is quite hard to trigger the compiler to generate update form insns
in asm, sigh.  So testing will probably not show anything either way.
Oh well :-)


Segher

^ permalink raw reply

* Re: [PATCH v4] powerpc/pseries: Avoid using addr_to_pfn in real mode
From: Ganesh @ 2020-10-20 11:33 UTC (permalink / raw)
  To: mpe, linuxppc-dev; +Cc: mahesh, npiggin, aneesh.kumar
In-Reply-To: <20200724063946.21378-1-ganeshgr@linux.ibm.com>

On 7/24/20 12:09 PM, Ganesh Goudar wrote:

> When an UE or memory error exception is encountered the MCE handler
> tries to find the pfn using addr_to_pfn() which takes effective
> address as an argument, later pfn is used to poison the page where
> memory error occurred, recent rework in this area made addr_to_pfn
> to run in real mode, which can be fatal as it may try to access
> memory outside RMO region.
>
> Have two helper functions to separate things to be done in real mode
> and virtual mode without changing any functionality. This also fixes
> the following error as the use of addr_to_pfn is now moved to virtual
> mode.
>
> Without this change following kernel crash is seen on hitting UE.
>
> [  485.128036] Oops: Kernel access of bad area, sig: 11 [#1]
> [  485.128040] LE SMP NR_CPUS=2048 NUMA pSeries
> [  485.128047] Modules linked in:
> [  485.128067] CPU: 15 PID: 6536 Comm: insmod Kdump: loaded Tainted: G OE 5.7.0 #22
> [  485.128074] NIP:  c00000000009b24c LR: c0000000000398d8 CTR: c000000000cd57c0
> [  485.128078] REGS: c000000003f1f970 TRAP: 0300   Tainted: G OE (5.7.0)
> [  485.128082] MSR:  8000000000001003 <SF,ME,RI,LE>  CR: 28008284  XER: 00000001
> [  485.128088] CFAR: c00000000009b190 DAR: c0000001fab00000 DSISR: 40000000 IRQMASK: 1
> [  485.128088] GPR00: 0000000000000001 c000000003f1fbf0 c000000001634300 0000b0fa01000000
> [  485.128088] GPR04: d000000002220000 0000000000000000 00000000fab00000 0000000000000022
> [  485.128088] GPR08: c0000001fab00000 0000000000000000 c0000001fab00000 c000000003f1fc14
> [  485.128088] GPR12: 0000000000000008 c000000003ff5880 d000000002100008 0000000000000000
> [  485.128088] GPR16: 000000000000ff20 000000000000fff1 000000000000fff2 d0000000021a1100
> [  485.128088] GPR20: d000000002200000 c00000015c893c50 c000000000d49b28 c00000015c893c50
> [  485.128088] GPR24: d0000000021a0d08 c0000000014e5da8 d0000000021a0818 000000000000000a
> [  485.128088] GPR28: 0000000000000008 000000000000000a c0000000017e2970 000000000000000a
> [  485.128125] NIP [c00000000009b24c] __find_linux_pte+0x11c/0x310
> [  485.128130] LR [c0000000000398d8] addr_to_pfn+0x138/0x170
> [  485.128133] Call Trace:
> [  485.128135] Instruction dump:
> [  485.128138] 3929ffff 7d4a3378 7c883c36 7d2907b4 794a1564 7d294038 794af082 3900ffff
> [  485.128144] 79291f24 790af00e 78e70020 7d095214 <7c69502a> 2fa30000 419e011c 70690040
> [  485.128152] ---[ end trace d34b27e29ae0e340 ]---
>
> Fixes: 9ca766f9891d ("powerpc/64s/pseries: machine check convert to use common event code")
> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
> ---
> V2: Leave bare metal code and save_mce_event as is.
>
> V3: Have separate functions for realmode and virtual mode handling.
>
> V4: Fix build warning, rephrase commit message.
> ---
>   arch/powerpc/platforms/pseries/ras.c | 118 ++++++++++++++++-----------
>   1 file changed, 69 insertions(+), 49 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
> index f3736fcd98fc..c509e43bac23 100644
> --- a/arch/powerpc/platforms/pseries/ras.c
> +++ b/arch/powerpc/platforms/pseries/ras.c
> @@ -522,18 +522,55 @@ int pSeries_system_reset_exception(struct pt_regs *regs)
>   	return 0; /* need to perform reset */
>   }
>   
> +static int mce_handle_err_realmode(int disposition, u8 error_type)
> +{
> +#ifdef CONFIG_PPC_BOOK3S_64
> +	if (disposition == RTAS_DISP_NOT_RECOVERED) {
> +		switch (error_type) {
> +		case	MC_ERROR_TYPE_SLB:
> +		case	MC_ERROR_TYPE_ERAT:
> +			/*
> +			 * Store the old slb content in paca before flushing.
> +			 * Print this when we go to virtual mode.
> +			 * There are chances that we may hit MCE again if there
> +			 * is a parity error on the SLB entry we trying to read
> +			 * for saving. Hence limit the slb saving to single
> +			 * level of recursion.
> +			 */
> +			if (local_paca->in_mce == 1)
> +				slb_save_contents(local_paca->mce_faulty_slbs);
> +			flush_and_reload_slb();
> +			disposition = RTAS_DISP_FULLY_RECOVERED;
> +			break;
> +		default:
> +			break;
> +		}
> +	} else if (disposition == RTAS_DISP_LIMITED_RECOVERY) {
> +		/* Platform corrected itself but could be degraded */
> +		pr_err("MCE: limited recovery, system may be degraded\n");
> +		disposition = RTAS_DISP_FULLY_RECOVERED;
> +	}
> +#endif
> +	return disposition;
> +}
>   
> -static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
> +static int mce_handle_err_virtmode(struct pt_regs *regs,
> +				   struct rtas_error_log *errp,
> +				   struct pseries_mc_errorlog *mce_log,
> +				   int disposition)
>   {
>   	struct mce_error_info mce_err = { 0 };
> -	unsigned long eaddr = 0, paddr = 0;
> -	struct pseries_errorlog *pseries_log;
> -	struct pseries_mc_errorlog *mce_log;
> -	int disposition = rtas_error_disposition(errp);
>   	int initiator = rtas_error_initiator(errp);
>   	int severity = rtas_error_severity(errp);
> +	unsigned long eaddr = 0, paddr = 0;
>   	u8 error_type, err_sub_type;
>   
> +	if (!mce_log)
> +		goto out;
> +
> +	error_type = mce_log->error_type;
> +	err_sub_type = rtas_mc_error_sub_type(mce_log);
> +
>   	if (initiator == RTAS_INITIATOR_UNKNOWN)
>   		mce_err.initiator = MCE_INITIATOR_UNKNOWN;
>   	else if (initiator == RTAS_INITIATOR_CPU)
> @@ -572,18 +609,7 @@ static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
>   	mce_err.error_type = MCE_ERROR_TYPE_UNKNOWN;
>   	mce_err.error_class = MCE_ECLASS_UNKNOWN;
>   
> -	if (!rtas_error_extended(errp))
> -		goto out;
> -
> -	pseries_log = get_pseries_errorlog(errp, PSERIES_ELOG_SECT_ID_MCE);
> -	if (pseries_log == NULL)
> -		goto out;
> -
> -	mce_log = (struct pseries_mc_errorlog *)pseries_log->data;
> -	error_type = mce_log->error_type;
> -	err_sub_type = rtas_mc_error_sub_type(mce_log);
> -
> -	switch (mce_log->error_type) {
> +	switch (error_type) {
>   	case MC_ERROR_TYPE_UE:
>   		mce_err.error_type = MCE_ERROR_TYPE_UE;
>   		mce_common_process_ue(regs, &mce_err);
> @@ -683,37 +709,31 @@ static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
>   		mce_err.error_type = MCE_ERROR_TYPE_UNKNOWN;
>   		break;
>   	}
> +out:
> +	save_mce_event(regs, disposition == RTAS_DISP_FULLY_RECOVERED,
> +		       &mce_err, regs->nip, eaddr, paddr);
> +	return disposition;
> +}
>   
> -#ifdef CONFIG_PPC_BOOK3S_64
> -	if (disposition == RTAS_DISP_NOT_RECOVERED) {
> -		switch (error_type) {
> -		case	MC_ERROR_TYPE_SLB:
> -		case	MC_ERROR_TYPE_ERAT:
> -			/*
> -			 * Store the old slb content in paca before flushing.
> -			 * Print this when we go to virtual mode.
> -			 * There are chances that we may hit MCE again if there
> -			 * is a parity error on the SLB entry we trying to read
> -			 * for saving. Hence limit the slb saving to single
> -			 * level of recursion.
> -			 */
> -			if (local_paca->in_mce == 1)
> -				slb_save_contents(local_paca->mce_faulty_slbs);
> -			flush_and_reload_slb();
> -			disposition = RTAS_DISP_FULLY_RECOVERED;
> -			break;
> -		default:
> -			break;
> -		}
> -	} else if (disposition == RTAS_DISP_LIMITED_RECOVERY) {
> -		/* Platform corrected itself but could be degraded */
> -		printk(KERN_ERR "MCE: limited recovery, system may "
> -		       "be degraded\n");
> -		disposition = RTAS_DISP_FULLY_RECOVERED;
> -	}
> -#endif
> +static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
> +{
> +	struct pseries_errorlog *pseries_log;
> +	struct pseries_mc_errorlog *mce_log = NULL;
> +	int disposition = rtas_error_disposition(errp);
> +	u8 error_type;
> +
> +	if (!rtas_error_extended(errp))
> +		goto out;
> +
> +	pseries_log = get_pseries_errorlog(errp, PSERIES_ELOG_SECT_ID_MCE);
> +	if (!pseries_log)
> +		goto out;
> +
> +	mce_log = (struct pseries_mc_errorlog *)pseries_log->data;
> +	error_type = mce_log->error_type;
> +
> +	disposition = mce_handle_err_realmode(disposition, error_type);
>   
> -out:
>   	/*
>   	 * Enable translation as we will be accessing per-cpu variables
>   	 * in save_mce_event() which may fall outside RMO region, also
> @@ -724,10 +744,10 @@ static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
>   	 * Note: All the realmode handling like flushing SLB entries for
>   	 *       SLB multihit is done by now.
>   	 */
> +out:
>   	mtmsr(mfmsr() | MSR_IR | MSR_DR);
> -	save_mce_event(regs, disposition == RTAS_DISP_FULLY_RECOVERED,
> -			&mce_err, regs->nip, eaddr, paddr);
> -
> +	disposition = mce_handle_err_virtmode(regs, errp, mce_log,
> +					      disposition);
>   	return disposition;
>   }
>   

We need this fix as well to fix pseries mce handling, Any comments on this patch.

Thanks

Ganesh


^ permalink raw reply

* [PATCH v3 13/16] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value
From: Serge Semin @ 2020-10-20 11:20 UTC (permalink / raw)
  To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
	Greg Kroah-Hartman, Rob Herring, Kevin Hilman, Neil Armstrong,
	Jerome Brunet, Martin Blumenstingl
  Cc: devicetree, linux-snps-arc, linux-kernel, Rob Herring, linux-mips,
	Yoshihiro Shimoda, linux-usb, Lad Prabhakar, Serge Semin,
	Bjorn Andersson, Serge Semin, Manu Gautam, Andy Gross,
	Pavel Parkhomenko, linux-amlogic, Alexey Malahov, linuxppc-dev,
	linux-arm-kernel, Roger Quadros
In-Reply-To: <20201020112101.19077-1-Sergey.Semin@baikalelectronics.ru>

An empty snps,quirk-frame-length-adjustment won't cause any change
performed by the driver. Moreover the DT schema validation will fail,
since it expects the property being assigned with some value. So set
fix the example by setting a valid FL-adj value in accordance with
Neil Armstrong comment.

Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-Sergey.Semin@baikalelectronics.ru/
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>

---

Note the same problem is in the DT source file
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi .
---
 .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
index 5b04a7dfa018..a4b44a16aaef 100644
--- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
+++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml
@@ -209,6 +209,6 @@ examples:
               interrupts = <30>;
               dr_mode = "host";
               snps,dis_u2_susphy_quirk;
-              snps,quirk-frame-length-adjustment;
+              snps,quirk-frame-length-adjustment = <0x20>;
           };
     };
-- 
2.27.0


^ permalink raw reply related

* [PATCH v3 16/16] dt-bindings: usb: qcom,dwc3: Validate DWC3 sub-node
From: Serge Semin @ 2020-10-20 11:21 UTC (permalink / raw)
  To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
	Greg Kroah-Hartman, Rob Herring, Andy Gross, Bjorn Andersson,
	Manu Gautam
  Cc: devicetree, linux-mips, Neil Armstrong, Martin Blumenstingl,
	Kevin Hilman, Yoshihiro Shimoda, linux-usb, linux-kernel,
	Lad Prabhakar, Serge Semin, Alexey Malahov, Serge Semin,
	Pavel Parkhomenko, linux-arm-msm, linux-snps-arc, linuxppc-dev,
	Rob Herring, linux-arm-kernel, Roger Quadros
In-Reply-To: <20201020112101.19077-1-Sergey.Semin@baikalelectronics.ru>

Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
have a DWC USB3 compatible sub-node to describe a fully functioning USB
interface. Let's use the available DWC USB3 DT schema to validate the
Qualcomm DWC3 sub-nodes.

Note since the generic DWC USB3 DT node is supposed to be named as generic
USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
regexp and fix the DT node example.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>

---

Changelog v2:
- Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes.
---
 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index dac10848dd7f..8f8d781e73a0 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -103,11 +103,8 @@ properties:
 # Required child node:
 
 patternProperties:
-  "^dwc3@[0-9a-f]+$":
-    type: object
-    description:
-      A child node must exist to represent the core DWC3 IP block
-      The content of the node is defined in dwc3.txt.
+  "^usb@[0-9a-f]+$":
+    $ref: snps,dwc3.yaml#
 
 required:
   - compatible
@@ -160,7 +157,7 @@ examples:
 
             resets = <&gcc GCC_USB30_PRIM_BCR>;
 
-            dwc3@a600000 {
+            usb@a600000 {
                 compatible = "snps,dwc3";
                 reg = <0 0x0a600000 0 0xcd00>;
                 interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.27.0


^ permalink raw reply related

* [PATCH v3 06/16] dt-bindings: usb: Convert xHCI bindings to DT schema
From: Serge Semin @ 2020-10-20 11:20 UTC (permalink / raw)
  To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
	Greg Kroah-Hartman, Rob Herring
  Cc: devicetree, linux-snps-arc, linux-mips, Neil Armstrong,
	Martin Blumenstingl, Kevin Hilman, Yoshihiro Shimoda, linux-usb,
	linux-kernel, Lad Prabhakar, Serge Semin, Bjorn Andersson,
	Serge Semin, Manu Gautam, Andy Gross, Pavel Parkhomenko,
	Alexey Malahov, linuxppc-dev, Rob Herring, linux-arm-kernel,
	Roger Quadros
In-Reply-To: <20201020112101.19077-1-Sergey.Semin@baikalelectronics.ru>

Currently the DT bindings of Generic xHCI Controllers are described by means
of the legacy text file. Since such format is deprecated in favor of the
DT schema, let's convert the Generic xHCI Controllers bindings file to the
corresponding yaml files. There will be two of them: a DT schema for the
xHCI controllers on a generic platform and a DT schema validating a generic
xHCI controllers properties. The later will be used to validate the xHCI
controllers, which aside from some vendor-specific features support the
basic xHCI functionality.

An xHCI-compatible DT node shall support the standard USB HCD properties
and custom ones like: usb2-lpm-disable, usb3-lpm-capable,
quirk-broken-port-ped and imod-interval-ns. In addition if a generic xHCI
controller is being validated against the DT schema it is also supposed to
be equipped with mandatory compatible string, single registers range,
single interrupts source, and is supposed to optionally contain up to two
reference clocks for the controller core and CSRs.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>

---

Changelog v2:
- Add explicit "additionalProperties: true" to the usb-xhci.yaml schema,
  since additionalProperties/unevaluatedProperties are going to be mandary
  for each binding.
---
 .../devicetree/bindings/usb/generic-xhci.yaml | 63 +++++++++++++++++++
 .../devicetree/bindings/usb/usb-xhci.txt      | 41 ------------
 .../devicetree/bindings/usb/usb-xhci.yaml     | 42 +++++++++++++
 3 files changed, 105 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/generic-xhci.yaml
 delete mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt
 create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.yaml

diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
new file mode 100644
index 000000000000..1ea1d49a8175
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB xHCI Controller Device Tree Bindings
+
+maintainers:
+  - Mathias Nyman <mathias.nyman@intel.com>
+
+allOf:
+  - $ref: "usb-xhci.yaml#"
+
+properties:
+  compatible:
+    oneOf:
+      - description: Generic xHCI device
+        const: generic-xhci
+      - description: Armada 37xx/375/38x/8k SoCs
+        items:
+          - enum:
+              - marvell,armada3700-xhci
+              - marvell,armada-375-xhci
+              - marvell,armada-380-xhci
+              - marvell,armada-8k-xhci
+          - const: generic-xhci
+      - description: Broadcom STB SoCs with xHCI
+        const: brcm,bcm7445-xhci
+      - description: Generic xHCI device
+        const: xhci-platform
+        deprecated: true
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 2
+
+  clock-names:
+    minItems: 1
+    items:
+      - const: core
+      - const: reg
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+examples:
+  - |
+    usb@f0931000 {
+      compatible = "generic-xhci";
+      reg = <0xf0931000 0x8c8>;
+      interrupts = <0x0 0x4e 0x0>;
+    };
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
deleted file mode 100644
index 0c5cff84a969..000000000000
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-USB xHCI controllers
-
-Required properties:
-  - compatible: should be one or more of
-
-    - "generic-xhci" for generic XHCI device
-    - "marvell,armada3700-xhci" for Armada 37xx SoCs
-    - "marvell,armada-375-xhci" for Armada 375 SoCs
-    - "marvell,armada-380-xhci" for Armada 38x SoCs
-    - "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI
-    - "xhci-platform" (deprecated)
-
-    When compatible with the generic version, nodes must list the
-    SoC-specific version corresponding to the platform first
-    followed by the generic version.
-
-  - reg: should contain address and length of the standard XHCI
-    register set for the device.
-  - interrupts: one XHCI interrupt should be described here.
-
-Optional properties:
-  - clocks: reference to the clocks
-  - clock-names: mandatory if there is a second clock, in this case
-    the name must be "core" for the first clock and "reg" for the
-    second one
-  - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
-  - usb3-lpm-capable: determines if platform is USB3 LPM capable
-  - quirk-broken-port-ped: set if the controller has broken port disable mechanism
-  - imod-interval-ns: default interrupt moderation interval is 5000ns
-  - phys : see usb-hcd.yaml in the current directory
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-
-Example:
-	usb@f0931000 {
-		compatible = "generic-xhci";
-		reg = <0xf0931000 0x8c8>;
-		interrupts = <0x0 0x4e 0x0>;
-	};
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.yaml b/Documentation/devicetree/bindings/usb/usb-xhci.yaml
new file mode 100644
index 000000000000..965f87fef702
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/usb-xhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic USB xHCI Controller Device Tree Bindings
+
+maintainers:
+  - Mathias Nyman <mathias.nyman@intel.com>
+
+allOf:
+  - $ref: "usb-hcd.yaml#"
+
+properties:
+  usb2-lpm-disable:
+    description: Indicates if we don't want to enable USB2 HW LPM
+    type: boolean
+
+  usb3-lpm-capable:
+    description: Determines if platform is USB3 LPM capable
+    type: boolean
+
+  quirk-broken-port-ped:
+    description: Set if the controller has broken port disable mechanism
+    type: boolean
+
+  imod-interval-ns:
+    description: Interrupt moderation interval
+    default: 5000
+
+additionalProperties: true
+
+examples:
+  - |
+    usb@f0930000 {
+      compatible = "generic-xhci";
+      reg = <0xf0930000 0x8c8>;
+      interrupts = <0x0 0x4e 0x0>;
+      usb2-lpm-disable;
+      usb3-lpm-capable;
+    };
-- 
2.27.0


^ permalink raw reply related

* [PATCH v3 10/16] dt-bindings: usb: dwc3: Add interrupt-names property support
From: Serge Semin @ 2020-10-20 11:20 UTC (permalink / raw)
  To: Mathias Nyman, Felipe Balbi, Krzysztof Kozlowski,
	Greg Kroah-Hartman, Rob Herring
  Cc: devicetree, linux-snps-arc, linux-mips, Neil Armstrong,
	Martin Blumenstingl, Kevin Hilman, Yoshihiro Shimoda, linux-usb,
	linux-kernel, Lad Prabhakar, Serge Semin, Bjorn Andersson,
	Serge Semin, Manu Gautam, Andy Gross, Pavel Parkhomenko,
	Alexey Malahov, linuxppc-dev, Rob Herring, linux-arm-kernel,
	Roger Quadros
In-Reply-To: <20201020112101.19077-1-Sergey.Semin@baikalelectronics.ru>

The controller driver supports two types of DWC USB3 devices: with a
common interrupt lane and with individual interrupts for each mode. Add
support for both these cases to the DWC USB3 DT schema.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>

---

Changelog v2:
- Grammar fix: "s/both of these cases support/support for both these cases"
- Drop quotes from around the string constants.
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 65bc66ec67d0..23f07222d3d7 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -30,9 +30,20 @@ properties:
       const: snps,dwc3
 
   interrupts:
+    description: |
+      It's either a single common DWC3 interrupt (dwc_usb3) or individual
+      interrupts for the host, gadget and DRD modes.
     minItems: 1
     maxItems: 3
 
+  interrupt-names:
+    minItems: 1
+    maxItems: 3
+    oneOf:
+      - const: dwc_usb3
+      - items:
+          enum: [host, peripheral, otg]
+
   clocks:
     description:
       In general the core supports three types of clocks. bus_early is a
-- 
2.27.0


^ 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