ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
torez has quit [Quit: torez]
djrscally has quit [Ping timeout: 260 seconds]
ardb has quit [Ping timeout: 268 seconds]
Pali has quit [Ping timeout: 260 seconds]
Nact has quit [Ping timeout: 268 seconds]
leoy has joined #armlinux
bps has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Quit: Client closed]
System_Error has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
System_Error has quit [Remote host closed the connection]
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
XV8 has joined #armlinux
System_Error has joined #armlinux
System_Error is now known as StackOverflow
StackOverflow is now known as System_Error
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #armlinux
prabhakarlad has joined #armlinux
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 265 seconds]
djrscally has joined #armlinux
<arnd>
nsaenz: I don't understand 059e3d0cc983 ("ARM: dts: bcm283x: Drop fallback compatible for vchiq") in the fixes. Is the vchiq actually incompatible between the two?
<arnd>
I would expect that the schema enforces the old compatible string to be there rather than disallowing it
ardb has joined #armlinux
<arnd>
[florian] ^
<nsaenz>
Good morning arnd, bcm2836 uses a different cache line size than bcm2835 to communicate with RPis co-processor. It still kind of worked with the wrong cache line size under some setups, but other would eventually be corrupted.
monstr has joined #armlinux
<nsaenz>
So in order to avoid breaking users of the new DT that still had an old version of the driver we let the fallback live there for a while.
<nsaenz>
That was Sept 25 2018, so we figured it is safe to remove now.
<arnd>
nsaenz: but isn't the cache line size a feature of the CPU rather than the vchiq? I still don't understand.
guillaume_g has joined #armlinux
<nsaenz>
arnd, It's documented as this in the vchiq driver: "This value is the size of the L2 cache lines as understood by the VPU firmware, which determines the required alignment of the offsets/sizes in pagelists."
<arnd>
nsaenz: to clarify: I think it still sounds to me like they are sufficiently similar that it's better if the binding requires listing bcm2835 as a fallback, rather than describing them as two different things
<arnd>
is anything broken by leaving in the old string?
<arnd>
the driver should be able to just check for the presence of the new string to determine if this is what it needs as a permanent solution, no need to ever change this
<arnd>
i.e. it's not a question of "is it ok to be removed right now", but of "is it more sensible with or without the fallback"
Pali has joined #armlinux
<nsaenz>
arnd, I've been giving it some extra though and I can't find a reason why having the fallback would be harmful. It's just a matter of tidying things up.
<nsaenz>
I get your point, I'll be happy to drop that patch from the PR.
<nsaenz>
In the meantime I'll discuss it with Stefan Wahren who was active at the time to see if I've missed something.
<arnd>
ok, thanks for taking a closer look! I assume we need a new change to the binding as well then. Has [florian] already picked up the patch that changes the binding, or is it going through some other tree?
<nsaenz>
arnd, it seems my PR is in his tree, but he didn't sent a PR himself. So we can still correct it. Let me ping [florian] privately (he won't be here until after lunch due to timezones) and we'll see how to fix this.
Peng_Fan has joined #armlinux
shenki has quit [Ping timeout: 252 seconds]
shenki has joined #armlinux
sszy has joined #armlinux
jlinton has quit [Quit: Client closed]
<geertu>
broonie: Thanks for taking care of linux-next! But it seems you forgot to push out the next-20211213 tag?
neocow has joined #armlinux
<arnd>
geertu: looking through your driver changes, I see in 05b22caa7490 ("soc: renesas: Consolidate product register handling") that the initcall returns -ENODEV on unknown SoCs, doesn't that cause a needless warning with initcall_debug?
<arnd>
this is with and without your patch, and not too important as initcall_debug isn't that commonly used, but it still sounds worth fixing
<arnd>
(and I've merged the branch of course, as there is nothing wrong with the actual patches)
<geertu>
arnd: It indeed has been doing that since forever
<arnd>
geertu: we had a similar but worse bug in the freescale soc device driver, which was fixed the other day after years, otherwise I probably wouldn't even have looked
<geertu>
arnd: OK, I'll add it to my list and will have a deeper look
<geertu>
Thx foor pulling, btw
<arnd>
thanks a lot, there is obviously no rush here, and I'm sure a oneliner to change it to "return 0" is sufficient
<geertu>
arnd: Do you have a link to the freescale issue?
<arnd>
in this case, the driver didn't even return an error, it just registered the device no matter what
<arnd>
there are probably more bugs like this in soc drivers
<geertu>
Yeah, that's bad.
<geertu>
Hmm, all those m68k drivers also do "if (!MACH_IS_<foo>) return -ENODEV;". Are you sure -ENODEV is not the appropriate error code?
<arnd>
geertu: it probably made no difference before initcall_debug was introduced, no idea how old that is
<geertu>
;-)
<arnd>
geertu: it looks like we used to warn for anything other than -ENODEV before bf5d770bd234 ("init: Do not warn on non-zero initcall return")
<arnd>
now we don't warn at all, but do log the return code with initcall_debug
<geertu>
So -ENODEV still sounds right to me?
<arnd>
before c1cda48af8b3 ("[PATCH] initcall failure reporting") we just ignored the error code entirely
<geertu>
I.e. "This is not the driver you were looking for"
alexels has joined #armlinux
<arnd>
geertu: makes sense, just leave it then. I think I would prefer 0 when writing a new driver, both of these seem common enough that there is no point changing one to the other
<arnd>
maybe I should try doing initcall_debug on a distro kernel to see if that produces any return codes other than 0 or -ENODEV
<geertu>
arnd: My understanding is 0 means driver init OK, -ENDOEV means not applicable, and anything else is a real error.
<geertu>
perhaps try an allyesconfig kernel (incl. COMPILE_TEST), and see whether it actually gets to userspace (or not)? ;-)
<arnd>
geertu: roxell is testing allmodconfig kernels with a small set of patches to make that boot, he probably already has an initcall_debug log available online
<arnd>
roxell: on a related note: have you ever tried loading every single kernel module in that allmodconfig kernel to see how far you get before crashing?
shawnguo0 has joined #armlinux
ziofork5 has joined #armlinux
maz_ has joined #armlinux
rperier_ has joined #armlinux
j`ey_ has joined #armlinux
mripard_ has joined #armlinux
amitk has joined #armlinux
shawnguo0 has quit [Client Quit]
alexels_ has joined #armlinux
gdd1 has joined #armlinux
shawnguo9 has joined #armlinux
Tokamak_ has joined #armlinux
lag- has joined #armlinux
<arnd>
geertu: I looked up the documentation and didn't find anything specific about initcall return codes, but as the calling conventions are the same as module_init() your interpretation sounds more useful than mine, you win ;-)
<geertu>
arnd: thx, medal accepted ;-)
<arnd>
returning -ENODEV will make the module fail to load, which is the appropriate behavior
System_Error has quit [Ping timeout: 276 seconds]
alexels has quit [*.net *.split]
Tokamak has quit [*.net *.split]
leoy has quit [*.net *.split]
amitk_ has quit [*.net *.split]
gdd has quit [*.net *.split]
Emantor has quit [*.net *.split]
nexgen has quit [*.net *.split]
ziofork has quit [*.net *.split]
milkylainen has quit [*.net *.split]
elroo has quit [*.net *.split]
mripard has quit [*.net *.split]
sud has quit [*.net *.split]
rperier has quit [*.net *.split]
shawnguo has quit [*.net *.split]
lag has quit [*.net *.split]
j`ey has quit [*.net *.split]
maz has quit [*.net *.split]
ziofork5 is now known as ziofork
lag- is now known as lag
shawnguo9 is now known as shawnguo
elroo has joined #armlinux
leoy has joined #armlinux
sud has joined #armlinux
milkylainen has joined #armlinux
Emantor has joined #armlinux
<arnd>
monstr, marcan: when you copy-paste the 'git request-pull' output into an email, it helps to use a pipe to make the command avoid overly long lines. I use 'git request-pull ... | xclip' to immediately copy it, but '| cat' works as well. The default for the diffstat is to use the whole width of your terminal, using a pipe forces it use under 80 characters
<monstr>
arnd: there is no problem with c&p it is my thunderbird setup which handles that long lines.
<marcan>
arnd: I actually pipe straight to a mailer to myself, then edit and re-send; did I send you one with long lines somehow?
nexgen has joined #armlinux
<arnd>
monstr, marcan: both your pull requests had extra line wraps when I looked it them with pwclient
<marcan>
urgh, I'll look into that when I get home. sorry about that. I use thunderbird too, wonder if that is the problem...
<monstr>
yep - thurnderbird is breaking this. Just need to find different way how to do it.
<arnd>
marcan: it looks like in your case the line would have been exactly 80 characters
<marcan>
hm, I suspect that's tbird wrapping the 80char lines into 72 or something like that
<marcan>
yeah
<arnd>
if I run the same 'git request-pull' command, the line is 79 characters, no idea what the difference is
<marcan>
that's interesting
<marcan>
arnd: btw, I have follow-on pulls, let me know if you want them particularly asap or you'd prefer I wait a bit and maybe add more stuff
<marcan>
nothing for fixes I think, just 5.17 stuff
<arnd>
it's the same number of '+' characters, but your email appears to have an extra space in front of each line that starts with a space
<marcan>
this sounds like thunderbird doing something very silly
<marcan>
*or* the way you do it dropping leading spaces? :)
<marcan>
I'll investigate
<marcan>
request-pull | cat shows leading single spaces
<marcan>
hmm
<arnd>
marcan: earlier is better, I only have a couple more days before I'm gone for two weeks, last for me is Dec 23, but I'd prefer not to get any new pull requests on the last day
<roxell>
arnd: I've tried to turn off most of the boot selftests http://ix.io/2J8i and I change a few fragments for qemu so its easier to debug http://ix.io/2FR1 and then I've found a few issues that I haven't been able solved so I turned them off too in order to get it to boot http://ix.io/3IlG.
<roxell>
arnd: I haven't been able to load every single kernel module yet, thats on my list to do.
<monstr>
marcan: That's my thunderbird setup I did long time ago to avoid long lines.
<arnd>
roxell: do you have any initcall_debug output at hand for reference?
<monstr>
arnd: Do you want me to send new pull request with this fixed?
<arnd>
monstr: it doesn't really matter as the diffstat does not become part of the git history, no need to resend at all
<marcan>
arnd: ack, I'll send them to you today or tomorrow then, if that works for you; there *may* be a DT follow-up after that if I can get the t6k bringup stuff merged, which would be for device trees for that, but it's not a big deal if it doesn't make 5.17 since we can ship them either way
<arnd>
I only mentioned it because torvalds complains when I get it wrong myself ;-)
<monstr>
arnd: ok. I am sending it in this style even to Linus and he never complained
<monstr>
but I know it is happening
<arnd>
marcan: ok, sounds good. I still need to talk to ojn anyway, hopefully he can pick up anything that comes up when I'm gone and merge that into a 'late' branch, while I send out pull requests for everything I merged before Christmas
<marcan>
sounds good
<roxell>
arnd: did you mean '[ 0.000000][ T0] Kernel command line: root=/dev/root rootfstype=9p rootflags=trans=virtio,msize=131072 console=ttyAMA0,38400n8 earlycon=pl011,0x9000000 initcall_debug softlockup_panic=0 security=none kpti=no'
<arnd>
I think that 'initcall_debug' is sufficient, yes. There is also a compile-time option, which would already be enabled in allmodconfig
<monstr>
arnd, marcan: diff.statGraphWidth can help with long lines with stats
apritzel_ has joined #armlinux
<monstr>
but at least there is one more line which is longer
<geertu>
arnd: good to know you're gone after dec 23th. Linus telling people there will be an rc8 might encourage some people to postpone their soc PRs, too.
<geertu>
FTR, I plan to send a second one this Friday.
j`ey_ is now known as j`ey
Turingtoast has joined #armlinux
System_Error has joined #armlinux
Peng_Fan has quit [Quit: Connection closed for inactivity]
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
prabhakarlad has quit [Quit: Client closed]
XV8 has joined #armlinux
jlinton has joined #armlinux
djrscally has quit [Quit: Konversation terminated!]
leoy has quit [Ping timeout: 256 seconds]
djrscally has joined #armlinux
Tokamak has joined #armlinux
jlinton has quit [Ping timeout: 256 seconds]
Tokamak_ has quit [Ping timeout: 268 seconds]
alexels_ has quit [Quit: WeeChat 3.3]
prabhakarlad has joined #armlinux
rbutler1728 has joined #armlinux
milkylainen_ has quit [Ping timeout: 268 seconds]
jlinton has joined #armlinux
djrscally has quit [Quit: Konversation terminated!]
sikkiladho[m] has joined #armlinux
djrscally has joined #armlinux
jlinton has quit [Quit: Client closed]
monstr has quit [Remote host closed the connection]