On Wed, Jun 13, 2012 at 7:00 AM, Takuya Yoshikawa
[off-list ref] wrote:

On Wed, 13 Jun 2012 22:31:13 +0900
Akinobu Mita [off-list ref] wrote:

quoted

quoted

quoted

Should this hash_table be converted from u16 hash_table[32] to
DECLARE_BITMAP(hash_table, 16 * 32) to ensure that it is aligned
on long-word boundary?

I think hash_table is already long-word aligned because it is placed
right after a pointer.

I recommend converting to proper bitmap.  Because such an implicit
assumption is easily broken by someone touching this function.

Do you mean something like:
       DECLARE_BITMAP(__hash_table, 16 * 32);
       u16 *hash_table = (u16 *)__hash_table;
?

Grant, what do you think about this?

Hi Takuya,
two thoughts:
1) while I agree with Akinobu and thank him for pointing out a
_potential_ alignment problem, this is a separate issue and your
existing patch should go in anyway. There are probably other drivers
with _potential_ alignment issues. Akinobu could get credit for
finding them by submitting patches after reviewing calls to set_bit
and set_bit_le() - similar to what you are doing now.

2) I generally do not like declaring one type and then using an alias
of a different type to reference the same memory address. We have a
simple alternative since hash_table[] is indexed directly only in one
hunk of code:
        for (i = 0; i < 32; i++) {
                *setup_frm++ = ((u16 *)hash_table)[i];
                *setup_frm++ = ((u16 *)hash_table)[i];
        }

thanks,
grant

       Takuya


===
drivers/net/ethernet/dec/tulip/tulip_core.c:

static void build_setup_frame_hash(u16 *setup_frm, struct net_device *dev)
{
       struct tulip_private *tp = netdev_priv(dev);
       u16 hash_table[32];
       ...
}

drivers/net/ethernet/dec/tulip/de2104x.c:

static void build_setup_frame_hash(u16 *setup_frm, struct net_device *dev)
{
       struct de_private *de = netdev_priv(dev);
       u16 hash_table[32];
       ...
}