From: Laurentiu Tudor <[email protected]>
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
From: [email protected]
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.
On Thu, May 30, 2019 at 5:09 PM David Miller <[email protected]> wrote:
>
> From: [email protected]
> 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.
One suggestion from the arm-soc maintainers is that after this pull
request is merged by arm-soc tree. You can also merge this pull
request and then apply the patches.
Regards,
Leo
Hello,
> -----Original Message-----
> From: David Miller <[email protected]>
> Sent: Friday, May 31, 2019 1:09 AM
>
> From: [email protected]
> 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
Hi Laurentiu,
Am 30.05.19 um 16:19 schrieb [email protected]:
> 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?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote:
> From: [email protected]
> 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.
The thing needs to be completely redone as it abuses parts of the
iommu API in a completely unacceptable way.
Hello Andreas,
> -----Original Message-----
> From: Andreas Färber <[email protected]>
> Sent: Friday, May 31, 2019 7:15 PM
>
> Hi Laurentiu,
>
> Am 30.05.19 um 16:19 schrieb [email protected]:
> > 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
On 31/05/2019 17:33, Christoph Hellwig wrote:
> On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote:
>> From: [email protected]
>> 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.
>
> The thing needs to be completely redone as it abuses parts of the
> iommu API in a completely unacceptable way.
`git grep iommu_iova_to_phys drivers/{crypto,gpu,net}`
:(
I guess one alternative is for the offending drivers to maintain their
own lookup tables of mapped DMA addresses - I think at least some of
these things allow storing some kind of token in a descriptor, which
even if it's not big enough for a virtual address might be sufficient
for an index.
Robin.
Hello Laurentiu,
Am 31.05.19 um 18:46 schrieb Laurentiu Tudor:
>> -----Original Message-----
>> From: Andreas Färber <[email protected]>
>> Sent: Friday, May 31, 2019 7:15 PM
>>
>> Hi Laurentiu,
>>
>> Am 30.05.19 um 16:19 schrieb [email protected]:
>>> 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!
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
On Fri, May 31, 2019 at 06:03:30PM +0100, Robin Murphy wrote:
> > The thing needs to be completely redone as it abuses parts of the
> > iommu API in a completely unacceptable way.
>
> `git grep iommu_iova_to_phys drivers/{crypto,gpu,net}`
>
> :(
>
> I guess one alternative is for the offending drivers to maintain their own
> lookup tables of mapped DMA addresses - I think at least some of these
> things allow storing some kind of token in a descriptor, which even if it's
> not big enough for a virtual address might be sufficient for an index.
Well, we'll at least need DMA API wrappers that work on the dma addr
only and hide this madness underneath. And then tell if an given device
supports this and fail the probe otherwise.
> -----Original Message-----
> From: Andreas Färber <[email protected]>
> 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 <[email protected]>
> >> Sent: Friday, May 31, 2019 7:15 PM
> >>
> >> Hi Laurentiu,
> >>
> >> Am 30.05.19 um 16:19 schrieb [email protected]:
> >>> 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
On 31/05/2019 18:08, Christoph Hellwig wrote:
> On Fri, May 31, 2019 at 06:03:30PM +0100, Robin Murphy wrote:
>>> The thing needs to be completely redone as it abuses parts of the
>>> iommu API in a completely unacceptable way.
>>
>> `git grep iommu_iova_to_phys drivers/{crypto,gpu,net}`
>>
>> :(
>>
>> I guess one alternative is for the offending drivers to maintain their own
>> lookup tables of mapped DMA addresses - I think at least some of these
>> things allow storing some kind of token in a descriptor, which even if it's
>> not big enough for a virtual address might be sufficient for an index.
>
> Well, we'll at least need DMA API wrappers that work on the dma addr
> only and hide this madness underneath. And then tell if an given device
> supports this and fail the probe otherwise.
Bleh, I'm certainly not keen on formalising any kind of
dma_to_phys()/dma_to_virt() interface for this. Or are you just
proposing something like dma_unmap_sorry_sir_the_dog_ate_my_homework()
for drivers which have 'lost' the original VA they mapped?
Robin.
On Fri, May 31, 2019 at 06:45:00PM +0100, Robin Murphy wrote:
> Bleh, I'm certainly not keen on formalising any kind of
> dma_to_phys()/dma_to_virt() interface for this. Or are you just proposing
> something like dma_unmap_sorry_sir_the_dog_ate_my_homework() for drivers
> which have 'lost' the original VA they mapped?
Yes, I guess we need that in some form. I've heard a report the IBM
emca ethernet driver has the same issue, and any SOC with it this
totally blows up dma-debug as they just never properly unmap.
Am 31.05.19 um 19:32 schrieb Laurentiu Tudor:
>> -----Original Message-----
>> From: Andreas Färber <[email protected]>
>> 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 <[email protected]>
>>>> Sent: Friday, May 31, 2019 7:15 PM
>>>>
>>>> Hi Laurentiu,
>>>>
>>>> Am 30.05.19 um 16:19 schrieb [email protected]:
>>>>> 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.
In short, customers rarely run master branch. Kindly have your
colleagues explain stable branches to you in details.
With Fixes header I was referring to the syntax explained here:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
> My plan was to share the kernel dts patches sometime after this series
> makes it through.
That's fine. What I'm warning you is that seemingly your DT patches,
once in one of your LSDK U-Boot releases, will cause a regression for
distros like our SLES 15 SP1 unless these prereq kernel patches get
applied on the respective stable branches. Which will not happen
automatically unless you as patch author take the appropriate action
before they get merged.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)