| Age | Commit message (Collapse) | Author |
|---|
|
It's big, but there doesn't seem to be a way to split it up smaller...
Signed-off-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Roland Dreier <rolandd@cisco.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Every current transport class calls transport_container_release but
ignores the return value. This is catastrophic if it returns an error
because the containers are part of a global list and the next action of
almost every transport class is to free the memory used by the
container.
Fix this by making transport_container_release a void, but making it BUG
if attribute_container_release returns an error ... this catches the
root cause of a system panic much earlier. If we don't do this, we get
an eventual BUG when the attribute container list notices the corruption
caused by the freed memory it's still referencing.
Also made attribute_container_release __must_check as a reminder.
Cc: Greg KH <greg@kroah.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
|
|
I recently tried to construct a totally generic transport class and
found there were certain features missing from the current abstract
transport class. Most notable is that you have to hang the data on the
class_device but most of the API is framed in terms of the generic
device, not the class_device.
These changes are two fold
- Provide the class_device to all of the setup and configure APIs
- Provide and extra API to take the device and the attribute class and
return the corresponding class_device
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
These were lost from the SCSI transport classes in
the transition to the generic classes. Ressurect it in
the generic class, since it's probable that more than SCSI
will want to use this.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
Transport classes are a mechanism for providing transport specific
services to drivers that the more generic command processing layers
don't care about. A good example is the SCSI mid-layer not caring about
parallel transfer characteristics or providing services for domain
validation. Transport classes usually provide a transport specific API
at one end and a class interface at the other (for the user to
interrogate and set parameters).
Originally, transport classes were SCSI specific. However, this code is
generic to the device model. As long as you have a generic device
representing a storage interface (or device) then you can attach a
transport class to it. The new code also allows an arbitrary number of
transport classes to be attached to a device, unlike SCSI which only
allowed one. This is going to be important for things like SATA and SAS
which share the PHY layer (and hence should be capable of sharing a PHY
transport class).
The generic transport class is designed to operate identically to the
current SCSI transport classes, except that it uses generic devices
rather than SCSI devices.
We have five events:
setup
add
-----
configure
-----
remove
destroy
With callbacks for setup configure and remove.
There's also an anonymous transport class which can only respond to
configure events (and which has no attributes).
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
