devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	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 10:27:21 +0000	[thread overview]
Message-ID: <3fa4997f-4409-97f6-ba10-a87013383eb7@linaro.org> (raw)
In-Reply-To: <4492b71e-9923-365c-f22c-3766e2d5bae2@linux.intel.com>



On 19/12/2019 20:05, Pierre-Louis Bossart wrote:
>>>
>> 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.

Thanks,
srini

  reply	other threads:[~2019-12-20 10:27 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 [this message]
2019-12-20 15:22           ` Pierre-Louis Bossart
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=3fa4997f-4409-97f6-ba10-a87013383eb7@linaro.org \
    --to=srinivas.kandagatla@linaro.org \
    --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=pierre-louis.bossart@linux.intel.com \
    --cc=robh@kernel.org \
    --cc=spapothi@codeaurora.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).