linux-kernel - Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support

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:	Mon, 5 Nov 2012 14:20:52 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jean Delvare <khali@...ux-fr.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	linux-kernel@...r.kernel.org, lenb@...nel.org,
	rafael.j.wysocki@...el.com, grant.likely@...retlab.ca,
	ben-linux@...ff.org, w.sang@...gutronix.de,
	mathias.nyman@...ux.intel.com, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 2/3] spi / ACPI: add ACPI enumeration support

On Mon, Nov 5, 2012 at 2:15 PM, Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
> On Mon, Nov 05, 2012 at 01:59:23PM +0100, Rafael J. Wysocki wrote:
>> On Monday, November 05, 2012 01:23:50 PM Jean Delvare wrote:
>> > On Mon, 5 Nov 2012 14:02:19 +0200, Mika Westerberg wrote:
>> > > On Mon, Nov 05, 2012 at 11:56:39AM +0100, Mark Brown wrote:
(...)
>> > > Yeah, I just went through DSDT table of one of our machines and found a
>> > > device that actually has two I2CSerialBus connectors (and those are to the
>> > > same controller). What I'm not sure is that is it used to select between
>> > > two different addresses or doest the device really have two physical I2C
>> > > connections.
>> >
>> > Neither would make sense from a hardware perspective.
>>
>> Well, interesting. :-)
>
> It looks like some PMICs for example have two I2C control interfaces, like
> TI's TWL6030 if I'm not mistaken. If both are put behind the same I2C
> controller with different address, you have the situation like above.

This is quite common. So for example the AB8500 (drivers/mfd/ab8500-core.c)
has this. The reason is usually that the device has more than 256 registers
to the address space simply is not big enough.

What we do is refer to the subaddresses as "banks" and they happen
to always be at the next consecutive address so n+1.

So the same device appear behind several addresses just to support
a lot of registers.

So you're not actually modelling the devices on the other end but the
multiple addresses of a single device.

If the addresses are consecutive like ours it makes sense
to just instantiate one device and have the driver know that it will
also be able to access address +1, +2 ... +n. So is it possible
to group the consecutive related addresses after each other
here at the acpi-spi level and just create a single device?

If the addresses are not consecutive I guess you need to have
one device driver bind to several devices and return -EPROBE_DEFER
until the driver has been probed for all of them or something like
that, this is what multi-block GPIO drivers sometimes do.

Yours,
Linus Walleij
--
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/