* RE: [PATCH v3 2/3] net: phy: DP83822 initial driver submission
From: Woojung.Huh @ 2017-10-09 16:27 UTC (permalink / raw)
To: dmurphy, andrew, f.fainelli; +Cc: netdev, afd
In-Reply-To: <20171009120302.23611-2-dmurphy@ti.com>
> Subject: [PATCH v3 2/3] net: phy: DP83822 initial driver submission
>
> Add support for the TI DP83822 10/100Mbit ethernet phy.
>
> The DP83822 provides flexibility to connect to a MAC through a
> standard MII, RMII or RGMII interface.
>
> Datasheet:
> http://www.ti.com/product/DP83822I/datasheet
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
Reviewed-by: Woojung Huh <woojung.huh@microchip.com>
^ permalink raw reply
* Re: [net-next 14/15] i40e: ignore skb->xmit_more when deciding to set RS bit
From: Alexander Duyck @ 2017-10-09 16:28 UTC (permalink / raw)
To: David Laight
Cc: Jeff Kirsher, davem@davemloft.net, Jacob Keller,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD008D373@AcuExch.aculab.com>
On Mon, Oct 9, 2017 at 2:07 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Jeff Kirsher
>> Sent: 06 October 2017 18:57
>> From: Jacob Keller <jacob.e.keller@intel.com>
>>
>> Since commit 6a7fded776a7 ("i40e: Fix RS bit update in Tx path and
>> disable force WB workaround") we've tried to "optimize" setting the
>> RS bit based around skb->xmit_more. This same logic was refactored
>> in commit 1dc8b538795f ("i40e: Reorder logic for coalescing RS bits"),
>> but ultimately was not functionally changed.
>
> I've tried to understand the above, but without definitions of WB
> and RS and the '4-ness' of something it is quite difficult.
>
> I THINK this is all about telling the hardware there is a packet
> in the ring to transmit?
>
> I don't understand the 4-ness. Linux requires that the hardware
> be notified of a single packet transmit, and that the 'transmit
> complete' also be notified in 'a timely manner' for a single packet.
So to clarify some of this. The RS is short for Report Status. It
tells the hardware that when it has completed the descriptor it should
trigger a write back, aka WB.
The 4-ness is because each descriptor is 16 bytes, so if we write back
once every 4 descriptors that is one 64B cache line which is much
better for most platforms performance wise.
> skb->xmit_more ought to be usable to optimise both of these
> (assuming it isn't a lie).
Actually it leads to issues if we hold off for too long. If we are
busy dequeueing a long list, and the Tx queue has gone empty then we
are stalling Tx without need to do so. We need to be regularly
notifying the device that it has buffers available to transmit which
is what xmit_more is good for. However in addition the hardware needs
to notify us regularly that there are buffers ready to clean which it
isn't necessarily so useful for, especially if are filling the entire
ring and only providing one notification to the driver that there are
buffers ready since we can defer the Tx interrupt for too long.
What Jake is trying to fix here is to prevent us from generating what
looks like a square wave in terms of throughput. Essentially the
current behavior that is being seen is that all the buffers in the
ring either belong to software, or belong to hardware. It is best for
us to have this split half and half so that the hardware has buffers
to transmit and software has buffers to clean and enqueue new buffers
onto.
> The driver would need to ensure a ring full of messages isn't
> generated without either wakeup - but that might be 128 frames.
That is what is happening here. Basically we are guaranteeing
writebacks are occurring on a regular basis instead of in large
bursts.
> FWIW on the systems I have PCIe writes are relatively cheap
> (reads are slow). So different counts would be appropriate
> for delaying doorbell writes and requesting completion interrupts.
>
> David
The doorbell writes are still being delayed the same amount with this
patch. The only thing that was split out was the device write backs
are now occurring on a more regular basis instead of being held off
until a much larger set is handled.
- Alex
^ permalink raw reply
* Re: [PATCH net] ipv6: Fix traffic triggered IPsec connections.
From: David Miller @ 2017-10-09 16:41 UTC (permalink / raw)
To: steffen.klassert; +Cc: tobias, weiwan, netdev
In-Reply-To: <20171009063943.GG3149@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 9 Oct 2017 08:39:43 +0200
> A recent patch removed the dst_free() on the allocated
> dst_entry in ipv6_blackhole_route(). The dst_free() marked
> the dst_entry as dead and added it to the gc list. I.e. it
> was setup for a one time usage. As a result we may now have
> a blackhole route cached at a socket on some IPsec scenarios.
> This makes the connection unusable.
>
> Fix this by marking the dst_entry directly at allocation time
> as 'dead', so it is used only once.
>
> Fixes: 587fea741134 ("ipv6: mark DST_NOGC and remove the operation of dst_free()")
> Reported-by: Tobias Brunner <tobias@strongswan.org>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv4: Fix traffic triggered IPsec connections.
From: David Miller @ 2017-10-09 16:41 UTC (permalink / raw)
To: steffen.klassert; +Cc: tobias, weiwan, netdev
In-Reply-To: <20171009064355.GI3149@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 9 Oct 2017 08:43:55 +0200
> A recent patch removed the dst_free() on the allocated
> dst_entry in ipv4_blackhole_route(). The dst_free() marked the
> dst_entry as dead and added it to the gc list. I.e. it was setup
> for a one time usage. As a result we may now have a blackhole
> route cached at a socket on some IPsec scenarios. This makes the
> connection unusable.
>
> Fix this by marking the dst_entry directly at allocation time
> as 'dead', so it is used only once.
>
> Fixes: b838d5e1c5b6 ("ipv4: mark DST_NOGC and remove the operation of dst_free()")
> Reported-by: Tobias Brunner <tobias@strongswan.org>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: avoid zeroing per cpu data again
From: Martin KaFai Lau @ 2017-10-09 16:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Tejun Heo
In-Reply-To: <1507554097.31614.11.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, Oct 09, 2017 at 01:01:37PM +0000, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> per cpu allocations are already zeroed, no need to clear them again.
>
> Fixes: d52d3997f843f ("ipv6: Create percpu rt6_info")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Tejun Heo <tj@kernel.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ permalink raw reply
* Re: [PATCH v3 1/3] net: phy: Remove TI DP83822 from DP83848 driver
From: Florian Fainelli @ 2017-10-09 16:44 UTC (permalink / raw)
To: Dan Murphy, andrew; +Cc: netdev, Woojung.Huh, afd
In-Reply-To: <20171009120302.23611-1-dmurphy@ti.com>
On 10/09/2017 05:03 AM, Dan Murphy wrote:
> Removing the DP83822 device from the DP83848 to
> support the TI DP83822 dedicated driver that will
> initially support WoL settings.
Hi Dan,
The ordering of patch 1 and 2 may have to be reversed, otherwise you are
leaving people with the Generic PHY driver matching the DP83822 PHY
after applying patch 1, and without proper interrupt management again
unless they apply patch 2.
It may even be better to combine patch 1 and 2 actually to have a
cleaner transition.
Sorry for noticing this so late in the series...
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v3 - No changes made
> v2 - There was no v1 on this patch this is new.
>
> drivers/net/phy/dp83848.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c
> index 3de4fe4dda77..3966d43c5146 100644
> --- a/drivers/net/phy/dp83848.c
> +++ b/drivers/net/phy/dp83848.c
> @@ -20,7 +20,6 @@
> #define TI_DP83620_PHY_ID 0x20005ce0
> #define NS_DP83848C_PHY_ID 0x20005c90
> #define TLK10X_PHY_ID 0x2000a210
> -#define TI_DP83822_PHY_ID 0x2000a240
>
> /* Registers */
> #define DP83848_MICR 0x11 /* MII Interrupt Control Register */
> @@ -80,7 +79,6 @@ static struct mdio_device_id __maybe_unused dp83848_tbl[] = {
> { NS_DP83848C_PHY_ID, 0xfffffff0 },
> { TI_DP83620_PHY_ID, 0xfffffff0 },
> { TLK10X_PHY_ID, 0xfffffff0 },
> - { TI_DP83822_PHY_ID, 0xfffffff0 },
> { }
> };
> MODULE_DEVICE_TABLE(mdio, dp83848_tbl);
> @@ -110,7 +108,6 @@ static struct phy_driver dp83848_driver[] = {
> DP83848_PHY_DRIVER(NS_DP83848C_PHY_ID, "NS DP83848C 10/100 Mbps PHY"),
> DP83848_PHY_DRIVER(TI_DP83620_PHY_ID, "TI DP83620 10/100 Mbps PHY"),
> DP83848_PHY_DRIVER(TLK10X_PHY_ID, "TI TLK10X 10/100 Mbps PHY"),
> - DP83848_PHY_DRIVER(TI_DP83822_PHY_ID, "TI DP83822 10/100 Mbps PHY"),
> };
> module_phy_driver(dp83848_driver);
>
>
--
Florian
^ permalink raw reply
* Re: pull request (net): ipsec 2017-10-09
From: David Miller @ 2017-10-09 16:44 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1507533399-29399-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 9 Oct 2017 09:16:35 +0200
> 1) Fix some error paths of the IPsec offloading API.
>
> 2) Fix a NULL pointer dereference when IPsec is used
> with vti. From Alexey Kodanev.
>
> 3) Don't call xfrm_policy_cache_flush under xfrm_state_lock,
> it triggers several locking warnings. From Artem Savkov.
>
> Please pull or let me know if there are problems.
Pulled, thank you.
^ permalink raw reply
* [PATCH] net: thunderx: mark expected switch fall-throughs in nicvf_main()
From: Gustavo A. R. Silva @ 2017-10-09 16:44 UTC (permalink / raw)
To: Sunil Goutham, Robert Richter
Cc: linux-arm-kernel, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Cc: Sunil Goutham <sgoutham@cavium.com>
Cc: Robert Richter <rric@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: netdev@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index d68478a..71989e1 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -566,8 +566,10 @@ static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
return true;
default:
bpf_warn_invalid_xdp_action(action);
+ /* fall through */
case XDP_ABORTED:
trace_xdp_exception(nic->netdev, prog, action);
+ /* fall through */
case XDP_DROP:
/* Check if it's a recycled page, if not
* unmap the DMA mapping.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 1/3] net: phy: Remove TI DP83822 from DP83848 driver
From: Dan Murphy @ 2017-10-09 16:45 UTC (permalink / raw)
To: Florian Fainelli, andrew; +Cc: netdev, Woojung.Huh, afd
In-Reply-To: <b1dc0e7e-7024-7111-1a15-59a114207555@gmail.com>
Florian
On 10/09/2017 11:44 AM, Florian Fainelli wrote:
> On 10/09/2017 05:03 AM, Dan Murphy wrote:
>> Removing the DP83822 device from the DP83848 to
>> support the TI DP83822 dedicated driver that will
>> initially support WoL settings.
> Hi Dan,
>
> The ordering of patch 1 and 2 may have to be reversed, otherwise you are
> leaving people with the Generic PHY driver matching the DP83822 PHY
> after applying patch 1, and without proper interrupt management again
> unless they apply patch 2.
>
> It may even be better to combine patch 1 and 2 actually to have a
> cleaner transition.
>
No worries I will squash patch 1 and 2.
Dan
> Sorry for noticing this so late in the series...
>
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>>
>> v3 - No changes made
>> v2 - There was no v1 on this patch this is new.
>>
>> drivers/net/phy/dp83848.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c
>> index 3de4fe4dda77..3966d43c5146 100644
>> --- a/drivers/net/phy/dp83848.c
>> +++ b/drivers/net/phy/dp83848.c
>> @@ -20,7 +20,6 @@
>> #define TI_DP83620_PHY_ID 0x20005ce0
>> #define NS_DP83848C_PHY_ID 0x20005c90
>> #define TLK10X_PHY_ID 0x2000a210
>> -#define TI_DP83822_PHY_ID 0x2000a240
>>
>> /* Registers */
>> #define DP83848_MICR 0x11 /* MII Interrupt Control Register */
>> @@ -80,7 +79,6 @@ static struct mdio_device_id __maybe_unused dp83848_tbl[] = {
>> { NS_DP83848C_PHY_ID, 0xfffffff0 },
>> { TI_DP83620_PHY_ID, 0xfffffff0 },
>> { TLK10X_PHY_ID, 0xfffffff0 },
>> - { TI_DP83822_PHY_ID, 0xfffffff0 },
>> { }
>> };
>> MODULE_DEVICE_TABLE(mdio, dp83848_tbl);
>> @@ -110,7 +108,6 @@ static struct phy_driver dp83848_driver[] = {
>> DP83848_PHY_DRIVER(NS_DP83848C_PHY_ID, "NS DP83848C 10/100 Mbps PHY"),
>> DP83848_PHY_DRIVER(TI_DP83620_PHY_ID, "TI DP83620 10/100 Mbps PHY"),
>> DP83848_PHY_DRIVER(TLK10X_PHY_ID, "TI TLK10X 10/100 Mbps PHY"),
>> - DP83848_PHY_DRIVER(TI_DP83822_PHY_ID, "TI DP83822 10/100 Mbps PHY"),
>> };
>> module_phy_driver(dp83848_driver);
>>
>>
>
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH v3 3/3] net: phy: Change error to EINVAL for invalid MAC
From: Florian Fainelli @ 2017-10-09 16:47 UTC (permalink / raw)
To: Dan Murphy, andrew; +Cc: netdev, Woojung.Huh, afd
In-Reply-To: <20171009120302.23611-3-dmurphy@ti.com>
On 10/09/2017 05:03 AM, Dan Murphy wrote:
> Change the return error code to EINVAL if the MAC
> address is not valid in the set_wol function.
Looks fine to me, since you are respining, do you mind using "net: phy:
at803x: Change error to EINVAL for invalid MAC" as a subject to further
specify what this is about?
Thanks!
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v3 - No changes made
> v2 - There was no v1 on this patch this is new.
>
> drivers/net/phy/at803x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index c1e52b9dc58d..5f93e6add563 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -167,7 +167,7 @@ static int at803x_set_wol(struct phy_device *phydev,
> mac = (const u8 *) ndev->dev_addr;
>
> if (!is_valid_ether_addr(mac))
> - return -EFAULT;
> + return -EINVAL;
>
> for (i = 0; i < 3; i++) {
> phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 0/7] A few cleanup for hns3 ethernet driver
From: David Miller @ 2017-10-09 16:50 UTC (permalink / raw)
To: linyunsheng
Cc: huangdaode, xuwei5, liguozhu, Yisen.Zhuang, gabriele.paoloni,
john.garry, linuxarm, salil.mehta, lipeng321, netdev,
linux-kernel
In-Reply-To: <1507535041-204956-1-git-send-email-linyunsheng@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Mon, 9 Oct 2017 15:43:54 +0800
> This patchset contains a few cleanup for hns3 ethernet driver.
> No functional change intended.
Series applied, thank you.
^ permalink raw reply
* Re: pull request: linux-firmware: update cxgb4 firmware
From: Ben Hutchings @ 2017-10-09 16:50 UTC (permalink / raw)
To: Ganesh Goudar, linux-firmware
Cc: linux-kernel, nirranjan, indranil, venkatesh, netdev
In-Reply-To: <1506525877-6675-1-git-send-email-ganeshgr@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]
On Wed, 2017-09-27 at 20:54 +0530, Ganesh Goudar wrote:
> Hi,
>
> Kindly pull the new firmware from the following URL.
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
Pulled, thanks.
Ben.
> Thanks
> Ganesh
>
> The following changes since commit 59bf7e2cad88269ea704eb270d7ac6e69e8a544c:
>
> cxgb4: update firmware to revision 1.16.63.0 (2017-09-27 08:14:29 -0700)
>
> are available in the git repository at:
>
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
>
> for you to fetch changes up to 59bf7e2cad88269ea704eb270d7ac6e69e8a544c:
>
> cxgb4: update firmware to revision 1.16.63.0 (2017-09-27 08:14:29 -0700)
>
> ----------------------------------------------------------------
--
Ben Hutchings
Humour is the best antidote to reality.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 00/15] nfp: bpf ABIv2 and multi port
From: David Miller @ 2017-10-09 16:52 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20171009040417.22172-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Sun, 8 Oct 2017 21:04:02 -0700
> This series migrates our eBPF offload from old PoC firmware to
> a redesigned, faster and more feature rich FW. Marking support
> is dropped for now. We have to teach the JIT about encoding
> local memory accesses (one of NFP memory types). There is also
> code to populate the ECC of instructions (PoC had ECC protection
> on instruction store disabled). There is also a minor ld_field
> fix and all 64 bit shifts can now be encoded.
Thank you for structuring this series the way you did, as this made it
very easy to review.
Series applied.
^ permalink raw reply
* [PATCH net-next 0/2] ipv6: addrlabel: avoid dirtying ip6addrlbl_entry
From: Eric Dumazet @ 2017-10-09 16:52 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Hideaki YOSHIFUJI
The refcount on ip6addrlbl_entry is only used to make sure ip6addrlbl_entry
does not disappear while ip6addrlbl_get() is allocating an skb.
We can instead allocate skb first, then use RCU, so that we no longer need
to refcount these structures.
Eric Dumazet (2):
ipv6: addrlabel: rework ip6addrlbl_get()
ipv6: addrlabel: remove refcounting
net/ipv6/addrlabel.c | 69 +++++++++++++---------------------------------------
1 file changed, 17 insertions(+), 52 deletions(-)
--
2.14.2.920.gcf0c67979c-goog
^ permalink raw reply
* [PATCH net-next 1/2] ipv6: addrlabel: rework ip6addrlbl_get()
From: Eric Dumazet @ 2017-10-09 16:52 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Hideaki YOSHIFUJI
In-Reply-To: <20171009165225.7008-1-edumazet@google.com>
If we allocate skb before the lookup, we can use RCU
without the need of ip6addrlbl_hold()
This means that the following patch can get rid of refcounting.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/addrlabel.c | 36 +++++++++++++-----------------------
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
index c6311d7108f651c7385cd6316752ba4a86667dcc..f31489652c4ae1fc0c93d1756e13717f0689b0ab 100644
--- a/net/ipv6/addrlabel.c
+++ b/net/ipv6/addrlabel.c
@@ -546,38 +546,28 @@ static int ip6addrlbl_get(struct sk_buff *in_skb, struct nlmsghdr *nlh,
return -EINVAL;
addr = nla_data(tb[IFAL_ADDRESS]);
- rcu_read_lock();
- p = __ipv6_addr_label(net, addr, ipv6_addr_type(addr), ifal->ifal_index);
- if (p && !ip6addrlbl_hold(p))
- p = NULL;
- lseq = net->ipv6.ip6addrlbl_table.seq;
- rcu_read_unlock();
-
- if (!p) {
- err = -ESRCH;
- goto out;
- }
-
skb = nlmsg_new(ip6addrlbl_msgsize(), GFP_KERNEL);
- if (!skb) {
- ip6addrlbl_put(p);
+ if (!skb)
return -ENOBUFS;
- }
- err = ip6addrlbl_fill(skb, p, lseq,
- NETLINK_CB(in_skb).portid, nlh->nlmsg_seq,
- RTM_NEWADDRLABEL, 0);
+ err = -ESRCH;
- ip6addrlbl_put(p);
+ rcu_read_lock();
+ p = __ipv6_addr_label(net, addr, ipv6_addr_type(addr), ifal->ifal_index);
+ lseq = net->ipv6.ip6addrlbl_table.seq;
+ if (p)
+ err = ip6addrlbl_fill(skb, p, lseq,
+ NETLINK_CB(in_skb).portid,
+ nlh->nlmsg_seq,
+ RTM_NEWADDRLABEL, 0);
+ rcu_read_unlock();
if (err < 0) {
WARN_ON(err == -EMSGSIZE);
kfree_skb(skb);
- goto out;
+ } else {
+ err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid);
}
-
- err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid);
-out:
return err;
}
--
2.14.2.920.gcf0c67979c-goog
^ permalink raw reply related
* [PATCH net-next 2/2] ipv6: addrlabel: remove refcounting
From: Eric Dumazet @ 2017-10-09 16:52 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Hideaki YOSHIFUJI
In-Reply-To: <20171009165225.7008-1-edumazet@google.com>
After previous patch ("ipv6: addrlabel: rework ip6addrlbl_get()")
we can remove the refcount from struct ip6addrlbl_entry,
since it is no longer elevated in p6addrlbl_get()
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/addrlabel.c | 33 ++++-----------------------------
1 file changed, 4 insertions(+), 29 deletions(-)
diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
index f31489652c4ae1fc0c93d1756e13717f0689b0ab..2606d2fa3ac4c8e7d13071d1895cf4e6e36a4116 100644
--- a/net/ipv6/addrlabel.c
+++ b/net/ipv6/addrlabel.c
@@ -18,7 +18,6 @@
#include <linux/if_addrlabel.h>
#include <linux/netlink.h>
#include <linux/rtnetlink.h>
-#include <linux/refcount.h>
#if 0
#define ADDRLABEL(x...) printk(x)
@@ -36,7 +35,6 @@ struct ip6addrlbl_entry {
int addrtype;
u32 label;
struct hlist_node list;
- refcount_t refcnt;
struct rcu_head rcu;
};
@@ -111,28 +109,6 @@ static const __net_initconst struct ip6addrlbl_init_table
}
};
-/* Object management */
-static inline void ip6addrlbl_free(struct ip6addrlbl_entry *p)
-{
- kfree(p);
-}
-
-static void ip6addrlbl_free_rcu(struct rcu_head *h)
-{
- ip6addrlbl_free(container_of(h, struct ip6addrlbl_entry, rcu));
-}
-
-static bool ip6addrlbl_hold(struct ip6addrlbl_entry *p)
-{
- return refcount_inc_not_zero(&p->refcnt);
-}
-
-static inline void ip6addrlbl_put(struct ip6addrlbl_entry *p)
-{
- if (refcount_dec_and_test(&p->refcnt))
- call_rcu(&p->rcu, ip6addrlbl_free_rcu);
-}
-
/* Find label */
static bool __ip6addrlbl_match(const struct ip6addrlbl_entry *p,
const struct in6_addr *addr,
@@ -219,7 +195,6 @@ static struct ip6addrlbl_entry *ip6addrlbl_alloc(const struct in6_addr *prefix,
newp->addrtype = addrtype;
newp->label = label;
INIT_HLIST_NODE(&newp->list);
- refcount_set(&newp->refcnt, 1);
return newp;
}
@@ -243,7 +218,7 @@ static int __ip6addrlbl_add(struct net *net, struct ip6addrlbl_entry *newp,
goto out;
}
hlist_replace_rcu(&p->list, &newp->list);
- ip6addrlbl_put(p);
+ kfree_rcu(p, rcu);
goto out;
} else if ((p->prefixlen == newp->prefixlen && !p->ifindex) ||
(p->prefixlen < newp->prefixlen)) {
@@ -281,7 +256,7 @@ static int ip6addrlbl_add(struct net *net,
ret = __ip6addrlbl_add(net, newp, replace);
spin_unlock(&net->ipv6.ip6addrlbl_table.lock);
if (ret)
- ip6addrlbl_free(newp);
+ kfree(newp);
return ret;
}
@@ -302,7 +277,7 @@ static int __ip6addrlbl_del(struct net *net,
p->ifindex == ifindex &&
ipv6_addr_equal(&p->prefix, prefix)) {
hlist_del_rcu(&p->list);
- ip6addrlbl_put(p);
+ kfree_rcu(p, rcu);
ret = 0;
break;
}
@@ -360,7 +335,7 @@ static void __net_exit ip6addrlbl_net_exit(struct net *net)
spin_lock(&net->ipv6.ip6addrlbl_table.lock);
hlist_for_each_entry_safe(p, n, &net->ipv6.ip6addrlbl_table.head, list) {
hlist_del_rcu(&p->list);
- ip6addrlbl_put(p);
+ kfree_rcu(p, rcu);
}
spin_unlock(&net->ipv6.ip6addrlbl_table.lock);
}
--
2.14.2.920.gcf0c67979c-goog
^ permalink raw reply related
* Re: [PATCH 0/4] RCU: introduce noref debug
From: Paolo Abeni @ 2017-10-09 16:53 UTC (permalink / raw)
To: paulmck
Cc: linux-kernel, Josh Triplett, Steven Rostedt, David S. Miller,
Eric Dumazet, Hannes Frederic Sowa, netdev
In-Reply-To: <20171006163414.GC3521@linux.vnet.ibm.com>
On Fri, 2017-10-06 at 09:34 -0700, Paul E. McKenney wrote:
> On Fri, Oct 06, 2017 at 05:10:09PM +0200, Paolo Abeni wrote:
> > Hi,
> >
> > On Fri, 2017-10-06 at 06:34 -0700, Paul E. McKenney wrote:
> > > On Fri, Oct 06, 2017 at 02:57:45PM +0200, Paolo Abeni wrote:
> > > > The networking subsystem is currently using some kind of long-lived
> > > > RCU-protected, references to avoid the overhead of full book-keeping.
> > > >
> > > > Such references - skb_dst() noref - are stored inside the skbs and can be
> > > > moved across relevant slices of the network stack, with the users
> > > > being in charge of properly clearing the relevant skb - or properly refcount
> > > > the related dst references - before the skb escapes the RCU section.
> > > >
> > > > We currently don't have any deterministic debug infrastructure to check
> > > > the dst noref usages - and the introduction of others noref artifact is
> > > > currently under discussion.
> > > >
> > > > This series tries to tackle the above introducing an RCU debug infrastructure
> > > > aimed at spotting incorrect noref pointer usage, in patch one. The
> > > > infrastructure is small and must be explicitly enabled via a newly introduced
> > > > build option.
> > > >
> > > > Patch two uses such infrastructure to track dst noref usage in the networking
> > > > stack.
> > > >
> > > > Patch 3 and 4 are bugfixes for small buglet found running this infrastructure
> > > > on basic scenarios.
> >
> > Thank you for the prompt reply!
> > >
> > > This patchset does not look like it handles rcu_read_lock() nesting.
> > > For example, given code like this:
> > >
> > > void foo(void)
> > > {
> > > rcu_read_lock();
> > > rcu_track_noref(&key2, &noref2, true);
> > > do_something();
> > > rcu_track_noref(&key2, &noref2, false);
> > > rcu_read_unlock();
> > > }
> > >
> > > void bar(void)
> > > {
> > > rcu_read_lock();
> > > rcu_track_noref(&key1, &noref1, true);
> > > do_something_more();
> > > foo();
> > > do_something_else();
> > > rcu_track_noref(&key1, &noref1, false);
> > > rcu_read_unlock();
> > > }
> > >
> > > void grill(void)
> > > {
> > > foo();
> > > }
> > >
> > > It looks like foo()'s rcu_read_unlock() will complain about key1.
> > > You could remove foo()'s rcu_read_lock() and rcu_read_unlock(), but
> > > that will break the call from grill().
> >
> > Actually the code should cope correctly with your example; when foo()'s
> > rcu_read_unlock() is called, 'cache' contains:
> >
> > { { &key1, &noref1, 1}, // ...
> >
> > and when the related __rcu_check_noref() is invoked preempt_count() is
> > 2 - because the check is called before decreasing the preempt counter.
> >
> > In the main loop inside __rcu_check_noref() we will hit always the
> > 'continue' statement because 'cache->store[i].nesting != nesting', so
> > no warn will be triggered.
>
> You are right, it was too early, and my example wasn't correct. How
> about this one?
>
> void foo(void (*f)(struct s *sp), struct s **spp)
> {
> rcu_read_lock();
> rcu_track_noref(&key2, &noref2, true);
> f(spp);
> rcu_track_noref(&key2, &noref2, false);
> rcu_read_unlock();
> }
>
> void barcb(struct s **spp)
> {
> *spp = &noref3;
> rcu_track_noref(&key3, *spp, true);
> }
>
> void bar(void)
> {
> struct s *sp;
>
> rcu_read_lock();
> rcu_track_noref(&key1, &noref1, true);
> do_something_more();
> foo(barcb, &sp);
> do_something_else(sp);
> rcu_track_noref(&key3, sp, false);
> rcu_track_noref(&key1, &noref1, false);
> rcu_read_unlock();
> }
>
> void grillcb(struct s **spp)
> {
> *spp
> }
>
> void grill(void)
> {
> foo();
> }
You are right: this will generate a splat, even if the code it safe.
The false positive can be avoided looking for leaked references only in
the outermost rcu unlook. I did a previous implementation performing
such check, but it emitted very generic splat so I tried to be more
strict. The latter choice allowed to find/do 3/4.
What about using save_stack_trace() in rcu_track_noref(, true) and
reporting such stack trace when the check in the outer most rcu fails?
the current strict/false-postive-prone check could be enabled under an
additional build flag.
> How does the user select the key argument? It looks like someone
> can choose to just pass in NULL -- is that the intent, or am I confused
> about this as well?
The 'key' argument is intented to discriminate the scope of the same
noref dst attached to different skbs, which happens e.g. as a result of
as skb_dst_copy().
In a generic use case, it can be NULL, too.
> I am also concerned about false negatives when the user invokes
> rcu_track_noref(..., false) but then leaks the pointer anyway. Or is
> there something you are doing that catches this that I am missing?
If the rcu_track_noref(..., false) is misplaced or missing, yes we can
have false negative.
In the noref rcu use-case the rcu_track_noref(, false) call is/must be
placed side-by-side with the code clearing the the noref pointer, so
is/should be quite easy avoiding such mistakes.
Cheers,
Paolo
^ permalink raw reply
* Re: pull-request: mac80211 2017-10-09
From: David Miller @ 2017-10-09 16:53 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20171009074013.1979-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 9 Oct 2017 09:40:12 +0200
> The QCA folks found another netlink problem - we were missing validation
> of some attributes. It's not super problematic since one can only read a
> few bytes beyond the message (and that memory must exist), but here's the
> fix for it.
>
> I thought perhaps we can make nla_parse_nested() require a policy, but
> given the two-stage validation/parsing in regular netlink that won't work.
>
> Please pull and let me know if there's any problem.
Yeah, nested parsing is messy validation-wise.
Pulled, thanks Johannes.
^ permalink raw reply
* [PATCH v4 1/2] net: phy: DP83822 initial driver submission
From: Dan Murphy @ 2017-10-09 16:59 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, Woojung.Huh, afd, Dan Murphy
Add support for the TI DP83822 10/100Mbit ethernet phy.
The DP83822 provides flexibility to connect to a MAC through a
standard MII, RMII or RGMII interface.
In addition the DP83822 needs to be removed from the DP83848 driver
as the WoL support is added here for this device.
Datasheet:
http://www.ti.com/product/DP83822I/datasheet
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v4 - Squash DP83822 removal patch into this patch -
https://www.mail-archive.com/netdev@vger.kernel.org/msg192424.html
v3 - Fixed WoL indication bit and removed mutex for suspend/resume -
https://www.mail-archive.com/netdev@vger.kernel.org/msg191891.html and
https://www.mail-archive.com/netdev@vger.kernel.org/msg191665.html
v2 - Updated per comments. Removed unnessary parantheis, called genphy_suspend/
resume routines and then performing WoL changes, reworked sopass storage and reduced
the number of phy reads, and moved WOL_SECURE_ON -
https://www.mail-archive.com/netdev@vger.kernel.org/msg191392.html
drivers/net/phy/Kconfig | 5 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/dp83822.c | 302 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/phy/dp83848.c | 3 -
4 files changed, 308 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/phy/dp83822.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index cd931cf9dcc2..8e78a482e09e 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -277,6 +277,11 @@ config DAVICOM_PHY
---help---
Currently supports dm9161e and dm9131
+config DP83822_PHY
+ tristate "Texas Instruments DP83822 PHY"
+ ---help---
+ Supports the DP83822 PHY.
+
config DP83848_PHY
tristate "Texas Instruments DP83848 PHY"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 416df92fbf4f..df3b82ba8550 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_CICADA_PHY) += cicada.o
obj-$(CONFIG_CORTINA_PHY) += cortina.o
obj-$(CONFIG_DAVICOM_PHY) += davicom.o
obj-$(CONFIG_DP83640_PHY) += dp83640.o
+obj-$(CONFIG_DP83822_PHY) += dp83822.o
obj-$(CONFIG_DP83848_PHY) += dp83848.o
obj-$(CONFIG_DP83867_PHY) += dp83867.o
obj-$(CONFIG_FIXED_PHY) += fixed_phy.o
diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/dp83822.c
new file mode 100644
index 000000000000..de196dbc46cd
--- /dev/null
+++ b/drivers/net/phy/dp83822.c
@@ -0,0 +1,302 @@
+/*
+ * Driver for the Texas Instruments DP83822 PHY
+ *
+ * Copyright (C) 2017 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/ethtool.h>
+#include <linux/etherdevice.h>
+#include <linux/kernel.h>
+#include <linux/mii.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy.h>
+#include <linux/netdevice.h>
+
+#define DP83822_PHY_ID 0x2000a240
+#define DP83822_DEVADDR 0x1f
+
+#define MII_DP83822_MISR1 0x12
+#define MII_DP83822_MISR2 0x13
+#define MII_DP83822_RESET_CTRL 0x1f
+
+#define DP83822_HW_RESET BIT(15)
+#define DP83822_SW_RESET BIT(14)
+
+/* MISR1 bits */
+#define DP83822_RX_ERR_HF_INT_EN BIT(0)
+#define DP83822_FALSE_CARRIER_HF_INT_EN BIT(1)
+#define DP83822_ANEG_COMPLETE_INT_EN BIT(2)
+#define DP83822_DUP_MODE_CHANGE_INT_EN BIT(3)
+#define DP83822_SPEED_CHANGED_INT_EN BIT(4)
+#define DP83822_LINK_STAT_INT_EN BIT(5)
+#define DP83822_ENERGY_DET_INT_EN BIT(6)
+#define DP83822_LINK_QUAL_INT_EN BIT(7)
+
+/* MISR2 bits */
+#define DP83822_JABBER_DET_INT_EN BIT(0)
+#define DP83822_WOL_PKT_INT_EN BIT(1)
+#define DP83822_SLEEP_MODE_INT_EN BIT(2)
+#define DP83822_MDI_XOVER_INT_EN BIT(3)
+#define DP83822_LB_FIFO_INT_EN BIT(4)
+#define DP83822_PAGE_RX_INT_EN BIT(5)
+#define DP83822_ANEG_ERR_INT_EN BIT(6)
+#define DP83822_EEE_ERROR_CHANGE_INT_EN BIT(7)
+
+/* INT_STAT1 bits */
+#define DP83822_WOL_INT_EN BIT(4)
+#define DP83822_WOL_INT_STAT BIT(12)
+
+#define MII_DP83822_RXSOP1 0x04a5
+#define MII_DP83822_RXSOP2 0x04a6
+#define MII_DP83822_RXSOP3 0x04a7
+
+/* WoL Registers */
+#define MII_DP83822_WOL_CFG 0x04a0
+#define MII_DP83822_WOL_STAT 0x04a1
+#define MII_DP83822_WOL_DA1 0x04a2
+#define MII_DP83822_WOL_DA2 0x04a3
+#define MII_DP83822_WOL_DA3 0x04a4
+
+/* WoL bits */
+#define DP83822_WOL_MAGIC_EN BIT(1)
+#define DP83822_WOL_SECURE_ON BIT(5)
+#define DP83822_WOL_EN BIT(7)
+#define DP83822_WOL_INDICATION_SEL BIT(8)
+#define DP83822_WOL_CLR_INDICATION BIT(11)
+
+static int dp83822_ack_interrupt(struct phy_device *phydev)
+{
+ int err = phy_read(phydev, MII_DP83822_MISR1);
+
+ if (err < 0)
+ return err;
+
+ err = phy_read(phydev, MII_DP83822_MISR2);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int dp83822_set_wol(struct phy_device *phydev,
+ struct ethtool_wolinfo *wol)
+{
+ struct net_device *ndev = phydev->attached_dev;
+ u16 value;
+ const u8 *mac;
+
+ if (wol->wolopts & (WAKE_MAGIC | WAKE_MAGICSECURE)) {
+ mac = (const u8 *)ndev->dev_addr;
+
+ if (!is_valid_ether_addr(mac))
+ return -EINVAL;
+
+ /* MAC addresses start with byte 5, but stored in mac[0].
+ * 822 PHYs store bytes 4|5, 2|3, 0|1
+ */
+ phy_write_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_WOL_DA1, (mac[1] << 8) | mac[0]);
+ phy_write_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_WOL_DA2, (mac[3] << 8) | mac[2]);
+ phy_write_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_DA3,
+ (mac[5] << 8) | mac[4]);
+
+ value = phy_read_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_WOL_CFG);
+ if (wol->wolopts & WAKE_MAGIC)
+ value |= DP83822_WOL_MAGIC_EN;
+ else
+ value &= ~DP83822_WOL_MAGIC_EN;
+
+ if (wol->wolopts & WAKE_MAGICSECURE) {
+ phy_write_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_RXSOP1,
+ (wol->sopass[1] << 8) | wol->sopass[0]);
+ phy_write_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_RXSOP2,
+ (wol->sopass[3] << 8) | wol->sopass[2]);
+ phy_write_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_RXSOP3,
+ (wol->sopass[5] << 8) | wol->sopass[4]);
+ value |= DP83822_WOL_SECURE_ON;
+ } else {
+ value &= ~DP83822_WOL_SECURE_ON;
+ }
+
+ value |= (DP83822_WOL_EN | DP83822_WOL_INDICATION_SEL |
+ DP83822_WOL_CLR_INDICATION);
+ phy_write_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG,
+ value);
+ } else {
+ value = phy_read_mmd(phydev, DP83822_DEVADDR,
+ MII_DP83822_WOL_CFG);
+ value &= ~DP83822_WOL_EN;
+ phy_write_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG,
+ value);
+ }
+
+ return 0;
+}
+
+static void dp83822_get_wol(struct phy_device *phydev,
+ struct ethtool_wolinfo *wol)
+{
+ int value;
+ u16 sopass_val;
+
+ wol->supported = (WAKE_MAGIC | WAKE_MAGICSECURE);
+ wol->wolopts = 0;
+
+ value = phy_read_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG);
+ if (value & DP83822_WOL_MAGIC_EN)
+ wol->wolopts |= WAKE_MAGIC;
+
+ if (~value & DP83822_WOL_CLR_INDICATION)
+ wol->wolopts = 0;
+
+ if (value & DP83822_WOL_SECURE_ON) {
+ wol->wolopts |= WAKE_MAGICSECURE;
+ } else {
+ wol->wolopts &= ~WAKE_MAGICSECURE;
+ return;
+ }
+
+ sopass_val = phy_read_mmd(phydev, DP83822_DEVADDR, MII_DP83822_RXSOP1);
+ wol->sopass[0] = (sopass_val & 0xff);
+ wol->sopass[1] = (sopass_val >> 8);
+
+ sopass_val = phy_read_mmd(phydev, DP83822_DEVADDR, MII_DP83822_RXSOP2);
+ wol->sopass[2] = (sopass_val & 0xff);
+ wol->sopass[3] = (sopass_val >> 8);
+
+ sopass_val = phy_read_mmd(phydev, DP83822_DEVADDR, MII_DP83822_RXSOP3);
+ wol->sopass[4] = (sopass_val & 0xff);
+ wol->sopass[5] = (sopass_val >> 8);
+}
+
+static int dp83822_config_intr(struct phy_device *phydev)
+{
+ int misr_status;
+ int err;
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED) {
+ misr_status = phy_read(phydev, MII_DP83822_MISR1);
+ if (misr_status < 0)
+ return misr_status;
+
+ misr_status |= (DP83822_RX_ERR_HF_INT_EN |
+ DP83822_FALSE_CARRIER_HF_INT_EN |
+ DP83822_ANEG_COMPLETE_INT_EN |
+ DP83822_DUP_MODE_CHANGE_INT_EN |
+ DP83822_SPEED_CHANGED_INT_EN |
+ DP83822_LINK_STAT_INT_EN |
+ DP83822_ENERGY_DET_INT_EN |
+ DP83822_LINK_QUAL_INT_EN);
+
+ err = phy_write(phydev, MII_DP83822_MISR1, misr_status);
+ if (err < 0)
+ return err;
+
+ misr_status = phy_read(phydev, MII_DP83822_MISR2);
+ if (misr_status < 0)
+ return misr_status;
+
+ misr_status |= (DP83822_JABBER_DET_INT_EN |
+ DP83822_WOL_PKT_INT_EN |
+ DP83822_SLEEP_MODE_INT_EN |
+ DP83822_MDI_XOVER_INT_EN |
+ DP83822_LB_FIFO_INT_EN |
+ DP83822_PAGE_RX_INT_EN |
+ DP83822_ANEG_ERR_INT_EN |
+ DP83822_EEE_ERROR_CHANGE_INT_EN);
+
+ err = phy_write(phydev, MII_DP83822_MISR2, misr_status);
+ } else {
+ err = phy_write(phydev, MII_DP83822_MISR1, 0);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, MII_DP83822_MISR1, 0);
+ }
+
+ return err;
+}
+
+static int dp83822_phy_reset(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_write(phydev, MII_DP83822_RESET_CTRL, DP83822_HW_RESET);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int dp83822_suspend(struct phy_device *phydev)
+{
+ int value;
+
+ value = phy_read_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG);
+
+ if (!(value & DP83822_WOL_EN))
+ genphy_suspend(phydev);
+
+ return 0;
+}
+
+static int dp83822_resume(struct phy_device *phydev)
+{
+ int value;
+
+ genphy_resume(phydev);
+
+ value = phy_read_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG);
+
+ phy_write_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG, value |
+ DP83822_WOL_CLR_INDICATION);
+
+
+ return 0;
+}
+
+static struct phy_driver dp83822_driver[] = {
+ {
+ .phy_id = DP83822_PHY_ID,
+ .phy_id_mask = 0xfffffff0,
+ .name = "TI DP83822",
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = genphy_config_init,
+ .soft_reset = dp83822_phy_reset,
+ .get_wol = dp83822_get_wol,
+ .set_wol = dp83822_set_wol,
+ .ack_interrupt = dp83822_ack_interrupt,
+ .config_intr = dp83822_config_intr,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .suspend = dp83822_suspend,
+ .resume = dp83822_resume,
+ },
+};
+module_phy_driver(dp83822_driver);
+
+static struct mdio_device_id __maybe_unused dp83822_tbl[] = {
+ { DP83822_PHY_ID, 0xfffffff0 },
+ { },
+};
+MODULE_DEVICE_TABLE(mdio, dp83822_tbl);
+
+MODULE_DESCRIPTION("Texas Instruments DP83822 PHY driver");
+MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com");
+MODULE_LICENSE("GPL");
diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c
index 3de4fe4dda77..3966d43c5146 100644
--- a/drivers/net/phy/dp83848.c
+++ b/drivers/net/phy/dp83848.c
@@ -20,7 +20,6 @@
#define TI_DP83620_PHY_ID 0x20005ce0
#define NS_DP83848C_PHY_ID 0x20005c90
#define TLK10X_PHY_ID 0x2000a210
-#define TI_DP83822_PHY_ID 0x2000a240
/* Registers */
#define DP83848_MICR 0x11 /* MII Interrupt Control Register */
@@ -80,7 +79,6 @@ static struct mdio_device_id __maybe_unused dp83848_tbl[] = {
{ NS_DP83848C_PHY_ID, 0xfffffff0 },
{ TI_DP83620_PHY_ID, 0xfffffff0 },
{ TLK10X_PHY_ID, 0xfffffff0 },
- { TI_DP83822_PHY_ID, 0xfffffff0 },
{ }
};
MODULE_DEVICE_TABLE(mdio, dp83848_tbl);
@@ -110,7 +108,6 @@ static struct phy_driver dp83848_driver[] = {
DP83848_PHY_DRIVER(NS_DP83848C_PHY_ID, "NS DP83848C 10/100 Mbps PHY"),
DP83848_PHY_DRIVER(TI_DP83620_PHY_ID, "TI DP83620 10/100 Mbps PHY"),
DP83848_PHY_DRIVER(TLK10X_PHY_ID, "TI TLK10X 10/100 Mbps PHY"),
- DP83848_PHY_DRIVER(TI_DP83822_PHY_ID, "TI DP83822 10/100 Mbps PHY"),
};
module_phy_driver(dp83848_driver);
--
2.14.0
^ permalink raw reply related
* [PATCH v4 2/2] net: phy: at803x: Change error to EINVAL for invalid MAC
From: Dan Murphy @ 2017-10-09 16:59 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, Woojung.Huh, afd, Dan Murphy
In-Reply-To: <20171009165934.12671-1-dmurphy@ti.com>
Change the return error code to EINVAL if the MAC
address is not valid in the set_wol function.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v4 - Updated $subject to include the part number -
https://www.mail-archive.com/netdev@vger.kernel.org/msg192424.html
v3 - No changes made
v2 - There was no v1 on this patch this is new.
drivers/net/phy/at803x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index c1e52b9dc58d..5f93e6add563 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -167,7 +167,7 @@ static int at803x_set_wol(struct phy_device *phydev,
mac = (const u8 *) ndev->dev_addr;
if (!is_valid_ether_addr(mac))
- return -EFAULT;
+ return -EINVAL;
for (i = 0; i < 3; i++) {
phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
--
2.14.0
^ permalink raw reply related
* Re: [PATCH v2] netlink: do not set cb_running if dump's start() errs
From: Jason A. Donenfeld @ 2017-10-09 17:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Miller, Netdev, LKML
In-Reply-To: <1507552289.26041.52.camel@sipsolutions.net>
On Mon, Oct 9, 2017 at 2:31 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Thanks for the review. Hopefully this can make it into 4.13.6 and 4.14-rc5.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: fix a BUG in rt6_get_pcpu_route()
From: Martin KaFai Lau @ 2017-10-09 17:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ido Schimmel, netdev, davem, weiwan, mlxsw
In-Reply-To: <1507522038.31614.3.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, Oct 09, 2017 at 04:07:18AM +0000, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Ido reported following splat and provided a patch.
>
> [ 122.221814] BUG: using smp_processor_id() in preemptible [00000000] code: sshd/2672
> [ 122.221845] caller is debug_smp_processor_id+0x17/0x20
> [ 122.221866] CPU: 0 PID: 2672 Comm: sshd Not tainted 4.14.0-rc3-idosch-next-custom #639
> [ 122.221880] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
> [ 122.221893] Call Trace:
> [ 122.221919] dump_stack+0xb1/0x10c
> [ 122.221946] ? _atomic_dec_and_lock+0x124/0x124
> [ 122.221974] ? ___ratelimit+0xfe/0x240
> [ 122.222020] check_preemption_disabled+0x173/0x1b0
> [ 122.222060] debug_smp_processor_id+0x17/0x20
> [ 122.222083] ip6_pol_route+0x1482/0x24a0
> ...
>
> I believe we can simplify this code path a bit, since we no longer
> hold a read_lock and need to release it to avoid a dead lock.
>
> By disabling BH, we make sure we'll prevent code re-entry and
> rt6_get_pcpu_route()/rt6_make_pcpu_route() run on the same cpu.
Thanks for fixing it!
^ permalink raw reply
* Re: Fw: [Bug 197099] New: Kernel panic in interrupt [l2tp_ppp]
From: Guillaume Nault @ 2017-10-09 17:15 UTC (permalink / raw)
To: James Chapman; +Cc: SviMik, netdev
In-Reply-To: <CAEwTi7S3-B81bNxyWq8j4hUpXyqNnTADReYoKoGF-V4wC5OBkQ@mail.gmail.com>
On Tue, Oct 03, 2017 at 08:27:32AM +0100, James Chapman wrote:
> On 2 October 2017 at 19:35, SviMik <svimik@gmail.com> wrote:
> > Hi, James!
> >
> > No, I'm suffering from kernel panics since I started using 4.x
> > kernels.
> It's interesting that you are seeing l2tp issues since switching to
> 4.x kernels. Are you able to try earlier kernels to find the latest
> version that works? I'm curious whether things broke at v3.15.
>
> > See my current collection:
> > http://svimik.com/hdmmsk1kp1.png
> This one is another crash implicating l2tp socket shutdown, this time
> when the session pppol2tp socket is closed. Unfortunately the
> screenshot doesn't show the full oops text. I'll investigate this one
> too if you can get a full oops capture.
>
For this one too, it looks like tunnel->sock is NULL. This time, it's
l2tp_session_free() that breaks, but the root issue is probably the
same: l2tp_tunnel_destruct() removes the tunnel concurrently, most
likely because the session was created on a closing tunnel (as was
suggested by James in another message). So here too, commit
f3c66d4e144a ("l2tp: prevent creation of sessions on terminated tunnels")
might be a good start.
^ permalink raw reply
* Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.
From: Alexei Starovoitov @ 2017-10-09 17:15 UTC (permalink / raw)
To: Tim Hansen
Cc: davem, willemb, edumazet, soheil, pabeni, elena.reshetova, tom,
Jason, fw, netdev, linux-kernel, alexander.levin
In-Reply-To: <20171009153759.km3lqss7hb72wrze@debian>
On Mon, Oct 09, 2017 at 11:37:59AM -0400, Tim Hansen wrote:
> Fix BUG() calls to use BUG_ON(conditional) macros.
>
> This was found using make coccicheck M=net/core on linux next
> tag next-2017092
>
> Signed-off-by: Tim Hansen <devtimhansen@gmail.com>
> ---
> net/core/skbuff.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index d98c2e3ce2bf..34ce4c1a0f3c 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -1350,8 +1350,7 @@ struct sk_buff *skb_copy(const struct sk_buff *skb, gfp_t gfp_mask)
> /* Set the tail pointer and length */
> skb_put(n, skb->len);
>
> - if (skb_copy_bits(skb, -headerlen, n->head, headerlen + skb->len))
> - BUG();
> + BUG_ON(skb_copy_bits(skb, -headerlen, n->head, headerlen + skb->len));
I'm concerned with this change.
1. Calling non-trivial bit of code inside the macro is a poor coding style (imo)
2. BUG_ON != BUG. Some archs like mips and ppc have HAVE_ARCH_BUG_ON and implementation
of BUG and BUG_ON look quite different.
I'd prefer to keep the code as-is.
^ permalink raw reply
* Re: [patch net-next v2 0/5] mlxsw: Offload bridge device mrouter
From: David Miller @ 2017-10-09 17:18 UTC (permalink / raw)
To: jiri
Cc: netdev, yotamg, idosch, nogahf, mlxsw, ivecera, nikolay, andrew,
stephen, nbd, roopa
In-Reply-To: <20171009091535.1315-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 9 Oct 2017 11:15:30 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Yotam says:
>
> Similarly to a bridged port, the bridge device itself can be configured by
> the user to be an mrouter port. In this case, all multicast traffic should
> be forwarded to it. Make the mlxsw Spectrum driver offload these directives
> to the Spectrum hardware.
>
> Patches 1 and 2 add a new switchdev notification for bridge device mrouter
> port status and make the bridge module notify about it.
>
> Patches 3-5 change the mlxsw Spectrum driver to handle these notifications
> by adding the Spectrum router port to the bridge MDB entries.
>
> ---
> v1->v2:
> - patch1:
> - Don't add the MDB_RTR_TYPE_TEMP state and use the timer_pending to
> distinguish between learning-on and learning-off states
Series applied, thank you.
^ 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