From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751043AbdAaVoU (ORCPT ); Tue, 31 Jan 2017 16:44:20 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:32895 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750852AbdAaVoR (ORCPT ); Tue, 31 Jan 2017 16:44:17 -0500 To: bjorn.andersson@linaro.org Cc: Mark Brown , Linux Kernel Mailing List From: Heiner Kallweit Subject: Optional regulators in bulk operations - reverted patch Message-ID: <8f3551cb-a499-5c9d-1c11-4ce66b093c44@gmail.com> Date: Tue, 31 Jan 2017 22:43:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn, I just came across a use case where I wanted to deal with optional regulators in bulk operations. I was about to submit a related patch when I saw that you submitted basically the same in 3ff3f518a135 "regulator: Make bulk API support optional supplies" and reverted it later stating that you misunderstood the API. How does this extension break the API? To me it sounds like a neat feature. The only thing I can think of if that we have to assume that struct regulator_bulk_data is zero-initialized to ensure backwards-compatibility (use "normal" get as default). Rgds, Heiner