[PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
Larry Finger
Larry.Finger at lwfinger.net
Mon Dec 5 22:34:08 UTC 2016
On 12/05/2016 03:34 PM, Dan Carpenter wrote:
> On Thu, Dec 01, 2016 at 07:48:29PM -0600, Larry Finger wrote:
>> --- wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
>> +++ wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
>> @@ -27,6 +27,29 @@
>>
>> #include "../wifi.h"
>>
>> +#ifdef CONFIG_RTLWIFI_DEBUG
>> +
>> +#define BTC_SPRINTF(ptr, ...) snprintf(ptr, ##__VA_ARGS__)
>> +#define BTC_TRACE(fmt) \
>> +do { \
>> + struct rtl_priv *rtlpriv = gl_bt_coexist.adapter; \
>> + if (!rtlpriv) \
>> + break; \
>> + RT_TRACE_STRING(rtlpriv, COMP_COEX, DBG_LOUD, fmt); \
>> +} while (0)
>> +
>
> This sort of macro is exactly when the rtl drivers spent so long in
> staging... Subsystems should not invent their own tracing but in
> particular these macros are so very very ugly.
>
> It's just super frustrating to even look at this...
>
> There are a lot of staging drivers I feel good about when they leave.
> The HyperV drivers. The IIO stuff. A lot of the media stuff and
> generally the media tree is getting better and better. I like comedi
> and unisys, those are in staging, but they are great and could move out
> any time as far as I'm concerned.
>
> But this patch just makes me super discouraged. What are we doing???
Dan,
It would not matter to me if these drivers got moved to staging, but there are a
lot of users whose distros do not build staging drivers that would be very unhappy.
Can you point me to a driver with a better way to conditionally dump a debugging
string to the logs?
Larry
More information about the devel
mailing list