Hi All,
Can you please help me understand the assignment of
bConfigurationValue in gadget serial driver.
As I had mentioned in my previous mail,
I agree that no two configurations can have same bConfigurationValue,
but in this case, the implementation is (drivers/usb/gadget/serial.c)
247
Hi,
usb_stor_euscsi_init() calls usb_stor_control_msg() with timeout argument
5000. USB_CTRL_SET_TIMEOUT is defined to be 5000 in usb.h, so would it make
sense to use that instead? Patch below if it would.
Signed-off-by: Mark Knibbs
---
diff -up linux-3.17-rc5/drivers/usb/storage/initializers.c
Anjana V Kumar wrote:
> I am using 3.10 kernel. The issue is that the set_configuration(2)
> is stalled, while the set_configuration(1) passes with the USB
> hardware I am using.
What USB hardware are you using?
Why not look into the actual problem with SET_CONFIGURATION? You may
discover things
> Subject: Re: FIX ME in oxu210p-hcd.c
>
>
> I found a unfixed FIX ME in the file stated in my above message. I am
> wondering what to set hcd->self.comtroller->dma_mask to as it's now been
> defined to NULL and clearly even as a newbie this seem incorrect.
> Regards Nick
Usually, it is set a
From: Stefan Agner
This adds Vybrid VF610 SoC support. The IP is very similar to i.MX6,
however, the non-core registers are spread in two different register
areas. Hence we support multiple instances of the USB misc driver
and add the driver instance to the imx_usbmisc_data structure.
Signed-off
Hi Greg,
Below are chipdea patches for v3.18-rc1, they are based on your
latest usb-next, and have verfied at i.mx6sx sabresd board.
Thanks.
Peter Chen (3):
usb: chipidea: otg initialization is only needed when the gadget is
supported
usb: chipidea: enhance kernel-doc format
of: add ve
Some kernel-doc style comment are not satisfied for format, fix them.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci.h | 14 ++
drivers/usb/chipidea/core.c |8 +++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/
Adds chipidea to the list of DT vendor prefixes.
Signed-off-by: Peter Chen
---
.../devicetree/bindings/vendor-prefixes.txt|1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
We have only needed to enable otg initialization when both of
below conditions are satisfied:
- The controller is otg capable
- The gadget function is enabled
If the controller is otg capable, but is host-only configuration, we do
not need to access register otgsc and do any otg operations (eg, c
>
> On Thu, Sep 11, 2014 at 07:57:12AM +0800, Peter Chen wrote:
> > On Fri, Sep 05, 2014 at 10:08:02AM -0400, Alan Stern wrote:
> > > On Fri, 5 Sep 2014, Peter Chen wrote:
> > >
> > > > On Thu, Sep 04, 2014 at 11:12:42AM -0400, Alan Stern wrote:
> > > > > On Thu, 4 Sep 2014, Peter Chen wrote:
>
Hi Vivek,
> Hi Anton,
>
>
> On Fri, Sep 19, 2014 at 1:05 PM, Anton Tikhomirov
> wrote:
> > According to user manual, pcs_tx_deemph_3p5db field in PHYPARAM1
> > register is 6bits wide, so mask value should be 0x3f instead
> > of 0x1f.
> >
> > Signed-off-by: Anton Tikhomirov
> > ---
> > drivers
According to user manual, pcs_tx_deemph_3p5db field in PHYPARAM1
register is 6bits wide, so mask value should be 0x3f instead
of 0x1f. Additionally, this patch renames the macro to correctly
reflect the field name which we see in SoC documentation.
Signed-off-by: Anton Tikhomirov
---
drivers/phy
On Monday, September 22, 2014 10:37 AM, Anton Tikhomirov wrote:
>
> According to user manual, pcs_tx_deemph_3p5db field in PHYPARAM1
> register is 6bits wide, so mask value should be 0x3f instead
> of 0x1f. Additionally, this patch renames the macro to correctly
> reflect the field name which we s
On 14-09-21 07:53 PM, Peter Chen wrote:
>
>
>> Subject: Re: FIX ME in oxu210p-hcd.c
>>
>>
>> I found a unfixed FIX ME in the file stated in my above message. I am
>> wondering what to set hcd->self.comtroller->dma_mask to as it's now been
>> defined to NULL and clearly even as a newbie this se
> >> Subject: Re: FIX ME in oxu210p-hcd.c
> >>
> >>
> >> I found a unfixed FIX ME in the file stated in my above message. I am
> >> wondering what to set hcd->self.comtroller->dma_mask to as it's now
> >> been defined to NULL and clearly even as a newbie this seem incorrect.
> >> Regards Nick
>
On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote:
>
>
> On 14-09-21 07:53 PM, Peter Chen wrote:
> >
> >
> >> Subject: Re: FIX ME in oxu210p-hcd.c
> >>
> >>
> >> I found a unfixed FIX ME in the file stated in my above message. I am
> >> wondering what to set hcd->self.comtroller->dma_mask t
On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote:
> On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote:
>>
>>
>> On 14-09-21 07:53 PM, Peter Chen wrote:
>>>
>>>
Subject: Re: FIX ME in oxu210p-hcd.c
I found a unfixed FIX ME in the file stated in my above message. I am
On Sun, Sep 21, 2014 at 10:17:38PM -0400, nick wrote:
>
>
> On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote:
> > On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote:
> >>
> >>
> >> On 14-09-21 07:53 PM, Peter Chen wrote:
> >>>
> >>>
> Subject: Re: FIX ME in oxu210p-hcd.c
>
> >
On 14-09-21 10:11 PM, Peter Chen wrote:
>
>
Subject: Re: FIX ME in oxu210p-hcd.c
I found a unfixed FIX ME in the file stated in my above message. I am
wondering what to set hcd->self.comtroller->dma_mask to as it's now
been defined to NULL and clearly even as a ne
On 14-09-21 10:24 PM, gre...@linuxfoundation.org wrote:
> On Sun, Sep 21, 2014 at 10:17:38PM -0400, nick wrote:
>>
>>
>> On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote:
>>> On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote:
On 14-09-21 07:53 PM, Peter Chen wrote:
>
>
Damm, didn't configure my kill-file correctly, and this snuck in, so
might as well respond...
On Sun, Sep 21, 2014 at 10:36:18PM -0400, nick wrote:
> On 14-09-21 10:24 PM, gre...@linuxfoundation.org wrote:
> >> Sorry Greg,
> >> I don't want to get banned again. I was trying to help out and learn,
On Mon, Sep 22, 2014 at 7:06 AM, Anton Tikhomirov
wrote:
> According to user manual, pcs_tx_deemph_3p5db field in PHYPARAM1
> register is 6bits wide, so mask value should be 0x3f instead
> of 0x1f. Additionally, this patch renames the macro to correctly
> reflect the field name which we see in SoC
On Thu, Sep 18, 2014 at 8:20 PM, Alan Stern wrote:
> On Thu, 18 Sep 2014, Vivek Gautam wrote:
>
>> Now that we have completely moved from older USB-PHY drivers
>> to newer GENERIC-PHY drivers for PHYs available with USB controllers
>> on Exynos series of SoCs, we can remove the support for the sam
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for our host in case we end up getting
EPROBE_DEFER er
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
We also defer the probe for our host in case we end up getting
EPROBE_DEFER er
25 matches
Mail list logo
