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]
Message-ID: <20140610143604.GC7054@lukather>
Date:	Tue, 10 Jun 2014 16:36:04 +0200
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	Wolfram Sang <wsa@...-dreams.de>,
	Randy Dunlap <rdunlap@...radead.org>,
	Hans de Goede <hdegoede@...hat.com>,
	Shuge <shuge@...winnertech.com>, kevin@...winnertech.com,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-i2c@...r.kernel.org
Subject: Re: [PATCH v5 2/2] i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface)
 controller support

Hi Arnd,

On Tue, Jun 10, 2014 at 03:54:56PM +0200, Arnd Bergmann wrote:
> On Tuesday 10 June 2014 15:47:16 Boris BREZILLON wrote:
> > 
> > +config I2C_SUN6I_P2WI
> > +       tristate "Allwinner sun6i internal P2WI controller"
> > +       depends on ARCH_SUNXI
> > +       help
> > +         If you say yes to this option, support will be included for the
> > +         P2WI (Push/Pull 2 Wire Interface) controller embedded in some sunxi
> > +         SOCs.
> > +         The P2WI looks like an SMBus controller (which supports only byte
> > +         accesses), except that it only supports one slave device.
> > +         This interface is used to connect to specific PMIC devices (like the
> > +         AXP221).
> > +
> 
> Sorry for the stupid question, but why is this an i2c driver if the
> hardware protocol is completely different?

It's not completely different. It deviates, but still looks very
similar to i2c, and to be precise, SMBus.

You'll have the full discussion that led to do this in i2c here:
http://www.spinics.net/lists/linux-i2c/msg15066.html

Also, one significant thing to take into account is that the
communication with a device starts as I2C, only to switch to this
protocol after some initialization sequence.

> I understand that a lot of devices can be driven using either spi or
> i2c, and we have two sets of {directories,maintainers,bus_types,...}
> for them. Your description sounds like this is a separate option
> that isn't any closer to i2c than it is to spi.

That's not true. It's *much* closer from I2C than it is from SPI.

> Would it perhaps be better to expose it only as a regmap rather than
> an i2c host?

That could be a solution, but is it a common practice to define a bus
adapter driver in a regmap driver?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ