netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: David Miller <davem@davemloft.net>,
	brandon@ifup.org, grundler@google.com, tobias@ringis.se,
	kyle@mcmartin.ca, netdev@vger.kernel.org,
	grundler@parisc-linux.org
Subject: Re: [PATCH v2] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
Date: Tue, 5 Jan 2010 09:58:17 -0700	[thread overview]
Message-ID: <20100105165817.GA13015@lackof.org> (raw)
In-Reply-To: <1262660588.26813.24.camel@localhost>

On Tue, Jan 05, 2010 at 03:03:08AM +0000, Ben Hutchings wrote:
> The Davicom DM9100 and DM9102 chips are used on the motherboards of
> some SPARC systems (supported by the tulip driver) and also in PCI
> expansion cards (supported by the dmfe driver).  There is no
> difference in the PCI device ids for the two different configurations,
> so these drivers both claim the device ids.  However, it is possible
> to distinguish the two configurations by the presence of Open Firmware
> properties for them, so we do that.
> 
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Signed-off-by: Grant Grundler <grundler@parisc-linux.org>

thanks for respinning this several times!
grant

> ---
> Changes from v1, as you requested:
> - Downgraded log messages from ERR to INFO
> - Removed dummy length parameter to of_get_property()
> 
> Ben.
> 
>  drivers/net/tulip/Kconfig      |    4 ++++
>  drivers/net/tulip/dmfe.c       |   17 +++++++++++++++++
>  drivers/net/tulip/tulip_core.c |   32 +++++++++++++++++++++++++-------
>  3 files changed, 46 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/tulip/Kconfig b/drivers/net/tulip/Kconfig
> index 1cc8cf4..516713f 100644
> --- a/drivers/net/tulip/Kconfig
> +++ b/drivers/net/tulip/Kconfig
> @@ -101,6 +101,10 @@ config TULIP_NAPI_HW_MITIGATION
>  
>  	  If in doubt, say Y.
>  
> +config TULIP_DM910X
> +	def_bool y
> +	depends on TULIP && SPARC
> +
>  config DE4X5
>  	tristate "Generic DECchip & DIGITAL EtherWORKS PCI/EISA"
>  	depends on PCI || EISA
> diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
> index ad63621..b2273a1 100644
> --- a/drivers/net/tulip/dmfe.c
> +++ b/drivers/net/tulip/dmfe.c
> @@ -377,6 +377,23 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
>  	if (!printed_version++)
>  		printk(version);
>  
> +	/*
> +	 *	SPARC on-board DM910x chips should be handled by the main
> +	 *	tulip driver, except for early DM9100s.
> +	 */
> +#ifdef CONFIG_TULIP_DM910X
> +	if (ent->driver_data == PCI_DM9100_ID && pdev->revision >= 0x30 ||
> +	    ent->driver_data == PCI_DM9102_ID) {
> +		struct device_node *dp = pci_device_to_OF_node(pdev);
> +
> +		if (dp && of_get_property(dp, "local-mac-address", NULL)) {
> +			printk(KERN_INFO DRV_NAME
> +			       ": skipping on-board DM910x (use tulip)\n");
> +			return -ENODEV;
> +		}
> +	}
> +#endif
> +
>  	/* Init network device */
>  	dev = alloc_etherdev(sizeof(*db));
>  	if (dev == NULL)
> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
> index 0fa3140..595777d 100644
> --- a/drivers/net/tulip/tulip_core.c
> +++ b/drivers/net/tulip/tulip_core.c
> @@ -196,9 +196,13 @@ struct tulip_chip_table tulip_tbl[] = {
>  	| HAS_NWAY | HAS_PCI_MWI, tulip_timer, tulip_media_task },
>  
>    /* DM910X */
> +#ifdef CONFIG_TULIP_DM910X
>    { "Davicom DM9102/DM9102A", 128, 0x0001ebef,
>  	HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
>  	tulip_timer, tulip_media_task },
> +#else
> +  { NULL },
> +#endif
>  
>    /* RS7112 */
>    { "Conexant LANfinity", 256, 0x0001ebef,
> @@ -228,8 +232,10 @@ static struct pci_device_id tulip_pci_tbl[] = {
>  	{ 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>  	{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
>  	{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
> +#ifdef CONFIG_TULIP_DM910X
>  	{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>  	{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> +#endif
>  	{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>  	{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
>  	{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
> @@ -1299,18 +1305,30 @@ static int __devinit tulip_init_one (struct pci_dev *pdev,
>  	}
>  
>  	/*
> -	 *	Early DM9100's need software CRC and the DMFE driver
> +	 *	DM910x chips should be handled by the dmfe driver, except
> +	 *	on-board chips on SPARC systems.  Also, early DM9100s need
> +	 *	software CRC which only the dmfe driver supports.
>  	 */
>  
> -	if (pdev->vendor == 0x1282 && pdev->device == 0x9100)
> -	{
> -		/* Read Chip revision */
> -		if (pdev->revision < 0x30)
> -		{
> -			printk(KERN_ERR PFX "skipping early DM9100 with Crc bug (use dmfe)\n");
> +#ifdef CONFIG_TULIP_DM910X
> +	if (chip_idx == DM910X) {
> +		struct device_node *dp;
> +
> +		if (pdev->vendor == 0x1282 && pdev->device == 0x9100 &&
> +		    pdev->revision < 0x30) {
> +			printk(KERN_INFO PFX
> +			       "skipping early DM9100 with Crc bug (use dmfe)\n");
> +			return -ENODEV;
> +		}
> +
> +		dp = pci_device_to_OF_node(pdev);
> +		if (!(dp && of_get_property(dp, "local-mac-address", NULL))) {
> +			printk(KERN_INFO PFX
> +			       "skipping DM910x expansion card (use dmfe)\n");
>  			return -ENODEV;
>  		}
>  	}
> +#endif
>  
>  	/*
>  	 *	Looks for early PCI chipsets where people report hangs
> -- 
> 1.6.5.7
> 

  reply	other threads:[~2010-01-05 16:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-05  3:03 [PATCH v2] dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips Ben Hutchings
2010-01-05 16:58 ` Grant Grundler [this message]
2010-01-07  8:51   ` David Miller
2010-01-07  9:06     ` David Miller
2010-01-07 12:41       ` [PATCH v3] " Ben Hutchings
2010-01-07 18:46         ` Grant Grundler
2010-01-08  1:27           ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100105165817.GA13015@lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=ben@decadent.org.uk \
    --cc=brandon@ifup.org \
    --cc=davem@davemloft.net \
    --cc=grundler@google.com \
    --cc=kyle@mcmartin.ca \
    --cc=netdev@vger.kernel.org \
    --cc=tobias@ringis.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).