Am 03.10.2013 um 22:00 schrieb David Miller:
> From: "Dr. H. Nikolaus Schaller"
> Date: Thu, 3 Oct 2013 21:40:34 +0200
>
>> I have made the bug observation from debug log that this bit is set in a
>> response
>> each time the modem has a RING message. It might be specific to this modem
>> and
Selecting CONFIG_USB_EHCI_TEGRA requires CONFIG_USB_ULPI_VIEWPORT.
Otherwise the build can break with:
drivers/usb/phy/phy-tegra-usb.c: In function 'ulpi_open':
drivers/usb/phy/phy-tegra-usb.c:689:31: error: 'ulpi_viewport_access_ops'
undeclared (first use in this function)
drivers/usb/phy/phy-
From: Manjunath Goudar
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly
handle ohci-pxa27x suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_hcd_pxa27x_drv_suspend
From: Manjunath Goudar
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly
handle ohci-sm501 suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_sm501_suspend() will ens
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
From: Manjunath 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(
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: Manjunath Goudar
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller.Alan Stern suggested, properly handle
ohci-platform suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_platform_suspend() w
From: Manjunath Goudar
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-omap suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_omap_suspend() will ensure
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.
Signed-off-by: Manjunath Goudar
Signed-off-by: Manjunat
On 08/12/2013 06:32 PM, Bjorn Helgaas wrote:
> On Mon, Aug 12, 2013 at 3:32 PM, Yinghai Lu wrote:
>> On Mon, Aug 12, 2013 at 2:14 PM, Bjorn Helgaas wrote:
>>> On Thu, Aug 8, 2013 at 7:57 AM, Rafael J. Wysocki wrote:
On Thursday, August 08, 2013 03:35:13 PM Heikki Krogerus wrote:
> If
On Thu, Oct 03, 2013 at 09:04:04AM -0700, David Cohen wrote:
> Hi Greg,
>
> On 10/02/2013 10:21 PM, Greg KH wrote:
> >On Tue, Oct 01, 2013 at 02:32:58PM -0700, David Cohen wrote:
> >>Signed-off-by: David Cohen
> >>---
> >> drivers/usb/chipidea/ci_hdrc_pci.c | 5 +
> >> 1 file changed, 5 inse
On Tue, Oct 01, 2013 at 02:32:57PM -0500, Thomas Pugliese wrote:
> Hi,
> This patch adds support for dev speed USB_SPEED_WIRELESS in
> snd_usb_parse_datainterval which allows the usb sound core to create
> ISO urbs with the correct number and size of buffers.
>
> Signed-off-by: Thomas Pugliese
On Tue, Oct 01, 2013 at 02:32:15PM -0500, Thomas Pugliese wrote:
> This patch updates snd_usb_audio_create also support devices whose
> speed == USB_SPEED_WIRELESS.
>
> Signed-off-by: Thomas Pugliese
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe linu
Hi All,
As a result of all my streams work, I've started to wonder if it would not
be better to leave bulk endpoints with streams disabled until streams are
allocated. It seems to me that allowing to submit non stream bulk transfers
on stream eps is not useful, and could even be harmful if it cau
This fixes TR dequeue validation failing on Intel XHCI controllers with the
following warning:
Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
Interestingly enough reading the deq ptr from the ep ctx after a
TR Deq Ptr command does work on a Nec XHCI controller, it seems
Signed-off-by: Hans de Goede
---
drivers/usb/host/xhci-ring.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 411da1f..1ad397f 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhc
Nec XHCI controllers don't seem to care, but without this Intel XHCI
controllers reject Set TR dequeue commands with a COMP_TRB_ERR, leading
to the following warning:
WARN Set TR Deq Ptr cmd invalid because of stream ID configuration
And very shortly after this the system completely freezes.
Sig
Hi All,
After spending 1.5 weeks debugging issues with xhci streams which would
hard-freeze my machine every 5 minutes, I'm very happy to present this
patch set, with which usb 3 streams are fully stable for me, including
using them from userspace through qemu usb redirection (I'll post
kernel pat
And warn about this, as that would be a driver bug.
Like wise drivers should ensure that streams are properly free-ed before a
device is reset. So lets warn about that too. This already causes warnings
in the form of:
[ 96.982398] xhci_hcd :01:00.0: WARN Can't disable streams for endpoint
From: Gerd Hoffmann
xhci maintains a radix tree for each stream endpoint because it must
be able to map a trb address to the stream ring. Each ring segment
must be added to the ring for this to work. Currently xhci sticks
only the first segment of each stream ring into the radix tree.
Result i
Before this a device needing ie 32 stream ctxs would end up with an entry from
the small_streams_pool which has 256 bytes entries, where as 32 stream ctxs
need 512 bytes. Things actually keep running for a surprisingly long time
before crashing because of this.
Signed-off-by: Hans de Goede
---
d
> Although the drive is USB-3 and is capable of communicating at
> SuperSpeed (5 Gb/s), it is running at only high speed (480 Mb/s).
> This suggests there may be something wrong with the cable. Are you
> using a high-quality USB-3 cable?
>
I'm using the one who comes with the drive, i've never ch
Do you have a firm or company that need loan to start up a business or
need,personal loan, Debt consolidation? For more information,Contact us now for
a guarantee loan with low interest rate. We will provide you with loan to meet
your needs. For more information contact us with the following inf
From: "Dr. H. Nikolaus Schaller"
Date: Thu, 3 Oct 2013 21:40:34 +0200
> I have made the bug observation from debug log that this bit is set in a
> response
> each time the modem has a RING message. It might be specific to this modem
> and firmware version, i.e. a firmware bug. But we have no mea
Hi,
Am 03.10.2013 um 21:29 schrieb David Miller:
> From: "Dr. H. Nikolaus Schaller"
> Date: Wed, 2 Oct 2013 09:00:18 +0200
>
>> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
>> From: "H. Nikolaus Schaller"
>> Date: Thu, 15 Nov 2012 14:40:57 +0100
>> Subject: [PATCH 1/1
From: "Dr. H. Nikolaus Schaller"
Date: Wed, 2 Oct 2013 09:00:18 +0200
> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
> From: "H. Nikolaus Schaller"
> Date: Thu, 15 Nov 2012 14:40:57 +0100
> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION
> G
> On Thu, Oct 03, 2013 at 06:00:50PM -, hema...@codeaurora.org wrote:
>> We have devices which require to send zero length packet in data stage
>> to
>> host in certain cases. We were not seeing any issue when we were using
>> ehci based controller. When we switched to XHCI here is what we are
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Thursday, October 03, 2013 12:35 AM
>
> > By the way, it looks like 'num_dev_ep' would have the same problem,
>
> I don't think so, since the hardware doesn't do the off-by-one trick
> there (presumably because having 0 endpoints make s
On Thu, Oct 03, 2013 at 06:00:50PM -, hema...@codeaurora.org wrote:
> We have devices which require to send zero length packet in data stage to
> host in certain cases. We were not seeing any issue when we were using
> ehci based controller. When we switched to XHCI here is what we are
> observ
We have devices which require to send zero length packet in data stage to
host in certain cases. We were not seeing any issue when we were using
ehci based controller. When we switched to XHCI here is what we are
observing:-
For IN DATA dir control xfer XHCI sets ISP so xhci updates actual_length
On Wed, 2 Oct 2013, [ISO-8859-1] Jorge Mu�oz Camadro wrote:
> Usbmon shows this when plugin the usb external drive:
It's all normal up to here...
> 880213239a80 1383565784 S Ci:1:006:0 s a1 fe 0001 1 <
> 880213239a80 1383566386 C Ci:1:006:0 0 1 = 01
> 880213239a80 138356651
Hi Greg,
On 10/02/2013 10:21 PM, Greg KH wrote:
On Tue, Oct 01, 2013 at 02:32:58PM -0700, David Cohen wrote:
Signed-off-by: David Cohen
---
drivers/usb/chipidea/ci_hdrc_pci.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/chipidea/ci_hdrc_pci.c
b/drivers/usb/chipidea/
This patch looks good. I've applied it and will send it to Greg
shortly.
Sarah Sharp
On Mon, Sep 16, 2013 at 12:01:34PM +0530, Sachin Kamat wrote:
> 'xhci_del_comp_mod_timer' is local to this file.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/usb/host/xhci-hub.c |3 ++-
> 1 file change
On Thu, Oct 03, 2013 at 05:54:14PM +0300, Roger Quadros wrote:
> On 10/03/2013 03:29 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Oct 02, 2013 at 04:41:53PM +0300, Roger Quadros wrote:
> >> On 10/02/2013 04:11 PM, Felipe Balbi wrote:
> >>> On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros
Hi Oliver,
This patch looks fine, aside from the introduction of trailing
whitespace on the blank line change, which I've fixed.
I'll queue it to Greg shortly.
Thanks,
Sarah Sharp
On Mon, Sep 30, 2013 at 03:50:54PM +0200, oli...@neukum.org wrote:
> From: Oliver Neukum
>
> It has been reported
Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types"
introduced a new AMD chipset type to filter AMD platforms with different
chipsets.
According to a recent thread [1], this patch updates SB800 prefetch routine
in AMD PLL quirk. And make it use the new chipset type to repres
Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types"
introduced a new AMD chipset type to filter AMD platforms with different
chipsets.
According to a recent thread [1], this patch updates USB subsystem hang
symptom quirk which is observed on AMD all SB600 and SB700 revision
On Thu, Oct 03, 2013 at 10:31:53AM -0400, Alan Stern wrote:
> On Thu, 3 Oct 2013, manju goudar wrote:
>
> > On Wed, Oct 2, 2013 at 9:22 PM, Alan Stern wrote:
> >
> > > On Wed, 2 Oct 2013, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > On Wednesday, October 02, 2013 10:
omap-control device is present from OMAP4 onwards which
support device tree boots only. So get rid of platform data.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-control.c | 12 +++-
include/linux/usb/omap_control_usb.h |4
2 files changed, 3 insertions(+), 13 d
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is
Hi Greg,
I was initially pushing this series through Felipe, but now that PHY framework
is in your usb-next tree, Felipe has asked me to send it to you.
We need this for 3.13.
There are more patches related to USB support for TI's DRA7 SoC and SATA support
for OMAP5 that depend on this series.
T
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
Also get rid of "ti,has-mailbox" property as it is redundant and
we can dete
Split otghs_ctrl and USB2 PHY power-down into separate
omap-control-usb nodes. Get rid of "ti,type" property.
Also get rid of "ti,has-mailbox" property from usb_otg_hs
node and provide the ctrl-module phandle.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi |
Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Get rid of "ti,type" property.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.
This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-control.c | 31 ++-
include/linu
Add support for new device types and in the process rid of "ti,type"
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types OTGHS, USB2, PIPE3 (e.g. USB3) and DRA7U
On 10/02/2013 09:39 PM, Marcel Holtmann wrote:
Hi Gustavo,
Many btusb devices have 2 modes, a hid mode and a bluetooth hci mode. These
devices default to hid mode for BIOS use. This means that after having been
reset they will revert to HID mode, and are no longer usable as a HCI.
Therefor it
On 10/03/2013 03:29 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 02, 2013 at 04:41:53PM +0300, Roger Quadros wrote:
>> On 10/02/2013 04:11 PM, Felipe Balbi wrote:
>>> On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote:
Hi Felipe,
On 09/18/2013 03:49 PM, Roger Quadros wro
On Thursday, October 03, 2013 10:31:53 AM Alan Stern wrote:
> On Thu, 3 Oct 2013, manju goudar wrote:
>
> > On Wed, Oct 2, 2013 at 9:22 PM, Alan Stern wrote:
> >
> > > On Wed, 2 Oct 2013, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > On Wednesday, October 02, 2013 10:
On Thu, 3 Oct 2013, manju goudar wrote:
> On Wed, Oct 2, 2013 at 9:22 PM, Alan Stern wrote:
>
> > On Wed, 2 Oct 2013, Bartlomiej Zolnierkiewicz wrote:
> >
> > >
> > > Hi,
> > >
> > > On Wednesday, October 02, 2013 10:38:58 AM Alan Stern wrote:
> > > > On Wed, 2 Oct 2013, Bartlomiej Zolnierkiewicz
On 03/10/2013 15:58, Roger Quadros wrote:
Hi Benoit,
On 10/03/2013 04:44 PM, Benoit Cousson wrote:
On 03/10/2013 14:05, Benoit Cousson wrote:
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
In fact it does not apply correctly on my for_3.13/dts branch :-(
error: arc
On Thu, Oct 03, 2013 at 10:11:36AM -0400, Alan Stern wrote:
> On Thu, 3 Oct 2013, Huang Rui wrote:
>
> > +int usb_amd_hang_symptom_quirk(void)
> > +{
> > + u8 rev;
> > +
> > + usb_amd_find_chipset_info();
> > + rev = amd_chipset.sb_type.rev;
> > + /* SB600 and old version of SB700 have han
On Thu, 3 Oct 2013, Robert Baldyga wrote:
> > This disagrees with the kerneldoc for usb_ep_autoconfig(). For bulk
> > endpoints, wMaxPacket is always supposed to be set to the full-speed
> > value, regardless of what the protocol driver specifies.
>
> Hmm, it looks like all gadgets calls usb_ep_
On Thu, 3 Oct 2013, Huang Rui wrote:
> Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types"
> introduced a new AMD chipset type to filter AMD platforms with different
> chipsets.
>
> According to a recent thread [1], this patch updates USB subsystem hang
> symptom quirk whic
Hi Benoit,
On 10/03/2013 04:44 PM, Benoit Cousson wrote:
> On 03/10/2013 14:05, Benoit Cousson wrote:
>> Hi Roger,
>>
>> Yes, I will. I've been waiting for these ones for so long :-)
>
> In fact it does not apply correctly on my for_3.13/dts branch :-(
>
> error: arch/arm/boot/dts/omap3-beagle.d
On 03/10/2013 14:05, Benoit Cousson wrote:
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
In fact it does not apply correctly on my for_3.13/dts branch :-(
error: arch/arm/boot/dts/omap3-beagle.dts: patch does not apply
Patch failed at 0004 ARM: dts: omap3-beagle: Mak
From: Manjunath Goudar
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly
handle ohci-pxa27x suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_hcd_pxa27x_drv_suspend
From: Manjunath Goudar
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller.Alan Stern suggested, properly handle
ohci-platform suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_platform_suspend() w
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-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly
handle ohci-sm501 suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_sm501_suspend() will ens
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-omap glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-omap suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_omap_suspend() will ensure
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
From: Manjunath 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(
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: 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 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.
Signed-off-by: Manjunath Goudar
Signed-off-by: Manjunat
Hi,
On Wed, Oct 02, 2013 at 04:41:53PM +0300, Roger Quadros wrote:
> On 10/02/2013 04:11 PM, Felipe Balbi wrote:
> > On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote:
> >> Hi Felipe,
> >>
> >> On 09/18/2013 03:49 PM, Roger Quadros wrote:
> >>> "usb_otg_ss_refclk960m" is an optional fu
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
Thanks,
Benoit
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We
Convert the legacy multi gadget to the new interface of f_ecm,
so that later the compatibility layer in f_ecm can be removed.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/Kconfig |1 +
drivers/usb/gadget/multi.c | 68
Here I present the conversion of everything that is required to provide
the equivalent of g_multi.ko with configfs.
v1..v2:
- removed the cause of Felipe returning -ENOLOG
- moved fsg_common_set_sysfs invocation after the lun number is set, so that
the latter operation does not try freeing nonexi
u_ms.ko is needed only together with usb_f_mass_storage.ko. Merge them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/Kconfig |7 ---
drivers/usb/gadget/Makefile |4 +---
2 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/driv
Convert old mass_storage gadget to use the new interface of f_mass_storage
so that later the compatibility layer in f_mass_storage can be removed.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/Kconfig|1 +
drivers/usb/gadget/mass_storage.c
Here I present the conversion of everything that is required to provide
the equivalent of g_acm_ms.ko with configfs.
In fact this series consists of just one patch; everything required to provide
the equivalent of g_acm_ms.ko with configfs has been done in the series related
to the g_mass_storage.
This will be required by configfs integration.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungin Park
---
drivers/usb/gadget/storage_common.c | 42 +++
drivers/usb/gadget/storage_common.h |5
2 files changed, 47 insertions(+), 0 deletions(-)
fsg_common_init is a lengthy function. Factor a portion of it out.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 32 +---
drivers/usb/gadget/f_mass_storage.h |2 ++
2 files changed, 23 insertions(+),
Convert the legacy acm_ms gadget to use the new function interface
of f_mass_storage, so that later the compatibility layer in
f_mass_storage can be removed.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/Kconfig |1 +
drivers/usb/gadget/acm_ms.c |
There are no more old interface users left. Remove it.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 154 +--
drivers/usb/gadget/f_mass_storage.h | 21 -
2 files changed, 1 insertions(+), 174 de
Convert the legacy multi gadget to the new interface of f_rndis,
so that later the compatibility layer in f_rndis can be removed.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/Kconfig |3 +-
drivers/usb/gadget/multi.c | 73 +++
Convert the legacy multi gadget to the new interface of f_mass_storage,
so that later the compatibility layer in f_mass_storage can be removed.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/Kconfig |1 +
drivers/usb/gadget/multi.c | 112 ++
This series aims at integrating configfs into mass storage, the way
it has been done for acm, ncm, ecm, eem, ecm subset, rndis, obex and phonet.
It contains everything that is required to provide the equivalent of
g_mass_storage.ko with configfs.
Mass storage itself is quite large, so the resultin
When configfs is in place, the luns will not be represented in sysfs,
so there will be no struct device associated with a lun.
In order to maintain compatibility and allow configfs adoption
sysfs is made optional in this patch.
As a consequence some debug macros need to be adjusted. Two new
fields
fsg_common_init is a lengthy function. Factor a portion of it out.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 68 +-
drivers/usb/gadget/f_mass_storage.h |2 +
2 files changed, 44 insertions(+)
fsg_common_init is a lengthy function. Factor portions of it out.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 16 ++--
drivers/usb/gadget/f_mass_storage.h |5 +
2 files changed, 19 insertions(+), 2 deletions(-
fsg_common_init is a lengthy function. Factor a portion of it out.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 29 +++--
drivers/usb/gadget/f_mass_storage.h |3 +++
2 files changed, 22 insertions(+), 1
Converting mass storage to the new function interface requires converting
the USB mass storage's function code and its users.
This patch converts the f_mass_storage.c to the new function interface.
The file is now compiled into a separate usb_f_mass_storage.ko module.
The old function interface is
fsg_common_init is a lengthy function. Factor portions of it out.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 81 +++---
drivers/usb/gadget/f_mass_storage.h |8 +++
2 files changed, 72 insertions(+
When configfs is in place, gadgets will have to be able to free
fsg buffers. Add a helper function.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff
fsg_common_init is a lengthy function. Factor a portion of it out.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 41 +-
1 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/ga
Show/store methods for sysfs attributes contain code which can be used
also by configfs. Make them abstract the source the lun and rw_semaphore
are taken from.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 27 +-
fsg_common_init is a lengthy function. Factor a portion of it out.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 52 +--
drivers/usb/gadget/f_mass_storage.h |3 ++
2 files changed, 34 insertions(
>From this commit on f_mass_storage is available through configfs.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
.../ABI/testing/configfs-usb-gadget-mass-storage | 31 ++
drivers/usb/gadget/Kconfig | 11 +
drivers/usb/gadget/f_mass_storage.c
fsg_common_init is a lengthy function. Factor portions of it out.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 260 ++-
drivers/usb/gadget/f_mass_storage.h |6 +
2 files changed, 169 insertions(+
Hello,
On 10/02/2013 05:48 PM, Alan Stern wrote:
On Wed, 2 Oct 2013, Robert Baldyga wrote:
This patch fix validation of maxpacket value given in endpoint descriptor.
Add check of maxpacket for bulk endpoints. If maxpacket is not set in
descriptor, it's set to maximum value for given type on end
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
> We no longer need to model the RESET line as a regulator since
> the USB phy-nop driver accepts "reset-gpios" property.
>
> Signed-off
1 - 100 of 114 matches
Mail list logo
