Alan Cox wrote:
With the attached patch, you can use ->flags for the two new flags, and
you can set those bits in the driver where you set the other
ATA_FLAG_xxx bits.
Its half way but I realised there is another reason that doesn't work
(and indeed why the device private flags are asking for trouble)
What are the locking sematics for ap->flags ?
In general, for both driver-private flags and ATA_FLAG_xxx, the flags
should be set at compile or pci_driver::probe() time, and never touched
after that.
So your patch is a bit of abuse, really, by fiddling with ap->flags at
all ;-) The drivers, for example, never touch the driver-private flags
after they are set at init. The core will occasionally twiddle flags,
inside of spin_lock_irqsave(ap->lock)
Since they are legacy ioctls, I think that reflecting current reality
should be sufficient. That is what the current set does:
* GET: return "16 bit"
* SET: if "16 bit" return success else fail
Thus 'set' has always been an illusion for libata. It's really been
read-only.
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
