[KERNEL] (Patch) USB OTG (host mode) + simultaneous charging!

(I really struggled with where to post this. Although much work and effort went into debugging unique Z5-specific issues, this is based on prior work so I put it here instead of in "original"; also, I would be very surprised if this didn't apply cleanly and work across the entire Z5 family, not just the Compact, but it might not apply beyond the Z5 so it doesn't make sense to put it in the cross-platform forum, which means I had to pick ONE Z5 family forum to post in. I've only tested on Compact, so I guess it goes here for now.)

I am attaching a set of kernel patches that will allow Z5 users to put their phone's USB port into host mode while simultaneously also allowing the phone to take a charge. In this scenario, the USB device(s) connected to the phone are not getting power from the phone like they normally would in a standard "OTG" scenario, but are sharing with the phone whatever power source is being used to charge the phone.

Acknowledgements:

HUGE thanks...

• ...to @ziddey for his original patch that he developed for the Nexus 4 which was the inspiration behind all of this,
• ...to @sollapse for being the first to successfully implement ACA support in the DWC3 driver,
• ...and to @Phoenix Wright for further refining that code

The patches presented here are based largely off of Phoenix Wright's work.

Background:

I used a Nexus 4 for a long time, and grew accustomed to being able to do this with my Nexus thanks to @ziddey's extremely clever hack. (My personal use-case is a phone dock in my car which both charges the phone and connects it to a USB sound card, which in turn is fed into the auxiliary input of my car's stereo head unit.) In fact, the modification ziddey came up with was both so effective and minimally-invasive that the changes were -- until relatively recently -- easy to apply to just about any Snapdragon-based device (even ones with fully-functioning OTG support, which the Nexus 4 didn'thave), since many of them shared a common USB core, and thus also shared drivers.

I was disappointed to discover upon receiving my Z5 Compact that although for some odd reason that venerable old Snapdragon USB driver was enabled in Sony's kernel's build .config, it wasn't actually being used by the hardware...I patched up the kernel, compiled it, flashed it, and the behavior of the USB port didn't change. Turns out all of the more recent Snapdragons use a new USB 3/SuperSpeed-capable core by Synopsys, part of their DesignWare series, and this core uses an entirely different driver called DWC3. And unlike the older driver, this new one does not implement support for so-called USB "accessory charging adapters" or ACAs (typically vendor-proprietary powered USB hubs that do exactly what we want: charge the phone while putting it in host mode), so in-built support for ACAs couldn't be exploited in the DWC3 driver the way that it had been in the old driver.

Fortunately, @sollapse rose to meet the challenge and whipped up some basic ACA support for the DWC3 driver included in the kernel source tree for the OnePlus One. I took what was largely a re-write of this, done by @Phoenix Wright, and essentially ported that version over to the Z5 kernel while also making some other changes and additions along the way.

Use:

Disclaimer: I cannot be held responsible if any harm should come to you or your phone on account of using these software modifications.

This was developed and tested against the Sony copyleft sources for the kernel that shipped with the last release of Lollipop for the Z5 series (32.0.A.6.200). I plan to also work on versions for the Marshmallow and Nougat kernel releases as well, but wanted to start with something as close to what I was porting from as possible and just deal with one variable at a time. Chances are good that very little changed in the USB drivers in later Z5 kernels anyway. I have also to-date only tried to apply this to an otherwise stock Sony source tree, and running on the stock Sony Lollipop ROM.

This isn't how ACAs are strictly meant to work on a device that officially supports them, but when it comes to this patch, to enable or disable "ACA mode", you need to either pass a certain parameter (aca_enable, should be set to 'Y') to the driver (dwc3) at initialization (during boot / on the kernel command line, so 'dwc3.aca_enable=Y'), or toggle the parameter after boot using sysfs (e.g. 'echo N > /sys/module/dwc3/parameters/aca_enable'). For write access to sysfs, you have to be root, so keep that in mind if you have a requirement to be able to toggle this on and off without a reboot.

Enabling ACA mode merely changes the behavior of the driver when the ID pin/pin 5 on the micro-USB cable is grounded (OTG cable), which indicates to the phone that it should switch to host mode. With ACA mode enabled, it basically doesn't engage the USB host voltage bus regulator and instead activates the battery charging circuitry; however, just like "normal" USB host mode, it still requires an actual OTG cable to work, UNLIKE ziddey's original patch. What this means is that if you want to plug, say, a thumb drive into your phone without having to also supply an external power source, you need to set 'aca_enable' back to 'N' first before this will work again.

Sometimes it is not possible to use an OTG cable in certain situations; for example, there is no way I am going to first cut out and then cut open the non-OTG micro-USB plug from my $80 Proclip car mount in order to turn it into a proper OTG cable. For these situations, ziddey's ingenious idea -- borne out of necessity by the broken ID_GND detection on the Nexus 4 -- of triggering host mode based on the type of charging adapter detected by the phone is extremely useful, and so I implemented a similar feature: by additionally setting 'prop_chg_aca_enable' to 'Y', the driver will switch to USB host mode if a so-called "proprietary" charging source is detected (which is apparently what the phone interprets the voltage injected with a USB Y-cable as).

'prop_chg_aca_enable' will have no effect if 'aca_enable' is not also toggled on. I split it out into a separate option, though, because for reasons I haven't had the time to hunt down yet, the charger detection toggle seems (based on extremely limited testing) to make the use of an OTG cable less reliable...sometimes it works, sometimes it engages the host mode but not the battery charger, sometimes it does neither. So if you already use an OTG cable with your particular set-up, I recommend you leave 'prop_chg_aca_enable' off.

Finally, as most of you surely know, the Z5 series (and the Z3+/Z4 before it) introduced a new coverless micro-USB port along with a new requirement that you the user must manually initiate a scan for attached USB gadgets in order for the port to switch over to host mode; presumably they did this so that they could keep the IP68 water ingress protection rating despite the change to a coverless port. Miraculously, when aca_enable is on, because the phone is accepting a charge instead of delivering power in this scenario, there is (in theory) no additional risk from water exposure in this mode and yet you also do NOT need to hit "Detect USB Device" on your phone before you can use the USB device...as long as both external power and a USB device are present on the cable at the moment you plug it in. If you don't have a USB device plugged into your Y-cable, only power, then the device will not be detected later. If you have a need to work around this, you can set 'no_device_timeout_enable' to 'N', which will keep the host controller on-line and engaged for as long as you have a powered OTG cable plugged in.

If you want to *really* live life on the edge, you can also set the 'force_id_polling_on' parameter of the 'qpnp_smbcharger_extension' driver to 'Y' in order to completely disable the need for tapping on "Detect USB Devices" for "normal" OTG mode.

Oh, one more thing I forgot: if you are supplying power through an OTG cable (with ID pin grounded), then you need to set 'dwc3_msm.force_float_on_bsv=N' in order to work around a change Sony made to the driver that causes it to treat powered OTG cables as if they are non-OTG. I don't know why they did this (perhaps just to further reduce the risk of water damage on account of the open port under certain circumstances?), but I added a toggle that bypasses their change.

In summary, here are all of the various driver/module options I have decided to supply to my own kernel at boot time; at a minimum #1 and #4 are mandatory when using a OTG cable and #4 and #5 are mandatory when using a non-OTG cable:

1. dwc3_msm.force_float_on_bsv=N
   (disables Sony "innovation" that prevents a powered OTG cable from switching controller into host mode)
2. qpnp_smbcharger_extension.force_id_polling_on=Y
   (disables the need for "Detect USB Devices" under normal OTG use -- NOTE this could reduce the integrity of the water protection!! Use with caution!)
3. dwc3.no_device_timeout_enable=N
   (disables host mode timeout in the event controller does not detect a device)
4. dwc3.aca_enable=Y
   (enables the new "ACA mode" which allows for the exclusive use of powered OTG cables at the expense of normal OTG use)
5. dwc3.prop_chg_aca_enable=Y
   (additionally allows USB host mode to be triggered by a non-OTG powered Y-cable that also has a USB device attached)

I hope others find this useful, while at the same time I also hope that our USB-C future will eventually end the need for us to dabble in such hackery.

-- Nathan

Phoenix Wright said:

Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there:

Click to expand...

Click to collapse

Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:


...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.

Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:


(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)

Thanks again,

-- Nathan

Phoenix Wright said:

[...] on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.

Click to expand...

Click to collapse

Gotcha, thanks; makes perfect sense. I'm not sure that the same thing is necessarily happening on the Z5...it uses a different battery charge controller than the 1+1 and in fact I ripped out a lot of the 1+1-specific workarounds when preparing my version of the patch. (I still need to do more testing, but in fact I'd say there are some instances where BSV is actually not being detected properly on this platform, which could explain my initial findings...there is a debugfs file exposed where you can check current BSV detection state, but even when phone is getting power it almost always shows "0".)

Nevertheless, I ran some tests:

1. With work=1 set explicitly every time (my addition to your code for my original version of the path), everything with a powered OTG cable and aca_enable=Y worked fine for me.

2. With that removed, it almost never engaged the battery charger, though host mode almost always kicked in.

3. After adding work=1 only if B_SESS_VLD bit was set, working functionality for powered OTG cables was restored (again, as long as my new prop_chg_aca_enable=N).

So I have updated the patch to check for that bit before forcing another workqueue loop, which I believe is "more correct".

Thanks again,

-- Nathan

Adamell0 said:

Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.

Click to expand...

Click to collapse

Sorry, haven't hung out around here in a while...

What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.

If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.

Adamell0 said:

Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.

Click to expand...

Click to collapse

Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)

And you already have the bootloader unlocked on your Z5c, yes?

EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.

Adamell0 said:

I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.

Click to expand...

Click to collapse

I would advise you to not just blindly unlock the bootloader on your Z5c if you haven't done so already. Doing so on the Z5c is irreversible and has permanent consequences unless you prepare in advance / take necessary precautions. (Side note: it's because of stuff like this that I've learned to always search and read up on any potential pitfalls when it comes to doing bootloader unlocks on specific models of phones before just jumping right in!!! Sony is not entirely forthcoming in their warnings on their site about what you lose when you unlock!)

The "necessary precautions" involve backing up what is called the TA partition of the phone before unlocking the bootloader. When you unlock the bootloader, the phone zeroes out all of the DRM keys stored in this sector that are unique to your particular phone (not phone model, your specific unit! if you lose them you can never get them back! and you can't take copies of keys from another Z5c and flash them to your phone unless you want a permanent brick that will never power back on again!). So best to back this up beforehand, both so that you have the option of returning to COMPLETE stock in the future if you so desire (re-lock bootloader, etc.), but also so that you can reflash the keys back to TA while retaining the unlocked bootloader, having the best of both worlds.

Unfortunately, this is a bit of a pain to do, admittedly, since TA partition is normally heavily guarded. It's supposed to be impossible to access, but a bug in older firmwares can be exploited to gain access to it even with a locked bootloader. So this means you have to actually downgrade back to Android 6.0 Marshmallow *just temporarily*, long enough to make a backup of the TA partition. After that, you can re-upgrade back to 7.1 Nougat and proceed with bootloader unlock.

If you decide not to go to the trouble, that's fine, but at least you will be making an informed decision in advance, rather than only finding out about what you lost after it's gone, robbing you of choice.

Link to TA backup utility: https://xdaforums.com/t/universal-dirtycow-based-ta-backup-v2.3514236/

To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.

Adamell0 said:

Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .

Click to expand...

Click to collapse

Check your PM for links and general overview of how to accomplish downgrade/TA backup/upgrade.

Your kernel is also ready, tested, and attached.

Note that this is just the raw kernel with OTG patches included. If you end up backing your TA partition up, you will want to patch this kernel image with the latest version of rootkernel (which adds additional patches to restore functionality lost after bootloader unlock, but are not patches that require a kernel re-compile) and then flash that version.

Also, just in case it wasn't clear in the original post, these patches do not allow you to seamlessly use both traditional non-powered OTG as well as powered OTG...it's one or the other. Non-powered OTG will stop working, and OTG/host mode will only be possible if a power source is also applied. It is possible to disable the powered OTG mode and revert to regular non-powered mode, but it has to be done with a terminal command, and it will return back to powered-only OTG mode after the phone is rebooted.