From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (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 250DC42CAF2 for ; Mon, 6 Jul 2026 09:30:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783330212; cv=none; b=IIvmysHECEaTsXaUJoQpX6NXv08Lgdjgg5hHtSxCihnSqQvOfsIdF/zERIi3S3A41Se3tj1dIiAqsxgACMWE0OtiJ//k5mR/P/KowpiKTIZvqTzaFenBZMhqkryLd/rTlRcrH9z22XRm+Rh6gfQ+t4NBlVui+34xMq0qQmufnUM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783330212; c=relaxed/simple; bh=OhFRXTlujyyMgb1o4KywRqevY2zJhFWTYPR4usZs7rA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=cdL6l42A332BZL6OwQeos/ClvQGik7gwTjctmH3i+5zJELacAfQ0JRiio7ToIyY+StY6v/oe7bxYjzmhiFCSygAVQZEDxQlrrm9r4ssHK3eczz1scG9BolubFv/SiPYuzHxT8H4sfX943VHVXZH7QVeGstfV/os14BBprMGS9A0= 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=hceINvlT; arc=none smtp.client-ip=209.85.216.44 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="hceINvlT" Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-381c51fde6bso2874171a91.2 for ; Mon, 06 Jul 2026 02:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783330206; x=1783935006; 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=EKujA/S28nH72LezpF4GQx72K8BhZF5KWOfp99g3VZA=; b=hceINvlTNY8JPFU9qcuYl5Fmpra3re1EyrKXN0+xhrCxjBToBcN/krptuSNphoCkS8 23e8CJVWKONlbRLpnz3qF31JR2GyyzLbgeP5f4PS327d1eE+eBbqU8hZ7dxJkZ4z9SK9 sVYKCracg+QSYQn04JWJ6l7NM0m5oERig34dOHLP3wLhW253ndLKfeyZSgndeGDOm/Aq PVRo/vg5/XeGlIgBAfsU9upZ5t2aSVXREcAQjcIASchgiLNYQEt6BpxmhdWGSDs8bwXL vN48iTGznNaOWp97889Vd90zxvJjfKd8OH9FeQ9JSGkfqM3s66MdDI9Sjz5nxSmh7plu tceQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783330206; x=1783935006; 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=EKujA/S28nH72LezpF4GQx72K8BhZF5KWOfp99g3VZA=; b=mTaqygdOT7rxcKcSW6wmrSZ6shi+pbw4bfqXKpb55vnEcI7O37Ig6FXSS5IRfzyDYP UFppU3rv8yEEP1v8iv9gPA9+fQOHuGKIcTGhW7/VmCYCrfJWLPe+mb+RDL/d0zxi6qfc qVMjG7e7zFddjDE9BuguVa9nJX08TXbNd6UjhNzo1OSF2d55PM8ABocoCl4Y2X8A8MQ9 uE1ip4htUMy44K/ET4VoJrrriE0q/JG4O21VA+xGah72lYPGnoz5ErkLvzit/la3b1Tg j5a/lxOsDxuHjIB6k1U99mPqpQ8CCZR0uZ9TUyssDl8S3CzQxc9Ap0P4LbpRpveo9rYa oDig== X-Gm-Message-State: AOJu0YzZNalxFnHeORwh6JF1r6huvjUtw/x2Rvtvs7oweYwrLBOrKCD1 U5k2i6VM347oBEUpz3FBrpGEMwA+yYnXl07AUzjDKseIOJK2QIA0zwFZ X-Gm-Gg: AfdE7clNjL00CYpvuJya/Qb/091HZQyIA+XElspgMgFTz4AhlJpDJcx6IktEBkYy9p+ 3XMjAZTMZMvpWS0b5UzYQ6eB0ajP9SZJuWlP7zv3/FxWwhHPEljgwA9ipXber90MvnwDNSzveX/ I7qwP6oKCnYUcsvXLf52JxhnI5yUMjAM6mqNPbInBwZJ+odyYu+gvJEU21xwHgXr2EZ2gT5UzWp lWxOFeS2dNTO5cFzpd8K5xEuodVYilY97YsuPnMaIY/e4FDU4Y8Sg3wZ+rWnVxS5eW0NzG2gp4n 2C1Win4F/BGmESfPscMDEQFCUhvrcFXo+qa2znhEP7aAPOlff9CzHaimCPXnkEFAppHlil3y+oB U3M24yWuKtqbmYL/w1U8P63+53uGdUJg6pE3YkXdLsS6oNo0MD+qEZfMp0OQ9BSo57iKAbl4116 g0TCabauIjW0jz5Q/qdcH0kITfQWgMT4JtkXXlVD+J/7K7g8g= X-Received: by 2002:a17:90a:d40f:b0:36a:a16b:5f6d with SMTP id 98e67ed59e1d1-382807aa1b0mr7919304a91.7.1783330204267; Mon, 06 Jul 2026 02:30:04 -0700 (PDT) Received: from localhost ([2401:4900:884c:cd4b:ab7:fd3a:cfef:a052]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30f0b7b9a1bsm52592003eec.3.2026.07.06.02.30.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jul 2026 02:30:03 -0700 (PDT) From: Senthilnathan To: joe@perches.com Cc: linux-kernel@vger.kernel.org, Senthilnathan Subject: [PATCH v2] checkpatch: remove incorrect IIO_DEV_ATTR_ permission-arg rule Date: Mon, 6 Jul 2026 14:59:43 +0530 Message-Id: <20260706092943.390194-1-ssenthil1490@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit checkpatch's @mode_permission_funcs table assumes that for any macro matching IIO_DEV_ATTR_[A-Z_]+, the permission/mode value is always argument 1. This is incorrect: the IIO_DEV_ATTR_* macro family, defined in drivers/staging/iio/frequency/dds.h, does not share a consistent argument layout. For example: IIO_DEV_ATTR_FREQ(_channel, _num, _mode, _show, _store, _addr) IIO_DEV_ATTR_FREQSYMBOL(_channel, _mode, _show, _store, _addr) IIO_DEV_ATTR_OUTY_ENABLE(_channel, _output, _mode, _show, _store, _addr) In IIO_DEV_ATTR_FREQ the mode is argument 3, while in IIO_DEV_ATTR_FREQSYMBOL it is argument 2 -- there is no single argument index that is correct for the whole family. As a result, checkpatch.pl --file reports spurious NON_OCTAL_PERMISSIONS errors against drivers/staging/iio/frequency/ad9834.c and ad9832.c, flagging the _channel or _num argument (typically "0" or "1") as if it were a malformed permission value, even though the actual mode arguments (0200) are correctly formatted 4-digit octal values: $ ./scripts/checkpatch.pl --no-tree --file \ drivers/staging/iio/frequency/ad9834.c ERROR: Use 4 digit octal (0777) not decimal permissions #315: FILE: drivers/staging/iio/frequency/ad9834.c:315: +static IIO_DEV_ATTR_FREQ(0, 0, 0200, NULL, ad9834_write, AD9834_REG_FREQ0); [... 8 more identical false positives ...] Since no single fixed argument position is correct for every member of this macro family, remove the rule rather than leave it pointing at the wrong argument. The other entries in @mode_permission_funcs are unaffected, and a genuine decimal-permission misuse (e.g. DEVICE_ATTR(foo, 644, ...)) is still correctly flagged after this change. Signed-off-by: Senthilnathan --- v2: Resend -- v1 had a mangled Subject line and a duplicated diff caused by a commit-message formatting mistake. No code changes from v1. scripts/checkpatch.pl | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 2b7a42bbdd94..0c6f8b92f168 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -854,7 +854,6 @@ our @mode_permission_funcs = ( ["debugfs_create_(?:file|u8|u16|u32|u64|x8|x16|x32|x64|size_t|atomic_t|bool|blob|regset32|u32_array)", 2], ["proc_create(?:_data|)", 2], ["(?:CLASS|DEVICE|SENSOR|SENSOR_DEVICE|IIO_DEVICE)_ATTR", 2], - ["IIO_DEV_ATTR_[A-Z_]+", 1], ["SENSOR_(?:DEVICE_|)ATTR_2", 2], ["SENSOR_TEMPLATE(?:_2|)", 3], ["__ATTR", 2], -- 2.34.1