On 07.03.2016 18:56, Sergei Shtylyov wrote:
On 03/07/2016 07:08 PM, Petr Kulhavy wrote:
Hello
On 07.03.2016 14:29, Sergei Shtylyov wrote:
Hello.
On 3/7/2016 2:20 PM, Petr Kulhavy wrote:
@@ -544,17 +643,25 @@ static int da8xx_probe(struct platform_device
*pdev)
pinfo.data = pdata;
Hi Felipe,
On Mon, Mar 7, 2016 at 11:13 PM, Felipe Balbi wrote:
>
> Hi,
>
> Victor Dodon writes:
>> [ text/plain ]
>> Sorry, I accidentally pressed Send
>>
>> On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote:
>>> Hi all,
>>>
>>> I have some performance issues with the host port on a Beaglebon
Hi,
Victor Dodon writes:
> [ text/plain ]
> Hi Felipe,
>
> On Mon, Mar 7, 2016 at 11:13 PM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Victor Dodon writes:
>>> [ text/plain ]
>>> Sorry, I accidentally pressed Send
>>>
>>> On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote:
Hi all,
I h
From: "Du, Changbin"
This is a reworked patch based on reverted commit d8f00cd685f5 ("usb:
hub: do not clear BOS field during reset device").
The privious one caused double mem-free if run to re_enumerate label.
New patch title changed to distinguish from old one. And I have tested
it with memor
On 03/08/2016 08:43 AM, Felipe Balbi wrote:
(...)
This is necessary because this driver is actually wrong in which is
asking for the host to power itself. This is not specified on USB-MIDI
specification, neither makes any sense since this configuration is
device specific.
>>>
Hi,
Krzysztof Opasiak writes:
> [ text/plain ]
>
>
> On 03/08/2016 08:43 AM, Felipe Balbi wrote:
> (...)
>
> This is necessary because this driver is actually wrong in which is
> asking for the host to power itself. This is not specified on USB-MIDI
> specification, neither makes any
Hi,
On 05-03-16 21:02, Greg Kroah-Hartman wrote:
On Fri, Mar 04, 2016 at 08:27:26AM +0100, Hans de Goede wrote:
Hi,
On 04-03-16 05:35, Greg Kroah-Hartman wrote:
On Sat, Feb 27, 2016 at 05:58:58PM +0100, Hans de Goede wrote:
From: Reinder de Haan
At least the EHCI/OHCI found on the Allwinnn
On Tue, Mar 8, 2016 at 12:39 AM, Oliver Neukum wrote:
> On Mon, 2016-03-07 at 22:50 +0300, Andrey Konovalov wrote:
>> Could you also add:
>> Reported-by: Andrey Konovalov
>
> Well, the exact bug you reported is fixed in Bjorn's
> patch the way Linus suggested. I'm fixing just a further
> race tha
On 04.03.2016 20:30, Timur Tabi wrote:
On Fri, Oct 9, 2015 at 5:30 AM, Mathias Nyman
wrote:
The xhci platform driver needs to work on systems that
either only support 64-bit DMA or only support 32-bit DMA.
Attempt to set a coherent dma mask for 64-bit DMA, and
attempt again with 32-bit DMA if t
Hi Balbi,
On 08/03/16 07:37, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello writes:
>> Since f_midi_transmit is called by both ALSA and USB frameworks, it
> can
>> potentially cause a race condition between both calls. This is bad
> because the
>> way f_midi_transmit
Hi,
Mathias Nyman writes:
> [ text/plain ]
> On 04.03.2016 20:30, Timur Tabi wrote:
>> On Fri, Oct 9, 2015 at 5:30 AM, Mathias Nyman
>> wrote:
>>> The xhci platform driver needs to work on systems that
>>> either only support 64-bit DMA or only support 32-bit DMA.
>>> Attempt to set a coherent
Hi Balbi,
On 08/03/16 07:43, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello writes:
@@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
module_param(out_ports, uint, S_IRUGO);
MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
Hi,
Felipe Ferreri Tonello writes:
>>> Since f_midi_transmit is called by both ALSA and USB frameworks, it
>> can
>>> potentially cause a race condition between both calls. This is bad
>> because the
>>> way f_midi_transmit is implemented can't handle concurrent calls.
>>
Hi,
Felipe Ferreri Tonello writes:
>>> its easy and simple to setup and use. So I think before we have some
>>
>> so is configfs.
>>
>>> sort of preset library of configfs-based gadget drivers, we still need
>>> these modules.
>>
>> there is already a library called libusbg.
>
> By preset lib
On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
(...)
>>
>>> sort of preset library of configfs-based gadget drivers, we still need
>>> these modules.
>>
>> there is already a library called libusbg.
>
> By preset library I meant scripts or little programs that implement the
> legacy dri
Hi,
Krzysztof Opasiak writes:
> [ text/plain ]
>
>
> On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
> (...)
>
>>>
sort of preset library of configfs-based gadget drivers, we still need
these modules.
>>>
>>> there is already a library called libusbg.
>>
>> By preset library I
Hello.
On 3/8/2016 11:35 AM, Petr Kulhavy wrote:
@@ -544,17 +643,25 @@ static int da8xx_probe(struct platform_device *pdev)
pinfo.data = pdata;
pinfo.size_data = sizeof(*pdata);
+ret = regulator_enable(glue->vbus_supply);
What does this achieve with a regulator that can't
Mathias Nyman wrote:
Evolution of the patch can be found in this thread:
http://www.spinics.net/lists/linux-usb/msg128495.html
I think version 8 was the final one.
I couldn't find any answers to my questions in that thread. The key
change to the patch was made between v1 and v2:
+
From: Felipe Balbi
> Sent: 08 March 2016 13:48
...
> wonder if we should provide a generic static inline for that. Seems like
> that will replicate on many drivers. How about:
>
> static inline int dma_try_mask_and_coherent(struct device *dev)
> {
> int ret;
>
> ret = dma_set_mask
Hi,
On 08/03/16 14:20, Felipe Balbi wrote:
>
> Hi,
>
> Krzysztof Opasiak writes:
>> [ text/plain ]
>>
>>
>> On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
>> (...)
>>
> sort of preset library of configfs-based gadget drivers, we still need
> these modules.
there i
Hi Balbi,
On 08/03/16 14:01, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello writes:
Since f_midi_transmit is called by both ALSA and USB frameworks, it
>>> can
potentially cause a race condition between both calls. This is bad
>>> because the
way f_mid
This is from ver-linux:
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux torr 4.4.2-smp #1 SMP Tue Feb 23 12:20:39 PST 2016 i686 Intel(R)
Core(TM)2 Quad CPU @ 2.66GHz GenuineIntel GNU/Linux
On Tue, Mar 08, 2016 at 05:48:07PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 3/8/2016 11:35 AM, Petr Kulhavy wrote:
>
> >@@ -544,17 +643,25 @@ static int da8xx_probe(struct platform_device
> >*pdev)
> > pinfo.data = pdata;
> > pinfo.size_data = sizeof(*pdata);
> >>>
On Tue, Mar 08, 2016 at 08:15:04AM -0800, Allen Ashley wrote:
> This is from ver-linux:
> If some fields are empty or look unusual you may have an old version.
> Compare to the current minimal requirements in Documentation/Changes.
>
> Linux torr 4.4.2-smp #1 SMP Tue Feb 23 12:20:39 PST 2016 i686
[Second transmission; hopefully this one will go through...]
Alan,
How about the attached patch? Works for me but definitely needs more
review and testing.
--david
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
Mo
From: David Mosberger
usb_submit_urb() may take quite long to execute. For example, a
single sg list may have 30 or more entries, possibly leading to that
many calls to DMA-map pages. This can cause interrupt latency of
several hundred micro-seconds.
Avoid the problem by releasing the io->lock
Hi Doug,
> Doug Anderson hat am 7. März 2016 um 22:30
> geschrieben:
>
>
> Stefan,
>
> On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren wrote:
> > Hi Doug,
> >
> >> Douglas Anderson hat am 4. März 2016 um 19:23
> >> geschrieben:
> >>
> >>
> >> This reverts commit 192cb07f7928 ("usb: dwc2: Fix pro
On 07.03.2016 22:13, Greg Kroah-Hartman wrote:
On Mon, Mar 07, 2016 at 11:09:36AM -0800, Andy Lutomirski wrote:
Quick ping here: this is still busted on 4.5-rc6.
On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski wrote:
On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman
wrote:
On 17.02.2016 07:19
Hi Greg,
Here are the usb-serial updates for 4.6-rc1.
These patches have all been in linux-next for a while now without any
reported issues.
Thanks,
Johan
The following changes since commit 81f70ba233d5f660e1ea5fe23260ee323af5d53a:
Linux 4.5-rc5 (2016-02-20 13:39:35 -0800)
are available in
On Tue, Mar 8, 2016 at 10:14 AM, Mathias Nyman wrote:
> On 07.03.2016 22:13, Greg Kroah-Hartman wrote:
>>
>> On Mon, Mar 07, 2016 at 11:09:36AM -0800, Andy Lutomirski wrote:
>>>
>>> Quick ping here: this is still busted on 4.5-rc6.
>>>
>>> On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski wrote:
>
On Mon, Mar 7, 2016 at 12:15 PM, Bjørn Mork wrote:
> usbnet_link_change will call schedule_work and should be
> avoided if bind is failing. Otherwise we will end up with
> scheduled work referring to a netdev which has gone away.
>
> Instead of making the call conditional, we can just defer
> it t
On Wed, Mar 2, 2016 at 4:59 PM, Li Yang wrote:
> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
> wrote:
>> On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
>>
>>>
>>>
>>> On 22/02/16 05:32, Bjorn Andersson wrote:
>>> >On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly
On Tue, 2016-03-08 at 11:43 -0800, Linus Torvalds wrote:
> Why is that FLAG_LINK_INTR thing not just always used?
>
> The _only_ thing that FLAG_LINK_INTR does is to cause
>
> usbnet_link_change(dev, 0, 0);
>
> to be called after network device attach. That doesn't seem to be
> controver
Linus Torvalds writes:
> So looking at this, I wonder...
>
> Why is that FLAG_LINK_INTR thing not just always used?
>
> The _only_ thing that FLAG_LINK_INTR does is to cause
>
> usbnet_link_change(dev, 0, 0);
>
> to be called after network device attach. That doesn't seem to be
> controv
Since f_midi_transmit is called by both ALSA and USB sub-systems, it can
potentially cause a race condition between both calls because f_midi_transmit
is not reentrant nor thread-safe. This is due to an implementation detail that
the transmit function looks for the next available usb request from t
On Tue, 2016-03-08 at 21:18 +0100, Bjørn Mork wrote:
> > Why is it called "FLAG_LINK_INTR" anyway? There doesn't seem to be
> > anything "INTR" about it.
>
> Beats me. I can only say that I always find naming difficult...
> We could ask Ben, who introduced it in:
It used to be done over USB inte
This refactor results in a cleaner state machine code and promotes
consistency, readability, and maintanability of this driver.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 204 ++-
1 file changed, 129 insertions(+), 75 deletions(-)
On Tue, 2016-03-08 at 21:18 +0100, Bjørn Mork wrote:
> Linus Torvalds writes:
>
> >
> > So looking at this, I wonder...
> >
> > Why is that FLAG_LINK_INTR thing not just always used?
> >
> > The _only_ thing that FLAG_LINK_INTR does is to cause
> >
> > usbnet_link_change(dev, 0, 0);
>
Passing overlapping source and destination is fragile, and in this
case we can even simplify the code and avoid the huge stack buffer by
using the %p extension for printing a small hex dump.
Signed-off-by: Rasmus Villemoes
---
drivers/usb/atm/usbatm.c | 11 ---
1 file changed, 4 insertio
Hi,
This series extends USB/IP support in Kernel by adding an emulated
USB Device Controller. This allows to virtually connect USB gadget
created on a server to some remote machine as if it would be a fully
functional USB device.
--
Current design:
--
From: Igor Kotrasinski
This file contains functions for returning requests to the client.
It also has functions that add requests completed in vudc_rx and
vudc_transfer to the return queue.
This commit is a result of cooperation between Samsung R&D Institute
Poland and Open Operating Systems Stu
From: Igor Kotrasinski
This file contains a function that simulates USB traffic, based on
the one in dummy_hcd. Is also handles udc-directed control
requests, and contains functions for setting up and controlling
a timer for the emulation.
This commit is a result of cooperation between Samsung R
From: Igor Kotrasinski
Add functions which allows to receive urbs from the client.
It receives traffic in a loop in a separate thread.
This commit is a result of cooperation between Samsung R&D Institute
Poland and Open Operating Systems Student Society at University
of Warsaw (O2S3@UW) consisti
From: Igor Kotrasinski
Add header with definitions needed by vudc driver.
This commit is a result of cooperation between Samsung R&D Institute
Poland and Open Operating Systems Student Society at University
of Warsaw (O2S3@UW) consisting of:
Igor Kotrasinski
Karol Kosik
Ewelina Ko
From: Igor Kotrasinski
Add sysfs attributes to allow controlling vudc from usbip tools.
dev_desc - device descriptor of current gadget. This is required to
be consisten with current usbip protocol and allow to list
exportable devices on given machine.
usbip_sockfd - allows to
Extract the code from current stub driver backend and a common
interface for both stub driver and vudc. This allows to share most
of the usbipd code for both of them.
Based on code created in cooperation with Open Operating Systems
Student Society at University of Warsaw (O2S3@UW) consisting of:
From: Igor Kotrasinski
Add endpoints definitions and ops for both endpoints and gadget.
Add also a suitable platform driver and functions for handling
usbip events.
This commit is a result of cooperation between Samsung R&D Institute
Poland and Open Operating Systems Student Society at Universit
From: Igor Kotrasinski
Add constants for VUDC events in usbip_common.h
and make use of them in usbip_common.c.
This commit is a result of cooperation between Samsung R&D Institute
Poland and Open Operating Systems Student Society at University
of Warsaw (O2S3@UW) consisting of:
Igor Kotrasi
From: Igor Kotrasinski
Add main vudc module file. This allows us to register suitable
platform device and driver (just like dummy_hcd does).
Currently number of vudc instances is determined using module
parameter but whole infrastructure is suitable to make vudc
creation dynamic (for example via
From: Igor Kotrasinski
Add the driver to Kconfig to make it visible in menuconfig
and allow people to compile it.
This commit is a result of cooperation between Samsung R&D Institute
Poland and Open Operating Systems Student Society at University
of Warsaw (O2S3@UW) consisting of:
Igor Kotr
From: Igor Kotrasinski
Modify userspace tools to allow exporting and connecting to vudc.
This commit is a result of cooperation between Samsung R&D Institute
Poland and Open Operating Systems Student Society at University
of Warsaw (O2S3@UW) consisting of:
Igor Kotrasinski
Karol Kosik
Adds an equivalent of usbip_host_driver for the vudc. Most
of the code is already shared, but this adds some vudc specific
code for getting information about devices.
Based on code created in cooperation with Open Operating Systems
Student Society at University of Warsaw (O2S3@UW) consisting of:
On Tue, 8 Mar 2016, David Mosberger-Tang wrote:
> From: David Mosberger
>
> usb_submit_urb() may take quite long to execute. For example, a
> single sg list may have 30 or more entries, possibly leading to that
> many calls to DMA-map pages. This can cause interrupt latency of
> several hundre
On Tue, 2016-03-08 at 21:40 +0100, Rasmus Villemoes wrote:
> Passing overlapping source and destination is fragile, and in this
> case we can even simplify the code and avoid the huge stack buffer by
> using the %p extension for printing a small hex dump.
[]
> diff --git a/drivers/usb/atm/usbatm.c
Alan,
Thanks for your feedback!
> This should now be GFP_NOIO.
OK, I updated the patch to fix that. Good catch.
> Strictly speaking, this loop should run backward. Then the
> spin_unlock() could be replaced with spin_unlock_irqrestore().
Good idea. A separate patch for this is included.
From: David Mosberger
usb_submit_urb() may take quite long to execute. For example, a
single sg list may have 30 or more entries, possibly leading to that
many calls to DMA-map pages. This can cause interrupt latency of
several hundred micro-seconds.
Avoid the problem by releasing the io->lock
From: David Mosberger
Restructure usb_sg_cancel() so we don't have to disable interrupts
while cancelling the URBs.
Suggested-by: Alan Stern
Signed-off-by: David Mosberger
---
drivers/usb/core/message.c | 37 +
1 file changed, 17 insertions(+), 20 deletions
The usb_get_phy() function returns either a valid pointer to phy or
ERR_PTR() error, check for NULL always fails and may lead to oops on
error path, fix this issue.
Signed-off-by: Vladimir Zapolskiy
---
drivers/usb/musb/jz4740.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
Hi Felipe,
On 09.03.2016 02:57, Vladimir Zapolskiy wrote:
> The usb_get_phy() function returns either a valid pointer to phy or
> ERR_PTR() error, check for NULL always fails and may lead to oops on
> error path, fix this issue.
>
> Signed-off-by: Vladimir Zapolskiy
> ---
> drivers/usb/musb/jz4
On Wed, Mar 09, 2016 at 03:17:21AM +0200, Vladimir Zapolskiy wrote:
> Hi Felipe,
>
> On 09.03.2016 02:57, Vladimir Zapolskiy wrote:
> > The usb_get_phy() function returns either a valid pointer to phy or
> > ERR_PTR() error, check for NULL always fails and may lead to oops on
> > error path, fix t
On Tue, Mar 8, 2016 at 11:52 AM, Li Yang wrote:
> On Wed, Mar 2, 2016 at 4:59 PM, Li Yang wrote:
>> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
>> wrote:
>>> On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
>>>
On 22/02/16 05:32, Bjorn Andersson wrote:
>On certai
On Tue, Mar 08, 2016 at 07:17:29PM +0100, Johan Hovold wrote:
> Hi Greg,
>
> Here are the usb-serial updates for 4.6-rc1.
>
> These patches have all been in linux-next for a while now without any
> reported issues.
>
> Thanks,
> Johan
>
>
> The following changes since commit 81f70ba233d5f660e1
I submitted a bug report about the UAS module crashing
earlier today (about 13 hours ago). It was suggested
by greg k-h that a patch be made to uas.c:
I changed:
.can_queue = 65535 /* Is there a limit on the _host_ ? */
to
.can_queue = MAX_CMNDS /* Is there a limit on the _host_ ? */
At t
Hi,
"Felipe F. Tonello" writes:
> [ text/plain ]
> This refactor results in a cleaner state machine code and promotes
> consistency, readability, and maintanability of this driver.
>
> Signed-off-by: Felipe F. Tonello
while working on this driver ...
> ---
> drivers/usb/gadget/function/f_mid
Hi,
"Felipe F. Tonello" writes:
> [ text/plain ]
> Since f_midi_transmit is called by both ALSA and USB sub-systems, it can
> potentially cause a race condition between both calls because f_midi_transmit
> is not reentrant nor thread-safe. This is due to an implementation detail that
> the trans
Hi,
"Felipe F. Tonello" writes:
> [ text/plain ]
> Since f_midi_transmit is called by both ALSA and USB sub-systems, it can
> potentially cause a race condition between both calls because f_midi_transmit
> is not reentrant nor thread-safe. This is due to an implementation detail that
> the trans
Hi,
Felipe Ferreri Tonello writes:
>> ps: can you point me to your devices shipping with f_midi ? Which
>> architecture are they using ? Which USB Peripheral Controller ? This
>> might be a good addition to my test farm depending on your answers above
>> :-p
>
> Seaboard GRAND[1]. Freescale's i.
67 matches
Mail list logo
