summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* misc: isl29020: add missed pm_runtime_disableChuhong Yuan2020-01-141-0/+1
| | | | | | | | | The driver forgets to call pm_runtime_disable in remove. Add the missed call to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20191118080931.30749-1-hslester96@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* misc: genwqe: fix compile warningsHongbo Yao2020-01-141-4/+4
| | | | | | | | | | | | | | | | | Using the following command will get compile warnings: make W=1 drivers/misc/genwqe/card_ddcb.o ARCH=x86_64 drivers/misc/genwqe/card_ddcb.c: In function setup_ddcb_queue: drivers/misc/genwqe/card_ddcb.c:1024:6: warning: variable rc set but not used [-Wunused-but-set-variable] drivers/misc/genwqe/card_ddcb.c: In function genwqe_card_thread: drivers/misc/genwqe/card_ddcb.c:1190:23: warning: variable rc set but not used [-Wunused-but-set-variable] Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Hongbo Yao <yaohongbo@huawei.com> Link: https://lore.kernel.org/r/20191205111655.170382-1-yaohongbo@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* bus: fsl-mc: properly empty-initialize structureIoana Ciornei2020-01-141-3/+3
| | | | | | | | | | | | | Use the proper form of the empty initializer when working with structures that contain an array. Otherwise, older gcc versions (eg gcc 4.9) will complain about this. Fixes: 1ac210d128ef ("bus: fsl-mc: add the fsl_mc_get_endpoint function") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Link: https://lore.kernel.org/r/20191204142950.30206-1-ioana.ciornei@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drivers/misc: sram-exec: have the callers of set_memory_*() check the return ↵Tianlin Li2020-01-141-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | value Right now several architectures allow their set_memory_*() family of functions to fail, but callers may not be checking the return values. If set_memory_*() returns with an error, call-site assumptions may be infact wrong to assume that it would either succeed or not succeed at all. Ideally, the failure of set_memory_*() should be passed up the call stack, and callers should examine the failure and deal with it. Need to fix the callers and add the __must_check attribute. They also may not provide any level of atomicity, in the sense that the memory protections may be left incomplete on failure. This issue likely has a few steps on effects architectures: 1) Have all callers of set_memory_*() helpers check the return value. 2) Add __must_check to all set_memory_*() helpers so that new uses do not ignore the return value. 3) Add atomicity to the calls so that the memory protections aren't left in a partial state. This series is part of step 1. Make sram driver check the return value of set_memory_*(). Signed-off-by: Tianlin Li <tli@digitalocean.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20191217194528.16461-1-tli@digitalocean.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 5.5-rc6 into char-misc-nextGreg Kroah-Hartman2020-01-13244-864/+1577
|\ | | | | | | | | | | We need the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * Linux 5.5-rc6v5.5-rc6Linus Torvalds2020-01-121-1/+1
| |
| * Merge tag 'riscv/for-v5.5-rc6' of ↵Linus Torvalds2020-01-124-6/+6
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: "Two fixes for RISC-V: - Clear FP registers during boot when FP support is present, rather than when they aren't present - Move the header files associated with the SiFive L2 cache controller to drivers/soc (where the code was recently moved)" * tag 'riscv/for-v5.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Fixup obvious bug for fp-regs reset riscv: move sifive_l2_cache.h to include/soc
| | * riscv: Fixup obvious bug for fp-regs resetGuo Ren2020-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CSR_MISA is defined in Privileged Architectures' spec: 3.1.1 Machine ISA Register misa. Every bit:1 indicate a feature, so we should beqz reset_done when there is no F/D bit in csr_misa register. Signed-off-by: Guo Ren <ren_guo@c-sky.com> [paul.walmsley@sifive.com: fix typo in commit message] Fixes: 9e80635619b51 ("riscv: clear the instruction cache and all registers when booting") Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
| | * riscv: move sifive_l2_cache.h to include/socYash Shah2020-01-123-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit 9209fb51896f ("riscv: move sifive_l2_cache.c to drivers/soc") moves the sifive L2 cache driver to driver/soc. It did not move the header file along with the driver. Therefore this patch moves the header file to driver/soc Signed-off-by: Yash Shah <yash.shah@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> [paul.walmsley@sifive.com: updated to fix the include guard] Fixes: 9209fb51896f ("riscv: move sifive_l2_cache.c to drivers/soc") Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
| * | Merge tag 'iommu-fixes-v5.5-rc5' of ↵Linus Torvalds2020-01-123-7/+19
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: - Two fixes for VT-d and generic IOMMU code to fix teardown on error handling code paths. - Patch for the Intel VT-d driver to fix handling of non-PCI devices - Fix W=1 compile warning in dma-iommu code * tag 'iommu-fixes-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/dma: fix variable 'cookie' set but not used iommu/vt-d: Unlink device if failed to add to group iommu: Remove device link to group on failure iommu/vt-d: Fix adding non-PCI devices to Intel IOMMU
| | * | iommu/dma: fix variable 'cookie' set but not usedQian Cai2020-01-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit c18647900ec8 ("iommu/dma: Relax locking in iommu_dma_prepare_msi()") introduced a compliation warning, drivers/iommu/dma-iommu.c: In function 'iommu_dma_prepare_msi': drivers/iommu/dma-iommu.c:1206:27: warning: variable 'cookie' set but not used [-Wunused-but-set-variable] struct iommu_dma_cookie *cookie; ^~~~~~ Fixes: c18647900ec8 ("iommu/dma: Relax locking in iommu_dma_prepare_msi()") Signed-off-by: Qian Cai <cai@lca.pw> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| | * | iommu/vt-d: Unlink device if failed to add to groupJon Derrick2020-01-071-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the device fails to be added to the group, make sure to unlink the reference before returning. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Fixes: 39ab9555c2411 ("iommu: Add sysfs bindings for struct iommu_device") Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| | * | iommu: Remove device link to group on failureJon Derrick2020-01-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the missing teardown step that removes the device link from the group when the device addition fails. Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Fixes: 797a8b4d768c5 ("iommu: Handle default domain attach failure") Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| | * | iommu/vt-d: Fix adding non-PCI devices to Intel IOMMUPatrick Steinhardt2020-01-071-1/+8
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting with commit fa212a97f3a3 ("iommu/vt-d: Probe DMA-capable ACPI name space devices"), we now probe DMA-capable ACPI name space devices. On Dell XPS 13 9343, which has an Intel LPSS platform device INTL9C60 enumerated via ACPI, this change leads to the following warning: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1 at pci_device_group+0x11a/0x130 CPU: 1 PID: 1 Comm: swapper/0 Tainted: G T 5.5.0-rc3+ #22 Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A20 06/06/2019 RIP: 0010:pci_device_group+0x11a/0x130 Code: f0 ff ff 48 85 c0 49 89 c4 75 c4 48 8d 74 24 10 48 89 ef e8 48 ef ff ff 48 85 c0 49 89 c4 75 af e8 db f7 ff ff 49 89 c4 eb a5 <0f> 0b 49 c7 c4 ea ff ff ff eb 9a e8 96 1e c7 ff 66 0f 1f 44 00 00 RSP: 0000:ffffc0d6c0043cb0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffffa3d1d43dd810 RCX: 0000000000000000 RDX: ffffa3d1d4fecf80 RSI: ffffa3d12943dcc0 RDI: ffffa3d1d43dd810 RBP: ffffa3d1d43dd810 R08: 0000000000000000 R09: ffffa3d1d4c04a80 R10: ffffa3d1d4c00880 R11: ffffa3d1d44ba000 R12: 0000000000000000 R13: ffffa3d1d4383b80 R14: ffffa3d1d4c090d0 R15: ffffa3d1d4324530 FS: 0000000000000000(0000) GS:ffffa3d1d6700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000000460a001 CR4: 00000000003606e0 Call Trace: ? iommu_group_get_for_dev+0x81/0x1f0 ? intel_iommu_add_device+0x61/0x170 ? iommu_probe_device+0x43/0xd0 ? intel_iommu_init+0x1fa2/0x2235 ? pci_iommu_init+0x52/0xe7 ? e820__memblock_setup+0x15c/0x15c ? do_one_initcall+0xcc/0x27e ? kernel_init_freeable+0x169/0x259 ? rest_init+0x95/0x95 ? kernel_init+0x5/0xeb ? ret_from_fork+0x35/0x40 ---[ end trace 28473e7abc25b92c ]--- DMAR: ACPI name space devices didn't probe correctly The bug results from the fact that while we now enumerate ACPI devices, we aren't able to handle any non-PCI device when generating the device group. Fix the issue by implementing an Intel-specific callback that returns `pci_device_group` only if the device is a PCI device. Otherwise, it will return a generic device group. Fixes: fa212a97f3a3 ("iommu/vt-d: Probe DMA-capable ACPI name space devices") Signed-off-by: Patrick Steinhardt <ps@pks.im> Cc: stable@vger.kernel.org # v5.3+ Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * | Merge branch 'i2c/for-current' of ↵Linus Torvalds2020-01-114-15/+23
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Two driver bugfixes, a documentation fix, and a removal of a spec violation for the bus recovery algorithm in the core" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: fix bus recovery stop mode timing i2c: bcm2835: Store pointer to bus clock dt-bindings: i2c: at91: fix i2c-sda-hold-time-ns documentation for sam9x60 i2c: at91: fix clk_offset for sam9x60
| | * | i2c: fix bus recovery stop mode timingRussell King2020-01-091-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The I2C specification states that tsu:sto for standard mode timing must be at minimum 4us. Pictographically, this is: SCL: ____/~~~~~~~~~ SDA: _________/~~~~ ->| |<- 4us minimum We are currently waiting 2.5us between asserting SCL and SDA, which is in violation of the standard. Adjust the timings to ensure that we meet what is stipulated as the minimum timings to ensure that all devices correctly interpret the STOP bus transition. This is more important than trying to generate a square wave with even duty cycle. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| | * | i2c: bcm2835: Store pointer to bus clockStefan Wahren2020-01-061-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit bebff81fb8b9 ("i2c: bcm2835: Model Divider in CCF") introduced a NULL pointer dereference on driver unload. It seems that we can't fetch the bus clock via devm_clk_get in bcm2835_i2c_remove. As an alternative approach store a pointer to the bus clock in the private driver structure. Fixes: bebff81fb8b9 ("i2c: bcm2835: Model Divider in CCF") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| | * | dt-bindings: i2c: at91: fix i2c-sda-hold-time-ns documentation for sam9x60Eugen Hristev2020-01-061-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SAM9X60 also supports i2c-sda-hold-time-ns. Fix the documentation accordingly. Fixes: 2034e3f4c9a5 ("dt-bindings: i2c: at91: add new compatible") Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| | * | i2c: at91: fix clk_offset for sam9x60Eugen Hristev2020-01-061-1/+1
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In SAM9X60 datasheet, FLEX_TWI_CWGR register description mentions clock offset of 3 cycles (compared to 4 in eg. SAMA5D3). This is the same offset as in SAMA5D2. Fixes: b00277923743 ("i2c: at91: add new platform support for sam9x60") Suggested-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Reviewed-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | Merge tag 'clone3-tls-v5.5-rc6' of ↵Linus Torvalds2020-01-1118-32/+45
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux Pull thread fixes from Christian Brauner: "This contains a series of patches to fix CLONE_SETTLS when used with clone3(). The clone3() syscall passes the tls argument through struct clone_args instead of a register. This means, all architectures that do not implement copy_thread_tls() but still support CLONE_SETTLS via copy_thread() expecting the tls to be located in a register argument based on clone() are currently unfortunately broken. Their tls value will be garbage. The patch series fixes this on all architectures that currently define __ARCH_WANT_SYS_CLONE3. It also adds a compile-time check to ensure that any architecture that enables clone3() in the future is forced to also implement copy_thread_tls(). My ultimate goal is to get rid of the copy_thread()/copy_thread_tls() split and just have copy_thread_tls() at some point in the not too distant future (Maybe even renaming copy_thread_tls() back to simply copy_thread() once the old function is ripped from all arches). This is dependent now on all arches supporting clone3(). While all relevant arches do that now there are still four missing: ia64, m68k, sh and sparc. They have the system call reserved, but not implemented. Once they all implement clone3() we can get rid of ARCH_WANT_SYS_CLONE3 and HAVE_COPY_THREAD_TLS. This series also includes a minor fix for the arm64 uapi headers which caused __NR_clone3 to be missing from the exported user headers. Unfortunately the series came in a little late especially given that it touches a range of architectures. Due to the holidays not all arch maintainers responded in time probably due to their backlog. Will and Arnd have thankfully acked the arm specific changes. Given that the changes are straightforward and rather minimal combined with the fact the that clone3() with CLONE_SETTLS is broken I decided to send them post rc3 nonetheless" * tag 'clone3-tls-v5.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux: um: Implement copy_thread_tls clone3: ensure copy_thread_tls is implemented xtensa: Implement copy_thread_tls riscv: Implement copy_thread_tls parisc: Implement copy_thread_tls arm: Implement copy_thread_tls arm64: Implement copy_thread_tls arm64: Move __ARCH_WANT_SYS_CLONE3 definition to uapi headers
| | * | um: Implement copy_thread_tlsAmanieu d'Antras2020-01-075-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: linux-um@lists.infradead.org Cc: <stable@vger.kernel.org> # 5.3.x Link: https://lore.kernel.org/r/20200104123928.1048822-1-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
| | * | clone3: ensure copy_thread_tls is implementedAmanieu d'Antras2020-01-071-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | copy_thread implementations handle CLONE_SETTLS by reading the TLS value from the registers containing the syscall arguments for clone. This doesn't work with clone3 since the TLS value is passed in clone_args instead. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: <stable@vger.kernel.org> # 5.3.x Link: https://lore.kernel.org/r/20200102172413.654385-8-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
| | * | xtensa: Implement copy_thread_tlsAmanieu d'Antras2020-01-072-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: linux-xtensa@linux-xtensa.org Cc: <stable@vger.kernel.org> # 5.3.x Link: https://lore.kernel.org/r/20200102172413.654385-7-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
| | * | riscv: Implement copy_thread_tlsAmanieu d'Antras2020-01-072-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: linux-riscv@lists.infradead.org Cc: <stable@vger.kernel.org> # 5.3.x Link: https://lore.kernel.org/r/20200102172413.654385-6-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
| | * | parisc: Implement copy_thread_tlsAmanieu d'Antras2020-01-072-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: linux-parisc@vger.kernel.org Cc: <stable@vger.kernel.org> # 5.3.x Link: https://lore.kernel.org/r/20200102172413.654385-5-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
| | * | arm: Implement copy_thread_tlsAmanieu d'Antras2020-01-072-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: <stable@vger.kernel.org> # 5.3.x Link: https://lore.kernel.org/r/20200102172413.654385-4-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
| | * | arm64: Implement copy_thread_tlsAmanieu d'Antras2020-01-072-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: <stable@vger.kernel.org> # 5.3.x Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200102172413.654385-3-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
| | * | arm64: Move __ARCH_WANT_SYS_CLONE3 definition to uapi headersAmanieu d'Antras2020-01-072-1/+1
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously this was only defined in the internal headers which resulted in __NR_clone3 not being defined in the user headers. Signed-off-by: Amanieu d'Antras <amanieu@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: <stable@vger.kernel.org> # 5.3.x Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200102172413.654385-2-amanieu@gmail.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
| * | Merge branch 'for-linus' of ↵Linus Torvalds2020-01-102-5/+7
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fix from Jiri Kosina: "A regression fix for EPOLLOUT handling in hidraw and uhid" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: hidraw, uhid: Always report EPOLLOUT
| | * | HID: hidraw, uhid: Always report EPOLLOUTJiri Kosina2020-01-102-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hidraw and uhid device nodes are always available for writing so we should always report EPOLLOUT and EPOLLWRNORM bits, not only in the cases when there is nothing to read. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Fixes: be54e7461ffdc ("HID: uhid: Fix returning EPOLLOUT from uhid_char_poll") Fixes: 9f3b61dc1dd7b ("HID: hidraw: Fix returning EPOLLOUT from hidraw_poll") Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * | | Merge tag 'usb-5.5-rc6' of ↵Linus Torvalds2020-01-1019-93/+243
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB/PHY fixes from Greg KH: "Here are a number of USB and PHY driver fixes for 5.5-rc6 Nothing all that unusual, just the a bunch of small fixes for a lot of different reported issues. The PHY driver fixes are in here as they interacted with the usb drivers. Full details of the patches are in the shortlog, and all of these have been in linux-next with no reported issues" * tag 'usb-5.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (24 commits) usb: missing parentheses in USE_NEW_SCHEME usb: ohci-da8xx: ensure error return on variable error is set usb: musb: Disable pullup at init usb: musb: fix idling for suspend after disconnect interrupt usb: typec: ucsi: Fix the notification bit offsets USB: Fix: Don't skip endpoint descriptors with maxpacket=0 USB-PD tcpm: bad warning+size, PPS adapters phy/rockchip: inno-hdmi: round clock rate down to closest 1000 Hz usb: chipidea: host: Disable port power only if previously enabled usb: cdns3: should not use the same dev_id for shared interrupt handler usb: dwc3: gadget: Fix request complete check usb: musb: dma: Correct parameter passed to IRQ handler usb: musb: jz4740: Silence error if code is -EPROBE_DEFER usb: udc: tegra: select USB_ROLE_SWITCH USB: core: fix check for duplicate endpoints phy: cpcap-usb: Drop extra write to usb2 register phy: cpcap-usb: Improve host vs docked mode detection phy: cpcap-usb: Prevent USB line glitches from waking up modem phy: mapphone-mdm6600: Fix uninitialized status value regression phy: cpcap-usb: Fix flakey host idling and enumerating of devices ...
| | * | | usb: missing parentheses in USE_NEW_SCHEMEQi Zhou2020-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | usb: ohci-da8xx: ensure error return on variable error is setColin Ian King2020-01-081-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when an error occurs when calling devm_gpiod_get_optional or calling gpiod_to_irq it causes an uninitialized error return in variable 'error' to be returned. Fix this by ensuring the error variable is set from da8xx_ohci->oc_gpio and oc_irq. Thanks to Dan Carpenter for spotting the uninitialized error in the gpiod_to_irq failure case. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: d193abf1c913 ("usb: ohci-da8xx: add vbus and overcurrent gpios") Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: stable <stable@vger.kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200107123901.101190-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | usb: musb: Disable pullup at initPaul Cercueil2020-01-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pullup may be already enabled before the driver is initialized. This happens for instance on JZ4740. It has to be disabled at init time, as we cannot guarantee that a gadget driver will be bound to the UDC. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Suggested-by: Bin Liu <b-liu@ti.com> Cc: stable@vger.kernel.org Signed-off-by: Bin Liu <b-liu@ti.com> Link: https://lore.kernel.org/r/20200107152625.857-3-b-liu@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | usb: musb: fix idling for suspend after disconnect interruptTony Lindgren2020-01-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When disconnected as USB B-device, suspend interrupt should come before diconnect interrupt, because the DP/DM pins are shorter than the VBUS/GND pins on the USB connectors. But we sometimes get a suspend interrupt after disconnect interrupt. In that case we have devctl set to 99 with VBUS still valid and musb_pm_runtime_check_session() wrongly thinks we have an active session. We have no other interrupts after disconnect coming in this case at least with the omap2430 glue. Let's fix the issue by checking the interrupt status again with delayed work for the devctl 99 case. In the suspend after disconnect case the devctl session bit has cleared by then and musb can idle. For a typical USB B-device connect case we just continue with normal interrupts. Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime PM for musb-core") Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Bin Liu <b-liu@ti.com> Link: https://lore.kernel.org/r/20200107152625.857-2-b-liu@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | usb: typec: ucsi: Fix the notification bit offsetsHeikki Krogerus2020-01-081-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bit offsets for the Set Notification Enable command were not considering the reserved bits in the middle. Fixes: 470ce43a1a81 ("usb: typec: ucsi: Remove struct ucsi_control") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200108131347.43217-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | USB: Fix: Don't skip endpoint descriptors with maxpacket=0Alan Stern2020-01-061-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | | USB-PD tcpm: bad warning+size, PPS adaptersDouglas Gilbert2020-01-021-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Augmented Power Delivery Objects (A)PDO_s are used by USB-C PD power adapters to advertize the voltages and currents they support. There can be up to 7 PDO_s but before PPS (programmable power supply) there were seldom more than 4 or 5. Recently Samsung released an optional PPS 45 Watt power adapter (EP-TA485) that has 7 PDO_s. It is for the Galaxy 10+ tablet and charges it quicker than the adapter supplied at purchase. The EP-TA485 causes an overzealous WARN_ON to soil the log plus it miscalculates the number of bytes to read. So this bug has been there for some time but goes undetected for the majority of USB-C PD power adapters on the market today that have 6 or less PDO_s. That may soon change as more USB-C PD adapters with PPS come to market. Tested on a EP-TA485 and an older Lenovo PN: SA10M13950 USB-C 65 Watt adapter (without PPS and has 4 PDO_s) plus several other PD power adapters. Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191230033544.1809-1-dgilbert@interlog.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| | * | | Merge tag 'usb-serial-5.5-rc5' of ↵Greg Kroah-Hartman2020-01-023-0/+15
| | |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.5-rc5 Here's a couple of new modem device ids, including a new quirk for devices that expect zero-length packets. Due to the holidays, only the first one has been in linux-next and with no reported issues. Signed-off-by: Johan Hovold <johan@kernel.org> * tag 'usb-serial-5.5-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add ZLP support for 0x1bc7/0x9010 USB: serial: option: add Telit ME910G1 0x110a composition
| | | * | | USB: serial: option: add ZLP support for 0x1bc7/0x9010Daniele Palmas2019-12-203-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Telit FN980 flashing device 0x1bc7/0x9010 requires zero packet to be sent if out data size is is equal to the endpoint max size. Signed-off-by: Daniele Palmas <dnlplm@gmail.com> [ johan: switch operands in conditional ] Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
| | | * | | USB: serial: option: add Telit ME910G1 0x110a compositionDaniele Palmas2019-12-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the following Telit ME910G1 composition: 0x110a: tty, tty, tty, rmnet Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
| | * | | | Merge tag 'phy-for-5.5-rc' of ↵Greg Kroah-Hartman2020-01-024-47/+98
| | |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus Kishon writes: phy: for 5.5-rc *) Fix error path in cpcap-usb driver when no host driver is loaded to avoid debug serial console from stop working *) Fix to let USB host idle before switching to UART mode in cpcap-usb driver in order to avoid flakey enumeration next time *) Prevent USB line glitches from waking up modem by enabling the USB lines (GPIO mux) after configuring the cpcap-usb PHY *) Improve host vs docked mode detection in cpcap-usb PHY driver to keep VBUS enabled in host mode *) Fix to prevent cpcap-usb PHY driver from enabling the PHY twice *) Increase PHY ready timeout in qcom-qmp PHY as it takes more than 1ms to initialize *) Round clock rate down to closest 1000 Hz in phy-rockchip-inno-hdmi to prevent wrong pixel clock to be used and result in no-signal when configuring a mode on RK3328 * tag 'phy-for-5.5-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy: phy/rockchip: inno-hdmi: round clock rate down to closest 1000 Hz phy: cpcap-usb: Drop extra write to usb2 register phy: cpcap-usb: Improve host vs docked mode detection phy: cpcap-usb: Prevent USB line glitches from waking up modem phy: mapphone-mdm6600: Fix uninitialized status value regression phy: cpcap-usb: Fix flakey host idling and enumerating of devices phy: qcom-qmp: Increase PHY ready timeout phy: cpcap-usb: Fix error path when no host driver is loaded
| | | * | | | phy/rockchip: inno-hdmi: round clock rate down to closest 1000 HzJonas Karlman2019-12-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock framework") changed what rate clk_round_rate() is called with, an additional 999 Hz added to the requsted mode clock. This has caused a regression on RK3328 and presumably also on RK3228 because the inno-hdmi-phy clock requires an exact match of the requested rate in the pre pll config table. When an exact match is not found the parent clock rate (24MHz) is returned to the clk_round_rate() caller. This cause wrong pixel clock to be used and result in no-signal when configuring a mode on RK3328. Fix this by rounding the rate down to closest 1000 Hz in round_rate func, this allows an exact match to be found in pre pll config table. Fixes: 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock framework") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | | * | | | phy: cpcap-usb: Drop extra write to usb2 registerTony Lindgren2019-12-261-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are currently writing the same register twice. Let's enable the USB PHY only at the end of the function. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | | * | | | phy: cpcap-usb: Improve host vs docked mode detectionTony Lindgren2019-12-261-15/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When docked to a Motorola lapdock or media dock, we're in USB A-host mode with VBUS provided by the dock. When in regular USB A-host mode, we're providing the VBUS. And in regular USB A-host mode we must also keep kicking the VBUS to keep it active. Let's wait a bit before configuring the USB PHY to allow some time between the ID and VBUS changes. And let's add vbus_provider flag so we can detect docked mode and regularo USB A-host mode better. With better USB A-host mode detection, we can now also just kick the VBUS to keep it enabled and leave out the unnecessary line muxing. We only need to set and clear vbus_provider in the delayed work so no locking is needed for it currently. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | | * | | | phy: cpcap-usb: Prevent USB line glitches from waking up modemTony Lindgren2019-12-261-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The micro-USB connector on Motorola Mapphone devices can be muxed between the SoC and the mdm6600 modem. But even when used for the SoC, configuring the PHY with ID pin grounded will wake up the modem from idle state. Looks like the issue is probably caused by line glitches. We can prevent the glitches by using a previously unknown mode of the GPIO mux to prevent the USB lines from being connected to the moden while configuring the USB PHY, and enable the USB lines after configuring the PHY. Note that this only prevents waking up mdm6600 as regular USB A-host mode, and does not help when connected to a lapdock. The lapdock specific issue still needs to be debugged separately. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | | * | | | phy: mapphone-mdm6600: Fix uninitialized status value regressionTony Lindgren2019-12-261-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only the used bits get cleared with bitmap_zero() when we call gpiod_get_array_value_cansleep(). We must mask only the bits we're using for ddata->status as the other bits in the bitmap may not be initialized. And let's also drop useless debug code accidentally left over while at it. Fixes: b9762bebc633 ("gpiolib: Pass bitmaps, not integer arrays, to get/set array") Cc: Jacopo Mondi <jacopo@jmondi.org> Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Scott <hashcode0f@gmail.com> Cc: NeKit <nekit1000@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | | * | | | phy: cpcap-usb: Fix flakey host idling and enumerating of devicesTony Lindgren2019-12-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We must let the USB host idle things properly before we switch to debug UART mode. Otherwise the USB host may never idle after disconnecting devices, and that causes the next enumeration to be flakey. Cc: Jacopo Mondi <jacopo@jmondi.org> Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Scott <hashcode0f@gmail.com> Cc: NeKit <nekit1000@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Fixes: 6d6ce40f63af ("phy: cpcap-usb: Add CPCAP PMIC USB support") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | | * | | | phy: qcom-qmp: Increase PHY ready timeoutBjorn Andersson2019-12-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's typical for the QHP PHY to take slightly above 1ms to initialize, so increase the timeout of the PHY ready check to 10ms - as already done in the downstream PCIe driver. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Evan Green <evgreen@chromium.org> Tested-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
| | | * | | | phy: cpcap-usb: Fix error path when no host driver is loadedTony Lindgren2019-12-201-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If musb_mailbox() returns an error, we must still continue to finish configuring the phy. Otherwise the phy state may end up only half initialized, and this can cause the debug serial console to stop working. And this will happen if the usb driver musb controller is not loaded. Let's fix the issue by adding helper for cpcap_usb_try_musb_mailbox(). Fixes: 6d6ce40f63af ("phy: cpcap-usb: Add CPCAP PMIC USB support") Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>