Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756025Ab3D0FaT (ORCPT ); Sat, 27 Apr 2013 01:30:19 -0400 Received: from server.prisktech.co.nz ([115.188.14.127]:60988 "EHLO server.prisktech.co.nz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753305Ab3D0FaS (ORCPT ); Sat, 27 Apr 2013 01:30:18 -0400 Message-ID: <517B6267.4070404@prisktech.co.nz> Date: Sat, 27 Apr 2013 17:30:15 +1200 From: Tony Prisk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Francois Romieu , "Mailing List, Arm" , netdev@vger.kernel.org, "linux-kernel@vger.kernel.org" Subject: VIA velocity network driver Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1833 Lines: 43 I would like to add support to this driver for platform devices as found on VIA's APC8750 board. At the moment, I have a standalone platform version that works fine, but wanted to ask a few questions before sending a patch to merge this code into one driver. The current driver is for PCI network cards, and uses pci dma functions. Most of the pci dma functions are wrappers around other functions which is what I have used for the platform version. For example: rd_info->skb_dma = pci_map_single(vptr->pdev, rd_info->skb->data, vptr->rx.buf_sz, PCI_DMA_FROMDEVICE); is replaced with: rd_info->skb_dma = dma_map_single(&vptr->plat_dev->dev, rd_info->skb->data, vptr->rx.buf_sz, DMA_FROM_DEVICE); Is it ok to use the non-pci versions (which are basically just the unwrapped pci versions) and pass the struct device *, or will I need to use the correct function for the correct instance. Other than adding some new probe/remove functions, this is all that is needed to add platform driver support. One bug/problem that arose is to do with the EEPROM code in velocity_init_registers(), in the case for VELOCITY_INIT_COLD: mac_eeprom_reload(regs); for (i = 0; i < 6; i++) writeb(vptr->dev->dev_addr[i], &(regs->PAR[i])); I assume this is loading something from an EEPROM, but there is no EEPROM on the APC8750. Removing this code, the driver seems to work fine on the APC8750. Could it be avoided with a vptr->has_no_eeprom that defaults to 0 to avoid breaking existing support? Regards Tony Prisk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/