* Re: [PATCH 1/1] tun: change speed from 10M to dynamically configured
From: yzhu1 @ 2015-02-13 2:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, mst, jasowang, viro, davem
In-Reply-To: <20150212045558.5091262a@uryu.home.lan>
On 02/12/2015 08:55 PM, Stephen Hemminger wrote:
> On Thu, 12 Feb 2015 13:35:23 +0800
> Zhu Yanjun <Yanjun.Zhu@windriver.com> wrote:
>
>> From: Zhu Yanjun <yanjun.zhu@windriver.com>
>>
>> The default speed of normal nic is 1000M while the default speed
>> of tun is 10M. Now the default speed of tun is changed to 1000M.
>> And there are 3 options: 10M, 100M and 1000M to the speed of tun.
>> The command "ethtool -s tun0 speed 10/100/1000" can configure the
>> speed of tun dynamically.
>>
>> CC: Michael S. Tsirkin <mst@redhat.com>
>> CC: Jason Wang <jasowang@redhat.com>
>> CC: Al Viro <viro@zeniv.linux.org.uk>
>> Signed-off-by: Zhu Yanjun <yanjun.zhu@windriver.com>
>> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
> Why limit to 10/100/1000 speed?
> Ethtool speed can be any value
Thanks for your comments.
Yes. But the real physical nic speed often 10M, 100M and 1000M.
This simulates the physical nic.
Zhu Yanjun
>
>>
>
>
^ permalink raw reply
* Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"
From: Linus Walleij @ 2015-02-13 2:16 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Nicolas Pitre, David S. Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1423760350-20149-1-git-send-email-robert.jarzmik@free.fr>
On Fri, Feb 13, 2015 at 12:59 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> The commit breaks the legacy platforms, ie. these not using device-tree,
> and setting up the interrupt resources with a flag to activate edge
> detection. The issue was found on the zylonite platform.
>
> The reason is that zylonite uses platform resources to pass the interrupt number
> and the irq flags (here IORESOURCE_IRQ_HIGHEDGE). It expects the driver to
> request the irq with these flags, which in turn setups the irq as high edge
> triggered.
>
> After the patch, this was supposed to be taken care of with :
> irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));
>
> But irq_resflags is 0 for legacy platforms, while for example in
> arch/arm/mach-pxa/zylonite.c, in struct resource smc91x_resources[] the
> irq flag is specified. This breaks zylonite because the interrupt is not
> setup as triggered, and hardware doesn't provide interrupts.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
But isn't the real problem that in the device tree case,
irq_get_irq_data(ndev->irq) will work becaus parsing an interrupt
from the device tree populates it correctly in platform_get_irq()
whereas for the legacy lookup it just fetches the number.
So to me it seems like a weakness in the platform_get_irq()
helper altogether.
Does the following work? (I can send as a separate patch for
testing if you like).
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9421fed40905..301f4b9ae908 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -101,6 +101,15 @@ int platform_get_irq(struct platform_device *dev,
unsigned int num)
}
r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+ /*
+ * The resources may pass trigger flags to the irqs that need
+ * to be set up. It so happens that the trigger flags for
+ * IORESOURCE_BITS correspond 1-to-1 to the IRQF_TRIGGER*
+ * settings.
+ */
+ if (r->flags & IORESOURCE_BITS)
+ irqd_set_trigger_type(irq_get_irq_data(r->start),
+ r->flags & IORESOURCE_BITS);
Yours,
Linus Walleij
^ permalink raw reply related
* [PATCH net-next v2] ipv6: fix ipv6_cow_metrics for non DST_HOST case
From: Martin KaFai Lau @ 2015-02-13 0:14 UTC (permalink / raw)
To: netdev, Hannes Frederic Sowa; +Cc: davem, Kernel Team
In-Reply-To: <1423771650-870555-1-git-send-email-kafai@fb.com>
ipv6_cow_metrics() currently assumes only DST_HOST routes require
dynamic metrics allocation from inetpeer. The assumption breaks
when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric.
Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set()
is called after the route is created.
This patch creates the metrics array (by calling dst_cow_metrics_generic) in
ipv6_cow_metrics().
Test:
radvd.conf:
interface qemubr0
{
AdvLinkMTU 1300;
AdvCurHopLimit 30;
prefix fd00:face:face:face::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
Before:
[root@qemu1 ~]# ip -6 r show | egrep -v unreachable
fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec
After:
[root@qemu1 ~]# ip -6 r show | egrep -v unreachable
fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec mtu 1300
fe80::/64 dev eth0 proto kernel metric 256 mtu 1300
default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec mtu 1300 hoplimit 30
Fixes: 8e2ec639173f325 (ipv6: don't use inetpeer to store metrics for routes.)
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 98565ce..4688bd4 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -141,7 +141,7 @@ static u32 *ipv6_cow_metrics(struct dst_entry *dst, unsigned long old)
u32 *p = NULL;
if (!(rt->dst.flags & DST_HOST))
- return NULL;
+ return dst_cow_metrics_generic(dst, old);
peer = rt6_get_peer_create(rt);
if (peer) {
--
1.8.1
^ permalink raw reply related
* RE: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Brown, Aaron F @ 2015-02-12 23:28 UTC (permalink / raw)
To: Kirsher, Jeffrey T, Thomas Jarosch
Cc: 'Linux Netdev List', Eric Dumazet, e1000-devel
In-Reply-To: <1423654440.27854.83.camel@jtkirshe-mobl>
> From: Kirsher, Jeffrey T
> Sent: Wednesday, February 11, 2015 3:34 AM
> To: Thomas Jarosch; Brown, Aaron F
> Cc: 'Linux Netdev List'; Eric Dumazet; e1000-devel
> Subject: Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
>
> On Wed, 2015-02-11 at 12:23 +0100, Thomas Jarosch wrote:
> > Hi Jeff,
> >
> > On Thursday, 15. January 2015 06:59:13 Jeff Kirsher wrote:
> > > > Sure, you basically reverted my patch.
> > > >
> > > > You are not the first to report a problem caused by this patch.
> > > >
> > > > This patch is known to have uncovered some driver bugs.
> > > >
> > > > We are not going to revert it. We are going to fix the real bugs.
> > > >
> > > > Thanks
> > >
> > > Agreed, we are looking into issue Thomas.
> >
> > any news from the Intel labs what might be going on here?
> >
> > We started seeing those hangs on "MSI B85M ECO" boards, too,
> > though it's way more sporadic there.
>
> I have not heard anything, so I have added Aaron Brown to see if he has
> any additional information.
I do not have any real info. I had been asked to try and reproduce some unit hangs (maybe for this) recently and did not succeed in producing them on the parts I have. Reading through the thread I see this is showing up in a NAT environment. The port that is getting the unit hang in the NAT system?
I will make some attempts at replicating this with the port in a NAT and or forwarding role. Has a bug been opened for this? Or has information for this specific unit hang been entered into one of the other unit hang bugs opened against e1000e?
^ permalink raw reply
* Wifi outside the faraday cage (was: Throughput regression with `tcp: refine TSO autosizing`)
From: Dave Taht @ 2015-02-12 22:14 UTC (permalink / raw)
To: Michal Kazior
Cc: Eric Dumazet, Neal Cardwell, Eyal Perry, netdev@vger.kernel.org,
linux-wireless, David Lang, Andrew McGregor
On Fri, Feb 6, 2015 at 1:57 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 5 February 2015 at 20:50, Dave Taht <dave.taht@gmail.com> wrote:
> [...]
>> And I really, really, really wish, that just once during this thread,
>> someone had bothered to try running a test
>> at a real world MCS rate - say MCS1, or MCS4, and measured the latency
>> under load of that...
>
> Time between frame submission to firmware and tx-completion on one of
> my ath10k machines:
THANK YOU for running these tests!
>
> Legacy 54mbps: ~18ms
> Legacy 6mbps: ~37ms
"legacy rates" are what many people actually achieve, given the
limited market penetration ac has on clients and APs.
> 11n MCS 3 (nss=0): ~13ms
> 11n MCS 8 (nss=1): ~6-8ms
> 11ac NSS=1 MCS=2: ~4-6ms
> 11ac NSS=2 MCS=0: ~5-8ms
>
> Keep in mind this is a clean room environment so retransmissions are
> kept at minimum. Obviously with a noisy environment you'll get retries
> at different rates and higher latency.
It is difficult to reconcile the results you get in the clean room
with the results I get from measurements in the real wold. I encourage
you to go test your code in coffee shops, in offices with wifi, and in
hotels and apartment buildings in preference to testing in the lab.
I typically measure induced delays in the 3 to 6 second range in your
typical conference scenario, which I measure at every conference I go
to. The latest talk, including data on that, is friday morning,
starting at 2:15 or so, at nznog:
http://new.livestream.com/i-filmservices/NZNOG2015/videos/75358960
1) In the real world, I rarely see the maximum *rates*.
I am personally quite fond of designing stuff with gears out of the
middle of the Boston Gear Catalog. [1]. In looking over my largely
outdoor wifi network, I see a cluster of values around mcs11,
followed\by mcs4,3, 7 and 0, and *nothing* with MCS15. David lang is
planning on doing some measurements at the SCALE conference next week,
and I expect heaps of data from that, but I strongly suspect that the
vast majority of connections in every circumstance except the
test-bench are not even coming close to the maximum MCS rate in the
standard(s).
I would have thought that the lessons of the chromecast, where *every*
attempt at reviewing it in an office environment failed, might have
supplied industry clue that even 20Mbit to a given station is
impossible in many cases due to airtime contention.
Aggregates should be sized to have a maximum of 2 full ones stacked up
at the rate being achieved for the destination, and the rest
backlogged in the qdisc layer, if possible. 37ms backed up in the
firmware is a lot, considering that the test above had no airtime
contention in it, and no multicast.
Drivers need to be aware that every TXOP is precious. I could see
having a watchdog timer set on getting one packet into a wifi driver
to wait a few hundred usec longer to fire off the write to the
hardware in order to maximize aggregation by accumulating more packets
to aggregate.
I have hopes for xmit_more also being useful, but I am really not sure
how well that works on single cores, interactions with napi, and with
other wifi aggregates. It looks like adding xmit_more to the ag71xx
driver will be easy...
2) In the real world I see media acquisition times *far* greater than 1ms.
Please feel free to test your drivers in coffee shops, in the office,
at hotels, in apartments...
And retries... let's not talk about retries...
3) Longer AMPDUs lead to more tail loss and retries
I have a paper around here somewhere that shows AMPDU loss and retries
go up disproportionately as the length of transmission approaches 4ms.
I hate drawing a conclusion from a paper I can't find, but my overall
take on it is that as media acquisition time and retransmits go up,
reducing AMPDU size from the maximum down to about 1ms at the current
rate would lead to more fair, responsive, and fast-feeling wifi for
everyone, improve ack clocking, flow mixing for web traffic, etc, etc.
4) There is some fairly decent academic work on other aspects of
excessive buffering at lower rates
http://hph16.uwaterloo.ca/~bshihada/publications/buffer-AMPDU.pdf
(there are problems with this paper, but at least it tests n)
and see google scholar for bufferbloat related papers in 2014 and
later on wifi and LTE.
5) As for rate control, Minstrel was designed in an era when there
wasn't one AP for every 4 people in the USA. Other people's rate
controllers are even dumber, and minstrel-ht itself needs a hard look
at n speeds, much less ac speeds.
6) Everything I say above applies to both stations and APs.
APs have FAR worse problems, where per-tid (station) queuing is really
needed in order to effectively aggregate when two or more stations are
in use. Statistically, with two or more stations using traffic,
aggregation possibilities will go down rapidly on a FIFO, (and go down
even faster with FQ in place without per sta queuing!), and with the
usual fixed buffersize underneath that, without per-tid queuing, this
grows the delays enormously, and wastes space in txops.
(please try the netperf-wrapper RTT_Fair tests on 2 or more stations.
Add in some multicast traffic while you are at it.
Some early tests I did of the ath10k showed it going from 600mbit to
20mbit - at full rate in a lab with the stations located 2m away - on
a 4-station test. Somewhere around there I gave up on wifi and worked
on refining "cake" instead.)
There are a zillion other things that can be improved in wifi, some of
which I've already pointed to in the ieee talk, and the original
thread forked with andrew mcgregor pitching in as to what can be
improved in minstrel. [2]
Wifi does not need to suck as bad as it does at mid to low rates and
under contention. I find it really depressing that a technology that
has billions of users, has so few people working on making it better.
I hope to be able to spend some time on it myself, finally, starting
in april.
[1] https://books.google.com/books?id=7papZR4oVssC&pg=PA101&lpg=PA101&dq=feynman+gears&source=bl&ots=etPYearM00&sig=9R0R88rOfAxm_U21mMLOwxO6Mfg&hl=en&sa=X&ei=cjfcVM2VDY_XoASYiYCwDg&ved=0CDYQ6AEwBg#v=onepage&q=feynman%20gears&f=false
[2] Other fork of this thread:
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2015-February/004001.html
>
> Michał
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
^ permalink raw reply
* Re: [PATCH next v3 2/6] bonding: implement bond_poll_controller()
From: Jay Vosburgh @ 2015-02-12 21:45 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Andy Gospodarek, Veaceslav Falico, Nikolay Aleksandrov,
David Miller, Maciej Zenczykowski, netdev, Eric Dumazet
In-Reply-To: <1423715065-9304-1-git-send-email-maheshb@google.com>
Mahesh Bandewar <maheshb@google.com> wrote:
>This patches implements the poll_controller support for all
>bonding driver. If the slaves have poll_controller net_op defined,
>this implementation calls them. This is mode agnostic implementation
>and iterates through all slaves (based on mode) and calls respective
>handler.
>
>Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>---
>v1:
> Initial version
>v2:
> Eliminate bool variable.
>v3:
> Rebase
>
> drivers/net/bonding/bond_3ad.c | 24 ++++++++++++++++++++++++
> drivers/net/bonding/bond_main.c | 33 +++++++++++++++++++++++++++++++++
> include/net/bond_3ad.h | 1 +
> 3 files changed, 58 insertions(+)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index 9b436696b95e..14f2ebe786c5 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -2477,6 +2477,30 @@ int bond_3ad_get_active_agg_info(struct bonding *bond, struct ad_info *ad_info)
> return ret;
> }
>
>+#define BOND_3AD_PORT_OPERATIONAL \
>+ (AD_STATE_DISTRIBUTING | AD_STATE_COLLECTING | \
>+ AD_STATE_SYNCHRONIZATION | AD_STATE_AGGREGATION)
>+
>+static int bond_3ad_port_operational(struct slave *slave)
>+{
>+ port_t *port = &SLAVE_AD_INFO(slave)->port;
>+
>+ return bond_slave_can_tx(slave) &&
>+ (port->actor_oper_port_state & port->partner_oper.port_state &
>+ BOND_3AD_PORT_OPERATIONAL) == BOND_3AD_PORT_OPERATIONAL;
>+}
>+
>+/* bond_3ad_port_is_active - check if a slave port is active or not. A port
>+ * is active when it can forward traffic.
>+ *
>+ * @slave: slave port to check state for.
>+ * Returns: 0 if not active else is active.
>+ */
>+int bond_3ad_port_is_active(struct slave *slave)
>+{
>+ return bond_3ad_port_operational(slave);
>+}
>+
Why the nesting here? I don't see other users of
bond_3ad_port_operational, so why not move that logic to
bond_3ad_port_is_active and eliminate the extra level of function call?
Also, the test in bond_3ad_port_operational will exclude the
case that the active agg port is Individual (e.g., link partner is not
LACP-capable) as that case won't run the state machine to coll-dist
state, but the agg is still available for TX/RX.
-J
> int bond_3ad_lacpdu_recv(const struct sk_buff *skb, struct bonding *bond,
> struct slave *slave)
> {
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index b979c265fc51..8433fe464f95 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -928,6 +928,39 @@ static inline void slave_disable_netpoll(struct slave *slave)
>
> static void bond_poll_controller(struct net_device *bond_dev)
> {
>+ struct bonding *bond = netdev_priv(bond_dev);
>+ struct slave *slave = NULL;
>+ struct list_head *iter;
>+ struct ad_info ad_info;
>+ struct netpoll_info *ni;
>+ const struct net_device_ops *ops;
>+
>+ if (BOND_MODE(bond) == BOND_MODE_8023AD)
>+ if (bond_3ad_get_active_agg_info(bond, &ad_info))
>+ return;
>+
>+ bond_for_each_slave(bond, slave, iter) {
>+ ops = slave->dev->netdev_ops;
>+ if (!bond_slave_is_up(slave) || !ops->ndo_poll_controller)
>+ continue;
>+
>+ if (BOND_MODE(bond) == BOND_MODE_8023AD) {
>+ struct aggregator *agg =
>+ SLAVE_AD_INFO(slave)->port.aggregator;
>+
>+ if (agg && agg->aggregator_identifier !=
>+ ad_info.aggregator_id)
>+ continue;
>+ if (!bond_3ad_port_is_active(slave) || ad_info.ports != 1)
>+ continue;
The above will exclude slaves that are in an aggregator with
more than one member, which is likely to be the usual case. Is that
intentional?
Also, if this will only accept slaves from the active
aggregator, and we're limiting it to case that the active agg has
exactly one slave, why do we need to loop through all slaves of the
bond? Could we do something (inside an "if (mode == 8023AD)" block)
like:
first_slave = bond_first_slave_rcu(bond);
[...]
agg = __get_active_agg(&(SLAVE_AD_INFO(first_slave)->aggregator));
if (agg->num_of_ports != 1)
return;
slave = agg->lag_ports->slave;
if (!bond_3ad_port_is_active(slave)
return;
[...]
ops->ndo_poll_controller(slave->dev);
That would need some checks, but, basically, go from the active
aggregator directly to its list of slaves.
-J
>+ }
>+
>+ ni = rcu_dereference_bh(slave->dev->npinfo);
>+ if (down_trylock(&ni->dev_lock))
>+ continue;
>+ ops->ndo_poll_controller(slave->dev);
>+ up(&ni->dev_lock);
>+ }
> }
>
> static void bond_netpoll_cleanup(struct net_device *bond_dev)
>diff --git a/include/net/bond_3ad.h b/include/net/bond_3ad.h
>index f04cdbb7848e..6c455c646d61 100644
>--- a/include/net/bond_3ad.h
>+++ b/include/net/bond_3ad.h
>@@ -278,5 +278,6 @@ int bond_3ad_lacpdu_recv(const struct sk_buff *skb, struct bonding *bond,
> struct slave *slave);
> int bond_3ad_set_carrier(struct bonding *bond);
> void bond_3ad_update_lacp_rate(struct bonding *bond);
>+int bond_3ad_port_is_active(struct slave *slave);
> #endif /* _NET_BOND_3AD_H */
>
>--
>2.2.0.rc0.207.ga3a616c
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [RFC PATCH net-next] ipv6: fix ipv6_cow_metrics for non DST_HOST case
From: Martin Lau @ 2015-02-12 21:39 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, davem, Kernel Team
In-Reply-To: <1423776759.3051.5.camel@stressinduktion.org>
On Thu, Feb 12, 2015 at 04:32:39PM -0500, Hannes Frederic Sowa wrote:
> This fixes 8e2ec639173f325 ("ipv6: don't use inetpeer to store metrics
> for routes.")?
Correct. I will add the 'Fixes' tag and repost.
Thanks!
--Martin
^ permalink raw reply
* Re: [RFC PATCH net-next] ipv6: fix ipv6_cow_metrics for non DST_HOST case
From: Hannes Frederic Sowa @ 2015-02-12 21:32 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: netdev, davem, Kernel Team
In-Reply-To: <1423771650-870555-1-git-send-email-kafai@fb.com>
Hi,
On Do, 2015-02-12 at 12:07 -0800, Martin KaFai Lau wrote:
> ipv6_cow_metrics() currently assumes only DST_HOST routes require
> dynamic metrics allocation from inetpeer. The assumption breaks
> when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric.
> Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set()
> is called after the route is created.
>
> This patch creates the metrics array (by calling dst_cow_metrics_generic) in
> ipv6_cow_metrics().
>
> Test:
> radvd.conf:
> interface qemubr0
> {
> AdvLinkMTU 1300;
> AdvCurHopLimit 30;
>
> prefix fd00:face:face:face::/64
> {
> AdvOnLink on;
> AdvAutonomous on;
> AdvRouterAddr off;
> };
> };
>
> Before:
> [root@qemu1 ~]# ip -6 r show | egrep -v unreachable
> fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec
> fe80::/64 dev eth0 proto kernel metric 256
> default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec
>
> After:
> [root@qemu1 ~]# ip -6 r show | egrep -v unreachable
> fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec mtu 1300
> fe80::/64 dev eth0 proto kernel metric 256 mtu 1300
> default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec mtu 1300 hoplimit 30
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Looks good to me.
This fixes 8e2ec639173f325 ("ipv6: don't use inetpeer to store metrics
for routes.")?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 4/7] ebpf: extend program type/subsystem registration
From: Daniel Borkmann @ 2015-02-12 21:06 UTC (permalink / raw)
To: Alexei Starovoitov, Thomas Graf
Cc: Jiří Pírko, Network Development
In-Reply-To: <CAMEtUuxwdk8RDbUbo8SO9zMU2ELgf-xZynEeT5i5JBNLc2Y_Hw@mail.gmail.com>
On 02/11/2015 02:37 AM, Alexei Starovoitov wrote:
...
> My concern that if we allow modules to register new program
> types we allow bypass of gpl and all safety checks we've
> put in place.
Right, I share this concern. That requires to make helper functions
generic enough and shareable among various ebpf users, but that should
be possible, so as mentioned in the other mail, the cls program type
reusing sock_filter_ops is a good way forward.
Thanks for the review!
^ permalink raw reply
* Re: [PATCH net-next 7/7] cls_bpf: add initial eBPF support for programmable classifiers
From: Daniel Borkmann @ 2015-02-12 20:46 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Jiří Pírko, Network Development
In-Reply-To: <CAMEtUuzAeukNAynQtMbjLYQcB+kxM+XaFFsB1tvrHjxUskJdZw@mail.gmail.com>
On 02/11/2015 03:16 AM, Alexei Starovoitov wrote:
...
> 2.
> in core/filter.c do:
> bpf_register_prog_type(&sock_type);
> bpf_register_prog_type(&cls_type);
> static struct bpf_prog_type_list cls_type = {
> .ops = &sock_filter_ops,
> .type = BPF_PROG_TYPE_SCHED_CLS,
> };
Yes, that's fine by me. That way, we'll also preserve ABI compatibility when
we decide to diverge from the current socket filter functionality.
^ permalink raw reply
* Re: [PATCH net-next 3/7] ebpf: check first for MAXINSNS in bpf_prog_load
From: Daniel Borkmann @ 2015-02-12 20:43 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Jiří Pírko, Network Development
In-Reply-To: <CAMEtUuxatiqWCGeNmKEXHRFR=68L9=SnpYrnzQm-+WnRzGvtzg@mail.gmail.com>
On 02/11/2015 02:21 AM, Alexei Starovoitov wrote:
...
> So if user specified 'my_ultra_long_proprietery_license'
> that should be fine. The program should still be accepted
> and marked as non-gpl.
Yep, true. Most likely I'll drop this one for non-RFC anyway
as it's not much of value. ;)
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: Fix key serialization.
From: Pravin Shelar @ 2015-02-12 20:41 UTC (permalink / raw)
To: Joe Stringer; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CANr6G5yyTRwwvgzB-eZE0-7UDP_P31+RQvYe0oWZh=prTStSMw@mail.gmail.com>
On Thu, Feb 12, 2015 at 11:02 AM, Joe Stringer <joestringer@nicira.com> wrote:
> On 12 February 2015 at 09:58, Pravin B Shelar <pshelar@nicira.com> wrote:
>> Fix typo where mask is used rather than key.
>>
>> Fixes: 74ed7ab9264("openvswitch: Add support for unique flow IDs.")
>> Reported-by: Joe Stringer <joestringer@nicira.com>
>> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
>> ---
>
> Thanks for looking into this. So in general we zero-initialize the
> key, but not the mask---then use the key to determine which parts of
> the key (or mask) to serialize?
>
Mask is also initialized in ovs_match_init().
> This fixes the problem I was seeing.
>
> Acked-by: Joe Stringer <joestringer@nicira.com>
Thanks.
^ permalink raw reply
* Re: [PATCH bluetooth-next v3] ieee802154: fix netns settings
From: Marcel Holtmann @ 2015-02-12 20:34 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: Alexander Aring, Network Development, David S. Miller
In-Reply-To: <1423156890-13382-1-git-send-email-nicolas.dichtel@6wind.com>
Hi Nicolas,
> 6LoWPAN currently doesn't supports x-netns and works only in init_net.
>
> With this patch, we ensure that:
> - the wpan interface cannot be moved to another netns;
> - the 6lowpan interface cannot be moved to another netns;
> - the wpan interface is in the same netns than the 6lowpan interface;
> - the 6lowpan interface is in init_net.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Acked-by: Alexander Aring <alex.aring@gmail.com>
> ---
>
> Note: only compile tested.
>
> v3: rebase on head of bluetooth-next
> add the Acked-by line
>
> v2: update patch title
> rebase the patch on bluetooth-next
> update flag features in cfg802154_netdev_notifier_call
>
> net/ieee802154/6lowpan/core.c | 6 ++++--
> net/ieee802154/core.c | 1 +
> 2 files changed, 5 insertions(+), 2 deletions(-)
patch has been applied bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: btcoex subsystem
From: Marcel Holtmann @ 2015-02-12 20:28 UTC (permalink / raw)
To: Kalle Valo
Cc: Larry Finger, linux-wireless, Troy Tan, netdev, linux-bluetooth
In-Reply-To: <874mr3xjnx.fsf_-_@kamboji.qca.qualcomm.com>
Hi Kalle,
>>> I will work on combining the latest BT drivers from Realtek with
>>> btusb to see if I can achieve a patch that will both work with the
>>> Realtek hardware, and get approval from the reviewers.
>>>
>>> What would be an approved method of communicating between two kernel
>>> modules? Is there some example in the kernel that I could study?
>>
>> We need a btcoex subsystem that both WiFi and Bluetooth can register
>> to and communicate with.
>
> The need for this seems to periodically come up, I remember needing
> something like that back in the Maemo wl1251 days and also ath6kl needed
> this. Are there any ideas for this subsystem? How would this btcoex
> subsystem work? What kind of information would it provide?
>
> Is this something we should discuss at Ottawa?
sadly something came up and I am not making it to Ottawa. However we should be talking about this at some point since Bluetooth has MWS for its coexistence which could be a good starting point. Something we have to look into for the Bluetooth subsystem at some point.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH net-next 6/7] ebpf: remove CONFIG_BPF_SYSCALL ifdefs in socket filter code
From: Daniel Borkmann @ 2015-02-12 20:09 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Jiří Pírko, Network Development
In-Reply-To: <CAMEtUuzruMSO7zwhYLfVdO0=YN_dJ+pLAoEg_pCVT8FT=DRz_Q@mail.gmail.com>
On 02/11/2015 02:51 AM, Alexei Starovoitov wrote:
...
> why move the functions inside filter.c ?
> couldn't we just remove two lines with #ifdef/endif ?
Yep, will do in the non-RFC. That should make it shorter.
^ permalink raw reply
* [RFC PATCH net-next] ipv6: fix ipv6_cow_metrics for non DST_HOST case
From: Martin KaFai Lau @ 2015-02-12 20:07 UTC (permalink / raw)
To: netdev; +Cc: Hannes Frederic Sowa, davem, Kernel Team
ipv6_cow_metrics() currently assumes only DST_HOST routes require
dynamic metrics allocation from inetpeer. The assumption breaks
when ndisc discovered router with RTAX_MTU and RTAX_HOPLIMIT metric.
Refer to ndisc_router_discovery() in ndisc.c and note that dst_metric_set()
is called after the route is created.
This patch creates the metrics array (by calling dst_cow_metrics_generic) in
ipv6_cow_metrics().
Test:
radvd.conf:
interface qemubr0
{
AdvLinkMTU 1300;
AdvCurHopLimit 30;
prefix fd00:face:face:face::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
Before:
[root@qemu1 ~]# ip -6 r show | egrep -v unreachable
fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec
After:
[root@qemu1 ~]# ip -6 r show | egrep -v unreachable
fd00:face:face:face::/64 dev eth0 proto kernel metric 256 expires 27sec mtu 1300
fe80::/64 dev eth0 proto kernel metric 256 mtu 1300
default via fe80::74df:d0ff:fe23:8ef2 dev eth0 proto ra metric 1024 expires 27sec mtu 1300 hoplimit 30
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 98565ce..4688bd4 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -141,7 +141,7 @@ static u32 *ipv6_cow_metrics(struct dst_entry *dst, unsigned long old)
u32 *p = NULL;
if (!(rt->dst.flags & DST_HOST))
- return NULL;
+ return dst_cow_metrics_generic(dst, old);
peer = rt6_get_peer_create(rt);
if (peer) {
--
1.8.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] NFC: Add ACPI support for NXP PN544
From: Uwe Kleine-König @ 2015-02-12 19:26 UTC (permalink / raw)
To: Robert Dolca
Cc: linux-nfc, Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
linux-kernel, linux-wireless, netdev, David S. Miller,
Berg Johannes, Clement Perrochaud
In-Reply-To: <20150212174843.GA4007@rdolca-desk.ger.corp.intel.com>
Hello Robert,
On Thu, Feb 12, 2015 at 07:48:43PM +0200, Robert Dolca wrote:
> On Thu, Feb 12, 2015 at 09:14:59AM +0100, Uwe Kleine-König wrote:
> > On Mon, Jan 26, 2015 at 01:13:37PM +0200, Robert Dolca wrote:
> > > + /* Get EN GPIO from ACPI */
> > > + gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
> > Actually devm_gpiod_get_index takes 4 arguments. In your case you should
> > also pass GPIOD_OUT_LOW, then you can skip the gpiod_direction_output
> > part below.
> >
> > > + if (IS_ERR(gpiod_en)) {
> > > + nfc_err(dev,
> > > + "Unable to get EN GPIO\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + phy->gpio_en = desc_to_gpio(gpiod_en);
> > Why don't you save a reference to the gpiod instead? Mixing usage of raw
> > and gpiod might result in surprising results. For example
> >
> > gpiod_direction_output(gpiod_en, 0);
> >
> > might actually have the same result as
> >
> > gpio_direction_output(gpio_en, 1);
> >
> > if the matching gpio is marked as active low.
> >
> > > +
> > > + /* Configuration EN GPIO */
> > > + ret = gpiod_direction_output(gpiod_en, 0);
> > > + if (ret) {
> > > + nfc_err(dev, "Fail EN pin direction\n");
> > > + return ret;
> > > + }
> > > +
> > > + /* Get FW GPIO from ACPI */
> > > + gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
> > > + if (IS_ERR(gpiod_fw)) {
> > > + nfc_err(dev,
> > > + "Unable to get FW GPIO\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + phy->gpio_fw = desc_to_gpio(gpiod_fw);
> > > +
> > > + /* Configuration FW GPIO */
> > > + ret = gpiod_direction_output(gpiod_fw, 0);
> > > + if (ret) {
> > > + nfc_err(dev, "Fail FW pin direction\n");
> > > + return ret;
> > > + }
> > The same comments apply here.
> >
> > > +
> > > + /* Get IRQ GPIO */
> > > + gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
> > > + if (IS_ERR(gpiod_irq)) {
> > > + nfc_err(dev,
> > > + "Unable to get IRQ GPIO\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + phy->gpio_irq = desc_to_gpio(gpiod_irq);
> > > +
> > > + /* Configure IRQ GPIO */
> > > + ret = gpiod_direction_input(gpiod_irq);
> > > + if (ret) {
> > > + nfc_err(dev, "Fail IRQ pin direction\n");
> > > + return ret;
> > > + }
> > > +
> > > + /* Map the pin to an IRQ */
> > > + ret = gpiod_to_irq(gpiod_irq);
> > > + if (ret < 0) {
> > > + nfc_err(dev, "Fail pin IRQ mapping\n");
> > > + return ret;
> > > + }
> > and here.
> Also as far as I know the device tree implementation will not give you the
> gpiod data structure. It gives you only the gpio index.
What is "the device tree implementation"? If devm_gpiod_get_index gets
the information which gpio to use from a device tree that doesn't change
the return type, you still get a struct gpio_desc pointer. And it can
very well return a descriptor with GPIO_ACTIVE_LOW set, see the
implementation of of_find_gpio.
> Keeping both gpiod and gpio depending on the enumeration method is unscallable
> so I didn't choose that.
And if the descriptor has GPIO_ACTIVE_LOW set, you should better not
ignore it. The best thing to do here AFAIUI is to first convert the
driver to gpiod and then add your ACPI support in an additional patch.
And then please (this was the main motivation for my reply) your the
4-parameter version of devm_gpiod_get_index.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: Fix key serialization.
From: Joe Stringer @ 2015-02-12 19:02 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1423763928-1554-1-git-send-email-pshelar@nicira.com>
On 12 February 2015 at 09:58, Pravin B Shelar <pshelar@nicira.com> wrote:
> Fix typo where mask is used rather than key.
>
> Fixes: 74ed7ab9264("openvswitch: Add support for unique flow IDs.")
> Reported-by: Joe Stringer <joestringer@nicira.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> ---
Thanks for looking into this. So in general we zero-initialize the
key, but not the mask---then use the key to determine which parts of
the key (or mask) to serialize?
This fixes the problem I was seeing.
Acked-by: Joe Stringer <joestringer@nicira.com>
^ permalink raw reply
* [PATCH net-next] openvswitch: Fix key serialization.
From: Pravin B Shelar @ 2015-02-12 17:58 UTC (permalink / raw)
To: davem; +Cc: netdev, joestringer, Pravin B Shelar
Fix typo where mask is used rather than key.
Fixes: 74ed7ab9264("openvswitch: Add support for unique flow IDs.")
Reported-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
net/openvswitch/flow_netlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 993281e..254e466 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -1516,7 +1516,7 @@ int ovs_nla_put_identifier(const struct sw_flow *flow, struct sk_buff *skb)
/* Called with ovs_mutex or RCU read lock. */
int ovs_nla_put_masked_key(const struct sw_flow *flow, struct sk_buff *skb)
{
- return ovs_nla_put_key(&flow->mask->key, &flow->key,
+ return ovs_nla_put_key(&flow->key, &flow->key,
OVS_FLOW_ATTR_KEY, false, skb);
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] NFC: Add ACPI support for NXP PN544
From: Robert Dolca @ 2015-02-12 17:48 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-nfc, Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz,
linux-kernel, linux-wireless, netdev, David S. Miller,
Berg Johannes, Clement Perrochaud
In-Reply-To: <20150212081459.GA28954@pengutronix.de>
Hi Uwe,
On Thu, Feb 12, 2015 at 09:14:59AM +0100, Uwe Kleine-König wrote:
> On Mon, Jan 26, 2015 at 01:13:37PM +0200, Robert Dolca wrote:
> > + /* Get EN GPIO from ACPI */
> > + gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
> Actually devm_gpiod_get_index takes 4 arguments. In your case you should
> also pass GPIOD_OUT_LOW, then you can skip the gpiod_direction_output
> part below.
>
> > + if (IS_ERR(gpiod_en)) {
> > + nfc_err(dev,
> > + "Unable to get EN GPIO\n");
> > + return -ENODEV;
> > + }
> > +
> > + phy->gpio_en = desc_to_gpio(gpiod_en);
> Why don't you save a reference to the gpiod instead? Mixing usage of raw
> and gpiod might result in surprising results. For example
>
> gpiod_direction_output(gpiod_en, 0);
>
> might actually have the same result as
>
> gpio_direction_output(gpio_en, 1);
>
> if the matching gpio is marked as active low.
>
> > +
> > + /* Configuration EN GPIO */
> > + ret = gpiod_direction_output(gpiod_en, 0);
> > + if (ret) {
> > + nfc_err(dev, "Fail EN pin direction\n");
> > + return ret;
> > + }
> > +
> > + /* Get FW GPIO from ACPI */
> > + gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
> > + if (IS_ERR(gpiod_fw)) {
> > + nfc_err(dev,
> > + "Unable to get FW GPIO\n");
> > + return -ENODEV;
> > + }
> > +
> > + phy->gpio_fw = desc_to_gpio(gpiod_fw);
> > +
> > + /* Configuration FW GPIO */
> > + ret = gpiod_direction_output(gpiod_fw, 0);
> > + if (ret) {
> > + nfc_err(dev, "Fail FW pin direction\n");
> > + return ret;
> > + }
> The same comments apply here.
>
> > +
> > + /* Get IRQ GPIO */
> > + gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
> > + if (IS_ERR(gpiod_irq)) {
> > + nfc_err(dev,
> > + "Unable to get IRQ GPIO\n");
> > + return -ENODEV;
> > + }
> > +
> > + phy->gpio_irq = desc_to_gpio(gpiod_irq);
> > +
> > + /* Configure IRQ GPIO */
> > + ret = gpiod_direction_input(gpiod_irq);
> > + if (ret) {
> > + nfc_err(dev, "Fail IRQ pin direction\n");
> > + return ret;
> > + }
> > +
> > + /* Map the pin to an IRQ */
> > + ret = gpiod_to_irq(gpiod_irq);
> > + if (ret < 0) {
> > + nfc_err(dev, "Fail pin IRQ mapping\n");
> > + return ret;
> > + }
> and here.
I didn't use gpiod_* functions because the existing enumeration method for
platform init and device tree was using gpio_* functions.
Also as far as I know the device tree implementation will not give you the
gpiod data structure. It gives you only the gpio index.
Keeping both gpiod and gpio depending on the enumeration method is unscallable
so I didn't choose that.
Regards,
Robert
^ permalink raw reply
* Re: [PATCH] net: compat: Ignore MSG_CMSG_COMPAT in compat_sys_{send,recv}msg
From: Catalin Marinas @ 2015-02-12 17:32 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Will Deacon,
luto@amacapital.net
In-Reply-To: <20150212.084124.1966135201655814270.davem@davemloft.net>
On Thu, Feb 12, 2015 at 04:41:24PM +0000, David Miller wrote:
> From: Catalin Marinas <catalin.marinas@arm.com>
> Date: Thu, 12 Feb 2015 12:28:07 +0000
>
> > With commit a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg), the
> > MSG_CMSG_COMPAT flag is blocked at the compat syscall entry points,
> > changing the kernel compat behaviour from the one before the commit it
> > was trying to fix (1be374a0518a, net: Block MSG_CMSG_COMPAT in
> > send(m)msg and recv(m)msg).
> >
> > On 32-bit kernels (!CONFIG_COMPAT), MSG_CMSG_COMPAT is 0 and the native
> > 32-bit sys_sendmsg() allows flag 0x80000000 to be set (it is ignored by
> > the kernel). However, on a 64-bit kernel, the compat ABI is different
> > with commit a7526eb5d06b.
> >
> > This patch changes the compat_sys_{send,recv}msg behaviour to the one
> > prior to commit 1be374a0518a.
> >
> > The problem was found running 32-bit LTP (sendmsg01) binary on an arm64
> > kernel. Arguably, LTP should not pass 0xffffffff as flags to sendmsg()
> > but the general rule is not to break user ABI (even when the user
> > behaviour is not entirely sane).
> >
> > Fixes: a7526eb5d06b (net: Unbreak compat_sys_{send,recv}msg)
> > Cc: Andy Lutomirski <luto@amacapital.net>
> > Cc: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>
> I think this is a very poor LTP test.
That I agree.
> Setting MSG_* bits that aren't supported by the protocol in any way
> gives undefined semantics. You may get an error, it may be silently
> ignored, etc.
>From the sendmsg(2) man page, if some bit in the flags is inappropriate
for the socket type, it should return -EOPNOTSUPP. But I can't tell
whether it refers only to bits which are defined (for other socket
types) or just any bit. The test itself checks for -EOPNOTSUPP but it
gets -EINVAL instead, hence the failure being reported.
> I'm not applying this, sorry.
What I'm after is consistency between the native 32-bit kernel and the
compat layer on 64-bit. On the former, bit 31 is silently ignored, on
the latter it reports -EINVAL.
We could as well do something like below but we end up with unnecessary
flags check on 32-bit. The question is whether such change would be
considered a 32-bit user ABI breakage.
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 6e49a14365dc..0b283397ca0a 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -272,11 +272,7 @@ struct ucred {
#define MSG_CMSG_CLOEXEC 0x40000000 /* Set close_on_exec for file
descriptor received through
SCM_RIGHTS */
-#if defined(CONFIG_COMPAT)
#define MSG_CMSG_COMPAT 0x80000000 /* This message needs 32 bit fixups */
-#else
-#define MSG_CMSG_COMPAT 0 /* We never have 32 bit fixups */
-#endif
/* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */
--
Catalin
^ permalink raw reply related
* [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"
From: Robert Jarzmik @ 2015-02-12 16:59 UTC (permalink / raw)
To: Nicolas Pitre, David S. Miller, Linus Walleij
Cc: netdev, linux-kernel, Robert Jarzmik
The commit breaks the legacy platforms, ie. these not using device-tree,
and setting up the interrupt resources with a flag to activate edge
detection. The issue was found on the zylonite platform.
The reason is that zylonite uses platform resources to pass the interrupt number
and the irq flags (here IORESOURCE_IRQ_HIGHEDGE). It expects the driver to
request the irq with these flags, which in turn setups the irq as high edge
triggered.
After the patch, this was supposed to be taken care of with :
irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));
But irq_resflags is 0 for legacy platforms, while for example in
arch/arm/mach-pxa/zylonite.c, in struct resource smc91x_resources[] the
irq flag is specified. This breaks zylonite because the interrupt is not
setup as triggered, and hardware doesn't provide interrupts.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/net/ethernet/smsc/smc91x.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 88a55f9..5d77e6f 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2243,10 +2243,9 @@ static int smc_drv_probe(struct platform_device *pdev)
const struct of_device_id *match = NULL;
struct smc_local *lp;
struct net_device *ndev;
- struct resource *res;
+ struct resource *res, *ires;
unsigned int __iomem *addr;
unsigned long irq_flags = SMC_IRQ_FLAGS;
- unsigned long irq_resflags;
int ret;
ndev = alloc_etherdev(sizeof(struct smc_local));
@@ -2338,19 +2337,16 @@ static int smc_drv_probe(struct platform_device *pdev)
goto out_free_netdev;
}
- ndev->irq = platform_get_irq(pdev, 0);
- if (ndev->irq <= 0) {
+ ires = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!ires) {
ret = -ENODEV;
goto out_release_io;
}
- /*
- * If this platform does not specify any special irqflags, or if
- * the resource supplies a trigger, override the irqflags with
- * the trigger flags from the resource.
- */
- irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));
- if (irq_flags == -1 || irq_resflags & IRQF_TRIGGER_MASK)
- irq_flags = irq_resflags & IRQF_TRIGGER_MASK;
+
+ ndev->irq = ires->start;
+
+ if (irq_flags == -1 || ires->flags & IRQF_TRIGGER_MASK)
+ irq_flags = ires->flags & IRQF_TRIGGER_MASK;
ret = smc_request_attrib(pdev, ndev);
if (ret)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: ipv6: Make address flushing on ifdown optional - v3
From: Nicolas Dichtel @ 2015-02-12 16:57 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: Hannes Frederic Sowa
In-Reply-To: <1423715261-53131-1-git-send-email-dsahern@gmail.com>
Le 12/02/2015 05:27, David Ahern a écrit :
> Currently, all ipv6 addresses are flushed when the interface is configured
> down, even static address:
>
[snip]
>
> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> [root@f20 ~]# ip link set dev eth1 up
> [root@f20 ~]# ip link set dev eth1 down
> [root@f20 ~]# ip addr show dev eth1
> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
> link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> inet6 2000:11:1:1::1/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::4:11ff:fe22:3301/64 scope link
> valid_lft forever preferred_lft forever
Can you show an output of 'ip -6 route list table local' and 'ip -6 route' ?
^ permalink raw reply
* [PATCH net] net: eth: altera: Change reset_mac failure message masks from err to dbg
From: Vince Bridgers @ 2015-02-12 16:47 UTC (permalink / raw)
To: netdev, nios2-dev, linux-kernel; +Cc: vbridger, vbridger
This debug output is not really an error message since mac reset can fail
if the phy clocks are gated, specifically when the phy has been placed in
a powered down or isolation mode. The netdev output masks were changed from
err to dbg, and comments added in the code.
Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>
---
drivers/net/ethernet/altera/altera_tse_main.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c b/drivers/net/ethernet/altera/altera_tse_main.c
index 760c72c..996bdf1 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -1099,8 +1099,12 @@ static int tse_open(struct net_device *dev)
spin_lock(&priv->mac_cfg_lock);
ret = reset_mac(priv);
+ /* Note that reset_mac will fail if the clocks are gated by the PHY
+ * due to the PHY being put into isolation or power down mode.
+ * This is not an error if reset fails due to no clock.
+ */
if (ret)
- netdev_err(dev, "Cannot reset MAC core (error: %d)\n", ret);
+ netdev_dbg(dev, "Cannot reset MAC core (error: %d)\n", ret);
ret = init_mac(priv);
spin_unlock(&priv->mac_cfg_lock);
@@ -1204,8 +1208,12 @@ static int tse_shutdown(struct net_device *dev)
spin_lock(&priv->tx_lock);
ret = reset_mac(priv);
+ /* Note that reset_mac will fail if the clocks are gated by the PHY
+ * due to the PHY being put into isolation or power down mode.
+ * This is not an error if reset fails due to no clock.
+ */
if (ret)
- netdev_err(dev, "Cannot reset MAC core (error: %d)\n", ret);
+ netdev_dbg(dev, "Cannot reset MAC core (error: %d)\n", ret);
priv->dmaops->reset_dma(priv);
free_skbufs(dev);
--
1.9.1
^ permalink raw reply related
* [PATCH net] net: eth: altera: Change access ports to mdio for all xMII applications
From: Vince Bridgers @ 2015-02-12 16:47 UTC (permalink / raw)
To: netdev, nios2-dev, linux-kernel; +Cc: vbridger, vbridger, kailng, dwesterg
Change use of Altera TSE's MDIO access from phy 0 registers to phy 1
registers. This allows support for GMII, MII, RGMII, and SGMII
designs where the external PHY is always accesible through
Altera TSE's MDIO phy 1 registers and Altera's PCS is accessible
through MDIO phy 0 registers for SGMII applications.
Signed-off-by: Vince Bridgers <vbridger@opensource.altera.com>
Tested-by: Kai Lin Ng <kailng@altera.com>
Tested-by: Dalon Westergreen <dwesterg@gmail.com>
---
drivers/net/ethernet/altera/altera_tse_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c b/drivers/net/ethernet/altera/altera_tse_main.c
index 996bdf1..a1ee261 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -105,11 +105,11 @@ static int altera_tse_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
/* set MDIO address */
csrwr32((mii_id & 0x1f), priv->mac_dev,
- tse_csroffs(mdio_phy0_addr));
+ tse_csroffs(mdio_phy1_addr));
/* get the data */
return csrrd32(priv->mac_dev,
- tse_csroffs(mdio_phy0) + regnum * 4) & 0xffff;
+ tse_csroffs(mdio_phy1) + regnum * 4) & 0xffff;
}
static int altera_tse_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
@@ -120,10 +120,10 @@ static int altera_tse_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
/* set MDIO address */
csrwr32((mii_id & 0x1f), priv->mac_dev,
- tse_csroffs(mdio_phy0_addr));
+ tse_csroffs(mdio_phy1_addr));
/* write the data */
- csrwr32(value, priv->mac_dev, tse_csroffs(mdio_phy0) + regnum * 4);
+ csrwr32(value, priv->mac_dev, tse_csroffs(mdio_phy1) + regnum * 4);
return 0;
}
--
1.9.1
^ 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