| Message ID | 20190530141951.6704-1-laurentiu.tudor@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Prerequisites for NXP LS104xA SMMU enablement | expand |
From: laurentiu.tudor@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.
On Thu, May 30, 2019 at 5:09 PM David Miller <davem@davemloft.net> wrote: > > From: laurentiu.tudor@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. 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 <davem@davemloft.net> > Sent: Friday, May 31, 2019 1:09 AM > > From: laurentiu.tudor@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
Hi Laurentiu, Am 30.05.19 um 16:19 schrieb laurentiu.tudor@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? Regards, Andreas
On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote: > From: laurentiu.tudor@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. 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 <afaerber@suse.de> > Sent: Friday, May 31, 2019 7:15 PM > > Hi Laurentiu, > > Am 30.05.19 um 16:19 schrieb laurentiu.tudor@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
On 31/05/2019 17:33, Christoph Hellwig wrote: > On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote: >> From: laurentiu.tudor@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. > > 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 <afaerber@suse.de> >> Sent: Friday, May 31, 2019 7:15 PM >> >> Hi Laurentiu, >> >> Am 30.05.19 um 16:19 schrieb laurentiu.tudor@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! Regards, Andreas
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 <afaerber@suse.de> > 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 <afaerber@suse.de> > >> Sent: Friday, May 31, 2019 7:15 PM > >> > >> Hi Laurentiu, > >> > >> Am 30.05.19 um 16:19 schrieb laurentiu.tudor@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
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 <afaerber@suse.de> >> 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 <afaerber@suse.de> >>>> Sent: Friday, May 31, 2019 7:15 PM >>>> >>>> Hi Laurentiu, >>>> >>>> Am 30.05.19 um 16:19 schrieb laurentiu.tudor@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. 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
From: Laurentiu Tudor <laurentiu.tudor@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. 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(-)