Re: [PATCH 2/7] of: factor out of_map_id() code
From: Vijayanand Jitta
Date: Thu Feb 05 2026 - 03:11:30 EST
On 2/4/2026 6:41 AM, Dmitry Baryshkov wrote:
> On Tue, Feb 03, 2026 at 03:43:58PM +0530, Vijayanand Jitta wrote:
>>
>>
>> On 2/2/2026 8:22 PM, Bryan O'Donoghue wrote:
>>> On 26/01/2026 12:25, Vikash Garodia wrote:
>>>> From: Charan Teja Kalla <charan.kalla@xxxxxxxxxxxxxxxx>
>>>
>>> This commit message is confusing and inaccurate.
>>>
>>> First up, you're not factoring _out_ of_map_id() - factor out of_map_id() means to remove of_map_id() - you are refactoring of_map_id().
>>>
>>> Your patch title should be something like "refactor of_map_id() to prepare for mapping of multiple IDs to a single device"
>>>
>>
>> Sure, will update the commit.
>>
>>>> Linux interprets multiple mappings for the same input ID as a set of
>>>> equivalent choices to pick one. There exists usecases where these set
>>>> must be maintained in parallel, ex: on ARM, a dynamically created child
>>>> device(s) is referencing multiple input id's in parent iommu-map.
>>>>
>>>> Factor out the code where multiple mappings needs to be maintained in
>>>> parallel can be achieved through callback from this factored out code.
>>>
>>> Which callback ? There is no ->function(pointer, here...); ?!
>>>
>>> Just make some plain and straightforward statements about what you are doing and why. There's no need to resort to dissertation-speak.
>>>
>>
>> The callback in introduced in patch 2 of this series. will update the commit descripition as suggested.
>
> I think, the callback was NAKed already.
>
>
I'll remove the callback and update change such that all entries of iommu-map are always scanned.
This would handle the video usecase ( i.e; same input id's mapping to different SIDs ) and in other
cases it would result in few additional scans in iommu-map compared to existing implementation (where
it just returns after first input id match) , does this look fine ?
Thanks,
Vijay