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_
56
>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
gh 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
> Cc: Microchip Linux Driver Support
> CC: David Miller
>
rs 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
to_skcipher_encrypt(req);
>> - if (rc)
>> - cifs_dbg(VFS, "could not encrypt crypt key rc: %d\n", rc);
>> -
>> - skcipher_request_free(req);
>> -
>> -smbhash_free_skcipher:
>> - crypto_free_skcipher(tfm_des);
>> -smbhash_err:
>> - return rc;
>> + return 0;
>> }
>>
>> static int
>
> Acked-by: Jeff Layton
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
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
used 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.o
ctly into the Type-C infrastructure).
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
ey 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 device.
Regards, Steve
--
To unsubscr
anything 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
string. You 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,
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 linux-usb" in
not the most clear indentation but I had to break it in
> order to avoid passing 80 columns.
>
Yes, I understood that code. It is a little confusing that gadgets use
OUT endpoints to receive data.
I think we are talking about different buffers. I meant that if you
ever received data in
>buflen);
> + midi_alloc_ep_req(midi->out_ep,
> + max_t(unsigned, midi->buflen,
> + bulk_out_desc.wMaxPacketSize));
> if (req == NULL)
> return -ENOMEM;
>
Won't you get a buffer ove
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.
> >
> > http:/
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
(memory card, hard
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 http://vger
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 S
tchings was posted during 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
commit e210c422b6fdd2dc123bedc588f399aefd8bf9de upstream.
If the difference is big enough between the bytes asked and received
in
r 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, Steve
--
To unsubscribe from this list: send the line "
sent and received with NO ZLT. For example USB mass
storage sends multiples of maxpacketsize but does not send ZLTs.
If you do an analyzer 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
On Mon, Jun 29, 2015 at 7:16 AM, Alan Stern 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, th
ze. I believe for HID the packet size 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
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
wrote:
> Hi Bj
urn
> the detected flags, and use this in the uas driver.
>
> Signed-off-by: Hans de Goede
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/
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
drive using xhci and uas. usbmon trace is
> > > attached.
> >
> > 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 = 2
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
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"
> &
96608-byte transfer has to be aborted after 30
> seconds, and only 65536 bytes were received. (Note that 122880-byte
> transfers succeeded in both the EHCI and xHCI-with-a-USB-2-cable
> traces.)
>
> Perhaps this drive needs some sort of max_sectors restriction.
>
>
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
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 "u
ite the code.
I filed 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 &
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 equip
On Thu, Jul 17, 2014 at 12:32 PM, Alan Stern 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
>> in
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/majordomo-info.html
, problems will ensue.
Steve
On Mon, Jul 7, 2014 at 6:00 PM, Grant 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 s
in to another machine, and then put back 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
coherent
systems? You are smashing two memory allocations into one. This does
not insure that the memory in each allocation is cache line 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 unsub
ot in the linux-next/stable or gregkh/usb/usb-next trees.
It adds that include 3 lines higher up, to keep the includes in
alphabetical order.
commit 9876388edfa553960815110acae4544359b385b5
Author: Daniel Mack
AuthorDate: Fri Nov 15 14:19:02 2013 +0100
Commit: Greg Kroah-Hartman
Com
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
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 patter
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 p
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
---
drivers/usb/serial/cp210x.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb
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
---
drivers/usb/serial/cp210x.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb
On Mon, Dec 17, 2012 at 11:08 AM, Steve Calfee wrote:
> On Mon, Dec 17, 2012 at 7:33 AM, Alan Stern 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, a
int/iso endpoint or just not used - all specified in the
device/interface descriptors. Nothing in the USB spec requires all
device endpoints to be used, 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
On 11 December 2012 16:27, Joe Perches wrote:
> On Tue, 2012-12-11 at 15:26 +0000, 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)
On 11 December 2012 16:13, Ming Lei wrote:
> On Tue, Dec 11, 2012 at 11:26 PM, Steve Glendinning
> wrote:
>> +
>> + if (on)
>> + usb_autopm_get_interface_no_resume(dev->intf);
>> + else
>> + usb_autopm_put_interfa
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
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
---
drivers/net/usb
On 11 December 2012 12:53, Ming Lei wrote:
> On Tue, Dec 11, 2012 at 6:27 PM, Oliver Neukum wrote:
>> So they can autosuspend if the interface is up and no cable is plugged
>> in?
>
> From the open datasheet, that is the suspend 1 mode, which is supported
> by all LAN95xx
On 10 December 2012 12:09, Oliver Neukum 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 runtime.
>>
>
y devices supporting
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
---
drivers/net/usb/smsc95xx.c | 136 +++-
1 file changed, 135 inser
>> +
>> + 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
> 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 "wo
ards, power buttons,
* 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
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
Hi Bjorn,
On 27 November 2012 17:21, Steve Glendinning 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?
>>
&
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. The USB device is handled by the
> generic "usb" driver, which will do the right
> BTW, I just saw the smsc95xx datasheet and the vendor's driver
> source code, and found the chip supports runtime PM well
> (remote wakeup on 'good packet' or link change), so do you
> plan to implement that?
Yes, I do plan to implement this. Note that this feature is only
supported on some pro
of the helper macro.
> Also, it isn't necessary to bother mm to allocate 8bytes/16byte,
> and we can use stack variable safely.
Acked-By: Steve Glendinning
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.k
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
uct ID: 0xa4a1
Vendor ID: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 cal
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 Ja
lue , automatically mask it off?
When replacing this I happened 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
d to allow the state of the pin
level to be specified
Signed-Off-By: Steve Birtles <[EMAIL PROTECTED]>
usb.patch
Description: Binary data
Matt,
You hit it on the first try! Everything works if I manually load
sd_mod.
Should sd_mod be loading automatically? Or should I add it
to /etc/modules? Currently I'm only autoloading ohci-hcd and everything
else USB needs seems to be pulled in as needed.
Thanks!
Steve
On Sat, 2007-
age: waiting for device to settle before scanning
<5>scsi 2:0:0:0: Direct-Access USB 2.0 Flash Drive 0.00 PQ: 0
ANSI: 2
<7>usb-storage: device scan complete
And nothing further--the expected sda device is never created.
This is new territory for me. Any advice on where I should b
68 matches
Mail list logo
