From: Joel Fernandes <joelf@ti.com>
To: Joe Perches <joe@perches.com>
Cc: Tony Lindgren <tony@atomide.com>, Rajendra Nayak <rnayak@ti.com>,
Mark Greer <mgreer@animalcreek.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Herbert Xu <herbert@gondor.hengli.com.au>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>,
Linux OMAP List <linux-omap@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Lokesh Vutla <lokeshvutla@ti.com>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
Date: Wed, 14 Aug 2013 22:12:45 -0500 [thread overview]
Message-ID: <520C472D.8000904@ti.com> (raw)
In-Reply-To: <1376527636.1949.120.camel@joe-AO722>
On 08/14/2013 07:47 PM, Joe Perches wrote:
> On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
>> On 08/14/2013 06:29 PM, Joe Perches wrote:
>>> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
>>>> When DEBUG is enabled, these macros can be used to print variables
>>>> in integer and hex format, and clearly display which registers,
>>>> offsets and values are being read/written , including printing the
>>>> names of the offsets and their values.
>>> []
>>>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>>> []
>>>> @@ -15,6 +15,14 @@
>>>>
>>>> #define pr_fmt(fmt) "%s: " fmt, __func__
>>>>
>>>> +#ifdef DEBUG
>>>> +#define prn(num) printk(#num "=%d\n", num)
>>>> +#define prx(num) printk(#num "=%x\n", num)
>>>
>>> pr_debug?
>>
>> Sure, can change that.
>>
>>>> +#else
>>>> +#define prn(num) do { } while (0)
>>>> +#define prx(num) do { } while (0)
>>>> +#endif
>>> []
>>>> @@ -172,13 +180,35 @@ struct omap_aes_dev {
>>>> static LIST_HEAD(dev_list);
>>>> static DEFINE_SPINLOCK(list_lock);
>>>>
>>>> +#ifdef DEBUG
>>>> +#define omap_aes_read(dd, offset) \
>>>> + do { \
>>>> + omap_aes_read_1(dd, offset); \
>>>> + pr_debug("omap_aes_read(" #offset ")\n"); \
>>>> + } while (0)
>>>> +
>>>> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
>>>> +#else
>>>> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
>>>> +#endif
>>>> {
>>>> return __raw_readl(dd->io_base + offset);
>>>> }
>>>>
>>>> +#ifdef DEBUG
>>>> +#define omap_aes_write(dd, offset, value) \
>>>> + do { \
>>>> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
>>>> + offset, value); \
>>>> + omap_aes_write_1(dd, offset, value); \
>>>> + } while (0)
>>>> +
>>>> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
>>>> + u32 value)
>>>> +#else
>>>> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
>>>> u32 value)
>>>> +#endif
>>>> {
>>>> __raw_writel(value, dd->io_base + offset);
>>>> }
>>>
>>> Umm, yuck?
>>>
>>> Is there any real value in read_1 and write_1?
>>
>> Can you be more descriptive? There is a lot of value in them for debug
>> to show clearly sequence of read/writes. Moreover, they are no-op'd when
>> DEBUG is disabled.
>
> pr_debug is no-op'd when DEBUG is not #defined.
> so just use a single
>
> omap_aes_write(...)
> {
> pr_debug(...)
> __raw_writel(...);
> }
Actually this doesn't work, as the pr_debug cannot print the name of the
offset as my original patch set does using "#offset".
There are many places where named offsets are used to pass to
read/write, and this macro helps to visually see which offset is being
written to by name.
So the original patch would stand in its current form except for a small
rewrite of the write debug part of it as follows to be cleaner getting
rid of the _1. For the read , we still need it as we need to return the
value from a function which cannot be done in a macro.
So the new patch would look something like this:
#ifdef DEBUG
#define omap_aes_read(dd, offset) \
omap_aes_read_1(dd, offset); \
pr_debug("omap_aes_read(" #offset ")\n");
static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
#endif
{
return __raw_readl(dd->io_base + offset);
}
#ifdef DEBUG
#define omap_aes_write(dd, offset, value) \
do { \
pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
offset, value); \
__raw_writel(value, dd->io_base + offset); \
} while (0)
#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
{
__raw_writel(value, dd->io_base + offset);
}
#endif
Thanks,
-Joel
WARNING: multiple messages have this Message-ID (diff)
From: joelf@ti.com (Joel Fernandes)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
Date: Wed, 14 Aug 2013 22:12:45 -0500 [thread overview]
Message-ID: <520C472D.8000904@ti.com> (raw)
In-Reply-To: <1376527636.1949.120.camel@joe-AO722>
On 08/14/2013 07:47 PM, Joe Perches wrote:
> On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
>> On 08/14/2013 06:29 PM, Joe Perches wrote:
>>> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
>>>> When DEBUG is enabled, these macros can be used to print variables
>>>> in integer and hex format, and clearly display which registers,
>>>> offsets and values are being read/written , including printing the
>>>> names of the offsets and their values.
>>> []
>>>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>>> []
>>>> @@ -15,6 +15,14 @@
>>>>
>>>> #define pr_fmt(fmt) "%s: " fmt, __func__
>>>>
>>>> +#ifdef DEBUG
>>>> +#define prn(num) printk(#num "=%d\n", num)
>>>> +#define prx(num) printk(#num "=%x\n", num)
>>>
>>> pr_debug?
>>
>> Sure, can change that.
>>
>>>> +#else
>>>> +#define prn(num) do { } while (0)
>>>> +#define prx(num) do { } while (0)
>>>> +#endif
>>> []
>>>> @@ -172,13 +180,35 @@ struct omap_aes_dev {
>>>> static LIST_HEAD(dev_list);
>>>> static DEFINE_SPINLOCK(list_lock);
>>>>
>>>> +#ifdef DEBUG
>>>> +#define omap_aes_read(dd, offset) \
>>>> + do { \
>>>> + omap_aes_read_1(dd, offset); \
>>>> + pr_debug("omap_aes_read(" #offset ")\n"); \
>>>> + } while (0)
>>>> +
>>>> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
>>>> +#else
>>>> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
>>>> +#endif
>>>> {
>>>> return __raw_readl(dd->io_base + offset);
>>>> }
>>>>
>>>> +#ifdef DEBUG
>>>> +#define omap_aes_write(dd, offset, value) \
>>>> + do { \
>>>> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
>>>> + offset, value); \
>>>> + omap_aes_write_1(dd, offset, value); \
>>>> + } while (0)
>>>> +
>>>> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
>>>> + u32 value)
>>>> +#else
>>>> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
>>>> u32 value)
>>>> +#endif
>>>> {
>>>> __raw_writel(value, dd->io_base + offset);
>>>> }
>>>
>>> Umm, yuck?
>>>
>>> Is there any real value in read_1 and write_1?
>>
>> Can you be more descriptive? There is a lot of value in them for debug
>> to show clearly sequence of read/writes. Moreover, they are no-op'd when
>> DEBUG is disabled.
>
> pr_debug is no-op'd when DEBUG is not #defined.
> so just use a single
>
> omap_aes_write(...)
> {
> pr_debug(...)
> __raw_writel(...);
> }
Actually this doesn't work, as the pr_debug cannot print the name of the
offset as my original patch set does using "#offset".
There are many places where named offsets are used to pass to
read/write, and this macro helps to visually see which offset is being
written to by name.
So the original patch would stand in its current form except for a small
rewrite of the write debug part of it as follows to be cleaner getting
rid of the _1. For the read , we still need it as we need to return the
value from a function which cannot be done in a macro.
So the new patch would look something like this:
#ifdef DEBUG
#define omap_aes_read(dd, offset) \
omap_aes_read_1(dd, offset); \
pr_debug("omap_aes_read(" #offset ")\n");
static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
#endif
{
return __raw_readl(dd->io_base + offset);
}
#ifdef DEBUG
#define omap_aes_write(dd, offset, value) \
do { \
pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
offset, value); \
__raw_writel(value, dd->io_base + offset); \
} while (0)
#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
{
__raw_writel(value, dd->io_base + offset);
}
#endif
Thanks,
-Joel
WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joelf@ti.com>
To: Joe Perches <joe@perches.com>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>,
"David S. Miller" <davem@davemloft.net>,
Mark Greer <mgreer@animalcreek.com>,
Tony Lindgren <tony@atomide.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Rajendra Nayak <rnayak@ti.com>, Lokesh Vutla <lokeshvutla@ti.com>,
Linux OMAP List <linux-omap@vger.kernel.org>,
Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
Date: Wed, 14 Aug 2013 22:12:45 -0500 [thread overview]
Message-ID: <520C472D.8000904@ti.com> (raw)
In-Reply-To: <1376527636.1949.120.camel@joe-AO722>
On 08/14/2013 07:47 PM, Joe Perches wrote:
> On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
>> On 08/14/2013 06:29 PM, Joe Perches wrote:
>>> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
>>>> When DEBUG is enabled, these macros can be used to print variables
>>>> in integer and hex format, and clearly display which registers,
>>>> offsets and values are being read/written , including printing the
>>>> names of the offsets and their values.
>>> []
>>>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>>> []
>>>> @@ -15,6 +15,14 @@
>>>>
>>>> #define pr_fmt(fmt) "%s: " fmt, __func__
>>>>
>>>> +#ifdef DEBUG
>>>> +#define prn(num) printk(#num "=%d\n", num)
>>>> +#define prx(num) printk(#num "=%x\n", num)
>>>
>>> pr_debug?
>>
>> Sure, can change that.
>>
>>>> +#else
>>>> +#define prn(num) do { } while (0)
>>>> +#define prx(num) do { } while (0)
>>>> +#endif
>>> []
>>>> @@ -172,13 +180,35 @@ struct omap_aes_dev {
>>>> static LIST_HEAD(dev_list);
>>>> static DEFINE_SPINLOCK(list_lock);
>>>>
>>>> +#ifdef DEBUG
>>>> +#define omap_aes_read(dd, offset) \
>>>> + do { \
>>>> + omap_aes_read_1(dd, offset); \
>>>> + pr_debug("omap_aes_read(" #offset ")\n"); \
>>>> + } while (0)
>>>> +
>>>> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
>>>> +#else
>>>> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
>>>> +#endif
>>>> {
>>>> return __raw_readl(dd->io_base + offset);
>>>> }
>>>>
>>>> +#ifdef DEBUG
>>>> +#define omap_aes_write(dd, offset, value) \
>>>> + do { \
>>>> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
>>>> + offset, value); \
>>>> + omap_aes_write_1(dd, offset, value); \
>>>> + } while (0)
>>>> +
>>>> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
>>>> + u32 value)
>>>> +#else
>>>> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
>>>> u32 value)
>>>> +#endif
>>>> {
>>>> __raw_writel(value, dd->io_base + offset);
>>>> }
>>>
>>> Umm, yuck?
>>>
>>> Is there any real value in read_1 and write_1?
>>
>> Can you be more descriptive? There is a lot of value in them for debug
>> to show clearly sequence of read/writes. Moreover, they are no-op'd when
>> DEBUG is disabled.
>
> pr_debug is no-op'd when DEBUG is not #defined.
> so just use a single
>
> omap_aes_write(...)
> {
> pr_debug(...)
> __raw_writel(...);
> }
Actually this doesn't work, as the pr_debug cannot print the name of the
offset as my original patch set does using "#offset".
There are many places where named offsets are used to pass to
read/write, and this macro helps to visually see which offset is being
written to by name.
So the original patch would stand in its current form except for a small
rewrite of the write debug part of it as follows to be cleaner getting
rid of the _1. For the read , we still need it as we need to return the
value from a function which cannot be done in a macro.
So the new patch would look something like this:
#ifdef DEBUG
#define omap_aes_read(dd, offset) \
omap_aes_read_1(dd, offset); \
pr_debug("omap_aes_read(" #offset ")\n");
static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
#endif
{
return __raw_readl(dd->io_base + offset);
}
#ifdef DEBUG
#define omap_aes_write(dd, offset, value) \
do { \
pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
offset, value); \
__raw_writel(value, dd->io_base + offset); \
} while (0)
#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
{
__raw_writel(value, dd->io_base + offset);
}
#endif
Thanks,
-Joel
next prev parent reply other threads:[~2013-08-15 3:12 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-14 23:12 [PATCH 00/10] crypto: omap-aes: DMA and PIO mode improvements Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 01/10] crypto: scatterwalk: Add support for calculating number of SG elements Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 02/10] crypto: omap-aes: Add useful debug macros Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:29 ` Joe Perches
2013-08-14 23:29 ` Joe Perches
2013-08-14 23:40 ` Joel Fernandes
2013-08-14 23:40 ` Joel Fernandes
2013-08-15 0:47 ` Joe Perches
2013-08-15 0:47 ` Joe Perches
2013-08-15 3:12 ` Joel Fernandes [this message]
2013-08-15 3:12 ` Joel Fernandes
2013-08-15 3:12 ` Joel Fernandes
2013-08-15 6:23 ` Dmitry Kasatkin
2013-08-15 6:23 ` Dmitry Kasatkin
2013-08-15 7:27 ` Joel Fernandes
2013-08-15 7:27 ` Joel Fernandes
2013-08-15 7:27 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 03/10] crypto: omap-aes: Populate number of SG elements Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 04/10] crypto: omap-aes: Simplify DMA usage by using direct SGs Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 05/10] crypto: omap-aes: Sync SG before DMA operation Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 06/10] crypto: omap-aes: Remove previously used intermediate buffers Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 07/10] crypto: omap-aes: Add IRQ info and helper macros Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 08/10] crypto: omap-aes: PIO mode: Add IRQ handler and walk SGs Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 09/10] crypto: omap-aes: PIO mode: platform data for OMAP4 and trigger it Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:12 ` [PATCH 10/10] crypto: omap-aes: Switch to PIO mode in probe function Joel Fernandes
2013-08-14 23:12 ` Joel Fernandes
2013-08-14 23:30 ` [PATCH 00/10] crypto: omap-aes: DMA and PIO mode improvements Joel Fernandes
2013-08-14 23:30 ` Joel Fernandes
2013-08-15 5:58 ` Dmitry Kasatkin
2013-08-15 5:58 ` Dmitry Kasatkin
2013-08-15 7:02 ` Joel Fernandes
2013-08-15 7:02 ` Joel Fernandes
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=520C472D.8000904@ti.com \
--to=joelf@ti.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.hengli.com.au \
--cc=joe@perches.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=mgreer@animalcreek.com \
--cc=rnayak@ti.com \
--cc=santosh.shilimkar@ti.com \
--cc=tony@atomide.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.