From: Randy Dunlap on
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
--
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
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


--
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
> 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
--
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
--- On Wed, 24/3/10, Marcel Holtmann <marcel(a)holtmann.org> wrote:

> From: Marcel Holtmann <marcel(a)holtmann.org>
> Subject: Re: [PATCH 4/6] drivers:misc: sources for Init manager module
> To: "Pavan Savoy" <pavan_savoy(a)yahoo.co.in>
> Cc: "Greg KH" <gregkh(a)suse.de>, "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: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/
--
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: Greg KH on
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?

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