On Sun, Oct 16, 2016 at 10:17:53AM -0700, Andy Lutomirski wrote:
> On Thu, Oct 6, 2016 at 10:25 AM, Andy Lutomirski wrote:
> > Pointing an sg list at the stack is verboten and, with
> > CONFIG_VMAP_STACK=y, will malfunction. Use kmalloc for the wusb
> > crypto stack space instead.
> >
> > Unteste
Hi,
(I have added you to another thread which is where we'll be collecting
discussion about this, however ...)
Alan Stern writes:
> On Fri, 14 Oct 2016, Felipe Balbi wrote:
>
>> argh, we have nested spinlocks :-( Well, we shouldn't call
>> usb_ep_disable() with locks held AFAICR. So the followi
Hi Baolin,
Baolin Wang writes:
>> Felipe Balbi writes:
>>> Instead of just delaying for 100us, we should
>>> actually wait for End Transfer Command Complete
>>> interrupt before moving on. Note that this should
>>> only be done if we're dealing with one of the core
>>> revisions that actually r
Hi,
Michael Niewöhner writes:
> Hi Felipe,
> On Fri, 2016-10-07 at 22:26 +0200, Michael Niewöhner wrote:
>> Hi Felipe,
>>
>> On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:
>> > Hi,
>> >
>> > Michael Niewöhner writes:
>> > >
>> > > >
>> > > > The clocks are same across working/non-wor
> From: Bin Liu [mailto:b-...@ti.com]
> On Thu, Oct 06, 2016 at 02:45:30PM +, Andrew Goodbody wrote:
> > I am trying to investigate an issue on a TI Sitara CPU, AM3352 with
> > the musb USB controller.
> >
> > The scenario is that a device has been in use and working correctly.
> > The device i
On Fri, 2016-10-14 at 01:16 +0100, Snaper wrote:
> Hi Oliver,
>
> On 10/10/2016 08:19, Oliver Neukum wrote:
> > it is very hard for us to say something about that specific kernel.
> > We don't know the kernel tree. And the error seems to be in the OF
> > code. I think you are in the wrong list, or
Hi,
(please, avoid top-posting: http://daringfireball.net/2007/07/on_top)
Lipengcheng writes:
> Hi,
> thank you for your suggestion.
>
> I have a question about usb2eth. In the function gen_ndis_set_resp
> of the rndis.c, the value of *params->filter may be 0x20 from the
> pc set co
Hi,
Pengcheng Li writes:
> The USBTRDTIM field needs to be cleared before setting a new value.
> Otherwise it will result in an incorrect value if phyif == GUSBCFG_PHYIF8.
>
> Change-Id: Ib3e33cf4fd15ada41dc070ff7b93858daafbd10f
> Signed-off-by: Pengcheng Li
> Acked-by: John Youn
which commit
On Mon, Oct 17, 2016 at 11:06:49AM +0300, Felipe Balbi wrote:
>
> Hi Baolin,
>
> Baolin Wang writes:
> >> Felipe Balbi writes:
> >>> Instead of just delaying for 100us, we should
> >>> actually wait for End Transfer Command Complete
> >>> interrupt before moving on. Note that this should
> >>>
On 10/17/2016 01:38 PM, Felipe Balbi wrote:
Hi,
Michael Niewöhner writes:
Hi Felipe,
On Fri, 2016-10-07 at 22:26 +0200, Michael Niewöhner wrote:
Hi Felipe,
On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:
Hi,
Michael Niewöhner writes:
The clocks are same across working/non-working
Hi,
Peter Chen writes:
> On Mon, Oct 17, 2016 at 11:06:49AM +0300, Felipe Balbi wrote:
>>
>> Hi Baolin,
>>
>> Baolin Wang writes:
>> >> Felipe Balbi writes:
>> >>> Instead of just delaying for 100us, we should
>> >>> actually wait for End Transfer Command Complete
>> >>> interrupt before mov
On Sun, Oct 16, 2016 at 10:54:34AM -0400, Alan Stern wrote:
> On Sat, 15 Oct 2016, Bryan Paluch wrote:
>
> > Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
> > with 20 ms of slack, after removing slack time some ohci controllers don't
> > respond in time. Logs from systems with
Hi,
Baolin Wang writes:
> When we change the USB function with configfs dynamically, we possibly met
> this
> situation: one core is doing the control transfer, another core is trying to
> unregister the USB gadget from userspace, we must wait for completing this
> control tranfer, or it will h
Hi,
Binyamin Sharet writes:
> On 09/12/2016 04:11 PM, Alan Stern wrote:
>> On Mon, 12 Sep 2016, Binyamin Sharet (bsharet) wrote:
>>
On 8 Sep 2016, at 23:24, Alan Stern wrote:
On Thu, 8 Sep 2016, Binyamin Sharet (bsharet) wrote:
>> On 8 Sep 2016, at 22:20, Alan Stern wro
Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
needs to handle 4 reset lines for EHCI.
Signed-off-by: Masahiro Yamada
---
drivers/usb/host/ehci-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/ho
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/next
head: 4281ef86fae986e0a9bb553fb311fe6d8e039118
commit: 040f47e7330045feaa8c06bf2900db2eb2038e80 [57/84] usb: dwc3: Kconfig:
allow all glues to build if COMPILE_TEST
config: blackfin-allmodconfig (attached as .con
Hi,
On 17 October 2016 at 18:10, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> When we change the USB function with configfs dynamically, we possibly met
>> this
>> situation: one core is doing the control transfer, another core is trying to
>> unregister the USB gadget from userspace,
Hi,
kbuild test robot writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> testing/next
> head: 4281ef86fae986e0a9bb553fb311fe6d8e039118
> commit: 040f47e7330045feaa8c06bf2900db2eb2038e80 [57/84] usb: dwc3: Kconfig:
> allow all glues to build if COMPILE_TEST
> co
Hi,
Baolin Wang writes:
>> Baolin Wang writes:
>>> When we change the USB function with configfs dynamically, we possibly met
>>> this
>>> situation: one core is doing the control transfer, another core is trying to
>>> unregister the USB gadget from userspace, we must wait for completing this
On Mon, Oct 17, 2016 at 08:11:59PM +0900, Masahiro Yamada wrote:
> Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
> needs to handle 4 reset lines for EHCI.
Why? What makes it different from other EHCI implementations?
thanks,
greg k-h
--
To unsubscribe from this list: sen
My Apologies, I never saw my original patch hit the linux-usb mailing
list either, I suspect it may have not been all plain text. (I did not
get a rejection message though). I will resend the original to
linux-usb.
On Mon, Oct 17, 2016 at 5:49 AM, Greg KH wrote:
> On Sun, Oct 16, 2016 at 10:54:34
Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
with 20 ms of slack, after removing slack time some ohci controllers don't
respond in time. Logs from systems with controllers that have the
issue would show "HcDoneHead not written back; disabled"
Signed-off-by: Bryan Paluch
---
R
Hi Greg,
2016-10-17 21:30 GMT+09:00 Greg Kroah-Hartman :
> On Mon, Oct 17, 2016 at 08:11:59PM +0900, Masahiro Yamada wrote:
>> Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
>> needs to handle 4 reset lines for EHCI.
>
> Why? What makes it different from other EHCI impleme
From: Bryan Paluch
> Sent: 17 October 2016 13:55
> Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
> with 20 ms of slack, after removing slack time some ohci controllers don't
> respond in time. Logs from systems with controllers that have the
> issue would show "HcDoneHead not wr
On 13 October 2016 at 13:37, Ulf Hansson wrote:
> The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are interfacing
> an rtsx_usb device (managed by an mfd driver) while communicating with the
> cards. The mmc/sd and memstick devices are children of the usb device.
>
> Issues has been
On Mon, 17 Oct 2016, Felipe Balbi wrote:
> Hi Baolin,
>
> Baolin Wang writes:
> >> Felipe Balbi writes:
> >>> Instead of just delaying for 100us, we should
> >>> actually wait for End Transfer Command Complete
> >>> interrupt before moving on. Note that this should
> >>> only be done if we're d
On Thu, 2016-09-08 at 14:58 +0200, Wim Osterholt wrote:
> On Thu, Sep 08, 2016 at 02:20:38PM +0200, Oliver Neukum wrote:
> > >
> > > The oops tells things that I didn't all write down, but it says
> > > null pointer dereference at 0246
> >
> > That is the important part. I am sorry, but witho
On Thu, Oct 06, 2016 at 06:40:11PM +0200, Stefan Tauner wrote:
> This adds support to ftdi_sio for the Infineon TriBoard TC2X7
> engineering board for first-generation Aurix SoCs with Tricore CPUs.
> Mere addition of the device IDs does the job.
>
> Signed-off-by: Stefan Tauner
Now applied, than
On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> Hi,
>
> I got one of those devices. However, I don't get a crash.
> Could you please give me instructions on how you trigger it?
That's not too hard, just plug it in. :-)
However you must have set cdc_acm in your kernel, or
On Mon, 17 Oct 2016, Ulf Hansson wrote:
> On 13 October 2016 at 13:37, Ulf Hansson wrote:
> > The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are
> > interfacing
> > an rtsx_usb device (managed by an mfd driver) while communicating with the
> > cards. The mmc/sd and memstick devic
From: Rafał Miłecki
Broadcom's Northstar XHCI controllers seem to need a special start
procedure to work correctly. There isn't any official documentation of
this, the problem is that controller doesn't detect any connected
devices with default setup. Moreover connecting USB device to controller
On 10/17/2016 10:30 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Broadcom's Northstar XHCI controllers seem to need a special start
> procedure to work correctly. There isn't any official documentation of
> this, the problem is that controller doesn't detect any connected
> devices with def
On 17 October 2016 at 23:10, Hauke Mehrtens wrote:
> On 10/17/2016 10:30 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> Broadcom's Northstar XHCI controllers seem to need a special start
>> procedure to work correctly. There isn't any official documentation of
>> this, the problem is that
On Monday, October 17, 2016 09:30:59 AM Peter Chen wrote:
> On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> > On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > > Hi all,
> > >
> > > This is a follow-up for my last power sequence framework patch set [1].
> > > Accor
This series reverts patches that incorrectly removed some FIFO
programming.
Hi Felipe,
This fixes a regression on 4.9-rc1, could you queue them in your fixes
tree?
Thanks,
John
v2:
* Added Rob Herring's Acked-by
John Youn (3):
Revert "usb: dwc2: gadget: change variable name to more meaningf
This reverts commit ba48eab8866c ("usb: dwc2: gadget: change variable
name to more meaningful").
This is needed to cleanly revert commit aa381a7259c3 ("usb: dwc2:
gadget: fix TX FIFO size and address initialization") which may cause
regressions on some platforms.
Signed-off-by: John Youn
Cc: Rob
This reverts commit aa381a7259c3 ("usb: dwc2: gadget: fix TX FIFO size
and address initialization").
The original commit removed the FIFO size programming per endpoint. The
DPTXFSIZn register is also used for DIEPTXFn and the SIZE field is r/w
in dedicated fifo mode. So it isn't appropriate to sim
This binding was deprecated due to commit aa381a7259c3 ("usb: dwc2:
gadget: fix TX FIFO size and address initialization"). However that
commit is now reverted, so also revert this commit.
The binding is valid and shouldn't be deprecated.
This reverts commit 65e1ff7f4b5b ("Documentation: devicetre
On Mon, Oct 17, 2016 at 12:51:48PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> > On Mon, Oct 17, 2016 at 11:06:49AM +0300, Felipe Balbi wrote:
> >>
> >> Hi Baolin,
> >>
> >> Baolin Wang writes:
> >> >> Felipe Balbi writes:
> >> >>> Instead of just delaying for 100us, we shoul
On Tue, Oct 18, 2016 at 02:35:38AM +0200, Rafael J. Wysocki wrote:
> On Monday, October 17, 2016 09:30:59 AM Peter Chen wrote:
> > On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> > > On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > > > Hi all,
> > > >
> > > > This
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.
The high-speed phy on qcom SoCs is controlled via the ULPI
viewport.
Cc: Kishon Vijay Abraham I
Cc:
Cc: Rob Herring
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/phy/qcom,usb-hs-phy.txt| 86 +++
drivers/phy/Kconfig| 8 +
drivers/phy/Makefil
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.
Acked-by: Peter Chen
Cc: Greg Kroah-Hartman
Signed-off-by: St
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.
Acked-by: Peter Chen
Cc: Greg Kroah-Hartman
Cc: Hei
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
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 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
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 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
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
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
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
In the case of an extcon-usb-gpio device being used with the
chipidea driver we'll sometimes miss the BSVIS event in the OTGSC
register. Consider the case where we don't have a cable attached
and the id pin is indicating "host" mode. When we plug in the usb
cable for "device" mode a gpio goes high
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 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 HSIC USB controller on qcom SoCs has an integrated all
digital phy controlled via the ULPI viewport.
Cc: Kishon Vijay Abraham I
Acked-by: Rob Herring
Cc:
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/phy/qcom,usb-hsic-phy.txt | 65 +
drivers/phy/Kconfig
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
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
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.
Acked-by: Rob Herring
Cc:
Signed-off-by: Stephen Boyd
---
drivers/of/device.c | 2 ++
1 file changed, 2 insertions(+)
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
Hi,
On 17 October 2016 at 19:53, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>>> Baolin Wang writes:
When we change the USB function with configfs dynamically, we possibly met
this
situation: one core is doing the control transfer, another core is trying
to
un
> -Original Message-
> From: Felipe Balbi [mailto:ba...@kernel.org]
> Sent: Monday, October 17, 2016 5:29 PM
> To: Lipengcheng; Peter Chen
> Cc: gre...@linuxfoundation.org; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Subject: RE: USB GADGET: have a question about usb2eth
Add the following four products of Lenovo and sort the order of the list.
VID PID
0x17ef 0x3062
0x17ef 0x3069
0x17ef 0x720c
0x17ef 0x7214
Signed-off-by: Hayes Wang
---
drivers/net/usb/cdc_ether.c | 28 ++
On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd wrote:
> 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.
>
> Acked-by: Rob Herring
> Cc:
> Signed-off-by: Stephen Boy
68 matches
Mail list logo
