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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH 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 8D32BC282CE for ; Tue, 4 Jun 2019 15:14:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5348D2075B for ; Tue, 4 Jun 2019 15:14:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="fIzt6mvr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728007AbfFDPOv (ORCPT ); Tue, 4 Jun 2019 11:14:51 -0400 Received: from lelv0142.ext.ti.com ([198.47.23.249]:55804 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727976AbfFDPOu (ORCPT ); Tue, 4 Jun 2019 11:14:50 -0400 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id x54FEibt022139; Tue, 4 Jun 2019 10:14:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1559661284; bh=Sl5OBcsT70V82QK3ubUuQgvQHwkd1HO9ZqCFNycFHNU=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=fIzt6mvrmu7C92OZ5lEXYzJwHk5/WxmY/o+l+4iuXfCKHhcae7HmJ5TI4oHvMR8J4 c5jTn+giscmdXCIOZt1af8SZG4Fge2VMN7evJIA1f4jxnYErj/ukfI/ravAlyvDsqq 8EDdTCqPcvM9TkDq1odziB+H6x5x9NUwydc+mJto= Received: from DLEE102.ent.ti.com (dlee102.ent.ti.com [157.170.170.32]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x54FEiMT013864 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 4 Jun 2019 10:14:44 -0500 Received: from DLEE114.ent.ti.com (157.170.170.25) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 4 Jun 2019 10:14:43 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Tue, 4 Jun 2019 10:14:43 -0500 Received: from [10.250.65.13] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id x54FEhtF014871; Tue, 4 Jun 2019 10:14:43 -0500 Subject: Re: [RESEND PATCH v4 1/6] regulator: lm363x: Make the gpio register enable flexible To: Mark Brown CC: , , , , , References: <20190522192733.13422-1-dmurphy@ti.com> <20190522192733.13422-2-dmurphy@ti.com> <20190523130311.GA17245@sirena.org.uk> <20190526124838.GH2456@sirena.org.uk> <2398099b-16e6-f155-5852-45ba3dbc21ef@ti.com> <20190529151000.GP2456@sirena.org.uk> <20190530152643.GS2456@sirena.org.uk> From: Dan Murphy Message-ID: Date: Tue, 4 Jun 2019 10:14:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190530152643.GS2456@sirena.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mark On 5/30/19 10:26 AM, Mark Brown wrote: > > That code is rather far away from the code you're changing and it's > really not clear that this will do the right thing for new devices, it > already appears that we're handling two devices without obvious code for > that (the regulator IDs get reused AFAICT). If there were a switch > statement right there it'd be clearer. > > Part of this is a reviewability thing - I initially stopped on the patch > because it looked like it was using the enable field for something other > than the intended purpose and now there's all this chasing around to see > if the code is OK. I am going to introduce this update in patch 4 of this series when the LM36274 is introduced to the regulator driver. It makes more sense to add it there as in patch 1 there is not really a need to extend the value or mask as it only supports the LM3632 device.  It makes sense to add the condition when adding another device to support Thoughts? Dan