[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: Jan Beulich <jbeulich@xxxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Tue, 20 Jun 2023 20:08:16 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=Dw99xWogjdWBedewA/C/J9H/djM3wdn7pVa0v5ebsBQ=; b=Y0YdcOhbqfDy87Axl8EacapuJCEQcF6KRX3h58UDikyGO3GLSUkpygAcl0Q/DvNsMV+pyorVVep8DNNiBLvtpYbgvorQy8Ds3RTtBxYT8OhE7UP02HBZzeYSyqA/5BosZ2dslbBktgCX0NKv/uoxjDOc0qnMNPWFWZFozhCHuHO3KZ+Y8TQAOz4kUIZt38NsSz56EDW8e/tHKfw80GjbO8wccJxcTRsG669KVusNO49HKElfip00tEM96wEXF48/D98X2ZJ16oLoAK5EPh+Gjyvl1G+uKer7gON/onRJrtXllKDpBxXvyoxyec3BPtmvLzkyKu0Uy4LmUZHzP6s5mw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LPoNHG6SVAFv3A+ULji3/WRZHxQ5fHT0qYW31ed8PfSzhmdJnaPjy7m9DvctU4d8i9d8yO2l4t3VHrqSstd9sy7+1j/iAdBWTlrLF9bXmncq/TJxgpRWw0Wm8tDHQ9oBiwQA8xNtgwC9kTql6Am3dnoworFAOka44DkC7Bc7V9F538feYN5YEX+kFcrny5Pe+PMuqKK+XWux1nMkMX8oxc6SPKHMQUt6Mr1PZWB+d/He7i4vHgpHDBh2OCIDCED6P6AIEi21zN43rhtUIaK2QN57CNjodrIjvIAyFCG5qx3KR8P5hWEE/ZD/z9P7u+9LTtQheCJzJ9ndVCct40B4Qg==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: 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>, "consulting@xxxxxxxxxxx" <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" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 20 Jun 2023 20:08:36 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Thread-index: AQHZo2afksvNjPDPpkuuVAXSvearq6+TodUAgAB9NwA=
- Thread-topic: [XEN PATCH 02/13] AMD/IOMMU: fixed violations of MISRA C:2012 Rule 7.2
> On 20 Jun 2023, at 13:39, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> 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?
Because you ask to the list, my personal opinion is that we might want to
have only capital U, so that it’s consistent across the codebase and we don’t
need to create too many rules for the developer, it stands out anyway as it
can’t
be an hex digit, also maybe every hex constant is nicer to have with all
capital,
but this is another subject.
Said that, clearly it’s up to the maintainers to choose.
>
> 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
>
|
