[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100903112248Q.fujita.tomonori@lab.ntt.co.jp>
Date: Fri, 3 Sep 2010 11:23:53 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: masa-korg@....okisemi.com
Cc: shemminger@...tta.com, sam@...nborg.org, joe@...ches.com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
gregory.v.rose@...el.com, mbizon@...ebox.fr,
kristoffer@...sler.com, ralf@...ux-mips.org, john.linn@...inx.com,
randy.dunlap@...cle.com, davem@...emloft.net, meego-dev@...go.com,
qi.wang@...el.com, yong.y.wang@...el.com,
andrew.chih.howe.khor@...el.com, joel.clark@...el.com,
margie.foster@...el.com, okada533@....okisemi.com,
morinaga526@....okisemi.com, shimizu394@....okisemi.com
Subject: Re: [PATCH] Gigabit Ethernet driver of Topcliff PCH
On Tue, 31 Aug 2010 23:15:22 +0900
Masayuki Ohtake <masa-korg@....okisemi.com> wrote:
> Gigabit Ethernet driver of Topcliff PCH
> Patch created against 2.6.35
>
> Topcliff PCH is the platform controller hub that is going to be used in
> Intel's upcoming general embedded platform. All IO peripherals in
> Topcliff PCH are actually devices sitting on AMBA bus.
> Topcliff PCH has Gigabit Ethernet I/F. Using this I/F, it is able to
> access system devices connected to Gigabit Ethernet.
>
> Signed-off-by: Masayuki Ohtake <masa-korg@....okisemi.com>
> ---
> drivers/net/Kconfig | 10 +
> drivers/net/Makefile | 1 +
> drivers/net/pch_gbe/Makefile | 4 +
> drivers/net/pch_gbe/pch_gbe.h | 683 +++++++++
> drivers/net/pch_gbe/pch_gbe_api.c | 246 ++++
> drivers/net/pch_gbe/pch_gbe_api.h | 34 +
> drivers/net/pch_gbe/pch_gbe_ethtool.c | 618 ++++++++
> drivers/net/pch_gbe/pch_gbe_main.c | 2591 +++++++++++++++++++++++++++++++++
> drivers/net/pch_gbe/pch_gbe_param.c | 519 +++++++
> drivers/net/pch_gbe/pch_gbe_phy.c | 276 ++++
> drivers/net/pch_gbe/pch_gbe_phy.h | 35 +
> 11 files changed, 5017 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/pch_gbe/Makefile
> create mode 100644 drivers/net/pch_gbe/pch_gbe.h
> create mode 100644 drivers/net/pch_gbe/pch_gbe_api.c
> create mode 100644 drivers/net/pch_gbe/pch_gbe_api.h
> create mode 100644 drivers/net/pch_gbe/pch_gbe_ethtool.c
> create mode 100644 drivers/net/pch_gbe/pch_gbe_main.c
> create mode 100644 drivers/net/pch_gbe/pch_gbe_param.c
> create mode 100644 drivers/net/pch_gbe/pch_gbe_phy.c
> create mode 100644 drivers/net/pch_gbe/pch_gbe_phy.h
(snip)
> +/**
> + * pch_gbe_unmap_and_free_rx_resource - Unmap and free rx socket buffer
> + * @adapter: Board private structure
> + * @buffer_info: Buffer information structure
> + */
> +static void pch_gbe_unmap_and_free_rx_resource(
> + struct pch_gbe_adapter *adapter,
> + struct pch_gbe_buffer *buffer_info)
> +{
> + if (buffer_info->dma) {
> + pci_unmap_single(adapter->pdev, buffer_info->dma,
> + buffer_info->length, PCI_DMA_FROMDEVICE);
> + buffer_info->dma = 0;
Probably, this trick doesn't work because zero could be a valid DMA
address on some architctures.
> + /*-- Set Buffer infomation --*/
> + buffer_info->length = skb->len;
> + buffer_info->dma =
> + pci_map_single(adapter->pdev, skb->data, buffer_info->length,
> + PCI_DMA_TODEVICE);
Needs to handle mapping failure (dma_mapping_errro)?
I found the same problems in other places.
Can you use dma_map_* API instead of pci_map_*? Please read:
Documentation/DMA-API.txt
Documentation/DMA-API-HOWTO.txt
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists