lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100126173409.54f32259@hyperion.delvare>
Date:	Tue, 26 Jan 2010 17:34:09 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Wolfram Sang <w.sang@...gutronix.de>
Cc:	Ben Dooks <ben-linux@...ff.org>,
	Uwe Kleine-Koenig <u.kleine-koenig@...gutronix.de>,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: add i2c tree for embedded platforms

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ