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 16:24:42 +1100 [thread overview]
Message-ID: <1259645082.2076.210.camel@pasglop> (raw)
In-Reply-To: <4B14A0EC.70607@kernel.org>
On Tue, 2009-12-01 at 13:51 +0900, Tejun Heo wrote:
>
> If the hotplug events are completely reliable, we can add a flag to
> tell libata EH to trust the hotplug notices completely but then again
> I'm not too convinced about the benefits of implementing it in very
> small number of drivers. It could be more beneficial to keep the
> behavior consistent across all ATA drivers.
Well... in my case I know for sure the device is out. So the stuff
libata does to try to poke at the device is not only a waste of time,
but a few scary messages in the dmesg log ;-)
> It's basically an advisory flag telling libata to try to look for new
> devices. From outside EH, the only behavior difference is that with
> the flag set EH will try to re-enable ports which got disabled due to
> repeated reset failures.
Ok, but ata_ehi_hotplugged() will set it anyway so I don't really have
to do anything.
> > 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.
>
> Link callbacks won't change the hotplug behavior tho.
Right, see my other message, they make the situation even more complex
in fact so I'm backing off that.
> Oh yeah, link stuff will help that. Or you can also implement custom
> softreset which checks link status and exits early if there's no
> device.
That might be an option, I'll look at it.
> The only problem with the latter approach is that you'll need
> to take care of the race window in the driver itself. You can close
> the window by checking link status again in postreset and rescheduling
> hotplug event if hotplug event happened after the link state is
> checked in softreset but before the port was thawed.
I've done simpler. I've added a pair of calls to lock/unlock the media
bay which directly grab the bay driver internal mutex, which guarantees
we won't get any callback while we hold it. I could have done something
like you described instead but this is easy and allow to also easily
solve some of the possible races with drivers/ide while at it.
> Those events are all advisory. The final decision is always upto what
> the reset methods and following probes tell the EH, so it may go
> through one more EH round but it won't lose anything.
That's what I'm starting to understand :-) Very good. I'll look at the
custom softreset approach.
Cheers,
Ben.
next prev parent reply other threads:[~2009-12-01 5:25 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
2009-12-01 4:51 ` Tejun Heo
2009-12-01 5:24 ` Benjamin Herrenschmidt [this message]
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=1259645082.2076.210.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.