<arnd>
bamse: the 0day bot reported a build failure on the your DT branch: Error: arch/arm64/boot/dts/qcom/sm6125.dtsi:452.28-29 syntax error
<arnd>
can you send a patch to soc@kernel.org to fix this up?
<Marijn[m]>
arnd: The `qcom-arm64-for-5.17` branch, not `qcom-dts-for-5.17` branch I presume? It appears `SM6125` support hasn't landed in `qcom-rpmpd.h` there yet :(
<Marijn[m]>
(dtc messages are unnecessarily cryptic :( )
<arnd>
yes, that sounds about right
<Marijn[m]>
(I understand why, the preprocessor is supposed to substitute this from the header, `dtc` itself does not expect an identifier in this position hence it's a syntax error)
<arnd>
We should be able to just open-code the numbers for the moment, and bring back the syntactic sugar in 5.18
<Marijn[m]>
I'm not the kernel / upstream merge expert, but that sounds horrible :)
<Marijn[m]>
I don't know if this patch is supposed to make its way into 5.17 another way though
<arnd>
I see the patch is in the drivers branch
<arnd>
I try to keep the branches separate normally for a number of reasons, but what we do sometimes is to have the binding changes at the start of both the dt and driver branches so the commits end up in the tree only once
<arnd>
the qcom/driver branch however mixes the binding patches with the code changes, so I can't easily pull that in
<arnd>
I could cherry-pick 8712107740ad ("dt-bindings: qcom-rpmpd: Add sm6125 power domains") into the arm/dt branch, but that would duplicate the commit, and possibly lead to the numbers getting added twice depending on whether the branches merge cleanly otherwise
<arnd>
I'll point my finger at the firmware developers that screwed this up in the first place. If they could just assign stable numbers in the interface, we wouldn't have to invent macros to enumerate the power domains in the binding
<Marijn[m]>
Fair enough, it seems there are two dt-bindings patches stuck on the arm64 branch? I guess it makes sense to move those out, into the drivers branch and then merge drivers before arm64?
<Marijn[m]>
As for the numbers there are a lot of similarities between SoCs to the point where this might be a HW/FW revision thing - we don't know that revision so are stuck with SoC names?
<arnd>
Marijn[m]: the order does not matter, each branch needs to be validated on its own
<Marijn[m]>
arnd: That sounds like it's impossible to get a driver (or driver change), dt-bindings change, and DT change into the kernel in a single merge window?
<Marijn[m]>
Unless the patches are duplicated... Or even better: the arm64 branch is based on top of drivers so that the hashes remain the same and there's no possibility for patches to get applied twice?
<arnd>
Marijn[m]: as I said, the usual procedure is to commit the binding first and then base the other two branches on top of the binding commit
<arnd>
the dt branch should not contain code changes, but both the dt and driver branches can contain the bindings
<arnd>
Marijn[m]: I don't know what you mean with "are stuck with SoC names"
<arnd>
are you saying that the numbers are defined by the SoC after all?
<arnd>
(or firmware, in that case)
<arnd>
we only need to define the macros in include/dt-bindings/ for devices whose developers are too stupid to come up with a sane enumeration scheme
<arnd>
for most things (irq, gpio, sane clock drivers, ...), you don't need macros at all, because each instance has a number that is uniquely defined by the device already, and you just need to know the number
<Marijn[m]>
arnd: It seems many SoCs share the same numbers here, it could have been deduplicated at some point. After all these macros are only used to keep the indices between DT and arrays in the driver in sync
<Marijn[m]>
So in this case the number is not defined by the device, but rather by the driver
<arnd>
Marijn[m]: right, that would be find, but it seems too late for that now
nashpa has quit [Ping timeout: 480 seconds]
dliviu has joined #linux-msm
dliviu has quit []
dliviu has joined #linux-msm
<Marijn[m]>
arnd: Yes I wouldn't want to burn my hands much more on backwards-compatibility-breaking DT changes anymore - had my fair share of those already :|
<bamse>
arnd: sorry about that
<bamse>
arnd: i believe from your discussion with marijn that you figured out that the "fix" is in the qcom-drivers-for-5.17 tag already
<bamse>
arnd: are you merging te drivers tag first? or would you like me to update the dt tag?
<arnd>
bamse: not entirely: while the for-next branch is fine, the arm/dt branch is not self-contained
<bamse>
arnd: right, i got lazy and only tested for-next :/ will definitely fix that
<arnd>
bamse: ok, I'll take the qcom-arm64-for-5.17 out of the arm/dt branch for now then, at least it's still on top of the branch so I don't need to redo any other merges
<bamse>
arnd: ahh, i see, so you merge them into separate branches on your side and your dt branch is failing in it's current state?
<arnd>
right
<bamse>
arnd: okay, but then let's fix that up!
<bamse>
arnd: do you want a new tag, a patch on the list or just the information that SM6125_VDDCX is 0?
<bamse>
ahh there's more instances, i'll write up a patch at least
<arnd>
A new pull request would be good, I don't care about the tag name. How quickly can you do a respin? I'm trying to wrap up the pull requests for the branches I want to send out to torvalds before I'm flying out to the US.
<bamse>
give me a few minutes
<arnd>
ok, perfect
<arnd>
I haven't actually started writing the DT tag description yet, so that takes a few more hours I think
<bamse>
right, there's alwasy soo much goodies to write about :)
<arnd>
Only 650 commits so far this time, last time it was 900, so either it's actually quiet, or a number of folks are going to be missing the merge window
<arnd>
olofj can still pick up a few last-minute changes when I'm gone, but probably won't take the larger pull requests
<arnd>
and now patchwork.kernel.org went down
<arnd>
oh, it's planned downtime
<bamse>
arnd: i see i have a couple of defconfig updates as well that i didn't send you last week, are you okay to take those as well?
<arnd>
bamse: sure, I'm actually in the middle of merging defconfig patches, so that would be perfect timing
<arnd>
no need for a pull request on those, just send them as patches
<bamse>
just tagged the patches and pushed it out...about to send you the pull request
<bamse>
feel free to just pick the three patches if you prefer, but you have them there in the tag
lumag_ has quit [Quit: Leaving]
<arnd>
bamse: merged now, thanks a lot for the quick respin
<bamse>
arnd: thanks for merging!
<bamse>
arnd: this was a nice milestone, out of the 3 platforms announced at the qualcomm techsummit just weeks ago we have two booting (and more) in there
<arnd>
bamse: that's really nice, I should definitely mention that in my pull request to torvalds
<bamse>
to clarify that's the "Snapdragon 8 Gen 1" mobile platform and the "SDX65" 5G modem platform
<arnd>
yes, I saw those, but didn't realize the SDX65 was also only just announced
<arnd>
bamse: that's a 4nm Cortex-A7, right?
<bamse>
checking
<bamse>
yes, that seems to be correct
<arnd>
IIRC the SDX55 was 5nm, and this is the next generation, and it shows that we won't get rid of arm32 for a while
<bamse>
not sure how much of anomaly this is in the industry?
<arnd>
I used to say that 32-bit had an end-of-life date on it because there were no cores below 28nm, but there are several SoCs on newer processes now
<bamse>
but mani_s is making really good progress on taking the upstream SDX55 to a state where we have the feature set to run that in production...and the delta towards SDX65 is mostly incremental on the Linux side, so we intend to get there as well
<arnd>
I think they are all the type where you have a larger "thing" that does the work (inference engine, fpga or modem), with a tiny arm core on the side that runs Linux
<minecrell>
bamse: speaking of arm32, are you also going to send a pull for my single arm32 defconfig commit? :) I think there is some trivial conflict with some of the tegra changes, not sure who is going to handle that
<arnd>
there are obviously no 32-bit SoCs on modern processes where the CPU takes up any significant die space, as that would make the whole chip tiny and uneconomical
<bamse>
minecrell: did i miss that?
<minecrell>
I don't see it at least :)
<bamse>
arnd: are you past the arm32 defconfig merge?
<arnd>
yes
<arnd>
if minecrell's patch was on the list, I can pick that up from there and add your Ack if that helps
<bamse>
minecrell: sorry about that, thanks for being awake :)
<minecrell>
bamse, arnd: Great, thanks to both of you :)
Haxk20[m] has joined #linux-msm
Haxk20[m] is now known as MartinBotka[m]
Danct12 has quit [Remote host closed the connection]
cxl000 has quit [Quit: Leaving]
<calebccff>
bamse: could I pick your brains about a wifi issue? I'm trying to bring up wifi on a new sdm845 device and the firmware crashes, followed by some iommu related null pointer dereference in the kernel https://p.calebs.dev/atitametot.log
<calebccff>
The device has secure boot off, so I've tried using the firmware from the db845c and the oneplus 6 and they all have the same issue