Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933360AbdGTGuY (ORCPT ); Thu, 20 Jul 2017 02:50:24 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:35270 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751810AbdGTGuW (ORCPT ); Thu, 20 Jul 2017 02:50:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Jul 2017 12:20:21 +0530 From: kgunda@codeaurora.org To: Stephen Boyd Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-msm-owner@vger.kernel.org Subject: Re: [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes In-Reply-To: <20170718221709.GA18179@codeaurora.org> References: <1500373265-12875-1-git-send-email-kgunda@codeaurora.org> <20170718221709.GA18179@codeaurora.org> Message-ID: <7dd982648a06c8ee72c73ae6ef51e4af@codeaurora.org> User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1624 Lines: 45 On 2017-07-19 03:47, Stephen Boyd wrote: > On 07/18, Kiran Gunda wrote: >> v4: >> * spmi: pmic-arb: add support for HW version 5 >> Clean-up as per Stephen's comments >> >> v3: >> * spmi: pmic-arb: add support for HW version 5 >> Modified #define INVALID (-1) to >> #define INVALID_EE 0xFF. >> >> v2: >> * spmi: pmic-arb: return __iomem pointer instead of offset >> Added Stephen's reviewed-by tag. >> >> * spmi: pmic-arb: fix a possible null pointer dereference >> Added Stephen's reviewed-by tag. >> >> * spmi: pmic-arb: add support for HW version 5 >> Modified the pmic_arb_offset_v5 function to return the offset >> instead >> of passed by a pointer. >> >> * spmi: pmic-arb: Remove checking opc value not less than 0 >> Added Stephen's reviewed-by tag. >> Added my sign-off tag. >> >> v1: >> >> This patch series add the support for pmic arbiter hardware v5 along >> with >> the few bug fixes and code cleanup. >> >> This patch series is dependent on the below patches and can be merged >> cleanly only after picking the below patches in to the tree. > > Can you combine the two series? It's really confusing why there > are two patch series from you for the same driver. Presumably one > of the series needs to be applied before the other, so putting > them into one series makes that clear what the order is. I had two series just to give the information about the fix-up patches for the previously merged patches and other new patches. Anyways, having a single series will be easy and clear to everyone. Will combine them.