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
next prev parent 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).