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
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
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
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
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
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
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
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
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
[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
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
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
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
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
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
[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:
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
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
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
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
*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&
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
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
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
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
/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
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
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:
-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
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
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
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
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
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
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
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
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
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
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.
-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
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
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
[ 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
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(),
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 */
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_
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
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
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
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
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
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
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
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
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
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
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,
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?
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
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
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
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
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
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
64 matches
Mail list logo