<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Sep 17, 2017 at 10:33 AM, 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>
> ><br>
> > What do you think of this?<br>
> ><br>
> > 1 - You simply wiggle the gpio from a script or small application<br>
> > at<br>
> > the appropriate time.<br>
><br>
> My thought here is -- the appropriate time is, right before phosphor-<br>
> hwmon wants to read it.<br>
<br>
</span>phosphor-hwmon shouldn't be providing an interface for something<br>
that isn't accessible. And it shouldn't concern itself with<br>
making something accessible because there could be any number of<br>
ways to do that, based on the wiring of the board.<br>
<br>
What I meant was why is the sensor gated by a gpio? For example, is it<br>
because the sensor is only available when some power domain is actually<br>
powered on? In that example, the appropriate time would be when<br>
the power domain is turned on and off.<br>
<br>
Is it just stuck behind a gpio for no reason? If that is the case, I<br>
would think you just wiggle the gpio when the bmc boots.<br></blockquote><div><br></div><div>In this particular case, it's behind a GPIO so it doesn't drain the battery -- or at least that's my understanding of the design.</div><div><br></div><div>The appropriate time would be -- when someone tries to read it from the host. What you're suggesting is that, the ipmi daemon, when it receives a request for this sensor - that is then launches something that sets the gpio, and then waits for the dbus objects to exist from the launched phosphor-hwmon, before then requesting the sensor value in its normal course of action. Because it's my understanding it's a gated sensor so that it doesn't drain the battery, which means leaving it open effectively permanently isn't an option. If I'm misunderstanding the goal of the design, then obviously just unlocking the GPIO effectively permanently is a solution.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> <br>
> > 2 - An application other than phosphor-hwmon monitors this gpio and<br>
> > binds the driver to it (or unbinds).<br>
><br>
> In this case, won't the device be removed/added to the hwmon sysfs on<br>
> demand? I don't believe phosphor-hwmon picks up new devices<br>
> automatically.<br>
<br>
</span>Yes, on demand, but he phosphor-layer has a udev rule that launches<br>
(and terminates) a phosphor-hwmon instance along with it.<br>
<span class=""><br>
> <br>
> > 3 - phosphor-hwmon works without modification.<br>
> ><br>
> > In fact, #2 is already done - Matt Spinler recently added code to<br>
> > phosphor-gpio-monitor to do exactly this.<br>
><br>
> I haven't looked at gpio-monitor.<br>
> <br>
> > I prefer something like this for two reasons:<br>
> ><br>
> > 1 - Consistency in how we handle things. It becomes easier to<br>
> > write<br>
> > howtos or cookbooks to provide guidance in the future. <br>
><br>
> <br>
> > 2 - We avoid one-offs in phosphor-hwmon.<br>
><br>
> I wouldn't necessarily consider it a one-off, as I can immediately<br>
> think of at least one other motherboard that would benefit from such<br>
> an opportunity. Also, in this case it would all fit into one nice<br>
> package -- one thing to configure by adding the corresponding line to<br>
> a configuration file.<br>
<br>
</span>I'm not arguing that there aren't several board setups where this is<br>
the case. Rather, board designers are free to do whatever they want,<br>
and if we start putting the board specific logic in phosphor-hwmon you<br>
won't have "one nice package" for very long....<br></blockquote><div><br></div><div>True-ish. This is quite similar to dealing with GAIN and OFFSET. Those are particulars of a board that now get factored into the value. I'm not suggesting something beyond the norms of hwmon. It would be convenient however, if the ADC driver could be programmed to know that some sensor is gated by a GPIO and handled flipping, waiting, reading, and flipping-back for someone -- quasi-similarly to i2c muxes that use gpios. Except, obviously, the waiting and setting it back part are ... a bad plan to build into a driver, in that it could delay returning a value. Although -- one could argue the fan speed controller driver does that -- takes time to respond. It's just, one would then also want to configure the wait time, because some configurations will take longer for a sensor value to stabilize.</div><div><br></div><div>Patrick</div></div><br></div></div>