* [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes @ 2020-09-29 6:13 Nicolin Chen 2020-09-29 6:13 ` [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get Nicolin Chen ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Nicolin Chen @ 2020-09-29 6:13 UTC (permalink / raw) To: thierry.reding, joro Cc: linux-kernel, iommu, jonathanh, hch, linux-tegra, digetx Two followup patches for tegra-smmu: PATCH-1 is a clean-up patch for the recently applied SWGROUP change. PATCH-2 fixes a potential race condition Changelog v3->v4: * PATCH-2: Fixed typo in subject v2->v3: * PATCH-2: renamed "err_unlock" to "unlock" v1->v2: * Separated first two changs of V1 so they may get applied first, since the other three changes need some extra time to finalize. Nicolin Chen (2): iommu/tegra-smmu: Unwrap tegra_smmu_group_get iommu/tegra-smmu: Expand mutex protection range drivers/iommu/tegra-smmu.c | 53 ++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 28 deletions(-) -- 2.17.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get 2020-09-29 6:13 [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes Nicolin Chen @ 2020-09-29 6:13 ` Nicolin Chen 2020-09-29 17:41 ` Dmitry Osipenko 2020-10-08 9:55 ` Thierry Reding 2020-09-29 6:13 ` [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range Nicolin Chen 2020-11-07 8:35 ` [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes Nicolin Chen 2 siblings, 2 replies; 11+ messages in thread From: Nicolin Chen @ 2020-09-29 6:13 UTC (permalink / raw) To: thierry.reding, joro Cc: linux-kernel, iommu, jonathanh, hch, linux-tegra, digetx The tegra_smmu_group_get was added to group devices in different SWGROUPs and it'd return a NULL group pointer upon a mismatch at tegra_smmu_find_group(), so for most of clients/devices, it very likely would mismatch and need a fallback generic_device_group(). But now tegra_smmu_group_get handles devices in same SWGROUP too, which means that it would allocate a group for every new SWGROUP or would directly return an existing one upon matching a SWGROUP, i.e. any device will go through this function. So possibility of having a NULL group pointer in device_group() is upon failure of either devm_kzalloc() or iommu_group_alloc(). In either case, calling generic_device_group() no longer makes a sense. Especially for devm_kzalloc() failing case, it'd cause a problem if it fails at devm_kzalloc() yet succeeds at a fallback generic_device_group(), because it does not create a group->list for other devices to match. This patch simply unwraps the function to clean it up. Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> --- Changelog v2->v4: * N/A v1->v2: * Changed type of swgroup to "unsigned int", following Thierry's commnets. drivers/iommu/tegra-smmu.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c index 0becdbfea306..ec4c9dafff95 100644 --- a/drivers/iommu/tegra-smmu.c +++ b/drivers/iommu/tegra-smmu.c @@ -903,10 +903,12 @@ static void tegra_smmu_group_release(void *iommu_data) mutex_unlock(&smmu->lock); } -static struct iommu_group *tegra_smmu_group_get(struct tegra_smmu *smmu, - unsigned int swgroup) +static struct iommu_group *tegra_smmu_device_group(struct device *dev) { + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); + struct tegra_smmu *smmu = dev_iommu_priv_get(dev); const struct tegra_smmu_group_soc *soc; + unsigned int swgroup = fwspec->ids[0]; struct tegra_smmu_group *group; struct iommu_group *grp; @@ -950,19 +952,6 @@ static struct iommu_group *tegra_smmu_group_get(struct tegra_smmu *smmu, return group->group; } -static struct iommu_group *tegra_smmu_device_group(struct device *dev) -{ - struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); - struct tegra_smmu *smmu = dev_iommu_priv_get(dev); - struct iommu_group *group; - - group = tegra_smmu_group_get(smmu, fwspec->ids[0]); - if (!group) - group = generic_device_group(dev); - - return group; -} - static int tegra_smmu_of_xlate(struct device *dev, struct of_phandle_args *args) { -- 2.17.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get 2020-09-29 6:13 ` [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get Nicolin Chen @ 2020-09-29 17:41 ` Dmitry Osipenko 2020-10-03 14:27 ` Dmitry Osipenko 2020-10-08 9:55 ` Thierry Reding 1 sibling, 1 reply; 11+ messages in thread From: Dmitry Osipenko @ 2020-09-29 17:41 UTC (permalink / raw) To: Nicolin Chen, thierry.reding, joro Cc: linux-kernel, iommu, jonathanh, hch, linux-tegra 29.09.2020 09:13, Nicolin Chen пишет: > The tegra_smmu_group_get was added to group devices in different > SWGROUPs and it'd return a NULL group pointer upon a mismatch at > tegra_smmu_find_group(), so for most of clients/devices, it very > likely would mismatch and need a fallback generic_device_group(). > > But now tegra_smmu_group_get handles devices in same SWGROUP too, > which means that it would allocate a group for every new SWGROUP > or would directly return an existing one upon matching a SWGROUP, > i.e. any device will go through this function. > > So possibility of having a NULL group pointer in device_group() > is upon failure of either devm_kzalloc() or iommu_group_alloc(). > In either case, calling generic_device_group() no longer makes a > sense. Especially for devm_kzalloc() failing case, it'd cause a > problem if it fails at devm_kzalloc() yet succeeds at a fallback > generic_device_group(), because it does not create a group->list > for other devices to match. > > This patch simply unwraps the function to clean it up. > > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> > --- Reviewed-by: Dmitry Osipenko <digetx@gmail.com> _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get 2020-09-29 17:41 ` Dmitry Osipenko @ 2020-10-03 14:27 ` Dmitry Osipenko 0 siblings, 0 replies; 11+ messages in thread From: Dmitry Osipenko @ 2020-10-03 14:27 UTC (permalink / raw) To: Nicolin Chen, thierry.reding, joro Cc: linux-kernel, iommu, jonathanh, hch, linux-tegra 29.09.2020 20:41, Dmitry Osipenko пишет: > 29.09.2020 09:13, Nicolin Chen пишет: >> The tegra_smmu_group_get was added to group devices in different >> SWGROUPs and it'd return a NULL group pointer upon a mismatch at >> tegra_smmu_find_group(), so for most of clients/devices, it very >> likely would mismatch and need a fallback generic_device_group(). >> >> But now tegra_smmu_group_get handles devices in same SWGROUP too, >> which means that it would allocate a group for every new SWGROUP >> or would directly return an existing one upon matching a SWGROUP, >> i.e. any device will go through this function. >> >> So possibility of having a NULL group pointer in device_group() >> is upon failure of either devm_kzalloc() or iommu_group_alloc(). >> In either case, calling generic_device_group() no longer makes a >> sense. Especially for devm_kzalloc() failing case, it'd cause a >> problem if it fails at devm_kzalloc() yet succeeds at a fallback >> generic_device_group(), because it does not create a group->list >> for other devices to match. >> >> This patch simply unwraps the function to clean it up. >> >> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> >> --- > > Reviewed-by: Dmitry Osipenko <digetx@gmail.com> > Tested-by: Dmitry Osipenko <digetx@gmail.com> _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get 2020-09-29 6:13 ` [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get Nicolin Chen 2020-09-29 17:41 ` Dmitry Osipenko @ 2020-10-08 9:55 ` Thierry Reding 1 sibling, 0 replies; 11+ messages in thread From: Thierry Reding @ 2020-10-08 9:55 UTC (permalink / raw) To: Nicolin Chen; +Cc: linux-kernel, jonathanh, hch, iommu, linux-tegra, digetx [-- Attachment #1.1: Type: text/plain, Size: 1462 bytes --] On Mon, Sep 28, 2020 at 11:13:24PM -0700, Nicolin Chen wrote: > The tegra_smmu_group_get was added to group devices in different > SWGROUPs and it'd return a NULL group pointer upon a mismatch at > tegra_smmu_find_group(), so for most of clients/devices, it very > likely would mismatch and need a fallback generic_device_group(). > > But now tegra_smmu_group_get handles devices in same SWGROUP too, > which means that it would allocate a group for every new SWGROUP > or would directly return an existing one upon matching a SWGROUP, > i.e. any device will go through this function. > > So possibility of having a NULL group pointer in device_group() > is upon failure of either devm_kzalloc() or iommu_group_alloc(). > In either case, calling generic_device_group() no longer makes a > sense. Especially for devm_kzalloc() failing case, it'd cause a > problem if it fails at devm_kzalloc() yet succeeds at a fallback > generic_device_group(), because it does not create a group->list > for other devices to match. > > This patch simply unwraps the function to clean it up. > > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> > --- > > Changelog > v2->v4: > * N/A > v1->v2: > * Changed type of swgroup to "unsigned int", following Thierry's > commnets. > > drivers/iommu/tegra-smmu.c | 19 ++++--------------- > 1 file changed, 4 insertions(+), 15 deletions(-) Acked-by: Thierry Reding <treding@nvidia.com> [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range 2020-09-29 6:13 [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes Nicolin Chen 2020-09-29 6:13 ` [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get Nicolin Chen @ 2020-09-29 6:13 ` Nicolin Chen 2020-09-29 17:42 ` Dmitry Osipenko 2020-10-08 9:56 ` Thierry Reding 2020-11-07 8:35 ` [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes Nicolin Chen 2 siblings, 2 replies; 11+ messages in thread From: Nicolin Chen @ 2020-09-29 6:13 UTC (permalink / raw) To: thierry.reding, joro Cc: linux-kernel, iommu, jonathanh, hch, linux-tegra, digetx This is used to protect potential race condition at use_count. since probes of client drivers, calling attach_dev(), may run concurrently. Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> --- Changelog v3->v4: * Fixed typo "Expend" => "Expand" v2->v3: * Renamed label "err_unlock" to "unlock" v1->v2: * N/A drivers/iommu/tegra-smmu.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c index ec4c9dafff95..6a3ecc334481 100644 --- a/drivers/iommu/tegra-smmu.c +++ b/drivers/iommu/tegra-smmu.c @@ -256,26 +256,19 @@ static int tegra_smmu_alloc_asid(struct tegra_smmu *smmu, unsigned int *idp) { unsigned long id; - mutex_lock(&smmu->lock); - id = find_first_zero_bit(smmu->asids, smmu->soc->num_asids); - if (id >= smmu->soc->num_asids) { - mutex_unlock(&smmu->lock); + if (id >= smmu->soc->num_asids) return -ENOSPC; - } set_bit(id, smmu->asids); *idp = id; - mutex_unlock(&smmu->lock); return 0; } static void tegra_smmu_free_asid(struct tegra_smmu *smmu, unsigned int id) { - mutex_lock(&smmu->lock); clear_bit(id, smmu->asids); - mutex_unlock(&smmu->lock); } static bool tegra_smmu_capable(enum iommu_cap cap) @@ -420,17 +413,21 @@ static int tegra_smmu_as_prepare(struct tegra_smmu *smmu, struct tegra_smmu_as *as) { u32 value; - int err; + int err = 0; + + mutex_lock(&smmu->lock); if (as->use_count > 0) { as->use_count++; - return 0; + goto unlock; } as->pd_dma = dma_map_page(smmu->dev, as->pd, 0, SMMU_SIZE_PD, DMA_TO_DEVICE); - if (dma_mapping_error(smmu->dev, as->pd_dma)) - return -ENOMEM; + if (dma_mapping_error(smmu->dev, as->pd_dma)) { + err = -ENOMEM; + goto unlock; + } /* We can't handle 64-bit DMA addresses */ if (!smmu_dma_addr_valid(smmu, as->pd_dma)) { @@ -453,24 +450,35 @@ static int tegra_smmu_as_prepare(struct tegra_smmu *smmu, as->smmu = smmu; as->use_count++; + mutex_unlock(&smmu->lock); + return 0; err_unmap: dma_unmap_page(smmu->dev, as->pd_dma, SMMU_SIZE_PD, DMA_TO_DEVICE); +unlock: + mutex_unlock(&smmu->lock); + return err; } static void tegra_smmu_as_unprepare(struct tegra_smmu *smmu, struct tegra_smmu_as *as) { - if (--as->use_count > 0) + mutex_lock(&smmu->lock); + + if (--as->use_count > 0) { + mutex_unlock(&smmu->lock); return; + } tegra_smmu_free_asid(smmu, as->id); dma_unmap_page(smmu->dev, as->pd_dma, SMMU_SIZE_PD, DMA_TO_DEVICE); as->smmu = NULL; + + mutex_unlock(&smmu->lock); } static int tegra_smmu_attach_dev(struct iommu_domain *domain, -- 2.17.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range 2020-09-29 6:13 ` [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range Nicolin Chen @ 2020-09-29 17:42 ` Dmitry Osipenko 2020-09-30 0:31 ` Nicolin Chen 2020-10-03 14:28 ` Dmitry Osipenko 2020-10-08 9:56 ` Thierry Reding 1 sibling, 2 replies; 11+ messages in thread From: Dmitry Osipenko @ 2020-09-29 17:42 UTC (permalink / raw) To: Nicolin Chen, thierry.reding, joro Cc: linux-kernel, iommu, jonathanh, hch, linux-tegra 29.09.2020 09:13, Nicolin Chen пишет: > This is used to protect potential race condition at use_count. > since probes of client drivers, calling attach_dev(), may run > concurrently. > > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> > --- It's always better not to mix success and error code paths in order to keep code readable, but not a big deal in the case of this particular patch since the changed code is quite simple. Please try to avoid doing this in the future patches. Also, please note that in general it's better to use locked/unlocked versions for the functions like it's already done for tegra_smmu_map/unmap, this will remove the need to maintain lockings in the code. The code touched by this patch doesn't have complicated code paths, so it's good enough to me. Reviewed-by: Dmitry Osipenko <digetx@gmail.com> _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range 2020-09-29 17:42 ` Dmitry Osipenko @ 2020-09-30 0:31 ` Nicolin Chen 2020-10-03 14:28 ` Dmitry Osipenko 1 sibling, 0 replies; 11+ messages in thread From: Nicolin Chen @ 2020-09-30 0:31 UTC (permalink / raw) To: Dmitry Osipenko Cc: linux-kernel, iommu, jonathanh, hch, thierry.reding, linux-tegra On Tue, Sep 29, 2020 at 08:42:52PM +0300, Dmitry Osipenko wrote: > 29.09.2020 09:13, Nicolin Chen пишет: > > This is used to protect potential race condition at use_count. > > since probes of client drivers, calling attach_dev(), may run > > concurrently. > > > > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> > > --- > > It's always better not to mix success and error code paths in order to > keep code readable, but not a big deal in the case of this particular > patch since the changed code is quite simple. Please try to avoid doing > this in the future patches. > > Also, please note that in general it's better to use locked/unlocked > versions for the functions like it's already done for > tegra_smmu_map/unmap, this will remove the need to maintain lockings in > the code. The code touched by this patch doesn't have complicated code > paths, so it's good enough to me. > > Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Okay. Thanks for the review! _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range 2020-09-29 17:42 ` Dmitry Osipenko 2020-09-30 0:31 ` Nicolin Chen @ 2020-10-03 14:28 ` Dmitry Osipenko 1 sibling, 0 replies; 11+ messages in thread From: Dmitry Osipenko @ 2020-10-03 14:28 UTC (permalink / raw) To: Nicolin Chen, thierry.reding, joro Cc: linux-kernel, iommu, jonathanh, hch, linux-tegra 29.09.2020 20:42, Dmitry Osipenko пишет: > 29.09.2020 09:13, Nicolin Chen пишет: >> This is used to protect potential race condition at use_count. >> since probes of client drivers, calling attach_dev(), may run >> concurrently. >> >> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> >> --- > > It's always better not to mix success and error code paths in order to > keep code readable, but not a big deal in the case of this particular > patch since the changed code is quite simple. Please try to avoid doing > this in the future patches. > > Also, please note that in general it's better to use locked/unlocked > versions for the functions like it's already done for > tegra_smmu_map/unmap, this will remove the need to maintain lockings in > the code. The code touched by this patch doesn't have complicated code > paths, so it's good enough to me. > > Reviewed-by: Dmitry Osipenko <digetx@gmail.com> > Tested-by: Dmitry Osipenko <digetx@gmail.com> _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range 2020-09-29 6:13 ` [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range Nicolin Chen 2020-09-29 17:42 ` Dmitry Osipenko @ 2020-10-08 9:56 ` Thierry Reding 1 sibling, 0 replies; 11+ messages in thread From: Thierry Reding @ 2020-10-08 9:56 UTC (permalink / raw) To: Nicolin Chen; +Cc: linux-kernel, jonathanh, hch, iommu, linux-tegra, digetx [-- Attachment #1.1: Type: text/plain, Size: 599 bytes --] On Mon, Sep 28, 2020 at 11:13:25PM -0700, Nicolin Chen wrote: > This is used to protect potential race condition at use_count. > since probes of client drivers, calling attach_dev(), may run > concurrently. > > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> > --- > > Changelog > v3->v4: > * Fixed typo "Expend" => "Expand" > v2->v3: > * Renamed label "err_unlock" to "unlock" > v1->v2: > * N/A > > drivers/iommu/tegra-smmu.c | 34 +++++++++++++++++++++------------- > 1 file changed, 21 insertions(+), 13 deletions(-) Acked-by: Thierry Reding <treding@nvidia.com> [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes 2020-09-29 6:13 [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes Nicolin Chen 2020-09-29 6:13 ` [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get Nicolin Chen 2020-09-29 6:13 ` [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range Nicolin Chen @ 2020-11-07 8:35 ` Nicolin Chen 2 siblings, 0 replies; 11+ messages in thread From: Nicolin Chen @ 2020-11-07 8:35 UTC (permalink / raw) To: thierry.reding, joro Cc: linux-kernel, iommu, jonathanh, hch, linux-tegra, digetx On Mon, Sep 28, 2020 at 11:13:23PM -0700, Nicolin Chen wrote: > Two followup patches for tegra-smmu: > PATCH-1 is a clean-up patch for the recently applied SWGROUP change. > PATCH-2 fixes a potential race condition These two changes have Acked-by and Reviewed-by for a month already. Who can apply them? Thanks Nic > Changelog > v3->v4: > * PATCH-2: Fixed typo in subject > v2->v3: > * PATCH-2: renamed "err_unlock" to "unlock" > v1->v2: > * Separated first two changs of V1 so they may get applied first, > since the other three changes need some extra time to finalize. > > Nicolin Chen (2): > iommu/tegra-smmu: Unwrap tegra_smmu_group_get > iommu/tegra-smmu: Expand mutex protection range > > drivers/iommu/tegra-smmu.c | 53 ++++++++++++++++++-------------------- > 1 file changed, 25 insertions(+), 28 deletions(-) > > -- > 2.17.1 > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-11-07 8:47 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-29 6:13 [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes Nicolin Chen 2020-09-29 6:13 ` [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get Nicolin Chen 2020-09-29 17:41 ` Dmitry Osipenko 2020-10-03 14:27 ` Dmitry Osipenko 2020-10-08 9:55 ` Thierry Reding 2020-09-29 6:13 ` [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range Nicolin Chen 2020-09-29 17:42 ` Dmitry Osipenko 2020-09-30 0:31 ` Nicolin Chen 2020-10-03 14:28 ` Dmitry Osipenko 2020-10-08 9:56 ` Thierry Reding 2020-11-07 8:35 ` [PATCH v4 0/2] iommu/tegra-smmu: Two followup changes Nicolin Chen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).