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
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.
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
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
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
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
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
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
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
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,
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
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
---
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
13 matches
Mail list logo