Re: [smartpqi updates PATCH 2/9] smartpqi: rm unsupported controller features msgs

[Paul Menzel]

[I corrected Martin’s email from peterson to peters*e*n. Don, you should 
have also receive a bounce message from the MTA. I guess Martin has 
these as a list subscriber nevertheless, but I suggest to resend the 
series as soon as possible.]

Dear Don,


Thank you for your reply.


Am 08.07.21 um 21:04 schrieb Don.Brace@xxxxxxxxxxxxx:
> -----Original Message-----
> From: Paul Menzel [mailto:pmenzel@xxxxxxxxxxxxx]
> Sent: Wednesday, July 7, 2021 2:29 AM
> Subject: Re: [smartpqi updates PATCH 2/9] smartpqi: rm unsupported controller features msgs

> Am 06.07.21 um 20:16 schrieb Don Brace:
> > From: Kevin Barnett <kevin.barnett@xxxxxxxxxxxxx>
> >
> > Remove "Feature XYZ not supported by controller" messages.
> >
> > During driver initialization, the driver examines the PQI Table Feature bits.
> > These bits are used by the controller to advertise features supported
> > by the controller. For any features not supported by the controller,
> > the driver would display a message in the form:
> >           "Feature XYZ not supported by controller"
> > Some of these "negative" messages were causing customer confusion.
>
> As it’s info log level and not warning or notice, these message are
> useful in my opinion. You could downgrade them to debug, but I do not
> see why. If customers do not want to see these info messages, they
> should filter them out.
>
> For completeness, is there an alternative to list the unsupported
> features from the firmware for example from sysfs?

> Don> Thanks for your Review. At this time we would prefer to not
> provide messages about unsupported features.

Only because a customer complained? That is not a good enough reason in 
my opinion. Log messages, often grepped for, are an interface which 
should only be changed with caution.

If these absent feature message were present for a long time, and you 
suddenly remove them, people looking a newer Linux kernel messages, 
users conclude the feature is supported now. That is quite a downside in 
my opinion.

> We may add them back at some point but we have taken them out of our
> out-of-box driver also so we hope to keep the driver code in sync.
That’s why you should develop for Linux master branch and upstream 
*first* to get external reviews. That argument should not count for 
Linux upstream reviews in my opinion.


Kind regards,

Paul


> > Reviewed-by: Mike McGowen <mike.mcgowen@xxxxxxxxxxxxx>
> > Reviewed-by: Scott Benesh <scott.benesh@xxxxxxxxxxxxx>
> > Reviewed-by: Scott Teel <scott.teel@xxxxxxxxxxxxx>
> > Signed-off-by: Kevin Barnett <kevin.barnett@xxxxxxxxxxxxx>
> > Signed-off-by: Don Brace <don.brace@xxxxxxxxxxxxx>
> > ---
> >    drivers/scsi/smartpqi/smartpqi_init.c | 5 +----
> >    1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/scsi/smartpqi/smartpqi_init.c
> > b/drivers/scsi/smartpqi/smartpqi_init.c
> > index d977c7b30d5c..7958316841a4 100644
> > --- a/drivers/scsi/smartpqi/smartpqi_init.c
> > +++ b/drivers/scsi/smartpqi/smartpqi_init.c
> > @@ -7255,11 +7255,8 @@ struct pqi_firmware_feature {
> >    static void pqi_firmware_feature_status(struct pqi_ctrl_info *ctrl_info,
> >        struct pqi_firmware_feature *firmware_feature)
> >    {
> > -     if (!firmware_feature->supported) {
> > -             dev_info(&ctrl_info->pci_dev->dev, "%s not supported by controller\n",
> > -                     firmware_feature->feature_name);
> > +     if (!firmware_feature->supported)
> >                return;
> > -     }
> >
> >        if (firmware_feature->enabled) {
> >                dev_info(&ctrl_info->pci_dev->dev,