From: Levente Kurusa <levex@linux.com>
To: Aaron Lu <aaron.lu@intel.com>, Tejun Heo <tj@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux ATA/IDE <linux-ide@vger.kernel.org>,
Joe Thomas <Joe.Thomas@dothill.com>
Subject: Re: [PATCH] ahci: unregister acpi notify handler when a ZPODD is unbound
Date: Tue, 06 May 2014 09:14:07 +0200 [thread overview]
Message-ID: <53688BBF.5090406@linux.com> (raw)
In-Reply-To: <53687C1E.2020001@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]
Hi,
On 05/06/2014 08:07 AM, Aaron Lu wrote:
> On 05/06/2014 02:02 PM, Levente Kurusa wrote:
>> Hi,
>>
>> On 05/06/2014 05:16 AM, Aaron Lu wrote:
>>> On 05/01/2014 12:04 AM, Levente Kurusa wrote:
>>>> When a ZPODD device is unbound via sysfs, the acpi notify handler
>>>> is not removed. This causes panics as observed in Bug #74601. The
>>>
>>> Ah...too bad, I forgot to consider this situation, thanks for tracking
>>> this.
>>>
>>>> panic only happens when the wake happens from outside the kernel
>>>> (i.e. inserting media or pressing a button). Implement a new
>>>> ahci_remove_one function which causes zpodd_exit to be called for all
>>>> ZPODD devices on the unbound PCI device.
>>>>
>>>> Signed-off-by: Levente Kurusa <levex@linux.com>
>>>> ---
>>>>
>>>> Hi,
>>>>
>>>> I am not sure if the loop below is correct. Maybe there is a better
>>>> solution to loop through all the devices which might use ZPODD?
>>>
>>> I didn't find a proper place either. For hotplug, we did the zpodd_exit
>>> at ata_scsi_handle_link_detach. But for host controller pci device
>>> removal, we used scsi_remove_host in ata_port_detach and there is no
>>> place to add the zpodd_exit for a to-be-removed scsi device...
>>>
>>> Looks like we can only iterate the ata devices and call zpodd_exit
>>> explicitly for them if they are zpodd devices. Instead of adding a new
>>> remove callback, what about just embed that into the ata_port_detach
>>> like the following example?
>>
>> Yes, this makes more sense as this doesn't tinker with exports and such...
>> However this will throw unused variable compiler warnings if we add the
>> required #ifdefs... Maybe a new function? ata_zpodd_detach_port?
>
> I think we can omit the #ifdefs as the loop is not called frequently and
> thus doesn't cost much. We already have stubs for zpodd_dev_enabled and
> zpodd_exit.
>
Ah, I see. Shall I send V2? Any tags I should add for you?
--
Regards,
Levente Kurusa
PGP: 4EF5D641
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]
next prev parent reply other threads:[~2014-05-06 7:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 16:04 [PATCH] ahci: unregister acpi notify handler when a ZPODD is unbound Levente Kurusa
2014-04-30 18:22 ` Bartlomiej Zolnierkiewicz
2014-05-06 3:16 ` Aaron Lu
2014-05-06 6:02 ` Levente Kurusa
2014-05-06 6:07 ` Aaron Lu
2014-05-06 7:14 ` Levente Kurusa [this message]
2014-05-06 7:32 ` 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=53688BBF.5090406@linux.com \
--to=levex@linux.com \
--cc=Joe.Thomas@dothill.com \
--cc=aaron.lu@intel.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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.