linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alex G." <mr.nuke.me@gmail.com>
To: Sinan Kaya <okaya@kernel.org>,
	bhelgaas@google.com, keith.busch@intel.com
Cc: alex_gagniuc@dellteam.com, austin_bolen@dell.com,
	shyam_iyer@dell.com, Frederick Lawler <fred@fredlawl.com>,
	Oza Pawandeep <poza@codeaurora.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI/AER: Do not clear AER bits if we don't own AER
Date: Thu, 19 Jul 2018 14:56:06 -0500	[thread overview]
Message-ID: <61c8a5d7-d520-e927-071a-bf5620bc0f4e@gmail.com> (raw)
In-Reply-To: <da6335db-1e6b-c19b-4bbd-0f5523484e0e@kernel.org>



On 07/19/2018 11:58 AM, Sinan Kaya wrote:
> 
> On 7/19/2018 8:55 AM, Alex G. wrote:
>> I find the intent clearer if we check it here rather than having to do 
>> the mental parsing of the state of aer_cap.
> 
> I don't feel too strong about my comment to be honest. This was a
> style/maintenance comment.
> 
> It feels like we are putting pcie_aer_get_firmware_first() into core
> functions unnecessarily after your change. I understand the need for
> your change. I'm asking if it is the right place or not.
> 
> pcie_aer_get_firmware_first() should be called from either the init or
> probe function so that the rest of the AER functions do not get called
> from any other context.
> 
> If someone adds another AER function, we might need to add another
> pcie_aer_get_firmware_first() check there. So, we have unnecessary code
> duplication.

We could move the aer_cap and get_ffs() check into one function that we 
end up calling all over the place. I understand your concern about code 
duplication, and I agree with it. I don't think that at this point it's 
that big of a deal, although we might need to guard every aer_() call.

So moving all the checks in a pcie_aer_is_kernel_first() makes sense.

Alex

  reply	other threads:[~2018-07-19 19:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17 15:31 [PATCH] PCI/AER: Do not clear AER bits if we don't own AER Alexandru Gagniuc
2018-07-17 15:41 ` Sinan Kaya
2018-07-19 15:55   ` Alex G.
2018-07-19 16:58     ` Sinan Kaya
2018-07-19 19:56       ` Alex G. [this message]
2018-07-23 16:52 ` [PATCH v2] " Alexandru Gagniuc
2018-07-24 15:59   ` Alex G.
2018-07-30 23:35     ` [PATCH v3] " Alexandru Gagniuc
2018-08-08  1:14       ` Bjorn Helgaas
2018-08-08  3:46         ` Alex G.
2018-07-24 17:08   ` [PATCH v2] " kbuild test robot
2018-07-25  1:03   ` kbuild test robot
2018-08-09 14:15 ` [PATCH] " Bjorn Helgaas
2018-08-09 16:46   ` Alex_Gagniuc
2018-08-09 18:29     ` Bjorn Helgaas
2018-08-09 19:00       ` Alex G.
2018-08-09 19:18         ` Bjorn Helgaas
2018-08-09 19:42           ` Alex G.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=61c8a5d7-d520-e927-071a-bf5620bc0f4e@gmail.com \
    --to=mr.nuke.me@gmail.com \
    --cc=alex_gagniuc@dellteam.com \
    --cc=austin_bolen@dell.com \
    --cc=bhelgaas@google.com \
    --cc=fred@fredlawl.com \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=okaya@kernel.org \
    --cc=poza@codeaurora.org \
    --cc=shyam_iyer@dell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).