From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
broonie@kernel.org, lee.jones@linaro.org,
linus.walleij@linaro.org
Cc: robh@kernel.org, alsa-devel@alsa-project.org,
bgoswami@codeaurora.org, vinod.koul@linaro.org,
devicetree@vger.kernel.org, spapothi@codeaurora.org,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [alsa-devel] [PATCH v6 02/11] mfd: wcd934x: add support to wcd9340/wcd9341 codec
Date: Fri, 20 Dec 2019 09:22:48 -0600 [thread overview]
Message-ID: <df1c8ef8-2619-99b7-317c-1970c9413d00@linux.intel.com> (raw)
In-Reply-To: <3fa4997f-4409-97f6-ba10-a87013383eb7@linaro.org>
>>> Note these are the child devices of the MFD SLIMBus device.
>>
>> Ah ok. I guess the creation of those child devices when the parent
>> SLIMbus device reports PRESENT initially if fine, it's the part where
>> you remove them if the device loses sync or gets powered off which is
>> odd. And I guess technically you could still have race conditions
>> where a child device starts a transaction just as the parent is no
>> longer attached to the bus.
>
> Losing power to SLIMBus device is very odd usecase and if it happens
> suggests that threre are bigger issues on the board design itself. This
> case should never happen. Even if it happens we would get timeout errors
> on every SLIMbus transactions.
>
>>
>>>> I would however not remove the devices when the status is down but
>>>> only on an explicit .remove.
>>>
>>> Am open for suggestions but I would not like the child devices to
>>> talk on the bus once the SLIMbus device is down! Only way to ensure
>>> or make it silent is to remove.
>>
>> it's as if you are missing a mechanism to forward the parent status to
>> the children so use remove() for lack of a better solution?
> That is true. This gives bit more control on the slave device lifecycle.
> Current solution works fine for now with less complexities across
> multiple drivers. I also agree that there is scope of improvement in
> future for this.
ok, makes sense, thanks for the answers. No further questions, so
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
next prev parent reply other threads:[~2019-12-20 15:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 10:31 [PATCH v6 00/11] ASoC: Add support to WCD9340/WCD9341 codec Srinivas Kandagatla
2019-12-19 10:31 ` [PATCH v6 01/11] ASoC: dt-bindings: add dt bindings for WCD9340/WCD9341 audio codec Srinivas Kandagatla
2019-12-19 10:31 ` [PATCH v6 02/11] mfd: wcd934x: add support to wcd9340/wcd9341 codec Srinivas Kandagatla
2019-12-19 16:36 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-19 17:28 ` Srinivas Kandagatla
2019-12-19 20:05 ` Pierre-Louis Bossart
2019-12-20 10:27 ` Srinivas Kandagatla
2019-12-20 15:22 ` Pierre-Louis Bossart [this message]
2020-01-22 9:55 ` Srinivas Kandagatla
2020-01-29 11:18 ` Lee Jones
2019-12-19 10:31 ` [PATCH v6 03/11] ASoC: " Srinivas Kandagatla
2019-12-25 18:21 ` Applied "ASoC: wcd934x: add support to wcd9340/wcd9341 codec" to the asoc tree Mark Brown
2019-12-19 10:31 ` [PATCH v6 04/11] ASoC: wcd934x: add basic controls Srinivas Kandagatla
2019-12-19 10:31 ` [PATCH v6 05/11] ASoC: wcd934x: add playback dapm widgets Srinivas Kandagatla
2019-12-19 10:31 ` [PATCH v6 06/11] ASoC: wcd934x: add capture " Srinivas Kandagatla
2019-12-19 10:31 ` [PATCH v6 07/11] ASoC: wcd934x: add audio routings Srinivas Kandagatla
2019-12-19 10:31 ` [PATCH v6 08/11] dt-bindings: gpio: wcd934x: Add bindings for gpio Srinivas Kandagatla
2020-01-07 9:47 ` Linus Walleij
2020-01-07 10:17 ` Srinivas Kandagatla
2020-01-07 22:28 ` Rob Herring
2019-12-19 10:31 ` [PATCH v6 09/11] gpio: wcd934x: Add support to wcd934x gpio controller Srinivas Kandagatla
2020-01-07 9:48 ` Linus Walleij
2019-12-19 10:31 ` [PATCH v6 10/11] ASoC: qcom: dt-bindings: Add compatible for DB845c and Lenovo Yoga Srinivas Kandagatla
2019-12-19 10:31 ` [PATCH v6 11/11] ASoC: qcom: sdm845: add support to " Srinivas Kandagatla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=df1c8ef8-2619-99b7-317c-1970c9413d00@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=bgoswami@codeaurora.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=spapothi@codeaurora.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=vinod.koul@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).