Steinar H. Gunderson wrote:
> > Our interface for zero copy reads/writes is O_DIRECT, and that requires
> > not special memory allocation, just proper alignment.
>
> But that assumes you are using I/O using read()/write(). There's no way you
> can shoehorn USB isochronous reads into the read() int
WEN Pingbo wrote:
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
> /* there are both host and device side versions of this call ... */
> static int dummy_g_get_frame(struct usb_gadget *_gadget)
> {
> - struct timeval tv;
>
Johan Hovold wrote:
> > I started in the morning to build the driver from the source provided
> > by the vendor, but it was written in the times of kernel-version 2.4,
> > and I got hopelessly stuck.
>
> The vendor driver is only for 2.4? Peter?
http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
Johan Hovold wrote:
> On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote:
..
> > garbage characters transmitted from embedded-device
..
> > It seems that there is some issue with the driver.
>
> Why do think it's a driver issue?
I can confirm similar issues with the in-tree driver and my h
Sven Brauch wrote:
> I don't make any other changes to the default settings. To be honest,
> I'm not sure in which mode it is operating then (I was assuming raw, but
> I might be wrong?).
You should explicitly set a mode if you need a particular mode,
otherwise the port might be in another mode. T
Mathias Nyman wrote:
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -82,7 +82,7 @@ dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg,
> return 0;
> /* offset in TRBs */
> segment_offset = trb - seg->trbs;
> - if (segment_offset > TRBS_PER_SEGMENT)
> + i
Stefan Agner wrote:
> libftdi requires to detach the kernel driver to get access to the device
Control transfers ought to be possible without a detach.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
Juergen Gross wrote:
> Do you have another feeling about the probability of a need to do usb 3?
> If it is already on the horizon I wouldn't want to do the user space
> backend now and the kernel one next year. :-)
One year is pretty long in kernel time.
//Peter
--
To unsubscribe from this list:
Mark Glover wrote:
> From: Mark Glover
>
> Signed-off-by: Mark Glover
There's an extraneous leading whitespace on the Signed-off-by line.
> +#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Apadter */
The typo remains. "Apadter" here ^
//Peter
-
Please update your commit message to leave one blank line between the
commit message summary and the rest of the message. (This avoids your
signed-off-by ending up in the email subject.)
Mark Glover wrote:
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
..
> +#define CHETCO_SEAGAUGE_PID 0xA548
Linus Torvalds wrote:
> I seem to get this problem possibly more commonly at boot these days:
> usb 1-6: device descriptor read/64, error -71
> xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1.
> usb 1-6: hub failed to enable device, error -22
Since my upgrade to 98e8d2e0
Felipe Balbi wrote:
> > > A babble only occurs when
> > > the device side tries to move data without the host asking for anything.
> >
> > It also occurs if the device moves more than packet_size bytes. Not
> > really helping, I know…
>
> hmm, why would the device move more than wMaxPacketSize at
Alan Stern wrote:
> > > Also, many host controllers cannot handle arbitrary alignment.
> > > It would be best to require that the buffer start at a page boundary.
> >
> > This requires a bit of negotiation with userspace, maybe per-URB but
>
> I don't follow. What negotiation is needed? All t
Thank you very much for working on this, Stefan.
Alan Stern wrote:
> Also, many host controllers cannot handle arbitrary alignment.
> It would be best to require that the buffer start at a page boundary.
This requires a bit of negotiation with userspace, maybe per-URB but
it seems better to neg
Philipp Hachtmann wrote:
> This patch adds a sysfs attribute "cbus" which allows to set the
> four CBUS pins on the FT232H.
I think this should be implemented with the gpio subsystem instead.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
Michal Nazarewicz wrote:
> + wcn36xx_err("Run out of memory while hnadling SMD_EVENT
> (%d)\n",
> + msg_header->msg_type);
Typo hnadling.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
Are you changing the code to have HOTPLUG always -on- or -off- ?
From the commit message I had expected always -on-.
Stephen Rothwell wrote:
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -68,14 +68,6 @@
> * are handled as text/data or they can be disc
0
> Subject: [PATCH] usbdevfs: Fix broken scatter-gather transfer
>
> The recently introduced handling of large bulk transfers is completely
> broken; the same user page is read over and over again. Fixed with
> this patch.
>
> Cc: sta...@kernel.org
> Signed-off-by: Henrik
Xiaofan Chen wrote:
> On Thu, Oct 11, 2012 at 2:50 PM, Peter Stuge wrote:
> > But it isn't certain that is is involved at all. If your impact
> > version uses libusb.so like in ISE 11.1 then it will not be. One way
> > to test is by trying to generate a libus
Henrik Rydberg wrote:
> > What is the programming cable and software that uses it?
>
> The programmer is impact, using libusbx-1.0.14-1.
Do you know for a fact that your version calls libusb-1.0? Did you
establish this with e.g. strace? ISE 11.1 impact uses only libusb.so,
ie. libusb-0.1.
Depend
Hej Henrik,
Henrik Rydberg wrote:
> commit 3d97ff63f8997761f12c8fbe8082996c6eeaba1a
> Author: Hans de Goede
> Date: Wed Jul 4 09:18:03 2012 +0200
>
> usbdevfs: Use scatter-gather lists for large bulk transfers
>
> breaks an usb programming cable over here. The problem is reported as
>
Rene Buergel wrote:
> - renamed CONFIG_USB_EZUSB to CONFIG_USB_EZUSB_FX2 to avoid build errors
Is this really the reason for the build error? I doubt it.
Also, does the code in fact support only FX2, neither older chips nor
newer FX3?
> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/K
Alexis R. Cortes wrote:
> This patch is intended to work around a known issue on the
> SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
> between a device and the host past the usual handshake timeout,
> and if that happens on the first insertion, the host controller
> port will enter
Hi Alexis,
Did you run the patch through checkpatch.pl before submitting it?
I think you will get a bunch of important and completely automatic
feedback when you do that. Please fix everything that the script
mentions.
Alexis R. Cortes wrote:
> This patch is intended to work around a known issu
On Fri, Jan 11, 2008 at 12:42:40PM +0900, Paul Mundt wrote:
> How about throwing out hand-rolled debug printk wrappers for the
> brain-damage they are and using the ones the kernel provides
> instead?
Sounds great!
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Thu, Jan 10, 2008 at 10:03:58PM +0100, Roel Kluin wrote:
> -#define DEBUG(x,args...) printk(__FUNCTION__ ": " x,##args)
> +#define DEBUG(x, args...)printk("%s: ", __func__, x, ##args)
Can this really be expected to work when x contains conversions?
How about:
#define DEBUG(x, args...)
Please stop cross-posting this thread at least to linux-pcmcia
until your post is relevant to PCMCIA.
Sorry for being a bore. (Not that I don't love reading LKML
discussions, but I found that it took too much time, and now
they're over at linux-pcmcia too! :)
Thank you in advance.
//Peter
-
To
On Mon, Aug 13, 2007 at 10:09:46AM -0600, Bjorn Helgaas wrote:
> > [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8
>
> As of 2.6.23-rc2, we should have:
> - probes for 8250 legacy devices (as in 2.6.21 and previous)
> - smsc PNP probes turned off by default (2.6.21 and previous h
CE_PROD_ID12("WEIDA", "TWTTI", 0xcc7cf69c, 0x212bb918),
> _
>
>
> Is this really supposed to add a TS2GCF120 entry with the same IDs
> as TS4GCF120?
That's probably a copy and paste error. 0x969aa4f2 is the correct ID.
> And pata_pcmcia-recognize-2gb-compactfl
On Wed, Apr 25, 2007 at 11:27:09AM +0200, Aeschbacher, Fabrice wrote:
> I'm not sure which correct values must be assigned to the 3th and
> 4th parameters (here: 0x709b1bf1, 0xf54a91c8). Anyway, the patch is
> working with these values. Tested on arch=mips.
>
> + PCMCIA_DEVICE_PROD_ID12("TRA
On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote:
> It works in LinuxBIOS now.
Cool, can't wait to try it out.
Good work!
//Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote:
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 06, 2006 12:59 PM
>
> >I haven't looked how the other usb_debug works -- if it's polled
> >too then it wouldn't have much advantage.
>
On Fri, Dec 01, 2006 at 04:02:03PM -0700, Eric W. Biederman wrote:
> >> Sure, I will send it out shortly. I currently have a working
> >> user space libusb thing (easy, but useful for my debug)
> >
> > Hm - for driving which end?
>
> Either. The specific device we are talking about doesn't care.
On Fri, Dec 01, 2006 at 02:15:24PM -0700, Eric W. Biederman wrote:
> Right. For LinuxBIOS not a problem for earlyprintk in the kernel
> somethings might need to be refactored. The challenge in the
> kernel is we don't know at build to how to do a pci_read_config...
>
> The other hard part early
On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote:
> Well, earlyprintk will not work, as you need PCI up and running.
Not all of it though. LinuxBIOS will probably do just enough PCI
setup to talk to the EHCI controller and use the debug port _very_
soon after power on.
> And I have some c
On Fri, Dec 01, 2006 at 10:41:23AM -0800, Greg KH wrote:
> On Fri, Dec 01, 2006 at 10:26:19AM -0800, Lu, Yinghai wrote:
> > Anyone is working on creating one usb_serial_driver for USB debug
> > device without using host debug port?
>
> I can do that in about 15 minutes if you give me the device id
36 matches
Mail list logo
