Hi Arndrea, On 2019-04-01 11:56, Andrea Merello wrote: > Hi all, > > Right now I'm in the process of writing the DT for a board that has an > EMMC with its reset signal attached to a I2C GPIO expander; the I2C > GPIO controller driver can sleep while setting GPIOs. > > Currently the pwrseq_emmc driver expects the GPIO driver not to sleep > since it makes use of gpiod_set_value() insted of > gpiod_set_value_cansleep(), so I cannot use it in my scenario. > > I guess that it has been done on purpose.. Is it just the emergency > reboot notification handler that needs this? Would it worth to check > if the GPIO driver can sleep, and eventually handle only the > .post_power_on() callback (I'm assuming it isn't called from atomic > context, but indeed I'm not sure)? > > Apart from that, I cannot see any obvious way to allows the > pwrseq_emmc drive to work with sleepy gpio-controller drivers. Does > anyone have any advice? Your idea seems to be fine. I'm okay with converting to *_cansleep() in .post_power_on and making the emergency callback optional (depending on the supported GPIO api). That time this code has been developed, there was no use case for the _cansleep() version. Feel free to fix it :) > Finally, if not any way to handle the said situation can be found, and > since AFAIK DTs are not just a Linux stuff (i.e. they can be used by > u-boot and maybe others..), would it eventually worth to check for a > sleepy gpio-controller in emmc_powerseq, and eventually refuse to work > and maybe spit a warning? This would allow for letting the DT to > describe the hardware as it is without getting kernel warnings and > other troubles.. > > Thanks, > Andrea > > Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
