into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

The following patch allows hw_random.c to build on ia64.  (The problem
was just that the VIA stuff has i386 assembly in it.  The current code
only probes for VIA on i386 anyway, so this patch just adds more ifdefs
so the VIA code is only built for i386.)

into ppc970.osdl.org:/home/torvalds/v2.6/linux

My tulip ethernet card doesn't work on Blue&White G3 PowerMac with Linux
2.6.5-rc2.  The card is shown by lspci as

01:03.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet
10/100 model NC100 (rev 11)

The kernel detects it as "ADMtek Comet rev 17".

The MAC address reported by the kernel looked obviously wrong.  Also, I
could only ping the system successfully if the interface was in promiscuous
mode (running Ethereal).

Those two symptoms indicated two different problems - one for reading the
MAC address from the card on module load (tulip_init_one), and the other
for writing the address to the card when the interface was brought up
(tulip_up).  I have fixed both, and here's the explanation:

tulip_init_one:

When reading the first 4 bytes of the address, inl() returns the same data
to the CPU on all platforms, interpreting the data from the lowest port
address as the least significant byte.  In other words, I/O is little
endian on all platforms; it's the memory that differs across platforms.
We want to write the data to memory preserving little-endianness of the
PCI bus.  To force little endian write to the memory, the data should be
converted to the little endian format.

When reading the remaining 2 bytes, the CPU gets them in 2 least
significant bytes.  To write those 2 bytes to the memory in a 16-bit
operation, they should be byte-swapped for the 16-bit operation.

tulip_up:

The first 4 bytes are processed correctly, but the code is confusing.
Reading from memory needs conversion to CPU format, while writing to I/O
ports doesn't.  So I replaced cpu_to_le32() to le32_to_cpu().

The second 2 bytes are read in a 16-bit memory operation, so they should
be passed to le16_to_cpu() rather than cpu_to_le32() to make them CPU
independent and suitable for outl().


All those conversions do nothing on little-endian machines, so they should
not be affected.

The patch has been tested.  The driver is working fine.  ping is OK, ssh
is OK, X11 over ssh is OK.  Even netconsole is working fine.

On Wednesday 24 March 2004 23:25, Jeff Garzik wrote:
> Daniel Ritz wrote:
> > clean up the last two instances of dev->priv in drivers/net/pcmcia.
> > against 2.6.5-rc2-bk.
> >
> > --- 1.27/drivers/net/pcmcia/3c589_cs.c	Wed Mar  3 01:03:51 2004
> > +++ edited/drivers/net/pcmcia/3c589_cs.c	Wed Mar 24 22:29:35 2004
> > @@ -716,7 +716,7 @@
> >  	  "status %4.4x.\n", dev->name, (long)skb->len,
> >  	  inw(ioaddr + EL3_STATUS));
> >
> > -    ((struct el3_private *)dev->priv)->stats.tx_bytes += skb->len;
> > +    ((struct el3_private *)netdev_priv(dev))->stats.tx_bytes += skb->len;
> >
> >      /* Put out the doubleword header... */
> >      outw(skb->len, ioaddr + TX_FIFO);
> > --- 1.24/drivers/net/pcmcia/ibmtr_cs.c	Wed Mar  3 01:06:03 2004
> > +++ edited/drivers/net/pcmcia/ibmtr_cs.c	Wed Mar 24 22:29:51 2004
> > @@ -444,7 +444,7 @@
> >          link->state &= ~DEV_PRESENT;
> >          if (link->state & DEV_CONFIG) {
> >  	    /* set flag to bypass normal interrupt code */
> > -	    ((struct tok_info *)dev->priv)->sram_virt |= 1;
> > +	    ((struct tok_info *)netdev_priv(dev))->sram_virt |= 1;
> >  	    netif_device_detach(dev);
> >  	    ibmtr_release(link);
>
>
> although the patch is OK, the code itself is a bit yucky.
>
> Can you please create a temporary variable, of struct el3_private or
> tok_info type, and eliminate that cast?
>
> struct el3_private *priv = netdev_priv(dev);
> priv->stats.tx_bytes += skb->len;
>
> Much nicer :)
>

agreed. here we go...

Used for sysfs support.

Please apply the following patch to 2.6.5-rc2-bk9 and 2.4.26-rc1 to
include support for the 79C976. Tested on IA32.

On Wed, 31 Mar 2004 15:05:16 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> I really should remove the ability to configure 8139_RXBUF_IDX=3.

On Tue, Apr 13, 2004 at 02:35:40PM -0400, Jeff Garzik wrote:
> Russell,
>
> Would you be willing to provide an updated diff of this?

I didn't particularly like the PRIV() method implemented previously -
gcc appears to want to avoid some optimisations it if its an inline
function rather than a macro.

Also, 'ei_local' may look unused in some functions, but it's your
typical hidden-use-in-a-macro crap which 8390 likes.

In systems with mixed network cards, and all drivers compiled into
the kernel; the PCI device (eth0) will get probed first, before the ISA.

The problem is that the ISA device can mistakenly try to probe
for eth0.  The problem is that the ISA driver will not detect the failure
until it goes to call register_netdevice, and not all drivers have
perfect error unwind code.

This patch short circuits the device probe, so it won't bother
looking for devices that already are registered.

* Ken Ashcraft (ken@coverity.com) wrote:
> [BUG]
> /home/kash/linux/linux-2.6.5/drivers/net/e1000/e1000_ethtool.c:1494:e1000_ethtool_ioctl: ERROR:TAINT: 1487:1494:Passing unbounded user value "(regs).len" as arg 2 to function "copy_to_user", which uses it unsafely in model [SOURCE_MODEL=(lib,copy_from_user,user,taintscalar)] [SINK_MODEL=(lib,copy_to_user,user,trustingsink)]    [PATH=]
> 	}
> 	case ETHTOOL_GREGS: {
> 		struct ethtool_regs regs = {ETHTOOL_GREGS};
> 		uint32_t regs_buff[E1000_REGS_LEN];
>
> Start --->
> 		if(copy_from_user(&regs, addr, sizeof(regs)))
> 			return -EFAULT;
> 		e1000_ethtool_gregs(adapter, &regs, regs_buff);
> 		if(copy_to_user(addr, &regs, sizeof(regs)))
> 			return -EFAULT;
>
> 		addr += offsetof(struct ethtool_regs, data);
> Error --->
> 		if(copy_to_user(addr, regs_buff, regs.len))
> 			return -EFAULT;
>
> 		return 0;

Looks like a bug.  Possible patch below zeros the buffer (since it's not
filled completely by e1000_ethtool_gregs()), and truncates len.

I get the following warning in 2.6.5-mm6 and 2.6.6-rc1:

<--  snip  -->

...
  CC      drivers/net/tulip/timer.o
drivers/net/tulip/timer.c: In function `comet_timer':
drivers/net/tulip/timer.c:156: warning: unused variable `ioaddr'
...

<--  snip  -->


Since the
   [netdrvr tulip] add MII support for Comet chips
patch has removed the only use of this variable, the fix is simple:

They are now upstream, we don't need driver-local ones anymore.

Tangentially noticed by Stanford checker.

Trivial patchlet...ethtool core already caps regs.len at a max of
->get_regs_len():

	reglen = ops->get_regs_len(dev);
	if (regs.len > reglen)
		regs.len = reglen;

So doing the same in the in de2104x driver ->get_regs() is redundant.
Patch below simply removes it to clarify the guarantee of the API.

> [BUG] minor
> /home/kash/linux/linux-2.6.5/drivers/net/wan/sdla.c:1206:sdla_xfer:
> ERROR:TAINT: 1201:1206:Passing unbounded user value "(mem).len" as arg 0
> to function "kmalloc", which uses it unsafely in model
> [SOURCE_MODEL=(lib,copy_from_user,user,taintscalar)]
> [SINK_MODEL=(lib,kmalloc,user,trustingsink)]  [MINOR]  [PATH=] [Also
> used at, line 1219 in argument 0 to function "kmalloc"]
> static int sdla_xfer(struct net_device *dev, struct sdla_mem *info, int
> read)
> {
> 	struct sdla_mem mem;
> 	char	*temp;
>
> Start --->
> 	if(copy_from_user(&mem, info, sizeof(mem)))
> 		return -EFAULT;
>
> 	if (read)
> 	{
> Error --->
> 		temp = kmalloc(mem.len, GFP_KERNEL);
> 		if (!temp)
> 			return(-ENOMEM);
> 		sdla_read(dev, mem.addr, temp, mem.len);

Hrm, I believe you could use this to read 128k of kernel memory.
sdla_read() takes len as a short, whereas mem.len is an int.  So,
if mem.len == 0x20000, the allocation could still succeed.  When cast
to short, len will be 0x0, causing the read loop to copy nothing into
the buffer.  At least it's protected by a capable() check.  I don't
know what proper upper bound is for this hardware, or how much it's
used/cared about.  Simple memset() is trivial fix.

Caught by Stanford checker.

If __ISAPNP__ and CONFIG_X86_PC9800 are not set, we forget to link the device
into the global chain and el3_init_module dereferences NULL.

small cosmetic fix for powermac mace network driver.

eth%d: MACE at 00:05:02:f4:1b:1d, chip revision 25.64
vs.
eth0: MACE at 00:05:02:f4:1b:1d, chip revision 25.64

into ppc970.osdl.org:/home/torvalds/v2.6/linux

From: Rusty Russell <rusty@rustcorp.com.au>

From: Pavel Roskin <proski@gnu.org>

If you use both module_param (new) and MODULE_PARM (obsolete) in a module,
only the second gets recognised.  Warn.

nfs token table can be  __initdata

From: William Lee Irwin III <wli@holomorphy.com>

The stack is now shared with struct thread_info on most arches, not task_t.
This mostly affects get_wchan() and stack usage debug.

From: William Lee Irwin III <wli@holomorphy.com>

The stack is now shared with struct thread_info on most arches, not task_t.
This mostly affects get_wchan() and stack usage debug.

From: William Lee Irwin III <wli@holomorphy.com>

The stack is now shared with struct thread_info on most arches, not task_t.
This mostly affects get_wchan() and stack usage debug.

From: William Lee Irwin III <wli@holomorphy.com>

The stack is now shared with struct thread_info on most arches, not task_t.
This mostly affects get_wchan() and stack usage debug.

From: William Lee Irwin III <wli@holomorphy.com>

The stack is now shared with struct thread_info on most arches, not task_t.
This mostly affects get_wchan() and stack usage debug.

hugepage_vma() is both misleadingly named and unnecessary.  On most archs it
always returns NULL, and on IA64 the vma it returns is never used.  The
function's real purpose is to determine whether the address it is passed is a
special hugepage address which must be looked up in hugepage pagetables,
rather than being looked up in the normal pagetables (which might have
specially marked hugepage PMDs or PTEs).

This patch kills off hugepage_vma() and folds the logic it really needs into
follow_huge_addr().  That now returns a (page *) if called on a special
hugepage address, and an error encoded with ERR_PTR otherwise.  This also
requires tweaking the IA64 code to check that the hugepage PTE is present in
follow_huge_addr() - previously this was guaranteed, since it was only called
if the address was in an existing hugepage VMA, and hugepages are always
prefaulted.

From: Bart Samwel <bart@samwel.tk>

The reiserfs patch that adds support for "commit=0" saves the default max
commit age in a variable when the fs is originally mounted, so that it can
later restore it.  Unfortunately it makes some mistakes with that:

- The default is not saved when the original mount has a commit=NNN option.

- The default is not correctly saved for older reiserfs filesystems, where
  the default was not stored on disk.

This patch fixes these mistakes.

From: me, Badari Pulavarty <pbadari@us.ibm.com>

Currently a direct-IO read or write of more than 2G on 64-bit machines is
broken.  Replace int with ssize_t in various places to fix that up.

From: Nathan Lynch <nathanl@austin.ibm.com>

On some larger ppc64 configurations /proc/device-tree is exhausting procfs'
dynamic (non-pid) inode range (16K).  This patch makes the dynamic inode
range 0xf0000000-0xffffffff and changes the inode number allocator to use
the idr.c allocator for the first-fit allocations.

From: Chris Wright <chrisw@osdl.org>

Make sure to return proper retval on unshare_files() error in load_elf_binary.

Error noted by Kirill Korotaev <kirillx@7ka.mipt.ru>.

From: Jim Houston <jim.houston@comcast.net>

- Adds idr_get_new_above(), whihc permits us to do a first-fit search
  from a specified offset rather than always from zero.

- Add IDR_INIT() DEFINE_IDR() constructors.  Often idr's are singletons
  and having to cook up an initcall for them is a pain.

This is needed by the "Increase number of dynamic inodes in procfs" patch.

From: Nigel Cunningham <ncunningham@users.sourceforge.net>

A few weeks ago, Pavel and I agreed that PF_IOTHREAD should be renamed to
PF_NOFREEZE.  This reflects the fact that some threads so marked aren't
actually used for IO while suspending, but simply shouldn't be frozen.
This patch, against 2.6.5 vanilla, applies that change.  In the
refrigerator calls, the actual value doesn't matter (so long as it's
non-zero) and it makes more sense to use PF_FREEZE so I've used that.