Am 02.12.2017 um 17:00 schrieb Greg KH:
On Sat, Dec 02, 2017 at 01:45:50PM +0200, Marcus Wolf wrote:
Since dev_dbg already depends on define DEBUG, there was no sense, to enclose
dev_dbg lines with #ifdef DEBUG.
Instead of removing #ifdef DEBUG, I introduced define DEBUG_FUNC_ENTRY. So now it is
possible to switch of the function entry debug lines even while debug is switched on.
Ick ick ick.
No, these lines should just all be deleted. Use ftrace if you want to
see what functions are being called, that's what it is there for. Don't
create driver-specific defines and functionality for when we already
have that functionality for the whole of the kernel. That's really
redundant and messy.
Signed-off-by: Marcus Wolf <linux@xxxxxxxxxxxxxxxxxxxxx>
---
drivers/staging/pi433/rf69.c | 118 +++++++++++++++++++++---------------------
1 file changed, 58 insertions(+), 60 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 12c9df9..0df084e 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -15,8 +15,10 @@
* GNU General Public License for more details.
*/
-/* enable prosa debug info */
+/* generic enable/disable dev_dbg */
#undef DEBUG
+/* enable print function entry */
+#undef DEBUG_FUNC_ENTRY
/* enable print of values on reg access */
#undef DEBUG_VALUES
/* enable print of values on fifo access */
@@ -40,7 +42,7 @@
int rf69_set_mode(struct spi_device *spi, enum mode mode)
{
- #ifdef DEBUG
+ #ifdef DEBUG_FUNC_ENTRY
dev_dbg(&spi->dev, "set: mode");
#endif
So this whole #ifdef dev_dbg #endif should all be removed.
thanks,
greg k-h
Hi all,
just for clarification, why I introduced these dev_dbg during
development of the driver and didn't use ftrace:
Since I wanted the driver to use a single module as sender and receiver
at (almost) the same time, the module constantly needs to be
reconfigured (constant switching between rx configuration and tx
configuration - see my documentation for details on the idea).
The routine, accessing the registers is able to print the register
number and the value, it reads / writes from / to the register. It's dam
hard to keep the survey over the use 30...40 register numbers, in 10th
of rows of register setting and reading, if you see just the numbers in
the log. Especially this is / was hard, if one register was written
several times, because it contains different settings. Then decoding of
the adress wasn't enough, I even need to decode the bits in the value.
Therefore I finally introduced this dev_dbg lines at the enty of the
setter (and getter): After that in the log I coud see something like this:
Set gain: 0x43 0x81
Set threshold: 0x51 0x30
Get moulation: 0x22 0x7c
instead of just numbers.
That eased the debugging a lot.
When using ftrace I would be able to see, in which order the setter were
called, but the link to the vlaues would be missing.
If those dev_dbg are unwanted, I am ok, if someone removes them.
Hope this helps understanding....
Marcus
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
