Hi Mark, On Mon, Nov 29, 2021 at 12:08:06PM +0000, Mark Brown wrote: > On Sun, Nov 28, 2021 at 01:38:34AM +0200, Laurent Pinchart wrote: > > On Fri, Nov 26, 2021 at 12:22:35PM +0100, Hans de Goede wrote: > > > On 11/26/21 00:32, Laurent Pinchart wrote: > > > > On Thu, Nov 25, 2021 at 05:54:02PM +0100, Hans de Goede wrote: > > > >> The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in > > > >> the kernel the Regulators and Clocks are controlled by an OpRegion > > > >> driver designed to work with power control methods defined in ACPI, but > > Please delete unneeded context from mails when replying. Doing this > makes it much easier to find your reply in the message, helping ensure > it won't be missed by people scrolling through the irrelevant quoted > material. I have mixed feelings about that, someones the context is indeed not needed, but I've found myself more often than not replying deep in a mail thread and wishing the context hadn't been deleted, because it ended up being relevant. > > > >> + * (1) This regulator must have the same voltage as VIO if S_IO LDO is used to > > > >> + * power a sensor/VCM which I2C is daisy chained behind the PMIC. > > > >> + * (2) If there is no I2C daisy chain it can be set freely. > > > >> + */ > > > > > Do we need safety checks for this ? > > > > There really is no way to deal this condition needs to matches inside the driver, > > > this should be enforced by setting proper constraints on the 2 regulators where > > > the PMIC is used with a sensor I2C daisy chained behind it. > > > Right. I tend to be cautious here, as incorrect settings can destroy the > > hardware. We should err on the side of too many safety checks rather > > than too few. I was thinking that the cio2-bridge driver could set a > > daisy-chaining flag, which could trigger additional checks here, but it > > wouldn't protect against someone experimenting to support a new device > > and setting different voltages without the daisy-chaining flag. > > > My biggest worry is that someone with an unsupported machine may start > > by copying and pasting an existing configuration to try it out, and fry > > their hardware. > > There's really nothing you can do that prevents this, especially in the > cut'n'paste scenario. Overrides tend to get copied along with the rest > of the configuration, or checks hacked out if people think they're > getting in the way without realising what they're there for. Maybe a big fat warning comment in the code ? Apart from that, I agree, I don't think we can do much. -- Regards, Laurent Pinchart
