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]
Message-ID: <55070C00.5040804@wwwdotorg.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ