[lkml]   [2003]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectPlatform Devices

    Sorry it's taken so long to reply, this has needed a chance to sink in
    (and for other things to be resolved).

    > I think we need to expand the platform device support to include the
    > notion of platform drivers. For example:
    > struct platform_driver {
    > int (*probe)(struct platform_device *);
    > int (*remove)(struct platform_device *);
    > int (*suspend)(struct platform_device *, u32);
    > int (*resume)(struct platform_device *);
    > struct device_driver drv;
    > };

    I see two ways of supporting platform devices that will have a variable
    number of logical interfaces -- depending on the platform -- per physical
    device, and support power management on them.

    The first: put power management methods in struct class.

    As we suspend each physical device, we would loop over each class device
    that is associated with the physical device, and call its class's
    ->suspend() method for it. The class would be responsible for stopping the
    device and taking that view of the device offline. The class-specific
    portion of the driver may optionally have suspend()/resume() methods that
    the class could call to save those bits of device state.

    This would leave the bus-specific power management calls to only power
    down the device and save config-space-like register state of the device.
    (Especially if there were per-driver class-specific suspend/resume
    methods, as they would be responsible for saving/restoring the interesting
    parts of the device.)

    The second: Allow mulitple drivers to bind to platform devices.

    We would use a similar structure as you have above, with a struct
    list_head in it to allow us to chain them together. When we suspended a
    platform device, the platform bus would iterate through each driver that's
    bound to a device and call ->suspend().

    Simple enough, though we'd have to create some sort of notion of a
    'platform_class' for each device type, as there could theoretically be
    multiple instances of a device type, and a chain of drivers could only
    bind to one without dynamically allocating each instance of the driver. It
    would be similar to the way system devices are handled, but without
    breaking away from the unified device hierarchy.

    Either way is relatively easy to implement, and I'm ambivalent about which
    to choose this morning. The former may have much added benefit by reducing
    the amount of work that needs to be done in each driver of each type,
    while the latter focuses on just resolving your issue..


    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 13:48    [W:0.022 / U:4.832 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site