Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 31 Jan 2022 15:37:16 +0200
From:   Andy Shevchenko <andriy.shevchenko@intel.com>
To:     Hans de Goede <hdegoede@redhat.com>
Cc:     "Rafael J . Wysocki" <rafael@kernel.org>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Mark Gross <markgross@kernel.org>,
        Andy Shevchenko <andy@kernel.org>,
        Wolfram Sang <wsa@kernel.org>,
        Lee Jones <lee.jones@linaro.org>,
        Sebastian Reichel <sre@kernel.org>,
        MyungJoo Ham <myungjoo.ham@samsung.com>,
        Chanwoo Choi <cw00.choi@samsung.com>,
        Ard Biesheuvel <ardb@kernel.org>, Len Brown <lenb@kernel.org>,
        linux-acpi@vger.kernel.org, Yauhen Kharuzhy <jekhor@gmail.com>,
        Tsuchiya Yuto <kitakar@gmail.com>,
        Fabio Aiuto <fabioaiuto83@gmail.com>,
        platform-driver-x86@vger.kernel.org, linux-pm@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org
Subject: Re: [PATCH v4 01/20] power: supply: core: Refactor
 power_supply_set_input_current_limit_from_supplier()
Message-ID: <YffmDCHY6csr0uyD@smile.fi.intel.com>
References: <20220130204557.15662-1-hdegoede@redhat.com>
 <20220130204557.15662-2-hdegoede@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220130204557.15662-2-hdegoede@redhat.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Sun, Jan 30, 2022 at 09:45:38PM +0100, Hans de Goede wrote:
> Some (USB) charger ICs have variants with USB D+ and D- pins to do their
> own builtin charger-type detection, like e.g. the bq24190 and bq25890 and
> also variants which lack this functionality, e.g. the bq24192 and bq25892.
> 
> In case the charger-type; and thus the input-current-limit detection is
> done outside the charger IC then we need some way to communicate this to
> the charger IC. In the past extcon was used for this, but if the external
> detection does e.g. full USB PD negotiation then the extcon cable-types do
> not convey enough information.
> 
> For these setups it was decided to model the external charging "brick"
> and the parameters negotiated with it as a power_supply class-device
> itself; and power_supply_set_input_current_limit_from_supplier() was
> introduced to allow drivers to get the input-current-limit this way.
> 
> But in some cases psy drivers may want to know other properties, e.g. the
> bq25892 can do "quick-charge" negotiation by pulsing its current draw,
> but this should only be done if the usb_type psy-property of its supplier
> is set to DCP (and device-properties indicate the board allows higher
> voltages).
> 
> Instead of adding extra helper functions for each property which
> a psy-driver wants to query from its supplier, refactor
> power_supply_set_input_current_limit_from_supplier() into a
> more generic power_supply_get_property_from_supplier() function.

...

> +	ret = power_supply_get_property_from_supplier(bdi->charger,
> +						      POWER_SUPPLY_PROP_CURRENT_MAX,
> +						      &val);
> +	if (ret == 0)

Can it be as simple as

	if (ret)
		return;

	...


?

Or did I misunderstand the meaning of 0?

-- 
With Best Regards,
Andy Shevchenko