[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56698b89-756a-ec89-787c-d08351abf7f0@linux.intel.com>
Date: Tue, 3 Jun 2025 10:15:26 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: "Nirujogi, Pratap" <pnirujog@....com>
cc: Pratap Nirujogi <pratap.nirujogi@....com>, rdunlap@...radead.org,
Hans de Goede <hdegoede@...hat.com>, sfr@...b.auug.org.au,
linux-next@...r.kernel.org, platform-driver-x86@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, benjamin.chan@....com, bin.du@....com,
gjorgji.rosikopulos@....com, king.li@....com, dantony@....com
Subject: Re: [PATCH 3/3] platform/x86: Use i2c adapter name to fix build
errors
On Mon, 2 Jun 2025, Nirujogi, Pratap wrote:
> Hi Ilpo,
>
> On 5/31/2025 1:11 AM, Ilpo Järvinen wrote:
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Fri, 30 May 2025, Pratap Nirujogi wrote:
> >
> > > Use 'adapater->name' inplace of 'adapter->owner->name' to fix build issues
> > > when CONFIG_MODULES is not defined.
> > >
> > > Fixes: 90b85567e457 ("platform/x86: Add AMD ISP platform config for
> > > OV05C10")
> >
> > This is the which should have this Fixes tag, the other commits should not
> > have it as they're not really the fix (but this change just depends on
> > them, but since stable is not in picture yet for this driver we don't
> > need to indicate even those deps).
> >
> Thank you, I will take care of keeping the Fixes tag only in the x86/platform
> driver patch and will remove in the other two i2c driver patches.
>
> Sorry I think I'm not completely clear on this statement "we don't need to
> indicate even those deps" - Am I good if I submit the same patch series
> removing the Fixes tag from the two i2c driver patches? Or Is it about
> submitting the i2c patches independently from x86/platform, instead of keeping
> all the 3 patches in a single series. Can you please help to clarify?
Just remove the other fixes tags. Those changes don't really "fix" the
problem but lay groundwork for the last patch.
(If this would be going to stable, which it isn't because the driver is
not yet in any stable kernels, you'd have to add Cc: <stable@...r.kernel.org>
to all dependencies within the series and the fix and the Fixes tag
would still be in the last change only.)
The series should be applied as whole, either by me or the i2c
maintainers once it's ready.
--
i.
> > > Reported-by: Randy Dunlap <rdunlap@...radead.org>
> > > Link:
> > > https://lore.kernel.org/all/04577a46-9add-420c-b181-29bad582026d@infradead.org
> > > Signed-off-by: Pratap Nirujogi <pratap.nirujogi@....com>
> > > ---
> > > drivers/platform/x86/amd/amd_isp4.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/platform/x86/amd/amd_isp4.c
> > > b/drivers/platform/x86/amd/amd_isp4.c
> > > index 0cc01441bcbb..80b57b58621a 100644
> > > --- a/drivers/platform/x86/amd/amd_isp4.c
> > > +++ b/drivers/platform/x86/amd/amd_isp4.c
> > > @@ -151,7 +151,7 @@ MODULE_DEVICE_TABLE(acpi, amdisp_sensor_ids);
> > >
> > > static inline bool is_isp_i2c_adapter(struct i2c_adapter *adap)
> > > {
> > > - return !strcmp(adap->owner->name, "i2c_designware_amdisp");
> > > + return !strcmp(adap->name, "AMDISP DesignWare I2C adapter");
> >
> > Since both are in-kernel code, share that name through a define in some
> > header.
> >
> sure, I will find the header file that can be used to add the adap->name
> definition.
>
> Thanks,
> Pratap
>
> > --
> > i.
> >
>
Powered by blists - more mailing lists