<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Sep 17, 2017 at 2:38 PM, Brad Bishop <span dir="ltr"><<a href="mailto:bradleyb@fuzziesquirrel.com" target="_blank">bradleyb@fuzziesquirrel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> > Is it just stuck behind a gpio for no reason?  If that is the case,<br>
> > I<br>
> > would think you just wiggle the gpio when the bmc boots.<br>
><br>
> In this particular case, it's behind a GPIO so it doesn't drain the<br>
> battery -- or at least that's my understanding of the design.<br>
><br>
> The appropriate time would be -- when someone tries to read it from<br>
> the host.  What you're suggesting is that, the ipmi daemon, when it<br>
> receives a request for this sensor - that is then launches something<br>
> that sets the gpio, and then waits for the dbus objects to exist from<br>
> the launched phosphor-hwmon, before then requesting the sensor value<br>
> in its normal course of action.  Because it's my understanding it's a<br>
> gated sensor so that it doesn't drain the battery, which means<br>
> leaving it open effectively permanently isn't an option.  If I'm<br>
> misunderstanding the goal of the design, then obviously just<br>
> unlocking the GPIO effectively permanently is a solution.<br>
<br>
</span>Aha!  Now I understand the motivation.  And yes the approach I've<br>
outlined is quite painful.  In my defense I would not have suggested<br>
that had I known :-)<br></blockquote><div><br></div><div>Ahh - yeah, sorry, I didn't explain the entire use-case path initially.  I assumed gpio-gated sensors were just a normal thing. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> ><br>
> > I'm not arguing that there aren't several board setups where this<br>
> > is<br>
> > the case.  Rather, board designers are free to do whatever they<br>
> > want,<br>
> > and if we start putting the board specific logic in phosphor-hwmon<br>
> > you<br>
> > won't have "one nice package" for very long....<br>
><br>
> True-ish.  This is quite similar to dealing with GAIN and OFFSET. <br>
<br>
</span>Those feel different to me.  They are needed for thermistor type<br>
sensors regardless of board wiring.<br>
<span class=""><br>
> Those are particulars of a board that now get factored into the<br>
> value.  I'm not suggesting something beyond the norms of hwmon.  It<br>
> would be convenient however, if the ADC driver could be programmed to<br>
> know that some sensor is gated by a GPIO and handled flipping,<br>
<br>
</span>Can you reach out to Guenter or the relevant maintainer (is this an IIO<br>
device?) for ideas here?  I hadn't mentioned it but in the back of my<br>
head this whole time I've been wondering about a completely in-kernel<br>
solution.<br></blockquote><div><br></div><div>I'll reach out and see if this should go into the adc driver or the iio-hwmon.  Since those are the paths that are involved.  The sensor itself it plugged into the aspeed adc, and then controlled by a gpio.  My initial thought is the adc should be configured to know if such things are required for its sensors, so that iio-hwmon wouldn't need to know.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> waiting, reading, and flipping-back for someone -- quasi-similarly to<br>
> i2c muxes that use gpios.  Except, obviously, the waiting and setting<br>
> it back part are ... a bad plan to build into a driver, in that it<br>
<br>
</span>It has to be done in one place or the other, does it not?  You mention<br>
i2c muxes - managing those isn't delegated to userspace (there are<br>
drivers for i2c muxes) so maybe this situation need not be any<br>
different?<br></blockquote><div><br></div><div>That's what I'm thinking, if I can put it in the driver as something that can be configured - then perhaps that'll be a neater solution.  Although, depending on how it gets added, it might be too platform specific.  I'm using an Aspeed part, but I know there are other manufacturers, and if this type of arrangement exists elsewhere, more drivers will need modification in-lieu of a solution at the highest level.  I see the value in both approaches.</div><div><br></div><div>Downstream I have a gpio addition to phosphor-hwmon -- that I'll hold off on submitting.  I'm going to pursue the modifications to the ADC, I think they might be appropriate at that level, and if I recall I known the author and may be able to rapidly implement the necessary modification myself.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> could delay returning a value.  Although -- one could argue the fan<br>
> speed controller driver does that -- takes time to respond.  It's<br>
> just, one would then also want to configure the wait time, because<br>
<br>
</span>In the very near future I intend to make all the wait/delay/retry<br>
intervals runtime configurable to handle exactly these kinds of nuances<br>
between devices and their drivers.<br>
<div class="HOEnZb"><div class="h5"><br>
> some configurations will take longer for a sensor value to stabilize.<br>
><br>
> Patrick<br>
><br>
</div></div></blockquote></div><br></div></div>