* Re: [PATCH net-next v5 1/2] flow dissector: ICMP support
From: Jiri Pirko @ 2016-12-07 12:26 UTC (permalink / raw)
To: Simon Horman; +Cc: Jiri Pirko, Tom Herbert, David Miller, netdev
In-Reply-To: <1481112880-9801-2-git-send-email-simon.horman@netronome.com>
Wed, Dec 07, 2016 at 01:14:39PM CET, simon.horman@netronome.com wrote:
>Allow dissection of ICMP(V6) type and code. This should only occur
>if a packet is ICMP(V6) and the dissector has FLOW_DISSECTOR_KEY_ICMP set.
>
>There are currently no users of FLOW_DISSECTOR_KEY_ICMP.
>A follow-up patch will allow FLOW_DISSECTOR_KEY_ICMP to be used by
>the flower classifier.
You are missing signedoff line.
^ permalink raw reply
* [RFC] Re: Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.
From: Pavel Machek @ 2016-12-07 12:31 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: Giuseppe CAVALLARO, alexandre.torgue, David Miller, netdev,
linux-kernel
In-Reply-To: <trinity-11729d3e-ae5e-4850-a1bf-b83a1d0a864c-1480687521037@3capp-gmx-bs55>
[-- Attachment #1: Type: text/plain, Size: 4485 bytes --]
On Fri 2016-12-02 15:05:21, Lino Sanfilippo wrote:
> Hi,
>
>
> >
> > There's nothing that protect stmmac_poll() from running concurently
> > with stmmac_dma_interrupt(), right?
> >
>
> could it be that there is also another issue concerned locking?:
> The tx completion handler takes the xmit_lock in case that the
> netif_queue is stopped. This is AFAICS unnecessary, since both
> xmit and completion handler are already synchronized by the private
> tx lock. But it is IMHO also dangerous:
>
> In the xmit handler we have the locking order
> 1. xmit_lock
> 2. private tx lock
>
> while in the completion handler its the reverse:
>
> 1. private tx lock
> 2. xmit lock.
>
> Do I miss something?
No, it seems you are right. Something like this?
Hmm. And can priv->tx_lock be removed, as we already rely on
netif_tx_lock?
(I copied the "lock already held" annotations from forcedeth. I hope
they are right....)
Best regards,
Pavel
commit a6f21255dfc11fcadc5062dfd0c5f3d77ca4f634
Author: Pavel <pavel@ucw.cz>
Date: Wed Dec 7 13:29:15 2016 +0100
Reported-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
The tx completion handler takes the xmit_lock in case that the
netif_queue is stopped. This is AFAICS unnecessary, since both
xmit and completion handler are already synchronized by the private
tx lock. But it is IMHO also dangerous:
In the xmit handler we have the locking order
1. xmit_lock
2. private tx lock
while in the completion handler its the reverse:
1. private tx lock
2. xmit lock.
Signed-off-by: Pavel Machek <pavel@denx.de>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 982c952..5df9bb3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1380,14 +1380,9 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
if (unlikely(netif_queue_stopped(priv->dev) &&
stmmac_tx_avail(priv) > STMMAC_TX_THRESH)) {
- netif_tx_lock(priv->dev);
- if (netif_queue_stopped(priv->dev) &&
- stmmac_tx_avail(priv) > STMMAC_TX_THRESH) {
- netif_dbg(priv, tx_done, priv->dev,
- "%s: restart transmit\n", __func__);
- netif_wake_queue(priv->dev);
- }
- netif_tx_unlock(priv->dev);
+ netif_dbg(priv, tx_done, priv->dev,
+ "%s: restart transmit\n", __func__);
+ netif_wake_queue(priv->dev);
}
if ((priv->eee_enabled) && (!priv->tx_path_in_lpi_mode)) {
@@ -1630,7 +1625,9 @@ static void stmmac_tx_timer(unsigned long data)
{
struct stmmac_priv *priv = (struct stmmac_priv *)data;
+ netif_tx_lock_bh(priv->dev);
stmmac_tx_clean(priv);
+ netif_tx_unlock_bh(priv->dev);
}
/**
@@ -1994,7 +1991,8 @@ static void stmmac_tso_allocator(struct stmmac_priv *priv, unsigned int des,
* --------
*
* mss is fixed when enable tso, so w/o programming the TDES3 ctx field.
- */
+ *
+ * Called with netif_tx_lock held. */
static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
{
u32 pay_len, mss;
@@ -2174,6 +2172,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
* Description : this is the tx entry point of the driver.
* It programs the chain or the ring and supports oversized frames
* and SG feature.
+ * Called with netif_tx_lock held.
*/
static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
{
@@ -2684,7 +2683,9 @@ static int stmmac_poll(struct napi_struct *napi, int budget)
int work_done = 0;
priv->xstats.napi_poll++;
+ netif_tx_lock_bh(priv->dev);
stmmac_tx_clean(priv);
+ netif_tx_unlock_bh(priv->dev);
work_done = stmmac_rx(priv, budget);
if (work_done < budget) {
@@ -2701,6 +2702,7 @@ static int stmmac_poll(struct napi_struct *napi, int budget)
* complete within a reasonable time. The driver will mark the error in the
* netdev structure and arrange for the device to be reset to a sane state
* in order to transmit a new packet.
+ * Called with netif_tx_lock held.
*/
static void stmmac_tx_timeout(struct net_device *dev)
{
--
(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
* Re: [PATCH] net: axienet: Utilize of_get_mac_address()
From: Tobias Klauser @ 2016-12-07 12:31 UTC (permalink / raw)
To: netdev; +Cc: michal.simek, soren.brinkmann, Florian Fainelli
In-Reply-To: <20161207122529.29508-1-tklauser@distanz.ch>
On 2016-12-07 at 13:25:28 +0100, Tobias Klauser <tklauser@distanz.ch> wrote:
> Do not open code getting the MAC address exclusively from the
> "local-mac-address" property, but instead use of_get_mac_address()
> which looks up the MAC address using the 3 typical property names.
>
> Also avoid casting away the const qualifier of the return value by
> making axienet_set_mac_address() take a const void* address.
>
> Follows commit b34296a9c047 ("net: ethoc: Utilize
> of_get_mac_address()").
>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Sorry for the duplicate, please disregard this patch.
^ permalink raw reply
* Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code
From: Daniele Palmas @ 2016-12-07 12:32 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Oliver Neukum, linux-usb, netdev
In-Reply-To: <CAGRyCJHjre7BByjcHt2XC5AH=Ta0jHGiPYAt=gDy71t=2PqOmw@mail.gmail.com>
2016-12-05 14:04 GMT+01:00 Daniele Palmas <dnlplm@gmail.com>:
> Hi,
>
> 2016-12-05 11:10 GMT+01:00 Bjørn Mork <bjorn@mork.no>:
>> Daniele Palmas <dnlplm@gmail.com> writes:
>>
>>> I went back to this and further checking revealed that MBIM function
>>> reset is not needed and the only problem is related to commit
>>> 48906f62c96cc2cd35753e59310cb70eb08cc6a5 cdc_ncm: toggle altsetting to
>>> force reset before setup, that, however, is mandatory for some Huawei
>>> modems.
>>
>> Interesting. That does sound like an odd firmware bug to me. I have a
>> bit of a hard time understanding how this can be. Using data interface
>> altsetting 0 to reset the function is documented in the NCM spec:
>>
>
> Agree, this is likely a firmware bug and it is also proved by all the
> other modems that accept the procedure without issues.
>
>> "
>> 7.2 Using Alternate Settings to Reset an NCM Function
>>
>> To place the network aspects of a function in a known state, the host
>> shall:
>> • select alternate setting 0 of the NCM Data Interface (this is the
>> setting with no endpoints). This can be done explicitly using
>> SetInterface, or implicitly using SetConfiguration. See [USB30] for
>> details.
>> • select the NCM operational parameters by sending commands to the NCM
>> Communication Interface, then
>> • select the second alternate interface setting of the NCM Data
>> Interface (this is the setting with a bulk IN endpoint and a bulk
>> OUT endpoint).
>>
>> Whenever alternate setting 0 is selected by the host, the function
>> shall:
>> • flush function buffers
>> • reset the packet filter to its default state
>> • clear all multicast address filters
>> • clear all power filters set using
>> SetEthernetPowerManagementPatternFilter
>> • reset statistics counters to zero
>> • restore its Ethernet address to its default state
>> • reset its IN NTB size to the value given by field dwNtbInMaxSize
>> from the NTB Parameter Struc- ture
>> • reset the NTB format to NTB-16
>> • reset the current Maximum Datagram Size to a function-specific
>> default. If SetMaxDatagramSize is not supported, then the maximum
>> datagram size shall be the same as the value in wMaxSegmentSize of
>> the Ethernet Networking Functional Descriptor. If SetMaxDatagramSize
>> is supported by the function, then the host must either query the
>> function to determine the current effective maximum datagram size,
>> or must explicitly set the maximum datagram size. If the host wishes
>> to set the Maximum Datagram Size, it may do so prior to selecting
>> the second alternate interface set- ting of the data
>> interface. Doing so will ensure that the change takes effect prior
>> to send or receiving data.
>> • reset CRC mode so that the function will not append CRCs to
>> datagrams sent on the IN pipe
>> • reset NTB sequence numbers to zero
>>
>> When the host selects the second alternate interface setting of the
>> NCM Data Interface, the function shall perform the following actions
>> in the following order.
>> • If connected to the network, the function shall send a
>> ConnectionSpeedChange notification to the host indicating the
>> current connection speed.
>> • Whether connected or not, the function shall then send a
>> NetworkConnection notification to the host, with wValue indicating
>> the current state of network connectivity
>> "
>>
>> The addition of the "RESET" request in MBIM did not change these
>> requirements AFAICS. Supporting NCM style "altsetting 0 reset" is
>> required by default inheritance. The description of dual NCM/MBIM
>> functions in the MBIM spec further emphasizes this:
>>
>> "
>> Regardless of the previous sequence of SET_INTERFACE commands targeting
>> the Communication Interface, the host is able to put the function into
>> a defined state by the following sequence:
>>
>> 1. SET_INTERFACE(Data Interface, 0)
>> 2. SET_INTERFACE(Communication Interface, desired alternate setting)
>> 3. Sending the required class commands for the targeted alternate
>> setting
>> 4. SET_INTERFACE(Data Interface, 1 if Communication Interface,0 and
>> Data Interface,2 Communication Interface 1)
>> "
>>
>>
>> This, along with the lack of *any* sort of discussion of the
>> relation/interfaction between "MBIM RESET" and "data interface
>> altsetting 0" makes the MBIM RESET control request either ambigious or
>> redundant. Or both...
>>
>> FWIW, I've always considered RESET a symptom of the sloppy MBIM spec
>> development. It did not exactly work to their advantage that the first
>> (and only?) published errata simply was an excuse to add new features
>> (the "MBIM extended functional descriptor" and "MBIM loopback testmode")
>> without updating the revision number. Causing even more confusion,
>> since we now have two different MBIMv1.0 specs.
>>
>> Well, whatever. No need to get all frustrated about that. We have to
>> deal with whatever the firmware developers serve us. And,
>> unfortunately, it is not surprising that unclear and ambigious specs
>> leads to incompatible firmware implementations.
>>
>> I wonder, what happens if you unload the MBIM driver and let the USB
>> core reset the data interface to altsetting 0? Will the device then
>> fail when the driver is loaded again? If not, then where is the
>> difference? And can we possibly reorder the driver set_interface
>> requests to make them similar to the USB core reset
>>
>
> I will check this.
>
I verified that the behavior does not change and data connection still
does not work, so I'm going to submit the new patch.
Regards,
Daniele
> Thanks,
> Daniele
>
>> Until now, I was under the impression that this was the
>> only documented way to reset both NCM and MBIM functions (since the
>> RESET is MBIM specific),
>>
>>> My proposal is to add something like
>>> CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk to avoid the toggle.
>>>
>>> To have a conservative approach, I would add only Telit LE922 to this
>>> quirk and keep also the usleep_range delay, since I do not have a
>>> clear view on all the VIDs/PIDs affected by this quirk. Then other
>>> modems, once tested, can be added to the quirk if the delay is not
>>> enough.
>>>
>>> If this approach, though ugly, has chances to be accepted I can write
>>> a new patch.
>>
>> Yes, that sounds like the best approach at the moment. I have
>> unfortunately not as much time to experiment with this as I seem to
>> need. And the EM7455 workaround (the delay) is a bit hard to verify,
>> since it is easily affected by small additional delays caused by the
>> debugging itself. This can cause bogus test results.
>>
>>
>> Bjørn
^ permalink raw reply
* Re: [PATCH] igmp: Make igmp group member RFC 3376 compliant
From: Michal Tesar @ 2016-12-07 12:38 UTC (permalink / raw)
To: David Miller; +Cc: haliu, kuznet, jmorris, kaber, netdev
In-Reply-To: <20161116.111943.1827868712701090468.davem@davemloft.net>
On Wed, Nov 16, 2016 at 11:19:43AM -0500, David Miller wrote:
> From: Hangbin Liu <haliu@redhat.com>
> Date: Wed, 16 Nov 2016 14:20:45 +0800
>
> > Hi David,
> >
> > On Tue, Nov 08, 2016 at 10:26:25AM +0100, Michal Tesar wrote:
> >> On Mon, Nov 07, 2016 at 08:13:45PM -0500, David Miller wrote:
> >>
> >> > From: Michal Tesar <mtesar@redhat.com>
> >> > Date: Thu, 3 Nov 2016 10:38:34 +0100
> >> >
> >> > > 2. If the received Query is a General Query, the interface timer is
> >> > > used to schedule a response to the General Query after the
> >> > > selected delay. Any previously pending response to a General
> >> > > Query is canceled.
> >> > > --8<--
> >> > >
> >> > > Currently the timer is rearmed with new random expiration time for
> >> > > every incoming query regardless of possibly already pending report.
> >> > > Which is not aligned with the above RFE.
> >> >
> >> > I don't read it that way. #2 says if this is a general query then any
> >> > pending response to a general query is cancelled. And that's
> >> > effectively what the code is doing right now.
> >>
> >> Hi David,
> >> I think that it is important to notice that the RFC says also
> >> that only the first matching rule is applied.
> >>
> >> "
> >> When new Query with the Router-Alert option arrives on an
> >> interface, provided the system has state to report, a delay for a
> >> response is randomly selected in the range (0, [Max Resp Time]) where
> >> Max Resp Time is derived from Max Resp Code in the received Query
> >> message. The following rules are then used to determine if a Report
> >> needs to be scheduled and the type of Report to schedule. The rules
> >> are considered in order and only the first matching rule is applied.
> >
> > ^^
> >
> > Would you like to reconsider about this? I also agree with Michal that we
> > need to choose the sooner timer. Or if we receive query very quickly, we
> > will keep refresh the timer and may never reply the report.
>
> I'm still thinking about this, please be patient, I review a hundred
> patches or more per day so it takes me time to get to tasks that
> require deep thinking or real consideration on any level.
Hi Dave,
would it be possible to have another look at this patch and reconsider
its behavior? I really believe that current code does not behave
correctly.
Best regards Michal Tesar
^ permalink raw reply
* [RESEND PATCH 1/3] bindings: net: stmmac: correct note about TSO
From: Niklas Cassel @ 2016-12-07 12:41 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, David S. Miller, Giuseppe CAVALLARO,
Alexandre TORGUE, Phil Reid, Eric Engestrom, Niklas Cassel
Cc: netdev, devicetree, linux-kernel
From: Niklas Cassel <niklas.cassel@axis.com>
snps,tso was previously placed under AXI BUS Mode parameters,
suggesting that the property should be in the stmmac-axi-config node.
TSO (TCP Segmentation Offloading) has nothing to do with AXI BUS Mode
parameters, and the parser actually expects it to be in the root node,
not in the stmmac-axi-config.
Also added a note about snps,tso only being available on GMAC4 and newer.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index 41b49e6075f5..b95ff998ba73 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -1,7 +1,7 @@
* STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
Required properties:
-- compatible: Should be "snps,dwmac-<ip_version>" "snps,dwmac"
+- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
For backwards compatibility: "st,spear600-gmac" is also supported.
- reg: Address and length of the register set for the device
- interrupt-parent: Should be the phandle for the interrupt controller
@@ -50,6 +50,8 @@ Optional properties:
- snps,ps-speed: port selection speed that can be passed to the core when
PCS is supported. For example, this is used in case of SGMII
and MAC2MAC connection.
+- snps,tso: this enables the TSO feature otherwise it will be managed by
+ MAC HW capability register. Only for GMAC4 and newer.
- AXI BUS Mode parameters: below the list of all the parameters to program the
AXI register inside the DMA module:
- snps,lpi_en: enable Low Power Interface
@@ -62,8 +64,6 @@ Optional properties:
- snps,fb: fixed-burst
- snps,mb: mixed-burst
- snps,rb: rebuild INCRx Burst
- - snps,tso: this enables the TSO feature otherwise it will be managed by
- MAC HW capability register.
- mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
Examples:
--
2.1.4
^ permalink raw reply related
* [RESEND PATCH 3/3] net: stmmac: stmmac_platform: use correct setup function for gmac4
From: Niklas Cassel @ 2016-12-07 12:41 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue; +Cc: Niklas Cassel, netdev, linux-kernel
In-Reply-To: <1481114469-4788-1-git-send-email-niklass@axis.com>
From: Niklas Cassel <niklas.cassel@axis.com>
devicetree binding for stmmac states:
- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
For backwards compatibility: "st,spear600-gmac" is also supported.
Previously, when specifying "snps,dwmac-4.10a", "snps,dwmac" as your
compatible string, plat_stmmacenet_data would have both has_gmac and
has_gmac4 set.
This would lead to stmmac_hw_init calling dwmac1000_setup rather than
dwmac4_setup, resulting in a non-functional driver.
This happened since the check for has_gmac is done before the check for
has_gmac4. However, the order should not matter, so it does not make sense
to have both set.
If something is valid for both, you should do as the stmmac_interrupt does:
if (priv->plat->has_gmac || priv->plat->has_gmac4) ...
The places where it was obvious that the author actually meant
if (has_gmac || has_gmac4) rather than if (has_gmac) has been updated.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 4 ++--
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index d5a8122b6033..dd5b38e4cd1f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -263,7 +263,7 @@ static void stmmac_ethtool_getdrvinfo(struct net_device *dev,
{
struct stmmac_priv *priv = netdev_priv(dev);
- if (priv->plat->has_gmac)
+ if (priv->plat->has_gmac || priv->plat->has_gmac4)
strlcpy(info->driver, GMAC_ETHTOOL_NAME, sizeof(info->driver));
else
strlcpy(info->driver, MAC100_ETHTOOL_NAME,
@@ -448,7 +448,7 @@ static void stmmac_ethtool_gregs(struct net_device *dev,
memset(reg_space, 0x0, REG_SPACE_SIZE);
- if (!priv->plat->has_gmac) {
+ if (!(priv->plat->has_gmac || priv->plat->has_gmac4)) {
/* MAC registers */
for (i = 0; i < 12; i++)
reg_space[i] = readl(priv->ioaddr + (i * 4));
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index e528e7126b65..d3b6f92f350a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -292,6 +292,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
if (of_device_is_compatible(np, "snps,dwmac-4.00") ||
of_device_is_compatible(np, "snps,dwmac-4.10a")) {
plat->has_gmac4 = 1;
+ plat->has_gmac = 0;
plat->pmt = 1;
plat->tso_en = of_property_read_bool(np, "snps,tso");
}
--
2.1.4
^ permalink raw reply related
* [RESEND PATCH 2/3] net: stmmac: dwmac-generic: add missing compatible strings
From: Niklas Cassel @ 2016-12-07 12:41 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue; +Cc: Niklas Cassel, netdev, linux-kernel
In-Reply-To: <1481114469-4788-1-git-send-email-niklass@axis.com>
From: Niklas Cassel <niklas.cassel@axis.com>
devicetree binding for stmmac states:
- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
For backwards compatibility: "st,spear600-gmac" is also supported.
Since dwmac-generic.c calls stmmac_probe_config_dt explicitly,
another alternative would have been to remove all compatible strings
other than "snps,dwmac" and "st,spear600-gmac" from dwmac-generic.c.
However, that would probably do more good than harm, since when trying
to figure out what hardware a certain driver supports, you usually look
at the compatible strings in the struct of_device_id, and not in some
function defined in a completely different file.
No functional change intended.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
index e6e6c2fcc4b7..3304095c934c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-generic.c
@@ -71,9 +71,12 @@ static int dwmac_generic_probe(struct platform_device *pdev)
static const struct of_device_id dwmac_generic_match[] = {
{ .compatible = "st,spear600-gmac"},
+ { .compatible = "snps,dwmac-3.50a"},
{ .compatible = "snps,dwmac-3.610"},
{ .compatible = "snps,dwmac-3.70a"},
{ .compatible = "snps,dwmac-3.710"},
+ { .compatible = "snps,dwmac-4.00"},
+ { .compatible = "snps,dwmac-4.10a"},
{ .compatible = "snps,dwmac"},
{ }
};
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next v5 1/2] flow dissector: ICMP support
From: Simon Horman @ 2016-12-07 12:44 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Jiri Pirko, Tom Herbert, David Miller, netdev
In-Reply-To: <20161207122629.GE1987@nanopsycho>
On Wed, Dec 07, 2016 at 01:26:29PM +0100, Jiri Pirko wrote:
> Wed, Dec 07, 2016 at 01:14:39PM CET, simon.horman@netronome.com wrote:
> >Allow dissection of ICMP(V6) type and code. This should only occur
> >if a packet is ICMP(V6) and the dissector has FLOW_DISSECTOR_KEY_ICMP set.
> >
> >There are currently no users of FLOW_DISSECTOR_KEY_ICMP.
> >A follow-up patch will allow FLOW_DISSECTOR_KEY_ICMP to be used by
> >the flower classifier.
>
>
> You are missing signedoff line.
Ooops!
^ permalink raw reply
* [PATCH net-next v6 0/2] net/sched: cls_flower: Support matching on ICMP
From: Simon Horman @ 2016-12-07 12:48 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Tom Herbert, David Miller, netdev, Simon Horman
Hi,
this series adds support for matching on ICMP type and code to cls_flower.
Changes v5->v6:
* Restore missing signed-off-by
Changes v4->v5:
* Drop all helpers
Changes v3->v4:
* Do not add icmp to struct flow_keys, it is not needed
* Do not test for ICMP protocols in packet in __skb_flow_dissect,
this is also not needed
Changes v2->v3:
* Add FLOW_DISSECTOR_KEY_ICMP and use separate structure for ICMP
Changes v1->v2:
* Include all dissector helpers in first patch
Simon Horman (2):
flow dissector: ICMP support
net/sched: cls_flower: Support matching on ICMP type and code
include/net/flow_dissector.h | 17 ++++++++++++++
include/uapi/linux/pkt_cls.h | 10 +++++++++
net/core/flow_dissector.c | 31 ++++++++++++++++++++++++++
net/sched/cls_flower.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 111 insertions(+)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH net-next v6 1/2] flow dissector: ICMP support
From: Simon Horman @ 2016-12-07 12:48 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Tom Herbert, David Miller, netdev, Simon Horman
In-Reply-To: <1481114908-24189-1-git-send-email-simon.horman@netronome.com>
Allow dissection of ICMP(V6) type and code. This should only occur
if a packet is ICMP(V6) and the dissector has FLOW_DISSECTOR_KEY_ICMP set.
There are currently no users of FLOW_DISSECTOR_KEY_ICMP.
A follow-up patch will allow FLOW_DISSECTOR_KEY_ICMP to be used by
the flower classifier.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
v6
* Add signed-off-by line which went missing at some point
v5
* Drop remaining helpers
v4
* Do not add icmp to struct flow_keys, it is not needed
* Do not test for ICMP protocols in packet in __skb_flow_dissect,
this is also not needed
* Drop now unnecessary helpers
v3
* Add FLOW_DISSECTOR_KEY_ICMP and use separate structure for ICMP, struct
flow_dissector_key_icmp, which is a union with struct
flow_dissector_key_ports in struct flow_keys.
* Drop checks for !ICMP before accessing port field
v2
* Include all helpers in this patch
---
include/net/flow_dissector.h | 17 +++++++++++++++++
net/core/flow_dissector.c | 31 +++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index c4f31666afd2..d896a33e00d4 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -104,6 +104,22 @@ struct flow_dissector_key_ports {
};
};
+/**
+ * flow_dissector_key_icmp:
+ * @ports: type and code of ICMP header
+ * icmp: ICMP type (high) and code (low)
+ * type: ICMP type
+ * code: ICMP code
+ */
+struct flow_dissector_key_icmp {
+ union {
+ __be16 icmp;
+ struct {
+ u8 type;
+ u8 code;
+ };
+ };
+};
/**
* struct flow_dissector_key_eth_addrs:
@@ -122,6 +138,7 @@ enum flow_dissector_key_id {
FLOW_DISSECTOR_KEY_IPV4_ADDRS, /* struct flow_dissector_key_ipv4_addrs */
FLOW_DISSECTOR_KEY_IPV6_ADDRS, /* struct flow_dissector_key_ipv6_addrs */
FLOW_DISSECTOR_KEY_PORTS, /* struct flow_dissector_key_ports */
+ FLOW_DISSECTOR_KEY_ICMP, /* struct flow_dissector_key_icmp */
FLOW_DISSECTOR_KEY_ETH_ADDRS, /* struct flow_dissector_key_eth_addrs */
FLOW_DISSECTOR_KEY_TIPC_ADDRS, /* struct flow_dissector_key_tipc_addrs */
FLOW_DISSECTOR_KEY_VLAN, /* struct flow_dissector_key_flow_vlan */
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 1eb6f949e5b2..d6447dc10371 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -58,6 +58,28 @@ void skb_flow_dissector_init(struct flow_dissector *flow_dissector,
EXPORT_SYMBOL(skb_flow_dissector_init);
/**
+ * skb_flow_get_be16 - extract be16 entity
+ * @skb: sk_buff to extract from
+ * @poff: offset to extract at
+ * @data: raw buffer pointer to the packet
+ * @hlen: packet header length
+ *
+ * The function will try to retrieve a be32 entity at
+ * offset poff
+ */
+__be16 skb_flow_get_be16(const struct sk_buff *skb, int poff, void *data,
+ int hlen)
+{
+ __be16 *u, _u;
+
+ u = __skb_header_pointer(skb, poff, sizeof(_u), data, hlen, &_u);
+ if (u)
+ return *u;
+
+ return 0;
+}
+
+/**
* __skb_flow_get_ports - extract the upper layer ports and return them
* @skb: sk_buff to extract the ports from
* @thoff: transport header offset
@@ -117,6 +139,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
struct flow_dissector_key_basic *key_basic;
struct flow_dissector_key_addrs *key_addrs;
struct flow_dissector_key_ports *key_ports;
+ struct flow_dissector_key_icmp *key_icmp;
struct flow_dissector_key_tags *key_tags;
struct flow_dissector_key_vlan *key_vlan;
struct flow_dissector_key_keyid *key_keyid;
@@ -546,6 +569,14 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
data, hlen);
}
+ if (dissector_uses_key(flow_dissector,
+ FLOW_DISSECTOR_KEY_ICMP)) {
+ key_icmp = skb_flow_dissector_target(flow_dissector,
+ FLOW_DISSECTOR_KEY_ICMP,
+ target_container);
+ key_icmp->icmp = skb_flow_get_be16(skb, nhoff, data, hlen);
+ }
+
out_good:
ret = true;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH net-next v6 2/2] net/sched: cls_flower: Support matching on ICMP type and code
From: Simon Horman @ 2016-12-07 12:48 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Tom Herbert, David Miller, netdev, Simon Horman
In-Reply-To: <1481114908-24189-1-git-send-email-simon.horman@netronome.com>
Support matching on ICMP type and code.
Example usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol ip parent ffff: flower \
indev eth0 ip_proto icmp type 8 code 0 action drop
tc filter add dev eth0 protocol ipv6 parent ffff: flower \
indev eth0 ip_proto icmpv6 type 128 code 0 action drop
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
v5
* Open-code checking for icmp protocols rather than using helpers
v4
* No change
v3
* Use separate dissector key FLOW_DISSECTOR_KEY_ICMP
* Use separate structure to hold icmp fields, this does not share
storage with ports
v2
* Move helpers to another patch
---
include/uapi/linux/pkt_cls.h | 10 +++++++++
net/sched/cls_flower.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index 1adc0b654996..884c5aa515c4 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -458,6 +458,16 @@ enum {
TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK, /* be16 */
TCA_FLOWER_KEY_ENC_UDP_DST_PORT, /* be16 */
TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK, /* be16 */
+
+ TCA_FLOWER_KEY_ICMPV4_CODE, /* u8 */
+ TCA_FLOWER_KEY_ICMPV4_CODE_MASK,/* u8 */
+ TCA_FLOWER_KEY_ICMPV4_TYPE, /* u8 */
+ TCA_FLOWER_KEY_ICMPV4_TYPE_MASK,/* u8 */
+ TCA_FLOWER_KEY_ICMPV6_CODE, /* u8 */
+ TCA_FLOWER_KEY_ICMPV6_CODE_MASK,/* u8 */
+ TCA_FLOWER_KEY_ICMPV6_TYPE, /* u8 */
+ TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,/* u8 */
+
__TCA_FLOWER_MAX,
};
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 29a9e6d9f274..f61f11b3194e 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -39,6 +39,7 @@ struct fl_flow_key {
struct flow_dissector_key_ipv6_addrs ipv6;
};
struct flow_dissector_key_ports tp;
+ struct flow_dissector_key_icmp icmp;
struct flow_dissector_key_keyid enc_key_id;
union {
struct flow_dissector_key_ipv4_addrs enc_ipv4;
@@ -386,6 +387,14 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
[TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_ENC_UDP_DST_PORT] = { .type = NLA_U16 },
[TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK] = { .type = NLA_U16 },
+ [TCA_FLOWER_KEY_ICMPV4_TYPE] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ICMPV4_TYPE_MASK] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ICMPV4_CODE] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ICMPV4_CODE_MASK] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ICMPV6_TYPE] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ICMPV6_TYPE_MASK] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ICMPV6_CODE] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ICMPV6_CODE_MASK] = { .type = NLA_U8 },
};
static void fl_set_key_val(struct nlattr **tb,
@@ -502,6 +511,26 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
fl_set_key_val(tb, &key->tp.dst, TCA_FLOWER_KEY_SCTP_DST,
&mask->tp.dst, TCA_FLOWER_KEY_SCTP_DST_MASK,
sizeof(key->tp.dst));
+ } else if (key->basic.n_proto == htons(ETH_P_IP) &&
+ key->basic.ip_proto == IPPROTO_ICMP) {
+ fl_set_key_val(tb, &key->icmp.type, TCA_FLOWER_KEY_ICMPV4_TYPE,
+ &mask->icmp.type,
+ TCA_FLOWER_KEY_ICMPV4_TYPE_MASK,
+ sizeof(key->icmp.type));
+ fl_set_key_val(tb, &key->icmp.code, TCA_FLOWER_KEY_ICMPV4_CODE,
+ &mask->icmp.code,
+ TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
+ sizeof(key->icmp.code));
+ } else if (key->basic.n_proto == htons(ETH_P_IPV6) &&
+ key->basic.ip_proto == IPPROTO_ICMPV6) {
+ fl_set_key_val(tb, &key->icmp.type, TCA_FLOWER_KEY_ICMPV6_TYPE,
+ &mask->icmp.type,
+ TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,
+ sizeof(key->icmp.type));
+ fl_set_key_val(tb, &key->icmp.code, TCA_FLOWER_KEY_ICMPV4_CODE,
+ &mask->icmp.code,
+ TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
+ sizeof(key->icmp.code));
}
if (tb[TCA_FLOWER_KEY_ENC_IPV4_SRC] ||
@@ -612,6 +641,8 @@ static void fl_init_dissector(struct cls_fl_head *head,
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_PORTS, tp);
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
+ FLOW_DISSECTOR_KEY_ICMP, icmp);
+ FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_VLAN, vlan);
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_ENC_KEYID, enc_key_id);
@@ -977,6 +1008,28 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
&mask->tp.dst, TCA_FLOWER_KEY_SCTP_DST_MASK,
sizeof(key->tp.dst))))
goto nla_put_failure;
+ else if (key->basic.n_proto == htons(ETH_P_IP) &&
+ key->basic.ip_proto == IPPROTO_ICMP &&
+ (fl_dump_key_val(skb, &key->icmp.type,
+ TCA_FLOWER_KEY_ICMPV4_TYPE, &mask->icmp.type,
+ TCA_FLOWER_KEY_ICMPV4_TYPE_MASK,
+ sizeof(key->icmp.type)) ||
+ fl_dump_key_val(skb, &key->icmp.code,
+ TCA_FLOWER_KEY_ICMPV4_CODE, &mask->icmp.code,
+ TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
+ sizeof(key->icmp.code))))
+ goto nla_put_failure;
+ else if (key->basic.n_proto == htons(ETH_P_IPV6) &&
+ key->basic.ip_proto == IPPROTO_ICMPV6 &&
+ (fl_dump_key_val(skb, &key->icmp.type,
+ TCA_FLOWER_KEY_ICMPV6_TYPE, &mask->icmp.type,
+ TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,
+ sizeof(key->icmp.type)) ||
+ fl_dump_key_val(skb, &key->icmp.code,
+ TCA_FLOWER_KEY_ICMPV6_CODE, &mask->icmp.code,
+ TCA_FLOWER_KEY_ICMPV6_CODE_MASK,
+ sizeof(key->icmp.code))))
+ goto nla_put_failure;
if (key->enc_control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
(fl_dump_key_val(skb, &key->enc_ipv4.src,
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH net-next v6 2/2] net/sched: cls_flower: Support matching on ICMP type and code
From: Jiri Pirko @ 2016-12-07 13:06 UTC (permalink / raw)
To: Simon Horman; +Cc: Jiri Pirko, Tom Herbert, David Miller, netdev
In-Reply-To: <1481114908-24189-3-git-send-email-simon.horman@netronome.com>
Wed, Dec 07, 2016 at 01:48:28PM CET, simon.horman@netronome.com wrote:
>Support matching on ICMP type and code.
>
>Example usage:
>
>tc qdisc add dev eth0 ingress
>
>tc filter add dev eth0 protocol ip parent ffff: flower \
> indev eth0 ip_proto icmp type 8 code 0 action drop
>
>tc filter add dev eth0 protocol ipv6 parent ffff: flower \
> indev eth0 ip_proto icmpv6 type 128 code 0 action drop
>
>Signed-off-by: Simon Horman <simon.horman@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH 1/1] NET: usb: cdc_mbim: add quirk for supporting Telit LE922A
From: Daniele Palmas @ 2016-12-07 13:07 UTC (permalink / raw)
To: Bjørn Mork, Oliver Neukum
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Daniele Palmas
In-Reply-To: <1481116068-32691-1-git-send-email-dnlplm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Telit LE922A MBIM based composition does not work properly
with altsetting toggle done in cdc_ncm_bind_common.
This patch adds CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk
to avoid this procedure that, instead, is mandatory for
other modems.
Signed-off-by: Daniele Palmas <dnlplm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/cdc_mbim.c | 21 +++++++++++++++++++++
drivers/net/usb/cdc_ncm.c | 14 +++++++++-----
include/linux/usb/cdc_ncm.h | 3 ++-
3 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 96a5028..3a98f37 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -602,6 +602,21 @@ static const struct driver_info cdc_mbim_info_ndp_to_end = {
.data = CDC_NCM_FLAG_NDP_TO_END,
};
+/* Some modems (e.g. Telit LE922A6) do not work properly with altsetting
+ * toggle done in cdc_ncm_bind_common. CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE
+ * flag is used to avoid this procedure.
+ */
+static const struct driver_info cdc_mbim_info_avoid_altsetting_toggle = {
+ .description = "CDC MBIM",
+ .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN,
+ .bind = cdc_mbim_bind,
+ .unbind = cdc_mbim_unbind,
+ .manage_power = cdc_mbim_manage_power,
+ .rx_fixup = cdc_mbim_rx_fixup,
+ .tx_fixup = cdc_mbim_tx_fixup,
+ .data = CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE,
+};
+
static const struct usb_device_id mbim_devs[] = {
/* This duplicate NCM entry is intentional. MBIM devices can
* be disguised as NCM by default, and this is necessary to
@@ -626,6 +641,12 @@ static const struct usb_device_id mbim_devs[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&cdc_mbim_info_ndp_to_end,
},
+
+ /* Telit LE922A6 in MBIM composition */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1bc7, 0x1041, USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&cdc_mbim_info_avoid_altsetting_toggle,
+ },
+
/* default entry */
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&cdc_mbim_info_zlp,
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 877c951..afbfc0f 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -839,11 +839,18 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_
iface_no = ctx->data->cur_altsetting->desc.bInterfaceNumber;
+ /* Device-specific flags */
+ ctx->drvflags = drvflags;
+
/* Reset data interface. Some devices will not reset properly
* unless they are configured first. Toggle the altsetting to
- * force a reset
+ * force a reset.
+ * Some other devices do not work properly with this procedure
+ * that can be avoided using quirk CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE
*/
- usb_set_interface(dev->udev, iface_no, data_altsetting);
+ if (!(ctx->drvflags & CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE))
+ usb_set_interface(dev->udev, iface_no, data_altsetting);
+
temp = usb_set_interface(dev->udev, iface_no, 0);
if (temp) {
dev_dbg(&intf->dev, "set interface failed\n");
@@ -890,9 +897,6 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_
/* finish setting up the device specific data */
cdc_ncm_setup(dev);
- /* Device-specific flags */
- ctx->drvflags = drvflags;
^ permalink raw reply related
* [PATCH 0/1] NET: usb: cdc_mbim: add quirk for supporting Telit LE922A
From: Daniele Palmas @ 2016-12-07 13:07 UTC (permalink / raw)
To: Bjørn Mork, Oliver Neukum; +Cc: netdev, linux-usb, Daniele Palmas
Telit LE922A MBIM based composition does not work properly
with altsetting toggle done in cdc_ncm_bind_common.
This patch adds CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk
to avoid this procedure that, instead, is mandatory for
other modems.
References:
https://www.spinics.net/lists/linux-usb/msg149249.html
https://www.spinics.net/lists/linux-usb/msg149819.html
Thanks to Bjørn for the productive discussion and feedback!
Daniele Palmas (1):
NET: usb: cdc_mbim: add quirk for supporting Telit LE922A
drivers/net/usb/cdc_mbim.c | 21 +++++++++++++++++++++
drivers/net/usb/cdc_ncm.c | 14 +++++++++-----
include/linux/usb/cdc_ncm.h | 3 ++-
3 files changed, 32 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 1/2] vhost-vsock: remove unused vq variable
From: Stefan Hajnoczi @ 2016-12-07 13:10 UTC (permalink / raw)
To: Peng Tao; +Cc: Stefan Hajnoczi, kvm, virtualization, netdev
In-Reply-To: <1481104340-77035-1-git-send-email-bergwolf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 230 bytes --]
On Wed, Dec 07, 2016 at 05:52:18PM +0800, Peng Tao wrote:
> Signed-off-by: Peng Tao <bergwolf@gmail.com>
> ---
> drivers/vhost/vsock.c | 3 ---
> 1 file changed, 3 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] vhost: remove unnecessary smp_mb from vhost_work_queue
From: Stefan Hajnoczi @ 2016-12-07 13:10 UTC (permalink / raw)
To: Peng Tao; +Cc: netdev, kvm, Stefan Hajnoczi, virtualization
In-Reply-To: <1481104340-77035-2-git-send-email-bergwolf@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 311 bytes --]
On Wed, Dec 07, 2016 at 05:52:19PM +0800, Peng Tao wrote:
> test_and_set_bit() already implies a memory barrier.
>
> Signed-off-by: Peng Tao <bergwolf@gmail.com>
> ---
> drivers/vhost/vhost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] Re: Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.
From: Lino Sanfilippo @ 2016-12-07 13:18 UTC (permalink / raw)
To: Pavel Machek, Lino Sanfilippo
Cc: Giuseppe CAVALLARO, alexandre.torgue, David Miller, netdev,
linux-kernel
In-Reply-To: <20161207123140.GA8785@amd>
Hi,
On 07.12.2016 13:31, Pavel Machek wrote:
> On Fri 2016-12-02 15:05:21, Lino Sanfilippo wrote:
>> Hi,
>>
>>
>>>
>>> There's nothing that protect stmmac_poll() from running concurently
>>> with stmmac_dma_interrupt(), right?
>>>
>>
>> could it be that there is also another issue concerned locking?:
>> The tx completion handler takes the xmit_lock in case that the
>> netif_queue is stopped. This is AFAICS unnecessary, since both
>> xmit and completion handler are already synchronized by the private
>> tx lock. But it is IMHO also dangerous:
>>
>> In the xmit handler we have the locking order
>> 1. xmit_lock
>> 2. private tx lock
>>
>> while in the completion handler its the reverse:
>>
>> 1. private tx lock
>> 2. xmit lock.
>>
>> Do I miss something?
>
> No, it seems you are right. Something like this?
>
> Hmm. And can priv->tx_lock be removed, as we already rely on
> netif_tx_lock?
>
David wanted indeed the private lock to be removed completely. See
this thread.
https://marc.info/?l=linux-netdev&m=148072001900620&w=2
If you can wait a bit, I already have patches prepared to fix this issue in both
drivers. I want to send them as soon as I am at home (a few hours).
Regards,
Lino
^ permalink raw reply
* Re: [PATCH nf-next v2] netfilter: xt_bpf: support ebpf
From: Pablo Neira Ayuso @ 2016-12-07 13:20 UTC (permalink / raw)
To: Willem de Bruijn
Cc: netfilter-devel, fw, eric.dumazet, netdev, daniel,
Willem de Bruijn
In-Reply-To: <1481059502-47824-1-git-send-email-willemdebruijn.kernel@gmail.com>
On Tue, Dec 06, 2016 at 04:25:02PM -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> Add support for attaching an eBPF object by file descriptor.
>
> The iptables binary can be called with a path to an elf object or a
> pinned bpf object. Also pass the mode and path to the kernel to be
> able to return it later for iptables dump and save.
Applied, thanks Willem.
^ permalink raw reply
* Re: [PATCH net-next v6 1/2] flow dissector: ICMP support
From: Jiri Pirko @ 2016-12-07 13:05 UTC (permalink / raw)
To: Simon Horman; +Cc: Jiri Pirko, Tom Herbert, David Miller, netdev
In-Reply-To: <1481114908-24189-2-git-send-email-simon.horman@netronome.com>
Wed, Dec 07, 2016 at 01:48:27PM CET, simon.horman@netronome.com wrote:
>Allow dissection of ICMP(V6) type and code. This should only occur
>if a packet is ICMP(V6) and the dissector has FLOW_DISSECTOR_KEY_ICMP set.
>
>There are currently no users of FLOW_DISSECTOR_KEY_ICMP.
>A follow-up patch will allow FLOW_DISSECTOR_KEY_ICMP to be used by
>the flower classifier.
>
>Signed-off-by: Simon Horman <simon.horman@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH 3/4] vsock: add pkt cancel capability
From: Stefan Hajnoczi @ 2016-12-07 13:22 UTC (permalink / raw)
To: Peng Tao; +Cc: netdev, kvm, Stefan Hajnoczi, virtualization
In-Reply-To: <1481104821-77294-4-git-send-email-bergwolf@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1782 bytes --]
On Wed, Dec 07, 2016 at 06:00:20PM +0800, Peng Tao wrote:
> Signed-off-by: Peng Tao <bergwolf@gmail.com>
> ---
> net/vmw_vsock/virtio_transport.c | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
> index 936d7ee..f88b6ed 100644
> --- a/net/vmw_vsock/virtio_transport.c
> +++ b/net/vmw_vsock/virtio_transport.c
> @@ -170,6 +170,41 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt)
> return len;
> }
>
> +static int
> +virtio_transport_cancel_pkt(struct vsock_sock *vsk)
> +{
> + struct virtio_vsock *vsock;
> + struct virtio_vsock_pkt *pkt, *n;
> + int cnt = 0;
> + LIST_HEAD(freeme);
> +
> + vsock = virtio_vsock_get();
> + if (!vsock) {
> + return -ENODEV;
> + }
> +
> + if (pkt->reply)
pkt is uninitialized. I guess this if statement should be deleted, you
already take care of counting reply packets below.
> + cnt++;
> +
> + spin_lock_bh(&vsock->send_pkt_list_lock);
> + list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
> + if (pkt->vsk != vsk)
> + continue;
> + list_move(&pkt->list, &freeme);
> + }
> + spin_unlock_bh(&vsock->send_pkt_list_lock);
> +
> + list_for_each_entry_safe(pkt, n, &freeme, list) {
> + if (pkt->reply)
> + cnt++;
> + list_del(&pkt->list);
> + virtio_transport_free_pkt(pkt);
> + }
> + atomic_sub(cnt, &vsock->queued_replies);
If we stopped rx because there were too many replies in flight then we
might be able to resume rx now:
/* Do we now have resources to resume rx processing? */
if (old_val >= virtqueue_get_vring_size(rx_vq) &&
new_val < virtqueue_get_vring_size(rx_vq))
queue_work(virtio_vsock_workqueue, &vsock->rx_work);
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 10/10] virtio: enable endian checks for sparse builds
From: Michael S. Tsirkin @ 2016-12-07 13:22 UTC (permalink / raw)
To: Johannes Berg
Cc: kvm, Neil Armstrong, David Airlie, linux-remoteproc, dri-devel,
virtualization, linux-s390, James E.J. Bottomley, Herbert Xu,
linux-scsi, v9fs-developer, Asias He, Arnd Bergmann, linux-kbuild,
Jens Axboe, Michal Marek, Stefan Hajnoczi, Matt Mackall,
Greg Kroah-Hartman, linux-kernel, linux-crypto, netdev,
David S. Miller
In-Reply-To: <1481091951.4092.12.camel@sipsolutions.net>
On Wed, Dec 07, 2016 at 07:25:51AM +0100, Johannes Berg wrote:
> On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
>
> > It seems that there should be a better way to do it,
> > but this works too.
>
> In some cases there might be:
>
> > --- a/drivers/s390/virtio/Makefile
> > +++ b/drivers/s390/virtio/Makefile
> > @@ -6,6 +6,8 @@
> > # it under the terms of the GNU General Public License (version 2
> > only)
> > # as published by the Free Software Foundation.
> >
> > +CFLAGS_virtio_ccw.o += -D__CHECK_ENDIAN__
> > +CFLAGS_kvm_virtio.o += -D__CHECK_ENDIAN__
> > s390-virtio-objs := virtio_ccw.o
> > ifdef CONFIG_S390_GUEST_OLD_TRANSPORT
> > s390-virtio-objs += kvm_virtio.o
>
> Here you could use
>
> ccflags-y += -D__CHECK_ENDIAN__
>
> for example, or even
>
> subdir-ccflags-y += -D__CHECK_ENDIAN__
>
> (in case any subdirs ever get added here)
Oh right. I forgot this directory only has virtio stuff.
> > --- a/drivers/vhost/Makefile
> > +++ b/drivers/vhost/Makefile
> > @@ -1,3 +1,4 @@
> > +ccflags-y := -D__CHECK_ENDIAN__
>
> Looks like you did that here and in some other places though - so
> perhaps the s390 one was intentionally different?
>
> > --- a/net/packet/Makefile
> > +++ b/net/packet/Makefile
> > @@ -2,6 +2,7 @@
> > # Makefile for the packet AF.
> > #
> >
> > +ccflags-y := -D__CHECK_ENDIAN__
>
> Technically this is slightly more than advertised, but I guess that
> still makes sense if it's clean now.
>
> johannes
^ permalink raw reply
* Re: [PATCH 2/4] vhost-vsock: add pkt cancel capability
From: Stefan Hajnoczi @ 2016-12-07 13:23 UTC (permalink / raw)
To: Peng Tao; +Cc: netdev, kvm, Stefan Hajnoczi, virtualization
In-Reply-To: <1481104821-77294-3-git-send-email-bergwolf@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1403 bytes --]
On Wed, Dec 07, 2016 at 06:00:19PM +0800, Peng Tao wrote:
> To allow canceling all packets of a connection.
>
> Signed-off-by: Peng Tao <bergwolf@gmail.com>
> ---
> drivers/vhost/vsock.c | 29 +++++++++++++++++++++++++++++
> include/linux/virtio_vsock.h | 3 +++
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index a504e2e0..0c23b55 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -218,6 +218,34 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt)
> return len;
> }
>
> +static int
> +vhost_transport_cancel_pkt(struct vsock_sock *vsk)
> +{
> + struct vhost_vsock *vsock;
> + struct virtio_vsock_pkt *pkt, *n;
> + LIST_HEAD(freeme);
> +
> + /* Find the vhost_vsock according to guest context id */
> + vsock = vhost_vsock_get(vsk->remote_addr.svm_cid);
> + if (!vsock)
> + return -ENODEV;
> +
> + spin_lock_bh(&vsock->send_pkt_list_lock);
> + list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
> + if (pkt->vsk != vsk)
> + continue;
> + list_move(&pkt->list, &freeme);
> + }
> + spin_unlock_bh(&vsock->send_pkt_list_lock);
> +
> + list_for_each_entry_safe(pkt, n, &freeme, list) {
> + list_del(&pkt->list);
> + virtio_transport_free_pkt(pkt);
> + }
Please handle queued_replies so we can resume rx if we fall below the
threshold again.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 4/4] vsock: cancel packets when failing to connect
From: Stefan Hajnoczi @ 2016-12-07 13:25 UTC (permalink / raw)
To: Peng Tao; +Cc: Stefan Hajnoczi, kvm, virtualization, netdev
In-Reply-To: <1481104821-77294-5-git-send-email-bergwolf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
On Wed, Dec 07, 2016 at 06:00:21PM +0800, Peng Tao wrote:
> Otherwise we'll leave the packets queued until releasing vsock device.
> E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest
> will get the connect requests from failed host sockets.
>
> Signed-off-by: Peng Tao <bergwolf@gmail.com>
> ---
> include/linux/virtio_vsock.h | 7 +++++++
> net/vmw_vsock/af_vsock.c | 7 +++++++
> net/vmw_vsock/virtio_transport_common.c | 7 -------
> 3 files changed, 14 insertions(+), 7 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH] net:dsa:mv88e6xxx: delete timer and cancel ppu_work
From: Volodymyr Bendiuga @ 2016-12-07 13:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: vivien.didelot, f.fainelli, netdev, volodymyr.bendiuga,
Jonas Johansson
In-Reply-To: <20161206142226.GD26615@lunn.ch>
This issue seems to be resolved now with new PPU patch set.
On 2016-12-06 15:22, Andrew Lunn wrote:
> On Tue, Dec 06, 2016 at 01:57:42PM +0100, Volodymyr Bendiuga wrote:
>> Signed-off-by: Jonas Johansson <jonas.johansson@westermo.se>
>> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@westermo.se>
>> ---
>> drivers/net/dsa/mv88e6xxx/chip.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>> index ca453f3..4212fb6 100644
>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
>> @@ -4528,8 +4528,11 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
>> out_mdio:
>> mv88e6xxx_mdio_unregister(chip);
>> out_g2_irq:
>> - if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_G2_INT) && chip->irq > 0)
>> + if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_G2_INT) && chip->irq > 0) {
>> mv88e6xxx_g2_irq_free(chip);
>> + del_timer(&chip->ppu_timer);
>> + cancel_work_sync(&chip->ppu_work);
>> + }
> Why do this here, inside this if statement?
>
> Vivien has also just reworked the PPU code. Please take a look at his
> patches and see if they fix the issue.
>
> 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