[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87obezs888.fsf@nemi.mork.no>
Date: Mon, 04 Mar 2013 12:41:11 +0100
From: Bjørn Mork <bjorn@...k.no>
To: fangxiaozhi 00110321 <fangxiaozhi@...wei.com>
Cc: <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<zihan@...wei.com>, <Lin.Lei@...wei.com>, <greg@...ah.com>,
<neil.yi@...wei.com>, <wangyuhua@...wei.com>,
<huqiao36@...wei.com>, <balbi@...com>,
<mdharm-usb@...-eyed-alien.net>, <sebastian@...akpoint.cc>
Subject: v3.8 regression: Huawei mode switching fails (was Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command)
Hello Franko,
This patch causes a number of regressions for both the Huawei devices I
have available for testing. One of them is completely unusable in v3.8
(unable to switch to modem mode) unless the usb-storage driver is
disabled.
I realize that some devices are historically handled by the usb-storage
driver, but userspace modeswitching is the rule for new devices AFAIK.
I see absolutely no valid argument for adding new devices. And there is
absolutely no excuse for adding devices which have been handled by
userspace switching for years! The patch does not just "optimize"
matching. It adds a large number of devices which were previously
handled just fine by usb_modeswitch. This is guaranteed to confuse users
with existing configurations, and users looking up any of the existing
documentation pointing to usb_modeswitch.
There is no need to repeat the discussion of kernel vs userspace
switching. I will only note that userspace switching:
- has been selected as the rule for new devices,
- allow the user to temporarily disable switching e.g. for mounting and
inspecting the usb-storage exported data,
- allow the user/system to apply device specific switching quirks
The v3.7->v3.8 regressions I observe are:
1) Temporarily disabling mode switching and mounting the CD image is now
impossible. Mode switching can only be disabled by blacklisting
usb-storage, which of course prevents usb-storage from working
Prior to v3.8, modeswitching could easily be disabled by userspace
configuration. The change breaks existing configurations.
2) Switching to non-default modes is now impossible. The E392
(initially appearing as 12d1:1505) Windows drivers will use a different
command than the one used by Linux, causing the device to select a
different configuration in Linux and Windows. This forces Linux and
Windows to see the device differently.
Prior to v3.8, different modeswitching commands could be configured
per device. The change breaks existing configurations.
3) Switching fails for some devices. The E367 (initially appearing as
12d1:1446) does not switch when it receives the command sent by
usb-storage. But the command disable further switching, preventing
userspace switching from working as well.
Prior to v3.8, the device would switch fine using a default
usb_modeswitch configuration. The change breaks existing
configurations.
I do note that there is a slight difference between the known working
usb_modeswitch command:
55534243123456780000000000000011062000000100000000000000000000
and the command sent by usb-storage:
char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
I assume the cause of the failure is either this difference or some
timing issue.
Anyway, I believe this patch must be reverted. It disables currently
used, well documented, and extremely useful, userspace funtionaliy for
all devices implicitly added by the conversion from device matching to
vendor matching.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists