--
Regards,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Uwe Bonnes писал 25.09.2012 12:46:
"Andrew" == Andrew writes:
Andrew> This is seen on widely used ftdi ft232rl chips. Setting
the
Andrew> parity to something like 'even' results in occasional
framing
Andrew> errors when transmitting data.
And
Alan Stern писал 25.09.2012 19:57:
On Tue, 25 Sep 2012, Greg KH wrote:
On Tue, Sep 25, 2012 at 04:57:43PM +0400, Andrew wrote:
> Uwe Bonnes писал 25.09.2012 12:46:
> >>>>>>"Andrew" == Andrew writes:
> >
> >Andrew> This is seen
your time, please close the bug report at
https://bugzilla.kernel.org/show_bug.cgi?id=47921
--
Regards,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Uwe Bonnes писал 26.09.2012 15:46:
"Andrew" == Andrew writes:
Andrew> Looks like it's a time for a break, I've been missing the
trivia
Andrew> and searching for the bug in the wrong place. Terribly
sorry
Andrew> for wasting your time, p
On Wed, 30 Jan 2013 19:53:22 +0800
Ming Lei wrote:
> The allocation failure is caused by the big sizeof(struct parsed_partitions),
> which is 64K in my 32bit box,
Geeze.
We could fix that nicely by making parsed_partitions.parts an array of
pointers to a single `struct parsed_partition' and all
ci-hcd a library module", we can
> avoid this problem by turning a bus glue into a separate
> module, as we do here for the orion bus glue.
>
> Signed-off-by: Manjunath Goudar
> Signed-off-by: Arnd Bergmann
> Cc: Jason Cooper
> Cc: Andrew Lunn
> ---
> dri
t; > .shutdown = usb_hcd_platform_shutdown,
> > .driver = {
> > - .name = "orion-ehci",
> > + .name = hcd_name,
>
> Is this really what you want -- changing the driver name from
> "orion-ehci" to "ehci-o
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 o
This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn
---
v1->v2
Remove debug module parameter.
Add missing \n to dev_dbg() strings.
Consistent dev_d
On Wed, 30 Oct 2013 00:07:22 +0800 Ming Lei wrote:
> sg_copy_buffer() can't meet demand for some drrivers(such usb
> mass storage), so we have to use the sg_miter_* APIs to access
> sg buffer, then need export sg_miter_skip() for these drivers.
>
> The API is needed for converting to sg_miter_*
:12:00.0 shows everything on the usb3 hub;
hubs, cameras and network adapters (fyi none of which are really usb3 -
all usb2 except the first hub).
i can check whatever you like if you want more info but i'm really only
reporting the message flood.
cheers
andrew--
To unsubscribe from this
> > + if (err) {
> > + mxuport_send_ctrl_urb(serial, RQ_VENDOR_SET_OPEN, 0,
> > + port->port_number);
> > +
> > + return err;
> > + }
> > +
> > + /* Initial port termios */
> > + m
On 11/07/2013 01:33:56 AM, David Laight wrote:
> > Subject: xhci message rate control needed
> >
> > fedora kernel 3.9.10-100.fc17.x86_64
> >
> > xhci_hcd :12:00.0: ERROR Transfer event TRB DMA ptr not part of
> > current TD
> >
> > i got this message about every 200 MICROseconds after a wa
Add the missing C_CMSPAR(tty) macro.
Signed-off-by: Andrew Lunn
---
include/linux/tty.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 64f864651d86..8d1ba896070a 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -137,6 +137,7
This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn
---
v1->v2
Remove debug module parameter.
Add missing \n to dev_dbg() strings.
Consistent dev_d
> Hopefully my comments will suffice as guidance for mxuport, but we could
> iterate the flow-control handling separate from the other changes if you
> want.
Hi Johan
I just posted v5. It would be good if you could take a look at the
flow-control changes first.
Thanks
And
amp;mxport->mutex);
> > +
> > + return err;
> > +}
>
> You should probably use SET_DTR (and rename the function
> mxuport_set_dtr).
I considered mxuport_set_dtr(), but it does not really fit with the
usb-serial naming. tty_port_operations has dtr_rts, not set_dtr_rts.
usb_serial_dr
This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn
---
v1->v2
Remove debug module parameter.
Add missing \n to dev_dbg() strings.
Consistent dev_d
Add the missing C_CMSPAR(tty) macro.
Signed-off-by: Andrew Lunn
---
include/linux/tty.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 64f864651d86..8d1ba896070a 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -137,6 +137,7
Add the missing C_CMSPAR(tty) macro.
Signed-off-by: Andrew Lunn
---
include/linux/tty.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 97d660ed70c1..e53e90ed3f19 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -137,6 +137,7
This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn
---
v1->v2
Remove debug module parameter.
Add missing \n to dev_dbg() strings.
Consistent dev_d
her two are used for. Freeing the buffers does save a
little bit of memory, but i could drop this code block and skip the
memory saved?
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 08, 2013 at 11:00:20PM +0200, Ben Hutchings wrote:
> On Thu, 2013-08-08 at 12:20 +0200, Andrew Lunn wrote:
> > Hi Ben, David
> >
> > Here is a pull request for firmware for Moxa USB-Serial hub devices.
> >
> > Thanks
> > Andrew
>
Andrew
The following changes since commit e7c85b24a5e5107e9911c6b80f536b6bbc5d465d:
moxa: Fix firmware file names. (2013-09-05 13:18:07 +0200)
are available in the git repository at:
g...@github.com:lunn/linux-firmware.git moxa
rsion. If the available
version is newer, it will be download into RAM of the device and
started. This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn
---
Cha
t;port[i];
> > + port->bulk_out_size = buffer_size;
>
> ...and then use
>
> port->bulk_out_size = port0->bulk_out_size
>
> and similar throughout.
So you are assuming the endpoints all have the same buffer size? At
least for the one device i have,
> > least for the one device i have, that is true. But is it guaranteed?
> > What would happen if the event endpoint actually had a smaller size?
>
> No, remember that we're setting up all ports to use the first bulk-out
> endpoint, so the fields can be retrieved from po
rsion. If the available
version is newer, it will be download into RAM of the device and
started. This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn
---
v
On Wed, Oct 09, 2013 at 07:27:42PM +0200, Johan Hovold wrote:
> On Wed, Oct 09, 2013 at 12:57:45PM +0200, Johan Hovold wrote:
> > On Wed, Sep 25, 2013 at 11:53:00AM +0200, Andrew Lunn wrote:
>
> [...]
>
> > > +#define MX_INT_RS232 0
> > > +#d
Based on previous work by Michael Walle and Jason Cooper.
Made their work actually work, which required added interrupt from DT
and auxdata, along with setting the dma_mask, which DT does not
currently do.
Signed-off-by: Andrew Lunn
---
.../devicetree/bindings/usb/ehci-orion.txt | 19
Now that the EHCI driver has DT support, drop old style configuration
of it and add DT in its place. Since all the boards enable the EHCI,
enable it by default in kirkwood.dtsi. Any new boards which don't have
USB can specifically disable it.
Signed-off-by: Andrew Lunn
---
arch/arm/boo
The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0
and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this.
Reported-by: Sebastian Hesselbarth
Signed-off-by: Andrew Lunn
---
drivers/usb/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/Kconfig b
nly mach-orion5x
needs this and nobody has shown any interest in moving mach-orion5x to
DT. So i would just hard code it to "NA".
If anybody does show interest in DT for orion5x, we can add a phy node
under ehci as a pure extension which does not affect backward
compatibility.
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 16 Oct 2012 23:59:41 +0800
Ming Lei wrote:
> This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
> 'struct task_struct'), so that the flag can be set by one task
> to avoid doing I/O inside memory allocation in the task's context.
>
> The patch trys to solve one deadl
On Wed, 17 Oct 2012 09:54:09 +0800
Ming Lei wrote:
> On Wed, Oct 17, 2012 at 4:19 AM, Andrew Morton
> wrote:
> >
> > The patch seems reasonable to me. I'd like to see some examples of
> > these resume-time callsite which are performing the GFP_KERNEL
> > a
and currently converting orion5x to DT is low
priority. Adding a phy node later will also not affect backwards
compatibility.
Andrew Lunn (2):
ARM: Kirkwood: ehci-orion: Add device tree binding
ARM: Kirkwood: Convert all DT boards to EHCI via DT.
.../devicetree/bindings/usb/ehci-orion.
Based on previous work by Michael Walle and Jason Cooper.
Made their work actually work, which required added interrupt from DT
and auxdata, along with setting the dma_mask, which DT does not
currently do.
Signed-off-by: Andrew Lunn
Tested-by: Sebastian Hesselbarth
Acked-by: Alan Stern
Now that the EHCI driver has DT support, drop old style configuration
of it and add DT in its place. Since all the boards enable the EHCI,
enable it by default in kirkwood.dtsi. Any new boards which don't have
USB can specifically disable it.
Signed-off-by: Andrew Lunn
---
arch/arm/boo
I have a Lenovo X220, and d3cold seems to break hotplug on xhci. This
is 3.6.2-4.fc17.x86_64.
The device is:
0e:00.0 USB Controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host
Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
Subsystem: Lenovo Device [17aa:21da]
Control: I/O
On Sat, Oct 27, 2012 at 9:59 PM, Andrew Lutomirski wrote:
> I have a Lenovo X220, and d3cold seems to break hotplug on xhci. This
> is 3.6.2-4.fc17.x86_64.
>
> The device is:
>
> 0e:00.0 USB Controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host
> Controller [1033:0194]
Hi Ben, David
Here is a pull request for firmware for Moxa USB-Serial hub devices.
Thanks
Andrew
The following changes since commit 931e4469dc254df66a2c990ff1a8723685759eb4:
radeon: add ucode for KABINI GPUs (2013-07-28 22:39:47 +0100)
are available in the git repository at
> On Tue, 22 Jan 2008 09:29:27 +0100 Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 22. Januar 2008 00:28:57 schrieb Serge Gavrilov:
> > vuescan D c066ce00 4972 25367 1
> > d8adfdb4 0046 c066ce00 c066ce00 0282 d8adfd94 c046c0f9
> > d878ac80
> > c066ce00
(cc linux-usb)
> On Tue, 15 Jan 2008 13:40:38 -0200 Otavio Salvador <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have the following in my syslog:
>
> Jan 15 13:30:38 neumann kernel: usb 1-2: new full speed USB device using
> uhci_hcd and address 5
> Jan 15 13:30:38 neumann kernel: usb 5-2: new lo
> On Fri, 25 Jan 2008 08:34:00 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9815
>
>Summary: Unable to mount ipod
>Product: Other
>Version: 2.5
> KernelVersion: 2.6.24
> Platform: All
> OS/Version: Linu
> On Fri, 25 Jan 2008 07:16:49 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9813
>
>Summary: usb mouse broken on X20 (intermittent)
>Product: Drivers
>Version: 2.5
> KernelVersion: 2.6.24
> Platform: All
>
On Tue, 5 Feb 2008 10:36:16 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Feb 2008 [EMAIL PROTECTED] wrote:
>
> > From: Andrew Morton <[EMAIL PROTECTED]>
> >
> > drivers/usb/storage/sddr55.c: In function 'sddr55_transport':
On Tue, 5 Feb 2008 22:48:29 +0100
"Oliver Pinter" <[EMAIL PROTECTED]> wrote:
> On 2/5/08, Oliver Pinter <[EMAIL PROTECTED]> wrote:
> > http://students.zipernowsky.hu/~oliverp/kernel/regression_2624/
> >
> > uploaded:
> > kernel image
> > .config
> > new pictures
> > lspci
> > lsusb
> >
> > -
>
On Sat, 9 Feb 2008 18:08:14 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9925
>
>Summary: PROBLEM: Card Reader Detected but won't connect to
> system
>Product: IO/Storage
>Version: 2.5
> KernelVersi
testing
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ing in that doesn't get flushed until a certain number of bytes are sent to
the USB end point? If this is the case, is there an accepted method of fushing
the URB to the USB endpoint?
I'm not too familiar with the USB system of Linux at this point. Trying to
familiarize myself wi
Pete Zaitcev wrote:
On Wed, 13 Feb 2008 13:31:54 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote:
spin_lock_bh(&port->lock);
if (port->write_urb_busy) {
If you lock against callbacks and do not trigger tasklets yourself,
you must use spin_lock_irqsave (or spin_lock_irq i
Andrew McKay wrote:
Pete Zaitcev wrote:
On Wed, 13 Feb 2008 13:31:54 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote:
spin_lock_bh(&port->lock);
if (port->write_urb_busy) {
If you lock against callbacks and do not trigger tasklets yourself,
you must use spin_
Greg KH wrote:
On Wed, Feb 13, 2008 at 01:31:54PM -0600, Andrew McKay wrote:
Hi
For a project I'm working on we had to add GPIO support to the cp2103
driver in the 2.6.20.4 kernel.
Can't you just do this from a usbfs/libusb application from userspace
instead? Why add a custom io
the ftdi part in the design. The problem is
that their parts
aren't rated for industrial temperature range. The cp210x family
however is.
Hardware requirements were more important than software requirements on
that
front. If I had my choice the cp210x parts would never be in any of our
space turn around to provide an accurate timing loop.
What would be the best way to implement a loop to handle flashing the LED in
kernel space. Is this a good task for a kthread? Or is there a simpler
construct to do this with?
Thanks,
Andrew
-
To unsubscribe from this list: sen
On Mon, 11 Feb 2008 12:29:33 -0800
Kevin Lloyd <[EMAIL PROTECTED]> wrote:
> From: Kevin Lloyd <[EMAIL PROTECTED]>
>
> Moves the Onda H600/ZTE MF33 device from the sierra driver to the option
> driver.
>
A changelog should describe why a change was made, not simply what the
change is.
>
> ---
to avoid it and still make sure all relevant people receive
the message.)
On 2/16/2008 10:20 AM, Alan Stern wrote:
On Sat, 16 Feb 2008, Oliver Pinter wrote:
On 2/15/08, Andrew Buehler <[EMAIL PROTECTED]> wrote:
In my workplace, I use a customized version of Novell's ZENworks
imag
On 2/16/2008 6:11 PM, Alan Stern wrote:
On Sat, 16 Feb 2008, Andrew Buehler wrote:
For another, getting two copies of a message is no big deal --
I disagree.
Everyone has his own taste. Obviously there's no world-wide
consensus, possibly because different people have different wor
On 2/17/2008 2:20 AM, Paul Jackson wrote:
Andrew wrote:
(Since there are multiple Andrews on just the LKML, and at least two -
one of whom is much more prominent than I am - in the direct address
list for this discussion, I'm not sure whether or not this is a
sufficient attribution.
On 2/16/2008 10:35 PM, Alan Stern wrote:
On Sat, 16 Feb 2008, Andrew Buehler wrote:
Messages sent to my address directly are explicitly not filtered
into the folders I have set up for various mailing lists, so that
if someone does send me a "heads up" reply for a specific topic on
On 2/16/2008 10:35 PM, Alan Stern wrote:
On Sat, 16 Feb 2008, Andrew Buehler wrote:
Until this thread, I was not even aware that ACPI was related to
USB; I had largely conflated it with a similar acronym which I
think is related to power management and which I can suddenly not
even find in
On Tue, 19 Feb 2008, Andrew Buehler wrote:
With those two problems out of the way, what is left is the
hard-drive issue, and that is also halfway fixed by enabling ACPI.
Specifically, it is "fixed" in that the kernel sees the hard drive
and I can mount it, but it is not fixed in that
On 2/20/2008 12:15 PM, Alan Stern wrote:
On Wed, 20 Feb 2008, Andrew Buehler wrote:
Hmm. One thing which just sprang to mind, in the stab-in-the-dark
category: in 2.6.24.2, launching the program on some machines gave
warnings along the lines of "this program is using a deprecated
On Wed, 20 Feb 2008 09:10:42 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=10051
>
>Summary: Spurious messages at boot, eventually hangs the usb
> subsustem
>Product: Drivers
>Version: 2.5
> KernelVer
On 2/20/2008 2:29 PM, Alan Stern wrote:
On Wed, 20 Feb 2008, Andrew Buehler wrote:
In other words: I don't think that's likely to be practical in the
present instance. If you have reason to believe otherwise (past
positive experience with Novell, for instance), I'd be glad to
On 2/21/2008 12:17 PM, Greg KH wrote:
On Thu, Feb 21, 2008 at 11:36:23AM -0500, Alan Stern wrote:
On Thu, 21 Feb 2008, Andrew Buehler wrote:
[Greg KH]
I know he's in the CC:, but I'm not sure he's reading this
thread, and I'm hesitant to bother people about things out
eing passed a struct ehci_hcd *, but:
811 static int ehci_setup(struct usb_hcd *hcd)
812 {
813 struct ehci_hcd *ehci = hcd_to_ehci(hcd);
814 int retval;
it seems to expect a struct usb_hcd *
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb
add up.
>
> Very good; tomorrow I will send your patch in.
Hi Alan, Soeren
Could you word the description a bit better. If Alan did not get it
without a bit of thought, few others are going to understand it
without a better explanation.
Thanks
Andrew
--
To unsubscribe from this lis
: error: 'struct rts51x_chip' has no
> member named 'us'
>
> chip->us here is only defined when CONFIG_REALTEK_AUTOPM is enabled.
local var `us' doesn't get used by anything and it's unclear why that
patch added it?
From: Andrew Morton
Subject:
These two patches add support for MOXA 12XX/14XX/16XX USB serial
devices. The first patch exports a function from the generic usb
serial driver, which the driver in the second patch would like to use.
Andrew Lunn (2):
USB: Serial: export usb_serial_generic_submit_read_urb()
usb-serial: Moxa
usable within generic functions,
in particular usb_serial_generic_read_bulk_callback().
Export this function so drivers can use it in there own read bulk
callback routine.
Signed-off-by: Andrew Lunn
---
drivers/usb/serial/generic.c |5 +++--
include/linux/usb/serial.h |2 ++
2 files
On Sun, May 26, 2013 at 06:04:24PM +0200, Johan Hovold wrote:
> On Sun, May 26, 2013 at 01:00:51PM +0200, Andrew Lunn wrote:
> > Add a driver which supports the following Moxa USB to serial converters:
> > * 2 ports : UPort 1250, UPort 1250I
> > * 4 ports : U
On Sun, May 26, 2013 at 06:04:24PM +0200, Johan Hovold wrote:
> On Sun, May 26, 2013 at 01:00:51PM +0200, Andrew Lunn wrote:
> > +/*
> > + * mxuport_write_room
> > + *
> > + * Return how much space is available in the buffer.
> > + */
> > +static int mx
On Tue, May 28, 2013 at 11:08:54PM +0200, Johan Hovold wrote:
> On Tue, May 28, 2013 at 09:41:08PM +0200, Andrew Lunn wrote:
> > On Sun, May 26, 2013 at 06:04:24PM +0200, Johan Hovold wrote:
> > > On Sun, May 26, 2013 at 01:00:51PM +0200,
This is optional and the driver appears to work O.K. with
older firmware in the devices ROM.
This driver is based on the MOXA driver and retains MOXAs copyright.
Signed-off-by: Andrew Lunn
---
v1->v2
Remove debug module parameter.
Add missing \n to dev_dbg() strings.
Consistent dev_d
Add the missing C_CMSPAR(tty) macro.
Signed-off-by: Andrew Lunn
---
include/linux/tty.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 97d660ed70c1..e53e90ed3f19 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -137,6 +137,7
> I hope it's OK that I submit the patch with the below changes to Greg
> for inclusion in v3.14. Let me know if you prefer to respin yourself.
Hi Johan
The patch looks good.
Acked-by: Andrew Lunn
> Thanks for all your work with fixing up and mainlining this driver!
And than
On Mon, Dec 09, 2013 at 12:47:52PM +0100, Andrzej Pietrasiewicz wrote:
> With g_ether loaded the sk occasionally becomes 0x.
> It happens usually after transferring few hundreds of kilobytes to few
> tens of megabytes. If sk is 0x then dereferencing it causes
> kernel panic.
Don't
Actually found what looks to be a fix for this in another thread.
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg574770.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
Cheers,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message
On Fri, Jan 24, 2014 at 07:38:31AM -0600, Andrew Ruder wrote:
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg574770.html
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
Just a little further confirmation. This appears in
__inet_lookup_established as the last four instru
On Sat, 3 Nov 2012 16:35:08 +0800
Ming Lei wrote:
> This patchset try to solve one deadlock problem which might be caused
> by memory allocation with block I/O during runtime PM and block device
> error handling path. Traditionly, the problem is addressed by passing
> GFP_NOIO statically to mm,
On Sat, 3 Nov 2012 16:35:09 +0800
Ming Lei wrote:
> This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
> 'struct task_struct'), so that the flag can be set by one task
> to avoid doing I/O inside memory allocation in the task's context.
>
> The patch trys to solve one deadl
On Sat, 3 Nov 2012 16:35:10 +0800
Ming Lei wrote:
> The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
> to help PM core to teach mm not allocating memory with GFP_KERNEL
> flag for avoiding probable deadlock.
>
> As explained in the comment, any GFP_KERNEL allocation inside
On Sat, 3 Nov 2012 16:35:11 +0800
Ming Lei wrote:
> This patch applyes the introduced pm_runtime_set_memalloc_noio on
> block device so that PM core will teach mm to not allocate memory with
> GFP_IOFS when calling the runtime_resume and runtime_suspend callback
> for block devices and its ances
On Wed, 7 Nov 2012 11:11:24 +0800 Ming Lei wrote:
> On Wed, Nov 7, 2012 at 7:23 AM, Andrew Morton
> wrote:
> >
> > It's unclear from the description why we're also clearing __GFP_FS in
> > this situation.
> >
> > If we can avoid doing this then
hi,
> Yes, during previous attempt to remove the files, Andrew said that it
> was used internally in his former company. I had no serious reason to
> remove it, so we kept it back then.
> But now it seems the situation has evolved and we must consider the move
> to a single kerne
demonstrate
> how to use the introduced mechanism to fix the deadlock problem.
>
> Andrew, could you queue these patches into your tree since V6 fixes all
> your concerns and looks no one objects these patches?
Yes, this patchset looks ready to run with. But as we're at -rc7 I&#
On Tue, Dec 11, 2012 at 6:32 PM, Huang Ying wrote:
> On Fri, 2012-12-07 at 22:00 +0100, Rafael J. Wysocki wrote:
>> On Thursday, December 06, 2012 04:28:08 PM Sarah Sharp wrote:
>> > On Thu, Dec 06, 2012 at 01:43:32AM +0100, Rafael J. Wysocki wrote:
>> > > On Wednesday, December 05, 2012 04:33:44
On Sat, 5 Jan 2013 10:25:38 +0800
Ming Lei wrote:
> This patchset try to solve one deadlock problem which might be caused
> by memory allocation with block I/O during runtime PM and block device
> error handling path. Traditionly, the problem is addressed by passing
> GFP_NOIO statically to mm,
On Thu, 17 Jan 2013 09:28:14 +0800
Ming Lei wrote:
> > If so, I wonder if we could avoid the whole problem by appropriately
> > syncing all dirty memory back to storage before starting to turn devices
> > off?
>
> The patchset is to address the probable deadlock problem by GFP_KERNEL
> during ru
a race condition caused by
not stopping the dedicated endpoint for bulk packets before
rotating its queue which allowed a packet to be recieved and then
thrown away.
V2 added a comment and removed debugging code
Andrew Goodbody (2):
usb: musb: Ensure rx reinit occurs for shared_fifo endpoints
from musb_rx_reinit before it was thrown away.
The data thrown away was a valid packet that had been correctly
ACKed which meant the host and device got out of sync.
Signed-off-by: Andrew Goodbody
Cc: sta...@vger.kernel.org
---
V2 added comment about clearing REQPKT before DATAERR_NAKTIMEOUT
shared_fifo endpoints would only get a previous tx state cleared
out, the rx state was only cleared for non shared_fifo endpoints
Change this so that the rx state is cleared for all endpoints.
This addresses an issue that resulted in rx packets being dropped
silently.
Signed-off-by: Andrew
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
>
> Hello.
>
> On 5/23/2016 3:00 PM, Andrew Goodbody wrote:
>
> > Ensure that the endpoint is stopped by clearing REQPKT before clearing
> > DATAERR_NAKTIMEOUT before rotating the queue on t
own away.
> >>>> The data thrown away was a valid packet that had been correctly
> >>>> ACKed which meant the host and device got out of sync.
> >>>>
> >>>> Signed-off-by: Andrew Goodbody
>
> >>>> Cc: sta...@vger.kernel.org
a race condition caused by
not stopping the dedicated endpoint for bulk packets before
rotating its queue which allowed a packet to be recieved and then
thrown away.
V3 Updated the comment to better reference the manual
V2 added a comment and removed debugging code
Andrew Goodbody (2):
usb: musb
shared_fifo endpoints would only get a previous tx state cleared
out, the rx state was only cleared for non shared_fifo endpoints
Change this so that the rx state is cleared for all endpoints.
This addresses an issue that resulted in rx packets being dropped
silently.
Signed-off-by: Andrew
from musb_rx_reinit before it was thrown away.
The data thrown away was a valid packet that had been correctly
ACKed which meant the host and device got out of sync.
Signed-off-by: Andrew Goodbody
Cc: sta...@vger.kernel.org
---
V3 removed the old comment, moved the new comment in place of the old one
dapters"
> select MII
> + depends on ACPI
Hi Mario
That seems a bit heavy handed. What about ARM or MIPS machines which
don't use ACPI but do have USB ports where i could plug in a USB
dongle with this chipset.
I think it would be better to make use of ACPI if it is ava
1 - 100 of 437 matches
Mail list logo
