DSS usage

[Bjørn Mork]

Dmytro Milinevskyy <dmilinevskyy at sequans.com> writes:

> this is quite interesting though I suppose this way of DSS creation is
> quite confusing.

Yes, it is.  But so is any new ioctl or NL message.  This is going to be
an extremely driver specific API no matter what we do.

> 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.

Yes, it would have to be implemented with backwards compatibility in
mind.  I believe that can be done. The VLAN interface can work as before
until you open the character device.  So if you don't open the chardev,
then nothing changes.

This would also allow a mixed usage, where one DSS session use the VLAN
interface and another use the chardev.  Mixed usage for the same DSS
session is of course not possible, and should not be.

Anyway, it was just a crazy idea. Most of my ideas are best forgotten :-)

> 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.

256 is a hard limit over a single MBIM link, so I don't think there is
any need to anticipate more channels in the future.  There is just one
byte available for session ID in the NDP signature.

> Regarding the name of the device name - the index of master mbim
> device is taken from the minor number of USB interface.

Ah, right. That will work.  Didn't notice that you used the USB
interface as a reference.

> 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.

Yup, agree.  This is an easy way to start and it can always be changed
later.


Bjørn