Re: [PATCH net-next 6/7] net: bridge: Notify about bridge VLANs
Vivien Didelot writes:
> Hi Petr,
>
> Petr Machata writes:
>
>> Vivien Didelot writes:
>>
+ } else {
+ err = br_switchdev_port_obj_add(dev, v->vid, flags);
+ if (err && err != -EOPNOTSUPP)
+ goto out;
}
>>>
>>> Except that br_switchdev_port_obj_add taking vid and flags arguments
>>> seems confusing to me, the change looks good:
>>
>> I'm not sure what you're aiming at. Both VID and flags are sent with the
>> notification, so they need to be passed on to the function somehow. Do
>> you have a counterproposal for the API?
>
> I'm only questioning the code organization here, not the functional
> aspect which I do agree with. What I'm saying is that you name a new
> switchdev helper br_switchdev_port_OBJ_add, which takes VLAN arguments
> (vid and flags.) How would you call another eventual helper taking MDB
> arguments, br_switchdev_port_OBJ_add again? So something like
> br_switchdev_port_VLAN_add would be more intuitive.
>
> At the same time there's an effort to centralize all switchdev helpers
> of the bridge layer (i.e. the software -> hardware bridge calls) into
> net/bridge/br_switchdev.c, so that file would be more adequate.
>
> You may discard my comments but I think it'd be beneficial to us all to
> finally keep a bit of consistency in that bridge layer code.
Nope, those are reasonable points. I'll post a v2 along those lines.
Thanks,
Petr
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v2 2/7] mlxsw: spectrum_switchdev: Ignore bridge VLAN events
Ignore VLAN events where the orig_dev is the bridge device itself. Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel --- drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c index 8c9cf8e..cbc8fab 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c @@ -1144,6 +1144,9 @@ static int mlxsw_sp_port_vlans_add(struct mlxsw_sp_port *mlxsw_sp_port, struct mlxsw_sp_bridge_port *bridge_port; u16 vid; + if (netif_is_bridge_master(orig_dev)) + return -EOPNOTSUPP; + if (switchdev_trans_ph_prepare(trans)) return 0; @@ -1741,6 +1744,9 @@ static int mlxsw_sp_port_vlans_del(struct mlxsw_sp_port *mlxsw_sp_port, struct mlxsw_sp_bridge_port *bridge_port; u16 vid; + if (netif_is_bridge_master(orig_dev)) + return -EOPNOTSUPP; + bridge_port = mlxsw_sp_bridge_port_find(mlxsw_sp->bridge, orig_dev); if (WARN_ON(!bridge_port)) return -EINVAL; -- 2.4.11 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v2 0/7] net: bridge: Notify about bridge VLANs
In commit 946a11e7408e ("mlxsw: spectrum_span: Allow bridge for gretap
mirror"), mlxsw got support for offloading mirror-to-gretap such that
the underlay packet path involves a bridge. In that case, the offload is
also influenced by PVID setting of said bridge. However, changes to VLAN
configuration of the bridge itself do not generate switchdev
notifications, so there's no mechanism to prod mlxsw to update the
offload when these settings change.
In this patchset, the problem is resolved by distributing the switchdev
notification SWITCHDEV_OBJ_ID_PORT_VLAN also for configuration changes
on bridge VLANs. Since stacked devices distribute the notification to
lower devices, such event eventually reaches the driver, which can
determine whether it's a bridge or port VLAN by inspecting orig_dev.
To keep things consistent, the newly-distributed notifications observe
the same protocol as the existing ones: dual prepare/commit, with
-EOPNOTSUPP indicating lack of support, even though there's currently
nothing to prepare for and nothing to support. Correspondingly, all
switchdev drivers have been updated to return -EOPNOTSUPP for bridge
VLAN notifications.
In patch #1, the code to send notifications for adding and deleting is
factored out into two named functions.
In patches #2-#5, respectively for mlxsw, rocker, DSA and DPAA2 ethsw,
the new notifications (which are not enabled yet) are ignored to
maintain the current behavior.
In patch #6, the notification is actually enabled.
In patch #7, mlxsw is changed to update offloads of mirror-to-gre also
for bridge-related notifications.
Changes from v1 to v2:
- Rename br_switchdev_port_obj_add() and br_switchdev_port_obj_del() to
br_switchdev_port_vlan_add() and br_switchdev_port_vlan_del(), and
move from br_vlan.c to br_switchdev.c.
Petr Machata (7):
net: bridge: Extract boilerplate around switchdev_port_obj_*()
mlxsw: spectrum_switchdev: Ignore bridge VLAN events
rocker: rocker_main: Ignore bridge VLAN events
dsa: port: Ignore bridge VLAN events
staging: fsl-dpaa2: ethsw: Ignore bridge VLAN events
net: bridge: Notify about bridge VLANs
mlxsw: spectrum_switchdev: Schedule respin during trans prepare
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 8 +++-
drivers/net/ethernet/rocker/rocker_main.c | 6 +++
drivers/staging/fsl-dpaa2/ethsw/ethsw.c| 6 +++
net/bridge/br_private.h| 3 ++
net/bridge/br_switchdev.c | 25
net/bridge/br_vlan.c | 45 +-
net/dsa/port.c | 6 +++
7 files changed, 71 insertions(+), 28 deletions(-)
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v2 5/7] staging: fsl-dpaa2: ethsw: Ignore bridge VLAN events
Ignore VLAN events where the orig_dev is the bridge device itself.
Signed-off-by: Petr Machata
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index c723a04..a17dd29 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -719,6 +719,9 @@ static int port_vlans_add(struct net_device *netdev,
struct ethsw_port_priv *port_priv = netdev_priv(netdev);
int vid, err;
+ if (netif_is_bridge_master(vlan->obj.orig_dev))
+ return -EOPNOTSUPP;
+
if (switchdev_trans_ph_prepare(trans))
return 0;
@@ -873,6 +876,9 @@ static int port_vlans_del(struct net_device *netdev,
struct ethsw_port_priv *port_priv = netdev_priv(netdev);
int vid, err;
+ if (netif_is_bridge_master(vlan->obj.orig_dev))
+ return -EOPNOTSUPP;
+
for (vid = vlan->vid_begin; vid <= vlan->vid_end; vid++) {
err = ethsw_port_del_vlan(port_priv, vid);
if (err)
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v2 1/7] net: bridge: Extract boilerplate around switchdev_port_obj_*()
A call to switchdev_port_obj_add() or switchdev_port_obj_del() involves
initializing a struct switchdev_obj_port_vlan, a piece of code that
repeats on each call site almost verbatim. While in the current codebase
there is just one duplicated add call, the follow-up patches add more of
both add and del calls.
Thus to remove the duplication, extract the repetition into named
functions and reuse.
Signed-off-by: Petr Machata
---
net/bridge/br_private.h | 3 +++
net/bridge/br_switchdev.c | 25 +
net/bridge/br_vlan.c | 31 ---
3 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 11520ed..33bd914 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -1178,6 +1178,9 @@ static inline void br_switchdev_frame_unmark(struct
sk_buff *skb)
}
#endif /* CONFIG_NET_SWITCHDEV */
+int br_switchdev_port_vlan_add(struct net_device *dev, u16 vid, u16 flags);
+int br_switchdev_port_vlan_del(struct net_device *dev, u16 vid);
+
/* br_arp_nd_proxy.c */
void br_recalculate_neigh_suppress_enabled(struct net_bridge *br);
void br_do_proxy_suppress_arp(struct sk_buff *skb, struct net_bridge *br,
diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
index 35474d4..d77f807 100644
--- a/net/bridge/br_switchdev.c
+++ b/net/bridge/br_switchdev.c
@@ -136,3 +136,28 @@ br_switchdev_fdb_notify(const struct net_bridge_fdb_entry
*fdb, int type)
break;
}
}
+
+int br_switchdev_port_vlan_add(struct net_device *dev, u16 vid, u16 flags)
+{
+ struct switchdev_obj_port_vlan v = {
+ .obj.orig_dev = dev,
+ .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
+ .flags = flags,
+ .vid_begin = vid,
+ .vid_end = vid,
+ };
+
+ return switchdev_port_obj_add(dev, &v.obj);
+}
+
+int br_switchdev_port_vlan_del(struct net_device *dev, u16 vid)
+{
+ struct switchdev_obj_port_vlan v = {
+ .obj.orig_dev = dev,
+ .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
+ .vid_begin = vid,
+ .vid_end = vid,
+ };
+
+ return switchdev_port_obj_del(dev, &v.obj);
+}
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index dc832c09..8ad5756 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -82,19 +82,10 @@ static bool __vlan_add_flags(struct net_bridge_vlan *v, u16
flags)
static int __vlan_vid_add(struct net_device *dev, struct net_bridge *br,
u16 vid, u16 flags)
{
- struct switchdev_obj_port_vlan v = {
- .obj.orig_dev = dev,
- .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
- .flags = flags,
- .vid_begin = vid,
- .vid_end = vid,
- };
- int err;
-
/* Try switchdev op first. In case it is not supported, fallback to
* 8021q add.
*/
- err = switchdev_port_obj_add(dev, &v.obj);
+ int err = br_switchdev_port_vlan_add(dev, vid, flags);
if (err == -EOPNOTSUPP)
return vlan_vid_add(dev, br->vlan_proto, vid);
return err;
@@ -130,18 +121,11 @@ static void __vlan_del_list(struct net_bridge_vlan *v)
static int __vlan_vid_del(struct net_device *dev, struct net_bridge *br,
u16 vid)
{
- struct switchdev_obj_port_vlan v = {
- .obj.orig_dev = dev,
- .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
- .vid_begin = vid,
- .vid_end = vid,
- };
- int err;
-
/* Try switchdev op first. In case it is not supported, fallback to
* 8021q del.
*/
- err = switchdev_port_obj_del(dev, &v.obj);
+ int err = br_switchdev_port_vlan_del(dev, vid);
+
if (err == -EOPNOTSUPP) {
vlan_vid_del(dev, br->vlan_proto, vid);
return 0;
@@ -1053,13 +1037,6 @@ int nbp_vlan_init(struct net_bridge_port *p)
int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags,
bool *changed)
{
- struct switchdev_obj_port_vlan v = {
- .obj.orig_dev = port->dev,
- .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
- .flags = flags,
- .vid_begin = vid,
- .vid_end = vid,
- };
struct net_bridge_vlan *vlan;
int ret;
@@ -1069,7 +1046,7 @@ int nbp_vlan_add(struct net_bridge_port *port, u16 vid,
u16 flags,
vlan = br_vlan_find(nbp_vlan_group(port), vid);
if (vlan) {
/* Pass the flags to the hardware bridge */
- ret = switchdev_port_obj_add(port->dev, &v.obj);
+ ret = br_switchdev_port_vlan_add(port->dev, vid, flags);
if (ret && ret != -EOPNOTSUPP)
return ret;
*changed = __vlan_add_flags(vlan, flags);
--
2.4.11
_
[PATCH net-next v2 4/7] dsa: port: Ignore bridge VLAN events
Ignore VLAN events where the orig_dev is the bridge device itself. Signed-off-by: Petr Machata Reviewed-by: Vivien Didelot --- net/dsa/port.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/net/dsa/port.c b/net/dsa/port.c index 2413beb..ed05954 100644 --- a/net/dsa/port.c +++ b/net/dsa/port.c @@ -252,6 +252,9 @@ int dsa_port_vlan_add(struct dsa_port *dp, .vlan = vlan, }; + if (netif_is_bridge_master(vlan->obj.orig_dev)) + return -EOPNOTSUPP; + if (br_vlan_enabled(dp->bridge_dev)) return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info); @@ -267,6 +270,9 @@ int dsa_port_vlan_del(struct dsa_port *dp, .vlan = vlan, }; + if (netif_is_bridge_master(vlan->obj.orig_dev)) + return -EOPNOTSUPP; + if (br_vlan_enabled(dp->bridge_dev)) return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info); -- 2.4.11 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v2 3/7] rocker: rocker_main: Ignore bridge VLAN events
Ignore VLAN events where the orig_dev is the bridge device itself.
Signed-off-by: Petr Machata
---
drivers/net/ethernet/rocker/rocker_main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c
b/drivers/net/ethernet/rocker/rocker_main.c
index e73e4fe..aeafdb9 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -1632,6 +1632,9 @@ rocker_world_port_obj_vlan_add(struct rocker_port
*rocker_port,
{
struct rocker_world_ops *wops = rocker_port->rocker->wops;
+ if (netif_is_bridge_master(vlan->obj.orig_dev))
+ return -EOPNOTSUPP;
+
if (!wops->port_obj_vlan_add)
return -EOPNOTSUPP;
@@ -1647,6 +1650,9 @@ rocker_world_port_obj_vlan_del(struct rocker_port
*rocker_port,
{
struct rocker_world_ops *wops = rocker_port->rocker->wops;
+ if (netif_is_bridge_master(vlan->obj.orig_dev))
+ return -EOPNOTSUPP;
+
if (!wops->port_obj_vlan_del)
return -EOPNOTSUPP;
return wops->port_obj_vlan_del(rocker_port, vlan);
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v2 7/7] mlxsw: spectrum_switchdev: Schedule respin during trans prepare
Since there's no special support for the bridge events, the driver
returns -EOPNOTSUPP, and thus the commit never happens. Therefore
schedule respin during the prepare stage: there's no real difference one
way or another.
This fixes the problem that mirror-to-gretap offload wouldn't adapt to
changes in bridge vlan configuration right away and another notification
would have to arrive for mlxsw to catch up.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index cbc8fab..8a15ac4 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -1697,7 +1697,7 @@ static int mlxsw_sp_port_obj_add(struct net_device *dev,
vlan = SWITCHDEV_OBJ_PORT_VLAN(obj);
err = mlxsw_sp_port_vlans_add(mlxsw_sp_port, vlan, trans);
- if (switchdev_trans_ph_commit(trans)) {
+ if (switchdev_trans_ph_prepare(trans)) {
/* The event is emitted before the changes are actually
* applied to the bridge. Therefore schedule the respin
* call for later, so that the respin logic sees the
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v2 6/7] net: bridge: Notify about bridge VLANs
A driver might need to react to changes in settings of brentry VLANs.
Therefore send switchdev port notifications for these as well. Reuse
SWITCHDEV_OBJ_ID_PORT_VLAN for this purpose. Listeners should use
netif_is_bridge_master() on orig_dev to determine whether the
notification is about a bridge port or a bridge.
Signed-off-by: Petr Machata
Reviewed-by: Florian Fainelli
Reviewed-by: Vivien Didelot
Reviewed-by: Nikolay Aleksandrov
Tested-by: Florian Fainelli
---
net/bridge/br_vlan.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 8ad5756..b15ef3f 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -243,6 +243,10 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
goto out_filt;
v->brvlan = masterv;
v->stats = masterv->stats;
+ } else {
+ err = br_switchdev_port_vlan_add(dev, v->vid, flags);
+ if (err && err != -EOPNOTSUPP)
+ goto out;
}
/* Add the dev mac and count the vlan only if it's usable */
@@ -278,6 +282,8 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
br_vlan_put_master(masterv);
v->brvlan = NULL;
}
+ } else {
+ br_switchdev_port_vlan_del(dev, v->vid);
}
goto out;
@@ -303,6 +309,11 @@ static int __vlan_del(struct net_bridge_vlan *v)
err = __vlan_vid_del(p->dev, p->br, v->vid);
if (err)
goto out;
+ } else {
+ err = br_switchdev_port_vlan_del(v->br->dev, v->vid);
+ if (err && err != -EOPNOTSUPP)
+ goto out;
+ err = 0;
}
if (br_vlan_should_use(v)) {
@@ -580,6 +591,9 @@ int br_vlan_add(struct net_bridge *br, u16 vid, u16 flags,
bool *changed)
vg->num_vlans++;
*changed = true;
}
+ ret = br_switchdev_port_vlan_add(br->dev, vid, flags);
+ if (ret && ret != -EOPNOTSUPP)
+ return ret;
if (__vlan_add_flags(vlan, flags))
*changed = true;
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: speakup: remove simple_strtoul()
The original code is fine. Just ignore checkpatch.pl. You added some kmalloc()s without a freeing the memory afterward. It's all way more complicated than it looks... regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v2 1/7] net: bridge: Extract boilerplate around switchdev_port_obj_*()
Petr Machata writes: > diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h > index 11520ed..33bd914 100644 > --- a/net/bridge/br_private.h > +++ b/net/bridge/br_private.h > @@ -1178,6 +1178,9 @@ static inline void br_switchdev_frame_unmark(struct > sk_buff *skb) > } > #endif /* CONFIG_NET_SWITCHDEV */ > > +int br_switchdev_port_vlan_add(struct net_device *dev, u16 vid, u16 flags); > +int br_switchdev_port_vlan_del(struct net_device *dev, u16 vid); > + Nope, this actually does need to be in the ifdef block. The whole br_switchdev.c is built conditionally. I'll send v3. Petr ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging:r8188eu: Use lib80211 to encrypt (WEP) tx frames
On Mon, May 28, 2018 at 09:18:21AM +0300, Ivan Safonov wrote:
> Put data to skb, decrypt with lib80211_crypt_wep, and place back to tx buffer.
>
> Signed-off-by: Ivan Safonov
> ---
> drivers/staging/rtl8188eu/core/rtw_security.c | 72
> ---
> 1 file changed, 43 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
> b/drivers/staging/rtl8188eu/core/rtw_security.c
> index bfe0b217e679..80d7569a3108 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_security.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_security.c
> @@ -139,17 +139,11 @@ static __le32 getcrc32(u8 *buf, int len)
> Need to consider the fragment situation
> */
> void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
> -{/* exclude ICV */
> -
> - unsigned char crc[4];
> - struct arc4context mycontext;
> -
> +{
> int curfragnum, length;
> - u32 keylength;
>
> - u8 *pframe, *payload, *iv;/* wepkey */
> - u8 wepkey[16];
> - u8 hw_hdr_offset = 0;
> + u8 *pframe;
> + u8 hw_hdr_offset = 0;
> struct pkt_attrib *pattrib = &((struct xmit_frame
> *)pxmitframe)->attrib;
> struct security_priv *psecuritypriv = &padapter->securitypriv;
> struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
> @@ -165,33 +159,53 @@ void rtw_wep_encrypt(struct adapter *padapter, u8
> *pxmitframe)
>
> /* start to encrypt each fragment */
> if ((pattrib->encrypt == _WEP40_) || (pattrib->encrypt == _WEP104_)) {
> - keylength =
> psecuritypriv->dot11DefKeylen[psecuritypriv->dot11PrivacyKeyIndex];
> + const int keyindex = psecuritypriv->dot11PrivacyKeyIndex;
> + void *crypto_private;
> + struct sk_buff *skb;
> + struct lib80211_crypto_ops *crypto_ops =
> try_then_request_module(lib80211_get_crypto_ops("WEP"), "lib80211_crypt_wep");
> +
> + if (!crypto_ops)
> + goto exit;
> +
> + crypto_private = crypto_ops->init(keyindex);
> + if (!crypto_private)
> + goto exit;
> +
> + if
> (crypto_ops->set_key(psecuritypriv->dot11DefKey[keyindex].skey,
> +
> psecuritypriv->dot11DefKeylen[keyindex], NULL, crypto_private) < 0)
> + goto exit;
>
> for (curfragnum = 0; curfragnum < pattrib->nr_frags;
> curfragnum++) {
> - iv = pframe+pattrib->hdrlen;
> - memcpy(&wepkey[0], iv, 3);
> - memcpy(&wepkey[3],
> &psecuritypriv->dot11DefKey[psecuritypriv->dot11PrivacyKeyIndex].skey[0],
> keylength);
> - payload = pframe+pattrib->iv_len+pattrib->hdrlen;
> + if (curfragnum + 1 == pattrib->nr_frags)
> + length = pattrib->last_txcmdsz;
> + else
> + length = pxmitpriv->frag_len;
> + skb = dev_alloc_skb(length);
> + if (!skb)
> + goto exit;
>
> - if ((curfragnum+1) == pattrib->nr_frags) { /* the
> last fragment */
> - length =
> pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
> + skb_put_data(skb, pframe, length);
>
> - *((__le32 *)crc) = getcrc32(payload, length);
> + memmove(skb->data + 4, skb->data, pattrib->hdrlen);
> + skb_pull(skb, 4);
> + skb_trim(skb, skb->len - 4);
>
> - arcfour_init(&mycontext, wepkey, 3+keylength);
> - arcfour_encrypt(&mycontext, payload, payload,
> length);
> - arcfour_encrypt(&mycontext, payload+length,
> crc, 4);
> - } else {
> - length =
> pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
> - *((__le32 *)crc) = getcrc32(payload, length);
> - arcfour_init(&mycontext, wepkey, 3+keylength);
> - arcfour_encrypt(&mycontext, payload, payload,
> length);
> - arcfour_encrypt(&mycontext, payload+length,
> crc, 4);
> -
> - pframe += pxmitpriv->frag_len;
> - pframe = (u8 *)round_up((size_t)(pframe), 4);
> + if (crypto_ops->encrypt_mpdu(skb, pattrib->hdrlen,
> crypto_private)) {
> + kfree_skb(skb);
> + goto exit;
> }
> +
> + memcpy(pframe, skb->data, skb->len);
> +
> + pframe += skb->len;
> + pframe = (u8 *)round_up((size_t)(pframe), 4);
> +
> +
[PATCH net-next v3 0/7] net: bridge: Notify about bridge VLANs
In commit 946a11e7408e ("mlxsw: spectrum_span: Allow bridge for gretap
mirror"), mlxsw got support for offloading mirror-to-gretap such that
the underlay packet path involves a bridge. In that case, the offload is
also influenced by PVID setting of said bridge. However, changes to VLAN
configuration of the bridge itself do not generate switchdev
notifications, so there's no mechanism to prod mlxsw to update the
offload when these settings change.
In this patchset, the problem is resolved by distributing the switchdev
notification SWITCHDEV_OBJ_ID_PORT_VLAN also for configuration changes
on bridge VLANs. Since stacked devices distribute the notification to
lower devices, such event eventually reaches the driver, which can
determine whether it's a bridge or port VLAN by inspecting orig_dev.
To keep things consistent, the newly-distributed notifications observe
the same protocol as the existing ones: dual prepare/commit, with
-EOPNOTSUPP indicating lack of support, even though there's currently
nothing to prepare for and nothing to support. Correspondingly, all
switchdev drivers have been updated to return -EOPNOTSUPP for bridge
VLAN notifications.
In patch #1, the code to send notifications for adding and deleting is
factored out into two named functions.
In patches #2-#5, respectively for mlxsw, rocker, DSA and DPAA2 ethsw,
the new notifications (which are not enabled yet) are ignored to
maintain the current behavior.
In patch #6, the notification is actually enabled.
In patch #7, mlxsw is changed to update offloads of mirror-to-gre also
for bridge-related notifications.
Changes from v2 to v3:
- Add a fallback definition for br_switchdev_port_obj_add() and
br_switchdev_port_obj_del() when !CONFIG_NET_SWITCHDEV.
Changes from v1 to v2:
- Rename br_switchdev_port_obj_add() and br_switchdev_port_obj_del() to
br_switchdev_port_vlan_add() and br_switchdev_port_vlan_del(), and
move from br_vlan.c to br_switchdev.c.
Petr Machata (7):
net: bridge: Extract boilerplate around switchdev_port_obj_*()
mlxsw: spectrum_switchdev: Ignore bridge VLAN events
rocker: rocker_main: Ignore bridge VLAN events
dsa: port: Ignore bridge VLAN events
staging: fsl-dpaa2: ethsw: Ignore bridge VLAN events
net: bridge: Notify about bridge VLANs
mlxsw: spectrum_switchdev: Schedule respin during trans prepare
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 8 +++-
drivers/net/ethernet/rocker/rocker_main.c | 6 +++
drivers/staging/fsl-dpaa2/ethsw/ethsw.c| 6 +++
net/bridge/br_private.h| 13 +++
net/bridge/br_switchdev.c | 25
net/bridge/br_vlan.c | 45 +-
net/dsa/port.c | 6 +++
7 files changed, 81 insertions(+), 28 deletions(-)
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v3 2/7] mlxsw: spectrum_switchdev: Ignore bridge VLAN events
Ignore VLAN events where the orig_dev is the bridge device itself. Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel --- drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c index 8c9cf8e..cbc8fab 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c @@ -1144,6 +1144,9 @@ static int mlxsw_sp_port_vlans_add(struct mlxsw_sp_port *mlxsw_sp_port, struct mlxsw_sp_bridge_port *bridge_port; u16 vid; + if (netif_is_bridge_master(orig_dev)) + return -EOPNOTSUPP; + if (switchdev_trans_ph_prepare(trans)) return 0; @@ -1741,6 +1744,9 @@ static int mlxsw_sp_port_vlans_del(struct mlxsw_sp_port *mlxsw_sp_port, struct mlxsw_sp_bridge_port *bridge_port; u16 vid; + if (netif_is_bridge_master(orig_dev)) + return -EOPNOTSUPP; + bridge_port = mlxsw_sp_bridge_port_find(mlxsw_sp->bridge, orig_dev); if (WARN_ON(!bridge_port)) return -EINVAL; -- 2.4.11 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v3 1/7] net: bridge: Extract boilerplate around switchdev_port_obj_*()
A call to switchdev_port_obj_add() or switchdev_port_obj_del() involves
initializing a struct switchdev_obj_port_vlan, a piece of code that
repeats on each call site almost verbatim. While in the current codebase
there is just one duplicated add call, the follow-up patches add more of
both add and del calls.
Thus to remove the duplication, extract the repetition into named
functions and reuse.
Signed-off-by: Petr Machata
---
net/bridge/br_private.h | 13 +
net/bridge/br_switchdev.c | 25 +
net/bridge/br_vlan.c | 31 ---
3 files changed, 42 insertions(+), 27 deletions(-)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 11520ed..5216a52 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -1139,6 +1139,8 @@ int br_switchdev_set_port_flag(struct net_bridge_port *p,
unsigned long mask);
void br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb,
int type);
+int br_switchdev_port_vlan_add(struct net_device *dev, u16 vid, u16 flags);
+int br_switchdev_port_vlan_del(struct net_device *dev, u16 vid);
static inline void br_switchdev_frame_unmark(struct sk_buff *skb)
{
@@ -1168,6 +1170,17 @@ static inline int br_switchdev_set_port_flag(struct
net_bridge_port *p,
return 0;
}
+static inline int br_switchdev_port_vlan_add(struct net_device *dev,
+u16 vid, u16 flags)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int br_switchdev_port_vlan_del(struct net_device *dev, u16 vid)
+{
+ return -EOPNOTSUPP;
+}
+
static inline void
br_switchdev_fdb_notify(const struct net_bridge_fdb_entry *fdb, int type)
{
diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
index 35474d4..d77f807 100644
--- a/net/bridge/br_switchdev.c
+++ b/net/bridge/br_switchdev.c
@@ -136,3 +136,28 @@ br_switchdev_fdb_notify(const struct net_bridge_fdb_entry
*fdb, int type)
break;
}
}
+
+int br_switchdev_port_vlan_add(struct net_device *dev, u16 vid, u16 flags)
+{
+ struct switchdev_obj_port_vlan v = {
+ .obj.orig_dev = dev,
+ .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
+ .flags = flags,
+ .vid_begin = vid,
+ .vid_end = vid,
+ };
+
+ return switchdev_port_obj_add(dev, &v.obj);
+}
+
+int br_switchdev_port_vlan_del(struct net_device *dev, u16 vid)
+{
+ struct switchdev_obj_port_vlan v = {
+ .obj.orig_dev = dev,
+ .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
+ .vid_begin = vid,
+ .vid_end = vid,
+ };
+
+ return switchdev_port_obj_del(dev, &v.obj);
+}
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index dc832c09..8ad5756 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -82,19 +82,10 @@ static bool __vlan_add_flags(struct net_bridge_vlan *v, u16
flags)
static int __vlan_vid_add(struct net_device *dev, struct net_bridge *br,
u16 vid, u16 flags)
{
- struct switchdev_obj_port_vlan v = {
- .obj.orig_dev = dev,
- .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
- .flags = flags,
- .vid_begin = vid,
- .vid_end = vid,
- };
- int err;
-
/* Try switchdev op first. In case it is not supported, fallback to
* 8021q add.
*/
- err = switchdev_port_obj_add(dev, &v.obj);
+ int err = br_switchdev_port_vlan_add(dev, vid, flags);
if (err == -EOPNOTSUPP)
return vlan_vid_add(dev, br->vlan_proto, vid);
return err;
@@ -130,18 +121,11 @@ static void __vlan_del_list(struct net_bridge_vlan *v)
static int __vlan_vid_del(struct net_device *dev, struct net_bridge *br,
u16 vid)
{
- struct switchdev_obj_port_vlan v = {
- .obj.orig_dev = dev,
- .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
- .vid_begin = vid,
- .vid_end = vid,
- };
- int err;
-
/* Try switchdev op first. In case it is not supported, fallback to
* 8021q del.
*/
- err = switchdev_port_obj_del(dev, &v.obj);
+ int err = br_switchdev_port_vlan_del(dev, vid);
+
if (err == -EOPNOTSUPP) {
vlan_vid_del(dev, br->vlan_proto, vid);
return 0;
@@ -1053,13 +1037,6 @@ int nbp_vlan_init(struct net_bridge_port *p)
int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags,
bool *changed)
{
- struct switchdev_obj_port_vlan v = {
- .obj.orig_dev = port->dev,
- .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
- .flags = flags,
- .vid_begin = vid,
- .vid_end = vid,
- };
struct net_bridge_vlan *vlan;
int ret;
@@ -1069,7 +1046,7 @@ int
[PATCH net-next v3 7/7] mlxsw: spectrum_switchdev: Schedule respin during trans prepare
Since there's no special support for the bridge events, the driver
returns -EOPNOTSUPP, and thus the commit never happens. Therefore
schedule respin during the prepare stage: there's no real difference one
way or another.
This fixes the problem that mirror-to-gretap offload wouldn't adapt to
changes in bridge vlan configuration right away and another notification
would have to arrive for mlxsw to catch up.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index cbc8fab..8a15ac4 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -1697,7 +1697,7 @@ static int mlxsw_sp_port_obj_add(struct net_device *dev,
vlan = SWITCHDEV_OBJ_PORT_VLAN(obj);
err = mlxsw_sp_port_vlans_add(mlxsw_sp_port, vlan, trans);
- if (switchdev_trans_ph_commit(trans)) {
+ if (switchdev_trans_ph_prepare(trans)) {
/* The event is emitted before the changes are actually
* applied to the bridge. Therefore schedule the respin
* call for later, so that the respin logic sees the
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v3 6/7] net: bridge: Notify about bridge VLANs
A driver might need to react to changes in settings of brentry VLANs.
Therefore send switchdev port notifications for these as well. Reuse
SWITCHDEV_OBJ_ID_PORT_VLAN for this purpose. Listeners should use
netif_is_bridge_master() on orig_dev to determine whether the
notification is about a bridge port or a bridge.
Signed-off-by: Petr Machata
Reviewed-by: Florian Fainelli
Reviewed-by: Vivien Didelot
Reviewed-by: Nikolay Aleksandrov
Tested-by: Florian Fainelli
---
net/bridge/br_vlan.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 8ad5756..b15ef3f 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -243,6 +243,10 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
goto out_filt;
v->brvlan = masterv;
v->stats = masterv->stats;
+ } else {
+ err = br_switchdev_port_vlan_add(dev, v->vid, flags);
+ if (err && err != -EOPNOTSUPP)
+ goto out;
}
/* Add the dev mac and count the vlan only if it's usable */
@@ -278,6 +282,8 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
br_vlan_put_master(masterv);
v->brvlan = NULL;
}
+ } else {
+ br_switchdev_port_vlan_del(dev, v->vid);
}
goto out;
@@ -303,6 +309,11 @@ static int __vlan_del(struct net_bridge_vlan *v)
err = __vlan_vid_del(p->dev, p->br, v->vid);
if (err)
goto out;
+ } else {
+ err = br_switchdev_port_vlan_del(v->br->dev, v->vid);
+ if (err && err != -EOPNOTSUPP)
+ goto out;
+ err = 0;
}
if (br_vlan_should_use(v)) {
@@ -580,6 +591,9 @@ int br_vlan_add(struct net_bridge *br, u16 vid, u16 flags,
bool *changed)
vg->num_vlans++;
*changed = true;
}
+ ret = br_switchdev_port_vlan_add(br->dev, vid, flags);
+ if (ret && ret != -EOPNOTSUPP)
+ return ret;
if (__vlan_add_flags(vlan, flags))
*changed = true;
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v3 5/7] staging: fsl-dpaa2: ethsw: Ignore bridge VLAN events
Ignore VLAN events where the orig_dev is the bridge device itself.
Signed-off-by: Petr Machata
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index c723a04..a17dd29 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -719,6 +719,9 @@ static int port_vlans_add(struct net_device *netdev,
struct ethsw_port_priv *port_priv = netdev_priv(netdev);
int vid, err;
+ if (netif_is_bridge_master(vlan->obj.orig_dev))
+ return -EOPNOTSUPP;
+
if (switchdev_trans_ph_prepare(trans))
return 0;
@@ -873,6 +876,9 @@ static int port_vlans_del(struct net_device *netdev,
struct ethsw_port_priv *port_priv = netdev_priv(netdev);
int vid, err;
+ if (netif_is_bridge_master(vlan->obj.orig_dev))
+ return -EOPNOTSUPP;
+
for (vid = vlan->vid_begin; vid <= vlan->vid_end; vid++) {
err = ethsw_port_del_vlan(port_priv, vid);
if (err)
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v3 3/7] rocker: rocker_main: Ignore bridge VLAN events
Ignore VLAN events where the orig_dev is the bridge device itself.
Signed-off-by: Petr Machata
---
drivers/net/ethernet/rocker/rocker_main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/rocker/rocker_main.c
b/drivers/net/ethernet/rocker/rocker_main.c
index e73e4fe..aeafdb9 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -1632,6 +1632,9 @@ rocker_world_port_obj_vlan_add(struct rocker_port
*rocker_port,
{
struct rocker_world_ops *wops = rocker_port->rocker->wops;
+ if (netif_is_bridge_master(vlan->obj.orig_dev))
+ return -EOPNOTSUPP;
+
if (!wops->port_obj_vlan_add)
return -EOPNOTSUPP;
@@ -1647,6 +1650,9 @@ rocker_world_port_obj_vlan_del(struct rocker_port
*rocker_port,
{
struct rocker_world_ops *wops = rocker_port->rocker->wops;
+ if (netif_is_bridge_master(vlan->obj.orig_dev))
+ return -EOPNOTSUPP;
+
if (!wops->port_obj_vlan_del)
return -EOPNOTSUPP;
return wops->port_obj_vlan_del(rocker_port, vlan);
--
2.4.11
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next v3 4/7] dsa: port: Ignore bridge VLAN events
Ignore VLAN events where the orig_dev is the bridge device itself. Signed-off-by: Petr Machata Reviewed-by: Vivien Didelot --- net/dsa/port.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/net/dsa/port.c b/net/dsa/port.c index 2413beb..ed05954 100644 --- a/net/dsa/port.c +++ b/net/dsa/port.c @@ -252,6 +252,9 @@ int dsa_port_vlan_add(struct dsa_port *dp, .vlan = vlan, }; + if (netif_is_bridge_master(vlan->obj.orig_dev)) + return -EOPNOTSUPP; + if (br_vlan_enabled(dp->bridge_dev)) return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info); @@ -267,6 +270,9 @@ int dsa_port_vlan_del(struct dsa_port *dp, .vlan = vlan, }; + if (netif_is_bridge_master(vlan->obj.orig_dev)) + return -EOPNOTSUPP; + if (br_vlan_enabled(dp->bridge_dev)) return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info); -- 2.4.11 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
On Fri, May 25, 2018 at 05:32:52PM -0700, Greg Thelen wrote:
> On Fri, May 25, 2018 at 2:32 PM Arnd Bergmann wrote:
>
> > Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
> > on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> > link error when another driver using it is built-in. The
> > INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
> > a 'bool' symbol that does not force anything to be a module in turn.
>
> > fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> > smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> > net/9p/trans_rdma.o: In function `rdma_request':
> > trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> > net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> > trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> > trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
>
> > Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig
> dependencies")
> > Signed-off-by: Arnd Bergmann
>
> Acked-by: Greg Thelen
>
> Sorry for the 9533b292a7ac problem.
> At this point the in release cycle, I think Arnd's revert is best.
>
> If there is interest, I've put a little thought into an alternative fix:
> making INFINIBAND_ADDR_TRANS tristate. But it's nontrivial.
> So I prefer this simple revert for now.
Is that a normal thing to do?
> Doug: do you need anything from me on this?
I can take the revert..
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
On Fri, May 25, 2018 at 11:29:59PM +0200, Arnd Bergmann wrote:
> Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
> on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> link error when another driver using it is built-in. The
> INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
> a 'bool' symbol that does not force anything to be a module in turn.
>
> fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_request':
> trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
>
> Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig dependencies")
> Signed-off-by: Arnd Bergmann
> Acked-by: Greg Thelen
> ---
> The patch that introduced the problem has been queued in the
> rdma-fixes/for-rc tree. Please revert the patch before sending
> the branch to Linus.
> ---
> drivers/infiniband/ulp/srpt/Kconfig | 2 +-
> drivers/nvme/host/Kconfig | 2 +-
> drivers/nvme/target/Kconfig | 2 +-
> drivers/staging/lustre/lnet/Kconfig | 2 +-
> fs/cifs/Kconfig | 2 +-
> net/9p/Kconfig | 2 +-
> net/rds/Kconfig | 2 +-
> net/sunrpc/Kconfig | 2 +-
> 8 files changed, 8 insertions(+), 8 deletions(-)
Applied to for-rc, thanks
Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
Jason Gunthorpe wrote:
On Fri, May 25, 2018 at 05:32:52PM -0700, Greg Thelen wrote:
On Fri, May 25, 2018 at 2:32 PM Arnd Bergmann wrote:
> Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn
depends
> on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> link error when another driver using it is built-in. The
> INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
> a 'bool' symbol that does not force anything to be a module in turn.
> fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_request':
> trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
> Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig
dependencies")
> Signed-off-by: Arnd Bergmann
Acked-by: Greg Thelen
Sorry for the 9533b292a7ac problem.
At this point the in release cycle, I think Arnd's revert is best.
If there is interest, I've put a little thought into an alternative fix:
making INFINIBAND_ADDR_TRANS tristate. But it's nontrivial.
So I prefer this simple revert for now.
Is that a normal thing to do?
For me: no, it's not normal. In my use case I merely want to disable
INFINIBAND_ADDR_TRANS while continuing to use INFINIBAND. This is
supported with f7cb7b85be55 ("IB: make INFINIBAND_ADDR_TRANS
configurable").
During f7cb7b85be55 development https://lkml.org/lkml/2018/4/30/1073
suggested that we drop dependency on both INFINIBAND and
INFINIBAND_ADDR_TRANS. Thus 9533b292a7ac ("IB: remove redundant
INFINIBAND kconfig dependencies").
But 9533b292a7ac led to the randconfig build errors reported and thus
("IB: Revert "remove redundant INFINIBAND kconfig dependencies"").
So I see no need to do anything more than apply ("IB: Revert "remove
redundant INFINIBAND kconfig dependencies"").
Doug: do you need anything from me on this?
I can take the revert..
Jason
Thanks.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: speakup: remove simple_strtoul()
Hi Gabriel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.17-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Gabriel-Fedel/staging-speakup-remove-simple_strtoul/20180528-231304
coccinelle warnings: (new ones prefixed by >>)
>> drivers/staging/speakup/kobjects.c:163:2-5: alloc with no test, possible
>> model on line 146
drivers/staging/speakup/kobjects.c:163:2-5: alloc with no test, possible
model on line 185
drivers/staging/speakup/kobjects.c:809:2-5: alloc with no test, possible
model on line 791
vim +163 drivers/staging/speakup/kobjects.c
105
106 /*
107 * This is called when a user changes the characters or chartab
parameters.
108 */
109 static ssize_t chars_chartab_store(struct kobject *kobj,
110 struct kobj_attribute *attr,
111 const char *buf, size_t count)
112 {
113 char *cp = (char *)buf;
114 char *end = cp + count; /* the null at the end of the buffer */
115 char *linefeed = NULL;
116 char keyword[MAX_DESC_LEN + 1];
117 char *outptr = NULL;/* Will hold keyword or desc. */
118 char *temp = NULL;
119 char *desc = NULL;
120 char *num = NULL; /* The number part of cp */
121 ssize_t retval = count;
122 unsigned long flags;
123 unsigned long index = 0;
124 int charclass = 0;
125 int received = 0;
126 int used = 0;
127 int rejected = 0;
128 int reset = 0;
129 int do_characters = !strcmp(attr->attr.name, "characters");
130 size_t desc_length = 0;
131 int i;
132
133 spin_lock_irqsave(&speakup_info.spinlock, flags);
134 while (cp < end) {
135 while ((cp < end) && (*cp == ' ' || *cp == '\t'))
136 cp++;
137
138 if (cp == end)
139 break;
140 if ((*cp == '\n') || strchr("dDrR", *cp)) {
141 reset = 1;
142 break;
143 }
144 received++;
145
> 146 linefeed = strchr(cp, '\n');
147 if (!linefeed) {
148 rejected++;
149 break;
150 }
151
152 if (!isdigit(*cp)) {
153 rejected++;
154 cp = linefeed + 1;
155 continue;
156 }
157
158 i = 0;
159 while (isdigit(*(cp + i)))
160 i = i + 1;
161 temp = cp + i;
162
> 163 num = kmalloc(i + 2, GFP_ATOMIC);
164 strscpy(num, cp, i + 1);
165
166 if (kstrtoul(num, 10, &index) != 0)
167 pr_warn("overflow or parsing error has
occurred");
168
169 if (index > 255) {
170 rejected++;
171 cp = linefeed + 1;
172 continue;
173 }
174
175 while ((temp < linefeed) && (*temp == ' ' || *temp ==
'\t'))
176 temp++;
177
178 desc_length = linefeed - temp;
179 if (desc_length > MAX_DESC_LEN) {
180 rejected++;
181 cp = linefeed + 1;
182 continue;
183 }
184 if (do_characters) {
185 desc = kmalloc(desc_length + 1, GFP_ATOMIC);
186 if (!desc) {
187 retval = -ENOMEM;
188 reset = 1; /* just reset on error.
*/
189 break;
190 }
191 outptr = desc;
192 } else {
193 outptr = keyword;
194 }
195
196 for (i = 0; i < desc_length; i++)
197 outptr[i] = temp[i];
198 outptr[desc_length] = '\0';
199
200 if (do_characters) {
201 if (spk_characters[index] !=
spk_default_chars[index])
RE: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared
> > Before the guest finishes the device initialization, the device can be > removed anytime by the host, and after that the host won't respond to > the guest's request, so the guest should be prepared to handle this > case. > > Signed-off-by: Dexuan Cui > Cc: Stephen Hemminger > Cc: K. Y. Srinivasan > --- > drivers/pci/host/pci-hyperv.c | 46 > --- > 1 file changed, 34 insertions(+), 12 deletions(-) > While this patch solves the immediate problem of getting hung waiting for a response from Hyper-V that will never come, there's another scenario to look at that I think introduces a race. Suppose the guest VM issues a vmbus_sendpacket() request in one of the cases covered by this patch, and suppose that Hyper-V queues a response to the request, and then immediately follows with a rescind request. Processing the response will get queued to a tasklet associated with the channel, while processing the rescind will get queued to a tasklet associated with the top-level vmbus connection. From what I can see, the code doesn't impose any ordering on processing the two. If the rescind is processed first, the new wait_for_response() function may wake up, notice the rescind flag, and return an error. Its caller will return an error, and in doing so pop the completion packet off the stack. When the response is processed later, it will try to signal completion via a completion packet that no longer exists, and memory corruption will likely occur. Am I missing anything that would prevent this scenario from happening? It is admittedly low probability, and a solution seems non-trivial. I haven't looked specifically, but a similar scenario is probably possible with the drivers for other VMbus devices. We should work on a generic solution. Michael ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/6] staging: mt7621-gpio: change gc_map to don't use pointers
There is no special gain in using pointers for 'gc_map' inside
'mtk_data' structure. We know the number of banks which is fixed
to MTK_BANK_CNT and we can just statically allocate them without
using kernel allocators.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index e31ed67..0ae6082 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -45,7 +45,7 @@ struct mtk_data {
void __iomem *gpio_membase;
int gpio_irq;
struct irq_domain *gpio_irq_domain;
- struct mtk_gc *gc_map[MTK_BANK_CNT];
+ struct mtk_gc gc_map[MTK_BANK_CNT];
};
static inline struct mtk_gc *
@@ -152,11 +152,8 @@ mediatek_gpio_bank_probe(struct platform_device *pdev,
struct device_node *bank)
if (!id || be32_to_cpu(*id) >= MTK_BANK_CNT)
return -EINVAL;
- rg = devm_kzalloc(&pdev->dev, sizeof(struct mtk_gc), GFP_KERNEL);
- if (!rg)
- return -ENOMEM;
-
- gpio_data->gc_map[be32_to_cpu(*id)] = rg;
+ rg = &gpio_data->gc_map[be32_to_cpu(*id)];
+ memset(rg, 0, sizeof(*rg));
spin_lock_init(&rg->lock);
@@ -196,7 +193,7 @@ mediatek_gpio_irq_handler(struct irq_desc *desc)
int i;
for (i = 0; i < MTK_BANK_CNT; i++) {
- struct mtk_gc *rg = gpio_data->gc_map[i];
+ struct mtk_gc *rg = &gpio_data->gc_map[i];
unsigned long pending;
int bit;
@@ -221,7 +218,7 @@ mediatek_gpio_irq_unmask(struct irq_data *d)
struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
int pin = d->hwirq;
int bank = pin / MTK_BANK_WIDTH;
- struct mtk_gc *rg = gpio_data->gc_map[bank];
+ struct mtk_gc *rg = &gpio_data->gc_map[bank];
unsigned long flags;
u32 rise, fall;
@@ -242,7 +239,7 @@ mediatek_gpio_irq_mask(struct irq_data *d)
struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
int pin = d->hwirq;
int bank = pin / MTK_BANK_WIDTH;
- struct mtk_gc *rg = gpio_data->gc_map[bank];
+ struct mtk_gc *rg = &gpio_data->gc_map[bank];
unsigned long flags;
u32 rise, fall;
@@ -263,7 +260,7 @@ mediatek_gpio_irq_type(struct irq_data *d, unsigned int
type)
struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
int pin = d->hwirq;
int bank = pin / MTK_BANK_WIDTH;
- struct mtk_gc *rg = gpio_data->gc_map[bank];
+ struct mtk_gc *rg = &gpio_data->gc_map[bank];
u32 mask = PIN_MASK(pin);
if (!rg)
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/6] staging: mt7621-gpio: last cleanups
The following series performs last cleanups pointed out in this mail by NeilBrown: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-May/121282.html If this is ok and after testing this driver should be ready to go out of staging. Please, note that this has to eb applied after previous series which are before in this mail thread. Hope this helps. Best regards, Sergio Paracuellos Sergio Paracuellos (6): staging: mt7621-dts: fix property #interrupt-cells for the gpio node staging: mt7621-gpio: dt-bindings: update documentation for #interrupt-cells property staging: mt7621-gpio: change 'to_mediatek_gpio' to make just a one line return staging: mt7621-gpio: use GPIOF_DIR_OUT and GPIOF_DIR_IN macros instead of custom values staging: mt7621-gpio: change gc_map to don't use pointers staging: mt7621-gpio: reorder includes alphabetically drivers/staging/mt7621-dts/mt7621.dtsi | 2 +- drivers/staging/mt7621-gpio/gpio-mt7621.c | 38 +- .../staging/mt7621-gpio/mediatek,mt7621-gpio.txt | 10 -- 3 files changed, 25 insertions(+), 25 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/6] staging: mt7621-gpio: change 'to_mediatek_gpio' to make just a one line return
Function to_mediatek_gpio can directly return without declaring
anything else in its body improving readability. Also change
pointer '*' declaration to be with return type in the upper line.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index c96ae67..9132963 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -47,14 +47,10 @@ struct mtk_data {
struct mtk_gc *gc_map[MTK_BANK_CNT];
};
-static inline struct mtk_gc
-*to_mediatek_gpio(struct gpio_chip *chip)
+static inline struct mtk_gc *
+to_mediatek_gpio(struct gpio_chip *chip)
{
- struct mtk_gc *mgc;
-
- mgc = container_of(chip, struct mtk_gc, chip);
-
- return mgc;
+ return container_of(chip, struct mtk_gc, chip);
}
static inline void
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/6] staging: mt7621-gpio: dt-bindings: update documentation for #interrupt-cells property
This commit update documentation for #interrupt-cells property in
the gpio node which has been changed from '1' to '2'.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt
b/drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt
index 94caba7..30d8a02 100644
--- a/drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt
+++ b/drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt
@@ -15,7 +15,13 @@ Required properties for the top level node:
- interrupt-parent : phandle of the parent interrupt controller.
- interrupts : Interrupt specifier for the controllers interrupt.
- interrupt-controller : Mark the device node as an interrupt controller.
-- #interrupt-cells : Should be 1. The first cell is the GPIO number.
+- #interrupt-cells : Should be 2. The first cell defines the interrupt number.
+ The second cell bits[3:0] is used to specify trigger type as follows:
+ - 1 = low-to-high edge triggered.
+ - 2 = high-to-low edge triggered.
+ - 4 = active high level-sensitive.
+ - 8 = active low level-sensitive.
+
Required properties for the GPIO bank node:
- compatible:
@@ -37,7 +43,7 @@ Example:
interrupt-parent = <&gic>;
interrupts = ;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
gpio0: bank@0 {
reg = <0>;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/6] staging: mt7621-gpio: reorder includes alphabetically
This commit reviews driver includes reordering them in alphabetic order. This improves readability. Signed-off-by: Sergio Paracuellos --- drivers/staging/mt7621-gpio/gpio-mt7621.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c b/drivers/staging/mt7621-gpio/gpio-mt7621.c index 0ae6082..7884b3c 100644 --- a/drivers/staging/mt7621-gpio/gpio-mt7621.c +++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c @@ -4,16 +4,16 @@ * Copyright (C) 2013 John Crispin */ -#include #include #include #include +#include +#include +#include #include #include -#include -#include -#include #include +#include #define MTK_BANK_CNT 3 #define MTK_BANK_WIDTH 32 -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/6] staging: mt7621-gpio: use GPIOF_DIR_OUT and GPIOF_DIR_IN macros instead of custom values
There are macros in gpio kernel's headers to define direction of a gpio. Use them instead of return custom '0' and '1' values. Signed-off-by: Sergio Paracuellos --- drivers/staging/mt7621-gpio/gpio-mt7621.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c b/drivers/staging/mt7621-gpio/gpio-mt7621.c index 9132963..e31ed67 100644 --- a/drivers/staging/mt7621-gpio/gpio-mt7621.c +++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c @@ -6,6 +6,7 @@ #include #include +#include #include #include #include @@ -127,7 +128,7 @@ mediatek_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) struct mtk_gc *rg = to_mediatek_gpio(chip); u32 t = mtk_gpio_r32(rg, GPIO_REG_CTRL); - return (t & BIT(offset)) ? 0 : 1; + return (t & BIT(offset)) ? GPIOF_DIR_OUT : GPIOF_DIR_IN; } static int -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/6] staging: mt7621-dts: fix property #interrupt-cells for the gpio node
Most gpio chips have two cells for interrupts and this should be also.
Set this property accordly fixing this up.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index d7e4981..bce6029 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -70,7 +70,7 @@
interrupt-parent = <&gic>;
interrupts = ;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
gpio0: bank@0 {
reg = <0>;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] media: staging: tegra-vde: Reset memory client
Hi Dmitry,
On 05/26/2018 04:27 PM, Dmitry Osipenko wrote:
> DMA requests must be blocked before resetting VDE HW, otherwise it is
> possible to get a memory corruption or a machine hang. Use the reset
> control provided by the Memory Controller to block DMA before resetting
> the VDE HW.
>
> Signed-off-by: Dmitry Osipenko
> ---
>
> Changelog:
>
> v2:
> - Reset HW even if Memory Client resetting fails.
Please note that v1 has already been merged, so if you can make a v3 rebased
on top of the latest media_tree master branch, then I'll queue that up for
4.18.
Regards,
Hans
>
> drivers/staging/media/tegra-vde/tegra-vde.c | 35 +++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/tegra-vde/tegra-vde.c
> b/drivers/staging/media/tegra-vde/tegra-vde.c
> index 90177a59b97c..6f06061a40d9 100644
> --- a/drivers/staging/media/tegra-vde/tegra-vde.c
> +++ b/drivers/staging/media/tegra-vde/tegra-vde.c
> @@ -73,6 +73,7 @@ struct tegra_vde {
> struct mutex lock;
> struct miscdevice miscdev;
> struct reset_control *rst;
> + struct reset_control *rst_mc;
> struct gen_pool *iram_pool;
> struct completion decode_completion;
> struct clk *clk;
> @@ -850,9 +851,23 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
> *vde,
>* We rely on the VDE registers reset value, otherwise VDE
>* causes bus lockup.
>*/
> + ret = reset_control_assert(vde->rst_mc);
> + if (ret) {
> + dev_err(dev, "DEC start: Failed to assert MC reset: %d\n",
> + ret);
> + goto put_runtime_pm;
> + }
> +
> ret = reset_control_reset(vde->rst);
> if (ret) {
> - dev_err(dev, "Failed to reset HW: %d\n", ret);
> + dev_err(dev, "DEC start: Failed to reset HW: %d\n", ret);
> + goto put_runtime_pm;
> + }
> +
> + ret = reset_control_deassert(vde->rst_mc);
> + if (ret) {
> + dev_err(dev, "DEC start: Failed to deassert MC reset: %d\n",
> + ret);
> goto put_runtime_pm;
> }
>
> @@ -880,9 +895,18 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
> *vde,
> ret = timeout;
> }
>
> + /*
> + * At first reset memory client to avoid resetting VDE HW in the
> + * middle of DMA which could result into memory corruption or hang
> + * the whole system.
> + */
> + err = reset_control_assert(vde->rst_mc);
> + if (err)
> + dev_err(dev, "DEC end: Failed to assert MC reset: %d\n", err);
> +
> err = reset_control_assert(vde->rst);
> if (err)
> - dev_err(dev, "Failed to assert HW reset: %d\n", err);
> + dev_err(dev, "DEC end: Failed to assert HW reset: %d\n", err);
>
> put_runtime_pm:
> pm_runtime_mark_last_busy(dev);
> @@ -1074,6 +1098,13 @@ static int tegra_vde_probe(struct platform_device
> *pdev)
> return err;
> }
>
> + vde->rst_mc = devm_reset_control_get_optional(dev, "mc");
> + if (IS_ERR(vde->rst_mc)) {
> + err = PTR_ERR(vde->rst_mc);
> + dev_err(dev, "Could not get MC reset %d\n", err);
> + return err;
> + }
> +
> irq = platform_get_irq_byname(pdev, "sync-token");
> if (irq < 0)
> return irq;
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
