* [PATCH v6 23/46] virtio_net: pass vi around
From: Michael S. Tsirkin @ 2014-11-27 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: David Miller, cornelia.huck, rusty, nab, pbonzini, thuth, dahi,
Rusty Russell, virtualization, netdev
In-Reply-To: <1417118789-18231-1-git-send-email-mst@redhat.com>
Too many places poke at [rs]q->vq->vdev->priv just to get
the vi structure. Let's just pass the pointer around: seems
cleaner, and might even be faster.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
drivers/net/virtio_net.c | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index c07e030..1630c21 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -241,11 +241,11 @@ static unsigned long mergeable_buf_to_ctx(void *buf, unsigned int truesize)
}
/* Called from bottom half context */
-static struct sk_buff *page_to_skb(struct receive_queue *rq,
+static struct sk_buff *page_to_skb(struct virtnet_info *vi,
+ struct receive_queue *rq,
struct page *page, unsigned int offset,
unsigned int len, unsigned int truesize)
{
- struct virtnet_info *vi = rq->vq->vdev->priv;
struct sk_buff *skb;
struct skb_vnet_hdr *hdr;
unsigned int copy, hdr_len, hdr_padded_len;
@@ -328,12 +328,13 @@ static struct sk_buff *receive_small(void *buf, unsigned int len)
}
static struct sk_buff *receive_big(struct net_device *dev,
+ struct virtnet_info *vi,
struct receive_queue *rq,
void *buf,
unsigned int len)
{
struct page *page = buf;
- struct sk_buff *skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
+ struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
if (unlikely(!skb))
goto err;
@@ -359,7 +360,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
int offset = buf - page_address(page);
unsigned int truesize = max(len, mergeable_ctx_to_buf_truesize(ctx));
- struct sk_buff *head_skb = page_to_skb(rq, page, offset, len, truesize);
+ struct sk_buff *head_skb = page_to_skb(vi, rq, page, offset, len,
+ truesize);
struct sk_buff *curr_skb = head_skb;
if (unlikely(!curr_skb))
@@ -433,9 +435,9 @@ err_buf:
return NULL;
}
-static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
+static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
+ void *buf, unsigned int len)
{
- struct virtnet_info *vi = rq->vq->vdev->priv;
struct net_device *dev = vi->dev;
struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
struct sk_buff *skb;
@@ -459,7 +461,7 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
if (vi->mergeable_rx_bufs)
skb = receive_mergeable(dev, vi, rq, (unsigned long)buf, len);
else if (vi->big_packets)
- skb = receive_big(dev, rq, buf, len);
+ skb = receive_big(dev, vi, rq, buf, len);
else
skb = receive_small(buf, len);
@@ -539,9 +541,9 @@ frame_err:
dev_kfree_skb(skb);
}
-static int add_recvbuf_small(struct receive_queue *rq, gfp_t gfp)
+static int add_recvbuf_small(struct virtnet_info *vi, struct receive_queue *rq,
+ gfp_t gfp)
{
- struct virtnet_info *vi = rq->vq->vdev->priv;
struct sk_buff *skb;
struct skb_vnet_hdr *hdr;
int err;
@@ -664,9 +666,9 @@ static int add_recvbuf_mergeable(struct receive_queue *rq, gfp_t gfp)
* before we're receiving packets, or from refill_work which is
* careful to disable receiving (using napi_disable).
*/
-static bool try_fill_recv(struct receive_queue *rq, gfp_t gfp)
+static bool try_fill_recv(struct virtnet_info *vi, struct receive_queue *rq,
+ gfp_t gfp)
{
- struct virtnet_info *vi = rq->vq->vdev->priv;
int err;
bool oom;
@@ -677,7 +679,7 @@ static bool try_fill_recv(struct receive_queue *rq, gfp_t gfp)
else if (vi->big_packets)
err = add_recvbuf_big(rq, gfp);
else
- err = add_recvbuf_small(rq, gfp);
+ err = add_recvbuf_small(vi, rq, gfp);
oom = err == -ENOMEM;
if (err)
@@ -726,7 +728,7 @@ static void refill_work(struct work_struct *work)
struct receive_queue *rq = &vi->rq[i];
napi_disable(&rq->napi);
- still_empty = !try_fill_recv(rq, GFP_KERNEL);
+ still_empty = !try_fill_recv(vi, rq, GFP_KERNEL);
virtnet_napi_enable(rq);
/* In theory, this can happen: if we don't get any buffers in
@@ -745,12 +747,12 @@ static int virtnet_receive(struct receive_queue *rq, int budget)
while (received < budget &&
(buf = virtqueue_get_buf(rq->vq, &len)) != NULL) {
- receive_buf(rq, buf, len);
+ receive_buf(vi, rq, buf, len);
received++;
}
if (rq->vq->num_free > virtqueue_get_vring_size(rq->vq) / 2) {
- if (!try_fill_recv(rq, GFP_ATOMIC))
+ if (!try_fill_recv(vi, rq, GFP_ATOMIC))
schedule_delayed_work(&vi->refill, 0);
}
@@ -826,7 +828,7 @@ static int virtnet_open(struct net_device *dev)
for (i = 0; i < vi->max_queue_pairs; i++) {
if (i < vi->curr_queue_pairs)
/* Make sure we have some buffers: if oom use wq. */
- if (!try_fill_recv(&vi->rq[i], GFP_KERNEL))
+ if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL))
schedule_delayed_work(&vi->refill, 0);
virtnet_napi_enable(&vi->rq[i]);
}
@@ -1851,7 +1853,7 @@ static int virtnet_probe(struct virtio_device *vdev)
/* Last of all, set up some receive buffers. */
for (i = 0; i < vi->curr_queue_pairs; i++) {
- try_fill_recv(&vi->rq[i], GFP_KERNEL);
+ try_fill_recv(vi, &vi->rq[i], GFP_KERNEL);
/* If we didn't even get one input buffer, we're useless. */
if (vi->rq[i].vq->num_free ==
@@ -1971,7 +1973,7 @@ static int virtnet_restore(struct virtio_device *vdev)
if (netif_running(vi->dev)) {
for (i = 0; i < vi->curr_queue_pairs; i++)
- if (!try_fill_recv(&vi->rq[i], GFP_KERNEL))
+ if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL))
schedule_delayed_work(&vi->refill, 0);
for (i = 0; i < vi->max_queue_pairs; i++)
--
MST
^ permalink raw reply related
* [PATCH v6 15/46] virtio_net: v1.0 endianness
From: Michael S. Tsirkin @ 2014-11-27 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: David Miller, cornelia.huck, rusty, nab, pbonzini, thuth, dahi,
Rusty Russell, virtualization, netdev, linux-api
In-Reply-To: <1417118789-18231-1-git-send-email-mst@redhat.com>
Based on patches by Rusty Russell, Cornelia Huck.
Note: more code changes are needed for 1.0 support
(due to different header size).
So we don't advertize support for 1.0 yet.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
include/uapi/linux/virtio_net.h | 15 ++++++++-------
drivers/net/virtio_net.c | 33 ++++++++++++++++++++-------------
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index 172a7f0..b5f1677 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -28,6 +28,7 @@
#include <linux/types.h>
#include <linux/virtio_ids.h>
#include <linux/virtio_config.h>
+#include <linux/virtio_types.h>
#include <linux/if_ether.h>
/* The feature bitmap for virtio net */
@@ -84,17 +85,17 @@ struct virtio_net_hdr {
#define VIRTIO_NET_HDR_GSO_TCPV6 4 // GSO frame, IPv6 TCP
#define VIRTIO_NET_HDR_GSO_ECN 0x80 // TCP has ECN set
__u8 gso_type;
- __u16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
- __u16 gso_size; /* Bytes to append to hdr_len per frame */
- __u16 csum_start; /* Position to start checksumming from */
- __u16 csum_offset; /* Offset after that to place checksum */
+ __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
+ __virtio16 gso_size; /* Bytes to append to hdr_len per frame */
+ __virtio16 csum_start; /* Position to start checksumming from */
+ __virtio16 csum_offset; /* Offset after that to place checksum */
};
/* This is the version of the header to use when the MRG_RXBUF
* feature has been negotiated. */
struct virtio_net_hdr_mrg_rxbuf {
struct virtio_net_hdr hdr;
- __u16 num_buffers; /* Number of merged rx buffers */
+ __virtio16 num_buffers; /* Number of merged rx buffers */
};
/*
@@ -149,7 +150,7 @@ typedef __u8 virtio_net_ctrl_ack;
* VIRTIO_NET_F_CTRL_MAC_ADDR feature is available.
*/
struct virtio_net_ctrl_mac {
- __u32 entries;
+ __virtio32 entries;
__u8 macs[][ETH_ALEN];
} __attribute__((packed));
@@ -193,7 +194,7 @@ struct virtio_net_ctrl_mac {
* specified.
*/
struct virtio_net_ctrl_mq {
- __u16 virtqueue_pairs;
+ __virtio16 virtqueue_pairs;
};
#define VIRTIO_NET_CTRL_MQ 4
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b0bc8ea..c07e030 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -347,13 +347,14 @@ err:
}
static struct sk_buff *receive_mergeable(struct net_device *dev,
+ struct virtnet_info *vi,
struct receive_queue *rq,
unsigned long ctx,
unsigned int len)
{
void *buf = mergeable_ctx_to_buf_address(ctx);
struct skb_vnet_hdr *hdr = buf;
- int num_buf = hdr->mhdr.num_buffers;
+ u16 num_buf = virtio16_to_cpu(rq->vq->vdev, hdr->mhdr.num_buffers);
struct page *page = virt_to_head_page(buf);
int offset = buf - page_address(page);
unsigned int truesize = max(len, mergeable_ctx_to_buf_truesize(ctx));
@@ -369,7 +370,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
ctx = (unsigned long)virtqueue_get_buf(rq->vq, &len);
if (unlikely(!ctx)) {
pr_debug("%s: rx error: %d buffers out of %d missing\n",
- dev->name, num_buf, hdr->mhdr.num_buffers);
+ dev->name, num_buf,
+ virtio16_to_cpu(rq->vq->vdev,
+ hdr->mhdr.num_buffers));
dev->stats.rx_length_errors++;
goto err_buf;
}
@@ -454,7 +457,7 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
}
if (vi->mergeable_rx_bufs)
- skb = receive_mergeable(dev, rq, (unsigned long)buf, len);
+ skb = receive_mergeable(dev, vi, rq, (unsigned long)buf, len);
else if (vi->big_packets)
skb = receive_big(dev, rq, buf, len);
else
@@ -473,8 +476,8 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
if (hdr->hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
pr_debug("Needs csum!\n");
if (!skb_partial_csum_set(skb,
- hdr->hdr.csum_start,
- hdr->hdr.csum_offset))
+ virtio16_to_cpu(vi->vdev, hdr->hdr.csum_start),
+ virtio16_to_cpu(vi->vdev, hdr->hdr.csum_offset)))
goto frame_err;
} else if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -514,7 +517,8 @@ static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
if (hdr->hdr.gso_type & VIRTIO_NET_HDR_GSO_ECN)
skb_shinfo(skb)->gso_type |= SKB_GSO_TCP_ECN;
- skb_shinfo(skb)->gso_size = hdr->hdr.gso_size;
+ skb_shinfo(skb)->gso_size = virtio16_to_cpu(vi->vdev,
+ hdr->hdr.gso_size);
if (skb_shinfo(skb)->gso_size == 0) {
net_warn_ratelimited("%s: zero gso size.\n", dev->name);
goto frame_err;
@@ -876,16 +880,19 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
if (skb->ip_summed == CHECKSUM_PARTIAL) {
hdr->hdr.flags = VIRTIO_NET_HDR_F_NEEDS_CSUM;
- hdr->hdr.csum_start = skb_checksum_start_offset(skb);
- hdr->hdr.csum_offset = skb->csum_offset;
+ hdr->hdr.csum_start = cpu_to_virtio16(vi->vdev,
+ skb_checksum_start_offset(skb));
+ hdr->hdr.csum_offset = cpu_to_virtio16(vi->vdev,
+ skb->csum_offset);
} else {
hdr->hdr.flags = 0;
hdr->hdr.csum_offset = hdr->hdr.csum_start = 0;
}
if (skb_is_gso(skb)) {
- hdr->hdr.hdr_len = skb_headlen(skb);
- hdr->hdr.gso_size = skb_shinfo(skb)->gso_size;
+ hdr->hdr.hdr_len = cpu_to_virtio16(vi->vdev, skb_headlen(skb));
+ hdr->hdr.gso_size = cpu_to_virtio16(vi->vdev,
+ skb_shinfo(skb)->gso_size);
if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4)
hdr->hdr.gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
@@ -1112,7 +1119,7 @@ static int virtnet_set_queues(struct virtnet_info *vi, u16 queue_pairs)
if (!vi->has_cvq || !virtio_has_feature(vi->vdev, VIRTIO_NET_F_MQ))
return 0;
- s.virtqueue_pairs = queue_pairs;
+ s.virtqueue_pairs = cpu_to_virtio16(vi->vdev, queue_pairs);
sg_init_one(&sg, &s, sizeof(s));
if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_MQ,
@@ -1189,7 +1196,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
sg_init_table(sg, 2);
/* Store the unicast list and count in the front of the buffer */
- mac_data->entries = uc_count;
+ mac_data->entries = cpu_to_virtio32(vi->vdev, uc_count);
i = 0;
netdev_for_each_uc_addr(ha, dev)
memcpy(&mac_data->macs[i++][0], ha->addr, ETH_ALEN);
@@ -1200,7 +1207,7 @@ static void virtnet_set_rx_mode(struct net_device *dev)
/* multicast list and count fill the end */
mac_data = (void *)&mac_data->macs[uc_count][0];
- mac_data->entries = mc_count;
+ mac_data->entries = cpu_to_virtio32(vi->vdev, mc_count);
i = 0;
netdev_for_each_mc_addr(ha, dev)
memcpy(&mac_data->macs[i++][0], ha->addr, ETH_ALEN);
--
MST
^ permalink raw reply related
* Re: [patch net-next v3 09/17] bridge: add API to notify bridge driver of learned FBD on offloaded device
From: John Fastabend @ 2014-11-27 19:36 UTC (permalink / raw)
To: Scott Feldman; +Cc: Arad, Ronen, netdev@vger.kernel.org
In-Reply-To: <CAE4R7bC9o4ucO_Erb0tU4EwJNYj8SrapbKxNWvUTL8YD=RMBJQ@mail.gmail.com>
On 11/26/2014 11:03 PM, Scott Feldman wrote:
> On Tue, Nov 25, 2014 at 9:37 PM, Arad, Ronen <ronen.arad@intel.com> wrote:
>>>>>>
>>>>>> Is there any case where this fdb entry gets re-used and is no
>>>>>> longer added by an external learning? Should we clear this flag somewhere?
>>>>>
>>>>> Once the FDB entry is marked "added_by_external_learn" it stays
>>>>> marked as such until removed by aging cleanup process (or flushed
>>>>> due to interface down, etc). If aged out (and now deleted), the
>>>>> FDB entry may come back either by SW learn or by HW learn. If SW
>>>>> learn comes first, and then HW learn, HW learn will override and
>>>>> mark the existing FDB entry "added_by_external_learn". So there is
>>>>> take-over by HW but no give-back to SW. And there is no explicit
>>>>> clearing of the mark short of deleting the FDB entry. The mark is
>>>>> mostly for letting user's know which FDB entries where learned by
>>>>> HW and synced to the bridge's FDB.
>>>>
>>>> Thanks, makes sense now. This is probably obvious in this context,
>>>> but maybe it would not hurt to come up with a documentation that
>>>> describe the offload API, FDB entry lifetime and HW/SW ownership etc...
>>>
>>> I have an updated Documentation/networking/switchdev.txt that covers
>>> the swdev APIs and usage and notes, but Jiri is being stingy with it.
>>> Will get this out, either in v4 or follow-on patches. There is enough
>>> going on just with L2 offload that we're going to need some good
>>> documentation to guide implementers.
>>> --
>>
>> To control the lifetime of an externally learned FDB entry, the bridge shall provide an API for the switch driver to update the freshness of externally learned entries. Otherwise, the bridge aging will age entries which are currently or frequently used by the HW.
>> Is this covered in the updated document?
>> Is this functionality planned for v4?
>
> Hi Ronen,
>
> It's already there: driver calls br_fdb_external_learn_add() to
> refresh FBD entry, which updates the fdb->updated and fdb->used
> timestamps, preventing bridge from prematurely aging out the entry.
> We'll make sure that detail gets in the doc. It's up to the driver on
> how frequently it calls br_fdb_external_learn_add(). Maybe it just
> blindly makes the call every 1s. That's what rocker driver does (as
> long as the FDB entry continues to get hits). From the user's
> perspective, 1s update is nice when looking at the stats dump for
> fdbs, since the timestamps are in secs.
>
> -scott
We could at some point add a driver knob to set the timing of the
updates as well, but I don't see the need for it yet. Rocker switch
doesn't need it but if vendors devices want to do this it wouldn't
be difficult.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: bug in networking code causes GPF
From: Mathias Krause @ 2014-11-27 19:26 UTC (permalink / raw)
To: Дениска-редиска
Cc: Daniel Borkmann, linux-net, netdev, linux-kernel@vger.kernel.org,
Florian Westphal
In-Reply-To: <1417102910.5477463ec9948@mail.inbox.lv>
On 27 November 2014 at 16:41, Дениска-редиска <slim@inbox.lv> wrote:
> well, I will try to disable CONFIG_PAX_MEMORY_SANITIZE.
> Will take some time to make sure that this resolve the issue
That should fix the issue for you. You could also try to add
"pax_sanitize_slab=0" to the kernel command line to disable slab
sanitization.
> Цитирование Daniel Borkmann <dborkman@redhat.com> :
>> On 11/27/2014 02:35 PM, Дениска-редиска wrote:
>> > [...]
>> > [354497.932330] ... RBX: fefefefefefefefe ...
>> > [...]
>> > [354497.934903] Code: c2 85 d2 49 8b 86 d0 04 00 00 74 14 66 45 85 ff 75 0e 65 ff 40 04 e8 85 f6 a4 ff 48 89 d8 eb 69 65 ff 00 48 8b 1b f6 c3 01 75 0f <8b> 43 10 39 45 00 b8 00 00 00 00 74 83 eb 9d 48 d1 eb 4c 39 eb
That's: mov 0x10(%rbx),%eax
RBX contains the PaX sanitize pattern, that's the reason for the #GP.
So this is very likely the bug Daniel mentioned.
Please update to a recent grsec kernel to get this issue fixed. It's
fixed in the stable patches as well as in the test patch.
Regards,
Mathias
^ permalink raw reply
* Re: [PATCH 1/1] bridge: Fix NAT66ed IPv6 packets not being bridged correctly
From: Bernhard Thaler @ 2014-11-27 19:26 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: sven, yoshfuji, netdev, bridge, jmorris, David Miller,
netfilter-devel, kuznet, kaber, linux-kernel
In-Reply-To: <20141003112119.GA5420@salvia>
Hi,
I tested Sven's patch in my setup and I think it should be safe to use
it. It is shorter and cleaner written and he submitted it earlier.
I will be happy to assist you or Sven if any further work is needed.
Regards,
Bernhard
On 03.10.2014 13:21, Pablo Neira Ayuso wrote:
> Hi Bernhard,
>
> Sorry for taking a bit to get back to you with feedback. We've been
> discussing recently some changes in br_netfilter. Basically, to
> modularize it [1] and this has taken a while.
>
> Regarding your change. Sven Eckelmann (CC'ed in this email) sent a RFC
> out of the merge window that have remain tagged in my patchwork, you
> can find it here.
>
> http://patchwork.ozlabs.org/patch/381027/
>
> I would like to see a submission that covers all NAT66 scenarios that
> we currenty support.
>
> Thanks.
>
> [1] http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/54234
>
> On Mon, Sep 15, 2014 at 05:40:09PM -0400, David Miller wrote:
>> From: Bernhard Thaler <bernhard.thaler@wvnet.at>
>> Date: Mon, 15 Sep 2014 23:27:28 +0200
>>
>> CC:'ing netfilter-devel and the netfilter maintainer, which is
>> probably the primary place this patch should have been submitted.
>>
>>> Ethernet frames are not bridged to correct interface when packets have
>>> been NAT66ed; compared to IPv4 logic in code, IPv6 code does not store
>>> original address (before NAT) on transmit to determine if packet was
>>> NAT66ed on receive to swap addresses back.
>>>
>>> Changes added in br_netfilter.c to store original address, compare
>>> against it and determine correct output interface. Changes needed in
>>> netfilter_bridge.h to store IPv6 address in pre-existing union.
>>> Export of ip6_route_input needed to use it in br_netfilter.c.
>>>
>>> Problem may only affect systems doing NAT66 and ethernet bridging at
>>> the same time. Tested in NAT66 setup on base of an ethernet bridge.
>>>
>>> Signed-off-by: Bernhard Thaler <bernhard.thaler@wvnet.at>
>>> ---
>>> include/linux/netfilter_bridge.h | 2 +
>>> net/bridge/br_netfilter.c | 136 ++++++++++++++++++++++++++++----------
>>> net/ipv6/route.c | 1 +
>>> 3 files changed, 105 insertions(+), 34 deletions(-)
>>>
>>> diff --git a/include/linux/netfilter_bridge.h b/include/linux/netfilter_bridge.h
>>> index 8ab1c27..3a9cdcd 100644
>>> --- a/include/linux/netfilter_bridge.h
>>> +++ b/include/linux/netfilter_bridge.h
>>> @@ -2,6 +2,7 @@
>>> #define __LINUX_BRIDGE_NETFILTER_H
>>>
>>> #include <uapi/linux/netfilter_bridge.h>
>>> +#include <uapi/linux/in6.h>
>>>
>>>
>>> enum nf_br_hook_priorities {
>>> @@ -79,6 +80,7 @@ static inline unsigned int nf_bridge_pad(const struct sk_buff *skb)
>>> struct bridge_skb_cb {
>>> union {
>>> __be32 ipv4;
>>> + struct in6_addr ipv6;
>>> } daddr;
>>> };
>>>
>>> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
>>> index a615264..2ae3888 100644
>>> --- a/net/bridge/br_netfilter.c
>>> +++ b/net/bridge/br_netfilter.c
>>> @@ -35,6 +35,9 @@
>>> #include <net/ip.h>
>>> #include <net/ipv6.h>
>>> #include <net/route.h>
>>> +#include <net/ip6_route.h>
>>> +#include <net/flow.h>
>>> +#include <net/dst.h>
>>>
>>> #include <asm/uaccess.h>
>>> #include "br_private.h"
>>> @@ -42,10 +45,18 @@
>>> #include <linux/sysctl.h>
>>> #endif
>>>
>>> -#define skb_origaddr(skb) (((struct bridge_skb_cb *) \
>>> - (skb->nf_bridge->data))->daddr.ipv4)
>>> -#define store_orig_dstaddr(skb) (skb_origaddr(skb) = ip_hdr(skb)->daddr)
>>> -#define dnat_took_place(skb) (skb_origaddr(skb) != ip_hdr(skb)->daddr)
>>> +#define skb_origaddr(skb) (((struct bridge_skb_cb *)\
>>> + (skb->nf_bridge->data))->daddr.ipv4)
>>> +#define skb_origaddr_ipv6(skb) (((struct bridge_skb_cb *)\
>>> + (skb->nf_bridge->data))->daddr.ipv6)
>>> +#define store_orig_dstaddr(skb) (skb_origaddr(skb) = ip_hdr(skb)->daddr)
>>> +#define store_orig_dstaddr_ipv6(skb) (skb_origaddr_ipv6(skb) = \
>>> + ipv6_hdr(skb)->daddr)
>>> +#define dnat_took_place(skb) (skb_origaddr(skb) != \
>>> + ip_hdr(skb)->daddr)
>>> +#define dnat_took_place_ipv6(skb) (memcmp(&skb_origaddr_ipv6(skb), \
>>> + &(ipv6_hdr(skb)->daddr), \
>>> + sizeof(struct in6_addr)) != 0)
>>>
>>> #ifdef CONFIG_SYSCTL
>>> static struct ctl_table_header *brnf_sysctl_header;
>>> @@ -340,36 +351,6 @@ int nf_bridge_copy_header(struct sk_buff *skb)
>>> return 0;
>>> }
>>>
>>> -/* PF_BRIDGE/PRE_ROUTING *********************************************/
>>> -/* Undo the changes made for ip6tables PREROUTING and continue the
>>> - * bridge PRE_ROUTING hook. */
>>> -static int br_nf_pre_routing_finish_ipv6(struct sk_buff *skb)
>>> -{
>>> - struct nf_bridge_info *nf_bridge = skb->nf_bridge;
>>> - struct rtable *rt;
>>> -
>>> - if (nf_bridge->mask & BRNF_PKT_TYPE) {
>>> - skb->pkt_type = PACKET_OTHERHOST;
>>> - nf_bridge->mask ^= BRNF_PKT_TYPE;
>>> - }
>>> - nf_bridge->mask ^= BRNF_NF_BRIDGE_PREROUTING;
>>> -
>>> - rt = bridge_parent_rtable(nf_bridge->physindev);
>>> - if (!rt) {
>>> - kfree_skb(skb);
>>> - return 0;
>>> - }
>>> - skb_dst_set_noref(skb, &rt->dst);
>>> -
>>> - skb->dev = nf_bridge->physindev;
>>> - nf_bridge_update_protocol(skb);
>>> - nf_bridge_push_encap_header(skb);
>>> - NF_HOOK_THRESH(NFPROTO_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL,
>>> - br_handle_frame_finish, 1);
>>> -
>>> - return 0;
>>> -}
>>> -
>>> /* Obtain the correct destination MAC address, while preserving the original
>>> * source MAC address. If we already know this address, we just copy it. If we
>>> * don't, we use the neighbour framework to find out. In both cases, we make
>>> @@ -527,6 +508,92 @@ bridged_dnat:
>>> return 0;
>>> }
>>>
>>> +/* PF_BRIDGE/PRE_ROUTING *********************************************
>>> + * Undo the changes made for ip6tables PREROUTING and continue the
>>> + * bridge PRE_ROUTING hook.
>>> + */
>>> +static int br_nf_pre_routing_finish_ipv6(struct sk_buff *skb)
>>> +{
>>> + struct net_device *dev = skb->dev;
>>> + struct ipv6hdr *iph = ipv6_hdr(skb);
>>> + struct nf_bridge_info *nf_bridge = skb->nf_bridge;
>>> + struct rtable *rt;
>>> + struct dst_entry *dst;
>>> + struct flowi6 fl6 = {
>>> + .flowi6_iif = skb->dev->ifindex,
>>> + .daddr = iph->daddr,
>>> + .saddr = iph->saddr,
>>> + .flowlabel = ip6_flowinfo(iph),
>>> + .flowi6_mark = skb->mark,
>>> + .flowi6_proto = iph->nexthdr,
>>> + };
>>> +
>>> + if (nf_bridge->mask & BRNF_PKT_TYPE) {
>>> + skb->pkt_type = PACKET_OTHERHOST;
>>> + nf_bridge->mask ^= BRNF_PKT_TYPE;
>>> + }
>>> + nf_bridge->mask ^= BRNF_NF_BRIDGE_PREROUTING;
>>> +
>>> + if (dnat_took_place_ipv6(skb)) {
>>> + ip6_route_input(skb);
>>> + /* ip6_route_input is void function,
>>> + * no int returned as in ip4_route_input
>>> + * changes value of skb->_skb_refdst) on success
>>> + */
>>> + if (skb->_skb_refdst == 0) {
>>> + struct in_device *in_dev = __in_dev_get_rcu(dev);
>>> +
>>> + if (!in_dev || IN_DEV_FORWARD(in_dev))
>>> + goto free_skb;
>>> +
>>> + dst = ip6_route_output(dev_net(dev), skb->sk, &fl6);
>>> + if (!IS_ERR(dst)) {
>>> + /* - Bridged-and-DNAT'ed traffic doesn't
>>> + * require ip_forwarding.
>>> + */
>>> + if (dst->dev == dev) {
>>> + skb_dst_set(skb, dst);
>>> + goto bridged_dnat;
>>> + }
>>> + dst_release(dst);
>>> + }
>>> +free_skb:
>>> + kfree_skb(skb);
>>> + return 0;
>>> + } else {
>>> + if (skb_dst(skb)->dev == dev) {
>>> +bridged_dnat:
>>> + skb->dev = nf_bridge->physindev;
>>> + nf_bridge_update_protocol(skb);
>>> + nf_bridge_push_encap_header(skb);
>>> + NF_HOOK_THRESH(NFPROTO_BRIDGE,
>>> + NF_BR_PRE_ROUTING,
>>> + skb, skb->dev, NULL,
>>> + br_nf_pre_routing_finish_bridge,
>>> + 1);
>>> + return 0;
>>> + }
>>> + memcpy(eth_hdr(skb)->h_dest, dev->dev_addr, ETH_ALEN);
>>> + skb->pkt_type = PACKET_HOST;
>>> + }
>>> + } else {
>>> + rt = bridge_parent_rtable(nf_bridge->physindev);
>>> + if (!rt) {
>>> + kfree_skb(skb);
>>> + return 0;
>>> + }
>>> + skb_dst_set_noref(skb, &rt->dst);
>>> + }
>>> +
>>> + skb->dev = nf_bridge->physindev;
>>> + nf_bridge_update_protocol(skb);
>>> + nf_bridge_push_encap_header(skb);
>>> + NF_HOOK_THRESH(NFPROTO_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL,
>>> + br_handle_frame_finish, 1);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static struct net_device *brnf_get_logical_dev(struct sk_buff *skb, const struct net_device *dev)
>>> {
>>> struct net_device *vlan, *br;
>>> @@ -658,6 +725,7 @@ static unsigned int br_nf_pre_routing_ipv6(const struct nf_hook_ops *ops,
>>> if (!setup_pre_routing(skb))
>>> return NF_DROP;
>>>
>>> + store_orig_dstaddr_ipv6(skb);
>>> skb->protocol = htons(ETH_P_IPV6);
>>> NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING, skb, skb->dev, NULL,
>>> br_nf_pre_routing_finish_ipv6);
>>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>>> index f23fbd2..e328905 100644
>>> --- a/net/ipv6/route.c
>>> +++ b/net/ipv6/route.c
>>> @@ -1017,6 +1017,7 @@ void ip6_route_input(struct sk_buff *skb)
>>>
>>> skb_dst_set(skb, ip6_route_input_lookup(net, skb->dev, &fl6, flags));
>>> }
>>> +EXPORT_SYMBOL(ip6_route_input);
>>>
>>> static struct rt6_info *ip6_pol_route_output(struct net *net, struct fib6_table *table,
>>> struct flowi6 *fl6, int flags)
>>> --
>>> 1.7.10.4
>>>
^ permalink raw reply
* Re: [PATCH] x86: bpf_jit_comp: simplify trivial boolean return
From: Joe Perches @ 2014-11-27 18:49 UTC (permalink / raw)
To: David Laight
Cc: Alexei Starovoitov, Quentin Lambert, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FDA63@AcuExch.aculab.com>
On Thu, 2014-11-27 at 12:25 +0000, David Laight wrote:
> Why the change in data?
btw: without gcov and using -O2
$ size arch/x86/net/bpf_jit_comp.o*
text data bss dec hex filename
9671 4 0 9675 25cb arch/x86/net/bpf_jit_comp.o.new
10679 4 0 10683 29bb arch/x86/net/bpf_jit_comp.o.old
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-27 18:38 UTC (permalink / raw)
To: Alex Strizhevsky
Cc: Bjørn Mork, ShaojunMidge.Tan, Mingying.Zhu, youtux,
linux-usb, netdev, Eli.Britstein
In-Reply-To: <CAPChA0cLuvRpYTYuFoi3bewqASgf_oZHSz5yQQ8JYm96dZ4-TQ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3333 bytes --]
To be clearer - then you fixed cdc_ncm magistrally I remember, adding also
sysfs attrs then.
But I was curious - so that we might understand if Thomas's problem was related
to the firmware or what else.
On Thu, 27 Nov 2014, Alex Strizhevsky wrote:
==Date: Thu, 27 Nov 2014 13:36:37
==From: Alex Strizhevsky <alexxst@gmail.com>
==To: Bjørn Mork <bjorn@mork.no>, ShaojunMidge.Tan@audiocodes.com,
== Mingying.Zhu@audiocodes.com
==Cc: Enrico Mioso <mrkiko.rs@gmail.com>, youtux@gmail.com,
== linux-usb@vger.kernel.org, netdev@vger.kernel.org,
== Eli.Britstein@audiocodes.com
==Subject: Re: Is this 32-bit NCM?
==
==Adding my colleagues - Eli, Kevin & Midge.
==
==Any ideas are welcome ;)
==
==
==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn@mork.no> wrote:
== Enrico Mioso <mrkiko.rs@gmail.com> writes:
==
== > Ok - we can arrive to some ocnclusions regarding the E3272.
== > First of all - the modem seems buggy enough to not be able to
== handle requests
== > for different formats. You need to unplug and re-plug it, but
== this is onlyan
== > impression and is reasonable.
== >
== > Then - the modem will accept to ndisdup the connection with
== > at^ndisdup=1,1,"internet"
== > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
== handling messages and
== > the modem stops here.
== > If we use the cdc_ncm 32-bit driver (modified) we get lotfs of
== > ^dsflorpt
== > that's how it should be.
== > So I think we can say that something is changing.
== > Then there's the alignment problem you mentioned in your
== previous reply. And
== > this is hard to solve.
== > could you try to help me understand where the problem is?
== > I feel like we are very close to the solution but something
== isn't working.
== > Or might be just try to change the 16 bit driver?
==
==If you use a recent version of the driver as a basis, then you get the
==CDC NCM NTB parameters in sysfs (if not, then you need to enable
==debugging and look in the log for these values). For example:
==
==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
==
==
==The possible problem I am thinking of is proper handling of the
==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame
==Alignment" in the spec. Which is confusing as hell, but if I
==understand
==it correctly then we are supposed to align the start of the IP packets
==(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor
==number
==as long as the wNdp*PayloadRemainder is 0.
==
==
==Bjørn
==
==
==
==
^ permalink raw reply
* Re: [PATCH] x86: bpf_jit_comp: simplify trivial boolean return
From: Joe Perches @ 2014-11-27 18:35 UTC (permalink / raw)
To: David Laight
Cc: Alexei Starovoitov, Quentin Lambert, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FDA63@AcuExch.aculab.com>
On Thu, 2014-11-27 at 12:25 +0000, David Laight wrote:
> From: Joe Perches
> > On Wed, 2014-11-26 at 10:34 -0800, Alexei Starovoitov wrote:
> > > On Wed, Nov 26, 2014 at 10:02 AM, Joe Perches <joe@perches.com> wrote:
> > > > On Wed, 2014-11-26 at 09:23 -0800, Alexei Starovoitov wrote:
> > > >> On Wed, Nov 26, 2014 at 8:58 AM, Joe Perches <joe@perches.com> wrote:
> > > >
> > > >> > Is there any value in reordering these tests for frequency
> > > >> > or maybe using | instead of || to avoid multiple jumps?
> > > >>
> > > >> probably not. It's not a critical path.
> > > >> compiler may fuse conditions depending on values anyway.
> > > >> If it was a critical path, we could have used
> > > >> (1 << reg) & mask trick.
> > > >> I picked explicit 'return true' else 'return false' here,
> > > >> because it felt easier to read. Just a matter of taste.
> > > >
> > > > There is a size difference though: (allyesconfig)
> > > >
> > > > $ size arch/x86/net/built-in.o*
> > > > text data bss dec hex filename
> > > > 12999 1012 4336 18347 47ab arch/x86/net/built-in.o.new
> > > > 13177 1076 4592 18845 499d arch/x86/net/built-in.o.old
> > >
> > > interesting. Compiler obviously thinks that 178 byte increase
> > > with -O2 is the right trade off. Which I agree with :)
> > >
> > > If I think dropping 'inline' and using -Os will give bigger savings...
> >
> > This was allyesconfig which already uses -Os
> >
> > Using -O2, there is no difference using inline
> > or not, but the size delta with the bitmask is
> > much larger
> >
> > $ size arch/x86/net/built-in.o* (allyesconfig, but not -Os)
> > text data bss dec hex filename
> > 13410 820 3624 17854 45be arch/x86/net/built-in.o.new
> > 16130 884 4200 21214 52de arch/x86/net/built-in.o.old
> > 16130 884 4200 21214 52de arch/x86/net/built-in.o.static
>
> That is quite a big % change in the code size.
> Why the change in data?
$ objdump -t arch/x86/net/bpf_jit_comp.o.new > new
$ objdump -t arch/x86/net/bpf_jit_comp.o.old > old
$ diff -urN old new
--- old 2014-11-27 10:31:36.654373756 -0800
+++ new 2014-11-27 10:31:31.254373453 -0800
@@ -1,5 +1,5 @@
-arch/x86/net/bpf_jit_comp.o.old: file format elf64-x86-64
+arch/x86/net/bpf_jit_comp.o.new: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l df *ABS* 0000000000000000 bpf_jit_comp.c
@@ -8,28 +8,26 @@
0000000000000000 l d .bss 0000000000000000 .bss
0000000000000000 l d .text.unlikely 0000000000000000 .text.unlikely
0000000000000000 l F .text 000000000000001f jit_fill_hole
-0000000000000098 l O .bss 0000000000000008 __gcov0.jit_fill_hole
+0000000000000060 l O .bss 0000000000000008 __gcov0.jit_fill_hole
0000000000000000 l d .rodata.str1.1 0000000000000000 .rodata.str1.1
0000000000000000 l d .rodata.str1.8 0000000000000000 .rodata.str1.8
-0000000000000020 l F .text 00000000000030a2 do_jit
-00000000000000c0 l O .bss 0000000000000b68 __gcov0.do_jit
+0000000000000020 l F .text 000000000000260b do_jit
+0000000000000080 l O .bss 0000000000000970 __gcov0.do_jit
00000000000006e0 l O .rodata 0000000000000034 reg2hex
0000000000000000 l d .rodata 0000000000000000 .rodata
-0000000000000060 l O .bss 0000000000000038 __gcov0.add_2mod
-0000000000000c28 l O .bss 0000000000000008 __gcov0.bpf_jit_compile
-0000000000000c40 l O .bss 00000000000003f0 __gcov0.bpf_int_jit_compile
+00000000000009f0 l O .bss 0000000000000008 __gcov0.bpf_jit_compile
+0000000000000a00 l O .bss 00000000000003f0 __gcov0.bpf_int_jit_compile
0000000000000040 l O .bss 0000000000000020 __gcov0.bpf_jit_dump
-0000000000001040 l O .bss 0000000000000028 __gcov0.bpf_jit_free
+0000000000000e00 l O .bss 0000000000000028 __gcov0.bpf_jit_free
0000000000000010 l O .bss 0000000000000018 __gcov0.bpf_prog_unlock_free
0000000000000000 l d .text.startup 0000000000000000 .text.startup
0000000000000000 l F .text.startup 0000000000000012 _GLOBAL__sub_I_65535_0_bpf_jit_compile
0000000000000000 l d .init_array 0000000000000000 .init_array
-0000000000000340 l O .data 0000000000000028 __gcov_.bpf_jit_free
-0000000000000260 l O .data 0000000000000028 __gcov_.bpf_int_jit_compile
-0000000000000220 l O .data 0000000000000028 __gcov_.bpf_jit_compile
-00000000000001e0 l O .data 0000000000000028 __gcov_.do_jit
-00000000000001a0 l O .data 0000000000000028 __gcov_.jit_fill_hole
-0000000000000160 l O .data 0000000000000028 __gcov_.add_2mod
+0000000000000300 l O .data 0000000000000028 __gcov_.bpf_jit_free
+0000000000000220 l O .data 0000000000000028 __gcov_.bpf_int_jit_compile
+00000000000001e0 l O .data 0000000000000028 __gcov_.bpf_jit_compile
+00000000000001a0 l O .data 0000000000000028 __gcov_.do_jit
+0000000000000160 l O .data 0000000000000028 __gcov_.jit_fill_hole
0000000000000120 l O .data 0000000000000028 __gcov_.bpf_jit_dump
00000000000000e0 l O .data 0000000000000028 __gcov_.bpf_prog_unlock_free
00000000000000a0 l O .data 0000000000000028 __gcov_.__get_order
@@ -43,17 +41,17 @@
0000000000000000 *UND* 0000000000000000 memset
0000000000000000 *UND* 0000000000000000 sk_load_half
0000000000000000 *UND* 0000000000000000 printk
+0000000000000000 *UND* 0000000000000000 sk_load_byte
+0000000000000000 *UND* 0000000000000000 sk_load_word
0000000000000000 *UND* 0000000000000000 sk_load_half_positive_offset
0000000000000000 *UND* 0000000000000000 sk_load_half_negative_offset
-0000000000000000 *UND* 0000000000000000 sk_load_word_positive_offset
-0000000000000000 *UND* 0000000000000000 sk_load_byte
0000000000000000 *UND* 0000000000000000 sk_load_byte_positive_offset
0000000000000000 *UND* 0000000000000000 sk_load_byte_negative_offset
-0000000000000000 *UND* 0000000000000000 sk_load_word
+0000000000000000 *UND* 0000000000000000 sk_load_word_positive_offset
0000000000000000 *UND* 0000000000000000 __bpf_call_base
0000000000000000 *UND* 0000000000000000 sk_load_word_negative_offset
-00000000000030d0 g F .text 0000000000000013 bpf_jit_compile
-00000000000030f0 g F .text 0000000000000352 bpf_int_jit_compile
+0000000000002630 g F .text 0000000000000013 bpf_jit_compile
+0000000000002650 g F .text 0000000000000352 bpf_int_jit_compile
0000000000000000 g O .data..read_mostly 0000000000000004 bpf_jit_enable
0000000000000000 *UND* 0000000000000000 __kmalloc
0000000000000000 *UND* 0000000000000000 bpf_jit_binary_alloc
@@ -62,7 +60,7 @@
0000000000000000 *UND* 0000000000000000 set_memory_ro
0000000000000000 *UND* 0000000000000000 kfree
0000000000000000 *UND* 0000000000000000 bpf_jit_binary_free
-0000000000003450 g F .text 000000000000008c bpf_jit_free
+00000000000029b0 g F .text 000000000000008c bpf_jit_free
0000000000000000 *UND* 0000000000000000 set_memory_rw
0000000000000000 *UND* 0000000000000000 __bpf_prog_free
0000000000000000 *UND* 0000000000000000 __gcov_init
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-27 18:34 UTC (permalink / raw)
To: Alex Strizhevsky
Cc: Bjørn Mork, ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg,
Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg,
youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg
In-Reply-To: <CAPChA0cLuvRpYTYuFoi3bewqASgf_oZHSz5yQQ8JYm96dZ4-TQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3996 bytes --]
What I suspect, is that all this mess started when Huawei introduce new
firmware releases that changed something in the IPV6 support.
Bjorn - do you remember when a guy called Thomas reported us a problem about an
LTE huawei modem that wasn't working with huawei_cdc_ncm?
And you then discovered the problem was originated from some changes in the
ordering of cdc_ncm actions; what happened then?
Did Thomas get his modem back to working state?
Sorry Thomas - you wilol read this message but I don't remember your surname,
and might get confused with other people called Thomas.
On Thu, 27 Nov 2014, Alex Strizhevsky wrote:
==Date: Thu, 27 Nov 2014 13:36:37
==From: Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==To: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org,
== Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
== linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
== Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==Subject: Re: Is this 32-bit NCM?
==
==Adding my colleagues - Eli, Kevin & Midge.
==
==Any ideas are welcome ;)
==
==
==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
== Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
==
== > Ok - we can arrive to some ocnclusions regarding the E3272.
== > First of all - the modem seems buggy enough to not be able to
== handle requests
== > for different formats. You need to unplug and re-plug it, but
== this is onlyan
== > impression and is reasonable.
== >
== > Then - the modem will accept to ndisdup the connection with
== > at^ndisdup=1,1,"internet"
== > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
== handling messages and
== > the modem stops here.
== > If we use the cdc_ncm 32-bit driver (modified) we get lotfs of
== > ^dsflorpt
== > that's how it should be.
== > So I think we can say that something is changing.
== > Then there's the alignment problem you mentioned in your
== previous reply. And
== > this is hard to solve.
== > could you try to help me understand where the problem is?
== > I feel like we are very close to the solution but something
== isn't working.
== > Or might be just try to change the 16 bit driver?
==
==If you use a recent version of the driver as a basis, then you get the
==CDC NCM NTB parameters in sysfs (if not, then you need to enable
==debugging and look in the log for these values). For example:
==
==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
==
==
==The possible problem I am thinking of is proper handling of the
==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame
==Alignment" in the spec. Which is confusing as hell, but if I
==understand
==it correctly then we are supposed to align the start of the IP packets
==(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor
==number
==as long as the wNdp*PayloadRemainder is 0.
==
==
==Bjørn
==
==
==
==
^ permalink raw reply
* Re: [PATCH v3] can: Convert to runtime_pm
From: Sören Brinkmann @ 2014-11-27 18:23 UTC (permalink / raw)
To: Kedareswara rao Appana
Cc: wg, mkl, michal.simek, grant.likely, robh+dt, devicetree, netdev,
linux-kernel, linux-can, Kedareswara rao Appana, linux-arm-kernel
In-Reply-To: <6b6db31d46074512a322eae6e4ef64d4@BN1BFFO11FD038.protection.gbl>
Hi Kedar,
On Thu, 2014-11-27 at 06:38PM +0530, Kedareswara rao Appana wrote:
> Instead of enabling/disabling clocks at several locations in the driver,
> use the runtime_pm framework. This consolidates the actions for
> runtime PM in the appropriate callbacks and makes the driver more
> readable and mantainable.
>
> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v3:
> - Converted the driver to use runtime_pm.
> Changes for v2:
> - Removed the struct platform_device* from suspend/resume
> as suggest by Lothar.
>
> drivers/net/can/xilinx_can.c | 119 +++++++++++++++++++++++++----------------
> 1 files changed, 72 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 8a998e3..1be28ed 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -32,6 +32,7 @@
> #include <linux/can/dev.h>
> #include <linux/can/error.h>
> #include <linux/can/led.h>
> +#include <linux/pm_runtime.h>
>
> #define DRIVER_NAME "xilinx_can"
>
> @@ -138,7 +139,7 @@ struct xcan_priv {
> u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
> void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
> u32 val);
> - struct net_device *dev;
> + struct device *dev;
> void __iomem *reg_base;
> unsigned long irq_flags;
> struct clk *bus_clk;
> @@ -842,6 +843,13 @@ static int xcan_open(struct net_device *ndev)
> struct xcan_priv *priv = netdev_priv(ndev);
> int ret;
>
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime CAN resume failed(%d)\n\r",
There might be other issues than the resume that make this fail. It
should probably just say 'pm_runtime_get failed'.
The CAN in the string should not be needed, the netdev_err macro makes
sure the device name is printed.
Can we have a space between 'failed' and the error code?
There should not be a '\r'
> + __func__, ret);
> + return ret;
> + }
> +
> ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
> ndev->name, ndev);
> if (ret < 0) {
> @@ -849,29 +857,17 @@ static int xcan_open(struct net_device *ndev)
> goto err;
> }
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable device clock\n");
> - goto err_irq;
> - }
> -
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable bus clock\n");
> - goto err_can_clk;
> - }
> -
> /* Set chip into reset mode */
> ret = set_reset_mode(ndev);
> if (ret < 0) {
> netdev_err(ndev, "mode resetting failed!\n");
> - goto err_bus_clk;
> + goto err_irq;
> }
>
> /* Common open */
> ret = open_candev(ndev);
> if (ret)
> - goto err_bus_clk;
> + goto err_irq;
>
> ret = xcan_chip_start(ndev);
> if (ret < 0) {
> @@ -887,13 +883,11 @@ static int xcan_open(struct net_device *ndev)
>
> err_candev:
> close_candev(ndev);
> -err_bus_clk:
> - clk_disable_unprepare(priv->bus_clk);
> -err_can_clk:
> - clk_disable_unprepare(priv->can_clk);
> err_irq:
> free_irq(ndev->irq, ndev);
> err:
> + pm_runtime_put(priv->dev);
> +
> return ret;
> }
>
> @@ -910,12 +904,11 @@ static int xcan_close(struct net_device *ndev)
> netif_stop_queue(ndev);
> napi_disable(&priv->napi);
> xcan_chip_stop(ndev);
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
> free_irq(ndev->irq, ndev);
> close_candev(ndev);
>
> can_led_event(ndev, CAN_LED_EVENT_STOP);
> + pm_runtime_put(priv->dev);
>
> return 0;
> }
> @@ -934,27 +927,21 @@ static int xcan_get_berr_counter(const struct net_device *ndev,
> struct xcan_priv *priv = netdev_priv(ndev);
> int ret;
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret)
> - goto err;
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime resume failed(%d)\n\r",
> + __func__, ret);
As above.
Sören
^ permalink raw reply
* Re: [PATCH] staging: r8188eu: Add new device ID for DLink GO-USB-N150
From: Larry Finger @ 2014-11-27 16:47 UTC (permalink / raw)
To: Greg KH; +Cc: devel, netdev
In-Reply-To: <20141127162854.GB1404@kroah.com>
On 11/27/2014 10:28 AM, Greg KH wrote:
> On Thu, Nov 27, 2014 at 10:10:21AM -0600, Larry Finger wrote:
>> The DLink GO-USB-N150 with revision B1 uses this driver.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>> drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
>> index 65a257f..d3cbcc4 100644
>> --- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
>> +++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
>> @@ -47,6 +47,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
>> {USB_DEVICE(0x07b8, 0x8179)}, /* Abocom - Abocom */
>> {USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
>> {USB_DEVICE(0x2001, 0x3310)}, /* Dlink DWA-123 REV D1 */
>> + {USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
>> {USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
>> {} /* Terminating entry */
>> };
>> --
>> 2.1.2
>
> Should this also go to stable kernels?
Yes, it should. Sorry for missing that Cc.
Larry
^ permalink raw reply
* Re: [PATCH] staging: r8188eu: Add new device ID for DLink GO-USB-N150
From: Greg KH @ 2014-11-27 16:28 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, netdev
In-Reply-To: <1417104621-9504-1-git-send-email-Larry.Finger@lwfinger.net>
On Thu, Nov 27, 2014 at 10:10:21AM -0600, Larry Finger wrote:
> The DLink GO-USB-N150 with revision B1 uses this driver.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> index 65a257f..d3cbcc4 100644
> --- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> +++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> @@ -47,6 +47,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
> {USB_DEVICE(0x07b8, 0x8179)}, /* Abocom - Abocom */
> {USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
> {USB_DEVICE(0x2001, 0x3310)}, /* Dlink DWA-123 REV D1 */
> + {USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
> {USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
> {} /* Terminating entry */
> };
> --
> 2.1.2
Should this also go to stable kernels?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] staging: r8188eu: Add new device ID for DLink GO-USB-N150
From: Larry Finger @ 2014-11-27 16:10 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
The DLink GO-USB-N150 with revision B1 uses this driver.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 65a257f..d3cbcc4 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -47,6 +47,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(0x07b8, 0x8179)}, /* Abocom - Abocom */
{USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
{USB_DEVICE(0x2001, 0x3310)}, /* Dlink DWA-123 REV D1 */
+ {USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
{USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
{} /* Terminating entry */
};
--
2.1.2
^ permalink raw reply related
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-11-27 15:58 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201411271622.58916@pali>
On Thu, Nov 27, 2014 at 04:22:58PM +0100, Pali Rohár wrote:
> On Thursday 27 November 2014 16:16:55 Greg Kroah-Hartman wrote:
> > On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > > On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > > > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> > >
> > > <pali.rohar@gmail.com> wrote:
> > > > > Hello,
> > > > >
> > > > > wifi driver wl1251 needs NVS calibration data for
> > > > > working. These data are loaded by driver via
> > > > > request_firmware from userspace file:
> > > > > ti-connectivity/wl1251-nvs.bin. In linux-fimrware git
> > > > > tree there is generic wl1251-nvs.bin file which is used
> > > > > by default.
> > > > >
> > > > > Driver wl1251 is used on Nokia N900 cellphone for its
> > > > > wifi chip. This cellphone has one special MTD partition
> > > > > (called CAL) where are stored some configuration data
> > > > > in special binary (key-value) format. And there is also
> > > > > stored correct calibration data for specific device
> > > > > (each device has different data). It is preferred to
> > > > > use those data instead generic one (provided by
> > > > > linux-firmware git tree).
> > > > >
> > > > > Now my question is: How to correctly load calibration
> > > > > data from special Nokia N900 CAL partition into wl1251
> > > > > kernel driver?
> > > >
> > > > It is better to let user space script handle the request.
> > >
> > > Yes, this makes sense. Implementing CAL parser in kernel
> > > wl1251 driver would be hard...
> > >
> > > > > By default kernel reads ti-connectivity/wl1251-nvs.bin
> > > > > file from VFS if exists without any userspace support.
> > > > > If it fails then it fallback to loading via udev.
> > > >
> > > > You can remove or rename this file so that loading from
> > > > user space can be triggered.
> > >
> > > It is no so easy... In case when CAL does not contains NVS
> > > data then we want to use this generic NVS file. And telling
> > > everybody to rename this is file is not good solution...
> >
> > But that's up to your system configuration, not the kernel.
> > Make a userspace package for the firmware that creates it in
> > the format you need it to be in, for the hardware you have,
> > and then there would not be any need for a kernel change,
> > right?
> >
> > greg k-h
>
> Not so simple as you think. Some parts of NVS data are configured
> based on location and cellular station. Data are not static.
Then you need a dynamic program that you control, in userspace, to dump
the needed data into the kernel. Don't try to do it with "static"
firmware files. Use the binary sysfs file interface for this if you
want.
good luck,
greg k-h
^ permalink raw reply
* Re: [PATCH net] rtnetlink: release net refcnt on error in do_setlink()
From: Eric W. Biederman @ 2014-11-27 15:48 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev
In-Reply-To: <1417079775-9287-1-git-send-email-nicolas.dichtel@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> rtnl_link_get_net() holds a reference on the 'struct net', we need to release
> it in case of error.
>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Doh!
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
> net/core/rtnetlink.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index b9b7dfaf202b..76321ea442c3 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1498,6 +1498,7 @@ static int do_setlink(const struct sk_buff *skb,
> goto errout;
> }
> if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
> + put_net(net);
> err = -EPERM;
> goto errout;
> }
^ permalink raw reply
* Re: bug in networking code causes GPF
From: Дениска-редиска @ 2014-11-27 15:41 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: linux-net, netdev, linux-kernel, minipli, fw
well, I will try to disable CONFIG_PAX_MEMORY_SANITIZE.
Will take some time to make sure that this resolve the issue
Цитирование Daniel Borkmann <dborkman@redhat.com> :
> On 11/27/2014 02:35 PM, Дениска-редиска wrote:
> > hello,
> >
> > i run ipvs DR on 2 servers under heavy load - up to 1Gbps of traffic.
> > Time to time the server where ipvs runs master IP (VIP) get general protection fault. Switching master to another server make no difference - after some time GPF come. So I assume it is not hardware issue.
> >
> > There are logs from both servers with different kernels (i run kernel with grsecurity patch set from Gentoo hardened portage tree):
> Hmm, looks pretty much like ...
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/54903
> ... which was a bug in the grsec patch set.
> Does your grsec kernel have:
> commit 0fa213cce614ad25a79acbd06f37f1e9022134d9
> Author: Brad Spengler <spender@grsecurity.net>
> Date: Fri Oct 31 17:29:20 2014 -0400
> From: Mathias Krause <minipli@googlemail.com>
> To: PaX Team <pageexec@freemail.hu>
> Cc: Brad Spengler <spender@grsecurity.net>, Mathias Krause
> <minipli@googlemail.com>
> Subject: [PATCH] pax: don't sanitize RCU slab caches
> We cannot sanitize SLAB_DESTROY_BY_RCU slab caches in kmem_cache_free()
> as there might be readers in this RCU period, wanting to access the
> object.
> Fix this, for now, by marking those with SLAB_NO_SANITIZE. Hopefully we
> can have a real fix later on. But this should fix the RCU stalls and
> netfilter conntrack related problems.
> This patch should go on top of the previous patch.
> Signed-off-by: Mathias Krause <minipli@googlemail.com>
> > [354497.931834] general protection fault: 0000 [#1] SMP
> > [354497.931903] CPU: 14 PID: 0 Comm: swapper/14 Not tainted 3.13.10-hardened.standart.20140515 #1
> > [354497.931993] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
> > [354497.932082] task: ffff88021e4b2ca0 ti: ffff88021e4b3100 task.ti: ffff88021e4b3100
> > [354497.932167] RIP: 0010:[<ffffffff81653ca2>] [<ffffffff81653ca2>] ffffffff81653ca2
> > [354497.932278] RSP: 0000:ffff88021fd03b98 EFLAGS: 00010246
> > [354497.932330] RAX: 0000000000013ba0 RBX: fefefefefefefefe RCX: 000000000001bc30
> > [354497.932413] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > [354497.932497] RBP: ffff88021fd03c40 R08: 00000000cacb7f0b R09: ffff88021fd03c58
> > [354497.932580] R10: ffffffffffffffff R11: ffff88041de33280 R12: 8000000000000000
> > [354497.932663] R13: 0000000000003786 R14: ffffffff81a82540 R15: 0000000000000000
> > [354497.932749] FS: 000003853a8a7740(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
> > [354497.932836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [354497.932891] CR2: 000003d8a933b2d0 CR3: 000000000174a000 CR4: 00000000000407f0
> > [354497.932973] Stack:
> > [354497.933013] 0000000000000000 ffffffff81a82540 00000000de1b1efe 0000000000000000
> > [354497.933110] ffff88021fd03c40 ffffffff81653f6d ffffffff81a92cc0 ffffffff81a82540
> > [354497.933206] ffff88041d70c500 0000000000000000 00000000de1b1efe ffffffff81654f6c
> > [354497.933304] Call Trace:
> > [354497.933347] <IRQ>
> > [354497.933357] [<ffffffff81653f6d>] ? __nf_conntrack_find_get+0x28/0x13b
> > [354497.933484] [<ffffffff81654f6c>] ? nf_conntrack_in+0x253/0x73e
> > [354497.933544] [<ffffffff8164eeb6>] ? nf_iterate+0x40/0x7d
> > [354497.933601] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
> > [354497.933658] [<ffffffff8164ef5f>] ? nf_hook_slow+0x6c/0x104
> > [354497.933714] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
> > [354497.933770] [<ffffffff816a98c8>] ? ip_rcv+0x313/0x35f
> > [354497.933824] [<ffffffff816a93d1>] ? ip_local_deliver_finish+0xb8/0x11f
> > [354497.933885] [<ffffffff81627dfd>] ? __netif_receive_skb_core+0x44d/0x4e2
> > [354497.933944] [<ffffffff8162afba>] ? netif_receive_skb+0x4c/0x81
> > [354497.934000] [<ffffffff8162b488>] ? napi_gro_receive+0x35/0x7a
> > [354497.934058] [<ffffffff81515ddc>] ? igb_poll+0xa49/0xd13
> > [354497.934115] [<ffffffff810ce5b1>] ? __wake_up+0x38/0x49
> > [354497.934169] [<ffffffff8162b773>] ? net_rx_action+0xa6/0x172
> > [354497.934225] [<ffffffff810a31cc>] ? __do_softirq+0xb9/0x1ae
> > [354497.934280] [<ffffffff810a3499>] ? irq_exit+0x37/0x7a
> > [354497.934335] [<ffffffff81003ce2>] ? do_IRQ+0x96/0xb0
> > [354497.934389] [<ffffffff81725a97>] ? common_interrupt+0x97/0x97
> > [354497.934441] <EOI>
> > [354497.934451] [<ffffffff810e3080>] ? update_ts_time_stats+0x30/0x76
> > [354497.934548] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
> > [354497.934607] [<ffffffff81009d23>] ? default_idle+0x3/0x9
> > [354497.934676] [<ffffffff8100a333>] ? arch_cpu_idle+0x6/0x1e
> > [354497.934732] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
> > [354497.934791] [<ffffffff810d434a>] ? cpu_startup_entry+0xe9/0x15b
> > [354497.934850] [<ffffffff81024ccf>] ? start_secondary+0x2f9/0x32c
> > [354497.934903] Code: c2 85 d2 49 8b 86 d0 04 00 00 74 14 66 45 85 ff 75 0e 65 ff 40 04 e8 85 f6 a4 ff 48 89 d8 eb 69 65 ff 00 48 8b 1b f6 c3 01 75 0f <8b> 43 10 39 45 00 b8 00 00 00 00 74 83 eb 9d 48 d1 eb 4c 39 eb
> > [354497.935402] RIP [<ffffffff81653ca2>] ffffffff81653ca2
> > [354497.935456] RSP <ffff88021fd03b98>
> > [354497.935965] ---[ end trace 7d6f660245b2d541 ]---
> > [354497.936080] Kernel panic - not syncing: Fatal exception in interrupt
> > [354498.016801] Rebooting in 10 seconds.
> >
> >
> > [674944.621564] general protection fault: 0000 [#1] SMP
> > [674944.621637] CPU: 12 PID: 17984 Comm: nginx Not tainted 3.15.10-hardened-r1.standart.20140925 #1
> > [674944.621728] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
> > [674944.621817] task: ffff88021e1d7700 ti: ffff88021e1d7c68 task.ti: ffff88021e1d7c68
> > [674944.621903] RIP: 0010:[<ffffffff816f2be8>] [<ffffffff816f2be8>] ffffffff816f2be8
> > [674944.621990] RSP: 0000:ffff88021fc03ce8 EFLAGS: 00010246
> > [674944.622057] RAX: ffffc90011901000 RBX: 822098c2102098c2 RCX: 000000005823edca
> > [674944.622143] RDX: fefefefefefefefe RSI: 000000009e90f1ad RDI: ffffffff81a8ad40
> > [674944.622226] RBP: 000000000050abb3 R08: 000000000050abb3 R09: 000000000001f106
> > [674944.622310] R10: ffffea00100cbd80 R11: ffffea00100cbd80 R12: 8000000000000000
> > [674944.622394] R13: ffffffff81a8ad40 R14: 0000000049c3f106 R15: ffffc900119f9830
> > [674944.622479] FS: 0000029d6fd04740(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
> > [674944.622566] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [674944.622619] CR2: ffffffffff600400 CR3: 0000000001787000 CR4: 00000000000407f0
> > [674944.622701] Stack:
> > [674944.622741] ffffffff816e9360 ffffffff00000050 ffffffff822098c2 abb3000280000000
> > [674944.622839] ffff88006e9c2b00 ffff88011cbd1bce ffff88021e0c0000 0000000000000008
> > [674944.622935] ffffffff81a955b0 ffffffff8170920a ffff880100000003 0000000000000008
> > [674944.623031] Call Trace:
> > [674944.623077] <IRQ>
> > [674944.623087] [<ffffffff816e9360>] ? inet_del_offload+0x39/0x39
> > [674944.623192] [<ffffffff8170920a>] ? tcp_v4_early_demux+0x14c/0x1bd
> > [674944.623250] [<ffffffff816e93b0>] ? ip_rcv_finish+0x50/0x2c1
> > [674944.623326] [<ffffffff8165ee92>] ? __netif_receive_skb_core+0x3c8/0x456
> > [674944.623386] [<ffffffff8165f10c>] ? netif_receive_skb_internal+0x4c/0x81
> > [674944.623447] [<ffffffff816623b3>] ? napi_gro_receive+0x36/0x7c
> > [674944.623511] [<ffffffff815485a5>] ? igb_poll+0xa8b/0xd5b
> > [674944.623572] [<ffffffff810f7fda>] ? __note_gp_changes+0x31/0x61
> > [674944.623630] [<ffffffff816626cf>] ? net_rx_action+0xa6/0x172
> > [674944.623688] [<ffffffff810bc995>] ? __do_softirq+0xf6/0x1fb
> > [674944.623744] [<ffffffff810bcbf4>] ? irq_exit+0x38/0x7c
> > [674944.623798] [<ffffffff81003ce3>] ? do_IRQ+0xb3/0xce
> > [674944.623853] [<ffffffff81767217>] ? common_interrupt+0x97/0x97
> > [674944.623906] <EOI>
> > [674944.623917] Code: 6a d4 75 0e 48 39 5a c8 74 51 eb 06 3b 44 24 50 74 50 4c 89 4c 24 08 e8 e8 fe ff ff 4c 8b 4c 24 08 eb 83 48 8b 12 f6 c2 01 75 0b <44> 39 72 d0 75 f2 e9 75 ff ff ff 48 d1 ea 4c 39 ca 0f 85 64 ff
> > [674944.624456] RIP [<ffffffff816f2be8>] ffffffff816f2be8
> > [674944.624536] RSP <ffff88021fc03ce8>
> > [674944.625020] ---[ end trace 8035e2b5322bab00 ]---
> > [674944.625126] Kernel panic - not syncing: Fatal exception in interrupt
> > [674944.706563] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
> > [674944.706711] Rebooting in 10 seconds.
> >
> >
> > [7523332.314991] general protection fault: 0000 [#1] SMP
> > [7523332.315078] CPU: 4 PID: 25432 Comm: nginx Not tainted 3.15.8-hardened.standart.20140901 #1
> > [7523332.315172] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.0 09/10/2012
> > [7523332.315266] task: ffff88041eb98000 ti: ffff88041eb98568 task.ti: ffff88041eb98568
> > [7523332.315355] RIP: 0010:[<ffffffff8168db79>] [<ffffffff8168db79>] ffffffff8168db79
> > [7523332.315446] RSP: 0018:ffff88021fa03bf8 EFLAGS: 00010246
> > [7523332.316983] RAX: 00000000000149c0 RBX: ffffffff81a8ac80 RCX: 00000000000011d5
> > [7523332.317070] RDX: 0000000000000000 RSI: 0000000000008ea8 RDI: ffffffff81a8acfe
> > [7523332.317187] RBP: ffff88021fa03c5c R08: 00000000b96542ae R09: ffff88021fa03c74
> > [7523332.317274] R10: 0000000000000002 R11: ffff880238b8ce00 R12: 8000000000000000
> > [7523332.317360] R13: fefefefefefefefe R14: 0000000000000000 R15: 0000000047567b68
> > [7523332.317448] FS: 0000031d200c5740(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
> > [7523332.317538] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [7523332.317594] CR2: 000004373dcef000 CR3: 0000000001779000 CR4: 00000000000007f0
> > [7523332.317679] Stack:
> > [7523332.317722] 0000000000000000 ffffffff81a8ac80 ffff880003e08200 0000000000000000
> > [7523332.317824] ffffffff81a9bf60 ffffffff8168ef87 ffffffff81a9bf60 ffffffff81a96970
> > [7523332.317925] 0000000047567b68 ffffffff81a96970 0000000281a90002 0000000000000014
> > [7523332.318026] Call Trace:
> > [7523332.318072] <IRQ>
> > [7523332.318085] [<ffffffff8168ef87>] ? nf_conntrack_in+0x2c1/0x846
> > [7523332.318199] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
> > [7523332.318259] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
> > [7523332.318321] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
> > [7523332.318393] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
> > [7523332.318453] [<ffffffff816eacf2>] ? ip_rcv+0x2f4/0x356
> > [7523332.318512] [<ffffffff81660173>] ? __netif_receive_skb_core+0x3d9/0x410
> > [7523332.318575] [<ffffffff8166039c>] ? netif_receive_skb_internal+0x6d/0x77
> > [7523332.318640] [<ffffffff816634c1>] ? napi_gro_receive+0x36/0x7c
> > [7523332.318702] [<ffffffff8154a30d>] ? igb_poll+0xa46/0xd09
> > [7523332.318762] [<ffffffff813bbd0d>] ? __list_add+0x1b/0x37
> > [7523332.318820] [<ffffffff816637d2>] ? net_rx_action+0xa0/0x171
> > [7523332.318882] [<ffffffff810bcb7a>] ? __do_softirq+0xf7/0x1fa
> > [7523332.318943] [<ffffffff8176a29c>] ? do_softirq_own_stack+0x1c/0x30
> > [7523332.318999] <EOI>
> > [7523332.319013] [<ffffffff810bcccb>] ? do_softirq+0x24/0x2c
> > [7523332.319112] [<ffffffff810bcd39>] ? __local_bh_enable_ip+0x66/0x74
> > [7523332.319174] [<ffffffff8172f029>] ? ipt_do_table+0x5c6/0x5f0
> > [7523332.319235] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
> > [7523332.319293] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
> > [7523332.319354] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
> > [7523332.319412] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
> > [7523332.319473] [<ffffffff816ee3a2>] ? __ip_local_out+0x64/0x6e
> > [7523332.319533] [<ffffffff8164f4a3>] ? __sk_dst_check+0x34/0x63
> > [7523332.319617] [<ffffffff816ee3be>] ? ip_local_out_sk+0x12/0x39
> > [7523332.319676] [<ffffffff816eea83>] ? ip_queue_xmit+0x2ab/0x2db
> > [7523332.319739] [<ffffffff81703a1e>] ? tcp_transmit_skb+0x6eb/0x735
> > [7523332.319801] [<ffffffff81704323>] ? tcp_write_xmit+0x82e/0x969
> > [7523332.319861] [<ffffffff816f7278>] ? tcp_sendpage+0x50b/0x5e4
> > [7523332.319923] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> > [7523332.319986] [<ffffffff8171a807>] ? inet_sendpage+0xbc/0xe0
> > [7523332.320045] [<ffffffff8164eacc>] ? kernel_sendpage+0x49/0x59
> > [7523332.320104] [<ffffffff8164eb23>] ? sock_sendpage+0x47/0x53
> > [7523332.320163] [<ffffffff81184658>] ? pipe_to_sendpage+0x6f/0x7c
> > [7523332.320223] [<ffffffff81185aa8>] ? splice_from_pipe_feed+0x7f/0x10e
> > [7523332.320285] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> > [7523332.320347] [<ffffffff81185c2e>] ? __splice_from_pipe+0x3a/0x6b
> > [7523332.320408] [<ffffffff81185dff>] ? splice_from_pipe+0x66/0x87
> > [7523332.320468] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> > [7523332.320533] [<ffffffff811845df>] ? direct_splice_actor+0x3f/0x49
> > [7523332.320599] [<ffffffff811860f5>] ? splice_direct_to_actor+0xd3/0x18d
> > [7523332.320661] [<ffffffff811845a0>] ? generic_pipe_buf_nosteal+0xc/0xc
> > [7523332.320723] [<ffffffff81186249>] ? do_splice_direct+0x9a/0xb6
> > [7523332.320783] [<ffffffff8115e7f2>] ? do_sendfile+0x182/0x32a
> > [7523332.320856] [<ffffffff811602bd>] ? SyS_sendfile64+0x137/0x1bc
> > [7523332.320916] [<ffffffff81768f37>] ? system_call_fastpath+0x16/0x1b
> > [7523332.320972] Code: 00 02 00 00 48 c7 c7 4d db 68 81 65 ff 40 04 e8 71 f1 a2 ff 4d 85 ed 75 58 e9 94 01 00 00 65 ff 00 4d 8b 6d 00 41 f6 c5 01 75 18 <41> 8b 55 10 31 c0 39 55 00 41 8a 7d 37 0f 85 14 ff ff ff e9 e7
> > [7523332.321522] RIP [<ffffffff8168db79>] ffffffff8168db79
> > [7523332.321579] RSP <ffff88021fa03bf8>
> > [7523332.322094] ---[ end trace 0e21b79561002306 ]---
> > [7523332.322210] Kernel panic - not syncing: Fatal exception in interrupt
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-11-27 15:34 UTC (permalink / raw)
To: Pali Rohár
Cc: Greg Kroah-Hartman, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201411271624.03066@pali>
On Thu, Nov 27, 2014 at 11:24 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 27 November 2014 16:14:48 Greg Kroah-Hartman wrote:
>> On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
>> > Which userspace helper programs for (automatic) firmware
>> > loading are used? Can be udev configured to use own program
>> > for loading firmware instead that udev integrated which
>> > looking for firmware only in /lib/firmware files?
>>
>> The code to load firmware from userspace has been removed from
>> udev, so that's not going to work at all, sorry.
>>
>> greg k-h
>
> Ok and how to load (dynamic) firmware files into kernel? What is
> preferred way if not udev (because it removed that support)?
As I said, it isn't difficult to write a helper with uevent monitor for
your case, and you can refer to mdev or android's implementation.
Thanks,
Ming Lei
^ permalink raw reply
* [PATCH net-next] netpoll: delete defconfig references to obsolete NETPOLL_TRAP
From: Paul Gortmaker @ 2014-11-27 15:28 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Paul Gortmaker
In commit 9c62a68d13119a1ca9718381d97b0cb415ff4e9d ("netpoll:
Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") this
Kconfig option was removed. So remove references to it from
all defconfigs as well.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/arm/configs/davinci_all_defconfig | 1 -
arch/powerpc/configs/85xx/ge_imp3a_defconfig | 1 -
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1 -
arch/powerpc/configs/86xx/gef_sbc310_defconfig | 1 -
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 1 -
arch/powerpc/configs/86xx/sbc8641d_defconfig | 1 -
arch/powerpc/configs/c2k_defconfig | 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc/configs/ppc64e_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/powerpc/configs/pseries_defconfig | 1 -
arch/powerpc/configs/pseries_le_defconfig | 1 -
arch/tile/configs/tilegx_defconfig | 1 -
arch/tile/configs/tilepro_defconfig | 1 -
14 files changed, 14 deletions(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index f95f72d62db7..759f9b0053e2 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -97,7 +97,6 @@ CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_MOUSEDEV is not set
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m
diff --git a/arch/powerpc/configs/85xx/ge_imp3a_defconfig b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
index dc939de9b5b0..b4c4b469e320 100644
--- a/arch/powerpc/configs/85xx/ge_imp3a_defconfig
+++ b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
@@ -100,7 +100,6 @@ CONFIG_NETDEVICES=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_FS_ENET=y
diff --git a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
index e5a648115ada..7cb9719abf3d 100644
--- a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
+++ b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
@@ -113,7 +113,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
diff --git a/arch/powerpc/configs/86xx/gef_sbc310_defconfig b/arch/powerpc/configs/86xx/gef_sbc310_defconfig
index 8317b6010ba6..ecabf625d249 100644
--- a/arch/powerpc/configs/86xx/gef_sbc310_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc310_defconfig
@@ -114,7 +114,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
index 124d66f0282c..4a4a86fb0d3d 100644
--- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
@@ -165,7 +165,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
diff --git a/arch/powerpc/configs/86xx/sbc8641d_defconfig b/arch/powerpc/configs/86xx/sbc8641d_defconfig
index 1e151594c691..99ea8746bbaf 100644
--- a/arch/powerpc/configs/86xx/sbc8641d_defconfig
+++ b/arch/powerpc/configs/86xx/sbc8641d_defconfig
@@ -167,7 +167,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
diff --git a/arch/powerpc/configs/c2k_defconfig b/arch/powerpc/configs/c2k_defconfig
index 59734916986a..8a08d6dcb0b4 100644
--- a/arch/powerpc/configs/c2k_defconfig
+++ b/arch/powerpc/configs/c2k_defconfig
@@ -211,7 +211,6 @@ CONFIG_MV643XX_ETH=y
# CONFIG_NETDEV_10000 is not set
# CONFIG_ATM_DRIVERS is not set
CONFIG_NETCONSOLE=m
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_KEYBOARD is not set
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 20bc5e2d368d..5830d735c5c3 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -154,7 +154,6 @@ CONFIG_WINDFARM_PM121=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
CONFIG_VIRTIO_NET=m
CONFIG_VHOST_NET=m
diff --git a/arch/powerpc/configs/ppc64e_defconfig b/arch/powerpc/configs/ppc64e_defconfig
index c3a3269b0865..67885b2d70aa 100644
--- a/arch/powerpc/configs/ppc64e_defconfig
+++ b/arch/powerpc/configs/ppc64e_defconfig
@@ -103,7 +103,6 @@ CONFIG_NETDEVICES=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
CONFIG_VORTEX=y
CONFIG_ACENIC=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index fec5870f1818..ad6d6b5af7d7 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -629,7 +629,6 @@ CONFIG_SLIP_SMART=y
CONFIG_NET_FC=y
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_VIRTIO_NET=m
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_JOYDEV=m
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index dd2a9cab4b50..1f97364017c7 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -133,7 +133,6 @@ CONFIG_DM_UEVENT=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
CONFIG_VIRTIO_NET=m
CONFIG_VHOST_NET=m
diff --git a/arch/powerpc/configs/pseries_le_defconfig b/arch/powerpc/configs/pseries_le_defconfig
index d2008887eb8c..ac7ca5852827 100644
--- a/arch/powerpc/configs/pseries_le_defconfig
+++ b/arch/powerpc/configs/pseries_le_defconfig
@@ -134,7 +134,6 @@ CONFIG_DM_UEVENT=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
CONFIG_VIRTIO_NET=m
CONFIG_VHOST_NET=m
diff --git a/arch/tile/configs/tilegx_defconfig b/arch/tile/configs/tilegx_defconfig
index 91de7dd7427f..37dc9364c4a1 100644
--- a/arch/tile/configs/tilegx_defconfig
+++ b/arch/tile/configs/tilegx_defconfig
@@ -218,7 +218,6 @@ CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=y
CONFIG_VETH=m
CONFIG_NET_DSA_MV88E6060=y
diff --git a/arch/tile/configs/tilepro_defconfig b/arch/tile/configs/tilepro_defconfig
index c7702b7ab7a5..76a2781dec2c 100644
--- a/arch/tile/configs/tilepro_defconfig
+++ b/arch/tile/configs/tilepro_defconfig
@@ -337,7 +337,6 @@ CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=y
CONFIG_VETH=m
CONFIG_NET_DSA_MV88E6060=y
--
1.9.2
^ permalink raw reply related
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 15:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141127151448.GA23064@kroah.com>
[-- Attachment #1: Type: Text/Plain, Size: 683 bytes --]
On Thursday 27 November 2014 16:14:48 Greg Kroah-Hartman wrote:
> On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > Which userspace helper programs for (automatic) firmware
> > loading are used? Can be udev configured to use own program
> > for loading firmware instead that udev integrated which
> > looking for firmware only in /lib/firmware files?
>
> The code to load firmware from userspace has been removed from
> udev, so that's not going to work at all, sorry.
>
> greg k-h
Ok and how to load (dynamic) firmware files into kernel? What is
preferred way if not udev (because it removed that support)?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 15:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141127151655.GB23064@kroah.com>
[-- Attachment #1: Type: Text/Plain, Size: 2389 bytes --]
On Thursday 27 November 2014 16:16:55 Greg Kroah-Hartman wrote:
> On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> >
> > <pali.rohar@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > wifi driver wl1251 needs NVS calibration data for
> > > > working. These data are loaded by driver via
> > > > request_firmware from userspace file:
> > > > ti-connectivity/wl1251-nvs.bin. In linux-fimrware git
> > > > tree there is generic wl1251-nvs.bin file which is used
> > > > by default.
> > > >
> > > > Driver wl1251 is used on Nokia N900 cellphone for its
> > > > wifi chip. This cellphone has one special MTD partition
> > > > (called CAL) where are stored some configuration data
> > > > in special binary (key-value) format. And there is also
> > > > stored correct calibration data for specific device
> > > > (each device has different data). It is preferred to
> > > > use those data instead generic one (provided by
> > > > linux-firmware git tree).
> > > >
> > > > Now my question is: How to correctly load calibration
> > > > data from special Nokia N900 CAL partition into wl1251
> > > > kernel driver?
> > >
> > > It is better to let user space script handle the request.
> >
> > Yes, this makes sense. Implementing CAL parser in kernel
> > wl1251 driver would be hard...
> >
> > > > By default kernel reads ti-connectivity/wl1251-nvs.bin
> > > > file from VFS if exists without any userspace support.
> > > > If it fails then it fallback to loading via udev.
> > >
> > > You can remove or rename this file so that loading from
> > > user space can be triggered.
> >
> > It is no so easy... In case when CAL does not contains NVS
> > data then we want to use this generic NVS file. And telling
> > everybody to rename this is file is not good solution...
>
> But that's up to your system configuration, not the kernel.
> Make a userspace package for the firmware that creates it in
> the format you need it to be in, for the hardware you have,
> and then there would not be any need for a kernel change,
> right?
>
> greg k-h
Not so simple as you think. Some parts of NVS data are configured
based on location and cellular station. Data are not static.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-11-27 15:16 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201411271543.23527@pali>
On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
> > > Hello,
> > >
> > > wifi driver wl1251 needs NVS calibration data for working.
> > > These data are loaded by driver via request_firmware from
> > > userspace file: ti-connectivity/wl1251-nvs.bin. In
> > > linux-fimrware git tree there is generic wl1251-nvs.bin
> > > file which is used by default.
> > >
> > > Driver wl1251 is used on Nokia N900 cellphone for its wifi
> > > chip. This cellphone has one special MTD partition (called
> > > CAL) where are stored some configuration data in special
> > > binary (key-value) format. And there is also stored correct
> > > calibration data for specific device (each device has
> > > different data). It is preferred to use those data instead
> > > generic one (provided by linux-firmware git tree).
> > >
> > > Now my question is: How to correctly load calibration data
> > > from special Nokia N900 CAL partition into wl1251 kernel
> > > driver?
> >
> > It is better to let user space script handle the request.
> >
>
> Yes, this makes sense. Implementing CAL parser in kernel wl1251
> driver would be hard...
>
> > > By default kernel reads ti-connectivity/wl1251-nvs.bin file
> > > from VFS if exists without any userspace support. If it
> > > fails then it fallback to loading via udev.
> >
> > You can remove or rename this file so that loading from user
> > space can be triggered.
> >
>
> It is no so easy... In case when CAL does not contains NVS data
> then we want to use this generic NVS file. And telling everybody
> to rename this is file is not good solution...
But that's up to your system configuration, not the kernel. Make a
userspace package for the firmware that creates it in the format you
need it to be in, for the hardware you have, and then there would not be
any need for a kernel change, right?
greg k-h
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-11-27 15:14 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201411271543.23527@pali>
On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> Which userspace helper programs for (automatic) firmware loading
> are used? Can be udev configured to use own program for loading
> firmware instead that udev integrated which looking for firmware
> only in /lib/firmware files?
The code to load firmware from userspace has been removed from udev, so
that's not going to work at all, sorry.
greg k-h
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-11-27 15:13 UTC (permalink / raw)
To: Pali Rohár
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <201411271543.23527@pali>
On Thu, Nov 27, 2014 at 10:43 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
>> On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > Hello,
>> >
>> > wifi driver wl1251 needs NVS calibration data for working.
>> > These data are loaded by driver via request_firmware from
>> > userspace file: ti-connectivity/wl1251-nvs.bin. In
>> > linux-fimrware git tree there is generic wl1251-nvs.bin
>> > file which is used by default.
>> >
>> > Driver wl1251 is used on Nokia N900 cellphone for its wifi
>> > chip. This cellphone has one special MTD partition (called
>> > CAL) where are stored some configuration data in special
>> > binary (key-value) format. And there is also stored correct
>> > calibration data for specific device (each device has
>> > different data). It is preferred to use those data instead
>> > generic one (provided by linux-firmware git tree).
>> >
>> > Now my question is: How to correctly load calibration data
>> > from special Nokia N900 CAL partition into wl1251 kernel
>> > driver?
>>
>> It is better to let user space script handle the request.
>>
>
> Yes, this makes sense. Implementing CAL parser in kernel wl1251
> driver would be hard...
>
>> > By default kernel reads ti-connectivity/wl1251-nvs.bin file
>> > from VFS if exists without any userspace support. If it
>> > fails then it fallback to loading via udev.
>>
>> You can remove or rename this file so that loading from user
>> space can be triggered.
>>
>
> It is no so easy... In case when CAL does not contains NVS data
> then we want to use this generic NVS file. And telling everybody
> to rename this is file is not good solution...
>
>> > Reading correct data from CAL partition is not easy
>> > (structure is difficult), but there is open source program
>> > which can parse CAL partition and write NVS data to stdout.
>> > So adding this CAL parser into kernel is not good idea
>> > (program is GPLv3+ code -- incompatible with kernel).
>> >
>> > So how to solve this problem? How to load correct NVS data
>> > from CAL partition into wl1251 driver?
>> >
>> > It is possible to tell kernel to use some helper userspace
>> > program for loading data and if it fails then fallback to
>> > direct loading? E.g first try to use model specific data
>> > and if it fails for some reasons then fallback to reading
>> > genetic data.
>>
>> One solution is to introduce request_firmware_user() and let
>> this API handle your case, but CONFIG_FW_LOADER_USER_HELPER
>> has to be enabled.
>>
>> If request_firmware_user() fails, request_firmware_direct()
>> can be tried further.
>>
>> Thanks,
>> Ming Lei
>
> Ok, new kernel function which will change order of loading
> firmware should work.
I mean you can do that in your driver.
>
> Which userspace helper programs for (automatic) firmware loading
> are used? Can be udev configured to use own program for loading
At default, udev had its builtin firmware helper, but some new
udev stops to handle firmware request.
If the udev you are using still supports to handle firmware request,
you can write your load helper and add your rule for handling
the special case. Otherwise, you need to write code to monitor
the netlink uevents from the kernel and handle your firmware
loading request.
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH v3] can: Convert to runtime_pm
From: Michal Simek @ 2014-11-27 14:46 UTC (permalink / raw)
To: Kedareswara rao Appana, wg, mkl, michal.simek, soren.brinkmann,
grant.likely, robh+dt
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel, devicetree,
Kedareswara rao Appana
In-Reply-To: <1417093733-29576-1-git-send-email-appanad@xilinx.com>
On 11/27/2014 02:08 PM, Kedareswara rao Appana wrote:
> Instead of enabling/disabling clocks at several locations in the driver,
> use the runtime_pm framework. This consolidates the actions for
> runtime PM in the appropriate callbacks and makes the driver more
> readable and mantainable.
>
> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v3:
> - Converted the driver to use runtime_pm.
> Changes for v2:
> - Removed the struct platform_device* from suspend/resume
> as suggest by Lothar.
>
> drivers/net/can/xilinx_can.c | 119 +++++++++++++++++++++++++----------------
> 1 files changed, 72 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 8a998e3..1be28ed 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -32,6 +32,7 @@
> #include <linux/can/dev.h>
> #include <linux/can/error.h>
> #include <linux/can/led.h>
> +#include <linux/pm_runtime.h>
>
> #define DRIVER_NAME "xilinx_can"
>
> @@ -138,7 +139,7 @@ struct xcan_priv {
> u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
> void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
> u32 val);
> - struct net_device *dev;
> + struct device *dev;
> void __iomem *reg_base;
> unsigned long irq_flags;
> struct clk *bus_clk;
> @@ -842,6 +843,13 @@ static int xcan_open(struct net_device *ndev)
> struct xcan_priv *priv = netdev_priv(ndev);
> int ret;
>
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime CAN resume failed(%d)\n\r",
> + __func__, ret);
> + return ret;
> + }
> +
> ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
> ndev->name, ndev);
> if (ret < 0) {
> @@ -849,29 +857,17 @@ static int xcan_open(struct net_device *ndev)
> goto err;
> }
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable device clock\n");
> - goto err_irq;
> - }
> -
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable bus clock\n");
> - goto err_can_clk;
> - }
> -
> /* Set chip into reset mode */
> ret = set_reset_mode(ndev);
> if (ret < 0) {
> netdev_err(ndev, "mode resetting failed!\n");
> - goto err_bus_clk;
> + goto err_irq;
> }
>
> /* Common open */
> ret = open_candev(ndev);
> if (ret)
> - goto err_bus_clk;
> + goto err_irq;
>
> ret = xcan_chip_start(ndev);
> if (ret < 0) {
> @@ -887,13 +883,11 @@ static int xcan_open(struct net_device *ndev)
>
> err_candev:
> close_candev(ndev);
> -err_bus_clk:
> - clk_disable_unprepare(priv->bus_clk);
> -err_can_clk:
> - clk_disable_unprepare(priv->can_clk);
> err_irq:
> free_irq(ndev->irq, ndev);
> err:
> + pm_runtime_put(priv->dev);
> +
> return ret;
> }
>
> @@ -910,12 +904,11 @@ static int xcan_close(struct net_device *ndev)
> netif_stop_queue(ndev);
> napi_disable(&priv->napi);
> xcan_chip_stop(ndev);
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
> free_irq(ndev->irq, ndev);
> close_candev(ndev);
>
> can_led_event(ndev, CAN_LED_EVENT_STOP);
> + pm_runtime_put(priv->dev);
>
> return 0;
> }
> @@ -934,27 +927,21 @@ static int xcan_get_berr_counter(const struct net_device *ndev,
> struct xcan_priv *priv = netdev_priv(ndev);
> int ret;
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret)
> - goto err;
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime resume failed(%d)\n\r",
> + __func__, ret);
> + return ret;
> + }
>
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret)
> - goto err_clk;
>
> bec->txerr = priv->read_reg(priv, XCAN_ECR_OFFSET) & XCAN_ECR_TEC_MASK;
> bec->rxerr = ((priv->read_reg(priv, XCAN_ECR_OFFSET) &
> XCAN_ECR_REC_MASK) >> XCAN_ESR_REC_SHIFT);
>
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
> + pm_runtime_put(priv->dev);
>
> return 0;
> -
> -err_clk:
> - clk_disable_unprepare(priv->can_clk);
> -err:
> - return ret;
> }
>
>
> @@ -967,15 +954,45 @@ static const struct net_device_ops xcan_netdev_ops = {
>
> /**
> * xcan_suspend - Suspend method for the driver
> - * @dev: Address of the platform_device structure
> + * @dev: Address of the net_device structure
This is just the device structure.
> *
> * Put the driver into low power mode.
> - * Return: 0 always
> + * Return: 0 on success and failure value on error
> */
> static int __maybe_unused xcan_suspend(struct device *dev)
> {
> - struct platform_device *pdev = dev_get_drvdata(dev);
> - struct net_device *ndev = platform_get_drvdata(pdev);
> + if (!device_may_wakeup(dev))
> + return pm_runtime_force_suspend(dev);
> +
> + return 0;
> +}
> +
> +/**
> + * xcan_resume - Resume from suspend
> + * @dev: Address of the net_device structure
ditto
> + *
> + * Resume operation after suspend.
> + * Return: 0 on success and failure value on error
> + */
> +static int __maybe_unused xcan_resume(struct device *dev)
> +{
> + if (!device_may_wakeup(dev))
> + return pm_runtime_force_resume(dev);
> +
> + return 0;
> +
> +}
> +
> +/**
> + * xcan_runtime_suspend - Runtime suspend method for the driver
> + * @dev: Address of the net_device structure
ditto.
> + *
> + * Put the driver into low power mode.
> + * Return: 0 always
> + */
> +static int __maybe_unused xcan_runtime_suspend(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> struct xcan_priv *priv = netdev_priv(ndev);
>
> if (netif_running(ndev)) {
> @@ -993,16 +1010,15 @@ static int __maybe_unused xcan_suspend(struct device *dev)
> }
>
> /**
> - * xcan_resume - Resume from suspend
> - * @dev: Address of the platformdevice structure
> + * xcan_runtime_resume - Runtime resume from suspend
> + * @dev: Address of the net_device structure
ditto.
Thanks,
Michal
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 14:43 UTC (permalink / raw)
To: Ming Lei
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <CACVXFVMr8jH1ZzyPNG91VDK8DuVjQsHn9ks62sSNjOfUnNsURQ@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 2970 bytes --]
On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
<pali.rohar@gmail.com> wrote:
> > Hello,
> >
> > wifi driver wl1251 needs NVS calibration data for working.
> > These data are loaded by driver via request_firmware from
> > userspace file: ti-connectivity/wl1251-nvs.bin. In
> > linux-fimrware git tree there is generic wl1251-nvs.bin
> > file which is used by default.
> >
> > Driver wl1251 is used on Nokia N900 cellphone for its wifi
> > chip. This cellphone has one special MTD partition (called
> > CAL) where are stored some configuration data in special
> > binary (key-value) format. And there is also stored correct
> > calibration data for specific device (each device has
> > different data). It is preferred to use those data instead
> > generic one (provided by linux-firmware git tree).
> >
> > Now my question is: How to correctly load calibration data
> > from special Nokia N900 CAL partition into wl1251 kernel
> > driver?
>
> It is better to let user space script handle the request.
>
Yes, this makes sense. Implementing CAL parser in kernel wl1251
driver would be hard...
> > By default kernel reads ti-connectivity/wl1251-nvs.bin file
> > from VFS if exists without any userspace support. If it
> > fails then it fallback to loading via udev.
>
> You can remove or rename this file so that loading from user
> space can be triggered.
>
It is no so easy... In case when CAL does not contains NVS data
then we want to use this generic NVS file. And telling everybody
to rename this is file is not good solution...
> > Reading correct data from CAL partition is not easy
> > (structure is difficult), but there is open source program
> > which can parse CAL partition and write NVS data to stdout.
> > So adding this CAL parser into kernel is not good idea
> > (program is GPLv3+ code -- incompatible with kernel).
> >
> > So how to solve this problem? How to load correct NVS data
> > from CAL partition into wl1251 driver?
> >
> > It is possible to tell kernel to use some helper userspace
> > program for loading data and if it fails then fallback to
> > direct loading? E.g first try to use model specific data
> > and if it fails for some reasons then fallback to reading
> > genetic data.
>
> One solution is to introduce request_firmware_user() and let
> this API handle your case, but CONFIG_FW_LOADER_USER_HELPER
> has to be enabled.
>
> If request_firmware_user() fails, request_firmware_direct()
> can be tried further.
>
> Thanks,
> Ming Lei
Ok, new kernel function which will change order of loading
firmware should work.
Which userspace helper programs for (automatic) firmware loading
are used? Can be udev configured to use own program for loading
firmware instead that udev integrated which looking for firmware
only in /lib/firmware files?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox