On 29 January 2018 at 09:44, Mika Westerberg
wrote:
> On Sat, Jan 27, 2018 at 01:31:00PM +, Mike Lothian wrote:
>> On 26 January 2018 at 09:53, Mike Lothian wrote:
>> > On 26 January 2018 at 08:31, Mika Westerberg
>> > wrote:
>> >> On Fri, Jan 26, 2018 at 08:07:56AM +, Mike Lothian wrote
On Sun, Feb 11, 2018 at 06:59:52PM +, Mike Lothian wrote:
> This a final patch ever get sent out?
I'll send it out tomorrow once merge window is closed.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo
It is hard to say what is wrong. I would start with reading the uhid /
hid code and see where you are getting stuck (and double check uhid
docs). Even for others we would need to do that as it is not easy to
see what is wrong.
I'm not sure what your goal is obvious you want to simulate a keyboard
On Tue, Feb 6, 2018 at 8:55 AM, Felipe Balbi
wrote:
>
> Hi,
>
> Ran Shalit writes:
>> Hello,
>>
>> I check code in:
>> https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c
>> but I see no API usage of DMA, yet it is being mentioned as if it is used.
>
> but it i
On Sun, Feb 11, 2018 at 1:46 PM, Roderick Colenbrander
wrote:
> It is hard to say what is wrong. I would start with reading the uhid /
> hid code and see where you are getting stuck (and double check uhid
> docs). Even for others we would need to do that as it is not easy to
> see what is wrong.
>
The goal of this series is to initialize multiple PHYs on a USB host
controller, which is needed on Amlogic Meson GXL and GXM SoCs.
- Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two
or three USB2 ports enabled on the internal root-hub. The SoCs also
provide separate USB2
Many SoC platforms have separate devices for the USB PHY which are
registered through the generic PHY framework. These PHYs have to be
enabled to make the USB controller actually work. They also have to be
disabled again on shutdown/suspend.
Currently (at least) the following HCI platform drivers
With the new PHY wrapper in place we can now handle multiple PHYs.
Remove the code which handles only one generic PHY as this is now
covered (with support for multiple PHYs as well as suspend/resume
support) by the new PHY wrapper.
Signed-off-by: Martin Blumenstingl
---
drivers/usb/core/hcd.c |
The USB HCD core driver parses the device-tree node for "phys" and
"usb-phys" properties. It also manages the power state of these PHYs
automatically.
However, drivers may opt-out of this behavior by setting "phy" or
"usb_phy" in struct usb_hcd to a non-null value. An example where this
is required
The new PHY wrapper is now wired up in the core HCD code. This means
that PHYs are now controlled (initialized, enabled, disabled, exited)
without requiring any host-driver specific code.
Remove the custom USB PHY handling from the ehci-platform driver as the
core HCD code now handles this.
Signed
The new PHY wrapper is now wired up in the core HCD code. This means
that PHYs are now controlled (initialized, enabled, disabled, exited)
without requiring any host-driver specific code.
Remove the custom USB PHY handling from the ohci-platform driver as the
core HCD code now handles this.
Signed
This integrates the PHY wrapper into the core hcd infrastructure.
Multiple PHYs which are part of the HCD's device tree node are now
managed (= powered on/off when needed), by the new usb_phy_roothub code.
Suspend and resume is also supported, however not for
runtime/auto-suspend (which is trigger
The new PHY wrapper is now wired up in the core HCD code. This means
that PHYs are now controlled (initialized, enabled, disabled, exited)
without requiring any host-driver specific code.
Remove the custom USB PHY handling from the xhci-mtk driver as the core
HCD code now handles this.
Signed-off-
A USB HCD may have several PHYs which need to be configured before the
the HCD starts working.
This adds the documentation for such a USB HCD as well as a reference to
the new "usb-hcd.txt" from all bindings that implement a USB HCD which
support one USB PHY per port.
Signed-off-by: Martin Blumens
Amlogic Meson GX SoCs (GXL and AXG) come with a (host-only) dwc3 USB
controller. This requires a clock to be enabled and a reset line to be
pulsed to get the hardware into a known state.
Add the documentation for this IP block, similar to "qcom,dwc3.txt".
Signed-off-by: Martin Blumenstingl
Review
Amlogic Meson AXG and GXL SoCs can use the dwc3-of-simple with little
modifications. These SoCs use:
- a gate clock for the USB components (DWC3, USB PHYs)
- a reset line which is shared across all USB components (DWC3, USB2 and
USB3 PHYs, OTG detection logic inside the USB3 PHY registers)
- a re
Amlogic Meson GXL and AXG SoCs come with a (host-only) dwc3 USB
controller. To use this controller a clock has to be enabled and a reset
line has to be pulsed.
Enabling the clock works identical to other SoCs. However, the reset
line has to be pulsed (using reset_control_reset) instead of using a
l
Some SoCs (such as Amlogic Meson GXL for example) share the reset line
with other components (in case of the Meson GXL example there's a shared
reset line between the USB2 PHYs, USB3 PHYs and the dwc3 controller).
Additionally SoC implementations may prefer a reset pulse over level
resets.
For now
Clang reports the following warning:
drivers/usb/gadget/udc/fsl_udc_core.c:1312:10: warning: address of array
'ep->name' will always evaluate to 'true' [-Wpointer-bool-conversion]
if (ep->name)
~~ ^~~~
It seems that the authors intention was to check if the ep has been
con
The local variable event is of type enum usb_phy_events. Use
the same enum value USB_EVENT_NONE instead of UX500_MUSB_NONE.
This avoids a warning when building with clang:
drivers/usb/phy/phy-ab8500-usb.c:906:30: warning: implicit conversion from
enumeration type 'enum ux500_musb_vbus_id_statu
mxs_charger_secondary_detection() is only used in this file, so make
it static.
This fixes the following sparse warning:
drivers/usb/phy/phy-mxs-usb.c:581:23: warning: symbol
'mxs_charger_secondary_detection' was not declared. Should it be static?
Signed-off-by: Fabio Estevam
---
drivers/usb/
From: Fabio Estevam
mxs_charger_secondary_detection() is only used in this file, so make
it static.
This fixes the following sparse warning:
drivers/usb/phy/phy-mxs-usb.c:581:23: warning: symbol
'mxs_charger_secondary_detection' was not declared. Should it be static?
Signed-off-by: Fabio Este
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年2月12日 10:24
> To: ba...@kernel.org
> Cc: Peter Chen ; linux-usb@vger.kernel.org; Jun Li
> ; Fabio Estevam
> Subject: [PATCH v2] usb: phy: mxs: Staticize
> mxs_charger_secondary_detection()
>
> From: Fabio
On Fri, Feb 09, 2018 at 12:25:44PM -0800, The Real Bev wrote:
> On 02/09/2018 05:13 AM, Greg KH wrote:
> > On Thu, Feb 08, 2018 at 01:00:02PM -0800, The Real Bev wrote:
> > > I think I have found a bug in the linux kernel 4.9.79. The problem
> > > is in the performance of the driver for the Renesas
2018-02-10 1:00 GMT+01:00 Chris Murphy :
> On Fri, Feb 9, 2018 at 3:57 AM, Menion wrote:
>> There are multiple reports of UAS issue together with JMS567 (from myself
>> also)
>> Question: you mentioned that connecting the enclosure to an
>> intermediate USB HUB is a workaround.
>> Can you specify
25 matches
Mail list logo
