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
heat has quit [Remote host closed the connection]
heat has joined #armlinux
Forty-Bot has quit [Ping timeout: 250 seconds]
apritzel has quit [Ping timeout: 246 seconds]
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
Forty-Bot has joined #armlinux
sally has quit [Remote host closed the connection]
sally has joined #armlinux
sally_ has joined #armlinux
sally_ has quit [Client Quit]
sally has quit [Ping timeout: 264 seconds]
Sally2 has joined #armlinux
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #armlinux
Sally1 has quit [Ping timeout: 246 seconds]
sally has joined #armlinux
heat_ has joined #armlinux
heat has quit [Read error: Connection reset by peer]
_whitelogger has joined #armlinux
ardb has joined #armlinux
heat_ has quit [Ping timeout: 264 seconds]
rvalue has quit [Ping timeout: 272 seconds]
rvalue has joined #armlinux
npcomp has quit [Ping timeout: 255 seconds]
npcomp has joined #armlinux
monstr has joined #armlinux
frieder has joined #armlinux
iivanov has joined #armlinux
rvalue has quit [Ping timeout: 250 seconds]
rvalue has joined #armlinux
Misotauros has quit [Ping timeout: 245 seconds]
sszy has joined #armlinux
prabhakarlad has joined #armlinux
Turingtoast has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
rockosov has quit [Ping timeout: 240 seconds]
rockosov has joined #armlinux
nsaenz has quit [Ping timeout: 260 seconds]
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 260 seconds]
Misotauros has joined #armlinux
nsaenz has joined #armlinux
apritzel has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
apritzel has quit [Ping timeout: 264 seconds]
prabhakarlad has quit [Quit: Client closed]
<shoragan>
khilman, do have hotel suggestions for embedded recipes? :)
<shoragan>
or anyone else going to kernel/embedded recipes in paris?
<mwalle>
anyone familiar with c standard? given a 'struct s { int a; int b; };', what happens if I do 'struct s s; ...; s = (struct s){ .a = 1 };', will the rhs object have an initialized b or not?
<arnd>
abelloni: do you have an opinion on rtc drivers with no in-tree users? I was working on a bugfix and noticed a couple that could perhaps be removed: https://www.irccloud.com/pastebin/0ISLRtW9/
<arnd>
BQ4802, PCF8583, and MAX6900 have one remaining user each but no DT support, so I added a stricter "depends on ARCH_* || COMPILE_TEST" dependency, but the others don't look like they are used at all
<heat_>
mwalle, there's a difference between struct S s; and struct S s = {};
<heat_>
the first example's struct remains uninitialized
<geertu>
arnd: Do they hurt?
<heat_>
whereas = {}; zero-inits everything
<geertu>
arnd: any chance bq4802 is similar to bq32002 on BeaglePlay?
<mwalle>
heat_: yeah, but if you take a look at the source op will be assigned later: op = (struct spi_mem_op){...};
<arnd>
geertu: possibly, but that is the one that has a nonstandard probing for sparc64 that came up a few weeks ago
<geertu>
arnd: OK
<mwalle>
heat_: so the "op = {}" initialization should be superfluous
<geertu>
pcf8583 is i2c, so I guess it can show up anywhere
<geertu>
e.g. to add an rtc to your fruit computer
<geertu>
same for the other i2c rtcs
<arnd>
geertu: the ones I listed are all either spi or i2c, so in theory they could all be used anywhere
<arnd>
for the pcf8583 that seems particularly unlikely since that is the one from the riscpc and is some 25+ years old. If anything else uses it, it won't get upstreamed any more
<geertu>
arnd: Digi-Key still has 1 (one) in stock ;-)
<abelloni>
thisis the one NXP didn't send me
<geertu>
abelloni: rotfl
<abelloni>
arnd: I wouldn't touch the spi/i2c ones
<abelloni>
I don't mind dropping BQ4802
<heat_>
mwalle, ok so my theory is that the compiler is getting confused wrt addr_mode? it sure as hell looks like it's the compiler's problem here
<arnd>
abelloni: ok, that is the one that I had in my backlog, I sent you my patch now
<heat_>
something funky is going on and the compiler is doing a bad job at telling us, I think
<heat_>
because the macros Look Good To Me(tm)
<ukleinek>
omitted members are even zeroed if an enum is involved that has no zero value.
<arnd>
abelloni: fwiw, the fm3130 was used until fb3642ebb52cf ("ARM: at91: remove at91sam9260/at91sam9g20 legacy boards files"), which noted that the DT support should fully replace the board file but there was never a replacement for that machine with the rtc enabled
<ukleinek>
= {} is an extension over c99 to initialize everything to zero
<geertu>
heat_: struct spi_mem_op contains a union and several bit fields. Probably that confuses the compiler.
<arnd>
The explicit constructors are also a GNU extension, which may contribute to the confusion. I think this ends up putting a second structure on the stack with an intializer, and then doing a struct assignment
<heat_>
{.a = 1, .b = 2} is C99
<mwalle>
arnd: but assigning a struct to another struct will copy all values over. so why is initializing the LHS fixing anything
<heat_>
fwiw i've been trying to repro it with gcc12 and gcc13 and I can't
<heat_>
i wonder if its an optimization level thing
<arnd>
heat_: which compiler shows the warning?
<mwalle>
heat_: a sample program or the actual linux kernel?
<heat_>
mwalle, make drivers/mtd/spi-nor/spansion.o
<arnd>
the -Wuninitialized warnings tend to depend on specific inlining decisions made by the compiler, so you need not just the same compiler but also the same kernel config
<heat_>
hmm
<arnd>
Looking at cypress_nor_set_addr_mode_nbytes(), I think what actually happens is that addr_mode is uninitialized when spi_nor_write_disable() fails, but gcc does not correctly track the state of 'ret'
<heat_>
yep
<arnd>
so it sees addr_mode getting copied into 'op' and then later used
<heat_>
but in that case I don't see why op = {}; would fix anything, as you'd still be copying the uninitialized addr_mode
<arnd>
adding the early initialization means that gcc marks the structure as initialized and then no longer warn about it even though it would still get overwritten with uninitialized data if cypress_nor_determine_addr_mode_by_sr1 fails
<mwalle>
so the actual patch is incorrect it seems
<ardb>
arnd: there are two occurrences, and the second one does not seem to match the pattern you describe
<arnd>
it's certainly suspicious without an actual explanation what is going on. Adding fake initializers for local variables to shut up warnings tends to make code worse either way
<abelloni>
arnd: so this means I still have boards with the fm3130 ;)
<heat_>
i got it to repro on gcc13 um-allyesconfig, but doing addr_mode = 0; doesn't do anything
<arnd>
torvalds disabled -Wmaybe-unitialized warnings in the kernel a while ago because gcc was so bad at it, but it does tend to get the -Wuninitialized ones right at least
<heat_>
smells like a compiler bug to me?
<arnd>
heat_, geertu: do you have the original .config that triggered the warning?
<heat_>
yeah it's the ARCH=um allyesconfig
<arnd>
heat_: it looks like I've never built an arch/um kernel from an arm64 machine. I'm trying to do
<arnd>
make ARCH=um SUBARCH=x86 CROSS_COMPILE=/home/arnd/cross/arm64/gcc-13.1.0-nolibc/x86_64-linux/bin/x86_64-linux- drivers/mtd/spi-nor/
<arnd>
but it fails with "arch/x86/um/user-offsets.c:2:10: fatal error: stdio.h: No such file or directory" since the cross-compilers don't have a glibc
<heat_>
tbf arch/um doesn't compile with Werror due to a missing prototypes warning anyway :)
<arnd>
I can work around that one with a s/foo/main/ on asm-offsers
<arnd>
I can build with debian's x86_64-linux-gnu-gcc, but I only have gcc-10/11/12, not 13
<arnd>
for my normal cross-compilers I have all versions
<arnd>
heat_: ok, so I tracked it down to gcc-12 -ftrivial-auto-var-init=pattern
<arnd>
gcc-11 does not have that option, and without this it does not warn
<arnd>
with the option I see it in both gcc-12 and gcc-13
amitk has joined #armlinux
<heat_>
ooooh that's interesting
<arnd>
heat_: what's even more interesting to me is that 'op' isn't even accessed anywhere in that function, it's just passed to spi_nor_read_any_reg by reference, but normally that does not trigger this warning at all because gcc has no idea if the extern function reads or writes the data
<arnd>
time to get out cvise
monstr has quit [Remote host closed the connection]
<ukleinek>
mwalle: if you tell me your preference regarding 20230719143956.6sv3feiroiwrcosb@pengutronix.de, I'll fix accordingly.
<mwalle>
ukleinek: do as you like :)
<arnd>
heat_, geertu: this is the reduced testcase, still doesn't make sense to me, but it looks the thing about the bitfields was a good guess: https://godbolt.org/z/PvMGzodc1
<geertu>
arnd: And the implicit gaps?
<heat_>
there has to be some tiny difference between zero and pattern here, as =zero does not trigger this
<arnd>
it seems to only happen when there are two bitfields that both don't add up to a full number of bytes
<ardb>
arnd: so why is the warning spurious in your godbolt reproducer?
<geertu>
arnd: because the compiler can't be sure spi_nor_read_any_reg() just doesn't fill it.
<geertu>
The warning says _is_ unintialized, not may.
<geertu>
ardb: ^
* geertu
was bitten by tab-completion, again
<ardb>
ah right
<heat_>
funny tidbit: if you add -mgeneral-regs-only the warning goes away :v
<ardb>
so the warning is not technically spurious, it's just a pattern that we cannot distinguish from the 'constructor' pattern where the function call *is* the assignment
<ardb>
(or initialization)
<heat_>
the warning is definitely spurious, it says "op" is used uninitialized in "struct spi_mem_op op;"
<ardb>
it is declared but not initialized, and then it is passed to spi_nor_read_any_reg()
<ardb>
so how is that spurious?
<ardb>
are we looking at the same thing?
<heat_>
how can the compiler have any basis to say op is used uninitialized?
<ardb>
i guess it depends on your definition of 'used'
<heat_>
seems like it's some -ftrivial-auto-var-init bug, the really weird thing is that if I add -mgeneral-regs-only the warnings also goes away
<heat_>
(does UM compile with SIMD enabled???)
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<arnd>
it also goes away if I change the 'long' to an 'int', or the -O2 to an -O1. I see that the initialization uses an SSE instruction ("movaps %xmm0, (%rsp)"), so it's probably triggered by some vector optimization
<arnd>
I see that the two bit fields together are 128 bits long because of alignment, so it's enough to use SSE for intializing them, but they don't contain a full byte, so no actual value gets set
<arnd>
I'll open a gcc bug, let's see what happens
<heat_>
(2) use of uninitialized value ‘*(long int *)((char *)&op + offsetof(struct spi_mem_op, addr.nbytes))’ here
<heat_>
-Wanalyzer spills the beans huh :p
sszy has quit [Ping timeout: 264 seconds]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
frieder has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 245 seconds]
Sally1 has quit [Read error: Connection reset by peer]
Sally2 has joined #armlinux
headless has joined #armlinux
Amit_T has joined #armlinux
<sally>
A suggestion needed; If I want to use ARM based as a daily PC, and I have two options: RPi4B with 8GB OR Orange Pi5 Plus, what do you think it's better, regarding the price, performance and software supported?
<bencoh>
I'd say orange pi5+, but that's just a personal take on it
<HdkR>
Going to be a spicy time with that Orange Pi5+ video driver though
<HdkR>
Which most people want for a daily driver
<bencoh>
hmm, I haven't tested the graphics intensively, but it seemed to be working to me ... what's wrong with it?
<bencoh>
(someone ran a desktop distrib on the pi5, and I toyed a bit with it)
<HdkR>
Panfrost support isn't upstream yet
<HdkR>
Also no Vulkan for the people that care about that, but unlikely to matter in this situation :)