drivers:misc: sources for Init manager module
in [Kernel]
|
From: Pavan Savoy on 24 Mar 2010 13:10 --- On Wed, 24/3/10, Greg KH <gregkh(a)suse.de> wrote: > From: Greg KH <gregkh(a)suse.de> > Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module > To: "Pavan Savoy" <pavan_savoy(a)yahoo.co.in> > Cc: "Marcel Holtmann" <marcel(a)holtmann.org>, "PavanSavoy" <pavan_savoy(a)ti.com>, "alan(a)lxorguk.ukuu.org.uk" <alan(a)lxorguk.ukuu.org.uk>, "linux-kernel(a)vger.kernel.org" <linux-kernel(a)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(a)suse.de> > wrote: > > > > > From: Greg KH <gregkh(a)suse.de> > > > Subject: Re: [PATCH 4/6] drivers:misc: sources > for Init manager module > > > To: "Marcel Holtmann" <marcel(a)holtmann.org> > > > Cc: "Pavan Savoy" <pavan_savoy(a)yahoo.co.in>, > "PavanSavoy" <pavan_savoy(a)ti.com>, > "alan(a)lxorguk.ukuu.org.uk" > <alan(a)lxorguk.ukuu.org.uk>, > "linux-kernel(a)vger.kernel.org" > <linux-kernel(a)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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 24 Mar 2010 13:10 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marcel Holtmann on 24 Mar 2010 13:20 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 24 Mar 2010 13:20 > 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(a)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(a)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 */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavan Savoy on 24 Mar 2010 13:20
--- On Wed, 24/3/10, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: > From: Alan Cox <alan(a)lxorguk.ukuu.org.uk> > Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module > To: "Pavan Savoy" <pavan_savoy(a)yahoo.co.in> > Cc: "Marcel Holtmann" <marcel(a)holtmann.org>, "Greg KH" <gregkh(a)suse.de>, "PavanSavoy" <pavan_savoy(a)ti.com>, "linux-kernel(a)vger.kernel.org" <linux-kernel(a)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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |