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: <1983976.4JKTfcThF7@vostro.rjw.lan>
Date:	Mon, 05 Nov 2012 13:59:23 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Jean Delvare <khali@...ux-fr.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	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,
	linus.walleij@...aro.org, 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 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:
> > > I've got practical systems where there are multiple buses physically
> > > connected, though in practice almost always only one is actually used at
> > > runtime when it's I2C and SPI there are some systems (usually with other
> > > buses) where you might want to use more than one bus.  Not sure those
> > > buses will fit in here though.
> > 
> > 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. :-)

I wonder what we're supposed to do with things like that?
It looks like our patch [3/3] will use the last one found, but is that
correct?  Should it use the first one instead, perhaps?

That little conundrum aside, the observations above seem to indicate
that we'd need a list of "serial" resources per struct acpi_device too.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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