From: Dinh Nguyen
Allow for platforms that have a reset controller driver in place to bring
the USB IP out of reset.
Signed-off-by: Dinh Nguyen
Cc: John Youn
---
drivers/usb/dwc2/core.h |1 +
drivers/usb/dwc2/platform.c | 15 +++
2 files changed, 16 insertions(+)
diff -
endpoint companion for config 1 interface 0 altsetting 1 ep 131:
using minimum values
Mar 27 21:14:18 hydra kernel: [ 104.306485] usb 3-2: New USB device
found, idVendor=0bc2, idProduct=2312
Mar 27 21:14:18 hydra kernel: [ 104.306490] usb 3-2: New USB device
strings: Mfr=1, Product=2, SerialNum
Greg KH writes:
Dear Greg
> > I moved the initialization and clean up code from the init_callback/release
> > callback to the port_init/port_remove callback.
I am referring to your last posting on Feb 25th:
gkh> Release your port data in the port_remove callback, not the release
gkh> callback.
On Sat, 26 Mar 2016, Felipe Balbi wrote:
> Peter Griffin writes:
> > On Fri, 25 Mar 2016, Felipe Balbi wrote:
> >> Gregory CLEMENT writes:
> >> >> Peter Griffin writes:
> >> >>> Otherwise generic-xhci and xhci-platform which have no data get wrongly
> >> >>> detected as XHCI_PLAT_TYPE_MARVELL_AR
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, March 28, 2016 2:52 PM
> To: Peter Chen
> Cc: Felipe Balbi ; Greg KH ;
> Sebastian Reichel ; Dmitry Eremin-Solenikov
> ; David Woodhouse ; Pet
Hi
Thanks Baolu very much!
Because of the reason usb3 module can not be used, it will affect the strong
of usb3 module;
1, the xhci control is suspend and resume, why to re-allocate memory?
2, whether we can allocate memory for more times, so we can avoid the
problem;
Best Regar
coccicheck found this pattern which could be
converted to PTR_ERR_OR_ZERO(). No functional
changes.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/udc/at91_udc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/ud
coccicheck found this pattern which could be
converted to PTR_ERR_OR_ZERO(). No functional
changes.
Signed-off-by: Felipe Balbi
---
drivers/usb/phy/phy-qcom-8x16-usb.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c
b/drivers/usb/phy/p
On 29 March 2016 at 16:45, Jun Li wrote:
>
>
>> -Original Message-
>> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> ow...@vger.kernel.org] On Behalf Of Baolin Wang
>> Sent: Monday, March 28, 2016 2:52 PM
>> To: Peter Chen
>> Cc: Felipe Balbi ; Greg KH ;
>> Sebastian Reichel
On Tue 2016-03-01 22:28:00, Heiner Kallweit wrote:
> Extend brightness sysfs property handling to deal with monochrome
> and color mode as well.
>
> Signed-off-by: Heiner Kallweit
> ---
> v2:
> - split from patch 1
> v3:
> - moved one change (led_is_off) to patch 1
> v4:
> - changed printf format
Hi!
First, please Cc me on RGB color support.
> Add generic support for RGB Color LED's.
>
> Basic idea is to use enum led_brightness also for the hue and saturation
> color components.This allows to implement the color extension w/o
> changes to struct led_classdev.
>
> Select LEDS_RGB to enab
On Tue 2016-03-01 22:36:12, Heiner Kallweit wrote:
> Export a function to convert HSV color values to RGB.
> It's intended to be called by drivers for RGB LEDs.
>
> Signed-off-by: Heiner Kallweit
> ---
> v2:
> - move hsv -> rgb conversion to separate file
> - remove flag LED_DEV_CAP_RGB
> v3:
> -
Now that the code has been refactored enough,
switching over to using ->plat_start() and
->init_quirk() becomes a very simple patch.
After this patch, there are no further uses for
xhci_plat_type_is() which will be removed in a
follow-up patch.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/x
xhci_plat_setup() is the rightful place for
xhci_mvebu_mbus_init_quirk(), so let's move it there
in order to make it simpler to get rid of
xhci_plat_type_is() later on.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-plat.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions
We're preparing to remove xhci_plat_type_is() in
favor of a better approach where we define function
pointers ahead of time. This will let us make
assumptions about which platforms we're running on
and which platform-specific functions we should call.
Signed-off-by: Felipe Balbi
---
drivers/usb/
This 6-patch series gets rid of the pointless
xhci_plat_type_is() in favour of a nicer setup where
we initialize function pointers ahead of time using
driver_data. That way we help the code look a little
cleaner and easier to read.
Felipe Balbi (6):
usb: host: xhci: rcar: retire use of xhci_plat
Just like RCAR's init_quirk() we want mvebu's to use
struct usb_hcd * as argument too. This is another
step towards removing xhci_plat_type_is().
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-mvebu.c | 7 ++-
drivers/usb/host/xhci-mvebu.h | 7 +--
drivers/usb/host/xhci-plat.c |
Now that there are no more users for
xhci_plat_type_is(), we can safely remove it.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-plat.c | 3 ---
drivers/usb/host/xhci-plat.h | 18 --
2 files changed, 21 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/us
these two methods will be used to hide
platform-specific details so we can get rid of
xhci_plat_type_is() in a later patch.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-plat.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.h b/drivers/usb/host/xhci-plat
Hi,
"Felipe F. Tonello" writes:
> [ text/plain ]
> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
> devices.
>
> That caused the OUT endpoint to freeze if the host send any data packet of
> length greater than 256 bytes.
>
> This is an example dump of what happended o
Dmitry Osipenko writes:
> udc->softconnect should be set regardless of the VBUS state, otherwise
> the USB peripheral device, connected during suspend, won't be detected
> since can_pullup() would return false and the UDC won't be enabled.
>
> Fixes: 252455c40316 (usb: gadget: fsl driver pullup fi
Hi Greg
This fixes the regression seen in 4.6-rc2 with USB 3.0 devices.
http://marc.info/?l=linux-usb&m=145920036421563&w=2
The first version was sent to usb-next. I failed however to respond to Alans
comments and couldn't make it in time for 4.6-rc1.
This version incudes the changes he proposed.
commit b37d83a6a414 ("usb: Parse the new USB 3.1 SuperSpeedPlus Isoc
endpoint companion descriptor") caused a regression in 4.6-rc1 and fails
to parse SuperSpeed endpoint companion descriptors.
The new SuperSpeedPlus Isoc endpoint companion parsing code incorrectly
decreased the the remaining buff
29.03.2016 13:31, Felipe Balbi пишет:
Dmitry Osipenko writes:
udc->softconnect should be set regardless of the VBUS state, otherwise
the USB peripheral device, connected during suspend, won't be detected
since can_pullup() would return false and the UDC won't be enabled.
Fixes: 252455c40316 (u
Dmitry Osipenko writes:
> 29.03.2016 13:31, Felipe Balbi пишет:
>> Dmitry Osipenko writes:
>>> udc->softconnect should be set regardless of the VBUS state, otherwise
>>> the USB peripheral device, connected during suspend, won't be detected
>>> since can_pullup() would return false and the UDC wo
Hello.
On 3/29/2016 1:47 PM, Mathias Nyman wrote:
commit b37d83a6a414 ("usb: Parse the new USB 3.1 SuperSpeedPlus Isoc
endpoint companion descriptor") caused a regression in 4.6-rc1 and fails
to parse SuperSpeed endpoint companion descriptors.
The new SuperSpeedPlus Isoc endpoint companion par
On 29.03.2016 14:21, Sergei Shtylyov wrote:
Hello.
On 3/29/2016 1:47 PM, Mathias Nyman wrote:
commit b37d83a6a414 ("usb: Parse the new USB 3.1 SuperSpeedPlus Isoc
endpoint companion descriptor") caused a regression in 4.6-rc1 and fails
to parse SuperSpeed endpoint companion descriptors.
The n
Le 29/03/2016 11:28, Felipe Balbi a écrit :
> coccicheck found this pattern which could be
> converted to PTR_ERR_OR_ZERO(). No functional
> changes.
>
> Signed-off-by: Felipe Balbi
Acked-by: Nicolas Ferre
Thanks Felipe for having taken care of this!
Bye,
> ---
> drivers/usb/gadget/udc/at91
Hello,
> 4.5.0+, which patches do you have on top of 4.5 vanilla ?
No code patches, just the configuration and dts file for the board.
> Also, can you try this patch:
I tried it, but the result is the same.
Sometimes I can see another entry in the log:
g_serial gadget: suspend
And there is a
Hi,
On Fri, Mar 18, 2016 at 08:59:48AM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Bin Liu writes:
> > [ text/plain ]
> > Hi,
> >
> > On Fri, Mar 11, 2016 at 6:54 AM, Felipe Balbi
> > wrote:
> >> previously we were using a maximum of 32 TRBs per
> >> endpoint. With each TRB being 16 bytes long, we
On 29.03.2016 11:33, Mathias Nyman wrote:
endpoint companion for config 1 interface 0 altsetting 1 ep 131:
using minimum values
Mar 27 21:14:18 hydra kernel: [ 104.306485] usb 3-2: New USB device
found, idVendor=0bc2, idProduct=2312
Mar 27 21:14:18 hydra kernel: [ 104.306490] usb 3-2: New USB
On Tue, Mar 29, 2016 at 09:01:43AM +, tilman wrote:
> Greg KH writes:
>
> Dear Greg
>
> > > I moved the initialization and clean up code from the
> > > init_callback/release
> > > callback to the port_init/port_remove callback.
>
> I am referring to your last posting on Feb 25th:
> gkh> Re
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of tilman
> Sent: Tuesday, March 29, 2016 04:02
> To: linux-usb@vger.kernel.org
> Subject: Re: driver migration
>
> Greg KH writes:
>
> Dear Greg
>
> > > I moved the initia
Hi Thierry
On Fri, 2016-03-04 at 17:19 +0100, Thierry Reding wrote:
> From: Thierry Reding >
>
> The NVIDIA Tegra XUSB pad controller provides a set of pads, each
> with a
> set of lanes that are used for PCIe, SATA and USB.
I finally got around trying this both on Jetson TK1 as well as our own
Hi I made a bug report on bugzilla and was told to forward it to this email.
Please see this thread: https://bbs.archlinux.org/viewtopic.php?id=210446
for current information related to the problem.
To summarise:
Works in windows and also bios/arch options menu but stops working when system
l
This patch series includes v5 of a patch to provide GPIO support for cp210x. I
have also included a patch to add the vendor/device ID for the GE Healthcare
Remote Alarm Box, which uses this chip.
Martyn Welch (2):
USB: serial: cp210x: Adding GPIO support for CP2105
USB: serial: cp210x: Adding
This patch adds support for the GPIO found on the CP2105. Unlike the GPIO
provided by some of the other devices supported by the cp210x driver, the
GPIO on the CP2015 is muxed on pins otherwise used for serial control
lines. The GPIO have been configured in 2 separate banks as the choice to
configu
The CP2105 is used in the GE Healthcare Remote Alarm Box, with the
Manufacturer ID of 0x1901 and Product ID of 0x0194.
Signed-off-by: Martyn Welch
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index b
On Tue, Mar 29, 2016 at 05:24:59PM +0200, Marcel Ziswiler wrote:
> Hi Thierry
>
> On Fri, 2016-03-04 at 17:19 +0100, Thierry Reding wrote:
> > From: Thierry Reding > >
> >
> > The NVIDIA Tegra XUSB pad controller provides a set of pads, each
> > with a
> > set of lanes that are used for PCIe, SA
On 28.03.2016 09:13, Rajesh Bhagat wrote:
-Original Message-
From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]
Sent: Wednesday, March 23, 2016 7:52 PM
To: Rajesh Bhagat
Cc: gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux-
ker...@vger.kernel.org; Sriram Dash
Subj
On Tue, Mar 29, 2016 at 10:05:23AM +0800, Baolin Wang wrote:
> Yes, The user 'wm831x_power' did not implement any callbacks in
> 'usb_charger_detect_type()' function, but in
> 'usb_charger_detect_type()' function it just supplies different
> callbacks to get the charger type with simple logic. Any
On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote:
> On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote:
> > > I am afraid I still not find the user (udc driver) for this framework, I
> > > would
> > > like to see how udc driver block the enumeration until the charger
> > > det
//adding cc to linux-usb ml
2016-03-29 7:55 GMT+03:00 Peter Chen :
> Would you please try below patch to see if it works for you:
With the patch applied the code enters "ci_udc_vbus_session", but too early,
before the gadget driver is loaded - during the probe of ci_hdrc. This
means that
"ci->dri
Am 29.03.2016 um 12:02 schrieb Pavel Machek:
> Hi!
>
> First, please Cc me on RGB color support.
>
>> Add generic support for RGB Color LED's.
>>
>> Basic idea is to use enum led_brightness also for the hue and saturation
>> color components.This allows to implement the color extension w/o
>> cha
Am 29.03.2016 um 12:05 schrieb Pavel Machek:
> On Tue 2016-03-01 22:36:12, Heiner Kallweit wrote:
>> Export a function to convert HSV color values to RGB.
>> It's intended to be called by drivers for RGB LEDs.
>>
>> Signed-off-by: Heiner Kallweit
>> ---
>> v2:
>> - move hsv -> rgb conversion to se
Hi!
> > First, please Cc me on RGB color support.
> >
> >> Add generic support for RGB Color LED's.
> >>
> >> Basic idea is to use enum led_brightness also for the hue and saturation
> >> color components.This allows to implement the color extension w/o
> >> changes to struct led_classdev.
> >>
>
Hi!
> > One driver for this extension was the idea of triggers using color
> > to visualize states etc.
> > Therefore it's not only about userspace controlling the color.
> > As a trigger is bound to a led_classdev we need a led_classdev
> > representing a RGB LED device.
> >
> > And ok: If requi
I'd been using kernel 3.18.10-29 on a set of Beaglebone Black boards, and had
found and corrected this on my local build tree.
Kernel build fails when the source file drivers/usb/musb/musb_cppi41.c is
built, with these kernel options enabled:
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_TI_CPPI41_DMA=y
T
Hi,
On 03/29/2016 05:17 PM, Lipengcheng wrote:
> Hi
>Thanks Baolu very much!
>Because of the reason usb3 module can not be used, it will affect the
> strong of usb3 module;
> 1, the xhci control is suspend and resume, why to re-allocate memory?
Some controllers need to set XHCI_RE
On Tue, Mar 29, 2016 at 10:15:41PM +0300, Светослав Нейков wrote:
> //adding cc to linux-usb ml
>
> 2016-03-29 7:55 GMT+03:00 Peter Chen :
> > Would you please try below patch to see if it works for you:
>
> With the patch applied the code enters "ci_udc_vbus_session", but too early,
> before the
On Tue, Mar 29, 2016 at 05:42:50PM +0100, reggie macdonald wrote:
> Hi I made a bug report on bugzilla and was told to forward it to this email.
>
> Please see this thread: https://bbs.archlinux.org/viewtopic.php?id=210446
>
> for current information related to the problem.
>
> To summarise:
>
On Tue, Mar 29, 2016 at 10:23:14AM -0700, Mark Brown wrote:
> On Mon, Mar 28, 2016 at 03:13:51PM +0800, Peter Chen wrote:
> > On Mon, Mar 28, 2016 at 02:51:40PM +0800, Baolin Wang wrote:
>
> > > > I am afraid I still not find the user (udc driver) for this framework,
> > > > I would
> > > > like
> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Tuesday, March 29, 2016 5:49 PM
> To: Jun Li
> Cc: Peter Chen ; Felipe Balbi ;
> Greg KH ; Sebastian Reichel ;
> Dmitry Eremin-Solenikov ; David Woodhouse
> ; Peter Chen ; Alan Stern
> ; r.bald...@samsung.co
Hi,
> The ohci-platform and ehci-platform drivers already perform their own
root-hub and bus resets.
I don't understand the sentence clearly.
Synopsis control VERSION： DesignWare Cores USB2.0 Host-AHB Controller, Version
2.98a
The synopsis has the three source clocks for EHCI Host Controller
Hi Felipe,
Thank you for the patch!
> Sent: Tuesday, March 29, 2016 7:11 PM
< snip >
> static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen2 = {
> .type = XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2,
> .firmware_name = XHCI_RCAR_FIRMWARE_NAME_V1,
> + .init_quirk = xhci_rcar_init_qu
Am 29.03.2016 um 23:43 schrieb Pavel Machek:
> Hi!
>
>>> First, please Cc me on RGB color support.
>>>
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation
color components.This allows to implement the color extension
Yoshihiro Shimoda writes:
> [ text/plain ]
> Hi Felipe,
>
> Thank you for the patch!
hey, no problem :-)
>> Sent: Tuesday, March 29, 2016 7:11 PM
> < snip >
>> static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen2 = {
>> .type = XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2,
>> .firmware_
Hi,
Bin Liu writes:
> On Fri, Mar 18, 2016 at 08:59:48AM +0200, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Bin Liu writes:
>> > [ text/plain ]
>> > Hi,
>> >
>> > On Fri, Mar 11, 2016 at 6:54 AM, Felipe Balbi
>> > wrote:
>> >> previously we were using a maximum of 32 TRBs per
>> >> endpoint. With ea
On 30 March 2016 at 10:54, Jun Li wrote:
>> >> It is not for udc driver but for power users who want to negotiate
>> >> with USB subsystem.
>> >>
>> >
>> > Seems you don't want to guarantee charger type detection is done
>> > before gadget connection(pullup DP), right?
>> > I see you call usb_char
Hi again,
Felipe Balbi writes:
> Bin Liu writes:
>> On Fri, Mar 18, 2016 at 08:59:48AM +0200, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Bin Liu writes:
>>> > [ text/plain ]
>>> > Hi,
>>> >
>>> > On Fri, Mar 11, 2016 at 6:54 AM, Felipe Balbi
>>> > wrote:
>>> >> previously we were using a maxim
Hello Peter,
On 16-03-29 00:24:46, Peter Chen wrote:
>
> >
> > On 2016-03-25 00:40, Peter Chen wrote:
> > > On Tue, Mar 15, 2016 at 02:08:26PM +0530, Sanchayan Maity wrote:
> > >> Hello Peter,
> > >>
> > >> The existing usage of extcon in Chipidea driver relies on OTG
> > >> registers. In case
JB writes:
> Hello,
>
>> 4.5.0+, which patches do you have on top of 4.5 vanilla ?
>
> No code patches, just the configuration and dts file for the board.
>
>> Also, can you try this patch:
>
> I tried it, but the result is the same.
>
> Sometimes I can see another entry in the log:
>
> g_serial g
62 matches
Mail list logo
