We need to inform the device about the *new* value, not the
old one.

Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Moving the call to cdc_ncm_setup() after the endpoint
setup removes the last remaining reference to ncm_parm
outside cdc_ncm_setup.

Collecting all the ncm_parm based calculations in
cdc_ncm_setup improves readability.

Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These fields are only used to prevent printing the same speeds
multiple times if we receive multiple identical speed notifications.

The value of these printk's is questionable, and even more so when
we filter out some of the notifications sent us by the firmware. If
we are going to print any of these, then we should print them all.

Removing little used fields is a bonus.

Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We already use the usbnet udev field everywhere this could have
been used.

Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Too many pointers back and forth are likely to confuse developers,
creating subtle bugs whenever we forget to syncronize them all.

As a usbnet driver, we should stick with the standard struct
usbnet fields as much as possible.  The netdevice is one such
field.

Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

No need to duplicate stuff already in the common usbnet
struct.  We still need to keep our special find_endpoints
function because we need explicit control over the selected
altsetting.

Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is always a duplicate of the "control" field. It causes
confusion wrt intf_data updates and cleanups.

Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We can avoid the costly division for the common case where
we pad the frame to tx_max size as long as we ensure that
tx_max is either the device specified dwNtbOutMaxSize or not
a multiplum of wMaxPacketSize.

Using the preconverted 'maxpacket' field avoids converting
wMaxPacketSize to CPU endianness for every transmitted frame

And since we only will hit the one byte padding rule for short
frames, we can drop testing the skb for tailroom.

The change means that tx_max now represents the real maximum
skb size, enabling us to allocate the correct size instead of
always making room for one extra byte.

Cc: Alexey Orishko <alexey.orishko@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use the introduced usbnet_link_change to handle link change.
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Receiving unhandled notifications is most certainly not an error
and should not be logged as one.  Knowing that the device sends
notifications we don't handle is useful for developers, but there
is very little a user can do about this.  The message is therefore
just annoying noise to most users with devices sending unhandled
notifications like e.g. USB_CDC_NOTIFY_RESPONSE_AVAILABLE

Cc: Alexey Orishko <alexey.orishko@stericsson.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

return -ENOMEM instead if kzalloc of cdc_ncm_ctx structure is failed.

and also remove the comparision of ctx structure with NULL and make
it as !ctx.
Signed-off-by: NDevendra Naga <devendra.aaru@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit bd329e12 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices")
introduced a new policy, preferring MBIM for dual NCM/MBIM functions if
the cdc_mbim driver was enabled.  This caused a regression for users
wanting to use NCM.

Devices implementing NCM backwards compatibility according to section
3.2 of the MBIM v1.0 specification allow either NCM or MBIM on a single
USB function, using different altsettings.  The cdc_ncm and cdc_mbim
drivers will both probe such functions, and must agree on a common
policy for selecting either MBIM or NCM.  Until now, this policy has
been set at build time based on CONFIG_USB_NET_CDC_MBIM.

Use a module parameter to set the system policy at runtime, allowing the
user to prefer NCM on systems with the cdc_mbim driver.

Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@stericsson.com>
Reported-by: NGeir Haatveit <nospam@haatveit.nu>
Reported-by: NTommi Kyntola <kynde@ts.ray.fi>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54791Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Tag all Huawei NCM devices as WWAN modems, as we don't know of any which
are not.  This is necessary for userspace clients to know that the device
requires further setup on e.g. an AT-capable serial ports before
connectivity is available.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit bd329e12 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices")
added a test for a CDC MBIM altsetting, implementing the cdc_ncm part of
MBIM backward compatibility support.  This intentionally made the driver
behave differently for CDC NCM devices with 2 alternate settings for the
Communication interface, depending on whether or not CONFIG_USB_NET_CDC_MBIM
was enabled.  This is correct iff alternate setting #1 really *is* a MBIM
setting.  If not, then NCM probing will use a different altsetting than before,
possibly causing probing failures depending on CONFIG_USB_NET_CDC_MBIM.

Fix by setting the altsetting back to default after the test, restoring the
previous behaviour for non MBIM devices.

This bug causes probing of Huawei E3276 devices to fail when the MBIM driver
is enabled, because these devices have a second alternate setting with no CDC
functional descriptors.

Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@stericsson.com>
Reported-and-tested-by: NJonathan A. <yo.natan@hotmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Adding a new vendor specific class/subclass/protocol combination
for CDC NCM devices based on information from a GPLed out-of-tree
driver from Huawei.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit 9992c2e2 (net: cdc_ncm: workaround for missing CDC Union)
added code to lookup an IAD for the interface we are probing.
This is redundant.  The USB core has already done the lookup
and saved the result in the USB interface struct.  Use that
instead.

Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@stericsson.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Infineon(now Intel) HSPA Modem platform NCM cannot support ARP.
we can define a new common structure wwan_noarp_info.
Then more similiar NO ARP devices can be handled easily
Signed-off-by: NWei Shuai <cpuwolf@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit bbc8d922 (net: cdc_ncm: add Huawei devices) implemented
support for devices with a single combined control and data
interface. Fix up the error path so that we do not double
release such interfaces in case of probing failures.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Adding support for the MBIM mode in some Sierra Wireless devices.

Some Sierra Wireless firmwares support CDC MBIM but have no CDC
Union funtional descriptor. This violates the MBIM specification,
but we can easily work around the bug by looking at the Interface
Association Descriptor instead.  This is most likely what
Windows uses too, which explains how the firmware bug has gone
unnoticed until now.

This change will not affect any currently supported device
conforming to the NCM or MBIM specifications, as they must have
the CDC Union descriptor.

Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@stericsson.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use strlcpy where possible to ensure the string is \0 terminated.
Use always sizeof(string) instead of 32, ETHTOOL_BUSINFO_LEN
and custom defines.
Use snprintf instead of sprint.
Remove unnecessary inits of ->fw_version
Remove unnecessary inits of drvinfo struct.
Signed-off-by: NJiri Pirko <jiri@resnulli.us>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This covers the drivers that can use a primitive
implementation.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A number of Huawei 3G and LTE modems implement a CDC NCM function,
including the necessary functional descriptors, but using a non
standard interface layout and class/subclass/protocol codes.

These devices can be handled by this driver with only a minor
change to the probing logic, allowing a single combined control
and data interface.  This works because the devices
- include a CDC Union descriptor labelling the combined
  interface as both master and slave, and
- have an alternate setting #1 for the bulk endpoints on the
  combined interface.

The 3G/LTE network connection is managed by vendor specific AT
commands on a serial function in the same composite device.
Handling the managment function is out of the scope of this
driver.  It will be handled by an appropriate USB serial
driver.
Reported-and-Tested-by: NOlof Ermis <olof.ermis@gmail.com>
Reported-and-Tested-by: NTommy Cheng <tommy7765@yahoo.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixes the sparse warning

 drivers/net/usb/cdc_ncm.c:836:9: warning: context imbalance in 'cdc_ncm_txpath_bh' - different lock contexts for basic block
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Probably doesn't matter much since the value is used as a
boolean anyway, but it removes the sparse warning:

 drivers/net/usb/cdc_ncm.c:1090:32: warning: incorrect type in assignment (different base types)
 drivers/net/usb/cdc_ncm.c:1090:32:    expected unsigned short [unsigned] [usertype] connected
 drivers/net/usb/cdc_ncm.c:1090:32:    got restricted __le16 [usertype] wValue
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Acked-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The MBIM specification allows a MBIM device to disguise
itself as NCM for backwards compatibility, using additional
altsettings with different subclass (control) or protocol
(data):

C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_mbim
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=7ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=7ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

If the MBIM driver is enabled then that should have priority
for devices providing such a NCM 1.0 backward compatibility
mode.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NGreg Suarez <gsuarez@smithmicro.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Move symbols and definitons which can be shared with a
MBIM driver in a new header.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Adding multiplexed NDP support to cdc_ncm_fill_tx_frame, allowing
transmissions of multiple independent sessions within the same NTB.

Refactoring the code quite a bit to avoid having to store copies
of multiple NDPs being prepared for tx. The old code would still
reserve enough room for a maximum sized NDP in the skb so we might
as well keep them in the skb while they are being prepared.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Verifying and handling received MBIM and NCM frames will need
to be different in three areas:
 - verifying the NDP signature
 - checking valid datagram length
 - datagram header manipulation

This makes it inconvenient to share rx_fixup in whole.  But
some verification parts are common.  Split these out in separate
functions.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The NCM 1.0 spefication makes provisions for linking more than
one NDP into a single NTB. This is important for MBIM support,
where these NDPs might be of different types.

Following the chain of NDPs is also correct for NCM, and will
not change anything in the common case where there is only
one NDP
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

NCM and MBIM can share most of the bind function.  Split
out the shareable part and add MBIM functional descriptor
parsing.
Signed-off-by: NGreg Suarez <gsuarez@smithmicro.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

MBIM and NCM are very similar, so we can reuse most of the
setup and bind logic in cdc_ncm for CDC MBIM devices.  Handle
a few minor differences in ncm_setup.
Signed-off-by: NGreg Suarez <gsuarez@smithmicro.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some devices do not support the 8 byte variants of the NTB input
size control messages despite announcing such support in their
NCM or MBIM functional descriptor.

According to the NCM specification, all devices must support the
4 byte variant regardless of whether or not the flag is set:

  If bit D5 is set in the bmNetworkCapabilities field of
  function’s NCM Functional Descriptor, the host may
  set wLength either to 4 or to 8. If wLength is 4, the
  function shall assume that wNtbInMaxDatagrams is to be
  set to zero. If wLength is 8, then the function shall
  use the provided value as the limit. The function shall
  return an error response (a STALL PID) if wLength is set
  to any other value.

We do not set wNtbInMaxDatagrams in any case, so we can just as
well unconditionally use the 4 byte variant without losing any
functionality.  This works around the known firmware bug, and
simplifies the code considerably.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Hello,

looking at http://sourceforge.net/apps/mediawiki/mbm/index.php?title=Main_Page#Supported_devices, there are branded Ericsson devices from Dell and Toshiba.

The to-be-added vendor IDs are 0x413c for Dell and 0x0930 for Toshiba.

Please find attached a patch to add these vendor IDs.
Signed-off-by: NPeter Meiser <meiser@gmx-topmail.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Tag Ericsson NCM devices as WWAN modems, since they almost certainly all
are.  This way userspace clients know that the device requires further
setup on the AT-capable serial ports before connectivity is available.
Signed-off-by: NDan Williams <dcbw@redhat.com>

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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Hansjoerg Lipp <hjlipp@web.de>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Jan Dumon <j.dumon@option.com>
Cc: Petko Manolov <petkan@users.sourceforge.net>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Kan Yan <kanyan@broadcom.com>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Changes:
- removed a limit for amount of datagrams for IN NTB
- using pointer to traverse NTB in rx_fixup()
- renamed "temp" to "len" in rx_fixup()
- do NTB sequence number check in rx path
Tested on Intel/ARM.
Reviewed-by: NSjur Brændeland <sjur.brandeland@stericsson.com>
Tested-by: NDmitry Tarnyagin <Dmitry.Tarnyagin@stericsson.com>
Signed-off-by: NAlexey Orishko <alexey.orishko@stericsson.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Changes/fixes:
- inform device if max_datagram_size was changed by host
- max_datagram_size can't be bigger MTU in ETH func descr
- fix constants definitions to enable running CAIF service over NCM

Tested on Intel/ARM.
Reviewed-by: NSjur Brændeland <sjur.brandeland@stericsson.com>
Tested-by: NDmitry Tarnyagin <Dmitry.Tarnyagin@stericsson.com>
Signed-off-by: NAlexey Orishko <alexey.orishko@stericsson.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Changes:
- use high resolution timer
  latency became approx. 10-15 times less than before
- use taklet for sending remaining data in tx path
Tested on Intel/ARM.
Reviewed-by: NSjur Brændeland <sjur.brandeland@stericsson.com>
Tested-by: NDmitry Tarnyagin <Dmitry.Tarnyagin@stericsson.com>
Signed-off-by: NAlexey Orishko <alexey.orishko@stericsson.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Print MAC/dev_addr via printk extended format specifier %pM
instead of custom code.
Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>