A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Wed, Jan 23, 2013 at 02:49:35PM -0500, Robert Dvoracek wrote:
> It's Knoppix 7.0.5, kernel 3.6.11
So, if you do:
modprobe xhci-
On Wed, Jan 23, 2013 at 03:09:19PM -0500, Alan Stern wrote:
> On Thu, 24 Jan 2013, Lan Tianyu wrote:
>
> > > > + status = usb_disable_function_remotewakeup(udev);
> > >
> > > Don't call that function here. Just put the code here and run it
> > > directly. Then you can get rid
Hi Thomas,
Le Wed, 23 Jan 2013 19:03:52 +0100,
Thomas Petazzoni a écrit :
> On Wed, 23 Jan 2013 14:04:42 -0300, Ezequiel Garcia wrote:
>
> > from the OpenBlocks AX3-4 board dts file, since you mentioned this
> > board uses that USB
> > port for a PCIe connector -- if I understood correctly.
>
>
On Mon, Jan 21, 2013 at 03:24:03PM -0800, David Moore wrote:
> On Mon, Jan 21, 2013 at 11:35 AM, Sarah Sharp wrote:
> > It's possible that the device is just buggy, and it expects the Windows
> > enumeration scheme. Windows will send an 8-byte request for the device
> > descriptor, set the device
Quoting Roger Quadros (2013-01-23 02:38:12)
> Fixes the below build warning when driver is built-in.
>
> drivers/mfd/omap-usb-host.c:750:12: warning:
> ‘usbhs_omap_remove’ defined but not used [-Wunused-function]
>
> Signed-off-by: Roger Quadros
> Reviewed-by: Felipe Balbi
Hi Roger,
I just no
-- Forwarded message --
From: Robert Dvoracek
Date: Wed, Jan 23, 2013 at 6:45 PM
Subject: Re: USB3 Not Being Detected on Intel DX79TO Desktop Board
To: Greg KH
On Wed, Jan 23, 2013 at 3:18 PM, Greg KH wrote:
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
Hi,
I am planning to build a USB device based on an embedded controller board
having a (High-Speed) USB peripheral port and an (Gbit) Ethernet port.
My goal is to "connect" arbitrary USB devices (e.g. physical mass storage /
serial devices or gadgets like g_mass_storage, g_serial) attached to a
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.8-rc4
for you to fetch changes up to dba63b2f733ebfd89bbb15
On Thu, Jan 24, 2013 at 12:59:00AM +0100, Carsten Neumann wrote:
> Hi,
>
> I am planning to build a USB device based on an embedded controller
> board having a (High-Speed) USB peripheral port and an (Gbit) Ethernet
> port. My goal is to "connect" arbitrary USB devices (e.g. physical
> mass stora
On Wed, Jan 23, 2013 at 06:46:34PM -0500, Robert Dvoracek wrote:
> On Wed, Jan 23, 2013 at 3:18 PM, Greg KH wrote:
> > On Wed, Jan 23, 2013 at 02:49:35PM -0500, Robert Dvoracek wrote:
> >> It's Knoppix 7.0.5, kernel 3.6.11
> >
> > So, if you do:
> > modprobe xhci-hcd
> > from the command l
On Wed, Jan 23, 2013 at 7:07 PM, Greg KH wrote:
> On Wed, Jan 23, 2013 at 06:46:34PM -0500, Robert Dvoracek wrote:
>> On Wed, Jan 23, 2013 at 3:18 PM, Greg KH wrote:
>> > On Wed, Jan 23, 2013 at 02:49:35PM -0500, Robert Dvoracek wrote:
>> >> It's Knoppix 7.0.5, kernel 3.6.11
>> >
>> > So, if you
于 2013年01月24日 00:34, Alan Stern 写道:
> Here you could just get rid of the second *** on each line. Or put the
> "7 ports max" into parentheses and get rid of all the ***'s.
>
> Alan Stern
thank you, I will send [PATCH 2/2 v2].
--
Chen Gang
Asianux Corporation
--
To unsubscribe from this lis
On Wed, Jan 23, 2013 at 7:47 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jan 22, 2013 at 10:51:32AM +0800, Chao Xie wrote:
>> On Mon, Jan 21, 2013 at 11:51 PM, Russell King - ARM Linux
>> wrote:
>> > On Mon, Jan 21, 2013 at 05:07:36AM -0500, Chao Xie wrote:
>> >> + mv_phy->extern_chip.head = de
get rid of the line breaks in string constants.
let comments within 80 with limitation.
delete ' \' at the end of a statement.
Signed-off-by: Chen Gang
---
drivers/usb/host/uhci-debug.c | 28
drivers/usb/host/uhci-hcd.c | 27 +--
Usb3.0 device defines function remote wakeup which is only for interface
recipient rather than device recipient. This is different with usb2.0 device's
remote wakeup feature which is defined for device recipient. According usb3.0
spec 9.4.5, the function remote wakeup can be modified by the SetFeat
usb2.0 and usb3.0 devices have different ways to enalbe/disable
remote wakeup. This patch is to put both their operations into
the seperate functions. Otherwise, usb_control_msg() has some
long arguments and are usually nested some indentations. So
encapsulating it into seperate functions would be
On Thursday 24 January 2013, 01:06 Greg KH wrote:
> On Thu, Jan 24, 2013 at 12:59:00AM +0100, Carsten Neumann wrote:
> > Hi,
> >
> > I am planning to build a USB device based on an embedded controller
> > board having a (High-Speed) USB peripheral port and an (Gbit) Ethernet
> > port. My goal i
Hi,
My intent is really special, I don't know whether I missed something, but all
the articles about writing a USB driver do not address my need.
I want to use the USB port on the host as a signal generator to drive a USB
cable (the two data lines) connected to another device's USB connector. T
>
> > I have post one patch which may remove the message, see link[2].
>
> I don't think sleeping is the right answer. For example, at the same
> time as the resume there could be a new device plugged in.
>
> What we really want to do is prevent the root hub from autosuspending
> while the re
On Thu, Jan 24, 2013 at 10:44 AM, Du, Yuyang wrote:
> My intent is really special, I don't know whether I missed
> something, but all the articles about writing a USB driver
> do not address my need.
>
> I want to use the USB port on the host as a signal generator to drive a
> USB cable (the two d
Sorry, forget to cc the list
>
> Hi Greg,
>
> Alex has no response for chipidea driver review for long time
> (more than 1 month), below are some links about patchset.
> Does anyone else can help do it?
>
> http://marc.info/?t=13540330436&r=1&w=2
> http://marc.info/?l=linux-usb&m=13587375
On Thursday 24 January 2013, 03:44 "Du, Yuyang" wrote:
> Hi,
>
> My intent is really special, I don't know whether I missed something, but all
> the articles about writing a USB driver do not address my need.
>
> I want to use the USB port on the host as a signal generator to drive a USB
> ca
Thanks.
Millisecond is good for me. Every signal (1 and 0) sent is triggered by a user
program. The period the signal lasts is not so important either.
Yuyang
-Original Message-
From: Xiaofan Chen [mailto:xiaof...@gmail.com]
Sent: Thursday, January 24, 2013 10:54 AM
To: Du, Yuyang
Cc:
On Thu, Jan 24, 2013 at 11:44 AM, Du, Yuyang wrote:
> Thanks.
>
> Millisecond is good for me. Every signal (1 and 0) sent is triggered
> by a user program. The period the signal lasts is not so important either.
I have doubts whether you can achieve millisecond accuracy
with the stock Linux kerne
On Thu, Jan 24, 2013 at 2:10 AM, Alan Stern wrote:
>
> Not so. It's true that the message can be produced even when the delay
> is present, but if the delay is set to 30 ms then you will get no more
> than one message every 30 ms. By contrast, Norbert was getting about 8
> messages per ms.
IMO,
On Thu, Jan 24, 2013 at 10:45 AM, Chen Peter-B29397
wrote:
>
> I also agree with no auto suspend occur during the resume signal is active.
Yes, I agree too.
>
> But one think I still can't understand that you add
> usb_autopm_get_interface_no_resume(
> to_usb_interface(hub->intfd
Hi everyone,
thanks for all the emails, but I am a bit at loss what to try next.
THere where patches, suggestions for usbsnoop etc flying around.
Can someone please let me know what information you would like
to see?
Norbert
--
On Thu, Jan 24, 2013 at 02:44:44AM +, Du, Yuyang wrote:
> Hi,
>
> My intent is really special, I don't know whether I missed something,
> but all the articles about writing a USB driver do not address my
> need.
>
> I want to use the USB port on the host as a signal generator to drive
> a USB
From: David Moore
When the xHCI driver is not available, actively switch the ports to EHCI
mode since some BIOSes leave them in xHCI mode where they would
otherwise appear dead.
Signed-off-by: David Moore
---
drivers/usb/host/pci-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/dri
On Thu, Jan 24, 2013 at 01:44:09PM +0800, Ming Lei wrote:
> On Thu, Jan 24, 2013 at 10:45 AM, Chen Peter-B29397
> wrote:
> >
> > I also agree with no auto suspend occur during the resume signal is active.
>
> Yes, I agree too.
>
> >
> > But one think I still can't understand that you add
> > usb
Hi,
>> >> Here are the last two setup data and CBW data received. the
>> >> get_next_command() is not called when CBW data is received. the
>> >> bulk_out_complete() wakes up the thread, however, get_next_command()
>> >> still sleeps. i do not see where req->length is checked in gadget
>> >> drive
The patches are divied into 4 parts
1. bug fixes
usb: gadget: mv_udc: use udc_start and udc_stop functions
usb: gadget: mv_udc: use devm_xxx for probe
usb: gadget: mv_udc: fix the warning of mv_udc_remove
usb: otg: mv_otg: use devm_xxx for probe
usb: host: ehci-mv: remove unused variable
This patches converts the driver into the new style start/stop
interface. As a result the driver no longer uses the static
global the_conroller variable.
Signed-off-by: Chao Xie
---
drivers/usb/gadget/mv_udc_core.c | 79 +-
1 files changed, 35 insertions(+),
Signed-off-by: Chao Xie
Acked-by: Alan Stern
---
drivers/usb/host/ehci-mv.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 6c56297..3065809 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-
use devm_xxx for udc driver probe. So we do need care about
the resources release in driver remove or failure handling
in driver probe.
Signed-off-by: Chao Xie
---
drivers/usb/gadget/mv_udc_core.c | 156 ++
1 files changed, 56 insertions(+), 100 deletions(-)
use devm_xxx for otg driver probe. So we do need care about
the resources release in driver remove or failure handling
in driver probe.
Signed-off-by: Chao Xie
---
drivers/usb/otg/mv_otg.c | 82 -
1 files changed, 22 insertions(+), 60 deletions(-)
d
usally we will use udc->tranceiver == NULL or
udc->tranceiver != NULL.
So when failed to get the udc->tranceiver by usb_get_phy(), we
directly set udc->tranceiver to be NULL.
Then the source code will not need macro IS_ERR_OR_NULL() for
udc->tranceiver judgement. It can reduce the line size and mak
Only ARCH_PXA and ARCH_MMP will use mv_udc.
Signed-off-by: Chao Xie
---
drivers/usb/gadget/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 14625fd..53943f7 100644
--- a/drivers/usb/gadget/Kconfig
+++ b
The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to initialized before use the controller.
Direclty writing the phy dr
The __exit_p() will be NULL if MODULE is no defined.
It will cause the warning. Removing __exit_p to remove
the warning.
Signed-off-by: Chao Xie
---
drivers/usb/gadget/mv_udc_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drive
Originaly, udc driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of ena
Originaly, otg driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of ena
Originaly, ehci driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of en
add the udc/otg/ehci devices for mmp2
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/include/mach/mmp2.h |4
arch/arm/mach-mmp/mmp2.c |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h
b/arch/arm/mach-mmp/includ
because phy is seperated from the usb controller driver,
we can use the common pxa_device_desc for device register.
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/include/mach/pxa910.h |7 ---
arch/arm/mach-mmp/pxa910.c |4
2 files changed, 8 insertions(+), 3 deletio
for brownstone board, add the udc/otg/ehci support
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/brownstone.c | 47
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index 5cb
for ttc_dkb board, add udc/otg/ehci support
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/ttc_dkb.c | 30 +++---
1 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index ce55fd8..0962791 100644
---
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/pxa168.c | 42 --
1 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
index b7f074f..dd3a68b 100644
--- a/arch/arm/mach-mmp/pxa168.c
+++ b/ar
phy setting are formatted into a phy driver at drivers/usb/phy,
we do not need do the setting in SOC files.
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/devices.c | 278 -
arch/arm/mach-mmp/include/mach/regs-usb.h | 253 --
2 f
For the vbus and idpin detection. It may be completed by some
external chip, for example the pmic chip 88pm860x in driver/mfd
can do it.
Although the usb controller can detect the vbus and id pin, but
it need clock on and PHY enabled to detect the
vbus/idpin. It will increase the power.
Using the e
Because arch-mmp will make use of irq domain for irq
allocation, the irqs allocated for PMIC is dynamical.
The vbus/idpin irqs from PMIC can not be passed by platform data.
Using the extern chip APIs provides by PHY driver can solve this
problem.
Marvell usb PHY driver provides a middle layer.
The
It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie
---
drivers/usb/otg/mv_otg.c | 63 -
drivers/usb/otg/mv_otg.h |3 ++
2 files changed, 31 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/otg/mv_otg.c b/driv
It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie
Acked-by: Alan Stern
---
drivers/usb/host/ehci-mv.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index be504fd..171e145
Change the board support for usb as extern chip is supported
in marvell usb PHY driver
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/brownstone.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index 90c034
Change the board support for usb as extern chip is supported
in marvell usb PHY driver.
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/ttc_dkb.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 0962791..eb346
In original driver, we have callbacks in platform data, and some
dynamically allocations variables in platform data.
Now, these blocks are removed, the device tree support is easier
now.
Signed-off-by: Chao Xie
---
drivers/usb/gadget/mv_udc.h |5 +-
drivers/usb/gadget/mv_udc_core.c | 1
All blocks are removed. Add the device tree support for otg.
Signed-off-by: Chao Xie
---
drivers/usb/otg/mv_otg.c | 128 +
drivers/usb/otg/mv_otg.h |6 +-
2 files changed, 108 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/otg/mv_otg.c b
All blocks are removed. Add the device tree support for ehci.
Signed-off-by: Chao Xie
Acked-by: Alan Stern
---
drivers/usb/host/ehci-mv.c | 105 +--
1 files changed, 80 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb
On Thu, Jan 24, 2013 at 02:37:32PM +0800, victor yeo wrote:
> Hi,
>
> >> >> Here are the last two setup data and CBW data received. the
> >> >> get_next_command() is not called when CBW data is received. the
> >> >> bulk_out_complete() wakes up the thread, however, get_next_command()
> >> >> still
101 - 159 of 159 matches
Mail list logo
