[PATCH] ide: Stop mapping ROMs

[PATCH] ide: Stop mapping ROMs

[Alan Cox]

Various old IDE drivers go mapping ROM devices for no apparent reason and
without using the ROM mapping API we now have. They don't actually use
the ROM they map and the new libata drivers are happy without it being
mapped so rather than port them lets just junk it for the next -rc1.

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/aec62xx.c linux-2.6.22-rc4-mm2/drivers/ide/pci/aec62xx.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/aec62xx.c	2007-06-07 14:26:08.000000000 +0100
+++ linux-2.6.22-rc4-mm2/drivers/ide/pci/aec62xx.c	2007-06-18 15:57:40.000000000 +0100
@@ -174,12 +174,6 @@
 {
 	int bus_speed = system_bus_clock();
 
-	if (dev->resource[PCI_ROM_RESOURCE].start) {
-		pci_write_config_dword(dev, PCI_ROM_ADDRESS, dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
-		printk(KERN_INFO "%s: ROM enabled at 0x%08lx\n", name,
-			(unsigned long)dev->resource[PCI_ROM_RESOURCE].start);
-	}
-
 	if (bus_speed <= 33)
 		pci_set_drvdata(dev, (void *) aec6xxx_33_base);
 	else
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/hpt34x.c linux-2.6.22-rc4-mm2/drivers/ide/pci/hpt34x.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/hpt34x.c	2007-06-07 14:25:58.000000000 +0100
+++ linux-2.6.22-rc4-mm2/drivers/ide/pci/hpt34x.c	2007-06-18 15:58:51.000000000 +0100
@@ -120,17 +120,10 @@
 	pci_write_config_byte(dev, HPT34X_PCI_INIT_REG, 0x00);
 	pci_read_config_word(dev, PCI_COMMAND, &cmd);
 
-	if (cmd & PCI_COMMAND_MEMORY) {
-		if (pci_resource_start(dev, PCI_ROM_RESOURCE)) {
-			pci_write_config_dword(dev, PCI_ROM_ADDRESS,
-				dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
-			printk(KERN_INFO "HPT345: ROM enabled at 0x%08lx\n",
-				(unsigned long)dev->resource[PCI_ROM_RESOURCE].start);
-		}
+	if (cmd & PCI_COMMAND_MEMORY)
 		pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0xF0);
-	} else {
+	else
 		pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0x20);
-	}
 
 	/*
 	 * Since 20-23 can be assigned and are R/W, we correct them.
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/hpt366.c linux-2.6.22-rc4-mm2/drivers/ide/pci/hpt366.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/hpt366.c	2007-06-07 14:26:08.000000000 +0100
+++ linux-2.6.22-rc4-mm2/drivers/ide/pci/hpt366.c	2007-06-18 15:59:08.000000000 +0100
@@ -993,14 +993,6 @@
 	 */
 	*info = *(struct hpt_info *)pci_get_drvdata(dev);
 
-	/*
-	 * FIXME: Not portable. Also, why do we enable the ROM in the first place?
-	 * We don't seem to be using it.
-	 */
-	if (dev->resource[PCI_ROM_RESOURCE].start)
-		pci_write_config_dword(dev, PCI_ROM_ADDRESS,
-			dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
-
 	pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, (L1_CACHE_BYTES / 4));
 	pci_write_config_byte(dev, PCI_LATENCY_TIMER, 0x78);
 	pci_write_config_byte(dev, PCI_MIN_GNT, 0x08);
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/pdc202xx_new.c linux-2.6.22-rc4-mm2/drivers/ide/pci/pdc202xx_new.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/pdc202xx_new.c	2007-06-07 14:25:58.000000000 +0100
+++ linux-2.6.22-rc4-mm2/drivers/ide/pci/pdc202xx_new.c	2007-06-18 15:59:28.000000000 +0100
@@ -369,13 +369,6 @@
 	int f, r;
 	u8 pll_ctl0, pll_ctl1;
 
-	if (dev->resource[PCI_ROM_RESOURCE].start) {
-		pci_write_config_dword(dev, PCI_ROM_ADDRESS,
-			dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
-		printk(KERN_INFO "%s: ROM enabled at 0x%08lx\n", name,
-			(unsigned long)dev->resource[PCI_ROM_RESOURCE].start);
-	}
-
 #ifdef CONFIG_PPC_PMAC
 	apple_kiwi_init(dev);
 #endif
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/pdc202xx_old.c linux-2.6.22-rc4-mm2/drivers/ide/pci/pdc202xx_old.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/ide/pci/pdc202xx_old.c	2007-06-07 14:26:08.000000000 +0100
+++ linux-2.6.22-rc4-mm2/drivers/ide/pci/pdc202xx_old.c	2007-06-18 15:59:40.000000000 +0100
@@ -314,14 +314,6 @@
 static unsigned int __devinit init_chipset_pdc202xx(struct pci_dev *dev,
 							const char *name)
 {
-	/* This doesn't appear needed */
-	if (dev->resource[PCI_ROM_RESOURCE].start) {
-		pci_write_config_dword(dev, PCI_ROM_ADDRESS,
-			dev->resource[PCI_ROM_RESOURCE].start | PCI_ROM_ADDRESS_ENABLE);
-		printk(KERN_INFO "%s: ROM enabled at 0x%08lx\n", name,
-			(unsigned long)dev->resource[PCI_ROM_RESOURCE].start);
-	}
-
 	return dev->irq;
 }
 

Re: [PATCH] ide: Stop mapping ROMs

[Sergei Shtylyov]

Hello.

Alan Cox wrote:

> Various old IDE drivers go mapping ROM devices for no apparent reason and
> without using the ROM mapping API we now have. They don't actually use

    Hm, do you mean the sysfs based aproach? I've tried that and somehow it 
failed to work for me -- that's because I deferred removing this stuff from 
the drivers.

> the ROM they map and the new libata drivers are happy without it being

    I guess ROMs used to be mappen just for dumping BIOSes...

> mapped so rather than port them lets just junk it for the next -rc1.

    I'd agree to the patch -- the drivers were mapping ROMs in a bad way, 
often using the default addresses.

MBR, Sergei

Re: [PATCH] ide: Stop mapping ROMs

[Bartlomiej Zolnierkiewicz]

On Friday 22 June 2007, Alan Cox wrote:
> Various old IDE drivers go mapping ROM devices for no apparent reason and
> without using the ROM mapping API we now have. They don't actually use
> the ROM they map and the new libata drivers are happy without it being
> mapped so rather than port them lets just junk it for the next -rc1.
> 
> Signed-off-by: Alan Cox <alan@redhat.com>

applied

Re: [PATCH] ide: Stop mapping ROMs

[Bartlomiej Zolnierkiewicz]

Hi,

On Friday 22 June 2007, Sergei Shtylyov wrote:
> Hello.
> 
> Alan Cox wrote:
> 
> > Various old IDE drivers go mapping ROM devices for no apparent reason and
> > without using the ROM mapping API we now have. They don't actually use
> 
>     Hm, do you mean the sysfs based aproach? I've tried that and somehow it 
> failed to work for me -- that's because I deferred removing this stuff from 
> the drivers.

Could you elaborate a bit about sysfs based approach?

If it indeed doesn't work we should ping PCI people about it.

> > the ROM they map and the new libata drivers are happy without it being
> 
>     I guess ROMs used to be mappen just for dumping BIOSes...
> 
> > mapped so rather than port them lets just junk it for the next -rc1.
> 
>     I'd agree to the patch -- the drivers were mapping ROMs in a bad way, 
> often using the default addresses.

I added your ACK to the patch.

Thanks,
Bart

Re: [PATCH] ide: Stop mapping ROMs

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:

>>>Various old IDE drivers go mapping ROM devices for no apparent reason and
>>>without using the ROM mapping API we now have. They don't actually use

>>    Hm, do you mean the sysfs based aproach? I've tried that and somehow it 
>>failed to work for me -- that's because I deferred removing this stuff from 
>>the drivers.

> Could you elaborate a bit about sysfs based approach?

    You can see the code is in drivers/pci/pci-sysfs.c.
    I have HPT370 as PCI device 11 -- and it fails with it in this way:

root@192.168.222.8:~# ls  -l   /sys/devices/pci0000\:00/0000\:00\:0b.0/rom
-r-------  1 root root 131072 Jun 23 21:36 21:36 
/sys/devices/pci0000:00/0000:00:0b.0/rom
root@192.168.222.8:~# echo 1 > /sys/devices/pci0000\:00/0000\:00\:0b.0/rom
root@192.168.222.8:~# od  -h   /sys/devices/pci0000\:00/0000\:00\:0b.0/rom
0000000

> If it indeed doesn't work we should ping PCI people about it.

    As you can see, the file isn't empty but 'od' fails to dump anything -- 
I've just verified this still happens with the most recent i386 kernel.
I suspect this is because ROM mapping fails... :-/

>>>mapped so rather than port them lets just junk it for the next -rc1.

>>    I'd agree to the patch -- the drivers were mapping ROMs in a bad way, 
>>often using the default addresses.

> I added your ACK to the patch.

    Well, if you think it's important... :-)
    (Yeah, I've read the recent LKML thread. :-)

> Thanks,
> Bart

MBR, Sergei