From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752473AbdC2OJn (ORCPT ); Wed, 29 Mar 2017 10:09:43 -0400 Received: from relmlor4.renesas.com ([210.160.252.174]:50443 "EHLO relmlie3.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751666AbdC2OJk (ORCPT ); Wed, 29 Mar 2017 10:09:40 -0400 X-IronPort-AV: E=Sophos;i="5.36,241,1486393200"; d="scan'208";a="238123886" From: Chris Brandt To: Linus Walleij CC: jacopo , Geert Uytterhoeven , Jacopo Mondi , Geert Uytterhoeven , Laurent Pinchart , Rob Herring , "Mark Rutland" , Russell King , Linux-Renesas , "linux-gpio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc Thread-Topic: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc Thread-Index: AQHSoZUtC1Wf1/FjiU2HPM0/L3VSV6GgrGwAgAHuCgCAB3K5AIAAUYwAgADHCICAAFUYgIAALKaAgAASUYCAAAyIAIAAAqkQgAAPcYCAAAKwUA== Date: Wed, 29 Mar 2017 14:09:33 +0000 Message-ID: References: <1490026491-21742-1-git-send-email-jacopo+renesas@jmondi.org> <1490026491-21742-3-git-send-email-jacopo+renesas@jmondi.org> <20170323160204.GL30223@w540> <20170329120530.GB6247@w540> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=renesas.com; x-originating-ip: [75.60.247.61] x-microsoft-exchange-diagnostics: 1;SG2PR06MB1165;7:hhkMLAOlGmfyzQcYlvKhfgE9h8Q44NRYBLkB4HQvwuyqIQIpbkfvfsmdLr4Hjgxp6F19vHnDJC6Dipm9W8FwZ/Rf9+3EL51z9iUNuWre711iy7OOV+ecNtH0BdtTOREfHrs8kor1TqjmN/bkedNs/Yt2R+FWdGRuRO3gQs9faipJqiW/c3PBmiNBLS+Z1fd7cwXwnxoVkeNq1HyoP7+KDlbWhYaMGnMpaQ8QkTh2AebE9Unxy86da4XocvqgVxwgdfGRTW4+Eg24qT7//1ncXjJO+cdEalCmSnpiTf428IeQCWVxHDJgMOt+oULWOSqdGcwahsUPzuP/JoVBwK+3xg==;20:wPf5Fp4r/SX7fPSclCvMDg9sfK/VSVSoeVkhC+4exkYphLO9LHcpLf0KCCN/5w6o0gqdMY1tHiNt6EkPe4nHa0hrbADcShOJZCvvqQ8SYTQAICUTYcOdXUfWFUwWE2RzmtjTsItGokKTBk05pqp7c5P9c3aYK2illtzvqetw0Yg= x-ms-office365-filtering-correlation-id: f8bcdf34-97db-4277-4eb6-08d476ad3a09 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:SG2PR06MB1165; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(6072148);SRVR:SG2PR06MB1165;BCL:0;PCL:0;RULEID:;SRVR:SG2PR06MB1165; x-forefront-prvs: 0261CCEEDF x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39410400002)(39860400002)(39840400002)(39850400002)(39400400002)(4326008)(8936002)(2906002)(86362001)(38730400002)(6246003)(5660300001)(33656002)(110136004)(81166006)(7416002)(74316002)(305945005)(7736002)(8676002)(229853002)(6916009)(7696004)(189998001)(122556002)(50986999)(53936002)(3660700001)(76176999)(6436002)(25786009)(54906002)(55016002)(102836003)(3846002)(9686003)(77096006)(6116002)(6506006)(54356999)(99286003)(3280700002)(66066001)(93886004)(2900100001)(2950100002);DIR:OUT;SFP:1102;SCL:1;SRVR:SG2PR06MB1165;H:SG2PR06MB1165.apcprd06.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: renesas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 14:09:33.8408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR06MB1165 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v2TE9ld3018716 On Wednesday, March 29, 2017, Linus Walleij: > If you prefer to use preprocessor macros or whatever to make the bitmasks > or how you want to organize the constants in your include files is not my > concern, do whatever you seem fit, just pack it into a 32bit thing somehow > which makes sense from a maintenance point of view. OK, I think everyone agrees that a single 32-bit value is fine because macros will also for good readability and maintenance. > >> Not only because it will save use from having a loong list(*) of > >> macros that has to be kept up to date when/if new RZ hardware will > >> arrive, but also because of readability and simplicity for down-stream > and BSP users. > >> Speaking of which, I would like to know what does Chris think of this. > > > > The list of macros would be very long, especially against the > > different packaging version of the RZ/A1 series. 11 ports, 16-pins for > > each port, 8 different function options for each pin....2 different > package/pin variations. > > > > And at the end of the day....there is no benefit for the user over > > just using a macro. > > I don't know who has this idea that you could not use macros, certainly > not me. Some misunderstanding must be going on. For what I'm concerned you > can write hex numbers in the pinmux = <0x12345678>; > > > The reason for the "FLAGS" is to work around a quirky hardware design > (in my opinion). > > The flags I don't like at all, and think they should be converted to > generic pin config because they have nothing to do with muxing. > > But I will point that out in the specific patch adding them. OK, I think I understand your issue a little better of mixing user-defined config with generic pinmux. >>From our perspective, the FLAGS (BI_DIR, SWIO_IN, and SWIO_OUT ) were not really optional when selecting what you want the pin to do....so we considered it part of the pin-mux. In the hardware manual, there are tables that say that for 'some' certain pins/functions "just setting the pin to a function is not enough...you need to make another register setting (that may or may not make sense), otherwise it's not going to work". So, trying to get the driver to be that smart across all the different pin/package variations seems to be way too ugly (and a maintenance nightmare). Simply putting that in the DT binding was much more cleaner. As for how to pass this HW info into the driver, I'll move over to the other email thread where you started to give some suggestions... Chris