On 15/07/2024 16:40, Maxime Ripard wrote: > On Thu, Jul 04, 2024 at 07:04:41PM GMT, Marc Gonzalez wrote: >> On 01/07/2024 15:50, Maxime Ripard wrote: >> >>> The i2c register access (and the whole behaviour of the device) is >>> constrained on the I2C_EN pin status, and you can't read it from the >>> device, so it's also something we need to have in the DT. >> >> I think the purpose of the I2C_EN pin might have been misunderstood. >> >> I2C_EN is not meant to be toggled, ever, by anyone from this planet. > > Toggled, probably not. Connected to a GPIO and the kernel has to assert > a level at boot, I've seen worse hardware design already. > >> I2C_EN is a layout-time setting, decided by a board manufacturer: >> >> - If the TDP158 is fully configured once-and-for-all at layout-time, >> then no I2C bus is required, and I2C_EN is pulled down forever. >> >> - If the board manufacturer wants to keep open the possibility >> to adjust some parameters at run-time, then they must connect >> the device to an I2C bus, and I2C_EN is pulled up forever. > > How do you express both cases in your current binding? It's not that I'm ignoring your question. It's that I don't understand what you're asking. SITUATION 1 tdp158 is pin strapped. Device node is child of root node. Properties in proposed binding are valid (regulators and power-on pin) Can be supported via module_platform_driver. SITUATION 2 tdp158 is sitting on I2C bus. Device node is child of i2c bus node. (robh said missing reg prop would be flagged by the compiler) Properties in proposed binding are valid (regulators and power-on pin) Supported via module_i2c_driver. If some settings-specific properties are added later, like skew, they would only be valid for the I2C programmable mode, obviously. Regards
