Re: ehci frame index goes backwards?

on the value of the Frame List Size field in the USBCMD register. 10, 11 or 12 bits is the N size. This becomes the SOF number. It does wrap, maybe you are seeing a reading after a wrap? Regards, Steve > ehci_read_frame_index(ehci)=12318 > [ 25.576523] ehci-pci :00:0a.1: iso_stream_

usbfs zerocopy broken on ARM/ARM64

6 >From what I read so far I got the impression that the 'proper' way would be to use dma_mmap_coherent() with dma_addr instead of remap_pfn_range(), however, I did not get it to work. Can anyone help out? Best Regards, Steve Markgraf

Re: [PATCH v3] smsc95xx: Add comments to the registers definition

river > programming through those devices can only rely on the Linux kernel > driver source to make their own. > > This commit adds a lot of comments to the registers definition to expand > the register names. > > Cc: Steve Glendinning <steve.glendinn...@shawell.net> >

Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access

and racy. So all DMA buffers should always be separate allocations from the stack AND not be embedded in structs. Memory allocations are always at least cache line aligned, so coherency is not a problem. Regards, Steve -- 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

Re: [PATCH] cifs: Fix smbencrypt() to stop pointing a scatterlist at the stack

, , 8, NULL); >> - >> - rc = crypto_skcipher_encrypt(req); >> - if (rc) >> - cifs_dbg(VFS, "could not encrypt crypt key rc: %d\n", rc); >> - >> - skcipher_request_free(req); >> - >> -smbhash_free_skcipher: >> - cry

Re: TCPCI driver issue

in a Type-C dock ? It converts HDMI (native to the SoC) to DisplayPort rather than the other way around as you'd need in a dock. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majo

Re: TCPCI driver issue

). I would be interested in seeing the test driver, either on the list or privately if you are not comfortable with a general release. I'm currently working on support for the Analogix AN7688. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linu

Re: question on trust in chaoskey

PIC, Arduino, or $9 CHIP. Who could tell a key is false or genuine? The false device could do the same dance with public keys (or whatever secret handshake you setup). If a user cannot be sure a key is genuine, and a false key can leak information, I don't see the point of anyone using such a USB

Re: [RFC] Create an audit record of USB specific details

hing is impacting the audit trail. -Steve -- 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

Re: [RFC] Create an audit record of USB specific details

ou can replace spaces with an underscore or dash for readability. So, manufacturer and product would need this treatment. -Steve > Admittedly this is only the USB device type at the moment, but I'd like to > break this out into other bus types at some time in the future, gotta start > so

Re: [RFC] Create an audit record of USB specific details

t when a uevent gets dropped? I may have to panic the machine if that happens depending on the configured policy. So, we need to know when it happens. If on the otherhand it doesn't ever drop events, then it might be usable. -Steve -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

er received data into your enlarged ep buffer, will you not copy it into your midi buffer? If the code checks, I guess you will truncate the received data? If not, it could be a midi buffer overrun. Regards, Steve -- 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

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

t;out_ep, midi->buflen); > + midi_alloc_ep_req(midi->out_ep, > + max_t(unsigned, midi->buflen, > + bulk_out_desc.wMaxPacketSize)); > if (req == NULL) >

Re: [PATCH BACKPORT] xhci:_don't_finish_a_TD_if_we_get_a_short_transfer_event_mid_TD

On Sun, 2016-02-14 at 14:15 -0800, Greg KH wrote: > On Wed, Dec 16, 2015 at 06:22:30AM -0800, Steve Bangert wrote: > > Hi, > > > > This original patch was posted and applied to the 4.3-rcX kernel > > and tagged for > > stable kernels. > > > > ht

Re: xHCI driver issue (ASMedia Controller using xhci_hcd)

In my case, my scanner problem has been fixed (so far) by tuning off autosuspend: # echo -1 >/sys/module/usbcore/parameters/autosuspend -- 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

Re: xHCI driver issue (ASMedia Controller using xhci_hcd)

I've been trying to get my scanner working on my newer laptop (entire Linux installation, apart from the kernel (4.2.5) cloned from the old one) and I seem to be seeing the same issue, although I have no problem with USB storage or HID devices on the USB 3 port. Here's a clip from the debug with

Re: xHCI driver issue (ASMedia Controller using xhci_hcd)

Oliver Neukum writes: > > # echo -1 >/sys/module/usbcore/parameters/autosuspend > > Did you see any other device failing or is it specific > to your scanner? > > Regards > Oliver > All other devices I own have worked as expected: mouse, keyboard, storage

[PATCH BACKPORT] xhci:_don't_finish_a_TD_if_we_get_a_short_transfer_event_mid_TD

the 3.2.73-rc1 review cycle and will now apply. Please consider for the next stable kernel release cycle. Steve Bangert From: Mathias Nyman <mathias.ny...@linux.intel.com> commit e210c422b6fdd2dc123bedc588f399aefd8bf9de upstream. If the difference is big enough between the bytes

Re: First kernel patch (optimization)

f wimpy compiler optimizer will not move the constant initializer out of the loop? I bet if you compare binary sizes/code it will be exactly the same, and you added some characters of code. Reorganizing code for readability is fine, but for compiler (in)efficiency seems like a bad idea. Regards, S

Re: About zero-length packet design for EHCI

trace between windows and your gadget, then you can see what those guys think the rules for your protocol are. Regards, Steve -- 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

Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller

On Mon, Jun 29, 2015 at 7:16 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 29 Jun 2015, Peter Chen wrote: Just like Steve pointed, it should be a ZLT problem, do you have below patch in your tree, and the host may not send zlt, but you may queue an zero-length request, the f_hid

Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller

is determined by the report size in the HID descriptor. Good Luck, Steve -- 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

Re: [PATCH v2 11/11] usbip: USB over WebSocket

If you are looking for a good C websockets library, gpl etc try: https://libwebsockets.org/trac/libwebsockets I used it in a project and was very pleased with how it worked and the support where it is hosted. Regards, Steve On Wed, Apr 22, 2015 at 11:52 PM, fx IWATA NOBUO nobuo.iw

Re: Unable to access USB mass storage device with xhci. okay with ehci

On Thu, 2015-04-16 at 13:49 +0200, Hans de Goede wrote: Hi, On 09-04-15 20:30, Steve Bangert wrote: On Thu, 2015-04-09 at 16:49 +0200, Hans de Goede wrote: Hi, On 09-04-15 15:27, Steve Bangert wrote: On Wed, 2015-04-08 at 10:56 -0400, Alan Stern wrote: On Wed, 8 Apr 2015, Steve

Re: [PATCH 1/3] uas: Allow uas_use_uas_driver to return usb-storage flags

the detected flags, and use this in the uas driver. Signed-off-by: Hans de Goede hdego...@redhat.com Patched (all 3 of them) and compile tested on the current Fedora kernel (3.19.3-200), device is accessible and functioning without a kernel parameter Steve --- drivers/usb/storage/uas-detect.h | 6

Re: Unable to access USB mass storage device with xhci. okay with ehci

On Thu, 2015-04-09 at 16:49 +0200, Hans de Goede wrote: Hi, On 09-04-15 15:27, Steve Bangert wrote: On Wed, 2015-04-08 at 10:56 -0400, Alan Stern wrote: On Wed, 8 Apr 2015, Steve Bangert wrote: What i did was not correct, usb-storage.quirks=174c:55aa:u was added to /etc/default/grub

Re: Unable to access USB mass storage device with xhci. okay with ehci

. What exactly do you mean with i now have access to the drive using xhci and uas ? Do you mean that everything works correctly with xhci + uas when setting .max_sectors = 240 ? Yes, that's what Steve meant. Without the .max_sectors = 240 restriction, the device froze up when the kernel

Re: Unable to access USB mass storage device with xhci. okay with ehci

the EHCI and xHCI-with-a-USB-2-cable traces.) Perhaps this drive needs some sort of max_sectors restriction. Alan Stern Okay, is there a patch i can try? Thanks for your help with this. Steve -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message

Re: Unable to access USB mass storage device with xhci. okay with ehci

On Sun, 2015-04-05 at 10:31 -0400, Alan Stern wrote: On Sun, 5 Apr 2015, Steve Bangert wrote: On Sat, 2015-04-04 at 15:48 -0400, Alan Stern wrote: Is that really all? Was there a UAS is blacklisted for this device line in the kernel log? It looks like the usb-storage driver

Unable to access USB mass storage device with xhci. okay with ehci

Alan or Mathias, Machine is a 64 bit Dell Inspiron with Intel chips running Fedora 3.19.3 kernel Disabling the uas driver is no help. Any help is appreciated. Steve lspci -v 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) (prog-if 30 [XHCI

Re: XHCI, brain-dead scanner, and microframe rounding

flawlessly. Pete -- 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 I have the same experience steve -- To unsubscribe from this list: send the line

Re: XHCI, brain-dead scanner, and microframe rounding

a bug on bugs.launchpad.net on kernel 3.18 04c5:11fc [System76 gazp9b] Excuting scanimage -L finds Fujitsu 6110 Scanner but if repeated does not with url https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402335 -steve -- To unsubscribe from this list: send the line unsubscribe linux-usb

[no subject]

1) Summary pasted summary: scanimage -L finds fitjitsu 04c5:11fc but if repeated does not find it + 04c5:11fc [System76 gazp9b] Excuting scanimage -L finds Fujitsu 6110 + Scanner but if repeated does not 2) full description: i plug a fitjitsu 04c5:11fc into a usb2.0 plug lsusb shows the

Re: [PATCH] usb: core: allow zero packet flag for interrupt urbs

probably no one has built an actual hardware device for consumers that uses multi-interrupt xfers up to now. Regards, Steve -- 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

Re: [PATCH] usb: core: allow zero packet flag for interrupt urbs

On Thu, Jul 17, 2014 at 12:32 PM, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 17 Jul 2014, Steve Calfee wrote: Hi Alan, I did some testing with multi interrupt transfers some time ago. You can get allocated a guaranteed 3x1024 time slot per uframe for an interval of your choice

Re: disable VBUS?

, problems will ensue. Steve On Mon, Jul 7, 2014 at 6:00 PM, Grant emailgr...@gmail.com wrote: it isn't possible to disable Vbus on a USB host port and still use the port. To do what you want, you would have to physically cut the Vbus wire in the USB cable and splice the device side of that wire

Re: Buffer I/O error after s2ram with usb storage persistance

in to the original before resuming from s2ram. For example, suspending a laptop, forgetting that the key is mounted, and using it to transfer files from the desktop. However, I haven't tested either of these scenarios. Steve -- To unsubscribe from this list: send the line unsubscribe linux-usb

Re: [PATCH v2] xhci: Allocate the td array and urb_priv together.

aligned does it? Arm and Mips systems don't like having two i/o actions or cpu and i/o activity on data sharing a cache line. Regards, Steve -- 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

Re: [PATCH 3/9] ARM: fix ohci-pxa27x build error with OF enabled

+0100 Commit: Greg Kroah-Hartman gre...@linuxfoundation.org CommitDate: Wed Dec 4 16:57:46 2013 -0800 Cheers, Steve -- 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

Re: [PATCH RESEND] dma: cppi41: only allocate descriptor memory once

On Wed, Dec 04, 2013 at 11:21 +0100, Daniel Mack wrote: While at it, remove the intermediate variable mem_decs (I guess it was only there to make the code comply to the 80-chars CodingSytle rule). purge_descs() still has a (now unused) mem_decs intermediate variable. Regards, Steve

Re: [BUG] ohci-pci: devices not detected after hibernate

On Tue, Aug 20, 2013 at 03:43:28PM -0400, Alan Stern wrote: On Tue, 20 Aug 2013, Steve Cotton wrote: Once my PC has been hibernated and resumed, some devices plugged in to the on-motherboard ports stop working, and don't show up in lsusb. The pattern seems to be that ports with USB 1.1

[BUG] ohci-pci: devices not detected after hibernate

Last working release: 3.10 Bisected earliest broken: c1117afb85 Broken in: 3.11-rc1, 3.11-rc6, bd479f2933 (the current usb-next) Once my PC has been hibernated and resumed, some devices plugged in to the on-motherboard ports stop working, and don't show up in lsusb. The pattern seems to be that

[PATCH] usb: serial: Add Rigblaster Advantage to device table

The Rigblaster Advantage is an amateur radio interface sold by West Mountain Radio. It contains a cp210x serial interface but the device ID is not in the driver. Signed-off-by: Steve Conklin sconk...@canonical.com --- drivers/usb/serial/cp210x.c |1 + 1 file changed, 1 insertion(+) diff

[PATCH v2] usb: serial: Add Rigblaster Advantage to device table

The Rigblaster Advantage is an amateur radio interface sold by West Mountain Radio. It contains a cp210x serial interface but the device ID is not in the driver. Signed-off-by: Steve Conklin sconk...@canonical.com --- drivers/usb/serial/cp210x.c |1 + 1 file changed, 1 insertion(+) diff

Re: Device configuration fails on superspeed, succeeds on highspeed

, or that interfaces have sequentially numbered endpoints. Regards, Steve -- 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

Re: Device configuration fails on superspeed, succeeds on highspeed

On Mon, Dec 17, 2012 at 11:08 AM, Steve Calfee stevecal...@gmail.com wrote: On Mon, Dec 17, 2012 at 7:33 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 16 Dec 2012, Vincent Pelletier wrote: Le dimanche 16 décembre 2012 20:46:38, Vincent Pelletier a écrit : I checked the specs

Re: [PATCHv2][RFC] smsc95xx: enable dynamic autosuspend

On 11 December 2012 16:13, Ming Lei ming@canonical.com wrote: On Tue, Dec 11, 2012 at 11:26 PM, Steve Glendinning steve.glendinn...@shawell.net wrote: + + if (on) + usb_autopm_get_interface_no_resume(dev-intf); + else

Re: [PATCHv2][RFC] smsc95xx: enable dynamic autosuspend

On 11 December 2012 16:27, Joe Perches j...@perches.com wrote: On Tue, 2012-12-11 at 15:26 +, Steve Glendinning wrote: [] diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c [] + ret = smsc95xx_read_reg_nopm(dev, RX_FIFO_INF, val); + if (ret 0

Re: [PATCH][RFC] smsc95xx: enable dynamic autosuspend (RFC)

LAN95xx devices. Steve, correct me if I am wrong. All parts support SUSPEND1, but some parts can't 100% reliably wake on ENERGYON - some link partners will wake them but others won't. The driver already detects parts that work reliably with all link partners and sets the FEATURE_PHY_NLP_CROSSOVER

[PATCHv2][RFC] smsc95xx: enable dynamic autosuspend

This patch enables USB dynamic autosuspend for LAN9500A. This saves very little power in itself, but it allows power saving in upstream hubs/hosts. The earlier devices in this family (LAN9500/9512/9514) do not support this feature. Signed-off-by: Steve Glendinning steve.glendinn...@shawell.net

Re: usb bus monitoring

Hi Tilman, Another option is to find and use fx2lib. It includes fx1 based stuff and should give you some ideas on how to at least make something work. It uses the open source SDCC compiler, so if you are using something else some of the syntax is different. Regards, Steve On Tue, Dec 11, 2012

[PATCH][RFC] smsc95xx: enable dynamic autosuspend (RFC)

autosuspend from the USB VID/PID if this would help. UPDATE: reposting this to a wider audience due to lack of feedback last time round Signed-off-by: Steve Glendinning steve.glendinn...@shawell.net --- drivers/net/usb/smsc95xx.c | 136 +++- 1 file changed, 135

Re: [PATCH][RFC] smsc95xx: enable dynamic autosuspend (RFC)

On 10 December 2012 12:09, Oliver Neukum oli...@neukum.org wrote: So this is a problem with remote wakeup on older hardware? Exactly, the older hardware revisions can't reliably do it. Unfortunately we don't know if the connected device supports this feature until we query its ID register at

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

Hi Alan, udev-do_remote_wakeup is set in choose_wakeup() in drivers/usb/core/driver.c. AFAICS it is always set as long as device_may_wakeup(udev-dev) is true. That's right. But is device_may_wakeup(udev-dev) true? By default it wouldn't be. The normal way to set it is for the user or a

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

, * possibly network interfaces, etc. Steve -- 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

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

Looking at the different ethernet drivers, the normal way do do this seems to be something like this in their .set_wol implementation: device_set_wakeup_enable(adapter-pdev-dev, adapter-wol); where adapter is a netdev_priv private struct, pdev is a pci device and wol is an u32. I

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

+ + ret = device_set_wakeup_enable(net-dev, pdata-wolopts); You are touching the network device here. That should have been the USB device. Try something like ret = device_set_wakeup_enable(dev-udev-dev, pdata-wolopts); Perfect, this works exactly as expected now. Patch included in

Re: [PATCH 1/2] smsc75xx: refactor entering suspend modes

Hi Bjorn, On 27 November 2012 17:21, Steve Glendinning st...@shawell.net wrote: Hi Bjorn, + smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP); As mentioned in another comment to the smsc95xx driver: This is weird. Do you really need to do that? This is an USB interface driver

Re: [PATCH 089/128] USB: at91_udc uses generic GPIO calls; minor cleanup

directly. Unfortunately.. the transistor should have been 'NPN' rather than the 'PNP' they used. But we do at least now have a system to allow manufacturing production variation . Thanks again goes to David B., for incorporating this change, so rapidly. Steve On Feb 2, 2008, at 7:18 AM

Re: [patch 2.6.24-rc6-git] usb: at91_udc uses generic GPIO calls; minor cleanup

:0x0525 Which would indicate it's working (at least for my reversed logic YL-9200 board.) Steve On Jan 6, 2008, at 5:21 AM, David Brownell wrote: From: David Brownell [EMAIL PROTECTED] Various small at91_udc cleanups: - Use generic GPIO calls, not older platform-specific ones - Use

Re: [patch 2.6.24-rc6-git] usb: at91_udc uses generic GPIO calls; minor cleanup

That's great David, I've just move forward to rc6 ,GOD what a fiasco that was. I'm showing a kernel panic in the Amtel_spi code (i thought we finished with that damned thing), which I have disabled for now. But let me apply this patch and see how it goes. Steve On Jan 6, 2008, at 5

Re: [patch 1/1] at91_udc modification for systems that require active low on i/o pin to take D+ high

to notice two small glitches in the cleanup code of that previous patch, so I may instead just merge this into an updated version of that patch. That would be great and I would really appreciate it. Steve - Dave [1] http://marc.info/?l=linux-usbm=119878579910739w=2 === CUT HERE Add