[lkml]   [2001]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: pci_disable_device() vs. arch
    >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.

    >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.

    >Correct. If your driver uses the API correctly, then when/if we want to
    >mess around with hotplug resource assignment, we can un-assign resources
    >as we like. Since there aren't too many users of pci_disable_device so
    >far, I want to make sure early adopters get it right.

    Well... at least with sungem, there's no such risk as the entire bus
    (up to the host bridge) where it lives is internal to the UniNorth

    >Can you give a -specific- example of arch code that is -not- sungem
    >related, but needs to occur when one powers-down a sungem MAC?
    >If the PM code is related to sungem, it belongs in sungem.
    >So far I don't see a need for arch-specific hooks anywhere...

    Hrm... let me try again...

    Powering down individual devices can be controlled by the PCI PM
    capabilities, or in some cases (at least 2 cases here on UniNorth
    based pmacs) by other bits in the host bridge.

    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.


    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.022 / U:168.232 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site