Skip to content

device/husky: MODEM-PLAN.md, S1 to S5e with results - #514

Open
Somnius wants to merge 1 commit into
derekross:mainfrom
Somnius:husky-modem-plan-1108
Open

Somnius wants to merge 1 commit into
derekross:mainfrom
Somnius:husky-modem-plan-1108

Conversation

@Somnius

@Somnius Somnius commented Nov 8, 2026

Copy link
Copy Markdown
Contributor

This is the modem plan @derekross asked for on kernel #187: S1 to S5e on the 8 Pro with the steps, the gates, the stop conditions, the dated results and the uname -r of each stage. Where a log didn't print the release itself, the file says which image set was flashed. It also has an "on hold" section (no more modem steps, no power lines until the answer on #472) and a list of what is still unknown.

The code that ran is on a public branch: https://github.com/Somnius/linux-omarchy-mobile/tree/husky-modem-cpif-test-hook (a test only debugfs hook, not for merge).

It's docs only. I ran tools/pr-check against main, it passes. I didn't run the whole tests/all, CI will.

…ated results and uname -r

Signed-off-by: Lef <me@lefteros.com>
@derekross

Copy link
Copy Markdown
Owner

@Somnius thank you for writing this up so quickly and for stopping when I asked. It's a careful record: one flash per stage, the retry counts, the UFS counters at every step, and for each stage what it does and doesn't prove. I read the hook on your branch and it does what the plan says: only the stock line helpers, no state change, no CP memory, no PCIe and no PMU. I also checked that Google's gpio_power_off_cp() and gpio_power_offon_cp() are the same as in your tree, and that the PMU readings came through the driver's SMC-backed regmap rather than from userspace. Thanks as well for the NV check. All eight match, and devinfo differing is expected.

A few things to fix in the file before I merge it:

  1. Times and the hold. Please give the time zone (or use UTC). Going by your commits, these are UTC+2, which puts S3 at 19:15 UTC, after your question on docs: husky roadmap and DEVICES row brought up to 2026-11-07 #472 at 18:04 UTC. Please say plainly in the status and in "Current state" that S3 to S5e ran after that question and before an answer. As it reads now, it sounds as if only S6 was waiting, and the record should be complete.
  2. Stock citations. Please cite Google's tree, as on device/husky: UFS-PLAN: U4, the Omarchy image boots #187: kernel/google-modules/radio/samsung/s5300, branch android-gs-shusky-6.1-android16. The line numbers there differ from yours: gpio_power_off_cp() is 906-918, gpio_power_offon_cp() 921-933, clear_boot_stage() is called at 1000, and the ap2cp-pda-active/dump-noti pair and the two init_ctrl_msg() calls in power_on_cp() are 1022-1027 (the plan has 874-903 and 990-991).
  3. The hook's description. The plan says gpio_on is refused unless all seven AP2CP lines read 0, but the published hook checks six and lets pda_active be 1, which S5e's E3 needs. Also, S5a and S5b ran a build without the pda_active file. Please say which build that was (a blob id, or "the same code without that file").
  4. The NV check as a gate. The checksum check of efs, efs_backup, modem_userdata, persist and modem_a/b is meant to come before radio work. Here it ran afterwards (and matched, which is good). Please record that, and make it the first gate of any later stage.
  5. What ran, in the repository. The overlays that enabled pcie_0 and its PHY, the modem node and modem-s4-cpif, the S3 module with one link try, and s5b.sh to s5e.sh aren't in either repository yet. The overlays belong in device/husky/overlays/. The scripts can go in device/husky/bringup/, or be described step by step in the plan. The S3 module change can just be a sentence.
  6. Leftovers on the phone. The S5 setup writes /etc/modprobe.d/modem-test.conf and pushes a test cpif.ko, but the plan never removes them. Is the blacklist file still there on your normal NFC set? A file in /etc/modprobe.d replaces a package's file of the same name, so please add its removal (or why it stays) to "Current state".

Smaller ones:

  • On the 8 Pro a hung kernel needs Power + Volume Up for 15-30 s, not the power button alone. Please also say whether anything armed and fed a watchdog during S3-S5, or that the steps were attended with the buttons as the way back.
  • S5d and S5e were on battery on purpose, for the current reading. Our rule keeps modem tests on the charger, so please note why those two weren't (92 %, short runs).
  • "The dead-screen kit" needs a sentence or a link.
  • For S6, when it comes: each step will need an Expect line, a rollback and a risk level as well as the stop rules, with the NV check first.

I still owe you the answer on #472, and S6 waits for it. Nothing else to run on the modem until then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants