Re: [PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

["Gustavo F. Padovan" <padovan@profusion.mobi>]

* Li, Steven <yongli@qca.qualcomm.com> [2011-06-29 06:14:34 +0000]:

> 
> Hi Padovan:
> 
> > -----Original Message-----
> > From: Gustavo F. Padovan [mailto:pao@profusion.mobi] On Behalf Of
> > Gustavo F. Padovan
> > Sent: Wednesday, June 29, 2011 12:32 PM
> > To: Li, Steven
> > Cc: Marcel Holtmann; linux-bluetooth@vger.kernel.org
> > Subject: Re: [PATCH] Bluetooth: Ath3k keeps same PID/VID after
> > downloading the patch and radio table
> > 
> > Hi Steven,
> > 
> > Please stop messy top postings like this one. It's not allowed on this mailing
> > list. Thanks.
> > 
> > * Li, Steven <yongli@qca.qualcomm.com> [2011-06-29 03:51:03 +0000]:
> > 
> > > Hi Marcel:
> > >
> > > > please fix the coding style. It is if[space](.
> > > Okay, I see.
> > >
> > > > I would say something similar in style
> > > > to what I have done for the older CSR chips. See workaround above.
> > > > And on that note, you could use data->udev to get the usb_device
> > > > struct ;)
> > > As to this point,  since now we are not using the btusb to download the
> > patch and radio table,
> > >  I think we do not need to alloc the data struct and use data->udev before
> > the workaround.
> > > So I'll still keep it was.  How do you think it ?
> > 
> > No, there is no extra allocation. data->udev is already there. Just use it as
> > Marcel said.
> 
> There is somehow different with  the older CSR chips.
> We need to return -NODEV directly if the bcd version of the 3012 chip is lower or equal to 0x0001,
> And I think in such "return -NODEV" case, we totally do not need to alloc the btusb_data.

Ah yes, you right, I misread the patch.

	Gustavo