* [PATCH net v2 0/5] fsl/fman: fixes for ARM
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: scott.wood, linuxppc-dev, linux-kernel, davem
The patch set fixes advertised speeds for QSGMII interfaces, disables
A007273 erratum workaround on non-PowerPC platforms where it does not
apply, enables compilation on ARM64 and addresses a probing issue on
non PPC platforms.
Changes from v1: unifying probing on all supported platforms
Igal Liberman (1):
fsl/fman: call of_platform_populate()
Madalin Bucur (4):
fsl/fman: fix 1G support for QSGMII interfaces
powerpc: remove fsl,fman from of_device_ids[]
fsl/fman: A007273 only applies to PPC SoCs
fsl/fman: enable compilation on ARM64
arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
drivers/net/ethernet/freescale/fman/fman.c | 16 ++++++++++++++++
drivers/net/ethernet/freescale/fman/mac.c | 1 +
4 files changed, 18 insertions(+), 4 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net v2 1/5] fsl/fman: fix 1G support for QSGMII interfaces
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: scott.wood, linuxppc-dev, linux-kernel, davem
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
QSGMII ports were not advertising 1G speed.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/mac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
index 69ca42c..0b31f85 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -594,6 +594,7 @@ static const u16 phy2speed[] = {
[PHY_INTERFACE_MODE_RGMII_RXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RGMII_TXID] = SPEED_1000,
[PHY_INTERFACE_MODE_RTBI] = SPEED_1000,
+ [PHY_INTERFACE_MODE_QSGMII] = SPEED_1000,
[PHY_INTERFACE_MODE_XGMII] = SPEED_10000
};
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 2/5] powerpc: remove fsl,fman from of_device_ids[]
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: scott.wood, linuxppc-dev, linux-kernel, davem
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
The fsl/fman drivers will use of_platform_populate() on all
supported platforms.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/platforms/85xx/corenet_generic.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 1179115..824b7f1 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -117,9 +117,6 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = "fsl,qe",
},
- {
- .compatible = "fsl,fman",
- },
/* The following two are for the Freescale hypervisor */
{
.name = "hypervisor",
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 3/5] fsl/fman: call of_platform_populate()
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
From: Igal Liberman <igal.liberman@freescale.com>
Call of_platform_populate() to probe the FMan sub-nodes.
Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/fman/fman.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index dafd9e1..0b7f711 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2868,6 +2868,14 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
fman->dev = &of_dev->dev;
+ /* call of_platform_populate in order to probe sub-nodes on arm64 */
+ err = of_platform_populate(fm_node, NULL, NULL, &of_dev->dev);
+ if (err) {
+ dev_err(&of_dev->dev, "%s: of_platform_populate() failed\n",
+ __func__);
+ goto fman_free;
+ }
+
return fman;
fman_node_put:
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 4/5] fsl/fman: A007273 only applies to PPC SoCs
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
---
drivers/net/ethernet/freescale/fman/fman.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 0b7f711..003b86d 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -1890,6 +1890,7 @@ static int fman_reset(struct fman *fman)
goto _return;
} else {
+#ifdef CONFIG_PPC
struct device_node *guts_node;
struct ccsr_guts __iomem *guts_regs;
u32 devdisr2, reg;
@@ -1921,6 +1922,7 @@ static int fman_reset(struct fman *fman)
/* Enable all MACs */
iowrite32be(reg, &guts_regs->devdisr2);
+#endif
/* Perform FMan reset */
iowrite32be(FPM_RSTC_FM_RESET, &fman->fpm_regs->fm_rstc);
@@ -1932,25 +1934,31 @@ static int fman_reset(struct fman *fman)
} while (((ioread32be(&fman->fpm_regs->fm_rstc)) &
FPM_RSTC_FM_RESET) && --count);
if (count == 0) {
+#ifdef CONFIG_PPC
iounmap(guts_regs);
of_node_put(guts_node);
+#endif
err = -EBUSY;
goto _return;
}
+#ifdef CONFIG_PPC
/* Restore devdisr2 value */
iowrite32be(devdisr2, &guts_regs->devdisr2);
iounmap(guts_regs);
of_node_put(guts_node);
+#endif
goto _return;
+#ifdef CONFIG_PPC
guts_regs:
of_node_put(guts_node);
guts_node:
dev_dbg(fman->dev, "%s: Didn't perform FManV3 reset due to Errata A007273!\n",
__func__);
+#endif
}
_return:
return err;
--
2.1.0
^ permalink raw reply related
* [PATCH net v2 5/5] fsl/fman: enable compilation on ARM64
From: Madalin Bucur @ 2016-12-19 9:22 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, linux-kernel, davem, scott.wood, mpe
In-Reply-To: <1482139343-8975-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
drivers/net/ethernet/freescale/fman/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fman/Kconfig b/drivers/net/ethernet/freescale/fman/Kconfig
index 79b7c84..dc0850b 100644
--- a/drivers/net/ethernet/freescale/fman/Kconfig
+++ b/drivers/net/ethernet/freescale/fman/Kconfig
@@ -1,6 +1,6 @@
config FSL_FMAN
tristate "FMan support"
- depends on FSL_SOC || COMPILE_TEST
+ depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST
select GENERIC_ALLOCATOR
select PHYLIB
default n
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
From: Pavel Machek @ 2016-12-19 10:02 UTC (permalink / raw)
To: Francois Romieu
Cc: Lino Sanfilippo, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, davem, linux-kernel, netdev
In-Reply-To: <20161218001507.GA5343@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
Hi!
> Lino, have you considered via-rhine.c since its "move work from irq to
> workqueue context" changes that started in
> 7ab87ff4c770eed71e3777936299292739fcd0fe [*] ?
>
> It's a shameless plug - originated in r8169.c - but it should be rather
> close to what the sxgbe and friends require. Thought / opinion ?
>
> [*] Including fixes/changes in:
> - 3a5a883a8a663b930908cae4abe5ec913b9b2fd2
> - e1efa87241272104d6a12c8b9fcdc4f62634d447
> - 810f19bcb862f8889b27e0c9d9eceac9593925dd
> - e45af497950a89459a0c4b13ffd91e1729fffef4
> - a926592f5e4e900f3fa903298c4619a131e60963
> - 559bcac35facfed49ab4f408e162971612dcfdf3
Considering the memory barriers... is something like this neccessary
in the via-rhine?
AFAICT... we need a barrier after making sure that descriptor is no
longer owned by DMA (to make sure we don't get stale data in rest of
descriptor)... and we need a barrier before giving the descriptor to
the dma, to make sure DMA engine sees the complete update....?
Thanks,
Pavel
diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c
index ba5c542..3806e72 100644
--- a/drivers/net/ethernet/via/via-rhine.c
+++ b/drivers/net/ethernet/via/via-rhine.c
@@ -1952,6 +1952,7 @@ static void rhine_tx(struct net_device *dev)
entry, txstatus);
if (txstatus & DescOwn)
break;
+ dma_rmb();
skb = rp->tx_skbuff[entry];
if (txstatus & 0x8000) {
netif_dbg(rp, tx_done, dev,
@@ -2061,6 +2062,7 @@ static int rhine_rx(struct net_device *dev, int limit)
if (desc_status & DescOwn)
break;
+ dma_rmb();
netif_dbg(rp, rx_status, dev, "%s() status %08x\n", __func__,
desc_status);
@@ -2146,6 +2148,7 @@ static int rhine_rx(struct net_device *dev, int limit)
u64_stats_update_end(&rp->rx_stats.syncp);
}
give_descriptor_to_nic:
+ dma_wmb();
desc->rx_status = cpu_to_le32(DescOwn);
entry = (++rp->cur_rx) % RX_RING_SIZE;
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Linux support for 802.1AS-Rev.
From: Praveen Bajantri @ 2016-12-19 10:20 UTC (permalink / raw)
To: netdev
Hello everyone,
I am new to Linux networking and had doubt related to support for
802.1AS-Rev. Please point me to appropriate forum/mailing list If this
is not a right place.
I know that Linux supports gPTP (802.1AS), As there are new clauses
added to gPTP to support new features such as one step time stamping,
I just wanted to know the Linux support for 802.1AS-Rev.
Does Linux support 802.1AS-Rev ? Is there any application which can be
used to test this feature ?
Thanks,
Praveen Bajantri
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Joao Pinto @ 2016-12-19 10:55 UTC (permalink / raw)
To: Pavel Machek, Joao Pinto
Cc: Niklas Cassel, Giuseppe CAVALLARO, Florian Fainelli,
Andy Shevchenko, David Miller, larper, rabinv, netdev,
CARLOS.PALMINHA, Jie.Deng1, Stephen Warren
In-Reply-To: <20161217173824.GB20231@amd>
Hi Pavel,
Às 5:38 PM de 12/17/2016, Pavel Machek escreveu:
> Hi!
>
>>>> So if there is a long time before handling interrupts,
>>>> I guess that it makes sense that one stream could
>>>> get an advantage in the net scheduler.
>>>>
>>>> If I find the time, and if no one beats me to it, I will try to replace
>>>> the normal timers with HR timers + a smaller default timeout.
>>>>
>>>
>>> Can you try something like this? Highres timers will be needed, too,
>>> but this fixes the logic problem.
>>>
>>> You'll need to apply it twice as code is copy&pasted.
>>>
>>> Best regards,
>>> Pavel
>>>
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>
>>> */
>>> priv->tx_count_frames += nfrags + 1;
>>> if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
>>> - mod_timer(&priv->txtimer,
>>> - STMMAC_COAL_TIMER(priv->tx_coal_timer));
>>> + if (priv->tx_count_frames == nfrags + 1)
>>> + mod_timer(&priv->txtimer,
>>> + STMMAC_COAL_TIMER(priv->tx_coal_timer));
>>> } else {
>>> priv->tx_count_frames = 0;
>>> priv->hw->desc->set_tx_ic(desc);
>>>
>>>
>>
>> I know that this is completely of topic, but I am facing a dificulty with
>> stmmac. I have interrupts, mac well configured rx packets being received
>> successfully, but TX is not working, resulting in Tx errors = Total TX packets.
>> I have made a lot of debug and my conclusions is that by some reason when using
>> stmmac after starting tx dma, the hw state machine enters a deadend state
>> resulting in those errors. Anyone faced this trouble?
>
> SMP or UP system? AFAICT the driver gets the memory barriers wrong. It
> does not fail completely for me, but still fails rather quickly.
I was able to put my setup receiving and transmiting packets. The problem is
that because my hw controller supports multi-queues, I had to enable the TX
queue 0 in order for it to work.
Now I am facing a new problem. My DUT with stmmac does not answer to ARP
messages. When I execute a "ping" the other machine in the nework executes a ARP
message asking "who is the owner of IP XXXX" which my DUT does not reply. I used
wireshark and the ARP messages are reaching the DUT machine, but for some reason
it does not reply. Did you ever face this problem when using stmmac?
When using my internal driver, it works perfectly, so some detail in the stmmac
I suppose.
Tahnks.
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3e40578..641b03d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2121,11 +2205,11 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
> if (mss_desc)
> priv->hw->desc->set_tx_owner(mss_desc);
>
> - /* The own bit must be the latest setting done when prepare the
> + /* The own bit must be the latest setting done when preparing the
> * descriptor and then barrier is needed to make sure that
> * all is coherent before granting the DMA engine.
> */
> - smp_wmb();
> + wmb();
>
> if (netif_msg_pktdata(priv)) {
> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
> @@ -2336,9 +2401,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>
> /* The own bit must be the latest setting done when prepare the
> * descriptor and then barrier is needed to make sure that
> - * all is coherent before granting the DMA engine.
> + * all is coherent before granting access to the DMA engine.
> */
> - smp_wmb();
> + wmb();
> }
>
> netdev_sent_queue(dev, skb->len);
>
> Plus I'd suggest... at least (hand-edited). Driver should really be
> modified to use readl() when accessing memory that changes.
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3e40578..641b03d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1309,6 +1323,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
> status = priv->hw->desc->tx_status(&priv->dev->stats,
> &priv->xstats, p,
> priv->ioaddr);
> + rmb();
> +
> /* Check if the descriptor is owned by the DMA */
> if (unlikely(status & tx_dma_own))
> break;
>
> Pavel
>
^ permalink raw reply
* Re: Synopsys Ethernet QoS
From: Joao Pinto @ 2016-12-19 11:01 UTC (permalink / raw)
To: Pavel Machek, Joao Pinto
Cc: Niklas Cassel, Giuseppe CAVALLARO, Florian Fainelli,
Andy Shevchenko, David Miller, larper, rabinv, netdev,
CARLOS.PALMINHA, Jie.Deng1, Stephen Warren
In-Reply-To: <3c70d3c0-d312-054f-6e8c-54035c63573e@synopsys.com>
Às 10:55 AM de 12/19/2016, Joao Pinto escreveu:
>
> Hi Pavel,
>
> Às 5:38 PM de 12/17/2016, Pavel Machek escreveu:
>> Hi!
>>
>>>>> So if there is a long time before handling interrupts,
>>>>> I guess that it makes sense that one stream could
>>>>> get an advantage in the net scheduler.
>>>>>
>>>>> If I find the time, and if no one beats me to it, I will try to replace
>>>>> the normal timers with HR timers + a smaller default timeout.
>>>>>
>>>>
>>>> Can you try something like this? Highres timers will be needed, too,
>>>> but this fixes the logic problem.
>>>>
>>>> You'll need to apply it twice as code is copy&pasted.
>>>>
>>>> Best regards,
>>>> Pavel
>>>>
>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>>>
>>>> */
>>>> priv->tx_count_frames += nfrags + 1;
>>>> if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
>>>> - mod_timer(&priv->txtimer,
>>>> - STMMAC_COAL_TIMER(priv->tx_coal_timer));
>>>> + if (priv->tx_count_frames == nfrags + 1)
>>>> + mod_timer(&priv->txtimer,
>>>> + STMMAC_COAL_TIMER(priv->tx_coal_timer));
>>>> } else {
>>>> priv->tx_count_frames = 0;
>>>> priv->hw->desc->set_tx_ic(desc);
>>>>
>>>>
>>>
>>> I know that this is completely of topic, but I am facing a dificulty with
>>> stmmac. I have interrupts, mac well configured rx packets being received
>>> successfully, but TX is not working, resulting in Tx errors = Total TX packets.
>>> I have made a lot of debug and my conclusions is that by some reason when using
>>> stmmac after starting tx dma, the hw state machine enters a deadend state
>>> resulting in those errors. Anyone faced this trouble?
>>
>> SMP or UP system? AFAICT the driver gets the memory barriers wrong. It
>> does not fail completely for me, but still fails rather quickly.
>
> I was able to put my setup receiving and transmiting packets. The problem is
> that because my hw controller supports multi-queues, I had to enable the TX
> queue 0 in order for it to work.
>
> Now I am facing a new problem. My DUT with stmmac does not answer to ARP
> messages. When I execute a "ping" the other machine in the nework executes a ARP
> message asking "who is the owner of IP XXXX" which my DUT does not reply. I used
> wireshark and the ARP messages are reaching the DUT machine, but for some reason
> it does not reply. Did you ever face this problem when using stmmac?
>
> When using my internal driver, it works perfectly, so some detail in the stmmac
> I suppose.
>
> Tahnks.
Forgot to say that I am using a PC with SMP and a PCI link to the controller.
Thanks.
>
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 3e40578..641b03d 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -2121,11 +2205,11 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
>> if (mss_desc)
>> priv->hw->desc->set_tx_owner(mss_desc);
>>
>> - /* The own bit must be the latest setting done when prepare the
>> + /* The own bit must be the latest setting done when preparing the
>> * descriptor and then barrier is needed to make sure that
>> * all is coherent before granting the DMA engine.
>> */
>> - smp_wmb();
>> + wmb();
>>
>> if (netif_msg_pktdata(priv)) {
>> pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
>> @@ -2336,9 +2401,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>>
>> /* The own bit must be the latest setting done when prepare the
>> * descriptor and then barrier is needed to make sure that
>> - * all is coherent before granting the DMA engine.
>> + * all is coherent before granting access to the DMA engine.
>> */
>> - smp_wmb();
>> + wmb();
>> }
>>
>> netdev_sent_queue(dev, skb->len);
>>
>> Plus I'd suggest... at least (hand-edited). Driver should really be
>> modified to use readl() when accessing memory that changes.
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 3e40578..641b03d 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -1309,6 +1323,8 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
>> status = priv->hw->desc->tx_status(&priv->dev->stats,
>> &priv->xstats, p,
>> priv->ioaddr);
>> + rmb();
>> +
>> /* Check if the descriptor is owned by the DMA */
>> if (unlikely(status & tx_dma_own))
>> break;
>>
>> Pavel
>>
>
^ permalink raw reply
* Re: [PATCH] af_unix: fix garbage collect vs. MSG_PEEK
From: Miklos Szeredi @ 2016-12-19 11:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, lkml, Hannes Frederic Sowa, Nikolay Borisov
In-Reply-To: <20161003.215103.2267442887041931968.davem@davemloft.net>
On Tue, Oct 4, 2016 at 3:51 AM, David Miller <davem@davemloft.net> wrote:
> From: Miklos Szeredi <mszeredi@redhat.com>
> Date: Thu, 29 Sep 2016 14:09:14 +0200
>
>> @@ -1550,6 +1550,17 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb)
>> return max_level;
>> }
>>
>> +static void unix_peek_fds(struct scm_cookie *scm, struct sk_buff *skb)
>> +{
>> + scm->fp = scm_fp_dup(UNIXCB(skb).fp);
>> + /*
>> + * During garbage collection it is assumed that in-flight sockets don't
>> + * get a new external reference. So we need to wait until current run
>> + * finishes.
>> + */
>> + unix_gc_barrier();
>> +}
> ...
>> @@ -266,6 +266,11 @@ void wait_for_unix_gc(void)
>> wait_event(unix_gc_wait, gc_in_progress == false);
>> }
>>
>> +void unix_gc_barrier(void)
>> +{
>> + spin_unlock_wait(&unix_gc_lock);
>> +}
>
> Can you explain why wait_for_unix_gc() isn't appropriate? I'm a little
> bit uncomfortable with a spinlock wait like this, and would rather see
> something like the existing helper used.
Missed this mail, sorry for the late reply...
AFAICS wait_for_unix_gc() lacks a barrier that the spin lock provides.
The ordering needs to be strictly:
A: duplicate file pointers
B: garbage collect
Also wait_for_unix_gc() is an overkill since the complete garbage
collect (including purging the trash) will take longer than the
collection stage, which we need to have ordering with. This probably
doesn't matter much in practice.
Thanks,
Miklos
^ permalink raw reply
* Re: [PATCH v8 3/8] thunderbolt: Communication with the ICM (firmware)
From: Mika Westerberg @ 2016-12-19 12:24 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Amir Levy, gregkh, andreas.noever, bhelgaas, corbet, linux-kernel,
linux-pci, netdev, linux-doc, mario_limonciello,
thunderbolt-linux, tomas.winkler, xiong.y.zhang
In-Reply-To: <fe0f0a6f-488b-bbc0-8987-a9c47d9ed9b9@kernel.org>
On Thu, Dec 01, 2016 at 05:21:01PM -0800, Andy Lutomirski wrote:
> On 09/28/2016 07:44 AM, Amir Levy wrote:
> > This patch provides the communication protocol between the
> > Intel Connection Manager(ICM) firmware that is operational in the
> > Thunderbolt controller in non-Apple hardware.
> > The ICM firmware-based controller is used for establishing and maintaining
> > the Thunderbolt Networking connection - we need to be able to communicate
> > with it.
>
> I'm a bit late to the party, but here goes. I have two big questions:
>
> 1. Why is this using netlink at all? A system has zero or more Thunderbolt
> controllers, they're probed just like any other PCI devices (by nhi_probe()
> if I'm understanding correctly), they'll have nodes in sysfs, etc.
> Shouldn't there be a simple char device per Thunderbolt controller that a
> daemon can connect to? This will clean up lots of things:
>
> a) You can actually enforce one-daemon-at-a-time in a very natural way. Your
> current code seems to try, but it's rather buggy. Your subscription count
> is a guess, your unsubscribe is entirely unchecked, and you are entirely
> unable to detect if a daemon crashes AFAICT.
>
> b) You won't need all of the complexity that's currently there to figure out
> *which* Thunderbolt device a daemon is talking to.
>
> c) You can use regular ioctl passing *structs* instead of netlink attrs.
> There's nothing wrong with netlink attrs, except that your driver seems to
> have a whole lot of boilerplate that just converts back and forth to regular
> structures.
>
> d) The userspace code that does stuff like "send message, wait 150ms,
> receive reply, complain if no reply" goes away because ioctl is synchronous.
> (Or you can use read and write, but it's still simpler.)
>
> e) You could have one daemon per Thunderbolt device if you were so inclined.
>
> f) You get privilege separation in userspace. Creating a netlink socket and
> dropping privilege is busted^Winteresting. Opening a device node and
> dropping privilege works quite nicely.
I agree with your points. Using a char device here instead seems to be
the right way to go forward.
There is small problem, though. On non-Apple systems the host controller
only appears when something is connected to thunderbolt ports. So the
char device would not be there all the time. However, I think we can
still notify the userspace by sending an extra uevent when we detect
there is a PCIe device or inter-domain connection plugged in.
> 2. Why do you need a daemon anyway. Functionally, what exactly does it do?
> (Okay, I get that it seems to talk to a giant pile of code running in SMM,
> and I get that Intel, for some bizarre reason, wants everyone except Apple
> to use this code in SMM, and that Apple (for entirely understandable
> reasons) turned it off, but that's beside the point. What does the user code
> do that's useful and that the kernel can't do all by itself? The only
> really interesting bit I can see is the part that approves PCI devices.
As far as I can tell it is used to notify user (via dbus, I guess) that
there is a new PCIe device or inter-domain connection (networking)
available and it needs to be approved before it can be used.
I don't think anything prevents the kernel to do all this (Amir, Michael
can correct me if I'm mistaken).
In fact we could provide a simple "tbtadm" tool, built on top of the
char device that can be used to list and approve devices from shell
command line. That could also allow user to turn on "auto-approve" mode
or similar where the kernel approves all connected devices automatically
(if such functionality is wanted).
The daemon can still be useful for listening uevents generated by the
driver and forwarding approval requests to user.
> I'm not going to review this in detail, but here's a tiny bit:
>
> > +static int nhi_genl_unsubscribe(__always_unused struct sk_buff *u_skb,
> > + __always_unused struct genl_info *info)
> > +{
> > + atomic_dec_if_positive(&subscribers);
> > +
> > + return 0;
> > +}
> > +
>
> This, for example, is really quite buggy.
OK.
> This entire function here:
>
> > +static int nhi_genl_query_information(__always_unused struct sk_buff *u_skb,
> > + struct genl_info *info)
> > +{
> > + struct tbt_nhi_ctxt *nhi_ctxt;
> > + struct sk_buff *skb;
> > + bool msg_too_long;
> > + int res = -ENODEV;
> > + u32 *msg_head;
> > +
> > + if (!info || !info->userhdr)
> > + return -EINVAL;
> > +
> > + skb = genlmsg_new(NLMSG_ALIGN(nhi_genl_family.hdrsize) +
> > + nla_total_size(sizeof(DRV_VERSION)) +
> > + nla_total_size(sizeof(nhi_ctxt->nvm_ver_offset)) +
> > + nla_total_size(sizeof(nhi_ctxt->num_ports)) +
> > + nla_total_size(sizeof(nhi_ctxt->dma_port)) +
> > + nla_total_size(0), /* nhi_ctxt->support_full_e2e */
> > + GFP_KERNEL);
> > + if (!skb)
> > + return -ENOMEM;
> > +
> > + msg_head = genlmsg_put_reply(skb, info, &nhi_genl_family, 0,
> > + NHI_CMD_QUERY_INFORMATION);
> > + if (!msg_head) {
> > + res = -ENOMEM;
> > + goto genl_put_reply_failure;
> > + }
> > +
> > + if (mutex_lock_interruptible(&controllers_list_mutex)) {
> > + res = -ERESTART;
> > + goto genl_put_reply_failure;
> > + }
> > +
> > + nhi_ctxt = nhi_search_ctxt(*(u32 *)info->userhdr);
> > + if (nhi_ctxt && !nhi_ctxt->d0_exit) {
> > + *msg_head = nhi_ctxt->id;
> > +
> > + msg_too_long = !!nla_put_string(skb, NHI_ATTR_DRV_VERSION,
> > + DRV_VERSION);
> > +
> > + msg_too_long = msg_too_long ||
> > + nla_put_u16(skb, NHI_ATTR_NVM_VER_OFFSET,
> > + nhi_ctxt->nvm_ver_offset);
> > +
> > + msg_too_long = msg_too_long ||
> > + nla_put_u8(skb, NHI_ATTR_NUM_PORTS,
> > + nhi_ctxt->num_ports);
> > +
> > + msg_too_long = msg_too_long ||
> > + nla_put_u8(skb, NHI_ATTR_DMA_PORT,
> > + nhi_ctxt->dma_port);
> > +
> > + if (msg_too_long) {
> > + res = -EMSGSIZE;
> > + goto release_ctl_list_lock;
> > + }
> > +
> > + if (nhi_ctxt->support_full_e2e &&
> > + nla_put_flag(skb, NHI_ATTR_SUPPORT_FULL_E2E)) {
> > + res = -EMSGSIZE;
> > + goto release_ctl_list_lock;
> > + }
> > + mutex_unlock(&controllers_list_mutex);
> > +
> > + genlmsg_end(skb, msg_head);
> > +
> > + return genlmsg_reply(skb, info);
> > + }
> > +
> > +release_ctl_list_lock:
> > + mutex_unlock(&controllers_list_mutex);
> > + genlmsg_cancel(skb, msg_head);
> > +
> > +genl_put_reply_failure:
> > + nlmsg_free(skb);
> > +
> > + return res;
> > +}
>
> would be about three lines of code if you used copy_to_user and a struct.
Understood.
Thanks Andy for your comments.
We will rework the driver to take your suggestions into account and
expose a char device instead of using netlink.
Meanwhile we will continue in the github to add new features and support
the new Thunderbolt HW generation.
^ permalink raw reply
* Re: [PATCH net 2/2] sctp: not copying duplicate addrs to the assoc's bind address list
From: Neil Horman @ 2016-12-19 12:35 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, Marcelo Ricardo Leitner,
Vlad Yasevich, Daniel Borkmann
In-Reply-To: <CADvbK_fH-Va3t4EfTktH-pRV-ht-W0N0SW_pBh90mHj8ZW+kYA@mail.gmail.com>
On Sat, Dec 17, 2016 at 05:56:51PM +0800, Xin Long wrote:
> On Wed, Aug 24, 2016 at 6:38 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Wed, Aug 24, 2016 at 01:14:27PM +0800, Xin Long wrote:
> >> >> > Ah, I see what you're doing. Ok, this makes some sense, at least on the receive
> >> >> > side, when you get a cookie unpacked and modify the remote peers address list,
> >> >> > it makes sense to check for duplicates. On the local side however, I would,
> >> >> > instead of checking it when the list gets copied, I'd check it when the master
> >> >> > list gets updated (in the NETDEV_UP event notifier for the local address list,
> >> >>
> >> >> I was thinking about to check it in the NETDEV_UP, yes it can make the
> >> >> master list has no duplicated addresses. But what if two same addresses
> >> >> events come, and they come from different NICs (though I can't point out
> >> >> the valid use case), then we filter there.
> >> >>
> >> > That I think would be a bug in the protocol code. For the ipv4 case, all
> >> > addresses are owned by the system and the same addresses added to multiple
> >> > interfaces should not be allowed. The same is true of ipv6 case. The only
> >> > exception there is a link local address and that should still be unique within
> >> > the context of an address/dev tuple.
> >> >
> >> understand, just sounds a little harsh. :-)
> >>
> >> For now, does it make sense to you to just leave as the master list
> >> is, and check
> >> the duplicate address when sctp is really binding them ?
> >>
> > I would think so, yes.
>
> Hi, Neil,
>
> About this patch, I think we are on the page, right ?
>
Yes, I think we are.
Neil
> If yes, I will repost v2, but other than improving some changelog,
> no other change compare to v1. Do you agree ?
>
^ permalink raw reply
* Re: "rfkill: Add rfkill-any LED trigger" causes deadlock
From: Michał Kępień @ 2016-12-19 14:01 UTC (permalink / raw)
To: Johannes Berg
Cc: Михаил Кринкин,
linux-wireless, davem, netdev
In-Reply-To: <1482137772.31461.1.camel@sipsolutions.net>
Mike, Johannes, sorry for the trouble caused.
> Thanks for the report. I'm sorry I missed this in review - obviously we
> can't call something that acquires the mutex from rfkill_set_sw_state()
> which clearly states, in the documentation:
>
> * This function can be called in any context, even from within rfkill
> * callbacks.
Drat, I missed that, sorry.
> I've reverted the change (and the follow-up fix) now.
Just to ensure things get cleaned up properly, as of now it looks like
you only reverted patch 2/2 of my v2 and Arnd's fix to patch 1/2, not
patch 1/2 itself.
> Michał, if you want to resubmit with this fixed, please also make sure
> you don't reintroduce the unused label warning and have the appropriate
> #ifdef that Arnd had later added for your change.
Noted, thanks. I will post v3 once I figure out how to handle locking
properly.
--
Best regards,
Michał Kępień
^ permalink raw reply
* RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF
From: David Laight @ 2016-12-19 14:14 UTC (permalink / raw)
To: 'George Spelvin', tom@herbertland.com
Cc: ak@linux.intel.com, davem@davemloft.net, djb@cr.yp.to,
ebiggers3@gmail.com, hannes@stressinduktion.org, Jason@zx2c4.com,
jeanphilippe.aumasson@gmail.com,
kernel-hardening@lists.openwall.com, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, luto@amacapital.net,
netdev@vger.kernel.org, torvalds@linux-foundation.org,
tytso@mit.edu, vegard.nossum@gmail.com
In-Reply-To: <20161217152122.19677.qmail@ns.sciencehorizons.net>
From: George Spelvin
> Sent: 17 December 2016 15:21
...
> uint32_t
> hsiphash24(char const *in, size_t len, uint32_t const key[2])
> {
> uint32_t c = key[0];
> uint32_t d = key[1];
> uint32_t a = 0x6c796765 ^ 0x736f6d65;
> uint32_t b = d ^ 0x74656462 ^ 0x646f7261;
I've not looked closely, but is that (in some sense) duplicating
the key length?
So you could set a = key[2] and b = key[3] and still have an
working hash - albeit not exactly the one specified.
I'll add another comment here...
Is it worth using the 32bit hash for IP addresses on 64bit systems that
can't do misaligned accessed?
David
^ permalink raw reply
* [PATCH 0/4] Add support for the ethernet switch on the EXPRESSObin
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
linux-arm-kernel
This set of patches adds support for the Marvell ethernet switch 88E6341.
It also add the devicetree definition of thid switch to the DT board.
Romain Perier (4):
net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address
0x1
net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >=
num_of_ports
net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
arm64: dts: marvell: Add ethernet switch definition for the
EXPRESSObin
.../boot/dts/marvell/armada-3720-espressobin.dts | 67 ++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/chip.c | 24 ++++----
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 4 +-
3 files changed, 84 insertions(+), 11 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
linux-arm-kernel
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>
The Marvell 88E6341 device is single-chip, 6-port ethernet switch with
four integrated 10/100/1000Mbps ethernet transceivers and one high speed
SerDes interfaces. It is compatible with switches of family 88E6352.
This commit adds basic support for this switch by describing its
capabilities to the driver.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 14 ++++++++++++++
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 4 +++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 76d944e..72ba24b 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4086,6 +4086,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.ops = &mv88e6321_ops,
},
+ [MV88E6341] = {
+ .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
+ .family = MV88E6XXX_FAMILY_6352,
+ .name = "Marvell 88E6341",
+ .num_databases = 4096,
+ .num_ports = 6,
+ .port_base_addr = 0x10,
+ .global1_addr = 0x1b,
+ .age_time_coeff = 15000,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
+ .flags = MV88E6XXX_FLAGS_FAMILY_6352,
+ .ops = &mv88e6352_ops,
+ },
+
[MV88E6350] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
.family = MV88E6XXX_FAMILY_6351,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index af54bae..176d6c4 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -86,6 +86,7 @@
#define PORT_SWITCH_ID_PROD_NUM_6097 0x099
#define PORT_SWITCH_ID_PROD_NUM_6131 0x106
#define PORT_SWITCH_ID_PROD_NUM_6320 0x115
+#define PORT_SWITCH_ID_PROD_NUM_6341 0x340
#define PORT_SWITCH_ID_PROD_NUM_6123 0x121
#define PORT_SWITCH_ID_PROD_NUM_6161 0x161
#define PORT_SWITCH_ID_PROD_NUM_6165 0x165
@@ -432,6 +433,7 @@ enum mv88e6xxx_model {
MV88E6290,
MV88E6320,
MV88E6321,
+ MV88E6341,
MV88E6350,
MV88E6351,
MV88E6352,
@@ -448,7 +450,7 @@ enum mv88e6xxx_family {
MV88E6XXX_FAMILY_6185, /* 6108 6121 6122 6131 6152 6155 6182 6185 */
MV88E6XXX_FAMILY_6320, /* 6320 6321 */
MV88E6XXX_FAMILY_6351, /* 6171 6175 6350 6351 */
- MV88E6XXX_FAMILY_6352, /* 6172 6176 6240 6352 */
+ MV88E6XXX_FAMILY_6352, /* 6172 6176 6240 6341 6352 */
MV88E6XXX_FAMILY_6390, /* 6190 6190X 6191 6290 6390 6390X */
};
--
2.9.3
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
linux-arm-kernel
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>
This defines and enables the Marvell ethernet switch MVE886341 on the
Marvell EXPRESSObin board.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
.../boot/dts/marvell/armada-3720-espressobin.dts | 67 ++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 83178d9..8ba6c0b 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -80,3 +80,70 @@
&usb3 {
status = "okay";
};
+
+&mdio {
+ switch0: switch0@0 {
+ compatible = "marvell,mv88e6085";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <ð0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "wan";
+ phy-handle = <&switch0phy0>;
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan0";
+ phy-handle = <&switch0phy1>;
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan1";
+ phy-handle = <&switch0phy2>;
+ };
+
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ switch0phy0: switch0phy0@0 {
+ reg = <0x11>;
+ };
+ switch0phy1: switch0phy1@1 {
+ reg = <0x12>;
+ };
+ switch0phy2: switch0phy2@2 {
+ reg = <0x13>;
+ };
+ };
+ };
+};
+
+ð0 {
+ phy-mode = "rgmii-id";
+ status = "okay";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: netdev, devicetree, Rob Herring, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala, linux-arm-kernel, Thomas Petazzoni,
Nadav Haklai, Romain Perier
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>
Some Marvell ethernet switches have internal ethernet transceivers with
hardcoded phy addresses. These addresses can be grearer than the number
of ports or its value might be different than the associated port number.
This is for example the case for MV88E6341 that has 6 ports and internal
Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.
This commits fixes the issue by removing the condition in MDIO callbacks.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b5f0e1e..76d944e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2881,9 +2881,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
u16 val;
int err;
- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_read(chip, phy, reg, &val);
mutex_unlock(&chip->reg_lock);
@@ -2896,9 +2893,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
struct mv88e6xxx_chip *chip = bus->priv;
int err;
- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_write(chip, phy, reg, val);
mutex_unlock(&chip->reg_lock);
--
2.9.3
^ permalink raw reply related
* [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement
Cc: netdev, devicetree, Rob Herring, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala, linux-arm-kernel, Thomas Petazzoni,
Nadav Haklai, Romain Perier
In-Reply-To: <20161219141610.30934-1-romain.perier@free-electrons.com>
Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
zero of sw_addr is 0x1. However, on some platforms, ethernet switches
are configured in Multi chip addressing mode and available at MDIO
address 0x1.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f7222dc..b5f0e1e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4240,10 +4240,6 @@ static void mv88e6xxx_phy_destroy(struct mv88e6xxx_chip *chip)
static int mv88e6xxx_smi_init(struct mv88e6xxx_chip *chip,
struct mii_bus *bus, int sw_addr)
{
- /* ADDR[0] pin is unavailable externally and considered zero */
- if (sw_addr & 0x1)
- return -EINVAL;
-
if (sw_addr == 0)
chip->smi_ops = &mv88e6xxx_smi_single_chip_ops;
else if (mv88e6xxx_has(chip, MV88E6XXX_FLAGS_MULTI_CHIP))
--
2.9.3
^ permalink raw reply related
* Re: [RFC PATCH net-next] virtio_net: Support UDP Tunnel offloads.
From: Vlad Yasevich @ 2016-12-19 14:26 UTC (permalink / raw)
To: Or Gerlitz, Jarno Rajahalme
Cc: Linux Netdev List, james.zhangming,
Michael S. Tsirkin <mst@redhat.com> (mst@redhat.com), ailan
In-Reply-To: <CAJ3xEMh79catGjC4p7EsCqix_fmUgbcDtaz-1OUnR2xFpNq99g@mail.gmail.com>
On 12/15/2016 02:07 AM, Or Gerlitz wrote:
> On Fri, Nov 18, 2016 at 1:01 AM, Jarno Rajahalme <jarno@ovn.org> wrote:
>> This patch is a proof-of-concept I did a few months ago for UDP tunnel
>> offload support in virtio_net interface [..]
>
> What's the use case you were considering for a guest running a UDP based VTEP?
Two cases that I've been aware of are nested virt or simply a guest acting
as router/bridge with possible different tunnel devices.
-vlad
>
>> Real implementation needs to extend the virtio_net header rather than
>> piggy-backing on existing fields. Inner MAC length (or inner network
>> offset) also needs to be passed as a new field. Control plane (QEMU)
>> also needs to be updated.
>>
>> All testing was done using Geneve, but this should work for all UDP
>> tunnels the same.
^ permalink raw reply
* Re: [PATCH net v2] ipvlan: fix crash when master is set in loopback mode
From: Eric Dumazet @ 2016-12-19 14:37 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: netdev, Eric Dumazet, David Miller, Mahesh Bandewar
In-Reply-To: <1482087625-30366-1-git-send-email-mahesh@bandewar.net>
On Sun, 2016-12-18 at 11:00 -0800, Mahesh Bandewar wrote:
> From: Mahesh Bandewar <maheshb@google.com>
>
> In an IPvlan setup when master is set in loopback mode e.g.
>
> ethtool -K eth0 set loopback on
>
> where eth0 is master device for IPvlan setup.
>
> The failure actually happens while processing mulitcast packets
> but that's a result of unconditionally queueing packets without
> ensuring ether-header is part of the linear part of skb.
>
> This patch forces this check at the reception and drops packets
> which fail this check before queuing them.
>
> ------------[ cut here ]------------
> kernel BUG at include/linux/skbuff.h:1737!
> Call Trace:
> [<ffffffff921fbbc2>] dev_forward_skb+0x92/0xd0
> [<ffffffffc031ac65>] ipvlan_process_multicast+0x395/0x4c0 [ipvlan]
> [<ffffffffc031a9a7>] ? ipvlan_process_multicast+0xd7/0x4c0 [ipvlan]
> [<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
> [<ffffffff91cdff09>] process_one_work+0x1a9/0x660
> [<ffffffff91cdfea7>] ? process_one_work+0x147/0x660
> [<ffffffff91ce086d>] worker_thread+0x11d/0x360
> [<ffffffff91ce0750>] ? rescuer_thread+0x350/0x350
> [<ffffffff91ce960b>] kthread+0xdb/0xe0
> [<ffffffff91c05c70>] ? _raw_spin_unlock_irq+0x30/0x50
> [<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
> [<ffffffff92348b7a>] ret_from_fork+0x9a/0xd0
> [<ffffffff91ce9530>] ? flush_kthread_worker+0xc0/0xc0
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> ---
> v1->v2: commit log update
>
> drivers/net/ipvlan/ipvlan_core.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
> index b4e990743e1d..4294fc1f5564 100644
> --- a/drivers/net/ipvlan/ipvlan_core.c
> +++ b/drivers/net/ipvlan/ipvlan_core.c
> @@ -660,6 +660,9 @@ rx_handler_result_t ipvlan_handle_frame(struct sk_buff **pskb)
> if (!port)
> return RX_HANDLER_PASS;
>
> + if (unlikely(!pskb_may_pull(skb, sizeof(struct ethhdr))))
> + goto out;
> +
> switch (port->mode) {
> case IPVLAN_MODE_L2:
> return ipvlan_handle_mode_l2(pskb, port);
> @@ -672,6 +675,8 @@ rx_handler_result_t ipvlan_handle_frame(struct sk_buff **pskb)
> /* Should not reach here */
> WARN_ONCE(true, "ipvlan_handle_frame() called for mode = [%hx]\n",
> port->mode);
> +
> +out:
> kfree_skb(skb);
> return RX_HANDLER_CONSUMED;
> }
There is something funky here.
When rx_handler() is called, we must have pulled Ethernet header
already.
Is this because RX_HANDLER_ANOTHER is returned in some cases, while it
should not ?
It looks like you added a pskb_may_pull() at a wrong place. Sure it
might fix the crash, but it looks weird here.
^ permalink raw reply
* Re: [PATCH 1/4] net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address 0x1
From: Andrew Lunn @ 2016-12-19 14:38 UTC (permalink / raw)
To: Romain Perier, Volodymyr Bendiuga
Cc: Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement, netdev, devicetree,
Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel, Thomas Petazzoni, Nadav Haklai
In-Reply-To: <20161219141610.30934-2-romain.perier@free-electrons.com>
On Mon, Dec 19, 2016 at 03:16:06PM +0100, Romain Perier wrote:
> Currently, the function mv88e6xxx_smi_init() returns -EINVAL if the bit
> zero of sw_addr is 0x1. However, on some platforms, ethernet switches
> are configured in Multi chip addressing mode and available at MDIO
> address 0x1.
Hi Romain
What branch is this against? net-next?
Please see:
https://www.spinics.net/lists/netdev/msg409156.html
It would be nicer to use Volodymyr, since it has been reviewed.
Volodymyr, what happened to your version 2? Did David accept it?
Andrew
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: marvell: Add ethernet switch definition for the EXPRESSObin
From: Andrew Lunn @ 2016-12-19 14:44 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Rutland, devicetree, Florian Fainelli, Jason Cooper,
Pawel Moll, Vivien Didelot, netdev, Ian Campbell, Nadav Haklai,
Rob Herring, Kumar Gala, Gregory Clement, Thomas Petazzoni,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161219141610.30934-5-romain.perier@free-electrons.com>
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + switch0phy0: switch0phy0@0 {
> + reg = <0x11>;
Since the reg is 0x11, this should be called switch0phy0@11. Please
follow the same scheme for the other phys.
Andrew
^ permalink raw reply
* Re: [PATCH 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Andrew Lunn @ 2016-12-19 14:52 UTC (permalink / raw)
To: Romain Perier
Cc: Vivien Didelot, Florian Fainelli, Jason Cooper,
Sebastian Hesselbarth, Gregory Clement, netdev, devicetree,
Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel, Thomas Petazzoni, Nadav Haklai
In-Reply-To: <20161219141610.30934-4-romain.perier@free-electrons.com>
Hi Romain
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 76d944e..72ba24b 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -4086,6 +4086,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
> .ops = &mv88e6321_ops,
> },
>
> + [MV88E6341] = {
> + .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
> + .family = MV88E6XXX_FAMILY_6352,
> + .name = "Marvell 88E6341",
> + .num_databases = 4096,
> + .num_ports = 6,
> + .port_base_addr = 0x10,
> + .global1_addr = 0x1b,
> + .age_time_coeff = 15000,
> + .tag_protocol = DSA_TAG_PROTO_EDSA,
> + .flags = MV88E6XXX_FLAGS_FAMILY_6352,
> + .ops = &mv88e6352_ops,
Even if it i 100% compatible with the 6532, you should still add an
ops structure for it. All chips have their own, even when the are
exactly the same as other in the family.
> --- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
> +++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
> @@ -86,6 +86,7 @@
> #define PORT_SWITCH_ID_PROD_NUM_6097 0x099
> #define PORT_SWITCH_ID_PROD_NUM_6131 0x106
> #define PORT_SWITCH_ID_PROD_NUM_6320 0x115
> +#define PORT_SWITCH_ID_PROD_NUM_6341 0x340
> #define PORT_SWITCH_ID_PROD_NUM_6123 0x121
> #define PORT_SWITCH_ID_PROD_NUM_6161 0x161
Ah, err..
These should be in numerical order of the macro.
PORT_SWITCH_ID_PROD_NUM_6320 is however in the wrong place. Please
put the 6341 after the 6321.
Thanks
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