diff mbox

[00/16] dts/dt-bindings: Fix Arm Ltd. ARMv8 "boards"

Message ID 20200505165212.76466-4-andre.przywara@arm.com
State Changes Requested, archived
Headers show

Checks

Context Check Description
robh/checkpatch warning "total: 0 errors, 1 warnings, 18 lines checked"
robh/dt-meta-schema success

Commit Message

Andre Przywara May 5, 2020, 4:51 p.m. UTC
Date: Mon, 4 May 2020 12:43:18 +0100
Subject: [PATCH 03/16] dt-bindings: ehci/ohci: Allow iommus property

A OHCI/EHCI controller could be behind an IOMMU, in which case an iommus
property assigns the stream ID for this device.

Allow that property in the DT bindings to fix a complaint about the Arm Juno
board's DTS file.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 Documentation/devicetree/bindings/usb/generic-ehci.yaml | 3 +++
 Documentation/devicetree/bindings/usb/generic-ohci.yaml | 3 +++
 2 files changed, 6 insertions(+)

Comments

gregkh@linuxfoundation.org May 5, 2020, 5:38 p.m. UTC | #1
On Tue, May 05, 2020 at 05:51:59PM +0100, Andre Przywara wrote:
> Date: Mon, 4 May 2020 12:43:18 +0100
> Subject: [PATCH 03/16] dt-bindings: ehci/ohci: Allow iommus property

Did you mean these lines to be in the patch body?

Something went wrong :(

greg k-h
Robin Murphy May 5, 2020, 5:51 p.m. UTC | #2
On 2020-05-05 5:51 pm, Andre Przywara wrote:
> Date: Mon, 4 May 2020 12:43:18 +0100
> Subject: [PATCH 03/16] dt-bindings: ehci/ohci: Allow iommus property
> 
> A OHCI/EHCI controller could be behind an IOMMU, in which case an iommus
> property assigns the stream ID for this device.

Hmm, pretty much any DMA master device could be behind an IOMMU, and in 
a way that's basically entirely irrelevant to the device itself (and 
thus the consumer of its binding). Is there a better way we can handle 
this than repeating such "semi-standard" properties in individual 
bindings for ever more?

Robin.

> Allow that property in the DT bindings to fix a complaint about the Arm Juno
> board's DTS file.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>   Documentation/devicetree/bindings/usb/generic-ehci.yaml | 3 +++
>   Documentation/devicetree/bindings/usb/generic-ohci.yaml | 3 +++
>   2 files changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> index 10edd05872ea..20664c28bfb2 100644
> --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> @@ -74,6 +74,9 @@ properties:
>     phy-names:
>       const: usb
>   
> +  iommus:
> +    maxItems: 1
> +
>   required:
>     - compatible
>     - reg
> diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> index bcffec1f1341..ff6c04cde695 100644
> --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> @@ -73,6 +73,9 @@ properties:
>     phy-names:
>       const: usb
>   
> +  iommus:
> +    maxItems: 1
> +
>   required:
>     - compatible
>     - reg
>
Andre Przywara May 5, 2020, 6:01 p.m. UTC | #3
On 05/05/2020 18:51, Robin Murphy wrote:
> On 2020-05-05 5:51 pm, Andre Przywara wrote:
>> Date: Mon, 4 May 2020 12:43:18 +0100
>> Subject: [PATCH 03/16] dt-bindings: ehci/ohci: Allow iommus property
>>
>> A OHCI/EHCI controller could be behind an IOMMU, in which case an iommus
>> property assigns the stream ID for this device.
> 
> Hmm, pretty much any DMA master device could be behind an IOMMU, and in
> a way that's basically entirely irrelevant to the device itself (and
> thus the consumer of its binding). Is there a better way we can handle
> this than repeating such "semi-standard" properties in individual
> bindings for ever more?

I was asking exactly the same question to Rob.
Indeed this is more of a parent bus property, if at all, and individual
drivers are not even aware of this.
But what is a device property is the number of device IDs that the
device uses and that would need to be translated into stream IDs.

So I think this is merely saying: just a single device ID.

And no, we couldn't come up with some more generic solution (yet). I
think a similar problem comes up with power-domains and other properties
handled by code in drivers/of.

Cheers,
Andre

> 
> Robin.
> 
>> Allow that property in the DT bindings to fix a complaint about the
>> Arm Juno
>> board's DTS file.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>   Documentation/devicetree/bindings/usb/generic-ehci.yaml | 3 +++
>>   Documentation/devicetree/bindings/usb/generic-ohci.yaml | 3 +++
>>   2 files changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>> b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>> index 10edd05872ea..20664c28bfb2 100644
>> --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>> +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>> @@ -74,6 +74,9 @@ properties:
>>     phy-names:
>>       const: usb
>>   +  iommus:
>> +    maxItems: 1
>> +
>>   required:
>>     - compatible
>>     - reg
>> diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>> b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>> index bcffec1f1341..ff6c04cde695 100644
>> --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>> +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>> @@ -73,6 +73,9 @@ properties:
>>     phy-names:
>>       const: usb
>>   +  iommus:
>> +    maxItems: 1
>> +
>>   required:
>>     - compatible
>>     - reg
>>
Rob Herring May 5, 2020, 10:31 p.m. UTC | #4
On Tue, May 5, 2020 at 12:52 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2020-05-05 5:51 pm, Andre Przywara wrote:
> > Date: Mon, 4 May 2020 12:43:18 +0100
> > Subject: [PATCH 03/16] dt-bindings: ehci/ohci: Allow iommus property
> >
> > A OHCI/EHCI controller could be behind an IOMMU, in which case an iommus
> > property assigns the stream ID for this device.
>
> Hmm, pretty much any DMA master device could be behind an IOMMU, and in
> a way that's basically entirely irrelevant to the device itself (and
> thus the consumer of its binding). Is there a better way we can handle
> this than repeating such "semi-standard" properties in individual
> bindings for ever more?

We did that for pinctrl-* properties which I was somewhat lukewarm on.
I think a lot more nodes have pins than DMA, so I prefer to keep this
explicit. We do allow more than 1 iommus entry which might be device
specific, so somewhere we need to capture how many are allowed/valid.

We could define a 'dma-device.yaml' schema and reference that on all
DMA capable device. Not sure that saves much though.

Rob
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 10edd05872ea..20664c28bfb2 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -74,6 +74,9 @@  properties:
   phy-names:
     const: usb
 
+  iommus:
+    maxItems: 1
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index bcffec1f1341..ff6c04cde695 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -73,6 +73,9 @@  properties:
   phy-names:
     const: usb
 
+  iommus:
+    maxItems: 1
+
 required:
   - compatible
   - reg