Re: Exposing ROM's though sysfs

From: Vojtech Pavlik (vojtech_at_suse.cz)
Date: 07/30/04

  • Next message: Andrew Morton: "Re: dentry cache leak? Re: rsync out of memory 2.6.8-rc2"
    Date:	Fri, 30 Jul 2004 21:47:04 +0200
    To: Jon Smirl <jonsmirl@yahoo.com>
    
    

    On Fri, Jul 30, 2004 at 12:30:11PM -0700, Jon Smirl wrote:
    > --- Matthew Wilcox <willy@debian.org> wrote:
    >
    > > My problem is with this is the following passage from PCI 2.2 and PCI
    > > 2.3:
    > >
    > > In order to minimize the number of address decoders needed, a
    > > device
    > > may share a decoder between the Expansion ROM Base Address register
    > > and
    > > other Base Address registers. When expansion ROM decode is
    > > enabled, ...
    > >
    > > On Fri, Jul 30, 2004 at 11:59:21AM -0700, Jon Smirl wrote:
    > > > Alan Cox knows more about this, but I believe there is only one PCI
    > > > card in existence that does this.
    > >
    > > Strange; he was the one who pointed out this requirement to me in the
    > > first place and he hinted that many devices did this.
    >
    > Alan, what's the answer here?
    >
    > > Shutting off interrupts isn't nearly enough. Any other CPU could
    > > access the device, or indeed any device capable of DMA could
    >
    > Another idea, it's ok to read the ROM when there is no device driver
    > loaded. When the driver for one of these card loads it could trigger a
    > copy of the ROM into RAM and cache it in a PCI structure.

    I think this is a good idea.

    It could either be done as a part of pci_enable_device(), or, which I
    believe would be better, as a separate function, say
    pci_copy_rom(char *dest), that the driver would call before
    pci_enable_device().

    Of course, in this case the ROM wouldn't be automatically exported
    through sysfs, although the driver should be able to export it itself
    rather easily.

    -- 
    Vojtech Pavlik
    SuSE Labs, SuSE CR
    -
    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/
    

  • Next message: Andrew Morton: "Re: dentry cache leak? Re: rsync out of memory 2.6.8-rc2"

    Relevant Pages

    • Re: IBM 45nm -- new or licensed from Intel?
      ... Please note that a custom ROM only needs fewer than half the number of ... transistors as it has bits. ... (well a few more for decoders etc) ... I got the impression that a microcode "ROM" in today's Intel and AMD ...
      (comp.arch)
    • RE: [UPDATED PATCH] EFI support for ia32 kernels
      ... >> reuse a single driver image for multiple architectures assuming there ... As one of the people responsible for the EFI Specification and our ... Perhaps the UNDI network card interface that Intel developed ... BIOS can't shadow that much ROM code. ...
      (Linux-Kernel)
    • Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices wi
      ... >> BIOS as it doesn't have a ROM attached to the video chip (it's burried ... >> in the main BIOS which thankfully copied it to c0000 when running it). ... >> modified copy that the X driver should get. ... It will still need a little support in ...
      (Linux-Kernel)
    • Re: Problems getting the 1394 ROM configuration info
      ... > I am new to device drivers and am working on a driver for a 1394 firewire ... I am having some problems in getting the ROM configuration ... > entire contents of the config info. ...
      (microsoft.public.development.device.drivers)
    • Re: [PATCH] add PCI ROMs to sysfs
      ... > kernel driver can force-enable the ROM decoding... ... My current plan is for the radeon driver to keep the code for enabling ... > the new quirk section stuff David just posted, we can have quirks ...
      (Linux-Kernel)