On Friday 22 April 2005 11:21 am, you wrote:
>
> > > Can you to verify that rc3 with this patch works on both your Zaurus
> > > models (C-860, SL-5600)? It works on a Motorola A768i too ... they all
> > > seem to abuse CDC MDLM in the same basic way.
>
> Sorry for the bad news, but the patch (the 7396 bytes one) did not work with
> my C860.
Based on the descriptor dump you sent, the problem is that it's
rejecting one of the options about how/when to pad when adjusting
for this nonstandard framing. But since zaurus_tx_fixup() clearly
works without caring about such nuances, that option bit seems to
be fair to treat as "don't care". (Your Zaurus sets the bit, the
Motorola clears it, yet the same fixup interops with both...)
> 1.)
> FYI: (I got the following warning when compiling)
> drivers/usb/net/usbnet.c:1534: warning: `cdc_status' defined but not used
Looks like most other folk build with CDC Ethernet!
See if the attached patch -- on top of the preceding one -- improves
things for you.
- Dave
Minor Zaurus-related fixes to usbnet:
- For the new pseudo-MDLM support, ignore the "pad before calculating CRC"
option since the Zaurus framing fixup has always done it that way. (And
oddly enough, it interoperates with devices that set that option, as
wll as those which don't...)
- Remove an "unused" warning if Zaurus is defined but not CDC Ethernet,
associated with the new CDC status transfer support; just move one
CONFIG_* #ifdef to cover more code.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- 1.134/drivers/usb/net/usbnet.c 2005-04-23 11:38:58 -07:00
+++ edited/drivers/usb/net/usbnet.c 2005-04-23 12:00:08 -07:00
@@ -1520,6 +1520,26 @@
}
}
+#endif /* NEED_GENERIC_CDC */
+
+
+#ifdef CONFIG_USB_CDCETHER
+#define HAVE_HARDWARE
+
+/*-------------------------------------------------------------------------
+ *
+ * Communications Device Class, Ethernet Control model
+ *
+ * Takes two interfaces. The DATA interface is inactive till an altsetting
+ * is selected. Configuration data includes class descriptors.
+ *
+ * This should interop with whatever the 2.4 "CDCEther.c" driver
+ * (by Brad Hards) talked with.
+ *
+ *-------------------------------------------------------------------------*/
+
+#include <linux/ctype.h>
+
static void dumpspeed (struct usbnet *dev, __le32 *speeds)
{
@@ -1570,26 +1590,6 @@
}
}
-#endif /* NEED_GENERIC_CDC */
-
-
-#ifdef CONFIG_USB_CDCETHER
-#define HAVE_HARDWARE
-
-/*-------------------------------------------------------------------------
- *
- * Communications Device Class, Ethernet Control model
- *
- * Takes two interfaces. The DATA interface is inactive till an altsetting
- * is selected. Configuration data includes class descriptors.
- *
- * This should interop with whatever the 2.4 "CDCEther.c" driver
- * (by Brad Hards) talked with.
- *
- *-------------------------------------------------------------------------*/
-
-#include <linux/ctype.h>
-
static u8 nibble (unsigned char c)
{
if (likely (isdigit (c)))
@@ -2800,11 +2800,13 @@
* - bPad (ignored, for PADAFTER -- BLAN-only)
* bits are:
* - 0x01 -- Zaurus framing (add CRC)
- * - 0x02 -- PADBEFORE
- * - 0x04 -- PADAFTER
+ * - 0x02 -- PADBEFORE (CRC includes some padding)
+ * - 0x04 -- PADAFTER (some padding after CRC)
* - 0x08 -- "fermat" packet mangling (for hw bugs)
+ * the PADBEFORE appears not to matter; we interop
+ * with devices that use it and those that don't.
*/
- if (detail->bDetailData[1] != 0x01) {
+ if ((detail->bDetailData[1] & ~02) != 0x01) {
/* bmDataCapabilites == 0 would be fine too,
* but framing is minidriver-coupled for now.
*/
