[PATCH] iommu/mediatek: Remove a unnecessary checking for larbid

AngeloGioacchino Del Regno angelogioacchino.delregno at collabora.com
Wed Jul 5 01:31:57 PDT 2023


Il 05/07/23 10:26, Robin Murphy ha scritto:
> On 2023-07-05 07:49, Yong Wu (吴勇) wrote:
>> On Tue, 2023-07-04 at 14:19 +0200, AngeloGioacchino Del Regno wrote:
>>>
>>> External email : Please do not click links or open attachments until
>>> you have verified the sender or the content.
>>>   Il 04/07/23 13:56, Yong Wu ha scritto:
>>>> Fix a coverity issue:
>>>>
>>>>>> assignment: Assigning: larbid = (fwspec->ids[0] >> 5) & 0x1fU.
>>>> larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
>>>>>> between: At condition larbid >= 32U, the value of larbid must be
>>> between
>>>>>> 0 and 31.
>>>>>> dead_error_condition: The condition larbid >= 32U cannot be true.
>>>> if (larbid >= MTK_LARB_NR_MAX)
>>>>>> CID 11306470 (#1 of 1): Logically dead code (DEADCODE)
>>>>>> dead_error_line: Execution cannot reach this statement:
>>>>>> return ERR_PTR(-22L);
>>>>           return ERR_PTR(-EINVAL);
>>>>
>>>> The checking "if (larbid >= MTK_LARB_NR_MAX)" is unnecessary.
>>>>
>>>
>>> I agree with the coverity tool in that after the transformation
>>> (going through
>>> the definition of MTK_M4U_TO_LARB) the check is pointless, but I
>>> think that the
>>> right fix here is to check for validity of fwspec->ids[0] instead of
>>> simply
>>> removing validation.
>>>
>>> Having no validation after mtk_iommu_probe_device() is fine, but
>>> that's
>>> because we assume that *this* function performs all validation steps.
>>
>> There already is validation code at the point later in this function.
>>
>> "if (!larbdev) return ERR_PTR(-EINVAL);" //if the larbid is invalid.
>>
>> This patch just removes a deadcode.
> 
> Right, if the fwspec value was out of range then the truncated value might happen 
> to map to a valid LARB, but then the fwspec could equally have an in-range value 
> for a valid (but incorrect) LARB; in general a driver can't validate the overall 
> correctness of data from the DT (and if it could, that data wouldn't need to be in 
> the DT anyway).
> 
>  From the history, the intent of this check doesn't appear to have been anything 
> other than protecting the dereference of the data->larb_imu array, and it's never 
> had any functional effect, so we don't lose anything by removing it. FWIW,
> 
> Reviewed-by: Robin Murphy <robin.murphy at arm.com>
> 

Yong, you're right. My bad for not noticing the later validation code.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>

> Cheers,
> Robin.
> 
>>
>>>
>>> Regards,
>>> Angelo
>>>
>>>> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
>>>> ---
>>>> Rebase on v6.4-rc1.
>>>> ---
>>>>    drivers/iommu/mtk_iommu.c | 3 ---
>>>>    1 file changed, 3 deletions(-)
>>>>
>>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>>> index aecc7d154f28..67caa90b481b 100644
>>>> --- a/drivers/iommu/mtk_iommu.c
>>>> +++ b/drivers/iommu/mtk_iommu.c
>>>> @@ -838,9 +838,6 @@ static struct iommu_device
>>> *mtk_iommu_probe_device(struct device *dev)
>>>>     * All the ports in each a device should be in the same larbs.
>>>>     */
>>>>    larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
>>>> -if (larbid >= MTK_LARB_NR_MAX)
>>>> -return ERR_PTR(-EINVAL);
>>>> -
>>>>    for (i = 1; i < fwspec->num_ids; i++) {
>>>>    larbidx = MTK_M4U_TO_LARB(fwspec->ids[i]);
>>>>    if (larbid != larbidx) {
>>>
>>>





More information about the linux-arm-kernel mailing list