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?
<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>
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>
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
<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)