Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <650012a3-b455-8be5-fd6d-d0775e718e6a@linux.intel.com>
Date:   Thu, 18 May 2023 10:16:16 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.11.0
Subject: Re: [PATCH 06/10] mfd: cs42l43: Add support for cs42l43 core driver
Content-Language: en-US
To:     Charles Keepax <ckeepax@opensource.cirrus.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     broonie@kernel.org, lee@kernel.org, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
        tglx@linutronix.de, maz@kernel.org, linus.walleij@linaro.org,
        vkoul@kernel.org, lgirdwood@gmail.com,
        yung-chuan.liao@linux.intel.com, sanyog.r.kale@intel.com,
        alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
        devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
        linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230512122838.243002-1-ckeepax@opensource.cirrus.com>
 <20230512122838.243002-7-ckeepax@opensource.cirrus.com>
 <73438e58-bd96-818d-1f43-5681b0d1a1de@linaro.org>
 <20230518102442.GZ68926@ediswmail.ad.cirrus.com>
From:   Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In-Reply-To: <20230518102442.GZ68926@ediswmail.ad.cirrus.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


>>> +	ret = regmap_register_patch(cs42l43->regmap, cs42l43_reva_patch,
>>> +				    ARRAY_SIZE(cs42l43_reva_patch));
>>> +	if (ret) {
>>> +		dev_err(cs42l43->dev, "Failed to apply register patch: %d\n", ret);
>>> +		goto err;
>>> +	}
>>> +
>>> +	pm_runtime_mark_last_busy(cs42l43->dev);
>>> +	pm_runtime_put_autosuspend(cs42l43->dev);
>>> +
>>> +	ret = devm_mfd_add_devices(cs42l43->dev, PLATFORM_DEVID_NONE,
>>> +				   cs42l43_devs, ARRAY_SIZE(cs42l43_devs),
>>
>> I don't why adding devices is not in probe. They use the same regmap
>> right? So there will be no problem in probing them from MFD probe.
> 
> Well except SoundWire is a bit of a special boy, the hardware is
> not necessarily available in probe, the hardware is only available
> at some point later when the device attaches. Doing it this way all
> of the attaching (and various detach/attach cycles the device needs
> during configuration) are over by the time the child drivers bind, so
> they don't all need special code to handle that.

if the devices are added in the probe, then the regmap needs to be moved
to cache-only and another special API would be needed to tell the MFD
framework to turn the regmap cache-only off.

But if it's the same regmap, the regmap cache is handled in the
SoundWire update_status callback so maybe  Krzysztof's proposal does work?