You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maybe, that thing looks like a full-blown regulator, i.e. for controlling voltages, whereas (I think) the ones used on the Surface devices are for measuring only.
Hmm. My search regarding MAX34417 revealed there appears to be a driver from Maxim https://github.com/MaximIntegratedAI/powermonitor/blob/main/max34417.c Also https://github.com/DanielJeongADI/LKD has one, and IMO a few more (Surface Duo has references to it, too). Searched in GitHub for MAX34417. Integration into max34440.c doesn't seem to fit to well.
I have 3x MAX34417 in the Windows Dev Kit 2023, and I'd like to use hem to find ot which regulators are what power domain, to make the dts better, and get a handle on power management.
Most likely this driver(s) should be located at drivers/iio/adc, as the max34408/9 are. They are current monitors, this one is voltage monitor. Seems like semantically it's related.
P.S. Wondering if you can assign this (for the max34407) to me. It's the only device which seem has no driver in upstream as of v6.14 is out.
Activity
dm crypt: do not wait for backlogged crypto request completion in sof…
dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq
dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq
dm crypt: do not wait for backlogged crypto request completion in sof…
drm/radeon: Fix off-by-one power_state index heap overwrite
drm/radeon: Fix off-by-one power_state index heap overwrite
drm/radeon: Fix off-by-one power_state index heap overwrite
drm/radeon: Fix off-by-one power_state index heap overwrite
um: Mark all kernel symbols as local
um: Mark all kernel symbols as local
drm/radeon: Fix off-by-one power_state index heap overwrite
um: Mark all kernel symbols as local
kasperk81 commentedon Jul 25, 2021
Related upstream proposed patch: https://lists.sr.ht/~postmarketos/upstreaming/patches/10202 (regulator: max77826: Add MAX77826 support). There could be some commonalities to MAX34407 and MAX34417?
qzed commentedon Jul 25, 2021
Maybe, that thing looks like a full-blown regulator, i.e. for controlling voltages, whereas (I think) the ones used on the Surface devices are for measuring only.
kasperk81 commentedon Jul 25, 2021
Ah, I see. The regulator patch is upstream, maybe closer one is https://github.com/torvalds/linux/blob/master/drivers/hwmon/pmbus/max34440.c (pressed T in GitHub file list aka "go to file" and typed drivers/max to get these results).
mm: fix race between MADV_FREE reclaim and blkdev direct IO read
cgroup: fix missing cpus_read_{lock,unlock}() in cgroup_transfer_tasks()
cgroup: fix missing cpus_read_{lock,unlock}() in cgroup_transfer_tasks()
jglathe commentedon Sep 12, 2023
Hmm. My search regarding MAX34417 revealed there appears to be a driver from Maxim https://github.com/MaximIntegratedAI/powermonitor/blob/main/max34417.c Also https://github.com/DanielJeongADI/LKD has one, and IMO a few more (Surface Duo has references to it, too). Searched in GitHub for MAX34417. Integration into max34440.c doesn't seem to fit to well.
I have 3x MAX34417 in the Windows Dev Kit 2023, and I'd like to use hem to find ot which regulators are what power domain, to make the dts better, and get a handle on power management.
md: fix warning for holder mismatch from export_rdev()
andy-shev commentedon Apr 21, 2025
Most likely this driver(s) should be located at drivers/iio/adc, as the max34408/9 are. They are current monitors, this one is voltage monitor. Seems like semantically it's related.
P.S. Wondering if you can assign this (for the max34407) to me. It's the only device which seem has no driver in upstream as of v6.14 is out.