Re: "deadlock" between smc91x driver and link_watch

[Nicolas Pitre]

On Wed, 24 Nov 2004, Ian Campbell wrote:

> On Wed, 2004-11-24 at 10:21 -0500, Nicolas Pitre wrote:
> 
> > How do you ensure that smc_phy_configure() can't end up being called 
> > after smc_phy_powerdown() here?
> 
> Hmm, I think that smc_phy_configure() is only called from
> smc_drv_resume() and smc_timeout() (via the workqueue).

There is smc_open() as well, but only smc_timeout() is really 
problematic because of the schedule_work() call.

> The other solution might be to set phy_type to 0 in smc_phy_powerdown()
> and then redetect it in smc_open() and smc_resume(). Or just use another
> flag altogether.

Please make it another flag.  You could replace your dev_hold(dev) with 
lp->work_pending = 1 and dev_put() with lp->work_pending = 0, then 
adding a while (lp->work_pending) schedule() in place of the 
flush_scheduled_work().

And while you're at it, could you replace:

smc_phy_configure(void *data)

with

smc_phy_configure(struct net_device *dev)

The parameter doesn't have to be void *data anymore now that you 
introduced smc_phy_configure_wq().

And finally, please tell about the reason why flush_scheduled_work() 
can't be used in your comment.


Nicolas
-
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/