This converts the FUSB302 driver to use GPIO descriptors.
The conversion to descriptors per se is pretty straight-forward.
In the process I discovered that:
1. The driver uses a completely undocumented device tree binding
for the interrupt GPIO line, "fcs,int_n". Ooops.
2. The undocumented binding, presumably since it has not seen
review, is just "fcs,int_n", lacking the compulsory "-gpios"
suffix and also something that is not a good name because
the "_n" implies the line is inverted which is something we
handle with flags in the device tree. Ooops.
3. Possibly the driver should not be requesting the line as a
GPIO and request the corresponding interrupt line by open
coding, the GPIO chip is very likely doubleing as an IRQ
controller and can probably provide an interrupt directly
for this line with interrupts-extended = <&gpio0 ...>;
4. Possibly the IRQ should just be tagged on the I2C client node
in the device tree like apparently ACPI does, as it overrides
this IRQ with client->irq if that exists.
But now it is too late to do much about that and as I can see
this is used like this in the Pinebook which is a shipping product
so let'a just contain the mess and move on.
The property currently appears in:
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
Create a quirk in the GPIO OF library to allow this property
specifically to be specified without the "-gpios" suffix, we have
other such bindings already.
Cc: Tobias Schramm <t.schramm@manjaro.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Yueyao Zhu <yueyao@google.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200415192448.305257-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During device mode initialization, lots of device information
are printed to console, see below. Change them as debug message.
cdns-usb3 5b130000.cdns3: Initialized ep0 support:
cdns-usb3 5b130000.cdns3: Initialized ep1out support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep2out support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep3out support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep4out support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep5out support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep6out support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep7out support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep1in support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep2in support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep3in support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep4in support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep5in support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep6in support: BULK, INT ISO
cdns-usb3 5b130000.cdns3: Initialized ep7in support: BULK, INT ISO
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Link: https://lore.kernel.org/r/20200331081005.32752-4-peter.chen@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In short, we have three kinds of role switches:
- Based on SoC: ID and VBUS
- Based on external connnctor, eg, Type-C or GPIO Connector
- Based on user choices through sysfs
Since HW handling and usb-role-switch handling are at
different places, we do not need role_override any more,
and this flag could not judge external connector case well.
With role_override deleted, We use cdns3_hw_role_switch for
the 1st use case, and usb-role-switch for the 2nd and 3rd cases.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Link: https://lore.kernel.org/r/20200331081005.32752-2-peter.chen@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Implement a get_multiple function for gpio-pca953x. If a driver
leaves get_multiple unimplemented then gpio_chip_get_multiple()
in gpiolib.c takes care of it by calling chip->get() as needed.
For i2c chips this is very inefficient. For example if you do an
8-bit read then instead of a single i2c transaction there are
8 transactions reading the same byte!
Signed-off-by: Paul Thomas <pthomas8589@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The usb_get_maximum_speed() function is part of the usb-common module,
so enable it by selecting the corresponding Kconfig symbol.
While at it, also make sure to depend on USB_SUPPORT because USB_PHY
requires that. This can lead to Kconfig conflicts if USB_SUPPORT is not
enabled while attempting to enable PHY_TEGRA_XUSB.
Reported-by: kbuild test robot <lkp@intel.com>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200330101038.2422389-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For userspace functions using OS Descriptors, if a function also supplies
Extended Property descriptors currently the counts and lengths stored in
the ms_os_descs_ext_prop_{count,name_len,data_len} variables are not
getting reset to 0 during an unbind or when the epfiles are closed. If
the same function is re-bound and the descriptors are re-written, this
results in those count/length variables to monotonically increase
causing the VLA allocation in _ffs_func_bind() to grow larger and larger
at each bind/unbind cycle and eventually fail to allocate.
Fix this by clearing the ms_os_descs_ext_prop count & lengths to 0 in
ffs_data_reset().
Fixes: f0175ab519 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable@vger.kernel.org
Signed-off-by: Udipto Goswami <ugoswami@codeaurora.org>
Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
Reviewed-by: Manu Gautam <mgautam@codeaurora.org>
Link: https://lore.kernel.org/r/20200402044521.9312-1-sallenki@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A SCSI error handler and block runtime PM must not allocate
memory with GFP_KERNEL. Furthermore they must not wait for
tasks allocating memory with GFP_KERNEL.
That means that they cannot share a workqueue with arbitrary tasks.
Fix this for UAS using a private workqueue.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Fixes: f9dc024a2d ("uas: pre_reset and suspend: Fix a few races")
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200415141750.811-2-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since commit ef441dd6af ("usb: typec: mux: Allow the muxes to be named")
the typec_switch_desc and typec_mux_desc structs contain a name field.
The pi3usb30532 driver allocates these structs on the stack and so far did
not explicitly zero the mem used for the structs. This causes the new name
fields to point to a random memory address, which in my test case happens
to be a valid address leading to "interesting" mux / switch names:
[root@localhost ~]# ls -l /sys/class/typec_mux/
total 0
lrwxrwxrwx. 1 root root 0 Apr 14 12:55 ''$'\r''-switch' -> ...
lrwxrwxrwx. 1 root root 0 Apr 14 12:55 ''$'\320\302\006''2'$'...
Explicitly initialize the structs to zero when declaring them on the stack
so that any unused fields get set to 0, fixing this.
Fixes: ef441dd6af ("usb: typec: mux: Allow the muxes to be named")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200414133313.131802-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fixes a bug that causes the USB3 early console to freeze after
printing a single line on AMD machines because it can't parse the
Transfer TRB properly.
The spec at
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf
says in section "4.5.1 Device Context Index" that the Context Index,
also known as Endpoint ID according to
section "1.6 Terms and Abbreviations", is normally computed as
`DCI = (Endpoint Number * 2) + Direction`, which matches the current
definitions of XDBC_EPID_OUT and XDBC_EPID_IN.
However, the numbering in a Debug Capability Context data structure is
supposed to be different:
Section "7.6.3.2 Endpoint Contexts and Transfer Rings" explains that a
Debug Capability Context data structure has the endpoints mapped to indices
0 and 1.
Change XDBC_EPID_OUT/XDBC_EPID_IN to the spec-compliant values, add
XDBC_EPID_OUT_INTEL/XDBC_EPID_IN_INTEL with Intel's incorrect values, and
let xdbc_handle_tx_event() handle both.
I have verified that with this patch applied, the USB3 early console works
on both an Intel and an AMD machine.
Fixes: aeb9dd1de9 ("usb/early: Add driver for xhci debug capability")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Link: https://lore.kernel.org/r/20200401074619.8024-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
FuzzUSB (a variant of syzkaller) found a free-while-still-in-use bug
in the USB scatter-gather library:
BUG: KASAN: use-after-free in atomic_read
include/asm-generic/atomic-instrumented.h:26 [inline]
BUG: KASAN: use-after-free in usb_hcd_unlink_urb+0x5f/0x170
drivers/usb/core/hcd.c:1607
Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27
CPU: 1 PID: 27 Comm: kworker/u4:1 Not tainted 5.5.11 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1ubuntu1 04/01/2014
Workqueue: scsi_tmf_2 scmd_eh_abort_handler
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xce/0x128 lib/dump_stack.c:118
print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374
__kasan_report+0x153/0x1cb mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:639
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x152/0x1b0 mm/kasan/generic.c:192
__kasan_check_read+0x11/0x20 mm/kasan/common.c:95
atomic_read include/asm-generic/atomic-instrumented.h:26 [inline]
usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607
usb_unlink_urb+0x72/0xb0 drivers/usb/core/urb.c:657
usb_sg_cancel+0x14e/0x290 drivers/usb/core/message.c:602
usb_stor_stop_transport+0x5e/0xa0 drivers/usb/storage/transport.c:937
This bug occurs when cancellation of the S-G transfer races with
transfer completion. When that happens, usb_sg_cancel() may continue
to access the transfer's URBs after usb_sg_wait() has freed them.
The bug is caused by the fact that usb_sg_cancel() does not take any
sort of reference to the transfer, and so there is nothing to prevent
the URBs from being deallocated while the routine is trying to use
them. The fix is to take such a reference by incrementing the
transfer's io->count field while the cancellation is in progres and
decrementing it afterward. The transfer's URBs are not deallocated
until io->complete is triggered, which happens when io->count reaches
zero.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Kyungtae Kim <kt0755@gmail.com>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2003281615140.14837-100000@netrider.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the following cppcheck warnings:
drivers/usb/gadget/legacy/inode.c:1364:8: style: Redundant initialization for 'value'. The initialized value is overwritten$
value = -EOPNOTSUPP;
^
drivers/usb/gadget/legacy/inode.c:1331:15: note: value is initialized
int value = -EOPNOTSUPP;
^
drivers/usb/gadget/legacy/inode.c:1364:8: note: value is overwritten
value = -EOPNOTSUPP;
^
drivers/usb/gadget/legacy/inode.c:1817:8: style: Redundant initialization for 'value'. The initialized value is overwritten$
value = -EINVAL;
^
drivers/usb/gadget/legacy/inode.c:1787:18: note: value is initialized
ssize_t value = len, length = len;
^
drivers/usb/gadget/legacy/inode.c:1817:8: note: value is overwritten
value = -EINVAL;
^
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200403131652.8183-1-masahiroy@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
u132_static_list is a global list protected by u132_module_lock.
It is read in the u132_hcd_exit() function without holding the lock
thus may lead to data race.
However, it turns out that this list isn't used for anything useful
and thus it is okay to get rid of it.
Thus, remove the u132_static_list from u132-hcd module.
Also remove struct list_head u132_list from struct u132.
Found by Linux Driver Verification project (linuxtesting.org).
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Link: https://lore.kernel.org/r/20200404174102.19862-1-madhuparnabhowmik10@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fixes two issues in the snd-soc-rcar driver blocking multichannel
HDMI audio out: The parent SSI in a multi-SSI configuration is not
correctly set up and started, and the SSI->HDMI channel mapping is
wrong.
With these patches, the following device tree snippet can be used on an
r8a7795-based platform (Salvator-X) to enable multichannel HDMI audio on
HDMI0:
rsnd_port1: port@1 {
rsnd_endpoint1: endpoint {
remote-endpoint = <&dw_hdmi0_snd_in>;
dai-format = "i2s";
bitclock-master = <&rsnd_endpoint1>;
frame-master = <&rsnd_endpoint1>;
playback = <&ssi0 &ssi1 &ssi2 &ssi9>;
};
};
With a capable receiver attached, all of 2ch (stereo), 6ch (e.g. 5.1)
and 8ch audio output should work.
Matthias Blankertz (2):
ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode
ASoC: rsnd: Fix HDMI channel mapping for multi-SSI mode
sound/soc/sh/rcar/ssi.c | 8 ++++----
sound/soc/sh/rcar/ssiu.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
base-commit: 7111951b8d
--
2.26.0
