Hello.
Some users have reported that they have issues with WiFi firmware
loading on Droid 4. The fragment of dmesg for the issue follows
at the bottom of this mail.
With the help of Tony Lindgren I have found that the root of the
issue was Bluetooth firmware loaded before WiFi driver (wlcore).
Now we need to change the kernel to make it load Bluetooth firmware
only after WiFi firmware is loaded. So the bug will not be triggered.
Any ideas on how it should be done?
P.S. When I do "rmmod hci_uart" on Droid 4 device, I get something
like endless loop of error reporting from kernel. The fragment of
dmesg can be downloaded from https://dropmefiles.com/wCPMF
I'm not sure where to report this one.
--
Best regards, Arthur D.
[ 15.951904] ------------[ cut here ]------------
[ 16.028137] WARNING: CPU: 1 PID: 23 at
drivers/net/wireless/ti/wlcore/sdio.c:78 wl12xx_sdio_raw_read+0xcc/0x15c
[wlcore_sdio]
[ 16.211669] Modules linked in: omapdrm drm_kms_helper cfbfillrect
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea
snd_soc_omap_hdmi wl12xx wlcore mac80211 panel_dsi_cm libarc4
sha256_generic libsha256 sha256_arm cfg80211 joydev mousedev evdev
pwm_vibra snd_soc_audio_graph_card ff_memless phy_generic
snd_soc_simple_card_utils phy_mapphone_mdm6600(+) led_bl cpufreq_dt
gpio_keys pwm_omap_dmtimer connector_hdmi omapdss omapdss_base
omap4_keypad drm matrix_keymap drm_panel_orientation_quirks cec
omap_mailbox omap_sham omap_aes_driver omap2430 ohci_platform ohci_hcd
ehci_omap ehci_hcd st_accel_spi st_sensors_spi st_accel_i2c st_sensors_i2c
st_accel st_sensors industrialio_triggered_buffer kfifo_buf omap_des
libdes crypto_engine omap_crypto wlcore_sdio omap_hdq wire cn
phy_cpcap_usb musb_hdrc cpcap_adc udc_core cpcap_battery usbcore
usb_common rtc_cpcap cpcap_pwrbutton cpcap_charger phy_omap_usb2
industrialio snd_soc_cpcap leds_cpcap atmel_mxt_ts hci_uart btbcm lm75
[ 16.211669] leds_lm3532
[ 16.226989] systemd-journald[105]: Compressed data object 989 -> 808
using LZ4
[ 17.050018] hwmon led_class bluetooth ecdh_generic ecc libaes
motorola_mdm n_gsm snd_soc_omap_mcbsp snd_soc_ti_sdma snd_soc_core
snd_pcm_dmaengine snd_pcm snd_timer omap_wdt watchdog snd soundcore autofs4
[ 17.144073] phy-mapphone-mdm6600 usb-phy@1: Waiting for power up
request to complete..
[ 17.255035] CPU: 1 PID: 23 Comm: kworker/1:1 Tainted: G
W 5.5.0-00039-gadd2f906e747-dirty #23
[ 17.657806] Hardware name: Generic OMAP4 (Flattened Device Tree)
[ 17.657867] Workqueue: events request_firmware_work_func
[ 17.861297] [<c0112b88>] (unwind_backtrace) from [<c010cafc>]
(show_stack+0x10/0x14)
[ 17.861297] [<c010cafc>] (show_stack) from [<c090753c>]
(dump_stack+0xb4/0xd0)
[ 17.861450] [<c090753c>] (dump_stack) from [<c013aaf0>]
(__warn+0xd0/0xf8)
[ 17.861450] [<c013aaf0>] (__warn) from [<c013abbc>]
(warn_slowpath_fmt+0xa4/0xb4)
[ 17.861450] [<c013abbc>] (warn_slowpath_fmt) from [<bf1bf418>]
(wl12xx_sdio_raw_read+0xcc/0x15c [wlcore_sdio])
[ 17.861633] [<bf1bf418>] (wl12xx_sdio_raw_read [wlcore_sdio]) from
[<bf525074>] (wl12xx_get_mac+0x150/0x324 [wl12xx])
[ 17.861938] [<bf525074>] (wl12xx_get_mac [wl12xx]) from [<bf410380>]
(wlcore_nvs_cb+0x250/0xad8 [wlcore])
[ 17.862121] [<bf410380>] (wlcore_nvs_cb [wlcore]) from [<eccfdb00>]
(0xeccfdb00)
[ 17.868988] ---[ end trace b49285f1f3a91e50 ]---
[ 17.868988] wl1271_sdio mmc4:0001:2: sdio read failed (-110)
[ 17.869079] wlcore: ERROR couldn't get hw info
Hi,
WTF :(
Right now the BT driver and the WiFi driver are no aware of
each other. Actually the kernel is not even aware, that both
drivers are using the same chip. Unfortunately this will be
tricky to solve properly. Since a system may have two WiLink
devices, the only solution coming to my mind would be adding
a link from the BT device to the WiFi device in device tree.
Additionally we would need something in the WiLink driver to
check if driver has been initialized properly for a given DT
node.
-- Sebastian
On Fri, Feb 14, 2020 at 12:54:50AM +0300, Arthur D. wrote:
> Hello.
>
> Some users have reported that they have issues with WiFi firmware
> loading on Droid 4. The fragment of dmesg for the issue follows
> at the bottom of this mail.
>
> With the help of Tony Lindgren I have found that the root of the
> issue was Bluetooth firmware loaded before WiFi driver (wlcore).
>
> Now we need to change the kernel to make it load Bluetooth firmware
> only after WiFi firmware is loaded. So the bug will not be triggered.
>
> Any ideas on how it should be done?
>
> P.S. When I do "rmmod hci_uart" on Droid 4 device, I get something
> like endless loop of error reporting from kernel. The fragment of
> dmesg can be downloaded from https://dropmefiles.com/wCPMF
> I'm not sure where to report this one.
>
> --
> Best regards, Arthur D.
>
>
> [ 15.951904] ------------[ cut here ]------------
> [ 16.028137] WARNING: CPU: 1 PID: 23 at
> drivers/net/wireless/ti/wlcore/sdio.c:78 wl12xx_sdio_raw_read+0xcc/0x15c
> [wlcore_sdio]
> [ 16.211669] Modules linked in: omapdrm drm_kms_helper cfbfillrect
> syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea
> snd_soc_omap_hdmi wl12xx wlcore mac80211 panel_dsi_cm libarc4
> sha256_generic libsha256 sha256_arm cfg80211 joydev mousedev evdev
> pwm_vibra snd_soc_audio_graph_card ff_memless phy_generic
> snd_soc_simple_card_utils phy_mapphone_mdm6600(+) led_bl cpufreq_dt
> gpio_keys pwm_omap_dmtimer connector_hdmi omapdss omapdss_base
> omap4_keypad drm matrix_keymap drm_panel_orientation_quirks cec
> omap_mailbox omap_sham omap_aes_driver omap2430 ohci_platform ohci_hcd
> ehci_omap ehci_hcd st_accel_spi st_sensors_spi st_accel_i2c st_sensors_i2c
> st_accel st_sensors industrialio_triggered_buffer kfifo_buf omap_des
> libdes crypto_engine omap_crypto wlcore_sdio omap_hdq wire cn
> phy_cpcap_usb musb_hdrc cpcap_adc udc_core cpcap_battery usbcore
> usb_common rtc_cpcap cpcap_pwrbutton cpcap_charger phy_omap_usb2
> industrialio snd_soc_cpcap leds_cpcap atmel_mxt_ts hci_uart btbcm lm75
> [ 16.211669] leds_lm3532
> [ 16.226989] systemd-journald[105]: Compressed data object 989 -> 808
> using LZ4
> [ 17.050018] hwmon led_class bluetooth ecdh_generic ecc libaes
> motorola_mdm n_gsm snd_soc_omap_mcbsp snd_soc_ti_sdma snd_soc_core
> snd_pcm_dmaengine snd_pcm snd_timer omap_wdt watchdog snd soundcore autofs4
> [ 17.144073] phy-mapphone-mdm6600 usb-phy@1: Waiting for power up
> request to complete..
> [ 17.255035] CPU: 1 PID: 23 Comm: kworker/1:1 Tainted: G
> W 5.5.0-00039-gadd2f906e747-dirty #23
> [ 17.657806] Hardware name: Generic OMAP4 (Flattened Device Tree)
> [ 17.657867] Workqueue: events request_firmware_work_func
> [ 17.861297] [<c0112b88>] (unwind_backtrace) from [<c010cafc>]
> (show_stack+0x10/0x14)
> [ 17.861297] [<c010cafc>] (show_stack) from [<c090753c>]
> (dump_stack+0xb4/0xd0)
> [ 17.861450] [<c090753c>] (dump_stack) from [<c013aaf0>]
> (__warn+0xd0/0xf8)
> [ 17.861450] [<c013aaf0>] (__warn) from [<c013abbc>]
> (warn_slowpath_fmt+0xa4/0xb4)
> [ 17.861450] [<c013abbc>] (warn_slowpath_fmt) from [<bf1bf418>]
> (wl12xx_sdio_raw_read+0xcc/0x15c [wlcore_sdio])
> [ 17.861633] [<bf1bf418>] (wl12xx_sdio_raw_read [wlcore_sdio]) from
> [<bf525074>] (wl12xx_get_mac+0x150/0x324 [wl12xx])
> [ 17.861938] [<bf525074>] (wl12xx_get_mac [wl12xx]) from [<bf410380>]
> (wlcore_nvs_cb+0x250/0xad8 [wlcore])
> [ 17.862121] [<bf410380>] (wlcore_nvs_cb [wlcore]) from [<eccfdb00>]
> (0xeccfdb00)
> [ 17.868988] ---[ end trace b49285f1f3a91e50 ]---
> [ 17.868988] wl1271_sdio mmc4:0001:2: sdio read failed (-110)
> [ 17.869079] wlcore: ERROR couldn't get hw info
* Sebastian Reichel <[email protected]> [200214 17:20]:
> Hi,
>
> WTF :(
>
> Right now the BT driver and the WiFi driver are no aware of
> each other. Actually the kernel is not even aware, that both
> drivers are using the same chip. Unfortunately this will be
> tricky to solve properly. Since a system may have two WiLink
> devices, the only solution coming to my mind would be adding
> a link from the BT device to the WiFi device in device tree.
> Additionally we would need something in the WiLink driver to
> check if driver has been initialized properly for a given DT
> node.
Yeah exactly.. I think the best way would be to export something
like wlcore_register_bt/wlcore_unregister_bt.. And then have
wlcore_register_bt return -EAGAIN until wlcore is up.
> On Fri, Feb 14, 2020 at 12:54:50AM +0300, Arthur D. wrote:
> > Hello.
> >
> > Some users have reported that they have issues with WiFi firmware
> > loading on Droid 4. The fragment of dmesg for the issue follows
> > at the bottom of this mail.
> >
> > With the help of Tony Lindgren I have found that the root of the
> > issue was Bluetooth firmware loaded before WiFi driver (wlcore).
> >
> > Now we need to change the kernel to make it load Bluetooth firmware
> > only after WiFi firmware is loaded. So the bug will not be triggered.
> >
> > Any ideas on how it should be done?
> >
> > P.S. When I do "rmmod hci_uart" on Droid 4 device, I get something
> > like endless loop of error reporting from kernel. The fragment of
> > dmesg can be downloaded from https://dropmefiles.com/wCPMF
> > I'm not sure where to report this one.
Yup I've seen rmmod hci_uart produce kernel oops, but I just tried
to reproduce it again on v5.5 and it just took a long time to rmmod
with no oops.
Regards,
Tony
8< ---------------
# dmesg -C; modprobe hci_uart; sleep 5; rmmod hci_uart; dmesg -c
[ 616.926422] Bluetooth: HCI UART driver ver 2.3
[ 616.926422] Bluetooth: HCI UART protocol H4 registered
[ 616.926422] Bluetooth: HCI UART protocol BCSP registered
[ 616.926513] Bluetooth: HCI UART protocol LL registered
[ 616.926635] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 616.927185] Bluetooth: HCI UART protocol Broadcom registered
[ 616.927764] hci-ti serial1-0: GPIO lookup for consumer enable
[ 616.927764] hci-ti serial1-0: using device tree for GPIO lookup
[ 616.927856] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/ocp/interconnect@48000000/segment@0/target-module@6e000/serial@0/bluetooth[0]' - status (0)
[ 616.927886] gpio gpiochip6: Persistence not supported for GPIO 14
[ 624.002838] Bluetooth: hci0: command 0xff05 tx timeout
[ 632.572662] Bluetooth: hci0: send command failed
[ 632.572814] Bluetooth: hci0: download firmware failed, retrying...
[ 634.722991] Bluetooth: hci0: command 0x1001 tx timeout
[ 642.812652] Bluetooth: hci0: Reading TI version information failed (-110)
[ 642.812652] Bluetooth: hci0: download firmware failed, retrying...
[ 644.962707] Bluetooth: hci0: command 0x1001 tx timeout
[ 653.043151] Bluetooth: hci0: Reading TI version information failed (-110)
[ 653.043182] Bluetooth: hci0: download firmware failed, retrying...
[ 655.203582] Bluetooth: hci0: command 0x1001 tx timeout
[ 663.294372] Bluetooth: hci0: Reading TI version information failed (-110)
[ 663.294464] Bluetooth: hci0: download firmware failed, retrying...
Hi Marcel,
On 14/02/2020 19:23, Marcel Holtmann wrote:
> Hi Tony,
>
>>> WTF :(
>>>
>>> Right now the BT driver and the WiFi driver are no aware of
>>> each other. Actually the kernel is not even aware, that both
>>> drivers are using the same chip. Unfortunately this will be
>>> tricky to solve properly. Since a system may have two WiLink
>>> devices, the only solution coming to my mind would be adding
>>> a link from the BT device to the WiFi device in device tree.
>>> Additionally we would need something in the WiLink driver to
>>> check if driver has been initialized properly for a given DT
>>> node.
>>
>> Yeah exactly.. I think the best way would be to export something
>> like wlcore_register_bt/wlcore_unregister_bt.. And then have
>> wlcore_register_bt return -EAGAIN until wlcore is up.
>
> actually NO.
>
> We have rejected this many times for all hardware manufacturers. Please fix the firmware instead.
That could be a real challenge, given that we don't have access to the
firmware source. Are there other historic precedents besides "fix the
firmware" that could be relevant here?
Currently we're stuck with either blacklisting the bluetooth modules all
together, or potentially have out of tree patches -- neither are ideal
for (my/our) "Mainline GNU/Linux" on a smartphone goal.
Cheers,
Merlijn