ChanServ changed the topic of #linux-msm to:
Caterpillar has quit [Ping timeout: 480 seconds]
Caterpillar has joined #linux-msm
Daanct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
jmassot has joined #linux-msm
Caterpillar has quit [Ping timeout: 480 seconds]
Caterpillar has joined #linux-msm
pespin has joined #linux-msm
Caterpillar has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.1.2]
f_ has quit [Ping timeout: 480 seconds]
Caterpillar has joined #linux-msm
f_ has joined #linux-msm
<bamse> arnd: forgot to check with you as well...i merged the pull requests into my 6.8 branches, so they will come there...but you're right i should double check to see if anything should be picked for 6.7
<minecrell> bamse: Can you check why https://patchwork.kernel.org/project/linux-arm-msm/patch/20231004-clk-qcom-smd-rpm-unused-v2-1-9a5281f324dc@kernkonzept.com/ is marked as "Changes Requested"? At least for Konrad's comment we agreed at the end that it is fine as-is
jhovold has quit [Ping timeout: 480 seconds]
Caterpillar has quit [Ping timeout: 480 seconds]
mripard has quit [Quit: mripard]
djakov has joined #linux-msm
djakov_ has quit [Read error: Connection reset by peer]
<calebccff> minecrell: lumag: im confused about the PMIC GPIOs on db410c. The schematics number them starting from 1, and it looks like this was blindly copied to the DTS, it has two LEDs connected to pm8916_gpios "1" and "2", but in the kernel indexing starts from 0 right?
<calebccff> the u-boot DTS uses 0-based indexing for them
<calebccff> I ask because the third GPIO is the USB hub reset pin
<lumag> let me check...
<lumag> calebccff, 1-based
<lumag> gpiochip2: GPIOs 638-641, parent: platform/200f000.spmi:pmic@0:gpio@c000, 200f000.spmi:pmic@0:gpio@c000:
<lumag> gpio1 : out low normal vin-0 pull-down 10uA push-pull high atest-0 dtest-0
<lumag> gpio2 : out low normal vin-0 pull-down 10uA push-pull high atest-0 dtest-0
<lumag> gpio3 : out low normal vin-0 pull-down 10uA push-pull high atest-0 dtest-0
<lumag> gpio4 : out low normal vin-0 pull-down 10uA push-pull high atest-0 dtest-0
<lumag> root@qcom-armv8a:~# cat /sys/kernel/debug/pinctrl/200f000.spmi:pmic@0:gpio@c000/pins
<lumag> registered pins: 4
<lumag> pin 0 (gpio1) 0:200f000.spmi:pmic@0:gpio@c000
<lumag> pin 1 (gpio2) 1:200f000.spmi:pmic@0:gpio@c000
<lumag> pin 2 (gpio3) 2:200f000.spmi:pmic@0:gpio@c000
<lumag> pin 3 (gpio4) 3:200f000.spmi:pmic@0:gpio@c000
<calebccff> lumag: urgh, so u-boot driver is wrong to be 0-based?
<calebccff> or
<calebccff> huh
<minecrell> calebccff: seems like yes? confused about the huh
<calebccff> lumag: ok, yeah i was also confused. I'll adjust u-boot driver to be 1-based
<calebccff> u-boot's GPIO framework is always 0-based, hmm, wtf
pespin has quit [Remote host closed the connection]
Caterpillar has joined #linux-msm
Caterpillar has quit [Ping timeout: 480 seconds]
<bamse> minecrell: looks reasonable