* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: Francois Romieu @ 2009-08-25 22:19 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Dillow, Michael Riepe, Michael Buesch, Rui Santos,
Michael B??ker, linux-kernel, netdev
In-Reply-To: <m1k50r8u4p.fsf@fess.ebiederm.org>
Eric W. Biederman <ebiederm@xmission.com> :
[...]
> I am a bit curious about TxDescUnavail. Perhaps we had a temporary
> memory shortage and that is what was screaming? I don't think we do
> anything at all with that state.
You are not alone, the driver completely ignores this bit.
As far as I remember, the TxDescUnavail event mostly pops up when the
driver makes an excessive use of TxPoll requests.
> Perhaps the flaw here is simply not masking TxDescUnavail while we are
> in NAPI mode ?
Yes, it is worth trying.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: David Dillow @ 2009-08-25 21:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <m1ljl77exz.fsf@fess.ebiederm.org>
On Tue, 2009-08-25 at 14:37 -0700, Eric W. Biederman wrote:
> David Dillow <dave@thedillows.org> writes:
> > Here's a possible patch to mask the NAPI events while we're running in
> > NAPI mode. I'm not sure it is going to help, since the intr_mask was
> > 0xffff when you hit the loop guard, so I left it in for now.
>
> Ok. I now get what your patch was trying to do and that does look like
> a reasonable test.
>
> I prefer:
> while ((status != 0xffff) && (status & tp->intr_mask))
I had thought of going that route first, but if you have any interrupt
event sources set, you want to enter the loop at least once to clear
them, otherwise you never see another MSI interrupt.
If the masking is the way things play out, then I'd put it where I had
it and put in a comment as to why it is there.
> The presence of TxDescUnavail suggests as is usually the case
> that the interrupt status bits are independent of which interrupts
> are actually enabled to fire.
Yes, but I seem to recall the MSI's edge detection being especially
oddly done -- I did tests with various masks and using the ability to
have it generate an interrupt on user demand, and IIRC it was handled
before the mask was applied, so we really did care about the events that
were active -- but I may misremember.
> I will take a moment and give that a try.
>
> I still like the idea of masking everything having poll do all
> of the work and then unmasking everything. That seems a little less
> fragile to me.
I wouldn't object if you did it, but I don't have time for it right now.
And it may make Francois's life harder when he does his periodic sweep
of the vendor driver, looking for differences.
^ permalink raw reply
* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: David Dillow @ 2009-08-25 21:46 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <m1k50r8u4p.fsf@fess.ebiederm.org>
On Tue, 2009-08-25 at 14:24 -0700, Eric W. Biederman wrote:
> David Dillow <dave@thedillows.org> writes:
> > I'm curious how you managed to receive an packet between us clearing the
> > all current sources and reading the current source list continuously for
> > 60+ seconds -- the loop is basically
>
>
> > status = get IRQ events from chip
> > while (status) {
> > /* process events, start NAPI if needed */
> > clear current events from chip
> > status = get IRQ events from chip
> > }
> >
> > That seems like a very small race window to consistently hit --
> > especially for long enough to trigger soft lockups.
>
> Interesting indeed. When I hit the guard we had popped out of NAPI
> mode while we were in the loop. The only way to do that is if
> poll and interrupt were running on different cpus.
That is the normal case on an SMP machine, but again that race window
should be fairly small as well -- from the __napi_schedule() to the
acking of the interrupt source is only a few lines of code, most of
which is in an error case that is skipped. Granted there may be a fair
number of instructions there if debugging or tracing is on -- I've not
checked -- but even then hitting that race consistently for 60+ seconds
doesn't seem likely.
Being out of NAPI in the guard may be a red herring -- it doesn't tell
us how long you were out of NAPI when you hit it. If there's a stuck bit
somewhere, then you could have been out of NAPI after the first cycle
and we'd have no way to tell. You could add some variables to keep track
of the status and mask values, and how long ago they changed to see.
> I am a bit curious about TxDescUnavail. Perhaps we had a temporary
> memory shortage and that is what was screaming? I don't think we do
> anything at all with that state.
TxDescUnavail is normal -- it means the chip finished sending everything
we asked it to.
> Perhaps the flaw here is simply not masking TxDescUnavail while we are
> in NAPI mode?
No, we never enable it on the chip, and it gets masked out when we
decide if we want to go to NAPI mode -- it is not set in tp->napi_event:
if (status & tp->intr_mask & tp->napi_event) {
^ permalink raw reply
* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: Eric W. Biederman @ 2009-08-25 21:37 UTC (permalink / raw)
To: David Dillow
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <1251169150.4023.11.camel@obelisk.thedillows.org>
David Dillow <dave@thedillows.org> writes:
> On Mon, 2009-08-24 at 17:51 -0700, Eric W. Biederman wrote:
>> When I decode the bits in status they are TxOK, RxOK and TxDescUnavail so it looks
>> there is some bidirectional communication going on.
>>
>> Do we really want to loop when those bits are set?
>
> Maybe not when only those bits are set, but I worry that we would trade
> one race for another where we stop getting interrupts from the card.
>
>> Perhaps we want to remove them from rtl_cfg_infos for the part?
>
> Then you'd never get an interrupt for them in the first place, I think.
>
> I'm not real happy with the interrupt handling in the driver; it makes a
> certain amount of sense to split the MSI vs non-MSI interrupt cases out.
> It also means another pass through re-auditing things against the vendor
> driver. That's more work than I'm able to commit to at the moment.
>
> I've not been able to reproduce it locally on my r8169d, running for ~30
> minutes straight at full speed. I've not tried running it in UP, though.
> Perhaps I can do that tomorrow.
>
> Here's a possible patch to mask the NAPI events while we're running in
> NAPI mode. I'm not sure it is going to help, since the intr_mask was
> 0xffff when you hit the loop guard, so I left it in for now.
Ok. I now get what your patch was trying to do and that does look like
a reasonable test.
I prefer:
while ((status != 0xffff) && (status & tp->intr_mask))
The presence of TxDescUnavail suggests as is usually the case
that the interrupt status bits are independent of which interrupts
are actually enabled to fire.
I will take a moment and give that a try.
I still like the idea of masking everything having poll do all
of the work and then unmasking everything. That seems a little less
fragile to me.
Eric
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index b82780d..12755b7 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -3556,6 +3556,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
> void __iomem *ioaddr = tp->mmio_addr;
> int handled = 0;
> int status;
> + int count = 0;
>
> /* loop handling interrupts until we have no new ones or
> * we hit a invalid/hotplug case.
> @@ -3564,6 +3565,15 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
> while (status && status != 0xffff) {
> handled = 1;
>
> + if (count++ > 100) {
> + printk_once("r8169 screaming irq status %08x "
> + "mask %08x event %08x napi %08x\n",
> + status, tp->intr_mask, tp->intr_event,
> + tp->napi_event);
> + break;
> + }
> +
> +
> /* Handle all of the error cases first. These will reset
> * the chip, so just exit the loop.
> */
> @@ -3613,6 +3623,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
> RTL_W16(IntrStatus,
> (status & RxFIFOOver) ? (status | RxOverflow) : status);
> status = RTL_R16(IntrStatus);
> + status &= tp->intr_mask;
> }
>
> return IRQ_RETVAL(handled);
^ permalink raw reply
* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: Eric W. Biederman @ 2009-08-25 21:24 UTC (permalink / raw)
To: David Dillow
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <1251232848.9607.15.camel@lap75545.ornl.gov>
David Dillow <dave@thedillows.org> writes:
> On Tue, 2009-08-25 at 13:22 -0700, Eric W. Biederman wrote:
>> David Dillow <dave@thedillows.org> writes:
>> > I'm not real happy with the interrupt handling in the driver; it makes a
>> > certain amount of sense to split the MSI vs non-MSI interrupt cases out.
>> > It also means another pass through re-auditing things against the vendor
>> > driver. That's more work than I'm able to commit to at the moment.
>> >
>> > I've not been able to reproduce it locally on my r8169d, running for ~30
>> > minutes straight at full speed. I've not tried running it in UP, though.
>> > Perhaps I can do that tomorrow.
>> >
>> > Here's a possible patch to mask the NAPI events while we're running in
>> > NAPI mode. I'm not sure it is going to help, since the intr_mask was
>> > 0xffff when you hit the loop guard, so I left it in for now.
>>
>> Interesting.
>>
>> If I understand this correctly the situation is that we have on the
>> chip there is correct logic for a level triggered interrupt and that
>> the msi logic sits on it and sends an event when the interrupt signal
>> goes high, but when we acknowledge some bits but not all it does not
>> send another interrupt.
>
> Correct, we have to acknowledge all current outstanding event sources
> before we get another MSI interrupt. It looks like the MSI interrupt is
> triggered on the edge transition of a logical OR of all irq sources.
>
>> Baring playing games with what version of the card has working logic
>> and which does not we seem to have to simple choices (if we don't want
>> to loop possibly forever).
>> - Don't use the msi logic on this card.
>> - Move all of the logic into rtl8169_poll and only come out of NAPI
>> mode when we have caught up with all of the interrupt work.
>>
>> Is that how you understand the hardware issue you are trying to work
>> around?
>
> That's how I understood the issue I was working around with the
> problematic patch, but I thought I had covered both issues fairly well
> without having to split the handling any further -- we ACK all existing
> sources each pass through the loop, so we'll get a new interrupt on the
> unmasked events, but not on ones we've masked out for NAPI until NAPI
> completes and unmasks them.
> I'm curious how you managed to receive an packet between us clearing the
> all current sources and reading the current source list continuously for
> 60+ seconds -- the loop is basically
> status = get IRQ events from chip
> while (status) {
> /* process events, start NAPI if needed */
> clear current events from chip
> status = get IRQ events from chip
> }
>
> That seems like a very small race window to consistently hit --
> especially for long enough to trigger soft lockups.
Interesting indeed. When I hit the guard we had popped out of NAPI
mode while we were in the loop. The only way to do that is if
poll and interrupt were running on different cpus.
I am a bit curious about TxDescUnavail. Perhaps we had a temporary
memory shortage and that is what was screaming? I don't think we do
anything at all with that state.
Perhaps the flaw here is simply not masking TxDescUnavail while we are
in NAPI mode?
Eric
^ permalink raw reply
* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
From: Rafael J. Wysocki @ 2009-08-25 21:05 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Francis Moreau, netdev
In-Reply-To: <JuOd1ZASH0B.A.YGB.0zGlKB@chimera>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter : Francis Moreau <francis.moro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-05-03 16:22 (115 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
^ permalink raw reply
* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: David Dillow @ 2009-08-25 20:40 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <m1prajabk8.fsf@fess.ebiederm.org>
On Tue, 2009-08-25 at 13:22 -0700, Eric W. Biederman wrote:
> David Dillow <dave@thedillows.org> writes:
> > I'm not real happy with the interrupt handling in the driver; it makes a
> > certain amount of sense to split the MSI vs non-MSI interrupt cases out.
> > It also means another pass through re-auditing things against the vendor
> > driver. That's more work than I'm able to commit to at the moment.
> >
> > I've not been able to reproduce it locally on my r8169d, running for ~30
> > minutes straight at full speed. I've not tried running it in UP, though.
> > Perhaps I can do that tomorrow.
> >
> > Here's a possible patch to mask the NAPI events while we're running in
> > NAPI mode. I'm not sure it is going to help, since the intr_mask was
> > 0xffff when you hit the loop guard, so I left it in for now.
>
> Interesting.
>
> If I understand this correctly the situation is that we have on the
> chip there is correct logic for a level triggered interrupt and that
> the msi logic sits on it and sends an event when the interrupt signal
> goes high, but when we acknowledge some bits but not all it does not
> send another interrupt.
Correct, we have to acknowledge all current outstanding event sources
before we get another MSI interrupt. It looks like the MSI interrupt is
triggered on the edge transition of a logical OR of all irq sources.
> Baring playing games with what version of the card has working logic
> and which does not we seem to have to simple choices (if we don't want
> to loop possibly forever).
> - Don't use the msi logic on this card.
> - Move all of the logic into rtl8169_poll and only come out of NAPI
> mode when we have caught up with all of the interrupt work.
>
> Is that how you understand the hardware issue you are trying to work
> around?
That's how I understood the issue I was working around with the
problematic patch, but I thought I had covered both issues fairly well
without having to split the handling any further -- we ACK all existing
sources each pass through the loop, so we'll get a new interrupt on the
unmasked events, but not on ones we've masked out for NAPI until NAPI
completes and unmasks them.
I'm curious how you managed to receive an packet between us clearing the
all current sources and reading the current source list continuously for
60+ seconds -- the loop is basically
status = get IRQ events from chip
while (status) {
/* process events, start NAPI if needed */
clear current events from chip
status = get IRQ events from chip
}
That seems like a very small race window to consistently hit --
especially for long enough to trigger soft lockups.
^ permalink raw reply
* 2.6.31-rc7-git2: Reported regressions 2.6.29 -> 2.6.30
From: Rafael J. Wysocki @ 2009-08-25 20:37 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Natalie Protasevich, Linux ACPI, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List
This message contains a list of some regressions introduced between 2.6.29 and
2.6.30, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.29
and 2.6.30, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-08-26 152 33 30
2009-08-20 150 35 32
2009-08-10 148 39 37
2009-08-02 145 44 39
2009-07-27 143 48 45
2009-07-07 138 50 46
2009-06-29 133 46 43
2009-06-07 110 35 31
2009-05-31 100 32 27
2009-05-24 92 34 27
2009-05-16 81 36 33
2009-04-25 55 36 26
2009-04-17 37 35 28
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14049
Subject : joydev: blacklist digitizers avoids recognition of Saitek X52 joysticks
Submitter : Janos Laube <janos.dev@gmail.com>
Date : 2009-08-24 14:18 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d07a9cba6be5c0e947afc1014b5a62182a86f1f1
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13958
Subject : ath5k Atheros AR5001 low signal
Submitter : Marco Siviero <darker1985@slacky.it>
Date : 2009-08-10 15:03 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13949
Subject : XFS regression
Submitter : Justin Piszcz <jpiszcz@lucidpixels.com>
Date : 2009-08-08 8:39 (18 days old)
References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898
Subject : Intel 3945ABG - problems on 2.6.30.X
Submitter : dienet <dienet@poczta.fm>
Date : 2009-07-31 15:17 (26 days old)
References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797
Subject : iBook G4 doesn't suspend since 2ed8d2b3a8
Submitter : Jörg Sommer <joerg@alea.gnuu.de>
Date : 2009-07-18 20:18 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795
Subject : abnormal boot and no suspend due to 'async' (fastboot)
Submitter : Rafal Kaczynski <fscnoboot@wp.pl>
Date : 2009-07-18 17:19 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780
Subject : NULL pointer dereference loading powernowk8
Submitter : Kurt Roeckx <kurt@roeckx.be>
Date : 2009-07-15 18:00 (42 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13770
Subject : System freeze on XFS filesystem recovery on an external disk
Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com>
Date : 2009-07-14 10:31 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739
Subject : 2.6.30 leaking keys on console switch
Submitter : Andi Kleen <andi@firstfloor.org>
Date : 2009-07-07 8:44 (50 days old)
References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4
Handled-By : Jiri Kosina <jkosina@suse.cz>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694
Subject : i915 phantom TV
Submitter : Maciek Józiewicz <mjoziew@gmail.com>
Date : 2009-07-02 12:26 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682
Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30
Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com>
Date : 2009-06-30 13:34 (57 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646
Subject : warn_on tty_io.c, broken bluetooth
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-06-19 17:05 (68 days old)
References : http://lkml.org/lkml/2009/6/19/187
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583
Subject : pdflush uses 5% CPU on otherwise idle system
Submitter : Paul Martin <pm@debian.org>
Date : 2009-06-19 13:33 (68 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581
Subject : ath9k doesn't work with newer kernels
Submitter : Matteo <rootkit85@yahoo.it>
Date : 2009-06-19 12:04 (68 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564
Subject : random general protection fault at boot time caused by khubd.
Submitter : Pauli <suokkos@gmail.com>
Date : 2009-06-18 12:44 (69 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558
Subject : Tracelog during resume
Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date : 2009-06-17 11:32 (70 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514
Subject : acer_wmi causes stack corruption
Submitter : Rus <harbour@sfinx.od.ua>
Date : 2009-06-12 08:13 (75 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512
Subject : D43 on 2.6.30 doesn't suspend anymore
Submitter : Daniel Smolik <marvin@mydatex.cz>
Date : 2009-06-11 20:12 (76 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502
Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
Submitter : <sveina@gmail.com>
Date : 2009-06-10 20:04 (77 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408
Subject : Performance regression in 2.6.30-rc7
Submitter : Diego Calleja <diegocg@gmail.com>
Date : 2009-05-30 18:51 (88 days old)
References : http://lkml.org/lkml/2009/5/30/146
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407
Subject : adb trackpad disappears after suspend to ram
Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de>
Date : 2009-05-28 7:59 (90 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401
Subject : pktcdvd writing is really slow with CFQ scheduler (bisected)
Submitter : Laurent Riffard <laurent.riffard@free.fr>
Date : 2009-05-28 18:43 (90 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
Subject : rt2x00: slow wifi with correct basic rate bitmap
Submitter : Alejandro Riveira <ariveira@gmail.com>
Date : 2009-05-22 13:32 (96 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject : 2.6.30 - 2.6.31 corrupts my system after suspend resume with readonly mounted hard disk
Submitter : <unggnu@googlemail.com>
Date : 2009-05-20 14:09 (98 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742
Handled-By : Yinghai Lu <yinghai@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject : Random Oops at boot at loading ip6tables rules
Submitter : <patrick@ostenberg.de>
Date : 2009-05-19 09:08 (99 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter : Francis Moreau <francis.moro@gmail.com>
Date : 2009-05-03 16:22 (115 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject : AGP doesn't work anymore on nforce2
Submitter : Karsten Mehrhoff <kawime@gmx.de>
Date : 2009-04-30 8:51 (118 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By : Shaohua Li <shaohua.li@intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject : hibernate slow on _second_ run
Submitter : Johannes Berg <johannes@sipsolutions.net>
Date : 2009-05-14 09:34 (104 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6
Submitter : David Hill <hilld@binarystorm.net>
Date : 2009-05-01 16:57 (117 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-04-21 21:35 (127 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14059
Subject : DomU crashes during xenfb initialization
Submitter : Michal Schmidt <mschmidt@redhat.com>
Date : 2009-08-21 10:40 (5 days old)
References : http://marc.info/?l=linux-kernel&m=125085108431360&w=4
Handled-By : Michal Schmidt <mschmidt@redhat.com>
Patch : http://patchwork.kernel.org/patch/43107/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389
Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be
Submitter : Frans Pop <elendil@planet.nl>
Date : 2009-05-26 15:24 (92 days old)
Handled-By : Frans Pop <elendil@planet.nl>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671
http://bugzilla.kernel.org/attachment.cgi?id=21672
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject : Page allocation failures with b43 and p54usb
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2009-04-29 21:01 (119 days old)
References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
http://lkml.org/lkml/2009/6/7/136
http://lkml.org/lkml/2009/7/26/213
Handled-By : Johannes Berg <johannes@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.29 and 2.6.30, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13070
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* [PATCH 05/12] tg3: Add 57788, remove 57720
From: Matt Carlson @ 2009-08-25 20:08 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patch adds support for the 57788 and removes support for the 57720
which was never released.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 5 ++++-
drivers/net/tg3.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 356b5d0..9ae3320 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -223,7 +223,7 @@ static struct pci_device_id tg3_pci_tbl[] = {
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57780)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57760)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57790)},
- {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57720)},
+ {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57788)},
{PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_9DXX)},
{PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_9MXX)},
{PCI_DEVICE(PCI_VENDOR_ID_ALTIMA, PCI_DEVICE_ID_ALTIMA_AC1000)},
@@ -11525,6 +11525,9 @@ out_not_found:
else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57780 &&
tp->pdev->device == TG3PCI_DEVICE_TIGON3_57790)
strcpy(tp->board_part_number, "BCM57790");
+ else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57780 &&
+ tp->pdev->device == TG3PCI_DEVICE_TIGON3_57788)
+ strcpy(tp->board_part_number, "BCM57788");
else
strcpy(tp->board_part_number, "none");
}
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index bb8591e..636008c 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -43,7 +43,7 @@
#define TG3PCI_DEVICE_TIGON3_57780 0x1692
#define TG3PCI_DEVICE_TIGON3_57760 0x1690
#define TG3PCI_DEVICE_TIGON3_57790 0x1694
-#define TG3PCI_DEVICE_TIGON3_57720 0x168c
+#define TG3PCI_DEVICE_TIGON3_57788 0x1691
/* 0x04 --> 0x64 unused */
#define TG3PCI_MSI_DATA 0x00000064
/* 0x66 --> 0x68 unused */
--
1.6.3.3
^ permalink raw reply related
* [PATCH 00/12] tg3: Updates and bugfixes
From: Matt Carlson @ 2009-08-25 20:06 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patchset contains a set of bugfixes for the tg3 driver.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
^ permalink raw reply
* [PATCH 02/12] tg3: Prevent tx BD corruption
From: Matt Carlson @ 2009-08-25 20:07 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patch prevents a tx BD corruption bug by preventing the device from
powering down the PLL from L1 if the link speed is 10Mbps or 100Mbps.
The same bits are also used to prevent a system hang during chip reset
resulting from a complicated set of events that ultimately leads to
PCIe block register corruption.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 28 ++++++++++++++++++++++++++++
drivers/net/tg3.h | 9 ++++++++-
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index e8def28..595ddf2 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3167,6 +3167,15 @@ relink:
pci_write_config_word(tp->pdev,
tp->pcie_cap + PCI_EXP_LNKCTL,
newlnkctl);
+ } else if (tp->tg3_flags3 & TG3_FLG3_TOGGLE_10_100_L1PLLPD) {
+ u32 newreg, oldreg = tr32(TG3_PCIE_LNKCTL);
+ if (tp->link_config.active_speed == SPEED_100 ||
+ tp->link_config.active_speed == SPEED_10)
+ newreg = oldreg & ~TG3_PCIE_LNKCTL_L1_PLL_PD_EN;
+ else
+ newreg = oldreg | TG3_PCIE_LNKCTL_L1_PLL_PD_EN;
+ if (newreg != oldreg)
+ tw32(TG3_PCIE_LNKCTL, newreg);
}
if (current_link_up != netif_carrier_ok(tp->dev)) {
@@ -6160,6 +6169,11 @@ static int tg3_chip_reset(struct tg3 *tp)
smp_mb();
synchronize_irq(tp->pdev->irq);
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57780) {
+ val = tr32(TG3_PCIE_LNKCTL) & ~TG3_PCIE_LNKCTL_L1_PLL_PD_EN;
+ tw32(TG3_PCIE_LNKCTL, val | TG3_PCIE_LNKCTL_L1_PLL_PD_DIS);
+ }
+
/* do the reset */
val = GRC_MISC_CFG_CORECLK_RESET;
@@ -6726,6 +6740,15 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
tw32(TG3_CORR_ERR_STAT, TG3_CORR_ERR_STAT_CLEAR);
}
+ if (tp->tg3_flags3 & TG3_FLG3_TOGGLE_10_100_L1PLLPD) {
+ val = tr32(TG3_PCIE_LNKCTL);
+ if (tp->tg3_flags3 & TG3_FLG3_CLKREQ_BUG)
+ val |= TG3_PCIE_LNKCTL_L1_PLL_PD_DIS;
+ else
+ val &= ~TG3_PCIE_LNKCTL_L1_PLL_PD_DIS;
+ tw32(TG3_PCIE_LNKCTL, val);
+ }
+
/* This works around an issue with Athlon chipsets on
* B3 tigon3 silicon. This bit has no effect on any
* other revision. But do not set this on PCI Express
@@ -12274,6 +12297,11 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_57780)
tp->tg3_flags3 |= TG3_FLG3_USE_PHYLIB;
+ if ((tp->pci_chip_rev_id == CHIPREV_ID_57780_A1 &&
+ tr32(RCVLPC_STATS_ENABLE) & RCVLPC_STATSENAB_ASF_FIX) ||
+ tp->pci_chip_rev_id == CHIPREV_ID_57780_A0)
+ tp->tg3_flags3 |= TG3_FLG3_TOGGLE_10_100_L1PLLPD;
+
err = tg3_mdio_init(tp);
if (err)
return err;
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index c613cbb..bb8591e 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -866,6 +866,7 @@
#define RCVLPC_STATSCTRL_ENABLE 0x00000001
#define RCVLPC_STATSCTRL_FASTUPD 0x00000002
#define RCVLPC_STATS_ENABLE 0x00002018
+#define RCVLPC_STATSENAB_ASF_FIX 0x00000002
#define RCVLPC_STATSENAB_DACK_FIX 0x00040000
#define RCVLPC_STATSENAB_LNGBRST_RFIX 0x00400000
#define RCVLPC_STATS_INCMASK 0x0000201c
@@ -1704,7 +1705,12 @@
#define PCIE_PWR_MGMT_L1_THRESH_MSK 0x0000ff00
#define PCIE_PWR_MGMT_L1_THRESH_4MS 0x0000ff00
#define PCIE_PWR_MGMT_EXT_ASPM_TMR_EN 0x01000000
-/* 0x7d2c --> 0x7e70 unused */
+/* 0x7d2c --> 0x7d54 unused */
+
+#define TG3_PCIE_LNKCTL 0x00007d54
+#define TG3_PCIE_LNKCTL_L1_PLL_PD_EN 0x00000008
+#define TG3_PCIE_LNKCTL_L1_PLL_PD_DIS 0x00000080
+/* 0x7d58 --> 0x7e70 unused */
#define TG3_PCIE_EIDLE_DELAY 0x00007e70
#define TG3_PCIE_EIDLE_DELAY_MASK 0x0000001f
@@ -2650,6 +2656,7 @@ struct tg3 {
#define TG3_FLG3_PHY_ENABLE_APD 0x00001000
#define TG3_FLG3_5755_PLUS 0x00002000
#define TG3_FLG3_NO_NVRAM 0x00004000
+#define TG3_FLG3_TOGGLE_10_100_L1PLLPD 0x00008000
struct timer_list timer;
u16 timer_counter;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 04/12] tg3: Preserve PCIe MPS setting for new devs
From: Matt Carlson @ 2009-08-25 20:08 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
Most older tg3 devices only supported a PCIe maximum payload size of
128 bytes. More recent devices bump this limit up to 256 bytes
though. This patch modifies the code so that the MPS limit is only
enforced on those devices that only allow the 128 byte setting.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index ca3052d..356b5d0 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6226,6 +6226,8 @@ static int tg3_chip_reset(struct tg3 *tp)
udelay(120);
if ((tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS) && tp->pcie_cap) {
+ u16 val16;
+
if (tp->pci_chip_rev_id == CHIPREV_ID_5750_A0) {
int i;
u32 cfg_val;
@@ -6239,12 +6241,22 @@ static int tg3_chip_reset(struct tg3 *tp)
cfg_val | (1 << 15));
}
- /* Set PCIE max payload size to 128 bytes and
- * clear the "no snoop" and "relaxed ordering" bits.
+ /* Clear the "no snoop" and "relaxed ordering" bits. */
+ pci_read_config_word(tp->pdev,
+ tp->pcie_cap + PCI_EXP_DEVCTL,
+ &val16);
+ val16 &= ~(PCI_EXP_DEVCTL_RELAX_EN |
+ PCI_EXP_DEVCTL_NOSNOOP_EN);
+ /*
+ * Older PCIe devices only support the 128 byte
+ * MPS setting. Enforce the restriction.
*/
+ if (!(tp->tg3_flags & TG3_FLAG_CPMU_PRESENT) ||
+ (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5784))
+ val16 &= ~PCI_EXP_DEVCTL_PAYLOAD;
pci_write_config_word(tp->pdev,
tp->pcie_cap + PCI_EXP_DEVCTL,
- 0);
+ val16);
pcie_set_readrq(tp->pdev, 4096);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 10/12] broadcom: Add AC131 phy support
From: Matt Carlson @ 2009-08-25 20:10 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patch adds support for the AC131 fast ethernet transceiver.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/phy/broadcom.c | 158 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 158 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index dec4dec..3262a24 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -142,6 +142,35 @@
#define PHY_BCM_FLAGS_MODE_1000BX 0x00000002
#define PHY_BCM_FLAGS_MODE_COPPER 0x00000001
+
+/*****************************************************************************/
+/* Fast Ethernet Transceiver definitions. */
+/*****************************************************************************/
+
+#define MII_BRCM_FET_INTREG 0x1a /* Interrupt register */
+#define MII_BRCM_FET_IR_MASK 0x0100 /* Mask all interrupts */
+#define MII_BRCM_FET_IR_LINK_EN 0x0200 /* Link status change enable */
+#define MII_BRCM_FET_IR_SPEED_EN 0x0400 /* Link speed change enable */
+#define MII_BRCM_FET_IR_DUPLEX_EN 0x0800 /* Duplex mode change enable */
+#define MII_BRCM_FET_IR_ENABLE 0x4000 /* Interrupt enable */
+
+#define MII_BRCM_FET_BRCMTEST 0x1f /* Brcm test register */
+#define MII_BRCM_FET_BT_SRE 0x0080 /* Shadow register enable */
+
+
+/*** Shadow register definitions ***/
+
+#define MII_BRCM_FET_SHDW_MISCCTRL 0x10 /* Shadow misc ctrl */
+#define MII_BRCM_FET_SHDW_MC_FAME 0x4000 /* Force Auto MDIX enable */
+
+#define MII_BRCM_FET_SHDW_AUXMODE4 0x1a /* Auxiliary mode 4 */
+#define MII_BRCM_FET_SHDW_AM4_LED_MASK 0x0003
+#define MII_BRCM_FET_SHDW_AM4_LED_MODE1 0x0001
+
+#define MII_BRCM_FET_SHDW_AUXSTAT2 0x1b /* Auxiliary status 2 */
+#define MII_BRCM_FET_SHDW_AS2_APDE 0x0020 /* Auto power down enable */
+
+
MODULE_DESCRIPTION("Broadcom PHY driver");
MODULE_AUTHOR("Maciej W. Rozycki");
MODULE_LICENSE("GPL");
@@ -436,6 +465,114 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
return ret;
}
+static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
+{
+ int val;
+
+ val = phy_read(phydev, reg);
+ if (val < 0)
+ return val;
+
+ return phy_write(phydev, reg, val | set);
+}
+
+static int brcm_fet_config_init(struct phy_device *phydev)
+{
+ int reg, err, err2, brcmtest;
+
+ /* Reset the PHY to bring it to a known state. */
+ err = phy_write(phydev, MII_BMCR, BMCR_RESET);
+ if (err < 0)
+ return err;
+
+ reg = phy_read(phydev, MII_BRCM_FET_INTREG);
+ if (reg < 0)
+ return reg;
+
+ /* Unmask events we are interested in and mask interrupts globally. */
+ reg = MII_BRCM_FET_IR_DUPLEX_EN |
+ MII_BRCM_FET_IR_SPEED_EN |
+ MII_BRCM_FET_IR_LINK_EN |
+ MII_BRCM_FET_IR_ENABLE |
+ MII_BRCM_FET_IR_MASK;
+
+ err = phy_write(phydev, MII_BRCM_FET_INTREG, reg);
+ if (err < 0)
+ return err;
+
+ /* Enable shadow register access */
+ brcmtest = phy_read(phydev, MII_BRCM_FET_BRCMTEST);
+ if (brcmtest < 0)
+ return brcmtest;
+
+ reg = brcmtest | MII_BRCM_FET_BT_SRE;
+
+ err = phy_write(phydev, MII_BRCM_FET_BRCMTEST, reg);
+ if (err < 0)
+ return err;
+
+ /* Set the LED mode */
+ reg = phy_read(phydev, MII_BRCM_FET_SHDW_AUXMODE4);
+ if (reg < 0) {
+ err = reg;
+ goto done;
+ }
+
+ reg &= ~MII_BRCM_FET_SHDW_AM4_LED_MASK;
+ reg |= MII_BRCM_FET_SHDW_AM4_LED_MODE1;
+
+ err = phy_write(phydev, MII_BRCM_FET_SHDW_AUXMODE4, reg);
+ if (err < 0)
+ goto done;
+
+ /* Enable auto MDIX */
+ err = brcm_phy_setbits(phydev, MII_BRCM_FET_SHDW_MISCCTRL,
+ MII_BRCM_FET_SHDW_MC_FAME);
+ if (err < 0)
+ goto done;
+
+ /* Enable auto power down */
+ err = brcm_phy_setbits(phydev, MII_BRCM_FET_SHDW_AUXSTAT2,
+ MII_BRCM_FET_SHDW_AS2_APDE);
+
+done:
+ /* Disable shadow register access */
+ err2 = phy_write(phydev, MII_BRCM_FET_BRCMTEST, brcmtest);
+ if (!err)
+ err = err2;
+
+ return err;
+}
+
+static int brcm_fet_ack_interrupt(struct phy_device *phydev)
+{
+ int reg;
+
+ /* Clear pending interrupts. */
+ reg = phy_read(phydev, MII_BRCM_FET_INTREG);
+ if (reg < 0)
+ return reg;
+
+ return 0;
+}
+
+static int brcm_fet_config_intr(struct phy_device *phydev)
+{
+ int reg, err;
+
+ reg = phy_read(phydev, MII_BRCM_FET_INTREG);
+ if (reg < 0)
+ return reg;
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ reg &= ~MII_BRCM_FET_IR_MASK;
+ else
+ reg |= MII_BRCM_FET_IR_MASK;
+
+ err = phy_write(phydev, MII_BRCM_FET_INTREG, reg);
+ return err;
+}
+
static struct phy_driver bcm5411_driver = {
.phy_id = 0x00206070,
.phy_id_mask = 0xfffffff0,
@@ -571,6 +708,21 @@ static struct phy_driver bcm57780_driver = {
.driver = { .owner = THIS_MODULE },
};
+static struct phy_driver bcmac131_driver = {
+ .phy_id = 0x0143bc70,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCMAC131",
+ .features = PHY_BASIC_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = brcm_fet_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = brcm_fet_ack_interrupt,
+ .config_intr = brcm_fet_config_intr,
+ .driver = { .owner = THIS_MODULE },
+};
+
static int __init broadcom_init(void)
{
int ret;
@@ -602,8 +754,13 @@ static int __init broadcom_init(void)
ret = phy_driver_register(&bcm57780_driver);
if (ret)
goto out_57780;
+ ret = phy_driver_register(&bcmac131_driver);
+ if (ret)
+ goto out_ac131;
return ret;
+out_ac131:
+ phy_driver_unregister(&bcm57780_driver);
out_57780:
phy_driver_unregister(&bcm50610m_driver);
out_50610m:
@@ -626,6 +783,7 @@ out_5411:
static void __exit broadcom_exit(void)
{
+ phy_driver_unregister(&bcmac131_driver);
phy_driver_unregister(&bcm57780_driver);
phy_driver_unregister(&bcm50610m_driver);
phy_driver_unregister(&bcm50610_driver);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 12/12] tg3: Update version to 3.100
From: Matt Carlson @ 2009-08-25 20:11 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patch updates the tg3 version to 3.100.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 2808152..8af2cdf 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -68,8 +68,8 @@
#define DRV_MODULE_NAME "tg3"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "3.99"
-#define DRV_MODULE_RELDATE "April 20, 2009"
+#define DRV_MODULE_VERSION "3.100"
+#define DRV_MODULE_RELDATE "August 25, 2009"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
--
1.6.3.3
^ permalink raw reply related
* [PATCH 07/12] tg3: Create MII_TG3_FET namespace
From: Matt Carlson @ 2009-08-25 20:09 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
Broadcom's phys come in two distinctly different register layouts. For
the lack of an official term to distinguish between the two formats, we
can loosely categorize them by their fast ethernet or gigabit ethernet
transceiver description. This patch creates the (driver-internal) Fast
Ethernet Transceiver (FET) namespace and converts the 5906 EPHY
definitions over.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 38 +++++++++++++++++++++-----------------
drivers/net/tg3.h | 21 +++++++++++++--------
2 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 41e0d40..800f980 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1514,17 +1514,19 @@ static void tg3_phy_toggle_automdix(struct tg3 *tp, int enable)
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
u32 ephy;
- if (!tg3_readphy(tp, MII_TG3_EPHY_TEST, &ephy)) {
- tg3_writephy(tp, MII_TG3_EPHY_TEST,
- ephy | MII_TG3_EPHY_SHADOW_EN);
- if (!tg3_readphy(tp, MII_TG3_EPHYTST_MISCCTRL, &phy)) {
+ if (!tg3_readphy(tp, MII_TG3_FET_TEST, &ephy)) {
+ u32 reg = MII_TG3_FET_SHDW_MISCCTRL;
+
+ tg3_writephy(tp, MII_TG3_FET_TEST,
+ ephy | MII_TG3_FET_SHADOW_EN);
+ if (!tg3_readphy(tp, reg, &phy)) {
if (enable)
- phy |= MII_TG3_EPHYTST_MISCCTRL_MDIX;
+ phy |= MII_TG3_FET_SHDW_MISCCTRL_MDIX;
else
- phy &= ~MII_TG3_EPHYTST_MISCCTRL_MDIX;
- tg3_writephy(tp, MII_TG3_EPHYTST_MISCCTRL, phy);
+ phy &= ~MII_TG3_FET_SHDW_MISCCTRL_MDIX;
+ tg3_writephy(tp, reg, phy);
}
- tg3_writephy(tp, MII_TG3_EPHY_TEST, ephy);
+ tg3_writephy(tp, MII_TG3_FET_TEST, ephy);
}
} else {
phy = MII_TG3_AUXCTL_MISC_RDSEL_MISC |
@@ -1915,7 +1917,7 @@ out:
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
/* adjust output voltage */
- tg3_writephy(tp, MII_TG3_EPHY_PTEST, 0x12);
+ tg3_writephy(tp, MII_TG3_FET_PTEST, 0x12);
}
tg3_phy_toggle_automdix(tp, 1);
@@ -9747,14 +9749,16 @@ static int tg3_run_loopback(struct tg3 *tp, int loopback_mode)
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
u32 phytest;
- if (!tg3_readphy(tp, MII_TG3_EPHY_TEST, &phytest)) {
- u32 phy;
+ if (!tg3_readphy(tp, MII_TG3_FET_TEST, &phytest)) {
+ u32 phy, reg = MII_TG3_FET_SHDW_AUXSTAT2;
- tg3_writephy(tp, MII_TG3_EPHY_TEST,
- phytest | MII_TG3_EPHY_SHADOW_EN);
- if (!tg3_readphy(tp, 0x1b, &phy))
- tg3_writephy(tp, 0x1b, phy & ~0x20);
- tg3_writephy(tp, MII_TG3_EPHY_TEST, phytest);
+ tg3_writephy(tp, MII_TG3_FET_TEST,
+ phytest | MII_TG3_FET_SHADOW_EN);
+ if (!tg3_readphy(tp, reg, &phy)) {
+ phy &= ~MII_TG3_FET_SHDW_AUXSTAT2_APD;
+ tg3_writephy(tp, reg, phy);
+ }
+ tg3_writephy(tp, MII_TG3_FET_TEST, phytest);
}
val = BMCR_LOOPBACK | BMCR_FULLDPLX | BMCR_SPEED100;
} else
@@ -9767,7 +9771,7 @@ static int tg3_run_loopback(struct tg3 *tp, int loopback_mode)
mac_mode = tp->mac_mode & ~MAC_MODE_PORT_MODE_MASK;
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
- tg3_writephy(tp, MII_TG3_EPHY_PTEST, 0x1800);
+ tg3_writephy(tp, MII_TG3_FET_PTEST, 0x1800);
mac_mode |= MAC_MODE_PORT_MODE_MII;
} else
mac_mode |= MAC_MODE_PORT_MODE_GMII;
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index d096e10..b8339c9 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -1909,7 +1909,6 @@
#define MII_TG3_DSP_RW_PORT 0x15 /* DSP coefficient read/write port */
-#define MII_TG3_EPHY_PTEST 0x17 /* 5906 PHY register */
#define MII_TG3_DSP_ADDRESS 0x17 /* DSP address register */
#define MII_TG3_DSP_TAP1 0x0001
@@ -1976,17 +1975,23 @@
#define MII_TG3_MISC_SHDW_SCR5_LPED 0x0010
#define MII_TG3_MISC_SHDW_SCR5_SEL 0x1400
-
-#define MII_TG3_EPHY_TEST 0x1f /* 5906 PHY register */
-#define MII_TG3_EPHY_SHADOW_EN 0x80
-
-#define MII_TG3_EPHYTST_MISCCTRL 0x10 /* 5906 EPHY misc ctrl shadow register */
-#define MII_TG3_EPHYTST_MISCCTRL_MDIX 0x4000
-
#define MII_TG3_TEST1 0x1e
#define MII_TG3_TEST1_TRIM_EN 0x0010
#define MII_TG3_TEST1_CRC_EN 0x8000
+
+/* Fast Ethernet Tranceiver definitions */
+#define MII_TG3_FET_PTEST 0x17
+#define MII_TG3_FET_TEST 0x1f
+#define MII_TG3_FET_SHADOW_EN 0x0080
+
+#define MII_TG3_FET_SHDW_MISCCTRL 0x10
+#define MII_TG3_FET_SHDW_MISCCTRL_MDIX 0x4000
+
+#define MII_TG3_FET_SHDW_AUXSTAT2 0x1b
+#define MII_TG3_FET_SHDW_AUXSTAT2_APD 0x0020
+
+
/* APE registers. Accessible through BAR1 */
#define TG3_APE_EVENT 0x000c
#define APE_EVENT_1 0x00000001
--
1.6.3.3
^ permalink raw reply related
* [PATCH 09/12] broadcom: Add BCM50610M support
From: Matt Carlson @ 2009-08-25 20:10 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patch adds support for the BCM50610M phy ID.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/phy/broadcom.c | 38 ++++++++++++++++++++++++++++++--------
1 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 190efc3..dec4dec 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -18,6 +18,7 @@
#include <linux/phy.h>
#define PHY_ID_BCM50610 0x0143bd60
+#define PHY_ID_BCM50610M 0x0143bd70
#define MII_BCM54XX_ECR 0x10 /* BCM54xx extended control register */
#define MII_BCM54XX_ECR_IM 0x1000 /* Interrupt mask */
@@ -447,7 +448,7 @@ static struct phy_driver bcm5411_driver = {
.read_status = genphy_read_status,
.ack_interrupt = bcm54xx_ack_interrupt,
.config_intr = bcm54xx_config_intr,
- .driver = { .owner = THIS_MODULE },
+ .driver = { .owner = THIS_MODULE },
};
static struct phy_driver bcm5421_driver = {
@@ -462,7 +463,7 @@ static struct phy_driver bcm5421_driver = {
.read_status = genphy_read_status,
.ack_interrupt = bcm54xx_ack_interrupt,
.config_intr = bcm54xx_config_intr,
- .driver = { .owner = THIS_MODULE },
+ .driver = { .owner = THIS_MODULE },
};
static struct phy_driver bcm5461_driver = {
@@ -477,7 +478,7 @@ static struct phy_driver bcm5461_driver = {
.read_status = genphy_read_status,
.ack_interrupt = bcm54xx_ack_interrupt,
.config_intr = bcm54xx_config_intr,
- .driver = { .owner = THIS_MODULE },
+ .driver = { .owner = THIS_MODULE },
};
static struct phy_driver bcm5464_driver = {
@@ -492,7 +493,7 @@ static struct phy_driver bcm5464_driver = {
.read_status = genphy_read_status,
.ack_interrupt = bcm54xx_ack_interrupt,
.config_intr = bcm54xx_config_intr,
- .driver = { .owner = THIS_MODULE },
+ .driver = { .owner = THIS_MODULE },
};
static struct phy_driver bcm5481_driver = {
@@ -507,7 +508,7 @@ static struct phy_driver bcm5481_driver = {
.read_status = genphy_read_status,
.ack_interrupt = bcm54xx_ack_interrupt,
.config_intr = bcm54xx_config_intr,
- .driver = { .owner = THIS_MODULE },
+ .driver = { .owner = THIS_MODULE },
};
static struct phy_driver bcm5482_driver = {
@@ -522,7 +523,7 @@ static struct phy_driver bcm5482_driver = {
.read_status = bcm5482_read_status,
.ack_interrupt = bcm54xx_ack_interrupt,
.config_intr = bcm54xx_config_intr,
- .driver = { .owner = THIS_MODULE },
+ .driver = { .owner = THIS_MODULE },
};
static struct phy_driver bcm50610_driver = {
@@ -537,7 +538,22 @@ static struct phy_driver bcm50610_driver = {
.read_status = genphy_read_status,
.ack_interrupt = bcm54xx_ack_interrupt,
.config_intr = bcm54xx_config_intr,
- .driver = { .owner = THIS_MODULE },
+ .driver = { .owner = THIS_MODULE },
+};
+
+static struct phy_driver bcm50610m_driver = {
+ .phy_id = PHY_ID_BCM50610M,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM50610M",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm54xx_ack_interrupt,
+ .config_intr = bcm54xx_config_intr,
+ .driver = { .owner = THIS_MODULE },
};
static struct phy_driver bcm57780_driver = {
@@ -552,7 +568,7 @@ static struct phy_driver bcm57780_driver = {
.read_status = genphy_read_status,
.ack_interrupt = bcm54xx_ack_interrupt,
.config_intr = bcm54xx_config_intr,
- .driver = { .owner = THIS_MODULE },
+ .driver = { .owner = THIS_MODULE },
};
static int __init broadcom_init(void)
@@ -580,12 +596,17 @@ static int __init broadcom_init(void)
ret = phy_driver_register(&bcm50610_driver);
if (ret)
goto out_50610;
+ ret = phy_driver_register(&bcm50610m_driver);
+ if (ret)
+ goto out_50610m;
ret = phy_driver_register(&bcm57780_driver);
if (ret)
goto out_57780;
return ret;
out_57780:
+ phy_driver_unregister(&bcm50610m_driver);
+out_50610m:
phy_driver_unregister(&bcm50610_driver);
out_50610:
phy_driver_unregister(&bcm5482_driver);
@@ -606,6 +627,7 @@ out_5411:
static void __exit broadcom_exit(void)
{
phy_driver_unregister(&bcm57780_driver);
+ phy_driver_unregister(&bcm50610m_driver);
phy_driver_unregister(&bcm50610_driver);
phy_driver_unregister(&bcm5482_driver);
phy_driver_unregister(&bcm5481_driver);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 06/12] tg3: Tune 5785 clock switching
From: Matt Carlson @ 2009-08-25 20:09 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patch tunes the timeouts the CPMU uses to decide when to switch
from the clocks output by the PHY to internal clock sources.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 15 ++++++++++-----
drivers/net/tg3.h | 4 ++++
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 9ae3320..41e0d40 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -917,7 +917,9 @@ static void tg3_mdio_config_5785(struct tg3 *tp)
tw32(MAC_PHYCFG2, val);
val = tr32(MAC_PHYCFG1);
- val &= ~MAC_PHYCFG1_RGMII_INT;
+ val &= ~(MAC_PHYCFG1_RGMII_INT |
+ MAC_PHYCFG1_RXCLK_TO_MASK | MAC_PHYCFG1_TXCLK_TO_MASK);
+ val |= MAC_PHYCFG1_RXCLK_TIMEOUT | MAC_PHYCFG1_TXCLK_TIMEOUT;
tw32(MAC_PHYCFG1, val);
return;
@@ -933,15 +935,18 @@ static void tg3_mdio_config_5785(struct tg3 *tp)
tw32(MAC_PHYCFG2, val);
- val = tr32(MAC_PHYCFG1) & ~(MAC_PHYCFG1_RGMII_EXT_RX_DEC |
- MAC_PHYCFG1_RGMII_SND_STAT_EN);
- if (tp->tg3_flags3 & TG3_FLG3_RGMII_STD_IBND_DISABLE) {
+ val = tr32(MAC_PHYCFG1);
+ val &= ~(MAC_PHYCFG1_RXCLK_TO_MASK | MAC_PHYCFG1_TXCLK_TO_MASK |
+ MAC_PHYCFG1_RGMII_EXT_RX_DEC | MAC_PHYCFG1_RGMII_SND_STAT_EN);
+ if (!(tp->tg3_flags3 & TG3_FLG3_RGMII_STD_IBND_DISABLE)) {
if (tp->tg3_flags3 & TG3_FLG3_RGMII_EXT_IBND_RX_EN)
val |= MAC_PHYCFG1_RGMII_EXT_RX_DEC;
if (tp->tg3_flags3 & TG3_FLG3_RGMII_EXT_IBND_TX_EN)
val |= MAC_PHYCFG1_RGMII_SND_STAT_EN;
}
- tw32(MAC_PHYCFG1, val | MAC_PHYCFG1_RGMII_INT | MAC_PHYCFG1_TXC_DRV);
+ val |= MAC_PHYCFG1_RXCLK_TIMEOUT | MAC_PHYCFG1_TXCLK_TIMEOUT |
+ MAC_PHYCFG1_RGMII_INT | MAC_PHYCFG1_TXC_DRV;
+ tw32(MAC_PHYCFG1, val);
val = tr32(MAC_EXT_RGMII_MODE);
val &= ~(MAC_RGMII_MODE_RX_INT_B |
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 636008c..d096e10 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -524,6 +524,10 @@
/* 0x598 --> 0x5a0 unused */
#define MAC_PHYCFG1 0x000005a0
#define MAC_PHYCFG1_RGMII_INT 0x00000001
+#define MAC_PHYCFG1_RXCLK_TO_MASK 0x00001ff0
+#define MAC_PHYCFG1_RXCLK_TIMEOUT 0x00001000
+#define MAC_PHYCFG1_TXCLK_TO_MASK 0x01ff0000
+#define MAC_PHYCFG1_TXCLK_TIMEOUT 0x01000000
#define MAC_PHYCFG1_RGMII_EXT_RX_DEC 0x02000000
#define MAC_PHYCFG1_RGMII_SND_STAT_EN 0x04000000
#define MAC_PHYCFG1_TXC_DRV 0x20000000
--
1.6.3.3
^ permalink raw reply related
* [PATCH 11/12] broadcom: Make the 57780 IEEE compliant
From: Matt Carlson @ 2009-08-25 20:11 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This brings the 57780's phy into IEEE compliance by suppressing the
common mode oscillation.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/phy/broadcom.c | 37 +++++++++++++++++++++++++++++++++++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 3262a24..f81e532 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -19,6 +19,11 @@
#define PHY_ID_BCM50610 0x0143bd60
#define PHY_ID_BCM50610M 0x0143bd70
+#define PHY_ID_BCM57780 0x03625d90
+
+#define BRCM_PHY_MODEL(phydev) \
+ ((phydev)->drv->phy_id & (phydev)->drv->phy_id_mask)
+
#define MII_BCM54XX_ECR 0x10 /* BCM54xx extended control register */
#define MII_BCM54XX_ECR_IM 0x1000 /* Interrupt mask */
@@ -118,6 +123,7 @@
#define MII_BCM54XX_EXP_EXP08_EARLY_DAC_WAKE 0x0200
#define MII_BCM54XX_EXP_EXP75 0x0f75
#define MII_BCM54XX_EXP_EXP75_VDACCTRL 0x003c
+#define MII_BCM54XX_EXP_EXP75_CM_OSC 0x0001
#define MII_BCM54XX_EXP_EXP96 0x0f96
#define MII_BCM54XX_EXP_EXP96_MYST 0x0010
#define MII_BCM54XX_EXP_EXP97 0x0f97
@@ -194,7 +200,7 @@ static int bcm54xx_shadow_write(struct phy_device *phydev, u16 shadow, u16 val)
}
/* Indirect register access functions for the Expansion Registers */
-static int bcm54xx_exp_read(struct phy_device *phydev, u8 regnum)
+static int bcm54xx_exp_read(struct phy_device *phydev, u16 regnum)
{
int val;
@@ -308,6 +314,33 @@ static int bcm54xx_config_init(struct phy_device *phydev)
return err;
}
+ if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM57780) {
+ int err2;
+
+ err = bcm54xx_auxctl_write(phydev,
+ MII_BCM54XX_AUXCTL_SHDWSEL_AUXCTL,
+ MII_BCM54XX_AUXCTL_ACTL_SMDSP_ENA |
+ MII_BCM54XX_AUXCTL_ACTL_TX_6DB);
+ if (err < 0)
+ return err;
+
+ reg = bcm54xx_exp_read(phydev, MII_BCM54XX_EXP_EXP75);
+ if (reg < 0)
+ goto error;
+
+ reg |= MII_BCM54XX_EXP_EXP75_CM_OSC;
+ err = bcm54xx_exp_write(phydev, MII_BCM54XX_EXP_EXP75, reg);
+
+error:
+ err2 = bcm54xx_auxctl_write(phydev,
+ MII_BCM54XX_AUXCTL_SHDWSEL_AUXCTL,
+ MII_BCM54XX_AUXCTL_ACTL_TX_6DB);
+ if (err)
+ return err;
+ if (err2)
+ return err2;
+ }
+
return 0;
}
@@ -694,7 +727,7 @@ static struct phy_driver bcm50610m_driver = {
};
static struct phy_driver bcm57780_driver = {
- .phy_id = 0x03625d90,
+ .phy_id = PHY_ID_BCM57780,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM57780",
.features = PHY_GBIT_FEATURES |
--
1.6.3.3
^ permalink raw reply related
* [PATCH 03/12] tg3: Fix TSO test against wrong flags var
From: Matt Carlson @ 2009-08-25 20:07 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
Julia Lawall discovered that the TG3_FLG2_TSO_CAPABLE flag was being
compared against the wrong flags device member. This patch implements
the fix.
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 595ddf2..ca3052d 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7192,7 +7192,7 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705 &&
tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750) {
- if ((tp->tg3_flags & TG3_FLG2_TSO_CAPABLE) &&
+ if ((tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE) &&
(tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 ||
tp->pci_chip_rev_id == CHIPREV_ID_5705_A2)) {
/* nothing */
--
1.6.3.3
^ permalink raw reply related
* [PATCH 08/12] tg3: Convert code to use PHY_IS_FET
From: Matt Carlson @ 2009-08-25 20:10 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patch converts the code to use the PHY_IS_FET flag rather than the
ASIC revision to decide whether or not to use FET paths.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 73 +++++++++++++++++++++++++++++++++-------------------
drivers/net/tg3.h | 1 +
2 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 800f980..2808152 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -784,7 +784,7 @@ static int tg3_writephy(struct tg3 *tp, int reg, u32 val)
unsigned int loops;
int ret;
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906 &&
+ if ((tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET) &&
(reg == MII_TG3_CTRL || reg == MII_TG3_AUX_CTRL))
return 0;
@@ -1069,6 +1069,7 @@ static int tg3_mdio_init(struct tg3 *tp)
case TG3_PHY_ID_RTL8201E:
case TG3_PHY_ID_BCMAC131:
phydev->interface = PHY_INTERFACE_MODE_MII;
+ tp->tg3_flags3 |= TG3_FLG3_PHY_IS_FET;
break;
}
@@ -1474,13 +1475,37 @@ static void tg3_phydsp_write(struct tg3 *tp, u32 reg, u32 val)
tg3_writephy(tp, MII_TG3_DSP_RW_PORT, val);
}
+static void tg3_phy_fet_toggle_apd(struct tg3 *tp, bool enable)
+{
+ u32 phytest;
+
+ if (!tg3_readphy(tp, MII_TG3_FET_TEST, &phytest)) {
+ u32 phy;
+
+ tg3_writephy(tp, MII_TG3_FET_TEST,
+ phytest | MII_TG3_FET_SHADOW_EN);
+ if (!tg3_readphy(tp, MII_TG3_FET_SHDW_AUXSTAT2, &phy)) {
+ if (enable)
+ phy |= MII_TG3_FET_SHDW_AUXSTAT2_APD;
+ else
+ phy &= ~MII_TG3_FET_SHDW_AUXSTAT2_APD;
+ tg3_writephy(tp, MII_TG3_FET_SHDW_AUXSTAT2, phy);
+ }
+ tg3_writephy(tp, MII_TG3_FET_TEST, phytest);
+ }
+}
+
static void tg3_phy_toggle_apd(struct tg3 *tp, bool enable)
{
u32 reg;
- if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS) ||
- GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
+ if (!(tp->tg3_flags2 & TG3_FLG2_5705_PLUS))
+ return;
+
+ if (tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET) {
+ tg3_phy_fet_toggle_apd(tp, enable);
return;
+ }
reg = MII_TG3_MISC_SHDW_WREN |
MII_TG3_MISC_SHDW_SCR5_SEL |
@@ -1511,7 +1536,7 @@ static void tg3_phy_toggle_automdix(struct tg3 *tp, int enable)
(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES))
return;
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
+ if (tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET) {
u32 ephy;
if (!tg3_readphy(tp, MII_TG3_FET_TEST, &ephy)) {
@@ -2662,7 +2687,7 @@ static void tg3_aux_stat_to_speed_duplex(struct tg3 *tp, u32 val, u16 *speed, u8
break;
default:
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
+ if (tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET) {
*speed = (val & MII_TG3_AUX_STAT_100) ? SPEED_100 :
SPEED_10;
*duplex = (val & MII_TG3_AUX_STAT_FULL) ? DUPLEX_FULL :
@@ -2997,7 +3022,7 @@ static int tg3_setup_copper_phy(struct tg3 *tp, int force_reset)
if (tp->tg3_flags & TG3_FLAG_USE_MI_INTERRUPT)
tg3_writephy(tp, MII_TG3_IMASK, ~MII_TG3_INT_LINKCHG);
- else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5906)
+ else if (!(tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET))
tg3_writephy(tp, MII_TG3_IMASK, ~0);
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
@@ -3107,7 +3132,9 @@ relink:
tp->mac_mode |= MAC_MODE_PORT_MODE_MII;
else
tp->mac_mode |= MAC_MODE_PORT_MODE_GMII;
- } else
+ } else if (tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET)
+ tp->mac_mode |= MAC_MODE_PORT_MODE_MII;
+ else
tp->mac_mode |= MAC_MODE_PORT_MODE_GMII;
tp->mac_mode &= ~MAC_MODE_HALF_DUPLEX;
@@ -7349,7 +7376,7 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
return err;
if (!(tp->tg3_flags2 & TG3_FLG2_PHY_SERDES) &&
- GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5906) {
+ !(tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET)) {
u32 tmp;
/* Clear CRC stats. */
@@ -9746,20 +9773,8 @@ static int tg3_run_loopback(struct tg3 *tp, int loopback_mode)
} else if (loopback_mode == TG3_PHY_LOOPBACK) {
u32 val;
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
- u32 phytest;
-
- if (!tg3_readphy(tp, MII_TG3_FET_TEST, &phytest)) {
- u32 phy, reg = MII_TG3_FET_SHDW_AUXSTAT2;
-
- tg3_writephy(tp, MII_TG3_FET_TEST,
- phytest | MII_TG3_FET_SHADOW_EN);
- if (!tg3_readphy(tp, reg, &phy)) {
- phy &= ~MII_TG3_FET_SHDW_AUXSTAT2_APD;
- tg3_writephy(tp, reg, phy);
- }
- tg3_writephy(tp, MII_TG3_FET_TEST, phytest);
- }
+ if (tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET) {
+ tg3_phy_fet_toggle_apd(tp, false);
val = BMCR_LOOPBACK | BMCR_FULLDPLX | BMCR_SPEED100;
} else
val = BMCR_LOOPBACK | BMCR_FULLDPLX | BMCR_SPEED1000;
@@ -9770,8 +9785,9 @@ static int tg3_run_loopback(struct tg3 *tp, int loopback_mode)
udelay(40);
mac_mode = tp->mac_mode & ~MAC_MODE_PORT_MODE_MASK;
- if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
- tg3_writephy(tp, MII_TG3_FET_PTEST, 0x1800);
+ if (tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET) {
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
+ tg3_writephy(tp, MII_TG3_FET_PTEST, 0x1800);
mac_mode |= MAC_MODE_PORT_MODE_MII;
} else
mac_mode |= MAC_MODE_PORT_MODE_GMII;
@@ -12268,12 +12284,15 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
tp->tg3_flags |= TG3_FLAG_WOL_SPEED_100MB;
}
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
+ tp->tg3_flags3 |= TG3_FLG3_PHY_IS_FET;
+
/* A few boards don't want Ethernet@WireSpeed phy feature */
if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700) ||
((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) &&
(tp->pci_chip_rev_id != CHIPREV_ID_5705_A0) &&
(tp->pci_chip_rev_id != CHIPREV_ID_5705_A1)) ||
- (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) ||
+ (tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET) ||
(tp->tg3_flags2 & TG3_FLG2_ANY_SERDES))
tp->tg3_flags2 |= TG3_FLG2_NO_ETH_WIRE_SPEED;
@@ -12284,7 +12303,7 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
tp->tg3_flags2 |= TG3_FLG2_PHY_5704_A0_BUG;
if ((tp->tg3_flags2 & TG3_FLG2_5705_PLUS) &&
- GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5906 &&
+ !(tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET) &&
GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5785 &&
GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_57780) {
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5755 ||
@@ -12409,7 +12428,7 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
tp->pdev->device == PCI_DEVICE_ID_TIGON3_5753F ||
tp->pdev->device == PCI_DEVICE_ID_TIGON3_5787F)) ||
tp->pdev->device == TG3PCI_DEVICE_TIGON3_57790 ||
- GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)
+ (tp->tg3_flags3 & TG3_FLG3_PHY_IS_FET))
tp->tg3_flags |= TG3_FLAG_10_100_ONLY;
err = tg3_phy_probe(tp);
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index b8339c9..60b12ab 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2666,6 +2666,7 @@ struct tg3 {
#define TG3_FLG3_5755_PLUS 0x00002000
#define TG3_FLG3_NO_NVRAM 0x00004000
#define TG3_FLG3_TOGGLE_10_100_L1PLLPD 0x00008000
+#define TG3_FLG3_PHY_IS_FET 0x00010000
struct timer_list timer;
u16 timer_counter;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 01/12] tg3: Fix 57780 asic rev PCIe link receiver errors
From: Matt Carlson @ 2009-08-25 20:06 UTC (permalink / raw)
To: davem; +Cc: netdev, andy
This patch fixes some PCIe link receiver errors by decreasing the internal
electrical idle timeout.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/tg3.c | 5 +++++
drivers/net/tg3.h | 13 +++++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 46a3f86..e8def28 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6719,6 +6719,11 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
val |= PCIE_PWR_MGMT_EXT_ASPM_TMR_EN |
PCIE_PWR_MGMT_L1_THRESH_4MS;
tw32(PCIE_PWR_MGMT_THRESH, val);
+
+ val = tr32(TG3_PCIE_EIDLE_DELAY) & ~TG3_PCIE_EIDLE_DELAY_MASK;
+ tw32(TG3_PCIE_EIDLE_DELAY, val | TG3_PCIE_EIDLE_DELAY_13_CLKS);
+
+ tw32(TG3_CORR_ERR_STAT, TG3_CORR_ERR_STAT_CLEAR);
}
/* This works around an issue with Athlon chipsets on
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index b3347c4..c613cbb 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -214,9 +214,11 @@
#define DUAL_MAC_CTRL_ID 0x00000004
#define TG3PCI_PRODID_ASICREV 0x000000bc
#define PROD_ID_ASIC_REV_MASK 0x0fffffff
-/* 0xc0 --> 0x100 unused */
+/* 0xc0 --> 0x110 unused */
-/* 0x100 --> 0x200 unused */
+#define TG3_CORR_ERR_STAT 0x00000110
+#define TG3_CORR_ERR_STAT_CLEAR 0xffffffff
+/* 0x114 --> 0x200 unused */
/* Mailbox registers */
#define MAILBOX_INTERRUPT_0 0x00000200 /* 64-bit */
@@ -1696,11 +1698,18 @@
#define PCIE_TRANSACTION_CFG 0x00007c04
#define PCIE_TRANS_CFG_1SHOT_MSI 0x20000000
#define PCIE_TRANS_CFG_LOM 0x00000020
+/* 0x7c08 --> 0x7d28 unused */
#define PCIE_PWR_MGMT_THRESH 0x00007d28
#define PCIE_PWR_MGMT_L1_THRESH_MSK 0x0000ff00
#define PCIE_PWR_MGMT_L1_THRESH_4MS 0x0000ff00
#define PCIE_PWR_MGMT_EXT_ASPM_TMR_EN 0x01000000
+/* 0x7d2c --> 0x7e70 unused */
+
+#define TG3_PCIE_EIDLE_DELAY 0x00007e70
+#define TG3_PCIE_EIDLE_DELAY_MASK 0x0000001f
+#define TG3_PCIE_EIDLE_DELAY_13_CLKS 0x0000000c
+/* 0x7e74 --> 0x8000 unused */
/* OTP bit definitions */
--
1.6.3.3
^ permalink raw reply related
* Re: [Bonding-devel] [PATCH net-next-2.6] bonding: introduce primary_lazy option
From: Nicolas de Pesloüan @ 2009-08-25 20:33 UTC (permalink / raw)
To: Jay Vosburgh, Stephen Hemminger; +Cc: netdev, bonding-devel, davem, Jiri Pirko
In-Reply-To: <16215.1251225681@death.nxdomain.ibm.com>
Jay Vosburgh wrote:
> Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote:
>> Thinking about all that, I start feeling that some sort of user space system to
>> select the "best" slave would be better. If we can design a NETLINK interface to
>> report events (slave up, slave down...) to user space, then any user space
>> daemon would be able to tell bonding what to do. Only if no process register to
>> receive those events would bonding use the normal slave selection rules.
>
> This has been discussed more than once in the past, but hasn't
> ever really gotten anywhere. I suspect the main impediment is the lack
> of a suitable API.
Does a 'NETLINK for bonding' document, describing the proposed API, exist ?
I imagine two different parts in the API :
1/ Everything related to configuration (set and read). This should be not far
from the current sysfs API.
2/ Event notification about "everything" that happens into bonding, to be able
to notify user space in real time.
It might be also interesting to use the netlink API to notify whoever is
interested that a given not-enslaved interface just received a 802.3ad related
packet. This would allow for self enslavement of slaves into the same bond, when
they happen to be connected to the same 802.3ad capable switch.
>> Designing such a NETLINK interface would replace my proposed weight option (at
>> least for best slave selection in active-backup mode and for best aggregator
>> selection in 802.3ad mode). It would also solve the problem reported by Jirka
>> and so replace the proposed primary_lazy option.
>
> Yes, a lot of the decision making at failover could be moved
> into a user space daemon. The daemon, I think, should be optional; if
> the basic selection policies are sufficient, then there's no need for a
> trip to user space and back.
>
>> Any way, NETLINK is something that is supposed to come into bonding at some
>> times, because we know that the sysfs purists hate the sysfs bonding stuff and
>> that NETLINK is the target to setup networking.
>
> I'm not a big fan of the sysfs API, either; it seemed like a
> good idea at the time. It's certainly better than ifenslave in terms of
> features, but some of it is pretty convoluted, and there are things that
> just can't be done from within sysfs.
>
> I recall seeing a note from Stephen Hemminger not too long ago
> (a month or two ago) that he was working on a netlink API for bonding,
> but I don't know how far that ever got.
Yes, I also read this note and remembered he detected that many things need to
be changed before... :-(
> One quesiton is, if a netlink API is implemented, whether to
> convert ifenslave, or deprecate ifenslave and put the various bonding
> functions into ip.
I suggest enhancing ip and removing ifenslave (or converting it to a script that
would call ip internally, for backward compatibility). Why would we need a
dedicated tool for bonding ? We can even write this script now and use sysfs
instead of the ioctl, waiting for the netlink API.
> If a netlink API is on the relatively near horizon (say, within
> a few months), then I'm less inclined to put in the "lazy" option, since
> it would just become baggage carried forward for the next several years
> (until the sysfs API could be deprecated and removed).
Does that mean you suggest Jiri works with Stephen on the netlink API ? :-)
Nicolas.
^ permalink raw reply
* Re: [Patch] Fix commit 63d9950b08184e6531adceb65f64b429909cc101 (ipv6: Make v4-mapped bindings consistent with IPv4)
From: Bruno Prémont @ 2009-08-25 20:20 UTC (permalink / raw)
To: stable; +Cc: David Miller, vladislav.yasevich, netdev
In-Reply-To: <20090823.190715.124304781.davem@davemloft.net>
On Sun, 23 August 2009 David Miller <davem@davemloft.net> wrote:
> From: Bruno Prémont <bonbons@linux-vserver.org>
> Date: Sat, 22 Aug 2009 01:45:23 +0200
>
> > Commit 63d9950b08184e6531adceb65f64b429909cc101
> > (ipv6: Make v4-mapped bindings consistent with IPv4)
> > changes behavior of inet6_bind() for v4-mapped addresses so it
> > should behave the same way as inet_bind().
> >
> > During this change setting of err to -EADDRNOTAVAIL got lost:
> ...
> > Signed-off-by Bruno Prémont <bonbons@linux-vserver.org>
>
> Thanks for finding and fixing this bug, applied, thanks!
Please consider queueing this for 2.6.30.x stable, upstream commit is
ca6982b858e1d08010c1d29d8e8255b2ac2ad70a
Bruno
^ permalink raw reply
* Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts
From: Eric W. Biederman @ 2009-08-25 20:22 UTC (permalink / raw)
To: David Dillow
Cc: Michael Riepe, Michael Buesch, Francois Romieu, Rui Santos,
Michael Büker, linux-kernel, netdev
In-Reply-To: <1251169150.4023.11.camel@obelisk.thedillows.org>
David Dillow <dave@thedillows.org> writes:
> On Mon, 2009-08-24 at 17:51 -0700, Eric W. Biederman wrote:
>> When I decode the bits in status they are TxOK, RxOK and TxDescUnavail so it looks
>> there is some bidirectional communication going on.
>>
>> Do we really want to loop when those bits are set?
>
> Maybe not when only those bits are set, but I worry that we would trade
> one race for another where we stop getting interrupts from the card.
>
>> Perhaps we want to remove them from rtl_cfg_infos for the part?
>
> Then you'd never get an interrupt for them in the first place, I think.
>
> I'm not real happy with the interrupt handling in the driver; it makes a
> certain amount of sense to split the MSI vs non-MSI interrupt cases out.
> It also means another pass through re-auditing things against the vendor
> driver. That's more work than I'm able to commit to at the moment.
>
> I've not been able to reproduce it locally on my r8169d, running for ~30
> minutes straight at full speed. I've not tried running it in UP, though.
> Perhaps I can do that tomorrow.
>
> Here's a possible patch to mask the NAPI events while we're running in
> NAPI mode. I'm not sure it is going to help, since the intr_mask was
> 0xffff when you hit the loop guard, so I left it in for now.
Interesting.
If I understand this correctly the situation is that we have on the
chip there is correct logic for a level triggered interrupt and that
the msi logic sits on it and sends an event when the interrupt signal
goes high, but when we acknowledge some bits but not all it does not
send another interrupt.
Baring playing games with what version of the card has working logic
and which does not we seem to have to simple choices (if we don't want
to loop possibly forever).
- Don't use the msi logic on this card.
- Move all of the logic into rtl8169_poll and only come out of NAPI
mode when we have caught up with all of the interrupt work.
Is that how you understand the hardware issue you are trying to work
around?
Eric
^ permalink raw reply
* Re: iproute2 / tbf with large burst seems broken again
From: Jarek Poplawski @ 2009-08-25 20:03 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: netdev
In-Reply-To: <200908251416.13888.denys@visp.net.lb>
Denys Fedoryschenko wrote, On 08/25/2009 01:16 PM:
...
> But this one maybe will overflow because of limitations in iproute2.
>
> PPoE_146 ~ # ./tc -s -d qdisc show dev ppp13
> qdisc tbf 8004: root rate 96000bit burst 797465b/8 mpu 0b lat 275.4s
> Sent 82867 bytes 123 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc ingress ffff: parent ffff:fff1 ----------------
> Sent 506821 bytes 1916 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
> So maybe all of that just wrong way of using TBF.
I guess so; I've just recollected you described it some time ago. If
it were done only with TBF it would mean very large surges with line
speed and probably a lot of drops by ISP. Since you're ISP, you
probably drop this with HTB or something (then you should mention it
describing the problem) or keep very long queues which means great
latencies. Probably there is a lot of TCP resending btw. Using TBF
with HTB etc. is considered wrong idea anyway. (But if it works for
you shouldn't care.)
> At same time this means, if HTB and policers in filters done same way, that
> QoS in Linux cannot do similar to squid delay pools feature:
>
> First 10Mb give with 1Mbit/s, then slow 64Kbit/s. If user use less than 64K -
> recharge with that unused bandwidth a "10 Mb / 1Mbit bucket".
Could you remind me why HFSC can't do something similar for you?
Jarek P.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox