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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <489A03C3.5070607@ru.mvista.com>
Date:	Thu, 07 Aug 2008 00:04:19 +0400
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	petkovbb@...il.com
Cc:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH 1/2] pata_legacy: export functionality to ide

Borislav Petkov wrote:

>>>>>From: Borislav Petkov <petkovbb@...il.com>
>>>>>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@...mvista.com>
>>>>>Signed-off-by: Borislav Petkov <petkovbb@...il.com>

>>>>Acked-by: Sergei Shtylyov <sshtylyov@...mvista.com>

>>>>>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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/