[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,
