As stated in [1], dma_set_mask() with a 64-bit mask never fails if
dev->dma_mask is non-NULL.
So, if it fails, the 32 bits case will also fail for the same reason.
Simplify code and remove some dead code accordingly.
[1]: https://lore.kernel.org/linux-kernel/[email protected]/#t
Signed-off-by: Christophe JAILLET <[email protected]>
---
v2: have the subject and updated driver match
---
drivers/dma/qcom/hidma.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 65d054bb11aa..51587cf8196b 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -838,9 +838,7 @@ static int hidma_probe(struct platform_device *pdev)
rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (rc) {
dev_warn(&pdev->dev, "unable to set coherent mask to 64");
- rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
- if (rc)
- goto dmafree;
+ goto dmafree;
}
dmadev->lldev = hidma_ll_init(dmadev->ddev.dev,
--
2.32.0
On 1/15/2022 2:35 AM, Christophe JAILLET wrote:
> As stated in [1], dma_set_mask() with a 64-bit mask never fails if
> dev->dma_mask is non-NULL.
> So, if it fails, the 32 bits case will also fail for the same reason.
>
> Simplify code and remove some dead code accordingly.
>
> [1]: https://lore.kernel.org/linux-kernel/[email protected]/#t
>
Can we please document this?
Usual practice was to try allocating 64 bit DMA if possible and fallback
to 32 bits.
> Signed-off-by: Christophe JAILLET <[email protected]>
> ---
> v2: have the subject and updated driver match
> ---
> drivers/dma/qcom/hidma.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index 65d054bb11aa..51587cf8196b 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -838,9 +838,7 @@ static int hidma_probe(struct platform_device *pdev)
> rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> if (rc) {
> dev_warn(&pdev->dev, "unable to set coherent mask to 64");
> - rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> - if (rc)
> - goto dmafree;
> + goto dmafree;
> }
>
> dmadev->lldev = hidma_ll_init(dmadev->ddev.dev,
Le 22/01/2022 à 19:05, Sinan Kaya a écrit :
> On 1/15/2022 2:35 AM, Christophe JAILLET wrote:
>> As stated in [1], dma_set_mask() with a 64-bit mask never fails if
>> dev->dma_mask is non-NULL.
>> So, if it fails, the 32 bits case will also fail for the same reason.
>>
>> Simplify code and remove some dead code accordingly.
>>
>> [1]:
>> https://lore.kernel.org/linux-kernel/[email protected]/#t
>>
>
> Can we please document this?
Hi, the patch has been applied, but [1] is sometimes given as an
explanation link.
CJ
[1]:
https://lists.linuxfoundation.org/pipermail/iommu/2019-February/033674.html
>
> Usual practice was to try allocating 64 bit DMA if possible and fallback
> to 32 bits.
>
>> Signed-off-by: Christophe JAILLET <[email protected]>
>> ---
>> v2: have the subject and updated driver match
>> ---
>> drivers/dma/qcom/hidma.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
>> index 65d054bb11aa..51587cf8196b 100644
>> --- a/drivers/dma/qcom/hidma.c
>> +++ b/drivers/dma/qcom/hidma.c
>> @@ -838,9 +838,7 @@ static int hidma_probe(struct platform_device *pdev)
>> rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> if (rc) {
>> dev_warn(&pdev->dev, "unable to set coherent mask to 64");
>> - rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
>> - if (rc)
>> - goto dmafree;
>> + goto dmafree;
>> }
>> dmadev->lldev = hidma_ll_init(dmadev->ddev.dev,
>
>
On 3/19/2022 2:24 AM, Christophe JAILLET wrote:
> Le 22/01/2022 à 19:05, Sinan Kaya a écrit :
>> On 1/15/2022 2:35 AM, Christophe JAILLET wrote:
>>> As stated in [1], dma_set_mask() with a 64-bit mask never fails if
>>> dev->dma_mask is non-NULL.
>>> So, if it fails, the 32 bits case will also fail for the same reason.
>>>
>>> Simplify code and remove some dead code accordingly.
>>>
>>> [1]:
>>> https://lore.kernel.org/linux-kernel/[email protected]/#t
>>>
>>
>> Can we please document this?
>
> Hi, the patch has been applied, but [1] is sometimes given as an
> explanation link.
>
> CJ
>
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/iommu/2019-February/033674.html
Sounds good, please carry my
Acked-By: Sinan Kaya <[email protected]>