lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ