Message-ID: <20130730224809.GN17130@pogo>
Date:	Tue, 30 Jul 2013 15:48:09 -0700
From:	"Luis R. Rodriguez" <rodrigue@....qualcomm.com>
To:	Marcel Holtmann <marcel@...tmann.org>
CC:	Hector Palacios <hector.palacios@...i.com>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
	"gustavo@...ovan.org" <gustavo@...ovan.org>,
	"johan.hedberg@...il.com" <johan.hedberg@...il.com>,
	<mcgrof@...not-panic.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"surajs@....qualcomm.com" <surajs@....qualcomm.com>,
	<jjohnson@....qualcomm.com>, Adrian Chadd <adrian@...ebsd.org>,
	<ddahlby@....qualcomm.com>, Ben Hutchings <ben@...adent.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency
 for BT_ATH3K)

CC'ing linux-wireless as ROM patching is mentioned and in so far as
802.11 mobile is concerned this is a pretty frequent practice there
as well so figured we'd tie in the conversations.

On Tue, Jul 30, 2013 at 03:05:18PM -0700, Marcel Holtmann wrote:
> Hi Luis,
> 
> >> This brings an interesting question: shouldn't the firmware download
> >> part be isolated from the USB driver? After all, I want to
> >> communicate with a UART bluetooth chip.
> > 
> > There are a few BT firmware upload modules (last I checked at least 2),
> > I believe it should be possible to stuff all that code a shared
> > module or even as FreeBSD does it -- treat fw uploading in userspace,
> > however just keep in mind for quirks [0]. So patches welcomed.
> 
> it really depends on what kind of patching or firmware download has to be done.
> 
> For all the ROM patching via HCI commands, we explicitly added support
> for setup stage

This stage is what is I was referring to.

> and exposed a standard way of getting in front of
> Bluetooth core init sequence.

Nice.

> An example here would be the Intel
> Bluetooth devices that require ROM patching. This can be useful for
> many Bluetooth devices that are generally USB transport standard
> compliant, but need a few extra commands of vendor setup.

Interesting. I believe for 802.11 we just throw in a bunch of ROM
patching onto the 802.11 driver_firwmare.fw file and then assume
the driver can do the right thing. I however haven't worked on that so I
am curious if someone more familiar with this can provide details of
how that happens. I do know that the 802.11 mobile drivers get tons of
firmware updates because of this exact architectural choice and do
wonder how we can easily keep up with the firmware updates in meaninful
way to linux-firwmare.

How often do the ROM patches get updated? And do the HCI commands
trigger a userspace event?

> We are planning to take one extra step and split this into a
> mini-driver approach similar to what has been done for usbnet, but we
> are not there yet.

Neat. Perhaps we need something that we can share with 802.11 or other
hardare I highly doubt we're the only ones patching ROM. Don't we even
patch up core CPUs? I'm wondering if firmware_class could be expanded to
support serialized ROM patching. The biggest hurdle I see with splititng
ROM patching from a single firmware is serializing that, addressing
revision dependencies and of course kernel dependencies.

I've thrown this on the list of topics for the next wireless summit
at New Orleans.

> However the ROM patching drivers need to be in the kernel since
> otherwise they will race with the core init sequence.

Sure and depending on the architecture -- if this is kicked off to
userspace helpers or not then we may need to consider dbus in
kernel thing to help with speed / races, dependenecies / async
loading, -EPROBE_DEFER, etc.

> There are also just firmware download drivers that do nothing else
> than just loading the firmware. And here it can be done via userspace
> or kernel space. In the Bluetooth world we have seen both, but
> generally the kernel ones stayed around while the userspace ones had a
> hard time to work with udev, libusb, libusb1 etc.

Ah I see. Perhaps we can address this once we get some form of dbus in
kernel.

> For UART based drivers it is a little bit different since we had to
> bring up the line discipline from userspace anyway and configure all
> the UART parameters. For these drivers the firmware download or ROM
> patching has been done normally via userspace since there is full
> exclusive access before the Bluetooth subsystem knows about the
> device.

Is this something that dbus in kernel can help clean up a bit?

> With the newly introduced setup stage, the drivers could actually
> share the setup handling for UART and USB based devices. Not sure if
> any vendor is going for this approach.

Interesting... Is the architecture documented somewhere? Is this
upstream already?

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

Powered by blists - more mailing lists