* Re: [PATCH v6 1/8] SUNRPC: introduce helpers for reference counted rpcbind clients
From: Stanislav Kinsbursky @ 2011-09-23 14:41 UTC (permalink / raw)
To: Trond.Myklebust@netapp.com
Cc: linux-nfs@vger.kernel.org, Pavel Emelianov, neilb@suse.de,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bfields@fieldses.org, davem@davemloft.net
In-Reply-To: <4E79A95F.8050304@parallels.com>
Trond, is this patch version suits you now? Or not?
Please, comment somehow to let me know, may I proceed with further development
or not.
Sorry for disturbing (if so).
21.09.2011 13:07, Stanislav Kinsbursky пишет:
> v6:
> 1) added write memory barrier to rpcb_set_local to make sure, that rpcbind
> clients become valid before rpcb_users assignment
> 2) explicitly set rpcb_users to 1 instead of incrementing it (looks clearer from
> my pow).
>
> Notice: write memory barrier after zeroing rpcbind clients in rpcb_put_local()
> is not required, since to users of them left. New user (service) will create new
> clients before dereferencing them.
>
> This helpers will be used for dynamical creation and destruction of rpcbind
> clients.
> Variable rpcb_users is actually a counter of lauched RPC services. If rpcbind
> clients has been created already, then we just increase rpcb_users.
>
> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>
> ---
> net/sunrpc/rpcb_clnt.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 54 insertions(+), 0 deletions(-)
>
> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
> index e45d2fb..9fcdb42 100644
> --- a/net/sunrpc/rpcb_clnt.c
> +++ b/net/sunrpc/rpcb_clnt.c
> @@ -114,6 +114,9 @@ static struct rpc_program rpcb_program;
> static struct rpc_clnt * rpcb_local_clnt;
> static struct rpc_clnt * rpcb_local_clnt4;
>
> +DEFINE_SPINLOCK(rpcb_clnt_lock);
> +unsigned int rpcb_users;
> +
> struct rpcbind_args {
> struct rpc_xprt * r_xprt;
>
> @@ -161,6 +164,57 @@ static void rpcb_map_release(void *data)
> kfree(map);
> }
>
> +static int rpcb_get_local(void)
> +{
> + int cnt;
> +
> + spin_lock(&rpcb_clnt_lock);
> + if (rpcb_users)
> + rpcb_users++;
> + cnt = rpcb_users;
> + spin_unlock(&rpcb_clnt_lock);
> +
> + return cnt;
> +}
> +
> +void rpcb_put_local(void)
> +{
> + struct rpc_clnt *clnt = rpcb_local_clnt;
> + struct rpc_clnt *clnt4 = rpcb_local_clnt4;
> + int shutdown;
> +
> + spin_lock(&rpcb_clnt_lock);
> + if (--rpcb_users == 0) {
> + rpcb_local_clnt = NULL;
> + rpcb_local_clnt4 = NULL;
> + }
> + shutdown = !rpcb_users;
> + spin_unlock(&rpcb_clnt_lock);
> +
> + if (shutdown) {
> + /*
> + * cleanup_rpcb_clnt - remove xprtsock's sysctls, unregister
> + */
> + if (clnt4)
> + rpc_shutdown_client(clnt4);
> + if (clnt)
> + rpc_shutdown_client(clnt);
> + }
> + return;
> +}
> +
> +static void rpcb_set_local(struct rpc_clnt *clnt, struct rpc_clnt *clnt4)
> +{
> + /* Protected by rpcb_create_local_mutex */
> + rpcb_local_clnt = clnt;
> + rpcb_local_clnt4 = clnt4;
> + smp_wmb();
> + rpcb_users = 1;
> + dprintk("RPC: created new rpcb local clients (rpcb_local_clnt: "
> + "%p, rpcb_local_clnt4: %p)\n", rpcb_local_clnt,
> + rpcb_local_clnt4);
> +}
> +
> /*
> * Returns zero on success, otherwise a negative errno value
> * is returned.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re:
From: BBC Online @ 2011-09-23 12:21 UTC (permalink / raw)
£800,000 has been awarded to you in the BBC Online,send Name/Tel/Country
^ permalink raw reply
* hi...
From: Mrs. Xue Chong @ 2011-09-23 13:16 UTC (permalink / raw)
Is your email valid ? join me for a personal discussion
^ permalink raw reply
* Re: Introducing open source MSTP daemon
From: Vitalii Demianets @ 2011-09-23 13:13 UTC (permalink / raw)
To: David Lamparter; +Cc: bridge, netdev, Srinivas M.A., Stephen Hemminger
In-Reply-To: <20110923123058.GD1012103@jupiter.n2.diac24.net>
On Friday 23 September 2011 15:30:58 David Lamparter wrote:
> On Fri, Sep 23, 2011 at 10:36:04AM +0300, Vitalii Demianets wrote:
> > I suppose these questions are not related to kernel development so I
> > suggest to continue discussion on above topics at the project discussion
> > board: http://sourceforge.net/p/mstpd/discussion/
>
> That's a forum - I'm afraid that's not quite a good communication
> channel for software development feedback. A "normal" software developer
> probably has 10, 20, 30... packages he follows around; if each of them
> was using a separate discussion forum, the developer would have to check
> 30 forums regularly, in hir browser.
>
> A mailing list delivers all of that discussion to the developer's
> mailbox where it's very easy to sort, follow & respond. Considering the
> probably rather low traffic, an existing list might even do it.
>
Ok, as long as there is no objection from other list participants, let's
continue in netdev list.
> > > I assume it works with current Linux kernel bridge code on a RSTP
> > > level? The code looks considerably more maintainable than rstpd :) - I
> > > will try running it later!
> >
> > Sorry, at the moment function MSTP_OUT_set_state() does nothing except
> > logging. But it is valueable thought: although MSTI states do not have
> > meaning to the kernel bridge code, CIST states can be used to control
> > bridge slave states, so mstpd can replace rstpd as more generic (and
> > conforming to more recent standard).
>
> Well, with the current kernel code you can basically support MSTP setups
> where all VLANs are mapped to one MSTI, since there's just one port
> state for all VLANs. As far as I can tell, that doesn't need to be
> the CIST/instance 0, as long as it's the same for all VLANs.
>
Theoretically, yes. But if the user have bothered to change default config and
assign all the VLANs to some MSTI, he obviously wants to do something
MST-related. Maybe she is just in the middle of the configuration process and
in some time he'll add some VLANs to another MSTI?
I'd prefer to keep it simple, and translating CIST states to the kernel bridge
(and all MSTI states to another driver) seems simple enough to me. And this
approach will also work in the cases when mstpd chooses (R)STP mode of
operation instead of MSTP, e.g. auto-sensing STP-only neighbors.
> > Anyways, the code is basically untested. It compiles and runs in my
> > setup, that's all for now. But I somehow have gut feeling that the code
> > is mature enough to be put for the community consideration.
>
> Well, "the community" is usually happy when you continually maintain and
> improve your code - one-shot code publications ("fire & forget") happen
> all too often and are forgotten quickly...
>
Understandable enough :)
So for now I'll focus on the (R)STP case and add code which will translate
CIST states to the kernel bridge. Then the code can be really evaluated (at
least for the (R)STP cases), not only reviewed.
--
Vitalii Demianets
^ permalink raw reply
* Re: Introducing open source MSTP daemon
From: David Lamparter @ 2011-09-23 12:30 UTC (permalink / raw)
To: Vitalii Demianets
Cc: David Lamparter, bridge, netdev, Srinivas M.A., Stephen Hemminger
In-Reply-To: <201109231036.05039.vitas@nppfactor.kiev.ua>
On Fri, Sep 23, 2011 at 10:36:04AM +0300, Vitalii Demianets wrote:
> I suppose these questions are not related to kernel development so I suggest
> to continue discussion on above topics at the project discussion board:
> http://sourceforge.net/p/mstpd/discussion/
That's a forum - I'm afraid that's not quite a good communication
channel for software development feedback. A "normal" software developer
probably has 10, 20, 30... packages he follows around; if each of them
was using a separate discussion forum, the developer would have to check
30 forums regularly, in hir browser.
A mailing list delivers all of that discussion to the developer's
mailbox where it's very easy to sort, follow & respond. Considering the
probably rather low traffic, an existing list might even do it.
> > I assume it works with current Linux kernel bridge code on a RSTP level?
> > The code looks considerably more maintainable than rstpd :) - I will try
> > running it later!
> >
> Sorry, at the moment function MSTP_OUT_set_state() does nothing except
> logging. But it is valueable thought: although MSTI states do not have
> meaning to the kernel bridge code, CIST states can be used to control bridge
> slave states, so mstpd can replace rstpd as more generic (and conforming to
> more recent standard).
Well, with the current kernel code you can basically support MSTP setups
where all VLANs are mapped to one MSTI, since there's just one port
state for all VLANs. As far as I can tell, that doesn't need to be
the CIST/instance 0, as long as it's the same for all VLANs.
> Anyways, the code is basically untested. It compiles and runs in my setup,
> that's all for now. But I somehow have gut feeling that the code is mature
> enough to be put for the community consideration.
Well, "the community" is usually happy when you continually maintain and
improve your code - one-shot code publications ("fire & forget") happen
all too often and are forgotten quickly...
-David
^ permalink raw reply
* [net-next 02/02] ixgb: finish conversion to ndo_fix_features
From: Jeff Kirsher @ 2011-09-23 12:11 UTC (permalink / raw)
To: davem; +Cc: Michał Mirosław, netdev, gospo, Jeff Kirsher
In-Reply-To: <1316779890-32436-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Finish conversion to unified ethtool ops: convert get_flags.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c | 39 ------------------------
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 22 +++++++++++--
2 files changed, 18 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c b/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
index fdb30cc..ab404e7 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_ethtool.c
@@ -634,43 +634,6 @@ ixgb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
}
}
-static int ixgb_set_flags(struct net_device *netdev, u32 data)
-{
- struct ixgb_adapter *adapter = netdev_priv(netdev);
- bool need_reset;
- int rc;
-
- /*
- * Tx VLAN insertion does not work per HW design when Rx stripping is
- * disabled. Disable txvlan when rxvlan is turned off, and enable
- * rxvlan when txvlan is turned on.
- */
- if (!(data & ETH_FLAG_RXVLAN) &&
- (netdev->features & NETIF_F_HW_VLAN_TX))
- data &= ~ETH_FLAG_TXVLAN;
- else if (data & ETH_FLAG_TXVLAN)
- data |= ETH_FLAG_RXVLAN;
-
- need_reset = (data & ETH_FLAG_RXVLAN) !=
- (netdev->features & NETIF_F_HW_VLAN_RX);
-
- rc = ethtool_op_set_flags(netdev, data, ETH_FLAG_RXVLAN |
- ETH_FLAG_TXVLAN);
- if (rc)
- return rc;
-
- if (need_reset) {
- if (netif_running(netdev)) {
- ixgb_down(adapter, true);
- ixgb_up(adapter);
- ixgb_set_speed_duplex(netdev);
- } else
- ixgb_reset(adapter);
- }
-
- return 0;
-}
-
static const struct ethtool_ops ixgb_ethtool_ops = {
.get_settings = ixgb_get_settings,
.set_settings = ixgb_set_settings,
@@ -691,8 +654,6 @@ static const struct ethtool_ops ixgb_ethtool_ops = {
.set_phys_id = ixgb_set_phys_id,
.get_sset_count = ixgb_get_sset_count,
.get_ethtool_stats = ixgb_get_ethtool_stats,
- .get_flags = ethtool_op_get_flags,
- .set_flags = ixgb_set_flags,
};
void ixgb_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index ca3ab4a..88558b1 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -325,13 +325,26 @@ ixgb_reset(struct ixgb_adapter *adapter)
}
}
+static u32
+ixgb_fix_features(struct net_device *netdev, u32 features)
+{
+ /*
+ * Tx VLAN insertion does not work per HW design when Rx stripping is
+ * disabled.
+ */
+ if (!(features & NETIF_F_HW_VLAN_RX))
+ features &= ~NETIF_F_HW_VLAN_TX;
+
+ return features;
+}
+
static int
ixgb_set_features(struct net_device *netdev, u32 features)
{
struct ixgb_adapter *adapter = netdev_priv(netdev);
u32 changed = features ^ netdev->features;
- if (!(changed & NETIF_F_RXCSUM))
+ if (!(changed & (NETIF_F_RXCSUM|NETIF_F_HW_VLAN_RX)))
return 0;
adapter->rx_csum = !!(features & NETIF_F_RXCSUM);
@@ -362,6 +375,7 @@ static const struct net_device_ops ixgb_netdev_ops = {
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = ixgb_netpoll,
#endif
+ .ndo_fix_features = ixgb_fix_features,
.ndo_set_features = ixgb_set_features,
};
@@ -464,10 +478,10 @@ ixgb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
netdev->hw_features = NETIF_F_SG |
NETIF_F_TSO |
- NETIF_F_HW_CSUM;
- netdev->features = netdev->hw_features |
+ NETIF_F_HW_CSUM |
NETIF_F_HW_VLAN_TX |
- NETIF_F_HW_VLAN_RX |
+ NETIF_F_HW_VLAN_RX;
+ netdev->features = netdev->hw_features |
NETIF_F_HW_VLAN_FILTER;
netdev->hw_features |= NETIF_F_RXCSUM;
--
1.7.6.2
^ permalink raw reply related
* [net-next 01/02] ixgb: eliminate checkstack warnings
From: Jeff Kirsher @ 2011-09-23 12:11 UTC (permalink / raw)
To: davem; +Cc: Jesse Brandeburg, netdev, gospo, Jeff Kirsher
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Really trivial fix, use kmalloc/kfree instead of stack space.
use static const instead of const to further reduce stack usage.
V2: reflect changes suggested by Joe Perches
before:
[jbrandeb@jbrandeb-mobl2 linux-2.6]$ make checkstack|grep '\[ixgb\]'
0x00000fc1 ixgb_set_multi [ixgb]: 768
0x00001031 ixgb_set_multi [ixgb]: 768
0x000010f2 ixgb_set_multi [ixgb]: 768
0x061c ixgb_check_options [ixgb]: 448
0x09c3 ixgb_check_options [ixgb]: 448
0x0000649e ixgb_set_ringparam [ixgb]: 192
0x0000130d ixgb_xmit_frame [ixgb]: 184
0x000019e0 ixgb_xmit_frame [ixgb]: 184
0x00002267 ixgb_clean [ixgb]: 152
0x00002673 ixgb_clean [ixgb]: 152
after:
0x000064ee ixgb_set_ringparam [ixgb]: 192
0x0000135d ixgb_xmit_frame [ixgb]: 184
0x00001a30 ixgb_xmit_frame [ixgb]: 184
0x000022b7 ixgb_clean [ixgb]: 152
0x000026c3 ixgb_clean [ixgb]: 152
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgb/ixgb_ee.c | 2 +-
drivers/net/ethernet/intel/ixgb/ixgb_ee.h | 4 +---
drivers/net/ethernet/intel/ixgb/ixgb_hw.c | 2 +-
drivers/net/ethernet/intel/ixgb/ixgb_hw.h | 4 +---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 21 ++++++++++++++-------
drivers/net/ethernet/intel/ixgb/ixgb_osdep.h | 1 +
drivers/net/ethernet/intel/ixgb/ixgb_param.c | 18 +++++++++---------
7 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_ee.c b/drivers/net/ethernet/intel/ixgb/ixgb_ee.c
index 38b362b..2ed925f 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_ee.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_ee.c
@@ -559,7 +559,7 @@ ixgb_get_ee_mac_addr(struct ixgb_hw *hw,
ENTER();
if (ixgb_check_and_get_eeprom_data(hw) == true) {
- for (i = 0; i < IXGB_ETH_LENGTH_OF_ADDRESS; i++) {
+ for (i = 0; i < ETH_ALEN; i++) {
mac_addr[i] = ee_map->mac_addr[i];
}
pr_debug("eeprom mac address = %pM\n", mac_addr);
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_ee.h b/drivers/net/ethernet/intel/ixgb/ixgb_ee.h
index 7ea1265..5680f64 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_ee.h
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_ee.h
@@ -31,8 +31,6 @@
#define IXGB_EEPROM_SIZE 64 /* Size in words */
-#define IXGB_ETH_LENGTH_OF_ADDRESS 6
-
/* EEPROM Commands */
#define EEPROM_READ_OPCODE 0x6 /* EEPROM read opcode */
#define EEPROM_WRITE_OPCODE 0x5 /* EEPROM write opcode */
@@ -75,7 +73,7 @@
/* EEPROM structure */
struct ixgb_ee_map_type {
- u8 mac_addr[IXGB_ETH_LENGTH_OF_ADDRESS];
+ u8 mac_addr[ETH_ALEN];
__le16 compatibility;
__le16 reserved1[4];
__le32 pba_number;
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_hw.c b/drivers/net/ethernet/intel/ixgb/ixgb_hw.c
index 3d61a9e..99b69ad 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_hw.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_hw.c
@@ -478,7 +478,7 @@ ixgb_mc_addr_list_update(struct ixgb_hw *hw,
ixgb_mta_set(hw, hash_value);
}
- mca += IXGB_ETH_LENGTH_OF_ADDRESS + pad;
+ mca += ETH_ALEN + pad;
}
pr_debug("MC Update Complete\n");
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_hw.h b/drivers/net/ethernet/intel/ixgb/ixgb_hw.h
index 873d32b..2a99a35 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_hw.h
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_hw.h
@@ -97,8 +97,6 @@ typedef enum {
ixgb_bus_width_64
} ixgb_bus_width;
-#define IXGB_ETH_LENGTH_OF_ADDRESS 6
-
#define IXGB_EEPROM_SIZE 64 /* Size in words */
#define SPEED_10000 10000
@@ -674,7 +672,7 @@ struct ixgb_hw {
u32 max_frame_size; /* Maximum frame size supported */
u32 mc_filter_type; /* Multicast filter hash type */
u32 num_mc_addrs; /* Number of current Multicast addrs */
- u8 curr_mac_addr[IXGB_ETH_LENGTH_OF_ADDRESS]; /* Individual address currently programmed in MAC */
+ u8 curr_mac_addr[ETH_ALEN]; /* Individual address currently programmed in MAC */
u32 num_tx_desc; /* Number of Transmit descriptors */
u32 num_rx_desc; /* Number of Receive descriptors */
u32 rx_buffer_size; /* Size of Receive buffer */
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index b8fb163..ca3ab4a 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -1093,7 +1093,6 @@ ixgb_set_multi(struct net_device *netdev)
struct ixgb_hw *hw = &adapter->hw;
struct netdev_hw_addr *ha;
u32 rctl;
- int i;
/* Check for Promiscuous and All Multicast modes */
@@ -1120,19 +1119,27 @@ ixgb_set_multi(struct net_device *netdev)
rctl |= IXGB_RCTL_MPE;
IXGB_WRITE_REG(hw, RCTL, rctl);
} else {
- u8 mta[IXGB_MAX_NUM_MULTICAST_ADDRESSES *
- IXGB_ETH_LENGTH_OF_ADDRESS];
+ u8 *mta = kmalloc(IXGB_MAX_NUM_MULTICAST_ADDRESSES *
+ ETH_ALEN, GFP_ATOMIC);
+ u8 *addr;
+ if (!mta) {
+ pr_err("allocation of multicast memory failed\n");
+ goto alloc_failed;
+ }
IXGB_WRITE_REG(hw, RCTL, rctl);
- i = 0;
- netdev_for_each_mc_addr(ha, netdev)
- memcpy(&mta[i++ * IXGB_ETH_LENGTH_OF_ADDRESS],
- ha->addr, IXGB_ETH_LENGTH_OF_ADDRESS);
+ addr = mta;
+ netdev_for_each_mc_addr(ha, netdev) {
+ memcpy(addr, ha->addr, ETH_ALEN);
+ addr += ETH_ALEN;
+ }
ixgb_mc_addr_list_update(hw, mta, netdev_mc_count(netdev), 0);
+ kfree(mta);
}
+alloc_failed:
if (netdev->features & NETIF_F_HW_VLAN_RX)
ixgb_vlan_strip_enable(adapter);
else
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_osdep.h b/drivers/net/ethernet/intel/ixgb/ixgb_osdep.h
index e361185..8fc9051 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_osdep.h
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_osdep.h
@@ -38,6 +38,7 @@
#include <asm/io.h>
#include <linux/interrupt.h>
#include <linux/sched.h>
+#include <linux/if_ether.h>
#undef ASSERT
#define ASSERT(x) BUG_ON(!(x))
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_param.c b/drivers/net/ethernet/intel/ixgb/ixgb_param.c
index dd7fbeb..07d83ab 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_param.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_param.c
@@ -267,7 +267,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
}
{ /* Transmit Descriptor Count */
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = range_option,
.name = "Transmit Descriptors",
.err = "using default of " __MODULE_STRING(DEFAULT_TXD),
@@ -286,7 +286,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
tx_ring->count = ALIGN(tx_ring->count, IXGB_REQ_TX_DESCRIPTOR_MULTIPLE);
}
{ /* Receive Descriptor Count */
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = range_option,
.name = "Receive Descriptors",
.err = "using default of " __MODULE_STRING(DEFAULT_RXD),
@@ -305,7 +305,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
rx_ring->count = ALIGN(rx_ring->count, IXGB_REQ_RX_DESCRIPTOR_MULTIPLE);
}
{ /* Receive Checksum Offload Enable */
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = enable_option,
.name = "Receive Checksum Offload",
.err = "defaulting to Enabled",
@@ -348,7 +348,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
}
}
{ /* Receive Flow Control High Threshold */
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = range_option,
.name = "Rx Flow Control High Threshold",
.err = "using default of " __MODULE_STRING(DEFAULT_FCRTH),
@@ -367,7 +367,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
pr_info("Ignoring RxFCHighThresh when no RxFC\n");
}
{ /* Receive Flow Control Low Threshold */
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = range_option,
.name = "Rx Flow Control Low Threshold",
.err = "using default of " __MODULE_STRING(DEFAULT_FCRTL),
@@ -386,7 +386,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
pr_info("Ignoring RxFCLowThresh when no RxFC\n");
}
{ /* Flow Control Pause Time Request*/
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = range_option,
.name = "Flow Control Pause Time Request",
.err = "using default of "__MODULE_STRING(DEFAULT_FCPAUSE),
@@ -416,7 +416,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
}
}
{ /* Receive Interrupt Delay */
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = range_option,
.name = "Receive Interrupt Delay",
.err = "using default of " __MODULE_STRING(DEFAULT_RDTR),
@@ -433,7 +433,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
}
}
{ /* Transmit Interrupt Delay */
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = range_option,
.name = "Transmit Interrupt Delay",
.err = "using default of " __MODULE_STRING(DEFAULT_TIDV),
@@ -451,7 +451,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
}
{ /* Transmit Interrupt Delay Enable */
- const struct ixgb_option opt = {
+ static const struct ixgb_option opt = {
.type = enable_option,
.name = "Tx Interrupt Delay Enable",
.err = "defaulting to Enabled",
--
1.7.6.2
^ permalink raw reply related
* [PATCH v5 3/3] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-23 12:12 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316779968-21390-1-git-send-email-shawn.guo@linaro.org>
The imx6q enet is a derivative of imx28 enet controller. It fixed
the frame endian issue found on imx28, and added 1 Gbps support.
It also fixes a typo on vendor name in Kconfig.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/Kconfig | 9 ++--
drivers/net/ethernet/freescale/fec.c | 66 +++++++++++++++++++++++++------
2 files changed, 57 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 4dbe41f..1cf6716 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
default y
depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC || \
+ ARCH_MXC || ARCH_MXS || \
(PPC_MPC52xx && PPC_BESTCOMM)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
@@ -16,16 +16,15 @@ config NET_VENDOR_FREESCALE
Note that the answer to this question doesn't directly affect the
kernel: saying N will just cause the configurator to skip all
- the questions about IBM devices. If you say Y, you will be asked for
- your specific card in the following questions.
+ the questions about Freescale devices. If you say Y, you will be
+ asked for your specific card in the following questions.
if NET_VENDOR_FREESCALE
config FEC
bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC)
- default IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC if ARM
+ ARCH_MXC || ARCH_MXS)
select PHYLIB
---help---
Say Y here if you want to use the built-in 10/100 Fast ethernet
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 2bbe6a5..cce78ce 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -18,7 +18,7 @@
* Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
* Copyright (c) 2004-2006 Macq Electronique SA.
*
- * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
*/
#include <linux/module.h>
@@ -72,6 +72,8 @@
#define FEC_QUIRK_SWAP_FRAME (1 << 1)
/* Controller uses gasket */
#define FEC_QUIRK_USE_GASKET (1 << 2)
+/* Controller has GBIT support */
+#define FEC_QUIRK_HAS_GBIT (1 << 3)
static struct platform_device_id fec_devtype[] = {
{
@@ -88,6 +90,9 @@ static struct platform_device_id fec_devtype[] = {
.name = "imx28-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
}, {
+ .name = "imx6q-fec",
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT,
+ }, {
/* sentinel */
}
};
@@ -97,12 +102,14 @@ enum imx_fec_type {
IMX25_FEC = 1, /* runs on i.mx25/50/53 */
IMX27_FEC, /* runs on i.mx27/35/51 */
IMX28_FEC,
+ IMX6Q_FEC,
};
static const struct of_device_id fec_dt_ids[] = {
{ .compatible = "fsl,imx25-fec", .data = &fec_devtype[IMX25_FEC], },
{ .compatible = "fsl,imx27-fec", .data = &fec_devtype[IMX27_FEC], },
{ .compatible = "fsl,imx28-fec", .data = &fec_devtype[IMX28_FEC], },
+ { .compatible = "fsl,imx6q-fec", .data = &fec_devtype[IMX6Q_FEC], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fec_dt_ids);
@@ -373,6 +380,7 @@ fec_restart(struct net_device *ndev, int duplex)
int i;
u32 temp_mac[2];
u32 rcntl = OPT_FRAME_SIZE | 0x04;
+ u32 ecntl = 0x2; /* ETHEREN */
/* Whack a reset. We should wait for this. */
writel(1, fep->hwp + FEC_ECNTRL);
@@ -442,18 +450,23 @@ fec_restart(struct net_device *ndev, int duplex)
/* Enable flow control and length check */
rcntl |= 0x40000000 | 0x00000020;
- /* MII or RMII */
- if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
+ /* RGMII, RMII or MII */
+ if (fep->phy_interface == PHY_INTERFACE_MODE_RGMII)
+ rcntl |= (1 << 6);
+ else if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
rcntl |= (1 << 8);
else
rcntl &= ~(1 << 8);
- /* 10M or 100M */
- if (fep->phy_dev && fep->phy_dev->speed == SPEED_100)
- rcntl &= ~(1 << 9);
- else
- rcntl |= (1 << 9);
-
+ /* 1G, 100M or 10M */
+ if (fep->phy_dev) {
+ if (fep->phy_dev->speed == SPEED_1000)
+ ecntl |= (1 << 5);
+ else if (fep->phy_dev->speed == SPEED_100)
+ rcntl &= ~(1 << 9);
+ else
+ rcntl |= (1 << 9);
+ }
} else {
#ifdef FEC_MIIGSK_ENR
if (id_entry->driver_data & FEC_QUIRK_USE_GASKET) {
@@ -478,8 +491,15 @@ fec_restart(struct net_device *ndev, int duplex)
}
writel(rcntl, fep->hwp + FEC_R_CNTRL);
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ /* enable ENET endian swap */
+ ecntl |= (1 << 8);
+ /* enable ENET store and forward mode */
+ writel(1 << 8, fep->hwp + FEC_X_WMRK);
+ }
+
/* And last, enable the transmit and receive processing */
- writel(2, fep->hwp + FEC_ECNTRL);
+ writel(ecntl, fep->hwp + FEC_ECNTRL);
writel(0, fep->hwp + FEC_R_DES_ACTIVE);
/* Enable interrupts we wish to service */
@@ -490,6 +510,8 @@ static void
fec_stop(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
/* We cannot expect a graceful transmit stop without link !!! */
if (fep->link) {
@@ -504,6 +526,10 @@ fec_stop(struct net_device *ndev)
udelay(10);
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+
+ /* We have to keep ENET enabled to have MII interrupt stay working */
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+ writel(2, fep->hwp + FEC_ECNTRL);
}
@@ -918,6 +944,8 @@ static int fec_enet_mdio_reset(struct mii_bus *bus)
static int fec_enet_mii_probe(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
struct phy_device *phy_dev = NULL;
char mdio_bus_id[MII_BUS_ID_SIZE];
char phy_name[MII_BUS_ID_SIZE + 3];
@@ -949,14 +977,18 @@ static int fec_enet_mii_probe(struct net_device *ndev)
snprintf(phy_name, MII_BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id, phy_id);
phy_dev = phy_connect(ndev, phy_name, &fec_enet_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ fep->phy_interface);
if (IS_ERR(phy_dev)) {
printk(KERN_ERR "%s: could not attach to PHY\n", ndev->name);
return PTR_ERR(phy_dev);
}
/* mask with MAC supported features */
- phy_dev->supported &= PHY_BASIC_FEATURES;
+ if (id_entry->driver_data & FEC_QUIRK_HAS_GBIT)
+ phy_dev->supported &= PHY_GBIT_FEATURES;
+ else
+ phy_dev->supported &= PHY_BASIC_FEATURES;
+
phy_dev->advertising = phy_dev->supported;
fep->phy_dev = phy_dev;
@@ -1006,8 +1038,16 @@ static int fec_enet_mii_init(struct platform_device *pdev)
/*
* Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
+ *
+ * The formula for FEC MDC is 'ref_freq / (MII_SPEED x 2)' while
+ * for ENET-MAC is 'ref_freq / ((MII_SPEED + 1) x 2)'. The i.MX28
+ * Reference Manual has an error on this, and gets fixed on i.MX6Q
+ * document.
*/
- fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000) << 1;
+ fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+ fep->phy_speed--;
+ fep->phy_speed <<= 1;
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
fep->mii_bus = mdiobus_alloc();
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 2/3] net/fec: fix fec1 check in fec_enet_mii_init()
From: Shawn Guo @ 2011-09-23 12:12 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316779968-21390-1-git-send-email-shawn.guo@linaro.org>
In function fec_enet_mii_init(), it uses non-zero pdev->id as part
of the condition to check the second fec instance (fec1). This works
before the driver supports device tree probe. But in case of device
tree probe, pdev->id is -1 which is also non-zero, so the logic becomes
broken when device tree probe gets supported.
The patch change the logic to check "pdev->id > 0" as the part of the
condition for identifying fec1.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/fec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 9c1d059..2bbe6a5 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -996,7 +996,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* mdio interface in board design, and need to be configured by
* fec0 mii_bus.
*/
- if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id) {
+ if ((id_entry->driver_data & FEC_QUIRK_ENET_MAC) && pdev->id > 0) {
/* fec1 uses fec0 mii_bus */
fep->mii_bus = fec0_mii_bus;
return 0;
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 1/3] net/fec: fec_reset_phy() does not need to always succeed
From: Shawn Guo @ 2011-09-23 12:12 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316779968-21390-1-git-send-email-shawn.guo@linaro.org>
FEC can work without a phy reset on some platforms, which means not
very platform necessarily have a phy-reset gpio encoded in device tree.
Even on the platforms that have the gpio, FEC can work without
resetting phy for some cases, e.g. boot loader has done that.
So it makes more sense to have the phy-reset-gpio request failure as
a debug message rather than a warning, and get fec_reset_phy() return
void since the caller does not check the return anyway.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/ethernet/freescale/fec.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 158b82e..9c1d059 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -1411,24 +1411,22 @@ static int __devinit fec_get_phy_mode_dt(struct platform_device *pdev)
return -ENODEV;
}
-static int __devinit fec_reset_phy(struct platform_device *pdev)
+static void __devinit fec_reset_phy(struct platform_device *pdev)
{
int err, phy_reset;
struct device_node *np = pdev->dev.of_node;
if (!np)
- return -ENODEV;
+ return;
phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
err = gpio_request_one(phy_reset, GPIOF_OUT_INIT_LOW, "phy-reset");
if (err) {
- pr_warn("FEC: failed to get gpio phy-reset: %d\n", err);
- return err;
+ pr_debug("FEC: failed to get gpio phy-reset: %d\n", err);
+ return;
}
msleep(1);
gpio_set_value(phy_reset, 1);
-
- return 0;
}
#else /* CONFIG_OF */
static inline int fec_get_phy_mode_dt(struct platform_device *pdev)
@@ -1436,13 +1434,12 @@ static inline int fec_get_phy_mode_dt(struct platform_device *pdev)
return -ENODEV;
}
-static inline int fec_reset_phy(struct platform_device *pdev)
+static inline void fec_reset_phy(struct platform_device *pdev)
{
/*
* In case of platform probe, the reset has been done
* by machine code.
*/
- return 0;
}
#endif /* CONFIG_OF */
--
1.7.4.1
^ permalink raw reply related
* [PATCH v5 0/3] add fec support for imx6q
From: Shawn Guo @ 2011-09-23 12:12 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches
This series adds imx6q enet support. The imx6q enet is a derivative of
imx28 enet controller. It fixes the frame endian issue found on imx28,
and adds 1 Gbps support.
Changes since v4:
* Confirmed with design team that i.MX28 Reference Manual has an error
on MII_SPEED formula. FEC uses 'ref_freq / (MII_SPEED x 2)' while
ENET-MAC uses 'ref_freq / ((MII_SPEED + 1) x 2)', so that minus one
should really apply for just FEC_QUIRK_ENET_MAC.
Changes since v3:
* The minus one on phy_speed should happen before left shift.
Changes since v2:
* Refine patch #1 to get fec_reset_phy() return void
Changes since v1:
* Fix typo pointed out by Francois Romieu
* Drop patch #3 in the v1
* Rebase on net-next tree
Thanks.
Shawn Guo (3):
net/fec: fec_reset_phy() does not need to always succeed
net/fec: fix fec1 check in fec_enet_mii_init()
net/fec: add imx6q enet support
drivers/net/ethernet/freescale/Kconfig | 9 ++--
drivers/net/ethernet/freescale/fec.c | 81 +++++++++++++++++++++++---------
2 files changed, 63 insertions(+), 27 deletions(-)
^ permalink raw reply
* Re: Question regarding wanrouter module
From: Francois Romieu @ 2011-09-23 11:26 UTC (permalink / raw)
To: Holger Hans Peter Freyther; +Cc: netdev
In-Reply-To: <4E7C528F.4010303@freyther.de>
Holger Hans Peter Freyther <holger@freyther.de> :
[...]
> Fast forward to today, Sangoma provides a wanrouter.ko as well (they didn't
> bother to change the symbol names or module name). I wonder if there are any
> plans to improve the situation, e.g. rename the kernel module, change symbols,
> or if there would be objections to trying to add functionality to the kernel
> wanrouter.ko again ?
There are objections to adding.
The kernel wanrouter code is almost empty. Afaiu it mostly contains a
wan setup API.
Is there a reason why the added functionalities could not go through the
generic hdlc kernel code (see drivers/net/wan/hdlc*) ?
--
Ueimor
^ permalink raw reply
* [PATCH 2/2] wireless: at76c50x: use native hex_pack_byte() method
From: Andy Shevchenko @ 2011-09-23 10:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Andy Shevchenko, John W. Linville, linux-wireless, netdev
In-Reply-To: <fa146966b0ce1e7f04d59eb27cc0e968f51b22de.1316774801.git.andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/at76c50x-usb.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index 2986014..157507a6 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -500,7 +500,6 @@ exit:
#define HEX2STR_BUFFERS 4
#define HEX2STR_MAX_LEN 64
-#define BIN2HEX(x) ((x) < 10 ? '0' + (x) : (x) + 'A' - 10)
/* Convert binary data into hex string */
static char *hex2str(void *buf, int len)
@@ -520,10 +519,8 @@ static char *hex2str(void *buf, int len)
}
while (len--) {
- *obuf++ = BIN2HEX(*ibuf >> 4);
- *obuf++ = BIN2HEX(*ibuf & 0xf);
+ obuf = hex_pack_byte(obuf, *ibuf++);
*obuf++ = '-';
- ibuf++;
}
*(--obuf) = '\0';
--
1.7.6.3
^ permalink raw reply related
* RE: [patch v2] caif: add error handling for allocation
From: Sjur BRENDELAND @ 2011-09-23 10:38 UTC (permalink / raw)
To: Dan Carpenter
Cc: David S. Miller, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <20110921072159.GJ4999@elgon.mountain>
[Dan]:
> The allocation of "phyinfo" wasn't checked, and also the allocation
> wasn't freed on error paths. Sjur Brændeland pointed out as well
> that "phy_driver" should be freed on the error path too.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Looks good, thank you Dan.
Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
^ permalink raw reply
* Question regarding wanrouter module
From: Holger Hans Peter Freyther @ 2011-09-23 9:34 UTC (permalink / raw)
To: netdev
Hi all,
at some point the Sangoma wanrouter and device drivers were merged in the
kernel. Somewhere in 2006 (8db60bcf3021921e2d10d158641792d640e52fe8) the
drivers were removed as Sangoma wanted to maintain them themselves. Later some
of the functionality got removed (ce0ecd594d78710422599918a608). In the kernel
it appears that cycx_x25.c and isdn_x25iface.c make use of the wanrouter.
Fast forward to today, Sangoma provides a wanrouter.ko as well (they didn't
bother to change the symbol names or module name). I wonder if there are any
plans to improve the situation, e.g. rename the kernel module, change symbols,
or if there would be objections to trying to add functionality to the kernel
wanrouter.ko again?
cheers
holger
^ permalink raw reply
* Re: [PATCH net-next v2] candev: allow SJW user setting for bittiming calculation
From: Pavel Pisa @ 2011-09-23 9:32 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Oliver Hartkopp, Linux Netdev List
In-Reply-To: <4E7C3424.8030406-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hello Oliver and Wolfgang,
On Friday 23 September 2011 09:24:20 Wolfgang Grandegger wrote:
> Hi Oliver,
>
> On 09/22/2011 09:41 PM, Oliver Hartkopp wrote:
> Then let us set it to 4 (maximum), by default. But other documents
> recommend a value of 1.
I am not expert for CAN timing nor I have time to go through
documentation at this moment. But I hope that I have some
sense/experience for electronic and dynamic systems
and we have done more designs utilizing CAN at university
and at our company.
So there are some thought about SJW based on my experience.
There could be some inaccuracies, if you want better
analysis, I need time for that.
1) The CAN needs fast local roundrip time for correct operation
of dominant/recessive arbitration.
The time is sum of propagation from CAN controller chip,
propagation delay of optocoupler or other galvanic isolation,
slew rate and delay in Tx circuitry of transceiver, charging
the wire, Rx part of receiver, optocoupler, controller
Rx filtering and Rx,Tx logic level comparator.
Iw we count necessity to synchronize this between multiple
CAN nodes then whole roundtrip time has to be smaller than
50-80% of single bit bit time quantum.
2) From the noise and stabilization of voltage on the wire
the sampling point should be in the middle of bit pulse
delayed by round-trip delay from 1. This is 50% of bit
time (i.e. dependent on bitrate) + round trip delay (dependent
on delay in controller and concrete board circuitry).
3) But sampling point has to allow to decide about collision
before next bit Tx is started => it cannot be moved after
end of the given Tx bit time interval.
4) It is necessary to synchronize bit timing in all
CAN controllers during arbitration (ID sending) phase.
The first sync is done after receiving of the first
edge on the wire. It can be other node start of Tx
or our own Tx dominant level. Controller shifts its Tx
timing such way, that start of the next Tx bit interval
should result in Rx transition at the end the sensed
Rx bit. I.e. it counts only TSEG2 til next bit start.
5) There are some more things to consider if triple
sampling and filtering is enabled to suppress noise
on wire. It can be used only, if time quantum clocks
are fast enough to fit this sampling interval between
stabilization of delayed Rx logic level and end of Tx bit
time interval.
6) If the clock frequencies of all nodes CAN controllers
are guaranteed to be same, then no more synchronization
is necessary during message Tx/Rx (SJW=0). But that assumption
does not hold. That is why bitstuffing is used and guarantees
that there is at least one logic level transition (edge)
after each 6 bit time. If there is zero roundtrip propagation
delay and sampling in 50% of bit time interval then
maximal skew/frequency difference of the clocks could be
(1+1/6*50%) - 1 i.e. 8%
This means, that SJW bigger than 8% of whole bit time
would not help to synchronize bitrate difference, because
for such case setup cannot work anyway. Propagation delay
is not zero then there is even less time left for sampling
point shift which would not cause incorrect bit data
detection so reasonable maximum is probably lower.
I expect that for reasonable precise setup of bitrate
when exact ratio is found and crystal based oscillators
there is the best option small SJW i.e. 1 or for very
fast TQ clock equivalent of 1% - 2% of bittime.
For nonexact ratio or low quality clocks sources,
bigger SJW values make sense. But big value has other
disadvantage. If there is bigger jitter in Tx/Rx delays
or clocks then it is propagated back to bit timing
and stability of system composed from multiple nodes
could be questionable. There is even bigger interval
where noise pulse could cause lost of the synchronization.
On base of above analysis, I think that blindly set SJW
on maximum is not good idea. It should be at least limited
to 5% of bit time.
Because bit timing calculation is not what everybody
want to do again and again, the actual code tries
to hide differences of CAN controllers and provide
at least partially understandable knobs to user
with parameters independent on concrete setup low level
details to allow set bitrate for usual Joe user.
The basic parameters are chosen such way, that user need
not to care about actual TQ clock and selecting prescaller,
that is why sampling point is in percent of bittime.
SJW is more problematic, but may it be use of 2 or 5%
of bittime by default with assurance that zero is
replaced by one, would serve to most people pleasure.
May it be, that 0.1 of percent should be used as unit
for external parameter too.
I hope that actual calculation works reasonably well.
But if it should be enhanced, then it would worth
to add additional parameter except crystal/controller
clock source freqency to the concrete boards drivers.
It should be measured round-trip delay of given/used
transceiver/optocouplers combination. This would
allow to have sampling point setup yet more independent
on given HW and same value could be used for different
bitrates. But there is still unknown parameter
capacity/length of connected wires so there is still
something left to user consideration.
Best wishes,
Pavel Pisa
e-mail: pisa-/N2ztlQkxE7Ub/6JBqosbQ@public.gmane.org
www: http://cmp.felk.cvut.cz/~pisa
university: http://dce.fel.cvut.cz/
company: http://www.pikron.com/
> > possible. And if an expert told me so and i had a simple config interface
> > to fullfill it, it would be great for me ;-)
>
> Anyway, if SJW does not depend on other bit-timing parameters and it
> usually works fine with the kernel calculated parameters I would no
> longer vote against this patch.
>
> Wolfgang,
^ permalink raw reply
* administrativní zprávy
From: univerzita Karlova @ 2011-09-23 8:02 UTC (permalink / raw)
--
Vážení karlin.mff.cuni.cz účastníka,
Ukončení vašeho karlin.mff.cuni.cz a související poštovním účtem
probíhá, jsme v současné době provádí upgrade na náš systém vzhledem k
tomu, že to přišlo na naše upozornění, že jedna nebo více z našich
předplatitelů zavádějí velmi silný virus do našeho systému a to
ovlivňuje naši síť.
Snažíme se zjistit konkrétní osobu. Z tohoto důvodu se všichni
účastníci jsou povinni poskytnout své uživatelské jméno a heslo pro nás
pro ověření a je zúčtováno proti tomuto viru. Nedodržení povede k
ukončení vašeho účtu v příštích 48 hodin.
Informace k odeslání;
* Uživatelské jméno E-mail} {: (.................) (povinné)
* Heslo :(..........................)( povinné)
* Datum narození: (...........................)( nepovinné)
* Země nebo území: (...................)( nepovinné)
Doufat, aby vám lépe sloužily ..
S pozdravem,
univerzita Karlova
**************************************************
******************************************
Jedná se o administrativní zprávy ze serveru karlin.mff.cuni.cz. To
není spam. Čas od času se karlin.mff.cuni.cz server, posílat zprávy
například pro komunikaci důležité informace o vašem předplatném.
**************************************************
******************************************
^ permalink raw reply
* Re: Introducing open source MSTP daemon
From: Vitalii Demianets @ 2011-09-23 7:36 UTC (permalink / raw)
To: David Lamparter; +Cc: bridge, netdev, Srinivas M.A., Stephen Hemminger
In-Reply-To: <20110922163939.GB1012103@jupiter.n2.diac24.net>
On Thursday 22 September 2011 19:39:40 David Lamparter wrote:
> Very cool!
>
> The code looks quite good to me (i've only looked at 2 files though ;).
> Minor nitpicks:
> - hmac_md5 & epoll could maybe come from an external library. you're
> the 3810583th person to have code for that... libevent?
> OpenSSL/gnutls?
> - libnetlink.c is a copy from iproute2? since it is a fresh clean SVN,
> it's not easy to know whether you made changes. Can you put a note
> which version this is? Or maybe you can link it externally?
> - the "assign" macro and "boolFalse" in mstp.c are weird. I understand
> you want stricter type checking, but this makes the code somewhat
> odd to read. Maybe external tools can be used to do this checking
> (sparse, cppcheck, llvm's static analysis, ...)
>
Happy to hear you are interested )
I suppose these questions are not related to kernel development so I suggest
to continue discussion on above topics at the project discussion board:
http://sourceforge.net/p/mstpd/discussion/
> I assume it works with current Linux kernel bridge code on a RSTP level?
> The code looks considerably more maintainable than rstpd :) - I will try
> running it later!
>
Sorry, at the moment function MSTP_OUT_set_state() does nothing except
logging. But it is valueable thought: although MSTI states do not have
meaning to the kernel bridge code, CIST states can be used to control bridge
slave states, so mstpd can replace rstpd as more generic (and conforming to
more recent standard).
Anyways, the code is basically untested. It compiles and runs in my setup,
that's all for now. But I somehow have gut feeling that the code is mature
enough to be put for the community consideration.
--
Vitalii Demianets
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Ian Campbell @ 2011-09-23 7:27 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, konrad.wilk@oracle.com, Jesse Barnes, Greg Rose, netdev,
gospo, linux-pci
In-Reply-To: <CAL3LdT7jDfytZD7WESmiHxvpmxKTEZ=uWRjzgsR9e4GtBPE31A@mail.gmail.com>
On Thu, 2011-09-22 at 21:16 -0700, Jeff Kirsher wrote:
>
>
> Jesse/Konrad/Ian-
>
> I sent this patch out as part of a pull request for David Miller's
> net-next tree. I know that Greg sent this originally out to the
> linux-pci mailing list as a RFC. Since Greg also has a patch against
> ixgbe which implemented this flag, I sent both patches for inclusion
> into David Miller's net-next.
>
> Dave is wanting to ensure that the PCI maintainers have reviewed this
> and are ok with it before pulls my series of patches.
I'm not a PCI maintainer by any stretch of the imagination but FWIW this
change is fine by me.
My original reason for commenting on this patch was just to wonder
whether this would also be useful for Xen and I think the answer is we
should patch xen-pciback to use this new flag but I've not had time to
look into that.
I suppose by that measure the comment could be less KVM specific:
> + /* Provide indication device is assigned by KVM */
> + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
but that's not exactly a big deal.
I suppose really the flag indicates "VF in use" rather than necessarily
"assigned"? Would it be just as bad to have a VF driver in the host
active when the PF was unloaded?
Ian.
--
Ian Campbell
Current Noise: Mudhoney - Mudride (Live In Berlin)
Well, I think Perl should run faster than C. :-)
-- Larry Wall in <199801200306.TAA11638@wall.org>
^ permalink raw reply
* Re: [PATCH net-next v2] candev: allow SJW user setting for bittiming calculation
From: Wolfgang Grandegger @ 2011-09-23 7:24 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: SocketCAN Core Mailing List, Linux Netdev List
In-Reply-To: <4E7B8F63.6060108-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Hi Oliver,
On 09/22/2011 09:41 PM, Oliver Hartkopp wrote:
> Hi Wolfgang,
>
> i put Pavel and Andrey into CC, maybe they also have an opinion about this.
> I just talked to a specialist who told me, that a higher SJW is better - if
Then let us set it to 4 (maximum), by default. But other documents
recommend a value of 1.
> possible. And if an expert told me so and i had a simple config interface to
> fullfill it, it would be great for me ;-)
Anyway, if SJW does not depend on other bit-timing parameters and it
usually works fine with the kernel calculated parameters I would no
longer vote against this patch.
Wolfgang,
^ permalink raw reply
* [PATCH] tcp: ECN blackhole should not force quickack mode
From: Eric Dumazet @ 2011-09-23 6:02 UTC (permalink / raw)
To: David Miller
Cc: netdev, Jerry Chu, Ilpo Järvinen, Jamal Hadi Salim,
Jim Gettys, Dave Taht
While playing with a new ADSL box at home, I discovered that ECN
blackhole can trigger suboptimal quickack mode on linux : We send one
ACK for each incoming data frame, without any delay and eventual
piggyback.
This is because TCP_ECN_check_ce() considers that if no ECT is seen on a
segment, this is because this segment was a retransmit.
Refine this heuristic and apply it only if we seen ECT in a previous
segment, to detect ECN blackhole at IP level.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Jamal Hadi Salim <jhs@mojatatu.com>
CC: Jerry Chu <hkchu@google.com>
CC: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
CC: Jim Gettys <jg@freedesktop.org>
CC: Dave Taht <dave.taht@gmail.com>
---
Another possibility is to remove this (not in RFC 3168) heuristic, what
do you think ?
include/net/tcp.h | 1 +
net/ipv4/tcp_input.c | 23 ++++++++++++++++-------
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index f357bef..702aefc 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -356,6 +356,7 @@ static inline void tcp_dec_quickack_mode(struct sock *sk,
#define TCP_ECN_OK 1
#define TCP_ECN_QUEUE_CWR 2
#define TCP_ECN_DEMAND_CWR 4
+#define TCP_ECN_SEEN 8
static __inline__ void
TCP_ECN_create_request(struct request_sock *req, struct tcphdr *th)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a5d01b1..5a4408c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -217,16 +217,25 @@ static inline void TCP_ECN_withdraw_cwr(struct tcp_sock *tp)
tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR;
}
-static inline void TCP_ECN_check_ce(struct tcp_sock *tp, struct sk_buff *skb)
+static inline void TCP_ECN_check_ce(struct tcp_sock *tp, const struct sk_buff *skb)
{
- if (tp->ecn_flags & TCP_ECN_OK) {
- if (INET_ECN_is_ce(TCP_SKB_CB(skb)->flags))
- tp->ecn_flags |= TCP_ECN_DEMAND_CWR;
+ if (!(tp->ecn_flags & TCP_ECN_OK))
+ return;
+
+ switch (TCP_SKB_CB(skb)->flags & INET_ECN_MASK) {
+ case INET_ECN_NOT_ECT:
/* Funny extension: if ECT is not set on a segment,
- * it is surely retransmit. It is not in ECN RFC,
- * but Linux follows this rule. */
- else if (INET_ECN_is_not_ect((TCP_SKB_CB(skb)->flags)))
+ * and we already seen ECT on a previous segment,
+ * it is probably a retransmit.
+ */
+ if (tp->ecn_flags & TCP_ECN_SEEN)
tcp_enter_quickack_mode((struct sock *)tp);
+ break;
+ case INET_ECN_CE:
+ tp->ecn_flags |= TCP_ECN_DEMAND_CWR;
+ /* fallinto */
+ default:
+ tp->ecn_flags |= TCP_ECN_SEEN;
}
}
^ permalink raw reply related
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
From: Michael Kerrisk @ 2011-09-23 5:27 UTC (permalink / raw)
To: Benjamin Poirier; +Cc: Neil Horman, linux-man, netdev
In-Reply-To: <20110922124448.GA19801@synalogic.ca>
HI Ben, Neil,
On Thu, Sep 22, 2011 at 2:44 PM, Benjamin Poirier
<benjamin.poirier@gmail.com> wrote:
> On 11-09-22 06:15, Michael Kerrisk wrote:
>> Ben, Neil,
>>
> [snip]
>>
>> Ben, thanks for writing this, and Neil, thanks for reviewing it. I've
>> applied that change for man-pages-3.34.
>>
>> Ben, I added one small piece ti the description of
>> /proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced
>> the entire text below. Perhaps you could take a quick scan, to make
>> sure that the changed text is consistent with the whole piece.
>>
>> Thanks,
>>
>> Michael
>>
>> IP_MTU_DISCOVER (since Linux 2.2)
>> Set or receive the Path MTU Discovery setting for a
>> socket. When enabled, Linux will perform Path MTU Dis-
>> covery as defined in RFC 1191 on SOCK_STREAM sockets.
>
> Oops, seems like there's a repetition that crept in here. I'd keep only
> the first of those two sentences:
>> For non-SOCK_STREAM sockets, IP_PMTUDISC_DO forces the
>> don't-fragment flag to be set on all outgoing packets.
>> The don't-fragment flag is set on all outgoing data-
>> grams.
Thanks for catching that! The second of the above sentences is now gone.
>> It is the user's responsibility to packetize the
>> data in MTU-sized chunks and to do the retransmits if
>> necessary. The kernel will reject (with EMSGSIZE) data-
>> grams that are bigger than the known path MTU.
>> IP_PMTUDISC_WANT will fragment a datagram if needed
>> according to the path MTU, or will set the don't-frag-
>> ment flag otherwise.
>>
>> The system-wide default can be toggled between IP_PMTUD-
>> ISC_WANT and IP_PMTUDISC_DONT by writing (respectively,
>> zero and nonzero values) to the
>> /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>
> I think it's a welcome clarification. Is is normal that IP_PMTUDISC_WANT
> gets hyphenated?
That's just an artifact of groff formatting. One can prevent it, but
then the text justification of some lines starts to look very weird.
>> Path MTU discovery flags Meaning
>
> I agree with what Neil said about "flags" here. setsockopt(2) calls
> these "option values".
Changed this to just "value".
> Other than that, LGTM
> Acked-by: Benjamin Poirier <benjamin.poirier@gmail.com>
>
> Thanks Michael,
> -Ben
You're welcome. Thanks for taking the time to write the text and check my work.
Cheers,
Michael
>> IP_PMTUDISC_WANT Use per-route settings.
>> IP_PMTUDISC_DONT Never do Path MTU Discovery.
>> IP_PMTUDISC_DO Always do Path MTU Discovery.
>> IP_PMTUDISC_PROBE Set DF but ignore Path MTU.
>>
>> When PMTU discovery is enabled, the kernel automatically
>> keeps track of the path MTU per destination host. When
>> it is connected to a specific peer with connect(2), the
>> currently known path MTU can be retrieved conveniently
>> using the IP_MTU socket option (e.g., after an EMSGSIZE
>> error occurred). The path MTU may change over time.
>> For connectionless sockets with many destinations, the
>> new MTU for a given destination can also be accessed
>> using the error queue (see IP_RECVERR). A new error
>> will be queued for every incoming MTU update.
>>
>> While MTU discovery is in progress, initial packets from
>> datagram sockets may be dropped. Applications using UDP
>> should be aware of this and not take it into account for
>> their packet retransmit strategy.
>>
>> To bootstrap the path MTU discovery process on uncon-
>> nected sockets, it is possible to start with a big data-
>> gram size (up to 64K-headers bytes long) and let it
>> shrink by updates of the path MTU.
>>
>> To get an initial estimate of the path MTU, connect a
>> datagram socket to the destination address using con-
>> nect(2) and retrieve the MTU by calling getsockopt(2)
>> with the IP_MTU option.
>>
>> It is possible to implement RFC 4821 MTU probing with
>> SOCK_DGRAM or SOCK_RAW sockets by setting a value of
>> IP_PMTUDISC_PROBE (available since Linux 2.6.22). This
>> is also particularly useful for diagnostic tools such as
>> tracepath(8) that wish to deliberately send probe pack-
>> ets larger than the observed Path MTU.
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Jeff Kirsher @ 2011-09-23 5:23 UTC (permalink / raw)
To: Jesse Barnes, David Miller; +Cc: netdev, Rose, Gregory V
In-Reply-To: <20110923104957.2f76d1a4@jbarnes-x220>
[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]
On Thu, 2011-09-22 at 22:19 -0700, Jesse Barnes wrote:
> On Thu, 22 Sep 2011 21:16:18 -0700
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
>
> > On Wed, Sep 21, 2011 at 03:12, Jeff Kirsher
> > <jeffrey.t.kirsher@intel.com> wrote:
> > > From: Greg Rose <gregory.v.rose@intel.com>
> > >
> > > Device drivers that create and destroy SR-IOV virtual functions via
> > > calls to pci_enable_sriov() and pci_disable_sriov can cause
> > > catastrophic failures if they attempt to destroy VFs while they are
> > > assigned to guest virtual machines. By adding a flag for use by
> > > the KVM module to indicate that a device is assigned a device
> > > driver can check that flag and avoid destroying VFs while they are
> > > assigned and avoid system failures.
> > >
> > > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > ---
> > > include/linux/pci.h | 2 ++
> > > virt/kvm/assigned-dev.c | 2 ++
> > > virt/kvm/iommu.c | 4 ++++
> > > 3 files changed, 8 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > index f27893b..4f511da 100644
> > > --- a/include/linux/pci.h
> > > +++ b/include/linux/pci.h
> > > @@ -174,6 +174,8 @@ enum pci_dev_flags {
> > > PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG = (__force
> > > pci_dev_flags_t) 1, /* Device configuration is irrevocably lost if
> > > disabled into D3 */ PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t)
> > > 2,
> > > + /* Provide indication device is assigned by KVM */
> > > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > > };
> > >
> > > enum pci_irq_reroute_variant {
> > > diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
> > > index 4e9eaeb..eaf3a50 100644
> > > --- a/virt/kvm/assigned-dev.c
> > > +++ b/virt/kvm/assigned-dev.c
> > > @@ -205,6 +205,8 @@ static void kvm_free_assigned_device(struct kvm
> > > *kvm, else
> > > pci_restore_state(assigned_dev->dev);
> > >
> > > + assigned_dev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> > > +
> > > pci_release_regions(assigned_dev->dev);
> > > pci_disable_device(assigned_dev->dev);
> > > pci_dev_put(assigned_dev->dev);
> > > diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
> > > index 78c80f6..967aba1 100644
> > > --- a/virt/kvm/iommu.c
> > > +++ b/virt/kvm/iommu.c
> > > @@ -187,6 +187,8 @@ int kvm_assign_device(struct kvm *kvm,
> > > goto out_unmap;
> > > }
> > >
> > > + pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> > > +
> > > printk(KERN_DEBUG "assign device %x:%x:%x.%x\n",
> > > assigned_dev->host_segnr,
> > > assigned_dev->host_busnr,
> > > @@ -215,6 +217,8 @@ int kvm_deassign_device(struct kvm *kvm,
> > >
> > > iommu_detach_device(domain, &pdev->dev);
> > >
> > > + pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> > > +
> > > printk(KERN_DEBUG "deassign device %x:%x:%x.%x\n",
> > > assigned_dev->host_segnr,
> > > assigned_dev->host_busnr,
> > > --
> > > 1.7.6.2
> >
> > Jesse/Konrad/Ian-
> >
> > I sent this patch out as part of a pull request for David Miller's
> > net-next tree. I know that Greg sent this originally out to the
> > linux-pci mailing list as a RFC. Since Greg also has a patch against
> > ixgbe which implemented this flag, I sent both patches for inclusion
> > into David Miller's net-next.
> >
> > Dave is wanting to ensure that the PCI maintainers have reviewed this
> > and are ok with it before pulls my series of patches.
>
> Yeah I think I looked at this one in the past, my ack must have been
> dropped. You can add it if you want.
>
> Jesse
Thanks Jesse!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Jesse Barnes @ 2011-09-23 5:20 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, konrad.wilk@oracle.com, ijc@hellion.org.uk, Greg Rose,
netdev, gospo, linux-pci
In-Reply-To: <CAL3LdT7jDfytZD7WESmiHxvpmxKTEZ=uWRjzgsR9e4GtBPE31A@mail.gmail.com>
[oops meant to cc everyone, yes this has my ack]
On Thu, 22 Sep 2011 21:16:18 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> On Wed, Sep 21, 2011 at 03:12, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > From: Greg Rose <gregory.v.rose@intel.com>
> >
> > Device drivers that create and destroy SR-IOV virtual functions via
> > calls to pci_enable_sriov() and pci_disable_sriov can cause
> > catastrophic failures if they attempt to destroy VFs while they are
> > assigned to guest virtual machines. By adding a flag for use by
> > the KVM module to indicate that a device is assigned a device
> > driver can check that flag and avoid destroying VFs while they are
> > assigned and avoid system failures.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > include/linux/pci.h | 2 ++
> > virt/kvm/assigned-dev.c | 2 ++
> > virt/kvm/iommu.c | 4 ++++
> > 3 files changed, 8 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index f27893b..4f511da 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -174,6 +174,8 @@ enum pci_dev_flags {
> > PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG = (__force
> > pci_dev_flags_t) 1, /* Device configuration is irrevocably lost if
> > disabled into D3 */ PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t)
> > 2,
> > + /* Provide indication device is assigned by KVM */
> > + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> > };
> >
> > enum pci_irq_reroute_variant {
> > diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
> > index 4e9eaeb..eaf3a50 100644
> > --- a/virt/kvm/assigned-dev.c
> > +++ b/virt/kvm/assigned-dev.c
> > @@ -205,6 +205,8 @@ static void kvm_free_assigned_device(struct kvm
> > *kvm, else
> > pci_restore_state(assigned_dev->dev);
> >
> > + assigned_dev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> > +
> > pci_release_regions(assigned_dev->dev);
> > pci_disable_device(assigned_dev->dev);
> > pci_dev_put(assigned_dev->dev);
> > diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
> > index 78c80f6..967aba1 100644
> > --- a/virt/kvm/iommu.c
> > +++ b/virt/kvm/iommu.c
> > @@ -187,6 +187,8 @@ int kvm_assign_device(struct kvm *kvm,
> > goto out_unmap;
> > }
> >
> > + pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> > +
> > printk(KERN_DEBUG "assign device %x:%x:%x.%x\n",
> > assigned_dev->host_segnr,
> > assigned_dev->host_busnr,
> > @@ -215,6 +217,8 @@ int kvm_deassign_device(struct kvm *kvm,
> >
> > iommu_detach_device(domain, &pdev->dev);
> >
> > + pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> > +
> > printk(KERN_DEBUG "deassign device %x:%x:%x.%x\n",
> > assigned_dev->host_segnr,
> > assigned_dev->host_busnr,
> > --
> > 1.7.6.2
>
> Jesse/Konrad/Ian-
>
> I sent this patch out as part of a pull request for David Miller's
> net-next tree. I know that Greg sent this originally out to the
> linux-pci mailing list as a RFC. Since Greg also has a patch against
> ixgbe which implemented this flag, I sent both patches for inclusion
> into David Miller's net-next.
>
> Dave is wanting to ensure that the PCI maintainers have reviewed this
> and are ok with it before pulls my series of patches.
>
^ permalink raw reply
* Re: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Jeff Kirsher @ 2011-09-23 4:16 UTC (permalink / raw)
To: davem, konrad.wilk@oracle.com, ijc@hellion.org.uk, Jesse Barnes
Cc: Greg Rose, netdev, gospo, Jeff Kirsher, linux-pci
In-Reply-To: <1316599974-23205-2-git-send-email-jeffrey.t.kirsher@intel.com>
On Wed, Sep 21, 2011 at 03:12, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> From: Greg Rose <gregory.v.rose@intel.com>
>
> Device drivers that create and destroy SR-IOV virtual functions via
> calls to pci_enable_sriov() and pci_disable_sriov can cause catastrophic
> failures if they attempt to destroy VFs while they are assigned to
> guest virtual machines. By adding a flag for use by the KVM module
> to indicate that a device is assigned a device driver can check that
> flag and avoid destroying VFs while they are assigned and avoid system
> failures.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> include/linux/pci.h | 2 ++
> virt/kvm/assigned-dev.c | 2 ++
> virt/kvm/iommu.c | 4 ++++
> 3 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index f27893b..4f511da 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -174,6 +174,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_MSI_INTX_DISABLE_BUG = (__force pci_dev_flags_t) 1,
> /* Device configuration is irrevocably lost if disabled into D3 */
> PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> + /* Provide indication device is assigned by KVM */
> + PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
> };
>
> enum pci_irq_reroute_variant {
> diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
> index 4e9eaeb..eaf3a50 100644
> --- a/virt/kvm/assigned-dev.c
> +++ b/virt/kvm/assigned-dev.c
> @@ -205,6 +205,8 @@ static void kvm_free_assigned_device(struct kvm *kvm,
> else
> pci_restore_state(assigned_dev->dev);
>
> + assigned_dev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +
> pci_release_regions(assigned_dev->dev);
> pci_disable_device(assigned_dev->dev);
> pci_dev_put(assigned_dev->dev);
> diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
> index 78c80f6..967aba1 100644
> --- a/virt/kvm/iommu.c
> +++ b/virt/kvm/iommu.c
> @@ -187,6 +187,8 @@ int kvm_assign_device(struct kvm *kvm,
> goto out_unmap;
> }
>
> + pdev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
> +
> printk(KERN_DEBUG "assign device %x:%x:%x.%x\n",
> assigned_dev->host_segnr,
> assigned_dev->host_busnr,
> @@ -215,6 +217,8 @@ int kvm_deassign_device(struct kvm *kvm,
>
> iommu_detach_device(domain, &pdev->dev);
>
> + pdev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
> +
> printk(KERN_DEBUG "deassign device %x:%x:%x.%x\n",
> assigned_dev->host_segnr,
> assigned_dev->host_busnr,
> --
> 1.7.6.2
Jesse/Konrad/Ian-
I sent this patch out as part of a pull request for David Miller's
net-next tree. I know that Greg sent this originally out to the
linux-pci mailing list as a RFC. Since Greg also has a patch against
ixgbe which implemented this flag, I sent both patches for inclusion
into David Miller's net-next.
Dave is wanting to ensure that the PCI maintainers have reviewed this
and are ok with it before pulls my series of patches.
--
Cheers,
Jeff
^ 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