lkml.org 
[lkml]   [2022]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] dt-bindings: PCI: host-generic-pci: Allow IOMMU and MSI properties
From
On 2022-08-02 23:21, Rob Herring wrote:
> On Tue, Aug 2, 2022 at 3:26 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2022-07-28 18:51, Rob Herring wrote:
>>> Allow 'iommu-map', 'iommu-map-mask', and 'msi-parent' properties for
>>> generic host. This fixes unevaluated property warnings on Arm Juno, AMD
>>> Seattle, and FSL LS1028a.
>>>
>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>> ---
>>> Documentation/devicetree/bindings/pci/host-generic-pci.yaml | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
>>> index 6bcaa8f2c3cf..d25423aa7167 100644
>>> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
>>> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.yaml
>>> @@ -106,6 +106,9 @@ properties:
>>> maxItems: 3
>>>
>>> dma-coherent: true
>>> + iommu-map: true
>>> + iommu-map-mask: true
>>> + msi-parent: true
>>
>> Hmm, in general this set looks suspiciously incomplete without msi-map
>> and msi-map-mask too. Am I right in thinking that the ideal thing to do
>> here would be to convert pci-msi.txt and pci-iommu.txt to schema and
>> $ref them?
>
> I already added msi-map/msi-map-mask to pci-bus.yaml[1] as well as
> schemas for iommu-map/iommu-map-mask[2] and msi-parent[3]. Since
> msi-map is already in the referenced schema, it is allowed here.
> msi-parent is separate because it is used elsewhere. iommu-map is
> separate largely to make copying pci-iommu.txt as-is easier.
>
> And yes, pci-iommu.txt can now be removed. pci-msi.txt is more
> complicated as all of it hasn't been moved into schemas.

Ah, great! One general comment, though - iommu-map/msi-map have pretty
much grown into common IOMMU/MSI consumer properties by now, so IMO
they'd be better off living alongside their respective iommus/msi-parent
counterparts, so that other consumers like fsl-mc and host1x can
reference a common definition rather than duplicating their own. The
only aspect that should still belong to the PCI binding is the detail of
how PCI B:D:F forms the input ID for the mappings (and equivalently for
other bus bindings).

Thanks,
Robin.

>
> Rob
>
> [1] https://github.com/devicetree-org/dt-schema/commit/109bde712466281e8c96a4fadb0f68e7a90a6eca
> [2] https://github.com/devicetree-org/dt-schema/commit/3d44bf2b46a9ac638550ca3916d7d7f70823bb58
> [3] https://github.com/devicetree-org/dt-schema/commit/59f2e3103b6e776afe4f42e45897f7eabae06fa4

\
 
 \ /
  Last update: 2022-08-03 12:34    [W:0.039 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site