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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 21 Aug 2011 15:10:49 -0700 (PDT)
From:	"Sagar Dharia" <sdharia@...eaurora.org>
To:	"Mark Brown" <broonie@...nsource.wolfsonmicro.com>
Cc:	"Arnd Bergmann" <arnd@...db.de>,
	"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.

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

Thanks again everyone for your feedback.
I will make sure to use the fields of the 48-bit elemental address for
device-to-driver-matching and will try to incorporate hot-plug
capabilities for the device powering up without assistance from the
driver's probe function. Other cases discussed in the mixed-approach will
be supported as well.
Another suggestion about probe is having callback to notify when the
device is ready-to-use after driver probe powers it up. I will change the
framework accordingly to have this done.

>> 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.
I will try to incorporate device-tree binding in the framework and put it
up for review for more suggestions.

-Sagar

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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