[re-worked] New ldisc for WiLink7.0

[re-worked] New ldisc for WiLink7.0

[pavan_savoy]

Greg/Alan & the linux-kernel community,

Texas Instruments has introduced it's new series of WiLink chipsets
which has Bluetooth, WLAN, FM-Rx and FM-Tx and GPS on 1 single chip.
This series of chipsets allow apps processor to interface with the chip
over a single UART mux-ed for all 3 (BT,FM and GPS) cores on chip and
SDIO for WLAN.

The following list of patches introduces a new line discipline which allows
such muxing to happen, and 3 different BT, FM and GPS drivers would sit on
top of this driver (registering/unregistering) and glue this to relevant s/w
stacks.

This has been verified to work on TI's OMAP platforms(34xx,36xx and 44xx).

[PATCH 1/6] serial: TTY: new ldisc for TI BT/FM/GPS chips

[pavan_savoy]

From: Pavan Savoy <pavan_savoy@ti.com>

A new N_TI_SHARED line discipline added for TI BT/FM/GPS
combo chips which make use of same TTY to communicate
with chip. This is to be made use of individual protocol
BT/FM/GPS drivers.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 include/linux/tty.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/include/linux/tty.h b/include/linux/tty.h
index 4409967..3eda091 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -23,7 +23,7 @@
  */
 #define NR_UNIX98_PTY_DEFAULT	4096      /* Default maximum for Unix98 ptys */
 #define NR_UNIX98_PTY_MAX	(1 << MINORBITS) /* Absolute limit */
-#define NR_LDISCS		20
+#define NR_LDISCS		21
 
 /* line disciplines */
 #define N_TTY		0
@@ -48,6 +48,7 @@
 #define N_PPS		18	/* Pulse per Second */
 
 #define N_V253		19	/* Codec control over voice modem */
+#define N_TI_SHARED	20	/* for TI's WL7 connectivity chips */
 
 /*
  * This character is the same as _POSIX_VDISABLE: it cannot be used as
-- 
1.5.4.3

[PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[pavan_savoy]

From: Pavan Savoy <pavan_savoy@ti.com>

This change adds the Kconfig and Make file for TI's
ST line discipline driver and the BlueZ driver for BT
core of the TI BT/FM/GPS combo chip.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 drivers/misc/Kconfig        |    1 +
 drivers/misc/Makefile       |    1 +
 drivers/misc/ti-st/Kconfig  |   24 ++++++++++++++++++++++++
 drivers/misc/ti-st/Makefile |    7 +++++++
 4 files changed, 33 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/ti-st/Kconfig
 create mode 100644 drivers/misc/ti-st/Makefile

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 625e3a6..c059bca 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -344,5 +344,6 @@ source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
 source "drivers/misc/iwmc3200top/Kconfig"
+source "drivers/misc/ti-st/Kconfig"
 
 endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c221917..021f282 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)      += iwmc3200top/
 obj-$(CONFIG_HWLAT_DETECTOR)	+= hwlat_detector.o
 obj-y				+= eeprom/
 obj-y				+= cb710/
+obj-y				+= ti-st/
diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig
new file mode 100644
index 0000000..18eea1c
--- /dev/null
+++ b/drivers/misc/ti-st/Kconfig
@@ -0,0 +1,24 @@
+#
+# TI's shared transport line discipline and the protocol
+# drivers (BT, FM and GPS)
+#
+menu "Texas Instruments shared transport line discipline"
+    config TI_ST
+    tristate "shared transport core driver"
+    select FW_LOADER
+    help
+        This enables the shared transport core driver for TI
+	    BT / FM and GPS combo chips.This enables protocol drivers
+	    to register themselves with core and send data, the responses
+	    are returned to relevant protocol drivers based on their
+	    packet types.
+
+    config ST_BT
+    tristate "BlueZ bluetooth driver for ST"
+    select BT
+    select TI_ST
+    help
+       This enables the Bluetooth driver for TI BT/FM/GPS combo devices
+       This makes use of shared transport line discipline core driver to
+       communicate with the BT core of the combo chip.
+endmenu
diff --git a/drivers/misc/ti-st/Makefile b/drivers/misc/ti-st/Makefile
new file mode 100644
index 0000000..cff3770
--- /dev/null
+++ b/drivers/misc/ti-st/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for TI's shared transport line discipline
+# and it's protocol drivers (BT, FM, GPS)
+#
+obj-$(CONFIG_TI_ST) += st_drv.o
+st_drv-objs			:= st_core.o st_kim.o st_ll.o
+obj-$(CONFIG_ST_BT) += bt_drv.o
-- 
1.5.4.3

[PATCH 3/6] drivers:misc: sources for ST core

[pavan_savoy]

From: Pavan Savoy <pavan_savoy@ti.com>

Texas Instruments BT, FM and GPS combo chips/drivers
make use of a single TTY to communicate with the chip.
This module constitutes the core logic, TTY ldisc driver
and the exported symbols for registering/unregistering of
the protocol drivers such as BT/FM/GPS.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 drivers/misc/ti-st/st_core.c | 1057 ++++++++++++++++++++++++++++++++++++++++++
 drivers/misc/ti-st/st_core.h |   92 ++++
 2 files changed, 1149 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/ti-st/st_core.c
 create mode 100644 drivers/misc/ti-st/st_core.h

diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
new file mode 100644
index 0000000..1cb7c0a
--- /dev/null
+++ b/drivers/misc/ti-st/st_core.c
@@ -0,0 +1,1057 @@
+/*
+ *  Shared Transport Line discipline driver Core
+ *	This hooks up ST KIM driver and ST LL driver
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/tty.h>
+
+/* understand BT, FM and GPS for now */
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+#include <net/bluetooth/hci.h>
+#include "fm.h"
+/*
+ * packet formats for fm and gps
+ * #include "gps.h"
+ */
+#include "st_core.h"
+#include "st_kim.h"
+#include "st_ll.h"
+#include "st.h"
+
+/* all debug macros go in here */
+#define ST_DRV_ERR(fmt, arg...)  printk(KERN_ERR "(stc):"fmt"\n" , ## arg)
+#if defined(DEBUG)		/* limited debug messages */
+#define ST_DRV_DBG(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
+#define ST_DRV_VER(fmt, arg...)
+#elif defined(VERBOSE)		/* very verbose */
+#define ST_DRV_DBG(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
+#define ST_DRV_VER(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
+#else /* error msgs only */
+#define ST_DRV_DBG(fmt, arg...)
+#define ST_DRV_VER(fmt, arg...)
+#endif
+
+#ifdef DEBUG
+/* strings to be used for rfkill entries and by
+ * ST Core to be used for sysfs debug entry
+ */
+#define PROTO_ENTRY(type, name)	name
+const unsigned char *protocol_strngs[] = {
+	PROTO_ENTRY(ST_BT, "Bluetooth"),
+	PROTO_ENTRY(ST_FM, "FM"),
+	PROTO_ENTRY(ST_GPS, "GPS"),
+};
+#endif
+/*
+ * local data instances
+ */
+static struct st_data_s *st_gdata;
+/* function pointer pointing to either,
+ * st_kim_recv during registration to receive fw download responses
+ * st_int_recv after registration to receive proto stack responses
+ */
+void (*st_recv) (const unsigned char *data, long count);
+
+/********************************************************************/
+/* internal misc functions */
+bool is_protocol_list_empty(void)
+{
+	unsigned char i = 0;
+	ST_DRV_DBG(" %s ", __func__);
+	for (i = 0; i < ST_MAX; i++) {
+		if (st_gdata->list[i] != NULL)
+			return ST_NOTEMPTY;
+		/* not empty */
+	}
+	/* list empty */
+	return ST_EMPTY;
+}
+
+/* can be called in from
+ * -- KIM (during fw download)
+ * -- ST Core (during st_write)
+ *
+ *  This is the internal write function - a wrapper
+ *  to tty->ops->write
+ */
+int st_int_write(const unsigned char *data, int count)
+{
+#ifdef VERBOSE			/* for debug */
+	int i;
+#endif
+	struct tty_struct *tty;
+	if (unlikely(st_gdata == NULL || st_gdata->tty == NULL)) {
+		ST_DRV_ERR("tty unavailable to perform write");
+		return ST_ERR_FAILURE;
+	}
+	tty = st_gdata->tty;
+#ifdef VERBOSE
+	printk(KERN_ERR "start data..\n");
+	for (i = 0; i < count; i++)	/* no newlines for each datum */
+		printk(" %x", data[i]);
+	printk(KERN_ERR "\n ..end data\n");
+#endif
+
+	return tty->ops->write(tty, data, count);
+
+}
+
+/*
+ * push the skb received to relevant
+ * protocol stacks
+ */
+void st_send_frame(enum proto_type protoid, struct sk_buff *skb)
+{
+	ST_DRV_DBG(" %s(prot:%d) ", __func__, protoid);
+
+	if (unlikely
+	    (st_gdata == NULL || skb == NULL
+	     || st_gdata->list[protoid] == NULL)) {
+		ST_DRV_ERR("protocol %d not registered, no data to send?",
+			   protoid);
+		kfree_skb(skb);
+		return;
+	}
+	/* this cannot fail
+	 * this shouldn't take long
+	 * - should be just skb_queue_tail for the
+	 *   protocol stack driver
+	 */
+	if (likely(st_gdata->list[protoid]->recv != NULL)) {
+		if (unlikely(st_gdata->list[protoid]->recv(skb)
+			     != ST_SUCCESS)) {
+			ST_DRV_ERR(" proto stack %d's ->recv failed", protoid);
+			kfree_skb(skb);
+			return;
+		}
+	} else {
+		ST_DRV_ERR(" proto stack %d's ->recv null", protoid);
+		kfree_skb(skb);
+	}
+	ST_DRV_DBG(" done %s", __func__);
+	return;
+}
+
+/*
+ * to call registration complete callbacks
+ * of all protocol stack drivers
+ */
+void st_reg_complete(char err)
+{
+	unsigned char i = 0;
+	ST_DRV_DBG(" %s ", __func__);
+	for (i = 0; i < ST_MAX; i++) {
+		if (likely(st_gdata != NULL && st_gdata->list[i] != NULL &&
+			   st_gdata->list[i]->reg_complete_cb != NULL))
+			st_gdata->list[i]->reg_complete_cb(err);
+	}
+}
+
+static inline int st_check_data_len(int protoid, int len)
+{
+	register int room = skb_tailroom(st_gdata->rx_skb);
+
+	ST_DRV_DBG("len %d room %d", len, room);
+
+	if (!len) {
+		/* Received packet has only packet header and
+		 * has zero length payload. So, ask ST CORE to
+		 * forward the packet to protocol driver (BT/FM/GPS)
+		 */
+		st_send_frame(protoid, st_gdata->rx_skb);
+
+	} else if (len > room) {
+		/* Received packet's payload length is larger.
+		 * We can't accommodate it in created skb.
+		 */
+		ST_DRV_ERR("Data length is too large len %d room %d", len,
+			   room);
+		kfree_skb(st_gdata->rx_skb);
+	} else {
+		/* Packet header has non-zero payload length and
+		 * we have enough space in created skb. Lets read
+		 * payload data */
+		st_gdata->rx_state = ST_BT_W4_DATA;
+		st_gdata->rx_count = len;
+		return len;
+	}
+
+	/* Change ST state to continue to process next
+	 * packet */
+	st_gdata->rx_state = ST_W4_PACKET_TYPE;
+	st_gdata->rx_skb = NULL;
+	st_gdata->rx_count = 0;
+
+	return 0;
+}
+
+/* internal function for action when wake-up ack
+ * received
+ */
+static inline void st_wakeup_ack(unsigned char cmd)
+{
+	register struct sk_buff *waiting_skb;
+	unsigned long flags = 0;
+
+	spin_lock_irqsave(&st_gdata->lock, flags);
+	/* de-Q from waitQ and Q in txQ now that the
+	 * chip is awake
+	 */
+	while ((waiting_skb = skb_dequeue(&st_gdata->tx_waitq)))
+		skb_queue_tail(&st_gdata->txq, waiting_skb);
+
+	/* state forwarded to ST LL */
+	st_ll_sleep_state((unsigned long)cmd);
+	spin_unlock_irqrestore(&st_gdata->lock, flags);
+
+	/* wake up to send the recently copied skbs from waitQ */
+	st_tx_wakeup(st_gdata);
+}
+
+/* Decodes received RAW data and forwards to corresponding
+ * client drivers (Bluetooth,FM,GPS..etc).
+ *
+ */
+void st_int_recv(const unsigned char *data, long count)
+{
+	register char *ptr;
+	struct hci_event_hdr *eh;
+	struct hci_acl_hdr *ah;
+	struct hci_sco_hdr *sh;
+	struct fm_event_hdr *fm;
+	struct gps_event_hdr *gps;
+	register int len = 0, type = 0, dlen = 0;
+	static enum proto_type protoid = ST_MAX;
+
+	ST_DRV_DBG("count %ld rx_state %ld"
+		   "rx_count %ld", count, st_gdata->rx_state,
+		   st_gdata->rx_count);
+
+	ptr = (char *)data;
+	/* tty_receive sent null ? */
+	if (unlikely(ptr == NULL)) {
+		ST_DRV_ERR(" received null from TTY ");
+		return;
+	}
+
+	/* Decode received bytes here */
+	while (count) {
+		if (st_gdata->rx_count) {
+			len = min_t(unsigned int, st_gdata->rx_count, count);
+			memcpy(skb_put(st_gdata->rx_skb, len), ptr, len);
+			st_gdata->rx_count -= len;
+			count -= len;
+			ptr += len;
+
+			if (st_gdata->rx_count)
+				continue;
+
+			/* Check ST RX state machine , where are we? */
+			switch (st_gdata->rx_state) {
+
+				/* Waiting for complete packet ? */
+			case ST_BT_W4_DATA:
+				ST_DRV_DBG("Complete pkt received");
+
+				/* Ask ST CORE to forward
+				 * the packet to protocol driver */
+				st_send_frame(protoid, st_gdata->rx_skb);
+
+				st_gdata->rx_state = ST_W4_PACKET_TYPE;
+				st_gdata->rx_skb = NULL;
+				protoid = ST_MAX;	/* is this required ? */
+				continue;
+
+				/* Waiting for Bluetooth event header ? */
+			case ST_BT_W4_EVENT_HDR:
+				eh = (struct hci_event_hdr *)st_gdata->rx_skb->
+				    data;
+
+				ST_DRV_DBG("Event header: evt 0x%2.2x"
+					   "plen %d", eh->evt, eh->plen);
+
+				st_check_data_len(protoid, eh->plen);
+				continue;
+
+				/* Waiting for Bluetooth acl header ? */
+			case ST_BT_W4_ACL_HDR:
+				ah = (struct hci_acl_hdr *)st_gdata->rx_skb->
+				    data;
+				dlen = __le16_to_cpu(ah->dlen);
+
+				ST_DRV_DBG("ACL header: dlen %d", dlen);
+
+				st_check_data_len(protoid, dlen);
+				continue;
+
+				/* Waiting for Bluetooth sco header ? */
+			case ST_BT_W4_SCO_HDR:
+				sh = (struct hci_sco_hdr *)st_gdata->rx_skb->
+				    data;
+
+				ST_DRV_DBG("SCO header: dlen %d", sh->dlen);
+
+				st_check_data_len(protoid, sh->dlen);
+				continue;
+			case ST_FM_W4_EVENT_HDR:
+				fm = (struct fm_event_hdr *)st_gdata->rx_skb->
+				    data;
+				ST_DRV_DBG("FM Header: ");
+				st_check_data_len(ST_FM, fm->plen);
+				continue;
+				/* TODO : Add GPS packet machine logic here */
+			case ST_GPS_W4_EVENT_HDR:
+				/* [0x09 pkt hdr][R/W byte][2 byte len] */
+				gps = (struct gps_event_hdr *)st_gdata->rx_skb->
+				     data;
+				ST_DRV_DBG("GPS Header: ");
+				st_check_data_len(ST_GPS, gps->plen);
+				continue;
+			}	/* end of switch rx_state */
+		}
+
+		/* end of if rx_count */
+		/* Check first byte of packet and identify module
+		 * owner (BT/FM/GPS) */
+		switch (*ptr) {
+
+			/* Bluetooth event packet? */
+		case HCI_EVENT_PKT:
+			ST_DRV_DBG("Event packet");
+			st_gdata->rx_state = ST_BT_W4_EVENT_HDR;
+			st_gdata->rx_count = HCI_EVENT_HDR_SIZE;
+			type = HCI_EVENT_PKT;
+			protoid = ST_BT;
+			break;
+
+			/* Bluetooth acl packet? */
+		case HCI_ACLDATA_PKT:
+			ST_DRV_DBG("ACL packet");
+			st_gdata->rx_state = ST_BT_W4_ACL_HDR;
+			st_gdata->rx_count = HCI_ACL_HDR_SIZE;
+			type = HCI_ACLDATA_PKT;
+			protoid = ST_BT;
+			break;
+
+			/* Bluetooth sco packet? */
+		case HCI_SCODATA_PKT:
+			ST_DRV_DBG("SCO packet");
+			st_gdata->rx_state = ST_BT_W4_SCO_HDR;
+			st_gdata->rx_count = HCI_SCO_HDR_SIZE;
+			type = HCI_SCODATA_PKT;
+			protoid = ST_BT;
+			break;
+
+			/* Channel 8(FM) packet? */
+		case ST_FM_CH8_PKT:
+			ST_DRV_DBG("FM CH8 packet");
+			type = ST_FM_CH8_PKT;
+			st_gdata->rx_state = ST_FM_W4_EVENT_HDR;
+			st_gdata->rx_count = FM_EVENT_HDR_SIZE;
+			protoid = ST_FM;
+			break;
+
+			/* Channel 9(GPS) packet? */
+		case 0x9:	/*ST_LL_GPS_CH9_PKT */
+			ST_DRV_DBG("GPS CH9 packet");
+			type = 0x9;	/* ST_LL_GPS_CH9_PKT; */
+			protoid = ST_GPS;
+			st_gdata->rx_state = ST_GPS_W4_EVENT_HDR;
+			st_gdata->rx_count = 3;	/* GPS_EVENT_HDR_SIZE -1*/
+			break;
+		case LL_SLEEP_IND:
+		case LL_SLEEP_ACK:
+		case LL_WAKE_UP_IND:
+			/* this takes appropriate action based on
+			 * sleep state received --
+			 */
+			st_ll_sleep_state(*ptr);
+			ptr++;
+			count--;
+			continue;
+		case LL_WAKE_UP_ACK:
+			/* wake up ack received */
+			st_wakeup_ack(*ptr);
+			ptr++;
+			count--;
+			continue;
+			/* Unknow packet? */
+		default:
+			ST_DRV_ERR("Unknown packet type %2.2x", (__u8) *ptr);
+			ptr++;
+			count--;
+			continue;
+		};
+		ptr++;
+		count--;
+
+		switch (protoid) {
+		case ST_BT:
+			/* Allocate new packet to hold received data */
+			st_gdata->rx_skb =
+			    bt_skb_alloc(HCI_MAX_FRAME_SIZE, GFP_ATOMIC);
+			if (!st_gdata->rx_skb) {
+				ST_DRV_ERR("Can't allocate mem for new packet");
+				st_gdata->rx_state = ST_W4_PACKET_TYPE;
+				st_gdata->rx_count = 0;
+				return;
+			}
+			bt_cb(st_gdata->rx_skb)->pkt_type = type;
+			break;
+		case ST_FM:	/* for FM */
+			st_gdata->rx_skb =
+			    alloc_skb(FM_MAX_FRAME_SIZE, GFP_ATOMIC);
+			if (!st_gdata->rx_skb) {
+				ST_DRV_ERR("Can't allocate mem for new packet");
+				st_gdata->rx_state = ST_W4_PACKET_TYPE;
+				st_gdata->rx_count = 0;
+				return;
+			}
+			/* place holder 0x08 */
+			skb_reserve(st_gdata->rx_skb, 1);
+			st_gdata->rx_skb->cb[0] = ST_FM_CH8_PKT;
+			break;
+		case ST_GPS:
+			/* for GPS */
+			st_gdata->rx_skb =
+			    alloc_skb(100 /*GPS_MAX_FRAME_SIZE */ , GFP_ATOMIC);
+			if (!st_gdata->rx_skb) {
+				ST_DRV_ERR("Can't allocate mem for new packet");
+				st_gdata->rx_state = ST_W4_PACKET_TYPE;
+				st_gdata->rx_count = 0;
+				return;
+			}
+			/* place holder 0x09 */
+			skb_reserve(st_gdata->rx_skb, 1);
+			st_gdata->rx_skb->cb[0] = 0x09;	/*ST_GPS_CH9_PKT; */
+			break;
+		case ST_MAX:
+			break;
+		}
+	}
+	ST_DRV_DBG("done %s", __func__);
+	return;
+}
+
+/* internal de-Q function
+ * -- return previous in-completely written skb
+ *  or return the skb in the txQ
+ */
+struct sk_buff *st_int_dequeue(struct st_data_s *st_data)
+{
+	struct sk_buff *returning_skb;
+
+	ST_DRV_VER("%s", __func__);
+	/* if the previous skb wasn't written completely
+	 */
+	if (st_gdata->tx_skb != NULL) {
+		returning_skb = st_gdata->tx_skb;
+		st_gdata->tx_skb = NULL;
+		return returning_skb;
+	}
+
+	/* de-Q from the txQ always if previous write is complete */
+	return skb_dequeue(&st_gdata->txq);
+}
+
+/* internal Q-ing function
+ * will either Q the skb to txq or the tx_waitq
+ * depending on the ST LL state
+ *
+ * lock the whole func - since ll_getstate and Q-ing should happen
+ * in one-shot
+ */
+void st_int_enqueue(struct sk_buff *skb)
+{
+	unsigned long flags = 0;
+
+	ST_DRV_VER("%s", __func__);
+	/* this function can be invoked in more then one context.
+	 * so have a lock */
+	spin_lock_irqsave(&st_gdata->lock, flags);
+
+	switch (st_ll_getstate()) {
+	case ST_LL_AWAKE:
+		ST_DRV_DBG("ST LL is AWAKE, sending normally");
+		skb_queue_tail(&st_gdata->txq, skb);
+		break;
+	case ST_LL_ASLEEP_TO_AWAKE:
+		skb_queue_tail(&st_gdata->tx_waitq, skb);
+		break;
+	case ST_LL_AWAKE_TO_ASLEEP:	/* host cannot be in this state */
+		ST_DRV_ERR("ST LL is illegal state(%ld),"
+			   "purging received skb.", st_ll_getstate());
+		kfree_skb(skb);
+		break;
+
+	case ST_LL_ASLEEP:
+		/* call a function of ST LL to put data
+		 * in tx_waitQ and wake_ind in txQ
+		 */
+		skb_queue_tail(&st_gdata->tx_waitq, skb);
+		st_ll_wakeup();
+		break;
+	default:
+		ST_DRV_ERR("ST LL is illegal state(%ld),"
+			   "purging received skb.", st_ll_getstate());
+		kfree_skb(skb);
+		break;
+	}
+	spin_unlock_irqrestore(&st_gdata->lock, flags);
+	ST_DRV_VER("done %s", __func__);
+	return;
+}
+
+/*
+ * internal wakeup function
+ * called from either
+ * - TTY layer when write's finished
+ * - st_write (in context of the protocol stack)
+ */
+void st_tx_wakeup(struct st_data_s *st_data)
+{
+	struct sk_buff *skb;
+	unsigned long flags;	/* for irq save flags */
+	ST_DRV_VER("%s", __func__);
+	/* check for sending & set flag sending here */
+	if (test_and_set_bit(ST_TX_SENDING, &st_data->tx_state)) {
+		ST_DRV_DBG("ST already sending");
+		/* keep sending */
+		set_bit(ST_TX_WAKEUP, &st_data->tx_state);
+		return;
+		/* TX_WAKEUP will be checked in another
+		 * context
+		 */
+	}
+	do {			/* come back if st_tx_wakeup is set */
+		/* woke-up to write */
+		clear_bit(ST_TX_WAKEUP, &st_data->tx_state);
+		while ((skb = st_int_dequeue(st_data))) {
+			int len;
+			spin_lock_irqsave(&st_data->lock, flags);
+			/* enable wake-up from TTY */
+			set_bit(TTY_DO_WRITE_WAKEUP, &st_data->tty->flags);
+			len = st_int_write(skb->data, skb->len);
+			skb_pull(skb, len);
+			/* if skb->len = len as expected, skb->len=0 */
+			if (skb->len) {
+				/* would be the next skb to be sent */
+				st_data->tx_skb = skb;
+				spin_unlock_irqrestore(&st_gdata->lock, flags);
+				break;
+			}
+			kfree_skb(skb);
+			spin_unlock_irqrestore(&st_gdata->lock, flags);
+		}
+		/* if wake-up is set in another context- restart sending */
+	} while (test_bit(ST_TX_WAKEUP, &st_data->tx_state));
+
+	/* clear flag sending */
+	clear_bit(ST_TX_SENDING, &st_data->tx_state);
+}
+
+/********************************************************************/
+/* functions called from ST KIM
+*/
+void kim_st_list_protocols(char *buf)
+{
+	unsigned long flags = 0;
+#ifdef DEBUG
+	unsigned char i = ST_MAX;
+#endif
+	spin_lock_irqsave(&st_gdata->lock, flags);
+#ifdef DEBUG			/* more detailed log */
+	for (i = 0; i < ST_MAX; i++) {
+		if (i == 0) {
+			sprintf(buf, "%s is %s", protocol_strngs[i],
+				st_gdata->list[i] !=
+				NULL ? "Registered" : "Unregistered");
+		} else {
+			sprintf(buf, "%s\n%s is %s", buf, protocol_strngs[i],
+				st_gdata->list[i] !=
+				NULL ? "Registered" : "Unregistered");
+		}
+	}
+	sprintf(buf, "%s\n", buf);
+#else /* limited info */
+	sprintf(buf, "BT=%c\nFM=%c\nGPS=%c\n",
+		st_gdata->list[ST_BT] != NULL ? 'R' : 'U',
+		st_gdata->list[ST_FM] != NULL ? 'R' : 'U',
+		st_gdata->list[ST_GPS] != NULL ? 'R' : 'U');
+#endif
+	spin_unlock_irqrestore(&st_gdata->lock, flags);
+}
+
+/********************************************************************/
+/*
+ * functions called from protocol stack drivers
+ * to be EXPORT-ed
+ */
+long st_register(struct st_proto_s *new_proto)
+{
+	long err = ST_SUCCESS;
+	unsigned long flags = 0;
+
+	ST_DRV_DBG("%s(%d) ", __func__, new_proto->type);
+	if (st_gdata == NULL || new_proto == NULL || new_proto->recv == NULL
+	    || new_proto->reg_complete_cb == NULL) {
+		ST_DRV_ERR("gdata/new_proto/recv or reg_complete_cb not ready");
+		return ST_ERR_FAILURE;
+	}
+
+	if (new_proto->type < ST_BT || new_proto->type >= ST_MAX) {
+		ST_DRV_ERR("protocol %d not supported", new_proto->type);
+		return ST_ERR_NOPROTO;
+	}
+
+	if (st_gdata->list[new_proto->type] != NULL) {
+		ST_DRV_ERR("protocol %d already registered", new_proto->type);
+		return ST_ERR_ALREADY;
+	}
+
+	/* can be from process context only */
+	spin_lock_irqsave(&st_gdata->lock, flags);
+
+	if (test_bit(ST_REG_IN_PROGRESS, &st_gdata->st_state)) {
+		ST_DRV_DBG(" ST_REG_IN_PROGRESS:%d ", new_proto->type);
+		/* fw download in progress */
+		st_kim_chip_toggle(new_proto->type, KIM_GPIO_ACTIVE);
+
+		st_gdata->list[new_proto->type] = new_proto;
+		new_proto->write = st_write;
+
+		set_bit(ST_REG_PENDING, &st_gdata->st_state);
+		spin_unlock_irqrestore(&st_gdata->lock, flags);
+		return ST_ERR_PENDING;
+	} else if (is_protocol_list_empty() == ST_EMPTY) {
+		ST_DRV_DBG(" protocol list empty :%d ", new_proto->type);
+		set_bit(ST_REG_IN_PROGRESS, &st_gdata->st_state);
+		st_recv = st_kim_recv;
+
+		/* release lock previously held - re-locked below */
+		spin_unlock_irqrestore(&st_gdata->lock, flags);
+
+		/* enable the ST LL - to set default chip state */
+		st_ll_enable();
+		/* this may take a while to complete
+		 * since it involves BT fw download
+		 */
+		err = st_kim_start();
+		if (err != ST_SUCCESS) {
+			clear_bit(ST_REG_IN_PROGRESS, &st_gdata->st_state);
+			if ((is_protocol_list_empty() != ST_EMPTY) &&
+			    (test_bit(ST_REG_PENDING, &st_gdata->st_state))) {
+				ST_DRV_ERR(" KIM failure complete callback ");
+				st_reg_complete(ST_ERR_FAILURE);
+			}
+
+			return ST_ERR_FAILURE;
+		}
+
+		/* the protocol might require other gpios to be toggled
+		 */
+		st_kim_chip_toggle(new_proto->type, KIM_GPIO_ACTIVE);
+
+		clear_bit(ST_REG_IN_PROGRESS, &st_gdata->st_state);
+		st_recv = st_int_recv;
+
+		/* this is where all pending registration
+		 * are signalled to be complete by calling callback functions
+		 */
+		if ((is_protocol_list_empty() != ST_EMPTY) &&
+		    (test_bit(ST_REG_PENDING, &st_gdata->st_state))) {
+			ST_DRV_VER(" call reg complete callback ");
+			st_reg_complete(ST_SUCCESS);
+		}
+		clear_bit(ST_REG_PENDING, &st_gdata->st_state);
+
+		/* check for already registered once more,
+		 * since the above check is old
+		 */
+		if (st_gdata->list[new_proto->type] != NULL) {
+			ST_DRV_ERR(" proto %d already registered ",
+				   new_proto->type);
+			return ST_ERR_ALREADY;
+		}
+
+		spin_lock_irqsave(&st_gdata->lock, flags);
+		st_gdata->list[new_proto->type] = new_proto;
+		new_proto->write = st_write;
+		spin_unlock_irqrestore(&st_gdata->lock, flags);
+		return err;
+	}
+	/* if fw is already downloaded & new stack registers protocol */
+	else {
+		switch (new_proto->type) {
+		case ST_BT:
+			/* do nothing */
+			break;
+		case ST_FM:
+		case ST_GPS:
+			st_kim_chip_toggle(new_proto->type, KIM_GPIO_ACTIVE);
+			break;
+		case ST_MAX:
+		default:
+			ST_DRV_ERR("%d protocol not supported",
+				   new_proto->type);
+			err = ST_ERR_NOPROTO;
+			/* something wrong */
+			break;
+		}
+		st_gdata->list[new_proto->type] = new_proto;
+		new_proto->write = st_write;
+
+		/* lock already held before entering else */
+		spin_unlock_irqrestore(&st_gdata->lock, flags);
+		return err;
+	}
+	ST_DRV_DBG("done %s(%d) ", __func__, new_proto->type);
+}
+EXPORT_SYMBOL_GPL(st_register);
+
+/* to unregister a protocol -
+ * to be called from protocol stack driver
+ */
+long st_unregister(enum proto_type type)
+{
+	long err = ST_SUCCESS;
+	unsigned long flags = 0;
+
+	ST_DRV_DBG("%s: %d ", __func__, type);
+
+	if (type < ST_BT || type >= ST_MAX) {
+		ST_DRV_ERR(" protocol %d not supported", type);
+		return ST_ERR_NOPROTO;
+	}
+
+	spin_lock_irqsave(&st_gdata->lock, flags);
+
+	if (st_gdata->list[type] == NULL) {
+		ST_DRV_ERR(" protocol %d not registered", type);
+		spin_unlock_irqrestore(&st_gdata->lock, flags);
+		return ST_ERR_NOPROTO;
+	}
+
+	st_gdata->list[type] = NULL;
+
+	/* kim ignores BT in the below function
+	 * and handles the rest, BT is toggled
+	 * only in kim_start and kim_stop
+	 */
+	st_kim_chip_toggle(type, KIM_GPIO_INACTIVE);
+	spin_unlock_irqrestore(&st_gdata->lock, flags);
+
+	if ((is_protocol_list_empty() == ST_EMPTY) &&
+	    (!test_bit(ST_REG_PENDING, &st_gdata->st_state))) {
+		ST_DRV_DBG(" all protocols unregistered ");
+
+		/* stop traffic on tty */
+		if (st_gdata->tty) {
+			tty_ldisc_flush(st_gdata->tty);
+			stop_tty(st_gdata->tty);
+		}
+
+		/* all protocols now unregistered */
+		st_kim_stop();
+		/* disable ST LL */
+		st_ll_disable();
+	}
+	return err;
+}
+
+/*
+ * called in protocol stack drivers
+ * via the write function pointer
+ */
+long st_write(struct sk_buff *skb)
+{
+#ifdef DEBUG
+	enum proto_type protoid = ST_MAX;
+#endif
+	long len;
+	struct st_data_s *st_data = st_gdata;
+
+	if (unlikely(skb == NULL || st_gdata == NULL
+		|| st_gdata->tty == NULL)) {
+		ST_DRV_ERR("data/tty unavailable to perform write");
+		return ST_ERR_FAILURE;
+	}
+#ifdef DEBUG			/* open-up skb to read the 1st byte */
+	switch (skb->data[0]) {
+	case HCI_COMMAND_PKT:
+	case HCI_ACLDATA_PKT:
+	case HCI_SCODATA_PKT:
+		protoid = ST_BT;
+		break;
+	case ST_FM_CH8_PKT:
+		protoid = ST_FM;
+		break;
+	case 0x09:
+		protoid = ST_GPS;
+		break;
+	}
+	if (unlikely(st_gdata->list[protoid] == NULL)) {
+		ST_DRV_ERR(" protocol %d not registered, and writing? ",
+			   protoid);
+		return ST_ERR_FAILURE;
+	}
+#endif
+	ST_DRV_DBG("%d to be written", skb->len);
+	len = skb->len;
+
+	/* st_ll to decide where to enqueue the skb */
+	st_int_enqueue(skb);
+	/* wake up */
+	st_tx_wakeup(st_data);
+
+	/* return number of bytes written */
+	return len;
+}
+
+/* for protocols making use of shared transport */
+EXPORT_SYMBOL_GPL(st_unregister);
+
+/********************************************************************/
+/*
+ * functions called from TTY layer
+ */
+static int st_tty_open(struct tty_struct *tty)
+{
+	int err = ST_SUCCESS;
+	ST_DRV_DBG("%s ", __func__);
+
+	st_gdata->tty = tty;
+
+	/* don't do an wakeup for now */
+	clear_bit(TTY_DO_WRITE_WAKEUP, &tty->flags);
+
+	/* mem already allocated
+	 */
+	tty->receive_room = 65536;
+	/* Flush any pending characters in the driver and discipline. */
+	tty_ldisc_flush(tty);
+	tty_driver_flush_buffer(tty);
+	/*
+	 * signal to UIM via KIM that -
+	 * installation of N_TI_SHARED ldisc is complete
+	 */
+	st_kim_complete();
+	ST_DRV_DBG("done %s", __func__);
+	return err;
+}
+
+static void st_tty_close(struct tty_struct *tty)
+{
+	unsigned char i = ST_MAX;
+	unsigned long flags = 0;
+
+	ST_DRV_DBG("%s ", __func__);
+
+	/* TODO:
+	 * if a protocol has been registered & line discipline
+	 * un-installed for some reason - what should be done ?
+	 */
+	spin_lock_irqsave(&st_gdata->lock, flags);
+	for (i = ST_BT; i < ST_MAX; i++) {
+		if (st_gdata->list[i] != NULL)
+			ST_DRV_ERR("%d not un-registered", i);
+		st_gdata->list[i] = NULL;
+	}
+	spin_unlock_irqrestore(&st_gdata->lock, flags);
+	/*
+	 * signal to UIM via KIM that -
+	 * N_TI_SHARED ldisc is un-installed
+	 */
+	st_kim_complete();
+	st_gdata->tty = NULL;
+	/* Flush any pending characters in the driver and discipline. */
+	tty_ldisc_flush(tty);
+	tty_driver_flush_buffer(tty);
+
+	spin_lock_irqsave(&st_gdata->lock, flags);
+	/* empty out txq and tx_waitq */
+	skb_queue_purge(&st_gdata->txq);
+	skb_queue_purge(&st_gdata->tx_waitq);
+	/* reset the TTY Rx states of ST */
+	st_gdata->rx_count = 0;
+	st_gdata->rx_state = ST_W4_PACKET_TYPE;
+	kfree_skb(st_gdata->rx_skb);
+	st_gdata->rx_skb = NULL;
+	spin_unlock_irqrestore(&st_gdata->lock, flags);
+
+	ST_DRV_DBG("%s: done ", __func__);
+}
+
+static void st_tty_receive(struct tty_struct *tty, const unsigned char *data,
+			   char *tty_flags, int count)
+{
+#ifdef VERBOSE
+	long i;
+	printk(KERN_ERR "incoming data...\n");
+	for (i = 0; i < count; i++)
+		printk(" %x", data[i]);
+	printk(KERN_ERR "\n.. data end\n");
+#endif
+
+	/*
+	 * if fw download is in progress then route incoming data
+	 * to KIM for validation
+	 */
+	st_recv(data, count);
+	ST_DRV_VER("done %s", __func__);
+}
+
+/* wake-up function called in from the TTY layer
+ * inside the internal wakeup function will be called
+ */
+static void st_tty_wakeup(struct tty_struct *tty)
+{
+	ST_DRV_DBG("%s ", __func__);
+	/* don't do an wakeup for now */
+	clear_bit(TTY_DO_WRITE_WAKEUP, &tty->flags);
+
+	/* call our internal wakeup */
+	st_tx_wakeup((void *)st_gdata);
+}
+
+static void st_tty_flush_buffer(struct tty_struct *tty)
+{
+	ST_DRV_DBG("%s ", __func__);
+
+	kfree_skb(st_gdata->tx_skb);
+	st_gdata->tx_skb = NULL;
+
+	tty->ops->flush_buffer(tty);
+	return;
+}
+
+/********************************************************************/
+static int __init st_core_init(void)
+{
+	long err;
+	static struct tty_ldisc_ops *st_ldisc_ops;
+
+	/* populate and register to TTY line discipline */
+	st_ldisc_ops = kzalloc(sizeof(*st_ldisc_ops), GFP_KERNEL);
+	if (!st_ldisc_ops) {
+		ST_DRV_ERR("no mem to allocate");
+		return -ENOMEM;
+	}
+
+	st_ldisc_ops->magic = TTY_LDISC_MAGIC;
+	st_ldisc_ops->name = "n_st";	/*"n_hci"; */
+	st_ldisc_ops->open = st_tty_open;
+	st_ldisc_ops->close = st_tty_close;
+	st_ldisc_ops->receive_buf = st_tty_receive;
+	st_ldisc_ops->write_wakeup = st_tty_wakeup;
+	st_ldisc_ops->flush_buffer = st_tty_flush_buffer;
+	st_ldisc_ops->owner = THIS_MODULE;
+
+	err = tty_register_ldisc(N_TI_SHARED, st_ldisc_ops);
+	if (err) {
+		ST_DRV_ERR("error registering %d line discipline %ld",
+			   N_TI_SHARED, err);
+		kfree(st_ldisc_ops);
+		return err;
+	}
+	ST_DRV_DBG("registered n_shared line discipline");
+
+	st_gdata = kzalloc(sizeof(struct st_data_s), GFP_KERNEL);
+	if (!st_gdata) {
+		ST_DRV_ERR("memory allocation failed");
+		err = tty_unregister_ldisc(N_TI_SHARED);
+		if (err)
+			ST_DRV_ERR("unable to un-register ldisc %ld", err);
+		kfree(st_ldisc_ops);
+		err = -ENOMEM;
+		return err;
+	}
+
+	/* Initialize ST TxQ and Tx waitQ queue head. All BT/FM/GPS module skb's
+	 * will be pushed in this queue for actual transmission.
+	 */
+	skb_queue_head_init(&st_gdata->txq);
+	skb_queue_head_init(&st_gdata->tx_waitq);
+
+	/* Locking used in st_int_enqueue() to avoid multiple execution */
+	spin_lock_init(&st_gdata->lock);
+
+	/* ldisc_ops ref to be only used in __exit of module */
+	st_gdata->ldisc_ops = st_ldisc_ops;
+
+	err = st_kim_init();
+	if (err) {
+		ST_DRV_ERR("error during kim initialization(%ld)", err);
+		kfree(st_gdata);
+		err = tty_unregister_ldisc(N_TI_SHARED);
+		if (err)
+			ST_DRV_ERR("unable to un-register ldisc");
+		kfree(st_ldisc_ops);
+		return -1;
+	}
+
+	err = st_ll_init();
+	if (err) {
+		ST_DRV_ERR("error during st_ll initialization(%ld)", err);
+		err = st_kim_deinit();
+		kfree(st_gdata);
+		err = tty_unregister_ldisc(N_TI_SHARED);
+		if (err)
+			ST_DRV_ERR("unable to un-register ldisc");
+		kfree(st_ldisc_ops);
+		return -1;
+	}
+	return 0;
+}
+
+static void __exit st_core_exit(void)
+{
+	long err;
+	/* internal module cleanup */
+	err = st_ll_deinit();
+	if (err)
+		ST_DRV_ERR("error during deinit of ST LL %ld", err);
+	err = st_kim_deinit();
+	if (err)
+		ST_DRV_ERR("error during deinit of ST KIM %ld", err);
+
+	if (st_gdata != NULL) {
+		/* Free ST Tx Qs and skbs */
+		skb_queue_purge(&st_gdata->txq);
+		skb_queue_purge(&st_gdata->tx_waitq);
+		kfree_skb(st_gdata->rx_skb);
+		kfree_skb(st_gdata->tx_skb);
+		/* TTY ldisc cleanup */
+		err = tty_unregister_ldisc(N_TI_SHARED);
+		if (err)
+			ST_DRV_ERR("unable to un-register ldisc %ld", err);
+		kfree(st_gdata->ldisc_ops);
+		/* free the global data pointer */
+		kfree(st_gdata);
+	}
+}
+
+module_init(st_core_init);
+module_exit(st_core_exit);
+MODULE_AUTHOR("Pavan Savoy <pavan_savoy@ti.com>");
+MODULE_DESCRIPTION("Shared Transport Driver for TI BT/FM/GPS combo chips ");
+MODULE_LICENSE("GPL");
diff --git a/drivers/misc/ti-st/st_core.h b/drivers/misc/ti-st/st_core.h
new file mode 100644
index 0000000..ff0d9d1
--- /dev/null
+++ b/drivers/misc/ti-st/st_core.h
@@ -0,0 +1,92 @@
+/*
+ *  Shared Transport Core header file
+ *
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#ifndef ST_CORE_H
+#define ST_CORE_H
+
+#include <linux/skbuff.h>
+#include "st.h"
+
+/* states of protocol list */
+#define ST_NOTEMPTY	1
+#define ST_EMPTY	0
+
+/*
+ * possible st_states
+ */
+#define ST_INITIALIZING		1
+#define ST_REG_IN_PROGRESS	2
+#define ST_REG_PENDING		3
+#define ST_WAITING_FOR_RESP	4
+
+/*
+ * local data required for ST/KIM/ST-HCI-LL
+ */
+struct st_data_s {
+	unsigned long st_state;
+/*
+ * an instance of tty_struct & ldisc ops to move around
+ */
+	struct tty_struct *tty;
+	struct tty_ldisc_ops *ldisc_ops;
+/*
+ * the tx skb -
+ * if the skb is already dequeued and the tty failed to write the same
+ * maintain the skb to write in the next transaction
+ */
+	struct sk_buff *tx_skb;
+#define ST_TX_SENDING	1
+#define ST_TX_WAKEUP	2
+	unsigned long tx_state;
+/*
+ * list of protocol registered
+ */
+	struct st_proto_s *list[ST_MAX];
+/*
+ * lock
+ */
+	unsigned long rx_state;
+	unsigned long rx_count;
+	struct sk_buff *rx_skb;
+	struct sk_buff_head txq, tx_waitq;
+	spinlock_t lock;	/* ST LL state lock  */
+};
+
+/* point this to tty->driver->write or tty->ops->write
+ * depending upon the kernel version
+ */
+int st_int_write(const unsigned char *, int);
+/* internal write function, passed onto protocol drivers
+ * via the write function ptr of protocol struct
+ */
+long st_write(struct sk_buff *);
+/* function to be called from ST-LL
+ */
+void st_ll_send_frame(enum proto_type, struct sk_buff *);
+/* internal wake up function */
+void st_tx_wakeup(struct st_data_s *st_data);
+
+#define GPS_STUB_TEST
+#ifdef GPS_STUB_TEST
+int gps_chrdrv_stub_write(const unsigned char*, int);
+void gps_chrdrv_stub_init(void);
+#endif
+
+#endif /*ST_CORE_H */
-- 
1.5.4.3

[PATCH 4/6] drivers:misc: sources for Init manager module

[pavan_savoy]

From: Pavan Savoy <pavan_savoy@ti.com>

Kernel Space Init-Manager works along with User-Mode
Init Manager daemon running to maintain the UART state.
It also is a platform driver with a relevant platform device
in the board-*.c along with the list of BT/FM/GPS chip enable
gpio configuration

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 drivers/misc/ti-st/st_kim.c |  717 +++++++++++++++++++++++++++++++++++++++++++
 drivers/misc/ti-st/st_kim.h |  151 +++++++++
 2 files changed, 868 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/ti-st/st_kim.c
 create mode 100644 drivers/misc/ti-st/st_kim.h

diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
new file mode 100644
index 0000000..20d6927
--- /dev/null
+++ b/drivers/misc/ti-st/st_kim.c
@@ -0,0 +1,717 @@
+/*
+ *  Shared Transport Line discipline driver Core
+ *	Init Manager module responsible for GPIO control
+ *	and firmware download
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include <linux/platform_device.h>
+#include <linux/jiffies.h>
+#include <linux/firmware.h>
+#include <linux/delay.h>
+#include <linux/wait.h>
+#include <linux/gpio.h>
+
+#include <linux/sched.h>
+
+#include "st_kim.h"
+/* understand BT events for fw response */
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+#include <net/bluetooth/hci.h>
+
+/* all debug macros go in here */
+#define ST_KIM_ERR(fmt, arg...)  printk(KERN_ERR "(stk):"fmt"\n" , ## arg)
+#if defined(DEBUG)		/* limited debug messages */
+#define ST_KIM_DBG(fmt, arg...)  printk(KERN_INFO "(stk):"fmt"\n" , ## arg)
+#define ST_KIM_VER(fmt, arg...)
+#elif defined(VERBOSE)		/* very verbose */
+#define ST_KIM_DBG(fmt, arg...)  printk(KERN_INFO "(stk):"fmt"\n" , ## arg)
+#define ST_KIM_VER(fmt, arg...)  printk(KERN_INFO "(stk):"fmt"\n" , ## arg)
+#else /* error msgs only */
+#define ST_KIM_DBG(fmt, arg...)
+#define ST_KIM_VER(fmt, arg...)
+#endif
+
+static int kim_probe(struct platform_device *pdev);
+static int kim_remove(struct platform_device *pdev);
+static ssize_t show_pid(struct device *dev, struct device_attribute
+			*attr, char *buf);
+static ssize_t store_pid(struct device *dev, struct device_attribute
+			 *devattr, char *buf, size_t count);
+static ssize_t show_list(struct device *dev, struct device_attribute
+			 *attr, char *buf);
+/* KIM platform device driver structure */
+static struct platform_driver kim_platform_driver = {
+	.probe = kim_probe,
+	.remove = kim_remove,
+	/* TODO: ST driver power management during suspend/resume ?
+	 */
+#if 0
+	.suspend = kim_suspend,
+	.resume = kim_resume,
+#endif
+	.driver = {
+		   .name = "kim",
+		   .owner = THIS_MODULE,
+		   },
+};
+
+/* structures specific for sysfs entries */
+static struct kobj_attribute pid_attr =
+__ATTR(pid, 0644, (void *)show_pid, (void *)store_pid);
+
+static struct kobj_attribute list_protocols =
+__ATTR(protocols, 0444, (void *)show_list, NULL);
+
+static struct attribute *uim_attrs[] = {
+	&pid_attr.attr,
+	/* add more debug sysfs entries */
+	&list_protocols.attr,
+	NULL,
+};
+
+static struct attribute_group uim_attr_grp = {
+	.attrs = uim_attrs,
+};
+
+/* strings to be used for rfkill entries and by
+ * ST Core to be used for sysfs debug entry
+ */
+#define PROTO_ENTRY(type, name)	name
+const unsigned char *protocol_names[] = {
+	PROTO_ENTRY(ST_BT, "Bluetooth"),
+	PROTO_ENTRY(ST_FM, "FM"),
+	PROTO_ENTRY(ST_GPS, "GPS"),
+};
+static int kim_toggle_radio(void*, bool);
+static const struct rfkill_ops kim_rfkill_ops = {
+	.set_block = kim_toggle_radio,
+};
+
+static struct kim_data_s *kim_gdata;
+
+/**********************************************************************/
+/* internal functions */
+
+/*
+ * function to return whether the firmware response was proper
+ * in case of error don't complete so that waiting for proper
+ * response times out
+ */
+void validate_firmware_response(struct sk_buff *skb)
+{
+	if (unlikely(skb->data[5] != 0)) {
+		ST_KIM_ERR("no proper response during fw download");
+		ST_KIM_ERR("data6 %x", skb->data[5]);
+		return;		/* keep waiting for the proper response */
+	}
+	/* becos of all the script being downloaded */
+	complete_all(&kim_gdata->kim_rcvd);
+	kfree_skb(skb);
+}
+
+/* check for data len received inside kim_int_recv
+ * most often hit the last case to update state to waiting for data
+ */
+static inline int kim_check_data_len(int len)
+{
+	register int room = skb_tailroom(kim_gdata->rx_skb);
+
+	ST_KIM_DBG("len %d room %d", len, room);
+
+	if (!len) {
+		validate_firmware_response(kim_gdata->rx_skb);
+	} else if (len > room) {
+		/* Received packet's payload length is larger.
+		 * We can't accommodate it in created skb.
+		 */
+		ST_KIM_ERR("Data length is too large len %d room %d", len,
+			   room);
+		kfree_skb(kim_gdata->rx_skb);
+	} else {
+		/* Packet header has non-zero payload length and
+		 * we have enough space in created skb. Lets read
+		 * payload data */
+		kim_gdata->rx_state = ST_BT_W4_DATA;
+		kim_gdata->rx_count = len;
+		return len;
+	}
+
+	/* Change ST LL state to continue to process next
+	 * packet */
+	kim_gdata->rx_state = ST_W4_PACKET_TYPE;
+	kim_gdata->rx_skb = NULL;
+	kim_gdata->rx_count = 0;
+
+	return 0;
+}
+
+/* receive function called during firmware download
+ * - firmware download responses on different UART drivers
+ *   have been observed to come in bursts of different
+ *   tty_receive and hence the logic
+ */
+void kim_int_recv(const unsigned char *data, long count)
+{
+	register char *ptr;
+	struct hci_event_hdr *eh;
+	register int len = 0, type = 0;
+
+	ST_KIM_DBG("%s", __func__);
+	/* Decode received bytes here */
+	ptr = (char *)data;
+	if (unlikely(ptr == NULL)) {
+		ST_KIM_ERR(" received null from TTY ");
+		return;
+	}
+	while (count) {
+		if (kim_gdata->rx_count) {
+			len = min_t(unsigned int, kim_gdata->rx_count, count);
+			memcpy(skb_put(kim_gdata->rx_skb, len), ptr, len);
+			kim_gdata->rx_count -= len;
+			count -= len;
+			ptr += len;
+
+			if (kim_gdata->rx_count)
+				continue;
+
+			/* Check ST RX state machine , where are we? */
+			switch (kim_gdata->rx_state) {
+				/* Waiting for complete packet ? */
+			case ST_BT_W4_DATA:
+				ST_KIM_DBG("Complete pkt received");
+				validate_firmware_response(kim_gdata->rx_skb);
+				kim_gdata->rx_state = ST_W4_PACKET_TYPE;
+				kim_gdata->rx_skb = NULL;
+				continue;
+				/* Waiting for Bluetooth event header ? */
+			case ST_BT_W4_EVENT_HDR:
+				eh = (struct hci_event_hdr *)kim_gdata->
+				    rx_skb->data;
+				ST_KIM_DBG("Event header: evt 0x%2.2x"
+					   "plen %d", eh->evt, eh->plen);
+				kim_check_data_len(eh->plen);
+				continue;
+			}	/* end of switch */
+		}		/* end of if rx_state */
+		switch (*ptr) {
+			/* Bluetooth event packet? */
+		case HCI_EVENT_PKT:
+			ST_KIM_DBG("Event packet");
+			kim_gdata->rx_state = ST_BT_W4_EVENT_HDR;
+			kim_gdata->rx_count = HCI_EVENT_HDR_SIZE;
+			type = HCI_EVENT_PKT;
+			break;
+		default:
+			ST_KIM_DBG("unknown packet");
+			ptr++;
+			count--;
+			continue;
+		}		/* end of switch *ptr */
+		ptr++;
+		count--;
+		kim_gdata->rx_skb =
+		    bt_skb_alloc(HCI_MAX_FRAME_SIZE, GFP_ATOMIC);
+		if (!kim_gdata->rx_skb) {
+			ST_KIM_ERR("can't allocate mem for new packet");
+			kim_gdata->rx_state = ST_W4_PACKET_TYPE;
+			kim_gdata->rx_count = 0;
+			return;
+		} /* not necessary in this case */
+		bt_cb(kim_gdata->rx_skb)->pkt_type = type;
+	}			/* end of while count */
+	ST_KIM_DBG("done %s", __func__);
+	return;
+}
+
+static long read_local_version(char *bts_scr_name)
+{
+	unsigned short version = 0, chip = 0, min_ver = 0, maj_ver = 0;
+	char read_ver_cmd[] = { 0x01, 0x01, 0x10, 0x00 };
+
+	ST_KIM_DBG("%s", __func__);
+
+	INIT_COMPLETION(kim_gdata->kim_rcvd);
+	if (4 != st_int_write(read_ver_cmd, 4)) {
+		ST_KIM_ERR("kim: couldn't write 4 bytes");
+		return ST_ERR_FAILURE;
+	}
+
+	if (!wait_for_completion_timeout
+	    (&kim_gdata->kim_rcvd, msecs_to_jiffies(CMD_RESP_TIME))) {
+		ST_KIM_ERR(" waiting for ver info- timed out ");
+		return ST_ERR_FAILURE;
+	}
+
+	version =
+	    MAKEWORD(kim_gdata->resp_buffer[13], kim_gdata->resp_buffer[14]);
+	chip = (version & 0x7C00) >> 10;
+	min_ver = (version & 0x007F);
+	maj_ver = (version & 0x0380) >> 7;
+
+	if (version & 0x8000)
+		maj_ver |= 0x0008;
+
+	sprintf(bts_scr_name, "TIInit_%d.%d.%d.bts", chip, maj_ver, min_ver);
+	ST_KIM_DBG("%s", bts_scr_name);
+	return ST_SUCCESS;
+}
+
+/* internal function which parses through the .bts firmware script file
+ * intreprets SEND, DELAY actions only as of now
+ */
+static long download_firmware(void)
+{
+	long err = ST_SUCCESS;
+	long len = 0;
+	register unsigned char *ptr = NULL;
+	register unsigned char *action_ptr = NULL;
+	unsigned char bts_scr_name[30] = { 0 };	/* 30 char long bts scr name? */
+
+	ST_KIM_VER("%s", __func__);
+
+	err = read_local_version(bts_scr_name);
+	if (err != ST_SUCCESS) {
+		ST_KIM_ERR("kim: failed to read local ver");
+		return err;
+	}
+	err =
+	    request_firmware(&kim_gdata->fw_entry, bts_scr_name,
+			     &kim_gdata->kim_pdev->dev);
+	if (unlikely((err != 0) || (kim_gdata->fw_entry->data == NULL) ||
+		     (kim_gdata->fw_entry->size == 0))) {
+		ST_KIM_ERR(" request_firmware failed(errno %ld) for %s", err,
+			   bts_scr_name);
+		return ST_ERR_FAILURE;
+	}
+	ptr = (void *)kim_gdata->fw_entry->data;
+	len = kim_gdata->fw_entry->size;
+	/* bts_header to remove out magic number and
+	 * version
+	 */
+	ptr += sizeof(struct bts_header);
+	len -= sizeof(struct bts_header);
+
+	while (len > 0 && ptr) {
+		ST_KIM_VER(" action size %d, type %d ",
+			   ((struct bts_action *)ptr)->size,
+			   ((struct bts_action *)ptr)->type);
+
+		switch (((struct bts_action *)ptr)->type) {
+		case ACTION_SEND_COMMAND:	/* action send */
+			action_ptr = &(((struct bts_action *)ptr)->data[0]);
+			if (unlikely
+			    (((struct hci_command *)action_ptr)->opcode ==
+			     0xFF36)) {
+				/* ignore remote change
+				 * baud rate HCI VS command */
+				ST_KIM_ERR
+				    (" change remote baud\
+				    rate command in firmware");
+				break;
+			}
+
+			INIT_COMPLETION(kim_gdata->kim_rcvd);
+			err = st_int_write(((struct bts_action_send *)
+					    action_ptr)->data,
+					   ((struct bts_action *)ptr)->size);
+			if (unlikely(err < 0)) {
+				release_firmware(kim_gdata->fw_entry);
+				return ST_ERR_FAILURE;
+			}
+			if (!wait_for_completion_timeout
+			    (&kim_gdata->kim_rcvd,
+			     msecs_to_jiffies(CMD_RESP_TIME))) {
+				ST_KIM_ERR
+				    (" response timeout during fw download ");
+				/* timed out */
+				release_firmware(kim_gdata->fw_entry);
+				return ST_ERR_FAILURE;
+			}
+			break;
+		case ACTION_DELAY:	/* sleep */
+			ST_KIM_DBG("sleep command in scr");
+			action_ptr = &(((struct bts_action *)ptr)->data[0]);
+			mdelay(((struct bts_action_delay *)action_ptr)->msec);
+			break;
+		}
+		len =
+		    len - (sizeof(struct bts_action) +
+			   ((struct bts_action *)ptr)->size);
+		ptr =
+		    ptr + sizeof(struct bts_action) +
+		    ((struct bts_action *)ptr)->size;
+	}
+	/* fw download complete */
+	release_firmware(kim_gdata->fw_entry);
+	return ST_SUCCESS;
+}
+
+/**********************************************************************/
+/* functions called from ST core */
+
+/* function to toggle the GPIO
+ * needs to know whether the GPIO is active high or active low
+ */
+void st_kim_chip_toggle(enum proto_type type, enum kim_gpio_state state)
+{
+	ST_KIM_DBG(" %s ", __func__);
+
+	if (kim_gdata->gpios[type] == -1) {
+		ST_KIM_DBG(" gpio not requested for protocol %s",
+			   protocol_names[type]);
+		return;
+	}
+	switch (type) {
+	case ST_BT:
+		/*Do Nothing */
+		break;
+
+	case ST_FM:
+		if (state == KIM_GPIO_ACTIVE)
+			gpio_set_value(kim_gdata->gpios[ST_FM], GPIO_LOW);
+		else
+			gpio_set_value(kim_gdata->gpios[ST_FM], GPIO_HIGH);
+		break;
+
+	case ST_GPS:
+		if (state == KIM_GPIO_ACTIVE)
+			gpio_set_value(kim_gdata->gpios[ST_GPS], GPIO_HIGH);
+		else
+			gpio_set_value(kim_gdata->gpios[ST_GPS], GPIO_LOW);
+		break;
+
+	case ST_MAX:
+	default:
+		break;
+	}
+
+	return;
+}
+
+/* called from ST Core, when REG_IN_PROGRESS (registration in progress)
+ * can be because of
+ * 1. response to read local version
+ * 2. during send/recv's of firmware download
+ */
+void st_kim_recv(const unsigned char *data, long count)
+{
+	ST_KIM_DBG(" %s ", __func__);
+	/* copy to local buffer */
+	if (unlikely(data[4] == 0x01 && data[5] == 0x10 && data[0] == 0x04)) {
+		/* must be the read_ver_cmd */
+		memcpy(kim_gdata->resp_buffer, data, count);
+		complete_all(&kim_gdata->kim_rcvd);
+		return;
+	} else {
+		kim_int_recv(data, count);
+		/* either completes or times out */
+	}
+	return;
+}
+
+/* to signal completion of line discipline installation
+ * called from ST Core, upon tty_open
+ */
+void st_kim_complete(void)
+{
+	complete(&kim_gdata->ldisc_installed);
+}
+
+/* called from ST Core upon 1st registration
+*/
+long st_kim_start(void)
+{
+	long err = ST_SUCCESS;
+	long retry = POR_RETRY_COUNT;
+	ST_KIM_DBG(" %s", __func__);
+
+	do {
+		/* Configure BT nShutdown to HIGH state */
+		gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_LOW);
+		mdelay(5);	/* FIXME: a proper toggle */
+		gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_HIGH);
+		mdelay(100);
+
+		/* re-initialize the completion */
+		INIT_COMPLETION(kim_gdata->ldisc_installed);
+		/* send signal to UIM */
+		err = kill_pid(find_get_pid(kim_gdata->uim_pid), SIGUSR2, 0);
+		if (err != 0) {
+			ST_KIM_VER(" sending SIGUSR2 to uim failed %ld", err);
+			err = ST_ERR_FAILURE;
+			continue;
+		}
+		/* wait for ldisc to be installed */
+		err = wait_for_completion_timeout(&kim_gdata->ldisc_installed,
+				msecs_to_jiffies(LDISC_TIME));
+		if (!err) {	/* timeout */
+			ST_KIM_ERR("line disc installation timed out ");
+			err = ST_ERR_FAILURE;
+			continue;
+		} else {
+			/* ldisc installed now */
+			ST_KIM_DBG(" line discipline installed ");
+			err = download_firmware();
+			if (err != ST_SUCCESS) {
+				ST_KIM_ERR("download firmware failed");
+				continue;
+			} else {	/* on success don't retry */
+				break;
+			}
+		}
+	} while (retry--);
+	return err;
+}
+
+/* called from ST Core, on the last un-registration
+*/
+long st_kim_stop(void)
+{
+	long err = ST_SUCCESS;
+
+	INIT_COMPLETION(kim_gdata->ldisc_installed);
+	/* send signal to UIM */
+	err = kill_pid(find_get_pid(kim_gdata->uim_pid), SIGUSR2, 1);
+	if (err != 0) {
+		ST_KIM_ERR("sending SIGUSR2 to uim failed %ld", err);
+		return ST_ERR_FAILURE;
+	}
+
+	/* wait for ldisc to be un-installed */
+	err = wait_for_completion_timeout(&kim_gdata->ldisc_installed,
+			msecs_to_jiffies(LDISC_TIME));
+	if (!err) {		/* timeout */
+		ST_KIM_ERR(" timed out waiting for ldisc to be un-installed");
+		return ST_ERR_FAILURE;
+	}
+
+	/* By default configure BT nShutdown to LOW state */
+	gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_LOW);
+	mdelay(1);
+	gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_HIGH);
+	mdelay(1);
+	gpio_set_value(kim_gdata->gpios[ST_BT], GPIO_LOW);
+	return err;
+}
+
+/**********************************************************************/
+/* functions called from subsystems */
+
+/* called when sysfs entry is written to */
+static ssize_t store_pid(struct device *dev, struct device_attribute
+			 *devattr, char *buf, size_t count)
+{
+	ST_KIM_DBG("%s: pid %s ", __func__, buf);
+	sscanf(buf, "%ld", &kim_gdata->uim_pid);
+	/* to be made use by kim_start to signal SIGUSR2
+	 */
+	return strlen(buf);
+}
+
+/* called when sysfs entry is read from */
+static ssize_t show_pid(struct device *dev, struct device_attribute
+			*attr, char *buf)
+{
+	sprintf(buf, "%ld", kim_gdata->uim_pid);
+	return strlen(buf);
+}
+
+/* called when sysfs entry is read from */
+static ssize_t show_list(struct device *dev, struct device_attribute
+			 *attr, char *buf)
+{
+	kim_st_list_protocols(buf);
+	return strlen(buf);
+}
+
+#ifdef LEGACY_RFKILL_SUPPORT
+/* function called from rfkill subsystem, when someone from
+ * user space would write 0/1 on the sysfs entry
+ * /sys/class/rfkill/rfkill0,1,3/state
+ */
+static int kim_toggle_radio(void *data, bool blocked)
+{
+	enum proto_type type = *((enum proto_type *)data);
+	ST_KIM_DBG(" %s: %d ", __func__, type);
+
+	switch (type) {
+	case ST_BT:
+		/* do nothing */
+		break;
+	case ST_FM:
+	case ST_GPS:
+		if (blocked)
+			st_kim_chip_toggle(type, KIM_GPIO_INACTIVE);
+		else
+			st_kim_chip_toggle(type, KIM_GPIO_ACTIVE);
+		break;
+	case ST_MAX:
+		ST_KIM_ERR(" wrong proto type ");
+		break;
+	}
+	return ST_SUCCESS;
+}
+#endif
+
+/**********************************************************************/
+/* functions called from platform device driver subsystem
+ * need to have a relevant platform device entry in the platform's
+ * board-*.c file
+ */
+
+static int kim_probe(struct platform_device *pdev)
+{
+	long status;
+	long proto;
+	long *gpios = pdev->dev.platform_data;
+
+	for (proto = 0; proto < ST_MAX; proto++) {
+		kim_gdata->gpios[proto] = gpios[proto];
+		ST_KIM_VER(" %ld gpio to be requested", gpios[proto]);
+	}
+
+	for (proto = 0; (proto < ST_MAX) && (gpios[proto] != -1); proto++) {
+		/* Claim the Bluetooth/FM/GPIO
+		 * nShutdown gpio from the system
+		 */
+		status = gpio_request(gpios[proto], "kim");
+		if (unlikely(status)) {
+			ST_KIM_ERR(" gpio %ld request failed ", gpios[proto]);
+			proto -= 1;
+			while (proto >= 0) {
+				if (gpios[proto] != -1)
+					gpio_free(gpios[proto]);
+			}
+			return status;
+		}
+
+		/* Configure nShutdown GPIO as output=0 */
+		status =
+		    gpio_direction_output(gpios[proto], 0);
+		if (unlikely(status)) {
+			ST_KIM_ERR(" unable to configure gpio %ld",
+				   gpios[proto]);
+			proto -= 1;
+			while (proto >= 0) {
+				if (gpios[proto] != -1)
+					gpio_free(gpios[proto]);
+			}
+			return status;
+		}
+	}
+	/* pdev to contain BT, FM and GPS enable/N-Shutdown GPIOs
+	 * execute request_gpio, set output direction
+	 */
+	kim_gdata->kim_kobj = kobject_create_and_add("uim", NULL);
+	/* create the sysfs entry for UIM to put in pid */
+	if (sysfs_create_group(kim_gdata->kim_kobj, &uim_attr_grp)) {
+		ST_KIM_ERR(" sysfs entry creation failed");
+		kobject_put(kim_gdata->kim_kobj);
+		/* free requested GPIOs and fail probe */
+		for (proto = ST_BT; proto < ST_MAX; proto++) {
+			if (gpios[proto] != -1)
+				gpio_free(gpios[proto]);
+		}
+		return -1;	/* fail insmod */
+	}
+
+	ST_KIM_DBG(" sysfs entry created ");
+
+	/* get reference of pdev for request_firmware
+	 */
+	kim_gdata->kim_pdev = pdev;
+	init_completion(&kim_gdata->kim_rcvd);
+	init_completion(&kim_gdata->ldisc_installed);
+#ifdef LEGACY_RFKILL_SUPPORT
+	for (proto = 0; (proto < ST_MAX) && (gpios[proto] != -1); proto++) {
+		/* TODO: should all types be rfkill_type_bt ? */
+		kim_gdata->rfkill[proto] = rfkill_alloc(protocol_names[proto],
+			&pdev->dev, RFKILL_TYPE_BLUETOOTH,
+			&kim_rfkill_ops, &proto);
+		if (kim_gdata->rfkill[proto] == NULL) {
+			ST_KIM_ERR("cannot create rfkill entry for gpio %ld",
+				   gpios[proto]);
+			continue;
+		}
+		status = rfkill_register(kim_gdata->rfkill[proto]);
+		if (unlikely(status)) {
+			ST_KIM_ERR("rfkill registration failed for gpio %ld",
+				   gpios[proto]);
+			rfkill_unregister(kim_gdata->rfkill[proto]);
+			continue;
+		}
+		ST_KIM_DBG("rfkill entry created for %ld", gpios[proto]);
+	}
+#endif
+	return ST_SUCCESS;
+}
+
+static int kim_remove(struct platform_device *pdev)
+{
+	/* free the GPIOs requested
+	 */
+	long *gpios = pdev->dev.platform_data;
+	long proto;
+
+	for (proto = 0; (proto < ST_MAX) && (gpios[proto] != -1); proto++) {
+		/* Claim the Bluetooth/FM/GPIO
+		 * nShutdown gpio from the system
+		 */
+		gpio_free(gpios[proto]);
+#ifdef LEGACY_RFKILL_SUPPORT
+		rfkill_unregister(kim_gdata->rfkill[proto]);
+		rfkill_destroy(kim_gdata->rfkill[proto]);
+		kim_gdata->rfkill[proto] = NULL;
+#endif
+	}
+	ST_KIM_DBG("kim: GPIO Freed");
+	/* delete the sysfs entries */
+	sysfs_remove_group(kim_gdata->kim_kobj, &uim_attr_grp);
+	kobject_put(kim_gdata->kim_kobj);
+	kim_gdata->kim_pdev = NULL;
+	return ST_SUCCESS;
+}
+
+/**********************************************************************/
+/* entry point for ST KIM module, called in from ST Core */
+
+long st_kim_init(void)
+{
+	long ret = ST_SUCCESS;
+	kim_gdata = kzalloc(sizeof(struct kim_data_s), GFP_ATOMIC);
+	if (!kim_gdata) {
+		ST_KIM_ERR("no mem to allocate");
+		return -ENOMEM;
+	}
+	ret = platform_driver_register(&kim_platform_driver);
+	if (ret != 0) {
+		ST_KIM_ERR("platform drv registration failed");
+		return ST_ERR_FAILURE;
+	}
+	return ST_SUCCESS;
+}
+
+long st_kim_deinit(void)
+{
+	/* the following returns void */
+	platform_driver_unregister(&kim_platform_driver);
+	kfree(kim_gdata);
+	kim_gdata = NULL;
+	return ST_SUCCESS;
+}
diff --git a/drivers/misc/ti-st/st_kim.h b/drivers/misc/ti-st/st_kim.h
new file mode 100644
index 0000000..4e73bb4
--- /dev/null
+++ b/drivers/misc/ti-st/st_kim.h
@@ -0,0 +1,151 @@
+/*
+ *  Shared Transport Line discipline driver Core
+ *	Init Manager Module header file
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#ifndef ST_KIM_H
+#define ST_KIM_H
+
+#include <linux/types.h>
+#include "st.h"
+#include "st_core.h"
+#include "st_ll.h"
+#include <linux/rfkill.h>
+
+/* time in msec to wait for
+ * line discipline to be installed
+ */
+#define LDISC_TIME	500
+#define CMD_RESP_TIME	500
+#define MAKEWORD(a, b)  ((unsigned short)(((unsigned char)(a)) \
+	| ((unsigned short)((unsigned char)(b))) << 8))
+
+#define GPIO_HIGH 1
+#define GPIO_LOW  0
+
+/* the Power-On-Reset logic, requires to attempt
+ * to download firmware onto chip more than once
+ * since the self-test for chip takes a while
+ */
+#define POR_RETRY_COUNT 5
+/*
+ * legacy rfkill support where-in 3 rfkill
+ * devices are created for the 3 gpios
+ * that ST has requested
+ */
+#define LEGACY_RFKILL_SUPPORT
+/*
+ * header file for ST provided by KIM
+ */
+struct kim_data_s {
+	long uim_pid;
+	struct platform_device *kim_pdev;
+	struct completion kim_rcvd, ldisc_installed;
+	/* MAX len of the .bts firmware script name */
+	char resp_buffer[30];
+	const struct firmware *fw_entry;
+	long gpios[ST_MAX];
+	struct kobject *kim_kobj;
+/* used by kim_int_recv to validate fw response */
+	unsigned long rx_state;
+	unsigned long rx_count;
+	struct sk_buff *rx_skb;
+#ifdef LEGACY_RFKILL_SUPPORT
+	struct rfkill *rfkill[ST_MAX];
+#endif
+};
+
+long st_kim_init(void);
+long st_kim_deinit(void);
+
+long st_kim_start(void);
+long st_kim_stop(void);
+/*
+ * called from st_tty_receive to authenticate fw_download
+ */
+void st_kim_recv(const unsigned char *, long count);
+
+void st_kim_chip_toggle(enum proto_type, enum kim_gpio_state);
+
+void st_kim_complete(void);
+
+/* function called from ST KIM to ST Core, to
+ * list out the protocols registered
+ */
+void kim_st_list_protocols(char *);
+
+/*
+ * BTS headers
+ */
+#define ACTION_SEND_COMMAND     1
+#define ACTION_WAIT_EVENT       2
+#define ACTION_SERIAL           3
+#define ACTION_DELAY            4
+#define ACTION_RUN_SCRIPT       5
+#define ACTION_REMARKS          6
+
+/*
+ *  * BRF Firmware header
+ *   */
+struct bts_header {
+	uint32_t magic;
+	uint32_t version;
+	uint8_t future[24];
+	uint8_t actions[0];
+} __attribute__ ((packed));
+
+/*
+ *  * BRF Actions structure
+ *   */
+struct bts_action {
+	uint16_t type;
+	uint16_t size;
+	uint8_t data[0];
+} __attribute__ ((packed));
+
+struct bts_action_send {
+	uint8_t data[0];
+} __attribute__ ((packed));
+
+struct bts_action_wait {
+	uint32_t msec;
+	uint32_t size;
+	uint8_t data[0];
+} __attribute__ ((packed));
+
+struct bts_action_delay {
+	uint32_t msec;
+} __attribute__ ((packed));
+
+struct bts_action_serial {
+	uint32_t baud;
+	uint32_t flow_control;
+} __attribute__ ((packed));
+
+/* for identifying the change speed HCI VS
+ * command
+ */
+struct hci_command {
+	uint8_t prefix;
+	uint16_t opcode;
+	uint8_t plen;
+	uint32_t speed;
+} __attribute__ ((packed));
+
+
+#endif /* ST_KIM_H */
-- 
1.5.4.3

[PATCH 5/6] drivers:misc: sources for HCI LL PM protocol

[pavan_savoy]

From: Pavan Savoy <pavan_savoy@ti.com>

Texas Instruments BT, FM and GPS combo chips/drivers
make use of a single TTY to communicate with the chip.
This module constitutes the proprietary power management
protocol from TI for the BT/FM/GPS combo chips

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 drivers/misc/ti-st/st_ll.c |  169 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/misc/ti-st/st_ll.h |   67 +++++++++++++++++
 2 files changed, 236 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/ti-st/st_ll.c
 create mode 100644 drivers/misc/ti-st/st_ll.h

diff --git a/drivers/misc/ti-st/st_ll.c b/drivers/misc/ti-st/st_ll.c
new file mode 100644
index 0000000..5e42cbe
--- /dev/null
+++ b/drivers/misc/ti-st/st_ll.c
@@ -0,0 +1,169 @@
+/*
+ *  Shared Transport driver
+ *	HCI-LL module responsible for TI proprietary HCI_LL protocol
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include "st_ll.h"
+
+/* all debug macros go in here */
+#define ST_LL_ERR(fmt, arg...)  printk(KERN_ERR "(stll):"fmt"\n" , ## arg)
+#if defined(DEBUG)		/* limited debug messages */
+#define ST_LL_DBG(fmt, arg...)  printk(KERN_INFO "(stll):"fmt"\n" , ## arg)
+#define ST_LL_VER(fmt, arg...)
+#elif defined(VERBOSE)		/* very verbose */
+#define ST_LL_DBG(fmt, arg...)  printk(KERN_INFO "(stll):"fmt"\n" , ## arg)
+#define ST_LL_VER(fmt, arg...)  printk(KERN_INFO "(stll):"fmt"\n" , ## arg)
+#else /* error msgs only */
+#define ST_LL_DBG(fmt, arg...)
+#define ST_LL_VER(fmt, arg...)
+#endif
+
+static struct ll_struct_s *ll;
+
+/**********************************************************************/
+/* internal functions */
+static void send_ll_cmd(unsigned char cmd)
+{
+
+	ST_LL_DBG("%s: writing %x", __func__, cmd);
+	st_int_write(&cmd, 1);
+	return;
+}
+
+static void ll_device_want_to_sleep(void)
+{
+	ST_LL_DBG("%s", __func__);
+	/* sanity check */
+	if (ll->ll_state != ST_LL_AWAKE)
+		ST_LL_ERR("ERR hcill: ST_LL_GO_TO_SLEEP_IND"
+			  "in state %ld", ll->ll_state);
+
+	send_ll_cmd(LL_SLEEP_ACK);
+	/* update state */
+	ll->ll_state = ST_LL_ASLEEP;
+}
+
+static void ll_device_want_to_wakeup(void)
+{
+	/* diff actions in diff states */
+	switch (ll->ll_state) {
+	case ST_LL_ASLEEP:
+		send_ll_cmd(LL_WAKE_UP_ACK);	/* send wake_ack */
+		break;
+	case ST_LL_ASLEEP_TO_AWAKE:
+		/* duplicate wake_ind */
+		ST_LL_ERR("duplicate wake_ind while waiting for Wake ack");
+		break;
+	case ST_LL_AWAKE:
+		/* duplicate wake_ind */
+		ST_LL_ERR("duplicate wake_ind already AWAKE");
+		break;
+	case ST_LL_AWAKE_TO_ASLEEP:
+		/* duplicate wake_ind */
+		ST_LL_ERR("duplicate wake_ind");
+		break;
+	}
+	/* update state */
+	ll->ll_state = ST_LL_AWAKE;
+}
+
+/**********************************************************************/
+/* functions invoked by ST Core */
+
+/* called when ST Core wants to
+ * enable ST LL */
+void st_ll_enable(void)
+{
+	ll->ll_state = ST_LL_AWAKE;
+}
+
+/* called when ST Core /local module wants to
+ * disable ST LL */
+void st_ll_disable(void)
+{
+	ll->ll_state = ST_LL_INVALID;
+}
+
+/* called when ST Core wants to update the state */
+void st_ll_wakeup(void)
+{
+	if (likely(ll->ll_state != ST_LL_AWAKE)) {
+		send_ll_cmd(LL_WAKE_UP_IND);	/* WAKE_IND */
+		ll->ll_state = ST_LL_ASLEEP_TO_AWAKE;
+	} else {
+		/* don't send the duplicate wake_indication */
+		ST_LL_ERR(" Chip already AWAKE ");
+	}
+}
+
+/* called when ST Core wants the state */
+unsigned long st_ll_getstate(void)
+{
+	ST_LL_DBG(" returning state %ld", ll->ll_state);
+	return ll->ll_state;
+}
+
+/* called from ST Core, when a PM related packet arrives */
+unsigned long st_ll_sleep_state(unsigned char cmd)
+{
+	switch (cmd) {
+	case LL_SLEEP_IND:	/* sleep ind */
+		ST_LL_DBG("sleep indication recvd");
+		ll_device_want_to_sleep();
+		break;
+	case LL_SLEEP_ACK:	/* sleep ack */
+		ST_LL_ERR("sleep ack rcvd: host shouldn't");
+		break;
+	case LL_WAKE_UP_IND:	/* wake ind */
+		ST_LL_DBG("wake indication recvd");
+		ll_device_want_to_wakeup();
+		break;
+	case LL_WAKE_UP_ACK:	/* wake ack */
+		ST_LL_DBG("wake ack rcvd");
+		ll->ll_state = ST_LL_AWAKE;
+		break;
+	default:
+		ST_LL_ERR(" unknown input/state ");
+		return ST_ERR_FAILURE;
+	}
+	return ST_SUCCESS;
+}
+
+/* Called from ST CORE to initialize ST LL */
+long st_ll_init(void)
+{
+	long err = ST_SUCCESS;
+
+	/* Allocate memory for ST LL private structure */
+	ll = kzalloc(sizeof(*ll), GFP_ATOMIC);
+	if (!ll) {
+		ST_LL_ERR("kzalloc failed to alloc memory for ST LL");
+		err = -ENOMEM;
+		return err;
+	}
+	/* set state to invalid */
+	ll->ll_state = ST_LL_INVALID;
+	return err;
+}
+
+/* Called from ST CORE to de-initialize ST LL */
+long st_ll_deinit(void)
+{
+	kfree(ll);
+	return 0;
+}
diff --git a/drivers/misc/ti-st/st_ll.h b/drivers/misc/ti-st/st_ll.h
new file mode 100644
index 0000000..fff88cb
--- /dev/null
+++ b/drivers/misc/ti-st/st_ll.h
@@ -0,0 +1,67 @@
+/*
+ *  Shared Transport Low Level (ST LL)
+ *
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#ifndef ST_LL_H
+#define ST_LL_H
+
+#include <linux/skbuff.h>
+#include "st.h"
+#include "st_core.h"
+
+/* ST LL receiver states */
+#define ST_W4_PACKET_TYPE       0
+#define ST_BT_W4_EVENT_HDR      1
+#define ST_BT_W4_ACL_HDR        2
+#define ST_BT_W4_SCO_HDR        3
+#define ST_BT_W4_DATA           4
+#define ST_FM_W4_EVENT_HDR      5
+#define ST_GPS_W4_EVENT_HDR	6
+
+/* ST LL state machines */
+#define ST_LL_ASLEEP               0
+#define ST_LL_ASLEEP_TO_AWAKE      1
+#define ST_LL_AWAKE                2
+#define ST_LL_AWAKE_TO_ASLEEP      3
+#define ST_LL_INVALID		   4
+
+#define LL_SLEEP_IND	0x30
+#define LL_SLEEP_ACK	0x31
+#define LL_WAKE_UP_IND	0x32
+#define LL_WAKE_UP_ACK	0x33
+
+/* ST LL private information */
+struct ll_struct_s {
+	unsigned long ll_state;	/* ST LL power state */
+};
+
+/* initialize and de-init ST LL */
+long st_ll_init(void);
+long st_ll_deinit(void);
+
+/* enable/disable ST LL along with KIM start/stop
+ * called by ST Core
+ */
+void st_ll_enable(void);
+void st_ll_disable(void);
+
+unsigned long st_ll_getstate(void);
+unsigned long st_ll_sleep_state(unsigned char);
+void st_ll_wakeup(void);
+#endif /* ST_LL_H */
-- 
1.5.4.3

[PATCH 6/6] drivers:misc: sources for ST header file

[pavan_savoy]

From: Pavan Savoy <pavan_savoy@ti.com>

Texas Instruments BT, FM and GPS combo chips/drivers
make use of a single TTY to communicate with the chip.
This is the common header file for both the ST driver and the
protocol drivers which intend to use ST as their mode of
transport.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 drivers/misc/ti-st/fm.h |   13 +++++++
 drivers/misc/ti-st/st.h |   85 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 98 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/ti-st/fm.h
 create mode 100644 drivers/misc/ti-st/st.h

diff --git a/drivers/misc/ti-st/fm.h b/drivers/misc/ti-st/fm.h
new file mode 100644
index 0000000..be41453
--- /dev/null
+++ b/drivers/misc/ti-st/fm.h
@@ -0,0 +1,13 @@
+struct fm_event_hdr {
+	unsigned char plen;
+} __attribute__ ((packed));
+
+#define FM_MAX_FRAME_SIZE 0xFF	/* TODO: */
+#define FM_EVENT_HDR_SIZE 1	/* size of fm_event_hdr */
+#define ST_FM_CH8_PKT 0x8
+
+/* gps stuff */
+struct gps_event_hdr {
+unsigned char opcode;
+unsigned short plen;
+} __attribute__ ((packed));
diff --git a/drivers/misc/ti-st/st.h b/drivers/misc/ti-st/st.h
new file mode 100644
index 0000000..ec821d2
--- /dev/null
+++ b/drivers/misc/ti-st/st.h
@@ -0,0 +1,85 @@
+/*
+ *  Shared Transport Header file
+ *	To be included by the protocol stack drivers for
+ *	Texas Instruments BT,FM and GPS combo chip drivers
+ *
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#ifndef ST_H
+#define ST_H
+
+#include <linux/skbuff.h>
+/*
+ * st.h
+ */
+
+/* some gpios have active high, others like fm have
+ * active low
+ */
+enum kim_gpio_state {
+	KIM_GPIO_INACTIVE,
+	KIM_GPIO_ACTIVE,
+};
+/*
+ * the list of protocols on chip
+ */
+enum proto_type {
+	ST_BT,
+	ST_FM,
+	ST_GPS,
+	ST_MAX,
+};
+
+enum {
+	ST_ERR_FAILURE = -1,	/* check struct */
+	ST_SUCCESS,
+	ST_ERR_PENDING = -5,	/* to call reg_complete_cb */
+	ST_ERR_ALREADY,		/* already registered */
+	ST_ERR_INPROGRESS,
+	ST_ERR_NOPROTO,		/* protocol not supported */
+};
+
+/* per protocol structure
+ * for BT/FM and GPS
+ */
+struct st_proto_s {
+	enum proto_type type;
+/*
+ * to be called by ST when data arrives
+ */
+	long (*recv) (struct sk_buff *);
+/*
+ * for future use, logic now to be in ST
+ */
+	unsigned char (*match_packet) (const unsigned char *data);
+/*
+ * subsequent registration return PENDING,
+ * signalled complete by this callback function
+ */
+	void (*reg_complete_cb) (char data);
+/*
+ * write function, sent in as NULL and to be returned to
+ * protocol drivers
+ */
+	long (*write) (struct sk_buff *skb);
+};
+
+extern long st_register(struct st_proto_s *new_proto);
+extern long st_unregister(enum proto_type type);
+
+#endif /* ST_H */
-- 
1.5.4.3

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Greg KH]

On Mon, Mar 22, 2010 at 04:19:14PM -0500, pavan_savoy@ti.com wrote:
> +/* structures specific for sysfs entries */
> +static struct kobj_attribute pid_attr =
> +__ATTR(pid, 0644, (void *)show_pid, (void *)store_pid);
> +
> +static struct kobj_attribute list_protocols =
> +__ATTR(protocols, 0444, (void *)show_list, NULL);

As you are creating sysfs attributes, you have to have
Documentation/ABI/ updates as well.  Please include them so we can see
what you are trying to do here.

And why "raw" attributes and not device ones?

thanks,

greg k-h

RE: [PATCH 4/6] drivers:misc: sources for Init manager module

[Savoy, Pavan]

----------------------
Thanks & Regards,
Pavan Savoy | x0099669
________________________________________
From: Greg KH [gregkh@suse.de]
Sent: Tuesday, March 23, 2010 3:06 AM
To: Savoy, Pavan
Cc: alan@lxorguk.ukuu.org.uk; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module

On Mon, Mar 22, 2010 at 04:19:14PM -0500, pavan_savoy@ti.com wrote:
> +/* structures specific for sysfs entries */
> +static struct kobj_attribute pid_attr =
> +__ATTR(pid, 0644, (void *)show_pid, (void *)store_pid);
> +
> +static struct kobj_attribute list_protocols =
> +__ATTR(protocols, 0444, (void *)show_list, NULL);

>As you are creating sysfs attributes, you have to have
>Documentation/ABI/ updates as well.  Please include them so we can see
>what you are trying to do here.
>And why "raw" attributes and not device ones?
>thanks,
>greg k-h

[pavan] >>>>>>>>
I am creating a sysfs entry for the daemon/service to write in it's PID to the sysfs entry, so
as to whenever a new protocol driver - BT/FM or GPS wants to use the N_TI_SHARED ldisc, 
the driver would then send signal to daemon on this PID.

The source for this problem, was that I could not install line discipline from kernel space.
i.e make N_TI_SHARED line discipline the current ldisc from kernel space itself.
>>>>>>

>From 92d89d132b5036d8ab58ce4f36b24bb1859610e0 Mon Sep 17 00:00:00 2001
From: Pavan Savoy <pavan_savoy@ti.com>
Date: Mon, 22 Mar 2010 18:11:32 -0400
Subject: [PATCH 1/1] Documentation/ABI: for N_TI_SHARED ldisc
N_TI_SHARED creates a sysfs entry to communicate
with the application/daemon which would want to install/
un-install the line discipline, it's documentation
now exists in testing/ subdirectory.
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 Documentation/ABI/testing/sysfs-uim |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-uim
diff --git a/Documentation/ABI/testing/sysfs-uim b/Documentation/ABI/testing/sysfs-uim
new file mode 100644
index 0000000..899aa4d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-uim
@@ -0,0 +1,24 @@
+What:           /sys/uim
+Date:           March 22
+Contact:        Pavan Savoy <pavan_savoy@ti.com>
+Description:
+                Create a new kobject to pass information about the
+  N_TI_SHARED line discipline created to application/daemon
+  which would install/un-install line discipline.
+
+What:           /sys/uim/pid
+Date:           March 22
+Contact:        Pavan Savoy <pavan_savoy@ti.com>
+Description:
+  The daemon/application wanting to use the line discipline
+  N_TI_SHARED will write in it's process Id, for the LDISC
+  driver to send SIGUSR2 signal to the process whenever a
+  upper layer protocol driver wants to make use of the LDISC
+  driver.
+
+What:           /sys/uim/protocols
+Date:           March 22
+Contact:        Pavan Savoy <pavan_savoy@ti.com>
+Description:
+  List the protocols currently making use of the LDISC to ensure
+  LDISC is not un-installed when BT/FM or GPS is making use of it.
-- 
1.5.4.3

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Greg KH]

On Tue, Mar 23, 2010 at 03:33:50AM +0530, Savoy, Pavan wrote:
> 
> ----------------------
> Thanks & Regards,
> Pavan Savoy | x0099669

That made no sense :(

> On Mon, Mar 22, 2010 at 04:19:14PM -0500, pavan_savoy@ti.com wrote:
> > +/* structures specific for sysfs entries */
> > +static struct kobj_attribute pid_attr =
> > +__ATTR(pid, 0644, (void *)show_pid, (void *)store_pid);
> > +
> > +static struct kobj_attribute list_protocols =
> > +__ATTR(protocols, 0444, (void *)show_list, NULL);
> 
> >As you are creating sysfs attributes, you have to have
> >Documentation/ABI/ updates as well.  Please include them so we can see
> >what you are trying to do here.
> >And why "raw" attributes and not device ones?
> >thanks,
> >greg k-h
> 
> [pavan] >>>>>>>>

Ick.  Please fix your email client to quote properly.  There are
hundreds of free email programs out there that will do that.  Heck,
there are free web email clients that even get this right...

> I am creating a sysfs entry for the daemon/service to write in it's
> PID to the sysfs entry, so as to whenever a new protocol driver -
> BT/FM or GPS wants to use the N_TI_SHARED ldisc, the driver would then
> send signal to daemon on this PID.

Then document it.  All sysfs files need documentation.

Hm, writing a PID to a sysfs file?  Oh, that's going to be ripe for
problems.  What namespace is that PID in?

> The source for this problem, was that I could not install line
> discipline from kernel space.  i.e make N_TI_SHARED line discipline
> the current ldisc from kernel space itself.

Are you sure?  I thought the bluetooth core did this already.  Have you
looked at how that works?

> >From 92d89d132b5036d8ab58ce4f36b24bb1859610e0 Mon Sep 17 00:00:00 2001
> From: Pavan Savoy <pavan_savoy@ti.com>
> Date: Mon, 22 Mar 2010 18:11:32 -0400
> Subject: [PATCH 1/1] Documentation/ABI: for N_TI_SHARED ldisc
> N_TI_SHARED creates a sysfs entry to communicate
> with the application/daemon which would want to install/
> un-install the line discipline, it's documentation
> now exists in testing/ subdirectory.
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
>  Documentation/ABI/testing/sysfs-uim |   24 ++++++++++++++++++++++++
>  1 files changed, 24 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-uim
> diff --git a/Documentation/ABI/testing/sysfs-uim b/Documentation/ABI/testing/sysfs-uim
> new file mode 100644
> index 0000000..899aa4d
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-uim
> @@ -0,0 +1,24 @@
> +What:           /sys/uim
> +Date:           March 22
> +Contact:        Pavan Savoy <pavan_savoy@ti.com>
> +Description:
> +                Create a new kobject to pass information about the
> +  N_TI_SHARED line discipline created to application/daemon
> +  which would install/un-install line discipline.

No, you don't get to create a new root sysfs file, sorry.  Please put it
in the correct subsystem location, if anywhere at all.

thanks,

greg k-h

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Marcel Holtmann]

Hi Greg,

> > The source for this problem, was that I could not install line
> > discipline from kernel space.  i.e make N_TI_SHARED line discipline
> > the current ldisc from kernel space itself.
> 
> Are you sure?  I thought the bluetooth core did this already.  Have you
> looked at how that works?

I didn't have time to look at it at all so far. However I think this
should just go via a proper review process. And it might need some
architecture review first. It is clearly not a candidate for staging
since it is not really self-contained.

Regards

Marcel

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Marcel Holtmann <marcel@holtmann.org> wrote:

> From: Marcel Holtmann <marcel@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Greg KH" <gregkh@suse.de>
> Cc: "Savoy, Pavan" <pavan_savoy@ti.com>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 1:34 PM
> Hi Greg,
> 
> > > The source for this problem, was that I could not
> install line
> > > discipline from kernel space.  i.e make
> N_TI_SHARED line discipline
> > > the current ldisc from kernel space itself.
> > 
> > Are you sure?  I thought the bluetooth core did
> this already.  Have you
> > looked at how that works?
> 
> I didn't have time to look at it at all so far. However I
> think this
> should just go via a proper review process. And it might
> need some
> architecture review first. It is clearly not a candidate
> for staging
> since it is not really self-contained.
> 
> Regards
> 
> Marcel
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


Marcel, Greg,

I wanted to somehow put this in staging because then it would probably have a thorough architectural review process.
Some details about this driver - 

1. This driver will be used by Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device driver) using the EXPORTED symbols (-register/_unregister).

2. Much like the hciattach daemon which maintains N_HCI bluetooth line discipline, this driver will also have a User-Space  N_TI_WL Init manager (UIM) maintaining the Line discipline.

3. Because of the UIM should know when to install/uninstall line discipline, the /sys entry is created a root called UIM (a new kobject) and UIM daemon would write it's PID to it.

4. As Alan suggested, If I make it self-contained by pushing number of line disciplines to a slightly larger number, then would it be OK ?



      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Greg KH]

On Wed, Mar 24, 2010 at 08:24:01PM +0530, Pavan Savoy wrote:
> 4. As Alan suggested, If I make it self-contained by pushing number of
> line disciplines to a slightly larger number, then would it be OK ?

That is fine with me, as long as you continue to work on fixing the
issues in the code, and do not object to changing the user/kernel
interface over time to be one that is more sane.

thanks,

greg k-h

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Marcel Holtmann]

Hi Pavan,


> I wanted to somehow put this in staging because then it would probably have a thorough architectural review process.
> Some details about this driver - 
> 
> 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device driver) using the EXPORTED symbols (-register/_unregister).
> 
> 2. Much like the hciattach daemon which maintains N_HCI bluetooth line discipline, this driver will also have a User-Space  N_TI_WL Init manager (UIM) maintaining the Line discipline.

can you explain why you think this is needed and we can not interface
this directly. If it is a serial port, what protocol does it talk?

> 3. Because of the UIM should know when to install/uninstall line discipline, the /sys entry is created a root called UIM (a new kobject) and UIM daemon would write it's PID to it.

I don't understand this. This sounds like a broken concept to me.

> 4. As Alan suggested, If I make it self-contained by pushing number of line disciplines to a slightly larger number, then would it be OK ?

Just from a quick look, I think within a few review cycles this might be
able to get proper upstream inclusion. No idea why bother with staging
in the first place. Lets do this correctly.

Regards

Marcel

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Marcel Holtmann <marcel@holtmann.org> wrote:

> From: Marcel Holtmann <marcel@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Greg KH" <gregkh@suse.de>, "PavanSavoy" <pavan_savoy@ti.com>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 9:41 PM
> Hi Pavan,
> 
> 
> > I wanted to somehow put this in staging because then
> it would probably have a thorough architectural review
> process.
> > Some details about this driver - 
> > 
> > 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2
> and GPS (probably character device driver) using the
> EXPORTED symbols (-register/_unregister).
> > 
> > 2. Much like the hciattach daemon which maintains
> N_HCI bluetooth line discipline, this driver will also have
> a User-Space  N_TI_WL Init manager (UIM) maintaining
> the Line discipline.
> 
> can you explain why you think this is needed and we can not
> interface
> this directly. If it is a serial port, what protocol does
> it talk?

Illustration: The BT driver on top of this ST driver, would create a hci0 interface, when someone does an DEVUP on that interface, the BT driver would then do a st-register - which in-turn would ask the hciattach-like daemon to install the line discipline for it via the sysfs entry.
The same concept goes for FM-V4L2 and GPS character driver.

The core of the problem is we cannot ask/install/ldisc_put for a line discipline from kernel space.

> 
> > 3. Because of the UIM should know when to
> install/uninstall line discipline, the /sys entry is created
> a root called UIM (a new kobject) and UIM daemon would write
> it's PID to it.
> 
> I don't understand this. This sounds like a broken concept
> to me.

Yes, I don't feel good about it either. But how do I request for a line discipline from kernel space ?
Currently a daemon has to run in user-space to maintain the ldisc, at all times, and I don't want to open TTY @ boot, and install Ldisc (tiocsetd) on it, without BT/FM or GPS core on chip being used - The Power Management team here would beat me up if I do that, 
and hence the very dumb idea of passing the PID of the daemon via sysfs entry, and the driver sending SIGUSR2 to that PID, daemon doing a tiocsetd upon that signal.

> 
> > 4. As Alan suggested, If I make it self-contained by
> pushing number of line disciplines to a slightly larger
> number, then would it be OK ?
> 
> Just from a quick look, I think within a few review cycles
> this might be
> able to get proper upstream inclusion. No idea why bother
> with staging
> in the first place. Lets do this correctly.
> 

The only reason I wanted this to be in staging was to have sort of continuous review process, and in hope the driver wouldn't be forgotten.

> Regards
> 
> Marcel
> 
> 
> 


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Marcel Holtmann]

Hi Pavan,

> > > I wanted to somehow put this in staging because then
> > it would probably have a thorough architectural review
> > process.
> > > Some details about this driver - 
> > > 
> > > 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2
> > and GPS (probably character device driver) using the
> > EXPORTED symbols (-register/_unregister).
> > > 
> > > 2. Much like the hciattach daemon which maintains
> > N_HCI bluetooth line discipline, this driver will also have
> > a User-Space  N_TI_WL Init manager (UIM) maintaining
> > the Line discipline.
> > 
> > can you explain why you think this is needed and we can not
> > interface
> > this directly. If it is a serial port, what protocol does
> > it talk?
> 
> Illustration: The BT driver on top of this ST driver, would create a hci0 interface, when someone does an DEVUP on that interface, the BT driver would then do a st-register - which in-turn would ask the hciattach-like daemon to install the line discipline for it via the sysfs entry.
> The same concept goes for FM-V4L2 and GPS character driver.
> 
> The core of the problem is we cannot ask/install/ldisc_put for a line discipline from kernel space.

so let us get the facts straight here. The device in question is using a
serial port to connect to the host and then multiplexing BT, FM and GPS
over it. My question again, what protocol does it talk.

Also why not just install the line discipline and then control the
subdevices via RFKILL?

You need to share some information about your hardware with us that
explain what are your objections and how it works.

> > > 3. Because of the UIM should know when to
> > install/uninstall line discipline, the /sys entry is created
> > a root called UIM (a new kobject) and UIM daemon would write
> > it's PID to it.
> > 
> > I don't understand this. This sounds like a broken concept
> > to me.
> 
> Yes, I don't feel good about it either. But how do I request for a line discipline from kernel space ?
> Currently a daemon has to run in user-space to maintain the ldisc, at all times, and I don't want to open TTY @ boot, and install Ldisc (tiocsetd) on it, without BT/FM or GPS core on chip being used - The Power Management team here would beat me up if I do that, 
> and hence the very dumb idea of passing the PID of the daemon via sysfs entry, and the driver sending SIGUSR2 to that PID, daemon doing a tiocsetd upon that signal.

Lets forget about this at all. This is not working out at all. We need
to figure out a workable solution.

> > > 4. As Alan suggested, If I make it self-contained by
> > pushing number of line disciplines to a slightly larger
> > number, then would it be OK ?
> > 
> > Just from a quick look, I think within a few review cycles
> > this might be
> > able to get proper upstream inclusion. No idea why bother
> > with staging
> > in the first place. Lets do this correctly.
> > 
> 
> The only reason I wanted this to be in staging was to have sort of continuous review process, and in hope the driver wouldn't be forgotten.

I dislike using the staging tree as review process. We can make a proper
review on LKML and go towards a real upstream solution.

Regards

Marcel

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Randy Dunlap]

On 03/24/10 09:38, Marcel Holtmann wrote:
> Hi Pavan,
> 
>>>> I wanted to somehow put this in staging because then
>>> it would probably have a thorough architectural review
>>> process.
>>>> Some details about this driver - 
>>>>
>>>> 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2
>>> and GPS (probably character device driver) using the
>>> EXPORTED symbols (-register/_unregister).
>>>>
>>>> 2. Much like the hciattach daemon which maintains
>>> N_HCI bluetooth line discipline, this driver will also have
>>> a User-Space  N_TI_WL Init manager (UIM) maintaining
>>> the Line discipline.
>>>
>>> can you explain why you think this is needed and we can not
>>> interface
>>> this directly. If it is a serial port, what protocol does
>>> it talk?
>>
>> Illustration: The BT driver on top of this ST driver, would create a hci0 interface, when someone does an DEVUP on that interface, the BT driver would then do a st-register - which in-turn would ask the hciattach-like daemon to install the line discipline for it via the sysfs entry.
>> The same concept goes for FM-V4L2 and GPS character driver.
>>
>> The core of the problem is we cannot ask/install/ldisc_put for a line discipline from kernel space.
> 
> so let us get the facts straight here. The device in question is using a
> serial port to connect to the host and then multiplexing BT, FM and GPS
> over it. My question again, what protocol does it talk.
> 
> Also why not just install the line discipline and then control the
> subdevices via RFKILL?
> 
> You need to share some information about your hardware with us that
> explain what are your objections and how it works.
> 
>>>> 3. Because of the UIM should know when to
>>> install/uninstall line discipline, the /sys entry is created
>>> a root called UIM (a new kobject) and UIM daemon would write
>>> it's PID to it.
>>>
>>> I don't understand this. This sounds like a broken concept
>>> to me.
>>
>> Yes, I don't feel good about it either. But how do I request for a line discipline from kernel space ?
>> Currently a daemon has to run in user-space to maintain the ldisc, at all times, and I don't want to open TTY @ boot, and install Ldisc (tiocsetd) on it, without BT/FM or GPS core on chip being used - The Power Management team here would beat me up if I do that, 
>> and hence the very dumb idea of passing the PID of the daemon via sysfs entry, and the driver sending SIGUSR2 to that PID, daemon doing a tiocsetd upon that signal.
> 
> Lets forget about this at all. This is not working out at all. We need
> to figure out a workable solution.
> 
>>>> 4. As Alan suggested, If I make it self-contained by
>>> pushing number of line disciplines to a slightly larger
>>> number, then would it be OK ?
>>>
>>> Just from a quick look, I think within a few review cycles
>>> this might be
>>> able to get proper upstream inclusion. No idea why bother
>>> with staging
>>> in the first place. Lets do this correctly.
>>>
>>
>> The only reason I wanted this to be in staging was to have sort of continuous review process, and in hope the driver wouldn't be forgotten.
> 
> I dislike using the staging tree as review process. We can make a proper
> review on LKML and go towards a real upstream solution.

I agree.  If I had a new driver, I would try to keep it out of staging,
not get it added there.

-- 
~Randy

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Marcel Holtmann <marcel@holtmann.org> wrote:

> From: Marcel Holtmann <marcel@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Greg KH" <gregkh@suse.de>, "PavanSavoy" <pavan_savoy@ti.com>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:08 PM
> Hi Pavan,
> 
> > > > I wanted to somehow put this in staging
> because then
> > > it would probably have a thorough architectural
> review
> > > process.
> > > > Some details about this driver - 
> > > > 
> > > > 1. This driver will be used by
> Bluetooth-BlueZ/FM-V4L2
> > > and GPS (probably character device driver) using
> the
> > > EXPORTED symbols (-register/_unregister).
> > > > 
> > > > 2. Much like the hciattach daemon which
> maintains
> > > N_HCI bluetooth line discipline, this driver will
> also have
> > > a User-Space  N_TI_WL Init manager (UIM)
> maintaining
> > > the Line discipline.
> > > 
> > > can you explain why you think this is needed and
> we can not
> > > interface
> > > this directly. If it is a serial port, what
> protocol does
> > > it talk?
> > 
> > Illustration: The BT driver on top of this ST driver,
> would create a hci0 interface, when someone does an DEVUP on
> that interface, the BT driver would then do a st-register -
> which in-turn would ask the hciattach-like daemon to install
> the line discipline for it via the sysfs entry.
> > The same concept goes for FM-V4L2 and GPS character
> driver.
> > 
> > The core of the problem is we cannot
> ask/install/ldisc_put for a line discipline from kernel
> space.
> 
> so let us get the facts straight here. The device in
> question is using a
> serial port to connect to the host and then multiplexing
> BT, FM and GPS
> over it. My question again, what protocol does it talk.

Ok, On TTY/4-wire UART, BT talks standard HCI, and HCI-LL for power management as in hci_ll.c/hciattach_ti.c which is already upstream.

And in a very similar way, FM talks over what is known as "channel 8" and GPS over "channel 9", Although these are not standard.

So, basically data going/coming to/out of chip is 
1,2,3,4 - HCI 
30,31,32,33 for HCI-LL
8 - FM
9 - GPS.

So consider this an extension of hci_ll/hci_ldisc but only more features to accomodate the FM and GPS.

> 
> Also why not just install the line discipline and then
> control the
> subdevices via RFKILL?

The chip side PM would be fine, and is being done so, st_kim.c creates the rfkill entries, and controls them locally, also allows applications to control them.
But ldisc can't be install upon boot, because UART clks would be used up for no reason at all.
(say on a mobile phone, how many times in a day - do we actually use BT/FM or GPS - so UART needs to be most often idle, and ldisc should be installed only upon requirement)

> 
> You need to share some information about your hardware with
> us that
> explain what are your objections and how it works.

Ok, I am already talking to my managers as to how much I can reveal etc..

> 
> > > > 3. Because of the UIM should know when to
> > > install/uninstall line discipline, the /sys entry
> is created
> > > a root called UIM (a new kobject) and UIM daemon
> would write
> > > it's PID to it.
> > > 
> > > I don't understand this. This sounds like a
> broken concept
> > > to me.
> > 
> > Yes, I don't feel good about it either. But how do I
> request for a line discipline from kernel space ?
> > Currently a daemon has to run in user-space to
> maintain the ldisc, at all times, and I don't want to open
> TTY @ boot, and install Ldisc (tiocsetd) on it, without
> BT/FM or GPS core on chip being used - The Power Management
> team here would beat me up if I do that, 
> > and hence the very dumb idea of passing the PID of the
> daemon via sysfs entry, and the driver sending SIGUSR2 to
> that PID, daemon doing a tiocsetd upon that signal.
> 
> Lets forget about this at all. This is not working out at
> all. We need
> to figure out a workable solution.

Yes, couple were discussed, like creating a device node, and UIM would open device node, and ldisc driver then can do a fasync/SIGIO upon it - Sounds complex for a simplistic job.
Any more suggestion ?

requirement is the daemon should open/set-baud/and then TIOCSETD only upon requirement for either BT, FM or GPS.
which is currently only known to ldisc driver via the st_register function.

> > > > 4. As Alan suggested, If I make it
> self-contained by
> > > pushing number of line disciplines to a slightly
> larger
> > > number, then would it be OK ?
> > > 
> > > Just from a quick look, I think within a few
> review cycles
> > > this might be
> > > able to get proper upstream inclusion. No idea
> why bother
> > > with staging
> > > in the first place. Lets do this correctly.
> > > 
> > 
> > The only reason I wanted this to be in staging was to
> have sort of continuous review process, and in hope the
> driver wouldn't be forgotten.
> 
> I dislike using the staging tree as review process. We can
> make a proper
> review on LKML and go towards a real upstream solution.

Well, the idea is the driver isn't forgotten when this sort of thing happens.
Controversial (may be wrong) concepts like sending signal from kernel to user-space, parsing the script request via firmware class, creating a root kobject just to create a sysfs entry.

I am ok with it going in staging or not - but just want the review to happen, and thanks a lot for having a look.

> Regards
> 
> Marcel
> 
> 
> 


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Alan Cox]

Ok I had a brief dig

Making a driver able to say "and open me in this ldisc" is about ten
lines of code to the core tty layer if that.

There is one caveat - the actual ldisc attach method for an ldisc attach
isn't allowed to fail the attach. That's something we eventually need to
fix anyway.

Otherwise it doesn't look too scary and it would occur when the user
opened the file not when the device was created.

Alan

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Marcel Holtmann" <marcel@holtmann.org>, "Greg KH" <gregkh@suse.de>, "PavanSavoy" <pavan_savoy@ti.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:33 PM
> Ok I had a brief dig
> 
> Making a driver able to say "and open me in this ldisc" is
> about ten
> lines of code to the core tty layer if that.
> 
> There is one caveat - the actual ldisc attach method for an
> ldisc attach
> isn't allowed to fail the attach. That's something we
> eventually need to
> fix anyway.
> 
> Otherwise it doesn't look too scary and it would occur when
> the user
> opened the file not when the device was created.

So as I understand the user-space application/daemon should do an open on the TTY and then do nothing ?
Somewhere down the line, the driver may do a tty_set_ldisc, and use it the way it wants to ?

Isn't there a mechanism for the tty_set_ldisc to do what _open does ?
I mean there might be plenty of devices on UART which might not need /dev/tty at all ? i.e An App need not open for a ldisc to be installed.


> 
> Alan
> 


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Alan Cox]

> Isn't there a mechanism for the tty_set_ldisc to do what _open does ?
> I mean there might be plenty of devices on UART which might not need /dev/tty at all ? i.e An App need not open for a ldisc to be installed.

There is no mechanism to have an open tty without having an open file
attached to it - and changing that would be very very non trivial. Plus
you still need a way to tell the kernel you want the device in question
active. That probably should get addressed some day but its not a quick
fix up!

Alan

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Marcel Holtmann" <marcel@holtmann.org>, "Greg KH" <gregkh@suse.de>, "PavanSavoy" <pavan_savoy@ti.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:56 PM
> > Isn't there a mechanism for the
> tty_set_ldisc to do what _open does ?
> > I mean there might be plenty of devices on UART which
> might not need /dev/tty at all ? i.e An App need not open
> for a ldisc to be installed.
> 
> There is no mechanism to have an open tty without having an
> open file
> attached to it - and changing that would be very very non
> trivial. Plus
> you still need a way to tell the kernel you want the device
> in question
> active. That probably should get addressed some day but its
> not a quick
> fix up!

Which puts me back to square 1, the requirement is TTY device should be open, only when either BT, FM or GPS would want to use it.
[with your patch one of the steps of installing ldisc would be reduced upon opening].

Now from kernel-space which is the first to get notification about requirement of BT/FM or GPS, I somehow have to communicate it to user-space, without the much disliked sysfs entry method.

How do I tell the user-space when I want the TTY device to be opened ?
Actually why do I even need a TTY device in this case - right ?
ldisc driver can do the tty->ops->write and tty_read and put it up on different interfaces like eth0/hci0 or /dev/radio0 etc..

That would mean, a device can be on UART, a ldisc driver attached to it, and doesn't require a user-space daemon to maintain the device node.

> 
> Alan
> 


      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Alan Cox]

> Which puts me back to square 1, the requirement is TTY device should be open, only when either BT, FM or GPS would want to use it.
> [with your patch one of the steps of installing ldisc would be reduced upon opening].

Perhaps but its up to you how you write your low level driver and how the
ldisc indicates it wishes to be active (eg speed B0 is used to indicate
'no carrier' in many cases)

> Actually why do I even need a TTY device in this case - right ?
> ldisc driver can do the tty->ops->write and tty_read and put it up on different interfaces like eth0/hci0 or /dev/radio0 etc..

You don't need a tty if you are simply demuxing some kind of stream of
bytes to/from the hardware and you gain nothing from the tty layer and
user space interfaces such as control signal and speed setting.

That may be even cleaner in your case as you can then then provide
suitable links between your demux and the drivers attached to it
indicating when they should be on or off.

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Marcel Holtmann" <marcel@holtmann.org>, "Greg KH" <gregkh@suse.de>, "PavanSavoy" <pavan_savoy@ti.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 11:09 PM
> > Which puts me back to square 1,
> the requirement is TTY device should be open, only when
> either BT, FM or GPS would want to use it.
> > [with your patch one of the steps of installing ldisc
> would be reduced upon opening].
> 
> Perhaps but its up to you how you write your low level
> driver and how the
> ldisc indicates it wishes to be active (eg speed B0 is used
> to indicate
> 'no carrier' in many cases)
> 
> > Actually why do I even need a TTY device in this case
> - right ?
> > ldisc driver can do the tty->ops->write and
> tty_read and put it up on different interfaces like
> eth0/hci0 or /dev/radio0 etc..
> 
> You don't need a tty if you are simply demuxing some kind
> of stream of
> bytes to/from the hardware and you gain nothing from the
> tty layer and
> user space interfaces such as control signal and speed
> setting.
> 

I still want to maintain this as a ldisc driver and the TTY layer is still required to be able to use this with different sort of serial drivers.

example:
We do a have a system here where both 8250/omap-serial co-exist creating their own device nodes (ttyS for 8250, ttyO for omap-serial) and I would want to be able to on boot suggest which serial driver to use, so I can open/install ldisc on ttyS or on ttyO.


> That may be even cleaner in your case as you can then then
> provide
> suitable links between your demux and the drivers attached
> to it
> indicating when they should be on or off.

And as Marcel suggested, can't really put in the PM/UART-clk shut off code in ldisc driver because few of these driver provide interfaces and few don't.

So is there no way this can be accepted with the sysfs entry way of communication ?


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Marcel Holtmann]

Hi Pavan,

> > > Which puts me back to square 1,
> > the requirement is TTY device should be open, only when
> > either BT, FM or GPS would want to use it.
> > > [with your patch one of the steps of installing ldisc
> > would be reduced upon opening].
> > 
> > Perhaps but its up to you how you write your low level
> > driver and how the
> > ldisc indicates it wishes to be active (eg speed B0 is used
> > to indicate
> > 'no carrier' in many cases)
> > 
> > > Actually why do I even need a TTY device in this case
> > - right ?
> > > ldisc driver can do the tty->ops->write and
> > tty_read and put it up on different interfaces like
> > eth0/hci0 or /dev/radio0 etc..
> > 
> > You don't need a tty if you are simply demuxing some kind
> > of stream of
> > bytes to/from the hardware and you gain nothing from the
> > tty layer and
> > user space interfaces such as control signal and speed
> > setting.
> > 
> 
> I still want to maintain this as a ldisc driver and the TTY layer is still required to be able to use this with different sort of serial drivers.
> 
> example:
> We do a have a system here where both 8250/omap-serial co-exist creating their own device nodes (ttyS for 8250, ttyO for omap-serial) and I would want to be able to on boot suggest which serial driver to use, so I can open/install ldisc on ttyS or on ttyO.
> 
> 
> > That may be even cleaner in your case as you can then then
> > provide
> > suitable links between your demux and the drivers attached
> > to it
> > indicating when they should be on or off.
> 
> And as Marcel suggested, can't really put in the PM/UART-clk shut off code in ldisc driver because few of these driver provide interfaces and few don't.
> 
> So is there no way this can be accepted with the sysfs entry way of communication ?

to be quite honest, I can't see how that can be accepted right now. It
looks wrong on too many levels.

Regards

Marcel

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

Marcel,

--- On Thu, 25/3/10, Marcel Holtmann <marcel@holtmann.org> wrote:

> From: Marcel Holtmann <marcel@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>, "Greg KH" <gregkh@suse.de>, "PavanSavoy" <pavan_savoy@ti.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Thursday, 25 March, 2010, 2:24 AM
> Hi Pavan,
> 
> > > > Which puts me back to square 1,
> > > the requirement is TTY device should be open,
> only when
> > > either BT, FM or GPS would want to use it.
> > > > [with your patch one of the steps of
> installing ldisc
> > > would be reduced upon opening].
> > > 
> > > Perhaps but its up to you how you write your low
> level
> > > driver and how the
> > > ldisc indicates it wishes to be active (eg speed
> B0 is used
> > > to indicate
> > > 'no carrier' in many cases)
> > > 
> > > > Actually why do I even need a TTY device in
> this case
> > > - right ?
> > > > ldisc driver can do the
> tty->ops->write and
> > > tty_read and put it up on different interfaces
> like
> > > eth0/hci0 or /dev/radio0 etc..
> > > 
> > > You don't need a tty if you are simply demuxing
> some kind
> > > of stream of
> > > bytes to/from the hardware and you gain nothing
> from the
> > > tty layer and
> > > user space interfaces such as control signal and
> speed
> > > setting.
> > > 
> > 
> > I still want to maintain this as a ldisc driver and
> the TTY layer is still required to be able to use this with
> different sort of serial drivers.
> > 
> > example:
> > We do a have a system here where both 8250/omap-serial
> co-exist creating their own device nodes (ttyS for 8250,
> ttyO for omap-serial) and I would want to be able to on boot
> suggest which serial driver to use, so I can open/install
> ldisc on ttyS or on ttyO.
> > 
> > 
> > > That may be even cleaner in your case as you can
> then then
> > > provide
> > > suitable links between your demux and the drivers
> attached
> > > to it
> > > indicating when they should be on or off.
> > 
> > And as Marcel suggested, can't really put in the
> PM/UART-clk shut off code in ldisc driver because few of
> these driver provide interfaces and few don't.
> > 
> > So is there no way this can be accepted with the sysfs
> entry way of communication ?
> 
> to be quite honest, I can't see how that can be accepted
> right now. It
> looks wrong on too many levels.

Sigh -
So to save power, and open/install tty-ldisc only when required, the sysfs entry was introduced.
So now I guess I have 2 options :-

1. Fix the UART/LDISC upon boot by the daemon, get away with the sysfs entry + signaling altogether.
2. find a better way of telling the user-space daemon to open/install the line discipline.

- So any suggestions on option 2 ? like some event mechanism which is simple and clean ?

While we are at it, I will send across the BT driver too which makes use of this LDISC.

> 
> Regards
> 
> Marcel
> 
> 
> 


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Marcel Holtmann]

Hi Pavan,

> > > > > I wanted to somehow put this in staging
> > because then
> > > > it would probably have a thorough architectural
> > review
> > > > process.
> > > > > Some details about this driver - 
> > > > > 
> > > > > 1. This driver will be used by
> > Bluetooth-BlueZ/FM-V4L2
> > > > and GPS (probably character device driver) using
> > the
> > > > EXPORTED symbols (-register/_unregister).
> > > > > 
> > > > > 2. Much like the hciattach daemon which
> > maintains
> > > > N_HCI bluetooth line discipline, this driver will
> > also have
> > > > a User-Space  N_TI_WL Init manager (UIM)
> > maintaining
> > > > the Line discipline.
> > > > 
> > > > can you explain why you think this is needed and
> > we can not
> > > > interface
> > > > this directly. If it is a serial port, what
> > protocol does
> > > > it talk?
> > > 
> > > Illustration: The BT driver on top of this ST driver,
> > would create a hci0 interface, when someone does an DEVUP on
> > that interface, the BT driver would then do a st-register -
> > which in-turn would ask the hciattach-like daemon to install
> > the line discipline for it via the sysfs entry.
> > > The same concept goes for FM-V4L2 and GPS character
> > driver.
> > > 
> > > The core of the problem is we cannot
> > ask/install/ldisc_put for a line discipline from kernel
> > space.
> > 
> > so let us get the facts straight here. The device in
> > question is using a
> > serial port to connect to the host and then multiplexing
> > BT, FM and GPS
> > over it. My question again, what protocol does it talk.
> 
> Ok, On TTY/4-wire UART, BT talks standard HCI, and HCI-LL for power management as in hci_ll.c/hciattach_ti.c which is already upstream.
> 
> And in a very similar way, FM talks over what is known as "channel 8" and GPS over "channel 9", Although these are not standard.
> 
> So, basically data going/coming to/out of chip is 
> 1,2,3,4 - HCI 
> 30,31,32,33 for HCI-LL
> 8 - FM
> 9 - GPS.
> 
> So consider this an extension of hci_ll/hci_ldisc but only more features to accomodate the FM and GPS.

So why are we not making the hci_ll into a generic driver that can
register besides Bluetooth also FM and GPS.

Then we can attach that driver to the TTY via line discipline on boot
and let the LL part handle the power management.

Registration of Bluetooth device, FM and GPS nodes are done via RFKILL
that the LL driver exports.

> > Also why not just install the line discipline and then
> > control the
> > subdevices via RFKILL?
> 
> The chip side PM would be fine, and is being done so, st_kim.c creates the rfkill entries, and controls them locally, also allows applications to control them.
> But ldisc can't be install upon boot, because UART clks would be used up for no reason at all.
> (say on a mobile phone, how many times in a day - do we actually use BT/FM or GPS - so UART needs to be most often idle, and ldisc should be installed only upon requirement)

I think the driver should make sure it doesn't use the UART clocks if in
deep sleep. This has nothing to do with installing the line discipline
on boot via a userspace tool.

You do the power management for the hci_ll driver already today. So why
can't we do the same in this driver?

Another way to view this is that the LL driver has to create a virtual
bus for Bluetooth, FM and GPS devices. However RFKILL might be a bit
more suitable and simpler.

Regards

Marcel

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Marcel Holtmann <marcel@holtmann.org> wrote:

> From: Marcel Holtmann <marcel@holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Greg KH" <gregkh@suse.de>, "PavanSavoy" <pavan_savoy@ti.com>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:45 PM
> Hi Pavan,
> 
> > > > > > I wanted to somehow put this in
> staging
> > > because then
> > > > > it would probably have a thorough
> architectural
> > > review
> > > > > process.
> > > > > > Some details about this driver - 
> > > > > > 
> > > > > > 1. This driver will be used by
> > > Bluetooth-BlueZ/FM-V4L2
> > > > > and GPS (probably character device
> driver) using
> > > the
> > > > > EXPORTED symbols
> (-register/_unregister).
> > > > > > 
> > > > > > 2. Much like the hciattach daemon
> which
> > > maintains
> > > > > N_HCI bluetooth line discipline, this
> driver will
> > > also have
> > > > > a User-Space  N_TI_WL Init manager
> (UIM)
> > > maintaining
> > > > > the Line discipline.
> > > > > 
> > > > > can you explain why you think this is
> needed and
> > > we can not
> > > > > interface
> > > > > this directly. If it is a serial port,
> what
> > > protocol does
> > > > > it talk?
> > > > 
> > > > Illustration: The BT driver on top of this
> ST driver,
> > > would create a hci0 interface, when someone does
> an DEVUP on
> > > that interface, the BT driver would then do a
> st-register -
> > > which in-turn would ask the hciattach-like daemon
> to install
> > > the line discipline for it via the sysfs entry.
> > > > The same concept goes for FM-V4L2 and GPS
> character
> > > driver.
> > > > 
> > > > The core of the problem is we cannot
> > > ask/install/ldisc_put for a line discipline from
> kernel
> > > space.
> > > 
> > > so let us get the facts straight here. The device
> in
> > > question is using a
> > > serial port to connect to the host and then
> multiplexing
> > > BT, FM and GPS
> > > over it. My question again, what protocol does it
> talk.
> > 
> > Ok, On TTY/4-wire UART, BT talks standard HCI, and
> HCI-LL for power management as in hci_ll.c/hciattach_ti.c
> which is already upstream.
> > 
> > And in a very similar way, FM talks over what is known
> as "channel 8" and GPS over "channel 9", Although these are
> not standard.
> > 
> > So, basically data going/coming to/out of chip is 
> > 1,2,3,4 - HCI 
> > 30,31,32,33 for HCI-LL
> > 8 - FM
> > 9 - GPS.
> > 
> > So consider this an extension of hci_ll/hci_ldisc but
> only more features to accomodate the FM and GPS.
> 
> So why are we not making the hci_ll into a generic driver
> that can
> register besides Bluetooth also FM and GPS.
> 
> Then we can attach that driver to the TTY via line
> discipline on boot
> and let the LL part handle the power management.
> 

Well hci_ll is tied up with hci_ldisc, we might not even want BT/FM on system, may be just GPS (like we have for 1 version of chip).
In that case GPS directly uses the ST line discipline.

Also few other things like firmware download, a chance for the ldisc driver to be platform device, to take in chip enable GPIOs, is sort of appropriate for a new driver isn't it ?


> Registration of Bluetooth device, FM and GPS nodes are done
> via RFKILL
> that the LL driver exports.
> 
> > > Also why not just install the line discipline and
> then
> > > control the
> > > subdevices via RFKILL?
> > 
> > The chip side PM would be fine, and is being done so,
> st_kim.c creates the rfkill entries, and controls them
> locally, also allows applications to control them.
> > But ldisc can't be install upon boot, because UART
> clks would be used up for no reason at all.
> > (say on a mobile phone, how many times in a day - do
> we actually use BT/FM or GPS - so UART needs to be most
> often idle, and ldisc should be installed only upon
> requirement)
> 
> I think the driver should make sure it doesn't use the UART
> clocks if in
> deep sleep. This has nothing to do with installing the line
> discipline
> on boot via a userspace tool.
> 
> You do the power management for the hci_ll driver already
> today. So why
> can't we do the same in this driver?
> 

Correct, However that piece of Android code, as far as I have seen it depends on bunch of interfaces provided by the UART driver.
This ldisc on other hand doesn't can work on 8250 driver or with complicated ones like the omap-serial which provides such interfaces to shut off UART clks as and when required.

> Another way to view this is that the LL driver has to
> create a virtual
> bus for Bluetooth, FM and GPS devices. However RFKILL might
> be a bit
> more suitable and simpler.
> 

Currently rfkill provided is just sort of an extension, but really it just depends on what protocol (bt, fm, GPS) is being ST_registered, the relevant chip_enable gpio is picked up from platform_device entry in arch/XX/board-YY.c and enabled.

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


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Marcel Holtmann]

Hi Pavan,

> > > > > > > I wanted to somehow put this in
> > staging
> > > > because then
> > > > > > it would probably have a thorough
> > architectural
> > > > review
> > > > > > process.
> > > > > > > Some details about this driver - 
> > > > > > > 
> > > > > > > 1. This driver will be used by
> > > > Bluetooth-BlueZ/FM-V4L2
> > > > > > and GPS (probably character device
> > driver) using
> > > > the
> > > > > > EXPORTED symbols
> > (-register/_unregister).
> > > > > > > 
> > > > > > > 2. Much like the hciattach daemon
> > which
> > > > maintains
> > > > > > N_HCI bluetooth line discipline, this
> > driver will
> > > > also have
> > > > > > a User-Space  N_TI_WL Init manager
> > (UIM)
> > > > maintaining
> > > > > > the Line discipline.
> > > > > > 
> > > > > > can you explain why you think this is
> > needed and
> > > > we can not
> > > > > > interface
> > > > > > this directly. If it is a serial port,
> > what
> > > > protocol does
> > > > > > it talk?
> > > > > 
> > > > > Illustration: The BT driver on top of this
> > ST driver,
> > > > would create a hci0 interface, when someone does
> > an DEVUP on
> > > > that interface, the BT driver would then do a
> > st-register -
> > > > which in-turn would ask the hciattach-like daemon
> > to install
> > > > the line discipline for it via the sysfs entry.
> > > > > The same concept goes for FM-V4L2 and GPS
> > character
> > > > driver.
> > > > > 
> > > > > The core of the problem is we cannot
> > > > ask/install/ldisc_put for a line discipline from
> > kernel
> > > > space.
> > > > 
> > > > so let us get the facts straight here. The device
> > in
> > > > question is using a
> > > > serial port to connect to the host and then
> > multiplexing
> > > > BT, FM and GPS
> > > > over it. My question again, what protocol does it
> > talk.
> > > 
> > > Ok, On TTY/4-wire UART, BT talks standard HCI, and
> > HCI-LL for power management as in hci_ll.c/hciattach_ti.c
> > which is already upstream.
> > > 
> > > And in a very similar way, FM talks over what is known
> > as "channel 8" and GPS over "channel 9", Although these are
> > not standard.
> > > 
> > > So, basically data going/coming to/out of chip is 
> > > 1,2,3,4 - HCI 
> > > 30,31,32,33 for HCI-LL
> > > 8 - FM
> > > 9 - GPS.
> > > 
> > > So consider this an extension of hci_ll/hci_ldisc but
> > only more features to accomodate the FM and GPS.
> > 
> > So why are we not making the hci_ll into a generic driver
> > that can
> > register besides Bluetooth also FM and GPS.
> > 
> > Then we can attach that driver to the TTY via line
> > discipline on boot
> > and let the LL part handle the power management.
> > 
> 
> Well hci_ll is tied up with hci_ldisc, we might not even want BT/FM on system, may be just GPS (like we have for 1 version of chip).
> In that case GPS directly uses the ST line discipline.

that is what I am saying. Lets take the hci_ll driver out of it and
create some sort of LL subsystem. Then the TI Bluetooth driver just uses
LL and doesn't have to use hci_ldisc framework.

Don't be afraid of taking hci_ll out of the Bluetooth part and make it a
"subdriver" of your LL driver/ST line discipline.

> Also few other things like firmware download, a chance for the ldisc driver to be platform device, to take in chip enable GPIOs, is sort of appropriate for a new driver isn't it ?

I don't see a problem with it in general. However having some more
details would help here to give clearer directions.

> > Registration of Bluetooth device, FM and GPS nodes are done
> > via RFKILL
> > that the LL driver exports.
> > 
> > > > Also why not just install the line discipline and
> > then
> > > > control the
> > > > subdevices via RFKILL?
> > > 
> > > The chip side PM would be fine, and is being done so,
> > st_kim.c creates the rfkill entries, and controls them
> > locally, also allows applications to control them.
> > > But ldisc can't be install upon boot, because UART
> > clks would be used up for no reason at all.
> > > (say on a mobile phone, how many times in a day - do
> > we actually use BT/FM or GPS - so UART needs to be most
> > often idle, and ldisc should be installed only upon
> > requirement)
> > 
> > I think the driver should make sure it doesn't use the UART
> > clocks if in
> > deep sleep. This has nothing to do with installing the line
> > discipline
> > on boot via a userspace tool.
> > 
> > You do the power management for the hci_ll driver already
> > today. So why
> > can't we do the same in this driver?
> > 
> 
> Correct, However that piece of Android code, as far as I have seen it depends on bunch of interfaces provided by the UART driver.
> This ldisc on other hand doesn't can work on 8250 driver or with complicated ones like the omap-serial which provides such interfaces to shut off UART clks as and when required.

That sounds just like an excuse. We should be able to abstract this
properly and make it work for Android and generic devices.

> > Another way to view this is that the LL driver has to
> > create a virtual
> > bus for Bluetooth, FM and GPS devices. However RFKILL might
> > be a bit
> > more suitable and simpler.
> > 
> 
> Currently rfkill provided is just sort of an extension, but really it just depends on what protocol (bt, fm, GPS) is being ST_registered, the relevant chip_enable gpio is picked up from platform_device entry in arch/XX/board-YY.c and enabled.

If possible please share some more details about the protocol in use and
the platform architecture of the chip. I think you are trying to make
this more complicated than it has to be.

Regards

Marcel

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Alan Cox]

> The core of the problem is we cannot ask/install/ldisc_put for a line discipline from kernel space.

The device is always in WL protocol mode and starts this way ?

If so lets simply fix the tty layer to allow a driver to set the initial
ldisc.

> The only reason I wanted this to be in staging was to have sort of continuous review process, and in hope the driver wouldn't be forgotten.

I would certainly prefer this as it is much easier to refine this way

Alan

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Marcel Holtmann" <marcel@holtmann.org>, "Greg KH" <gregkh@suse.de>, "PavanSavoy" <pavan_savoy@ti.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:28 PM
> > The core of the problem is we
> cannot ask/install/ldisc_put for a line discipline from
> kernel space.
> 
> The device is always in WL protocol mode and starts this
> way ?

Totally makes sense, just EXPORT the symbol tty_set_ldisc or tiocsetd, so that kernel space drivers can install/un-install LDISC.

> 
> If so lets simply fix the tty layer to allow a driver to
> set the initial
> ldisc.
> 
> > The only reason I wanted this to be in staging was to
> have sort of continuous review process, and in hope the
> driver wouldn't be forgotten.
> 
> I would certainly prefer this as it is much easier to
> refine this way
> 
> Alan
> 


      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Greg KH]

On Wed, Mar 24, 2010 at 09:11:45AM -0700, Marcel Holtmann wrote:
> > I wanted to somehow put this in staging because then it would probably have a thorough architectural review process.
> > Some details about this driver - 
> > 
> > 1. This driver will be used by Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device driver) using the EXPORTED symbols (-register/_unregister).
> > 
> > 2. Much like the hciattach daemon which maintains N_HCI bluetooth line discipline, this driver will also have a User-Space  N_TI_WL Init manager (UIM) maintaining the Line discipline.
> 
> can you explain why you think this is needed and we can not interface
> this directly. If it is a serial port, what protocol does it talk?
> 
> > 3. Because of the UIM should know when to install/uninstall line discipline, the /sys entry is created a root called UIM (a new kobject) and UIM daemon would write it's PID to it.
> 
> I don't understand this. This sounds like a broken concept to me.

I also agree, those sysfs files are not acceptable, and will not work
as-designed due to the pid namespace issues :(

thanks,

greg k-h

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Greg KH <gregkh@suse.de> wrote:

> From: Greg KH <gregkh@suse.de>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Marcel Holtmann" <marcel@holtmann.org>
> Cc: "Pavan Savoy" <pavan_savoy@yahoo.co.in>, "PavanSavoy" <pavan_savoy@ti.com>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 9:56 PM
> On Wed, Mar 24, 2010 at 09:11:45AM
> -0700, Marcel Holtmann wrote:
> > > I wanted to somehow put this in staging because
> then it would probably have a thorough architectural review
> process.
> > > Some details about this driver - 
> > > 
> > > 1. This driver will be used by
> Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device
> driver) using the EXPORTED symbols (-register/_unregister).
> > > 
> > > 2. Much like the hciattach daemon which maintains
> N_HCI bluetooth line discipline, this driver will also have
> a User-Space  N_TI_WL Init manager (UIM) maintaining
> the Line discipline.
> > 
> > can you explain why you think this is needed and we
> can not interface
> > this directly. If it is a serial port, what protocol
> does it talk?
> > 
> > > 3. Because of the UIM should know when to
> install/uninstall line discipline, the /sys entry is created
> a root called UIM (a new kobject) and UIM daemon would write
> it's PID to it.
> > 
> > I don't understand this. This sounds like a broken
> concept to me.
> 
> I also agree, those sysfs files are not acceptable, and
> will not work
> as-designed due to the pid namespace issues :(

Ok, How do I then from kernel space, ask a user-space daemon to open the TTY port and do a tiocsetd on it ? 
[i.e ask for a line discipline to be installed ?]

Can't open the TTY and TIOCSETD upon boot, because BT, FM and GPS might be used or not used anytime.

And the idea of creating a device node, specifically for this and then doing an fasync/SIGIO was somehow rubbished.

> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Greg KH]

On Wed, Mar 24, 2010 at 10:05:19PM +0530, Pavan Savoy wrote:
> --- On Wed, 24/3/10, Greg KH <gregkh@suse.de> wrote:
> 
> > From: Greg KH <gregkh@suse.de>
> > Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> > To: "Marcel Holtmann" <marcel@holtmann.org>
> > Cc: "Pavan Savoy" <pavan_savoy@yahoo.co.in>, "PavanSavoy" <pavan_savoy@ti.com>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> > Date: Wednesday, 24 March, 2010, 9:56 PM
> > On Wed, Mar 24, 2010 at 09:11:45AM
> > -0700, Marcel Holtmann wrote:
> > > > I wanted to somehow put this in staging because
> > then it would probably have a thorough architectural review
> > process.
> > > > Some details about this driver - 
> > > > 
> > > > 1. This driver will be used by
> > Bluetooth-BlueZ/FM-V4L2 and GPS (probably character device
> > driver) using the EXPORTED symbols (-register/_unregister).
> > > > 
> > > > 2. Much like the hciattach daemon which maintains
> > N_HCI bluetooth line discipline, this driver will also have
> > a User-Space? N_TI_WL Init manager (UIM) maintaining
> > the Line discipline.
> > > 
> > > can you explain why you think this is needed and we
> > can not interface
> > > this directly. If it is a serial port, what protocol
> > does it talk?
> > > 
> > > > 3. Because of the UIM should know when to
> > install/uninstall line discipline, the /sys entry is created
> > a root called UIM (a new kobject) and UIM daemon would write
> > it's PID to it.
> > > 
> > > I don't understand this. This sounds like a broken
> > concept to me.
> > 
> > I also agree, those sysfs files are not acceptable, and
> > will not work
> > as-designed due to the pid namespace issues :(
> 
> Ok, How do I then from kernel space, ask a user-space daemon to open the TTY port and do a tiocsetd on it ? 
> [i.e ask for a line discipline to be installed ?]

What would cause the kernel to want to tell userspace to do this?  Is it
an external event that happens somehow that userspace should know to
look for?

> Can't open the TTY and TIOCSETD upon boot, because BT, FM and GPS
> might be used or not used anytime.

What causes them to want to be used?  The user, right?

> And the idea of creating a device node, specifically for this and then
> doing an fasync/SIGIO was somehow rubbished.

Why?

thanks,

greg k-h

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Wed, 24/3/10, Greg KH <gregkh@suse.de> wrote:

> From: Greg KH <gregkh@suse.de>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: "Marcel Holtmann" <marcel@holtmann.org>, "PavanSavoy" <pavan_savoy@ti.com>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
> Date: Wednesday, 24 March, 2010, 10:22 PM
> On Wed, Mar 24, 2010 at 10:05:19PM
> +0530, Pavan Savoy wrote:
> > --- On Wed, 24/3/10, Greg KH <gregkh@suse.de>
> wrote:
> > 
> > > From: Greg KH <gregkh@suse.de>
> > > Subject: Re: [PATCH 4/6] drivers:misc: sources
> for Init manager module
> > > To: "Marcel Holtmann" <marcel@holtmann.org>
> > > Cc: "Pavan Savoy" <pavan_savoy@yahoo.co.in>,
> "PavanSavoy" <pavan_savoy@ti.com>,
> "alan@lxorguk.ukuu.org.uk"
> <alan@lxorguk.ukuu.org.uk>,
> "linux-kernel@vger.kernel.org"
> <linux-kernel@vger.kernel.org>
> > > Date: Wednesday, 24 March, 2010, 9:56 PM
> > > On Wed, Mar 24, 2010 at 09:11:45AM
> > > -0700, Marcel Holtmann wrote:
> > > > > I wanted to somehow put this in staging
> because
> > > then it would probably have a thorough
> architectural review
> > > process.
> > > > > Some details about this driver - 
> > > > > 
> > > > > 1. This driver will be used by
> > > Bluetooth-BlueZ/FM-V4L2 and GPS (probably
> character device
> > > driver) using the EXPORTED symbols
> (-register/_unregister).
> > > > > 
> > > > > 2. Much like the hciattach daemon which
> maintains
> > > N_HCI bluetooth line discipline, this driver will
> also have
> > > a User-Space? N_TI_WL Init manager (UIM)
> maintaining
> > > the Line discipline.
> > > > 
> > > > can you explain why you think this is needed
> and we
> > > can not interface
> > > > this directly. If it is a serial port, what
> protocol
> > > does it talk?
> > > > 
> > > > > 3. Because of the UIM should know when
> to
> > > install/uninstall line discipline, the /sys entry
> is created
> > > a root called UIM (a new kobject) and UIM daemon
> would write
> > > it's PID to it.
> > > > 
> > > > I don't understand this. This sounds like a
> broken
> > > concept to me.
> > > 
> > > I also agree, those sysfs files are not
> acceptable, and
> > > will not work
> > > as-designed due to the pid namespace issues :(
> > 
> > Ok, How do I then from kernel space, ask a user-space
> daemon to open the TTY port and do a tiocsetd on it ? 
> > [i.e ask for a line discipline to be installed ?]
> 
> What would cause the kernel to want to tell userspace to do
> this?  Is it
> an external event that happens somehow that userspace
> should know to
> look for?

Yes, Userspace events like opening the /dev/radio0 device for FM, or hci0 interface for BT.
However the apps/stack would not want to know what LDISC is being used underneath, well they might not even want to know whether it's TTY or USB/i2C - right ?

> > Can't open the TTY and TIOCSETD upon boot, because BT,
> FM and GPS
> > might be used or not used anytime.
> 
> What causes them to want to be used?  The user,
> right?
> 
> > And the idea of creating a device node, specifically
> for this and then
> > doing an fasync/SIGIO was somehow rubbished.
> 
> Why?

It does pretty much the same thing, But we would be stuffing in more interfaces to the already huge driver.
I mean just 3 fops on the device ? open/ioctl-fasync/close - but it also uses the SIGnaling concept - but not via PID though.

Alan's talking about opening up the LDISC installation to kernel (say EXPORTING tty_set_ldisc/tiocsetd), That's like ideal scenario in this case.

> 
> thanks,
> 
> greg k-h
> 


      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH 4/6] drivers:misc: sources for Init manager module

[Alan Cox]

> Alan's talking about opening up the LDISC installation to kernel (say EXPORTING tty_set_ldisc/tiocsetd), That's like ideal scenario in this case.

Ok I lied - its four lines of code changing, and just set

	.ldisc = N_whatever

in your tty_driver

Marcel - that should also clean up some of the other pending goodies

[Untested Patch]

--

tty: Allow the driver to force an ldisc on open

From: Alan Cox <alan@linux.intel.com>

We need this because some hardware is always in various mux or control
modes. At the moment we do handstands via userspace to sort this out on
devices where it makes no sense. Given the size of the patch to fix this
inanity we might as well do so.

Signed-off-by: Alan Cox <alan@linux.intel.com>
---

 drivers/char/tty_ldisc.c   |    6 +++---
 include/linux/tty_driver.h |    1 +
 2 files changed, 4 insertions(+), 3 deletions(-)


diff --git a/drivers/char/tty_ldisc.c b/drivers/char/tty_ldisc.c
index 500e740..b149f9c 100644
--- a/drivers/char/tty_ldisc.c
+++ b/drivers/char/tty_ldisc.c
@@ -863,8 +863,8 @@ void tty_ldisc_release(struct tty_struct *tty, struct tty_struct *o_tty)
 	/* Force an oops if we mess this up */
 	tty->ldisc = NULL;
 
-	/* Ensure the next open requests the N_TTY ldisc */
-	tty_set_termios_ldisc(tty, N_TTY);
+	/* Ensure the next open requests the expected (usually N_TTY) ldisc */
+	tty_set_termios_ldisc(tty, tty->driver->ldisc);
 	mutex_unlock(&tty->ldisc_mutex);
 
 	/* This will need doing differently if we need to lock */
@@ -885,7 +885,7 @@ void tty_ldisc_release(struct tty_struct *tty, struct tty_struct *o_tty)
 
 void tty_ldisc_init(struct tty_struct *tty)
 {
-	struct tty_ldisc *ld = tty_ldisc_get(N_TTY);
+	struct tty_ldisc *ld = tty_ldisc_get(tty->driver->ldisc);
 	if (IS_ERR(ld))
 		panic("n_tty: init_tty");
 	tty_ldisc_assign(tty, ld);
diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
index b086779..fc22a41 100644
--- a/include/linux/tty_driver.h
+++ b/include/linux/tty_driver.h
@@ -291,6 +291,7 @@ struct tty_driver {
 	short	type;		/* type of tty driver */
 	short	subtype;	/* subtype of tty driver */
 	struct ktermios init_termios; /* Initial termios */
+	int	ldisc;		/* initial ldisc */
 	int	flags;		/* tty driver flags */
 	struct proc_dir_entry *proc_entry; /* /proc fs entry */
 	struct tty_driver *other; /* only used for the PTY driver */

Re: [PATCH 3/6] drivers:misc: sources for ST core

[Greg KH]

On Mon, Mar 22, 2010 at 04:19:13PM -0500, pavan_savoy@ti.com wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
> 
> Texas Instruments BT, FM and GPS combo chips/drivers
> make use of a single TTY to communicate with the chip.
> This module constitutes the core logic, TTY ldisc driver
> and the exported symbols for registering/unregistering of
> the protocol drivers such as BT/FM/GPS.
> 
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
>  drivers/misc/ti-st/st_core.c | 1057 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/misc/ti-st/st_core.h |   92 ++++
>  2 files changed, 1149 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/misc/ti-st/st_core.c
>  create mode 100644 drivers/misc/ti-st/st_core.h
> 
> diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
> new file mode 100644
> index 0000000..1cb7c0a
> --- /dev/null
> +++ b/drivers/misc/ti-st/st_core.c
> @@ -0,0 +1,1057 @@
> +/*
> + *  Shared Transport Line discipline driver Core
> + *	This hooks up ST KIM driver and ST LL driver
> + *  Copyright (C) 2009 Texas Instruments
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/tty.h>
> +
> +/* understand BT, FM and GPS for now */
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci_core.h>
> +#include <net/bluetooth/hci.h>
> +#include "fm.h"
> +/*
> + * packet formats for fm and gps
> + * #include "gps.h"
> + */
> +#include "st_core.h"
> +#include "st_kim.h"
> +#include "st_ll.h"
> +#include "st.h"
> +
> +/* all debug macros go in here */
> +#define ST_DRV_ERR(fmt, arg...)  printk(KERN_ERR "(stc):"fmt"\n" , ## arg)
> +#if defined(DEBUG)		/* limited debug messages */
> +#define ST_DRV_DBG(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
> +#define ST_DRV_VER(fmt, arg...)
> +#elif defined(VERBOSE)		/* very verbose */
> +#define ST_DRV_DBG(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
> +#define ST_DRV_VER(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
> +#else /* error msgs only */
> +#define ST_DRV_DBG(fmt, arg...)
> +#define ST_DRV_VER(fmt, arg...)
> +#endif

NO!

Please use the existing debug macros (dev_printk and friends) and do not
roll your own.

thanks,

greg k-h

Re: [PATCH 3/6] drivers:misc: sources for ST core

[Alan Cox]

> +/* all debug macros go in here */
> +#define ST_DRV_ERR(fmt, arg...)  printk(KERN_ERR "(stc):"fmt"\n" , ## arg)
> +#if defined(DEBUG)		/* limited debug messages */
> +#define ST_DRV_DBG(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
> +#define ST_DRV_VER(fmt, arg...)
> +#elif defined(VERBOSE)		/* very verbose */
> +#define ST_DRV_DBG(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
> +#define ST_DRV_VER(fmt, arg...)  printk(KERN_INFO "(stc):"fmt"\n" , ## arg)
> +#else /* error msgs only */
> +#define ST_DRV_DBG(fmt, arg...)
> +#define ST_DRV_VER(fmt, arg...)
> +#endif

Use the existing debug macros


> +/* function pointer pointing to either,
> + * st_kim_recv during registration to receive fw download responses
> + * st_int_recv after registration to receive proto stack responses
> + */
> +void (*st_recv) (const unsigned char *data, long count);

What if you have multiple devices at once one in each state ?
Why is this global ?

> +	if (unlikely(st_gdata == NULL || st_gdata->tty == NULL)) {

Again shouldn't be using globals and needs to support multiple devices.
See the tty_struct - there is a field for an ldisc pointer, stuff
st_gdata in there at open time and pass tty around ?


> +		ST_DRV_ERR("tty unavailable to perform write");
> +		return ST_ERR_FAILURE;
> +	}
> +	tty = st_gdata->tty;

Explain the locking on this NULL test - what stops it becoming NULL
between the if and the assignment ?


I think this code needs a fair bit of work at this point - locking,
supporting multiple devices at once etc.

Staging perhaps ?

Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[Greg KH]

On Mon, Mar 22, 2010 at 04:19:12PM -0500, pavan_savoy@ti.com wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
> 
> This change adds the Kconfig and Make file for TI's
> ST line discipline driver and the BlueZ driver for BT
> core of the TI BT/FM/GPS combo chip.

This patch breaks the build if you were to apply them in order, or hit
is in a 'git bisect' session.  Please always make it so that no
individual patch would ever break anything.

thanks,

greg k-h

Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[Greg KH]

On Mon, Mar 22, 2010 at 04:19:12PM -0500, pavan_savoy@ti.com wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
> 
> This change adds the Kconfig and Make file for TI's
> ST line discipline driver and the BlueZ driver for BT
> core of the TI BT/FM/GPS combo chip.
> 
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
>  drivers/misc/Kconfig        |    1 +

Why 'misc'?  Why not 'char' like all the other ldiscs?

Or 'drivers/ldisc' to be more specific?

thanks,

greg k-h

Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

Am 22.03.2010 22:35 schrieb Greg KH:
> On Mon, Mar 22, 2010 at 04:19:12PM -0500, pavan_savoy@ti.com wrote:
>> From: Pavan Savoy <pavan_savoy@ti.com>
>>
>> This change adds the Kconfig and Make file for TI's
>> ST line discipline driver and the BlueZ driver for BT
>> core of the TI BT/FM/GPS combo chip.
>>
>> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
>> ---
>>  drivers/misc/Kconfig        |    1 +
> 
> Why 'misc'?  Why not 'char' like all the other ldiscs?

Not wanting to nitpick, but the majority of ldiscs do not live
in drivers/char. There is a whole lot of them in drivers/net, a
handful scattered over various other drivers/ places like
drivers/bluetooth, drivers/input, drivers/isdn, drivers/pps,
and even one outside the drivers/ tree, in sound/.
(Leaving aside the one in staging.)

HTH,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[Alan Cox]

On Mon, 22 Mar 2010 14:35:30 -0700
Greg KH <gregkh@suse.de> wrote:

> On Mon, Mar 22, 2010 at 04:19:12PM -0500, pavan_savoy@ti.com wrote:
> > From: Pavan Savoy <pavan_savoy@ti.com>
> > 
> > This change adds the Kconfig and Make file for TI's
> > ST line discipline driver and the BlueZ driver for BT
> > core of the TI BT/FM/GPS combo chip.
> > 
> > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > ---
> >  drivers/misc/Kconfig        |    1 +
> 
> Why 'misc'?  Why not 'char' like all the other ldiscs?
> 
> Or 'drivers/ldisc' to be more specific?

We've discussed having /tty or drivers/tty for a while. The ldiscs are
currently everywhere - drivers/net, isdn, char ....

I am not sure an ldisc directory helps though - slip and ppp are in
drivers/net for example and clearly belong there.

Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[Greg KH]

On Tue, Mar 23, 2010 at 03:18:52PM +0000, Alan Cox wrote:
> On Mon, 22 Mar 2010 14:35:30 -0700
> Greg KH <gregkh@suse.de> wrote:
> 
> > On Mon, Mar 22, 2010 at 04:19:12PM -0500, pavan_savoy@ti.com wrote:
> > > From: Pavan Savoy <pavan_savoy@ti.com>
> > > 
> > > This change adds the Kconfig and Make file for TI's
> > > ST line discipline driver and the BlueZ driver for BT
> > > core of the TI BT/FM/GPS combo chip.
> > > 
> > > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > > ---
> > >  drivers/misc/Kconfig        |    1 +
> > 
> > Why 'misc'?  Why not 'char' like all the other ldiscs?
> > 
> > Or 'drivers/ldisc' to be more specific?
> 
> We've discussed having /tty or drivers/tty for a while. The ldiscs are
> currently everywhere - drivers/net, isdn, char ....
> 
> I am not sure an ldisc directory helps though - slip and ppp are in
> drivers/net for example and clearly belong there.

Yeah, good point.  I like the idea of a tty/ directory for the tty core
in the future if it's really needed.

thanks,

greg k-h

Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[Randy Dunlap]

On 03/22/10 14:19, pavan_savoy@ti.com wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
> 
> This change adds the Kconfig and Make file for TI's
> ST line discipline driver and the BlueZ driver for BT
> core of the TI BT/FM/GPS combo chip.
> 
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
>  drivers/misc/Kconfig        |    1 +
>  drivers/misc/Makefile       |    1 +
>  drivers/misc/ti-st/Kconfig  |   24 ++++++++++++++++++++++++
>  drivers/misc/ti-st/Makefile |    7 +++++++
>  4 files changed, 33 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/misc/ti-st/Kconfig
>  create mode 100644 drivers/misc/ti-st/Makefile
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 625e3a6..c059bca 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -344,5 +344,6 @@ source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"
>  source "drivers/misc/iwmc3200top/Kconfig"
> +source "drivers/misc/ti-st/Kconfig"
>  
>  endif # MISC_DEVICES
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index c221917..021f282 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)      += iwmc3200top/
>  obj-$(CONFIG_HWLAT_DETECTOR)	+= hwlat_detector.o
>  obj-y				+= eeprom/
>  obj-y				+= cb710/
> +obj-y				+= ti-st/
> diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig
> new file mode 100644
> index 0000000..18eea1c
> --- /dev/null
> +++ b/drivers/misc/ti-st/Kconfig
> @@ -0,0 +1,24 @@
> +#
> +# TI's shared transport line discipline and the protocol
> +# drivers (BT, FM and GPS)
> +#
> +menu "Texas Instruments shared transport line discipline"
> +    config TI_ST
> +    tristate "shared transport core driver"
> +    select FW_LOADER
> +    help
> +        This enables the shared transport core driver for TI
> +	    BT / FM and GPS combo chips.This enables protocol drivers
> +	    to register themselves with core and send data, the responses
> +	    are returned to relevant protocol drivers based on their
> +	    packet types.

Please indent kconfig help text with one tab + 2 spaces.

> +
> +    config ST_BT
> +    tristate "BlueZ bluetooth driver for ST"

I'd be careful.  There are some places in the kernel tree where ST
means STMicroelectronics.

> +    select BT

That select looks unsafe.  You don't know that CONFIG_NET  is even enabled here,
do you?  Most drivers use "depends on BT" instead of "select BT" from my grepping.



> +    select TI_ST
> +    help
> +       This enables the Bluetooth driver for TI BT/FM/GPS combo devices

End sentence with period.

> +       This makes use of shared transport line discipline core driver to
> +       communicate with the BT core of the combo chip.
> +endmenu
> diff --git a/drivers/misc/ti-st/Makefile b/drivers/misc/ti-st/Makefile
> new file mode 100644
> index 0000000..cff3770
> --- /dev/null
> +++ b/drivers/misc/ti-st/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for TI's shared transport line discipline
> +# and it's protocol drivers (BT, FM, GPS)

         its

> +#
> +obj-$(CONFIG_TI_ST) += st_drv.o
> +st_drv-objs			:= st_core.o st_kim.o st_ll.o
> +obj-$(CONFIG_ST_BT) += bt_drv.o


-- 
~Randy

RE: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[Savoy, Pavan]

patch below....
_______________________________________
From: Randy Dunlap [randy.dunlap@oracle.com]
Sent: Tuesday, March 23, 2010 3:15 AM
To: Savoy, Pavan
Cc: gregkh@suse.de; alan@lxorguk.ukuu.org.uk; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

On 03/22/10 14:19, pavan_savoy@ti.com wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
>
> This change adds the Kconfig and Make file for TI's
> ST line discipline driver and the BlueZ driver for BT
> core of the TI BT/FM/GPS combo chip.
>
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
>  drivers/misc/Kconfig        |    1 +
>  drivers/misc/Makefile       |    1 +
>  drivers/misc/ti-st/Kconfig  |   24 ++++++++++++++++++++++++
>  drivers/misc/ti-st/Makefile |    7 +++++++
>  4 files changed, 33 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/misc/ti-st/Kconfig
>  create mode 100644 drivers/misc/ti-st/Makefile
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 625e3a6..c059bca 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -344,5 +344,6 @@ source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"
>  source "drivers/misc/iwmc3200top/Kconfig"
> +source "drivers/misc/ti-st/Kconfig"
>
>  endif # MISC_DEVICES
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index c221917..021f282 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)      += iwmc3200top/
>  obj-$(CONFIG_HWLAT_DETECTOR) += hwlat_detector.o
>  obj-y                                += eeprom/
>  obj-y                                += cb710/
> +obj-y                                += ti-st/
> diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig
> new file mode 100644
> index 0000000..18eea1c
> --- /dev/null
> +++ b/drivers/misc/ti-st/Kconfig
> @@ -0,0 +1,24 @@
> +#
> +# TI's shared transport line discipline and the protocol
> +# drivers (BT, FM and GPS)
> +#
> +menu "Texas Instruments shared transport line discipline"
> +    config TI_ST
> +    tristate "shared transport core driver"
> +    select FW_LOADER
> +    help
> +        This enables the shared transport core driver for TI
> +         BT / FM and GPS combo chips.This enables protocol drivers
> +         to register themselves with core and send data, the responses
> +         are returned to relevant protocol drivers based on their
> +         packet types.

Please indent kconfig help text with one tab + 2 spaces.

> +
> +    config ST_BT
> +    tristate "BlueZ bluetooth driver for ST"

I'd be careful.  There are some places in the kernel tree where ST
means STMicroelectronics.

> +    select BT

That select looks unsafe.  You don't know that CONFIG_NET  is even enabled here,
do you?  Most drivers use "depends on BT" instead of "select BT" from my grepping.



> +    select TI_ST
> +    help
> +       This enables the Bluetooth driver for TI BT/FM/GPS combo devices

End sentence with period.

> +       This makes use of shared transport line discipline core driver to
> +       communicate with the BT core of the combo chip.
> +endmenu
> diff --git a/drivers/misc/ti-st/Makefile b/drivers/misc/ti-st/Makefile
> new file mode 100644
> index 0000000..cff3770
> --- /dev/null
> +++ b/drivers/misc/ti-st/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for TI's shared transport line discipline
> +# and it's protocol drivers (BT, FM, GPS)

         its

> +#
> +obj-$(CONFIG_TI_ST) += st_drv.o
> +st_drv-objs                  := st_core.o st_kim.o st_ll.o
> +obj-$(CONFIG_ST_BT) += bt_drv.o


--
~Randy



>From 91b326a876066f0724f08957ee446f6b6bbed40e Mon Sep 17 00:00:00 2001
From: Pavan Savoy <pavan_savoy@ti.com>
Date: Mon, 22 Mar 2010 16:40:19 -0400
Subject: [PATCH 2/7] drivers:misc: Kconfig, Makefile for TI's ST ldisc
This change adds the Kconfig and Make file for TI's
ST line discipline driver and the BlueZ driver for BT
core of the TI BT/FM/GPS combo chip.
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 drivers/misc/Kconfig        |    1 +
 drivers/misc/Makefile       |    1 +
 drivers/misc/ti-st/Kconfig  |   24 ++++++++++++++++++++++++
 drivers/misc/ti-st/Makefile |    7 +++++++
 4 files changed, 33 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/ti-st/Kconfig
 create mode 100644 drivers/misc/ti-st/Makefile
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 625e3a6..c059bca 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -344,5 +344,6 @@ source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
 source "drivers/misc/iwmc3200top/Kconfig"
+source "drivers/misc/ti-st/Kconfig"
 
 endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c221917..021f282 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)      += iwmc3200top/
 obj-$(CONFIG_HWLAT_DETECTOR) += hwlat_detector.o
 obj-y    += eeprom/
 obj-y    += cb710/
+obj-y    += ti-st/
diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig
new file mode 100644
index 0000000..fe5b0e8
--- /dev/null
+++ b/drivers/misc/ti-st/Kconfig
@@ -0,0 +1,24 @@
+#
+# TI's shared transport line discipline and the protocol
+# drivers (BT, FM and GPS)
+#
+menu "Texas Instruments shared transport line discipline"
+    config TI_ST
+    tristate "shared transport core driver"
+    select FW_LOADER
+    help
+   This enables the shared transport core driver for TI
+   BT / FM and GPS combo chips.This enables protocol drivers
+   to register themselves with core and send data, the responses
+   are returned to relevant protocol drivers based on their
+   packet types.
+
+    config ST_BT
+    tristate "BlueZ bluetooth driver for ST"
+    depends on BT
+    select TI_ST
+    help
+   This enables the Bluetooth driver for TI BT/FM/GPS combo devices
+   This makes use of shared transport line discipline core driver to
+   communicate with the BT core of the combo chip.
+endmenu
diff --git a/drivers/misc/ti-st/Makefile b/drivers/misc/ti-st/Makefile
new file mode 100644
index 0000000..cff3770
--- /dev/null
+++ b/drivers/misc/ti-st/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for TI's shared transport line discipline
+# and it's protocol drivers (BT, FM, GPS)
+#
+obj-$(CONFIG_TI_ST) += st_drv.o
+st_drv-objs   := st_core.o st_kim.o st_ll.o
+obj-$(CONFIG_ST_BT) += bt_drv.o
-- 
1.5.4.3


Would this do ? I've modified the Kconfig to have depends on BT.
I chose "drivers/misc" because there is no other place to put in Line discipline drivers - plan for drivers/ldisc ?
Also, Having TI_ST should I suppose suggest it has something to do with Texas Instruments.

PS:
If you still see problems with identation - blame my email editor (outlook express)

Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc

[Randy Dunlap]

On 03/22/10 15:37, Savoy, Pavan wrote:
> patch below....
> _______________________________________
> From: Randy Dunlap [randy.dunlap@oracle.com]
> Sent: Tuesday, March 23, 2010 3:15 AM
> To: Savoy, Pavan
> Cc: gregkh@suse.de; alan@lxorguk.ukuu.org.uk; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/6] drivers:misc: Kconfig, Makefile for TI's ST ldisc
> 
> On 03/22/10 14:19, pavan_savoy@ti.com wrote:
>> From: Pavan Savoy <pavan_savoy@ti.com>
>>
>> This change adds the Kconfig and Make file for TI's
>> ST line discipline driver and the BlueZ driver for BT
>> core of the TI BT/FM/GPS combo chip.
>>
>> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
>> ---
>>  drivers/misc/Kconfig        |    1 +
>>  drivers/misc/Makefile       |    1 +
>>  drivers/misc/ti-st/Kconfig  |   24 ++++++++++++++++++++++++
>>  drivers/misc/ti-st/Makefile |    7 +++++++
>>  4 files changed, 33 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/misc/ti-st/Kconfig
>>  create mode 100644 drivers/misc/ti-st/Makefile
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 625e3a6..c059bca 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -344,5 +344,6 @@ source "drivers/misc/c2port/Kconfig"
>>  source "drivers/misc/eeprom/Kconfig"
>>  source "drivers/misc/cb710/Kconfig"
>>  source "drivers/misc/iwmc3200top/Kconfig"
>> +source "drivers/misc/ti-st/Kconfig"
>>
>>  endif # MISC_DEVICES
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index c221917..021f282 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)      += iwmc3200top/
>>  obj-$(CONFIG_HWLAT_DETECTOR) += hwlat_detector.o
>>  obj-y                                += eeprom/
>>  obj-y                                += cb710/
>> +obj-y                                += ti-st/
>> diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig
>> new file mode 100644
>> index 0000000..18eea1c
>> --- /dev/null
>> +++ b/drivers/misc/ti-st/Kconfig
>> @@ -0,0 +1,24 @@
>> +#
>> +# TI's shared transport line discipline and the protocol
>> +# drivers (BT, FM and GPS)
>> +#
>> +menu "Texas Instruments shared transport line discipline"
>> +    config TI_ST
>> +    tristate "shared transport core driver"
>> +    select FW_LOADER
>> +    help
>> +        This enables the shared transport core driver for TI
>> +         BT / FM and GPS combo chips.This enables protocol drivers
>> +         to register themselves with core and send data, the responses
>> +         are returned to relevant protocol drivers based on their
>> +         packet types.
> 
> Please indent kconfig help text with one tab + 2 spaces.
> 
>> +
>> +    config ST_BT
>> +    tristate "BlueZ bluetooth driver for ST"
> 
> I'd be careful.  There are some places in the kernel tree where ST
> means STMicroelectronics.
> 
>> +    select BT
> 
> That select looks unsafe.  You don't know that CONFIG_NET  is even enabled here,
> do you?  Most drivers use "depends on BT" instead of "select BT" from my grepping.
> 
> 
> 
>> +    select TI_ST
>> +    help
>> +       This enables the Bluetooth driver for TI BT/FM/GPS combo devices
> 
> End sentence with period.
> 
>> +       This makes use of shared transport line discipline core driver to
>> +       communicate with the BT core of the combo chip.
>> +endmenu
>> diff --git a/drivers/misc/ti-st/Makefile b/drivers/misc/ti-st/Makefile
>> new file mode 100644
>> index 0000000..cff3770
>> --- /dev/null
>> +++ b/drivers/misc/ti-st/Makefile
>> @@ -0,0 +1,7 @@
>> +#
>> +# Makefile for TI's shared transport line discipline
>> +# and it's protocol drivers (BT, FM, GPS)
> 
>          its
> 
>> +#
>> +obj-$(CONFIG_TI_ST) += st_drv.o
>> +st_drv-objs                  := st_core.o st_kim.o st_ll.o
>> +obj-$(CONFIG_ST_BT) += bt_drv.o
> 
> 
> --
> ~Randy
> 
> 
> 
> From 91b326a876066f0724f08957ee446f6b6bbed40e Mon Sep 17 00:00:00 2001
> From: Pavan Savoy <pavan_savoy@ti.com>
> Date: Mon, 22 Mar 2010 16:40:19 -0400
> Subject: [PATCH 2/7] drivers:misc: Kconfig, Makefile for TI's ST ldisc
> This change adds the Kconfig and Make file for TI's
> ST line discipline driver and the BlueZ driver for BT
> core of the TI BT/FM/GPS combo chip.
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
>  drivers/misc/Kconfig        |    1 +
>  drivers/misc/Makefile       |    1 +
>  drivers/misc/ti-st/Kconfig  |   24 ++++++++++++++++++++++++
>  drivers/misc/ti-st/Makefile |    7 +++++++
>  4 files changed, 33 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/misc/ti-st/Kconfig
>  create mode 100644 drivers/misc/ti-st/Makefile
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 625e3a6..c059bca 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -344,5 +344,6 @@ source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"
>  source "drivers/misc/iwmc3200top/Kconfig"
> +source "drivers/misc/ti-st/Kconfig"
>  
>  endif # MISC_DEVICES
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index c221917..021f282 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_IWMC3200TOP)      += iwmc3200top/
>  obj-$(CONFIG_HWLAT_DETECTOR) += hwlat_detector.o
>  obj-y    += eeprom/
>  obj-y    += cb710/
> +obj-y    += ti-st/
> diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig
> new file mode 100644
> index 0000000..fe5b0e8
> --- /dev/null
> +++ b/drivers/misc/ti-st/Kconfig
> @@ -0,0 +1,24 @@
> +#
> +# TI's shared transport line discipline and the protocol
> +# drivers (BT, FM and GPS)
> +#
> +menu "Texas Instruments shared transport line discipline"
> +    config TI_ST
> +    tristate "shared transport core driver"
> +    select FW_LOADER
> +    help
> +   This enables the shared transport core driver for TI
> +   BT / FM and GPS combo chips.This enables protocol drivers
> +   to register themselves with core and send data, the responses
> +   are returned to relevant protocol drivers based on their
> +   packet types.
> +
> +    config ST_BT
> +    tristate "BlueZ bluetooth driver for ST"
> +    depends on BT

OK.

> +    select TI_ST
> +    help
> +   This enables the Bluetooth driver for TI BT/FM/GPS combo devices
> +   This makes use of shared transport line discipline core driver to
> +   communicate with the BT core of the combo chip.

There are no tabs above.  They appear to have been eaten (assuming that
they were there at some point).


> +endmenu
> diff --git a/drivers/misc/ti-st/Makefile b/drivers/misc/ti-st/Makefile
> new file mode 100644
> index 0000000..cff3770
> --- /dev/null
> +++ b/drivers/misc/ti-st/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for TI's shared transport line discipline
> +# and it's protocol drivers (BT, FM, GPS)

         ^^^^
should be "its"

> +#
> +obj-$(CONFIG_TI_ST) += st_drv.o
> +st_drv-objs   := st_core.o st_kim.o st_ll.o
> +obj-$(CONFIG_ST_BT) += bt_drv.o


> PS:
> If you still see problems with identation - blame my email editor (outlook express)

I guess that you'll need to do something about that.


-- 
~Randy

Re: [PATCH 1/6] serial: TTY: new ldisc for TI BT/FM/GPS chips

[Alan Cox]

>  #define N_V253		19	/* Codec control over voice modem */
> +#define N_TI_SHARED	20	/* for TI's WL7 connectivity chips */

Be more specific or some future TI shared bus protocol might cause
confusion N_TI_WL7 sounds fine.

Alan

RE: [PATCH 4/6] drivers:misc: sources for Init manager module

[Pavan Savoy]

--- On Thu, 25/3/10, Marcel Holtmann <marcel@holtmann.org> wrote:

> From: Marcel Holtmann <marcel@holtmann.org>
> Subject: RE: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Savoy, Pavan" <pavan_savoy@ti.com>
> Cc: "Pavan Savoy" <pavan_savoy@yahoo.co.in>, "Greg KH" <gregkh@suse.de>, "alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>, "Deosthali, Amey" <adeosthali@ti.com>, "Alathur, Pramodh" <pramodh_ag@ti.com>
> Date: Thursday, 25 March, 2010, 3:05 AM
> Hi Pavan,
> 
> > Find enclosed the design document, where in figure-1
> pretty much explains the different protocols for FM, GPS, BT
> and HCI-LL.
> 
> just after quickly going through that document, I think you
> should
> create an actual ST bus. The ST line discipline should be
> just one
> transport driver for that bus. Since you clearly looking
> into SPI and
> other transports as well.

Had planned a range of TTY drivers for SPI/SlimBus 'ala usb-serial device driver for that.
And hence somehow assumed TTY line discipline should be enough.

SPI/SlimBus I tend to agree, their device nodes in user space is not used, and settings like bus freq, CPOL/CPHA are all set via drivers (for spi atleast).

Even after doing that, what about the requirement of opening an tty device upon request from BT or FM when chip is on UART ?

> 
> And then the bus can export Bluetooth, FM and GPS devices.
> And we can
> have separate drivers for these devices.

Hnm, Any such example drivers to look around ?

> You might wanna pick a different name than ST to not make
> ST
> Microelectronics unhappy and next time they call their next
> thing TI ;)

I had called it SHUART for some reason earlier, Yep point to be considered.
Thanks,

> Regards
> 
> Marcel
> 
> 
> 


      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/