[RFClue] pci_get_device, new driver model

From: William D Waddington (william.waddington_at_beezmo.com)
Date: 10/07/05

  • Next message: Andi Kleen: "Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance" 
    Date:	Fri, 07 Oct 2005 10:18:15 -0700
To: linux-kernel@vger.kernel.org

    Alan Cox wrote:
    > On Gwe, 2005-10-07 at 09:18 -0700, William D Waddington wrote:

    >>If I just give in to the new driver model how/when do I associate
    >>instance/minor numbers with boards found? Is it ever possible for
    >>ordinary PCI boards to be (logically) removed and re-added w/out
    >>removing the driver? If so, how to maintain association between
    >>a particular board and minor number?
    >
    >
    > Its up to you how you implement this. One requirement I suspect would be
    > that the boards have unique serial numbers. Most drivers do not retain
    > state if someone unplugs a board, moves it and plugs it back in. Instead
    > they report the old device as "gone" and let user space sort it out

    I don't have unique serial #s available, but my question wasn't clear.

    Is it ever possible that the hotplug stuff will try to remove and re-add
    one (or all) of my boards when there _hasn't_ been a physical change or
    power cycle/reboot/driver reload/whatever.

    As long as the driver gets reloaded following any logical or physical
    system change I will just go through the instance/minor assignment
    again. What I don't want is /dev/idr0 /dev/idr1 turning into /dev/idr2
    /dev/idr3 because someone tickled the hotplug controls.

    Still not quite clear how to assocuiate instance/minor #s with boards.
    Do I just keep a global counter and bump it each time probe (or init)
    gets called for each board? Hence my worry above.

    Thanks for the quick reply.

    Bill (not sure if this will thread OK)
    --------------------------------------------
    William D Waddington
    Bainbridge Island, WA, USA
    william.waddington@beezmo.com
    --------------------------------------------
    "Even bugs...are unexpected signposts on
    the long road of creativity..." - Ken Burtch

    -
    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: Andi Kleen: "Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance"

    Relevant Pages

    • Re: My thoughts on the "new development model"
      ... |>>> 2.6 tree is great for gentoo users who like gcc consuming all CPU ... |>> that after a month or so of fixes etc it will be a very stable kernel ... driver for 2.6.7 for an ADSL card; a development driver for 2.6.5 for a ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: sata related hang with linux-2.6
      ... IMHO there's something not quite right with the Silicon Image libata ... Perhaps the driver is enabling the hardware to generate interrupts ... before setting up the interrupt routine for it? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: SL811 problem on mach-pxa
      ... It was tested with _both_ workarounds for IRQ issues; ... unlike the predecessors to this driver). ... I've had reports that one of the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [RFC] removal of legacy cdrom drivers (Re: [PATCH] mcdx.c insanity removal)
      ... bar and baz and fairly long expressions. ... if we want to keep the FPOS in the tree. ... Driver is obviously ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related)
      ... Patch r8139-20.patch didn't help. ... crash but without DEBUG it did crash. ... Here is a snapshot from the log file when driver is crashing: ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)