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
Pali has quit [Ping timeout: 260 seconds]
apritzel has quit [Ping timeout: 260 seconds]
sakman_ has joined #armlinux
sakman has quit [Ping timeout: 252 seconds]
sakman has joined #armlinux
sakman_ has quit [Ping timeout: 260 seconds]
amitk has joined #armlinux
cbeznea has joined #armlinux
<palmer>
vkoul: hey, so I'm fine doing whatever with those DMA patches -- I just hadn't seen anything and was doing a pass through old stuff to pick up what I thought had gotten lost
<vkoul>
palmer: sure I looked at patches, they look good to me, so should be in my -next after rc1
<palmer>
no worries on my end
<palmer>
I'll just drop the whole set? it's a bit easier for me if they stay together
<palmer>
I don't think there's any rush on these, they smell like they're for a future HW flavor anyway
<vkoul>
palmer: i think dts bits should go thru your tree :)
<palmer>
I guess it just seems kind of awkward to have the DT (and bindings) that say there's the # channels field, but have the driver ignore it for a release
<palmer>
I can wait until 5.19 for the DTs?
<palmer>
(and then post a tag?)
guillaume_g has joined #armlinux
<palmer>
vkoul: ^, and I don't really care that much either way -- I've dropped the merge for now, so no rush on my end
<vkoul>
palmer: DT is an ABI so it should not matter which versions these go in :) Driver takes care of missing channels property which is the right thing to do there
<palmer>
I guess
<palmer>
(oops)
<vkoul>
By convention driver and bindings go thru subsystem tree
<palmer>
vkoul: I guess my worry is that the DT will say there's a # channels field, but then the driver will ignore it
<vkoul>
the dts ones go thru respective arch tree
<palmer>
OK, I'll take them for 5.18
<vkoul>
palmer: that should work too.. part of ABI.. we should think of DT as firmware and not rely on kernel and dt to be in sync.. it is supposed to be work with older dt as well as updates
<palmer>
vkoul: OK, well, I'd still prefer to hold off on the DTs until 5.19 if that's when the driver is going to add the feature, if only to avoid publishing the ABI so long before the driver has support for it (IMO it'll be confusing for users)
<palmer>
if you want them in 5.18 just LMK, it's not that big of a deal on my end
sakman has quit [Remote host closed the connection]
sakman has joined #armlinux
apritzel has joined #armlinux
prabhakarlad has joined #armlinux
SallyAhaj_ has joined #armlinux
iivanov has joined #armlinux
SallyAhaj has quit [Ping timeout: 250 seconds]
apritzel has quit [Ping timeout: 246 seconds]
Misotauros has quit [Ping timeout: 256 seconds]
SallyAhaj_ is now known as SallyAhaj
luispm has joined #armlinux
mcoquelin has quit [Remote host closed the connection]
mcoquelin has joined #armlinux
mcoquelin has quit [Ping timeout: 252 seconds]
macromorgan has joined #armlinux
Xogium_ has joined #armlinux
macromorgan is now known as Guest5298
Guest5298 has quit [Killed (silver.libera.chat (Nickname regained by services))]
mcoquelin has joined #armlinux
Xogium has quit [Ping timeout: 245 seconds]
Xogium_ is now known as Xogium
nsaenz has joined #armlinux
sszy has joined #armlinux
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
Pali has joined #armlinux
cbeznea1 has joined #armlinux
cbeznea1 has quit [Client Quit]
cbeznea1 has joined #armlinux
cbeznea has quit [Quit: Leaving.]
matthias_bgg has joined #armlinux
mraynal has joined #armlinux
apritzel has joined #armlinux
monstr has joined #armlinux
mcoquelin has quit [Quit: Leaving]
mcoquelin has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 260 seconds]
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Read error: Connection reset by peer]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
prabhakarlad has quit [Ping timeout: 250 seconds]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
ziofork52 has joined #armlinux
ziofork52 has quit [Remote host closed the connection]
ziofork52 has joined #armlinux
amitk has joined #armlinux
prabhakarlad has joined #armlinux
<tmlind>
ardb: looks like n900 stopped booting with commit 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems")
<tmlind>
so this is with CONFIG_SMP and V6 as in omap2plus_defconfig
<ardb>
ouch
<ardb>
could you be more specific?
<tmlind>
ardb: not yet, just noticed :)
<tmlind>
ardb: let me try without v6 first?
<ardb>
tmlind: this code has been in -next for a long time. did you only notice it now?
<tmlind>
ardb: yup, don't boot n900 that often
<tmlind>
must have only booted with -rc series, not with next
<tmlind>
disabling v6 did not help, testing with smp disabled next
<tmlind>
disabling smp did not help
<tmlind>
seems this affects n900 only somehow
<tmlind>
ardb: with debug_ll and earlycon, the last message is: RX-51: Enabling ARM errata 430973 workaround
<ardb>
so this is called from .init_machine() ?
<ardb>
did you bisect it to 9c46929e7989?
<tmlind>
yeah and yes
<tmlind>
n900 uses smc calls for a bunch of stuff, i wonder if that's now somehow affected?
<ardb>
that shouldn't matter
elastic_dog has quit [Ping timeout: 256 seconds]
<tmlind>
commenting out setting the ibe bit it boots a bit further so the last message is: Registering SWP/SWPB emulation handler
<ardb>
wait what?
<ardb>
ah ok
elastic_dog has joined #armlinux
<ardb>
i thought you were talking about the spectre stuff
<ardb>
tmlind: so it gets stuck in the smc call somewhere, right?
<tmlind>
ardb: i guess yeah
<arnd>
ret = omap_smc3(idx, process, flag, __pa(param));
<arnd>
so it's using __pa() on a stack variable
<arnd>
which doesn't work with vmap-stack
<ardb>
nice find!
<tmlind>
ok, i thought we sorted out the vmap-stack stuff already last year..
<ardb>
tmlind: can you please double check that disabling vmap stack fixes the issue?
<tmlind>
ok let me check
<ardb>
tmlind: are those SMC calls supposed to be reentrant on SMP?
<ardb>
if not, we could just make that param[] buffer static
<ardb>
or per-cpu
<tmlind>
static should work just fine, nothing else happens during the smc calls afaik
<tmlind>
yeah commenting out select HAVE_ARCH_VMAP_STACK in arch/arm/Kconfig makes n900 boot again
<arnd>
powerpc has a simple vmalloc_to_phys() function, copying that make the code clearer to read
<ardb>
does that work when vmap stack is off?
<arnd>
no, nevermind then, it runs into a VIRTUAL_BUG_ON(!is_vmalloc_or_module_addr(vmalloc_addr)) in vmalloc_to_apge
<arnd>
page
<arnd>
I think aside from that it would work, as the page walk itself does not rely on it being vmalloc\
<tmlind>
i'll test tagging all the arrays static in omap-secure.c
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #armlinux
<ardb>
tmlind: so how on earth does this only break n900 and nothing else??
<arnd>
git grep -w __pa arch/arm/mach-*/ shows nothing other than mach-omap2
<arnd>
(for stack variables)
<ardb>
yeah but i did all my local testing on beaglebone white
<tmlind>
ardb: luck based computing? :)
torez has joined #armlinux
monstr has quit [Read error: No route to host]
<tmlind>
ardb: hmm actually using static u32 param[5] does not help, maybe i missed some
<arnd>
"if (omap_type() != OMAP2_DEVICE_TYPE_GP) { omap3_save_secure_ram_context(); }" should run into the a similar issue on omap3 and am35xx but not on am335x, which is the one on the beaglebone white
<tmlind>
hmm doing static u32 param[5] outside the functions works..
<tmlind>
arnd: but those are GP devices, no smc calls
<tmlind>
GP = general purpose
<arnd>
ah, I see
<ardb>
maybe the compiler notices that the values are always written before they are read?
<tmlind>
well a single static u32 param[5] will be racy for sure between the smc functions :)
<ardb>
perpcu variable maybe?
<arnd>
or kmalloc() if it's not called too early, or performance critical?
<ardb>
that is guaranteed to avoid any races onSMP
<tmlind>
well on n900 i guess the rng and other smc calls could be racy
<arnd>
possibly even dma_alloc_coherent(), and then do away with the cache flush
<tmlind>
that seems like an improvment yeah
<arnd>
tmlind: do you know why omap3_save_secure_ram() skips the cache flush, is that intentional?
<tmlind>
arnd: probably done already in the secure mode?
<tmlind>
arnd: not sure if dma_alloc_coherent is coherent also for the secure mode
<arnd>
tmlind: in general no, but I think on mach-omap2 it is because dma-coherent memory implies uncached
<tmlind>
i guess it depends on what the secure mode version specific code does
<tmlind>
it sets it's own mappings likely, then restores what linux has, no?
<arnd>
I think the question is whether the code accessing the data runs with caches enabled or not
<arnd>
if it runs with MMU off, then I think it also bypasses caching
<tmlind>
who knows.. seems like allocating an array of buffers on init is the safest route for a fix
<tmlind>
then changing separately to dma_alloc_coherent if it works later on :)
<arnd>
omap3_save_secure_ram() has an incorrect __iomem annotation on the pointer -- it's not __iomem but a regular kmalloc() type pointer. This is harmless, but it doesn't give me confidence that the rest of that function is correct
<tmlind>
ok so should be just void *
<arnd>
right, I think dma_alloc_coherent() is the correct change, but it does feel risky, so we may not want that as a hotfix in -rc1
<arnd>
yes
<arnd>
tmlind: I was thinking the alloc/free could be done on every call to one of the affected functions rather than once at init time
<tmlind>
the static allocation feels like a bit sucky solution though
<tmlind>
i mean init time allocation
<arnd>
it's slightly wasteful to do a kmalloc() or dma_alloc_coherent() on every call, but if they are called rarely then it doesn't matter
<tmlind>
allocating each time seems inefficient though, this stuff gets called all the time
<arnd>
ok, fair enough. I have no idea what the actual call chains are
<tmlind>
well for most part save and restore context from cpuidle, flush caches etc
<tmlind>
hmm maybe the smc flush caches part is no longer needed luckily
<arnd>
a cache flush at least shouldn't risk running into out-of-memory, that would be unexpected. For idle it may be a little better but still suboptimal if it fails
<tmlind>
have you guys checked the other __pa() callers?
<arnd>
for the rx51_secure_dispatcher at least, it should be sufficient to move the param[] access inside the irq-disabled portion, that will prevent preemtion even with preempt-rt, and there is no SMP either
<arnd>
tmlind: I have not checked all the omap_secure_dispatcher() callers yet, but I don't see anything else calling __pa() directly on a stack variable
<tmlind>
yeah
<tmlind>
ok great
nsaenz_ has joined #armlinux
nsaenz has quit [Read error: Connection reset by peer]
<arnd>
tmlind: for am43xx_suspend(), omap4_secondary_init(), and irq_save_secure_context() and irq_notifier(), it looks like we can't be in preemptable context either, so per-cpu will be sufficient
jlinton has joined #armlinux
<tmlind>
ok
<tmlind>
arnd: looks like am335x does smc too for suspend/resume, see omap_secure_dispatcher()
monstr has joined #armlinux
<arnd>
tmlind: I don't see it, all these callers look am43xx specific:
<tmlind>
oh right in pm33xx-core.c but am43xx specific
<tmlind>
khilman: that might explain some am43xx suspend/resume issues
<arnd>
so I suppose 'static DEFINE_PER_CPU()' should be enough for the omap_secure_dispatcher() arguments, and a normal 'static' for the rx51 version, or possibly the same variable for both because you don't call them on the same machine
<tmlind>
arnd: so is per_cpu valid if smp is disabled for am43xx?
<tmlind>
as local static did not work based on one try at least with my gcc
<arnd>
yes, it should be safe, without SMP there will only be the copy for cpu 0 in the kernel image, and the other copies of the percpu data never get allocated or referenced
<tmlind>
ok. let me give it a try
darkapex has quit [Ping timeout: 260 seconds]
luispm has quit [Quit: Leaving]
<tmlind>
arnd: so i changed to static DEFINE_PER_CPU(u32 [5], param) instead of u32 param[5] locally for each function, did you want to do something different for rx51?
<tmlind>
as just local static did not work
<arnd>
tmlind: that should be fine as well, I was thinking of file-scope DEFINE_PER_CPU() once, which would save a few bytes
<tmlind>
arnd: that brings in other changes because rng using the rx51 calls i think
<tmlind>
so maybe let's attempt that separately? :)
<tmlind>
i guess the race is unlikely though as on idle no rng calls should happen..
<tmlind>
while setting the params
<arnd>
sure, let me know when you have a patch so I can have another look regarding correctness. I would have thought moving the local_irq_disable() in the rx51 version is simple enough, but it's all a question of what you find most readable in the end
<arnd>
my earlier reasoning was purely based on rx51 being single-core and anything in the function being non-preemptible with the local_irq_disable()
<tmlind>
yeah..
<tmlind>
so you're thinking a shared static param[5] for omap3_save_secure_ram() and rx51_secure_dispatcher()?
<arnd>
I was thinking a single global per-cpu array shared between all three
<arnd>
but as I said, you are going to be the one that has to understand this code the next time, so do it whichever way helps you remember what is going on
<tmlind>
heh
luispm has joined #armlinux
<tmlind>
i retested local static param[5], it works fine. i must have forgotten to compile the kernel or something
<tmlind>
seems that's the most minimal fix for now, then other changes are possible later on :)
<tmlind>
i mean local static u32 param[5]
<arnd>
sounds good
headless has joined #armlinux
<tmlind>
any ideas why commit 9c46929e7989 started triggering this?
<tmlind>
so THREAD_INFO_IN_TASK was not set earlier blocking vmap stack?
<tmlind>
yeah so VMAP_STACK is now selected by default, patch sent for this one
<tmlind>
so then there's the assigned-clocks regression to look at still
<gpiccoli>
Curious about arm64 BUG() implementation - it seems it relies on brk 0x800 instruction, does it make sense? If so, what does happen when processor execute such instruction? I read some resources that say "self-hosted debug breakpoint" ... couldn't parse this in a simple CPU terminology. Does it hang forever, for example?
<tmlind>
fyi if others are seeing the clock regresssion, that's patch [PATCH v2 3/3] clk: Drop the rate range on clk_put
<gpiccoli>
nm, it seems it justs traps into a defined function, which call bug_handler() heh
<j`ey>
gpiccoli: it's a nice code compact way of having BUGs
<gpiccoli>
yeah, and it seems it gives flexibility to handle BUG() with more data preservation and potential recovery than the generic panic-based implementation
<mrutland>
gpiccoli: the BRK instruction generates an exception, when the exception is taken the immediate is placed in ESR_EL1
<mrutland>
... and as you've figured, from the exception vectors we eventually get to bug_handler()
<mrutland>
x86 does similar with a UD2 opcode IIRC, they just don't have an immediate
<gpiccoli>
thanks mrutland ! It makes sense now, very interesting approach
headless has quit [Quit: Konversation terminated!]
jn has quit [Ping timeout: 260 seconds]
matthias_bgg has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #armlinux
balrog has quit [Quit: Bye]
elastic_dog has quit [Ping timeout: 240 seconds]
guillaume_g has quit [Quit: Konversation terminated!]