In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly. Adds a static tracking variable to
match the timer global.
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 115004
Addresses-Coverity-ID: 115005
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Detailed description for this pull request:
1. Split out extcon header file for consumer and provider device
: The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect
the state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API
for both provider and consumer device driver. To clarify the meaning
of header file and to remove the wrong use-case on consumer device.
- include/linux/extcon-provider.h includes API for the provider device driver.
- include/linux/extcon.h includes the API for the consumer device driver.
2. Support the SmartDock accessory on extcon-max77843.c device driver
- Support the SmartDock accessory which detects following connectors
at the same time.
: USB host throught USB hub for mouse, keyboard and so on.
: MHL connector for video output.
: Charger connector for battery charging.
- It tested with Unitek Y-2165 MHL+OTG Hub Smart Phone Dock.
3. Fix the minor issue of extcon driver
- Delete the unneeded initialization in extcon-max14577.
- Make extcon_info static const in order to fix the warning.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZ8bQaAAoJEJzN3yze689Tc8IP/RTxI/35eP0RIyxwIH93PcPT
H7yup4tJDmQtp2+aH8qyCxrjiy9Tb+eu45A+UroM8RHyBb47BiiDC5J4/H9I+Wed
jU/aoPp6NN4HocYSqtgkG+6DiyyA3ibbKPZHCeUKgf3Us1LZAL1pMPqZVpnfJIIX
nnW4LdJ7ociY31N3UYepRmMly4LejUO1HLNsd8WFfFv+KM7bSkqmAIViw/dtteCa
DL3SVbqzWXN226BtxiZoKZTHsz9QUQ9ZUvJe22d19fIkmP9FqJ5/ujxSUKgzOFe6
qRpF8HGKkgy6lwQ8XJzwY53bQw1NiG/KU+fXpMRL0mkoe3MNvBPIl+GTr0Ts6jrH
e0So0aIWZTtoPAxvs6mc0wl4P9zkESZ0PoxH8Ulo+rxKYau2ES3GRBofNzr1FHLu
4iQ7UikAIS33oyhYjJn/zm0nShKzWJxjQDXIx57CiHn4XKxGlwBz+wsLrfvdt1Me
WJ1yvhpL5F3B08RfmzIIpsrXwsS/IhTlfEHcbI/gAscpcALSgG5MZoZBwwm7IC7F
l0V81Z4jGNjztf0ZgTiBStN5KM0ntNH6AZAdrFigCtu9HzI4Egi45P7Gm7+Lxlic
sHI3d7I6g+L9V5Um6GmLPjzo6epNkYp46ws6YhAqjqM7HZ4YXFtCcm6YM4s/qlV5
6ubXPN/bRI7S5hWSkUTH
=gWvl
-----END PGP SIGNATURE-----
Merge tag 'extcon-next-for-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into usb-next
Chanwoo writes:
Update extcon for 4.15
Detailed description for this pull request:
1. Split out extcon header file for consumer and provider device
: The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect
the state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API
for both provider and consumer device driver. To clarify the meaning
of header file and to remove the wrong use-case on consumer device.
- include/linux/extcon-provider.h includes API for the provider device driver.
- include/linux/extcon.h includes the API for the consumer device driver.
2. Support the SmartDock accessory on extcon-max77843.c device driver
- Support the SmartDock accessory which detects following connectors
at the same time.
: USB host throught USB hub for mouse, keyboard and so on.
: MHL connector for video output.
: Charger connector for battery charging.
- It tested with Unitek Y-2165 MHL+OTG Hub Smart Phone Dock.
3. Fix the minor issue of extcon driver
- Delete the unneeded initialization in extcon-max14577.
- Make extcon_info static const in order to fix the warning.
Not much going on this time around. With only 51 non-merge commits,
this was one of the smallest pull requests from the Gadget tree.
Most of the changes are in the mtu3 driver which added support for
36-bit DMA, support for USB 3.1 and support for dual-role (along with
some non-critical fixes).
The dwc2 driver got a few improvements to how we handle gadget state
tracking and also added support for STM32F7xx devices.
Other than that, we just some minor non-critical fixes and
improvements all over the place.
-----BEGIN PGP SIGNATURE-----
iQJRBAABCgA7FiEElLzh7wn96CXwjh2IzL64meEamQYFAlnvDUQdHGZlbGlwZS5i
YWxiaUBsaW51eC5pbnRlbC5jb20ACgkQzL64meEamQbaFg//WorvPDm7vu/o5G4r
pMCLodF0Ye6sFs5Ug2X2Fr3sXpRTlr6LfPi6Zt3rwimF5EBtDuNF0Tu8jKj0vfSI
iKYpXIvDOc4DVeqMiQzw3kBt8FQcUjb8cVV2VUbO9ata0ALUF3TH27PUIS0R1vTG
HOhSx4EVIkpp2vM9XOFBWi2e46HsDscoymGNXn/b3WmAUysPoNf+7i9NUgI88VHZ
KbFmdYlMyvPTOQsJM3EaNIoGmWzoNtuBU+W0aO0h17QweGaDDpINBFocCru/MWT3
d8IaRtkHmq+nUYMM3IrKCL0i40uq86ckm110jEYhBLkZsAlf728118MKnD4PnJoR
NMnRn1xLV0/JbGV0Nq1Kz0WefYiWj7nsve7TNnDDteJ8PKZTzQUSb0LQ4KIQTBo3
3LfeQgRmhzSafJ11xr1IWiVti7D6ijkqMw8R+z+YazTCN9Mgwt0aA/BFDihcSNR8
Qan9VHqiCvldfJCY0a+VoD5lE1zWeYqBkDF2XhrjuhEvfo9fjrJnJ1ElQhFDT8w8
zJDerBpxuVlYZta45t7PKS6Y4XiuVZrwXo8ilTQEVg68KoJ4GX7GhKJbfResuaKB
OvSvr2aRCAAKhXil7C8sRVjdpRdLhKNY6NQisxEwhrqaGI7RzWIhibFlHGWwLNNv
HYjtoNi5JcZmeteEdXeBLRyPUtI=
=nkak
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
Felipe writes:
usb: changes for v4.15 merge window
Not much going on this time around. With only 51 non-merge commits,
this was one of the smallest pull requests from the Gadget tree.
Most of the changes are in the mtu3 driver which added support for
36-bit DMA, support for USB 3.1 and support for dual-role (along with
some non-critical fixes).
The dwc2 driver got a few improvements to how we handle gadget state
tracking and also added support for STM32F7xx devices.
Other than that, we just some minor non-critical fixes and
improvements all over the place.
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1350962
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 703128
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 145713
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect the
state/properties of external connector. Also, it notifies the
state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API for
both provider and consumer device driver. To clarify the meaning of
header file and to remove the wrong use-case on consumer device,
this patch separates into extcon.h and extcon-provider.h.
[Description for include/linux/{extcon.h|extcon-provider.h}]
- extcon.h includes the extcon API and data structure for extcon consumer
device driver. This header file contains the following APIs:
: Register/unregister the notifier to catch the change of extcon device
: Get the extcon device instance
: Get the extcon device name
: Get the state of each external connector
: Get the property value of each external connector
: Get the property capability of each external connector
- extcon-provider.h includes the extcon API and data structure for extcon
provider device driver. This header file contains the following APIs:
: Include 'include/linux/extcon.h'
: Allocate the memory for extcon device instance
: Register/unregister extcon device
: Set the state of each external connector
: Set the property value of each external connector
: Set the property capability of each external connector
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
usb_endpoint_maxp() has an inline keyword and searches for bits[10:0]
by & operation with 0x7ff. So, we can remove the duplicate & operation
with 0x7ff.
Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
usb_endpoint_maxp() has an inline keyword and searches for bits[10:0]
by & operation with 0x7ff. So, we can remove the duplicate & operation
with 0x7ff.
Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Make this const as it is only stored in the const field of a structure
video_device in the file referencing it. Make the declaration const too.
Done using Coccinelle.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Use the of_device_get_match_data() helper instead of open coding,
postponing the matching until when it's really needed.
Note that the renesas_usb3 driver is used with DT only, so there's
always a valid match.
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch adds support for generic phy as an optional. If you want
to use a generic phy (e.g. phy-rcar-gen3-usb3 driver) on this driver,
you have to do "insmod phy-rcar-gen3-usb3.ko" first for now.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch moves pm_runtime_{en,dis}able() call timing to
renesas_usb3_{probe,remove}() for supporting PM_SLEEP feature in
the future.
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
[shimoda: Revise the commit log]
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
If the probe fails, udc_remove() will not be called, so there is no
reason to make del_timer_sync() calls conditional. As a result, use of
the .data field can be dropped, in support of making removing this field
entirely from struct timer_list.
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Raviteja Garimella <raviteja.garimella@broadcom.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kmemleak checking configuration reports a memory leak in
usb_os_desc_prepare_interf_dir function when rndis function
instance is freed and then allocated again. For example, this
happens with FunctionFS driver with RNDIS function enabled
when "ffs-test" test application is run several times in a row.
The data for intermediate "os_desc" group for interface directories
is allocated as a single VLA chunk and (after a change of default
groups handling) is not ever freed and actually not stored anywhere
besides inside a list of default groups of a parent group.
The fix is to make usb_os_desc_prepare_interf_dir function return
a pointer to allocated data (as a pointer to the first VLA item)
instead of (an unused) integer and to make the caller component
(currently the only one is RNDIS function) responsible for storing
the pointer and freeing the memory when appropriate.
Fixes: 1ae1602de0 ("configfs: switch ->default groups to a linked list")
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
KASAN enabled configuration reports an error
BUG: KASAN: use-after-free in usb_composite_overwrite_options+...
[libcomposite] at addr ...
Read of size 1 by task ...
when some driver is un-bound and then bound again.
For example, this happens with FunctionFS driver when "ffs-test"
test application is run several times in a row.
If the driver has empty manufacturer ID string in initial static data,
it is then replaced with generated string. After driver unbinding
the generated string is freed, but the driver data still keep that
pointer. And if the driver is then bound again, that pointer
is re-used for string emptiness check.
The fix is to clean up the driver string data upon its unbinding
to drop the pointer to freed memory.
Fixes: cc2683c318 ("usb: gadget: Provide a default implementation of default manufacturer string")
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The dummy-hcd driver calls the gadget driver's disconnect callback
under the wrong conditions. It should invoke the callback when Vbus
power is turned off, but instead it does so when the D+ pullup is
turned off.
This can cause a deadlock in the composite core when a gadget driver
is unregistered:
[ 88.361471] ============================================
[ 88.362014] WARNING: possible recursive locking detected
[ 88.362580] 4.14.0-rc2+ #9 Not tainted
[ 88.363010] --------------------------------------------
[ 88.363561] v4l_id/526 is trying to acquire lock:
[ 88.364062] (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547e03>] composite_disconnect+0x43/0x100 [libcomposite]
[ 88.365051]
[ 88.365051] but task is already holding lock:
[ 88.365826] (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
[ 88.366858]
[ 88.366858] other info that might help us debug this:
[ 88.368301] Possible unsafe locking scenario:
[ 88.368301]
[ 88.369304] CPU0
[ 88.369701] ----
[ 88.370101] lock(&(&cdev->lock)->rlock);
[ 88.370623] lock(&(&cdev->lock)->rlock);
[ 88.371145]
[ 88.371145] *** DEADLOCK ***
[ 88.371145]
[ 88.372211] May be due to missing lock nesting notation
[ 88.372211]
[ 88.373191] 2 locks held by v4l_id/526:
[ 88.373715] #0: (&(&cdev->lock)->rlock){....}, at: [<ffffffffa0547b09>] usb_function_deactivate+0x29/0x80 [libcomposite]
[ 88.374814] #1: (&(&dum_hcd->dum->lock)->rlock){....}, at: [<ffffffffa05bd48d>] dummy_pullup+0x7d/0xf0 [dummy_hcd]
[ 88.376289]
[ 88.376289] stack backtrace:
[ 88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
[ 88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[ 88.379504] Call Trace:
[ 88.380019] dump_stack+0x86/0xc7
[ 88.380605] __lock_acquire+0x841/0x1120
[ 88.381252] lock_acquire+0xd5/0x1c0
[ 88.381865] ? composite_disconnect+0x43/0x100 [libcomposite]
[ 88.382668] _raw_spin_lock_irqsave+0x40/0x54
[ 88.383357] ? composite_disconnect+0x43/0x100 [libcomposite]
[ 88.384290] composite_disconnect+0x43/0x100 [libcomposite]
[ 88.385490] set_link_state+0x2d4/0x3c0 [dummy_hcd]
[ 88.386436] dummy_pullup+0xa7/0xf0 [dummy_hcd]
[ 88.387195] usb_gadget_disconnect+0xd8/0x160 [udc_core]
[ 88.387990] usb_gadget_deactivate+0xd3/0x160 [udc_core]
[ 88.388793] usb_function_deactivate+0x64/0x80 [libcomposite]
[ 88.389628] uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]
This patch changes the code to test the port-power status bit rather
than the port-connect status bit when deciding whether to isue the
callback.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: David Tulloh <david@tulloh.id.au>
CC: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The dummy-hcd driver doesn't support emulation of isochronous
transfers. Therefore it doesn't need to export isochronous endpoint
descriptors; they can be commented out.
Also, the comments in the source code don't express clearly enough the
fact that isochronous isn't supported. They need to be more explicit.
Finally, change the error status value we use (in theory) for
isochronous URBs. checkpatch complains about ENOSYS; EINVAL is more
appropriate (it is documented to mean "ISO madness").
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Part of the emulation performed by dummy-hcd is accounting for
bandwidth utilization. The total amount of data transferred in a
single frame is supposed to be no larger than an actual USB connection
could accommodate.
Currently the driver performs bandwidth limiting only for bulk
transfers; control and periodic transfers are effectively unlimited.
(Presumably drivers were not expected to request extremely large
control or interrupt transfers.) This patch improves the situation
somewhat by restricting them as well.
The emulation still isn't perfect. On a real system, even 0-length
transfers use some bandwidth because of transaction overhead
(IN, OUT, ACK, NACK packets) and packet overhead (SYNC, PID, bit
stuffing, CRC, EOP). Adding in those factors is left as an exercise
for a later patch.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver triggers actions on both edges of the vbus signal.
The former PIO controller was triggering IRQs on both falling and rising edges
by default. Newer PIO controller don't, so it's better to set it explicitly to
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING.
Without this patch we may trigger the connection with host but only on some
bouncing signal conditions and thus lose connecting events.
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: stable <stable@vger.kernel.org> # v4.4+
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
By submitting completed transfers to the system workqueue there is no
guarantee that completion events will be queued up in the correct order,
as in multi-processor systems there is a thread running for each
processor and the work items are not bound to a particular core.
This means that several completions are in the queue at the same time,
they may be processed in parallel and complete out of order, resulting
in data appearing corrupt when read by userspace.
Create a single-threaded workqueue for FunctionFS so that data completed
requests is passed to userspace in the order in which they complete.
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
This patch fixes an issue that this driver cannot go status stage
in control read when the req.zero is set to 1 and the len in
usb3_write_pipe() is set to 0. Otherwise, if we use g_ncm driver,
usb enumeration takes long time (5 seconds or more).
Fixes: 746bfe63bb ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
According to the datasheet of R-Car Gen3, the Pn_RAMMAP.Pn_MPKT should
be set to one of 8, 16, 32, 64, 512 and 1024. Otherwise, when a gadget
driver uses an interrupt endpoint, unexpected behavior happens. So,
this patch fixes it.
Fixes: 746bfe63bb ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
When bRequestType & USB_DIR_IN is false and req.length is 0 in control
transfer, since it means non-data, this driver should not set the mode
as control write. So, this patch fixes it.
Fixes: 746bfe63bb ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
A recent change to the synchronization in dummy-hcd was incorrect.
The issue was that dummy_udc_stop() contained no locking and therefore
could race with various gadget driver callbacks, and the fix was to
add locking and issue the callbacks with the private spinlock held.
UDC drivers aren't supposed to do this. Gadget driver callback
routines are allowed to invoke functions in the UDC driver, and these
functions will generally try to acquire the private spinlock. This
would deadlock the driver.
The correct solution is to drop the spinlock before issuing callbacks,
and avoid races by emulating the synchronize_irq() call that all real
UDC drivers must perform in their ->udc_stop() routines after
disabling interrupts. This involves adding a flag to dummy-hcd's
private structure to keep track of whether interrupts are supposed to
be enabled, and adding a counter to keep track of ongoing callbacks so
that dummy_udc_stop() can wait for them all to finish.
A real UDC driver won't receive disconnect, reset, suspend, resume, or
setup events once it has disabled interrupts. dummy-hcd will receive
them but won't try to issue any gadget driver callbacks, which should
be just as good.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Fixes: f16443a034 ("USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks")
CC: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The dummy-hcd HCD/UDC emulator tries not to do too much work during
each timer interrupt. But it doesn't try very hard; currently all
it does is limit the total amount of bulk data transferred. Other
transfer types aren't limited, and URBs that transfer no data (because
of an error, perhaps) don't count toward the limit, even though on a
real USB bus they would consume at least a minimum overhead.
This means it's possible to get the driver stuck in an infinite loop,
for example, if the host class driver resubmits an URB every time it
completes (which is common for interrupt URBs). Each time the URB is
resubmitted it gets added to the end of the pending-URBs list, and
dummy-hcd doesn't stop until that list is empty. Andrey Konovalov was
able to trigger this failure mode using the syzkaller fuzzer.
This patch fixes the infinite-loop problem by restricting the URBs
handled during each timer interrupt to those that were already on the
pending list when the interrupt routine started. Newly added URBs
won't be processed until the next timer interrupt. The problem of
properly accounting for non-bulk bandwidth (as well as packet and
transaction overhead) is not addressed here.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
The dummy-hcd UDC driver is not careful about the way it handles
connection speeds. It ignores the module parameter that is supposed
to govern the maximum connection speed and it doesn't set the HCD
flags properly for the case where it ends up running at full speed.
The result is that in many cases, gadget enumeration over dummy-hcd
fails because the bMaxPacketSize byte in the device descriptor is set
incorrectly. For example, the default settings call for a high-speed
connection, but the maxpacket value for ep0 ends up being set for a
Super-Speed connection.
This patch fixes the problem by initializing the gadget's max_speed
and the HCD flags correctly.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
As a holdover from the old g_file_storage gadget, the g_mass_storage
legacy gadget driver attempts to unregister itself when its main
operating thread terminates (if it hasn't been unregistered already).
This is not strictly necessary; it was never more than an attempt to
have the gadget fail cleanly if something went wrong and the main
thread was killed.
However, now that the UDC core manages gadget drivers independently of
UDC drivers, this scheme doesn't work any more. A simple test:
modprobe dummy-hcd
modprobe g-mass-storage file=...
rmmod dummy-hcd
ends up in a deadlock with the following backtrace:
sysrq: SysRq : Show Blocked State
task PC stack pid father
file-storage D 0 1130 2 0x00000000
Call Trace:
__schedule+0x53e/0x58c
schedule+0x6e/0x77
schedule_preempt_disabled+0xd/0xf
__mutex_lock.isra.1+0x129/0x224
? _raw_spin_unlock_irqrestore+0x12/0x14
__mutex_lock_slowpath+0x12/0x14
mutex_lock+0x28/0x2b
usb_gadget_unregister_driver+0x29/0x9b [udc_core]
usb_composite_unregister+0x10/0x12 [libcomposite]
msg_cleanup+0x1d/0x20 [g_mass_storage]
msg_thread_exits+0xd/0xdd7 [g_mass_storage]
fsg_main_thread+0x1395/0x13d6 [usb_f_mass_storage]
? __schedule+0x573/0x58c
kthread+0xd9/0xdb
? do_set_interface+0x25c/0x25c [usb_f_mass_storage]
? init_completion+0x1e/0x1e
ret_from_fork+0x19/0x24
rmmod D 0 1155 683 0x00000000
Call Trace:
__schedule+0x53e/0x58c
schedule+0x6e/0x77
schedule_timeout+0x26/0xbc
? __schedule+0x573/0x58c
do_wait_for_common+0xb3/0x128
? usleep_range+0x81/0x81
? wake_up_q+0x3f/0x3f
wait_for_common+0x2e/0x45
wait_for_completion+0x17/0x19
fsg_common_put+0x34/0x81 [usb_f_mass_storage]
fsg_free_inst+0x13/0x1e [usb_f_mass_storage]
usb_put_function_instance+0x1a/0x25 [libcomposite]
msg_unbind+0x2a/0x42 [g_mass_storage]
__composite_unbind+0x4a/0x6f [libcomposite]
composite_unbind+0x12/0x14 [libcomposite]
usb_gadget_remove_driver+0x4f/0x77 [udc_core]
usb_del_gadget_udc+0x52/0xcc [udc_core]
dummy_udc_remove+0x27/0x2c [dummy_hcd]
platform_drv_remove+0x1d/0x31
device_release_driver_internal+0xe9/0x16d
device_release_driver+0x11/0x13
bus_remove_device+0xd2/0xe2
device_del+0x19f/0x221
? selinux_capable+0x22/0x27
platform_device_del+0x21/0x63
platform_device_unregister+0x10/0x1a
cleanup+0x20/0x817 [dummy_hcd]
SyS_delete_module+0x10c/0x197
? ____fput+0xd/0xf
? task_work_run+0x55/0x62
? prepare_exit_to_usermode+0x65/0x75
do_fast_syscall_32+0x86/0xc3
entry_SYSENTER_32+0x4e/0x7c
What happens is that removing the dummy-hcd driver causes the UDC core
to unbind the gadget driver, which it does while holding the udc_lock
mutex. The unbind routine in g_mass_storage tells the main thread to
exit and waits for it to terminate.
But as mentioned above, when the main thread exits it tries to
unregister the mass-storage function driver. Via the composite
framework this ends up calling usb_gadget_unregister_driver(), which
tries to acquire the udc_lock mutex. The result is deadlock.
The simplest way to fix the problem is not to be so clever: The main
thread doesn't have to unregister the function driver. The side
effects won't be so terrible; if the gadget is still attached to a USB
host when the main thread is killed, it will appear to the host as
though the gadget's firmware has crashed -- a reasonably accurate
interpretation, and an all-too-common occurrence for USB mass-storage
devices.
In fact, the code to unregister the driver when the main thread exits
is specific to g-mass-storage; it is not used when f-mass-storage is
included as a function in a larger composite device. Therefore the
entire mechanism responsible for this (the fsg_operations structure
with its ->thread_exits method, the fsg_common_set_ops() routine, and
the msg_thread_exits() callback routine) can all be eliminated. Even
the msg_registered bitflag can be removed, because now the driver is
unregistered in only one place rather than in two places.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The gadgetfs driver (drivers/usb/gadget/legacy/inode.c) was written
before the UDC and composite frameworks were adopted; it is a legacy
driver. As such, it expects that once bound to a UDC controller, it
will not be unbound until it unregisters itself.
However, the UDC framework does unbind function drivers while they are
still registered. When this happens, it can cause the gadgetfs driver
to misbehave or crash. For example, userspace can cause a crash by
opening the device file and doing an ioctl call before setting up a
configuration (found by Andrey Konovalov using the syzkaller fuzzer).
This patch adds checks and synchronization to prevent these bad
behaviors. It adds a udc_usage counter that the driver increments at
times when it is using a gadget interface without holding the private
spinlock. The unbind routine waits for this counter to go to 0 before
returning, thereby ensuring that the UDC is no longer in use.
The patch also adds a check in the dev_ioctl() routine to make sure
the driver is bound to a UDC before dereferencing the gadget pointer,
and it makes destroy_ep_files() synchronize with the endpoint I/O
routines, to prevent the user from accessing an endpoint data
structure after it has been removed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The gadgetfs driver as a long-outstanding FIXME, regarding a call of
copy_to_user() made while holding a spinlock. This patch fixes the
issue by dropping the spinlock and using the dev->udc_usage mechanism
introduced by another recent patch to guard against status changes
while the lock isn't held.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
CC: <stable@vger.kernel.org>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gcc-8 points out two comparisons that are clearly bogus
and almost certainly not what the author intended to write:
drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed':
drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
USB_PORT_STAT_ENABLE) == 1 &&
^~
drivers/usb/gadget/udc/dummy_hcd.c:381:25: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]
USB_SS_PORT_LS_U0) == 1 &&
^~
I looked at the code for a bit and came up with a change that makes
it look like what the author probably meant here. This makes it
look reasonable to me and to gcc, shutting up the warning.
It does of course change behavior as the two conditions are actually
evaluated rather than being hardcoded to false, and I have made no
attempt at verifying that the changed logic makes sense in the context
of a USB HCD, so that part needs to be reviewed carefully.
Fixes: 1cd8fd2887 ("usb: gadget: dummy_hcd: add SuperSpeed support")
Cc: Tatyana Brokhman <tlinder@codeaurora.org>
Cc: Felipe Balbi <balbi@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Fix build errors that happen when CONFIG_EXTCON=m and
CONFIG_USB_SNP_UDC_PLAT=y by preventing that combination in Kconfig.
CONFIG_EXTCON can still be disabled or enabled for this driver since
<linux/extcon.h> has stubs for the disabled case, but if CONFIG_EXTCON=m,
USB_SNP_UDC_PLAT is restricted to m or n (cannot be builtin).
drivers/built-in.o: In function `udc_plat_remove':
snps_udc_plat.c:(.text+0x2c4060): undefined reference to `extcon_unregister_notifier'
drivers/built-in.o: In function `udc_plat_probe':
snps_udc_plat.c:(.text+0x2c438c): undefined reference to `extcon_get_edev_by_phandle'
snps_udc_plat.c:(.text+0x2c43f2): undefined reference to `extcon_register_notifier'
snps_udc_plat.c:(.text+0x2c4416): undefined reference to `extcon_get_state'
snps_udc_plat.c:(.text+0x2c44f7): undefined reference to `extcon_unregister_notifier'
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
If usb_gadget_giveback_request() is called in usb_ep_queue(),
this printer_write() is possible to cause spinlock recursion. So,
this patch adds spin_unlock() before calls usb_ep_queue() to avoid it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Consider the following case: udc controller supports SuperSpeed. If we
first load a HighSpeed gadget followed by a SuperSpeed gadget, the
SuperSpeed gadget will be limited to HighSpeed as UDC core driver
doesn't call ->udc_set_speed() in the second case.
Call ->udc_set_speed() unconditionally to fix this issue.
This will also fix the case for dwc3 controller driver when SuperSpeed
gadget is loaded first and works in HighSpeed only as udc_set_speed()
was never being called.
Fixes: 6099eca796ae ("usb: gadget: core: introduce ->udc_set_speed() method")
Cc: <stable@vger.kernel.org> [v4.13+]
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Pull more set_fs removal from Al Viro:
"Christoph's 'use kernel_read and friends rather than open-coding
set_fs()' series"
* 'work.set_fs' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
fs: unexport vfs_readv and vfs_writev
fs: unexport vfs_read and vfs_write
fs: unexport __vfs_read/__vfs_write
lustre: switch to kernel_write
gadget/f_mass_storage: stop messing with the address limit
mconsole: switch to kernel_read
btrfs: switch write_buf to kernel_write
net/9p: switch p9_fd_read to kernel_write
mm/nommu: switch do_mmap_private to kernel_read
serial2002: switch serial2002_tty_write to kernel_{read/write}
fs: make the buf argument to __kernel_write a void pointer
fs: fix kernel_write prototype
fs: fix kernel_read prototype
fs: move kernel_read to fs/read_write.c
fs: move kernel_write to fs/read_write.c
autofs4: switch autofs4_write to __kernel_write
ashmem: switch to ->read_iter
Here is the big char/misc driver update for 4.14-rc1.
Lots of different stuff in here, it's been an active development cycle
for some reason. Highlights are:
- updated binder driver, this brings binder up to date with what
shipped in the Android O release, plus some more changes that
happened since then that are in the Android development trees.
- coresight updates and fixes
- mux driver file renames to be a bit "nicer"
- intel_th driver updates
- normal set of hyper-v updates and changes
- small fpga subsystem and driver updates
- lots of const code changes all over the driver trees
- extcon driver updates
- fmc driver subsystem upadates
- w1 subsystem minor reworks and new features and drivers added
- spmi driver updates
Plus a smattering of other minor driver updates and fixes.
All of these have been in linux-next with no reported issues for a
while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWa1+Ew8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yl26wCgquufNylfhxr65NbJrovduJYzRnUAniCivXg8
bePIh/JI5WxWoHK+wEbY
=hYWx
-----END PGP SIGNATURE-----
Merge tag 'char-misc-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH:
"Here is the big char/misc driver update for 4.14-rc1.
Lots of different stuff in here, it's been an active development cycle
for some reason. Highlights are:
- updated binder driver, this brings binder up to date with what
shipped in the Android O release, plus some more changes that
happened since then that are in the Android development trees.
- coresight updates and fixes
- mux driver file renames to be a bit "nicer"
- intel_th driver updates
- normal set of hyper-v updates and changes
- small fpga subsystem and driver updates
- lots of const code changes all over the driver trees
- extcon driver updates
- fmc driver subsystem upadates
- w1 subsystem minor reworks and new features and drivers added
- spmi driver updates
Plus a smattering of other minor driver updates and fixes.
All of these have been in linux-next with no reported issues for a
while"
* tag 'char-misc-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (244 commits)
ANDROID: binder: don't queue async transactions to thread.
ANDROID: binder: don't enqueue death notifications to thread todo.
ANDROID: binder: Don't BUG_ON(!spin_is_locked()).
ANDROID: binder: Add BINDER_GET_NODE_DEBUG_INFO ioctl
ANDROID: binder: push new transactions to waiting threads.
ANDROID: binder: remove proc waitqueue
android: binder: Add page usage in binder stats
android: binder: fixup crash introduced by moving buffer hdr
drivers: w1: add hwmon temp support for w1_therm
drivers: w1: refactor w1_slave_show to make the temp reading functionality separate
drivers: w1: add hwmon support structures
eeprom: idt_89hpesx: Support both ACPI and OF probing
mcb: Fix an error handling path in 'chameleon_parse_cells()'
MCB: add support for SC31 to mcb-lpc
mux: make device_type const
char: virtio: constify attribute_group structures.
Documentation/ABI: document the nvmem sysfs files
lkdtm: fix spelling mistake: "incremeted" -> "incremented"
perf: cs-etm: Fix ETMv4 CONFIGR entry in perf.data file
nvmem: include linux/err.h from header
...
Instead use kernel_read/write consistently, which also makes sparse
happy.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Detailed description for this pull request:
1. Add new 'extcon-usbc-cros-ec.c' driver
- ChromeOS Embedded Controller extcon driver supports
the detection of the Display Port (EXTCON_DISP_DP)
through USB C-type and contol it.
2. Update extcon core
- Modify the description for both functions and structures
in order to improve the readability and give the more correct
guide about the role of functions because there are different
explanation even if the same arguments.
- Keep the indentation with tab instead of space
- Remove the following deprecated extcon API. The deprecated API
are exchanged on all of linux tree.
: extcon_get_cable_state_() -> extcon_get_state()
: extcon_set_cable_state_() -> extcon_set_state_sync()
3. Include the two immutable branch as following:
- ib-extcon-mfd-4.14 for the 'extcon-ubsc-cros-ec.c' driver
because the patches of 'extcon-ubsc-cros-ec.c' touch the MFD directory.
- ib-extcon-usb-phy-4.14 for removing the deprecated extcon API
because the usb/phy driver usese the deprecated extcon API.
So, this immutable branch alters the extcon API and then
remove them from extcon.
4. Fix minor issue of extcon driver
- Fix the MHL detection on extcon-max77693.c
- Convert to using %pOF instead of full_name on extcon.c
- Add 'const' kerywod for acpi_device_id on extcon-intel-int3496.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZn3XJAAoJEJzN3yze689Tat0P/jnTEqEleNCDBYx4SW/c7ilO
KCNXEEfgtD0sIon3KPt6Zbc0Na+QmD7DSrdlPsc0864k7Vrb/M+bshETtrxC/fQi
WW8SaRHNLePCH0UnayUoukYtlui1zWbfdJ8HLQqfQILQy2LVIaA7famL8wuHHXJR
4zl69EQPTODBKt9akHjQ2pLuucN/6KAl4QcBje4eY/c+mMpyjo6Ivi6vRCFpL66T
J+rBobTvRoMUwTaIlmquwoVgdMpk2DA9NXOypGT3slIeIqfyUf+7TUtBGbVrCmvj
o+zVap5pcZhf6KXfi4OZUbDdgXpIn2V1p5ztAq0JlW2LcyguZ1bZs3EJAsyRS0aS
3ykru6e5KqH4vcMwcxkgatPKhSSPyC93ETdvx55IF7uP6qH8ym1hgtDKr7FrPW0+
Md/gO8YPgFMZRUG2rAbCJO/zFbS4aNh0X6eOOCmsraxy0IQBE/p41zw8Tp7Jgupv
oxV1beXyB2DLBCGkj12baGUzePZent/vse3dPbl8YHiubQCgAa4u4NO70EU/T9W+
3PeJEK4o3vw9aDBGTMINRUSMKQGCAkf4VL+wyBn8k/LTYWPP1YsA1+beX1E184vB
vS0nnjhJP8VphfAAx5+eYnep6HPTUPwlyi9CR/vbSG8HmPkfIDslQ8700VsmsEkn
6mMDK+pd9FGjs6nwwO5d
=oQMu
-----END PGP SIGNATURE-----
Merge tag 'extcon-next-for-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next
Chanwoo writes:
Update extcon for 4.14
Detailed description for this pull request:
1. Add new 'extcon-usbc-cros-ec.c' driver
- ChromeOS Embedded Controller extcon driver supports
the detection of the Display Port (EXTCON_DISP_DP)
through USB C-type and contol it.
2. Update extcon core
- Modify the description for both functions and structures
in order to improve the readability and give the more correct
guide about the role of functions because there are different
explanation even if the same arguments.
- Keep the indentation with tab instead of space
- Remove the following deprecated extcon API. The deprecated API
are exchanged on all of linux tree.
: extcon_get_cable_state_() -> extcon_get_state()
: extcon_set_cable_state_() -> extcon_set_state_sync()
3. Include the two immutable branch as following:
- ib-extcon-mfd-4.14 for the 'extcon-ubsc-cros-ec.c' driver
because the patches of 'extcon-ubsc-cros-ec.c' touch the MFD directory.
- ib-extcon-usb-phy-4.14 for removing the deprecated extcon API
because the usb/phy driver usese the deprecated extcon API.
So, this immutable branch alters the extcon API and then
remove them from extcon.
4. Fix minor issue of extcon driver
- Fix the MHL detection on extcon-max77693.c
- Convert to using %pOF instead of full_name on extcon.c
- Add 'const' kerywod for acpi_device_id on extcon-intel-int3496.c
Make this const as it is only used during a copy operation.
Done using Coccinelle.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
