* Re: [PATCH 2/4] net: 3com: 3c59x: Move boomerang/vortex conditional into function
From: Sebastian Andrzej Siewior @ 2018-05-04 15:22 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev, David S. Miller, tglx, Anna-Maria Gleixner
In-Reply-To: <20180504151749.6966-3-bigeasy@linutronix.de>
On 2018-05-04 17:17:47 [+0200], To netdev@vger.kernel.org wrote:
> From: Anna-Maria Gleixner <anna-maria@linutronix.de>
>
> If vp->full_bus_master_tx is set, vp->full_bus_master_rx is set as well
> (see vortex_probe1()). Therefore the conditionals for the decision if
> boomerang or vortex ISR is executed have the same result. Instead of
> repeating the explicit conditional execution of the boomerang/vortex ISR,
> move it into an own function.
>
> No functional change.
>
> Cc: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Steffen, this email address is still listed in the MAINTAINERS file for
the driver and rejects emails.
Sebastian
^ permalink raw reply
* Re: [PATCH bpf-next] bpf, xskmap: fix crash in xsk_map_alloc error path handling
From: David Miller @ 2018-05-04 15:39 UTC (permalink / raw)
To: daniel; +Cc: alexei.starovoitov, netdev, bjorn.topel
In-Reply-To: <20180504142753.10621-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 4 May 2018 16:27:53 +0200
> If bpf_map_precharge_memlock() did not fail, then we set err to zero.
> However, any subsequent failure from either alloc_percpu() or the
> bpf_map_area_alloc() will return ERR_PTR(0) which in find_and_alloc_map()
> will cause NULL pointer deref.
>
> In devmap we have the convention that we return -EINVAL on page count
> overflow, so keep the same logic here and just set err to -ENOMEM
> after successful bpf_map_precharge_memlock().
>
> Fixes: fbfc504a24f5 ("bpf: introduce new bpf AF_XDP map type BPF_MAP_TYPE_XSKMAP")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_en: optimizes get_fixed_ipv6_csum()
From: David Miller @ 2018-05-04 15:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: tariqt, saeedm, edumazet, netdev
In-Reply-To: <1a58a62c-8c5a-7c08-6d76-0030e45bda25@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 3 May 2018 19:10:29 -0700
>
>
> On 05/03/2018 06:52 PM, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 3 May 2018 17:05:06 -0700
>>
>>>
>>>
>>> On 05/02/2018 07:18 AM, Tariq Toukan wrote:
>>>>
>>>>
>>>> On 27/04/2018 1:56 AM, Saeed Mahameed wrote:
>>>
>>>>> LGTM,
>>>>>
>>>>> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
>>>>>
>>>>
>>>> Acked-by: Tariq Toukan <tariqt@mellanox.com>
>>>>
>>>> Thanks Eric.
>>>
>>> Thanks guys.
>>>
>>> I see this patch ( http://patchwork.ozlabs.org/patch/901336/ ) in
>>> a state I do not know : "Awaiting Upstream"
>>
>> THat means I expect to see this change from the upstream
>> maintainer, which in this case is Tariq.
>>
>
> I see, but it seems Tariq does not know that, otherwise he would
> not have sent an "Acked-by:"
>
> I guess this will need an extra round-trip ...
No need to extra round-trip, I applied it directly ;)
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_en: optimizes get_fixed_ipv6_csum()
From: Eric Dumazet @ 2018-05-04 16:10 UTC (permalink / raw)
To: David Miller, eric.dumazet; +Cc: tariqt, saeedm, edumazet, netdev
In-Reply-To: <20180504.115945.1508377407280334775.davem@davemloft.net>
On 05/04/2018 08:59 AM, David Miller wrote:
>
> No need to extra round-trip, I applied it directly ;)
>
Very nice, thanks David !
^ permalink raw reply
* Re: [PATCH v2 1/2] net: phy: broadcom: add support for BCM89610 PHY
From: David Miller @ 2018-05-04 16:46 UTC (permalink / raw)
To: vbhadram; +Cc: andrew, f.fainelli, netdev, linux-tegra
In-Reply-To: <1525274038-13217-1-git-send-email-vbhadram@nvidia.com>
From: Bhadram Varka <vbhadram@nvidia.com>
Date: Wed, 2 May 2018 20:43:58 +0530
> It adds support for BCM89610 (Single-Port 10/100/1000BASE-T)
> transceiver which is used in P3310 Tegra186 platform.
>
> Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] selftests: net: use TEST_PROGS_EXTENDED
From: Anders Roxell @ 2018-05-04 16:47 UTC (permalink / raw)
To: davem, shuah; +Cc: netdev, linux-kselftest, linux-kernel, Anders Roxell
When a script file that isn't generated uses the variable
TEST_GEN_PROGS_EXTENDED and a 'make -C tools/testing/selftests clean' is
performed the script file gets removed and git shows the file as
deleted. For script files that isn't generated TEST_PROGS_EXTENDED
should be used.
Fixes: 9faedd643fd9 ("selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
tools/testing/selftests/net/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 44895de1a0c4..eee47a4bc675 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -7,7 +7,7 @@ CFLAGS += -I../../../../usr/include/
TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh udpgso.sh
TEST_PROGS += udpgso_bench.sh
-TEST_GEN_PROGS_EXTENDED := in_netns.sh
+TEST_PROGS_EXTENDED := in_netns.sh
TEST_GEN_FILES = socket
TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
TEST_GEN_FILES += tcp_mmap tcp_inq
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 net-next] microchip_t1: Add driver for Microchip LAN87XX T1 PHYs
From: David Miller @ 2018-05-04 16:47 UTC (permalink / raw)
To: Nisar.Sayed; +Cc: UNGLinuxDriver, netdev
In-Reply-To: <20180502153917.6916-1-Nisar.Sayed@microchip.com>
From: Nisar Sayed <Nisar.Sayed@microchip.com>
Date: Wed, 2 May 2018 21:09:17 +0530
> Add driver for Microchip LAN87XX T1 PHYs
>
> This patch support driver for Microchp T1 PHYs.
> There will be followup patches to this driver to support T1 PHY
> features such as cable diagnostics, signal quality indicator(SQI),
> sleep and wakeup (TC10) support.
>
> Signed-off-by: Nisar Sayed <Nisar.Sayed@microchip.com>
> ---
> v0 - v1:
> * Rename microchipT1phy.c file to microchip_t1.c
> * Remove microchipT1phy.h include file
> * Add SPDX license identifier
> * Remove remove probe and remove functions
> * Update LAN87XX_INTERRUPT_MASK write as suggested
> v1 - v2:
> * Update comments with C++ style
> * Update suggestion for naming and style
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: dsa: mv88e6xxx: 88E6141/6341 SERDES support
From: David Miller @ 2018-05-04 16:49 UTC (permalink / raw)
To: marek.behun; +Cc: netdev, andrew, gregkh, vivien.didelot, arkadis
In-Reply-To: <20180503142723.26244-1-marek.behun@nic.cz>
From: Marek Behún <marek.behun@nic.cz>
Date: Thu, 3 May 2018 16:27:23 +0200
> The 88E6141/6341 switches (also known as Topaz) have 1 SGMII lane,
> which can be configured the same way as the SERDES lane on 88E6390.
>
> Signed-off-by: Marek Behun <marek.behun@nic.cz>
This patch doesn't apply cleanly to net-next, please respin.
Thank you.
^ permalink raw reply
* Re: [PATCH net] openvswitch: Don't swap table in nlattr_set() after OVS_ATTR_NESTED is found
From: David Miller @ 2018-05-04 16:51 UTC (permalink / raw)
To: sbrivio-H+wXaHxf7aLQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, sd-y1jBWg8GRStKuXlAQpz2QA,
netdev-u79uwXL29TY76Z2rM5mHXA, jesse-l0M0P4e3n4LQT0dZR+AlfA,
liuhangbin-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <44f4cc7dd6ceb5aac6045e59ff49dce70dd53e74.1525363636.git.sbrivio-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Stefano Brivio <sbrivio-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Thu, 3 May 2018 18:13:25 +0200
> If an OVS_ATTR_NESTED attribute type is found while walking
> through netlink attributes, we call nlattr_set() recursively
> passing the length table for the following nested attributes, if
> different from the current one.
>
> However, once we're done with those sub-nested attributes, we
> should continue walking through attributes using the current
> table, instead of using the one related to the sub-nested
> attributes.
>
> For example, given this sequence:
>
> 1 OVS_KEY_ATTR_PRIORITY
> 2 OVS_KEY_ATTR_TUNNEL
> 3 OVS_TUNNEL_KEY_ATTR_ID
> 4 OVS_TUNNEL_KEY_ATTR_IPV4_SRC
> 5 OVS_TUNNEL_KEY_ATTR_IPV4_DST
> 6 OVS_TUNNEL_KEY_ATTR_TTL
> 7 OVS_TUNNEL_KEY_ATTR_TP_SRC
> 8 OVS_TUNNEL_KEY_ATTR_TP_DST
> 9 OVS_KEY_ATTR_IN_PORT
> 10 OVS_KEY_ATTR_SKB_MARK
> 11 OVS_KEY_ATTR_MPLS
>
> we switch to the 'ovs_tunnel_key_lens' table on attribute #3,
> and we don't switch back to 'ovs_key_lens' while setting
> attributes #9 to #11 in the sequence. As OVS_KEY_ATTR_MPLS
> evaluates to 21, and the array size of 'ovs_tunnel_key_lens' is
> 15, we also get this kind of KASan splat while accessing the
> wrong table:
...
> Reported-by: Hangbin Liu <liuhangbin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Fixes: 982b52700482 ("openvswitch: Fix mask generation for nested attributes.")
> Signed-off-by: Stefano Brivio <sbrivio-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Sabrina Dubroca <sd-y1jBWg8GRStKuXlAQpz2QA@public.gmane.org>
Looks good, applied and queued up for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: hns3: Add support of hardware rx-vlan-offload to HNS3 VF driver
From: David Miller @ 2018-05-04 16:53 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm, linyunsheng
In-Reply-To: <20180503162811.12440-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Thu, 3 May 2018 17:28:11 +0100
> From: Yunsheng Lin <linyunsheng@huawei.com>
>
> This patch adds support of hardware rx-vlan-offload to VF driver.
> VF uses mailbox to convey PF to configure the hardware.
>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: zatm: Fix potential Spectre v1
From: David Miller @ 2018-05-04 16:54 UTC (permalink / raw)
To: gustavo; +Cc: 3chas3, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20180503181712.GA7443@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 3 May 2018 13:17:12 -0500
> pool can be indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/atm/zatm.c:1462 zatm_ioctl() warn: potential spectre issue
> 'zatm_dev->pool_info' (local cap)
>
> Fix this by sanitizing pool before using it to index
> zatm_dev->pool_info
>
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net: atm: Fix potential Spectre v1
From: David Miller @ 2018-05-04 16:54 UTC (permalink / raw)
To: gustavo; +Cc: netdev, linux-kernel
In-Reply-To: <20180503184558.GA9705@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 3 May 2018 13:45:58 -0500
> ioc_data.dev_num can be controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
> net/atm/lec.c:702 lec_vcc_attach() warn: potential spectre issue
> 'dev_lec'
>
> Fix this by sanitizing ioc_data.dev_num before using it to index
> dev_lec. Also, notice that there is another instance in which array
> dev_lec is being indexed using ioc_data.dev_num at line 705:
> lec_vcc_added(netdev_priv(dev_lec[ioc_data.dev_num]),
>
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] nsh: fix infinite loop
From: David Miller @ 2018-05-04 16:55 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, jbenc
In-Reply-To: <20180503203754.60611-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 3 May 2018 13:37:54 -0700
> syzbot caught an infinite recursion in nsh_gso_segment().
>
> Problem here is that we need to make sure the NSH header is of
> reasonable length.
...
> Fixes: c411ed854584 ("nsh: add GSO support")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Jiri Benc <jbenc@redhat.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: ethernet: sun: niu set correct packet size in skb
From: David Miller @ 2018-05-04 16:56 UTC (permalink / raw)
To: rob; +Cc: netdev
In-Reply-To: <60bfe424f5c1427633fc67443d9c538c@taglang.io>
From: Rob Taglang <rob@taglang.io>
Date: Thu, 03 May 2018 17:13:06 -0400
> Currently, skb->len and skb->data_len are set to the page size, not
> the packet size. This causes the frame check sequence to not be
> located at the "end" of the packet resulting in ethernet frame check
> errors. The driver does work currently, but stricter kernel facing
> networking solutions like OpenVSwitch will drop these packets as
> invalid.
>
> These changes set the packet size correctly so that these errors no
> longer occur. The length does not include the frame check sequence, so
> that subtraction was removed.
>
> Tested on Oracle/SUN Multithreaded 10-Gigabit Ethernet Network
> Controller [108e:abcd] and validated in wireshark.
>
> Signed-off-by: Rob Taglang <rob@taglang.io>
> ---
> drivers/net/ethernet/sun/niu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/sun/niu.c
> b/drivers/net/ethernet/sun/niu.c
> index f081de4..88c1247 100644
> --- a/drivers/net/ethernet/sun/niu.c
> +++ b/drivers/net/ethernet/sun/niu.c
> @@ -3443,7 +3443,7 @@ static int niu_process_rx_pkt(struct napi_struct
> *napi, struct niu *np,
Still corrupted. Your email client is chopping up long lines.
Please, send a test patch to yourself and make sure you can apply the
patch that arrives in that test email.
Thank you.
^ permalink raw reply
* Re: [PATCH net] tg3: Fix vunmap() BUG_ON() triggered from tg3_free_consistent().
From: David Miller @ 2018-05-04 16:57 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, siva.kallam, zumeng.chen
In-Reply-To: <1525392267-5129-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Thu, 3 May 2018 20:04:27 -0400
> tg3_free_consistent() calls dma_free_coherent() to free tp->hw_stats
> under spinlock and can trigger BUG_ON() in vunmap() because vunmap()
> may sleep. Fix it by removing the spinlock and relying on the
> TG3_FLAG_INIT_COMPLETE flag to prevent race conditions between
> tg3_get_stats64() and tg3_free_consistent(). TG3_FLAG_INIT_COMPLETE
> is always cleared under tp->lock before tg3_free_consistent()
> and therefore tg3_get_stats64() can safely access tp->hw_stats
> under tp->lock if TG3_FLAG_INIT_COMPLETE is set.
>
> Fixes: f5992b72ebe0 ("tg3: Fix race condition in tg3_get_stats64().")
> Reported-by: Zumeng Chen <zumeng.chen@gmail.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: support use of ethtool to set link speed of CN23XX-225 cards
From: David Miller @ 2018-05-04 17:00 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
weilin.chang
In-Reply-To: <20180504022325.GA1332@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Thu, 3 May 2018 19:23:25 -0700
> +static int lio_set_link_ksettings(struct net_device *netdev,
> + const struct ethtool_link_ksettings *ecmd)
> +{
> + struct lio *lio = GET_LIO(netdev);
> + struct octeon_device *oct = lio->oct_dev;
> + struct oct_link_info *linfo;
> + const int speed = ecmd->base.speed;
> + u32 is25G = 0;
Please order local variable declarations from longest to shortest line,
as was properly done in the rest of this patch.
Thank you.
^ permalink raw reply
* Re: [PATCH V3] net/netlink: make sure the headers line up actual value output
From: David Miller @ 2018-05-04 17:02 UTC (permalink / raw)
To: tsu.yubo; +Cc: xiyou.wangcong, yuzibode, netdev
In-Reply-To: <20180504030920.ztpb2axpygrszpvh@debian>
From: YU Bo <tsu.yubo@gmail.com>
Date: Thu, 3 May 2018 23:09:23 -0400
> Making sure the headers line up properly with the actual value output
> of the command
> `cat /proc/net/netlink`
>
> Before the patch:
> <sk Eth Pid Groups Rmem Wmem Dump Locks Drops Inode
> <ffff8cd2c2f7b000 0 909 00000550 0 0 0 2 0 18946
>
> After the patch:
>>sk Eth Pid Groups Rmem Wmem Dump Locks Drops Inode
>>0000000033203952 0 897 00000113 0 0 0 2 0 14906
>
> Signed-off-by: Bo YU <tsu.yubo@gmail.com>
Applied, but why did you send this V3 to the list two times?
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 01/13] net: phy: sfp: make the i2c-bus property really optional
From: Florian Fainelli @ 2018-05-04 17:03 UTC (permalink / raw)
To: Antoine Tenart, davem, kishon, linux, gregory.clement, andrew,
jason, sebastian.hesselbarth
Cc: netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
miquel.raynal, nadavh, stefanc, ymarkman, mw, linux-arm-kernel
In-Reply-To: <20180504135643.23466-2-antoine.tenart@bootlin.com>
On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> The SFF,SFP documentation is clear about making all the DT properties,
> with the exception of the compatible, optional. In practice this is not
> the case and without an i2c-bus property provided the SFP code will
> throw NULL pointer exceptions.
>
> This patch is an attempt to fix this.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> ---
> drivers/net/phy/sfp.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index 4ab6e9a50bbe..4686c443fc22 100644
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -298,11 +298,17 @@ static void sfp_set_state(struct sfp *sfp, unsigned int state)
>
> static int sfp_read(struct sfp *sfp, bool a2, u8 addr, void *buf, size_t len)
> {
> + if (!sfp->read)
> + return -EOPNOTSUPP;
-ENODEV would be closer to the intended meaning IMHO, those this could
be argue that this is yet another color to paint the bikeshed with.
> +
> return sfp->read(sfp, a2, addr, buf, len);
> }
>
> static int sfp_write(struct sfp *sfp, bool a2, u8 addr, void *buf, size_t len)
> {
> + if (!sfp->write)
> + return -EOPNOTSUPP;
> +
> return sfp->write(sfp, a2, addr, buf, len);
> }
>
> @@ -533,6 +539,8 @@ static int sfp_sm_mod_hpower(struct sfp *sfp)
> return 0;
>
> err = sfp_read(sfp, true, SFP_EXT_STATUS, &val, sizeof(val));
> + if (err == -EOPNOTSUPP)
> + goto err;
> if (err != sizeof(val)) {
> dev_err(sfp->dev, "Failed to read EEPROM: %d\n", err);
> err = -EAGAIN;
> @@ -542,6 +550,8 @@ static int sfp_sm_mod_hpower(struct sfp *sfp)
> val |= BIT(0);
>
> err = sfp_write(sfp, true, SFP_EXT_STATUS, &val, sizeof(val));
> + if (err == -EOPNOTSUPP)
> + goto err;
> if (err != sizeof(val)) {
> dev_err(sfp->dev, "Failed to write EEPROM: %d\n", err);
> err = -EAGAIN;
> @@ -565,6 +575,8 @@ static int sfp_sm_mod_probe(struct sfp *sfp)
> int ret;
>
> ret = sfp_read(sfp, false, 0, &id, sizeof(id));
> + if (ret == -EOPNOTSUPP)
> + return ret;
Can you find a way such that only sfp_sm_mod_probe() needs to check
whether the sfp read/write operations returned failure and then we just
make sure the SFP state machine does not make any more progress? Having
to check the sfp_read()/sfp_write() operations all over the place sounds
error prone and won't scale in the future.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Florian Fainelli @ 2018-05-04 17:04 UTC (permalink / raw)
To: Antoine Tenart, davem, kishon, linux, gregory.clement, andrew,
jason, sebastian.hesselbarth
Cc: netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
miquel.raynal, nadavh, stefanc, ymarkman, mw, linux-arm-kernel
In-Reply-To: <20180504135643.23466-3-antoine.tenart@bootlin.com>
On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> SFP connectors can be solder on a board without having any of their pins
> (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> and the overall link status reporting is left to other layers.
>
> In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> This mode is set when it is not possible for the SFP code to get the
> link status and as a result the link status is reported to be always UP
> from the SFP point of view.
Why represent the SFP in Device Tree then? Why not just declare this is
a fixed link which would avoid having to introduce this "unknown" state.
--
Florian
^ permalink raw reply
* Re: [PATCH 0/8] Assorted rhashtable fixes and cleanups
From: David Miller @ 2018-05-04 17:07 UTC (permalink / raw)
To: neilb; +Cc: tgraf, herbert, netdev, linux-kernel
In-Reply-To: <152540595840.18473.11298241115621799037.stgit@noble>
From: NeilBrown <neilb@suse.com>
Date: Fri, 04 May 2018 13:54:14 +1000
> This series contains some bugfixes, mostly minor though one
> is worthy of a stable backport I think - tagged with Fixes and Cc: stable.
>
> Then there are improvements to walking, which have been discussed
> to some degree already.
> Finally a code simplification which I think is correct...
Please do not mix bug fixes and features or improvements.
Please target the serious bug fixes for 'net' and then you can
target the features and improvements for 'net-next'.
This is especially important if you want a change queued up for
-stable, as the change must first go into 'net' for that to happen.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Florian Fainelli @ 2018-05-04 17:07 UTC (permalink / raw)
To: Antoine Tenart, davem, kishon, linux, gregory.clement, andrew,
jason, sebastian.hesselbarth
Cc: netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
miquel.raynal, nadavh, stefanc, ymarkman, mw, linux-arm-kernel
In-Reply-To: <20180504135643.23466-4-antoine.tenart@bootlin.com>
On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> In case no Tx disable pin is available the SFP modules will always be
> emitting. This could be an issue when using modules using laser as their
> light source as we would have no way to disable it when the fiber is
> removed. This patch adds a warning when registering an SFP cage which do
> not have its tx_disable pin wired or available.
Is this something that was done in a possibly earlier revision of a
given board design and which was finally fixed? Nothing wrong with the
patch, but this seems like a pretty serious board design mistake, that
needs to be addressed.
--
Florian
^ permalink raw reply
* Re: [PATCH] net: ethernet: sun: niu set correct packet size in skb
From: David Miller @ 2018-05-04 17:09 UTC (permalink / raw)
To: rob; +Cc: netdev
In-Reply-To: <1525453674.10031.0@server175.web-hosting.com>
From: Rob Taglang <rob@taglang.io>
Date: Fri, 04 May 2018 13:07:54 -0400
>> Still corrupted. Your email client is chopping up long lines.
>> Please, send a test patch to yourself and make sure you can apply the
>> patch that arrives in that test email.
>> Thank you.
>
> Hi David,
>
> I did go through the process of sending myself a test email before
> submitting.
>
> I can copy-paste the patch from my message on the archive:
> https://www.spinics.net/lists/netdev/msg500099.html
> and apply it successfully, so I'm not sure what you need me to do
> differently.
>
> Any help is appreciated.
Weird, let me sort this out.
^ permalink raw reply
* Re: [PATCH] net: sched: cls: fix a potential missing-check bug
From: David Miller @ 2018-05-04 17:12 UTC (permalink / raw)
To: wang6495; +Cc: kjlu, jhs, xiyou.wangcong, jiri, netdev, linux-kernel
In-Reply-To: <1525417505-19056-1-git-send-email-wang6495@umn.edu>
From: Wenwen Wang <wang6495@umn.edu>
Date: Fri, 4 May 2018 02:05:05 -0500
> Given that gen_tunnel() may return a value larger than 255 based on
> data, the new value of f->res.classid should be re-checked.
gen_tunnel() may not ever return a value larger than 255.
data->tgenerator is a u8 and therefore can never take on a value
outside of the range of 0 to 255.
I'm not applying this patch, sorry.
^ permalink raw reply
* Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Andrew Lunn @ 2018-05-04 17:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: Antoine Tenart, davem, kishon, linux, gregory.clement, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <ed267042-1a61-7fcc-13ee-3cad2c05c658@gmail.com>
On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote:
> On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> > In case no Tx disable pin is available the SFP modules will always be
> > emitting. This could be an issue when using modules using laser as their
> > light source as we would have no way to disable it when the fiber is
> > removed. This patch adds a warning when registering an SFP cage which do
> > not have its tx_disable pin wired or available.
>
> Is this something that was done in a possibly earlier revision of a
> given board design and which was finally fixed? Nothing wrong with the
> patch, but this seems like a pretty serious board design mistake, that
> needs to be addressed.
Hi Florian
Zii Devel B is like this. Only the "Signal Detect" pin is wired to a
GPIO.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Andrew Lunn @ 2018-05-04 17:17 UTC (permalink / raw)
To: Florian Fainelli
Cc: Antoine Tenart, davem, kishon, linux, gregory.clement, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <e338472c-1f26-e49b-9a2d-7942e6ed4288@gmail.com>
On Fri, May 04, 2018 at 10:04:48AM -0700, Florian Fainelli wrote:
> On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> > SFP connectors can be solder on a board without having any of their pins
> > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> > and the overall link status reporting is left to other layers.
> >
> > In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> > This mode is set when it is not possible for the SFP code to get the
> > link status and as a result the link status is reported to be always UP
> > from the SFP point of view.
>
> Why represent the SFP in Device Tree then? Why not just declare this is
> a fixed link which would avoid having to introduce this "unknown" state.
Hi Antoine
I agree with Florian here.
It LOS was missing, but i2c worked, i could see some value in using
SFP, or order to be able to read the EEPROM. But if everything is
missing, fixed-link seems a better fit.
Andrew
^ 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