DSS usage
Dmytro Milinevskyy
dmilinevskyy at sequans.com
Wed May 7 04:32:02 PDT 2014
Hello,
please find a set of patches in attachment for creation of DSS channels as char devices which are independent of the state of wwanX interface.
Changelog:
- clean submitted URBs on device detach
- proper cleanup on DSS deregistration
- NL interface for DSS creation/deletion
- a userspace tool to test NL interface
Not yet tested/integrated:
- proper power management
thanks,
~ dmytro
----- Original Message -----
>
>
> ----- Original Message -----
> > Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:
> >
> > > Hi Bjørn,
> > >
> > > I've already started to work on a concept of DSS through char
> > > dev.
> > > In the attachment you can find the first trial.
> > > It's not extremely stable version but I can exchange data between
> > > the host and the device
> > > even if the main wwan interface is down. The DSS channel is
> > > registered as a misc device.
> > >
> > > There are several points which so far I don't know how to
> > > implement
> > > correctly:
> > > 1. how to publish/delete new DSS channel? Via ioctl for cdc-wdmXX
> > > device or via NL msg. Honestly I would prefer to use NL.
> >
> > Hello Dmytro,
> >
> > I just got a new idea for you regarding this point. Don't yet know
> > if
> > it's a *good* idea, but I thought I could throw it out for you to
> > consider. At least it's simple to implement and avoids any new
> > userspace
> > tool:
> >
> > In my attempt to add a "magic" IP session 0 VLAN, I set
> > NETIF_F_HW_VLAN_CTAG_FILTER in bind and abused the VLAN hardware
> > filtering infrastructure like this:
> >
> > static int cdc_mbim_rx_add_vid(struct net_device *netdev, __be16
> > proto, u16 vid)
> > {
> > struct usbnet *dev = netdev_priv(netdev);
> > struct cdc_mbim_state *info = (void *)&dev->data;
> >
> > if (vid == IPS0_MAGIC_VLAN)
> > info->flags |= FLAG_IPS0_VLAN;
> >
> > /* only 256 IP sessions and 256 Device Stream sessions are mapped
> > */
> > if (vid >= 512)
> > return -EINVAL;
> > return 0;
> > }
> >
> > static int cdc_mbim_rx_kill_vid(struct net_device *netdev, __be16
> > proto, u16 vid)
> > {
> > struct usbnet *dev = netdev_priv(netdev);
> > struct cdc_mbim_state *info = (void *)&dev->data;
> >
> > if (vid == IPS0_MAGIC_VLAN)
> > info->flags &= ~FLAG_IPS0_VLAN;
> > return 0;
> > }
> >
> > static const struct net_device_ops cdc_mbim_netdev_ops = {
> > .ndo_open = usbnet_open,
> > .ndo_stop = usbnet_stop,
> > .ndo_start_xmit = usbnet_start_xmit,
> > .ndo_tx_timeout = usbnet_tx_timeout,
> > .ndo_change_mtu = usbnet_change_mtu,
> > .ndo_set_mac_address = eth_mac_addr,
> > .ndo_validate_addr = eth_validate_addr,
> > .ndo_vlan_rx_add_vid = cdc_mbim_rx_add_vid,
> > .ndo_vlan_rx_kill_vid = cdc_mbim_rx_kill_vid,
> > };
> >
> Hello Bjørn,
> this is quite interesting though I suppose this way of DSS creation
> is quite confusing.
> Basically a given vlan interface won't work as a normal interface.
> This sounds like an easy path for device creation but it's not
> obvious and breaks backward compatibility.
> Some vendors might be using dss over vlan already.
> Also this closes the door to extending the number of IPS pipes. I
> believe that 256 IPS channels is enough right now but that
> may be a limitation in the future.
>
> Regarding the name of the device name - the index of master mbim
> device is taken from the minor number of USB interface.
> Of course I can preserve the name of the control pipe device but the
> indexes remain same.
>
> Misc device is easy to create. So I chose it as a starter. Of course
> if it limits the number of simultaneously existing
> device the dcc char dev may be turned into a generic chardev with a
> dedicated major number.
>
> best regards,
> ~ dmytro
>
> >
> > The purpose was to get notifications when VLANs are added and
> > removed,
> > and I'm really only interested in knowing about the single magic
> > ID.
> >
> > But what if you use this to automatically create and delete DSS
> > character devices when one of the DSS VLAN IDs are added or
> > removed?
> > Just adding something like
> >
> > /* create DSS TTY */
> > if (vid >= 256 && vid < 512)
> > dss_register(info, vid - 256)
> >
> > /* remove DSS TTY */
> > if (vid >= 256 && vid < 512) {
> > struct mbim_dss_channel *dss = dss_find(info, vid -
> > 256)
> >
> > if (dss)
> > dss_unregister(info, vid - 256)
> > }
> >
> > should do all you want?
> >
> > So that would be a simple way to make 'ip' (or any other tool using
> > the
> > VLAN NL API) create the character device too. So
> >
> > ip link add link wwan0 wwan0.256 type vlan id 256
> >
> > would now have 2 effects:
> >
> > wwan0.256 is created
> > /dev/mbim1234-dss0 is created
> >
> >
> > (BTW, I would strongly suggest using the master netdev name as part
> > of
> > the tty device, because otherwise you'll have problems mapping
> > these
> > character devices to multiple MBIM devices).
> >
> > This would also need some additional magic in the packet delivery,
> > but I
> > think you'll need that anyway because you cannot just remvoe the
> > existing API. You could either just deliver a skb clone to both
> > your
> > character device and to usbnet_skb_return, or you could select one
> > of
> > them based on whether the chardev is open or not.
> >
> > > 2. what is the best way to destroy DSS channels if MBIM device
> > > goes
> > > offline(i.e. it's being unbound).
> > > I'm afraid that I can't sleep in this context to wait for all
> > > DSS users to finish with the cleanup
> >
> > You'll just have to let the DSS devices live on like zombies,
> > returning
> > appropriate errors and doing final cleanup in release. I believe
> > that's
> > how this is for all character device drivers?
> >
> > > 3. there's a limitation on the number of misc devices in the
> > > system
> > > since it uses same major index.
> > > Don't know whether it's a big limitation though.
> >
> > Probably not, but it would be nice to say "unlimited" :-)
> >
> > Looking at drivers/char/misc.c it seems that the number of
> > DYNAMIC_MINORS is as low as 64 by default. Maybe a misc_device
> > just
> > isn't the best approach here?
> >
> > But this is a minor detail which can be changed at any time later.
> >
> >
> > Bjørn
> > _______________________________________________
> > libmbim-devel mailing list
> > libmbim-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libmbim-devel
> >
>
-- IMPORTANT NOTICE:
The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drivers-net-usb-usbnet-flag-to-submit-IN-URBs-even-t.patch
Type: text/x-patch
Size: 3614 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140507/2e236797/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-drivers-net-usb-mbim-export-DSS-pipes-via-miscdev.patch
Type: text/x-patch
Size: 19355 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140507/2e236797/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-drivers-net-usb-mbim-add-NL-interface-to-create-and-.patch
Type: text/x-patch
Size: 7181 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140507/2e236797/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-tools-mbim-ctrl-tool.patch
Type: text/x-patch
Size: 7151 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libmbim-devel/attachments/20140507/2e236797/attachment-0007.bin>
More information about the libmbim-devel
mailing list