linux-toradex.git/drivers/net/usb/rndis_host.c, branch v3.7.2

Merge tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2012-05-22T22:50:46+00:00

Pull USB 3.5-rc1 changes from Greg Kroah-Hartman:
"Here is the big USB 3.5-rc1 pull request for the 3.5-rc1 merge window.

It's touches a lot of different parts of the kernel, all USB drivers,
due to some API cleanups (getting rid of the ancient err() macro) and
some changes that are needed for USB 3.0 power management updates.

There are also lots of new drivers, pimarily gadget, but others as
well. We deleted a staging driver, which was nice, and finally
dropped the obsolete usbfs code, which will make Al happy to never
have to touch that again.

There were some build errors in the tree that linux-next found a few
days ago, but those were fixed by the most recent changes (all were
due to us not building with CONFIG_PM disabled.)

Signed-off-by: Greg Kroah-Hartman "

* tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (477 commits)
xhci: Fix DIV_ROUND_UP compile error.
xhci: Fix compile with CONFIG_USB_SUSPEND=n
USB: Fix core compile with CONFIG_USB_SUSPEND=n
brcm80211: Fix compile error for .disable_hub_initiated_lpm.
Revert "USB: EHCI: work around bug in the Philips ISP1562 controller"
MAINTAINERS: Add myself as maintainer to the USB PHY Layer
USB: EHCI: fix command register configuration lost problem
USB: Remove races in devio.c
USB: ehci-platform: remove update_device
USB: Disable hub-initiated LPM for comms devices.
xhci: Add Intel U1/U2 timeout policy.
xhci: Add infrastructure for host-specific LPM policies.
USB: Add macros for interrupt endpoint types.
xhci: Reserve one command for USB3 LPM disable.
xhci: Some Evaluate Context commands must succeed.
USB: Disable USB 3.0 LPM in critical sections.
USB: Add support to enable/disable USB3 link states.
USB: Allow drivers to disable hub-initiated LPM.
USB: Calculate USB 3.0 exit latencies for LPM.
USB: Refactor code to set LPM support flag.
...

Conflicts:
arch/arm/mach-exynos/mach-nuri.c
arch/arm/mach-exynos/mach-universal_c210.c
drivers/net/wireless/ath/ath6kl/usb.c

USB: Disable hub-initiated LPM for comms devices.

2012-05-18T22:42:55+00:00

Hub-initiated LPM is not good for USB communications devices.  Comms
devices should be able to tell when their link can go into a lower power
state, because they know when an incoming transmission is finished.
Ideally, these devices would slam their links into a lower power state,
using the device-initiated LPM, after finishing the last packet of their
data transfer.

If we enable the idle timeouts for the parent hubs to enable
hub-initiated LPM, we will get a lot of useless LPM packets on the bus
as the devices reject LPM transitions when they're in the middle of
receiving data.  Worse, some devices might blindly accept the
hub-initiated LPM and power down their radios while they're in the
middle of receiving a transmission.

The Intel Windows folks are disabling hub-initiated LPM for all USB
communications devices under a xHCI USB 3.0 host.  In order to keep
the Linux behavior as close as possible to Windows, we need to do the
same in Linux.

Set the disable_hub_initiated_lpm flag for for all USB communications
drivers.  I know there aren't currently any USB 3.0 devices that
implement these class specifications, but we should be ready if they do.

Signed-off-by: Sarah Sharp 
Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Cc: Hansjoerg Lipp 
Cc: Tilman Schmidt 
Cc: Karsten Keil 
Cc: Peter Korsgaard 
Cc: Jan Dumon 
Cc: Petko Manolov 
Cc: Steve Glendinning 
Cc: "John W. Linville" 
Cc: Kalle Valo 
Cc: "Luis R. Rodriguez" 
Cc: Jouni Malinen 
Cc: Vasanthakumar Thiagarajan 
Cc: Senthil Balasubramanian 
Cc: Christian Lamparter 
Cc: Brett Rudley 
Cc: Roland Vossen 
Cc: Arend van Spriel 
Cc: "Franky (Zhenhui) Lin" 
Cc: Kan Yan 
Cc: Dan Williams 
Cc: Jussi Kivilinna 
Cc: Ivo van Doorn 
Cc: Gertjan van Wingerde 
Cc: Helmut Schaa 
Cc: Herton Ronaldo Krzesinski 
Cc: Hin-Tak Leung 
Cc: Larry Finger 
Cc: Chaoming Li 
Cc: Daniel Drake 
Cc: Ulrich Kunitz 
Signed-off-by: Sarah Sharp

rndis_host: cleanup: change oid from __le32 to u32 in rndis_query()

2012-05-12T19:18:00+00:00

Signed-off-by: Jussi Kivilinna 
Signed-off-by: Linus Walleij 
Signed-off-by: David S. Miller

rndis_host: cleanup: byteswap data from device instead of RNDIS_* defines

2012-05-12T19:16:13+00:00

All other values from device provided buffer are byteswapped, so it seems
more logical to do same for these.

Signed-off-by: Jussi Kivilinna 
Signed-off-by: Linus Walleij 
Signed-off-by: David S. Miller

usb/net: rndis: eliminate first set of duplicate OIDs

2012-05-12T19:04:19+00:00

The RNDIS protocol contains a vast number of Object ID:s (OIDs).
The current definitions had multiple definitions of these ID:s,
let's use the nicely RNDIS_*-prefixed defines from the HyperV
implementation, rename everywhere they're used, and copy+rename
the few that were missing from this list of objects.

Signed-off-by: Linus Walleij 
Signed-off-by: David S. Miller

usb/net: rndis: inline the cpu_to_le32() macro

2012-05-12T19:00:45+00:00

The header file  used a number of #defines
that included the cpu_to_le32() macro to assure the result will be
in LE endianness. Inlining this into the code instead of using it
in the code definitions yields consolidation opportunities later
on as you will see in the following patches. The individual
drivers also used local defines - all are switched over to the
pattern of doing the conversion at the call sites instead.

Signed-off-by: Jussi Kivilinna 
Signed-off-by: Linus Walleij 
Signed-off-by: David S. Miller

USB: convert drivers/net/* to use module_usb_driver()

2011-11-18T17:44:20+00:00

This converts the drivers in drivers/net/* to use the
module_usb_driver() macro which makes the code smaller and a bit
simpler.

Added bonus is that it removes some unneeded kernel log messages about
drivers loading and/or unloading.

Cc: Wolfgang Grandegger 
Cc: Samuel Ortiz 
Cc: Oliver Neukum 
Cc: Peter Korsgaard 
Cc: Petko Manolov 
Cc: Steve Glendinning 
Cc: Christian Lamparter 
Cc: "John W. Linville" 
Cc: Dan Williams 
Cc: Jussi Kivilinna 
Cc: Ivo van Doorn 
Cc: Gertjan van Wingerde 
Cc: Helmut Schaa 
Cc: Herton Ronaldo Krzesinski 
Cc: Hin-Tak Leung 
Cc: Larry Finger 
Cc: Chaoming Li 
Cc: Lucas De Marchi 
Cc: "David S. Miller" 
Cc: Roel Kluin 
Cc: Paul Gortmaker 
Cc: Jiri Pirko 
Cc: Pavel Roskin 
Cc: Yoann DI-RUZZA 
Cc: George 
Signed-off-by: Greg Kroah-Hartman

rndis_host: Quirky devices are still 'point-to-point'

2011-04-15T06:23:45+00:00

My changes in commit 4d42d417be75d750b82798922b6e775915e11bce were
written some time before the introduction of FLAG_POINTTOPOINT, so
didn't include that flag in the new driver_info.  Change the new
driver_info to be consistent.

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller

rndis_host: Poll status before control channel where necessary

2011-04-13T21:48:55+00:00

Some RNDIS devices don't respond on the control channel until polled
on the status channel.  In particular, this was reported to be the
case for the 2Wire HomePortal 1000SW and for some Windows Mobile
devices.

This is roughly based on a patch by John Carr 
which is currently applied by Mandriva.

Reported-by: Mark Glassberg 
Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller

usbnet: use eth%d name for known ethernet devices

2011-04-02T03:12:02+00:00

The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.

Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().

Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.

The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two.  The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.

Signed-off-by: Arnd Bergmann 
Tested-by: Andy Green 
Signed-off-by: David S. Miller