All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Schmidt <stefan@osg.samsung.com>
To: Xue Liu <liuxuenetmail@gmail.com>
Cc: linux-wpan@vger.kernel.org
Subject: Re: [PATCHv2 3/3] ieee802154: Add MCR20A IEEE 802.15.4 device driver
Date: Tue, 20 Feb 2018 10:27:11 +0100	[thread overview]
Message-ID: <ac1d2dd1-b8f8-ffa6-abd4-7eb2b04dd0e1@osg.samsung.com> (raw)
In-Reply-To: <CAJuUDws623rbNS9pfnJERd7oQfvK8WY64rRxQ-aBDLzkqtFh=w@mail.gmail.com>

Hello.


On 02/20/2018 12:59 AM, Xue Liu wrote:
> Hello
>
> On 19 February 2018 at 23:37, Stefan Schmidt <stefan@osg.samsung.com> wrote:
>> Hello.
>>
>>
>> On 02/19/2018 10:40 PM, Xue Liu wrote:
>>> Hello Stefan,
>>>
>>> Thanks for the second review.
>>>
>>> On 19 February 2018 at 17:31, Stefan Schmidt <stefan@osg.samsung.com> wrote:
>>>> Hello.
>>>>
>>>> On Mon, 2018-02-19 at 11:51, Xue Liu wrote:
>>>>
>>>>> +
>>>>> +#ifdef DEBUG
>>>>> +     print_hex_dump(KERN_INFO, "mcr20a rx: ", DUMP_PREFIX_OFFSET, 16, 1,
>>>>> +                    lp->rx_buf, len, 0);
>>>>> +     pr_info("mcr20a rx: lqi: %02hhx\n", lp->rx_lqi[0]);
>>>>> +#endif
>>>> Here, as well as in the corresponding TX hex_dump call I wonder how to better
>>>> make use of it. Recompiling the driver to get the dump is not really nice.
>>>> Having a way to have this enabled during runtime might be better. And across
>>>> all drivers. Just thinking out loud here. Not saying you need to be he one
>>>> implementing it. What do you think?
>>>>
>>>>
>>> using module parameters may a solution.
>> This would be an option but I was thinking more about towards a tracepoints like approach where we can dynamically enable or disable the
>> hexdump or other debug functionality. Loading and unloading the module to change this is a bit cumbersome. This code might not even be a
>> module at all but compiled in.
>>
>> I need to check what the kernel infra offers here and how other subsystems use it.
>>
> Do you mean "dynamic debug"
> https://www.kernel.org/doc/html/v4.11/admin-guide/dynamic-debug-howto.html
> ?
> I saw there is all a version for print_hex_dump.

Indeed, that would be a good way of doing it. Switch to print_hex_dump_debug() and pr_debug and eliminate the ifdef.
That way it is always compiled in but off by default and can be dynamically enabled during runtime.

Are you ok with changing this or would you prefer to stay with your current construct?

regards
Stefan Schmidt

  reply	other threads:[~2018-02-20  9:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-19 10:51 [PATCHv2 0/3] ieee802154: Add support for NXP MCR20A Xue Liu
2018-02-19 10:51 ` [PATCHv2 1/3] ieee802154: Add device tree documentation for MCR20A Xue Liu
2018-02-19 10:51 ` [PATCHv2 2/3] ieee802154: Add entry in MAINTAINTERS for MCR20a driver Xue Liu
2018-02-19 10:51 ` [PATCHv2 3/3] ieee802154: Add MCR20A IEEE 802.15.4 device driver Xue Liu
2018-02-19 16:31   ` Stefan Schmidt
2018-02-19 21:40     ` Xue Liu
2018-02-19 22:37       ` Stefan Schmidt
2018-02-19 23:49         ` Xue Liu
2018-02-20  3:44           ` Alexander Aring
2018-02-20 10:42             ` Xue Liu
2018-02-19 23:59         ` Xue Liu
2018-02-20  9:27           ` Stefan Schmidt [this message]
2018-02-20 10:45             ` Xue Liu
2018-02-19 17:29   ` Michael Richardson
2018-02-19 21:42     ` Xue Liu
2018-02-20  3:37     ` Alexander Aring
2018-02-20 10:53       ` Xue Liu

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=ac1d2dd1-b8f8-ffa6-abd4-7eb2b04dd0e1@osg.samsung.com \
    --to=stefan@osg.samsung.com \
    --cc=linux-wpan@vger.kernel.org \
    --cc=liuxuenetmail@gmail.com \
    /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.