Re: [PATCH v5 2/2] i2c: mv64xxx: add an optional bus-reset-gpios property

[Krzysztof Kozlowski]

On 29/10/2023 21:48, Chris Packham wrote:
> 
> On 28/10/23 00:37, 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.
> 
> Last time I checked you couldn't share GPIOs. If that's no longer the 
> case then I can probably make what I need to happen work. It still 
> creates an issue that I have multiple PCA954x muxes connected to a 
> common reset GPIO so as each mux is probed the PCA954x driver will 
> toggle the reset. That's probably OK as the PCA954x is sufficiently 
> stateless that the extra resets won't do any harm but if it were a more 
> complicated device then there would be issues.

I know, but this is a broader problem, not really specific to this one
device. I also argue that your I2C controller does not actually have
this reset line.

> 
> Having some kind of ref-counted reset controller that is implemented 
> with GPIOs is probably the better solution. I was kind of surprised that 
> nothing existed like that in drivers/reset.

reset controller framework already supports this. The point is that GPIO
reset is not a reset controller, so in terms of bindings "resets"
property does not fit it.

> 
>> The problem is doing reset:
>> 1. in proper moment for all devices
>> 2. without affecting other devices when one unbinds/remove()
>>
>> 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://scanmail.trustwave.com/?c=20988&d=6qC75SLs-9PNM1ZHpLa6reGv82R6opEUmyI62vCytQ&u=https%3a%2f%2fsocial%2etreehouse%2esystems%2f%40marcan%2f111268780311634160
>>
>> 2. my WSA884x:
>> https://scanmail.trustwave.com/?c=20988&d=6qC75SLs-9PNM1ZHpLa6reGv82R6opEUmyJk3q3j7g&u=https%3a%2f%2flore%2ekernel%2eorg%2falsa-devel%2f84f9f1c4-0627-4986-8160-b4ab99469b81%40linaro%2eorg%2f
> Apologies for the mangled links (they're more secure now at least that's 
> what our IS team have been sold).
>> 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.
> 
> Actually I kind of expected this feedback. I figured I could start with 
> the driver that is currently causing me issues and once the dt-binding 
> was considered good enough it might migrate to the i2c core.
> 
>>


Best regards,
Krzysztof