aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/ibm_newemac
AgeCommit message (Collapse)Author
2007-10-17fix EMAC driver for proper napi_synchronize APIBenjamin Herrenschmidt
The EMAC driver "fix" was merged by mistake before the dust had settled on the new napi synchronize interface (and before it got merged). The final version of that function is spelled without underscores. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-16net: Fix new EMAC driver for NAPI changesBenjamin Herrenschmidt
net: Fix new EMAC driver for NAPI changes This fixes the new EMAC driver for the NAPI updates. The previous patch by Roland Dreier (already applied) to do that doesn't actually work. This applies on top of it makes it work on my test Ebony machine. This patch depends on "net: Add __napi_sycnhronize() to sync with napi poll" posted previously. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15Use dcr_host_t.base in dcr_unmap()Michael Ellerman
With the base stored in dcr_host_t, there's no need for callers to pass the dcr_n into dcr_unmap(). In fact this removes the possibility of them passing the incorrect value, which would then be iounmap()'ed. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15Add dcr_host_t.base in dcr_read()/dcr_write()Michael Ellerman
Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we can save them the trouble and do it in dcr_read()/dcr_write(). As some background to why we just went through all this jiggery-pokery, benh sayeth: Initially the goal of the dcr_read/dcr_write routines was to operate like mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx hardware, indirect DCR access is a pain (goes through a table of instructions) and it's useful to have the compiler resolve an absolute DCR inline. We decided that wasn't worth the API bastardisation since most places where absolute DCR values are used are low level 4xx-only code which may as well continue using mfdcr/mtdcr, while the new API is designed for device "instances" that can exist on 4xx and Axon type platforms and may be located at variable DCR offsets. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15Update ibm_newemac to use dcr_host_t.baseMichael Ellerman
Now that dcr_host_t contains the base address, we can use that in the ibm_newemac code, rather than storing it separately. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-14ibm_newemac annotations (iomem, NULL noise)Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-14skb->tail in ibm_newemac should be skb_tail_pointer()Al Viro
... since that sucker is not 32bit-only and on 64bit skb->tail is an offset, not a pointer. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-14typo in ibm_newemac/rgmii.cAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-10ibm_emac: Convert to use napi_struct independent of struct net_deviceRoland Dreier
Commit da3dedd9 ("[NET]: Make NAPI polling independent of struct net_device objects.") changed the interface to NAPI polling. Fix up the ibm_newemac driver so that it works with this new interface. This is actually a nice cleanup because ibm_newemac is one of the drivers that wants to have multiple NAPI structures for a single net_device. Compile-tested only as I don't have a system that uses the ibm_newemac driver. This conversion the conversion for the ibm_emac driver that was tested on real PowerPC 440SPe hardware. Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-10ibm_new_emac: Nuke SET_MODULE_OWNER() useRoland Dreier
Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-10Fix typo in new EMAC driver.vbarshak@ru.mvista.com
Fix an obvious typo in emac_xmit_finish. Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-10Device tree aware EMAC driverDavid Gibson
Based on BenH's earlier work, this is a new version of the EMAC driver for the built-in ethernet found on PowerPC 4xx embedded CPUs. The same ASIC is also found in the Axon bridge chip. This new version is designed to work in the arch/powerpc tree, using the device tree to probe the device, rather than the old and ugly arch/ppc OCP layer. This driver is designed to sit alongside the old driver (that lies in drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The old driver is left in place to support arch/ppc until arch/ppc itself reaches its final demise (not too long now, with luck). This driver still has a number of things that could do with cleaning up, but I think they can be fixed up after merging. Specifically: - Should be adjusted to properly use the dma mapping API. Axon needs this. - Probe logic needs reworking, in conjuction with the general probing code for of_platform devices. The dependencies here between EMAC, MAL, ZMII etc. make this complicated. At present, it usually works, because we initialize and register the sub-drivers before the EMAC driver itself, and (being in driver code) runs after the devices themselves have been instantiated from the device tree. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>