Hi,
Bin Liu writes:
> On Wed, Apr 18, 2018 at 08:20:28AM +0300, Felipe Balbi wrote:
>>
>> Hi Bin,
>>
>> Bin Liu writes:
>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
>> >> Hi guys,
>> >>
>> >> I've been working on this series for a while now. I feels like after
>> >> thi
On Wed, Apr 18, 2018 at 09:18:30PM +0200, Martin Blumenstingl wrote:
> Hi Johan,
>
> On Fri, Apr 13, 2018 at 5:15 PM, Johan Hovold wrote:
> > I've been carrying a patch out-of-tree since my work on improving the
> > USB device-tree support which is needed to be able to describe USB
> > topologies
Not all chipidea users need EXTCON, so it's better to avoid
unconditionally select EXTCON, this could save us 2KB kernel Image size.
Signed-off-by: Jisheng Zhang
---
drivers/usb/chipidea/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipide
Am Mittwoch, den 18.04.2018, 12:44 +0530 schrieb Tushar Nimkar:
> On 2018-04-17 12:03, Tushar Nimkar wrote:
Hi,
> I have doubt that sequential scan(scsi_sequential_lun_scan) work well
> for uas device(SCSI>3)..
> Why? As I have seen in most cases failed to enumerate during REPORT_LUN
> command.
Am Mittwoch, den 18.04.2018, 12:34 +0530 schrieb Tushar Nimkar:
> Oliver/Greg,
> Weather you are able to reproduce the issue?
> Did you tested it on dwc3 previously?
I don't even have a dwc3.
May I suggest that you try to determine whether the issue
happens on the same SCSI command? We need to kno
Hi Ravi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.17-rc1 next-20180419]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Ravi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.17-rc1 next-20180419]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Am Mittwoch, den 18.04.2018, 10:34 -0300 schrieb Cristian:
> Hello,
>
> Open bug in launchpad.net
> https://bugs.launchpad.net/bugs/1765043
Hi,
some more details perhaps? Did this happen during enumeration?
With or without a medium? And so on.
sr should be able to deal with such things. Please
Am Mittwoch, den 18.04.2018, 16:42 +0200 schrieb Dominik 'Rathann'
Mierzejewski:
> On Thursday, 15 March 2018 at 16:53, Dominik 'Rathann' Mierzejewski wrote:
> [...]
> > Could you give me any pointers for debugging this? I cannot trigger
> > this on-demand, but when I'm in a conference call, it occ
It is not a good idea to directly modify the resource of a platform
device. Modify its local copy, and pass it to devm_ioremap_resource()
so that we do not need to restore it in the failure path and the remove
hook.
Signed-off-by: Masahiro Yamada
Reviewed-by: Masami Hiramatsu
---
Changes in v2
In the current design of DWC3 driver,
the DT typically becomes a nested structure like follows:
dwc3-glue {
compatible = "foo,dwc3";
...
dwc3 {
compatible = "snps,dwc3";
...
};
}
The current DWC3 core (drivers/usb/dw
Historically, the clocks and resets are handled on the glue layer
side instead of the DWC3 core. For simple cases, dwc3-of-simple.c
takes care of arbitrary number of clocks and resets. The DT node
structure typically looks like as follows:
dwc3-glue {
compatible = "foo,dwc3";
On 18.04.2018 20:30, Nazar Mokrynskyi wrote:
Hi everyone, I'm running a VM using libvirt on kernel 4.15 (Ubuntu 18.04).
ASMedia USB 3.1 Gen 2 controller is assigned to VM like this:
Occasionally VM start fails with following error and I'm u
Hi,
Felipe Balbi writes:
>>> Bin Liu writes:
>>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
>>> >> Hi guys,
>>> >>
>>> >> I've been working on this series for a while now. I feels like after
>>> >> this series the transfer management code is far easier to read and
>>> >> u
Initialization for SoCs with dual role phy is being bypassed since
FSL_USB2_PHY_UTMI_DUAL macro is not being evaluated in the FSL gadget
driver. In this state a controller configured in peripheral mode will
not work as a gadget. This patch addresses this issue.
Tested on 4.14.32 using a hardware w
On Thu, Apr 19, 2018 at 02:18:21PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Balbi writes:
> >>> Bin Liu writes:
> >>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
> >>> >> Hi guys,
> >>> >>
> >>> >> I've been working on this series for a while now. I feels like after
>
Hi,
Bin Liu writes:
>> Felipe Balbi writes:
>> >>> Bin Liu writes:
>> >>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
>> >>> >> Hi guys,
>> >>> >>
>> >>> >> I've been working on this series for a while now. I feels like after
>> >>> >> this series the transfer management c
clk_disable_unprepare() already checks that the clock pointer is valid.
No need to test it before calling it.
Signed-off-by: Gregory CLEMENT
---
drivers/usb/host/xhci-plat.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/
Hello,
The purpose of this series is to allow xhci-plat using a second
clock. It is needed on the Armada 7K/8K but could be used by other
SoCs.
The first patch is just an other fix found while I was working on this
feature.
Thanks,
Gregory
Changelog:
v1 -> v2:
- Rebased on v4.17-rc1
Gregory
On Armada 7K/8K we need to explicitly enable the register clock. This
clock is optional because not all the SoCs using this IP need it but at
least for Armada 7K/8K it is actually mandatory.
The change was done at xhci-plat level and not at a xhci-mvebu.c because,
it is expected that other SoC wou
Hi Mathias,
On jeu., avril 19 2018, Mathias Nyman wrote:
> On 18.04.2018 17:20, Gregory CLEMENT wrote:
>> Hi Mathias,
>> On mer., févr. 14 2018, Gregory CLEMENT
>> wrote:
>>
>>> Hello,
>>>
>>> The purpose of this series is to allow xhci-plat using a second
>>> clock. It is needed on the A
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/usb/mtu3/mtu3_plat.c | 6 ++
1 file changed, 2 insertions(+), 4 deletion
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/usb/phy/phy-am335x.c | 6 ++
1 file changed, 2 insertions(+), 4 deletion
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ s
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for readi
Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
4=link100/1000/
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell
---
dr
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for readi
On 2018-04-19 14:15, Oliver Neukum wrote:
Am Mittwoch, den 18.04.2018, 12:44 +0530 schrieb Tushar Nimkar:
On 2018-04-17 12:03, Tushar Nimkar wrote:
Hi,
I have doubt that sequential scan(scsi_sequential_lun_scan) work well
for uas device(SCSI>3)..
Why? As I have seen in most cases failed to e
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2018年4月16日 22:28
> To: Jun Li
> Cc: gre...@linuxfoundation.org; heikki.kroge...@linux.intel.com;
> li...@roeck-us.net; a.ha...@samsung.com; shufan_...@richtek.com; Peter
> Chen ; devicet...@vger.kernel.org;
> linux-u
On 2018-04-19 14:18, Oliver Neukum wrote:
Am Mittwoch, den 18.04.2018, 12:34 +0530 schrieb Tushar Nimkar:
Oliver/Greg,
Weather you are able to reproduce the issue?
Did you tested it on dwc3 previously?
I don't even have a dwc3.
Great, so uas on dwc3 new to all...
May I suggest that you try t
On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote:
> On chromebooks we depend on wakeup count to identify the wakeup source.
> But currently USB devices do not increment the wakeup count when they
> trigger the remote wake. This patch addresses the same.
>
> Resume condition is reported differentl
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell
---
dr
Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
4=link100/1000/
> @@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
> mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
> phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
>
> + if (phydev->mdio.dev.of_node) {
> + u32 reg;
> +
[ Resending due to incorrect distribution list ]
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or prog
On Thu, Apr 19, 2018 at 03:32:05PM +0100, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications withou
Hosts that support USB 3.2 Enhaned SuperSpeed can set their hcd speed
to HCD_USB32 to let usb core and host drivers know that the controller
supports new USB 3.2 dual-lane features.
make sure usb core handle HCD_USB32 hosts correctly, for now similar
to HCD_USB32.
Signed-off-by: Mathias Nyman
--
Hi
A new version based on earlier suggestions and feedback.
The USB 3.2 specification adds support for Dual-lane, doubling the
maximum rate to 20Gbps by taking into use another set of rx and tx
wires and pins in the Type-C cable and connector.
The changes to support this in USB core and xhci dri
Set the the rx_lane and tx_lane count to "2" for USB 3.2 hosts.
For all other older hosts set the default lane counts to 1
Signed-off-by: Mathias Nyman
---
drivers/usb/core/hcd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index b1463a
USB 3.2 specification adds a Gen XxY notion for USB3 devices where
X is the signaling rate on the wire. Gen 1xY is 5Gbps Superspeed
and Gen 2xY is 10Gbps SuperSpeedPlus. Y is the lane count.
For normal, non inter-chip (SSIC) devies the rx and tx lane count is
symmetric, and the maximum lane count
USB 3.2 specification adds Dual-lane support, doubling the maximum
SuperSpeedPlus data rate from 10Gbps to 20Gbps.
Dual-lane takes into use a second set of rx and tx wires/pins in the
Type-C cable and connector.
Add "rx_lanes" and "tx_lanes" variables to struct usb_device to store
the numer of la
rx_lanes and tx_lanes sysfs entries show the number of lanes in use by a
device.
USB 3.2 adds support for Dual-lane (symmetrical), using 2 rx lanes and
2 tx lanes for normal non Inter-Chip SSIC devices.
USB 3.1 and older are all single lane.
SSIC devices can have up to 4 lanes per direction in use
Add rx_lanes and tx_lanes lane count sysfs entries for a usb device
struct usb_devuce rx_lanes and tx_lanes variables.
Shows number of lanes used by the usb device
Data rate of a device is the lane speed * lane count, for example
USB 3.2 Gen 2x2 device uses 10Gbps signaling per lane, and has dual
On Thu, Apr 19, 2018 at 10:16 AM, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications without an EE
On Thu, Apr 19, 2018 at 8:01 AM, Alan Stern wrote:
> On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote:
>
>> On chromebooks we depend on wakeup count to identify the wakeup source.
>> But currently USB devices do not increment the wakeup count when they
>> trigger the remote wake. This patch addres
Hi all,
On 10/04/2018 10:21 PM, Grigor Tovmasyan wrote:
> Here are two little fixes for LPM feature.
>
> First one is coverity warning fix.
>
> The Second one was asserted by Stefan Wahren.
>
> Changes from version 0:
>
> 1/2:
> - Instead of converting parameter in the CHECK_RANGE macro
>
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell
---
dr
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for readi
Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
4=link100/1000/
From: Pawel Dembicki
Date: Wed, 18 Apr 2018 16:03:24 +0200
> This modem is embedded on dlink dwr-960 router.
> The oem configuration states:
...
> Tested on openwrt distribution
>
> Signed-off-by: Pawel Dembicki
Applied and queued up for -stable.
--
To unsubscribe from this list: send the lin
19.04.18 14:17, Mathias Nyman пише:
> On 18.04.2018 20:30, Nazar Mokrynskyi wrote:
>> Hi everyone, I'm running a VM using libvirt on kernel 4.15 (Ubuntu 18.04).
>>
>> ASMedia USB 3.1 Gen 2 controller is assigned to VM like this:
>>
>>
>>
>>
>>
>>
>> >
On 17.04.2018 03:17, Jerry Zhang wrote:
[...]
+ cfg = &gi->control_config;
+ c = &cfg->c;
+ list_for_each_entry_safe(f, tmp, &cfg->func_list, list) {
+ if (f->req_match && f->setup) {
+ list_del(&f->list);
+ if (usb_add_fu
> [...]
> >
> > + cfg = &gi->control_config;
> > + c = &cfg->c;
> > + list_for_each_entry_safe(f, tmp, &cfg->func_list, list) {
> > + if (f->req_match && f->setup) {
> > + list_del(&f->list);
> > + if (usb_add_function(&cfg->c, f))
> >
On 19.04.2018 21:02, Jerry Zhang wrote:
[...]
As main usecase for this code is FunctionFS I think that we should
consider adding some flag to FunctionFS to mark instance as only for
such purpouse. I mean sth like FFS_CONTROL_ONLY which would make
FunctionFS igore the descs (or allow to provid
Hi Paul,
Thank you for the patch series. I believe you've already noticed that the
subject line of the cover letter should have mentioned 0/4 instead of 0/5.
On Wednesday, 18 April 2018 06:20:15 EEST Paul Elder wrote:
> Down the call stack from the ioctl handler for VIDIOC_STREAMON,
> uvc_video_
Hi Paul,
(CC'ing Felipe Balbi and Roger Quadros)
Thank you for the patch.
Have you used scripts/get_maintainer.pl ? It should point you to Felipe Balbi,
the maintainer of the USB gadget subsystem, who I recommend you CC, at least
on patch 2/4. The script also points to Greg, who I don't think
Dear Friend,
Compliments of the day. I hope that this letter does not surprise you
because we have not met. However, I urge you to treat the information
with it's contains with due and utmost attention. Apart from being
eternally grateful to you, I also assure that you shall be adequately
compensa
Hello Johan,
On Thu, Apr 19, 2018 at 9:43 AM, Johan Hovold wrote:
> On Wed, Apr 18, 2018 at 09:18:30PM +0200, Martin Blumenstingl wrote:
>> Hi Johan,
>>
>> On Fri, Apr 13, 2018 at 5:15 PM, Johan Hovold wrote:
>> > I've been carrying a patch out-of-tree since my work on improving the
>> > USB dev
Still an issue as of 4.17-rc1 for sound card.
Sincerely, Nazar Mokrynskyi
github.com/nazar-pc
17.03.18 19:04, Nazar Mokrynskyi пише:
> With kernel 4.16-rc5 it is still happening to USB sound card, Android phone
> issue was probably related to something else and is already fixed.
>
> Very annoyin
From: Kamil Lulko
Add DELAY_INIT quirk to fix the following problem with HP
v222w 16GB Mini:
usb 1-3: unable to read config index 0 descriptor/start: -110
usb 1-3: can't read configurations, error -110
usb 1-3: can't set config #1, error -110
Signed-off-by: Kamil Lulko
Signed-off-by: Kuppuswam
Thanks for your feedback! I think I'm beginning to better understand
what's going on. When I originally got the X360-emulated device working
on the loopback interface, I left out several class descriptors and an
interface with no endpoints (but has a vendor-specific descriptor
following it).
On chromebooks we depend on wakeup count to identify the wakeup source.
But currently USB devices do not increment the wakeup count when they
trigger the remote wake. This patch addresses the same.
Resume condition is reported differently on USB 2.0 and USB 3.0 devices.
On USB 2.0 devices, a wake
Hi Alan,
Thanks for reviewing the change. Appreciate your time. I tried to
address your comments in the V2 of the patch.
On Thu, Apr 19, 2018 at 8:01 AM, Alan Stern wrote:
> On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote:
>
>> On chromebooks we depend on wakeup count to identify the wakeup sou
> drivers/usb/chipidea/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index
> 785f0ed037f7..97509172d536 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -1,7 +1,6 @@
> config USB_
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -3,6 +3,8 @@ config USB_CHIPIDEA
> depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD
> && !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
> select EXTCON
> select RESET_CONTROLLER
69 matches
Mail list logo
