On 24. feb. 2011 22:56, Greg KH wrote:
On Thu, Feb 24, 2011 at 09:45:02PM +0100, Josua Dietze wrote:
I'm forwarding this with the consent of the author.
Josua Dietze
--------------------------------------------------
Hi all!
I have then released the driver as far as I have come at Github:
https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
Be free to test and hack and propose improvements of the driver
code. Issues/feature requests are best registered/discussed in the
issues section:
https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver/issues
See README file for instructions of building and using the driver.
Ok, but as this is just a fork of an existing in-kernel driver, we need
a patch, sent to us in the format described in
Documentation/SubmittingPatches, for us to be able to accept it.
Option is simply patched yes:
--- a/option.c
+++ b/option.c
@@ -370,6 +370,10 @@ static void option_instat_callback(struct urb *urb);
#define CELOT_VENDOR_ID 0x211f
#define CELOT_PRODUCT_CT680M 0x6801
+/* Samsung products */
+#define SAMSUNG_VENDOR_ID 0x04e8
+#define SAMSUNG_PRODUCT_GT_B3730 0x6889
+
/* some devices interfaces need special handling due to a number of
reasons */
enum option_blacklist_reason {
OPTION_BLACKLIST_NONE = 0,
@@ -913,6 +917,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(CINTERION_VENDOR_ID, 0x0047) },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA
450 1xEVDO modem */
+ { USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung
GT-B373
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
People was waiting to test the driver, so I rushed it out without time
to check if I should fork some other git repo.
The gt_b3730 is independent (just inspired by cdc_eem module).
I am not asking for it to be included yet, cause if you look at the
issues list, it has serious problems with the downlink speed (uplink is
nearer where it should be).
What I am wondering about is if how it is done in usbnet is suitable for
such a high speed device (LTE), possibly very chatty on USB. I am
suspecting that it polls for incoming USB packets too infrequently (only
through a "tasklet_schedule", not continuously). Do you think that could
be a case? If so, maybe the usbnet needs a flag for "continuous" polling
(not sure if it is possible with USB bulk ports?) or write that part
independently of the usbnet code.
--
Marius
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
