From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c@vger.kernel.org, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>
Subject: Re: [PATCH v1 01/40] i2c: qup: Move bus frequency definitions to i2c.h
Date: Tue, 25 Feb 2020 12:47:08 +0200 [thread overview]
Message-ID: <20200225104708.GF10400@smile.fi.intel.com> (raw)
In-Reply-To: <20200225102233.GA3677@ninjato>
On Tue, Feb 25, 2020 at 11:22:33AM +0100, Wolfram Sang wrote:
> On Mon, Feb 24, 2020 at 05:14:51PM +0200, Andy Shevchenko wrote:
> > Move bus frequency definitions to i2c.h for wider use.
> >
> > Cc: Andy Gross <agross@kernel.org>
> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> A cover letter would have been nice so we could discuss the general
> appraoch there. And to read more about the motivation.
Motivation is simple:
- Standardize the (small) set of mostly used bus frequences
- Get rid of repetition of (subset) of above in many drivers
- Reduce amount of potential typos
Let's discuss it here. I don't think new version of this would be good to have
without initial settlement.
> > --- a/include/linux/i2c.h
> > +++ b/include/linux/i2c.h
> > @@ -39,6 +39,13 @@ enum i2c_slave_event;
> > typedef int (*i2c_slave_cb_t)(struct i2c_client *client,
> > enum i2c_slave_event event, u8 *val);
> >
> > +#define HZ_PER_KHZ 1000
>
> Unlike Jarkko, I think such macros help readability when calculating
> frequencies within drivers. However, they shouldn't be local to I2C if
> we agree on them. They should be available Linux-wide. There are some
> other (few) local implementations already.
I aware about that, but I would like to avoid I²C subsystem storming for
another change like this. So, let's consider this as a trampoline when in the
future we will switch entire subsystem to Linux wide header at once.
We have already same/similar definitions in the other drivers and I really
would like to avoid cross subsystem collisions.
> > +/* I2C Frequency Modes */
> > +#define I2C_STANDARD_MODE_FREQ (100 * HZ_PER_KHZ)
> > +#define I2C_FAST_MODE_FREQ (400 * HZ_PER_KHZ)
> > +#define I2C_FAST_MODE_PLUS_FREQ (1000 * HZ_PER_KHZ)
>
> For such a header, I'd prefer the plain number, though. There will be
> enough review to make sure we get it right ;)
No problem. I'm fine with either.
> Furthermore, I'd prefer to
> have 'MAX' in there, e.g. I2C_MAX_STANDARD_MODE_FREQ etc. Just to make
> clear that I2C can have other bus speeds as well.
Works for me.
Btw, what about Vladimir's comment WRT STANDARD -> STD? My personal opinion
that STD is a bit too short.
> And finally, I'd think all driver patches should be squashed into one,
> and all core ones into one etc. Or?
I'm fine with either. For reviewers it would be better I think to see only
their portion. Since I got a lot of tags already I consider I may squash it
together. So, what do you prefer?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-02-25 10:47 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 15:14 [PATCH v1 01/40] i2c: qup: Move bus frequency definitions to i2c.h Andy Shevchenko
2020-02-24 15:14 ` [PATCH v1 02/40] i2c: algo: Use generic definitions for bus frequencies Andy Shevchenko
2020-02-24 15:14 ` [PATCH v1 03/40] i2c: core: " Andy Shevchenko
2020-02-24 16:28 ` Mika Westerberg
2020-02-24 15:14 ` [PATCH v1 04/40] i2c: altera: " Andy Shevchenko
2020-02-25 7:30 ` Jarkko Nikula
2020-02-24 15:14 ` [PATCH v1 05/40] i2c: amd-mp2: " Andy Shevchenko
2020-02-26 17:58 ` Elie Morisse
2020-02-27 5:06 ` Shah, Nehal-bakulchandra
2020-02-24 15:14 ` [PATCH v1 06/40] i2c: aspeed: " Andy Shevchenko
2020-02-26 3:54 ` Brendan Higgins
2020-02-24 15:14 ` [PATCH v1 07/40] i2c: axxia: " Andy Shevchenko
2020-02-24 15:14 ` [PATCH v1 08/40] i2c: bcm-iproc: " Andy Shevchenko
2020-02-24 17:29 ` Scott Branden
2020-02-24 15:14 ` [PATCH v1 09/40] i2c: bcm-kona: " Andy Shevchenko
2020-02-24 17:29 ` Scott Branden
2020-02-24 15:15 ` [PATCH v1 10/40] i2c: cadence: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 11/40] i2c: designware: " Andy Shevchenko
2020-02-24 16:30 ` Mika Westerberg
2020-02-25 7:30 ` Jarkko Nikula
2020-02-24 15:15 ` [PATCH v1 12/40] i2c: digicolor: " Andy Shevchenko
2020-02-24 18:25 ` Baruch Siach
2020-02-24 15:15 ` [PATCH v1 13/40] i2c: diolan-u2c: " Andy Shevchenko
2020-02-25 17:36 ` Guenter Roeck
2020-02-24 15:15 ` [PATCH v1 14/40] i2c: exynos5: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 15/40] i2c: hix5hd2: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 16/40] i2c: img-scb: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 17/40] i2c: imx-lpi2c: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 18/40] i2c: imx: " Andy Shevchenko
2020-02-25 8:18 ` Oleksij Rempel
2020-02-24 15:15 ` [PATCH v1 19/40] i2c: lpc2k: " Andy Shevchenko
2020-02-24 15:35 ` Vladimir Zapolskiy
2020-02-24 16:01 ` Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 20/40] i2c: mt65xx: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 21/40] i2c: mv64xxx: " Andy Shevchenko
2020-03-13 20:28 ` Gregory CLEMENT
2020-02-24 15:15 ` [PATCH v1 22/40] i2c: mxs: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 23/40] i2c: nomadik: " Andy Shevchenko
2020-02-25 21:57 ` Linus Walleij
2020-02-24 15:15 ` [PATCH v1 24/40] i2c: owl: " Andy Shevchenko
2020-02-24 15:27 ` Manivannan Sadhasivam
2020-02-24 15:15 ` [PATCH v1 25/40] i2c: rcar: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 26/40] i2c: riic: " Andy Shevchenko
2020-02-24 16:48 ` Chris Brandt
2020-02-24 15:15 ` [PATCH v1 27/40] i2c: rk3x: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 28/40] i2c: s3c2410: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 29/40] i2c: sh_mobile: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 30/40] i2c: sirf: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 31/40] i2c: spdr: " Andy Shevchenko
2020-02-25 0:49 ` Baolin Wang
2020-02-25 10:38 ` Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 32/40] i2c: stm32f4: " Andy Shevchenko
2020-03-02 8:39 ` Pierre Yves MORDRET
2020-02-24 15:15 ` [PATCH v1 33/40] i2c: stm32f7: " Andy Shevchenko
2020-03-02 8:40 ` Pierre Yves MORDRET
2020-02-24 15:15 ` [PATCH v1 34/40] i2c: stu300: " Andy Shevchenko
2020-02-25 21:57 ` Linus Walleij
2020-02-24 15:15 ` [PATCH v1 35/40] i2c: st: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 36/40] i2c: synquacer: " Andy Shevchenko
2020-02-24 15:18 ` Ard Biesheuvel
2020-02-24 15:15 ` [PATCH v1 37/40] i2c: tegra: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 38/40] i2c: uniphier-f: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 39/40] i2c: uniphier: " Andy Shevchenko
2020-02-24 15:15 ` [PATCH v1 40/40] i2c: xlp9xx: " Andy Shevchenko
2020-02-25 10:22 ` [PATCH v1 01/40] i2c: qup: Move bus frequency definitions to i2c.h Wolfram Sang
2020-02-25 10:47 ` Andy Shevchenko [this message]
2020-02-25 11:44 ` Wolfram Sang
2020-02-25 11:56 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200225104708.GF10400@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-i2c@vger.kernel.org \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).