linux-kernel - Re: Request for input regarding new driver in MFD for GPS_Bluetooth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Sep 2010 12:14:17 +0200
From:	Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@...ricsson.com>
To:	Pavan Savoy <pavan_savoy@...y.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linus.walleij@...ricsson.com,
	linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org
Subject: Re: Request for input regarding new driver in MFD for
 GPS_Bluetooth_FM controller CG2900

Hi Pavan,

Thanks for your comments and sorry for me taking time to answer your mail.
See below for answers.

>
> ok bit more of information ....
> We don;t use the hciattach, instead we have our own daemon which opens
> up the UART and installs the line discipline (not N_HCI, but similar
> one called N_SHARED) when the hciconfig hci0 up happens or even when
> /dev/radio0 (FM V4L2 device) happens or when generic GPS character
> device (/dev/tigps) happens...

:-) We also have our own user space application for opening the UART
and setting the line disc since we don't  want to depend completely on
hciattach, which contains more than we need, and also misses stuff
that we want to do towards our specific controller. I just used it as
an example since that is the common BlueZ way to open the Bluetooth
transport.

>
> There is non-mailine driver which gets modified to get into mainline @
> http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-
> st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-
> omap-2.6.32
>
> feel free to have a look at it...
> Yes our solution too works with BlueZ and non-exactly a MFD driver but
> it is a simple platform device driver .. by looks of things the driver
> can run as is for your chip too .. (except for the firmware search and
> download part .. may be...).

Your code is in a lot of ways similar to ours (which is not so strange
since you address the same market with your chip as we do with ours),
but there are several differences that would at least for now make it
impossible for us to use your driver. When we post our first patches
(which will hopefully be in a few days) you can see for yourself. But
I don't think there is a simple way for us to re-use your driver.

>
> and note when we would want to support SPI transport for the same, we
> plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
> N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
> related stuff to be handled by the spi-tty.c which registers itself as
> a tty_device and a tty_driver ....

Our SPI usage will be a bit different, where we don't use TTY for our
driver. We will use the SPI directly instead.

>
> regards,
> Pavan
>
> On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <pavan_savoy@...y.com>
> wrote:
> > Can you directly make use of the ti-st driver which is currently
> staged?
> > It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising
> !!!

:-) As I said earlier this is quite natural since both TI and
ST-Ericsson address the same market segments.

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