* [RESEND][PATCH 2/3] ehea: Simplify resource usage check
From: Thomas Klein @ 2007-08-06 11:55 UTC (permalink / raw)
To: Jeff Garzik
Cc: Christoph Raisch, Jan-Bernd Themann, Jan-Bernd Themann,
linux-kernel, linux-ppc, Marcus Eder, netdev, Thomas Klein,
Stefan Roscher
Use shorter method to determine whether adapter has configured ports
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea_main.c | 18 ++++++------------
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index d43ab0f..36ca322 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2165,24 +2165,18 @@ static int ehea_clean_all_portres(struct ehea_port *port)
return ret;
}
-static void ehea_remove_adapter_mr (struct ehea_adapter *adapter)
+static void ehea_remove_adapter_mr(struct ehea_adapter *adapter)
{
- int i;
-
- for (i=0; i < EHEA_MAX_PORTS; i++)
- if (adapter->port[i])
- return;
+ if (adapter->active_ports)
+ return;
ehea_rem_mr(&adapter->mr);
}
-static int ehea_add_adapter_mr (struct ehea_adapter *adapter)
+static int ehea_add_adapter_mr(struct ehea_adapter *adapter)
{
- int i;
-
- for (i=0; i < EHEA_MAX_PORTS; i++)
- if (adapter->port[i])
- return 0;
+ if (adapter->active_ports)
+ return 0;
return ehea_reg_kernel_mr(adapter, &adapter->mr);
}
--
1.5.2
^ permalink raw reply related
* [RESEND][PATCH 3/3] ehea: Eliminated some compiler warnings
From: Thomas Klein @ 2007-08-06 11:55 UTC (permalink / raw)
To: Jeff Garzik
Cc: Christoph Raisch, Jan-Bernd Themann, Jan-Bernd Themann,
linux-kernel, linux-ppc, Marcus Eder, netdev, Thomas Klein,
Stefan Roscher
Fixed wrongly casted pointers
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea_main.c | 25 ++++++++++---------------
1 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 36ca322..9756211 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1326,7 +1326,6 @@ static void write_swqe2_TSO(struct sk_buff *skb,
u8 *imm_data = &swqe->u.immdata_desc.immediate_data[0];
int skb_data_size = skb->len - skb->data_len;
int headersize;
- u64 tmp_addr;
/* Packet is TCP with TSO enabled */
swqe->tx_control |= EHEA_SWQE_TSO;
@@ -1347,9 +1346,8 @@ static void write_swqe2_TSO(struct sk_buff *skb,
/* set sg1entry data */
sg1entry->l_key = lkey;
sg1entry->len = skb_data_size - headersize;
-
- tmp_addr = (u64)(skb->data + headersize);
- sg1entry->vaddr = ehea_map_vaddr(tmp_addr);
+ sg1entry->vaddr =
+ ehea_map_vaddr(skb->data + headersize);
swqe->descriptors++;
}
} else
@@ -1362,7 +1360,6 @@ static void write_swqe2_nonTSO(struct sk_buff *skb,
int skb_data_size = skb->len - skb->data_len;
u8 *imm_data = &swqe->u.immdata_desc.immediate_data[0];
struct ehea_vsgentry *sg1entry = &swqe->u.immdata_desc.sg_entry;
- u64 tmp_addr;
/* Packet is any nonTSO type
*
@@ -1379,8 +1376,8 @@ static void write_swqe2_nonTSO(struct sk_buff *skb,
/* copy sg1entry data */
sg1entry->l_key = lkey;
sg1entry->len = skb_data_size - SWQE2_MAX_IMM;
- tmp_addr = (u64)(skb->data + SWQE2_MAX_IMM);
- sg1entry->vaddr = ehea_map_vaddr(tmp_addr);
+ sg1entry->vaddr =
+ ehea_map_vaddr(skb->data + SWQE2_MAX_IMM);
swqe->descriptors++;
}
} else {
@@ -1395,7 +1392,6 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev,
struct ehea_vsgentry *sg_list, *sg1entry, *sgentry;
skb_frag_t *frag;
int nfrags, sg1entry_contains_frag_data, i;
- u64 tmp_addr;
nfrags = skb_shinfo(skb)->nr_frags;
sg1entry = &swqe->u.immdata_desc.sg_entry;
@@ -1417,9 +1413,9 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev,
/* copy sg1entry data */
sg1entry->l_key = lkey;
sg1entry->len = frag->size;
- tmp_addr = (u64)(page_address(frag->page)
- + frag->page_offset);
- sg1entry->vaddr = ehea_map_vaddr(tmp_addr);
+ sg1entry->vaddr =
+ ehea_map_vaddr(page_address(frag->page)
+ + frag->page_offset);
swqe->descriptors++;
sg1entry_contains_frag_data = 1;
}
@@ -1431,10 +1427,9 @@ static inline void write_swqe2_data(struct sk_buff *skb, struct net_device *dev,
sgentry->l_key = lkey;
sgentry->len = frag->size;
-
- tmp_addr = (u64)(page_address(frag->page)
- + frag->page_offset);
- sgentry->vaddr = ehea_map_vaddr(tmp_addr);
+ sgentry->vaddr =
+ ehea_map_vaddr(page_address(frag->page)
+ + frag->page_offset);
swqe->descriptors++;
}
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 6/7] Make qdisc changeable.
From: Patrick McHardy @ 2007-08-06 12:06 UTC (permalink / raw)
To: Corey Hickey; +Cc: netdev
In-Reply-To: <46B68BBE.9010307@fatooh.org>
Corey Hickey wrote:
> Patrick McHardy wrote:
>
>>> + if ((err = sfq_q_init(&tmp, opt)))
>>> + return err;
>>
>>
>>
>> This will also use defaults for all unspecified values. It would
>> be more consistent with other qdiscs to only change those values
>> that are actually specified, so something like "tc qdisc change ...
>> perturb 10" will *only* change the perturbation parameter.
>
>
> I'm fixed this for all the parameters except one--your example above.
> Since 0 is a valid value for perturb, I can't see any clever way to
> differentiate between the user specifying "perturb 0" or leaving perturb
> unspecified. Either way, opt->perturb_period is 0.
>
> The only way I can see would be to add another member, say,
> opt->perturb_specified, and use that accordingly. Unfortunately, this
> would break usage of sfq with older versions of tc, so I'm hoping
> there's a better approach.
>
> Do you have any suggestions? I've looked at the other qdisc files and I
> don't see any other instances like this.
Maybe use the nested compat attribute and split the base SFQ
struct in the individual members ..
^ permalink raw reply
* Re: [PATCH net-2.6.22-rc7] xfrm beet interfamily support
From: Patrick McHardy @ 2007-08-06 12:08 UTC (permalink / raw)
To: Joakim Koskela; +Cc: netdev, David Miller
In-Reply-To: <200708060949.58758.joakim.koskela@hiit.fi>
Joakim Koskela wrote:
> On Tuesday 17 July 2007 17:30:21 Joakim Koskela wrote:
>
>>>>@@ -108,7 +108,8 @@ int xfrm4_rcv_encap(struct sk_buff *skb, __u16
>>>>encap_type) if (x->mode->input(x, skb))
>>>> goto drop;
>>>>
>>>>- if (x->props.mode == XFRM_MODE_TUNNEL) {
>>>>+ if (x->props.mode == XFRM_MODE_TUNNEL ||
>>>>+ x->props.mode == XFRM_MODE_BEET) {
>>>> decaps = 1;
>>>> break;
>>>> }
>>>
> It's been a while, but as a fyi in case there are comments / suggestions
> before submitting the whole patch again - it seems that this had some
> problems after all. Works ok for normal cases, but fails when using ip
> options for the inner packet as they don't get processed after being
> extracted from the pseudoheader. Calling something like ip_options_compile
> from beet_mode's input when handling ipv4 would do the trick, but seems a bit
> ugly & perhaps unsafe, I'd rather just put the whole packet through the loop
> again.
Won't the options get parsed by ip_rcv() on the second reception?
^ permalink raw reply
* TCP's initial cwnd setting correct?...
From: Ilpo Järvinen @ 2007-08-06 12:37 UTC (permalink / raw)
To: Netdev; +Cc: David Miller
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3410 bytes --]
I'm I missing something or why it seems to me that whenever rtt stuff is
reset, also tcp_init_cwnd is not called to do RFC3390-like initial
window setting (remains then in 2 which is set by tcp_v4_init_sock)...
Is this done on purpose or what?
...Another thing that makes me wonder, is the tp->mss_cache > 1460 check
as based on rfc3390 (and also it's precursor rfc2414) with up to 2190
bytes MSS TCP can use 3 as initial cwnd...
...Compile tested patch below in case these are valid concerns... ...Goto
logic could be cleaner (somebody has any suggestion for better way to
structure it?)
--
i.
[PATCH] [TCP]: Use IW also when RTT vars get reset & update to match RFC
Previously when RTT got reset, initial window was not being set.
Initial window defined RFC3390 (and it's precursor 2414) allows
using initial window of three as long as MSS < 2190 bytes.
Also update RFC2414 references as it's obsoleted by RFC3390.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 32 +++++++++++++++++---------------
net/ipv4/tcp_output.c | 2 +-
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index eb96864..89794ec 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -805,13 +805,13 @@ void tcp_update_metrics(struct sock *sk)
}
}
-/* Numbers are taken from RFC2414. */
+/* Numbers are taken from RFC3390. */
__u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry *dst)
{
__u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0);
if (!cwnd) {
- if (tp->mss_cache > 1460)
+ if (tp->mss_cache >= 2190)
cwnd = 2;
else
cwnd = (tp->mss_cache > 1095) ? 3 : 4;
@@ -897,22 +897,24 @@ static void tcp_init_metrics(struct sock *sk)
}
tcp_set_rto(sk);
tcp_bound_rto(sk);
- if (inet_csk(sk)->icsk_rto < TCP_TIMEOUT_INIT && !tp->rx_opt.saw_tstamp)
- goto reset;
- tp->snd_cwnd = tcp_init_cwnd(tp, dst);
- tp->snd_cwnd_stamp = tcp_time_stamp;
- return;
+
+ if (inet_csk(sk)->icsk_rto < TCP_TIMEOUT_INIT && !tp->rx_opt.saw_tstamp) {
reset:
- /* Play conservative. If timestamps are not
- * supported, TCP will fail to recalculate correct
- * rtt, if initial rto is too small. FORGET ALL AND RESET!
- */
- if (!tp->rx_opt.saw_tstamp && tp->srtt) {
- tp->srtt = 0;
- tp->mdev = tp->mdev_max = tp->rttvar = TCP_TIMEOUT_INIT;
- inet_csk(sk)->icsk_rto = TCP_TIMEOUT_INIT;
+ /* Play conservative. If timestamps are not
+ * supported, TCP will fail to recalculate correct
+ * rtt, if initial rto is too small. FORGET ALL AND RESET!
+ */
+ if (!tp->rx_opt.saw_tstamp && tp->srtt) {
+ tp->srtt = 0;
+ tp->mdev = tp->mdev_max = tp->rttvar = TCP_TIMEOUT_INIT;
+ inet_csk(sk)->icsk_rto = TCP_TIMEOUT_INIT;
+ }
}
+
+ tp->snd_cwnd = tcp_init_cwnd(tp, dst);
+ tp->snd_cwnd_stamp = tcp_time_stamp;
+ return;
}
static void tcp_update_reordering(struct sock *sk, const int metric,
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 3abe22e..4f9be23 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -209,7 +209,7 @@ void tcp_select_initial_window(int __space, __u32 mss,
}
/* Set initial window to value enough for senders,
- * following RFC2414. Senders, not following this RFC,
+ * following RFC3390. Senders, not following this RFC,
* will be satisfied with 2.
*/
if (mss > (1<<*rcv_wscale)) {
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH net-2.6.22-rc7] xfrm beet interfamily support
From: Joakim Koskela @ 2007-08-06 13:07 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, David Miller
In-Reply-To: <46B70F2C.6090807@trash.net>
On Monday 06 August 2007 15:08:12 Patrick McHardy wrote:
> >
> > It's been a while, but as a fyi in case there are comments / suggestions
> > before submitting the whole patch again - it seems that this had some
> > problems after all. Works ok for normal cases, but fails when using ip
> > options for the inner packet as they don't get processed after being
> > extracted from the pseudoheader. Calling something like
> > ip_options_compile from beet_mode's input when handling ipv4 would do the
> > trick, but seems a bit ugly & perhaps unsafe, I'd rather just put the
> > whole packet through the loop again.
>
> Won't the options get parsed by ip_rcv() on the second reception?
Yes. The thing was that it seemed like we could get by with only a
transport-mode- amount of processing of same-family beet packets. But unless
we do some special processing during beet reception (which doesn't seem that
elegant), it won't work. So I'm changing it back to tunnel-like processing.
br, j
^ permalink raw reply
* Re: [PATCH 2/4][SSB] EXTIF serial port initialization
From: Arnaldo Carvalho de Melo @ 2007-08-06 13:14 UTC (permalink / raw)
To: Michael Buesch; +Cc: Aurelien Jarno, netdev, Felix Fietkau
In-Reply-To: <200708061051.05769.mb@bu3sch.de>
Em Mon, Aug 06, 2007 at 10:51:05AM +0200, Michael Buesch escreveu:
> On Monday 06 August 2007, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Aug 06, 2007 at 01:19:59AM +0200, Aurelien Jarno escreveu:
> > > The patch below against 2.6.23-rc1-mm2 implements EXTIF serial
> > > initialization, currently marked as TODO.
> > >
> > > It originally comes from the OpenWrt patches.
> >
> > Comments below
> >
> > > Cc: Felix Fietkau <nbd@openwrt.org>
> > > Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> > >
> > > --- a/drivers/ssb/driver_mipscore.c
> > > +++ b/drivers/ssb/driver_mipscore.c
> > > @@ -128,51 +128,52 @@
> > > ssb_write32(mdev, SSB_IPSFLAG, irqflag);
> > > }
> > >
> > > -/* XXX: leave here or move into separate extif driver? */
> > > -static int ssb_extif_serial_init(struct ssb_device *dev, struct ssb_serial_ports *ports)
> > > +static inline bool serial_exists(u8 *regs)
> > > {
> > > + u8 save_mcr, msr = 0;
> >
> > Why declare save_mcr here...
> >
> > >
> > > + if (regs) {
> >
> > if it is just used here?
>
> There is almost never an advantage when declaring variables at the beginning
> of a statement block instead of the function start.
> The only thing you "gain" is that you don't easily see anymore how much
> stackspace is used by the funtions.
Well, I disagree, your argument is flawed because if the function is too
big to have so many variables it should be split in smaller functions
anyway, and when it is not that big, like in the above case one can see
the stack usage just fine on the same screen.
> So I really suggest to declare variables at the beginning of functions,
> except for some rare circumstances maybe. Which is not the case here.
I'd recommend the reverse, but anyway, it is just a suggestion.
- Arnaldo
^ permalink raw reply
* Re: [PATCH net-2.6.22-rc7] xfrm beet interfamily support
From: Patrick McHardy @ 2007-08-06 13:21 UTC (permalink / raw)
To: Joakim Koskela; +Cc: netdev, David Miller
In-Reply-To: <200708061607.28259.joakim.koskela@hiit.fi>
Joakim Koskela wrote:
> On Monday 06 August 2007 15:08:12 Patrick McHardy wrote:
>
>>>It's been a while, but as a fyi in case there are comments / suggestions
>>>before submitting the whole patch again - it seems that this had some
>>>problems after all. Works ok for normal cases, but fails when using ip
>>>options for the inner packet as they don't get processed after being
>>>extracted from the pseudoheader. Calling something like
>>>ip_options_compile from beet_mode's input when handling ipv4 would do the
>>>trick, but seems a bit ugly & perhaps unsafe, I'd rather just put the
>>>whole packet through the loop again.
>>
>>Won't the options get parsed by ip_rcv() on the second reception?
>
>
> Yes. The thing was that it seemed like we could get by with only a
> transport-mode- amount of processing of same-family beet packets. But unless
> we do some special processing during beet reception (which doesn't seem that
> elegant), it won't work. So I'm changing it back to tunnel-like processing.
I think you could parse the options directly after decapsulation
in xfrm4_mode_beet.c, that doesn't seem very ugly to me.
^ permalink raw reply
* Re: Possible bug in realtek 8169 ethernet driver
From: Bram @ 2007-08-06 13:37 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel, netdev
In-Reply-To: <20070805213557.GA21500@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
> Please try the patch below on top of 2.6.23-rc2 ?
>
Ok, I did that.
The device now works! But, it still comes up as eth2 instead of eth0,
even though it's first detected as eth0. There are no other network
interfaces according to ifconfig -a.
I've attached the entire dmesg, which ends with messages from me
unloading and reloading the r8169 module again. If you need anything else,
just let me know.
Best regards,
Bram
[-- Attachment #2: dmesg.bz2 --]
[-- Type: application/octet-stream, Size: 10045 bytes --]
^ permalink raw reply
* [PATCH] kexec: fix pci device initialization fail after kexec (2.6.23-rc2). (Related to e1000 doesn't resume properly from standby)
From: Joonwoo Park @ 2007-08-06 13:42 UTC (permalink / raw)
To: Linux Kernel Mailing List, Kexec Mailing List, Simon Arlott
Cc: Pavel Machek, Kok, Auke, linux-pm, netdev
Hi.
I think that the pci_set_power_state() has bug.
The specification says that some delays is required.
Simon, please can I know whether it works to you?
It is seems to the things are related.
Joonwoo Park.
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 37c00f6..9f78064 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -493,8 +493,14 @@ pci_set_power_state(struct pci_dev *dev, pci_power_t state)
* restore at least the BARs so that the device will be
* accessible to its driver.
*/
- if (need_restore)
+ if (need_restore) {
+ /* The specification also says that "Must ensure that all of
+ * its PCI signal drivers remain disabled for the duration of
+ * the D3hot to D0 Uninitialized state transition".
+ */
+ msleep(10);
pci_restore_bars(dev);
+ }
return 0;
}
2007/8/6, Simon Arlott <simon@fire.lp0.eu>:
> On Mon, August 6, 2007 11:44, Pavel Machek wrote:
> > Hi!
> >
> >> >00:0a.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet
> >> >Controller (Copper) (rev 01)
> >> > Subsystem: Intel Corp.: Unknown device 1012
> >> > Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 5
> >> > Memory at e3020000 (64-bit, non-prefetchable) [size=128K]
> >> > I/O ports at b000 [size=64]
> >> > Capabilities: [dc] Power Management version 2
> >> > Capabilities: [e4] PCI-X non-bridge device.
> >> > Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0
> >> > Enable-
> >> >
> >> >00:0a.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet
> >> >Controller (Copper) (rev 01)
> >> > Subsystem: Intel Corp.: Unknown device 1012
> >> > Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 12
> >> > Memory at e3000000 (64-bit, non-prefetchable) [size=128K]
> >> > I/O ports at b400 [size=64]
> >> > Capabilities: [dc] Power Management version 2
> >> > Capabilities: [e4] PCI-X non-bridge device.
> >> > Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0
> >> > Enable-
> >> >
> >> >[ 950.132046] Stopping tasks ... done.
> >> >[ 950.459794] Suspending console(s)
> >> >[ 951.776277] pnp: Device 00:0c disabled.
> >> >[ 951.776673] pnp: Device 00:0a disabled.
> >> >[ 951.776984] pnp: Device 00:09 disabled.
> >> >[ 951.777306] pnp: Device 00:08 disabled.
> >> >[ 951.777786] ACPI: PCI interrupt for device 0000:00:11.5 disabled
> >> >[ 951.995359] ACPI: PCI interrupt for device 0000:00:11.3 disabled
> >> >[ 952.006094] ACPI: PCI interrupt for device 0000:00:11.2 disabled
> >> >[ 952.022243] ACPI handle has no context!
> >> >[ 952.033068] ACPI: PCI interrupt for device 0000:00:0c.2 disabled
> >> >[ 952.044086] ACPI: PCI interrupt for device 0000:00:0c.1 disabled
> >> >[ 952.055083] ACPI: PCI interrupt for device 0000:00:0c.0 disabled
> >> >[ 952.282211] ACPI: PCI interrupt for device 0000:00:0a.1 disabled
> >> >[ 952.282221] ACPI handle has no context!
> >> >[ 952.537474] ACPI: PCI interrupt for device 0000:00:0a.0 disabled
> >> >[ 952.537495] ACPI handle has no context!
> >> >
> >> >[ 956.857085] Back to C!
> >
> > Are you sure that is standby? Looks like suspend-to-RAM to me.
>
> It's S1 (power-on suspend/standby), my BIOS/motherboard doesn't support S2 or S3.
>
> --
> Simon Arlott
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply related
* [PATCH 0/3] SSB support for BCM947xx CPUs
From: Aurelien Jarno @ 2007-08-06 15:04 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev, Felix Fietkau
In-Reply-To: <200708061042.14722.mb@bu3sch.de>
On Mon, Aug 06, 2007 at 10:42:14AM +0200, Michael Buesch wrote:
> On Monday 06 August 2007, Aurelien Jarno wrote:
> > The patch below against 2.6.23-rc1-mm2 implements EXTIF timing
> > initialization, currently marked as TODO.
> >
> > It originally comes from the OpenWrt patches.
> >
> > Cc: Felix Fietkau <nbd@openwrt.org>
> > Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> >
> > --- a/drivers/ssb/driver_mipscore.c
> > +++ b/drivers/ssb/driver_mipscore.c
>
> Please do a seperate file driver_extif.c to implement these functions
> and call it from the mipscore driver.
> Compilation can also depend on the mipscore kconfig option, so no
> additional kconfig is needed.
I have separated EXTIF functions into driver_extif.c and taken into
account your other comments. The new patchset is organized a bit
differently.
The following patches add a few features into the SSB EXTIF driver and
fix and improve the SSB Broadcom MIPS core driver, in order to correctly
support the BCM947xx CPUs.
They originally comes from the OpenWrt patches.
Patch #1: SSB EXTIF timing & serial port initialization
Patch #2: Use SSB EXTIF in SSB MIPS core driver
Patch #3: Add buswidth to SSB MIPS core flash driver
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply
* [PATCH 1/3] SSB EXTIF timing & serial port initialization
From: Aurelien Jarno @ 2007-08-06 15:04 UTC (permalink / raw)
To: Michael Buesch, netdev; +Cc: Felix Fietkau
The patch below adds a new file drivers/ssb/driver_extif.c which
contains new SSB EXTIF functions to initializes the timing and the
serial ports.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
--- a/drivers/ssb/driver_extif.c
+++ b/drivers/ssb/driver_extif.c
@@ -0,0 +1,104 @@
+/*
+ * Sonics Silicon Backplane
+ * Broadcom EXTIF core driver
+ *
+ * Copyright 2005, Broadcom Corporation
+ * Copyright 2006, 2007, Michael Buesch <mb@bu3sch.de>
+ * Copyright 2006, 2007, Felix Fietkau <nbd@openwrt.org>
+ * Copyright 2007, Aurelien Jarno <aurelien@aurel32.net>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/serial_reg.h>
+
+#include "ssb_private.h"
+
+
+static inline u32 extif_read32(struct ssb_extif *extif, u16 offset)
+{
+ return ssb_read32(extif->dev, offset);
+}
+
+static inline void extif_write32(struct ssb_extif *extif, u16 offset, u32 value)
+{
+ ssb_write32(extif->dev, offset, value);
+}
+
+#ifdef CONFIG_SSB_SERIAL
+static bool serial_exists(u8 *regs)
+{
+ u8 save_mcr, msr = 0;
+
+ if (regs) {
+ save_mcr = regs[UART_MCR];
+ regs[UART_MCR] = (UART_MCR_LOOP | UART_MCR_OUT2 | UART_MCR_RTS);
+ msr = regs[UART_MSR] & (UART_MSR_DCD | UART_MSR_RI \
+ | UART_MSR_CTS | UART_MSR_DSR);
+ regs[UART_MCR] = save_mcr;
+ }
+ return (msr == (UART_MSR_DCD | UART_MSR_CTS));
+}
+
+int ssb_extif_serial_init(struct ssb_extif *extif, struct ssb_serial_port *ports)
+{
+ u32 i, nr_ports = 0;
+
+ /* Disable GPIO interrupt initially */
+ extif_write32(extif, SSB_EXTIF_GPIO_INTPOL, 0);
+ extif_write32(extif, SSB_EXTIF_GPIO_INTMASK, 0);
+
+ for (i = 0; i < 2; i++) {
+ void __iomem *uart_regs;
+
+ uart_regs = ioremap_nocache(SSB_EUART, 16);
+ if (uart_regs) {
+ uart_regs += (i * 8);
+
+ if (serial_exists(uart_regs) && ports) {
+ extif_write32(extif, SSB_EXTIF_GPIO_INTMASK, 2);
+
+ nr_ports++;
+ ports[i].regs = uart_regs;
+ ports[i].irq = 2;
+ ports[i].baud_base = 13500000;
+ ports[i].reg_shift = 0;
+ }
+ iounmap(uart_regs);
+ }
+ }
+ return nr_ports;
+}
+#endif /* CONFIG_SSB_SERIAL */
+
+void ssb_extif_timing_init(struct ssb_extif *extif, unsigned long ns)
+{
+ u32 tmp;
+
+ /* Initialize extif so we can get to the LEDs and external UART */
+ extif_write32(extif, SSB_EXTIF_PROG_CFG, SSB_EXTCFG_EN);
+
+ /* Set timing for the flash */
+ tmp = DIV_ROUND_UP(10, ns) << SSB_PROG_WCNT_3_SHIFT;
+ tmp |= DIV_ROUND_UP(40, ns) << SSB_PROG_WCNT_1_SHIFT;
+ tmp |= DIV_ROUND_UP(120, ns);
+ extif_write32(extif, SSB_EXTIF_PROG_WAITCNT, tmp);
+
+ /* Set programmable interface timing for external uart */
+ tmp = DIV_ROUND_UP(10, ns) << SSB_PROG_WCNT_3_SHIFT;
+ tmp |= DIV_ROUND_UP(20, ns) << SSB_PROG_WCNT_2_SHIFT;
+ tmp |= DIV_ROUND_UP(100, ns) << SSB_PROG_WCNT_1_SHIFT;
+ tmp |= DIV_ROUND_UP(120, ns);
+ extif_write32(extif, SSB_EXTIF_PROG_WAITCNT, tmp);
+}
+
+void ssb_extif_get_clockcontrol(struct ssb_extif *extif,
+ u32 *pll_type, u32 *n, u32 *m)
+{
+ *pll_type = SSB_PLLTYPE_1;
+ *n = extif_read32(extif, SSB_EXTIF_CLOCK_N);
+ *m = extif_read32(extif, SSB_EXTIF_CLOCK_SB);
+}
+
--- a/drivers/ssb/Makefile
+++ b/drivers/ssb/Makefile
@@ -7,7 +7,7 @@
# built-in drivers
ssb-y += driver_chipcommon.o
-ssb-$(CONFIG_SSB_DRIVER_MIPS) += driver_mipscore.o
+ssb-$(CONFIG_SSB_DRIVER_MIPS) += driver_mipscore.o driver_extif.o
ssb-$(CONFIG_SSB_DRIVER_PCICORE) += driver_pcicore.o
obj-$(CONFIG_SSB) += ssb.o
--- a/include/linux/ssb/ssb_driver_extif.h
+++ b/include/linux/ssb/ssb_driver_extif.h
@@ -156,5 +156,15 @@
/* watchdog */
#define SSB_EXTIF_WATCHDOG_CLK 48000000 /* Hz */
+extern void ssb_extif_get_clockcontrol(struct ssb_extif *extif,
+ u32 *plltype, u32 *n, u32 *m);
+
+extern void ssb_extif_timing_init(struct ssb_extif *extif,
+ unsigned long ns);
+
+#ifdef CONFIG_SSB_SERIAL
+extern int ssb_extif_serial_init(struct ssb_extif *extif,
+ struct ssb_serial_port *ports);
+#endif /* CONFIG_SSB_SERIAL */
#endif /* LINUX_SSB_EXTIFCORE_H_ */
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply
* [PATCH 2/3] Use SSB EXTIF in SSB MIPS core driver
From: Aurelien Jarno @ 2007-08-06 15:05 UTC (permalink / raw)
To: Michael Buesch, netdev; +Cc: Felix Fietkau
The patch below against 2.6.23-rc1-mm2 uses the functions added in the
previous patch to do serial and timing initializations for EXTIF,
currently marked as TODO. It also implements the ssb_cpu_clock() and
export it. This function is needed to support the BCM947xx CPUs.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
--- a/drivers/ssb/driver_mipscore.c
+++ b/drivers/ssb/driver_mipscore.c
@@ -117,51 +117,10 @@
ssb_write32(mdev, SSB_IPSFLAG, irqflag);
}
-/* XXX: leave here or move into separate extif driver? */
-static int ssb_extif_serial_init(struct ssb_device *dev, struct ssb_serial_ports *ports)
-{
-
-}
-
-
static void ssb_mips_serial_init(struct ssb_mipscore *mcore)
{
struct ssb_bus *bus = mcore->dev->bus;
- //TODO if (EXTIF available
-#if 0
- extifregs_t *eir = (extifregs_t *) regs;
- sbconfig_t *sb;
-
- /* Determine external UART register base */
- sb = (sbconfig_t *)((ulong) eir + SBCONFIGOFF);
- base = EXTIF_CFGIF_BASE(sb_base(R_REG(&sb->sbadmatch1)));
-
- /* Determine IRQ */
- irq = sb_irq(sbh);
-
- /* Disable GPIO interrupt initially */
- W_REG(&eir->gpiointpolarity, 0);
- W_REG(&eir->gpiointmask, 0);
-
- /* Search for external UARTs */
- n = 2;
- for (i = 0; i < 2; i++) {
- regs = (void *) REG_MAP(base + (i * 8), 8);
- if (BCMINIT(serial_exists)(regs)) {
- /* Set GPIO 1 to be the external UART IRQ */
- W_REG(&eir->gpiointmask, 2);
- if (add)
- add(regs, irq, 13500000, 0);
- }
- }
-
- /* Add internal UART if enabled */
- if (R_REG(&eir->corecontrol) & CC_UE)
- if (add)
- add((void *) &eir->uartdata, irq, sb_clock(sbh), 2);
-
-#endif
if (bus->extif.dev)
mcore->nr_serial_ports = ssb_extif_serial_init(&bus->extif, mcore->serial_ports);
else if (bus->chipco.dev)
@@ -183,9 +142,29 @@
}
}
-
-static void ssb_cpu_clock(struct ssb_mipscore *mcore)
+u32 ssb_cpu_clock(struct ssb_mipscore *mcore)
{
+ struct ssb_bus *bus = mcore->dev->bus;
+ u32 pll_type, n, m, rate = 0;
+
+ if (bus->extif.dev) {
+ ssb_extif_get_clockcontrol(&bus->extif, &pll_type, &n, &m);
+ } else if (bus->chipco.dev) {
+ ssb_chipco_get_clockcpu(&bus->chipco, &pll_type, &n, &m);
+ } else
+ return 0;
+
+ if ((pll_type == SSB_PLLTYPE_5) || (bus->chip_id == 0x5365)) {
+ rate = 200000000;
+ } else {
+ rate = ssb_calc_clock_rate(pll_type, n, m);
+ }
+
+ if (pll_type == SSB_PLLTYPE_6) {
+ rate *= 2;
+ }
+
+ return rate;
}
void ssb_mipscore_init(struct ssb_mipscore *mcore)
@@ -205,27 +184,9 @@
hz = 100000000;
ns = 1000000000 / hz;
-//TODO
-#if 0
- if (have EXTIF) {
- /* Initialize extif so we can get to the LEDs and external UART */
- W_REG(&eir->prog_config, CF_EN);
-
- /* Set timing for the flash */
- tmp = CEIL(10, ns) << FW_W3_SHIFT; /* W3 = 10nS */
- tmp = tmp | (CEIL(40, ns) << FW_W1_SHIFT); /* W1 = 40nS */
- tmp = tmp | CEIL(120, ns); /* W0 = 120nS */
- W_REG(&eir->prog_waitcount, tmp); /* 0x01020a0c for a 100Mhz clock */
-
- /* Set programmable interface timing for external uart */
- tmp = CEIL(10, ns) << FW_W3_SHIFT; /* W3 = 10nS */
- tmp = tmp | (CEIL(20, ns) << FW_W2_SHIFT); /* W2 = 20nS */
- tmp = tmp | (CEIL(100, ns) << FW_W1_SHIFT); /* W1 = 100nS */
- tmp = tmp | CEIL(120, ns); /* W0 = 120nS */
- W_REG(&eir->prog_waitcount, tmp);
- }
-#endif
- if (bus->chipco.dev)
+ if (bus->extif.dev)
+ ssb_extif_timing_init(&bus->extif, ns);
+ else if (bus->chipco.dev)
ssb_chipco_timing_init(&bus->chipco, ns);
/* Assign IRQs to all cores on the bus, start with irq line 2, because serial usually takes 1 */
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -819,12 +819,13 @@
u32 plltype;
u32 clkctl_n, clkctl_m;
- //TODO if EXTIF: PLLTYPE == 1, read n from clockcontrol_n, m from clockcontrol_sb
-
- if (bus->chipco.dev) {
+ if (bus->extif.dev)
+ ssb_extif_get_clockcontrol(&bus->extif, &plltype,
+ &clkctl_n, &clkctl_m);
+ else if (bus->chipco.dev)
ssb_chipco_get_clockcontrol(&bus->chipco, &plltype,
&clkctl_n, &clkctl_m);
- } else
+ else
return 0;
if (bus->chip_id == 0x5365) {
--- a/include/linux/ssb/ssb_driver_mips.h
+++ b/include/linux/ssb/ssb_driver_mips.h
@@ -25,6 +25,7 @@
};
extern void ssb_mipscore_init(struct ssb_mipscore *mcore);
+extern u32 ssb_cpu_clock(struct ssb_mipscore *mcore);
extern unsigned int ssb_mips_irq(struct ssb_device *dev);
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply
* [PATCH 3/3] Add buswidth to SSB MIPS core flash driver
From: Aurelien Jarno @ 2007-08-06 15:05 UTC (permalink / raw)
To: Michael Buesch, netdev; +Cc: Felix Fietkau
The patch below against 2.6.23-rc1-mm2 fixes the size of the flash
window and detect the width of the flash bus (8 or 16 bits).
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
--- a/drivers/ssb/driver_mipscore.c
+++ b/drivers/ssb/driver_mipscore.c
@@ -133,12 +133,16 @@
{
struct ssb_bus *bus = mcore->dev->bus;
+ mcore->flash_buswidth = 2;
if (bus->chipco.dev) {
mcore->flash_window = 0x1c000000;
- mcore->flash_window_size = 0x800000;
+ mcore->flash_window_size = 0x02000000;
+ if ((ssb_read32(bus->chipco.dev, SSB_CHIPCO_FLASH_CFG)
+ & SSB_CHIPCO_CFG_DS16) == 0)
+ mcore->flash_buswidth = 1;
} else {
mcore->flash_window = 0x1fc00000;
- mcore->flash_window_size = 0x400000;
+ mcore->flash_window_size = 0x00400000;
}
}
--- a/include/linux/ssb/ssb_driver_mips.h
+++ b/include/linux/ssb/ssb_driver_mips.h
@@ -20,6 +20,7 @@
int nr_serial_ports;
struct ssb_serial_port serial_ports[4];
+ u8 flash_buswidth;
u32 flash_window;
u32 flash_window_size;
};
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply
* Support for Intel 82562V-2?
From: Erik Mouw @ 2007-08-06 16:38 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
Hi,
Just got a brand new Dell Vostro and it appears to have an unsupported
Intel network card:
00:19.0 Ethernet controller: Intel Corporation 82562V-2 10/100 Network Connection (rev 02)
Subsystem: Dell Unknown device 0238
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fdfc0000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at fdfff000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at fe00 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [e0] Vendor Specific Information
00: 86 80 c0 10 07 00 10 00 02 00 00 02 00 00 00 00
10: 00 00 fc fd 00 f0 ff fd 01 fe 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 38 02
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0a 01 00 00
The e100 driver doesn't recognise it and the "old" eepro100 also
doesn't. Would it be enought to add the PCI ID to one of these drivers
to get the card supported?
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Chuck Ebbert @ 2007-08-06 17:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Marcin Ślusarz, Jarek Poplawski, Thomas Gleixner,
Linus Torvalds, Jean-Baptiste Vignaud, linux-kernel, shemminger,
linux-net, netdev, Andrew Morton, Alan Cox
In-Reply-To: <20070806070300.GA4509@elte.hu>
On 08/06/2007 03:03 AM, Ingo Molnar wrote:
>
> But, since level types don't need this retriggers too much I think
> this "don't mask interrupts by default" idea should be rethinked:
> is there enough gain to risk such hard to diagnose errors?
>
>
I reverted those masking changes in Fedora and the baffling problem
with 3Com 3C905 network adapters went away.
Before, they would print:
eth0: transmit timed out, tx_status 00 status e601.
diagnostics: net 0ccc media 8880 dma 0000003a fifo 0000
eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
Flags; bus-master 1, dirty 295757(13) current 295757(13)
Transmit list 00000000 vs. f7150a20.
0: @f7150200 length 80000070 status 0c010070
1: @f71502a0 length 80000070 status 0c010070
2: @f7150340 length 8000005c status 0c01005c
Now they just work, apparently...
So why not just revert the change?
^ permalink raw reply
* RE: Support for Intel 82562V-2?
From: Allan, Bruce W @ 2007-08-06 17:54 UTC (permalink / raw)
To: Erik Mouw, netdev
In-Reply-To: <20070806163819.GA18130@gateway.home>
While that is a "10/100 network connection", it is actually a GigE MAC
with a 10/100 PHY and will be supported by the e1000e driver that is
currently in the process of final cleanup before getting into the
upstream kernel.
If you must use it now, you can grab the latest out-of-tree version of
the e1000 driver from http://e1000.sf.net which has support for that
device. There are no plans for adding support for this device to the
in-tree e1000 driver.
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Erik Mouw
Sent: Monday, August 06, 2007 9:38 AM
To: netdev@vger.kernel.org
Subject: Support for Intel 82562V-2?
Hi,
Just got a brand new Dell Vostro and it appears to have an unsupported
Intel network card:
00:19.0 Ethernet controller: Intel Corporation 82562V-2 10/100 Network
Connection (rev 02)
Subsystem: Dell Unknown device 0238
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fdfc0000 (32-bit, non-prefetchable)
[size=128K]
Region 1: Memory at fdfff000 (32-bit, non-prefetchable)
[size=4K]
Region 2: I/O ports at fe00 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [e0] Vendor Specific Information
00: 86 80 c0 10 07 00 10 00 02 00 00 02 00 00 00 00
10: 00 00 fc fd 00 f0 ff fd 01 fe 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 38 02
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0a 01 00 00
The e100 driver doesn't recognise it and the "old" eepro100 also
doesn't. Would it be enought to add the PCI ID to one of these drivers
to get the card supported?
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V5
From: Michael Chan @ 2007-08-06 18:00 UTC (permalink / raw)
To: David Miller, netdev; +Cc: shemminger, jgarzik, hadi, rusty
In-Reply-To: <20070805.232423.21363072.davem@davemloft.net>
David Miller wrote:
> 4) NETPOLL put hopefully into a working state.
It's no longer necessary to change the tx locking scheme
in bnx2.c and tg3.c, right? May be you forgot to revert
the tx locking changes you did in V4?
^ permalink raw reply
* Re: [PATCH 1/3] SSB EXTIF timing & serial port initialization
From: Michael Buesch @ 2007-08-06 18:23 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: netdev, Felix Fietkau
In-Reply-To: <20070806150447.GB24308@hall.aurel32.net>
On Monday 06 August 2007, Aurelien Jarno wrote:
> The patch below adds a new file drivers/ssb/driver_extif.c which
> contains new SSB EXTIF functions to initializes the timing and the
> serial ports.
>
> Cc: Felix Fietkau <nbd@openwrt.org>
> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> +#ifdef CONFIG_SSB_SERIAL
> +static bool serial_exists(u8 *regs)
> +{
> + u8 save_mcr, msr = 0;
> +
> + if (regs) {
> + save_mcr = regs[UART_MCR];
> + regs[UART_MCR] = (UART_MCR_LOOP | UART_MCR_OUT2 | UART_MCR_RTS);
> + msr = regs[UART_MSR] & (UART_MSR_DCD | UART_MSR_RI \
^^^^^
Backslash?
> + | UART_MSR_CTS | UART_MSR_DSR);
> + regs[UART_MCR] = save_mcr;
> + }
> + return (msr == (UART_MSR_DCD | UART_MSR_CTS));
> +}
^ permalink raw reply
* Re: [PATCH 1/3] SSB EXTIF timing & serial port initialization
From: Aurelien Jarno @ 2007-08-06 18:29 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev, Felix Fietkau
In-Reply-To: <200708062023.08046.mb@bu3sch.de>
On Mon, Aug 06, 2007 at 08:23:07PM +0200, Michael Buesch wrote:
> On Monday 06 August 2007, Aurelien Jarno wrote:
> > The patch below adds a new file drivers/ssb/driver_extif.c which
> > contains new SSB EXTIF functions to initializes the timing and the
> > serial ports.
> >
> > Cc: Felix Fietkau <nbd@openwrt.org>
> > Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
>
> > +#ifdef CONFIG_SSB_SERIAL
> > +static bool serial_exists(u8 *regs)
> > +{
> > + u8 save_mcr, msr = 0;
> > +
> > + if (regs) {
> > + save_mcr = regs[UART_MCR];
> > + regs[UART_MCR] = (UART_MCR_LOOP | UART_MCR_OUT2 | UART_MCR_RTS);
> > + msr = regs[UART_MSR] & (UART_MSR_DCD | UART_MSR_RI \
> ^^^^^
> Backslash?
>
Oops I did too much shell scripts recently ;-) I will send a new patch.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply
* Re: TCP's initial cwnd setting correct?...
From: Ilpo Järvinen @ 2007-08-06 18:31 UTC (permalink / raw)
To: Netdev; +Cc: David Miller
In-Reply-To: <Pine.LNX.4.64.0708061508070.8788@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 263 bytes --]
On Mon, 6 Aug 2007, Ilpo Järvinen wrote:
> ...Goto logic could be cleaner (somebody has any suggestion for better
> way to structure it?)
...I could probably move the setting of snd_cwnd earlier to avoid
this problem if this seems a valid fix at all.
--
i.
^ permalink raw reply
* RE: [2/2] 2.6.23-rc2: known regressions with patches
From: Luck, Tony @ 2007-08-06 18:45 UTC (permalink / raw)
To: trenn, Michal Piotrowski
Cc: Linus Torvalds, Andrew Morton, LKML, Christoph Lameter,
Pekka Enberg, Peter Zijlstra, Ingo Molnar, Jan Dittmer, Netdev,
Joachim Deguara, Michael Chan, linux-scsi, James Bottomley,
Matthew Wilcox, Seokmann Ju, Richard Lary
In-Reply-To: <1186331976.3858.39.camel@fanta4.site>
> > Caused-By : Thomas Renninger <trenn@suse.de>
> > commit 29b71a1ca74491fab9fed09e9d835d840d042690
> A patch was sent to Tony. AFAIK it got accepted, not sure whether it
> already is in any and which git tree...
The suggested patch adds manual padding to the acpi_device_id structure
definition in include/linux/mod_devicetable.h I didn't take it, and it
appears that nobody else did either. It is not in Linus' tree (as of 2.6.23-rc2).
I expressed doubts about whether this is the right fix. The problem
is that when cross-compiling a locally compiled utility makes a size &
alignment check. This is bogus. We shouldn't care whether this structure
compiles to the same size/alignment as the kernel that will use on the
target platform.
Is fixing this the right way (make the scripts/mod/file2alias.c understand
target alignment rules in a cross environment) just too hideous to
contemplate ... and we should just sacrifice 7 bytes of padding in
order to keep life simple?
-Tony
^ permalink raw reply
* [PATCH 1/3] SSB EXTIF timing & serial port initialization (v2)
From: Aurelien Jarno @ 2007-08-06 18:55 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev, Felix Fietkau
In-Reply-To: <200708062023.08046.mb@bu3sch.de>
The patch below adds a new file drivers/ssb/driver_extif.c which
contains new SSB EXTIF functions to initializes the timing and the
serial ports.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
--- a/drivers/ssb/driver_extif.c
+++ b/drivers/ssb/driver_extif.c
@@ -0,0 +1,104 @@
+/*
+ * Sonics Silicon Backplane
+ * Broadcom EXTIF core driver
+ *
+ * Copyright 2005, Broadcom Corporation
+ * Copyright 2006, 2007, Michael Buesch <mb@bu3sch.de>
+ * Copyright 2006, 2007, Felix Fietkau <nbd@openwrt.org>
+ * Copyright 2007, Aurelien Jarno <aurelien@aurel32.net>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/serial_reg.h>
+
+#include "ssb_private.h"
+
+
+static inline u32 extif_read32(struct ssb_extif *extif, u16 offset)
+{
+ return ssb_read32(extif->dev, offset);
+}
+
+static inline void extif_write32(struct ssb_extif *extif, u16 offset, u32 value)
+{
+ ssb_write32(extif->dev, offset, value);
+}
+
+#ifdef CONFIG_SSB_SERIAL
+static bool serial_exists(u8 *regs)
+{
+ u8 save_mcr, msr = 0;
+
+ if (regs) {
+ save_mcr = regs[UART_MCR];
+ regs[UART_MCR] = (UART_MCR_LOOP | UART_MCR_OUT2 | UART_MCR_RTS);
+ msr = regs[UART_MSR] & (UART_MSR_DCD | UART_MSR_RI
+ | UART_MSR_CTS | UART_MSR_DSR);
+ regs[UART_MCR] = save_mcr;
+ }
+ return (msr == (UART_MSR_DCD | UART_MSR_CTS));
+}
+
+int ssb_extif_serial_init(struct ssb_extif *extif, struct ssb_serial_port *ports)
+{
+ u32 i, nr_ports = 0;
+
+ /* Disable GPIO interrupt initially */
+ extif_write32(extif, SSB_EXTIF_GPIO_INTPOL, 0);
+ extif_write32(extif, SSB_EXTIF_GPIO_INTMASK, 0);
+
+ for (i = 0; i < 2; i++) {
+ void __iomem *uart_regs;
+
+ uart_regs = ioremap_nocache(SSB_EUART, 16);
+ if (uart_regs) {
+ uart_regs += (i * 8);
+
+ if (serial_exists(uart_regs) && ports) {
+ extif_write32(extif, SSB_EXTIF_GPIO_INTMASK, 2);
+
+ nr_ports++;
+ ports[i].regs = uart_regs;
+ ports[i].irq = 2;
+ ports[i].baud_base = 13500000;
+ ports[i].reg_shift = 0;
+ }
+ iounmap(uart_regs);
+ }
+ }
+ return nr_ports;
+}
+#endif /* CONFIG_SSB_SERIAL */
+
+void ssb_extif_timing_init(struct ssb_extif *extif, unsigned long ns)
+{
+ u32 tmp;
+
+ /* Initialize extif so we can get to the LEDs and external UART */
+ extif_write32(extif, SSB_EXTIF_PROG_CFG, SSB_EXTCFG_EN);
+
+ /* Set timing for the flash */
+ tmp = DIV_ROUND_UP(10, ns) << SSB_PROG_WCNT_3_SHIFT;
+ tmp |= DIV_ROUND_UP(40, ns) << SSB_PROG_WCNT_1_SHIFT;
+ tmp |= DIV_ROUND_UP(120, ns);
+ extif_write32(extif, SSB_EXTIF_PROG_WAITCNT, tmp);
+
+ /* Set programmable interface timing for external uart */
+ tmp = DIV_ROUND_UP(10, ns) << SSB_PROG_WCNT_3_SHIFT;
+ tmp |= DIV_ROUND_UP(20, ns) << SSB_PROG_WCNT_2_SHIFT;
+ tmp |= DIV_ROUND_UP(100, ns) << SSB_PROG_WCNT_1_SHIFT;
+ tmp |= DIV_ROUND_UP(120, ns);
+ extif_write32(extif, SSB_EXTIF_PROG_WAITCNT, tmp);
+}
+
+void ssb_extif_get_clockcontrol(struct ssb_extif *extif,
+ u32 *pll_type, u32 *n, u32 *m)
+{
+ *pll_type = SSB_PLLTYPE_1;
+ *n = extif_read32(extif, SSB_EXTIF_CLOCK_N);
+ *m = extif_read32(extif, SSB_EXTIF_CLOCK_SB);
+}
+
--- a/drivers/ssb/Makefile
+++ b/drivers/ssb/Makefile
@@ -7,7 +7,7 @@
# built-in drivers
ssb-y += driver_chipcommon.o
-ssb-$(CONFIG_SSB_DRIVER_MIPS) += driver_mipscore.o
+ssb-$(CONFIG_SSB_DRIVER_MIPS) += driver_mipscore.o driver_extif.o
ssb-$(CONFIG_SSB_DRIVER_PCICORE) += driver_pcicore.o
obj-$(CONFIG_SSB) += ssb.o
--- a/include/linux/ssb/ssb_driver_extif.h
+++ b/include/linux/ssb/ssb_driver_extif.h
@@ -156,5 +156,15 @@
/* watchdog */
#define SSB_EXTIF_WATCHDOG_CLK 48000000 /* Hz */
+extern void ssb_extif_get_clockcontrol(struct ssb_extif *extif,
+ u32 *plltype, u32 *n, u32 *m);
+
+extern void ssb_extif_timing_init(struct ssb_extif *extif,
+ unsigned long ns);
+
+#ifdef CONFIG_SSB_SERIAL
+extern int ssb_extif_serial_init(struct ssb_extif *extif,
+ struct ssb_serial_port *ports);
+#endif /* CONFIG_SSB_SERIAL */
#endif /* LINUX_SSB_EXTIFCORE_H_ */
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Ingo Molnar @ 2007-08-06 19:08 UTC (permalink / raw)
To: Chuck Ebbert
Cc: Marcin Ślusarz, Jarek Poplawski, Thomas Gleixner,
Linus Torvalds, Jean-Baptiste Vignaud, linux-kernel, shemminger,
linux-net, netdev, Andrew Morton, Alan Cox
In-Reply-To: <46B75DD4.5080709@redhat.com>
* Chuck Ebbert <cebbert@redhat.com> wrote:
> Before, they would print:
>
> eth0: transmit timed out, tx_status 00 status e601.
> diagnostics: net 0ccc media 8880 dma 0000003a fifo 0000
> eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
> Flags; bus-master 1, dirty 295757(13) current 295757(13)
> Transmit list 00000000 vs. f7150a20.
> 0: @f7150200 length 80000070 status 0c010070
> 1: @f71502a0 length 80000070 status 0c010070
> 2: @f7150340 length 8000005c status 0c01005c
>
> Now they just work, apparently...
could you please try the patch below? If this doesnt do the trick then i
guess we need to revert that change.
Ingo
------------>
(take 2)
Subject: genirq: fix simple and fasteoi irq handlers
After the "genirq: do not mask interrupts by default" patch interrupts
should be disabled not immediately upon request, but after they happen.
But, handle_simple_irq() and handle_fasteoi_irq() can skip this once or
more if an irq is just serviced (IRQ_INPROGRESS), possibly disrupting a
driver's work.
The main reason of problems here, pointing the broken patch and making
the first patch which can fix this was done by Marcin Slusarz.
Additional test patches of Thomas Gleixner and Ingo Molnar tested by
Marcin Slusarz helped to narrow possible reasons even more. Thanks.
PS: this patch fixes only one evident error here, but there could be
more places affected by above-mentioned change in irq handling.
PS 2:
After rethinking, IMHO, there are two most probable scenarios here:
1. After hw resend there could be a conflict between retriggered
edge type irq and the next level type one: e.g. if this level type
irq (io_apic is enabled then) is triggered while retriggered irq is
serviced (IRQ_INPROGRESS) there is goto out with eoi, and probably
the next such levels are triggered and looping, so probably kind of
flood in io_apic until this retriggered edge service has ended.
2. There is something wrong with ioapic_retrigger_irq (less probable
because this should be probably seen with 'normal' edge retriggers,
but on the other hand, they could be less common).
So, if there is #1, this fixed patch should work.
But, since level types don't need this retriggers too much I think
this "don't mask interrupts by default" idea should be rethinked:
is there enough gain to risk such hard to diagnose errors?
So, IMHO, there should be at least possibility to turn this off for
level types in config (it should be a visible option, so people could
find & try this before writing for help or changing a network card).
Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
---
diff -Nurp 2.6.23-rc1-/kernel/irq/chip.c 2.6.23-rc1/kernel/irq/chip.c
--- 2.6.23-rc1-/kernel/irq/chip.c 2007-07-09 01:32:17.000000000 +0200
+++ 2.6.23-rc1/kernel/irq/chip.c 2007-08-05 21:49:46.000000000 +0200
@@ -295,12 +295,11 @@ handle_simple_irq(unsigned int irq, stru
spin_lock(&desc->lock);
- if (unlikely(desc->status & IRQ_INPROGRESS))
- goto out_unlock;
kstat_cpu(cpu).irqs[irq]++;
action = desc->action;
- if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+ if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |
+ IRQ_DISABLED)))) {
if (desc->chip->mask)
desc->chip->mask(irq);
desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
@@ -318,6 +317,8 @@ handle_simple_irq(unsigned int irq, stru
spin_lock(&desc->lock);
desc->status &= ~IRQ_INPROGRESS;
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
out_unlock:
spin_unlock(&desc->lock);
}
@@ -392,18 +393,16 @@ handle_fasteoi_irq(unsigned int irq, str
spin_lock(&desc->lock);
- if (unlikely(desc->status & IRQ_INPROGRESS))
- goto out;
-
desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
kstat_cpu(cpu).irqs[irq]++;
/*
- * If its disabled or no action available
+ * If it's running, disabled or no action available
* then mask it and get out of here:
*/
action = desc->action;
- if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+ if (unlikely(!action || (desc->status & (IRQ_INPROGRESS |
+ IRQ_DISABLED)))) {
desc->status |= IRQ_PENDING;
if (desc->chip->mask)
desc->chip->mask(irq);
@@ -420,6 +419,8 @@ handle_fasteoi_irq(unsigned int irq, str
spin_lock(&desc->lock);
desc->status &= ~IRQ_INPROGRESS;
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
out:
desc->chip->eoi(irq);
^ permalink raw reply
* [PATCH 1/6] ibmveth: Enable TCP checksum offload
From: Brian King @ 2007-08-06 19:42 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yielded a ~30% increase
in throughput. This feature is enabled by default on systems that
support it, but can be disabled with a module option.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 53 ++++++++++++++++++++++++++++++++
linux-2.6-bjking1/drivers/net/ibmveth.h | 41 +++++++++++++++++++++++-
2 files changed, 92 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload 2007-08-01 14:55:11.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-08-01 14:55:11.000000000 -0500
@@ -47,6 +47,8 @@
#include <linux/mm.h>
#include <linux/ethtool.h>
#include <linux/proc_fs.h>
+#include <linux/in.h>
+#include <linux/ip.h>
#include <asm/semaphore.h>
#include <asm/hvcall.h>
#include <asm/atomic.h>
@@ -131,6 +133,11 @@ static inline int ibmveth_rxq_frame_leng
return (adapter->rx_queue.queue_addr[adapter->rx_queue.index].length);
}
+static inline int ibmveth_rxq_csum_good(struct ibmveth_adapter *adapter)
+{
+ return (adapter->rx_queue.queue_addr[adapter->rx_queue.index].csum_good);
+}
+
/* setup the initial settings for a buffer pool */
static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32 pool_index, u32 pool_size, u32 buff_size, u32 pool_active)
{
@@ -684,6 +691,24 @@ static int ibmveth_start_xmit(struct sk_
desc[0].fields.length, DMA_TO_DEVICE);
desc[0].fields.valid = 1;
+ if (skb->ip_summed == CHECKSUM_PARTIAL &&
+ ip_hdr(skb)->protocol != IPPROTO_TCP && skb_checksum_help(skb)) {
+ ibmveth_error_printk("tx: failed to checksum packet\n");
+ tx_dropped++;
+ goto out;
+ }
+
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ unsigned char *buf = skb_transport_header(skb) + skb->csum_offset;
+
+ desc[0].fields.no_csum = 1;
+ desc[0].fields.csum_good = 1;
+
+ /* Need to zero out the checksum */
+ buf[0] = 0;
+ buf[1] = 0;
+ }
+
if(dma_mapping_error(desc[0].fields.address)) {
ibmveth_error_printk("tx: unable to map initial fragment\n");
tx_map_failed++;
@@ -702,6 +727,10 @@ static int ibmveth_start_xmit(struct sk_
frag->size, DMA_TO_DEVICE);
desc[curfrag+1].fields.length = frag->size;
desc[curfrag+1].fields.valid = 1;
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ desc[curfrag+1].fields.no_csum = 1;
+ desc[curfrag+1].fields.csum_good = 1;
+ }
if(dma_mapping_error(desc[curfrag+1].fields.address)) {
ibmveth_error_printk("tx: unable to map fragment %d\n", curfrag);
@@ -792,7 +821,11 @@ static int ibmveth_poll(struct net_devic
} else {
int length = ibmveth_rxq_frame_length(adapter);
int offset = ibmveth_rxq_frame_offset(adapter);
+ int csum_good = ibmveth_rxq_csum_good(adapter);
+
skb = ibmveth_rxq_get_buffer(adapter);
+ if (csum_good)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
ibmveth_rxq_harvest_buffer(adapter);
@@ -962,8 +995,10 @@ static void ibmveth_poll_controller(stru
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
{
int rc, i;
+ long ret;
struct net_device *netdev;
struct ibmveth_adapter *adapter = NULL;
+ union ibmveth_illan_attributes set_attr, ret_attr;
unsigned char *mac_addr_p;
unsigned int *mcastFilterSize_p;
@@ -1058,6 +1093,24 @@ static int __devinit ibmveth_probe(struc
ibmveth_debug_printk("registering netdev...\n");
+ ret = h_illan_attributes(dev->unit_address, 0, 0, &ret_attr.desc);
+
+ if (ret == H_SUCCESS && !ret_attr.fields.active_trunk &&
+ !ret_attr.fields.trunk_priority &&
+ ret_attr.fields.csum_offload_padded_pkt_support) {
+ set_attr.desc = 0;
+ set_attr.fields.tcp_csum_offload_ipv4 = 1;
+
+ ret = h_illan_attributes(dev->unit_address, 0, set_attr.desc,
+ &ret_attr.desc);
+
+ if (ret == H_SUCCESS)
+ netdev->features |= NETIF_F_IP_CSUM;
+ else
+ ret = h_illan_attributes(dev->unit_address, set_attr.desc,
+ 0, &ret_attr.desc);
+ }
+
rc = register_netdev(netdev);
if(rc) {
diff -puN drivers/net/ibmveth.h~ibmveth_csum_offload drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_csum_offload 2007-08-01 14:55:11.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-08-01 14:55:11.000000000 -0500
@@ -67,6 +67,21 @@ static inline long h_send_logical_lan(un
return rc;
}
+static inline long h_illan_attributes(unsigned long unit_address,
+ unsigned long reset_mask, unsigned long set_mask,
+ unsigned long *ret_attributes)
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall(H_ILLAN_ATTRIBUTES, retbuf, unit_address,
+ reset_mask, set_mask);
+
+ *ret_attributes = retbuf[0];
+
+ return rc;
+}
+
#define h_multicast_ctrl(ua, cmd, mac) \
plpar_hcall_norets(H_MULTICAST_CTRL, ua, cmd, mac)
@@ -141,7 +156,9 @@ struct ibmveth_adapter {
struct ibmveth_buf_desc_fields {
u32 valid : 1;
u32 toggle : 1;
- u32 reserved : 6;
+ u32 reserved : 4;
+ u32 no_csum : 1;
+ u32 csum_good : 1;
u32 length : 24;
u32 address;
};
@@ -151,10 +168,30 @@ union ibmveth_buf_desc {
struct ibmveth_buf_desc_fields fields;
};
+struct ibmveth_illan_attributes_fields {
+ u32 reserved;
+ u32 reserved2 : 18;
+ u32 csum_offload_padded_pkt_support : 1;
+ u32 reserved3 : 1;
+ u32 trunk_priority : 4;
+ u32 reserved4 : 5;
+ u32 tcp_csum_offload_ipv6 : 1;
+ u32 tcp_csum_offload_ipv4 : 1;
+ u32 active_trunk : 1;
+};
+
+union ibmveth_illan_attributes {
+ u64 desc;
+ struct ibmveth_illan_attributes_fields fields;
+};
+
struct ibmveth_rx_q_entry {
u16 toggle : 1;
u16 valid : 1;
- u16 reserved : 14;
+ u16 reserved : 4;
+ u16 no_csum : 1;
+ u16 csum_good : 1;
+ u16 reserved2 : 8;
u16 offset;
u32 length;
u64 correlator;
_
^ 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