Re: [PATCH 1/2] pata_legacy: export functionality to ide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Borislav Petkov wrote:

From: Borislav Petkov <petkovbb@xxxxxxxxx>
Date: Sun, 3 Aug 2008 18:46:35 +0200
Subject: [PATCH] ide-generic: handle probing of legacy io-ports v4

Avoid probing the io-ports in case an IDE PCI controller is present and it uses
the legacy iobases. If we still want to enforce the probing, we do

ide_generic.probe_mask=0x3f

on the kernel command line. The iobase checking code is adapted from
drivers/ata/pata_legacy.c after converting hex pci ids into their
corresponding
macros in <linux/pci_ids.h>.

CC: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx>
Signed-off-by: Borislav Petkov <petkovbb@xxxxxxxxx>

Acked-by: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx>

diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
index 8fe8b5b..efce159 100644
--- a/drivers/ide/ide-generic.c
+++ b/drivers/ide/ide-generic.c

[...]

@@ -100,19 +101,69 @@ static const u16 legacy_bases[] = { 0x1f0, 0x170,
0x1e8, 0x168, 0x1e0, 0x160 };
static const int legacy_irqs[]  = { 14, 15, 11, 10, 8, 12 };
#endif
+static void ide_generic_check_pci_legacy_iobases(int *primary, int
*secondary)
+{
+       struct pci_dev *p = NULL;
+       u16 val;
+
+       for_each_pci_dev(p) {
+               int r;
+
+               for (r = 0; r < 6; r++) {
+                       if (pci_resource_start(p, r) == 0x1f0)
+                               *primary = 1;
+                       if (pci_resource_start(p, r) == 0x170)
+                               *secondary = 1;
+               }

Would have been probably enough to test only BAR0/2, don't you think?

I assume you're referring to the legacy ioports fixup in
drivers/pci/probe.c:pci_setup_device().

And to the fact that the value 0x1f0 should only be ever seen in BAR0 and 0x170 in BAR2 even if they would have been read off the chips (some chips have these values reading back even in legacy mode, and even could malfunction if other values are written there), not fixed up there, and certainly not in BAR1 or BAR3, so it's quite pointless to look in these BARs too.

So the comment in there saying that in some cases BAR0-3 could contain junk is a
bogus?

Don't know. The PCI IDE spec. said that those should be 0 in compatibility mode but I know that some controllers require the standard values of 0x1[f7]0 to be in BAR0/2 in compatibility mode. If my memory serves, NatSemi PC8741x were ones of those...

In other words, can we assume that one will always read 0x1f0 from BAR0
and 0x170 from BAR2 in compatibility mode.

Certainly not. We can only rely on the workaround putting 0x1[f7]0 in the resources 0/2.

If so, the check is even simpler:

	if (pci_resource_start(p, 0) == 0x1f0)
		*primary = 1;
	if (pci_resource_start(p, 2) == 0x170)
		*secondary = 1;

   Yes, I think that should be enough...

WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux