bcl: Defer probe until battery power supply is ready

When the battery supply isn't ready and probe finishes anyway, the gvotable
callback can trigger a NULL pointer dereference if an soc check hasn't had
the opportunity to initialize bcl_dev->batt_psy once the battery power
supply is ready:
  [  136.493967] Unable to handle kernel NULL pointer dereference at virtual address 00000000000003b0
  [  136.493998] Mem abort info:
  [  136.494007]   ESR = 0x0000000096000006
  [  136.494018]   EC = 0x25: DABT (current EL), IL = 32 bits
  [  136.494032]   SET = 0, FnV = 0
  [  136.494042]   EA = 0, S1PTW = 0
  [  136.494050]   FSC = 0x06: level 2 translation fault
  [  136.494061] Data abort info:
  [  136.494069]   ISV = 0, ISS = 0x00000006
  [  136.494078]   CM = 0, WnR = 0
  [  136.494083] google,charger google,charger: chg_psy_changed name=tcpm-source-psy-i2c-max77759tcpc evt=0
  [  136.494087] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000b5807000
  [  136.494097] [00000000000003b0] pgd=08000000b5806003, p4d=08000000b5806003, pud=08000000b5806003, pmd=0000000000000000
  [  136.494126] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
  [  136.494157] debug-snapshot dss: context saved(CPU:6)
  [  136.494523] google,charger google,charger: chg_psy_changed name=usb evt=0
  [  136.494732] item - log_kevents is disabled
  [  136.494754] CPU: 6 PID: 242 Comm: wq-bcl-usb Tainted: G S                 6.1.134-Sultan #1
  [  136.494772] Hardware name: ZUMA PRO KOMODO MP board based on ZUMA PRO (DT)
  [  136.494782] pstate: 62400005 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
  [  136.494800] pc : google_bcl_usb_votable_callback+0x60/0x1c0
  [  136.494852] lr : gvotable_cast_vote.lto_priv.0+0x204/0x30c
  [  136.494909] sp : ffffff80077c3d50
  [  136.494917] x29: ffffff80077c3d70 x28: 00000000bb1ac47f x27: ffffff8004ce5ad0
  [  136.494940] x26: 0000000000000001 x25: ffffff8004ce5a40 x24: ffffff8004ce5a20
  [  136.494957] x23: 0000000000000000 x22: 0000000000000001 x21: 0000000000000000
  [  136.494973] x20: ffffff8004ce5a00 x19: ffffff8003642040 x18: 0000000000000000
  [  136.494989] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000008
  [  136.495005] x14: 6e6f635f71726900 x13: ffffffffffffff00 x12: 0000000000000000
  [  136.495021] x11: 0101010101010101 x10: 0000006c99657d28 x9 : 0000000000000038
  [  136.495039] x8 : 0101010101010101 x7 : 5245544f565f4253 x6 : 0000000000000080
  [  136.495055] x5 : 0000000000000000 x4 : ffffff80190fc4c0 x3 : ffffffec9dc49740
  [  136.495071] x2 : 0000000000000000 x1 : ffffff80190fc4c0 x0 : 0000000000000000
  [  136.495087] Call trace:
  [  136.495095]  google_bcl_usb_votable_callback+0x60/0x1c0
  [  136.495113]  gvotable_cast_vote.lto_priv.0+0x204/0x30c
  [  136.495134]  bcl_usb_vote_work+0x40/0x78
  [  136.495184]  kthread_worker_fn.lto_priv.0+0xcc/0x1c0
  [  136.495213]  kthread+0xf4/0x100
  [  136.495226]  ret_from_fork+0x10/0x20
  [  136.495273] Code: 397fc260 36000420 f9402260 b40003e0 (b943b001)

Fix this by just deferring probe until the battery power supply is ready.

Note that this doesn't call power_supply_put() on batt_psy because the
existing code already egregiously leaks the power_supply struct, so don't
bother with the power_supply_put().

Signed-off-by: Sultan Alsawaf <[email protected]>

bcmdhd: Affine dhd_dpc kthread to CPUs 0-7

Sometimes there are periods during which dhd_dpc spikes in load visible via
top command. Allowing dhd_dpc to use all CPUs migrates work during those
periods, which can happen all 40-70 seconds, to the prime CPU. Migration to
the prime CPU during those periods consumes a lot of energy.

Affine dhd_dpc thread to little and mid CPUs to prevent that.

Results from zumapro:
Before:
  Subdomain            Avg Power
  S4M_VDD_CPUCL0:        161 mW
  S2M_VDD_CPUCL1:         40 mW
  S3M_VDD_CPUCL2:        788 mW
  S9M_VDD_CPUCL1_M:       11 mW
  S5M_VDD_INT:            20 mW
  S1M_VDD_MIF:            75 mW
  S2S_VDD_G3D:             1 mW

  Total:                1096 mW

After:
  S4M_VDD_CPUCL0:        121 mW
  S2M_VDD_CPUCL1:        148 mW
  S3M_VDD_CPUCL2:          0 mW
  S9M_VDD_CPUCL1_M:       11 mW
  S5M_VDD_INT:            17 mW
  S1M_VDD_MIF:            71 mW
  S2S_VDD_G3D:             1 mW

  Total:                 369 mW

[Sultan: rewrote the code to use a hex mask rather than a string, set the
         affinity mask to CPUs 0-7 for zuma]
Signed-off-by: Sultan Alsawaf <[email protected]>

bcmdhd: Downgrade the DPC thread from SCHED_FIFO to SCHED_NORMAL

When there is heavy WiFi traffic, the DPC thread can starve user processes
that are waiting for packets over WiFi because the DPC thread is a
real-time task, so it preempts all fair-scheduled tasks. This can result in
noticeable system-wide stutters.

Downgrade the DPC thread's scheduling class so that it is a fair-scheduled
task with a nice value of 0, which is the default for a freshly-created
kthread.

This makes the DPC thread behave more similarly to tasklets since ksoftirqd
is a fair-scheduled task with a nice value of 0.

Signed-off-by: Sultan Alsawaf <[email protected]>

bcmdhd: Downgrade the DPC thread from SCHED_FIFO to SCHED_NORMAL

When there is heavy WiFi traffic, the DPC thread can starve user processes
that are waiting for packets over WiFi because the DPC thread is a
real-time task, so it preempts all fair-scheduled tasks. This can result in
noticeable system-wide stutters.

Downgrade the DPC thread's scheduling class so that it is a fair-scheduled
task with a nice value of 0, which is the default for a freshly-created
kthread.

This makes the DPC thread behave more similarly to tasklets since ksoftirqd
is a fair-scheduled task with a nice value of 0.

Signed-off-by: Sultan Alsawaf <[email protected]>

exynos-bts: Convert btsdev->mutex_lock into an rt_mutex lock

The DPU (display) performs BTS voting from decon0_kthread, which has
real-time scheduling priority. The ISP (camera) performs BTS voting from
tasks of varying _normal_ scheduling priority, _not_ real-time scheduling
priority.

As a result, when decon0_kthread needs to wait for btsdev->mutex_lock to be
unlocked, there is a priority inversion where the real-time decon0_kthread
task must wait for the lower-priority mutex owner to finish using the lock.

Fix the priority inversion by converting btsdev->mutex_lock into an
rt_mutex lock.

Signed-off-by: Sultan Alsawaf <[email protected]>

cs35l41: Fix out-of-bounds bit shift in cs35l41_otp_unpack()

UBSAN generates the following splat:
[    2.748114] ================================================================================
[    2.748116] UBSAN: shift-out-of-bounds in ../google-modules/amplifiers/cs35l41/cs35l41.c:1936:5
[    2.748122] shift exponent 64 is too large for 64-bit type 'long unsigned int'
[    2.748128] CPU: 4 PID: 380 Comm: modprobe Tainted: G S                 6.1.84-Sultan #1
[    2.748133] Hardware name: ZUMA PRO TOKAY MP board based on ZUMA PRO (DT)
[    2.748136] Call trace:
[    2.748139] show_stack+0xa4/0xb0
[    2.748158] dump_stack_lvl+0x68/0x80
[    2.748171] dump_stack+0x18/0x30
[    2.748174] ubsan_epilogue+0x10/0x40
[    2.748196] __ubsan_handle_shift_out_of_bounds+0xd0/0x170
[    2.748207] cs35l41_probe+0x1700/0x1850
[    2.748231] cs35l41_spi_probe+0x80/0xc0
[    2.748234] spi_probe+0x84/0xdc
[    2.748248] really_probe+0xc8/0x390
[    2.748256] __driver_probe_device+0x84/0x150
[    2.748258] driver_probe_device+0x38/0x120
[    2.748261] __driver_attach+0x80/0x160
[    2.748264] bus_for_each_dev+0x78/0xd0
[    2.748287] driver_attach+0x24/0x2c
[    2.748291] bus_add_driver+0x150/0x220
[    2.748294] driver_register+0x74/0x120
[    2.748299] __spi_register_driver+0xc4/0xd0
[    2.748311] cs35l41_spi_driver_init+0x1c/0x24
[    2.748322] do_one_initcall+0x70/0x238
[    2.748325] load_module+0x5ac/0x850
[    2.748338] __arm64_sys_finit_module+0xa8/0x100
[    2.748344] invoke_syscall.constprop.0+0x50/0xe0
[    2.748355] do_el0_svc+0x50/0x120
[    2.748358] el0_svc+0x18/0x58
[    2.748362] el0t_64_sync_handler+0x110/0x11c
[    2.748368] el0t_64_sync+0x170/0x174
[    2.748371] ================================================================================

Which occurs with the following observed state:
[    2.748110] cs35l41 spi19.0: otp_map[i].reg=0 otp_mem[word_offset]=00080000 bit_offset=0 otp_map[i].size=0 GENMASK(-1, 0)

And the trigger is the GENMASK(-1, 0).

Since otp_val is only used when otp_map[i].reg != 0, fix the UBSAN splat by
only setting otp_val when otp_map[i].reg != 0.

Signed-off-by: Sultan Alsawaf <[email protected]>

sbalance: Fix severe misattribution of movable IRQs to the last activ…

…e CPU

Due to a horrible omission in the big IRQ list traversal, all movable IRQs
are misattributed to the last active CPU in the system since that's what
`bd` is last set to in the loop prior. This horribly breaks SBalance's
notion of balance, producing nonsensical balancing decisions and failing to
balance IRQs even when they are heavily imbalanced.

Fix the massive breakage by adding the missing line of code to set `bd` to
the CPU an IRQ actually belongs to, so that it's added to the correct CPU's
movable IRQs list.

Signed-off-by: Sultan Alsawaf <[email protected]>

zuma_defconfig: Remove more unused drivers

Remove more drivers which are unused on the production Pixel 8 series.

Signed-off-by: Sultan Alsawaf <[email protected]>

cpufreq: schedutil: Allow single-CPU frequency to drop without idling

Given that a CPU's clock is gated at even the shallowest idle state,
waiting until a CPU idles at least once before reducing its frequency is
putting the cart before the horse. For long-running workloads with low
compute needs, requiring an idle call since the last frequency update to
lower the CPU's frequency results in significantly increased energy usage.

Given that there is already a mechanism in place to ratelimit frequency
changes, this heuristic is wholly unnecessary.

Allow single-CPU performance domains to drop their frequency without
requiring an idle call in between to improve energy. Right off the bat,
this reduces CPU power consumption by 7.5% playing a cat gif in Firefox on
a Pixel 8 (270 mW -> 250 mW). And there is no visible loss of performance.

Signed-off-by: Sultan Alsawaf <[email protected]>

sched/fair: Disable CACHE_HOT_BUDDY to leverage DynamIQ Shared Unit

In a similar vein to setting sysctl_sched_migration_cost to zero, disable
CACHE_HOT_BUDDY to better leverage the DynamIQ Shared Unit (DSU). With the
DSU, L2$ and L3$ locality isn't lost when a task is migrated to another
intra-DSU core.

Signed-off-by: Sultan Alsawaf <[email protected]>