summaryrefslogtreecommitdiffstats
path: root/drivers/net/ibm_newemac/mal.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ehea/ibm*: Move the IBM driversJeff Kirsher2011-08-111-316/+0
| | | | | | | | | | | | | | | | | | | Move the IBM drivers into drivers/net/ethernet/ibm/ and make the necessary Kconfig and Makefile changes. - Renamed ibm_new_emac to emac - Cleaned up Makefile and Kconfig options which referred to IBM_NEW_EMAC to IBM_EMAC - ibmlana driver is a National Semiconductor SONIC driver so it was not moved CC: Christoph Raisch <raisch@de.ibm.com> CC: Santiago Leon <santil@linux.vnet.ibm.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: David Gibson <dwg@au1.ibm.com> CC: Kyle Lucke <klucke@us.ibm.com> CC: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* of/device: Replace struct of_device with struct platform_deviceGrant Likely2010-08-061-1/+1
| | | | | | | | | | | | | | | | of_device is just an alias for platform_device, so remove it entirely. Also replace to_of_device() with to_platform_device() and update comment blocks. This patch was initially generated from the following semantic patch, and then edited by hand to pick up the bits that coccinelle didn't catch. @@ @@ -struct of_device +struct platform_device Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Reviewed-by: David S. Miller <davem@davemloft.net>
* net: Add init_dummy_netdev() and fix EMAC driver using itBenjamin Herrenschmidt2009-01-151-0/+2
| | | | | | | | | | | | | | | | | | | This adds an init_dummy_netdev() function that gets a network device structure (allocation and lifetime entirely under caller's control) and initialize the minimum amount of fields so it can be used to schedule NAPI polls without registering a full blown interface. This is to be used by drivers that need to tie several hardware interfaces to a single NAPI poll scheduler due to HW limitations. It also updates the ibm_newemac driver to use that, this fixing the oops on 2.6.29 due to passing NULL as "dev" to netif_napi_add() Symbol is exported GPL only a I don't think we want binary drivers doing that sort of acrobatics (if we want them at all). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge commit 'origin'Benjamin Herrenschmidt2008-10-151-2/+2
|\ | | | | | | | | | | Manual fixup of conflicts on: arch/powerpc/include/asm/dcr-regs.h drivers/net/ibm_newemac/core.h
| * ibm_newemac: MAL[12]_IER_EVENTS definition: 2x *_OTE -> *_DEroel kluin2008-09-031-2/+2
| | | | | | | | | | | | | | | | MAL[12]_IER_EVENTS definitions have MAL_IER_OTE twice but lack MAL_IER_DE Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* | ibm_newemac: Introduce mal_has_featureJosh Boyer2008-09-301-0/+34
|/ | | | | | | | | | | | | | | | | | | | | | There are some PowerPC SoCs that do odd things with the MAL handling. In order to accommodate them, we need to introduce a feature mechanism that is similar to the existing emac_has_feature function. This adds a feature variable to the mal_instance structure, and adds a mal_has_feature function. Two features are defined and are guarded by Kconfig options that are selected by the affected platforms. MAL_FTR_CLEAR_ICINSTAT is used for platforms that need to clear the interrupt bits in the ICINTSTAT SDR for txeob/rxeob. This is common on MAL implementations that have interrupt coalescing. MAL_FTR_COMMON_ERR_INT is used for platforms that have SERR, TXDE, and RXDE OR'd into a single interrupt bit. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
* ibm_newemac: Update file headers copyright noticesBenjamin Herrenschmidt2007-12-071-0/+5
| | | | | | | | This updates the copyright notices of the new EMAC driver to avoid confusion as who is to be blamed for new bugs. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* Add dcr_host_t.base in dcr_read()/dcr_write()Michael Ellerman2007-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Update ibm_newemac to use dcr_host_t.baseMichael Ellerman2007-10-151-3/+2
| | | | | | | | 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>
* ibm_emac: Convert to use napi_struct independent of struct net_deviceRoland Dreier2007-10-111-1/+1
| | | | | | | | | | | | | | | 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>
* Device tree aware EMAC driverDavid Gibson2007-10-111-0/+276
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>