Re: [RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

On 24-04-18, 22:32, Krzysztof Kozlowski wrote: > The Exynos5440 is not actively developed, there are no development > boards available and probably there are no real products with it. > Remove wide-tree support for Exynos5440. > > Signed-off-by: Krzysztof Kozlowski > --- >

RE: [PATCH resend] usb: chipidea: Don't select EXTCON

> > > > > > The patch doesn't remove extcon support from chipidea driver. > > > I just want to not select EXTCON unconditionally, but let the users > > > choose. If the users need extcon, they could enable EXTCON > > > themselves > > > > > > I just searched all the dts in arch/arm/boot/dts and >

Re: [PATCH v8 0/6] typec: tcpm: Add sink side support for PPS

Hi Greg, On Tue, Apr 24, 2018 at 03:57:49PM +0200, Greg Kroah-Hartman wrote: > On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote: > > This patch set adds sink side support for the PPS feature introduced in the > > USB PD 3.0 specification. > > > > The source PPS supply is represented

[PATCH 4/4] usb: gadget: f_fs: Add FUNCTIONFS_CONTROL_ONLY flag

This flag allows users to directly specify when they want a ffs instance to be used for handling control requests only via the configfs control_config/ group. When the flag is set, user must set *none* of the speed descriptor flags and provide no speeds in the descriptor. This ensures that it

[PATCH V2 3/4] Documentation: usb: Add docs for configfs control requests

Signed-off-by: Jerry Zhang --- Changes in V2: - Updated doc with the FUNCTIONFS_CONTROL_ONLY flag Documentation/usb/gadget_configfs.txt | 34 +++ 1 file changed, 34 insertions(+) diff --git a/Documentation/usb/gadget_configfs.txt

[PATCH V2 2/4] usb: gadget: configfs: Create control_config group

Control_config is a group under gadget that acts as a normal config group, except it does not appear in cdev->configs. Functions that have exactly zero descriptors can be linked into control_config. These functions are bound and unbound with the rest of the gadget, but are never enabled. Also,

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:56 PM, Krzysztof Kozlowski wrote: > On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote: >> On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski >> wrote: > The only dependency is through Kconfig symbol (SOC_EXYNOS5440).

[PATCH v2 3/3] usb: gadget: uvc: disable stream when disconnected

Down the call stack from the ioctl handler for VIDIOC_STREAMON, uvc_video_alloc_requests contains a BUG_ON, which in the high level, triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF being issued previously. This can also be triggered by starting the stream and then

[PATCH v2 1/3] usb: gadget: uvc: synchronize streamon/off with uvc_function_set_alt

Down the call stack from the ioctl handler for VIDIOC_STREAMON, uvc_video_alloc_requests contains a BUG_ON, which in the high level, triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF being issued previously. This could be triggered by uvc_function_set_alt 0 racing and winning

[PATCH v2 2/3] usb: gadget: uvc: remove delay usb status phase

The completion of the usb status phase doesn't need to be delayed from uvc_function_set_alt to uvc_v4l2_streamon/off. Remove USB_GADGET_DELAYED_STATUS and usb_composite_setup_delay from these two, respectively. Signed-off-by: Paul Elder --- Changes in v2: 1.

[PATCH v2 0/3] usb: gadget: uvc: fix racing between uvc_function_set_alt and streamon/off

Down the call stack from the ioctl handler for VIDIOC_STREAMON, uvc_video_alloc_requests contains a BUG_ON, which in the high level, triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF being issued previously. This can happen in a few ways, such as if the userspace uvc gadget

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote: > On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski wrote: > > Hi, > > > > > > Overview > > > > Let's continue the removal of old platforms. We already get rid of > > Exynos4212. > > Now it's time for

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski wrote: > Hi, > > > Overview > > Let's continue the removal of old platforms. We already get rid of Exynos4212. > Now it's time for Exynos5440. > > The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting >

[RFC 04/10] clk: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/clock/exynos5440-clock.txt | 28

[RFC 03/10] cpufreq: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../bindings/cpufreq/cpufreq-exynos5440.txt| 28 --

[RFC 06/10] thermal: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/thermal/exynos-thermal.txt | 14 +-

[RFC 02/10] ata: ahci-platform: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 -

[RFC 07/10] pinctrl: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/pinctrl/samsung/Kconfig | 10 +-

[RFC 10/10] ARM: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- arch/arm/mach-exynos/Kconfig | 12

[RFC 09/10] usb: host: exynos: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/usb/host/ehci-exynos.c | 7 ---

[RFC 08/10] spi: s3c64xx: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- drivers/spi/spi-s3c64xx.c | 12 1 file changed, 12

[RFC 05/10] i2c: s3c2410: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development boards available and probably there are no real products with it. Remove wide-tree support for Exynos5440. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt | 4 +---

[RFC 01/10] ARM: dts: exynos: Remove Exynos5440

The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting server platforms but it did not make it to the market really. There are no development boards with it and probably there are no real products neither. The development for Exynos5440 ended in 2013 and since then the platform is in

[RFC 00/10] ARM: Remove support for Exynos5440

Hi, Overview Let's continue the removal of old platforms. We already get rid of Exynos4212. Now it's time for Exynos5440. The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting server platforms but it did not make it to the market really. There are no development boards

Re: Request for information how to disable USB bulk endpoint transfer validation

Hello, On 04/23/2018 11:50 PM, Alan Stern wrote: In ZWO forums there was a suggestion to revert USB packet validation by applying a "break" to Linux kernel. With some changes to line locations I have applied the patch below and camera started to work on a desktop with USB 2.0 host. The

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

On Mon, Apr 23, 2018 at 11:21:32PM -0500, Dan Williams wrote: > On Tue, 2018-04-24 at 09:55 +0700, Lars Melin wrote: > > On 4/23/2018 23:54, Dan Williams wrote: > > > > > > MI_00 D-Link Mobile Broadband Device (cdc_ether) > > > > MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp m > > >

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

On Mon, Apr 23, 2018 at 11:54:32AM -0500, Dan Williams wrote: > On Mon, 2018-04-23 at 14:14 +0700, Lars Melin wrote: > > Blacklisting interface 4 and 5 is correct because: > > > > MI_00 D-Link Mobile Broadband Device (cdc_ether) > > MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds wrote: > On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote: >> >> $ objdump -S clang-eflag.o >> >> Does this now look good? > > Looks fine to me. The instruction choice is still pretty odd: > >

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote: > > $ objdump -S clang-eflag.o > > Does this now look good? Looks fine to me. The instruction choice is still pretty odd: 1a: f6 c3 fftest $0xff,%bl 1d: 74 02 je 21

Re: [PATCH/RFC 02/11] dt-bindings: usb: add usb role switch driver

On Wed, Apr 18, 2018 at 05:09:56PM +0900, Yoshihiro Shimoda wrote: > This patch adds a new documentation for a usb role switch driver. > The usb role switch framework will parse this to get each device > pointer by using each remote-endpoint. Bindings describe h/w, not drivers. This doesn't look

Re: [PATCH/RFC 01/11] Documentation: of: Add device-connection-id property

On Wed, Apr 18, 2018 at 05:09:55PM +0900, Yoshihiro Shimoda wrote: > This patch adds a new property for device connection framework. What's the "device connection framework" and what does it have to do with DT? > > Signed-off-by: Yoshihiro Shimoda > --- >

Re: [PATCH v2] doc: usb: ci-hdrc-usb2: Add property "mux-controls"

On Tue, Apr 17, 2018 at 04:53:25PM +0300, Yossi Mansharoff wrote: > The chipidea usb controller may be connected, in some platforms, > to an external mux to toggle between different usb ports for > different roles (host and device). > > The mux-controller property, if set, binds the chipidea usb

Re: [PATCH v8 0/6] typec: tcpm: Add sink side support for PPS

On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote: > This patch set adds sink side support for the PPS feature introduced in the > USB PD 3.0 specification. > > The source PPS supply is represented using the Power Supply framework to > provide > access and control APIs for dealing

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

On Tue, 24 Apr 2018, Mathias Nyman wrote: > >>> In this situation, the HCD_WAKEUP_PENDING(hcd) test in > >>> hcd-pci.c:suspend_common() should prevent the controller from going > >>> back into D3. The WAKEUP_PENDING bit gets set in > >>> usb_hcd_resume_root_hub() and it doesn't get cleared until

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 3:28 PM, Sedat Dilek wrote: > On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds > wrote: >> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote: >>> >>> $ objdump -S clang-eflag.o >>> >>>

Re: [PATCH 1/2] usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

On Tue, Apr 24, 2018 at 06:02:56AM -0700, Guenter Roeck wrote: > The chip should return the number of bytes it has available and then NAK > the transfer. The chip driver should then report the number of bytes read > to its caller. This is why i2c_smbus_read_block_data() and friends return > not

[PATCH] usbnet: ipheth: fix ipheth_tx()'s return type

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, but the implementation in this driver returns an 'int'. Fix this by returning 'netdev_tx_t' in this driver too. Signed-off-by: Luc Van Oostenryck ---

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

On 24.04.2018 16:24, Alan Stern wrote: On Tue, 24 Apr 2018, Mathias Nyman wrote: On 23.04.2018 18:11, Alan Stern wrote: On Mon, 23 Apr 2018, Mathias Nyman wrote: On 22.04.2018 09:29, russianneuroman...@ya.ru wrote: Hello! So far I tested attached patch but didn't tried to revert commit

Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds wrote: > On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote: >> >> $ objdump -S clang-eflag.o >> >> clang-eflag.o: file format elf64-x86-64 >> >> >> Disassembly of section .text: >> >>

[PATCH] usb: gadget: f_phonet: fix pn_net_xmit()'s return type

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, but the implementation in this driver returns an 'int'. Fix this by returning 'netdev_tx_t' in this driver too. Signed-off-by: Luc Van Oostenryck ---

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

On Tue, 24 Apr 2018, Mathias Nyman wrote: > On 23.04.2018 18:11, Alan Stern wrote: > > On Mon, 23 Apr 2018, Mathias Nyman wrote: > > > >> On 22.04.2018 09:29, russianneuroman...@ya.ru wrote: > >>> Hello! > >>> > >>> So far I tested attached patch but didn't tried to revert commit yet, > >>> will

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

On 23.04.2018 18:11, Alan Stern wrote: On Mon, 23 Apr 2018, Mathias Nyman wrote: On 22.04.2018 09:29, russianneuroman...@ya.ru wrote: Hello! So far I tested attached patch but didn't tried to revert commit yet, will do next week. Result of running patched kernel with recommended debug

Re: [PATCH 1/2] usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

On 04/24/2018 04:46 AM, Heikki Krogerus wrote: On Mon, Apr 23, 2018 at 09:43:57AM -0700, Guenter Roeck wrote: On Mon, Apr 23, 2018 at 11:03:09AM +0300, Heikki Krogerus wrote: On Fri, Apr 20, 2018 at 10:26:08AM -0700, Guenter Roeck wrote: On Wed, Apr 18, 2018 at 03:34:09PM +0300, Heikki

Re: [PATCH v8 5/6] typec: tcpm: Represent source supply through power_supply

On Mon, Apr 23, 2018 at 03:11:00PM +0100, Adam Thomson wrote: > This commit adds a power_supply class instance to represent a > PD source's voltage and current properties. This provides an > interface for reading these properties from user-space or other > drivers. > > For PPS enabled Sources,

Re: [PATCH v8 4/6] power: supply: Add 'usb_type' property and supporting code

On Mon, Apr 23, 2018 at 03:10:59PM +0100, Adam Thomson wrote: > This commit adds the 'usb_type' property to represent USB supplies > which can report a number of different types based on a connection > event. > > Examples of this already exist in drivers whereby the existing 'type' > property is

Re: [PATCH v8 3/6] power: supply: Add error checking of psy desc during registration

On Mon, Apr 23, 2018 at 03:10:58PM +0100, Adam Thomson wrote: > Currently there's no error checking of this parameter in the > registration function and it's blindly added to psy class and > subsequently used as is. For example if this is NULL the call > to psy_register_thermal() will try to

Re: [PATCH v8 2/6] Documentation: power: Initial effort to document power_supply ABI

On Mon, Apr 23, 2018 at 03:10:57PM +0100, Adam Thomson wrote: > This commit adds generic ABI information regarding power_supply > properties. This is an initial attempt to try and align the usage > of these properties between drivers. As part of this commit, > common Battery and USB related

Re: [PATCH/RFC 04/11] of: platform: add device connection parsing

Hi Yoshihiro, On Wed, Apr 18, 2018 at 05:09:58PM +0900, Yoshihiro Shimoda wrote: > This patch adds device connection parsing in of_platform_populate(). > > TODO: > - How to free the devcon memories? > - How to remove the devcon instances? > > Signed-off-by: Yoshihiro Shimoda

Re: [PATCH 0/3] musb fixes backport to v4.9+

On Mon, Apr 23, 2018 at 12:41:12PM -0500, Bin Liu wrote: > Hi, > > Here are several patches backported to v4.9+ to fix runtime PM problems in > musb > drivers. All now applied, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to

Re: [PATCH 1/2] usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

On Mon, Apr 23, 2018 at 09:43:57AM -0700, Guenter Roeck wrote: > On Mon, Apr 23, 2018 at 11:03:09AM +0300, Heikki Krogerus wrote: > > On Fri, Apr 20, 2018 at 10:26:08AM -0700, Guenter Roeck wrote: > > > On Wed, Apr 18, 2018 at 03:34:09PM +0300, Heikki Krogerus wrote: > > > > If the I2C adapter

Re: USB regression for Android phone and sound card in 4.14

My expectation is that kernel will figure out what to load first on its own. What HCD stands for in your message? USB hub is connected to native USB 2.0 port on motherboard with Z370 chipset. Sincerely, Nazar Mokrynskyi github.com/nazar-pc 24.04.18 11:04, Oliver Neukum пише: > Am Dienstag, den

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Am Montag, den 23.04.2018, 18:35 +0530 schrieb Tushar Nimkar: > hi, > > On 2018-04-23 18:20, Oliver Neukum wrote: > > Am Donnerstag, den 19.04.2018, 20:18 +0530 schrieb Tushar Nimkar: > > No. But for testing we don't need to. Can you confirm that > > the problem is triggered by specific

Re: [PATCH 2/2] usb: dwc2: fix isoc split in transfer with no data

Dear Sergei, 在 2018年04月24日 16:27, Sergei Shtylyov 写道: Hello! On 4/24/2018 5:43 AM, William Wu wrote: If isoc split in transfer with no data (the length of DATA0 packet is 0), we can't simply return immediately. Because the DATA0 can be the first transaction or the second transaction for the

Re: [PATCH v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

Hi Tomeu, Am Montag, 23. April 2018, 15:24:04 CEST schrieb Tomeu Vizoso: > Hi, > > could this patch be picked up, please? Or if for some reason it cannot > be, could the commit that introduced the regression be reverted? > > It's causing some tests in KernelCI to fail: > >

Re: [PATCH] usb: always build usb/common/ targets; fixes extcon-axp288 build error

Hi, On 24-04-18 09:42, Chanwoo Choi wrote: On 2018년 04월 17일 18:01, Hans de Goede wrote: Hi, On 17-04-18 07:14, Randy Dunlap wrote: From: Randy Dunlap The extcon-axp288 driver selects USB_ROLE_SWITCH, but the USB Makefile does not currently build drivers/usb/common/

Re: [PATCH 2/2] usb: dwc2: fix isoc split in transfer with no data

Hello! On 4/24/2018 5:43 AM, William Wu wrote: If isoc split in transfer with no data (the length of DATA0 packet is 0), we can't simply return immediately. Because the DATA0 can be the first transaction or the second transaction for the isoc split in transaction. If the DATA0 packet with on

Re: USB regression for Android phone and sound card in 4.14

Am Dienstag, den 24.04.2018, 07:35 +0300 schrieb Nazar Mokrynskyi: > I've tried to bisect kernels from 4.13 to 4.14 and didn't find the reason. > Then I found that with upstream 4.13 the issue is still present on Ubuntu > 18.04, so there should be something more than just a kernel. > >

Re: [PATCH] usb: always build usb/common/ targets; fixes extcon-axp288 build error

On 2018년 04월 17일 18:01, Hans de Goede wrote: > Hi, > > On 17-04-18 07:14, Randy Dunlap wrote: >> From: Randy Dunlap >> >> The extcon-axp288 driver selects USB_ROLE_SWITCH, but the USB >> Makefile does not currently build drivers/usb/common/ (where >> USB_ROLE_SWITCH code