Re: [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@xxxxxxxx>
> > > Acked-by: Mark Brown <broonie@xxxxxxxxxx>
> > > ---
> > >
> > > 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