[lkml]   [2001]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: pci_disable_device() vs. arch
    Benjamin Herrenschmidt wrote:
    > >
    > >Its not clutter -- what you are doing is hiding pieces of the driver
    > >from the driver maintainer. pcibios_enable_device should not be
    > >cluttered up with such mess, too.
    > Well... pcibios_enable_device() has to at least make sure the device
    > gets powered up as it's powered down after PCI probe. Except if we
    > end up calling pci_set_power_state() to power it up early in the
    > sungem driver.

    huh? pci_enable_device calls pci_set_power_state. sungem calls

    pcibios_enable_device shouldn't have to worry about power stuff. If it
    does, you need a pcibios_set_power_state, called from
    pci_set_power_state, instead.

    > >I point out that I recently fixed a bug where Via interrupts were being
    > >assigned incorrectly. If I had not done a global grep for Via
    > >irq-related code, I would have missed the spot where the PPC code was
    > >doing a kludge for one of the four on-board Via devices, hardcoding the
    > >USB irq number to 11.
    > Hrm... interrupt routing on some PPC-based motherboard is quite a
    > mess, fortunately that's not the case on pmacs. The IRQ assignement
    > has to be part of the arch AFAIK, only the arch knows on which
    > interrupt line of the controller a given chip is wired and how
    > interrupt controllers are cascaded.

    Via is an exception

    > What I suggest if for pci_bus to have an optional set_power_state
    > function that is called when a device on that bus calls
    > pci_set_power_state(). This function would then be able to implement
    > those cases where power control is possible, while not done
    > via PCI PM caps.

    > A pci_bus structure exist for both "root" busses and busses under
    > PCI<->PCI bridges, so effectively, there's a pci_bus structure per
    > bridge (beeing host or PCI<->PCI). I beleive it makes sense for
    > the bridge to have a way to handle the child power state.

    Ok, agreed. There are always gonna be special case bridges, including
    (for my interest) multi-port NICs whose interfaces are presented as PCI
    devices downstream from a PCI-PCI bridge. Controlling power for these
    nics is sometimes done by messing around with the PM bits on the bridge,
    not on the downstream devices.


    Jeff Garzik | Andre the Giant has a posse.
    Building 1024 |
    MandrakeSoft |
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:55    [W:0.024 / U:10.792 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site