Re: [PATCH 0/6] bus: fsl-mc: Make remove function return void
On 3/11/2023 12:41 AM, Uwe Kleine-König wrote: Hello, many bus remove functions return an integer which is a historic misdesign that makes driver authors assume that there is some kind of error handling in the upper layers. This is wrong however and returning and error code only yields an error message. This series improves the fsl-mc bus by changing the remove callback to return no value instead. As a preparation all drivers are changed to return zero before so that they don't trigger the error message. Best regards Uwe Uwe Kleine-König (6): bus: fsl-mc: Only warn once about errors on device unbind bus: fsl-mc: dprc: Push down error message from fsl_mc_driver_remove() bus: fsl-mc: fsl-mc-allocator: Drop if block with always wrong condition bus: fsl-mc: fsl-mc-allocator: Improve error reporting soc: fsl: dpio: Suppress duplicated error reporting on device remove bus: fsl-mc: Make remove function return void Thanks for the series, Uwe. Did a quick boot test with ACPI, so: Reviewed-by: Laurentiu Tudor Tested-by: Laurentiu Tudor
Re: [PATCH] tty: evh_bytechan: Replace NO_IRQ by 0
On 10/6/2022 8:20 AM, Christophe Leroy wrote:
NO_IRQ is used to check the return of irq_of_parse_and_map().
On some architecture NO_IRQ is 0, on other architectures it is -1.
irq_of_parse_and_map() returns 0 on error, independent of NO_IRQ.
So use 0 instead of using NO_IRQ.
Signed-off-by: Christophe Leroy
Acked-by: Laurentiu Tudor
---
drivers/tty/ehv_bytechan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index 19d32cb6af84..8595483f4697 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -118,7 +118,7 @@ static int find_console_handle(void)
return 0;
stdout_irq = irq_of_parse_and_map(np, 0);
- if (stdout_irq == NO_IRQ) {
+ if (!stdout_irq) {
pr_err("ehv-bc: no 'interrupts' property in %pOF node\n", np);
return 0;
}
@@ -696,7 +696,7 @@ static int ehv_bc_tty_probe(struct platform_device *pdev)
bc->rx_irq = irq_of_parse_and_map(np, 0);
bc->tx_irq = irq_of_parse_and_map(np, 1);
- if ((bc->rx_irq == NO_IRQ) || (bc->tx_irq == NO_IRQ)) {
+ if (!bc->rx_irq || !bc->tx_irq) {
dev_err(&pdev->dev, "no 'interrupts' property in %pOFn node\n",
np);
ret = -ENODEV;
[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] soc: fsl: dpio: Change 'cpumask_t mask' to global variable
Hi,
Thanks for finding this. Comment inline.
On 10/14/2020 10:27 AM, Yi Wang wrote:
> From: Hao Si
>
> The local variable 'cpumask_t mask' is in the stack memory, and its address
> is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
> But the memory area where this variable is located is at risk of being
> modified.
>
> During LTP testing, the following error was generated:
>
> Unable to handle kernel paging request at virtual address 12e9b790
> Mem abort info:
> ESR = 0x9607
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x0007
> CM = 0, WnR = 0
> swapper pgtable: 4k pages, 48-bit VAs, pgdp = 75ac5e07
> [12e9b790] pgd=0027dbffe003, pud=0027dbffd003,
> pmd=0027b6d61003, pte=
> Internal error: Oops: 9607 [#1] PREEMPT SMP
> Modules linked in: xt_conntrack
> Process read_all (pid: 20171, stack limit = 0x44ea4095)
> CPU: 14 PID: 20171 Comm: read_all Tainted: GB W
> Hardware name: NXP Layerscape LX2160ARDB (DT)
> pstate: 8085 (Nzcv daIf -PAN -UAO)
> pc : irq_affinity_hint_proc_show+0x54/0xb0
> lr : irq_affinity_hint_proc_show+0x4c/0xb0
> sp : 1138bc10
> x29: 1138bc10 x28: d131d1e0
> x27: 007000c0 x26: 8025b9480dc0
> x25: 8025b9480da8 x24: 03ff
> x23: 8027334f8300 x22: 80272e97d000
> x21: 80272e97d0b0 x20: 8025b9480d80
> x19: 09a49000 x18:
> x17: x16:
> x15: x14:
> x13: x12: 0040
> x11: x10: 802735b79b88
> x9 : x8 :
> x7 : 09a49848 x6 : 0003
> x5 : x4 : 08157d6c
> x3 : 1138bc10 x2 : 12e9b790
> x1 : x0 :
> Call trace:
> irq_affinity_hint_proc_show+0x54/0xb0
> seq_read+0x1b0/0x440
> proc_reg_read+0x80/0xd8
> __vfs_read+0x60/0x178
> vfs_read+0x94/0x150
> ksys_read+0x74/0xf0
> __arm64_sys_read+0x24/0x30
> el0_svc_common.constprop.0+0xd8/0x1a0
> el0_svc_handler+0x34/0x88
> el0_svc+0x10/0x14
> Code: f9001bbf 943e0732 f94066c2 b462 (f9400041)
> ---[ end trace b495bdcb0b3b732b ]---
> Kernel panic - not syncing: Fatal exception
> SMP: stopping secondary CPUs
> SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15
> Kernel Offset: disabled
> CPU features: 0x0,21006008
> Memory Limit: none
> ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Fix it by changing 'cpumask_t mask' to global variable.
>
> Signed-off-by: Hao Si
> Signed-off-by: Lin Chen
> Signed-off-by: Yi Wang
> ---
> drivers/soc/fsl/dpio/dpio-driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/dpio/dpio-driver.c
> b/drivers/soc/fsl/dpio/dpio-driver.c
> index 7b642c3..b31ec53 100644
> --- a/drivers/soc/fsl/dpio/dpio-driver.c
> +++ b/drivers/soc/fsl/dpio/dpio-driver.c
> @@ -31,6 +31,7 @@ struct dpio_priv {
> struct dpaa2_io *io;
> };
>
> +static cpumask_t mask;
There can be multiple dpio devices with their associated driver
instances so it's not ok to make the variable global. Please place it in
the driver's private data and while at it, please rename it to cpu_mask.
---
Thanks & Best Regards, Laurentiu
Re: ppc32 panic on boot on linux-next
Hello, On 10.03.2020 06:44, Michael Ellerman wrote: Christophe Leroy writes: Le 07/03/2020 à 09:42, Christophe Leroy a écrit : Le 06/03/2020 à 20:05, Nick Desaulniers a écrit : As a heads up, our CI went red last night, seems like a panic from free_initmem? Is this a known issue? Thanks for the heads up. No such issue with either 8xx or book3s/32. I've now been able to reproduce it with bamboo QEMU. Reverting 2efc7c085f05 makes it disappear. I'll investigate. Ok, I found the problem. virt_to_kpte() lacks a NULL pmd check. I'll send a patch for that. However, if there is no PMD I guess this area is mapped through some kind of block mapping. Therefore it should bail out of the function through: if (v_block_mapped(address)) return 0; Can someone who knows BOOKE investigate that ? Not sure we have anyone left? cheers With latest linux-next, PPC32 Book-E boots to prompt: https://paste.debian.net/1134272/ --- Best Regards, Laurentiu
Re: [PATCH] evh_bytechan: fix out of bounds accesses
On 25.02.2020 22:56, Stephen Rothwell wrote: Hi Laurentiu, On Tue, 25 Feb 2020 11:54:17 +0200 Laurentiu Tudor wrote: On 21.02.2020 01:57, Stephen Rothwell wrote: On Thu, 16 Jan 2020 11:37:14 +1100 Stephen Rothwell wrote: On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood wrote: On Thu, 2020-01-16 at 06:42 +1100, Stephen Rothwell wrote: On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi wrote: On 1/14/20 12:31 AM, Stephen Rothwell wrote: +/** + * ev_byte_channel_send - send characters to a byte stream + * @handle: byte stream handle + * @count: (input) num of chars to send, (output) num chars sent + * @bp: pointer to chars to send + * + * Returns 0 for success, or an error code. + */ +static unsigned int ev_byte_channel_send(unsigned int handle, + unsigned int *count, const char *bp) Well, now you've moved this into the .c file and it is no longer available to other callers. Anything wrong with keeping it in the .h file? There are currently no other callers - are there likely to be in the future? Even if there are, is it time critical enough that it needs to be inlined everywhere? It's not performance critical and there aren't likely to be other users -- just a matter of what's cleaner. FWIW I'd rather see the original patch, that keeps the raw asm hcall stuff as simple wrappers in one place. And I don't mind either way :-) I just want to get rid of the warnings. Any progress with this? I think that the consensus was to pick up the original patch that is, this one: https://patchwork.ozlabs.org/patch/1220186/ I've tested it too, so please feel free to add a: Tested-by: Laurentiu Tudor So, whose tree should his go via? Maybe Scott or Michael can help us here. And while at it maybe, take a look at this patch [1] too. [1] https://patchwork.ozlabs.org/patch/1227780/ --- Best Regards, Laurentiu
Re: [PATCH] evh_bytechan: fix out of bounds accesses
On 21.02.2020 01:57, Stephen Rothwell wrote: Hi all, On Thu, 16 Jan 2020 11:37:14 +1100 Stephen Rothwell wrote: On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood wrote: On Thu, 2020-01-16 at 06:42 +1100, Stephen Rothwell wrote: Hi Timur, On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi wrote: On 1/14/20 12:31 AM, Stephen Rothwell wrote: +/** + * ev_byte_channel_send - send characters to a byte stream + * @handle: byte stream handle + * @count: (input) num of chars to send, (output) num chars sent + * @bp: pointer to chars to send + * + * Returns 0 for success, or an error code. + */ +static unsigned int ev_byte_channel_send(unsigned int handle, + unsigned int *count, const char *bp) Well, now you've moved this into the .c file and it is no longer available to other callers. Anything wrong with keeping it in the .h file? There are currently no other callers - are there likely to be in the future? Even if there are, is it time critical enough that it needs to be inlined everywhere? It's not performance critical and there aren't likely to be other users -- just a matter of what's cleaner. FWIW I'd rather see the original patch, that keeps the raw asm hcall stuff as simple wrappers in one place. And I don't mind either way :-) I just want to get rid of the warnings. Any progress with this? I think that the consensus was to pick up the original patch that is, this one: https://patchwork.ozlabs.org/patch/1220186/ I've tested it too, so please feel free to add a: Tested-by: Laurentiu Tudor --- Best Regards, Laurentiu
RE: [PATCH] bus: fsl-mc: add api to retrieve mc version
> -Original Message-
> From: Andrei Botila
> Sent: Monday, January 27, 2020 1:16 PM
>
> Add a new api that returns Management Complex firmware version
> and make the required structure public. The api's first user will be
> the caam driver for setting prediction resistance bits.
>
> Signed-off-by: Andrei Botila
Acked-by: Laurentiu Tudor
> ---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 33 +
> include/linux/fsl/mc.h | 16
> 2 files changed, 33 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-
> bus.c
> index a07cc19becdb..330c76181604 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -26,6 +26,8 @@
> */
> #define FSL_MC_DEFAULT_DMA_MASK (~0ULL)
>
> +static struct fsl_mc_version mc_version;
> +
> /**
> * struct fsl_mc - Private data of a "fsl,qoriq-mc" platform device
> * @root_mc_bus_dev: fsl-mc device representing the root DPRC
> @@ -54,20 +56,6 @@ struct fsl_mc_addr_translation_range {
> phys_addr_t start_phys_addr;
> };
>
> -/**
> - * struct mc_version
> - * @major: Major version number: incremented on API compatibility changes
> - * @minor: Minor version number: incremented on API additions (that are
> - * backward compatible); reset when major version is incremented
> - * @revision: Internal revision number: incremented on implementation
> changes
> - * and/or bug fixes that have no impact on API
> - */
> -struct mc_version {
> - u32 major;
> - u32 minor;
> - u32 revision;
> -};
> -
> /**
> * fsl_mc_bus_match - device to driver matching callback
> * @dev: the fsl-mc device to match against
> @@ -338,7 +326,7 @@ EXPORT_SYMBOL_GPL(fsl_mc_driver_unregister);
> */
> static int mc_get_version(struct fsl_mc_io *mc_io,
> u32 cmd_flags,
> - struct mc_version *mc_ver_info)
> + struct fsl_mc_version *mc_ver_info)
> {
> struct fsl_mc_command cmd = { 0 };
> struct dpmng_rsp_get_version *rsp_params;
> @@ -363,6 +351,20 @@ static int mc_get_version(struct fsl_mc_io *mc_io,
> return 0;
> }
>
> +/**
> + * fsl_mc_get_version - function to retrieve the MC f/w version
> information
> + *
> + * Return: mc version when called after fsl-mc-bus probe; NULL otherwise.
> + */
> +struct fsl_mc_version *fsl_mc_get_version(void)
> +{
> + if (mc_version.major)
> + return &mc_version;
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(fsl_mc_get_version);
> +
> /**
> * fsl_mc_get_root_dprc - function to traverse to the root dprc
> */
> @@ -862,7 +864,6 @@ static int fsl_mc_bus_probe(struct platform_device
> *pdev)
> int container_id;
> phys_addr_t mc_portal_phys_addr;
> u32 mc_portal_size;
> - struct mc_version mc_version;
> struct resource res;
>
> mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
> diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
> index 54d9436600c7..2b5f8366dbe1 100644
> --- a/include/linux/fsl/mc.h
> +++ b/include/linux/fsl/mc.h
> @@ -381,6 +381,22 @@ int __must_check __fsl_mc_driver_register(struct
> fsl_mc_driver *fsl_mc_driver,
>
> void fsl_mc_driver_unregister(struct fsl_mc_driver *driver);
>
> +/**
> + * struct fsl_mc_version
> + * @major: Major version number: incremented on API compatibility changes
> + * @minor: Minor version number: incremented on API additions (that are
> + * backward compatible); reset when major version is incremented
> + * @revision: Internal revision number: incremented on implementation
> changes
> + * and/or bug fixes that have no impact on API
> + */
> +struct fsl_mc_version {
> + u32 major;
> + u32 minor;
> + u32 revision;
> +};
> +
> +struct fsl_mc_version *fsl_mc_get_version(void);
> +
> int __must_check fsl_mc_portal_allocate(struct fsl_mc_device *mc_dev,
> u16 mc_io_flags,
> struct fsl_mc_io **new_mc_io);
> --
> 2.17.1
[PATCH] powerpc/fsl_booke: avoid creating duplicate tlb1 entry
In the current implementation, the call to loadcam_multi() is wrapped
between switch_to_as1() and restore_to_as0() calls so, when it tries
to create its own temporary AS=1 TLB1 entry, it ends up duplicating the
existing one created by switch_to_as1(). Add a check to skip creating
the temporary entry if already running in AS=1.
Fixes: d9e1831a4202 ("powerpc/85xx: Load all early TLB entries at once")
Signed-off-by: Laurentiu Tudor
Cc: sta...@vger.kernel.org
---
arch/powerpc/mm/nohash/tlb_low.S | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/nohash/tlb_low.S b/arch/powerpc/mm/nohash/tlb_low.S
index 2ca407cedbe7..eaeee402f96e 100644
--- a/arch/powerpc/mm/nohash/tlb_low.S
+++ b/arch/powerpc/mm/nohash/tlb_low.S
@@ -397,7 +397,7 @@ _GLOBAL(set_context)
* extern void loadcam_entry(unsigned int index)
*
* Load TLBCAM[index] entry in to the L2 CAM MMU
- * Must preserve r7, r8, r9, and r10
+ * Must preserve r7, r8, r9, r10 and r11
*/
_GLOBAL(loadcam_entry)
mflrr5
@@ -433,6 +433,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
*/
_GLOBAL(loadcam_multi)
mflrr8
+ /* Don't switch to AS=1 if already there */
+ mfmsr r11
+ andi. r11,r11,MSR_IS
+ bne 10f
/*
* Set up temporary TLB entry that is the same as what we're
@@ -458,6 +462,7 @@ _GLOBAL(loadcam_multi)
mtmsr r6
isync
+10:
mr r9,r3
add r10,r3,r4
2: bl loadcam_entry
@@ -466,6 +471,10 @@ _GLOBAL(loadcam_multi)
mr r3,r9
blt 2b
+ /* Don't return to AS=0 if we were in AS=1 at function start */
+ andi. r11,r11,MSR_IS
+ bne 3f
+
/* Return to AS=0 and clear the temporary entry */
mfmsr r6
rlwinm. r6,r6,0,~(MSR_IS|MSR_DS)
@@ -481,6 +490,7 @@ _GLOBAL(loadcam_multi)
tlbwe
isync
+3:
mtlrr8
blr
#endif
--
2.17.1
RE: [PATCH] evh_bytechan: fix out of bounds accesses
from arch/powerpc/include/asm/bitops.h:250, > from include/linux/bitops.h:29, > from include/linux/kernel.h:12, > from include/asm-generic/bug.h:19, > from arch/powerpc/include/asm/bug.h:109, > from include/linux/bug.h:5, > from include/linux/mmdebug.h:5, > from include/linux/gfp.h:5, > from include/linux/slab.h:15, > from drivers/tty/ehv_bytechan.c:24: > arch/powerpc/include/asm/epapr_hcalls.h:300:20: warning: array subscript 3 > is outside array bounds of ‘const char[1]’ [-Warray-bounds] > 300 | r8 = be32_to_cpu(p[3]); > include/uapi/linux/byteorder/big_endian.h:40:51: note: in definition of > macro ‘__be32_to_cpu’ >40 | #define __be32_to_cpu(x) ((__force __u32)(__be32)(x)) > | ^ > arch/powerpc/include/asm/epapr_hcalls.h:300:7: note: in expansion of macro > ‘be32_to_cpu’ > 300 | r8 = be32_to_cpu(p[3]); > | ^~~ > drivers/tty/ehv_bytechan.c:166:13: note: while referencing ‘data’ > 166 | static void ehv_bc_udbg_putc(char c) > | ^~~~ > > Signed-off-by: Stephen Rothwell > --- Tested-by: Laurentiu Tudor --- Best Regards, Laurentiu
[PATCH] MAINTAINERS: Add myself as maintainer of ehv_bytechan tty driver
Michael Ellerman made a call for volunteers from NXP to maintain this driver and I offered myself. Signed-off-by: Laurentiu Tudor --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4017e6b760be..62082e5f7101 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6155,6 +6155,12 @@ M: Maxim Levitsky S: Maintained F: drivers/media/rc/ene_ir.* +EPAPR HYPERVISOR BYTE CHANNEL DEVICE DRIVER +M: Laurentiu Tudor +L: linuxppc-dev@lists.ozlabs.org +S: Maintained +F: drivers/tty/ehv_bytechan.c + EPSON S1D13XXX FRAMEBUFFER DRIVER M: Kristoffer Ericson S: Maintained -- 2.17.1
Re: [PATCH] evh_bytechan: fix out of bounds accesses
On 14.01.2020 03:10, Michael Ellerman wrote: > Laurentiu Tudor writes: >> Hello, >> >> On 13.01.2020 15:48, Timur Tabi wrote: >>> On 1/13/20 6:26 AM, Michael Ellerman wrote: >>>> I've never heard of it, and I have no idea how to test it. >>>> >>>> It's not used by qemu, I guess there is/was a Freescale hypervisor that >>>> used it. >>> >>> Yes, there is/was a Freescale hypervisor that I and a few others worked >>> on. I've added a couple people on CC that might be able to tell the >>> current disposition of it. >> >> More info on this: it's opensource and it's published here [1]. We still >> claim to maintain it but there wasn't much activity past years, as one >> might notice. >> >>>> But maybe it's time to remove it if it's not being maintained/used by >>>> anyone? >>> >>> I wouldn't be completely opposed to that if there really are no more >>> users. There really weren't any users even when I wrote the driver. >> >> There are a few users that I know of, but I can't tell if that's enough >> to justify keeping the driver. > > It is, I don't want to remove code that people are actually using, > unless it's causing unsustainable maintenance burden. > > But this should be easy enough to get fixed. Right. I see that Stephen already came up with a proposal for a fix. > Could you or someone else at NXP volunteer to maintain this driver? That > shouldn't involve much work, other than fixing small things like this > warning. I can offer myself. I'll send a MAINTAINERS patch if nobody is against it. --- Best Regards, Laurentiu
Re: [PATCH] evh_bytechan: fix out of bounds accesses
Hello, On 13.01.2020 15:48, Timur Tabi wrote: > On 1/13/20 6:26 AM, Michael Ellerman wrote: >> I've never heard of it, and I have no idea how to test it. >> >> It's not used by qemu, I guess there is/was a Freescale hypervisor that >> used it. > > Yes, there is/was a Freescale hypervisor that I and a few others worked > on. I've added a couple people on CC that might be able to tell the > current disposition of it. More info on this: it's opensource and it's published here [1]. We still claim to maintain it but there wasn't much activity past years, as one might notice. >> But maybe it's time to remove it if it's not being maintained/used by >> anyone? > > I wouldn't be completely opposed to that if there really are no more > users. There really weren't any users even when I wrote the driver. There are a few users that I know of, but I can't tell if that's enough to justify keeping the driver. [1] https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/hypervisor/ --- Best Regards, Laurentiu
RE: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
> -Original Message- > From: Andreas Färber > Sent: Friday, May 31, 2019 8:04 PM > > Hello Laurentiu, > > Am 31.05.19 um 18:46 schrieb Laurentiu Tudor: > >> -Original Message- > >> From: Andreas Färber > >> Sent: Friday, May 31, 2019 7:15 PM > >> > >> Hi Laurentiu, > >> > >> Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com: > >>> This patch series contains several fixes in preparation for SMMU > >>> support on NXP LS1043A and LS1046A chips. Once these get picked up, > >>> I'll submit the actual SMMU enablement patches consisting in the > >>> required device tree changes. > >> > >> Have you thought through what will happen if this patch ordering is not > >> preserved? In particular, a user installing a future U-Boot update with > >> the DTB bits but booting a stable kernel without this patch series - > >> wouldn't that regress dpaa then for our customers? > >> > > > > These are fixes for issues that popped out after enabling SMMU. > > I do not expect them to break anything. > > That was not my question! You're missing my point: All your patches are > lacking a Fixes header in their commit message, for backporting them, to > avoid _your DT patches_ breaking the driver on stable branches! It does appear that I'm missing your point. For sure, the DT updates solely will break the kernel without these fixes but I'm not sure I understand how this could happen. My plan was to share the kernel dts patches sometime after this series makes it through. --- Best Regards, Laurentiu
RE: [PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames
> -Original Message- > From: Christoph Hellwig > Sent: Friday, May 31, 2019 7:56 PM > > On Fri, May 31, 2019 at 04:53:16PM +0000, Laurentiu Tudor wrote: > > Unfortunately due to our hardware particularities we do not have > alternatives. This is also the case for our next generation of ethernet > drivers [1]. I'll let my colleagues that work on the ethernet drivers to > comment more on this. > > Then you need to enhance the DMA API to support your use case instead > of using an API only supported for two specific IOMMU implementations. > > Remember in Linux you can should improve core code and not hack around > it in crappy ways making lots of assumptions in your drivers. Alright, I'm ok with that. I'll try to come up with something, will keep you in the loop. --- Best Regards, Laurentiu
RE: [PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames
Hi Christoph,
> -Original Message-
> From: Christoph Hellwig
> Sent: Friday, May 31, 2019 7:32 PM
>
> On Thu, May 30, 2019 at 05:19:50PM +0300, laurentiu.tu...@nxp.com wrote:
> > +static phys_addr_t dpaa_iova_to_phys(const struct dpaa_priv *priv,
> > +dma_addr_t addr)
> > +{
> > + return priv->domain ? iommu_iova_to_phys(priv->domain, addr) : addr;
> > +}
>
> Again, a driver using the iommu API must not call iommu_* APIs.
>
> This chane is not acceptable.
Unfortunately due to our hardware particularities we do not have alternatives.
This is also the case for our next generation of ethernet drivers [1]. I'll let
my colleagues that work on the ethernet drivers to comment more on this.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c#n37
---
Best Regards, Laurentiu
RE: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
Hello Andreas, > -Original Message- > From: Andreas Färber > Sent: Friday, May 31, 2019 7:15 PM > > Hi Laurentiu, > > Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com: > > This patch series contains several fixes in preparation for SMMU > > support on NXP LS1043A and LS1046A chips. Once these get picked up, > > I'll submit the actual SMMU enablement patches consisting in the > > required device tree changes. > > Have you thought through what will happen if this patch ordering is not > preserved? In particular, a user installing a future U-Boot update with > the DTB bits but booting a stable kernel without this patch series - > wouldn't that regress dpaa then for our customers? > These are fixes for issues that popped out after enabling SMMU. I do not expect them to break anything. --- Best Regards, Laurentiu
RE: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
Hello, > -Original Message- > From: David Miller > Sent: Friday, May 31, 2019 1:09 AM > > From: laurentiu.tu...@nxp.com > Date: Thu, 30 May 2019 17:19:45 +0300 > > > Depends on this pull request: > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html > > I'm not sure how you want me to handle this. Dave, would it make sense / be possible to also pick Leo's PR through your tree? --- Thanks & Best Regards, Laurentiu
[PATCH v3 2/6] fsl/fman: add API to get the device behind a fman port
From: Laurentiu Tudor
Add an API that retrieves the 'struct device' that the specified fman
port probed against. The new API will be used in a subsequent iommu
enablement related patch.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/fman/fman_port.c | 14 ++
drivers/net/ethernet/freescale/fman/fman_port.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c
b/drivers/net/ethernet/freescale/fman/fman_port.c
index ee82ee1384eb..bd76c9730692 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.c
+++ b/drivers/net/ethernet/freescale/fman/fman_port.c
@@ -1728,6 +1728,20 @@ u32 fman_port_get_qman_channel_id(struct fman_port *port)
}
EXPORT_SYMBOL(fman_port_get_qman_channel_id);
+/**
+ * fman_port_get_device
+ * port: Pointer to the FMan port device
+ *
+ * Get the 'struct device' associated to the specified FMan port device
+ *
+ * Return: pointer to associated 'struct device'
+ */
+struct device *fman_port_get_device(struct fman_port *port)
+{
+ return port->dev;
+}
+EXPORT_SYMBOL(fman_port_get_device);
+
int fman_port_get_hash_result_offset(struct fman_port *port, u32 *offset)
{
if (port->buffer_offsets.hash_result_offset == ILLEGAL_BASE)
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.h
b/drivers/net/ethernet/freescale/fman/fman_port.h
index 9dbb69f40121..82f12661a46d 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.h
+++ b/drivers/net/ethernet/freescale/fman/fman_port.h
@@ -157,4 +157,6 @@ int fman_port_get_tstamp(struct fman_port *port, const void
*data, u64 *tstamp);
struct fman_port *fman_port_bind(struct device *dev);
+struct device *fman_port_get_device(struct fman_port *port);
+
#endif /* __FMAN_PORT_H */
--
2.17.1
[PATCH v3 1/6] fsl/fman: don't touch liodn base regs reserved on non-PAMU SoCs
From: Laurentiu Tudor
liodn base registers are specific to PAMU based NXP systems and on SMMU
based ones are reserved. Don't access them if PAMU is compiled in.
Signed-off-by: Laurentiu Tudor
---
drivers/net/ethernet/freescale/fman/fman.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c
b/drivers/net/ethernet/freescale/fman/fman.c
index e80fedb27cee..cce6636b1763 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -634,6 +634,9 @@ static void set_port_liodn(struct fman *fman, u8 port_id,
{
u32 tmp;
+ iowrite32be(liodn_ofst, &fman->bmi_regs->fmbm_spliodn[port_id - 1]);
+ if (!IS_ENABLED(CONFIG_FSL_PAMU))
+ return;
/* set LIODN base for this port */
tmp = ioread32be(&fman->dma_regs->fmdmplr[port_id / 2]);
if (port_id % 2) {
@@ -644,7 +647,6 @@ static void set_port_liodn(struct fman *fman, u8 port_id,
tmp |= liodn_base << DMA_LIODN_SHIFT;
}
iowrite32be(tmp, &fman->dma_regs->fmdmplr[port_id / 2]);
- iowrite32be(liodn_ofst, &fman->bmi_regs->fmbm_spliodn[port_id - 1]);
}
static void enable_rams_ecc(struct fman_fpm_regs __iomem *fpm_rg)
@@ -1942,6 +1944,8 @@ static int fman_init(struct fman *fman)
fman->liodn_offset[i] =
ioread32be(&fman->bmi_regs->fmbm_spliodn[i - 1]);
+ if (!IS_ENABLED(CONFIG_FSL_PAMU))
+ continue;
liodn_base = ioread32be(&fman->dma_regs->fmdmplr[i / 2]);
if (i % 2) {
/* FMDM_PLR LSB holds LIODN base for odd ports */
--
2.17.1
[PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
From: Laurentiu Tudor This patch series contains several fixes in preparation for SMMU support on NXP LS1043A and LS1046A chips. Once these get picked up, I'll submit the actual SMMU enablement patches consisting in the required device tree changes. This patch series contains only part of the previously submitted one, (including also the device tree changes) available here: https://patchwork.kernel.org/cover/10634443/ There are a couple of changes/fixes since then: - for consistency, renamed mmu node to smmu - new patch page aligning the sizes of the qbman reserved memory - rebased on 5.1.0-rc2 Depends on this pull request: http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html Changes in v3: - cache iommu domain in driver's private data - rebased on v5.2.0-rc2 - rework to get rid of #ifdef spaghetti (David) Changes in v2: - dropped patches dealing with mapping reserved memory in iommu - changed logic for qman portal probe status (Leo) - moved "#ifdef CONFIG_PAMU" in header file (Leo) - rebased on v5.1.0-rc5 Laurentiu Tudor (6): fsl/fman: don't touch liodn base regs reserved on non-PAMU SoCs fsl/fman: add API to get the device behind a fman port dpaa_eth: defer probing after qbman dpaa_eth: base dma mappings on the fman rx port dpaa_eth: fix iova handling for contiguous frames dpaa_eth: fix iova handling for sg frames .../net/ethernet/freescale/dpaa/dpaa_eth.c| 131 -- .../net/ethernet/freescale/dpaa/dpaa_eth.h| 2 + drivers/net/ethernet/freescale/fman/fman.c| 6 +- .../net/ethernet/freescale/fman/fman_port.c | 14 ++ .../net/ethernet/freescale/fman/fman_port.h | 2 + 5 files changed, 108 insertions(+), 47 deletions(-) -- 2.17.1
[PATCH v3 4/6] dpaa_eth: base dma mappings on the fman rx port
From: Laurentiu Tudor
The dma transactions initiator is the rx fman port so that's the device
that the dma mappings should be done. Previously the mappings were done
through the MAC device which makes no sense because it's neither dma-able
nor connected in any way to smmu.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 975f307f0caa..f54b0cd0d175 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2805,8 +2805,15 @@ static int dpaa_eth_probe(struct platform_device *pdev)
return -ENODEV;
}
+ mac_dev = dpaa_mac_dev_get(pdev);
+ if (IS_ERR(mac_dev)) {
+ dev_err(&pdev->dev, "dpaa_mac_dev_get() failed\n");
+ err = PTR_ERR(mac_dev);
+ goto probe_err;
+ }
+
/* device used for DMA mapping */
- dev = pdev->dev.parent;
+ dev = fman_port_get_device(mac_dev->port[RX]);
err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
if (err) {
dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
@@ -2831,13 +2838,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
priv->msg_enable = netif_msg_init(debug, DPAA_MSG_DEFAULT);
- mac_dev = dpaa_mac_dev_get(pdev);
- if (IS_ERR(mac_dev)) {
- dev_err(dev, "dpaa_mac_dev_get() failed\n");
- err = PTR_ERR(mac_dev);
- goto free_netdev;
- }
-
/* If fsl_fm_max_frm is set to a higher value than the all-common 1500,
* we choose conservatively and let the user explicitly set a higher
* MTU via ifconfig. Otherwise, the user may end up with different MTUs
@@ -2973,9 +2973,9 @@ static int dpaa_eth_probe(struct platform_device *pdev)
qman_release_cgrid(priv->cgr_data.cgr.cgrid);
free_dpaa_bps:
dpaa_bps_free(priv);
-free_netdev:
dev_set_drvdata(dev, NULL);
free_netdev(net_dev);
+probe_err:
return err;
}
--
2.17.1
[PATCH v3 3/6] dpaa_eth: defer probing after qbman
From: Laurentiu Tudor
Enabling SMMU altered the order of device probing causing the dpaa1
ethernet driver to get probed before qbman and causing a boot crash.
Add predictability in the probing order by deferring the ethernet
driver probe after qbman and portals by using the recently introduced
qbman APIs.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index d3f2408dc9e8..975f307f0caa 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2774,6 +2774,37 @@ static int dpaa_eth_probe(struct platform_device *pdev)
int err = 0, i, channel;
struct device *dev;
+ err = bman_is_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev, "failing probe due to bman probe error\n");
+ return -ENODEV;
+ }
+ err = qman_is_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev, "failing probe due to qman probe error\n");
+ return -ENODEV;
+ }
+ err = bman_portals_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev,
+ "failing probe due to bman portals probe error\n");
+ return -ENODEV;
+ }
+ err = qman_portals_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev,
+ "failing probe due to qman portals probe error\n");
+ return -ENODEV;
+ }
+
/* device used for DMA mapping */
dev = pdev->dev.parent;
err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
--
2.17.1
[PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this by adding a function that does
proper iova -> phys conversions using the iommu api and update the code
to use it.
Also, a dma_unmap_single() call had to be moved further down the code
because iova -> vaddr conversions were required before the unmap.
For now only the contiguous frame case is handled and the SG case is
split in a following patch.
While at it, clean-up a redundant dpaa_bpid2pool() and pass the bp
as parameter.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 42 ++-
.../net/ethernet/freescale/dpaa/dpaa_eth.h| 2 +
2 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index f54b0cd0d175..46194a04617a 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1595,6 +1596,12 @@ static int dpaa_eth_refill_bpools(struct dpaa_priv *priv)
return 0;
}
+static phys_addr_t dpaa_iova_to_phys(const struct dpaa_priv *priv,
+dma_addr_t addr)
+{
+ return priv->domain ? iommu_iova_to_phys(priv->domain, addr) : addr;
+}
+
/* Cleanup function for outgoing frame descriptors that were built on Tx path,
* either contiguous frames or scatter/gather ones.
* Skb freeing is not handled here.
@@ -1617,7 +1624,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
int nr_frags, i;
u64 ns;
- skbh = (struct sk_buff **)phys_to_virt(addr);
+ skbh = (struct sk_buff **)phys_to_virt(dpaa_iova_to_phys(priv, addr));
skb = *skbh;
if (priv->tx_tstamp && skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
@@ -1687,25 +1694,21 @@ static u8 rx_csum_offload(const struct dpaa_priv *priv,
const struct qm_fd *fd)
* accommodate the shared info area of the skb.
*/
static struct sk_buff *contig_fd_to_skb(const struct dpaa_priv *priv,
- const struct qm_fd *fd)
+ const struct qm_fd *fd,
+ struct dpaa_bp *dpaa_bp,
+ void *vaddr)
{
ssize_t fd_off = qm_fd_get_offset(fd);
- dma_addr_t addr = qm_fd_addr(fd);
- struct dpaa_bp *dpaa_bp;
struct sk_buff *skb;
- void *vaddr;
- vaddr = phys_to_virt(addr);
WARN_ON(!IS_ALIGNED((unsigned long)vaddr, SMP_CACHE_BYTES));
- dpaa_bp = dpaa_bpid2pool(fd->bpid);
- if (!dpaa_bp)
- goto free_buffer;
-
skb = build_skb(vaddr, dpaa_bp->size +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
- if (WARN_ONCE(!skb, "Build skb failure on Rx\n"))
- goto free_buffer;
+ if (WARN_ONCE(!skb, "Build skb failure on Rx\n")) {
+ skb_free_frag(vaddr);
+ return NULL;
+ }
WARN_ON(fd_off != priv->rx_headroom);
skb_reserve(skb, fd_off);
skb_put(skb, qm_fd_get_length(fd));
@@ -1713,10 +1716,6 @@ static struct sk_buff *contig_fd_to_skb(const struct
dpaa_priv *priv,
skb->ip_summed = rx_csum_offload(priv, fd);
return skb;
-
-free_buffer:
- skb_free_frag(vaddr);
- return NULL;
}
/* Build an skb with the data of the first S/G entry in the linear portion and
@@ -2309,12 +2308,12 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct
qman_portal *portal,
if (!dpaa_bp)
return qman_cb_dqrr_consume;
- dma_unmap_single(dpaa_bp->dev, addr, dpaa_bp->size, DMA_FROM_DEVICE);
-
/* prefetch the first 64 bytes of the frame or the SGT start */
- vaddr = phys_to_virt(addr);
+ vaddr = phys_to_virt(dpaa_iova_to_phys(priv, addr));
prefetch(vaddr + qm_fd_get_offset(fd));
+ dma_unmap_single(dpaa_bp->dev, addr, dpaa_bp->size, DMA_FROM_DEVICE);
+
/* The only FD types that we may receive are contig and S/G */
WARN_ON((fd_format != qm_fd_contig) && (fd_format != qm_fd_sg));
@@ -2325,7 +2324,7 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct
qman_portal *portal,
(*count_ptr)--;
if (likely(fd_format == qm_fd_contig))
- skb = contig_fd_to_skb(priv, fd);
+ skb = contig_fd_to_skb(priv, fd, dpaa_bp, vaddr);
else
skb = sg_fd_to_skb(priv, fd);
if (!skb)
@@ -2836,6 +2835,9 @@ static int dpaa_eth_probe(struct platform_device *pdev)
priv = netdev_priv(net_d
[PATCH v3 6/6] dpaa_eth: fix iova handling for sg frames
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this also for scatter-gather frames
using the iova -> phys conversion function added in the previous patch.
While at it, clean-up a redundant dpaa_bpid2pool() and pass the bp
as parameter.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 40 +++
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 46194a04617a..7d978a93dffd 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1641,14 +1641,17 @@ 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,
-qm_fd_get_offset(fd) + DPAA_SGT_SIZE,
-dma_dir);
/* The sgt buffer has been allocated with netdev_alloc_frag(),
* it's from lowmem.
*/
- sgt = phys_to_virt(addr + qm_fd_get_offset(fd));
+ sgt = phys_to_virt(dpaa_iova_to_phys(priv,
+addr +
+qm_fd_get_offset(fd)));
+
+ dma_unmap_single(dev, addr,
+qm_fd_get_offset(fd) + DPAA_SGT_SIZE,
+dma_dir);
/* sgt[0] is from lowmem, was dma_map_single()-ed */
dma_unmap_single(dev, qm_sg_addr(&sgt[0]),
@@ -1663,7 +1666,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
}
/* Free the page frag that we allocated on Tx */
- skb_free_frag(phys_to_virt(addr));
+ skb_free_frag(skbh);
} else {
dma_unmap_single(dev, addr,
skb_tail_pointer(skb) - (u8 *)skbh, dma_dir);
@@ -1724,14 +1727,14 @@ static struct sk_buff *contig_fd_to_skb(const struct
dpaa_priv *priv,
* The page fragment holding the S/G Table is recycled here.
*/
static struct sk_buff *sg_fd_to_skb(const struct dpaa_priv *priv,
- const struct qm_fd *fd)
+ const struct qm_fd *fd,
+ struct dpaa_bp *dpaa_bp,
+ void *vaddr)
{
ssize_t fd_off = qm_fd_get_offset(fd);
- dma_addr_t addr = qm_fd_addr(fd);
const struct qm_sg_entry *sgt;
struct page *page, *head_page;
- struct dpaa_bp *dpaa_bp;
- void *vaddr, *sg_vaddr;
+ void *sg_vaddr;
int frag_off, frag_len;
struct sk_buff *skb;
dma_addr_t sg_addr;
@@ -1740,7 +1743,6 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
int *count_ptr;
int i;
- vaddr = phys_to_virt(addr);
WARN_ON(!IS_ALIGNED((unsigned long)vaddr, SMP_CACHE_BYTES));
/* Iterate through the SGT entries and add data buffers to the skb */
@@ -1751,14 +1753,17 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
sg_addr = qm_sg_addr(&sgt[i]);
- sg_vaddr = phys_to_virt(sg_addr);
- WARN_ON(!IS_ALIGNED((unsigned long)sg_vaddr,
- SMP_CACHE_BYTES));
/* We may use multiple Rx pools */
dpaa_bp = dpaa_bpid2pool(sgt[i].bpid);
- if (!dpaa_bp)
+ if (!dpaa_bp) {
+ pr_info("%s: fail to get dpaa_bp for sg bpid %d\n",
+ __func__, sgt[i].bpid);
goto free_buffers;
+ }
+ sg_vaddr = phys_to_virt(dpaa_iova_to_phys(priv, sg_addr));
+ WARN_ON(!IS_ALIGNED((unsigned long)sg_vaddr,
+ SMP_CACHE_BYTES));
count_ptr = this_cpu_ptr(dpaa_bp->percpu_count);
dma_unmap_single(dpaa_bp->dev, sg_addr, dpaa_bp->size,
@@ -1830,10 +1835,11 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
/* free all the SG entries */
for (i = 0; i < DPAA_SGT_MAX_ENTRIES ; i++) {
sg_addr = qm_sg_addr(&sgt[i]);
- sg_vaddr = phys_to_virt(sg_addr);
- skb_free_frag(sg_vaddr);
dpaa_bp = dpaa_bpid2pool(sgt[i].bpid);
if (dpaa_bp) {
+ sg_addr = dpaa_iova_to_phys(priv, sg_ad
[PATCH v3] dpaa_eth: fix SG frame cleanup
From: Laurentiu Tudor
Fix issue with the entry indexing in the sg frame cleanup code being
off-by-1. This problem showed up when doing some basic iperf tests and
manifested in traffic coming to a halt.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
Cc:
---
v3:
- added cc:stable tag (Joakim)
- pulled from the original patch series and send individually
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index daede7272768..40420edc9ce6 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1663,7 +1663,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
qm_sg_entry_get_len(&sgt[0]), dma_dir);
/* remaining pages were mapped with skb_frag_dma_map() */
- for (i = 1; i < nr_frags; i++) {
+ for (i = 1; i <= nr_frags; i++) {
WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
dma_unmap_page(dev, qm_sg_addr(&sgt[i]),
--
2.17.1
RE: [PATCH v2 9/9] dpaa_eth: fix SG frame cleanup
> -Original Message-
> From: Joakim Tjernlund
> Sent: Thursday, May 2, 2019 1:37 PM
>
> On Thu, 2019-05-02 at 09:05 +0000, Laurentiu Tudor wrote:
> > Hi Joakim,
> >
> > > -Original Message-
> > > From: Joakim Tjernlund
> > > Sent: Saturday, April 27, 2019 8:11 PM
> > >
> > > On Sat, 2019-04-27 at 10:10 +0300, laurentiu.tu...@nxp.com wrote:
> > > > From: Laurentiu Tudor
> > > >
> > > > Fix issue with the entry indexing in the sg frame cleanup code being
> > > > off-by-1. This problem showed up when doing some basic iperf tests
> and
> > > > manifested in traffic coming to a halt.
> > > >
> > > > Signed-off-by: Laurentiu Tudor
> > > > Acked-by: Madalin Bucur
> > >
> > > Wasn't this a stable candidate too?
> >
> > Yes, it is. I forgot to add the cc:stable tag, sorry about that.
>
> Then this is a bug fix that should go directly to linus/stable.
>
> I note that
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/net/ethernet/freescale/dpaa?h=linux-4.19.y
Not sure I understand ... I don't see the patch in the link.
> is in 4.19 but not in 4.14 , is it not appropriate for 4.14?
I think it makes sense to go in both stable trees.
---
Best Regards, Laurentiu
> >
> > > > ---
> > > > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > > b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > > > index daede7272768..40420edc9ce6 100644
> > > > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > > > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > > > @@ -1663,7 +1663,7 @@ static struct sk_buff
> *dpaa_cleanup_tx_fd(const
> > > struct dpaa_priv *priv,
> > > > qm_sg_entry_get_len(&sgt[0]),
> dma_dir);
> > > >
> > > > /* remaining pages were mapped with
> skb_frag_dma_map()
> > > */
> > > > - for (i = 1; i < nr_frags; i++) {
> > > > + for (i = 1; i <= nr_frags; i++) {
> > > > WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
> > > >
> > > > dma_unmap_page(dev, qm_sg_addr(&sgt[i]),
> > > > --
> > > > 2.17.1
> > > >
RE: [PATCH v2 7/9] dpaa_eth: fix iova handling for contiguous frames
> -Original Message- > From: Christoph Hellwig > Sent: Saturday, April 27, 2019 7:46 PM > > On Sat, Apr 27, 2019 at 10:10:29AM +0300, laurentiu.tu...@nxp.com wrote: > > From: Laurentiu Tudor > > > > The driver relies on the no longer valid assumption that dma addresses > > (iovas) are identical to physical addressees and uses phys_to_virt() to > > make iova -> vaddr conversions. Fix this by adding a function that does > > proper iova -> phys conversions using the iommu api and update the code > > to use it. > > Also, a dma_unmap_single() call had to be moved further down the code > > because iova -> vaddr conversions were required before the unmap. > > For now only the contiguous frame case is handled and the SG case is > > split in a following patch. > > While at it, clean-up a redundant dpaa_bpid2pool() and pass the bp > > as parameter. > > Err, this is broken. A driver using the DMA API has no business > call IOMMU APIs. Just save the _virtual_ address used for the mapping > away and use that again. We should not go through crazy gymnastics > like this. I think that due to the particularity of this hardware we don't have a way of saving the VA, but I'd let my colleagues maintaining this driver to comment more on why we need to do this. --- Best Regards, Laurentiu
RE: [PATCH v2 9/9] dpaa_eth: fix SG frame cleanup
Hi Joakim,
> -Original Message-
> From: Joakim Tjernlund
> Sent: Saturday, April 27, 2019 8:11 PM
>
> On Sat, 2019-04-27 at 10:10 +0300, laurentiu.tu...@nxp.com wrote:
> > From: Laurentiu Tudor
> >
> > Fix issue with the entry indexing in the sg frame cleanup code being
> > off-by-1. This problem showed up when doing some basic iperf tests and
> > manifested in traffic coming to a halt.
> >
> > Signed-off-by: Laurentiu Tudor
> > Acked-by: Madalin Bucur
>
> Wasn't this a stable candidate too?
Yes, it is. I forgot to add the cc:stable tag, sorry about that.
---
Best Regards, Laurentiu
> > ---
> > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > index daede7272768..40420edc9ce6 100644
> > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > @@ -1663,7 +1663,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const
> struct dpaa_priv *priv,
> > qm_sg_entry_get_len(&sgt[0]), dma_dir);
> >
> > /* remaining pages were mapped with skb_frag_dma_map()
> */
> > - for (i = 1; i < nr_frags; i++) {
> > + for (i = 1; i <= nr_frags; i++) {
> > WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
> >
> > dma_unmap_page(dev, qm_sg_addr(&sgt[i]),
> > --
> > 2.17.1
> >
[PATCH v2 9/9] dpaa_eth: fix SG frame cleanup
From: Laurentiu Tudor
Fix issue with the entry indexing in the sg frame cleanup code being
off-by-1. This problem showed up when doing some basic iperf tests and
manifested in traffic coming to a halt.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index daede7272768..40420edc9ce6 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1663,7 +1663,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
qm_sg_entry_get_len(&sgt[0]), dma_dir);
/* remaining pages were mapped with skb_frag_dma_map() */
- for (i = 1; i < nr_frags; i++) {
+ for (i = 1; i <= nr_frags; i++) {
WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
dma_unmap_page(dev, qm_sg_addr(&sgt[i]),
--
2.17.1
[PATCH v2 8/9] dpaa_eth: fix iova handling for sg frames
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this also for scatter-gather frames
using the iova -> phys conversion function added in the previous patch.
While at it, clean-up a redundant dpaa_bpid2pool() and pass the bp
as parameter.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 41 +++
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index f17edc80dc37..daede7272768 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1646,14 +1646,17 @@ 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,
-qm_fd_get_offset(fd) + DPAA_SGT_SIZE,
-dma_dir);
/* The sgt buffer has been allocated with netdev_alloc_frag(),
* it's from lowmem.
*/
- sgt = phys_to_virt(addr + qm_fd_get_offset(fd));
+ sgt = phys_to_virt(dpaa_iova_to_phys(dev,
+addr +
+qm_fd_get_offset(fd)));
+
+ dma_unmap_single(dev, addr,
+qm_fd_get_offset(fd) + DPAA_SGT_SIZE,
+dma_dir);
/* sgt[0] is from lowmem, was dma_map_single()-ed */
dma_unmap_single(dev, qm_sg_addr(&sgt[0]),
@@ -1668,7 +1671,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
}
/* Free the page frag that we allocated on Tx */
- skb_free_frag(phys_to_virt(addr));
+ skb_free_frag(skbh);
} else {
dma_unmap_single(dev, addr,
skb_tail_pointer(skb) - (u8 *)skbh, dma_dir);
@@ -1729,14 +1732,14 @@ static struct sk_buff *contig_fd_to_skb(const struct
dpaa_priv *priv,
* The page fragment holding the S/G Table is recycled here.
*/
static struct sk_buff *sg_fd_to_skb(const struct dpaa_priv *priv,
- const struct qm_fd *fd)
+ const struct qm_fd *fd,
+ struct dpaa_bp *dpaa_bp,
+ void *vaddr)
{
ssize_t fd_off = qm_fd_get_offset(fd);
- dma_addr_t addr = qm_fd_addr(fd);
const struct qm_sg_entry *sgt;
struct page *page, *head_page;
- struct dpaa_bp *dpaa_bp;
- void *vaddr, *sg_vaddr;
+ void *sg_vaddr;
int frag_off, frag_len;
struct sk_buff *skb;
dma_addr_t sg_addr;
@@ -1745,7 +1748,6 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
int *count_ptr;
int i;
- vaddr = phys_to_virt(addr);
WARN_ON(!IS_ALIGNED((unsigned long)vaddr, SMP_CACHE_BYTES));
/* Iterate through the SGT entries and add data buffers to the skb */
@@ -1756,14 +1758,18 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
sg_addr = qm_sg_addr(&sgt[i]);
- sg_vaddr = phys_to_virt(sg_addr);
- WARN_ON(!IS_ALIGNED((unsigned long)sg_vaddr,
- SMP_CACHE_BYTES));
/* We may use multiple Rx pools */
dpaa_bp = dpaa_bpid2pool(sgt[i].bpid);
- if (!dpaa_bp)
+ if (!dpaa_bp) {
+ pr_info("%s: fail to get dpaa_bp for sg bpid %d\n",
+ __func__, sgt[i].bpid);
goto free_buffers;
+ }
+ sg_vaddr = phys_to_virt(dpaa_iova_to_phys(dpaa_bp->dev,
+ sg_addr));
+ WARN_ON(!IS_ALIGNED((unsigned long)sg_vaddr,
+ SMP_CACHE_BYTES));
count_ptr = this_cpu_ptr(dpaa_bp->percpu_count);
dma_unmap_single(dpaa_bp->dev, sg_addr, dpaa_bp->size,
@@ -1835,10 +1841,11 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
/* free all the SG entries */
for (i = 0; i < DPAA_SGT_MAX_ENTRIES ; i++) {
sg_addr = qm_sg_addr(&sgt[i]);
- sg_vaddr = phys_to_virt(sg_addr);
- skb_free_frag(sg_vaddr);
dpaa_bp = dpaa_bpid2pool(sgt[i].bpid);
if (dpaa_bp
[PATCH v2 7/9] dpaa_eth: fix iova handling for contiguous frames
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this by adding a function that does
proper iova -> phys conversions using the iommu api and update the code
to use it.
Also, a dma_unmap_single() call had to be moved further down the code
because iova -> vaddr conversions were required before the unmap.
For now only the contiguous frame case is handled and the SG case is
split in a following patch.
While at it, clean-up a redundant dpaa_bpid2pool() and pass the bp
as parameter.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 44 ++-
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index cdc7e6d83f77..f17edc80dc37 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1595,6 +1596,17 @@ static int dpaa_eth_refill_bpools(struct dpaa_priv *priv)
return 0;
}
+static phys_addr_t dpaa_iova_to_phys(struct device *dev, dma_addr_t addr)
+{
+ struct iommu_domain *domain;
+
+ domain = iommu_get_domain_for_dev(dev);
+ if (domain)
+ return iommu_iova_to_phys(domain, addr);
+ else
+ return addr;
+}
+
/* Cleanup function for outgoing frame descriptors that were built on Tx path,
* either contiguous frames or scatter/gather ones.
* Skb freeing is not handled here.
@@ -1617,7 +1629,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
int nr_frags, i;
u64 ns;
- skbh = (struct sk_buff **)phys_to_virt(addr);
+ skbh = (struct sk_buff **)phys_to_virt(dpaa_iova_to_phys(dev, addr));
skb = *skbh;
if (priv->tx_tstamp && skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
@@ -1687,25 +1699,21 @@ static u8 rx_csum_offload(const struct dpaa_priv *priv,
const struct qm_fd *fd)
* accommodate the shared info area of the skb.
*/
static struct sk_buff *contig_fd_to_skb(const struct dpaa_priv *priv,
- const struct qm_fd *fd)
+ const struct qm_fd *fd,
+ struct dpaa_bp *dpaa_bp,
+ void *vaddr)
{
ssize_t fd_off = qm_fd_get_offset(fd);
- dma_addr_t addr = qm_fd_addr(fd);
- struct dpaa_bp *dpaa_bp;
struct sk_buff *skb;
- void *vaddr;
- vaddr = phys_to_virt(addr);
WARN_ON(!IS_ALIGNED((unsigned long)vaddr, SMP_CACHE_BYTES));
- dpaa_bp = dpaa_bpid2pool(fd->bpid);
- if (!dpaa_bp)
- goto free_buffer;
-
skb = build_skb(vaddr, dpaa_bp->size +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
- if (WARN_ONCE(!skb, "Build skb failure on Rx\n"))
- goto free_buffer;
+ if (WARN_ONCE(!skb, "Build skb failure on Rx\n")) {
+ skb_free_frag(vaddr);
+ return NULL;
+ }
WARN_ON(fd_off != priv->rx_headroom);
skb_reserve(skb, fd_off);
skb_put(skb, qm_fd_get_length(fd));
@@ -1713,10 +1721,6 @@ static struct sk_buff *contig_fd_to_skb(const struct
dpaa_priv *priv,
skb->ip_summed = rx_csum_offload(priv, fd);
return skb;
-
-free_buffer:
- skb_free_frag(vaddr);
- return NULL;
}
/* Build an skb with the data of the first S/G entry in the linear portion and
@@ -2309,12 +2313,12 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct
qman_portal *portal,
if (!dpaa_bp)
return qman_cb_dqrr_consume;
- dma_unmap_single(dpaa_bp->dev, addr, dpaa_bp->size, DMA_FROM_DEVICE);
-
/* prefetch the first 64 bytes of the frame or the SGT start */
- vaddr = phys_to_virt(addr);
+ vaddr = phys_to_virt(dpaa_iova_to_phys(dpaa_bp->dev, addr));
prefetch(vaddr + qm_fd_get_offset(fd));
+ dma_unmap_single(dpaa_bp->dev, addr, dpaa_bp->size, DMA_FROM_DEVICE);
+
/* The only FD types that we may receive are contig and S/G */
WARN_ON((fd_format != qm_fd_contig) && (fd_format != qm_fd_sg));
@@ -2325,7 +2329,7 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct
qman_portal *portal,
(*count_ptr)--;
if (likely(fd_format == qm_fd_contig))
- skb = contig_fd_to_skb(priv, fd);
+ skb = contig_fd_to_skb(priv, fd, dpaa_bp, vaddr);
else
skb = sg_fd_to_skb(priv, fd);
if (!skb)
--
2.17.1
[PATCH v2 5/9] dpaa_eth: defer probing after qbman
From: Laurentiu Tudor
Enabling SMMU altered the order of device probing causing the dpaa1
ethernet driver to get probed before qbman and causing a boot crash.
Add predictability in the probing order by deferring the ethernet
driver probe after qbman and portals by using the recently introduced
qbman APIs.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index dfebc30c4841..647e90e7434f 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2774,6 +2774,37 @@ static int dpaa_eth_probe(struct platform_device *pdev)
int err = 0, i, channel;
struct device *dev;
+ err = bman_is_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev, "failing probe due to bman probe error\n");
+ return -ENODEV;
+ }
+ err = qman_is_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev, "failing probe due to qman probe error\n");
+ return -ENODEV;
+ }
+ err = bman_portals_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev,
+ "failing probe due to bman portals probe error\n");
+ return -ENODEV;
+ }
+ err = qman_portals_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev,
+ "failing probe due to qman portals probe error\n");
+ return -ENODEV;
+ }
+
/* device used for DMA mapping */
dev = pdev->dev.parent;
err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
--
2.17.1
[PATCH v2 3/9] fsl/fman: backup and restore ICID registers
From: Laurentiu Tudor
During probing, FMAN is reset thus losing all its register
settings. Backup port ICID registers before reset and restore
them after, similarly to how it's done on powerpc / PAMU based
platforms.
This also has the side effect of disabling the old code path
(liodn backup/restore handling) that obviously make no sense
in the context of SMMU on ARMs.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/fman/fman.c | 35 +-
drivers/net/ethernet/freescale/fman/fman.h | 4 +++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c
b/drivers/net/ethernet/freescale/fman/fman.c
index e80fedb27cee..ae833e215b74 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -629,6 +629,7 @@ static void set_port_order_restoration(struct fman_fpm_regs
__iomem *fpm_rg,
iowrite32be(tmp, &fpm_rg->fmfp_prc);
}
+#ifdef CONFIG_PPC
static void set_port_liodn(struct fman *fman, u8 port_id,
u32 liodn_base, u32 liodn_ofst)
{
@@ -646,6 +647,27 @@ static void set_port_liodn(struct fman *fman, u8 port_id,
iowrite32be(tmp, &fman->dma_regs->fmdmplr[port_id / 2]);
iowrite32be(liodn_ofst, &fman->bmi_regs->fmbm_spliodn[port_id - 1]);
}
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+static void save_restore_port_icids(struct fman *fman, bool save)
+{
+ int port_idxes[] = {
+ 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc,
+ 0xd, 0xe, 0xf, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
+ 0x10, 0x11, 0x30, 0x31
+ };
+ int idx, i;
+
+ for (i = 0; i < ARRAY_SIZE(port_idxes); i++) {
+ idx = port_idxes[i];
+ if (save)
+ fman->sp_icids[idx] =
+ ioread32be(&fman->bmi_regs->fmbm_spliodn[idx]);
+ else
+ iowrite32be(fman->sp_icids[idx],
+ &fman->bmi_regs->fmbm_spliodn[idx]);
+ }
+}
+#endif
static void enable_rams_ecc(struct fman_fpm_regs __iomem *fpm_rg)
{
@@ -1914,7 +1936,10 @@ static int fman_reset(struct fman *fman)
static int fman_init(struct fman *fman)
{
struct fman_cfg *cfg = NULL;
- int err = 0, i, count;
+ int err = 0, count;
+#ifdef CONFIG_PPC
+ int i;
+#endif
if (is_init_done(fman->cfg))
return -EINVAL;
@@ -1934,6 +1959,7 @@ static int fman_init(struct fman *fman)
memset_io((void __iomem *)(fman->base_addr + CGP_OFFSET), 0,
fman->state->fm_port_num_of_cg);
+#ifdef CONFIG_PPC
/* Save LIODN info before FMan reset
* Skipping non-existent port 0 (i = 1)
*/
@@ -1953,6 +1979,9 @@ static int fman_init(struct fman *fman)
}
fman->liodn_base[i] = liodn_base;
}
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+ save_restore_port_icids(fman, true);
+#endif
err = fman_reset(fman);
if (err)
@@ -2181,8 +2210,12 @@ int fman_set_port_params(struct fman *fman,
if (err)
goto return_err;
+#ifdef CONFIG_PPC
set_port_liodn(fman, port_id, fman->liodn_base[port_id],
fman->liodn_offset[port_id]);
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+ save_restore_port_icids(fman, false);
+#endif
if (fman->state->rev_info.major < 6)
set_port_order_restoration(fman->fpm_regs, port_id);
diff --git a/drivers/net/ethernet/freescale/fman/fman.h
b/drivers/net/ethernet/freescale/fman/fman.h
index 935c317fa696..19f20fa58053 100644
--- a/drivers/net/ethernet/freescale/fman/fman.h
+++ b/drivers/net/ethernet/freescale/fman/fman.h
@@ -346,8 +346,12 @@ struct fman {
unsigned long fifo_offset;
size_t fifo_size;
+#ifdef CONFIG_PPC
u32 liodn_base[64];
u32 liodn_offset[64];
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+ u32 sp_icids[64];
+#endif
struct fman_dts_params dts_params;
};
--
2.17.1
[PATCH v2 6/9] dpaa_eth: base dma mappings on the fman rx port
From: Laurentiu Tudor
The dma transactions initiator is the rx fman port so that's the device
that the dma mappings should be done. Previously the mappings were done
through the MAC device which makes no sense because it's neither dma-able
nor connected in any way to smmu.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 647e90e7434f..cdc7e6d83f77 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2805,8 +2805,15 @@ static int dpaa_eth_probe(struct platform_device *pdev)
return -ENODEV;
}
+ mac_dev = dpaa_mac_dev_get(pdev);
+ if (IS_ERR(mac_dev)) {
+ dev_err(&pdev->dev, "dpaa_mac_dev_get() failed\n");
+ err = PTR_ERR(mac_dev);
+ goto probe_err;
+ }
+
/* device used for DMA mapping */
- dev = pdev->dev.parent;
+ dev = fman_port_get_device(mac_dev->port[RX]);
err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
if (err) {
dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
@@ -2831,13 +2838,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
priv->msg_enable = netif_msg_init(debug, DPAA_MSG_DEFAULT);
- mac_dev = dpaa_mac_dev_get(pdev);
- if (IS_ERR(mac_dev)) {
- dev_err(dev, "dpaa_mac_dev_get() failed\n");
- err = PTR_ERR(mac_dev);
- goto free_netdev;
- }
-
/* If fsl_fm_max_frm is set to a higher value than the all-common 1500,
* we choose conservatively and let the user explicitly set a higher
* MTU via ifconfig. Otherwise, the user may end up with different MTUs
@@ -2973,9 +2973,9 @@ static int dpaa_eth_probe(struct platform_device *pdev)
qman_release_cgrid(priv->cgr_data.cgr.cgrid);
free_dpaa_bps:
dpaa_bps_free(priv);
-free_netdev:
dev_set_drvdata(dev, NULL);
free_netdev(net_dev);
+probe_err:
return err;
}
--
2.17.1
[PATCH v2 4/9] fsl/fman: add API to get the device behind a fman port
From: Laurentiu Tudor
Add an API that retrieves the 'struct device' that the specified fman
port probed against. The new API will be used in a subsequent iommu
enablement related patch.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/fman/fman_port.c | 14 ++
drivers/net/ethernet/freescale/fman/fman_port.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c
b/drivers/net/ethernet/freescale/fman/fman_port.c
index ee82ee1384eb..bd76c9730692 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.c
+++ b/drivers/net/ethernet/freescale/fman/fman_port.c
@@ -1728,6 +1728,20 @@ u32 fman_port_get_qman_channel_id(struct fman_port *port)
}
EXPORT_SYMBOL(fman_port_get_qman_channel_id);
+/**
+ * fman_port_get_device
+ * port: Pointer to the FMan port device
+ *
+ * Get the 'struct device' associated to the specified FMan port device
+ *
+ * Return: pointer to associated 'struct device'
+ */
+struct device *fman_port_get_device(struct fman_port *port)
+{
+ return port->dev;
+}
+EXPORT_SYMBOL(fman_port_get_device);
+
int fman_port_get_hash_result_offset(struct fman_port *port, u32 *offset)
{
if (port->buffer_offsets.hash_result_offset == ILLEGAL_BASE)
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.h
b/drivers/net/ethernet/freescale/fman/fman_port.h
index 9dbb69f40121..82f12661a46d 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.h
+++ b/drivers/net/ethernet/freescale/fman/fman_port.h
@@ -157,4 +157,6 @@ int fman_port_get_tstamp(struct fman_port *port, const void
*data, u64 *tstamp);
struct fman_port *fman_port_bind(struct device *dev);
+struct device *fman_port_get_device(struct fman_port *port);
+
#endif /* __FMAN_PORT_H */
--
2.17.1
[PATCH v2 1/9] 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 +-
drivers/soc/fsl/qbman/qman_priv.h | 9 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
b/drivers/soc/fsl/qbman/qman_ccsr.c
index 109b38de3176..a6bb43007d03 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -596,7 +596,7 @@ static int qman_init_ccsr(struct device *dev)
}
#define LIO_CFG_LIODN_MASK 0x0fff
-void qman_liodn_fixup(u16 channel)
+void __qman_liodn_fixup(u16 channel)
{
static int done;
static u32 liodn_offset;
diff --git a/drivers/soc/fsl/qbman/qman_priv.h
b/drivers/soc/fsl/qbman/qman_priv.h
index 75a8f905f8f7..04515718cfd9 100644
--- a/drivers/soc/fsl/qbman/qman_priv.h
+++ b/drivers/soc/fsl/qbman/qman_priv.h
@@ -193,7 +193,14 @@ extern struct gen_pool *qm_cgralloc; /* CGR ID allocator */
u32 qm_get_pools_sdqcr(void);
int qman_wq_alloc(void);
-void qman_liodn_fixup(u16 channel);
+#ifdef CONFIG_FSL_PAMU
+#define qman_liodn_fixup __qman_liodn_fixup
+#else
+static inline void qman_liodn_fixup(u16 channel)
+{
+}
+#endif
+void __qman_liodn_fixup(u16 channel);
void qman_set_sdest(u16 channel, unsigned int cpu_idx);
struct qman_portal *qman_create_affine_portal(
--
2.17.1
[PATCH v2 2/9] soc/fsl/qbman_portals: add APIs to retrieve the probing status
From: Laurentiu Tudor
Add a couple of new APIs to check the probing status of the required
cpu bound qman and bman portals:
'int bman_portals_probed()' and 'int qman_portals_probed()'.
They return the following values.
* 1 if qman/bman portals were all probed correctly
* 0 if qman/bman portals were not yet probed
* -1 if probing of qman/bman portals failed
Portals are considered successful probed if no error occurred during
the probing of any of the portals and if enough portals were probed
to have one available for each cpu.
The error handling paths were slightly rearranged in order to fit this
new functionality without being too intrusive.
Drivers that use qman/bman portal driver services are required to use
these APIs before calling any functions exported by these drivers or
otherwise they will crash the kernel.
First user will be the dpaa1 ethernet driver, coming in a subsequent
patch.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_portal.c | 20
drivers/soc/fsl/qbman/qman_portal.c | 21 +
include/soc/fsl/bman.h | 8
include/soc/fsl/qman.h | 9 +
4 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/fsl/qbman/bman_portal.c
b/drivers/soc/fsl/qbman/bman_portal.c
index 2c95cf59f3e7..cf4f10d6f590 100644
--- a/drivers/soc/fsl/qbman/bman_portal.c
+++ b/drivers/soc/fsl/qbman/bman_portal.c
@@ -32,6 +32,7 @@
static struct bman_portal *affine_bportals[NR_CPUS];
static struct cpumask portal_cpus;
+static int __bman_portals_probed;
/* protect bman global registers and global data shared among portals */
static DEFINE_SPINLOCK(bman_lock);
@@ -87,6 +88,12 @@ static int bman_online_cpu(unsigned int cpu)
return 0;
}
+int bman_portals_probed(void)
+{
+ return __bman_portals_probed;
+}
+EXPORT_SYMBOL_GPL(bman_portals_probed);
+
static int bman_portal_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -104,8 +111,10 @@ static int bman_portal_probe(struct platform_device *pdev)
}
pcfg = devm_kmalloc(dev, sizeof(*pcfg), GFP_KERNEL);
- if (!pcfg)
+ if (!pcfg) {
+ __bman_portals_probed = -1;
return -ENOMEM;
+ }
pcfg->dev = dev;
@@ -113,14 +122,14 @@ static int bman_portal_probe(struct platform_device *pdev)
DPAA_PORTAL_CE);
if (!addr_phys[0]) {
dev_err(dev, "Can't get %pOF property 'reg::CE'\n", node);
- return -ENXIO;
+ goto err_ioremap1;
}
addr_phys[1] = platform_get_resource(pdev, IORESOURCE_MEM,
DPAA_PORTAL_CI);
if (!addr_phys[1]) {
dev_err(dev, "Can't get %pOF property 'reg::CI'\n", node);
- return -ENXIO;
+ goto err_ioremap1;
}
pcfg->cpu = -1;
@@ -128,7 +137,7 @@ static int bman_portal_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq <= 0) {
dev_err(dev, "Can't get %pOF IRQ'\n", node);
- return -ENXIO;
+ goto err_ioremap1;
}
pcfg->irq = irq;
@@ -150,6 +159,7 @@ static int bman_portal_probe(struct platform_device *pdev)
spin_lock(&bman_lock);
cpu = cpumask_next_zero(-1, &portal_cpus);
if (cpu >= nr_cpu_ids) {
+ __bman_portals_probed = 1;
/* unassigned portal, skip init */
spin_unlock(&bman_lock);
return 0;
@@ -175,6 +185,8 @@ static int bman_portal_probe(struct platform_device *pdev)
err_ioremap2:
memunmap(pcfg->addr_virt_ce);
err_ioremap1:
+__bman_portals_probed = -1;
+
return -ENXIO;
}
diff --git a/drivers/soc/fsl/qbman/qman_portal.c
b/drivers/soc/fsl/qbman/qman_portal.c
index 661c9b234d32..e2186b681d87 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -38,6 +38,7 @@ EXPORT_SYMBOL(qman_dma_portal);
#define CONFIG_FSL_DPA_PIRQ_FAST 1
static struct cpumask portal_cpus;
+static int __qman_portals_probed;
/* protect qman global registers and global data shared among portals */
static DEFINE_SPINLOCK(qman_lock);
@@ -220,6 +221,12 @@ static int qman_online_cpu(unsigned int cpu)
return 0;
}
+int qman_portals_probed(void)
+{
+ return __qman_portals_probed;
+}
+EXPORT_SYMBOL_GPL(qman_portals_probed);
+
static int qman_portal_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -238,8 +245,10 @@ static int qman_portal_probe(struct platform_device *pdev)
}
pcfg = devm_kmalloc(dev, sizeof(*pcfg), GFP_KERNEL);
- if (!pcfg)
+ if (!pcfg) {
+
[PATCH v2 0/9] Prerequisites for NXP LS104xA SMMU enablement
From: Laurentiu Tudor This patch series contains several fixes in preparation for SMMU support on NXP LS1043A and LS1046A chips. Once these get picked up, I'll submit the actual SMMU enablement patches consisting in the required device tree changes. This patch series contains only part of the previously submitted one, (including also the device tree changes) available here: https://patchwork.kernel.org/cover/10634443/ Changes in v2: - dropped patches dealing with mapping reserved memory in iommu - changed logic for qman portal probe status (Leo) - moved "#ifdef CONFIG_PAMU" in header file (Leo) - rebased on v5.1.0-rc5 Laurentiu Tudor (9): soc/fsl/qman: fixup liodns only on ppc targets soc/fsl/qbman_portals: add APIs to retrieve the probing status fsl/fman: backup and restore ICID registers fsl/fman: add API to get the device behind a fman port dpaa_eth: defer probing after qbman dpaa_eth: base dma mappings on the fman rx port dpaa_eth: fix iova handling for contiguous frames dpaa_eth: fix iova handling for sg frames dpaa_eth: fix SG frame cleanup .../net/ethernet/freescale/dpaa/dpaa_eth.c| 136 -- drivers/net/ethernet/freescale/fman/fman.c| 35 - drivers/net/ethernet/freescale/fman/fman.h| 4 + .../net/ethernet/freescale/fman/fman_port.c | 14 ++ .../net/ethernet/freescale/fman/fman_port.h | 2 + drivers/soc/fsl/qbman/bman_portal.c | 20 ++- drivers/soc/fsl/qbman/qman_ccsr.c | 2 +- drivers/soc/fsl/qbman/qman_portal.c | 21 ++- drivers/soc/fsl/qbman/qman_priv.h | 9 +- include/soc/fsl/bman.h| 8 ++ include/soc/fsl/qman.h| 9 ++ 11 files changed, 202 insertions(+), 58 deletions(-) -- 2.17.1
RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu
Hi Robin, > -Original Message- > From: Robin Murphy > Sent: Friday, March 29, 2019 4:51 PM > > On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote: > > From: Laurentiu Tudor > > > > Add a one-to-one iommu mapping for bman private data memory (FBPR). > > This is required for BMAN to work without faults behind an iommu. > > > > Signed-off-by: Laurentiu Tudor > > --- > > drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c > b/drivers/soc/fsl/qbman/bman_ccsr.c > > index 7c3cc968053c..b209c79511bb 100644 > > --- a/drivers/soc/fsl/qbman/bman_ccsr.c > > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c > > @@ -29,6 +29,7 @@ > >*/ > > > > #include "bman_priv.h" > > +#include > > > > u16 bman_ip_rev; > > EXPORT_SYMBOL(bman_ip_rev); > > @@ -178,6 +179,7 @@ static int fsl_bman_probe(struct platform_device > *pdev) > > int ret, err_irq; > > struct device *dev = &pdev->dev; > > struct device_node *node = dev->of_node; > > + struct iommu_domain *domain; > > struct resource *res; > > u16 id, bm_pool_cnt; > > u8 major, minor; > > @@ -225,6 +227,15 @@ static int fsl_bman_probe(struct platform_device > *pdev) > > > > dev_dbg(dev, "Allocated FBPR 0x%llx 0x%zx\n", fbpr_a, fbpr_sz); > > > > + /* Create an 1-to-1 iommu mapping for FBPR area */ > > + domain = iommu_get_domain_for_dev(dev); > > If that's expected to be the default domain that you're grabbing, then > this is *incredibly* fragile. There's nothing to stop the IOVA that you > forcibly map from being automatically allocated later and causing some > other DMA mapping to fail noisily and unexpectedly. Furthermore, have > you tried this with "iommu.passthrough=1"? > > That said, I really don't understand what's going on here anyway :/ > > As far as I can tell from qbman_init_private_mem(), fbpr_a comes from > dma_alloc_coherent() and thus would already be a mapped IOVA - isn't > this the stuff that Roy converted to nicely use shared-dma-pool regions > a while ago? > Finally found some time to look into this, sorry for the delay. It seems that on the code path taken in our case (dma_alloc_coherent() -> dma_alloc_attrs() -> dma_alloc_from_dev_coherent() -> __dma_alloc_from_coherent()) there's no call into the iommu layer, thus no mapping in the smmu. I plan to come up with a RFC patch early next week so we have something concrete to discuss on. --- Best Regards, Laurentiu
[PATCH v2] powerpc/booke64: set RI in default MSR
From: Laurentiu Tudor Set RI in the default kernel's MSR so that the architected way of detecting unrecoverable machine check interrupts has a chance to work. This is inline with the MSR setup of the rest of booke powerpc architectures configured here. Signed-off-by: Laurentiu Tudor Cc: sta...@vger.kernel.org --- Changes in v2: - fixed typo - s/SI/RI arch/powerpc/include/asm/reg_booke.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index eb2a33d5df26..e382bd6ede84 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -41,7 +41,7 @@ #if defined(CONFIG_PPC_BOOK3E_64) #define MSR_64BIT MSR_CM -#define MSR_ (MSR_ME | MSR_CE) +#define MSR_ (MSR_ME | MSR_RI | MSR_CE) #define MSR_KERNEL (MSR_ | MSR_64BIT) #define MSR_USER32 (MSR_ | MSR_PR | MSR_EE) #define MSR_USER64 (MSR_USER32 | MSR_64BIT) -- 2.17.1
[PATCH] powerpc/booke64: set RI in default MSR
From: Laurentiu Tudor Set SI in the default kernel's MSR so that the architected way of detecting unrecoverable machine check interrupts has a chance to work. This is inline with the MSR setup of the rest of booke powerpc architectures configured here. Signed-off-by: Laurentiu Tudor Cc: sta...@vger.kernel.org --- arch/powerpc/include/asm/reg_booke.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index eb2a33d5df26..e382bd6ede84 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -41,7 +41,7 @@ #if defined(CONFIG_PPC_BOOK3E_64) #define MSR_64BIT MSR_CM -#define MSR_ (MSR_ME | MSR_CE) +#define MSR_ (MSR_ME | MSR_RI | MSR_CE) #define MSR_KERNEL (MSR_ | MSR_64BIT) #define MSR_USER32 (MSR_ | MSR_PR | MSR_EE) #define MSR_USER64 (MSR_USER32 | MSR_64BIT) -- 2.17.1
Re: [PATCH v2 1/2] bus: mc-bus: Add support for mapping shareable portals
Hi Roy,
On 05.04.2019 17:41, Roy Pledge wrote:
> Starting with v5 of NXP QBMan devices the hardware supports using
> regular cacheable/shareable memory as the backing store for the
> portals.
>
> This patch adds support for the new portal mode by switching to
> use the DPRC get object region v2 command which returns both
> a base address and offset for the portal memory. The new portal
> region is identified as shareable through the addition of a new
> flag.
>
> Signed-off-by: Roy Pledge
Looks good to me:
Reviewed-by: Laurentiu Tudor
---
Best Regards, Laurentiu
> ---
> drivers/bus/fsl-mc/dprc.c | 30 +++---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 15 +--
> drivers/bus/fsl-mc/fsl-mc-private.h | 17 +++--
> 3 files changed, 55 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
> index 1c3f621..0fe3f52 100644
> --- a/drivers/bus/fsl-mc/dprc.c
> +++ b/drivers/bus/fsl-mc/dprc.c
> @@ -443,11 +443,31 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
> struct fsl_mc_command cmd = { 0 };
> struct dprc_cmd_get_obj_region *cmd_params;
> struct dprc_rsp_get_obj_region *rsp_params;
> + u16 major_ver, minor_ver;
> int err;
>
> /* prepare command */
> - cmd.header = mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG,
> - cmd_flags, token);
> + err = dprc_get_api_version(mc_io, 0,
> + &major_ver,
> + &minor_ver);
> + if (err)
> + return err;
> +
> + /**
> + * MC API version 6.3 introduced a new field to the region
> + * descriptor: base_address. If the older API is in use then the base
> + * address is set to zero to indicate it needs to be obtained elsewhere
> + * (typically the device tree).
> + */
> + if (major_ver > 6 || (major_ver == 6 && minor_ver >= 3))
> + cmd.header =
> + mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG_V2,
> + cmd_flags, token);
> + else
> + cmd.header =
> + mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG,
> + cmd_flags, token);
> +
> cmd_params = (struct dprc_cmd_get_obj_region *)cmd.params;
> cmd_params->obj_id = cpu_to_le32(obj_id);
> cmd_params->region_index = region_index;
> @@ -461,8 +481,12 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
>
> /* retrieve response parameters */
> rsp_params = (struct dprc_rsp_get_obj_region *)cmd.params;
> - region_desc->base_offset = le64_to_cpu(rsp_params->base_addr);
> + region_desc->base_offset = le64_to_cpu(rsp_params->base_offset);
> region_desc->size = le32_to_cpu(rsp_params->size);
> + if (major_ver > 6 || (major_ver == 6 && minor_ver >= 3))
> + region_desc->base_address = le64_to_cpu(rsp_params->base_addr);
> + else
> + region_desc->base_address = 0;
>
> return 0;
> }
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index f0404c6..5c9bf2e 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -487,10 +487,19 @@ static int fsl_mc_device_get_mmio_regions(struct
> fsl_mc_device *mc_dev,
> "dprc_get_obj_region() failed: %d\n", error);
> goto error_cleanup_regions;
> }
> -
> - error = translate_mc_addr(mc_dev, mc_region_type,
> + /*
> + * Older MC only returned region offset and no base address
> + * If base address is in the region_desc use it otherwise
> + * revert to old mechanism
> + */
> + if (region_desc.base_address)
> + regions[i].start = region_desc.base_address +
> + region_desc.base_offset;
> + else
> + error = translate_mc_addr(mc_dev, mc_region_type,
> region_desc.base_offset,
> ®ions[i].start);
> +
> if (error < 0) {
> dev_err(parent_dev,
> "Invalid MC offset: %#x (for %s.%d\'s region
> %d)\n",
> @@ -504,6 +513,8 @@ static int fsl_mc_device_get_mmio_regions(struct
> fsl_mc_device *mc_dev,
> regions[i].flags = IORESOURCE_IO;
>
RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu
Hi Leo,
> -Original Message-
> From: Li Yang [mailto:leoyang...@nxp.com]
> Sent: Friday, March 29, 2019 11:16 PM
>
> On Fri, Mar 29, 2019 at 9:03 AM wrote:
> >
> > From: Laurentiu Tudor
> >
> > Add a one-to-one iommu mapping for bman private data memory (FBPR).
> > This is required for BMAN to work without faults behind an iommu.
> >
> > Signed-off-by: Laurentiu Tudor
> > ---
> > drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
> b/drivers/soc/fsl/qbman/bman_ccsr.c
> > index 7c3cc968053c..b209c79511bb 100644
> > --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
> > @@ -29,6 +29,7 @@
> > */
> >
> > #include "bman_priv.h"
> > +#include
> >
> > u16 bman_ip_rev;
> > EXPORT_SYMBOL(bman_ip_rev);
> > @@ -178,6 +179,7 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> > int ret, err_irq;
> > struct device *dev = &pdev->dev;
> > struct device_node *node = dev->of_node;
> > + struct iommu_domain *domain;
> > struct resource *res;
> > u16 id, bm_pool_cnt;
> > u8 major, minor;
> > @@ -225,6 +227,15 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> >
> > dev_dbg(dev, "Allocated FBPR 0x%llx 0x%zx\n", fbpr_a, fbpr_sz);
> >
> > + /* Create an 1-to-1 iommu mapping for FBPR area */
> > + domain = iommu_get_domain_for_dev(dev);
> > + if (domain) {
> > + ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
> > + IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > + if (ret)
> > + dev_warn(dev, "failed to iommu_map() %d\n",
> ret);
> > + }
>
> Like Robin has pointed out, could you explain why the mapping in this
> patch and other similar patches cannot be dealt with the dma APIs
> automatically? If the current bqman driver doesn't use the dma APIs
> correctly, we need to fix that instead of doing the mapping
> explicitly.
Please see my reply to Robin.
As a side comment, if we want to convert to dma api it will be interesting to
see how we'll deal with the qman portal devices as they require a smmu mapping
for an area of their register block (where stashing goes). Problem is they
treated as distinct devices, the address where they should dma cannot be
configured independently for each one of them. I think I can came up with a
proposal but probably will not look very pretty.
---
Best Regards, Laurentiu
> > +
> > bm_set_memory(fbpr_a, fbpr_sz);
> >
> > err_irq = platform_get_irq(pdev, 0);
> > --
> > 2.17.1
> >
RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu
Hi Robin,
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, March 29, 2019 4:51 PM
>
> On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote:
> > From: Laurentiu Tudor
> >
> > Add a one-to-one iommu mapping for bman private data memory (FBPR).
> > This is required for BMAN to work without faults behind an iommu.
> >
> > Signed-off-by: Laurentiu Tudor
> > ---
> > drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
> b/drivers/soc/fsl/qbman/bman_ccsr.c
> > index 7c3cc968053c..b209c79511bb 100644
> > --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
> > @@ -29,6 +29,7 @@
> >*/
> >
> > #include "bman_priv.h"
> > +#include
> >
> > u16 bman_ip_rev;
> > EXPORT_SYMBOL(bman_ip_rev);
> > @@ -178,6 +179,7 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> > int ret, err_irq;
> > struct device *dev = &pdev->dev;
> > struct device_node *node = dev->of_node;
> > + struct iommu_domain *domain;
> > struct resource *res;
> > u16 id, bm_pool_cnt;
> > u8 major, minor;
> > @@ -225,6 +227,15 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> >
> > dev_dbg(dev, "Allocated FBPR 0x%llx 0x%zx\n", fbpr_a, fbpr_sz);
> >
> > + /* Create an 1-to-1 iommu mapping for FBPR area */
> > + domain = iommu_get_domain_for_dev(dev);
>
> If that's expected to be the default domain that you're grabbing, then
> this is *incredibly* fragile. There's nothing to stop the IOVA that you
> forcibly map from being automatically allocated later and causing some
> other DMA mapping to fail noisily and unexpectedly.
Agree here, we pretty much rely on luck with this implementation. As a side
note, I've also experimented using dma_map_resource() instead of directly
calling into iommu api and things worked fine, but see below ...
> Furthermore, have you tried this with "iommu.passthrough=1"?
Yes. The iommu_map() calls fail and the drivers issue warning messages, but
apart from that I don't see any issues.
> That said, I really don't understand what's going on here anyway :/
>
> As far as I can tell from qbman_init_private_mem(), fbpr_a comes from
> dma_alloc_coherent() and thus would already be a mapped IOVA - isn't
> this the stuff that Roy converted to nicely use shared-dma-pool regions
> a while ago?
I must say that I'm also unclear on this. The thing is that I don't get to see
a smmu mapping being created for the reserved memory as result of calling
dma_alloc_coherent(). IIRC, at the time when I looked at this I concluded that
the call to dma_alloc_coherent() simply returns the phys address of the
device's reserved memory without creating a smmu mapping to back it up. Maybe
my understanding was not correct or perhaps there's an issue with this
shared-dma-pool mechanism where instead of creating a mapping in the smmu and
return an IOVA it just returns the physical address of the reserved memory area.
---
Thanks & Best Regards, Laurentiu
>
> > + if (domain) {
> > + ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
> > + IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > + if (ret)
> > + dev_warn(dev, "failed to iommu_map() %d\n", ret);
> > + }
> > +
> > bm_set_memory(fbpr_a, fbpr_sz);
> >
> > err_irq = platform_get_irq(pdev, 0);
> >
RE: [PATCH 13/13] dpaa_eth: fix SG frame cleanup
Hi Joakim,
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Friday, March 29, 2019 5:25 PM>
>
> Should this one go stable 4.14/4.19 too?
Good point. I also think it makes sense to cc: stable.
---
Best Regards, Laurentiu
> On Fri, 2019-03-29 at 16:00 +0200, laurentiu.tu...@nxp.com wrote:
> >
> > From: Laurentiu Tudor
> >
> > Fix issue with the entry indexing in the sg frame cleanup code being
> > off-by-1. This problem showed up when doing some basic iperf tests and
> > manifested in traffic coming to a halt.
> >
> > Signed-off-by: Laurentiu Tudor
> > Acked-by: Madalin Bucur
> > ---
> > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > index daede7272768..40420edc9ce6 100644
> > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > @@ -1663,7 +1663,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const
> struct dpaa_priv *priv,
> > qm_sg_entry_get_len(&sgt[0]), dma_dir);
> >
> > /* remaining pages were mapped with skb_frag_dma_map()
> */
> > - for (i = 1; i < nr_frags; i++) {
> > + for (i = 1; i <= nr_frags; i++) {
> > WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
> >
> > dma_unmap_page(dev, qm_sg_addr(&sgt[i]),
> > --
> > 2.17.1
> >
RE: [PATCH 01/13] soc/fsl/qman: fixup liodns only on ppc targets
Hi Leo,
> -Original Message-
> From: Li Yang [mailto:leoyang...@nxp.com]
> Sent: Friday, March 29, 2019 11:50 PM
> To: Laurentiu Tudor
> Cc: Netdev ; Madalin-cristian Bucur
> ; Roy Pledge ; Camelia
> Alexandra Groza ; David Miller
> ; Linux IOMMU ;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE ker...@lists.infradead.org>; linuxppc-dev ;
> lkml
> Subject: Re: [PATCH 01/13] soc/fsl/qman: fixup liodns only on ppc targets
> Importance: High
>
> On Fri, Mar 29, 2019 at 9:01 AM wrote:
> >
> > 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 109b38de3176..12e414ca3b03 100644
> > --- a/drivers/soc/fsl/qbman/qman_ccsr.c
> > +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
> > @@ -598,6 +598,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;
> > @@ -617,6 +618,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
>
> According to the Linux coding style recommendation, it would be better
> to put the #ifdef into the header files
> "drivers/soc/fsl/qbman/qman_priv.h". And I'm not sure if this is
> needed on PPC when IOMMU(PAMU) driver is not compiled, if not,
> probably using CONFIG_PAMU as condition would be even better.
Good point, will so in the next spin.
---
Best Regards, Laurentiu
> > }
> >
> > #define IO_CFG_SDEST_MASK 0x00ff
> > --
> > 2.17.1
> >
RE: [PATCH 05/13] soc/fsl/bqman: page align iommu mapping sizes
Hi Leo,
> -Original Message-
> From: Li Yang [mailto:leoyang...@nxp.com]
> Sent: Saturday, March 30, 2019 12:07 AM
> To: Laurentiu Tudor
> Cc: Netdev ; Madalin-cristian Bucur
> ; Roy Pledge ; Camelia
> Alexandra Groza ; David Miller
> ; Linux IOMMU ;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE ker...@lists.infradead.org>; linuxppc-dev ;
> lkml
> Subject: Re: [PATCH 05/13] soc/fsl/bqman: page align iommu mapping sizes
> Importance: High
>
> On Fri, Mar 29, 2019 at 9:01 AM wrote:
> >
> > From: Laurentiu Tudor
> >
> > Prior to calling iommu_map()/iommu_unmap() page align the size or
> > failures such as below could happen:
> >
> > iommu: unaligned: iova 0x... pa 0x... size 0x4000 min_pagesz 0x1
> > qman_portal 5.qman-portal: failed to iommu_map() -22
> >
> > Seen when booted a kernel compiled with 64K page size support.
>
> This will silently incease the actual space mapped to 64K when the
> driver is actually trying to map 4K. Will this potentially cause
> security breaches? If it is really safe to map 64K, probably the
> better way is to increase the region size to 64k in the device tree
> explicitly.
Not sure if such small reserved areas are practical, so I wouldn't worry
much. As an example, currently on ls1046a we reserve the following memory:
bman 16MB, qman fqd 8MB, qman pdfr 32MB.
But just to be on the safe side, maybe we could add an error check for
device trees that specify < 64KB reserved memory.
---
Best Regards, Laurentiu
> >
> > Signed-off-by: Laurentiu Tudor
> > ---
> > drivers/soc/fsl/qbman/bman_ccsr.c | 2 +-
> > drivers/soc/fsl/qbman/qman_ccsr.c | 4 ++--
> > drivers/soc/fsl/qbman/qman_portal.c | 2 +-
> > 3 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
> b/drivers/soc/fsl/qbman/bman_ccsr.c
> > index b209c79511bb..3a6e01bde32d 100644
> > --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
> > @@ -230,7 +230,7 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> > /* Create an 1-to-1 iommu mapping for FBPR area */
> > domain = iommu_get_domain_for_dev(dev);
> > if (domain) {
> > - ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
> > + ret = iommu_map(domain, fbpr_a, fbpr_a,
> PAGE_ALIGN(fbpr_sz),
> > IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > if (ret)
> > dev_warn(dev, "failed to iommu_map() %d\n",
> ret);
> > diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
> b/drivers/soc/fsl/qbman/qman_ccsr.c
> > index eec7700507e1..8d3c950ce52d 100644
> > --- a/drivers/soc/fsl/qbman/qman_ccsr.c
> > +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
> > @@ -783,11 +783,11 @@ static int fsl_qman_probe(struct platform_device
> *pdev)
> > /* Create an 1-to-1 iommu mapping for fqd and pfdr areas */
> > domain = iommu_get_domain_for_dev(dev);
> > if (domain) {
> > - ret = iommu_map(domain, fqd_a, fqd_a, fqd_sz,
> > + ret = iommu_map(domain, fqd_a, fqd_a,
> PAGE_ALIGN(fqd_sz),
> > IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > if (ret)
> > dev_warn(dev, "iommu_map(fqd) failed %d\n",
> ret);
> > - ret = iommu_map(domain, pfdr_a, pfdr_a, pfdr_sz,
> > + ret = iommu_map(domain, pfdr_a, pfdr_a,
> PAGE_ALIGN(pfdr_sz),
> > IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > if (ret)
> > dev_warn(dev, "iommu_map(pfdr) failed %d\n",
> ret);
> > diff --git a/drivers/soc/fsl/qbman/qman_portal.c
> b/drivers/soc/fsl/qbman/qman_portal.c
> > index dfb62f9815e9..bce56da2b01f 100644
> > --- a/drivers/soc/fsl/qbman/qman_portal.c
> > +++ b/drivers/soc/fsl/qbman/qman_portal.c
> > @@ -297,7 +297,7 @@ static int qman_portal_probe(struct platform_device
> *pdev)
> > */
> > err = iommu_map(domain,
> > addr_phys[0]->start, addr_phys[0]-
> >start,
> > - resource_size(addr_phys[0]),
> > + PAGE_ALIGN(resource_size(addr_phys[0])),
> > IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > if (err)
> > dev_warn(dev, "failed to iommu_map() %d\n",
> err);
> > --
> > 2.17.1
> >
[PATCH 12/13] dpaa_eth: fix iova handling for sg frames
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this also for scatter-gather frames
using the iova -> phys conversion function added in the previous patch.
While at it, clean-up a redundant dpaa_bpid2pool() and pass the bp
as parameter.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 41 +++
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index f17edc80dc37..daede7272768 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1646,14 +1646,17 @@ 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,
-qm_fd_get_offset(fd) + DPAA_SGT_SIZE,
-dma_dir);
/* The sgt buffer has been allocated with netdev_alloc_frag(),
* it's from lowmem.
*/
- sgt = phys_to_virt(addr + qm_fd_get_offset(fd));
+ sgt = phys_to_virt(dpaa_iova_to_phys(dev,
+addr +
+qm_fd_get_offset(fd)));
+
+ dma_unmap_single(dev, addr,
+qm_fd_get_offset(fd) + DPAA_SGT_SIZE,
+dma_dir);
/* sgt[0] is from lowmem, was dma_map_single()-ed */
dma_unmap_single(dev, qm_sg_addr(&sgt[0]),
@@ -1668,7 +1671,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
}
/* Free the page frag that we allocated on Tx */
- skb_free_frag(phys_to_virt(addr));
+ skb_free_frag(skbh);
} else {
dma_unmap_single(dev, addr,
skb_tail_pointer(skb) - (u8 *)skbh, dma_dir);
@@ -1729,14 +1732,14 @@ static struct sk_buff *contig_fd_to_skb(const struct
dpaa_priv *priv,
* The page fragment holding the S/G Table is recycled here.
*/
static struct sk_buff *sg_fd_to_skb(const struct dpaa_priv *priv,
- const struct qm_fd *fd)
+ const struct qm_fd *fd,
+ struct dpaa_bp *dpaa_bp,
+ void *vaddr)
{
ssize_t fd_off = qm_fd_get_offset(fd);
- dma_addr_t addr = qm_fd_addr(fd);
const struct qm_sg_entry *sgt;
struct page *page, *head_page;
- struct dpaa_bp *dpaa_bp;
- void *vaddr, *sg_vaddr;
+ void *sg_vaddr;
int frag_off, frag_len;
struct sk_buff *skb;
dma_addr_t sg_addr;
@@ -1745,7 +1748,6 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
int *count_ptr;
int i;
- vaddr = phys_to_virt(addr);
WARN_ON(!IS_ALIGNED((unsigned long)vaddr, SMP_CACHE_BYTES));
/* Iterate through the SGT entries and add data buffers to the skb */
@@ -1756,14 +1758,18 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
sg_addr = qm_sg_addr(&sgt[i]);
- sg_vaddr = phys_to_virt(sg_addr);
- WARN_ON(!IS_ALIGNED((unsigned long)sg_vaddr,
- SMP_CACHE_BYTES));
/* We may use multiple Rx pools */
dpaa_bp = dpaa_bpid2pool(sgt[i].bpid);
- if (!dpaa_bp)
+ if (!dpaa_bp) {
+ pr_info("%s: fail to get dpaa_bp for sg bpid %d\n",
+ __func__, sgt[i].bpid);
goto free_buffers;
+ }
+ sg_vaddr = phys_to_virt(dpaa_iova_to_phys(dpaa_bp->dev,
+ sg_addr));
+ WARN_ON(!IS_ALIGNED((unsigned long)sg_vaddr,
+ SMP_CACHE_BYTES));
count_ptr = this_cpu_ptr(dpaa_bp->percpu_count);
dma_unmap_single(dpaa_bp->dev, sg_addr, dpaa_bp->size,
@@ -1835,10 +1841,11 @@ static struct sk_buff *sg_fd_to_skb(const struct
dpaa_priv *priv,
/* free all the SG entries */
for (i = 0; i < DPAA_SGT_MAX_ENTRIES ; i++) {
sg_addr = qm_sg_addr(&sgt[i]);
- sg_vaddr = phys_to_virt(sg_addr);
- skb_free_frag(sg_vaddr);
dpaa_bp = dpaa_bpid2pool(sgt[i].bpid);
if (dpaa_bp
[PATCH 06/13] soc/fsl/qbman_portals: add APIs to retrieve the probing status
From: Laurentiu Tudor
Add a couple of new APIs to check the probing status of the required
cpu bound qman and bman portals:
'int bman_portals_probed()' and 'int qman_portals_probed()'.
They return the following values.
* 1 if qman/bman portals were all probed correctly
* 0 if qman/bman portals were not yet probed
* -1 if probing of qman/bman portals failed
Portals are considered successful probed if no error occurred during
the probing of any of the portals and if enough portals were probed
to have one available for each cpu.
The error handling paths were slightly rearranged in order to fit this
new functionality without being too intrusive.
Drivers that use qman/bman portal driver services are required to use
these APIs before calling any functions exported by these drivers or
otherwise they will crash the kernel.
First user will be the dpaa1 ethernet driver, coming in a subsequent
patch.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_portal.c | 22 ++
drivers/soc/fsl/qbman/qman_portal.c | 23 +++
include/soc/fsl/bman.h | 8
include/soc/fsl/qman.h | 9 +
4 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/fsl/qbman/bman_portal.c
b/drivers/soc/fsl/qbman/bman_portal.c
index 2c95cf59f3e7..7819bc29936d 100644
--- a/drivers/soc/fsl/qbman/bman_portal.c
+++ b/drivers/soc/fsl/qbman/bman_portal.c
@@ -32,6 +32,7 @@
static struct bman_portal *affine_bportals[NR_CPUS];
static struct cpumask portal_cpus;
+static int __bman_portals_probed;
/* protect bman global registers and global data shared among portals */
static DEFINE_SPINLOCK(bman_lock);
@@ -87,6 +88,12 @@ static int bman_online_cpu(unsigned int cpu)
return 0;
}
+int bman_portals_probed(void)
+{
+ return __bman_portals_probed;
+}
+EXPORT_SYMBOL_GPL(bman_portals_probed);
+
static int bman_portal_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -104,8 +111,10 @@ static int bman_portal_probe(struct platform_device *pdev)
}
pcfg = devm_kmalloc(dev, sizeof(*pcfg), GFP_KERNEL);
- if (!pcfg)
+ if (!pcfg) {
+ __bman_portals_probed = -1;
return -ENOMEM;
+ }
pcfg->dev = dev;
@@ -113,14 +122,14 @@ static int bman_portal_probe(struct platform_device *pdev)
DPAA_PORTAL_CE);
if (!addr_phys[0]) {
dev_err(dev, "Can't get %pOF property 'reg::CE'\n", node);
- return -ENXIO;
+ goto err_ioremap1;
}
addr_phys[1] = platform_get_resource(pdev, IORESOURCE_MEM,
DPAA_PORTAL_CI);
if (!addr_phys[1]) {
dev_err(dev, "Can't get %pOF property 'reg::CI'\n", node);
- return -ENXIO;
+ goto err_ioremap1;
}
pcfg->cpu = -1;
@@ -128,7 +137,7 @@ static int bman_portal_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq <= 0) {
dev_err(dev, "Can't get %pOF IRQ'\n", node);
- return -ENXIO;
+ goto err_ioremap1;
}
pcfg->irq = irq;
@@ -156,6 +165,9 @@ static int bman_portal_probe(struct platform_device *pdev)
}
cpumask_set_cpu(cpu, &portal_cpus);
+ if (!__bman_portals_probed &&
+ cpumask_weight(&portal_cpus) == num_online_cpus())
+ __bman_portals_probed = 1;
spin_unlock(&bman_lock);
pcfg->cpu = cpu;
@@ -175,6 +187,8 @@ static int bman_portal_probe(struct platform_device *pdev)
err_ioremap2:
memunmap(pcfg->addr_virt_ce);
err_ioremap1:
+__bman_portals_probed = -1;
+
return -ENXIO;
}
diff --git a/drivers/soc/fsl/qbman/qman_portal.c
b/drivers/soc/fsl/qbman/qman_portal.c
index bce56da2b01f..11ba6c77c0d6 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -39,6 +39,7 @@ EXPORT_SYMBOL(qman_dma_portal);
#define CONFIG_FSL_DPA_PIRQ_FAST 1
static struct cpumask portal_cpus;
+static int __qman_portals_probed;
/* protect qman global registers and global data shared among portals */
static DEFINE_SPINLOCK(qman_lock);
@@ -221,6 +222,12 @@ static int qman_online_cpu(unsigned int cpu)
return 0;
}
+int qman_portals_probed(void)
+{
+ return __qman_portals_probed;
+}
+EXPORT_SYMBOL_GPL(qman_portals_probed);
+
static int qman_portal_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -240,8 +247,10 @@ static int qman_portal_probe(struct platform_device *pdev)
}
pcfg = devm_kmalloc(dev, sizeof(*pcfg), GFP_KERNEL);
- if (!pcfg)
+ if (!pcfg) {
+ __qman_
[PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu
From: Laurentiu Tudor
Add a one-to-one iommu mapping for bman private data memory (FBPR).
This is required for BMAN to work without faults behind an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
b/drivers/soc/fsl/qbman/bman_ccsr.c
index 7c3cc968053c..b209c79511bb 100644
--- a/drivers/soc/fsl/qbman/bman_ccsr.c
+++ b/drivers/soc/fsl/qbman/bman_ccsr.c
@@ -29,6 +29,7 @@
*/
#include "bman_priv.h"
+#include
u16 bman_ip_rev;
EXPORT_SYMBOL(bman_ip_rev);
@@ -178,6 +179,7 @@ static int fsl_bman_probe(struct platform_device *pdev)
int ret, err_irq;
struct device *dev = &pdev->dev;
struct device_node *node = dev->of_node;
+ struct iommu_domain *domain;
struct resource *res;
u16 id, bm_pool_cnt;
u8 major, minor;
@@ -225,6 +227,15 @@ static int fsl_bman_probe(struct platform_device *pdev)
dev_dbg(dev, "Allocated FBPR 0x%llx 0x%zx\n", fbpr_a, fbpr_sz);
+ /* Create an 1-to-1 iommu mapping for FBPR area */
+ domain = iommu_get_domain_for_dev(dev);
+ if (domain) {
+ ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
+ IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
+ if (ret)
+ dev_warn(dev, "failed to iommu_map() %d\n", ret);
+ }
+
bm_set_memory(fbpr_a, fbpr_sz);
err_irq = platform_get_irq(pdev, 0);
--
2.17.1
[PATCH 01/13] 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 109b38de3176..12e414ca3b03 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -598,6 +598,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;
@@ -617,6 +618,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
[PATCH 03/13] soc/fsl/qman: map FQD and PFDR areas in the iommu
From: Laurentiu Tudor
Add a one-to-one iommu mapping for qman private data memory areas
(FQD and PFDR). This is required for QMAN to work without faults
behind an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/qman_ccsr.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
b/drivers/soc/fsl/qbman/qman_ccsr.c
index 12e414ca3b03..eec7700507e1 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -29,6 +29,7 @@
*/
#include "qman_priv.h"
+#include
u16 qman_ip_rev;
EXPORT_SYMBOL(qman_ip_rev);
@@ -699,6 +700,7 @@ static int fsl_qman_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *node = dev->of_node;
+ struct iommu_domain *domain;
struct resource *res;
int ret, err_irq;
u16 id;
@@ -778,6 +780,19 @@ static int fsl_qman_probe(struct platform_device *pdev)
}
dev_dbg(dev, "Allocated PFDR 0x%llx 0x%zx\n", pfdr_a, pfdr_sz);
+ /* Create an 1-to-1 iommu mapping for fqd and pfdr areas */
+ domain = iommu_get_domain_for_dev(dev);
+ if (domain) {
+ ret = iommu_map(domain, fqd_a, fqd_a, fqd_sz,
+ IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
+ if (ret)
+ dev_warn(dev, "iommu_map(fqd) failed %d\n", ret);
+ ret = iommu_map(domain, pfdr_a, pfdr_a, pfdr_sz,
+ IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
+ if (ret)
+ dev_warn(dev, "iommu_map(pfdr) failed %d\n", ret);
+ }
+
ret = qman_init_ccsr(dev);
if (ret) {
dev_err(dev, "CCSR setup failed\n");
--
2.17.1
[PATCH 09/13] dpaa_eth: defer probing after qbman
From: Laurentiu Tudor
Enabling SMMU altered the order of device probing causing the dpaa1
ethernet driver to get probed before qbman and causing a boot crash.
Add predictability in the probing order by deferring the ethernet
driver probe after qbman and portals by using the recently introduced
qbman APIs.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index dfebc30c4841..647e90e7434f 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2774,6 +2774,37 @@ static int dpaa_eth_probe(struct platform_device *pdev)
int err = 0, i, channel;
struct device *dev;
+ err = bman_is_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev, "failing probe due to bman probe error\n");
+ return -ENODEV;
+ }
+ err = qman_is_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev, "failing probe due to qman probe error\n");
+ return -ENODEV;
+ }
+ err = bman_portals_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev,
+ "failing probe due to bman portals probe error\n");
+ return -ENODEV;
+ }
+ err = qman_portals_probed();
+ if (!err)
+ return -EPROBE_DEFER;
+ if (err < 0) {
+ dev_err(&pdev->dev,
+ "failing probe due to qman portals probe error\n");
+ return -ENODEV;
+ }
+
/* device used for DMA mapping */
dev = pdev->dev.parent;
err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
--
2.17.1
[PATCH 05/13] soc/fsl/bqman: page align iommu mapping sizes
From: Laurentiu Tudor
Prior to calling iommu_map()/iommu_unmap() page align the size or
failures such as below could happen:
iommu: unaligned: iova 0x... pa 0x... size 0x4000 min_pagesz 0x1
qman_portal 5.qman-portal: failed to iommu_map() -22
Seen when booted a kernel compiled with 64K page size support.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_ccsr.c | 2 +-
drivers/soc/fsl/qbman/qman_ccsr.c | 4 ++--
drivers/soc/fsl/qbman/qman_portal.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
b/drivers/soc/fsl/qbman/bman_ccsr.c
index b209c79511bb..3a6e01bde32d 100644
--- a/drivers/soc/fsl/qbman/bman_ccsr.c
+++ b/drivers/soc/fsl/qbman/bman_ccsr.c
@@ -230,7 +230,7 @@ static int fsl_bman_probe(struct platform_device *pdev)
/* Create an 1-to-1 iommu mapping for FBPR area */
domain = iommu_get_domain_for_dev(dev);
if (domain) {
- ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
+ ret = iommu_map(domain, fbpr_a, fbpr_a, PAGE_ALIGN(fbpr_sz),
IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
if (ret)
dev_warn(dev, "failed to iommu_map() %d\n", ret);
diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
b/drivers/soc/fsl/qbman/qman_ccsr.c
index eec7700507e1..8d3c950ce52d 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -783,11 +783,11 @@ static int fsl_qman_probe(struct platform_device *pdev)
/* Create an 1-to-1 iommu mapping for fqd and pfdr areas */
domain = iommu_get_domain_for_dev(dev);
if (domain) {
- ret = iommu_map(domain, fqd_a, fqd_a, fqd_sz,
+ ret = iommu_map(domain, fqd_a, fqd_a, PAGE_ALIGN(fqd_sz),
IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
if (ret)
dev_warn(dev, "iommu_map(fqd) failed %d\n", ret);
- ret = iommu_map(domain, pfdr_a, pfdr_a, pfdr_sz,
+ ret = iommu_map(domain, pfdr_a, pfdr_a, PAGE_ALIGN(pfdr_sz),
IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
if (ret)
dev_warn(dev, "iommu_map(pfdr) failed %d\n", ret);
diff --git a/drivers/soc/fsl/qbman/qman_portal.c
b/drivers/soc/fsl/qbman/qman_portal.c
index dfb62f9815e9..bce56da2b01f 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -297,7 +297,7 @@ static int qman_portal_probe(struct platform_device *pdev)
*/
err = iommu_map(domain,
addr_phys[0]->start, addr_phys[0]->start,
- resource_size(addr_phys[0]),
+ PAGE_ALIGN(resource_size(addr_phys[0])),
IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
if (err)
dev_warn(dev, "failed to iommu_map() %d\n", err);
--
2.17.1
[PATCH 08/13] fsl/fman: add API to get the device behind a fman port
From: Laurentiu Tudor
Add an API that retrieves the 'struct device' that the specified fman
port probed against. The new API will be used in a subsequent iommu
enablement related patch.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/fman/fman_port.c | 14 ++
drivers/net/ethernet/freescale/fman/fman_port.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c
b/drivers/net/ethernet/freescale/fman/fman_port.c
index ee82ee1384eb..bd76c9730692 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.c
+++ b/drivers/net/ethernet/freescale/fman/fman_port.c
@@ -1728,6 +1728,20 @@ u32 fman_port_get_qman_channel_id(struct fman_port *port)
}
EXPORT_SYMBOL(fman_port_get_qman_channel_id);
+/**
+ * fman_port_get_device
+ * port: Pointer to the FMan port device
+ *
+ * Get the 'struct device' associated to the specified FMan port device
+ *
+ * Return: pointer to associated 'struct device'
+ */
+struct device *fman_port_get_device(struct fman_port *port)
+{
+ return port->dev;
+}
+EXPORT_SYMBOL(fman_port_get_device);
+
int fman_port_get_hash_result_offset(struct fman_port *port, u32 *offset)
{
if (port->buffer_offsets.hash_result_offset == ILLEGAL_BASE)
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.h
b/drivers/net/ethernet/freescale/fman/fman_port.h
index 9dbb69f40121..82f12661a46d 100644
--- a/drivers/net/ethernet/freescale/fman/fman_port.h
+++ b/drivers/net/ethernet/freescale/fman/fman_port.h
@@ -157,4 +157,6 @@ int fman_port_get_tstamp(struct fman_port *port, const void
*data, u64 *tstamp);
struct fman_port *fman_port_bind(struct device *dev);
+struct device *fman_port_get_device(struct fman_port *port);
+
#endif /* __FMAN_PORT_H */
--
2.17.1
[PATCH 07/13] fsl/fman: backup and restore ICID registers
From: Laurentiu Tudor
During probing, FMAN is reset thus losing all its register
settings. Backup port ICID registers before reset and restore
them after, similarly to how it's done on powerpc / PAMU based
platforms.
This also has the side effect of disabling the old code path
(liodn backup/restore handling) that obviously make no sense
in the context of SMMU on ARMs.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/fman/fman.c | 35 +-
drivers/net/ethernet/freescale/fman/fman.h | 4 +++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c
b/drivers/net/ethernet/freescale/fman/fman.c
index e80fedb27cee..ae833e215b74 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -629,6 +629,7 @@ static void set_port_order_restoration(struct fman_fpm_regs
__iomem *fpm_rg,
iowrite32be(tmp, &fpm_rg->fmfp_prc);
}
+#ifdef CONFIG_PPC
static void set_port_liodn(struct fman *fman, u8 port_id,
u32 liodn_base, u32 liodn_ofst)
{
@@ -646,6 +647,27 @@ static void set_port_liodn(struct fman *fman, u8 port_id,
iowrite32be(tmp, &fman->dma_regs->fmdmplr[port_id / 2]);
iowrite32be(liodn_ofst, &fman->bmi_regs->fmbm_spliodn[port_id - 1]);
}
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+static void save_restore_port_icids(struct fman *fman, bool save)
+{
+ int port_idxes[] = {
+ 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc,
+ 0xd, 0xe, 0xf, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
+ 0x10, 0x11, 0x30, 0x31
+ };
+ int idx, i;
+
+ for (i = 0; i < ARRAY_SIZE(port_idxes); i++) {
+ idx = port_idxes[i];
+ if (save)
+ fman->sp_icids[idx] =
+ ioread32be(&fman->bmi_regs->fmbm_spliodn[idx]);
+ else
+ iowrite32be(fman->sp_icids[idx],
+ &fman->bmi_regs->fmbm_spliodn[idx]);
+ }
+}
+#endif
static void enable_rams_ecc(struct fman_fpm_regs __iomem *fpm_rg)
{
@@ -1914,7 +1936,10 @@ static int fman_reset(struct fman *fman)
static int fman_init(struct fman *fman)
{
struct fman_cfg *cfg = NULL;
- int err = 0, i, count;
+ int err = 0, count;
+#ifdef CONFIG_PPC
+ int i;
+#endif
if (is_init_done(fman->cfg))
return -EINVAL;
@@ -1934,6 +1959,7 @@ static int fman_init(struct fman *fman)
memset_io((void __iomem *)(fman->base_addr + CGP_OFFSET), 0,
fman->state->fm_port_num_of_cg);
+#ifdef CONFIG_PPC
/* Save LIODN info before FMan reset
* Skipping non-existent port 0 (i = 1)
*/
@@ -1953,6 +1979,9 @@ static int fman_init(struct fman *fman)
}
fman->liodn_base[i] = liodn_base;
}
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+ save_restore_port_icids(fman, true);
+#endif
err = fman_reset(fman);
if (err)
@@ -2181,8 +2210,12 @@ int fman_set_port_params(struct fman *fman,
if (err)
goto return_err;
+#ifdef CONFIG_PPC
set_port_liodn(fman, port_id, fman->liodn_base[port_id],
fman->liodn_offset[port_id]);
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+ save_restore_port_icids(fman, false);
+#endif
if (fman->state->rev_info.major < 6)
set_port_order_restoration(fman->fpm_regs, port_id);
diff --git a/drivers/net/ethernet/freescale/fman/fman.h
b/drivers/net/ethernet/freescale/fman/fman.h
index 935c317fa696..19f20fa58053 100644
--- a/drivers/net/ethernet/freescale/fman/fman.h
+++ b/drivers/net/ethernet/freescale/fman/fman.h
@@ -346,8 +346,12 @@ struct fman {
unsigned long fifo_offset;
size_t fifo_size;
+#ifdef CONFIG_PPC
u32 liodn_base[64];
u32 liodn_offset[64];
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+ u32 sp_icids[64];
+#endif
struct fman_dts_params dts_params;
};
--
2.17.1
[PATCH 10/13] dpaa_eth: base dma mappings on the fman rx port
From: Laurentiu Tudor
The dma transactions initiator is the rx fman port so that's the device
that the dma mappings should be done. Previously the mappings were done
through the MAC device which makes no sense because it's neither dma-able
nor connected in any way to smmu.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 647e90e7434f..cdc7e6d83f77 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2805,8 +2805,15 @@ static int dpaa_eth_probe(struct platform_device *pdev)
return -ENODEV;
}
+ mac_dev = dpaa_mac_dev_get(pdev);
+ if (IS_ERR(mac_dev)) {
+ dev_err(&pdev->dev, "dpaa_mac_dev_get() failed\n");
+ err = PTR_ERR(mac_dev);
+ goto probe_err;
+ }
+
/* device used for DMA mapping */
- dev = pdev->dev.parent;
+ dev = fman_port_get_device(mac_dev->port[RX]);
err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
if (err) {
dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
@@ -2831,13 +2838,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
priv->msg_enable = netif_msg_init(debug, DPAA_MSG_DEFAULT);
- mac_dev = dpaa_mac_dev_get(pdev);
- if (IS_ERR(mac_dev)) {
- dev_err(dev, "dpaa_mac_dev_get() failed\n");
- err = PTR_ERR(mac_dev);
- goto free_netdev;
- }
-
/* If fsl_fm_max_frm is set to a higher value than the all-common 1500,
* we choose conservatively and let the user explicitly set a higher
* MTU via ifconfig. Otherwise, the user may end up with different MTUs
@@ -2973,9 +2973,9 @@ static int dpaa_eth_probe(struct platform_device *pdev)
qman_release_cgrid(priv->cgr_data.cgr.cgrid);
free_dpaa_bps:
dpaa_bps_free(priv);
-free_netdev:
dev_set_drvdata(dev, NULL);
free_netdev(net_dev);
+probe_err:
return err;
}
--
2.17.1
[PATCH 00/13] Prerequisites for NXP LS104xA SMMU enablement
From: Laurentiu Tudor This patch series contains several fixes in preparation for SMMU support on NXP LS1043A and LS1046A chips. Once these get picked up, I'll submit the actual SMMU enablement patches consisting in the required device tree changes. This patch series contains only part of the previously submitted one, (including also the device tree changes) available here: https://patchwork.kernel.org/cover/10634443/ There are a couple of changes/fixes since then: - for consistency, renamed mmu node to smmu - new patch page aligning the sizes of the qbman reserved memory - rebased on 5.1.0-rc2 Laurentiu Tudor (13): soc/fsl/qman: fixup liodns only on ppc targets soc/fsl/bman: map FBPR area in the iommu soc/fsl/qman: map FQD and PFDR areas in the iommu soc/fsl/qman-portal: map CENA area in the iommu soc/fsl/bqman: page align iommu mapping sizes soc/fsl/qbman_portals: add APIs to retrieve the probing status fsl/fman: backup and restore ICID registers fsl/fman: add API to get the device behind a fman port dpaa_eth: defer probing after qbman dpaa_eth: base dma mappings on the fman rx port dpaa_eth: fix iova handling for contiguous frames dpaa_eth: fix iova handling for sg frames dpaa_eth: fix SG frame cleanup .../net/ethernet/freescale/dpaa/dpaa_eth.c| 136 -- drivers/net/ethernet/freescale/fman/fman.c| 35 - drivers/net/ethernet/freescale/fman/fman.h| 4 + .../net/ethernet/freescale/fman/fman_port.c | 14 ++ .../net/ethernet/freescale/fman/fman_port.h | 2 + drivers/soc/fsl/qbman/bman_ccsr.c | 11 ++ drivers/soc/fsl/qbman/bman_portal.c | 22 ++- drivers/soc/fsl/qbman/qman_ccsr.c | 17 +++ drivers/soc/fsl/qbman/qman_portal.c | 40 +- include/soc/fsl/bman.h| 8 ++ include/soc/fsl/qman.h| 9 ++ 11 files changed, 242 insertions(+), 56 deletions(-) -- 2.17.1
[PATCH 13/13] dpaa_eth: fix SG frame cleanup
From: Laurentiu Tudor
Fix issue with the entry indexing in the sg frame cleanup code being
off-by-1. This problem showed up when doing some basic iperf tests and
manifested in traffic coming to a halt.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index daede7272768..40420edc9ce6 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -1663,7 +1663,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
qm_sg_entry_get_len(&sgt[0]), dma_dir);
/* remaining pages were mapped with skb_frag_dma_map() */
- for (i = 1; i < nr_frags; i++) {
+ for (i = 1; i <= nr_frags; i++) {
WARN_ON(qm_sg_entry_is_ext(&sgt[i]));
dma_unmap_page(dev, qm_sg_addr(&sgt[i]),
--
2.17.1
[PATCH 11/13] dpaa_eth: fix iova handling for contiguous frames
From: Laurentiu Tudor
The driver relies on the no longer valid assumption that dma addresses
(iovas) are identical to physical addressees and uses phys_to_virt() to
make iova -> vaddr conversions. Fix this by adding a function that does
proper iova -> phys conversions using the iommu api and update the code
to use it.
Also, a dma_unmap_single() call had to be moved further down the code
because iova -> vaddr conversions were required before the unmap.
For now only the contiguous frame case is handled and the SG case is
split in a following patch.
While at it, clean-up a redundant dpaa_bpid2pool() and pass the bp
as parameter.
Signed-off-by: Laurentiu Tudor
Acked-by: Madalin Bucur
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 44 ++-
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index cdc7e6d83f77..f17edc80dc37 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1595,6 +1596,17 @@ static int dpaa_eth_refill_bpools(struct dpaa_priv *priv)
return 0;
}
+static phys_addr_t dpaa_iova_to_phys(struct device *dev, dma_addr_t addr)
+{
+ struct iommu_domain *domain;
+
+ domain = iommu_get_domain_for_dev(dev);
+ if (domain)
+ return iommu_iova_to_phys(domain, addr);
+ else
+ return addr;
+}
+
/* Cleanup function for outgoing frame descriptors that were built on Tx path,
* either contiguous frames or scatter/gather ones.
* Skb freeing is not handled here.
@@ -1617,7 +1629,7 @@ static struct sk_buff *dpaa_cleanup_tx_fd(const struct
dpaa_priv *priv,
int nr_frags, i;
u64 ns;
- skbh = (struct sk_buff **)phys_to_virt(addr);
+ skbh = (struct sk_buff **)phys_to_virt(dpaa_iova_to_phys(dev, addr));
skb = *skbh;
if (priv->tx_tstamp && skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
@@ -1687,25 +1699,21 @@ static u8 rx_csum_offload(const struct dpaa_priv *priv,
const struct qm_fd *fd)
* accommodate the shared info area of the skb.
*/
static struct sk_buff *contig_fd_to_skb(const struct dpaa_priv *priv,
- const struct qm_fd *fd)
+ const struct qm_fd *fd,
+ struct dpaa_bp *dpaa_bp,
+ void *vaddr)
{
ssize_t fd_off = qm_fd_get_offset(fd);
- dma_addr_t addr = qm_fd_addr(fd);
- struct dpaa_bp *dpaa_bp;
struct sk_buff *skb;
- void *vaddr;
- vaddr = phys_to_virt(addr);
WARN_ON(!IS_ALIGNED((unsigned long)vaddr, SMP_CACHE_BYTES));
- dpaa_bp = dpaa_bpid2pool(fd->bpid);
- if (!dpaa_bp)
- goto free_buffer;
-
skb = build_skb(vaddr, dpaa_bp->size +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
- if (WARN_ONCE(!skb, "Build skb failure on Rx\n"))
- goto free_buffer;
+ if (WARN_ONCE(!skb, "Build skb failure on Rx\n")) {
+ skb_free_frag(vaddr);
+ return NULL;
+ }
WARN_ON(fd_off != priv->rx_headroom);
skb_reserve(skb, fd_off);
skb_put(skb, qm_fd_get_length(fd));
@@ -1713,10 +1721,6 @@ static struct sk_buff *contig_fd_to_skb(const struct
dpaa_priv *priv,
skb->ip_summed = rx_csum_offload(priv, fd);
return skb;
-
-free_buffer:
- skb_free_frag(vaddr);
- return NULL;
}
/* Build an skb with the data of the first S/G entry in the linear portion and
@@ -2309,12 +2313,12 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct
qman_portal *portal,
if (!dpaa_bp)
return qman_cb_dqrr_consume;
- dma_unmap_single(dpaa_bp->dev, addr, dpaa_bp->size, DMA_FROM_DEVICE);
-
/* prefetch the first 64 bytes of the frame or the SGT start */
- vaddr = phys_to_virt(addr);
+ vaddr = phys_to_virt(dpaa_iova_to_phys(dpaa_bp->dev, addr));
prefetch(vaddr + qm_fd_get_offset(fd));
+ dma_unmap_single(dpaa_bp->dev, addr, dpaa_bp->size, DMA_FROM_DEVICE);
+
/* The only FD types that we may receive are contig and S/G */
WARN_ON((fd_format != qm_fd_contig) && (fd_format != qm_fd_sg));
@@ -2325,7 +2329,7 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct
qman_portal *portal,
(*count_ptr)--;
if (likely(fd_format == qm_fd_contig))
- skb = contig_fd_to_skb(priv, fd);
+ skb = contig_fd_to_skb(priv, fd, dpaa_bp, vaddr);
else
skb = sg_fd_to_skb(priv, fd);
if (!skb)
--
2.17.1
[PATCH 04/13] soc/fsl/qman-portal: map CENA area in the iommu
From: Laurentiu Tudor
Add a one-to-one iommu mapping for qman portal CENA register area.
This is required for QMAN stashing to work without faults behind
an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/qman_portal.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman_portal.c
b/drivers/soc/fsl/qbman/qman_portal.c
index 661c9b234d32..dfb62f9815e9 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -29,6 +29,7 @@
*/
#include "qman_priv.h"
+#include
struct qman_portal *qman_dma_portal;
EXPORT_SYMBOL(qman_dma_portal);
@@ -224,6 +225,7 @@ static int qman_portal_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *node = dev->of_node;
+ struct iommu_domain *domain;
struct qm_portal_config *pcfg;
struct resource *addr_phys[2];
int irq, cpu, err;
@@ -286,6 +288,21 @@ static int qman_portal_probe(struct platform_device *pdev)
goto err_ioremap2;
}
+ /* Create an 1-to-1 iommu mapping for cena portal area */
+ domain = iommu_get_domain_for_dev(dev);
+ if (domain) {
+ /*
+* Note: not mapping this as cacheable triggers the infamous
+* QMan CIDE error.
+*/
+ err = iommu_map(domain,
+ addr_phys[0]->start, addr_phys[0]->start,
+ resource_size(addr_phys[0]),
+ IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
+ if (err)
+ dev_warn(dev, "failed to iommu_map() %d\n", err);
+ }
+
pcfg->pools = qm_get_pools_sdqcr();
spin_lock(&qman_lock);
--
2.17.1
RE: FSL/NXP P5020: USB problems with the latest Git kernels
Hi Scott, > -Original Message- > On Mon, 2018-08-27 at 20:15 +0200, Christian Zigotzky wrote: > > Hello, > > > > Our users tested the RC1 of kernel 4.19 on their P5020 boards today. > > Unfortunately the USB bug still exists. With mem values bigger than > 4096M, > > the USB mouse and keyboard doesn’t work. With the bootarg mem=4096M, the > USB > > devices work without any problems. Please compile the RC1 and test it on > > your P5020 board. There is a problem with the memory management since > > 22/08/18. > > I just tested 4.19-rc1 on a T4240 and got a similar problem with MMC. MMC > and > USB on these chips both have a 32-bit DMA limitation. I'll look into it. I encountered similar issues on LS104xA chips. This is the workaround for MMC: https://patchwork.kernel.org/patch/10506627/ On the USB side I didn't find a proper place in the usb subsystem code for a workaround but instead found an undocumented kernel arg (*) that limits the dma mask to 32 bits: xhci-hcd.quirks=0x80. (*) https://patchwork.kernel.org/patch/10509159/ --- Best Regards, Laurentiu
Re: [PATCH 6/7 v5] bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus
On 05/20/2018 04:49 PM, Nipun Gupta wrote: > of_dma_configure() API expects coherent_dma_mask to be correctly > set in the devices. This patch does the needful. > > Signed-off-by: Nipun Gupta Acked-by: Laurentiu Tudor --- Best Regards, Laurentiu > --- > drivers/bus/fsl-mc/fsl-mc-bus.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c > index fa43c7d..624828b 100644 > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c > @@ -627,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc, > mc_dev->icid = parent_mc_dev->icid; > mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK; > mc_dev->dev.dma_mask = &mc_dev->dma_mask; > + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask; > dev_set_msi_domain(&mc_dev->dev, > dev_get_msi_domain(&parent_mc_dev->dev)); > } >
Re: [PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
Hi Nipun,
On 04/27/2018 01:27 PM, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta
> ---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 5d8266c..624828b 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct
> kobj_uevent_env *env)
> return 0;
> }
>
> +static int fsl_mc_dma_configure(struct device *dev)
> +{
> + struct device *dma_dev = dev;
> +
> + while (dev_is_fsl_mc(dma_dev))
> + dma_dev = dma_dev->parent;
> +
> + return of_dma_configure(dev, dma_dev->of_node, 0);
> +}
> +
> static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr,
>char *buf)
> {
> @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> .name = "fsl-mc",
> .match = fsl_mc_bus_match,
> .uevent = fsl_mc_bus_uevent,
> + .dma_configure = fsl_mc_dma_configure,
> .dev_groups = fsl_mc_dev_groups,
> };
> EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> mc_dev->icid = parent_mc_dev->icid;
> mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
> mc_dev->dev.dma_mask = &mc_dev->dma_mask;
> + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
This change seems a bit unrelated to the patch subject. I wonder if it
makes sense to split it it in a distinct patch.
---
Best Regards, Laurentiu
Re: [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
Hi Nipun,
On 04/30/2018 09:27 AM, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta
> ---
If my understanding is correct, the kbuild error is triggered by this
missing dependency patch:
https://patchwork.kernel.org/patch/10370081/
Apart from that, patch looks good to me, so
Reviewed-by: Laurentiu Tudor
---
Best Regards, Laurentiu
> drivers/bus/fsl-mc/fsl-mc-bus.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 5d8266c..624828b 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct
> kobj_uevent_env *env)
> return 0;
> }
>
> +static int fsl_mc_dma_configure(struct device *dev)
> +{
> + struct device *dma_dev = dev;
> +
> + while (dev_is_fsl_mc(dma_dev))
> + dma_dev = dma_dev->parent;
> +
> + return of_dma_configure(dev, dma_dev->of_node, 0);
> +}
> +
> static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr,
>char *buf)
> {
> @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> .name = "fsl-mc",
> .match = fsl_mc_bus_match,
> .uevent = fsl_mc_bus_uevent,
> + .dma_configure = fsl_mc_dma_configure,
> .dev_groups = fsl_mc_dev_groups,
> };
> EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> mc_dev->icid = parent_mc_dev->icid;
> mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
> mc_dev->dev.dma_mask = &mc_dev->dma_mask;
> + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
> dev_set_msi_domain(&mc_dev->dev,
> dev_get_msi_domain(&parent_mc_dev->dev));
> }
> @@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> goto error_cleanup_dev;
> }
>
> - /* Objects are coherent, unless 'no shareability' flag set. */
> - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> -
> /*
>* The device-specific probe callback will get invoked by device_add()
>*/
>
Re: [PATCH v4 6/6] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc
Hi Nipun,
On 04/30/2018 09:27 AM, Nipun Gupta wrote:
> fsl-mc bus support the new iommu-map property. Comply to this binding
> for fsl_mc bus.
>
> Signed-off-by: Nipun Gupta
This looks good to me, so:
Reviewed-By: Laurentiu Tudor
---
Best Regards, Laurentiu
> ---
> arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> index 137ef4d..6010505 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> @@ -184,6 +184,7 @@
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> + dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
>
> clockgen: clocking@130 {
> compatible = "fsl,ls2080a-clockgen";
> @@ -357,6 +358,8 @@
> reg = <0x0008 0x0c00 0 0x40>,/* MC portal
> base */
> <0x 0x0834 0 0x4>; /* MC control
> reg */
> msi-parent = <&its>;
> + iommu-map = <0 &smmu 0 0>; /* This is fixed-up by
> u-boot */
> + dma-coherent;
> #address-cells = <3>;
> #size-cells = <1>;
>
> @@ -460,6 +463,8 @@
> compatible = "arm,mmu-500";
> reg = <0 0x500 0 0x80>;
> #global-interrupts = <12>;
> + #iommu-cells = <1>;
> + stream-match-mask = <0x7C00>;
> interrupts = <0 13 4>, /* global secure fault */
><0 14 4>, /* combined secure interrupt */
><0 15 4>, /* global non-secure fault */
> @@ -502,7 +507,6 @@
><0 204 4>, <0 205 4>,
><0 206 4>, <0 207 4>,
><0 208 4>, <0 209 4>;
> - mmu-masters = <&fsl_mc 0x300 0>;
> };
>
> dspi: dspi@210 {
>
Re: [PATCH] powerpc/kvm/booke: fix altivec related build break
Hi Michael,
On 04/27/2018 09:14 AM, Michael Ellerman wrote:
> laurentiu.tu...@nxp.com writes:
>> From: Laurentiu Tudor
>>
>> Add missing "altivec unavailable" interrupt injection helper
>> thus fixing the linker error below:
>>
>> arch/powerpc/kvm/emulate_loadstore.o: In function
>> `kvmppc_check_altivec_disabled':
>> arch/powerpc/kvm/emulate_loadstore.c: undefined reference to
>> `.kvmppc_core_queue_vec_unavail'
>>
>> Fixes: 09f984961c137c4b ("KVM: PPC: Book3S: Add MMIO emulation for VMX
>> instructions")
>
> What config are you using to hit this? I'd like to add it to my
> auto-builder to catch it in future.
>
Start with the corenet64_smp_defconfig and enable CONFIG_KVM_E500MC
option found in "Virtualization -> KVM support for PowerPC
E500MC/E5500/E6500 processors".
P.S. Sorry for the late reply. I took advantage of labor day and
arranged a mini-vacation. :-)
---
Best Regards, Laurentiu
[PATCH] powerpc/kvm/booke: fix altivec related build break
From: Laurentiu Tudor
Add missing "altivec unavailable" interrupt injection helper
thus fixing the linker error below:
arch/powerpc/kvm/emulate_loadstore.o: In function
`kvmppc_check_altivec_disabled':
arch/powerpc/kvm/emulate_loadstore.c: undefined reference to
`.kvmppc_core_queue_vec_unavail'
Fixes: 09f984961c137c4b ("KVM: PPC: Book3S: Add MMIO emulation for VMX
instructions")
Signed-off-by: Laurentiu Tudor
---
arch/powerpc/kvm/booke.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 6038e2e7aee0..876d4f294fdd 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -305,6 +305,13 @@ void kvmppc_core_queue_fpunavail(struct kvm_vcpu *vcpu)
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_FP_UNAVAIL);
}
+#ifdef CONFIG_ALTIVEC
+void kvmppc_core_queue_vec_unavail(struct kvm_vcpu *vcpu)
+{
+ kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_ALTIVEC_UNAVAIL);
+}
+#endif
+
void kvmppc_core_queue_dec(struct kvm_vcpu *vcpu)
{
kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DECREMENTER);
--
2.17.0
Re: Machine Check in P2010(e500v2)
Hi Jocke, On 09/01/2017 02:32 PM, Joakim Tjernlund wrote: > I am trying to debug a Machine Check for a P2010 (e500v2) CPU: > > [ 28.111816] Caused by (from MCSR=10008): Bus - Read Data Bus Error > [ 28.117998] Oops: Machine check, sig: 7 [#1] > [ 28.122263] P1010 RDB > [ 28.124529] Modules linked in: linux_bcm_knet(PO) linux_user_bde(PO) > linux_kernel_bde(PO) > [ 28.132718] CPU: 0 PID: 470 Comm: emxp2_hw_bl Tainted: P O > 4.1.38+ #49 > [ 28.140376] task: db16cd10 ti: df128000 task.ti: df128000 > [ 28.145770] NIP: LR: 10a4e404 CTR: 10046c38 > [ 28.150730] REGS: df129f10 TRAP: 0204 Tainted: P O > (4.1.38+) > [ 28.157776] MSR: 0002d000 CR: 44002428 XER: > [ 28.164140] DEAR: b7187000 ESR: > GPR00: 10a4e404 bf86ea30 b7ca94a0 132f9fa8 07006000 0700 132f9fd8 > GPR08: b7149000 b7159000 0003e000 bf86ea20 24004424 11d6cf7c > GPR16: 10f6e29c 10f6c872 10f6db01 b541 b541 11d92fcc 0011 0001 > GPR24: 01a4d12d 132ffbf0 11d6 07006000 132f9fa8 > [ 28.196375] NIP [] (null) > [ 28.199859] LR [10a4e404] 0x10a4e404 > [ 28.203426] Call Trace: > [ 28.205866] ---[ end trace f456255ddf9bee83 ]--- > > I cannot figure out why NIP is NULL ? It LOOKs like NIP is set to > MCSRR0 early on but maybe it is lost somehow? > > Anyhow, looking at entry_32.S: > .globl mcheck_transfer_to_handler > mcheck_transfer_to_handler: > mfspr r0,SPRN_DSRR0 > stw r0,_DSRR0(r11) > mfspr r0,SPRN_DSRR1 > stw r0,_DSRR1(r11) > /* fall through */ > > .globl debug_transfer_to_handler > debug_transfer_to_handler: > mfspr r0,SPRN_CSRR0 > stw r0,_CSRR0(r11) > mfspr r0,SPRN_CSRR1 > stw r0,_CSRR1(r11) > /* fall through */ > > .globl crit_transfer_to_handler > crit_transfer_to_handler: > > It looks odd that DSRRx is assigned in mcheck and CSRRx in debug and > crit has none. Should not this assigment be shifted down one level? > This does indeed looks weird. Have you tried moving the SPRN_CSRR* saving in the crit section? Any results? --- Best Regards, Laurentiu
Re: mpic IRQ_TYPE_BOTH handling
On 08/31/2017 01:52 AM, Michael Ellerman wrote:
> Hi Gregory,
>
> Gregory Fong writes:
>> Hi all,
>>
>> In arch/powerpc/sysdev/mpic.c , it looks like IRQ_TYPE_EDGE_BOTH is
>> handled the same way as IRQ_TYPE_EDGE_FALLING:
>>
>> static unsigned int mpic_type_to_vecpri(struct mpic *mpic, unsigned int type)
>> {
>> /* Now convert sense value */
>> switch(type & IRQ_TYPE_SENSE_MASK) {
>> case IRQ_TYPE_EDGE_RISING:
>> return MPIC_INFO(VECPRI_SENSE_EDGE) |
>> MPIC_INFO(VECPRI_POLARITY_POSITIVE);
>> case IRQ_TYPE_EDGE_FALLING:
>> case IRQ_TYPE_EDGE_BOTH:
>> return MPIC_INFO(VECPRI_SENSE_EDGE) |
>> MPIC_INFO(VECPRI_POLARITY_NEGATIVE);
>> case IRQ_TYPE_LEVEL_HIGH:
>> return MPIC_INFO(VECPRI_SENSE_LEVEL) |
>> MPIC_INFO(VECPRI_POLARITY_POSITIVE);
>> case IRQ_TYPE_LEVEL_LOW:
>> default:
>> return MPIC_INFO(VECPRI_SENSE_LEVEL) |
>> MPIC_INFO(VECPRI_POLARITY_NEGATIVE);
>> }
>> }
>>
>> If IRQ_TYPE_EDGE_BOTH is unsupported, shouldn't we be returning an
>> error, instead of silently setting to use IRQ_TYPE_EDGE_FALLING?
>> Something like the following (sorry if the diff wraps weirdly, on
>> webmail at the moment):
>
> I don't know this code so I asked Ben and he said something like
> "PowerMacs never use BOTH, so it hasn't mattered, but Freescale machines
> might".
IIRC, the mpic in freescale MPICs the interrupts are either low or high,
so not both. There's a bit which controls the interrupt polarity which
selects if the interrupt triggers on high-to-low or low-to-high.
So i guess it doesn't matter on freescale machines too.
---
Best Regards, Laurentiu
Re: [PATCH v2] powerpc: allow compiling with GENERIC_MSI_IRQ_DOMAIN
Hi Michael, On 07/18/2017 01:55 PM, Michael Ellerman wrote: > laurentiu.tu...@nxp.com writes: > >> From: Laurentiu Tudor >> >> This allows building powerpc with the GENERIC_MSI_IRQ_DOMAIN >> Kconfig by enabling the asm-generic msi.h in Kbuild. Without >> this, there's a compilation error [1] because powerpc, as most >> arches, doesn't provide an asm/msi.h. >> >> [1] In file included from ./include/linux/kvm_host.h:20:0, >> from ./arch/powerpc/include/asm/kvm_ppc.h:30, >> from arch/powerpc/kernel/dbell.c:20: >> ./include/linux/msi.h:195:21: fatal error: asm/msi.h: No such file or >> directory >> >> Signed-off-by: Laurentiu Tudor >> --- >> v2: >> - compilation error happens when GENERIC_MSI_IRQ_DOMAIN is enabled and not >> GENERIC_MSI_IRQ, so fix commit msg and title > > It looks like the only way powerpc can enable GENERIC_MSI_IRQ_DOMAIN is > by enabling FSL_MC_BUS ? > Yes, i think so. I'm currently working on making FSL_MC_BUS compile multi-arch [1] and that's how i hit this compilation error on ppc. [1] https://lkml.org/lkml/2017/7/17/415 --- Best Regards, Laurentiu
Re: [PATCH] powerpc: allow compiling with GENERIC_MSI_IRQ
Hi Michael, On 06/30/2017 01:08 PM, Michael Ellerman wrote: > Hi Laurentiu, > > laurentiu.tu...@nxp.com writes: >> From: Laurentiu Tudor >> >> This allows building powerpc with the GENERIC_MSI_IRQ Kconfig >> by enabling the asm-generic msi.h in Kbuild. Without this, >> there's a compilation error [1] because powerpc, as most arches, >> doesn't provide an asm/msi.h. >> >> [1] In file included from ./include/linux/kvm_host.h:20:0, >> from ./arch/powerpc/include/asm/kvm_ppc.h:30, >> from arch/powerpc/kernel/dbell.c:20: >> ./include/linux/msi.h:195:21: fatal error: asm/msi.h: No such file or >> directory > > I have >50 configs here with GENERIC_MSI_IRQ=y, so I don't understand > what's going wrong for you. > > Can you tell me more about what you're doing and how it's breaking. > Actually i made an error in the commit message, sorry about that. It's GENERIC_MSI_IRQ_DOMAIN that breaks the arch/powerpc build. If this is enabled, the generic header include/linux/msi.h wants an asm/msi.h and we don't have one on powerpc. That's what the patch tries to fix. Want me to resend with the correct commit message? ... if you're ok with the patch, of course. --- Thanks & Best Regards, Laurentiu
RE: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms
-Original Message- From: Michael Ellerman [mailto:m...@ellerman.id.au] Sent: Friday, April 07, 2017 4:22 PM To: Laurentiu Tudor ; Horia Geantă ; Herbert Xu ; Scott Wood ; Roy Pledge Cc: Claudiu Manoil ; Cristian Stoica ; Dan Douglass ; linux-arm-ker...@lists.infradead.org; Vakul Garg ; linuxppc-dev@lists.ozlabs.org; David S. Miller ; Alexandru Porosanu ; linux-cry...@vger.kernel.org Subject: Re: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms Importance: High Laurentiu Tudor writes: > On 04/05/2017 01:06 PM, Michael Ellerman wrote: >> Laurentiu Tudor writes: >> >>> Hi Michael, >>> >>> Just a couple of basic things to check: >>>- was the dtb updated to the newest? >> >> Possibly not, it's an automated build/boot, I'll have to check what >> it does with the dtb. >> >>>- is the qman node present? This should be easily visible in >>> /proc/device-tree/soc@ffe00/qman@318000. >> >> No it's not there. >> >> That's running linux-next with: >> >> CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI=n >> >> >> Does that mean I didn't update the device tree? > > I think so. Also, I just checked that the node is actually there by > compiling p5020ds.dts and then decompiling the dtb. > OK, I'll make sure I update the DTB. > > It will still be good if the code was a bit more robust about the qman being > missing. Totally agree. We should handle this error condition. --- Thanks & Best Regards, Laurentiu
Re: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms
On 04/05/2017 01:06 PM, Michael Ellerman wrote: > Laurentiu Tudor writes: > >> Hi Michael, >> >> Just a couple of basic things to check: >>- was the dtb updated to the newest? > > Possibly not, it's an automated build/boot, I'll have to check what it > does with the dtb. > >>- is the qman node present? This should be easily visible in >> /proc/device-tree/soc@ffe00/qman@318000. > > No it's not there. > > That's running linux-next with: > > CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI=n > > > Does that mean I didn't update the device tree? > I think so. Also, I just checked that the node is actually there by compiling p5020ds.dts and then decompiling the dtb. --- Best Regards, Laurentiu
Re: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms
Hi Michael,
Just a couple of basic things to check:
- was the dtb updated to the newest?
- is the qman node present? This should be easily visible in
/proc/device-tree/soc@ffe00/qman@318000.
---
Best Regards, Laurentiu
On 04/04/2017 08:03 AM, Michael Ellerman wrote:
> Horia Geantă writes:
>
>> Add support to submit ablkcipher and authenc algorithms
>> via the QI backend:
>> -ablkcipher:
>> cbc({aes,des,des3_ede})
>> ctr(aes), rfc3686(ctr(aes))
>> xts(aes)
>> -authenc:
>> authenc(hmac(md5),cbc({aes,des,des3_ede}))
>> authenc(hmac(sha*),cbc({aes,des,des3_ede}))
>>
>> caam/qi being a new driver, let's wait some time to settle down without
>> interfering with existing caam/jr driver.
>> Accordingly, for now all caam/qi algorithms (caamalg_qi module) are
>> marked to be of lower priority than caam/jr ones (caamalg module).
>>
>> Signed-off-by: Vakul Garg
>> Signed-off-by: Alex Porosanu
>> Signed-off-by: Horia Geantă
>> ---
>> drivers/crypto/caam/Kconfig| 20 +-
>> drivers/crypto/caam/Makefile |1 +
>> drivers/crypto/caam/caamalg.c |9 +-
>> drivers/crypto/caam/caamalg_desc.c | 77 +-
>> drivers/crypto/caam/caamalg_desc.h | 15 +-
>> drivers/crypto/caam/caamalg_qi.c | 2387
>>
>> drivers/crypto/caam/sg_sw_qm.h | 108 ++
>> 7 files changed, 2601 insertions(+), 16 deletions(-)
>> create mode 100644 drivers/crypto/caam/caamalg_qi.c
>> create mode 100644 drivers/crypto/caam/sg_sw_qm.h
>
>
> This appears to be blowing up my Freescale (NXP) P5020DS board:
>
>Unable to handle kernel paging request for data at address 0x0020
>Faulting instruction address: 0xc04393e4
>Oops: Kernel access of bad area, sig: 11 [#1]
>SMP NR_CPUS=24
>CoreNet Generic
>Modules linked in:
>CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.11.0-rc3-compiler_gcc-4.6.3-00046-gb189817cf789 #5
>task: c000f70c task.stack: c000f70c8000
>NIP: c04393e4 LR: c04aeba0 CTR: c04fa7d8
>REGS: c000f70cb160 TRAP: 0300 Not tainted
> (4.11.0-rc3-compiler_gcc-4.6.3-00046-gb189817cf789)
>MSR: 80029000
> CR: 24adbe48 XER: 2000
>DEAR: 0020 ESR: SOFTE: 1
>GPR00: c06feba0 c000f70cb3e0 c0e6
>GPR04: 0001 c0e0b290 0003
>GPR08: 0004 c0ea5280 0004 0004
>GPR12: 88adbe22 c0003fff5000 c0ba3518 880088090fa8
>GPR16: 1000 c0ba3500 c000f72c68d8 0004
>GPR20: c0ea5280 c0ba34e8 0020 0004
>GPR24: c0eab7c0 c000f7fc8818 c0eb
>GPR28: c000f786cc00 c0eab780 f786cc00 c0eab7c0
>NIP [c04393e4] .gen_pool_alloc+0x0/0xc
>LR [c04aeba0] .qman_alloc_cgrid_range+0x24/0x54
>Call Trace:
>[c000f70cb3e0] [c0504054]
> .platform_device_register_full+0x12c/0x150 (unreliable)
>[c000f70cb460] [c06feba0] .caam_qi_init+0x158/0x63c
>[c000f70cb5f0] [c06fc64c] .caam_probe+0x8b8/0x1830
>[c000f70cb740] [c0503288] .platform_drv_probe+0x60/0xac
>[c000f70cb7c0] [c0501194] .driver_probe_device+0x248/0x344
>[c000f70cb870] [c05013b4] .__driver_attach+0x124/0x128
>[c000f70cb900] [c04fed90] .bus_for_each_dev+0x80/0xcc
>[c000f70cb9a0] [c0500858] .driver_attach+0x24/0x38
>[c000f70cba10] [c050043c] .bus_add_driver+0x14c/0x29c
>[c000f70cbab0] [c0501d64] .driver_register+0x8c/0x154
>[c000f70cbb30] [c0503000] .__platform_driver_register+0x48/0x5c
>[c000f70cbba0] [c0c7f798] .caam_driver_init+0x1c/0x30
>[c000f70cbc10] [c0001904] .do_one_initcall+0x60/0x1a8
>[c000f70cbcf0] [c0c35f30] .kernel_init_freeable+0x248/0x334
>[c000f70cbdb0] [c00020fc] .kernel_init+0x1c/0xf20
>[c000f70cbe30] [c9bc] .ret_from_kernel_thread+0x58/0x9c
>Instruction dump:
>eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 4e800020 3860 4bb0
>7ce53b78 4b0c 7f67db78 4b24 e8c30028 4bfffd30 fbe1fff8
>---[ end trace 9f61087068991b02 ]---
>
>
> home:linux-next(4)(I)> git bisect log
> ...
> git bisect bad b189817cf7894e03fd3700acd923221d3007259e
> # first bad commit: [b189817cf7894e03fd3700acd923221d3007259e] crypto:
> caam/qi - add ablkcipher and authenc algorithms
>
>
> The oops is saying gen_pool_alloc() was called with a NULL pointer, so
> it seems qm_cgralloc is NULL:
>
> static int qman_alloc_range(struct gen_pool *p, u32 *result, u32 cnt)
> {
> unsigned long addr;
>
> addr = gen_pool_alloc(p, cnt);
> ...
>
> int qman_alloc_cgrid_range(u32 *result, u32 co
Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd
Hi, Some more information on the crash, inline. On 02/17/2017 02:18 PM, Aneesh Kumar K.V wrote: > laurentiu.tu...@nxp.com writes: > >> From: Laurentiu Tudor >> >> On 32-bit book-e machines, hugepd_ok() does not take >> into account null hugepd values, causing this crash at boot: >> >> Unable to handle kernel paging request for data at address 0x8000 >> Faulting instruction address: 0xc00182a8 >> Oops: Kernel access of bad area, sig: 11 [#1] >> SMP NR_CPUS=24 >> CoreNet Generic >> Modules linked in: >> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW >> 4.10.0-rc8-00016-g69b1f87 #11 >> task: e505 task.stack: e5058000 >> NIP: c00182a8 LR: c001829c CTR: 7ffe >> REGS: e5059c50 TRAP: 0300 Tainted: GW >> (4.10.0-rc8-00016-g69b1f87) >> MSR: 00021002 >>CR: 88428e82 XER: >> DEAR: 8000 ESR: >> GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 >> 2017 >> GPR08: 28428e82 c00027d0 >> >> GPR16: 88a28e82 2000 48422e82 88a28e84 >> dd004000 >> GPR24: e5059e38 bff1 dd004000 0001 00029002 >> bff1 >> NIP [c00182a8] follow_huge_addr+0x38/0xf0 >> LR [c001829c] follow_huge_addr+0x2c/0xf0 >> Call Trace: >> [e5059d00] [e5059d00] 0xe5059d00 (unreliable) >> [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0 >> [e5059d80] [c0107958] __get_user_pages+0xc8/0x420 >> [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230 >> [e5059e30] [c013f170] copy_strings+0x110/0x3a0 >> [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50 >> [e5059ec0] [c0141324] do_execveat_common+0x474/0x620 >> [e5059f10] [c01414fc] do_execve+0x2c/0x40 >> [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60 >> [e5059f30] [c000289c] kernel_init+0xcc/0x120 >> [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64 >> Instruction dump: >> bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008 >> 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89 >> ---[ end trace 4bf94e15fd9fa824 ]--- > > > Which code path is that. That null should be filtered by the if > (pmd_none(pmd)) check in find_linux_pte_or_hugepte right ? The crash happens when __find_linux_pte_or_hugepte() calls hugepd_ok(), on this line [1]. It's triggered when __find_linux_pte_or_hugepte() is first called, when the kernel tries to spawn the init process. The input effective address (ea arg) is bff1. This is the call stack: [e5059cd0] [c0017b60] __find_linux_pte_or_hugepte+0x60/0x120 (unreliable) [e5059d00] [c001832c] follow_huge_addr+0x2c/0xf0 [e5059d20] [c0107590] follow_page_mask+0x40/0x3c0 [e5059d80] [c01079d8] __get_user_pages+0xc8/0x420 [e5059de0] [c01081fc] get_user_pages_remote+0x8c/0x230 [e5059e30] [c013f210] copy_strings+0x110/0x3a0 [e5059ea0] [c013f4cc] copy_strings_kernel+0x2c/0x50 [e5059ec0] [c01413c4] do_execveat_common+0x474/0x620 [e5059f10] [c014159c] do_execve+0x2c/0x40 [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60 [e5059f30] [c000289c] kernel_init+0xcc/0x120 [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64 Thanks in advance for any pointers. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/mm/hugetlbpage.c#n918 --- Best Regards, Laurentiu
Re: [bug report] v4.10.1 Oops on P1010 - huge tlb - there's already a fix ...
Hi Wolfgang, Thanks for reporting! On 02/28/2017 01:47 PM, Wolfgang Ocker wrote:> On Tue, 2017-02-28 at 10:57 +0100, Wolfgang Ocker wrote: >> With kernel v4.10.1 and huge tlb enabled (CONFIG_HUGETLBFS=y) I see >> the >> following oops on a P1010: > > Just saw that there is already a fix: > The fix is not accepted but you can use it until we come up with a better one. Please note that 4.7 & 4.9 stable kernels are also impacted so if you plan to use them you'll need the fix. --- Best Regards, Laurentiu
Re: [PATCH] staging: fsl-mc: fix warning in DT ranges parser
Hi Arnd, On 02/27/2017 10:42 PM, Arnd Bergmann wrote: > The fsl-mc-bus driver in staging contains a copy of the standard > 'ranges' property parsing algorithm with a hack to treat a missing > property the same way as an empty one. This code produces false-positive > warnings for me in an allmodconfig build: > > drivers/staging/fsl-mc/bus/fsl-mc-bus.c: In function 'fsl_mc_bus_probe': > drivers/staging/fsl-mc/bus/fsl-mc-bus.c:645:6: error: 'mc_size_cells' may be > used uninitialized in this function [-Werror=maybe-uninitialized] > drivers/staging/fsl-mc/bus/fsl-mc-bus.c:682:8: error: 'mc_addr_cells' may be > used uninitialized in this function [-Werror=maybe-uninitialized] > drivers/staging/fsl-mc/bus/fsl-mc-bus.c:644:6: note: 'mc_addr_cells' was > declared here > drivers/staging/fsl-mc/bus/fsl-mc-bus.c:684:8: error: 'paddr_cells' may be > used uninitialized in this function [-Werror=maybe-uninitialized] > drivers/staging/fsl-mc/bus/fsl-mc-bus.c:643:6: note: 'paddr_cells' was > declared here > > To avoid the warnings, I'm simplifying the argument handling to pass > the number of valid ranges in the property as the function return code > rather than passing it by reference. With this change, gcc can see that > we don't evaluate the cell numbers for an missing ranges property. > > Signed-off-by: Arnd Bergmann Looks good to me, i've tested it and did not see any issues, so here's an: Acked-by: Laurentiu Tudor --- Thanks & Best Regards, Laurentiu
Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd
On 02/17/2017 02:18 PM, Aneesh Kumar K.V wrote: > laurentiu.tu...@nxp.com writes: > >> From: Laurentiu Tudor >> >> On 32-bit book-e machines, hugepd_ok() does not take >> into account null hugepd values, causing this crash at boot: >> >> Unable to handle kernel paging request for data at address 0x8000 >> Faulting instruction address: 0xc00182a8 >> Oops: Kernel access of bad area, sig: 11 [#1] >> SMP NR_CPUS=24 >> CoreNet Generic >> Modules linked in: >> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW >> 4.10.0-rc8-00016-g69b1f87 #11 >> task: e505 task.stack: e5058000 >> NIP: c00182a8 LR: c001829c CTR: 7ffe >> REGS: e5059c50 TRAP: 0300 Tainted: GW >> (4.10.0-rc8-00016-g69b1f87) >> MSR: 00021002 >>CR: 88428e82 XER: >> DEAR: 8000 ESR: >> GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 >> 2017 >> GPR08: 28428e82 c00027d0 >> >> GPR16: 88a28e82 2000 48422e82 88a28e84 >> dd004000 >> GPR24: e5059e38 bff1 dd004000 0001 00029002 >> bff1 >> NIP [c00182a8] follow_huge_addr+0x38/0xf0 >> LR [c001829c] follow_huge_addr+0x2c/0xf0 >> Call Trace: >> [e5059d00] [e5059d00] 0xe5059d00 (unreliable) >> [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0 >> [e5059d80] [c0107958] __get_user_pages+0xc8/0x420 >> [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230 >> [e5059e30] [c013f170] copy_strings+0x110/0x3a0 >> [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50 >> [e5059ec0] [c0141324] do_execveat_common+0x474/0x620 >> [e5059f10] [c01414fc] do_execve+0x2c/0x40 >> [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60 >> [e5059f30] [c000289c] kernel_init+0xcc/0x120 >> [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64 >> Instruction dump: >> bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008 >> 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89 >> ---[ end trace 4bf94e15fd9fa824 ]--- > > > Which code path is that. That null should be filtered by the if > (pmd_none(pmd)) check in find_linux_pte_or_hugepte right ? > I haven't characterized the issue in detail as i wanted to get the patch out ASAP. I only noticed that the previous check, that is: "signed hpd_val > 0" vs the new one, that is: "unsigned hpd_val & PD_HUGE == 0" evaluate differently for a value of zero: old expression evaluates to false and the new one to true. --- Best Regards, Laurentiu
Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd
On 02/17/2017 12:08 PM, Scott Wood wrote: > On Thu, 2017-02-16 at 09:11 -0600, laurentiu.tu...@nxp.com wrote: >> From: Laurentiu Tudor >> >> On 32-bit book-e machines, hugepd_ok() does not take >> into account null hugepd values, causing this crash at boot: > > Why only 32-bit? I wanted to get this patch out as quick as possible so i didn't had time to investigate in depth. I just tested on 64-bit that the kernel boots ok. >> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h >> b/arch/powerpc/include/asm/nohash/pgtable.h >> index 0cd8a38..e5805ad 100644 >> --- a/arch/powerpc/include/asm/nohash/pgtable.h >> +++ b/arch/powerpc/include/asm/nohash/pgtable.h >> @@ -230,7 +230,7 @@ static inline int hugepd_ok(hugepd_t hpd) >> return ((hpd_val(hpd) & 0x4) != 0); >> #else >> /* We clear the top bit to indicate hugepd */ >> -return ((hpd_val(hpd) & PD_HUGE) == 0); >> +return (hpd_val(hpd) && (hpd_val(hpd) & PD_HUGE) == 0); >> #endif >> } >> > > Any reason why this can't go back to being "hpd_val(hpd) > 0"? Why was nohash > changed to begin with? I don't expect nohash (or at least fsl-book3e) will > ever have a pagetable that is not native-endian, and "> 0" is consistent with > what the TLB miss code is doing. The patch that introduced the brokenness changes "hugepd_t.pd" from "signed long" to "unsigned long" so as a consequence "> 0" was replaced with the bitwise op. --- Best Regards, Laurentiu
Re: "Unable to handle kernel paging request for instruction fetch" on P4080
Hi Thomas, On 02/01/2017 11:46 AM, Thomas De Schampheleire wrote: > On Wed, Jan 25, 2017 at 10:46 AM, Thomas De Schampheleire > wrote: >> Hi, >> >> We are experiencing kernel panics of the type "Unable to handle kernel paging >> request for instruction fetch" but are stuck in our analysis. We would >> appreciate any help you can give. >> >> The problem occurs from time to time on different instances of a particular >> embedded systems. The kernel is very old, 2.6.36.4, and runs on an 8-core >> Freescale P4080 QorIQ processor (e500mc-based). Upgrading the kernel to a >> newer >> version is not an option at this point. Any chance of at least trying a newer kernel just to check if the issue was fixed in the meantime. Also, trying a newer u-boot might help. Another thing: can you try booting on one core only? --- Best Regards, Laurentiu
Re: [PATCH v2 05/18] powerpc/85xx: Load all early TLB entries at once
On 10/07/2015 06:48 AM, Scott Wood wrote:
> Use an AS=1 trampoline TLB entry to allow all normal TLB1 entries to
> be loaded at once. This avoids the need to keep the translation that
> code is executing from in the same TLB entry in the final TLB
> configuration as during early boot, which in turn is helpful for
> relocatable kernels (e.g. kdump) where the kernel is not running from
> what would be the first TLB entry.
>
> On e6500, we limit map_mem_in_cams() to the primary hwthread of a
> core (the boot cpu is always considered primary, as a kdump kernel
> can be entered on any cpu). Each TLB only needs to be set up once,
> and when we do, we don't want another thread to be running when we
> create a temporary trampoline TLB1 entry.
>
> Signed-off-by: Scott Wood
> ---
> arch/powerpc/kernel/setup_64.c | 8 +
> arch/powerpc/mm/fsl_booke_mmu.c | 15 --
> arch/powerpc/mm/mmu_decl.h | 1 +
> arch/powerpc/mm/tlb_nohash.c | 19 +++-
> arch/powerpc/mm/tlb_nohash_low.S | 63
>
> 5 files changed, 102 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index bdcbb71..505ec2c 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -108,6 +108,14 @@ static void setup_tlb_core_data(void)
> for_each_possible_cpu(cpu) {
> int first = cpu_first_thread_sibling(cpu);
>
> + /*
> + * If we boot via kdump on a non-primary thread,
> + * make sure we point at the thread that actually
> + * set up this TLB.
> + */
> + if (cpu_first_thread_sibling(boot_cpuid) == first)
> + first = boot_cpuid;
> +
> paca[cpu].tcd_ptr = &paca[first].tcd;
>
> /*
> diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
> index 354ba3c..36d3c55 100644
> --- a/arch/powerpc/mm/fsl_booke_mmu.c
> +++ b/arch/powerpc/mm/fsl_booke_mmu.c
> @@ -105,8 +105,9 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
> * an unsigned long (for example, 32-bit implementations cannot support a 4GB
> * size).
> */
> -static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
> - unsigned long size, unsigned long flags, unsigned int pid)
> +static void preptlbcam(int index, unsigned long virt, phys_addr_t phys,
> +unsigned long size, unsigned long flags,
> +unsigned int pid)
> {
> unsigned int tsize;
>
> @@ -141,7 +142,13 @@ static void settlbcam(int index, unsigned long virt,
> phys_addr_t phys,
> tlbcam_addrs[index].start = virt;
> tlbcam_addrs[index].limit = virt + size - 1;
> tlbcam_addrs[index].phys = phys;
> +}
>
> +void settlbcam(int index, unsigned long virt, phys_addr_t phys,
Nit: shouldn't this be left static? Also, now with this bulk TLB1 loading is it
still used? Maybe it can be dropped.
---
Best Regards, Laurentiu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/e6500: add TMCFG0 register definition
The register is not currently used in the base kernel but will be in a forthcoming kvm patch. Signed-off-by: Laurentiu Tudor --- arch/powerpc/include/asm/reg_booke.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index 16547ef..2fef74b 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -742,6 +742,12 @@ #define MMUBE1_VBE40x0002 #define MMUBE1_VBE50x0001 +#define TMRN_TMCFG0 16/* Thread Management Configuration Register 0 */ +#define TMRN_TMCFG0_NPRIBITS 0x003f /* Bits of thread priority */ +#define TMRN_TMCFG0_NPRIBITS_SHIFT 16 +#define TMRN_TMCFG0_NATHRD 0x3f00 /* Number of active threads */ +#define TMRN_TMCFG0_NATHRD_SHIFT 8 +#define TMRN_TMCFG0_NTHRD 0x003f /* Number of threads */ #define TMRN_IMSR0 0x120 /* Initial MSR Register 0 (e6500) */ #define TMRN_IMSR1 0x121 /* Initial MSR Register 1 (e6500) */ #define TMRN_INIA0 0x140 /* Next Instruction Address Register 0 */ -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: using general IRQs
On 08/10/2015 10:48 AM, Ran Shalit wrote:
> Hello,
>
> MPC8349 has general IRQ numbered 0-7,
> It is required to bind these IRQs with some routine , i.e. they are
> not used with any specific driver.
>
> - Should they be configured as gpios in device tree so that we can use
> the gpio as irq in linux ? Is there any example ?
If it's a gpio then yes, you need to use it as a gpio. Not familiar with
MPC8349,
but newer FSL chips can select between gpio or irq through a RCW field
(IRQ_BASE?).
Note that for gpios there's special apis, such as: of_get_gpio(),
gpio_request_one() a.s.o.
Also you'll need to update your device tree node to something like:
intc2@0{
compatible = "intc2";
reg = <0 0x1000>;
gpios = <&gpio0 4 0>;
};
See Documentation/gpio.txt for more info.
---
Best Regards, Laurentiu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/perf: Fix book3s kernel to userspace backtraces
On 05/26/2015 08:10 AM, Anton Blanchard wrote:
> When we take a PMU exception or a software event we call
> perf_read_regs(). This overloads regs->result with a boolean that
> describes if we should use the sampled instruction address register
> (SIAR) or the regs.
>
> If the exception is in kernel, we start with the kernel regs and
> backtrace through the kernel stack. At this point we switch to the
> userspace regs and backtrace the user stack with perf_callchain_user().
>
> Unfortunately these regs have not got the perf_read_regs() treatment,
> so regs->result could be anything. If it is non zero,
> perf_instruction_pointer() decides to use the SIAR, and we get issues
> like this:
>
> 0.11% qemu-system-ppc [kernel.kallsyms][k] _raw_spin_lock_irqsave
>|
>---_raw_spin_lock_irqsave
> |
> |--52.35%-- 0
> | |
> | |--46.39%-- __hrtimer_start_range_ns
> | | kvmppc_run_core
> | | kvmppc_vcpu_run_hv
> | | kvmppc_vcpu_run
> | | kvm_arch_vcpu_ioctl_run
> | | kvm_vcpu_ioctl
> | | do_vfs_ioctl
> | | sys_ioctl
> | | system_call
> | | |
> | | |--67.08%-- _raw_spin_lock_irqsave <--- hi mum
> | | | |
> | | | --100.00%-- 0x7e714
> | | | 0x7e714
>
> Notice the bogus _raw_spin_irqsave when we transition from kernel
> (system_call) to userspace (0x7e714). We inserted what was in the SIAR.
>
> Add a check in regs_use_siar() to check that the regs in question
> are from a PMU exception. With this fix the backtrace makes sense:
>
> 0.47% qemu-system-ppc [kernel.vmlinux] [k]
> _raw_spin_lock_irqsave
> |
> ---_raw_spin_lock_irqsave
>|
>|--53.83%-- 0
>| |
>| |--44.73%-- hrtimer_try_to_cancel
>| | kvmppc_start_thread
>| | kvmppc_run_core
>| | kvmppc_vcpu_run_hv
>| | kvmppc_vcpu_run
>| | kvm_arch_vcpu_ioctl_run
>| | kvm_vcpu_ioctl
>| | do_vfs_ioctl
>| | sys_ioctl
>| | system_call
>| | __ioctl
>| | 0x7e714
>| | 0x7e714
>
> Signed-off-by: Anton Blanchard
> ---
> arch/powerpc/perf/core-book3s.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 12b6384..42a3725 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -131,7 +131,10 @@ static void pmao_restore_workaround(bool ebb) { }
>
> static bool regs_use_siar(struct pt_regs *regs)
> {
> - return !!regs->result;
> + if ((TRAP(regs) == 0xf00) && regs->result)
> + return true;
> +
> + return false;
Why not just
return (TRAP(regs) == 0xf00) && regs->result;
?
---
Best Regards, Laurentiu;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/3][PATCH][v2] Device Tree bindings for Freescale TDM controller
Hi Sandeep, Small nit inside. On 04/02/2015 01:47 PM, sand...@freescale.com wrote: > From: Sandeep Singh > > This controller is available on many Freescale SOCs like MPC8315, P1020, > P1010, > P1022 and P1024 > > Signed-off-by: Sandeep Singh > Signed-off-by: Poonam Aggrwal > --- > Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 65 > + > 1 files changed, 65 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/tdm/fsl-tdm.txt > > diff --git a/Documentation/devicetree/bindings/tdm/fsl-tdm.txt > b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt > new file mode 100644 > index 000..1258b89 > --- /dev/null > +++ b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt > @@ -0,0 +1,65 @@ > += > +TDM Device Tree Binding > +Copyright (C) 2012 Freescale Semiconductor Inc. > + > +NOTE: The bindings described in this document are preliminary > +and subject to change. > + > += > +TDM (Time Division Multiplexing) > + > +DESCRIPTION > + > +The TDM is full duplex serial port designed to allow various devices > including > +digital signal processors (DSPs) to communicate with a variety of serial > devices > +including industry standard framers, codecs, other DSPs and microprocessors. > + > +The below properties describe the device tree bindings for Freescale TDM > +controller. > +This TDM controller is available on various Freescale Processors like > +MPC8313, P1020, P1022 and P1010. > + > +PROPERTIES > + > + - compatible > + Usage: required > + Value type: > + Definition: Should contain "fsl,tdm1.0". > + > + - reg > + Usage: required > + Definition: A standard property. The first reg specifier describes the > + TDM registers, and the second describes the TDM DMAC registers. > + > + - clock-frequency > + Usage: optional > + Value type: > + Definition: The frequency at which the TDM block is operating. > + > + - interrupts > + Usage: required > + Definition: Definition: Two interrupt specifiers. The first is TDM Extra "Definition:" here. --- Best Regards, Laurentiu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/msi: Use WARN_ON() in msi bitmap selftests
Hi Michael, Comment inline. On 10/10/2014 11:04 AM, Michael Ellerman wrote: > As demonstrated in the previous commit, the failure message from the msi > bitmap selftests is a bit subtle, it's easy to miss a failure in a busy > boot log. > > So drop our check() macro and use WARN_ON() instead. This necessitates > inverting all the conditions as well. > > Signed-off-by: Michael Ellerman > --- > arch/powerpc/sysdev/msi_bitmap.c | 54 > ++-- [snip] > > /* Free most of them for the alignment tests */ > msi_bitmap_free_hwirqs(&bmp, 3, size - 3); > > /* Check we get a naturally aligned offset */ > rc = msi_bitmap_alloc_hwirqs(&bmp, 2); > - check(rc >= 0 && rc % 2 == 0); > + WARN_ON(rc < 0 && rc % 2 != 0); Here and below, shouldn't these be: WARN_ON(rc < 0 || rc % 2 != 0); ? > rc = msi_bitmap_alloc_hwirqs(&bmp, 4); > - check(rc >= 0 && rc % 4 == 0); > + WARN_ON(rc < 0 && rc % 4 != 0); > rc = msi_bitmap_alloc_hwirqs(&bmp, 8); > - check(rc >= 0 && rc % 8 == 0); > + WARN_ON(rc < 0 && rc % 8 != 0); > rc = msi_bitmap_alloc_hwirqs(&bmp, 9); > - check(rc >= 0 && rc % 16 == 0); > + WARN_ON(rc < 0 && rc % 16 != 0); > rc = msi_bitmap_alloc_hwirqs(&bmp, 3); > - check(rc >= 0 && rc % 4 == 0); > + WARN_ON(rc < 0 && rc % 4 != 0); > rc = msi_bitmap_alloc_hwirqs(&bmp, 7); > - check(rc >= 0 && rc % 8 == 0); > + WARN_ON(rc < 0 && rc % 8 != 0); > rc = msi_bitmap_alloc_hwirqs(&bmp, 121); > - check(rc >= 0 && rc % 128 == 0); > + WARN_ON(rc < 0 && rc % 128 != 0); > > msi_bitmap_free(&bmp); > > - /* Clients may check bitmap == NULL for "not-allocated" */ > - check(bmp.bitmap == NULL); > + /* Clients may WARN_ON bitmap == NULL for "not-allocated" */ > + WARN_ON(bmp.bitmap != NULL); > > kfree(bmp.bitmap); > } > @@ -229,14 +224,13 @@ static void __init test_of_node(void) > of_node_init(&of_node); > of_node.full_name = node_name; > > - check(0 == msi_bitmap_alloc(&bmp, size, &of_node)); > + WARN_ON(msi_bitmap_alloc(&bmp, size, &of_node)); > > /* No msi-available-ranges, so expect > 0 */ > - check(msi_bitmap_reserve_dt_hwirqs(&bmp) > 0); > + WARN_ON(msi_bitmap_reserve_dt_hwirqs(&bmp) <= 0); > > /* Should all still be free */ > - check(0 == bitmap_find_free_region(bmp.bitmap, size, > -get_count_order(size))); > + WARN_ON(bitmap_find_free_region(bmp.bitmap, size, > get_count_order(size))); > bitmap_release_region(bmp.bitmap, 0, get_count_order(size)); > > /* Now create a fake msi-available-ranges property */ > @@ -250,11 +244,11 @@ static void __init test_of_node(void) > of_node.properties = ∝ > > /* msi-available-ranges, so expect == 0 */ > - check(msi_bitmap_reserve_dt_hwirqs(&bmp) == 0); > + WARN_ON(msi_bitmap_reserve_dt_hwirqs(&bmp)); > > /* Check we got the expected result */ > - check(0 == bitmap_parselist(expected_str, expected, size)); > - check(bitmap_equal(expected, bmp.bitmap, size)); > + WARN_ON(bitmap_parselist(expected_str, expected, size)); > + WARN_ON(!bitmap_equal(expected, bmp.bitmap, size)); > > msi_bitmap_free(&bmp); > kfree(bmp.bitmap); > --- Best Regards, Laurentiu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
Hi Jingchang, On 09/23/2014 09:46 AM, Jingchang Lu wrote: > The IP is shared by PPC and ARM, this renames it to qoriq for better > represention, and this also adds the CLK_OF_DECLARE support for being > initialized by of_clk_init() on ARM. > I think you need to also update drivers/cpufreq/Kconfig.powerpc to use the renamed config option. --- Best Regards, Laurentiu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/15] powerpc/msi: Improve IRQ bitmap allocator
Hi Michael, Minor comment inline. On 09/18/2014 11:26 AM, Michael Neuling wrote: > From: Ian Munsie > > Currently msi_bitmap_alloc_hwirqs() will round up any IRQ allocation requests > to the nearest power of 2. eg. ask for 5 IRQs and you'll get 8. This wastes > a > lot of IRQs which can be a scarce resource. > > For cxl we can require multiple IRQs for every contexts that is attached to > the > accelerator. For AFU directed accelerators, there may be 1000s of contexts > attached, hence we can easily run out of IRQs, especially if we are needlessly > wasting them. > > This changes the msi_bitmap_alloc_hwirqs() to allocate only the required > number > of IRQs, hence avoiding this wastage. > > Signed-off-by: Ian Munsie > Signed-off-by: Michael Neuling > --- > arch/powerpc/sysdev/msi_bitmap.c | 18 +- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/arch/powerpc/sysdev/msi_bitmap.c > b/arch/powerpc/sysdev/msi_bitmap.c > index 2ff6302..e001559 100644 > --- a/arch/powerpc/sysdev/msi_bitmap.c > +++ b/arch/powerpc/sysdev/msi_bitmap.c > @@ -24,28 +24,36 @@ int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int > num) >* This is fast, but stricter than we need. We might want to add >* a fallback routine which does a linear search with no alignment. >*/ Is this comment still relevant (especially the part mentioning "fast")? --- Best Regards, Laurentiu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/15] powerpc/msi: Improve IRQ bitmap allocator
On 09/19/2014 11:16 PM, Scott Wood wrote:
> On Thu, 2014-09-18 at 18:26 +1000, Michael Neuling wrote:
>> From: Ian Munsie
>>
>> Currently msi_bitmap_alloc_hwirqs() will round up any IRQ allocation requests
>> to the nearest power of 2. eg. ask for 5 IRQs and you'll get 8. This
>> wastes a
>> lot of IRQs which can be a scarce resource.
>>
>> For cxl we can require multiple IRQs for every contexts that is attached to
>> the
>> accelerator. For AFU directed accelerators, there may be 1000s of contexts
>> attached, hence we can easily run out of IRQs, especially if we are
>> needlessly
>> wasting them.
>>
>> This changes the msi_bitmap_alloc_hwirqs() to allocate only the required
>> number
>> of IRQs, hence avoiding this wastage.
>>
>> Signed-off-by: Ian Munsie
>> Signed-off-by: Michael Neuling
>> ---
>> arch/powerpc/sysdev/msi_bitmap.c | 18 +-
>> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> This conflicts with (and partially duplicates)
> http://patchwork.ozlabs.org/patch/381892/
> which I have in my tree. How should we handle it?
>
> Laurentiu, from looking at the overlap between patches I see a problem
> with your existing patch, regarding the out-of-irqs path and
> msi_bitmap_free_hwirqs(), so one way or another that needs to get fixed
> soon.
>
Agree. My patch lacks error checking so Michael's patch is better.
---
Best Regards, Laurentiu
>
>> diff --git a/arch/powerpc/sysdev/msi_bitmap.c
>> b/arch/powerpc/sysdev/msi_bitmap.c
>> index 2ff6302..e001559 100644
>> --- a/arch/powerpc/sysdev/msi_bitmap.c
>> +++ b/arch/powerpc/sysdev/msi_bitmap.c
>> @@ -24,28 +24,36 @@ int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int
>> num)
>> * This is fast, but stricter than we need. We might want to add
>> * a fallback routine which does a linear search with no alignment.
>> */
>> -offset = bitmap_find_free_region(bmp->bitmap, bmp->irq_count, order);
>> +offset = bitmap_find_next_zero_area(bmp->bitmap, bmp->irq_count, 0,
>> +num, (1 << order) - 1);
>> +if (offset > bmp->irq_count)
>> +goto err;
>> +bitmap_set(bmp->bitmap, offset, num);
>> spin_unlock_irqrestore(&bmp->lock, flags);
>>
>> pr_debug("msi_bitmap: allocated 0x%x (2^%d) at offset 0x%x\n",
>> num, order, offset);
>>
>> return offset;
>> +err:
>> +spin_unlock_irqrestore(&bmp->lock, flags);
>> +return -ENOMEM;
>> }
>> +EXPORT_SYMBOL(msi_bitmap_alloc_hwirqs);
>>
>> void msi_bitmap_free_hwirqs(struct msi_bitmap *bmp, unsigned int offset,
>> unsigned int num)
>> {
>> unsigned long flags;
>> -int order = get_count_order(num);
>>
>> -pr_debug("msi_bitmap: freeing 0x%x (2^%d) at offset 0x%x\n",
>> - num, order, offset);
>> +pr_debug("msi_bitmap: freeing 0x%x at offset 0x%x\n",
>> + num, offset);
>>
>> spin_lock_irqsave(&bmp->lock, flags);
>> -bitmap_release_region(bmp->bitmap, offset, order);
>> +bitmap_clear(bmp->bitmap, offset, num);
>> spin_unlock_irqrestore(&bmp->lock, flags);
>> }
>> +EXPORT_SYMBOL(msi_bitmap_free_hwirqs);
>>
>> void msi_bitmap_reserve_hwirq(struct msi_bitmap *bmp, unsigned int hwirq)
>> {
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/15] powerpc/msi: Improve IRQ bitmap allocator
On 09/19/2014 11:19 PM, Scott Wood wrote: > On Fri, 2014-09-19 at 15:16 -0500, Scott Wood wrote: >> On Thu, 2014-09-18 at 18:26 +1000, Michael Neuling wrote: >>> From: Ian Munsie >>> >>> Currently msi_bitmap_alloc_hwirqs() will round up any IRQ allocation >>> requests >>> to the nearest power of 2. eg. ask for 5 IRQs and you'll get 8. This >>> wastes a >>> lot of IRQs which can be a scarce resource. >>> >>> For cxl we can require multiple IRQs for every contexts that is attached to >>> the >>> accelerator. For AFU directed accelerators, there may be 1000s of contexts >>> attached, hence we can easily run out of IRQs, especially if we are >>> needlessly >>> wasting them. >>> >>> This changes the msi_bitmap_alloc_hwirqs() to allocate only the required >>> number >>> of IRQs, hence avoiding this wastage. >>> >>> Signed-off-by: Ian Munsie >>> Signed-off-by: Michael Neuling >>> --- >>> arch/powerpc/sysdev/msi_bitmap.c | 18 +- >>> 1 file changed, 13 insertions(+), 5 deletions(-) >> >> This conflicts with (and partially duplicates) >> http://patchwork.ozlabs.org/patch/381892/ >> which I have in my tree. How should we handle it? >> >> Laurentiu, from looking at the overlap between patches I see a problem >> with your existing patch, regarding the out-of-irqs path and >> msi_bitmap_free_hwirqs(), so one way or another that needs to get fixed >> soon. > > Given the problems with Laurentiu's patch, perhaps it'd be best for me > to just revert that patch in my tree, and respin it after this patchset > has been merged. Let me know if you want me to rebase my stuff on top of Michael's patch. --- Best Regards, Laurentiu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: make sure of_alias is initialized before accessing it
On 09/08/2014 04:29 PM, Grant Likely wrote:
> On Wed, 27 Aug 2014 17:09:39 +0300, Laurentiu Tudor
> wrote:
>> Simply swap of_alias and of_chosen initialization so
>> that of_alias ends up read first. This must be done
>> because it is accessed couple of lines below when
>> trying to initialize the of_stdout using the alias
>> based legacy method.
>>
>> [Fixes a752ee5 - tty: Update hypervisor tty drivers to
>>
>> use core stdout parsing code]
>>
>> Signed-off-by: Laurentiu Tudor
>> Cc: Grant Likely
>> ---
>> drivers/of/base.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index d8574ad..52f8506 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -1847,6 +1847,10 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64
>> align))
>> {
>> struct property *pp;
>>
>> +of_aliases = of_find_node_by_path("/aliases");
>> +if (!of_aliases)
>> +return;
>> +
>> of_chosen = of_find_node_by_path("/chosen");
>> if (of_chosen == NULL)
>> of_chosen = of_find_node_by_path("/chosen@0");
>> @@ -1862,10 +1866,6 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64
>> align))
>> of_stdout = of_find_node_by_path(name);
>> }
>>
>> -of_aliases = of_find_node_by_path("/aliases");
>> -if (!of_aliases)
>> -return;
>> -
>
> Close, but not quite. The 'if (!of_aliases)' test should not be moved.
> Only the search for of_find_node_by_path().
Eek, completely missed this. Sorry.
> I've fixed it up and applied.
Thanks!
---
Best Regards, Laurentiu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
