From: Daniel Axtens <dja@axtens.net>
To: Cyril Bur <cyrilbur@gmail.com>
Cc: linuxppc-dev@ozlabs.org, mikey@neuling.org,
"Matthew R. Ochs" <mrochs@linux.vnet.ibm.com>,
imunsie@au.ibm.com, Manoj Kumar <kumarmn@us.ibm.com>
Subject: Re: [PATCH v2 08/10] cxl: Allow the kernel to trust that an image won't change on PERST.
Date: Wed, 12 Aug 2015 09:47:58 +1000 [thread overview]
Message-ID: <1439336878.24419.41.camel@axtens.net> (raw)
In-Reply-To: <1439292157.24419.37.camel@axtens.net>
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
So after further offline conversations,
Yes, Cyril, you are right, I don't need the ifdef in my code. I just
need the symbol. I will amend my patches appropriately.
On Tue, 2015-08-11 at 21:22 +1000, Daniel Axtens wrote:
> > So I'm not super all over the putting all sorts of code inside CONFIG_CXL_EEH,
> > I understand that there is another driver being merged and they'll use
> > CONFIG_CXL_EEH so that both this driver and the other driver can go in the same
> > merge window but does this mean you need to put it around everything here?
> >
> > I may have misunderstood what you've told me but if the other driver depends on
> > work done in this one (and not the other way around), if they depend on
> > CONFIG_CXL_EEH which you create in the last patch, then they cannot be built
> > until this series exists, so they can't have issues.
> >
> > The one catch is that this series as is waits untill the last patch to actually
> > create the symbol, and therefore compile everything so lets be sure you don't
> > break bisecting. You might need to rethink the order of things in 8/10 and 9/10,
> > I can't see anything obvious if it helps...
> >
>
> Yeah, so you're right. I've taken the guards off everything except the
> new API function. I still want to leave the patch that adds the symbol
> at the end: that way you don't get the function unless it is actually
> going to make a difference in the EEH process.
>
> The other driver (cxlflash) just guards the API function, inserting a
> stub if it's not defined. So this setup will make our code cleaner and
> will still let their code merge cleanly.
>
> Thanks again for the review.
>
--
Regards,
Daniel
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 860 bytes --]
next prev parent reply other threads:[~2015-08-11 23:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 5:28 [PATCH v2 00/10] CXL EEH Handling Daniel Axtens
2015-07-28 5:28 ` [PATCH v2 01/10] cxl: Drop commands if the PCI channel is not in normal state Daniel Axtens
2015-08-11 3:31 ` Cyril Bur
2015-08-11 4:11 ` Daniel Axtens
2015-07-28 5:28 ` [PATCH v2 02/10] cxl: Allocate and release the SPA with the AFU Daniel Axtens
2015-08-11 3:42 ` Cyril Bur
2015-08-11 4:16 ` Daniel Axtens
2015-07-28 5:28 ` [PATCH v2 03/10] cxl: Make IRQ release idempotent Daniel Axtens
2015-08-11 3:44 ` Cyril Bur
2015-07-28 5:28 ` [PATCH v2 04/10] cxl: Clean up adapter MMIO unmap path Daniel Axtens
2015-08-11 3:52 ` Cyril Bur
2015-08-11 6:38 ` Daniel Axtens
2015-07-28 5:28 ` [PATCH v2 05/10] cxl: Refactor adaptor init/teardown Daniel Axtens
2015-08-11 6:01 ` Cyril Bur
2015-08-11 22:38 ` Daniel Axtens
2015-08-12 10:14 ` David Laight
2015-08-12 21:58 ` Daniel Axtens
2015-07-28 5:28 ` [PATCH v2 06/10] cxl: Refactor AFU init/teardown Daniel Axtens
2015-08-11 3:59 ` Cyril Bur
2015-07-28 5:28 ` [PATCH v2 07/10] cxl: Don't remove AFUs/vPHBs in cxl_reset Daniel Axtens
2015-08-11 5:57 ` Cyril Bur
2015-07-28 5:28 ` [PATCH v2 08/10] cxl: Allow the kernel to trust that an image won't change on PERST Daniel Axtens
2015-08-11 7:15 ` Cyril Bur
2015-08-11 11:22 ` Daniel Axtens
2015-08-11 23:47 ` Daniel Axtens [this message]
2015-07-28 5:28 ` [PATCH v2 09/10] cxl: EEH support Daniel Axtens
2015-08-11 7:23 ` Cyril Bur
2015-07-28 5:28 ` [PATCH v2 10/10] cxl: Add CONFIG_CXL_EEH symbol Daniel Axtens
2015-08-11 3:59 ` Cyril Bur
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=1439336878.24419.41.camel@axtens.net \
--to=dja@axtens.net \
--cc=cyrilbur@gmail.com \
--cc=imunsie@au.ibm.com \
--cc=kumarmn@us.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.org \
--cc=mrochs@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.