On 2/9/22 15:22, Mark Brown wrote: > On Wed, Feb 09, 2022 at 03:17:06PM +0100, Javier Martinez Canillas wrote: >> On 2/9/22 14:43, Mark Brown wrote: > >>> Unless the device supports power being physically omitted regulator >>> usage should not be optional, it's just more code and a recipie for poor >>> error handling. > >> The device has a VCC pin but in most cases this is just connected to a >> power provided by the board in its pinout header. For example, I've it >> connected to a rpi4 3.3v pin. > > That sounds like a very common configuration. > Yep. >> I guess in that case what we should do then is to just have a regulator >> fixed as the vbat-supply in the Device Tree, that's regulator-always-on. > > Generally I'd suggest labelling things with whatever the supply is > called in the board's schematics/documentation, that tends to make > things clearer and easier to follow. > The display controller datasheet and schematics mention VBAT as the power supply but the documentation says that it's just connected to VCC and the label in the display says VCC. But I understand why the Device Tree binding and fbdev driver used VBAT since that's what the documentation mentions. >> The old ssd1307fb fbdev driver also had this as optional and I wanted to >> keep the new driver as backward compatible. But I understand now that is >> not describing the hardware properly by making this regulator optional. > > It is depressingly common to see broken code here, unfortunately > graphics drivers seem like one of the most common offendors. I'll include a patch for the existing DT binding and mark the vbat-supply property as required. Probably we won't be able to change the fbdev driver without causing regressions, and I'm not interested in that driver anyways. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
