[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB9PR10MB5881479C5BE3D2A97A7D354CE0379@DB9PR10MB5881.EURPRD10.PROD.OUTLOOK.COM>
Date: Mon, 31 Oct 2022 13:26:50 +0000
From: "Starke, Daniel" <daniel.starke@...mens.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
"jirislaby@...nel.org" <jirislaby@...nel.org>,
"ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] tty: n_gsm: add parameter negotiation support
Thank you for your review.
> > + pr_err("%s: unsupported frame type %d\n", __func__,
> > + dlci->ftype);
>
> This needs to be dev_err(), right?
There is no place within this driver that uses dev_*() at the moment except
for the timeout function of the network stack (gsm_mux_net_tx_timeout()).
I do not mind either way, but I would prefer a consistent variant within
this driver. Therefore, I suggest switching from pr_*() to dev_*() in a
separate patch.
> And why is it not just dev_dbg()/
I used pr_err() instead of pr_dbg() due to the fact that this mismatch will
most likely make it impossible to use the n_gsm driver with the connected
device as it stands. I am okay to replace it with pr_info() though.
> > + pr_err("%s: unsupported adaption %d\n", __func__,
> > + dlci->adaption);
>
> Again, dev_dbg()?
>
> Do not yet userspace, or external devices, spam kernel logs with
> messages.
These are related to the user API. Therefore, I do not mind changing these
to debug level.
> > + if (n1 < MIN_MTU) {
> > + if (debug & DBG_ERRORS)
>
> Please use the proper debug code in the kernel, don't roll your own.
Again, I am only reusing what is already there in the driver. To avoid
segmentation I suggest cleaning this up in a future patch.
> > + pr_info("%s N1 out of range in PN\n", __func__);
>
> This should be dev_dbg().
Same as above. The connected device appears to be incompatible with the
based standard. It will most likely not work. Should it be debug level,
nevertheless?
> And never use __func__ in a dev_dbg() call, it's there automatically.
I could not find a hint that __func__ is included in dev_dbg(). What is
included is the subsystem name and the device name but not the function
name within the driver according to include/linux/dev_printk.h. Other
device drivers like usb/dwc2/core.c also include __func__ here. But it
appears to be possible to automate this by re-defining dev_fmt().
Please let me know if you prefer me to segment the current printk-related
code by introducing dev_*() or keep this change open for a later patch.
Best regards,
Daniel Starke
Powered by blists - more mailing lists