All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jacob Keller <jacob.e.keller@intel.com>,
	Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v1] ixgbe: guard fwlog code by CONFIG_DEBUG_FS
Date: Wed, 15 Oct 2025 21:07:26 +0200	[thread overview]
Message-ID: <aO/w7gnXquHNK6k7@mev-dev.igk.intel.com> (raw)
In-Reply-To: <e94f188d-3578-447f-8815-6c2393f2f807@roeck-us.net>

On Wed, Oct 15, 2025 at 10:53:45AM -0700, Guenter Roeck wrote:
> On 10/15/25 10:32, Jacob Keller wrote:
> > 
> > 
> > On 10/14/2025 10:24 PM, Michal Swiatkowski wrote:
> > > On Tue, Oct 14, 2025 at 04:41:43PM -0700, Jacob Keller wrote:
> > > > 
> > > > 
> > > > On 10/14/2025 7:11 AM, Michal Swiatkowski wrote:
> > > > > Building the ixgbe without CONFIG_DEBUG_FS leads to a build error. Fix
> > > > > that by guarding fwlog code.
> > > > > 
> > > > > Fixes: 641585bc978e ("ixgbe: fwlog support for e610")
> > > > > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > > > > Closes: https://lore.kernel.org/lkml/f594c621-f9e1-49f2-af31-23fbcb176058@roeck-us.net/
> > > > > Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> > > > > ---
> > > > 
> > > > Hm. It probably is best to make this optional and not require debugfs
> > > > via kconfig.
> > > 
> > > Make sense
> > > 
> > > > 
> > > > >   drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c | 2 ++
> > > > >   drivers/net/ethernet/intel/ixgbe/ixgbe_e610.h | 8 ++++++++
> > > > >   2 files changed, 10 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
> > > > > index c2f8189a0738..c5d76222df18 100644
> > > > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
> > > > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c
> > > > > @@ -3921,6 +3921,7 @@ static int ixgbe_read_pba_string_e610(struct ixgbe_hw *hw, u8 *pba_num,
> > > > >   	return err;
> > > > >   }
> > > > > +#ifdef CONFIG_DEBUG_FS
> > > > >   static int __fwlog_send_cmd(void *priv, struct libie_aq_desc *desc, void *buf,
> > > > >   			    u16 size)
> > > > >   {
> > > > > @@ -3952,6 +3953,7 @@ void ixgbe_fwlog_deinit(struct ixgbe_hw *hw)
> > > > >   	libie_fwlog_deinit(&hw->fwlog);
> > > > >   }
> > > > > +#endif /* CONFIG_DEBUG_FS */
> > > > 
> > > > What does the fwlog module from libie do? Seems likely that it won't
> > > > compile without CONFIG_DEBUG_FS either...
> > > 
> > > Right, it shouldn't, because there is a dependency on fs/debugfs.
> > > It is building on my env, but maybe I don't have it fully cleaned.

BTW, it is building because DEBUG_FS also have dummy functions if not
selected.

> > > I wonder, because in ice there wasn't a check (or select) for
> > > CONFIG_DEBUG_FS for fwlog code.
> > > 
> > > Looks like LIBIE_FWLOG should select DEBUG_FS, right?
> > > I will send v2 with that, if it is fine.
> > > 
> > > Thanks
> > > 
> > My only worry is that could lead to ice selecting LIBIE_FWLOG which then
> > selects DEBUG_FS which then means we implicitly require DEBUG_FS regardless.
> > 
> > I don't quite remember the semantics of select and whether that would
> > let you build a kernel without DEBUG_FS.. I think some systems would
> > like to be able to disable DEBUG_FS as a way of limiting scope of
> > available interfaces exposed by the kernel.
> >

Yeah, the idea with dummy functions is better, thanks for your input.

> 
> If fwlog depends on debugfs, why not spell out that dependency and
> provide dummy functions if it isn't enabled ? The Kconfig entries
> selecting it could then be changed to
> 	select LIBIE_FWLOG if DEBUG_FS
> 

Sounds good, thanks.

> Guenter
> 

      reply	other threads:[~2025-10-15 19:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14 14:11 [Intel-wired-lan] [PATCH iwl-net v1] ixgbe: guard fwlog code by CONFIG_DEBUG_FS Michal Swiatkowski
2025-10-14 14:11 ` Michal Swiatkowski
2025-10-14 23:41 ` [Intel-wired-lan] " Jacob Keller
2025-10-15  5:24   ` Michal Swiatkowski
2025-10-15 17:32     ` Jacob Keller
2025-10-15 17:53       ` Guenter Roeck
2025-10-15 19:07         ` Michal Swiatkowski [this message]

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=aO/w7gnXquHNK6k7@mev-dev.igk.intel.com \
    --to=michal.swiatkowski@linux.intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=linux@roeck-us.net \
    --cc=netdev@vger.kernel.org \
    /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.