Messages in this thread | | | Subject | Re: [smartpqi updates PATCH 2/9] smartpqi: rm unsupported controller features msgs | From | Paul Menzel <> | Date | Fri, 9 Jul 2021 09:24:21 +0200 |
| |
[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@microchip.com: > -----Original Message----- > From: Paul Menzel [mailto:pmenzel@molgen.mpg.de] > 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@microchip.com> >> >> 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@microchip.com> >> Reviewed-by: Scott Benesh <scott.benesh@microchip.com> >> Reviewed-by: Scott Teel <scott.teel@microchip.com> >> Signed-off-by: Kevin Barnett <kevin.barnett@microchip.com> >> Signed-off-by: Don Brace <don.brace@microchip.com> >> --- >> 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, >>
| |