From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Suchanek Subject: Re: [PATCH v3 07/13] spi: sunxi: rename constants to match between sun4i and sun6i Date: Tue, 14 Jun 2016 06:43:39 +0200 Message-ID: References: Reply-To: hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Julian Calaby Cc: linux-sunxi , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Maxime Ripard , Chen-Yu Tsai , Russell King , Mark Brown , Arnd Bergmann , Olof Johansson , Krzysztof Kozlowski , Javier Martinez Canillas , Simon Horman , Sjoerd Simons , Thierry Reding , Alison Wang , Timo Sigurdsson , Jonathan Liu , Gerhard Bertelsmann , Priit Laes devicet List-Id: devicetree@vger.kernel.org Hello, On 14 June 2016 at 01:31, Julian Calaby wrote: > Hi Michal, > > On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: >> SUNXI_CTL_ -> SUNXI_TFR_CTL_ >> SUNXI_TFR_CTL_LMTF -> SUNXI_TFR_CTL_FBS > > I don't know these abbreviations, are they both referring to the same thing? > >> SUNXI_TFR_CTL_CS_ACTIVE_LOW -> SUNXI_TFR_CTL_SPOL > > It looks like you're making the constant name less descriptive here. > Is the old version (CS_ACTIVE_LOW) incorrect? > >> and some SUNXI_???_CTL_ -> SUNXI_CTL_ >> for constants migrated to different registers between sun4i and sun6i >> >> No functional change. >> >> #define SUNXI_INT_CTL_REG 0x0c >> diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c >> index a27bf8f..f26b52a 100644 >> --- a/drivers/spi/spi-sun6i.c >> +++ b/drivers/spi/spi-sun6i.c >> @@ -26,9 +26,9 @@ >> #define SUNXI_FIFO_DEPTH 128 >> >> #define SUNXI_GBL_CTL_REG 0x04 >> -#define SUNXI_GBL_CTL_BUS_ENABLE BIT(0) >> -#define SUNXI_GBL_CTL_MASTER BIT(1) >> -#define SUNXI_GBL_CTL_TP BIT(7) >> +#define SUNXI_CTL_ENABLE BIT(0) >> +#define SUNXI_CTL_MASTER BIT(1) >> +#define SUNXI_CTL_TP BIT(7) > > If these are bit definitions for the GBL register, why throw that > information away? Those bits are on the TFR register in the earlier IP so it makes perfect sense to me this way. Thanks Michal