ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
apritzel has quit [Ping timeout: 268 seconds]
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #armlinux
Xogium has quit [Quit: Leaving.]
Xogium has joined #armlinux
Xogium has quit [Quit: Leaving.]
Xogium has joined #armlinux
Nact has quit [Quit: Konversation terminated!]
alpernebbi has joined #armlinux
apritzel has joined #armlinux
<wens_>
just realized that arm-soc repo was changed to soc
frieder has joined #armlinux
audgirka has joined #armlinux
<geertu>
wens_: They're still kept in sync, aren't they?
<ukleinek>
geertu: I wrote to you in reply to your regression report of d7bff84fe7ed8c3b that you can contact me via irc. In case you're not aware who to contact: That's /me :-)
<geertu>
ukleinek: thanks!
<geertu>
Will debug later today
apritzel has quit [Ping timeout: 256 seconds]
<ukleinek>
geertu: I look forward to your report and wonder if my change is broken or if it "only" uncovers a problem in the driver.
nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
Pali has joined #armlinux
sszy has joined #armlinux
nsaenz has quit [Quit: Leaving]
nsaenz has joined #armlinux
<mort>
javierm: regarding yesterday: the reeeeally fun thing is that if Linux still warned about setting unused config values, this would've just been a compile-time error the very first time I tried to compile the new kernel and debugging would've started at "why did the old kernel have the LEDS_QCOM_LPG driver but the new kernel doesn't"
<mort>
not 100% sure removing that error was a good idea
<wens_>
geertu: arm-soc no longer appears on the listing on git.kernel.org, so I was a bit confused when I wanted to add the url in another repo
wens_ is now known as wens
<geertu>
wens: Indeed. The repo is still there though.
<arnd>
not sure if this was intended, but I wouldn't change it now. I think the asm-soc.git there is a symlink on the server that we left after the migration. It's possible that the web gui stopped showing symlinks
<arnd>
We don't actively update arm-soc.git, so it's always the same as soc.git
<geertu>
arnd: OK, I thought it was a manual process :-)
<geertu>
Will drop the remote
nsaenz has quit [Remote host closed the connection]
<geertu>
No need to keep on checking if they are identical ;-)
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<javierm>
mort: ah, I didn't even notice that there wasn't a warning anymore
apritzel has joined #armlinux
Pali has quit [Ping timeout: 265 seconds]
Crassus has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 256 seconds]
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
CrashTestDummy2 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 240 seconds]
wwilly has quit [Ping timeout: 265 seconds]
atorgue has quit [Read error: Connection reset by peer]
atorgue has joined #armlinux
Crassus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mort>
I don't understand. I have a driver which is enabled by CONFIG_LEDS_QCOM_LPG, defined in a Kconfig file and with code in a Makefile which uses that option. The LEDS_QCOM_LPG option shows up when searching the menuconfig. I set `CONFIG_LEDS_QCOM_LPG=y` in a kernel config fragment (.cfg) file and compile linux with that .cfg file. The kernel compiles
<mort>
successfully. But when I boot into that kernel and zcat /proc/config.gz, it doesn't mention anything about QCOM_LPG
<javierm>
mort: what's your resulting .config ?
<javierm>
because maybe the config fragment is not picked ? That is, config fragments are just a convention but you need to use ./scripts/kconfig/merge_config.sh to merge those bits
<broonie>
Also check that there's no dependencies for it missing, the config is checked during build and things that can't be enabled will be dropped.
<javierm>
indeed
<mort>
wait it doesn't error if you enable something with unmet dependencies? It just silently ignores your config?
<mort>
anyways, missing deps shouldn't be an issue, all the dependencies are =y according to the menuconfig
<javierm>
mort: I believe ./scripts/kconfig/merge_config.sh will complain but make prepare modules_prepare won't AFAIK
<mort>
I don't think that's after the configs, there are config options I set but which are commented as not set in that .config
<javierm>
mort: you are using a bitbake recipe right? can you share the relevant snippet ?
<broonie>
There's no error on missing deps, just warnings, in order to handle upgrades gracefully.
wwilly has joined #armlinux
scosu_ has quit [Ping timeout: 250 seconds]
<javierm>
yeah, kconfig symbols are not considered and ABI an can change between releases
<javierm>
*an
<mort>
the recipe is here: https://p.mort.coffee/E4m - that pm8916-pwm.cfg file just contains "CONFIG_LEDS_QCOM_LPG=y"
<javierm>
mort: hmm, seems correct. Are the symbols from the other fragments present in your final .config ?
<mort>
There's a bunch of options I'm setting to =n in .cfg files but which are marked as not set in the .config I linked, for example I have CONFIG_REMOTEPROC=n but the .config contains "# CONFIG_REMOTEPROC is not set"
<j`ey>
mort: thats the same as =n
<mort>
I haven't found anything I'm setting to =m or =y which isn't in the .config
<mort>
I'm relatively certain that CONFIG_MWIFIEX_USB is =n by default, but one of my .cfg files is setting it to =m and it's =m in the .config
<javierm>
mort: so I would take your config and try to do just do ./scripts/config --enable CONFIG_LEDS_QCOM_LPG
<javierm>
I think broonie is correct and should be some missing dependency that prevents that option to be enabled
<javierm>
although that only depends on LEDS_CLASS that you already have enabled...
<javierm>
mort: anyways, trying to enable manually would be easier to troubleshoot
<mort>
`./scripts/config --enable CONFIG_LEDS_QCOM_LPG` just works
<mort>
and the .config is updated to contain CONFIG_LEDS_QCOM_LPG=y
wwilly has quit [Ping timeout: 256 seconds]
wwilly has joined #armlinux
wwilly has quit [Remote host closed the connection]
wwilly has joined #armlinux
<javierm>
mort: Ok, then it's something in your bitbake recipe or the bitbake cache I guess
<mort>
building with -v, the one line which looks relevant is: "Value of CONFIG_LEDS_QCOM_LPG is redundant by fragment /mnt/yocto-ev2/build/tmp/work/ev2-poky-linux/linux-linaro-qcomlt/17.06-r0/pm8916-pwm.cfg:"
Nact has joined #armlinux
<javierm>
mort: interesting... but I wouldn't expect it to disable due that
<mort>
and assuming NEW_VAL=y, that just means it's enabled by default which makes enabling it in the fragment unnecessary
<mort>
actually, let me patch merge_configs.sh to print the value when it shows that message
<mort>
just to verify it's actually =y
<mort>
indeed, it thinks the previous value is =y
<mort>
I don't understand this at all
<mort>
javierm: do you know if config options have to be specified anywhere else than in the one relevant Kconfig file?
<javierm>
mort: no, just in the Kconfigs (and Makefiles or course so kbuild can build and include the object files if enabled)
scosu has joined #armlinux
<mort>
https://p.mort.coffee/Cj8.auto so there's nothing missing here, it adds the config option to a Kconfig and uses it in a Makefile
<javierm>
mort: ah, but that has more dependencies than the patch posted to the mailing list that you shared
<javierm>
mort: you are missing LEDS_CLASS_MULTICOLOR for example in your .cofing
<mort>
hmm, shouldn't *something* have printed something at this point about that though? I did compile with -v and grepped through the output
<mort>
well, I removed that dependency, and now the leds-qcom-lpg.c file gets compiled at least
<mort>
(which I know because it errors because led-class-multicolor.h doesn't exist, but that's another issue)
<mort>
I would've assumed that "the user requests a config option, that config option exists, but it depends on something which isn't enabled" would be an error or at least a warning :(
<javierm>
mort: which makes sense since you removed the dependency. You need to either add another config fragment enabling the LEDS_CLASS_MULTICOLOR or add that to your pwm config fragment
<javierm>
mort: and yeah, I can't remember now when it complains but for sure we are lacking on debug messages to catch these
<mort>
I don't think this kernel has LEDS_CLASS_MULTICOLOR, it's probably a patch targeting a newer kernel
<mort>
it feels stupid, this seems to be a combined PWM+LED driver but we just need the PWM part to drive a backlight yet we can't use the newest version because our kernel doesn't have a concept of multicolor LEDs
<mort>
I wonder if it's easier to forward-port the 2017 patch to 5.7 or remove multicolor support from the 2020 patch
<mort>
..and they say upgrading linux is easy
<javierm>
mort: who said that :)
<mort>
every other talk I've seen from greg complains that people aren't just taking his changes on a regular basis and that everyone is too slow at upgrading their kernels and that it's easy
<mort>
https://patches.linaro.org/patch/466103/ this is the latest patch in this series, it's from june 23 and with a comment from june 25, so it's probably going to be mainlined *eventually*
<mort>
maybe it'll even be there for linux 6 and I can get rid of this patch in 2035
audgirka has quit [Remote host closed the connection]
<mort>
I got the new patch to compile by commenting out everything related to RGB and copy/pasting from the led-class-multicolor header, so that's nice
<ukleinek>
geertu: the log snippet in your mail corresponds to some debug printks with the patch reverted, right?
<ukleinek>
geertu: ah, this is a diff
sszy has quit [Ping timeout: 265 seconds]
<geertu>
ukleinek: yep, it's a diff
<ukleinek>
geertu: that the first pwm_config goes away is expected, the second however should stay
* ukleinek
sees a bug but I think this one doesn't trigger for you.
<ukleinek>
(i.e. if you have .duty_cycle = A, .period = B configured and then call pwm_apply(pwm, { .duty_cycle = C, .period = D, .enabled = false}) and then pwm_apply(pwm, {.duty_cycle = C, .period = D, .enabled = true }) .pwm_config isn't called but it should.