Re: [PATCH 12/34] brcmfmac: Replace old IO functions with simpler ones.

On 07/08/17 18:55, Ian Molton wrote: > On 07/08/17 12:26, Arend van Spriel wrote: >> On 7/26/2017 10:25 PM, Ian Molton wrote: >>> Primarily this patch removes: >>> >>> brcmf_sdiod_f0_writeb() >>> brcmf_sdiod_reg_write() >>> brcmf_sdiod_reg_read() >> >> Having [patch 30/34] "brcmfmac: Correctly

Re: [PATCH 11/34] brcmfmac: Split brcmf_sdiod_buffrw function up.

On 07/08/17 12:26, Arend van Spriel wrote: >> +err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2, addr, mypkt); >> >> brcmu_pkt_buf_free_skb(mypkt); >> + > > You are keen on sprinkling whitespace here and there. Could you please > use separate patches for that as much as possible.

Re: [PATCH 08/34] brcmfmac: Fix uninitialised variable

On 07/08/17 12:26, Arend van Spriel wrote: > On 7/26/2017 10:25 PM, Ian Molton wrote: >> Unlikely to be a problem, but brcmf_sdiod_regrb() is >> not symmetric with brcmf_sdiod_regrl() in this regard. > > You are pretty keen on symmetry, but you could also remove the > initialization in

Re: [PATCH 06/34] brcmfmac: Remove bandaid for SleepCSR

On 07/08/17 12:25, Arend van Spriel wrote: > On 26-07-17 22:25, Ian Molton wrote: >> Register access code is not the place for band-aid fixes like this. >> If this is a genuine problem, it should be fixed further up in the driver >> stack. > > So lets make it a SDIO debug message for all register

Re: [PATCH 34/34] brcmfmac: Reduce the noise from repeatedly dereferencing common pointers

On 08/08/17 13:29, Arend van Spriel wrote: >> int brcmf_sdio_sleep(struct brcmf_sdio *bus, bool sleep) >> { >> +struct brcmf_sdio_dev *sdiodev = bus->sdiodev; >> +struct sdio_func *func1 = sdiodev->func1; > > Actually only wanted to explicitly mention this one. Probably the > compiler is

Re: [PATCH 31/34] brcmfmac: Remove func0 from function array

On 08/08/17 12:19, Arend van Spriel wrote: >> -sdio_f0_readb((sdiodev)->func[0], (addr), (r)) >> +sdio_f0_readb((sdiodev)->func[1], (addr), (r)) > > There is no reason to keep these any longer as these do not provide any > functionality over the core sdio function unless you consider the

Re: [PATCH 29/34] brcmfmac: stabilise the value of ->sbwad in use for some xfer routines.

On 07/08/17 13:32, Arend van Spriel wrote: > > We actually just need the chipcommon base address so why not have that > here, ie.: > +u32 cc_base; I see no advantage to that - the u32 is the same size as (or not much bigger than the pointer to the struct brcmf_core, and my approach makes it

Re: [PATCH 14/34] brcmfmac: Remove brcmf_sdiod_addrprep()

On 07/08/17 12:27, Arend van Spriel wrote: > On 7/26/2017 10:25 PM, Ian Molton wrote: >> This function has become trivial enough that it may as well be pushed >> into >> its callers, which has the side-benefit of clarifying what's going on. >> >> Remove it, and rename

Re: [PATCH 09/34] brcmfmac: Remove noisy debugging.

On 07/08/17 12:26, Arend van Spriel wrote: > > Needing this debugging does not necessarily means you are doing > something wrong. You may be dealing with hardware that is doing > something wrong and when that happens this debug can be useful. I > frankly hardly ever enable SDIO debug level unless

Re: [PATCH 07/34] brcmfmac: Remove brcmf_sdiod_request_data()

On 07/08/17 18:51, Ian Molton wrote: > On 07/08/17 12:25, Arend van Spriel wrote: >>> Handling of -ENOMEDIUM is altered, but as that's pretty much broken >>> anyway >>> we can ignore that. >> >> Please explain why you think it is broken. > > Not got the code to hand right now, but from memory,

Re: [PATCH 01/34] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()

On 07/08/17 12:25, Arend van Spriel wrote: >> All the other IO functions are the other way round in this >> driver. Make this one match. > > Core SDIO functions are indeed the other way around, but the IO > functions in this file use (addr, data) pattern. So should we aim to get > it all

[PATCH] ath10k: sdio: remove unused struct member

irq_wq in struct ath10k_sdio is a remnant from an earlier version of the sdio patchset. It's use was removed as a result of Kalle's review, but somehow the struct member survived. It is not used and can therefore safely be removed. Signed-off-by: Erik Stromdahl ---

pull-request: iwlwifi-next 2017-08-18

Hi Kalle, Here's my third pull-request intended for v4.14.  We continued doing generic development work, with improvements, bug fixes and cleanups all around.  More details in the tag description. My patch "iwlwifi: update channel flags parser" is going to cause a conflict with net because they