<dsimic>
but I'm not sure what does it have to do with IRC, it's an email client?
<dsimic>
oops... sorry, I wanted to ping diederik
<dsimic>
naoki: hmm, what's that commit about? it looks rather wrong, frankly
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
<naoki>
hmm...
<dsimic>
modifying those DT values is simply wrong, because they need to come from the upstream DTs
<dsimic>
the "compatible" values are also part of the ABI
<naoki>
upstream DT values are wrong...
System_Error has quit [Remote host closed the connection]
<dsimic>
ah, we'll get them corrected eventually, i.e. we'll split the DTs
System_Error has joined #linux-rockchip
<diederik>
dsimic: aerc is indeed an email client. I first mentioned "looks like aerc has some quirks (too ...)" and to correct the record, I then posted that that quirk had already been solved. That's all :)
<dsimic>
thanks for the clarification :)
<diederik>
It was actually amazing. 45 mins after I reported the issue, an updated Debian package was uploaded to the archives :)
<dsimic>
that was very fast :)
<diederik>
yep. Likely fastest turn around time I've ever seen :)
<dsimic>
it can hardly be any faster :)
<mps>
sometimes in alpine linux fixes are done in few minutes
<mps>
personally I did this for some pkgs
<dsimic>
that's even faster :)
<mps>
dsimic: test me :)
<dsimic>
there's no need, a few minutes is already extremely fast :)
<mps>
dsimic: sorry for private question, (you don't have to answer) from your name I could think that we are living close maybe
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ldevulder has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
warpme has joined #linux-rockchip
sre has joined #linux-rockchip
<hrw>
naoki: I wonder sometimes why vendors go with as cryptic names as possible + reuse them in quite random way. 'rock pi e/pi e v3.0', 'rock 5a/5b/5itx'
helene has quit [Remote host closed the connection]
naoki has quit [Quit: naoki]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dsimic>
hrw: hmm, I don't see those as cryptic... maybe the Pi E is cryptic a bit, though :)
<dsimic>
when it comes to 5A, 5B and 5 ITX, those denote the type of the board: "Model A", "Model B" and "Model ITX", so to speak
<diederik>
I'm with hrw on this one. Most of them have 'rock' and/or 'pi' in them and then often an almost random number. I pretty much always have to look up the board spec to even find out which SoC they have
<diederik>
The 'ITX' suffix *is* actually descriptive though
<dsimic>
maybe the naming scheme that FireFly uses is better? but again, what's "PC", and what's "PC Pro"?
hrw has quit [Remote host closed the connection]
hrw has joined #linux-rockchip
warpme has joined #linux-rockchip
franoosh has joined #linux-rockchip
franoosh has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
erg_ has joined #linux-rockchip
franoosh has quit [Read error: Connection reset by peer]
erg_ has quit [Read error: Connection reset by peer]
franoosh has joined #linux-rockchip
franoosh has quit [Ping timeout: 252 seconds]
System_Error has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
System_Error has joined #linux-rockchip
erg_ has joined #linux-rockchip
erg_ has quit [Read error: Connection reset by peer]
franoosh has quit [Ping timeout: 252 seconds]
hrw has quit [Quit: Lost terminal]
hrw has joined #linux-rockchip
franoosh has joined #linux-rockchip
franoosh has quit [Read error: Connection reset by peer]
ungeskriptet is now known as Guest3170
Guest3170 has quit [Killed (iridium.libera.chat (Nickname regained by services))]
Guest4205 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
ungeskriptet has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
Daanct12 has quit [Quit: WeeChat 4.4.1]
franoosh has joined #linux-rockchip
franoosh has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
franoosh has quit [Read error: Connection reset by peer]
franoosh has joined #linux-rockchip
Kwiboo has quit [Quit: .]
franoosh has quit [Read error: Connection reset by peer]
Kwiboo has joined #linux-rockchip
franoosh has joined #linux-rockchip
<macromorgan>
so if I'm going to rebase a patch series and add an RFC driver on top of it, should I 1) submit them seperately or 2) submit them all as an RFC, even though I did it as a patch previously?
<macromorgan>
I wrote a regulator/power MFD driver I want to submit as an RFC that this series depends on
franoosh has quit [Read error: Connection reset by peer]
erg_ has joined #linux-rockchip
<dsimic>
well, it's simple, the patch series should remain as-is, and the new RFC driver should be a separate patch for which it's noted that it depeneds on the series
<dsimic>
that makes reviewing simpler, and makes it easier to get the patch series reviewed, possibly improved further, and hopefully accepted first
<dsimic>
the RFC driver can keep chugging along until that happens
erg_ has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
franoosh has quit [Read error: Connection reset by peer]
erg_ has joined #linux-rockchip
<qschulz>
macromorgan: for this specific patch, I would say your driver is a requirement for the DT to make it upstream, therefore you cannot have the RFC driver depend on the series that depend on that RFC driver :)
<qschulz>
Considering that a driver is required, I assume that a dummy regulator will not make your device work, therefore it shouldn't be added
<qschulz>
macromorgan: what you could do is have a stripped down version of your GameForce Ace DT without what requires thi new regulator driver
<macromorgan>
yeah, I'll probably do that
<qschulz>
and then in a new series, all RFC, have the parts you stripped down in a separate commit + teh regulator driver
<macromorgan>
I'll just rip out the USB guts and resubmit, then do the new series with the RFC yeah
<dsimic>
ah, makes sense
<dsimic>
so the RFC pulls in all that's the cross dependency
<dsimic>
so to speak
<CounterPillow>
Do DT schemas even need a driver? DT should be independent of kernel.
<qschulz>
CounterPillow: they should but they aren't merged without a driver
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<CounterPillow>
Huh. Odd policy
<qschulz>
not sure it's a policy
<qschulz>
how do you know the binding makes sense without some amount of code?
Stat_headcrabed has joined #linux-rockchip
erg_ has quit [Remote host closed the connection]
erg_ has joined #linux-rockchip
robmur01 has quit [Remote host closed the connection]
hrw has quit [Quit: Lost terminal]
robmur01 has joined #linux-rockchip
warpme has joined #linux-rockchip
erg_ has quit [Remote host closed the connection]
erg__ has joined #linux-rockchip
erg__ has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
erg_ has joined #linux-rockchip
erg_ has quit [Read error: Connection reset by peer]
franoosh has quit [Ping timeout: 264 seconds]
erg_ has joined #linux-rockchip
erg_ has quit [Read error: Connection reset by peer]