linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Molton <ian@mnementh.co.uk>
To: Hante Meuleman <hante.meuleman@broadcom.com>,
	Arend Van Spriel <arend.vanspriel@broadcom.com>,
	linux-wireless@vger.kernel.org
Cc: Franky Lin <franky.lin@broadcom.com>, brcm80211-dev-list@broadcom.com
Subject: Re: brcmfmac bus level addressing issues.
Date: Wed, 19 Jul 2017 10:33:47 +0100	[thread overview]
Message-ID: <6b40c7b1-d786-baef-8c82-84412507c956@mnementh.co.uk> (raw)
In-Reply-To: <1ca886ff99c569faad930b6b4d6c0d3f@mail.gmail.com>

On 19/07/17 09:39, Hante Meuleman wrote:
> Dear Ian,

Hi,

> Stuff like " The PCIe code sets the window *regardless* of wether its
> changed, on *every single* write." Is totally incorrect. Sure if you limit
> yourself to the function brcmf_pcie_buscore_{read,write}32(). But you
> talked about performance, and msgbuf prototocol is where performance
> counts and that don't use those functions. You wrote: " The PCIe code uses
> brcmf_pcie_select_core(), which, ultimately, appears to be totally
> redundant" and that is simply not true.

This actually kinda underlines my point - at the time I was, as you say,
referring to the _{read,write}32() functions (which is where I'd been
cleaning up in the sdio code too.

> So I decided to answer that mail
> and provoke you a bit. I'm sorry for that, I shouldn't have done that.

Fair enough. I lost my cool in my reply to that too, so lets just start
again. Fair?

> You obviously spent some time on creating all these patches, but why
> provoke/agitate people? Why use such strong words? You may not consider
> them personally, but I just explained why I do. Can you at least
> understand that?

Sorry it came over as personal. Its not. And yes, it sometimes hurts
when people are critical about code you've written - and I've been on
the receiving end of it before now - and they were correct, and I was
wrong at the time. It has to be said though - that code is not pretty
(sdio side in particular - as mentioned before, the PCIe side is a fair
bit better).

> Just some word of advice and then I hope we can leave it to that.
Yes, lets.

-Ian

  reply	other threads:[~2017-07-19  9:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-18  9:45 RFC: brcmfmac bus level addressing issues Ian Molton
2017-07-18 10:35 ` Hante Meuleman
2017-07-18 11:27   ` Ian Molton
     [not found]     ` <6fe08666ca09bf3c1d4476fdad8ce97a@mail.gmail.com>
     [not found]       ` <222e2bc1-4d8f-8133-4fa7-51a48f3de785@mnementh.co.uk>
2017-07-18 15:14         ` Ian Molton
2017-07-18 20:44           ` Arend van Spriel
2017-07-18 22:45             ` Ian Molton
2017-07-19  8:39               ` Hante Meuleman
2017-07-19  9:33                 ` Ian Molton [this message]
2017-07-19 11:47               ` Arend van Spriel
2017-07-19 19:25                 ` Ian Molton

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=6b40c7b1-d786-baef-8c82-84412507c956@mnementh.co.uk \
    --to=ian@mnementh.co.uk \
    --cc=arend.vanspriel@broadcom.com \
    --cc=brcm80211-dev-list@broadcom.com \
    --cc=franky.lin@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=linux-wireless@vger.kernel.org \
    /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).