From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Aaron Lu <aaron.lu@intel.com>
Cc: Tejun Heo <tj@kernel.org>, Matthew Garrett <mjg@redhat.com>,
Liu Jiang <liuj97@gmail.com>,
Dirk Griesbach <spamthis@freenet.de>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
Liu Jiang <jiang.liu@huawei.com>, Aaron Lu <aaron.lwe@gmail.com>
Subject: Re: [PATCH] libata: remove dead code from libata-acpi.c
Date: Thu, 20 Jun 2013 15:02:07 +0400 [thread overview]
Message-ID: <51C2E12F.4000603@cogentembedded.com> (raw)
In-Reply-To: <51C26861.9050106@intel.com>
Hello.
On 20-06-2013 6:26, Aaron Lu wrote:
>>>>> From: Liu Jiang <liu97@gmail.com>
>>>>>
>>>>> Commit 30dcf76acc69 "libata: migrate ACPI code over to new bindings"
>>>>> removed ACPI dock notification related code, but there's some dead
>>>>> code left, so clean up it.
[...]
> Subject: [PATCH] libata-acpi: add back ACPI based hotplug functionality
> Commit 30dcf76acc mistakenly dropped the code to register hotplug
Please specify the summary line for this commit, the same as was
done by Liu above (may use parens instead of quotes).
> notificaion handler for ATA port/devices, causing regression for people
> using ATA bay, as bug #59871 shows.
> Fix this by adding back the hotplug notification handler registration
> code. Since this code has to be run once and notification needs to be
> installed on every ATA port/devices handle no matter if there is actual
> device attached, we can't do this in binding time for ATA device ACPI
> handle, as the binding only occurs when a SCSI device is created, i.e.
> there is device attached. So introduced the ata_acpi_hotplug_init
> function to loop scan all ATA ACPI handles and if it is available,
> install the notification handler for it during ATA init time.
> With the ATA ACPI handle binding to SCSI device tree, it is possible now
> that when the SCSI hotplug work removes the SCSI device, the ACPI unbind
> function will find that the corresponding ACPI device has already been
> deleted by dock driver, causing a scaring message like:
> [ 128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt
> Fix this by waiting for SCSI hotplug task finish in our notificaion
> handler, so that the removal of ACPI device done in ACPI unbind function
> triggered by the removal of SCSI device is run earlier when ACPI device
> is still available.
> References: https://bugzilla.kernel.org/show_bug.cgi?id=59871
> Reported-and-bisected-by: Dirk Griesbach <spamthis@freenet.de>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> ---
> drivers/ata/libata-acpi.c | 34 +++++++++++++++++++++++++++++++++-
> drivers/ata/libata-core.c | 2 ++
> drivers/ata/libata.h | 2 ++
> 3 files changed, 37 insertions(+), 1 deletion(-)
> diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
> index 87f2f39..0ad54bb 100644
> --- a/drivers/ata/libata-acpi.c
> +++ b/drivers/ata/libata-acpi.c
[...]
> @@ -214,6 +216,36 @@ static const struct acpi_dock_ops ata_acpi_ap_dock_ops = {
> .uevent = ata_acpi_ap_uevent,
> };
>
> +void ata_acpi_hotplug_init(struct ata_host *host)
> +{
> + int i;
> +
> + for (i = 0; i < host->n_ports; i++) {
> + struct ata_port *ap = host->ports[i];
> + acpi_handle handle;
> + struct ata_device *dev;
> +
> + if (!ap)
> + continue;
> +
> + handle = ata_ap_acpi_handle(ap);
> + if (handle) {
> + /* we might be on a docking station */
> + register_hotplug_dock_device(handle,
> + &ata_acpi_ap_dock_ops, ap);
Please indent this line under the next character after ( above.
> + }
> +
> + ata_for_each_dev(dev, &ap->link, ALL) {
> + handle = ata_dev_acpi_handle(dev);
> + if (handle) {
> + /* we might be on a docking station */
> + register_hotplug_dock_device(handle,
> + &ata_acpi_dev_dock_ops, dev);
Same comment.
WBR, Sergei
next prev parent reply other threads:[~2013-06-20 11:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-15 3:02 [PATCH] libata: remove dead code from libata-acpi.c Liu Jiang
2013-06-17 1:50 ` Aaron Lu
2013-06-17 18:01 ` Tejun Heo
2013-06-18 1:15 ` Jiang Liu (Gerry)
2013-06-18 9:16 ` Aaron Lu
2013-06-20 2:26 ` Aaron Lu
2013-06-20 11:02 ` Sergei Shtylyov [this message]
2013-06-21 0:55 ` Aaron Lu
2013-06-21 6:29 ` Tejun Heo
2013-06-21 6:48 ` Aaron Lu
2013-06-21 11:35 ` Sergei Shtylyov
2013-06-26 6:27 ` Aaron Lu
2013-06-21 15:25 ` James Bottomley
2013-06-26 2:01 ` Aaron Lu
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=51C2E12F.4000603@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=aaron.lu@intel.com \
--cc=aaron.lwe@gmail.com \
--cc=jiang.liu@huawei.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuj97@gmail.com \
--cc=mjg@redhat.com \
--cc=spamthis@freenet.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox