On 3/4/20 1:16 PM, Johannes Berg wrote: > On Wed, 2020-03-04 at 12:49 +0100, Markus Theil wrote: >> Endianess conversion should not happen when writing out the string, >> instead convert proto endiannes when creating the trace point data, >> like its already done for control port rx. >> >> Without this patch, trace looks like: >> <...>-53819 [000] 12957.654875: rdev_tx_control_port: [FAILED TO PARSE] >> wiphy_name=phy0 name=wlan0 ifindex=3 dest=ARRAY[dc, 7b, 94, a5, bb, 3e] >> proto=36488 unencrypted=1 >> >> After applying this patch: >> wpa_supplicant-553 [001] 121.211264: rdev_tx_control_port: phy0, >> netdev:wlan0(3), dc:7b:94:a5:bb:3e, proto: 0x888e, unencrypted: true > This is from trace-cmd? That just means it doesn't know about the endian > conversion, but I don't really see any reason to change this - big > endian is a perfectly valid format for trace points? > > Maybe teach trace-cmd to understand it? We already did that for > __le16_to_cpu(). Maybe, but then this is also inconsistent in comparison to the same kind of conversion in control port rx. I think, both calls should have the same conversion (be that introducing the fn to trace-cmd or converting the input data for tx control port). > johannes >
