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. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
