linux-kernel - Re: [PATCH v2 1/2] staging: gdm7240: adding LTE USB driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABe_0=JCfq3pHvmQK42NQd16JRj-xjXP=jLvN5QCk-k8KH199w@mail.gmail.com>
Date:	Thu, 25 Jul 2013 14:56:51 +0900
From:	Won Kang <wkang77@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	devel@...verdev.osuosl.org, wonkang@...semi.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] staging: gdm7240: adding LTE USB driver

>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/