FUND TRANSFER (KEEP AS CONFIDENTIAL)

[johnsoncole564]

FUND TRANSFER (KEEP AS CONFIDENTIAL)


BANK LETTER..doc
Description: MS-Word document

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

[Michal Nazarewicz]

On Wed, Mar 09 2016, Felipe F. Tonello wrote:
> 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]
>
> This patch fixes this problem by setting the minimum usb_request's buffer size
> for the OUT endpoint as its wMaxPacketSize.
>
> Signed-off-by: Felipe F. Tonello 

Acked-by: Michal Nazarewicz 

But see comment below:

> ---
>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index 8475e3dc82d4..826ba641f29d 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, 
> unsigned intf, unsigned alt)
>   /* allocate a bunch of read buffers and queue them all at once. */
>   for (i = 0; i < midi->qlen && err == 0; i++) {
>   struct usb_request *req =
> - midi_alloc_ep_req(midi->out_ep, midi->buflen);
> + midi_alloc_ep_req(midi->out_ep,
> + max_t(unsigned, midi->buflen,
> + bulk_out_desc.wMaxPacketSize));

Or, just:

+   midi_alloc_ep_req(midi->out_ep,
+ bulk_out_desc.wMaxPacketSize);

Packet cannot be greater than wMaxPacketSize so there is no need to
allocate more (if buflen > wMaxPacketSize).

>   if (req == NULL)
>   return -ENOMEM;
>  

I’m also wondering whether it would be beneficial to get rid of buflen
all together and use wMaxPacketSie for in endpoints as well?  Is that
feasible?

-- 
Best regards
ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
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/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Bin Liu]

Hi,

On Fri, Mar 11, 2016 at 09:27:23PM +0300, Sergei Shtylyov wrote:
> On 03/11/2016 06:51 PM, Bin Liu wrote:
> 
> >>DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
> >
> >It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
> >still does not use DT with these patches?  Or did I miss anything?
> 
>The .dts[i] patches go thru the arm-soc tree. This patch only
> documents the bindings, that's all.
> 
> >Thanks,
> >-Bin.
> 
>Please cut out the part of mail you're not replying to -- this
> saves everybody's time.

Ok, will do. Thanks.

> 
> MBR, Sergei
> 

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: [PATCH 1/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Sergei Shtylyov]

On 03/11/2016 06:51 PM, Bin Liu wrote:


DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.


It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
still does not use DT with these patches?  Or did I miss anything?


   The .dts[i] patches go thru the arm-soc tree. This patch only documents 
the bindings, that's all.



Thanks,
-Bin.


   Please cut out the part of mail you're not replying to -- this saves 
everybody's time.


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 1/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Sergei Shtylyov]

On 03/11/2016 07:21 PM, Petr Kulhavy wrote:


I am having 2nd thought on parsing the clock prop, Sergei's comment
might be better. I will look more on this over this weekend. (DT is not
in my expertise...)

Regards,
-Bin.


I like Sergei's comment as well, but cannot see (yet) how the clock input
selection would be done.


   The same way as now, of course. Only getting the clock frequency would be 
different, via clk_get_rate()...



I mean, it makes sense to do the clock abstraction only if it can be done
properly and the clock input selection can be covered as well.


   No, this item has never been covered by the clk layer IIRC. That's what 
the device node props are for.



The DA8xx platform is missing the real clock framework and therefore the
different clocks cannot be referenced in DT.


   You mean more than one clock per device?


There is a fake clock framework in arch/arm/mach-davinci/clock.c - I've
already been through that and then gave up.


   I'm not sure why you call it "fake". It's a normal clk implementation, 
just not converted to the common clk framework.



Regards
Petr


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 v7 1/5] leds: core: add generic support for RGB LED's

[Heiner Kallweit]

Am 11.03.2016 um 09:38 schrieb Jacek Anaszewski:
> Hi Heiner,
> 
> Thanks for the updated set. I've renamed the feature to RGB LED class
> and pushed out to devel branch of linux-leds.git. It will sit there
> till the end of the upcoming merge window. There have been some
> uncertainties raised related to overloading brightness syntax. so let's
> better have it in linux-next through the whole next development cycle
> for the people to comment on.

Thanks Jacek, fine with me. I think in the next days I can come up with
two or three follow-up patches using this RGB LED functionality in triggers.
They would also be candidates for the devel branch then.

Rgds, Heiner

> 
> Thanks,
> Jacek Anaszewski
> 
> [...]
--
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: Freezable workqueue blocks non-freezable workqueue during the system resume process

[Tejun Heo]

Hello, Jan.

On Thu, Mar 03, 2016 at 10:33:10AM +0100, Jan Kara wrote:
> > Ugh... that's nasty.  I wonder whether the right thing to do is making
> > writeback workers non-freezable.  IOs are supposed to be blocked from
> > lower layer anyway.  Jan, what do you think?
> 
> Well no, at least currently IO is not blocked in lower layers AFAIK - for
> that you'd need to freeze block devices & filesystems and there are issues

At least libata does and I think SCSI does too, but yeah, there
probably are drivers which depend on block layer blocking IOs, which
btw is a pretty fragile way to go about as upper layers might not be
the only source of activities.

> with that (Jiri Kosina was the last one which was trying to make this work
> AFAIR). And I think you need to stop writeback (and generally any IO) to be
> generated so that it doesn't interact in a strange way with device drivers
> being frozen. So IMO until suspend freezes filesystems & devices properly
> you have to freeze writeback workqueue.

I still think the right thing to do is plugging that block layer or
low level drivers.  It's like we're trying to plug multiple sources
when we can plug the point where they come together anyway.

Thanks.

-- 
tejun
--
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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Fri, 11 Mar 2016, Jiri Kosina wrote:

> On Wed, 2 Mar 2016, Alan Stern wrote:
> 
> [ ... snip ... ]
> > The patch that fixed Daniel's problem is repeated below for your 
> > convenience.  Is this the right approach?  If you think it is, I'll 
> > submit it officially.
> 
> I've been thinking about this, and while I don't really like such bandaids 
> being added to the generic code, I haven't been able to come up with 
> anything better.
> 
> So the aproach is fine with me ... perhaps a short comment before testing 
> HID_STARTED wouldn't hurt as well, as it has a potential of making code 
> reader's head spin.

Perhaps I didn't do a good job of addressing the real underlying
problem.  That's why I asked if this was the right approach.

In Daniel's case, usbhid_start() never got called.  Perhaps that's the
real problem?  Anyway, this meant that usbhid->urbin never got set, and
consequently hid_start_in() returned an error when it was called by
hid_post_reset().

Does it make sense for usbhid_start() not to be called?

It stands out that hid_resume() checks the HID_STARTED bit before
calling hid_start_in() but hid_post_reset() doesn't.  That is
inconsistent; the check should be done in both places or in neither,
but I don't know which.  Is it possible for one of usbhid's devices to
be suspended or reset before usbhid_start() or after usbhid_stop()?  If 
it is then both places need to check -- my patch adds the missing 
check.

Finally, isn't it possible for an HID device not to have an 
interrupt-IN endpoint?  In which case usbhid->urbin will always be 
NULL, so hid_start_in() will always return an error unless it 
specifically checks -- and my patch adds such a check.

As you can see, it's a complicated and confusing situation.  Maybe 
you'd like to explore it in greater depth with Daniel to understand it 
better.

What do you suggest?

Alan Stern

--
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/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Petr Kulhavy]

On 11.03.2016 17:06, Bin Liu wrote:

Hi,

On Fri, Mar 11, 2016 at 04:58:52PM +0100, Petr Kulhavy wrote:


On 11.03.2016 16:51, Bin Liu wrote:

Hi,

On Fri, Mar 11, 2016 at 09:29:45AM +0100, Petr Kulhavy wrote:

DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.

It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
still does not use DT with these patches?  Or did I miss anything?

Thanks,
-Bin.

Hi Bin,

I have not touched the DA8xx dtsi file as I have these changes in my
own board specific dts.
But I can create another patch if you find it sensible. For me it
makes sense.

Okay, that is up to you, you can submit that patch whenever you are
ready. I will take this patch set when all comments are sorted out.

I will submit that patch once the DT is there.


I am having 2nd thought on parsing the clock prop, Sergei's comment
might be better. I will look more on this over this weekend. (DT is not
in my expertise...)

Regards,
-Bin.


I like Sergei's comment as well, but cannot see (yet) how the clock 
input selection would be done.
I mean, it makes sense to do the clock abstraction only if it can be 
done properly and the clock input selection can be covered as well.
The DA8xx platform is missing the real clock framework and therefore the 
different clocks cannot be referenced in DT.
There is a fake clock framework in arch/arm/mach-davinci/clock.c - I've 
already been through that and then gave up.


So if you come up with some good idea it's appreciated.

Regards
Petr
--
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/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Petr Kulhavy]

On 11.03.2016 16:51, Bin Liu wrote:

Hi,

On Fri, Mar 11, 2016 at 09:29:45AM +0100, Petr Kulhavy wrote:

DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.

It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
still does not use DT with these patches?  Or did I miss anything?

Thanks,
-Bin.

Hi Bin,

I have not touched the DA8xx dtsi file as I have these changes in my own 
board specific dts.
But I can create another patch if you find it sensible. For me it makes 
sense.


Petr
--
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 3/5 v10] usb: musb: core: added missing const qualifier to musb_hdrc_platform_data::config

[Bin Liu]

Hi,

On Fri, Mar 11, 2016 at 09:29:47AM +0100, Petr Kulhavy wrote:
> The musb_hdrc_platform_data::config was defined as a non-const pointer.
> However some drivers (e.g. the ux500) set up this pointer to point to a
> static structure, which is potentially dangerous. Since the musb core
> uses the pointer in a read-only manner the const qualifier was added to
> protect the content of the config.
> 
> Signed-off-by: Petr Kulhavy 
> Acked-by: Sergei Shtylyov 
> Signed-off-by: Bin Liu 

It is okay now, but I don't remember I've given my Signed-off-by to this
patch yet.

Regards,
-Bin.

> ---
> v5: 
> 
> v6:
>  - whitespace formatting corrected
> 
> v7: 
> v8: 
> v9: 
> v10: 
> 
>  drivers/usb/musb/musb_core.c | 2 +-
>  drivers/usb/musb/musb_core.h | 2 +-
>  include/linux/usb/musb.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 6a2d6d3..b0be1a9 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -1920,7 +1920,7 @@ static void musb_recover_from_babble(struct musb *musb)
>   */
>  
>  static struct musb *allocate_instance(struct device *dev,
> - struct musb_hdrc_config *config, void __iomem *mbase)
> + const struct musb_hdrc_config *config, void __iomem *mbase)
>  {
>   struct musb *musb;
>   struct musb_hw_ep   *ep;
> diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
> index 3f7a325..a062185 100644
> --- a/drivers/usb/musb/musb_core.h
> +++ b/drivers/usb/musb/musb_core.h
> @@ -438,7 +438,7 @@ struct musb {
>*/
>   unsigneddouble_buffer_not_ok:1;
>  
> - struct musb_hdrc_config *config;
> + const struct musb_hdrc_config *config;
>  
>   int xceiv_old_state;
>  #ifdef CONFIG_DEBUG_FS
> diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
> index 96ddfb7..0b3da40 100644
> --- a/include/linux/usb/musb.h
> +++ b/include/linux/usb/musb.h
> @@ -124,7 +124,7 @@ struct musb_hdrc_platform_data {
>   int (*set_power)(int state);
>  
>   /* MUSB configuration-specific details */
> - struct musb_hdrc_config *config;
> + const struct musb_hdrc_config *config;
>  
>   /* Architecture specific board data */
>   void*board_data;
> -- 
> 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 1/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Bin Liu]

Hi,

On Fri, Mar 11, 2016 at 09:29:45AM +0100, Petr Kulhavy wrote:
> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.

It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
still does not use DT with these patches?  Or did I miss anything?

Thanks,
-Bin.

> 
> Signed-off-by: Petr Kulhavy 
> ---
> v1: 
> 
> v2:
>  - using standard properties "dr_mode", "mentor,power", "mentor,num-eps", 
> "mentor,multipoint", "mentor,ram-bits"
>  - using "ti," prefix instead of "da8xx," for specific property names
>  - no wildcards in compatibility string
> 
> v3:
>  - added "reg", "interrupts" and "interrupt-names" properties
>  - wildcards in compatibility string
> 
> v4:
>  - compatibility string set to "ti,da830-musb"
>  - "mentor,num-eps", "mentor,multipoint", "mentor,ram-bits" properties 
> removed and hardcoded
>  - "ti,phy20-clkmux-cfg" renamed to "ti,phy20-clkmux-pll" and changed to 
> boolean
>  - removed "ti,hwmods"
> 
> v5:
>  - "ti,phy20-refclock-frequency" property made mandatory
> 
> v6:
>  - using "ti,usb2-phy-" prefix instead of "ti,phy20-" for the specific 
> properties
> 
> v7:
>  - removed the "mentor,power" property; hard coded to 500mA in the code
> 
> v8:
>  - "ti,usb2-phy-refclock-frequency" renamed to "ti,usb2-phy-refclock-hz" and 
> description amended
>  - "ti,usb2-phy-clkmux-pll" changed to "ti,usb2-phy-clkmux-refclkin" to 
> reflect the more common case
>  - USB maximum power modelled via a regulator "vbus-supply"
> 
> v9: 
> v10: 
> 
>  .../devicetree/bindings/usb/da8xx-usb.txt  | 45 
> ++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt 
> b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> new file mode 100644
> index 000..a6eda5b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> @@ -0,0 +1,45 @@
> +TI DA8xx MUSB
> +~
> +For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
> +
> +Required properties:
> +
> + - compatible : Should be set to "ti,da830-musb".
> +
> + - reg: Offset and length of the USB controller register set.
> +
> + - interrupts: The USB interrupt number.
> +
> + - interrupt-names: Should be set to "mc".
> +
> + - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or 
> "otg".
> +
> + - vbus-supply: Phandle to a regulator providing the USB bus power.
> +
> + - ti,usb2-phy-refclock-hz : Integer. Frequency in Hz of the USB 2.0 PHY 
> reference clock,
> + either provided by the internal PLL or an external source.
> + The supported values are: 12MHz, 13MHz, 19.2MHz, 20MHz, 24MHz, 26MHz, 
> 38.4MHz, 40MHz, 48MHz.
> +
> +
> +Optional properties:
> +
> + - ti,usb2-phy-clkmux-refclkin: Boolean. Defines the USB 2.0 PHY reference 
> clock source.
> + If present the the external USB_REFCLKIN pin is used as a clock source, 
> otherwise
> + the internal PLL is used.
> +
> +Example:
> +
> + usb20: usb@1e0 {
> + compatible = "ti,da830-musb";
> + reg =   <0x0020 0x1>;
> + interrupt-parent = <>;
> + interrupts = <58>;
> + interrupt-names = "mc";
> +
> + dr_mode = "host";
> + vbus-supply = <_vbus>;
> +
> + ti,usb2-phy-refclock-hz = <2400>;
> +
> + status = "okay";
> + };
> -- 
> 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 5/5 v9] usb: musb: da8xx: Add DT support for the DA8xx driver

[Bin Liu]

Hi,

On Thu, Mar 10, 2016 at 10:39:49AM +0100, Petr Kulhavy wrote:
> On 09.03.2016 21:00, Bin Liu wrote:
> >Hi,
> >
> >On Wed, Mar 09, 2016 at 10:25:27AM +0100, Petr Kulhavy wrote:
> >>+static inline int get_phy_refclk_cfg(struct device_node *np)
> >>+{
> >>+   u32 freq;
> >>+
> >>+   if (of_property_read_u32(np, "ti,usb2-phy-refclock-hz", ))
> >>+   return -EINVAL;
> >>+
> >>+   switch (freq) {
> >>+   case 1200:
> >>+   return CFGCHIP2_REFFREQ_12MHZ;
> >>+   case 1300:
> >>+   return CFGCHIP2_REFFREQ_13MHZ;
> >>+   case 1920:
> >>+   return CFGCHIP2_REFFREQ_19_2MHZ;
> >>+   case 2000:
> >>+   return CFGCHIP2_REFFREQ_20MHZ;
> >>+   case 2400:
> >>+   return CFGCHIP2_REFFREQ_24MHZ;
> >>+   case 2600:
> >>+   return CFGCHIP2_REFFREQ_26MHZ;
> >>+   case 3840:
> >>+   return CFGCHIP2_REFFREQ_38_4MHZ;
> >>+   case 4000:
> >>+   return CFGCHIP2_REFFREQ_40MHZ;
> >>+   case 4800:
> >>+   return CFGCHIP2_REFFREQ_48MHZ;
> >>+   default:
> >>+   return -EINVAL;
> >>+   }
> >>+}
> >Should this be wrapped with CONFIG_OF? Have you tried to build it with
> >OF disabled?
> 
> Hi Bin,
> 
> apart of the fact that the ARCH_DAVINCI requires the DT the

Even if DT is mandatory, disabling CONFIG_OF still should be tested to
ensure passing randconfig tests.

> usb/musb/da8xx.c compiles without errors if CONFIG_OF is disabled.

Good.

Thanks,
-Bin.

> Other drivers like Ethernet fail however.
> 
> Regards
> Petr
--
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 5/5 v9] usb: musb: da8xx: Add DT support for the DA8xx driver

[Bin Liu]

Hi,

On Thu, Mar 10, 2016 at 10:42:42AM +0100, Petr Kulhavy wrote:
> 
> 
> On 09.03.2016 12:53, Sergei Shtylyov wrote:
> >Hello.
> >
> >On 3/9/2016 12:25 PM, Petr Kulhavy wrote:
> >
> >>This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
> >>
> >>Signed-off-by: Petr Kulhavy 
> >>Tested-by: Petr Kulhavy 
> >[...]
> >
> >>diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
> >>index b03d3b8..aabd33a 100644
> >>--- a/drivers/usb/musb/da8xx.c
> >>+++ b/drivers/usb/musb/da8xx.c
> >[...]
> >>@@ -134,6 +139,55 @@ static inline void phy_off(void)
> >>  __raw_writel(cfgchip2, CFGCHIP2);
> >>  }
> >>
> >>+static inline int get_phy_refclk_cfg(struct device_node *np)
> >>+{
> >>+u32 freq;
> >>+
> >>+if (of_property_read_u32(np, "ti,usb2-phy-refclock-hz", ))
> >>+return -EINVAL;
> >
> >Shouldn't the frequency be retrieved thru the clk API, like we
> >do it for the power, BTW?
> >
> Bin, what do you think about it? I prefer the pragmatic approach
> leaving it as a parameter ;-)
> Then the clock selection would be needed as well, etc. I'd keep it simple.

Sorry for my late response, but I am okay with either way.

Regards,
-Bin.

> 
> >>+
> >>+switch (freq) {
> >>+case 1200:
> >>+return CFGCHIP2_REFFREQ_12MHZ;
> >>+case 1300:
> >>+return CFGCHIP2_REFFREQ_13MHZ;
> >>+case 1920:
> >>+return CFGCHIP2_REFFREQ_19_2MHZ;
> >>+case 2000:
> >>+return CFGCHIP2_REFFREQ_20MHZ;
> >>+case 2400:
> >>+return CFGCHIP2_REFFREQ_24MHZ;
> >>+case 2600:
> >>+return CFGCHIP2_REFFREQ_26MHZ;
> >>+case 3840:
> >>+return CFGCHIP2_REFFREQ_38_4MHZ;
> >>+case 4000:
> >>+return CFGCHIP2_REFFREQ_40MHZ;
> >>+case 4800:
> >>+return CFGCHIP2_REFFREQ_48MHZ;
> >>+default:
> >>+return -EINVAL;
> >>+}
> >>+}
> >>+
> >>+static inline u8 get_vbus_power(struct device *dev)
> >>+{
> >>+struct regulator *vbus_supply;
> >>+int current_uA;
> >>+
> >>+vbus_supply = regulator_get(dev, "vbus");
> >>+if (IS_ERR(vbus_supply))
> >>+return 255;
> >>+
> >>+current_uA = regulator_get_current_limit(vbus_supply);
> >>+regulator_put(vbus_supply);
> >>+
> >>+if (current_uA <= 0 || current_uA > 51)
> >>+return 255;
> >>+
> >>+return current_uA / 1000;
> >>+}
> >
> >   Wait, the platform data expects that in 2 mA units, you forgot
> >to divide by 2!
> >
> Argh, yes indeed!
> 
> Regards
> Petr
--
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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Jiri Kosina]

On Wed, 2 Mar 2016, Alan Stern wrote:

[ ... snip ... ]
> The patch that fixed Daniel's problem is repeated below for your 
> convenience.  Is this the right approach?  If you think it is, I'll 
> submit it officially.

I've been thinking about this, and while I don't really like such bandaids 
being added to the generic code, I haven't been able to come up with 
anything better.

So the aproach is fine with me ... perhaps a short comment before testing 
HID_STARTED wouldn't hurt as well, as it has a potential of making code 
reader's head spin.

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
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/3] usb: dwc3: increase maximum number of TRBs per endpoint

[Felipe Balbi]

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.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index e4f8b90d9627..bf05cca96941 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -435,7 +435,7 @@ struct dwc3_event_buffer {
 #define DWC3_EP_DIRECTION_TX   true
 #define DWC3_EP_DIRECTION_RX   false
 
-#define DWC3_TRB_NUM   32
+#define DWC3_TRB_NUM   256
 #define DWC3_TRB_MASK  (DWC3_TRB_NUM - 1)
 
 /**
-- 
2.7.0.GIT

--
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 3/3] usb: dwc3: core: improve reset sequence

[Felipe Balbi]

According to Synopsys Databook, we shouldn't be
relying on GCTL.CORESOFTRESET bit as that's only for
debugging purposes. Instead, let's use DCTL.CSFTRST
if we're OTG or PERIPHERAL mode.

Host side block will be reset by XHCI driver if
necessary. Note that this reduces amount of time
spent on dwc3_probe() by a long margin.

We're still gonna wait for reset to finish for a
long time (default to 1ms max), but tests show that
the reset polling loop executed at most 19 times
(modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).

Suggested-by: Mian Yousaf Kaukab 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.c | 48 ++--
 1 file changed, 18 insertions(+), 30 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index de5e01f41bc2..7a7fc12fc94b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -67,23 +67,9 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
 static int dwc3_core_soft_reset(struct dwc3 *dwc)
 {
u32 reg;
+   int retries = 1000;
int ret;
 
-   /* Before Resetting PHY, put Core in Reset */
-   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-   reg |= DWC3_GCTL_CORESOFTRESET;
-   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
-
-   /* Assert USB3 PHY reset */
-   reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-   reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
-   dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
-   /* Assert USB2 PHY reset */
-   reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-   reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
-   dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
-
usb_phy_init(dwc->usb2_phy);
usb_phy_init(dwc->usb3_phy);
ret = phy_init(dwc->usb2_generic_phy);
@@ -95,26 +81,28 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
phy_exit(dwc->usb2_generic_phy);
return ret;
}
-   mdelay(100);
 
-   /* Clear USB3 PHY reset */
-   reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
-   reg &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
-   dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+   /*
+* We're resetting only the device side because, if we're in host mode,
+* XHCI driver will reset the host block. If dwc3 was configured for
+* host-only mode, then we can return early.
+*/
+   if (dwc->dr_mode == USB_DR_MODE_HOST)
+   return 0;
 
-   /* Clear USB2 PHY reset */
-   reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
-   reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
-   dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+   reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+   reg |= DWC3_DCTL_CSFTRST;
+   dwc3_writel(dwc->regs, DWC3_DCTL, reg);
 
-   mdelay(100);
+   do {
+   reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+   if (!(reg & DWC3_DCTL_CSFTRST))
+   return 0;
 
-   /* After PHYs are stable we can take Core out of reset state */
-   reg = dwc3_readl(dwc->regs, DWC3_GCTL);
-   reg &= ~DWC3_GCTL_CORESOFTRESET;
-   dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+   udelay(1);
+   } while (--retries);
 
-   return 0;
+   return -ETIMEDOUT;
 }
 
 /**
-- 
2.7.0.GIT

--
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/3] usb: dwc3: gadget: always enable CSP

[Felipe Balbi]

CSP bit of TRB Control is useful for protocols such
CDC EEM/ECM/NCM where we're transferring in blocks
of MTU-sized requests (usually MTU is 1500 bytes).

We know we will always have a short packet after two
(for HS) wMaxPacketSize packets and, usually, we
will have a long(-ish) queue of requests (for our
g_ether gadget, we have at least 10
requests).

Instead of always stopping the queue processing to
interrupt, giveback and restart, let's tell dwc3 to
interrupt but continue processing following request
if we have anything already pending in the queue.

This gave me a considerable improvement of 40% on my
test setup.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2363bad45af8..cbc331a89c46 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -811,6 +811,9 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
trb->ctrl = DWC3_TRBCTL_ISOCHRONOUS_FIRST;
else
trb->ctrl = DWC3_TRBCTL_ISOCHRONOUS;
+
+   /* always enable Interrupt on Missed ISOC */
+   trb->ctrl |= DWC3_TRB_CTRL_ISP_IMI;
break;
 
case USB_ENDPOINT_XFER_BULK:
@@ -825,15 +828,14 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
BUG();
}
 
-   if (!req->request.no_interrupt && !chain)
-   trb->ctrl |= DWC3_TRB_CTRL_IOC;
+   /* always enable Continue on Short Packet */
+   trb->ctrl |= DWC3_TRB_CTRL_CSP;
 
-   if (usb_endpoint_xfer_isoc(dep->endpoint.desc)) {
-   trb->ctrl |= DWC3_TRB_CTRL_ISP_IMI;
-   trb->ctrl |= DWC3_TRB_CTRL_CSP;
-   } else if (last) {
+   if (!req->request.no_interrupt)
+   trb->ctrl |= DWC3_TRB_CTRL_IOC | DWC3_TRB_CTRL_ISP_IMI;
+
+   if (last)
trb->ctrl |= DWC3_TRB_CTRL_LST;
-   }
 
if (chain)
trb->ctrl |= DWC3_TRB_CTRL_CHN;
-- 
2.7.0.GIT

--
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 3/3] dm9601: add support ethtool style utility

[Ben Hutchings]

On Fri, 2016-03-11 at 11:33 +, Ben Hutchings wrote:
> On Fri, 2016-03-11 at 19:08 +0800, Joseph Chang wrote:
> > 
> > I tested by
> >  ./ethtool -E eth0 magic 0x9620 offset 0 length 3 value 0xf1 value 0xf2 
> > value 0xf3
> > 
> > I think ethtool need [ value N ] for each byte (so need three "value xx" in 
> > above command line), 
> > am I right?
> > 
> > Oh, I can see it goes wrong~ Thanks~
> [...]
> 
> You can only pass one byte on the command line and that forces the
> length to be 1.  To set multiple bytes, you need to provide them on
> stdin instead.

...as raw binary data, not hexadecimal strings.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 3/3] dm9601: add support ethtool style utility

[Ben Hutchings]

On Fri, 2016-03-11 at 19:08 +0800, Joseph Chang wrote:
> I tested by
>  ./ethtool -E eth0 magic 0x9620 offset 0 length 3 value 0xf1 value 0xf2 value 
> 0xf3
> 
> I think ethtool need [ value N ] for each byte (so need three "value xx" in 
> above command line), 
> am I right?
> 
> Oh, I can see it goes wrong~ Thanks~
[...]

You can only pass one byte on the command line and that forces the
length to be 1.  To set multiple bytes, you need to provide them on
stdin instead.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 1/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Sergei Shtylyov]

On 3/11/2016 11:29 AM, Petr Kulhavy wrote:


DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.

Signed-off-by: Petr Kulhavy 


Acked-by: Sergei Shtylyov 

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 5/5 v10] usb: musb: da8xx: Add DT support for the DA8xx driver

[Sergei Shtylyov]

Hello.

On 3/11/2016 11:29 AM, Petr Kulhavy wrote:


This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver

Signed-off-by: Petr Kulhavy 
Tested-by: Petr Kulhavy 


   Author's own "Tested-by:" tag is assumed, no need to specify it.

Acked-by: Sergei Shtylyov 

   Though using the clk API seems a good idea still...

[...]

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 3/3] dm9601: add support ethtool style utility

[Joseph Chang]

I tested by
 ./ethtool -E eth0 magic 0x9620 offset 0 length 3 value 0xf1 value 0xf2 value 
0xf3

I think ethtool need [ value N ] for each byte (so need three "value xx" in 
above command line), 
am I right?

Oh, I can see it goes wrong~ Thanks~

* I will go a vacation from now on, this issue will be study later.
 Any helpful reference implementation data is appreciated. 
 
Best Regards,
Joseph CHANG
System Application Engineering Division
Davicom Semiconductor, Inc.
No. 6 Li-Hsin 6th Rd., Science-Based Park,
Hsin-Chu, Taiwan.
Tel: 886-3-5798797 Ex 8534
Fax: 886-3-5646929
Web: http://www.davicom.com.tw


-Original Message-
From: Ben Hutchings [mailto:b...@decadent.org.uk] 
Sent: Thursday, March 10, 2016 9:18 PM
To: Joseph Chang; 'Joseph CHANG'; 'Peter Korsgaard'; net...@vger.kernel.org; 
linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 3/3] dm9601: add support ethtool style utility

On Thu, 2016-03-10 at 20:51 +0800, Joseph Chang wrote:
> I did verify to dump EEPROM data and also write EEPROM by per byte.
> 
> 1.Plug dm9601/dm9621 adapter and has get dm9601.ko be 'insmod' to have 'eht0',
> 2.Run ethtool v3.7 (as attached executable file and it's help display.)
> 3. Commands:
>./ethtool -e eth0  (dump EEPROM data for all the .get_eeprom_len )
>./ethtool -E eth0 magic 0x9620 offset 0 value 0xf1  (write 0xf1 to eeprom 
> byte0)
>./ethtool -E eth0 magic 0x9620 offset 1 value 0xf2  (write 0xf2 to eeprom 
> byte1)
>./ethtool -E eth0 magic 0x9620 offset 2 value 0xf3  (write 0xf3 to eeprom 
> byte2)
[...]

So you only tested writing 1 byte at a time.  Try again with 3 bytes
and you'll see how it goes wrong.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.

--
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] dm9601: manage eeprom to assure the chip for correct operation

[Joseph Chang]

Yes, this is to fixup purpose.

My customer buy "net101 USB20" netcards,
It was manifactured by some company and in the market.
We find it can not work due to eeprom wrong.

This fixup make it correct.
I focus on the essential eeprom words only.
Yes, need to reset the device once the eeprom is updated.
(I don't know how to let the device reset by software ?
 Only un-plug and then plug the device.)

Best Regards,
Joseph CHANG
System Application Engineering Division
Davicom Semiconductor, Inc.
No. 6 Li-Hsin 6th Rd., Science-Based Park,
Hsin-Chu, Taiwan.
Tel: 886-3-5798797 Ex 8534
Fax: 886-3-5646929
Web: http://www.davicom.com.tw


-Original Message-
From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard
Sent: Friday, March 11, 2016 2:37 AM
To: Joseph CHANG
Cc: Peter Korsgaard; net...@vger.kernel.org; linux-usb@vger.kernel.org;
linux-ker...@vger.kernel.org; Joseph Chang
Subject: Re: [PATCH 2/3] dm9601: manage eeprom to assure the chip for correct
operation

> "Joseph" == Joseph CHANG  writes:

 > Add to maintain variant eeprom adapters which may have not right
 > dm962x's format.

 > Signed-off-by: Joseph CHANG 

> +static void dm_render_begin(struct usbnet *dev)
 > +{
 > +/* Render eeprom if need, WORD3 render, set D[15:14] 01b */
 > +dm_eeprom_render(dev, 3, 0x4000, 0xc000);
 > +/* Render eeprom if need, WORD7 render, clear D[10] */
 > +dm_eeprom_render(dev, 7, 0x, 0x0400);
 > +/* Render eeprom if need, WORD11 render, need 0x005a */
 > +dm_eeprom_render(dev, 11, 0x005a, 0x);
 > +/* Render eeprom if need, WORD12 render, need 0x0007 */
 > +dm_eeprom_render(dev, 12, DM_EP3I_VAL, 0x);

With render I guess you mean something like fixup? I'm not sure we want
to do this automatically without an explicit action from the user.

How common are these adapters without valid eeprom? What happens if the
eeprom content isn't fixed?

Do we need to reset the device once the eeprom is updated?

-- 
Bye, Peter Korsgaard

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
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/3] dm9601: enable EP3 interrupt

[Joseph Chang]

After check more.
I think this is also to fix the bug to dm962x chip too. 

If keep no patch below:
 > +
 > +/* Always return 8-bytes data to host per interrupt-interval */
 > +dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);

 When attach dm962x to linux USB host, 
 The reg 'DM_USB_CTRL' get default value 0x00   
 This means the USB interrupt routine below,
   .status  = dm9601_status,
 will be called by events (they are: RX data found, TX complete, link change)
 Unfortunately, the link change CAN not work to trigger this event call.

 So I do
 > +dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);

 That 
   .status  = dm9601_status,
  will be called by time interval.

 * ".status = dm9601_status" is the way to tell the kernel new link
state,
  I can find it is bt 'usbnet_link_change( xx)' in ".status =
dm9601_status".

Information:  


In my [PATCH 2/3], 

+#defineDM_EP3I_VAL 0x07
+   /* Render eeprom if need, WORD12 render, need 0x0007 */
+   dm_eeprom_render(dev, 12, DM_EP3I_VAL, 0x); }

It can determine the above time interval.

If user define
+#defineDM_EP3I_VAL 0x0f

The time interval will be around 1 second.
Note: Must reset the device once to get effect. 



Best Regards,
Joseph CHANG
System Application Engineering Division
Davicom Semiconductor, Inc.
No. 6 Li-Hsin 6th Rd., Science-Based Park,
Hsin-Chu, Taiwan.
Tel: 886-3-5798797 Ex 8534
Fax: 886-3-5646929
Web: http://www.davicom.com.tw


-Original Message-
From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard
Sent: Friday, March 11, 2016 5:55 AM
To: Joseph CHANG
Cc: Peter Korsgaard; net...@vger.kernel.org; linux-usb@vger.kernel.org;
linux-ker...@vger.kernel.org; Joseph Chang
Subject: Re: [PATCH 1/3] dm9601: enable EP3 interrupt

> "Joseph" == Joseph CHANG  writes:

 > Enable chip's EP3 interrupt to get the link-up notify soon
 > immediately.

Sorry, what do you mean about 'soon immediately'?

 > +
 > +/* Always return 8-bytes data to host per interrupt-interval */
 > +dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);

Why would we want to do that instead of the current setup that afaik
only returns data when the link status changes?

-- 
Bye, Peter Korsgaard

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
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: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Clemens Ladisch]

Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello  
> wrote:
>> [...]
>> This patch fixes this problem by setting the minimum usb_request's buffer 
>> size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>> struct usb_request *req =
>> -   midi_alloc_ep_req(midi->out_ep, midi->buflen);
>> +   midi_alloc_ep_req(midi->out_ep,
>> +   max_t(unsigned, midi->buflen,
>> +   bulk_out_desc.wMaxPacketSize));
>
> Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?

No.  f_midi_handle_out_data() uses only the request buffer.


Regards,
Clemens
--
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 v7 1/5] leds: core: add generic support for RGB LED's

[Jacek Anaszewski]

Hi Heiner,

Thanks for the updated set. I've renamed the feature to RGB LED class
and pushed out to devel branch of linux-leds.git. It will sit there
till the end of the upcoming merge window. There have been some
uncertainties raised related to overloading brightness syntax. so let's
better have it in linux-next through the whole next development cycle
for the people to comment on.

Thanks,
Jacek Anaszewski

On 03/04/2016 10:09 PM, Heiner Kallweit wrote:

Add generic support for RGB 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)

Signed-off-by: Heiner Kallweit 
---
v2:
- move extension-specific code into a separate source file and
   introduce config symbol LEDS_HSV for it
- create separate patch for the extension to sysfs
- use variable name led_cdev as in the rest if the core
- rename to_hsv to led_validate_brightness
- rename LED_BRIGHTNESS_SET_COLOR to LED_SET_HSV
- introduce helper is_off for checking whether V part
   of a HSV value is zero
v3:
- change Kconfig to use depend instead of select, add help message,
   and change config symbol to LEDS_COLOR
- change LED core object file name in Makefile
- rename flag LED_SET_HSV to LED_SET_COLOR
- rename is_off to led_is_off
- rename led_validate-brightness to led_confine_brightness
- rename variable in led_confine_brightness
- add dummy enum led_brightness value to enforce 32bit enum
- rename led-hsv-core.c to led-color-core.c
- move check of provided brightness value to led_confine_brightness
v4:
- change config symbol name to LEDS_RGB
- change name of new file to led-rgb-core.c
- factor out part of led_confine_brightness
- change led_is_off to __is_set_brightness
- in led_set_software_blink pass led_cdev->max_brightness instead of LED_FULL
- rename LED_SET_COLOR to LED_SET_HUE_SAT
v5:
- change "RGB Color LED" to "RGB LED" in Kconfig
- move definition of LED_HUE_SAT_MASK to drivers/leds/leds.h
- rename LED_DEV_CAP_HSV to LED_DEV_CAP_RGB
v6:
- no change
v7:
- removed "Color" from RGB Color LED in commit message and title
- don't include linux/kernel.h in led-rgb-core.c
- keep definition of LED_DEV_CAP_[] flags together
---
  drivers/leds/Kconfig| 11 +++
  drivers/leds/Makefile   |  4 +++-
  drivers/leds/led-class.c|  2 +-
  drivers/leds/led-core.c | 16 +---
  drivers/leds/led-rgb-core.c | 39 +++
  drivers/leds/leds.h | 18 ++
  include/linux/leds.h| 11 ++-
  7 files changed, 91 insertions(+), 10 deletions(-)
  create mode 100644 drivers/leds/led-rgb-core.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7f940c2..5b1c852 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -13,6 +13,13 @@ menuconfig NEW_LEDS

  if NEW_LEDS

+config LEDS_RGB
+   bool "RGB LED Support"
+   help
+This option enables support for RGB Color LED devices.
+Sysfs attribute brightness is interpreted as a HSV color value.
+For details see Documentation/leds/leds-class.txt.
+
  config LEDS_CLASS
tristate "LED Class Support"
help
@@ -29,6 +36,10 @@ config LEDS_CLASS_FLASH
  for the flash related features of a LED device. It can be built
  as a module.

+if LEDS_RGB
+comment "RGB LED drivers"
+endif # LEDS_RGB
+
  comment "LED drivers"

  config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index e9d5309..cc3676f 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -1,6 +1,8 @@

  # LED Core
-obj-$(CONFIG_NEW_LEDS) += led-core.o
+obj-$(CONFIG_NEW_LEDS) += led-core-objs.o
+led-core-objs-y:= led-core.o
+led-core-objs-$(CONFIG_LEDS_RGB)   += led-rgb-core.o
  obj-$(CONFIG_LEDS_CLASS)  += led-class.o
  obj-$(CONFIG_LEDS_CLASS_FLASH)+= led-class-flash.o
  obj-$(CONFIG_LEDS_TRIGGERS)   += led-triggers.o
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index aa84e5b..007a5b3 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -53,7 +53,7 @@ static ssize_t brightness_store(struct device *dev,
if (ret)
goto unlock;

-   if (state == LED_OFF)
+  

[PATCH 2/5 v10] usb: musb: core: added helper function for parsing DT

[Petr Kulhavy]

This adds the function musb_get_mode() to get the DT property "dr_mode"

Signed-off-by: Petr Kulhavy 
Acked-by: Sergei Shtylyov 
---
v4: 
 - created musb_get_dr_mode()

v5:
 - musb_get_dr_mode() renamed to musb_get_mode()
 - added musb_get_power()

v6:
 - musb_get_power() : added missing boundary check for the maximum value 510mA
 - formatting
 - added empty implementation of musb_get_power()

v7:
 - removed empty implementation of musb_get_power()
 - musb_get_mode() returns MUSB_OTG if the property is not found

v8:
 - musb_get_power() removed

v9: 
v10: 

 drivers/usb/musb/musb_core.c | 19 +++
 drivers/usb/musb/musb_core.h |  5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c3791a0..6a2d6d3 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "musb_core.h"
 
@@ -129,6 +130,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
 }
 
+enum musb_mode musb_get_mode(struct device *dev)
+{
+   enum usb_dr_mode mode;
+
+   mode = usb_get_dr_mode(dev);
+   switch (mode) {
+   case USB_DR_MODE_HOST:
+   return MUSB_HOST;
+   case USB_DR_MODE_PERIPHERAL:
+   return MUSB_PERIPHERAL;
+   case USB_DR_MODE_OTG:
+   case USB_DR_MODE_UNKNOWN:
+   default:
+   return MUSB_OTG;
+   }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
 /*-*/
 
 #ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index fd215fb..3f7a325 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -614,4 +614,9 @@ static inline void musb_platform_post_root_reset_end(struct 
musb *musb)
musb->ops->post_root_reset_end(musb);
 }
 
+/* gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
 #endif /* __MUSB_CORE_H__ */
-- 
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 5/5 v10] usb: musb: da8xx: Add DT support for the DA8xx driver

[Petr Kulhavy]

This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver

Signed-off-by: Petr Kulhavy 
Tested-by: Petr Kulhavy 
---
v1: 

v2:
 - using standard MUSB properties "dr_mode", "mentor,power", "mentor,num-eps", 
"mentor,multipoint", "mentor,ram-bits"
 - using "ti," prefix instead of "da8xx," for specific property names
 - no wilcards in compatibility string
 - using CFGCHIP2_USB2PHYCLKMUX_SHIFT instead of CFGCHIP2_USB2PHYCLKMUX_OFFSET

v3:
 - DMA mask initialization corrected
 - removed extra #ifdef CONFIG_OF

v4:
 - compatibility string set to "ti,da830-musb"
 - "mentor,num-eps", "mentor,multipoint", "mentor,ram-bits" properties removed 
and hardcoded
 - "ti,phy20-clkmux-cfg" renamed to "ti,phy20-clkmux-pll" and changed to boolean
 - removed use of the DA8XX_SYSCFG0_VIRT macro

v5:
 - using CFGCHIP2_REFFREQ_ in get_phy_refclk_cfg()
 - simplified initialization of the hard coded config parameters
 - optimization CFGCHIP2 register update

v6:
 - using "ti,usb2-phy-" prefix instead of "ti,phy20-" for the specific 
properties
 - optimization CFGCHIP2 register update
 
v7:
 - pdata::power hard coded to 500mA

v8:
 - USB maximum power modelled via a regulator "vbus-supply"
 - "ti,usb2-phy-refclock-frequency" renamed to "ti,usb2-phy-refclock-hz"
 - "ti,usb2-phy-clkmux-pll" changed to "ti,usb2-phy-clkmux-refclkin" and the 
boolean meaning inverted to reflect the more common case

v9:
 - power regulator used only to get the current

v10:
 - corrected current calculation in get_vbus_power (missing divide by 2)

 drivers/usb/musb/da8xx.c | 106 +++
 1 file changed, 106 insertions(+)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index b03d3b8..52f2c3d 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
  * Based on the DaVinci "glue layer" code.
  * Copyright (C) 2005-2006 by Texas Instruments
  *
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy, Barix AG 
+ *
  * This file is part of the Inventra Controller Driver for Linux.
  *
  * The Inventra Controller Driver for Linux is free software; you
@@ -33,9 +36,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 
 #include "musb_core.h"
 
@@ -134,6 +139,55 @@ static inline void phy_off(void)
__raw_writel(cfgchip2, CFGCHIP2);
 }
 
+static inline int get_phy_refclk_cfg(struct device_node *np)
+{
+   u32 freq;
+
+   if (of_property_read_u32(np, "ti,usb2-phy-refclock-hz", ))
+   return -EINVAL;
+
+   switch (freq) {
+   case 1200:
+   return CFGCHIP2_REFFREQ_12MHZ;
+   case 1300:
+   return CFGCHIP2_REFFREQ_13MHZ;
+   case 1920:
+   return CFGCHIP2_REFFREQ_19_2MHZ;
+   case 2000:
+   return CFGCHIP2_REFFREQ_20MHZ;
+   case 2400:
+   return CFGCHIP2_REFFREQ_24MHZ;
+   case 2600:
+   return CFGCHIP2_REFFREQ_26MHZ;
+   case 3840:
+   return CFGCHIP2_REFFREQ_38_4MHZ;
+   case 4000:
+   return CFGCHIP2_REFFREQ_40MHZ;
+   case 4800:
+   return CFGCHIP2_REFFREQ_48MHZ;
+   default:
+   return -EINVAL;
+   }
+}
+
+static inline u8 get_vbus_power(struct device *dev)
+{
+   struct regulator *vbus_supply;
+   int current_uA;
+
+   vbus_supply = regulator_get(dev, "vbus");
+   if (IS_ERR(vbus_supply))
+   return 255;
+
+   current_uA = regulator_get_current_limit(vbus_supply);
+   regulator_put(vbus_supply);
+
+   if (current_uA <= 0 || current_uA > 51)
+   return 255;
+
+   return current_uA / 1000 / 2;
+}
+
 /*
  * Because we don't set CTRL.UINT, it's "important" to:
  * - not read/write INTRUSB/INTRUSBE (except during
@@ -482,6 +536,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask   = DMA_BIT_MASK(32),
 };
 
+static const struct musb_hdrc_config da8xx_config = {
+   .ram_bits = 10,
+   .num_eps = 5,
+   .multipoint = 1,
+};
+
 static int da8xx_probe(struct platform_device *pdev)
 {
struct resource musb_resources[2];
@@ -490,6 +550,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
struct clk  *clk;
+   struct device_node  *np = pdev->dev.of_node;
 
int ret = -ENOMEM;
 
@@ -515,6 +576,42 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev   = >dev;
glue->clk   = clk;
 
+   if (IS_ENABLED(CONFIG_OF) && np) {
+   int refclk_cfg;
+   u32 cfgchip2;
+
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   ret = 

[PATCH 4/5 v10] ARM: davinci: defined missing CFGCHIP2_REFFREQ_* macros for MUSB PHY

[Petr Kulhavy]

Only few MUSB PHY reference clock  frequencies were defined.
This patch defines macros for the missing frequencies:
19.2MHz, 38.4MHz, 13MHz, 26MHz, 20MHz, 40MHz

Signed-off-by: Petr Kulhavy 
Acked-by: Sergei Shtylyov 
Signed-off-by: Bin Liu 
---
v5: 
v6: 
v7: 
v8: 
v9: 
v10: 

 include/linux/platform_data/usb-davinci.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/platform_data/usb-davinci.h 
b/include/linux/platform_data/usb-davinci.h
index e0bc4ab..961d3dc 100644
--- a/include/linux/platform_data/usb-davinci.h
+++ b/include/linux/platform_data/usb-davinci.h
@@ -33,6 +33,12 @@
 #define CFGCHIP2_REFFREQ_12MHZ (1 << 0)
 #define CFGCHIP2_REFFREQ_24MHZ (2 << 0)
 #define CFGCHIP2_REFFREQ_48MHZ (3 << 0)
+#define CFGCHIP2_REFFREQ_19_2MHZ   (4 << 0)
+#define CFGCHIP2_REFFREQ_38_4MHZ   (5 << 0)
+#define CFGCHIP2_REFFREQ_13MHZ (6 << 0)
+#define CFGCHIP2_REFFREQ_26MHZ (7 << 0)
+#define CFGCHIP2_REFFREQ_20MHZ (8 << 0)
+#define CFGCHIP2_REFFREQ_40MHZ (9 << 0)
 
 struct da8xx_ohci_root_hub;
 
-- 
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 1/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Petr Kulhavy]

DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.

Signed-off-by: Petr Kulhavy 
---
v1: 

v2:
 - using standard properties "dr_mode", "mentor,power", "mentor,num-eps", 
"mentor,multipoint", "mentor,ram-bits"
 - using "ti," prefix instead of "da8xx," for specific property names
 - no wildcards in compatibility string

v3:
 - added "reg", "interrupts" and "interrupt-names" properties
 - wildcards in compatibility string

v4:
 - compatibility string set to "ti,da830-musb"
 - "mentor,num-eps", "mentor,multipoint", "mentor,ram-bits" properties removed 
and hardcoded
 - "ti,phy20-clkmux-cfg" renamed to "ti,phy20-clkmux-pll" and changed to boolean
 - removed "ti,hwmods"

v5:
 - "ti,phy20-refclock-frequency" property made mandatory

v6:
 - using "ti,usb2-phy-" prefix instead of "ti,phy20-" for the specific 
properties

v7:
 - removed the "mentor,power" property; hard coded to 500mA in the code

v8:
 - "ti,usb2-phy-refclock-frequency" renamed to "ti,usb2-phy-refclock-hz" and 
description amended
 - "ti,usb2-phy-clkmux-pll" changed to "ti,usb2-phy-clkmux-refclkin" to reflect 
the more common case
 - USB maximum power modelled via a regulator "vbus-supply"

v9: 
v10: 

 .../devicetree/bindings/usb/da8xx-usb.txt  | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt 
b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 000..a6eda5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,45 @@
+TI DA8xx MUSB
+~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or 
"otg".
+
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+ - ti,usb2-phy-refclock-hz : Integer. Frequency in Hz of the USB 2.0 PHY 
reference clock,
+ either provided by the internal PLL or an external source.
+ The supported values are: 12MHz, 13MHz, 19.2MHz, 20MHz, 24MHz, 26MHz, 
38.4MHz, 40MHz, 48MHz.
+
+
+Optional properties:
+
+ - ti,usb2-phy-clkmux-refclkin: Boolean. Defines the USB 2.0 PHY reference 
clock source.
+ If present the the external USB_REFCLKIN pin is used as a clock source, 
otherwise
+ the internal PLL is used.
+
+Example:
+
+   usb20: usb@1e0 {
+   compatible = "ti,da830-musb";
+   reg =   <0x0020 0x1>;
+   interrupt-parent = <>;
+   interrupts = <58>;
+   interrupt-names = "mc";
+
+   dr_mode = "host";
+   vbus-supply = <_vbus>;
+
+   ti,usb2-phy-refclock-hz = <2400>;
+
+   status = "okay";
+   };
-- 
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 3/5 v10] usb: musb: core: added missing const qualifier to musb_hdrc_platform_data::config

[Petr Kulhavy]

The musb_hdrc_platform_data::config was defined as a non-const pointer.
However some drivers (e.g. the ux500) set up this pointer to point to a
static structure, which is potentially dangerous. Since the musb core
uses the pointer in a read-only manner the const qualifier was added to
protect the content of the config.

Signed-off-by: Petr Kulhavy 
Acked-by: Sergei Shtylyov 
Signed-off-by: Bin Liu 
---
v5: 

v6:
 - whitespace formatting corrected

v7: 
v8: 
v9: 
v10: 

 drivers/usb/musb/musb_core.c | 2 +-
 drivers/usb/musb/musb_core.h | 2 +-
 include/linux/usb/musb.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 6a2d6d3..b0be1a9 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1920,7 +1920,7 @@ static void musb_recover_from_babble(struct musb *musb)
  */
 
 static struct musb *allocate_instance(struct device *dev,
-   struct musb_hdrc_config *config, void __iomem *mbase)
+   const struct musb_hdrc_config *config, void __iomem *mbase)
 {
struct musb *musb;
struct musb_hw_ep   *ep;
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 3f7a325..a062185 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -438,7 +438,7 @@ struct musb {
 */
unsigneddouble_buffer_not_ok:1;
 
-   struct musb_hdrc_config *config;
+   const struct musb_hdrc_config *config;
 
int xceiv_old_state;
 #ifdef CONFIG_DEBUG_FS
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 96ddfb7..0b3da40 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -124,7 +124,7 @@ struct musb_hdrc_platform_data {
int (*set_power)(int state);
 
/* MUSB configuration-specific details */
-   struct musb_hdrc_config *config;
+   const struct musb_hdrc_config *config;
 
/* Architecture specific board data */
void*board_data;
-- 
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