All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Sujith Manoharan <sujith@msujith.org>
Cc: John Linville <linville@tuxdriver.com>,
	<linux-wireless@vger.kernel.org>, <ath9k-devel@qca.qualcomm.com>
Subject: Re: [PATCH v2] ath: Add support for tracing
Date: Tue, 30 Sep 2014 08:20:41 +0300	[thread overview]
Message-ID: <87k34ly992.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <21545.4248.512297.913983@gargle.gargle.HOWL> (Sujith Manoharan's message of "Mon, 29 Sep 2014 13:26:08 +0530")

Sujith Manoharan <sujith@msujith.org> writes:

> Kalle Valo wrote:
>> You mean ath_printk() & friends? But that doesn't require tracing code
>> to be in ath.ko as well, right? If I understood correctly, trace.c could
>> be under ath9k directory and the kconfig option could be
>> ATH9K_TRACEPOINTS.
>> 
>> I think it's just misleading and confusing for the user to call it
>> "Atheros wireless tracing" when it only affects ath9k. It's easier to
>> understand if each driver has it's own "tracing" kconfig option.
>
> We have CONFIG_ATH_DEBUG, which is used by ath9k and ath9k_htc.
> I think it is okay to have CONFIG_ATH_TRACEPOINTS, which can be
> used by ath9k/ath9k_htc too.

In my opinion that just creates even a bigger mess.

> The original motive of ath.ko was to have a common module with
> debugging facilities that can be shared by Atheros drivers. But,
> each driver has ended up reinventing things.

The current debug printing code in ath10k is something like 100 lines, I
don't see the point of trying to make that common with all ath* drivers.

In my opinion ath.ko should only have code which used at least two
different drivers (and I consider ath9k.ko and ath9k_htc.ko as one
driver). So the right thing here would be to actually move all debugging
code from ath.ko to ath9k, as it's the only user anyway.

> Since it is mentioned in the help text that ath9k is the only driver
> making use of ATH_DEBUG/ATH_TRACEPOINTS, I don't think it is
> confusing.

To me it is. But it's a mess already so I guess I'm worrying nothing.

-- 
Kalle Valo

  reply	other threads:[~2014-09-30  5:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-27  7:57 [PATCH v2] ath: Add support for tracing Sujith Manoharan
2014-09-29  6:25 ` Kalle Valo
2014-09-29  6:29   ` Sujith Manoharan
2014-09-29  6:53     ` Kalle Valo
2014-09-29  7:56       ` Sujith Manoharan
2014-09-30  5:20         ` Kalle Valo [this message]
2014-09-30  6:02           ` Sujith Manoharan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k34ly992.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=ath9k-devel@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=sujith@msujith.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.