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, 27 Oct 2023 14:55:37 +0200
From:   Andi Shyti <andi.shyti@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Chris Packham <chris.packham@...iedtelesis.co.nz>,
        gregory.clement@...tlin.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        Abel Vesa <abel.vesa@...aro.org>,
        Mark Brown <broonie@...nel.org>, linux-i2c@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/2] i2c: mv64xxx: add an optional bus-reset-gpios
 property

Hi Krzysztof,

On Fri, Oct 27, 2023 at 01:37:05PM +0200, Krzysztof Kozlowski wrote:
> On 27/10/2023 13:27, Krzysztof Kozlowski wrote:
> > On 27/10/2023 05:31, Chris Packham wrote:
> >> Some hardware designs have a GPIO used to control the reset of all the
> >> devices on and I2C bus. It's not possible for every child node to
> >> declare a reset-gpios property as only the first device probed would be
> >> able to successfully request it (the others will get -EBUSY). Represent
> 
> Cc: Mark,
> 
> Also this part is not true. If the bus is non-discoverable, then it is
> possible to have reset-gpios in each probed device. You can share GPIOs,
> so no problem with -EBUSY at all.
> 
> The problem is doing reset:
> 1. in proper moment for all devices
> 2. without affecting other devices when one unbinds/remove()

yes, I thought that we could get to this point, but I did not
object the patch as I didn't see an immediate better solution. I
would still be OK to merge it until we develop something better.

Let me mull this over and will be back to the topic.

Thanks, Krzysztof!
Andi

> The (2) above is not solveable easy in kernel and we already had nice
> talks about it just few days ago:
> 1. Apple case:
> https://social.treehouse.systems/@marcan/111268780311634160
> 
> 2. my WSA884x:
> https://lore.kernel.org/alsa-devel/84f9f1c4-0627-4986-8160-b4ab99469b81@linaro.org/
> 
> Last,
> I would like to apologize to you Chris. I understand that bringing such
> feedback at v5 is not that good. I had plenty of time to say something
> earlier, so this is not really professional from my side. I am sorry,
> just my brain did not connect all these topics together.
> 
> I apologize.
> 
> Best regards,
> Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ