Re: [PATCH 3/3] staging: octeon: ethernet: add pr_fmt macro

[Greg KH]

On Wed, Mar 25, 2026 at 02:33:00PM +0530, Ayush Mukkanwar wrote:
> On Tue, Mar 24, 2026 at 7:58 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Mar 24, 2026 at 07:00:29PM +0530, AyushMukkanwar wrote:
> > > Add pr_fmt macro to prefix log messages with the module
> > > name for easier debugging.
> > >
> > > Signed-off-by: AyushMukkanwar <ayushmukkanwar@xxxxxxxxx>
> > > ---
> > >  drivers/staging/octeon/ethernet.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c
> > > index eadb74fc14c8..5bb8c303f88b 100644
> > > --- a/drivers/staging/octeon/ethernet.c
> > > +++ b/drivers/staging/octeon/ethernet.c
> > > @@ -5,6 +5,7 @@
> > >   * Copyright (c) 2003-2007 Cavium Networks
> > >   */
> > >
> > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > >  #include <linux/platform_device.h>
> > >  #include <linux/kernel.h>
> > >  #include <linux/module.h>
> > > --
> > > 2.53.0
> > >
> >
> > How about working to remove the existing pr_*() calls with the proper
> > dev_*() and netdev_*() calls instead, so that pr_fmt() is not needed at
> > all?  That is the more "correct" solution here.
> >
> > thanks,
> >
> > greg k-h
> 
> Hi Greg,
> 
> After investigating, the pr_*() calls in ethernet-mem.c and
> ethernet-spi.c are inside functions that only receive hardware pool
> indices or register structs with no net_device or device pointer
> available, so dev_*() and netdev_*() replacements are not possible
> there.
> 
> For ethernet.c, device pointers are available at most call sites and I
> can replace those with dev_err() and netdev_err()/netdev_info()
> appropriately. The two calls where no device pointer is available
> would keep pr_err() as is.

That's a good start, but for the others, work back up the call chain to
properly pass in a device pointer so that these warning/error messages
can get printed out properly.  Drivers should not have any "generic"
messages like that, as it does not show what device actually created the
message.

thanks,

greg k-h