RE: [PATCH] net: ethernet: renesas: rswitch: Fix MAC address info

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Thursday, November 17, 2022 6:38 PM
> 
> Hi Leon,
> 
> On Thu, Nov 17, 2022 at 10:14 AM Leon Romanovsky <leon@xxxxxxxxxx> wrote:
> > On Thu, Nov 17, 2022 at 09:59:55AM +0100, Geert Uytterhoeven wrote:
> > > On Thu, Nov 17, 2022 at 9:58 AM Yoshihiro Shimoda
> > > <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote:
> > > > > From: Leon Romanovsky, Sent: Thursday, November 17, 2022 3:09 PM
> > > > > > --- a/drivers/net/ethernet/renesas/rswitch.c
> > > > > > +++ b/drivers/net/ethernet/renesas/rswitch.c
> > > > > > @@ -1714,7 +1714,7 @@ static int rswitch_init(struct rswitch_private *priv)
> > > > > >     }
> > > > > >
> > > > > >     for (i = 0; i < RSWITCH_NUM_PORTS; i++)
> > > > > > -           netdev_info(priv->rdev[i]->ndev, "MAC address %pMn",
> > > > > > +           netdev_info(priv->rdev[i]->ndev, "MAC address %pM\n",
> > > > >
> > > > > You can safely drop '\n' from here. It is not needed while printing one
> > > > > line.
> > > >
> > > > Oh, I didn't know that. I'll remove '\n' from here on v2 patch.
> > >
> > > Please don't remove it.  The convention is to have the newlines.
> >
> > Can you please explain why?
> 
> I'm quite sure this was discussed in the context of commits
> 5fd29d6ccbc98884 ("printk: clean up handling of log-levels and
> newlines") and 4bcc595ccd80decb ("printk: reinstate KERN_CONT for
> printing continuation lines"), but I couldn't find a pointer to an
> official statement.
> 
> I did find[1], which states:
> 
>     The printk subsystem will, for every printk, check
>     if the last printk has a newline termination and if
>     it doesn't and the current printk does not start with
>     KERN_CONT will insert a newline.
> 
>     The negative to this approach is the last printk,
>     if it does not have a newline, is buffered and not
>     emitted until another printk occurs.

Thank you for your reply and sharing information.
I'll keep '\n' on v2 patch.

Best regards,
Yoshihiro Shimoda

>     There is also the (now small) possibility that
>     multiple concurrent kernel threads or processes
>     could interleave printks without a terminating
>     newline and a different process could emit a
>     printk that starts with KERN_CONT and the emitted
>     message could be garbled.
> 
> [1]
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds




[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux