On Sat, Nov 08, 2014 at 08:01:09 -0500,
Alan Stern wrote:
I'm not aware of any changes to ohci-hcd which would cause this to
happen. In fact, I'm not aware of any changes at all to the PCI
version of ohci-hcd in this development cycle.
I double checked and the issue was in 3.17. I thought i
On Wed, 5 Nov 2014 15:46:25 +
Daniel Silverstone wrote:
> Sadly I can't look at the exact firmware of the device, but I can
> tell you it was based on ST Electronics' virtual COM port example in
> their *old* STM32 development kits.
>From some experience with this at work, I have to say that
Hayes Wang :
> Francois Romieu [mailto:rom...@fr.zoreil.com]
> > Sent: Monday, November 03, 2014 6:53 AM
> [...]
> > test_and_clear_bit (dense) or clear_bit would be more idiomatic.
>
> Excuse me. Any suggestion?
> Should I use clear_bit directly, or something else?
> Or, do I have to remove th
On Sat, 8 Nov 2014 16:27:54 -0500 (EST)
Alan Stern wrote:
> On Sat, 8 Nov 2014, Mark Knibbs wrote:
>
> > It seems I didn't take into account the recent patch
> > "SCSI: Don't store LUN bits in CDB[1] for USB mass-storage devices"[1],
> > which causes my patch to not work properly. I should have
This patch does two things for SCM eUSCSI USB-SCSI converters:
1. SCM eUSCSI bridge devices are hard-wired to use SCSI ID 7. On connecting
the converter, access to that ID is attempted during the bus scan. Asking
the converter to issue INQUIRY commands to itself isn't very polite and
wastes time.
On Sat, 8 Nov 2014, Mark Knibbs wrote:
> It seems I didn't take into account the recent patch
> "SCSI: Don't store LUN bits in CDB[1] for USB mass-storage devices"[1],
> which causes my patch to not work properly. I should have actually tested it
> before posting. Sigh.
>
> [1] https://www.mail-a
On Fri, 7 Nov 2014 22:01:38 +
Mark Knibbs wrote:
> This patch does two things for SCM eUSCSI USB-SCSI converters:
> ...
> 2. Enable multi-LUN support. eUSCSI devices don't support Get Max LUN
> requests, returning an error (-32). [Different targets could have different
> numbers of LUNs, so
On Sat, Nov 08, 2014 at 08:01:09 -0500,
Alan Stern wrote:
I'm not aware of any changes to ohci-hcd which would cause this to
happen. In fact, I'm not aware of any changes at all to the PCI
version of ohci-hcd in this development cycle.
Can you perform a bisection to see which commit was resp
The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4:
Linux 3.18-rc3 (2014-11-02 15:01:51 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
tags/usb-3.18-rc4
for you to fetch changes up to 1910195423e7bea4c01
On Sat, Nov 08, 2014 at 06:45:59PM +0100, Robert Jarzmik wrote:
> Felipe Balbi writes:
>
> > fine by me, as long as their all optional and agreed with devicetree
dumb me: s/their/they're
> > folks. I think we still have time for v3.19 if you manage to finish this
> > before next week's end.
> I
Felipe Balbi writes:
> fine by me, as long as their all optional and agreed with devicetree
> folks. I think we still have time for v3.19 if you manage to finish this
> before next week's end.
I will try, no promise I'll succeed in this window.
At least I should fire out within the next days the
On Fri, 7 Nov 2014, Bruno Wolff III wrote:
> lsusb -v output is at https://bugzilla.kernel.org/attachment.cgi?id=156981
> Sample dmesg output from booting 3.18.0-0.rc3.git2.2.fc22.1.i686+PAE on
> a machine with USB 1.1:
>
> [ 14.014047] usb 1-2: device descriptor read/64, error -32
> [ 14.28
12 matches
Mail list logo
