[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH 02/13] AMD/IOMMU: fixed violations of MISRA C:2012 Rule 7.2


  • To: Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 20 Jun 2023 14:39:56 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=AveoQ8cmZdJz2QeFEoXVf37UbdP2Go3jTrt1Zgj5rsI=; b=Qz3+KgstyfwWieEh3HVEkbFAZBCifZoDRkxpKkXvg6ROIk90/R1VeNzMh4MAWrx5EPUMRUmk8aQTxlj+hB2tMVMbZcPEtHudZ/xZwTCwVplNk1kZSaUMSA5cqUSVaiLeJKfScmjlrbn5X22l5c2YqrYoc6o6s13koLxBnQbk4PI2ocBKF9qGx7makMTIbtDSwYsjCpyAJEEA7TSkFUtkLBe5g5G8Q70SOeoNZDsv6SAuskii/penmjQJFct5nVhcyb6aW8HMuaAhDww+NKjLreMHMb4vFjAZG6rP4t88ILsFzlQ4bP13DtAfGnwli0BPimxXyP1ANLOpa87UEGp2sg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XQFCUYVvIKw0O3vaI1N4E9MzoG3UCnOKtZnZfqu/XY1LffX0hAwQKjTjv4NI/Repq99pu5zoaNbRJUvw5P5+iVzjJYH6nkDJITddPWnYskUqvwAi7/j87Ul+b/Q17fErsTQnexf6fnzLjoi+ok8LBc/arxBnDBuOMTI0lOWOa4t1IaVHjr6nCCsSp0GGXfOUKTFQ2C6X2Br+F5QMWBXolxxvJY7Z2FYJUtl4wL2ctC6xRjwpf56HL68J94KgF6rwDKcWBQn8nEuvQ2V56zZGYp0DDVUZ+b5Q11X3no73t3QGxsZXjmdTa3xjzeVfo/WhuP7l4bxukQf61Rue7J+vrw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: consulting@xxxxxxxxxxx, Gianluca Luparini <gianluca.luparini@xxxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Xenia Ragiadakou <Xenia.Ragiadakou@xxxxxxx>, Ayan Kumar <ayan.kumar.halder@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 20 Jun 2023 12:40:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 20.06.2023 12:34, Simone Ballarin wrote:
> --- a/xen/drivers/passthrough/amd/iommu-defs.h
> +++ b/xen/drivers/passthrough/amd/iommu-defs.h
> @@ -38,49 +38,49 @@
>          ((uint64_t)(offset) << (12 + (PTE_PER_TABLE_SHIFT * ((level) - 1))))
>  
>  /* IOMMU Capability */
> -#define PCI_CAP_ID_MASK              0x000000FF
> +#define PCI_CAP_ID_MASK              0x000000FFU

Seeing this and similar uses further down, I think there's a purely
stylistic question to be resolved first (and hence I'm widening the To:
list here): Do we want to allow either case of U to be used
interchangeably, leaving the choice up to the patch author?

Personally at least for hex numbers I'd prefer the suffix to stand out: If
the digits use upper case, have the suffix be lower case and vice versa.
(If there are only numbers, then surrounding context would need
consulting.) I realize though that this will not fit well with the desire
of avoiding lower-case l in number suffixes; it would be fine for e.g.
0xFFul. Not sure in how many cases this would matter though, as I expect
most constants want to be unsigned.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.