netdev - Re: [PATCH v2.6.26] gianfar: Determine TBIPA value dynamically

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:	Fri, 11 Apr 2008 14:06:07 -0500
From:	Andy Fleming <afleming@...escale.com>
To:	Scott Wood <scottwood@...escale.com>
Cc:	netdev@...r.kernel.org, paul.gortmaker@...driver.com,
	linuxppc-dev@...abs.org
Subject: Re: [PATCH v2.6.26] gianfar: Determine TBIPA value dynamically

On Apr 11, 2008, at 10:31, Scott Wood wrote:

> On Thu, Apr 10, 2008 at 06:34:31PM -0500, Andy Fleming wrote:
>>
>> +	/*
>> +	 * This is mildly evil, but so is our hardware for doing this.
>> +	 * Also, we have to cast back to struct gfar_mii because of
>> +	 * definition weirdness done in gianfar.h.
>> +	 */
>> +	enet_regs = (struct gfar __iomem *)
>> +		((char *)regs - offsetof(struct gfar, gfar_mii_regs));
>
> Can we use to_container() here?

I tried.  Technically, we can.  But the issue is that struct gfar  
*enet_regs->gfar_mii_regs is declared:

u8 gfar_mii_regs[24];

I could not find any sequence of castings that made the warning go  
away about casting that to a struct gfar_mii __iomem *.  And that  
includes mucking around with the declaration of gfar_mii_regs.  I  
vaguely recall determining that you couldn't make it a struct, because  
you can't guarantee gcc won't much with the size of the struct.  Or  
something.  Suffice it to say, this worked, and wasn't much wordier.   
But I really did spend a couple hours banging my head against sparse  
trying to get the pointers to agree.

Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html