On Thu, Oct 9, 2014 at 4:14 PM, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 01:45:47PM +0900, Yoshihiro Shimoda wrote:
>> This patch fixes an issue that suspend/resume cannot work correctly
>> on xhci-rcar because the xhci driver output the following log:
>>
>> xhci-hcd ee00.usb: WAR
Hi Felipe,
Thank you very much for taking time in reviewing the patch.
I will try to improve the patch as per your suggestions.
however,i have few queries which i wanted to understand from you.
On 7 October 2014 19:55, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 07, 2014 at 02:45:44PM +0530, Kiran
On 10/09/2014 04:21 PM, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 09:41:16AM +0200, Robert Baldyga wrote:
>> During FunctionFS bind, ffs_data_get() function was called twice
>> (in functionfs_bind() and in ffs_do_functionfs_bind()), while on unbind
>> ffs_data_put() was called once (in function
On 10/10/14 00:47, Peter Hurley wrote:
> Hi Andre,
>
> On 10/08/2014 11:54 PM, Andre Wolokita wrote:
>> On 09/10/14 14:38, Greg KH wrote:
>>> On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
On 09/10/14 13:56, Greg KH wrote:
> On Thu, Oct 09, 2014 at 11:23:59AM +1100, And
On 10/09/2014 07:07 PM, Mark Knibbs wrote:
[For removable media, it's a good idea to disable polling for medium
changes before running a test. Depending on kernel & distribution that could
be achieved by doing
udisks --inhibit-all-polling
and/or for example
echo -1 >/sys/block/sdb/even
Hi,
On Fri, Oct 10, 2014 at 08:43:20AM +0800, Huang Rui wrote:
> > > But it does't block my building. Because I can comment CROSS_COMPILE at
> > > makefile.
> > >
> > > I am testing my driver and dwc3 controller with MSC tool currently, and
> > > will
> > > let you know message log later.
> >
>
On Thu, Oct 09, 2014 at 10:09:37AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Thu, Oct 09, 2014 at 01:10:36PM +0800, Huang Rui wrote:
>
>
> don't worry about that. Some of the tools need to run on the target but
> you're not doing that :-) You can make a specific tool by e.g. "make msc".
>
> >
On Fri, Oct 10, 2014 at 08:43:19AM +0800, Huang Rui wrote:
> On Thu, Oct 09, 2014 at 10:09:37AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Oct 09, 2014 at 01:10:36PM +0800, Huang Rui wrote:
> >
>
>
>
> >
> > don't worry about that. Some of the tools need to run on the target but
> > y
I have tested Kernel versions starting with 3.15.1 all the way to
3.15.10 under both Arch and Fedora, using both NEC and Intel host
controllers and the result is always the same.
Connecting a Asmedia ASM1051e device causes a kernel panic after about
a minute of connection.
Interestingly, Asmedia
On Thu, Oct 09, 2014 at 05:58:32PM -0700, Greg KH wrote:
> On Fri, Oct 10, 2014 at 01:57:10AM +0200, Thomas Bork wrote:
> > Am 09.10.2014 um 22:47 Greg KH wrote:
> >
> > >That's tens of thousands of changes difference, I'm sorry, but if you
> > >are stuck on an old kernel, you need to get support
On Fri, Oct 10, 2014 at 01:57:10AM +0200, Thomas Bork wrote:
> Am 09.10.2014 um 22:47 Greg KH wrote:
>
> >That's tens of thousands of changes difference, I'm sorry, but if you
> >are stuck on an old kernel, you need to get support from the companies
> >that are forcing you to use such an obsolete
Am 10.10.2014 um 02:00 I wrote:
The patch doesn't apply cleanly to 3.2.63, trying the second approach.
Thanks for your help!
Doesn't work. Applied cd70469d084fde198dc07c1a31b8463562228a5a by hand.
Works now.
Thanks again!
der tom
--
To unsubscribe from this list: send the line "unsubscribe
Hi,
(2014/10/09 23:14), Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 01:45:47PM +0900, Yoshihiro Shimoda wrote:
>> This patch fixes an issue that suspend/resume cannot work correctly
>> on xhci-rcar because the xhci driver output the following log:
>>
>> xhci-hcd ee00.usb: WARN: xHC C
Hello.
(2014/10/09 21:51), Sergei Shtylyov wrote:
> Hello.
>
> On 10/09/2014 05:07 AM, Yoshihiro Shimoda wrote:
>
>>> Enable HS-USB device for the Koelsch board, defining the GPIO that the
>>> driver
>>> should check when probing (which is the ID output from MAX3355 OTG chip).
>
>>> Note that
Am 09.10.2014 um 23:31 Thomas Pugliese wrote:
I actually ran into this same issue a while back when porting WUSB updates
back to older kernels. The commit that fixes the warning is
cd70469d084fde198dc07c1a31b8463562228a5a from Linus' tree. If that
doesn't apply cleanly, you could also change t
Am 09.10.2014 um 22:47 Greg KH wrote:
That's tens of thousands of changes difference, I'm sorry, but if you
are stuck on an old kernel, you need to get support from the companies
that are forcing you to use such an obsolete kernel release.
It is an stable longterm release and I have to use thi
Hi Alan,
On Thursday 09 October 2014 12:51:34 Alan Stern wrote:
> On Thu, 9 Oct 2014, Michael Grzeschik wrote:
> > This patch adds an hub_control override to toggle the PORT_POWER
> > by the registered regulator. That is needed when an external
> > GPIO is used instead of the default PORT_POWER bi
From: Hayes Wang
Date: Thu, 9 Oct 2014 18:00:23 +0800
> v2:
> Make sure the autoresume wouldn't occur inside the mutex, otherwise
> the dead lock would happen. For the purpose, adjust some code about
> autosuspend/autoresume.
>
> v1:
> Use mutex to avoid that the serial hw settings would be inte
From: Hayes Wang
Date: Thu, 9 Oct 2014 07:59:35 +
> If I use the rtnl_lock(), I get a dead lock when enabling autosuspend.
>
> Case 1:
>autosuspend before calling open.
>rtnl_lock()
>call open
>try to autoresume and rtl8152_resume is called.
>dead lock occurs.
>
> Case 2
From: Evgeny Boger
Date: Thu, 9 Oct 2014 02:14:58 +0400
> There might be 11 GPIOs in total.
> Last three GPIOs (offsets 8-10, 0-based) are shared with FDX, LNKA, SPD
> LEDs respectively. The LEDs are driven by chip by default at startup time.
> Once the corresponding GPIO is requested, the chip
Hi,
On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
> What GCC version are you using?
>
> 4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these
> find_get_entry() crashes with 0x involved smell a lot like the
> earlier reports from kernels build with th
Hi,
On Thu, Oct 09, 2014 at 03:46:37PM -0500, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
> > On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
> > > alright, it's pretty deterministic however. Always on the same test, no
> > > matter which USB
On Thu, 9 Oct 2014, Thomas Bork wrote:
> Hi @all,
>
> loading and unloading vhci-hcd in 3.2.63-longterm produces a warning in syslog
> (Trying to free already-free IRQ 0). I know vhci-hcd is staging but
> backporting as much as possible changes of usbip from 3.16.4 (without the
> switch to udev
I did see that note and link but it was an to a pretty old thread. I
figured something must have happend on this since then. There seem to
be quite a few products with these displaylink chip sets in them.
If its really just a bad product as as far as linux goes could you
recommend other USB to Dua
On Thu, 9 Oct 2014, Mark Knibbs wrote:
> Since setting max_lun to 0 in the US_FL_SINGLE_LUN case is done elsewhere,
> how about setting max_lun to 7 for US_FL_SCM_MULT_TARG next to that? So the
> above could could become:
>
> /*
>* Determine the max LUN value for bulk-only devices,
On Thu, Oct 09, 2014 at 07:37:12PM +0200, Thomas Bork wrote:
> Hi @all,
>
> loading and unloading vhci-hcd in 3.2.63-longterm produces a warning in
> syslog (Trying to free already-free IRQ 0). I know vhci-hcd is staging but
> backporting as much as possible changes of usbip from 3.16.4 (without t
Hi,
On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
> On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
> > alright, it's pretty deterministic however. Always on the same test, no
> > matter which USB controller, no matter if backing store is RAM or MMC.
> >
> > Those t
On Thu, 9 Oct 2014, Dennis Gesker wrote:
> By the way, Alan. Thank you for looking at that. I'd really like to
> get this working. --drg
Well, I'm not so much looking at this as trying to collect information
that will help the people who do know what to look for. The standard
information reque
On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
> alright, it's pretty deterministic however. Always on the same test, no
> matter which USB controller, no matter if backing store is RAM or MMC.
>
> Those two undefined instructions on the disassembly caught my attention,
> perhaps I'
Hi,
On Wed, 8 Oct 2014 16:13:22 -0400 (EDT)
Alan Stern wrote:
> On Wed, 8 Oct 2014, Mark Knibbs wrote:
>
> > SCM-based USB-SCSI converters work with multi-LUN devices. I tested an MPL
> > ...
> > With Linux however, only the lower slot (LUN 0) is detected. It seems the
> > us->max_lun field is
On Thu, Sep 25, 2014 at 6:41 PM, Octavian Purdila
wrote:
> Changes since v3:
>
> * undo a whitespace change
>
> * one more error path cleanup
>
> * add commit body to the last patch
>
> Changes since v2:
>
> * switch to using devm_ allocation
>
> * remove unused platform_device
>
> Changes si
Hi,
On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
> > I'm thinking it's not the slot pointer itself that's bad, because
> > __radix_tree_lookup() dereferences that to test if it's populated
> > before returning it, and slot life-time is guaranteed by RCU.
> >
> > That would only l
On Thu, Oct 9, 2014 at 10:44 PM, Joe Perches wrote:
> On Thu, 2014-10-09 at 22:22 +0300, Octavian Purdila wrote:
>> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
>> Master Adapter DLN-2. Details about the device can be found here:
>
> trivia:
>
>> diff --git a/drivers/mfd/Kconf
File names in the heading comments fell out of favor long ago, and these weren't
even changed when the drivers were moved from drivers/usb/otg/, so remove them
at last...
Signed-off-by: Sergei Shtylyov
---
Changes in version 2:
- fixed typos in the summary.
This patch is atop of the 'next' bran
File names in the heading comments fell out of favor long ago, and these weren't
even changed when the drivers were moved from drivers/usb/otg/, so remove them
at last...
Signed-off-by: Sergei Shtylyov
---
This patch is atop of the 'next' branch of Felipe's 'usb.git' repo.
drivers/usb/phy/phy-
On Thu, 2014-10-09 at 22:22 +0300, Octavian Purdila wrote:
> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
> Master Adapter DLN-2. Details about the device can be found here:
trivia:
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
[]
> +config MFD_DLN2
> + tristat
This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.
Because th
Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set
operation but do not need a threaded irq handler.
Signed-off-by: Octavian Purdila
---
drivers/gpio/gpiolib.c | 2 +-
include/linux/gpio/driver.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/g
From: Daniel Baluta
This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.
[1] https://www.diolan.com/downloads/dln-api
Changes since v6:
* MFD: make sure DLN2_HANDLE_EVENT stays 0, move a few operations out
of the lock block, renamed one missed _rx_callback function to
_event_callback, speed-up disconnect by checking for it in
find_free_slot, remove the URB submit helper and simplify URB
resubmit code, use
From: Laurentiu Palcu
This patch adds support for the Diolan DLN-2 I2C master module. Due
to hardware limitations it does not support SMBUS quick commands.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 6.2.2 for the I2C
master mod
By the way, Alan. Thank you for looking at that. I'd really like to
get this working. --drg
On Thu, Oct 9, 2014 at 1:03 PM, Dennis Gesker wrote:
> On Wed, Oct 8, 2014 at 2:23 PM, Alan Stern wrote:
>> lsusb -v
>
>
> Bus 002 Device 003: ID 04f2:b34c Chicony Electronics Co., Ltd
> Device Descriptor
On Wed, Oct 8, 2014 at 2:23 PM, Alan Stern wrote:
> lsusb -v
Bus 002 Device 003: ID 04f2:b34c Chicony Electronics Co., Ltd
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass
Hi @all,
loading and unloading vhci-hcd in 3.2.63-longterm produces a warning in
syslog (Trying to free already-free IRQ 0). I know vhci-hcd is staging
but backporting as much as possible changes of usbip from 3.16.4
(without the switch to udev) changed nothing to this warning.
I tested kern
On Thu, 9 Oct 2014, Michael Grzeschik wrote:
> This patch adds an hub_control override to toggle the PORT_POWER
> by the registered regulator. That is needed when an external
> GPIO is used instead of the default PORT_POWER bit.
I don't think this is such a good approach. There are places in
eh
Hi Johannes,
On Thu, Oct 09, 2014 at 12:01:38PM -0400, Johannes Weiner wrote:
> On Wed, Oct 08, 2014 at 04:29:38PM -0500, Felipe Balbi wrote:
> > Finally bisected it down to commit 139e561660fe11e0fc35e142a800df3dd7d03e9d
> > (lib: radix_tree: tree node interface). Here's full bisect log:
> >
> >
This patch adds an hub_control override to toggle the PORT_POWER
by the registered regulator. That is needed when an external
GPIO is used instead of the default PORT_POWER bit.
Signed-off-by: Michael Grzeschik
---
drivers/usb/chipidea/host.c | 102 +++-
1
Hi Felipe,
On Wed, Oct 08, 2014 at 04:29:38PM -0500, Felipe Balbi wrote:
> Finally bisected it down to commit 139e561660fe11e0fc35e142a800df3dd7d03e9d
> (lib: radix_tree: tree node interface). Here's full bisect log:
>
> git bisect start
> # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux
- This patch adds a UDC driver for Broadcom's USB3.0 device controller IP(BDC).
- The driver was written using the Felipe's USB tree as a baseline from:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
- The driver is tested on FPGA-PCIe based platform using various gadget driv
On 10/09/2014 10:26 AM, Alan Stern wrote:
> On Thu, 9 Oct 2014, Andre Wolokita wrote:
>
> Isn't this now a "use-after-free" issue?
>
Are you referring to the subsequent call to wait event() on gs_closed()?
>>>
>>> Yes.
>>>
Testing the use-case with this patch applied seemed
Just like some Seagate enclosures, these devices do not seem to grok ata
pass through commands.
Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede
---
drivers/usb/storage/unusual_uas.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/storage/unusual_uas.h
b/dri
Hi,
On Thu, Oct 09, 2014 at 01:10:36PM +0800, Huang Rui wrote:
> > > > ray@hr-ub:~/felipe/usb-tools$ make
> > > > LINK companion-desc
> > > > companion-desc.o: In function `main':
> > > > /home/ray/felipe/usb-tools/companion-desc.c:219: undefined reference to
> > > > `libusb_init'
> >
Hi Andre,
On 10/08/2014 11:54 PM, Andre Wolokita wrote:
> On 09/10/14 14:38, Greg KH wrote:
>> On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
>>> On 09/10/14 13:56, Greg KH wrote:
On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
> Issuing a modprobe -r g_se
On Thu, 9 Oct 2014, Robert Baldyga wrote:
> In fact this patch solves in some way the problem 'who should handle
> requests addressed to device?'.
In theory, such requests should be handled by the top-level gadget
driver (i.e., composite.c or equivalent). By definition, function
drivers handle
On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
> Hi Oliver & Alan,
>
>
>
> Thanks for your inputs.
>
>
>
> I enabled the dynamic debugging for USB HC driver. Please correct me
> if I am wrong.
Debugging the kernel (or doing anything else to the kernel, for that
matter) won't solve the proble
On Thu, 9 Oct 2014, Mark Knibbs wrote:
> I finally finished doing git bisect between 2.6.33 and 2.6.34. Sadly I'm
> not really any the wiser, since the result looks pretty bogus.
>
> The supposedly-bad commit was:
> 002345925e6c45861f60db6f4fc6236713fd8847
> syslog: distinguish between /proc/
On Thu, 9 Oct 2014, Andre Wolokita wrote:
> >>> Isn't this now a "use-after-free" issue?
> >>>
> >>
> >> Are you referring to the subsequent call to wait event() on gs_closed()?
> >
> > Yes.
> >
> >> Testing the use-case with this patch applied seemed to work without any
> >> issues. The ttyGS0
On Thu, Oct 09, 2014 at 09:41:16AM +0200, Robert Baldyga wrote:
> During FunctionFS bind, ffs_data_get() function was called twice
> (in functionfs_bind() and in ffs_do_functionfs_bind()), while on unbind
> ffs_data_put() was called once (in functionfs_unbind() function).
> In result refcount never
If NO_DMA=y:
drivers/built-in.o: In function `xudc_done':
udc-xilinx.c:(.text+0x54f4d2): undefined reference to `usb_gadget_unmap_request'
drivers/built-in.o: In function `xudc_dma_send':
udc-xilinx.c:(.text+0x54f9f8): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In functio
On Thu, Oct 09, 2014 at 01:45:47PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that suspend/resume cannot work correctly
> on xhci-rcar because the xhci driver output the following log:
>
> xhci-hcd ee00.usb: WARN: xHC CMD_RUN timeout
>
> So, this patch adds to set the
On Thu, 9 Oct 2014, Andre Wolokita wrote:
> Issuing a modprobe -r g_serial command to the target
> over the gadget serial communications line causes
> modprobe to enter uninterruptable sleep, leaving the
> system in an unstable state.
>
> The associated tty_port.count won't drop to 0 because
> th
This patch modifies the usb_authorize_device() function such as that it does
not reload the device descriptor for wired devices. The reasons for this
are as follows:
* Some devices dislike the master requesting the descriptor from them twice,
failing on the usb_get_device_descriptor() call with
On Thu, Oct 09 2014, Robert Baldyga wrote:
> Since we can compose gadgets from many functions, there is the problem
> related to gadget breakage while FunctionFS daemon being closed. FFS
> function is userspace code so there is no way to know when it will close
> files (it doesn't matter what is t
Since we can compose gadgets from many functions, there is the problem
related to gadget breakage while FunctionFS daemon being closed. FFS
function is userspace code so there is no way to know when it will close
files (it doesn't matter what is the reason of this situation, it can
be daemon logic,
On Wed, Oct 08, 2014 at 03:33:28PM +0300, Octavian Purdila wrote:
> On Wed, Oct 8, 2014 at 3:04 PM, Johan Hovold wrote:
> > On Wed, Oct 08, 2014 at 01:54:07PM +0300, Octavian Purdila wrote:
> >> On Wed, Oct 8, 2014 at 12:23 PM, Johan Hovold wrote:
> >> > On Thu, Sep 25, 2014 at 07:07:31PM +0300,
On Thu, Oct 09, 2014 at 11:59:50AM +0100, Lee Jones wrote:
> On Thu, 09 Oct 2014, Johan Hovold wrote:
> > On Thu, Oct 09, 2014 at 08:40:29AM +0100, Lee Jones wrote:
> > > On Mon, 06 Oct 2014, Muthu Mani wrote:
> > > > diff --git a/include/linux/mfd/cyusbs23x.h
> > > > b/include/linux/mfd/cyusbs23
Hello.
On 10/09/2014 05:07 AM, Yoshihiro Shimoda wrote:
Enable HS-USB device for the Koelsch board, defining the GPIO that the driver
should check when probing (which is the ID output from MAX3355 OTG chip).
Note that there will be pinctrl-related error messages if both internal PCI
and HS-U
On 10/09/2014 01:59 PM, Andrzej Pietrasiewicz wrote:
> W dniu 08.10.2014 o 15:06, Felipe Balbi pisze:
>> Hi,
>>
>> On Wed, Oct 08, 2014 at 01:32:31PM +0200, Andrzej Pietrasiewicz wrote:
>>> Some not-so-well-behaving USB hosts with a popular proprietary operating
>>> system sometimes issue per-devic
W dniu 08.10.2014 o 15:06, Felipe Balbi pisze:
Hi,
On Wed, Oct 08, 2014 at 01:32:31PM +0200, Andrzej Pietrasiewicz wrote:
Some not-so-well-behaving USB hosts with a popular proprietary operating
system sometimes issue per-device requests even though they mean requests
for a particular function,
Since we can compose gadgets from many functions, there is the problem
related to gadget breakage while FunctionFS daemon being closed. FFS
function is userspace code so there is no way to know when it will close
files (it doesn't matter what is the reason of this situation, it can
be daemon logic,
Hi,
On Thu, 09 Oct 2014 16:45:39 +0800
Lu Baolu wrote:
> I got a different result with my machine. Below is the details.
> ...
> >>> Connected to USB 2.0 port via USB 1.1 hub:
> ...
> allen@allen-ivb:~$ sudo ddpt if=/dev/sg2 bs=512 bpt=240 count=65536
> verbose=2
> ...
> time to read data: 30.
On Thu, 09 Oct 2014, Johan Hovold wrote:
> On Thu, Oct 09, 2014 at 08:40:29AM +0100, Lee Jones wrote:
> > On Mon, 06 Oct 2014, Muthu Mani wrote:
>
> > > +static int update_ep_details(struct usb_interface *interface,
> > > + struct cyusbs23x *cyusbs)
> > > +{
> > > + struct
>> On Tue, Oct 07 2014, Alan Stern wrote:
>>> If you want to allow for the possibility of orderly shutdown (and maybe
>>> even possible restart) of a userspace handler, the function library
>>> should first tell the kernel explicitly to disconnect.
> On Tue, 7 Oct 2014, Michal Nazarewicz wrote:
On Mon, 29 Sep 2014 09:28:37 -0400 (EDT)
Alan Stern wrote:
> On Sun, 28 Sep 2014, Mark Knibbs wrote:
>
> > > There's no telling the reason for this difference. It's got to be a
> > > hardware issue, though, not a software problem. Maybe your xHCI
> > > controller just isn't optimized for carry
On Thu, Oct 09 2014, Robert Baldyga wrote:
> During FunctionFS bind, ffs_data_get() function was called twice
> (in functionfs_bind() and in ffs_do_functionfs_bind()), while on unbind
> ffs_data_put() was called once (in functionfs_unbind() function).
> In result refcount never reached value 0, an
Hi,
Isn't the "usb_free_all_descriptors(f)" after "fail" label
redundant? Is it needed at all ?
FILE : drivers/usb/gadget/function/f_eem.c
FUNCTION : eem_bind
In fact this can cause "double-free" in case of failures from
"usb_assign_descriptors"; cause
usb_assign_descriptors alread
v2:
Make sure the autoresume wouldn't occur inside the mutex, otherwise
the dead lock would happen. For the purpose, adjust some code about
autosuspend/autoresume.
v1:
Use mutex to avoid that the serial hw settings would be interrupted
by other settings. Although there is no problem now, it makes
Use the mutex to avoid the settings are interrupted by other ones.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 64 -
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1
Add usb_autopm_xxx for rtl8152_get_settings() ,and remove
usb_autopm_xxx from read_mii_word() and write_mii_word().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drive
Resume the device before setting the feature.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5cfd414..c5afe8c 100644
--- a/drivers/net/usb/r8152.c
+++ b/dr
Hi Mark,
I got a different result with my machine. Below is the details.
>>> Kernel version
allen@allen-ivb:~$ uname -a
Linux allen-ivb 3.17.0+ #1 SMP Thu Oct 9 16:19:28 CST 2014 x86_64 x86_64
x86_64 GNU/Linux
>>> Host controler information
allen@allen-ivb:~$ lspci | grep USB
00:14.0 USB co
On Thu, Oct 09, 2014 at 08:40:29AM +0100, Lee Jones wrote:
> On Mon, 06 Oct 2014, Muthu Mani wrote:
> > +static int update_ep_details(struct usb_interface *interface,
> > + struct cyusbs23x *cyusbs)
> > +{
> > + struct usb_host_interface *iface_desc;
> > + struct usb_
> -Original Message-
> From: Hayes Wang
> Sent: Thursday, October 09, 2014 2:25 PM
> To: net...@vger.kernel.org
> Cc: nic_swsd; linux-ker...@vger.kernel.org;
> linux-usb@vger.kernel.org; Hayes Wang
> Subject: [PATCH net-next] r8152: add rtnl_lock
>
> Add rtnl_lock() for suspend/resume an
David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, October 09, 2014 3:45 AM
[..]
> I think a much simpler fix is to take rtnl_lock() in the workqueue
> function and suspend/resume ops.
>
> Every other place you are adding the mutex already holds the RTNL
> mutex.
If I use the rtnl_lock
On Thu, Oct 9, 2014 at 8:46 AM, RR wrote:
> On Wed, Oct 8, 2014 at 12:18 AM, Alexandre Courbot wrote:
>> On Wed, Oct 8, 2014 at 4:09 PM, Muthu Mani wrote:
-Original Message-
From: Alexandre Courbot [mailto:gnu...@gmail.com]
Sent: Tuesday, October 07, 2014 3:34 PM
To:
During FunctionFS bind, ffs_data_get() function was called twice
(in functionfs_bind() and in ffs_do_functionfs_bind()), while on unbind
ffs_data_put() was called once (in functionfs_unbind() function).
In result refcount never reached value 0, and ffs memory resources has
been never released.
Sin
On Mon, 06 Oct 2014, Muthu Mani wrote:
> Adds support for USB-I2C/GPIO interfaces of Cypress Semiconductor
> CYUSBS234 USB-Serial Bridge controller.
>
> Details about the device can be found at:
> http://www.cypress.com/?rID=84126
>
> Signed-off-by: Muthu Mani
> Signed-off-by: Rajaram Regupathy
Currently this quirk is enabled for the model with the device id 0x0089, it
is needed for the 0x009b model, which is found on the Fujitsu Lifebook u904
as well.
Signed-off-by: Adel Gadllah
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirk
Yet another device affected by this.
Tested-by: Kevin Fenzi
Signed-off-by: Adel Gadllah
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index b40c2c1..e6091e8 100644
--- a/drivers/usb/core/quirks.c
+++ b/
Am 09.10.2014 um 09:19 schrieb Johan Hovold:
On Thu, Oct 09, 2014 at 08:03:22AM +0200, Adel Gadllah wrote:
Currently this quirk is enabled for the model with the device id 0x0089, it
is needed for the 0x009b model, which is found on the Fujitsu Lifebook u904
as well.
Signed-off-by: Adel Gadllah
On Thu, Oct 09, 2014 at 08:03:22AM +0200, Adel Gadllah wrote:
> Currently this quirk is enabled for the model with the device id 0x0089, it
> is needed for the 0x009b model, which is found on the Fujitsu Lifebook u904
> as well.
>
> Signed-off-by: Adel Gadllah
> ---
> drivers/usb/core/quirks.c |
91 matches
Mail list logo
