* Re: [PATCH net-next 4/5] ethtool: Explicitly state the exit condition for interrupt coalescing
From: David Miller @ 2011-08-16 23:36 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, eli
In-Reply-To: <1313453317.2731.60.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 16 Aug 2011 01:08:37 +0100
> Also explicitly state how to disable interrupt coalescing.
>
> Remove the now-redundant text from field descriptions.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ethtool: Note common alternate exit condition for interrupt coalescing
From: David Miller @ 2011-08-16 23:36 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, eli
In-Reply-To: <1313453362.2731.61.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 16 Aug 2011 01:09:22 +0100
> Many implementations ignore the value of max_frames and do not
> treat usecs == 0 as special. Document this as deprecated.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* RE: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: Ben Hutchings @ 2011-08-16 23:43 UTC (permalink / raw)
To: Rasesh Mody
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A94D99537C@HQ1-EXCH01.corp.brocade.com>
On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
> >From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> >Sent: Tuesday, August 16, 2011 2:49 PM
> >
> >On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
> >> Change details:
> >> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
> >> bna_is_iscsi_over_cee
> >> - Added support for multipe Tx queues with a separate iSCSI Tx queue
> >based
> >> on the default value of iSCSI port number. The feature is supported
> >based
> >> on the underlying hardware and enabled for DCB (CEE) mode only.
> >> - Allocate multiple TxQ resource in netdev
> >> - Implement bnad_tx_select_queue() which enables the correct
> >selection of
> >> TxQ Id (and tcb). This function is called either by the kernel to
> >channel
> >> packets to the right TxQ
> >> - bnad_tx_select_queue() returns priority, while only a few packets
> >during
> >> transition could have wrong priority, all will be associated with a
> >valid
> >> non-NULL tcb.
> >> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
> >packet
> >> inspection and retrieval of tcb corresponding to the iSCSI
> >priority.
> >> - Construction of priority indirection table to be used by bnad to
> >direct
> >> packets into TxQs
> >[...]
> >
> >You probably should implement TX priority classes through the
> >ndo_setup_tc operation, not ndo_select_queue.
>
> The reason we went with ndo_select_queue is due to the need for mapping
> iSCSI packets (TCP port 3260) to a priority derived from DCB configuration.
> Here the iSCSI packets may not have any tc defined in the packet header.
There is an skb priority, which is derived from the socket priority
option (SO_PRIORITY). If you implement ndo_setup_tc then the networking
core will take care of mapping the skb priority onto a different queue
(or range of queues).
I don't know whether the socket priority option is easily configurable
for the existing iSCSI implementations. But looking at port numbers
really doesn't seem like the right way to do this.
Ben.
--
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
* linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-17 0:01 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jeff Kirsher
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
Hi all,
I do build and boot tests for various PowerPC servers I have access to.
Last night's test failed due to the fact that their ethernet drivers are
not longer being built. In particular, CONFIG_TIGON3 newly depends on
CONFIG_NET_VENDOR_BROADCOM which will no be selected when doing a "make
oldconfig" from a working config. Similarly for CONFIG_IBM_VETH and (the
new) CONFIG_VENDOR_IBM. The original config had both CONFIG_TIGON3 and
CONFIG_IBM_VETH set (to y and m resp.) and the final config had neither.
These Kconfig changes need to be revised so that "make oldconfig" from a
working config builds the same set of drivers ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-17 0:15 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110817100146.3b557cf815a5a2ae09bc09a7@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Aug 2011 10:01:46 +1000
> In particular, CONFIG_TIGON3 newly depends on
> CONFIG_NET_VENDOR_BROADCOM which will no be selected when doing a
> "make oldconfig" from a working config.
When you type "make oldconfig" with an existing .config it prompts you
for those vendor guards, giving you ample opportunity to say yes to
them.
^ permalink raw reply
* Re: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: John Fastabend @ 2011-08-17 0:17 UTC (permalink / raw)
To: Ben Hutchings
Cc: Rasesh Mody, davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <1313538196.2725.74.camel@bwh-desktop>
On 8/16/2011 4:43 PM, Ben Hutchings wrote:
> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>
>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>> Change details:
>>>> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>>>> bna_is_iscsi_over_cee
>>>> - Added support for multipe Tx queues with a separate iSCSI Tx queue
>>> based
>>>> on the default value of iSCSI port number. The feature is supported
>>> based
>>>> on the underlying hardware and enabled for DCB (CEE) mode only.
>>>> - Allocate multiple TxQ resource in netdev
>>>> - Implement bnad_tx_select_queue() which enables the correct
>>> selection of
>>>> TxQ Id (and tcb). This function is called either by the kernel to
>>> channel
>>>> packets to the right TxQ
>>>> - bnad_tx_select_queue() returns priority, while only a few packets
>>> during
>>>> transition could have wrong priority, all will be associated with a
>>> valid
>>>> non-NULL tcb.
>>>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>>> packet
>>>> inspection and retrieval of tcb corresponding to the iSCSI
>>> priority.
>>>> - Construction of priority indirection table to be used by bnad to
>>> direct
>>>> packets into TxQs
>>> [...]
>>>
>>> You probably should implement TX priority classes through the
>>> ndo_setup_tc operation, not ndo_select_queue.
>>
>> The reason we went with ndo_select_queue is due to the need for mapping
>> iSCSI packets (TCP port 3260) to a priority derived from DCB configuration.
>> Here the iSCSI packets may not have any tc defined in the packet header.
>
> There is an skb priority, which is derived from the socket priority
> option (SO_PRIORITY). If you implement ndo_setup_tc then the networking
> core will take care of mapping the skb priority onto a different queue
> (or range of queues).
>
> I don't know whether the socket priority option is easily configurable
> for the existing iSCSI implementations. But looking at port numbers
> really doesn't seem like the right way to do this.
>
> Ben.
>
At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for events.
These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To support
this in your driver you need to call dcb_setapp() or dcb_ieee_setapp() to
add the application data and follow this with the appropriate notify call.
Then assuming you do the necessary tc setup work the stack will handle the
mapping of priority to queues.
John.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-17 0:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110816.171525.639251389938336183.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
Hi Dave,
On Tue, 16 Aug 2011 17:15:25 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Aug 2011 10:01:46 +1000
>
> > In particular, CONFIG_TIGON3 newly depends on
> > CONFIG_NET_VENDOR_BROADCOM which will no be selected when doing a
> > "make oldconfig" from a working config.
>
> When you type "make oldconfig" with an existing .config it prompts you
> for those vendor guards, giving you ample opportunity to say yes to
> them.
Which is a bit of a pain for automated systems. Ours does (essentially):
yes '' | make oldconfig
We really don't want to select every new config item that comes along.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-17 0:56 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110817105002.efebf85d08460ad99b14be8e@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Aug 2011 10:50:02 +1000
> Which is a bit of a pain for automated systems. Ours does (essentially):
>
> yes '' | make oldconfig
>
> We really don't want to select every new config item that comes along.
If you're indeed piping "yes" output to "make oldconfig" on an
existing config, it would select the new guards for you.
This happens on other occaisions, I see new group guards all
the time when I resync my net and net-next trees with Linus.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Ben Hutchings @ 2011-08-17 1:19 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110816.175657.1688139393736610845.davem@davemloft.net>
On Tue, 2011-08-16 at 17:56 -0700, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Aug 2011 10:50:02 +1000
>
> > Which is a bit of a pain for automated systems. Ours does (essentially):
> >
> > yes '' | make oldconfig
> >
> > We really don't want to select every new config item that comes along.
>
> If you're indeed piping "yes" output to "make oldconfig" on an
> existing config, it would select the new guards for you.
[....]
If you were to use just "yes", then of course it would. But since there
is no explicit default, "yes ''" will deselect them.
Maybe these guards should have "default y"?
Ben.
--
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: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-17 1:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110816.175657.1688139393736610845.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
Hi Dave,
On Tue, 16 Aug 2011 17:56:57 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Aug 2011 10:50:02 +1000
>
> > Which is a bit of a pain for automated systems. Ours does (essentially):
> >
> > yes '' | make oldconfig
> >
> > We really don't want to select every new config item that comes along.
>
> If you're indeed piping "yes" output to "make oldconfig" on an
> existing config, it would select the new guards for you.
Notice the '' that just is the same as typing return to every prompt. In
the case of these new gueards, that means 'n'. This will be the same
with "make silentoldconfig".
> This happens on other occaisions, I see new group guards all
> the time when I resync my net and net-next trees with Linus.
"All the time"? really?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: Rasesh Mody @ 2011-08-17 2:14 UTC (permalink / raw)
To: John Fastabend, Ben Hutchings
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <4E4B089E.9080102@intel.com>
>From: John Fastabend [mailto:john.r.fastabend@intel.com]
>Sent: Tuesday, August 16, 2011 5:18 PM
>
>On 8/16/2011 4:43 PM, Ben Hutchings wrote:
>> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>>> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>>
>>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>>> Change details:
>>>>> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>>>>> bna_is_iscsi_over_cee
>>>>> - Added support for multipe Tx queues with a separate iSCSI Tx
>queue
>>>> based
>>>>> on the default value of iSCSI port number. The feature is
>supported
>>>> based
>>>>> on the underlying hardware and enabled for DCB (CEE) mode only.
>>>>> - Allocate multiple TxQ resource in netdev
>>>>> - Implement bnad_tx_select_queue() which enables the correct
>>>> selection of
>>>>> TxQ Id (and tcb). This function is called either by the kernel
>to
>>>> channel
>>>>> packets to the right TxQ
>>>>> - bnad_tx_select_queue() returns priority, while only a few
>packets
>>>> during
>>>>> transition could have wrong priority, all will be associated
>with a
>>>> valid
>>>>> non-NULL tcb.
>>>>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>>>> packet
>>>>> inspection and retrieval of tcb corresponding to the iSCSI
>>>> priority.
>>>>> - Construction of priority indirection table to be used by bnad to
>>>> direct
>>>>> packets into TxQs
>>>> [...]
>>>>
>>>> You probably should implement TX priority classes through the
>>>> ndo_setup_tc operation, not ndo_select_queue.
>>>
>>> The reason we went with ndo_select_queue is due to the need for
>mapping
>>> iSCSI packets (TCP port 3260) to a priority derived from DCB
>configuration.
>>> Here the iSCSI packets may not have any tc defined in the packet
>header.
>>
>> There is an skb priority, which is derived from the socket priority
>> option (SO_PRIORITY). If you implement ndo_setup_tc then the
>networking
>> core will take care of mapping the skb priority onto a different queue
>> (or range of queues).
>>
>> I don't know whether the socket priority option is easily configurable
>> for the existing iSCSI implementations. But looking at port numbers
>> really doesn't seem like the right way to do this.
>>
>> Ben.
>>
>
>At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for
>events.
>These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To
>support
>this in your driver you need to call dcb_setapp() or dcb_ieee_setapp()
>to
>add the application data and follow this with the appropriate notify
>call.
>Then assuming you do the necessary tc setup work the stack will handle
>the
>mapping of priority to queues.
This is how iSCSI over DCB feature is expected to works in BNA driver:-
FW running in the BNA adapter implements the DCB protocol. It learns the
iSCSI priority from the switch through iSCSI TLV exchange. BNA driver
extracts the iSCSI priority from the FW that needs to be used for iSCSI
packets. For every outgoing packet, BNA driver does a TCP header
inspection to classify iSCSI packet and attach right 802.1q priority &
send it on the correct TX queue.
This is expected to work with iSCSI applications that do not configure the
priority with SO_PRIORITY - here the iSCSI priority configuration actually
comes from the switch to the adapter.
The goal of this iSCSI priority is:
a) adapter applies prioritized scheduling for packets in its egress - to
guarantee minimum bandwidth as per ETS
b) packets are tagged with right priority so that switch can also identify
and guarantee BW on its egress.
Hope this explains.
Thanks,
Rasesh
^ permalink raw reply
* Attention
From: Mr.Sani Mohammed @ 2011-08-17 1:26 UTC (permalink / raw)
I wrote to know if this is your valid email. Please, let me know if
this Email is valid. I have information to pass to you. The G-20
meeting that was hold recently in France has appointed you through an
email electronic ballot system selection. That makes you the beneficiary
of 1.2 Million USD, in this year?s annual financial meeting for the
development
of your geographical area that will enhance the economic growth of the
society.
Please confirm your email to the G-20 Secretarial in Malaysia.
Please notify us if your email is valid by providing the below details.
Full Name:
Country:
Email: sani_moh9090@yahoo.com.my
Mr.Sani Mohammed
Tele: +601116300759
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-17 3:04 UTC (permalink / raw)
To: bhutchings; +Cc: sfr, netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <1313543952.2981.132.camel@deadeye>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 17 Aug 2011 02:19:12 +0100
> If you were to use just "yes", then of course it would. But since there
> is no explicit default, "yes ''" will deselect them.
>
> Maybe these guards should have "default y"?
The point is to declutter xconfig and friends, if it defaults to
'y' everything will just always expand.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-17 3:05 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20110817112110.ec81ef078204bf4a02049a66@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Aug 2011 11:21:10 +1000
> On Tue, 16 Aug 2011 17:56:57 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>>
>> This happens on other occaisions, I see new group guards all
>> the time when I resync my net and net-next trees with Linus.
>
> "All the time"? really?
I can't think of too many days during the merge window where this
doesn't happen, quite frankly.
^ permalink raw reply
* [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, PPC list
David,
The following set of patches have been reviewed by the above parties and
all comments have been integrated. Although the patches stray from the
drivers/net/can directory, the diversions are related to changes for
the flexcan driver.
The patch set is based upon your net-next-2.6 tree's commit 6c37e46.
Could you please queue these up for the next appropriate push to Linus'
tree?
Thanks,
Robin Holt
^ permalink raw reply
* [PATCH v13 1/6] flexcan: Remove #include <mach/clock.h>
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
powerpc does not have a mach-####/clock.h. When testing, I found neither
arm nor powerpc needed the mach/clock.h at all so I removed it.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
---
drivers/net/can/flexcan.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 1767811..586b2cd 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -35,8 +35,6 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-#include <mach/clock.h>
-
#define DRV_NAME "flexcan"
/* 8 for RX fifo and 2 error handling */
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 2/6] flexcan: Abstract off read/write for big/little endian.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Make flexcan driver handle register reads in the appropriate endianess.
This was a basic search and replace and then define some inlines.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
---
drivers/net/can/flexcan.c | 140 ++++++++++++++++++++++++++------------------
1 files changed, 83 insertions(+), 57 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 586b2cd..68cbe52 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -190,6 +190,31 @@ static struct can_bittiming_const flexcan_bittiming_const = {
};
/*
+ * Abstract off the read/write for arm versus ppc.
+ */
+#if defined(__BIG_ENDIAN)
+static inline u32 flexcan_read(void __iomem *addr)
+{
+ return in_be32(addr);
+}
+
+static inline void flexcan_write(u32 val, void __iomem *addr)
+{
+ out_be32(addr, val);
+}
+#else
+static inline u32 flexcan_read(void __iomem *addr)
+{
+ return readl(addr);
+}
+
+static inline void flexcan_write(u32 val, void __iomem *addr)
+{
+ writel(val, addr);
+}
+#endif
+
+/*
* Swtich transceiver on or off
*/
static void flexcan_transceiver_switch(const struct flexcan_priv *priv, int on)
@@ -210,9 +235,9 @@ static inline void flexcan_chip_enable(struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg &= ~FLEXCAN_MCR_MDIS;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
udelay(10);
}
@@ -222,9 +247,9 @@ static inline void flexcan_chip_disable(struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_MDIS;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
}
static int flexcan_get_berr_counter(const struct net_device *dev,
@@ -232,7 +257,7 @@ static int flexcan_get_berr_counter(const struct net_device *dev,
{
const struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->base;
- u32 reg = readl(®s->ecr);
+ u32 reg = flexcan_read(®s->ecr);
bec->txerr = (reg >> 0) & 0xff;
bec->rxerr = (reg >> 8) & 0xff;
@@ -266,15 +291,15 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (cf->can_dlc > 0) {
u32 data = be32_to_cpup((__be32 *)&cf->data[0]);
- writel(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[0]);
+ flexcan_write(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[0]);
}
if (cf->can_dlc > 3) {
u32 data = be32_to_cpup((__be32 *)&cf->data[4]);
- writel(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[1]);
+ flexcan_write(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[1]);
}
- writel(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
- writel(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
+ flexcan_write(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
+ flexcan_write(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
kfree_skb(skb);
@@ -462,8 +487,8 @@ static void flexcan_read_fifo(const struct net_device *dev,
struct flexcan_mb __iomem *mb = ®s->cantxfg[0];
u32 reg_ctrl, reg_id;
- reg_ctrl = readl(&mb->can_ctrl);
- reg_id = readl(&mb->can_id);
+ reg_ctrl = flexcan_read(&mb->can_ctrl);
+ reg_id = flexcan_read(&mb->can_id);
if (reg_ctrl & FLEXCAN_MB_CNT_IDE)
cf->can_id = ((reg_id >> 0) & CAN_EFF_MASK) | CAN_EFF_FLAG;
else
@@ -473,12 +498,12 @@ static void flexcan_read_fifo(const struct net_device *dev,
cf->can_id |= CAN_RTR_FLAG;
cf->can_dlc = get_can_dlc((reg_ctrl >> 16) & 0xf);
- *(__be32 *)(cf->data + 0) = cpu_to_be32(readl(&mb->data[0]));
- *(__be32 *)(cf->data + 4) = cpu_to_be32(readl(&mb->data[1]));
+ *(__be32 *)(cf->data + 0) = cpu_to_be32(flexcan_read(&mb->data[0]));
+ *(__be32 *)(cf->data + 4) = cpu_to_be32(flexcan_read(&mb->data[1]));
/* mark as read */
- writel(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
- readl(®s->timer);
+ flexcan_write(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
+ flexcan_read(®s->timer);
}
static int flexcan_read_frame(struct net_device *dev)
@@ -514,17 +539,17 @@ static int flexcan_poll(struct napi_struct *napi, int quota)
* The error bits are cleared on read,
* use saved value from irq handler.
*/
- reg_esr = readl(®s->esr) | priv->reg_esr;
+ reg_esr = flexcan_read(®s->esr) | priv->reg_esr;
/* handle state changes */
work_done += flexcan_poll_state(dev, reg_esr);
/* handle RX-FIFO */
- reg_iflag1 = readl(®s->iflag1);
+ reg_iflag1 = flexcan_read(®s->iflag1);
while (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_AVAILABLE &&
work_done < quota) {
work_done += flexcan_read_frame(dev);
- reg_iflag1 = readl(®s->iflag1);
+ reg_iflag1 = flexcan_read(®s->iflag1);
}
/* report bus errors */
@@ -534,8 +559,8 @@ static int flexcan_poll(struct napi_struct *napi, int quota)
if (work_done < quota) {
napi_complete(napi);
/* enable IRQs */
- writel(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
- writel(priv->reg_ctrl_default, ®s->ctrl);
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
+ flexcan_write(priv->reg_ctrl_default, ®s->ctrl);
}
return work_done;
@@ -549,9 +574,9 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg_iflag1, reg_esr;
- reg_iflag1 = readl(®s->iflag1);
- reg_esr = readl(®s->esr);
- writel(FLEXCAN_ESR_ERR_INT, ®s->esr); /* ACK err IRQ */
+ reg_iflag1 = flexcan_read(®s->iflag1);
+ reg_esr = flexcan_read(®s->esr);
+ flexcan_write(FLEXCAN_ESR_ERR_INT, ®s->esr); /* ACK err IRQ */
/*
* schedule NAPI in case of:
@@ -567,16 +592,16 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
* save them for later use.
*/
priv->reg_esr = reg_esr & FLEXCAN_ESR_ERR_BUS;
- writel(FLEXCAN_IFLAG_DEFAULT & ~FLEXCAN_IFLAG_RX_FIFO_AVAILABLE,
- ®s->imask1);
- writel(priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_ALL,
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT &
+ ~FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->imask1);
+ flexcan_write(priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_ALL,
®s->ctrl);
napi_schedule(&priv->napi);
}
/* FIFO overflow */
if (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_OVERFLOW) {
- writel(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW, ®s->iflag1);
+ flexcan_write(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW, ®s->iflag1);
dev->stats.rx_over_errors++;
dev->stats.rx_errors++;
}
@@ -585,7 +610,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
if (reg_iflag1 & (1 << FLEXCAN_TX_BUF_ID)) {
/* tx_bytes is incremented in flexcan_start_xmit */
stats->tx_packets++;
- writel((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
+ flexcan_write((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
netif_wake_queue(dev);
}
@@ -599,7 +624,7 @@ static void flexcan_set_bittiming(struct net_device *dev)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->ctrl);
+ reg = flexcan_read(®s->ctrl);
reg &= ~(FLEXCAN_CTRL_PRESDIV(0xff) |
FLEXCAN_CTRL_RJW(0x3) |
FLEXCAN_CTRL_PSEG1(0x7) |
@@ -623,11 +648,11 @@ static void flexcan_set_bittiming(struct net_device *dev)
reg |= FLEXCAN_CTRL_SMP;
dev_info(dev->dev.parent, "writing ctrl=0x%08x\n", reg);
- writel(reg, ®s->ctrl);
+ flexcan_write(reg, ®s->ctrl);
/* print chip status */
dev_dbg(dev->dev.parent, "%s: mcr=0x%08x ctrl=0x%08x\n", __func__,
- readl(®s->mcr), readl(®s->ctrl));
+ flexcan_read(®s->mcr), flexcan_read(®s->ctrl));
}
/*
@@ -648,10 +673,10 @@ static int flexcan_chip_start(struct net_device *dev)
flexcan_chip_enable(priv);
/* soft reset */
- writel(FLEXCAN_MCR_SOFTRST, ®s->mcr);
+ flexcan_write(FLEXCAN_MCR_SOFTRST, ®s->mcr);
udelay(10);
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
if (reg_mcr & FLEXCAN_MCR_SOFTRST) {
dev_err(dev->dev.parent,
"Failed to softreset can module (mcr=0x%08x)\n",
@@ -673,12 +698,12 @@ static int flexcan_chip_start(struct net_device *dev)
* choose format C
*
*/
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
reg_mcr |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_FEN | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_SUPV | FLEXCAN_MCR_WRN_EN |
FLEXCAN_MCR_IDAM_C;
dev_dbg(dev->dev.parent, "%s: writing mcr=0x%08x", __func__, reg_mcr);
- writel(reg_mcr, ®s->mcr);
+ flexcan_write(reg_mcr, ®s->mcr);
/*
* CTRL
@@ -696,7 +721,7 @@ static int flexcan_chip_start(struct net_device *dev)
* (FLEXCAN_CTRL_ERR_MSK), too. Otherwise we don't get any
* warning or bus passive interrupts.
*/
- reg_ctrl = readl(®s->ctrl);
+ reg_ctrl = flexcan_read(®s->ctrl);
reg_ctrl &= ~FLEXCAN_CTRL_TSYN;
reg_ctrl |= FLEXCAN_CTRL_BOFF_REC | FLEXCAN_CTRL_LBUF |
FLEXCAN_CTRL_ERR_STATE | FLEXCAN_CTRL_ERR_MSK;
@@ -704,38 +729,39 @@ static int flexcan_chip_start(struct net_device *dev)
/* save for later use */
priv->reg_ctrl_default = reg_ctrl;
dev_dbg(dev->dev.parent, "%s: writing ctrl=0x%08x", __func__, reg_ctrl);
- writel(reg_ctrl, ®s->ctrl);
+ flexcan_write(reg_ctrl, ®s->ctrl);
for (i = 0; i < ARRAY_SIZE(regs->cantxfg); i++) {
- writel(0, ®s->cantxfg[i].can_ctrl);
- writel(0, ®s->cantxfg[i].can_id);
- writel(0, ®s->cantxfg[i].data[0]);
- writel(0, ®s->cantxfg[i].data[1]);
+ flexcan_write(0, ®s->cantxfg[i].can_ctrl);
+ flexcan_write(0, ®s->cantxfg[i].can_id);
+ flexcan_write(0, ®s->cantxfg[i].data[0]);
+ flexcan_write(0, ®s->cantxfg[i].data[1]);
/* put MB into rx queue */
- writel(FLEXCAN_MB_CNT_CODE(0x4), ®s->cantxfg[i].can_ctrl);
+ flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
+ ®s->cantxfg[i].can_ctrl);
}
/* acceptance mask/acceptance code (accept everything) */
- writel(0x0, ®s->rxgmask);
- writel(0x0, ®s->rx14mask);
- writel(0x0, ®s->rx15mask);
+ flexcan_write(0x0, ®s->rxgmask);
+ flexcan_write(0x0, ®s->rx14mask);
+ flexcan_write(0x0, ®s->rx15mask);
flexcan_transceiver_switch(priv, 1);
/* synchronize with the can bus */
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
reg_mcr &= ~FLEXCAN_MCR_HALT;
- writel(reg_mcr, ®s->mcr);
+ flexcan_write(reg_mcr, ®s->mcr);
priv->can.state = CAN_STATE_ERROR_ACTIVE;
/* enable FIFO interrupts */
- writel(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
/* print chip status */
dev_dbg(dev->dev.parent, "%s: reading mcr=0x%08x ctrl=0x%08x\n",
- __func__, readl(®s->mcr), readl(®s->ctrl));
+ __func__, flexcan_read(®s->mcr), flexcan_read(®s->ctrl));
return 0;
@@ -757,12 +783,12 @@ static void flexcan_chip_stop(struct net_device *dev)
u32 reg;
/* Disable all interrupts */
- writel(0, ®s->imask1);
+ flexcan_write(0, ®s->imask1);
/* Disable + halt module */
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_MDIS | FLEXCAN_MCR_HALT;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
flexcan_transceiver_switch(priv, 0);
priv->can.state = CAN_STATE_STOPPED;
@@ -854,24 +880,24 @@ static int __devinit register_flexcandev(struct net_device *dev)
/* select "bus clock", chip must be disabled */
flexcan_chip_disable(priv);
- reg = readl(®s->ctrl);
+ reg = flexcan_read(®s->ctrl);
reg |= FLEXCAN_CTRL_CLK_SRC;
- writel(reg, ®s->ctrl);
+ flexcan_write(reg, ®s->ctrl);
flexcan_chip_enable(priv);
/* set freeze, halt and activate FIFO, restrict register access */
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_FEN | FLEXCAN_MCR_SUPV;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
/*
* Currently we only support newer versions of this core
* featuring a RX FIFO. Older cores found on some Coldfire
* derivates are not yet supported.
*/
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
if (!(reg & FLEXCAN_MCR_FEN)) {
dev_err(dev->dev.parent,
"Could not enable RX FIFO, unsupported core\n");
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, Grant Likely, Marc Kleine-Budde, Scott Wood, PPC list,
Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
This patch cleans up the documentation of the device-tree binding for
the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
properties are not used by the driver so we are removing them.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
---
.../devicetree/bindings/net/can/fsl-flexcan.txt | 61 ++++----------------
arch/powerpc/boot/dts/p1010rdb.dts | 10 +---
arch/powerpc/boot/dts/p1010si.dtsi | 10 +--
3 files changed, 17 insertions(+), 64 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 1a729f0..8dfb98b 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -1,61 +1,22 @@
-CAN Device Tree Bindings
-------------------------
-2011 Freescale Semiconductor, Inc.
+Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
-fsl,flexcan-v1.0 nodes
------------------------
-In addition to the required compatible-, reg- and interrupt-properties, you can
-also specify which clock source shall be used for the controller.
+Required properties:
-CPI Clock- Can Protocol Interface Clock
- This CLK_SRC bit of CTRL(control register) selects the clock source to
- the CAN Protocol Interface(CPI) to be either the peripheral clock
- (driven by the PLL) or the crystal oscillator clock. The selected clock
- is the one fed to the prescaler to generate the Serial Clock (Sclock).
- The PRESDIV field of CTRL(control register) controls a prescaler that
- generates the Serial Clock (Sclock), whose period defines the
- time quantum used to compose the CAN waveform.
+- compatible : Should be "fsl,<processor>-flexcan"
-Can Engine Clock Source
- There are two sources for CAN clock
- - Platform Clock It represents the bus clock
- - Oscillator Clock
+ An implementation should also claim any of the following compatibles
+ that it is fully backwards compatible with:
- Peripheral Clock (PLL)
- --------------
- |
- --------- -------------
- | |CPI Clock | Prescaler | Sclock
- | |---------------->| (1.. 256) |------------>
- --------- -------------
- | |
- -------------- ---------------------CLK_SRC
- Oscillator Clock
+ - fsl,p1010-flexcan
-- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
- the peripheral clock. PLL clock is fed to the
- prescaler to generate the Serial Clock (Sclock).
- Valid values are "oscillator" and "platform"
- "oscillator": CAN engine clock source is oscillator clock.
- "platform" The CAN engine clock source is the bus clock
- (platform clock).
+- reg : Offset and length of the register set for this device
+- interrupts : Interrupt tuple for this device
-- fsl,flexcan-clock-divider : for the reference and system clock, an additional
- clock divider can be specified.
-- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
+Example:
-Note:
- - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
- - P1010 does not have oscillator as the Clock Source.So the default
- Clock Source is platform clock.
-Examples:
-
- can0@1c000 {
- compatible = "fsl,flexcan-v1.0";
+ can@1c000 {
+ compatible = "fsl,p1010-flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-source = "platform";
- fsl,flexcan-clock-divider = <2>;
- clock-frequency = <fixed by u-boot>;
};
diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
index 6b33b73..d6c669c 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dts
+++ b/arch/powerpc/boot/dts/p1010rdb.dts
@@ -23,6 +23,8 @@
ethernet2 = &enet2;
pci0 = &pci0;
pci1 = &pci1;
+ can0 = &can0;
+ can1 = &can1;
};
memory {
@@ -169,14 +171,6 @@
};
};
- can0@1c000 {
- fsl,flexcan-clock-source = "platform";
- };
-
- can1@1d000 {
- fsl,flexcan-clock-source = "platform";
- };
-
usb@22000 {
phy_type = "utmi";
};
diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
index 7f51104..cabe0a4 100644
--- a/arch/powerpc/boot/dts/p1010si.dtsi
+++ b/arch/powerpc/boot/dts/p1010si.dtsi
@@ -140,20 +140,18 @@
interrupt-parent = <&mpic>;
};
- can0@1c000 {
- compatible = "fsl,flexcan-v1.0";
+ can0: can@1c000 {
+ compatible = "fsl,p1010-flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-divider = <2>;
};
- can1@1d000 {
- compatible = "fsl,flexcan-v1.0";
+ can1: can@1d000 {
+ compatible = "fsl,p1010-flexcan";
reg = <0x1d000 0x1000>;
interrupts = <61 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-divider = <2>;
};
L2: l2-cache-controller@20000 {
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 4/6] flexcan: Add of_match to platform_device definition.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Grant Likely, Marc Kleine-Budde, PPC list, Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
On powerpc, the OpenFirmware devices are not matched without specifying
an of_match array. Introduce that array as that is used for matching
on the Freescale P1010 processor.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
---
drivers/net/can/flexcan.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 68cbe52..cc1e0a7 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -1027,8 +1027,19 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id flexcan_of_match[] = {
+ {
+ .compatible = "fsl,p1010-flexcan",
+ },
+ {},
+};
+
static struct platform_driver flexcan_driver = {
- .driver.name = DRV_NAME,
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = flexcan_of_match,
+ },
.probe = flexcan_probe,
.remove = __devexit_p(flexcan_remove),
};
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 6/6] flexcan: Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Allow the p1010 processor to select the flexcan network driver.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---
arch/powerpc/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6926b61..47682b6 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -656,6 +656,8 @@ config SBUS
config FSL_SOC
bool
+ select HAVE_CAN_FLEXCAN if NET && CAN
+ select PPC_CLOCK if CAN_FLEXCAN
config FSL_PCI
bool
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 5/6] flexcan: Prefer device tree clock frequency if available.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: Robin Holt, Wolfgang Grandegger, Kumar Gala, Marc Kleine-Budde,
U Bhaskar-B22300, Scott Wood, Grant Likely, socketcan-core,
netdev, PPC list, devicetree-discuss
In-Reply-To: <1313551944-28603-1-git-send-email-holt@sgi.com>
If our CAN device's device tree node has a clock-frequency property,
then use that value for the can devices clock frequency. If not, fall
back to asking the platform/mach code for the clock frequency associated
with the flexcan device.
Signed-off-by: Robin Holt <holt@sgi.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>,
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
Cc: U Bhaskar-B22300 <B22300@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: socketcan-core@lists.berlios.de,
Cc: netdev@vger.kernel.org,
Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
Cc: devicetree-discuss@lists.ozlabs.org
---
.../devicetree/bindings/net/can/fsl-flexcan.txt | 2 +
drivers/net/can/flexcan.c | 34 ++++++++++++++-----
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 8dfb98b..1ad80d5 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -11,6 +11,7 @@ Required properties:
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
+- clock-frequency : The oscillator frequency driving the flexcan device
Example:
@@ -19,4 +20,5 @@ Example:
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
+ clock-frequency = <200000000>; // filled in by bootloader
};
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index cc1e0a7..e023379 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -33,6 +33,7 @@
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#define DRV_NAME "flexcan"
@@ -925,16 +926,29 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
struct net_device *dev;
struct flexcan_priv *priv;
struct resource *mem;
- struct clk *clk;
+ struct clk *clk = NULL;
void __iomem *base;
resource_size_t mem_size;
int err, irq;
+ u32 clock_freq = 0;
+
+ if (pdev->dev.of_node) {
+ const u32 *clock_freq_p;
- clk = clk_get(&pdev->dev, NULL);
- if (IS_ERR(clk)) {
- dev_err(&pdev->dev, "no clock defined\n");
- err = PTR_ERR(clk);
- goto failed_clock;
+ clock_freq_p = of_get_property(pdev->dev.of_node,
+ "clock-frequency", NULL);
+ if (clock_freq_p)
+ clock_freq = *clock_freq_p;
+ }
+
+ if (!clock_freq) {
+ clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "no clock defined\n");
+ err = PTR_ERR(clk);
+ goto failed_clock;
+ }
+ clock_freq = clk_get_rate(clk);
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -967,7 +981,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
dev->flags |= IFF_ECHO; /* we support local echo in hardware */
priv = netdev_priv(dev);
- priv->can.clock.freq = clk_get_rate(clk);
+ priv->can.clock.freq = clock_freq;
priv->can.bittiming_const = &flexcan_bittiming_const;
priv->can.do_set_mode = flexcan_set_mode;
priv->can.do_get_berr_counter = flexcan_get_berr_counter;
@@ -1002,7 +1016,8 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
failed_map:
release_mem_region(mem->start, mem_size);
failed_get:
- clk_put(clk);
+ if (clk)
+ clk_put(clk);
failed_clock:
return err;
}
@@ -1020,7 +1035,8 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(mem->start, resource_size(mem));
- clk_put(priv->clk);
+ if (priv->clk)
+ clk_put(priv->clk);
free_candev(dev);
--
1.7.2.1
^ permalink raw reply related
* PROTECTED PROJECT
From: Mr. Vincent Cheng @ 2011-08-17 4:44 UTC (permalink / raw)
I am Mr. Vincent Cheng, GBS, JP Chairman of the Hong Kong and Shanghai
Banking Corporation Limited.
i have a business proposal of Twenty Two million Five Hundred Thousand
United State Dollars only for you to
transact with me from my bank to your country.Having gone through a
methodical search, I decided to contact you hoping
that you will find this proposal interesting. Please on your
confirmation of this message and indicating your interest
All confirmable documents to back up the claims will be made available
to you prior to your acceptance
and as soon as I receive your return mail Via my email
address:vincent.cheng@qatar.io and I will let
you know what is required of you,your earliest response to this letter
will be appreciated.
Endeavor to let me know your decision rather than keep me waiting
Best Regards,
Mr. Vincent Cheng
^ permalink raw reply
* IXGBE driver indicates "not enough MMIO resources for SR-IOV"
From: J.Hwan Kim @ 2011-08-17 5:38 UTC (permalink / raw)
To: netdev
Hi, everyone
When I set SR-IOV function in driver base on intel ixgbe,
the driver shows error message "not enough MMIO resources for SR-IOV".
My cpu is XEON E5450.
I set Intel Virutualization Technology option enable in BIOS.
How can I fix this problem?
Thanks in advance
Best Regards,
J.Hwan Kim
^ permalink raw reply
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Jiri Pirko @ 2011-08-17 5:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon, netdev, mike.auty
In-Reply-To: <20110816150918.5b2d7067.akpm@linux-foundation.org>
Wed, Aug 17, 2011 at 12:09:18AM CEST, akpm@linux-foundation.org wrote:
>
>(switched to email. Please respond via emailed reply-to-all, not via the
>bugzilla web interface).
>
>On Sun, 14 Aug 2011 12:48:16 GMT
>bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=41152
>>
>> Summary: kernel 3.0 and above fails to handle vlan id 0
>> (802.1p) packets properly without hardware
>> acceleration
>> Product: Networking
>> Version: 2.5
>> Kernel Version: 3.0
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Other
>> AssignedTo: acme@ghostprotocols.net
>> ReportedBy: mike.auty@gmail.com
>> Regression: Yes
>>
>>
>> Hi there,
>>
>> I recently found that packets tagged with a vlan id of 0 are no longer received
>> on the main interface. There were no dmesg entries on the dropped packets. I
>> attempted to setup a vlan 0 interface and configure it, but couldn't
>> successfully route traffic to the device. I can recreate this on two of the
>> three networking devices I have, my guess is that the third does successfully
>> handle hardware acceleration of vlan tags.
>>
>> After a bisection this appears to be related to commit
>> bcc6d47903612c3861201cc3a866fb604f26b8b2, which seems to try to merge the
>> non-hardware accelerated and hardware accelerated code paths for handling
>> vlans. In the process, it appears vlan id 0 (802.1p) packets are no longer
>> handled correctly.
>>
>> Unfortunately I don't know the code paths well enough to figure out what's
>> going wrong, but I'd be happy to provide more information, run tests or try out
>> patches if it would help, just let me know. Thanks... 5:)
>>
>> Mike 5:)
Hi Mike. May I ask what NIC are you seeing the regression on?
It may have something to do with dev->vlangrp and ndo_vlan_add/kill_vid.
VID 0 was recently only added by the latter ones. So if driver only
depended on dev->vlangrp, 0 was not there. This was changed recently by
my "vlan cleanup" patches. It may work for you again on net-next today.
Jirka
>
^ permalink raw reply
* Re: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: John Fastabend @ 2011-08-17 5:47 UTC (permalink / raw)
To: Rasesh Mody
Cc: Ben Hutchings, davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A94D9953ED@HQ1-EXCH01.corp.brocade.com>
On 8/16/2011 7:14 PM, Rasesh Mody wrote:
>> From: John Fastabend [mailto:john.r.fastabend@intel.com]
>> Sent: Tuesday, August 16, 2011 5:18 PM
>>
>> On 8/16/2011 4:43 PM, Ben Hutchings wrote:
>>> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>>>> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>>>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>>>
>>>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>>>> Change details:
>>>>>> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>>>>>> bna_is_iscsi_over_cee
>>>>>> - Added support for multipe Tx queues with a separate iSCSI Tx
>> queue
>>>>> based
>>>>>> on the default value of iSCSI port number. The feature is
>> supported
>>>>> based
>>>>>> on the underlying hardware and enabled for DCB (CEE) mode only.
>>>>>> - Allocate multiple TxQ resource in netdev
>>>>>> - Implement bnad_tx_select_queue() which enables the correct
>>>>> selection of
>>>>>> TxQ Id (and tcb). This function is called either by the kernel
>> to
>>>>> channel
>>>>>> packets to the right TxQ
>>>>>> - bnad_tx_select_queue() returns priority, while only a few
>> packets
>>>>> during
>>>>>> transition could have wrong priority, all will be associated
>> with a
>>>>> valid
>>>>>> non-NULL tcb.
>>>>>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>>>>> packet
>>>>>> inspection and retrieval of tcb corresponding to the iSCSI
>>>>> priority.
>>>>>> - Construction of priority indirection table to be used by bnad to
>>>>> direct
>>>>>> packets into TxQs
>>>>> [...]
>>>>>
>>>>> You probably should implement TX priority classes through the
>>>>> ndo_setup_tc operation, not ndo_select_queue.
>>>>
>>>> The reason we went with ndo_select_queue is due to the need for
>> mapping
>>>> iSCSI packets (TCP port 3260) to a priority derived from DCB
>> configuration.
>>>> Here the iSCSI packets may not have any tc defined in the packet
>> header.
>>>
>>> There is an skb priority, which is derived from the socket priority
>>> option (SO_PRIORITY). If you implement ndo_setup_tc then the
>> networking
>>> core will take care of mapping the skb priority onto a different queue
>>> (or range of queues).
>>>
>>> I don't know whether the socket priority option is easily configurable
>>> for the existing iSCSI implementations. But looking at port numbers
>>> really doesn't seem like the right way to do this.
>>>
>>> Ben.
>>>
>>
>> At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for
>> events.
>> These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To
>> support
>> this in your driver you need to call dcb_setapp() or dcb_ieee_setapp()
>> to
>> add the application data and follow this with the appropriate notify
>> call.
>> Then assuming you do the necessary tc setup work the stack will handle
>> the
>> mapping of priority to queues.
>
> This is how iSCSI over DCB feature is expected to works in BNA driver:-
> FW running in the BNA adapter implements the DCB protocol. It learns the
> iSCSI priority from the switch through iSCSI TLV exchange. BNA driver
> extracts the iSCSI priority from the FW that needs to be used for iSCSI
> packets.
Up to here this is fine. What I was suggesting was to then use the
dcb_setapp() routines to program the iSCSI TLV and generate an event
so any user space applications listening to DCB events could handle
this. It would also be nice if your driver notified user space of
any PG or PFC changes as well. Then management agents (lldpad) could
use the DCB attributes to make policy decisions.
> For every outgoing packet, BNA driver does a TCP header
> inspection to classify iSCSI packet and attach right 802.1q priority &
> send it on the correct TX queue.
>
> This is expected to work with iSCSI applications that do not configure the
> priority with SO_PRIORITY - here the iSCSI priority configuration actually
> comes from the switch to the adapter.
>
Although this works I don't think it is optimal for a few reason. Your
L2 driver is inspecting TCP frames which is bad layering IMHO. The
iSCSI port number is hard coded into the driver so it will only work
with the well known port number. Also it adds more driver specific
behavior into select_queue() where I think the trend is to try to
use select_queue() less not more.
To address iSCSI applications that do not configure the priority
we could either work on adding the DCB hooks needed in those
applications. Or look at adding a hook in the qdisc layer to
to do what your select_queue() hook does here. I started prototyping
this awhile ago but this requires running the packet classifiers
and associated actions before picking a queue assuming you want
to use mq or mqprio. I hope to get back to this soon I have some
more details to flush out wrt this and need to run it by some other
folks to make sure its a sane idea.
> The goal of this iSCSI priority is:
> a) adapter applies prioritized scheduling for packets in its egress - to
> guarantee minimum bandwidth as per ETS
> b) packets are tagged with right priority so that switch can also identify
> and guarantee BW on its egress.
Correct. This is the same for other drivers that support DCB and
use tc_setup as Ben suggested. See the bnx2x driver for an example
that also uses a FW based LLDP engine and does this.
>
> Hope this explains.
I think the one valid item is the unsupported applications but
hopefully that can be addressed. Thanks for the details.
John.
>
> Thanks,
> Rasesh
^ 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