David Miller <da...@davemloft.net> writes:
From: Shay Agroskin <shay...@amazon.com>
Date: Sun, 13 Sep 2020 11:16:34 +0300
ENA logs are adjusted to display the full ENA representation to
distinct each ENA device in case of multiple interfaces.
Using dev_err/warn/info function family for logging provides
uniform
printing with clear distinction of the driver and device.
This patch changes all printing in ena_com files to use dev_*
logging
messages. It also adds some log messages to make driver
debugging
easier.
Signed-off-by: Amit Bernstein <amitb...@amazon.com>
Signed-off-by: Shay Agroskin <shay...@amazon.com>
This device prefix is so much less useful than printing the
actual
networking adapter that the ena_com operations are for.
So if you are going to do this, go all the way and pass the
ena_adapter
or the netdev down into these ena_com routines so that you can
use
the netdev_*() message helpers.
Thank you.
Hi David, I researched the possibility to use netdev_* functions
in this patch. Currently our driver initializes the net_device
only after calling some functions in ena_com files.
Although netdev_* log family functions can be used before
allocating a net_device struct, the print it produces in such a
case is less informative than the dev_* log print (which at least
specifies what pcie device made the print).
I would rather change the allocation order for the net_device
struct in our driver, so that when calling ena_com device it would
always be allocated (and this way all ena_com prints could be
transformed into netdev/netif_* log family).
This change seems doable, but requires us to do some internal
testing before sending it. I could remove this whole patch, but
then our driver would be left with pr_err() functions in it which
is even less informative than dev_err().
Can we go through with this patch, and send a future patch which
changes all dev_* functions into netif/netdev_* along with the
change in the allocation order of the net_device struct ? I know
it sounds like a procrastination attempt, but I would really
prefer not to drop the patch and leave the driver with pr_* log
prints.
Thanks,
Shay
