Message ID | 1261601807-8385-1-git-send-email-tloo@saltstorm.net |
---|---|
State | Changes Requested, archived |
Delegated to: | David Miller |
Headers | show |
Hi Thomas, > This patch adds the Sony Ericsson J105i (Naite) > mobile phone to the cdc_ether device whitelist, > enabling access to the modem. > > I would think more SE models of this generation > (2009Q3) with builtin HSDPA modules also needs > to be added to this list. I do prefer if we NOT use the mbm_info details for this since they are clearly for mobile broadband cards with FLAG_WWAN. Since this is a phone where the setup of the connection is done via the phone. And you just treat this as an Ethernet device and run DHCP, then please create a se_info or similar with FLAG_ETHER. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann <marcel@holtmann.org> writes: >> This patch adds the Sony Ericsson J105i (Naite) >> mobile phone to the cdc_ether device whitelist, >> enabling access to the modem. >> >> I would think more SE models of this generation >> (2009Q3) with builtin HSDPA modules also needs >> to be added to this list. > > I do prefer if we NOT use the mbm_info details for this since they are > clearly for mobile broadband cards with FLAG_WWAN. Assuming that these devices can be configured just like the WWAN cards by sending commands to the associated ACM* or WDM* interfaces, why would you treat them differently? Because they've got a keyboard and a display? > Since this is a phone where the setup of the connection is done via the > phone. And you just treat this as an Ethernet device and run DHCP, then > please create a se_info or similar with FLAG_ETHER. Why would anyone want to setup the connection via the phone? That seems unnecessary cumbersome. I'd prefer such devices to be auto-configured just like any other WWAN device. Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bjorn, > >> This patch adds the Sony Ericsson J105i (Naite) > >> mobile phone to the cdc_ether device whitelist, > >> enabling access to the modem. > >> > >> I would think more SE models of this generation > >> (2009Q3) with builtin HSDPA modules also needs > >> to be added to this list. > > > > I do prefer if we NOT use the mbm_info details for this since they are > > clearly for mobile broadband cards with FLAG_WWAN. > > Assuming that these devices can be configured just like the WWAN cards > by sending commands to the associated ACM* or WDM* interfaces, why would > you treat them differently? Because they've got a keyboard and a > display? these are not like MBM devices WWAN cards. The MBM cards require to setup the PDP context before the card will become ready. With an actual phone you are already set. So these are Ethernet devices and not WWAN cards. > > Since this is a phone where the setup of the connection is done via the > > phone. And you just treat this as an Ethernet device and run DHCP, then > > please create a se_info or similar with FLAG_ETHER. > > Why would anyone want to setup the connection via the phone? That seems > unnecessary cumbersome. I'd prefer such devices to be auto-configured > just like any other WWAN device. Are they WWAN devices? What these do is basically tethering via an Ethernet like device. It does not require a telephony stack to drive this hardware. We require a proper DEVTYPE classification and these don't fall into the category of WWAN devices. They can be treated like every other Ethernet card and should be classified like this. We have FLAG_ETHER for this, so please use that one. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann <marcel@holtmann.org> writes: > Hi Bjorn, > >> >> This patch adds the Sony Ericsson J105i (Naite) >> >> mobile phone to the cdc_ether device whitelist, >> >> enabling access to the modem. >> >> >> >> I would think more SE models of this generation >> >> (2009Q3) with builtin HSDPA modules also needs >> >> to be added to this list. >> > >> > I do prefer if we NOT use the mbm_info details for this since they are >> > clearly for mobile broadband cards with FLAG_WWAN. >> >> Assuming that these devices can be configured just like the WWAN cards >> by sending commands to the associated ACM* or WDM* interfaces, why would >> you treat them differently? Because they've got a keyboard and a >> display? > > these are not like MBM devices WWAN cards. The MBM cards require to > setup the PDP context before the card will become ready. With an actual > phone you are already set. You are? AFAIK, the PDP context *may* be configured using the phone UI but it still needs to be setup. And there are good reasons why you'd like to configure/setup/verify the PDP context from the PC even if one is setup using the phone UI. You will at least need to verify that a PDP context actually *is* setup. And you might want to use a different APN than the one used when surfing from the phone. You might even want to choose different APNs depending on context (for VPN access, e.g) > So these are Ethernet devices and not WWAN cards. Well, I argued that the WWAN card were Ethernet devices. I realise that they've been defined otherwise now. What I'm trying to understand are the finer details of this definition. Exactly what defines a WWAN card? >> > Since this is a phone where the setup of the connection is done via the >> > phone. And you just treat this as an Ethernet device and run DHCP, then >> > please create a se_info or similar with FLAG_ETHER. >> >> Why would anyone want to setup the connection via the phone? That seems >> unnecessary cumbersome. I'd prefer such devices to be auto-configured >> just like any other WWAN device. > > Are they WWAN devices? What these do is basically tethering via an > Ethernet like device. It does not require a telephony stack to drive > this hardware. Do they connect automatically, or do you need to initiate the connection somehow? > We require a proper DEVTYPE classification and these don't fall into the > category of WWAN devices. They can be treated like every other Ethernet > card and should be classified like this. We have FLAG_ETHER for this, so > please use that one. I believe the WWAN cards also can be treated like every other USB Ethernet device, as far as the kernel is concerned. Any differences are easily resolved by userspace applications. So I'm still trying to figure out what makes a WWAN device special wrt the kernel. Thanks for explaining. Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bjorn, > >> >> This patch adds the Sony Ericsson J105i (Naite) > >> >> mobile phone to the cdc_ether device whitelist, > >> >> enabling access to the modem. > >> >> > >> >> I would think more SE models of this generation > >> >> (2009Q3) with builtin HSDPA modules also needs > >> >> to be added to this list. > >> > > >> > I do prefer if we NOT use the mbm_info details for this since they are > >> > clearly for mobile broadband cards with FLAG_WWAN. > >> > >> Assuming that these devices can be configured just like the WWAN cards > >> by sending commands to the associated ACM* or WDM* interfaces, why would > >> you treat them differently? Because they've got a keyboard and a > >> display? > > > > these are not like MBM devices WWAN cards. The MBM cards require to > > setup the PDP context before the card will become ready. With an actual > > phone you are already set. > > You are? AFAIK, the PDP context *may* be configured using the phone UI > but it still needs to be setup. And there are good reasons why you'd > like to configure/setup/verify the PDP context from the PC even if one > is setup using the phone UI. You will at least need to verify that a PDP > context actually *is* setup. And you might want to use a different APN > than the one used when surfing from the phone. You might even want to > choose different APNs depending on context (for VPN access, e.g) > > > So these are Ethernet devices and not WWAN cards. > > Well, I argued that the WWAN card were Ethernet devices. I realise that > they've been defined otherwise now. What I'm trying to understand are > the finer details of this definition. Exactly what defines a WWAN card? > > >> > Since this is a phone where the setup of the connection is done via the > >> > phone. And you just treat this as an Ethernet device and run DHCP, then > >> > please create a se_info or similar with FLAG_ETHER. > >> > >> Why would anyone want to setup the connection via the phone? That seems > >> unnecessary cumbersome. I'd prefer such devices to be auto-configured > >> just like any other WWAN device. > > > > Are they WWAN devices? What these do is basically tethering via an > > Ethernet like device. It does not require a telephony stack to drive > > this hardware. > > Do they connect automatically, or do you need to initiate the connection > somehow? > > > We require a proper DEVTYPE classification and these don't fall into the > > category of WWAN devices. They can be treated like every other Ethernet > > card and should be classified like this. We have FLAG_ETHER for this, so > > please use that one. > > I believe the WWAN cards also can be treated like every other USB > Ethernet device, as far as the kernel is concerned. Any differences are > easily resolved by userspace applications. and this is where you are totally wrong. It is not easy for userspace to identify the type of an interface and resolve things. Take WiFi for example. We need to actually connect to a network before these are useful. Same applies for 3G cards (aka WWAN) devices. You have to register with the network, attach to GPRS etc. before any of this becomes really useful. If the the USB network interface does automatic connect and does tethering then it is not a WWAN device. Then it is an Ethernet device. And that you can use your phone via a TTY and configure a second PDP context and then run PPP has nothing to do with its network device. > So I'm still trying to figure out what makes a WWAN device special wrt > the kernel. Thanks for explaining. It has nothing to do with the kernel. It classifies the network device type for userspace. Like you classify /dev/sda as "disk" and /dev/sda1 as "partition". So please modify your patch as outlined in my first response. It should take you only like 5 minutes to do so. Then your phone will show up and gets a proper classification. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcel Holtmann <marcel@holtmann.org> writes: >> I believe the WWAN cards also can be treated like every other USB >> Ethernet device, as far as the kernel is concerned. Any differences are >> easily resolved by userspace applications. > > and this is where you are totally wrong. It is not easy for userspace to > identify the type of an interface and resolve things. No? Well, I probably have a too limited view of this, but I found it easy enough to create a pre-up/post-down script which checked whether the network interface being brought up/down belongs to a supported WWAN card and then do the necessary magic on one of the related cdc-wdm channels. This was implemented by poking around in the sysfs. I fail to see why one needs a special network device name to do that. But it would have been useful to have the CDC MDLM header exported somewhere in sysfs. That's more of a generic usb/cdc thing though, I guess. > Take WiFi for example. We need to actually connect to a network before > these are useful. Same applies for 3G cards (aka WWAN) devices. You have > to register with the network, attach to GPRS etc. before any of this > becomes really useful. If the the USB network interface does automatic > connect and does tethering then it is not a WWAN device. Then it is an > Ethernet device. I can live with that defintion of the difference between a WWAN/3G device (wwan%d) and a USB Ethernet device (usb%d). But I still don't see why this doesn't make a phone (supporting the same commands as a 3G card) a WWAN device. A phone can't do an automatic connection any more than a WWAN card can. Both *must* be configured with at least one PDP context, register with the network, attach to GPRS etc. Yes, some phones can be configured to auto-connect using it's own UI. But there's really nothing preventing anyone from implementing the same feature for a WWAN card. What would that make that card then? > And that you can use your phone via a TTY and configure a second PDP > context and then run PPP has nothing to do with its network device. I was talking about the network device. My experience with these devices is limited to the Ericsson F3507g, but I assume that many of them will behave identically. It allows you to define multiple PDP contexts and select which one you connect with, either you use PPP or the network device. The list of defined contexts are in fact shared. >> So I'm still trying to figure out what makes a WWAN device special wrt >> the kernel. Thanks for explaining. > > It has nothing to do with the kernel. It classifies the network device > type for userspace. Like you classify /dev/sda as "disk" and /dev/sda1 > as "partition". > > So please modify your patch as outlined in my first response. It should > take you only like 5 minutes to do so. Then your phone will show up and > gets a proper classification. Sorry for the confusion, but the patch was not mine. I just stumbled across the discussion and first wondered why the heck the mbm_info stuff was added (hadn't noticed before) and then why the heck this device should be treated differenctly if it shows up as a similar one. Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2010-01-05 at 13:46 +0100, Bjørn Mork wrote: > Marcel Holtmann <marcel@holtmann.org> writes: > > >> I believe the WWAN cards also can be treated like every other USB > >> Ethernet device, as far as the kernel is concerned. Any differences are > >> easily resolved by userspace applications. > > > > and this is where you are totally wrong. It is not easy for userspace to > > identify the type of an interface and resolve things. > > No? Well, I probably have a too limited view of this, but I found it > easy enough to create a pre-up/post-down script which checked whether > the network interface being brought up/down belongs to a supported WWAN > card and then do the necessary magic on one of the related cdc-wdm > channels. This was implemented by poking around in the sysfs. I fail to > see why one needs a special network device name to do that. > > But it would have been useful to have the CDC MDLM header exported > somewhere in sysfs. That's more of a generic usb/cdc thing though, I > guess. > > > Take WiFi for example. We need to actually connect to a network before > > these are useful. Same applies for 3G cards (aka WWAN) devices. You have > > to register with the network, attach to GPRS etc. before any of this > > becomes really useful. If the the USB network interface does automatic > > connect and does tethering then it is not a WWAN device. Then it is an > > Ethernet device. > > I can live with that defintion of the difference between a WWAN/3G > device (wwan%d) and a USB Ethernet device (usb%d). > > But I still don't see why this doesn't make a phone (supporting the same > commands as a 3G card) a WWAN device. A phone can't do an automatic > connection any more than a WWAN card can. Both *must* be configured > with at least one PDP context, register with the network, attach to GPRS > etc. > > Yes, some phones can be configured to auto-connect using it's own > UI. But there's really nothing preventing anyone from implementing the > same feature for a WWAN card. What would that make that card then? > > > And that you can use your phone via a TTY and configure a second PDP > > context and then run PPP has nothing to do with its network device. > > I was talking about the network device. > > My experience with these devices is limited to the Ericsson F3507g, but > I assume that many of them will behave identically. It allows you to Haha. No. Never assume that two WWAN devices (or even two phones) will behave identically. It's almost never the case. > define multiple PDP contexts and select which one you connect with, > either you use PPP or the network device. The list of defined contexts > are in fact shared. Here's the difference: F3507g: requires AT command setup before cdc-ether port is usable SE j105i: does not require AT command setup before port is usable Same on my TM-506; you can simply run DHCP on the 'usb0' port and it works, because the phone is pretending to be a usb-ethernet device and transparently bridge between the ethernet and the cellular network. That's simply not the case with the F3507g or any other WWAN card. Phones are fundamentally different than WWAN cards and shouldn't be treated like one, at least at this time. Dan > >> So I'm still trying to figure out what makes a WWAN device special wrt > >> the kernel. Thanks for explaining. > > > > It has nothing to do with the kernel. It classifies the network device > > type for userspace. Like you classify /dev/sda as "disk" and /dev/sda1 > > as "partition". > > > > So please modify your patch as outlined in my first response. It should > > take you only like 5 minutes to do so. Then your phone will show up and > > gets a proper classification. > > Sorry for the confusion, but the patch was not mine. I just stumbled > across the discussion and first wondered why the heck the mbm_info stuff > was added (hadn't noticed before) and then why the heck this device > should be treated differenctly if it shows up as a similar one. > > > > Bjørn > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dan Williams <dcbw@redhat.com> writes: > Here's the difference: > > F3507g: requires AT command setup before cdc-ether port is usable > SE j105i: does not require AT command setup before port is usable > > Same on my TM-506; you can simply run DHCP on the 'usb0' port and it > works, because the phone is pretending to be a usb-ethernet device and > transparently bridge between the ethernet and the cellular network. > That's simply not the case with the F3507g or any other WWAN card. > > Phones are fundamentally different than WWAN cards and shouldn't be > treated like one, at least at this time. OK, then I misunderstood the request. I thought that this phone behaved like a WWAN card since it presumably advertised the same CDC "Mobile Direct Line" class as the Ericsson WWAN cards, maybe even with the same GUID in the MDLM header? If it really behaves like you describe (which is what the other Sony Ericsson phones I've seen does too), then I don't understand why it doesn't just advertise a CDC Ethernet class device. That's what the other phones do, and as you of course know, the reason why we don't have a gazillion phone VID/PID entries in cdc_ether.c.. Bjørn -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2010-01-07 at 09:50 +0100, Bjørn Mork wrote: > Dan Williams <dcbw@redhat.com> writes: > > > Here's the difference: > > > > F3507g: requires AT command setup before cdc-ether port is usable > > SE j105i: does not require AT command setup before port is usable > > > > Same on my TM-506; you can simply run DHCP on the 'usb0' port and it > > works, because the phone is pretending to be a usb-ethernet device and > > transparently bridge between the ethernet and the cellular network. > > That's simply not the case with the F3507g or any other WWAN card. > > > > Phones are fundamentally different than WWAN cards and shouldn't be > > treated like one, at least at this time. > > OK, then I misunderstood the request. I thought that this phone behaved > like a WWAN card since it presumably advertised the same CDC "Mobile > Direct Line" class as the Ericsson WWAN cards, maybe even with the same > GUID in the MDLM header? Interesting. But I'd be very, very skeptical if the phone really acted just like an MBM card. My TM-506 has *some* of the same commands that the F3507g and the F3607gw do but certainly not all of them. > If it really behaves like you describe (which is what the other Sony > Ericsson phones I've seen does too), then I don't understand why it > doesn't just advertise a CDC Ethernet class device. That's what the > other phones do, and as you of course know, the reason why we don't have > a gazillion phone VID/PID entries in cdc_ether.c.. Good question; though I've seen enough hardware that I'll simply just assume they did it differently just because they could, not for any specific reason. Don't over-estimate the intelligence of firmware people, they are just as human as the rest of us :) Dan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c index 21e183a..833ba5a 100644 --- a/drivers/net/usb/cdc_ether.c +++ b/drivers/net/usb/cdc_ether.c @@ -584,6 +584,11 @@ static const struct usb_device_id products [] = { USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE), .driver_info = (unsigned long) &mbm_info, }, { + /* Sony Ericsson J105i (Naite) */ + USB_DEVICE_AND_INTERFACE_INFO(0x0fce, 0xd12d, USB_CLASS_COMM, + USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE), + .driver_info = (unsigned long) &mbm_info, +}, { /* Toshiba F3507g */ USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x130b, USB_CLASS_COMM, USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
This patch adds the Sony Ericsson J105i (Naite) mobile phone to the cdc_ether device whitelist, enabling access to the modem. I would think more SE models of this generation (2009Q3) with builtin HSDPA modules also needs to be added to this list. Signed-off-by: Thomas Loo <tloo@saltstorm.net> --- drivers/net/usb/cdc_ether.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)