From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DC5AECE560 for ; Mon, 17 Sep 2018 19:23:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4EA38214DA for ; Mon, 17 Sep 2018 19:23:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="A8xAjtZ5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EA38214DA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728419AbeIRAvl (ORCPT ); Mon, 17 Sep 2018 20:51:41 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:53132 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727176AbeIRAvl (ORCPT ); Mon, 17 Sep 2018 20:51:41 -0400 Received: by mail-wm1-f66.google.com with SMTP id y139-v6so10849460wmc.2; Mon, 17 Sep 2018 12:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6GBjaSZ4kCqwCbgJ3waYfPyNwAUNz+UfRKd1/WIBfGY=; b=A8xAjtZ5D3DJVjPwrgY9Y4Ctux0GfOW5VY1YHO4UV6mDzucXM9M6t3u5pjl5DSq+rc 8x+HgnFqhFFH+aMca8lLK+iTsIE1G49EN/PMUslq1+OE6QNlHxu7sUqq3SFeB/GOPUxr xCEs7HoEDBBNsxfn5qnKgxrm88WPWbyyVfAvfjhal3qQlOuxz7i35vqgTz9htH16hFAe mkFqWq7GIqZuR44GUUEwQp4hEviyyCLD47cdCPTdda72uGiso2tLxGA8V8LTdff7vCF6 AQYzI6pyESVo35rMBw47ejd7xZI4o+6KAqfEB758nHfLsjGcbM0GIjlNZQsrVdyEtm7C ynFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6GBjaSZ4kCqwCbgJ3waYfPyNwAUNz+UfRKd1/WIBfGY=; b=oPmztxnpJiCZvgG/GXlqwdjCxvqM2ADOfDS/ibrjYmefk3lexjYGRZ/hM725Mum8au g/K4Fl1HQf0uB2iHITkehsjrIx7IqtB6sqO0XvzBUNQwPFbEipNETTbN0ICCl5tmgwai BsxGkNNRhld6geMtstCDOHtiE4V2GolpQ/xoyFQyEi8t0hRSWCCtxmPFQNGcqeUgtuXO Q00rlPm+VhUfkEUcKqNRInv5WORo3aP1PY1h935+gQjRIsrgxLJkC93DZi9QszEtFAp1 j9X0jgIsiJI58W4i4HJgTLzWAvNMZzpNNTRN7eLnQ84+JWlM1w5IHAYs6UX15KAP7Src 8dgw== X-Gm-Message-State: APzg51BETIPIu2fR9jvkmU2mm3p9gKzKyF3MxtRJqwXzUIAbu1dQ38MQ lQLVJCpz4vPODHI9DeK7IhLJaQqI X-Google-Smtp-Source: ANB0VdZlla7a7027cbwh8AY5A5qQpPYoOeuLpMqcHBLwpkGmrTL7n05/F1zgRNPs7RLSt87Hl2e/yw== X-Received: by 2002:a1c:cf8a:: with SMTP id f132-v6mr12555276wmg.0.1537212176807; Mon, 17 Sep 2018 12:22:56 -0700 (PDT) Received: from [192.168.1.18] (ckd81.neoplus.adsl.tpnet.pl. [83.31.79.81]) by smtp.gmail.com with ESMTPSA id s2-v6sm19789941wrn.83.2018.09.17.12.22.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 12:22:56 -0700 (PDT) Subject: Re: [PATCH v7 1/6] dt-bindings: ti-lmu: Remove LM3697 To: Dan Murphy , Pavel Machek Cc: robh+dt@kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, lee.jones@linaro.org, linux-omap@vger.kernel.org, linux-leds@vger.kernel.org References: <20180911170825.17789-1-dmurphy@ti.com> <20180911170825.17789-2-dmurphy@ti.com> <20180911200530.GA28290@amd> <85ab3bf4-21d4-dda9-a7c8-5ed68f15c611@ti.com> <20180912214938.GA30654@amd> <7950fa32-c8f9-52bb-06b0-0c1cc93b6bc9@ti.com> <20180914081822.GA21830@amd> <9c14ee7c-f172-bb0c-d9a8-8aeee408f716@gmail.com> <20180914214220.GA2081@amd> <5a249ae3-e3f7-8eff-4022-ed982e364326@ti.com> From: Jacek Anaszewski Message-ID: <7a6e83ad-2bc9-c776-21bf-e1d51413b0af@gmail.com> Date: Mon, 17 Sep 2018 21:22:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5a249ae3-e3f7-8eff-4022-ed982e364326@ti.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dan, On 09/17/2018 05:24 PM, Dan Murphy wrote: > Jacek > > On 09/15/2018 03:00 PM, Jacek Anaszewski wrote: >> Hi Pavel. >> >> On 09/14/2018 11:42 PM, Pavel Machek wrote: >>> Hi! >>> >>>>> You may want to learn more about device tree and/or talk to the device >>>>> tree maintainers. This is an old article. https://lwn.net/Articles/561462/ >>>> >>>> The article title is "Device trees as ABI". A device tree is defined >>>> in the "*.dts" file that is then compiled to a dtb blob, which >>>> constitutes the ABI. And this ABI should be kept backwards compatible. >>>> >>>> What is discussed here is a documentation of bindings, i.e. according >>>> to ePAPR: "requirements for how specific types and classes of devices >>>> are represented in the device tree". >>>> >>>> >From the bindings documented in the >>>> Documentation/devicetree/bindings/mfd/ti-lmu.txt only >>>> ti,lm3532-backlight is used in the mainline dts file >>>> (arch/arm/boot/dts/omap4-droid4-xt894.dts). >>>> >>>> Having the above it seems that there is no risk of breaking any >>>> users. >>> >>> DTBs and bindings are supposed to be portable between operating >>> systems. You are right there are no _mainline_ _Linux_ users. >> >> No mainline users means no users we should care of. >> Other people also don't care - see patch [0]. >> >>>>> NAK on this patch. I see that this binding has problems, but >>>>> introducing different binding for subset of devices is _not_ a fix. >>>>> >>>>>>> What about the multi function devices? They should have same binding. >>>>>> >>>>>> The MFD devices defined are not in contention here only the SFD. >>>>> >>>>> I'd like to see common solutions for SFD and MFD, as the hardware is >>>>> similar, and that includes the code. Having code that is easier to >>>>> maintain is important, and having many drivers are harder to maintain >>>>> than one driver. >>>>> >>>>> Milo's code looks better than yours in that regard. I disagree about >>>>> Milo's code being "nightmare" to modify, and care about "easy to >>>>> maintain" more than "binary size". >>>> >>>> Easy to maintain will be a dedicated LED class driver. >>> >>> You mean, 3 dedicated LED class drivers and 3 MFD drivers with LED >>> parts? We'll need complex driver anyway, and I'd really like to have >>> just one. >> >> In the LED subsystem we can wrap common functionalities >> into a library object. MFD driver will be able to reuse it then. > > I am currently working on that code now. I expect a RFC on this this week. Will it affect the shape of the driver for lm3697 as of v7 [0]? Or the patch set [0] state should be deemed "awaiting merge"? [0] https://lkml.org/lkml/2018/9/11/760 -- Best regards, Jacek Anaszewski