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]

Message-ID: <1772239.ndMLD9ec3r@wuerfel>
Date:	Wed, 17 Aug 2011 09:09:44 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Kenneth Heitke <kheitke@...eaurora.org>
Cc:	sdharia@...eaurora.org, David Brown <davidb@...eaurora.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	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 Tuesday 16 August 2011 17:27:05 Kenneth Heitke wrote:
> On 08/16/2011 01:49 PM, Arnd Bergmann wrote:
> > Or does the 48-bit number actually tell us something about what
> > device we're talking to, e.g. 24 bit vendor plus 24 bit device
> > type and revision or such. If that's the case, the number needs
> > to be the primary key that gets used to identify the driver,
> > just like we do it in case of USB or PCI devices.
> 
> The 8-bit address is a logical address that is assigned by the SLIMbus 
> framework.  The framework maintains the mapping of logical addresses to 
> the 48-bit Enumeration Address (EA).  The 8-bit logical address is then 
> used for any further SLIMbus device addressing.
> 
> The slim_get_logical_addr() API call is used by the client drivers to 
> get the logical address that has been assigned to the device.
> 
> For the proposed implementation, the client drivers are probed before 
> their devices are discovered because the client driver may need to 
> power-up the device or pull it out of reset.  Once the device is powered 
> up, the call to get_logical_address() will let the client know whether 
> or not their device has enumerated.

Hmm, I looked at http://www.national.com/assets/en/other/intro_to_SLIMbus.pdf
which contains:

| SLIMbusTM uses a 48-bit Enumeration Addresses (EA) to
| uniquely identify Devices which can announce
| their presence on the bus. Each Device has an EA,
| which incorporates Manufacturer ID, Product Code,
| Device Index, and Instance Value for a Device. The
| Manufacturer ID code is supplied by the MIPI
| Alliance and uniquely identifies the manufacturer
| of the Device, similar to the manufacturer IDs used with
| PCI bus components. The Device Index code uniquely
| identifies multiple Devices within a single
| Component. The Instance Value code is for the case
| where multiple Devices of the same type or Class
| are attached to the bus.

Based on this, I would strongly suggest a different model to the
one that you are suggesting:

* Make each device driver assume that the device is powered on when
  talking to it.
* Make the EA (minus the index/instance ID) the primary identifier for a
  device driver, not an arbitrary string.
* Move the logic for enabling and disabling devices into a host specific
  driver that takes care of powering the devices up initially, identifying
  them and putting them into run-time PM disabled state when no driver was
  found or the device is unused.

This will make it possible to reuse the same driver for multiple machines
that have the same endpoint devices, while moving all the board specific
clock and reset logic into a separate driver, which can be very small in
many cases.

I would guess that in many cases, the logic for enabling the devices
fits into the slimbus host driver. If that is not the case, e.g. when
a lot of machines have the same host controller but each of them uses
a different way to get the devices out of reset, you can turn the host
driver into a library that contains the actual code accessing the host
controller registers, but provide a per-machine platform_driver that
known how to enable the individual devices and uses the library code
from the main host driver to talk to the devices.

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