Re: [PATCH] call drv->shutdown at rmmod

[Patrick Mochel]

> Assuming the device driver can get a device out of the suspend state
> when the module is loaded.  This has been one of the biggest problem areas
> with the e100 driver.  It's init code cannot bring the device out of a low
> power state.

You're assuming that a driver can always bring a device out a shutdown
state. That's one of the things we talked about at OLS, and the other half
of the justification behind such a feature, not just making sure the
device is queisced. Your argument against my suggestion are some of the
same arguments for a feature like you're introducing. 

We have similar goals - introduce device power state code paths into 
common operations (e.g module removal). Doing so gets the code paths 
tested, which will help us ultimately achieve our utopian goals. And, it 
can be done in one shot. 

> > The default would always be 'Do Nothing', but with a per-device sysfs 
> > file, a developer/user/gui app could be used to set the policy from user 
> > space. 
> 
> Possibly.  But this is getting complicated.  And while I do support things
> being complicated enough to handle the problem this part of the API feels
> like it is excessively complicated.  Which is why I was trying to simply
> it by always calling shutdown on a device before we remove it.

Eh? This is complicated? especially compared your overall goal, kexec? Let 
me explain again: 

I won't take the patch to unconditionally shutdown devices on module 
removal, so you need some sort of flag. But, you must have some way to set 
the flag, which is what sysfs is designed for. While you're at it, we 
might as well make it an integer value, rather than a pure binary one, and 
conditionally attempt to set the power state if the user says so. 

It's actually pretty simple, and if it is confusing, then sit back and 
wait, and I'll provide documentation when I submit the patch. 



	Pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/