* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: chetan loke @ 2012-07-31 18:02 UTC (permalink / raw)
To: Jon Mason; +Cc: Bjorn Helgaas, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <20120731172709.GB14080@jonmason-lab>
On Tue, Jul 31, 2012 at 1:27 PM, Jon Mason <jon.mason@intel.com> wrote:
>
> I don't see the benefit of having the driver in staging. Any vendors
> who would notice the ntb driver in staging would be sitting on these
> mailing lists and hopefully have planety of comments on the design.
> Stashing the driver in staging while waiting for these comments (which
> may never come) doesn't seem the best course of action.
>
I thought that since others are talking about it then may be there is
some WIP code for foo-NTB. Seems like that's not the case. So no need
to stage.
Correct me if I'm wrong but wouldn't apps just open a socket and route
data via ntb_vir_eth_dev? So I don't see an ABI breakage issue and
hence nothing would prevent us from changing the kernel parts(for
accommodating some foo-NTB part) in future.
It may not be a bad idea to prefix intel-specific(if any)
ntb_structs/variables/logic with the 'intc'(Intel ticker or pick your
string) keyword.
Chetan Loke
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: folkert @ 2012-07-31 17:58 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: linux-hams, Linux Netdev List
In-Reply-To: <5017F96B.1060701@free.fr>
> Here is a complementary observation.
> Trying to remove rose module with rmmod rose did not create any
> kernel panic.
A while ago I wrote a script that at random removed and inserted modules
into the system and that gave surprising results: not only crashing
system, also corrupt filesystems etc. Filed a bug-report and I was told
that removing a module might work but there's no guarantee.
Folkert van Heusden
--
Feeling generous? -> http://www.vanheusden.com/wishlist.php
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: folkert @ 2012-07-31 17:56 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: linux-hams, Linux Netdev List
In-Reply-To: <5017E786.5000102@free.fr>
> I observe systematically a kernel panic when I try to shutdown rose0
> device using ifconfig rose0 down
That's funny: I always get a kernel panic(!) when doing an ifconfig
rose0 up!
Folkert van Heusden
--
Nagios user? Check out CoffeeSaint - the versatile Nagios status
viewer! http://www.vanheusden.com/java/CoffeeSaint/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* inquiry
From: roboth roli company @ 2012-07-31 9:31 UTC (permalink / raw)
i am robothroli, Purchase manager from roli Merchant Ltd. We are
Import/export Company based in taiwan. We are interested in purchasing
your product and I would like to make an inquiry. Please inform me on:
Sample availability and price
Minimum order quantity
FOB Prices
Sincerely
Purchase Manager
robothroli
^ permalink raw reply
* Re: [PATCH 0/7] Deconstruct struct fib_result
From: Alexander Duyck @ 2012-07-31 17:27 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120727.211814.1628871775065221675.davem@davemloft.net>
On Fri, Jul 27, 2012 at 9:18 PM, David Miller <davem@davemloft.net> wrote:
>
> This patch set tries to move towards reducing struct fib_result down
> to it's absolute minimum.
>
> The eventual idea is to make it so that fib_lookup() simply
> returns a "struct fib_nh *" and pointer encoded errnos, instead
> of writing into a complicated structure as the return value on
> the stack as is done now.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
I tested these patches most of yesterday and I haven't seen any
issues. Then again I haven't seen much of an improvement either.
Tested-by: Alexander Duyck <alexander.h.duyck@intel.com>
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-07-31 17:27 UTC (permalink / raw)
To: chetan loke; +Cc: Bjorn Helgaas, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAAsGZS5kOyQ5FQ7Jg3HxOmmPNYS+F6XcB-_3tm=rcgDV7wAvRQ@mail.gmail.com>
On Tue, Jul 31, 2012 at 12:02:20PM -0400, chetan loke wrote:
> On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
> >>
> >> I've tried to make it all generic enough that non-Intel NTBs should plug in with
> >> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> >> redesign of ntb_hw.c might be necessary. But from what I've seen of other
> >> designs on the internet, they appear to be extremely similar. The transport and
> >> client drivers were written with the hardware abstracted away as much as
> >> possible to prevent the need to modify it for different hardware. If there is
> >> anything which is Intel hardware specific, I'd be happy to change it to make it
> >> more generic.
> >
> > That makes sense from a technical point of view, but I think it's
> > going to cause maintenance issues. For example, assume PLX NTB
> > support is added. Will PLX be happy about having to convince you to
> > accept changes? Will Intel be happy about having to release a new
>
> Do you mean convince Intel? Well, if we think of ntb as the class
> driver then the onus is on the community to vet the changes and NOT
> intel.
> And since this is the first NTB part for which the support is
> introduced the class driver design could be a moving target. As
> someone else mentioned, the async/sync tx-dma is another hook that
> could change the class driver's design.
>
>
> > driver for their hardware just to incorporate a PLX bug fix? Will
> > users of PLX hardware accept a new driver release that only benefits
> > Intel users?
>
> May be till the class driver is stable, the client(intel/PLX) drivers
> might have to be modified. This is a cue for other vendors to
> chime-in and review this design?
> Just thinking if this could sit in staging for some time(so that
> others get a chance to review/suggest changes as well) and then get
> promoted out of staging.
I don't see the benefit of having the driver in staging. Any vendors
who would notice the ntb driver in staging would be sitting on these
mailing lists and hopefully have planety of comments on the design.
Stashing the driver in staging while waiting for these comments (which
may never come) doesn't seem the best course of action.
Thanks,
Jon
>
> Chetan Loke
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-07-31 17:10 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAErSpo6gjMf4C3RMn5YLNg5JtJ8CjHvTw1iqsKPa6YuRqPe90g@mail.gmail.com>
On Tue, Jul 31, 2012 at 07:45:29AM -0600, Bjorn Helgaas wrote:
> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
> > On Mon, Jul 30, 2012 at 10:50:13AM -0600, Bjorn Helgaas wrote:
> >> On Sun, Jul 29, 2012 at 6:26 PM, Jon Mason <jon.mason@intel.com> wrote:
> >> > A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
> >> > connecting 2 systems, providing electrical isolation between the two subsystems.
> >> > A non-transparent bridge is functionally similar to a transparent bridge except
> >> > that both sides of the bridge have their own independent address domains. The
> >> > host on one side of the bridge will not have the visibility of the complete
> >> > memory or I/O space on the other side of the bridge. To communicate across the
> >> > non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
> >> > the local system. Writes to these apertures are mirrored to memory on the
> >> > remote system. Communications can also occur through the use of doorbell
> >> > registers that initiate interrupts to the alternate domain, and scratch-pad
> >> > registers accessible from both sides.
> >> >
> >> > The NTB device driver is needed to configure these memory windows, doorbell, and
> >> > scratch-pad registers as well as use them in such a way as they can be turned
> >> > into a viable communication channel to the remote system. ntb_hw.[ch]
> >> > determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
> >> > the underlying hardware to provide access and a common interface to the doorbell
> >> > registers, scratch pads, and memory windows. These hardware interfaces are
> >> > exported so that other, non-mainlined kernel drivers can access these.
> >> > ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
> >> > communication channel(s) and provide a reliable way of transferring data from
> >> > one side to the other, which it then exports so that "client" drivers can access
> >> > them. These client drivers are used to provide a standard kernel interface
> >> > (i.e., Ethernet device) to NTB, such that Linux can transfer data from one
> >> > system to the other in a standard way.
> >> >
> >> > Signed-off-by: Jon Mason <jon.mason@intel.com>
> >> > ---
> >> > MAINTAINERS | 6 +
> >> > drivers/Kconfig | 2 +
> >> > drivers/Makefile | 1 +
> >> > drivers/ntb/Kconfig | 13 +
> >> > drivers/ntb/Makefile | 3 +
> >> > drivers/ntb/ntb_hw.c | 1178 ++++++++++++++++++++++++++++++++++++
> >> > drivers/ntb/ntb_hw.h | 206 +++++++
> >> > drivers/ntb/ntb_regs.h | 150 +++++
> >> > drivers/ntb/ntb_transport.c | 1387 +++++++++++++++++++++++++++++++++++++++++++
> >> > include/linux/ntb.h | 92 +++
> >>
> >> Where will drivers for non-Intel NTBs fit in this hierarchy? It seems
> >> a bit presumptuous to claim the generic "ntb" names just for Intel
> >> devices.
> >
> > I've tried to make it all generic enough that non-Intel NTBs should plug in with
> > minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> > redesign of ntb_hw.c might be necessary. But from what I've seen of other
> > designs on the internet, they appear to be extremely similar. The transport and
> > client drivers were written with the hardware abstracted away as much as
> > possible to prevent the need to modify it for different hardware. If there is
> > anything which is Intel hardware specific, I'd be happy to change it to make it
> > more generic.
>
> That makes sense from a technical point of view, but I think it's
> going to cause maintenance issues. For example, assume PLX NTB
> support is added. Will PLX be happy about having to convince you to
> accept changes? Will Intel be happy about having to release a new
> driver for their hardware just to incorporate a PLX bug fix? Will
> users of PLX hardware accept a new driver release that only benefits
> Intel users?
Firstly, I don't believe this is an issue. The amount of hardware
specific code is small (<150 loc), and the design of the PLX hardware
appears to be the same as Intel (from what I've read on the internet).
Assuming Intel is me, I am always happy to do whatever I can to help
PLX or any other NTB vendor. I am willing to make internal releases
(which I am assuming is the issue you are referring to) for any change
to the driver.
If necessary, refactoring the driver shouldn't be a significant issue.
However, I would prefer to do it if/when another NTB driver wants to
be added. PLX (and those who are using their NTB hardware) hasn't
pushed an NTB driver yet, and may never (as their design docs on the
web are from '05). Why complicate the driver for them if they never
come?
Thanks,
Jon
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Bjorn Helgaas @ 2012-07-31 17:03 UTC (permalink / raw)
To: chetan loke; +Cc: Jon Mason, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAAsGZS5kOyQ5FQ7Jg3HxOmmPNYS+F6XcB-_3tm=rcgDV7wAvRQ@mail.gmail.com>
On Tue, Jul 31, 2012 at 10:02 AM, chetan loke <loke.chetan@gmail.com> wrote:
> On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
>>>
>>> I've tried to make it all generic enough that non-Intel NTBs should plug in with
>>> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
>>> redesign of ntb_hw.c might be necessary. But from what I've seen of other
>>> designs on the internet, they appear to be extremely similar. The transport and
>>> client drivers were written with the hardware abstracted away as much as
>>> possible to prevent the need to modify it for different hardware. If there is
>>> anything which is Intel hardware specific, I'd be happy to change it to make it
>>> more generic.
>>
>> That makes sense from a technical point of view, but I think it's
>> going to cause maintenance issues. For example, assume PLX NTB
>> support is added. Will PLX be happy about having to convince you to
>> accept changes? Will Intel be happy about having to release a new
>
> Do you mean convince Intel? Well, if we think of ntb as the class
> driver then the onus is on the community to vet the changes and NOT
> intel.
No, I said convince "you," meaning *Jon*. Intel doesn't apply
patches. "The community" doesn't apply patches. Jon applies patches.
This has nothing to do with the fact that Jon is employed by Intel.
The point is that when you have multiple organizations involved, they
have different goals, markets, customers, and schedules. If one
module contains both Intel-specific and PLX-specific things, that's a
place where these organizational differences may cause issues,
regardless of who is applying the patches.
Obviously it's not a problem now, and maybe it will never be. But I
think there's a possibility. Since I have no direct interest in any
of these devices, I'm only raising that possibility, not trying to
force any particular direction.
^ permalink raw reply
* Re: [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Andrew Lunn @ 2012-07-31 16:46 UTC (permalink / raw)
To: Ian Molton
Cc: linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks, arnd,
netdev
In-Reply-To: <1343749529-17571-4-git-send-email-ian.molton@codethink.co.uk>
On Tue, Jul 31, 2012 at 04:45:26PM +0100, Ian Molton wrote:
> This patch adds basic device tree support to the mv643xx ethernet driver.
>
> It should be enough for most current users of the device, and should allow
> a fairly painless migration once proper support for clk devices is available
> to those platforms.
>
> Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
> ---
> Documentation/devicetree/bindings/net/mv643xx.txt | 75 +++++++++++++
> arch/arm/mach-kirkwood/board-dt.c | 5 +
Hi Ian
Probably the driver change will get upstream by netdev. The rest will
go via the Orion maintainers into arm-soc. So you should probably move
this board-dt.c change into a patch of its own, or make it part of:
csb1724: Enable device tree based mv643xx ethernet support.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH v2 1/6] Initial csb1724 board support (FDT)
From: Andrew Lunn @ 2012-07-31 16:43 UTC (permalink / raw)
To: Ian Molton
Cc: linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks, arnd,
netdev
In-Reply-To: <1343749529-17571-2-git-send-email-ian.molton@codethink.co.uk>
On Tue, Jul 31, 2012 at 04:45:24PM +0100, Ian Molton wrote:
> This patch adds support for the csb1724 SoM.
>
> It includes serial and SATA support.
>
> Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
> ---
> arch/arm/boot/dts/kirkwood-csb1724.dts | 30 ++++++++++++++++
> arch/arm/configs/csb1724_defconfig | 47 +++++++++++++++++++++++++
I'm unlikely to accept csb1724_defconfig. Please keep it for yourself.
If there is anything you want adding to kirkwood_defconfig, please let
me know.
Jason planned to rework kirkwood_defconfig, but he got sidetracked. I
hope we can get to this soon and enable the building of all DT
platforms by default.
Andrew
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-07-31 16:33 UTC (permalink / raw)
To: Jianbin Kang; +Cc: Bjorn Helgaas, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAF8raN6M0_TWyCCzjyXZcFYP=vgFaqQg4hNmNpBxSM+D0C_Bpg@mail.gmail.com>
On Tue, Jul 31, 2012 at 11:35:33AM +0800, Jianbin Kang wrote:
> > I've tried to make it all generic enough that non-Intel NTBs should plug in with
> > minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> > redesign of ntb_hw.c might be necessary. But from what I've seen of other
> > designs on the internet, they appear to be extremely similar. The transport and
> > client drivers were written with the hardware abstracted away as much as
> > possible to prevent the need to modify it for different hardware. If there is
> > anything which is Intel hardware specific, I'd be happy to change it to make it
> > more generic.
> In ntb_process_tx(), ntb uses hard-coding 'memcpy_toio' to copy data
> to remote.
> Is it better to provide a function pointer like 'tx()' and call qp->tx().
> memcpy_toio is a slow operation. Some hardware can setup a dma
> transfer and wait.
>
> IMHO, the best way is to handle tx in async mode. But it requires
> lots of modification.
Actually this is what I'm working on now, using async_tx to replace the
memcpy. I believe the changes shouldn't be that significant.
Is the "hardware that can setup dma" you refer to something that does
not use this interface?
Thanks,
Jon
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: chetan loke @ 2012-07-31 16:14 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <1343607994-32415-2-git-send-email-jon.mason@intel.com>
On Sun, Jul 29, 2012 at 8:26 PM, Jon Mason <jon.mason@intel.com> wrote:
<snip>
> +static void ntb_tx_copy_task(struct ntb_transport_qp *qp,
> + struct ntb_queue_entry *entry,
> + void *offset)
> +{
> + struct ntb_payload_header *hdr = offset;
> +
> + offset += sizeof(struct ntb_payload_header);
> + memcpy_toio(offset, entry->buf, entry->len);
> +
> + hdr->len = entry->len;
> + hdr->ver = qp->tx_pkts;
> +
> + /* Ensure that the data is fully copied out before setting the flag */
> + wmb();
> + hdr->flags = entry->flags | DESC_DONE_FLAG;
> +
> + ntb_ring_sdb(qp->ndev, qp->qp_num);
> +
> + /* The entry length can only be zero if the packet is intended to be a
> + * "link down" or similar. Since no payload is being sent in these
> + * cases, there is nothing to add to the completion queue.
> + */
> + if (entry->len > 0) {
> + qp->tx_bytes += entry->len;
> +
> + /* Add fully transmitted data to completion queue */
> + ntb_list_add_tail(&qp->ntb_tx_comp_q_lock, &entry->entry,
> + &qp->tx_comp_q);
> +
> + if (qp->tx_handler)
> + qp->tx_handler(qp->cb_data, qp);
> + } else
> + ntb_list_add_tail(&qp->ntb_tx_free_q_lock, &entry->entry,
> + &qp->tx_free_q);
> +}
I know you talked about a fixed array. But it's not here yet. So at
all the call-sites, for [r/t]x_free_q , add the 'entry' to the head -
change to ntb_list_add_head here and else where.
Chetan Loke
^ permalink raw reply
* 802.15.4 Issues
From: Alan Ott @ 2012-07-31 16:04 UTC (permalink / raw)
To: netdev, linux-zigbee-devel, Alexander Smirnov, Tony Cheneau
Hello,
I'm trying to follow the directions at linux-wsn[1] and am not having
much luck. Since I don't have the at91sam9g20ek board, I'm trying this
on my desktop PC with an Econotag[2] (using the serial.c driver I pulled
from [3]) and on a BeagleBone with an MRF24J40 (using a driver I made [4]).
I know this sounds like a big mess, and it is, but let me first start by
staying that all this worked with the code in the linux-zigbee repo at
[3]. With the code in that repo I could run the steps at [5] and
communicate between devices using izchat. (Yes, I know that izchat and
the workflow at [5] are not supported in the -next code yet, which is
why I'm using [1])
Currently, I'm trying to follow the steps at [1] to start using the
latest mainline functionality and I'm not having very much success. I'm
using linux-next, which in looking at the log should currently be the
same as net-next with respect to ieee802154 and 6lowpan.
On the destkop PC, there are several issues. The first is that I'm
getting __schedule_bug errors caused by lowpan_header_create() calling
kzalloc(..., GFP_KERNEL) from interrupt context (see [schedule_log]
below). Replacing kzalloc() calls in lowpan_header_create() and in
ieee802154_header_create() with stack arrays (since they were small
static lengths anyway), I'm able to run the commands at [1] without
stack dumps in the log. This is good, I suppose. The issue now is, once
I've set up the lowpan0 device on the Econotag, when I issue a ping, I
don't see its .xmit() function getting called at all
(ieee802154_serial_xmit() in this case).
I can certainly investigate further, but before doing so, I'd like to
know if what I'm doing, the way I'm doing it, is even _expected_ to
work, or if there's something fundamental that I'm missing.
Also, the instructions at [1] say:
"no platform data merged to the mainline, please apply the last patch
from wpan series manually"
Those instructions[1] were updated July 4, which is before the most
recent 802.15.4 related commits made it into -next. Is that sentence
still valid? If so, where is this wpan series of which it speaks? I'm
assuming platform data may mean for the at91sam9g20ek and that it
doesn't affect me since I'm not using that hardware. Please correct me
if I'm wrong.
Also, interestingly, on my embedded configuration (Beagle Bone +
MRF24J40), ping6 _will_ cause packets to get sent. The kernel I have on
that system is mainline (linux.git) still, and I haven't moved it to
-next yet because of the issues on the desktop PC.
Like I said, I feel like there's something fundamental I'm doing wrong.
Please let me know if you see it.
Alan.
[1] http://code.google.com/p/linux-wsn/wiki/Mainline
[2] http://www.redwirellc.com/store/node/1
[3]
http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=summary
[4] http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1135
[5] http://sourceforge.net/apps/trac/linux-zigbee/wiki/GettingStarted-0.2
[schedule_log]
[ 87.605763] Call Trace:
[ 87.605764] <IRQ> [<ffffffff81084992>] __schedule_bug+0x52/0x60
[ 87.605772] [<ffffffff815e303d>] __schedule+0x6cd/0x7c0
[ 87.605774] [<ffffffff8108875a>] __cond_resched+0x2a/0x40
[ 87.605776] [<ffffffff815e31c0>] _cond_resched+0x30/0x40
[ 87.605779] [<ffffffff81159740>] __kmalloc+0x60/0x170
[ 87.605781] [<ffffffffa02fe28f>] ? kzalloc+0xf/0x20 [6lowpan]
[ 87.605783] [<ffffffffa02fe28f>] kzalloc+0xf/0x20 [6lowpan]
[ 87.605785] [<ffffffffa02fe50e>] lowpan_header_create+0x7e/0x570
[6lowpan]
[ 87.605788] [<ffffffff814de84b>] ? __kmalloc_reserve+0x3b/0xa0
[ 87.605790] [<ffffffff811597d5>] ? __kmalloc+0xf5/0x170
[ 87.605792] [<ffffffff814f711d>] neigh_connected_output+0xad/0x110
[ 87.605795] [<ffffffff8158438d>] ip6_finish_output2+0xfd/0x310
[ 87.605797] [<ffffffff8159041b>] ? rt6_bind_peer+0x4b/0x90
[ 87.605799] [<ffffffff81584638>] ip6_finish_output+0x98/0xc0
[ 87.605801] [<ffffffff815846d8>] ip6_output+0x78/0xb0
[ 87.605803] [<ffffffff8159843e>] ndisc_send_skb+0x1be/0x1f0
[ 87.605805] [<ffffffff815984d1>] __ndisc_send+0x61/0x80
[ 87.605807] [<ffffffff81598d89>] ndisc_send_rs+0x39/0x40
[ 87.605809] [<ffffffff81589df3>] ? ipv6_ifa_notify+0x43/0x50
[ 87.605810] [<ffffffff81589ea0>] addrconf_dad_completed+0xa0/0xf0
[ 87.605812] [<ffffffff8158a08f>] addrconf_dad_timer+0x19f/0x1c0
[ 87.605814] [<ffffffff81064338>] run_timer_softirq+0x178/0x3a0
[ 87.605816] [<ffffffff81589ef0>] ? addrconf_dad_completed+0xf0/0xf0
[ 87.605818] [<ffffffff8101a639>] ? read_tsc+0x9/0x20
[ 87.605819] [<ffffffff8105bfff>] __do_softirq+0xcf/0x250
[ 87.605822] [<ffffffff810a6b34>] ? clockevents_program_event+0x74/0xf0
[ 87.605824] [<ffffffff8107be9e>] ? hrtimer_interrupt+0x13e/0x240
[ 87.605826] [<ffffffff815ed5bc>] call_softirq+0x1c/0x30
[ 87.605829] [<ffffffff810152d5>] do_softirq+0x65/0xa0
[ 87.605830] [<ffffffff8105bded>] irq_exit+0xbd/0xe0
[ 87.605832] [<ffffffff815edefe>] smp_apic_timer_interrupt+0x6e/0x99
[ 87.605833] [<ffffffff815ececa>] apic_timer_interrupt+0x6a/0x70
[ 87.605834] <EOI> [<ffffffff81041436>] ? native_safe_halt+0x6/0x10
[ 87.605838] [<ffffffff8101c54d>] default_idle+0x5d/0x1b0
[ 87.605840] [<ffffffff8101bb98>] cpu_idle+0xd8/0x120
[ 87.605842] [<ffffffff815dcc1e>] start_secondary+0x1cf/0x1d6
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: chetan loke @ 2012-07-31 16:02 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Jon Mason, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAErSpo6gjMf4C3RMn5YLNg5JtJ8CjHvTw1iqsKPa6YuRqPe90g@mail.gmail.com>
On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
>>
>> I've tried to make it all generic enough that non-Intel NTBs should plug in with
>> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
>> redesign of ntb_hw.c might be necessary. But from what I've seen of other
>> designs on the internet, they appear to be extremely similar. The transport and
>> client drivers were written with the hardware abstracted away as much as
>> possible to prevent the need to modify it for different hardware. If there is
>> anything which is Intel hardware specific, I'd be happy to change it to make it
>> more generic.
>
> That makes sense from a technical point of view, but I think it's
> going to cause maintenance issues. For example, assume PLX NTB
> support is added. Will PLX be happy about having to convince you to
> accept changes? Will Intel be happy about having to release a new
Do you mean convince Intel? Well, if we think of ntb as the class
driver then the onus is on the community to vet the changes and NOT
intel.
And since this is the first NTB part for which the support is
introduced the class driver design could be a moving target. As
someone else mentioned, the async/sync tx-dma is another hook that
could change the class driver's design.
> driver for their hardware just to incorporate a PLX bug fix? Will
> users of PLX hardware accept a new driver release that only benefits
> Intel users?
May be till the class driver is stable, the client(intel/PLX) drivers
might have to be modified. This is a cue for other vendors to
chime-in and review this design?
Just thinking if this could sit in staging for some time(so that
others get a chance to review/suggest changes as well) and then get
promoted out of staging.
Chetan Loke
^ permalink raw reply
* [PATCH v2 6/6] DT: Convert all kirkwood boards with mv643xx that use DT
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch converts all present DT capable kirkwood board configurations
to use DT to configure the mv643xx ethernet controller.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 9 +++++++++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 8 ++++++++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 10 ++++++++++
arch/arm/boot/dts/kirkwood-iconnect.dts | 10 ++++++++++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/kirkwood-ts219-6281.dts | 8 +++++++-
arch/arm/boot/dts/kirkwood-ts219-6282.dts | 8 +++++++-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 3 +++
arch/arm/mach-kirkwood/board-dnskw.c | 7 +------
arch/arm/mach-kirkwood/board-dreamplug.c | 13 ++-----------
arch/arm/mach-kirkwood/board-goflexnet.c | 7 +------
arch/arm/mach-kirkwood/board-ib62x0.c | 7 +------
arch/arm/mach-kirkwood/board-iconnect.c | 7 +------
arch/arm/mach-kirkwood/board-lsxl.c | 13 ++-----------
arch/arm/mach-kirkwood/board-ts219.c | 10 +---------
16 files changed, 98 insertions(+), 57 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 7408655..214fe0b 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -65,5 +65,14 @@
reg = <0x7b00000 0x500000>;
};
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 26e281f..c27ed1c 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -53,6 +53,24 @@
status = "okay";
nr-ports = <1>;
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ smi1: mdio@76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <1>;
+ status = "ok";
+ };
};
gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 7c8238f..f03dbd0 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -50,6 +50,14 @@
nr-ports = <2>;
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
};
gpio-leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 66794ed..8c462a1 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -45,6 +45,16 @@
};
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
+
};
gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 52d9470..9fc82be 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -30,6 +30,16 @@
clock-frequency = <200000000>;
status = "ok";
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <b>;
+ status = "ok";
+ };
+
};
gpio-leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 8ac51c0..2f47661 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -40,6 +40,23 @@
};
};
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ smi1: mdio@76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <8>;
+ status = "ok";
+ };
};
gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index ccbf327..4ca49b5 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -3,6 +3,12 @@
/include/ "kirkwood-ts219.dtsi"
/ {
+ ocp@f1000000 {
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
+ };
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -18,4 +24,4 @@
gpios = <&gpio0 16 1>;
};
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index fbe9932..40f3c61 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -3,6 +3,12 @@
/include/ "kirkwood-ts219.dtsi"
/ {
+ ocp@f1000000 {
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+ };
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -18,4 +24,4 @@
gpios = <&gpio1 5 1>;
};
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 64ea27c..06caf41 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -74,5 +74,8 @@
status = "okay";
nr-ports = <2>;
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index 4ab3506..4d8216b 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -15,7 +15,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/gpio.h>
#include <linux/input.h>
@@ -29,10 +28,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data dnskw_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int dnskw_mpp_config[] __initdata = {
MPP13_UART1_TXD, /* Custom ... */
MPP14_UART1_RXD, /* ... Controller (DNS-320 only) */
@@ -112,7 +107,7 @@ void __init dnskw_init(void)
kirkwood_mpp_conf(dnskw_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&dnskw_ge00_data);
+ kirkwood_ge00_init(NULL);
platform_device_register(&dnskw_fan_device);
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
index aeb234d..b97a112 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -15,7 +15,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
@@ -34,14 +33,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(1),
-};
-
static struct mvsdio_platform_data dreamplug_mvsdio_data = {
/* unfortunately the CD signal has not been connected */
};
@@ -65,7 +56,7 @@ void __init dreamplug_init(void)
kirkwood_mpp_conf(dreamplug_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&dreamplug_ge00_data);
- kirkwood_ge01_init(&dreamplug_ge01_data);
+ kirkwood_ge00_init(NULL);
+ kirkwood_ge01_init(NULL);
kirkwood_sdio_init(&dreamplug_mvsdio_data);
}
diff --git a/arch/arm/mach-kirkwood/board-goflexnet.c b/arch/arm/mach-kirkwood/board-goflexnet.c
index 413e2c8..be7437d 100644
--- a/arch/arm/mach-kirkwood/board-goflexnet.c
+++ b/arch/arm/mach-kirkwood/board-goflexnet.c
@@ -20,7 +20,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
@@ -36,10 +35,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data goflexnet_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
static unsigned int goflexnet_mpp_config[] __initdata = {
MPP29_GPIO, /* USB Power Enable */
MPP47_GPIO, /* LED Orange */
@@ -67,5 +62,5 @@ void __init goflexnet_init(void)
pr_err("can't setup GPIO 29 (USB Power Enable)\n");
kirkwood_ehci_init();
- kirkwood_ge00_init(&goflexnet_ge00_data);
+ kirkwood_ge00_init(NULL);
}
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
index cfc47f8..0a29183 100644
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ b/arch/arm/mach-kirkwood/board-ib62x0.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/input.h>
#include <asm/mach-types.h>
@@ -27,10 +26,6 @@
#define IB62X0_GPIO_POWER_OFF 24
-static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int ib62x0_mpp_config[] __initdata = {
MPP0_NF_IO2,
MPP1_NF_IO3,
@@ -62,7 +57,7 @@ void __init ib62x0_init(void)
kirkwood_mpp_conf(ib62x0_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&ib62x0_ge00_data);
+ kirkwood_ge00_init(NULL);
if (gpio_request(IB62X0_GPIO_POWER_OFF, "ib62x0:power:off") == 0 &&
gpio_direction_output(IB62X0_GPIO_POWER_OFF, 0) == 0)
pm_power_off = ib62x0_power_off;
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
index d7a9198..220f0d4 100644
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ b/arch/arm/mach-kirkwood/board-iconnect.c
@@ -17,7 +17,6 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/mtd/partitions.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/input.h>
#include <linux/gpio_keys.h>
@@ -26,10 +25,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data iconnect_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(11),
-};
-
static unsigned int iconnect_mpp_config[] __initdata = {
MPP12_GPIO,
MPP35_GPIO,
@@ -92,7 +87,7 @@ void __init iconnect_init(void)
kirkwood_nand_init(ARRAY_AND_SIZE(iconnect_nand_parts), 25);
kirkwood_ehci_init();
- kirkwood_ge00_init(&iconnect_ge00_data);
+ kirkwood_ge00_init(NULL);
platform_device_register(&iconnect_button_device);
}
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
index 83d8975..60331d1 100644
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ b/arch/arm/mach-kirkwood/board-lsxl.c
@@ -18,7 +18,6 @@
#include <linux/ata_platform.h>
#include <linux/spi/flash.h>
#include <linux/spi/spi.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/gpio-fan.h>
#include <linux/input.h>
@@ -28,14 +27,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data lsxl_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data lsxl_ge01_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int lsxl_mpp_config[] __initdata = {
MPP10_GPO, /* HDD Power Enable */
MPP11_GPIO, /* USB Vbus Enable */
@@ -126,8 +117,8 @@ void __init lsxl_init(void)
gpio_set_value(LSXL_GPIO_HDD_POWER, 1);
kirkwood_ehci_init();
- kirkwood_ge00_init(&lsxl_ge00_data);
- kirkwood_ge01_init(&lsxl_ge01_data);
+ kirkwood_ge00_init(NULL);
+ kirkwood_ge01_init(NULL);
platform_device_register(&lsxl_fan_device);
/* register power-off method */
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index 1750e68..7e7fe6c 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -18,7 +18,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
#include <linux/ata_platform.h>
#include <linux/gpio_keys.h>
#include <linux/input.h>
@@ -29,10 +28,6 @@
#include "mpp.h"
#include "tsx1x-common.h"
-static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int qnap_ts219_mpp_config[] __initdata = {
MPP0_SPI_SCn,
MPP1_SPI_MOSI,
@@ -62,10 +57,7 @@ void __init qnap_dt_ts219_init(void)
kirkwood_mpp_conf(qnap_ts219_mpp_config);
kirkwood_pcie_id(&dev, &rev);
- if (dev == MV88F6282_DEV_ID)
- qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-
- kirkwood_ge00_init(&qnap_ts219_ge00_data);
+ kirkwood_ge00_init(NULL);
kirkwood_ehci_init();
pm_power_off = qnap_tsx1x_power_off;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/6] mv643xx.c: Remove magic numbers.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
replace magic number with RX_CSUM_WITH_HEADER.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 4fbba57..92497eb 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -86,6 +86,7 @@ static char mv643xx_eth_driver_version[] = "1.4";
* port #0, 0x0800 for port #1, and 0x0c00 for port #2.
*/
#define PORT_CONFIG 0x0000
+#define RX_CSUM_WITH_HEADER 0x02000000
#define UNICAST_PROMISCUOUS_MODE 0x00000001
#define PORT_CONFIG_EXT 0x0004
#define MAC_ADDR_LOW 0x0014
@@ -1607,7 +1608,7 @@ mv643xx_eth_set_features(struct net_device *dev, netdev_features_t features)
struct mv643xx_eth_private *mp = netdev_priv(dev);
bool rx_csum = features & NETIF_F_RXCSUM;
- wrlp(mp, PORT_CONFIG, rx_csum ? 0x02000000 : 0x00000000);
+ wrlp(mp, PORT_CONFIG, rx_csum ? RX_CSUM_WITH_HEADER : 0x00000000);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 5/6] csb1724: Enable device tree based mv643xx ethernet support.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch enables mv643xx based ethernet built into the SoM on the
csb1724, via flattened device tree.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/boot/dts/kirkwood-csb1724.dts | 19 ++++++++++++++
arch/arm/boot/dts/kirkwood.dtsi | 33 +++++++++++++++++++++++
arch/arm/configs/csb1724_defconfig | 45 ++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-csb1724.c | 1 +
4 files changed, 98 insertions(+)
diff --git a/arch/arm/boot/dts/kirkwood-csb1724.dts b/arch/arm/boot/dts/kirkwood-csb1724.dts
index 44dfe9a..f43f8dd 100644
--- a/arch/arm/boot/dts/kirkwood-csb1724.dts
+++ b/arch/arm/boot/dts/kirkwood-csb1724.dts
@@ -25,6 +25,25 @@
nr-ports = <2>;
status = "ok";
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ smi1: mdio@76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <1>;
+ status = "ok";
+ };
+
};
};
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index cef9616..f5f1f92 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -76,6 +76,39 @@
status = "okay";
};
+ smi0: mdio@72000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x72000 0x4000>;
+ interrupts = <46>;
+ tx_csum_limit = <1600>;
+ status = "disabled";
+ };
+
+ egiga0 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x72000 0x4000>;
+ mdio = <&smi0>;
+ interrupts = <11>;
+ status = "disabled";
+ };
+
+ smi1: mdio@76000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x76000 0x4000>;
+ interrupts = <47>;
+ shared_smi = <&smi0>;
+ tx_csum_limit = <1600>;
+ status = "disabled";
+ };
+
+ egiga1 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x76000 0x4000>;
+ mdio = <&smi1>;
+ interrupts = <15>;
+ status = "disabled";
+ };
+
sata@80000 {
compatible = "marvell,orion-sata";
reg = <0x80000 0x5000>;
diff --git a/arch/arm/configs/csb1724_defconfig b/arch/arm/configs/csb1724_defconfig
index 927b269..fbea657 100644
--- a/arch/arm/configs/csb1724_defconfig
+++ b/arch/arm/configs/csb1724_defconfig
@@ -45,3 +45,48 @@ CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_DYNAMIC_DEBUG=y
+CONFIG_NET=y
+CONFIG_INET=y
+CONFIG_NETDEVICES=y
+CONFIG_MV643XX_ETH=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_IPV6=n
+CONFIG_NET_VENDOR_3COM=n
+CONFIG_NET_VENDOR_ADAPTEC=n
+CONFIG_NET_VENDOR_ALTEON=n
+CONFIG_NET_VENDOR_AMD=n
+CONFIG_NET_VENDOR_ATHEROS=n
+CONFIG_NET_VENDOR_BROADCOM=n
+CONFIG_NET_VENDOR_BROCADE=n
+CONFIG_NET_VENDOR_CHELSIO=n
+CONFIG_NET_VENDOR_CIRRUS=n
+CONFIG_NET_VENDOR_CISCO=n
+CONFIG_NET_VENDOR_DEC=n
+CONFIG_NET_VENDOR_HP=n
+CONFIG_NET_VENDOR_DLINK=n
+CONFIG_NET_VENDOR_EMULEX=n
+CONFIG_NET_VENDOR_EXAR=n
+CONFIG_NET_VENDOR_FARADAY=n
+CONFIG_NET_VENDOR_INTEL=n
+CONFIG_NET_VENDOR_MELLANOX=n
+CONFIG_NET_VENDOR_MICREL=n
+CONFIG_NET_VENDOR_MYRI=n
+CONFIG_NET_VENDOR_NATSEMI=n
+CONFIG_NET_VENDOR_NVIDIA=n
+CONFIG_NET_VENDOR_OKI=n
+CONFIG_NET_PACKET_ENGINE=n
+CONFIG_NET_VENDOR_QLOGIC=n
+CONFIG_NET_VENDOR_REALTEK=n
+CONFIG_NET_VENDOR_RDC=n
+CONFIG_NET_VENDOR_SEEQ=n
+CONFIG_NET_VENDOR_SILAN=n
+CONFIG_NET_VENDOR_SIS=n
+CONFIG_NET_VENDOR_SMSC=n
+CONFIG_NET_VENDOR_STMICRO=n
+CONFIG_NET_VENDOR_SUN=n
+CONFIG_NET_VENDOR_TEHUTI=n
+CONFIG_NET_VENDOR_TI=n
+CONFIG_NET_VENDOR_VIA=n
+CONFIG_NET_VENDOR_WIZNET=n
+
diff --git a/arch/arm/mach-kirkwood/board-csb1724.c b/arch/arm/mach-kirkwood/board-csb1724.c
index 979112d..9c58b92 100644
--- a/arch/arm/mach-kirkwood/board-csb1724.c
+++ b/arch/arm/mach-kirkwood/board-csb1724.c
@@ -13,6 +13,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
+#include "common.h"
#include "mpp.h"
static unsigned int csb1724_mpp_config[] __initdata = {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch adds basic device tree support to the mv643xx ethernet driver.
It should be enough for most current users of the device, and should allow
a fairly painless migration once proper support for clk devices is available
to those platforms.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
Documentation/devicetree/bindings/net/mv643xx.txt | 75 +++++++++++++
arch/arm/mach-kirkwood/board-dt.c | 5 +
drivers/net/ethernet/marvell/mv643xx_eth.c | 119 ++++++++++++++++++---
3 files changed, 185 insertions(+), 14 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/mv643xx.txt
diff --git a/Documentation/devicetree/bindings/net/mv643xx.txt b/Documentation/devicetree/bindings/net/mv643xx.txt
new file mode 100644
index 0000000..2727f79
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mv643xx.txt
@@ -0,0 +1,75 @@
+mv643xx related nodes.
+
+marvell,mdio-mv643xx:
+
+Required properties:
+
+ - interrupts : <a> where a is the SMI interrupt number.
+ - reg : the base address and size of the controllers register space.
+
+Optional properties:
+ - shared_smi : on some chips, the second PHY is "shared", meaning it is
+ really accessed via the first SMI controller. It is passed in this
+ way due to the present structure of the driver, which requires the
+ base address for the MAC to be passed in via the SMI controllers
+ platform data.
+ - tx_csum_limit : on some devices, this option is required for proper
+ operation wrt. jumbo frames.
+
+
+Example:
+
+smi0: mdio@72000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x72000 0x4000>;
+ interrupts = <46>;
+ tx_csum_limit = <1600>;
+ status = "disabled";
+};
+
+smi1: mdio@76000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x76000 0x4000>;
+ interrupts = <47>;
+ shared_smi = <&smi0>;
+ tx_csum_limit = <1600>;
+ status = "disabled";
+};
+
+
+
+marvell,mv643xx-eth:
+
+Required properties:
+ - interrupts : the port interrupt number.
+ - mdio : phandle of the smi device as drescribed above
+
+Optional properties:
+ - port_number : the port number on this bus.
+ - phy_addr : the PHY address.
+ - reg : should match the mdio reg this device is attached to.
+ this is a required hack for now due to the way the
+ driver is constructed. This allows the device clock to be
+ kept running so that the MAC is not lost after boot.
+
+
+Example:
+
+egiga0 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x72000 0x4000>;
+ mdio = <&smi0>;
+ port_number = <0>;
+ phy_addr = <0x80>;
+ interrupts = <11>;
+};
+
+egiga1 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x76000 0x4000>;
+ mdio = <&smi1>;
+ port_number = <0>;
+ phy_addr = <0x81>;
+ interrupts = <15>;
+};
+
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 7679f7f..9816b85 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/of.h>
#include <linux/of_platform.h>
+#include <linux/mv643xx_eth.h>
#include <linux/kexec.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -33,6 +34,10 @@ struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("marvell,orion-wdt", 0xf1020300, "orion_wdt", NULL),
OF_DEV_AUXDATA("marvell,orion-sata", 0xf1080000, "sata_mv.0", NULL),
OF_DEV_AUXDATA("marvell,orion-nand", 0xf4000000, "orion_nand", NULL),
+ OF_DEV_AUXDATA("marvell,mv643xx", 0xf1072000, MV643XX_ETH_NAME ".0",
+ NULL),
+ OF_DEV_AUXDATA("marvell,mv643xx", 0xf1076000, MV643XX_ETH_NAME ".1",
+ NULL),
{},
};
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 92497eb..733c69f 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -48,6 +48,9 @@
#include <linux/ethtool.h>
#include <linux/platform_device.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_irq.h>
#include <linux/kernel.h>
#include <linux/spinlock.h>
#include <linux/workqueue.h>
@@ -2601,11 +2604,11 @@ static void infer_hw_params(struct mv643xx_eth_shared_private *msp)
static int mv643xx_eth_shared_probe(struct platform_device *pdev)
{
static int mv643xx_eth_version_printed;
- struct mv643xx_eth_shared_platform_data *pd = pdev->dev.platform_data;
+ struct mv643xx_eth_shared_platform_data *pd;
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
- int ret;
+ int ret, irq = -1;
if (!mv643xx_eth_version_printed++)
pr_notice("MV-643xx 10/100/1000 ethernet driver version %s\n",
@@ -2625,6 +2628,26 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
if (msp->base == NULL)
goto out_free;
+ if (pdev->dev.of_node) {
+ struct device_node *np = NULL;
+
+ /* when all users of this driver use FDT, we can remove this */
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_dbg(&pdev->dev, "Could not allocate platform data\n");
+ goto out_free;
+ }
+
+ of_property_read_u32(pdev->dev.of_node,
+ "tx_csum_limit", &pd->tx_csum_limit);
+
+ np = of_parse_phandle(pdev->dev.of_node, "shared_smi", 0);
+ if (np)
+ pd->shared_smi = of_find_device_by_node(np);
+
+ } else {
+ pd = pdev->dev.platform_data;
+ }
/*
* Set up and register SMI bus.
*/
@@ -2654,15 +2677,22 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
/*
* Check whether the error interrupt is hooked up.
*/
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (res != NULL) {
+ if (pdev->dev.of_node) {
+ irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (res)
+ irq = res->start;
+ }
+
+ if (irq != -1) {
int err;
- err = request_irq(res->start, mv643xx_eth_err_irq,
+ err = request_irq(irq, mv643xx_eth_err_irq,
IRQF_SHARED, "mv643xx_eth", msp);
if (!err) {
writel(ERR_INT_SMI_DONE, msp->base + ERR_INT_MASK);
- msp->err_interrupt = res->start;
+ msp->err_interrupt = irq;
}
}
@@ -2675,6 +2705,10 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
pd->tx_csum_limit : 9 * 1024;
+
+ if (pdev->dev.of_node)
+ kfree(pd); /* If we created a fake pd, free it now */
+
infer_hw_params(msp);
platform_set_drvdata(pdev, msp);
@@ -2708,12 +2742,21 @@ static int mv643xx_eth_shared_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id mv_mdio_dt_ids[] __devinitdata = {
+ { .compatible = "marvell,mdio-mv643xx", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mv_mdio_dt_ids);
+#endif
+
static struct platform_driver mv643xx_eth_shared_driver = {
.probe = mv643xx_eth_shared_probe,
.remove = mv643xx_eth_shared_remove,
.driver = {
.name = MV643XX_ETH_SHARED_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mv_mdio_dt_ids),
},
};
@@ -2873,7 +2916,36 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
struct resource *res;
int err;
- pd = pdev->dev.platform_data;
+ if (pdev->dev.of_node) {
+ struct device_node *np = NULL;
+
+ /* when all users of this driver use FDT, we can remove this */
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_dbg(&pdev->dev, "Could not allocate platform data\n");
+ return -ENOMEM;
+ }
+
+ of_property_read_u32(pdev->dev.of_node,
+ "port_number", &pd->port_number);
+
+ if(!of_property_read_u32(pdev->dev.of_node,
+ "phy_addr", &pd->phy_addr))
+ pd->phy_addr = MV643XX_ETH_PHY_ADDR(pd->phy_addr);
+ else
+ pd->phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT;
+
+ np = of_parse_phandle(pdev->dev.of_node, "mdio", 0);
+ if (np) {
+ pd->shared = of_find_device_by_node(np);
+ } else {
+ kfree(pd);
+ return -ENODEV;
+ }
+ } else {
+ pd = pdev->dev.platform_data;
+ }
+
if (pd == NULL) {
dev_err(&pdev->dev, "no mv643xx_eth_platform_data\n");
return -ENODEV;
@@ -2881,12 +2953,15 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
if (pd->shared == NULL) {
dev_err(&pdev->dev, "no mv643xx_eth_platform_data->shared\n");
- return -ENODEV;
+ err = -ENODEV;
+ goto out_free_pd;
}
dev = alloc_etherdev_mq(sizeof(struct mv643xx_eth_private), 8);
- if (!dev)
- return -ENOMEM;
+ if (!dev) {
+ err = -ENOMEM;
+ goto out_free_pd;
+ }
mp = netdev_priv(dev);
platform_set_drvdata(pdev, mp);
@@ -2923,6 +2998,8 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
init_pscr(mp, pd->speed, pd->duplex);
+ if (pdev->dev.of_node)
+ kfree(pd); /* If we created a fake pd, free it now */
mib_counters_clear(mp);
@@ -2942,10 +3019,13 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
mp->rx_oom.data = (unsigned long)mp;
mp->rx_oom.function = oom_timer_wrapper;
-
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- BUG_ON(!res);
- dev->irq = res->start;
+ if (pdev->dev.of_node) {
+ dev->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ BUG_ON(!res);
+ dev->irq = res->start;
+ }
dev->netdev_ops = &mv643xx_eth_netdev_ops;
@@ -2991,6 +3071,8 @@ out:
}
#endif
free_netdev(dev);
+out_free_pd:
+ kfree(pd);
return err;
}
@@ -3030,6 +3112,14 @@ static void mv643xx_eth_shutdown(struct platform_device *pdev)
port_reset(mp);
}
+#ifdef CONFIG_OF
+static struct of_device_id mv_eth_dt_ids[] __devinitdata = {
+ { .compatible = "marvell,mv643xx-eth", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mv_eth_dt_ids);
+#endif
+
static struct platform_driver mv643xx_eth_driver = {
.probe = mv643xx_eth_probe,
.remove = mv643xx_eth_remove,
@@ -3037,6 +3127,7 @@ static struct platform_driver mv643xx_eth_driver = {
.driver = {
.name = MV643XX_ETH_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mv_eth_dt_ids),
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/6] Initial csb1724 board support (FDT)
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch adds support for the csb1724 SoM.
It includes serial and SATA support.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/boot/dts/kirkwood-csb1724.dts | 30 ++++++++++++++++
arch/arm/configs/csb1724_defconfig | 47 +++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 7 ++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/Makefile.boot | 1 +
arch/arm/mach-kirkwood/board-csb1724.c | 59 ++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-dt.c | 4 +++
arch/arm/mach-kirkwood/common.h | 6 ++++
8 files changed, 155 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-csb1724.dts
create mode 100644 arch/arm/configs/csb1724_defconfig
create mode 100644 arch/arm/mach-kirkwood/board-csb1724.c
diff --git a/arch/arm/boot/dts/kirkwood-csb1724.dts b/arch/arm/boot/dts/kirkwood-csb1724.dts
new file mode 100644
index 0000000..44dfe9a
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-csb1724.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood.dtsi"
+
+/ {
+ model = "Cogent CSB1724-88F-628X SoM";
+ compatible = "cogent,csb1724", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk";
+ };
+
+ ocp@f1000000 {
+ serial@12000 {
+ clock-frequency = <200000000>;
+ status = "ok";
+ };
+
+ sata@80000 {
+ nr-ports = <2>;
+ status = "ok";
+ };
+ };
+
+};
diff --git a/arch/arm/configs/csb1724_defconfig b/arch/arm/configs/csb1724_defconfig
new file mode 100644
index 0000000..927b269
--- /dev/null
+++ b/arch/arm/configs/csb1724_defconfig
@@ -0,0 +1,47 @@
+CONFIG_ARCH_KIRKWOOD=y
+CONFIG_ARCH_KIRKWOOD_DT=y
+CONFIG_MACH_CSB1724_DT=y
+CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
+CONFIG_EXPERIMENTAL=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_VFP=y
+CONFIG_AEABI=y
+CONFIG_OABI_COMPAT=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_ATA=y
+CONFIG_ATA_SFF=y
+CONFIG_ATA_BMDMA=y
+CONFIG_SATA_MV=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_ISO8859_2=y
+CONFIG_NLS_UTF8=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
+CONFIG_TIMER_STATS=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_USER=y
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_DTC=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_EXT4_FS=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_TICK_ONESHOT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
+CONFIG_DYNAMIC_DEBUG=y
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index ca5c15a..6d51c50 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -109,6 +109,13 @@ config MACH_LSXL_DT
Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
Flattened Device Tree.
+config MACH_CSB1724_DT
+ bool "Cogent CSB1724 SoM (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the
+ Cogent CSB1724 SoM, using Flattened Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 055c85a..665ed63 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o tsx1x-common.o
obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
+obj-$(CONFIG_MACH_CSB1724_DT) += board-csb1724.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot
index 2a576ab..899bc80 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -2,6 +2,7 @@
params_phys-y := 0x00000100
initrd_phys-y := 0x00800000
+dtb-$(CONFIG_MACH_CSB1724_DT) += kirkwood-csb1724.dtb
dtb-$(CONFIG_MACH_DREAMPLUG_DT) += kirkwood-dreamplug.dtb
dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns320.dtb
dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns325.dtb
diff --git a/arch/arm/mach-kirkwood/board-csb1724.c b/arch/arm/mach-kirkwood/board-csb1724.c
new file mode 100644
index 0000000..979112d
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-csb1724.c
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2012 (C), Ian Molton <ian.molton@codethink.co.uk>
+ *
+ * arch/arm/mach-kirkwood/board-csb1724.c
+ *
+ * Cogent csb1724 Board Init for drivers not converted to
+ * flattened device tree yet.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include "mpp.h"
+
+static unsigned int csb1724_mpp_config[] __initdata = {
+ MPP0_NF_IO2,
+ MPP1_NF_IO3,
+ MPP2_NF_IO4,
+ MPP3_NF_IO5,
+ MPP4_NF_IO6,
+ MPP5_NF_IO7,
+ MPP8_TW0_SDA,
+ MPP9_TW0_SCK,
+ MPP12_SD_CLK,
+ MPP13_SD_CMD,
+ MPP14_SD_D0,
+ MPP15_SD_D1,
+ MPP16_SD_D2,
+ MPP17_SD_D3,
+ MPP18_NF_IO0,
+ MPP19_NF_IO1,
+ MPP20_GE1_TXD0,
+ MPP21_GE1_TXD1,
+ MPP22_GE1_TXD2,
+ MPP23_GE1_TXD3,
+ MPP24_GE1_RXD0,
+ MPP25_GE1_RXD1,
+ MPP26_GE1_RXD2,
+ MPP27_GE1_RXD3,
+ MPP30_GE1_RXCTL,
+ MPP31_GE1_RXCLK,
+ MPP32_GE1_TCLKOUT,
+ MPP33_GE1_TXCTL,
+ MPP34_SATA1_ACTn,
+ MPP35_SATA0_ACTn,
+ MPP36_TW1_SDA,
+ MPP37_TW1_SCK,
+};
+
+void __init csb1724_init(void)
+{
+ /*
+ * Basic setup. Needs to be called early.
+ */
+ kirkwood_mpp_conf(csb1724_mpp_config);
+}
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index e4eb450..7679f7f 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -87,6 +87,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("buffalo,lsxl"))
lsxl_init();
+ if (of_machine_is_compatible("cogent,csb1724"))
+ csb1724_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -100,6 +103,7 @@ static const char *kirkwood_dt_board_compat[] = {
"qnap,ts219",
"seagate,goflexnet",
"buffalo,lsxl",
+ "cogent,csb1724",
NULL
};
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 304dd1a..8aab1ae 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -94,6 +94,12 @@ void lsxl_init(void);
static inline void lsxl_init(void) {};
#endif
+#ifdef CONFIG_MACH_CSB1724_DT
+void csb1724_init(void);
+#else
+static inline void csb1724_init(void) {};
+#endif
+
/* early init functions not converted to fdt yet */
char *kirkwood_id(void);
void kirkwood_l2_init(void);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/6] kirkwood: Add a clock setup helper for mv643xx ethernet.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch adds an ethernet setup helper function allowing the mv643xx
clock to be kept enabled so that the MAC address(es) are not lost.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/mach-kirkwood/board-dt.c | 2 ++
arch/arm/mach-kirkwood/common.c | 22 ++++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 3 +++
3 files changed, 27 insertions(+)
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 9816b85..1bcae22 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -97,6 +97,8 @@ static void __init kirkwood_dt_init(void)
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
+
+ kirkwood_eth_clock_fixup();
}
static const char *kirkwood_dt_board_compat[] = {
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index c4b64ad..57b91cf 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -18,6 +18,7 @@
#include <linux/clk-provider.h>
#include <linux/spinlock.h>
#include <linux/mv643xx_i2c.h>
+#include <linux/of.h>
#include <net/dsa.h>
#include <asm/page.h>
#include <asm/timex.h>
@@ -293,6 +294,27 @@ void __init kirkwood_ehci_init(void)
orion_ehci_init(USB_PHYS_BASE, IRQ_KIRKWOOD_USB, EHCI_PHY_NA);
}
+/* Fixup ethernet clocks for DT based kirkwood platforms.
+ * This is required because if the clock is not kept running, the
+ * Interface will forget its MAC address.
+ */
+#ifdef CONFIG_OF
+void __init kirkwood_eth_clock_fixup(void)
+{
+ struct device_node *np;
+
+ np = of_find_node_by_name(NULL, "egiga0");
+ if (np && of_device_is_available(np))
+ clk_prepare_enable(ge0);
+ of_node_put(np);
+
+ np = of_find_node_by_name(NULL, "egiga1");
+ if (np && of_device_is_available(np))
+ clk_prepare_enable(ge1);
+ of_node_put(np);
+
+}
+#endif
/*****************************************************************************
* GE00
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 8aab1ae..7183718 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -36,6 +36,9 @@ void kirkwood_enable_pcie(void);
void kirkwood_pcie_id(u32 *dev, u32 *rev);
void kirkwood_ehci_init(void);
+#ifdef CONFIG_OF
+void kirkwood_eth_clock_fixup(void);
+#endif
void kirkwood_ge00_init(struct mv643xx_eth_platform_data *eth_data);
void kirkwood_ge01_init(struct mv643xx_eth_platform_data *eth_data);
void kirkwood_ge00_switch_init(struct dsa_platform_data *d, int irq);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/6] mv643xx Ethernet DT support and CSB1724 board support.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
Respin of the previous patch. All comments have been addressed.
Addressed:
* Typos
* Docs
* Automatic clock detection / setup
* PHY addresses are not | 0x80 anymore
- which is a horrid way for the driver to be doing things but hey...
* property added to DT bindings for tx_csum_limit
* GFP_ATOMIC allocations demoted to GFP_KERNEL (cpoypaste error)
* devide order in .dts(i) files fixed
Outstanding:
* Should the tx_csum_limit issue be addressed by:
- a new device name
- detecting the host platform
- a property (present solution).
Ian Molton (6):
Initial csb1724 board support (FDT)
mv643xx.c: Remove magic numbers.
mv643xx.c: Add basic device tree support.
kirkwood: Add a clock setup helper for mv643xx ethernet.
csb1724: Enable device tree based mv643xx ethernet support.
DT: Convert all kirkwood boards with mv643xx that use DT
Documentation/devicetree/bindings/net/mv643xx.txt | 75 +++++++++++++
arch/arm/boot/dts/kirkwood-csb1724.dts | 49 +++++++++
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 9 ++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 18 +++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 8 ++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 10 ++
arch/arm/boot/dts/kirkwood-iconnect.dts | 10 ++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 17 +++
arch/arm/boot/dts/kirkwood-ts219-6281.dts | 8 +-
arch/arm/boot/dts/kirkwood-ts219-6282.dts | 8 +-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 3 +
arch/arm/boot/dts/kirkwood.dtsi | 33 ++++++
arch/arm/configs/csb1724_defconfig | 92 ++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 7 ++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/Makefile.boot | 1 +
arch/arm/mach-kirkwood/board-csb1724.c | 60 ++++++++++
arch/arm/mach-kirkwood/board-dnskw.c | 7 +-
arch/arm/mach-kirkwood/board-dreamplug.c | 13 +--
arch/arm/mach-kirkwood/board-dt.c | 11 ++
arch/arm/mach-kirkwood/board-goflexnet.c | 7 +-
arch/arm/mach-kirkwood/board-ib62x0.c | 7 +-
arch/arm/mach-kirkwood/board-iconnect.c | 7 +-
arch/arm/mach-kirkwood/board-lsxl.c | 13 +--
arch/arm/mach-kirkwood/board-ts219.c | 10 +-
arch/arm/mach-kirkwood/common.c | 22 ++++
arch/arm/mach-kirkwood/common.h | 9 ++
drivers/net/ethernet/marvell/mv643xx_eth.c | 122 ++++++++++++++++++---
28 files changed, 565 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/mv643xx.txt
create mode 100644 arch/arm/boot/dts/kirkwood-csb1724.dts
create mode 100644 arch/arm/configs/csb1724_defconfig
create mode 100644 arch/arm/mach-kirkwood/board-csb1724.c
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH] mac80211: use eth_broadcast_addr
From: Joe Perches @ 2012-07-31 15:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg, netdev
In-Reply-To: <1343744471-5910-1-git-send-email-johannes@sipsolutions.net>
On Tue, 2012-07-31 at 16:21 +0200, Johannes Berg wrote:
> Instead of memset().
Maybe just do them all?
git ls-files net drivers/net |
xargs perl -p -i -e 's/\bmemset\s*\(\s*([^,]+),\s*(?i:0xff|255)\s*\,\s*(ETH_ALEN|6)\s*\)/eth_broadcast_addr\(\1\)/g'
^ permalink raw reply
* [PATCH v2] ipv4: percpu nh_rth_output cache
From: Eric Dumazet @ 2012-07-31 15:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Alexander Duyck
From: Eric Dumazet <edumazet@google.com>
Input path is mostly run under RCU and doesnt touch dst refcnt
But output path on forwarding or UDP workloads hits
badly dst refcount, and we have lot of false sharing, for example
in ipv4_mtu() when reading rt->rt_pmtu
Using a percpu cache for nh_rth_output gives a nice performance
increase at a small cost.
24 udpflood test on my 24 cpu machine (dummy0 output device)
(each process sends 1.000.000 udp frames, 24 processes are started)
before : 5.24 s
after : 2.06 s
For reference, time on linux-3.5 : 6.60 s
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
v2: use __this_cpu_ptr() and slighly better annotations to avoid
ugly casts
On top on previous "ipv4: Restore old dst_free() behavior" patch
We probably can remove all paddings in struct dst_entry
include/net/ip_fib.h | 3 ++-
net/ipv4/fib_semantics.c | 20 +++++++++++++++++++-
net/ipv4/route.c | 18 +++++++++++++-----
3 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index e521a03..e331746 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -21,6 +21,7 @@
#include <linux/rcupdate.h>
#include <net/fib_rules.h>
#include <net/inetpeer.h>
+#include <linux/percpu.h>
struct fib_config {
u8 fc_dst_len;
@@ -81,7 +82,7 @@ struct fib_nh {
__be32 nh_gw;
__be32 nh_saddr;
int nh_saddr_genid;
- struct rtable __rcu *nh_rth_output;
+ struct rtable __rcu * __percpu *nh_pcpu_rth_output;
struct rtable __rcu *nh_rth_input;
struct fnhe_hash_bucket *nh_exceptions;
};
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 625cf18..fe2ca02 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -176,6 +176,23 @@ static void rt_nexthop_free(struct rtable __rcu **rtp)
dst_free(&rt->dst);
}
+static void rt_nexthop_free_cpus(struct rtable __rcu * __percpu *rtp)
+{
+ int cpu;
+
+ if (!rtp)
+ return;
+
+ for_each_possible_cpu(cpu) {
+ struct rtable *rt;
+
+ rt = rcu_dereference_protected(*per_cpu_ptr(rtp, cpu), 1);
+ if (rt)
+ dst_free(&rt->dst);
+ }
+ free_percpu(rtp);
+}
+
/* Release a nexthop info record */
static void free_fib_info_rcu(struct rcu_head *head)
{
@@ -186,7 +203,7 @@ static void free_fib_info_rcu(struct rcu_head *head)
dev_put(nexthop_nh->nh_dev);
if (nexthop_nh->nh_exceptions)
free_nh_exceptions(nexthop_nh);
- rt_nexthop_free(&nexthop_nh->nh_rth_output);
+ rt_nexthop_free_cpus(nexthop_nh->nh_pcpu_rth_output);
rt_nexthop_free(&nexthop_nh->nh_rth_input);
} endfor_nexthops(fi);
@@ -817,6 +834,7 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
fi->fib_nhs = nhs;
change_nexthops(fi) {
nexthop_nh->nh_parent = fi;
+ nexthop_nh->nh_pcpu_rth_output = alloc_percpu(struct rtable __rcu *);
} endfor_nexthops(fi)
if (cfg->fc_mx) {
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 2bd1074..4f6276c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1206,11 +1206,15 @@ static inline void rt_free(struct rtable *rt)
static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
{
- struct rtable *orig, *prev, **p = (struct rtable **)&nh->nh_rth_output;
+ struct rtable *orig, *prev, **p;
- if (rt_is_input_route(rt))
+ if (rt_is_input_route(rt)) {
p = (struct rtable **)&nh->nh_rth_input;
-
+ } else {
+ if (!nh->nh_pcpu_rth_output)
+ goto nocache;
+ p = (struct rtable **)__this_cpu_ptr(nh->nh_pcpu_rth_output);
+ }
orig = *p;
prev = cmpxchg(p, orig, rt);
@@ -1223,6 +1227,7 @@ static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
* unsuccessful at storing this route into the cache
* we really need to set it.
*/
+nocache:
rt->dst.flags |= DST_NOCACHE;
}
}
@@ -1749,8 +1754,11 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
fnhe = NULL;
if (fi) {
fnhe = find_exception(&FIB_RES_NH(*res), fl4->daddr);
- if (!fnhe) {
- rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_output);
+ if (!fnhe && FIB_RES_NH(*res).nh_pcpu_rth_output) {
+ struct rtable __rcu **prth;
+
+ prth = __this_cpu_ptr(FIB_RES_NH(*res).nh_pcpu_rth_output);
+ rth = rcu_dereference(*prth);
if (rt_cache_valid(rth)) {
dst_hold(&rth->dst);
return rth;
^ permalink raw reply related
* Re: [PATCH] ipv4: percpu nh_rth_output cache
From: Eric Dumazet @ 2012-07-31 15:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Alexander Duyck
In-Reply-To: <1343748166.21269.304.camel@edumazet-glaptop>
On Tue, 2012-07-31 at 17:22 +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> + p = per_cpu_ptr(nh->nh_pcpu_rth_output,
> + raw_smp_processor_id());
> + }
Note : this can use :
p = __this_cpu_ptr(nh->nh_pcpu_rth_output);
and same thing in __mkroute_output()
prth = __this_cpu_ptr(FIB_RES_NH(*res).nh_pcpu_rth_output);
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: Bernard Pidoux @ 2012-07-31 15:27 UTC (permalink / raw)
To: linux-hams, Linux Netdev List
In-Reply-To: <5017E786.5000102@free.fr>
Here is a complementary observation.
Trying to remove rose module with rmmod rose did not create any kernel
panic.
However, there is an endless message from the kernel saying :
Message from syslogd@raspberrypi at Jul 31 17:22:40 ...
kernel:[ 831.579007] unregister_netdevice: waiting for rose0 to
become free. Usage count = 23
Message from syslogd@raspberrypi at Jul 31 17:22:50 ...
kernel:[ 841.739390] unregister_netdevice: waiting for rose0 to
become free. Usage count = 23
Message from syslogd@raspberrypi at Jul 31 17:23:00 ...
kernel:[ 851.899758] unregister_netdevice: waiting for rose0 to
become free. Usage count = 23
.....
As observed at many occasions, count number seems to be random ! and
the same message keeps going without any change of count number.
At the same time, there is no possibility to recover the command line on
any console.
However I could loggin via ssh and I noticed that rose0 device is
actually no more in the ifconfig list.
If I try to remove rose with rmmod rose I get :
root@raspberrypi:/home/pi# rmmod rose
libkmod: ERROR ../libkmod/libkmod-module.c:753
kmod_module_remove_module: could not remove 'rose': Device or resource busy
Error: could not remove module rose: Device or resource busy
Does this help ?
On 31/07/2012 16:11, Bernard Pidoux wrote:
> Hi,
>
> I observe systematically a kernel panic when I try to shutdown rose0
> device using ifconfig rose0 down
>
> This is happening on two very different ROSE implementation, one is on a
> machine with x86-64 kernel 4.6.3 on an Intel core 2 duo CPU
> the other is on a RaspBerry Pi with Raspbian and 3.1.9+ wheezy kernel
> recompiled with AX.25 modules (ax25, rose, netrom, 6pack, kiss) enabled.
>
> Here is an image of the screen dump :
>
> http://f6bvp.org/photos/rose_device_event.JPG
>
> It can be noticed that PC is at rose_device_event and
> LR is at sock_def_wakeup
>
> One thing to be noticed is that when I close before all ROSE and AX.25
> applications, there are still a few populated sockets, probably for one
> of the program did not close the sockets properly.
>
> I that case, does rose module should accept to shutdown rose0 device ?
> However, I guess that it should not create a kernel panic due to a
> kernel NULL pointer.
>
> I don't know what to do in order to debug that issue.
>
> Bernard
>
^ 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