linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTin3QqukxP8M_L9nWgkrv6bGsnGx1JFNtOY1jXtp@mail.gmail.com>
Date:	Wed, 29 Sep 2010 12:40:23 -0700
From:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
To:	Marcel Holtmann <holtmann@...ux.intel.com>,
	Ken Steck <Ken.Steck@...eros.com>,
	Shanmugamkamatchi Balashanmugam 
	<Shanmugamkamatchi.Balashanmugam@...eros.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: Re: RFC: btusb firmware load help

On Fri, Sep 24, 2010 at 4:07 PM, Luis R. Rodriguez
<lrodriguez@...eros.com> wrote:
> 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, and we need to support existing customers with
> current hardware, can you provide some recommendation as to an alternative
> approach to resolve this upstream?

Marcel some attention to this would be greatly appreciated.

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

I have gotten clarifications from Ken Steck that this issue is only
present on AR3011 chips used in the SFLASH configuration. AR3012 will
not have this issue.

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

I saw no takers on this.. so I just created the page myself.

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

Shanmugamkamatchi has noted to me he will be sending me this patch
soon and it also supports suspend/resume properly, however, I would
like to resolve this upstream.

Marcel, please let us know what path you recommend we take for this.

  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/