linux-kernel - Re: [RFC PATCH v2] regmap: smbus: add support for regmap over smbus

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Apr 2014 15:34:55 +0200
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Mark Brown <broonie@...nel.org>
CC:	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Shuge <shuge@...winnertech.com>, kevin@...winnertech.com,
	Chen-Yu Tsai <wens@...e.org>,
	Hans de Goede <hdegoede@...hat.com>,
	Carlo Caione <carlo@...one.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	dev@...ux-sunxi.org
Subject: Re: [RFC PATCH v2] regmap: smbus: add support for regmap over smbus

On 04/15/2014 02:56 PM, Mark Brown wrote:
[...]
>> My suggestion is that in regmap_init_i2c() you check the capabilities of the
>> I2C adapter. If it supports native I2C you setup the regmap with the
>> regmap_i2c struct just as it does right now. If the adapter does not support
>> native I2C, check if the device can be supported by smbus (reg_bytes == 8 &&
>> val_bytes % 8 == 0). For each type of smbus operations have one regmap_bus
>> struct, and if you can fallback to smbus choose the bus depending on the
>> config's val_bytes.
>
> That'd definitely be useful but potentially orthogonal, we can also do
> both and expose smbus explicitly with I2C falling back to it
> transparently.
>
> If the device *is* limited to smbus and the controller supports both
> (some do) I'd naively have expected that the native smbus support would
> do a little better - otherwise why bother using it?  We could identify
> the constraint set automatically for I2C devices though it's more for
> the client driver to specify.
>
> This means there's two changes to consider here:
>
>   - Providing APIs for registering actual smbus devices as a convenience
>     for devices with that constraint, regardless of how that is done
>     behind the scenes.
>
>   - Having the I2C implementation automatically use the smbus APIs if
>     it can and either the controller is smbus only or it makes sense to
>     do so for optimisation.
>
> both of which are independently useful.
>

I don't think it makes sense to expose smbus explicitly. We can already 
describe smbus restricted devices just fine with the current regmap_config 
and already support them with the current I2C regmap implementation. Using 
native I2C to access these devices will be more efficient than going through 
the smbus emulation layer. The smbus emulation layer essentially does the 
same as we do in regmap, so using the smbus emulation layer through regmap 
means doing the same thing twice.

What we currently do not support is devices which are restricted to block 
transfers and I think adding support for this should be handled by a 
separate patchset. As far as I understood it this patchset is about making 
it possible to use smbus controllers with regmap devices which are smbus 
compatible.

As I see it there are currently 3 cases:

1) Device is strictly smbus only and the controller supports native smbus
    => Use smbus
2) The device is smbus compatible but has extensions (e.g. support for multi 
register writes) and the controller supports only smbus.
    => Use smbus
3) For every other case
    => Use native I2C.

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