[PATCH linux dev-4.10 1/6] dt-bindings: max31785: Add mark-fan-installed property

Andrew Jeffery andrew at aj.id.au
Mon Jul 31 18:55:39 AEST 2017

On Mon, 2017-07-31 at 17:42 +0930, Joel Stanley wrote:
> > On Sat, Jul 29, 2017 at 1:52 AM, Andrew Jeffery <andrew at aj.id.au> wrote:
> > It's a system design decision with regards to managing the default
> > values of registers such as FAN_CONFIG_1_2. Do not assume the hardware
> > is configured such as the fans are marked as installed, rather expose a
> > devicetree option to inform the driver of whether it should mark the
> > fan as installed itself.
> I think we would be better served by making this a property of the
> device (instead of each fan).

> The property presence indicates "check the register to enable/disable
> specific fans". For systems that have this bit configured, we have the
> existing behaviour of the driver.
> Otherwise we just set the register based on the fan child nodes that
> are present in the device tree, which is your proposed behaviour.

So I'll attempt to rephrase what you're suggesting and make it

What you're proposing is something like a 'strict-fan-check' property
that *requires* that the device has the installed bit pre-programmed
for each fan described in the devicetree, else the driver warns or
errors out.

If 'strict-fan-check' is not present at the chip node level, then for
each fan child-node, simply set the installed bit on the appropriate

Have I understood correctly?

Alternatively we have a mark-fans-installed at the chip node level.
This seems less attractive having read your reply.


Bonus round: In some systems we have presence-detect GPIOs for each
fan. Should we have a gpio property in the fan controller bindings to
describe this? Given that we're in the process of trying to export the
GPIOs to userspace, maybe not, but it's worth a thought.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170731/60a7bc85/attachment.sig>

More information about the openbmc mailing list