From: Mauro Carvalho Chehab Date: Mon, 19 Sep 2016 11:07:47 +0000 (-0300) Subject: Documentation/CodingStyle: use the .. note:: markup where needed X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=3772ec4adfcd5b2ce8829c4a5fbd24411aa67e68;p=GitHub%2FLineageOS%2Fandroid_kernel_motorola_exynos9610.git Documentation/CodingStyle: use the .. note:: markup where needed There are two places there where there are notes that should be highlighted. So, use the ReST note markup for such texts. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet --- diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 0024c36b8046..7e30da38bb3a 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -333,9 +333,11 @@ useful only for: Example: ``pte_t`` etc. opaque objects that you can only access using the proper accessor functions. - NOTE! Opaqueness and ``accessor functions`` are not good in themselves. - The reason we have them for things like pte_t etc. is that there - really is absolutely **zero** portably accessible information there. + .. note:: + + Opaqueness and ``accessor functions`` are not good in themselves. + The reason we have them for things like pte_t etc. is that there + really is absolutely **zero** portably accessible information there. (b) Clear integer types, where the abstraction **helps** avoid confusion whether it is ``int`` or ``long``. @@ -343,8 +345,10 @@ useful only for: u8/u16/u32 are perfectly fine typedefs, although they fit into category (d) better than here. - NOTE! Again - there needs to be a **reason** for this. If something is - ``unsigned long``, then there's no reason to do + .. note:: + + Again - there needs to be a **reason** for this. If something is + ``unsigned long``, then there's no reason to do typedef unsigned long myflags_t;