linux-kernel - Re: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.

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:	Fri, 19 Aug 2011 12:24:44 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Kenneth Heitke <kheitke@...eaurora.org>, sdharia@...eaurora.org,
	David Brown <davidb@...eaurora.org>, bryanh@...eaurora.org,
	linux-arm-msm@...r.kernel.org, rdunlap@...otime.net,
	rmk+kernel@....linux.org.uk, john.stultz@...aro.org,
	akpm@...ux-foundation.org, ohad@...ery.com, gregkh@...e.de,
	stefanr@...6.in-berlin.de, lethal@...ux-sh.org,
	linville@...driver.com, zajec5@...il.com,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] slimbus: Linux driver framework for SLIMbus.

On Wed, 2011-08-17 at 16:00 +0200, Arnd Bergmann wrote:

> How about a mixed model then?

> I can see three relevant cases to consider:

> 1. A simple potentially hotplugged device that registers itself to the bus
>    can be automatically matched to the driver.
> 2. A device tree representation for hardwired devices that require
>    something to happen in order to register to the bus (clock, regulator,
>    ...).
> 3. A hardcoded list of devices on a slimbus host for stuff that is known
>    to be there, e.g. on a PCI card that has its own driver and that
>    also need some special setup as in case 2.

> I think in all three cases, we should identify the device by its EA and
> match that to the device driver. We create the slim_device and register
> it to the bus as soon as one of the three above is found, but in case 2
> and 3, the driver is responsible for the device to actually become active
> on the bus before it's allowed to send any commands to it.

Yes, I think that makes sense and it matches what we're doing with the
other subsystems well. We should be able to make the drivers work with
all cases. Probably the probe function should have a flag and/or query
function to let the driver know if the device has actually appeared yet.

> For the device tree binding, I would suggest defining a slimbus bus to
> have #address-cells=1, #size-cells=0 and just put the EA into the reg
> property. This is enough for the host driver to add create a
> slim_device and match a driver to it. The driver can access all the
> properties from the device_node (or platform_data in case of statically
> defined devices). When the physical device shows up on the bus, it is
> automatically associated with the existing slim_device.

Sounds reasonable I'd need to actually look at the specs again for the
details.

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