linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Luca Coelho <luca@coelho.fi>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
	linux-wireless@vger.kernel.org,
	Matti Gottlieb <matti.gottlieb@intel.com>
Subject: Re: [PATCH 2/2] iwlwifi: mvm: Fix paging memory leak
Date: Sun, 06 Mar 2016 14:03:22 +0200	[thread overview]
Message-ID: <878u1vx185.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <1457120732.28365.166.camel@coelho.fi> (Luca Coelho's message of "Fri, 04 Mar 2016 21:45:32 +0200")

Luca Coelho <luca@coelho.fi> writes:

> On Fri, 2016-03-04 at 18:07 +0200, Kalle Valo wrote:
>> Emmanuel Grumbach <emmanuel.grumbach@intel.com> writes:
>> 
>> > From: Matti Gottlieb <matti.gottlieb@intel.com>
>> > 
>> > If the opmode is stopped and started again we did not free
>> > the paging buffers. Fix that.
>> > In addition when freeing the firmware's paging download
>> > buffer, set the pointer to NULL.
>> > 
>> > Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
>> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>> 
>> Nitpicking while writing the pull request for Dave:
>> 
>> What does "opmode is stopped" mean? Important bug fixes should have a
>> clear bug description from user's point of view. Using driver internal
>> jargon is gibberish to most people.
>
> I agree that there could be a bit more high-level description here, but
> I also think it's good to keep a bit more details about what is
> happening internally, so that developers understand too. ;)

Sure, feel free to write as much as you want and in such detail as you
think is necessary :) Just having a clear summary without internal
jargon helps people outside of iwlwifi.

BTW, the other iwlwifi fix had a bit similar problem:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=fb896c44f88a75843a072cd6961b1615732f7811

What does "non-sta" mean in this context? Is it the AP or what? Or
something not part of the current BSS? I guess I might find a definition
from the spec or from iwlwifi sources but I really should not be forced
to do that.

> Do you think it would be acceptable to keep the commit log most as it
> is, but start with something like "Some paging buffers were not freed
> when the driver is restarted."? I don't mean to change this commit
> itself, but just so that we know how to please you (and users) while
> still keeping the details as part of the commit logs... ;)

That sounds good to me. What I'm after is that someone like Dave or
Linus can understand from the commit log what kind of bug this patch is
fixing, without looking into source or checking mailing lists. This is
especially more important in the later stages of the cycle.

>> I investigated this myself and apparently "opmode" is stopped when the
>> module is unloaded or the PCI device is removed. So just say that in the
>> commit log and everyone understand much better.
>
> Our driver is divided roughly into two layers: the bus layer (called
> transport) and the protocol layer (called opmode).  The name comes from
> the difference between the two opmodes that we currently have.  One
> supports only a single operating channel (dvm) and the other supports
> multiple operating channels (mvm).
>
> Hope this clarifies a bit. :)

It did, thanks.

-- 
Kalle Valo

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

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-25 20:56 pull request: iwlwifi 2016-02-25 Grumbach, Emmanuel
2016-02-25 20:57 ` [PATCH 1/2] iwlwifi: mvm: inc pending frames counter also when txing non-sta Emmanuel Grumbach
2016-02-25 20:57 ` [PATCH 2/2] iwlwifi: mvm: Fix paging memory leak Emmanuel Grumbach
2016-03-04 16:07   ` Kalle Valo
2016-03-04 19:45     ` Luca Coelho
2016-03-06 12:03       ` Kalle Valo [this message]
2016-03-06 13:49         ` Grumbach, Emmanuel
2016-02-26 10:46 ` pull request: iwlwifi 2016-02-25 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=878u1vx185.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=emmanuel.grumbach@intel.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luca@coelho.fi \
    --cc=matti.gottlieb@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).