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
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #armlinux
Pali has quit [Ping timeout: 240 seconds]
mrutland- has quit [Quit: oh no.]
mrutland has joined #armlinux
nathanchance has quit [Ping timeout: 268 seconds]
nathanchance has joined #armlinux
mvaittin has quit [Ping timeout: 268 seconds]
shoragan[m] has quit [Ping timeout: 268 seconds]
mvaittin has joined #armlinux
shoragan[m] has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
prabhakarlad has quit [Ping timeout: 256 seconds]
mripard has quit [Read error: Connection reset by peer]
mripard has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
<wens> IIRC, there was some talk about making the regmap clk stuff for qcom more generic and available to other platforms. Did that go anywhere?
amitk has joined #armlinux
<tmlind> mwalle: that one fixes the boot issue for me, but i agree with robher it's best to revert and try again as otherwise we have a buggy -rc1 which makes git bisect a pain for tracking down other issues
guillaume_g has joined #armlinux
monstr has joined #armlinux
iivanov has joined #armlinux
frieder has joined #armlinux
frieder has quit [Client Quit]
frieder has joined #armlinux
apritzel has joined #armlinux
<mwalle> robher: have a look before the patch is applied. if i read the code correctly, the negative value is passed to of_parse_phandle_with_args(), which returns -EINVAL and the for loop continues with the parent node
<mwalle> robher: ok, should I just resend the patches (with the clk patch) after the merge window?
apritzel has quit [Ping timeout: 240 seconds]
headless has joined #armlinux
djrscally has joined #armlinux
mcoquelin has joined #armlinux
<ardb> arnd: just sent a fix for alignment faults in copy_from/to_kernel_nofault()
<ardb> but i am seeing alignment fixups in the networking stack as well :-(
<arnd> ardb: As far as I understand, the network stack has some cases in which we should add get_unaligned()/put_unaligned(), and some drivers that need to correctly align the incoming buffers, but rmk also mentioned cases in which the headers are always unaligned
<arnd> do you have a backtrace for the alignment fixups?
<ardb> System:189642 (tcp_v4_rcv+0xb6/0x944)
<ardb> and
<ardb> System:2015 (ip6_datagram_recv_common_ctl+0x7e/0x8c)
<ardb> the first one hits in the checksumming code, as it dereferences daddr and saddr and loads both using a single ldrd
<ardb> making struct ip[v6]hdr __packed fixes both issues
headless has quit [Quit: Konversation terminated!]
<arnd> ardb: which network driver allocated these skbs? I assume they are for incoming packets, right?
<ardb> arnd: this is on a beaglebone white
<arnd> probably drivers/net/ethernet/ti/cpsw_new.c then
sszy has joined #armlinux
<ardb> arnd: so you're thinking that driver does not honour NET_IP_ALIGN?
<arnd> yes, exactly. There are many ways to get this wrong
<arnd> ardb: 9ed4050c0d75 ("net: ethernet: ti: cpsw: add XDP support") is a recent change to this code. I'm fairly sure the netdev_alloc_skb_ip_align() in the old version aligned it correctly, less sure about the new version
<arnd> #define CPSW_HEADROOM_NA (max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + NET_IP_ALIGN)
<arnd> #define CPSW_HEADROOM ALIGN(CPSW_HEADROOM_NA, sizeof(long))
<arnd> I only looked briefly, but it could be that CPSW_HEADROOM_NA is the version that is intentionally offset by 2 bytes to get the IP alignment, but then the driver rounds that up to a multiple of four, which breaks it again
<arnd> it might be easier to try changing CPSW_HEADROOM than to understand what the code actually does
<ardb> right
Pali has joined #armlinux
<mwalle> does anyone know the difference between -mfpu=fp-armv8 and -mfpu=vfpv4 ? Reading the gcc manual page suggests that vfpv4 is for armv7, but the arm page (eg. the cortex-a53 or cortex-a72 overview) mentions the core uses a VFPv4
<arnd> mwalle: IIRC vfpv4 was introduced in the middle of armv7, so A8 and A9 should be vfpv3, but A7 and A15 should be vfpv4
<arnd> not sure if it's an exact match with ARMv7VE, which introduced a few unrelated changes (virtualization, idiv, lpae, ...)
<mwalle> arnd: ok, but i'm more confused on the aarch64 side
<arnd> mwalle: I didn't think aarch64-gcc even took -mfpu= options at all, as opposed to the new -march=armv8+fp style
<arnd> mwalle: maybe you are looking at the aarch32 options for armv8?
alexels has joined #armlinux
<mwalle> arnd: mh, I'm not sure. can't find anything in the manual which suggests that -mfpu is for the aarch32, it just mentions that -mfpu is "auto" by default which then looks at the -mpcu/-march
<arnd> aarch64-linux-gnu-gcc-11 -march=armv8.2-a -xc /dev/null -o /dev/null -c -mpfu=auto
<arnd> aarch64-linux-gnu-gcc-11: error: unrecognized command-line option ‘-mpfu=auto’
<arnd> it doesn't seem to take any such options
<arnd> on arm-linux-gnueabi-gcc, the -mfpu= options are still accepted for backwards compatibility, but you are not supposed to pass them any more
<mwalle> arnd: no i have to look at how buildroot does it ;)
<mwalle> *now
<mwalle> arnd: btw there is a typo in your commandline (its mfpu) but that isn't indeed accepted neither
nsaenz has joined #armlinux
System_Error has quit [Ping timeout: 276 seconds]
prabhakarlad has joined #armlinux
<milkylainen> anyone knows if linux-firmware guys are on irc somewhere?
<mwalle> arnd: thanks btw. if you look closely enough there is a aarch64 section in the gcc man page which doesn't mention the mfpu
<ukleinek> milkylainen: not entirely sure if ben hutchings is a firmware guy, but he is on irc
djrscally has quit [Quit: Konversation terminated!]
djrscally has joined #armlinux
<milkylainen> ukleinek: tnx.
apritzel_ has joined #armlinux
apritzel has joined #armlinux
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
jlinton has joined #armlinux
luispm has quit [Ping timeout: 240 seconds]
luispm has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
Tokamak has joined #armlinux
amitk has quit [Ping timeout: 240 seconds]
<robher> mwalle: I added this unittest and it passes. The only change from before would be the error code. https://www.irccloud.com/pastebin/5BkxsOOC/
<mwalle> robher: mh? can't follow you. should index now be unsigned or signed?
amitk has joined #armlinux
<robher> mwalle: Is there something that cares that the return is ENOENT instead of EINVAL? The clock code mentions EINVAL, but I haven't found what cares.
<mwalle> robher: the clock cares, that it passes a negative number as index to of_parse_phandle_with_args() and expects -EINVAL in return, which obviously doesn't work if index is unsigned
<mwalle> as part of the error handling of of_property_match_string(np, "clock-names", name);
<robher> mwalle: but as unsigned, it will just be looking for a huge index beyond the property length and error out that way.
<mwalle> robher: ah yes, but that is even more awful, no?
<mwalle> robher: at least, the function doc of of_parse_clkspec() mentions EINVAL and ENOENT
<robher> mwalle: less efficient, but should still function.
tom5760 has quit [Remote host closed the connection]
<robher> mwalle: backing up, what pointed you to of_parse_clkspec? Just grepping around or a specific caller failing?
tom5760 has joined #armlinux
<mwalle> robher: tmlind debugged it and saw -22 and -61 passed as negative indices to of_parse_phandle_with_args()
<mwalle> robher: and together with its backtrace, i found the of_parse_clkspec thingy
<mwalle> robher: but now i get you. who is expecting EINVAL, but gets ENOENT at the moment (presumingly)
headless has joined #armlinux
<mwalle> robher: there is https://elixir.bootlin.com/linux/v5.16.1/source/drivers/clk/clk.c#L436 which checks for ENOENT and might actually be triggered with my patchset. Hard to tell without a failing system
<robher> mwalle: It's probably best if we just keep index signed.
<mwalle> robher: should i still make the of_parse_phandle variants static inline or should I just add the new variant to of/base.c ?
<robher> mwalle: I think the 'index < 0' check can be moved into __of_parse_phandle_with_args and then still make variants inline.
<mwalle> robher: ok, so basically thats how it looked liked i've posted the revert yesterday
Amit_T has joined #armlinux
prabhakarlad has joined #armlinux
monstr has quit [Remote host closed the connection]
guillaume_g has quit [Quit: Konversation terminated!]
ardb has quit [Ping timeout: 240 seconds]
ardb has joined #armlinux
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
frieder has quit [Remote host closed the connection]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alexels has quit [Quit: WeeChat 3.4]
gdd has quit [Ping timeout: 256 seconds]
apritzel_ has quit [Ping timeout: 268 seconds]
sudeepholla has quit [Quit: Ex-Chat]
sudeepholla has joined #armlinux
sudeepholla has quit [Ping timeout: 256 seconds]
sudeepholla has joined #armlinux
ardb has quit [Ping timeout: 256 seconds]
ardb has joined #armlinux
torez has joined #armlinux
Amit_T has quit [Quit: Leaving]
torez has quit [Remote host closed the connection]
apritzel has joined #armlinux
prabhakarlad has quit [Ping timeout: 256 seconds]
Tokamak has joined #armlinux
headless has quit [Quit: Konversation terminated!]
jlinton has quit [Quit: Client closed]
sakman has quit [Quit: Leaving]
amitk has quit [Ping timeout: 240 seconds]
sakman has joined #armlinux
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
System_Error has joined #armlinux
ardb has quit [Ping timeout: 268 seconds]
<ukleinek> broonie: just for your information: I intend to send a patch changing spi_driver::remove to return void after the end of the merge window
<ukleinek> there are currently some patches I cherry picked from next that I hope will disappear when I rebase to -rc1
ardb has joined #armlinux
mcoquelin has quit [Ping timeout: 268 seconds]
mcoquelin has joined #armlinux