From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753817AbbBMReO (ORCPT ); Fri, 13 Feb 2015 12:34:14 -0500 Received: from vps0.lunn.ch ([178.209.37.122]:43715 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753778AbbBMReK (ORCPT ); Fri, 13 Feb 2015 12:34:10 -0500 Date: Fri, 13 Feb 2015 18:31:21 +0100 From: Andrew Lunn To: Antoine Tenart Cc: sebastian.hesselbarth@gmail.com, mturquette@linaro.org, sboyd@codeaurora.org, zmxu@marvell.com, jszhang@marvell.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 0/7] ARM: berlin: refactor the clock Message-ID: <20150213173121.GG26475@lunn.ch> References: <1423845781-7480-1-git-send-email-antoine.tenart@free-electrons.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1423845781-7480-1-git-send-email-antoine.tenart@free-electrons.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 13, 2015 at 05:42:54PM +0100, Antoine Tenart wrote: > Hi, > > Marvell Berlin SoCs have a chip control register set providing several > individual registers dealing with various controllers (pinctrl, reset, > clk). This chip controller is described by a single DT node since the > individual registers are spread among the chip control register bank. > > Marvell Berlin also have a system control register set providing several > individual registers for pinctrl or adc. > > A series was sent[1] to correctly handle these two nodes, by introducing > a Berlin mfd controller driver. The series converted the existing > pin-controller and reset drivers to take the changes into account. Hi Antoine Something which needs to be discussed for both this patchset and the previous one, is backwards compatibility of the device tree. As far as i can see, these changes are not backwards compatible. Somebody trying to boot a new kernel with a old DT blob is going to have trouble. How do we want to handle this? Andrew