On Mon, 2017-09-18 at 13:15 -0700, Guenter Roeck wrote: > On Mon, Sep 18, 2017 at 02:26:38PM -0500, Rob Herring wrote: > > On Fri, Sep 08, 2017 at 02:39:17PM +1000, Andrew Jeffery wrote: > > > > > > Signed-off-by: Andrew Jeffery <andrew@xxxxxxxx> > > > --- > > > .../devicetree/bindings/hwmon/pmbus/max31785.txt | 158 +++++++++++++++++++++ > > > > I think this needs to be located by what it does (fan control), not what > > interface it has (pmbus). > > > > I'm not all that happy with hwmon either because things here seem to > > just be based on being Linux hwmon devices which is sometimes arbitrary. > > > > The chip also measures temperatures. Other PMBus chips may do fan control, > measure temperatures, measure and/or control voltages, current, power ... > Strictly speaking pretty much all PMBus chips are multi-function devices. > I personally don't really care if the documentation is spread across > several directories, but even here this is already challenging. > > Only solution I can think of would be to create separate documents for each > functionality, ie here one for the device itself, one for fan control, > and one for temperature control (if that needs separate bindings). That > would be similar to mfd. But then we would still have to sort out where > to store the various bindings. Like iio, in subdirectories ? Like mfd, > in the matching subsystems ? If so, what to do if there is no matching > subsystem ? > > Lots of questions. I'll be happy to spend some time sorting it out, > but I would need some directions. > Likewise - I'm keen to discuss and iterate on this so we get something satisfactory. At least I could split out the PMBus-specific bindings from the Maxim- specific bindings in the current document, but there's still the question of how to arrange it as Guenter has queried above, and also how much of PMBus to define bindings for. I'm hesitant to take a stab at describing bindings across the whole spec if I don't have useful driver implementations to test against. I know that the bindings describe the hardware and not the driver, but there are probably more or less clumsy ways to describe devices that could be ironed out with a corresponding implementation (e.g. the Aspeed PWM/Tacho...). Thoughts? Andrew
Attachment:
signature.asc
Description: This is a digitally signed message part
