Re: Probelm on (brcmfmac: use pre-allocated scatter-gather table for txglomming)

[Michael Trimarchi]

Hi


On Sat, Mar 12, 2016 at 8:29 AM, Arend van Spriel
 wrote:
>
>
> On 11-03-16 16:23, Michael Trimarchi wrote:
>> Hi
>>
>> I have a kernel panic on the brcmf_sdiod_sgtable_alloc just because
>> the function is called before brcmf_sdio_probe.
>>
>> I think that
>>  nents = max_t(uint, BRCMF_DEFAULT_RXGLOM_SIZE,
>>   sdiodev->bus_if->drvr->settings->sdiod_txglomsz);
>>
>> drvr is null. Can you explain how it can work or do you have already a
>> fix for this?
>
> What kernel version are you using? This has been fixed already in
> 4.5-rc2 or rc3.

Ok, I see it I was using rockchip for-next and I have seen now the fix
in newest tree.

Thank you
Michael

>
> Regards,
> Arend



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] staging: rtl8723au: Fix line longer than 80 columns.

[Edward Lipinsky]

This patch fixes the checkpatch.pl warning:

WARNING: line over 80 characters

Signed-off-by: Edward Lipinsky 
---
Change in v2:
- Break the line after the format string, as suggested by Joe
  Perches .

 drivers/staging/rtl8723au/core/rtw_ap.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c 
b/drivers/staging/rtl8723au/core/rtw_ap.c
index ce4b589..67c9d90 100644
--- a/drivers/staging/rtl8723au/core/rtw_ap.c
+++ b/drivers/staging/rtl8723au/core/rtw_ap.c
@@ -1834,7 +1834,8 @@ void stop_ap_mode23a(struct rtw_adapter *padapter)
}
spin_unlock_bh(&pacl_node_q->lock);
 
-   DBG_8723A("%s, free acl_node_queue, num =%d\n", __func__, 
pacl_list->num);
+   DBG_8723A("%s, free acl_node_queue, num =%d\n",
+ __func__, pacl_list->num);
 
rtw_sta_flush23a(padapter);
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: carl1970: stops working at random periods on Ubuntu 15.05

[Christian Lamparter]

On Friday, March 11, 2016 09:12:40 AM alexander nekrasov wrote:
> Thanks for an answer, Christian! Adapter is getting hot sometimes
> indeed. Also my adapter is usb2.0 but it was on extender with another
> usb1.1 device. I plugged it into motherboards port directly but issue
> still continue to happens. I  also tried reload host controller but it
> did not help. 
In that case, this might be a problem with the host controller on your
motherboard. I say "might", because it could also be that the ar9170
device is damaged or that something else is going on. Can you test the
device on a different PC and test if it fails in the same way?

Other than that, there's not much you can do (easily). If you want
to investigate the issue further, you would need probe the FUSB200
in the device. The only place you can do that is within the firmware
as the USB subsystem is breaking down. The firmware can be downloaded
from [0]. The register to look at is 0x1E110C (AR9170_USB_REG_DMA_STATUS).

There are a few error bits that can be checked.

Bit 24: Error when the upstream DMA access the data bus.
Bit 25: Error when the upstream DMA access the command bus.
Bit 26: Error when the downstream DMA access the data bus.
Bit 27: Error when the downstream DMA access the command bus.
Bit 28: Error when the CPU access the data bus.
Bit 29: Error when the CPU access the command bus.

If any of those bits are set, it's probably time to issue a
firmware reboot (set fw.reboot to 1 or directly call "reboot();").

That said, I don't have high hopes. In your logs, the carl9170
driver is already trying to reset the device... and failing since
it is unable to communicate with the device.

> However I discovered strange behavior. Here is my
> scenario:
> 1. boot system
> 2. check device is displayed by 'lsusb' and 'lsusb -t'
> 3. unbind and bind root hub where device is plugged into
> 4. this time 'lsusb' does list device and 'lsusb -t' does not
> 
> Is it ok?
> 
> After unbind/bind device definitely is not working - there is led
> indicator and it is off. Should I 'enable' device after binding root
> hub with another command?

I would suggest you also contact the linux-usb mailing list [1].
They may be able to debug why the host controller is not responding
to the bind and unbind.

[0] 
[1] 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html