linux-kernel - Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

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: <20130408095525.GB3496@the-dreams.de>
Date:	Mon, 8 Apr 2013 11:55:25 +0200
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Simon Glass <sjg@...omium.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Daniel Kurtz <djkurtz@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

Guenter,

> I think there is a difference between a bad driver or underlying hardware. To
> me, "shipped" applies to hardware or firmware which can not be upgraded, not to
> the software running on it.

OK. Valuable distinction.

> "board support hosted in the I2C directory". But that is exactly what I am
> talking about, isn't it ? I have board specific multiplexers and a board
> specific I2C controller, and that is just talking about the I2C code.

Yes and no. I think I can accept that some hardware has GPIOs wired to
handle I2C arbitration. I still have problems in having arbitrator
drivers per board, each one with various ideas how to do it. That would
be a maintenance horror and has nothing to do with I2C, strictly
speaking. What I would love to see is a few generic arbitrator drivers,
e.g. utilizing a timeout-based scheme (as proposed here). Or like the
old SCSI method putting IDs on the wire and the lowest wins. Stuff like
that.

> A better example might be Kontron board support. They implement gpio, I2C mux,
> and a watchdog in a PLD. They too have an access arbitration scheme where
> one has to acquire a hardware mutex before accessing the pld, if I understand
> correctly because some microcontroller might need to access it as well.
> Leaving the actual code aside, would you reject that too if you don't like
> the arbitration scheme, or because you don't want to have board support
> in the i2c directory ?

If I understood correctly, getting the mutex would be done in some
platform code and the I2C driver will simply call the necessary function
to obtain and release the mutex. Or maybe the MFD layer can help, dunno.
Both are fine with me and I don't care about the actual PLD arbitration.

Thanks,

   Wolfram
--
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/