Re: [PATCH 3/6] bus: fsl-mc: return -EPROBE_DEFER when a device is not yet discovered
On 1/7/2021 5:36 PM, Ioana Ciornei wrote: > From: Ioana Ciornei > > The fsl_mc_get_endpoint() should return a pointer to the connected > fsl_mc device, if there is one. By interrogating the MC firmware, we > know if there is an endpoint or not so when the endpoint device is > actually searched on the fsl-mc bus and not found we are hitting the > case in which the device has not been yet discovered by the bus. > > Return -EPROBE_DEFER so that callers can differentiate this case. > > Signed-off-by: Ioana Ciornei Acked-by: Laurentiu Tudor --- Best Regards, Laurentiu > --- > drivers/bus/fsl-mc/fsl-mc-bus.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c > index 34811db074b7..28d5da1c011c 100644 > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c > @@ -936,6 +936,15 @@ struct fsl_mc_device *fsl_mc_get_endpoint(struct > fsl_mc_device *mc_dev) > endpoint_desc.id = endpoint2.id; > endpoint = fsl_mc_device_lookup(&endpoint_desc, mc_bus_dev); > > + /* > + * We know that the device has an endpoint because we verified by > + * interrogating the firmware. This is the case when the device was not > + * yet discovered by the fsl-mc bus, thus the lookup returned NULL. > + * Differentiate this case by returning EPROBE_DEFER. > + */ > + if (!endpoint) > + return ERR_PTR(-EPROBE_DEFER); > + > return endpoint; > } > EXPORT_SYMBOL_GPL(fsl_mc_get_endpoint); >
[PATCH v4] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
From: Ionut-robert Aron Convert fsl,qoriq-mc to YAML in order to automate the verification process of dts files. In addition, update MAINTAINERS accordingly and, while at it, add some missing files. Signed-off-by: Ionut-robert Aron [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] Signed-off-by: Laurentiu Tudor --- Changes in v4: - use $ref to point to fsl,qoriq-mc-dpmac binding Changes in v3: - dropped duplicated "fsl,qoriq-mc-dpmac" schema and replaced with reference to it - fixed a dt_binding_check warning Changes in v2: - fixed errors reported by yamllint - dropped multiple unnecessary quotes - used schema instead of text in description - added constraints on dpmac reg property .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 -- .../bindings/misc/fsl,qoriq-mc.yaml | 186 + .../ethernet/freescale/dpaa2/overview.rst | 5 +- MAINTAINERS | 4 +- 4 files changed, 193 insertions(+), 198 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt deleted file mode 100644 index 7b486d4985dc.. --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ /dev/null @@ -1,196 +0,0 @@ -* Freescale Management Complex - -The Freescale Management Complex (fsl-mc) is a hardware resource -manager that manages specialized hardware objects used in -network-oriented packet processing applications. After the fsl-mc -block is enabled, pools of hardware resources are available, such as -queues, buffer pools, I/O interfaces. These resources are building -blocks that can be used to create functional hardware objects/devices -such as network interfaces, crypto accelerator instances, L2 switches, -etc. - -For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst - -As described in the above overview, all DPAA2 objects in a DPRC share the -same hardware "isolation context" and a 10-bit value called an ICID -(isolation context id) is expressed by the hardware to identify -the requester. - -The generic 'iommus' property is insufficient to describe the relationship -between ICIDs and IOMMUs, so an iommu-map property is used to define -the set of possible ICIDs under a root DPRC and how they map to -an IOMMU. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - -For arm-smmu binding, see: -Documentation/devicetree/bindings/iommu/arm,smmu.yaml. - -The MSI writes are accompanied by sideband data which is derived from the ICID. -The msi-map property is used to associate the devices with both the ITS -controller and the sideband data which accompanies the writes. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -For GICv3 and GIC ITS bindings, see: -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex -compatible with this binding must have Block Revision -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in -the MC control register region. - -- reg -Value type: -Definition: A standard property. Specifies one or two regions -defining the MC's registers: - - -the first region is the command portal for the -this machine and must always be present - - -the second region is the MC control registers. This -region may not be present in some scenarios, such -as in the device tree presented to a virtual machine. - -- ranges -Value type: -Definition: A standard property. Defines the mapping between the child -MC address space and the parent system address space. - -The MC address space is defined by 3 components: - - -Valid values for region type are - 0x0 - MC portals - 0x1 - QBMAN portals - -- #address-cells -Value type: -Definition: Must be 3. (see definition in 'ranges' property) - -- #size-cells -Value type: -Definition: Must be 1. - -Sub-nodes: - -The fsl-mc node may optionally have dpmac sub-nodes that describe -the relationship between the Ethernet MACs which belong to the MC -and the Ethernet PHYs on the system board. - -The dpmac nodes must
[PATCH v3] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
From: Ionut-robert Aron Convert fsl,qoriq-mc to YAML in order to automate the verification process of dts files. In addition, update MAINTAINERS accordingly and, while at it, add some missing files. Signed-off-by: Ionut-robert Aron [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] Signed-off-by: Laurentiu Tudor --- Changes in v3: - dropped duplicated "fsl,qoriq-mc-dpmac" schema and replaced with reference to it - fixed a dt_binding_check warning Changes in v2: - fixed errors reported by yamllint - dropped multiple unnecessary quotes - used schema instead of text in description - added constraints on dpmac reg property .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 -- .../bindings/misc/fsl,qoriq-mc.yaml | 187 + .../ethernet/freescale/dpaa2/overview.rst | 5 +- MAINTAINERS | 4 +- 4 files changed, 194 insertions(+), 198 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt deleted file mode 100644 index 7b486d4985dc.. --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ /dev/null @@ -1,196 +0,0 @@ -* Freescale Management Complex - -The Freescale Management Complex (fsl-mc) is a hardware resource -manager that manages specialized hardware objects used in -network-oriented packet processing applications. After the fsl-mc -block is enabled, pools of hardware resources are available, such as -queues, buffer pools, I/O interfaces. These resources are building -blocks that can be used to create functional hardware objects/devices -such as network interfaces, crypto accelerator instances, L2 switches, -etc. - -For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst - -As described in the above overview, all DPAA2 objects in a DPRC share the -same hardware "isolation context" and a 10-bit value called an ICID -(isolation context id) is expressed by the hardware to identify -the requester. - -The generic 'iommus' property is insufficient to describe the relationship -between ICIDs and IOMMUs, so an iommu-map property is used to define -the set of possible ICIDs under a root DPRC and how they map to -an IOMMU. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - -For arm-smmu binding, see: -Documentation/devicetree/bindings/iommu/arm,smmu.yaml. - -The MSI writes are accompanied by sideband data which is derived from the ICID. -The msi-map property is used to associate the devices with both the ITS -controller and the sideband data which accompanies the writes. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -For GICv3 and GIC ITS bindings, see: -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex -compatible with this binding must have Block Revision -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in -the MC control register region. - -- reg -Value type: -Definition: A standard property. Specifies one or two regions -defining the MC's registers: - - -the first region is the command portal for the -this machine and must always be present - - -the second region is the MC control registers. This -region may not be present in some scenarios, such -as in the device tree presented to a virtual machine. - -- ranges -Value type: -Definition: A standard property. Defines the mapping between the child -MC address space and the parent system address space. - -The MC address space is defined by 3 components: - - -Valid values for region type are - 0x0 - MC portals - 0x1 - QBMAN portals - -- #address-cells -Value type: -Definition: Must be 3. (see definition in 'ranges' property) - -- #size-cells -Value type: -Definition: Must be 1. - -Sub-nodes: - -The fsl-mc node may optionally have dpmac sub-nodes that describe -the relationship between the Ethernet MACs which belong to the MC -and the Ethernet PHYs on the system board. - -The dpmac nodes must be under a node named "dpmacs" which contai
Re: [PATCH v2 2/2] dt-bindings: misc: convert fsl, qoriq-mc from txt to YAML
On 11/10/2020 7:20 PM, Rob Herring wrote:
> On Mon, Nov 9, 2020 at 4:11 PM Rob Herring wrote:
>>
>> On Mon, 09 Nov 2020 12:46:35 +0200, Laurentiu Tudor wrote:
>>> From: Ionut-robert Aron
>>>
>>> Convert fsl,qoriq-mc to YAML in order to automate the verification
>>> process of dts files. In addition, update MAINTAINERS accordingly
>>> and, while at it, add some missing files.
>>>
>>> Signed-off-by: Ionut-robert Aron
>>> [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema]
>>> Signed-off-by: Laurentiu Tudor
>>> ---
>>> Changes in v2:
>>> - fixed errors reported by yamllint
>>> - dropped multiple unnecessary quotes
>>> - used schema instead of text in description
>>> - added constraints on dpmac reg property
>>>
>>> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196
>>> .../bindings/misc/fsl,qoriq-mc.yaml | 210 ++
>>> .../ethernet/freescale/dpaa2/overview.rst | 5 +-
>>> MAINTAINERS | 4 +-
>>> 4 files changed, 217 insertions(+), 198 deletions(-)
>>> delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>> create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml
>>>
>>
>> Applied, thanks!
>
> And now dropped. This duplicates what's in commit 0dbcd4991719
> ("dt-bindings: net: add the DPAA2 MAC DTS definition") and has
> warnings from it:
>
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.example.dt.yaml:
> dpmac@1: $nodename:0: 'dpmac@1' does not match '^ethernet(@.*)?$'
> From schema:
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
>
My patch converts the .txt devicetree/bindings/misc/fsl,qoriq-mc.yaml
while the commit you mention creates
devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml, but at a first sight
there seems to be some duplication. Will sync internally with my
colleagues and return with a resolution. Thanks and sorry for the trouble.
---
Best Regards, Laurentiu
[PATCH v2 2/2] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
From: Ionut-robert Aron Convert fsl,qoriq-mc to YAML in order to automate the verification process of dts files. In addition, update MAINTAINERS accordingly and, while at it, add some missing files. Signed-off-by: Ionut-robert Aron [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] Signed-off-by: Laurentiu Tudor --- Changes in v2: - fixed errors reported by yamllint - dropped multiple unnecessary quotes - used schema instead of text in description - added constraints on dpmac reg property .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 .../bindings/misc/fsl,qoriq-mc.yaml | 210 ++ .../ethernet/freescale/dpaa2/overview.rst | 5 +- MAINTAINERS | 4 +- 4 files changed, 217 insertions(+), 198 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt deleted file mode 100644 index 7b486d4985dc.. --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ /dev/null @@ -1,196 +0,0 @@ -* Freescale Management Complex - -The Freescale Management Complex (fsl-mc) is a hardware resource -manager that manages specialized hardware objects used in -network-oriented packet processing applications. After the fsl-mc -block is enabled, pools of hardware resources are available, such as -queues, buffer pools, I/O interfaces. These resources are building -blocks that can be used to create functional hardware objects/devices -such as network interfaces, crypto accelerator instances, L2 switches, -etc. - -For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst - -As described in the above overview, all DPAA2 objects in a DPRC share the -same hardware "isolation context" and a 10-bit value called an ICID -(isolation context id) is expressed by the hardware to identify -the requester. - -The generic 'iommus' property is insufficient to describe the relationship -between ICIDs and IOMMUs, so an iommu-map property is used to define -the set of possible ICIDs under a root DPRC and how they map to -an IOMMU. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - -For arm-smmu binding, see: -Documentation/devicetree/bindings/iommu/arm,smmu.yaml. - -The MSI writes are accompanied by sideband data which is derived from the ICID. -The msi-map property is used to associate the devices with both the ITS -controller and the sideband data which accompanies the writes. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -For GICv3 and GIC ITS bindings, see: -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex -compatible with this binding must have Block Revision -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in -the MC control register region. - -- reg -Value type: -Definition: A standard property. Specifies one or two regions -defining the MC's registers: - - -the first region is the command portal for the -this machine and must always be present - - -the second region is the MC control registers. This -region may not be present in some scenarios, such -as in the device tree presented to a virtual machine. - -- ranges -Value type: -Definition: A standard property. Defines the mapping between the child -MC address space and the parent system address space. - -The MC address space is defined by 3 components: - - -Valid values for region type are - 0x0 - MC portals - 0x1 - QBMAN portals - -- #address-cells -Value type: -Definition: Must be 3. (see definition in 'ranges' property) - -- #size-cells -Value type: -Definition: Must be 1. - -Sub-nodes: - -The fsl-mc node may optionally have dpmac sub-nodes that describe -the relationship between the Ethernet MACs which belong to the MC -and the Ethernet PHYs on the system board. - -The dpmac nodes must be under a node named "dpmacs" which contains -the following properties: - -- #address-cells - Value type: - Definition: Must be present if dpmac sub-nodes are d
[PATCH v2 1/2] dt-bindings: misc: convert fsl,dpaa2-console from txt to YAML
From: Ionut-robert Aron Convert fsl,dpaa2-console to YAML in order to automate the verification process of dts files. Signed-off-by: Ionut-robert Aron Signed-off-by: Laurentiu Tudor --- Changes in v2: - add missing additionalProperties .../bindings/misc/fsl,dpaa2-console.txt | 11 .../bindings/misc/fsl,dpaa2-console.yaml | 25 +++ 2 files changed, 25 insertions(+), 11 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt deleted file mode 100644 index 1442ba5d2d98.. --- a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt +++ /dev/null @@ -1,11 +0,0 @@ -DPAA2 console support - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,dpaa2-console". -- reg -Value type: -Definition: A standard property. Specifies the region where the MCFBA -(MC firmware base address) register can be found. diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml new file mode 100644 index ..271a3eafc054 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml @@ -0,0 +1,25 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/fsl,dpaa2-console.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DPAA2 console support + +maintainers: + - Laurentiu Tudor + +properties: + compatible: +const: "fsl,dpaa2-console" + + reg: +description: A standard property. Specifies the region where the MCFBA +(MC firmware base address) register can be found. + +required: + - compatible + - reg + +additionalProperties: false -- 2.17.1
Re: [PATCH 2/2] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
Hi Rob, On 11/5/2020 9:17 PM, Rob Herring wrote: > On Thu, Nov 05, 2020 at 04:11:14PM +0200, Laurentiu Tudor wrote: >> From: Ionut-robert Aron >> >> Convert fsl,qoriq-mc to YAML in order to automate the verification >> process of dts files. In addition, update MAINTAINERS accordingly >> and, while at it, add some missing files. >> >> Signed-off-by: Ionut-robert Aron >> [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] >> Signed-off-by: Laurentiu Tudor >> --- >> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 >> .../bindings/misc/fsl,qoriq-mc.yaml | 218 ++ >> .../ethernet/freescale/dpaa2/overview.rst | 5 +- >> MAINTAINERS | 4 +- >> 4 files changed, 225 insertions(+), 198 deletions(-) >> delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt >> create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml > > [...] > >> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml >> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml >> new file mode 100644 >> index ..9e89fd8eb635 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml >> @@ -0,0 +1,218 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +# Copyright 2020 NXP >> +%YAML 1.2 >> +--- >> +$id: >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fmisc%2Ffsl%2Cqoriq-mc.yaml%23&data=04%7C01%7Claurentiu.tudor%40nxp.com%7C64a5aeb6fee5459041db08d881bf7bf2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637402006701140599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fkXEIYUqXK1Dn6AqZtYLzro8nwJNCPJFI1Q9F9fRYxE%3D&reserved=0 >> +$schema: >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=04%7C01%7Claurentiu.tudor%40nxp.com%7C64a5aeb6fee5459041db08d881bf7bf2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637402006701140599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X7k0Sxh7uPo11GgkGCeaKKMzHdu0gtphKheyJeROZ9Q%3D&reserved=0 >> + >> +maintainers: >> + - Laurentiu Tudor >> + >> +title: Freescale Management Complex >> + >> +description: | >> + The Freescale Management Complex (fsl-mc) is a hardware resource >> + manager that manages specialized hardware objects used in >> + network-oriented packet processing applications. After the fsl-mc >> + block is enabled, pools of hardware resources are available, such as >> + queues, buffer pools, I/O interfaces. These resources are building >> + blocks that can be used to create functional hardware objects/devices >> + such as network interfaces, crypto accelerator instances, L2 switches, >> + etc. >> + >> + For an overview of the DPAA2 architecture and fsl-mc bus see: >> + Documentation/networking/device_drivers/freescale/dpaa2/overview.rst >> + >> + As described in the above overview, all DPAA2 objects in a DPRC share the >> + same hardware "isolation context" and a 10-bit value called an ICID >> + (isolation context id) is expressed by the hardware to identify >> + the requester. >> + >> + The generic 'iommus' property is insufficient to describe the relationship >> + between ICIDs and IOMMUs, so an iommu-map property is used to define >> + the set of possible ICIDs under a root DPRC and how they map to >> + an IOMMU. >> + >> + For generic IOMMU bindings, see: >> + Documentation/devicetree/bindings/iommu/iommu.txt. >> + >> + For arm-smmu binding, see: >> + Documentation/devicetree/bindings/iommu/arm,smmu.yaml. >> + >> + MC firmware binary images can be found here: >> + >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNXP%2Fqoriq-mc-binary&data=04%7C01%7Claurentiu.tudor%40nxp.com%7C64a5aeb6fee5459041db08d881bf7bf2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637402006701140599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QKyEydXdS2AzqS7BlXVXDXpdjHfGL1%2BEdx95F1j5OHM%3D&reserved=0 >> + >> +properties: >> + compatible: >> +const: "fsl,qoriq-mc" > > Don't need quotes. > >> +description: "Must be 'fsl,qoriq-mc'. A Freescale Management Complex > > Drop &g
[PATCH 2/2] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
From: Ionut-robert Aron Convert fsl,qoriq-mc to YAML in order to automate the verification process of dts files. In addition, update MAINTAINERS accordingly and, while at it, add some missing files. Signed-off-by: Ionut-robert Aron [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] Signed-off-by: Laurentiu Tudor --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 .../bindings/misc/fsl,qoriq-mc.yaml | 218 ++ .../ethernet/freescale/dpaa2/overview.rst | 5 +- MAINTAINERS | 4 +- 4 files changed, 225 insertions(+), 198 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt deleted file mode 100644 index 7b486d4985dc.. --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ /dev/null @@ -1,196 +0,0 @@ -* Freescale Management Complex - -The Freescale Management Complex (fsl-mc) is a hardware resource -manager that manages specialized hardware objects used in -network-oriented packet processing applications. After the fsl-mc -block is enabled, pools of hardware resources are available, such as -queues, buffer pools, I/O interfaces. These resources are building -blocks that can be used to create functional hardware objects/devices -such as network interfaces, crypto accelerator instances, L2 switches, -etc. - -For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst - -As described in the above overview, all DPAA2 objects in a DPRC share the -same hardware "isolation context" and a 10-bit value called an ICID -(isolation context id) is expressed by the hardware to identify -the requester. - -The generic 'iommus' property is insufficient to describe the relationship -between ICIDs and IOMMUs, so an iommu-map property is used to define -the set of possible ICIDs under a root DPRC and how they map to -an IOMMU. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - -For arm-smmu binding, see: -Documentation/devicetree/bindings/iommu/arm,smmu.yaml. - -The MSI writes are accompanied by sideband data which is derived from the ICID. -The msi-map property is used to associate the devices with both the ITS -controller and the sideband data which accompanies the writes. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -For GICv3 and GIC ITS bindings, see: -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex -compatible with this binding must have Block Revision -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in -the MC control register region. - -- reg -Value type: -Definition: A standard property. Specifies one or two regions -defining the MC's registers: - - -the first region is the command portal for the -this machine and must always be present - - -the second region is the MC control registers. This -region may not be present in some scenarios, such -as in the device tree presented to a virtual machine. - -- ranges -Value type: -Definition: A standard property. Defines the mapping between the child -MC address space and the parent system address space. - -The MC address space is defined by 3 components: - - -Valid values for region type are - 0x0 - MC portals - 0x1 - QBMAN portals - -- #address-cells -Value type: -Definition: Must be 3. (see definition in 'ranges' property) - -- #size-cells -Value type: -Definition: Must be 1. - -Sub-nodes: - -The fsl-mc node may optionally have dpmac sub-nodes that describe -the relationship between the Ethernet MACs which belong to the MC -and the Ethernet PHYs on the system board. - -The dpmac nodes must be under a node named "dpmacs" which contains -the following properties: - -- #address-cells - Value type: - Definition: Must be present if dpmac sub-nodes are defined and must - have a value of 1. - -- #size-cells - Value type: - Definition: Must be present if dpmac sub-no
[PATCH 1/2] dt-bindings: misc: convert fsl,dpaa2-console from txt to YAML
From: Ionut-robert Aron Convert fsl,dpaa2-console to YAML in order to automate the verification process of dts files. Signed-off-by: Ionut-robert Aron Signed-off-by: Laurentiu Tudor --- .../bindings/misc/fsl,dpaa2-console.txt | 11 - .../bindings/misc/fsl,dpaa2-console.yaml | 23 +++ 2 files changed, 23 insertions(+), 11 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt deleted file mode 100644 index 1442ba5d2d98.. --- a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt +++ /dev/null @@ -1,11 +0,0 @@ -DPAA2 console support - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,dpaa2-console". -- reg -Value type: -Definition: A standard property. Specifies the region where the MCFBA -(MC firmware base address) register can be found. diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml new file mode 100644 index ..9ffb864d8b58 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml @@ -0,0 +1,23 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/fsl,dpaa2-console.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DPAA2 console support + +maintainers: + - Laurentiu Tudor + +properties: + compatible: +const: "fsl,dpaa2-console" + + reg: +description: A standard property. Specifies the region where the MCFBA +(MC firmware base address) register can be found. + +required: + - compatible + - reg -- 2.17.1
Re: [PATCH net-next 5/6] dpaa_eth: change DMA device
On 22.10.2019 12:10, Madalin-cristian Bucur wrote:
>> -Original Message-
>> From: Laurentiu Tudor
>> Sent: Tuesday, October 22, 2019 11:50 AM
>> To: Madalin-cristian Bucur ; da...@davemloft.net;
>> netdev@vger.kernel.org
>> Cc: Roy Pledge
>> Subject: Re: [PATCH net-next 5/6] dpaa_eth: change DMA device
>>
>> Hello,
>>
>> On 21.10.2019 15:28, Madalin-cristian Bucur wrote:
>>> The DPAA Ethernet driver is using the FMan MAC as the device for DMA
>>> mapping. This is not actually correct, as the real DMA device is the
>>> FMan port (the FMan Rx port for reception and the FMan Tx port for
>>> transmission). Changing the device used for DMA mapping to the Fman
>>> Rx and Tx port devices.
>>>
>>> Signed-off-by: Madalin Bucur
>>> Signed-off-by: Laurentiu Tudor
>>> ---
>>>drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 105 +
>>
>>>drivers/net/ethernet/freescale/dpaa/dpaa_eth.h | 8 +-
>>>2 files changed, 62 insertions(+), 51 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
>> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
>>> index 8d5686d88d30..639cafaa59b8 100644
>>> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
>>> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
>>> @@ -1335,15 +1335,15 @@ static void dpaa_fd_release(const struct
>> net_device *net_dev,
>>> vaddr = phys_to_virt(qm_fd_addr(fd));
>>> sgt = vaddr + qm_fd_get_offset(fd);
>>>
>>> - dma_unmap_single(dpaa_bp->dev, qm_fd_addr(fd), dpaa_bp->size,
>>> -DMA_FROM_DEVICE);
>>> + dma_unmap_single(dpaa_bp->priv->rx_dma_dev, qm_fd_addr(fd),
>>> +dpaa_bp->size, DMA_FROM_DEVICE);
>>>
>>> dpaa_release_sgt_members(sgt);
>>>
>>> - addr = dma_map_single(dpaa_bp->dev, vaddr, dpaa_bp->size,
>>> - DMA_FROM_DEVICE);
>>> - if (dma_mapping_error(dpaa_bp->dev, addr)) {
>>> - dev_err(dpaa_bp->dev, "DMA mapping failed");
>>> + addr = dma_map_single(dpaa_bp->priv->rx_dma_dev, vaddr,
>>> + dpaa_bp->size, DMA_FROM_DEVICE);
>>> + if (dma_mapping_error(dpaa_bp->priv->rx_dma_dev, addr)) {
>>> + netdev_err(net_dev, "DMA mapping failed");
>>> return;
>>> }
>>> bm_buffer_set64(&bmb, addr);
>>> @@ -1488,7 +1488,7 @@ static int dpaa_enable_tx_csum(struct dpaa_priv
>> *priv,
>>>
>>>static int dpaa_bp_add_8_bufs(const struct dpaa_bp *dpaa_bp)
>>>{
>>> - struct device *dev = dpaa_bp->dev;
>>> + struct net_device *net_dev = dpaa_bp->priv->net_dev;
>>> struct bm_buffer bmb[8];
>>> dma_addr_t addr;
>>> void *new_buf;
>>> @@ -1497,16 +1497,18 @@ static int dpaa_bp_add_8_bufs(const struct
>> dpaa_bp *dpaa_bp)
>>> for (i = 0; i < 8; i++) {
>>> new_buf = netdev_alloc_frag(dpaa_bp->raw_size);
>>> if (unlikely(!new_buf)) {
>>> - dev_err(dev, "netdev_alloc_frag() failed, size %zu\n",
>>> - dpaa_bp->raw_size);
>>> + netdev_err(net_dev,
>>> + "netdev_alloc_frag() failed, size %zu\n",
>>> + dpaa_bp->raw_size);
>>> goto release_previous_buffs;
>>> }
>>> new_buf = PTR_ALIGN(new_buf, SMP_CACHE_BYTES);
>>>
>>> - addr = dma_map_single(dev, new_buf,
>>> + addr = dma_map_single(dpaa_bp->priv->rx_dma_dev, new_buf,
>>> dpaa_bp->size, DMA_FROM_DEVICE);
>>> - if (unlikely(dma_mapping_error(dev, addr))) {
>>> - dev_err(dpaa_bp->dev, "DMA map failed");
>>> + if (unlikely(dma_mapping_error(dpaa_bp->priv->rx_dma_dev,
>>> + addr))) {
>>> + netdev_err(net_dev, "DMA map failed");
>>> goto release_previous_buffs;
>>> }
>>>
>>> @@ -1634,7 +1636,7 @@ static struc
Re: [PATCH net-next 5/6] dpaa_eth: change DMA device
Hello,
On 21.10.2019 15:28, Madalin-cristian Bucur wrote:
> The DPAA Ethernet driver is using the FMan MAC as the device for DMA
> mapping. This is not actually correct, as the real DMA device is the
> FMan port (the FMan Rx port for reception and the FMan Tx port for
> transmission). Changing the device used for DMA mapping to the Fman
> Rx and Tx port devices.
>
> Signed-off-by: Madalin Bucur
> Signed-off-by: Laurentiu Tudor
> ---
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 105
> +
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.h | 8 +-
> 2 files changed, 62 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 8d5686d88d30..639cafaa59b8 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -1335,15 +1335,15 @@ static void dpaa_fd_release(const struct net_device
> *net_dev,
> vaddr = phys_to_virt(qm_fd_addr(fd));
> sgt = vaddr + qm_fd_get_offset(fd);
>
> - dma_unmap_single(dpaa_bp->dev, qm_fd_addr(fd), dpaa_bp->size,
> - DMA_FROM_DEVICE);
> + dma_unmap_single(dpaa_bp->priv->rx_dma_dev, qm_fd_addr(fd),
> + dpaa_bp->size, DMA_FROM_DEVICE);
>
> dpaa_release_sgt_members(sgt);
>
> - addr = dma_map_single(dpaa_bp->dev, vaddr, dpaa_bp->size,
> - DMA_FROM_DEVICE);
> - if (dma_mapping_error(dpaa_bp->dev, addr)) {
> - dev_err(dpaa_bp->dev, "DMA mapping failed");
> + addr = dma_map_single(dpaa_bp->priv->rx_dma_dev, vaddr,
> + dpaa_bp->size, DMA_FROM_DEVICE);
> + if (dma_mapping_error(dpaa_bp->priv->rx_dma_dev, addr)) {
> + netdev_err(net_dev, "DMA mapping failed");
> return;
> }
> bm_buffer_set64(&bmb, addr);
> @@ -1488,7 +1488,7 @@ static int dpaa_enable_tx_csum(struct dpaa_priv *priv,
>
> static int dpaa_bp_add_8_bufs(const struct dpaa_bp *dpaa_bp)
> {
> - struct device *dev = dpaa_bp->dev;
> + struct net_device *net_dev = dpaa_bp->priv->net_dev;
> struct bm_buffer bmb[8];
> dma_addr_t addr;
> void *new_buf;
> @@ -1497,16 +1497,18 @@ static int dpaa_bp_add_8_bufs(const struct dpaa_bp
> *dpaa_bp)
> for (i = 0; i < 8; i++) {
> new_buf = netdev_alloc_frag(dpaa_bp->raw_size);
> if (unlikely(!new_buf)) {
> - dev_err(dev, "netdev_alloc_frag() failed, size %zu\n",
> - dpaa_bp->raw_size);
> + netdev_err(net_dev,
> +"netdev_alloc_frag() failed, size %zu\n",
> +dpaa_bp->raw_size);
> goto release_previous_buffs;
> }
> new_buf = PTR_ALIGN(new_buf, SMP_CACHE_BYTES);
>
> - addr = dma_map_single(dev, new_buf,
> + addr = dma_map_single(dpaa_bp->priv->rx_dma_dev, new_buf,
> dpaa_bp->size, DMA_FROM_DEVICE);
> - if (unlikely(dma_mapping_error(dev, addr))) {
> - dev_err(dpaa_bp->dev, "DMA map failed");
> + if (unlikely(dma_mapping_error(dpaa_bp->priv->rx_dma_dev,
> +addr))) {
> + netdev_err(net_dev, "DMA map failed");
> goto release_previous_buffs;
> }
>
> @@ -1634,7 +1636,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
> dpaa_priv *priv,
>
> if (unlikely(qm_fd_get_format(fd) == qm_fd_sg)) {
> nr_frags = skb_shinfo(skb)->nr_frags;
> - dma_unmap_single(dev, addr,
> + dma_unmap_single(priv->tx_dma_dev, addr,
>qm_fd_get_offset(fd) + DPAA_SGT_SIZE,
>dma_dir);
>
> @@ -1644,21 +1646,21 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const
> struct dpaa_priv *priv,
> sgt = phys_to_virt(addr + qm_fd_get_offset(fd));
>
> /* sgt[0] is from lowmem, was dma_map_single()-ed */
> - dma_unmap_single(dev, qm_sg_addr(&sgt[0]),
> + dma_unmap_single(priv->tx_dma_dev, qm_sg_addr(&sgt[0]),
>qm_sg_entry
RE: [PATCH 0/5] soc: fsl: add device links support for devices on the fsl-mc bus
> -Original Message- > From: Ioana Ciornei > Sent: Monday, December 10, 2018 6:50 PM > > The fsl-mc bus discovers and exports devices dynamically allocated > by the Management Complex firmware. > This patch set adds the ability to automatically create a device link > between a consumer device on the fsl-mc bus and a supplier one. > For example, a dpni device (a network interface) requests access to a > dpio device (I/O portal) using the dpaa2_io_service_register function > which is enhanced to also add the corresponding device link between > them. > > The first 3 patches set the stage for a proper handling of device > links while the following 2 are the ones that add the actual links. > > The internal management of the links is not exported to the consumer > driver, but it's rather included in the functions that actually allocate > the provider device: fsl_mc_portal_allocate, fsl_mc_object_allocate and > dpaa2_io_service_register. > > Ioana Ciornei (4): > soc: fsl: dpio: keep a per dpio device MC portal > soc: fsl: dpio: store a backpointer to the device backing the dpaa2_io > soc: fsl: dpio: add a device_link at dpaa2_io_service_register > bus: fsl-mc: automatically add a device_link on > fsl_mc_[portal,object]_allocate > > Roy Pledge (1): > soc: fsl: dpio: perform DPIO Reset on Probe > > drivers/bus/fsl-mc/fsl-mc-allocator.c| 11 +++ > drivers/bus/fsl-mc/mc-io.c | 13 + > drivers/crypto/caam/caamalg_qi2.c| 6 +++--- > drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 9 + > drivers/soc/fsl/dpio/dpio-cmd.h | 1 + > drivers/soc/fsl/dpio/dpio-driver.c | 18 +- > drivers/soc/fsl/dpio/dpio-service.c | 23 > --- > drivers/soc/fsl/dpio/dpio.c | 23 > +++ > drivers/soc/fsl/dpio/dpio.h | 4 > include/linux/fsl/mc.h | 1 + > include/soc/fsl/dpaa2-io.h | 9 ++--- > 11 files changed, 96 insertions(+), 22 deletions(-) Reviewed-by: Laurentiu Tudor --- Best Regards, Laurentiu
[PATCH v3 01/22] soc/fsl/qman: fixup liodns only on ppc targets
From: Laurentiu Tudor
ARM SoCs use SMMU so the liodn fixup done in the qman driver is no
longer making sense and it also breaks the ICID settings inherited
from u-boot. Do the fixups only for PPC targets.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/qman_ccsr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
b/drivers/soc/fsl/qbman/qman_ccsr.c
index 79cba58387a5..619e22030460 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -597,6 +597,7 @@ static int qman_init_ccsr(struct device *dev)
#define LIO_CFG_LIODN_MASK 0x0fff
void qman_liodn_fixup(u16 channel)
{
+#ifdef CONFIG_PPC
static int done;
static u32 liodn_offset;
u32 before, after;
@@ -616,6 +617,7 @@ void qman_liodn_fixup(u16 channel)
qm_ccsr_out(REG_REV3_QCSP_LIO_CFG(idx), after);
else
qm_ccsr_out(REG_QCSP_LIO_CFG(idx), after);
+#endif
}
#define IO_CFG_SDEST_MASK 0x00ff
--
2.17.1
Re: [PATCH 00/21] SMMU enablement for NXP LS1043A and LS1046A
On 20.09.2018 14:49, Robin Murphy wrote:
> On 20/09/18 11:38, Laurentiu Tudor wrote:
>>
>>
>> On 19.09.2018 17:37, Robin Murphy wrote:
>>> On 19/09/18 15:18, Laurentiu Tudor wrote:
>>>> Hi Robin,
>>>>
>>>> On 19.09.2018 16:25, Robin Murphy wrote:
>>>>> Hi Laurentiu,
>>>>>
>>>>> On 19/09/18 13:35, laurentiu.tu...@nxp.com wrote:
>>>>>> From: Laurentiu Tudor
>>>>>>
>>>>>> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
>>>>>> and consists mostly in important driver fixes and the required device
>>>>>> tree updates. It touches several subsystems and consists of three
>>>>>> main
>>>>>> parts:
>>>>>> - changes in soc/drivers/fsl/qbman drivers adding iommu
>>>>>> mapping of
>>>>>> reserved memory areas, fixes and defered probe support
>>>>>> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
>>>>>> consisting in misc dma mapping related fixes and probe ordering
>>>>>> - addition of the actual arm smmu device tree node together with
>>>>>> various adjustments to the device trees
>>>>>>
>>>>>> Performance impact
>>>>>>
>>>>>> Running iperf benchmarks in a back-to-back setup (both sides
>>>>>> having smmu enabled) on a 10GBps port show an important
>>>>>> networking performance degradation of around %40 (9.48Gbps
>>>>>> linerate vs 5.45Gbps). If you need performance but without
>>>>>> SMMU support you can use "iommu.passthrough=1" to disable
>>>>>> SMMU.
>
> I should have said before - thanks for the numbers there as well. Always
> good to add another datapoint to my collection. If you're interested
> I've added SMMUv2 support to the "non-strict mode" series (of which I
> should be posting v8 soon), so it might be fun to see how well that
> works on MMU-500 in the real world.
Hmm, I think I gave those a try some weeks ago and vaguely remember that
I did see improvements. Can't remember the numbers off the top of my
head but I'll re-test with the latest spin and update the numbers.
>>>>>>
>>>>>> USB issue and workaround
>>>>>>
>>>>>> There's a problem with the usb controllers in these chips
>>>>>> generating smaller, 40-bit wide dma addresses instead of the
>>>>>> 48-bit
>>>>>> supported at the smmu input. So you end up in a situation
>>>>>> where the
>>>>>> smmu is mapped with 48-bit address translations, but the
>>>>>> device
>>>>>> generates transactions with clipped 40-bit addresses, thus
>>>>>> smmu
>>>>>> context faults are triggered. I encountered a similar
>>>>>> situation for
>>>>>> mmc that I managed to fix in software [1] however for USB I
>>>>>> did not
>>>>>> find a proper place in the code to add a similar fix. The only
>>>>>> workaround I found was to add this kernel parameter which
>>>>>> limits the
>>>>>> usb dma to 32-bit size: "xhci-hcd.quirks=0x80".
>>>>>> This workaround if far from ideal, so any suggestions for a
>>>>>> code
>>>>>> based workaround in this area would be greatly appreciated.
>>>>>
>>>>> If you have a nominally-64-bit device with a
>>>>> narrower-than-the-main-interconnect link in front of it, that should
>>>>> already be fixed in 4.19-rc by bus_dma_mask picking up DT dma-ranges,
>>>>> provided the interconnect hierarchy can be described appropriately (or
>>>>> at least massaged sufficiently to satisfy the binding), e.g.:
>>>>>
>>>>> / {
>>>>> ...
>>>>>
>>>>> soc {
>>>>> ranges;
>>>>> dma-ranges = <0 0 1 0>;
>>>>>
>>>>> dev_48bit { ... };
>>>>>
>>>>> periph_bus {
>>>>> ranges;
>>>>> dma-ranges = <
Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
Hi Andrew, On 04/05/2018 03:48 PM, Andrew Lunn wrote: >>> Hi Laurentiu >>> >>> So i can use switchdev without it? I can modprobe the switchdev >>> driver, all the physical interfaces will appear, and i can use ip addr >>> add etc. I do not need to use a user space tool at all in order to use >>> the network functionality? >> >> Absolutely! > > Great. > > Then the easiest way forwards is to simply drop the IOCTL code for the > moment. Get the basic support for the hardware into the kernel > first. Then come back later to look at dynamic behaviour which needs > some form of configuration. Hmm, not sure I understand. We already have a fully functional ethernet driver [1] and a switch driver [2] ... >> In normal use cases the system designer, depending on the requirements, >> configures the various devices that it desires through a firmware >> configuration (think something like a device tree). The devices >> configured are presented on the mc-bus and probed normally by the >> kernel. The standard networking linux tools can be used as expected. > > So what you should probably do is start a discussion on what this > device tree binding looks like. But you need to be careful even > here. Device tree describes the hardware, not how you configure the > hardware. So maybe DT does not actually fit. It's not an actual device tree, but a configuration file that happens to reuse the DTS format. I guess my analogy with a device tree was not the best. Detailed documentation on the syntax can be found here [3], chapter 22. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/fsl-dpaa2/ethernet [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/fsl-dpaa2/ethsw [3] https://www.nxp.com/docs/en/user-guide/DPAA2_UM.pdf --- Best Regards, Laurentiu
Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
Hi Greg, On 04/05/2018 03:30 PM, gregkh wrote: > On Thu, Apr 05, 2018 at 10:30:01AM +0000, Laurentiu Tudor wrote: >> Hello, >> >> My 2c below. >> >> On 04/04/2018 03:42 PM, Andrew Lunn wrote: >>>> I hear you. It is more complicated this way...having all these individual >>>> objects vs just a single "bundle" of them that represents a NIC. But, >>>> that's >>>> the way the DPAA2 hardware is, and we're implementing kernel support for >>>> the hardware as it is. >>> >>> Hi Stuart >>> >>> I see we are not making any progress here. >>> >>> So what i suggest is you post the kernel code and configuration tool >>> concept to netdev for a full review. You want reviews from David >>> Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc. >>> >> >> I think that the discussion steered too much towards networking related >> topics, while this ioctl doesn't have much to do with networking. >> It's just an ioctl for our mc-bus bus driver that is used to manage the >> devices on this bus through userspace tools. >> In addition, I'd drop any mention of our reference user space app >> (restool) to emphasize that this ioctl is not added just for a >> particular user space app. I think Stuart also mentioned this. > > I'm not going to take a "generic device configuration ioctl" patch > unless it is documented to all exactly what it does, and why it is > there. The ioctl() is just a simple pass-through interface to the firmware. It passes commands to the firmware and returns the response back to the userspace. Thus the ABI used by the firmware applies for this ioctl() and it is documented in detail here: https://www.nxp.com/docs/en/user-guide/DPAA2_UM.pdf --- Best Regards, Laurentiu
Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
On 04/05/2018 02:47 PM, Andrew Lunn wrote: > On Thu, Apr 05, 2018 at 10:30:01AM +0000, Laurentiu Tudor wrote: >> Hello, >> >> My 2c below. >> >> On 04/04/2018 03:42 PM, Andrew Lunn wrote: >>>> I hear you. It is more complicated this way...having all these individual >>>> objects vs just a single "bundle" of them that represents a NIC. But, >>>> that's >>>> the way the DPAA2 hardware is, and we're implementing kernel support for >>>> the hardware as it is. >>> >>> Hi Stuart >>> >>> I see we are not making any progress here. >>> >>> So what i suggest is you post the kernel code and configuration tool >>> concept to netdev for a full review. You want reviews from David >>> Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc. >>> >> >> I think that the discussion steered too much towards networking related >> topics, while this ioctl doesn't have much to do with networking. > > Hi Laurentiu > > So i can use switchdev without it? I can modprobe the switchdev > driver, all the physical interfaces will appear, and i can use ip addr > add etc. I do not need to use a user space tool at all in order to use > the network functionality? Absolutely! In normal use cases the system designer, depending on the requirements, configures the various devices that it desires through a firmware configuration (think something like a device tree). The devices configured are presented on the mc-bus and probed normally by the kernel. The standard networking linux tools can be used as expected. The ioctl is necessary only for more advanced use cases that are supported by this bus. Think "more dynamic" scenarios that involve linking & unlinking various devices at runtime, maybe some virtualization scenarios. Unfortunately I'm not the architect type of guy so I don't have more specific examples to better illustrate ... --- Best Regards, Laurentiu
Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
Hello, My 2c below. On 04/04/2018 03:42 PM, Andrew Lunn wrote: >> I hear you. It is more complicated this way...having all these individual >> objects vs just a single "bundle" of them that represents a NIC. But, that's >> the way the DPAA2 hardware is, and we're implementing kernel support for >> the hardware as it is. > > Hi Stuart > > I see we are not making any progress here. > > So what i suggest is you post the kernel code and configuration tool > concept to netdev for a full review. You want reviews from David > Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc. > I think that the discussion steered too much towards networking related topics, while this ioctl doesn't have much to do with networking. It's just an ioctl for our mc-bus bus driver that is used to manage the devices on this bus through userspace tools. In addition, I'd drop any mention of our reference user space app (restool) to emphasize that this ioctl is not added just for a particular user space app. I think Stuart also mentioned this. --- Thanks & Best Regards, Laurentiu
Re: [PATCH v6 0/6] staging: Introduce DPAA2 Ethernet Switch driver
Hi Dan, On 03/15/2018 12:56 PM, Dan Carpenter wrote: > On Thu, Mar 15, 2018 at 12:44:37AM +0100, Andrew Lunn wrote: >> On Wed, Mar 14, 2018 at 10:55:52AM -0500, Razvan Stefanescu wrote: >>> This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs >>> with DPAA2 (DataPath Acceleration Architecture v2). The driver manages >>> switch objects discovered on the fsl-mc bus. A description of the driver >>> can be found in the associated README file. >> >> Hi Greg >> >> This code has much better quality than the usual stuff in staging. I >> see no reason not to merge it. > > Yeah. It seems pretty decent. Stuart, Laurentiu, care to comment? Not sure on what you want us to comment ... > Meanwhile, netdev and DaveM aren't even on the CC list and they're the > ones to ultimately decide. I think we'll post to netdev when we'll be done with the TODOs and start moving the driver out of staging. --- Best Regards, Laurentiu
Re: [RESEND PATCH 2/6] staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet Switch driver
Hi Florian, On 09/29/2017 07:11 PM, Florian Fainelli wrote: > On September 29, 2017 6:59:18 AM PDT, Razvan Stefanescu > wrote: >> >> >>> -Original Message- >>> From: Bogdan Purcareata >>> Sent: Friday, September 29, 2017 16:36 >>> To: Razvan Stefanescu ; >>> gre...@linuxfoundation.org >>> Cc: de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org; >>> netdev@vger.kernel.org; ag...@suse.de; a...@arndb.de; Alexandru >> Marginean >>> ; Ruxandra Ioana Radulescu >>> ; Laurentiu Tudor >> ; >>> stuyo...@gmail.com >>> Subject: RE: [RESEND PATCH 2/6] staging: fsl-dpaa2/ethsw: Add >> Freescale DPAA2 >>> Ethernet Switch driver >>> >>>> Introduce the DPAA2 Ethernet Switch driver, which manages Datapath >> Switch >>>> (DPSW) objects discovered on the MC bus. >>>> >>>> Suggested-by: Alexandru Marginean >>>> Signed-off-by: Razvan Stefanescu > > This looks pretty good for a new switchdev driver, is there a reason you > can't target drivers/net/ethernet instead of staging? Is it because the MC > bus code is still in staging (AFAICT)? There's a pending patch [1] that moves the bus from staging to its place in drivers/bus. DPIO plus other bits and pieces are next on the list. Greg, Just a heads up: if this driver goes in first, then i'll need to re-spin my patch [1] to also update the #include's in this switch driver. P.S. Any news on my patch? :-) [1] https://www.spinics.net/lists/arm-kernel/msg603534.html --- Thanks, Laurentiu
