All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <darren.hart@intel.com>
To: "lkml, " <linux-kernel@vger.kernel.org>
Cc: Wang Qi <qi.wang@intel.com>,
	Tomoya MORINAGA <tomoya.rohm@gmail.com>,
	Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: Porting pch_pcieqos to 3.2 for Intel EG20T with no MAC
Date: Fri, 13 Jan 2012 09:33:15 -0800	[thread overview]
Message-ID: <4F106ADB.4040000@intel.com> (raw)
In-Reply-To: <4F0CECC8.7010203@linux.intel.com>

On 01/10/2012 05:58 PM, Darren Hart wrote:
> I find myself with a development board with no MAC address for the pch_gbe in
> the Platform Controller Hub EG20T. I've dusted off an old patch and am trying
> to get it working so it can be included upstream.
> 
> I found the phub_util_mac utility on sourceforge which appears to require the
> following patch:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-extras/plain/recipes-kernel/linux/linux-netbook-2.6.33.2/linux-2.6.34-pch-pcieqos.patch
> 
> I've made the obvious changes to the driver to use unlocked_ioctl as ioctl has
> been removed upstream. With this driver built and installed, the
> topcliff_mac_util command reports no errors and reads the MAC address as:
> 
> 00:00:00:00:00:00
> 
> Trying to set it reports no errors either, and the instrumentation suggests it
> is at least trying to write the correct data. Reading back still results in all
> zeros.
> 
> During boot, the pch_gbe driver reports:
> [    2.211233] pch_gbe 0000:02:00.1: enabling device (0000 -> 0003)
> [    2.217271] pch_gbe 0000:02:00.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [    2.224349] pch_gbe 0000:02:00.1: setting latency timer to 64
> [    2.233388] pch_gbe 0000:02:00.1: Invalid MAC Address
> [    2.238821] pch_gbe 0000:02:00.1: PCI INT A disabled
> [    2.243809] pch_gbe: probe of 0000:02:00.1 failed with error -5
> 
> The patch itself follows, I have attached a rather lengthy log which includes a
> read/write/read cycle demonstrating the write not taking effect.
> 
> Can you shed some light on why this might be the case?

After stumbling around blindly for a bit longer, I ran across the pch_phub
driver, which appears to be intended for the same purpose, but uses a sysfs
interface rather than an ioctl interface with a separate userpsace utility.
Do I have this right?

Enabling this driver doesn't change the above pch_gbe messages which still
include the failed probe of 0000:02:00.1. pch_phub has entries in /sys:

root@(none):/# find /sys/bus/pci/drivers/pch_phub
/sys/bus/pci/drivers/pch_phub
/sys/bus/pci/drivers/pch_phub/uevent
/sys/bus/pci/drivers/pch_phub/unbind
/sys/bus/pci/drivers/pch_phub/bind
/sys/bus/pci/drivers/pch_phub/new_id
/sys/bus/pci/drivers/pch_phub/remove_id

but no "pch_mac" as I was expecting after reviewing pch_phub.c.

Am I still barking up the wrong tree here?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

  reply	other threads:[~2012-01-13 17:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-11  1:58 Porting pch_pcieqos to 3.2 for Intel EG20T with no MAC Darren Hart
2012-01-13 17:33 ` Darren Hart [this message]
2012-01-16  3:06   ` Tomoya MORINAGA
2012-01-16  6:26     ` Darren Hart

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=4F106ADB.4040000@intel.com \
    --to=darren.hart@intel.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qi.wang@intel.com \
    --cc=tomoya.rohm@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.