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=+bXAuXhG+XG4ObUO_2MYD_XWxF_wbTVrpKagmHi8_CDQ@mail.gmail.com>
Date:	Thu, 25 Jul 2013 13:15:07 +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.

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.

On Thu, Jul 25, 2013 at 7:06 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Thu, Jul 25, 2013 at 12:53:40AM +0300, Dan Carpenter wrote:
>> > +static int gdm_lte_ioctl_get_data(struct wm_req_t *req, struct net_device *dev)
>> > +{
>> > +   u16 id = req->data_id;
>> > +
>> > +   switch (id) {
>> > +   case GET_ENDIAN_INFO:
>> > +           /* required for the user space application to find out device endian */
>> > +           get_dev_endian(&req->data, dev);
>> > +           break;
>> > +   default:
>> > +           printk(KERN_ERR "glte: ioctl - unknown type %d\n", id);
>> > +           break;
>> > +   }
>> > +   return 0;
>> > +}
>>
>> This should be a sysfs file not an ioctl.  What would break if we
>> fixed this right now (as opposed to waiting until we can't change
>> the API?).
>>
>> Otherwise if we can't change this, then it should return an error
>> code instead of printing a message.
>
> It should just be removed, why would you care about the endian-ness of
> the device at all?
>
> thanks,
>
> greg k-h
--
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/