linux-kernel - Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTimyR7f=PdQbxxBLCnznTA4PT1TWEFiNX3C_qaZo@mail.gmail.com>
Date:	Fri, 29 Oct 2010 14:08:11 +0200
From:	Par-Gunnar Hjalmdahl <pghatwork@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linus.walleij@...ricsson.com,
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
	Lukasz.Rymanowski@...to.com
Subject: Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.

2010/10/29 Par-Gunnar Hjalmdahl <pghatwork@...il.com>:
> 2010/10/28 Arnd Bergmann <arnd@...db.de>:
>> On Friday 22 October 2010, Par-Gunnar Hjalmdahl wrote:
>>
>>> >
>>> > So - NAK this for the moment, it needs to be split cleanly into ldisc
>>> > (thing which speaks the protocol and eg sees "speed change required" and
>>> > acts on it) and device (thing which knows about the hardware).
>>>
>>> OK. We will try to figure out a new design.
>>> I'm not too happy about putting the ldisc part in Bluetooth though
>>> since it is only partly Bluetooth, it is also GPS and FM. Better could
>>> maybe be under char/?
>>
>> After getting a better idea of what the base mfd driver does, my impression
>> is now that you should not register a second N_HCI line discipline at all,
>> but instead extend the existing line discipline with this number.
>>
>> I'm not sure what happens if you need two modules that try to register
>> the same ldisc number, but I imagine it is not good.
>>
>> Shouldn't you instead be using the drivers/bluetooth/hci_{ldisc,h4} code?
>>
>>        Arnd
>>
>
> We also need the ldisc code to handle events from FM and GPS and since
> that is chip specific we cannot add that to the generic hci_ldisc
> code.
> I agree that we might run into problems if two drivers try to register
> the same line discipline. It might then be better to introduce a new
> line discipline then even though that could cause other problems. I do
> not know if it is possible to add a condition in Kconfig otherwise so
> the CG2900 ldisc cannot be active while the "normal" ldisc driver is
> selected.
>
> /P-G
>

Hi again,

I might have been a bit too quick there.
The actual channel matching and packet creation is done in hci_h4.c
while ldisc registration is done in hci_ldisc.c.
So it might to be enough to create a new hci_h4-cg2900.c (or similar
name) that can separate the right channels. We must however do changes
to hci_ldisc as well since it seems to always register to the
Bluetooth stack here, which we definitely don't want since that is
handled by btcg2900.c.
Also note that this ldisc issue is only valid when using UART as
transport. We will also support SPI and then we will probably run into
completely new, interesting problems. :-)

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