Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
Am 31.05.19 um 19:32 schrieb Laurentiu Tudor: >> -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. 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)
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
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.
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
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.
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 0/6] Prerequisites for NXP LS104xA SMMU enablement
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.
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
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! Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
On 31/05/2019 17:33, Christoph Hellwig wrote: On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote: 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. 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.
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
On Thu, May 30, 2019 at 03:08:44PM -0700, David Miller wrote: > 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. The thing needs to be completely redone as it abuses parts of the iommu API in a completely unacceptable way.
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
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? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
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
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
On Thu, May 30, 2019 at 5:09 PM David Miller wrote: > > 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. 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
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
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.