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
>
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)
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
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
.
>>
>> 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
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.
>>
>
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
>> +
>> + 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
> 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
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
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
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?
>>
&
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
> 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
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
15 matches
Mail list logo