On Fri, 11 May 2007, Oliver Neukum wrote:
> Am Freitag, 11. Mai 2007 20:15 schrieb Alan Stern:
> > > On the contrary. This propblem usually occurs during probe() where it is
> > > handled exactly this way. You return an error.
> >
> > The situations aren't parallel. During probe() the driver is
Am Freitag, 11. Mai 2007 20:15 schrieb Alan Stern:
> > On the contrary. This propblem usually occurs during probe() where it is
> > handled exactly this way. You return an error.
>
> The situations aren't parallel. During probe() the driver is supposed to
> test the device to make sure it really
On Fri, 11 May 2007, Oliver Neukum wrote:
> You are asking drivers to do something what some of them cannot do
> in principle. To restore state from scratch you need to know the state
> the device was in. Many drivers cannot know that.
>
> > Now perhaps you would like to add a subroutine to the
Am Freitag, 11. Mai 2007 16:27 schrieb Alan Stern:
> On Fri, 11 May 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > it seems to me that you have to allow for drivers failling to restore
> > their devices' state. The obvious way would be to let post_reset()
> > return an error code and treat failure
On Fri, 11 May 2007, Oliver Neukum wrote:
> Hi,
>
> it seems to me that you have to allow for drivers failling to restore
> their devices' state. The obvious way would be to let post_reset()
> return an error code and treat failure as unplug.
To begin with, you don't want to trait failure as unp
Hi,
it seems to me that you have to allow for drivers failling to restore
their devices' state. The obvious way would be to let post_reset()
return an error code and treat failure as unplug.
Regards
Oliver
--
