* Re: [PATCH] vlan: set sysfs device_type to 'vlan'
From: Ben Hutchings @ 2012-10-23 22:52 UTC (permalink / raw)
To: Ben Greear
Cc: David Miller, cardoe, kaber, netdev, systemd-devel, linux-kernel
In-Reply-To: <5086C256.20202@candelatech.com>
On Tue, 2012-10-23 at 09:14 -0700, Ben Greear wrote:
> On 10/22/2012 11:36 PM, David Miller wrote:
> > From: Doug Goldstein <cardoe@cardoe.com>
> > Date: Mon, 22 Oct 2012 00:53:57 -0500
> >
> >> Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
> >> applications that query network information via udev to identify vlans
> >> instead of using strrchr().
> >>
> >> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
> >
> > You're extremely misguided. This change, in fact, makes it ten times
> > harder for such applications to query such devices.
>
> If the application doesn't care, it can use the old way (which at least
> for me, involves string-comparing the driver name ethtool returns, which
> sucks at best).
The 'old way' that has only worked since Linux 2.6.29 (3.5 years)?
The 'right way' seems to be to query for VLAN information through
netlink. But that has only worked since Linux 2.6.23 (5 years ago).
The real 'old way' is to use SIOCGIFVLAN. :-/
> And applications that care might suddenly have more features, or be more
> efficient when running on newer kernels..
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] vlan: set sysfs device_type to 'vlan'
From: Ben Greear @ 2012-10-23 23:03 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, cardoe, kaber, netdev, systemd-devel, linux-kernel
In-Reply-To: <1351032742.5283.69.camel@deadeye.wl.decadent.org.uk>
On 10/23/2012 03:52 PM, Ben Hutchings wrote:
> On Tue, 2012-10-23 at 09:14 -0700, Ben Greear wrote:
>> On 10/22/2012 11:36 PM, David Miller wrote:
>>> From: Doug Goldstein <cardoe@cardoe.com>
>>> Date: Mon, 22 Oct 2012 00:53:57 -0500
>>>
>>>> Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
>>>> applications that query network information via udev to identify vlans
>>>> instead of using strrchr().
>>>>
>>>> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
>>>
>>> You're extremely misguided. This change, in fact, makes it ten times
>>> harder for such applications to query such devices.
>>
>> If the application doesn't care, it can use the old way (which at least
>> for me, involves string-comparing the driver name ethtool returns, which
>> sucks at best).
>
> The 'old way' that has only worked since Linux 2.6.29 (3.5 years)?
>
> The 'right way' seems to be to query for VLAN information through
> netlink. But that has only worked since Linux 2.6.23 (5 years ago).
> The real 'old way' is to use SIOCGIFVLAN. :-/
Oh, I have the SIOCGIFVLAN fallback in place too.
But none of this is easy from a shell script, where reading a sysfs
file is quite easy.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-next 1/2] packet: clean up error variable assignments
From: Ben Hutchings @ 2012-10-23 23:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Daniel Borkmann, davem, netdev
In-Reply-To: <1351011952.8609.2334.camel@edumazet-glaptop>
On Tue, 2012-10-23 at 19:05 +0200, Eric Dumazet wrote:
> On Tue, 2012-10-23 at 13:56 +0200, Daniel Borkmann wrote:
> > This patch performs clean-ups of packet's err variables where appropriate.
> > In particular, errnos are *only* assigned in error cases, which saves
> > useless instructions in non-error cases and makes the code more readable
> > in terms of which error type belongs to which evaluated error condition.
> > Also, in some cases an errno was set, but not used until the next assignment.
>
> I see no value in this patch.
>
> Setting err before a test is a common way to handle error cases and
> generates smaller code in linux kernel.
>
> Better live with it than trying to change it ?
>
> err = -ENOMEM;
> match = kzalloc(xxxx);
> if (!match)
> goto error;
>
>
> is smaller (source code & generated code) than :
>
> match = kzalloc(xxxx);
> if (!match) {
> err = -ENOMEM;
> goto error;
> }
>
> An immediate load is basically free, but code size matters.
In my experience gcc is generally able to perform this optimisation
itself, at least for x86. Setting 'err' only after checking for failure
seems clearer, but I think this is really a matter of taste.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Incorrect ARP behavior when multiple/none IPv4 address assigned to interface
From: Julian Anastasov @ 2012-10-24 0:15 UTC (permalink / raw)
To: Sergey Popovich; +Cc: netdev
In-Reply-To: <50867F51.3030500@mail.ru>
Hello,
On Tue, 23 Oct 2012, Sergey Popovich wrote:
> Hello!
>
> We have following setup:
> ------------------------
>
> PC1 | |
> ip: 10.0.1.2/24 | | Linux Router (3.7-rc2)
> gw: 10.0.1.1 |--------eth0-| Lo0: 10.10.10.10/32
> | Lo255: 10.0.1.1/24
> PC2 |--------eth1-| 10.0.2.1/24
> ip: 10.0.1.3/24 | | eth[0-2]: no ip address
> gw: 10.0.1.1 | | ip route 10.0.1.2/32 dev eth0 src 10.0.1.1
> +-| ip route 10.0.1.3/32 dev eth1 src 10.0.1.1
> | | ip route 10.0.2.2/32 dev eth2 src 10.0.2.1
> PC3 |-----eth2--+
> ip: 10.0.2.2/24 |
> gw: 10.0.2.1 |
>
>
> Problem with ARP Requests sent with incorrect source address (10.10.10.10
> instead of 10.0.1.1):
>
> # tcpdump -vv -ieth0 -s1500 -nnpe 'arp'
> 13:28:57.395181 08:00:27:3b:63:ae > 0a:00:27:00:00:00, ethertype ARP (0x0806),
> length 42: Ethernet (len 6),.
> IPv4 (len 4), Request who-has 10.0.1.2 tell 10.10.10.10, length 28
What kind of packet triggers ARP request here?
May be this IP packet already has saddr=10.10.10.10 ?
arp_solicit() when eth0/arp_announce=0 (default) just
ensures that this saddr is local. Or it is a forwarding
case and inet_select_addr is used? Also, any reason to put
addresses on loopback and not on eth0?
> 13:28:58.395257 08:00:27:3b:63:ae > 0a:00:27:00:00:00, ethertype ARP (0x0806),
> length 42: Ethernet (len 6),.
> IPv4 (len 4), Request who-has 10.0.1.2 tell 10.10.10.10, length 28
> 13:28:59.395207 08:00:27:3b:63:ae > 0a:00:27:00:00:00, ethertype ARP (0x0806),
> length 42: Ethernet (len 6),.
> IPv4 (len 4), Request who-has 10.0.1.2 tell 10.10.10.10, length 28
> 13:29:01.393739 08:00:27:3b:63:ae > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806),
> length 42: Ethernet (len 6),.
> IPv4 (len 4), Request who-has 10.0.1.2 tell 10.0.1.1, length 28
> 13:29:01.393862 0a:00:27:00:00:00 > 08:00:27:3b:63:ae, ethertype ARP (0x0806),
> length 60: Ethernet (len 6),.
> IPv4 (len 4), Reply 10.0.1.2 is-at 0a:00:27:00:00:00, length 46
>
> Detailed information about this (and other, that triggers same case with ARP)
> network topology usage in real world
> can be found at https://bugzilla.kernel.org/show_bug.cgi?id=49311
Your case 2 can be also solved with proper ordering of
the primaries, eg. first add /32 primaries, then /31, ... /25, /24.
You can also use decreasing scope for the addresses if global
scope is not needed for them, it can help for the ordering.
For the proposed patch: providing iph->saddr to
inet_select_addr() in icmp_send() looks better than before.
Still, inet_select_addr() is incorrect function to use
from icmp_send(), there is the risk to expose scope link
addresses.
The other part from patch in inet_select_addr() looks
correct to me but comes with some price for the arp_solicit()
and icmp_send() cases, a slowdown that may not be liked by
others.
About fib_info_update_nh_saddr: same fib_info can
be used for different subnets, so we can not check the
destination. But routes to directly connected hosts
usually come with prefsrc (proto kernel), so it is not a
problem.
> Sorry for early bug report.
>
> --
> SP5474-RIPE
> Sergey Popovich
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [3.2.y] e1000: fix vlan processing regression
From: Jonathan Nieder @ 2012-10-24 1:21 UTC (permalink / raw)
To: David Miller
Cc: Jeff Kirsher, Jiri Pirko, netdev, Andy Gospodarek, sassmann,
Andrey Jr. Melnikov, stable
In-Reply-To: <1332917548-13102-2-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Tue, 20 Mar 2012 18:10:01 +0000
commit 52f5509fe8ccb607ff9b84ad618f244262336475 upstream.
This patch fixes a regression introduced by commit "e1000: do vlan
cleanup (799d531)".
Apparently some e1000 chips (not mine) are sensitive about the order of
setting vlan filter and vlan stripping/inserting functionality. So this
patch changes the order so it's the same as before vlan cleanup.
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Tested-by: Andrey Jr. Melnikov <temnota@kmv.ru>
---
Hi Dave,
Would
52f5509fe8cc e1000: fix vlan processing regression, 2012-03-20
be ok for 3.2.y?
It doesn't apply cleanly to kernels before v3.3-rc1~182^2~581 (net:
introduce and use netdev_features_t for device features sets) but a
backport is straightforward. The patch is already in 3.3.y as
v3.3.6~52 (2012-05-12). 3.0.y doesn't need this because it doesn't
have 799d531.
Andrey (cc-ed) tested[1] this patch against a 3.2.23-based kernel and
found it to work ok.
Thoughts of all kinds welcome, as always.
Thanks,
Jonathan
[1] http://bugs.debian.org/690956
drivers/net/ethernet/intel/e1000/e1000_main.c | 76 +++++++++++++++------------
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index c5f6b0e60c39..6546191a5951 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -168,6 +168,8 @@ static int e1000_82547_fifo_workaround(struct e1000_adapter *adapter,
static bool e1000_vlan_used(struct e1000_adapter *adapter);
static void e1000_vlan_mode(struct net_device *netdev, u32 features);
+static void e1000_vlan_filter_on_off(struct e1000_adapter *adapter,
+ bool filter_on);
static void e1000_vlan_rx_add_vid(struct net_device *netdev, u16 vid);
static void e1000_vlan_rx_kill_vid(struct net_device *netdev, u16 vid);
static void e1000_restore_vlan(struct e1000_adapter *adapter);
@@ -1219,7 +1221,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
if (err)
goto err_register;
- e1000_vlan_mode(netdev, netdev->features);
+ e1000_vlan_filter_on_off(adapter, false);
/* print bus type/speed/width info */
e_info(probe, "(PCI%s:%dMHz:%d-bit) %pM\n",
@@ -4553,43 +4555,11 @@ static bool e1000_vlan_used(struct e1000_adapter *adapter)
return false;
}
-static void e1000_vlan_filter_on_off(struct e1000_adapter *adapter,
- bool filter_on)
+static void __e1000_vlan_mode(struct e1000_adapter *adapter, u32 features)
{
struct e1000_hw *hw = &adapter->hw;
- u32 rctl;
-
- if (!test_bit(__E1000_DOWN, &adapter->flags))
- e1000_irq_disable(adapter);
-
- if (filter_on) {
- /* enable VLAN receive filtering */
- rctl = er32(RCTL);
- rctl &= ~E1000_RCTL_CFIEN;
- if (!(adapter->netdev->flags & IFF_PROMISC))
- rctl |= E1000_RCTL_VFE;
- ew32(RCTL, rctl);
- e1000_update_mng_vlan(adapter);
- } else {
- /* disable VLAN receive filtering */
- rctl = er32(RCTL);
- rctl &= ~E1000_RCTL_VFE;
- ew32(RCTL, rctl);
- }
-
- if (!test_bit(__E1000_DOWN, &adapter->flags))
- e1000_irq_enable(adapter);
-}
-
-static void e1000_vlan_mode(struct net_device *netdev, u32 features)
-{
- struct e1000_adapter *adapter = netdev_priv(netdev);
- struct e1000_hw *hw = &adapter->hw;
u32 ctrl;
- if (!test_bit(__E1000_DOWN, &adapter->flags))
- e1000_irq_disable(adapter);
-
ctrl = er32(CTRL);
if (features & NETIF_F_HW_VLAN_RX) {
/* enable VLAN tag insert/strip */
@@ -4599,6 +4569,44 @@ static void e1000_vlan_mode(struct net_device *netdev, u32 features)
ctrl &= ~E1000_CTRL_VME;
}
ew32(CTRL, ctrl);
+}
+static void e1000_vlan_filter_on_off(struct e1000_adapter *adapter,
+ bool filter_on)
+{
+ struct e1000_hw *hw = &adapter->hw;
+ u32 rctl;
+
+ if (!test_bit(__E1000_DOWN, &adapter->flags))
+ e1000_irq_disable(adapter);
+
+ __e1000_vlan_mode(adapter, adapter->netdev->features);
+ if (filter_on) {
+ /* enable VLAN receive filtering */
+ rctl = er32(RCTL);
+ rctl &= ~E1000_RCTL_CFIEN;
+ if (!(adapter->netdev->flags & IFF_PROMISC))
+ rctl |= E1000_RCTL_VFE;
+ ew32(RCTL, rctl);
+ e1000_update_mng_vlan(adapter);
+ } else {
+ /* disable VLAN receive filtering */
+ rctl = er32(RCTL);
+ rctl &= ~E1000_RCTL_VFE;
+ ew32(RCTL, rctl);
+ }
+
+ if (!test_bit(__E1000_DOWN, &adapter->flags))
+ e1000_irq_enable(adapter);
+}
+
+static void e1000_vlan_mode(struct net_device *netdev, u32 features)
+{
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+
+ if (!test_bit(__E1000_DOWN, &adapter->flags))
+ e1000_irq_disable(adapter);
+
+ __e1000_vlan_mode(adapter, features);
if (!test_bit(__E1000_DOWN, &adapter->flags))
e1000_irq_enable(adapter);
--
1.8.0.rc2
^ permalink raw reply related
* Re: Synchronization between process context and softirq context on SMP machine
From: Feng King @ 2012-10-24 2:47 UTC (permalink / raw)
To: Cong Xu; +Cc: netdev
In-Reply-To: <loom.20121023T223837-223@post.gmane.org>
2012/10/24 Cong Xu <davidxu06@gmail.com>
>
> I met some problems when I did some research in improving the TCP/UDP
> performance of Virtual Machine(VM), if anybody can offer me some help or
> suggestion to handle my problem, I will be very appreciated.
>
>
> On virtual machine platform, virtual CPU (vCPU) of each VM can not be always
> online when several vCPUs share one physical CPU (pCPU) (Here we can simply
> assume the vCPU scheduling is round-robin.). Therefore, the high delay of TCP
> receiving of VM hurts the TCP throughput significantly. In order to handle this
> problem I assign a virtual co-processor (co-vCPU) which is almost always online
> to each VM and pin NIC IRQ of the VM to this co-vCPU. ( If you are not familiar
> with VM, you can simply assume that in a common OS the user level application
> (e.g. iperf) runs on a cpu which will be offline every 30ms, and the bottom half
> or softirq context runs on another cpu which is always online. )
>
> In my experiment, this method works well for UDP but does not work for TCP. I
> doubt that it is due to the synchronization between process context and softirq
> context. Because when I read some source code of TCP layer in linux, I found
> that both softirq context (e.g. tcp_v4_rcv() in net/ipv4/tcp_ipv4.c) and process
> context (e.g. tcp_recvmsg() in net/ipv4/tcp.c) call lock_sock()/unlock_sock()
> when they access the buffers in kernel(receive_queue, backlog_queue or p
> requeue). Therefore, sometimes softirq context can not access the receiving
> buffers locked by another vCPU which runs the user level receiving process
> (iperf server) and this vCPU holding the spinlock has been descheduled by VM
> monitor(VMM) or hypervisor.
if socket is held by process(sock_owned_by_user), softirq will just
add skb to socket's backlog
and then return. when process called release_sock, skbs in backlog
will be handled in process context,
to finish their tcp handling.
so if softirq enqueues skb more quickly than process consume speed,
the skbs held in sock recvqueue, prequeue
and backlog will grow, if sum of skb truesize beyond per socket
receive buffer limit, skb will be dropped. through
'ss -oemi' you can see per socket receive buffer consumed,
>
>
>
> I am not sure I described my problem clearly. Anyway, welcome any suggestion on
> it.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
king
^ permalink raw reply
* Re: Re: [Pv-drivers] 3.7-rc2 regression : file copied to CIFS-mounted directory corrupted
From: Jongman Heo @ 2012-10-24 2:53 UTC (permalink / raw)
To: Eric Dumazet, Shreyas Bhatewara
Cc: VMware, Inc., netdev@vger.kernel.org, edumazet@google.com,
linux-kernel@vger.kernel.org, 허종만
Hi,
------- Original Message -------
Sender : Eric Dumazet
Date : 2012-10-24 04:39 (GMT+09:00)
Title : Re: [Pv-drivers] 3.7-rc2 regression : file copied to CIFS-mounted directory corrupted
On Tue, 2012-10-23 at 15:50 +0200, Eric Dumazet wrote:
> Only the skb head is handled in the code you copy/pasted.
>
> You need to generalize that to code in lines ~754
>
>
> Then, the number of estimated descriptors is bad :
>
> /* conservatively estimate # of descriptors to use */
> count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) +
> skb_shinfo(skb)->nr_frags + 1;
>
>
> Yes, you need a more precise estimation and vmxnet3_map_pkt() should
> eventually split too big frags.
raw patch would be :
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index ce9d4f2..0ae1bcc 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -744,28 +744,43 @@ vmxnet3_map_pkt(struct sk_buff *skb, struct vmxnet3_tx_ctx *ctx,
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
const struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i];
+ u32 buf_size;
- tbi = tq->buf_info + tq->tx_ring.next2fill;
- tbi->map_type = VMXNET3_MAP_PAGE;
- tbi->dma_addr = skb_frag_dma_map(&adapter->pdev->dev, frag,
- 0, skb_frag_size(frag),
- DMA_TO_DEVICE);
+ buf_offset = 0;
+ len = skb_frag_size(frag);
+ while (len) {
+ tbi = tq->buf_info + tq->tx_ring.next2fill;
+ if (len < VMXNET3_MAX_TX_BUF_SIZE) {
+ buf_size = len;
+ dw2 |= len;
+ } else {
+ buf_size = VMXNET3_MAX_TX_BUF_SIZE;
+ /* spec says that for TxDesc.len, 0 == 2^14 */
+ }
+ tbi->map_type = VMXNET3_MAP_PAGE;
+ tbi->dma_addr = skb_frag_dma_map(&adapter->pdev->dev, frag,
+ buf_offset, buf_size,
+ DMA_TO_DEVICE);
- tbi->len = skb_frag_size(frag);
+ tbi->len = buf_size;
- gdesc = tq->tx_ring.base + tq->tx_ring.next2fill;
- BUG_ON(gdesc->txd.gen == tq->tx_ring.gen);
+ gdesc = tq->tx_ring.base + tq->tx_ring.next2fill;
+ BUG_ON(gdesc->txd.gen == tq->tx_ring.gen);
- gdesc->txd.addr = cpu_to_le64(tbi->dma_addr);
- gdesc->dword[2] = cpu_to_le32(dw2 | skb_frag_size(frag));
- gdesc->dword[3] = 0;
+ gdesc->txd.addr = cpu_to_le64(tbi->dma_addr);
+ gdesc->dword[2] = cpu_to_le32(dw2);
+ gdesc->dword[3] = 0;
- dev_dbg(&adapter->netdev->dev,
- "txd[%u]: 0x%llu %u %u\n",
- tq->tx_ring.next2fill, le64_to_cpu(gdesc->txd.addr),
- le32_to_cpu(gdesc->dword[2]), gdesc->dword[3]);
- vmxnet3_cmd_ring_adv_next2fill(&tq->tx_ring);
- dw2 = tq->tx_ring.gen << VMXNET3_TXD_GEN_SHIFT;
+ dev_dbg(&adapter->netdev->dev,
+ "txd[%u]: 0x%llu %u %u\n",
+ tq->tx_ring.next2fill, le64_to_cpu(gdesc->txd.addr),
+ le32_to_cpu(gdesc->dword[2]), gdesc->dword[3]);
+ vmxnet3_cmd_ring_adv_next2fill(&tq->tx_ring);
+ dw2 = tq->tx_ring.gen << VMXNET3_TXD_GEN_SHIFT;
+
+ len -= buf_size;
+ buf_offset += buf_size;
+ }
}
ctx->eop_txd = gdesc;
@@ -886,6 +901,18 @@ vmxnet3_prepare_tso(struct sk_buff *skb,
}
}
+static int txd_estimate(const struct sk_buff *skb)
+{
+ int count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) + 1;
+ int i;
+
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ const struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i];
+
+ count += VMXNET3_TXD_NEEDED(skb_frag_size(frag));
+ }
+ return count;
+}
/*
* Transmits a pkt thru a given tq
@@ -914,9 +941,7 @@ vmxnet3_tq_xmit(struct sk_buff *skb, struct vmxnet3_tx_queue *tq,
union Vmxnet3_GenericDesc tempTxDesc;
#endif
- /* conservatively estimate # of descriptors to use */
- count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) +
- skb_shinfo(skb)->nr_frags + 1;
+ count = txd_estimate(skb);
ctx.ipv4 = (vlan_get_protocol(skb) == cpu_to_be16(ETH_P_IP));
------- Original Message End -------
Hi, Eric,
your raw patch seemed to fix the issue. But after ~200 runs, copied file has been corrupted again.
# cmp -l /home/local.bin /mnt/cifs/new.bin | awk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}' > diff.log
I compared the difference between source and copied file. Size of file is 45872732 bytes (= 0x2BBF65C).
Among them, 4096 (0x1000) bytes are different, from 0x2B96001 to 0x2B97000. Instead of original data, 0x00 was copied in those area.
patch applied on top of 2d1f4c8e ("Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux").
Regards,
Jongman Heo.
^ permalink raw reply related
* Payment Sent!!
From: Western Union Transfer @ 2012-10-24 2:56 UTC (permalink / raw)
To: netdev
We write to inform you that we have transferred $400,000 dollars. deposited for transfer to you by one MR Bernard Harry from BLACKBERRY MOBILE COMPANY for transfer as a winning prize from the promotion lottery held by the communication company to encourage usage and appreciate already users of their product.
The money is available for pick up by receiver(you) to be cashed on daily installment of $10,000 for 40days. We tried calling to give you the information over the phone but we could not reach you so we decided to email you the information to pick up the first $10,000 already transferred to you. for you to be able to pick the first payment,
You will have to pay $250 to get it re-activated in your name for you to start picking up your money because we de-activate the transaction for security reason, by making the status to display pick up.
Use this link to track the below information
https://wumt.westernunion.com/asp/orderStatus.asp?country=global
Sender's Fist name: Perry
Sender's Last Name: Poston
MTCN: 9429519950
Question: Who Is Great
Answer: God
Amount: $10,000.00USD
Thanks
Best Regards
Mr.Mcferrin Phoenix .
+60169162934
western union Office,
MALAYSIA OFFICE.
Western Union® Money Transfer
^ permalink raw reply
* Re: [net-next 2/8] maintainers: update with official intel support link, new maintainer
From: Jeff Kirsher @ 2012-10-24 4:32 UTC (permalink / raw)
To: Joe Perches; +Cc: Tushar Dave, davem, Jesse Brandeburg, netdev, gospo, sassmann
In-Reply-To: <1350998701.7502.42.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]
On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:
> On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:
> > From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> >
> > Add an official link which is designed to guide the user to the appropriate
> > support resource (be it community, OEM, Intel phone, Intel email, etc)
> >
> > Add the current e1000 maintainer to the list of Intel maintainers.
>
> Hi Jeff.
>
> I think it's unwise to have 10 named maintainers for all
> the intel ethernet drivers if there are specialists
> maintainers.
>
> Maybe it'd be better to break out these sub-maintainers
> into specific driver sections with you as the overall
> maintainer.
>
> Maybe add an internal exploder to get all the various
> maintainers on a list if everyone really looks at all
> patches to intel drivers.
>
> Something like:
>
> INTEL ETHERNET DRIVERS
> M: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> M: Intel Linux Support <linux.drivers@intel.com>
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
> S: Supported
> F: drivers/net/ethernet/intel/
>
> INTEL ETHERNET E1000 DRIVER
> M: Tushar Dave <tushar.n.dave@intel.com>
> S: Supported
> F: drivers/net/ethernet/intel/e1000/
> F: Documentation/networking/e1000.txt
>
> etc...
I understand where your coming from and this has been been something
that I have been trying to find a "reasonable" solution, which is harder
to do than one would expect.
We do have developers like Bruce Allan who maintains e1000e and Carolyn
Wyborny who maintains igb and Don Skidmore (and others) who maintain
ixgbe. The problem we did not want to fall into by pigeon holing
developers in maintaining a driver. Developers like John, Jesse, Alex,
and Tushar work on all of our drivers. Jesse tends to focus on
performance related matters, where as Tushar responds to customer issues
on any driver and does the root cause and fix for the issues.
So how do we go about giving this spider web of complex coverage to some
clear concise coverage in the MAINTAINERS?
For now, the solution was to list all the developers actively working on
the kernel drivers since anyone of them can work on pretty much anyone
of our drivers.
If you have some ideas which may help resolve the issues, I am open to
suggestions.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [net-next 2/8] maintainers: update with official intel support link, new maintainer
From: Joe Perches @ 2012-10-24 4:52 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Tushar Dave, davem, Jesse Brandeburg, netdev, gospo, sassmann
In-Reply-To: <1351053166.2252.39.camel@jtkirshe-mobl>
On Tue, 2012-10-23 at 21:32 -0700, Jeff Kirsher wrote:
> On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:
> > On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:
> > > Add the current e1000 maintainer to the list of Intel maintainers.
> > Maybe add an internal exploder to get all the various
> > maintainers on a list if everyone really looks at all
> > patches to intel drivers.
> > INTEL ETHERNET DRIVERS
> > M: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > M: Intel Linux Support <linux.drivers@intel.com>
> > T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git
> > T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
> > S: Supported
> > F: drivers/net/ethernet/intel/
> I understand where your coming from and this has been been something
> that I have been trying to find a "reasonable" solution, which is harder
> to do than one would expect.
[]
> So how do we go about giving this spider web of complex coverage to some
> clear concise coverage in the MAINTAINERS?
[]
> If you have some ideas which may help resolve the issues, I am open to
> suggestions.
It's great that they all work on all intel drivers, but it seems
that you are the nominal maintainer and they are all developers
that might work on anything but nothing in particular.
I think an internal exploder email address would work well.
^ permalink raw reply
* Re: [PATCH] ipv6: fix the bug when propagating Redirect Message
From: Steffen Klassert @ 2012-10-24 4:54 UTC (permalink / raw)
To: Duan Jiong; +Cc: davem, netdev
In-Reply-To: <5086B721.1090905@gmail.com>
On Tue, Oct 23, 2012 at 11:26:25PM +0800, Duan Jiong wrote:
>
> Before using icmpv6_notify() to propagate redirect, change skb->data
> to poing the IP packet that triggered the sending of the Redirect.
>
> Signed-off-by: Duan Jiong <djduanjiong@gmail.com>
> ---
> net/ipv6/ndisc.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
> index ff36194..0f73303 100644
> --- a/net/ipv6/ndisc.c
> +++ b/net/ipv6/ndisc.c
> @@ -1334,6 +1334,11 @@ out:
>
> static void ndisc_redirect_rcv(struct sk_buff *skb)
> {
> + int opt_len;
> + int opt_offset;
> + int ndisc_head_len;
> + struct nd_opt_hdr *nd_opt;
> +
> #ifdef CONFIG_IPV6_NDISC_NODETYPE
> switch (skb->ndisc_nodetype) {
> case NDISC_NODETYPE_HOST:
> @@ -1350,6 +1355,40 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
> return;
> }
>
> + ndisc_head_len = sizeof(struct icmp6hdr) + 2*sizeof(struct in6_addr);
> + if (!pskb_may_pull(skb, ndisc_head_len)) {
> + return;
> + }
> +
> + nd_opt = (struct nd_opt_hdr *)(skb->data + ndisc_head_len);
> +
> + opt_len = skb->tail - skb->transport_header - ndisc_head_len;
> + if (opt_len < 0) {
> + return;
> + }
> + while (opt_len) {
> + int l;
> +
> + if (opt_len < sizeof(struct nd_opt_hdr)) {
> + return;
> + }
> + l = nd_opt->nd_opt_len << 3;
> + if (opt_len < l || l == 0) {
> + return;
> + }
> + if (nd_opt->nd_opt_type == ND_OPT_REDIRECT_HDR) {
> + __skb_pull(skb, ndisc_head_len + opt_offset + 8);
> + break;
> + }
> + opt_len -= l;
> + nd_opt = ((void *)nd_opt) + 1;
> + opt_offset += 1;
> + }
Instead of the above loop, you could use ndisc_parse_options().
This does the same what you are doing here and it would make it
a bit clearer what's going on.
^ permalink raw reply
* Re: [PATCH]ipv6: Add an ICMP error handler icmpv6_err
From: Steffen Klassert @ 2012-10-24 5:01 UTC (permalink / raw)
To: Duan Jiong; +Cc: davem, netdev
In-Reply-To: <5086B6AD.8060306@gmail.com>
On Tue, Oct 23, 2012 at 11:24:29PM +0800, Duan Jiong wrote:
>
> Add an ICMP error handler icmpv6_err to deal with ICMPV6 Error
> Messages and Redirect Message, when we do not have a socket
> context.
>
> Signed-off-by: Duan Jiong <djduanjiong@gmail.com>
> ---
> net/ipv6/icmp.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
> index 24d69db..d3cb61d 100644
> --- a/net/ipv6/icmp.c
> +++ b/net/ipv6/icmp.c
> @@ -82,9 +82,12 @@ static inline struct sock *icmpv6_sk(struct net *net)
> }
>
> static int icmpv6_rcv(struct sk_buff *skb);
> +static void icmpv6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
> + u8 type, u8 code, int offset, __be32 info);
>
> static const struct inet6_protocol icmpv6_protocol = {
> .handler = icmpv6_rcv,
> + .err_handler = icmpv6_err,
> .flags = INET6_PROTO_NOPOLICY|INET6_PROTO_FINAL,
> };
>
> @@ -782,6 +785,26 @@ drop_no_count:
> return 0;
> }
>
> +static void icmpv6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
> + u8 type, u8 code, int offset, __be32 info)
> +{
> + struct net *net = dev_net(skb->dev);
> + struct icmp6hdr *hdr = icmp6_hdr(skb);
> +
> + switch (hdr->icmp6_type) {
> + case ICMPV6_PKT_TOOBIG:
> + ip6_update_pmtu(skb, net, info, 0, 0);
> + break;
> +
> + case NDISC_REDIRECT:
> + ip6_redirect(skb, net, 0, 0);
> + break;
> +
> + default:
> + break;
> + }
> +}
> +
Not sure if it really matters, but the ip6_update_pmtu/ip6_redirect
function would be called twice if we have (raw) socket context. Maybe
it's better to do this in raw6_icmp_error() if we have no socket context.
^ permalink raw reply
* Re: [net-next 2/8] maintainers: update with official intel support link, new maintainer
From: Jeff Kirsher @ 2012-10-24 5:13 UTC (permalink / raw)
To: Joe Perches; +Cc: Tushar Dave, davem, Jesse Brandeburg, netdev, gospo, sassmann
In-Reply-To: <1351054355.7502.102.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
On Tue, 2012-10-23 at 21:52 -0700, Joe Perches wrote:
> On Tue, 2012-10-23 at 21:32 -0700, Jeff Kirsher wrote:
> > On Tue, 2012-10-23 at 06:25 -0700, Joe Perches wrote:
> > > On Tue, 2012-10-23 at 03:24 -0700, Jeff Kirsher wrote:
>
> > > > Add the current e1000 maintainer to the list of Intel maintainers.
>
> > > Maybe add an internal exploder to get all the various
> > > maintainers on a list if everyone really looks at all
> > > patches to intel drivers.
>
> > > INTEL ETHERNET DRIVERS
> > > M: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > M: Intel Linux Support <linux.drivers@intel.com>
> > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net.git
> > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git
> > > S: Supported
> > > F: drivers/net/ethernet/intel/
>
> > I understand where your coming from and this has been been something
> > that I have been trying to find a "reasonable" solution, which is harder
> > to do than one would expect.
> []
> > So how do we go about giving this spider web of complex coverage to some
> > clear concise coverage in the MAINTAINERS?
> []
> > If you have some ideas which may help resolve the issues, I am open to
> > suggestions.
>
> It's great that they all work on all intel drivers, but it seems
> that you are the nominal maintainer and they are all developers
> that might work on anything but nothing in particular.
>
> I think an internal exploder email address would work well.
>
That sounds good, I will discuss it with guys and figure it out.
Thanks!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 1/2] r8169: enable ALDPS for power saving
From: hayeswang @ 2012-10-24 5:55 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20121023193146.GA10463@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
[...]
> It would be nice to state these things in the commit message, namely:
> - ALDPS should never be enabled for the RTL8105e
> - none of the firmware-free chipsets support ALDPS
> - neither do the RTL8168d/8111d
Excuse me. I don't understand why the RTL8105e shouldn't enable ALDPS.
Best Regards,
Hayes
^ permalink raw reply
* RE: [PATCH v2 net-next 1/2] r8169: enable ALDPS for power saving
From: hayeswang @ 2012-10-24 5:55 UTC (permalink / raw)
To: 'Francois Romieu'; +Cc: netdev, linux-kernel
In-Reply-To: <20121023193304.GB10463@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
[...]
> > +static void r810x_aldps_disable(struct rtl8169_private *tp)
> > +{
> > + rtl_writephy(tp, 0x1f, 0x0000);
> > + rtl_writephy(tp, 0x18, 0x0310);
> > + msleep(100);
> > +}
>
> rtl8402_hw_phy_config used a msleep(20). Meguesses it won't
> hurt, right ?
No, it won't hurt. The delay make suer there is enough time to pause ALDPS.
Best Regards,
Hayes
^ permalink raw reply
* [PATCH] ipv6: Set default hoplimit as zero.
From: roy.qing.li @ 2012-10-24 6:01 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
Commit a02e4b7dae4551(Demark default hoplimit as zero) only changes the
hoplimit checking condition and default value in ip6_dst_hoplimit, not
zeros all hoplimit default value.
Keep the zeroing ip6_template_metrics[RTAX_HOPLIMIT - 1] to force it as
const, cause as a37e6e344910(net: force dst_default_metrics to const
section)
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/ipv6/route.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index d1ddbc6..ba3c16e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -219,7 +219,7 @@ static struct dst_ops ip6_dst_blackhole_ops = {
};
static const u32 ip6_template_metrics[RTAX_MAX] = {
- [RTAX_HOPLIMIT - 1] = 255,
+ [RTAX_HOPLIMIT - 1] = 0,
};
static const struct rt6_info ip6_null_entry_template = {
@@ -1232,7 +1232,7 @@ struct dst_entry *icmp6_dst_alloc(struct net_device *dev,
rt->rt6i_dst.addr = fl6->daddr;
rt->rt6i_dst.plen = 128;
rt->rt6i_idev = idev;
- dst_metric_set(&rt->dst, RTAX_HOPLIMIT, 255);
+ dst_metric_set(&rt->dst, RTAX_HOPLIMIT, 0);
spin_lock_bh(&icmp6_dst_lock);
rt->dst.next = icmp6_dst_gc_list;
--
1.7.4.1
^ permalink raw reply related
* [PATCH v3 net-next] r8169: enable ALDPS for power saving
From: Hayes Wang @ 2012-10-24 6:24 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, jean, Hayes Wang
In-Reply-To: <1350893153-18320-1-git-send-email-hayeswang@realtek.com>
Enable ALDPS function to save power when link down. Note that the
feature should be set after the other PHY settings. And the firmware
is necessary. Don't enable it without loading the firmware.
None of the firmware-free chipsets support ALDPS. Neither do the
RTL8168d/8111d.
For 8136 series, make sure the ALDPS is disabled before loading the
firmware. For 8168 series, the ALDPS would be disabled automatically
when loading firmware. You must not disable it directly.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 56 +++++++++++++++++++++++++++++-------
1 file changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index e7ff886..2317b8c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -687,6 +687,7 @@ enum features {
RTL_FEATURE_WOL = (1 << 0),
RTL_FEATURE_MSI = (1 << 1),
RTL_FEATURE_GMII = (1 << 2),
+ RTL_FEATURE_FW_LOADED = (1 << 3),
};
struct rtl8169_counters {
@@ -2394,8 +2395,10 @@ static void rtl_apply_firmware(struct rtl8169_private *tp)
struct rtl_fw *rtl_fw = tp->rtl_fw;
/* TODO: release firmware once rtl_phy_write_fw signals failures. */
- if (!IS_ERR_OR_NULL(rtl_fw))
+ if (!IS_ERR_OR_NULL(rtl_fw)) {
rtl_phy_write_fw(tp, rtl_fw);
+ tp->features |= RTL_FEATURE_FW_LOADED;
+ }
}
static void rtl_apply_firmware_cond(struct rtl8169_private *tp, u8 reg, u16 val)
@@ -2406,6 +2409,31 @@ static void rtl_apply_firmware_cond(struct rtl8169_private *tp, u8 reg, u16 val)
rtl_apply_firmware(tp);
}
+static void r810x_aldps_disable(struct rtl8169_private *tp)
+{
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_writephy(tp, 0x18, 0x0310);
+ msleep(100);
+}
+
+static void r810x_aldps_enable(struct rtl8169_private *tp)
+{
+ if (!(tp->features & RTL_FEATURE_FW_LOADED))
+ return;
+
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_writephy(tp, 0x18, 0x8310);
+}
+
+static void r8168_aldps_enable_1(struct rtl8169_private *tp)
+{
+ if (!(tp->features & RTL_FEATURE_FW_LOADED))
+ return;
+
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_w1w0_phy(tp, 0x15, 0x1000, 0x0000);
+}
+
static void rtl8169s_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -3178,6 +3206,8 @@ static void rtl8168e_2_hw_phy_config(struct rtl8169_private *tp)
rtl_w1w0_phy(tp, 0x19, 0x0000, 0x0001);
rtl_w1w0_phy(tp, 0x10, 0x0000, 0x0400);
rtl_writephy(tp, 0x1f, 0x0000);
+
+ r8168_aldps_enable_1(tp);
}
static void rtl8168f_hw_phy_config(struct rtl8169_private *tp)
@@ -3250,6 +3280,8 @@ static void rtl8168f_1_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x05, 0x8b85);
rtl_w1w0_phy(tp, 0x06, 0x4000, 0x0000);
rtl_writephy(tp, 0x1f, 0x0000);
+
+ r8168_aldps_enable_1(tp);
}
static void rtl8168f_2_hw_phy_config(struct rtl8169_private *tp)
@@ -3257,6 +3289,8 @@ static void rtl8168f_2_hw_phy_config(struct rtl8169_private *tp)
rtl_apply_firmware(tp);
rtl8168f_hw_phy_config(tp);
+
+ r8168_aldps_enable_1(tp);
}
static void rtl8411_hw_phy_config(struct rtl8169_private *tp)
@@ -3354,6 +3388,8 @@ static void rtl8411_hw_phy_config(struct rtl8169_private *tp)
rtl_w1w0_phy(tp, 0x19, 0x0000, 0x0001);
rtl_w1w0_phy(tp, 0x10, 0x0000, 0x0400);
rtl_writephy(tp, 0x1f, 0x0000);
+
+ r8168_aldps_enable_1(tp);
}
static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp)
@@ -3439,21 +3475,19 @@ static void rtl8105e_hw_phy_config(struct rtl8169_private *tp)
};
/* Disable ALDPS before ram code */
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x18, 0x0310);
- msleep(100);
+ r810x_aldps_disable(tp);
rtl_apply_firmware(tp);
rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+
+ r810x_aldps_enable(tp);
}
static void rtl8402_hw_phy_config(struct rtl8169_private *tp)
{
/* Disable ALDPS before setting firmware */
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x18, 0x0310);
- msleep(20);
+ r810x_aldps_disable(tp);
rtl_apply_firmware(tp);
@@ -3463,6 +3497,8 @@ static void rtl8402_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x10, 0x401f);
rtl_writephy(tp, 0x19, 0x7030);
rtl_writephy(tp, 0x1f, 0x0000);
+
+ r810x_aldps_enable(tp);
}
static void rtl8106e_hw_phy_config(struct rtl8169_private *tp)
@@ -3475,9 +3511,7 @@ static void rtl8106e_hw_phy_config(struct rtl8169_private *tp)
};
/* Disable ALDPS before ram code */
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x18, 0x0310);
- msleep(100);
+ r810x_aldps_disable(tp);
rtl_apply_firmware(tp);
@@ -3485,6 +3519,8 @@ static void rtl8106e_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
rtl_eri_write(tp, 0x1d0, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
+
+ r810x_aldps_enable(tp);
}
static void rtl_hw_phy_config(struct net_device *dev)
--
1.7.11.4
^ permalink raw reply related
* Re: [m68k, powerpc, dma, ethernet, freescale RFA] Coldfire m54xx FEC ethernet driver
From: Greg Ungerer @ 2012-10-24 6:30 UTC (permalink / raw)
To: Philippe De Muyter
Cc: uClinux development list, netdev, linux-kernel, linux-m68k,
stany.marcel, linuxppc-dev
In-Reply-To: <20121016080349.GA8427@frolo.macqel>
Hi Philippe,
On 16/10/12 18:03, Philippe De Muyter wrote:
> On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote:
>> On 09/10/12 19:07, Philippe De Muyter wrote:
>>> [CCing lkml, linux-ppc, netdev, linux-m68k]
>>>
>>> Hello kernel sources architects
>>>
>>> I have a working driver for the m54xx FEC ethernet driver that I
>>> would like to integrate in the kernel tree. Problems are that
>>> - this driver needs an associated DMA driver (provided by FreeScale)
>>> wich is not dma-engine enabled
>>> - they're are already many fec drivers in the kernel tree, and
>>> at least one, fec_mpc52xx.c, seems to be very similar (information
>>> below), to the one for the mcf54xx, except it uses a differently
>>> named associated DMA driver (BestComm/SmartDma/SDMA) which is also
>>> not dma-engine enabled, and even kept hidden in /arch/powerpc where
>>> it is inaccessible when compiling for m68k. The underlying DMA part
>>> from Freescale however seems similar to the one used in the
>>> m54xx. (again, see information below)
>>>
>>> So, now I am lost, what should I do ?
>>>
>>> The current state of my patches
>>> [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html]
>>> is pushing the freescale provided MCD_DMA dma driver to /drivers/dma,
>>> without adding the dma-engine compatibility layer, and adding the specific
>>> fec_m54xx ethernet driver to /drivers/net/ethernet/freescale
>>
>> Do you get any responses?
>> I didn't see any...
>
> No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm
> to drivers/dma/bestcomm (except a private and useful one telling me how to
> set '-M' option as default for 'git format-patch'), but at least this simpler
> patch seems to be in a wait bucket at
> http://patchwork.ozlabs.org/project/linuxppc-dev/list/.
Well, something useful then :-)
Feel free to send me the m68k header file updates as a patch (or patches
as appropriate), lets get those in now. They are worthwhile changes
on their own.
In light of no other other feedback you may want to push ahead then
with your patches to put the DMA engine code in drivers/dma. That
does seem like the right place to put it.
The new fec driver code should go to the netdev list for review.
Regards
Greg
> Regards
>
> Philippe
>
> PS: -M as default for 'git format-patch':
>
> put
> [diff]
> renames = true
> in .git/config
>
>>
>> Regards
>> Greg
>>
>>
>>
>>> On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
>>>> Hi Philippe,
>>>>
>>>> On 05/10/12 01:03, Philippe De Muyter wrote:
>>>>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>>>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>>>>
>>>>>>> My biggest concern is the amount of MCD/DMA support code. And it is
>>>>>>> all done quite differently to everything else in the kernel. We may
>>>>>>> get a bit of push back from kernel folk who look after DMA.
>>>>>>
>>>>>> Actually, there is already a similar code in
>>>>>> arch/powerpc/sysdev/bestcomm
>>>>>> (also from freescale, maybe an identical part, but I did not find any
>>>>>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc
>>>>>> tree, instead of installing it in drivers/dma.
>>>>>
>>>>> The MCD DMA or DMA FEC code from freescale has a comment implying that
>>>>> this
>>>>> was first used in the MPC8220 part. And Montavista has a MPC8220 port,
>>>>> but
>>>>> I did not find it, so I do not know where they installed the MCD DMA
>>>>> driver.
>>>>
>>>> Ok, looks like there is a bit a variance in all this.
>>>
>>> I also began to read the mpc5200 user's guide parts about the fec and
>>> BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name)
>>> and they look very similar, but not identical, to their m54xx
>>> counterparts.
>>>
>>> It seems possible to make the fec_mpc52xx.c driver work for the m54xx
>>> but that needs at least:
>>> - moving some files or part of them from /arch/powerpc/sysdev and
>>> /arch/powerpc/include/asm to /drivers/dma and /include/linux,
>>> - renaming the fec_mpc52xx files to a more sensible name,
>>> - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h,
>>> - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA
>>> in mcf_52xx.c.
>>>
>>> An additional problem is that the freescale docs for powerpcs and for
>>> coldfires do not use the same mnemonics for the same registers.
>>>
>>> e.g. FEC registers
>>> offset MPC5200 MCF5484
>>> ====== ======= =======
>>> 000 FEC_ID n/a
>>> 004 IEVENT EIR
>>> 008 IMASK EIMR
>>> 010 R_DES_ACTIVE n/a
>>> 014 X_DES_ACTIVE n/a
>>> 024 ECNTRL ECR
>>> 040 MII_DATA MDATA
>>> 044 MII_SPEED MSCR
>>> 064 MIB_CONTROL MIBC
>>> 084 R_CNTRL RCR
>>> 088 R_HASH RHR
>>> 0C4 X_CNTRL TCR
>>> 0E4 PADDR1 PALR
>>> 0E8 PADDR2 PAHR
>>> 0EC OP_PAUSE OPD
>>> 118 IADDR1 IAUR
>>> 11C IADDR1 IALR
>>> 120 GADDR1 GAUR
>>> 124 GADDR2 GALR
>>> 144 X_WMRK FECTFWR
>>> 184 RFIFO_DATA FECRFDR
>>> 188 RFIFO_STATUS FECRFSR
>>> 18C RFIFO_CONTROL FECRFCR
>>> 190 RFIFO_LRF_PTR FECRLRFP
>>> 194 RFIFO_LWF_PTR FECRLWFP
>>> 198 RFIFO_ALARM FECRFAR
>>> 19C RFIFO_RDPTR FECRFRP
>>> 1A0 RFIFO_WRPTR FECRFWP
>>> 1A4 TFIFO_DATA FECTFDR
>>> 1A8 TFIFO_STATUS FECTFSR
>>> 1AC TFIFO_CONTROL FECTFCR
>>> 1B0 TFIFO_LRF_PTR FECTLRFP
>>> 1B4 TFIFO_LWF_PTR FECTLWFP
>>> 1B8 TFIFO_ALARM FECTFAR
>>> 1BC TFIFO_RDPTR FECTFRP
>>> 1C0 TFIFO_WRPTR FECTFWP
>>> 1C4 RESET_CNTRL FECFRST
>>> 1C8 XMIT_FSM FECCTCWR
>>>
>>>> Probably the best thing to do is post the patches on the linux kernel
>>>> mailing list then, asking for direction on a dma driver.
>>>>
>>>> I have no problem with it going into the arch/m68k area. So that is
>>>> always an option.
>>>
>>> For the dma engines, the similarity is also obvious. For example, find
>>> below side by side mpc52xx and m54xx definitions for the
>>> main DMA registers :
>>>
>>> from mpc52xx.h from MCD_dma.h
>>> /* SDMA */ /* MCD_DMA */
>>> struct mpc52xx_sdma { struct dmaRegs {
>>> u32 taskBar; /* 0x00 */ u32 taskbar;
>>> u32 currentPointer; /* 0x04 */ u32 currPtr;
>>> u32 endPointer; /* 0x08 */ u32 endPtr;
>>> u32 variablePointer; /* 0x0c */ u32 varTablePtr;
>>>
>>> u8 IntVect1; /* 0x10 */ u16 dma_rsvd0;
>>> u8 IntVect2; /* 0x11 */
>>> u16 PtdCntrl; /* 0x12 */ u16 ptdControl;
>>>
>>> u32 IntPend; /* 0x14 */ u32 intPending;
>>> u32 IntMask; /* 0x18 */ u32 intMask;
>>>
>>> u16 tcr[16]; /* 0x1c .. 0x3a */ u16 taskControl[16];
>>>
>>> u8 ipr[32]; /* 0x3c .. 0x5b */ u8 priority[32];
>>>
>>> u32 cReqSelect; /* 0x5c */ u32 initiatorMux;
>>> u32 task_size0; /* 0x60 */ u32 taskSize0;
>>> u32 task_size1; /* 0x64 */ u32 taskSize1;
>>> u32 MDEDebug; /* 0x68 */ u32 dma_rsvd1;
>>> u32 ADSDebug; /* 0x6c */ u32 dma_rsvd2;
>>> u32 Value1; /* 0x70 */ u32 debugComp1;
>>> u32 Value2; /* 0x74 */ u32 debugComp2;
>>> u32 Control; /* 0x78 */ u32 debugControl;
>>> u32 Status; /* 0x7c */ u32 debugStatus;
>>> u32 PTDDebug; /* 0x80 */ u32 ptdDebug;
>>> }; };
>
>
>
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
^ permalink raw reply
* BUSINESS DEAL PROPOSAL!!!
From: WONG HUI @ 2012-10-24 1:49 UTC (permalink / raw)
Please I would like you to keep this proposal as a top secret and delete it if you
are not interested and get back to me if you are interested for details as regards
to the transfer of $24,500,000 to you.
This money initially belongs to a Libyan client who died in the libya crisis and had no next of kin in his
account-opening package in my bank here in Hong kong where I am a bank director.
In other to achieve this, I shall require your full name, and telephone number to reach you.
Most importantly, a confirmation of acceptance from you will be needed after which I
shall furnish you with the full details of this transaction.
Yours Truly,
Wong Hui.
^ permalink raw reply
* Re: Incorrect ARP behavior when multiple/none IPv4 address assigned to interface
From: Sergey Popovich @ 2012-10-24 7:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <alpine.LFD.2.00.1210232317400.1780@ja.ssi.bg>
Julian Anastasov пишет:
>> # tcpdump -vv -ieth0 -s1500 -nnpe 'arp'
>> 13:28:57.395181 08:00:27:3b:63:ae> 0a:00:27:00:00:00, ethertype ARP (0x0806),
>> length 42: Ethernet (len 6),.
>> IPv4 (len 4), Request who-has 10.0.1.2 tell 10.10.10.10, length 28
>
> What kind of packet triggers ARP request here?
> May be this IP packet already has saddr=10.10.10.10 ?
> arp_solicit() when eth0/arp_announce=0 (default) just
> ensures that this saddr is local. Or it is a forwarding
> case and inet_select_addr is used? Also, any reason to put
> addresses on loopback and not on eth0?
1. Sorry, from bug report is not clear to undestand how this is reproduced:
1.1. on PC1 run ping 10.0.1.1
1.2. on Linux Router start arp-probe-bug.bsh as root user.
So this kind of packet generated after link layer addresses resolved &
ICMP Echo Request/Reply in progress (with no packet loss).
2. No I do not think that saddr=10.10.10.10 in probe.
arp_solicit calls inet_select_addr() only if saddr=0.0.0.0.
Call to arp_solicit() made from net/core/neighbour.c neigh_probe()
which is static and called from neigh_timer_handler() when entry ages
out and goes to PROBE phase.
3. Reason to put addr on loopback (not actually system loopback, but
linux dummy interface or any other network interface) described in more
details in my bug report, but for short:
Suppose we have 10.0.1.0/24 subnet.
and many customers with single ip address (common for Internet
Providers) on differend broadcast domains (VLANs).
Each customer connected using 4(!) IPv4 address using traditional schema:
10.0.1.0/30 - Customer 1 (ip: 10.0.1.2, gw: 10.0.1.1, mask: /30)
10.0.1.4/30 - Customer 2 (ip: 10.0.1.6, gw: 10.0.1.5, mask: /30)
10.0.1.8/30 - Customer 3 (ip: 10.0.1.10, gw: 10.0.1.9, mask: /30)
...
10.0.1.252/30 - Customer 64 (ip: 10.0.1.254, gw: 10.0.1.253, mask: /30
As can be seen on each connection we waste at least 2 IP address:
one for subnet address (all zeros in host part)
one for subnet broadcast (all ones in host part)
More efficiently to use entire subnet with /24 mask and assign to each
customer one ip from subnet with mask /24.
10.0.1.1/24 - Loopback (dummy) on Linux Router. This is gateway address
to customers.
10.0.1.2/24 - Customer 1
10.0.1.3/24 - Customer 2
10.0.1.4/24 - Customer 3
...
10.0.1.254/24 - Customer 253
This schema called by some network equipment vendors as "ip unnumbered"
and works in Linux for years (and thus used with proper NICs by many
small/medium (and even large) ISPs to aggregate broadband customers).
> Your case 2 can be also solved with proper ordering of
> the primaries, eg. first add /32 primaries, then /31, ... /25, /24.
> You can also use decreasing scope for the addresses if global
> scope is not needed for them, it can help for the ordering.
>
Yes you are right, but it is not clear to understand at configure
time:-).
> For the proposed patch: providing iph->saddr to
> inet_select_addr() in icmp_send() looks better than before.
> Still, inet_select_addr() is incorrect function to use
> from icmp_send(), there is the risk to expose scope link
> addresses.
>
Correct, but using sysctl icmp_errors_use_inbound_ifaddr as for
me is not right entirely:
ICMP might be generated for address that is not directly reachable
(more than hop away from interface on which packet arrives -
reachable via gw on interface) and thus it is better to rely on
prefsrc of route associated with this interface when sending ICMP in
ip_route_output_slow() that is already done and works correctly.
Using iph->saddr is done as contermeasure only used then such sysctl is
activated (default: no).
> The other part from patch in inet_select_addr() looks
> correct to me but comes with some price for the arp_solicit()
> and icmp_send() cases, a slowdown that may not be liked by
> others.
Yes, we looking at all interfaces in system and all primary addresses
on.
>
> About fib_info_update_nh_saddr: same fib_info can
> be used for different subnets, so we can not check the
> destination. But routes to directly connected hosts
> usually come with prefsrc (proto kernel), so it is not a
> problem.
Yes, I point to this to clarify this to me. Thank you.
--
SP5474-RIPE
Sergey Popovich
^ permalink raw reply
* Re: [PATCH net-next 1/2] packet: clean up error variable assignments
From: Daniel Borkmann @ 2012-10-24 7:47 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Eric Dumazet, davem, netdev
In-Reply-To: <1351033824.5283.80.camel@deadeye.wl.decadent.org.uk>
On Wed, Oct 24, 2012 at 1:10 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Tue, 2012-10-23 at 19:05 +0200, Eric Dumazet wrote:
>> On Tue, 2012-10-23 at 13:56 +0200, Daniel Borkmann wrote:
>> > This patch performs clean-ups of packet's err variables where appropriate.
>> > In particular, errnos are *only* assigned in error cases, which saves
>> > useless instructions in non-error cases and makes the code more readable
>> > in terms of which error type belongs to which evaluated error condition.
>> > Also, in some cases an errno was set, but not used until the next assignment.
>>
>> I see no value in this patch.
>>
>> Setting err before a test is a common way to handle error cases and
>> generates smaller code in linux kernel.
>>
>> Better live with it than trying to change it ?
>>
>> err = -ENOMEM;
>> match = kzalloc(xxxx);
>> if (!match)
>> goto error;
>>
>>
>> is smaller (source code & generated code) than :
>>
>> match = kzalloc(xxxx);
>> if (!match) {
>> err = -ENOMEM;
>> goto error;
>> }
>>
>> An immediate load is basically free, but code size matters.
>
> In my experience gcc is generally able to perform this optimisation
> itself, at least for x86. Setting 'err' only after checking for failure
> seems clearer, but I think this is really a matter of taste.
It might also be more likely in case code gets removed, that the
relating 'err' will be removed as well. If I remember correctly, I've
seen one or two cases where there was an assignment with no 'return'
in between the next assignment of 'err'. But probably spatch could
detect such cases as well.
^ permalink raw reply
* Re: [PATCH 0/6] kernel parameters: introduce "macaddr" to set mac address
From: Paolo Pisati @ 2012-10-24 8:07 UTC (permalink / raw)
To: David Miller; +Cc: p.pisati, netdev, peppe.cavallaro, kristoffer
In-Reply-To: <20121023.132037.2010164496712539552.davem@davemloft.net>
On Tue, Oct 23, 2012 at 01:20:37PM -0400, David Miller wrote:
> From: Paolo Pisati <p.pisati@gmail.com>
> Date: Tue, 23 Oct 2012 19:15:27 +0200
>
> > In the past drivers grew mechanism to set their own mac address at boot time
> > via (usually) a module parameter. Unfortunately every single driver had its
> > own naming/implementation and it soon became clear that a generic
> > mechanism was needed.
> >
> > Introduce "macaddr=", a new kernel parameter to set MAC address using
> > netdevice ops (and hence being hardware independent).
>
> Sorry, no, no module parameters.
>
> Run time setting is the only reasonable way to set the MAC address
> explicitly.
actually it's a not a module parameter.
and what if you want to change your nic MAC at boot time? e.g. netboot
setup with different configs per different MACs.
--
bye,
p.
^ permalink raw reply
* Re: Incorrect ARP behavior when multiple/none IPv4 address assigned to interface
From: Julian Anastasov @ 2012-10-24 9:06 UTC (permalink / raw)
To: Sergey Popovich; +Cc: netdev
In-Reply-To: <50879632.20909@mail.ru>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3764 bytes --]
Hello,
On Wed, 24 Oct 2012, Sergey Popovich wrote:
> Julian Anastasov пишет:
>
> > > # tcpdump -vv -ieth0 -s1500 -nnpe 'arp'
> > > 13:28:57.395181 08:00:27:3b:63:ae> 0a:00:27:00:00:00, ethertype ARP
> > > (0x0806),
> > > length 42: Ethernet (len 6),.
> > > IPv4 (len 4), Request who-has 10.0.1.2 tell 10.10.10.10, length 28
> >
> > What kind of packet triggers ARP request here?
> > May be this IP packet already has saddr=10.10.10.10 ?
> > arp_solicit() when eth0/arp_announce=0 (default) just
> > ensures that this saddr is local. Or it is a forwarding
> > case and inet_select_addr is used? Also, any reason to put
> > addresses on loopback and not on eth0?
>
> 1. Sorry, from bug report is not clear to undestand how this is reproduced:
> 1.1. on PC1 run ping 10.0.1.1
> 1.2. on Linux Router start arp-probe-bug.bsh as root user.
> So this kind of packet generated after link layer addresses resolved &
> ICMP Echo Request/Reply in progress (with no packet loss).
>
> 2. No I do not think that saddr=10.10.10.10 in probe.
> arp_solicit calls inet_select_addr() only if saddr=0.0.0.0.
> Call to arp_solicit() made from net/core/neighbour.c neigh_probe()
> which is static and called from neigh_timer_handler() when entry ages
> out and goes to PROBE phase.
Indeed, it can happen often to see skb=NULL for
empty arp_queue...
> 3. Reason to put addr on loopback (not actually system loopback, but
> linux dummy interface or any other network interface) described in more
> details in my bug report, but for short:
>
> Suppose we have 10.0.1.0/24 subnet.
> and many customers with single ip address (common for Internet
> Providers) on differend broadcast domains (VLANs).
>
> Each customer connected using 4(!) IPv4 address using traditional schema:
>
> 10.0.1.0/30 - Customer 1 (ip: 10.0.1.2, gw: 10.0.1.1, mask: /30)
> 10.0.1.4/30 - Customer 2 (ip: 10.0.1.6, gw: 10.0.1.5, mask: /30)
> 10.0.1.8/30 - Customer 3 (ip: 10.0.1.10, gw: 10.0.1.9, mask: /30)
> ...
> 10.0.1.252/30 - Customer 64 (ip: 10.0.1.254, gw: 10.0.1.253, mask: /30
>
> As can be seen on each connection we waste at least 2 IP address:
> one for subnet address (all zeros in host part)
> one for subnet broadcast (all ones in host part)
>
> More efficiently to use entire subnet with /24 mask and assign to each
> customer one ip from subnet with mask /24.
>
> 10.0.1.1/24 - Loopback (dummy) on Linux Router. This is gateway address
> to customers.
> 10.0.1.2/24 - Customer 1
> 10.0.1.3/24 - Customer 2
> 10.0.1.4/24 - Customer 3
> ...
> 10.0.1.254/24 - Customer 253
>
> This schema called by some network equipment vendors as "ip unnumbered"
> and works in Linux for years (and thus used with proper NICs by many
> small/medium (and even large) ISPs to aggregate broadband customers).
But I still don't understand what will prevent
this "ip unnumbered" address assignment schema to work on
eth0/1/2 instead of using many dummy interfaces, they are
only a place to put addresses, it seems.
dummy module is usually used as blackhole for
traffic or to hide addresses from other interfaces with
some sysctl interface flags.
For example, can it work in this way?:
eth0: addr 10.0.1.1/24
ip route 10.0.1.2/32 dev eth0 src 10.0.1.1
eth1: addr 10.0.1.1/24
ip route 10.0.1.3/32 dev eth1 src 10.0.1.1
eth2: addr 10.0.2.1/24
ip route 10.0.2.2/32 dev eth2 src 10.0.2.1
By this way we have subnet on every device and
we can prefer local IP from such subnet in inet_select_addr.
May be arp_ignore=1/2 and arp_announce=1/2 can help here
to put the needed restrictions, i.e. we should not expose
addresses from other devices. It should not cause problem
for proxy_arp because we have more specific /32 routes.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH 1/2] can: flexcan: disable bus error interrupts for the i.MX6q
From: Marc Kleine-Budde @ 2012-10-24 9:06 UTC (permalink / raw)
To: David Miller
Cc: Linux Netdev List, linux-can, Wolfgang Grandegger, Hui Wang,
Shawn Guo, Marc Kleine-Budde
In-Reply-To: <1351069576-20790-1-git-send-email-mkl@pengutronix.de>
From: Wolfgang Grandegger <wg@grandegger.com>
This patch adds some Flexcan version info and removes the feature flag
FLEXCAN_HAS_BROKEN_ERR_STATE for the i.MX6Q. It also has the line [TR]WRN_INT
properly connected.
Cc: Hui Wang <jason77.wang@gmail.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
[mkl: convert to incremental patch]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index c78ecfc..a412bf6 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -144,9 +144,22 @@
#define FLEXCAN_MB_CODE_MASK (0xf0ffffff)
-/* FLEXCAN hardware feature flags */
+/*
+ * FLEXCAN hardware feature flags
+ *
+ * Below is some version info we got:
+ * SOC Version IP-Version Glitch- [TR]WRN_INT
+ * Filter? connected?
+ * MX25 FlexCAN2 03.00.00.00 no no
+ * MX28 FlexCAN2 03.00.04.00 yes yes
+ * MX35 FlexCAN2 03.00.00.00 no no
+ * MX53 FlexCAN2 03.00.00.00 yes no
+ * MX6s FlexCAN3 10.00.12.00 yes yes
+ *
+ * Some SOCs do not have the RX_WARN & TX_WARN interrupt line connected.
+ */
#define FLEXCAN_HAS_V10_FEATURES BIT(1) /* For core version >= 10 */
-#define FLEXCAN_HAS_BROKEN_ERR_STATE BIT(2) /* Broken error state handling */
+#define FLEXCAN_HAS_BROKEN_ERR_STATE BIT(2) /* [TR]WRN_INT not connected */
/* Structure of the message buffer */
struct flexcan_mb {
@@ -205,7 +218,7 @@ static struct flexcan_devtype_data fsl_p1010_devtype_data = {
};
static struct flexcan_devtype_data fsl_imx28_devtype_data;
static struct flexcan_devtype_data fsl_imx6q_devtype_data = {
- .features = FLEXCAN_HAS_V10_FEATURES | FLEXCAN_HAS_BROKEN_ERR_STATE,
+ .features = FLEXCAN_HAS_V10_FEATURES,
};
static const struct can_bittiming_const flexcan_bittiming_const = {
--
1.7.10
^ permalink raw reply related
* [PATCH 2/2] can: sja1000: fix/add miniPCIe/cPCI PC/104Plus PCI/104e PEAK-System boards
From: Marc Kleine-Budde @ 2012-10-24 9:06 UTC (permalink / raw)
To: David Miller
Cc: Linux Netdev List, linux-can, Stephane Grosjean,
Marc Kleine-Budde
In-Reply-To: <1351069576-20790-1-git-send-email-mkl@pengutronix.de>
From: Stephane Grosjean <s.grosjean@peak-system.com>
This patch adds the support for 4 new PCI boards based on the SJA1000 CAN
controller, from PEAK-System Technik:
. PCAN-miniPCIe (PCI-Express Mini slots, available as single or dual-channel)
. PCAN-cPCI (CompactPCI format, available as single or dual-channel)
. PCAN-PC/104-Plus (PC/104-Plus system, av. as 1, 2 or 4 channels)
. PCAN-PCI/104-Express (PCI/104-Express system, av. as 1 or 2 channels)
This patch also fixes a typo in existing "PEAK_MPCI_DEVICE_ID" identifier
(missing "e" for Express). Finally, it also changes the author as well as it
updates the module supported devices list.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/peak_pci.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c
index f5b82ae..6525dbc 100644
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -30,9 +30,10 @@
#include "sja1000.h"
-MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
+MODULE_AUTHOR("Stephane Grosjean <s.grosjean@peak-system.com>");
MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCI family cards");
MODULE_SUPPORTED_DEVICE("PEAK PCAN PCI/PCIe/PCIeC miniPCI CAN cards");
+MODULE_SUPPORTED_DEVICE("PEAK PCAN miniPCIe/cPCI PC/104+ PCI/104e CAN Cards");
MODULE_LICENSE("GPL v2");
#define DRV_NAME "peak_pci"
@@ -64,7 +65,11 @@ struct peak_pci_chan {
#define PEAK_PCI_DEVICE_ID 0x0001 /* for PCI/PCIe slot cards */
#define PEAK_PCIEC_DEVICE_ID 0x0002 /* for ExpressCard slot cards */
#define PEAK_PCIE_DEVICE_ID 0x0003 /* for nextgen PCIe slot cards */
-#define PEAK_MPCI_DEVICE_ID 0x0008 /* The miniPCI slot cards */
+#define PEAK_CPCI_DEVICE_ID 0x0004 /* for nextgen cPCI slot cards */
+#define PEAK_MPCI_DEVICE_ID 0x0005 /* for nextgen miniPCI slot cards */
+#define PEAK_PC_104P_DEVICE_ID 0x0006 /* PCAN-PC/104+ cards */
+#define PEAK_PCI_104E_DEVICE_ID 0x0007 /* PCAN-PCI/104 Express cards */
+#define PEAK_MPCIE_DEVICE_ID 0x0008 /* The miniPCIe slot cards */
#define PEAK_PCI_CHAN_MAX 4
@@ -76,6 +81,10 @@ static DEFINE_PCI_DEVICE_TABLE(peak_pci_tbl) = {
{PEAK_PCI_VENDOR_ID, PEAK_PCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
{PEAK_PCI_VENDOR_ID, PEAK_PCIE_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
{PEAK_PCI_VENDOR_ID, PEAK_MPCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_MPCIE_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_PC_104P_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_PCI_104E_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_CPCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
#ifdef CONFIG_CAN_PEAK_PCIEC
{PEAK_PCI_VENDOR_ID, PEAK_PCIEC_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
#endif
--
1.7.10
^ permalink raw reply related
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