All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Jeff Garzik <jeff@garzik.org>,
	linux-ide@vger.kernel.org, linux-acpi@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 2
Date: Fri, 21 Sep 2007 11:53:33 +0900	[thread overview]
Message-ID: <46F3322D.5090407@gmail.com> (raw)
In-Reply-To: <20070921024214.GA6317@srcf.ucam.org>

Matthew Garrett wrote:
> On Fri, Sep 21, 2007 at 11:35:05AM +0900, Tejun Heo wrote:
>> Matthew Garrett wrote:
>>> The alternative would be to add a flag to the ap structure indicating 
>>> whether the hotplugging is handled by the firmware or not. If we find a 
>>> reference to a controller or port in the firmware tables, it probably 
>>> indicates that the hardware has opinions about how this should be 
>>> handled. We might be safer leaving it to the firmware in those cases, 
>>> and using that flag to skip the controller-specific hotplug code.
>> I was thinking the other way around.  I'd rather depend on hardware
>> provided events than firmware provided ones.  How about flagging drivers
>> which can do native hoplugging and using ACPI hotplugging only if the
>> driver can't do it natively?
> 
> If the manufacturers have added firmware-level hotswap interrupts, then 
> there's all sorts of insane ways they might have wired the bay up. I 
> don't really trust them to have managed to do so without breaking native 
> hotplug :) It doesn't really matter at the moment, though, since I 
> haven't actually seen any examples of hardware using anything that can 
> manage native hotplug. If anyone out there does have one, it would be 
> nice to get some feedback about what it does.

Maybe just letting both events in is the best idea.  It's not like two
duplicate events are gonna break anything and I don't think many vendors
are gonna implement separate mechanism when the default SATA phy based
one works.

-- 
tejun

  reply	other threads:[~2007-09-21  2:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-15  3:01 [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug Matthew Garrett
2007-09-15 17:06 ` [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 2 Matthew Garrett
2007-09-16 12:22   ` Tejun Heo
2007-09-20 22:04   ` Jeff Garzik
2007-09-20 22:21     ` Matthew Garrett
2007-09-21  2:35       ` Tejun Heo
2007-09-21  2:42         ` Matthew Garrett
2007-09-21  2:53           ` Tejun Heo [this message]
2007-09-21  2:57             ` Matthew Garrett
2007-09-21  3:08               ` Tejun Heo
2007-09-21  3:12                 ` Matthew Garrett
2007-09-21  3:19                   ` Tejun Heo
2007-09-24 23:14                     ` [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 3 Matthew Garrett
2007-09-27 17:26                       ` Kristen Carlson Accardi
2007-09-27 17:55                         ` Matthew Garrett
2007-09-27 20:39                           ` Henrique de Moraes Holschuh
2007-10-02 15:04                       ` Jeff Garzik
2007-10-02 18:46                         ` Matthew Garrett
2007-10-02 18:49                         ` [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 4 Matthew Garrett
2007-10-02 18:55                           ` Jeff Garzik
2007-10-02 20:38                             ` Jeff Garzik
2007-10-02 20:42                               ` Matthew Garrett
2007-10-02 21:20                               ` Matthew Garrett
2007-10-02 21:23                                 ` Jeff Garzik
2007-10-03  0:24                                   ` [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 5 Matthew Garrett
2007-10-03 20:27                                     ` 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=46F3322D.5090407@gmail.com \
    --to=htejun@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jeff@garzik.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=mjg59@srcf.ucam.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.