Hi Stephen,
On Thu, Sep 1, 2016 at 6:10 AM, Stephen Boyd wrote:
> The HSIC USB controller on qcom SoCs has an integrated all
> digital phy controlled via the ULPI viewport.
>
> Cc: Kishon Vijay Abraham I
> Cc:
> Signed-off-by: Stephen Boyd
> ---
> .../devicetree/bindings/phy/qcom,usb-hsic-ph
On Thu, Sep 01, 2016 at 11:31:20AM +0800, Tang Jianqiang wrote:
> Hi ALL,
> One question for you guys,
> does the current kernel USB stack support H264 USB camera by default?
> Did some basic check but not found clear result.
> Help will be very appreciated!
What is the usb vendor/product
On 31 August 2016 at 21:00, Rafał Miłecki wrote:
> On 31 August 2016 at 20:23, Alan Stern wrote:
>> On Tue, 30 Aug 2016, Rafał Miłecki wrote:
>>> Not really as it won't cover some pretty common use cases. Many home
>>> routers have few USB ports (2-5) and only 1 USB LED. It has to be
>>> possible
On 31-08-16, 12:46, Alan Stern wrote:
> On Wed, 31 Aug 2016, Viresh Kumar wrote:
>
> > On 05-08-16, 11:51, Alan Stern wrote:
> > > +++ usb-4.x/drivers/usb/core/hub.c
> > > @@ -1052,7 +1052,7 @@ static void hub_activate(struct usb_hub
> > >
> > > /* Continue a partial initialization */
> > >
From: robert.f...@collabora.com
Date: Mon, 29 Aug 2016 09:32:14 -0400
> This is a resubmission of v3, since the netdev
> mailinlist was not sent the previous submission.
>
> This series improves power management of the asix driver.
...
Series applied, thanks.
--
To unsubscribe from this list: s
From: Julia Lawall
Date: Thu, 1 Sep 2016 00:21:22 +0200
> Check for ethtool_ops structures that are only stored in the ethtool_ops
> field of a net_device structure or passed as the second argument to
> netdev_set_default_ethtool_ops. These contexts are declared const, so
> ethtool_ops structur
Hi ALL,
One question for you guys,
does the current kernel USB stack support H264 USB camera by default?
Did some basic check but not found clear result.
Help will be very appreciated!
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message
Hi,
On 08/31/2016 06:17 PM, Oliver Neukum wrote:
> On Mon, 2016-08-29 at 13:26 +0800, Lu Baolu wrote:
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -1128,6 +1128,7 @@ bytes respectively. Such letter suffixes can
>> also be entirely omitted.
>>
Hi Oliver,
Thanks for review.
On 08/31/2016 05:53 PM, Oliver Neukum wrote:
> On Mon, 2016-08-29 at 13:26 +0800, Lu Baolu wrote:
>> + /*
>> +* Memory barrier to ensure hardware sees the trbs
>> +* enqueued above.
>> +*/
>> + wmb();
>> + if (cycle)
>> +
This driver is for Fintek F81532/F81534 USB to Serial Ports IC.
F81532 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?usp=
sharing
F81534 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?usp=
sharing
Features:
1. F81532 is 1-to-2 & F81534 is 1-to-4
On 2016年09月01日 00:29, Alan Stern wrote:
On Wed, 31 Aug 2016, Chuang Dong wrote:
When a system is put into S3 sleep, a usb terminal connected to the
UHCI host port can't wake up the system.
For example: if the command "pm-suspend" is used to put the system into
S3 mode, the system cannot be w
The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
product ID registers. This makes it impossible to make a ULPI
driver match against the ID registers. Add support to discover
the ULPI phys via DT help alleviate this problem. In the DT case,
we'll look for a ULPI bus node underneath
The ULPI bus can be built as a module, and it will soon be
calling these functions when it supports probing devices from DT.
Export them so they can be used by the ULPI module.
Cc: Rob Herring
Cc:
---
drivers/of/device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/of/device.c
The state of USB ChipIdea support on Qualcomm's platforms is not great.
The DT description of these devices requires up to three different nodes
for what amounts to be the same hardware block, when there should really
only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
du
With the id and vbus detection done via extcon we need to make
sure we poll the status of OTGSC properly by considering what the
extcon is saying, and not just what the register is saying. Let's
move this hw_wait_reg() function to the only place it's used and
simplify it for polling the OTGSC regis
In the case of ULPI devices, we want to be able to load the
driver before registering the device so that we don't get stuck
in a loop waiting for the phy module to appear and failing usb
controller probe. Currently we request the ulpi module via the
ulpi ids, but in the DT case we might need to req
The ULPI phy on qcom platforms needs to be initialized and
powered on after a USB reset and before we toggle the run/stop
bit. Otherwise, the phy locks up and doesn't work properly.
Therefore, add a flag to skip any phy power management in the
core layer, leaving it up to the glue driver to manage.
We're currently emulating the vbus and id interrupts in the OTGSC
read API, but we also need to make sure that if we're handling
the events with extcon that we don't enable the interrupts for
those events in the hardware. Therefore, properly emulate this
register if we're using extcon, but don't en
We're not properly marking the glue layer/wrapper device as
runtime active, so runtime PM believes that the hardware state is
inactive when we call pm_runtime_enable() in this driver. This
causes a problem when the glue layer has a power domain
associated with it, because runtime PM will go and dis
The two extcon notifiers are almost the same except for the
variable name for the cable structure and the id notifier inverts
the cable->state logic. Make it the same and replace two
functions with one to save some lines. This also makes it so that
the id cable state is true when the id pin is pull
The chipidea/udc.c file sends a CI_HDRC_CONTROLLER_RESET_EVENT to
the wrapper drivers when it calls hw_device_reset(), but that
function is not called from chipidea/host.c. And the udc.c file
sends the CI_HDRC_CONTROLLER_STOPPED_EVENT but the host.c file
doesn't do anything.
The intent of the rese
We don't call hw_device_reset() with the ci->lock held, so it
doesn't seem like this lock here is protecting anything. Let's
just remove it. This allows us to call sleeping functions like
phy_init() from within the CI_HDRC_CONTROLLER_RESET_EVENT hook.
Acked-by: Peter Chen
Cc: Greg Kroah-Hartman
The core framework already handles setting this parameter with a
platform quirk. Add the appropriate flag so that we always set
AHBBURST to 0. Technically DT should be doing this, but we always
do it for msm chipidea devices so setting the flag in the driver
works just as well. If the burst needs t
Some phys for the chipidea controller are controlled via the ULPI
viewport. Add support for the ULPI bus so that these sorts of
phys can be probed and read/written automatically without having
to duplicate the viewport logic in each phy driver.
Cc: Peter Chen
Cc: Greg Kroah-Hartman
Cc: Heikki Kr
The HSIC USB controller on qcom SoCs has an integrated all
digital phy controlled via the ULPI viewport.
Cc: Kishon Vijay Abraham I
Cc:
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/phy/qcom,usb-hsic-phy.txt | 65 +
drivers/phy/Kconfig| 7 +
The high-speed phy on qcom SoCs is controlled via the ULPI
viewport.
Cc: Kishon Vijay Abraham I
Cc:
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/phy/qcom,usb-hs-phy.txt| 83 ++
drivers/phy/Kconfig| 8 +
drivers/phy/Makefile
The MSM_USB_BASE macro trick is not very clear, and we're using
it for only one register write so let's just move to using
hw_write_id_reg() and passing the ci pointer instead. That
clearly shows what offset we're using and avoids needing to
include the msm_hsusb_hw.h file when we're going to delet
If something fails in ci_hdrc_add_device() due to probe defer, we
shouldn't print an error message. Be silent in this case as we'll
try probe again later.
Acked-by: Peter Chen
Cc: Greg Kroah-Hartman
Signed-off-by: Stephen Boyd
---
drivers/usb/chipidea/ci_hdrc_msm.c | 3 ++-
1 file changed, 2 i
The msm chipidea controller uses two main clks, an AHB clk to
read/write the MMIO registers and a core clk called the system
clk that drives the controller itself. Add support for these clks
as they're required in all designs.
Also add support for an optional third clk that we need to turn
on to r
The MSM chipidea wrapper has two bits that are used to reset the
first or second phy. Add support for these bits via the reset
controller framework, so that phy drivers can reset their
hardware at the right time during initialization.
Cc: Peter Chen
Cc: Greg Kroah-Hartman
Signed-off-by: Stephen
The ULPI phy on qcom platforms needs to be initialized and
powered on after a USB reset and before we toggle the run/stop
bit. Otherwise, the phy locks up and doesn't work properly. Hook
the phy initialization into the RESET event and the phy power off
into the STOPPED event.
Acked-by: Peter Chen
If two devices are probed with this same driver, they'll share
the same platform data structure, while the chipidea core layer
writes and modifies it. This can lead to interesting results
especially if one device is an OTG type chipidea controller and
another is a host. Let's create a copy of this
When the RESET bit is set in the USBCMD register it resets quite
a few of the wrapper's registers to their reset state. This
includes the GENCONFIG and GENCONFIG2 registers. Currently this
is done by the usb phy and ehci-msm drivers writing into the
controller wrapper's MMIO address space. Let's co
We need to pick the correct phy at runtime based on how the SoC
has been wired onto the board. If the secondary phy is used, take
it out of reset and mux over to it by writing into the TCSR
register. Make sure to do this on reset too, because this
register is reset to the default value (primary phy
Constify ethtool_ops structures.
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
drivers/net/ethernet/synopsys/dwc_eth_qos.c |2 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c |2 +-
drivers/net/usb/r8152.c |2 +-
drivers/staging
Check for ethtool_ops structures that are only stored in the ethtool_ops
field of a net_device structure or passed as the second argument to
netdev_set_default_ethtool_ops. These contexts are declared const, so
ethtool_ops structures that have these properties can be declared as const
also.
The s
On 8/31/2016 12:47 PM, Felipe Balbi wrote:
>
> Hi John,
>
> John Youn writes:
>> On 8/31/2016 2:38 AM, Felipe Balbi wrote:
>>> If we don't know what are the actual U1/U2 exit
>>> latencies from the UDC, we're better off using
>>> maximum latencies as default. This should avoid
>>> any problems w
On Wed, 31 Aug 2016, Felipe Balbi wrote:
> Hi John,
>
> John Youn writes:
> > On 8/31/2016 2:38 AM, Felipe Balbi wrote:
> >> If we don't know what are the actual U1/U2 exit
> >> latencies from the UDC, we're better off using
> >> maximum latencies as default. This should avoid
> >> any problems
Hi John,
John Youn writes:
> On 8/31/2016 2:38 AM, Felipe Balbi wrote:
>> If we don't know what are the actual U1/U2 exit
>> latencies from the UDC, we're better off using
>> maximum latencies as default. This should avoid
>> any problems with too frequent U1/U2 entry.
>>
>> Signed-off-by: Feli
On 31 August 2016 at 20:23, Alan Stern wrote:
> On Tue, 30 Aug 2016, Rafał Miłecki wrote:
>
>> >> As you quite often need more complex LED management, there are
>> >> triggers that were introduced in 2006 by c3bc9956ec52f ("[PATCH] LED:
>> >> add LED trigger tupport"). Some triggers are trivial an
--
Dear Sir/Madam, we would like to see your company latest catalogs.
Your early reply is highly appreciated.
Thank You !
Best Regards,
Mr. John williams
(Purchasing Manager)
*
Trade Company limited.
2755 lake pine path apt 122,
St Joseph, Trad
On 8/31/2016 2:38 AM, Felipe Balbi wrote:
> If we don't know what are the actual U1/U2 exit
> latencies from the UDC, we're better off using
> maximum latencies as default. This should avoid
> any problems with too frequent U1/U2 entry.
>
> Signed-off-by: Felipe Balbi
> ---
> include/linux/usb/g
On Tue, 30 Aug 2016, Rafał Miłecki wrote:
> >> As you quite often need more complex LED management, there are
> >> triggers that were introduced in 2006 by c3bc9956ec52f ("[PATCH] LED:
> >> add LED trigger tupport"). Some triggers are trivial and could be
> >> implemented in userspace as well (e.g
On Wed, Aug 31, 2016 at 5:57 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 30 August 2016 08:00 PM, Al Cooper wrote:
>> Add a new USB Phy driver for Broadcom STB SoCs. This driver
>> supports all Broadcom STB ARM SoCs. This driver in combination
>> with the generic ohci, ehci and xhci pla
On Wednesday 31 August 2016 10:03 PM, Fabio Estevam wrote:
On Wed, Aug 31, 2016 at 1:28 PM, Sudip Mukherjee
wrote:
Use proper error code instead of using -1 on failure to allocate
memory. We may use the error code later in the caller.
Signed-off-by: Sudip Mukherjee
---
drivers/hid/usbhid/us
Additional testing has been done the hardware that is available to me.
I'm not seeing any dmesg warnings/errors that are new to this series:
AX88772A
- Pass network_EthernetStressPlug
- Pass phy up/down + iperf3 UDP stress
- Pass network_EthernetStressPlug + iperf3 UDP stress
AX88772B
- Pass net
On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hirema
On Wed, 31 Aug 2016, Viresh Kumar wrote:
> On 05-08-16, 11:51, Alan Stern wrote:
> > +++ usb-4.x/drivers/usb/core/hub.c
> > @@ -1052,7 +1052,7 @@ static void hub_activate(struct usb_hub
> >
> > /* Continue a partial initialization */
> > if (type == HUB_INIT2 || type == HUB_INIT3) {
> >
On Wed, 31 Aug 2016, Chuang Dong wrote:
> When a system is put into S3 sleep, a usb terminal connected to the
> UHCI host port can't wake up the system.
>
> For example: if the command "pm-suspend" is used to put the system into
> S3 mode, the system cannot be woken up via a keyboard connected to
On Wed, Aug 31, 2016 at 1:28 PM, Sudip Mukherjee
wrote:
> Use proper error code instead of using -1 on failure to allocate
> memory. We may use the error code later in the caller.
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/hid/usbhid/usbkbd.c | 10 +-
> 1 file changed, 5 insertio
Use proper error code instead of using -1 on failure to allocate
memory. We may use the error code later in the caller.
Signed-off-by: Sudip Mukherjee
---
drivers/hid/usbhid/usbkbd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/usbhid/usbkbd.c b/driv
On Wed, Aug 31, 2016 at 07:30:55AM -0700, Tony Lindgren wrote:
> * Vinod Koul [160830 21:45]:
> > On Fri, Aug 19, 2016 at 03:59:40PM -0700, Tony Lindgren wrote:
> > > Let's keep the device enabled between cppi41_dma_issue_pending()
> > > and dmaengine_desc_get_callback_invoke() and rely on the PM
* Vinod Koul [160830 21:45]:
> On Fri, Aug 19, 2016 at 03:59:40PM -0700, Tony Lindgren wrote:
> > Let's keep the device enabled between cppi41_dma_issue_pending()
> > and dmaengine_desc_get_callback_invoke() and rely on the PM runtime
> > autoidle timeout elsewhere.
> >
> > As the PM runtime is f
On August 31, 2016 5:23:05 PM GMT+03:00, Tejun Heo wrote:
>On Tue, Aug 30, 2016 at 10:02:47PM +0530, Bhaktipriya Shridhar wrote:
>> The workqueue "pegasus_workqueue" queues a single work item per
>pegasus
>> instance and hence it doesn't require execution ordering. Hence,
>> alloc_workqueue has be
On Tue, Aug 30, 2016 at 10:02:47PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue "pegasus_workqueue" queues a single work item per pegasus
> instance and hence it doesn't require execution ordering. Hence,
> alloc_workqueue has been used to replace the deprecated
> create_singlethread_workqueu
On 08/31/2016 01:24 PM, Oliver Neukum wrote:
> On Wed, 2016-08-31 at 12:48 +0300, Binyamin Sharet wrote:
>
>> Sure, but could you send me the cdc-acm.c file that this patch applies to?
>> Otherwise I need to patch it manually each time...
> Patch already applied.
>
> HTH
> Olive
On 08/31/2016 04:09 AM, Heikki Krogerus wrote:
Hi guys,
On Tue, Aug 30, 2016 at 06:47:41AM -0700, Guenter Roeck wrote:
On 08/30/2016 06:11 AM, Heikki Krogerus wrote:
Hi,
On Tue, Aug 30, 2016 at 02:49:50PM +0300, Heikki Krogerus wrote:
On Tue, Aug 30, 2016 at 01:16:46PM +0200, Oliver Neukum w
On Tue, 2016-08-30 at 19:20 +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 26, 2016 at 05:38:27PM +0800, chunfeng yun wrote:
> > Hi,
> >
> > On Thu, 2016-08-25 at 10:32 +0200, Oliver Neukum wrote:
> > > On Thu, 2016-08-25 at 11:05 +0800, Chunfeng Yun wrote:
> > > > This patch adds support for the
Hi guys,
On Tue, Aug 30, 2016 at 06:47:41AM -0700, Guenter Roeck wrote:
> On 08/30/2016 06:11 AM, Heikki Krogerus wrote:
> > Hi,
> >
> > On Tue, Aug 30, 2016 at 02:49:50PM +0300, Heikki Krogerus wrote:
> > > On Tue, Aug 30, 2016 at 01:16:46PM +0200, Oliver Neukum wrote:
> > > > Error reporting do
On Wed, 2016-08-31 at 12:48 +0300, Binyamin Sharet wrote:
> Sure, but could you send me the cdc-acm.c file that this patch applies to?
> Otherwise I need to patch it manually each time...
Patch already applied.
HTH
Oliver
/*
* cdc-acm.c
*
* Copyright (c) 1999 Armin F
On Mon, 2016-08-29 at 13:26 +0800, Lu Baolu wrote:
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1128,6 +1128,7 @@ bytes respectively. Such letter suffixes can
> also be entirely omitted.
> earlyprintk=ttySn[,baudrate]
>
On Mon, 2016-08-29 at 13:26 +0800, Lu Baolu wrote:
> + /*
> +* Memory barrier to ensure hardware sees the trbs
> +* enqueued above.
> +*/
> + wmb();
> + if (cycle)
> + trb->field[3] |= cpu_to_le32(cycle);
> + else
> + trb->
Hi,
On Tuesday 30 August 2016 08:00 PM, Al Cooper wrote:
> Add a new USB Phy driver for Broadcom STB SoCs. This driver
> supports all Broadcom STB ARM SoCs. This driver in combination
> with the generic ohci, ehci and xhci platform drivers will enable
> USB1.1, USB2.0 and USB3.0 support. This Phy
On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
>
>
> On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
> >On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
> >>On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
> >>>On Monday 15 August 2016 02:43 PM,
On 08/31/2016 12:27 PM, Oliver Neukum wrote:
> On Fri, 2016-08-26 at 18:02 +, Binyamin Sharet (bsharet) wrote:
>
>> I think the reason is that in case of quirks == NO_UNION_NORMAL it gets the
>> data
>> and control interfaces and then jumps to skip_normal probe, in which case
>> there are no
If we don't know what are the actual U1/U2 exit
latencies from the UDC, we're better off using
maximum latencies as default. This should avoid
any problems with too frequent U1/U2 entry.
Signed-off-by: Felipe Balbi
---
include/linux/usb/gadget.h | 12 ++--
1 file changed, 10 insertions(+
According to USB 3.1 Specification, that field is
called bU1DevExitLat with a capitalized 'Dev'.
Just to make grepping in the spec easier, let's
match the name.
Signed-off-by: Felipe Balbi
---
drivers/usb/core/hub.c | 8
drivers/usb/gadget/composite.c | 4 ++--
include/linux/us
According to USB 3.1 Specification, that field is 2
bytes wide and is named with a 'w' prefix, not 'b'.
Just to make grepping in the spec easier, let's
match the name.
Signed-off-by: Felipe Balbi
---
drivers/usb/core/hub.c | 8
drivers/usb/gadget/composite.c | 4 ++--
drivers/u
On Fri, 2016-08-26 at 18:02 +, Binyamin Sharet (bsharet) wrote:
> I think the reason is that in case of quirks == NO_UNION_NORMAL it gets the
> data
> and control interfaces and then jumps to skip_normal probe, in which case
> there are no
> checks whether data_interface, data_interface->cur
When a system is put into S3 sleep, a usb terminal connected to the
UHCI host port can't wake up the system.
For example: if the command "pm-suspend" is used to put the system into
S3 mode, the system cannot be woken up via a keyboard connected to the
UCHI port.
The reason is the suspend_rh() set
On Wed, Aug 31, 2016 at 02:30:15PM +0530, Malith Yapa wrote:
> On Mon, Aug 29, 2016 at 11:29 PM, Alan Stern
> wrote:
> > On Mon, 29 Aug 2016, Greg KH wrote:
> >
> >> > >> I have since compiled 4.8.0_rc1. And just as you guys suggested a part
> >> > >> of problem is solved. The minor number now de
On Mon, Aug 29, 2016 at 11:29 PM, Alan Stern wrote:
> On Mon, 29 Aug 2016, Greg KH wrote:
>
>> > >> I have since compiled 4.8.0_rc1. And just as you guys suggested a part
>> > >> of problem is solved. The minor number now definitely goes up to 512
>> > >> before giving no more free serial devices.
On Monday 29 August 2016 04:40 PM, Peter Chen wrote:
On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:
On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:
On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
Hi all,
This is a follow-up for my last power sequence fram
73 matches
Mail list logo
