Re: [PATCH 2/2] platform/x86: int3472: Fix uninitialised variable warning

On Mon, Aug 24, 2026 at 10:43:12AM +0300, Ilpo Järvinen wrote:
> On Fri, 21 Aug 2026, Sakari Ailus wrote:
> 
> > Moi,
> > 
> > Thanks for the review.
> > 
> > On Fri, Aug 21, 2026 at 11:34:06AM +0300, Ilpo Järvinen wrote:
> > > On Thu, 20 Aug 2026, Sakari Ailus wrote:
> > > 
> > > > Fix a smatch warning about uninitialised err_msg variable, by printing the
> > > > error where it is handled.
> > > > 
> > > > Signed-off-by: Sakari Ailus <[email protected]>
> > > > ---
> > > >  drivers/platform/x86/intel/int3472/discrete.c | 21 +++++++++----------
> > > >  1 file changed, 10 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> > > > index 6c729fcfce5d..cf8a58ef963b 100644
> > > > --- a/drivers/platform/x86/intel/int3472/discrete.c
> > > > +++ b/drivers/platform/x86/intel/int3472/discrete.c
> > > > @@ -329,7 +329,6 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
> > > >  	unsigned long gpio_flags;
> > > >  	union acpi_object *obj;
> > > >  	struct gpio_desc *gpio;
> > > > -	const char *err_msg;
> > > >  	const char *con_id;
> > > >  	int ret;
> > > >  
> > > > @@ -375,7 +374,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
> > > >  	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> > > >  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
> > > >  		if (ret)
> > > > -			err_msg = "Failed to map GPIO pin to sensor\n";
> > > > +			dev_err(int3472->dev, "Failed to map GPIO pin to sensor\n");
> > > >  
> > > >  		break;
> > > >  	case INT3472_GPIO_TYPE_CLK_ENABLE:
> > > > @@ -387,7 +386,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
> > > >  		gpio = skl_int3472_gpiod_get_from_temp_lookup(int3472, agpio, con_id, gpio_flags);
> > > >  		if (IS_ERR(gpio)) {
> > > >  			ret = PTR_ERR(gpio);
> > > > -			err_msg = "Failed to get GPIO\n";
> > > > +			dev_err(int3472->dev, "Failed to get GPIO\n");
> > > >  			break;
> > > >  		}
> > > >  
> > > 
> > > ssahiko is not happy about dev_err_probe() -> dev_err() conversion.
> > 
> > I was wondering, too, whether I should keep it, but then again returning
> > the error won't help here (as of now at least) and it is probably not
> > possible -EPROBE_DEFER would be returned in these cases. I can keep using
> > dev_err_probe() though if you prefer that.
> 
> If sashiko is wrong and skl_int3472_gpiod_get_from_temp_lookup() cannot 
> ever return -EPROBE_DEFER, then it doesn't matter. (But it seems 
> reasonably good at tracking the callchains so you might want to check the 
> detailed log if it actually found how it can return that). If it does 
> return -EPROBE_DEFER, dev_err_probe() should be kept.

I presume -EPROBE_DEFER comes from the gpiolib but it shouldn't happen
here.

I think I'll still switch back to dev_err_probe() just in case, as the
intention here is to avoid a build warning while cleaning up things a
little.

-- 
Sakari Ailus