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 10:43:17 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.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 10:12 AM, Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
> On Mon, Nov 05, 2012 at 04:19:20PM +0100, Jean Delvare wrote:
>> On Mon, 5 Nov 2012 16:53:15 +0200, Mika Westerberg wrote:
>> > On Mon, Nov 05, 2012 at 03:19:58PM +0100, Rafael J. Wysocki wrote:
>> > >
>> > > In the ACPI namespace we have device nodes and serial interfaces below them.
>> > > In the above case we see that a single device node supports two different
>> > > interfaces and in that case we probably should create two different
>> > > struct i2c_adapter objects for the same ACPI device node.
>> > >
>> > > Mika, what do you think?
>> >
>> > I agree.
>> >
>> > Only problem I see is that then we have two I2C adapter devices with the
>> > same ACPI ID (and hence the same i2c_client->name). I wonder what the I2C
>> > core thinks about that.
>>
>> I2C core fears that you're mixing up everything ;) I2C adapter devices
>> are struct i2c_adapter aka i2c-0, i2c-1 etc. i2c_client is for slave
>> devices. There's nothing wrong with i2c_clients sharing ->name, that's
>> even how device driver matching is achieved. The uniqueness of
>> i2c_clients is on their bus_id which is the combination of i2c adapter
>> number and slave address (e.g. 0-0050)
>
> Yeah, I mixed I2C adapter and client. Thanks for correcting.
>
> So if we create one I2C adapter from the platform bus code as we do now and
> then for each I2CSerialBus connector we create one I2C client (well, the
> one that is created when i2c_new_device() is called), everything should
> work, right?
>
> Then I suggest that we have a list of serial bus resources in the struct
> acpi_device and create the I2C clients based on that.
>
>> i2c_adapter->name should, OTOH, be unique. In i2c bus drivers we
>> usually append the base I/O address at the end of the name to guarantee
>> that. ACPI will have to come up with something similar.
>
> It should already be unique in case of ACPI. We use ACPI _HID and _UID to
> achieve that.

Using only _HID and _UID to guarantee uniqueness means you're relying
on a property of the BIOS, so you're vulnerable to BIOS bugs.

If there's an ACPI Device for I2C adapters, why wouldn't you just use
its device name as set in acpi_device_register() (basically a _HID +
instance number)?
--
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/