Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3851890ybz; Tue, 28 Apr 2020 01:20:46 -0700 (PDT) X-Google-Smtp-Source: APiQypLRCebXspy/2kaKUajchNToxDDdwSixlE71LSvyTY7X6JJC02c4viQBTjNsBRZwc16nVL2s X-Received: by 2002:a05:6402:1b08:: with SMTP id by8mr21468425edb.286.1588062046831; Tue, 28 Apr 2020 01:20:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588062046; cv=none; d=google.com; s=arc-20160816; b=vywB6ghquQYBRsJYCJc4LIiVjBGt67nxVAq8Djztj/PxBUP5pS3rhRjM/Kiw/oFeza kfQRFCpceczDhiS/wRBkIO1mRVpqOQf5gFWqdoaMYZz/0WDxH7e7mJRGXu3V9LBHMbt9 1UHjBgXTRjzoy0mdyxq/jSjDqdNBxEkWsz/W9OWNsB/4sr3iEzSkVY9K7qFQoyMLWdvp mpffv3JWOo7LTn83BJqWjX/INeI2/WoLyYdObmg2j/rX2b98HAD1TOh6eyMfQn9+oic/ QnDkzOfZjWn7MrjHQMkqXl7f8qtGtEfGEE1UktOlg/CjN96IwWyDrb8LWTMRpN1xvNAV n3MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=OURtSv+36+oE/sqTvfCFcfDI8FbFV0v5BfUs3TstP2w=; b=nIXX/ckIthl47hNdHD0vzHsShY3O1Djsh8xkwmz4pjioj+1ZmBgYI+CvDgXqVzf+N7 DpH87HeGAUr980IJqcwzpOUsyQH+6BxeECS2boDEABOYPKUSZJy/bis5+5gGqJ0gktA6 Nw3yyj8PWJyIJWDF5i//2POPpvJ7uIXIuVX4Ym+JEqksXTIpgHq7MNH+1/ZaEe8tDM1k BY08TFcxyoVr9Q53Q+GMC6tUQ3DL2Z87y3GvLgQttu9V1ErOwSAlPbtj61sSjrRKHO0h jLkF+c90c1NtEVwo7LzmqF8d1ADWDwt+U/sWqK+IHan+Ql7tgvrd+gjhKm8euPUwUyYQ jE+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ad+roKvC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m9si1515141eda.147.2020.04.28.01.20.22; Tue, 28 Apr 2020 01:20:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ad+roKvC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726636AbgD1ITH (ORCPT + 99 others); Tue, 28 Apr 2020 04:19:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726377AbgD1ITG (ORCPT ); Tue, 28 Apr 2020 04:19:06 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99DC9C03C1A9 for ; Tue, 28 Apr 2020 01:19:06 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id s10so23570123wrr.0 for ; Tue, 28 Apr 2020 01:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=OURtSv+36+oE/sqTvfCFcfDI8FbFV0v5BfUs3TstP2w=; b=ad+roKvC5V8gYPY6wjww2oXYWV0rJ1z7ziGfl3GObc7dSPCs6URF5nw+O8lGQ/q7V0 lhoRdB+RkFf4o0ELPOxVDrWDIqY3siAbUtnsluyjycLeZXxQo+RM7BrzsmPg7l2tG6Xd iprqLr1acQkJVXohTBskh+XV0ma9j659hsKnnl0stRnvKXKKa0T4UEN8T9NfZURKNc8E gC8Ixeuj2Qc8OBsvOJ56dl8+rNfFaTtqcWvhd5EDR2C1kmD3sV3J3IMw7NpA+9R7NW4P A7od6NYP1u04jqdcVjv+z+F3kZLQN8fSHncovPF7Kr/JwEnK/jo0hW3ikYjuMkwD97Yg klLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=OURtSv+36+oE/sqTvfCFcfDI8FbFV0v5BfUs3TstP2w=; b=OMUHXpCHRRecaHAydymU3uuBI6qEaAzYx0shD79rInkTUvl5uOCKaCMDj2o4WPjnxp egRTuX5M4yuMJF39AWb6tpEQztjyUt4TckmGcUg29qd9/SJy1Ldy4VXJTa/HoTW1J1iI wQMwX09u6VkhpZgw36iP3SCKCACHZrA1KezNgmwmyzQm01DMkILZV7CkOUZ6oc5/yz/2 RbbD4K4iRgdygV12q9eOdRKPIA4CSGPZ0unbqaVymhqXBz09O0jJZrh7U0qcFDYKCq8Q XAZNtuuhkLtOQYkRr0DdrTaHoOS+F0aOuksRoAoj2j/bklmZdsktUaEgKMIBVDquzarH qtyw== X-Gm-Message-State: AGi0PubReeIipv2gLiQhg6H4oL6iQ5ZD7GtIdHZoj5LePzkNuPwCrkGA eLN0p3py9oIlEghk/BVpa4B2MA== X-Received: by 2002:adf:e986:: with SMTP id h6mr31497011wrm.256.1588061945215; Tue, 28 Apr 2020 01:19:05 -0700 (PDT) Received: from dell ([2.31.163.63]) by smtp.gmail.com with ESMTPSA id c20sm2395678wmd.36.2020.04.28.01.19.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 01:19:04 -0700 (PDT) Date: Tue, 28 Apr 2020 09:19:02 +0100 From: Lee Jones To: Baolin Wang Cc: Arnd Bergmann , Mark Brown , Orson Zhai , Chunyan Zhang , LKML Subject: Re: [PATCH v3] mfd: syscon: Add Spreadtrum physical regmap bus support Message-ID: <20200428081902.GK3559@dell> References: <20200427090518.GG3559@dell> <20200428071447.GJ3559@dell> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Apr 2020, Baolin Wang wrote: > On Tue, Apr 28, 2020 at 3:14 PM Lee Jones wrote: > > > > On Tue, 28 Apr 2020, Baolin Wang wrote: > > > > > On Mon, Apr 27, 2020 at 5:05 PM Lee Jones wrote: > > > > > > > > On Mon, 27 Apr 2020, Baolin Wang wrote: > > > > > > > > > Hi Arnd and Lee, > > > > > > > > > > On Tue, Apr 21, 2020 at 10:13 PM Baolin Wang wrote: > > > > > > > > > > > > Some platforms such as Spreadtrum platform, define a special method to > > > > > > update bits of the registers instead of read-modify-write, which means > > > > > > we should use a physical regmap bus to define the reg_update_bits() > > > > > > operation instead of the MMIO regmap bus. Thus we can register a new > > > > > > physical regmap bus into syscon core to support this. > > > > > > > > > > > > Signed-off-by: Baolin Wang > > > > > > > > > > Do you have any comments for this patch? Thanks. > > > > > > > > Yes. I'm not accepting it, sorry. > > > > > > > > I'd rather you duplicate the things you need from of_syscon_register() > > > > in your own driver than taint this one. > > > > > > Thanks for your comments and I can understand your concern. But we > > > still want to use the standard syscon APIs in syscon.c, which means we > > > still need insert an callback or registration or other similar methods > > > to support vendor specific regmap bus. Otherwise we should invent some > > > similar syscon APIs in our vendor syscon driver, like > > > sprd_syscon_regmap_lookup_by_phandle/sprd_syscon_regmap_lookup_by_compatible. > > > > So long as the generic driver stays generic. Providing a registration > > function sounds cleaner than tainting the code with vendor specifics. > > So seems my V1 patch set [1] was on the direction as you suggested, > but Arnd did not like that. > > [1] > https://lore.kernel.org/patchwork/patch/1226161/ > https://lore.kernel.org/patchwork/patch/1226162/ I don't often disagree with Arnd, but in this instance I think a registration function which allows vendor spin-offs to use the generic API is better than tainting the generic driver by adding vendor specific #ifery/code to it. Your original idea seems more palatable to me. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog