From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v2 3/4] ata: add APM X-Gene SoC 6.0Gbps SATA PHY driver Date: Wed, 20 Nov 2013 19:46:52 +0100 Message-ID: <201311201946.52659.arnd@arndb.de> References: <1384905197-3566-1-git-send-email-lho@apm.com> <201311201641.20230.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Tejun Heo Cc: "devicetree@vger.kernel.org" , Suman Tripathi , "linux-scsi@vger.kernel.org" , jcm@redhat.com, linux-ide , Loc Ho , olof@lixom.net, Tuan Phan , "linux-arm-kernel@lists.infradead.org" List-Id: linux-ide@vger.kernel.org On Wednesday 20 November 2013, Tejun Heo wrote: > On Wed, Nov 20, 2013 at 10:41 AM, Arnd Bergmann wrote: > > It needs to be in drivers/phy, which is currently being prepared for > > the next merge window and which contains the generic interface used > > in this driver. > > Ah, cool, so I don't need to worry about this one, right? Right, we just need to make sure the patches are staged the right way when they go through different subsystem maintainers. There should not be any build-time dependencies, so I think it won't be an issue. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Wed, 20 Nov 2013 19:46:52 +0100 Subject: [PATCH v2 3/4] ata: add APM X-Gene SoC 6.0Gbps SATA PHY driver In-Reply-To: References: <1384905197-3566-1-git-send-email-lho@apm.com> <201311201641.20230.arnd@arndb.de> Message-ID: <201311201946.52659.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday 20 November 2013, Tejun Heo wrote: > On Wed, Nov 20, 2013 at 10:41 AM, Arnd Bergmann wrote: > > It needs to be in drivers/phy, which is currently being prepared for > > the next merge window and which contains the generic interface used > > in this driver. > > Ah, cool, so I don't need to worry about this one, right? Right, we just need to make sure the patches are staged the right way when they go through different subsystem maintainers. There should not be any build-time dependencies, so I think it won't be an issue. Arnd