<Armbian-Discord> <m​arcone> hmm, the community Radxa Zero image on https://github.com/armbian/community/ doesn't appear to have working USB OTG.
<Armbian-Discord> <m​arcone> the UDC driver is there and can be configured, but it doesn't actually seem to do anything: the attached host doesn't see a device.
<Armbian-Discord> <m​arcone> It works with the Radxa image, so I know the hardware and cable are good.
<Armbian-Discord> <n​armstrong> @marcone usb mode switching must not be implemented on these boards since they use usb-code
<Armbian-Discord> <n​armstrong> with manual switch it will work
<Armbian-Discord> <m​arcone> Well like I said it works with the radxa image, so the problem is with the software, not the hardware.
<Armbian-Discord> <T​onymac32> Well, which kernel is Radxa using, vs the community Armbian one?
<Armbian-Discord> <c​0rnelius> some 5.10 kernel I believe.
<Armbian-Discord> <n​armstrong> @marcone you’re invited to submit patches to add support for this upstream or contact Radxa to ask them to upstream the support, thanks
<Armbian-Discord> <c​0rnelius> i think dr_mode = "host"; just needs to be removed from &usb. If I'm reading correctly what he is trying to do.
<Armbian-Discord> <n​armstrong> For his use case yes, proper DRD support should be implemented with the PD controller. Seems radxa did that
<Armbian-Discord> <r​pardini> here's what Radxa is doing... exactly what c0rnelius said... https://github.com/radxa-repo/bsp/blob/main/linux/stable/0020-radxa-zero/0005-arm64-dts-radxa-zero-set-dr_mode-of-usb-node-to-otg.patch
<Armbian-Discord> <r​pardini> I'm still a bit confused at Radxa's "bsp" repo vs the "debos" images they offer... not sure what ends up where...
gordea has joined #armbian-amlogic
gordea has quit [Client Quit]
<Armbian-Discord> <m​arcone> I checked dr_mode on the booted device, and it was set to "peripheral" for the USB port in question, so on the surface it looked like it should work. And IIRC it worked on an Armbian image that @c0rnelius built for me to try out a few weeks ago when I first found that official Armbian image didn't work.
<Armbian-Discord> <m​arcone> It's just not working with this community image (which I'm only trying because the official image doesn't work). I suppose it could be that upstream is broken (assuming that by "upstream" you mean kernel.org), but it seems more likely to me that the problem is in the way the community image was built. I guess I'll try building my own and see what I get.
gordea has joined #armbian-amlogic
<Armbian-Discord> <m​arcone> But speaking of submitting patches: what is Armbian's policy on failed lint/shellcheck on PRs? I submitted a PR (unrelated to the OTG issue), but it failed shellcheck because of existing code, not because of my changes.
<Armbian-Discord> <I​gorPec> we enabled this not long ago and the rule is - if you touch the script, fix shellcheck too
<Armbian-Discord> <I​gorPec> this is how we did it at my full time job back then, but here we have community development
<Armbian-Discord> <m​arcone> Not to point fingers, but this change was merged 9 days, with shellcheck errors: https://github.com/armbian/build/pull/4436
<Armbian-Discord> <m​arcone> Or do you mean it was checking, but not enforcing at that time?
<Armbian-Discord> <m​arcone> (ok, 11 days ago, not 9)
<Armbian-Discord> <m​arcone> there was another change 9 days ago that also ignored shellcheck errors
<Armbian-Discord> <I​gorPec> we haven't started this rule, just technology was enabled like two weeks ago or smth
<Armbian-Discord> <m​arcone> less than 9 days, apparently 🙂
<Armbian-Discord> <m​arcone> well, 9 days for the "you fix it" rule 🙂
<Armbian-Discord> <I​gorPec> possible. i was in the bed whole week 😦 lost touch with time
<Armbian-Discord> <I​gorPec> in fact shellcheck was around for awhile and once someone tried with automation ... which was epic fail
<Armbian-Discord> <I​gorPec> then we put it on a side
<Armbian-Discord> <I​gorPec> also there is major rework of scripts going on where this is addressed OOB
<Armbian-Discord> <m​arcone> it would be nice if there was a way to filter out shellcheck errors that aren't due to the PR being checked. That way new code could conform, while old code could be fixed when opportunity arises. Having a blanket "you touch it you fix everything" rule makes it kind of daunting to make even minimal changes, because it can mean fixing hundreds of existing problems first.
<Armbian-Discord> <r​pardini> Heh. Go fix the stuff. I've solved 95% of shellcheck warnings on lib/ already by myself.
<Armbian-Discord> <I​gorPec> shellcheck is done on files that are changing
<Armbian-Discord> <I​gorPec> yeah, i also think we can continue ignoring shellcheck
<Armbian-Discord> <r​pardini> The board-side scripts though, they break on the user's faces, and a strict shellcheck should be in place for those
<Armbian-Discord> <r​pardini> Also, shellcheck catches a lot of stuff, but not everything, so no silver bullet.
<Armbian-Discord> <I​gorPec> this is one of those
<Armbian-Discord> <I​gorPec> and those you probably didn't touch ?
<Armbian-Discord> <m​arcone> Sure, but I mean within files. Kinda like the kernel's "checkpatch", which can ignore pre-existing problems and only check new/changed lines within a file. In this case the relatively small file I changed had 33 existing shellcheck errors.
<Armbian-Discord> <m​arcone> And don't get me wrong, I like shellcheck, I use it in my own project too.
<Armbian-Discord> <m​arcone> anyway, it's a moot point because shellcheck doesn't support that AFAIK
<Armbian-Discord> <m​arcone> (though I suppose some post-check filtering could be done, but that's probably more work than just fixing everything)
<Armbian-Discord> <r​pardini> Yeah. Again, easier to just fix.
<Armbian-Discord> <I​gorPec> i know what you mean, but this is the way to deal with this. if we had like some praticants around, we would give them such work
<Armbian-Discord> <I​gorPec> but its us or its not done 🙂
<Armbian-Discord> <m​arcone> so I assume that putting something like # shellcheck disable=SC1091is frowned upon?
<Armbian-Discord> <I​gorPec> disable if not other way, yes
<Armbian-Discord> <m​arcone> (that particular one is for shellcheck not following files that it can't find, so should be fixed by changing the shellcheck invocation itself)
<Armbian-Discord> <r​pardini> SC1091 you can solve better by # shellcheck source=xxx
<Armbian-Discord> <m​arcone> for example [[ -f /etc/os-release ]] && . /etc/os-release, where the file in question isn't even present in the project, so source=xxx won't help either.
<Armbian-Discord> <r​pardini> yeah in those cases it's the same, source=/dev/null or just ignore SC1091
<Armbian-Discord> <m​arcone> ha, clever, pointing it at /dev/null
<Armbian-Discord> <m​arcone> (that made me wonder if I could point it at itself and have it loop infinitely, but either it treats it the same as /dev/null, or it doesn't recurse)