Linux ATA/IDE development
 help / color / mirror / Atom feed
* Re: detect and warn about ahci-remapped NVMe devices
From: Tejun Heo @ 2016-12-05 19:33 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: dan.j.williams, linux-ide, linux-nvme
In-Reply-To: <1480703463-17489-1-git-send-email-hch@lst.de>

Hello,

On Fri, Dec 02, 2016 at 07:31:00PM +0100, Christoph Hellwig wrote:
> Just a small band-aid to detect the AHCI-remapped NVMe devices
> for now.  Hopefully we'll eventually get a fake PCIe root port
> driver ala VMD for them.

Applied 1-3 to libata/for-4.10.  Fixed the dup constant definition in
0002.

Thanks.

-- 
tejun

^ permalink raw reply

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Tejun Heo @ 2016-12-05 19:23 UTC (permalink / raw)
  To: whiteheadm; +Cc: One Thousand Gnomes, Sergei Shtylyov, linux-ide
In-Reply-To: <CAP8WD_bUW9cAAQpvenL73sxvpoxNYwZdRqpj92YWEyanK51+0g@mail.gmail.com>

Hello,

Hmm... I'm a bit confused.  These resources are tied to the platform
device which is unregistered on probe failure which will invoke
devres_release_all().

Matthew, can you please apply the following patch and see whether
device_release() gets invoked?

Thanks.

diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index bce2a8c..0dd72ce 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -1013,6 +1013,7 @@ static __init int legacy_init_one(struct legacy_probe *probe)
 	}
 	ata_host_detach(host);
 fail:
+	printk("XXX pata_legacy: unregistering platform dev %p\n", pdev);
 	platform_device_unregister(pdev);
 	return ret;
 }
diff --git a/drivers/base/core.c b/drivers/base/core.c
index ce057a5..a3d112d 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -237,6 +237,7 @@ static void device_release(struct kobject *kobj)
 	 * is deleted but alive, so release devres here to avoid
 	 * possible memory leak.
 	 */
+	printk("XXX device_release: invoking devres_release_all\n");
 	devres_release_all(dev);
 
 	if (dev->release)


^ permalink raw reply related

* Re: [PATCH 2/3] ahci-remap.h: add ahci remapping definitions
From: Christoph Hellwig @ 2016-12-05 15:31 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: Christoph Hellwig, tj, dan.j.williams, linux-ide, linux-nvme
In-Reply-To: <aa6cba2c-6cf7-0222-b871-d98d1c8e4fe8@cogentembedded.com>

On Sat, Dec 03, 2016 at 01:57:01PM +0300, Sergei Shtylyov wrote:
>> +#ifndef _LINUX_AHCI_REMAP_H
>> +#define _LINUX_AHCI_REMAP_H
>> +
>> +#include <linux/sizes.h>
>> +
>> +#define AHCI_VSCAP		0xa4
>> +#define AHCI_REMAP_CAP		0x800
>> +#define AHCI_VSCAP		0xa4
>
>    Why do it twice?

No good reason, probably just me messing up the move..

^ permalink raw reply

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: tedheadster @ 2016-12-05 14:19 UTC (permalink / raw)
  To: Tejun Heo; +Cc: One Thousand Gnomes, Sergei Shtylyov, linux-ide
In-Reply-To: <20161202170705.GB6033@htj.duckdns.org>

Tejun,
  that new patch worked better.

Here is the dmesg output:

[   34.347350] scsi0 : pata_legacy
[   34.367366] ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
[   34.523330] ata1.00: ATA-4: QUANTUM FIREBALL CR8.4A, A5U.1200, max UDMA/66
[   34.524804] ata1.00: 16514064 sectors, multi 0: LBA
[   34.525747] ata1.00: configured for PIO
[   34.569330] scsi 0:0:0:0: Direct-Access     ATA      QUANTUM
FIREBALL A5U. PQ: 0 ANSI: 5
[   34.655313] sd 0:0:0:0: [sda] 16514064 512-byte logical blocks:
(8.45 GB/7.87 GiB)
[   34.674309] sd 0:0:0:0: [sda] Write Protect is off
[   34.675683] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   34.689347] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   34.691283] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   34.800293]  sda: sda1 sda2 sda3 sda4
[   34.890325] sd 0:0:0:0: [sda] Attached SCSI disk
[   34.976270] scsi1 : pata_legacy
[   34.999263] ata2: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15
[   35.448191] scsi2 : pata_legacy
[   35.486192] ata3: PATA max PIO4 cmd 0x1e8 ctl 0x3ee irq 11
[   35.997114] scsi3 : pata_legacy
[   36.051103] ata4: PATA max PIO4 cmd 0x168 ctl 0x36e irq 10
[   36.384057] genirq: Flags mismatch irq 8. 00000000 (platform) vs.
00000000 (rtc0)
[   36.571024] scsi4 : pata_legacy
[   36.626014] ata5: PATA max PIO4 cmd 0x160 ctl 0x366 irq 12
[   42.143223] EXT4-fs (sda4): mounting ext3 file system using the
ext4 subsystem

and /proc/interrupts looks good:

           CPU0
  0:     558552    XT-PIC-XT-PIC    timer
  1:        337    XT-PIC-XT-PIC    i8042
  2:          0    XT-PIC-XT-PIC    cascade
  4:          1    XT-PIC-XT-PIC
  8:          0    XT-PIC-XT-PIC    rtc0
 14:      51538    XT-PIC-XT-PIC    platform

I would still like to get my patch in. If you have a motherboard where
you cannot disable the secondary hard drive controllers, the
pata_legacy driver will detect them and allocate the interrupt. Some
way to disable this behavior is useful.

- Matthew

^ permalink raw reply

* Re: [PATCH 2/3] ahci-remap.h: add ahci remapping definitions
From: Sergei Shtylyov @ 2016-12-03 10:57 UTC (permalink / raw)
  To: Christoph Hellwig, tj; +Cc: dan.j.williams, linux-ide, linux-nvme
In-Reply-To: <1480703463-17489-3-git-send-email-hch@lst.de>

Hello.

On 12/2/2016 9:31 PM, Christoph Hellwig wrote:

> From: Dan Williams <dan.j.williams@intel.com>
>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> [hch: split into a separate header and commit]
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  include/linux/ahci-remap.h | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 include/linux/ahci-remap.h
>
> diff --git a/include/linux/ahci-remap.h b/include/linux/ahci-remap.h
> new file mode 100644
> index 0000000..883d366
> --- /dev/null
> +++ b/include/linux/ahci-remap.h
> @@ -0,0 +1,29 @@
> +#ifndef _LINUX_AHCI_REMAP_H
> +#define _LINUX_AHCI_REMAP_H
> +
> +#include <linux/sizes.h>
> +
> +#define AHCI_VSCAP		0xa4
> +#define AHCI_REMAP_CAP		0x800
> +#define AHCI_VSCAP		0xa4

    Why do it twice?

MBR, Sergei


^ permalink raw reply

* [PATCH 3/3] ahci: warn about remapped NVMe devices
From: Christoph Hellwig @ 2016-12-02 18:31 UTC (permalink / raw)
  To: tj; +Cc: dan.j.williams, linux-ide, linux-nvme
In-Reply-To: <1480703463-17489-1-git-send-email-hch@lst.de>

Some Intel ahci implementations have a completely broken remapping mode
where they hide one or more NVMe devices behind the bar of an AHCI device.

Intel refuses to let the OS reprogram the BIOS to switch out of this
mode at runtime, and so far we're not come up with another good way
to undo the mess that the Chipset people created.  So for now the only
thing we can do is to alert users about this situation and switch to the
faster and much saner so called "AHCI" mode insted of the RAID mode in
the BIOS so that the BIOS does not hide the NVMe devices from us.

The sitation is even worse as at least one vendor (thanks a lot Lenovo..)
has started hardcoding their BIOS into the "RAID" mode even for laptops
that don't use AHCI _at all_ and just have a single NVMe device.  For now
there is an unspported Linux-only BIOS that undoes this braindamage,
but we'll have to see if things are getting better or worse from here.

Based on an earlier patch from Dan Williams <dan.j.williams@intel.com>.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/ata/ahci.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index ba5f11c..516a689 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -46,6 +46,8 @@
 #include <scsi/scsi_host.h>
 #include <scsi/scsi_cmnd.h>
 #include <linux/libata.h>
+#include <linux/ahci-remap.h>
+#include <linux/io-64-nonatomic-lo-hi.h>
 #include "ahci.h"
 
 #define DRV_NAME	"ahci"
@@ -1400,6 +1402,40 @@ static irqreturn_t ahci_thunderx_irq_handler(int irq, void *dev_instance)
 }
 #endif
 
+static void ahci_remap_check(struct pci_dev *pdev, int bar,
+		struct ahci_host_priv *hpriv)
+{
+	int i, count = 0;
+	u32 cap;
+
+	/*
+	 * Check if this device might have remapped nvme devices.
+	 */
+	if (pdev->vendor != PCI_VENDOR_ID_INTEL ||
+	    pci_resource_len(pdev, bar) < SZ_512K ||
+	    bar != AHCI_PCI_BAR_STANDARD ||
+	    !(readl(hpriv->mmio + AHCI_VSCAP) & 1))
+		return;
+
+	cap = readq(hpriv->mmio + AHCI_REMAP_CAP);
+	for (i = 0; i < AHCI_MAX_REMAP; i++) {
+		if ((cap & (1 << i)) == 0)
+			continue;
+		if (readl(hpriv->mmio + ahci_remap_dcc(i))
+				!= PCI_CLASS_STORAGE_EXPRESS)
+			continue;
+
+		/* We've found a remapped device */
+		count++;
+	}
+
+	if (!count)
+		return;
+
+	dev_warn(&pdev->dev, "Found %d remapped NVMe devices.\n", count);
+	dev_warn(&pdev->dev, "Switch your BIOS from RAID to AHCI mode to use them.\n");
+}
+
 static int ahci_get_irq_vector(struct ata_host *host, int port)
 {
 	return pci_irq_vector(to_pci_dev(host->dev), port);
@@ -1545,6 +1581,9 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	hpriv->mmio = pcim_iomap_table(pdev)[ahci_pci_bar];
 
+	/* detect remapped nvme devices */
+	ahci_remap_check(pdev, ahci_pci_bar, hpriv);
+
 	/* must set flag prior to save config in order to take effect */
 	if (ahci_broken_devslp(pdev))
 		hpriv->flags |= AHCI_HFLAG_NO_DEVSLP;
-- 
2.1.4


^ permalink raw reply related

* [PATCH 2/3] ahci-remap.h: add ahci remapping definitions
From: Christoph Hellwig @ 2016-12-02 18:31 UTC (permalink / raw)
  To: tj; +Cc: dan.j.williams, linux-ide, linux-nvme
In-Reply-To: <1480703463-17489-1-git-send-email-hch@lst.de>

From: Dan Williams <dan.j.williams@intel.com>

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
[hch: split into a separate header and commit]
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 include/linux/ahci-remap.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 include/linux/ahci-remap.h

diff --git a/include/linux/ahci-remap.h b/include/linux/ahci-remap.h
new file mode 100644
index 0000000..883d366
--- /dev/null
+++ b/include/linux/ahci-remap.h
@@ -0,0 +1,29 @@
+#ifndef _LINUX_AHCI_REMAP_H
+#define _LINUX_AHCI_REMAP_H
+
+#include <linux/sizes.h>
+
+#define AHCI_VSCAP		0xa4
+#define AHCI_REMAP_CAP		0x800
+#define AHCI_VSCAP		0xa4
+
+/* device class code */
+#define AHCI_REMAP_N_DCC	0x880
+
+/* remap-device base relative to ahci-bar */
+#define AHCI_REMAP_N_OFFSET	SZ_16K
+#define AHCI_REMAP_N_SIZE	SZ_16K
+
+#define AHCI_MAX_REMAP		3
+
+static inline unsigned int ahci_remap_dcc(int i)
+{
+	return AHCI_REMAP_N_DCC + i * 0x80;
+}
+
+static inline unsigned int ahci_remap_base(int i)
+{
+	return AHCI_REMAP_N_OFFSET + i * AHCI_REMAP_N_SIZE;
+}
+
+#endif /* _LINUX_AHCI_REMAP_H */
-- 
2.1.4


^ permalink raw reply related

* [PATCH 1/3] nvme: move NVMe class code to pci_ids.h
From: Christoph Hellwig @ 2016-12-02 18:31 UTC (permalink / raw)
  To: tj; +Cc: dan.j.williams, linux-ide, linux-nvme
In-Reply-To: <1480703463-17489-1-git-send-email-hch@lst.de>

We'll need to check for it in the AHCI drivers (yes, really) soon.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/nvme/host/pci.c | 3 ---
 include/linux/pci_ids.h | 2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 0fc99f0..2c58f15 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2064,9 +2064,6 @@ static const struct pci_error_handlers nvme_err_handler = {
 	.reset_notify	= nvme_reset_notify,
 };
 
-/* Move to pci_ids.h later */
-#define PCI_CLASS_STORAGE_EXPRESS	0x010802
-
 static const struct pci_device_id nvme_id_table[] = {
 	{ PCI_VDEVICE(INTEL, 0x0953),
 		.driver_data = NVME_QUIRK_STRIPE_SIZE |
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index c58752f..a5e6c7b 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -23,8 +23,10 @@
 #define PCI_CLASS_STORAGE_SATA		0x0106
 #define PCI_CLASS_STORAGE_SATA_AHCI	0x010601
 #define PCI_CLASS_STORAGE_SAS		0x0107
+#define PCI_CLASS_STORAGE_EXPRESS	0x010802
 #define PCI_CLASS_STORAGE_OTHER		0x0180
 
+
 #define PCI_BASE_CLASS_NETWORK		0x02
 #define PCI_CLASS_NETWORK_ETHERNET	0x0200
 #define PCI_CLASS_NETWORK_TOKEN_RING	0x0201
-- 
2.1.4


^ permalink raw reply related

* detect and warn about ahci-remapped NVMe devices
From: Christoph Hellwig @ 2016-12-02 18:31 UTC (permalink / raw)
  To: tj; +Cc: dan.j.williams, linux-ide, linux-nvme

Just a small band-aid to detect the AHCI-remapped NVMe devices
for now.  Hopefully we'll eventually get a fake PCIe root port
driver ala VMD for them.


^ permalink raw reply

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Tejun Heo @ 2016-12-02 17:07 UTC (permalink / raw)
  To: whiteheadm; +Cc: One Thousand Gnomes, Sergei Shtylyov, linux-ide
In-Reply-To: <CAP8WD_bZWeLBhLXqJG5uDwBe+zBubw+A+ecSuaihOuwvw9QoCQ@mail.gmail.com>

Hello,

Sorry, I got the order of operation wrong.  Can you please test this
one?

Thanks.

diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index bce2a8c..3a0bb89 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -962,6 +962,9 @@ static __init int legacy_init_one(struct legacy_probe *probe)
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
 
+	if (!devres_open_group(&pdev->dev, legacy_init_one, GFP_KERNEL))
+		return -ENOMEM;
+
 	ret = -EBUSY;
 	if (devm_request_region(&pdev->dev, io, 8, "pata_legacy") == NULL ||
 	    devm_request_region(&pdev->dev, io + 0x0206, 1,
@@ -1008,11 +1011,13 @@ static __init int legacy_init_one(struct legacy_probe *probe)
 		if (!ata_dev_absent(dev)) {
 			legacy_host[probe->slot] = host;
 			ld->platform_dev = pdev;
+			devres_remove_group(&pdev->dev, legacy_init_one);
 			return 0;
 		}
 	}
 	ata_host_detach(host);
 fail:
+	devres_release_group(&pdev->dev, legacy_init_one);
 	platform_device_unregister(pdev);
 	return ret;
 }

^ permalink raw reply related

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: One Thousand Gnomes @ 2016-12-02 16:24 UTC (permalink / raw)
  To: tedheadster; +Cc: Tejun Heo, Sergei Shtylyov, linux-ide
In-Reply-To: <CAP8WD_bPns6hGPWUUGbRd_20+bHX460p5szrfCP4bKr9k76wsQ@mail.gmail.com>

On Fri, 2 Dec 2016 08:37:04 -0500
tedheadster <tedheadster@gmail.com> wrote:

> Alan,
> 
> >> Alan,
> >>   on my hardware it grabbed all those interrupts, showing up in
> >> /proc/interrupts very clearly.  
> >
> > Do you have a dmesg of the boot ?
> >  
> 
> Here is the relevant dmesg information and also the /proc/interrupts results:

That's very strange. The legacy code should be seeing that no devices are
present and then dropping the controller

        /* Nothing found means we drop the port as its probably not there */

        ret = -ENODEV;
        ata_for_each_dev(dev, &ap->link, ALL) {
                if (!ata_dev_absent(dev)) {
                        legacy_host[probe->slot] = host;
                        ld->platform_dev = pdev;
                        return 0;
                }
        }
        ata_host_detach(host);


so this ought to be triggered and free up the interface and the IRQ

Alan

^ permalink raw reply

* Re: Forcing a CAP register value to make booting more reliable on the Acer Aspire Switch Alpha 12 tablet
From: Tejun Heo @ 2016-12-02 16:11 UTC (permalink / raw)
  To: Sui Chen; +Cc: linux-ide
In-Reply-To: <CAFaEeaFuQCya0HrQNSQe1f1HZ18B=iCAoXKcxdhxv3uq_OzHFA@mail.gmail.com>

Hello,

On Thu, Dec 01, 2016 at 05:57:55PM -0600, Sui Chen wrote:
> When the SSD is detected the following lines can be seen in the dmesg
> output:
>    [    1.347021] ahci 0000:00:17.0: version 3.0
>    [    1.365569] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 3 ports 6 Gbps
> 0x7 impl SATA mode
>    [    1.367519] ahci 0000:00:17.0: flags: 64bit ncq pm led clo only pio
> slum part deso sadm sds apst
>    [    1.377574] scsi host0: ahci
>    [    1.379465] scsi host1: ahci
>    [    1.381373] scsi host2: ahci
>    [    1.383060] ata1: SATA max UDMA/133 abar m2048@0xb1648000 port
> 0xb1648100 irq 124
>    [    1.384665] ata2: SATA max UDMA/133 abar m2048@0xb1648000 port
> 0xb1648180 irq 124
>    [    1.386305] ata3: SATA max UDMA/133 abar m2048@0xb1648000 port
> 0xb1648200 irq 124
> 
> However, when the SSD is not detecting:
>    [    1.337065] ahci 0000:00:17.0: version 3.0
> -> [    1.343206] ahci 0000:00:17.0: implemented port map (0x7) contains
> more ports than nr_ports (2), using nr_ports
> -> [    1.351165] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 2 ports 6 Gbps
> *0x0* impl SATA mode
>    [    1.352323] ahci 0000:00:17.0: flags: 64bit ncq pm led clo only pio
> slum part deso sadm sds apst
>    [    1.355960] scsi host0: ahci
>    [    1.357292] scsi host1: ahci
> -> [    1.358405] ata1: *DUMMY*
> -> [    1.359466] ata2: *DUMMY*

That looks like BIOS messing up initial setup.

> One can note the differences in the marked lines in the dmesg output when
> the SSD is not detecting: 1) nr_ports becomes 2 instead of 3; 2) ATA1 and
> ATA2 are both DUMMY.
> 
> Adding the following lines in the function "ahci_save_initial_config" in
> file libahci.c, line 453 seems to fix this for now:
>     if ((cap & 0xC734FF00) == 0xC734FF00) {
>         dev_info(dev, "Forcing CAP to 0xC734FF02 and port_map to 0x7!\n");
>         hpriv->saved_cap = cap = 0xC734FF02;
>         hpriv->saved_port_map = port_map = 0x7;
>     }
> 
> What the code does is to force port_map to become 0x7 and saved_cap to
> become 0xC734FF02. Actually, when the SSD is detecting the cap register
> holds a value of 0xC734FF02 but when it fails, cap can be either 0xC734FF01
> or 0xC734FF00.
> 
> My questions are:
> Is this a bad way of solving this or possibly damage the computer?
> Could this also possibly be related to the BIOS of the specific computer?

We have a bunch of system-specific workarounds implemented in ahci.c.
Look for DMI_MATCH().  I think this can be handled the same way.
Match the system and just override CAP to the sane value.

Thanks.

-- 
tejun

^ permalink raw reply

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: tedheadster @ 2016-12-02 13:37 UTC (permalink / raw)
  To: One Thousand Gnomes; +Cc: Tejun Heo, Sergei Shtylyov, linux-ide
In-Reply-To: <20161130181539.59cbec41@lxorguk.ukuu.org.uk>

Alan,

>> Alan,
>>   on my hardware it grabbed all those interrupts, showing up in
>> /proc/interrupts very clearly.
>
> Do you have a dmesg of the boot ?
>

Here is the relevant dmesg information and also the /proc/interrupts results:

dmesg info:

[   22.534587] scsi host0: pata_legacy
[   22.566618] ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
[   22.730639] ata1.00: ATA-4: QUANTUM FIREBALL CR8.4A, A5U.1200, max UDMA/66
[   22.730639] ata1.00: 16514064 sectors, multi 0: LBA
[   22.730639] ata1.00: configured for PIO
[   22.738601] scsi 0:0:0:0: Direct-Access     ATA      QUANTUM
FIREBALL 1200 PQ: 0 ANSI: 5
[   22.798627] sd 0:0:0:0: [sda] 16514064 512-byte logical blocks:
(8.45 GB/7.87 GiB)
[   22.818640] sd 0:0:0:0: [sda] Write Protect is off
[   22.818640] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   22.830629] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[   22.934729]  sda: sda1 sda2 sda3 sda4
[   23.062648] sd 0:0:0:0: [sda] Attached SCSI disk
[   23.162640] scsi host1: pata_legacy
[   23.186648] ata2: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15
[   23.494643] scsi host2: pata_legacy
[   23.518656] ata3: PATA max PIO4 cmd 0x1e8 ctl 0x3ee irq 11
[   23.830691] scsi host3: pata_legacy
[   23.854692] ata4: PATA max PIO4 cmd 0x168 ctl 0x36e irq 10
[   24.086711] genirq: Flags mismatch irq 8. 00000000 (pata_legacy.4)
vs. 00000000 (rtc0)
[   24.190692] scsi host4: pata_legacy
[   24.214697] ata5: PATA max PIO4 cmd 0x160 ctl 0x366 irq 12

/proc/interrupts info :

           CPU0
  0:      49060    XT-PIC  timer
...
 10:          0    XT-PIC  pata_legacy.3
 11:          0    XT-PIC  pata_legacy.2
 12:          0    XT-PIC  pata_legacy.5
 14:      41233    XT-PIC  pata_legacy.0
 15:          0    XT-PIC  pata_legacy.1
...

Tejun: I will build a kernel with your patches today and let you know
the results.

- Matthew

^ permalink raw reply

* Re: [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
From: Dennis Chen @ 2016-12-02  6:04 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-ide, Lorenzo Pieralisi, Steve Capper, Marc Zyngier,
	linux-pci, Tom Long Nguyen, Bjorn Helgaas, Greg Kroah-Hartman,
	Tejun Heo, nd, linux-arm-kernel
In-Reply-To: <20161201085243.GA24684@lst.de>

On Thu, Dec 01, 2016 at 09:52:43AM +0100, Christoph Hellwig wrote:
> Hi Dennis,
> 
> I've fixed ahci to treat all errors the same in the meantime, please
> try latest Linux tree.  That being said I don't like the different
> error returns from __pci_enable_msi_range (and __pci_enable_msix_range),
> but they have been there for a while.

Ah, I've noticed that you have the fix recently which is somehow to weaken
the necessary of the change. But, that also being said that I don't like we insist
at least the inconsistent either just because something has been there *for a while*.
Both below comments from cpi_alloc_irq_vectors_affinity() and the logic itself
leads us to think that the correct return value is -NOSPC:
/**
 *...
 *Return the number of vectors allocated,
 * (which might be smaller than @max_vecs) if successful, or a negative
 * error code on error. If less than @min_vecs interrupt vectors are
 * available for @dev the function will fail with -ENOSPC.
 * ...
*/

People maybe argue that almost has no device drivers depending on the different
return value, then why we still need to do that?

Thanks,
Dennis 

^ permalink raw reply

* Forcing CAP register value to make booting more reliable on the Acer Aspire Switch Alpha 12 tablet
From: Sui Chen @ 2016-12-02  0:05 UTC (permalink / raw)
  To: linux-ide

Hello, Linux-IDE mailing list,

I recently bought an Acer Aspire Switch Alpha 12 (Model Number: SA5-271) 
2-in-1 convertible computer. This computer has an Intel Skylake i5-6200U 
processor and a Lite-On CV1-8B256 SSD.

I noticed that the kernel will intermittently fail to detect the SSD as 
/dev/sda and may be fixed by changing seemingly unrelated settings in 
the BIOS (such as clearing secure boot databases) or with a "dirty hack" 
in libahci.c (tested on Kernel 4.8). When the SSD is not detected, the 
kernel will print an alert saying "Gave Up waiting for root device. 
Alert! /dev/disk/by-uuid/ does not exist. Dropping to a shell." Typing 
"blkid" in the initramfs shell shows no devices either.

When the SSD is detected the following lines can be seen in the dmesg 
output:
    [    1.347021] ahci 0000:00:17.0: version 3.0
    [    1.365569] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 3 ports 6 
Gbps 0x7 impl SATA mode
    [    1.367519] ahci 0000:00:17.0: flags: 64bit ncq pm led clo only 
pio slum part deso sadm sds apst
    [    1.377574] scsi host0: ahci
    [    1.379465] scsi host1: ahci
    [    1.381373] scsi host2: ahci
    [    1.383060] ata1: SATA max UDMA/133 abar m2048@0xb1648000 port 
0xb1648100 irq 124
    [    1.384665] ata2: SATA max UDMA/133 abar m2048@0xb1648000 port 
0xb1648180 irq 124
    [    1.386305] ata3: SATA max UDMA/133 abar m2048@0xb1648000 port 
0xb1648200 irq 124

However, when the SSD is not detecting:
    [    1.337065] ahci 0000:00:17.0: version 3.0
-> [    1.343206] ahci 0000:00:17.0: implemented port map (0x7) contains 
more ports than nr_ports (2), using nr_ports
-> [    1.351165] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 2 ports 6 
Gbps 0x0 impl SATA mode
    [    1.352323] ahci 0000:00:17.0: flags: 64bit ncq pm led clo only 
pio slum part deso sadm sds apst
    [    1.355960] scsi host0: ahci
    [    1.357292] scsi host1: ahci
-> [    1.358405] ata1: DUMMY
-> [    1.359466] ata2: DUMMY

One can note the differences in the marked lines in the dmesg output 
when the SSD is not detecting: 1) nr_ports becomes 2 instead of 3; 2) 
ATA1 and ATA2 are both DUMMY.


Adding the following lines in the function "ahci_save_initial_config" in 
file libahci.c, line 453 seems to fix this for now:
     if ((cap & 0xC734FF00) == 0xC734FF00) {
         dev_info(dev, "Forcing CAP to 0xC734FF02 and port_map to 0x7!\n");
         hpriv->saved_cap = cap = 0xC734FF02;
         hpriv->saved_port_map = port_map = 0x7;
     }

What the code does is to force port_map to become 0x7 and saved_cap to 
become 0xC734FF02. Actually, when the SSD is detecting the cap register 
holds a value of 0xC734FF02 but when it fails, cap can be either 
0xC734FF01 or 0xC734FF00.

My questions are:
Is this a bad way of solving this; can it possibly damage the computer?
Could this be possibly related to the BIOS of the specific computer?

Thank you so much!
2016-12-01
Sui


^ permalink raw reply

* LSF/MM 2017: Call for Proposals
From: Jeff Layton @ 2016-12-01 14:11 UTC (permalink / raw)
  To: linux-block, linux-btrfs, linux-cifs, linux-ext4, linux-fsdevel,
	linux-ide, linux-kernel, linux-mm, linux-nfs, linux-scsi,
	xfs@oss.sgi.com, ceph-devel, linux-nvme
  Cc: lsf-pc@lists.linux-foundation.org

The annual Linux Storage, Filesystem and Memory Management (LSF/MM)
Summit for 2017 will be held on March 20th and 21st at the Hyatt
Cambridge, Cambridge, MA. LSF/MM is an invitation-only technical
workshop to map out improvements to the Linux storage, filesystem and
memory management subsystems that will make their way into the mainline
kernel within the coming years.

    http://events.linuxfoundation.org/events/linux-storage-filesystem-and-mm-summit

Like last year, LSF/MM will be colocated with the Linux Foundation Vault
conference which takes place on March 22nd and 23rd in the same Venue.
For those that do not know, Vault is designed to be an event where open
source storage and filesystem practitioners meet storage implementors
and, as such, it would be of benefit for LSF/MM attendees to attend.

Unlike past years, Vault admission is not free for LSF/MM attendees this
year unless they're giving a talk. There is a discount for LSF/MM
attendees, however we would also like to encourage folks to submit talk
proposals to speak at the Vault conference.

    http://events.linuxfoundation.org/events/vault

On behalf of the committee I am issuing a call for agenda proposals that
are suitable for cross-track discussion as well as technical subjects
for the breakout sessions.

If advance notice is required for visa applications then please point
that out in your proposal or request to attend, and submit the topic
as soon as possible.

1) Proposals for agenda topics should be sent before January 15th, 2016
to:

    lsf-pc@lists.linux-foundation.org

and cc the Linux list or lists that are relevant for the topic in
question:

    ATA:   linux-ide@vger.kernel.org
    Block: linux-block@vger.kernel.org
    FS:    linux-fsdevel@vger.kernel.org
    MM:    linux-mm@kvack.org
    SCSI:  linux-scsi@vger.kernel.org
    NVMe:  linux-nvme@lists.infradead.org

Please tag your proposal with [LSF/MM TOPIC] to make it easier to track.
In addition, please make sure to start a new thread for each topic
rather than following up to an existing one.  Agenda topics and
attendees will be selected by the program committee, but the final
agenda will be formed by consensus of the attendees on the day.

2) Requests to attend the summit for those that are not proposing a
topic should be sent to:

    lsf-pc@lists.linux-foundation.org

Please summarise what expertise you will bring to the meeting, and what
you would like to discuss. Please also tag your email with [LSF/MM
ATTEND] and send it as a new thread so there is less chance of it
getting lost.

We will try to cap attendance at around 25-30 per track to facilitate
discussions although the final numbers will depend on the room sizes at
the venue.

Brief presentations are allowed to guide discussion, but are strongly
discouraged. There will be no recording or audio bridge. However, we
expect that written minutes will be published as we did in previous
years:

2016: https://lwn.net/Articles/lsfmm2016/

2015: https://lwn.net/Articles/lsfmm2015/

2014: http://lwn.net/Articles/LSFMM2014/

2013: http://lwn.net/Articles/548089/

3) If you have feedback on last year's meeting that we can use to
improve this year's, please also send that to:

    lsf-pc@lists.linux-foundation.org

Thank you on behalf of the program committee:

Storage:
    James Bottomley
    Martin K. Petersen (track chair)
    Sagi Grimberg

Filesystems:
    Anna Schumaker
    Chris Mason
    Eric Sandeen
    Jan Kara
    Jeff Layton (summit chair)
    Josef Bacik (track chair)
    Trond Myklebust

MM:
    Johannes Weiner
    Rik van Riel (track chair)
-- 
Jeff Layton <jlayton@poochiereds.net>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
From: Christoph Hellwig @ 2016-12-01  8:52 UTC (permalink / raw)
  To: Dennis Chen
  Cc: linux-ide, Lorenzo Pieralisi, Greg Kroah-Hartman, Marc Zyngier,
	linux-pci, Steve Capper, Bjorn Helgaas, Tom Long Nguyen,
	Tejun Heo, nd, Christoph Hellwig, linux-arm-kernel
In-Reply-To: <1480558504-18691-1-git-send-email-dennis.chen@arm.com>

Hi Dennis,

I've fixed ahci to treat all errors the same in the meantime, please
try latest Linux tree.  That being said I don't like the different
error returns from __pci_enable_msi_range (and __pci_enable_msix_range),
but they have been there for a while.

^ permalink raw reply

* [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
From: Dennis Chen @ 2016-12-01  2:15 UTC (permalink / raw)
  To: linux-pci
  Cc: linux-ide, Lorenzo Pieralisi, Steve Capper, Marc Zyngier,
	Tom Long Nguyen, Bjorn Helgaas, Greg Kroah-Hartman, Tejun Heo,
	Dennis Chen, nd, Christoph Hellwig, linux-arm-kernel

The __pci_enable_msi_range() should return -ENOSPC instead of -EINVAL
when the device doesn't have enough vectors as required, just as the 
MSI-X vector allocator does in __pci_enable_msix_range(). Otherwise, 
some drivers depending on that return value will probably fallback to
the legacy interrupt directly, for example, in commit 17a51f12cfbd2814
("ahci: only try to use multi-MSI mode if there is more than 1 port"), the
ahci driver will fallback to single MSI mode only when the return value
is -ENOSPC in case of required vectors is not enough, else the driver will
use legacy interrupt which has been observed on a x86 box with 6-port SATA
controller.

With this patch, when a MSI-capable device doesn't have enough MSI
vectors as requested, it will fallback to single MSI mode while not
legacy interrupt.

Signed-off-by: Dennis Chen <dennis.chen@arm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Tom Long Nguyen <tom.l.nguyen@intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: linux-ide@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 drivers/pci/msi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index ad70507..da37113 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1084,7 +1084,7 @@ static int __pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec,
 	if (nvec < 0)
 		return nvec;
 	if (nvec < minvec)
-		return -EINVAL;
+		return -ENOSPC;
 
 	if (nvec > maxvec)
 		nvec = maxvec;
-- 
2.7.4

^ permalink raw reply related

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Tejun Heo @ 2016-11-30 20:22 UTC (permalink / raw)
  To: whiteheadm; +Cc: One Thousand Gnomes, Sergei Shtylyov, linux-ide
In-Reply-To: <CAP8WD_boGwPZCEPE8hA-AhQnHChrbaM+74LTUy-9__s6ex56Sg@mail.gmail.com>

Hello,

On Wed, Nov 30, 2016 at 10:03:47AM -0500, tedheadster wrote:
>   on my hardware it grabbed all those interrupts, showing up in
> /proc/interrupts very clearly.

Can you please see whether the following patch makes a difference?

Thanks.

diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index bce2a8c..fdc2b4f 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -962,6 +962,9 @@ static __init int legacy_init_one(struct legacy_probe *probe)
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
 
+	if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL))
+		return -ENOMEM;
+
 	ret = -EBUSY;
 	if (devm_request_region(&pdev->dev, io, 8, "pata_legacy") == NULL ||
 	    devm_request_region(&pdev->dev, io + 0x0206, 1,
@@ -1008,12 +1011,14 @@ static __init int legacy_init_one(struct legacy_probe *probe)
 		if (!ata_dev_absent(dev)) {
 			legacy_host[probe->slot] = host;
 			ld->platform_dev = pdev;
+			devres_remove_group(&pdev->dev, NULL);
 			return 0;
 		}
 	}
 	ata_host_detach(host);
 fail:
 	platform_device_unregister(pdev);
+	devres_release_group(&pdev->dev, NULL);
 	return ret;
 }
 

^ permalink raw reply related

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: One Thousand Gnomes @ 2016-11-30 18:15 UTC (permalink / raw)
  To: tedheadster; +Cc: Sergei Shtylyov, linux-ide
In-Reply-To: <CAP8WD_boGwPZCEPE8hA-AhQnHChrbaM+74LTUy-9__s6ex56Sg@mail.gmail.com>

On Wed, 30 Nov 2016 10:03:47 -0500
tedheadster <tedheadster@gmail.com> wrote:

> On Wed, Nov 30, 2016 at 9:53 AM, One Thousand Gnomes
> <gnomes@lxorguk.ukuu.org.uk> wrote:
> > On Wed, 30 Nov 2016 16:11:39 +0300
> > Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote:
> >  
> >> Hello.
> >>
> >> On 11/29/2016 08:53 PM, Matthew Whitehead wrote:
> >>  
> >> > If there is no PCI bus detected in drivers/ata/pata_legacy.c, it registers all the
> >> > common legacy PATA devices. This includes I/O ports (0x1f0, 0x170, 0x1e8, 0x168, 0x1e0, 0x160)
> >> > and also their associated interrupts (14,15,11,10,8,12).
> >> >
> >> > Unfortunately, on such systems those interrupt lines are at a premium because there is no
> >> > PCI alternative. This patch allows you to disable individual port/interrupt pairs by providing
> >> > a list of ports to skip allocating.  
> >
> > In what situation do you actually hit this. The probes should fail so the
> > interrupt shouldn't end up allocated.
> >  
> 
> Alan,
>   on my hardware it grabbed all those interrupts, showing up in
> /proc/interrupts very clearly.

Do you have a dmesg of the boot ?

Alan

^ permalink raw reply

* [PATCH,v3] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Matthew Whitehead @ 2016-11-30 18:14 UTC (permalink / raw)
  To: linux-ide, tj, b.zolnierkie, sergei.shtylyov, gnomes; +Cc: Matthew Whitehead
In-Reply-To: <1480440386-20400-1-git-send-email-tedheadster@gmail.com>

If there is no PCI bus detected in drivers/ata/pata_legacy.c, it registers all
the common legacy PATA devices. This includes I/O ports (0x1f0, 0x170, 0x1e8,
0x168, 0x1e0, 0x160) and also their associated interrupts (14,15,11,10,8,12).

Unfortunately, on such systems those interrupt lines are at a premium because
there is no PCI alternative. This patch allows you to disable individual
port/interrupt pairs by providing a list of ports to skip allocating.

modprobe pata_legacy ignore_ports=0x1e8,0x168,0x1e0,0x160

Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
---
 drivers/ata/pata_legacy.c |   31 +++++++++++++++++++++++++------
 1 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 4fe9d21..b9b49db 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -130,6 +130,8 @@ static struct legacy_data legacy_data[NR_HOST];
 static struct ata_host *legacy_host[NR_HOST];
 static int nr_legacy_host;
 
+static int ignore_ports[NR_HOST];
+static int ignore_ports_count;
 
 static int probe_all;		/* Set to check all ISA port ranges */
 static int ht6560a;		/* HT 6560A on primary 1, second 2, both 3 */
@@ -1168,6 +1170,17 @@ static __init void probe_qdi_vlb(void)
 	}
 }
 
+static bool port_ignored(int port)
+{
+	int i;
+
+	for (i = 0; i < ignore_ports_count; i++) {
+		if (port == ignore_ports[i])
+			return true;
+	}
+	return false;
+}
+
 /**
  *	legacy_init		-	attach legacy interfaces
  *
@@ -1212,17 +1225,22 @@ static __init int legacy_init(void)
 	if (winbond == 1)
 		winbond = 0x130;	/* Default port, alt is 1B0 */
 
-	if (primary == 0 || all)
+	if ((primary == 0 || all) && !port_ignored(0x1F0))
 		legacy_probe_add(0x1F0, 14, UNKNOWN, 0);
-	if (secondary == 0 || all)
+	if ((secondary == 0 || all) && !port_ignored(0x170))
 		legacy_probe_add(0x170, 15, UNKNOWN, 0);
 
 	if (probe_all || !pci_present) {
 		/* ISA/VLB extra ports */
-		legacy_probe_add(0x1E8, 11, UNKNOWN, 0);
-		legacy_probe_add(0x168, 10, UNKNOWN, 0);
-		legacy_probe_add(0x1E0, 8, UNKNOWN, 0);
-		legacy_probe_add(0x160, 12, UNKNOWN, 0);
+
+		if (!port_ignored(0x1E8))
+			legacy_probe_add(0x1E8, 11, UNKNOWN, 0);
+		if (!port_ignored(0x168))
+			legacy_probe_add(0x168, 10, UNKNOWN, 0);
+		if (!port_ignored(0x1E0))
+			legacy_probe_add(0x1E0, 8, UNKNOWN, 0);
+		if (!port_ignored(0x160))
+			legacy_probe_add(0x160, 12, UNKNOWN, 0);
 	}
 
 	if (opti82c46x)
@@ -1272,6 +1290,7 @@ module_param(qdi, int, 0);
 module_param(winbond, int, 0);
 module_param(pio_mask, int, 0);
 module_param(iordy_mask, int, 0);
+module_param_array(ignore_ports, int, &ignore_ports_count, 0444);
 
 module_init(legacy_init);
 module_exit(legacy_exit);
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH,v2] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Sergei Shtylyov @ 2016-11-30 17:24 UTC (permalink / raw)
  To: Matthew Whitehead, linux-ide, tj, b.zolnierkie, gnomes
In-Reply-To: <1480526456-15797-1-git-send-email-tedheadster@gmail.com>

Hello.

On 11/30/2016 08:20 PM, Matthew Whitehead wrote:

> If there is no PCI bus detected in drivers/ata/pata_legacy.c, it registers all
> the common legacy PATA devices. This includes I/O ports (0x1f0, 0x170, 0x1e8,
> 0x168, 0x1e0, 0x160) and also their associated interrupts (14,15,11,10,8,12).
>
> Unfortunately, on such systems those interrupt lines are at a premium because
> there is no PCI alternative. This patch allows you to disable individual
> port/interrupt pairs by providing a list of ports to skip allocating.
>
> modprobe pata_legacy ignore_ports=0x1e8,0x168,0x1e0,0x160
>
> Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
> ---
>  drivers/ata/pata_legacy.c |   30 ++++++++++++++++++++++++------
>  1 files changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
> index 4fe9d21..65a33b4 100644
> --- a/drivers/ata/pata_legacy.c
> +++ b/drivers/ata/pata_legacy.c
> @@ -130,6 +130,8 @@ static struct legacy_data legacy_data[NR_HOST];
>  static struct ata_host *legacy_host[NR_HOST];
>  static int nr_legacy_host;
>
> +static int ignore_ports[NR_HOST];
> +static int ignore_ports_count;

    It's ignore_port_count if my grammar serves still. :-)

>
>  static int probe_all;		/* Set to check all ISA port ranges */
>  static int ht6560a;		/* HT 6560A on primary 1, second 2, both 3 */
> @@ -1168,6 +1170,16 @@ static __init void probe_qdi_vlb(void)
>  	}
>  }
>
> +static bool port_ignored(int port)
> +{
> +	int i;

    Need empty line here.

> +	for (i = 0; i < ignore_ports_count; i++) {
> +		if (port == ignore_ports[i])
> +			return 1;

    s/1/true/.

> +	}
> +	return 0;

    s/0/false/.

[...]

MBR, Sergei


^ permalink raw reply

* [PATCH,v2] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Matthew Whitehead @ 2016-11-30 17:20 UTC (permalink / raw)
  To: linux-ide, tj, b.zolnierkie, sergei.shtylyov, gnomes; +Cc: Matthew Whitehead
In-Reply-To: <1480440386-20400-1-git-send-email-tedheadster@gmail.com>

If there is no PCI bus detected in drivers/ata/pata_legacy.c, it registers all
the common legacy PATA devices. This includes I/O ports (0x1f0, 0x170, 0x1e8,
0x168, 0x1e0, 0x160) and also their associated interrupts (14,15,11,10,8,12).

Unfortunately, on such systems those interrupt lines are at a premium because
there is no PCI alternative. This patch allows you to disable individual
port/interrupt pairs by providing a list of ports to skip allocating.

modprobe pata_legacy ignore_ports=0x1e8,0x168,0x1e0,0x160

Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
---
 drivers/ata/pata_legacy.c |   30 ++++++++++++++++++++++++------
 1 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 4fe9d21..65a33b4 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -130,6 +130,8 @@ static struct legacy_data legacy_data[NR_HOST];
 static struct ata_host *legacy_host[NR_HOST];
 static int nr_legacy_host;
 
+static int ignore_ports[NR_HOST];
+static int ignore_ports_count;
 
 static int probe_all;		/* Set to check all ISA port ranges */
 static int ht6560a;		/* HT 6560A on primary 1, second 2, both 3 */
@@ -1168,6 +1170,16 @@ static __init void probe_qdi_vlb(void)
 	}
 }
 
+static bool port_ignored(int port)
+{
+	int i;
+	for (i = 0; i < ignore_ports_count; i++) {
+		if (port == ignore_ports[i])
+			return 1;
+	}
+	return 0;
+}
+
 /**
  *	legacy_init		-	attach legacy interfaces
  *
@@ -1212,17 +1224,22 @@ static __init int legacy_init(void)
 	if (winbond == 1)
 		winbond = 0x130;	/* Default port, alt is 1B0 */
 
-	if (primary == 0 || all)
+	if ((primary == 0 || all) && !port_ignored(0x1F0))
 		legacy_probe_add(0x1F0, 14, UNKNOWN, 0);
-	if (secondary == 0 || all)
+	if ((secondary == 0 || all) && !port_ignored(0x170))
 		legacy_probe_add(0x170, 15, UNKNOWN, 0);
 
 	if (probe_all || !pci_present) {
 		/* ISA/VLB extra ports */
-		legacy_probe_add(0x1E8, 11, UNKNOWN, 0);
-		legacy_probe_add(0x168, 10, UNKNOWN, 0);
-		legacy_probe_add(0x1E0, 8, UNKNOWN, 0);
-		legacy_probe_add(0x160, 12, UNKNOWN, 0);
+
+		if (!port_ignored(0x1E8))
+			legacy_probe_add(0x1E8, 11, UNKNOWN, 0);
+		if (!port_ignored(0x168))
+			legacy_probe_add(0x168, 10, UNKNOWN, 0);
+		if (!port_ignored(0x1E0))
+			legacy_probe_add(0x1E0, 8, UNKNOWN, 0);
+		if (!port_ignored(0x160))
+			legacy_probe_add(0x160, 12, UNKNOWN, 0);
 	}
 
 	if (opti82c46x)
@@ -1272,6 +1289,7 @@ module_param(qdi, int, 0);
 module_param(winbond, int, 0);
 module_param(pio_mask, int, 0);
 module_param(iordy_mask, int, 0);
+module_param_array(ignore_ports, int, &ignore_ports_count, 0444);
 
 module_init(legacy_init);
 module_exit(legacy_exit);
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: tedheadster @ 2016-11-30 17:13 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: Tejun Heo, linux-ide
In-Reply-To: <2368047.lDgGYdnaMc@amdc3058>

Bartlomiej,

> I would also prefer to have such systems detected automatically
> (i.e. by using DMI, please check dmidecode output on this board).
> If this is not possible I'm fine with the change, though I have some
> review comments to the patch itself (please see the other mail).
>

I will try dmidecode when I return from travel on Friday. I predict it
will have nothing, but I will verify. Assuming that turns out to be
correct, I'm posting my revised patch next.

- Matthew

^ permalink raw reply

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: tedheadster @ 2016-11-30 15:03 UTC (permalink / raw)
  To: One Thousand Gnomes; +Cc: Sergei Shtylyov, linux-ide
In-Reply-To: <20161130145322.252f7403@lxorguk.ukuu.org.uk>

On Wed, Nov 30, 2016 at 9:53 AM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
> On Wed, 30 Nov 2016 16:11:39 +0300
> Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote:
>
>> Hello.
>>
>> On 11/29/2016 08:53 PM, Matthew Whitehead wrote:
>>
>> > If there is no PCI bus detected in drivers/ata/pata_legacy.c, it registers all the
>> > common legacy PATA devices. This includes I/O ports (0x1f0, 0x170, 0x1e8, 0x168, 0x1e0, 0x160)
>> > and also their associated interrupts (14,15,11,10,8,12).
>> >
>> > Unfortunately, on such systems those interrupt lines are at a premium because there is no
>> > PCI alternative. This patch allows you to disable individual port/interrupt pairs by providing
>> > a list of ports to skip allocating.
>
> In what situation do you actually hit this. The probes should fail so the
> interrupt shouldn't end up allocated.
>

Alan,
  on my hardware it grabbed all those interrupts, showing up in
/proc/interrupts very clearly.

- Matthew

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox