Hi,
Peter Chen writes:
>> >>> +
>> >>> +/* start host */
>> >>> +ret = hcd_ops->add(otg->primary_hcd.hcd,
>> >>> + otg->primary_hcd.irqnum,
>> >>> + otg->primary_hcd.irqflags);
>> >>
>> >> this i
Hi,
Peter Chen writes:
>> >> > It provides APIs for the following tasks
>> >> >
>> >> > - Registering an OTG/dual-role capable controller
>> >> > - Registering Host and Gadget controllers to OTG core
>> >> > - Providing inputs to and kicking the OTG state machine
>> >>
>> >> I think I have alre
Hi,
Yoshihiro Shimoda writes:
> Hi Roger,
>
>> From: Roger Quadros
>> Sent: Monday, June 20, 2016 7:13 PM
>>
>> Hi,
>>
>> On 20/06/16 10:45, Felipe Balbi wrote:
> < snip >
>> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> index f4fc0aa..1d74fb8 100644
>> >> --- a
Because of recent changes to transfer handling on
DWC3, we will not get XferComplete unless we
completely fill up our TRB ring. This means that we
might get a Reset or Disconnect without getting a
XferComplete first.
In order to correctly release our allocated Transfer
Resource, we must issue ENDT
Hi Baolin,
Baolin Wang writes:
>>> -Original Message-
>>> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>>> ow...@vger.kernel.org] On Behalf Of Baolin Wang
>>> Sent: Monday, June 13, 2016 4:47 PM
>>> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
>>> dbarys
Hi Greg
These patches for 4.8 contain td-fragment work that ensures bulk tranfers
finally follows the aligment requirements in the xhci specs.
Also reworking helper functions for checking last and link trbs,
and cleanups for platform data
-Mathias
Heikki Krogerus (3):
xhci: plat: adapt to uni
If a zero-length packet is needed after a bulk transfer, then an
additional zero length TD was prepared before enqueueing the bulk transfer
This set up the zero packet TD structure with incorrect td->start_seg
and td->first_trb pointers.
Prepare the zero packet TD after the data bulk TD is enqueue
We only need to know if we are queuing the last trb for a TD when
calculating the td remainder field.
The total number of trbs left is not used.
We won't be able to trust the pre-calculated number of trbs used if we
need to align trb data by splitting or merging trbs in order to satisfy
comply wit
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to ali
Add a new is_link_trb() function that only checks for link trbs.
We want to split generic last_trb() function which is used for both
event rings without link trbs, and endpoint and command rings with links.
This will allow us to easier check for link trbs added mid segments.
Signed-off-by: Mathia
Remove the event ring related checks in inc_enq()
Host hardware is the producer of events on the event ring,
driver will not queue anything, or call inc_enq() for the
event ring.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 64 +++-
1 f
Tiny change, a bit more readable.
The real reason for this change is that the coming td fragment work
had several over 80 lines character lines split just because of a few
extra characters in variable names.
no functional changes
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 2
Queue trbs until all payload data in the urb is tranferred.
The actual number of trbs might need to change from the pre-calculated
number when the packet alignment restrictions for td fragments in
xhci 4.11.7.1 are taken into account.
Long term plan is to get rid of calculating the needed trbs in
TD fragments section 4.11.7.1 in xhci specs have additional requirements
on how trbs in TDs must be organized.
TD fragments shall not span transfer ring segments and TD fragments must
be packet aligned. Normally we don't care about TD fragments, on TD is one
big fragment, but if a TD spans ring se
Hi,
John Youn writes:
> On 5/25/2016 6:06 PM, John Youn wrote:
>> The following patch series fixes up isochronous support for the dwc2
>> gadget. The existing isochronous support lacked a few features. Most
>> notably it did not properly sync up with the first packet and it
>> didn't handle the
Hi Heiko,
On 2016/6/20 12:56, Guenter Roeck wrote:
Hi Frank,
On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang wrote:
Hi Heiko & Guenter,
On 2016/6/20 11:00, Guenter Roeck wrote:
On Sun, Jun 19, 2016 at 6:27 PM, Frank Wang
wrote:
Hi Guenter,
On 2016/6/17 21:20, Guenter Roeck wrote:
Hi Frank
Krzysztof Opasiak writes:
> Hi,
>
> On Tue, Jun 7, 2016 at 3:27 AM, Peter Chen wrote:
>> On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote:
>>> Currently it is possible to build in some subset of usb functions
>>> *OR* some gadget module. This is limited only by Kconfig not
>>> a
Only used in one place, replace with trb_is_link() helper
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 086b871..2d8dcb1f 100644
--- a/driv
inc_deq() is called both for rings with link trbs and the event ring
without link trbs.
The last_trb() check in inc_deq() has a off by one error, going beyond
allocated array when checking if trb == [TRBS_PER_SEGMENT], and the whole
inc_deq() depend on this.
Rewrite the inc_deq() funciton, remove
Hi Felipe,
On 21 June 2016 at 15:45, Felipe Balbi wrote:
>
> Hi Baolin,
>
> Baolin Wang writes:
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
ow...@vger.kernel.org] On Behalf Of Baolin Wang
Sent: Monday, June 13, 2016 4:47 PM
To: ba.
It's only used with rings that have link trbs
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 65 +---
1 file changed, 25 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 2d8dcb1
Hi,
John Youn writes:
> On 6/3/2016 8:59 AM, dingu...@opensource.altera.com wrote:
>> 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
>> Acked-by: John Youn
>> Tested-by: Stefan Wa
On Tue, Jun 21, 2016 at 10:19:32AM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> >> >>> +
> >> >>> + /* start host */
> >> >>> + ret = hcd_ops->add(otg->primary_hcd.hcd,
> >> >>> + otg->primary_hcd.irqnum,
> >> >>> +
Hi,
William Wu writes:
> This patch adds the devicetree documentation required for Rockchip
> USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.
>
> It supports DRD mode, and could operate in device mode (SS, HS, FS)
> and host mode (SS, HS, FS, LS).
>
> Signed-off-by: William Wu
I'm d
Hi,
Peter Chen writes:
>> Peter Chen writes:
>> >> >>> +
>> >> >>> + /* start host */
>> >> >>> + ret = hcd_ops->add(otg->primary_hcd.hcd,
>> >> >>> +otg->primary_hcd.irqnum,
>> >> >>> +otg->primary_hcd.irqf
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-
When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function and usb_charger_exit()
function by getting 'struct usb_charger' from 'struct gadget'.
Signed-off-by: Baolin Wang
Reviewed-by: Li Jun
Tested-by: Li Jun
---
drivers/us
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.
Signed-off-by: Baolin Wang
Reviewed-by: Li Ju
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 b
Dear Heiko,
On 06/20/2016 10:44 PM, Heiko Stübner wrote:
Hi William,
Am Freitag, 17. Juni 2016, 17:18:59 schrieb William Wu:
On 06/17/2016 07:15 AM, Heiko Stübner wrote:
Am Donnerstag, 2. Juni 2016, 20:34:56 schrieb William Wu:
This patch adds the devicetree documentation required for Rockch
On Tue, Jun 21, 2016 at 10:26:00AM +0300, Felipe Balbi wrote:
>
> Hi,
>
> >>
> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> when they say OTG. Usually they just mean "a method for swapping between
> >> host and peripheral roles, but we really don't want all the ex
Hi Heiko,
On 2016/6/21 17:05, Heiko Stübner wrote:
Hi Frank,
Am Dienstag, 21. Juni 2016, 15:52:45 schrieb Frank Wang:
On 2016/6/20 12:56, Guenter Roeck wrote:
On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang
wrote:
Turns out my problem was one of terminology. Using "suspend" and
"resume" to me
Hi Frank,
Am Dienstag, 21. Juni 2016, 15:52:45 schrieb Frank Wang:
> On 2016/6/20 12:56, Guenter Roeck wrote:
> > On Sun, Jun 19, 2016 at 8:32 PM, Frank Wang
wrote:
> >>> Turns out my problem was one of terminology. Using "suspend" and
> >>> "resume" to me suggested the common use of suspend and
Hi,
Peter Chen writes:
>> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> when they say OTG. Usually they just mean "a method for swapping between
>> >> host and peripheral roles, but we really don't want all the extra cost
>> >> of the OTG specification".
>> >>
>>
Hi,
Arnd Bergmann writes:
> I stumbled over this warning last week, which showed up after I had
> removed an incorrect patch from my randconfig build setup:
>
> drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_probe':
> drivers/usb/phy/phy-msm-usb.c:1735:14: error: 'regs[0].consumer' may be u
From: Heikki Krogerus
This should allow xhci to remove handling of platform data.
Signed-off-by: Heikki Krogerus
Cc: Felipe Balbi
Signed-off-by: Mathias Nyman
---
drivers/usb/dwc3/host.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/h
Mathias Nyman writes:
> From: Heikki Krogerus
>
> This should allow xhci to remove handling of platform data.
>
> Signed-off-by: Heikki Krogerus
> Cc: Felipe Balbi
Cc: Felipe Balbi
Acked-by: Felipe Balbi
> Signed-off-by: Mathias Nyman
> ---
> drivers/usb/dwc3/host.c | 18 +---
Hi,
Baolin Wang writes:
> This patch introduces the usb charger driver based on usb gadget that
> makes an enhancement to a power driver. It works well in practice but
> that requires a system with suitable hardware.
>
> The basic conception of the usb charger is that, when one usb charger
> is
Signed-off-by: Frank Wang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v7: None
Changes in v6:
- Changed '_' to '-' for otg-id and otg-bvalid property.
Changes in v5:
- Added 'reg' property to identify the different phy-blocks.
Changes in v4:
- Used 'phy-supply' instea
The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
than rk3288 and before, and most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.
Signed-off-by: Frank Wang
Suggested-by: Heiko Stuebner
Suggested-by: Guenter Roeck
Suggested
From: Iago Abal
Fixes: d3cb25a12138 (usb: gadget: udc: fix spin_lock in pch_udc)
The above commit reordered spin_lock/unlock and now `&dev->lock' is acquired
(rather than released) before calling `dev->driver->disconnect',
`dev->driver->setup', `dev->driver->suspend', `usb_gadget_giveback_reques
The newer SoCs (rk3366, rk3399) of Rock-chip take a different usb-phy
IP block than rk3288 and before, and most of phy-related registers are
also different from the past, so a new phy driver is required necessarily.
These series patches add phy-rockchip-inno-usb2.c and the corresponding
documentat
Hi,
Baolin Wang writes:
> @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device
> *pdev)
> }
> }
>
> + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> + power->usb_charger =
> + usb_charger_find_by_name(wm831x_pdata
* Felipe Balbi [160621 03:06]:
> 8<--
> vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
> id = read(ID_STATE); /* could be a gpio_get_value() */
>
> set_role(id);
> set_vbus(vbus);
We sho
Hi,
Tony Lindgren writes:
> * Felipe Balbi [160621 03:06]:
>> 8<--
>> vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>> id = read(ID_STATE); /* could be a gpio_get_value() */
>>
>> set_role(id)
From: Heikki Krogerus
Requesting the only property that the driver needs using the
unified device property interface so it will be available
for all types of platforms, not just the ones using DT.
Signed-off-by: Heikki Krogerus
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-plat.c | 5
Hi,
Baolin Wang writes:
> For supporting the usb charger, it adds the usb_charger_init() and
> usb_charger_exit() functions for usb charger initialization and exit.
>
> It will report to the usb charger when the gadget state is changed,
> then the usb charger can do the power things.
>
> Signed-
On Tue, Jun 21, 2016 at 01:30:49PM +0300, Felipe Balbi wrote:
> Baolin Wang writes:
> > @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device
> > *pdev)
> > }
> > }
> > + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> > + power->usb_charger =
>
On 21 June 2016 at 18:27, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> For supporting the usb charger, it adds the usb_charger_init() and
>> usb_charger_exit() functions for usb charger initialization and exit.
>>
>> It will report to the usb charger when the gadget state is changed,
>>
On 21 June 2016 at 19:03, Mark Brown wrote:
> On Tue, Jun 21, 2016 at 01:30:49PM +0300, Felipe Balbi wrote:
>> Baolin Wang writes:
>> > @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device
>> > *pdev)
>> > }
>> > }
>
>> > + if (wm831x_pdata && wm831x_pdata-
On Tue, Jun 21, 2016 at 11:18:21AM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> >> Peter Chen writes:
> >> >> >>> +
> >> >> >>> + /* start host */
> >> >> >>> + ret = hcd_ops->add(otg->primary_hcd.hcd,
> >> >> >>> + otg->primary_hc
Hi,
Mark Brown writes:
> [ Unknown signature status ]
> On Tue, Jun 21, 2016 at 01:30:49PM +0300, Felipe Balbi wrote:
>> Baolin Wang writes:
>> > @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device
>> > *pdev)
>> >}
>> >}
>
>> > + if (wm831x_pdata && wm83
On 21 June 2016 at 19:53, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> On 21 June 2016 at 19:03, Mark Brown wrote:
>>> On Tue, Jun 21, 2016 at 01:30:49PM +0300, Felipe Balbi wrote:
Baolin Wang writes:
> @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct
> platfo
On 21 June 2016 at 19:49, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>>> Can't you just tie a charger to a UDC and avoid the charger class
>>> completely?
>>
>> Yeah, I also hope so. But we really want something to manage the
>> charger devices, do you have any good suggestion to avoid t
From: Heikki Krogerus
No more users for it.
Signed-off-by: Heikki Krogerus
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-plat.c | 5 +
include/linux/usb/xhci_pdriver.h | 27 ---
2 files changed, 1 insertion(+), 31 deletions(-)
delete mode 100644 incl
Hi,
Baolin Wang writes:
> On 21 June 2016 at 19:03, Mark Brown wrote:
>> On Tue, Jun 21, 2016 at 01:30:49PM +0300, Felipe Balbi wrote:
>>> Baolin Wang writes:
>>> > @@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device
>>> > *pdev)
>>> > }
>>> > }
>>
>>> >
On 21 June 2016 at 20:27, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>>> Baolin Wang writes:
> Can't you just tie a charger to a UDC and avoid the charger class
> completely?
Yeah, I also hope so. But we really want something to manage the
charger devices, do you
Hi,
Peter Chen writes:
>> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with OTG
>> >> >> >>> core.
>> >> >> >>
>> >> >> >> do you really know of any platform which has a separate OTG
>> >> >> >> controller?
>> >> >> >>
>> >> >> >
>> >> >> > Andrew had pointed out in [1]
Hi,
Baolin Wang writes:
>> Baolin Wang writes:
Baolin Wang writes:
>> Can't you just tie a charger to a UDC and avoid the charger class
>> completely?
>
> Yeah, I also hope so. But we really want something to manage the
> charger devices, do you have any good suggestio
Hi,
Baolin Wang writes:
>> Baolin Wang writes:
Can't you just tie a charger to a UDC and avoid the charger class
completely?
>>>
>>> Yeah, I also hope so. But we really want something to manage the
>>> charger devices, do you have any good suggestion to avoid the 'class'
>>> but also
On 21 June 2016 at 20:36, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>>> Baolin Wang writes:
> Baolin Wang writes:
>>> Can't you just tie a charger to a UDC and avoid the charger class
>>> completely?
>>
>> Yeah, I also hope so. But we really want something to manag
Hi,
Baolin Wang writes:
Can't you just tie a charger to a UDC and avoid the charger class
completely?
>>>
>>> Yeah, I also hope so. But we really want something to manage the
>>> charger devices, do you have any good suggestion to avoid the 'class'
>>> but also
On 21 June 2016 at 18:25, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> This patch introduces the usb charger driver based on usb gadget that
>> makes an enhancement to a power driver. It works well in practice but
>> that requires a system with suitable hardware.
>>
>> The basic concept
Hi,
Felipe Balbi writes:
> Can't you just tie a charger to a UDC and avoid the charger class
> completely?
Yeah, I also hope so. But we really want something to manage the
charger devices, do you have any good suggestion to avoid the 'class'
bu
On 06/21/2016 06:08 AM, Oliver Neukum wrote:
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
The purpose of this class is to provide unified interface for user
space to get the status and basic information about USB Type-C
Connectors in the system, control data role swapping, and when
On Tue, Jun 21, 2016 at 03:35:00PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with
> >> >> >> >>> OTG core.
> >> >> >> >>
> >> >> >> >> do you really know of any platform which has a separate OTG
> >> >> >>
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> The purpose of this class is to provide unified interface for user
> space to get the status and basic information about USB Type-C
> Connectors in the system, control data role swapping, and when USB PD
> is available, also power role swa
On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > The purpose of this class is to provide unified interface for user
> > space to get the status and basic information about USB Type-C
> > Connectors in the system, control
Hi,
Baolin Wang writes:
>> Can't you just tie a charger to a UDC and avoid the charger class
>> completely?
>
> Yeah, I also hope so. But we really want something to manage the
> charger devices, do you have any good suggestion to avoid the 'class'
> but also can manage the charger devices?
man
Hi,
Peter Chen writes:
>> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with
>> >> >> >> >>> OTG core.
>> >> >> >> >>
>> >> >> >> >> do you really know of any platform which has a separate OTG
>> >> >> >> >> controller?
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Andre
Hi,
I'm considering all the RFCs I send after v1 as v2 (I don't remember
how many I send). Hope this is OK and hope there is nothing big
missing anymore (or broken).
Sorry about the delay. I've been really busy with some internal tasks.
I'm guessing we missed v4.8 with this thing. I'm sorry about
The purpose of USB Type-C connector class is to provide
unified interface for the user space to get the status and
basic information about USB Type-C connectors on a system,
control over data role swapping, and when USB PD is
available, also control over power role swapping and
Alternate Modes.
Si
This adds driver for the USB Type-C PHY on Intel WhiskeyCove
PMIC which is available on some of the Intel Broxton SoC
based platforms.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/Kconfig | 14 ++
drivers/usb/typec/Makefile | 1 +
drivers/usb/typec/typec_wcove.c | 376 +
Hi,
Baolin Wang writes:
>>> This patch introduces the usb charger driver based on usb gadget that
>>> makes an enhancement to a power driver. It works well in practice but
>>> that requires a system with suitable hardware.
>>>
>>> The basic conception of the usb charger is that, when one usb cha
On Tue, Jun 21, 2016 at 02:50:27PM +0300, Felipe Balbi wrote:
> Mark Brown writes:
> > The wm831x has no DT support currently.
> okay, perhaps its time to add it.
The only platform using it would need the DT connector overlays
completing in order to be able to convert to DT. I'm really not
con
On 21/06/2016 at 09:32:44 +0800, Wenyou Yang wrote :
> In order to save power consumption, as a workaround, forcibly suspend
> the USB PORTA/B/C via setting the SUSPEND_A/B/C bits of OHCI Interrupt
> Configuration Register in the SFR while OHCI USB suspend.
>
> This suspend operation must be done
Le 21/06/2016 03:32, Wenyou Yang a écrit :
> In order to save power consumption, as a workaround, forcibly suspend
> the USB PORTA/B/C via setting the SUSPEND_A/B/C bits of OHCI Interrupt
> Configuration Register in the SFR while OHCI USB suspend.
>
> This suspend operation must be done before the
On Tue, 21 Jun 2016, Nicolas Ferre wrote:
> Le 21/06/2016 03:32, Wenyou Yang a �crit :
> > In order to save power consumption, as a workaround, forcibly suspend
> > the USB PORTA/B/C via setting the SUSPEND_A/B/C bits of OHCI Interrupt
> > Configuration Register in the SFR while OHCI USB suspend.
On Tue, Jun 21, 2016 at 01:02:59PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> >> when they say OTG. Usually they just mean "a method for swapping between
> >> >> host and peripheral roles, but we rea
The usbhs_write32 function is not used outside of the rcar3.c
file, so fix the following sparse warning by making it static:
drivers/usb/renesas_usbhs/rcar3.c:26:6: warning: symbol 'usbhs_write32' was not
declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Yoshihiro Shimoda
Cc: Gre
On 6/21/2016 1:06 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> On 6/3/2016 8:59 AM, dingu...@opensource.altera.com wrote:
>>> 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
On 06/21/2016 02:15 PM, John Youn wrote:
>
> Can you resend this to Philipp Zabel.
>
> Hi Philipp,
>
> Could you take this in your reset/next tree? It depends on the
> following patch there:
>
> http://marc.info/?l=linux-usb&m=146473891018262&w=2
>
I've resent that patch to Philipp.
Thanks,
On Tue, 2016-06-21 at 06:24 -0700, Guenter Roeck wrote:
> On 06/21/2016 06:08 AM, Oliver Neukum wrote:
> > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> >> The purpose of this class is to provide unified interface for user
> >> space to get the status and basic information about USB T
On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote:
> +What: /sys/class/typec//supported_data_roles
> +Data: June 2016
> +Contact: Heikki Krogerus
> +Description:
> + Lists the USB data roles, host or device, the port is
> capable
> + of su
On Tue, 2016-06-21 at 16:58 +0300, Heikki Krogerus wrote:
> On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote:
>
> > The firmware will surely want to display something. So it is possible
> > that we start the OS will a valid power contract. How do we deal
> > with that? Renegotiate?
>
On Tue, Jun 21, 2016 at 10:11:17AM +0800, Peter Chen wrote:
> On Mon, Jun 20, 2016 at 11:16:07AM -0500, Rob Herring wrote:
> > On Mon, Jun 20, 2016 at 07:26:51PM +0800, Peter Chen wrote:
> > > On Fri, Jun 17, 2016 at 12:16:48PM -0500, Rob Herring wrote:
> > > > On Fri, Jun 17, 2016 at 5:09 AM, Pete
On Tue, Jun 21, 2016 at 09:43:20PM +0200, Oliver Neukum wrote:
> On Tue, 2016-06-21 at 06:24 -0700, Guenter Roeck wrote:
> > On 06/21/2016 06:08 AM, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > >> The purpose of this class is to provide unified interface
On Tue, Jun 21, 2016 at 05:51:49PM +0300, Heikki Krogerus wrote:
> Hi,
>
> I'm considering all the RFCs I send after v1 as v2 (I don't remember
> how many I send). Hope this is OK and hope there is nothing big
> missing anymore (or broken).
>
> Sorry about the delay. I've been really busy with so
Introduces a new FunctionFS descriptor flag named
FUNCTIONFS_ALL_CTRL_RECIP. When this flag is enabled, control requests,
which are not explicitly directed to an interface or endpoint, can be
handled.
This allows FunctionFS userspace drivers to process non-standard
control requests.
Signed-off-by
Introduces a new FunctionFS descriptor flag named
FUNCTIONFS_CONFIG0_SETUP.
When this flag is enabled, FunctionFS userspace drivers can process
non-standard control requests in configuration 0.
Signed-off-by: Felix Hädicke
---
drivers/usb/gadget/function/f_fs.c | 5 +++--
include/uapi/linux/us
It can sometimes be necessary for gadget drivers to process non-standard
control requests, which host devices can send without having sent
USB_REQ_SET_CONFIGURATION.
Therefore, the req_match() usb_function method is enhanced with the new
parameter "config0". When a USB configuration is active, thi
On Tue, Jun 21, 2016 at 04:26:53PM -0500, Rob Herring wrote:
> On Tue, Jun 21, 2016 at 10:11:17AM +0800, Peter Chen wrote:
> > On Mon, Jun 20, 2016 at 11:16:07AM -0500, Rob Herring wrote:
> > > On Mon, Jun 20, 2016 at 07:26:51PM +0800, Peter Chen wrote:
> > > > On Fri, Jun 17, 2016 at 12:16:48PM -0
On 21 June 2016 at 20:53, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
> Can't you just tie a charger to a UDC and avoid the charger class
> completely?
Yeah, I also hope so. But we really want something to manage the
charger devices, do you have
On 21 June 2016 at 22:50, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The bas
Signed-off-by: Bruno Herrera
---
drivers/usb/dwc2/core.c | 18 ++
drivers/usb/dwc2/core.h | 5 +
drivers/usb/dwc2/hcd.c | 12 +++-
drivers/usb/dwc2/hw.h | 2 ++
drivers/usb/dwc2/platform.c | 37 +
5 files changed
Signed-off-by: Bruno Herrera
---
arch/arm/boot/dts/stm32f429-disco.dts | 30 ++
arch/arm/boot/dts/stm32f429.dtsi | 33 -
arch/arm/boot/dts/stm32f469-disco.dts | 30 ++
3 files changed, 92 insertions(+), 1
Signed-off-by: Bruno Herrera
---
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 20a68bf..79e5370 100644
--- a/Documentation/devicetree/binding
On Tue, Jun 21, 2016 at 05:47:47PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> >> >> >> >> >>> + * @otg_dev: OTG controller device, if needs to be used with
> >> >> >> >> >>> OTG core.
> >> >> >> >> >>
> >> >> >> >> >> do you really know of any platform which has a separate OTG
Hi,
I am using linux kernel 4.1.15Here is the "lsusb -tv² output (Just shown
related devices)
# lsusb -tv
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
|__ Port 1: Dev 2, If 0, Class=Communications, Driver=cdc_acm, 12M
|__ Port 1: Dev 2, If 1, Class=CDC Data, Driver=cdc
1 - 100 of 104 matches
Mail list logo
