In f_hidg_write() the write_spinlock is acquired before calling
usb_ep_queue() which causes a deadlock when dummy_hcd is being used.
This is because dummy_queue() callbacks into f_hidg_req_complete() which
tries to acquire the same spinlock. This is (part of) the backtrace when
the deadlock occurs:

  0xffffffffc06b1410 in f_hidg_req_complete
  0xffffffffc06a590a in usb_gadget_giveback_request
  0xffffffffc06cfff2 in dummy_queue
  0xffffffffc06a4b96 in usb_ep_queue
  0xffffffffc06b1eb6 in f_hidg_write
  0xffffffff8127730b in __vfs_write
  0xffffffff812774d1 in vfs_write
  0xffffffff81277725 in SYSC_write

Fix this by releasing the write_spinlock before calling usb_ep_queue()
Reviewed-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Cc: stable@vger.kernel.org # 4.11+
Fixes: 749494b6 ("usb: gadget: f_hid: fix: Move IN request allocation to set_alt()")
Signed-off-by: NRadoslav Gerganov <rgerganov@vmware.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Restore the status of ep->stopped in function net2272_dequeue().

When the given request is not found in the endpoint queue
the function returns -EINVAL without restoring the state of
ep->stopped. Thus the endpoint keeps blocked and does not transfer
any data anymore.

This fix is only compile-tested, since we do not have a
corresponding hardware. An analogous fix was tested in the sibling
driver. See "usb: gadget: net2280: Fix net2280_dequeue()"
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGuido Kiener <guido.kiener@rohde-schwarz.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When a request must be dequeued with net2280_dequeue() e.g. due
to a device clear action and the same request is finished by the
function scan_dma_completions() then the function net2280_dequeue()
does not find the request in the following search loop and
returns the error -EINVAL without restoring the status ep->stopped.
Thus the endpoint keeps blocked and does not receive any data
anymore.
This fix restores the status and does not issue an error message.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGuido Kiener <guido.kiener@rohde-schwarz.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The OUT endpoint normally blocks (NAK) subsequent packets when a
short packet was received and returns an incomplete queue entry to
the gadget driver. Thereby the gadget driver can detect a short packet
when reading queue entries with a length that is not equal to a
multiple of packet size.

The start_queue() function enables receiving OUT packets regardless of
the content of the OUT FIFO. This results in a race: With the current
code, it's possible that the "!ep->is_in && (readl(&ep->regs->ep_stat)
& BIT(NAK_OUT_PACKETS))" test in start_dma() will fail, then a short
packet will be received, and then start_queue() will call
stop_out_naking(). That's what we don't want (OUT naking gets turned
off while there is data in the FIFO) because then the next driver
request might receive a mixture of old and new packets.

With the patch, this race can't occur because the FIFO's state is
tested after we know that OUT naking is already turned on, and OUT
naking is stopped only when both of the conditions are met.  This
ensures that all received data is delivered to the gadget driver,
which can detect a short packet now before new packets are appended
to the last short packet.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGuido Kiener <guido.kiener@rohde-schwarz.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons.  Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

dma_map_single already transfers ownership to the device.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

My @samusung.com address is going to cease existing soon, so change it to
an address which can actually be used to contact me.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Since the 5.0 merge window opened, I've been seeing frequent
crashes on suspend and reboot with the trace:

[   36.911170] Unable to handle kernel paging request at virtual address ffffff801153d660
[   36.912769] Unable to handle kernel paging request at virtual address ffffff800004b564
...
[   36.950666] Call trace:
[   36.950670]  queued_spin_lock_slowpath+0x1cc/0x2c8
[   36.950681]  _raw_spin_lock_irqsave+0x64/0x78
[   36.950692]  complete+0x28/0x70
[   36.950703]  ffs_epfile_io_complete+0x3c/0x50
[   36.950713]  usb_gadget_giveback_request+0x34/0x108
[   36.950721]  dwc3_gadget_giveback+0x50/0x68
[   36.950723]  dwc3_thread_interrupt+0x358/0x1488
[   36.950731]  irq_thread_fn+0x30/0x88
[   36.950734]  irq_thread+0x114/0x1b0
[   36.950739]  kthread+0x104/0x130
[   36.950747]  ret_from_fork+0x10/0x1c

I isolated this down to in ffs_epfile_io():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/f_fs.c#n1065

Where the completion done is setup on the stack:
  DECLARE_COMPLETION_ONSTACK(done);

Then later we setup a request and queue it, and wait for it:
  if (unlikely(wait_for_completion_interruptible(&done))) {
    /*
    * To avoid race condition with ffs_epfile_io_complete,
    * dequeue the request first then check
    * status. usb_ep_dequeue API should guarantee no race
    * condition with req->complete callback.
    */
    usb_ep_dequeue(ep->ep, req);
    interrupted = ep->status < 0;
  }

The problem is, that we end up being interrupted, dequeue the
request, and exit.

But then the irq triggers and we try calling complete() on the
context pointer which points to now random stack space, which
results in the panic.

Alan Stern pointed out there is a bug here, in that the snippet
above "assumes that usb_ep_dequeue() waits until the request has
been completed." And that:

    wait_for_completion(&done);

Is needed right after the usb_ep_dequeue().

Thus this patch implements that change. With it I no longer see
the crashes on suspend or reboot.

This issue seems to have been uncovered by behavioral changes in
the dwc3 driver in commit fec9095b ("usb: dwc3: gadget:
remove wait_end_transfer").

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Zeng Tao <prime.zeng@hisilicon.com>
Cc: Jack Pham <jackp@codeaurora.org>
Cc: Thinh Nguyen <thinh.nguyen@synopsys.com>
Cc: Chen Yu <chenyu56@huawei.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Vincent Pelletier <plr.vincent@gmail.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linux USB List <linux-usb@vger.kernel.org>
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

usb_ep_autoconfig() treats the passed descriptor as if it were an fs
descriptor. In particular, for bulk endpoints, it clips wMaxPacketSize
to 64. This patch preserves the original value.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The moved code refers to non-super speed endpoints only. This patch also
makes the comment stress the fact, that autoconfigured descriptor might
need some adjustments.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

f_uac1 audio control header descriptor default set
baInterfaceNr[]={1,2}, but usb gadget make a configuration descriptor
with more interfaces combination, it can not confirm f_uac1 function
linked first. So always keep baInterfaceNr[]={1,2} is correct, and it
is necessary to sync baInterfaceNr[] with usb_interface_id() value.
Signed-off-by: NLiang Shengjun <liangshengjun@hisilicon.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

There are a bunch of various indentation issues, clean these up.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

A reset e.g. calling ep_reset_338x() can happen while endpoints
are enabled. The ep_reset_338x() sets ep->desc = NULL to mark
endpoint being invalid. A subsequent call of net2280_disable will
fail and return -EINVAL to parent function usb_ep_disable(),
which will fail, too, and do not set the member ep->enabled = false.

See:
https://elixir.bootlin.com/linux/v5.0-rc5/source/drivers/usb/gadget/udc/core.c#L139

This fix ignores dp->desc and allows net2280_disable() to succeed.
Subsequent calls to usb_ep_enable()/usb_ep_disable() succeeds.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGuido Kiener <guido.kiener@rohde-schwarz.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Commit bf594c10 ("USB: gadget: Document that certain ep operations
can be called in interrupt context") documented that usb_ep_dequeue()
may be called in a non-process context.  It follows that the routine
must not sleep or wait for events.

However, the routine's existing kerneldoc seems to imply that it will
wait until the request being cancelled has fully completed.  This is
not so, and thus the comment needs to be improved.  Misunderstanding
this point may very well have been responsible for a bug recently
uncovered in the f_fs function.

The updated comment explicitly says that the routine may return before
the request's completion handler is called.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: John Stultz <john.stultz@linaro.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Due to the patch that makes TMF handling synchronous the
write_pending_status() callback function is no longer called.  Hence remove
it.
Acked-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
Reviewed-by: NAndy Grover <agrover@redhat.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NHannes Reinecke <hare@suse.com>
Reviewed-by: NBryant G. Ly <bryantly@linux.vnet.ibm.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: Saurav Kashyap <saurav.kashyap@qlogic.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Move the Rohm Vendor ID to pci_ids.h instead of defining it in several
drivers.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

(!x & y) strikes again.

Fix bitwise and boolean operations by enclosing the expression:

	intcsr & (1 << NET2272_PCI_IRQ)

in parentheses, before applying the boolean operator '!'.

Notice that this code has been there since 2011. So, it would
be helpful if someone can double-check this.

This issue was detected with the help of Coccinelle.

Fixes: ceb80363 ("USB: net2272: driver for PLX NET2272 USB device controller")
Cc: stable@vger.kernel.org
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

RZ/G2E USB 3.0 implementation is like the one found on R-Car E3,
therefore add the same quirk.
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We only have uvcg_dbg, uvcg_info, and uvcg_err, so add uvcg_warn macro
to print gadget device name and function name along with format.
Signed-off-by: NPaul Elder <paul.elder@ideasonboard.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Switch RX processing from tasklet to (delayed) work queue. This allows
receiver more room to process incoming data and prevents flood of
"ttyGS0: RX not scheduled?" messages on HS receive on slow CPU.

A side effect is 2.4MB/s zmodem transfer speed (up from 1.8MB/s)
on my test board.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Delete tab aligning a statement with the right hand side of a
preceding assignment rather than the left hand side.

Found with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Fix spelling mistake: "lenght" -> "length"
Signed-off-by: NMatteo Croce <mcroce@redhat.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

'num' is a u8 variable, it never greater than 255,
So the if branch is dead code and can be removed.
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

There are a few remaining drivers/usb/ files that do not have SPDX
identifiers in them, all of these are either Kconfig or Makefiles.  Add
the correct GPL-2.0 identifier to them to make scanning tools happy.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The source_sink_alloc_func() function is supposed to return error
pointers on error.  The function is called from usb_get_function() which
doesn't check for NULL returns so it would result in an Oops.

Of course, in the current kernel, small allocations always succeed so
this doesn't affect runtime.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We already need to zero out memory for dma_alloc_coherent(), as such
using dma_zalloc_coherent() is superflous. Phase it out.

This change was generated with the following Coccinelle SmPL patch:

@ replace_dma_zalloc_coherent @
expression dev, size, data, handle, flags;
@@

-dma_zalloc_coherent(dev, size, handle, flags)
+dma_alloc_coherent(dev, size, handle, flags)
Suggested-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NLuis Chamberlain <mcgrof@kernel.org>
[hch: re-ran the script on the latest tree]
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Delete tab aligning a statement with the right hand side of a
preceding assignment rather than the left hand side.

Found with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
of the user address range verification function since we got rid of the
old racy i386-only code to walk page tables by hand.

It existed because the original 80386 would not honor the write protect
bit when in kernel mode, so you had to do COW by hand before doing any
user access.  But we haven't supported that in a long time, and these
days the 'type' argument is a purely historical artifact.

A discussion about extending 'user_access_begin()' to do the range
checking resulted this patch, because there is no way we're going to
move the old VERIFY_xyz interface to that model.  And it's best done at
the end of the merge window when I've done most of my merges, so let's
just get this done once and for all.

This patch was mostly done with a sed-script, with manual fix-ups for
the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

There were a couple of notable cases:

 - csky still had the old "verify_area()" name as an alias.

 - the iter_iov code had magical hardcoded knowledge of the actual
   values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
   really used it)

 - microblaze used the type argument for a debug printout

but other than those oddities this should be a total no-op patch.

I tried to fix up all architectures, did fairly extensive grepping for
access_ok() uses, and the changes are trivial, but I may have missed
something.  Any missed conversion should be trivially fixable, though.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A follow-up patch will add a notifier type NETDEV_PRE_CHANGEADDR, which
allows vetoing of MAC address changes. One prominent path to that
notification is through dev_set_mac_address(). Therefore give this
function an extack argument, so that it can be packed together with the
notification. Thus a textual reason for rejection (or a warning) can be
communicated back to the user.
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Acked-by: NJiri Pirko <jiri@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: NYangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

iscsi_target_mod is the only LIO fabric where fabric_ops.name differs from
the fabric_ops.fabric_name string.  fabric_ops.name is used when matching
target/$fabric ConfigFS create paths, so rename it .fabric_alias and
fallback to target/$fabric vs .fabric_name comparison if .fabric_alias
isn't initialised.  iscsi_target_mod is the only fabric module to set
.fabric_alias . All other fabric modules rely on .fabric_name matching and
can drop the duplicate string.
Signed-off-by: NDavid Disseldorp <ddiss@suse.de>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

All fabrics return a const string. In all cases *except* iSCSI the
get_fabric_name() string matches fabric_ops.name.

Both fabric_ops.get_fabric_name() and fabric_ops.name are user-facing, with
the former being used for PR/ALUA state and the latter for ConfigFS
(config/target/$name), so we unfortunately need to keep both strings around
for now.  Replace the useless .get_fabric_name() accessor function with a
const string fabric_name member variable.
Signed-off-by: NDavid Disseldorp <ddiss@suse.de>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

list_for_each_entry_safe() is not safe for deleting entries from the
list if the spin lock, which protects it, is released and reacquired during
the list iteration. Fix this issue by replacing this construction with
a simple check if list is empty and removing the first entry in each
iteration. This is almost equivalent to a revert of the commit mentioned in
the Fixes: tag.

This patch fixes following issue:
--->8---
Unable to handle kernel NULL pointer dereference at virtual address 00000104
pgd = (ptrval)
[00000104] *pgd=00000000
Internal error: Oops: 817 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1 PID: 84 Comm: kworker/1:1 Not tainted 4.20.0-rc2-next-20181114-00009-g8266b35ec404 #1061
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events eth_work
PC is at rx_fill+0x60/0xac
LR is at _raw_spin_lock_irqsave+0x50/0x5c
pc : [<c065fee0>]    lr : [<c0a056b8>]    psr: 80000093
sp : ee7fbee8  ip : 00000100  fp : 00000000
r10: 006000c0  r9 : c10b0ab0  r8 : ee7eb5c0
r7 : ee7eb614  r6 : ee7eb5ec  r5 : 000000dc  r4 : ee12ac00
r3 : ee12ac24  r2 : 00000200  r1 : 60000013  r0 : ee7eb5ec
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 6d5dc04a  DAC: 00000051
Process kworker/1:1 (pid: 84, stack limit = 0x(ptrval))
Stack: (0xee7fbee8 to 0xee7fc000)
...
[<c065fee0>] (rx_fill) from [<c0143b7c>] (process_one_work+0x200/0x738)
[<c0143b7c>] (process_one_work) from [<c0144118>] (worker_thread+0x2c/0x4c8)
[<c0144118>] (worker_thread) from [<c014a8a4>] (kthread+0x128/0x164)
[<c014a8a4>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
Exception stack(0xee7fbfb0 to 0xee7fbff8)
...
---[ end trace 64480bc835eba7d6 ]---

Fixes: fea14e68 ("usb: gadget: u_ether: use better list accessors")
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Commit 387f869d ("usb: gadget: u_ether: conditionally align
transfer size") started aligning transfer size only if requested,
breaking omap_udc DMA mode. Set quirk_ep_out_aligned_size to restore
the old behaviour.

Fixes: 387f869d ("usb: gadget: u_ether: conditionally align transfer size")
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

On Palm TE nothing happens when you try to use gadget drivers and plug
the USB cable. Fix by adding the board to the vbus sense quirk list.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

On OMAP 15xx machines there are no transceivers, and omap_udc_start()
always fails as it forgot to adjust the default return value.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We currently crash if usb_add_gadget_udc_release() fails, since the
udc->done is not initialized until in the remove function.
Furthermore, on module removal the udc data is accessed although
the release function is already triggered by usb_del_gadget_udc()
early in the function.

Fix by rewriting the release and remove functions, basically moving
all the cleanup into the release function, and doing the completion
only in the module removal case.

The patch fixes omap_udc module probe with a failing gadged, and also
allows the removal of omap_udc. Tested by running "modprobe omap_udc;
modprobe -r omap_udc" in a loop.
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The current code fails to release the third irq on the error path
(observed by reading the code), and we get also multiple WARNs with
failing gadget drivers due to duplicate IRQ releases. Fix by using
devm_request_irq().
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Some protocols implemented in userspace with FunctionFS might require large
buffers, e.g. 64kB or more. Currently the said memory is allocated with
kmalloc, which might fail should system memory be highly fragmented.

On the other hand, some UDC hardware allows scatter-gather operation and
this patch takes advantage of this capability: if the requested buffer
is larger than PAGE_SIZE and the UDC allows scatter-gather operation, then
the buffer is allocated with vmalloc and a scatterlist describing it is
created and passed to usb request.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Nothing to remap, only check length.
Define a minimal structure for CCID descriptor only used to check length.
As this descriptor shares the same value as HID descriptors, keep track and
compare current interface's class to expected HID and CCID standard values.
Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>