* Re: Bridge stays down until a port is added
From: Stephen Hemminger @ 2011-08-11 22:41 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
In-Reply-To: <20110811205429.GB21307@torres.zugschlus.de>
On Thu, 11 Aug 2011 22:54:29 +0200
Marc Haber <mh+netdev@zugschlus.de> wrote:
> Hi Stephen,
>
> On Thu, Aug 11, 2011 at 08:17:06AM -0700, Stephen Hemminger wrote:
> > On Thu, 11 Aug 2011 09:06:59 +0200
> > Marc Haber <mh+netdev@zugschlus.de> wrote:
> > > Is that a feature? If so, why does the interface stay pingable after
> > > removing the dummy0 interface from the bridge?
> >
> > Yes, there are no links to send a packet so it seems logical
> > that there would be no carrier.
>
> Yes, but if I can configure an IP address to the bridge I would expect
> it to be reachable even if there are no interfaces in the bridge.
> "Older" kernels used to behave like that.
>
> > > New new behavior is somewhat unhandy when one uses the bridge address
> > > for services that the host offers, to save on IP addresses and
> > > networks (for example, when one has only a single IP address and a
> > > single additional network), since one has to take extra measures to
> > > have the addresses on the bridge interface reachable.
> > >
> > > Or am I doing things wrong?
> >
> > The goal is to make the bridge behave the same as a vlan or
> > a physical device. Could you explain better what the application(s)
> > would expect.
>
> I have a number of housing systems that have only a single IP address
> on their eth0, but an IP network routed to bring virtual machines
> running on these systems online. The virtual machines are all on br0,
> and the host is routing between eth0 and br0. To route, it needs its
> own IP address on br0, and I have not resisted the temptation of
> running servies on the br0 IP address.
>
> It is unnatural to not have the br0 IP address reachable unless the
> first VM is running. I have, in the mean time, created a dummy0
> interface and am adding dummy0 to br0 just to have the bridge
> operational, but that's a hack. I'd like to have the old behavior back
> as an optional configuration.
I still say why should bridge behave differently than bonding
or a physical device? I wonder if part of the difference is that real
devices have transmit queues and the test for link being up
is done in IP based on transmit queue rather than on carrier state.
On routers, it is common to assign some addresses to loopback device so
they stay up independent of the underlying links.
^ permalink raw reply
* [net 4/4] e1000e: increase driver version number
From: Jeff Kirsher @ 2011-08-11 22:31 UTC (permalink / raw)
To: davem; +Cc: Bruce Allan, netdev, gospo, Jeff Kirsher
In-Reply-To: <1313101908-11622-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index c0406b1..362f703 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -56,7 +56,7 @@
#define DRV_EXTRAVERSION "-k"
-#define DRV_VERSION "1.3.16" DRV_EXTRAVERSION
+#define DRV_VERSION "1.4.4" DRV_EXTRAVERSION
char e1000e_driver_name[] = "e1000e";
const char e1000e_driver_version[] = DRV_VERSION;
--
1.7.6
^ permalink raw reply related
* [net 3/4] e1000e: alternate MAC address update
From: Jeff Kirsher @ 2011-08-11 22:31 UTC (permalink / raw)
To: davem; +Cc: Bruce Allan, netdev, gospo, Jeff Kirsher
In-Reply-To: <1313101908-11622-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
If word 0x37 in the EEPROM is 0xFFFF _or_ 0x0000, then there is no
alternate MAC address in the EEPROM.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/lib.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
index 58af091..0893ab1 100644
--- a/drivers/net/e1000e/lib.c
+++ b/drivers/net/e1000e/lib.c
@@ -201,10 +201,10 @@ s32 e1000_check_alt_mac_addr_generic(struct e1000_hw *hw)
goto out;
}
- if (nvm_alt_mac_addr_offset == 0xFFFF) {
+ if ((nvm_alt_mac_addr_offset == 0xFFFF) ||
+ (nvm_alt_mac_addr_offset == 0x0000))
/* There is no Alternate MAC Address */
goto out;
- }
if (hw->bus.func == E1000_FUNC_1)
nvm_alt_mac_addr_offset += E1000_ALT_MAC_ADDRESS_OFFSET_LAN1;
--
1.7.6
^ permalink raw reply related
* [net 2/4] e1000e: do not disable receiver on 82574/82583
From: Jeff Kirsher @ 2011-08-11 22:31 UTC (permalink / raw)
To: davem; +Cc: Bruce Allan, netdev, gospo, Jeff Kirsher
In-Reply-To: <1313101908-11622-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
Due to a hardware erratum, the receiver on 82574 and 82583 should not be
stopped once it has been started.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/82571.c | 6 ++++--
drivers/net/e1000e/e1000.h | 1 +
drivers/net/e1000e/ethtool.c | 3 ++-
drivers/net/e1000e/netdev.c | 7 +++++--
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e1000e/82571.c b/drivers/net/e1000e/82571.c
index 480f259..536b3a5 100644
--- a/drivers/net/e1000e/82571.c
+++ b/drivers/net/e1000e/82571.c
@@ -2085,7 +2085,8 @@ struct e1000_info e1000_82574_info = {
| FLAG_HAS_AMT
| FLAG_HAS_CTRLEXT_ON_LOAD,
.flags2 = FLAG2_CHECK_PHY_HANG
- | FLAG2_DISABLE_ASPM_L0S,
+ | FLAG2_DISABLE_ASPM_L0S
+ | FLAG2_NO_DISABLE_RX,
.pba = 32,
.max_hw_frame_size = DEFAULT_JUMBO,
.get_variants = e1000_get_variants_82571,
@@ -2104,7 +2105,8 @@ struct e1000_info e1000_82583_info = {
| FLAG_HAS_AMT
| FLAG_HAS_JUMBO_FRAMES
| FLAG_HAS_CTRLEXT_ON_LOAD,
- .flags2 = FLAG2_DISABLE_ASPM_L0S,
+ .flags2 = FLAG2_DISABLE_ASPM_L0S
+ | FLAG2_NO_DISABLE_RX,
.pba = 32,
.max_hw_frame_size = DEFAULT_JUMBO,
.get_variants = e1000_get_variants_82571,
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index 638d175..35916f4 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -453,6 +453,7 @@ struct e1000_info {
#define FLAG2_DISABLE_ASPM_L0S (1 << 7)
#define FLAG2_DISABLE_AIM (1 << 8)
#define FLAG2_CHECK_PHY_HANG (1 << 9)
+#define FLAG2_NO_DISABLE_RX (1 << 10)
#define E1000_RX_DESC_PS(R, i) \
(&(((union e1000_rx_desc_packet_split *)((R).desc))[i]))
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index 06d88f3..6a0526a 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -1206,7 +1206,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
rx_ring->next_to_clean = 0;
rctl = er32(RCTL);
- ew32(RCTL, rctl & ~E1000_RCTL_EN);
+ if (!(adapter->flags2 & FLAG2_NO_DISABLE_RX))
+ ew32(RCTL, rctl & ~E1000_RCTL_EN);
ew32(RDBAL, ((u64) rx_ring->dma & 0xFFFFFFFF));
ew32(RDBAH, ((u64) rx_ring->dma >> 32));
ew32(RDLEN, rx_ring->size);
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index ab4be80..c0406b1 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -2915,7 +2915,8 @@ static void e1000_configure_rx(struct e1000_adapter *adapter)
/* disable receives while setting up the descriptors */
rctl = er32(RCTL);
- ew32(RCTL, rctl & ~E1000_RCTL_EN);
+ if (!(adapter->flags2 & FLAG2_NO_DISABLE_RX))
+ ew32(RCTL, rctl & ~E1000_RCTL_EN);
e1e_flush();
usleep_range(10000, 20000);
@@ -3394,7 +3395,8 @@ void e1000e_down(struct e1000_adapter *adapter)
/* disable receives in the hardware */
rctl = er32(RCTL);
- ew32(RCTL, rctl & ~E1000_RCTL_EN);
+ if (!(adapter->flags2 & FLAG2_NO_DISABLE_RX))
+ ew32(RCTL, rctl & ~E1000_RCTL_EN);
/* flush and sleep below */
netif_stop_queue(netdev);
@@ -3403,6 +3405,7 @@ void e1000e_down(struct e1000_adapter *adapter)
tctl = er32(TCTL);
tctl &= ~E1000_TCTL_EN;
ew32(TCTL, tctl);
+
/* flush both disables and wait for them to finish */
e1e_flush();
usleep_range(10000, 20000);
--
1.7.6
^ permalink raw reply related
* [net 1/4] e1000e: alternate MAC address does not work on device id 0x1060
From: Jeff Kirsher @ 2011-08-11 22:31 UTC (permalink / raw)
To: davem; +Cc: Bruce Allan, netdev, gospo, stable, Jeff Kirsher
In-Reply-To: <1313101908-11622-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
This issue is present all the way back to 2.6.34 kernels.
CC: <stable@kernel.org>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeffrey Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/lib.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
index 7898a67..58af091 100644
--- a/drivers/net/e1000e/lib.c
+++ b/drivers/net/e1000e/lib.c
@@ -190,7 +190,8 @@ s32 e1000_check_alt_mac_addr_generic(struct e1000_hw *hw)
/* Check for LOM (vs. NIC) or one of two valid mezzanine cards */
if (!((nvm_data & NVM_COMPAT_LOM) ||
(hw->adapter->pdev->device == E1000_DEV_ID_82571EB_SERDES_DUAL) ||
- (hw->adapter->pdev->device == E1000_DEV_ID_82571EB_SERDES_QUAD)))
+ (hw->adapter->pdev->device == E1000_DEV_ID_82571EB_SERDES_QUAD) ||
+ (hw->adapter->pdev->device == E1000_DEV_ID_82571EB_SERDES)))
goto out;
ret_val = e1000_read_nvm(hw, NVM_ALT_MAC_ADDR_PTR, 1,
--
1.7.6
^ permalink raw reply related
* [net 0/4]{pull request] Intel Wired LAN Driver Update
From: Jeff Kirsher @ 2011-08-11 22:31 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
The following series contains 4 updates to e1000e, one of which can be
applied to stable kernels back to 2.6.34.
The following are changes since commit a02bc7084501d2edecb0e5b9de56da070db19aa:
PCnet: Fix section mismatch
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net master
Bruce Allan (4):
e1000e: alternate MAC address does not work on device id 0x1060
e1000e: do not disable receiver on 82574/82583
e1000e: alternate MAC address update
e1000e: increase driver version number
drivers/net/e1000e/82571.c | 6 ++++--
drivers/net/e1000e/e1000.h | 1 +
drivers/net/e1000e/ethtool.c | 3 ++-
drivers/net/e1000e/lib.c | 7 ++++---
drivers/net/e1000e/netdev.c | 9 ++++++---
5 files changed, 17 insertions(+), 9 deletions(-)
--
1.7.6
^ permalink raw reply
* Re: [PATCH v2] net: add Documentation/networking/scaling.txt
From: Will de Bruijn @ 2011-08-11 21:34 UTC (permalink / raw)
To: Rick Jones; +Cc: Eric Dumazet, rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <4E44192A.2070204@hp.com>
>> Well, patch was already accepted by David in net tree two days ago ;)
>
> Didn't see the customary "Applied" email - mailer glitch somewhere?
>
I didn't catch that either. Since it's already in, I instead wrote a
patch set where
[1/2] adds one-liners to 00-INDEX for scaling.txt and all other
missing entries (I had no idea how many there were when I started)
[2/2] fixes the few text-related issues that Rick raised below.
Will send them out shortly.
> <rss>
> Whether it lowers latency in the absence of an interrupt processing
> bottleneck depends on whether or not the application(s) receiving the data
> are able/allowed to run on the CPU(s) to which the IRQs of the queues are
> directed right?
The latency saved would be the time spent in the interrupt handler.
With multiple application threads, this delay is reduced if packets
are spread between interrupt service routines on different CPUs. These
savings, if any, are irrespective of where the application threads are
run. I have no data for the practical savings in absence of a
bottleneck: it could be inconsequential.
> Also, what mpstat and its ilk shows as CPUs could be HW threads - is it
> indeed the case that one is optimal when there are as many queues as there
> are HW threads, or is it when there are as many queues as there are discrete
> cores?
In my experience, cores. I'll add a brief statement on HT.
> If I have disabled interrupt coalescing in the name of latency, does the
> number of queues actually affect the number of interrupts?
Good point: I suppose it doesn't.
> Certainly any CPU processing interrupts that stays below 100% utilization is
> less likely to be a bottleneck, but if there are algorithms/heuristics that
> get more efficient under load, staying below the 100% CPU utilization mark
> doesn't mean that peak efficiency has been reached. If there is something
> that processes more and more packets per lock grab/release then it is
> actually most efficient in terms of packets processed per unit CPU
> consumption once one gets to the ragged edge of saturation.
a busy polling CPU would be an example where measuring utilization is
useless. But for default interrupt-based device driver operation,
utilization of a CPU dedicated exclusively to HW interrupt processing
is indicative of overflow.
> Is utilization of the rx ring associated with the queue the more accurate,
> albeit unavailable, measure of saturation?
measuring overflow here could be an interesting alternative.
> This isn't the first mention of "cache domain"
I will add a definition on first use.
> This one is more drift than critique of the documentation itself, but just
> how often is the scheduler shuffling a thread of execution around anyway? I
> would have thought that was happening on a timescale that would seem
> positively glacial compared to packet arrival rates.
I didn't contribute to the evaluation or implementation, so cannot
answer decisively (just happen to have written a user's guide for
colleagues that could be reworked into this)
> Again, drifting from critique simply of the documentation, but if
> accelerated RFS is indeed goodness when RFS is being used and the NIC HW
> supports it, shouldn't it be enabled automagically? And then drifting back
> to the documentation itself, if accelerated RFS isn't enabled automagically
> with RFS today, does the reason suggest a caveat to the suggested
> configuration?
It probably should be enabled automatically, indeed.
> I'd probably go with "over all packets in the flow"
will change that.
> And I'm curious/confused about rates of thread migration vs packets - it
> seems like the mechanisms in place to avoid OOO packets have a property that
> the queue selected can remain "stuck" when the packet rates are sufficiently
> high.
It sounds like that, yes.
> If being stuck isn't likely, it suggests that "normal" processing is
> enough to get packets drained - that the thread of execution is (at least in
> the context of sending and receiving traffic) going idle.
Not necessarily, if a single thread processes many connections at
once. State is kept on a per connection basis in the sk struct.
> In the specific example of TCP, I see where ACK of data is sufficient to
> guarantee no OOO on outbound when migrating, but all that is really
> necessary is transmit completion by the NIC, no? Admittedly, getting that
> information to TCP is probably undesired overhead, but doesn't using the ACK
> "penalize" the thread/TCP talking to more remote (in terms of RTT)
> destinations?
Probably, but perhaps someone with more intimate knowledge of the
implementation should answer definitely.
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Marc Haber @ 2011-08-11 20:54 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110811081706.7307e8b2@nehalam.ftrdhcpuser.net>
Hi Stephen,
On Thu, Aug 11, 2011 at 08:17:06AM -0700, Stephen Hemminger wrote:
> On Thu, 11 Aug 2011 09:06:59 +0200
> Marc Haber <mh+netdev@zugschlus.de> wrote:
> > Is that a feature? If so, why does the interface stay pingable after
> > removing the dummy0 interface from the bridge?
>
> Yes, there are no links to send a packet so it seems logical
> that there would be no carrier.
Yes, but if I can configure an IP address to the bridge I would expect
it to be reachable even if there are no interfaces in the bridge.
"Older" kernels used to behave like that.
> > New new behavior is somewhat unhandy when one uses the bridge address
> > for services that the host offers, to save on IP addresses and
> > networks (for example, when one has only a single IP address and a
> > single additional network), since one has to take extra measures to
> > have the addresses on the bridge interface reachable.
> >
> > Or am I doing things wrong?
>
> The goal is to make the bridge behave the same as a vlan or
> a physical device. Could you explain better what the application(s)
> would expect.
I have a number of housing systems that have only a single IP address
on their eth0, but an IP network routed to bring virtual machines
running on these systems online. The virtual machines are all on br0,
and the host is routing between eth0 and br0. To route, it needs its
own IP address on br0, and I have not resisted the temptation of
running servies on the br0 IP address.
It is unnatural to not have the br0 IP address reachable unless the
first VM is running. I have, in the mean time, created a dummy0
interface and am adding dummy0 to br0 just to have the bridge
operational, but that's a hack. I'd like to have the old behavior back
as an optional configuration.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
^ permalink raw reply
* Re: Intel 82599 ixgbe driver performance
From: Rick Jones @ 2011-08-11 18:43 UTC (permalink / raw)
To: J.Hwan Kim; +Cc: netdev
In-Reply-To: <4E433706.2020302@gmail.com>
On 08/10/2011 06:57 PM, J.Hwan Kim wrote:
> On 2011년 08월 11일 05:58, Rick Jones wrote:
>> On 08/09/2011 11:19 PM, J.Hwan Kim wrote:
>>> Hi, everyone
>>>
>>> I'm testing our network card which includes intel 82599 based on
>>> ixgbe driver. I wonder what is the Rx performance of i82599 without
>>> network stack only with 64Byte frames. Our driver reads the packet
>>> directly from DMA packet buffer and push to the application without
>>> passing through linux kernel stack. It seems that the intel 82599
>>> cannot push 64B frames to DMA area in 10G. Is it right?
>>
>> Does your driver perform a copy of that 64B frame to user space?
> Our driver and user application shares the packet memory
>
>> Is this a single-threaded test running?
> Now, 4 core is running and 4 RX queue is used, of which intrerrupt
> affinity is set, but the result is worse than 1 single queue.
>> What does an lat_mem_rd -t (-t for random stride) test from lmbench
>> give for your system's memory latency? (Perhaps using numactl to
>> ensure local, or remote memory access, as you desire)
> ./lat_mem_rd -t 128
> "stride=64
>
> 0.00049 1.003
> 0.00098 1.003
> 0.00195 1.003
> 0.00293 1.003
> 0.00391 1.003
> 0.00586 1.003
> 0.00781 1.003
> 0.01172 1.003
> 0.01562 1.003
> 0.02344 1.003
> 0.03125 1.003
> 0.04688 5.293
> 0.06250 5.307
> 0.09375 5.571
> 0.12500 5.683
> 0.18750 5.683
> 0.25000 5.683
> 0.37500 16.394
> 0.50000 42.394
Unless the chip you are using has a rather tiny (by today's standards)
data cache, you need to go much father there - I suspect that at 0.5 MB
you have not yet gotten beyond the size of the last level of data cache
on the chip.
I would suggest:
(from a system that is not otherwise idle...)
./lat_mem_rd -t 512 256"stride=256
0.00049 1.237
0.00098 1.239
0.00195 1.228
0.00293 1.238
0.00391 1.243
0.00586 1.238
0.00781 1.250
0.01172 1.249
0.01562 1.251
0.02344 1.247
0.03125 1.247
0.04688 3.125
0.06250 3.153
0.09375 3.158
0.12500 3.177
0.18750 6.636
0.25000 8.729
0.37500 16.167
0.50000 16.901
0.75000 16.953
1.00000 17.362
1.50000 18.781
2.00000 20.243
3.00000 23.434
4.00000 24.965
6.00000 35.951
8.00000 56.026
12.00000 76.169
16.00000 80.741
24.00000 83.237
32.00000 84.043
48.00000 84.132
64.00000 83.775
96.00000 83.298
128.00000 83.039
192.00000 82.659
256.00000 82.464
384.00000 82.280
512.00000 82.092
You can see the large jump starting at 8MB - that is where the last
level cache runs-out on the chip I'm using - an Intel W3550.
Now, as run, that will include TLB miss overhead once the area of memory
being accessed is larger than can be mapped by the chip's TLB at the
page size being used. You can use libhugetlbfs to mitigate that through
the use of hugepages.
rick jones
^ permalink raw reply
* [PATCH 08/11] dynamic_debug: make netif_dbg() call __netdev_printk()
From: Jason Baron @ 2011-08-11 18:36 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1313085588.git.jbaron@redhat.com>
From: Jason Baron <jbaron@redhat.com>
Previously, netif_dbg() was using dynamic_dev_dbg() to perform
the underlying printk. Fix it to use __netdev_printk(), instead.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
include/linux/netdevice.h | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9333a03..2797260 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2714,9 +2714,7 @@ do { \
#define netif_dbg(priv, type, netdev, format, args...) \
do { \
if (netif_msg_##type(priv)) \
- dynamic_dev_dbg((netdev)->dev.parent, \
- "%s: " format, \
- netdev_name(netdev), ##args); \
+ dynamic_netdev_dbg(netdev, format, ##args); \
} while (0)
#else
#define netif_dbg(priv, type, dev, format, args...) \
--
1.7.5.4
^ permalink raw reply related
* [PATCH 07/11] dynamic_debug: make netdev_dbg() call __netdev_printk()
From: Jason Baron @ 2011-08-11 18:36 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1313085588.git.jbaron@redhat.com>
From: Jason Baron <jbaron@redhat.com>
Previously, if dynamic debug was enabled netdev_dbg() was using
dynamic_dev_dbg() to print out the underlying msg. Fix this by making
sure netdev_dbg() uses __netdev_printk().
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
include/linux/dynamic_debug.h | 17 +++++++++++++++++
include/linux/netdevice.h | 6 ++++--
lib/dynamic_debug.c | 25 +++++++++++++++++++++++++
net/core/dev.c | 3 ++-
4 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 843cb9e..feaac1e 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -47,6 +47,13 @@ extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
+struct net_device;
+
+extern int __dynamic_netdev_dbg(struct _ddebug *descriptor,
+ const struct net_device *dev,
+ const char *fmt, ...)
+ __attribute__ ((format (printf, 3, 4)));
+
#define dynamic_pr_debug(fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -67,6 +74,16 @@ extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
__dynamic_dev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__); \
} while (0)
+#define dynamic_netdev_dbg(dev, fmt, ...) do { \
+ static struct _ddebug descriptor \
+ __used \
+ __attribute__((section("__verbose"), aligned(8))) = \
+ { KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
+ _DPRINTK_FLAGS_DEFAULT }; \
+ if (unlikely(descriptor.enabled)) \
+ __dynamic_netdev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__);\
+ } while (0)
+
#else
static inline int ddebug_remove_module(const char *mod)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ddee79b..9333a03 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2617,6 +2617,9 @@ static inline const char *netdev_name(const struct net_device *dev)
return dev->name;
}
+extern int __netdev_printk(const char *level, const struct net_device *dev,
+ struct va_format *vaf);
+
extern int netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...)
__attribute__ ((format (printf, 3, 4)));
@@ -2644,8 +2647,7 @@ extern int netdev_info(const struct net_device *dev, const char *format, ...)
#elif defined(CONFIG_DYNAMIC_DEBUG)
#define netdev_dbg(__dev, format, args...) \
do { \
- dynamic_dev_dbg((__dev)->dev.parent, "%s: " format, \
- netdev_name(__dev), ##args); \
+ dynamic_netdev_dbg(__dev, format, ##args); \
} while (0)
#else
#define netdev_dbg(__dev, format, args...) \
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 4fc03dd..ee3b9ba 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -33,6 +33,7 @@
#include <linux/hardirq.h>
#include <linux/sched.h>
#include <linux/device.h>
+#include <linux/netdevice.h>
extern struct _ddebug __start___verbose[];
extern struct _ddebug __stop___verbose[];
@@ -503,6 +504,30 @@ int __dynamic_dev_dbg(struct _ddebug *descriptor,
}
EXPORT_SYMBOL(__dynamic_dev_dbg);
+int __dynamic_netdev_dbg(struct _ddebug *descriptor,
+ const struct net_device *dev, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int res;
+
+ BUG_ON(!descriptor);
+ BUG_ON(!fmt);
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ res = dynamic_emit_prefix(descriptor);
+ res += __netdev_printk(KERN_CONT, dev, &vaf);
+
+ va_end(args);
+
+ return res;
+}
+EXPORT_SYMBOL(__dynamic_netdev_dbg);
+
static __initdata char ddebug_setup_string[1024];
static __init int ddebug_setup_query(char *str)
{
diff --git a/net/core/dev.c b/net/core/dev.c
index 17d67b5..c47a7bc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6290,7 +6290,7 @@ const char *netdev_drivername(const struct net_device *dev)
return empty;
}
-static int __netdev_printk(const char *level, const struct net_device *dev,
+int __netdev_printk(const char *level, const struct net_device *dev,
struct va_format *vaf)
{
int r;
@@ -6305,6 +6305,7 @@ static int __netdev_printk(const char *level, const struct net_device *dev,
return r;
}
+EXPORT_SYMBOL(__netdev_printk);
int netdev_printk(const char *level, const struct net_device *dev,
const char *format, ...)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 01/11] dynamic_debug: Add __dynamic_dev_dbg
From: Jason Baron @ 2011-08-11 18:36 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
In-Reply-To: <cover.1313085588.git.jbaron@redhat.com>
From: Joe Perches <joe@perches.com>
Unlike dynamic_pr_debug, dynamic uses of dev_dbg can not
currently add task_pid/KBUILD_MODNAME/__func__/__LINE__
to selected debug output.
Add a new function similar to dynamic_pr_debug to
optionally emit these prefixes.
Cc: Aloisio Almeida <aloisio.almeida@openbossa.org>
Noticed-by: Aloisio Almeida <aloisio.almeida@openbossa.org>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jason Baron <jbaron@redhat.com>
---
drivers/base/core.c | 5 +++--
include/linux/device.h | 5 +++++
include/linux/dynamic_debug.h | 10 ++++++++--
lib/dynamic_debug.c | 38 ++++++++++++++++++++++++++++++++++++++
4 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bc8729d..82c8654 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1764,8 +1764,8 @@ void device_shutdown(void)
#ifdef CONFIG_PRINTK
-static int __dev_printk(const char *level, const struct device *dev,
- struct va_format *vaf)
+int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
{
if (!dev)
return printk("%s(NULL device *): %pV", level, vaf);
@@ -1773,6 +1773,7 @@ static int __dev_printk(const char *level, const struct device *dev,
return printk("%s%s %s: %pV",
level, dev_driver_string(dev), dev_name(dev), vaf);
}
+EXPORT_SYMBOL(__dev_printk);
int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
diff --git a/include/linux/device.h b/include/linux/device.h
index c20dfbf..4639419 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -785,6 +785,8 @@ extern const char *dev_driver_string(const struct device *dev);
#ifdef CONFIG_PRINTK
+extern int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf);
extern int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
@@ -805,6 +807,9 @@ extern int _dev_info(const struct device *dev, const char *fmt, ...)
#else
+static inline int __dev_printk(const char *level, const struct device *dev,
+ struct va_format *vaf)
+ { return 0; }
static inline int dev_printk(const char *level, const struct device *dev,
const char *fmt, ...)
__attribute__ ((format (printf, 3, 4)));
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index e747ecd..bdf1531 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -47,6 +47,13 @@ extern int ddebug_remove_module(const char *mod_name);
extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
__attribute__ ((format (printf, 2, 3)));
+struct device;
+
+extern int __dynamic_dev_dbg(struct _ddebug *descriptor,
+ const struct device *dev,
+ const char *fmt, ...)
+ __attribute__ ((format (printf, 3, 4)));
+
#define dynamic_pr_debug(fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -57,7 +64,6 @@ extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
__dynamic_pr_debug(&descriptor, pr_fmt(fmt), ##__VA_ARGS__); \
} while (0)
-
#define dynamic_dev_dbg(dev, fmt, ...) do { \
static struct _ddebug descriptor \
__used \
@@ -65,7 +71,7 @@ extern int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
{ KBUILD_MODNAME, __func__, __FILE__, fmt, __LINE__, \
_DPRINTK_FLAGS_DEFAULT }; \
if (unlikely(descriptor.enabled)) \
- dev_printk(KERN_DEBUG, dev, fmt, ##__VA_ARGS__); \
+ __dynamic_dev_dbg(&descriptor, dev, fmt, ##__VA_ARGS__); \
} while (0)
#else
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 75ca78f..63b6f95 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -30,6 +30,7 @@
#include <linux/jump_label.h>
#include <linux/hardirq.h>
#include <linux/sched.h>
+#include <linux/device.h>
extern struct _ddebug __start___verbose[];
extern struct _ddebug __stop___verbose[];
@@ -456,6 +457,43 @@ int __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
}
EXPORT_SYMBOL(__dynamic_pr_debug);
+int __dynamic_dev_dbg(struct _ddebug *descriptor,
+ const struct device *dev, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+ int res;
+
+ BUG_ON(!descriptor);
+ BUG_ON(!fmt);
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va = &args;
+
+ res = printk(KERN_DEBUG);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_TID) {
+ if (in_interrupt())
+ res += printk(KERN_CONT "<intr> ");
+ else
+ res += printk(KERN_CONT "[%d] ", task_pid_vnr(current));
+ }
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_MODNAME)
+ res += printk(KERN_CONT "%s:", descriptor->modname);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
+ res += printk(KERN_CONT "%s:", descriptor->function);
+ if (descriptor->flags & _DPRINTK_FLAGS_INCL_LINENO)
+ res += printk(KERN_CONT "%d ", descriptor->lineno);
+
+ res += __dev_printk(KERN_CONT, dev, &vaf);
+
+ va_end(args);
+
+ return res;
+}
+EXPORT_SYMBOL(__dynamic_dev_dbg);
+
static __initdata char ddebug_setup_string[1024];
static __init int ddebug_setup_query(char *str)
{
--
1.7.5.4
^ permalink raw reply related
* [PATCH 00/11] various fixes v3
From: Jason Baron @ 2011-08-11 18:36 UTC (permalink / raw)
To: gregkh
Cc: joe, jim.cromie, bvanassche, linux-kernel, davem, aloisio.almeida,
netdev
Hi,
Dynamic debug fixes and cleanups. Only changes from v2 are a re-base against
Linus's latest tree and the inclusion of the re-posted version for patch #11.
Thanks,
-Jason
Joe Perches (4):
dynamic_debug: Add __dynamic_dev_dbg
dynamic_debug: Consolidate prefix output to single routine
dynamic_debug: Remove uses of KERN_CONT in dynamic_emit_prefix
dynamic_debug: Convert printks to pr_<level>
Jason Baron (7):
dynamic_debug: remove unused control variables
dynamic_debug: add Jason Baron as maintainer
dynamic_debug: make netdev_dbg() call __netdev_printk()
dynamic_debug: make netif_dbg() call __netdev_printk()
dynamic_debug: consolidate repetitive struct _ddebug descriptor definitions
dynamic_debug: remove num_enabled accounting
dynamic_debug: use a single printk() to emit msgs
MAINTAINERS | 6 ++
drivers/base/core.c | 5 +-
include/linux/device.h | 5 ++
include/linux/dynamic_debug.h | 51 ++++++++-----
include/linux/netdevice.h | 10 ++--
lib/dynamic_debug.c | 155 ++++++++++++++++++++++++++--------------
net/core/dev.c | 3 +-
7 files changed, 153 insertions(+), 82 deletions(-)
--
1.7.5.4
^ permalink raw reply
* Re: Move interface across network namespaces
From: Renato Westphal @ 2011-08-11 18:29 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev
In-Reply-To: <m1r54s8lq4.fsf@fess.ebiederm.org>
2011/8/11 Eric W. Biederman <ebiederm@xmission.com>:
> Renato Westphal <renatowestphal@gmail.com> writes:
>
>> Hello,
>>
>> I have two questions regarding the process of moving a network
>> interface across different network namespaces:
>>
>> * When I move an interface, all the virtual interfaces attached to it
>> are deleted. Is there any reason for such odd behavior? I would like
>> to move some network interfaces and keep the attached vlans untouched.
>
> The defined semantics are that a network device is unregistered from
> the networking stack in one network namespace and then registered
> with the networking stack in another. It is an unfortunate fact
> that when vlan devices see their underlying device being unregistered
> they decide to delete themselves.
>
> A different vlan implementation might be able to have different
> properties but I can't think of any obvious solution other than
> don't do move the device that you have your vlans on top of.
>
Thanks for the info, I can handle with that by modifying my quagga-vrf patches.
>> * The target network namespace sends a RTM_NEWLINK netlink message
>> when an interface is moved to it. In the other hand, the source
>> network namespace doesn't sends a RTM_DELLINK message when an
>> interface is moved from it. This is very annoying because user space
>> applications (such as zebra) can't detect some interface moving
>> operations and then get into an inconsistent state. Anyone knows if
>> there's a workaround for this?
>
> Not getting RTM_DELLINK is a bug. The device registration and
> unregistration code has changed since dev_change_net_namespace was
> written and apparently one of the changes failed to update
> dev_change_net_namespace.
>
Good, that makes a lot more sense. In the kernel 2.6.32.43 the
RTM_DELLINK netlink message is sent when a network interface is moved
from a network namespace. The same doesn't happens in the kernel
2.6.35.13. I'll try to isolate the problem some more.
Best Regards,
Renato.
--
Renato Westphal
^ permalink raw reply
* pull request: wireless 2011-08-11
From: John W. Linville @ 2011-08-11 18:20 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
David,
This is a little batch of patches intended for 3.1.
Included is a fix for a typo that incorrectly calibrated an ath9k phy,
a fix for an skb leak in ath5k, a fix for a bus error on some Broadcom
SoC using b43, a fix for a memory leak in wl1251, and another pair
of calibration fixes for ath9k. A handful of device ID updates are
included as well.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit aa02bc7084501d2edecb0e5b9de56da070db19aa:
PCnet: Fix section mismatch (2011-08-11 07:42:45 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Alex Hacker (1):
ath9k: fix a misprint which leads to incorrect calibration
Anthony Bourguignon (1):
rt2x00: Add rt2870 device id for Dvico usb key
Bob Copeland (1):
ath5k: fix error handling in ath5k_beacon_send
Hauke Mehrtens (1):
b43: read correct register on bcma bus.
Ivo van Doorn (1):
rt2x00: Add new rt73 buffalo USB id
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Julia Lawall (1):
drivers/net/wireless/wl1251: add missing kfree
Larry Finger (1):
rtlwifi: rtl892cu: New USB IDs
Rajkumar Manoharan (2):
ath9k_hw: Fix incorrect Tx control power in AR9003 template
ath9k_hw: update PMU to improve ripple issue for AR9485
drivers/net/wireless/ath/ath5k/base.c | 23 ++++++++++++++---------
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 8 ++++----
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 2 +-
drivers/net/wireless/b43/dma.c | 20 +++++++++++++++++---
drivers/net/wireless/rt2x00/rt2800usb.c | 2 ++
drivers/net/wireless/rt2x00/rt73usb.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 11 ++++++++---
drivers/net/wireless/wl1251/acx.c | 6 +-----
drivers/net/wireless/wl1251/cmd.c | 2 +-
9 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index f54dff4..c3119a6 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1735,6 +1735,8 @@ ath5k_beacon_setup(struct ath5k_hw *ah, struct ath5k_buf *bf)
if (dma_mapping_error(ah->dev, bf->skbaddr)) {
ATH5K_ERR(ah, "beacon DMA mapping failed\n");
+ dev_kfree_skb_any(skb);
+ bf->skb = NULL;
return -EIO;
}
@@ -1819,8 +1821,6 @@ ath5k_beacon_update(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
ath5k_txbuf_free_skb(ah, avf->bbuf);
avf->bbuf->skb = skb;
ret = ath5k_beacon_setup(ah, avf->bbuf);
- if (ret)
- avf->bbuf->skb = NULL;
out:
return ret;
}
@@ -1840,6 +1840,7 @@ ath5k_beacon_send(struct ath5k_hw *ah)
struct ath5k_vif *avf;
struct ath5k_buf *bf;
struct sk_buff *skb;
+ int err;
ATH5K_DBG_UNLIMIT(ah, ATH5K_DEBUG_BEACON, "in beacon_send\n");
@@ -1888,11 +1889,6 @@ ath5k_beacon_send(struct ath5k_hw *ah)
avf = (void *)vif->drv_priv;
bf = avf->bbuf;
- if (unlikely(bf->skb == NULL || ah->opmode == NL80211_IFTYPE_STATION ||
- ah->opmode == NL80211_IFTYPE_MONITOR)) {
- ATH5K_WARN(ah, "bf=%p bf_skb=%p\n", bf, bf ? bf->skb : NULL);
- return;
- }
/*
* Stop any current dma and put the new frame on the queue.
@@ -1906,8 +1902,17 @@ ath5k_beacon_send(struct ath5k_hw *ah)
/* refresh the beacon for AP or MESH mode */
if (ah->opmode == NL80211_IFTYPE_AP ||
- ah->opmode == NL80211_IFTYPE_MESH_POINT)
- ath5k_beacon_update(ah->hw, vif);
+ ah->opmode == NL80211_IFTYPE_MESH_POINT) {
+ err = ath5k_beacon_update(ah->hw, vif);
+ if (err)
+ return;
+ }
+
+ if (unlikely(bf->skb == NULL || ah->opmode == NL80211_IFTYPE_STATION ||
+ ah->opmode == NL80211_IFTYPE_MONITOR)) {
+ ATH5K_WARN(ah, "bf=%p bf_skb=%p\n", bf, bf->skb);
+ return;
+ }
trace_ath5k_tx(ah, bf->skb, &ah->txqs[ah->bhalq]);
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index d109c25..c34bef1 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -307,7 +307,7 @@ static const struct ar9300_eeprom ar9300_default = {
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 1), CTL(60, 0), CTL(60, 0), CTL(60, 1) } },
- { { CTL(60, 1), CTL(60, 0), CTL(0, 0), CTL(0, 0) } },
+ { { CTL(60, 1), CTL(60, 0), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
@@ -884,7 +884,7 @@ static const struct ar9300_eeprom ar9300_x113 = {
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 1), CTL(60, 0), CTL(60, 0), CTL(60, 1) } },
- { { CTL(60, 1), CTL(60, 0), CTL(0, 0), CTL(0, 0) } },
+ { { CTL(60, 1), CTL(60, 0), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
@@ -2040,7 +2040,7 @@ static const struct ar9300_eeprom ar9300_x112 = {
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 1), CTL(60, 0), CTL(60, 0), CTL(60, 1) } },
- { { CTL(60, 1), CTL(60, 0), CTL(0, 0), CTL(0, 0) } },
+ { { CTL(60, 1), CTL(60, 0), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
{ { CTL(60, 0), CTL(60, 1), CTL(60, 0), CTL(60, 0) } },
@@ -3734,7 +3734,7 @@ static void ar9003_hw_internal_regulator_apply(struct ath_hw *ah)
}
} else {
reg_pmu_set = (5 << 1) | (7 << 4) |
- (1 << 8) | (2 << 14) |
+ (2 << 8) | (2 << 14) |
(6 << 17) | (1 << 20) |
(3 << 24) | (1 << 28);
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.h b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
index 6de3f0b..5c59042 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
@@ -850,7 +850,7 @@
#define AR_PHY_TPC_11_B1 (AR_SM1_BASE + 0x220)
#define AR_PHY_PDADC_TAB_1 (AR_SM1_BASE + 0x240)
#define AR_PHY_TX_IQCAL_STATUS_B1 (AR_SM1_BASE + 0x48c)
-#define AR_PHY_TX_IQCAL_CORR_COEFF_B1(_i) (AR_SM_BASE + 0x450 + ((_i) << 2))
+#define AR_PHY_TX_IQCAL_CORR_COEFF_B1(_i) (AR_SM1_BASE + 0x450 + ((_i) << 2))
/*
* Channel 2 Register Map
diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index 83cba22..481e534 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -795,9 +795,23 @@ static u64 supported_dma_mask(struct b43_wldev *dev)
u32 tmp;
u16 mmio_base;
- tmp = b43_read32(dev, SSB_TMSHIGH);
- if (tmp & SSB_TMSHIGH_DMA64)
- return DMA_BIT_MASK(64);
+ switch (dev->dev->bus_type) {
+#ifdef CONFIG_B43_BCMA
+ case B43_BUS_BCMA:
+ tmp = bcma_aread32(dev->dev->bdev, BCMA_IOST);
+ if (tmp & BCMA_IOST_DMA64)
+ return DMA_BIT_MASK(64);
+ break;
+#endif
+#ifdef CONFIG_B43_SSB
+ case B43_BUS_SSB:
+ tmp = ssb_read32(dev->dev->sdev, SSB_TMSHIGH);
+ if (tmp & SSB_TMSHIGH_DMA64)
+ return DMA_BIT_MASK(64);
+ break;
+#endif
+ }
+
mmio_base = b43_dmacontroller_base(0, 0);
b43_write32(dev, mmio_base + B43_DMA32_TXCTL, B43_DMA32_TXADDREXT_MASK);
tmp = b43_read32(dev, mmio_base + B43_DMA32_TXCTL);
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 5075593..9395631 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -921,6 +921,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x07d1, 0x3c16) },
/* Draytek */
{ USB_DEVICE(0x07fa, 0x7712) },
+ /* DVICO */
+ { USB_DEVICE(0x0fe9, 0xb307) },
/* Edimax */
{ USB_DEVICE(0x7392, 0x7711) },
{ USB_DEVICE(0x7392, 0x7717) },
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 6a93939..0baeb89 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2420,6 +2420,7 @@ static struct usb_device_id rt73usb_device_table[] = {
/* Buffalo */
{ USB_DEVICE(0x0411, 0x00d8) },
{ USB_DEVICE(0x0411, 0x00d9) },
+ { USB_DEVICE(0x0411, 0x00e6) },
{ USB_DEVICE(0x0411, 0x00f4) },
{ USB_DEVICE(0x0411, 0x0116) },
{ USB_DEVICE(0x0411, 0x0119) },
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index 942f7a3..ef63c0d 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -281,6 +281,8 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817d, rtl92cu_hal_cfg)},
/* 8188CE-VAU USB minCard (b/g mode only) */
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817e, rtl92cu_hal_cfg)},
+ /* 8188RU in Alfa AWUS036NHR */
+ {RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817f, rtl92cu_hal_cfg)},
/* 8188 Combo for BC4 */
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8754, rtl92cu_hal_cfg)},
@@ -303,20 +305,23 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
{RTL_USB_DEVICE(0x0eb0, 0x9071, rtl92cu_hal_cfg)}, /*NO Brand - Etop*/
/* HP - Lite-On ,8188CUS Slim Combo */
{RTL_USB_DEVICE(0x103c, 0x1629, rtl92cu_hal_cfg)},
+ {RTL_USB_DEVICE(0x13d3, 0x3357, rtl92cu_hal_cfg)}, /* AzureWave */
{RTL_USB_DEVICE(0x2001, 0x3308, rtl92cu_hal_cfg)}, /*D-Link - Alpha*/
{RTL_USB_DEVICE(0x2019, 0xab2a, rtl92cu_hal_cfg)}, /*Planex - Abocom*/
{RTL_USB_DEVICE(0x2019, 0xed17, rtl92cu_hal_cfg)}, /*PCI - Edimax*/
{RTL_USB_DEVICE(0x20f4, 0x648b, rtl92cu_hal_cfg)}, /*TRENDnet - Cameo*/
{RTL_USB_DEVICE(0x7392, 0x7811, rtl92cu_hal_cfg)}, /*Edimax - Edimax*/
- {RTL_USB_DEVICE(0x3358, 0x13d3, rtl92cu_hal_cfg)}, /*Azwave 8188CE-VAU*/
+ {RTL_USB_DEVICE(0x13d3, 0x3358, rtl92cu_hal_cfg)}, /*Azwave 8188CE-VAU*/
/* Russian customer -Azwave (8188CE-VAU b/g mode only) */
- {RTL_USB_DEVICE(0x3359, 0x13d3, rtl92cu_hal_cfg)},
+ {RTL_USB_DEVICE(0x13d3, 0x3359, rtl92cu_hal_cfg)},
+ {RTL_USB_DEVICE(0x4855, 0x0090, rtl92cu_hal_cfg)}, /* Feixun */
+ {RTL_USB_DEVICE(0x4855, 0x0091, rtl92cu_hal_cfg)}, /* NetweeN-Feixun */
+ {RTL_USB_DEVICE(0x9846, 0x9041, rtl92cu_hal_cfg)}, /* Netgear Cameo */
/****** 8192CU ********/
{RTL_USB_DEVICE(0x0586, 0x341f, rtl92cu_hal_cfg)}, /*Zyxel -Abocom*/
{RTL_USB_DEVICE(0x07aa, 0x0056, rtl92cu_hal_cfg)}, /*ATKK-Gemtek*/
{RTL_USB_DEVICE(0x07b8, 0x8178, rtl92cu_hal_cfg)}, /*Funai -Abocom*/
- {RTL_USB_DEVICE(0x07b8, 0x8178, rtl92cu_hal_cfg)}, /*Abocom -Abocom*/
{RTL_USB_DEVICE(0x2001, 0x3307, rtl92cu_hal_cfg)}, /*D-Link-Cameo*/
{RTL_USB_DEVICE(0x2001, 0x3309, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
{RTL_USB_DEVICE(0x2001, 0x330a, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
diff --git a/drivers/net/wireless/wl1251/acx.c b/drivers/net/wireless/wl1251/acx.c
index ef8370e..ad87a1a 100644
--- a/drivers/net/wireless/wl1251/acx.c
+++ b/drivers/net/wireless/wl1251/acx.c
@@ -140,8 +140,6 @@ int wl1251_acx_sleep_auth(struct wl1251 *wl, u8 sleep_auth)
auth->sleep_auth = sleep_auth;
ret = wl1251_cmd_configure(wl, ACX_SLEEP_AUTH, auth, sizeof(*auth));
- if (ret < 0)
- return ret;
out:
kfree(auth);
@@ -681,10 +679,8 @@ int wl1251_acx_cca_threshold(struct wl1251 *wl)
ret = wl1251_cmd_configure(wl, ACX_CCA_THRESHOLD,
detection, sizeof(*detection));
- if (ret < 0) {
+ if (ret < 0)
wl1251_warning("failed to set cca threshold: %d", ret);
- return ret;
- }
out:
kfree(detection);
diff --git a/drivers/net/wireless/wl1251/cmd.c b/drivers/net/wireless/wl1251/cmd.c
index 81f164b..d14d69d 100644
--- a/drivers/net/wireless/wl1251/cmd.c
+++ b/drivers/net/wireless/wl1251/cmd.c
@@ -241,7 +241,7 @@ int wl1251_cmd_data_path(struct wl1251 *wl, u8 channel, bool enable)
if (ret < 0) {
wl1251_error("tx %s cmd for channel %d failed",
enable ? "start" : "stop", channel);
- return ret;
+ goto out;
}
wl1251_debug(DEBUG_BOOT, "tx %s cmd channel %d",
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v11 6/6] powerpc: Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-11 18:12 UTC (permalink / raw)
To: Kumar Gala
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Scott Wood, PPC list
In-Reply-To: <9C81E6C0-D278-40BF-8F32-445F870F845A-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Thu, Aug 11, 2011 at 12:41:34PM -0500, Kumar Gala wrote:
>
> On Aug 11, 2011, at 11:07 AM, Robin Holt wrote:
>
> > Allow the p1010 processor to select the flexcan network driver.
> >
> > Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> > Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> > Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> > Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> > Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> > Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> > Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> > ---
> > arch/powerpc/boot/dts/p1010rdb.dts | 8 ++++++++
> > arch/powerpc/platforms/85xx/Kconfig | 2 ++
> > 2 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> > index d6c669c..df89b60 100644
> > --- a/arch/powerpc/boot/dts/p1010rdb.dts
> > +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> > @@ -171,6 +171,14 @@
> > };
> > };
> >
> > + can@1c000 {
> > + clock-frequency = <0x0bebc1fc>;
> > + };
> > +
> > + can1: can@1d000 {
> > + clock-frequency = <0x0bebc1fc>;
> > + };
> > +
>
> set them to 0, as we expect u-boot to fill them in.
Done.
>
> > usb@22000 {
> > phy_type = "utmi";
> > };
> > diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> > index 498534c..c4304ae 100644
> > --- a/arch/powerpc/platforms/85xx/Kconfig
> > +++ b/arch/powerpc/platforms/85xx/Kconfig
> > @@ -70,6 +70,8 @@ config MPC85xx_RDB
> > config P1010_RDB
> > bool "Freescale P1010RDB"
> > select DEFAULT_UIMAGE
> > + select HAVE_CAN_FLEXCAN if NET && CAN
> > + select PPC_CLOCK if CAN_FLEXCAN
>
> Can you move this to arch/powerpc/Kconfig & FSL_SOC instead.
I am not sure. FSL_SOC seems to come with any of the freescale system
on a chip. I would not be that worried, about the flexcan build as
I think that is sufficiently agostic where we will not see problems,
but now we could end up with build failures on any of the other configs
which select CAN_FLEXCAN. I would normally want to do all those builds,
but there is no way I would know how to do that with my limited knowledge
of powerpc and freescale.
If you are comfortable with that, I will happily make the change.
Thanks,
Robin
^ permalink raw reply
* Re: [PATCH v2] net: add Documentation/networking/scaling.txt
From: Rick Jones @ 2011-08-11 18:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Will de Bruijn, rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <1313080279.3261.17.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 08/11/2011 09:31 AM, Eric Dumazet wrote:
> Le jeudi 11 août 2011 à 10:26 -0400, Will de Bruijn a écrit :
>
>>
>> I'll be happy to revise it once more. This version also lacks the
>> required one-line description in Documentation/networking/00-INDEX, so
>> I will have to resubmit, either way.
>>
>
> Well, patch was already accepted by David in net tree two days ago ;)
Didn't see the customary "Applied" email - mailer glitch somewhere?
Anyhow, regardless of how further changes are made, or if they are made,
here's the bits I was considering might a matter of opinion, or perhaps
simply stripes on the bikeshed...
<rss>
> +== Suggested Configuration
> +
> +RSS should be enabled when latency is a concern or whenever receive
> +interrupt processing forms a bottleneck. Spreading load between CPUs
> +decreases queue length. For low latency networking, the optimal setting
> +is to allocate as many queues as there are CPUs in the system (or the
> +NIC maximum, if lower). Because the aggregate number of interrupts grows
> +with each additional queue, the most efficient high-rate configuration
> +is likely the one with the smallest number of receive queues where no
> +CPU that processes receive interrupts reaches 100% utilization. Per-cpu
> +load can be observed using the mpstat utility.
Whether it lowers latency in the absence of an interrupt processing
bottleneck depends on whether or not the application(s) receiving the
data are able/allowed to run on the CPU(s) to which the IRQs of the
queues are directed right?
Also, what mpstat and its ilk shows as CPUs could be HW threads - is it
indeed the case that one is optimal when there are as many queues as
there are HW threads, or is it when there are as many queues as there
are discrete cores?
If I have disabled interrupt coalescing in the name of latency, does the
number of queues actually affect the number of interrupts?
Certainly any CPU processing interrupts that stays below 100%
utilization is less likely to be a bottleneck, but if there are
algorithms/heuristics that get more efficient under load, staying below
the 100% CPU utilization mark doesn't mean that peak efficiency has been
reached. If there is something that processes more and more packets per
lock grab/release then it is actually most efficient in terms of packets
processed per unit CPU consumption once one gets to the ragged edge of
saturation.
Is utilization of the rx ring associated with the queue the more
accurate, albeit unavailable, measure of saturation?
<rps>
> +== Suggested Configuration
> +
> +For a single queue device, a typical RPS configuration would be to set
> +the rps_cpus to the CPUs in the same cache domain of the interrupting
> +CPU. If NUMA locality is not an issue, this could also be all CPUs in
> +the system. At high interrupt rate, it might be wise to exclude the
> +interrupting CPU from the map since that already performs much work.
> +
> +For a multi-queue system, if RSS is configured so that a hardware
> +receive queue is mapped to each CPU, then RPS is probably redundant
> +and unnecessary. If there are fewer hardware queues than CPUs, then
> +RPS might be beneficial if the rps_cpus for each queue are the ones that
> +share the same cache domain as the interrupting CPU for that queue.
This isn't the first mention of "cache domain" - there is actually one
above it in the RSS Configuration section, but is the anticipated
audience reasonably expected to already know what a cache domain is,
particularly as it may relate/differ from NUMA locality?
A very simplistic search for "cache domain" against Documentation/
doesn't find that term used anywhere else.
<rfs>
> +When the scheduler moves a thread to a new CPU while it has outstanding
> +receive packets on the old CPU, packets may arrive out of order. To
> +avoid this, RFS uses a second flow table to track outstanding packets
> +for each flow: rps_dev_flow_table is a table specific to each hardware
> +receive queue of each device. Each table value stores a CPU index and a
> +counter. The CPU index represents the *current* CPU onto which packets
> +for this flow are enqueued for further kernel processing. Ideally, kernel
> +and userspace processing occur on the same CPU, and hence the CPU index
> +in both tables is identical. This is likely false if the scheduler has
> +recently migrated a userspace thread while the kernel still has packets
> +enqueued for kernel processing on the old CPU.
This one is more drift than critique of the documentation itself, but
just how often is the scheduler shuffling a thread of execution around
anyway? I would have thought that was happening on a timescale that
would seem positively glacial compared to packet arrival rates.
<accelerated rfs>
> +== Suggested Configuration
> +
> +This technique should be enabled whenever one wants to use RFS and the
> +NIC supports hardware acceleration.
Again, drifting from critique simply of the documentation, but if
accelerated RFS is indeed goodness when RFS is being used and the NIC HW
supports it, shouldn't it be enabled automagically? And then drifting
back to the documentation itself, if accelerated RFS isn't enabled
automagically with RFS today, does the reason suggest a caveat to the
suggested configuration?
<xps>
> +The queue chosen for transmitting a particular flow is saved in the
> +corresponding socket structure for the flow (e.g. a TCP connection).
> +This transmit queue is used for subsequent packets sent on the flow to
> +prevent out of order (ooo) packets. The choice also amortizes the cost
> +of calling get_xps_queues() over all packets in the connection. To avoid
> +ooo packets, the queue for a flow can subsequently only be changed if
> +skb->ooo_okay is set for a packet in the flow. This flag indicates that
> +there are no outstanding packets in the flow, so the transmit queue can
> +change without the risk of generating out of order packets. The
> +transport layer is responsible for setting ooo_okay appropriately. TCP,
> +for instance, sets the flag when all data for a connection has been
> +acknowledged.
I'd probably go with "over all packets in the flow" as that part is in
the "generic" discussion space rather than the specific example of a TCP
connection.
And I'm curious/confused about rates of thread migration vs packets - it
seems like the mechanisms in place to avoid OOO packets have a property
that the queue selected can remain "stuck" when the packet rates are
sufficiently high. If being stuck isn't likely, it suggests that
"normal" processing is enough to get packets drained - that the thread
of execution is (at least in the context of sending and receiving
traffic) going idle. Is that then consistent with that thread of
execution being bounced from CPU to CPU by the scheduler in the first place?
In the specific example of TCP, I see where ACK of data is sufficient to
guarantee no OOO on outbound when migrating, but all that is really
necessary is transmit completion by the NIC, no? Admittedly, getting
that information to TCP is probably undesired overhead, but doesn't
using the ACK "penalize" the thread/TCP talking to more remote (in terms
of RTT) destinations?
rick jones
^ permalink raw reply
* Re: [PATCH v11 6/6] powerpc: Add flexcan device support for p1010rdb.
From: Kumar Gala @ 2011-08-11 17:41 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Grant Likely,
Marc Kleine-Budde, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <1313078831-2511-7-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
On Aug 11, 2011, at 11:07 AM, Robin Holt wrote:
> Allow the p1010 processor to select the flexcan network driver.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
> arch/powerpc/boot/dts/p1010rdb.dts | 8 ++++++++
> arch/powerpc/platforms/85xx/Kconfig | 2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> index d6c669c..df89b60 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -171,6 +171,14 @@
> };
> };
>
> + can@1c000 {
> + clock-frequency = <0x0bebc1fc>;
> + };
> +
> + can1: can@1d000 {
> + clock-frequency = <0x0bebc1fc>;
> + };
> +
set them to 0, as we expect u-boot to fill them in.
> usb@22000 {
> phy_type = "utmi";
> };
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..c4304ae 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -70,6 +70,8 @@ config MPC85xx_RDB
> config P1010_RDB
> bool "Freescale P1010RDB"
> select DEFAULT_UIMAGE
> + select HAVE_CAN_FLEXCAN if NET && CAN
> + select PPC_CLOCK if CAN_FLEXCAN
Can you move this to arch/powerpc/Kconfig & FSL_SOC instead.
> help
> This option enables support for the MPC85xx RDB (P1010 RDB) board
>
> --
> 1.7.2.1
^ permalink raw reply
* Re: [PATCH v11 5/6] flexcan: Prefer device tree clock frequency if available.
From: Kumar Gala @ 2011-08-11 17:40 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Grant Likely, Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <4E4400CC.3020704-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Aug 11, 2011, at 11:18 AM, Marc Kleine-Budde wrote:
> On 08/11/2011 06:07 PM, Robin Holt wrote:
>> If our CAN device's device tree node has a clock-frequency property,
>> then use that value for the can devices clock frequency. If not, fall
>> back to asking the platform/mach code for the clock frequency associated
>> with the flexcan device.
>
> nitpicking follows inline:
>
>> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
>> To: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
>> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
>> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
>> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
>> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
>> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
>> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>> ---
>> .../devicetree/bindings/net/can/fsl-flexcan.txt | 2 +
>> drivers/net/can/flexcan.c | 33 +++++++++++++++-----
>> 2 files changed, 27 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>> index c78dcbb..a4382c7 100644
>> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>> +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>> @@ -11,6 +11,7 @@ Required properties:
>>
>> - reg : Offset and length of the register set for this device
>> - interrupts : Interrupt tuple for this device
>> +- clock-frequency : The oscillator frequency driving the flexcan device
>>
>> Example:
>>
>> @@ -19,4 +20,5 @@ Example:
>> reg = <0x1c000 0x1000>;
>> interrupts = <48 0x2>;
>> interrupt-parent = <&mpic>;
>> + clock-frequency = <0x0bebc1fc>;
>
> Does the device tree support dec coded integers? IMHO a frequency is
> best expressed in decimal.
Yes it does, and agree that in the example a dec # might be better
- k
^ permalink raw reply
* RE: [PATCH] Fix RCU warning in rt_cache_seq_show
From: Eric Dumazet @ 2011-08-11 16:58 UTC (permalink / raw)
To: Mark Rutland, Paul E. McKenney; +Cc: netdev, David S. Miller, Gergely Kalman
In-Reply-To: <4e424f6c.12cde30a.131e.ffffec9bSMTPIN_ADDED@mx.google.com>
Le mercredi 10 août 2011 à 10:28 +0100, Mark Rutland a écrit :
> > -----Original Message-----
> > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > Sent: 09 August 2011 18:19
> > To: Mark Rutland; Paul E. McKenney
> > Cc: netdev@vger.kernel.org; David S. Miller; Gergely Kalman
> > Subject: Re: [PATCH] Fix RCU warning in rt_cache_seq_show
> >
> > Le mardi 09 août 2011 à 18:02 +0100, Mark Rutland a écrit :
> > > Commit f2c31e32 ("net: fix NULL dereferences in check_peer_redir()")
> > > added rcu protection to dst neighbour, and updated callsites for
> > > dst_{get,set}_neighbour. Unfortunately, it missed rt_cache_seq_show.
> > >
> > > This produces a warning on v3.1-rc1 (on a preemptible kernel, on an
> > > ARM Vexpress A9x4):
> > >
> > > ===================================================
> > > [ INFO: suspicious rcu_dereference_check() usage. ]
> > > ---------------------------------------------------
> > > include/net/dst.h:91 invoked rcu_dereference_check() without
> > protection!
> > >
> > > other info that might help us debug this:
> > >
> > > rcu_scheduler_active = 1, debug_locks = 0
> > > 2 locks held by proc01/32159:
> > >
> > > stack backtrace:
> > > [<80014880>] (unwind_backtrace+0x0/0xf8) from [<802e5c78>]
> > (rt_cache_seq_show+0x18c/0x1c4)
> > > [<802e5c78>] (rt_cache_seq_show+0x18c/0x1c4) from [<800e0c5c>]
> > (seq_read+0x324/0x4a4)
> > > [<800e0c5c>] (seq_read+0x324/0x4a4) from [<8010786c>]
> > (proc_reg_read+0x70/0x94)
> > > [<8010786c>] (proc_reg_read+0x70/0x94) from [<800c0ba8>]
> > (vfs_read+0xb0/0x144)
> > > [<800c0ba8>] (vfs_read+0xb0/0x144) from [<800c0ea8>]
> > (sys_read+0x40/0x70)
> > > [<800c0ea8>] (sys_read+0x40/0x70) from [<8000e0c0>]
> > (ret_fast_syscall+0x0/0x3c)
> > >
> > > This patch adds calls to rcu_read_{lock,unlock} in rt_cache_seq_show,
> > > protecting the dereferenced variable, and clearing the warning.
> > >
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > Cc: David S. Miller <davem@davemloft.net>
> > > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > > Cc: Gergely Kalman <synapse@hippy.csoma.elte.hu>
> > > ---
> > > net/ipv4/route.c | 2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > > index e3dec1c..6699ef7 100644
> > > --- a/net/ipv4/route.c
> > > +++ b/net/ipv4/route.c
> > > @@ -419,6 +419,7 @@ static int rt_cache_seq_show(struct seq_file
> > *seq, void *v)
> > > struct neighbour *n;
> > > int len;
> > >
> > > + rcu_read_lock();
> > > n = dst_get_neighbour(&r->dst);
> > > seq_printf(seq, "%s\t%08X\t%08X\t%8X\t%d\t%u\t%d\t"
> > > "%08X\t%d\t%u\t%u\t%02X\t%d\t%1d\t%08X%n",
> > > @@ -435,6 +436,7 @@ static int rt_cache_seq_show(struct seq_file
> > *seq, void *v)
> > > -1,
> > > (n && (n->nud_state & NUD_CONNECTED)) ? 1 : 0,
> > > r->rt_spec_dst, &len);
> > > + rcu_read_unlock();
> > >
> > > seq_printf(seq, "%*s\n", 127 - len, "");
> > > }
> >
> >
> > Hmm, I though rcu_read_lock_bh() (done by caller of this function) was
> > protecting us here.
>
> Aha. Being a bit trigger-happy, I'd had a quick look at the functions
> mentioned in the backtrace, and not looked at any possible inlining.
>
> This being my first real exposure to RCU, I wasn't aware of the *_bh
> variants. Looking at the documentation (Documentation/RCU/checklist.txt),
> I think the real problem is that we should be using rcu_dereference_bh in
> this case:
>
> > read-side critical sections are delimited by rcu_read_lock()
> > and rcu_read_unlock(), or by similar primitives such as
> > rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case
> > the matching rcu_dereference() primitive must be used in order
> > to keep lockdep happy, in this case, rcu_dereference_bh().
Hmm.
I do think dst_get_neighbour() should use rcu_dereference(), because
dst->_neighbour are freed by call_rcu().
The question is : Is following construct [A] safe or not ?
{
rcu_read_lock_bh();
/* BH are now disabled, and we are not allowed to sleep */
...
ptr = rcu_dereference();
...
rcu_read_unlock_bh();
}
I dont really understand why lockdep wants [B] instead :
{
rcu_read_lock_bh();
...
{
rcu_read_lock();
ptr = rcu_dereference();
rcu_read_unlock();
}
...
rcu_read_unlock_bh();
}
However, I can understand the other way [C], this is really needed :
{
rcu_read_lock();
...
{
rcu_read_lock_bh();
ptr = rcu_dereference_bh();
rcu_read_unlock_bh();
}
...
rcu_read_unlock();
}
I believe [A] should be allowed by lockdep.
^ permalink raw reply
* Re: [PATCH v11 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Grant Likely @ 2011-08-11 16:53 UTC (permalink / raw)
To: Robin Holt
Cc: Kumar Gala, Wolfgang Grandegger, Marc Kleine-Budde,
U Bhaskar-B22300, Scott Wood, socketcan-core, netdev, PPC list,
devicetree-discuss
In-Reply-To: <1313078831-2511-4-git-send-email-holt@sgi.com>
On Thu, Aug 11, 2011 at 10:07 AM, Robin Holt <holt@sgi.com> wrote:
> This patch cleans up the documentation of the device-tree binding for
> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> properties are not used by the driver so we are removing them.
>
> Signed-off-by: Robin Holt <holt@sgi.com>
> To: Marc Kleine-Budde <mkl@pengutronix.de>,
> To: Wolfgang Grandegger <wg@grandegger.com>,
> To: U Bhaskar-B22300 <B22300@freescale.com>
> To: Scott Wood <scottwood@freescale.com>
> To: Grant Likely <grant.likely@secretlab.ca>
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: socketcan-core@lists.berlios.de,
> Cc: netdev@vger.kernel.org,
> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
> Cc: devicetree-discuss@lists.ozlabs.org
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 69 ++++---------------
> arch/powerpc/boot/dts/p1010rdb.dts | 10 +--
> arch/powerpc/boot/dts/p1010si.dtsi | 10 +--
> 3 files changed, 21 insertions(+), 68 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> index 1a729f0..c78dcbb 100644
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> @@ -1,61 +1,22 @@
> -CAN Device Tree Bindings
> -------------------------
> -2011 Freescale Semiconductor, Inc.
> +Flexcan CAN contoller on Freescale's ARM and PowerPC processors
>
> -fsl,flexcan-v1.0 nodes
> ------------------------
> -In addition to the required compatible-, reg- and interrupt-properties, you can
> -also specify which clock source shall be used for the controller.
> +Required properties:
>
> -CPI Clock- Can Protocol Interface Clock
> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> - The PRESDIV field of CTRL(control register) controls a prescaler that
> - generates the Serial Clock (Sclock), whose period defines the
> - time quantum used to compose the CAN waveform.
> +- compatible : Should be "fsl,<processor>-flexcan" and "fsl,flexcan"
Don't do this. "fsl,flexcan" is far too generic. Be specific to the
soc part number or the ip core implementation version.
>
> -Can Engine Clock Source
> - There are two sources for CAN clock
> - - Platform Clock It represents the bus clock
> - - Oscillator Clock
> + An implementation should also claim any of the following compatibles
> + that it is fully backwards compatible with:
>
> - Peripheral Clock (PLL)
> - --------------
> - |
> - --------- -------------
> - | |CPI Clock | Prescaler | Sclock
> - | |---------------->| (1.. 256) |------------>
> - --------- -------------
> - | |
> - -------------- ---------------------CLK_SRC
> - Oscillator Clock
> + - fsl,p1010-flexcan
>
> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> - the peripheral clock. PLL clock is fed to the
> - prescaler to generate the Serial Clock (Sclock).
> - Valid values are "oscillator" and "platform"
> - "oscillator": CAN engine clock source is oscillator clock.
> - "platform" The CAN engine clock source is the bus clock
> - (platform clock).
> +- reg : Offset and length of the register set for this device
> +- interrupts : Interrupt tuple for this device
>
> -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> - clock divider can be specified.
> -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> +Example:
>
> -Note:
> - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> - - P1010 does not have oscillator as the Clock Source.So the default
> - Clock Source is platform clock.
> -Examples:
> -
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> - reg = <0x1c000 0x1000>;
> - interrupts = <48 0x2>;
> - interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-source = "platform";
> - fsl,flexcan-clock-divider = <2>;
> - clock-frequency = <fixed by u-boot>;
> - };
> + can@1c000 {
> + compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> + reg = <0x1c000 0x1000>;
> + interrupts = <48 0x2>;
> + interrupt-parent = <&mpic>;
> + };
The diffstat for this patch looks too big because the whitespace has
changed. Try to restrict whitespace changes so that the patch is
friendly to reviewers.
g.
^ permalink raw reply
* Re: [PATCH v11 6/6] powerpc: Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-11 16:48 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
Grant Likely, Marc Kleine-Budde, Scott Wood, PPC list
In-Reply-To: <4E4404BC.7060502-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Thu, Aug 11, 2011 at 06:35:08PM +0200, Wolfgang Grandegger wrote:
> On 08/11/2011 06:07 PM, Robin Holt wrote:
> > Allow the p1010 processor to select the flexcan network driver.
> >
> > Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> > Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> > Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> > Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> > Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> > Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> > Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> > ---
> > arch/powerpc/boot/dts/p1010rdb.dts | 8 ++++++++
> > arch/powerpc/platforms/85xx/Kconfig | 2 ++
> > 2 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> > index d6c669c..df89b60 100644
> > --- a/arch/powerpc/boot/dts/p1010rdb.dts
> > +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> > @@ -171,6 +171,14 @@
> > };
> > };
> >
> > + can@1c000 {
> > + clock-frequency = <0x0bebc1fc>;
> > + };
>
>
> clock-frequency = <200000000>; // filled in by boot-loader
>
> Is better readable and makes clear that the value is filled in by the
> boot loader. Usually we specify "<0>" in that case but it will *not*
> work with your board because U-Boot fills into the property "clock_freq"
> the CCB-frequency, which is twice as much. This needs to be fixed.
I guess the question then is, should I not add the clock-frequency to
this file and let this fall back upon the boot-loader? Until the boot
loader is up-to-speed, my test .dts file will need to define it.
Thanks,
Robin
>
> > + can1: can@1d000 {
>
> What is the "can1:" good for?
>
> > + clock-frequency = <0x0bebc1fc>;
>
> See above.
>
> Wolfgang.
>
>
>
>
> > usb@22000 {
> > phy_type = "utmi";
> > };
> > diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> > index 498534c..c4304ae 100644
> > --- a/arch/powerpc/platforms/85xx/Kconfig
> > +++ b/arch/powerpc/platforms/85xx/Kconfig
> > @@ -70,6 +70,8 @@ config MPC85xx_RDB
> > config P1010_RDB
> > bool "Freescale P1010RDB"
> > select DEFAULT_UIMAGE
> > + select HAVE_CAN_FLEXCAN if NET && CAN
> > + select PPC_CLOCK if CAN_FLEXCAN
> > help
> > This option enables support for the MPC85xx RDB (P1010 RDB) board
> >
^ permalink raw reply
* Re: [PATCH v11 5/6] flexcan: Prefer device tree clock frequency if available.
From: Wolfgang Grandegger @ 2011-08-11 16:35 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, Grant Likely, Marc Kleine-Budde, Scott Wood, PPC list
In-Reply-To: <1313078831-2511-6-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
On 08/11/2011 06:07 PM, Robin Holt wrote:
> If our CAN device's device tree node has a clock-frequency property,
> then use that value for the can devices clock frequency. If not, fall
> back to asking the platform/mach code for the clock frequency associated
> with the flexcan device.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 2 +
> drivers/net/can/flexcan.c | 33 +++++++++++++++-----
> 2 files changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> index c78dcbb..a4382c7 100644
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> @@ -11,6 +11,7 @@ Required properties:
>
> - reg : Offset and length of the register set for this device
> - interrupts : Interrupt tuple for this device
> +- clock-frequency : The oscillator frequency driving the flexcan device
>
> Example:
>
> @@ -19,4 +20,5 @@ Example:
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> + clock-frequency = <0x0bebc1fc>;
clock-frequency = <200000000>; // filled in by bootloader
Is better readable. You should also add the comment.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v11 6/6] powerpc: Add flexcan device support for p1010rdb.
From: Wolfgang Grandegger @ 2011-08-11 16:35 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
Grant Likely, Marc Kleine-Budde, Scott Wood, PPC list
In-Reply-To: <1313078831-2511-7-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
On 08/11/2011 06:07 PM, Robin Holt wrote:
> Allow the p1010 processor to select the flexcan network driver.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
> arch/powerpc/boot/dts/p1010rdb.dts | 8 ++++++++
> arch/powerpc/platforms/85xx/Kconfig | 2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> index d6c669c..df89b60 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -171,6 +171,14 @@
> };
> };
>
> + can@1c000 {
> + clock-frequency = <0x0bebc1fc>;
> + };
clock-frequency = <200000000>; // filled in by boot-loader
Is better readable and makes clear that the value is filled in by the
boot loader. Usually we specify "<0>" in that case but it will *not*
work with your board because U-Boot fills into the property "clock_freq"
the CCB-frequency, which is twice as much. This needs to be fixed.
> + can1: can@1d000 {
What is the "can1:" good for?
> + clock-frequency = <0x0bebc1fc>;
See above.
Wolfgang.
> usb@22000 {
> phy_type = "utmi";
> };
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..c4304ae 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -70,6 +70,8 @@ config MPC85xx_RDB
> config P1010_RDB
> bool "Freescale P1010RDB"
> select DEFAULT_UIMAGE
> + select HAVE_CAN_FLEXCAN if NET && CAN
> + select PPC_CLOCK if CAN_FLEXCAN
> help
> This option enables support for the MPC85xx RDB (P1010 RDB) board
>
^ permalink raw reply
* rt_iif conversions (was Re: return of ip_rt_bug())
From: Julian Anastasov @ 2011-08-11 16:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Thomas Graf
In-Reply-To: <20110811.060057.36747750681761864.davem@davemloft.net>
Hello,
On Thu, 11 Aug 2011, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Tue, 9 Aug 2011 16:51:26 +0300 (EEST)
>
> > There are other places that used fl.iif (0 for output
> > routes) but are now using rt_iif instead of rt_route_iif,
> > not sure if this change is fatal for them because:
> >
> > - net/sched/cls_route.c, route4_classify() gets optional
> > iif, so it can be 0, may be to match output route? And
> > later route4_classify does exact match for rt_iif. Does
> > it mean that now we can not match output packets without
> > providing "fromif OUTDEV" ?
It seems the user space for route filter treats
0 as error, so "fromif if0" was never supported. So, using
rt_iif is a better choice here.
> > - net/sched/em_meta.c: now int_rtiif (being rt_iif) is
> > always != 0, may be not good to match output routes?
May be using 'rt_iif eq 0' is silly for the meta match.
It is preferred to use rt_iif instead of rt_route_iif so that
one can match even packets from loopback.
> > In short, the fl.iif -> rt_iif conversion is risky
> > at some places.
>
> If we convert em_meta.c and cls_route.c to use rt_route_iif
> we should be OK right? Please patches to do this if so.
It seems no patches are needed. Sorry for the confusion.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ 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