linux-kernel - Re: [PATCH 06/10] mfd: cs42l43: Add support for cs42l43 core driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3fd73def-4765-d43c-4c2c-e0fb0e2e0516@linux.intel.com>
Date:   Thu, 18 May 2023 11:47:12 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Richard Fitzgerald <rf@...nsource.cirrus.com>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     broonie@...nel.org, lee@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        tglx@...utronix.de, maz@...nel.org, linus.walleij@...aro.org,
        vkoul@...nel.org, lgirdwood@...il.com,
        yung-chuan.liao@...ux.intel.com, sanyog.r.kale@...el.com,
        alsa-devel@...a-project.org, patches@...nsource.cirrus.com,
        devicetree@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/10] mfd: cs42l43: Add support for cs42l43 core driver



On 5/18/23 11:15, Richard Fitzgerald wrote:
> 
> 
> On 18/05/2023 16:16, Pierre-Louis Bossart wrote:
>>
>>>>> +    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?
> 
> But you still can't access the hardware in probe(). So you'd have all
> the child drivers probing but not able to talk to the hardware. The
> child drivers would have to hook into the update_status() somehow so
> they know when the peripheral has enumerated.
> It's simpler to add them after the hardware has enumerated - they will
> be able to access the hardware in their probe().

It depends on what you mean by 'access the hardware'. If the only
interface is regmap and regmap is in cache-only, then the child drivers
could "access the hardware" without anything happening until after
regmap is no longer cache-only.

But yeah, I realize it's a long shot.