All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PROPOSED] ata: Report 16/32bit PIO as best we can
Date: Thu, 09 Apr 2009 09:33:20 -0400	[thread overview]
Message-ID: <49DDF920.70801@garzik.org> (raw)
In-Reply-To: <20090409141254.283d9f11@lxorguk.ukuu.org.uk>

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





  reply	other threads:[~2009-04-09 13:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-09 13:32 [PROPOSED] ata: Report 16/32bit PIO as best we can Alan Cox
2009-04-09 12:50 ` Jeff Garzik
2009-04-09 12:53   ` Alan Cox
2009-04-09 13:08     ` Jeff Garzik
2009-04-09 13:12       ` Alan Cox
2009-04-09 13:33         ` Jeff Garzik [this message]
2009-04-09 13:41           ` Alan Cox
2009-04-09 13:45             ` Jeff Garzik
2009-04-09 13:48             ` Tejun Heo
2009-04-09 13:49               ` Tejun Heo
2009-04-09 13:45         ` Tejun Heo
2009-04-09 13:58           ` Alan Cox
2009-04-09 14:02             ` Tejun Heo
2009-04-09 13:02 ` Mark Lord
2009-04-09 13:08   ` Alan Cox
2009-04-13 16:32     ` Jeff Garzik
2009-04-13 16:39       ` Alan Cox
2009-04-13 16:57         ` Jeff Garzik
2009-04-09 13:25   ` Jeff Garzik
2009-04-09 16:57     ` Mark Lord
2009-04-09 20:42       ` Jeff Garzik
2009-04-10  0:38     ` Douglas Gilbert
2009-04-10  0:47       ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49DDF920.70801@garzik.org \
    --to=jeff@garzik.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.