From: Holger Macht <hmacht@suse.de>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
linux acpi <linux-acpi@vger.kernel.org>,
Len Brown <lenb@kernel.org>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
"Accardi, Kristen C" <kristen.c.accardi@intel.com>,
Jeff Garzik <jeff@garzik.org>, Tejun Heo <htejun@gmail.com>
Subject: Re: [PATCH 6/8] libata hotplug to align with dock driver
Date: Tue, 10 Jun 2008 10:15:27 +0200 [thread overview]
Message-ID: <20080610081527.GB29300@homac> (raw)
In-Reply-To: <1213061676.32112.6.camel@sli10-desk.sh.intel.com>
On Tue 10. Jun - 09:34:36, Shaohua Li wrote:
> On Mon, 2008-06-09 at 02:37 +0100, Matthew Garrett wrote:
> > On Fri, Jun 06, 2008 at 01:23:08PM +0800, Shaohua Li wrote:
> >
> > > case ACPI_NOTIFY_EJECT_REQUEST:
> > > ata_ehi_push_desc(ehi, "ACPI event");
> > > -
> > > - if (!is_dock_event)
> > > - break;
> > > -
> > > - /* undock event - immediate unplug */
> > > ata_acpi_detach_device(ap, dev);
> >
> > Ok, just to check that I've understood the other patches - this will
> > only be called if the device has actually been removed, and not if you
> > merely get an EJECT_REQUEST, right? An EJECT_REQUEST from a bay device
> > should always just signal userspace, and never actually cause the device
> > to be deleted. I don't really like the way that you're remapping event
> > types inside the dock driver - it'd be cleaner if the per-driver
> > handlers received ADD_DEVICE or REMOVE_DEVICE or something.
> It's not forcely ejected. This patch adds a check in dock.c, if eject
> request is for an ata bay, we just signal userspace. Latter if a
> device/bus check invoked, dock driver will check status, and doing force
> eject. At this time, ata's EJECT_REQUEST handler will be called.
> Remapping event is to make per-driver handlers easy. complex is all in
> dock driver.
I still don't get a uevent signalled to userspace for a bay device in my
dock station when pressing the lever on the bay device. I think I'll get
to debug this by the end of the week or the weekend if you like...
Regards,
Holger
next prev parent reply other threads:[~2008-06-10 8:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-06 5:23 [PATCH 6/8] libata hotplug to align with dock driver Shaohua Li
2008-06-09 1:37 ` Matthew Garrett
2008-06-09 19:15 ` Henrique de Moraes Holschuh
2008-06-10 1:34 ` Shaohua Li
2008-06-10 8:15 ` Holger Macht [this message]
2008-06-10 8:27 ` Shaohua Li
2008-06-10 16:43 ` Holger Macht
2008-06-11 3:23 ` Shaohua Li
2008-06-11 12:52 ` Holger Macht
2008-06-12 1:23 ` Shaohua Li
2008-06-16 12:49 ` Holger Macht
2008-06-18 4:02 ` Shaohua Li
-- strict thread matches above, loose matches on Subject: below --
2008-05-22 6:34 Shaohua Li
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=20080610081527.GB29300@homac \
--to=hmacht@suse.de \
--cc=hmh@hmh.eng.br \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=kristen.c.accardi@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=shaohua.li@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox