Hi Sarah,
On 10/15/2013 03:54 AM, Gerd Hoffmann wrote:
Gerd, Hans, any objections to this updated patch? The warning is fixed
with it.
No objections, looks good to me.
The patch probably still needs to address the case where the ring
expansion fails because we can't insert the new
strtobool is more flexible for the user and is more appropriate in the
context.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/storage_common.c | 16
A short series to fix 2 issues:
- use strtobool instead of kstrtouint with base 2 for: ro, nofua, cdrom,
removable attrs
(better fits the context and more flexible to users)
- setting a lun to be cdrom implies read-only and succeeds only if the lun is
not open
v1..v2:
- fixes after Michal's
If cdrom flag is set ro flag is implied. Try setting the ro first, and
only if it succeeds set the cdrom flag.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
W dniu 15.10.2013 00:48, Felipe Balbi pisze:
Hi,
On Mon, Oct 14, 2013 at 11:21:45AM +0200, Andrzej Pietrasiewicz wrote:
A short series to fix 2 issues:
- use strtobool instead of kstrtouint with base 2 for: ro, nofua, cdrom,
removable attrs
(better fits the context and more flexible to
This series adapts the phy-omap-usb2 generic phy driver for AM437x.
While at that arrange the include files alphabetically (PATCH 1)
V2 of 2nd Patch which fixes the following from v1
- List comaptible entries in Documentaion
- Add usb_phy_data instead of checking compatible each
Hi Roger,
On 14/10/2013 11:20, Roger Quadros wrote:
Hi Benoit,
On 10/10/2013 06:34 PM, Felipe Balbi wrote:
On Mon, Oct 07, 2013 at 04:28:13PM +0300, Roger Quadros wrote:
The generic PHY framewrok expects different properties than the
old USB PHY framework. Supply those properties.
Fixes USB
This patch arranges the includes in alphabetical order
Signed-off-by: George Cherian george.cher...@ti.com
---
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
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 george.cher...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 4 +-
drivers/phy/phy-omap-usb2.c
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 iiva...@mm-sol.com
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 george.cher...@ti.com
---
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 iiva...@mm-sol.com
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
On Thu, Sep 26, 2013 at 7:35 PM, Vishal Annapurve vannapu...@nvidia.com 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
On Mon, Oct 14, 2013 at 03:43:35PM -0500, Bin Liu wrote:
On Mon, Oct 14, 2013 at 10:22 AM, Markus Pargmann m...@pengutronix.de 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 m...@pengutronix.de
wrote:
The USB
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 andrze...@samsung.com wrote:
From this commit on f_mass_storage is available through configfs.
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 09/02/2013 06:43 PM, Kishon
From this commit on f_mass_storage is available through configfs.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
.../ABI/testing/configfs-usb-gadget-mass-storage | 31 ++
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,
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.
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 11:32
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:
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
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 set. But first the
This adds omap control module support for USBSS in AM437x SoC.
Update DT binding information to reflect these changes.
Signed-off-by: George Cherian george.cher...@ti.com
---
Changes from v1:
Make ON and OFF operations symmetric.
Documentation/devicetree/bindings/usb/omap-usb.txt | 2
This makes checking for duplicates easier while adding new #include.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/phy/phy-omap-usb2.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c
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 george.cher...@ti.com
---
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
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 lesson
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 george.cher...@ti.com
I commented on
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 wrote:
Hi,
On
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:
Adapted dwc3 core to use
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 Friday 11 October
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 06:43 PM, Kishon Vijay
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 ckee...@opensource.wolfsonmicro.com
---
drivers/usb/host/ohci-hcd.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff
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 mrkiko...@gmail.com
Signed-off-by: Antonella Pellizzari anto.pellizzar...@gmail.com
diff --git a/drivers/usb/serial/option.c
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 mrkiko...@gmail.com
Signed-off-by: Antonella Pellizzari anto.pellizzar...@gmail.com
diff --git
From: Manjunath Goudar manjunath.gou...@linaro.org
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.
From: Manjunath Goudar manjunath.gou...@linaro.org
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
From: Manjunath Goudar manjunath.gou...@linaro.org
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
From: Manjunath Goudar manjunath.gou...@linaro.org
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
From: Majunath Goudar manju.gou...@lge.com
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
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;
+ struct phy
From: Manjunath Goudar manjunath.gou...@linaro.org
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
From: Manjunath Goudar manjunath.gou...@linaro.org
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
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 *usb2_generic_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;
struct usb_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 {
struct usb_phy
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 +0300, Roger Quadros
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
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 mrkiko...@gmail.com
Signed-off-by: Antonella Pellizzari anto.pellizzar...@gmail.com
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 mrkiko...@gmail.com
Signed-off-by: Antonella
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 hswee...@visionengravers.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
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
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:
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
fix it
On Tue, Oct 15, 2013 at 06:49:56PM +0530, Majunath Goudar wrote:
From: Manjunath Goudar manjunath.gou...@linaro.org
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
On Tue, 15 Oct 2013, Majunath Goudar wrote:
From: Majunath Goudar manju.gou...@lge.com
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.
Hi,
On Mon, Oct 14, 2013 at 2:35 PM, H Hartley Sweeten
hartl...@visionengravers.com wrote:
Convert ep93xx to use the OHCI platform driver and remove the
ohci-ep93xx bus glue driver.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc:
On Tue, 15 Oct 2013, Ming Lei wrote:
On Thu, Sep 26, 2013 at 7:35 PM, Vishal Annapurve vannapu...@nvidia.com
wrote:
Hi,
There was a recent commit in mainline for the scsi devices which do not
respond properly to medium access command:
commit
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:
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
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
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 bige...@linutronix.de
---
drivers/usb/musb/musb_dsps.c | 75 ++--
1 file changed, 37
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
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 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
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
More
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_packets
-
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 introduced a
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_gadget(struct
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
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 convenience.
Gained a new conflict, but nothing too
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 kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |
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 kis...@ti.com
---
drivers/phy/phy-omap-usb2.c |2 +-
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 kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
This patch was deferred from
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
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 kis...@ti.com
---
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
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 kis...@ti.com
---
.../devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt} |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
rename
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
these
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:
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 bit,
On Tue, Oct 15, 2013 at 6:07 PM, Alan Stern st...@rowland.harvard.edu 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
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 patch
On Tuesday, October 15, 2013 8:50 AM, Olof Johansson wrote:
On Mon, Oct 14, 2013 at 2:35 PM, H Hartley Sweeten
hartl...@visionengravers.com wrote:
Convert ep93xx to use the OHCI platform driver and remove the
ohci-ep93xx bus glue driver.
Signed-off-by: H Hartley Sweeten
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
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 :
#
1 - 100 of 108 matches
Mail list logo
