-----Original Message----- From: Paul Menzel [mailto:pmenzel@xxxxxxxxxxxxx] 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. Don: It was many customers. Enough to have our customer support ask for the messages to be redacted. Also, some of the messages were erroneous causing yet more confusion. I'm sorry, but they have to be removed. 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. Don: Thanks for your suggestion. Our model has a lot of internal reviews, then several weeks or more of testing before we add patches to the kernel. More automated tests are added daily. Any changes from the kernel community are included in our model. 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, >>
