On Sun, Apr 12, 2015 at 02:07:33PM +0200, Guido Günther wrote: ... > +DECLARE_EVENT_CLASS(802154_le16_template, > + TP_PROTO(struct wpan_phy *wpan_phy, struct wpan_dev *wpan_dev, > + __le16 le16arg), > + TP_ARGS(wpan_phy, wpan_dev, le16arg), > + TP_STRUCT__entry( > + WPAN_PHY_ENTRY > + WPAN_DEV_ENTRY > + __field(__le16, le16arg) > + ), > + TP_fast_assign( > + WPAN_PHY_ASSIGN; > + WPAN_DEV_ASSIGN; > + __entry->le16arg = __le16_to_cpu(le16arg); When "__entry->le16arg" is type of "__le16" which is given by "__field(__le16, le16arg)". Then translation of __le16_to_cpu is here wrong because __le16_to_cpu return u16. > + ), > + TP_printk(WPAN_PHY_PR_FMT ", " WPAN_DEV_PR_FMT ", pan id: 0x%04x", > + WPAN_PHY_PR_ARG, WPAN_DEV_PR_ARG, __entry->le16arg) When then we need to do the translation here. The format string requires a host byte-order type. So it's __le16_to_cpu(__entry->le16arg), I don't know why sparse (the C=2) doesn't report about that. This is like wireless it does at [0], but with a pointer. When wireless do that in kernelspace, then I have no idea why there is a cfg80211 plugin which doing byte order translation at [1]. I think this not for parsing the argument, it's for correct handling of handling the display of __le16_to_cpup (We use __le16_to_cpu here). Then we need a cfg802154 plugin in trace_cmd for handling "__le16_to_cpu" correct. - Alex [0] http://lxr.free-electrons.com/source/net/wireless/trace.h?v=3.19#L2160 [1] http://git.kernel.org/cgit/linux/kernel/git/rostedt/trace-cmd.git/tree/plugin_cfg80211.c -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
