On 02/19/2013 08:40 PM, Yinghai Lu wrote:
On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke wrote:
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost, caus
On Tue, Feb 19, 2013 at 01:21:46PM +0100, Magda Matouskova wrote:
> Hi,
>
> i have a problem with driver for my usb modems. Time after time server stuck(
> log from this event is below), in this case server has to be rebooted. I think
> that this could be caused by any condition that cannot be occ
On Tue, Feb 19, 2013 at 11:53:47PM -0300, Dâniel Fraga wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=54111
>
> Posting this regression here as suggested by Greg Kroah-Hartman.
>
> After upgrading from kernel 3.7.0 to 3.8.0, the
> USB devices (keyboard, mouse etc) will not work
https://bugzilla.kernel.org/show_bug.cgi?id=54111
Posting this regression here as suggested by Greg Kroah-Hartman.
After upgrading from kernel 3.7.0 to 3.8.0, the
USB devices (keyboard, mouse etc) will not work at all. My motherboard
is an Asus P8Z68-V PRO/GEN3 and I am NOT using
Add the DWC2 Kconfig and Makefile, and modify the USB Kconfig and
Makefile to include them
Signed-off-by: Paul Zimmerman
---
drivers/usb/Kconfig | 2 ++
drivers/usb/Makefile | 2 ++
drivers/usb/dwc2/Kconfig | 27 +++
drivers/usb/dwc2/Makefile | 15 ++
This file contains the PCI bus interface "glue" for the DWC2
driver
Signed-off-by: Paul Zimmerman
---
drivers/usb/dwc2/pci.c | 355 +
1 file changed, 355 insertions(+)
create mode 100644 drivers/usb/dwc2/pci.c
diff --git a/drivers/usb/dwc2/pci.c
This file contains the code to support the HCD descriptor DMA mode
of the controller
Signed-off-by: Paul Zimmerman
---
drivers/usb/dwc2/hcd_ddma.c | 1193 +++
1 file changed, 1193 insertions(+)
create mode 100644 drivers/usb/dwc2/hcd_ddma.c
diff --git a/
Hi Felipe,
Here is v4 of the DWC2 patch set. I made most of the changes you asked
for, except for the following:
- I did not convert to a threaded IRQ handler. I would like to postpone
that for now.
- I did not use an asychronous function call during driver initialization
in dwc2_hcd_start(),
On Tue, Feb 19, 2013 at 12:47:32PM -0700, Bjorn Helgaas wrote:
> On Mon, Feb 18, 2013 at 3:09 AM, Hannes Reinecke wrote:
> > The PCI config space reseves a byte for the interrupt line,
> > so irq 255 actually refers to 'not set'.
> > However, the 'irq' field for struct pci_dev is an integer,
> > s
On Tue, Feb 19, 2013 at 01:48:51PM -0800, Sarah Sharp wrote:
> Hi Tony,
>
> Greg closed the usb-next tree for 3.9 two weeks ago. The bug fix
> patches will have to go in after the 3.9 merge window closes
> (approximately two weeks from now).
>
> Sorry for the lack of response, I was on vacation.
Hi Tony,
Greg closed the usb-next tree for 3.9 two weeks ago. The bug fix
patches will have to go in after the 3.9 merge window closes
(approximately two weeks from now).
Sorry for the lack of response, I was on vacation. I'll review your
patch in the next few days.
The one thing I wanted to c
On Tue, Feb 19, 2013 at 08:06:35PM +0100, Sascha Hauer wrote:
> On Tue, Feb 19, 2013 at 11:30:19AM +0200, Felipe Balbi wrote:
> > On Mon, Feb 04, 2013 at 02:24:28PM +0100, Sascha Hauer wrote:
> > > Most of otg/otg.c is not otg specific, but phy specific, so move it
> > > to the phy directory.
> > >
On Mon, Feb 18, 2013 at 3:09 AM, Hannes Reinecke wrote:
> The PCI config space reseves a byte for the interrupt line,
> so irq 255 actually refers to 'not set'.
> However, the 'irq' field for struct pci_dev is an integer,
> so the original meaning is lost, causing the system to
> assign an interru
On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke wrote:
> The PCI config space reseves a byte for the interrupt line,
> so irq 255 actually refers to 'not set'.
> However, the 'irq' field for struct pci_dev is an integer,
> so the original meaning is lost, causing the system to
> assign an interru
On Tue, 19 Feb 2013 13:27:49 -0500 (EST)
Alan Stern wrote:
> > Adding a completely new API that returns a timestamp associated with
> > the start/end/fixed offset of a frame number sounds like a perfect
> > solution for my problem. I am not sure what you mean with completion
> > (interrupt). AFAI
On Tue, Feb 19, 2013 at 11:30:19AM +0200, Felipe Balbi wrote:
> On Mon, Feb 04, 2013 at 02:24:28PM +0100, Sascha Hauer wrote:
> > Most of otg/otg.c is not otg specific, but phy specific, so move it
> > to the phy directory.
> >
> > Signed-off-by: Sascha Hauer
> > Reported-by: Kishon Vijay Abraham
On Sun, 17 Feb 2013, Ronald wrote:
> Current head gives this when I plug a 'Mass Storage Device' into a 2.0 hub:
>
> [ 842.760400] hub 1-0:1.0: unable to enumerate USB device on port 3
> [ 843.080058] usb 1-3: new high-speed USB device number 48 using ehci-pci
> [ 858.230072] usb 1-3: device d
On Tue, 19 Feb 2013, Stefan Tauner wrote:
> > Using frame boundaries for time synchronization at the user level is
> > possibly a defensible reason for exporting frame numbers. But there
> > are better ways to accomplish this goal. For example, there could be
> > an API that returns both a realt
On Mon, 18 Feb 2013 22:10:45 -0500 (EST)
Alan Stern wrote:
> On Tue, 19 Feb 2013, Stefan Tauner wrote:
>
> > Therefore I am currently playing around with a
> > usb_hcd_get_real_frame_number() which uses a ehci_get_real_frame()
> > function hacked into ehci-hcd.c which returns the actual SOF coun
On Tue, 19 Feb 2013, Felipe Balbi wrote:
> > > we will still see the warning since usbcore will continue to call
> > > ->drop_endpoint() for disabled eps.
> >
> > But if xhci-hcd is fixed properly, it won't print out those warnings
> > when drop_endpoint is called for eps that were disabled by a
On Tue, Feb 19, 2013 at 11:36:02AM -0500, Alan Stern wrote:
> On Tue, 19 Feb 2013, Felipe Balbi wrote:
>
> > On Tue, Feb 19, 2013 at 10:43:54AM -0500, Alan Stern wrote:
> > > On Tue, 19 Feb 2013, Felipe Balbi wrote:
> > >
> > > > Hi,
> > > >
> > > > On Mon, Feb 18, 2013 at 05:20:44PM -0500, Alan
On Tue, 19 Feb 2013, Felipe Balbi wrote:
> On Tue, Feb 19, 2013 at 10:43:54AM -0500, Alan Stern wrote:
> > On Tue, 19 Feb 2013, Felipe Balbi wrote:
> >
> > > Hi,
> > >
> > > On Mon, Feb 18, 2013 at 05:20:44PM -0500, Alan Stern wrote:
> > > > On Fri, 15 Feb 2013, Felipe Balbi wrote:
> > > >
> >
Hi,
On Tue, Feb 19, 2013 at 05:07:09PM +0100, Marc Kleine-Budde wrote:
> On 02/19/2013 04:05 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
> >> On Tuesday 19 February 2013, Felipe Balbi wrote:
> >>> On Tue, Feb 19, 2013 at 12:33:54PM +,
On 02/19/2013 04:05 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
>> On Tuesday 19 February 2013, Felipe Balbi wrote:
>>> On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
> Currently drivers/phy and drivers/net/phy are independen
Sarah,
This patch is pursuant to the patch at ...
http://www.mail-archive.com/linux-usb@vger.kernel.org/msg14965.html,
Message ID <1361209953-5195-1-git-send-email-tcam...@redhat.com>
... and must be applied after that patch is applied.
Can these patches be included in the next merge?
Thanks,
T
On Tue, Feb 19, 2013 at 10:43:54AM -0500, Alan Stern wrote:
> On Tue, 19 Feb 2013, Felipe Balbi wrote:
>
> > Hi,
> >
> > On Mon, Feb 18, 2013 at 05:20:44PM -0500, Alan Stern wrote:
> > > On Fri, 15 Feb 2013, Felipe Balbi wrote:
> > >
> > > > Hi all,
> > > >
> > > > I keep seeing the following m
On Tue, Feb 19, 2013 at 03:28:17PM +, Arnd Bergmann wrote:
> On Tuesday 19 February 2013, Felipe Balbi wrote:
> > On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
> > > On Tuesday 19 February 2013, Felipe Balbi wrote:
> > > > On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann
4 ports; AT/PPP is standard CDC-ACM. The other three (added by this
patch) are QCDM/DIAG, possibly GPS, and unknown.
Signed-off-by: Dan Williams
---
This time with a [PATCH] prefix.
diff --git a/drivers/usb/serial/qcaux.c b/drivers/usb/serial/qcaux.c
index 9b1b96f..31f81c3 100644
--- a/drivers/
On Tue, 19 Feb 2013, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 18, 2013 at 05:20:44PM -0500, Alan Stern wrote:
> > On Fri, 15 Feb 2013, Felipe Balbi wrote:
> >
> > > Hi all,
> > >
> > > I keep seeing the following messages when transferring data to any USB3
> > > mass storage I have (tried 3 di
On Tuesday 19 February 2013, Felipe Balbi wrote:
> On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
> > On Tuesday 19 February 2013, Felipe Balbi wrote:
> > > On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
> > It's a fine line, but I think a phy is something that resem
On Tue, 19 Feb 2013, Arnd Bergmann wrote:
> On Tuesday 19 February 2013, Manjunath Goudar wrote:
> > > This is not necessary; ehci_setup is the default value anyway. This
> > > structure can be omitted.
> > >
> >
> > ehci_init_driver function we are passing orion_overrides,if we are removing
> >
Hi,
On Tue, Feb 19, 2013 at 02:34:40PM +, Arnd Bergmann wrote:
> On Tuesday 19 February 2013, Felipe Balbi wrote:
> > On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
> > > > Currently drivers/phy and drivers/net/phy are independent and are not
> > > > related to each other. The
Hi,
I am no longer sure about my test procedure for cdc-wdm.
Do you have a test script?
I am also including what I currently have for your review.
Regards
Oliver
>From 1dbdd790304cba9dadb725d1aee71633b8340504 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Tue, 19 Fe
On Tuesday 19 February 2013, Felipe Balbi wrote:
> On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
> > > Currently drivers/phy and drivers/net/phy are independent and are not
> > > related to each other. There are some fundamental differences on how
> > > these frameworks work. IIU
On Tuesday 19 February 2013, kishon wrote:
> >> +
> >> + devname = dev_name(dev);
> >> + device_initialize(&phy->dev);
> >> + phy->desc = desc;
> >> + phy->dev.class = phy_class;
> >> + phy->dev.parent = dev;
> >> + phy->dev.bus = desc->bus;
> >> + ret = dev_set_name(&phy->dev, "%s", devname
There are no functional changes in this patch. However, because the
compliance mode timer can be deleted in more than one function, it
seemed expedient to include the function name in the debug strings.
Also limited the use of capitals to the first word in the compliance
mode debug messages, excep
Hi,
On Tuesday 19 February 2013 06:26 PM, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a 'class
Hi,
On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote:
> On Tuesday 19 February 2013, kishon wrote:
> > On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
> > > On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
> > >> Added a generic PHY framework that provides a set o
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
> +static struct class *phy_class;
> +static LIST_HEAD(phy_list);
> +static DEFINE_MUTEX(phy_list_mutex);
> +static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a 'class'. There is a GregKH mandated ban on
new classes, meaning th
On Tuesday 19 February 2013, kishon wrote:
> On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
> > On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
> >> Added a generic PHY framework that provides a set of APIs for the PHY
> >> drivers
> >> to create/destroy a PHY and APIs for t
Hi,
i have a problem with driver for my usb modems. Time after time server stuck(
log from this event is below), in this case server has to be rebooted. I think
that this could be caused by any condition that cannot be occured.
Can you take a look for it or give me some tips to solve this proble
Hi,
On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or wit
On Tuesday 19 February 2013, Manjunath Goudar wrote:
> > This is not necessary; ehci_setup is the default value anyway. This
> > structure can be omitted.
> >
>
> ehci_init_driver function we are passing orion_overrides,if we are removing
> above struct initialization, what should we need to pass
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> the PHY with or without using phandle. To obtain a reference to the PHY
> withou
On Mon, Feb 04, 2013 at 02:24:28PM +0100, Sascha Hauer wrote:
> Most of otg/otg.c is not otg specific, but phy specific, so move it
> to the phy directory.
>
> Signed-off-by: Sascha Hauer
> Reported-by: Kishon Vijay Abraham I
> Cc: Felipe Balbi
this is pretty ok, I'll start queueing patches fo
Andrew Lunn writes:
Hi,
[...]
>> > +
>> > +static const char hcd_name[] = "ehci-orion";
[...]
>> > }
>> >
>> > -MODULE_ALIAS("platform:orion-ehci");
>> > -
>> > static const struct of_device_id ehci_orion_dt_ids[] = {
>> >{ .compatible = "marvell,orion-ehci", },
orion-ehci here ...
>
Hi,
On Tue, Feb 19, 2013 at 11:23:15AM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. omap_usb2_suspend
> is split into omap_usb_suspend and omap_usb_resume in order to align
> with the new framework.
>
> However using the old USB PHY library cannot b
Hi,
On Tue, Feb 19, 2013 at 11:23:14AM +0530, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
48 matches
Mail list logo
