Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754727AbcCJRXW (ORCPT ); Thu, 10 Mar 2016 12:23:22 -0500 Received: from e28smtp08.in.ibm.com ([125.16.236.8]:35936 "EHLO e28smtp08.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753448AbcCJRXQ (ORCPT ); Thu, 10 Mar 2016 12:23:16 -0500 X-IBM-Helo: d28relay04.in.ibm.com X-IBM-MailFrom: vaibhav@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org From: Vaibhav Jain To: Michael Neuling , Ian Munsie , Michael Ellerman , linux-kernel , Matt Ochs , Manoj Kumar Cc: linuxppc-dev Subject: Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events In-Reply-To: <1457580271.26279.8.camel@neuling.org> References: <1457401715-26435-1-git-send-email-imunsie@au.ibm.com> <87a8m7iunv.fsf@vajain21.in.ibm.com> <1457580271.26279.8.camel@neuling.org> User-Agent: Notmuch/0.21+45~ga5c1536 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-unknown-linux-gnu) Date: Thu, 10 Mar 2016 22:53:06 +0530 Message-ID: <87fuvyp7r9.fsf@vajain21.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable x-cbid: 16031017-0029-0000-0000-00000B72ACAC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 990 Lines: 25 Michael Neuling writes: > These are here to enable the feature in other drivers. So the cxlflash > (or whoever) can put their code in via the linux-scsi tree but that new > piece is only enabled when CXL_AFU_DRIVER_OPS is present (ie. when > merged upstream). But if it's not, their code can still compile. > > Hence their code compiles in linux-scsi and our code compiles in linux > -ppc, but only once they're together do they actually enable the full > feature. We don't have a nasty dependency of linux-scsi having to pull > in linux-ppc or visa versa before the merge window. Everyone works > independently and it all gets fixed in linus tree. > > Eventually, when everyone has the all the code in merged upstream, we > can remove these config options. We should be able to remove > CXL_KERNEL_API and CXL_EEH now actually! > > So no, we shouldn't wrap the actual code. Mikey & Ian, Agree on the point made. Thanks for detailed explaination. ~ Vaibhav