<rsalvaterra>
blocktrron_: What's this PHY_SIMPLE the AR7{1,2}00 USB drivers select, and why can't I find it anywhere else in the kernel, either ours (patched) or mainline…? I'm inclined to believe it should be GENERIC_PHY…
<Weissnix4711>
PaulFertser will have a look thanks
Weissnix4711 has quit []
<Tusker>
that was quick
<rsalvaterra>
blocktrron_: … and it definitely should. I'll take care of it.
<rsalvaterra>
blocktrron_: I just noticed this error by accident, while trying to slim down the USB configuration for my TL-WDR3600 as much as possible. :)
<johnf>
could someone please take a look at this PR: https://github.com/openwrt/openwrt/pull/4246 , I believe that adschm has followed through on his threat to stop reviewing it
<johnf>
I worked very hard to decode his terse and outright aggressive comments, but apparently not to his satisfaction
<johnf>
though the last of the issues is resolved and it should be very clean now
<PaulFertser>
johnf: as a general remark, I know him as a very reasonable and welcoming person, so I guess you had some unfortunate misunderstanding there.
Acinonyx_ has quit [Ping timeout: 480 seconds]
<johnf>
I believe he was frustrated by my lack of knowledge and failure to understand his comments and feedback
<johnf>
but really, my main interest is, if at all possible, to get this PR moving again
<johnf>
would you be able to review it PaulFertser?
<PaulFertser>
johnf: unfortunately, no, I'm just an OpenWrt user like you. For devices I contributed support for I was sending patches to the mailing list, I do not enjoy the github workflow.
<PaulFertser>
johnf: I can try to help understand some of the comments but you say you have already dealt with all of them. Looks like he was expressing frustration rather than aggression to me.
<johnf>
well, I believe I have addressed all of them
<Tusker>
johnf: probably be a good idea to update your PR comment with the latest commit information, so that they match
<Tusker>
interesting device though, I have some RS485 devices that I could try it on
<johnf>
Tusker: yes, it's a very interesting device at an excellent price point
<johnf>
can't guarantee the RS485 though, it needs that additional patch, you could add it
<Tusker>
US$31 shipping for me
<Tusker>
no thanks :)
<Tusker>
anyway, need to log off now, please go through each of the comments from Adrian and if there are any that you closed without addressing... maybe you should force push the change before you click on resolve
<Tusker>
and I don't think there are any aggressive comments, they are stating the fact of the matter plainly, and sometimes it's hard to hear when you make a mistake and you are called out on it
<Tusker>
if you look at my attempt at PRs, you'll see all manner of comments :)
<Tusker>
and that rs485 patch is dodgy... :)
<johnf>
so I've reviewed every comment (which is kind of hard in the github UI) and everything should be resolved
<johnf>
I just need someone to review and approve, or highlight any remaining issues
<johnf>
which is the state this PR has been in since Jul 7
<russell-->
fwiw it is semi-normal for support-adding patches to sit for months
<johnf>
ok, so I should not worry about this and it will eventually be looked at?
<johnf>
I'm building firmware for these devices and I was hoping to have this PR merged so I could build from an official snapshot release instead of my fork
<blocktrron_>
rmilecki: ah sorry, this is a different issue
<blocktrron_>
I'll have a look
<blocktrron_>
johnf: I'll have a look this evening when i'm back at home
<blocktrron_>
If you hear nothing till tomorrow, ping me please
<blocktrron_>
johnf: did a quick review
<johnf>
blocktrron_: thank you very much, I see that and will answer and address your questions
<johnf>
tmn505: the interface is quite difficult for a complex review, particularly if a question is closed and reopened
<johnf>
thanks very much for everyone's feedback and help, really appreciate it
<tmn505>
that is why I don't look at conversation in GitHub PRs except only when I'm pinged
<johnf>
the system works much better when I'm using github at work actually, but the process is more direct and synchronous, and usually accompanied by a call
<PaulFertser>
The system works much better when github is not used at all for anything :/
<PaulFertser>
Gerrit is ok-ish, and in recent versions you can review by e-mail too.
<johnf>
blocktrron_: for the DTSI there's another version of this device, I'm not going to create a PR for that one but it would consume the same DTSI, this was discussed in the comments or possibly on the second device that I'm working on; you think it would be best to make it a single file and, if someone later implements support, they could then split it back out?
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<stintel>
had a long (or short, depending on how you look at it) night, figured out the cause of the random crashes I had on the Firebox M300 ... turns out that mpc85xx has CONFIG_THREAD_SHIFT=13 and for ppc64 that should be 14
<stintel>
unfortunately I'm still nowhere with the bloody dts
<stintel>
neither OEM dts nor upstream DTS result in working network
Rentong has joined #openwrt-devel
Tapper has joined #openwrt-devel
<stintel>
also wtf dts. pre includes, post includes, overriding stuff, using labels in main dts that are only created later in other includes etc
<stintel>
what a horrible mess
<rsalvaterra>
stintel: Oh, my…! You were bitten by the kernel stacks being too small? :)
<stintel>
yeah
<stintel>
what an epic waste of time
<rsalvaterra>
stintel: It's never a waste of time if the cause is found, and you found it. ;)
<stintel>
problem is I suspected I was doing something wrong in the DTS
<stintel>
I don't want to know how many different variations of DTS I've tried
<stintel>
like few hundred probably
<rsalvaterra>
I also noticed you worked on the M200 too, right?
<stintel>
and the worst thing is that at some point I had a DTS that could at least probe some of the ethernet interface properly and init the phy
<stintel>
not getting in this state anymore :(
<stintel>
m200 is in the closet
<stintel>
it needs musl patching
<stintel>
because it has no altivec and musl hardcodes altivec instructions
<stintel>
and the psu is broken
<stintel>
if you want it I can ship it to you
<stintel>
but I'm more interested in getting the m300 to work
<rsalvaterra>
Yeah, the M300 seems like the perfect target.
<stintel>
I've started from the OEM dts, and from the upstream DTS of the board that this one is based on
<stintel>
neither work, and I fail at modifying them so they do
<hauke>
mangix: I would like to do a 19.07.8 at the weekend, do you have anything pending in the package feed?
<rsalvaterra_>
hauke: Ping
<hauke>
rsalvaterra_: pong
<rsalvaterra_>
hauke: Quick question, how do you refresh gcc patches (command)?
<rsalvaterra_>
I tried several possibilities, but all failed.
<hauke>
I copy them to the gcc package in the feed and do the refresh there ;-)
<hauke>
somehow the refresh in the toolchain dire is broken
<hauke>
*dir
<rsalvaterra_>
*facepalm*
<rsalvaterra_>
Well, I feel a bit less stupid now, thanks. :)
<stintel>
:P
<rsalvaterra_>
hauke: But only gcc is affected, it seems. I had no trouble refreshing binutils patches… Maybe it's because of those initial/final/minimal stages…?
<hauke>
rsalvaterra_: yes I think most otehr stuff works
<hauke>
are you preparing gcc 11.2?
<rsalvaterra_>
hauke: It's ready. I've been building images for mvebu/cortexa9 and ath79/generic since yesterday morning. :)
<rsalvaterra_>
I just haven't refreshed the patches, but they apply without issues.
<rsalvaterra>
Oh, don't get me wrong, I run cake everywhere. It has its limitations, though. Cell networks, for example, but I think *nothing* will ever fix the bufferbloat on those, since bandwidth fluctuates so much…
<rsalvaterra>
Sure, there's autorate-ingress, but it seems to be purely reactive (haven't looked at the source)… and when it reacts, it's already too late. :)