linux-kernel - Re: __hci_cmd_sync() not suitable for nokia h4p

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]

Message-Id: <CAA1630D-1A2E-4D3D-9BBC-2EE86256D58B@holtmann.org>
Date:	Thu, 11 Dec 2014 23:25:13 +0100
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Pavel Machek <pavel@....cz>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Sebastian Reichel <sre@...ian.org>,
	Sebastian Reichel <sre@...g0.de>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>, khilman@...nel.org,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Ивайло Димитров 
	<ivo.g.dimitrov.75@...il.com>,
	"Gustavo F. Padovan" <gustavo@...ovan.org>,
	Johan Hedberg <johan.hedberg@...il.com>,
	linux-bluetooth@...r.kernel.org
Subject: Re: __hci_cmd_sync() not suitable for nokia h4p

Hi Pavel,

>>> h4p changes uart speed again after load of the firmware, but I guess
>>> that's ok.
> 
>> if you can do it the other way around it would result in a faster
>> init. Depending on how many patches are actually required to be
>> loaded.
> 
> IIRC driver does two speed changes, so it looks to me like someone
> already tried that (and it did not work).

normally it does not matter which way around. I think some people changed it in hciattach for Broadcom devices actually.

>>>> What needs to be done is the bring up of the device including the proper UART settings and speed and then just run the firmware downloads. All firmware files on the Nokia devices where just HCI commands with vendor specific details. Some from CSR, some from Broadcom and some from TI. You can actually decode them if you really want to. Shouldn't be that hard.
>>>> 
>>> 
>>> Speed changes at the end of firmware load, but I guess that's detail?
>>> Anyway, patch would look like this.
>> 
>> You should really look into providing hdev->setup() callback. That is normally the callback where you want to load the firmware.
>> 
> 
> I can provide setup() callback and load firmware from there.
> 
> I have created provisional device tree binding, and the driver still
> works.
> 
> Some time ago you mentioned that with the "big" issues fixed, you'd be
> willing to take it into the tree. What way forward do you see? Would
> it make sense to re-enable the driver in staging, so that "big"
> changes could be applied, followed by renames?

If the driver is clean, there is no point in taking it through staging. It can be cleaned up and then merged all together.

I think the important part is to focus on the N900 derivative with the Broadcom chip inside. And just ignore all the rest. So start small and do not try to carry the N770, N800, N810 hacks over.

However you might want to check Neil Brown's patches for TTY-slave devices he just posted. Maybe the N900 devices should be exposed as TTY and we just attach N_HCI line discipline to it. If all the GPIO wiggling can be done automatically at TTY open, then that should be the way to go. I also send an email about using the new unconfigured stage to get this done cleanly.

http://permalink.gmane.org/gmane.linux.bluez.kernel/50483

Regards

Marcel

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