On Fri, 2023-12-01 at 08:46 -0800, Guenter Roeck wrote: > On 12/1/23 08:29, Nuno Sá wrote: > > On Fri, 2023-12-01 at 08:04 -0800, Guenter Roeck wrote: > > > On 12/1/23 07:47, Andy Shevchenko wrote: > > > > On Fri, Dec 01, 2023 at 04:24:35PM +0100, Nuno Sá wrote: > > > > > On Fri, 2023-12-01 at 14:40 +0100, Linus Walleij wrote: > > > > > > > > ... > > > > > > > > > Yes, that is the only thing we have. Meaning that there is no hw setting to > > > > > set > > > > > the > > > > > pins to open drain. Open drain is what they are. That is why I'm not seeing > > > > > the > > > > > point > > > > > in having PIN_CONFIG_DRIVE_OPEN_DRAIN implemented. > > > > > > > > At least you have to implement error for PUSH_PULL mode and other modes, > > > > so from the (core) software point of view the user should be able to ask for > > > > anything and get an answer from the certain driver that "hey, i do support > > > > OD", > > > > or "hey, push-pull can't be supported with this hw". > > > > > > > > > > It seems to me that this is heading towards a mfd driver. I don't feel > > > comfortable > > > with all that gpio specific code in the hwmon subsystem. > > > > > > Maybe I should request that all hwmon chips with gpio support must be > > > implemented > > > as mfd drivers. I'll have to think about that. > > > > > > Guenter > > > > > > > Hopefully you don't ask that already for this driver... > > > > Yes, I am, because the gpio part is getting way to complicated for embedding it > into a hwmon driver. > Well, fair enough... I will then drop it for now. The priority is the hwmon part as that was the request from a customer. I'll only leave the pin functions that might be relevant from a monitoring point of view. Hopefully, I'll get into the gpio stuff later on. From a brief look, the auxiliary bus might feet and easier than mfd. - Nuno Sá
