* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
From: Herbert Xu @ 2011-09-21 12:24 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20110921115727.GX1808@secunet.com>
On Wed, Sep 21, 2011 at 01:57:27PM +0200, Steffen Klassert wrote:
>
> Well, I've got pretty reproduceable crashes when the sender of
> the IPsec packets introduces reorder, that's why I noticed this.
>
> The problem is, that the replay check function is called before
> the asynchronous crypto processing and the replay advance function
> is called after resume from the asynchronous processing. So
> we can submit multiple packets to the crypto layer without
> updating the replay window. This means that the replay check
> function accepts packets that should have been dropped, because
> they are reordered and more than 'replay window size' packets
> to late. This leads to a crash as we try to update the replay
> window beyond the allocated bounds.
OK I see what you mean now.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 3/3] net/fec: add imx6q enet support
From: Wolfram Sang @ 2011-09-21 12:26 UTC (permalink / raw)
To: Shawn Guo
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921115821.GF28907@S2100-06.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
On Wed, Sep 21, 2011 at 07:58:22PM +0800, Shawn Guo wrote:
> On Wed, Sep 21, 2011 at 01:32:39PM +0200, Wolfram Sang wrote:
> >
> > > +/* Controller has GBIT support */
> > > +#define FEC_QUIRK_HAS_GBIT (1 << 3)
> >
> > Heh, this is not really a quirk, but a nice feature :) I think we can
> > drop QUIRK if we see driver_data more as "flags" instead of "quirks"?
> > Minor, though.
> >
> As you have told, all these FEC_QUIRK_* are just flags actually. The
> name was pick to keep the consistency, as they are all used for the
> same purpose.
I think introducing FEC_FEATURE_HAS_GBIT would be consistent enough, but
as I said, I don't mind much.
> > Also minor, but the patch looks like a good oportunity to start
> > replacing magic values with proper defines?
> >
> There are already so many magic numbers. It really deserves a separated
> patch.
That is the other possibility, yes. Which sadly never happened.
> I heard that Uwe had a plan to do that some time ago. He gives up
> now? :)
I don't know about this case. Also, it is not about blaming here. It is
totally okay for you to say that you don't want to change your patch to
start replacing the magic values. I mainly wanted to point out the
oportunity here.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Hello my love, My name is jane ferguson,i come across and read through your profile today and i became interested in you,i will also like to know you the more,and i want you to send an e-mail to my e-mail address so i can give you my picture for you to know whom i am and for the both of us to know each other very well and better in life,and we can achieve it in future because ture love and feeling means alot in future.Here is my private e-mail address you can contact me with it.(jane.ferguson@gala.net )I am waiting for your mail to my e-mail address above and aslo, Remember the distance or colour does not matter but love,feeling,e-motions and sympathetic love matters alot in life. Thanks,and i promise to be honest and to keep a very good relationship with you. jane. ja ne.ferguson@gala.net
From: jane ferguson @ 2011-09-21 12:24 UTC (permalink / raw)
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Shawn Guo @ 2011-09-21 12:44 UTC (permalink / raw)
To: Wolfram Sang
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921121159.GG1966@pengutronix.de>
On Wed, Sep 21, 2011 at 02:11:59PM +0200, Wolfram Sang wrote:
> On Wed, Sep 21, 2011 at 08:03:42PM +0800, Shawn Guo wrote:
> > On Wed, Sep 21, 2011 at 01:25:55PM +0200, Wolfram Sang wrote:
> > > Hi Shawn,
> > >
> > > On Wed, Sep 21, 2011 at 07:10:30PM +0800, Shawn Guo wrote:
> > > > 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.
> > > > So it makes more sense to have the phy-reset-gpio request failure as
> > > > a debug message rather than a warning.
> > >
> > > Or remove it entirely?
> > >
> > I would like to keep it. When people want to debug at this point, they
> > do not need to type the debug message.
>
> I just think the message might be confusing in case you don't need the
> gpio, because then failing is expected behaviour. For those platforms,
> it is not even an error then, so you must drop returning the error. To
> be very precise, you should check of_get_named_gpio() and return if no
> gpio is specified. Then, you can distinguish that case from problems
> when getting the GPIO.
>
The whole fec_reset_phy() should not be a show-stopper failure. Even
on platforms that have the gpio, FEC can work without resetting the
phy in FEC driver for some cases, for example, boot loader has done it.
It might be good enough to give a warning message rather than getting
the probe fail.
> > > I also wanted to suggested to drop returning the error code, since it is
> > > not an error anymore, strictly speaking. Then I noticed that the caller
> > > does not check the error code. So, this could be added or turn the
> > > function to void?
> > >
> > To me, keep the return value as integer is more scalable. Someday,
> > someone need to add more stuff in the function, or want to improve
> > the caller to check return value, it plays.
>
> I agree that keeping it int is way better. But why not add it now to
> keep things proper and tested? If this patch gets accepted as it is and
> later someone else will add error checking to the caller, your platform
> will lose FEC support as a regression.
>
Again, fec_reset_phy() failure is not a show-stopper. We might not
want to make the probe fail because of that.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Wolfram Sang @ 2011-09-21 12:59 UTC (permalink / raw)
To: Shawn Guo
Cc: Shawn Guo, David S. Miller, patches, netdev, Troy Kisky,
Francois Romieu, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921124423.GI28907@S2100-06.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
> > I agree that keeping it int is way better. But why not add it now to
> > keep things proper and tested? If this patch gets accepted as it is and
> > later someone else will add error checking to the caller, your platform
> > will lose FEC support as a regression.
> >
> Again, fec_reset_phy() failure is not a show-stopper. We might not
> want to make the probe fail because of that.
That would be an argument to make the function returning void?
Well, I still think something like
/* No phy reset configured */
if (phy_reset == -ENODEV)
return 0;
might be cleaner, yet I don't have the setup to test such an approach.
So, I'll be quiet now and hope for no problems.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* TCP_DELACK_MIN vs TCP_ATO_MIN
From: Daniel Baluta @ 2011-09-21 12:59 UTC (permalink / raw)
To: netdev, kernelnewbies
Hello,
RFC2582, Section 4.2 says:
"... an ACK SHOULD be generated for at least every second
full-sized segment, and MUST be generated within 500 ms
of the arrival of the first unacknowledged packet. ".
I guess that the delayed ACK timeout is computed in tcp_send_delayed_ack:
===
void tcp_send_delayed_ack(struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
int ato = icsk->icsk_ack.ato;
unsigned long timeout;
/* .... */
/* Stay within the limit we were given */
timeout = jiffies + ato;
====
Can one explain what is the difference between TCP_DELACK_MIN and
TCP_ATO_MIN, specifically if the timeout (ato) is always in the interval
[TCP_DELACK_MIN, TCP_DELACK_MAX] ?
I want to make the delayed ack timeout configurable as some guys tried
here [1],
so for this reason I plan to make TCP_DELACK_MIN and TCP_DELACK_MAX
tunable via proc entries.
thanks,
Daniel.
[1] http://kerneltrap.org/mailarchive/linux-netdev/2008/9/9/3245554
^ permalink raw reply
* Re: [PATCH v2 1/3] net/fec: change phy-reset-gpio request warning to debug message
From: Shawn Guo @ 2011-09-21 13:18 UTC (permalink / raw)
To: Wolfram Sang
Cc: patches, netdev, Troy Kisky, Francois Romieu, Shawn Guo,
David S. Miller, linux-arm-kernel, Lothar Waßmann
In-Reply-To: <20110921125905.GI1966@pengutronix.de>
On Wed, Sep 21, 2011 at 02:59:05PM +0200, Wolfram Sang wrote:
> > > I agree that keeping it int is way better. But why not add it now to
> > > keep things proper and tested? If this patch gets accepted as it is and
> > > later someone else will add error checking to the caller, your platform
> > > will lose FEC support as a regression.
> > >
> > Again, fec_reset_phy() failure is not a show-stopper. We might not
> > want to make the probe fail because of that.
>
> That would be an argument to make the function returning void?
>
Hmm, it seems to be. Ok, will send v3 to return void.
Regards,
Shawn
> Well, I still think something like
>
> /* No phy reset configured */
> if (phy_reset == -ENODEV)
> return 0;
>
> might be cleaner, yet I don't have the setup to test such an approach.
>
> So, I'll be quiet now and hope for no problems.
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* FYI
From: Christele.Moussu @ 2011-09-21 12:51 UTC (permalink / raw)
After much attempts to reach you on phone, I deemed it necessary and urgent to contact you via your e-mail address and to notify you finally about your outstanding compensation payment.
During our last annual calculation of your banking activities we have realized that you are eligible to receive a compensation payment of $2,811,041.00 USD.
This compensation is being made to all of you who have suffered loss as a result of fraud, accident or illness.
For more info, contact the assigned UPS agent for the delivery of your cashier check.
Name: Ford Hamilton
Tel: +2348072178475
E-mail: ups-cs1@helixnet.cn
Please take note that you will pay a shipping/handling fee of $95.00 USD to UPS.
Thank you for your patience.
Moussu Christele
United Nation Human Settlement Programme
^ permalink raw reply
* Hello my love, My name is jane ferguson,i come across and read through your profile today and i became interested in you,i will also like to know you the more,and i want you to send an e-mail to my e-mail address so i can give you my picture for you to know whom i am and for the both of us to know each other very well and better in life,and we can achieve it in future because ture love and feeling means alot in future.Here is my private e-mail address you can contact me with it.(jane.ferguson@gala.net )I am waiting for your mail to my e-mail address above and aslo, Remember the distance or colour does not matter but love,feeling,e-motions and sympathetic love matters alot in life. Thanks,and i promise to be honest and to keep a very good relationship with you. jane. ja ne.ferguson@gala.net
From: jane ferguson @ 2011-09-21 14:08 UTC (permalink / raw)
^ permalink raw reply
* Re: TCP_DELACK_MIN vs TCP_ATO_MIN
From: rohan puri @ 2011-09-21 14:58 UTC (permalink / raw)
To: Daniel Baluta; +Cc: netdev, kernelnewbies
In-Reply-To: <CAEnQRZAObcdhikY6GzG3mC1KZjgK8Xp5LzNetczmZP=BRPqN6w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2036 bytes --]
On Wed, Sep 21, 2011 at 6:29 PM, Daniel Baluta <daniel.baluta@gmail.com>wrote:
> Hello,
>
> RFC2582, Section 4.2 says:
>
> "... an ACK SHOULD be generated for at least every second
> full-sized segment, and MUST be generated within 500 ms
> of the arrival of the first unacknowledged packet. ".
>
>
> I guess that the delayed ACK timeout is computed in tcp_send_delayed_ack:
>
> ===
> void tcp_send_delayed_ack(struct sock *sk)
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
> int ato = icsk->icsk_ack.ato;
> unsigned long timeout;
>
> /* .... */
> /* Stay within the limit we were given */
> timeout = jiffies + ato;
> ====
>
>
> Can one explain what is the difference between TCP_DELACK_MIN and
> TCP_ATO_MIN, specifically if the timeout (ato) is always in the interval
> [TCP_DELACK_MIN, TCP_DELACK_MAX] ?
>
> I want to make the delayed ack timeout configurable as some guys tried
> here [1],
> so for this reason I plan to make TCP_DELACK_MIN and TCP_DELACK_MAX
> tunable via proc entries.
>
> thanks,
> Daniel.
>
> [1] http://kerneltrap.org/mailarchive/linux-netdev/2008/9/9/3245554
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
Hi Daniel,
TCP in linux makes use of two modes for acking the data received.
1. Quick Ack : - Used at the start of the TCP connection so that the
congestion window can grow fastly.
2. Delayed Ack : - It moves to delayed ack mode, in which ack is sent for
multiple packets.
TCP switches between the two modes depending on the congestion experienced.
In Quick Ack, Ack timeout interval (ato) is set to minimum i.e. TCP_ATO_MIN
while in Delayed Ack mode, TCP_DELACK_MIN is used for restarting/ resetting
the timer.
Now the default value is of both the macros is same.
But if you want to make delayed ack timeout configurable, then I think you
should give proc interface for TCP_DELACK_MIN.
Regards,
Rohan Puri
[-- Attachment #1.2: Type: text/html, Size: 2732 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply
* Re: RFS issue: no HW filter for paused stream
From: Ben Hutchings @ 2011-09-21 15:09 UTC (permalink / raw)
To: amirv; +Cc: Tom Herbert, oren, liranl, netdev, Diego Crupnicoff
In-Reply-To: <4E783855.4020907@dev.mellanox.co.il>
On Tue, 2011-09-20 at 09:53 +0300, Amir Vadai wrote:
> This will unset the current CPU of the rflow that belongs to the desired
> CPU.
> The problem is when the stream resumes and it goes to the wrong RXQ - in
> our HW, it will be according to RSS, as long as there is no specific
> flow steering rule for the stream.
Sorry, yes. Told you I didn't test my patch!
> We need to unset the current CPU of the rflow of the actual RXQ that the
> packet arrived at:
[...]
> Or even better, not set it in the first place - but I'm not sure I
> undersdtand the implications on RPS:
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 4b9981c..748acdb 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2654,7 +2654,7 @@ set_rps_cpu(struct net_device *dev, struct sk_buff
> *skb,
> {
> u16 tcpu;
>
> - tcpu = rflow->cpu = next_cpu;
> + tcpu = next_cpu;
> if (tcpu != RPS_NO_CPU) {
> #ifdef CONFIG_RFS_ACCEL
> struct netdev_rx_queue *rxqueue;
>
>
But that means we never move the flow to a new CPU in the non-
accelerated case. So maybe the proper change would be:
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2652,10 +2652,7 @@ static struct rps_dev_flow *
set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
struct rps_dev_flow *rflow, u16 next_cpu)
{
- u16 tcpu;
-
- tcpu = rflow->cpu = next_cpu;
- if (tcpu != RPS_NO_CPU) {
+ if (next_cpu != RPS_NO_CPU) {
#ifdef CONFIG_RFS_ACCEL
struct netdev_rx_queue *rxqueue;
struct rps_dev_flow_table *flow_table;
@@ -2683,16 +2680,16 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
goto out;
old_rflow = rflow;
rflow = &flow_table->flows[flow_id];
- rflow->cpu = next_cpu;
rflow->filter = rc;
if (old_rflow->filter == rflow->filter)
old_rflow->filter = RPS_NO_FILTER;
out:
#endif
rflow->last_qtail =
- per_cpu(softnet_data, tcpu).input_queue_head;
+ per_cpu(softnet_data, next_cpu).input_queue_head;
}
+ rflow->cpu = next_cpu;
return rflow;
}
--- END ---
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: TCP_DELACK_MIN vs TCP_ATO_MIN
From: Daniel Baluta @ 2011-09-21 15:28 UTC (permalink / raw)
To: rohan puri; +Cc: netdev, kernelnewbies
In-Reply-To: <CALJfu6MnV0se8YCTWt65=_4PcOhKsbvUgRmaNxbjf7La+4ar4g@mail.gmail.com>
> Now the default value is of both the macros is same.
>
> But if you want to make delayed ack timeout configurable, then I think you
> should give proc interface for TCP_DELACK_MIN.
Thanks Rohan. Then also I have to export TCP_DELACK_MAX since I think
ato cannot grow over this value.
thanks,
Daniel.
^ permalink raw reply
* [PATCH v3 2/3] net/fec: fix fec1 check in fec_enet_mii_init()
From: Shawn Guo @ 2011-09-21 16:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316621270-27805-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 v3 3/3] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-21 16:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316621270-27805-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 | 61 +++++++++++++++++++++++++------
2 files changed, 53 insertions(+), 17 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..3101d05 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,10 @@
#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)
+/* Controller's phy_speed bit field need to minus one */
+#define FEC_QUIRK_PHY_SPEED_MINUS_ONE (1 << 4)
static struct platform_device_id fec_devtype[] = {
{
@@ -88,6 +92,10 @@ 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 |
+ FEC_QUIRK_PHY_SPEED_MINUS_ONE,
+ }, {
/* sentinel */
}
};
@@ -97,12 +105,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 +383,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 +453,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 +494,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 +513,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 +529,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 +947,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 +980,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;
@@ -1008,6 +1043,8 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
*/
fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000) << 1;
+ if (id_entry->driver_data & FEC_QUIRK_PHY_SPEED_MINUS_ONE)
+ fep->phy_speed--;
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
fep->mii_bus = mdiobus_alloc();
--
1.7.4.1
^ permalink raw reply related
* [PATCH v3 1/3] net/fec: fec_reset_phy() does not need to always succeed
From: Shawn Guo @ 2011-09-21 16:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316621270-27805-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 v3 0/3] add fec support for imx6q
From: Shawn Guo @ 2011-09-21 16:07 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 fixed the frame endian issue found on imx28,
and added 1 Gbps support.
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 | 76 +++++++++++++++++++++++---------
2 files changed, 59 insertions(+), 26 deletions(-)
^ permalink raw reply
* Re: [PATCH 39/57] net: irq: Remove IRQF_DISABLED
From: David Miller @ 2011-09-21 17:40 UTC (permalink / raw)
To: yong.zhang0
Cc: linux-arch, linux-kernel, tglx, perex, leitao, olof, nico,
steve.glendinning, geoff, t.sailer, jreuter, klaus.kudielka, jpr,
samuel, chunkeey, linville, jeffrey.t.kirsher, jpirko, bob.liu,
grundler, ralf, blogic, marc, lucas.demarchi, joe,
uclinux-dist-devel, netdev, cbe-oss-dev, linux-hams,
linux-wireless
In-Reply-To: <1316597339-29861-40-git-send-email-yong.zhang0@gmail.com>
From: Yong Zhang <yong.zhang0@gmail.com>
Date: Wed, 21 Sep 2011 17:28:40 +0800
> Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
>
> So now this flag is a NOOP and can be removed.
>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* (unknown),
From: Coca Cola @ 2011-09-21 18:16 UTC (permalink / raw)
Attn: Sir/Madam,
This is to inform you that you have won
$ 1,000,000.00 (One Million Dollars) in
Coca Cola seasonal promo. Further
informations will be shared upon
response from you.
Thank you,
Kevin Howards,
Regional Director
Coca Cola Plc.
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: Greg Thelen @ 2011-09-21 18:47 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
netdev, linux-mm, kirill
In-Reply-To: <1316393805-3005-3-git-send-email-glommer@parallels.com>
On Sun, Sep 18, 2011 at 5:56 PM, Glauber Costa <glommer@parallels.com> wrote:
> We aim to control the amount of kernel memory pinned at any
> time by tcp sockets. To lay the foundations for this work,
> this patch adds a pointer to the kmem_cgroup to the socket
> structure.
>
> Signed-off-by: Glauber Costa <glommer@parallels.com>
> CC: David S. Miller <davem@davemloft.net>
> CC: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
> CC: Eric W. Biederman <ebiederm@xmission.com>
...
> +void sock_update_memcg(struct sock *sk)
> +{
> + /* right now a socket spends its whole life in the same cgroup */
> + BUG_ON(sk->sk_cgrp);
> +
> + rcu_read_lock();
> + sk->sk_cgrp = mem_cgroup_from_task(current);
> +
> + /*
> + * We don't need to protect against anything task-related, because
> + * we are basically stuck with the sock pointer that won't change,
> + * even if the task that originated the socket changes cgroups.
> + *
> + * What we do have to guarantee, is that the chain leading us to
> + * the top level won't change under our noses. Incrementing the
> + * reference count via cgroup_exclude_rmdir guarantees that.
> + */
> + cgroup_exclude_rmdir(mem_cgroup_css(sk->sk_cgrp));
This grabs a css_get() reference, which prevents rmdir (will return
-EBUSY). How long is this reference held? I wonder about the case
where a process creates a socket in memcg M1 and later is moved into
memcg M2. At that point an admin would expect to be able to 'rmdir
M1'. I think this rmdir would return -EBUSY and I suspect it would be
difficult for the admin to understand why the rmdir of M1 failed. It
seems that to rmdir a memcg, an admin would have to kill all processes
that allocated sockets while in M1. Such processes may not still be
in M1.
> + rcu_read_unlock();
> +}
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: Glauber Costa @ 2011-09-21 18:59 UTC (permalink / raw)
To: Greg Thelen
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
netdev, linux-mm, kirill
In-Reply-To: <CAHH2K0YgkG2J_bO+U9zbZYhTTqSLvr6NtxKxN8dRtfHs=iB8iA@mail.gmail.com>
On 09/21/2011 03:47 PM, Greg Thelen wrote:
> On Sun, Sep 18, 2011 at 5:56 PM, Glauber Costa<glommer@parallels.com> wrote:
>> We aim to control the amount of kernel memory pinned at any
>> time by tcp sockets. To lay the foundations for this work,
>> this patch adds a pointer to the kmem_cgroup to the socket
>> structure.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
> ...
>> +void sock_update_memcg(struct sock *sk)
>> +{
>> + /* right now a socket spends its whole life in the same cgroup */
>> + BUG_ON(sk->sk_cgrp);
>> +
>> + rcu_read_lock();
>> + sk->sk_cgrp = mem_cgroup_from_task(current);
>> +
>> + /*
>> + * We don't need to protect against anything task-related, because
>> + * we are basically stuck with the sock pointer that won't change,
>> + * even if the task that originated the socket changes cgroups.
>> + *
>> + * What we do have to guarantee, is that the chain leading us to
>> + * the top level won't change under our noses. Incrementing the
>> + * reference count via cgroup_exclude_rmdir guarantees that.
>> + */
>> + cgroup_exclude_rmdir(mem_cgroup_css(sk->sk_cgrp));
>
> This grabs a css_get() reference, which prevents rmdir (will return
> -EBUSY).
Yes.
How long is this reference held?
For the socket lifetime.
> I wonder about the case
> where a process creates a socket in memcg M1 and later is moved into
> memcg M2. At that point an admin would expect to be able to 'rmdir
> M1'. I think this rmdir would return -EBUSY and I suspect it would be
> difficult for the admin to understand why the rmdir of M1 failed. It
> seems that to rmdir a memcg, an admin would have to kill all processes
> that allocated sockets while in M1. Such processes may not still be
> in M1.
>
>> + rcu_read_unlock();
>> +}
I agree. But also, don't see too much ways around it without
implementing full task migration.
Right now I am working under the assumption that tasks are long lived
inside the cgroup. Migration potentially introduces some nasty locking
problems in the mem_schedule path.
Also, unless I am missing something, the memcg already has the policy of
not carrying charges around, probably because of this very same complexity.
True that at least it won't EBUSY you... But I think this is at least a
way to guarantee that the cgroup under our nose won't disappear in the
middle of our allocations.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next 0/8][pull request] Intel Wired LAN Driver Update
From: David Miller @ 2011-09-21 19:13 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1316599974-23205-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 21 Sep 2011 03:12:46 -0700
> - reconfigure SR-IOV init to take advantage of the new pci flag
Has this gotten any review from the PCI maintainers?
^ permalink raw reply
* Re: [PATCH resend] fib:fix BUG_ON in fib_nl_newrule when add new fib rule
From: David Miller @ 2011-09-21 19:17 UTC (permalink / raw)
To: wanlong.gao; +Cc: linux-kernel, netdev, omarapazanadi, gaofeng, eric.dumazet
In-Reply-To: <1315791365-5324-1-git-send-email-wanlong.gao@gmail.com>
From: Wanlong Gao <wanlong.gao@gmail.com>
Date: Mon, 12 Sep 2011 09:36:05 +0800
> From: Gao feng <gaofeng@cn.fujitsu.com>
>
> add new fib rule can cause BUG_ON happen
> the reproduce shell is
> ip rule add pref 38
> ip rule add pref 38
> ip rule add to 192.168.3.0/24 goto 38
> ip rule del pref 38
> ip rule add to 192.168.3.0/24 goto 38
> ip rule add pref 38
>
> then the BUG_ON will happen
> del BUG_ON and use (ctarget == NULL) identify whether this rule is unresolved
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH] net/smsc911x: Correctly configure 16-bit register access from DT
From: David Miller @ 2011-09-21 19:18 UTC (permalink / raw)
To: dave.martin
Cc: netdev, patches, steve.glendinning, shawn.guo, devicetree-discuss
In-Reply-To: <1315910969-4018-1-git-send-email-dave.martin@linaro.org>
From: Dave Martin <dave.martin@linaro.org>
Date: Tue, 13 Sep 2011 11:49:29 +0100
> The SMSC911X_USE_16BIT needs to be set when using 16-bit register
> access. However, currently no flag is set if the device tree
> doesn't specify 32-bit access, resulting in a BUG() and a non-
> working driver when 16-bit register access is configured for
> smsc911x in the DT.
>
> This patch should set the SMSC911X_USE_16BIT flag in a manner
> consistent with the documented DT bindings.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] xfrm: Perform a replay check after return from async codepaths
From: David Miller @ 2011-09-21 19:21 UTC (permalink / raw)
To: herbert; +Cc: steffen.klassert, netdev
In-Reply-To: <20110921122442.GA19162@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Wed, 21 Sep 2011 22:24:42 +1000
> On Wed, Sep 21, 2011 at 01:57:27PM +0200, Steffen Klassert wrote:
>>
>> Well, I've got pretty reproduceable crashes when the sender of
>> the IPsec packets introduces reorder, that's why I noticed this.
>>
>> The problem is, that the replay check function is called before
>> the asynchronous crypto processing and the replay advance function
>> is called after resume from the asynchronous processing. So
>> we can submit multiple packets to the crypto layer without
>> updating the replay window. This means that the replay check
>> function accepts packets that should have been dropped, because
>> they are reordered and more than 'replay window size' packets
>> to late. This leads to a crash as we try to update the replay
>> window beyond the allocated bounds.
>
> OK I see what you mean now.
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-08
From: David Miller @ 2011-09-21 19:26 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1315500051-1122-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Thu, 8 Sep 2011 18:40:44 +0200
> The following changes since commit a943cac144e035c21d4f1b31b95f15b33c33a480:
>
> batman-adv: merge update_transtable() into tt related code (2011-08-22 15:16:22 +0200)
>
> are available in the git repository at:
> git://git.open-mesh.org/linux-merge.git batman-adv/next
Pulled, thanks Marek.
^ 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