>> GDM7240 is in LE where as GDM7243 (currently under development) is in BE. > > But why does this information need to be sent to userspace? > GDM724x chips have different endianess because of their internal architecture.The device sends out and accepts LTE protocol information in its own endianess. This is the design decision we made and we let the host converts the byte order. To decode the protocols, userspace needs this endianess information. >> User space applications needs to discover the endianess to properly >> encode/decode LTE control protocols. We have existing customers >> already deploying units in large volume, and want to avoid forcing >> them to change SDK APIs along with kernel updates. >> At some point, It will have to be fixed with SDK API can interoperate properly. > > Ugh, really? What special tools does userspace need to talk to this > device? It "should" just be a network device, and a serial port, why > does the endianness of the device mean anything? Just like 3G modems, network device and a serial port is enough for basic operation. For this, no ioctl for endianess is required. However, customers and operators want more information and programming capabilities, and this is really difficult to achieve with standard 3GPP AT commands alone. Therefore, if wanted, we also provide SDK APIs for handling more advanced features. Examples of such information include detailed connection status, rf controls, debug logs, and even firmware download. > Custom ioctls aren't ok for new drivers, if at all possible. Can't > userspace just trigger this based on the device id instead? Historically, the SDK is cross-platform designed and we wanted to have common methods for different operating systems, and have chosen to use ioctl. Windows does have one :). We will probably go with reading device id Anyway, you are right that endianess matters only when using this SDK. If you suggest to remove the ioctl because SDK is optional, I will agree. Regards, Won. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
