Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] MAINTAINERS: add i2c tree for embedded platforms

0 views
Skip to first unread message

Uwe Kleine-König

unread,
Jan 25, 2010, 4:30:03 AM1/25/10
to
Signed-off-by: Uwe Kleine-König <u.klein...@pengutronix.de>
Cc: Ben Dooks <ben-...@fluff.org>
---
Hello,

I wonder if it makes sence to split the "I2C SUBSYSTEM" entry into
something like:

I2C SUBSYSTEM (PC drivers, core)
M: Jean Delvare <kh...@linux-fr.org>
L: ...
W: ...
T: quilt ...
S: ...
F: Documentation/i2c/
F: drivers/i2c/
F: include/linux/i2c.h
F: include/linux/i2c-*.h

I2C SUBSYSTEM (embedded platforms)
M: Ben Dooks <ben-...@fluff.org>
L: ...
W: ...
T: git ...
S: ...
F: drivers/i2c/
F: include/linux/i2c-*.h

(I'm not entirely sure about the file patterns for the 2nd entry.)

Best regards
Uwe

MAINTAINERS | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1858646..a1813fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2629,6 +2629,7 @@ M: "Ben Dooks (embedded platforms)" <ben-...@fluff.org>
L: linu...@vger.kernel.org
W: http://i2c.wiki.kernel.org/
T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
+T: git git://git.fluff.org/bjdooks/linux.git
S: Maintained
F: Documentation/i2c/
F: drivers/i2c/
--
1.6.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jean Delvare

unread,
Jan 25, 2010, 5:20:02 AM1/25/10
to

I'm not sure what value it adds, compared to having a single entry as
we have today. scripts/get_maintainer.pl will produce the same output,
won't it?

This script (and our minds) being directory-driven, I suspect that the
only efficient way to split the entries would be to first move all i2c bus
driver for embedded platforms to a separate subdirectory. I'm leaving
it to Ben and the embedded community to decide whether they want to do
that or not.

>
> Best regards
> Uwe
>
> MAINTAINERS | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1858646..a1813fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2629,6 +2629,7 @@ M: "Ben Dooks (embedded platforms)" <ben-...@fluff.org>
> L: linu...@vger.kernel.org
> W: http://i2c.wiki.kernel.org/
> T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
> +T: git git://git.fluff.org/bjdooks/linux.git
> S: Maintained
> F: Documentation/i2c/
> F: drivers/i2c/

Yes, please!

Acked-by: Jean Delvare <kh...@linux-fr.org>

--
Jean Delvare

Ben Dooks

unread,
Jan 26, 2010, 9:40:02 AM1/26/10
to
On Mon, Jan 25, 2010 at 11:10:55AM +0100, Jean Delvare wrote:
> On Mon, 25 Jan 2010 10:20:34 +0100, Uwe Kleine-K??nig wrote:
> > Signed-off-by: Uwe Kleine-K??nig <u.klein...@pengutronix.de>

I'd much prefer to see just the one directory of i2c drivers, the
minor point being people silly enough to load modules by explicit path
and the second is that having all the drivers in one place makes it
easier to update them when changing something in the core...



> >
> > Best regards
> > Uwe
> >
> > MAINTAINERS | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 1858646..a1813fd 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2629,6 +2629,7 @@ M: "Ben Dooks (embedded platforms)" <ben-...@fluff.org>
> > L: linu...@vger.kernel.org
> > W: http://i2c.wiki.kernel.org/
> > T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
> > +T: git git://git.fluff.org/bjdooks/linux.git
> > S: Maintained
> > F: Documentation/i2c/
> > F: drivers/i2c/
>
> Yes, please!
>
> Acked-by: Jean Delvare <kh...@linux-fr.org>
>
> --
> Jean Delvare
> --

> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in


> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

--
Ben (b...@fluff.org, http://www.fluff.org/)

'a smiley only costs 4 bytes'

Ben Dooks

unread,
Jan 26, 2010, 9:40:03 AM1/26/10
to
On Mon, Jan 25, 2010 at 10:20:34AM +0100, Uwe Kleine-K??nig wrote:
> Signed-off-by: Uwe Kleine-K??nig <u.klein...@pengutronix.de>

> Cc: Ben Dooks <ben-...@fluff.org>
> ---
> Hello,
>
> I wonder if it makes sence to split the "I2C SUBSYSTEM" entry into
> something like:
>
> I2C SUBSYSTEM (PC drivers, core)
> M: Jean Delvare <kh...@linux-fr.org>
> L: ...
> W: ...
> T: quilt ...
> S: ...
> F: Documentation/i2c/
> F: drivers/i2c/
> F: include/linux/i2c.h
> F: include/linux/i2c-*.h
>
> I2C SUBSYSTEM (embedded platforms)
> M: Ben Dooks <ben-...@fluff.org>
> L: ...
> W: ...
> T: git ...
> S: ...
> F: drivers/i2c/
> F: include/linux/i2c-*.h
>
> (I'm not entirely sure about the file patterns for the 2nd entry.)

We might be able to add each driver individually, but that would mean
updating the entry with each driver added, and that sounds too much
like hard work (sorry, receipie for merge conflict)



> Best regards
> Uwe
>
> MAINTAINERS | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1858646..a1813fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2629,6 +2629,7 @@ M: "Ben Dooks (embedded platforms)" <ben-...@fluff.org>
> L: linu...@vger.kernel.org
> W: http://i2c.wiki.kernel.org/
> T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
> +T: git git://git.fluff.org/bjdooks/linux.git
> S: Maintained
> F: Documentation/i2c/
> F: drivers/i2c/
> --
> 1.6.6
>
> --

> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in


> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

--
Ben (b...@fluff.org, http://www.fluff.org/)

'a smiley only costs 4 bytes'

Jean Delvare

unread,
Jan 26, 2010, 10:30:02 AM1/26/10
to

Never thought of that, but I wouldn't care. There is no good reason to
do this.

> and the second is that having all the drivers in one place makes it
> easier to update them when changing something in the core...

This doesn't seem to be a blocker either. For one thing, i2c
subsystem-wide changes tend to affect chip drivers more than bus
drivers. And even then, looking for drivers in 2 directories doesn't
seem much harder than looking into just one, especially when said 2
directories live next to each other.

So I see no objection to a mass move of all embedded/system i2c bus
drivers to a separate sub-directory.

--
Jean Delvare
--

Wolfram Sang

unread,
Jan 26, 2010, 10:40:02 AM1/26/10
to
> So I see no objection to a mass move of all embedded/system i2c bus
> drivers to a separate sub-directory.

And with the PCA9xxx-controllers? The ISA-driver into non-embedded and the
platform-driver into embedded? Hmmm...

And (in 80 years ;)) there might be just one I2C-maintainer taking care of them
all? Then, why the split?

I am all for taking the embedded-burden away from you, just I am not too fond
of this idea.

Regards,

Wolfram

--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |

signature.asc

Jean Delvare

unread,
Jan 26, 2010, 11:40:02 AM1/26/10
to
On Tue, 26 Jan 2010 16:37:59 +0100, Wolfram Sang wrote:
> > So I see no objection to a mass move of all embedded/system i2c bus
> > drivers to a separate sub-directory.
>
> And with the PCA9xxx-controllers? The ISA-driver into non-embedded and the
> platform-driver into embedded? Hmmm...

Ideally the ISA driver would go to the trash can ;) and having both on
separate directories doesn't strike me as being a problem. We have
i2c-algo-bit-based drivers in many places and this has never been a
problem.

> And (in 80 years ;)) there might be just one I2C-maintainer taking care of them
> all? Then, why the split?

That's a more valid argument. But then again, MAINTAINERS can be edited
again later as needed, with split entries getting merged or the other
way around. What matters is that MAINTAINERS reflects the reality of
who is doing what.

> I am all for taking the embedded-burden away from you, just I am not too fond
> of this idea.

I'm not forcing anyone, and I would welcome alternative solutions.

0 new messages