Re: Reserving an ATA interface

[Andre Hedrick]

On Sat, 3 May 2003, Bartlomiej Zolnierkiewicz wrote:

> 
> On 3 May 2003, Benjamin Herrenschmidt wrote:
> 
> >
> > > 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 :)
> 
> Yes, only remaining question is how... :-)

I will reveal in time, as this is already done.

2.7 I will release the remainder of my voodoo.

> > > > 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 ?
> 
> Yes.
> 
> > 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.
> 
> Fully agreed.
> 
> > 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.
> 
> Yeah, to be done, probably 2.7 :\.
> --
> Bartlomiej
> 
> > Ben.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group