8 березня 2023 р. 13:35:46 GMT+02:00, Guenter Roeck <linux@xxxxxxxxxxxx> написав(-ла): >On 3/8/23 02:32, Svyatoslav Ryhel wrote: >> ср, 8 бер. 2023 р. о 12:27 Krzysztof Kozlowski >> <krzysztof.kozlowski@xxxxxxxxxx> пише: >>> >>> On 08/03/2023 10:40, Svyatoslav Ryhel wrote: >>>> Add supply property. >>> >>> You have entire commit msg to explain and give background, but instead >>> there is just sentence duplicating subject. And since you did not >>> explain anything, we have questions... like: INA238 does not have VDD, >>> so this does not look correct. >>> >> >> This is why a regulator is not mandatory. If ina238 does not have vdd >> then one who needs ina238 may omit this prop. How about looking from >> this perspective? >> > >If a chip does not have VDD, the driver should not even try to get it >for that chip. INS238 is supported by a different driver, so that does >not require special code, but it needs to be spelled out in the devicetree >bindings. Devicetree has a means to specify if a property is valid for >a given device. > >Having said this, as it turns out, _none_ of the chips supported by >the ina2xx and the ina238 drivers have VDD. All of them have Vs, and >all but INA219 have Vbus. The bindings don't even explain which one >of those is supposed to refer to "VDD". > So you refer to vdd as to a real name. Now I understand this misunderstand. Regulator I am interested in is Vs. Since you confirmed that Vs is supported by all ina2xx there should be no contraversions further. >Also, regulator_get_optional() returns -ENODEV if CONFIG_REGULATOR >is not enabled, so it isn't entirely optional. We can not suddenly fail >to load the driver on systems with CONFIG_REGULATOR=n, so some conditional >code will unfortunately be necessary. > >Guenter > Hm, then Lars-Peter Clausen suggestion should be applicable in this case. >>> >>> Best regards, >>> Krzysztof >>> >> >> Best regards, >> Svyatoslav R. >
