On Wed, 2019-11-06 at 11:23 +0200, Peter Ujfalusi wrote: > > On 05/11/2019 20.07, Grygorii Strashko wrote: > > > > (but hey - if this is boot only then gpio-hogs should work. Are they?) > > > > > > That is another thing which almost works ;) > > > w/o gpio binding deferred probing is not possible if the GPIO controller > > > is probed later. > > > In some cases it might be even impossible to make sure that the GPIO > > > controller would probe first (GPIO extender on different i2c bus than > > > the user(s) of the gpio line) > > > In some cases moving around nodes in DT might artificially make things > > > work, but then someone compiles the expander as module, or some 'small' > > > change in kernel and the probe order on the bus changes. > > > I don't think it is a valid thing to have commits on the DT files > > > saying: move the expander front/after the hog affected user since since > > > Monday the probe order has changed. Then move it back two weeks later ;) > > > > > > > Ok. Above sounds like real problem. The implicit dependence is exist, > > but can't > > be resolved if any driver depends on gpio-hog of some gpio-controller. > > Probe deferring of gpio-controller will not lead to probe differing of > > dependent driver. > > > > Question: will gpio-hog mechanism resolve your case if it works (and > > probe differing issues)? > > I see gpio-hog to fulfill different role, use cases. It is more like > controlling muxes on boards to select between different exclusive > features. Things like route the I2S lines to analog codec or HDMI, route > RGB video to LCD panel or to HDMI, etc. > > But, if it would work it could be used for components which can be > enabled all the time. On the other hand, if a device has reset/enable > line then the driver should have a way to control it. I wonder if it would be useful to differentiate between required and suggested state in the consumer facing GPIO API for nonexclusive GPIOs. A driver that is ok with the enable line going into active state at any time while the device is suspended could use gpiod_set_value(en_gpio, 1); to resume, but gpiod_politely_suggest_value(en_gpio, 0); or similar to suspend, and the core could allow other drivers to override this state. Similarly to how the regulator framework allows consumers to set a voltage range, and the core decides on the actual voltage that fits the constraints. regards Philipp
