linux-kernel - Re: [alsa-devel] [PATCH v6 02/11] mfd: wcd934x: add support to wcd9340/wcd9341 codec

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: <df1c8ef8-2619-99b7-317c-1970c9413d00@linux.intel.com>
Date:   Fri, 20 Dec 2019 09:22:48 -0600
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        broonie@...nel.org, lee.jones@...aro.org, linus.walleij@...aro.org
Cc:     robh@...nel.org, alsa-devel@...a-project.org,
        bgoswami@...eaurora.org, vinod.koul@...aro.org,
        devicetree@...r.kernel.org, spapothi@...eaurora.org,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH v6 02/11] mfd: wcd934x: add support to
 wcd9340/wcd9341 codec



>>> 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@...ux.intel.com>