[<prev] [next>] [day] [month] [year] [list]
Message-ID: <e0e28988-9699-4e6c-abb0-30fa2727c2c3@ti.com>
Date: Mon, 20 May 2024 16:46:34 +0530
From: Siddharth Vadapalli <s-vadapalli@...com>
To: Onkarnath <onkarnath.1@...sung.com>
CC: Siddharth Vadapalli <s-vadapalli@...com>,
"bhelgaas@...gle.com"
<bhelgaas@...gle.com>,
"vigneshr@...com" <vigneshr@...com>,
"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
"kw@...ux.com"
<kw@...ux.com>, "robh@...nel.org" <robh@...nel.org>,
"yue.wang@...ogic.com"
<yue.wang@...ogic.com>,
"neil.armstrong@...aro.org"
<neil.armstrong@...aro.org>,
"khilman@...libre.com" <khilman@...libre.com>,
"jbrunet@...libre.com" <jbrunet@...libre.com>,
"martin.blumenstingl@...glemail.com" <martin.blumenstingl@...glemail.com>,
"thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
"shawn.guo@...aro.org" <shawn.guo@...aro.org>,
"lchuanhua@...linear.com"
<lchuanhua@...linear.com>,
"srikanth.thokala@...el.com"
<srikanth.thokala@...el.com>,
"songxiaowei@...ilicon.com"
<songxiaowei@...ilicon.com>,
"wangbinghui@...ilicon.com"
<wangbinghui@...ilicon.com>,
"manivannan.sadhasivam@...aro.org"
<manivannan.sadhasivam@...aro.org>,
"thierry.reding@...il.com"
<thierry.reding@...il.com>,
"jonathanh@...dia.com" <jonathanh@...dia.com>,
"hayashi.kunihiko@...ionext.com" <hayashi.kunihiko@...ionext.com>,
"mhiramat@...nel.org" <mhiramat@...nel.org>,
"pali@...nel.org"
<pali@...nel.org>,
"toan@...amperecomputing.com"
<toan@...amperecomputing.com>,
"daire.mcnamara@...rochip.com"
<daire.mcnamara@...rochip.com>,
"conor.dooley@...rochip.com"
<conor.dooley@...rochip.com>,
"marek.vasut+renesas@...il.com"
<marek.vasut+renesas@...il.com>,
"shawn.lin@...k-chips.com"
<shawn.lin@...k-chips.com>,
"heiko@...ech.de" <heiko@...ech.de>,
"nirmal.patel@...ux.intel.com" <nirmal.patel@...ux.intel.com>,
"jonathan.derrick@...ux.dev" <jonathan.derrick@...ux.dev>,
"kishon@...nel.org" <kishon@...nel.org>,
"jdmason@...zu.us"
<jdmason@...zu.us>,
"dave.jiang@...el.com" <dave.jiang@...el.com>,
"rafael@...nel.org" <rafael@...nel.org>,
"lenb@...nel.org" <lenb@...nel.org>,
"mahesh@...ux.ibm.com" <mahesh@...ux.ibm.com>,
"oohall@...il.com"
<oohall@...il.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-amlogic@...ts.infradead.org"
<linux-amlogic@...ts.infradead.org>,
"linux-arm-msm@...r.kernel.org"
<linux-arm-msm@...r.kernel.org>,
"linux-tegra@...r.kernel.org"
<linux-tegra@...r.kernel.org>,
Rohit Thapliyal <r.thapliyal@...sung.com>,
Maninder Singh <maninder1.s@...sung.com>
Subject: Re: [PATCH 1/1] PCI : Refactoring error log prints for better
readability
On Mon, May 20, 2024 at 04:13:58PM +0530, Onkarnath wrote:
> Hi,
>
>
[...]
>
> >>Similar question as above regarding converting "failed, ret" to
>
> >>"failed:". Is this a new convention that is expected to be followed,
>
> >where all errors are supposed to have "failed: %pe", rather than custom
>
> >statements? Please let me know if this has already been discussed
>
> >elsewhere.
>
>
> Bjorn suggested to make all errors consistent.
>
> and I thought printing error like below:
>
>
> "gpio request failed: -ENOMEM".
>
>
> Seems more suitable than
>
>
> "gpio request failed, ret (-ENOMEM)".
>
>
> If it needs to be changed in other format, please let me know, i will make all
> errors in that format.
>
> and will share v2.
Thank you for clarifying. It appeared to me that the suggestion was
limited to the %d to %pe conversion. The existing implementation looks
good in that case.
Regards,
Siddharth.
Powered by blists - more mailing lists