On Mon, 2013-10-14 at 17:52 -0500, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 14, 2013 at 06:24:28PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > This patch fix compilation error and is an intermediate step
> > before the addition of DeviceTree support for newer targets.
> >
On 10/14/2013 6:49 PM, Roger Quadros wrote:
Hi George,
On 10/14/2013 03:51 PM, George Cherian wrote:
This adds omap control module support for USBSS in AM437x SoC.
Update DT binding information to reflect these changes.
Signed-off-by: George Cherian
---
Documentation/devicetree/bindings/usb
On Mon, 2013-10-14 at 17:59 -0500, Felipe Balbi wrote:
> On Mon, Oct 14, 2013 at 06:24:39PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > IRQ with number 0 is valid case, so check for negative
>
> not entirelly correct... IRQ 0 isn't supposed to be used as a linux IRQ
> number
On Thu, Sep 26, 2013 at 7:35 PM, Vishal Annapurve wrote:
> Hi,
>
> There was a recent commit in mainline for the scsi devices which do not
> respond properly to medium access command:
>
> commit18a4d0a22ed6c54b67af7718c305cd010f09ddf8
>
> [SCSI] Handle disk devices which can not process medium
On Mon, Oct 14, 2013 at 03:43:35PM -0500, Bin Liu wrote:
> On Mon, Oct 14, 2013 at 10:22 AM, Markus Pargmann wrote:
> > Hi,
> >
> > On Mon, Oct 14, 2013 at 08:54:09AM -0500, Bin Liu wrote:
> >> On Mon, Oct 14, 2013 at 8:35 AM, Markus Pargmann
> >> wrote:
> >> > The USB Controller does not suppor
W dniu 14.10.2013 22:39, Michal Nazarewicz pisze:
I generally agree, but please see inline. I will post the corrected
patch as a reply to this thread.
On Wed, Oct 09 2013, Andrzej Pietrasiewicz wrote:
From this commit on f_mass_storage is available through configfs.
Signed-off-by: Andrzej
On 10/15/2013 08:31 AM, Kishon Vijay Abraham I wrote:
> Hi Roger,
>
> On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
>> +Vivek
>>
>> On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
>>> Hi Roger,
>>>
>>> On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On
>From this commit on f_mass_storage is available through configfs.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
Acked-by: Michal Nazarewicz
---
.../ABI/testing/configfs-usb-gadget-mass-storage | 31 ++
drivers/usb/gadget/Kconfig | 11 +
driver
Hello,
I made a change to the rts5139 driver that got included in kernel 3.11
(see second patch at end of this email), but Lutz Vieweg reported that
the patch causes issues for him, because the driver falsely detects
that the SD card is no longer present after transfer of a few 100 MBs.
I do not
Hi Andrew,
We can do the interface testing but I want to know how to get the latest
source. We need about 5 days to do the testing for all models and give you a
testing report.
Thanks.
Danny.
-Original Message-
From: Andrew Lunn [mailto:and...@lunn.ch]
Sent: Thursday, October 10, 2
On Tue, Oct 15, 2013 at 08:30:51AM +, Danny Lin (林政易) wrote:
> Hi Andrew,
>
> We can do the interface testing but I want to know how to get the
> latest source. We need about 5 days to do the testing for all models
> and give you a testing report.
Hi Danny
Thanks for the offer of testing. Ho
Hi everyone,
Sorry for the late test but I had other tasks...
I just had some time to look at it and test it.
Le 30/09/2013 09:47, Mylene Josserand a écrit :
> Le 29/09/2013 19:08, Christoph Fritz a écrit :
>> On Sun, 2013-09-29 at 12:19 -0300, Fabio Estevam wrote:
>>> On Sun, Sep 29, 2013 at
Hi Andrew,
Since all the models are putting on the configuration file, I hope it should be
a full function before put in mainline even if it needs more time to verify. I
think it is the right thing for us.
Danny.
-Original Message-
From: Andrew Lunn [mailto:and...@lunn.ch]
Sent: Tue
We are seeing complete lockups of the transmit side when using
the smsc95xx driver connected to a USB3 port on an i7 (Ivybridge) cpu.
These errors are very intermittent - less than once a day, and
it isn't actually clear that they are related to traffic load.
Most of the systems are running the 3.
hi alan:
>> > > BTW, I have another question about iso_stream_schedule.
>> > > When if (likely (!list_empty (&stream->td_list))) happen,
>> > > why don't we just take last scheduled microframe, stream->next_uframe
>> > > as start point directly?
>> >
>> > We do exactly that if URB_ISO_ASAP isn't
This adds omap control module support for USBSS in AM437x SoC.
Update DT binding information to reflect these changes.
Signed-off-by: George Cherian
---
Changes from v1:
Make ON and OFF operations symmetric.
Documentation/devicetree/bindings/usb/omap-usb.txt | 2 ++
drivers/usb/phy/phy
This makes checking for duplicates easier while adding new #include.
Signed-off-by: George Cherian
---
drivers/phy/phy-omap-usb2.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index bfc5c33..3e5f0
This patch adds a compatible for AM437x "ti,am43xx-usb2" to
reuse the same phy-omap-usb2 driver.
Also updated the documentation to add the new compatible.
Signed-off-by: George Cherian
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 4 +-
drivers/phy/phy-omap-usb2.c
This series adapts the phy-omap-usb2 generic phy driver for AM437x.
While at that sort the include files alphabetically (PATCH 1)
Patch1 - v2->v3 Amend the commit log
V2 of 2nd Patch which fixes the following from v1
- List comaptible entries in Documentaion
- Add usb_phy_data inst
Le 15/10/2013 11:48, Mylene Josserand a écrit :
> Unfortunately, I don't know if I missed any configurations but the SMSC
> 3340 is still not working in my case.. :(
>
> I test it with a 2.6.32 kernel. The phy seems to be detected (same thing
> before the "patches") but when I plug an USB-key, no
On Tue, Oct 15, 2013 at 10:18:15AM +0800, Peter Chen wrote:
> So, the lessons for this topic are:
>
> - If one atomic variable's operation only includes one instruction like
> atomic_read and atomic_set, it is not meaningful for using atomic
> operation, we can just use bool instead of it.
The le
Hi,
On Tue, Oct 15, 2013 at 12:23:45PM +0530, George Cherian wrote:
> This patch adds a compatible for AM437x "ti,am43xx-usb2" to
> reuse the same phy-omap-usb2 driver.
it does more than just adding a new compatible flag.
> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
>
On Tue, Oct 15, 2013 at 04:07:43PM +0530, George Cherian wrote:
> This patch adds a compatible for AM437x "ti,am43xx-usb2" to
> reuse the same phy-omap-usb2 driver.
>
> Also updated the documentation to add the new compatible.
>
> Signed-off-by: George Cherian
I commented on oldler series, sorr
On Tue, Oct 15, 2013 at 11:01:16AM +0530, Kishon Vijay Abraham I wrote:
> Hi Roger,
>
> On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
> > +Vivek
> >
> > On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
> >> Hi Roger,
> >>
> >> On Friday 11 October 2013 08:39 PM, Roger Quadros wrot
Hi,
On Mon, Oct 14, 2013 at 01:21:29PM +0300, Roger Quadros wrote:
> +Vivek
>
> On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
> > Hi Roger,
> >
> > On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
> >>> Adap
On Tue, Oct 15, 2013 at 10:57:16AM +0300, Roger Quadros wrote:
> On 10/15/2013 08:31 AM, Kishon Vijay Abraham I wrote:
> > Hi Roger,
> >
> > On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
> >> +Vivek
> >>
> >> On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
> >>> Hi Roger,
> >>>
>
On 10/15/2013 02:57 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 14, 2013 at 01:21:29PM +0300, Roger Quadros wrote:
>> +Vivek
>>
>> On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
>>> Hi Roger,
>>>
>>> On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013
Overrides are optional and many drivers pass NULL, in this case don't
process the overrides so we don't deference a NULL pointer.
Signed-off-by: Charles Keepax
---
drivers/usb/host/ohci-hcd.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b
Interface 6 of this device speaks QMI as per tests done by us.
Credits go to Antonella for providing the hardware.
Signed-off-by: Enrico Mioso
Signed-off-by: Antonella Pellizzari
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 80a7104..d7c10d6 100644
--- a/drivers/u
This is a QMI device, manufactured by TCT Mobile Phones.
A companion patch blacklisting this device's QMI interface in the option.c
driver has been sent.
Signed-off-by: Enrico Mioso
Signed-off-by: Antonella Pellizzari
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3d
From: Manjunath Goudar
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. Alan Stern
suggested, properly handle OHCI suspend scenario.
This does generic proper handling of suspend
scenario to all OHCI SOC.
V1->V2:
- No change.
Due to build failure o
From: Manjunath Goudar
Suspend scenario in case of ohci-at91 glue was not properly handled
as it was not suspending generic part of ohci controller. Alan Stern
suggested, properly handle ohci-at91 suspend scenario.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will
From: Manjunath Goudar
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-da8xx suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensu
From: Manjunath Goudar
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-s3c2410 suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspe
From: Majunath Goudar
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-ep93xx suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_hcd_ep93xx_drv_suspend()
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
> > @@ -665,6 +669,9 @@ struct dwc3 {
> > struct usb_phy *usb2_phy;
> > struct usb_phy *usb3_phy;
> >
> > + struct phy *usb2_generic_phy;
> > + st
From: Manjunath Goudar
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-spear suspend scenario.
Calling explicitly the ohci_suspend() routine in
spear_ohci_hcd_drv_suspend()
From: Manjunath Goudar
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-exynos suspend scenario.
Calling explicitly the ohci_suspend() routine in
exynos_ohci_suspend() will e
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
>>> @@ -665,6 +669,9 @@ struct dwc3 {
>>> struct usb_phy *usb2_phy;
>>> struct usb_phy *usb3_phy;
>>>
>>> + struct phy
Hi,
On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
> On 10/15/2013 04:19 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
> >>> @@ -665,6 +669,9 @@ struct dwc3 {
> >>> struct usb_phy *usb2_phy;
> >>>
On 10/15/2013 04:56 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
>> On 10/15/2013 04:19 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
> @@ -665,6 +669,9 @@ struct dwc3 {
>
On Tue, Oct 15, 2013 at 05:03:50PM +0300, Roger Quadros wrote:
> On 10/15/2013 04:56 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
> >> On 10/15/2013 04:19 PM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Tue, Oct 15, 2013 at 03:10:42PM +030
I'm pulling together code at the moment which I'll post for comment
later in the week.
What I want to do is combine the operations of 2 drivers to create a
virtual monitor via UVC, uvcfbsource
It involves configuring the UVC video-streaming capability of the USB
Webcam Gadget to use a frameb
On Tue, 2013-10-15 at 15:06 +0200, Enrico Mioso wrote:
> Interface 6 of this device speaks QMI as per tests done by us.
> Credits go to Antonella for providing the hardware.
>
> Signed-off-by: Enrico Mioso
> Signed-off-by: Antonella Pellizzari
Tested-by: Dan Williams
> diff --git a/drivers/us
On Tue, 2013-10-15 at 15:06 +0200, Enrico Mioso wrote:
> This is a QMI device, manufactured by TCT Mobile Phones.
> A companion patch blacklisting this device's QMI interface in the option.c
> driver has been sent.
>
> Signed-off-by: Enrico Mioso
> Signed-off-by: Antonella Pellizzari
Good find.
On Mon, 14 Oct 2013, Hartley Sweeten wrote:
> >> config USB_OHCI_HCD_PLATFORM
> >>tristate "Generic OHCI driver for a platform device"
> >> - default n
> >> + default y if ARCH_EP93XX
> >
> > Shouldn't we select USB_OHCI_HCD_PLATFORM, e.g. something like:
> >
> > config ARCH_EP93XX_USB
On Mon, 14 Oct 2013, H Hartley Sweeten wrote:
> Convert ep93xx to use the OHCI platform driver and remove the
> ohci-ep93xx bus glue driver.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Cc: Ryan Mallon
...
> @@ -297,22 +298,58 @@ static struct platform_de
This patch supports the separate handling of the USB transfer buffer length
and the length of the buffer used for multi packet support. The USB transfer
size can now be explicitly configured via the device_info record. Otherwise
it defaults to the configured report packet size as before. For device
On Mon, 14 Oct 2013, Gerd Hoffmann wrote:
> Gerd, Hans, any objections to this updated patch? The warning is fixed
> with it.
>
> The patch probably still needs to address the case where the ring
> expansion fails because we can't insert the new segments into the radix
> tree. The patch should
On Mon, Oct 14, 2013 at 05:24:10PM -0700, Sarah Sharp wrote:
> The following changes since commit f4c19b8e165cff1a6607c21f8809441d61cab7ec:
>
> USB: serial: option: add support for Inovia SEW858 device (2013-10-11
> 16:17:51 -0700)
>
> are available in the git repository at:
>
> git://git.k
On Tue, Oct 15, 2013 at 10:34:53AM +0530, manju goudar wrote:
> Alan,
>
> I am very sorry for this mistake.
> I will fix this issue and sending back series.
>
> Greg,
> I am really sorry :((
> Next time I will not make this kind of mistake.
> If any issue reported related to my patches I will
>
On Tue, Oct 15, 2013 at 06:49:56PM +0530, Majunath Goudar wrote:
> From: Manjunath Goudar
>
> Suspend scenario in case of OHCI was not properly
> handled in ochi_suspend()routine. Alan Stern
> suggested, properly handle OHCI suspend scenario.
>
> This does generic proper handling of suspend
> sc
On Tue, 15 Oct 2013, Majunath Goudar wrote:
> From: Majunath Goudar
>
> Suspend scenario in case of ohci-ep93xx glue was not
> properly handled as it was not suspending generic part
> of ohci controller. Alan Stern suggested, properly handle
> ohci-ep93xx suspend scenario.
>
> Calling explicitl
Hi,
On Mon, Oct 14, 2013 at 2:35 PM, H Hartley Sweeten
wrote:
> Convert ep93xx to use the OHCI platform driver and remove the
> ohci-ep93xx bus glue driver.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Cc: Ryan Mallon
> ---
> arch/arm/mach-ep93xx/clock.c
On Tue, 15 Oct 2013, Ming Lei wrote:
> On Thu, Sep 26, 2013 at 7:35 PM, Vishal Annapurve
> wrote:
> > Hi,
> >
> > There was a recent commit in mainline for the scsi devices which do not
> > respond properly to medium access command:
> >
> > commit18a4d0a22ed6c54b67af7718c305cd010f09ddf8
> >
On Tue, 15 Oct 2013, Marcus Overhagen wrote:
> Hello,
>
> I made a change to the rts5139 driver that got included in kernel 3.11
> (see second patch at end of this email), but Lutz Vieweg reported that
> the patch causes issues for him, because the driver falsely detects
> that the SD card is no
:) I'm very happy you got it working.
The firmware of our device seems so fragile still - and several QMI calls can
bring it to a crashing state, especially when asking a network scan to the NAS
service.
On Tue, 15 Oct 2013, Dan Williams wrote:
==Date: Tue, 15 Oct 2013 09:49:57 -0500
==From: D
Hi Felipe,
this small series includes the remaining fixes to the OTG mode tested on
am335x-evm.
What works with these:
- modprobe musb_dsps; plug device; no crash (#1)
- plug a host or device into the OTG port and they will be recognized and
served. Also after unplug :) (mainline #4)
What still
Hi Alan,
This issue seems more related to the devices using SCSI protocol and the
changes otherwise will be at more places giving the same end result.
I think as the comment says over the command_abort function,
intentional result change should only happen in case of timeout.
Regards,
Vishal
--
In commit 001dd84 ("usb: musb: start musb on the udc side, too") it was
ensured that the state engine is started also in OTG mode after a
removal / insertion of the gadget.
Unfortunately this change also introduced a bug: If the device is
configured as OTG and it connected with a remote host _witho
This patch moves dsps_musb_try_idle() before dsps_musb_enable() so the
declaration (of dsps_musb_try_idle() can be removed.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_dsps.c | 75 ++--
1 file changed, 37 insertions(+), 38 deletions(
According to the comments, we rely on the OTG timer because the core
does not expose some important OTG details. So far this is all I
know. After playing with OTG I stumbled over a problem:
musb is recognized as a B-device without a problem. Whenever a cable is
plugged, the VBUS rises, musb recogni
The timer is initialized right after musb is probed. There is actually
no need to have this timer running because _nothing_ will happen until
we have the gadget loaded. Also we need this timer only if we run in OTG
mode _and_ we need it also after the gadget has been replaced with
another one.
I'v
I introduced this check here because it looked wrong in HOST only
configurions. The timer would remove that session bit and will never
come back and so there would not be another session.
Now that I played with OTG for a while I belive this workaround is
only required for the OTG mode because we ha
On Tue, 15 Oct 2013, Vishal Annapurve wrote:
> Hi Alan,
>
> This issue seems more related to the devices using SCSI protocol and the
> changes otherwise will be at more places giving the same end result.
>
> I think as the comment says over the command_abort function,
> intentional result change
Apologies looks like I was on an earlier RC there and the users
that did this have been removed. I assume this patch can be
ignored sorry for the noise.
Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
Mor
On Tue, 15 Oct 2013, vichy wrote:
> > This is the second part (printing a debug message if all the assigned
> > microframes have already expired):
> Does this "expired" come from (controller frame pointer) >
> (stream->next_uframe)?
It comes from frame_pointer > next_uframe + period * (number_of_
Hi,
On Tue, Oct 15, 2013 at 06:29:22PM +0200, Sebastian Andrzej Siewior wrote:
> In commit 001dd84 ("usb: musb: start musb on the udc side, too") it was
> ensured that the state engine is started also in OTG mode after a
> removal / insertion of the gadget.
> Unfortunately this change also introdu
On 10/15/2013 07:43 PM, Felipe Balbi wrote:
> Hi,
Hi,
>> index d1d6b83..9af6bba 100644 ---
>> a/drivers/usb/musb/musb_virthub.c +++
>> b/drivers/usb/musb/musb_virthub.c @@ -220,6 +220,23 @@ int
>> musb_hub_status_data(struct usb_hcd *hcd, char *buf) return
>> retval; }
>>
>> +static int musb_has
Hi Alan,
USB storage maybe just has to say that the abort occurred. By setting the
US_FLIDX_TIMED_OUT bit USB storage is getting signaled that the reason was
time out and the command is being aborted.
Now, it's arguable whether to change the implication of US_FLIDX_TIMED_OUT
bit for scsi - USB s
On 10/15/2013 06:07 PM, Alan Stern wrote:
The USB endpoint specifies a transfer interval of 10. The rts5139
Does the device connect at high speed (480 Mb/s)?
I can say that the rts5139 card reader in my laptop
does use the 480 MBit/s rate.
(I don't know whether there are derivatives of that
On Tue, Oct 15, 2013 at 08:09:01AM -0700, Greg Kroah-Hartman wrote:
> All of these are for issues that do not look like "regressions" to me,
> but rather, "long-standing" bugs. While I'm all about fixing bugs and
> problems, none of these seem like urgent fixes for things that have been
> recently
On 10/15/13 07:02, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131015 tag is also provided for convenienc
Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation
of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt
and Documentation/devicetree/bindings/phy/ti-phy.txt.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |5 -
1
No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-omap-usb2.c |2 +-
include/linux/{usb => phy}
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
Reviewed-by: Sylwester Nawrocki
---
This patch was deferred from Generic PHY framework series since dwc3 uses the
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to
There can be systems which does not have a external usb_phy, so get
usb_phy only if dt data indicates the presence of PHY in the case of dt boot or
if platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy layer.
Adapted omap-usb3 PHY driver to Generic PHY Framework and moved phy-omap-usb3
driver in drivers/usb/phy to drivers/phy and also renamed the file to
phy-ti-pipe3 since this same driver will be used for SATA PHY and
PCIE PHY.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/Kconfig
Felipe,
Looks like most of the patches are dependent on Generic PHY Framework except
the first one. Let me know if I have to take these patches with your ACK or
you'll take it yourself.
**
Modified dwc3 core to find PHYs only if the p
Since now we have a separate folder for phy, move the PHY dt binding
documentation of TI to that folder.
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/{usb/usb-phy.txt => phy/ti-phy.txt} |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
rename Documentation
On Tue, Oct 15, 2013 at 12:44:08PM -0700, Sarah Sharp wrote:
> > So I'd like to take these for 3.13-rc1, and if they are fixes, take them
> > into the 3.12-stable tree (and older ones) when they hit Linus's tree
> > then.
>
> Ok, fine with me. Just to be clear though: are you asking me to delay
>
On Tue, 15 Oct 2013, Charles Keepax wrote:
> Apologies looks like I was on an earlier RC there and the users
> that did this have been removed. I assume this patch can be
> ignored sorry for the noise.
Actually it's the other way around. The change you submitted has
already been merged:
https:
On Tue, 15 Oct 2013, Vishal Annapurve wrote:
> Hi Alan,
>
> USB storage maybe just has to say that the abort occurred. By setting the
> US_FLIDX_TIMED_OUT bit USB storage is getting signaled that the reason was
> time out and the command is being aborted.
No. By setting the US_FLIDX_TIMED_OUT b
On Tue, Oct 15, 2013 at 6:07 PM, Alan Stern wrote:
> Why does the driver make this mistake?
My initial assumption was wrong, the driver doesn't infrequently poll, but
does so more often. I was misled by the confusing source.
However, I now made usbmon traces and analyzed them with LibreOffice.
This removes the old EHCI transaction translator scheduling code,
leaving only the "new" (now over 7 years old) scheduling code.
---
I think it's been long enough to prove the "new" tt sched
code works, and we can drop the old stuff. Alan, Greg,
and reason to keep the old tt sched code?
This pa
On Tuesday, October 15, 2013 8:50 AM, Olof Johansson wrote:
> On Mon, Oct 14, 2013 at 2:35 PM, H Hartley Sweeten
> wrote:
>> Convert ep93xx to use the OHCI platform driver and remove the
>> ohci-ep93xx bus glue driver.
>>
>> Signed-off-by: H Hartley Sweeten
>> Cc: Alan Stern
>> Cc: Greg Kroah-H
This patch adds the Port Reset Change flag to the set of bits that are
preemptively cleared on init/resume of a hub. In theory this bit should
never be set unexpectedly... in practice it can still happen if BIOS,
SMM or ACPI code plays around with USB devices without cleaning up
correctly. This is
Hello.
On 10/16/2013 01:23 AM, Julius Werner wrote:
This patch adds the Port Reset Change flag to the set of bits that are
preemptively cleared on init/resume of a hub. In theory this bit should
never be set unexpectedly... in practice it can still happen if BIOS,
SMM or ACPI code plays around
Hello,
I get a compile error with the kernel 3.12-rc4 :
Kernel: arch/x86/boot/bzImage is ready (#8)
ERROR: "devm_regmap_init_i2c" [drivers/usb/misc/usb3503.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
If I set :
# CONFIG_USB_HSIC_USB3503 is not set
the kernel co
On 10/15/13 14:48, jpliste wrote:
> Hello,
>
> I get a compile error with the kernel 3.12-rc4 :
>
> Kernel: arch/x86/boot/bzImage is ready (#8)
> ERROR: "devm_regmap_init_i2c" [drivers/usb/misc/usb3503.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> If I set
On Wed, Oct 16, 2013 at 4:22 AM, Alan Stern wrote:
> On Tue, 15 Oct 2013, Vishal Annapurve wrote:
>
>> Hi Alan,
>>
>> USB storage maybe just has to say that the abort occurred. By setting the
>> US_FLIDX_TIMED_OUT bit USB storage is getting signaled that the reason was
>> time out and the command
>> + if ((portchange & USB_PORT_STAT_C_RESET)) {
>
>
>Hm, why these double parens?
Oh... good question. I copied the entry below it, remove the && and
must have overlooked those. Sorry, v2 incoming...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the
This patch adds the Port Reset Change flag to the set of bits that are
preemptively cleared on init/resume of a hub. In theory this bit should
never be set unexpectedly... in practice it can still happen if BIOS,
SMM or ACPI code plays around with USB devices without cleaning up
correctly. This is
Convert ep93xx to use the OHCI platform driver and remove the
ohci-ep93xx bus glue driver.
Enable CONFIG_OHCI_HCD_PLATFORM and refresh the ep93xx_defconfig
so that USB is still enabled by default on the EP93xx platform.
Signed-off-by: H Hartley Sweeten
Cc: Alan Stern
Cc: Greg Kroah-Hartman
Cc:
On 16/10/13 11:47, H Hartley Sweeten wrote:
> Convert ep93xx to use the OHCI platform driver and remove the
> ohci-ep93xx bus glue driver.
>
> Enable CONFIG_OHCI_HCD_PLATFORM and refresh the ep93xx_defconfig
> so that USB is still enabled by default on the EP93xx platform.
>
> Signed-off-by: H Ha
On Tuesday, October 15, 2013 5:57 PM, Ryan Mallon wrote:
> On 16/10/13 11:47, H Hartley Sweeten wrote:
>> Convert ep93xx to use the OHCI platform driver and remove the
>> ohci-ep93xx bus glue driver.
>>
>> Enable CONFIG_OHCI_HCD_PLATFORM and refresh the ep93xx_defconfig
>> so that USB is still ena
Hi Sarah,
On Fri, Oct 11, 2013 at 05:43:49AM +0800, Sarah Sharp wrote:
> Hi Sipter and Marcus,
>
> Xenia has a potential fix for a long-standing bug in the xHCI driver,
> and I need your help testing it. You ran into that bug back in Feb
> 2013:
>
> http://sourceforge.net/mailarchive/forum.php?
The USB3503 driver had an incorrect depedency on REGMAP, instead of
REGMAP_I2C. This caused the build to fail since the necessary regmap
i2c pieces were not available.
Signed-off-by: Matthew Dawson
---
drivers/usb/misc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Hi Christian,
On Tue, Oct 15, 2013 at 04:50:00PM +0200, Christian Engelmayer wrote:
> This patch supports the separate handling of the USB transfer buffer length
> and the length of the buffer used for multi packet support. The USB transfer
> size can now be explicitly configured via the device_in
1 - 100 of 101 matches
Mail list logo