From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751349AbdGPUxM (ORCPT <rfc822;w@1wt.eu>);
        Sun, 16 Jul 2017 16:53:12 -0400
Received: from mail-pg0-f52.google.com ([74.125.83.52]:35228 "EHLO
        mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751290AbdGPUxJ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 16 Jul 2017 16:53:09 -0400
Date: Sun, 16 Jul 2017 13:53:04 -0700
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Richard Purdie <rpurdie@rpsys.net>,
        Jacek Anaszewski <jacek.anaszewski@gmail.com>,
        linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org,
        Fenglin Wu <fenglinw@codeaurora.org>
Subject: Re: [PATCH v2 0/3] Qualcomm Light Pulse Generator
Message-ID: <20170716205304.GU1618@tuxbook>
References: <20170714224520.467-1-bjorn.andersson@linaro.org>
 <20170715091032.GA26602@amd>
 <20170716053429.GR1618@tuxbook>
 <20170706031813.GC12954@xo-6d-61-c0.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170706031813.GC12954@xo-6d-61-c0.localdomain>
User-Agent: Mutt/1.8.3 (2017-05-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed 05 Jul 20:18 PDT 2017, Pavel Machek wrote:

> Hi!
> 
> > > >   DT: leds: Add Qualcomm Light Pulse Generator binding
> > > 
> > > This one should be first.
> > > 
> > 
> > Okay, no problems.
> > 
> > > And I guess I'd prefer the driver to go in first, before the generic
> > > pattern interface.
> > > 
> > 
> > The driver won't compile without the additions to the header file. Would
> > you like the rest of the driver to go in first, then the generic
> > interface and finally the pattern part of the driver?
> > 
> > Large portions of the driver doesn't make sense without the pattern
> > part, so I think I would prefer it to go in as one patch.
> 
> Can we get minimum driver without the pattern parts?
> 

It's possible to do, but I must admit I find it slightly contrived.

The overall design of different parts of the driver does relate to how I
decided to structure and implement the pattern support, so this would
mean that the driver we merge has a conceptual dependency on a
out-of-tree part.


May I ask about the reasoning for your request? Is it just to not leave
the driver hanging while we conclude the discussion on the pattern
interface?

Regards,
Bjorn