Blackbird™ Linux sources for OpenPOWER https://git.raptorcs.com/git/blackbird-op-linux/atom?h=master 2020-01-29T18:09:44+00:00 2020-01-29T18:09:44+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-01-29T18:09:44+00:00 urn:sha1:aac96626713fe167c672f9a008be0f514aa3e237 Pull USB/Thunderbolt/PHY driver updates from Greg KH: "Here is the big USB and Thunderbolt and PHY driver updates for 5.6-rc1. With the advent of USB4, "Thunderbolt" has really become USB4, so the renaming of the Kconfig option and starting to share subsystem code has begun, hence both subsystems coming in through the same tree here. PHY driver updates also touched USB drivers, so that is coming in through here as well. Major stuff included in here are: - USB 4 initial support added (i.e. Thunderbolt) - musb driver updates - USB gadget driver updates - PHY driver updates - USB PHY driver updates - lots of USB serial stuff fixed up - USB typec updates - USB-IP fixes - lots of other smaller USB driver updates All of these have been in linux-next for a while now (the usb-serial tree is already tested in linux-next on its own before merged into here), with no reported issues" [ Removed an incorrect compile test enablement for PHY_EXYNOS5250_SATA that causes configuration warnings - Linus ] * tag 'usb-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (207 commits) Doc: ABI: add usb charger uevent usb: phy: show USB charger type for user usb: cdns3: fix spelling mistake and rework grammar in text usb: phy: phy-gpio-vbus-usb: Convert to GPIO descriptors USB: serial: cyberjack: fix spelling mistake "To" -> "Too" USB: serial: ir-usb: simplify endpoint check USB: serial: ir-usb: make set_termios synchronous USB: serial: ir-usb: fix IrLAP framing USB: serial: ir-usb: fix link-speed handling USB: serial: ir-usb: add missing endpoint sanity check usb: typec: fusb302: fix "op-sink-microwatt" default that was in mW usb: typec: wcove: fix "op-sink-microwatt" default that was in mW usb: dwc3: pci: add ID for the Intel Comet Lake -V variant usb: typec: tcpci: mask event interrupts when remove driver usb: host: xhci-tegra: set MODULE_FIRMWARE for tegra186 usb: chipidea: add inline for ci_hdrc_host_driver_init if host is not defined usb: chipidea: handle single role for usb role class usb: musb: fix spelling mistake: "periperal" -> "peripheral" phy: ti: j721e-wiz: Fix build error without CONFIG_OF_ADDRESS USB: usbfs: Always unlink URBs in reverse order ... 2020-01-27T21:03:00+00:00 Linus Torvalds torvalds@linux-foundation.org 2020-01-27T21:03:00+00:00 urn:sha1:6a1000bd27035bba17ede9dc915166276a811edb Pull ioremap updates from Christoph Hellwig: "Remove the ioremap_nocache API (plus wrappers) that are always identical to ioremap" * tag 'ioremap-5.6' of git://git.infradead.org/users/hch/ioremap: remove ioremap_nocache and devm_ioremap_nocache MIPS: define ioremap_nocache to ioremap 2020-01-21T18:36:59+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2020-01-21T18:36:59+00:00 urn:sha1:dd7d99dc688d0fc448976f52f8517fbdeccdccda We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2020-01-17T16:57:04+00:00 Alan Stern stern@rowland.harvard.edu 2020-01-17T15:47:13+00:00 urn:sha1:fdd64df7b9d1e20dbe28c9c205682b66ad821e6c When the kernel unlinks a bunch of URBs for a single endpoint, it should always unlink them in reverse order. This eliminates any possibility that some URB x will be unlinked before it can execute but the following URB x+1 will execute before it can be unlinked. Such an event would be bad, for obvious reasons. Chris Dickens pointed out that usbfs doesn't behave this way when it is unbound from an interface. All pending URBs are cancelled, but in the order of submission. This patch changes the behavior to make the unlinks occur in reverse order. It similarly changes the behavior when usbfs cancels the continuation URBs for a BULK endpoint. Suggested-by: Chris Dickens <christopher.a.dickens@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2001171045380.1571-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2020-01-15T12:14:28+00:00 Keiya Nobuta nobuta.keiya@fujitsu.com 2020-01-09T05:14:48+00:00 urn:sha1:9c06ac4c83df6d6fbdbf7488fbad822b4002ba19 If hub_activate() is called before D+ has stabilized after remote wakeup, the following situation might occur: __ ___________________ / \ / D+ __/ \__/ Hub _______________________________ | ^ ^ ^ | | | | Host _____v__|___|___________|______ | | | | | | | \-- Interrupt Transfer (*3) | | \-- ClearPortFeature (*2) | \-- GetPortStatus (*1) \-- Host detects remote wakeup - D+ goes high, Host starts running by remote wakeup - D+ is not stable, goes low - Host requests GetPortStatus at (*1) and gets the following hub status: - Current Connect Status bit is 0 - Connect Status Change bit is 1 - D+ stabilizes, goes high - Host requests ClearPortFeature and thus Connect Status Change bit is cleared at (*2) - After waiting 100 ms, Host starts the Interrupt Transfer at (*3) - Since the Connect Status Change bit is 0, Hub returns NAK. In this case, port_event() is not called in hub_event() and Host cannot recognize device. To solve this issue, flag change_bits even if only Connect Status Change bit is 1 when got in the first GetPortStatus. This issue occurs rarely because it only if D+ changes during a very short time between GetPortStatus and ClearPortFeature. However, it is fatal if it occurs in embedded system. Signed-off-by: Keiya Nobuta <nobuta.keiya@fujitsu.com> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200109051448.28150-1-nobuta.keiya@fujitsu.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2020-01-08T16:44:11+00:00 Qi Zhou atmgnd@outlook.com 2020-01-04T11:02:01+00:00 urn:sha1:1530f6f5f5806b2abbf2a9276c0db313ae9a0e09 According to bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") the kernel will try the old enumeration scheme first for high speed devices. This can happen when a high speed device is plugged in. But due to missing parentheses in the USE_NEW_SCHEME define, this logic can get messed up and the incorrect result happens. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Qi Zhou <atmgnd@outlook.com> Link: https://lore.kernel.org/r/ht4mtag8ZP-HKEhD0KkJhcFnVlOFV8N8eNjJVRD9pDkkLUNhmEo8_cL_sl7xy9mdajdH-T8J3TFQsjvoYQT61NFjQXy469Ed_BbBw_x4S1E=@protonmail.com [ fixup changelog text - gregkh] Cc: stable <stable@vger.kernel.org> Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2020-01-06T15:54:09+00:00 Alan Stern stern@rowland.harvard.edu 2020-01-06T15:43:42+00:00 urn:sha1:2548288b4fb059b2da9ceada172ef763077e8a59 It turns out that even though endpoints with a maxpacket length of 0 aren't useful for data transfer, the descriptors do serve other purposes. In particular, skipping them will also skip over other class-specific descriptors for classes such as UVC. This unexpected side effect has caused some UVC cameras to stop working. In addition, the USB spec requires that when isochronous endpoint descriptors are present in an interface's altsetting 0 (which is true on some devices), the maxpacket size _must_ be set to 0. Warning about such things seems like a bad idea. This patch updates an earlier commit which would log a warning and skip these endpoint descriptors. Now we only log a warning, and we don't even do that for isochronous endpoints in altsetting 0. We don't need to worry about preventing endpoints with maxpacket = 0 from ever being used for data transfers; usb_submit_urb() already checks for this. Reported-and-tested-by: Roger Whittaker <Roger.Whittaker@suse.com> Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length") Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://marc.info/?l=linux-usb&m=157790377329882&w=2 Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2001061040270.1514-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2020-01-06T08:45:59+00:00 Christoph Hellwig hch@lst.de 2020-01-06T08:43:50+00:00 urn:sha1:4bdc0d676a643140bdf17dbf7eafedee3d496a3c ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de> 2019-12-30T18:54:55+00:00 Johan Hovold johan@kernel.org 2019-12-19T16:10:16+00:00 urn:sha1:3e4f8e21c4f27bcf30a48486b9dcc269512b79ff Amend the endpoint-descriptor sanity checks to detect all duplicate endpoint addresses in a configuration. Commit 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses") added a check for duplicate endpoint addresses within a single alternate setting, but did not look for duplicate addresses in other interfaces. The current check would also not detect all duplicate addresses when one endpoint is as a (bi-directional) control endpoint. This specifically avoids overwriting the endpoint entries in struct usb_device when enabling a duplicate endpoint, something which could potentially lead to crashes or leaks, for example, when endpoints are later disabled. Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20191219161016.6695-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2019-12-11T08:06:41+00:00 Fredrik Noring noring@nocrew.org 2019-12-10T17:29:05+00:00 urn:sha1:f8c63edfd78905320e86b6b2be2b7a5ac768fa4e Fix commit 7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities") where local memory USB drivers erroneously allocate DMA memory instead of pool memory, causing OHCI Unrecoverable Error, disabled HC died; cleaning up The order between hcd_uses_dma() and hcd->localmem_pool is now arranged as in hcd_buffer_alloc() and hcd_buffer_free(), with the test for hcd->localmem_pool placed first. As an alternative, one might consider adjusting hcd_uses_dma() with static inline bool hcd_uses_dma(struct usb_hcd *hcd) { - return IS_ENABLED(CONFIG_HAS_DMA) && (hcd->driver->flags & HCD_DMA); + return IS_ENABLED(CONFIG_HAS_DMA) && + (hcd->driver->flags & HCD_DMA) && + (hcd->localmem_pool == NULL); } One can also consider unsetting HCD_DMA for local memory pool drivers. Fixes: 7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities") Cc: stable <stable@vger.kernel.org> Signed-off-by: Fredrik Noring <noring@nocrew.org> Link: https://lore.kernel.org/r/20191210172905.GA52526@sx9 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>