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]
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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ