linux-kernel - Re: [PATCH] pinctrl: tegra: use signed bitfields for optional fields

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Mar 2015 10:59:44 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Stefan Agner <stefan@...er.ch>
CC:	linus.walleij@...aro.org, thierry.reding@...il.com,
	gnurou@...il.com, linux-gpio@...r.kernel.org,
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: tegra: use signed bitfields for optional fields

On 03/14/2015 06:05 PM, Stefan Agner wrote:
> Optional fields are set to -1 by various preprocessor macros. Make
> sure the struct fields can actually store them.

> diff --git a/drivers/pinctrl/pinctrl-tegra.h b/drivers/pinctrl/pinctrl-tegra.h

> -	u32 mux_bit:6;
> -	u32 pupd_bit:6;
> -	u32 tri_bit:6;
...
> +	s8 mux_bit:6;
> +	s8 pupd_bit:6;
> +	s8 tri_bit:6;

Could we make these s32s instead? According to the C standard, the type 
should be a signed or unsigned int, and s32 matches that better than s8 
for existing Tegra 32-bit platforms. Equally, for bitfields that don't 
fit into the remaining space within a container (s8 above), 
implementations are allowed to either span bitfields across multiple 
containers, or pad the current container and start the bitfield in the 
next container. Using the larger s32 as the "container" yields less 
opportunity for potential padding and thus wasting space.

Do you observe any increase in the sizes reported by 
"${CROSS_COMPILE}size pinctrl-tegra*.o" with this patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/