* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Eric Dumazet @ 2011-12-02 14:29 UTC (permalink / raw)
To: igorm; +Cc: netdev, davem, Realtek linux nic maintainers, Francois Romieu
In-Reply-To: <1322831399-23505-1-git-send-email-igorm@etf.rs>
Le vendredi 02 décembre 2011 à 14:09 +0100, igorm@etf.rs a écrit :
> From: Igor Maravic <igorm@etf.rs>
>
> Changes to r8169 to use byte queue limits.
>
> Signed-off-by: Igor Maravic <igorm@etf.rs>
> ---
> drivers/net/ethernet/realtek/r8169.c | 12 ++++++++++--
> 1 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index e5a6d8e..7ea428c 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -3773,6 +3773,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
> static void rtl8169_init_ring_indexes(struct rtl8169_private *tp)
> {
> tp->dirty_tx = tp->dirty_rx = tp->cur_tx = tp->cur_rx = 0;
> + netdev_reset_queue(tp->dev);
Hmm... What about rtl8169_tx_clear_range() or rtl8169_tx_clear() ?
Also please CC maintainers of this driver to your submission.
(I did this)
> }
>
> static void rtl_hw_jumbo_enable(struct rtl8169_private *tp)
> @@ -5458,6 +5459,7 @@ static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
> tp->tx_skb[entry].skb = skb;
> txd->opts1 |= cpu_to_le32(LastFrag);
> }
> + netdev_sent_queue(tp->dev, skb->len);
>
> return cur_frag;
>
> @@ -5623,6 +5625,8 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
> void __iomem *ioaddr)
> {
> unsigned int dirty_tx, tx_left;
> + unsigned int bytes_compl = 0;
> + int tx_compl = 0;
>
> dirty_tx = tp->dirty_tx;
> smp_rmb();
> @@ -5641,8 +5645,8 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
> rtl8169_unmap_tx_skb(&tp->pci_dev->dev, tx_skb,
> tp->TxDescArray + entry);
> if (status & LastFrag) {
> - dev->stats.tx_packets++;
> - dev->stats.tx_bytes += tx_skb->skb->len;
> + bytes_compl += tx_skb->skb->len;
> + tx_compl++;
> dev_kfree_skb(tx_skb->skb);
> tx_skb->skb = NULL;
> }
> @@ -5650,6 +5654,10 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
> tx_left--;
> }
>
> + dev->stats.tx_packets += tx_compl;
> + dev->stats.tx_bytes += bytes_compl;
> + netdev_completed_queue(dev, tx_compl, bytes_compl);
> +
> if (tp->dirty_tx != dirty_tx) {
> tp->dirty_tx = dirty_tx;
> smp_wmb();
^ permalink raw reply
* Re: [PATCH 2/3] caif: Add support for flow-control on device's tx-queue
From: Eric Dumazet @ 2011-12-02 14:38 UTC (permalink / raw)
To: Sjur Brændeland; +Cc: netdev, David Miller, Alexey Orishko
In-Reply-To: <1322834777-2486-3-git-send-email-sjur.brandeland@stericsson.com>
Le vendredi 02 décembre 2011 à 15:06 +0100, Sjur Brændeland a écrit :
> Flow control is implemented by inspecting the qdisc queue length
> in order to detect potential overflow on the TX queue. When a threshold
> is reached flow-off is sent upwards in the CAIF stack. At the same time
> the skb->destructor is hi-jacked in order to detect when the last packet
> put on queue is consumed. When this "hi-jacked" packet is consumed, flow-on
> is sent upwards in the CAIF stack.
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
> ---
> net/caif/caif_dev.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
> index f7e8c70..415353e 100644
> --- a/net/caif/caif_dev.c
> +++ b/net/caif/caif_dev.c
> @@ -34,6 +34,7 @@ struct caif_device_entry {
> struct list_head list;
> struct net_device *netdev;
> int __percpu *pcpu_refcnt;
> + bool xoff;
> };
>
> struct caif_device_entry_list {
> @@ -48,6 +49,7 @@ struct caif_net {
> };
>
> static int caif_net_id;
> +static int q_high = 50; /* Percent */
>
> struct cfcnfg *get_cfcnfg(struct net *net)
> {
> @@ -126,9 +128,28 @@ static struct caif_device_entry *caif_get(struct net_device *dev)
> return NULL;
> }
>
> +void caif_flow_cb(struct sk_buff *skb)
> +{
> + struct caif_device_entry *caifd;
> + WARN_ON(skb->dev == NULL);
> +
> + rcu_read_lock();
> + caifd = caif_get(skb->dev);
> + caifd->xoff = 0;
> + caifd_hold(caifd);
> + rcu_read_unlock();
> +
> + caifd->layer.up->
> + ctrlcmd(caifd->layer.up,
> + _CAIF_CTRLCMD_PHYIF_FLOW_ON_IND,
> + caifd->layer.id);
> + caifd_put(caifd);
> +}
> +
> static int transmit(struct cflayer *layer, struct cfpkt *pkt)
> {
> int err;
> + struct caif_dev_common *caifdev;
> struct caif_device_entry *caifd =
> container_of(layer, struct caif_device_entry, layer);
> struct sk_buff *skb;
> @@ -137,6 +158,33 @@ static int transmit(struct cflayer *layer, struct cfpkt *pkt)
> skb->dev = caifd->netdev;
> skb_reset_network_header(skb);
> skb->protocol = htons(ETH_P_CAIF);
> + caifdev = netdev_priv(caifd->netdev);
> +
> + if (caifdev->flowctrl == NULL && caifd->netdev->tx_queue_len > 0 &&
> + !caifd->xoff) {
> + struct netdev_queue *txq;
> + int high;
> +
> + txq = netdev_get_tx_queue(skb->dev, 0);
Why queue 0 and not another one ?
> + high = (caifd->netdev->tx_queue_len * q_high) / 100;
> +
> + /* If we run with a TX queue, check if the queue is too long*/
Are you sure only this cpu can run here ? any lock is held ?
> + if (netif_queue_stopped(caifd->netdev) ||
> + qdisc_qlen(txq->qdisc) > high) {
> +
> + pr_debug("queue stop(%d) or full (%d>%d) - XOFF\n",
> + netif_queue_stopped(caifd->netdev),
> + qdisc_qlen(txq->qdisc), high);
> + caifd->xoff = 1;
> + /* Hijack this skb free callback function. */
> + skb_orphan(skb);
> + skb->destructor = caif_flow_cb;
> + caifd->layer.up->
> + ctrlcmd(caifd->layer.up,
> + _CAIF_CTRLCMD_PHYIF_FLOW_OFF_IND,
> + caifd->layer.id);
> + }
> + }
>
> err = dev_queue_xmit(skb);
> if (err > 0)
What prevents dev_queue_xmit() to early orphan skb ?
^ permalink raw reply
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Igor Maravić @ 2011-12-02 14:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, Realtek linux nic maintainers, Francois Romieu
In-Reply-To: <1322836191.2762.3.camel@edumazet-laptop>
> Hmm... What about rtl8169_tx_clear_range() or rtl8169_tx_clear() ?
>
You mean we should put netdev_reset_queue() in those functions?
I think that we shouldn't put any thing in these functions.
When ever they are called, they are precede/followed by function
rtl8169_hw_reset() which calls rtl_hw_reset() which calls
rtl8169_init_ring_indexes() in which I've put netdev_reset_queue()
Only time when rtl8169_tx_clear_range() isn't preceded/followed by
rtl8169_hw_reset() is in function rtl8169_xmit_frags(). In that
function it's
called only in case there's an error. In case there was an error in that
function, netdev_sent_queue() will never be called, so we are going to have
accurate length of queue.
^ permalink raw reply
* Re: BCM43224: 00:00:00:00:00:00 address (3.2.0-rc3-00099-g883381d)
From: Nico Schottelius @ 2011-12-02 15:01 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Nico Schottelius, LKML, netdev, b43-dev, Greg KH
In-Reply-To: <4ED8B610.2010703@broadcom.com>
Hey Arend,
Arend van Spriel [Fri, Dec 02, 2011 at 12:27:12PM +0100]:
> Have you tried the brcmsmac driver?
I've been mislead: bcma was enabled and thus brcmsmac
not shown in menuconfig.
Upgrade the kernel to 3.2.0-rc4-00077-g5983fe2, fired
up wpa_supplicant. Result: wpa_cli can connect to wpa_supplicant,
but stops working after a few seconds:
wpa_state=ASSOCIATING
> 'PING' command timed out.
Connection to wpa_supplicant lost - trying to reconnect
Warning: Failed to attach to wpa_supplicant.
> 'PING' command timed out.
Connection to wpa_supplicant lost - trying to reconnect
Warning: Failed to attach to wpa_supplicant.
'PING' command timed out.
Connection to wpa_supplicant lost - trying to reconnect
Warning: Failed to attach to wpa_supplicant.
'PING' command timed out.
Connection to wpa_supplicant lost - trying to reconnect
Warning: Failed to attach to wpa_supplicant.
No network connectivity and network processes are hanging.
I.e. same behaviour as reported on 2011-10-18.
Is it possible the related patch as discussed
in "BUG: All network processes hang (brcmsmac/wpa_supplicant)"
has not been merged into 3.2.0-rc4-00077-g5983fe2?
And regarding b43: Wouldn't it be good to remove support for the
specific pci-ids from it so it does not create a non-functional
wlan0 device?
Cheers,
Nico
--
PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
^ permalink raw reply
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Eric Dumazet @ 2011-12-02 15:11 UTC (permalink / raw)
To: igorm
Cc: netdev, davem, Realtek linux nic maintainers, Francois Romieu,
Tom Herbert
In-Reply-To: <CAFdo_mVwRgB3OEBA7=nMcemr1x1WLkXC05UAnDW_n5gyYy9W=A@mail.gmail.com>
Le vendredi 02 décembre 2011 à 15:54 +0100, Igor Maravić a écrit :
> > Hmm... What about rtl8169_tx_clear_range() or rtl8169_tx_clear() ?
> >
>
> You mean we should put netdev_reset_queue() in those functions?
>
> I think that we shouldn't put any thing in these functions.
>
> When ever they are called, they are precede/followed by function
> rtl8169_hw_reset() which calls rtl_hw_reset() which calls
> rtl8169_init_ring_indexes() in which I've put netdev_reset_queue()
>
> Only time when rtl8169_tx_clear_range() isn't preceded/followed by
> rtl8169_hw_reset() is in function rtl8169_xmit_frags(). In that
> function it's
> called only in case there's an error. In case there was an error in that
> function, netdev_sent_queue() will never be called, so we are going to have
> accurate length of queue.
Quite frankly, any queued skb is eventually freed, so
netdev_reset_queue() could be avoided.
r8169 driver has some problems (see current threads on netdev about it),
and its not very clear that BQL locking requirements are going to be
respected. This can lead to inaccurate BQL counts and a txqueue freeze.
(In particular, a chip reset can be triggered by an IRQ, while another
cpu is currently sending an skb through ndo_start_xmit())
So I advise not using netdev_reset_queue() in this driver, only
netdev_completed_queue(), and make sure that their calls are serialized
under a given lock (see include/linux/dynamic_queue_limits.h comments)
^ permalink raw reply
* Re: [PATCH 1/1] net/macb: add DT support
From: Nicolas Ferre @ 2011-12-02 15:30 UTC (permalink / raw)
To: Jamie Iles; +Cc: Jean-Christophe PLAGNIOL-VILLARD, devicetree-discuss, netdev
In-Reply-To: <20111120171123.GA7845@gallagher>
On 11/20/2011 06:11 PM, Jamie Iles :
> On Sun, Nov 20, 2011 at 05:47:40PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 15:58 Fri 18 Nov , Jamie Iles wrote:
>>> Hi Jean-Christophe,
>>>
>>> On Fri, Nov 18, 2011 at 03:29:25PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>> allow the DT to pass the mac address and the phy mode
>>>>
>>>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD<plagnioj@jcrosoft.com>
>>>> Cc: Jamie Iles<jamie@jamieiles.com>
>>>> Cc: Nicolas Ferre<nicolas.ferre@atmel.com>
>>>
>>> This looks OK to me in principle. I can't easily test this at the
>>> moment, but as I don't have a DT platform that has the clk framework up
>>> and running. A couple of nits/questions inline, but thanks for doing
>>> this!
>>>
>>> Jamie
>>>
>>>> ---
>>>> Documentation/devicetree/bindings/net/macb.txt | 22 ++++++++
>>>> drivers/net/ethernet/cadence/macb.c | 65 +++++++++++++++++++++---
>>>> drivers/net/ethernet/cadence/macb.h | 2 +
>>>> 3 files changed, 81 insertions(+), 8 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/net/macb.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
>>>> new file mode 100644
>>>> index 0000000..2b727ec
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/macb.txt
>>>> @@ -0,0 +1,22 @@
>>>> +* Cadence EMACB
>>>> +
>>>> +Implemeted on Atmel AT91& AVR32 SoC
>>>
>>> I think something along the lines of "Binding for the Cadence MACB
>>> Ethernet controller" rather than listing specific parts might be
>>> clearer.
>> I prefer as we will have implementation detail in the binding
>
> I can't see any Atmel specific implementation detail here though so lets
> keep it generic for now. There isn't a benefit to keeping a list of
> SoC's that the device is implemented in here as it'll only become out of
> date. We need to make it easy for other vendors to reuse the binding +
> driver.
>
>>>> + compatible = "atmel,macb";
>>>
>>> This should be "cdns,macb" as it isn't Atmel specific. I believe cdns
>>> is the correct stock ticker symbol for Cadence.
>> here I put "atmel,macb" on purpose to specify the difference of the IP between
>> the soc, in fact it should have been atmel-at91,macb
>
> Well if we really can't detect the difference from the revision register
> then we should have "cdns,macb" *and* "atmel,at91-macb" at least then
> where platforms could claim compatibility as:
>
> compatible = "atmel,at91-macb", "cdns,macb";
re-thinking about this I propose that we go for the following compatible
string for macb:
- compatible: Should be "cdns,<chip>-macb"
And as the first SoC that have embedded an emacb that is compatible with
current 10/100 AT91 usage is AVR32 at32ap7000... We may end up with
"cdns,at32ap7000-macb" compatible string. The first ones with different
synthesis parameters where at91sam9260/3 so I may also add:
"cdns,at91sam9260-macb".
Then you will have to add the first SoC that uses the gigabit version of
the macb...
What do you think about that?
BTW, "cdns" seems not included in the vendor-prefixes.txt file yet...
Bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 1/1] net/macb: add DT support
From: Jamie Iles @ 2011-12-02 15:38 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Jamie Iles, Jean-Christophe PLAGNIOL-VILLARD, devicetree-discuss,
netdev
In-Reply-To: <4ED8EF1C.80503@atmel.com>
On Fri, Dec 02, 2011 at 04:30:36PM +0100, Nicolas Ferre wrote:
> On 11/20/2011 06:11 PM, Jamie Iles :
> >On Sun, Nov 20, 2011 at 05:47:40PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>On 15:58 Fri 18 Nov , Jamie Iles wrote:
[...]
> >>>>+ compatible = "atmel,macb";
> >>>
> >>>This should be "cdns,macb" as it isn't Atmel specific. I believe cdns
> >>>is the correct stock ticker symbol for Cadence.
> >>here I put "atmel,macb" on purpose to specify the difference of the IP between
> >>the soc, in fact it should have been atmel-at91,macb
> >
> >Well if we really can't detect the difference from the revision register
> >then we should have "cdns,macb" *and* "atmel,at91-macb" at least then
> >where platforms could claim compatibility as:
> >
> > compatible = "atmel,at91-macb", "cdns,macb";
>
> re-thinking about this I propose that we go for the following
> compatible string for macb:
>
> - compatible: Should be "cdns,<chip>-macb"
>
> And as the first SoC that have embedded an emacb that is compatible
> with current 10/100 AT91 usage is AVR32 at32ap7000... We may end up
> with "cdns,at32ap7000-macb" compatible string. The first ones with
> different synthesis parameters where at91sam9260/3 so I may also
> add:
> "cdns,at91sam9260-macb".
> Then you will have to add the first SoC that uses the gigabit
> version of the macb...
> What do you think about that?
Sure, that works for me, though I guess this is a much more general
thing than this one binding, but that does make sense to me. I think
that keeping a general "cdns,macb" _too_ still makes sense though as
lots of it may well be detectable and it will probably be difficult for
one SoC vendor to know whether their IP instantiation really is the same
as another vendors... Either way I don't have a strong opinion on that.
> BTW, "cdns" seems not included in the vendor-prefixes.txt file yet...
No, that one is missing. If you want to add it then feel free, if not
I'll add it to my list of patches to do!
Jamie
^ permalink raw reply
* Re: ebtables on a stick
From: Michal Soltys @ 2011-12-02 15:40 UTC (permalink / raw)
To: Greg Scott; +Cc: David Lamparter, netdev
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A048FA@mail733.InfraSupportEtc.com>
On 11-12-01 17:56, Greg Scott wrote:
>> # ip -4 a l eth0; ip r l match 0.0.0.0; ip r l exact 10.255.255.1
>> 2: eth0:<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>> state UNKNOWN qlen 1000
>> inet 87.106.131.203/32 scope global eth0
>> default via 10.255.255.1 dev eth0
>> 10.255.255.1 dev eth0 scope link
Aside from addresses, same config I had when I was on adsl.
>
> Wow, how does that even work? Every time I think I know something, I
> get challenged. I should make that a slogan.
>
> - Greg
>
BTW:
You should be able to avoid whole proxy thing altogether (on your
router), by doing:
ip add add 1.2.115.157/32 dev eth0
ip ro del table local 192.168.99.5/32 dev eth0
ip route add 1.2.115.157/32 dev eth1
instead of:
ip neigh add proxy 1.2.115.157 dev eth0
The former will still expose the address, but it will be not routable
inside the router, so will get passed to your internal host. (this
assumes your kernel is compiled with advanced routing).
^ permalink raw reply
* Re: Bug in computing data_len in tcp_sendmsg?
From: Eric Dumazet @ 2011-12-02 15:44 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: Tom Herbert, Linux Netdev List, David Miller
In-Reply-To: <1322827188.2607.19.camel@edumazet-laptop>
Le vendredi 02 décembre 2011 à 12:59 +0100, Eric Dumazet a écrit :
> Thanks for this detailed explanation !
>
> And yes, you're probably right.
>
> Are you willing to submit a patch to fix this ?
>
> (If not, I can do it myself of course)
>
[PATCH net-next] tcp: fix tcp_trim_head()
commit f07d960df3 (tcp: avoid frag allocation for small frames)
breaked assumption in tcp stack that skb is either linear (data_len ==
0), either fully fragged (data_len == len)
Thanks to Vijay for providing a very detailed explanation.
Reported-by: Vijay Subramanian <subramanian.vijay@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_output.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 58f69ac..4a0f54a 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1093,6 +1093,13 @@ static void __pskb_trim_head(struct sk_buff *skb, int len)
{
int i, k, eat;
+ eat = min_t(int, len, skb_headlen(skb));
+ if (eat) {
+ __skb_pull(skb, eat);
+ len -= eat;
+ if (!len)
+ return;
+ }
eat = len;
k = 0;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
@@ -1124,11 +1131,7 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
return -ENOMEM;
- /* If len == headlen, we avoid __skb_pull to preserve alignment. */
- if (unlikely(len < skb_headlen(skb)))
- __skb_pull(skb, len);
- else
- __pskb_trim_head(skb, len - skb_headlen(skb));
+ __pskb_trim_head(skb, len);
TCP_SKB_CB(skb)->seq += len;
skb->ip_summed = CHECKSUM_PARTIAL;
^ permalink raw reply related
* Re: ebtables on a stick
From: David Lamparter @ 2011-12-02 16:04 UTC (permalink / raw)
To: Michal Soltys; +Cc: Greg Scott, David Lamparter, netdev
In-Reply-To: <4ED8F15D.8020909@ziu.info>
On Fri, Dec 02, 2011 at 04:40:13PM +0100, Michal Soltys wrote:
> You should be able to avoid whole proxy thing altogether (on your
> router), by doing:
>
> ip add add 1.2.115.157/32 dev eth0
> ip ro del table local 192.168.99.5/32 dev eth0
> ip route add 1.2.115.157/32 dev eth1
... and any application that looks at the local interface addresses
(e.g. ntpd, bind, etc.) will get thoroughly confused. Oh and worst-case
(i don't know/didn't check) source address selection as well.
I'd advise against it.
> instead of:
>
> ip neigh add proxy 1.2.115.157 dev eth0
-David
^ permalink raw reply
* Re: Bug in computing data_len in tcp_sendmsg?
From: Eric Dumazet @ 2011-12-02 16:05 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: Tom Herbert, Linux Netdev List, David Miller
In-Reply-To: <1322840663.2762.26.camel@edumazet-laptop>
Le vendredi 02 décembre 2011 à 16:44 +0100, Eric Dumazet a écrit :
> [PATCH net-next] tcp: fix tcp_trim_head()
>
> commit f07d960df3 (tcp: avoid frag allocation for small frames)
> breaked assumption in tcp stack that skb is either linear (data_len ==
> 0), either fully fragged (data_len == len)
>
> Thanks to Vijay for providing a very detailed explanation.
>
> Reported-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
Another problem is the possible misalignement of skb->data if/when we
receive an ACK of an odd (not a 4 multiple) tcp sequence.
So when/if packet is restransmited, tcp header (and IP header as well)
could be misaligned.
Hmm, I probably miss something obvious, since this problem could happen
for linear skbs before my patch ?
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-02 16:06 UTC (permalink / raw)
To: Michal Soltys; +Cc: David Lamparter, netdev
In-Reply-To: <4ED8F15D.8020909@ziu.info>
> You should be able to avoid whole proxy thing altogether (on your
router), by doing:
>
> ip add add 1.2.115.157/32 dev eth0
> ip ro del table local 192.168.99.5/32 dev eth0 ip route add
1.2.115.157/32 dev eth1
What's the 192.168.99.5/21 address?
- Greg
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-02 16:09 UTC (permalink / raw)
To: David Lamparter, Michal Soltys; +Cc: netdev
In-Reply-To: <20111202160442.GQ589422@jupiter.n2.diac24.net>
..and as much as I went into the proxy thing kicking and screaming, it
does seem clean and simple now that I finally did it.
The routing still has me confused - my public host is on the router's
eth1, its gateway is on eth0, but it all still works. I should probably
reboot that router at some point soon to make sure there aren't any
hidden legacies from my old bridge config left over.
- Greg
-----Original Message-----
From: David Lamparter [mailto:equinox@diac24.net]
Sent: Friday, December 02, 2011 10:05 AM
To: Michal Soltys
Cc: Greg Scott; David Lamparter; netdev@vger.kernel.org
Subject: Re: ebtables on a stick
On Fri, Dec 02, 2011 at 04:40:13PM +0100, Michal Soltys wrote:
> You should be able to avoid whole proxy thing altogether (on your
> router), by doing:
>
> ip add add 1.2.115.157/32 dev eth0
> ip ro del table local 192.168.99.5/32 dev eth0
> ip route add 1.2.115.157/32 dev eth1
... and any application that looks at the local interface addresses
(e.g. ntpd, bind, etc.) will get thoroughly confused. Oh and worst-case
(i don't know/didn't check) source address selection as well.
I'd advise against it.
> instead of:
>
> ip neigh add proxy 1.2.115.157 dev eth0
-David
^ permalink raw reply
* Re: ebtables on a stick
From: Michal Soltys @ 2011-12-02 16:16 UTC (permalink / raw)
To: Greg Scott; +Cc: David Lamparter, netdev
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A0491B@mail733.InfraSupportEtc.com>
On 11-12-02 17:06, Greg Scott wrote:
>> You should be able to avoid whole proxy thing altogether (on your
> router), by doing:
>>
>> ip add add 1.2.115.157/32 dev eth0
>> ip ro del table local 192.168.99.5/32 dev eth0 ip route add
> 1.2.115.157/32 dev eth1
>
> What's the 192.168.99.5/21 address?
>
Should be 1.2.115.157/32 (hasty copy paste).
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-02 16:20 UTC (permalink / raw)
To: Michal Soltys; +Cc: David Lamparter, netdev
In-Reply-To: <4ED8F9CC.9000308@ziu.info>
OK. But I dunno.... I set eth0 on the router with the same address as
the real host behind it on eth1. So something comes in on eth0 for
1.2.115.157. The router has that as its own address now, plus a route
to somebody else with the same address on eth1. But as far as the
router/firewall is concerned, that packet is already delivered - why
would it forward it out on eth1?
- Greg
-----Original Message-----
From: Michal Soltys [mailto:soltys@ziu.info]
Sent: Friday, December 02, 2011 10:16 AM
To: Greg Scott
Cc: David Lamparter; netdev@vger.kernel.org
Subject: Re: ebtables on a stick
On 11-12-02 17:06, Greg Scott wrote:
>> You should be able to avoid whole proxy thing altogether (on your
> router), by doing:
>>
>> ip add add 1.2.115.157/32 dev eth0
>> ip ro del table local 192.168.99.5/32 dev eth0 ip route add
> 1.2.115.157/32 dev eth1
>
> What's the 192.168.99.5/21 address?
>
Should be 1.2.115.157/32 (hasty copy paste).
^ permalink raw reply
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: "Igor Maravić" @ 2011-12-02 16:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: igorm, netdev, davem, Realtek linux nic maintainers,
Francois Romieu, Tom Herbert
In-Reply-To: <1322838687.2762.18.camel@edumazet-laptop>
>
> Quite frankly, any queued skb is eventually freed, so
> netdev_reset_queue() could be avoided.
>
If I didn't add netdev_reset_queue(), how dql would reset its parameters to 0?
I added spin_locks around netdev_completed_queue and netdev_sent_queue
[PATCH net-next] r8169: Support for byte queue limits
Changes to r8169 to use byte queue limits.
Signed-off-by: Igor Maravic <igorm@etf.rs>
---
drivers/net/ethernet/realtek/r8169.c | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index e5a6d8e..e46d4e6 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3773,6 +3773,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
static void rtl8169_init_ring_indexes(struct rtl8169_private *tp)
{
tp->dirty_tx = tp->dirty_rx = tp->cur_tx = tp->cur_rx = 0;
+ netdev_reset_queue(tp->dev);
}
static void rtl_hw_jumbo_enable(struct rtl8169_private *tp)
@@ -5422,6 +5423,7 @@ static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
unsigned int cur_frag, entry;
struct TxDesc * uninitialized_var(txd);
struct device *d = &tp->pci_dev->dev;
+ unsigned long flag;
entry = tp->cur_tx;
for (cur_frag = 0; cur_frag < info->nr_frags; cur_frag++) {
@@ -5458,6 +5460,9 @@ static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
tp->tx_skb[entry].skb = skb;
txd->opts1 |= cpu_to_le32(LastFrag);
}
+ spin_lock_irqsave(&tp->lock,flag);
+ netdev_sent_queue(tp->dev, skb->len);
+ spin_unlock_irqrestore(&tp->lock,flag);
return cur_frag;
@@ -5623,6 +5628,9 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
void __iomem *ioaddr)
{
unsigned int dirty_tx, tx_left;
+ unsigned int bytes_compl = 0;
+ int tx_compl = 0;
+ unsigned long flag;
dirty_tx = tp->dirty_tx;
smp_rmb();
@@ -5641,8 +5649,8 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
rtl8169_unmap_tx_skb(&tp->pci_dev->dev, tx_skb,
tp->TxDescArray + entry);
if (status & LastFrag) {
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += tx_skb->skb->len;
+ bytes_compl += tx_skb->skb->len;
+ tx_compl++;
dev_kfree_skb(tx_skb->skb);
tx_skb->skb = NULL;
}
@@ -5650,6 +5658,11 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
tx_left--;
}
+ dev->stats.tx_packets += tx_compl;
+ dev->stats.tx_bytes += bytes_compl;
+ spin_lock_irqsave(&tp->lock, flag);
+ netdev_completed_queue(dev, tx_compl, bytes_compl);
+ spin_unlock_irqrestore(&tp->lock, flag);
if (tp->dirty_tx != dirty_tx) {
tp->dirty_tx = dirty_tx;
smp_wmb();
--
1.7.5.4
^ permalink raw reply related
* Re: ebtables on a stick
From: Michal Soltys @ 2011-12-02 16:44 UTC (permalink / raw)
To: Greg Scott; +Cc: David Lamparter, netdev
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A0491E@mail733.InfraSupportEtc.com>
On 11-12-02 17:20, Greg Scott wrote:
> OK. But I dunno.... I set eth0 on the router with the same address as
> the real host behind it on eth1. So something comes in on eth0 for
> 1.2.115.157. The router has that as its own address now, plus a route
> to somebody else with the same address on eth1. But as far as the
> router/firewall is concerned, that packet is already delivered - why
> would it forward it out on eth1?
>
Where the packet gets delivered is decided by the routing - and the very
first table traversed is local - which is auto filled by the kernel. But
that routing rule still can be forcibly removed, after which the next
matching one is the one added manually - after which the packet will end
in FORWARD, instead of INPUT.
(and keep in mind earlier David's warning about confusing
programs/services - it's still doable, but requires more manual labor -
proxy is certianly cleaner and just works)
^ permalink raw reply
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Eric Dumazet @ 2011-12-02 16:47 UTC (permalink / raw)
To: igorm
Cc: netdev, davem, Realtek linux nic maintainers, Francois Romieu,
Tom Herbert
In-Reply-To: <6b84ddc047f72f8a66cc587a1813fbe9.squirrel@kondor.etf.bg.ac.rs>
Le vendredi 02 décembre 2011 à 17:31 +0100, "Igor Maravić" a écrit :
> >
> > Quite frankly, any queued skb is eventually freed, so
> > netdev_reset_queue() could be avoided.
> >
>
> If I didn't add netdev_reset_queue(), how dql would reset its parameters to 0?
>
They are initted at device setup.
As I said, if every transmitted skb is correctly freed (and BQL
accounted), there is no need to netdev_reset_queue()
> I added spin_locks around netdev_completed_queue and netdev_sent_queue
>
Oh well, no, dont do that. BQL must be lightweight.
^ permalink raw reply
* Re: [PATCH net-next V0 03/21] mlx4_core: Add "native" argument to mlx4_cmd and its callers (where needed)
From: Roland Dreier @ 2011-12-02 17:01 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, liranl-VPRAkNaXOzVS1MOuV/RT9w,
jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
In-Reply-To: <4ED8A591.2070705-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
On Fri, Dec 2, 2011 at 2:16 AM, Yevgeny Petrilin
<yevgenyp-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org> wrote:
> return mlx4_cmd(dev, limit_watermark, srq_num, 0, MLX4_CMD_ARM_SRQ,
> - MLX4_CMD_TIME_CLASS_B);
> + MLX4_CMD_TIME_CLASS_B, 0);
Instead of a 0 or 1 for the native parameter, can we define something like
enum {
MLX4_CMD_NATIVE,
MLX4_CMD_WRAPPED
};
so that all these calls become easier to read?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Igor Maravić @ 2011-12-02 17:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, Realtek linux nic maintainers, Francois Romieu,
Tom Herbert
In-Reply-To: <1322844451.2762.36.camel@edumazet-laptop>
>
> They are initted at device setup.
>
What about when device is reseted?
>
> Oh well, no, dont do that. BQL must be lightweight.
>
Forcedeth driver utilizes spin_locks. :)
^ permalink raw reply
* Re: [PATCH net-next V0 18/21] mlx4_core: adjust catas operation for SRIOV mode
From: Roland Dreier @ 2011-12-02 17:07 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, liranl-VPRAkNaXOzVS1MOuV/RT9w,
jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
In-Reply-To: <4ED8A62D.8080008-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
On Fri, Dec 2, 2011 at 2:19 AM, Yevgeny Petrilin
<yevgenyp-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org> wrote:
> When running in SRIOV mode, driver should not automatically start/stop
> the mlx4_core upon sensing an HCA internal error -- doing this disables/enables
> sriov, which will cause the hypervisor to hang if there are running VMs with
> attached VFs.
Not sure I understand this -- what happens if the driver doesn't reset
the device
after a catastrophic error? Surely all the VFs are pretty screwed at
that point?
Which hypervisor are we talking about here anyway?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: pull request: batman-adv 2011-11-26
From: Antonio Quartulli @ 2011-12-02 17:12 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
lindner_marek-LWAfsSFWpa4
In-Reply-To: <20111126.144122.775553783672941660.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hello David,
On Sat, Nov 26, 2011 at 02:41:22 -0500, David Miller wrote:
[CUT]
> Some things to look into:
>
> + if (unlikely(skb_headlen(skb) <
> + sizeof(struct tt_query_packet) +
> + tt_len))
>
> This isn't formatted correctly, all the leading edges should line
> up to the openning parenthesis of the unlikely:
>
> + if (unlikely(skb_headlen(skb) <
> + sizeof(struct tt_query_packet) +
> + tt_len))
>
Thank you for reporting this issue. We have already prepared a patch which is
going to be sent within the next batch.
> Next, there is a lot of linearization done by the stack, but really the
> thing to do is to make sure that the part you want to look at is
> linear.
>
> You do this using pskb_may_pull() right before you want to look at some
> headers. It makes sure that, for the length given, that many bytes are
> linear at the head of the skb.
>
For this issue, we had some problem to understand it.
First of all I think you are referring to patch 08/10, in which I moved a
skb_linearise() operation.
To be sure it is really needed, I backtracked the code flow and noted down any
eventual psbk_may_pull() (or any other linearisation operation). The result is:
=> in batman_skb_recv()
- pskb_may_pull(2)
=> in recv_tt_query()
- pskb_may_pull(sizeof(header))
- skb_linearise()
Actually it seems we haven't any useless linearisation.
Would you mind explain us where you actually found the problem, please?
It might also be that I misunderstood your advice.
Thank you.
Best Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
^ permalink raw reply
* Re: [PATCH net-next] r8169: Support for byte queue limits
From: Eric Dumazet @ 2011-12-02 17:12 UTC (permalink / raw)
To: igorm
Cc: netdev, davem, Realtek linux nic maintainers, Francois Romieu,
Tom Herbert
In-Reply-To: <CAFdo_mWtxexXXCpFZsQKAJ96ZXEnDRiBsb4zFO8oR0hc6gXPMQ@mail.gmail.com>
Le vendredi 02 décembre 2011 à 18:00 +0100, Igor Maravić a écrit :
> >
> > They are initted at device setup.
> >
>
> What about when device is reseted?
>
What happens to queued skbs ? Are they LOST ?
Think about it.
> >
> > Oh well, no, dont do that. BQL must be lightweight.
> >
>
> Forcedeth driver utilizes spin_locks. :)
No added spin_locks in BQL patch.
Reread what I said : "BQL must be lightweight"
Not : "No lock should be used"
OK ?
^ permalink raw reply
* [PATCH] net/macb: add DT support
From: Nicolas Ferre @ 2011-12-02 17:14 UTC (permalink / raw)
To: robherring2-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
netdev-u79uwXL29TY76Z2rM5mHXA, plagnioj-sclMFOaUSTBWk0Htik3J/w
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20111202153832.GA4998@totoro>
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Allow the device tree to provide the mac address and the phy mode.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
[nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org: change "compatible" node property, doc and DT hwaddr]
Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Cc: Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>
---
Documentation/devicetree/bindings/net/macb.txt | 22 +++++++
drivers/net/ethernet/cadence/macb.c | 71 +++++++++++++++++++++---
drivers/net/ethernet/cadence/macb.h | 2 +
3 files changed, 87 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/macb.txt
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
new file mode 100644
index 0000000..7f0b90a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -0,0 +1,22 @@
+* Cadence MACB Ethernet controller
+
+Required properties:
+- compatible: Should be "cdns,[<chip>-]macb"
+ Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
+ Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb"
+- reg: Address and length of the register set for the device
+- interrupts: Should contain macb interrupt
+- phy-mode: String, operation mode of the PHY interface.
+ Supported values are: "mii", "rmii", "gmii", "rgmii".
+
+Optional properties:
+- local-mac-address: 6 bytes, mac address
+
+Examples:
+
+ macb0: ethernet@fffc4000 {
+ compatible = "cdns,at32ap7000-macb";
+ reg = <0xfffc4000 0x4000>;
+ interrupts = <21>;
+ phy-mode = "rmii";
+ };
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 64d6146..103c6e6 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -23,6 +23,8 @@
#include <linux/platform_data/macb.h>
#include <linux/platform_device.h>
#include <linux/phy.h>
+#include <linux/of_device.h>
+#include <linux/of_net.h>
#include "macb.h"
@@ -191,7 +193,6 @@ static int macb_mii_probe(struct net_device *dev)
{
struct macb *bp = netdev_priv(dev);
struct phy_device *phydev;
- struct macb_platform_data *pdata;
int ret;
phydev = phy_find_first(bp->mii_bus);
@@ -200,14 +201,11 @@ static int macb_mii_probe(struct net_device *dev)
return -1;
}
- pdata = bp->pdev->dev.platform_data;
/* TODO : add pin_irq */
/* attach the mac to the phy */
ret = phy_connect_direct(dev, phydev, &macb_handle_link_change, 0,
- pdata && pdata->is_rmii ?
- PHY_INTERFACE_MODE_RMII :
- PHY_INTERFACE_MODE_MII);
+ bp->phy_interface);
if (ret) {
netdev_err(dev, "Could not attach to PHY\n");
return ret;
@@ -1244,6 +1242,50 @@ static const struct net_device_ops macb_netdev_ops = {
#endif
};
+#if defined(CONFIG_OF)
+static const struct of_device_id macb_dt_ids[] = {
+ { .compatible = "cdns,at32ap7000-macb" },
+ { .compatible = "cdns,at91sam9260-macb" },
+ { .compatible = "cdns,macb" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, macb_dt_ids);
+
+static int __devinit macb_get_phy_mode_dt(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+
+ if (np)
+ return of_get_phy_mode(np);
+
+ return -ENODEV;
+}
+
+static int __devinit macb_get_hwaddr_dt(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ if (np) {
+ const char *mac = of_get_mac_address(np);
+ if (mac) {
+ memcpy(pdev->dev->dev_addr, mac, ETH_ALEN);
+ return 0;
+ }
+ }
+
+ return -ENODEV;
+}
+#else
+static int __devinit macb_get_phy_mode_dt(struct platform_device *pdev)
+{
+ return -ENODEV;
+}
+static int __devinit macb_get_hwaddr_dt(struct platform_device *pdev)
+{
+ return -ENODEV;
+}
+#endif
+
static int __init macb_probe(struct platform_device *pdev)
{
struct macb_platform_data *pdata;
@@ -1318,10 +1360,22 @@ static int __init macb_probe(struct platform_device *pdev)
config |= macb_dbw(bp);
macb_writel(bp, NCFGR, config);
- macb_get_hwaddr(bp);
- pdata = pdev->dev.platform_data;
+ err = macb_get_hwaddr_dt(pdev);
+ if (err < 0)
+ macb_get_hwaddr(bp);
+
+ err = macb_get_phy_mode_dt(pdev);
+ if (err < 0) {
+ pdata = pdev->dev.platform_data;
+ if (pdata && pdata->is_rmii)
+ bp->phy_interface = PHY_INTERFACE_MODE_RMII;
+ else
+ bp->phy_interface = PHY_INTERFACE_MODE_MII;
+ } else {
+ bp->phy_interface = err;
+ }
- if (pdata && pdata->is_rmii)
+ if (bp->phy_interface == PHY_INTERFACE_MODE_RMII)
#if defined(CONFIG_ARCH_AT91)
macb_or_gem_writel(bp, USRIO, (MACB_BIT(RMII) |
MACB_BIT(CLKEN)));
@@ -1444,6 +1498,7 @@ static struct platform_driver macb_driver = {
.driver = {
.name = "macb",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(macb_dt_ids),
},
};
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 1931078..335e288 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -532,6 +532,8 @@ struct macb {
unsigned int link;
unsigned int speed;
unsigned int duplex;
+
+ phy_interface_t phy_interface;
};
static inline bool macb_is_gem(struct macb *bp)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] net/macb: add DT support
From: Jamie Iles @ 2011-12-02 17:28 UTC (permalink / raw)
To: Nicolas Ferre
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1322846050-4543-1-git-send-email-nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Hi Nicolas,
On Fri, Dec 02, 2011 at 06:14:10PM +0100, Nicolas Ferre wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
>
> Allow the device tree to provide the mac address and the phy mode.
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> [nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org: change "compatible" node property, doc and DT hwaddr]
> Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> Cc: Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>
Looks nice to me. There's a patch below to add the GEM stuff to the
binding too if you want to role that in.
Acked-by: Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>
8<----
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 7f0b90a..e09e3fb 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -1,9 +1,11 @@
-* Cadence MACB Ethernet controller
+* Cadence MACB/GEM Ethernet controller
Required properties:
-- compatible: Should be "cdns,[<chip>-]macb"
+- compatible: Should be "cdns,[<chip>-]{macb,gem}"
Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb"
+ Use "cnds,pc302-gem" for Picochip picoXcell pc302 and later devices based on
+ the Cadence GEM, or the generic form "cdns,gem".
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
- phy-mode: String, operation mode of the PHY interface.
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 103c6e6..89060e6 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1247,6 +1247,8 @@ static const struct of_device_id macb_dt_ids[] = {
{ .compatible = "cdns,at32ap7000-macb" },
{ .compatible = "cdns,at91sam9260-macb" },
{ .compatible = "cdns,macb" },
+ { .compatible = "cdns,pc302-gem" },
+ { .compatible = "cdns,gem" },
{ /* sentinel */ }
};
^ 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