All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Tejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org
Subject: Re: libata hotplug question
Date: Tue, 01 Dec 2009 13:43:40 +1100	[thread overview]
Message-ID: <1259635420.2076.180.camel@pasglop> (raw)
In-Reply-To: <4B1459B5.40504@kernel.org>


> Oh... yeah, that was the original intention when adding those
> functions but you wouldn't need them for hot plug/unplug.  Just set
> probe mask and freeze the port.  EH will do the right thing.

So I experimented a bit... and not touching probe_mask at all, just
doing ata_ehi_hotplugged and ata_port_freeze seems to get the basics
working, however with a few issues.

For example, if I remove the device, it will spend a few second trying
to poke at it & reset the bus before deciding its gone. This isn't a
terribly good idea (and could cause "interesting" issues if it's
re-plugged right away in fact)

I tried toying with the probe_mask bits but it doesn't seem to make any
difference here. I must admit that I got more or less lost as to what
probe_mask actually means, how it's used, when it's initialized and when
it's cleared. I will try to spend some more time later looking at the
code and trying to sort it out but it doesn't appear to be a great
solution.

At the end of the day, it might be better to just add those link
callbacks... I'll give that a try too, unless you have a better idea.

In addition, to speed up boot time, I want to remove the synchronous
waiting for the media bay to be up that we have in there, which is easy
since it's already run by a kthread.

The reason I had that was originally to provide some stability in drive
ordering with old drivers/ide and have the drive ready at boot when the
driver was probed, but that isn't really necessary anymore. I will
provide a callback to keep doing that synchronous wait for the old IDE
driver because I don't want to deal with races there at boot time, but
for libata, I can just trigger the EH for a hotplug at about any time.

But for that to work right, I need to be able to prevent probing when
setting up the host, when I know that the bay is empty, which the link
stuff would cover nicely too, don't you think ? Or do you have a better
idea ?

I also have to be careful of a possible race if the hotplug callback
since it can potentially happen as soon as I enter my driver->probe()
(it comes from the macio "bus" layer). What is the harm of triggering a
hotplug if nothing was actually unplugged ? Will libata silently just
keep things as they were ?

Cheers,
Ben. 


  parent reply	other threads:[~2009-12-01  2:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-30  6:04 libata hotplug question Benjamin Herrenschmidt
2009-11-30 23:44 ` Benjamin Herrenschmidt
2009-11-30 23:48   ` Tejun Heo
2009-12-01  0:05     ` Benjamin Herrenschmidt
2009-12-01  2:43     ` Benjamin Herrenschmidt [this message]
2009-12-01  4:51       ` Tejun Heo
2009-12-01  5:24         ` Benjamin Herrenschmidt
2009-12-01  5:17       ` Benjamin Herrenschmidt
2009-12-01  5:22         ` Tejun Heo
2009-12-01  5:30           ` Benjamin Herrenschmidt
2009-12-01  5:34             ` Tejun Heo
2009-12-01  5:39               ` Benjamin Herrenschmidt
2009-12-01  5:57                 ` Benjamin Herrenschmidt
2009-12-01  5:35           ` Benjamin Herrenschmidt
2009-11-30 23:46 ` Tejun Heo

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=1259635420.2076.180.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=tj@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.