linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: gwshan@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,
	paulus@samba.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early()
Date: Wed, 13 Jan 2016 10:08:32 -0200	[thread overview]
Message-ID: <56963E40.8070702@linux.vnet.ibm.com> (raw)
In-Reply-To: <1452681487.7404.6.camel@ellerman.id.au>

On 01/13/2016 08:38 AM, Michael Ellerman wrote:
> But eeh_enabled() is still false? That seems like it's liable to cause breakage
> elsewhere.

Yes, eeh_enabled() is false as expected. Notice that eeh_enabled() is 
telling if EEH is enabled or not, and since it's not (because there's no 
PCI adapters on machine yet!), makes sense it returns false.

At the end of runs of eeh_add_device_early(), the devices are probed and 
EEH is enabled, so the function will reflect this. Notice that the 
problem addressed by this patch is the use of eeh_enabled() in hotplug 
operations only, which in my opinion is not correct. I checked every 
other use of eeh_enable() in the code, and they all seems appropriate, 
so I expect no errors at all.


> Shouldn't the PCI hotplug code instead be taught to initialise EEH correctly
> when the first device is added?

Well, for sure there are other ways to achieve this patch's goal, like 
refactor PCI hotplug code in lots of places. But notice although the 
proposed solution is simple, it solves the issue because 
eeh_add_device_early() is ultimately the function used by PCI hotplug 
mechanism (no matter if pseries/cell/etc or the type of hotplug) to 
initialize EEH by probing the devices at the moment they are added to 
the system. In my opinion, this is exactly the location we want to 
change code to address this issue.

What do you think? Thanks very much for the review.

Cheers,


Guilherme

  reply	other threads:[~2016-01-13 12:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-10  3:08 [PATCH] powerpc/eeh: Validate arch in eeh_add_device_early() Guilherme G. Piccoli
2016-01-13  6:04 ` Benjamin Herrenschmidt
2016-01-13 11:56   ` Guilherme G. Piccoli
2016-01-13 10:38 ` Michael Ellerman
2016-01-13 12:08   ` Guilherme G. Piccoli [this message]
2016-01-13 21:25     ` Michael Ellerman
2016-01-14 19:59       ` Guilherme G. Piccoli
2016-01-14 23:37         ` Michael Ellerman
2016-01-19 20:11           ` Guilherme G. Piccoli

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=56963E40.8070702@linux.vnet.ibm.com \
    --to=gpiccoli@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    /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).