summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/renesas/ravb_main.c
AgeCommit message (Collapse)Author
2015-11-02ravb: use pdev rather than ndev for error messagesSimon Horman
This corrects what appear to be typos, making the code consistent with itself, and allowing meaningful prefixes to be displayed with the errors in question. Before: (null): failed to initialize MDIO (null): Cannot allocate desc base address table (size 176 bytes) After: ravb e6800000.ethernet: failed to initialize MDIO ravb e6800000.ethernet: Cannot allocate desc base address table (size 176 bytes) Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-03ravb: Add support for r8a7795 SoCKazuya Mizuguchi
This patch supports the r8a7795 SoC by: - Using two interrupts + One for E-MAC + One for everything else + Both can be handled by the existing common interrupt handler, which affords a simpler update to support the new SoC. In future some consideration may be given to implementing multiple interrupt handlers - Limiting the phy speed to 100Mbit/s for the new SoC; at this time it is not clear how this restriction may be lifted but I hope it will be possible as more information comes to light Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> [horms: reworked] Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-10-03ravb: Provide dev parameter to DMA APIKazuya Mizuguchi
This patch is in preparation for using this driver on arm64 where the implementation of __dma_alloc_coherent fails if a device parameter is not provided. Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com> [horms: squashed into a single patch] Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
2015-08-28ravb: propagate platform_get_irq() error upstreamSergei Shtylyov
The driver overrides the error returned by platform_get_irq() with -ENODEV which e.g. precludes the deferred probing from working. Propagate the real error code to the driver core instead. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-27ravb: minimize TX data copyingSergei Shtylyov
Renesas Ethernet AVB controller requires that all data are aligned on 4-byte boundary. While it's easily achievable for the RX data with the help of skb_reserve() (we even align on 128-byte boundary as recommended by the manual), we can't do the same with the TX data, and it always comes unaligned from the networking core. Originally we solved it an easy way, copying all packet to a preallocated aligned buffer; however, it's enough to copy only up to 3 first bytes from each packet, doing the transfer using 2 TX descriptors instead of just 1. Here's an implementation of the new TX algorithm that significantly reduces the driver's memory requirements. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Conflicts: net/bridge/br_mdb.c br_mdb.c conflict was a function call being removed to fix a bug in 'net' but whose signature was changed in 'net-next'. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-21ravb: fix ring memory allocationSergei Shtylyov
The driver is written as if it can adapt to a low memory situation allocating less RX skbs and TX aligned buffers than the respective RX/TX ring sizes. In reality though the driver would malfunction in this case. Stop being overly smart and just fail in such situation -- this is achieved by moving the memory allocation from ravb_ring_format() to ravb_ring_init(). We leave dma_map_single() calls in place but make their failure non-fatal by marking the corresponding RX descriptors with zero data size which should prevent DMA to an invalid addresses. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-20ravb: fix race updating TCCRSergei Shtylyov
The TCCR.TSRQn bit may get clearead after TCCR gets read, so that TCCR write would get skipped. We don't need to check this bit before setting. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-17ravb: do not invalidate cache for RX buffer twiceSergei Shtylyov
First, dma_sync_single_for_cpu() shouldn't have been called in the first place (it's a streaming DMA API), dma_unmap_single() should have been called instead. Second, dma_unmap_single() call after handing the buffer to napi_gro_receive() makes little sense. Moreover desc->dptr might not be valid at this point. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-14ravb: kill useless initializersSergei Shtylyov
Some of the local variable intializers in the driver turned out to be pointless, kill them. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-06-11Renesas Ethernet AVB PTP clock driverSergei Shtylyov
Ethernet AVB device includes the gPTP timer, so we can implement a PTP clock driver. We're doing that in a separate file, with the main Ethernet driver calling the PTP driver's [de]initialization and interrupt handler functions. Unfortunately, the clock seems tightly coupled with the AVB-DMAC, so when that one leaves the operation mode, we have to unregister the PTP clock... :-( Based on the original patches by Masaru Nagai. Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>