All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rajkumar Manoharan <rmanohar@codeaurora.org>
To: Ben Greear <greearb@candelatech.com>
Cc: linux-wireless@vger.kernel.org,
	Rajkumar Manoharan <rmanohar@qti.qualcomm.com>,
	ath10k@lists.infradead.org
Subject: Re: [PATCH 2/2] ath10k: remove 10.1 firmware support
Date: Fri, 03 Jun 2016 21:58:28 +0530	[thread overview]
Message-ID: <0ec837e1ff03d8a7df8bc06ebca7c635@codeaurora.org> (raw)
In-Reply-To: <5751AB3F.2070604@candelatech.com>

On 2016-06-03 21:37, Ben Greear wrote:
> On 06/03/2016 08:55 AM, Rajkumar Manoharan wrote:
>> On 2016-06-03 21:18, Ben Greear wrote:
>>> On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
>>>> Earlier qca9888 device was brought up using 10.1 firmware and then
>>>> later all firmware fixes and new features are migrated to 
>>>> 10.2/10.2.x
>>>> firmware branch. As all of 10.1 funtionalities are supported in 10.2
>>>> based firmware, removing 10.1 firmware support for qca9888 device.
>>> 
>>> Oh please do not do this.  My 10.1 firmware works very nicely,
>>> and out-performs 10.2 in my testing.  Lots of people use my firmware
>>> when they need IBSS support or other features not found in
>>> official firmware, so it is not just me that will have
>>> problems if you remove this support.
>>> 
>> Aah.. I thought CT firmware is 10.2 based. Since most of firmware bug 
>> fixes and enhancements are integrated into 10.2 based firmware, we 
>> thought of get rid of
>> 10.1 firmware to reduce code size. Moreover existing 10.1 official 
>> firmware has known issues. Is it possible to upgrade CT firmware to 
>> 10.2 WMI/HTT interfaces?
> 
> I have a 10.2 firmware too, but it is less stable, performs worse,
> uses more RAM on the NIC (so I can do fewer virtual stations),
> and I am not sure I can squeeze enough RAM out of it to port some
> of the more interesting rate-ctrl fixes from 10.1 to 10.2.
> I have recently started backporting a lot of 10.2.4 changes
> into 10.1, which will aid any users on pre 4.0 kernels since they 
> cannot
> run 10.2.4 firmware w/out backporting.
> 
> I might could make my 10.1 work with a 10.2 driver API, but it would
> take quite a bit of
> effort, way more than what removing 10.1 from the driver saves in my 
> opinion.
> The driver already separates firmware specific logic pretty well, so I
> don't think
> it should be a huge maintenance effort to keep 10.1 support in the 
> driver.
> 
> Maybe you could delete the 10.2 (not 10.2.4) firmware support and gain
> some space that way?  I
> doubt anyone is using that productively....
> 
Nope. There are customers who are still using 10.2.2 firmware. My kind 
advice is that please try to optimize latest firmware. 10.2 is nothing 
but based on 10.1 trunk so there wont be much interface difference... 
Will drop this series as of now...

Kalle,

Please drop this series.. Sorry for the noise.

-Rajkumar


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Rajkumar Manoharan <rmanohar@codeaurora.org>
To: Ben Greear <greearb@candelatech.com>
Cc: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>,
	ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 2/2] ath10k: remove 10.1 firmware support
Date: Fri, 03 Jun 2016 21:58:28 +0530	[thread overview]
Message-ID: <0ec837e1ff03d8a7df8bc06ebca7c635@codeaurora.org> (raw)
In-Reply-To: <5751AB3F.2070604@candelatech.com>

On 2016-06-03 21:37, Ben Greear wrote:
> On 06/03/2016 08:55 AM, Rajkumar Manoharan wrote:
>> On 2016-06-03 21:18, Ben Greear wrote:
>>> On 06/03/2016 08:33 AM, Rajkumar Manoharan wrote:
>>>> Earlier qca9888 device was brought up using 10.1 firmware and then
>>>> later all firmware fixes and new features are migrated to 
>>>> 10.2/10.2.x
>>>> firmware branch. As all of 10.1 funtionalities are supported in 10.2
>>>> based firmware, removing 10.1 firmware support for qca9888 device.
>>> 
>>> Oh please do not do this.  My 10.1 firmware works very nicely,
>>> and out-performs 10.2 in my testing.  Lots of people use my firmware
>>> when they need IBSS support or other features not found in
>>> official firmware, so it is not just me that will have
>>> problems if you remove this support.
>>> 
>> Aah.. I thought CT firmware is 10.2 based. Since most of firmware bug 
>> fixes and enhancements are integrated into 10.2 based firmware, we 
>> thought of get rid of
>> 10.1 firmware to reduce code size. Moreover existing 10.1 official 
>> firmware has known issues. Is it possible to upgrade CT firmware to 
>> 10.2 WMI/HTT interfaces?
> 
> I have a 10.2 firmware too, but it is less stable, performs worse,
> uses more RAM on the NIC (so I can do fewer virtual stations),
> and I am not sure I can squeeze enough RAM out of it to port some
> of the more interesting rate-ctrl fixes from 10.1 to 10.2.
> I have recently started backporting a lot of 10.2.4 changes
> into 10.1, which will aid any users on pre 4.0 kernels since they 
> cannot
> run 10.2.4 firmware w/out backporting.
> 
> I might could make my 10.1 work with a 10.2 driver API, but it would
> take quite a bit of
> effort, way more than what removing 10.1 from the driver saves in my 
> opinion.
> The driver already separates firmware specific logic pretty well, so I
> don't think
> it should be a huge maintenance effort to keep 10.1 support in the 
> driver.
> 
> Maybe you could delete the 10.2 (not 10.2.4) firmware support and gain
> some space that way?  I
> doubt anyone is using that productively....
> 
Nope. There are customers who are still using 10.2.2 firmware. My kind 
advice is that please try to optimize latest firmware. 10.2 is nothing 
but based on 10.1 trunk so there wont be much interface difference... 
Will drop this series as of now...

Kalle,

Please drop this series.. Sorry for the noise.

-Rajkumar


  reply	other threads:[~2016-06-03 16:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03 15:33 [PATCH 1/2] ath10k: handle testmode events for 10.2 based firmware Rajkumar Manoharan
2016-06-03 15:33 ` Rajkumar Manoharan
2016-06-03 15:33 ` [PATCH 2/2] ath10k: remove 10.1 firmware support Rajkumar Manoharan
2016-06-03 15:33   ` Rajkumar Manoharan
2016-06-03 15:48   ` Ben Greear
2016-06-03 15:48     ` Ben Greear
2016-06-03 15:55     ` Rajkumar Manoharan
2016-06-03 15:55       ` Rajkumar Manoharan
2016-06-03 16:07       ` Ben Greear
2016-06-03 16:07         ` Ben Greear
2016-06-03 16:28         ` Rajkumar Manoharan [this message]
2016-06-03 16:28           ` Rajkumar Manoharan
2016-06-03 16:36           ` Ben Greear
2016-06-03 16:36             ` Ben Greear
2016-06-03 16:09       ` Valo, Kalle
2016-06-03 16:09         ` Valo, Kalle
2016-06-03 16:20         ` Ben Greear
2016-06-03 16:20           ` Ben Greear
2016-06-03 16:33           ` Valo, Kalle
2016-06-03 16:33             ` Valo, Kalle
2016-06-03 16:46             ` Ben Greear
2016-06-03 16:46               ` Ben Greear
2016-09-14 12:24 ` [1/2] ath10k: handle testmode events for 10.2 based firmware Kalle Valo
2016-09-14 12:24   ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0ec837e1ff03d8a7df8bc06ebca7c635@codeaurora.org \
    --to=rmanohar@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rmanohar@qti.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.