Hi folks,
I'm trying to find out which CPU's that are supported by Linux have
USB controllers that support gadget mode.
In theory, this should be a relatively straightforward matter, given
the device tree descriptions, I think. But I am struggling to figure
out how to actually create a list of th
Hi Felipe,
On Mon, Dec 4, 2017 at 1:36 PM, Felipe Balbi wrote:
>
> Hi,
>
> Ruslan Bilovol writes:
>> On Tue, Nov 7, 2017 at 3:52 AM, Ruslan Bilovol
>> wrote:
>>> Hi,
>>>
>>> This patch adds USB Audio Device Class 3.0 [1] function
>>> support to gadget subsystem.
>>> I didn't add UAC3 support t
Hi,
Ruslan Bilovol writes:
> On Tue, Nov 7, 2017 at 3:52 AM, Ruslan Bilovol
> wrote:
>> Hi,
>>
>> This patch adds USB Audio Device Class 3.0 [1] function
>> support to gadget subsystem.
>> I didn't add UAC3 support to legacy gadget as it will
>> make preprocessor configuration too complex (UAC
-ci/linux/commits/Ruslan-Bilovol/usb-gadget-add-USB-Audio-Device-Class-3-0-gadget-support/20171107-175202
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
coccinelle warnings: (new ones prefixed by >>)
>> drivers/usb/gadget/function/f_uac3.c:766:2-9: alloc
/linux/commits/Ruslan-Bilovol/usb-gadget-add-USB-Audio-Device-Class-3-0-gadget-support/20171107-175202
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the
On Tue, Nov 7, 2017 at 3:52 AM, Ruslan Bilovol wrote:
> Hi,
>
> This patch adds USB Audio Device Class 3.0 [1] function
> support to gadget subsystem.
> I didn't add UAC3 support to legacy gadget as it will
> make preprocessor configuration too complex (UAC3 device
> must have two configurations f
0 > configs/c.2/MaxPower
ln -s functions/uac3.0 configs/c.2
echo 0x0101 > idProduct
echo 0x1d6b > idVendor
echo my-serial-num > strings/0x409/serialnumber
echo my-manufacturer > strings/0x409/manufacturer
echo musb-hdrc.0 > UDC
[1] http://www.usb.org/developers/docs/devclass_d
Device
Definition) on each ADC3.0 compliant device
This patch adds UAC3 gadget support basing on UAC3
specification, implementing Generic I/O Profile
(BAOF + BAIF) from BADD document.
There are still few areas for future improvements
because not all functionality is completely
implemented, for
Sending v2 of this patch series, including fixes for build regressions
introduced with the original series. I missed the usage of f_uac* in the
legacy modules and did not test that. Fixed now, see patches changelog for
details.
This patch series adds support for exposing multiple supported samplin
This patch series adds support for exposing multiple supported sampling rates
from UAC1 and UAC2 USB gadgets to the connected host. It is currently limited
to up to ten discrete sampling frequencies. The USB specification does not
actually limit this, but to avoid complex list handling I am using a
On 20 February 2017 at 18:08, kbuild test robot wrote:
> Hi Baolin,
>
> [auto build test ERROR on v4.9-rc8]
> [cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> ur
Hi Baolin,
[auto build test ERROR on v4.9-rc8]
[cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-
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
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
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
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
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
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
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 char
Hi Felipe,
On 29 June 2016 at 20:06, 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
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
On 29 June 2016 at 16:34, 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 stat
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
Hi Felipe,
On 29 June 2016 at 16:20, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>>> 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
Hi,
Baolin Wang writes:
>> 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 ca
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
Hi,
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 change
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
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,
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
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 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:
>> 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
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
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
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
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,
>>
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-
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
..@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 2/4] gadget: Support for the usb charger
> framework
>
Hi,
[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.7-rc3 next-20160609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal
Hi,
[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.7-rc3 next-20160609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-
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
---
drivers/usb/g
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
---
drivers/usb/g
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
---
drivers/usb/g
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
---
drivers/usb/g
Hi,
Peter Chen writes:
>> >> > In below change of usb_gadget_vbus_draw(), already can get charger
>> >> > type via usb_charger_get_type().
>> >> >
>> >> > static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget,
>> >> > unsigned mA) {
>> >> > + enum usb_charger_type type;
>> >> >
On Wed, Apr 06, 2016 at 04:58:03PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Jun Li writes:
> >> >> >> > Since we already have get_charger_type callback at usb_charger
> >> >> >> > structure, why we still need this API at usb_gadget_ops?
> >> >> >>
> >> >> >> In case some users want to get charger
Hi,
Jun Li writes:
>> >> >> > Since we already have get_charger_type callback at usb_charger
>> >> >> > structure, why we still need this API at usb_gadget_ops?
>> >> >>
>> >> >> In case some users want to get charger type at gadget level.
>> >> >>
>> >> > Why gadget needs to know charger type?
ern ; r.bald...@samsung.com; Yoshihiro
> Shimoda ; Lee Jones
> ; Mark Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML ker...@vger.kernel.org>
> Subject: RE: [PATCH v9 2/4] gadget:
Hi,
Jun Li writes:
>> >> On 6 April 2016 at 15:19, Peter Chen wrote:
>> >> > On Fri, Apr 01, 2016 at 03:21:50PM +0800, Baolin Wang wrote:
>> >> >>
>> >> >> @@ -563,6 +564,8 @@ struct usb_gadget_ops {
>> >> >> struct usb_ep *(*match_ep)(struct usb_gadget *,
>> >> >> s
ern ; r.bald...@samsung.com; Yoshihiro
> Shimoda ; Lee Jones
> ; Mark Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML ker...@vger.kernel.org>
> Subject: RE: [PATCH v9 2/4] gadget:
USB ;
>> device-mainlin...@lists.linuxfoundation.org; LKML > ker...@vger.kernel.org>
>> Subject: Re: [PATCH v9 2/4] gadget: Support for the usb charger framework
>>
>> On 6 April 2016 at 15:19, Peter Chen wrote:
>> > On Fri, Apr 01, 2016 at 03:21:50PM +080
v
> ; David Woodhouse ; Peter Chen
> ; Alan Stern ;
> r.bald...@samsung.com; Yoshihiro Shimoda
> ; Lee Jones ; Mark
> Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML ker...@vger.ker
On 6 April 2016 at 15:19, Peter Chen wrote:
> On Fri, Apr 01, 2016 at 03:21:50PM +0800, Baolin Wang wrote:
>>
>> @@ -563,6 +564,8 @@ struct usb_gadget_ops {
>> struct usb_ep *(*match_ep)(struct usb_gadget *,
>> struct usb_endpoint_descriptor *,
>>
On Fri, Apr 01, 2016 at 03:21:50PM +0800, Baolin Wang wrote:
> 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 c
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.
Introduce a callback 'get_charger_type' which
Hi Baolin,
[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160324]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-
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.
Introduce a callback 'get_charger_type' which
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.
Introduce a callback 'get_charger_type' which
Hi Baolin,
[auto build test WARNING on v4.5-rc7]
[also build test WARNING on next-20160316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-w
Hi Baolin,
[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-
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.
Introduce a callback 'get_charger_type' which
Hi Baolin,
[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.4-rc4 next-20151208]
url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/gadget-Introduce-the-usb-charger-framework/20151208-163942
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git nex
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.
Introduce a callback 'get_charger_type' which
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.
Introduce a callback 'get_charger_type' which
Hi Baolin,
[auto build test WARNING on v4.3-rc7]
[also build test WARNING on next-20151106]
url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20151106-194008
reproduce: make htmldocs
All warnings (new ones p
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.
Signed-off-by: Baolin Wang
---
d
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.
Signed-off-by: Baolin Wang
---
d
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.
Signed-off-by: Baolin Wang
---
d
On 19 August 2015 at 20:56, Sergei Shtylyov
wrote:
> Hello.
>
> On 8/19/2015 12:13 PM, Baolin Wang wrote:
>
>> For supporting the usb charger, it adds the usb_charger_init() and
>> usb_charger_exit() functions for usb charger initialization and exit.
>>
>> Introduce a callback 'get_charger_type' w
Hello.
On 8/19/2015 12:13 PM, Baolin Wang wrote:
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.
Signed-off-by: Baolin Wang
---
d
On 19 August 2015 at 00:04, Greg KH wrote:
> On Tue, Aug 18, 2015 at 07:14:19PM +0800, Baolin Wang wrote:
>> The usb charger framework is based on usb gadget, and each usb gadget
>> can be one usb charger to set the current limitation.
>>
>> This patch adds a notifier mechanism for usb charger to
On Tue, Aug 18, 2015 at 07:14:19PM +0800, Baolin Wang wrote:
> The usb charger framework is based on usb gadget, and each usb gadget
> can be one usb charger to set the current limitation.
>
> This patch adds a notifier mechanism for usb charger to report to usb
> charger when the usb gadget state
The usb charger framework is based on usb gadget, and each usb gadget
can be one usb charger to set the current limitation.
This patch adds a notifier mechanism for usb charger to report to usb
charger when the usb gadget state is changed.
Also we introduce a callback 'get_charger_type' which wil
On 17 August 2015 at 08:40, Peter Chen wrote:
> On Fri, Aug 14, 2015 at 05:47:44PM +0800, Baolin Wang wrote:
>> The usb charger framework is based on usb gadget, and each usb gadget
>> can be one usb charger to set the current limitation.
>>
>> This patch adds a notifier mechanism for usb charger
On Fri, Aug 14, 2015 at 05:47:44PM +0800, Baolin Wang wrote:
> The usb charger framework is based on usb gadget, and each usb gadget
> can be one usb charger to set the current limitation.
>
> This patch adds a notifier mechanism for usb charger to report to usb
> charger when the usb gadget state
The usb charger framework is based on usb gadget, and each usb gadget
can be one usb charger to set the current limitation.
This patch adds a notifier mechanism for usb charger to report to usb
charger when the usb gadget state is changed.
Also we introduce a callback 'get_charger_type' which wil
On 8 August 2015 at 01:53, Greg KH wrote:
> On Fri, Aug 07, 2015 at 05:22:47PM +0800, Baolin Wang wrote:
>> On 7 August 2015 at 17:07, Peter Chen wrote:
>> >
>> >> >> /**
>> >> >> * struct usb_udc - describes one usb device controller @@ -127,12
>> >> >> +128,45 @@ void usb_gadget_giveback_req
On Fri, Aug 07, 2015 at 05:22:47PM +0800, Baolin Wang wrote:
> On 7 August 2015 at 17:07, Peter Chen wrote:
> >
> >> >> /**
> >> >> * struct usb_udc - describes one usb device controller @@ -127,12
> >> >> +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep, }
> >> >> EXPORT_SYMBOL_G
On 7 August 2015 at 17:07, Peter Chen wrote:
>
>> >> /**
>> >> * struct usb_udc - describes one usb device controller @@ -127,12
>> >> +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep, }
>> >> EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
>> >>
>> >> +int usb_gadget_register_not
> >> /**
> >> * struct usb_udc - describes one usb device controller @@ -127,12
> >> +128,45 @@ void usb_gadget_giveback_request(struct usb_ep *ep, }
> >> EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
> >>
> >> +int usb_gadget_register_notify(struct usb_gadget *gadget,
> >> +
On 7 August 2015 at 13:45, Peter Chen wrote:
> On Thu, Aug 06, 2015 at 03:03:49PM +0800, Baolin Wang wrote:
>> The usb charger framework is based on usb gadget, and each usb gadget
>> can be one usb charger to set the current limitation.
>>
>> This patch adds a notifier mechanism for usb charger t
On Thu, Aug 06, 2015 at 03:03:49PM +0800, Baolin Wang wrote:
> The usb charger framework is based on usb gadget, and each usb gadget
> can be one usb charger to set the current limitation.
>
> This patch adds a notifier mechanism for usb charger to report to usb
> charger when the usb gadget state
The usb charger framework is based on usb gadget, and each usb gadget
can be one usb charger to set the current limitation.
This patch adds a notifier mechanism for usb charger to report to usb
charger when the usb gadget state is changed.
Also we introduce a callback 'get_charger_type' which wil
This patch series enable the usb gadget support on at91sam9n12ek
board. On at91sam9n12 SoC which integrate the full speed udc device.
Bo Shen (3):
USB: gadget: at91_udc: add at91sam9n12 support
ARM: at91: dt: at91sam9n12: add udp device node
ARM: at91: dt: at91sam9n12ek: enable udp
arch
The upstream sources for platform/intel-mid aren't in any public git
repos and are distributed
as a tarball. I have been unable to find any platform/intel-mid
specific mailing lists, so
I created my own repos and tickets to track my progress. I haven't
done much work in the
kernel, but I'm trying
Hi Chris
On 2015-01-08 at 17:38:07 +0100, Chris McClimans wrote:
> I found your email in the commits for gadget_hid.txt and thought one of you
> might might be able to point me in the right direction. I'm trying to get
> the g_hid module working with the Intel Edison.
Please don't send such e-ma
W dniu 08.01.2015 o 18:09, Felipe Balbi pisze:
Hi,
On Thu, Jan 08, 2015 at 09:05:24AM -0800, Chris McClimans wrote:
I'm trying to get the g_hid module working with the Intel Edison.
I tried just compiling intel's patch(1) to 3.10.17 with
CONFIG_USB_GADGETFS=m CONFIG_USB_G_HID=m but I get an er
Hi,
On Thu, Jan 08, 2015 at 09:05:24AM -0800, Chris McClimans wrote:
> I'm trying to get the g_hid module working with the Intel Edison.
>
> I tried just compiling intel's patch(1) to 3.10.17 with
> CONFIG_USB_GADGETFS=m CONFIG_USB_G_HID=m but I get an error trying to
> load the module:
>
> modp
I'm trying to get the g_hid module working with the Intel Edison.
I tried just compiling intel's patch(1) to 3.10.17 with
CONFIG_USB_GADGETFS=m CONFIG_USB_G_HID=m but I get an error trying to
load the module:
modprobe: ERROR: could not insert 'g_hid': No such device
According to https://www.kern
On Wed, Jun 18, 2014 at 1:52 PM, Fabio Estevam wrote:
> MPC does not use it only because no one has converted it yet :-)
Okay. That makes sense :-)
> Take a look at the existing bindings of i.MX. You probably only needs
> to add the drivers/usb/chipidea/ci_hdrc_imx.c equivalent for MPC.
That d
On Wed, Jun 18, 2014 at 5:31 PM, Barry G wrote:
> On Wed, Jun 18, 2014 at 1:00 PM, Fabio Estevam wrote:
>> Can't you use the chipidea driver instead of
>> drivers/usb/gadget/fsl_udc_core.c?
>
> I was under the impression that the chipidea stuff was for iMX series
> processors.
MPC does not use
On Wed, Jun 18, 2014 at 1:00 PM, Fabio Estevam wrote:
> Can't you use the chipidea driver instead of
> drivers/usb/gadget/fsl_udc_core.c?
I was under the impression that the chipidea stuff was for iMX series
processors.
The comments in fsl_udc_core.c say it is for the MPC8349E and friends and
it
On Wed, Jun 18, 2014 at 4:47 PM, Barry G wrote:
> Seems to me the right solution is making a patch to add the 83XX stuff
> to the id_table
> and finding the right place to set_dma_ops? I am fine doing the leg work of
> creating/testing/submitting the patch providing that sounds right and people
_ops hence the 0x10 offset).
Looks like nothing on the Freescale 83XX is calling set_dma_ops.
The following complete hacks give me USB gadget support:
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 150866b..50db4f7 100644
--- a/arch/powerpc/inclu
On Tue, Jun 17, 2014 at 8:47 PM, Felipe Balbi wrote:
> Hi,
> 3.10 is a pretty old kernel, you need to ask support from whoever gave
> you that kernel, unless you can try v3.16-rc1 on your board.
>
Thanks for responding.
We are just running Vanilla 3.10 from kernel.org without any "vendor" per se
Hi,
On Tue, Jun 17, 2014 at 04:04:04PM -0700, Barry G wrote:
> Hi all,
>
> We have a custom board that has been running on the v3.0 kernel
> for a while. Since that kernel version is deprecated we are working
> on upgrading to the 3.10 kernel (some products are 3.10-ltsi so trying
3.10 is a pre
Hi all,
We have a custom board that has been running on the v3.0 kernel
for a while. Since that kernel version is deprecated we are working
on upgrading to the 3.10 kernel (some products are 3.10-ltsi so trying
to be common).
Everything is now working except the USB gadget support. This is a
1 - 100 of 114 matches
Mail list logo
