On Tue, Jul 2, 2024 at 4:29 AM Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > On Mon, Jul 01, 2024 at 11:42:27AM GMT, Rob Herring wrote: > > On Mon, Jul 01, 2024 at 08:42:22PM +0530, Krishna Yarlagadda wrote: > > > I2C interface timing registers are configured using config setting > > > framework. List available field properties for Tegra I2C controllers. > > > > How is I2C bus timing parameters specific to NVIDIA? Just because you > > have more controls? No. That's no reason to invent a whole new way to > > specify parameters. Extend what's already there and make it work for > > anyone. > > This may be applicable to a subset of this, and yes, maybe we can find > generalizations for some of these parameters. > > However, we're also looking for feedback specifically on these config > nodes that go beyond individual timing parameters. For example in the > case of I2C, how should parameters for different operating modes be > described? Like what? It all looks like timing to me. > Would you agree with something along the lines provided in this series? When there are multiple users/vendors of it, maybe. In general, it goes against the DT design of properties for foo go in foo's node. This looks more like how ACPI does things where it's add another table for this new thing we need. Rob
