On Thu, Nov 17, 2016 at 3:45 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > Hi Jyri, > > On Wednesday 16 Nov 2016 16:39:28 Jyri Sarha wrote: >> On 11/16/16 15:33, Rob Herring wrote: >> >> +Optional properties >> >> >> >>> + - reg: I2C address. If and only if present the driver node > > I assume you meant device node, not driver node ? > >> >>> + should be placed into the i2c controller node where the >> >>> + tfp410 i2c is connected to (the current implementation does >> >>> + not yet support this). >> > >> > So this chip can work without programming I guess? >> >> Yes. Just powering it up is enough for most application. >> >> > reg should only be not present if I2C is not connected in the design. It >> > can't be a function of what the driver supports. In otherwords, you >> > can't be moving this node around based on when you add I2C control. >> >> Ok, I'll try to implement a dummy i2c driver at the same time too. I can >> not test anything related to it because I do not have a piece of HW with >> tfp410 i2c wires connected, but it should not matter as long as I am >> able to probe it as a i2c client. > > I think that Rob's point was that whether the current implementation supports > this or not is irrelevant from a DT bindings point of view. It should not be > mentioned in the bindings document. Right. Now, whether the h/w has I2C wires connected or not is relevant to the binding doc. So the doc just needs some rewording, a dummy driver isn't needed. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
