> (whitespace damaged; more for comment than for application).
>
> > -if ((u32)skb->data & 3) {
> > +if ((unsigned long)skb->data & 3) {
>
> I suppose it quietens a compiler warning. Doesn't actually fix a bug
> though.
Right but it does no harm casting it to either so its worth
On Mon, Oct 02, 2006 at 04:12:35PM +0100, Alan Cox wrote:
> @@ -1423,14 +1418,15 @@
> printk(KERN_ERR DEV_LABEL "can't allocate DLEs\n");
> goto err_out;
> }
> - iadev->rx_dle_q.start = (struct dle*)dle_addr;
> + iadev->rx_dle_q.start = (struct dle *)dle_
Ar Llu, 2006-10-02 am 09:52 -0400, ysgrifennodd chas williams -
CONTRACTOR:
> some of the drivers in atm are already marked with !64BIT and some
> need to be marked. this might be more complete for drivers/atm/Kconfig:
This should fix Iphase for one. Some of the others look a lot harder
however
Hello,
Jeff Garzik wrote:
Andi Kleen wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
Add a broken-on-64bit option, similar to the existing broken-on-smp
config option. This is just the first pass, marking the obvious
candidates.
When I had this problem in the past I just used && !64BIT.
How i
Ar Llu, 2006-10-02 am 00:55 -0400, ysgrifennodd Jeff Garzik:
> Add a broken-on-64bit option, similar to the existing broken-on-smp
> config option. This is just the first pass, marking the obvious
> candidates.
NAK. This contains lots of stuff whcih isn't broken in the first place.
(Eg Megaraid
In message <[EMAIL PROTECTED]>,Jeff Garzik writes:
>Several driver have been marked as dependent on CONFIG_32BIT in the
>past, when they should really be dependent on this new
>CONFIG_BROKEN_ON_64BIT option, because the 32BIT marker was due to bugs
>rather than fundamentals.
some of the drivers in
Andi Kleen wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
Add a broken-on-64bit option, similar to the existing broken-on-smp
config option. This is just the first pass, marking the obvious
candidates.
When I had this problem in the past I just used && !64BIT.
How is this new option differen
Jeff Garzik <[EMAIL PROTECTED]> writes:
> Add a broken-on-64bit option, similar to the existing broken-on-smp
> config option. This is just the first pass, marking the obvious
> candidates.
When I had this problem in the past I just used && !64BIT.
How is this new option different?
> config ISD
Add a broken-on-64bit option, similar to the existing broken-on-smp
config option. This is just the first pass, marking the obvious
candidates.
Several driver have been marked as dependent on CONFIG_32BIT in the
past, when they should really be dependent on this new
CONFIG_BROKEN_ON_64BIT option
