This can be handled by having st (or sd, or whatever "client driver" decide
to take over a SCSI device) register a struct device node that is a child
of the actual SCSI device.
In fact, I'm wondering if we need a struct device node at all for the
SCSI device on the bus. The SCSI controller (or USB/storage or
FireWire SBP2) will expose SCSI devices, that is "interface" to
which you can feed SCSI requests, but do those really need to have
a structure device associated ? One possibility would be to only do
so once attached to a "client" driver like st, sd, sg, ...
The "client" would then create that structure.
But...
If we still want "unclaimed" devices to have a representation in the
device tree (because, for example, userland wants to know about them,
eventually in order to "instanciate" an sg driver), then we could have
the SCSI subsystem create a simple skeletton struct device when the
devices are probed, and have the client driver just populate this with
more infos & PM hooks once attached to the device.
I don't think there's a need to have 2 struct device stacked.
But it's mostly a matter of taste ;)
Thinking more about it, I think I prefer the second solution. That is
to have SCSI create "standard" struct device for all devices probed
on the bus, thus ensuring they are visible from the userland
representation of the device-tree, and then eventually have drivers like
sd, st, etc... add entries & PM hooks to those devices if needed when
attached to them. But doing that, or just having them create a virtual
node as a child of the device is mostly a matter of taste, I beleive.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/