Bug 67921 - Dell Venue 8 Pro "Dell Wireless" (Atheros 6k) chipset with SDIO ID 0271:0418 not recognized/supported
Summary: Dell Venue 8 Pro "Dell Wireless" (Atheros 6k) chipset with SDIO ID 0271:0418 ...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-30 01:43 UTC by Adam Williamson
Modified: 2018-03-08 15:40 UTC (History)
16 users (show)

See Also:
Kernel Version: 3.13.0-0.rc5.git0.1.fc21
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump from affected system (265.28 KB, text/plain)
2013-12-30 01:43 UTC, Adam Williamson
Details
journal from a boot of the affected system, in case it's any use (170.97 KB, text/plain)
2013-12-30 01:44 UTC, Adam Williamson
Details
debug output from trying to load ath6kl_sdio on affected hardware with debug_mask=0xffffffff (9.72 KB, text/plain)
2014-04-15 03:52 UTC, Adam Williamson
Details
attachment-710-0.html (2.16 KB, text/html)
2014-04-17 21:45 UTC, Doug Johnson
Details
attachment-19711-0.html (176 bytes, text/html)
2014-04-21 17:20 UTC, Doug Johnson
Details

Description Adam Williamson 2013-12-30 01:43:26 UTC
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.
Comment 1 Adam Williamson 2013-12-30 01:43:45 UTC
Created attachment 120231 [details]
acpidump from affected system
Comment 2 Adam Williamson 2013-12-30 01:44:05 UTC
Created attachment 120241 [details]
journal from a boot of the affected system, in case it's any use
Comment 3 Adam Williamson 2014-02-13 19:29:25 UTC
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.
Comment 4 Adam Williamson 2014-02-22 08:07:34 UTC
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.
Comment 5 Doug Johnson 2014-04-11 06:51:16 UTC
(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.
Comment 6 Adam Williamson 2014-04-11 07:23:46 UTC
I believe that's already been mentioned and known by the intel devs, but thanks...
Comment 7 Doug Johnson 2014-04-11 08:25:01 UTC
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.
Comment 8 Adam Williamson 2014-04-11 15:33:11 UTC
sounds great, thanks! if you drop a test patch here I can try it too.
Comment 9 Doug Johnson 2014-04-12 19:18:03 UTC
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.
Comment 10 Adam Williamson 2014-04-12 19:30:20 UTC
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.
Comment 11 Doug Johnson 2014-04-13 07:16:59 UTC
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
Comment 12 Adam Williamson 2014-04-13 07:52:21 UTC
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?
Comment 13 Doug Johnson 2014-04-13 08:01:22 UTC
I am working from 3.14. I will switch to 3.15 and see if that resolves any issues lockup-wise
Comment 14 Doug Johnson 2014-04-13 09:59:56 UTC
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.
Comment 15 Adam Williamson 2014-04-13 15:01:41 UTC
awesome, thanks! I'll try it out ASAP.
Comment 16 Doug Johnson 2014-04-14 21:06:31 UTC
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.
Comment 17 Doug Johnson 2014-04-14 21:10:25 UTC
I forgot to mention that despite the lockups, the patch does work in getting the SDIO bus to enable.
Comment 18 Adam Williamson 2014-04-14 22:13:16 UTC
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.
Comment 19 Adam Williamson 2014-04-14 22:50:43 UTC
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).
Comment 20 Adam Williamson 2014-04-15 03:20:47 UTC
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.
Comment 21 Adam Williamson 2014-04-15 03:36:07 UTC
hum, doesn't seem to add anything, unless I'm doing it rong. Is the above enough to go on?
Comment 22 Adam Williamson 2014-04-15 03:52:06 UTC
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.
Comment 23 Adam Williamson 2014-04-15 05:32:44 UTC
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.
Comment 24 Doug Johnson 2014-04-16 08:55:10 UTC
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.
Comment 25 Adam Williamson 2014-04-16 09:35:34 UTC
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.
Comment 26 Adam Williamson 2014-04-17 01:31:37 UTC
If you're running a Fedora Rawhide-ish build, dropping 'rhgb quiet' from the boot parameters may get video going again.
Comment 27 Adam Williamson 2014-04-17 21:38:14 UTC
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?
Comment 28 Doug Johnson 2014-04-17 21:45:35 UTC
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.
>
Comment 29 Doug Johnson 2014-04-18 04:03:11 UTC
I get the same results. Everything works except the touchscreen driver (incidentally I don't have sound either). I am looking into this now.
Comment 30 Adam Williamson 2014-04-18 04:37:12 UTC
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.
Comment 31 Adam Williamson 2014-04-21 15:52:53 UTC
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.
Comment 32 Doug Johnson 2014-04-21 17:20:18 UTC
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.
Comment 33 Doug Johnson 2014-04-21 22:06:51 UTC
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);
Comment 34 Doug Johnson 2014-04-22 03:01:57 UTC
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
Comment 35 Doug Johnson 2014-04-22 03:02:24 UTC
Correction *V8P not A8P
Comment 36 Adam Williamson 2014-04-22 22:03:29 UTC
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.
Comment 37 Doug Johnson 2014-04-22 22:25:33 UTC
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
Comment 38 Adam Williamson 2014-04-23 01:20:09 UTC
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.
Comment 39 Adam Williamson 2014-04-23 23:23:41 UTC
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.
Comment 40 Jin Yao 2014-04-29 06:48:39 UTC
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
Comment 41 Doug Johnson 2014-04-29 07:24:32 UTC
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.
Comment 42 Jin Yao 2014-04-30 01:09:22 UTC
Even with this patch http://dougvj.net/baytrail_gpio_quirk_v4.patch, SDID is still D0 and SDCARD is D0 too (no sdcard inserted).
Comment 43 Doug Johnson 2014-04-30 01:23:16 UTC
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
Comment 44 Philipp Ruess 2014-05-24 11:23:19 UTC
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.
Comment 45 Adam Williamson 2014-06-12 19:47:26 UTC
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?
Comment 46 Adam Williamson 2014-06-24 22:09:43 UTC
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 ~]$
Comment 47 Philipp Ruess 2014-07-06 19:50:54 UTC
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.
Comment 48 Adam Williamson 2014-09-12 09:02:57 UTC
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.
Comment 49 Michael Shigorin 2014-12-01 16:07:26 UTC
(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.
Comment 50 Adam Williamson 2014-12-01 17:49:02 UTC
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.
Comment 51 J M 2015-01-14 05:06:05 UTC
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
Comment 52 Michael Shigorin 2015-01-14 10:25:22 UTC
(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).
Comment 53 J M 2015-01-14 16:53:51 UTC
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.
Comment 54 Alan 2015-01-14 16:57:50 UTC
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.
Comment 55 RussianNeuroMancer 2016-07-29 14:29:35 UTC
Is there any reason why patch from comment 50 is not upstreamed?
Comment 56 Alan 2016-07-29 15:01:20 UTC
Looks like nobody ever submitted upstream
Comment 57 Bastien Nocera 2016-07-29 15:04:01 UTC
(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.
Comment 58 RussianNeuroMancer 2016-07-29 15:09:46 UTC
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?
Comment 59 Alan 2016-07-29 15:15:12 UTC
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.
Comment 60 Bastien Nocera 2016-07-29 15:25:55 UTC
(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
Comment 61 Kalle Valo 2016-07-31 09:24:04 UTC
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.
Comment 62 RussianNeuroMancer 2016-08-01 08:59:42 UTC
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).
Comment 63 RussianNeuroMancer 2016-10-12 04:55:25 UTC
Heads up, is there anyone who willing to submit patch following mentioned rules?
Comment 64 Alan 2016-10-12 14:56:55 UTC
I did and it got ignored - I'll resend it after this merge window
Comment 65 Kalle Valo 2016-10-12 16:16:51 UTC
(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.
Comment 66 Alan 2016-10-12 18:01:50 UTC
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.
Comment 67 Kalle Valo 2016-10-13 05:39:10 UTC
(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/
Comment 68 RussianNeuroMancer 2016-10-13 07:28:03 UTC
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
Comment 69 Alan 2016-10-13 09:56:09 UTC
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.
Comment 70 RussianNeuroMancer 2016-10-13 12:19:34 UTC
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."
Comment 71 Pavel Bludov 2017-06-20 13:36:52 UTC
(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.
Comment 72 RussianNeuroMancer 2018-03-08 15:40:43 UTC
> 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?

Note You need to log in before you can comment on or make changes to this bug.