hi Greg:
2015-04-17 14:45 GMT+08:00 Greg KH :
> On Fri, Apr 17, 2015 at 09:22:02AM +0800, yoma sophian wrote:
>> hi all:
>> if we build usb driver as module, the dependence is like below:
>> usb-common.ko
>> usbcore.ko
>> ehci-hcd.ko
>> ...
>> etc.
>> if we choose build-in instead of modules, how
On 17/04/15 05:18, Peter Chen wrote:
> On Tue, Apr 14, 2015 at 01:41:53PM +0300, Roger Quadros wrote:
>> The existing usb_add/remove_hcd() functionality
>> remains unchanged for non-OTG devices. For OTG
>> devices they only register the HCD with the OTG core.
>>
>> Introduce _usb_add/remove_hcd() f
On Fri, Apr 17, 2015 at 03:19:26PM +0800, yoma sophian wrote:
> hi Greg:
>
> 2015-04-17 14:45 GMT+08:00 Greg KH :
> > On Fri, Apr 17, 2015 at 09:22:02AM +0800, yoma sophian wrote:
> >> hi all:
> >> if we build usb driver as module, the dependence is like below:
> >> usb-common.ko
> >> usbcore.ko
>
On 17/04/15 05:28, Peter Chen wrote:
> On Tue, Apr 14, 2015 at 01:41:55PM +0300, Roger Quadros wrote:
>> This is the a_set_b_hnp_enable flag in the OTG state machine
>> diagram and must be set when the A-Host has successfully set
>> the b_hnp_enable feature of the OTG-B-Peripheral attached to it.
>
hi Greg:
>> > The linker order determines the order of the init functions.
>> Would you mind to let us know where and how it do so?
>
> I don't understand, what is the problem with the existing code? What
> are you trying to solve here? Is the linking order somehow not working
> properly?
No.
the
On Fri, Apr 17, 2015 at 03:51:09PM +0800, yoma sophian wrote:
> hi Greg:
> >> > The linker order determines the order of the init functions.
> >> Would you mind to let us know where and how it do so?
> >
> > I don't understand, what is the problem with the existing code? What
> > are you trying to
Hi,
Sorry for the lack of review on this series; will take care of this tomorrow.
Valentina
--
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
hi Greg:
2015-04-17 16:22 GMT+08:00 Greg KH :
> On Fri, Apr 17, 2015 at 03:51:09PM +0800, yoma sophian wrote:
>> hi Greg:
>> >> > The linker order determines the order of the init functions.
>> >> Would you mind to let us know where and how it do so?
>> >
>> > I don't understand, what is the probl
On 16/04/15 14:32, Peter Chen wrote:
> On Tue, Apr 14, 2015 at 01:41:48PM +0300, Roger Quadros wrote:
>> struct otg_fsm is the interface to the OTG state machine.
>>
>> Document the input, output and internal state variables.
>> Definations are taken from Table 7-2 and Table 7-4 of
>> the USB OTG &
Hi Wei,
Thank you for the patch.
On Thursday 16 April 2015 21:07:05 weiyj...@163.com wrote:
> From: Wei Yongjun
>
> Remove including that don't need it.
>
> Signed-off-by: Wei Yongjun
Acked-by: Laurent Pinchart
Felipe, could you please pick this up ?
> ---
> drivers/usb/gadget/function/
On Fri, Apr 17, 2015 at 12:28:45PM +0300, Laurent Pinchart wrote:
> Hi Wei,
>
> Thank you for the patch.
>
> On Thursday 16 April 2015 21:07:05 weiyj...@163.com wrote:
> > From: Wei Yongjun
> >
> > Remove including that don't need it.
> >
> > Signed-off-by: Wei Yongjun
>
> Acked-by: Laurent
On Fri, 17 Apr 2015, Roger Quadros wrote:
> On 17/04/15 05:18, Peter Chen wrote:
> > On Tue, Apr 14, 2015 at 01:41:53PM +0300, Roger Quadros wrote:
> >> The existing usb_add/remove_hcd() functionality
> >> remains unchanged for non-OTG devices. For OTG
> >> devices they only register the HCD with
On 16 April 2015 at 18:57, Dorian Gray wrote:
> On 16 April 2015 at 16:24, Suman Tripathi wrote:
>> Try increasing the SWIOTLB size to 128MB .Default is 64MB.
>
> Ok, so I'm back to k3.18.7 (default in the latest Fatdog), although
> I'm not sure what should be the exact value of swiotlb boot para
On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk wrote:
> And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
> and then load the attached module.
>
> That should tell you who and what else is holding on the buffers.
Ok, I have compiled 3.19.4 w/ CONFIG_DMA_API_DEBUG=y + the module
From: Felipe Balbi
When going into bus suspend/resume we _must_
call gadget driver's ->suspend/->resume callbacks
accordingly. This patch implements that very feature
which has been missing forever.
Cc: # 3.14
Signed-off-by: Felipe Balbi
Signed-off-by: David Cohen
---
Hi,
This patch was int
On Fri, Apr 17, 2015 at 11:41:56AM -0700, David Cohen wrote:
> From: Felipe Balbi
>
> When going into bus suspend/resume we _must_
> call gadget driver's ->suspend/->resume callbacks
> accordingly. This patch implements that very feature
> which has been missing forever.
>
> Cc: # 3.14
> Signed
On Fri, Apr 17, 2015 at 11:41:56AM -0700, David Cohen wrote:
> From: Felipe Balbi
missing the required:
[ Upstream commit bc5ba2e0b829c9397f96df1191c7d2319ebc36d9 ]
>
> When going into bus suspend/resume we _must_
> call gadget driver's ->suspend/->resume callbacks
> accordingly. This patch im
On Fri, Apr 17, 2015 at 02:43:27PM -0500, Felipe Balbi wrote:
> On Fri, Apr 17, 2015 at 11:41:56AM -0700, David Cohen wrote:
> > From: Felipe Balbi
>
> missing the required:
>
> [ Upstream commit bc5ba2e0b829c9397f96df1191c7d2319ebc36d9 ]
>
> >
> > When going into bus suspend/resume we _must_
On Fri, Apr 17, 2015 at 05:14:20PM +0200, Dorian Gray wrote:
> On 16 April 2015 at 20:42, Konrad Rzeszutek Wilk
> wrote:
> > And easier way is to compile the kernel with CONFIG_DMA_API_DEBUG
> > and then load the attached module.
> >
> > That should tell you who and what else is holding on the bu
19 matches
Mail list logo
