Hm,
Scratch the idea I outline below, seems like its not a good idea.
I'm reading the e100, e1000 and the ixgb power management code, and they
go through all sorts of steps I don't need to do for PCI device reset.
There's no clear abstraction that would serve both needs.
On Thu, Jun 30, 2005 at 03:39:31PM -0500, Linas Vepstas was heard to remark:
> On Wed, Jun 29, 2005 at 06:58:29PM +0200, Andi Kleen was heard to remark:
> > > Yep, OK. Pushig the timer would in fact break if the device was marked
> > > perm disabled.
> >
> > I think for network drivers you should just write a generic error handler
> > (perhaps in net/core/dev.c) that calls the watchdog handler.
> > Then all drivers could be easily converted without much code duplication.
>
> Well, there's no watchdog per-se in "struct net_device" -- are you
> suggesting I add one?
>
> It looks like I can almost create generic handlers for net devices;
> looks like calling netdev->stop() is enough to handle the error
> detection.
>
> However, a generic bringup would need to call pci_enable_device(),
> and net/core/dev.c does not include pci.h so I can't really do it
> there. Other than that, a generic recovry routine looks like it might
> be possible; I'll have to experiment; its hard to tell by reading code.
>
> This might be the wrong paradigm, though. The pci error recovery
> routines are *almost identical* to the power-management suspend/resume
> routines. From what I can tell, the only real difference is that
> I want to not actually turn off/on the power.
>
> Thus, the right thing to do might be to split up the
> struct pci_dev->suspend() and pci_dev->resume() calls into
>
> suspend()
> poweroff()
> poweron()
> resume()
>
> and then have the generic pci error recovery routines call
> suspend/resume only, skipping the poweroff-on calls. Does that
> sound good?
>
> I'm not sure I can pull this off without having someone from
> the power-management world throw a brick at me.
>
> --linas
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]