From nobody Tue Apr 7 01:33:43 2026 Received: from mail-dy1-f182.google.com (mail-dy1-f182.google.com [74.125.82.182]) (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 68D473750CA for ; Mon, 16 Mar 2026 23:20:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773703219; cv=none; b=rdx+5FINTWdevbGoPsjsdsZwGqaifI3xRnHlIAzdBYT85uYVvtiFq1+z7dV8X7cElkq8/xiBng5bfodB0fsKDZpreAUgbUhyW4D+h706YuOOW4A4EpB/I69+6ko+M/cGJCu8L/bP1B67rEYxh1xXbb30XkyHWisl1EUzcH5gkBY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773703219; c=relaxed/simple; bh=bvCXSrrK+bsuMX/JIIQ5RzFghgzKSgXgNYwxE4t+MDI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=UjHRHBUIupkM1+ENJMnX8rRJovME8/P5046Uw3AsX/wp+TUlJDco1h3sThSI3rMhOBaQ7he3TkD2c/VCQi2vZuk+fSMd9qyyUtPE0eQ06f97yR1r8B7Co2vwWyf5f2BUx1tuGYcnwATTAI9oTnNoygJP35VhytdbrHVJXtiXHjE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Rh8EvO7J; arc=none smtp.client-ip=74.125.82.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com 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="Rh8EvO7J" Received: by mail-dy1-f182.google.com with SMTP id 5a478bee46e88-2c0d1d096d7so125599eec.1 for ; Mon, 16 Mar 2026 16:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773703216; x=1774308016; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=0wbNvfm2bMqUSp2PBT04xk1dYdjzZD03hLTKy9vjQfM=; b=Rh8EvO7JAtcUlPWNVVD9PdW5+2j6W/ef63IKsbgdnVQ1ueQqUIY63njfrFa9MA3km9 h3CSN4sBeiXpmdYGBixNhKA9qb8nb0b2AiBVKYg2T35b/Qsm7MTZtjMBwpXJoI8M0x38 qxobOnzfUWvCct2PoZj4jiagYmD3kKs9QfMSdULsAh4SlvKKamCwcGohC0u7al0g/70F xiMB6VpIdHzIgJyJ3+eThXNeTiWcXxndlAwJDUKgimoav95gbEiBhmUXLw83kV6r6OD6 abLi20kDw3b3Lj530QLYTzxkt4NhNUZEjvMNvyrEE+6OaZc65qY7LLOJgBGyfb72MvK1 MuHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773703216; x=1774308016; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0wbNvfm2bMqUSp2PBT04xk1dYdjzZD03hLTKy9vjQfM=; b=DF1dEEX9zgWqRZxd/6pBdMK3R82+UFQxTITeL1oD9qtLKhxA4UJC+MsoQ+yOy+toHb VpzljJZL+CPIQrTe8Ix7298MBBDcJqj0jgHK6Y7nSxxBshyvIWH/FscpVnTr3n9vWTal HsKAkkw6rBuKfJxp8NEYPwVCK8R4Ok6Pcpq3rm/ttLTYQLISNxTN9NDlMfHyfvpeTHku RTFRClj/cCrvSb3ns2qpBk52M/4QxF2c1rdKizC5LBeAsQYnD2rGQVrjGn6ltTsQhOx3 NxebRd3PO5fSVh9rbUAXIpxy/PLDRrLEyUT7BxlmDp7cJ4TJoE645kv5yA+5ocltjUNX sktA== X-Forwarded-Encrypted: i=1; AJvYcCUoOtd4onbIadhxt6qC2U+2EhZBwvpBHHOTufStzXyuRO3u1SpQmajCbNCyr6rJs4aEugbkvownM5pLsFg=@vger.kernel.org X-Gm-Message-State: AOJu0YzKzD50B3SHcSA9u/W6sh7NdE7G3RVbnXqm8oYQ6mTASCbYQAuc vAEnS4cZoQa4hX5RcKvAD8wm/VIFywtnX8uoN+Ed2hgpsoC5Brqrxmhx X-Gm-Gg: ATEYQzwyyhW3FZJzVHiIR5M9VB9LngyAjER0TioUs3ArboBV/rvTYbbDZg2pVShySPe +PzRPdEVEMjY82miQNBVoeBTb4wr6EXm4fg0uCAX31nvOU43ECZhZ289jcG5/nG+DJIbMI3p9bN e0COiw41RNjEmjwLV7Ou3pld6eoOw4hqq6Vzubx4gLvrGdnNjMVSdriFyjOe6jSftNvB07DlxfX DgV58PG825s7B1YoaUO6f6PP4OZV4S3OtrQ8BQ8t23uhu9gpYHDk9sMl3JDwM20X9YeKcWMswn9 3GFrPbARQL8dZrUPpYaT5OSoBu095MVbvWCviiLwXr2tjNu41v5iGtjg2tOCC8XZ0V3mHdrggal LEfoJoz/96FcMbAnV0p5lz1Q7FF6yS8hXXnFya/G1j8DtcL5SgQqxu5ZpXhuy+S/24jWHxkhIzm rywUv7SAnUKjBDQaB6z8uN3bqU/jS/FjoP237ppr9IOsMrQCFIctjxGVHazgg+H+y0Sn4BVn0j8 DqOuQ== X-Received: by 2002:a05:7022:2214:b0:128:d396:f2ea with SMTP id a92af1059eb24-1291722bc7cmr547868c88.11.1773703216378; Mon, 16 Mar 2026 16:20:16 -0700 (PDT) Received: from localhost.localdomain ([2804:14d:4c64:82a2:a465:e71c:7d56:aecd]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2beab555c44sm19846924eec.25.2026.03.16.16.20.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 16:20:15 -0700 (PDT) From: Rodrigo Gobbi To: lanzano.alex@gmail.com, jic23@kernel.org, dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org, gustavograzs@gmail.com Cc: ~lkcamp/patches@lists.sr.ht, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] iio: imu: bmi270: use dev_warn for unexpected chip id Date: Mon, 16 Mar 2026 20:11:48 -0300 Message-ID: <20260316232007.22887-1-rodrigo.gobbi.7@gmail.com> X-Mailer: git-send-email 2.48.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" An unexpected chip id read from hardware indicates a potential failure for detecting id, which needs a more appropriate level of verbosity. Signed-off-by: Rodrigo Gobbi --- I was exploring Bosch BMI270 driver and noticed a possible dev_info usage t= hat might not be appropriate it regarding its verbosity level. Let's consider that pr= obe definition at [1], used by [2] spi version and [3] i2 version. The i2c or spi callers will fill chip_info and then, probe will try to vali= date it at _init function: // drivers/iio/imu/bmi270/bmi270_core.c int bmi270_core_probe(struct device *dev, struct regmap *regmap, const struct bmi270_chip_info *chip_info) =20 data->chip_info =3D chip_info; ... ret =3D bmi270_chip_init(data); .... static int bmi270_chip_init(struct bmi270_data *data) { int ret; ret =3D bmi270_validate_chip_id(data); if (ret) return ret; .... from init, chipid will be read from hardware but if the value is not expect= ed with the one from the caller, i2c or spi, it will trigger a dev_info and not a w= arning: // valid ids for i2c and spi #define BMI260_CHIP_ID_VAL 0x27 #define BMI270_CHIP_ID_VAL 0x24 static int bmi270_validate_chip_id(struct bmi270_data *data) { int chip_id; int ret; struct device *dev =3D data->dev; struct regmap *regmap =3D data->regmap; ret =3D regmap_read(regmap, BMI270_CHIP_ID_REG, &chip_id); if (ret) return dev_err_probe(dev, ret, "Failed to read chip id"); .... if (chip_id !=3D data->chip_info->chip_id) dev_info(dev, "Unexpected chip id 0x%x", chip_id); if (chip_id =3D=3D bmi260_chip_info.chip_id) data->chip_info =3D &bmi260_chip_info; else if (chip_id =3D=3D bmi270_chip_info.chip_id) data->chip_info =3D &bmi270_chip_info; return 0; } The chip_info will be correct due the caller matching DT or ACPI before, an= d here, driver is only double-checking the value at hardware and printing if it is = not matching. Printing as info can be confusing, since this is more like a warning than i= nfo.=20 I don't have the hw here to test it, but I'm suggesting to just change the = level of that msg. Tks and regards. [1] https://github.com/torvalds/linux/blob/2d1373e4246da3b58e1df058374ed6b1= 01804e07/drivers/iio/imu/bmi270/bmi270_core.c#L1599 [2] https://github.com/torvalds/linux/blob/2d1373e4246da3b58e1df058374ed6b1= 01804e07/drivers/iio/imu/bmi270/bmi270_spi.c#L65 [3] https://github.com/torvalds/linux/blob/2d1373e4246da3b58e1df058374ed6b1= 01804e07/drivers/iio/imu/bmi270/bmi270_i2c.c#L32 --- drivers/iio/imu/bmi270/bmi270_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/imu/bmi270/bmi270_core.c b/drivers/iio/imu/bmi270/= bmi270_core.c index 2ad230788532..a2f90ac22873 100644 --- a/drivers/iio/imu/bmi270/bmi270_core.c +++ b/drivers/iio/imu/bmi270/bmi270_core.c @@ -1473,7 +1473,7 @@ static int bmi270_validate_chip_id(struct bmi270_data= *data) return -ENODEV; =20 if (chip_id !=3D data->chip_info->chip_id) - dev_info(dev, "Unexpected chip id 0x%x", chip_id); + dev_warn(dev, "Unexpected chip id 0x%x", chip_id); =20 if (chip_id =3D=3D bmi260_chip_info.chip_id) data->chip_info =3D &bmi260_chip_info; --=20 2.48.1