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
