From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752098AbdAaM7p (ORCPT ); Tue, 31 Jan 2017 07:59:45 -0500 Received: from mail-it0-f41.google.com ([209.85.214.41]:34282 "EHLO mail-it0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751978AbdAaM7k (ORCPT ); Tue, 31 Jan 2017 07:59:40 -0500 MIME-Version: 1.0 In-Reply-To: <08e9505d2d366557950f8e6a4e81f57a@mail.crapouillou.net> References: <27071da2f01d48141e8ac3dfaa13255d@mail.crapouillou.net> <20170122144947.16158-1-paul@crapouillou.net> <20170122144947.16158-2-paul@crapouillou.net> <08e9505d2d366557950f8e6a4e81f57a@mail.crapouillou.net> From: Linus Walleij Date: Tue, 31 Jan 2017 13:59:37 +0100 Message-ID: Subject: Re: [PATCH v2 01/14] Documentation: dt/bindings: Document pinctrl-ingenic To: Paul Cercueil Cc: Rob Herring , Mark Rutland , Ralf Baechle , Ulf Hansson , Boris Brezillon , Thierry Reding , Bartlomiej Zolnierkiewicz , Maarten ter Huurne , Lars-Peter Clausen , Paul Burton , "linux-gpio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linux MIPS , "linux-mmc@vger.kernel.org" , "linux-mtd@lists.infradead.org" , "linux-pwm@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , James Hogan 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, Jan 27, 2017 at 4:27 PM, Paul Cercueil wrote: > [Me]: >> In the former case, if this pertains to the *inside* of the SoC: >> is it just different between jz4740 and jz4780? >> In that case, just code this into the driver as .data to the .compatible >> in the DT match. No special DT properties needed. > > Well, I've been taught that devicetree is for describing the hardware, and > the driver code is for functionality. So that's why I put it in devicetree. This is a gray area. But as GPIO maintainer I'm not happy about encoding information about the hardware, that can be deducted from the compatible-string, into the devicetree. I prefer to encode per-compatible hardware information tables into the driver, as structs, and pick the right table based on the compatible string as .data in the of match entry. It's simple to retrieve into the driver using of_device_get_match_data() these days. > That's also the reason why I put the list of functions and groups in > devicetree and not in the driver code. I'm not super-happy about that either, and it's not the way I would have done it but the argument has been made that it is a lot of opaque data and people prefer to maintain it in the device tree. I accept it for functions and groups, but I don't like it. I will not fold to any consistency arguments of the type "now you allowed this one thing, so you must allow this other thing so you are consistent", just no. I didn't like it the first time, so I'm not liking it anymore the second time. I guess if the DT people tell me it has to be done this way I would accept it. After a lot of discussion. But noone has. Please make it a table and put it in the driver instead. Yours, Linus Walleij