* Re: Does arping update arp table?
From: David Ahern @ 2015-01-27 20:46 UTC (permalink / raw)
To: Murali Karicheri, netdev; +Cc: David Miller
In-Reply-To: <54C7E5B5.8060401@ti.com>
On 1/27/15 12:23 PM, Murali Karicheri wrote:
> However this command doesn't update the arp table on my Keystone EVM
> based on v3.19.x and also newer ubuntu machine based on v3.11. Is this
> expected behavior? I believe the arp response resulting from a arping
> command is controlled through per interface accept sys control like as
> in gratuitous arp. Please repond.
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_accept
^ permalink raw reply
* Re: [PATCH 4/7] net: wireless: wcn36xx: introduce WCN36XX_HAL_AVOID_FREQ_RANGE_IND
From: Andy Green @ 2015-01-27 20:57 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: Kalle Valo, wcn36xx, linux-wireless, netdev
In-Reply-To: <CAFSJ42ZydByi_u0auSGDx2A6_ObZGfjV7+kR_CzFYLORRHQ5wg@mail.gmail.com>
On 28 January 2015 at 04:01, Eugene Krasnikov <k.eugene.e@gmail.com> wrote:
> Do you know when is this message used? sounds important.
It's related to BT coexistance or radar... prima expects this payload with it
#define WLAN_HAL_MAX_AVOID_FREQ_RANGE 4
typedef PACKED_PRE struct PACKED_POST
{
tANI_U32 startFreq;
tANI_U32 endFreq;
} tHalFreqRange, *tpHalFreqRange;
typedef PACKED_PRE struct PACKED_POST
{
tANI_U32 avoidCnt;
tHalFreqRange avoidRange[WLAN_HAL_MAX_AVOID_FREQ_RANGE];
Basically wcn firmware can propose up to 4 frequency ranges to not use
for whatever reason... prima looks like it tries to disable channels
accordingly.
-Andy
> 2015-01-18 5:11 GMT+00:00 Andy Green <andy.green@linaro.org>:
>> WCN3620 firmware introduces a new async indication, we need to
>> add it as a known message type so we can accept it
>>
>> Signed-off-by: Andy Green <andy.green@linaro.org>
>> ---
>> drivers/net/wireless/ath/wcn36xx/hal.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h b/drivers/net/wireless/ath/wcn36xx/hal.h
>> index a1f1127..b947de0 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/hal.h
>> +++ b/drivers/net/wireless/ath/wcn36xx/hal.h
>> @@ -345,6 +345,8 @@ enum wcn36xx_hal_host_msg_type {
>> WCN36XX_HAL_DHCP_START_IND = 189,
>> WCN36XX_HAL_DHCP_STOP_IND = 190,
>>
>> + WCN36XX_HAL_AVOID_FREQ_RANGE_IND = 233,
>> +
>> WCN36XX_HAL_MSG_MAX = WCN36XX_HAL_MSG_TYPE_MAX_ENUM_SIZE
>> };
>>
>>
>
>
>
> --
> Best regards,
> Eugene
^ permalink raw reply
* Re: Does arping update arp table?
From: Murali Karicheri @ 2015-01-27 21:12 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, David Miller
In-Reply-To: <54C7F930.6090506@gmail.com>
On 01/27/2015 03:46 PM, David Ahern wrote:
> On 1/27/15 12:23 PM, Murali Karicheri wrote:
>> However this command doesn't update the arp table on my Keystone EVM
>> based on v3.19.x and also newer ubuntu machine based on v3.11. Is this
>> expected behavior? I believe the arp response resulting from a arping
>> command is controlled through per interface accept sys control like as
>> in gratuitous arp. Please repond.
>
> echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_accept
>
Thanks. That is what I thought.
--
Murali Karicheri
Linux Kernel, Texas Instruments
^ permalink raw reply
* Altera TSE (altera_tse) - tx_fifo_depth init bug
From: Vlastimil Setka @ 2015-01-27 21:26 UTC (permalink / raw)
To: vbridger, netdev, rfi
Hello,
I have discovered a bug in Altera TSE (altera_tse) ethernet driver.
In altera_tse_main.c, function altera_tse_probe:
if (of_property_read_u32(pdev->dev.of_node, "tx-fifo-depth",
&priv->rx_fifo_depth)) {
the TX related "tx-fifo-depth" is read from device tree, but by mistake
written to RX related struct member rx_fifo_depth instead of correct
tx_fifo_depth.
https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/altera/altera_tse_main.c#L1401
I am not sure about impact of this bug, but it seems that
priv->tx_fifo_depth is left uninitialised which is definitely not OK.
[PATCH 1/1] Altera TSE: Fix priv->tx_fifo_depth initialization
This patch fixes priv->tx_fifo_depth initialization in altera_tse_probe().
The "tx-fifo-depth" attribute was read again into rx_fifo_depth instead
of correct tx_fifo_depth probably because of copy-and-paste typo,
and tx_fifo_depth was left uninitialised.
Signed-off-by: Vlastimil Setka <setka@vsis.cz>
---
drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/altera/altera_tse_main.c
b/drivers/net/ethernet/altera/altera_tse_main.c
index 760c72c..f3d784a 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -1399,7 +1399,7 @@ static int altera_tse_probe(struct platform_device
*pdev)
}
if (of_property_read_u32(pdev->dev.of_node, "tx-fifo-depth",
- &priv->rx_fifo_depth)) {
+ &priv->tx_fifo_depth)) {
dev_err(&pdev->dev, "cannot obtain tx-fifo-depth\n");
ret = -ENXIO;
goto err_free_netdev;
--
1.8.1.2
Regards,
Vlastimil Setka
^ permalink raw reply related
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: David Miller @ 2015-01-27 22:10 UTC (permalink / raw)
To: herbert
Cc: tgraf, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127203924.GB9061@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 28 Jan 2015 07:39:24 +1100
> On Tue, Jan 27, 2015 at 11:40:28AM +0000, Thomas Graf wrote:
>>
>> This is unrelated to resize run control though, the reason is that
>> I'm converting tcp_hashinfo et al and they require a hybrid approach.
>> The tables may be too big to construct a parallel data structure, we
>> don't want to hold off inserts or deletes while the expensive dump
>> is underway. Even though we can't build a shadow structure while
>> locking everybody else out, we still want to provide a way to somehow
>> achieve consistent information. I think that NLM_F_INTR with fallback
>> to restarting the dump is a good option and very easy to implement. In
>> that case, we want to lock out resize from dumping iterations but
>> still allow parallel insert/delete.
>
> Well I guess Dave needs to make the call. Do we want to allow
> lockless walks over the hash table or not?
>
> Personally I don't think a linked list is that big a deal. But then
> you guys were agonsing over a single pointer so who knows.
For netlink a linked list is no big deal, but for something like TCP
sockets it really is.
^ permalink raw reply
* Re: [PATCH net-next v8 0/4] net: Add Keystone NetCP ethernet driver support
From: Arnd Bergmann @ 2015-01-27 22:28 UTC (permalink / raw)
To: Murali Karicheri; +Cc: David Miller, devicetree, linux-kernel, netdev
In-Reply-To: <54BE7A00.2020205@ti.com>
On Tuesday 20 January 2015 10:53:36 Murali Karicheri wrote:
> On 01/19/2015 03:11 PM, David Miller wrote:
> > From: Murali Karicheri<m-karicheri2@ti.com>
> > Date: Thu, 15 Jan 2015 19:10:03 -0500
> >
> >> The Network Coprocessor (NetCP) is a hardware accelerator that processes
> >> Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
> >> switch sub-module to send and receive packets. NetCP also includes a packet
> >> accelerator (PA) module to perform packet classification operations such as
> >> header matching, and packet modification operations such as checksum
> >> generation. NetCP can also optionally include a Security Accelerator(SA)
> >> capable of performing IPSec operations on ingress/egress packets.
> >>
> >> Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
> >> includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
> >> 1Gb/s rates per Ethernet port.
> >>
> >> Both GBE and XGBE network processors supported using common driver. It
> >> is also designed to handle future variants of NetCP.
> >
> > Series applied to net-next, thanks.
> David,
>
> Thanks a lot for applying this series. This helps us move forward to
> work on the next set of patches.
Hi Murali,
Building an ARM 'allmodconfig' kernel now runs into two separate problems
from your driver:
- you have two module_init() instances in one module, which conflict.
- you have two files that are linked into more than one module, so building
both TI_CPSW and TI_KEYSTONE_NETCP in the same kernel fails.
The answer to both of these is probably to have separate loadable modules,
but you might be able to come up with a different solution.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Herbert Xu @ 2015-01-27 23:16 UTC (permalink / raw)
To: David Miller
Cc: tgraf, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127.141018.1208673547021029175.davem@davemloft.net>
On Tue, Jan 27, 2015 at 02:10:18PM -0800, David Miller wrote:
>
> For netlink a linked list is no big deal, but for something like TCP
> sockets it really is.
OK then I'll resubmit my iterators.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 0/2] rhashtable: Add walk iterator primitives and use them in netlink
From: Herbert Xu @ 2015-01-27 23:19 UTC (permalink / raw)
To: Thomas Graf; +Cc: Ying Xue, davem, kaber, paulmck, netdev, netfilter-devel
In-Reply-To: <20150125232040.GA17936@gondor.apana.org.au>
On Mon, Jan 26, 2015 at 10:20:40AM +1100, Herbert Xu wrote:
>
> Here are the first two patches, one to add the primitives and one
> to demonstrate its use in netlink. In fact while testing this I
> found that the existing netlink walking code is totally broken.
So this is a repost of the same thing. These lockless iterators
won't be usable by netfilter as it stands because it wants to do
nested walks and also isn't currently lockless.
However, I'll wait for Patrick to post his pending patches to see
what exactly he needs before implementing helpers for that case.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Herbert Xu @ 2015-01-27 23:20 UTC (permalink / raw)
To: Thomas Graf, Ying Xue, davem, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127231950.GA11374@gondor.apana.org.au>
Some existing rhashtable users get too intimate with it by walking
the buckets directly. This prevents us from easily changing the
internals of rhashtable.
This patch adds the helpers rhashtable_walk_init/next/end which
will replace these custom walkers.
They are meant to be usable for both procfs seq_file walks as well
as walking by a netlink dump. The iterator structure should fit
inside a netlink dump cb structure, with at least one element to
spare.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
include/linux/rhashtable.h | 44 +++++++++++++++++++++
lib/rhashtable.c | 91 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 135 insertions(+)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index 6d7e840..b03b375 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -18,6 +18,7 @@
#ifndef _LINUX_RHASHTABLE_H
#define _LINUX_RHASHTABLE_H
+#include <linux/compiler.h>
#include <linux/list_nulls.h>
#include <linux/workqueue.h>
#include <linux/mutex.h>
@@ -123,6 +124,22 @@ struct rhashtable {
bool being_destroyed;
};
+/**
+ * struct rhashtable_iter - Hash table iterator
+ * @ht: Table to iterate through
+ * @p: Current pointer
+ * @lock: Slot lock
+ * @slot: Current slot
+ * @skip: Number of entries to skip in slot
+ */
+struct rhashtable_iter {
+ struct rhashtable *ht;
+ struct rhash_head *p;
+ spinlock_t *lock;
+ unsigned int slot;
+ unsigned int skip;
+};
+
static inline unsigned long rht_marker(const struct rhashtable *ht, u32 hash)
{
return NULLS_MARKER(ht->p.nulls_base + hash);
@@ -178,6 +195,33 @@ bool rhashtable_lookup_compare_insert(struct rhashtable *ht,
bool (*compare)(void *, void *),
void *arg);
+/**
+ * rhashtable_walk_init - Initialise an iterator
+ * @ht: Table to walk over
+ * @iter: Hash table Iterator
+ *
+ * This function prepares a hash table walk.
+ * Note that if you restart a walk after rhashtable_walk_stop you
+ * may see the same object twice. Also, you may miss objects if
+ * there are removals in between rhashtable_walk_stop and the next
+ * call to rhashtable_walk_start.
+ *
+ * For a completely stable walk you should construct your own data
+ * structure outside the hash table.
+ */
+static inline void rhashtable_walk_init(struct rhashtable *ht,
+ struct rhashtable_iter *iter)
+{
+ iter->ht = ht;
+ iter->p = NULL;
+ iter->slot = 0;
+ iter->skip = 0;
+}
+
+int rhashtable_walk_start(struct rhashtable_iter *iter) __acquires(RCU);
+void *rhashtable_walk_next(struct rhashtable_iter *iter);
+void rhashtable_walk_stop(struct rhashtable_iter *iter) __releases(RCU);
+
void rhashtable_destroy(struct rhashtable *ht);
#define rht_dereference(p, ht) \
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 71c6aa1..d51fb06 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -813,6 +813,97 @@ exit:
}
EXPORT_SYMBOL_GPL(rhashtable_lookup_compare_insert);
+/**
+ * rhashtable_walk_start - Start a hash table walk
+ * @iter: Hash table iterator
+ *
+ * Start a hash table walk.
+ *
+ * Returns zero if successful. Returns -EINTR if we couldn't
+ * obtain the resize lock.
+ */
+int rhashtable_walk_start(struct rhashtable_iter *iter)
+{
+ struct rhashtable *ht = iter->ht;
+ int err;
+
+ err = mutex_lock_interruptible(&ht->mutex);
+ rcu_read_lock();
+
+ if (!err)
+ mutex_unlock(&ht->mutex);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(rhashtable_walk_start);
+
+/**
+ * rhashtable_walk_next - Return the next object and advance the iterator
+ * @iter: Hash table iterator
+ *
+ * Note that you must call rhashtable_walk_stop when you are finished
+ * with the walk.
+ *
+ * Returns the next object or NULL when the end of the table is reached.
+ */
+void *rhashtable_walk_next(struct rhashtable_iter *iter)
+{
+ const struct bucket_table *tbl;
+ struct rhashtable *ht = iter->ht;
+ struct rhash_head *p = iter->p;
+
+ tbl = rht_dereference_rcu(ht->tbl, ht);
+
+ if (p) {
+ p = rht_dereference_bucket(p->next, tbl, iter->slot);
+ goto next;
+ }
+
+ for (; iter->slot < tbl->size; iter->slot++) {
+ int skip = iter->skip;
+
+ iter->lock = bucket_lock(tbl, iter->slot);
+ spin_lock_bh(iter->lock);
+
+ rht_for_each(p, tbl, iter->slot) {
+ if (!skip)
+ break;
+ skip--;
+ }
+
+next:
+ if (!rht_is_a_nulls(p)) {
+ iter->skip++;
+ iter->p = p;
+ return rht_obj(ht, p);
+ }
+ spin_unlock_bh(iter->lock);
+
+ iter->skip = 0;
+ }
+
+ iter->p = NULL;
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(rhashtable_walk_next);
+
+/**
+ * rhashtable_walk_stop - Finish a hash table walk
+ * @iter: Hash table iterator
+ *
+ * Finish a hash table walk.
+ */
+void rhashtable_walk_stop(struct rhashtable_iter *iter)
+{
+ if (iter->p)
+ spin_unlock_bh(iter->lock);
+
+ rcu_read_unlock();
+
+ iter->p = NULL;
+}
+EXPORT_SYMBOL_GPL(rhashtable_walk_stop);
+
static size_t rounded_hashtable_size(struct rhashtable_params *params)
{
return max(roundup_pow_of_two(params->nelem_hint * 4 / 3),
^ permalink raw reply related
* [PATCH 2/2] netlink: Use rhashtable walk iterator
From: Herbert Xu @ 2015-01-27 23:20 UTC (permalink / raw)
To: Thomas Graf, Ying Xue, davem, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127231950.GA11374@gondor.apana.org.au>
This patch gets rid of the manual rhashtable walk in netlink
which touches rhashtable internals that should not be exposed.
It does so by using the rhashtable iterator primitives.
In fact the existing code was very buggy. Some sockets weren't
shown at all while others were shown more than once.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
net/netlink/af_netlink.c | 113 +++++++++++++++++------------------------------
1 file changed, 41 insertions(+), 72 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index d77b346..6f8549e 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2884,99 +2884,68 @@ EXPORT_SYMBOL(nlmsg_notify);
#ifdef CONFIG_PROC_FS
struct nl_seq_iter {
struct seq_net_private p;
+ struct rhashtable_iter hti;
int link;
- int hash_idx;
};
-static struct sock *netlink_seq_socket_idx(struct seq_file *seq, loff_t pos)
+static int netlink_walk_start(struct nl_seq_iter *iter)
{
- struct nl_seq_iter *iter = seq->private;
- int i, j;
- struct netlink_sock *nlk;
- struct sock *s;
- loff_t off = 0;
-
- for (i = 0; i < MAX_LINKS; i++) {
- struct rhashtable *ht = &nl_table[i].hash;
- const struct bucket_table *tbl = rht_dereference_rcu(ht->tbl, ht);
-
- for (j = 0; j < tbl->size; j++) {
- struct rhash_head *node;
-
- rht_for_each_entry_rcu(nlk, node, tbl, j, node) {
- s = (struct sock *)nlk;
-
- if (sock_net(s) != seq_file_net(seq))
- continue;
- if (off == pos) {
- iter->link = i;
- iter->hash_idx = j;
- return s;
- }
- ++off;
- }
- }
- }
- return NULL;
-}
-
-static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(RCU)
-{
- rcu_read_lock();
- return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
+ rhashtable_walk_init(&nl_table[iter->link].hash, &iter->hti);
+ return rhashtable_walk_start(&iter->hti);
}
-static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
+static void *__netlink_seq_next(struct seq_file *seq)
{
- struct rhashtable *ht;
- const struct bucket_table *tbl;
- struct rhash_head *node;
+ struct nl_seq_iter *iter = seq->private;
struct netlink_sock *nlk;
- struct nl_seq_iter *iter;
- struct net *net;
- int i, j;
- ++*pos;
+ do {
+ while (!(nlk = rhashtable_walk_next(&iter->hti))) {
+ int err;
- if (v == SEQ_START_TOKEN)
- return netlink_seq_socket_idx(seq, 0);
+ rhashtable_walk_stop(&iter->hti);
+ if (++iter->link >= MAX_LINKS)
+ return NULL;
- net = seq_file_net(seq);
- iter = seq->private;
- nlk = v;
+ err = netlink_walk_start(iter);
+ if (err)
+ return ERR_PTR(err);
+ }
+ } while (sock_net(&nlk->sk) != seq_file_net(seq));
- i = iter->link;
- ht = &nl_table[i].hash;
- tbl = rht_dereference_rcu(ht->tbl, ht);
- rht_for_each_entry_rcu_continue(nlk, node, nlk->node.next, tbl, iter->hash_idx, node)
- if (net_eq(sock_net((struct sock *)nlk), net))
- return nlk;
+ return nlk;
+}
- j = iter->hash_idx + 1;
+static void *netlink_seq_start(struct seq_file *seq, loff_t *posp)
+{
+ struct nl_seq_iter *iter = seq->private;
+ void *obj = SEQ_START_TOKEN;
+ loff_t pos;
+ int err;
- do {
+ iter->link = 0;
+ err = netlink_walk_start(iter);
+ if (err)
+ return ERR_PTR(err);
- for (; j < tbl->size; j++) {
- rht_for_each_entry_rcu(nlk, node, tbl, j, node) {
- if (net_eq(sock_net((struct sock *)nlk), net)) {
- iter->link = i;
- iter->hash_idx = j;
- return nlk;
- }
- }
- }
+ for (pos = *posp; pos && obj; pos--)
+ obj = __netlink_seq_next(seq);
- j = 0;
- } while (++i < MAX_LINKS);
+ return obj;
+}
- return NULL;
+static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
+{
+ ++*pos;
+ return __netlink_seq_next(seq);
}
static void netlink_seq_stop(struct seq_file *seq, void *v)
- __releases(RCU)
{
- rcu_read_unlock();
+ struct nl_seq_iter *iter = seq->private;
+
+ if (iter->link < MAX_LINKS)
+ rhashtable_walk_stop(&iter->hti);
}
^ permalink raw reply related
* Re: [PATCH v2 2/2] NFC: Add ACPI support for NXP PN544
From: Samuel Ortiz @ 2015-01-27 23:28 UTC (permalink / raw)
To: Robert Dolca
Cc: linux-nfc, Lauro Ramos Venancio, Aloisio Almeida Jr, linux-kernel,
linux-wireless, netdev, David S. Miller, Berg Johannes,
Clement Perrochaud
In-Reply-To: <1422270817-10950-3-git-send-email-robert.dolca@intel.com>
Hi Robert,
On Mon, Jan 26, 2015 at 01:13:37PM +0200, Robert Dolca wrote:
> @@ -1022,9 +1127,12 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
> PN544_I2C_FRAME_HEADROOM, PN544_I2C_FRAME_TAILROOM,
> PN544_HCI_I2C_LLC_MAX_PAYLOAD,
> pn544_hci_i2c_fw_download, &phy->hdev);
> - if (r < 0)
> + if (r < 0) {
> + nfc_err(&client->dev, "HCI Probing error\n");
> goto err_hci;
> + }
>
> + nfc_info(&client->dev, "NFC I2C driver loaded\n");
> return 0;
This is unrelated to this patch, so I removed that part.
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH v2 0/2] Add ACPI support for NXP PN544
From: Samuel Ortiz @ 2015-01-27 23:29 UTC (permalink / raw)
To: Robert Dolca
Cc: linux-nfc, Lauro Ramos Venancio, Aloisio Almeida Jr, linux-kernel,
linux-wireless, netdev, David S. Miller, Berg Johannes,
Clement Perrochaud
In-Reply-To: <1422270817-10950-1-git-send-email-robert.dolca@intel.com>
Hi Robert,
On Mon, Jan 26, 2015 at 01:13:35PM +0200, Robert Dolca wrote:
> This patch set introduces ACPI support for PN544.
>
> gpio_set_value was replaced with gpio_set_value_cansleep in order
> to allow GPIO access that may sleep. This is particularelly useful
> when GPIO is accessed using busses like I2C, SPI, USB
>
> Changes since v1:
> - Added cover letter
> - Removed debug define and Kconfig include
> - Minor fixes to patch subjects
>
> Links to v1:
> - http://lkml.iu.edu/hypermail/linux/kernel/1501.1/00943.html
> - http://lkml.iu.edu/hypermail/linux/kernel/1501.1/00944.html
>
> Robert Dolca (2):
> NFC: PN544: GPIO access that may sleep
> NFC: Add ACPI support for NXP PN544
Both patches applied, many thanks.
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host
From: Bill Fink @ 2015-01-27 23:32 UTC (permalink / raw)
To: David Miller; +Cc: fengyuleidian0615, fan.du, steffen.klassert, herbert, netdev
In-Reply-To: <20150127.001226.711259930266409202.davem@davemloft.net>
On Tue, 27 Jan 2015, David Miller wrote:
> From: Fan Du <fengyuleidian0615@gmail.com>
> Date: Tue, 27 Jan 2015 15:44:36 +0800
>
> > 于 2015年01月27日 15:39, David Miller 写道:
> >> From: Fan Du <fan.du@intel.com>
> >> Date: Tue, 27 Jan 2015 10:54:22 +0800
> >>
> >>> @@ -2419,6 +2419,11 @@ static int xfrm_user_rcv_msg(struct sk_buff
> >>> *skb, struct nlmsghdr *nlh)
> >>> const struct xfrm_link *link;
> >>> int type, err;
> >>>
> >>> +#ifdef CONFIG_COMPAT
> >>> + if (is_compat_task())
> >>> + return -EPERM;
> >>> +#endif
> >>> +
> >>
> >> This seems more like an unsupported operation rather then a permission
> >> problem.
> >>
> > how about *ENOTSUPP* ?
>
> Unquestionably, that is an improvement over EPERM.
But it should be EOPNOTSUPP rather than ENOTSUP, right?
-Bill
^ permalink raw reply
* Re: [PATCH] lib/checksum.c: fix carry in csum_tcpudp_nofold
From: Alexei Starovoitov @ 2015-01-27 23:56 UTC (permalink / raw)
To: Karl Beldan
Cc: Al Viro, Karl Beldan, Mike Frysinger, Arnd Bergmann,
linux-kernel@vger.kernel.org, Stable, netdev@vger.kernel.org
On Tue, Jan 27, 2015 at 3:13 PM, Karl Beldan <karl.beldan@gmail.com> wrote:
> On Tue, Jan 27, 2015 at 10:03:32PM +0000, Al Viro wrote:
>> On Tue, Jan 27, 2015 at 04:25:16PM +0100, Karl Beldan wrote:
>> > The carry from the 64->32bits folding was dropped, e.g with:
>> > saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1
>> >
>> > Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
>> > Cc: Mike Frysinger <vapier@gentoo.org>
>> > Cc: Arnd Bergmann <arnd@arndb.de>
>> > Cc: linux-kernel@vger.kernel.org
>> > Cc: Stable <stable@vger.kernel.org>
>> > ---
>> > lib/checksum.c | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/lib/checksum.c b/lib/checksum.c
>> > index 129775e..4b5adf2 100644
>> > --- a/lib/checksum.c
>> > +++ b/lib/checksum.c
>> > @@ -195,8 +195,8 @@ __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
>> > #else
>> > s += (proto + len) << 8;
>> > #endif
>> > - s += (s >> 32);
>> > - return (__force __wsum)s;
>> > + s += (s << 32) + (s >> 32);
>> > + return (__force __wsum)(s >> 32);
>>
>> Umm... I _think_ it's correct, but it needs a better commit message. AFAICS,
>> what we have is that s is guaranteed to be (a << 32) + b, with a being small.
>> What we want is something congruent to a + b modulo 0xffff. And yes, in case
>> when a + b >= 2^32, the original variant fails - it yields a + b - 2^32, which
>> is one less than what's needed. New one results first in
>> (a + b)(2^32+1)mod 2^64, then that divided by 2^32. If a + b <= 2^32 - 1,
>> the first product is less than 2^64 and dividing it by 2^32 yields a + b.
>> If a + b = 2^32 + c, c is guaranteed to be small and we first get
>> 2^32 * c + 2^32 + 1, then c + 1, i.e. a + b - 0xffffffff, i.e.
>> a + b - 0x10001 * 0xffff, so the congruence holds in all cases.
>>
>> IOW, I think the fix is correct, but it really needs analysis in the commit
>> message.
>
> My take on this was "somewhat" simpler:
>
> s = a31..0b31..b0 = a << 32 + b, as you put it
>
> Here however I don't assume that a is "small", however I assume it has
> never overflowed, which is trivial to verify since we only add 3 32bits
> values and 2 16 bits values to a 64bits.
> Now we just want (a + b + carry(a + b)) % 2^32, and here I assume
> (a + b + carry(a + b)) % 2^32 == (a + b) % 2^32 + carry(a + b), I
> guess this is the trick, and this is easy to convince oneself with:
> 0xffffffff + 0xffffffff == 0x1fffffffe ==>
> ((u32)-1 + (u32)-1 + 1) % 2^32 == 0xfffffffe % 2^32 + 1
> We get this carry pushed out from the MSbs side by the s+= addition
> pushed back in to the LSbs side of the upper 32bits and this carry
> doesn't make the upper side overflow.
>
> If this explanation is acceptable, I can reword the commit message with
> it. Sorry if my initial commit log lacked details, and thanks for your
> detailed input.
please cc: netdev next time as well.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2015-01-28 1:02 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Jiri Pirko, Daniel Borkmann
[-- Attachment #1: Type: text/plain, Size: 975 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/sched/cls_bpf.c between commit 7913ecf69e24 ("net: cls_bpf: fix
size mismatch on filter preparation") from the net tree and commit
33e9fcc666e2 ("tc: cls_bpf: rename bpf_len to bpf_num_ops") from the
net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/sched/cls_bpf.c
index f59adf8a4cd7,1029923f9e86..000000000000
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@@ -179,12 -179,7 +179,12 @@@ static int cls_bpf_modify_existing(stru
goto errout;
}
- bpf_size = bpf_len * sizeof(*bpf_ops);
+ bpf_size = bpf_num_ops * sizeof(*bpf_ops);
+ if (bpf_size != nla_len(tb[TCA_BPF_OPS])) {
+ ret = -EINVAL;
+ goto errout;
+ }
+
bpf_ops = kzalloc(bpf_size, GFP_KERNEL);
if (bpf_ops == NULL) {
ret = -ENOMEM;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: various 802.3ad fixes
From: David Miller @ 2015-01-28 1:09 UTC (permalink / raw)
To: jtoppins; +Cc: j.vosburgh, vfalico, andy, netdev
In-Reply-To: <1422253021-3798-1-git-send-email-jtoppins@cumulusnetworks.com>
From: Jonathan Toppins <jtoppins@cumulusnetworks.com>
Date: Mon, 26 Jan 2015 01:16:56 -0500
> This patch series is a forward porting of patches we (Cumulus) are shipping
> in our 3.2 series kernels. These fixes attempt to make 802.3ad bonding mode
> more predictable in certian state machine transtions in addition to fixing
> 802.3ad bond carrier determination when bonding min_links option is changed.
> Specific notes are contained within each patch.
>
> For this patch series there are no userspace facing changes, a diff between
> the modinfo output showed no difference. However, there are behavioral
> facing changes, primarily in the bond carrier state. Please make sure to
> review carefully.
>
> v2:
> * fixed some style issues
> * dropped a portion of patch 1 in favor of more testing on my side
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] vxlan: advertise link netns in fdb messages
From: David Miller @ 2015-01-28 1:11 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1422277853-5722-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 26 Jan 2015 14:10:53 +0100
> Previous commit is based on a wrong assumption, fdb messages are always sent
> into the netns where the interface stands (see vxlan_fdb_notify()).
>
> These fdb messages doesn't embed the rtnl attribute IFLA_LINK_NETNSID, thus we
> need to add it (useful to interpret NDA_IFINDEX or NDA_DST for example).
>
> Note also that vxlan_nlmsg_size() was not updated.
>
> Fixes: 193523bf9373 ("vxlan: advertise netns of vxlan dev in fdb msg")
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next V1 00/11] Mellanox ethernet driver updates Jan-27-2015
From: David Miller @ 2015-01-28 1:13 UTC (permalink / raw)
To: amirv; +Cc: netdev, ogerlitz, yevgenyp
In-Reply-To: <1422367089-13419-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Tue, 27 Jan 2015 15:57:58 +0200
> This patchset introduces some bug fixes, code cleanups and support in a new
> firmware event called recoverable error events.
>
> Patches were applied and tested against commit b8665c6 ("net: dsa/mv88e6352:
> make mv88e6352_wait generic")
>
> Changes from V0:
> - Patch 6/11 ("net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding
> explicit"):
> - Removed __packed
> - Rephrased commit message
>
> - Added a new patch by Majd ("net/mlx4_core: Update the HCA core clock frequency
> after INIT_PORT")
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] csiostor:T5 Firmware fix and cleanup.
From: David Miller @ 2015-01-28 1:17 UTC (permalink / raw)
To: praveenm; +Cc: netdev, linux-scsi, JBottomley, hch, hariprasad, varun
In-Reply-To: <1422368197-22086-1-git-send-email-praveenm@chelsio.com>
From: Praveen Madhavan <praveenm@chelsio.com>
Date: Tue, 27 Jan 2015 19:46:37 +0530
> This patch fix is to use default firmware configuration files
> present in the adapter incase if not available in standard
> /lib/firmware/* dir. Additional cleanup is done to reuse flash
> related defines from cxgb4 header file.
>
> Please apply over net-next since it depends on previous commit.
>
> Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Move firmware version MACRO to t4fw_version.h
From: David Miller @ 2015-01-28 1:18 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, praveenm
In-Reply-To: <1422369772-2215-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 27 Jan 2015 20:12:52 +0530
> Move firmware version MACRO to a new t4fw_version.h file so that csiostor driver
> can also use it.
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v1] net: netcp: remove unused kconfig option and code
From: David Miller @ 2015-01-28 1:19 UTC (permalink / raw)
To: m-karicheri2; +Cc: netdev, linux-kernel
In-Reply-To: <1422370194-2828-1-git-send-email-m-karicheri2@ti.com>
From: Murali Karicheri <m-karicheri2@ti.com>
Date: Tue, 27 Jan 2015 09:49:54 -0500
> Currently CPTS is built into the netcp driver even though there is no
> call out to the CPTS driver. This patch removes the dependency in Kconfig
> and remove cpts.o from the Makefile for NetCP.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Applied, thank you.
^ permalink raw reply
* query: Can ethtool be used to print Expansion ROM version of the adapter?
From: Hariprasad S @ 2015-01-28 2:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: ben@decadent.org.uk, davem@davemloft.net, Nirranjan Kirubaharan,
Casey Leedom, Kumar A S
Hi,
For printing the Expansion ROM version of the adapter, we were thinking if ethtool
could be used for it ?
There are fields in ethtool_drvinfo to display fw_version and driver_version. Also,
there are two reserved fields present. Are these two reserved fields already in use ?
Could anyone of the reserved field be used to print the custom adapter info like
Expansion ROM version ?
Thanks,
Hariprasad Shenai
^ permalink raw reply
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: David Ahern @ 2015-01-28 3:21 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Andy Gospodarek, Stephen Hemminger, netdev
In-Reply-To: <1422372523.13969.23.camel@stressinduktion.org>
On 01/27/2015 08:28 AM, Hannes Frederic Sowa wrote:
>> From the discussion a second patch is needed to make sure DAD is done
>> on a link up if there is an address configured.
>
> Thank you!
>
> Let's see if the DAD patch isn't complex, maybe it is a candidate for
> stable?
Actually, DAD is done on a link up; you can see the notifications go out
when the link is brought up:
18:46:28.519907 IP6 :: > ff02::1:ff00:10: ICMP6, neighbor solicitation,
who has 2001:1::10, length 24
18:46:28.607650 IP6 :: > ff02::1:ff03:402: ICMP6, neighbor solicitation,
who has fe80::1:2ff:fe03:402, length 24
So current top of tree works fine wrt DAD on addresses added when a link
is down and then the link is brought up.
But, my previous patch does not re-send notifications on the up in a
down-up cycle. I believe it is because the IFA_F_TENTATIVE flag is not
set for the global address configured. I will address that in the
revised patch.
David
^ permalink raw reply
* Re: ipv6: oops in datagram.c line 260
From: Chris Ruehl @ 2015-01-28 3:50 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Hannes Frederic Sowa, netdev, davem
In-Reply-To: <20150127115814.GL13046@secunet.com>
On Tuesday, January 27, 2015 07:58 PM, Steffen Klassert wrote:
> On Tue, Jan 27, 2015 at 12:58:35PM +0800, Chris Ruehl wrote:
>>
>> Steffen,
>>
>> your patch can't apply to the vanilla v3.14.29 can you cross check please.
>
> Sorry, this patch was based on the net tree.
>
>> I'm sorry but we running a productive system and I can't make to much
>> noise here!
>> Your patch is partly in the 3.14.29 and
>> skb->protocol = htons(ETH_P_IP)
>> from the xfrm4/6_output_finish() no removed. I do then
>>
>> --- linux-3.14.x/net/ipv4/xfrm4_output.c.orig 2015-01-27
>> 12:50:01.830651344 +0800
>> +++ linux-3.14.x/net/ipv4/xfrm4_output.c 2015-01-27 12:51:13.280386355
>> +0800
>> @@ -82,7 +82,6 @@
>> IPCB(skb)->flags |= IPSKB_XFRM_TRANSFORMED;
>> #endif
>>
>> - skb->protocol = htons(ETH_P_IP);
>> return xfrm_output(skb);
>> }
>>
>> --- linux-3.14.x/net/ipv6/xfrm6_output.c.orig 2015-01-27
>> 12:49:39.260735321 +0800
>> +++ linux-3.14.x/net/ipv6/xfrm6_output.c 2015-01-27 12:50:47.280482636
>> +0800
>> @@ -132,7 +132,6 @@
>> IP6CB(skb)->flags |= IP6SKB_XFRM_TRANSFORMED;
>> #endif
>>
>> - skb->protocol = htons(ETH_P_IPV6);
>> return xfrm_output(skb);
>> }
>
> Yes, that should be ok. Here is the complete patch for v3.14.29:
>
> Subject: [PATCH RFC v3.14.29] xfrm: Fix local error reporting crash with interfamily tunnels
>
> We set the outer mode protocol too early. As a result, the
> local error handler might dispatch to the wrong address family
> and report the error to a wrong socket type. We fix this by
> seting the outer protocol to the skb only after we accessed the
> inner mode for the last time, right before we do the atcual
> encapsulation where we switch finally to the outer mode.
> The settings in xfrm{4,6}_output_finish() are removed.
>
> Reported-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
> net/ipv4/xfrm4_output.c | 1 -
> net/ipv6/xfrm6_output.c | 1 -
> 2 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
> index baa0f63..0cb9606 100644
> --- a/net/ipv4/xfrm4_output.c
> +++ b/net/ipv4/xfrm4_output.c
> @@ -82,7 +82,6 @@ int xfrm4_output_finish(struct sk_buff *skb)
> IPCB(skb)->flags |= IPSKB_XFRM_TRANSFORMED;
> #endif
>
> - skb->protocol = htons(ETH_P_IP);
> return xfrm_output(skb);
> }
>
> diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
> index 6cd625e..98396cf 100644
> --- a/net/ipv6/xfrm6_output.c
> +++ b/net/ipv6/xfrm6_output.c
> @@ -132,7 +132,6 @@ int xfrm6_output_finish(struct sk_buff *skb)
> IP6CB(skb)->flags |= IP6SKB_XFRM_TRANSFORMED;
> #endif
>
> - skb->protocol = htons(ETH_P_IPV6);
> return xfrm_output(skb);
> }
>
>
Applied, wait for a window for reboot the system. And wait :0)
Chris
^ permalink raw reply
* Re: query: Can ethtool be used to print Expansion ROM version of the adapter?
From: Ben Hutchings @ 2015-01-28 3:52 UTC (permalink / raw)
To: Hariprasad S
Cc: netdev@vger.kernel.org, davem@davemloft.net,
Nirranjan Kirubaharan, Casey Leedom, Kumar A S
In-Reply-To: <26E3F92EC670BD429DB5CB319D773C13C7FE19@nice.asicdesigners.com>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
On Wed, 2015-01-28 at 02:18 +0000, Hariprasad S wrote:
> Hi,
>
> For printing the Expansion ROM version of the adapter, we were thinking if ethtool
> could be used for it ?
> There are fields in ethtool_drvinfo to display fw_version and driver_version. Also,
> there are two reserved fields present. Are these two reserved fields already in use ?
> Could anyone of the reserved field be used to print the custom adapter info like
> Expansion ROM version ?
Yes, I think reserved1 could be used for this. But you should rename it
in the header and update the comment to indicate what it's now being
used for.
Ben.
--
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 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