lkml.org 
[lkml]   [2008]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] pata_legacy: export functionality to ide
Borislav Petkov wrote:

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

>>>>Acked-by: Sergei Shtylyov <sshtylyov@ru.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


\
 
 \ /
  Last update: 2008-08-06 22:07    [W:0.118 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site