This "flaw" isn't a new thing, of course. I remember pointing out the rather
annoying proclivity of the PM framework to deadlock when suspend() tried to
remove USB devices ... back around 2.6.10 or so. Things have shuffled around
a bit, and gotten better in some cases, but not fundamentally changed.
It may be more accurate to say that now we understand some constraints on
device tree management policies ... ones we had previously assumed should
not be issues. (But AFAICT, without actually considering the question.
Now we know the right question to ask!)
On Monday 25 February 2008, Rafael J. Wysocki wrote:
There's also the case where it's framework code that handles the additions
rather than the parent device. That would be typical for many bridge, hub,
or adapter type drivers ... you may be thinking mostly about drivers acting
as "leaf" nodes in the device tree, at least in terms of real hardware nodes.
Yes, "require that policy from such framework code too". Just trying to be
sure the description doesn't have gaping holes in the middle. :)
I can think of a bunch of serial busses where framework code has that sort
of responsiblity. USB, SPI, I2C ... "legacy" I2C drivers would all need
to be taught not to create/remove children during those intervals, lacking
"new style" conversion (which makes them work more like normal drivers).
- Dave
--
