On 19/07/17 12:47, Arend van Spriel wrote:
> On 19-07-17 00:45, Ian Molton wrote:
>> (as it stands, back to back wpasuplpicant runs make it keel over, as
>> does module unload and reload).
>
> It is good to get such feedback. We should get in details about this.
I'll reply with a couple of logs
On 19-07-17 00:45, Ian Molton wrote:
[...]
> Fair enough - I guess now that its in the kernel it needs fixing before
> 4.13 - but I would argue that no new features should go into the driver
> for the short term once that is done. Lets give it a good spring clean.
>
> I am, actually, able to put
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 perf
iginal Message-
From: Ian Molton [mailto:i...@mnementh.co.uk]
Sent: Wednesday, July 19, 2017 12:45 AM
To: Arend van Spriel; linux-wireless@vger.kernel.org
Cc: Franky Lin; brcm80211-dev-l...@broadcom.com; Hante Meuleman
Subject: Re: brcmfmac bus level addressing issues.
On 18/07/17 21:44, Arend va
). Get it stable, make it a
shining example of how to do WiFi.
Deal?
-Ian
>
> Regards,
> Arend
>
>>> -Ian
>>>
>>>>
>>>> Regards, Hante
>>>>
>>>> -Original Message-----
>>>> From: Ian Molton [mailto:i...@mnemen
t; spelling error in a commit message, one dangling variable, and some
>> minor shenannigans around f0 writes which needs a trivial re-work for
>> compliance with the linux mmc framework (I should use a QUIRK for the
>> func0 accesses - although the original driver code was worse an
some
> minor shenannigans around f0 writes which needs a trivial re-work for
> compliance with the linux mmc framework (I should use a QUIRK for the
> func0 accesses - although the original driver code was worse and
> actively worked around the quirk instead). I will re-spin and post
On 18/07/17 11:35, Hante Meuleman wrote:
> Hi Ian,
>
> I've really no idea what you mean.
You should look at the code...
> brcmf_pcie_select_core is redundant?
Essentially yes - there may be a couple of corner cases where the IO
accesses are not performed via brcmf_pcie_buscore_{read,write}32()
nd Van Spriel; Franky Lin; Hante Meuleman
Subject: RFC: brcmfmac bus level addressing issues.
Hi folks,
Its come to my attention that there is a substantial disparity between the
PCIe and SDIO variants of the driver when it comes to handlign writes via
the backplane.
The SDIO bus code checks, u
Hi folks,
Its come to my attention that there is a substantial disparity between
the PCIe and SDIO variants of the driver when it comes to handlign
writes via the backplane.
The SDIO bus code checks, upon every (32 bit) access, wether the
backplane window is in the right place, and only updates i
10 matches
Mail list logo
