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: <20121105171248.GJ24532@intel.com>
Date:	Mon, 5 Nov 2012 19:12:48 +0200
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Walleij <linus.walleij@...aro.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 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.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ