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/

Powered by blists - more mailing lists