Re: [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management

[Phillip Susi <phill@thesusis.net>]

Damien Le Moal <dlemoal@kernel.org> writes:

> Yes. Many embedded systems and people using old PCs still use that.
> And that is not the only case. Port multiplier is the other major one since
> multiple drives share the same link. In both cases, the drive "think" it is
> talking to its own port, but the port is used to manage several devices. One
> consequence of this is that the link speed for the port MUST be limited to the
> lowest link speed of all devices. And to discover that, one has to probe all 15
> ports of the PMP to discover the devices attached... Hence the fact that
> bypassing revalidation being a really bad idea.

Really?  I thought that the PMP recieved the FIS on the upstream port,
buffered it, then sent it to the downstream port, and that could be at a
different speed.  So you could have a FBS PMP that is taking 3 Gbps in
on the upstream link, and splitting the FISes out to two different
downstream links at 1.5 Gbps.  Or does that only happen with SAS
switches?

I think the last time I had a PATA drive was before 2006.  It's really
hard to believe that anyone is still using them nearly 20 years later.

> Patching udisk and smartd would be a lot more sensible. An application using
> passthrough to talk to a drive without first checking if the drive is actually
> active is not a sensible thing to do. Especially considering that runtime

They already do that.  The problem is that even checking to see if the
drive is running with CHECK POWER CONDITION causes libata to wake up a
drive from SLEEP ( not STANDBY ) so that it can feed the drive the
command.  Thus why I patched libata to just complete the command without
waking the drive and tell user space that it is in standby.  Likewise,
when the filesystem issued a FLUSH CACHE while the drive is in SLEEP,
libata can just complete the request and ignore it, since there isn't
anything dirty in the cache.