* Fw: [Bug 195835] New: regression: tcp_fastretrans_alert
From: Stephen Hemminger @ 2017-05-22 4:14 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sun, 21 May 2017 08:53:17 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 195835] New: regression: tcp_fastretrans_alert
https://bugzilla.kernel.org/show_bug.cgi?id=195835
Bug ID: 195835
Summary: regression: tcp_fastretrans_alert
Product: Networking
Version: 2.5
Kernel Version: 4.11.2
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: nanericwang@gmail.com
Regression: No
The issue can be reproduced in 4.11 running netfilter and Transmission
BitTorrent. However 4.10.x has no such issue.
[May21 16:38] ------------[ cut here ]------------
[ +0.000044] WARNING: CPU: 3 PID: 0 at net/ipv4/tcp_input.c:2819
tcp_fastretrans_alert+0x7ff/0xa10
[ +0.000006] Modules linked in: xt_TPROXY iptable_mangle xt_owner xt_REDIRECT
nf_nat_redirect xt_set af_packet iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_set_hash_net i
[ +0.000100] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.11.2 #2
[ +0.000004] Hardware name: BIOSTAR Group A68N-5000/A68N-5000, BIOS 4.6.5
04/22/2014
[ +0.000002] Call Trace:
[ +0.000007] <IRQ>
[ +0.000010] ? dump_stack+0x46/0x5e
[ +0.000009] ? __warn+0xb4/0xd0
[ +0.000006] ? tcp_fastretrans_alert+0x7ff/0xa10
[ +0.000006] ? tcp_ack+0xe95/0x1448
[ +0.000009] ? __ip_flush_pending_frames.isra.51+0x70/0x70
[ +0.000007] ? tcp_rcv_established+0x1ae/0x6b0
[ +0.000007] ? tcp_v4_do_rcv+0x12b/0x1e8
[ +0.000006] ? tcp_v4_rcv+0x7c4/0x880
[ +0.000011] ? nf_nat_ipv4_fn+0x53/0x150 [nf_nat_ipv4]
[ +0.000007] ? ip_local_deliver_finish+0x49/0x110
[ +0.000006] ? ip_local_deliver+0x66/0xd8
[ +0.000006] ? inet_del_offload+0x30/0x30
[ +0.000008] ? ip_sabotage_in+0x26/0x30 [br_netfilter]
[ +0.000009] ? nf_hook_slow+0x21/0xa0
[ +0.000005] ? ip_rcv+0x2e8/0x370
[ +0.000006] ? ip_local_deliver_finish+0x110/0x110
[ +0.000008] ? __netif_receive_skb_core+0x363/0x700
[ +0.000007] ? netif_receive_skb_internal+0x2a/0x98
[ +0.000014] ? br_pass_frame_up+0x60/0xd8 [bridge]
[ +0.000012] ? br_handle_frame_finish+0x132/0x330 [bridge]
[ +0.000015] ? nf_ct_get_tuple+0x56/0x90 [nf_conntrack]
[ +0.000011] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000007] ? br_nf_hook_thresh+0xa7/0xb8 [br_netfilter]
[ +0.000009] ? ipt_do_table+0x2b5/0x3e0 [ip_tables]
[ +0.000007] ? br_nf_pre_routing_finish+0x173/0x2f8 [br_netfilter]
[ +0.000010] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000007] ? nf_nat_ipv4_in+0x23/0x70 [nf_nat_ipv4]
[ +0.000007] ? br_nf_pre_routing+0x2c4/0x420 [br_netfilter]
[ +0.000007] ? br_nf_forward_arp+0x250/0x250 [br_netfilter]
[ +0.000007] ? nf_hook_slow+0x21/0xa0
[ +0.000010] ? br_handle_frame+0x1ae/0x2c8 [bridge]
[ +0.000010] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000010] ? br_handle_local_finish+0x38/0x38 [bridge]
[ +0.000006] ? __netif_receive_skb_core+0x1d7/0x700
[ +0.000006] ? netif_receive_skb_internal+0x2a/0x98
[ +0.000006] ? napi_gro_receive+0x6a/0xb0
[ +0.000012] ? rtl8169_poll+0x2c9/0x690 [r8169]
[ +0.000007] ? net_rx_action+0x1c6/0x2b8
[ +0.000007] ? __do_softirq+0xd8/0x200
[ +0.000005] ? irq_exit+0xa3/0xa8
[ +0.000007] ? do_IRQ+0x45/0xc0
[ +0.000009] ? common_interrupt+0x7f/0x7f
[ +0.000003] </IRQ>
[ +0.000013] ? acpi_idle_do_entry+0x2b/0xed0 [processor]
[ +0.000007] ? acpi_idle_enter+0xe1/0x288 [processor]
[ +0.000009] ? cpuidle_enter_state+0x128/0x1f0
[ +0.000008] ? do_idle+0x17a/0x1d8
[ +0.000006] ? cpu_startup_entry+0x68/0x70
[ +0.000009] ? start_secondary+0x138/0x158
[ +0.000005] ? start_cpu+0x14/0x14
[ +0.000008] ---[ end trace ab2d840ff39c9793 ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH 0/2] usbnet: Adjustments for usbnet_write_cmd_async()
From: SF Markus Elfring @ 2017-05-22 5:07 UTC (permalink / raw)
To: linux-usb, netdev, Oliver Neukum; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 07:04:03 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation
Improve a size determination
drivers/net/usb/usbnet.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--
2.13.0
^ permalink raw reply
* [PATCH 1/2] usbnet: Delete an error message for a failed memory allocation in usbnet_write_cmd_async()
From: SF Markus Elfring @ 2017-05-22 5:09 UTC (permalink / raw)
To: linux-usb, netdev, Oliver Neukum; +Cc: LKML, kernel-janitors
In-Reply-To: <a81c2551-ce6c-967d-1120-4307f95b1e65@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 06:33:48 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/usb/usbnet.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 79048e72c1bd..802ba68d37d1 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -2124,10 +2124,7 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype,
if (data) {
buf = kmemdup(data, size, GFP_ATOMIC);
- if (!buf) {
- netdev_err(dev->net, "Error allocating buffer"
- " in %s!\n", __func__);
+ if (!buf)
goto fail_free;
- }
}
--
2.13.0
^ permalink raw reply related
* [PATCH 2/2] usbnet: Improve a size determination in usbnet_write_cmd_async()
From: SF Markus Elfring @ 2017-05-22 5:10 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum
Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <a81c2551-ce6c-967d-1120-4307f95b1e65-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Date: Mon, 22 May 2017 06:42:33 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
---
drivers/net/usb/usbnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 802ba68d37d1..b73c2a40501c 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -2129,6 +2129,6 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype,
}
- req = kmalloc(sizeof(struct usb_ctrlrequest), GFP_ATOMIC);
+ req = kmalloc(sizeof(*req), GFP_ATOMIC);
if (!req)
goto fail_free_buf;
--
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/2] ieee802154: ca8210: Adjustments for two function implementations
From: SF Markus Elfring @ 2017-05-22 6:12 UTC (permalink / raw)
To: linuxdev, linux-wpan, netdev, Alexander Aring, Harry Morris,
Stefan Schmidt
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 08:08:04 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation in ca8210_probe()
Delete an error message for a failed memory allocation in ca8210_skb_rx()
drivers/net/ieee802154/ca8210.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--
2.13.0
^ permalink raw reply
* [PATCH 1/2] ieee802154: ca8210: Delete an error message for a failed memory allocation in ca8210_probe()
From: SF Markus Elfring @ 2017-05-22 6:13 UTC (permalink / raw)
To: linuxdev, linux-wpan, netdev, Alexander Aring, Harry Morris,
Stefan Schmidt
Cc: LKML, kernel-janitors
In-Reply-To: <55fddbc7-28c4-8866-67d3-ff1ff1a4eeb7@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 07:32:46 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ieee802154/ca8210.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 25fd3b04b3c0..25ed11bb5ed3 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -3143,10 +3143,6 @@ static int ca8210_probe(struct spi_device *spi_device)
pdata = kmalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
- dev_crit(
- &spi_device->dev,
- "Could not allocate platform data\n"
- );
ret = -ENOMEM;
goto error;
}
--
2.13.0
^ permalink raw reply related
* [PATCH 2/2] ieee802154: ca8210: Delete an error message for a failed memory allocation in ca8210_skb_rx()
From: SF Markus Elfring @ 2017-05-22 6:14 UTC (permalink / raw)
To: linuxdev, linux-wpan, netdev, Alexander Aring, Harry Morris,
Stefan Schmidt
Cc: LKML, kernel-janitors
In-Reply-To: <55fddbc7-28c4-8866-67d3-ff1ff1a4eeb7@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 08:03:17 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ieee802154/ca8210.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 25ed11bb5ed3..f6df75e80a60 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -1808,10 +1808,9 @@ static int ca8210_skb_rx(
/* Allocate mtu size buffer for every rx packet */
skb = dev_alloc_skb(IEEE802154_MTU + sizeof(hdr));
- if (!skb) {
- dev_crit(&priv->spi->dev, "dev_alloc_skb failed\n");
+ if (!skb)
return -ENOMEM;
- }
+
skb_reserve(skb, sizeof(hdr));
msdulen = data_ind[22]; /* msdu_length */
--
2.13.0
^ permalink raw reply related
* [PATCH 4750/4750] net: ipv4: tcp: fixed comment coding style issue
From: Rohit Chavan @ 2017-05-22 6:29 UTC (permalink / raw)
To: davem; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
Rohit Chavan
Fixed a coding style issue
Signed-off-by: Rohit Chavan <roheetchavan@gmail.com>
---
net/ipv4/tcp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1e4c76d..87b0296 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2183,7 +2183,7 @@ void tcp_close(struct sock *sk, long timeout)
/* Now socket is owned by kernel and we acquire BH lock
- to finish close. No need to check for user refs.
+ * to finish close. No need to check for user refs.
*/
local_bh_disable();
bh_lock_sock(sk);
@@ -2471,7 +2471,8 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
case TCP_MAXSEG:
/* Values greater than interface MTU won't take effect. However
* at the point when this call is done we typically don't yet
- * know which interface is going to be used */
+ * know which interface is going to be used
+ */
if (val && (val < TCP_MIN_MSS || val > MAX_TCP_WINDOW)) {
err = -EINVAL;
break;
--
2.7.4
^ permalink raw reply related
* Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
From: Jesper Dangaard Brouer @ 2017-05-22 6:39 UTC (permalink / raw)
To: Tom Herbert
Cc: Daniel Borkmann, Alexei Starovoitov,
Linux Kernel Network Developers, brouer
In-Reply-To: <CALx6S34-4kQLQLkU9QRjyfZ808f_hXV4N+bh+XG8iu1BtQOUSA@mail.gmail.com>
On Sun, 21 May 2017 15:10:29 -0700
Tom Herbert <tom@herbertland.com> wrote:
> On Sun, May 21, 2017 at 9:04 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > On Sat, 20 May 2017 09:16:09 -0700
> > Tom Herbert <tom@herbertland.com> wrote:
> >
> >> > +/* XDP rxhash have an associated type, which is related to the RSS
> >> > + * (Receive Side Scaling) standard, but NIC HW have different mapping
> >> > + * and support. Thus, create mapping that is interesting for XDP. XDP
> >> > + * would primarly want insight into L3 and L4 protocol info.
> >> > + *
> >> > + * TODO: Likely need to get extended with "L3_IPV6_EX" due RSS standard
> >> > + *
> >> > + * The HASH_TYPE will be returned from bpf helper as the top 32-bit of
> >> > + * the 64-bit rxhash (internally type stored in xdp_buff->flags).
> >> > + */
> >> > +#define XDP_HASH(x) ((x) & ((1ULL << 32)-1))
> >> > +#define XDP_HASH_TYPE(x) ((x) >> 32)
> >> > +
> >> > +#define XDP_HASH_TYPE_L3_SHIFT 0
> >> > +#define XDP_HASH_TYPE_L3_BITS 3
> >> > +#define XDP_HASH_TYPE_L3_MASK ((1ULL << XDP_HASH_TYPE_L3_BITS)-1)
> >> > +#define XDP_HASH_TYPE_L3(x) ((x) & XDP_HASH_TYPE_L3_MASK)
> >> > +enum {
> >> > + XDP_HASH_TYPE_L3_IPV4 = 1,
> >> > + XDP_HASH_TYPE_L3_IPV6,
> >> > +};
> >> > +
> >> > +#define XDP_HASH_TYPE_L4_SHIFT XDP_HASH_TYPE_L3_BITS
> >> > +#define XDP_HASH_TYPE_L4_BITS 5
> >> > +#define XDP_HASH_TYPE_L4_MASK \
> >> > + (((1ULL << XDP_HASH_TYPE_L4_BITS)-1) << XDP_HASH_TYPE_L4_SHIFT)
> >> > +#define XDP_HASH_TYPE_L4(x) ((x) & XDP_HASH_TYPE_L4_MASK)
> >> > +enum {
> >> > + _XDP_HASH_TYPE_L4_TCP = 1,
> >> > + _XDP_HASH_TYPE_L4_UDP,
> >> > +};
> >> > +#define XDP_HASH_TYPE_L4_TCP (_XDP_HASH_TYPE_L4_TCP << XDP_HASH_TYPE_L4_SHIFT)
> >> > +#define XDP_HASH_TYPE_L4_UDP (_XDP_HASH_TYPE_L4_UDP << XDP_HASH_TYPE_L4_SHIFT)
> >> > +
> >> Hi Jesper,
> >>
> >> Why do we need these indicators for protocol specific hash? It seems
> >> like L4 and L3 is useful differentiation and protocol agnostic (I'm
> >> still holding out hope that SCTP will be deployed some day ;-) )
> >
> > I'm not sure I understood the question fully, but let me try to answer
> > anyway. To me it seems obvious that you would want to know the
> > protocol/L4 type, as this helps avoid hash collisions between UDP and
> > TCP flows. I can easily imagine someone constructing an UDP packet
> > that could hash collide with a given TCP flow.
> >
> > And yes, i40 support matching SCTP, and we will create a
> > XDP_HASH_TYPE_L4_SCTP when adding XDP rxhash support for that driver.
> >
> But where would this information be used? We don't save it in skbuff,
> don't use it in RPS, RFS. RSS doesn't use it for packet steering so
> the hash collision problem already exists at the device level. If
> there is a collision problem between two protocols then maybe hash
> should be over 5-tuple instead...
One use-case (I heard at a customer) was that they had (web-)servers
that didn't serve any UDP traffic, thus they simply block/drop all
incoming UDP on the service NIC (as an ACL in the switch). (The servers
own DNS lookups and NTP goes through the management NIC to internal
DNS/NTP servers).
Another use-case: Inside an XDP/bpf program is can be used for
splitting protocol processing, into different tail calls, before even
touching packet-data. I can imagine the bpf TCP handling code is
larger, thus an optimization is to have a separate tail call for the
UDP protocol handling. One could also transfer/queue all TCP traffic
to other CPU(s) like RPS, just without touching packet memory.
This info is saved in the skb, but due to space constrains, it is
reduced to a single bit, namely skb->l4_hash, iif some
RSS-proto/XDP_HASH_TYPE_L4_* bit was set. And the network stack do use
and react on this.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] Bluetooth: Delete error messages for failed memory allocations in two functions
From: SF Markus Elfring @ 2017-05-22 6:54 UTC (permalink / raw)
To: linux-bluetooth, netdev, David S. Miller, Gustavo Padovan,
Johan Hedberg, Marcel Holtmann
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 08:42:28 +0200
Omit two extra messages for memory allocation failures in these functions.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/bluetooth/ecdh_helper.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/bluetooth/ecdh_helper.c b/net/bluetooth/ecdh_helper.c
index 24d4e60f8c48..c7b1a9aee579 100644
--- a/net/bluetooth/ecdh_helper.c
+++ b/net/bluetooth/ecdh_helper.c
@@ -92,8 +92,6 @@ bool compute_ecdh_secret(const u8 public_key[64], const u8 private_key[32],
- if (!buf) {
- pr_err("alg: kpp: Failed to allocate %d bytes for buf\n",
- buf_len);
+ if (!buf)
goto free_req;
- }
+
crypto_ecdh_encode_key(buf, buf_len, &p);
/* Set A private Key */
@@ -173,8 +171,5 @@ bool generate_ecdh_keys(u8 public_key[64], u8 private_key[32])
- if (!buf) {
- pr_err("alg: kpp: Failed to allocate %d bytes for buf\n",
- buf_len);
+ if (!buf)
goto free_req;
- }
do {
if (tries++ >= max_tries)
--
2.13.0
^ permalink raw reply related
* Re: [PATCH 2/2] usbnet: Improve a size determination in usbnet_write_cmd_async()
From: Oliver Neukum @ 2017-05-22 7:08 UTC (permalink / raw)
To: SF Markus Elfring, linux-usb, netdev; +Cc: kernel-janitors, LKML
In-Reply-To: <d5ae61d4-8339-29e4-e91c-90ba644d69aa@users.sourceforge.net>
Am Montag, den 22.05.2017, 07:10 +0200 schrieb SF Markus Elfring:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 22 May 2017 06:42:33 +0200
>
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Oliver Neukum <oneukum@suse.com>
^ permalink raw reply
* Re: [PATCH 1/2] usbnet: Delete an error message for a failed memory allocation in usbnet_write_cmd_async()
From: Oliver Neukum @ 2017-05-22 7:08 UTC (permalink / raw)
To: SF Markus Elfring, linux-usb, netdev; +Cc: kernel-janitors, LKML
In-Reply-To: <3b831fce-93ed-c017-2549-967a39c2d1da@users.sourceforge.net>
Am Montag, den 22.05.2017, 07:09 +0200 schrieb SF Markus Elfring:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 22 May 2017 06:33:48 +0200
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Oliver Neukum <oneukum@suse.com>
^ permalink raw reply
* [PATCH net-next] net/wan/fsl_ucc_hdlc: fix muram allocation error
From: Holger Brunck @ 2017-05-22 7:31 UTC (permalink / raw)
To: netdev; +Cc: Holger Brunck, Zhao Qiang
sizeof(priv->ucc_pram) is 4 as it is the size of a pointer, but we want
to reserve space for the struct ucc_hdlc_param.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Cc: Zhao Qiang <qiang.zhao@nxp.com>
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index e9b2d687f150..33df76405b86 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -189,7 +189,7 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
}
/* Alloc parameter ram for ucc hdlc */
- priv->ucc_pram_offset = qe_muram_alloc(sizeof(priv->ucc_pram),
+ priv->ucc_pram_offset = qe_muram_alloc(sizeof(struct ucc_hdlc_param),
ALIGNMENT_OF_UCC_HDLC_PRAM);
if (priv->ucc_pram_offset < 0) {
--
2.12.0.rc1
^ permalink raw reply related
* [PATCH] flowcache: Delete an error message for a failed memory allocation in flow_cache_cpu_prepare()
From: SF Markus Elfring @ 2017-05-22 7:33 UTC (permalink / raw)
To: netdev, David S. Miller, Herbert Xu, Steffen Klassert
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 09:19:51 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/core/flow.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/core/flow.c b/net/core/flow.c
index f7f5d1932a27..08c851236b97 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -412,7 +412,6 @@ static int flow_cache_cpu_prepare(struct flow_cache *fc, int cpu)
- if (!fcp->hash_table) {
- pr_err("NET: failed to allocate flow cache sz %u\n", sz);
+ if (!fcp->hash_table)
return -ENOMEM;
- }
+
fcp->hash_rnd_recalc = 1;
fcp->hash_count = 0;
tasklet_init(&fcp->flush_tasklet, flow_cache_flush_tasklet, 0);
--
2.13.0
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Delete error messages for failed memory allocations in two functions
From: Marcel Holtmann @ 2017-05-22 8:25 UTC (permalink / raw)
To: SF Markus Elfring
Cc: open list:BLUETOOTH DRIVERS, Network Development, David S. Miller,
Gustavo F. Padovan, Johan Hedberg, LKML,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0afbfdb7-48f1-4d15-d5bd-8ea40b1eb52a-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Hallo Markus,
> Omit two extra messages for memory allocation failures in these functions.
>
> This issue was detected by using the Coccinelle software.
>
> Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> ---
> net/bluetooth/ecdh_helper.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 0/2] ieee802154: ca8210: Adjustments for two function implementations
From: Marcel Holtmann @ 2017-05-22 8:28 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linuxdev, linux-wpan, Network Development, Alexander Aring,
Harry Morris, Stefan Schmidt, LKML, kernel-janitors
In-Reply-To: <55fddbc7-28c4-8866-67d3-ff1ff1a4eeb7@users.sourceforge.net>
Hi Markus,
> Two update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (2):
> Delete an error message for a failed memory allocation in ca8210_probe()
> Delete an error message for a failed memory allocation in ca8210_skb_rx()
>
> drivers/net/ieee802154/ca8210.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
both patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH 0/3] net-pktgen: Adjustments for some function implementations
From: SF Markus Elfring @ 2017-05-22 9:11 UTC (permalink / raw)
To: netdev, Alexey Dobriyan, David S. Miller, Eric Dumazet,
Florian Westphal, Günter Röck, John Fastabend,
Paolo Abeni, Willem de Bruijn
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 11:01:23 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (3):
Improve four size determinations
Delete an error message for a failed memory allocation in pktgen_create_thread()
Adjust five checks for null pointers
net/core/pktgen.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
--
2.13.0
^ permalink raw reply
* [PATCH 1/3] net: pktgen: Improve four size determinations
From: SF Markus Elfring @ 2017-05-22 9:12 UTC (permalink / raw)
To: netdev, Alexey Dobriyan, David S. Miller, Eric Dumazet,
Florian Westphal, Günter Röck, John Fastabend,
Paolo Abeni, Willem de Bruijn
Cc: LKML, kernel-janitors
In-Reply-To: <79472009-7764-bb92-5f29-60bb21793cec@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 10:34:11 +0200
Replace the specification of four data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/core/pktgen.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 96947f5d41e4..c89f4ad21187 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2995,10 +2995,10 @@ static struct sk_buff *fill_packet_ipv6(struct net_device *odev,
skb_reset_mac_header(skb);
skb_set_network_header(skb, skb->len);
- iph = (struct ipv6hdr *) skb_put(skb, sizeof(struct ipv6hdr));
+ iph = (struct ipv6hdr *)skb_put(skb, sizeof(*iph));
skb_set_transport_header(skb, skb->len);
- udph = (struct udphdr *) skb_put(skb, sizeof(struct udphdr));
+ udph = (struct udphdr *)skb_put(skb, sizeof(*udph));
skb_set_queue_mapping(skb, queue_map);
skb->priority = pkt_dev->skb_priority;
@@ -3678,5 +3678,5 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
return -EBUSY;
}
- pkt_dev = kzalloc_node(sizeof(struct pktgen_dev), GFP_KERNEL, node);
+ pkt_dev = kzalloc_node(sizeof(*pkt_dev), GFP_KERNEL, node);
if (!pkt_dev)
@@ -3756,6 +3756,5 @@ static int __net_init pktgen_create_thread(int cpu, struct pktgen_net *pn)
struct proc_dir_entry *pe;
struct task_struct *p;
- t = kzalloc_node(sizeof(struct pktgen_thread), GFP_KERNEL,
- cpu_to_node(cpu));
+ t = kzalloc_node(sizeof(*t), GFP_KERNEL, cpu_to_node(cpu));
if (!t) {
--
2.13.0
^ permalink raw reply related
* [PATCH 3/3] net: pktgen: Adjust five checks for null pointers
From: SF Markus Elfring @ 2017-05-22 9:14 UTC (permalink / raw)
To: netdev, Alexey Dobriyan, David S. Miller, Eric Dumazet,
Florian Westphal, Günter Röck, John Fastabend,
Paolo Abeni, Willem de Bruijn
Cc: LKML, kernel-janitors
In-Reply-To: <79472009-7764-bb92-5f29-60bb21793cec@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 10:44:16 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script “checkpatch.pl” pointed information out like the following.
Comparison to NULL could be written !…
Thus fix the affected source code places.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/core/pktgen.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 51008ddc7af6..a28350c9ac67 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -1986,7 +1986,7 @@ static void pktgen_mark_device(const struct pktgen_net *pn, const char *ifname)
while (1) {
pkt_dev = __pktgen_NN_threads(pn, ifname, REMOVE);
- if (pkt_dev == NULL)
+ if (!pkt_dev)
break; /* success */
mutex_unlock(&pktgen_thread_lock);
@@ -3274,7 +3274,7 @@ static struct pktgen_dev *next_to_run(struct pktgen_thread *t)
list_for_each_entry_rcu(pkt_dev, &t->if_list, list) {
if (!pkt_dev->running)
continue;
- if (best == NULL)
+ if (!best)
best = pkt_dev;
else if (ktime_compare(pkt_dev->next_tx, best->next_tx) < 0)
best = pkt_dev;
@@ -3402,7 +3402,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
kfree_skb(pkt_dev->skb);
pkt_dev->skb = fill_packet(odev, pkt_dev);
- if (pkt_dev->skb == NULL) {
+ if (!pkt_dev->skb) {
pr_err("ERROR: couldn't allocate skb in fill_packet\n");
schedule();
pkt_dev->clone_count--; /* back out increment, OOM */
@@ -3685,7 +3685,7 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
strcpy(pkt_dev->odevname, ifname);
pkt_dev->flows = vzalloc_node(MAX_CFLOWS * sizeof(struct flow_state),
node);
- if (pkt_dev->flows == NULL) {
+ if (!pkt_dev->flows) {
kfree(pkt_dev);
return -ENOMEM;
}
@@ -3868,7 +3868,7 @@ static int __net_init pg_net_init(struct net *net)
return -ENODEV;
}
pe = proc_create(PGCTRL, 0600, pn->proc_dir, &pktgen_fops);
- if (pe == NULL) {
+ if (!pe) {
pr_err("cannot create %s procfs entry\n", PGCTRL);
ret = -EINVAL;
goto remove;
--
2.13.0
^ permalink raw reply related
* [PATCH 2/3] net: pktgen: Delete an error message for a failed memory allocation in pktgen_create_thread()
From: SF Markus Elfring @ 2017-05-22 9:13 UTC (permalink / raw)
To: netdev, Alexey Dobriyan, David S. Miller, Eric Dumazet,
Florian Westphal, Günter Röck, John Fastabend,
Paolo Abeni, Willem de Bruijn
Cc: LKML, kernel-janitors
In-Reply-To: <79472009-7764-bb92-5f29-60bb21793cec@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 10:38:46 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/core/pktgen.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index c89f4ad21187..51008ddc7af6 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3760,7 +3760,5 @@ static int __net_init pktgen_create_thread(int cpu, struct pktgen_net *pn)
- if (!t) {
- pr_err("ERROR: out of memory, can't create new thread\n");
+ if (!t)
return -ENOMEM;
- }
mutex_init(&t->if_lock);
t->cpu = cpu;
--
2.13.0
^ permalink raw reply related
* [PATCH] net: fec: add post PHY reset delay DT property
From: Quentin Schulz @ 2017-05-22 9:15 UTC (permalink / raw)
To: fugang.duan-3arQi8VN3Tc, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8
Cc: Quentin Schulz, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Some PHY require to wait for a bit after the reset GPIO has been
toggled. This adds support for the DT property `phy-reset-post-delay`
which gives the delay in milliseconds to wait after reset.
If the DT property is not given, no delay is observed. Post reset delay
greater than 1000ms are invalid and are default to 1ms.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Documentation/devicetree/bindings/net/fsl-fec.txt | 5 +++++
drivers/net/ethernet/freescale/fec_main.c | 17 +++++++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
index a1e3693cca16..8795e8ca5793 100644
--- a/Documentation/devicetree/bindings/net/fsl-fec.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -15,6 +15,11 @@ Optional properties:
- phy-reset-active-high : If present then the reset sequence using the GPIO
specified in the "phy-reset-gpios" property is reversed (H=reset state,
L=operation state).
+- phy-reset-post-delay : Post reset delay in milliseconds. If present then
+ a delay of phy-reset-post-delay milliseconds will be observed after the
+ phy-reset-gpios has been toggled. Can be omitted thus no delay is
+ observed. Delay is in range of 1ms to 1000ms. If given delay is higher
+ than 1000ms, 1ms delay is done instead.
- phy-supply : regulator that powers the Ethernet PHY.
- phy-handle : phandle to the PHY device connected to this device.
- fixed-link : Assume a fixed link. See fixed-link.txt in the same directory.
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 56a563f90b0b..00a7fd0bcd59 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3192,7 +3192,7 @@ static int fec_reset_phy(struct platform_device *pdev)
{
int err, phy_reset;
bool active_high = false;
- int msec = 1;
+ int msec = 1, phy_post_delay = 0;
struct device_node *np = pdev->dev.of_node;
if (!np)
@@ -3210,7 +3210,6 @@ static int fec_reset_phy(struct platform_device *pdev)
return 0;
active_high = of_property_read_bool(np, "phy-reset-active-high");
-
err = devm_gpio_request_one(&pdev->dev, phy_reset,
active_high ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
"phy-reset");
@@ -3219,6 +3218,11 @@ static int fec_reset_phy(struct platform_device *pdev)
return err;
}
+ err = of_property_read_u32(np, "phy-reset-post-delay", &phy_post_delay);
+ /* valid reset duration should be less than 1s */
+ if (!err && phy_post_delay > 1000)
+ phy_post_delay = 1;
+
if (msec > 20)
msleep(msec);
else
@@ -3226,6 +3230,15 @@ static int fec_reset_phy(struct platform_device *pdev)
gpio_set_value_cansleep(phy_reset, !active_high);
+ if (!phy_post_delay)
+ return 0;
+
+ if (phy_post_delay > 20)
+ msleep(phy_post_delay);
+ else
+ usleep_range(phy_post_delay * 1000,
+ phy_post_delay * 1000 + 1000);
+
return 0;
}
#else /* CONFIG_OF */
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] Accept packets that the H.245 ALG can't process
From: Sergei Shtylyov @ 2017-05-22 9:25 UTC (permalink / raw)
To: Blair Steven, netdev
In-Reply-To: <20170522020753.16712-2-blair.steven@alliedtelesis.co.nz>
Hello!
On 5/22/2017 5:07 AM, Blair Steven wrote:
> When two VoIP end points are configured differently (fast connect /
> not fast connect) the ALG was failing to find a matching expectation
> and dropping packets in one direction.
>
> Dropping packets not the job of an ALG, and as such the behaviour
s/not/is not/. Perhaps could be fixed while applying...
> has been changed to allow the packet to be send to the forwarding
> engine.
>
> Signed-off-by: Blair Steven <blair.steven@alliedtelesis.co.nz>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCHv4] wlcore: add wl1285 compatible
From: Kalle Valo @ 2017-05-22 9:28 UTC (permalink / raw)
To: David S. Miller, Sebastian Reichel
Cc: Sebastian Reichel, Tony Lindgren, Marcel Holtmann, Rob Herring,
linux-wireless, linux-omap, linux-kernel, netdev
In-Reply-To: <20170505141553.2605-1-sebastian.reichel@collabora.co.uk>
Sebastian Reichel <sebastian.reichel@collabora.co.uk> writes:
> Motorola Droid 4 uses a WL1285C. With differences between the
> chips not being public let's add explicit binding for wl1285
> instead of relying on wl1283 being very similar.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> Acked-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> ---
> Hi Dave,
>
> I previously send this in two patches, but its hard to apply without
> requiring multiple kernel releases (the driver must be updated before
> the DTS change). Since the actual change is not very complex Marcel
> Holtmann & Tony Lindgren suggested, that I send this directly to you
> in a single patch for inclusion into 4.12. This also means, that the
> remaining series can be queued normally for 4.13.
I noticed that Dave set this patch to Awaiting Upstream state on his
patchwork:
https://patchwork.ozlabs.org/patch/759042/
Which makes me suspect that he is waiting me to apply this (as I
normally apply wlcore patches). Dave, should I actually take this patch?
What do you prefer?
There's a small change to arm directory but I don't see that as a
problem as Tony acked it:
Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt | 1 +
arch/arm/boot/dts/omap4-droid4-xt894.dts | 2 +-
drivers/net/wireless/ti/wlcore/sdio.c | 1 +
drivers/net/wireless/ti/wlcore/spi.c | 1 +
4 files changed, 4 insertions(+), 1 deletion(-)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] vhost/scsi: Improve a size determination in four functions
From: Stefan Hajnoczi @ 2017-05-22 9:37 UTC (permalink / raw)
To: SF Markus Elfring
Cc: kvm, Michael S. Tsirkin, netdev, kernel-janitors, LKML,
virtualization
In-Reply-To: <68e78c4b-9b18-7607-f8c8-327fdd51f20b@users.sourceforge.net>
[-- Attachment #1.1: Type: text/plain, Size: 621 bytes --]
On Sat, May 20, 2017 at 04:31:13PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 20 May 2017 13:48:44 +0200
>
> Replace the specification of four data structures by pointer dereferences
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/vhost/scsi.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 1/1] dt-binding: net: wireless: fix node name in the BCM43xx example
From: Arend van Spriel @ 2017-05-22 9:37 UTC (permalink / raw)
To: Andreas Färber, Martin Blumenstingl
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <11675313-d92f-e562-0fd5-21339b5aa599-l3A5Bk7waGM@public.gmane.org>
On 5/21/2017 4:19 PM, Andreas Färber wrote:
> Hi,
>
> Am 16.05.2017 um 21:56 schrieb Martin Blumenstingl:
>> On Tue, May 16, 2017 at 12:05 AM, Arend Van Spriel
>> <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>> On 15-5-2017 22:13, Martin Blumenstingl wrote:
>>>> The example in the BCM43xx documentation uses "brcmf" as node name.
>>>> However, wireless devices should be named "wifi" instead. Fix this to
>>>
>>> Since when is that a rule. I never got the memo and the DTC did not ever
>>> complain to me about the naming.
>
> How do you expect it to? Maintain a blacklist of every device model
> someone might use, including all typo variations?
Not really why I was asking it. Just saying the node name is trivial as
I don't think there is different kernel behaviour depending on the node
name.
>> That being said I do not really care
>>> and I suppose it is for the sake of consistency only.
>> I'm not sure if it's actually a rule or (as you already noted) just
>> for consistency. back when I added devicetree support to ath9k Rob
>> pointed out that the node should be named "wifi" (instead of "ath9k"),
>> see [0]
>
> The general rule is that the node name should be the type of the device,
> not duplicate its compatible string.
>
> For consistency Rob was asking we use "wifi" as node name.
Fine with that. Not sure how long ago it was that I added this binding,
but DT folks were involved back than. I never looked back so I should
not be surprised with new consistency rules. I was just curious about
the story behind it.
Thanks,
Arend
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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