All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	netdev@vger.kernel.org, davem@davemloft.net,
	linux-can@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH net-next 06/10] can: rcar_canfd: Repurpose f_dcfg base for other registers
Date: Thu, 19 Jun 2025 07:22:13 -0700	[thread overview]
Message-ID: <20250619072213.3d84c100@kernel.org> (raw)
In-Reply-To: <CAMuHMdU=7YUZgcwK_annDigTgE9YqQ=sxjtF9ttAGzPV-7wR6A@mail.gmail.com>

On Thu, 19 Jun 2025 12:16:00 +0200 Geert Uytterhoeven wrote:
> On Thu, 19 Jun 2025 at 06:43, Vincent Mailhol <mailhol.vincent@wanadoo.fr> wrote:
> > On Thu. 19 Jun. 2025 at 10:38, Jakub Kicinski <kuba@kernel.org> wrote:  
> > > On Wed, 18 Jun 2025 11:20:00 +0200 Marc Kleine-Budde wrote:  
> > > > +static inline unsigned int rcar_canfd_f_cfdcrc(struct rcar_canfd_global *gpriv,
> > > > +                                            unsigned int ch)
> > > > +{
> > > > +     return gpriv->info->regs->coffset + 0x10 + 0x20 * ch;
> > > > +}  
> > >
> > > clang is no longer fooled by static inline, it identifies that 4 out of  
> 
> Oh well, that explains why someone pointed to a CI log showing more
> unused functions in a different driver.  I hope it only does that
> for unused functions in .c files, not in header files?

Yes, AFAIU it's clever enough to distinguish what came in from 
the headers.

> > > these functions are never called. I think one ends up getting used in
> > > patch 10 (just looking at warning counts), but the other 3 remain dead
> > > code. Geert, do you have a strong attachment to having all helpers
> > > defined or can we trim this, please?  
> 
> I would like to keep them (or at least the information), as it serves
> as register documentation, just like the macros they replaced....

Okay, we'll pull, but we really should try to keep the tree free of W=1
warnings. The CI can deal with existing warnings but they will annoy
humans doing development. Maybe there is a way to disable the warning
selectively for rcar if you find it unhelpful? And then we'll see if
some well meaning code janitor sends a patch to delete them anyway ;)

  reply	other threads:[~2025-06-19 14:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18  9:19 [PATCH net-next 0/10] pull-request: can-next 2025-06-18 Marc Kleine-Budde
2025-06-18  9:19 ` [PATCH net-next 01/10] can: rcar_canfd: Consistently use ndev for net_device pointers Marc Kleine-Budde
2025-06-19 15:30   ` patchwork-bot+netdevbpf
2025-06-18  9:19 ` [PATCH net-next 02/10] can: rcar_canfd: Remove bittiming debug prints Marc Kleine-Budde
2025-06-18  9:19 ` [PATCH net-next 03/10] can: rcar_canfd: Add helper variable ndev to rcar_canfd_rx_pkt() Marc Kleine-Budde
2025-06-18  9:19 ` [PATCH net-next 04/10] can: rcar_canfd: Add helper variable dev to rcar_canfd_reset_controller() Marc Kleine-Budde
2025-06-18  9:19 ` [PATCH net-next 05/10] can: rcar_canfd: Simplify data access in rcar_canfd_{ge,pu}t_data() Marc Kleine-Budde
2025-06-18  9:20 ` [PATCH net-next 06/10] can: rcar_canfd: Repurpose f_dcfg base for other registers Marc Kleine-Budde
2025-06-19  1:38   ` Jakub Kicinski
2025-06-19  4:43     ` Vincent Mailhol
2025-06-19 10:16       ` Geert Uytterhoeven
2025-06-19 14:22         ` Jakub Kicinski [this message]
2025-06-18  9:20 ` [PATCH net-next 07/10] can: rcar_canfd: Rename rcar_canfd_setrnc() to rcar_canfd_set_rnc() Marc Kleine-Budde
2025-06-18  9:20 ` [PATCH net-next 08/10] can: rcar_canfd: Share config code in rcar_canfd_set_bittiming() Marc Kleine-Budde
2025-06-18  9:20 ` [PATCH net-next 09/10] can: rcar_canfd: Return early in rcar_canfd_set_bittiming() when not FD Marc Kleine-Budde
2025-06-18  9:20 ` [PATCH net-next 10/10] can: rcar_canfd: Add support for Transceiver Delay Compensation Marc Kleine-Budde

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=20250619072213.3d84c100@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=geert@linux-m68k.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=mkl@pengutronix.de \
    --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.