From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f43.google.com (mail-dl1-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A73482749DF for ; Fri, 6 Mar 2026 18:10:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772820608; cv=none; b=t/o247UIHO3VnXIX7gpfZSFC+CCWaxBUBvCOBpX//KvX09/3QPL5WKUAk6HQz8poIbfb0TJ3h1FKOGnyZU9MBuV0G8cTrwzxmeZlE5b8Vr06sfjWpVdp0L/yeWuCO3szQCkmhp3r8B4qOttOFoa7hH5iNzQdI8+0Ggd8hzDtf6c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772820608; c=relaxed/simple; bh=fb9fAI+2R4+pLGV9+1rNCenVLZhpHBa88vK4gABjIw8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IeUqCtqy84PpSFci01ClB4mwM5LI/lvGxsWJ8YAhmu5hQEv2CDGJFASX4N89MNBCw5DxWXH69lxeqPcbbtX9b6FaPT3IOKoh3gu/oXysxVCVuoNPImCGcnXo61TH15KKfqwdYoMhBihAFr3/8dp0Cxe/L8w1xIRQOEIPvc1jy38= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=DIVLYDWQ; arc=none smtp.client-ip=74.125.82.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DIVLYDWQ" Received: by mail-dl1-f43.google.com with SMTP id a92af1059eb24-127380532eeso4040916c88.1 for ; Fri, 06 Mar 2026 10:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772820607; x=1773425407; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=4t90rBsh0jMs5hxeKF0aBgH4tWUbByc3KabB0tRVGYg=; b=DIVLYDWQcua0+8SGuUS0ptNGhjqxHRSnwy+7N1PXVFP/1fe1pQktqxgFqBGGRZ7eqk WncpVAVCimI/nlrcQPWvr5CLG9a9oQtTMOCJC4sRZb6UMjCgGiZvxbxxeqdF8C7oOaAf AvnHYDrBYTaHSO4yVXm45omz1Xyv3O3OcMyIevJwRjglNlC4dulSYxErxdZqjY5JToz0 2rx3peWypJoPfRRUK4hNcuhFsGp5jG6x26r9TlLDf+eZVSkmavME+a6t4rw6N1BptW8B GUHsHTK3BqR36/I3s2R40Xk/giaQRZ3+1GISYHBbOQUkcVGTyh8Y79g4q1wLQe2TWzUC BooQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772820607; x=1773425407; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=4t90rBsh0jMs5hxeKF0aBgH4tWUbByc3KabB0tRVGYg=; b=i9yvwk/njj6EIo5n4kcDQ2iqEvSP+BGfEk3lh39xQ/XQCg7xqp8zz5Yvx4nzkppbD5 r56MxDNhMnUXfweTRQeDR5jCxeoo2+kmJk3JFbUV7i8JdbpEbbUm2etP1fIEAoydutn+ p5UwDz5Bqt58eMGbhvAC9KuEwEx16WAexF2Qb2FJBXUhoCNhLKP4gk49HjKmrBfSqznN A4rBIl61iaoGUlMeRfgLpFrMPVpZ0RC/f1IIXI/l77Q9PJoV6iMa+9JU/vG0i7sCTYAK ai1Da4ndli7ByfG2kgBNGGqYUkd2o/562lZ3dy/dISHf2Hw6I8oXQD02tinPK4Es1qN+ xcBw== X-Forwarded-Encrypted: i=1; AJvYcCXtuC5RilYcrPR7ssKNIZk89+pomiqoTaDxem0IQp8/QAXlIDSFMjMAb4c5H+a3UEYP7KPmbMIj3En6THg=@vger.kernel.org X-Gm-Message-State: AOJu0Yy2wJDrYHcO33IucbdjqR39aPzMx5HcNjlEQ651r5GC+6hqAJVQ UdIooUZDr4oXTn+UTv4FYW2DPrNc+3t/oVvWrRsH7nmyEq29Q8KD/TxRsE7Cle/2 X-Gm-Gg: ATEYQzxkDjnQiSlFei1fNfOAmLNAGcksVhY4ZfuMSqXSpE5AHJsBJ2ioS8th3Y5DjO0 wnXjtT2Uhy7sz7oerg0XSUONMZFvc9ZAmEZ9Tka70v4AgmRTmDfUYf9aMwQYHQAl4bYG7esAtrC PnhP23hSa3w+BnxZMmD8yWYVPU/L9DX8GlY9luIliAwZjjpLnAEqC7jiI4tcGjxckxfZWtr/6q9 Lo9Cpz73vuUIp2lvzcE5v1f+efYK96lHxdcS15pAFZQ9HkIalojwSW6XHSIGZzgWjBQvnQIjTew 5e3AVd+SNarO/hOVBV7nQFjqcbC74CwAZUgAepHDRUjutOoDtGfX0SjUt/xJbot1cKXwyDswbU+ 1UiQ4u32UABZseUhQIGKOvYGmzna1FVFFHDqa+edGTIFfTHxGLhukAeh6ISKc+Ekv+A/UVdpLfn EkNbszlT8ycmB01RvAWCVTwRdvxLjikqIn2KjP X-Received: by 2002:a05:7022:784:b0:11c:b3ad:1fe1 with SMTP id a92af1059eb24-128c2dc0854mr1462737c88.11.1772820606683; Fri, 06 Mar 2026 10:10:06 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:da43:aeff:fecc:bfd5]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-128c3f4351bsm1596188c88.11.2026.03.06.10.10.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 10:10:06 -0800 (PST) Sender: Guenter Roeck Date: Fri, 6 Mar 2026 10:10:05 -0800 From: Guenter Roeck To: Andrew Davis Cc: Chiang Brian , Erick Karanja , Grant Peltier , Jeff Lin , Cherrence Sarip , Kim Seer Paller , Alexis Czezar Torreno , linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 10/11] hwmon: (pmbus/ltc2978) Remove use of i2c_match_id() Message-ID: <85d35de0-943d-4efc-925f-d42eae941948@roeck-us.net> References: <20260306171652.951274-1-afd@ti.com> <20260306171652.951274-11-afd@ti.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260306171652.951274-11-afd@ti.com> On Fri, Mar 06, 2026 at 11:16:51AM -0600, Andrew Davis wrote: > The function i2c_match_id() is used to fetch the matching ID from > the i2c_device_id table. This can instead be done with > i2c_client_get_device_id(). For this driver functionality should > not change. Switch over to remove the last couple users of the > i2c_match_id() function from kernel. > > Signed-off-by: Andrew Davis > --- > drivers/hwmon/pmbus/ltc2978.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/hwmon/pmbus/ltc2978.c b/drivers/hwmon/pmbus/ltc2978.c > index 8f5be520a15db..d69a5e675e80e 100644 > --- a/drivers/hwmon/pmbus/ltc2978.c > +++ b/drivers/hwmon/pmbus/ltc2978.c > @@ -733,7 +733,7 @@ static int ltc2978_probe(struct i2c_client *client) > return chip_id; > > data->id = chip_id; > - id = i2c_match_id(ltc2978_id, client); > + id = i2c_client_get_device_id(client); AI feedback: Is `id` guaranteed to be non-NULL here? If the device is instantiated via ACPI `PRP0001` or using a fallback DT compatible string where the first compatible string is not in the `ltc2978_id` table, `i2c_client_get_device_id()` will return `NULL`. This leads to a NULL pointer dereference when accessing `id->driver_data`. While this vulnerability existed in the old code with `i2c_match_id()`, adding a NULL check here might be a good idea while the code is being refactored. I never know if this is real. Any idea ? Thanks, Guenter > if (data->id != id->driver_data) > dev_warn(&client->dev, > "Device mismatch: Configured %s (%d), detected %d\n", > -- > 2.39.2 >