linux-kernel - RE: [PATCH] drivers: staging: GPS protocol driver for wl128x

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] [day] [month] [year] [list]

Date:	Fri, 11 Jun 2010 17:55:04 +0530 (IST)
From:	Pavan Savoy <pavan_savoy@...oo.co.in>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	greg <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] drivers: staging: GPS protocol driver for wl128x

Alan, (slightly long mail warning..)

as I mentioned before, the problem is how can I know which platform device's registration caused the tty_open to be called ?

Background: [apart from the mail chain below...]
A platform driver by name ST_0 allows registration of certain protocol driver like BT_0 to be registered onto it, and use it as the transport.

This plat driver ST_O now signals the user-space to open up a TTY device and install the ldisc on top of it. (ldisc being ST_0's registered ldisc during it's plat probe).

Now the plat driver's tty_open previously registered is called, but here lies the problem - On what basis do I know that it was because of ST_0 and also How can I send the device number 'x' information in ttySx for user-space application to open/tiocsetd on that device.

All these problems would be solved, if only we could open/tiocsetd a ldisc from the kernel space - basically the ability to claim/use a TTY interface.
something like,

tty_register_ldisc(N_TI_WL, &ldisc_ops, UART_NUM_1);
tty_set_ldisc(); from ldisc drivers itself.. 

please comment...

> Here are the 2 ST platform devices,
> struct platform_device st_device_0 = {
>         .name = "ST_DEV_0",
>         .id = -1,
>         .dev.platform_data =
> &array,
>         .dev.release =
> any_device_release,
> };
> struct platform_device st_device_1 = {
>         .name = "ST_DEV_1",
>         .id = -1,
>         .dev.platform_data =
> &array,
>         .dev.release =
> any_device_release,
> };
>
> BT attaching itself to ST_DEV_0,
> static struct protocol_platform_data bt_data = {
>         .parent_dev =
> &st_device_0,
>         .name = "BT",
> };
>
> static struct platform_device bt_device = {
>         .name = "BT",
>         .id = -1,
>         .dev.platform_data =
> &bt_data,
>         .dev.release =
> bt_device_release,
> };
>
> And FM attaching itself to - ST_DEV_1,
> static struct protocol_platform_data fm_data = {
>         .parent_dev =
> &st_device_1,
>         .name = "FM",
> };
> static struct platform_device fm_device = {
>         .name = "FM",
>         .id = -1,
>         .dev.platform_data =
> &fm_data,
>         .dev.release =
> fm_device_release,
> };
>
> My "ST_REGISTER" would now look like,
> int st_register(struct protocol_platform_data *data)
> {
>         struct st_data_s *st_data;
>         struct platform_device *parent
> = data->parent_dev;
>
>         st_data =
> dev_get_drvdata(&parent->dev);
>
>         printk("%s registering into
> %s\n", data->name, parent->name);
>
>         printk("data got is %s\n",
> st_data->name);
>         st_data->name = "Changed
> Name";
>         return 0;
> }
> EXPORT_SYMBOL(st_register);

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