linux-kernel - Re: [PATCH 1/2] i2c-core: Add gpio based bus arbitration implementation

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Dec 2012 00:58:05 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Simon Glass <sjg@...omium.org>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Naveen Krishna Chatradhi <ch.naveen@...sung.com>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	lk <linux-kernel@...r.kernel.org>,
	linux-samsung-soc@...r.kernel.org,
	Wolfram Sang <w.sang@...gutronix.de>,
	Jean Delvare <khali@...ux-fr.org>,
	Ben Dooks <ben-linux@...ff.org>,
	Devicetree Discuss <devicetree-discuss@...ts.ozlabs.org>,
	Grant Grundler <grundler@...omium.org>,
	Naveen Krishna <naveen@...omium.org>
Subject: Re: [PATCH 1/2] i2c-core: Add gpio based bus arbitration implementation

On Thu, Dec 20, 2012 at 12:17 AM, Simon Glass <sjg@...omium.org> wrote:
> On Wed, Dec 19, 2012 at 9:14 AM, Mark Brown
> <broonie@...nsource.wolfsonmicro.com> wrote:
>> On Wed, Dec 19, 2012 at 12:32:01PM +0000, Grant Likely wrote:
>>
>>> I'm not convinced on the design of this protocol. It won't scale beyond
>>> 2 bus masters and it seems very specific to the design of a specific
>>> piece of hardware. I don't think it is mature enough to bake into the
>>
>> I ought to point out that the original patch would've baked this into
>> the Samsung I2C driver but I asked for it to be split out as it's
>> nothing to do with the controller really and I'm sure I've seen it
>> before.
>
> Grant your idea looks nice to me. I only worry if we should wait until
> we have a second user before going so far with it. But it is certainly
> a nice general solution.
>
> The scaling beyond two bus masters would require the code to be
> changed to check more input lines from other masters. Best avoided for
> now I think until we have a use for it.

There is two parts to this; the design of the binding, and the
implementation. Of the two, the binding is the most difficult to
change, so it is important to get something we can live with long term
sorted out now. The implementation can start somewhat naive, with a
plan for how to extend it.

Regarding the scaling to multiple devices, it is a much smaller issue
(if an issue at all) if the arbitration back end is pluggable. Then it
becomes easy to support hardware with a different arbitration
protocol. If it gets baked into the core i2c code, then we've got a
problem and a lot more scrutiny needs to be put into this specific
protocol.

g.
--
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/