From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755226AbbFRNaF (ORCPT ); Thu, 18 Jun 2015 09:30:05 -0400 Received: from eusmtp01.atmel.com ([212.144.249.243]:7333 "EHLO eusmtp01.atmel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752084AbbFRN34 (ORCPT ); Thu, 18 Jun 2015 09:29:56 -0400 Message-ID: <5582C797.80203@atmel.com> Date: Thu, 18 Jun 2015 15:28:55 +0200 From: Nicolas Ferre Organization: atmel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alexandre Belloni , Paul Bolle CC: Boris Brezillon , , Ludovic Desroches , Josh Wu , , Subject: Re: [PATCH] clk: at91: add generated clock driver References: <1434547409-12232-1-git-send-email-nicolas.ferre@atmel.com> <1434611556.2385.8.camel@x220> <20150618093344.7d486e97@bbrezillon> <55827606.7020908@atmel.com> <1434614090.2385.19.camel@x220> <20150618125918.GC27492@piout.net> In-Reply-To: <20150618125918.GC27492@piout.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.161.30.18] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 18/06/2015 14:59, Alexandre Belloni a écrit : > On 18/06/2015 at 09:54:50 +0200, Paul Bolle wrote : >>> I'd like though that this matter of fact doesn't block this piece of >>> code from being reviewed or even better merged in order to ease this new >>> SoC landing... >> >> The other side of that is that the sama5d2 might never make it, or take >> very long to make it, into mainline. And this would then end up being >> yet another chunk of code adding no value to mainline. >> > > Come on Paul, you prefer the current situation were each vendor have > there tree and when support for an SoC lands in mainline it is already > deprecated? > > You have one vendor here, trying to get support for its SoC even before > the silicon is available. Intel is always cited as being a good player > in the linux community for doing exactly that. They even have to remove > support for a CPU that was never manufactured... > The main difference here is that we are no longer doinc everything in > mach-xxx so we have to get the driver part mainlined and this requires > synchronization. I really belive that you can't blame Nicolas to get the > drivers first then the SoC in. > > Also, Atmel has a good track record and their SocS are almost fully > supported in mainline, you can trust that sama5d2 support is going to > land there soon. I've just posted it BTW. And it contains the "HAVE_AT91_GENERATED" symbol. Bye, -- Nicolas Ferre From mboxrd@z Thu Jan 1 00:00:00 1970 From: nicolas.ferre@atmel.com (Nicolas Ferre) Date: Thu, 18 Jun 2015 15:28:55 +0200 Subject: [PATCH] clk: at91: add generated clock driver In-Reply-To: <20150618125918.GC27492@piout.net> References: <1434547409-12232-1-git-send-email-nicolas.ferre@atmel.com> <1434611556.2385.8.camel@x220> <20150618093344.7d486e97@bbrezillon> <55827606.7020908@atmel.com> <1434614090.2385.19.camel@x220> <20150618125918.GC27492@piout.net> Message-ID: <5582C797.80203@atmel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Le 18/06/2015 14:59, Alexandre Belloni a ?crit : > On 18/06/2015 at 09:54:50 +0200, Paul Bolle wrote : >>> I'd like though that this matter of fact doesn't block this piece of >>> code from being reviewed or even better merged in order to ease this new >>> SoC landing... >> >> The other side of that is that the sama5d2 might never make it, or take >> very long to make it, into mainline. And this would then end up being >> yet another chunk of code adding no value to mainline. >> > > Come on Paul, you prefer the current situation were each vendor have > there tree and when support for an SoC lands in mainline it is already > deprecated? > > You have one vendor here, trying to get support for its SoC even before > the silicon is available. Intel is always cited as being a good player > in the linux community for doing exactly that. They even have to remove > support for a CPU that was never manufactured... > The main difference here is that we are no longer doinc everything in > mach-xxx so we have to get the driver part mainlined and this requires > synchronization. I really belive that you can't blame Nicolas to get the > drivers first then the SoC in. > > Also, Atmel has a good track record and their SocS are almost fully > supported in mainline, you can trust that sama5d2 support is going to > land there soon. I've just posted it BTW. And it contains the "HAVE_AT91_GENERATED" symbol. Bye, -- Nicolas Ferre