Date:   Tue, 30 Nov 2021 09:43:51 -0600
From:   Bjorn Helgaas <helgaas@kernel.org>
To:     Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
        lorenzo.pieralisi@arm.com, bhelgaas@google.com,
        svarbanov@mm-sol.com, bjorn.andersson@linaro.org, robh@kernel.org,
        linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v2] PCI: qcom: Use __be16 for catching cpu_to_be16()
 return instead of u16
Message-ID: <20211130154351.GA2738262@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <YaXc3mlBbhvEkZCX@rocinante>
Precedence: bulk

On Tue, Nov 30, 2021 at 09:12:14AM +0100, Krzysztof Wilczyński wrote:
> Hello!
> 
> [...]
> > > > cpu_to_be16() returns __be16 value but the driver uses u16 and that's
> > > > incorrect. Fix it by using __be16 as the datatype of bdf_be variable.
> > > 
> > > It would be "data type" in the above.
> > > 
> > > Not really a requirement to do so, but you could include the actual
> > > warning, as sometimes this is useful for reference later, as per:
> > > 
> > >   drivers/pci/controller/dwc/pcie-qcom.c:1346:30: warning: incorrect type in initializer (different base types)
> > >   drivers/pci/controller/dwc/pcie-qcom.c:1346:30:    expected unsigned short [usertype] bdf_be
> > >   drivers/pci/controller/dwc/pcie-qcom.c:1346:30:    got restricted __be16 [usertype]
> > > 
> > 
> > I usually do but as per Bjorn's comment I thought it is not recommended for PCI
> > subsystem (or maybe I misread his comments). Will add.
> 
> Ah right.  I must have missed his comment too.  I usually include warnings
> myself, where applicable.  Let's wait for what Bjorn says, just in case, so
> that we avoid adding something he does not want to have included in the
> commit message.

I think it's nice to include the warning in the commit log (and even
the way to *generate* the warning if it's more complicated than
"make") because that helps others verify the commit.

I just don't want the warning to be the *reason* for the commit
because it's too easy to focus on quickly removing the warning without
fully understanding whether there is an underlying defect.

Bjorn