On Mon, Jan 18, 2021 at 1:07 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > On Fri, Jan 15, 2021 at 11:30:14AM +0100, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > > > When inspecting the current bias setting of a GPIO line, the AS_IS name > > of one of the possible values really means that the kernel uAPI can't > > determine the bias setting because it didn't set it itself. In this case > > it's better to change the name to BIAS_UNKNOWN to reflect that. > > > > Your checkin comment incorporates some of my review comments, which were > actually a bit sloppy. While I didn't bother to correct myself for that > email, I'd rather the checkin comment be more precise. > > Specifically, I was conflating gpiolib and the cdev uAPI. If the bias > is set via gpiolib then the uAPI will report it correctly. If it is set > otherwise then the setting is unknown to gpiolib and therefore the uAPI. > > And I'm not sure if the DT example that I used in that email was a good > one. But say the hardware initialises with pull-up enabled. If it hasn't > also been set via gpiolib then it will be reported as unknown. > Which makes me wonder whether we shouldn't add a get_config() callback to drivers in gpiolib for that because some controllers allow you to query their current settings. --- When inspecting the current bias setting of a GPIO line, the AS_IS name of one of the possible values really means that the kernel GPIO subsystem can't determine the bias setting because it didn't set it itself (e.g. the hardware may have internally initialized pull-up or pull-down resistors). In this case it's better to change the name to BIAS_UNKNOWN to reflect that. --- Does this sound good? Bartosz