* 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
* [PATCH 1/2] net: nixge: Fix error path for obtaining mac address
From: Moritz Fischer @ 2018-05-04 17:18 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem, alex.williams, Moritz Fischer
Fix issue where nixge_get_nvmem_address() returns a non-NULL
return value on a failed nvmem_cell_get() that causes an invalid
access when error value encoded in pointer is dereferenced.
Furthermore ensure that buffer allocated by nvmem_cell_read()
actually gets kfreed() if the function succeeds.
Fixes commit 492caffa8a1a ("net: ethernet: nixge: Add support for
National Instruments XGE netdev")
Reported-by: Alex Williams <alex.williams@ni.com>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
drivers/net/ethernet/ni/nixge.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
index 27364b7572fc..c41fea9253e3 100644
--- a/drivers/net/ethernet/ni/nixge.c
+++ b/drivers/net/ethernet/ni/nixge.c
@@ -1170,7 +1170,7 @@ static void *nixge_get_nvmem_address(struct device *dev)
cell = nvmem_cell_get(dev, "address");
if (IS_ERR(cell))
- return cell;
+ return NULL;
mac = nvmem_cell_read(cell, &cell_size);
nvmem_cell_put(cell);
@@ -1202,10 +1202,12 @@ static int nixge_probe(struct platform_device *pdev)
ndev->max_mtu = NIXGE_JUMBO_MTU;
mac_addr = nixge_get_nvmem_address(&pdev->dev);
- if (mac_addr && is_valid_ether_addr(mac_addr))
+ if (mac_addr && is_valid_ether_addr(mac_addr)) {
ether_addr_copy(ndev->dev_addr, mac_addr);
- else
+ kfree(mac_addr);
+ } else {
eth_hw_addr_random(ndev);
+ }
priv = netdev_priv(ndev);
priv->ndev = ndev;
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] net: nixge: Address compiler warnings about signedness
From: Moritz Fischer @ 2018-05-04 17:18 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem, alex.williams, Moritz Fischer
In-Reply-To: <20180504171834.9365-1-mdf@kernel.org>
Fixes the following warnings:
warning: pointer targets in passing argument 1 of
‘is_valid_ether_addr’ differ in signedness [-Wpointer-sign]
if (mac_addr && is_valid_ether_addr(mac_addr)) {
^~~~~~~~
expected ‘const u8 * {aka const unsigned char *}’ but argument
is of type ‘const char *’
static inline bool is_valid_ether_addr(const u8 *addr)
^~~~~~~~~~~~~~~~~~~
warning: pointer targets in passing argument 2 of
‘ether_addr_copy’ differ in signedness [-Wpointer-sign]
ether_addr_copy(ndev->dev_addr, mac_addr);
^~~~~~~~
expected ‘const u8 * {aka const unsigned char *}’ but argument
is of type ‘const char *’
static inline void ether_addr_copy(u8 *dst, const u8 *src)
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
drivers/net/ethernet/ni/nixge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
index c41fea9253e3..b092894dd128 100644
--- a/drivers/net/ethernet/ni/nixge.c
+++ b/drivers/net/ethernet/ni/nixge.c
@@ -1183,7 +1183,7 @@ static int nixge_probe(struct platform_device *pdev)
struct nixge_priv *priv;
struct net_device *ndev;
struct resource *dmares;
- const char *mac_addr;
+ const u8 *mac_addr;
int err;
ndev = alloc_etherdev(sizeof(*priv));
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next v2 01/13] net: phy: sfp: make the i2c-bus property really optional
From: Antoine Tenart @ 2018-05-04 17:19 UTC (permalink / raw)
To: Florian Fainelli
Cc: Antoine Tenart, davem, kishon, linux, gregory.clement, andrew,
jason, sebastian.hesselbarth, netdev, linux-kernel,
thomas.petazzoni, maxime.chevallier, miquel.raynal, nadavh,
stefanc, ymarkman, mw, linux-arm-kernel
In-Reply-To: <fd91699d-c290-8821-b4a6-0789071cfba1@gmail.com>
Hi Florian,
On Fri, May 04, 2018 at 10:03:16AM -0700, Florian Fainelli wrote:
> On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> >
> > 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.
I thought about -ENODEV as well, but ended up choosing -EOPNOTSUPP for
some reason. But I'm really fine with both solutions, it really depends
on if we want to return a callback isn't available from a s/w point of
view (-EOPNOTSUPP) or a h/w point of view (-ENODEV).
> > 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.
I tried doing this in this way (only having logic in the probe
function), but that wasn't as simple as this solution and it seemed
quite invasive as these read/write calls can be called from a few
functions but many code paths (as it's a state machine). So I choose the
easiest solution to maintain in the long run, as each future state
machine update could impact this.
Thanks!
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] net: ethernet: sun: niu set correct packet size in skb
From: David Miller @ 2018-05-04 17:22 UTC (permalink / raw)
To: rob; +Cc: netdev
In-Reply-To: <20180504.130950.1760681294731661849.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 04 May 2018 13:09:50 -0400 (EDT)
> 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.
I ended up fixing it up by hand. I have no idea why the copy that showed
up on spinics looks completely different to what I received directly in
my inbox and what showed up on patchwork.ozlabs.org
Anyways, applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Antoine Tenart @ 2018-05-04 17:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: Antoine Tenart, davem, kishon, linux, gregory.clement, andrew,
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>
Hi Florian,
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.
The other solution would have been to represent this as a fixed-link.
But such a representation would report the link as being up all the
time, which is something we wanted to avoid as the GoP in PPv2 can
report some link status. This is achieved using SFP+phylink+PPv2.
And representing the SFP cage in the device tree, although it's a
"dummy" one, helps describing the hardware.
Thanks!
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v3 net-next] net: dsa: mv88e6xxx: 88E6141/6341 SERDES support
From: Marek Behún @ 2018-05-04 17:26 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, Marek Behún
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>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 ++
drivers/net/dsa/mv88e6xxx/serdes.c | 20 ++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/serdes.h | 3 +++
3 files changed, 25 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 9d62e4acc01b..e7e079b1888c 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2529,6 +2529,7 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.reset = mv88e6185_g1_reset,
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
+ .serdes_power = mv88e6341_serdes_power,
};
static const struct mv88e6xxx_ops mv88e6095_ops = {
@@ -2848,6 +2849,7 @@ static const struct mv88e6xxx_ops mv88e6175_ops = {
.reset = mv88e6352_g1_reset,
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
+ .serdes_power = mv88e6341_serdes_power,
};
static const struct mv88e6xxx_ops mv88e6176_ops = {
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index fb058fd35c0d..3a185ea1bf20 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -326,3 +326,23 @@ int mv88e6390_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
return 0;
}
+
+int mv88e6341_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
+{
+ int err;
+ u8 cmode;
+
+ if (port != 5)
+ return 0;
+
+ err = mv88e6xxx_port_get_cmode(chip, port, &cmode);
+ if (err)
+ return err;
+
+ if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ cmode == MV88E6XXX_PORT_STS_CMODE_SGMII ||
+ cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
+ return mv88e6390_serdes_sgmii(chip, MV88E6341_ADDR_SERDES, on);
+
+ return 0;
+}
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.h b/drivers/net/dsa/mv88e6xxx/serdes.h
index 1897c01c6e19..b6e5fbd46b5e 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.h
+++ b/drivers/net/dsa/mv88e6xxx/serdes.h
@@ -19,6 +19,8 @@
#define MV88E6352_ADDR_SERDES 0x0f
#define MV88E6352_SERDES_PAGE_FIBER 0x01
+#define MV88E6341_ADDR_SERDES 0x15
+
#define MV88E6390_PORT9_LANE0 0x09
#define MV88E6390_PORT9_LANE1 0x12
#define MV88E6390_PORT9_LANE2 0x13
@@ -42,6 +44,7 @@
#define MV88E6390_SGMII_CONTROL_LOOPBACK BIT(14)
#define MV88E6390_SGMII_CONTROL_PDOWN BIT(11)
+int mv88e6341_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
int mv88e6390_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
int mv88e6352_serdes_get_sset_count(struct mv88e6xxx_chip *chip, int port);
--
2.16.1
^ permalink raw reply related
* Re: [PATCH net-next v2] net: core: rework basic flow dissection helper
From: David Miller @ 2018-05-04 17:26 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet, jasowang
In-Reply-To: <e87a05fed35c9cb8e60fe8f867c43b27b3044e21.1525426286.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Fri, 4 May 2018 11:32:59 +0200
> When the core networking needs to detect the transport offset in a given
> packet and parse it explicitly, a full-blown flow_keys struct is used for
> storage.
> This patch introduces a smaller keys store, rework the basic flow dissect
> helper to use it, and apply this new helper where possible - namely in
> skb_probe_transport_header(). The used flow dissector data structures
> are renamed to match more closely the new role.
>
> The above gives ~50% performance improvement in micro benchmarking around
> skb_probe_transport_header() and ~30% around eth_get_headlen(), mostly due
> to the smaller memset. Small, but measurable improvement is measured also
> in macro benchmarking.
>
> v1 -> v2: use the new helper in eth_get_headlen() and skb_get_poff(),
> as per DaveM suggestion
>
> Suggested-by: David Miller <davem@davemloft.net>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Awesome. Applied, thanks Paolo.
^ permalink raw reply
* Re: [PATCH v2 2/4] net: hook socketpair() into LSM
From: David Miller @ 2018-05-04 17:31 UTC (permalink / raw)
To: dh.herrmann
Cc: linux-kernel, jmorris, paul, teg, sds, selinux,
linux-security-module, eparis, serge, casey, netdev
In-Reply-To: <20180504142822.15233-3-dh.herrmann@gmail.com>
From: David Herrmann <dh.herrmann@gmail.com>
Date: Fri, 4 May 2018 16:28:20 +0200
> Use the newly created LSM-hook for socketpair(). The default hook
> return-value is 0, so behavior stays the same unless LSMs start using
> this hook.
>
> Acked-by: Serge Hallyn <serge@hallyn.com>
> Signed-off-by: Tom Gundersen <teg@jklm.no>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net] net: phy: sfp: fix the BR,min computation
From: David Miller @ 2018-05-04 17:31 UTC (permalink / raw)
To: antoine.tenart
Cc: linux, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180504151054.17525-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 4 May 2018 17:10:54 +0200
> In an SFP EEPROM values can be read to get information about a given SFP
> module. One of those is the bitrate, which can be determined using a
> nominal bitrate in addition with min and max values (in %). The SFP code
> currently compute both BR,min and BR,max values thanks to this nominal
> and min,max values.
>
> This patch fixes the BR,min computation as the min value should be
> subtracted to the nominal one, not added.
>
> Fixes: 9962acf7fb8c ("sfp: add support for 1000Base-PX and 1000Base-BX10")
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Charity Gift !!!
From: Mrs Mavis L. Wanczyk @ 2018-05-03 16:23 UTC (permalink / raw)
--
This is the second time i am sending you this mail.
I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details
for claims.
I await your earliest response and God Bless you
Good luck.
Mavis Wanczyk
^ 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