Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

On Thu, Apr 26, 2018 at 12:56 AM, Krzysztof Kozlowski <k...@kernel.org> wrote: > On Thu, Apr 26, 2018 at 2:40 AM, Grant Grundler <grund...@chromium.org> wrote: >> On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski <k...@kernel.org&g

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

ID 13b1:0041 Linksys > > Signed-off-by: Grant Grundler <grund...@chromium.org> > Reviewed-by: Douglas Anderson <diand...@chromium.org> > Signed-off-by: David S. Miller <da...@davemloft.net> > [krzk: Rebase on v4.4] > Signed-off-by: Krzysztof Kozlowski <k...@kerne

Re: [PATCH V4] r8152: add Linksys USB3GIGV1 id

On Sun, Oct 1, 2017 at 10:39 PM, David Miller <da...@davemloft.net> wrote: > From: Grant Grundler <grund...@chromium.org> > Date: Thu, 28 Sep 2017 11:35:00 -0700 > >> This linksys dongle by default comes up in cdc_ether mode. >> This patch allows r8152 to claim the

[PATCH V4] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/cdc_ether.c | 10 ++ drivers/net/usb/r8152.c | 2 ++ 2

Re: [PATCH V3] r8152: add Linksys USB3GIGV1 id

Hi Doug! On Wed, Sep 27, 2017 at 4:47 PM, Doug Anderson <diand...@chromium.org> wrote: > Hi, > > On Wed, Sep 27, 2017 at 10:28 AM, Grant Grundler <grund...@chromium.org> > wrote: >> This linksys dongle by default comes up in cdc_ether mode. >> This pa

[PATCH V3] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/cdc_ether.c | 10 ++ drivers/net/usb/r8152.c | 2 ++ 2

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote: > Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson: >> >> I know that for at least some of the adapters in the CDC Ethernet >> blacklist it was claimed that the CDC Ethernet support in the adapter >> was kinda

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

On Mon, Sep 25, 2017 at 1:17 PM, Grant Grundler <grund...@chromium.org> wrote: ... > I didn't realize cdc_ether has a blacklist to make sure > RTL8152|RTL8153 devices are not picked up by cdc_ether. Would you > prefer I add this device to the blacklist in the same patch? I've sent

[PATCH V2] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/cdc_ether.c | 8 drivers/net/usb/r8152.c | 2 ++ 2

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

[grrhmail...sorry! resending as plain text] Hallo Oliver! On Mon, Sep 25, 2017 at 7:51 AM, Oliver Neukum <oneu...@suse.com> wrote: > Am Freitag, den 22.09.2017, 12:06 -0700 schrieb Grant Grundler: > > This Linksys dongle by default comes up in cdc_ether mode. > > This patch

[PATCH] r8152: add Linksys USB3GIGV1 id

This Linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/r8152.c | 2 ++ 1 file changed, 2 insertions(+) This was

Re: [PATCH v3 5/5] net: asix: autoneg will set WRITE_MEDIUM reg

On Thu, Sep 1, 2016 at 10:02 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2016-09-01 at 12:47 -0400, Robert Foss wrote: > >> I'm not quite sure how the first From line was added, it >> should not have been. >> Grant Grundler is most definitely the a

Re: [PATCH 1/3] net: asix: Add in_pm parameter

On Tue, Jul 26, 2016 at 2:14 PM, Robert Foss wrote: ... > Thanks for the feedback (for this patch and the other ones)! > I'm preparing a v2 and will submit it withing a day or two. Excellent! very welcome and thanks again for picking this up. ... >> FTR, current

Re: [PATCH 3/3] net: asix: Fix AX88772x resume failures

igned-off-by: Allan Chou <al...@asix.com.tw> Signed-off-by: WK Tsai <wk.t...@nvidia.com> Tested-by: Grant Grundler <grund...@chromium.org> Reviewed-by: Wang-Kai Tsai <gis5...@gmail.com> Reviewed-by: Mark Kuo <m...@nvidia.com> Reviewed-by: Grant Grundler <grund...@chro

Re: [PATCH 2/3] net: asix: Avoid looping when the device is disconnected

On Mon, Jul 25, 2016 at 10:40 AM, wrote: > From: Vincent Palatin > > Check the answers from the USB stack and avoid re-sending multiple times > the request if the device has disappeared. > > Signed-off-by: Vincent Palatin

Re: [PATCH 1/3] net: asix: Add in_pm parameter

[as plain text this time...] Robert, On Mon, Jul 25, 2016 at 10:40 AM, <robert.f...@collabora.com> wrote: > From: Grant Grundler <grund...@chromium.org> For the record, I believe I am not the author of these patches. I believe the original author is Signed-off-by:

Re: [PATCH] r8152: add MODULE_VERSION

On Fri, Jul 15, 2016 at 2:25 PM, David Miller <da...@davemloft.net> wrote: > From: Grant Grundler <grund...@chromium.org> > Date: Thu, 14 Jul 2016 11:27:16 -0700 > >> ethtool -i provides a driver version that is hard coded. >> Export the same value via &quo

[PATCH] r8152: add MODULE_VERSION

ethtool -i provides a driver version that is hard coded. Export the same value via "modinfo". Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/r8152.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152

Re: [PATCH] net: tulip: turn compile-time warning into dev_warn()

On Thu, Nov 19, 2015 at 3:50 PM, Francois Romieu <rom...@fr.zoreil.com> wrote: > Grant Grundler <grantgrund...@gmail.com> : > [...] >> Some additional minor refactoring of the code could convert this into >> a "multi-bus driver" if there is any system t

[PATCH] net: tulip: update MAINTAINER status to Orphan

From: Grant Grundler <grund...@parisc-linux.org> I haven't had any PCI tulip HW for the past ~5 years. I have been reviewing tulip patches and can continue doing that. Signed-off-by: Grant Grundler <grund...@parisc-linux.org> --- I'm also proposing to add linux-parisc to the list

Re: [PATCH] net: tulip: turn compile-time warning into dev_warn()

*dev) >> #elif defined(CONFIG_SPARC) || defined (CONFIG_PARISC) || >> defined(CONFIG_ARM) >> i |= 0x4800; >> #else >> -#warning Processor architecture undefined >> + dev_warn(>dev, "unknown CPU architecture, using default csr0 >> setting\n&

Re: [PATCH] net: tulip: turn compile-time warning into dev_warn()

On Thu, Nov 19, 2015 at 12:29 PM, Florian Fainelli wrote: > On 19/11/15 04:26, Will Deacon wrote: ... >> /me waits for on-soc tulip integration. > > FWIW, this already happened, the ADMtek/Infineon ADM8668 actually > integrated a Tulip chip. I have not submitted these

Re: [PATCH] net: tulip: update MAINTAINER status to Orphan

On Thu, Nov 19, 2015 at 6:29 PM, Florian Fainelli <f.faine...@gmail.com> wrote: > On 19/11/15 17:56, Grant Grundler wrote: >> From: Grant Grundler <grund...@parisc-linux.org> >> >> I haven't had any PCI tulip HW for the past ~5 years. I have >> been reviewi

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

On Mon, Feb 25, 2008 at 02:30:00AM -0500, Jeff Garzik wrote: Grant Grundler wrote: On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote: I think that de2104x driver should be removed (or at least its MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI IDs added

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote: On Monday 18 February 2008 04:21:11 Grant Grundler wrote: On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote: On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote: Hello, I was having problems

[PATCH] [Bug 5839] uli526x partially recognizing interface

/testing a similar patch before: http://lkml.org/lkml/2006/8/21/45 Signed-off-by: Grant Grundler [EMAIL PROTECTED] diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c index ca2548e..1dd8485 100644 --- a/drivers/net/tulip/uli526x.c +++ b/drivers/net/tulip/uli526x.c @@ -484,9

[PATCH] update TULIP MAINTAINERS

Jeff, Kyle and I are co-maintaining tulip driver. Normally kyle will review my patchs and submit them. I'll deal with bugzilla.kernel.org bugs and try to resolve those bugs. thanks, grant Signed-off-by: Grant Grundler [EMAIL PROTECTED] --- linux-2.6.24.1/MAINTAINERS-ORIG 2008-02-17 10:33

Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x

On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote: On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote: Hello, I was having problems with these FreedomLine cards with Linux before but tested it thoroughly today. This card uses DEC 21041 chip and has TP and BNC connectors:

Re: [patch 06/13] Fix a potential NULL pointer dereference in uli526x_interrupt() in drivers/net/tulip/uli526x.c

-by: Micah Gruber [EMAIL PROTECTED] Cc: Grant Grundler [EMAIL PROTECTED] Acked-by: Grant Grundler [EMAIL PROTECTED] thanks! grant Acked-by: Jeff Garzik [EMAIL PROTECTED] Acked-by: Kyle McMartin [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/tulip

Re: [PATCH] Clean up redundant PHY write line for ULi526x Ethernet driver

On Thu, Sep 27, 2007 at 11:36:58PM -0400, Jeff Garzik wrote: Zang Roy-r61911 wrote: From: Roy Zang [EMAIL PROTECTED] Clean up redundant PHY write line for ULi526x Ethernet Driver. Signed-off-by: Roy Zang [EMAIL PROTECTED] --- drivers/net/tulip/uli526x.c |1 - 1 files changed, 0

Re: [TULIP] Need new maintainer

On Mon, Jul 30, 2007 at 03:31:58PM -0400, Kyle McMartin wrote: On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote: The Tulip network driver needs a new maintainer! I no longer have time to maintain the Tulip network driver and I'm stepping down. Jeff Garzik would be happy to

Re: [patch 06/10] tulip: fix shutdown DMA/irq race

On Mon, Mar 26, 2007 at 09:47:25PM -0800, [EMAIL PROTECTED] wrote: From: Grant Grundler [EMAIL PROTECTED] IRQs are racing with tulip_down(). DMA can be restarted by the interrupt handler _after_ we call tulip_stop_rxtx() and the DMA buffers are unmapped. The result is an MCA (hard crash

Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx

On Thu, Mar 15, 2007 at 11:25:10AM -0400, Jeff Garzik wrote: ... Here's the problem with this: this printk is signalling that the DMA engines have not yet stopped, which is an event of which we should be wary. While it makes sense to do this patch, since the complaining cards appear to

Re: [PATCH 2/5] fixing errors handling during pci_driver resume stage [ata]

On Tue, Jan 09, 2007 at 12:01:28PM +0300, Dmitriy Monakhov wrote: ata pci drivers have to return correct error code during resume stage in case of errors. ... @@ -6246,8 +6253,10 @@ int ata_pci_device_suspend(struct pci_de int ata_pci_device_resume(struct pci_dev *pdev) { struct

Re: [PATCH 2/2] [TULIP] Check the return value from pci_set_mwi()

On Fri, Oct 06, 2006 at 03:59:57PM -0400, Jeff Garzik wrote: The unmodified tulip driver checks both MWI and cacheline-size because one of the clones (PNIC or PNIC2) will let you set the MWI bit, but hardwires cacheline size to zero. Maybe the generic pci_set_mwi() can verify cacheline size

PATCH: fix cut/paste error in TCPPROBE

Fix cut/paste error in TCPPROBE help text. Signed-off-by: Grant Grundler [EMAIL PROTECTED] --- a/net/Kconfig +++ b/net/Kconfig @@ -231,7 +231,7 @@ config NET_TCPPROBE TCP congestion avoidance modules. If you don't understand what was just said, you don't need it: say N

Re: [PATCH 4/9] [TULIP] Clean tulip.h so it can be used by winbond-840.c

On Wed, Aug 09, 2006 at 01:33:18AM -0400, Jeff Garzik wrote: 2) nobody (but parisc folks?) knows what CBMA and CBIO mean. Just use MMIO and PIO CBIO is what's in the public documentation. I just want to make it easy for anyone who bothers to read the documentation to be sure they are reading

Re: [parisc-linux] [git patches] tulip fixes from parisc-linux

On Sat, Jul 29, 2006 at 06:54:59PM -0400, Kyle McMartin wrote: Hi Val, Sorry it took so long for me to get around to splitting up the changes from the parisc-linux tree. But here they finally are. Kyle, dude, you rock! Many thanks for doing that. I just wanted to warn that some of the

Re: [patch 1/2] tulip: fix for 64-bit mips

On Sun, Jun 25, 2006 at 10:31:08AM +0100, Martin Michlmayr wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] [2006-06-25 01:45]: Cc: Valerie Henson [EMAIL PROTECTED] [akpm: this is a previously-nacked patch, but the problem is real] ia64 and parisc need the changes to tulip_select_media() too.

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

-term with the ordering Grant uses: disable interrupts free_irq() stop rxtx remove DMA resources Make sense to everyone? I'll redo the patch with the comment and get Grant's sign-off. Yes. I'm ok with anything similar to what you posted above: Signed-off-by: Grant Grundler [EMAIL

Re: [openib-general] [PATCH v3 1/7] AMSO1100 Low Level Driver.

On Wed, Jun 21, 2006 at 11:32:51AM -0500, Steve Wise wrote: Um, what's a 'PCI posting flush'? Can you point me where its described/used so I can see if we need it? Thanx. I've written this up before: http://iou.parisc-linux.org/ols_2002/4Posted_vs_Non_Posted.html grant - To

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Fri, Jun 16, 2006 at 03:32:56AM -0400, Jeff Garzik wrote: Correct. Before calling free_irq(), patch V3 masks interrupts on tulip and guarantees the tulip will not generate new interrupts before that call. Incorrect -- it does not guarantee that tulip will not generate new interrupt

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

[ Jeff, apologies. I hit reply instead of group reply on previous email. I've added everyone back on the cc list.] On Fri, Jun 16, 2006 at 11:30:32AM -0400, Jeff Garzik wrote: ... Are you saying this sequence won't mask interrupts on tulip? /* Disable interrupts by clearing the

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Thu, Jun 15, 2006 at 10:30:17PM +0200, Francois Romieu wrote: Afaik free_irq() on a shared irq does not touch the hardware and irqs are anything but synchronous. If free_irq() is issued before the device is idle and its irq are not acked, it's wrong. Correct. Before calling free_irq(),

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Wed, Jun 14, 2006 at 09:05:06AM -0400, Kyle McMartin wrote: I think the correct sequence would be: reset tulip interrupt mask flush posted write synchronize irq /* make sure we got 'em all */ tulip_stop_rxtx /* turn off dma */

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Wed, Jun 14, 2006 at 11:03:48AM -0400, Jeff Garzik wrote: Grant Grundler wrote: Switching the order to be: tulip_stop_rxtx(tp);/* Stop DMA */ free_irq (dev-irq, dev); /* no more races after this */ still leaves us open to IRQs being delivered _after_

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Wed, Jun 14, 2006 at 10:47:20PM +0200, Francois Romieu wrote: Grant Grundler [EMAIL PROTECTED] : [...] I'm not keen on adding more code to tulip_interrupt() routine for something that rarely happens (compared to IRQs) and is handled outside the interrupt routine. I'm pretty sure

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Thu, Jun 08, 2006 at 11:01:20AM -0600, Grant Grundler wrote: Here is a new patch that moves free_irq() into tulip_down(). The resulting code is structured the same as cp_close(). Val, Two details are wrong in version 2 and are fixed in v3 (appended below): o we don't need synchronize_irq

Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late

On Tue, Jun 13, 2006 at 08:33:22PM -0400, Jeff Garzik wrote: Grant Grundler wrote: o tulip_stop_rxtx() has to be called _after_ free_irq(). ie. v2 patch didn't fix the original race condition and when under test, dies about as fast as the original code. You made the race window smaller

Re: PATCH 2.6.17-rc5 tulip free_irq() called too late

On Thu, Jun 08, 2006 at 10:43:04AM -0400, Jeff Garzik wrote: (CC'ing our newly minted tulip maintainer, Val) Excellent! Has MAINTAINERS file been updated? :) ... NAK. This is a band-aid, and one that creates new problems even as it attempts to solve problems. You failed to demonstrate that

Re: PATCH 2.6.17-rc5 tulip free_irq() called too late

On Thu, Jun 08, 2006 at 09:22:21AM -0600, Grant Grundler wrote: Perhaps cp_close() in 8139cp.c could be an example of a good ordering? It stops the chip, syncs irqs, frees irq, then frees [thus unmapping] the rings. Sorry, I don't see how it matters if we disable chip IRQ first

Re: PATCH 2.6.17-rc5 tulip free_irq() called too late

On Thu, Jun 08, 2006 at 11:32:39AM -0400, Jeff Garzik wrote: The chip IRQ gets turned off in tulip_down(). It won't be screaming for very long. Then you admit that you add a race. Yes - I realized that after I hit send :( ... In the shared IRQ case, I expect free_irq() to unlink this

Re: PATCH 2.6.17-rc5 tulip free_irq() called too late

On Thu, Jun 08, 2006 at 11:38:52AM -0400, Jeff Garzik wrote: Can we call free_irq() from tulip_down()? I'm sure you can answer that yourself. If it doesn't cause problems elsewhere, yes. Otherwise, no. :) Yeah, well, I was hoping you would Just Know (tm). :) Research takes time. Did

Re: New tulip maintainer...

On Thu, Jun 08, 2006 at 11:41:28AM -0400, Jeff Garzik wrote: Now that we have a new tulip maintainer, perhaps a resend of the long-outstanding tulip phy patches could be resent? All the tulip patches I have are archived here: ftp://ftp.parisc-linux.org/patches/ Anything else tulip

Re: PATCH 2.6.17-rc5 tulip free_irq() called too late

On Thu, Jun 08, 2006 at 10:43:04AM -0400, Jeff Garzik wrote: ... Perhaps cp_close() in 8139cp.c could be an example of a good ordering? It stops the chip, syncs irqs, frees irq, then frees [thus unmapping] the rings. Here is a new patch that moves free_irq() into tulip_down(). The resulting

PATCH 2.6.17-rc5 tulip free_irq() called too late

believe the problem is a race condition between an interrupt coming in and the tulip_down() code path. Moving the free_irq() to before tulip_down() call fixes the problem. I've been able to run the above test for several hours now. Please apply. thanks, grant Signed-off-by: Grant Grundler [EMAIL

Re: [openib-general] [PATCH 5/5] [RFC] Infiniband: connection abstraction

On Wed, Jan 18, 2006 at 10:19:01AM -0800, Sean Hefty wrote: Roland Dreier wrote: + UCMA_MAX_BACKLOG= 128 Is there any reason that we might want to make this a tunable? Maybe as a module parameter that's writable in sysfs... There's no reason not to make this tunable. Yes,

Re: [openib-general] RE: [PATCH 2/5] [RFC] Infiniband: connection abstraction

On Tue, Jan 17, 2006 at 03:24:37PM -0800, Sean Hefty wrote: +static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask) +{ + int i; + + for (i = 0; i IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++) + dst[i] = src[i] mask[i]; +} Is this code going to get invoked very often?

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

On Wed, Dec 07, 2005 at 07:41:29AM -0500, jamal wrote: ok - that's fair. I suspect the hyperthreading case is one where binding the IRQs to particule CPUs is necessary to reproduce the results. Note: I didnt bind anything. The p4/xeon starts with routing everything to CPU#0 - i just

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

On Wed, Dec 07, 2005 at 02:17:16PM -0500, jamal wrote: ... Note, however that as soon as i turn copybreak off, the numbers go down ;- Now for some obtuse theory as to why this happens: I think the reason that prefetch + copybreak together have higher numbers is because the copybreak code

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

On Sat, Dec 03, 2005 at 02:37:59PM -0500, jamal wrote: On Sat, 2005-03-12 at 12:00 -0700, Grant Grundler wrote: On Sat, Dec 03, 2005 at 09:20:52AM -0500, jamal wrote: Ok, so you seem to be saying again that for case #b above, there is no harm in issuing the prefetch late since the CPU

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

On Thu, Dec 01, 2005 at 09:32:37PM -0500, jamal wrote: I think until a counter case is shown, the prefetches should remain on unconditionally. Proof of detriment is the burdon of the accusor, especially since the Intel folks aparently did a lot of testing :-) We've already been down this

Re: [openib-general] error compiling kernel...

be enabled as a module. Patch below adds EXPORT_SYMBOL() to fib_frontend.c. I'm not trying to assert this is the Right Thing. It's just the first obvious solution to the immediate problem. thanks, grant Signed-off-by: Grant Grundler [EMAIL PROTECTED] --- linux-2.6.14-ORIG/net/ipv4/fib_frontend.c

Re: [openib-general] error compiling kernel...

On Mon, Nov 07, 2005 at 09:59:49PM -0800, Grant Grundler wrote: WARNING: /lib/modules/2.6.14/kernel/drivers/infiniband/ulp/sdp/ib_sdp.ko needs unknown symbol ip_dev_find Patch below adds EXPORT_SYMBOL() to fib_frontend.c. ...never mind