From: Greg KH <gregkh@linuxfoundation.org>
To: Ayush Mukkanwar <ayushmukkanwar@gmail.com>
Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] staging: octeon: ethernet: add pr_fmt macro
Date: Mon, 30 Mar 2026 17:56:35 +0200 [thread overview]
Message-ID: <2026033001-doorframe-reforest-d967@gregkh> (raw)
In-Reply-To: <CABJ81biO14i_FCxeMCTZkXGofxN+Lvw8H7UmG5v_qLi2CJovGQ@mail.gmail.com>
On Thu, Mar 26, 2026 at 12:42:27AM +0530, Ayush Mukkanwar wrote:
> On Wed, Mar 25, 2026 at 2:41 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > 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@linuxfoundation.org> 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@gmail.com>
> > > > > ---
> > > > > 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
>
> Hi Greg,
>
> After tracing the call chains, the pr_warn() calls are inside
> ethernet-mem.c. cvm_oct_mem_fill_fpa() which eventually reaches them
> is called from two places:
>
> 1. ethernet.c via cvm_oct_configure_common_hw(), which is called from
> cvm_oct_probe() - pdev is available here.
> 2. cvm_oct_rx_refill_pool() in ethernet-rx.h, which is called from
> cvm_oct_poll() in ethernet-rx.c - no device pointer is available there
> as it is called by the NAPI subsystem and oct_rx_group has no device
> pointer either.
>
> Since both call sites share cvm_oct_mem_fill_fpa(), adding a struct
> device * parameter would break the second call site. The FPA pool is
> shared hardware owned by the platform device, so storing &pdev->dev in
> a static global during probe and using that in the mem functions in
> ethernet-mem.c seems like the right approach. This avoids changing any
> function parameters. The same global could also be used for the
> pr_err() calls in ethernet-spi.c, where the interrupt handler has no
> device pointer available either. Would that be acceptable, or is there
> a preferred way to handle this?
Drivers should NEVER have "shared hardware pools", they are always
device specific, so passing in the proper device everywhere is the
correct thing to be doing here.
thanks,
greg k-h
next prev parent reply other threads:[~2026-03-30 15:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 13:30 [PATCH 0/3] staging: octeon: add pr_fmt macro to ethernet drivers AyushMukkanwar
2026-03-24 13:30 ` [PATCH 1/3] staging: octeon: ethernet-mem: add pr_fmt macro AyushMukkanwar
2026-03-24 13:30 ` [PATCH 2/3] staging: octeon: ethernet-spi: " AyushMukkanwar
2026-03-24 13:30 ` [PATCH 3/3] staging: octeon: ethernet: " AyushMukkanwar
2026-03-24 14:28 ` Greg KH
2026-03-25 9:03 ` Ayush Mukkanwar
2026-03-25 9:11 ` Greg KH
2026-03-25 19:12 ` Ayush Mukkanwar
2026-03-30 15:56 ` Greg KH [this message]
2026-03-31 7:16 ` Ayush Mukkanwar
2026-03-31 8:28 ` Greg KH
2026-03-31 11:17 ` [PATCH v2 0/2] staging: octeon: replace pr_*() calls with dev_*() and netdev_*() AyushMukkanwar
2026-03-31 11:17 ` [PATCH v2 1/2] staging: octeon: ethernet-spi: replace pr_err with dev_err AyushMukkanwar
2026-04-01 10:09 ` Greg KH
2026-04-04 9:17 ` Ayush Mukkanwar
2026-04-04 9:20 ` Ayush Mukkanwar
2026-04-05 8:02 ` Greg KH
2026-03-31 11:17 ` [PATCH v2 2/2] staging: octeon: ethernet: replace pr_* with dev_* and netdev_* AyushMukkanwar
2026-04-01 1:10 ` kernel test robot
2026-04-01 9:32 ` Dan Carpenter
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=2026033001-doorframe-reforest-d967@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=ayushmukkanwar@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox