linux-kernel - RFC: btusb firmware load help

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-next>] [day] [month] [year] [list]

Message-ID: <20100924230730.GB6566@tux>
Date:	Fri, 24 Sep 2010 16:07:31 -0700
From:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
To:	Marcel Holtmann <holtmann@...ux.intel.com>
CC:	linux-bluetooth <linux-bluetooth@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-wireless@...r.kernel.org>,
	Deepak Dhamdhere <Deepak.Dhamdhere@...eros.com>,
	Sree Durbha <Sree.Durbha@...eros.com>
Subject: RFC: btusb firmware load help

Marcel, I was just poked about this thread:

http://www.spinics.net/lists/linux-bluetooth/msg06087.html

The hack is required because our BT hardware does not accept HCI commands
when the device is plugged in. If I understood your position you did not
want to accept the patch because our BT USB devices are violating the
specification by not acceping HCI commands and yet claiming to be BT
devices, is that right?

This position seems perfectly reasonable, and if it is violating the
specification this needs to be fixed in hardware for future devices. But
what is done is done, an dwe need to support existing customers with
current hardware, can you provide some recommendation as to an alternative
approach to resolve this upstream?

Without a patch like the one suggested Atheros' Bluetooth USB devices are
essentially not functional at all. I am in hopes we can come to some agreement
how to deal with a hardware quirk for now while we nag at our hardware team
to consider changing the way our devices work.

Someone from the Atheros BT team: can you send me the same patch to be
applied into compat-wireless under the linux-next-pending/ directory ?
That is, send me a patch which will apply onto compat-wireless.
This way we can actually get our hardware functional to customers while
we try to look for a better alternative directly upstream. You will
also need to document this issue on the wiki. I recommend you document
this here:

http://wireless.kernel.org/en/users/Drivers/ath3k

That is, create a new wiki page there for the driver and the things
needed for it. Once I get the patch into compat-wireless we can
refer users/customers to the compat-wireless stable releases with
the linux-next-pending/ patch you give to me applied.

Someone from the Atheros BT team: does the patch currently handle
suspend/resume?

  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/