On Sat, Jun 10, 2017 at 10:27 PM, Arend van Spriel
wrote:
> On 03-06-17 17:36, Andy Shevchenko wrote:
>> On Sat, Jun 3, 2017 at 1:29 AM, Peter S. Housel wrote:
The following looks good to me.
Feel free to add
Reviewed-by: Andy Shevchenko
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac
On 11-06-17 02:18, Peter Housel wrote:
>
>> On Jun 10, 2017, at 12:27 PM, Arend van Spriel
>> wrote:
>>
>> On 03-06-17 17:36, Andy Shevchenko wrote:
>>> On Sat, Jun 3, 2017 at 1:29 AM, Peter S. Housel wrote:
An earlier change to this function (3bdae810721b) fixed a leak in the
case of
On 03-06-17 17:36, Andy Shevchenko wrote:
> On Sat, Jun 3, 2017 at 1:29 AM, Peter S. Housel wrote:
>> An earlier change to this function (3bdae810721b) fixed a leak in the
>> case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
>> glom_skb buffer, used for emulating a scattering read
On Sat, Jun 3, 2017 at 1:29 AM, Peter S. Housel wrote:
> An earlier change to this function (3bdae810721b) fixed a leak in the
> case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
> glom_skb buffer, used for emulating a scattering read, is never used
> or referenced after its conte
An earlier change to this function (3bdae810721b) fixed a leak in the
case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
glom_skb buffer, used for emulating a scattering read, is never used
or referenced after its contents are copied into the destination
buffers, and therefore alway
