Message-ID: <20130730235508.GA25319@kroah.com>
Date:	Tue, 30 Jul 2013 16:55:08 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"Luis R. Rodriguez" <rodrigue@....qualcomm.com>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	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>
Subject: Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency
 for BT_ATH3K)

On Tue, Jul 30, 2013 at 03:48:09PM -0700, Luis R. Rodriguez wrote:
> > 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.

What does the firmware_class need to do here that it doesn't do today?

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

How would dbus in the kernel change anything here?

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

The kernel directly loads firmware from the filesystem now, no userspace
helpers are involved, so no need for udev, libusb, etc.  And as such, no
need for any "dbus" in the kernel to do this either.

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

I don't understand how it could, please explain.

Also note, for those not knowing, we have been working on dbus in the
kernel (google "kdbus" for the github repo), but it is all
outward-facing (i.e. userspace using the kdbus code to interact with
other processes with a dbus-like protocol, not for in-kernel dbus
things, although adding it wouldn't be that hard, just really strange.

thanks,

greg k-h
--
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