<Lynx->
so we look up cpuinfo, we see cpu model : MIPS 1004Kc V2.15
<robimarko>
Lynx-: That doesnt matter
<Lynx->
how does that get us to 24kc?
<robimarko>
OpenWrt specifies mipsel 24kc in the makefile
<robimarko>
As its compatible to avoid building another set of packages
<Lynx->
ah
<mrkiko>
Lynx-: my fault, sorry
<Lynx->
Actually could someone here do me a favour and pull ModemManager from master into 22.03? The 22.03 version 1.18.6 does not support dispatcher scripts, meaning automatic reconnect is much harder
<Lynx->
by 22.03.4 perhaps OpenWrt can support automatic reconnection for LTE modems :D
<mrkiko>
well, the entire mobile broadband story is a little bit of a friction point. I can understand the community doesn't want to have big things like MM on a router. On the other hand, the complexity of managing mobile broadband devices is ... really high.
<mrkiko>
Lynx-: did you explore uqmi and autoconnect functionality ? Or did you jump straight to MM?
Lynx- has quit [Read error: Connection reset by peer]
Lynx- has joined #openwrt-devel
<Lynx->
robimarko are you sure it's 24kc ?
<Znevna>
yes
<Lynx->
* pkg_hash_fetch_best_installation_candidate: Packages for modemmanager found, but incompatible with the architectures configured
<Lynx->
I can install 1.20.2-1 but that fails with loads of errors: Error relocating /usr/sbin/ModemManager: qmi_message_uim_get_slot_status_output_get_slot_eid: symbol not found
<Znevna>
mipsel_24kc and not mips_24kc, yes?
<Lynx->
And now I can't go back to the version for 22.03
<Lynx->
ah, luckily I had modemmanager_1.18.12-1_mipsel_24kc.ipk saved in my 'Downloads' folder on my laptop
<Lynx->
(which works fine)
<Lynx->
anyway, thanks for your help mrkiko, robimarko and Znevna
Lynx- has quit [Read error: Connection reset by peer]
Lynx- has joined #openwrt-devel
borek has quit [Read error: Connection reset by peer]
borek has joined #openwrt-devel
<karlp>
so, make package/blah/{clean,compile} V=s has been my go to for a while now, but with python apckages, I get "no rule to make blah/clean" and same for compile.
<karlp>
now, I can see differences with package/python-blah/{clean,compile} and package/python3-blah/{clean,compile} and get it continue
<karlp>
but I don't get an ipk built in my bin dir for the package?
gch981213 has joined #openwrt-devel
<karlp>
ah, that's because I hadn't _enabled_ it in my menuconfig yet. I should have remembered that one.
neg2led has joined #openwrt-devel
srslypascal is now known as Guest1150
srslypascal has joined #openwrt-devel
neggles has quit [Ping timeout: 480 seconds]
neg2led is now known as neggles
Guest1150 has quit [Ping timeout: 480 seconds]
gch981213 has quit [Remote host closed the connection]
gch981213 has joined #openwrt-devel
Lynx- has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
borek1 has joined #openwrt-devel
f0g has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
borek1 is now known as borek
<f0g>
Hi all. I want to share a variable with 2 different process, but the lifetime of the variable is only during the device running. So I don't want to store it in the uci. What's the standard solution in openwrt?
<f0g>
ynezz: thanks. I just wonder is there any system like uci in openwrt but only store things in ram
<mrkiko>
f0g: you might frame your problem little bit better - we don't know, for example, whether the two processes are running at the same time, or one runs first, the other later and so on.
<ynezz>
you can point uci into /tmp
<f0g>
ynezz: yes I can, but if there any commit was called by other process after that, the value will be saved to a file, right?
<f0g>
mrkiko: hmmm... is there any different? in my issue, there is no race condition.
borek1 has joined #openwrt-devel
<f0g>
mrkiko: you can just think process A run first, then process B
<karlp>
if the device is not running, who cares if it's in uci?
<mrkiko>
f0g: of course, if the two processes are alive, you might consider an IPC solution or other message-passing strategies, even ubus itself might be used somehow. If this is not the case, then you might consider different tools.
<karlp>
but otherwise, you have a sea of traditional IPC methods....
<f0g>
mrkiko: ah, I got your point. yes, you are right.
<ynezz>
f0g: `uci -c <path> set the search path for config files (default: /etc/config)` so you can use `uci -c /tmp/myapp/config get ..`
<f0g>
ynezz: great, that's what I want.
<f0g>
Thanks all.
borek has quit [Ping timeout: 480 seconds]
borek1 is now known as borek
Misanthropos has quit [Ping timeout: 480 seconds]
<karlp>
lol, have a python package, want to work on a local fork of it for a bit, use git-src to override. classic.
<karlp>
but the python package it downloads from pypi has already patched in a setup.py, and the upstream git source doesn't have it anymore.
Ansuel has joined #openwrt-devel
<Ansuel>
hello
<robimarko>
Productive day so far Ansuel
<Ansuel>
did you find the ath11k crash ?
<robimarko>
Nope, got caught up in the flag setting
<robimarko>
Il get around to it sometime today
<Ansuel>
so the bricks are probably caused by a wrong flag settings?
<robimarko>
Probably
<robimarko>
Not all flags were being overwritten during upgrade, so bootloader may have done some of its crap
<robimarko>
Thats the best guess anyway
<robimarko>
As nobody has caught it in the act
<Ansuel>
so the bricks may have been just the router trying to boot from the second partition
<robimarko>
Probably
<robimarko>
I assume that the failed flag was set as that is not self clearing
<robimarko>
So in the end it had nothing to boot from
<robimarko>
BTW, can you merge the ath11k monitor mode fix PR
<robimarko>
Its just 2 upstream backports, otherwise it crashes the kernel nicely if monitor mode is tried
<Ansuel>
227 successful checks... ci testing are getting out of hands
<robimarko>
Yeah, building everything aint gonna work out
<robimarko>
Looks sane, but would be nice to runtime test on multiple targets
<Ansuel>
my concern is about downstream project
<Ansuel>
in our source the only user of that function is nand.sh and it's an intenral function
<Ansuel>
(and today i can't write english)
Piraty has quit [Remote host closed the connection]
<oliv3r[m]>
What are the options to include hardware-in-the-loop testing to the CI? E.g. i might get my hands on some Realtek hardware, that I do not intend to use, so I can hook it up to do hardware-in-the-loop testing triggered by the CI. Obviously, I wouldn't want that in 'master' run by anyone (only on certain tags/somethings) but even then, what's the best approach here? Maintaining a fork with some CI files is not ideal, but an option
<Ansuel>
the changes looks to be related to cert expire and checksum
<Ansuel>
robimarko i'm checking the various dts... is the dp and switch nodes actually different?
<Ansuel>
example by comparing ax9000 and qnap 301 the main difference for the switch node is just in the switch modes and port_phyinfo node
<Ansuel>
all the other node are the same
<Ansuel>
i assume the dp situation is comparable with just the id different for port order and phy handle
<Ansuel>
oliv3r ti support something like that self hosting ci is a MUST i think
<oliv3r[m]>
oh sure, as the CI will need to integrate with the actual hardware, toggle relays etc; but how to trigger it
<oliv3r[m]>
i can imagine 'if tag == reaktek; and target_branch = 'master' or something. though one big constrain on my part would be, it would need to be a gitlab CI runner :p as I'll only install that on my systems
<oliv3r[m]>
but I take it we don't do any hardware in the loop CI atm?
<Ansuel>
for packages we have run testing with qemu
danitool has quit [Remote host closed the connection]
<oliv3r[m]>
ok just checked, the runner is written in C# (obviously, as it comes from the Microsoft Azure pipelines) which are both reasons I won't be installing that, ever :D
<oliv3r[m]>
BUT, I do want to include hardware in the CI loop for the realtek target, so whenever something is marked as 'ready for merge' on, it can actually be run ...
<oliv3r[m]>
but it's not supported yet, and I'll have to think about that for a bit I suppose :)
<oliv3r[m]>
Habbie: nice find :) but that's just playing catch-up. e.g. they already write 'reverse engineerd' ugh
<Habbie>
yes
<Habbie>
also, i don't like the security model of the official runner (it's better in this one)
<Habbie>
i'd rather even stick an ssh key in a github secret and log into my "runner" explicitly
<oliv3r[m]>
i'm an old fart, i'm still not trusting MS to run anything of mine :p (interacting with github already feels dirty and sinful :p
<Znevna>
I'm sure they will use realtek code in windows12
<oliv3r[m]>
lol; i have no doubt ;)
<f00b4r0>
Ansuel: imho the base-file patch looks legit and should be merged in master. It's the only way it'll get significant exposure, and that's what master is for after all
<oliv3r[m]>
speaking of base-file; i have 2 or 3 of those open as well; which actually fix a few issues/spam
minimal has joined #openwrt-devel
<robimarko>
Ansuel: They are similar, but not the same
<robimarko>
The switch params usually differ per refence model plus PHY-s
<Ansuel>
the scheduler resource and config looks to be the same for everyone
<robimarko>
Time for diffing
<Ansuel>
alsi i bet each dp node is the same except for id and phy-handle and lan... my idea is to have something common and just use status + specific diff for the special devices
<Ansuel>
and label*
<robimarko>
Yeah, I get your idea, I tried to commonize it
<robimarko>
In the ESS DTSI
<robimarko>
I remember that switch scheduler being different per board
<robimarko>
That is why I left it in the board DTS
<Ansuel>
i compared 3 dts and they are all the same
<robimarko>
You are right
<ynezz>
oliv3r[m]: https://gitlab.com/ynezz/openwrt-device-runtime-testing it downloads every morning latest initramfs images for master/21.02/22.03 from downloads.openwrt.org and runs those on glinet-b1300 and turris-omnia
<robimarko>
I now diffed all of them and they are the same.
<robimarko>
Great, can just move that to ESS DTSI
<oliv3r[m]>
ynezz: that's super nice! though ideally, i'd run a test _before_ it actually gets merged :D
<Ansuel>
i would do the same for the dp nodes and flag them disabled by default
<Ansuel>
and set the id phy-handle and label in the single dts
<Ansuel>
the phy-mode looks to be the same for everyone
<Ansuel>
mactype to 1 for everything > of dp4
<ynezz>
oliv3r[m]: I plan to extend that with zyxel-gs1900, belkin-rt3200 and dynalink-wrx36 (just placed order) in upcoming weeks
<robimarko>
Ansuel: PHY mode is gonna be SGMII in 99% of cases
<robimarko>
Only SFP will be different
<oliv3r[m]>
ynezz: that's amazing; how is your hardware setup looking like? Do you have a relay or anything connected to power-cycle things? Plenty of cheap USB -> relay adapters. I'll def. look into 'connecting' too Though I only have rtl930x based hardware and hopefully rtl931x soon
<ynezz>
oliv3r[m]: it can be done, those CI pipelines could be trigerred externally, so you could just pass URL with initramfs from anywhere
<robimarko>
And mactype, that will maybe vary, but it can be overriden
<Ansuel>
actually no mactype to 0 for everyone and single dts will set the different value
<Ansuel>
but you get the point IMHO we should have a very generic and common config and just fix it for the single device
<robimarko>
Yeah, I get your idea
<robimarko>
That was my inital idea as well, and then got sidetracked
<oliv3r[m]>
ynezz: openwrt should have used gitlab (or at least gitlab pipelines) really :p github is too inverior :p
<Ansuel>
you can attach webhook
<Ansuel>
and trigger stuff
<Ansuel>
the test can just checkout the pr and test on it's own
<ynezz>
waste of time, simply just pass it initramfs image and wait for the results
<Ansuel>
true just putting ideas... also i remember there was an idea of creating testing image from ci
<robimarko>
Ansuel: I am also leaning towards getting rid of labels for MAC-s
<robimarko>
And just reading directly from NVMEM
<Ansuel>
so dropping the uboot way... it was handy but if things can be read in a more generic way
<f00b4r0>
ynezz: i could probably dedicate a few devices to this. Including a Mochabin
<robimarko>
Ansuel: Well, they all should have MAC-s at start of ART
<robimarko>
I can do it for the boards that I have at least
<f00b4r0>
not sure I feel like reading the entire labgrid doc tho, so it'd be nice if there were a "quick start" summup that's tailored to your typical setup ;)
<ynezz>
you're just looking for something you can use for UART and power control, there are several options available, so it depends on your preferencies, budget, local availability etc.
<rmilecki>
nbd: i profiled my bcm53xx BCM47094 with perf and got some nice graphs, would you be able to find a moment to look at them?
<Ansuel>
or with wifi enabled something in the codeflow of the NAT changes?
<rmilecki>
Ansuel: it's actually spending less time doing v7_dma_* sutff
<rmilecki>
which is probably wrong
<rmilecki>
as dma stuff is what processes network buffers
<rmilecki>
I believe we want those functions to take as much CPU time as possible
<rmilecki>
i don't see anything wifi related taking any CPU time according to that flame graph
<f00b4r0>
rmilecki: I don't know anything about this platform but I can't help but notice the significant increase in calls to __siphash_unaligned(). Quick look at that function (in lib/siphash.c) shows as the name suggests that it does unaligned accesses. On many platforms this carries a strong performance penalty
<Ansuel>
rmilecki my theory is that with wifi enabled extra stuff is allocated in skb and that cause unalligned access
<Ansuel>
just to make sure wifi is enabled but nothing is connected right?
<rmilecki>
hm, i have no idea, maybe...
<rmilecki>
right
<rmilecki>
no clients
<robimarko>
Ok, a bit off-topic, but do you have any docs on how would one go creating those graphs
<robimarko>
I know they are based off perf
<robimarko>
Cause, I am interested in seeing where ipq807x chokes
<Ansuel>
rmilecki what is the timeframe of the graph? wonder if by increasing or decreasing the sample time the problem is more present?
<Ansuel>
i can see it's for 60 second ?
<f00b4r0>
rmilecki: I wonder if this could be a scheduling issue (latency/context switches), that AIUI your current report wouldn't show?
<Ansuel>
well softirq is increased
<Ansuel>
so yes
<f00b4r0>
that's why I'm asking :)
Lynx- has joined #openwrt-devel
<f00b4r0>
the increase in arch_cpu_idle is also troubling
dangole has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
Lynx- has quit [Remote host closed the connection]
<Ansuel>
rmilecki what i REALLY can't understand is the increased read_32 like why that is happening when wifi is on ?
Misanthropos has quit [Ping timeout: 480 seconds]
<Ansuel>
also does on to off restore original perf?
Lynx- has joined #openwrt-devel
<nbd>
rmilecki: one difference i can find is that in the wifi-on case bgmac does more processing in softirq context, whereas in the wifi-off case it's more bounced to ksoftirqd
<nbd>
rmilecki: can you try enabling threaded napi on ethernet via sysfs and check how that compares
<robimarko>
How can I check if the label MAC is present?
<robimarko>
I dont know if you can use an alias to GMAC that uses NVMEM for it
<Ansuel>
what do you mean with label MAC?
<robimarko>
Its supposed to be the MAC that is printed on the device sticker/label
<robimarko>
There was a way to check if it got read
borek has quit [Remote host closed the connection]
borek has joined #openwrt-devel
<tmn505>
robimarko: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/lib/functions/system.sh#l18, naturally alias must be set in dt
* f00b4r0
is tempted to try the OnHub patchset on his asus OnHub
<f00b4r0>
(that's another device I could commit to continuous testing, along with a Google WiFi ;)
<Ansuel>
hw testing for ipq806x *.+
shibboleth has joined #openwrt-devel
nixuser has quit [Remote host closed the connection]
nixuser has joined #openwrt-devel
<f00b4r0>
Ansuel: what's not completely clear to me is that i've been told that switching google devices to dev mode kills the radio, and that you have to rollback a sufficiently old fw to get past that. But that's not what the installation note say so I'm curious
<mrkiko>
rmilecki: I did read your mail about NAT slowing down due to wi-fi issues, and I think it's very very interesting activities, one of those thankless tasks that help a lot making the software better. I know hwat I am asking you is really "problematic2 - but... would it be possible to do some kind of testing with different wi-fi drivers to understand if the problem might driver- or subsystem- related?
<Ansuel>
f00b4r0 can you ask that on the mailing list?
<f00b4r0>
I'll want to confirm with my "inside source" first. I'll ask then ;)
<f00b4r0>
my onhub is already in dev mode with "the right fw" so I can't check that locally
<Ansuel>
that thing is full of security measure so it could be
<Ansuel>
i also ready that enabling second cpu cause the system to hang
<mrkiko>
Ansuel: how much similar / different are those devices from the classic R7800?
<mrkiko>
Ansuel: and,furhtermore, any progress with 5.15 on R7800?
<Ansuel>
they are just different design i prefer r7800 instead of the cone thing
<Ansuel>
and nope got sidetracked by other task :(
<mrkiko>
Ansuel: "cone"?
floof58 is now known as Guest1174
floof58 has joined #openwrt-devel
<Ansuel>
cylinder
<mrkiko>
Ansuel: but in terms of "powerfulness" - do these devices have advantages over the R7800? Maybe even in radio terms
<mrkiko>
Ansuel: ah ok, didn't get we where talking about form-factor
<mrkiko>
Ansuel: In other terms, I am trying to understand if these devices are "better" than the R7800 or just more complicated :D
<Ansuel>
imho nope it's just ipq806x with the usual ath10k wifi card actually it's problematic since you need to do 20 more step to install openwrt and you lose feature it seems
<mrkiko>
Ansuel: loose features = CPU and radio
<mrkiko>
so IPQ806X isn't dead yeat
<mrkiko>
*yet*
<f00b4r0>
mrkiko: "these devices", the onhubs?
<mrkiko>
f00b4r0: yes
<f00b4r0>
they have zigbee radio (currently unsupported) and the antenna array is said to have been refined to provide superior performance.
<mrkiko>
f00b4r0: thanks
<Ansuel>
f00b4r0 marketing bs
<f00b4r0>
Ansuel: given *who* told me this, I don't think so.
Guest1174 has quit [Ping timeout: 480 seconds]
<f00b4r0>
I'm also probably not breaking any trade secret by saying there might be growing interest in having them working with openwrt because google has EOL'd the range and will soon pull the plug
<Ansuel>
you will always face limits of using concrete walls reg domain power limit and wifi congestion sooo it can be better but not that much
<mrkiko>
Ansuel: but how doew the firmware stop you from enabling the wi-fi, from a design perspective? How are wi-fi chips connected? I guess they're not connected over AHB/PCI
<Ansuel>
you have plenty of way to have fun with undocumented gpio and regs to disable wifi or reject any change
<mrkiko>
Ansuel: sure
<Ansuel>
f00b4r0 happy to collaborate... i'm really curious about the secondary cpu not working
<Ansuel>
i have some ideas tho
<Ansuel>
btw i think with v4 i will merge the devices
<mrkiko>
Ansuel: I'm curious as well
<Ansuel>
my bet is on them enabling secure world stuff and the upstream kernel totally not having support for booting the cpu in that state
<Ansuel>
so everything locks up as things are tried to be written in a bad way
<Ansuel>
i got this hint by the fact that they put a tpm device in that and they totally require these kind of thing for everything to work
<Ansuel>
but all of this was never used before so no support upstream
<Ansuel>
at best it's just implementing the missing piece in the hotplug cpu code
<Ansuel>
(the first cpu works just because uboot correctly init it and upstream kernel doesn't touch it)
<shibboleth>
mrkiko, iirc the r7800 is a 1.4ghz dual core ipq806x
<shibboleth>
the "new" ax/wifi63 devices tend to have even beefier SOCs
<shibboleth>
wifi6e even
<Ansuel>
the real improvement is not strictly more hz but better IPC
<Ansuel>
ipq806x is basted on ancient arm design... ipq807x is still old design but at least not that old and 64bit
<shibboleth>
Ansuel, still a huuuge improvement with re to the older mainstays, like archer c7 :)
<Ansuel>
based*
<shibboleth>
didn't i read something about ath11 and master? can't find any ath11 devices in toh?
<Ansuel>
ipq807x is almost ready for inclusion
<f00b4r0>
ok so killing radios is only on google wifi. Not on onhub. Forget what I said.
<f00b4r0>
Ansuel: btw, the second cpu is working in brian's last patchset
<Ansuel>
sad that they put that kind of limitation...
<Ansuel>
f00b4r0 strange? i read that it didn't work
<f00b4r0>
no in his last patch he says he fixed it
<shibboleth>
Ansuel, known devices? searching wikidevi for ath11 and ipq807x, no results
<Ansuel>
qnap 301w xiaomi ax3600 ax900
<Ansuel>
they are probably not there as they didn't have official support
<robimarko>
Before we found this, you had to have UART
<Ansuel>
if they hard code the bootcmd
<robimarko>
Yeah, only then
<Ansuel>
are we aware of ny ipq60xx device on the market?
Ryncewynd has quit [Quit: Leaving]
<robimarko>
There is a lot of IPQ60xx ones
<robimarko>
Decent number of IPQ50xx as well
<Ansuel>
really?
<robimarko>
Yeah
<Ansuel>
curious of the price
<robimarko>
Its not high
<Ansuel>
but you can't go lower than 70€
<robimarko>
Linksys MR7350 is dirt cheap
<robimarko>
I got mine for 45EUR from Amazon
<f00b4r0>
robimarko: I thought most of the ipq60xx devices were crippled with not enough ram
<robimarko>
f00b4r0: Not really, only the junk ones
<f00b4r0>
ah
<robimarko>
Usually they have 512MB RAM which is fine
<Ansuel>
here it's 83
<robimarko>
Check used prices
<rmilecki>
Ansuel: f00b4r0: sorry I had to go home
<Ansuel>
65
<robimarko>
Mine was "used" but its brand new
<rmilecki>
Ansuel: it was 120 seconds of recording
<Ansuel>
lowest price was 43
<rmilecki>
Ansuel: "perf record -a -g -- sleep 120"
<robimarko>
That is the one I got it for
<Ansuel>
rmilecki nbd gave you some hint of the cause
<rmilecki>
Ansuel: reading backlog and answering one by one :)
<Ansuel>
strange that linksys didn't have a ipq807x
<robimarko>
They probably have but is expensive
<robimarko>
Gotta go eat
<f00b4r0>
same :)
<Ansuel>
bye
<rmilecki>
Ansuel: f00b4r0: bgmac_poll() is NAPI callback and it uses bcma_host_soc_read32()
<rmilecki>
Ansuel: f00b4r0: if scheduling got affected, it's likely that bgmac_poll() gets called at different moments / intervals and that results in different amount of slow bcma_host_soc_read32() calls
<rmilecki>
Ansuel: f00b4r0: so irq handling & scheduling can affect performance I believe
<rmilecki>
nbd: i'll try threaded napi next thing, thank you!
<rmilecki>
mrkiko: testing / improving other platforms I have scheduled for years probably, it just some extra work I can't find time for and noone is going to pay for
<rmilecki>
mrkiko: i'd love to work on other targets though
<nbd>
threaded NAPI helped a lot with performance on MTK
shibboleth has quit [Quit: shibboleth]
hanetzer has quit [Quit: WeeChat 3.7.1]
<mrkiko>
robimarko: thanks!!
<rmilecki>
nbd: do I just have to do "echo 1 > /sys/class/net/eth0/threaded"?
<Ansuel>
driver should have support for it i think
<rmilecki>
FWIW i didn't get sysfs write error
<rmilecki>
mt76 adds "napi_threaded" sysfs file which seems do does the same as "threaded" - it just calls dev_set_threaded()
<rmilecki>
maybe I need sth magic in a driver though
<Ansuel>
robimarko how the dp rework is doing? curious if you notice more problems
<robimarko>
Ansuel: Its basically done
<robimarko>
Pushed the changes, now its time to get rid of the stupid hack with DP ordering on Dynalink
<robimarko>
But I need to tear it apart to get UART again and its my AP currently
<robimarko>
EAP102 is the only one with a similar thing
<robimarko>
So, check out the latest push
<Ansuel>
checking and i really like it
<Ansuel>
dts are much cleaner now
<robimarko>
Converted the AX9000 to NVMEM while doing it
<robimarko>
WIll do the same for AX3600/AX6
<robimarko>
Probably Dynalink as well
<jayk>
I can't subscribe to openwrt-devel: Internal Server Error
<jayk>
;\
<jayk>
does the old fasion way of emailing openwrt-devel-subscribe work?
<Ansuel>
robimarko i'm not sure but what it's important is the reg... id it's just a way to identify the thing from the driver but it should just be that... an id
<robimarko>
Ansuel: Yes
<Ansuel>
so changing it should not cause any problem... as we think it's just for port naming and order but we handle that with the label
<robimarko>
Previously it mattered as that is how the ports got numbering, but now its set by labels in DTS anyway
<robimarko>
So, the qcom,index shouldnt really matter
<Ansuel>
jayk is it the first time you have this? if it isn't then it's worth to report that on the mailing list
<robimarko>
He cant cause he cant subscribe
<jayk>
^
<Ansuel>
i will if it's not the first time, just asking as it could be a transient problem
<jayk>
today is the first time i tried to subscribe, using two different browsers got the same internal server error
<jayk>
didnt get an email either, so i dont think it worked