Re: RFC: hotplug & libata.

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Fri, 15 Oct 2004 15:16:56 -0500, Andy Warner <andyw@pobox.com> wrote:
> I've spent time over the last 10 days or so working
> through hotplug issues with libata and am coming round
> to the position that the current __init/probe mechanism
> may need some reorganisation for hotplug to work well.
> 
> I can currently (mostly) hotplug SATA drives that were
> present at __init/probe all day long; but things
> are less good for drives which were not present
> at __init/probe.
> 
> If it's not there at __init/probe time, the groundwork
> isn't in place to add devices later without some fairly
> nasty & repetitious code. I keep coming back to a model
> where the host adapter ports are initialised, then the
> initial drive scan & addition is effectively a hot-plug
> event (either automatic or forced, depending on hardware
> capabilities.)

Sounds fine.

> Unfortunately, I fear that any impending PATA/libata
> train-wreck may conflict with this, due to the behaviour
> of some (many) of the PATA chipsets out there (e.g.
> misbehaving seriously when no active devices are attached
> to the bus etc.)

misbehaving?

For the PATA I worry a bit about chipset tuning vs hotplug:
* single PCI config space byte holds settings for all devices etc.
* some hosts don't like when settings for the one port are
  changed while there is IO in flight for the other port

There should be some smart host wide locking for that.

Otherwise I see no major problems for PATA hotplug
(or rather "coldplug") support.

> Anyone have thoughts/advice to share on this concept? I think
> the re-org may be quite intrusive, and I don't want to waste
> cycles on something that "would never work with PATA, because
> of blah, blah, blah.."

Without seeing actual code it is hard to say but I'm an optimist. :)