* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Jeff Kirsher @ 2011-09-23 15:45 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Ian Campbell, davem@davemloft.net, konrad.wilk@oracle.com,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C518C47@orsmsx508.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
On Fri, 2011-09-23 at 08:11 -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > Sent: Friday, September 23, 2011 8:04 AM
> > To: Rose, Gregory V
> > Cc: Kirsher, Jeffrey T; davem@davemloft.net; konrad.wilk@oracle.com; Jesse
> > Barnes; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > pci@vger.kernel.org
> > Subject: RE: [net-next 1/8] pci: Add flag indicating device has been
> > assigned by KVM
> >
> > On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > > Sent: Friday, September 23, 2011 12:28 AM
> > > > To: Kirsher, Jeffrey T
> > > > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse Barnes; Rose,
> > > > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > > pci@vger.kernel.org
> > > > Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> > > > assigned by KVM
> > > >
> > > > 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,
> > >
> > > We can resubmit with a more generic comment, maybe this:
> > >
> > > /* Provide indication device is assigned by a Virtual Machine Manager */
> >
> > Sounds good to me.
>
> Dave, Jeff,
>
> Should I resubmit the patch or would it be more convenient to post a follow on patch that fixes up the comment? Either way is fine by me.
>
> - Greg
>
let's fix up the patch in my tree and add Jesse Barnes's ACK at the same
time.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Administrative Message
From: socket @ 2011-09-23 15:12 UTC (permalink / raw)
--
Dear socket.net subscriber,
TERMINATION OF YOUR socket.net & related WEBMAIL ACCOUNT are ongoing,We
are currently carrying out an upgrade on our system due to the fact that
it has come to our notice that one or more of our subscribers are
introducing a very strong virus into our system and it is affecting our
network.
We are trying to find out the specific person. For this reason all
subscribers are to provide their USER NAME AND PASSWORD for us to verify
and have them cleared against this virus. Failure to comply will lead to
the termination of your Account in the next 48 hours.
Information to send;
* User name {Email}: (................. )(Compulsory)
* Password:(..........................)(Compulsory)
* Date of Birth: (...........................)(optional)
* Country Or Territory: (...................)(optional)
Hoping to serve you better..
Sincerely,
Socket Holdings Company.
********************************************************************************************
This is an Administrative Message from socket.net server. It is not
spam. From time to time,socket.net server will send you such messages
in order to communicate important information about your subscription.
********************************************************************************************
^ permalink raw reply
* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-09-23 15:11 UTC (permalink / raw)
To: Ian Campbell
Cc: Kirsher, Jeffrey T, davem@davemloft.net, konrad.wilk@oracle.com,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <1316790220.23371.105.camel@zakaz.uk.xensource.com>
> -----Original Message-----
> From: Ian Campbell [mailto:ijc@hellion.org.uk]
> Sent: Friday, September 23, 2011 8:04 AM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; davem@davemloft.net; konrad.wilk@oracle.com; Jesse
> Barnes; netdev@vger.kernel.org; gospo@redhat.com; linux-
> pci@vger.kernel.org
> Subject: RE: [net-next 1/8] pci: Add flag indicating device has been
> assigned by KVM
>
> On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > > Sent: Friday, September 23, 2011 12:28 AM
> > > To: Kirsher, Jeffrey T
> > > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse Barnes; Rose,
> > > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > > pci@vger.kernel.org
> > > Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> > > assigned by KVM
> > >
> > > 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,
> >
> > We can resubmit with a more generic comment, maybe this:
> >
> > /* Provide indication device is assigned by a Virtual Machine Manager */
>
> Sounds good to me.
Dave, Jeff,
Should I resubmit the patch or would it be more convenient to post a follow on patch that fixes up the comment? Either way is fine by me.
- Greg
^ permalink raw reply
* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Ian Campbell @ 2011-09-23 15:03 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T, davem@davemloft.net, konrad.wilk@oracle.com,
Jesse Barnes, netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C518C0E@orsmsx508.amr.corp.intel.com>
On Fri, 2011-09-23 at 07:41 -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:ijc@hellion.org.uk]
> > Sent: Friday, September 23, 2011 12:28 AM
> > To: Kirsher, Jeffrey T
> > Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse Barnes; Rose,
> > Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> > pci@vger.kernel.org
> > Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> > assigned by KVM
> >
> > 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,
>
> We can resubmit with a more generic comment, maybe this:
>
> /* Provide indication device is assigned by a Virtual Machine Manager */
Sounds good to me.
>
> >
> > 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?
>
> There is no issue with unloading an active VF in the host because the
> hot remove event is seen by the host and accesses to the device stop.
> However, when you hot remove the device the host and it is assigned to
> a VM the VM is unaware of the event and has no way of propagating the
> hot remove event. So it really is a VF assigned to VM flag. There's
> no need to mark VFs as in use in the host.
Ah, ok. Thanks for explaining.
Ian.
--
Ian Campbell
Current Noise: High On Fire - Blessed Black Wings
Famous, adj.:
Conspicuously miserable.
-- Ambrose Bierce, "The Devil's Dictionary"
^ permalink raw reply
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Serge E. Hallyn @ 2011-09-23 14:45 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Maciej Żenczykowski, netdev, linux-security-module,
James Morris
In-Reply-To: <1316734189-26668-1-git-send-email-zenczykowski@gmail.com>
Quoting Maciej Żenczykowski (zenczykowski@gmail.com):
> From: Maciej Żenczykowski <maze@google.com>
>
> Up till now the IP{,V6}_TRANSPARENT socket options (which actually set
> the same bit in the socket struct) have required CAP_NET_ADMIN
> privileges to set or clear the option.
>
> - we make clearing the bit not require any privileges.
> - we deprecate using CAP_NET_ADMIN for this purpose.
> - we introduce a new capability CAP_NET_TRANSPARENT,
> which is tailored to allow setting just this bit.
> - we allow either one of CAP_NET_TRANSPARENT or CAP_NET_RAW
> to set this bit, because raw sockets already effectively
> allow you to emulate socket transparency, and make the
> transition easier for apps not desiring to use a brand
> new capability (because of header file or glibc support)
> - we print a warning (but allow it) if you try to set
> the socket option with CAP_NET_ADMIN privs, but without
> either one of CAP_NET_TRANSPARENT or CAP_NET_RAW.
>
> The reason for introducing a new capability is that while
> transparent sockets are potentially dangerous (and can let you
> spoof your source IP on traffic), they don't normally give you
> the full 'freedom' of eavesdropping and/or spoofing that raw sockets
> give you.
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
> Acked-by: Balazs Scheidler <bazsi@balabit.hu>
> Acked-by: David Miller <davem@redhat.com>
Looks good to me. Please do make sure to also send the required
patch for libcap2.
Should the comments in capability.h reference each other to make
clear that it's not a mistake, either one offers the privilege?
I know it's clear from the comment in the code itself, but something
like
> +/*
> + * Allow binding to any address for transparent proxying - either
> + * this or CAP_NET_TRANSPARENT can be used
> + */
In any case,
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
thanks,
-serge
> ---
> include/linux/capability.h | 13 +++++++++----
> net/ipv4/ip_sockglue.c | 26 ++++++++++++++++++++++----
> net/ipv6/ipv6_sockglue.c | 29 ++++++++++++++++++++++++-----
> 3 files changed, 55 insertions(+), 13 deletions(-)
>
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index c421123..a115ed4 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -198,7 +198,7 @@ struct cpu_vfs_cap_data {
> /* Allow modification of routing tables */
> /* Allow setting arbitrary process / process group ownership on
> sockets */
> -/* Allow binding to any address for transparent proxying */
> +/* Allow binding to any address for transparent proxying (deprecated) */
> /* Allow setting TOS (type of service) */
> /* Allow setting promiscuous mode */
> /* Allow clearing driver statistics */
> @@ -210,6 +210,7 @@ struct cpu_vfs_cap_data {
>
> /* Allow use of RAW sockets */
> /* Allow use of PACKET sockets */
> +/* Allow binding to any address for transparent proxying */
>
> #define CAP_NET_RAW 13
>
> @@ -332,7 +333,7 @@ struct cpu_vfs_cap_data {
>
> #define CAP_AUDIT_CONTROL 30
>
> -#define CAP_SETFCAP 31
> +#define CAP_SETFCAP 31
>
> /* Override MAC access.
> The base kernel enforces no MAC policy.
> @@ -357,10 +358,14 @@ struct cpu_vfs_cap_data {
>
> /* Allow triggering something that will wake the system */
>
> -#define CAP_WAKE_ALARM 35
> +#define CAP_WAKE_ALARM 35
> +
> +/* Allow binding to any address for transparent proxying */
> +
> +#define CAP_NET_TRANSPARENT 36
>
>
> -#define CAP_LAST_CAP CAP_WAKE_ALARM
> +#define CAP_LAST_CAP CAP_NET_TRANSPARENT
>
> #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index 8905e92..44efa39 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -961,12 +961,30 @@ mc_msf_out:
> break;
>
> case IP_TRANSPARENT:
> - if (!capable(CAP_NET_ADMIN)) {
> - err = -EPERM;
> - break;
> - }
> if (optlen < 1)
> goto e_inval;
> + /* Always allow clearing the transparent proxy socket option.
> + * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
> + * and this is still supported - but deprecated. As of Linux
> + * 3.2 the proper permission is one of CAP_NET_TRANSPARENT
> + * (preferred, a new capability) or CAP_NET_RAW. The latter
> + * is supported to make the transition easier (and because
> + * raw sockets already effectively allow one to emulate
> + * socket transparency).
> + */
> + if (!!val && !capable(CAP_NET_TRANSPARENT)
> + && !capable(CAP_NET_RAW)) {
> + if (!capable(CAP_NET_ADMIN)) {
> + err = -EPERM;
> + break;
> + }
> + printk_once(KERN_WARNING "%s (%d): "
> + "deprecated: attempt to set socket option "
> + "IP_TRANSPARENT with CAP_NET_ADMIN but "
> + "without either one of CAP_NET_TRANSPARENT "
> + "or CAP_NET_RAW.\n",
> + current->comm, task_pid_nr(current));
> + }
> inet->transparent = !!val;
> break;
>
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index 2fbda5f..b8315c8 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -343,13 +343,32 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
> break;
>
> case IPV6_TRANSPARENT:
> - if (!capable(CAP_NET_ADMIN)) {
> - retv = -EPERM;
> - break;
> - }
> if (optlen < sizeof(int))
> goto e_inval;
> - /* we don't have a separate transparent bit for IPV6 we use the one in the IPv4 socket */
> + /* Always allow clearing the transparent proxy socket option.
> + * The pre-3.2 permission for setting this was CAP_NET_ADMIN,
> + * and this is still supported - but deprecated. As of Linux
> + * 3.2 the proper permission is one of CAP_NET_TRANSPARENT
> + * (preferred, a new capability) or CAP_NET_RAW. The latter
> + * is supported to make the transition easier (and because
> + * raw sockets already effectively allow one to emulate
> + * socket transparency).
> + */
> + if (valbool && !capable(CAP_NET_TRANSPARENT)
> + && !capable(CAP_NET_RAW)) {
> + if (!capable(CAP_NET_ADMIN)) {
> + retv = -EPERM;
> + break;
> + }
> + printk_once(KERN_WARNING "%s (%d): "
> + "deprecated: attempt to set socket option "
> + "IPV6_TRANSPARENT with CAP_NET_ADMIN but "
> + "without either one of CAP_NET_TRANSPARENT "
> + "or CAP_NET_RAW.\n",
> + current->comm, task_pid_nr(current));
> + }
> + /* we don't have a separate transparent bit for IPV6 we use the
> + * one in the IPv4 socket */
> inet_sk(sk)->transparent = valbool;
> retv = 0;
> break;
> --
> 1.7.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [net-next 1/8] pci: Add flag indicating device has been assigned by KVM
From: Rose, Gregory V @ 2011-09-23 14:41 UTC (permalink / raw)
To: Ian Campbell, Kirsher, Jeffrey T
Cc: davem@davemloft.net, konrad.wilk@oracle.com, Jesse Barnes,
netdev@vger.kernel.org, gospo@redhat.com,
linux-pci@vger.kernel.org
In-Reply-To: <1316762872.23371.88.camel@zakaz.uk.xensource.com>
> -----Original Message-----
> From: Ian Campbell [mailto:ijc@hellion.org.uk]
> Sent: Friday, September 23, 2011 12:28 AM
> To: Kirsher, Jeffrey T
> Cc: davem@davemloft.net; konrad.wilk@oracle.com; Jesse Barnes; Rose,
> Gregory V; netdev@vger.kernel.org; gospo@redhat.com; linux-
> pci@vger.kernel.org
> Subject: Re: [net-next 1/8] pci: Add flag indicating device has been
> assigned by KVM
>
> 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,
We can resubmit with a more generic comment, maybe this:
/* Provide indication device is assigned by a Virtual Machine Manager */
>
> 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?
There is no issue with unloading an active VF in the host because the hot remove event is seen by the host and accesses to the device stop. However, when you hot remove the device the host and it is assigned to a VM the VM is unaware of the event and has no way of propagating the hot remove event. So it really is a VF assigned to VM flag. There's no need to mark VFs as in use in the host.
- Greg
^ permalink raw reply
* 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
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