Re: [RFC] Changing pci_iounmap to take 'bar' argument

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> > Ok, just wanted some feedback from you. Some people prefer that I whack
> > some "token" in the vitual address at map time, or that I compare the
> > vaddr at unmap time with all PCI busses IO ranges or that sort of ugly
> > thing, it sounds to me simpler to just pass along the bar number, but I
> > wanted your and Greg's ack first.
> 
> Oh, and MIPS seems to be broken here ... it's like ppc, it's ioremap'ing
> MMIO and just using an existing mapped stuff for IO, but unconditionally
> iounmap's on pci_iounmap()... unless there is some arch black magic in
> there, that seems broken. Ralph, should I fix it while I'm at it ?

Hrm... in fact, It complicates life for drivers. There already a few
using it, and there are cases, like sym53c8xx_2, that do something like

	int bar = dodgy_logic_to_find_what_bar_to_use();

	foo = pci_iomap(dev, bar, pci_resource_len(dev, bar));

And in a completely different function, a simple

	pci_iounmap(dev, foo);

To pass the bar in there requires to either add a field to the driver
"instance" structure or to reproduce the "dodgy logic".

I've fixed them all, but I don't like the patch that much.

It may be simpler indeed for me to actually only complicate the ppc &
ppc64 pci_iounmap() implementation and have it compare the virtual
address against known PCI IO spaces...

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/