* [PATCH 1/2] net/fec: clean suspend/resume
From: Eric Bénard @ 2010-06-18 14:19 UTC (permalink / raw)
Cc: netdev, s.hauer, amit.kucheria, davem, linux-arm-kernel
Commit 59d4289b83b11379d867e2f7146904b19cc96404 converted fec to dev_pm_ops but
didn't update the suspend/resume functions thus leading to the following warning :
"initialization from incompatible pointer type" when CONFIG_PM is set.
This patch also fixe a few indentation and style around CONFIG_PM area.
Signed-off-by: Eric Bénard <eric@eukrea.com>
Cc: netdev@vger.kernel.org
Cc: davem@davemloft.net
Cc: amit.kucheria@canonical.com
Cc: s.hauer@pengutronix.de
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/net/fec.c | 30 ++++++++++++------------------
1 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index a3cae4e..b4afd7a 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -1360,11 +1360,10 @@ fec_drv_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM
-
static int
-fec_suspend(struct platform_device *dev, pm_message_t state)
+fec_suspend(struct device *dev)
{
- struct net_device *ndev = platform_get_drvdata(dev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct fec_enet_private *fep;
if (ndev) {
@@ -1377,9 +1376,9 @@ fec_suspend(struct platform_device *dev, pm_message_t state)
}
static int
-fec_resume(struct platform_device *dev)
+fec_resume(struct device *dev)
{
- struct net_device *ndev = platform_get_drvdata(dev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct fec_enet_private *fep;
if (ndev) {
@@ -1399,23 +1398,18 @@ static const struct dev_pm_ops fec_pm_ops = {
.poweroff = fec_suspend,
.restore = fec_resume,
};
-
-#define FEC_PM_OPS (&fec_pm_ops)
-
-#else /* !CONFIG_PM */
-
-#define FEC_PM_OPS NULL
-
-#endif /* !CONFIG_PM */
+#endif
static struct platform_driver fec_driver = {
.driver = {
- .name = "fec",
- .owner = THIS_MODULE,
- .pm = FEC_PM_OPS,
+ .name = "fec",
+ .owner = THIS_MODULE,
+#ifdef CONFIG_PM
+ .pm = &fec_pm_ops,
+#endif
},
- .probe = fec_probe,
- .remove = __devexit_p(fec_drv_remove),
+ .probe = fec_probe,
+ .remove = __devexit_p(fec_drv_remove),
};
static int __init
--
1.6.3.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Wolfgang Grandegger @ 2010-06-18 12:30 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C1B5E1F.5080702-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 06/18/2010 01:53 PM, Wolfgang Grandegger wrote:
> On 06/18/2010 01:21 PM, Marc Kleine-Budde wrote:
>> Wolfgang Grandegger wrote:
>>> On 06/18/2010 12:44 PM, Marc Kleine-Budde wrote:
>>>> Wolfgang Grandegger wrote:
>>>>> On 06/18/2010 12:16 PM, Marc Kleine-Budde wrote:
>>>>>> Wolfgang Grandegger wrote:
>>>>>>> Hi Hans-Jürgen,
>>>>>>>
>>>>>>> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
>>>>>>>> This adds a driver for FlexCAN based CAN controllers,
>>>>>>>> e.g. found in Freescale i.MX35 SoCs.
>>>>>>>>
>>>>>>>> The original version of this driver was posted by Sascha Hauer in July 2009:
>>>>>>>> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>>>>>>>>
>>>>>>>> I took this version, added NAPI support, and fixed some problems found
>>>>>>>> during testing. Well, here is the result. Please review.
>>>>>>> I briefly browsed the patch and various bits and pieces are missing or
>>>>>>> not correctly implemented. Marc already pointed out a few of them:
>>>>>>>
>>>>>>> - I do not find can_put/get_echo_skb functions in the code. How is
>>>>>>> IFF_ECHO supposed to work?
>>>>>> the driver uses hardware loopback
>>>>> OK, then
>>>>>
>>>>> dev = alloc_candev(sizeof(struct flexcan_priv), 0);
>>>>>
>>>>> should be used (and TX_ECHO_SKB_MAX removed) in Hans-Jürgens driver.
>>>>>
>>>>>>> - Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
>>>>>>> seems to be missing.
>>>>>>>
>>>>>>> - Make use of alloc_can_skb() and alloc_can_err_skb().
>>>>>> the last two points are already addressed in my version of the driver.
>>>>> I do not see support for CAN_CTRLMODE_BERR_REPORTING in your driver
>>>>> (which has nothing to do with do_get_berr_counter).
>>>> oh yes...sorry, got confused.
>>>>
>>>> However I implemented CAN_CTRLMODE_BERR_REPORTING, i.e. turning of the
>>>> bit error interrupts by default. This has the effect that no bus warning
>>>> and bus passive interrupt was signalled.
>>>>
>>>> I should add a comment to my driver.
>>>
>>> I'm confused, CAN_CTRLMODE_BERR_REPORTING means that the user can enable
>>> bus error reporting, which seems not be handled in the driver your sent.
>>> See:
>>>
>>> http://lxr.linux.no/linux/drivers/net/can/sja1000/sja1000.c#L134
>>> http://lxr.linux.no/linux/drivers/net/can/sja1000/sja1000.c#L588
>>
>> Which interrupts does "IRQ_BEI" include? What should
>> CAN_CTRLMODE_BERR_REPORTING do?
>>
>> Looking at:
>> http://lxr.linux.no/linux+v2.6.34/drivers/net/can/sja1000/sja1000.c#L393
>> it seems that BEI on the SJA just effects bit, form and stuff errors.
>
> Yes, it effects *bus errors*... actually the one you handle in
> at91_poll_err_frame(). Especially the AT91_IRQ_AERR does cause the
> infamous interrupt flooding (which is, btw, not treated correctly as
> bus error in your driver).
>
>> If I disable the corresponding interrupt in the flexcan. This is
>> ERR_MSK, (1 << 14 in CTRL), I don't get error warning or error passive
>> interrupts either. I'm not sure about the bus off interrupt.
>
> Hm, my understanding is that you can disable those bus error
> interrupts individually via AT91_IRQ_ERR_FRAME.
>
>> From my point of view this is not that what CAN_CTRLMODE_BERR_REPORTING
>> should do, is it?
>
> It should *not* disable state change interrupts, of course. I have
> started to fix some issues in the at91 driver some time ago, which
> I have attached below.
Sorry, I drifted away to the at91 driver. If the flexcan hardware does
not allow to disable bus error reporting individually, just do *not*
support CAN_CTRLMODE_BERR_REPORTING, as you already do in your patch.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Wolfgang Grandegger @ 2010-06-18 12:19 UTC (permalink / raw)
To: Hans J. Koch
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100618120044.GB2007-hikPBsva6T+Nj9Bq2fkWzw@public.gmane.org>
On 06/18/2010 02:00 PM, Hans J. Koch wrote:
> On Fri, Jun 18, 2010 at 11:47:04AM +0200, Wolfgang Grandegger wrote:
>> Hi Hans-Jürgen,
>>
>> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
>>> This adds a driver for FlexCAN based CAN controllers,
>>> e.g. found in Freescale i.MX35 SoCs.
>>>
>>> The original version of this driver was posted by Sascha Hauer in July 2009:
>>> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>>>
>>> I took this version, added NAPI support, and fixed some problems found
>>> during testing. Well, here is the result. Please review.
>>
>> I briefly browsed the patch and various bits and pieces are missing or
>> not correctly implemented. Marc already pointed out a few of them:
>
> Before we continue, we should address the fact that we now have two versions
> of the driver. It doesn't make sense to work on both.
> Just for the record, I knew that Marc was working on this, and offered
> cooperation in a private mail a few weeks ago. He never answered, so I made
> it work myself, and posted it as soon as I could. A few hours after he saw
> that, he came up with his version...
>
> So, instead of continuing wasting engineering powers, you should decide
> which of the two versions is in the better shape already, and we continue
> working on that. I don't mind at all if you choose Marc's version. I'm
> not running after copyright lines, I just want to see flexcan in mainline
> as soon as possible.
Me too. Marc's version is definitely more up-to-date and should be taken
as starting point.
Wolfgang.
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Lennert Buytenhek @ 2010-06-18 12:12 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF8E185B56.9B8AB610-ONC1257746.003A78DF-C1257746.003D4C6C@transmode.se>
On Fri, Jun 18, 2010 at 01:09:32PM +0200, Joakim Tjernlund wrote:
> > > > > I am trying to wrap my head around DSA and I need some help.
> > > > >
> > > > > Assume the example from Lennert:
> > > > >
> > > > > +-----------+ +-----------+
> > > > > | | RGMII | |
> > > > > | +-------+ +------ 1000baseT MDI ("WAN")
> > > > > | | | 6-port +------ 1000baseT MDI ("LAN1")
> > > > > | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> > > > > | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> > > > > | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> > > > > | | | |
> > > > > +-----------+ +-----------+
> > > > >
> > > > > If I understand this correctly I get at least 5 virtual I/Fs corresponding
> > > > > to WAN, LAN1-4, but how is the RGMII I/F modelled?
> > > >
> > > > The RGMII interface is just the interface that your "real" network
> > > > driver exports. In the case of the Kirkwood 6281 A0 Reference Design
> > > > (which I developed this code on), that would be eth0. After the DSA
> > > > driver is instantiated, you don't send or receive over eth0 directly
> > > > anymore -- eth0 becomes purely a transport for DSA-tagged packets.
> > >
> > > hmm, but how do I send normal pkgs form the CPU to the switch then?
> >
> > Define what you mean by 'normal pkgs'.
>
> An ethernet broadcast pkg flooded onto all ports.
This statement assumes that all ports have been configured into a
bridge, which is not the default case. (And why would it be? Having each
port in the same VLAN/subnet is only one of the many possible ways of
configuring your switch ports -- and regular (non-DSA) Linux network
interfaces aren't bridged together by default either.) I.e. after boot,
each of the switch ports behaves as if it's independent.
> A normal ethernet host DST address would be looked up by
> the switch HW and sent to the appropriate port.
In current upstream kernels, if you in fact bridge all switch ports
together using Linux bridging, this address lookup will be done by the
Linux bridging code.
> > > I envision I would get some interface in the CPU I can set an IP address
> > > on and use as a normal I/F which would be switched by the HW switch to
> > > the appropriate port.
> >
> > Yes, these are the DSA/slave interfaces created by net/dsa/slave.c.
> > You are free to attach IP addresses to the wan/lanX interfaces, and
> > things will work as you'd expect them to.
>
> Not sure what to expect here actually.
That the DSA interfaces will behave just like non-DSA Linux network
interfaces.
> > > What about RX? What decides which pkg to route through the switch and
> > > which pgk to send up to the virtual I/F?
> >
> > By default, which is until you enable bridging on some subset of the
> > ports, all ports have their own address database, and all received
> > packets are passed directly up to the CPU, where the DSA code will
> > then make those packets be received on the DSA slave interfaces.
>
> ah, so until I enable bridging, all ports are viewed as a separate
> network I/F?
Yes. The original DSA commit message says as much:
The switch driver presents each port on the switch as a separate
network interface to Linux, [...]
> Once I create a linux bridge device and add the virtual I/Fs, one
> enables the bridge function.
Yes and no. Right now there is no hardware switch offload code in the
upstream kernel, so all bridging will still be done in software. You
will need something along the lines of the patch I pointed you to to
enable hardware bridging.
> One drawback with that is that you kill the bridge when you reboot
> linux.
With the hardware bridging patch, hardware bridging will continue if
you don't break down your br0 interface before rebooting. (Of course,
your board might still have a hardware reset line that resets the
switch when the CPU resets.)
> > > > > Now I want to add STP/RSTP to the switch. How would one do that?
> > > >
> > > > First, you'll want the hardware bridging patches that I posted to
> > > > netdev@ a while back, e.g.:
> > > >
> > > > http://patchwork.ozlabs.org/patch/16578/
> > >
> > > I see, will have to study this a bit closer. One question though,
> > > does this disable MAC learning in the linux bridge?
> >
> > No, why should it?
>
> Doesn't the HW switch handle all MAC leaning? Why duplicate
> this in the SW bridge?
> I figured the HW switch would offload the SW bridge this task.
Imagine the case where you bridge lan1, lan2 (both on the switch chip)
into br0, together with wlan0 (which is not on the switch chip).
Now a packet is sent out of br0. Should it be sent to wlan0 or to the
switch chip? How will you make this decision without an address database
on the Linux side?
> > > Do you have any idea how to do DSA on a Broadcom switch?
> >
> > I have no idea. When I originally submitted the DSA code for merging,
> > I contacted Broadcom people about adding support for Broadcom switch
> > chips to it, but I never heard back from them.
>
> OK. With DSA, how does one configure VLANs, policing and parameters in the
> HW switch that don't map or exist in the linux bridge?
The idea is to use existing kernel interface for this as much as
possible. So e.g. if you do:
vconfig add lan1 123
vconfig add lan2 123
brctl addbr br123
brctl addif br123 lan1.123
brctl addif br123 lan2.123
Then the DSA code (or some userspace netlink listener helper, or some
combination of both) should ideally also detect that VLAN 123 on
interfaces lan1 and lan2 are to be bridged together, and program the
switch chip accordingly. I think all VLAN configurations that at least
the Marvell hardware supports can be expressed this way.
To configure things like ingress/egress rate limiting and such in the
switch chip for which there is no Linux counterpart interface, I suppose
some sysfs interface or so might suffice.
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Hans J. Koch @ 2010-06-18 12:00 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C1B4098.3090800-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Fri, Jun 18, 2010 at 11:47:04AM +0200, Wolfgang Grandegger wrote:
> Hi Hans-Jürgen,
>
> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
> > This adds a driver for FlexCAN based CAN controllers,
> > e.g. found in Freescale i.MX35 SoCs.
> >
> > The original version of this driver was posted by Sascha Hauer in July 2009:
> > http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
> >
> > I took this version, added NAPI support, and fixed some problems found
> > during testing. Well, here is the result. Please review.
>
> I briefly browsed the patch and various bits and pieces are missing or
> not correctly implemented. Marc already pointed out a few of them:
Before we continue, we should address the fact that we now have two versions
of the driver. It doesn't make sense to work on both.
Just for the record, I knew that Marc was working on this, and offered
cooperation in a private mail a few weeks ago. He never answered, so I made
it work myself, and posted it as soon as I could. A few hours after he saw
that, he came up with his version...
So, instead of continuing wasting engineering powers, you should decide
which of the two versions is in the better shape already, and we continue
working on that. I don't mind at all if you choose Marc's version. I'm
not running after copyright lines, I just want to see flexcan in mainline
as soon as possible.
Thanks,
Hans
_______________________________________________
Socketcan-core mailing list
Socketcan-core@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Wolfgang Grandegger @ 2010-06-18 11:53 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C1B56BC.1050303-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 06/18/2010 01:21 PM, Marc Kleine-Budde wrote:
> Wolfgang Grandegger wrote:
>> On 06/18/2010 12:44 PM, Marc Kleine-Budde wrote:
>>> Wolfgang Grandegger wrote:
>>>> On 06/18/2010 12:16 PM, Marc Kleine-Budde wrote:
>>>>> Wolfgang Grandegger wrote:
>>>>>> Hi Hans-Jürgen,
>>>>>>
>>>>>> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
>>>>>>> This adds a driver for FlexCAN based CAN controllers,
>>>>>>> e.g. found in Freescale i.MX35 SoCs.
>>>>>>>
>>>>>>> The original version of this driver was posted by Sascha Hauer in July 2009:
>>>>>>> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>>>>>>>
>>>>>>> I took this version, added NAPI support, and fixed some problems found
>>>>>>> during testing. Well, here is the result. Please review.
>>>>>> I briefly browsed the patch and various bits and pieces are missing or
>>>>>> not correctly implemented. Marc already pointed out a few of them:
>>>>>>
>>>>>> - I do not find can_put/get_echo_skb functions in the code. How is
>>>>>> IFF_ECHO supposed to work?
>>>>> the driver uses hardware loopback
>>>> OK, then
>>>>
>>>> dev = alloc_candev(sizeof(struct flexcan_priv), 0);
>>>>
>>>> should be used (and TX_ECHO_SKB_MAX removed) in Hans-Jürgens driver.
>>>>
>>>>>> - Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
>>>>>> seems to be missing.
>>>>>>
>>>>>> - Make use of alloc_can_skb() and alloc_can_err_skb().
>>>>> the last two points are already addressed in my version of the driver.
>>>> I do not see support for CAN_CTRLMODE_BERR_REPORTING in your driver
>>>> (which has nothing to do with do_get_berr_counter).
>>> oh yes...sorry, got confused.
>>>
>>> However I implemented CAN_CTRLMODE_BERR_REPORTING, i.e. turning of the
>>> bit error interrupts by default. This has the effect that no bus warning
>>> and bus passive interrupt was signalled.
>>>
>>> I should add a comment to my driver.
>>
>> I'm confused, CAN_CTRLMODE_BERR_REPORTING means that the user can enable
>> bus error reporting, which seems not be handled in the driver your sent.
>> See:
>>
>> http://lxr.linux.no/linux/drivers/net/can/sja1000/sja1000.c#L134
>> http://lxr.linux.no/linux/drivers/net/can/sja1000/sja1000.c#L588
>
> Which interrupts does "IRQ_BEI" include? What should
> CAN_CTRLMODE_BERR_REPORTING do?
>
> Looking at:
> http://lxr.linux.no/linux+v2.6.34/drivers/net/can/sja1000/sja1000.c#L393
> it seems that BEI on the SJA just effects bit, form and stuff errors.
Yes, it effects *bus errors*... actually the one you handle in
at91_poll_err_frame(). Especially the AT91_IRQ_AERR does cause the
infamous interrupt flooding (which is, btw, not treated correctly as
bus error in your driver).
> If I disable the corresponding interrupt in the flexcan. This is
> ERR_MSK, (1 << 14 in CTRL), I don't get error warning or error passive
> interrupts either. I'm not sure about the bus off interrupt.
Hm, my understanding is that you can disable those bus error
interrupts individually via AT91_IRQ_ERR_FRAME.
> From my point of view this is not that what CAN_CTRLMODE_BERR_REPORTING
> should do, is it?
It should *not* disable state change interrupts, of course. I have
started to fix some issues in the at91 driver some time ago, which
I have attached below.
Wolfgang.
---
diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index a2f29a3..ad36b59 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -164,6 +164,7 @@ struct at91_priv {
void __iomem *reg_base;
u32 reg_sr;
+ u32 reg_ie_napi;
unsigned int tx_next;
unsigned int tx_echo;
unsigned int rx_next;
@@ -273,7 +274,7 @@ static int at91_set_bittiming(struct net_device *dev)
static void at91_chip_start(struct net_device *dev)
{
struct at91_priv *priv = netdev_priv(dev);
- u32 reg_mr, reg_ier;
+ u32 reg_mr;
/* disable interrupts */
at91_write(priv, AT91_IDR, AT91_IRQ_ALL);
@@ -290,10 +291,12 @@ static void at91_chip_start(struct net_device *dev)
priv->can.state = CAN_STATE_ERROR_ACTIVE;
- /* Enable interrupts */
- reg_ier = AT91_IRQ_MB_RX | AT91_IRQ_ERRP | AT91_IRQ_ERR_FRAME;
+ /* enable interrupts */
+ priv->reg_ir_napi = AT91_IRQ_MB_RX;
+ if (priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING)
+ priv->reg_ir_napi |= AT91_IRQ_ERR_FRAME;
at91_write(priv, AT91_IDR, AT91_IRQ_ALL);
- at91_write(priv, AT91_IER, reg_ier);
+ at91_write(priv, AT91_IER, priv->reg_ir_napi | AT91_IRQ_ERRP);
}
static void at91_chip_stop(struct net_device *dev, enum can_state state)
@@ -604,20 +607,21 @@ static void at91_poll_err_frame(struct net_device *dev,
{
struct at91_priv *priv = netdev_priv(dev);
+ priv->can.can_stats.bus_error++;
+ cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
+
/* CRC error */
if (reg_sr & AT91_IRQ_CERR) {
dev_dbg(dev->dev.parent, "CERR irq\n");
dev->stats.rx_errors++;
- priv->can.can_stats.bus_error++;
- cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
+ cf->data[3] |= CAN_ERR_PROT_LOC_CRC_SEQ |
+ CAN_ERR_PROT_LOC_CRC_DEL;
}
/* Stuffing Error */
if (reg_sr & AT91_IRQ_SERR) {
dev_dbg(dev->dev.parent, "SERR irq\n");
dev->stats.rx_errors++;
- priv->can.can_stats.bus_error++;
- cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
cf->data[2] |= CAN_ERR_PROT_STUFF;
}
@@ -626,14 +630,13 @@ static void at91_poll_err_frame(struct net_device *dev,
dev_dbg(dev->dev.parent, "AERR irq\n");
dev->stats.tx_errors++;
cf->can_id |= CAN_ERR_ACK;
+ cf->data[3] |= CAN_ERR_PROT_LOC_ACK;
}
/* Form error */
if (reg_sr & AT91_IRQ_FERR) {
dev_dbg(dev->dev.parent, "FERR irq\n");
dev->stats.rx_errors++;
- priv->can.can_stats.bus_error++;
- cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
cf->data[2] |= CAN_ERR_PROT_FORM;
}
@@ -641,9 +644,7 @@ static void at91_poll_err_frame(struct net_device *dev,
if (reg_sr & AT91_IRQ_BERR) {
dev_dbg(dev->dev.parent, "BERR irq\n");
dev->stats.tx_errors++;
- priv->can.can_stats.bus_error++;
- cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
- cf->data[2] |= CAN_ERR_PROT_BIT;
+ cf->data[2] |= CAN_ERR_PROT_BIT0 | CAN_ERR_PROT_BIT1;
}
}
@@ -662,7 +663,6 @@ static int at91_poll_err(struct net_device *dev, int quota, u32 reg_sr)
at91_poll_err_frame(dev, cf, reg_sr);
netif_receive_skb(skb);
- dev->last_rx = jiffies;
dev->stats.rx_packets++;
dev->stats.rx_bytes += cf->can_dlc;
@@ -688,12 +688,10 @@ static int at91_poll(struct napi_struct *napi, int quota)
work_done += at91_poll_err(dev, quota - work_done, reg_sr);
if (work_done < quota) {
- /* enable IRQs for frame errors and all mailboxes >= rx_next */
- u32 reg_ier = AT91_IRQ_ERR_FRAME;
- reg_ier |= AT91_IRQ_MB_RX & ~AT91_MB_RX_MASK(priv->rx_next);
-
napi_complete(napi);
- at91_write(priv, AT91_IER, reg_ier);
+ /* enable IRQs for frame errors and all mailboxes >= rx_next */
+ at91_write(priv, AT91_IER, priv->reg_ir_napi &
+ ~AT91_MB_RX_MASK(priv->rx_next));
}
return work_done;
@@ -899,7 +897,6 @@ static void at91_irq_err(struct net_device *dev)
at91_irq_err_state(dev, cf, new_state);
netif_rx(skb);
- dev->last_rx = jiffies;
dev->stats.rx_packets++;
dev->stats.rx_bytes += cf->can_dlc;
@@ -933,8 +930,7 @@ static irqreturn_t at91_irq(int irq, void *dev_id)
* save for later use.
*/
priv->reg_sr = reg_sr;
- at91_write(priv, AT91_IDR,
- AT91_IRQ_MB_RX | AT91_IRQ_ERR_FRAME);
+ at91_write(priv, AT91_IDR, priv->reg_ir_napi);
napi_schedule(&priv->napi);
}
@@ -1073,7 +1069,8 @@ static int __init at91_can_probe(struct platform_device *pdev)
priv->can.bittiming_const = &at91_bittiming_const;
priv->can.do_set_bittiming = at91_set_bittiming;
priv->can.do_set_mode = at91_set_mode;
- priv->can.ctrlmode_supported = CAN_CTRLMODE_3_SAMPLES;
+ priv->can.ctrlmode_supported = CAN_CTRLMODE_3_SAMPLES |
+ CAN_CTRLMODE_BERR_REPORTING;
priv->reg_base = addr;
priv->dev = dev;
priv->clk = clk;
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index 145b1a7..77b5fbc 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -89,8 +89,8 @@ static int sja1000_probe_chip(struct net_device *dev)
struct sja1000_priv *priv = netdev_priv(dev);
if (priv->reg_base && (priv->read_reg(priv, 0) == 0xFF)) {
- printk(KERN_INFO "%s: probing @0x%lX failed\n",
- DRV_NAME, dev->base_addr);
+ dev_info(dev->dev.parent, "probing @0x%p failed\n",
+ priv->reg_base);
return 0;
}
return -1;
@@ -254,7 +254,7 @@ static void chipset_init(struct net_device *dev)
* [ can-id ] [flags] [len] [can data (up to 8 bytes]
*/
static netdev_tx_t sja1000_start_xmit(struct sk_buff *skb,
- struct net_device *dev)
+ struct net_device *dev)
{
struct sja1000_priv *priv = netdev_priv(dev);
struct can_frame *cf = (struct can_frame *)skb->data;
@@ -602,9 +602,9 @@ void free_sja1000dev(struct net_device *dev)
EXPORT_SYMBOL_GPL(free_sja1000dev);
static const struct net_device_ops sja1000_netdev_ops = {
- .ndo_open = sja1000_open,
- .ndo_stop = sja1000_close,
- .ndo_start_xmit = sja1000_start_xmit,
+ .ndo_open = sja1000_open,
+ .ndo_stop = sja1000_close,
+ .ndo_start_xmit = sja1000_start_xmit,
};
int register_sja1000dev(struct net_device *dev)
^ permalink raw reply related
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Marc Kleine-Budde @ 2010-06-18 11:21 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C1B52A7.3060607-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2970 bytes --]
Wolfgang Grandegger wrote:
> On 06/18/2010 12:44 PM, Marc Kleine-Budde wrote:
>> Wolfgang Grandegger wrote:
>>> On 06/18/2010 12:16 PM, Marc Kleine-Budde wrote:
>>>> Wolfgang Grandegger wrote:
>>>>> Hi Hans-Jürgen,
>>>>>
>>>>> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
>>>>>> This adds a driver for FlexCAN based CAN controllers,
>>>>>> e.g. found in Freescale i.MX35 SoCs.
>>>>>>
>>>>>> The original version of this driver was posted by Sascha Hauer in July 2009:
>>>>>> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>>>>>>
>>>>>> I took this version, added NAPI support, and fixed some problems found
>>>>>> during testing. Well, here is the result. Please review.
>>>>> I briefly browsed the patch and various bits and pieces are missing or
>>>>> not correctly implemented. Marc already pointed out a few of them:
>>>>>
>>>>> - I do not find can_put/get_echo_skb functions in the code. How is
>>>>> IFF_ECHO supposed to work?
>>>> the driver uses hardware loopback
>>> OK, then
>>>
>>> dev = alloc_candev(sizeof(struct flexcan_priv), 0);
>>>
>>> should be used (and TX_ECHO_SKB_MAX removed) in Hans-Jürgens driver.
>>>
>>>>> - Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
>>>>> seems to be missing.
>>>>>
>>>>> - Make use of alloc_can_skb() and alloc_can_err_skb().
>>>> the last two points are already addressed in my version of the driver.
>>> I do not see support for CAN_CTRLMODE_BERR_REPORTING in your driver
>>> (which has nothing to do with do_get_berr_counter).
>> oh yes...sorry, got confused.
>>
>> However I implemented CAN_CTRLMODE_BERR_REPORTING, i.e. turning of the
>> bit error interrupts by default. This has the effect that no bus warning
>> and bus passive interrupt was signalled.
>>
>> I should add a comment to my driver.
>
> I'm confused, CAN_CTRLMODE_BERR_REPORTING means that the user can enable
> bus error reporting, which seems not be handled in the driver your sent.
> See:
>
> http://lxr.linux.no/linux/drivers/net/can/sja1000/sja1000.c#L134
> http://lxr.linux.no/linux/drivers/net/can/sja1000/sja1000.c#L588
Which interrupts does "IRQ_BEI" include? What should
CAN_CTRLMODE_BERR_REPORTING do?
Looking at:
http://lxr.linux.no/linux+v2.6.34/drivers/net/can/sja1000/sja1000.c#L393
it seems that BEI on the SJA just effects bit, form and stuff errors.
If I disable the corresponding interrupt in the flexcan. This is
ERR_MSK, (1 << 14 in CTRL), I don't get error warning or error passive
interrupts either. I'm not sure about the bus off interrupt.
From my point of view this is not that what CAN_CTRLMODE_BERR_REPORTING
should do, is it?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [v3 Patch 2/2] mlx4: add dynamic LRO disable support
From: Stanislaw Gruszka @ 2010-06-18 11:09 UTC (permalink / raw)
To: Amerigo Wang
Cc: netdev, nhorman, herbert.xu, bhutchings, Ramkrishna.Vepa, davem
In-Reply-To: <20100618105945.6496.67648.sendpatchset@localhost.localdomain>
On Fri, Jun 18, 2010 at 06:55:38AM -0400, Amerigo Wang wrote:
> +static int mlx4_ethtool_op_set_flags(struct net_device *dev, u32 data)
> +{
> + struct mlx4_en_priv *priv = netdev_priv(dev);
> + struct mlx4_en_dev *mdev = priv->mdev;
> + int rc = 0;
> + int changed = 0;
> +
> + if (data & (ETH_FLAG_NTUPLE | ETH_FLAG_RXHASH))
> + return -EOPNOTSUPP;
> +
> + if (data & ETH_FLAG_LRO) {
> + if (!(dev->features & NETIF_F_LRO))
> + changed = 1;
> + } else if (dev->features & NETIF_F_LRO) {
> + changed = 1;
> + mdev->profile.num_lro = 0;
Everything fine except that, what for you zero num_lro value?
If we set it to zero it will stay zero and we will not create
proper number of lro descriptors in mlx4_en_create_rx_ring()
(called from mlx4_en_set_ringparam() -> mlx4_en_alloc_resources())
when someone enable LRO again on.
Stanislaw
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Joakim Tjernlund @ 2010-06-18 11:09 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev
In-Reply-To: <20100618095923.GC14513@mail.wantstofly.org>
Lennert Buytenhek <buytenh@wantstofly.org> wrote on 2010/06/18 11:59:23:
>
> On Fri, Jun 18, 2010 at 11:15:09AM +0200, Joakim Tjernlund wrote:
>
> > > > I am trying to wrap my head around DSA and I need some help.
> > > >
> > > > Assume the example from Lennert:
> > > >
> > > > +-----------+ +-----------+
> > > > | | RGMII | |
> > > > | +-------+ +------ 1000baseT MDI ("WAN")
> > > > | | | 6-port +------ 1000baseT MDI ("LAN1")
> > > > | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> > > > | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> > > > | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> > > > | | | |
> > > > +-----------+ +-----------+
> > > >
> > > > If I understand this correctly I get at least 5 virtual I/Fs corresponding
> > > > to WAN, LAN1-4, but how is the RGMII I/F modelled?
> > >
> > > The RGMII interface is just the interface that your "real" network
> > > driver exports. In the case of the Kirkwood 6281 A0 Reference Design
> > > (which I developed this code on), that would be eth0. After the DSA
> > > driver is instantiated, you don't send or receive over eth0 directly
> > > anymore -- eth0 becomes purely a transport for DSA-tagged packets.
> >
> > hmm, but how do I send normal pkgs form the CPU to the switch then?
>
> Define what you mean by 'normal pkgs'.
An ethernet broadcast pkg flooded onto all ports.
A normal ethernet host DST address would be looked up by
the switch HW and sent to the appropriate port.
>
>
> > I envision I would get some interface in the CPU I can set an IP address
> > on and use as a normal I/F which would be switched by the HW switch to
> > the appropriate port.
>
> Yes, these are the DSA/slave interfaces created by net/dsa/slave.c.
> You are free to attach IP addresses to the wan/lanX interfaces, and
> things will work as you'd expect them to.
Not sure what to expect here actually.
>
>
> > > > I guess I will have one "real" ethX I/F which maps to RGMII but do I
> > > > get one virtual I/F too?
> > >
> > > You get a virtual interface for each of the ports on the switch (that
> > > are not CPU or inter-switch ports), i.e. all ports on the right of the
> > > diagram -- wan, lan1, lan2, lan3, lan4. These interfaces are created
> > > by net/dsa/slave.c and are called DSA interfaces or slave interfaces.
> > >
> > >
> > > > What use are these virtual I/Fs? Just to read status from the
> > > > corresponding ports?
> > >
> > > That's one of the purposes, yes. There's a polling routine that
> > > periodically checks the status of each of the ports on the switch (via
> > > the MII management interface) and feeds back that status to the virtual
> > > interfaces. I.e. if you plug a cable into lan3, you'll see a syslog
> > > message about the link on the virtual interface lan3 having come up,
> > > with the link speed, etc.
> > >
> > >
> > > > Can one TX and RX network pkgs over these I/Fs too?
> > >
> > > Sure -- that's the whole point.
> >
> > TX:ing pkgs on such virtual I/F would go directly to the port, bypassing
> > normal switching?
>
> Define what you mean by 'normal switching'.
>
>
> > What about RX? What decides which pkg to route through the switch and
> > which pgk to send up to the virtual I/F?
>
> By default, which is until you enable bridging on some subset of the
> ports, all ports have their own address database, and all received
> packets are passed directly up to the CPU, where the DSA code will
> then make those packets be received on the DSA slave interfaces.
ah, so until I enable bridging, all ports are viewed as a separate
network I/F?
Once I create a linux bridge device and add the virtual I/Fs, one
enables the bridge function.
One drawback with that is that you kill the bridge when you reboot
linux.
>
>
> > > > Now I want to add STP/RSTP to the switch. How would one do that?
> > >
> > > First, you'll want the hardware bridging patches that I posted to
> > > netdev@ a while back, e.g.:
> > >
> > > http://patchwork.ozlabs.org/patch/16578/
> >
> > I see, will have to study this a bit closer. One question though,
> > does this disable MAC learning in the linux bridge?
>
> No, why should it?
Doesn't the HW switch handle all MAC leaning? Why duplicate
this in the SW bridge?
I figured the HW switch would offload the SW bridge this task.
>
>
> > Do you have any idea how to do DSA on a Broadcom switch?
>
> I have no idea. When I originally submitted the DSA code for merging,
> I contacted Broadcom people about adding support for Broadcom switch
> chips to it, but I never heard back from them.
OK. With DSA, how does one configure VLANs, policing and parameters in the
HW switch that don't map or exist in the linux bridge?
Jocke
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Wolfgang Grandegger @ 2010-06-18 11:04 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C1B4DF0.2090103-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 06/18/2010 12:44 PM, Marc Kleine-Budde wrote:
> Wolfgang Grandegger wrote:
>> On 06/18/2010 12:16 PM, Marc Kleine-Budde wrote:
>>> Wolfgang Grandegger wrote:
>>>> Hi Hans-Jürgen,
>>>>
>>>> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
>>>>> This adds a driver for FlexCAN based CAN controllers,
>>>>> e.g. found in Freescale i.MX35 SoCs.
>>>>>
>>>>> The original version of this driver was posted by Sascha Hauer in July 2009:
>>>>> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>>>>>
>>>>> I took this version, added NAPI support, and fixed some problems found
>>>>> during testing. Well, here is the result. Please review.
>>>> I briefly browsed the patch and various bits and pieces are missing or
>>>> not correctly implemented. Marc already pointed out a few of them:
>>>>
>>>> - I do not find can_put/get_echo_skb functions in the code. How is
>>>> IFF_ECHO supposed to work?
>>> the driver uses hardware loopback
>>
>> OK, then
>>
>> dev = alloc_candev(sizeof(struct flexcan_priv), 0);
>>
>> should be used (and TX_ECHO_SKB_MAX removed) in Hans-Jürgens driver.
>>
>>>> - Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
>>>> seems to be missing.
>>>>
>>>> - Make use of alloc_can_skb() and alloc_can_err_skb().
>>> the last two points are already addressed in my version of the driver.
>>
>> I do not see support for CAN_CTRLMODE_BERR_REPORTING in your driver
>> (which has nothing to do with do_get_berr_counter).
>
> oh yes...sorry, got confused.
>
> However I implemented CAN_CTRLMODE_BERR_REPORTING, i.e. turning of the
> bit error interrupts by default. This has the effect that no bus warning
> and bus passive interrupt was signalled.
>
> I should add a comment to my driver.
I'm confused, CAN_CTRLMODE_BERR_REPORTING means that the user can enable
bus error reporting, which seems not be handled in the driver your sent.
See:
http://lxr.linux.no/linux/drivers/net/can/sja1000/sja1000.c#L134
http://lxr.linux.no/linux/drivers/net/can/sja1000/sja1000.c#L588
Wolfgang.
^ permalink raw reply
* [v3 Patch 2/2] mlx4: add dynamic LRO disable support
From: Amerigo Wang @ 2010-06-18 10:55 UTC (permalink / raw)
To: netdev
Cc: nhorman, sgruszka, herbert.xu, Amerigo Wang, bhutchings,
Ramkrishna.Vepa, davem
In-Reply-To: <20100618105935.6496.4725.sendpatchset@localhost.localdomain>
This patch adds dynamic LRO diable support for mlx4 net driver.
It also fixes a bug of mlx4, which checks NETIF_F_LRO flag in rx
path without rtnl lock.
I don't have mlx4 card, so only did compiling test. Anyone who wants
to test this is more than welcome.
This is based on Neil's initial work too.
Signed-off-by: WANG Cong <amwang@redhat.com>
Signed-off-by: Neil Horman <nhorman@redhat.com>
Acked-by: Neil Horman <nhorman@redhat.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
---
diff --git a/drivers/net/mlx4/en_ethtool.c b/drivers/net/mlx4/en_ethtool.c
index d5afd03..d68b796 100644
--- a/drivers/net/mlx4/en_ethtool.c
+++ b/drivers/net/mlx4/en_ethtool.c
@@ -387,6 +387,41 @@ static void mlx4_en_get_ringparam(struct net_device *dev,
param->tx_pending = mdev->profile.prof[priv->port].tx_ring_size;
}
+static int mlx4_ethtool_op_set_flags(struct net_device *dev, u32 data)
+{
+ struct mlx4_en_priv *priv = netdev_priv(dev);
+ struct mlx4_en_dev *mdev = priv->mdev;
+ int rc = 0;
+ int changed = 0;
+
+ if (data & (ETH_FLAG_NTUPLE | ETH_FLAG_RXHASH))
+ return -EOPNOTSUPP;
+
+ if (data & ETH_FLAG_LRO) {
+ if (!(dev->features & NETIF_F_LRO))
+ changed = 1;
+ } else if (dev->features & NETIF_F_LRO) {
+ changed = 1;
+ mdev->profile.num_lro = 0;
+ }
+
+ if (changed) {
+ if (netif_running(dev)) {
+ mutex_lock(&mdev->state_lock);
+ mlx4_en_stop_port(dev);
+ }
+ dev->features ^= NETIF_F_LRO;
+ if (netif_running(dev)) {
+ rc = mlx4_en_start_port(dev);
+ if (rc)
+ en_err(priv, "Failed to restart port\n");
+ mutex_unlock(&mdev->state_lock);
+ }
+ }
+
+ return rc;
+}
+
const struct ethtool_ops mlx4_en_ethtool_ops = {
.get_drvinfo = mlx4_en_get_drvinfo,
.get_settings = mlx4_en_get_settings,
@@ -415,7 +450,7 @@ const struct ethtool_ops mlx4_en_ethtool_ops = {
.get_ringparam = mlx4_en_get_ringparam,
.set_ringparam = mlx4_en_set_ringparam,
.get_flags = ethtool_op_get_flags,
- .set_flags = ethtool_op_set_flags,
+ .set_flags = mlx4_ethtool_op_set_flags,
};
^ permalink raw reply related
* [v3 Patch 1/2] s2io: add dynamic LRO disable support
From: Amerigo Wang @ 2010-06-18 10:55 UTC (permalink / raw)
To: netdev
Cc: nhorman, sgruszka, herbert.xu, Amerigo Wang, bhutchings,
Ramkrishna.Vepa, davem
This patch adds dynamic LRO diable support for s2io net driver.
I don't have s2io card, so only did compiling test. Anyone who wants
to test this is more than welcome.
This is based on Neil's initial work.
Signed-off-by: WANG Cong <amwang@redhat.com>
Signed-off-by: Neil Horman <nhorman@redhat.com>
Acked-by: Neil Horman <nhorman@redhat.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Ramkrishna Vepa <Ramkrishna.Vepa@exar.com>
---
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 668327c..e380f37 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -795,7 +795,6 @@ static int init_shared_mem(struct s2io_nic *nic)
ring->rx_curr_put_info.ring_len = rx_cfg->num_rxd - 1;
ring->nic = nic;
ring->ring_no = i;
- ring->lro = lro_enable;
blk_cnt = rx_cfg->num_rxd / (rxd_count[nic->rxd_mode] + 1);
/* Allocating all the Rx blocks */
@@ -6684,6 +6683,41 @@ static int s2io_ethtool_op_set_tso(struct net_device *dev, u32 data)
return 0;
}
+static int s2io_ethtool_set_flags(struct net_device *dev, u32 data)
+{
+ struct s2io_nic *sp = netdev_priv(dev);
+ int rc = 0;
+ int changed = 0;
+
+ if (data & (ETH_FLAG_NTUPLE | ETH_FLAG_RXHASH))
+ return -EOPNOTSUPP;
+
+ if (data & ETH_FLAG_LRO) {
+ if (lro_enable) {
+ if (!(dev->features & NETIF_F_LRO)) {
+ dev->features |= NETIF_F_LRO;
+ changed = 1;
+ }
+ } else
+ rc = -EINVAL;
+ } else if (dev->features & NETIF_F_LRO) {
+ dev->features &= ~NETIF_F_LRO;
+ changed = 1;
+ }
+
+ if (changed && netif_running(dev)) {
+ s2io_stop_all_tx_queue(sp);
+ s2io_card_down(sp);
+ sp->lro = dev->features & NETIF_F_LRO;
+ rc = s2io_card_up(sp);
+ if (rc)
+ s2io_reset(sp);
+ else
+ s2io_start_all_tx_queue(sp);
+ }
+
+ return rc;
+}
static const struct ethtool_ops netdev_ethtool_ops = {
.get_settings = s2io_ethtool_gset,
@@ -6701,6 +6735,8 @@ static const struct ethtool_ops netdev_ethtool_ops = {
.get_rx_csum = s2io_ethtool_get_rx_csum,
.set_rx_csum = s2io_ethtool_set_rx_csum,
.set_tx_csum = s2io_ethtool_op_set_tx_csum,
+ .set_flags = s2io_ethtool_set_flags,
+ .get_flags = ethtool_op_get_flags,
.set_sg = ethtool_op_set_sg,
.get_tso = s2io_ethtool_op_get_tso,
.set_tso = s2io_ethtool_op_set_tso,
@@ -7229,6 +7265,7 @@ static int s2io_card_up(struct s2io_nic *sp)
struct ring_info *ring = &mac_control->rings[i];
ring->mtu = dev->mtu;
+ ring->lro = sp->lro;
ret = fill_rx_buffers(sp, ring, 1);
if (ret) {
DBG_PRINT(ERR_DBG, "%s: Out of memory in Open\n",
^ permalink raw reply related
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Marc Kleine-Budde @ 2010-06-18 10:44 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C1B4B85.3010905-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1976 bytes --]
Wolfgang Grandegger wrote:
> On 06/18/2010 12:16 PM, Marc Kleine-Budde wrote:
>> Wolfgang Grandegger wrote:
>>> Hi Hans-Jürgen,
>>>
>>> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
>>>> This adds a driver for FlexCAN based CAN controllers,
>>>> e.g. found in Freescale i.MX35 SoCs.
>>>>
>>>> The original version of this driver was posted by Sascha Hauer in July 2009:
>>>> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>>>>
>>>> I took this version, added NAPI support, and fixed some problems found
>>>> during testing. Well, here is the result. Please review.
>>> I briefly browsed the patch and various bits and pieces are missing or
>>> not correctly implemented. Marc already pointed out a few of them:
>>>
>>> - I do not find can_put/get_echo_skb functions in the code. How is
>>> IFF_ECHO supposed to work?
>> the driver uses hardware loopback
>
> OK, then
>
> dev = alloc_candev(sizeof(struct flexcan_priv), 0);
>
> should be used (and TX_ECHO_SKB_MAX removed) in Hans-Jürgens driver.
>
>>> - Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
>>> seems to be missing.
>>>
>>> - Make use of alloc_can_skb() and alloc_can_err_skb().
>> the last two points are already addressed in my version of the driver.
>
> I do not see support for CAN_CTRLMODE_BERR_REPORTING in your driver
> (which has nothing to do with do_get_berr_counter).
oh yes...sorry, got confused.
However I implemented CAN_CTRLMODE_BERR_REPORTING, i.e. turning of the
bit error interrupts by default. This has the effect that no bus warning
and bus passive interrupt was signalled.
I should add a comment to my driver.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Wolfgang Grandegger @ 2010-06-18 10:33 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C1B4796.3060506-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 06/18/2010 12:16 PM, Marc Kleine-Budde wrote:
> Wolfgang Grandegger wrote:
>> Hi Hans-Jürgen,
>>
>> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
>>> This adds a driver for FlexCAN based CAN controllers,
>>> e.g. found in Freescale i.MX35 SoCs.
>>>
>>> The original version of this driver was posted by Sascha Hauer in July 2009:
>>> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>>>
>>> I took this version, added NAPI support, and fixed some problems found
>>> during testing. Well, here is the result. Please review.
>>
>> I briefly browsed the patch and various bits and pieces are missing or
>> not correctly implemented. Marc already pointed out a few of them:
>>
>> - I do not find can_put/get_echo_skb functions in the code. How is
>> IFF_ECHO supposed to work?
>
> the driver uses hardware loopback
OK, then
dev = alloc_candev(sizeof(struct flexcan_priv), 0);
should be used (and TX_ECHO_SKB_MAX removed) in Hans-Jürgens driver.
>
>> - Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
>> seems to be missing.
>>
>> - Make use of alloc_can_skb() and alloc_can_err_skb().
>
> the last two points are already addressed in my version of the driver.
I do not see support for CAN_CTRLMODE_BERR_REPORTING in your driver
(which has nothing to do with do_get_berr_counter).
Wolfgang.
^ permalink raw reply
* Re: [Bugme-new] [Bug 16216] New: wrong source addr of UDP packets when using policy routing
From: Unknown @ 2010-06-18 9:56 UTC (permalink / raw)
To: Patrick McHardy
Cc: Eric Dumazet, Andrew Morton, netdev, bugzilla-daemon,
bugme-daemon
In-Reply-To: <4C190D34.8080100@trash.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1255 bytes --]
Okey. Did you people came into any conclusions?
Is there a patch I can test?
I tried to find 914a9ab386a288d0f22252fc268ecbc048cdcbd5
in few stable trees but was unable to.
---------- Original message ----------
From: Patrick McHardy <kaber@trash.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, netdev@vger.kernel.org,
bugzilla-daemon@bugzilla.kernel.org, bugme-daemon@bugzilla.kernel.org,
borg@uu3.net
Subject: Re: [Bugme-new] [Bug 16216] New: wrong source addr of UDP packets when
using policy routing
Date: Wed, 16 Jun 2010 19:43:16 +0200
Message-ID: <4C190D34.8080100@trash.net>
Eric Dumazet wrote:
> Le mercredi 16 juin 2010 18:46 +0200, Patrick McHardy a écrit :
>
>
> > This is know behaviour, fwmarks don't work for source address selection
> > since before the source address is chosen, you don't even have a packet
> > which could be marked.
> >
>
> We know have sk->sk_mark routing (socket based), so we might change
> sk->sk_mark with appropriate iptables target when one packet is
> received... not very clean but worth to mention...
>
That would still be too late. The proper way would be to have the application
set the socket mark.
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Marc Kleine-Budde @ 2010-06-18 10:16 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C1B4098.3090800-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1302 bytes --]
Wolfgang Grandegger wrote:
> Hi Hans-Jürgen,
>
> On 06/17/2010 12:52 PM, Hans J. Koch wrote:
>> This adds a driver for FlexCAN based CAN controllers,
>> e.g. found in Freescale i.MX35 SoCs.
>>
>> The original version of this driver was posted by Sascha Hauer in July 2009:
>> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>>
>> I took this version, added NAPI support, and fixed some problems found
>> during testing. Well, here is the result. Please review.
>
> I briefly browsed the patch and various bits and pieces are missing or
> not correctly implemented. Marc already pointed out a few of them:
>
> - I do not find can_put/get_echo_skb functions in the code. How is
> IFF_ECHO supposed to work?
the driver uses hardware loopback
> - Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
> seems to be missing.
>
> - Make use of alloc_can_skb() and alloc_can_err_skb().
the last two points are already addressed in my version of the driver.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Wolfgang Grandegger @ 2010-06-18 10:04 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: Hans J. Koch, netdev, socketcan-core
In-Reply-To: <4C1A2CDF.2040008@pengutronix.de>
On 06/17/2010 04:10 PM, Marc Kleine-Budde wrote:
> Hey Hans,
>
> Hans J. Koch wrote:
>> + priv->can.do_set_bittiming = flexcan_set_bittiming;
Yes, but we need to fix it globally anyway.
> using this callback is error prone, with respect to 3-sample and
> friends, see discussion on socketcan-core.
>
>> + priv->can.bittiming_const = &flexcan_bittiming_const;
>> + priv->can.do_set_mode = flexcan_set_mode;
>> + priv->can.restart_ms = 500;
>
> should this be set in the driver?
No, the default is manual restart for all drivers.
Wolfgang.
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Lennert Buytenhek @ 2010-06-18 9:59 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF68B8EEAD.B003EFE7-ONC1257746.003109DB-C1257746.0032D371@transmode.se>
On Fri, Jun 18, 2010 at 11:15:09AM +0200, Joakim Tjernlund wrote:
> > > I am trying to wrap my head around DSA and I need some help.
> > >
> > > Assume the example from Lennert:
> > >
> > > +-----------+ +-----------+
> > > | | RGMII | |
> > > | +-------+ +------ 1000baseT MDI ("WAN")
> > > | | | 6-port +------ 1000baseT MDI ("LAN1")
> > > | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> > > | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> > > | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> > > | | | |
> > > +-----------+ +-----------+
> > >
> > > If I understand this correctly I get at least 5 virtual I/Fs corresponding
> > > to WAN, LAN1-4, but how is the RGMII I/F modelled?
> >
> > The RGMII interface is just the interface that your "real" network
> > driver exports. In the case of the Kirkwood 6281 A0 Reference Design
> > (which I developed this code on), that would be eth0. After the DSA
> > driver is instantiated, you don't send or receive over eth0 directly
> > anymore -- eth0 becomes purely a transport for DSA-tagged packets.
>
> hmm, but how do I send normal pkgs form the CPU to the switch then?
Define what you mean by 'normal pkgs'.
> I envision I would get some interface in the CPU I can set an IP address
> on and use as a normal I/F which would be switched by the HW switch to
> the appropriate port.
Yes, these are the DSA/slave interfaces created by net/dsa/slave.c.
You are free to attach IP addresses to the wan/lanX interfaces, and
things will work as you'd expect them to.
> > > I guess I will have one "real" ethX I/F which maps to RGMII but do I
> > > get one virtual I/F too?
> >
> > You get a virtual interface for each of the ports on the switch (that
> > are not CPU or inter-switch ports), i.e. all ports on the right of the
> > diagram -- wan, lan1, lan2, lan3, lan4. These interfaces are created
> > by net/dsa/slave.c and are called DSA interfaces or slave interfaces.
> >
> >
> > > What use are these virtual I/Fs? Just to read status from the
> > > corresponding ports?
> >
> > That's one of the purposes, yes. There's a polling routine that
> > periodically checks the status of each of the ports on the switch (via
> > the MII management interface) and feeds back that status to the virtual
> > interfaces. I.e. if you plug a cable into lan3, you'll see a syslog
> > message about the link on the virtual interface lan3 having come up,
> > with the link speed, etc.
> >
> >
> > > Can one TX and RX network pkgs over these I/Fs too?
> >
> > Sure -- that's the whole point.
>
> TX:ing pkgs on such virtual I/F would go directly to the port, bypassing
> normal switching?
Define what you mean by 'normal switching'.
> What about RX? What decides which pkg to route through the switch and
> which pgk to send up to the virtual I/F?
By default, which is until you enable bridging on some subset of the
ports, all ports have their own address database, and all received
packets are passed directly up to the CPU, where the DSA code will
then make those packets be received on the DSA slave interfaces.
> > > Now I want to add STP/RSTP to the switch. How would one do that?
> >
> > First, you'll want the hardware bridging patches that I posted to
> > netdev@ a while back, e.g.:
> >
> > http://patchwork.ozlabs.org/patch/16578/
>
> I see, will have to study this a bit closer. One question though,
> does this disable MAC learning in the linux bridge?
No, why should it?
> Do you have any idea how to do DSA on a Broadcom switch?
I have no idea. When I originally submitted the DSA code for merging,
I contacted Broadcom people about adding support for Broadcom switch
chips to it, but I never heard back from them.
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Wolfgang Grandegger @ 2010-06-18 9:47 UTC (permalink / raw)
To: Hans J. Koch; +Cc: netdev, socketcan-core
In-Reply-To: <20100617105201.GA2015@bluebox.local>
Hi Hans-Jürgen,
On 06/17/2010 12:52 PM, Hans J. Koch wrote:
> This adds a driver for FlexCAN based CAN controllers,
> e.g. found in Freescale i.MX35 SoCs.
>
> The original version of this driver was posted by Sascha Hauer in July 2009:
> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>
> I took this version, added NAPI support, and fixed some problems found
> during testing. Well, here is the result. Please review.
I briefly browsed the patch and various bits and pieces are missing or
not correctly implemented. Marc already pointed out a few of them:
- I do not find can_put/get_echo_skb functions in the code. How is
IFF_ECHO supposed to work?
- Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
seems to be missing.
- Make use of alloc_can_skb() and alloc_can_err_skb().
Wolfgang.
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Joakim Tjernlund @ 2010-06-18 9:15 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev
In-Reply-To: <20100618073309.GB14513@mail.wantstofly.org>
Lennert Buytenhek <buytenh@wantstofly.org> wrote on 2010/06/18 09:33:09:
>
> On Fri, Jun 18, 2010 at 09:06:52AM +0200, Joakim Tjernlund wrote:
>
> > I am trying to wrap my head around DSA and I need some help.
> >
> > Assume the example from Lennert:
> >
> > +-----------+ +-----------+
> > | | RGMII | |
> > | +-------+ +------ 1000baseT MDI ("WAN")
> > | | | 6-port +------ 1000baseT MDI ("LAN1")
> > | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> > | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> > | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> > | | | |
> > +-----------+ +-----------+
> >
> > If I understand this correctly I get at least 5 virtual I/Fs corresponding
> > to WAN, LAN1-4, but how is the RGMII I/F modelled?
>
> The RGMII interface is just the interface that your "real" network
> driver exports. In the case of the Kirkwood 6281 A0 Reference Design
> (which I developed this code on), that would be eth0. After the DSA
> driver is instantiated, you don't send or receive over eth0 directly
> anymore -- eth0 becomes purely a transport for DSA-tagged packets.
hmm, but how do I send normal pkgs form the CPU to the switch then?
I envision I would get some interface in the CPU I can set an IP address
on and use as a normal I/F which would be switched by the HW switch to
the appropriate port.
>
>
> > I guess I will have one "real" ethX I/F which maps to RGMII but do I
> > get one virtual I/F too?
>
> You get a virtual interface for each of the ports on the switch (that
> are not CPU or inter-switch ports), i.e. all ports on the right of the
> diagram -- wan, lan1, lan2, lan3, lan4. These interfaces are created
> by net/dsa/slave.c and are called DSA interfaces or slave interfaces.
>
>
> > What use are these virtual I/Fs? Just to read status from the
> > corresponding ports?
>
> That's one of the purposes, yes. There's a polling routine that
> periodically checks the status of each of the ports on the switch (via
> the MII management interface) and feeds back that status to the virtual
> interfaces. I.e. if you plug a cable into lan3, you'll see a syslog
> message about the link on the virtual interface lan3 having come up,
> with the link speed, etc.
>
>
> > Can one TX and RX network pkgs over these I/Fs too?
>
> Sure -- that's the whole point.
TX:ing pkgs on such virtual I/F would go directly to the port, bypassing
normal switching?
What about RX? What decides which pkg to route through the switch and
which pgk to send up to the virtual I/F?
>
>
> > Now I want to add STP/RSTP to the switch. How would one do that?
>
> First, you'll want the hardware bridging patches that I posted to
> netdev@ a while back, e.g.:
>
> http://patchwork.ozlabs.org/patch/16578/
I see, will have to study this a bit closer. One question though,
does this disable MAC learning in the linux bridge?
Do you have any idea how to do DSA on a Broadcom switch?
The control plane is an attached with PCI and has a big
user space lib/apps to manage the switch.
>
> They aren't in upstream-mergeable form in their current form, but they
> do the job. These will propagate brctl addif/delif calls into the switch
> chip, so that switching between those ports will be done in hardware.
>
> Now if all you want is regular STP, with that patch you'll be done --
> the ->bridge_set_stp_state() hook propagates the spanning tree state of
> each of the DSA virtual interfaces into the switch chip automatically.
>
> If you want to use a userspace STP implementation, you'll just have to
> make sure that STP state (listening/learning/blocking/forwarding/etc) is
> correctly propagated to the switch chip similarly to how it's done in the
> patch.
>
> (Ideally, these patches should be reworked to receive bridge configuration
> and port status changes via netlink. Unfortunately, I was asked to return
> all my Marvell hardware when I left Marvell, so someone else will have to
> do this work.)
>
^ permalink raw reply
* Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
From: Herbert Xu @ 2010-06-18 7:45 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: Stephen Hemminger, netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu,
davem@davemloft.net, jdike@linux.intel.com, Rusty Russell
In-Reply-To: <F2E9EB7348B8264F86B6AB8151CE2D7915089FE573@shsmsx502.ccr.corp.intel.com>
On Fri, Jun 18, 2010 at 03:14:18PM +0800, Xin, Xiaohui wrote:
>
> Thanks for the verification. By the way, does that mean that nearly all drivers can use the
> same napi_gro_frags() to receive buffers though currently each driver has it's own receiving
> function?
There is no reason why the napi_gro_frags can't be used by any
driver that supports receiving data into pages.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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 2/2] Driver core: reduce duplicated code
From: Uwe Kleine-König @ 2010-06-18 7:39 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, Greg Kroah-Hartman, Magnus Damm, Rafael J. Wysocki,
Paul Mundt, Dmitry Torokhov, Eric Miao, netdev
In-Reply-To: <20100616205332.GB15837@kroah.com>
Hi Greg,
On Wed, Jun 16, 2010 at 01:53:32PM -0700, Greg KH wrote:
> On Tue, Jun 15, 2010 at 11:05:00AM +0200, Uwe Kleine-König wrote:
> > On Tue, Jun 15, 2010 at 10:47:56AM +0200, Uwe Kleine-König wrote:
> > > This makes the two similar functions platform_device_register_simple
> > > and platform_device_register_data one line inline functions using a new
> > > generic function platform_device_register_resndata.
> > I forgot to add some comments to this mail, ... sorry.
> >
> > - I'm not completely happy with the name of the new function. If
> > someone has a better name please tell me.
>
> I don't like it either, what is "resndata" supposed to stand for?
resources and data -> res'n'data -> resndata.
> > - can platform_device_register_resndata be moved to __init_or_module?
>
> I doubt it, but try it and see if a build warns about it.
for x86_64_defconfig + MODULES=n there are two section mismatches:
dock_add
regulatory_init
regulatory_init is only called from
static int __init cfg80211_init(void)
. (I just sent a patch[1] that moves regulatory_init to .init.text.)
dock_add (in drivers/acpi/dock.c) is a bit harder. I will take a look
later if it can go to .init.text (together with a few more functions),
too.
> > - I moved the kernel docs to the header but didn't test if they are
> > picked up when generating docs. Even if not, there is no better
> > place, is there?
>
> No, that's the proper place, but make sure the docbook source is also
> picking up the .h file, I don't know if it currently does.
It does not, will fix in a v2.
Thanks
Uwe
[1] http://mid.gmane.org/1276846735-12105-2-git-send-email-u.kleine-koenig@pengutronix.de
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Lennert Buytenhek @ 2010-06-18 7:33 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF4DC5B7A3.2D318B4E-ONC1257746.00253DA6-C1257746.002714B0@transmode.se>
On Fri, Jun 18, 2010 at 09:06:52AM +0200, Joakim Tjernlund wrote:
> I am trying to wrap my head around DSA and I need some help.
>
> Assume the example from Lennert:
>
> +-----------+ +-----------+
> | | RGMII | |
> | +-------+ +------ 1000baseT MDI ("WAN")
> | | | 6-port +------ 1000baseT MDI ("LAN1")
> | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> | | | |
> +-----------+ +-----------+
>
> If I understand this correctly I get at least 5 virtual I/Fs corresponding
> to WAN, LAN1-4, but how is the RGMII I/F modelled?
The RGMII interface is just the interface that your "real" network
driver exports. In the case of the Kirkwood 6281 A0 Reference Design
(which I developed this code on), that would be eth0. After the DSA
driver is instantiated, you don't send or receive over eth0 directly
anymore -- eth0 becomes purely a transport for DSA-tagged packets.
> I guess I will have one "real" ethX I/F which maps to RGMII but do I
> get one virtual I/F too?
You get a virtual interface for each of the ports on the switch (that
are not CPU or inter-switch ports), i.e. all ports on the right of the
diagram -- wan, lan1, lan2, lan3, lan4. These interfaces are created
by net/dsa/slave.c and are called DSA interfaces or slave interfaces.
> What use are these virtual I/Fs? Just to read status from the
> corresponding ports?
That's one of the purposes, yes. There's a polling routine that
periodically checks the status of each of the ports on the switch (via
the MII management interface) and feeds back that status to the virtual
interfaces. I.e. if you plug a cable into lan3, you'll see a syslog
message about the link on the virtual interface lan3 having come up,
with the link speed, etc.
> Can one TX and RX network pkgs over these I/Fs too?
Sure -- that's the whole point.
> Now I want to add STP/RSTP to the switch. How would one do that?
First, you'll want the hardware bridging patches that I posted to
netdev@ a while back, e.g.:
http://patchwork.ozlabs.org/patch/16578/
They aren't in upstream-mergeable form in their current form, but they
do the job. These will propagate brctl addif/delif calls into the switch
chip, so that switching between those ports will be done in hardware.
Now if all you want is regular STP, with that patch you'll be done --
the ->bridge_set_stp_state() hook propagates the spanning tree state of
each of the DSA virtual interfaces into the switch chip automatically.
If you want to use a userspace STP implementation, you'll just have to
make sure that STP state (listening/learning/blocking/forwarding/etc) is
correctly propagated to the switch chip similarly to how it's done in the
patch.
(Ideally, these patches should be reworked to receive bridge configuration
and port status changes via netlink. Unfortunately, I was asked to return
all my Marvell hardware when I left Marvell, so someone else will have to
do this work.)
^ permalink raw reply
* RE: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
From: Xin, Xiaohui @ 2010-06-18 7:14 UTC (permalink / raw)
To: Herbert Xu
Cc: Stephen Hemminger, netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu,
davem@davemloft.net, jdike@linux.intel.com, Rusty Russell
In-Reply-To: <20100618055929.GA11333@gondor.apana.org.au>
>-----Original Message-----
>From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
>Sent: Friday, June 18, 2010 1:59 PM
>To: Xin, Xiaohui
>Cc: Stephen Hemminger; netdev@vger.kernel.org; kvm@vger.kernel.org;
>linux-kernel@vger.kernel.org; mst@redhat.com; mingo@elte.hu; davem@davemloft.net;
>jdike@linux.intel.com; Rusty Russell
>Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
>
>On Fri, Jun 18, 2010 at 01:26:49PM +0800, Xin, Xiaohui wrote:
>>
>> Herbert,
>> I have questions about the idea above:
>> 1) Since netdev_alloc_skb() is still there, and we only modify alloc_page(),
>> then we don't need napi_gro_frags() any more, the driver's original receiving
>> function is ok. Right?
>
>Well I was actually thinking about converting all drivers that
>need this to napi_gro_frags. But now that you mention it, yes
>we could still keep the old interface to minimise the work.
>
>> 2) Is napi_gro_frags() only suitable for TCP protocol packet?
>> I have done a small test for ixgbe driver to let it only allocate paged buffers
>> and found kernel hangs when napi_gro_frags() receives an ARP packet.
>
>It should work with any packet. In fact, I'm pretty sure the
>other drivers (e.g., cxgb3) use that interface for all packets.
>
Thanks for the verification. By the way, does that mean that nearly all drivers can use the
same napi_gro_frags() to receive buffers though currently each driver has it's own receiving
function?
>> 3) As I have mentioned above, with this idea, netdev_alloc_skb() will allocate
>> as usual, the data pointed by skb->data will be copied into the first guest buffer.
>> That means we should reserve sufficient room in guest buffer. For PS mode
>> supported driver (for example ixgbe), the room will be more than 128. After 128bytes,
>> we will put the first frag data. Look into virtio-net.c the function page_to_skb()
>> and receive_mergeable(), that means we should modify guest virtio-net driver to
>> compute the offset as the parameter for skb_set_frag().
>>
>> How do you think about this? Attached is a patch to how to modify the guest driver.
>> I reserve 512 bytes as an example, and transfer the header len of the skb in hdr->hdr_len.
>
>Expanding the buffer size to 512 bytes to accomodate PS mode
>looks reasonable to me.
>
>However, I don't think we should increase the copy threshold to
>512 bytes at the same time. I don't have any figures myself but
>I think if we are to make such a change it should be a separate
>one and come with supporting numbers.
>
Let me have a look to see if I can retain the copy threshold as 128 bytes
and copy the header data safely.
>Cheers,
>--
>Visit Openswan at http://www.openswan.org/
>Email: Herbert Xu ~{PmV>HI~} <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
* Distributed Switch Architecture(DSA)
From: Joakim Tjernlund @ 2010-06-18 7:06 UTC (permalink / raw)
To: Lennert Buytenhek, netdev
I am trying to wrap my head around DSA and I need some help.
Assume the example from Lennert:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
If I understand this correctly I get at least 5 virtual I/Fs corresponding
to WAN, LAN1-4, but how is the RGMII I/F modelled?
I guess I will have one "real" ethX I/F which maps to RGMII but do I get one
virtual I/F too?
What use are these virtual I/Fs? Just to read status from the corresponding
ports? Can one TX and RX network pkgs over these I/Fs too?
Now I want to add STP/RSTP to the switch. How would one do that?
Jocke
^ 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