[PATCH v2 2/3] iommu/sound: Use component_match_add_of helper

[Robin Murphy]

On 03/01/2023 4:15 pm, Maxime Ripard wrote:
> Hi Robin,
> 
> On Tue, Jan 03, 2023 at 01:01:07PM +0000, Robin Murphy wrote:
>> Hi Sean,
>>
>> On 22/12/2022 11:37 pm, Sean Anderson wrote:
>>> Convert users of component_match_add_release with component_release_of
>>> and component_compare_of to component_match_add_of.
>>>
>>> Signed-off-by: Sean Anderson <sean.anderson at seco.com>
>>> Acked-by: Mark Brown <broonie at kernel.org>
>>> ---
>>>
>>> Changes in v2:
>>> - Split off from helper addition
>>>
>>>    drivers/iommu/mtk_iommu.c    | 3 +--
>>>    drivers/iommu/mtk_iommu_v1.c | 3 +--
>>>    sound/soc/codecs/wcd938x.c   | 6 ++----
>>>    3 files changed, 4 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index 2ab2ecfe01f8..483b7a9e4410 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -1079,8 +1079,7 @@ static int mtk_iommu_mm_dts_parse(struct device *dev, struct component_match **m
>>>    		}
>>>    		data->larb_imu[id].dev = &plarbdev->dev;
>>> -		component_match_add_release(dev, match, component_release_of,
>>> -					    component_compare_of, larbnode);
>>> +		component_match_add_of(dev, match, larbnode);
>>
>> I've long since given up trying to make sense of how the DRM tree works, but
>> the conflicting change is definitely already in mainline:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=b5765a1b44bea9dfcae69c53ffeb4c689d0922a7
> 
> As far as I can see, that patch doesn't affect DRM at all, and the
> commit you pointed to doesn't either, nor has it been merged through the
> DRM tree.

Right it doesn't affect DRM, and was merged via the IOMMU tree, but it 
does affect *this* patch, which Sean has based on a drm-next branch that 
seemingly still wasn't up to date with 6.2-rc1 at the time.

Since v2 had already been posted, it seemed like a bright idea to 
comment here to clarify that it was still relevant, rather than bumping 
the old thread to reply directly. Apologies for any confusion.

In practical terms I think it's merely a case of dropping this hunk; the 
other one in mtk_iommu_v1.c looks fine to me.

Cheers,
Robin.

> Can you expand a bit on how we're involved in this, what we should
> clarify or help with?
> 
> Maxime