Re: [patch 4/6] ide: allow ide_dev_read_id() to be called from the IRQ context

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bartlomiej Zolnierkiewicz wrote:
On Wednesday 24 June 2009 12:48:20 Bartlomiej Zolnierkiewicz wrote:

1) You want the device to be quiescent anyways when you do this
   SET_XFER command.  What better way than to plug the queue
   and make sure all currently outstanding requests complete?

   And as already discussed, we even already have logic to support
   this kind of thing for the sake of power-management.
Power management requests are kind of special and need block layer support.

Please take a look at REQ_DEVSET_EXEC special requests from ide-devsets.c
instead if you would like to investigate possibility of a cleaner (although
more invasive) solution.

2) All commands going into the device do so from a context from
   which we could take a sleeping lock such as a mutex.  It's
   therefore the most natural way to synchonize things.
The fact is that we need to synchronize against all commands going into
the device and they are synchronized using block queue (which is protected
with spinlock by block layer). Adding an extra mutex (even if possible)

We need to also take the synchronization between block queues of all devices
on the port and the serialized ports into account..  This is quite complex
and fragile code (vide cmd64x screaming IRQ issue ;)..

I would personally try going with 1) and avoid 2) at all costs..

FWIW, on Promise chipsets, SETFEATURES_XFER requires synchronization across all ports on the controller, otherwise SETFEATURES_XFER on port M can potentially cause data corruption on unrelated port N.

This has to do with the snooping of ATA commands performed by the Promise PATA and SATA chips. The chip sees SETFEATURES_XFER, and does a bit of internal programming.

Silicon Image (siimage or sata_sil) also snoops ATA commands such as SETFEATURES_XFER; ditto a few other chipsets.

SETFEATURES_XFER has always required very, very careful, often chipset-specific handling.

	Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux