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 is) unless USB_COMMON is
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.
>
> Eventuall
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 da
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/ (where
USB_ROLE_SWITCH co
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:
>
> https://storage.kerne
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
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 commands?
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
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 that
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 m
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
> ---
> drivers/
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 propert
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 derefe
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 u
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, thi
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 Krogeru
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 option
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
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
---
drivers/usb/gadget/function/f_phonet.c
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:
>>
>> :
>>0: 55 push
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 yet
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
---
drivers/net/usb/ipheth.c | 2 +-
1 fil
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 jus
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
>>>
>>> clang-eflag.o: file format elf64-x86-64
>>>
>>>
>>> Disassembly of section .text:
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
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 with
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
>
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
> ---
> Documentation/devicetree/bindings/gra
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 l
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
that "test $0xff,%bl" is a
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:
>
> 1a: f6 c3 fftest $0xff,%bl
> 1
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 mode
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
> > >
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 patc
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 wit
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
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 +---
drivers/i2c/busses/
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 deletions(-)
diff
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 ---
drivers/usb/host/ohci-exynos.c | 6
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
arch/arm/mach-exynos/common.h | 8
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 +-
drivers/pinctrl/samsung/Mak
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 -
drivers/ata/ahci_pla
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 +-
drivers/thermal/samsun
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 --
drivers/cpufreq/Kconfi
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
drivers/clk/samsung/
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
> server platforms bu
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 Exynos5440.
> >
> >
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
ap
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 physically
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
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. Remove delay usb status phase
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). After
> applying 10/10, which remove
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, fun
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
b/Documentation/usb/gadget_configfs.txt
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
canno
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 u
> > >
> > > 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
>
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
> ---
> .../bindings/cpufreq/c
Use SPDX-License-Identifier tag instead of the GPL license text
Signed-off-by: Chunfeng Yun
---
drivers/phy/mediatek/Makefile | 1 +
drivers/phy/mediatek/phy-mtk-tphy.c | 10 +-
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/mediatek/Makefile b/drivers/
59 matches
Mail list logo
