lkml.org 
[lkml]   [2003]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Reserving an ATA interface
    From
    Date

    > Yesterday I was thinking about:
    > - default arch hwifs, added/probed in ide_init_defult_hwifs() if no
    > IDE PCI/PCI (depends on arch, should be IDE PCI?) support is compiled in
    > - PCI hwifs
    > - legacy hwifs probed in ide_setup()
    > - legacy hwifs probed after PCI
    > and about ide_register_hw() + initializing flag.
    >
    > What a mess... ordering issues can make you crazy.

    Yup, I'd suggest we think about re-writing all that stuff for 2.7 :)

    > > The simplest solution I have in mind is to add an hwif flag,
    > > called "hold" (or whatever better name you find). Drivers like
    > > ide/ppc/pmac.c would set this flag for the "hotswap" media bay
    > > interface, and not for others.
    >
    > This change is obviously correct and it doesn't have influence on
    > any existing code.
    >
    > > The only change to the core code would then be for ide_register_hw
    > > to 'skip' those when searching for an available slot, and to call
    > > init_hwif_data when (!hwif->present && !hwif->hold) to handle case 2
    > > where the iops & other hwif fields (mmio among others) need to be
    > > reset to initial/legacy state.
    >
    > Less safe change but also okay, as callers .
    > btw, Can't "ghost ides" be dealed inside ppc specific code?
    > Do you know when interface is valid and when it is "ghost",
    > and what other OS-es do in this case?

    Not re-using the slot for an interface with the "hold" bit won't
    affect anybody but setters of that bit, so we are ok. The act of
    calling init_hwif_data when !present && !hold is the one bringing
    a possible change of behaviour to existing code.

    However, who calls ide_register_hw() dynamically ? ide-cs and ?
    I don't think there would much harm in re-calling init_hwif_data
    at this point since hwif->present is not set, we _are_ re-using
    the hwif, wether it was previously initialized or not by somebody
    else. In this case, we really want to "clean" it, don't we ?

    Right now, the only problem with re-initializing this way that
    I've found is with hotswap interfaces like ide-pmac, because
    they will have preset special MMIO ops etc... and that call
    would revert that pre-setting. That's exactly why such interfaces
    should set the "hold" bit to "reserve" the hwif slot. You see
    the point ? I don't think there are much drivers aroung playing
    with such tricks though.

    All I can do within ide pmac itself is set or not that "hold"
    bit for those interfaces. I just need to set it on the hotswap
    ones (wthr they have devices connected or not) that way they
    stay around "reserved" for when a device gets plugged. Other
    "fixed" interfaces will have hwif->present cleared automatically
    by the probe code, and thus will be "freed" for other uses, if
    they don't have any device attached.
    (Which is why that init_hwif_data is needed to reset their hwif
    to something good default, and not whatever ide pmac have set).

    In 2.5, I can be slightly smarted since I'm calling the probe
    myself and no longer rely on the automatic initial probe done
    by the IDE layer, like for PCI devices, so I can actually
    "clear" those "empty" interfaces myself after they are probed.
    But still, it makes sense to have this "hold" flag to let a
    hotswap interface reserve a slot, and it makes sense when the
    interface isn't held by anybody to "clean it up" before giving
    it to somebody else.

    The only problem I see right now is for a dynamic interface
    (like ide-cs) where the _controller_ itself is hotswap, so
    the hwif slot cannot be reserved in advance _and_ that interface
    needs special IOps (which is fortunately not the case of ide-cs)

    Such an interface can't really know what slot will be
    picked by ide_register_hw() and can't "prepare" the HWIF with
    special iops, so it won't be much harmed by the fact we are
    calling init_hwif_data, but still, we should ultimately think
    about splitting completely the fact of allocating an hwif slot,
    setting it up, and triggering a probe on it. Those are 3 different
    things that are currently mixed in bad ways. I don't beleive
    fixing that fits in the 2.6 timeframe though.

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

    \
     
     \ /
      Last update: 2005-03-22 13:35    [W:0.026 / U:58.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site