Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[Heiner Kallweit]

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 w/o
 changes to struct led_classdev.

 Select LEDS_RGB to enable building drivers using the RGB extension.

 Flag LED_SET_HUE_SAT allows to specify that hue / saturation
 should be overridden even if the provided values are zero.

 Some examples for writing values to /sys/class/leds//brightness:
 (now also hex notation can be used)

 255 -> set full brightness and keep existing color if set
 0 -> switch LED off but keep existing color so that it can be restored
  if the LED is switched on again later
 0x100 -> switch LED off and set also hue and saturation to 0
 0x00 -> set full brightness, full saturation and set hue to 0
 (red)
>>>
>>> Umm, that's rather strange interface -- and three values in single sysfs
>>> file is actually forbidden.
>>>
>>> Plus, it is very much unlike existing interfaces for RGB LEDs, which
>>> we already have supported in the tree. (At least nokia N900 and Sony
>>> motion controller already contain supported three-color LEDs).
>>>
>>> Now... yes, there's work to be done for the 3-color LEDs. Currently,
>>> they are treated as three different LEDs. (Which makes some sense, you
>>> can use "battery charging" trigger for LED, and CPU activity trigger
>>> for green, for example). It would be good to have some kind of
>>> grouping, so that userspace can tell "these 3 leds are actually
>>> combined into one light".
>>>
>> At first thanks for the review comments.
>> Treating the three physical LEDs of a RGB LED as separate LED devices
>> might have been implemented due to the lack of alternatives.
> 
> To be fair... they _are_ separate LED devices. In N900 case, you can
> even see light comming from slightly different places if you look closely.
> 
I mainly work with encapsulated USB HID LED devices like Thingm blink(1).
Due to the diffuse plastic cover you don't see the individual LEDs on the chip.

>> With one trigger controlling the red LED and another controlling the green
>> LED we may end up with a yellow light. Not sure whether this is what
>> we want.
> 
> Well, it should be understandable for most people.
> 
>> 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 required the sysfs interface can be splitted into separate
>> attributes for hue, saturation, and (existing) brightness.
> 
> Required.
> 
> Ok, so:
> 
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?
> 
> b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> and it is what hardware implements. (But we'd need to do gamma
> correction).
> 
HSV has the charme that the current monochrome V-only is a subset.
Therefore the current API can be used also with color LEDs.
However there might be good reasons for using RGB too.

> c) My hardware has "acceleration engine", LED is independend from
> CPU. That's rather big deal. Does yours? It seems to be quite common,
> at least in cellphones.
> 
Devices like blink(1) support storing and re-playing patterns, fading etc.

> Ideally, I'd like to have "triggers", but different ones. As in: if
> charging, do yellow " .xX" pattern. If fully charged, do green steady
> light. If message is waiting, do blue " x x" pattern. If none of
> above, do slow white blinking. (Plus priorities of events). But that's
> quite different from existing support...)
> 
I think for this a separate layer would be helpful.
Your primary intention is to e.g. display "charging" on the RGB LED
device. Most likely you don't want to split yellow into its red + green
component and then write to the respective (sub-)LEDs.
Also just think of the case that later you might decide that orange
is nicer than yellow.

>   Pavel
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 5/6] usb: host: xhci: plat: make use of new methods in xhci_plat_priv

[Yoshihiro Shimoda]

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_quirk,
>  };

I should have said explicitly before, but the xhci_plat_renesas_rcar_gen2
also needs ".plat_start = xhci_rcar_start" like the variable of gen3.

< Full code of " xhci_plat_renesas_rcar_gen2" >
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_quirk,
.plat_start = xhci_rcar_start,
};

Best regards,
Yoshihiro Shimoda

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ehci and ohci reset number doubt

[Lipengcheng]

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 
implementation:
A, System (AHB BIU) Clock
B, PHY Clock(BUS clock)
C, UTMI PHY Clock(per port)

A clock corresponding to a reset, so the ehci control should have the same 
number reset. We are ready to put the utmi phy clock and utmi reset into the 
phy module. The ehci-platform is on the lack of a reset number.
Clock and reset detail:
Signal Description
ehci_hclk_i EHCI AHB System Clock
Function: The EHCI AHB System clock 
supports 30- to 166- MHz 
operation and has been tested at 
40/50/60 MHz in FPGA technology. All 
signal timings are related to the 
rising edge of ehci_hclk_i. The EHCI 
System Clock runs off this clock. For 
correct synchronization between the 
AHB and UTMI, the minimum required AHB 
frequency is 30 MHz.
This clock is valid only if "Dedicated 
AHB interface for EHCI and OHCI" is 
Selected

ehci_hreset_i_n EHCI System Reset
Function: This active-low, synchronous 
or asynchronous (depending on the
configuration) reset serves as power-on 
reset and resets all the EHCI 
control signals.
This signal is active only  if 
"Dedicated AHB interface for EHCI and OHCI" is 
selected

Phy_clk_i  Local EHCI PHY Clock
Function: This free-running clock 
provides an operating frequency in the 
Root Hub for clocking receive and 
transmit parallel data.

phy_rst_i_n Power-on Reset
Function: This signal is synchronous 
(asynchronous, if ASYNC reset option 
selected) to phy_clk_i, and resets all 
registers and state machines in receive 
and transmit logic.

Best regards,
Pengcheng Li

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Friday, March 18, 2016 1:52 AM
> To: Lipengcheng
> Cc: ba...@ti.com; chasemetzge...@gmail.com; baolu...@linux.intel.com; 
> mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com;
> robert.schlabb...@gmx.net; linux-usb@vger.kernel.org
> Subject: Re: ehci and ohci reset number doubt
> 
> On Thu, 17 Mar 2016, Lipengcheng wrote:
> 
> > Hi,
> >In the files of ohci-platform.c and ehci-platform.c, they have only a 
> > control reset. Can the files have one more controller reset?
> 
> Currently only one reset is allowed.
> 
> >Our usb2 controller using a synopsis, need bus reset, root hub reset, 
> > utmi reset. The usb controller of reset and clock have the same
> number.
> 
> If your platform has a Synopsis (now DesignWare) USB2 controller, why not use 
> the dwc2 driver that's already in the kernel?
> 
> The ohci-platform and ehci-platform drivers already perform their own 
> root-hub and bus resets.  They do not perform a UTMI reset, but they
> do call phy_init() and phy_power_on().  Will that be good enough for you?
> 
> Alan Stern

RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -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.com; Yoshihiro Shimoda
> ; Lee Jones ; Mark
> Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML  ker...@vger.kernel.org>
> Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> 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 ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; Peter Chen ; Alan
> >> Stern ; r.bald...@samsung.com; Yoshihiro
> >> Shimoda ; Lee Jones
> >> ; Mark Brown ; Charles
> >> Keepax ;
> >> patc...@opensource.wolfsonmicro.com;
> >> Linux PM list ; USB
> >> ;
> >> device-mainlin...@lists.linuxfoundation.org; LKML  >> ker...@vger.kernel.org>
> >> Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 25 March 2016 at 15:09, Peter Chen  wrote:
> >> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb charger, which is pending testing. Moreover there may be other
> >> >> potential users will use it in future.
> >> >>
> >> >
> >> > 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 detection has finished, or am I missing something?
> >>
> >> 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_charger_detect_type() in each gadget usb state
> changes.
> 
> I am not sure I get your point correctly, please correct me if I
> misunderstand you.
> We need to check the charger type at every event comes from the usb gadget
> state changes or the extcon device state changes, which means a new
> charger plugin or pullup.
> 

According to usb charger spec, my understanding is you can't do real charger
detection procedure *after* gadget _connection_(pullup DP), also I don't
think it's necessary to check charger type at every event from usb gadget.
Something in gadget driver you can utilize is only vbus detection, and
report diff current by diff usb state if it's a SDP.

> >
> > Li Jun
> >> >
> >> > --
> >> > Best Regards,
> >> > Peter Chen
> >>
> >>
> >>
> >> --
> >> Baolin.wang
> >> Best Regards
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-usb"
> >> in the body of a message to majord...@vger.kernel.org More majordomo
> >> info at http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> --
> Baolin.wang
> Best Regards

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Peter Chen]

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 to see how udc driver block the enumeration until the charger 
> > > > detection
> > > > has finished, or am I missing something?
> 
> > > It is not for udc driver but for power users who want to negotiate
> > > with USB subsystem.
> 
> > Then, where is the code the test user to decide what kinds of USB charger
> > (SDP, CDP, DCP) is connecting now?
> 
> Even without detection of CDP and DCP we have configurability within SDP
> - there's the 2.5mA suspended limit, the 100mA default limit and the
> higher 500mA limit which can be negotiated.

Well, things may be a little complicated.

- First, how to design get_charger_type for each udc driver?
Since the charger detection process affects dp/dm signal, it can't be done
during the enumeration or after that. So, the detection process can be only
done after vbus has detected and before udc pull up dp.

Then, when the get_charger_type do real charger detection? My suggestion is,
if the charger type is unknown, we do real one, else, we just return the
stored type value.

- Second, When to notify charger IC to charger:
For SDP and CDP, it needs to notify charger IC after set configuration
has finished.
For DCP (and ACA, I am not sure), can notify charger IC after charger
detection has finished or later.

So, when we get charger is present, we need to notify charger IC at once
for DCP (and ACA); But for SDP and CDP, we need to let the gadget
composite core to notify charger IC after set configuration has finished,
like the patch 2/4 does.

- Third, since composite driver covers 500mA (and more for CDP) after set
configuration and 2mA after suspend, and vbus handler covers connect
and disconnect. I can't see any reasons we need to notify gadget state
for power driver, do we really need to have usb_charger_plug_by_gadget?

-- 
Best Regards,
eter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Usb point of sale keyboard shows err 19 of hub has too many ports

[Greg KH]

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:
>  
> Works in windows and also bios/arch options menu but stops working when 
> system loads with error message of hub has too many ports.
>   --

If your device says it has too many ports, there's not much we can do
about it in Linux, right?  I suggest buying a new keyboard, it's going
to be much cheaper in the end.

good luck!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Chipidea in device mode & VBUS

[Peter Chen]

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 gadget driver is loaded - during the probe of ci_hdrc. This
> means that
> "ci->driver" is null, so it doesn't enter the gadget_active section.
> 

When the gadget driver is loaded, it will call ci_udc_start, and the udc
will be initialized as device mode and pull dp up, in that case, the
host will find the port connection. The purpose for this design is just
to set ci->vbus_active as true for your situation.

If you find it can't work, there are may be something wrong at other
places, eg, the gadget driver is not loaded successfully. Would you
please help to check more?

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem

[Lu Baolu]

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_RESET_ON_RESUME quirk.
With this quirk bit set, host will be reset and reinitialized during
resuming.

> 2, whether we can allocate memory for more times, so we can avoid the 
> problem;

Sorry. I didn't get your point.

Best regards,
Baolu

>
> Best Regards,
> Pengcheng Li
>
>
>> -Original Message-
>> From: Lu Baolu [mailto:baolu...@linux.intel.com]
>> Sent: Friday, March 25, 2016 10:19 PM
>> To: Lipengcheng; Mathias Nyman; gre...@linuxfoundation.org
>> Cc: st...@rowland.harvard.edu; ba...@ti.com; chasemetzge...@gmail.com; 
>> mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com;
>> robert.schlabb...@gmx.net; linux-usb@vger.kernel.org
>> Subject: Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
>>
>> Hi,
>>
>> On 03/25/2016 03:39 PM, Lipengcheng wrote:
>>> Hi,
>>>Thanks Baolu very much!
>>>The kernel is 3.10.Before the problem is inevitable emergence. But we 
>>> fix patch number:b630d4b9d05ba2e66878ca4614946d0f950d4111
>> and your suggest.
>>> Then we resume and suspend the seventh and it is ok only if the usb3 can 
>>> not work. So the changes are effective.
>> Thanks for testing.
>>
>>>In the wrong state which the usb3 can not work, we continue to suspend 
>>> and resume. It will be core dump. Should it be a normal
>> phenomenon?
>>
>> dpm_run_callback(): platform_pm_resume+0x0/0x5c returns -12
>> PM: Device hiusb-xhci.0 failed to resume: error -12
>>
>>
>> Your xHCI host controller failed to resume. As the result, your usb3 devices 
>> should not work. You couldn't suspend it once more either.
>>
>> Best Regards,
>> Baolu

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[Pavel Machek]

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 required the sysfs interface can be splitted into separate
> > attributes for hue, saturation, and (existing) brightness.
> 
> Required.
> 
> Ok, so:
> 
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?

And subquestion: if using existing subsystem, should the RGB led be
one led, or three?

Kernel currently uses three leds for one RGB led, and even before
that, there were leds such as "charging::yellow", "charging::green"
that were as close as leds in RGB module are.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[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
> >> changes to struct led_classdev.
> >>
> >> Select LEDS_RGB to enable building drivers using the RGB extension.
> >>
> >> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
> >> should be overridden even if the provided values are zero.
> >>
> >> Some examples for writing values to /sys/class/leds//brightness:
> >> (now also hex notation can be used)
> >>
> >> 255 -> set full brightness and keep existing color if set
> >> 0 -> switch LED off but keep existing color so that it can be restored
> >>  if the LED is switched on again later
> >> 0x100 -> switch LED off and set also hue and saturation to 0
> >> 0x00 -> set full brightness, full saturation and set hue to 0
> >> (red)
> > 
> > Umm, that's rather strange interface -- and three values in single sysfs
> > file is actually forbidden.
> > 
> > Plus, it is very much unlike existing interfaces for RGB LEDs, which
> > we already have supported in the tree. (At least nokia N900 and Sony
> > motion controller already contain supported three-color LEDs).
> > 
> > Now... yes, there's work to be done for the 3-color LEDs. Currently,
> > they are treated as three different LEDs. (Which makes some sense, you
> > can use "battery charging" trigger for LED, and CPU activity trigger
> > for green, for example). It would be good to have some kind of
> > grouping, so that userspace can tell "these 3 leds are actually
> > combined into one light".
> > 
> At first thanks for the review comments.
> Treating the three physical LEDs of a RGB LED as separate LED devices
> might have been implemented due to the lack of alternatives.

To be fair... they _are_ separate LED devices. In N900 case, you can
even see light comming from slightly different places if you look closely.

> With one trigger controlling the red LED and another controlling the green
> LED we may end up with a yellow light. Not sure whether this is what
> we want.

Well, it should be understandable for most people.

> 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 required the sysfs interface can be splitted into separate
> attributes for hue, saturation, and (existing) brightness.

Required.

Ok, so:

a) Do we want RGB leds to be handled by existing subsystem, or do we
need separate layer on top of that?

b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
and it is what hardware implements. (But we'd need to do gamma
correction).

c) My hardware has "acceleration engine", LED is independend from
CPU. That's rather big deal. Does yours? It seems to be quite common,
at least in cellphones.

Ideally, I'd like to have "triggers", but different ones. As in: if
charging, do yellow " .xX" pattern. If fully charged, do green steady
light. If message is waiting, do blue " x x" pattern. If none of
above, do slow white blinking. (Plus priorities of events). But that's
quite different from existing support...)

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

[Heiner Kallweit]

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 separate file
>> - remove flag LED_DEV_CAP_RGB
>> v3:
>> - call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
>>   This is needed in cases when we have monochrome and color LEDs
>>   as well in a system.
>> v4:
>> - Export led_hsv_to_rgb and let the device driver call it instead
>>   of doing the conversion in the core
>> v5:
>> - don't ignore led_cdev->brightness_get silently if LED_DEV_CAP_RGB
>>   is set but warn
>> ---
>>  drivers/leds/led-class.c|  7 +++
>>  drivers/leds/led-rgb-core.c | 36 
>>  include/linux/leds.h|  8 
>>  3 files changed, 51 insertions(+)
>>
>> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
>> index 8a3748a..a4b144e 100644
>> --- a/drivers/leds/led-class.c
>> +++ b/drivers/leds/led-class.c
>> @@ -193,6 +193,13 @@ int led_classdev_register(struct device *parent, struct 
>> led_classdev *led_cdev)
>>  char name[64];
>>  int ret;
>>  
>> +/*
>> + * for now reading back the color is not supported as multiple
>> + * HSV -> RGB -> HSV conversions may distort the color due to
>> + * rounding issues in the conversion algorithm
>> + */
>> +WARN_ON(led_cdev->flags & LED_DEV_CAP_RGB && led_cdev->brightness_get);
>> +
> 
> Backtrace is useless here, you may want to add some ()s and you don't
> really want user to be causing messages in syslog this easily.
> 
I agree that the backtrace doesn't provide a benefit here.

However I don't see how a user could create syslog entries.
The warn condition can be true only for drivers implementing the RGB extension
in a not supported way (by setting flag LED_DEV_CAP_RGB and implementing
brightness_get).

Pavel
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Mark Brown]

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 
> > > detection
> > > has finished, or am I missing something?

> > It is not for udc driver but for power users who want to negotiate
> > with USB subsystem.

> Then, where is the code the test user to decide what kinds of USB charger
> (SDP, CDP, DCP) is connecting now?

Even without detection of CDP and DCP we have configurability within SDP
- there's the 2.5mA suspended limit, the 100mA default limit and the
higher 500mA limit which can be negotiated.


signature.asc
Description: PGP signature

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

[Mathias Nyman]

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 
Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI
commmand timeout

On 23.03.2016 05:53, Rajesh Bhagat wrote:


IMO, The assumption that "xhci_abort_cmd_ring would always generate
an event and handle_cmd_completion would be called" will not be
always be true if HW

is in bad state.


Please share your opinion.



writing the CA (command abort) bit in CRCR (command ring control
register)  will stop the command ring, and CRR (command ring running) will be 
set

to 0 by xHC.

xhci_abort_cmd_ring() polls this bit up to 5 seconds.
If it's not 0 then the driver considers the command abort as failed.

The scenario you're thinking of is that xHC would still react to CA
bit set, it would stop the command ring and set CRR 0, but not send a command

completion event.


Have you tried adding some debug to handle_cmd_completion() and see
if you receive any event after command abortion?



Yes. We have added debug prints at first line of
handle_cmd_completion, and we are not getting those prints. The last
print messages that we get are as below from xhci_alloc_dev while
resume
operation:

xhci-hcd xhci-hcd.0.auto: Command timeout xhci-hcd xhci-hcd.0.auto:
Abort command ring

May be somehow, USB controller is in bad state and not responding to the

commands.


Please suggest how XHCI driver can handle such situations.



Restart the command timeout timer when writing the command abort bit.
If we get theIf we get the abort event the timer is deleted.

Otherwise if the timout triggers a second time we end up calling
xhci_handle_command_timeout() with a stopped ring, This will call
xhci_handle_stopped_cmd_ring(), turn the aborted command to no-op, restart the
command ring, and finally when the no-op completes it should call the missing
completion.

If command ring doesn't start then additional code could be added to
xhci_handle_command_timeout() that clears the command ring if it is called a 
second
time (=current command is already in abort state and command ring is stopped 
when
entering xhci_handle_command_timeout)

There might be some details missing, I'm not able to test any of this, but try
something like this:

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index
3e1d24c..576819e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -319,7 +319,10 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
  xhci_halt(xhci);
  return -ESHUTDOWN;
  }
-
+   /* writing the CMD_RING_ABORT bit should create a command completion
+* event, add a command completion timeout for it as well
+*/
+   mod_timer(>cmd_timer, jiffies + XHCI_CMD_DEFAULT_TIMEOUT);
  return 0;
   }


Hello Mathias,

Thanks for the patch.

After application of above patch, I'm getting following prints constantly:

xhci-hcd xhci-hcd.0.auto: Command timeout
xhci-hcd xhci-hcd.0.auto: Abort command ring
xhci-hcd xhci-hcd.0.auto: Command timeout on stopped ring
xhci-hcd xhci-hcd.0.auto: Turn aborted command be56e000 to no-op
xhci-hcd xhci-hcd.0.auto: // Ding dong!
...
xhci-hcd xhci-hcd.0.auto: Command timeout
xhci-hcd xhci-hcd.0.auto: Abort command ring
xhci-hcd xhci-hcd.0.auto: Command timeout on stopped ring
xhci-hcd xhci-hcd.0.auto: Turn aborted command be56e000 to no-op
xhci-hcd xhci-hcd.0.auto: // Ding dong!

As expected, xhci_handle_command_timeout is called again and next time ring 
state
is __not__ CMD_RING_STATE_RUNNING, Hence xhci_handle_stopped_cmd_ring is called
which turn all the aborted commands to no-ops and again makes the ring state as
CMD_RING_STATE_RUNNING, and rings the door bell.

But again in this case, no response from USB controller and xhci_alloc_dev is 
still waiting for
wait_for_completion.

Does rescheduling the xhci->cmd_timer ensures command completion will be 
called. IMO, it is still
dependent on HW response.



It's still dependent on hw starting the command ring, which apparently fails

So additional code is needed that will treat a second or third timeout as
a failed abort attempt, i.e. if a command times out on a stopped ring and the
command status is already aborted, then we cleanup the command ring and kill 
xhci.

So in addition to the previous added timeout something like this is needed:
(Again, uncompiled, untested semi pseudocode)


diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7cf6621..d8518e8f 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1253,6 +1253,7 @@ void xhci_handle_command_timeout(unsigned long data)
int ret;
unsigned long flags;
u64 

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Thierry Reding]

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, SATA and USB.
> 
> I finally got around trying this both on Jetson TK1 as well as our own
> Toradex Apalis TK1 module we are about to mainline.

Looking forward to it.

> I actually applied
> your patch set on top of 4.6.0-rc1. While USB 3.0 seems to work fine I
> noticed PCIe and SATA no more to come up right with the following
> message:
> 
> [2.794458] tegra-pcie 1003000.pcie-controller: PLL failed to lock:
> -110
> [2.801177] tegra-pcie 1003000.pcie-controller: failed to power on
> PHY: -110
> [2.809031] tegra-pcie: probe of 1003000.pcie-controller failed with
> error -110
> 
> Do you happen to know what could be the issue?

That's to be expected. You'll need this one:

http://patchwork.ozlabs.org/patch/596548/

which I had hoped would make v4.6-rc1, but didn't. I'll have to respin
and send out again. I didn't know that SATA failed in the same way, but
I'll need to recheck and see if it needs a similar change.

> As for USB I do get some message about the endpoint companion but do
> not know whether or not this is to be expected:
> 
> [ 1021.575301] usb 4-1: new SuperSpeed USB device number 2 using tegra-
> xusb
> [ 1021.598913] usb 4-1: No SuperSpeed endpoint companion for config
> 1  interface 0 altsetting 0 ep 2: using minimum values

I'm not exactly sure why that message appears, but I think it is
harmless.

> Otherwise it looks good:
> 
> ubuntu@tegra-ubuntu:~$ lsusb
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 002: ID 0951:1666 Kingston Technology DataTraveler G4
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> And performs satisfactorily (up from around 24 MB/sec with just USB
> 2.0):
> 
> ubuntu@tegra-ubuntu:~$ sudo hdparm -t /dev/sda
> 
> /dev/sda:
>  Timing buffered disk reads:  94 MB in  3.05 seconds =  30.81 MB/sec
> 
> Apalis TK1 actually features two USB 3.0 host ports:
> 
> ubuntu@tegra-ubuntu:~$ lsusb
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 005 Device 002: ID 0951:1666 Kingston Technology DataTraveler G4
> Bus 005 Device 003: ID 1f75:0902 Innostor Technology Corporation IS902
> UFD controller
> Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> ubuntu@tegra-ubuntu:~$ sudo hdparm -t /dev/sda
> 
> /dev/sda:
>  Timing buffered disk reads:  96 MB in  3.00 seconds =  31.98 MB/sec
> 
> ubuntu@tegra-ubuntu:~$ sudo hdparm -t /dev/sdb
> 
> /dev/sdb:
>  Timing buffered disk reads: 152 MB in  3.04 seconds =  49.99 MB/sec

Looking great. Thanks for testing.

Thierry


signature.asc
Description: PGP signature

[PATCH v5 2/2] USB: serial: cp210x: Adding GE Healthcare Device ID

[Martyn Welch]

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 b1eb8da..5b5c4ec 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -170,6 +170,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */
+   { USB_DEVICE(0x1901, 0x0194) }, /* GE Healthcare Remote Alarm Box */
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
{ USB_DEVICE(0x1BA4, 0x0002) }, /* Silicon Labs 358x factory default */
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/2] USB: serial: cp210x: Adding GPIO support for CP2105

[Martyn Welch]

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
configure the pins for GPIO is made separately for pins shared with each
of the 2 serial ports this device provides, though the choice is made for
all pins associated with that port in one go. The choice of whether to use
the pins for GPIO or serial is made by adding configuration to a one-time
programable PROM in the chip and can not be changed at runtime. The device
defaults to GPIO.

This device supports either push-pull or open-drain modes, it doesn't
provide an explicit input mode, though the state of the GPIO can be read
when used in open-drain mode. Like with pin use, the mode is configured in
the one-time programable PROM and can't be changed at runtime.

Signed-off-by: Martyn Welch 
---

V2: - Doesn't break build when gpiolib isn't selected.

V3: - Tracking GPIO state so pins no longer get their state changed should
  the pin be in open-drain mode and be pulled down externally whilst
  another pin is set.
- Reworked buffers and moved to byte accesses to remove the
  questionable buffer size logic and byte swapping.
- Added error reporting.
- Removed incorrect/pointless comments.
- Renamed tmp variable to make use clearer.

V4: - Fixed memory leak in cp210x_gpio_get error path.

V5: - Determining shared GPIO based on device type.
- Reordered vendor specific values by value.
- Use interface device for gpio messages.
- Remove unnecessary empty lines.
- Using kzalloc rather than kcalloc.
- Added locking to port_priv->output_state.
- Added dummy cp2105_shared_gpio_init for !CONFIG_GPIOLIB.
- Removed unnecessary masking on u8.
- Added support for use of GPIO pin as RS485 traffic indication or activity
  LEDs.
- Use correct dev for GPIO device.
- Set can_sleep.
- Roll in initial configuration state support.
- Print error message & continue if GPIO fails.
- Simplified ifdef'ing.

 drivers/usb/serial/cp210x.c | 353 +++-
 1 file changed, 349 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index c740592..b1eb8da 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -23,6 +23,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define DRIVER_DESC "Silicon Labs CP210x RS232 serial adaptor driver"
 
@@ -44,10 +47,14 @@ static int cp210x_tiocmset(struct tty_struct *, unsigned 
int, unsigned int);
 static int cp210x_tiocmset_port(struct usb_serial_port *port,
unsigned int, unsigned int);
 static void cp210x_break_ctl(struct tty_struct *, int);
+static int cp210x_attach(struct usb_serial *);
+static void cp210x_release(struct usb_serial *);
 static int cp210x_port_probe(struct usb_serial_port *);
 static int cp210x_port_remove(struct usb_serial_port *);
 static void cp210x_dtr_rts(struct usb_serial_port *p, int on);
 
+#define CP210X_FEATURE_HAS_SHARED_GPIO BIT(0)
+
 static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x045B, 0x0053) }, /* Renesas RX610 RX-Stick */
{ USB_DEVICE(0x0471, 0x066A) }, /* AKTAKOM ACE-1001 cable */
@@ -133,7 +140,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
-   { USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
+   { USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA71) }, /* Infinity GPS-MIC-1 Radio Monophone */
{ USB_DEVICE(0x10C4, 0xF001) }, /* Elan Digital Systems USBscope50 */
{ USB_DEVICE(0x10C4, 0xF002) }, /* Elan Digital Systems USBwave12 */
@@ -199,9 +206,20 @@ static const struct usb_device_id id_table[] = {
 
 MODULE_DEVICE_TABLE(usb, id_table);
 
+struct cp210x_dev_private {
+   u8  partnum;
+};
+
 struct cp210x_port_private {
__u8bInterfaceNumber;
boolhas_swapped_line_ctl;
+#ifdef CONFIG_GPIOLIB
+   struct usb_serial   *serial;
+   struct gpio_chipgc;
+   struct mutexoutput_lock;
+   unsigned intoutput_state;
+   unsigned int*gpio_map;
+#endif
 };
 
 static struct usb_serial_driver cp210x_device = {
@@ -220,6 +238,8 @@ static struct usb_serial_driver cp210x_device = {
.tx_empty   = cp210x_tx_empty,
.tiocmget   = cp210x_tiocmget,
.tiocmset   = cp210x_tiocmset,
+   .attach  

Usb point of sale keyboard shows err 19 of hub has too many ports

[reggie macdonald]

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 
loads with error message of hub has too many ports. 
   --
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: driver migration

[Konstantin Shkolnyy]

> -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 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.  The release callback is for when your whole device is
> gkh> removed, not the individual ports.
> 
> In addition, I initialized a spinlock  as part of setting up the data
> structures in the port_init callback routine. Since then, the driver is no
> longer crashing, and also the load no longer slowly builds up causing the
> machine to eventually freeze.
> 
> One problem solved.
> 
> Next problem:
> When issuing a write command to the driver via echo "text" > /dev/ttyUSB0,
> there is a delay of about 30 seconds until echo completes (echo is blocking
> for 30 seconds). The timestamp in the syslog also show this: usbrsa_close is
> started only around 30 secs (see below below @ 7346.332061) after
> completion
> of the write completion handlers.
> The routine usbrsa_status_callback that was started first by usbrsa_open,
> and is then being continuously called by itself, does not block.
> (For the source code of the involved routines, please see below)
> 
> 
> With the ancient kernel version 3.17, this was working fine.
> I would not think that the 30 seconds blockng are not random but are related
> to a timeout of any kind.
> 
> 1) I wonder what the kernel is doing between usbrsa_write and
> usbrsa_close.
> it seems not to be executing code within the driver. What can cause the 30
> seconds of blocking/what is the kernel waiting for?
[...]

Just a wild guess - this 30-second delay before close can happen because 
usbserial is waiting for data to be transmitted, before closing the port.
If you know that your data have been transmitted, perhaps you didn't properly 
tell usbserial that your write operation has finished.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb 3.0 stopped working with 4.6.0 rc1

[Mathias Nyman]

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 device
strings: Mfr=1, Product=2, SerialNumber=3
Mar 27 21:14:18 hydra kernel: [  104.306493] usb 3-2: Product: Expansion
Mar 27 21:14:18 hydra kernel: [  104.306494] usb 3-2: Manufacturer: Seagate
Mar 27 21:14:18 hydra kernel: [  104.306496] usb 3-2: SerialNumber: 2HC015KJ
Mar 27 21:14:18 hydra kernel: [  104.318943] xhci_hcd :00:14.0:
WARN: SuperSpeed Endpoint Companion descriptor for ep 0x83 does not
support streams
Mar 27 21:14:18 hydra kernel: [  104.319504] uas: probe of 3-2:1.0
failed with error -22
Mar 27 21:14:18 hydra mtp-probe: checking bus 3, device 4:
"/sys/devices/pci:00/:00:14.0/usb3/3-2"
Mar 27 21:14:18 hydra mtp-probe: bus: 3, device: 4 was not an MTP device

something is broken in rc1.


Can you use 'git bisect' to track down the offending commit that causes
it?  It shouldn't take too many tries.

thanks,



Very likely this change:

commit b37d83a6a41499d582b8faedff1913ec75d9e70b
 usb: Parse the new USB 3.1 SuperSpeedPlus Isoc endpoint companion 
descriptor

I'll send a series with fixes for usb-linus today, including the fix for this 
one.



On second thought, it's probably better to just send the regression fix
http://marc.info/?l=linux-usb=145924804900533=2

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: dwc3: increase maximum number of TRBs per endpoint

[Bin Liu]

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 were
> >> using 512 bytes of memory for each endpoint.
> >>
> >> However, SLAB/SLUB will always allocate PAGE_SIZE
> >> chunks. In order to better utilize the memory we
> >> allocate and to allow deeper queues for gadgets
> >> which would benefit from it (g_ether comes to mind),
> >> let's increase the maximum to 256 TRBs which rounds
> >> up to 4096 bytes for each endpoint.
> >
> > Do we want to increase the same for event ring buffers as
> > while, which is allocated by dma_alloc_coherent(), which
> > is also at PAGE_SIZE chunks, right?
> 
> I could, but that's much less important. Currently we have up to 2

I agree it is less important, the only issue I see is wasting of memory.
The device I am working on right now has two dwc3 controllers, each
allocates 16 event buffers, so for the total of 128KB allocated pages,
only 8KB is really used, 120KB is wasted.

Seems dma pool makes more sense in here?

Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Getting a gadget serial device working on Atmel SAMA5D31

[JB]

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 single instance where this is followed by a few other entries:

gadget: high-speed config #2: CDC ACM config
gadget: reset acm control interface 0
g_serial gadget: reset acm ttyGS0
g_serial gadget: activate acm ttyGS0
g_serial gadget: acm ttyGS0 serial state 
g_serial gadget: non-core control reqa1.21 v i l7
g_serial gadget: acm ttyGS0 reqa1.21 v i l7
g_serial gadget: non-core control req21.22 v i l0
g_serial gadget: acm ttyGS0 req21.22 v i l0
g_serial gadget: non-core control req21.20 v i l7
g_serial gadget: acm ttyGS0 req21.20 v i l7
g_serial gadget: non-core control reqa1.21 v i l7
g_serial gadget: acm ttyGS0 reqa1.21 v i l7
g_serial gadget: reset config
g_serial gadget: acm ttyGS0 deactivated

Any other leads?

Thanks,
Bálint
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: gadget: udc: at91: use PTR_ERR_OR_ZERO()

[Nicolas Ferre]

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_udc.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/at91_udc.c 
> b/drivers/usb/gadget/udc/at91_udc.c
> index d0d18947f58b..8bc78418d40e 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -1726,10 +1726,7 @@ static int at91sam9261_udc_init(struct at91_udc *udc)
>  
>   udc->matrix = syscon_regmap_lookup_by_phandle(udc->pdev->dev.of_node,
> "atmel,matrix");
> - if (IS_ERR(udc->matrix))
> - return PTR_ERR(udc->matrix);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(udc->matrix);
>  }
>  
>  static void at91sam9261_udc_pullup(struct at91_udc *udc, int is_on)
> 


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: fix regression in SuperSpeed endpoint descriptor parsing

[Mathias Nyman]

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 new SuperSpeedPlus Isoc endpoint companion parsing code incorrectly
decreased the the remaining buffer size before comparing the size with the
expected length of the descriptor.

This lead to possible failure in reading the SuperSpeed endpoint companion
descriptor of the last endpoint, displaying a message like:

"No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0
  ep 129: using minimum values"

Fix it by decreasing the size after comparing it.
Also finish all the SS endpoint companion parsing before calling SSP isoc
endpoint parsing function.


Isn't it another problem?


If you mean moving the parsing of the SSP isoc ep a bit further down in
the function it wasn't a problem at all. It makes the code more sane and
readable, and it was one of the reasons the first version didn't make it.

Alan commented:
"Also, wouldn't it be better in the original patch to call
usb_parse_ssp_isoc_endpoint_companion() after all the SS endpoint
companion stuff is finished, instead of in the middle?"




Fixes: b37d83a6a414


This tag requires the same format as you used above.


I didn't want to clutter with a two-line (or line wrapped) message here again
when the commit ID and summary is mentioned a few lines above.
I actually did a quick git-log and checked that there are "Fixes." tags with
just commit IDs.

But seems that SubmittingPatches recommends 12 + Summary for Fixes as well.
Not sure. Up to Greg If he takes it or wants me to resend

-Mathias


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: fix regression in SuperSpeed endpoint descriptor parsing

[Sergei Shtylyov]

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 parsing code incorrectly
decreased the the remaining buffer size before comparing the size with the
expected length of the descriptor.

This lead to possible failure in reading the SuperSpeed endpoint companion
descriptor of the last endpoint, displaying a message like:

"No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0
  ep 129: using minimum values"

Fix it by decreasing the size after comparing it.
Also finish all the SS endpoint companion parsing before calling SSP isoc
endpoint parsing function.


   Isn't it another problem?


Fixes: b37d83a6a414


   This tag requires the same format as you used above.


Signed-off-by: Mathias Nyman 


[...]

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: gadget: fsl_udc_core: Fix pullup status

[Felipe Balbi]

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 won't be enabled.
>>>
>>> Fixes: 252455c40316 (usb: gadget: fsl driver pullup fix)
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>> Changelog:
>>> V2: "(is_on != 0)" changed to "!!is_on" as per Sergei Shtylyov comment,
>>>  cleaned up commit message.
>>>
>>>   drivers/usb/gadget/udc/fsl_udc_core.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
>>> b/drivers/usb/gadget/udc/fsl_udc_core.c
>>> index aab5221..4309b4f 100644
>>> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
>>> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
>>> @@ -1220,10 +1220,11 @@ static int fsl_pullup(struct usb_gadget *gadget, 
>>> int is_on)
>>>
>>> udc = container_of(gadget, struct fsl_udc, gadget);
>>>
>>> +   udc->softconnect = !!is_on;
>>> +
>>> if (!udc->vbus_active)
>>> return -EOPNOTSUPP;
>>>
>>> -   udc->softconnect = (is_on != 0);
>>
>> if we're suspended and VBUS was cut off, why would we keep softconnect
>> set to true ? That would also cause a discrepancy between SW state and
>> HW state.
>>
>> I don't have this HW to test, but this patch seems wrong to me.
>>
>
> Yeah, you are right. I'm using a fork of this driver with some minor 
> differences 
> to make it work with other hardware and missed that upstream driver enables 
> controller on resume unconditionally. Sorry for the noise and please ignore 
> this 
> patch.

you shouldn't send patches unless you have tested them. Simply
cherry-picking from another tree and sending it is NOT good enough. You
MUST test what you're sending with latest tag from Linus (right now,
that's v4.6-rc1). If you can't update your kernel, then don't try to
patch something you can't validate.

Thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2] usb: gadget: fsl_udc_core: Fix pullup status

[Dmitry Osipenko]

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 (usb: gadget: fsl driver pullup fix)
Signed-off-by: Dmitry Osipenko 
---
Changelog:
V2: "(is_on != 0)" changed to "!!is_on" as per Sergei Shtylyov comment,
 cleaned up commit message.

  drivers/usb/gadget/udc/fsl_udc_core.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index aab5221..4309b4f 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1220,10 +1220,11 @@ static int fsl_pullup(struct usb_gadget *gadget, int 
is_on)

udc = container_of(gadget, struct fsl_udc, gadget);

+   udc->softconnect = !!is_on;
+
if (!udc->vbus_active)
return -EOPNOTSUPP;

-   udc->softconnect = (is_on != 0);


if we're suspended and VBUS was cut off, why would we keep softconnect
set to true ? That would also cause a discrepancy between SW state and
HW state.

I don't have this HW to test, but this patch seems wrong to me.



Yeah, you are right. I'm using a fork of this driver with some minor differences 
to make it work with other hardware and missed that upstream driver enables 
controller on resume unconditionally. Sorry for the noise and please ignore this 
patch.


--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] usb: fix regression in SuperSpeed endpoint descriptor parsing

[Mathias Nyman]

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 buffer size before comparing the size with the
expected length of the descriptor.

This lead to possible failure in reading the SuperSpeed endpoint companion
descriptor of the last endpoint, displaying a message like:

"No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0
 ep 129: using minimum values"

Fix it by decreasing the size after comparing it.
Also finish all the SS endpoint companion parsing before calling SSP isoc
endpoint parsing function.

Fixes: b37d83a6a414
Signed-off-by: Mathias Nyman 
---
 drivers/usb/core/config.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 5eb1a87..31ccdcc 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -75,8 +75,6 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
 * be the first thing immediately following the endpoint descriptor.
 */
desc = (struct usb_ss_ep_comp_descriptor *) buffer;
-   buffer += desc->bLength;
-   size -= desc->bLength;
 
if (desc->bDescriptorType != USB_DT_SS_ENDPOINT_COMP ||
size < USB_DT_SS_EP_COMP_SIZE) {
@@ -100,7 +98,8 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
ep->desc.wMaxPacketSize;
return;
}
-
+   buffer += desc->bLength;
+   size -= desc->bLength;
memcpy(>ss_ep_comp, desc, USB_DT_SS_EP_COMP_SIZE);
 
/* Check the various values */
@@ -146,12 +145,6 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
ep->ss_ep_comp.bmAttributes = 2;
}
 
-   /* Parse a possible SuperSpeedPlus isoc ep companion descriptor */
-   if (usb_endpoint_xfer_isoc(>desc) &&
-   USB_SS_SSP_ISOC_COMP(desc->bmAttributes))
-   usb_parse_ssp_isoc_endpoint_companion(ddev, cfgno, inum, asnum,
-   ep, buffer, size);
-
if (usb_endpoint_xfer_isoc(>desc))
max_tx = (desc->bMaxBurst + 1) *
(USB_SS_MULT(desc->bmAttributes)) *
@@ -171,6 +164,11 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
max_tx);
ep->ss_ep_comp.wBytesPerInterval = cpu_to_le16(max_tx);
}
+   /* Parse a possible SuperSpeedPlus isoc ep companion descriptor */
+   if (usb_endpoint_xfer_isoc(>desc) &&
+   USB_SS_SSP_ISOC_COMP(desc->bmAttributes))
+   usb_parse_ssp_isoc_endpoint_companion(ddev, cfgno, inum, asnum,
+   ep, buffer, size);
 }
 
 static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] usb regression fix for 4.6-rc2 usb-linus

[Mathias Nyman]

Hi Greg

This fixes the regression seen in 4.6-rc2 with USB 3.0 devices.
http://marc.info/?l=linux-usb=145920036421563=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.
For more detals see:

http://marc.info/?l=linux-usb=145582017515890=2

I'll send this separately as I don't want to risk other fixes delaying
this one

-Mathias

Mathias Nyman (1):
  usb: fix regression in SuperSpeed endpoint descriptor parsing

 drivers/usb/core/config.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: gadget: fsl_udc_core: Fix pullup status

[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 (usb: gadget: fsl driver pullup fix)
> Signed-off-by: Dmitry Osipenko 
> ---
> Changelog:
> V2: "(is_on != 0)" changed to "!!is_on" as per Sergei Shtylyov comment,
> cleaned up commit message.
>
>  drivers/usb/gadget/udc/fsl_udc_core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
> b/drivers/usb/gadget/udc/fsl_udc_core.c
> index aab5221..4309b4f 100644
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -1220,10 +1220,11 @@ static int fsl_pullup(struct usb_gadget *gadget, int 
> is_on)
>  
>   udc = container_of(gadget, struct fsl_udc, gadget);
>  
> + udc->softconnect = !!is_on;
> +
>   if (!udc->vbus_active)
>   return -EOPNOTSUPP;
>  
> - udc->softconnect = (is_on != 0);

if we're suspended and VBUS was cut off, why would we keep softconnect
set to true ? That would also cause a discrepancy between SW state and
HW state.

I don't have this HW to test, but this patch seems wrong to me.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2] usb: gadget: f_midi: fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Balbi]

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 on that enpoint:
> HOST:   [DATA][Length=260][...]
> DEVICE: [NAK]
> HOST:   [PING]
> DEVICE: [NAK]
> HOST:   [PING]
> DEVICE: [NAK]
> ...
> HOST:   [PING]
> DEVICE: [NAK]
>
> Users should not change the buffer size to anything other than wMaxPacketSize
> because that can cause bugs (this bug) or performance issues. Thus, this patch
> fixes this problem by eliminating buflen entirely and replacing it with
> wMaxPacketSize of the appropriate endpoint where needed.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>
> v2:
>  - Removed buflen

sounds like removing buflen should be delyed to v4.7 merge window while
the fix is, indeed, needed. Can you drop the removal of buflen ? I guess
it's mostly about picking v1 and fixing endianess problems ?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2 2/6] usb: xhci: plat: add ->plat_start() and ->init_quirk() methods

[Felipe Balbi]

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.h
index 5a2e2e3936c4..d26e2fa2b76f 100644
--- a/drivers/usb/host/xhci-plat.h
+++ b/drivers/usb/host/xhci-plat.h
@@ -22,6 +22,8 @@ enum xhci_plat_type {
 struct xhci_plat_priv {
enum xhci_plat_type type;
const char *firmware_name;
+   void (*plat_start)(struct usb_hcd *);
+   int (*init_quirk)(struct usb_hcd *);
 };
 
 #define hcd_to_xhci_priv(h) ((struct xhci_plat_priv *)hcd_to_xhci(h)->priv)
-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 6/6] usb: host: xhci: plat: finally get rid of xhci_plat_type_is()

[Felipe Balbi]

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/usb/host/xhci-plat.c
index bdaa65319d40..c3818b97d2ac 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -86,18 +86,15 @@ static int xhci_plat_start(struct usb_hcd *hcd)
 
 #ifdef CONFIG_OF
 static const struct xhci_plat_priv xhci_plat_marvell_armada = {
-   .type = XHCI_PLAT_TYPE_MARVELL_ARMADA,
.init_quirk = xhci_mvebu_mbus_init_quirk,
 };
 
 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_quirk,
 };
 
 static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen3 = {
-   .type = XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3,
.firmware_name = XHCI_RCAR_FIRMWARE_NAME_V2,
.init_quirk = xhci_rcar_init_quirk,
.plat_start = xhci_rcar_start,
diff --git a/drivers/usb/host/xhci-plat.h b/drivers/usb/host/xhci-plat.h
index d26e2fa2b76f..9af0cb48053f 100644
--- a/drivers/usb/host/xhci-plat.h
+++ b/drivers/usb/host/xhci-plat.h
@@ -13,29 +13,11 @@
 
 #include "xhci.h"  /* for hcd_to_xhci() */
 
-enum xhci_plat_type {
-   XHCI_PLAT_TYPE_MARVELL_ARMADA,
-   XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2,
-   XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3,
-};
-
 struct xhci_plat_priv {
-   enum xhci_plat_type type;
const char *firmware_name;
void (*plat_start)(struct usb_hcd *);
int (*init_quirk)(struct usb_hcd *);
 };
 
 #define hcd_to_xhci_priv(h) ((struct xhci_plat_priv *)hcd_to_xhci(h)->priv)
-
-static inline bool xhci_plat_type_is(struct usb_hcd *hcd,
-enum xhci_plat_type type)
-{
-   struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
-
-   if (priv && priv->type == type)
-   return true;
-   else
-   return false;
-}
 #endif /* _XHCI_PLAT_H */
-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/6] usb: xhci: plat: get rid of xhci_plat_type_is()

[Felipe Balbi]

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_type_is()
  usb: xhci: plat: add ->plat_start() and ->init_quirk() methods
  usb: host: xhci: plat: move mvebu init_quirk() to xhci_plat_setup()
  usb: host: xhci: plat: change type of mvebu init_quirk()
  usb: host: xhci: plat: make use of new methods in xhci_plat_priv
  usb: host: xhci: plat: finally get rid of xhci_plat_type_is()

 drivers/usb/host/xhci-mvebu.c |  7 ++-
 drivers/usb/host/xhci-mvebu.h |  7 +--
 drivers/usb/host/xhci-plat.c  | 46 +--
 drivers/usb/host/xhci-plat.h  | 20 ++-
 drivers/usb/host/xhci-rcar.c  | 13 +++-
 5 files changed, 52 insertions(+), 41 deletions(-)

-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/6] usb: host: xhci: plat: change type of mvebu init_quirk()

[Felipe Balbi]

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  | 5 +
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index 1eefc988192d..85908a3ecb8f 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -12,6 +12,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include "xhci-mvebu.h"
 
 #define USB3_MAX_WINDOWS   4
@@ -41,8 +44,10 @@ static void xhci_mvebu_mbus_config(void __iomem *base,
}
 }
 
-int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev)
+int xhci_mvebu_mbus_init_quirk(struct usb_hcd *hcd)
 {
+   struct device *dev = hcd->self.controller;
+   struct platform_device *pdev = to_platform_device(dev);
struct resource *res;
void __iomem *base;
const struct mbus_dram_target_info *dram;
diff --git a/drivers/usb/host/xhci-mvebu.h b/drivers/usb/host/xhci-mvebu.h
index 7ede92aa41f6..301fc984cae6 100644
--- a/drivers/usb/host/xhci-mvebu.h
+++ b/drivers/usb/host/xhci-mvebu.h
@@ -10,10 +10,13 @@
 
 #ifndef __LINUX_XHCI_MVEBU_H
 #define __LINUX_XHCI_MVEBU_H
+
+struct usb_hcd;
+
 #if IS_ENABLED(CONFIG_USB_XHCI_MVEBU)
-int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev);
+int xhci_mvebu_mbus_init_quirk(struct usb_hcd *hcd);
 #else
-static inline int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev)
+static inline int xhci_mvebu_mbus_init_quirk(struct usb_hcd *hcd)
 {
return 0;
 }
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 21b4a52d15c4..d2a4f2be6a75 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -60,10 +60,7 @@ static int xhci_plat_setup(struct usb_hcd *hcd)
}
 
if (xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_MARVELL_ARMADA)) {
-   struct platform_device *pdev;
-
-   pdev = to_platform_device(hcd->self.controller);
-   ret = xhci_mvebu_mbus_init_quirk(pdev);
+   ret = xhci_mvebu_mbus_init_quirk(hcd);
if (ret)
return ret;
}
-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/6] usb: host: xhci: rcar: retire use of xhci_plat_type_is()

[Felipe Balbi]

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/host/xhci-rcar.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
index 623100e9385e..2617cd7eb8ff 100644
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "xhci.h"
@@ -76,6 +77,16 @@ static void xhci_rcar_start_gen2(struct usb_hcd *hcd)
writel(RCAR_USB3_TX_POL_VAL, hcd->regs + RCAR_USB3_TX_POL);
 }
 
+static int xhci_rcar_is_gen2(struct device *dev)
+{
+   struct device_node *node = dev->of_node;
+
+   return of_device_is_compatible(node, "renesas,xhci-r8a7790") ||
+   of_device_is_compatible(node, "renesas,xhci-r8a7791") ||
+   of_device_is_compatible(node, "renesas,xhci-r8a7793") ||
+   of_device_is_compatible(node, "renensas,rcar-gen2-xhci");
+}
+
 void xhci_rcar_start(struct usb_hcd *hcd)
 {
u32 temp;
@@ -85,7 +96,7 @@ void xhci_rcar_start(struct usb_hcd *hcd)
temp = readl(hcd->regs + RCAR_USB3_INT_ENA);
temp |= RCAR_USB3_INT_ENA_VAL;
writel(temp, hcd->regs + RCAR_USB3_INT_ENA);
-   if (xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2))
+   if (xhci_rcar_is_gen2(hcd->self.controller))
xhci_rcar_start_gen2(hcd);
}
 }
-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/6] usb: host: xhci: plat: move mvebu init_quirk() to xhci_plat_setup()

[Felipe Balbi]

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(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5c15e9bc5f7a..21b4a52d15c4 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -59,6 +59,15 @@ static int xhci_plat_setup(struct usb_hcd *hcd)
return ret;
}
 
+   if (xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_MARVELL_ARMADA)) {
+   struct platform_device *pdev;
+
+   pdev = to_platform_device(hcd->self.controller);
+   ret = xhci_mvebu_mbus_init_quirk(pdev);
+   if (ret)
+   return ret;
+   }
+
return xhci_gen_setup(hcd, xhci_plat_quirks);
 }
 
@@ -194,12 +203,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
*priv = *priv_match;
}
 
-   if (xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_MARVELL_ARMADA)) {
-   ret = xhci_mvebu_mbus_init_quirk(pdev);
-   if (ret)
-   goto disable_clk;
-   }
-
device_wakeup_enable(hcd->self.controller);
 
xhci->clk = clk;
-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/6] usb: host: xhci: plat: make use of new methods in xhci_plat_priv

[Felipe Balbi]

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/xhci-plat.c | 41 ++---
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index d2a4f2be6a75..bdaa65319d40 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -37,6 +37,24 @@ static const struct xhci_driver_overrides 
xhci_plat_overrides __initconst = {
.start = xhci_plat_start,
 };
 
+static void xhci_priv_plat_start(struct usb_hcd *hcd)
+{
+   struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
+
+   if (priv->plat_start)
+   priv->plat_start(hcd);
+}
+
+static int xhci_priv_init_quirk(struct usb_hcd *hcd)
+{
+   struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
+
+   if (!priv->init_quirk)
+   return 0;
+
+   return priv->init_quirk(hcd);
+}
+
 static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 {
/*
@@ -52,44 +70,37 @@ static int xhci_plat_setup(struct usb_hcd *hcd)
 {
int ret;
 
-   if (xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2) ||
-   xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3)) {
-   ret = xhci_rcar_init_quirk(hcd);
-   if (ret)
-   return ret;
-   }
 
-   if (xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_MARVELL_ARMADA)) {
-   ret = xhci_mvebu_mbus_init_quirk(hcd);
-   if (ret)
-   return ret;
-   }
+   ret = xhci_priv_init_quirk(hcd);
+   if (ret)
+   return ret;
 
return xhci_gen_setup(hcd, xhci_plat_quirks);
 }
 
 static int xhci_plat_start(struct usb_hcd *hcd)
 {
-   if (xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2) ||
-   xhci_plat_type_is(hcd, XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3))
-   xhci_rcar_start(hcd);
-
+   xhci_priv_plat_start(hcd);
return xhci_run(hcd);
 }
 
 #ifdef CONFIG_OF
 static const struct xhci_plat_priv xhci_plat_marvell_armada = {
.type = XHCI_PLAT_TYPE_MARVELL_ARMADA,
+   .init_quirk = xhci_mvebu_mbus_init_quirk,
 };
 
 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_quirk,
 };
 
 static const struct xhci_plat_priv xhci_plat_renesas_rcar_gen3 = {
.type = XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3,
.firmware_name = XHCI_RCAR_FIRMWARE_NAME_V2,
+   .init_quirk = xhci_rcar_init_quirk,
+   .plat_start = xhci_rcar_start,
 };
 
 static const struct of_device_id usb_xhci_of_match[] = {
-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

[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 separate file
> - remove flag LED_DEV_CAP_RGB
> v3:
> - call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
>   This is needed in cases when we have monochrome and color LEDs
>   as well in a system.
> v4:
> - Export led_hsv_to_rgb and let the device driver call it instead
>   of doing the conversion in the core
> v5:
> - don't ignore led_cdev->brightness_get silently if LED_DEV_CAP_RGB
>   is set but warn
> ---
>  drivers/leds/led-class.c|  7 +++
>  drivers/leds/led-rgb-core.c | 36 
>  include/linux/leds.h|  8 
>  3 files changed, 51 insertions(+)
> 
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 8a3748a..a4b144e 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -193,6 +193,13 @@ int led_classdev_register(struct device *parent, struct 
> led_classdev *led_cdev)
>   char name[64];
>   int ret;
>  
> + /*
> +  * for now reading back the color is not supported as multiple
> +  * HSV -> RGB -> HSV conversions may distort the color due to
> +  * rounding issues in the conversion algorithm
> +  */
> + WARN_ON(led_cdev->flags & LED_DEV_CAP_RGB && led_cdev->brightness_get);
> +

Backtrace is useless here, you may want to add some ()s and you don't
really want user to be causing messages in syslog this easily.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[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
> changes to struct led_classdev.
> 
> Select LEDS_RGB to enable building drivers using the RGB extension.
> 
> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
> should be overridden even if the provided values are zero.
> 
> Some examples for writing values to /sys/class/leds//brightness:
> (now also hex notation can be used)
> 
> 255 -> set full brightness and keep existing color if set
> 0 -> switch LED off but keep existing color so that it can be restored
>  if the LED is switched on again later
> 0x100 -> switch LED off and set also hue and saturation to 0
> 0x00 -> set full brightness, full saturation and set hue to 0
> (red)

Umm, that's rather strange interface -- and three values in single sysfs
file is actually forbidden.

Plus, it is very much unlike existing interfaces for RGB LEDs, which
we already have supported in the tree. (At least nokia N900 and Sony
motion controller already contain supported three-color LEDs).

Now... yes, there's work to be done for the 3-color LEDs. Currently,
they are treated as three different LEDs. (Which makes some sense, you
can use "battery charging" trigger for LED, and CPU activity trigger
for green, for example). It would be good to have some kind of
grouping, so that userspace can tell "these 3 leds are actually
combined into one light".

Second, we should define that LED brightness has similar gamma to the
monitor, so that expected colors are displayed when user requests
them.

(And then.. I guess we should talk about more advanced stuff, like
hardware that can drive the LED changes independently of the main
CPU.)

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/4] leds: core: add color LED sysfs extension

[Pavel Machek]

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 string to %#.6x
> v5:
> - no changes
> ---
>  drivers/leds/led-class.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 007a5b3..8a3748a 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -32,7 +32,10 @@ static ssize_t brightness_show(struct device *dev,
>   /* no lock needed for this */
>   led_update_brightness(led_cdev);
>  
> - return sprintf(buf, "%u\n", led_cdev->brightness);
> + if (led_cdev->brightness > LED_FULL)
> + return sprintf(buf, "%#.6x\n", led_cdev->brightness);
> + else
> + return sprintf(buf, "%u\n", led_cdev->brightness);
>  }
>  
>  static ssize_t brightness_store(struct device *dev,

No... I don't think you should change interface for existing file like
this.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

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 ; Dmitry Eremin-Solenikov
>> ; David Woodhouse ; Peter Chen
>> ; Alan Stern ;
>> r.bald...@samsung.com; Yoshihiro Shimoda
>> ; Lee Jones ; Mark
>> Brown ; Charles Keepax
>> ; patc...@opensource.wolfsonmicro.com;
>> Linux PM list ; USB ;
>> device-mainlin...@lists.linuxfoundation.org; LKML > ker...@vger.kernel.org>
>> Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 25 March 2016 at 15:09, Peter Chen  wrote:
>> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
>> >> Currently the Linux kernel does not provide any standard integration
>> >> of this feature that integrates the USB subsystem with the system
>> >> power regulation provided by PMICs meaning that either vendors must
>> >> add this in their kernels or USB gadget devices based on Linux (such
>> >> as mobile phones) may not behave as they should. Thus provide a
>> standard framework for doing this in kernel.
>> >>
>> >> Now introduce one user with wm831x_power to support and test the usb
>> >> charger, which is pending testing. Moreover there may be other
>> >> potential users will use it in future.
>> >>
>> >
>> > 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 detection has finished, or am I missing something?
>>
>> 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_charger_detect_type() in each gadget usb state changes.

I am not sure I get your point correctly, please correct me if I
misunderstand you.
We need to check the charger type at every event comes from the usb
gadget state changes or the extcon device state changes, which means a
new charger plugin or pullup.

>
> Li Jun
>> >
>> > --
>> > Best Regards,
>> > Peter Chen
>>
>>
>>
>> --
>> Baolin.wang
>> Best Regards
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] usb: phy: qcom: use PTR_ERR_OR_ZERO()

[Felipe Balbi]

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/phy-qcom-8x16-usb.c
index 579587d97217..590d2f881136 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -291,10 +291,7 @@ static int phy_8x16_read_devicetree(struct phy_8x16 *qphy)
 
qphy->switch_gpio = devm_gpiod_get_optional(dev, "switch",
   GPIOD_OUT_LOW);
-   if (IS_ERR(qphy->switch_gpio))
-   return PTR_ERR(qphy->switch_gpio);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(qphy->switch_gpio);
 }
 
 static int phy_8x16_reboot_notify(struct notifier_block *this,
-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] usb: gadget: udc: at91: use PTR_ERR_OR_ZERO()

[Felipe Balbi]

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/udc/at91_udc.c
index d0d18947f58b..8bc78418d40e 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1726,10 +1726,7 @@ static int at91sam9261_udc_init(struct at91_udc *udc)
 
udc->matrix = syscon_regmap_lookup_by_phandle(udc->pdev->dev.of_node,
  "atmel,matrix");
-   if (IS_ERR(udc->matrix))
-   return PTR_ERR(udc->matrix);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(udc->matrix);
 }
 
 static void at91sam9261_udc_pullup(struct at91_udc *udc, int is_on)
-- 
2.8.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem

[Lipengcheng]

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 Regards,
Pengcheng Li


> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Friday, March 25, 2016 10:19 PM
> To: Lipengcheng; Mathias Nyman; gre...@linuxfoundation.org
> Cc: st...@rowland.harvard.edu; ba...@ti.com; chasemetzge...@gmail.com; 
> mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com;
> robert.schlabb...@gmx.net; linux-usb@vger.kernel.org
> Subject: Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
> 
> Hi,
> 
> On 03/25/2016 03:39 PM, Lipengcheng wrote:
> > Hi,
> >Thanks Baolu very much!
> >The kernel is 3.10.Before the problem is inevitable emergence. But we 
> > fix patch number:b630d4b9d05ba2e66878ca4614946d0f950d4111
> and your suggest.
> > Then we resume and suspend the seventh and it is ok only if the usb3 can 
> > not work. So the changes are effective.
> 
> Thanks for testing.
> 
> >In the wrong state which the usb3 can not work, we continue to suspend 
> > and resume. It will be core dump. Should it be a normal
> phenomenon?
> 
> dpm_run_callback(): platform_pm_resume+0x0/0x5c returns -12
> PM: Device hiusb-xhci.0 failed to resume: error -12
> 
> 
> Your xHCI host controller failed to resume. As the result, your usb3 devices 
> should not work. You couldn't suspend it once more either.
> 
> Best Regards,
> Baolu

RE: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -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 ; Peter Chen
> ; Alan Stern ;
> r.bald...@samsung.com; Yoshihiro Shimoda
> ; Lee Jones ; Mark
> Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML  ker...@vger.kernel.org>
> Subject: Re: [PATCH v8 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 25 March 2016 at 15:09, Peter Chen  wrote:
> > On Thu, Mar 24, 2016 at 08:35:53PM +0800, Baolin Wang wrote:
> >> Currently the Linux kernel does not provide any standard integration
> >> of this feature that integrates the USB subsystem with the system
> >> power regulation provided by PMICs meaning that either vendors must
> >> add this in their kernels or USB gadget devices based on Linux (such
> >> as mobile phones) may not behave as they should. Thus provide a
> standard framework for doing this in kernel.
> >>
> >> Now introduce one user with wm831x_power to support and test the usb
> >> charger, which is pending testing. Moreover there may be other
> >> potential users will use it in future.
> >>
> >
> > 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 detection has finished, or am I missing something?
> 
> 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_charger_detect_type() in each gadget usb state changes.

Li Jun  
> >
> > --
> > Best Regards,
> > Peter Chen
> 
> 
> 
> --
> Baolin.wang
> Best Regards
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value

[Lee Jones]

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_ARMADA by xhci_plat_type_is().
> >> >>>
> >> >>> This fixes a regression in v4.5 for STiH407 family SoC's which use the
> >> >>> synopsis dwc3 IP, whereby the disable_clk error path gets taken due to
> >> >>> wrongly being detected as XHCI_PLAT_TYPE_MARVELL_ARMADA and the hcd 
> >> >>> never
> >> >>> gets added.
> >> >>>
> >> >>> I suspect this will also fix other dwc3 DT platforms such as Exynos,
> >> >>> although I've only tested on STih410 SoC.
> >> >>>
> >> >>> Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv")
> >> >>> Cc: sta...@vger.kernel.org
> >> >>> Cc: gregory.clem...@free-electrons.com
> >> >>> Cc: yoshihiro.shimoda...@renesas.com
> >> >>> Signed-off-by: Peter Griffin 
> >> >>> ---
> >> >>>  drivers/usb/host/xhci-plat.h | 2 +-
> >> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>>
> >> >>> diff --git a/drivers/usb/host/xhci-plat.h 
> >> >>> b/drivers/usb/host/xhci-plat.h
> >> >>> index 5a2e2e3..529c3c4 100644
> >> >>> --- a/drivers/usb/host/xhci-plat.h
> >> >>> +++ b/drivers/usb/host/xhci-plat.h
> >> >>> @@ -14,7 +14,7 @@
> >> >>>  #include "xhci.h" /* for hcd_to_xhci() */
> >> >>>  
> >> >>>  enum xhci_plat_type {
> >> >>> -  XHCI_PLAT_TYPE_MARVELL_ARMADA,
> >> >>> +  XHCI_PLAT_TYPE_MARVELL_ARMADA = 1,
> >> >>>XHCI_PLAT_TYPE_RENESAS_RCAR_GEN2,
> >> >>>XHCI_PLAT_TYPE_RENESAS_RCAR_GEN3,
> >> >>
> >> >> aren't these platforms using device tree ? Why aren't these just
> >> >> different compatible strings ?
> >> >
> >> > According to 4efb2f69411456d35051e9047c15157c9a5ba217 "usb: host:
> >> > xhci-plat: add struct xhci_plat_priv" :
> >> >
> >> > This patch adds struct xhci_plat_priv to simplify the code to match
> >> > platform specific variables. For now, this patch adds a member "type" in
> >> > the structure
> >> 
> >> that's fine but the answer doesn't exactly match my question ;-)
> >> 
> >> My point is that this enum shouldn't be necessary at all. We have
> >> compatible flags to make these checks instead. How about below ?
> >> (untested, uncompiled, yada yada yada). Note that we DON'T need this
> >> xhci_plat_type trickery, just need to be a little bit smarter about how
> >> we use driver_data:
> >
> > Your solution certainly looks more elegant.
> 
> cool thanks. Now that I think about this more carefully, we might wanna
> take $subject anyway for the -rc and get my version applied for v4.7
> merge window. What do you think ?

+1 for a simple/quick fix.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: driver migration

[tilman]

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.  The release callback is for when your whole device is
gkh> removed, not the individual ports.

In addition, I initialized a spinlock  as part of setting up the data
structures in the port_init callback routine. Since then, the driver is no
longer crashing, and also the load no longer slowly builds up causing the
machine to eventually freeze.

One problem solved.

Next problem: 
When issuing a write command to the driver via echo "text" > /dev/ttyUSB0,
there is a delay of about 30 seconds until echo completes (echo is blocking
for 30 seconds). The timestamp in the syslog also show this: usbrsa_close is
started only around 30 secs (see below below @ 7346.332061) after completion
of the write completion handlers. 
The routine usbrsa_status_callback that was started first by usbrsa_open,
and is then being continuously called by itself, does not block.
(For the source code of the involved routines, please see below)


With the ancient kernel version 3.17, this was working fine.
I would not think that the 30 seconds blockng are not random but are related
to a timeout of any kind. 

1) I wonder what the kernel is doing between usbrsa_write and usbrsa_close.
it seems not to be executing code within the driver. What can cause the 30
seconds of blocking/what is the kernel waiting for?

2) I have seen other drivers calling usb_serial_port_softint from various
places. What exaclty does usb_serial_port_softint/schedule_word that is
called by usb_serial_port_softint?



Many thanks

Tilman

Syslog:
===
...
[ 7315.882626] usbrsa_open - port=0
[ 7315.882666] usbrsa ttyUSB0: usbrsa_write_room(): Pool=640;usbrsa.tx=4084
[ 7315.882673] usbrsa ttyUSB0: usbrsa_write - port 0 START
[ 7315.882676] usbrsa_write; private struct =8803ff468c00
[ 7315.882682] usbrsa ttyUSB0: usbrsa_write - port 0; bytes=10 := count=10 :
nofTxBytesFree=4084
[ 7315.882688] usbrsa ttyUSB0: usbrsa_write - poolsize  10, urb_index 0
[ 7315.882694] usbrsa ttyUSB0: usbrsa_write - port 0;URB allocated=0
[ 7315.882699] usbrsa ttyUSB0: usbrsa_write - port 0;bytes in urb=10
[ 7315.882705] usbrsa ttyUSB0: usbrsa_write - length = 10, data = 31 32 33
34 35 36 37 38 39 30
[ 7315.882711] usbrsa ttyUSB0: usbrsa_write - port 0;sent=10;count=0;
nof_bytes_to_be_sent=0;bytes=10
[ 7315.882714] usbrsa ttyUSB0: usbrsa_write() End - sent=10
[ 7315.882722] usbrsa ttyUSB0: usbrsa_write_room(): Pool=576;usbrsa.tx=4084
[ 7315.882726] usbrsa ttyUSB0: usbrsa_write - port 0 START
[ 7315.882729] usbrsa_write; private struct =8803ff468c00
[ 7315.882734] usbrsa ttyUSB0: usbrsa_write - port 0; bytes=2 := count=2 :
nofTxBytesFree=4084
[ 7315.882738] usbrsa ttyUSB0: usbrsa_write - poolsize  10, urb_index 1
[ 7315.882742] usbrsa ttyUSB0: usbrsa_write - port 0;URB allocated=1
[ 7315.882745] usbrsa ttyUSB0: usbrsa_write - port 0;bytes in urb=2
[ 7315.882748] usbrsa ttyUSB0: usbrsa_write - length = 2, data = 0d 0a
[ 7315.882753] usbrsa ttyUSB0: usbrsa_write - port 0;sent=2;count=0;
nof_bytes_to_be_sent=0;bytes=2
[ 7315.882756] usbrsa ttyUSB0: usbrsa_write() End - sent=2
[ 7315.882769] usbrsa ttyUSB0: usbrsa_write_callback() - port = 0, ep
=0xc0018380
[ 7315.882776] usbrsa ttyUSB0: usbrsa_write_callback - length = 10, data =
31 32 33 34 35 36 37 38 39 30
[ 7315.882781] usbrsa ttyUSB0: usbrsa_write_callback(): Returned URB 0
[ 7315.882918] usbrsa ttyUSB0: usbrsa_write_callback() - port = 0, ep
=0xc0018380
[ 7315.882927] usbrsa ttyUSB0: usbrsa_write_callback - length = 2, data = 0d 0a
[ 7315.882932] usbrsa ttyUSB0: usbrsa_write_callback(): Returned URB 1
[ 7315.882938] usbrsa_status_callback: nofTxBytesFree=4074,nofRxBytesReceived=0 
[ 7315.883002] usbrsa_status_callback: nofTxBytesFree=4072,nofRxBytesReceived=0 
[ 7346.332061] usbrsa_close - start
[ 7346.332070] usbrsa ttyUSB0: usbrsa_close - port 0 start
[ 7346.332076] usbrsa ttyUSB0: send_baudrate_lcr_register() CFLAG=3261 
[ 7346.332080] usbrsa ttyUSB0: send_baudrate_lcr_register()
ST16C550.DLL=50;ST16C550.DLM=0;ST16C550.LCR=3
[ 7346.332130] usbrsa ttyUSB0: usbrsa_baudrate_lcr_callback() - port = 0,
ep=0xc0028300
[ 7346.332142] usbrsa ttyUSB0: send_baudrate_lcr_register() leaving
[ 7346.332146] usbrsa ttyUSB0: usbrsa_close - #retries=3
[ 7346.332148] usbrsa_close - end
[ 7346.332151] usbrsa ttyUSB0: usbrsa_close - end 
[ 7346.332163] usbrsa ttyUSB0: usbrsa_status_callback(): wake_up


Source code Excerpt:
=

static struct usb_serial_driver usbrsa_enumerated_device = 
{
.driver = {
.owner =THIS_MODULE,
.name = "usbrsa",
}, 
.description =  "IO-DATA - USB-RSA",
.id_table = id_table_std,
.num_ports =   

Re: usb 3.0 stopped working with 4.6.0 rc1

[Mathias Nyman]

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, SerialNumber=3
Mar 27 21:14:18 hydra kernel: [  104.306493] usb 3-2: Product: Expansion
Mar 27 21:14:18 hydra kernel: [  104.306494] usb 3-2: Manufacturer: Seagate
Mar 27 21:14:18 hydra kernel: [  104.306496] usb 3-2: SerialNumber: 2HC015KJ
Mar 27 21:14:18 hydra kernel: [  104.318943] xhci_hcd :00:14.0:
WARN: SuperSpeed Endpoint Companion descriptor for ep 0x83 does not
support streams
Mar 27 21:14:18 hydra kernel: [  104.319504] uas: probe of 3-2:1.0
failed with error -22
Mar 27 21:14:18 hydra mtp-probe: checking bus 3, device 4:
"/sys/devices/pci:00/:00:14.0/usb3/3-2"
Mar 27 21:14:18 hydra mtp-probe: bus: 3, device: 4 was not an MTP device

something is broken in rc1.


Can you use 'git bisect' to track down the offending commit that causes
it?  It shouldn't take too many tries.

thanks,



Very likely this change:

commit b37d83a6a41499d582b8faedff1913ec75d9e70b
usb: Parse the new USB 3.1 SuperSpeedPlus Isoc endpoint companion descriptor

I'll send a series with fixes for usb-linus today, including the fix for this 
one.

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] usb: dwc2: Add reset control to dwc2

[dinguyen]

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 --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 3c58d63..f748132 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -837,6 +837,7 @@ struct dwc2_hsotg {
void *priv;
int irq;
struct clk *clk;
+   struct reset_control *reset;
 
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 88629be..b1fa9dd 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -337,6 +338,9 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
 {
int i, ret;
 
+   if(hsotg->reset)
+   reset_control_deassert(hsotg->reset);
+
/* Set default UTMI width */
hsotg->phyif = GUSBCFG_PHYIF16;
 
@@ -434,6 +438,9 @@ static int dwc2_driver_remove(struct platform_device *dev)
if (hsotg->ll_hw_enabled)
dwc2_lowlevel_hw_disable(hsotg);
 
+   if (hsotg->reset)
+   reset_control_assert(hsotg->reset);
+
return 0;
 }
 
@@ -529,6 +536,14 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(>dev, "mapped PA %08lx to VA %p\n",
(unsigned long)res->start, hsotg->regs);
 
+   hsotg->reset = devm_reset_control_get(>dev, "dwc2");
+   if (IS_ERR(hsotg->reset)) {
+   dev_info(>dev, "Could not get reset control!\n");
+   if (PTR_ERR(hsotg->reset) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   hsotg->reset = NULL;
+   }
+
retval = dwc2_lowlevel_hw_init(hsotg);
if (retval)
return retval;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Getting a gadget serial device working on Atmel SAMA5D31

[Felipe Balbi]

Hi,

(please, don't top-post)

JB  writes:
> [ text/plain ]
> But that's it. On the host side, the device is detected for a brief
> moment - I managed to get the device info, and it looks like the real
> deal:
>
> Gadget Serial v2.4:
>Product ID: 0xa4a7
>Vendor ID: 0x0525  (PLX Technology, Inc.)
>Version: 4.05
>Speed: Up to 480 Mb/sec
>Manufacturer: Linux 4.5.0+ with atmel_usba_udc

4.5.0+, which patches do you have on top of 4.5 vanilla ?

Also, can you try this patch:

commit d0211ef4d96e1faf8939af6b171e47e6d85e31b2
Author: Felipe Balbi 
Date:   Mon Mar 21 09:04:23 2016 +0200

usb: gadget: udc: atmel: don't disable enpdoints we don't own

UDC driver should NEVER do anything behind
udc-core's back, so let's stop disabling endpoints
we don't exactly own - rather we provide as
resources for gadget drivers. This fixes the
regression reported by Gil.

Reported-by: Gil Weber 
Tested-by: Gil Weber 
Signed-off-by: Felipe Balbi 

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 81d42cce885a..18569de06b04 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1045,20 +1045,6 @@ static void reset_all_endpoints(struct usba_udc *udc)
list_del_init(>queue);
request_complete(ep, req, -ECONNRESET);
}
-
-   /* NOTE:  normally, the next call to the gadget driver is in
-* charge of disabling endpoints... usually disconnect().
-* The exception would be entering a high speed test mode.
-*
-* FIXME remove this code ... and retest thoroughly.
-*/
-   list_for_each_entry(ep, >gadget.ep_list, ep.ep_list) {
-   if (ep->ep.desc) {
-   spin_unlock(>lock);
-   usba_ep_disable(>ep);
-   spin_lock(>lock);
-   }
-   }
 }
 
 static struct usba_ep *get_ep_by_addr(struct usba_udc *udc, u16 wIndex)

-- 
balbi


signature.asc
Description: PGP signature

[PATCH 2/2] ARM: socfpga: dts: add reset control for USB

[dinguyen]

From: Dinh Nguyen 

Add the resets property for the 2 USB controllers.

Signed-off-by: Dinh Nguyen 
---
 arch/arm/boot/dts/socfpga.dtsi |4 
 arch/arm/boot/dts/socfpga_arria10.dtsi |4 
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index b89cbde3b..9f48141 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -831,6 +831,8 @@
interrupts = <0 125 4>;
clocks = <_mp_clk>;
clock-names = "otg";
+   resets = < USB0_RESET>;
+   reset-names = "dwc2";
phys = <>;
phy-names = "usb2-phy";
status = "disabled";
@@ -842,6 +844,8 @@
interrupts = <0 128 4>;
clocks = <_mp_clk>;
clock-names = "otg";
+   resets = < USB1_RESET>;
+   reset-names = "dwc2";
phys = <>;
phy-names = "usb2-phy";
status = "disabled";
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi 
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 1c5e139..b065651 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -689,6 +689,8 @@
interrupts = <0 95 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clk>;
clock-names = "otg";
+   resets = < USB0_RESET>;
+   reset-names = "dwc2";
phys = <>;
phy-names = "usb2-phy";
status = "disabled";
@@ -700,6 +702,8 @@
interrupts = <0 96 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clk>;
clock-names = "otg";
+   resets = < USB1_RESET>;
+   reset-names = "dwc2";
phys = <>;
phy-names = "usb2-phy";
status = "disabled";
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html