On Sat, 4 Mar 2023 04:36:49 -0800 Andrew Hepp <andrew.hepp@xxxxxxxxx> wrote: > Hi Krzysztof, > > Appreciate the feedback! Snipping for brevity. > > On 3/4/23 3:20 AM, Krzysztof Kozlowski wrote: > > ... > >> + maxItems: 1 > >> + > >> + interrupts: > >> + minItems: 1 > >> + maxItems: 6 > >> + > >> + interrupt-names: > >> + minItems: 1 > >> + maxItems: 6 > >> + items: > >> + enum: > > > > The interrupts should be usually strictly ordered and you allow any > > combinations. Why? > > > > Why are they optional? > > The driver as currently written doesn’t support any interrupts. The > device does not require interrupts to function. > > This is the first dt-binding I’ve written, so it’s very possible that > I’ve made a mistake, but I believe any combination of interrupts should > be valid. Each of the interrupts listed represent an independent > physical pin of the mcp960x chip. That pin might not be connected at > all, so it seems to me that any combination of interrupts should be allowed. > > MCP9600 and MCP9601 chips have four alert interrupts that trigger when > temperature crosses a threshold (with configurable hysteresis). The > MCP9601 adds short and open circuit detection interrupts. This is a very common situation for sensors, hence the use of interrupt-names to allow us to specify any subset. A driver using these will then need to cope with a random subset (of course it's allowed to just not use any of them at all if only some are wired, or any other policy the driver author wants to use). Board designers love to save pins on their interrupt controller so not wiring them all up is very common. Jonathan > > > > > > >> + - open > >> + - short > >> + - alert1 > >> + - alert2 > >> + - alert3 > >> + - alert4 > >> + > >> + thermocouple-type: > ... > > Thanks, > Andy
