Re: [PATCH] Make e100 suspend handler support PCI cards lacking PM capability

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Sunday 14 June 2009, Andreas Mohr wrote:
> Hi,
> 
> On Sun, Jun 14, 2009 at 04:06:29PM +0200, Rafael J. Wysocki wrote:
> > On Sunday 14 June 2009, Andreas Mohr wrote:
> > > Hi,
> > > 
> > > On Sun, Jun 14, 2009 at 12:28:15AM +0200, Rafael J. Wysocki wrote:
> > > > On Saturday 13 June 2009, Andreas Mohr wrote:
> > > > > +
> > > > >  	if (wake) {
> > > > >  		return pci_prepare_to_sleep(pdev);
> > > > 
> > > > pci_prepare_to_sleep() is supposed to return 0 for your device.  I'll have a
> > > > look at it.
> > > 
> > > No, wake is false for my card, thus that's not the branch to
> > > investigate.
> > 
> > Ah.  The problem is, then, that we try to put the device into D3, which it
> > cannot do and error code is correctly returned from pci_set_power_state().
> > 
> > I would use the appended patch in that case and the patch sent previously
> > is necessary for the 'wake = true' case.
> 
> OK, as said I cannot test this right now, but I'm _damn_ sure it would
> work. Thus I'd say your equivalent patch posted a bit later can be
> committed already.
> 
> But what about the wake = true case?
> I'm not affected by this since my card doesn't have any wake capa,
> thus it's your call of whether that pci core code part really was broken
> and needed fixing.

I think it needs fixing.

> So, for the patch in your next mail:
> Acked-by: Andreas Mohr <andi@lisas.de>
> 
> 
> BTW, that patch was (pasted):
> 
>  static int __e100_power_off(struct pci_dev *pdev, bool wake)
>  {
> -       if (wake) {
> +       if (wake)
>                 return pci_prepare_to_sleep(pdev);
> -       } else {
> -               pci_wake_from_d3(pdev, false);
> -               return pci_set_power_state(pdev, PCI_D3hot);
> -       }
> +
> +       pci_wake_from_d3(pdev, false);
> +       pci_set_power_state(pdev, PCI_D3hot);
> +
> +       return 0;
>  }
> 
> 
> Couple questions still:
> - why do we call pci_wake_from_d3(...false) only!?
>   Wouldn't this break WoL after one iteration back and forth,
>   due to missing 'true' case?

The 'true' case is the 'wake = true' one.

> - why do we call netif_device_detach() _after_ doing hardware shutdown
>   of the network controller? I'd guess this can cause huge issues?
>   Someone told me he had rtnl lock issues upon S2D with e100
>   (very similar to my rtnl issues during aborted .suspend),
>   and that might possibly be the reason?

I think you're right, but I'm not a network driver expert.

Perhaps you can change the ordering and see if that fixes the rtnl issue
(since you're able to reproduce it without my patch, that should be easy to
verify).

Best,
Rafael

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects