From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755472AbcHVNpx (ORCPT ); Mon, 22 Aug 2016 09:45:53 -0400 Received: from mail-lf0-f42.google.com ([209.85.215.42]:33685 "EHLO mail-lf0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754926AbcHVNpv (ORCPT ); Mon, 22 Aug 2016 09:45:51 -0400 MIME-Version: 1.0 In-Reply-To: <20160819124414.24242-6-andrew@aj.id.au> References: <20160819124414.24242-1-andrew@aj.id.au> <20160819124414.24242-6-andrew@aj.id.au> From: Linus Walleij Date: Mon, 22 Aug 2016 15:45:48 +0200 Message-ID: Subject: Re: [PATCH v2 5/8] pinctrl: Add core support for Aspeed SoCs To: Andrew Jeffery Cc: Joel Stanley , Alexandre Courbot , Mark Rutland , Rob Herring , Benjamin Herrenschmidt , Jeremy Kerr , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 19, 2016 at 2:44 PM, Andrew Jeffery wrote: > +++ b/drivers/pinctrl/aspeed/Kconfig > @@ -0,0 +1,8 @@ > +config PINCTRL_ASPEED > + bool > + depends on (ARCH_ASPEED || COMPILE_TEST) && OF > + select PINMUX > + select PINCONF > + select GENERIC_PINCONF > + select MFD_SYSCON > + select REGMAP_MMIO Since this device is spawn from the syscon, should it not be "depends on MFD_SYSCON"? (No big deal, if you think this is right then go with it.) > +#include What is this include for? > +#include > +#include > +#include > +#include > +#include "../core.h" > +#include "pinctrl-aspeed.h" No #include ? Maybe some #includes are centralized to pinctrl-aspeed.h I don't know, just make sure you don't have implicit includes. > + if (regmap_read(map, desc->reg, &val) < 0) > + return false; > + > + val &= ~desc->mask; > + val |= pattern << __ffs(desc->mask); > + > + if (regmap_write(map, desc->reg, val) < 0) > + return false; Use: regmap_update_bits(map, desc->reg, desc->mask, pattern << __ffs->desc->mask); Or something like that instead of reimplementing mask-and-set. Regmap already knows how to do the business. (Applied everywhere in the driver where you have a mask-and-set like this). The expression core engine is still a complete mystery for me, I will just trust you that it works as intended. Yours, Linus Walleij