stikonas has quit [Quit: Konversation terminated!]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
dsimic has quit [Ping timeout: 246 seconds]
dsimic has joined #linux-rockchip
krei-se has quit [Ping timeout: 248 seconds]
krei-se has joined #linux-rockchip
smaeul has joined #linux-rockchip
smaeul_ has quit [Ping timeout: 260 seconds]
<naoki>
oh I forgot to add Fixes tag for rfkill patch...
<naoki>
can I add tag by reply to myself ;)
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #linux-rockchip
hexdump0815 has quit [Ping timeout: 255 seconds]
<naoki>
oops
hexdump0815 has joined #linux-rockchip
Daanct12 has joined #linux-rockchip
raster has joined #linux-rockchip
Daanct12 has quit [Ping timeout: 276 seconds]
mps has quit [Ping timeout: 244 seconds]
warpme has joined #linux-rockchip
Daanct12 has joined #linux-rockchip
<naoki>
mmind00: hmm... how can I use dual-role type-C USB port? I can use it as host if I add dr_mode = "host", but I cannot use it as host without it
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-rockchip
Stat_headcrabbed has joined #linux-rockchip
<naoki>
dsimic: I (temporary?) lost your last mail due to XXXX e-mail server in that country :(
<naoki>
dsimic: there was cover letter in v1, I forgot to send it in v2 XD
<a3f>
a1batross, that sounds like debugging output from a routine setting SD/MMC clock.
<a3f>
400kHz is the initial frequency for the SD/MMC probe
<a3f>
naoki, did you try dr_mode = "otg"?
<dsimic>
naoki: regarding the additional Fixes tag, maybe it would be better to submit the next version of the patch
<qschulz>
naoki: look into lore.kernel.org/linux-rockchip and you can get an mbox from there to be able to reply to dsimic
<naoki>
a3f: I'm not talking about how to use dr_mode. (btw "otg" is default"
<qschulz>
naoki: the default for dr_mode should be otg except if overridden in some DTS IIRC
<naoki>
dsimic: about Fixes, yes
<naoki>
qschulz: yes, I just did it :) thanks
<qschulz>
naoki: it could be an issue with the ID pin then
<qschulz>
naoki: either HW level or missing some configuration in the DT
<dsimic>
naoki: how do you send patches, so cover letters can be lost? :) I'm just curious
<dsimic>
I write cover letters as branch descriptions, which makes it rather impossible for them to become lost (unless there's some bug or misconfiguration in Git, of course)
<qschulz>
dsimic: i can highly recommend b4
<qschulz>
this is also MUCH more beginner friendly than git-send-email and the likes
<qschulz>
handles versioning series, diffing between versions, etc...
<dsimic>
qschulz: I see, but I currently have no need for b4, my "manual" approach works great for me, after spending many days on defining Git aliases, etc. :)
<dsimic>
naoki: I prefer to see patches on the mailing list :)
<naoki>
I'll send it with cover letter ;)
<dsimic>
great, thanks
<qschulz>
dsimic: I was fine with my workflow too but the fact that b4 tags the current commit after sending it, manages the versions for me, handles adding people to Cc/To and allows to run checkpatch on all patches... :)
<dsimic>
qschulz: I see, it surely comes with quite a few benefits
<qschulz>
dsimic: also, it's not kernel-specific though it is mostly used there
<naoki>
my manual approach seems to be trash lol
<qschulz>
but Buildroot has support for it too, U-Boot as well, and Yocto is getting there
<dsimic>
sure, it shouldn't be specific to any project
<dsimic>
perhaps b4 is better for someone who doesn't want to spend days on defining Git aliases, etc., ehich I specifically wanted to do, to learn Git better that way, but that surely isn't everyone's cup of tea :)
<qschulz>
dsimic: it lowers the barrier of entry drastically
<qschulz>
also, you can send mails without a mail server, which should help get rid of issues of people not being able to send patches via e.g. gmail or their corporate accounts
<dsimic>
also, I contributed to Git, and chances are high you're all running a bit of my code in Git whenever you run it, because I fixed some bug in the Git configuration parsing, and that code gets executed very early in each Git invocation :)
<qschulz>
because on m.2, the pins for Bluetooth and WiFi enabling aren't specified by the standard
<qschulz>
and I vaguely recall they could be different on some modules I checked
<dsimic>
qschulz: that web API that b4 can use to send patches is quite neat, because many people have troubles setting up SMTP to send patches
<dsimic>
I like that it exists as an additional option, but I won't use it :)
<dsimic>
it should help a lot people who simply don't want to get into all the steps required to set all up manually, so to speak
<naoki>
"because on m.2, the pins for Bluetooth and WiFi enabling aren't specified by the standard" I wonder why rock-5b.dts has rfkill node ;) but at least that's true for Radxa A8 module
<naoki>
s/true/right/
<dsimic>
also, s/m.2/M.2/, if we want to be pedantic :)
<dsimic>
I'm not really sure that the support for SDIO WiFi+BT chips on M.2 modules is backed by some formal standard at all
<dsimic>
AFAIK (and IIRC), it's just left as a slightly undefined option
<qschulz>
you have W_DISABLE1# and W_DISABLE2# but that';s basically it
<dsimic>
thus, I think that defining support for rfkill in board dts files is fine, because there's no formal standard to start with
<qschulz>
dsimic: well that's exactly the reason for NOT adding them
<qschulz>
because then you could need to rfkill bluetooth to be able to use the WiFi
<qschulz>
depending on which m.2 module you insert
<dsimic>
hmm, but in that case we shouldn't have support for SDIO modules at all, except in per-module DT overlays
<qschulz>
I honestly do not know what should be done exactly
<dsimic>
the safest option would be to have per-module DT overlays for supported and tested SDIO modules
<qschulz>
we've used GPIO hogs on Jaguar for example
<qschulz>
which means they cannot ever be disable, which is bad
<dsimic>
s/SDIO modules/M.2 SDIO modules/
<qschulz>
dsimic: yeah but that's not really reasonable
<qschulz>
dsimic: ah, or you just provide two DTBO
<qschulz>
one with W_DISABLE1 = rfkill BT+W_DISABLE2 = rfkill WiFi and the other one with those swapped
<dsimic>
yeah, but that's the only 100% safe option, if I'm right that M.2 SDIO modules aren't strictly backed by a formal standard
<dsimic>
if we could provide just two DT overlays, that would be even better
<qschulz>
naoki: you can remove subject-prefix and use -v 3 instead
<naoki>
what!?
<dsimic>
naoki: I'd suggest that you learn a bit about using branch descriptions as cover letters
<naoki>
oh! "-v"!
<qschulz>
naoki: ah also, b4 stores your cover letter as an empty commit directly in the branch (there's another option as well), so you don't have to keep your cover letter somewhere to update it between versions