Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp4102189pxa; Mon, 10 Aug 2020 00:10:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwAsFiODT6V6hyIem0jpOT/yn77G6mDQn/V0x34amE7zuvgfzoTwyMy3oKe5ObXKfmWMlTi X-Received: by 2002:a17:906:a284:: with SMTP id i4mr20954998ejz.490.1597043415594; Mon, 10 Aug 2020 00:10:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597043415; cv=none; d=google.com; s=arc-20160816; b=j+nbXXjQfy/22evEeU5wO5v4LTTqEczZWuctRbKIGVJ0b0vP7mgRFtBjMFS7kASlyS rwGrstAPwp37VQRVfIt8+lrvbBrwZ6MnJdcNNGKhy+ZkOvWWWykebIeGptuHL2AvK2di mvBpzLFcblMgLeB7Kk1naP+7QLZddSMLWWIWbMX1GPoTakTNuG5Sylt6tkZGxacKSt3m lr5EQJ/kzyl2tw7QLbgP8IdKbqUtEe0lZiFayNC9jkGpESkme72XkxVHlk3PSOxArCMA 3jziASs5O3dI+sg4Dg0hzpKoW75sm2LW3LCAjJYk3DHv2aNiSRDGaFX24k2QPZdoC14K jKww== 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=47Gs9F1F8d09vZAc729o4HZeuw/VZH9JG+bx1Ajssig=; b=rLT2GXGBzUrcTVaOjBzHpTqy5j5WIQ2CmYYz8WruebLAwmjKh670pnUj9JJPbtJcux e/nYHPY5sDYoeMXgbkQiNig4dBNeyh3kT+e3PGOIqa7Ixvsxe+ldaJFwTJAJ/9yPbHEo RiXQVLXANGMNqL3LVhg1ZUJmhPAlEEJwD23yVAjm2IB8uXk0YxoHWfW/LAaAn0IXUiCV teJwMVUbNzR5OtoNl+Xo1ltMso+9ekLIpA+OuWwmcIh+3Z+a4w7MvC29qApGZUkGFuf+ gkHuycOzg4xRwbcQLWBKAECzQ8rh96VSctBLd2KsNm5/dQB1A1gJs+0Jx+DwTIHZimgB tKZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=zcKtsfc8; 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 bq18si5939063ejb.460.2020.08.10.00.09.53; Mon, 10 Aug 2020 00:10:15 -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=zcKtsfc8; 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 S1726109AbgHJHIs (ORCPT + 99 others); Mon, 10 Aug 2020 03:08:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725846AbgHJHIr (ORCPT ); Mon, 10 Aug 2020 03:08:47 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9410C061756 for ; Mon, 10 Aug 2020 00:08:46 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id c80so6709557wme.0 for ; Mon, 10 Aug 2020 00:08:46 -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=47Gs9F1F8d09vZAc729o4HZeuw/VZH9JG+bx1Ajssig=; b=zcKtsfc8/Kleb9yRFPedZRukZN5BBfo337spqmdbUq9GEygQLbhq2BJ4pzaTY0/jUo 91w5WkpjQW5DWV6jefPAnIRJvmGRiwiJcMfFNoOeDvuYJEa4PNoh36UhmSwof/MQAsGR m2xJsQK9B/9RZimDRm5uYXPUQq58wChaHdgj7XJYw6L6cMig5+QJ0+Wgg7VLEwzrU3DU fuRLexZM8n86RWBdX+vcqa9boVH8K2D3ntwLzct/OLmqy7m1Yy5+7NR2s0Qj1AER3+BE HFEDUEbuI0RitlAe4uPcyWkF19VwDo7tD381Uy/kh964R5Znw1VCtPGix9HAT4eUIFKZ kz8A== 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=47Gs9F1F8d09vZAc729o4HZeuw/VZH9JG+bx1Ajssig=; b=rpTL7TcjPtHntqmQUh6EhoWGdIaiHFOOkA31/dZ90Bm7tNMfygvKgp7QJsPGEeFfzm XOUINMCUPW5VK8NR4qyFGeCLiaTq4grL0aS0FR8/VMKyJPYqiJYF30Yq8DEQdj7+SSOZ rsGt81c6fKZg61u73mCPy1mezdaQERVddgSkRngv/wM6N27pczDR7ibkXkwM3/L2CmIW zEIZsf+/YMzqnhVxw17y+nhbsvPfhd4tvSCwunfFy7K7EOl2OVMQRSg8e94zVZRBEbBt eqIQ0UUJIV7tsxYe1cBEgxJjMWtjO9h+jCuUyQRgOwRzkym32Whg38eud1n3KD4Djj3q L4gg== X-Gm-Message-State: AOAM531v0jJgGe7jloAR2xnpriX+UbLU3SiBZ3v9XgBnWBINpzwSl4xk a7lb5OBurBCRF3nYCsNr1HNybA== X-Received: by 2002:a7b:c4d5:: with SMTP id g21mr25757680wmk.185.1597043325510; Mon, 10 Aug 2020 00:08:45 -0700 (PDT) Received: from dell ([2.27.167.73]) by smtp.gmail.com with ESMTPSA id w10sm20031948wmk.0.2020.08.10.00.08.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2020 00:08:44 -0700 (PDT) Date: Mon, 10 Aug 2020 08:08:43 +0100 From: Lee Jones To: Gene Chen Cc: Mark Brown , Matthias Brugger , rafael@kernel.org, gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Gene Chen , benjamin.chao@mediatek.com, shufan_lee@richtek.com, cy_huang@richtek.com Subject: Re: [PATCH 9/9] mfd: mt6360: Merge different sub-devices I2C read/write Message-ID: <20200810070843.GA4411@dell> References: <1596558782-3415-1-git-send-email-gene.chen.richtek@gmail.com> <1596558782-3415-11-git-send-email-gene.chen.richtek@gmail.com> <20200805161021.GK5556@sirena.org.uk> <20200806121332.GB6442@sirena.org.uk> 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 Fri, 07 Aug 2020, Gene Chen wrote: > Mark Brown 於 2020年8月6日 週四 下午8:13寫道: > > > > On Thu, Aug 06, 2020 at 11:30:56AM +0800, Gene Chen wrote: > > > Mark Brown 於 2020年8月6日 週四 上午12:10寫道: > > > > > > It's not clear why this isn't just done in the device regmap, there's > > > > exactly one user? > > > > > because I use one regmap to access 4 I2C devices, > > > > There appears to be only one device here? > > > > > I need change the regmap_bus struct to fit I2C read/write with CRC bit > > > Therefore, MFD reviewer suggests I can move the regmap api to regmap > > > folder such as regmap-ac97.c > > > > AC'97 is an industry standard bus used by a range of devices in > > different subsystems. You can already have custom operations for a > > device just in a regular regmap using the reg_read() and reg_write() > > operations which are there so devices that individual device support > > doesn't need to be added to the regmap core. > > > > I need use regmap_raw_read to access MT6360 TYPEC part, so we need > implement bus read control > > > You really also need to write a much clearer changelog, I would be hard > > pressed to tell from the changelog that this was moving things to the > > regmap core rather than shuffling regmaps within the device. > > MT6360 has 4 I2C worker devices > First, I increase reg_bits from 8 to 16 bits. > Higher 8 bits, bank, indicated which worker device I want access > Then, if worker devices is PMIC or LDO part, I need calculate or check > CRC8 bits when we write or read data. > CRC8 bits is calculated by 3 parts. > 1'st part include 1 byte is worker address and R/W in LSB. > 2'nd part include 1 byte is register address > 3'nd part include written data or read data from MT6360 > I also need 1 dummy byte when write data > > @Lee Jones, > I found out drivers/iio/chemical/bme680_spi.c implement their own > regmap_bus too. > Can I move regmap control back to mt6360-core.c? Yes, if that is the 'done thing'. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog