Messages in this thread | | | Date | Mon, 16 Jan 2012 12:06:55 +0900 | Subject | Re: Porting pch_pcieqos to 3.2 for Intel EG20T with no MAC | From | Tomoya MORINAGA <> |
| |
Hi Darren,
Can you execute like below root@(none):/# find /sys/bus/pci/drivers/pch_phub/0000:02:00.0
You must see pch_mac.
Or Is your pch_phub integrated as module ? If module, you can access from below. /sys/module/pch_phub/drivers/pci:pch_phub/0000:02:00.0
thanks, tomoya
2012/1/14 Darren Hart <darren.hart@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 -- 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/
| |