| Message ID | 1394775970-6022-3-git-send-email-aaron.lu@intel.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On Fri, Mar 14, 2014 at 01:46:09PM +0800, Aaron Lu wrote: > If ACPI handle for an ATA device is NULL, we shouldn't call > ata_dev_get_GTF as that function will use handle to do some ACPI > evaluation. This caused a crash, right? Can you please include what can trigger such oops and how it looks like and reference to the original bug report. In general, when you're cc'ing stable, please try to provide as much information about the bug as possible so that downstreams have easier time evaluating the importance and risk of the change. The same goes for the previous patch. Thanks.
On 03/14/2014 08:58 PM, Tejun Heo wrote: > On Fri, Mar 14, 2014 at 01:46:09PM +0800, Aaron Lu wrote: >> If ACPI handle for an ATA device is NULL, we shouldn't call >> ata_dev_get_GTF as that function will use handle to do some ACPI >> evaluation. > > This caused a crash, right? Can you please include what can trigger > such oops and how it looks like and reference to the original bug > report. In general, when you're cc'ing stable, please try to provide > as much information about the bug as possible so that downstreams have > easier time evaluating the importance and risk of the change. The > same goes for the previous patch. It shouldn't cause a crash, just some error messages from ACPICA I think. There isn't a bug for it right now, I have only some vague memory that I saw such error messages when dealing with some other bugs some time ago. So perhaps I shouldn't add the stable tag, sorry for that, this seems to belong to the 'this patch solves a potential problem' case... For the 1/3 patch, no crash either. It's just that if CONFIG_PM_RUNTIME is not set, ZPODD will not function so building it doesn't make sense. Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/14/2014 10:25 PM, Aaron Lu wrote: > On 03/14/2014 08:58 PM, Tejun Heo wrote: >> On Fri, Mar 14, 2014 at 01:46:09PM +0800, Aaron Lu wrote: >>> If ACPI handle for an ATA device is NULL, we shouldn't call >>> ata_dev_get_GTF as that function will use handle to do some ACPI >>> evaluation. >> >> This caused a crash, right? Can you please include what can trigger >> such oops and how it looks like and reference to the original bug >> report. In general, when you're cc'ing stable, please try to provide >> as much information about the bug as possible so that downstreams have >> easier time evaluating the importance and risk of the change. The >> same goes for the previous patch. > > For the 1/3 patch, no crash either. It's just that if CONFIG_PM_RUNTIME > is not set, ZPODD will not function so building it doesn't make sense. No bug report for this either, I realized this when I'm preparing a test build for !CONFIG_PM_RUNTIME and found that I can still select ZPODD. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 14, 2014 at 10:32:08PM +0800, Aaron Lu wrote: > On 03/14/2014 10:25 PM, Aaron Lu wrote: > > On 03/14/2014 08:58 PM, Tejun Heo wrote: > >> On Fri, Mar 14, 2014 at 01:46:09PM +0800, Aaron Lu wrote: > >>> If ACPI handle for an ATA device is NULL, we shouldn't call > >>> ata_dev_get_GTF as that function will use handle to do some ACPI > >>> evaluation. > >> > >> This caused a crash, right? Can you please include what can trigger > >> such oops and how it looks like and reference to the original bug > >> report. In general, when you're cc'ing stable, please try to provide > >> as much information about the bug as possible so that downstreams have > >> easier time evaluating the importance and risk of the change. The > >> same goes for the previous patch. > > > > For the 1/3 patch, no crash either. It's just that if CONFIG_PM_RUNTIME > > is not set, ZPODD will not function so building it doesn't make sense. > > No bug report for this either, I realized this when I'm preparing a test > build for !CONFIG_PM_RUNTIME and found that I can still select ZPODD. Both aren't really -stable material then, right?
On 03/14/2014 10:33 PM, Tejun Heo wrote: > On Fri, Mar 14, 2014 at 10:32:08PM +0800, Aaron Lu wrote: >> On 03/14/2014 10:25 PM, Aaron Lu wrote: >>> On 03/14/2014 08:58 PM, Tejun Heo wrote: >>>> On Fri, Mar 14, 2014 at 01:46:09PM +0800, Aaron Lu wrote: >>>>> If ACPI handle for an ATA device is NULL, we shouldn't call >>>>> ata_dev_get_GTF as that function will use handle to do some ACPI >>>>> evaluation. >>>> >>>> This caused a crash, right? Can you please include what can trigger >>>> such oops and how it looks like and reference to the original bug >>>> report. In general, when you're cc'ing stable, please try to provide >>>> as much information about the bug as possible so that downstreams have >>>> easier time evaluating the importance and risk of the change. The >>>> same goes for the previous patch. >>> >>> For the 1/3 patch, no crash either. It's just that if CONFIG_PM_RUNTIME >>> is not set, ZPODD will not function so building it doesn't make sense. >> >> No bug report for this either, I realized this when I'm preparing a test >> build for !CONFIG_PM_RUNTIME and found that I can still select ZPODD. > > Both aren't really -stable material then, right? Yes. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c index 9e69a5308693..b4f7cc2522d9 100644 --- a/drivers/ata/libata-acpi.c +++ b/drivers/ata/libata-acpi.c @@ -835,6 +835,7 @@ void ata_acpi_on_resume(struct ata_port *ap) ata_for_each_dev(dev, &ap->link, ALL) { ata_acpi_clear_gtf(dev); if (ata_dev_enabled(dev) && + ata_dev_acpi_handle(dev) && ata_dev_get_GTF(dev, NULL) >= 0) dev->flags |= ATA_DFLAG_ACPI_PENDING; }
If ACPI handle for an ATA device is NULL, we shouldn't call ata_dev_get_GTF as that function will use handle to do some ACPI evaluation. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Cc: stable@vger.kernel.org --- drivers/ata/libata-acpi.c | 1 + 1 file changed, 1 insertion(+)