I'm trying to get a usable Fedora running on a Dell Venue 8 Pro (baytrail / valleyview-based tablet). Among other issues with it, the onboard wireless does not appear to be detected or brought up at all. From poking about in Device Manager on Windows, it appears the wireless chip is an Atheros device with SDIO ID 0271:0418 that calls itself a "Dell Wireless" device (see http://marc.info/?l=linux-wireless&m=138583868807274&w=2 for some details). I think ath6kl would be the appropriate driver. No driver for the adapter is automatically loaded via modaliases. Manually modprobing ath6kl doesn't appear to achieve anything at all - the module loads but there's no indication it tries to do anything. I have tested with a build of the current Fedora Rawhide kernel (3.13.0-0.rc5.git0.1.fc21) with this patch: --- linux-3.13.0-0.rc2.git2.1.1.fc21.x86_64/drivers/net/wireless/ath/ath6kl/sdio.c 2013-11-03 15:41:51.000000000 -0800 +++ linux-3.13.0-0.rc2.git2.1.1.fc21.x86_64/drivers/net/wireless/ath/ath6kl/sdio.c.new 2013-12-03 16:38:36.109011716 -0800 @@ -1403,6 +1403,7 @@ {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6003_BASE | 0x1))}, {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))}, {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))}, + {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))}, {}, }; that adds the appropriate ID to the module's aliases, but doesn't seem to really help at all: the module is still not loaded on boot and loading it manually still appears to do nothing. It's possible there's an issue lower in the stack here, but I'm not familiar with debugging issues with SDIO-attached hardware at all, so I'm filing the bug on the obvious symptom/component for now. Please let me know if I can provide further information to help debug this.
Created attachment 120231 [details] acpidump from affected system
Created attachment 120241 [details] journal from a boot of the affected system, in case it's any use
Request from Kalle: --- I wasn't able to find any information about this device. Can you try ath6kl again, but this time with all debug messages enabled? In kernel config enable debug messages: CONFIG_ATH6KL_DEBUG=y And load ath6kl with all debug levels enabled: debug_mask=0xffffffff Now you should see a lot of messages, hopefully that gives some clues what kind of device it is. Also do you have the windows driver for the device? That might give some hints, especially the inf file, but I'm not very familiar with Windows... --- Note that Benjamin Tissoires has pointed out the Bay Trail tablets are likely affected by an Atom platform bug - http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/atom-Z36xxx-Z37xxx-spec-update.pdf , VLT37 - which means we may not even be bringing up the SDIO bus power at all, so we may not be able to get the debug output needed until that's fixed. I'm going to give it a shot, though.
Just to confirm c#3, I'm fairly sure we can't get anywhere with this right now. /sys/bus/sdio/devices is entirely unpopulated on the V8P, I believe further work is needed at a lower level to actually enumerate the device at all before we can look at trying to get the driver to talk to it.
(In reply to Adam Williamson from comment #4) > Just to confirm c#3, I'm fairly sure we can't get anywhere with this right > now. /sys/bus/sdio/devices is entirely unpopulated on the V8P, I believe > further work is needed at a lower level to actually enumerate the device at > all before we can look at trying to get the driver to talk to it. In intel's specification update for bay trail found here: http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/atom-Z36xxx-Z37xxx-spec-update.pdf Under VLT37: Problem: The SD Bus Power bit in Power Control Register (Bus 0; Device 17; Function 0; Offset 029H) is not connected to any SOC IO pin that can reset the SDIO bus power. Due to this erratum, SDIO device Power-On-Reset cannot be controlled by Power Control Register. SDIO Controller may fail to comply with SD Host Controller Specification Version 3.0 Implication: SDIO devices may not be powered up and initialized correctly. Workaround: Software should be configured to use a GPIO pin on the platform to enable or disable the SDIO bus power. So I believe it is a matter of looking at the specs and finding the right GPIO pin to enable/disable power to the SDIO devices.
I believe that's already been mentioned and known by the intel devs, but thanks...
Ah yes, I didn't notice it was mentioned. Well I found the relevant GPIO pin, labeled GPIO_S0_SC[41] in the Intel documentation. Tomorrow I look through the SDIO drivers and see if I can't come up with a quick fix to see if this bug is really the issue. I have a Lenovo Miix 2 with the same SoC and I can test it on that.
sounds great, thanks! if you drop a test patch here I can try it too.
Just a quick update: I added the relevant quirk in the sdio driver which should take care of this, but I am having trouble getting the baytrail GPIO driver to probe correctly. Hopefully I will get this working soon and I will drop a patch.
There may be some other not-yet-merged patches you need, there are certainly some relating to GPIO on Baytrail floating around. I've kind of lost track of what patch is for what and what the status of them all are, it gets confusing.
Sure enough you are correct. I found a patch from back in november that adds the new device IDs, but it was reverted in January because it causes kernel lockups. Adding it back in I still get the same soft lockups, but discovered that they had to do with the IRQ handlers, so I disabled that (commented that whole block out). I will contact the relevant Intel dev about that shortly. So now I modified the controller to accept the GPIO pin we need to assert power on the SDIO bus and now it works, I can see two devices, one is the WiFi and the other bluetooth. Right now I am having trouble with the WiFi driver, it's a broadcom chip so I am going to keep working at this, but this is something that you should be able to try and see how it runs on your system. Note, sometimes when I boot with this patch I see soft lockups, so I must have some kind of race condition. I will investigate this further, but this should be enough to get it started. If you have serious issues you can't figure out, post a kernel ring dump and I will try and figure it out. Let me know how it goes. http://dougvj.net/baytrail_gpio_quirk.patch
IIRC there are some later patches which are supposed to avoid the lockups, if you poke around a bit. You're talking about https://lkml.org/lkml/2014/1/23/716 , right? Looks like it may have gone back into 3.15: https://lkml.org/lkml/2014/2/18/787 are you working on top of 3.14 or 3.15?
I am working from 3.14. I will switch to 3.15 and see if that resolves any issues lockup-wise
OK, Looks like switching to linux-next (which is 3.15 right?) resolved some instability issues as far as I can tell. I am getting device enumeration on the sdio bus, so things look really happy. The pinctrl driver for baytrail has alot of functionality changed, so I need to work with the intel developer with this. It seems to have been broken anyway. The sdio driver should be good to go. Let me know what you discover.
awesome, thanks! I'll try it out ASAP.
Today I got a hold of an ASUS T100A which has the baytrail SoC as well and tried the kernel patch, I get some really bad lockups still, so there are some major issues to work through. I will send an email to the intel dev who wrote the GPIO driver and see if we can't get these ironed out.
I forgot to mention that despite the lockups, the patch does work in getting the SDIO bus to enable.
Cool. Re the lockups, could it be https://bugzilla.kernel.org/show_bug.cgi?id=68291 ? There's a new patch at https://lkml.org/lkml/2014/4/13/190 , but it doesn't apply at all for me (5 out of 5 hunks fail). YMMV.
Well hey, it sure does something! [adamw@fedlet ~]$ ls /sys/bus/sdio/devices/ -l total 0 lrwxrwxrwx. 1 root root 0 Apr 14 15:46 mmc1:0001:1 -> ../../../devices/platform/INT33BB:00/mmc_host/mmc1/mmc1:0001/mmc1:0001:1 [root@fedlet adamw]# journalctl -b | grep -i sdio Apr 14 08:46:24 fedlet.happyassassin.net kernel: mmc1: new high speed SDIO card at address 0001 graphics seem not to come up, though, so I'm poking it via ssh only. Not sure if that's related to your patch at all, or just coincidental borkage (I bumped to newer upstream 3.15 code at the same time).
woop, we're definitely getting somewhere! Now we have the SDIO devices enumerating, if I patch the SDIO ID into the driver again, ath6kl_sdio loads on boot. Doesn't work, but now I get some juicy errors in the logs: Apr 14 20:17:34 fedlet.happyassassin.net kernel: ath6kl: Unsupported hardware version: 0x31c809f8 Apr 14 20:17:34 fedlet.happyassassin.net kernel: ath6kl: Failed to init ath6kl core Apr 14 20:17:34 fedlet.happyassassin.net kernel: ath6kl_sdio: probe of mmc1:0001:1 failed with error -22 I'll try with the debug stuff mentioned back in c#3 soon.
hum, doesn't seem to add anything, unless I'm doing it rong. Is the above enough to go on?
Created attachment 132321 [details] debug output from trying to load ath6kl_sdio on affected hardware with debug_mask=0xffffffff oh, I was doing it rong. passing the parameter to the wrong module, _sdio not _core. D'oh. Attaching the debug output.
Kalle Valo says that the issue is pretty much as the error says: this is apparently a fairly new version of the ath6k hardware, and the driver does not yet support it. They've talked about adding support, but not had time yet.
OK. So earlier I picked up a v8pro from eBay. I will investigate more into this ath6k hardware. If the differences from the older hardware are simple then maybe I can get some rudimentary support myself. In the meantime, I am waiting for the gpio pinctrl drivers to settle down in terms of the IRQ issues, I see from https://bugzilla.kernel.org/show_bug.cgi?id=68291 that this is being worked on. I had to add one simple change to that driver for the quirk to function correcty. I did notice that on the Asus T100A the video stopped functioning in the latest drm-intel drivers. Maybe this is related to my patch? Did you get video working again? If you have to try reverting my patch and see if the video comes back again, otherwise we might be dealing with a regression.
If by "the latest drm-intel drivers" you mean you're compiling from upstream master, I'm not doing that. What I run on my V8P is precisely what you'd get from the official Fedora Rawhide repository, plus my Fedlet repo - https://www.happyassassin.net/fedlet/repo/i386/ . That's it. On current Rawhide, it seems like 'runlevel 5' (that is, graphical.target) boot quite frequently fails to reach X, and nerfs the console too (though remaining accessible via ssh) - but that doesn't seem to be specific to the fedlet kernels, or baytrail hardware. It seems to be affecting 'plain old Rawhide' on regular hardware too. I've certainly had a working graphical boot on my V8P using a kernel with your patch included. The latest fedlet repo kernel - https://www.happyassassin.net/fedlet/repo/i386/kernel-3.15.0-0.rc1.git1.1.1awb.i686.rpm - has your patch included, thanks a lot.
If you're running a Fedora Rawhide-ish build, dropping 'rhgb quiet' from the boot parameters may get video going again.
Doug: So I built a 3.15rc1 kernel with these two patches: https://github.com/AdamWill/baytrail-m/blob/master/kernel/baytrail_gpio_quirk.patch https://github.com/AdamWill/baytrail-m/blob/master/kernel/pinctrl-baytrail-workaround-for-irq-descriptor-conflict-on-ASUS-T100TA.patch that's a version of your patch for this bug but with the bits that disable IRQ allocation in pinctrl-baytrail.c dropped, and a rediffed version of the patch for https://bugzilla.kernel.org/show_bug.cgi?id=68291 . (also has the other patches in that directory applied, one is for shutdown/reboot, the others are for battery status - see MANIFEST for details). On my V8P it boots and enumerates the SDIO devices and doesn't seem to cause any lockups. There's a problem with touchscreen input which may be related somehow to either or both patches, but that's all I hit so far. You could try it and see how it goes for you, maybe?
Created attachment 132831 [details] attachment-710-0.html Yes! I will try this tonight and get back to you. On Thu, Apr 17, 2014 at 3:38 PM, <bugzilla-daemon@bugzilla.kernel.org>wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=67921 > > --- Comment #27 from Adam Williamson <awilliam@redhat.com> --- > Doug: So I built a 3.15rc1 kernel with these two patches: > > > > https://github.com/AdamWill/baytrail-m/blob/master/kernel/baytrail_gpio_quirk.patch > > > https://github.com/AdamWill/baytrail-m/blob/master/kernel/pinctrl-baytrail-workaround-for-irq-descriptor-conflict-on-ASUS-T100TA.patch > > that's a version of your patch for this bug but with the bits that disable > IRQ > allocation in pinctrl-baytrail.c dropped, and a rediffed version of the > patch > for https://bugzilla.kernel.org/show_bug.cgi?id=68291 . (also has the > other > patches in that directory applied, one is for shutdown/reboot, the others > are > for battery status - see MANIFEST for details). > > On my V8P it boots and enumerates the SDIO devices and doesn't seem to > cause > any lockups. There's a problem with touchscreen input which may be related > somehow to either or both patches, but that's all I hit so far. You could > try > it and see how it goes for you, maybe? > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
I get the same results. Everything works except the touchscreen driver (incidentally I don't have sound either). I am looking into this now.
You need firmware to make the sound work. Benjamin Tissoires is working on the touchscreen issue - I've filed it at https://bugzilla.kernel.org/show_bug.cgi?id=74241, but we're mostly working it via email. There are at least two different issues so far - if you build the hid-rmi driver (which is queued for 3.16 but backported to Fedora's 3.15 builds) it interferes, but even after dropping that, I hit an issue with i2c-hid. On 3.14, hid-multitouch handles the device successfully, i2c-hid doesn't seem to really get a look-in.
Hey Doug - Benjamin Tissoires says your patch is causing touchscreen initialization to fail on at least the V8P and Miix2. I'm definitely seeing the problem, I haven't yet confirmed that it traces down to your patch precisely, but it's probably OK to trust Benjamin :) Something to do with ACPI IRQ requests. At first he thought it was caused by the fix for https://bugzilla.kernel.org/show_bug.cgi?id=68291 , but he says he tested and it traces back to your patch for this bug, not that one.
Created attachment 133221 [details] attachment-19711-0.html That is interesting. I will poke around with some changes today hopefully I can figure out what's going on and fix it.
OK So doing some research, the following patch does nothing except enable the pinctrl driver for baytrail, which causes the ACPI IRQ issues. The rest of my patch actually enabling the SDIO bus doesn't affect it. I will try to find a way to work around the issue in the pinctrl code. diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c index 69e29f4..d79c6d7 100644 --- a/drivers/acpi/acpi_lpss.c +++ b/drivers/acpi/acpi_lpss.c @@ -180,6 +180,7 @@ static const struct acpi_device_id acpi_lpss_device_ids[] = { { "80860F14", (unsigned long)&byt_sdio_dev_desc }, { "80860F41", (unsigned long)&byt_i2c_dev_desc }, { "INT33B2", }, + { "INT33FC", }, { "INT3430", (unsigned long)&lpt_dev_desc }, { "INT3431", (unsigned long)&lpt_dev_desc }, diff --git a/drivers/pinctrl/pinctrl-baytrail.c b/drivers/pinctrl/pinctrl-baytrail.c index 6e8301f..447f1dc 100644 --- a/drivers/pinctrl/pinctrl-baytrail.c +++ b/drivers/pinctrl/pinctrl-baytrail.c @@ -572,6 +572,7 @@ static const struct dev_pm_ops byt_gpio_pm_ops = { static const struct acpi_device_id byt_gpio_acpi_match[] = { { "INT33B2", 0 }, + { "INT33FC", 0 }, { } }; MODULE_DEVICE_TABLE(acpi, byt_gpio_acpi_match);
OK, I found the problem and I found a workaround, but I don't know what to do to fix it exactly. A new version of the patch is here: http://dougvj.net/baytrail_gpio_quirk_v2.patch The relevant difference is this right here: + /* This is an attempt to stop the SDHCI drivers from requesting IRQ lines + * through the pinctrl driver. This may be a quirk in the hardware or it + * may be a bug here in the IRQ handling + */ + if (offset == 38) + return -EINVAL; This prevents the SDHCI driver from using GPIOs to detect card insertion. This fixes the ACPI issues and the touchscreen works for me on the ASUS T100A. Go ahead and see if this fixes it for you on the A8P
Correction *V8P not A8P
Ah, thanks. I was going to look at it systematically, seeing what was the smallest change that would cause the problem, but I guess that's not necessary any more? So far I confirmed that a kernel built from Fedora Rawhide sources with the sole difference of disabling the hid-rmi driver (to avoid *that* bug) results in a working touchscreen. For now I'll skip the next stage of my approach and instead test a build with both patches... looks like your latest patch has some unnecessary whitespace changes, BTW.
Whoops. That was from my commenting out different blocks to find the problem. The patch with the whitespace changes removed is here: http://dougvj.net/baytrail_gpio_quirk_v3.patch
OK, so I can confirm that with a 3.15rc2 kernel build with v3 of your patch (but no patch for #68291), the Venue 8 Pro touchscreen works, SDIO device is present in /sys/bus/sdio/devices , and I don't see any lockups. I'll try a build with the #68291 patch added as well, just to see what happens, but it doesn't appear to be necessary on the V8P at least.
I think I've nailed down the circumstances of the touchscreen issue now: it happens when *both* this patch - http://dougvj.net/baytrail_gpio_quirk_v3.patch - and the fix for #68291 - https://patchwork.kernel.org/patch/4000341/ - are applied. Either patch alone does not cause the touchscreen issue.
One potential issue with this patch (http://dougvj.net/baytrail_gpio_quirk_v3.patch) is, after applying it, the SDIO is always in D0. I'm using following patch to display SDIO power status: http://lwn.net/Articles/589723/ -and- cat /sys/kernel/debug/pmc_atom/dev_state
Oops, I missed an important source file than handles the powering on and off. This version of the patch adds that: http://dougvj.net/baytrail_gpio_quirk_v4.patch I am in the middle of final semester work so I don't have time to test much this week, but let me know of any other issues.
Even with this patch http://dougvj.net/baytrail_gpio_quirk_v4.patch, SDID is still D0 and SDCARD is D0 too (no sdcard inserted).
OK thanks for testing. I don't have much time to work on it this week but next week I will look at it in detail and try to find a solution. Let me know of any other issues
Owning a Schenker Element (Baytrail SoC but with a Realtek RTL8723BS SDIO) with the same gpio erratum. But in my case the quirk drops out with "Unable to request GPIO. SDIO may be broken." I'm not quite sure if i need to change some Settings in BIOS or if my hardware somehow differs enough for the quirk to drop out.
Looks like the patch needs re-diffing for 3.16, just a heads-up. Has there been any interest from Intel/upstream in getting this merged?
with a 3.16 rc2 kernel, even without any version of Doug's patch, the SDIO device enumerates: [adamw@fedlet ~]$ ls /sys/bus/sdio/devices/ mmc1:0001:1 [adamw@fedlet ~]$ ls /sys/bus/sdio/devices/mmc1\:0001\:1/ class device firmware_node modalias power subsystem uevent vendor [adamw@fedlet ~]$ cat /sys/bus/sdio/devices/mmc1\:0001\:1/modalias sdio:c00v0271d0418 [adamw@fedlet ~]$
i can confirm this for my Schenker Tablet. After importing some Android Drivers from a 2.6 Kernel I have a Baytrail Tablet with working wireless. Even the touchscreen worked right out of the box, including backlight and resolution.
with a patch to add the ID (same one as up in the description), and the latest ath6kl code from linville, the adapter at least shows up and scans for APs. It seems to fail to connect to one, for me, but we have progress. Will try and get some debug output soon.
(In reply to Adam Williamson from comment #48) > the adapter at least shows up and scans for APs. > It seems to fail to connect to one, for me, but we have progress. Might be similar to bug #88061 (runtime-pm support missing, sdhci sleepin' away) that looked exactly the same for me on brcmfmac.
Whoops, I should've updated this! Jan-Michael Brummer sent me a patch a few weeks back that I've been carrying in Fedlet for a while: https://github.com/AdamWill/baytrail-m/blob/master/kernel/sdhci-pm.patch for me that works fine. With the patch to add the V8P's SDIO ID - https://github.com/AdamWill/baytrail-m/blob/master/kernel/support-Dell-OEM-chipset-found-in-Venue-8-Pro-SDIO-I.patch - the V8P's wifi works pretty well. I don't know if J-M B's patch is upstreamable or has been submitted upstream, yet.
I ma trying to make SDIO work with 3.10 on baytrail based tablet. I am not seeing any devices under /sys/bus/sdio/devices/ Please help me to find out patch to enable SDIO. Thanks
(In reply to J M from comment #51) > I am trying to make SDIO work with 3.10 on baytrail based tablet. If it's vanilla 3.10 and not vendor kernel, try modern one -- I don't remember when exactly SDIO wifi started to work for me but it was November 2014 or so (don't forget firmware, probably nvram file too).
I am looking for SDIO to work. I have firmware and drivers for wifi modules. My kernel is 3.10.18 and i have no option to move to new kernel. I can back port the patch to kernel 3.10. I was looking for http://dougvj.net/baytrail_gpio_quirk_v4.patch But looks like its not available now. please suggest.
This is a bug tracker not a support forum. It's the wrong place to ask about backports of the wifi and dozens of other things you'd need.
Is there any reason why patch from comment 50 is not upstreamed?
Looks like nobody ever submitted upstream
(In reply to Alan from comment #56) > Looks like nobody ever submitted upstream It was, as one of: http://thread.gmane.org/gmane.linux.kernel.mmc/25081/focus=25087 http://thread.gmane.org/gmane.linux.kernel.mmc/31583 But gmane is (shutting) down, so who knows.
As recommended on page https://wireless.wiki.kernel.org/en/users/drivers/ath6kl I sent request for reviewing patch to kvalo@qca.qualcomm.com and linux-wireless@vger.kernel.org But since other info other page is outdated (for example broken link to ath6kl project on GitHub) I not sure if it was right thing. Just in case, is there any other way to reach Qualcomm developers to be sure they will look into this?
The linux-wireless address is a good one. I've also tadded the patch to my tree so when I get time I can see if it needs further pushing.
(In reply to Alan from comment #59) > The linux-wireless address is a good one. I've also tadded the patch to my > tree so when I get time I can see if it needs further pushing. This is a version that's ready for submission with the original author credited: https://github.com/hadess/rtl8723bs/blob/master/patches/0001-mmc-sdhci-get-runtime-pm-when-sdio-irq-is-enabled.patch
For ath6kl patches please follow the instructions on the wiki: https://wireless.wiki.kernel.org/en/users/drivers/ath6kl#hacking_on_ath6kl I also fixed the link of my ath.git tree, it's now on kernel.org: https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/ But this is only for ath6kl, mmc patches go via a different maintainer and tree.
Ok, I can't do this: http://lists.infradead.org/pipermail/ath6kl/2016-August/000247.html Pinged Adam, but he "not really interested". Anyone else could do this? And also please include Dell Wireless 1537 into patch, code is 0x19 (next after Dell Wireless 1538).
Heads up, is there anyone who willing to submit patch following mentioned rules?
I did and it got ignored - I'll resend it after this merge window
(In reply to Alan from comment #64) > I did and it got ignored - I'll resend it after this merge window You mean the ath6kl patch? Where did you submit it, linux-wireless list? I don't recall seeing any patches from you.
A while ago - August ?- to linux-wireless. No problem I'll resend it now if it got lost - I know all too well given the volume of patches things do.
(In reply to Alan from comment #66) > A while ago - August ?- to linux-wireless. No problem I'll resend it now if > it got lost - I know all too well given the volume of patches things do. Odd, I would have imagined that I definitely would remember if I get a patch from you :) Also patchwork can't find it: https://patchwork.kernel.org/project/linux-wireless/list/?state=*&q=ath6k But anyway, I got your patch your now and I'm planning to push it to 4.9 so this should be finally sorted: https://patchwork.kernel.org/patch/9373725/
Alan, can you please include device from Comment 62 into this patch or via separte patch? Like here: http://www.studioteabag.com/science/dell-venue-pro-linux/#kernel_compiling
Thanks - I guess if it vanished before the list that would explain why you didn't see it 8) RussianNeuroMancer: I will take a look. Can you confirm it works. The description on that website of barely registering wifi suggests more is needed for that device.
Alan, on this page http://www.studioteabag.com/science/dell-venue-pro-linux/#just_the_facts scroll to "What works, what doesn't". As you see "Chip is similar to Venue 8, different revision." and "Needs kernel patch as Device ID is not yet in mainline."
(In reply to RussianNeuroMancer from comment #70) Please check the DKMS module with patch for Dell Wireless 1537: https://github.com/pbludov/ath6kl-dkms/releases/tag/v4.12 If this works for you, I'll post the patch to the maintainers.
> If this works for you, I'll post the patch to the maintainers. I didn't test it myself but other user confirm this is works. Could you please submit patch to maintainers?