From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81D0B2FD7A7 for ; Mon, 13 Oct 2025 09:27:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760347659; cv=none; b=Is8nXuklf+ox2pvl40LtTWD0K4/4ScANQVSq5/QueWBbRVDBrkHhgl+kGOaqeanCRl9WFfKe5jfburbuxS1kLrtLyB0NnmTKAmEWzvprGUpomzXAEFCmm61XTBGhqQq+XbdxXWpQRz1CcZY8ccRRnZ47HCC2f6KeSKLtY4uJATI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760347659; c=relaxed/simple; bh=Vnu9qF1W+mtePyJT46244Xk0nYQav+1PFrImO+uiBpI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eMdFf44JBlEVQ+QlwFVwYpX9vrOt1B97FSh2w4dn6P/ZREBAD9vIp5DJnyfUVpbO9mKQ0XfT1fvhK4L2VFl/T8owZWoknU5R42lZHmItSUQRW7yLES9jp8bs9q9ZJ0s1ixFCwwQGX3T+GMo3e3WIErwzkM9CbgZgZanvFYfH4TA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jWZ/5+Sl; arc=none smtp.client-ip=209.85.167.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jWZ/5+Sl" Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-57edfeaa05aso4582881e87.0 for ; Mon, 13 Oct 2025 02:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760347656; x=1760952456; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=TSTsG2geMiXZZ54sKPHqUYbwVwZADjPORMJscfDPZgg=; b=jWZ/5+SljpEk8QizK6qM0TG2OT6docRYqUXFzt+x95jYvOnNrmmT7zioksz6h8wUEG QJWTj/SExgnOGFXuyQiBZXsR73urnrb84UOTMd8t/GNhcUsfmUSeGGGkXQIs0X+o6CAh NECFMEmve/PvMzAc5HpXqlitNn9BEbaMbDPb9rxE5SA5aAnCmkb6I+Lc04sPG7dJlz30 o6M5AygU50aC/Yr9rbBZnyfGujoZVyuF+57VMEPM687PTKWTz9pZLPVNmpLdsD4pd9e+ J9QFDE2plJzI5eOg9tU3z9QkKDyaI+pcJEzRADffESa6n9ENzDtNN0q/5wo1Q571lvnp pWnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760347656; x=1760952456; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TSTsG2geMiXZZ54sKPHqUYbwVwZADjPORMJscfDPZgg=; b=Hupfva7RVNulNEcTJFCKnOMiQhn5+J7XGA59BjTxmFDtloBPvg9YLFeQU/gKaH4837 Rz50t++vQG7w+b9QHFirdatYDTMM1QPQ7/sJWg39slzVD5/toC3KWhA2+Y5xMy0JLoUe GbxXyu3VtRhjYjBk0MgCpJNCCZya4Q7DXhaJ2lgTzFMKHPi01BvRcxg5O75GlOMN1f2l KkbtLrHMuqUOVvV/VjW0t1wNavxdjQzKRVR4l6ytGy5Fz3o4SSLijI2yGrglyP/iwlmw GQtudYok7sNRMLXJ9z8WOGqAHJwlsNDO2dNBzxGncaYPmuJjQFeePsN1xt8JJBZRf0kN xhcg== X-Forwarded-Encrypted: i=1; AJvYcCX1FYLabshRsFJUAiCDFvUm17TAaDtoi6Mej9SmhkgnegBTyUcPwhnOn/U/Ww4u+lQbNdNymOYBvnAp@vger.kernel.org X-Gm-Message-State: AOJu0YxZPcXopW+z5m+y7nM7Zw+PY3zNETfTC4sMInGGRAOevjRLV2SW FzfqoJVImv4JSCETXsjeUtTAivdCynRlAT0bKzd42IvGm8qcv1g41wzo X-Gm-Gg: ASbGnctCk+iO4INnmGOZ/Mg3JhjUmR3xmtKNPndId/LTr8NzIkPbBiWw9ZBDgnf7ifN 1iJLyo5Qy8hDxkLhqs++FO/PVzNYS3SBL8BTfIhnMPEUP9O4ohIinhyjcOFbtyzW6aKMNj8tSkK PBUWjnXZw5U/n65Rsly+5A1+rwvYhrPo7BOSHsAgQTswYPGuQf8riQCACsiGqCei4CiA86TXDDb 5MBNBl2UoH0VuwPwRv9fSp1rstNq+rL8QfredClAWz+ZishgamiUvvBBl+zF/4E62zJwWB8TEtG 7gHGberS9JQF2h1SSUW7IujZarjwvM9nJgjjinRDTVjdUKIFcHBCRCBeYzGiaLYw5Sn2Sl/CQwA xuwIa+n6Lb9GY7d0iWfPEgqTc/BhG2VGyMdHuz48UADzz1y8BBkxjKa7eYqLG29+AGbwBCv/0UR MmD3VdYW/JISkOLfohjbrl8+Mal23VL+Wa5A== X-Google-Smtp-Source: AGHT+IEqb5UWThw0zJL0ngTJbT7pv4o6411sYhb14KLtxUGEsvK5SpnsWbVBznfiz/L/V7BnIrIUsw== X-Received: by 2002:a05:6512:3b9a:b0:57f:6da2:6a1a with SMTP id 2adb3069b0e04-5906db01c1emr5500852e87.48.1760347655259; Mon, 13 Oct 2025 02:27:35 -0700 (PDT) Received: from ?IPV6:2a10:a5c0:800d:dd00:8fdf:935a:2c85:d703? ([2a10:a5c0:800d:dd00:8fdf:935a:2c85:d703]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-59088577c1bsm3920293e87.106.2025.10.13.02.27.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Oct 2025 02:27:34 -0700 (PDT) Message-ID: Date: Mon, 13 Oct 2025 12:27:33 +0300 Precedence: bulk X-Mailing-List: linux-gpio@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 06/13] mfd: bd71828: Support ROHM BD72720 To: Andreas Kemnade Cc: Lee Jones , Matti Vaittinen , Pavel Machek , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sebastian Reichel , Liam Girdwood , Mark Brown , Linus Walleij , Bartosz Golaszewski , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-gpio@vger.kernel.org References: <93142a80d90a0ac80b27090d0c83914675aad94d.1759824376.git.mazziesaccount@gmail.com> <20251009161847.GE2890766@google.com> <8ea507eb-f78c-4a16-882b-112e277fa1b6@gmail.com> <20251010150317.07bfdbe8@kemnade.info> Content-Language: en-US, en-AU, en-GB, en-BW From: Matti Vaittinen In-Reply-To: <20251010150317.07bfdbe8@kemnade.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andreas! First of all, thanks for taking a look at this! On 10/10/2025 16:03, Andreas Kemnade wrote: > On Fri, 10 Oct 2025 15:09:07 +0300 > Matti Vaittinen wrote: > >>>> +static int bd72720_get_secondary_regmap(struct i2c_client *i2c, >>> >>> Does this 'secondary' have a specific purpose or a better name? >> >> I am not entirely sure. When I asked this from the designers they just >> told me that they needed more than 255 registers so they added another >> slave address... (I'm not sure what would have been wrong with using a >> page register). So, I assume they just placed stuff that didn't fit in >> first 255 register there. But yeah, it looks like most of the registers >> there are related to the charger. So, perhaps it isn't completely >> misleading to use "charger regmap"? The data-sheet seems to be just >> using "Register map 1" and "Register map 2" in the tables listing these >> registers. I kind of like using something which maps easily to the >> data-sheet, but I really have no strong opinion on this. > > just another idea: What about one regmap with custom functions covering > both these adresses? Maybe that could even be added to the regmap > functionality, maybe with a 0x100 offset for the second range. > That way the rest of the code only needs to real with one regmap > and properly defined registers. Interesting idea. I suppose you mean something like implementing custom remap_read() and regmap_write() - which would practically select the I2C adapter to use based on the register address - and then doing same thing as the regmap_i2c_smbus_i2c_write() / regmap_i2c_smbus_i2c_read() do? I suppose this would mean duplicating the functionality provided by the regmap_i2c_smbus_i2c_write() and the regmap_i2c_smbus_i2c_read(), which are static. It'd also mean we'll lose the 1 to 1 mapping between the register addresses in driver and addresses in the data-sheet. I agree this wouldn't be such a huge thing if we used offset like 0x100 though. I am still leaning towards using two different regmaps though, as it seems like a more 'standard' solution. I assume people are more familiar with providing platform data to "MFD sub drivers" than custom regmaps accessing different I2C slave addresses. But yeah, thanks for this suggestion! It opened up some completely new paths in my brains! :) Yours, -- Matti