Re: rsi_91x: Failed to read status register on failed authentication

[Amitkumar Karwar]

On Tue, Dec 5, 2017 at 9:41 PM, Alexey Brodkin
 wrote:
> Hi Amit,
>
> I'm seeing quite a strange behavior of RedPine module.
> It connects perfectly fine to one of access points but fails
> to connect to another.
>
> Moreover after that failure RSI driver starts to flood me with
> messages saying:
> ->8
> rsi_91x: rsi_sdio_check_buffer_status: Failed to read status register
> ->8
>
> Below you may find details of my 2 experiments.
> Note I use vanilla Linux kernel v4.14.4
>
> Any ideas what could be wrong?
>

Could you enable driver debug zones and share dmesg log for analysis?

echo 0x > /sys/kernel/debug/phy0/debug_zone

Regards,
Amitkumar

Re: rsi_91x: Failed to read status register on failed authentication

[Amitkumar Karwar]

On Tue, Dec 5, 2017 at 9:41 PM, Alexey Brodkin
 wrote:
> Hi Amit,
>
> I'm seeing quite a strange behavior of RedPine module.
> It connects perfectly fine to one of access points but fails
> to connect to another.
>
> Moreover after that failure RSI driver starts to flood me with
> messages saying:
> ->8
> rsi_91x: rsi_sdio_check_buffer_status: Failed to read status register
> ->8
>
> Below you may find details of my 2 experiments.
> Note I use vanilla Linux kernel v4.14.4
>
> Any ideas what could be wrong?
>

Could you enable driver debug zones and share dmesg log for analysis?

echo 0x > /sys/kernel/debug/phy0/debug_zone

Regards,
Amitkumar

RE: Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

[Amitkumar Karwar]

Hi Brian,

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, January 18, 2017 1:18 AM
> To: Dmitry Torokhov
> Cc: Amitkumar Karwar; Nishant Sarmukadam; linux-kernel@vger.kernel.org;
> Kalle Valo; linux-wirel...@vger.kernel.org; Cathy Luo
> Subject: Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry
> interrupt status checks
> 
> On Sun, Jan 15, 2017 at 04:54:52PM -0800, Dmitry Torokhov wrote:
> > On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote:
> > > The following sequence occurs when using IEEE power-save on 8997:
> > > (a) driver sees SLEEP event
> > > (b) driver issues SLEEP CONFIRM
> > > (c) driver recevies CMD interrupt; within the interrupt processing
> loop,
> > > we do (d) and (e):
> > > (d) wait for FW sleep cookie (and often time out; it takes a
> while), FW
> > > is putting card into low power mode
> > > (e) re-check PCIE_HOST_INT_STATUS register; quit loop with 0 value
> > >
> > > But at (e), no one actually signaled an interrupt (i.e., we didn't
> > > check
> > > adapter->int_status). And what's more, because the card is going to
> > > sleep, this register read appears to take a very long time in some
> > > cases
> > > -- 3 milliseconds in my case!
> > >
> > > Now, I propose that (e) is completely unnecessary. If there were
> any
> > > additional interrupts signaled after the start of this loop, then
> > > the interrupt handler would have set adapter->int_status to non-
> zero
> > > and queued more work for the main loop -- and we'd catch it on the
> > > next iteration of the main loop.
> > >
> > > So this patch drops all the looping/re-reading of
> > > PCIE_HOST_INT_STATUS, which avoids the problematic (and slow)
> register read in step (e).
> > >
> > > Incidentally, this is a very similar issue to the one fixed in
> > > commit
> > > ec815dd2a5f1 ("mwifiex: prevent register accesses after host is
> > > sleeping"), except that the register read is just very slow instead
> > > of fatal in this case.
> > >
> > > Tested on 8997 in both MSI and (though not technically supported at
> > > the
> > > moment) MSI-X mode.
> >
> > Well, that kills interrupt mitigation and with PCIE that might be
> > somewhat important (SDIO is too slow to be important I think) and
> > might cost you throughput.
> 
> Hmm, well I don't see us disabling interrupts in here, at least for MSI
> mode, so it doesn't actually look like a mitigation mechanism. More
> like a redundancy. But I'm not an expert on MSI, and definitely not on
> network performance.
> 
> Also, FWIW, I did some fairly non-scientific tests of this on my
> systems, and I didn't see much difference. I can run better tests, and
> even collect data on how often we loop here vs. see new interrupts.
> 
> > OTOH maybe Marvell should convert PICE to NAPI to make this more
> > obvious and probably more correct.
> 
> From my brief reading, that sounds like a better way to make this
> configurable.
> 
> So I'm not sure which way you'd suggest then; take a patch like this,
> which makes the driver more clear and less buggy? Or write some
> different patch that isolates just the power-save related condition, so
> we break out of this look [1]?
> 
> I'm also interested in any opinions from the Marvell side --
> potentially testing results, rationale behind this code structure, or
> even a better alternative patch.
> 

Thanks for the fix. It looks fine to me. Alternate fix would be below change.
We ran throughput tests with your patch vs below change. Results are almost 
same.


@@ -2370,7 +2370,7 @@ static int mwifiex_process_pcie_int(struct 
mwifiex_adapter *adapter)
ret = mwifiex_pcie_process_cmd_complete(adapter);
if (ret)
return ret;
-   if (adapter->hs_activated)
+   if (adapter->hs_activated || adapter->ps_state == 
PS_STATE_SLEEP)
return ret;


The logic of having while loop here was to avoid scheduling latency. As Dmitry 
pointed out in other email packet aggregation takes care of interrupts arriving 
too closely together. We have Rx buffer ring of size 32. So we may get a single 
interrupt to deliver 32 Rx packets.

Regards,
Amitkumar

RE: Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

[Amitkumar Karwar]

Hi Brian,

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, January 18, 2017 1:18 AM
> To: Dmitry Torokhov
> Cc: Amitkumar Karwar; Nishant Sarmukadam; linux-kernel@vger.kernel.org;
> Kalle Valo; linux-wirel...@vger.kernel.org; Cathy Luo
> Subject: Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry
> interrupt status checks
> 
> On Sun, Jan 15, 2017 at 04:54:52PM -0800, Dmitry Torokhov wrote:
> > On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote:
> > > The following sequence occurs when using IEEE power-save on 8997:
> > > (a) driver sees SLEEP event
> > > (b) driver issues SLEEP CONFIRM
> > > (c) driver recevies CMD interrupt; within the interrupt processing
> loop,
> > > we do (d) and (e):
> > > (d) wait for FW sleep cookie (and often time out; it takes a
> while), FW
> > > is putting card into low power mode
> > > (e) re-check PCIE_HOST_INT_STATUS register; quit loop with 0 value
> > >
> > > But at (e), no one actually signaled an interrupt (i.e., we didn't
> > > check
> > > adapter->int_status). And what's more, because the card is going to
> > > sleep, this register read appears to take a very long time in some
> > > cases
> > > -- 3 milliseconds in my case!
> > >
> > > Now, I propose that (e) is completely unnecessary. If there were
> any
> > > additional interrupts signaled after the start of this loop, then
> > > the interrupt handler would have set adapter->int_status to non-
> zero
> > > and queued more work for the main loop -- and we'd catch it on the
> > > next iteration of the main loop.
> > >
> > > So this patch drops all the looping/re-reading of
> > > PCIE_HOST_INT_STATUS, which avoids the problematic (and slow)
> register read in step (e).
> > >
> > > Incidentally, this is a very similar issue to the one fixed in
> > > commit
> > > ec815dd2a5f1 ("mwifiex: prevent register accesses after host is
> > > sleeping"), except that the register read is just very slow instead
> > > of fatal in this case.
> > >
> > > Tested on 8997 in both MSI and (though not technically supported at
> > > the
> > > moment) MSI-X mode.
> >
> > Well, that kills interrupt mitigation and with PCIE that might be
> > somewhat important (SDIO is too slow to be important I think) and
> > might cost you throughput.
> 
> Hmm, well I don't see us disabling interrupts in here, at least for MSI
> mode, so it doesn't actually look like a mitigation mechanism. More
> like a redundancy. But I'm not an expert on MSI, and definitely not on
> network performance.
> 
> Also, FWIW, I did some fairly non-scientific tests of this on my
> systems, and I didn't see much difference. I can run better tests, and
> even collect data on how often we loop here vs. see new interrupts.
> 
> > OTOH maybe Marvell should convert PICE to NAPI to make this more
> > obvious and probably more correct.
> 
> From my brief reading, that sounds like a better way to make this
> configurable.
> 
> So I'm not sure which way you'd suggest then; take a patch like this,
> which makes the driver more clear and less buggy? Or write some
> different patch that isolates just the power-save related condition, so
> we break out of this look [1]?
> 
> I'm also interested in any opinions from the Marvell side --
> potentially testing results, rationale behind this code structure, or
> even a better alternative patch.
> 

Thanks for the fix. It looks fine to me. Alternate fix would be below change.
We ran throughput tests with your patch vs below change. Results are almost 
same.


@@ -2370,7 +2370,7 @@ static int mwifiex_process_pcie_int(struct 
mwifiex_adapter *adapter)
ret = mwifiex_pcie_process_cmd_complete(adapter);
if (ret)
return ret;
-   if (adapter->hs_activated)
+   if (adapter->hs_activated || adapter->ps_state == 
PS_STATE_SLEEP)
return ret;


The logic of having while loop here was to avoid scheduling latency. As Dmitry 
pointed out in other email packet aggregation takes care of interrupts arriving 
too closely together. We have Rx buffer ring of size 32. So we may get a single 
interrupt to deliver 32 Rx packets.

Regards,
Amitkumar

RE: [PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar
> Sent: Friday, November 25, 2016 4:51 PM
> To: 'Marcel Holtmann'
> Cc: 'linux-blueto...@vger.kernel.org'; 'linux-kernel@vger.kernel.org';
> Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> Subject: RE: [PATCH] btusb: fix zero BD address problem during stress
> test
> 
> Hi Marcel,
> 
> > From: Amitkumar Karwar
> > Sent: Wednesday, November 23, 2016 3:14 PM
> > To: 'Marcel Holtmann'
> > Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> > Subject: RE: [PATCH] btusb: fix zero BD address problem during stress
> > test
> >
> > Hi Marcel,
> >
> > > From: Marcel Holtmann [mailto:mar...@holtmann.org]
> > > Sent: Wednesday, November 23, 2016 1:46 PM
> > > To: Amitkumar Karwar
> > > Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> > > Subject: Re: [PATCH] btusb: fix zero BD address problem during
> > > stress test
> > >
> > > Hi Amitkumar,
> > >
> > > >>>> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> > > >>>> Sent: Tuesday, October 18, 2016 6:27 PM
> > > >>>> To: linux-blueto...@vger.kernel.org
> > > >>>> Cc: mar...@holtmann.org; linux-kernel@vger.kernel.org; Cathy
> > Luo;
> > > >>>> Nishant Sarmukadam; Ganapathi Bhat; Amitkumar Karwar
> > > >>>> Subject: [PATCH] btusb: fix zero BD address problem during
> > stress
> > > >>>> test
> > > >>>>
> > > >>>> From: Ganapathi Bhat <gb...@marvell.com>
> > > >>>>
> > > >>>> We came across a corner case issue during reboot stress test
> in
> > > >> which
> > > >>>> hciconfig shows BD address is all zero. Reason is we don't get
> > > >>>> response for HCI RESET command during initialization
> > > >>>>
> > > >>>> The issue is tracked to a race where USB subsystem calls
> > > >>>> btusb_intr_complete() to deliver a data(NOOP frame) received
> on
> > > >>>> interrupt endpoint. HCI_RUNNING flag is not yet set by
> > > >>>> bluetooth subsystem. So we ignore that frame and return.
> > > >>>>
> > > >>>> As we missed to resubmit the buffer to interrupt endpoint in
> > this
> > > >>>> case, we don't get response for BT reset command downloaded
> > after
> > > >> this.
> > > >>>>
> > > >>>> This patch handles the corner case to resolve zero BD address
> > > >> problem.
> > > >>>>
> > > >>>> Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> > > >>>> Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> > > >>>> ---
> > > >>>> drivers/bluetooth/btusb.c | 5 +
> > > >>>> 1 file changed, 1 insertion(+), 4 deletions(-)
> > > >>>>
> > > >>>> diff --git a/drivers/bluetooth/btusb.c
> > > >>>> b/drivers/bluetooth/btusb.c index 811f9b9..b5596ac 100644
> > > >>>> --- a/drivers/bluetooth/btusb.c
> > > >>>> +++ b/drivers/bluetooth/btusb.c
> > > >>>> @@ -607,10 +607,7 @@ static void btusb_intr_complete(struct
> urb
> > > >> *urb)
> > > >>>>  BT_DBG("%s urb %p status %d count %d", hdev->name, urb,
> > urb-
> > > >>>>> status,
> > > >>>> urb->actual_length);
> > > >>>>
> > > >>>> -if (!test_bit(HCI_RUNNING, >flags))
> > > >>>> -return;
> > > >>>> -
> > > >>>> -if (urb->status == 0) {
> > > >>>> +if (urb->status == 0 && test_bit(HCI_RUNNING, 
> > > >flags)) {
> > > >>>>  hdev->stat.byte_rx += urb->actual_length;
> > > >>>>
> > > >>>>  if (btusb_recv_intr(data, urb->transfer_buffer,
> > > >>>
> > > >>> Did you get a chance to check this?
> > > >>> Please let us know if you have any review comments.
> > > >>
> > > >> can you explain how th

RE: [PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar
> Sent: Friday, November 25, 2016 4:51 PM
> To: 'Marcel Holtmann'
> Cc: 'linux-blueto...@vger.kernel.org'; 'linux-kernel@vger.kernel.org';
> Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> Subject: RE: [PATCH] btusb: fix zero BD address problem during stress
> test
> 
> Hi Marcel,
> 
> > From: Amitkumar Karwar
> > Sent: Wednesday, November 23, 2016 3:14 PM
> > To: 'Marcel Holtmann'
> > Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> > Subject: RE: [PATCH] btusb: fix zero BD address problem during stress
> > test
> >
> > Hi Marcel,
> >
> > > From: Marcel Holtmann [mailto:mar...@holtmann.org]
> > > Sent: Wednesday, November 23, 2016 1:46 PM
> > > To: Amitkumar Karwar
> > > Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> > > Subject: Re: [PATCH] btusb: fix zero BD address problem during
> > > stress test
> > >
> > > Hi Amitkumar,
> > >
> > > >>>> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> > > >>>> Sent: Tuesday, October 18, 2016 6:27 PM
> > > >>>> To: linux-blueto...@vger.kernel.org
> > > >>>> Cc: mar...@holtmann.org; linux-kernel@vger.kernel.org; Cathy
> > Luo;
> > > >>>> Nishant Sarmukadam; Ganapathi Bhat; Amitkumar Karwar
> > > >>>> Subject: [PATCH] btusb: fix zero BD address problem during
> > stress
> > > >>>> test
> > > >>>>
> > > >>>> From: Ganapathi Bhat 
> > > >>>>
> > > >>>> We came across a corner case issue during reboot stress test
> in
> > > >> which
> > > >>>> hciconfig shows BD address is all zero. Reason is we don't get
> > > >>>> response for HCI RESET command during initialization
> > > >>>>
> > > >>>> The issue is tracked to a race where USB subsystem calls
> > > >>>> btusb_intr_complete() to deliver a data(NOOP frame) received
> on
> > > >>>> interrupt endpoint. HCI_RUNNING flag is not yet set by
> > > >>>> bluetooth subsystem. So we ignore that frame and return.
> > > >>>>
> > > >>>> As we missed to resubmit the buffer to interrupt endpoint in
> > this
> > > >>>> case, we don't get response for BT reset command downloaded
> > after
> > > >> this.
> > > >>>>
> > > >>>> This patch handles the corner case to resolve zero BD address
> > > >> problem.
> > > >>>>
> > > >>>> Signed-off-by: Ganapathi Bhat 
> > > >>>> Signed-off-by: Amitkumar Karwar 
> > > >>>> ---
> > > >>>> drivers/bluetooth/btusb.c | 5 +
> > > >>>> 1 file changed, 1 insertion(+), 4 deletions(-)
> > > >>>>
> > > >>>> diff --git a/drivers/bluetooth/btusb.c
> > > >>>> b/drivers/bluetooth/btusb.c index 811f9b9..b5596ac 100644
> > > >>>> --- a/drivers/bluetooth/btusb.c
> > > >>>> +++ b/drivers/bluetooth/btusb.c
> > > >>>> @@ -607,10 +607,7 @@ static void btusb_intr_complete(struct
> urb
> > > >> *urb)
> > > >>>>  BT_DBG("%s urb %p status %d count %d", hdev->name, urb,
> > urb-
> > > >>>>> status,
> > > >>>> urb->actual_length);
> > > >>>>
> > > >>>> -if (!test_bit(HCI_RUNNING, >flags))
> > > >>>> -return;
> > > >>>> -
> > > >>>> -if (urb->status == 0) {
> > > >>>> +if (urb->status == 0 && test_bit(HCI_RUNNING, 
> > > >flags)) {
> > > >>>>  hdev->stat.byte_rx += urb->actual_length;
> > > >>>>
> > > >>>>  if (btusb_recv_intr(data, urb->transfer_buffer,
> > > >>>
> > > >>> Did you get a chance to check this?
> > > >>> Please let us know if you have any review comments.
> > > >>
> > > >> can you explain how this is correct and show me the HCI traces
> > > >> for this.
> > > 

RE: [PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar
> Sent: Wednesday, November 23, 2016 3:14 PM
> To: 'Marcel Holtmann'
> Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> Subject: RE: [PATCH] btusb: fix zero BD address problem during stress
> test
> 
> Hi Marcel,
> 
> > From: Marcel Holtmann [mailto:mar...@holtmann.org]
> > Sent: Wednesday, November 23, 2016 1:46 PM
> > To: Amitkumar Karwar
> > Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> > Subject: Re: [PATCH] btusb: fix zero BD address problem during stress
> > test
> >
> > Hi Amitkumar,
> >
> > >>>> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> > >>>> Sent: Tuesday, October 18, 2016 6:27 PM
> > >>>> To: linux-blueto...@vger.kernel.org
> > >>>> Cc: mar...@holtmann.org; linux-kernel@vger.kernel.org; Cathy
> Luo;
> > >>>> Nishant Sarmukadam; Ganapathi Bhat; Amitkumar Karwar
> > >>>> Subject: [PATCH] btusb: fix zero BD address problem during
> stress
> > >>>> test
> > >>>>
> > >>>> From: Ganapathi Bhat <gb...@marvell.com>
> > >>>>
> > >>>> We came across a corner case issue during reboot stress test in
> > >> which
> > >>>> hciconfig shows BD address is all zero. Reason is we don't get
> > >>>> response for HCI RESET command during initialization
> > >>>>
> > >>>> The issue is tracked to a race where USB subsystem calls
> > >>>> btusb_intr_complete() to deliver a data(NOOP frame) received on
> > >>>> interrupt endpoint. HCI_RUNNING flag is not yet set by bluetooth
> > >>>> subsystem. So we ignore that frame and return.
> > >>>>
> > >>>> As we missed to resubmit the buffer to interrupt endpoint in
> this
> > >>>> case, we don't get response for BT reset command downloaded
> after
> > >> this.
> > >>>>
> > >>>> This patch handles the corner case to resolve zero BD address
> > >> problem.
> > >>>>
> > >>>> Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> > >>>> Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> > >>>> ---
> > >>>> drivers/bluetooth/btusb.c | 5 +
> > >>>> 1 file changed, 1 insertion(+), 4 deletions(-)
> > >>>>
> > >>>> diff --git a/drivers/bluetooth/btusb.c
> > >>>> b/drivers/bluetooth/btusb.c index 811f9b9..b5596ac 100644
> > >>>> --- a/drivers/bluetooth/btusb.c
> > >>>> +++ b/drivers/bluetooth/btusb.c
> > >>>> @@ -607,10 +607,7 @@ static void btusb_intr_complete(struct urb
> > >> *urb)
> > >>>>BT_DBG("%s urb %p status %d count %d", hdev->name, urb,
> urb-
> > >>>>> status,
> > >>>>   urb->actual_length);
> > >>>>
> > >>>> -  if (!test_bit(HCI_RUNNING, >flags))
> > >>>> -  return;
> > >>>> -
> > >>>> -  if (urb->status == 0) {
> > >>>> +  if (urb->status == 0 && test_bit(HCI_RUNNING, 
> > >flags)) {
> > >>>>hdev->stat.byte_rx += urb->actual_length;
> > >>>>
> > >>>>if (btusb_recv_intr(data, urb->transfer_buffer,
> > >>>
> > >>> Did you get a chance to check this?
> > >>> Please let us know if you have any review comments.
> > >>
> > >> can you explain how this is correct and show me the HCI traces for
> > >> this.
> > >>
> > >
> > > I suppose HCI trace means hcidump logs here. As device hasn't yet
> > initialized, hcidump won't show anything.
> > > We had added debug info in btusb driver to trace the data received
> > > on
> > all USB endpoints and also checked usbmon logs.
> >
> > use btmon and it will show it.
> >
> > > Here is the sequence of events we observed in a corner case while
> > running stress test.
> > > 1) Inside btusb_open() call -- Thread 1
> > > 2) btusb_submit_intr_urb() submits the URB for receiving data on
> > > interrupt endpoint  Thread 1
> 

RE: [PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar
> Sent: Wednesday, November 23, 2016 3:14 PM
> To: 'Marcel Holtmann'
> Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> Subject: RE: [PATCH] btusb: fix zero BD address problem during stress
> test
> 
> Hi Marcel,
> 
> > From: Marcel Holtmann [mailto:mar...@holtmann.org]
> > Sent: Wednesday, November 23, 2016 1:46 PM
> > To: Amitkumar Karwar
> > Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> > Subject: Re: [PATCH] btusb: fix zero BD address problem during stress
> > test
> >
> > Hi Amitkumar,
> >
> > >>>> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> > >>>> Sent: Tuesday, October 18, 2016 6:27 PM
> > >>>> To: linux-blueto...@vger.kernel.org
> > >>>> Cc: mar...@holtmann.org; linux-kernel@vger.kernel.org; Cathy
> Luo;
> > >>>> Nishant Sarmukadam; Ganapathi Bhat; Amitkumar Karwar
> > >>>> Subject: [PATCH] btusb: fix zero BD address problem during
> stress
> > >>>> test
> > >>>>
> > >>>> From: Ganapathi Bhat 
> > >>>>
> > >>>> We came across a corner case issue during reboot stress test in
> > >> which
> > >>>> hciconfig shows BD address is all zero. Reason is we don't get
> > >>>> response for HCI RESET command during initialization
> > >>>>
> > >>>> The issue is tracked to a race where USB subsystem calls
> > >>>> btusb_intr_complete() to deliver a data(NOOP frame) received on
> > >>>> interrupt endpoint. HCI_RUNNING flag is not yet set by bluetooth
> > >>>> subsystem. So we ignore that frame and return.
> > >>>>
> > >>>> As we missed to resubmit the buffer to interrupt endpoint in
> this
> > >>>> case, we don't get response for BT reset command downloaded
> after
> > >> this.
> > >>>>
> > >>>> This patch handles the corner case to resolve zero BD address
> > >> problem.
> > >>>>
> > >>>> Signed-off-by: Ganapathi Bhat 
> > >>>> Signed-off-by: Amitkumar Karwar 
> > >>>> ---
> > >>>> drivers/bluetooth/btusb.c | 5 +
> > >>>> 1 file changed, 1 insertion(+), 4 deletions(-)
> > >>>>
> > >>>> diff --git a/drivers/bluetooth/btusb.c
> > >>>> b/drivers/bluetooth/btusb.c index 811f9b9..b5596ac 100644
> > >>>> --- a/drivers/bluetooth/btusb.c
> > >>>> +++ b/drivers/bluetooth/btusb.c
> > >>>> @@ -607,10 +607,7 @@ static void btusb_intr_complete(struct urb
> > >> *urb)
> > >>>>BT_DBG("%s urb %p status %d count %d", hdev->name, urb,
> urb-
> > >>>>> status,
> > >>>>   urb->actual_length);
> > >>>>
> > >>>> -  if (!test_bit(HCI_RUNNING, >flags))
> > >>>> -  return;
> > >>>> -
> > >>>> -  if (urb->status == 0) {
> > >>>> +  if (urb->status == 0 && test_bit(HCI_RUNNING, 
> > >flags)) {
> > >>>>hdev->stat.byte_rx += urb->actual_length;
> > >>>>
> > >>>>if (btusb_recv_intr(data, urb->transfer_buffer,
> > >>>
> > >>> Did you get a chance to check this?
> > >>> Please let us know if you have any review comments.
> > >>
> > >> can you explain how this is correct and show me the HCI traces for
> > >> this.
> > >>
> > >
> > > I suppose HCI trace means hcidump logs here. As device hasn't yet
> > initialized, hcidump won't show anything.
> > > We had added debug info in btusb driver to trace the data received
> > > on
> > all USB endpoints and also checked usbmon logs.
> >
> > use btmon and it will show it.
> >
> > > Here is the sequence of events we observed in a corner case while
> > running stress test.
> > > 1) Inside btusb_open() call -- Thread 1
> > > 2) btusb_submit_intr_urb() submits the URB for receiving data on
> > > interrupt endpoint  Thread 1
> > > 3) btusb_intr_complete() gets called to deliver NOP frame from HC

RE: [PATCH] mwifiex: pcie: implement timeout loop for FW programming doorbell

[Amitkumar Karwar]

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, November 23, 2016 8:10 AM
> To: Amitkumar Karwar; Nishant Sarmukadam
> Cc: linux-kernel@vger.kernel.org; Kalle Valo; linux-
> wirel...@vger.kernel.org; Cathy Luo; Dmitry Torokhov; Brian Norris
> Subject: [PATCH] mwifiex: pcie: implement timeout loop for FW
> programming doorbell
> 
> Marvell Wifi PCIe modules don't always behave nicely for PCIe power
> management when their firmware hasn't been loaded, particularly after
> suspending the PCIe link one or more times. When this happens, we might
> end up spinning forever in this status-polling tight loop. Let's make
> this less tight by adding a timeout and by sleeping a bit in between
> reads, as we do with the other similar loops.
> 
> This prevents us from hogging a CPU even in such pathological cases,
> and allows the FW initialization to just fail gracefully instead.
> 
> I chose the same polling parameters as the earlier loop in this
> function, and empirically, I found that this loop never makes it more
> than about 12 cycles in a sane FW init sequence. I had no official
> information on the actual intended latency for this portion of the
> download.
> 
> Signed-off-by: Brian Norris <briannor...@chromium.org>
> ---
>  drivers/net/wireless/marvell/mwifiex/pcie.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 4b89f557d0b6..9f9ea1350591 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -2050,7 +2050,7 @@ static int mwifiex_prog_fw_w_helper(struct
> mwifiex_adapter *adapter,
>   }
> 
>   /* Wait for the command done interrupt */
> - do {
> + for (tries = 0; tries < MAX_POLL_TRIES; tries++) {
>   if (mwifiex_read_reg(adapter, PCIE_CPU_INT_STATUS,
>_intr)) {
>   mwifiex_dbg(adapter, ERROR,
> @@ -2062,8 +2062,18 @@ static int mwifiex_prog_fw_w_helper(struct
> mwifiex_adapter *adapter,
>   ret = -1;
>   goto done;
>   }
> - } while ((ireg_intr & CPU_INTR_DOOR_BELL) ==
> -  CPU_INTR_DOOR_BELL);
> + if (!(ireg_intr & CPU_INTR_DOOR_BELL))
> + break;
> + usleep_range(10, 20);
> + }
> + if (ireg_intr & CPU_INTR_DOOR_BELL) {
> + mwifiex_dbg(adapter, ERROR, "%s: Card failed to ACK
> download\n",
> + __func__);
> + mwifiex_unmap_pci_memory(adapter, skb,
> +  PCI_DMA_TODEVICE);
> + ret = -1;
> + goto done;
> + }
> 
>   mwifiex_unmap_pci_memory(adapter, skb, PCI_DMA_TODEVICE);
> 

Patch looks fine to me.

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH] mwifiex: pcie: implement timeout loop for FW programming doorbell

[Amitkumar Karwar]

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, November 23, 2016 8:10 AM
> To: Amitkumar Karwar; Nishant Sarmukadam
> Cc: linux-kernel@vger.kernel.org; Kalle Valo; linux-
> wirel...@vger.kernel.org; Cathy Luo; Dmitry Torokhov; Brian Norris
> Subject: [PATCH] mwifiex: pcie: implement timeout loop for FW
> programming doorbell
> 
> Marvell Wifi PCIe modules don't always behave nicely for PCIe power
> management when their firmware hasn't been loaded, particularly after
> suspending the PCIe link one or more times. When this happens, we might
> end up spinning forever in this status-polling tight loop. Let's make
> this less tight by adding a timeout and by sleeping a bit in between
> reads, as we do with the other similar loops.
> 
> This prevents us from hogging a CPU even in such pathological cases,
> and allows the FW initialization to just fail gracefully instead.
> 
> I chose the same polling parameters as the earlier loop in this
> function, and empirically, I found that this loop never makes it more
> than about 12 cycles in a sane FW init sequence. I had no official
> information on the actual intended latency for this portion of the
> download.
> 
> Signed-off-by: Brian Norris 
> ---
>  drivers/net/wireless/marvell/mwifiex/pcie.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 4b89f557d0b6..9f9ea1350591 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -2050,7 +2050,7 @@ static int mwifiex_prog_fw_w_helper(struct
> mwifiex_adapter *adapter,
>   }
> 
>   /* Wait for the command done interrupt */
> - do {
> + for (tries = 0; tries < MAX_POLL_TRIES; tries++) {
>   if (mwifiex_read_reg(adapter, PCIE_CPU_INT_STATUS,
>_intr)) {
>   mwifiex_dbg(adapter, ERROR,
> @@ -2062,8 +2062,18 @@ static int mwifiex_prog_fw_w_helper(struct
> mwifiex_adapter *adapter,
>   ret = -1;
>   goto done;
>   }
> - } while ((ireg_intr & CPU_INTR_DOOR_BELL) ==
> -  CPU_INTR_DOOR_BELL);
> + if (!(ireg_intr & CPU_INTR_DOOR_BELL))
> + break;
> + usleep_range(10, 20);
> + }
> + if (ireg_intr & CPU_INTR_DOOR_BELL) {
> + mwifiex_dbg(adapter, ERROR, "%s: Card failed to ACK
> download\n",
> + __func__);
> + mwifiex_unmap_pci_memory(adapter, skb,
> +  PCI_DMA_TODEVICE);
> + ret = -1;
> + goto done;
> + }
> 
>   mwifiex_unmap_pci_memory(adapter, skb, PCI_DMA_TODEVICE);
> 

Patch looks fine to me.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

RE: [PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

Hi Marcel,

> From: Marcel Holtmann [mailto:mar...@holtmann.org]
> Sent: Wednesday, November 23, 2016 1:46 PM
> To: Amitkumar Karwar
> Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> Subject: Re: [PATCH] btusb: fix zero BD address problem during stress
> test
> 
> Hi Amitkumar,
> 
> >>>> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> >>>> Sent: Tuesday, October 18, 2016 6:27 PM
> >>>> To: linux-blueto...@vger.kernel.org
> >>>> Cc: mar...@holtmann.org; linux-kernel@vger.kernel.org; Cathy Luo;
> >>>> Nishant Sarmukadam; Ganapathi Bhat; Amitkumar Karwar
> >>>> Subject: [PATCH] btusb: fix zero BD address problem during stress
> >>>> test
> >>>>
> >>>> From: Ganapathi Bhat <gb...@marvell.com>
> >>>>
> >>>> We came across a corner case issue during reboot stress test in
> >> which
> >>>> hciconfig shows BD address is all zero. Reason is we don't get
> >>>> response for HCI RESET command during initialization
> >>>>
> >>>> The issue is tracked to a race where USB subsystem calls
> >>>> btusb_intr_complete() to deliver a data(NOOP frame) received on
> >>>> interrupt endpoint. HCI_RUNNING flag is not yet set by bluetooth
> >>>> subsystem. So we ignore that frame and return.
> >>>>
> >>>> As we missed to resubmit the buffer to interrupt endpoint in this
> >>>> case, we don't get response for BT reset command downloaded after
> >> this.
> >>>>
> >>>> This patch handles the corner case to resolve zero BD address
> >> problem.
> >>>>
> >>>> Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> >>>> Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> >>>> ---
> >>>> drivers/bluetooth/btusb.c | 5 +
> >>>> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> >>>> index 811f9b9..b5596ac 100644
> >>>> --- a/drivers/bluetooth/btusb.c
> >>>> +++ b/drivers/bluetooth/btusb.c
> >>>> @@ -607,10 +607,7 @@ static void btusb_intr_complete(struct urb
> >> *urb)
> >>>>  BT_DBG("%s urb %p status %d count %d", hdev->name, urb, urb-
> >>>>> status,
> >>>> urb->actual_length);
> >>>>
> >>>> -if (!test_bit(HCI_RUNNING, >flags))
> >>>> -return;
> >>>> -
> >>>> -if (urb->status == 0) {
> >>>> +if (urb->status == 0 && test_bit(HCI_RUNNING, 
> >flags)) {
> >>>>  hdev->stat.byte_rx += urb->actual_length;
> >>>>
> >>>>  if (btusb_recv_intr(data, urb->transfer_buffer,
> >>>
> >>> Did you get a chance to check this?
> >>> Please let us know if you have any review comments.
> >>
> >> can you explain how this is correct and show me the HCI traces for
> >> this.
> >>
> >
> > I suppose HCI trace means hcidump logs here. As device hasn't yet
> initialized, hcidump won't show anything.
> > We had added debug info in btusb driver to trace the data received on
> all USB endpoints and also checked usbmon logs.
> 
> use btmon and it will show it.
> 
> > Here is the sequence of events we observed in a corner case while
> running stress test.
> > 1) Inside btusb_open() call -- Thread 1
> > 2) btusb_submit_intr_urb() submits the URB for receiving data on
> > interrupt endpoint  Thread 1
> > 3) btusb_intr_complete() gets called to deliver NOP frame from HCI
> > controller  Thread 2
> > 4) HCI_RUNNING isn't set yet. So we return from btusb_intr_complete()
> > without resubmitting the buffer --- Thread 2
> > 5) Exit btusb_open()  Thread 1
> > 6) "set_bit(HCI_RUNNING, >flags)" done by bluetooth core 
> > Thread 1
> >
> > Later HCI_RESET command gets timedout, as we haven't re-submitted
> buffer for interrupt endpoint in step (4) above.
> >
> > Please find attached logs. usbmon log shows first frame received on
> interrupt endpoint is NOP(Search for Marvell in log).
> >
> > Here is what bluetooth spec says about NOP frame.
> >
> > "To indicate to the Host that

RE: [PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

Hi Marcel,

> From: Marcel Holtmann [mailto:mar...@holtmann.org]
> Sent: Wednesday, November 23, 2016 1:46 PM
> To: Amitkumar Karwar
> Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Cathy Luo; Nishant Sarmukadam; Ganapathi Bhat
> Subject: Re: [PATCH] btusb: fix zero BD address problem during stress
> test
> 
> Hi Amitkumar,
> 
> >>>> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> >>>> Sent: Tuesday, October 18, 2016 6:27 PM
> >>>> To: linux-blueto...@vger.kernel.org
> >>>> Cc: mar...@holtmann.org; linux-kernel@vger.kernel.org; Cathy Luo;
> >>>> Nishant Sarmukadam; Ganapathi Bhat; Amitkumar Karwar
> >>>> Subject: [PATCH] btusb: fix zero BD address problem during stress
> >>>> test
> >>>>
> >>>> From: Ganapathi Bhat 
> >>>>
> >>>> We came across a corner case issue during reboot stress test in
> >> which
> >>>> hciconfig shows BD address is all zero. Reason is we don't get
> >>>> response for HCI RESET command during initialization
> >>>>
> >>>> The issue is tracked to a race where USB subsystem calls
> >>>> btusb_intr_complete() to deliver a data(NOOP frame) received on
> >>>> interrupt endpoint. HCI_RUNNING flag is not yet set by bluetooth
> >>>> subsystem. So we ignore that frame and return.
> >>>>
> >>>> As we missed to resubmit the buffer to interrupt endpoint in this
> >>>> case, we don't get response for BT reset command downloaded after
> >> this.
> >>>>
> >>>> This patch handles the corner case to resolve zero BD address
> >> problem.
> >>>>
> >>>> Signed-off-by: Ganapathi Bhat 
> >>>> Signed-off-by: Amitkumar Karwar 
> >>>> ---
> >>>> drivers/bluetooth/btusb.c | 5 +
> >>>> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> >>>> index 811f9b9..b5596ac 100644
> >>>> --- a/drivers/bluetooth/btusb.c
> >>>> +++ b/drivers/bluetooth/btusb.c
> >>>> @@ -607,10 +607,7 @@ static void btusb_intr_complete(struct urb
> >> *urb)
> >>>>  BT_DBG("%s urb %p status %d count %d", hdev->name, urb, urb-
> >>>>> status,
> >>>> urb->actual_length);
> >>>>
> >>>> -if (!test_bit(HCI_RUNNING, >flags))
> >>>> -return;
> >>>> -
> >>>> -if (urb->status == 0) {
> >>>> +if (urb->status == 0 && test_bit(HCI_RUNNING, 
> >flags)) {
> >>>>  hdev->stat.byte_rx += urb->actual_length;
> >>>>
> >>>>  if (btusb_recv_intr(data, urb->transfer_buffer,
> >>>
> >>> Did you get a chance to check this?
> >>> Please let us know if you have any review comments.
> >>
> >> can you explain how this is correct and show me the HCI traces for
> >> this.
> >>
> >
> > I suppose HCI trace means hcidump logs here. As device hasn't yet
> initialized, hcidump won't show anything.
> > We had added debug info in btusb driver to trace the data received on
> all USB endpoints and also checked usbmon logs.
> 
> use btmon and it will show it.
> 
> > Here is the sequence of events we observed in a corner case while
> running stress test.
> > 1) Inside btusb_open() call -- Thread 1
> > 2) btusb_submit_intr_urb() submits the URB for receiving data on
> > interrupt endpoint  Thread 1
> > 3) btusb_intr_complete() gets called to deliver NOP frame from HCI
> > controller  Thread 2
> > 4) HCI_RUNNING isn't set yet. So we return from btusb_intr_complete()
> > without resubmitting the buffer --- Thread 2
> > 5) Exit btusb_open()  Thread 1
> > 6) "set_bit(HCI_RUNNING, >flags)" done by bluetooth core 
> > Thread 1
> >
> > Later HCI_RESET command gets timedout, as we haven't re-submitted
> buffer for interrupt endpoint in step (4) above.
> >
> > Please find attached logs. usbmon log shows first frame received on
> interrupt endpoint is NOP(Search for Marvell in log).
> >
> > Here is what bluetooth spec says about NOP frame.
> >
> > "To indicate to the Host that the Controller is ready to receive HCI
> > command packets, the Control

RE: [PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> Sent: Tuesday, October 18, 2016 6:27 PM
> To: linux-blueto...@vger.kernel.org
> Cc: mar...@holtmann.org; linux-kernel@vger.kernel.org; Cathy Luo;
> Nishant Sarmukadam; Ganapathi Bhat; Amitkumar Karwar
> Subject: [PATCH] btusb: fix zero BD address problem during stress test
> 
> From: Ganapathi Bhat <gb...@marvell.com>
> 
> We came across a corner case issue during reboot stress test in which
> hciconfig shows BD address is all zero. Reason is we don't get response
> for HCI RESET command during initialization
> 
> The issue is tracked to a race where USB subsystem calls
> btusb_intr_complete() to deliver a data(NOOP frame) received on
> interrupt endpoint. HCI_RUNNING flag is not yet set by bluetooth
> subsystem. So we ignore that frame and return.
> 
> As we missed to resubmit the buffer to interrupt endpoint in this case,
> we don't get response for BT reset command downloaded after this.
> 
> This patch handles the corner case to resolve zero BD address problem.
> 
> Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> ---
>  drivers/bluetooth/btusb.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 811f9b9..b5596ac 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -607,10 +607,7 @@ static void btusb_intr_complete(struct urb *urb)
>   BT_DBG("%s urb %p status %d count %d", hdev->name, urb, urb-
> >status,
>  urb->actual_length);
> 
> - if (!test_bit(HCI_RUNNING, >flags))
> - return;
> -
> - if (urb->status == 0) {
> + if (urb->status == 0 && test_bit(HCI_RUNNING, >flags)) {
>   hdev->stat.byte_rx += urb->actual_length;
> 
>   if (btusb_recv_intr(data, urb->transfer_buffer,

Did you get a chance to check this?
Please let us know if you have any review comments.

Regards,
Amitkumar

RE: [PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> Sent: Tuesday, October 18, 2016 6:27 PM
> To: linux-blueto...@vger.kernel.org
> Cc: mar...@holtmann.org; linux-kernel@vger.kernel.org; Cathy Luo;
> Nishant Sarmukadam; Ganapathi Bhat; Amitkumar Karwar
> Subject: [PATCH] btusb: fix zero BD address problem during stress test
> 
> From: Ganapathi Bhat 
> 
> We came across a corner case issue during reboot stress test in which
> hciconfig shows BD address is all zero. Reason is we don't get response
> for HCI RESET command during initialization
> 
> The issue is tracked to a race where USB subsystem calls
> btusb_intr_complete() to deliver a data(NOOP frame) received on
> interrupt endpoint. HCI_RUNNING flag is not yet set by bluetooth
> subsystem. So we ignore that frame and return.
> 
> As we missed to resubmit the buffer to interrupt endpoint in this case,
> we don't get response for BT reset command downloaded after this.
> 
> This patch handles the corner case to resolve zero BD address problem.
> 
> Signed-off-by: Ganapathi Bhat 
> Signed-off-by: Amitkumar Karwar 
> ---
>  drivers/bluetooth/btusb.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 811f9b9..b5596ac 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -607,10 +607,7 @@ static void btusb_intr_complete(struct urb *urb)
>   BT_DBG("%s urb %p status %d count %d", hdev->name, urb, urb-
> >status,
>  urb->actual_length);
> 
> - if (!test_bit(HCI_RUNNING, >flags))
> - return;
> -
> - if (urb->status == 0) {
> + if (urb->status == 0 && test_bit(HCI_RUNNING, >flags)) {
>   hdev->stat.byte_rx += urb->actual_length;
> 
>   if (btusb_recv_intr(data, urb->transfer_buffer,

Did you get a chance to check this?
Please let us know if you have any review comments.

Regards,
Amitkumar

RE: [PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()

[Amitkumar Karwar]

> From: Ricky Liang [mailto:jcli...@chromium.org]
> Sent: Wednesday, November 09, 2016 9:07 AM
> Cc: Ricky Liang; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; open
> list:MARVELL MWIFIEX WIRELESS DRIVER; open list:NETWORKING DRIVERS; open
> list
> Subject: [PATCH] mwifiex: fix memory leak in
> mwifiex_save_hidden_ssid_channels()
> 
> kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels():
> 
> unreferenced object 0xffc0a2914780 (size 192):
>   comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s)
>   hex dump (first 32 bytes):
> 00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40  ..GIN-2g...`l..@
> 07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04  ..TW 4..d.$..$..
>   backtrace:
> [] create_object+0x164/0x2b4
> [] kmemleak_alloc+0x50/0x88
> [] __kmalloc_track_caller+0x1bc/0x264
> [] kmemdup+0x38/0x64
> [] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex]
> [] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex]
> []
> mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex]
> [] mwifiex_process_sta_event+0x378/0x898 [mwifiex]
> [] mwifiex_process_event+0x1a8/0x1e8 [mwifiex]
> [] mwifiex_main_process+0x258/0x534 [mwifiex]
> [] 0xffbffc258858
> [] process_sdio_pending_irqs+0xf8/0x160
> [] sdio_irq_thread+0x9c/0x1a4
> [] kthread+0xf4/0x100
> [] ret_from_fork+0xc/0x50
> [] 0x
> 
> Signed-off-by: Ricky Liang <jcli...@chromium.org>
> ---
>  drivers/net/wireless/marvell/mwifiex/scan.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
> b/drivers/net/wireless/marvell/mwifiex/scan.c
> index 97c9765..98ce072 100644
> --- a/drivers/net/wireless/marvell/mwifiex/scan.c
> +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
> @@ -1671,6 +1671,10 @@ static int
> mwifiex_save_hidden_ssid_channels(struct mwifiex_private *priv,
>   }
> 
>  done:
> + /* beacon_ie buffer was allocated in function
> +  * mwifiex_fill_new_bss_desc(). Free it now.
> +  */
> + kfree(bss_desc->beacon_buf);
>   kfree(bss_desc);
>   return 0;
>  }

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()

[Amitkumar Karwar]

> From: Ricky Liang [mailto:jcli...@chromium.org]
> Sent: Wednesday, November 09, 2016 9:07 AM
> Cc: Ricky Liang; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; open
> list:MARVELL MWIFIEX WIRELESS DRIVER; open list:NETWORKING DRIVERS; open
> list
> Subject: [PATCH] mwifiex: fix memory leak in
> mwifiex_save_hidden_ssid_channels()
> 
> kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels():
> 
> unreferenced object 0xffc0a2914780 (size 192):
>   comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s)
>   hex dump (first 32 bytes):
> 00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40  ..GIN-2g...`l..@
> 07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04  ..TW 4..d.$..$..
>   backtrace:
> [] create_object+0x164/0x2b4
> [] kmemleak_alloc+0x50/0x88
> [] __kmalloc_track_caller+0x1bc/0x264
> [] kmemdup+0x38/0x64
> [] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex]
> [] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex]
> []
> mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex]
> [] mwifiex_process_sta_event+0x378/0x898 [mwifiex]
> [] mwifiex_process_event+0x1a8/0x1e8 [mwifiex]
> [] mwifiex_main_process+0x258/0x534 [mwifiex]
> [] 0xffbffc258858
> [] process_sdio_pending_irqs+0xf8/0x160
> [] sdio_irq_thread+0x9c/0x1a4
> [] kthread+0xf4/0x100
> [] ret_from_fork+0xc/0x50
> [] 0x
> 
> Signed-off-by: Ricky Liang 
> ---
>  drivers/net/wireless/marvell/mwifiex/scan.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
> b/drivers/net/wireless/marvell/mwifiex/scan.c
> index 97c9765..98ce072 100644
> --- a/drivers/net/wireless/marvell/mwifiex/scan.c
> +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
> @@ -1671,6 +1671,10 @@ static int
> mwifiex_save_hidden_ssid_channels(struct mwifiex_private *priv,
>   }
> 
>  done:
> + /* beacon_ie buffer was allocated in function
> +  * mwifiex_fill_new_bss_desc(). Free it now.
> +  */
> + kfree(bss_desc->beacon_buf);
>   kfree(bss_desc);
>   return 0;
>  }

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

RE: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs

[Amitkumar Karwar]

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, November 09, 2016 7:58 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-kernel@vger.kernel.org; linux-wirel...@vger.kernel.org; Cathy
> Luo; secur...@kernel.org; sta...@vger.kernel.org; Brian Norris
> Subject: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs
> 
> SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
> when we print them out.
> 
> This can be easily noticed by connecting to a network with a 32-octet
> SSID:
> 
> [ 3903.502925] mwifiex_pcie :01:00.0: info: trying to associate to
> '0123456789abcdef0123456789abcdef ' bssid
> xx:xx:xx:xx:xx:xx
> 
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell
> mwifiex driver")
> Signed-off-by: Brian Norris <briannor...@chromium.org>
> Cc: <sta...@vger.kernel.org>
> ---
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index 39ce76ad00bc..16241d21727b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -,8 +,9 @@ mwifiex_cfg80211_assoc(struct mwifiex_private
> *priv, size_t ssid_len,
>   is_scanning_required = 1;
>   } else {
>   mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to associate to '%s' bssid
> %pM\n",
> - (char *)req_ssid.ssid, bss->bssid);
> + "info: trying to associate to '%.*s' bssid
> %pM\n",
> + req_ssid.ssid_len, (char *)req_ssid.ssid,
> + bss->bssid);
>   memcpy(>cfg_bssid, bss->bssid, ETH_ALEN);
>   break;
>   }
> @@ -2283,8 +2284,8 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy,
> struct net_device *dev,
>   }
> 
>   mwifiex_dbg(adapter, INFO,
> - "info: Trying to associate to %s and bssid %pM\n",
> - (char *)sme->ssid, sme->bssid);
> + "info: Trying to associate to %.*s and bssid %pM\n",
> + (int)sme->ssid_len, (char *)sme->ssid, sme->bssid);
> 
>   if (!mwifiex_stop_bg_scan(priv))
>   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
> @@ -2417,8 +2418,8 @@ mwifiex_cfg80211_join_ibss(struct wiphy *wiphy,
> struct net_device *dev,
>   }
> 
>   mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to join to %s and bssid %pM\n",
> - (char *)params->ssid, params->bssid);
> + "info: trying to join to %.*s and bssid %pM\n",
> + params->ssid_len, (char *)params->ssid, params->bssid);
> 
>   mwifiex_set_ibss_params(priv, params);
> 
> --
> 2.8.0.rc3.226.g39d4020

Thanks for fixing this.

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs

[Amitkumar Karwar]

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, November 09, 2016 7:58 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-kernel@vger.kernel.org; linux-wirel...@vger.kernel.org; Cathy
> Luo; secur...@kernel.org; sta...@vger.kernel.org; Brian Norris
> Subject: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs
> 
> SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
> when we print them out.
> 
> This can be easily noticed by connecting to a network with a 32-octet
> SSID:
> 
> [ 3903.502925] mwifiex_pcie :01:00.0: info: trying to associate to
> '0123456789abcdef0123456789abcdef ' bssid
> xx:xx:xx:xx:xx:xx
> 
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell
> mwifiex driver")
> Signed-off-by: Brian Norris 
> Cc: 
> ---
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index 39ce76ad00bc..16241d21727b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -,8 +,9 @@ mwifiex_cfg80211_assoc(struct mwifiex_private
> *priv, size_t ssid_len,
>   is_scanning_required = 1;
>   } else {
>   mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to associate to '%s' bssid
> %pM\n",
> - (char *)req_ssid.ssid, bss->bssid);
> + "info: trying to associate to '%.*s' bssid
> %pM\n",
> + req_ssid.ssid_len, (char *)req_ssid.ssid,
> + bss->bssid);
>   memcpy(>cfg_bssid, bss->bssid, ETH_ALEN);
>   break;
>   }
> @@ -2283,8 +2284,8 @@ mwifiex_cfg80211_connect(struct wiphy *wiphy,
> struct net_device *dev,
>   }
> 
>   mwifiex_dbg(adapter, INFO,
> - "info: Trying to associate to %s and bssid %pM\n",
> - (char *)sme->ssid, sme->bssid);
> + "info: Trying to associate to %.*s and bssid %pM\n",
> + (int)sme->ssid_len, (char *)sme->ssid, sme->bssid);
> 
>   if (!mwifiex_stop_bg_scan(priv))
>   cfg80211_sched_scan_stopped_rtnl(priv->wdev.wiphy);
> @@ -2417,8 +2418,8 @@ mwifiex_cfg80211_join_ibss(struct wiphy *wiphy,
> struct net_device *dev,
>   }
> 
>   mwifiex_dbg(priv->adapter, MSG,
> - "info: trying to join to %s and bssid %pM\n",
> - (char *)params->ssid, params->bssid);
> + "info: trying to join to %.*s and bssid %pM\n",
> + params->ssid_len, (char *)params->ssid, params->bssid);
> 
>   mwifiex_set_ibss_params(priv, params);
> 
> --
> 2.8.0.rc3.226.g39d4020

Thanks for fixing this.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

[PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

We came across a corner case issue during reboot stress test
in which hciconfig shows BD address is all zero. Reason is we
don't get response for HCI RESET command during initialization

The issue is tracked to a race where USB subsystem calls
btusb_intr_complete() to deliver a data(NOOP frame) received
on interrupt endpoint. HCI_RUNNING flag is not yet set by
bluetooth subsystem. So we ignore that frame and return.

As we missed to resubmit the buffer to interrupt endpoint in
this case, we don't get response for BT reset command downloaded
after this.

This patch handles the corner case to resolve zero BD address
problem.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/btusb.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 811f9b9..b5596ac 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -607,10 +607,7 @@ static void btusb_intr_complete(struct urb *urb)
BT_DBG("%s urb %p status %d count %d", hdev->name, urb, urb->status,
   urb->actual_length);
 
-   if (!test_bit(HCI_RUNNING, >flags))
-   return;
-
-   if (urb->status == 0) {
+   if (urb->status == 0 && test_bit(HCI_RUNNING, >flags)) {
hdev->stat.byte_rx += urb->actual_length;
 
if (btusb_recv_intr(data, urb->transfer_buffer,
-- 
1.9.1

[PATCH] btusb: fix zero BD address problem during stress test

[Amitkumar Karwar]

From: Ganapathi Bhat 

We came across a corner case issue during reboot stress test
in which hciconfig shows BD address is all zero. Reason is we
don't get response for HCI RESET command during initialization

The issue is tracked to a race where USB subsystem calls
btusb_intr_complete() to deliver a data(NOOP frame) received
on interrupt endpoint. HCI_RUNNING flag is not yet set by
bluetooth subsystem. So we ignore that frame and return.

As we missed to resubmit the buffer to interrupt endpoint in
this case, we don't get response for BT reset command downloaded
after this.

This patch handles the corner case to resolve zero BD address
problem.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/btusb.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 811f9b9..b5596ac 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -607,10 +607,7 @@ static void btusb_intr_complete(struct urb *urb)
BT_DBG("%s urb %p status %d count %d", hdev->name, urb, urb->status,
   urb->actual_length);
 
-   if (!test_bit(HCI_RUNNING, >flags))
-   return;
-
-   if (urb->status == 0) {
+   if (urb->status == 0 && test_bit(HCI_RUNNING, >flags)) {
hdev->stat.byte_rx += urb->actual_length;
 
if (btusb_recv_intr(data, urb->transfer_buffer,
-- 
1.9.1

RE: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()

[Amitkumar Karwar]

Hi Javier,

> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Tuesday, September 06, 2016 5:43 PM
> To: Kalle Valo
> Cc: linux-kernel@vger.kernel.org; Amitkumar Karwar;
> net...@vger.kernel.org; linux-wirel...@vger.kernel.org; Nishant
> Sarmukadam; Arend van Spriel
> Subject: Re: mwifiex: propagate error if IRQ request fails in
> mwifiex_sdio_of()
> 
> Hello Kalle,
> 
> On 09/03/2016 12:35 PM, Kalle Valo wrote:
> > Javier Martinez Canillas <jav...@osg.samsung.com> wrote:
> >> If request_irq() fails in mwifiex_sdio_probe_of(), only an error
> >> message is printed but the actual error is not propagated to the
> caller function.
> >>
> >> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> >
> > What's the conclusion with this patch? Should I drop it or take it?
> >
> > (The discussion is available from the patchwork link in the
> > signature.)
> >
> 
> My understanding is that Arend agrees with the patch and that the
> question raised was caused by looking at an older kernel version. IOW,
> the patch is OK and should be picked.
> 
> I'm adding Arend to cc, so can comment in case I misunderstood him
> though.
> 

This error doesn't affect actual wifi functionality. Only thing is wakeup on 
interrupt when system is in suspended state won't work.
I think, we can make below change. 

--
@@ -122,9 +122,11 @@ static int mwifiex_sdio_probe_of(struct device *dev, 
struct sdio_mmc_card *card)
   IRQF_TRIGGER_LOW,
   "wifi_wake", cfg);
   if (ret) {
-dev_err(dev,
+dev_dbg(dev,
 "Failed to request irq_wifi %d (%d)\n",
 cfg->irq_wifi, ret);
+card->plt_wake_cfg = NULL;
+return 0;
 }
disable_irq(cfg->irq_wifi);
}
-

Regards,
Amitkumar

RE: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()

[Amitkumar Karwar]

Hi Javier,

> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Tuesday, September 06, 2016 5:43 PM
> To: Kalle Valo
> Cc: linux-kernel@vger.kernel.org; Amitkumar Karwar;
> net...@vger.kernel.org; linux-wirel...@vger.kernel.org; Nishant
> Sarmukadam; Arend van Spriel
> Subject: Re: mwifiex: propagate error if IRQ request fails in
> mwifiex_sdio_of()
> 
> Hello Kalle,
> 
> On 09/03/2016 12:35 PM, Kalle Valo wrote:
> > Javier Martinez Canillas  wrote:
> >> If request_irq() fails in mwifiex_sdio_probe_of(), only an error
> >> message is printed but the actual error is not propagated to the
> caller function.
> >>
> >> Signed-off-by: Javier Martinez Canillas 
> >
> > What's the conclusion with this patch? Should I drop it or take it?
> >
> > (The discussion is available from the patchwork link in the
> > signature.)
> >
> 
> My understanding is that Arend agrees with the patch and that the
> question raised was caused by looking at an older kernel version. IOW,
> the patch is OK and should be picked.
> 
> I'm adding Arend to cc, so can comment in case I misunderstood him
> though.
> 

This error doesn't affect actual wifi functionality. Only thing is wakeup on 
interrupt when system is in suspended state won't work.
I think, we can make below change. 

--
@@ -122,9 +122,11 @@ static int mwifiex_sdio_probe_of(struct device *dev, 
struct sdio_mmc_card *card)
   IRQF_TRIGGER_LOW,
   "wifi_wake", cfg);
   if (ret) {
-dev_err(dev,
+dev_dbg(dev,
 "Failed to request irq_wifi %d (%d)\n",
 cfg->irq_wifi, ret);
+card->plt_wake_cfg = NULL;
+return 0;
 }
disable_irq(cfg->irq_wifi);
}
-

Regards,
Amitkumar

[PATCH v13 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

This patch implement firmware download feature for
Marvell Bluetooth devices. If firmware is already
downloaded, it will skip downloading.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
v2: Fixed compilation warning reported by kbuild test robot
v3: Addressed review comments from Marcel Holtmann
a) Removed vendor specific code from hci_ldisc.c
b) Get rid of static forward declaration
c) Removed unnecessary heavy nesting
d) Git rid of module parameter and global variables
e) Add logic to pick right firmware image
v4: Addresses review comments from Alan
a) Use existing kernel helper APIs instead of writing own.
b) Replace mdelay() with msleep()
v5: Addresses review comments from Loic Poulain
a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
b) Used static functions where required and removed forward delcarations
c) Edited comments for the function hci_uart_recv_data
d) Made HCI_UART_DNLD_FW flag a part of driver private data
v6: Addresses review comments from Loic Poulain
a) Used skb instead of array to store firmware data during download
b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
c) Used GFP_KERNEL instead of GFP_ATOMIC
v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change resolves
errors reported by kbuild test robot.
v8: Addressed review comments from Marcel Holtmann
a) Removed unnecessary memory allocation failure messages
b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c file
v9: Addressed review comments from Marcel Holtmann
a) Moved firmware download code from setup to prepare handler.
b) Change messages from bt_dev_*->BT_*, as hdev isn't available during 
firmware
 download.
v10: Addressed review comments from Marcel Holtmann
a) Added new callback recv_for_prepare to receive data from device
 during prepare phase
b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive callback is
 added for the same purpose
c) Used kernel API to handle unaligned data
d) Moved mrvl_set_baud functionality inside setup callback
v11: Write data through ldisc in mrvl_send_ack() instead of directly calling
write method(One Thousand Gnomes).
v12: a) Check for buffer length before copying to skb (Loic Poulain)
 b) Rearrange skb memory allocation check
v13: Addressed review comments from Loic Poulain
 a) Instead of hardcoding 115200, initialise init_speed as 115200
 b) Allocate required length instead of max size.
---
 drivers/bluetooth/Kconfig |  11 +
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/hci_ldisc.c |   6 +
 drivers/bluetooth/hci_mrvl.c  | 548 ++
 drivers/bluetooth/hci_uart.h  |   8 +-
 5 files changed, 573 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/hci_mrvl.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 43e9f93..3cc9bff 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
 
  Say Y here to compile support for Intel AG6XX protocol.
 
+config BT_HCIUART_MRVL
+   bool "Marvell protocol support"
+   depends on BT_HCIUART
+   select BT_HCIUART_H4
+   help
+ Marvell is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for most Marvell Bluetooth
+ devices with UART interface.
+
+ Say Y here to compile support for HCI MRVL protocol.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 3e92cfe..b1fc29a 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -38,6 +38,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
 hci_uart-$(CONFIG_BT_HCIUART_BCM)  += hci_bcm.o
 hci_uart-$(CONFIG_BT_HCIUART_QCA)  += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
+hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
 
 ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 2c88586..ded13d3 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -821,6 +821,9 @@ static int __init hci_uart_init(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_init();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_init();
+#endif
 
return 0;
 }
@@ -856,6 +859,9 @@ static void __exit hci_uart_exit(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_deinit();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_deinit();
+#endif
 
/* Release tty registration of line discipline */
err = tty_unregister_ldisc(N_HCI);
di

[PATCH v13 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

From: Ganapathi Bhat 

This patch implement firmware download feature for
Marvell Bluetooth devices. If firmware is already
downloaded, it will skip downloading.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
v2: Fixed compilation warning reported by kbuild test robot
v3: Addressed review comments from Marcel Holtmann
a) Removed vendor specific code from hci_ldisc.c
b) Get rid of static forward declaration
c) Removed unnecessary heavy nesting
d) Git rid of module parameter and global variables
e) Add logic to pick right firmware image
v4: Addresses review comments from Alan
a) Use existing kernel helper APIs instead of writing own.
b) Replace mdelay() with msleep()
v5: Addresses review comments from Loic Poulain
a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
b) Used static functions where required and removed forward delcarations
c) Edited comments for the function hci_uart_recv_data
d) Made HCI_UART_DNLD_FW flag a part of driver private data
v6: Addresses review comments from Loic Poulain
a) Used skb instead of array to store firmware data during download
b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
c) Used GFP_KERNEL instead of GFP_ATOMIC
v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change resolves
errors reported by kbuild test robot.
v8: Addressed review comments from Marcel Holtmann
a) Removed unnecessary memory allocation failure messages
b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c file
v9: Addressed review comments from Marcel Holtmann
a) Moved firmware download code from setup to prepare handler.
b) Change messages from bt_dev_*->BT_*, as hdev isn't available during 
firmware
 download.
v10: Addressed review comments from Marcel Holtmann
a) Added new callback recv_for_prepare to receive data from device
 during prepare phase
b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive callback is
 added for the same purpose
c) Used kernel API to handle unaligned data
d) Moved mrvl_set_baud functionality inside setup callback
v11: Write data through ldisc in mrvl_send_ack() instead of directly calling
write method(One Thousand Gnomes).
v12: a) Check for buffer length before copying to skb (Loic Poulain)
 b) Rearrange skb memory allocation check
v13: Addressed review comments from Loic Poulain
 a) Instead of hardcoding 115200, initialise init_speed as 115200
 b) Allocate required length instead of max size.
---
 drivers/bluetooth/Kconfig |  11 +
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/hci_ldisc.c |   6 +
 drivers/bluetooth/hci_mrvl.c  | 548 ++
 drivers/bluetooth/hci_uart.h  |   8 +-
 5 files changed, 573 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/hci_mrvl.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 43e9f93..3cc9bff 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
 
  Say Y here to compile support for Intel AG6XX protocol.
 
+config BT_HCIUART_MRVL
+   bool "Marvell protocol support"
+   depends on BT_HCIUART
+   select BT_HCIUART_H4
+   help
+ Marvell is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for most Marvell Bluetooth
+ devices with UART interface.
+
+ Say Y here to compile support for HCI MRVL protocol.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 3e92cfe..b1fc29a 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -38,6 +38,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
 hci_uart-$(CONFIG_BT_HCIUART_BCM)  += hci_bcm.o
 hci_uart-$(CONFIG_BT_HCIUART_QCA)  += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
+hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
 
 ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 2c88586..ded13d3 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -821,6 +821,9 @@ static int __init hci_uart_init(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_init();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_init();
+#endif
 
return 0;
 }
@@ -856,6 +859,9 @@ static void __exit hci_uart_exit(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_deinit();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_deinit();
+#endif
 
/* Release tty registration of line discipline */
err = tty_unregister_ldisc(N_HCI);
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
new file mo

[PATCH v13 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

The new callback is used to prepare the device before HCI becomes
ready. One can use this to download firmware if the download process
doesn't use HCI commands. Also recv_for_prepare callback is
introduced for receiving data from devices during prepare phase.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/hci_ldisc.c | 11 ++-
 drivers/bluetooth/hci_uart.h  |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index dda9739..d7184dc 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -551,8 +551,11 @@ static void hci_uart_tty_receive(struct tty_struct *tty, 
const u8 *data,
if (!hu || tty != hu->tty)
return;
 
-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }
 
/* It does not need a lock here as it is already protected by a mutex in
 * tty caller
@@ -639,6 +642,12 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
 
hu->proto = p;
+   if (p->prepare) {
+   err = p->prepare(hu);
+   if (err)
+   return err;
+   }
+
set_bit(HCI_UART_PROTO_READY, >flags);
 
err = hci_uart_register_dev(hu);
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 839bad1..17ba3b4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -67,8 +67,11 @@ struct hci_uart_proto {
int (*close)(struct hci_uart *hu);
int (*flush)(struct hci_uart *hu);
int (*setup)(struct hci_uart *hu);
+   int (*prepare)(struct hci_uart *hu);
int (*set_baudrate)(struct hci_uart *hu, unsigned int speed);
int (*recv)(struct hci_uart *hu, const void *data, int len);
+   int (*recv_for_prepare)(struct hci_uart *hu, const void *data,
+   int len);
int (*enqueue)(struct hci_uart *hu, struct sk_buff *skb);
struct sk_buff *(*dequeue)(struct hci_uart *hu);
 };
-- 
1.8.1.4

[PATCH v13 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

From: Ganapathi Bhat 

The new callback is used to prepare the device before HCI becomes
ready. One can use this to download firmware if the download process
doesn't use HCI commands. Also recv_for_prepare callback is
introduced for receiving data from devices during prepare phase.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/hci_ldisc.c | 11 ++-
 drivers/bluetooth/hci_uart.h  |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index dda9739..d7184dc 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -551,8 +551,11 @@ static void hci_uart_tty_receive(struct tty_struct *tty, 
const u8 *data,
if (!hu || tty != hu->tty)
return;
 
-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }
 
/* It does not need a lock here as it is already protected by a mutex in
 * tty caller
@@ -639,6 +642,12 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
 
hu->proto = p;
+   if (p->prepare) {
+   err = p->prepare(hu);
+   if (err)
+   return err;
+   }
+
set_bit(HCI_UART_PROTO_READY, >flags);
 
err = hci_uart_register_dev(hu);
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 839bad1..17ba3b4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -67,8 +67,11 @@ struct hci_uart_proto {
int (*close)(struct hci_uart *hu);
int (*flush)(struct hci_uart *hu);
int (*setup)(struct hci_uart *hu);
+   int (*prepare)(struct hci_uart *hu);
int (*set_baudrate)(struct hci_uart *hu, unsigned int speed);
int (*recv)(struct hci_uart *hu, const void *data, int len);
+   int (*recv_for_prepare)(struct hci_uart *hu, const void *data,
+   int len);
int (*enqueue)(struct hci_uart *hu, struct sk_buff *skb);
struct sk_buff *(*dequeue)(struct hci_uart *hu);
 };
-- 
1.8.1.4

[PATCH v13 2/3] Bluetooth: hci_uart: check if hdev is present before using it

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

The hdev struct might not have initialized in protocol receive handler.
This patch adds necessary checks.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/hci_ldisc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index d7184dc..2c88586 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -154,7 +154,9 @@ restart:
 
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
len = tty->ops->write(tty, skb->data, skb->len);
-   hdev->stat.byte_tx += len;
+
+   if (hdev)
+   hdev->stat.byte_tx += len;
 
skb_pull(skb, len);
if (skb->len) {
@@ -349,7 +351,7 @@ void hci_uart_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, );
 
-   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
+   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev ? hu->hdev->name : "",
   tty->termios.c_ispeed, tty->termios.c_ospeed);
 }
 
-- 
1.8.1.4

[PATCH v13 2/3] Bluetooth: hci_uart: check if hdev is present before using it

[Amitkumar Karwar]

From: Ganapathi Bhat 

The hdev struct might not have initialized in protocol receive handler.
This patch adds necessary checks.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/hci_ldisc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index d7184dc..2c88586 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -154,7 +154,9 @@ restart:
 
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
len = tty->ops->write(tty, skb->data, skb->len);
-   hdev->stat.byte_tx += len;
+
+   if (hdev)
+   hdev->stat.byte_tx += len;
 
skb_pull(skb, len);
if (skb->len) {
@@ -349,7 +351,7 @@ void hci_uart_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, );
 
-   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
+   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev ? hu->hdev->name : "",
   tty->termios.c_ispeed, tty->termios.c_ospeed);
 }
 
-- 
1.8.1.4

RE: [PATCH v12 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Loic,

Thanks for your comments.

> -Original Message-
> From: Loic Poulain [mailto:loic.poul...@intel.com]
> Sent: Tuesday, August 16, 2016 1:20 PM
> To: Amitkumar Karwar; linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-rockc...@lists.infradead.org;
> mar...@holtmann.org; Ganapathi Bhat
> Subject: Re: [PATCH v12 3/3] Bluetooth: hci_uart: Support firmware
> download for Marvell
> 
> Hi Amit,
> 
> On 09/08/2016 18:32, Amitkumar Karwar wrote:
> > From: Ganapathi Bhat <gb...@marvell.com>
> >
> > This patch implement firmware download feature for Marvell Bluetooth
> > devices. If firmware is already downloaded, it will skip downloading.
> >
> > Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> > Tested-by: Jeffy Chen <jeffy.c...@rock-chips.com>
> > ---
> > v2: Fixed compilation warning reported by kbuild test robot
> > v3: Addressed review comments from Marcel Holtmann
> >  a) Removed vendor specific code from hci_ldisc.c
> >  b) Get rid of static forward declaration
> >  c) Removed unnecessary heavy nesting
> >  d) Git rid of module parameter and global variables
> >  e) Add logic to pick right firmware image
> > v4: Addresses review comments from Alan
> >  a) Use existing kernel helper APIs instead of writing own.
> >  b) Replace mdelay() with msleep()
> > v5: Addresses review comments from Loic Poulain
> >  a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> >  b) Used static functions where required and removed forward
> delcarations
> >  c) Edited comments for the function hci_uart_recv_data
> >  d) Made HCI_UART_DNLD_FW flag a part of driver private data
> > v6: Addresses review comments from Loic Poulain
> >  a) Used skb instead of array to store firmware data during
> download
> >  b) Used hci_uart_tx_wakeup and enqueued packets instead of tty
> write
> >  c) Used GFP_KERNEL instead of GFP_ATOMIC
> > v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> resolves
> >  errors reported by kbuild test robot.
> > v8: Addressed review comments from Marcel Holtmann
> >  a) Removed unnecessary memory allocation failure messages
> >  b) Get rid of btmrvl.h header file and add definitions in
> > hci_mrvl.c file
> > v9: Addressed review comments from Marcel Holtmann
> >  a) Moved firmware download code from setup to prepare handler.
> >  b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> during firmware
> >   download.
> > v10: Addressed review comments from Marcel Holtmann
> >  a) Added new callback recv_for_prepare to receive data from
> device
> >   during prepare phase
> >  b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> callback is
> >   added for the same purpose
> >  c) Used kernel API to handle unaligned data
> >  d) Moved mrvl_set_baud functionality inside setup callback
> > v11: Write data through ldisc in mrvl_send_ack() instead of directly
> calling
> >  write method(One Thousand Gnomes).
> > v12: a) Check for buffer length before copying to skb (Loic Poulain)
> >   b) Rearrange skb memory allocation check
> > ---
> >   drivers/bluetooth/Kconfig |  11 +
> >   drivers/bluetooth/Makefile|   1 +
> >   drivers/bluetooth/hci_ldisc.c |   6 +
> >   drivers/bluetooth/hci_mrvl.c  | 545
> ++
> >   drivers/bluetooth/hci_uart.h  |   8 +-
> >   5 files changed, 570 insertions(+), 1 deletion(-)
> >   create mode 100644 drivers/bluetooth/hci_mrvl.c
> >
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index cf50fd2..daafd0c 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
> >
> >   Say Y here to compile support for Intel AG6XX protocol.
> >
> > +config BT_HCIUART_MRVL
> > +   bool "Marvell protocol support"
> > +   depends on BT_HCIUART
> > +   select BT_HCIUART_H4
> > +   help
> > + Marvell is serial protocol for communication between Bluetooth
> > + device and host. This protocol is required for most Marvell
> Bluetooth
> > + devices with UART interface.
> > +
> > + Say Y here to compile support for HCI MRVL protocol.
> > +
> >   config BT_HCIBCM203X
> > tristate "HCI BCM203x USB driver"
>

RE: [PATCH v12 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Loic,

Thanks for your comments.

> -Original Message-
> From: Loic Poulain [mailto:loic.poul...@intel.com]
> Sent: Tuesday, August 16, 2016 1:20 PM
> To: Amitkumar Karwar; linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-rockc...@lists.infradead.org;
> mar...@holtmann.org; Ganapathi Bhat
> Subject: Re: [PATCH v12 3/3] Bluetooth: hci_uart: Support firmware
> download for Marvell
> 
> Hi Amit,
> 
> On 09/08/2016 18:32, Amitkumar Karwar wrote:
> > From: Ganapathi Bhat 
> >
> > This patch implement firmware download feature for Marvell Bluetooth
> > devices. If firmware is already downloaded, it will skip downloading.
> >
> > Signed-off-by: Ganapathi Bhat 
> > Signed-off-by: Amitkumar Karwar 
> > Tested-by: Jeffy Chen 
> > ---
> > v2: Fixed compilation warning reported by kbuild test robot
> > v3: Addressed review comments from Marcel Holtmann
> >  a) Removed vendor specific code from hci_ldisc.c
> >  b) Get rid of static forward declaration
> >  c) Removed unnecessary heavy nesting
> >  d) Git rid of module parameter and global variables
> >  e) Add logic to pick right firmware image
> > v4: Addresses review comments from Alan
> >  a) Use existing kernel helper APIs instead of writing own.
> >  b) Replace mdelay() with msleep()
> > v5: Addresses review comments from Loic Poulain
> >  a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> >  b) Used static functions where required and removed forward
> delcarations
> >  c) Edited comments for the function hci_uart_recv_data
> >  d) Made HCI_UART_DNLD_FW flag a part of driver private data
> > v6: Addresses review comments from Loic Poulain
> >  a) Used skb instead of array to store firmware data during
> download
> >  b) Used hci_uart_tx_wakeup and enqueued packets instead of tty
> write
> >  c) Used GFP_KERNEL instead of GFP_ATOMIC
> > v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> resolves
> >  errors reported by kbuild test robot.
> > v8: Addressed review comments from Marcel Holtmann
> >  a) Removed unnecessary memory allocation failure messages
> >  b) Get rid of btmrvl.h header file and add definitions in
> > hci_mrvl.c file
> > v9: Addressed review comments from Marcel Holtmann
> >  a) Moved firmware download code from setup to prepare handler.
> >  b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> during firmware
> >   download.
> > v10: Addressed review comments from Marcel Holtmann
> >  a) Added new callback recv_for_prepare to receive data from
> device
> >   during prepare phase
> >  b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> callback is
> >   added for the same purpose
> >  c) Used kernel API to handle unaligned data
> >  d) Moved mrvl_set_baud functionality inside setup callback
> > v11: Write data through ldisc in mrvl_send_ack() instead of directly
> calling
> >  write method(One Thousand Gnomes).
> > v12: a) Check for buffer length before copying to skb (Loic Poulain)
> >   b) Rearrange skb memory allocation check
> > ---
> >   drivers/bluetooth/Kconfig |  11 +
> >   drivers/bluetooth/Makefile|   1 +
> >   drivers/bluetooth/hci_ldisc.c |   6 +
> >   drivers/bluetooth/hci_mrvl.c  | 545
> ++
> >   drivers/bluetooth/hci_uart.h  |   8 +-
> >   5 files changed, 570 insertions(+), 1 deletion(-)
> >   create mode 100644 drivers/bluetooth/hci_mrvl.c
> >
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index cf50fd2..daafd0c 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
> >
> >   Say Y here to compile support for Intel AG6XX protocol.
> >
> > +config BT_HCIUART_MRVL
> > +   bool "Marvell protocol support"
> > +   depends on BT_HCIUART
> > +   select BT_HCIUART_H4
> > +   help
> > + Marvell is serial protocol for communication between Bluetooth
> > + device and host. This protocol is required for most Marvell
> Bluetooth
> > + devices with UART interface.
> > +
> > + Say Y here to compile support for HCI MRVL protocol.
> > +
> >   config BT_HCIBCM203X
> > tristate "HCI BCM203x USB driver"
> > depends on USB
> > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> > in

RE: mwifiex: PCIe8997 chip specific handling

[Amitkumar Karwar]

Hi Kalle,

> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
> ow...@vger.kernel.org] On Behalf Of Amitkumar Karwar
> Sent: Thursday, August 11, 2016 4:11 PM
> To: Steve deRosier
> Cc: Brian Norris; linux-wirel...@vger.kernel.org; Cathy Luo; Nishant
> Sarmukadam; linux-kernel@vger.kernel.org; Wei-Ning Huang
> Subject: RE: mwifiex: PCIe8997 chip specific handling
> 
> Hi Steve,
> 
> > From: Steve deRosier [mailto:deros...@gmail.com]
> > Sent: Thursday, August 11, 2016 2:39 AM
> > To: Amitkumar Karwar
> > Cc: Brian Norris; linux-wirel...@vger.kernel.org; Cathy Luo; Nishant
> > Sarmukadam; linux-kernel@vger.kernel.org; Wei-Ning Huang
> > Subject: Re: mwifiex: PCIe8997 chip specific handling
> >
> > Hi,
> >
> > On Wed, Aug 10, 2016 at 12:07 AM, Amitkumar Karwar
> > <akar...@marvell.com>
> > wrote:
> > > Hi Brian,
> > >
> > >> From: Brian Norris [mailto:briannor...@chromium.org]
> > >> Sent: Wednesday, August 10, 2016 12:14 AM
> > >> To: Amitkumar Karwar
> > >> Cc: linux-wirel...@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> > >> linux-kernel@vger.kernel.org
> > >> Subject: Re: mwifiex: PCIe8997 chip specific handling
> > >>
> > >> Hi,
> > >>
> > >> On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> > >> > The patch corrects the revision id register and uses it along
> > >> > with magic value and chip version registers to download
> > >> > appropriate firmware image.
> > >> >
> > >> > PCIe8997 Z chipset variant code has been removed, as it won't be
> > >> > used in production.
> > >> >
> > >> > Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> > >> > ---
> > >> >  drivers/net/wireless/marvell/mwifiex/pcie.c | 35
> > >> > ++---
> > >> > drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +---
> > >> >  2 files changed, 18 insertions(+), 31 deletions(-)
> > >>
> > >> [...]
> > >>
> > >> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > >> > b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > >> > index f6992f0..46f99ca 100644
> > >> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > >> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > >> > @@ -32,12 +32,9 @@
> > >> >  #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> > >> >  #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> > >> >  #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> > >> > -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> > >> > -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> > >> > -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> > >> > -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> > >> > -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> > >> > -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> > >> > +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> > >> > +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> > >> > +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
> > >>
> > >> Why do version bumps require firmware renames? Is this just to make
> > >> sure you don't load the new firmware on old chip revs that you
> > >> don't plan to support for production (i.e., only early revs like
> > >> the _Z you're dropping)? This doesn't seems like a good long-term
> > >> solution, at least once you start getting this silicon out in the
> > >> wild. At some point, I'd expect to see a stable file name.
> > >>
> > >> Brian
> > >>
> > >
> > > We haven't yet submitted any firmware image upstream for 8997
> chipset.
> > > pcieuart8997_combo_v4.bin/pcieusb8997_combo_v4.bin would be our
> > firmware candidate for upstream submission. The filename would remain
> > same hereafter.
> > >
> > > pcie*8997_combo_v2.bin had support only for A0 chipset
> > > pcie*8997_combo_v3.bin was our internal development version which
> > > had support for A1

RE: mwifiex: PCIe8997 chip specific handling

[Amitkumar Karwar]

Hi Kalle,

> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
> ow...@vger.kernel.org] On Behalf Of Amitkumar Karwar
> Sent: Thursday, August 11, 2016 4:11 PM
> To: Steve deRosier
> Cc: Brian Norris; linux-wirel...@vger.kernel.org; Cathy Luo; Nishant
> Sarmukadam; linux-kernel@vger.kernel.org; Wei-Ning Huang
> Subject: RE: mwifiex: PCIe8997 chip specific handling
> 
> Hi Steve,
> 
> > From: Steve deRosier [mailto:deros...@gmail.com]
> > Sent: Thursday, August 11, 2016 2:39 AM
> > To: Amitkumar Karwar
> > Cc: Brian Norris; linux-wirel...@vger.kernel.org; Cathy Luo; Nishant
> > Sarmukadam; linux-kernel@vger.kernel.org; Wei-Ning Huang
> > Subject: Re: mwifiex: PCIe8997 chip specific handling
> >
> > Hi,
> >
> > On Wed, Aug 10, 2016 at 12:07 AM, Amitkumar Karwar
> > 
> > wrote:
> > > Hi Brian,
> > >
> > >> From: Brian Norris [mailto:briannor...@chromium.org]
> > >> Sent: Wednesday, August 10, 2016 12:14 AM
> > >> To: Amitkumar Karwar
> > >> Cc: linux-wirel...@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> > >> linux-kernel@vger.kernel.org
> > >> Subject: Re: mwifiex: PCIe8997 chip specific handling
> > >>
> > >> Hi,
> > >>
> > >> On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> > >> > The patch corrects the revision id register and uses it along
> > >> > with magic value and chip version registers to download
> > >> > appropriate firmware image.
> > >> >
> > >> > PCIe8997 Z chipset variant code has been removed, as it won't be
> > >> > used in production.
> > >> >
> > >> > Signed-off-by: Amitkumar Karwar 
> > >> > ---
> > >> >  drivers/net/wireless/marvell/mwifiex/pcie.c | 35
> > >> > ++---
> > >> > drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +---
> > >> >  2 files changed, 18 insertions(+), 31 deletions(-)
> > >>
> > >> [...]
> > >>
> > >> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > >> > b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > >> > index f6992f0..46f99ca 100644
> > >> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > >> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > >> > @@ -32,12 +32,9 @@
> > >> >  #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> > >> >  #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> > >> >  #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> > >> > -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> > >> > -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> > >> > -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> > >> > -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> > >> > -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> > >> > -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> > >> > +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> > >> > +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> > >> > +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
> > >>
> > >> Why do version bumps require firmware renames? Is this just to make
> > >> sure you don't load the new firmware on old chip revs that you
> > >> don't plan to support for production (i.e., only early revs like
> > >> the _Z you're dropping)? This doesn't seems like a good long-term
> > >> solution, at least once you start getting this silicon out in the
> > >> wild. At some point, I'd expect to see a stable file name.
> > >>
> > >> Brian
> > >>
> > >
> > > We haven't yet submitted any firmware image upstream for 8997
> chipset.
> > > pcieuart8997_combo_v4.bin/pcieusb8997_combo_v4.bin would be our
> > firmware candidate for upstream submission. The filename would remain
> > same hereafter.
> > >
> > > pcie*8997_combo_v2.bin had support only for A0 chipset
> > > pcie*8997_combo_v3.bin was our internal development version which
> > > had support for A1 chipset pcie*8997_combo_v4.bin has support for
> &

RE: mwifiex: PCIe8997 chip specific handling

[Amitkumar Karwar]

Hi Steve,

> From: Steve deRosier [mailto:deros...@gmail.com]
> Sent: Thursday, August 11, 2016 2:39 AM
> To: Amitkumar Karwar
> Cc: Brian Norris; linux-wirel...@vger.kernel.org; Cathy Luo; Nishant
> Sarmukadam; linux-kernel@vger.kernel.org; Wei-Ning Huang
> Subject: Re: mwifiex: PCIe8997 chip specific handling
> 
> Hi,
> 
> On Wed, Aug 10, 2016 at 12:07 AM, Amitkumar Karwar <akar...@marvell.com>
> wrote:
> > Hi Brian,
> >
> >> From: Brian Norris [mailto:briannor...@chromium.org]
> >> Sent: Wednesday, August 10, 2016 12:14 AM
> >> To: Amitkumar Karwar
> >> Cc: linux-wirel...@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> >> linux-kernel@vger.kernel.org
> >> Subject: Re: mwifiex: PCIe8997 chip specific handling
> >>
> >> Hi,
> >>
> >> On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> >> > The patch corrects the revision id register and uses it along with
> >> > magic value and chip version registers to download appropriate
> >> > firmware image.
> >> >
> >> > PCIe8997 Z chipset variant code has been removed, as it won't be
> >> > used in production.
> >> >
> >> > Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> >> > ---
> >> >  drivers/net/wireless/marvell/mwifiex/pcie.c | 35
> >> > ++---
> >> > drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +---
> >> >  2 files changed, 18 insertions(+), 31 deletions(-)
> >>
> >> [...]
> >>
> >> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h
> >> > b/drivers/net/wireless/marvell/mwifiex/pcie.h
> >> > index f6992f0..46f99ca 100644
> >> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> >> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> >> > @@ -32,12 +32,9 @@
> >> >  #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> >> >  #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> >> >  #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> >> > -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> >> > -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> >> > -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> >> > -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> >> > -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> >> > -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> >> > +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> >> > +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> >> > +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
> >>
> >> Why do version bumps require firmware renames? Is this just to make
> >> sure you don't load the new firmware on old chip revs that you don't
> >> plan to support for production (i.e., only early revs like the _Z
> >> you're dropping)? This doesn't seems like a good long-term solution,
> >> at least once you start getting this silicon out in the wild. At some
> >> point, I'd expect to see a stable file name.
> >>
> >> Brian
> >>
> >
> > We haven't yet submitted any firmware image upstream for 8997 chipset.
> > pcieuart8997_combo_v4.bin/pcieusb8997_combo_v4.bin would be our
> firmware candidate for upstream submission. The filename would remain
> same hereafter.
> >
> > pcie*8997_combo_v2.bin had support only for A0 chipset
> > pcie*8997_combo_v3.bin was our internal development version which had
> > support for A1 chipset pcie*8997_combo_v4.bin has support for both A0
> and A1 chipsets and this is the version that shall be released to
> customers/upstream from now on.
> >
> 
> Seems to me then it should just be named pcie*8997_wlan.bin.  A version
> number shouldn't be part of the file name in this case. Having to update
> the driver for a firmware name change is silly. Most wireless drivers
> have different names for different hardware/chip revs and/or an
> incompatible API change.  Most distributions would typically only carry
> a single instance of the firmware for a particular chip.
> Speaking for the ones I work with, I usually keep the original filename
> intact (with a version number) and make a symlink to it with the name
> the driver expects.  eg:
> 
> fw-4.bin 

RE: mwifiex: PCIe8997 chip specific handling

[Amitkumar Karwar]

Hi Steve,

> From: Steve deRosier [mailto:deros...@gmail.com]
> Sent: Thursday, August 11, 2016 2:39 AM
> To: Amitkumar Karwar
> Cc: Brian Norris; linux-wirel...@vger.kernel.org; Cathy Luo; Nishant
> Sarmukadam; linux-kernel@vger.kernel.org; Wei-Ning Huang
> Subject: Re: mwifiex: PCIe8997 chip specific handling
> 
> Hi,
> 
> On Wed, Aug 10, 2016 at 12:07 AM, Amitkumar Karwar 
> wrote:
> > Hi Brian,
> >
> >> From: Brian Norris [mailto:briannor...@chromium.org]
> >> Sent: Wednesday, August 10, 2016 12:14 AM
> >> To: Amitkumar Karwar
> >> Cc: linux-wirel...@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> >> linux-kernel@vger.kernel.org
> >> Subject: Re: mwifiex: PCIe8997 chip specific handling
> >>
> >> Hi,
> >>
> >> On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> >> > The patch corrects the revision id register and uses it along with
> >> > magic value and chip version registers to download appropriate
> >> > firmware image.
> >> >
> >> > PCIe8997 Z chipset variant code has been removed, as it won't be
> >> > used in production.
> >> >
> >> > Signed-off-by: Amitkumar Karwar 
> >> > ---
> >> >  drivers/net/wireless/marvell/mwifiex/pcie.c | 35
> >> > ++---
> >> > drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +---
> >> >  2 files changed, 18 insertions(+), 31 deletions(-)
> >>
> >> [...]
> >>
> >> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h
> >> > b/drivers/net/wireless/marvell/mwifiex/pcie.h
> >> > index f6992f0..46f99ca 100644
> >> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> >> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> >> > @@ -32,12 +32,9 @@
> >> >  #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> >> >  #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> >> >  #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> >> > -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> >> > -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> >> > -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> >> > -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> >> > -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> >> > -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> >> > +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> >> > +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> >> > +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
> >>
> >> Why do version bumps require firmware renames? Is this just to make
> >> sure you don't load the new firmware on old chip revs that you don't
> >> plan to support for production (i.e., only early revs like the _Z
> >> you're dropping)? This doesn't seems like a good long-term solution,
> >> at least once you start getting this silicon out in the wild. At some
> >> point, I'd expect to see a stable file name.
> >>
> >> Brian
> >>
> >
> > We haven't yet submitted any firmware image upstream for 8997 chipset.
> > pcieuart8997_combo_v4.bin/pcieusb8997_combo_v4.bin would be our
> firmware candidate for upstream submission. The filename would remain
> same hereafter.
> >
> > pcie*8997_combo_v2.bin had support only for A0 chipset
> > pcie*8997_combo_v3.bin was our internal development version which had
> > support for A1 chipset pcie*8997_combo_v4.bin has support for both A0
> and A1 chipsets and this is the version that shall be released to
> customers/upstream from now on.
> >
> 
> Seems to me then it should just be named pcie*8997_wlan.bin.  A version
> number shouldn't be part of the file name in this case. Having to update
> the driver for a firmware name change is silly. Most wireless drivers
> have different names for different hardware/chip revs and/or an
> incompatible API change.  Most distributions would typically only carry
> a single instance of the firmware for a particular chip.
> Speaking for the ones I work with, I usually keep the original filename
> intact (with a version number) and make a symlink to it with the name
> the driver expects.  eg:
> 
> fw-4.bin -> fw_v3.4.0.94.bin
> fw_v3.2.0.144.bi

RE: mwifiex: PCIe8997 chip specific handling

[Amitkumar Karwar]

Hi Brian,

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, August 10, 2016 12:14 AM
> To: Amitkumar Karwar
> Cc: linux-wirel...@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> linux-kernel@vger.kernel.org
> Subject: Re: mwifiex: PCIe8997 chip specific handling
> 
> Hi,
> 
> On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> > The patch corrects the revision id register and uses it along with
> > magic value and chip version registers to download appropriate
> > firmware image.
> >
> > PCIe8997 Z chipset variant code has been removed, as it won't be used
> > in production.
> >
> > Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> > ---
> >  drivers/net/wireless/marvell/mwifiex/pcie.c | 35
> > ++---
> > drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +---
> >  2 files changed, 18 insertions(+), 31 deletions(-)
> 
> [...]
> 
> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > index f6992f0..46f99ca 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > @@ -32,12 +32,9 @@
> >  #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> >  #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> >  #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> > -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> > -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> > -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> > -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> > -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> > -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> > +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> > +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> > +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
> 
> Why do version bumps require firmware renames? Is this just to make sure
> you don't load the new firmware on old chip revs that you don't plan to
> support for production (i.e., only early revs like the _Z you're
> dropping)? This doesn't seems like a good long-term solution, at least
> once you start getting this silicon out in the wild. At some point, I'd
> expect to see a stable file name.
> 
> Brian
> 

We haven't yet submitted any firmware image upstream for 8997 chipset.
pcieuart8997_combo_v4.bin/pcieusb8997_combo_v4.bin would be our firmware 
candidate for upstream submission. The filename would remain same hereafter.

pcie*8997_combo_v2.bin had support only for A0 chipset
pcie*8997_combo_v3.bin was our internal development version which had support 
for A1 chipset
pcie*8997_combo_v4.bin has support for both A0 and A1 chipsets and this is the 
version that shall be released to customers/upstream from now on.

Regards,
Amitkumar Karwar

RE: mwifiex: PCIe8997 chip specific handling

[Amitkumar Karwar]

Hi Brian,

> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Wednesday, August 10, 2016 12:14 AM
> To: Amitkumar Karwar
> Cc: linux-wirel...@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> linux-kernel@vger.kernel.org
> Subject: Re: mwifiex: PCIe8997 chip specific handling
> 
> Hi,
> 
> On Fri, Jul 29, 2016 at 04:08:51PM +0530, Amitkumar Karwar wrote:
> > The patch corrects the revision id register and uses it along with
> > magic value and chip version registers to download appropriate
> > firmware image.
> >
> > PCIe8997 Z chipset variant code has been removed, as it won't be used
> > in production.
> >
> > Signed-off-by: Amitkumar Karwar 
> > ---
> >  drivers/net/wireless/marvell/mwifiex/pcie.c | 35
> > ++---
> > drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +---
> >  2 files changed, 18 insertions(+), 31 deletions(-)
> 
> [...]
> 
> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > index f6992f0..46f99ca 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.h
> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
> > @@ -32,12 +32,9 @@
> >  #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
> >  #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
> >  #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
> > -#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
> > -#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
> > -#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
> > -#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
> > -#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
> > -#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
> > +#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
> > +#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
> > +#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
> 
> Why do version bumps require firmware renames? Is this just to make sure
> you don't load the new firmware on old chip revs that you don't plan to
> support for production (i.e., only early revs like the _Z you're
> dropping)? This doesn't seems like a good long-term solution, at least
> once you start getting this silicon out in the wild. At some point, I'd
> expect to see a stable file name.
> 
> Brian
> 

We haven't yet submitted any firmware image upstream for 8997 chipset.
pcieuart8997_combo_v4.bin/pcieusb8997_combo_v4.bin would be our firmware 
candidate for upstream submission. The filename would remain same hereafter.

pcie*8997_combo_v2.bin had support only for A0 chipset
pcie*8997_combo_v3.bin was our internal development version which had support 
for A1 chipset
pcie*8997_combo_v4.bin has support for both A0 and A1 chipsets and this is the 
version that shall be released to customers/upstream from now on.

Regards,
Amitkumar Karwar

[PATCH v12 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

This patch implement firmware download feature for
Marvell Bluetooth devices. If firmware is already
downloaded, it will skip downloading.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
Tested-by: Jeffy Chen <jeffy.c...@rock-chips.com>
---
v2: Fixed compilation warning reported by kbuild test robot
v3: Addressed review comments from Marcel Holtmann
a) Removed vendor specific code from hci_ldisc.c
b) Get rid of static forward declaration
c) Removed unnecessary heavy nesting
d) Git rid of module parameter and global variables
e) Add logic to pick right firmware image
v4: Addresses review comments from Alan
a) Use existing kernel helper APIs instead of writing own.
b) Replace mdelay() with msleep()
v5: Addresses review comments from Loic Poulain
a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
b) Used static functions where required and removed forward delcarations
c) Edited comments for the function hci_uart_recv_data
d) Made HCI_UART_DNLD_FW flag a part of driver private data
v6: Addresses review comments from Loic Poulain
a) Used skb instead of array to store firmware data during download
b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
c) Used GFP_KERNEL instead of GFP_ATOMIC
v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change resolves
errors reported by kbuild test robot.
v8: Addressed review comments from Marcel Holtmann
a) Removed unnecessary memory allocation failure messages
b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c file
v9: Addressed review comments from Marcel Holtmann
a) Moved firmware download code from setup to prepare handler.
b) Change messages from bt_dev_*->BT_*, as hdev isn't available during 
firmware
 download.
v10: Addressed review comments from Marcel Holtmann
a) Added new callback recv_for_prepare to receive data from device
 during prepare phase
b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive callback is
 added for the same purpose
c) Used kernel API to handle unaligned data
d) Moved mrvl_set_baud functionality inside setup callback
v11: Write data through ldisc in mrvl_send_ack() instead of directly calling
write method(One Thousand Gnomes).
v12: a) Check for buffer length before copying to skb (Loic Poulain)
 b) Rearrange skb memory allocation check
---
 drivers/bluetooth/Kconfig |  11 +
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/hci_ldisc.c |   6 +
 drivers/bluetooth/hci_mrvl.c  | 545 ++
 drivers/bluetooth/hci_uart.h  |   8 +-
 5 files changed, 570 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/hci_mrvl.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index cf50fd2..daafd0c 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
 
  Say Y here to compile support for Intel AG6XX protocol.
 
+config BT_HCIUART_MRVL
+   bool "Marvell protocol support"
+   depends on BT_HCIUART
+   select BT_HCIUART_H4
+   help
+ Marvell is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for most Marvell Bluetooth
+ devices with UART interface.
+
+ Say Y here to compile support for HCI MRVL protocol.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9c18939..364dbb6 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -37,6 +37,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
 hci_uart-$(CONFIG_BT_HCIUART_BCM)  += hci_bcm.o
 hci_uart-$(CONFIG_BT_HCIUART_QCA)  += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
+hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
 
 ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 2c88586..ded13d3 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -821,6 +821,9 @@ static int __init hci_uart_init(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_init();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_init();
+#endif
 
return 0;
 }
@@ -856,6 +859,9 @@ static void __exit hci_uart_exit(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_deinit();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_deinit();
+#endif
 
/* Release tty registration of line discipline */
err = tty_unregister_ldisc(N_HCI);
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
new file mode 100644
index 000..c993c1b
-

[PATCH v12 2/3] Bluetooth: hci_uart: check if hdev is present before using it

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

The hdev struct might not have initialized in protocol receive handler.
This patch adds necessary checks.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/hci_ldisc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index d7184dc..2c88586 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -154,7 +154,9 @@ restart:
 
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
len = tty->ops->write(tty, skb->data, skb->len);
-   hdev->stat.byte_tx += len;
+
+   if (hdev)
+   hdev->stat.byte_tx += len;
 
skb_pull(skb, len);
if (skb->len) {
@@ -349,7 +351,7 @@ void hci_uart_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, );
 
-   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
+   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev ? hu->hdev->name : "",
   tty->termios.c_ispeed, tty->termios.c_ospeed);
 }
 
-- 
1.8.1.4

[PATCH v12 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

From: Ganapathi Bhat 

This patch implement firmware download feature for
Marvell Bluetooth devices. If firmware is already
downloaded, it will skip downloading.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
Tested-by: Jeffy Chen 
---
v2: Fixed compilation warning reported by kbuild test robot
v3: Addressed review comments from Marcel Holtmann
a) Removed vendor specific code from hci_ldisc.c
b) Get rid of static forward declaration
c) Removed unnecessary heavy nesting
d) Git rid of module parameter and global variables
e) Add logic to pick right firmware image
v4: Addresses review comments from Alan
a) Use existing kernel helper APIs instead of writing own.
b) Replace mdelay() with msleep()
v5: Addresses review comments from Loic Poulain
a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
b) Used static functions where required and removed forward delcarations
c) Edited comments for the function hci_uart_recv_data
d) Made HCI_UART_DNLD_FW flag a part of driver private data
v6: Addresses review comments from Loic Poulain
a) Used skb instead of array to store firmware data during download
b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
c) Used GFP_KERNEL instead of GFP_ATOMIC
v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change resolves
errors reported by kbuild test robot.
v8: Addressed review comments from Marcel Holtmann
a) Removed unnecessary memory allocation failure messages
b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c file
v9: Addressed review comments from Marcel Holtmann
a) Moved firmware download code from setup to prepare handler.
b) Change messages from bt_dev_*->BT_*, as hdev isn't available during 
firmware
 download.
v10: Addressed review comments from Marcel Holtmann
a) Added new callback recv_for_prepare to receive data from device
 during prepare phase
b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive callback is
 added for the same purpose
c) Used kernel API to handle unaligned data
d) Moved mrvl_set_baud functionality inside setup callback
v11: Write data through ldisc in mrvl_send_ack() instead of directly calling
write method(One Thousand Gnomes).
v12: a) Check for buffer length before copying to skb (Loic Poulain)
 b) Rearrange skb memory allocation check
---
 drivers/bluetooth/Kconfig |  11 +
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/hci_ldisc.c |   6 +
 drivers/bluetooth/hci_mrvl.c  | 545 ++
 drivers/bluetooth/hci_uart.h  |   8 +-
 5 files changed, 570 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/hci_mrvl.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index cf50fd2..daafd0c 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
 
  Say Y here to compile support for Intel AG6XX protocol.
 
+config BT_HCIUART_MRVL
+   bool "Marvell protocol support"
+   depends on BT_HCIUART
+   select BT_HCIUART_H4
+   help
+ Marvell is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for most Marvell Bluetooth
+ devices with UART interface.
+
+ Say Y here to compile support for HCI MRVL protocol.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9c18939..364dbb6 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -37,6 +37,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
 hci_uart-$(CONFIG_BT_HCIUART_BCM)  += hci_bcm.o
 hci_uart-$(CONFIG_BT_HCIUART_QCA)  += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
+hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
 
 ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 2c88586..ded13d3 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -821,6 +821,9 @@ static int __init hci_uart_init(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_init();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_init();
+#endif
 
return 0;
 }
@@ -856,6 +859,9 @@ static void __exit hci_uart_exit(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_deinit();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_deinit();
+#endif
 
/* Release tty registration of line discipline */
err = tty_unregister_ldisc(N_HCI);
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
new file mode 100644
index 000..c993c1b
--- /dev/null
+++ b/drivers/bluetooth/hci_mrvl.c
@@ -0,0 +1,545 @@
+/* Bluetooth HCI UART driver for Marvell devic

[PATCH v12 2/3] Bluetooth: hci_uart: check if hdev is present before using it

[Amitkumar Karwar]

From: Ganapathi Bhat 

The hdev struct might not have initialized in protocol receive handler.
This patch adds necessary checks.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/hci_ldisc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index d7184dc..2c88586 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -154,7 +154,9 @@ restart:
 
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
len = tty->ops->write(tty, skb->data, skb->len);
-   hdev->stat.byte_tx += len;
+
+   if (hdev)
+   hdev->stat.byte_tx += len;
 
skb_pull(skb, len);
if (skb->len) {
@@ -349,7 +351,7 @@ void hci_uart_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, );
 
-   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
+   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev ? hu->hdev->name : "",
   tty->termios.c_ispeed, tty->termios.c_ospeed);
 }
 
-- 
1.8.1.4

[PATCH v12 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

The new callback is used to prepare the device before HCI becomes
ready. One can use this to download firmware if the download process
doesn't use HCI commands. Also recv_for_prepare callback is
introduced for receiving data from devices during prepare phase.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/hci_ldisc.c | 11 ++-
 drivers/bluetooth/hci_uart.h  |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index dda9739..d7184dc 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -551,8 +551,11 @@ static void hci_uart_tty_receive(struct tty_struct *tty, 
const u8 *data,
if (!hu || tty != hu->tty)
return;
 
-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }
 
/* It does not need a lock here as it is already protected by a mutex in
 * tty caller
@@ -639,6 +642,12 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
 
hu->proto = p;
+   if (p->prepare) {
+   err = p->prepare(hu);
+   if (err)
+   return err;
+   }
+
set_bit(HCI_UART_PROTO_READY, >flags);
 
err = hci_uart_register_dev(hu);
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 839bad1..17ba3b4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -67,8 +67,11 @@ struct hci_uart_proto {
int (*close)(struct hci_uart *hu);
int (*flush)(struct hci_uart *hu);
int (*setup)(struct hci_uart *hu);
+   int (*prepare)(struct hci_uart *hu);
int (*set_baudrate)(struct hci_uart *hu, unsigned int speed);
int (*recv)(struct hci_uart *hu, const void *data, int len);
+   int (*recv_for_prepare)(struct hci_uart *hu, const void *data,
+   int len);
int (*enqueue)(struct hci_uart *hu, struct sk_buff *skb);
struct sk_buff *(*dequeue)(struct hci_uart *hu);
 };
-- 
1.8.1.4

[PATCH v12 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

From: Ganapathi Bhat 

The new callback is used to prepare the device before HCI becomes
ready. One can use this to download firmware if the download process
doesn't use HCI commands. Also recv_for_prepare callback is
introduced for receiving data from devices during prepare phase.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/hci_ldisc.c | 11 ++-
 drivers/bluetooth/hci_uart.h  |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index dda9739..d7184dc 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -551,8 +551,11 @@ static void hci_uart_tty_receive(struct tty_struct *tty, 
const u8 *data,
if (!hu || tty != hu->tty)
return;
 
-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }
 
/* It does not need a lock here as it is already protected by a mutex in
 * tty caller
@@ -639,6 +642,12 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
 
hu->proto = p;
+   if (p->prepare) {
+   err = p->prepare(hu);
+   if (err)
+   return err;
+   }
+
set_bit(HCI_UART_PROTO_READY, >flags);
 
err = hci_uart_register_dev(hu);
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 839bad1..17ba3b4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -67,8 +67,11 @@ struct hci_uart_proto {
int (*close)(struct hci_uart *hu);
int (*flush)(struct hci_uart *hu);
int (*setup)(struct hci_uart *hu);
+   int (*prepare)(struct hci_uart *hu);
int (*set_baudrate)(struct hci_uart *hu, unsigned int speed);
int (*recv)(struct hci_uart *hu, const void *data, int len);
+   int (*recv_for_prepare)(struct hci_uart *hu, const void *data,
+   int len);
int (*enqueue)(struct hci_uart *hu, struct sk_buff *skb);
struct sk_buff *(*dequeue)(struct hci_uart *hu);
 };
-- 
1.8.1.4

RE: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Loic,

> -Original Message-
> From: Loic Poulain [mailto:loic.poul...@intel.com]
> Sent: Thursday, June 30, 2016 4:24 PM
> To: Amitkumar Karwar; Jeffy Chen; linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Cathy Luo; Marcel
> Holtmann
> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> for Marvell
> 
> Hi Amitkumar,
> 
> 
> > Hi Marcel,
> 
> I suggest you to add Marcel as recipient of your patches.
> 
> >
> >> From: Jeffy Chen [mailto:jeffy.c...@rock-chips.com]
> >> Sent: Friday, June 24, 2016 11:32 AM
> >> To: Amitkumar Karwar; linux-blueto...@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat
> >> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> >> for Marvell
> >>
> >> On 2016-5-6 23:31, Amitkumar Karwar wrote:
> >>> From: Ganapathi Bhat <gb...@marvell.com>
> >>>
> >>> This patch implement firmware download feature for Marvell Bluetooth
> >>> devices. If firmware is already downloaded, it will skip
> downloading.
> 
> 
> >>> +static struct sk_buff *mrvl_process_fw_data(struct hci_uart *hu,
> >>> + struct sk_buff *skb,
> >>> + u8 *buf, int count)
> >>> +{
> >>> + struct mrvl_data *mrvl = hu->priv;
> >>> + struct fw_data *fw_data = mrvl->fwdata;
> >>> + int i = 0, len;
> >>> +
> >>> + if (!skb) {
> >>> + while (buf[i] != fw_data->expected_ack && i < count)
> >>> + i++;
> >>> + if (i == count)
> >>> + return ERR_PTR(-EILSEQ);
> >>> +
> >>> + skb = bt_skb_alloc(MRVL_FW_HDR_LEN, GFP_KERNEL);
> 
> Why you don't test skb here.
> 
> >>> + }
> >>> +
> >>> + if (!skb)
> >>> + return ERR_PTR(-ENOMEM);
> >>> +
> >>> + len = count - i;
> >>> + memcpy(skb_put(skb, len), [i], len);
> 
> You copy all the remaining data from buf into your skb, but what if buf
> contains more than one packet ? out of skb.
> Don't assume that buf contains a full packet as well as only one packet.
> 
> 

Thanks for your comments. We have added necessarily checks to address these 
comments. I will submit updated version shortly.

Regards,
Amitkumar Karwar

RE: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Loic,

> -Original Message-
> From: Loic Poulain [mailto:loic.poul...@intel.com]
> Sent: Thursday, June 30, 2016 4:24 PM
> To: Amitkumar Karwar; Jeffy Chen; linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Cathy Luo; Marcel
> Holtmann
> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> for Marvell
> 
> Hi Amitkumar,
> 
> 
> > Hi Marcel,
> 
> I suggest you to add Marcel as recipient of your patches.
> 
> >
> >> From: Jeffy Chen [mailto:jeffy.c...@rock-chips.com]
> >> Sent: Friday, June 24, 2016 11:32 AM
> >> To: Amitkumar Karwar; linux-blueto...@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat
> >> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> >> for Marvell
> >>
> >> On 2016-5-6 23:31, Amitkumar Karwar wrote:
> >>> From: Ganapathi Bhat 
> >>>
> >>> This patch implement firmware download feature for Marvell Bluetooth
> >>> devices. If firmware is already downloaded, it will skip
> downloading.
> 
> 
> >>> +static struct sk_buff *mrvl_process_fw_data(struct hci_uart *hu,
> >>> + struct sk_buff *skb,
> >>> + u8 *buf, int count)
> >>> +{
> >>> + struct mrvl_data *mrvl = hu->priv;
> >>> + struct fw_data *fw_data = mrvl->fwdata;
> >>> + int i = 0, len;
> >>> +
> >>> + if (!skb) {
> >>> + while (buf[i] != fw_data->expected_ack && i < count)
> >>> + i++;
> >>> + if (i == count)
> >>> + return ERR_PTR(-EILSEQ);
> >>> +
> >>> + skb = bt_skb_alloc(MRVL_FW_HDR_LEN, GFP_KERNEL);
> 
> Why you don't test skb here.
> 
> >>> + }
> >>> +
> >>> + if (!skb)
> >>> + return ERR_PTR(-ENOMEM);
> >>> +
> >>> + len = count - i;
> >>> + memcpy(skb_put(skb, len), [i], len);
> 
> You copy all the remaining data from buf into your skb, but what if buf
> contains more than one packet ? out of skb.
> Don't assume that buf contains a full packet as well as only one packet.
> 
> 

Thanks for your comments. We have added necessarily checks to address these 
comments. I will submit updated version shortly.

Regards,
Amitkumar Karwar

RE: [PATCH 1/1] mwifiex: key_material_v2 remove superfluous condition

[Amitkumar Karwar]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Sunday, July 31, 2016 5:41 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Heinrich Schuchardt
> Subject: [PATCH 1/1] mwifiex: key_material_v2 remove superfluous
> condition
> 
> We are using mac as source address in a memcpy.
> In the lines below we can assume mac is not NULL.
> 
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index 128add8..0d4f9fe 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -706,15 +706,10 @@ mwifiex_cmd_802_11_key_material_v2(struct
> mwifiex_private *priv,
>   (priv->wep_key_curr_index & KEY_INDEX_MASK))
>   key_info |= KEY_DEFAULT;
>   } else {
> - if (mac) {
> - if (is_broadcast_ether_addr(mac))
> - key_info |= KEY_MCAST;
> - else
> - key_info |= KEY_UNICAST |
> - KEY_DEFAULT;
> - } else {
> + if (is_broadcast_ether_addr(mac))
>   key_info |= KEY_MCAST;
> - }
> + else
> + key_info |= KEY_UNICAST | KEY_DEFAULT;
>   }
>       }
>   km->key_param_set.key_info = cpu_to_le16(key_info);
> --
> 2.8.1

Looks ok to me.

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH 1/1] mwifiex: key_material_v2 remove superfluous condition

[Amitkumar Karwar]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Sunday, July 31, 2016 5:41 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Heinrich Schuchardt
> Subject: [PATCH 1/1] mwifiex: key_material_v2 remove superfluous
> condition
> 
> We are using mac as source address in a memcpy.
> In the lines below we can assume mac is not NULL.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index 128add8..0d4f9fe 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -706,15 +706,10 @@ mwifiex_cmd_802_11_key_material_v2(struct
> mwifiex_private *priv,
>   (priv->wep_key_curr_index & KEY_INDEX_MASK))
>   key_info |= KEY_DEFAULT;
>   } else {
> - if (mac) {
> - if (is_broadcast_ether_addr(mac))
> - key_info |= KEY_MCAST;
> - else
> - key_info |= KEY_UNICAST |
> - KEY_DEFAULT;
> - } else {
> + if (is_broadcast_ether_addr(mac))
>   key_info |= KEY_MCAST;
> - }
> + else
> + key_info |= KEY_UNICAST | KEY_DEFAULT;
>   }
>   }
>   km->key_param_set.key_info = cpu_to_le16(key_info);
> --
> 2.8.1

Looks ok to me.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

RE: [PATCH 1/1] mwifiex: remove superfluous condition

[Amitkumar Karwar]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Sunday, July 31, 2016 4:09 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Heinrich Schuchardt
> Subject: [PATCH 1/1] mwifiex: remove superfluous condition
> 
> for_each_property_of_node is only executed if the property prop is not
> NULL.
> 
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index 7897037..128add8 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1482,7 +1482,7 @@ int mwifiex_dnld_dt_cfgdata(struct mwifiex_private
> *priv,
>   continue;
> 
>   /* property header is 6 bytes, data must fit in cmd buffer
> */
> - if (prop && prop->value && prop->length > 6 &&
> + if (prop->value && prop->length > 6 &&
>   prop->length <= MWIFIEX_SIZE_OF_CMD_BUFFER - S_DS_GEN) {
>   ret = mwifiex_send_cmd(priv, HostCmd_CMD_CFG_DATA,
>  HostCmd_ACT_GEN_SET, 0,

Thanks. The patch looks fine to me.

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH 1/1] mwifiex: remove superfluous condition

[Amitkumar Karwar]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Sunday, July 31, 2016 4:09 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Heinrich Schuchardt
> Subject: [PATCH 1/1] mwifiex: remove superfluous condition
> 
> for_each_property_of_node is only executed if the property prop is not
> NULL.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index 7897037..128add8 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1482,7 +1482,7 @@ int mwifiex_dnld_dt_cfgdata(struct mwifiex_private
> *priv,
>   continue;
> 
>   /* property header is 6 bytes, data must fit in cmd buffer
> */
> - if (prop && prop->value && prop->length > 6 &&
> + if (prop->value && prop->length > 6 &&
>   prop->length <= MWIFIEX_SIZE_OF_CMD_BUFFER - S_DS_GEN) {
>   ret = mwifiex_send_cmd(priv, HostCmd_CMD_CFG_DATA,
>  HostCmd_ACT_GEN_SET, 0,

Thanks. The patch looks fine to me.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

[PATCH] Bluetooth: btmrvl: reset is_suspending flag in failure path

[Amitkumar Karwar]

is_suspending flag remains on when host sleep fails to enable. Data
path is unnecessarily blocked after this. This patch ensures to
reset the flag in failure path.

Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/btmrvl_sdio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index b7c3928..d02f2c1 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -1625,6 +1625,7 @@ static int btmrvl_sdio_suspend(struct device *dev)
if (priv->adapter->hs_state != HS_ACTIVATED) {
if (btmrvl_enable_hs(priv)) {
BT_ERR("HS not actived, suspend failed!");
+   priv->adapter->is_suspending = false;
return -EBUSY;
}
}
-- 
1.8.1.4

[PATCH] Bluetooth: btmrvl: reset is_suspending flag in failure path

[Amitkumar Karwar]

is_suspending flag remains on when host sleep fails to enable. Data
path is unnecessarily blocked after this. This patch ensures to
reset the flag in failure path.

Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/btmrvl_sdio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index b7c3928..d02f2c1 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -1625,6 +1625,7 @@ static int btmrvl_sdio_suspend(struct device *dev)
if (priv->adapter->hs_state != HS_ACTIVATED) {
if (btmrvl_enable_hs(priv)) {
BT_ERR("HS not actived, suspend failed!");
+   priv->adapter->is_suspending = false;
return -EBUSY;
}
}
-- 
1.8.1.4

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Monday, June 27, 2016 3:43 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
> to driver. So, "leX_to_cpu" conversion is required too many times
> afterwards in driver.
> 
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
> 
> Signed-off-by: Prasun Maiti <prasunmait...@gmail.com>
> ---
> Changes in v3:
>   - Fixed the following warnings:
>   * sta_ioctl.c:1339:34: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
>   * sta_cmdresp.c:821:6: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
> 
> Changes in v4:
>   - Fixed the sparse compilation warnings:
>   * warning: cast from restricted __le32
>   * warning: cast from restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/ioctl.h   | 10 +++---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +++
> -
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 +++
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++--
>  4 files changed, 46 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> index a5a48c1..4ce9330 100644
> --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> @@ -341,16 +341,16 @@ enum {
>  };
> 
>  struct mwifiex_ds_reg_rw {
> - __le32 type;
> - __le32 offset;
> - __le32 value;
> + u32 type;
> + u32 offset;
> + u32 value;
>  };
> 
>  #define MAX_EEPROM_DATA 256
> 
>  struct mwifiex_ds_read_eeprom {
> - __le16 offset;
> - __le16 byte_count;
> + u16 offset;
> + u16 byte_count;
>   u8 value[MAX_EEPROM_DATA];
>  };
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574..9df02ba 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
>   mac_reg = >params.mac_reg;
>   mac_reg->action = cpu_to_le16(cmd_action);
> - mac_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - mac_reg->value = reg_rw->value;
> + mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + mac_reg->value = cpu_to_le32(reg_rw->value);
>   break;
>   }
>   case HostCmd_CMD_BBP_REG_ACCESS:
> @@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
>   bbp_reg = >params.bbp_reg;
>   bbp_reg->action = cpu_to_le16(cmd_action);
> - bbp_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + bbp_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_RF_REG_ACCESS:
> @@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
>   rf_reg = >params.rf_reg;
>   rf_reg->action = cpu_to_le16(cmd_action);
> - rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw-
> >offset));
> - rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + rf_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_PMIC_REG_ACCESS:
> @@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
>  

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Monday, June 27, 2016 3:43 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
> to driver. So, "leX_to_cpu" conversion is required too many times
> afterwards in driver.
> 
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
> 
> Signed-off-by: Prasun Maiti 
> ---
> Changes in v3:
>   - Fixed the following warnings:
>   * sta_ioctl.c:1339:34: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
>   * sta_cmdresp.c:821:6: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
> 
> Changes in v4:
>   - Fixed the sparse compilation warnings:
>   * warning: cast from restricted __le32
>   * warning: cast from restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/ioctl.h   | 10 +++---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +++
> -
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 +++
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++--
>  4 files changed, 46 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> index a5a48c1..4ce9330 100644
> --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> @@ -341,16 +341,16 @@ enum {
>  };
> 
>  struct mwifiex_ds_reg_rw {
> - __le32 type;
> - __le32 offset;
> - __le32 value;
> + u32 type;
> + u32 offset;
> + u32 value;
>  };
> 
>  #define MAX_EEPROM_DATA 256
> 
>  struct mwifiex_ds_read_eeprom {
> - __le16 offset;
> - __le16 byte_count;
> + u16 offset;
> + u16 byte_count;
>   u8 value[MAX_EEPROM_DATA];
>  };
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574..9df02ba 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
>   mac_reg = >params.mac_reg;
>   mac_reg->action = cpu_to_le16(cmd_action);
> - mac_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - mac_reg->value = reg_rw->value;
> + mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + mac_reg->value = cpu_to_le32(reg_rw->value);
>   break;
>   }
>   case HostCmd_CMD_BBP_REG_ACCESS:
> @@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
>   bbp_reg = >params.bbp_reg;
>   bbp_reg->action = cpu_to_le16(cmd_action);
> - bbp_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + bbp_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_RF_REG_ACCESS:
> @@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
>   rf_reg = >params.rf_reg;
>   rf_reg->action = cpu_to_le16(cmd_action);
> - rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw-
> >offset));
> - rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + rf_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_PMIC_REG_ACCESS:
> @@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
>   pmic_reg = >params.pmi

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
> ow...@vger.kernel.org] On Behalf Of Kalle Valo
> Sent: Friday, July 08, 2016 7:10 PM
> To: Amitkumar Karwar
> Cc: Prasun Maiti; Nishant Sarmukadam; Linux Wireless; Linux Next; Linux
> Kernel
> Subject: Re: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> Amitkumar Karwar <akar...@marvell.com> writes:
> 
> >> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> >> Sent: Monday, June 27, 2016 3:43 PM
> >> To: Amitkumar Karwar
> >> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel;
> >> Kalle Valo
> >> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> >> Commands
> >>
> >> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> >> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are
> >> saved to driver. So, "leX_to_cpu" conversion is required too many
> >> times afterwards in driver.
> >>
> >> This patch reduces the endian: conversion without saving "cpu_to_leX"
> >> converted values in driver. This will convert endianness in prepare
> >> command and command response path.
> >>
> >> Signed-off-by: Prasun Maiti <prasunmait...@gmail.com>
> 
> [deleted almost 300 lines of unnecessary quotes]
> 
> > Any specific reason for dropping this patch?
> > I can see the status as "Deferred" on patchwork.
> 
> It's not dropped, "Deferred" means that the patch was postponed for some
> reason and I need to look at the patch more carefully. In this case I
> did it because I was hoping to see an Acked-by from you.

Thanks for clarification. I will ack the patch.

Regards,
Amitkumar

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
> ow...@vger.kernel.org] On Behalf Of Kalle Valo
> Sent: Friday, July 08, 2016 7:10 PM
> To: Amitkumar Karwar
> Cc: Prasun Maiti; Nishant Sarmukadam; Linux Wireless; Linux Next; Linux
> Kernel
> Subject: Re: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> Amitkumar Karwar  writes:
> 
> >> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> >> Sent: Monday, June 27, 2016 3:43 PM
> >> To: Amitkumar Karwar
> >> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel;
> >> Kalle Valo
> >> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> >> Commands
> >>
> >> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> >> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are
> >> saved to driver. So, "leX_to_cpu" conversion is required too many
> >> times afterwards in driver.
> >>
> >> This patch reduces the endian: conversion without saving "cpu_to_leX"
> >> converted values in driver. This will convert endianness in prepare
> >> command and command response path.
> >>
> >> Signed-off-by: Prasun Maiti 
> 
> [deleted almost 300 lines of unnecessary quotes]
> 
> > Any specific reason for dropping this patch?
> > I can see the status as "Deferred" on patchwork.
> 
> It's not dropped, "Deferred" means that the patch was postponed for some
> reason and I need to look at the patch more carefully. In this case I
> did it because I was hoping to see an Acked-by from you.

Thanks for clarification. I will ack the patch.

Regards,
Amitkumar

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

Hi Kalle,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Monday, June 27, 2016 3:43 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
> to driver. So, "leX_to_cpu" conversion is required too many times
> afterwards in driver.
> 
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
> 
> Signed-off-by: Prasun Maiti <prasunmait...@gmail.com>
> ---
> Changes in v3:
>   - Fixed the following warnings:
>   * sta_ioctl.c:1339:34: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
>   * sta_cmdresp.c:821:6: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
> 
> Changes in v4:
>   - Fixed the sparse compilation warnings:
>   * warning: cast from restricted __le32
>   * warning: cast from restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/ioctl.h   | 10 +++---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +++
> -
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 +++
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++--
>  4 files changed, 46 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> index a5a48c1..4ce9330 100644
> --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> @@ -341,16 +341,16 @@ enum {
>  };
> 
>  struct mwifiex_ds_reg_rw {
> - __le32 type;
> - __le32 offset;
> - __le32 value;
> + u32 type;
> + u32 offset;
> + u32 value;
>  };
> 
>  #define MAX_EEPROM_DATA 256
> 
>  struct mwifiex_ds_read_eeprom {
> - __le16 offset;
> - __le16 byte_count;
> + u16 offset;
> + u16 byte_count;
>   u8 value[MAX_EEPROM_DATA];
>  };
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574..9df02ba 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
>   mac_reg = >params.mac_reg;
>   mac_reg->action = cpu_to_le16(cmd_action);
> - mac_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - mac_reg->value = reg_rw->value;
> + mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + mac_reg->value = cpu_to_le32(reg_rw->value);
>   break;
>   }
>   case HostCmd_CMD_BBP_REG_ACCESS:
> @@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
>   bbp_reg = >params.bbp_reg;
>   bbp_reg->action = cpu_to_le16(cmd_action);
> - bbp_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + bbp_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_RF_REG_ACCESS:
> @@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
>   rf_reg = >params.rf_reg;
>   rf_reg->action = cpu_to_le16(cmd_action);
> - rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw-
> >offset));
> - rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + rf_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_PMIC_REG_ACCESS:
> @@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*pm

RE: [PATCH v4] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

Hi Kalle,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Monday, June 27, 2016 3:43 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v4] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
> to driver. So, "leX_to_cpu" conversion is required too many times
> afterwards in driver.
> 
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
> 
> Signed-off-by: Prasun Maiti 
> ---
> Changes in v3:
>   - Fixed the following warnings:
>   * sta_ioctl.c:1339:34: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
>   * sta_cmdresp.c:821:6: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
> 
> Changes in v4:
>   - Fixed the sparse compilation warnings:
>   * warning: cast from restricted __le32
>   * warning: cast from restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/ioctl.h   | 10 +++---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +++
> -
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 +++
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++--
>  4 files changed, 46 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> index a5a48c1..4ce9330 100644
> --- a/drivers/net/wireless/marvell/mwifiex/ioctl.h
> +++ b/drivers/net/wireless/marvell/mwifiex/ioctl.h
> @@ -341,16 +341,16 @@ enum {
>  };
> 
>  struct mwifiex_ds_reg_rw {
> - __le32 type;
> - __le32 offset;
> - __le32 value;
> + u32 type;
> + u32 offset;
> + u32 value;
>  };
> 
>  #define MAX_EEPROM_DATA 256
> 
>  struct mwifiex_ds_read_eeprom {
> - __le16 offset;
> - __le16 byte_count;
> + u16 offset;
> + u16 byte_count;
>   u8 value[MAX_EEPROM_DATA];
>  };
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574..9df02ba 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
>   mac_reg = >params.mac_reg;
>   mac_reg->action = cpu_to_le16(cmd_action);
> - mac_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - mac_reg->value = reg_rw->value;
> + mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + mac_reg->value = cpu_to_le32(reg_rw->value);
>   break;
>   }
>   case HostCmd_CMD_BBP_REG_ACCESS:
> @@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
>   bbp_reg = >params.bbp_reg;
>   bbp_reg->action = cpu_to_le16(cmd_action);
> - bbp_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + bbp_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_RF_REG_ACCESS:
> @@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
>   rf_reg = >params.rf_reg;
>   rf_reg->action = cpu_to_le16(cmd_action);
> - rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw-
> >offset));
> - rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + rf_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_PMIC_REG_ACCESS:
> @@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
>   pmic_re

RE: [PATCH v2] mwifiex: Fix endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Amitkumar Karwar]

Hi Prasun,

> -Original Message-
> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Thursday, June 30, 2016 2:01 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v2] mwifiex: Fix endianness for event TLV type
> TLV_BTCOEX_WL_SCANTIME
> 
> The two members min_scan_time and max_scan_time of structure
> "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
> are assigned directtly from firmware without endian conversion handling.
> So, wrong datas will get saved in big-endian systems.
> 
> This patch converts the values into cpu's byte order before assigning
> them into the local members.
> 
> Signed-off-by: Prasun Maiti <prasunmait...@gmail.com>
> ---
> Changes in v2:
>   - Fixed the following sparse compilation warnings:
>   * sta_event.c:477:55: warning: cast to restricted __le16
>   * sta_event.c:478:55: warning: cast to restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/fw.h| 4 ++--
>  drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h
> b/drivers/net/wireless/marvell/mwifiex/fw.h
> index 8e4145a..03d3edf 100644
> --- a/drivers/net/wireless/marvell/mwifiex/fw.h
> +++ b/drivers/net/wireless/marvell/mwifiex/fw.h
> @@ -1958,8 +1958,8 @@ struct mwifiex_ie_types_btcoex_scan_time {
>   struct mwifiex_ie_types_header header;
>   u8 coex_scan;
>   u8 reserved;
> - u16 min_scan_time;
> - u16 max_scan_time;
> + __le16 min_scan_time;
> + __le16 max_scan_time;
>  } __packed;
> 
>  struct mwifiex_ie_types_btcoex_aggr_win_size { diff --git
> a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> index 0104108..7dff452 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> @@ -474,8 +474,8 @@ void mwifiex_bt_coex_wlan_param_update_event(struct
> mwifiex_private *priv,
>   scantlv =
>   (struct mwifiex_ie_types_btcoex_scan_time *)tlv;
>   adapter->coex_scan = scantlv->coex_scan;
> - adapter->coex_min_scan_time = scantlv->min_scan_time;
> - adapter->coex_max_scan_time = scantlv->max_scan_time;
> + adapter->coex_min_scan_time = le16_to_cpu(scantlv-
> >min_scan_time);
> +     adapter->coex_max_scan_time = le16_to_cpu(scantlv-
> >max_scan_time);
>   break;
> 
>   default:
> --
> 1.9.1

Updated change looks fine to me.

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH v2] mwifiex: Fix endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Amitkumar Karwar]

Hi Prasun,

> -Original Message-
> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Thursday, June 30, 2016 2:01 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v2] mwifiex: Fix endianness for event TLV type
> TLV_BTCOEX_WL_SCANTIME
> 
> The two members min_scan_time and max_scan_time of structure
> "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
> are assigned directtly from firmware without endian conversion handling.
> So, wrong datas will get saved in big-endian systems.
> 
> This patch converts the values into cpu's byte order before assigning
> them into the local members.
> 
> Signed-off-by: Prasun Maiti 
> ---
> Changes in v2:
>   - Fixed the following sparse compilation warnings:
>   * sta_event.c:477:55: warning: cast to restricted __le16
>   * sta_event.c:478:55: warning: cast to restricted __le16
> 
>  drivers/net/wireless/marvell/mwifiex/fw.h| 4 ++--
>  drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h
> b/drivers/net/wireless/marvell/mwifiex/fw.h
> index 8e4145a..03d3edf 100644
> --- a/drivers/net/wireless/marvell/mwifiex/fw.h
> +++ b/drivers/net/wireless/marvell/mwifiex/fw.h
> @@ -1958,8 +1958,8 @@ struct mwifiex_ie_types_btcoex_scan_time {
>   struct mwifiex_ie_types_header header;
>   u8 coex_scan;
>   u8 reserved;
> - u16 min_scan_time;
> - u16 max_scan_time;
> + __le16 min_scan_time;
> + __le16 max_scan_time;
>  } __packed;
> 
>  struct mwifiex_ie_types_btcoex_aggr_win_size { diff --git
> a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> index 0104108..7dff452 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> @@ -474,8 +474,8 @@ void mwifiex_bt_coex_wlan_param_update_event(struct
> mwifiex_private *priv,
>   scantlv =
>   (struct mwifiex_ie_types_btcoex_scan_time *)tlv;
>   adapter->coex_scan = scantlv->coex_scan;
> - adapter->coex_min_scan_time = scantlv->min_scan_time;
> - adapter->coex_max_scan_time = scantlv->max_scan_time;
> + adapter->coex_min_scan_time = le16_to_cpu(scantlv-
> >min_scan_time);
> +     adapter->coex_max_scan_time = le16_to_cpu(scantlv-
> >max_scan_time);
>   break;
> 
>   default:
> --
> 1.9.1

Updated change looks fine to me.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

RE: [PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Friday, June 24, 2016 12:27 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: Linux Wireless; Linux Next; Linux Kernel
> Subject: Re: [PATCH] mwifiex: Fixed endianness for event TLV type
> TLV_BTCOEX_WL_SCANTIME
> 
> On Thu, Jun 16, 2016 at 9:49 AM, Prasun Maiti <prasunmait...@gmail.com>
> wrote:
> > The two members min_scan_time and max_scan_time of structure
> > "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
> > are assigned directtly from firmware without endian conversion
> handling.
> > So, wrong datas will get saved in big-endian systems.
> >
> > This patch converts the values into cpu's byte order before assigning
> > them into the local members.
> >
> > Signed-off-by: Prasun Maiti <prasunmait...@gmail.com>
> > ---
> >  drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > index 0104108..7dff452 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > @@ -474,8 +474,8 @@ void
> mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
> > scantlv =
> > (struct mwifiex_ie_types_btcoex_scan_time
> *)tlv;
> > adapter->coex_scan = scantlv->coex_scan;
> > -   adapter->coex_min_scan_time = scantlv-
> >min_scan_time;
> > -   adapter->coex_max_scan_time = scantlv-
> >max_scan_time;
> > +   adapter->coex_min_scan_time =
> le16_to_cpu(scantlv->min_scan_time);
> > +   adapter->coex_max_scan_time =
> > + le16_to_cpu(scantlv->max_scan_time);
> > break;
> >
> > default:
> > --
> > 1.9.1
> >

Along with this change, you need to define these elements as __le16 in scan_tlv 
structure. Ensure that sparse compilation is passed with your final patch.

Regards,
Amitkumar

RE: [PATCH] mwifiex: Fixed endianness for event TLV type TLV_BTCOEX_WL_SCANTIME

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Friday, June 24, 2016 12:27 PM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: Linux Wireless; Linux Next; Linux Kernel
> Subject: Re: [PATCH] mwifiex: Fixed endianness for event TLV type
> TLV_BTCOEX_WL_SCANTIME
> 
> On Thu, Jun 16, 2016 at 9:49 AM, Prasun Maiti 
> wrote:
> > The two members min_scan_time and max_scan_time of structure
> > "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values
> > are assigned directtly from firmware without endian conversion
> handling.
> > So, wrong datas will get saved in big-endian systems.
> >
> > This patch converts the values into cpu's byte order before assigning
> > them into the local members.
> >
> > Signed-off-by: Prasun Maiti 
> > ---
> >  drivers/net/wireless/marvell/mwifiex/sta_event.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > index 0104108..7dff452 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/sta_event.c
> > @@ -474,8 +474,8 @@ void
> mwifiex_bt_coex_wlan_param_update_event(struct mwifiex_private *priv,
> > scantlv =
> > (struct mwifiex_ie_types_btcoex_scan_time
> *)tlv;
> > adapter->coex_scan = scantlv->coex_scan;
> > -   adapter->coex_min_scan_time = scantlv-
> >min_scan_time;
> > -   adapter->coex_max_scan_time = scantlv-
> >max_scan_time;
> > +   adapter->coex_min_scan_time =
> le16_to_cpu(scantlv->min_scan_time);
> > +   adapter->coex_max_scan_time =
> > + le16_to_cpu(scantlv->max_scan_time);
> > break;
> >
> > default:
> > --
> > 1.9.1
> >

Along with this change, you need to define these elements as __le16 in scan_tlv 
structure. Ensure that sparse compilation is passed with your final patch.

Regards,
Amitkumar

RE: [PATCH v3] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Thursday, June 23, 2016 10:59 AM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v3] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
> to driver. So, "leX_to_cpu" conversion is required too many times
> afterwards in driver.
> 
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
> 
> Signed-off-by: Prasun Maiti <prasunmait...@gmail.com>
> ---
> Changes in v3:
>   - Fixed the following warnings:
>   * sta_ioctl.c:1339:34: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
>   * sta_cmdresp.c:821:6: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
> 
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +++
> -
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 +++
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++--
>  3 files changed, 41 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574..9df02ba 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
>   mac_reg = >params.mac_reg;
>   mac_reg->action = cpu_to_le16(cmd_action);
> - mac_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - mac_reg->value = reg_rw->value;
> + mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + mac_reg->value = cpu_to_le32(reg_rw->value);
>   break;
>   }
>   case HostCmd_CMD_BBP_REG_ACCESS:
> @@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
>   bbp_reg = >params.bbp_reg;
>   bbp_reg->action = cpu_to_le16(cmd_action);
> - bbp_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + bbp_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_RF_REG_ACCESS:
> @@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
>   rf_reg = >params.rf_reg;
>   rf_reg->action = cpu_to_le16(cmd_action);
> - rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw-
> >offset));
> - rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + rf_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_PMIC_REG_ACCESS:
> @@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
>   pmic_reg = >params.pmic_reg;
>   pmic_reg->action = cpu_to_le16(cmd_action);
> - pmic_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - pmic_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + pmic_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + pmic_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_CAU_REG_ACCESS:
> @@ -1177,9 +1174,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*cau_reg) + S_DS_GEN);
>   cau_reg = >params.rf_reg;
>   cau_reg->action = cpu_to_le16(cmd_action);
> - cau_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - cau

RE: [PATCH v3] mwifiex: Reduce endian conversion for REG Host Commands

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Thursday, June 23, 2016 10:59 AM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; Linux Wireless; Linux Next; Linux Kernel; Kalle
> Valo
> Subject: [PATCH v3] mwifiex: Reduce endian conversion for REG Host
> Commands
> 
> For multiple REG Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS,
> HostCmd_CMD_MAC_REG_ACCESS etc.) "cpu_to_leX"-converted values are saved
> to driver. So, "leX_to_cpu" conversion is required too many times
> afterwards in driver.
> 
> This patch reduces the endian: conversion without saving "cpu_to_leX"
> converted values in driver. This will convert endianness in prepare
> command and command response path.
> 
> Signed-off-by: Prasun Maiti 
> ---
> Changes in v3:
>   - Fixed the following warnings:
>   * sta_ioctl.c:1339:34: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
>   * sta_cmdresp.c:821:6: warning: comparison of distinct pointer
> types lacks a cast [enabled by default]
> 
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +++
> -
>  drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 +++
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   | 21 ++--
>  3 files changed, 41 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e436574..9df02ba 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1130,9 +1130,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*mac_reg) + S_DS_GEN);
>   mac_reg = >params.mac_reg;
>   mac_reg->action = cpu_to_le16(cmd_action);
> - mac_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - mac_reg->value = reg_rw->value;
> + mac_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + mac_reg->value = cpu_to_le32(reg_rw->value);
>   break;
>   }
>   case HostCmd_CMD_BBP_REG_ACCESS:
> @@ -1142,9 +1141,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*bbp_reg) + S_DS_GEN);
>   bbp_reg = >params.bbp_reg;
>   bbp_reg->action = cpu_to_le16(cmd_action);
> - bbp_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - bbp_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + bbp_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + bbp_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_RF_REG_ACCESS:
> @@ -1154,8 +1152,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*rf_reg) + S_DS_GEN);
>   rf_reg = >params.rf_reg;
>   rf_reg->action = cpu_to_le16(cmd_action);
> - rf_reg->offset = cpu_to_le16((u16) le32_to_cpu(reg_rw-
> >offset));
> - rf_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + rf_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + rf_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_PMIC_REG_ACCESS:
> @@ -1165,9 +1163,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*pmic_reg) + S_DS_GEN);
>   pmic_reg = >params.pmic_reg;
>   pmic_reg->action = cpu_to_le16(cmd_action);
> - pmic_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - pmic_reg->value = (u8) le32_to_cpu(reg_rw->value);
> + pmic_reg->offset = cpu_to_le16((u16) reg_rw->offset);
> + pmic_reg->value = (u8) reg_rw->value;
>   break;
>   }
>   case HostCmd_CMD_CAU_REG_ACCESS:
> @@ -1177,9 +1174,8 @@ static int mwifiex_cmd_reg_access(struct
> host_cmd_ds_command *cmd,
>   cmd->size = cpu_to_le16(sizeof(*cau_reg) + S_DS_GEN);
>   cau_reg = >params.rf_reg;
>   cau_reg->action = cpu_to_le16(cmd_action);
> - cau_reg->offset =
> - cpu_to_le16((u16) le32_to_cpu(reg_rw->offset));
> - cau_reg-&

RE: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Marcel,

> From: Jeffy Chen [mailto:jeffy.c...@rock-chips.com]
> Sent: Friday, June 24, 2016 11:32 AM
> To: Amitkumar Karwar; linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat
> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> for Marvell
> 
> On 2016-5-6 23:31, Amitkumar Karwar wrote:
> > From: Ganapathi Bhat <gb...@marvell.com>
> >
> > This patch implement firmware download feature for Marvell Bluetooth
> > devices. If firmware is already downloaded, it will skip downloading.
> >
> > Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> > ---
> > v2: Fixed compilation warning reported by kbuild test robot
> > v3: Addressed review comments from Marcel Holtmann
> >  a) Removed vendor specific code from hci_ldisc.c
> >  b) Get rid of static forward declaration
> >  c) Removed unnecessary heavy nesting
> >  d) Git rid of module parameter and global variables
> >  e) Add logic to pick right firmware image
> > v4: Addresses review comments from Alan
> >  a) Use existing kernel helper APIs instead of writing own.
> >  b) Replace mdelay() with msleep()
> > v5: Addresses review comments from Loic Poulain
> >  a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> >  b) Used static functions where required and removed forward
> delcarations
> >  c) Edited comments for the function hci_uart_recv_data
> >  d) Made HCI_UART_DNLD_FW flag a part of driver private data
> > v6: Addresses review comments from Loic Poulain
> >  a) Used skb instead of array to store firmware data during
> download
> >  b) Used hci_uart_tx_wakeup and enqueued packets instead of tty
> write
> >  c) Used GFP_KERNEL instead of GFP_ATOMIC
> > v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> resolves
> >  errors reported by kbuild test robot.
> > v8: Addressed review comments from Marcel Holtmann
> >  a) Removed unnecessary memory allocation failure messages
> >  b) Get rid of btmrvl.h header file and add definitions in
> > hci_mrvl.c file
> > v9: Addressed review comments from Marcel Holtmann
> >  a) Moved firmware download code from setup to prepare handler.
> >  b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> during firmware
> >   download.
> > v10: Addressed review comments from Marcel Holtmann
> >  a) Added new callback recv_for_prepare to receive data from
> device
> >   during prepare phase
> >  b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> callback is
> >   added for the same purpose
> >  c) Used kernel API to handle unaligned data
> >  d) Moved mrvl_set_baud functionality inside setup callback
> > v11: Write data through ldisc in mrvl_send_ack() instead of directly
> calling
> >  write method(One Thousand Gnomes).
> > ---
> >   drivers/bluetooth/Kconfig |  11 +
> >   drivers/bluetooth/Makefile|   1 +
> >   drivers/bluetooth/hci_ldisc.c |   6 +
> >   drivers/bluetooth/hci_mrvl.c  | 543
> ++
> >   drivers/bluetooth/hci_uart.h  |   8 +-
> >   5 files changed, 568 insertions(+), 1 deletion(-)
> >   create mode 100644 drivers/bluetooth/hci_mrvl.c
> >
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index cf50fd2..daafd0c 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
> >
> >   Say Y here to compile support for Intel AG6XX protocol.
> >
> > +config BT_HCIUART_MRVL
> > +   bool "Marvell protocol support"
> > +   depends on BT_HCIUART
> > +   select BT_HCIUART_H4
> > +   help
> > + Marvell is serial protocol for communication between Bluetooth
> > + device and host. This protocol is required for most Marvell
> Bluetooth
> > + devices with UART interface.
> > +
> > + Say Y here to compile support for HCI MRVL protocol.
> > +
> >   config BT_HCIBCM203X
> > tristate "HCI BCM203x USB driver"
> > depends on USB
> > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> > index 9c18939..364dbb6 100644
> > --- a/drivers/bluetooth/Makefile
> > +++ b/drivers/bluetooth/Makefile
> > @@ -37,6 +37,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
> >   hci_uart-$(CONFIG_BT_H

RE: [v11,3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Marcel,

> From: Jeffy Chen [mailto:jeffy.c...@rock-chips.com]
> Sent: Friday, June 24, 2016 11:32 AM
> To: Amitkumar Karwar; linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat
> Subject: Re: [v11,3/3] Bluetooth: hci_uart: Support firmware download
> for Marvell
> 
> On 2016-5-6 23:31, Amitkumar Karwar wrote:
> > From: Ganapathi Bhat 
> >
> > This patch implement firmware download feature for Marvell Bluetooth
> > devices. If firmware is already downloaded, it will skip downloading.
> >
> > Signed-off-by: Ganapathi Bhat 
> > Signed-off-by: Amitkumar Karwar 
> > ---
> > v2: Fixed compilation warning reported by kbuild test robot
> > v3: Addressed review comments from Marcel Holtmann
> >  a) Removed vendor specific code from hci_ldisc.c
> >  b) Get rid of static forward declaration
> >  c) Removed unnecessary heavy nesting
> >  d) Git rid of module parameter and global variables
> >  e) Add logic to pick right firmware image
> > v4: Addresses review comments from Alan
> >  a) Use existing kernel helper APIs instead of writing own.
> >  b) Replace mdelay() with msleep()
> > v5: Addresses review comments from Loic Poulain
> >  a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> >  b) Used static functions where required and removed forward
> delcarations
> >  c) Edited comments for the function hci_uart_recv_data
> >  d) Made HCI_UART_DNLD_FW flag a part of driver private data
> > v6: Addresses review comments from Loic Poulain
> >  a) Used skb instead of array to store firmware data during
> download
> >  b) Used hci_uart_tx_wakeup and enqueued packets instead of tty
> write
> >  c) Used GFP_KERNEL instead of GFP_ATOMIC
> > v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> resolves
> >  errors reported by kbuild test robot.
> > v8: Addressed review comments from Marcel Holtmann
> >  a) Removed unnecessary memory allocation failure messages
> >  b) Get rid of btmrvl.h header file and add definitions in
> > hci_mrvl.c file
> > v9: Addressed review comments from Marcel Holtmann
> >  a) Moved firmware download code from setup to prepare handler.
> >  b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> during firmware
> >   download.
> > v10: Addressed review comments from Marcel Holtmann
> >  a) Added new callback recv_for_prepare to receive data from
> device
> >   during prepare phase
> >  b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> callback is
> >   added for the same purpose
> >  c) Used kernel API to handle unaligned data
> >  d) Moved mrvl_set_baud functionality inside setup callback
> > v11: Write data through ldisc in mrvl_send_ack() instead of directly
> calling
> >  write method(One Thousand Gnomes).
> > ---
> >   drivers/bluetooth/Kconfig |  11 +
> >   drivers/bluetooth/Makefile|   1 +
> >   drivers/bluetooth/hci_ldisc.c |   6 +
> >   drivers/bluetooth/hci_mrvl.c  | 543
> ++
> >   drivers/bluetooth/hci_uart.h  |   8 +-
> >   5 files changed, 568 insertions(+), 1 deletion(-)
> >   create mode 100644 drivers/bluetooth/hci_mrvl.c
> >
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index cf50fd2..daafd0c 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
> >
> >   Say Y here to compile support for Intel AG6XX protocol.
> >
> > +config BT_HCIUART_MRVL
> > +   bool "Marvell protocol support"
> > +   depends on BT_HCIUART
> > +   select BT_HCIUART_H4
> > +   help
> > + Marvell is serial protocol for communication between Bluetooth
> > + device and host. This protocol is required for most Marvell
> Bluetooth
> > + devices with UART interface.
> > +
> > + Say Y here to compile support for HCI MRVL protocol.
> > +
> >   config BT_HCIBCM203X
> > tristate "HCI BCM203x USB driver"
> > depends on USB
> > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> > index 9c18939..364dbb6 100644
> > --- a/drivers/bluetooth/Makefile
> > +++ b/drivers/bluetooth/Makefile
> > @@ -37,6 +37,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
> >   hci_uart-$(CONFIG_BT_HCIUART_BCM) += hci_bcm.o
> >   hci_uart-$(CONFIG_BT_HCIUART

RE: [Query] mwifiex: few observations to reduce number of endian conversions

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Friday, June 17, 2016 6:42 PM
> To: Amitkumar Karwar; Nishant Sarmukadam
> Cc: Linux Kernel; Linux Next; WiFi Mailing List; Johannes Berg
> Subject: [Query] mwifiex: few observations to reduce number of endian
> conversions
> 
> Hi Amitkumar,
> 
> I have two observations:
> 
> 1. I have found that in the command response path for host command
> "HostCmd_CMD_802_11_EEPROM_ACCESS", a "0" value has been endian
> converted. It can only be a safe futuristic approach for any non-zero
> value there however! Otherwise, the endian conversion can be removed.
> 
> 2. For multiple Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS
> etc.) "cpu_to_leX"-converted values are saved to driver. So "leX_to_cpu"
> conversion is required too many times afterwards in driver.
> On the contrary, we can save the values to driver without any
> conversion, and only command buffer(s) are prepared with endian
> converted values. In this way we can gain some efficiency [code size /
> time] by reducing the number of endian conversion considerably.
> 

I agree with your observations. We'll prepare a cleanup patch to address this.

Regards,
Amitkumar

RE: [Query] mwifiex: few observations to reduce number of endian conversions

[Amitkumar Karwar]

Hi Prasun,

> From: Prasun Maiti [mailto:prasunmait...@gmail.com]
> Sent: Friday, June 17, 2016 6:42 PM
> To: Amitkumar Karwar; Nishant Sarmukadam
> Cc: Linux Kernel; Linux Next; WiFi Mailing List; Johannes Berg
> Subject: [Query] mwifiex: few observations to reduce number of endian
> conversions
> 
> Hi Amitkumar,
> 
> I have two observations:
> 
> 1. I have found that in the command response path for host command
> "HostCmd_CMD_802_11_EEPROM_ACCESS", a "0" value has been endian
> converted. It can only be a safe futuristic approach for any non-zero
> value there however! Otherwise, the endian conversion can be removed.
> 
> 2. For multiple Host Commands (e.g HostCmd_CMD_802_11_EEPROM_ACCESS
> etc.) "cpu_to_leX"-converted values are saved to driver. So "leX_to_cpu"
> conversion is required too many times afterwards in driver.
> On the contrary, we can save the values to driver without any
> conversion, and only command buffer(s) are prepared with endian
> converted values. In this way we can gain some efficiency [code size /
> time] by reducing the number of endian conversion considerably.
> 

I agree with your observations. We'll prepare a cleanup patch to address this.

Regards,
Amitkumar

RE: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar
> Sent: Monday, May 23, 2016 11:37 AM
> To: 'linux-blueto...@vger.kernel.org'
> Cc: 'linux-kernel@vger.kernel.org'; Ganapathi Bhat; Cathy Luo
> Subject: RE: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware
> download for Marvell
> 
> Hi Marcel,
> 
> > > From: Amitkumar Karwar [mailto:akar...@marvell.com]
> > > Sent: Friday, May 06, 2016 9:02 PM
> > > To: linux-blueto...@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Amitkumar Karwar
> > > Subject: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware
> > > download for Marvell
> > >
> > > From: Ganapathi Bhat <gb...@marvell.com>
> > >
> > > This patch implement firmware download feature for Marvell Bluetooth
> > > devices. If firmware is already downloaded, it will skip
> downloading.
> > >
> > > Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> > > Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> > > ---
> > > v2: Fixed compilation warning reported by kbuild test robot
> > > v3: Addressed review comments from Marcel Holtmann
> > > a) Removed vendor specific code from hci_ldisc.c
> > > b) Get rid of static forward declaration
> > > c) Removed unnecessary heavy nesting
> > > d) Git rid of module parameter and global variables
> > > e) Add logic to pick right firmware image
> > > v4: Addresses review comments from Alan
> > > a) Use existing kernel helper APIs instead of writing own.
> > > b) Replace mdelay() with msleep()
> > > v5: Addresses review comments from Loic Poulain
> > > a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> > > b) Used static functions where required and removed forward
> > > delcarations
> > > c) Edited comments for the function hci_uart_recv_data
> > > d) Made HCI_UART_DNLD_FW flag a part of driver private data
> > > v6: Addresses review comments from Loic Poulain
> > > a) Used skb instead of array to store firmware data during
> > download
> > > b) Used hci_uart_tx_wakeup and enqueued packets instead of tty
> > write
> > > c) Used GFP_KERNEL instead of GFP_ATOMIC
> > > v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> > > resolves
> > > errors reported by kbuild test robot.
> > > v8: Addressed review comments from Marcel Holtmann
> > > a) Removed unnecessary memory allocation failure messages
> > > b) Get rid of btmrvl.h header file and add definitions in
> > > hci_mrvl.c file
> > > v9: Addressed review comments from Marcel Holtmann
> > > a) Moved firmware download code from setup to prepare handler.
> > > b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> > > during firmware
> > >  download.
> > > v10: Addressed review comments from Marcel Holtmann
> > > a) Added new callback recv_for_prepare to receive data from
> device
> > >  during prepare phase
> > > b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> > > callback is
> > >  added for the same purpose
> > > c) Used kernel API to handle unaligned data
> > > d) Moved mrvl_set_baud functionality inside setup callback
> > > v11: Write data through ldisc in mrvl_send_ack() instead of directly
> > > calling
> > > write method(One Thousand Gnomes).
> >
> 
> Could you please take this patch?
> 

This has been pending for a while.
Please let me know your comment.

Regards,
Amitkumar

RE: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar
> Sent: Monday, May 23, 2016 11:37 AM
> To: 'linux-blueto...@vger.kernel.org'
> Cc: 'linux-kernel@vger.kernel.org'; Ganapathi Bhat; Cathy Luo
> Subject: RE: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware
> download for Marvell
> 
> Hi Marcel,
> 
> > > From: Amitkumar Karwar [mailto:akar...@marvell.com]
> > > Sent: Friday, May 06, 2016 9:02 PM
> > > To: linux-blueto...@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Amitkumar Karwar
> > > Subject: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware
> > > download for Marvell
> > >
> > > From: Ganapathi Bhat 
> > >
> > > This patch implement firmware download feature for Marvell Bluetooth
> > > devices. If firmware is already downloaded, it will skip
> downloading.
> > >
> > > Signed-off-by: Ganapathi Bhat 
> > > Signed-off-by: Amitkumar Karwar 
> > > ---
> > > v2: Fixed compilation warning reported by kbuild test robot
> > > v3: Addressed review comments from Marcel Holtmann
> > > a) Removed vendor specific code from hci_ldisc.c
> > > b) Get rid of static forward declaration
> > > c) Removed unnecessary heavy nesting
> > > d) Git rid of module parameter and global variables
> > > e) Add logic to pick right firmware image
> > > v4: Addresses review comments from Alan
> > > a) Use existing kernel helper APIs instead of writing own.
> > > b) Replace mdelay() with msleep()
> > > v5: Addresses review comments from Loic Poulain
> > > a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> > > b) Used static functions where required and removed forward
> > > delcarations
> > > c) Edited comments for the function hci_uart_recv_data
> > > d) Made HCI_UART_DNLD_FW flag a part of driver private data
> > > v6: Addresses review comments from Loic Poulain
> > > a) Used skb instead of array to store firmware data during
> > download
> > > b) Used hci_uart_tx_wakeup and enqueued packets instead of tty
> > write
> > > c) Used GFP_KERNEL instead of GFP_ATOMIC
> > > v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> > > resolves
> > > errors reported by kbuild test robot.
> > > v8: Addressed review comments from Marcel Holtmann
> > > a) Removed unnecessary memory allocation failure messages
> > > b) Get rid of btmrvl.h header file and add definitions in
> > > hci_mrvl.c file
> > > v9: Addressed review comments from Marcel Holtmann
> > > a) Moved firmware download code from setup to prepare handler.
> > > b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> > > during firmware
> > >  download.
> > > v10: Addressed review comments from Marcel Holtmann
> > > a) Added new callback recv_for_prepare to receive data from
> device
> > >  during prepare phase
> > > b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> > > callback is
> > >  added for the same purpose
> > > c) Used kernel API to handle unaligned data
> > > d) Moved mrvl_set_baud functionality inside setup callback
> > > v11: Write data through ldisc in mrvl_send_ack() instead of directly
> > > calling
> > > write method(One Thousand Gnomes).
> >
> 
> Could you please take this patch?
> 

This has been pending for a while.
Please let me know your comment.

Regards,
Amitkumar

RE: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station ioctl file

[Amitkumar Karwar]

Hi Kalle/Javier,

> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Friday, June 10, 2016 8:07 PM
> To: Kalle Valo
> Cc: linux-kernel@vger.kernel.org; Julian Calaby; Shengzhen Li; Enric
> Balletbo i Serra; Amitkumar Karwar; net...@vger.kernel.org; linux-
> wirel...@vger.kernel.org; Nishant Sarmukadam
> Subject: Re: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station
> ioctl file
> 
> Hello Kalle,
> 
> On 06/10/2016 10:30 AM, Kalle Valo wrote:
> > Javier Martinez Canillas <jav...@osg.samsung.com> writes:
> >
> >> From: Shengzhen Li <s...@marvell.com>
> >>
> >> Most cfg80211 operations are just a wrappers to functions defined in
> >> the sta_ioctl.c file, so for consistency move the .get_tx_power logic
> there.
> >>
> >> Signed-off-by: Shengzhen Li <s...@marvell.com>
> >> Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> >> [javier: update the subject line and commit message]
> >> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> >
> > [...]
> >
> >> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> >> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> >> @@ -385,18 +385,10 @@ mwifiex_cfg80211_get_tx_power(struct wiphy
> *wiphy,
> >>  int *dbm)
> >>  {
> >>struct mwifiex_adapter *adapter =
> mwifiex_cfg80211_get_adapter(wiphy);
> >> -  struct mwifiex_private *priv = mwifiex_get_priv(adapter,
> >> -  MWIFIEX_BSS_ROLE_ANY);
> >> -  int ret = mwifiex_send_cmd(priv, HostCmd_CMD_RF_TX_PWR,
> >> - HostCmd_ACT_GEN_GET, 0, NULL, true);
> >> -
> >> -  if (ret < 0)
> >> -  return ret;
> >> -
> >> -  /* tx_power_level is set in HostCmd_CMD_RF_TX_PWR command handler
> */
> >> -  *dbm = priv->tx_power_level;
> >> +  struct mwifiex_private *priv;
> >>
> >> -  return 0;
> >> +  priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
> >> +  return mwifiex_get_tx_power(priv, dbm);
> >>  }
> >
> > So in patch 1 you added the patch and in patch 2 you move it to a
> > different location? That doesn't make any sense, can't you just fold
> > the two patches into one so that the function is added only once.
> >
> 
> I posted this patch in v1 but then Amitkumar shared his patch with me
> that was very similar to mine, only that the logic was in a different
> location.
> 
> So I included his delta as a separate patch to try keeping attribution
> as best as possible.
> 

This patch (2/3) is only for code rearrangement and adds an unnecessary wrapper 
function. We can simply drop the patch.

Regards,
Amitkumar

RE: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station ioctl file

[Amitkumar Karwar]

Hi Kalle/Javier,

> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Friday, June 10, 2016 8:07 PM
> To: Kalle Valo
> Cc: linux-kernel@vger.kernel.org; Julian Calaby; Shengzhen Li; Enric
> Balletbo i Serra; Amitkumar Karwar; net...@vger.kernel.org; linux-
> wirel...@vger.kernel.org; Nishant Sarmukadam
> Subject: Re: [PATCH v2 2/3] mwifiex: move .get_tx_power logic to station
> ioctl file
> 
> Hello Kalle,
> 
> On 06/10/2016 10:30 AM, Kalle Valo wrote:
> > Javier Martinez Canillas  writes:
> >
> >> From: Shengzhen Li 
> >>
> >> Most cfg80211 operations are just a wrappers to functions defined in
> >> the sta_ioctl.c file, so for consistency move the .get_tx_power logic
> there.
> >>
> >> Signed-off-by: Shengzhen Li 
> >> Signed-off-by: Amitkumar Karwar 
> >> [javier: update the subject line and commit message]
> >> Signed-off-by: Javier Martinez Canillas 
> >
> > [...]
> >
> >> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> >> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> >> @@ -385,18 +385,10 @@ mwifiex_cfg80211_get_tx_power(struct wiphy
> *wiphy,
> >>  int *dbm)
> >>  {
> >>struct mwifiex_adapter *adapter =
> mwifiex_cfg80211_get_adapter(wiphy);
> >> -  struct mwifiex_private *priv = mwifiex_get_priv(adapter,
> >> -  MWIFIEX_BSS_ROLE_ANY);
> >> -  int ret = mwifiex_send_cmd(priv, HostCmd_CMD_RF_TX_PWR,
> >> - HostCmd_ACT_GEN_GET, 0, NULL, true);
> >> -
> >> -  if (ret < 0)
> >> -  return ret;
> >> -
> >> -  /* tx_power_level is set in HostCmd_CMD_RF_TX_PWR command handler
> */
> >> -  *dbm = priv->tx_power_level;
> >> +  struct mwifiex_private *priv;
> >>
> >> -  return 0;
> >> +  priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
> >> +  return mwifiex_get_tx_power(priv, dbm);
> >>  }
> >
> > So in patch 1 you added the patch and in patch 2 you move it to a
> > different location? That doesn't make any sense, can't you just fold
> > the two patches into one so that the function is added only once.
> >
> 
> I posted this patch in v1 but then Amitkumar shared his patch with me
> that was very similar to mine, only that the logic was in a different
> location.
> 
> So I included his delta as a separate patch to try keeping attribution
> as best as possible.
> 

This patch (2/3) is only for code rearrangement and adds an unnecessary wrapper 
function. We can simply drop the patch.

Regards,
Amitkumar

RE: [PATCH 7/8] mwifiex: don't print an error if an optional DT property is missing

[Amitkumar Karwar]

> From: Julian Calaby [mailto:julian.cal...@gmail.com]
> Sent: Thursday, June 02, 2016 4:44 AM
> To: Javier Martinez Canillas; Xinming Hu
> Cc: linux-kernel@vger.kernel.org; Amitkumar Karwar; Kalle Valo; netdev;
> linux-wireless; Nishant Sarmukadam
> Subject: Re: [PATCH 7/8] mwifiex: don't print an error if an optional DT
> property is missing
> 
> Hi Javier,
> 
> On Wed, Jun 1, 2016 at 11:51 PM, Javier Martinez Canillas
> <jav...@osg.samsung.com> wrote:
> > Hello Julian,
> >
> > Thanks a lot for your feedback and reviews.
> >
> > On 06/01/2016 12:20 AM, Julian Calaby wrote:
> >> Hi All,
> >>
> >> On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas
> >> <jav...@osg.samsung.com> wrote:
> >>> The
> >>> Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT
> >>> binding document say that the "interrupts" property in the child
> node is optional. So the property being missed shouldn't be treated as
> an error.
> >>
> >> Have you checked whether it is truly optional? I.e. nothing else
> >> breaks if this property isn't set?
> >>
> >
> > That's what the DT binding says and the IRQ is only used as a wakeup
> > source during system suspend, it is not used during runtime. And that
> > is why the
> > mwifiex_sdio_probe_of() function does not fail if the IRQ is missing.
> 
> Awesome, that's what I wanted to know.
> 
> > Now, I just got to that conclusion by reading the binding docs, the
> > message in the commits that introduced this and the driver code.
> > Xinming Hu should comment on how critical this feature is for systems
> that needs to be wakeup.
> 
> Xinming, could you review this also?
> 

Yes. IRQ is the optional parameter. System has a flexibility to not use it, but 
it still can configure other device tree parameters. The patch looks good.

Regards,
Amitkumar

RE: [PATCH 7/8] mwifiex: don't print an error if an optional DT property is missing

[Amitkumar Karwar]

> From: Julian Calaby [mailto:julian.cal...@gmail.com]
> Sent: Thursday, June 02, 2016 4:44 AM
> To: Javier Martinez Canillas; Xinming Hu
> Cc: linux-kernel@vger.kernel.org; Amitkumar Karwar; Kalle Valo; netdev;
> linux-wireless; Nishant Sarmukadam
> Subject: Re: [PATCH 7/8] mwifiex: don't print an error if an optional DT
> property is missing
> 
> Hi Javier,
> 
> On Wed, Jun 1, 2016 at 11:51 PM, Javier Martinez Canillas
>  wrote:
> > Hello Julian,
> >
> > Thanks a lot for your feedback and reviews.
> >
> > On 06/01/2016 12:20 AM, Julian Calaby wrote:
> >> Hi All,
> >>
> >> On Sat, May 28, 2016 at 12:18 AM, Javier Martinez Canillas
> >>  wrote:
> >>> The
> >>> Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT
> >>> binding document say that the "interrupts" property in the child
> node is optional. So the property being missed shouldn't be treated as
> an error.
> >>
> >> Have you checked whether it is truly optional? I.e. nothing else
> >> breaks if this property isn't set?
> >>
> >
> > That's what the DT binding says and the IRQ is only used as a wakeup
> > source during system suspend, it is not used during runtime. And that
> > is why the
> > mwifiex_sdio_probe_of() function does not fail if the IRQ is missing.
> 
> Awesome, that's what I wanted to know.
> 
> > Now, I just got to that conclusion by reading the binding docs, the
> > message in the commits that introduced this and the driver code.
> > Xinming Hu should comment on how critical this feature is for systems
> that needs to be wakeup.
> 
> Xinming, could you review this also?
> 

Yes. IRQ is the optional parameter. System has a flexibility to not use it, but 
it still can configure other device tree parameters. The patch looks good.

Regards,
Amitkumar

RE: [PATCH 0/8] mwifiex: Fix some error handling issues in mwifiex_sdio_probe() function

[Amitkumar Karwar]

> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Friday, May 27, 2016 7:48 PM
> To: linux-kernel@vger.kernel.org
> Cc: Xinming Hu; Javier Martinez Canillas; Amitkumar Karwar; Kalle Valo;
> net...@vger.kernel.org; linux-wirel...@vger.kernel.org; Nishant
> Sarmukadam
> Subject: [PATCH 0/8] mwifiex: Fix some error handling issues in
> mwifiex_sdio_probe() function
> 
> Hello,
> 
> While booting a system with a mwifiex WiFi card, I noticed the following
> missleading error message:
> 
> [  12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available
> 
> This error only applies to platforms that define a child node for the
> SDIO device, but it's currently shown even in platforms that don't have
> a child node defined.
> 
> So this series fixes this issue and others I found in the .probe
> function (mostly related to error handling and the error path) while
> looking at it.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (8):
>   mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node
>   mwifiex: propagate sdio_enable_func() errno code in
> mwifiex_sdio_probe()
>   mwifiex: propagate mwifiex_add_card() errno code in
> mwifiex_sdio_probe()
>   mwifiex: consolidate mwifiex_sdio_probe() error paths
>   mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()
>   mwifiex: check if mwifiex_sdio_probe_of() fails and return error
>   mwifiex: don't print an error if an optional DT property is missing
>   mwifiex: use better message and error code when OF node doesn't match
> 
>  drivers/net/wireless/marvell/mwifiex/sdio.c | 46 ++
> ---
>  1 file changed, 28 insertions(+), 18 deletions(-)
> 

Thanks for fixing the error handling code. These patches look fine to me.

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH 0/8] mwifiex: Fix some error handling issues in mwifiex_sdio_probe() function

[Amitkumar Karwar]

> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Friday, May 27, 2016 7:48 PM
> To: linux-kernel@vger.kernel.org
> Cc: Xinming Hu; Javier Martinez Canillas; Amitkumar Karwar; Kalle Valo;
> net...@vger.kernel.org; linux-wirel...@vger.kernel.org; Nishant
> Sarmukadam
> Subject: [PATCH 0/8] mwifiex: Fix some error handling issues in
> mwifiex_sdio_probe() function
> 
> Hello,
> 
> While booting a system with a mwifiex WiFi card, I noticed the following
> missleading error message:
> 
> [  12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available
> 
> This error only applies to platforms that define a child node for the
> SDIO device, but it's currently shown even in platforms that don't have
> a child node defined.
> 
> So this series fixes this issue and others I found in the .probe
> function (mostly related to error handling and the error path) while
> looking at it.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (8):
>   mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node
>   mwifiex: propagate sdio_enable_func() errno code in
> mwifiex_sdio_probe()
>   mwifiex: propagate mwifiex_add_card() errno code in
> mwifiex_sdio_probe()
>   mwifiex: consolidate mwifiex_sdio_probe() error paths
>   mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()
>   mwifiex: check if mwifiex_sdio_probe_of() fails and return error
>   mwifiex: don't print an error if an optional DT property is missing
>   mwifiex: use better message and error code when OF node doesn't match
> 
>  drivers/net/wireless/marvell/mwifiex/sdio.c | 46 ++
> ---
>  1 file changed, 28 insertions(+), 18 deletions(-)
> 

Thanks for fixing the error handling code. These patches look fine to me.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

RE: [PATCH v2] mwifiex: fix race condition when downloading firmware

[Amitkumar Karwar]

> From: Wei-Ning Huang [mailto:wnhu...@chromium.org]
> Sent: Friday, May 27, 2016 5:58 PM
> To: Linux-Wireless
> Cc: LKML; Amitkumar Karwar; djku...@chromium.org; Wei-Ning Huang
> Subject: [PATCH v2] mwifiex: fix race condition when downloading
> firmware
> 
> The action 'check for winner' and 'download firmware' should be an
> atomic action. This is true for btmrvl driver but not mwmfiex, which
> cause firmware download to fail when the following scenario happens:
> 
> 1) mwifiex check winner status: true
> 2) btmrvl check winner status: true, and start downloading firmware
> 3) mwifiex tries to download firmware, but failed because btmrvl is
> already downloading.
> 
> This won't happen if 1) and 3) is an atomic action. This patch adds
> sdio_claim/release_host call around those two actions to make sure it's
> atomic.
> 
> Signed-off-by: Wei-Ning Huang <wnhu...@chromium.org>
> ---
>  drivers/net/wireless/marvell/mwifiex/init.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c
> b/drivers/net/wireless/marvell/mwifiex/init.c
> index 78c532f..7703438 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -24,6 +24,7 @@
>  #include "main.h"
>  #include "wmm.h"
>  #include "11n.h"
> +#include "sdio.h"
> 
>  /*
>   * This function adds a BSS priority table to the table list.
> @@ -737,16 +738,20 @@ mwifiex_shutdown_drv(struct mwifiex_adapter
> *adapter)  int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
>   struct mwifiex_fw_image *pmfw)
>  {
> + struct sdio_mmc_card *card = adapter->card;
>   int ret;
>   u32 poll_num = 1;
> 
> + if (adapter->iface_type == MWIFIEX_SDIO)
> + sdio_claim_host(card->func);
> +
>   if (adapter->if_ops.check_fw_status) {
>   /* check if firmware is already running */
>   ret = adapter->if_ops.check_fw_status(adapter, poll_num);
>   if (!ret) {
>   mwifiex_dbg(adapter, MSG,
>   "WLAN FW already running! Skip FW dnld\n");
> - return 0;
> + goto release_host;
>   }
>   }
> 
> @@ -759,7 +764,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
>   if (ret) {
>   mwifiex_dbg(adapter, MSG,
>   "WLAN read winner status failed!\n");
> - return ret;
> + goto release_host;
>   }
> 
>   if (!adapter->winner) {
> @@ -775,7 +780,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
>   if (ret) {
>   mwifiex_dbg(adapter, ERROR,
>   "prog_fw failed ret=%#x\n", ret);
> - return ret;
> + goto release_host;
>   }
>   }
> 
> @@ -785,6 +790,9 @@ poll_fw:
>   if (ret)
>   mwifiex_dbg(adapter, ERROR,
>   "FW failed to be active in time\n");
> +release_host:
> + if (adapter->iface_type == MWIFIEX_SDIO)
> + sdio_release_host(card->func);
> 
>   return ret;
>  }
> --
> 2.1.2

Patch looks fine to me.

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH v2] mwifiex: fix race condition when downloading firmware

[Amitkumar Karwar]

> From: Wei-Ning Huang [mailto:wnhu...@chromium.org]
> Sent: Friday, May 27, 2016 5:58 PM
> To: Linux-Wireless
> Cc: LKML; Amitkumar Karwar; djku...@chromium.org; Wei-Ning Huang
> Subject: [PATCH v2] mwifiex: fix race condition when downloading
> firmware
> 
> The action 'check for winner' and 'download firmware' should be an
> atomic action. This is true for btmrvl driver but not mwmfiex, which
> cause firmware download to fail when the following scenario happens:
> 
> 1) mwifiex check winner status: true
> 2) btmrvl check winner status: true, and start downloading firmware
> 3) mwifiex tries to download firmware, but failed because btmrvl is
> already downloading.
> 
> This won't happen if 1) and 3) is an atomic action. This patch adds
> sdio_claim/release_host call around those two actions to make sure it's
> atomic.
> 
> Signed-off-by: Wei-Ning Huang 
> ---
>  drivers/net/wireless/marvell/mwifiex/init.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c
> b/drivers/net/wireless/marvell/mwifiex/init.c
> index 78c532f..7703438 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -24,6 +24,7 @@
>  #include "main.h"
>  #include "wmm.h"
>  #include "11n.h"
> +#include "sdio.h"
> 
>  /*
>   * This function adds a BSS priority table to the table list.
> @@ -737,16 +738,20 @@ mwifiex_shutdown_drv(struct mwifiex_adapter
> *adapter)  int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
>   struct mwifiex_fw_image *pmfw)
>  {
> + struct sdio_mmc_card *card = adapter->card;
>   int ret;
>   u32 poll_num = 1;
> 
> + if (adapter->iface_type == MWIFIEX_SDIO)
> + sdio_claim_host(card->func);
> +
>   if (adapter->if_ops.check_fw_status) {
>   /* check if firmware is already running */
>   ret = adapter->if_ops.check_fw_status(adapter, poll_num);
>   if (!ret) {
>   mwifiex_dbg(adapter, MSG,
>   "WLAN FW already running! Skip FW dnld\n");
> - return 0;
> + goto release_host;
>   }
>   }
> 
> @@ -759,7 +764,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
>   if (ret) {
>   mwifiex_dbg(adapter, MSG,
>   "WLAN read winner status failed!\n");
> - return ret;
> + goto release_host;
>   }
> 
>   if (!adapter->winner) {
> @@ -775,7 +780,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
>   if (ret) {
>   mwifiex_dbg(adapter, ERROR,
>   "prog_fw failed ret=%#x\n", ret);
> - return ret;
> + goto release_host;
>   }
>   }
> 
> @@ -785,6 +790,9 @@ poll_fw:
>   if (ret)
>   mwifiex_dbg(adapter, ERROR,
>   "FW failed to be active in time\n");
> +release_host:
> + if (adapter->iface_type == MWIFIEX_SDIO)
> + sdio_release_host(card->func);
> 
>   return ret;
>  }
> --
> 2.1.2

Patch looks fine to me.

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

RE: [PATCH 1/1] mwifiex: illegal assignment

[Amitkumar Karwar]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Wednesday, May 18, 2016 4:32 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: Xinming Hu; Cathy Luo; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Heinrich
> Schuchardt
> Subject: [PATCH 1/1] mwifiex: illegal assignment
> 
> Variable adapter is incorrectly initialized.
> 
> Fixes: bf00dc22bc7a ("mwifiex: AMSDU Rx frame handling in AP mode")
> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> ---
>  drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> index 666e91a..bf5660e 100644
> --- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> +++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> @@ -272,7 +272,7 @@ int mwifiex_handle_uap_rx_forward(struct
> mwifiex_private *priv,  int mwifiex_uap_recv_packet(struct
> mwifiex_private *priv,
>   struct sk_buff *skb)
>  {
> - struct mwifiex_adapter *adapter = adapter;
> + struct mwifiex_adapter *adapter = priv->adapter;
>   struct mwifiex_sta_node *src_node;
>   struct ethhdr *p_ethhdr;
>   struct sk_buff *skb_uap;
> --
> 2.1.4

Acked-by: Amitkumar Karwar <akar...@marvell.com>

Regards,
Amitkumar

RE: [PATCH 1/1] mwifiex: illegal assignment

[Amitkumar Karwar]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Wednesday, May 18, 2016 4:32 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo
> Cc: Xinming Hu; Cathy Luo; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Heinrich
> Schuchardt
> Subject: [PATCH 1/1] mwifiex: illegal assignment
> 
> Variable adapter is incorrectly initialized.
> 
> Fixes: bf00dc22bc7a ("mwifiex: AMSDU Rx frame handling in AP mode")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> index 666e91a..bf5660e 100644
> --- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> +++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> @@ -272,7 +272,7 @@ int mwifiex_handle_uap_rx_forward(struct
> mwifiex_private *priv,  int mwifiex_uap_recv_packet(struct
> mwifiex_private *priv,
>   struct sk_buff *skb)
>  {
> - struct mwifiex_adapter *adapter = adapter;
> + struct mwifiex_adapter *adapter = priv->adapter;
>   struct mwifiex_sta_node *src_node;
>   struct ethhdr *p_ethhdr;
>   struct sk_buff *skb_uap;
> --
> 2.1.4

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar

RE: mwifiex: fix self-assignment in mwifiex_uap_recv_packet

[Amitkumar Karwar]

Hi Dave,

> From: Dave Jones [mailto:da...@codemonkey.org.uk]
> Sent: Tuesday, May 31, 2016 8:47 PM
> To: Linux Kernel
> Cc: Xinming Hu; Cathy Luo; Amitkumar Karwar; Kalle Valo
> Subject: mwifiex: fix self-assignment in mwifiex_uap_recv_packet
> 
> This function wants to operate on the adapter pointer in the priv
> struct, not on itself which makes no sense.
> 
> Signed-off-by: Dave Jones <da...@codemonkey.org.uk>
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> index 666e91af59d7..bf5660eb27d3 100644
> --- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> +++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> @@ -272,7 +272,7 @@ int mwifiex_handle_uap_rx_forward(struct
> mwifiex_private *priv,  int mwifiex_uap_recv_packet(struct
> mwifiex_private *priv,
>   struct sk_buff *skb)
>  {
> - struct mwifiex_adapter *adapter = adapter;
> + struct mwifiex_adapter *adapter = priv->adapter;
>   struct mwifiex_sta_node *src_node;
>   struct ethhdr *p_ethhdr;
>   struct sk_buff *skb_uap;

Thanks for the patch. This has been already taken cared by below patch 
submitted recently.
https://patchwork.kernel.org/patch/9115501/

Regards,
Amitkumar

RE: mwifiex: fix self-assignment in mwifiex_uap_recv_packet

[Amitkumar Karwar]

Hi Dave,

> From: Dave Jones [mailto:da...@codemonkey.org.uk]
> Sent: Tuesday, May 31, 2016 8:47 PM
> To: Linux Kernel
> Cc: Xinming Hu; Cathy Luo; Amitkumar Karwar; Kalle Valo
> Subject: mwifiex: fix self-assignment in mwifiex_uap_recv_packet
> 
> This function wants to operate on the adapter pointer in the priv
> struct, not on itself which makes no sense.
> 
> Signed-off-by: Dave Jones 
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> index 666e91af59d7..bf5660eb27d3 100644
> --- a/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> +++ b/drivers/net/wireless/marvell/mwifiex/uap_txrx.c
> @@ -272,7 +272,7 @@ int mwifiex_handle_uap_rx_forward(struct
> mwifiex_private *priv,  int mwifiex_uap_recv_packet(struct
> mwifiex_private *priv,
>   struct sk_buff *skb)
>  {
> - struct mwifiex_adapter *adapter = adapter;
> + struct mwifiex_adapter *adapter = priv->adapter;
>   struct mwifiex_sta_node *src_node;
>   struct ethhdr *p_ethhdr;
>   struct sk_buff *skb_uap;

Thanks for the patch. This has been already taken cared by below patch 
submitted recently.
https://patchwork.kernel.org/patch/9115501/

Regards,
Amitkumar

RE: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Marcel,
 
> > From: Amitkumar Karwar [mailto:akar...@marvell.com]
> > Sent: Friday, May 06, 2016 9:02 PM
> > To: linux-blueto...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Amitkumar Karwar
> > Subject: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware
> > download for Marvell
> >
> > From: Ganapathi Bhat <gb...@marvell.com>
> >
> > This patch implement firmware download feature for Marvell Bluetooth
> > devices. If firmware is already downloaded, it will skip downloading.
> >
> > Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> > ---
> > v2: Fixed compilation warning reported by kbuild test robot
> > v3: Addressed review comments from Marcel Holtmann
> > a) Removed vendor specific code from hci_ldisc.c
> > b) Get rid of static forward declaration
> > c) Removed unnecessary heavy nesting
> > d) Git rid of module parameter and global variables
> > e) Add logic to pick right firmware image
> > v4: Addresses review comments from Alan
> > a) Use existing kernel helper APIs instead of writing own.
> > b) Replace mdelay() with msleep()
> > v5: Addresses review comments from Loic Poulain
> > a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> > b) Used static functions where required and removed forward
> > delcarations
> > c) Edited comments for the function hci_uart_recv_data
> > d) Made HCI_UART_DNLD_FW flag a part of driver private data
> > v6: Addresses review comments from Loic Poulain
> > a) Used skb instead of array to store firmware data during
> download
> > b) Used hci_uart_tx_wakeup and enqueued packets instead of tty
> write
> > c) Used GFP_KERNEL instead of GFP_ATOMIC
> > v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> > resolves
> > errors reported by kbuild test robot.
> > v8: Addressed review comments from Marcel Holtmann
> > a) Removed unnecessary memory allocation failure messages
> > b) Get rid of btmrvl.h header file and add definitions in
> > hci_mrvl.c file
> > v9: Addressed review comments from Marcel Holtmann
> > a) Moved firmware download code from setup to prepare handler.
> > b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> > during firmware
> >  download.
> > v10: Addressed review comments from Marcel Holtmann
> > a) Added new callback recv_for_prepare to receive data from device
> >  during prepare phase
> > b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> > callback is
> >  added for the same purpose
> > c) Used kernel API to handle unaligned data
> > d) Moved mrvl_set_baud functionality inside setup callback
> > v11: Write data through ldisc in mrvl_send_ack() instead of directly
> > calling
> > write method(One Thousand Gnomes).
> 

Could you please take this patch?

Regards,
Amitkumar

RE: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Marcel,
 
> > From: Amitkumar Karwar [mailto:akar...@marvell.com]
> > Sent: Friday, May 06, 2016 9:02 PM
> > To: linux-blueto...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Amitkumar Karwar
> > Subject: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware
> > download for Marvell
> >
> > From: Ganapathi Bhat 
> >
> > This patch implement firmware download feature for Marvell Bluetooth
> > devices. If firmware is already downloaded, it will skip downloading.
> >
> > Signed-off-by: Ganapathi Bhat 
> > Signed-off-by: Amitkumar Karwar 
> > ---
> > v2: Fixed compilation warning reported by kbuild test robot
> > v3: Addressed review comments from Marcel Holtmann
> > a) Removed vendor specific code from hci_ldisc.c
> > b) Get rid of static forward declaration
> > c) Removed unnecessary heavy nesting
> > d) Git rid of module parameter and global variables
> > e) Add logic to pick right firmware image
> > v4: Addresses review comments from Alan
> > a) Use existing kernel helper APIs instead of writing own.
> > b) Replace mdelay() with msleep()
> > v5: Addresses review comments from Loic Poulain
> > a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> > b) Used static functions where required and removed forward
> > delcarations
> > c) Edited comments for the function hci_uart_recv_data
> > d) Made HCI_UART_DNLD_FW flag a part of driver private data
> > v6: Addresses review comments from Loic Poulain
> > a) Used skb instead of array to store firmware data during
> download
> > b) Used hci_uart_tx_wakeup and enqueued packets instead of tty
> write
> > c) Used GFP_KERNEL instead of GFP_ATOMIC
> > v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> > resolves
> > errors reported by kbuild test robot.
> > v8: Addressed review comments from Marcel Holtmann
> > a) Removed unnecessary memory allocation failure messages
> > b) Get rid of btmrvl.h header file and add definitions in
> > hci_mrvl.c file
> > v9: Addressed review comments from Marcel Holtmann
> > a) Moved firmware download code from setup to prepare handler.
> > b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> > during firmware
> >  download.
> > v10: Addressed review comments from Marcel Holtmann
> > a) Added new callback recv_for_prepare to receive data from device
> >  during prepare phase
> > b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> > callback is
> >  added for the same purpose
> > c) Used kernel API to handle unaligned data
> > d) Moved mrvl_set_baud functionality inside setup callback
> > v11: Write data through ldisc in mrvl_send_ack() instead of directly
> > calling
> > write method(One Thousand Gnomes).
> 

Could you please take this patch?

Regards,
Amitkumar

RE: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> Sent: Friday, May 06, 2016 9:02 PM
> To: linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Amitkumar Karwar
> Subject: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download
> for Marvell
> 
> From: Ganapathi Bhat <gb...@marvell.com>
> 
> This patch implement firmware download feature for Marvell Bluetooth
> devices. If firmware is already downloaded, it will skip downloading.
> 
> Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
> Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
> ---
> v2: Fixed compilation warning reported by kbuild test robot
> v3: Addressed review comments from Marcel Holtmann
> a) Removed vendor specific code from hci_ldisc.c
> b) Get rid of static forward declaration
> c) Removed unnecessary heavy nesting
> d) Git rid of module parameter and global variables
> e) Add logic to pick right firmware image
> v4: Addresses review comments from Alan
> a) Use existing kernel helper APIs instead of writing own.
> b) Replace mdelay() with msleep()
> v5: Addresses review comments from Loic Poulain
> a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> b) Used static functions where required and removed forward
> delcarations
> c) Edited comments for the function hci_uart_recv_data
> d) Made HCI_UART_DNLD_FW flag a part of driver private data
> v6: Addresses review comments from Loic Poulain
> a) Used skb instead of array to store firmware data during download
> b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
> c) Used GFP_KERNEL instead of GFP_ATOMIC
> v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> resolves
> errors reported by kbuild test robot.
> v8: Addressed review comments from Marcel Holtmann
> a) Removed unnecessary memory allocation failure messages
> b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c
> file
> v9: Addressed review comments from Marcel Holtmann
> a) Moved firmware download code from setup to prepare handler.
> b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> during firmware
>  download.
> v10: Addressed review comments from Marcel Holtmann
> a) Added new callback recv_for_prepare to receive data from device
>  during prepare phase
> b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> callback is
>  added for the same purpose
> c) Used kernel API to handle unaligned data
> d) Moved mrvl_set_baud functionality inside setup callback
> v11: Write data through ldisc in mrvl_send_ack() instead of directly
> calling
> write method(One Thousand Gnomes).

Could you please take this patch if there are no further comments/suggestions 
for improvement?

Regards,
Amitkumar

RE: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Marcel,

> From: Amitkumar Karwar [mailto:akar...@marvell.com]
> Sent: Friday, May 06, 2016 9:02 PM
> To: linux-blueto...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Ganapathi Bhat; Amitkumar Karwar
> Subject: [PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download
> for Marvell
> 
> From: Ganapathi Bhat 
> 
> This patch implement firmware download feature for Marvell Bluetooth
> devices. If firmware is already downloaded, it will skip downloading.
> 
> Signed-off-by: Ganapathi Bhat 
> Signed-off-by: Amitkumar Karwar 
> ---
> v2: Fixed compilation warning reported by kbuild test robot
> v3: Addressed review comments from Marcel Holtmann
> a) Removed vendor specific code from hci_ldisc.c
> b) Get rid of static forward declaration
> c) Removed unnecessary heavy nesting
> d) Git rid of module parameter and global variables
> e) Add logic to pick right firmware image
> v4: Addresses review comments from Alan
> a) Use existing kernel helper APIs instead of writing own.
> b) Replace mdelay() with msleep()
> v5: Addresses review comments from Loic Poulain
> a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
> b) Used static functions where required and removed forward
> delcarations
> c) Edited comments for the function hci_uart_recv_data
> d) Made HCI_UART_DNLD_FW flag a part of driver private data
> v6: Addresses review comments from Loic Poulain
> a) Used skb instead of array to store firmware data during download
> b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
> c) Used GFP_KERNEL instead of GFP_ATOMIC
> v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change
> resolves
> errors reported by kbuild test robot.
> v8: Addressed review comments from Marcel Holtmann
> a) Removed unnecessary memory allocation failure messages
> b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c
> file
> v9: Addressed review comments from Marcel Holtmann
> a) Moved firmware download code from setup to prepare handler.
> b) Change messages from bt_dev_*->BT_*, as hdev isn't available
> during firmware
>  download.
> v10: Addressed review comments from Marcel Holtmann
> a) Added new callback recv_for_prepare to receive data from device
>  during prepare phase
> b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive
> callback is
>  added for the same purpose
> c) Used kernel API to handle unaligned data
> d) Moved mrvl_set_baud functionality inside setup callback
> v11: Write data through ldisc in mrvl_send_ack() instead of directly
> calling
> write method(One Thousand Gnomes).

Could you please take this patch if there are no further comments/suggestions 
for improvement?

Regards,
Amitkumar

[PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

This patch implement firmware download feature for
Marvell Bluetooth devices. If firmware is already
downloaded, it will skip downloading.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
v2: Fixed compilation warning reported by kbuild test robot
v3: Addressed review comments from Marcel Holtmann
a) Removed vendor specific code from hci_ldisc.c
b) Get rid of static forward declaration
c) Removed unnecessary heavy nesting
d) Git rid of module parameter and global variables
e) Add logic to pick right firmware image
v4: Addresses review comments from Alan
a) Use existing kernel helper APIs instead of writing own.
b) Replace mdelay() with msleep()
v5: Addresses review comments from Loic Poulain
a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
b) Used static functions where required and removed forward delcarations
c) Edited comments for the function hci_uart_recv_data
d) Made HCI_UART_DNLD_FW flag a part of driver private data
v6: Addresses review comments from Loic Poulain
a) Used skb instead of array to store firmware data during download
b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
c) Used GFP_KERNEL instead of GFP_ATOMIC
v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change resolves
errors reported by kbuild test robot.
v8: Addressed review comments from Marcel Holtmann
a) Removed unnecessary memory allocation failure messages
b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c file
v9: Addressed review comments from Marcel Holtmann
a) Moved firmware download code from setup to prepare handler.
b) Change messages from bt_dev_*->BT_*, as hdev isn't available during 
firmware
 download.
v10: Addressed review comments from Marcel Holtmann
a) Added new callback recv_for_prepare to receive data from device
 during prepare phase
b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive callback is
 added for the same purpose
c) Used kernel API to handle unaligned data
d) Moved mrvl_set_baud functionality inside setup callback
v11: Write data through ldisc in mrvl_send_ack() instead of directly calling
write method(One Thousand Gnomes).
---
 drivers/bluetooth/Kconfig |  11 +
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/hci_ldisc.c |   6 +
 drivers/bluetooth/hci_mrvl.c  | 543 ++
 drivers/bluetooth/hci_uart.h  |   8 +-
 5 files changed, 568 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/hci_mrvl.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index cf50fd2..daafd0c 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
 
  Say Y here to compile support for Intel AG6XX protocol.
 
+config BT_HCIUART_MRVL
+   bool "Marvell protocol support"
+   depends on BT_HCIUART
+   select BT_HCIUART_H4
+   help
+ Marvell is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for most Marvell Bluetooth
+ devices with UART interface.
+
+ Say Y here to compile support for HCI MRVL protocol.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9c18939..364dbb6 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -37,6 +37,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
 hci_uart-$(CONFIG_BT_HCIUART_BCM)  += hci_bcm.o
 hci_uart-$(CONFIG_BT_HCIUART_QCA)  += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
+hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
 
 ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 047e786..4896b6f 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -821,6 +821,9 @@ static int __init hci_uart_init(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_init();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_init();
+#endif
 
return 0;
 }
@@ -856,6 +859,9 @@ static void __exit hci_uart_exit(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_deinit();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_deinit();
+#endif
 
/* Release tty registration of line discipline */
err = tty_unregister_ldisc(N_HCI);
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
new file mode 100644
index 000..2686901
--- /dev/null
+++ b/drivers/bluetooth/hci_mrvl.c
@@ -0,0 +1,543 @@
+/* Bluetooth HCI UART driver for Marvell devices
+ *
+ * Copyright (C) 2016, Marvell International Ltd.

[PATCH v11 2/3] Bluetooth: hci_uart: check if hdev is present before using it

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

The hdev struct might not have initialized in protocol receive handler.
This patch adds necessary checks.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/hci_ldisc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index b4ee682..047e786 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -154,7 +154,9 @@ restart:
 
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
len = tty->ops->write(tty, skb->data, skb->len);
-   hdev->stat.byte_tx += len;
+
+   if (hdev)
+   hdev->stat.byte_tx += len;
 
skb_pull(skb, len);
if (skb->len) {
@@ -349,7 +351,7 @@ void hci_uart_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, );
 
-   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
+   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev ? hu->hdev->name : "",
   tty->termios.c_ispeed, tty->termios.c_ospeed);
 }
 
-- 
1.8.1.4

[PATCH v11 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

From: Ganapathi Bhat 

This patch implement firmware download feature for
Marvell Bluetooth devices. If firmware is already
downloaded, it will skip downloading.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
v2: Fixed compilation warning reported by kbuild test robot
v3: Addressed review comments from Marcel Holtmann
a) Removed vendor specific code from hci_ldisc.c
b) Get rid of static forward declaration
c) Removed unnecessary heavy nesting
d) Git rid of module parameter and global variables
e) Add logic to pick right firmware image
v4: Addresses review comments from Alan
a) Use existing kernel helper APIs instead of writing own.
b) Replace mdelay() with msleep()
v5: Addresses review comments from Loic Poulain
a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
b) Used static functions where required and removed forward delcarations
c) Edited comments for the function hci_uart_recv_data
d) Made HCI_UART_DNLD_FW flag a part of driver private data
v6: Addresses review comments from Loic Poulain
a) Used skb instead of array to store firmware data during download
b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
c) Used GFP_KERNEL instead of GFP_ATOMIC
v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change resolves
errors reported by kbuild test robot.
v8: Addressed review comments from Marcel Holtmann
a) Removed unnecessary memory allocation failure messages
b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c file
v9: Addressed review comments from Marcel Holtmann
a) Moved firmware download code from setup to prepare handler.
b) Change messages from bt_dev_*->BT_*, as hdev isn't available during 
firmware
 download.
v10: Addressed review comments from Marcel Holtmann
a) Added new callback recv_for_prepare to receive data from device
 during prepare phase
b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive callback is
 added for the same purpose
c) Used kernel API to handle unaligned data
d) Moved mrvl_set_baud functionality inside setup callback
v11: Write data through ldisc in mrvl_send_ack() instead of directly calling
write method(One Thousand Gnomes).
---
 drivers/bluetooth/Kconfig |  11 +
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/hci_ldisc.c |   6 +
 drivers/bluetooth/hci_mrvl.c  | 543 ++
 drivers/bluetooth/hci_uart.h  |   8 +-
 5 files changed, 568 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/hci_mrvl.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index cf50fd2..daafd0c 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
 
  Say Y here to compile support for Intel AG6XX protocol.
 
+config BT_HCIUART_MRVL
+   bool "Marvell protocol support"
+   depends on BT_HCIUART
+   select BT_HCIUART_H4
+   help
+ Marvell is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for most Marvell Bluetooth
+ devices with UART interface.
+
+ Say Y here to compile support for HCI MRVL protocol.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9c18939..364dbb6 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -37,6 +37,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
 hci_uart-$(CONFIG_BT_HCIUART_BCM)  += hci_bcm.o
 hci_uart-$(CONFIG_BT_HCIUART_QCA)  += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
+hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
 
 ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 047e786..4896b6f 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -821,6 +821,9 @@ static int __init hci_uart_init(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_init();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_init();
+#endif
 
return 0;
 }
@@ -856,6 +859,9 @@ static void __exit hci_uart_exit(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_deinit();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_deinit();
+#endif
 
/* Release tty registration of line discipline */
err = tty_unregister_ldisc(N_HCI);
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
new file mode 100644
index 000..2686901
--- /dev/null
+++ b/drivers/bluetooth/hci_mrvl.c
@@ -0,0 +1,543 @@
+/* Bluetooth HCI UART driver for Marvell devices
+ *
+ * Copyright (C) 2016, Marvell International Ltd.
+ *
+ *  Acknowledgements:
+ *  This file is based on hci_h4.c, which was written
+ 

[PATCH v11 2/3] Bluetooth: hci_uart: check if hdev is present before using it

[Amitkumar Karwar]

From: Ganapathi Bhat 

The hdev struct might not have initialized in protocol receive handler.
This patch adds necessary checks.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/hci_ldisc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index b4ee682..047e786 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -154,7 +154,9 @@ restart:
 
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
len = tty->ops->write(tty, skb->data, skb->len);
-   hdev->stat.byte_tx += len;
+
+   if (hdev)
+   hdev->stat.byte_tx += len;
 
skb_pull(skb, len);
if (skb->len) {
@@ -349,7 +351,7 @@ void hci_uart_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, );
 
-   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
+   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev ? hu->hdev->name : "",
   tty->termios.c_ispeed, tty->termios.c_ospeed);
 }
 
-- 
1.8.1.4

[PATCH v11 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

The new callback is used to prepare the device before HCI becomes
ready. One can use this to download firmware if the download process
doesn't use HCI commands. Also recv_for_prepare callback is
introduced for receiving data from devices during prepare phase.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/hci_ldisc.c | 11 ++-
 drivers/bluetooth/hci_uart.h  |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 49b3e1e..b4ee682 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -551,8 +551,11 @@ static void hci_uart_tty_receive(struct tty_struct *tty, 
const u8 *data,
if (!hu || tty != hu->tty)
return;
 
-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }
 
/* It does not need a lock here as it is already protected by a mutex in
 * tty caller
@@ -639,6 +642,12 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
 
hu->proto = p;
+   if (p->prepare) {
+   err = p->prepare(hu);
+   if (err)
+   return err;
+   }
+
set_bit(HCI_UART_PROTO_READY, >flags);
 
err = hci_uart_register_dev(hu);
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 839bad1..17ba3b4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -67,8 +67,11 @@ struct hci_uart_proto {
int (*close)(struct hci_uart *hu);
int (*flush)(struct hci_uart *hu);
int (*setup)(struct hci_uart *hu);
+   int (*prepare)(struct hci_uart *hu);
int (*set_baudrate)(struct hci_uart *hu, unsigned int speed);
int (*recv)(struct hci_uart *hu, const void *data, int len);
+   int (*recv_for_prepare)(struct hci_uart *hu, const void *data,
+   int len);
int (*enqueue)(struct hci_uart *hu, struct sk_buff *skb);
struct sk_buff *(*dequeue)(struct hci_uart *hu);
 };
-- 
1.8.1.4

[PATCH v11 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

From: Ganapathi Bhat 

The new callback is used to prepare the device before HCI becomes
ready. One can use this to download firmware if the download process
doesn't use HCI commands. Also recv_for_prepare callback is
introduced for receiving data from devices during prepare phase.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/hci_ldisc.c | 11 ++-
 drivers/bluetooth/hci_uart.h  |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 49b3e1e..b4ee682 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -551,8 +551,11 @@ static void hci_uart_tty_receive(struct tty_struct *tty, 
const u8 *data,
if (!hu || tty != hu->tty)
return;
 
-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }
 
/* It does not need a lock here as it is already protected by a mutex in
 * tty caller
@@ -639,6 +642,12 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
 
hu->proto = p;
+   if (p->prepare) {
+   err = p->prepare(hu);
+   if (err)
+   return err;
+   }
+
set_bit(HCI_UART_PROTO_READY, >flags);
 
err = hci_uart_register_dev(hu);
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 839bad1..17ba3b4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -67,8 +67,11 @@ struct hci_uart_proto {
int (*close)(struct hci_uart *hu);
int (*flush)(struct hci_uart *hu);
int (*setup)(struct hci_uart *hu);
+   int (*prepare)(struct hci_uart *hu);
int (*set_baudrate)(struct hci_uart *hu, unsigned int speed);
int (*recv)(struct hci_uart *hu, const void *data, int len);
+   int (*recv_for_prepare)(struct hci_uart *hu, const void *data,
+   int len);
int (*enqueue)(struct hci_uart *hu, struct sk_buff *skb);
struct sk_buff *(*dequeue)(struct hci_uart *hu);
 };
-- 
1.8.1.4

RE: [PATCH v10 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Alan,

> From: One Thousand Gnomes [mailto:gno...@lxorguk.ukuu.org.uk]
> Sent: Thursday, May 05, 2016 8:53 PM
> To: Amitkumar Karwar
> Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Ganapathi Bhat
> Subject: Re: [PATCH v10 3/3] Bluetooth: hci_uart: Support firmware
> download for Marvell
> 
> > +/* Send ACK/NAK to the device */
> > +static void mrvl_send_ack(struct hci_uart *hu, unsigned char ack) {
> > +   struct tty_struct *tty = hu->tty;
> > +
> > +   tty->ops->write(tty, , sizeof(ack)); }
> 
> You don't know if the device has a write method, and it should be
> locked.
> This should go via your ldisc not directly.
> 

Thanks for review. We will take care of this.

Regards,
Amitkumar

RE: [PATCH v10 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

Hi Alan,

> From: One Thousand Gnomes [mailto:gno...@lxorguk.ukuu.org.uk]
> Sent: Thursday, May 05, 2016 8:53 PM
> To: Amitkumar Karwar
> Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Ganapathi Bhat
> Subject: Re: [PATCH v10 3/3] Bluetooth: hci_uart: Support firmware
> download for Marvell
> 
> > +/* Send ACK/NAK to the device */
> > +static void mrvl_send_ack(struct hci_uart *hu, unsigned char ack) {
> > +   struct tty_struct *tty = hu->tty;
> > +
> > +   tty->ops->write(tty, , sizeof(ack)); }
> 
> You don't know if the device has a write method, and it should be
> locked.
> This should go via your ldisc not directly.
> 

Thanks for review. We will take care of this.

Regards,
Amitkumar

RE: [PATCH v10 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

Hi Alan,

> From: linux-bluetooth-ow...@vger.kernel.org [mailto:linux-bluetooth-
> ow...@vger.kernel.org] On Behalf Of One Thousand Gnomes
> Sent: Thursday, May 05, 2016 8:49 PM
> To: Amitkumar Karwar
> Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Ganapathi Bhat
> Subject: Re: [PATCH v10 1/3] Bluetooth: hci_uart: add prepare callbacks
> to hci_uart_proto structure.
> 
> On Thu, 5 May 2016 08:08:20 -0700
> Amitkumar Karwar <akar...@marvell.com> wrote:
> 
> > From: Ganapathi Bhat <gb...@marvell.com>
> >
> > The new callback is used to prepare the device before HCI becomes
> > ready. One can use this to download firmware if the download process
> > doesn't use HCI commands. Also recv_for_prepare callback is introduced
> > for receiving data from devices during prepare phase.
> 
> If your device is not speaking HCI protocol then instead of hackig up
> the HCI ldisc would it not make more sense to have a tiny ldisc for your
> firmware loader instead of adding crap to the fast paths of what is
> currently a clean properly separated out interface ?
> 

Below is the code change. It won't add any overhead for existing receive path. 

-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }

Regards,
Amitkumar

RE: [PATCH v10 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

Hi Alan,

> From: linux-bluetooth-ow...@vger.kernel.org [mailto:linux-bluetooth-
> ow...@vger.kernel.org] On Behalf Of One Thousand Gnomes
> Sent: Thursday, May 05, 2016 8:49 PM
> To: Amitkumar Karwar
> Cc: linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Ganapathi Bhat
> Subject: Re: [PATCH v10 1/3] Bluetooth: hci_uart: add prepare callbacks
> to hci_uart_proto structure.
> 
> On Thu, 5 May 2016 08:08:20 -0700
> Amitkumar Karwar  wrote:
> 
> > From: Ganapathi Bhat 
> >
> > The new callback is used to prepare the device before HCI becomes
> > ready. One can use this to download firmware if the download process
> > doesn't use HCI commands. Also recv_for_prepare callback is introduced
> > for receiving data from devices during prepare phase.
> 
> If your device is not speaking HCI protocol then instead of hackig up
> the HCI ldisc would it not make more sense to have a tiny ldisc for your
> firmware loader instead of adding crap to the fast paths of what is
> currently a clean properly separated out interface ?
> 

Below is the code change. It won't add any overhead for existing receive path. 

-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }

Regards,
Amitkumar

[PATCH v10 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

The new callback is used to prepare the device before HCI becomes
ready. One can use this to download firmware if the download process
doesn't use HCI commands. Also recv_for_prepare callback is
introduced for receiving data from devices during prepare phase.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/hci_ldisc.c | 11 ++-
 drivers/bluetooth/hci_uart.h  |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 49b3e1e..b4ee682 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -551,8 +551,11 @@ static void hci_uart_tty_receive(struct tty_struct *tty, 
const u8 *data,
if (!hu || tty != hu->tty)
return;
 
-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }
 
/* It does not need a lock here as it is already protected by a mutex in
 * tty caller
@@ -639,6 +642,12 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
 
hu->proto = p;
+   if (p->prepare) {
+   err = p->prepare(hu);
+   if (err)
+   return err;
+   }
+
set_bit(HCI_UART_PROTO_READY, >flags);
 
err = hci_uart_register_dev(hu);
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 839bad1..17ba3b4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -67,8 +67,11 @@ struct hci_uart_proto {
int (*close)(struct hci_uart *hu);
int (*flush)(struct hci_uart *hu);
int (*setup)(struct hci_uart *hu);
+   int (*prepare)(struct hci_uart *hu);
int (*set_baudrate)(struct hci_uart *hu, unsigned int speed);
int (*recv)(struct hci_uart *hu, const void *data, int len);
+   int (*recv_for_prepare)(struct hci_uart *hu, const void *data,
+   int len);
int (*enqueue)(struct hci_uart *hu, struct sk_buff *skb);
struct sk_buff *(*dequeue)(struct hci_uart *hu);
 };
-- 
1.8.1.4

[PATCH v10 1/3] Bluetooth: hci_uart: add prepare callbacks to hci_uart_proto structure.

[Amitkumar Karwar]

From: Ganapathi Bhat 

The new callback is used to prepare the device before HCI becomes
ready. One can use this to download firmware if the download process
doesn't use HCI commands. Also recv_for_prepare callback is
introduced for receiving data from devices during prepare phase.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/hci_ldisc.c | 11 ++-
 drivers/bluetooth/hci_uart.h  |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 49b3e1e..b4ee682 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -551,8 +551,11 @@ static void hci_uart_tty_receive(struct tty_struct *tty, 
const u8 *data,
if (!hu || tty != hu->tty)
return;
 
-   if (!test_bit(HCI_UART_PROTO_READY, >flags))
+   if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
+   if (hu->proto->recv_for_prepare)
+   hu->proto->recv_for_prepare(hu, data, count);
return;
+   }
 
/* It does not need a lock here as it is already protected by a mutex in
 * tty caller
@@ -639,6 +642,12 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
return err;
 
hu->proto = p;
+   if (p->prepare) {
+   err = p->prepare(hu);
+   if (err)
+   return err;
+   }
+
set_bit(HCI_UART_PROTO_READY, >flags);
 
err = hci_uart_register_dev(hu);
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 839bad1..17ba3b4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -67,8 +67,11 @@ struct hci_uart_proto {
int (*close)(struct hci_uart *hu);
int (*flush)(struct hci_uart *hu);
int (*setup)(struct hci_uart *hu);
+   int (*prepare)(struct hci_uart *hu);
int (*set_baudrate)(struct hci_uart *hu, unsigned int speed);
int (*recv)(struct hci_uart *hu, const void *data, int len);
+   int (*recv_for_prepare)(struct hci_uart *hu, const void *data,
+   int len);
int (*enqueue)(struct hci_uart *hu, struct sk_buff *skb);
struct sk_buff *(*dequeue)(struct hci_uart *hu);
 };
-- 
1.8.1.4

[PATCH v10 2/3] Bluetooth: hci_uart: check if hdev is present before using it

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

The hdev struct might not have initialized in protocol receive handler.
This patch adds necessary checks.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
 drivers/bluetooth/hci_ldisc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index b4ee682..047e786 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -154,7 +154,9 @@ restart:
 
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
len = tty->ops->write(tty, skb->data, skb->len);
-   hdev->stat.byte_tx += len;
+
+   if (hdev)
+   hdev->stat.byte_tx += len;
 
skb_pull(skb, len);
if (skb->len) {
@@ -349,7 +351,7 @@ void hci_uart_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, );
 
-   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
+   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev ? hu->hdev->name : "",
   tty->termios.c_ispeed, tty->termios.c_ospeed);
 }
 
-- 
1.8.1.4

[PATCH v10 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

From: Ganapathi Bhat <gb...@marvell.com>

This patch implement firmware download feature for
Marvell Bluetooth devices. If firmware is already
downloaded, it will skip downloading.

Signed-off-by: Ganapathi Bhat <gb...@marvell.com>
Signed-off-by: Amitkumar Karwar <akar...@marvell.com>
---
v2: Fixed compilation warning reported by kbuild test robot
v3: Addressed review comments from Marcel Holtmann
  a) Removed vendor specific code from hci_ldisc.c
  b) Get rid of static forward declaration
  c) Removed unnecessary heavy nesting
  d) Git rid of module parameter and global variables
  e) Add logic to pick right firmware image
v4: Addresses review comments from Alan
  a) Use existing kernel helper APIs instead of writing own.
  b) Replace mdelay() with msleep()
v5: Addresses review comments from Loic Poulain
  a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
  b) Used static functions where required and removed forward delcarations
  c) Edited comments for the function hci_uart_recv_data
  d) Made HCI_UART_DNLD_FW flag a part of driver private data
v6: Addresses review comments from Loic Poulain
  a) Used skb instead of array to store firmware data during download
  b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
  c) Used GFP_KERNEL instead of GFP_ATOMIC
v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change resolves
   errors reported by kbuild test robot.
v8: Addressed review comments from Marcel Holtmann
  a) Removed unnecessary memory allocation failure messages
  b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c file
v9: Addressed review comments from Marcel Holtmann
  a) Moved firmware download code from setup to prepare handler.
  b) Change messages from bt_dev_*->BT_*, as hdev isn't available during 
firmware
 download.
v10: Addressed review comments from Marcel Holtmann
  a) Added new callback recv_for_prepare to receive data from device
 during prepare phase
  b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive callback is
 added for the same purpose
  c) Used kernel API to handle unaligned data
  d) Moved mrvl_set_baud functionality inside setup callback
---
 drivers/bluetooth/Kconfig |  11 +
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/hci_ldisc.c |   6 +
 drivers/bluetooth/hci_mrvl.c  | 535 ++
 drivers/bluetooth/hci_uart.h  |   8 +-
 5 files changed, 560 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/hci_mrvl.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index cf50fd2..daafd0c 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
 
  Say Y here to compile support for Intel AG6XX protocol.
 
+config BT_HCIUART_MRVL
+   bool "Marvell protocol support"
+   depends on BT_HCIUART
+   select BT_HCIUART_H4
+   help
+ Marvell is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for most Marvell Bluetooth
+ devices with UART interface.
+
+ Say Y here to compile support for HCI MRVL protocol.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9c18939..364dbb6 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -37,6 +37,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
 hci_uart-$(CONFIG_BT_HCIUART_BCM)  += hci_bcm.o
 hci_uart-$(CONFIG_BT_HCIUART_QCA)  += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
+hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
 
 ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 047e786..4896b6f 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -821,6 +821,9 @@ static int __init hci_uart_init(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_init();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_init();
+#endif
 
return 0;
 }
@@ -856,6 +859,9 @@ static void __exit hci_uart_exit(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_deinit();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_deinit();
+#endif
 
/* Release tty registration of line discipline */
err = tty_unregister_ldisc(N_HCI);
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
new file mode 100644
index 000..8416014
--- /dev/null
+++ b/drivers/bluetooth/hci_mrvl.c
@@ -0,0 +1,535 @@
+/* Bluetooth HCI UART driver for Marvell devices
+ *
+ * Copyright (C) 2016, Marvell International Ltd.
+ *
+ *  Acknowledgements:
+ *  This file is based on hci_h4.c, which was written
+ *  by Maxim Krasnyansky and Marcel Holtmann.
+ *
+ * This software file (the "

[PATCH v10 2/3] Bluetooth: hci_uart: check if hdev is present before using it

[Amitkumar Karwar]

From: Ganapathi Bhat 

The hdev struct might not have initialized in protocol receive handler.
This patch adds necessary checks.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
 drivers/bluetooth/hci_ldisc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index b4ee682..047e786 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -154,7 +154,9 @@ restart:
 
set_bit(TTY_DO_WRITE_WAKEUP, >flags);
len = tty->ops->write(tty, skb->data, skb->len);
-   hdev->stat.byte_tx += len;
+
+   if (hdev)
+   hdev->stat.byte_tx += len;
 
skb_pull(skb, len);
if (skb->len) {
@@ -349,7 +351,7 @@ void hci_uart_set_baudrate(struct hci_uart *hu, unsigned 
int speed)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, );
 
-   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
+   BT_DBG("%s: New tty speeds: %d/%d", hu->hdev ? hu->hdev->name : "",
   tty->termios.c_ispeed, tty->termios.c_ospeed);
 }
 
-- 
1.8.1.4

[PATCH v10 3/3] Bluetooth: hci_uart: Support firmware download for Marvell

[Amitkumar Karwar]

From: Ganapathi Bhat 

This patch implement firmware download feature for
Marvell Bluetooth devices. If firmware is already
downloaded, it will skip downloading.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Amitkumar Karwar 
---
v2: Fixed compilation warning reported by kbuild test robot
v3: Addressed review comments from Marcel Holtmann
  a) Removed vendor specific code from hci_ldisc.c
  b) Get rid of static forward declaration
  c) Removed unnecessary heavy nesting
  d) Git rid of module parameter and global variables
  e) Add logic to pick right firmware image
v4: Addresses review comments from Alan
  a) Use existing kernel helper APIs instead of writing own.
  b) Replace mdelay() with msleep()
v5: Addresses review comments from Loic Poulain
  a) Use bt_dev_err/warn/dbg helpers insted of BT_ERR/WARN/DBG
  b) Used static functions where required and removed forward delcarations
  c) Edited comments for the function hci_uart_recv_data
  d) Made HCI_UART_DNLD_FW flag a part of driver private data
v6: Addresses review comments from Loic Poulain
  a) Used skb instead of array to store firmware data during download
  b) Used hci_uart_tx_wakeup and enqueued packets instead of tty write
  c) Used GFP_KERNEL instead of GFP_ATOMIC
v7: Edited Kconfig to add dependency for BT_HCIUART_H4. The change resolves
   errors reported by kbuild test robot.
v8: Addressed review comments from Marcel Holtmann
  a) Removed unnecessary memory allocation failure messages
  b) Get rid of btmrvl.h header file and add definitions in hci_mrvl.c file
v9: Addressed review comments from Marcel Holtmann
  a) Moved firmware download code from setup to prepare handler.
  b) Change messages from bt_dev_*->BT_*, as hdev isn't available during 
firmware
 download.
v10: Addressed review comments from Marcel Holtmann
  a) Added new callback recv_for_prepare to receive data from device
 during prepare phase
  b) Avoided using private flags (HCI_UART_DNLD_FW) as new receive callback is
 added for the same purpose
  c) Used kernel API to handle unaligned data
  d) Moved mrvl_set_baud functionality inside setup callback
---
 drivers/bluetooth/Kconfig |  11 +
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/hci_ldisc.c |   6 +
 drivers/bluetooth/hci_mrvl.c  | 535 ++
 drivers/bluetooth/hci_uart.h  |   8 +-
 5 files changed, 560 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/hci_mrvl.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index cf50fd2..daafd0c 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -180,6 +180,17 @@ config BT_HCIUART_AG6XX
 
  Say Y here to compile support for Intel AG6XX protocol.
 
+config BT_HCIUART_MRVL
+   bool "Marvell protocol support"
+   depends on BT_HCIUART
+   select BT_HCIUART_H4
+   help
+ Marvell is serial protocol for communication between Bluetooth
+ device and host. This protocol is required for most Marvell Bluetooth
+ devices with UART interface.
+
+ Say Y here to compile support for HCI MRVL protocol.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9c18939..364dbb6 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -37,6 +37,7 @@ hci_uart-$(CONFIG_BT_HCIUART_INTEL)   += hci_intel.o
 hci_uart-$(CONFIG_BT_HCIUART_BCM)  += hci_bcm.o
 hci_uart-$(CONFIG_BT_HCIUART_QCA)  += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
+hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
 
 ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 047e786..4896b6f 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -821,6 +821,9 @@ static int __init hci_uart_init(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_init();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_init();
+#endif
 
return 0;
 }
@@ -856,6 +859,9 @@ static void __exit hci_uart_exit(void)
 #ifdef CONFIG_BT_HCIUART_AG6XX
ag6xx_deinit();
 #endif
+#ifdef CONFIG_BT_HCIUART_MRVL
+   mrvl_deinit();
+#endif
 
/* Release tty registration of line discipline */
err = tty_unregister_ldisc(N_HCI);
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
new file mode 100644
index 000..8416014
--- /dev/null
+++ b/drivers/bluetooth/hci_mrvl.c
@@ -0,0 +1,535 @@
+/* Bluetooth HCI UART driver for Marvell devices
+ *
+ * Copyright (C) 2016, Marvell International Ltd.
+ *
+ *  Acknowledgements:
+ *  This file is based on hci_h4.c, which was written
+ *  by Maxim Krasnyansky and Marcel Holtmann.
+ *
+ * This software file (the "File") is distributed by Marvell International
+ * Ltd. under the terms