Re: [PATCH v3] smsc95xx: Add comments to the registers definition

2017-04-12 Thread Steve Glendinning
gh those devices can only rely on the Linux kernel > driver source to make their own. > > This commit adds a lot of comments to the registers definition to expand > the register names. > > Cc: Steve Glendinning > Cc: Microchip Linux Driver Support > CC: David Miller >

Re: [PATCHv2][RFC] smsc95xx: enable dynamic autosuspend

2012-12-14 Thread Steve Glendinning
On 11 December 2012 16:27, Joe Perches wrote: > On Tue, 2012-12-11 at 15:26 +0000, Steve Glendinning wrote: > []> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c > [] >> + ret = smsc95xx_read_reg_nopm(dev, RX_FIFO_INF, &val)

Re: [PATCHv2][RFC] smsc95xx: enable dynamic autosuspend

2012-12-14 Thread Steve Glendinning
On 11 December 2012 16:13, Ming Lei wrote: > On Tue, Dec 11, 2012 at 11:26 PM, Steve Glendinning > wrote: >> + >> + if (on) >> + usb_autopm_get_interface_no_resume(dev->intf); >> + else >> + usb_autopm_put_interfa

[PATCHv2][RFC] smsc95xx: enable dynamic autosuspend

2012-12-11 Thread Steve Glendinning
This patch enables USB dynamic autosuspend for LAN9500A. This saves very little power in itself, but it allows power saving in upstream hubs/hosts. The earlier devices in this family (LAN9500/9512/9514) do not support this feature. Signed-off-by: Steve Glendinning --- drivers/net/usb

Re: [PATCH][RFC] smsc95xx: enable dynamic autosuspend (RFC)

2012-12-11 Thread Steve Glendinning
. >> >> If you can get rid of a periodic work this would be great. > > For the LAN95xx devices, the periodic work isn't needed because > they may generate remote wakeup when link change is detected. As above, some parts will do this but some will not. I think we sh

Re: [PATCH][RFC] smsc95xx: enable dynamic autosuspend (RFC)

2012-12-10 Thread Steve Glendinning
On 10 December 2012 12:09, Oliver Neukum wrote: > So this is a problem with remote wakeup on older hardware? Exactly, the older hardware revisions can't reliably do it. >> Unfortunately we don't know if the connected device supports >> this feature until we query its ID register at runtime. >> >

[PATCH][RFC] smsc95xx: enable dynamic autosuspend (RFC)

2012-12-10 Thread Steve Glendinning
y devices supporting autosuspend from the USB VID/PID if this would help. UPDATE: reposting this to a wider audience due to lack of feedback last time round Signed-off-by: Steve Glendinning --- drivers/net/usb/smsc95xx.c | 136 +++- 1 file changed, 135 inser

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

2012-11-28 Thread Steve Glendinning
>> + >> + ret = device_set_wakeup_enable(&net->dev, pdata->wolopts); > > You are touching the network device here. That should have been the USB > device. Try something like > > ret = device_set_wakeup_enable(&dev->udev->dev, pdata->wolopts); Perfect, this works exactly as expected now. Patch

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

2012-11-28 Thread Steve Glendinning
> Looking at the different ethernet drivers, the normal way do do this > seems to be something like this in their .set_wol implementation: > > device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol); > > > where "adapter" is a netdev_priv private struct, "pdev" is a pci device > and "wo

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

2012-11-28 Thread Steve Glendinning
Hi Bjorn, On 28 November 2012 09:31, Bjørn Mork wrote: > > Remote wakeup will not be enabled on system suspend unless the user (or > a userspace program on the users behalf) has requested it. If a user types "ethtool -s eth2 wol p" they *are* explicitly requesting the ethernet device to bring th

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

2012-11-28 Thread Steve Glendinning
Hi Alan, >> udev->do_remote_wakeup is set in choose_wakeup() in >> drivers/usb/core/driver.c. AFAICS it is always set as long as >> device_may_wakeup(&udev->dev) is true. > > That's right. But is device_may_wakeup(&udev->dev) true? > > By default it wouldn't be. The normal way to set it is for

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

2012-11-27 Thread Steve Glendinning
Hi Bjorn, On 27 November 2012 17:21, Steve Glendinning wrote: > Hi Bjorn, > >>> + smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP); >> >> As mentioned in another comment to the smsc95xx driver: This is weird. >> Do you really need to do that? >> &

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

2012-11-27 Thread Steve Glendinning
Hi Bjorn, >> + smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP); > > As mentioned in another comment to the smsc95xx driver: This is weird. > Do you really need to do that? > > This is an USB interface driver. The USB device is handled by the > generic "usb" driver, which will do the right

Re: [PATCH v3 3/5] usbnet: smsc95xx: fix memory leak in smsc95xx_suspend

2012-11-06 Thread Steve Glendinning
> BTW, I just saw the smsc95xx datasheet and the vendor's driver > source code, and found the chip supports runtime PM well > (remote wakeup on 'good packet' or link change), so do you > plan to implement that? Yes, I do plan to implement this. Note that this feature is only supported on some pro

Re: [PATCH v3 3/5] usbnet: smsc95xx: fix memory leak in smsc95xx_suspend

2012-11-06 Thread Steve Glendinning
of the helper macro. > Also, it isn't necessary to bother mm to allocate 8bytes/16byte, > and we can use stack variable safely. Acked-By: Steve Glendinning -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.k