[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zyo84z0DUi-NweEV@smile.fi.intel.com>
Date: Tue, 5 Nov 2024 17:42:27 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Andi Shyti <andi.shyti@...nel.org>
Cc: linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] i2c: busses: Use *-y instead of *-objs in Makefile
On Tue, Nov 05, 2024 at 04:11:37PM +0100, Andi Shyti wrote:
> On Tue, Nov 05, 2024 at 04:56:37PM +0200, Andy Shevchenko wrote:
> > On Tue, Nov 05, 2024 at 03:44:34PM +0100, Andi Shyti wrote:
> > > On Mon, Nov 04, 2024 at 12:39:14PM +0200, Andy Shevchenko wrote:
> > > > *-objs suffix is reserved rather for (user-space) host programs while
> > > > usually *-y suffix is used for kernel drivers (although *-objs works
> > > > for that purpose for now).
> > > >
> > > > Let's correct the old usages of *-objs in Makefiles.
...
> > > > config I2C_AT91_SLAVE_EXPERIMENTAL
> > > > - tristate "Microchip AT91 I2C experimental slave mode"
> > > > + bool "Microchip AT91 I2C experimental slave mode"
> > > > depends on I2C_AT91
> > > > select I2C_SLAVE
> > > > help
> > > > @@ -440,7 +440,7 @@ config I2C_AT91_SLAVE_EXPERIMENTAL
> > > > been tested in a heavy way, help wanted.
> > > > There are known bugs:
> > > > - It can hang, on a SAMA5D4, after several transfers.
> > > > - - There are some mismtaches with a SAMA5D4 as slave and a SAMA5D2 as
> > > > + - There are some mismatches with a SAMA5D4 as slave and a SAMA5D2 as
> > >
> > > Although these changes are related and I'm OK also with the typo
> > > fix, could you please propose here a couple of lines that I can
> > > add to the commit message?
> >
> > Would this work?
> > "While at it, fix an obvious typo in help section of the Kconfig."
>
> works for me.
>
> > Of course, feel free to drop that hunk or request for a new version without it
> > (or split into a separate change), I am fine with all options.
> >
> > Note, bool is essential to for the patch, but can be split as a prerequisite,
> > but without this patch it doesn't really fix match as we never try to build
> > the code when it was =m.
>
> As you wish, you can keep it in three patches or I can keep it
> as it is. I'm not too religious.
>
> If I don't see anything coming I will take this patch as it is.
If you can take it as is (including the above mentioned add-on
to the commit message) it would be the best.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists