Re: pci_scan, tulip, 3c59x, multiple detections and others
Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Tue, 28 Sep 1999 20:18:09 MET-1
On 28 Sep 99 at 13:54, Jeff Garzik wrote:
> Check over the kernel archives for the recent PCI probing thread, mainly
> between myself, Donald, and Alan. There are several issues related to
> MMIO and the current scan code.
I read that thread and I was very surprised that scan.c apeared in kernel...
> > (2) store device virtual address into netdevice's priv field, if device
> > does not use it priv structure. Maybe specific vbase_addr field is better,
> > network device drivers can probably provide better comments on this (fbdev
> > has base & vbase... base is exported to userspace & passed to allocation/
> > deallocation functions, vbase is really used)
> If the driver uses MMIO, it should be using writel() and friends, and
> also calling iounmap(). Using 'vbase' or 'virt_base' or similar is best
> IMHO.
Yes. Alan recommended to use mem_start in private post; unfortunately,
at least tulip uses mem_start for something other :-( If it was not exported
to userspace...
> > (3) drivers/pci/scan.c passes physical address to driver.
> > Driver can create virtual mapping by ioremap if it needs it.
> Nah, it can be done generically in scan.c... If it uses MMIO, it
> _should_ be calling ioremap().
> said:
Yes.
> > (4) it is driver task to determine resource type (by checking
> > pci_tbl[chip_idx].pci_flags), call appropriate request_{mem,}region
> > and ioremap. If probe function fails, it must iounmap virtual
> > mapping and release registered regions.
> In the PCI probe thread Donald said there was a reason why he didn't do
> a request_region in scan.c (but he didn't elaborate)
I found it. Current code registers region as 'eth0'. You know that
this is 'eth0' after init_etherdev... We can register_region AFTER
initialization returns (with desired name), but it is not raceless solution.
> > (5) on driver unload it's driver's task to release regions and
> > iounmap virtual mappings.
> Whichever code obtains the mappings should also release them.
So another helper. Ok.
> > (4) it is driver task to determine resource type and choose
> > readb/inb depending on it. If driver needs physical address,
> > it can find it by doing
> > pdev->resource[(pci_tbl[chip_idx].pci_flags >> 4) & 7].start
> > If probe function fails, it must NOT passed virtual mapping
^^^ ... release passed ...
> > and must NOT release passed region.
> If scan.c sets up virt_base automatically, there need only be a flag
> that tells the driver whether or not to use pio.
I added flags PCI_PROBE_PHYSICAL and PCI_REGISTER_RESOURCE into pci_id_info
struct and converted tulip.c to all four formats. Shortest code came,
as expected, if probe gets virtual address and device is registered by
scanning code. Unfortunately, if you want support ifconfig, driver
must determine physical address through strange code quoted above.
And you cannot register device under name "eth0".
To be 100% correct, we should probably use base_addr field when doing
I/O and mem_start/end when doing MMIO. Otherwise ifconfig prints only
low four digits of address; and it is a bit useless on most configurations.
I'll publish some code later today.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/