* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: David Miller @ 2009-09-25 21:59 UTC (permalink / raw)
To: greearb; +Cc: herbert, peter.p.waskiewicz.jr, netdev
In-Reply-To: <4ABD3B34.8010903@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Fri, 25 Sep 2009 14:50:44 -0700
> I get aggregate 18Gbps with LRO v/s 12Gbps without, so it's very
> much a useful feature for me.
And it'll stay like that until you work with Herbert to fix
that performance difference.
^ permalink raw reply
* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: Peter P Waskiewicz Jr @ 2009-09-25 21:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: greearb@candelatech.com, netdev@vger.kernel.org
In-Reply-To: <20090925214505.GA3472@gondor.apana.org.au>
On Fri, 2009-09-25 at 14:45 -0700, Herbert Xu wrote:
> Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> >
> >> That's a bummer. I'm guessing you might get close to right on average with some
> >> trivial math, but if someone is sending you pkts with size of 1000 and
> >> your MTU is 1500, would there be any way to tell that the pkts were originally
> >> 1000 bytes instead of 1500?
> >
> > Good point.
>
> Well if you did GRO instead of LRO then none of this would matter :)
ixgbe uses GRO, but we have HW RSC/LRO running on 82599 adapters
underneath GRO.
-PJ
^ permalink raw reply
* Re: Why is LRO off by default on ixgbe?
From: Ben Greear @ 2009-09-25 21:53 UTC (permalink / raw)
To: Herbert Xu; +Cc: shemminger, netdev
In-Reply-To: <20090925214303.GA3399@gondor.apana.org.au>
On 09/25/2009 02:43 PM, Herbert Xu wrote:
> On Fri, Sep 25, 2009 at 02:37:27PM -0700, Herbert Xu wrote:
>>
>>> Ok. It seems GRO was enabled the whole time, but LRO is what gave me the
>>> extra performance boost.
>>>
>>> In this particular case, I'm not actually routing, though I do have ip-forward
>>> enabled, so I guess LRO will be OK as long as I'm careful...
>>
>> What? A driver is either GRO or LRO, it can't be both. What
>> kernel version was this?
>
> Oh perhaps you mean LRO performed by hardware? That would make
> sense indeed. It's also one of the reasons why we hope the hardware
> folks would switch over to GRO so we can enable it for everyone :)
I assume it's in hardware. I am using ixgbe driver, 82599 chipset,
2.6.31 kernel.
GRO was showing as enabled the whole time in ethtool. Turning on LRO gave me an extra
6Gbps (from 12Gbps -> 18Gbps) receive throughput, so it certainly had some affect!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] 3c59x: Rework suspend and resume
From: Rafael J. Wysocki @ 2009-09-25 21:54 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: David Miller, Alan Stern, linux-pm, netdev
In-Reply-To: <20090925205206.GA9270@oksana.dev.rtsoft.ru>
On Friday 25 September 2009, Anton Vorontsov wrote:
> As noticed by Alan Stern, there is still one issue with the driver:
> we disable PCI IRQ on suspend, but other devices on the same IRQ
> line might still need the IRQ enabled to suspend properly.
>
> Nowadays, PCI core handles all power management work by itself, with
> one condition though: if we use dev_pm_ops. So, rework the driver to
> only quiesce 3c59x internal logic on suspend, while PCI core will
> manage PCI device power state with IRQs disabled.
>
> Suggested-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> Suggested-by: Alan Stern <stern@rowland.harvard.edu>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/net/3c59x.c | 77 +++++++++++++++++++++++++--------------------------
> 1 files changed, 38 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
> index 7cdd4b0..dee2320 100644
> --- a/drivers/net/3c59x.c
> +++ b/drivers/net/3c59x.c
> @@ -799,52 +799,54 @@ static void poll_vortex(struct net_device *dev)
>
> #ifdef CONFIG_PM
>
> -static int vortex_suspend(struct pci_dev *pdev, pm_message_t state)
> +static int vortex_suspend(struct device *dev)
> {
> - struct net_device *dev = pci_get_drvdata(pdev);
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct net_device *ndev = pci_get_drvdata(pdev);
> +
> + if (!ndev || !netif_running(ndev))
> + return 0;
> +
> + netif_device_detach(ndev);
> + vortex_down(ndev, 1);
>
> - if (dev && netdev_priv(dev)) {
> - if (netif_running(dev)) {
> - netif_device_detach(dev);
> - vortex_down(dev, 1);
> - disable_irq(dev->irq);
> - }
> - pci_save_state(pdev);
> - pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
> - pci_disable_device(pdev);
> - pci_set_power_state(pdev, pci_choose_state(pdev, state));
> - }
> return 0;
> }
>
> -static int vortex_resume(struct pci_dev *pdev)
> +static int vortex_resume(struct device *dev)
> {
> - struct net_device *dev = pci_get_drvdata(pdev);
> - struct vortex_private *vp = netdev_priv(dev);
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct net_device *ndev = pci_get_drvdata(pdev);
> int err;
>
> - if (dev && vp) {
> - pci_set_power_state(pdev, PCI_D0);
> - pci_restore_state(pdev);
> - err = pci_enable_device(pdev);
> - if (err) {
> - pr_warning("%s: Could not enable device\n",
> - dev->name);
> - return err;
> - }
> - pci_set_master(pdev);
> - if (netif_running(dev)) {
> - err = vortex_up(dev);
> - if (err)
> - return err;
> - enable_irq(dev->irq);
> - netif_device_attach(dev);
> - }
> - }
> + if (!ndev || !netif_running(ndev))
> + return 0;
> +
> + err = vortex_up(ndev);
> + if (err)
> + return err;
> +
> + netif_device_attach(ndev);
> +
> return 0;
> }
>
> -#endif /* CONFIG_PM */
> +static struct dev_pm_ops vortex_pm_ops = {
> + .suspend = vortex_suspend,
> + .resume = vortex_resume,
> + .freeze = vortex_suspend,
> + .thaw = vortex_resume,
> + .poweroff = vortex_suspend,
> + .restore = vortex_resume,
> +};
> +
> +#define VORTEX_PM_OPS (&vortex_pm_ops)
> +
> +#else /* !CONFIG_PM */
> +
> +#define VORTEX_PM_OPS NULL
> +
> +#endif /* !CONFIG_PM */
>
> #ifdef CONFIG_EISA
> static struct eisa_device_id vortex_eisa_ids[] = {
> @@ -3191,10 +3193,7 @@ static struct pci_driver vortex_driver = {
> .probe = vortex_init_one,
> .remove = __devexit_p(vortex_remove_one),
> .id_table = vortex_pci_tbl,
> -#ifdef CONFIG_PM
> - .suspend = vortex_suspend,
> - .resume = vortex_resume,
> -#endif
> + .driver.pm = VORTEX_PM_OPS,
> };
Thanks,
Rafael
^ permalink raw reply
* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: Ben Greear @ 2009-09-25 21:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: Peter P Waskiewicz Jr, netdev
In-Reply-To: <20090925214505.GA3472@gondor.apana.org.au>
On 09/25/2009 02:45 PM, Herbert Xu wrote:
> Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com> wrote:
>>
>>> That's a bummer. I'm guessing you might get close to right on average with some
>>> trivial math, but if someone is sending you pkts with size of 1000 and
>>> your MTU is 1500, would there be any way to tell that the pkts were originally
>>> 1000 bytes instead of 1500?
>>
>> Good point.
>
> Well if you did GRO instead of LRO then none of this would matter :)
I get aggregate 18Gbps with LRO v/s 12Gbps without, so it's very much a useful feature
for me.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] tunnel: eliminate recursion field
From: Herbert Xu @ 2009-09-25 21:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <4ABA8254.9000701@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> It seems recursion field from "struct ip_tunnel" is not anymore needed.
> recursion prevention is done at the upper level (in dev_queue_xmit()),
> since we use HARD_TX_LOCK protection for tunnels.
What if we get async processing in between, e.g., nf_queue?
In that case we could end up with a packet that went round and
around until it exceeded the MTU.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Getting physical packet counts with LRO enabled with ixgbe?
From: Herbert Xu @ 2009-09-25 21:45 UTC (permalink / raw)
To: Peter P Waskiewicz Jr; +Cc: greearb, netdev
In-Reply-To: <1253731834.2538.32.camel@localhost.localdomain>
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
>
>> That's a bummer. I'm guessing you might get close to right on average with some
>> trivial math, but if someone is sending you pkts with size of 1000 and
>> your MTU is 1500, would there be any way to tell that the pkts were originally
>> 1000 bytes instead of 1500?
>
> Good point.
Well if you did GRO instead of LRO then none of this would matter :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Why is LRO off by default on ixgbe?
From: Herbert Xu @ 2009-09-25 21:43 UTC (permalink / raw)
To: Ben Greear; +Cc: shemminger, netdev
In-Reply-To: <20090925213727.GA3291@gondor.apana.org.au>
On Fri, Sep 25, 2009 at 02:37:27PM -0700, Herbert Xu wrote:
>
> > Ok. It seems GRO was enabled the whole time, but LRO is what gave me the
> > extra performance boost.
> >
> > In this particular case, I'm not actually routing, though I do have ip-forward
> > enabled, so I guess LRO will be OK as long as I'm careful...
>
> What? A driver is either GRO or LRO, it can't be both. What
> kernel version was this?
Oh perhaps you mean LRO performed by hardware? That would make
sense indeed. It's also one of the reasons why we hope the hardware
folks would switch over to GRO so we can enable it for everyone :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Why is LRO off by default on ixgbe?
From: Herbert Xu @ 2009-09-25 21:37 UTC (permalink / raw)
To: Ben Greear; +Cc: shemminger, netdev
In-Reply-To: <4ABA57D1.5000905@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote:
>
> Ok. It seems GRO was enabled the whole time, but LRO is what gave me the
> extra performance boost.
>
> In this particular case, I'm not actually routing, though I do have ip-forward
> enabled, so I guess LRO will be OK as long as I'm careful...
What? A driver is either GRO or LRO, it can't be both. What
kernel version was this?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH][net-next] LRO: improve aggregation in case of zero TSecr packets
From: Herbert Xu @ 2009-09-25 21:33 UTC (permalink / raw)
To: Octavian Purdila; +Cc: themann, raisch, eric.dumazet, netdev
In-Reply-To: <200908270208.31581.opurdila@ixiacom.com>
Octavian Purdila <opurdila@ixiacom.com> wrote:
>
> This fixes a temporary performance issue we noticed in back to back
> TSO - LRO tests when such tests are run within five minutes after
> boot.
Sorry for responding to old emails again but just for the record,
please keep in mind that LRO is going away so you really should
run your tests with GRO (and update the driver if necessary) as
otherwise your efforts may end up being wasted.
In this particular instance, you're trying to fix an issue that
GRO already fixes.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] [bridge] Fix double-free in br_add_if.
From: Stephen Hemminger @ 2009-09-25 21:33 UTC (permalink / raw)
To: Jeff Hansen; +Cc: netdev, jeff, Dave Miller, Jeff Hansen
In-Reply-To: <1253910324-19006-1-git-send-email-x@jeffhansen.com>
On Fri, 25 Sep 2009 14:25:24 -0600
Jeff Hansen <x@jeffhansen.com> wrote:
> There is a potential double-kfree in net/bridge/br_if.c. If br_fdb_insert
> fails, then the kobject is put back (which calls kfree due to the kobject
> release), and then kfree is called again on the net_bridge_port. This
> patch fixes the crash.
>
> Signed-off-by: Jeff Hansen <x@jeffhansen.com>
> ---
> net/bridge/br_if.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index eb404dc..1becec1 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -368,7 +368,7 @@ done:
> int br_add_if(struct net_bridge *br, struct net_device *dev)
> {
> struct net_bridge_port *p;
> - int err = 0;
> + int err = 0, kobj_initted = 0;
>
> if (dev->flags & IFF_LOOPBACK || dev->type != ARPHRD_ETHER)
> return -EINVAL;
> @@ -391,6 +391,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
> SYSFS_BRIDGE_PORT_ATTR);
> if (err)
> goto err0;
> + kobj_initted = 1;
>
> err = br_fdb_insert(br, p, dev->dev_addr);
> if (err)
> @@ -429,7 +430,8 @@ err0:
> dev_set_promiscuity(dev, -1);
> put_back:
> dev_put(dev);
> - kfree(p);
> + if (!kobj_initted)
> + kfree(p);
> return err;
> }
>
I'll look at it, probably needs fixing, but the code style with condition
variables is out of place in this code.
^ permalink raw reply
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Gregory Haskins @ 2009-09-25 21:32 UTC (permalink / raw)
To: Avi Kivity
Cc: Ira W. Snyder, Michael S. Tsirkin, netdev, virtualization, kvm,
linux-kernel, mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze,
alacrityvm-devel
In-Reply-To: <4ABC7DCE.2000404@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 21865 bytes --]
Avi Kivity wrote:
> On 09/24/2009 09:03 PM, Gregory Haskins wrote:
>>
>>> I don't really see how vhost and vbus are different here. vhost expects
>>> signalling to happen through a couple of eventfds and requires someone
>>> to supply them and implement kernel support (if needed). vbus requires
>>> someone to write a connector to provide the signalling implementation.
>>> Neither will work out-of-the-box when implementing virtio-net over
>>> falling dominos, for example.
>>>
>> I realize in retrospect that my choice of words above implies vbus _is_
>> complete, but this is not what I was saying. What I was trying to
>> convey is that vbus is _more_ complete. Yes, in either case some kind
>> of glue needs to be written. The difference is that vbus implements
>> more of the glue generally, and leaves less required to be customized
>> for each iteration.
>>
>
>
> No argument there. Since you care about non-virt scenarios and virtio
> doesn't, naturally vbus is a better fit for them as the code stands.
Thanks for finally starting to acknowledge there's a benefit, at least.
To be more precise, IMO virtio is designed to be a performance oriented
ring-based driver interface that supports all types of hypervisors (e.g.
shmem based kvm, and non-shmem based Xen). vbus is designed to be a
high-performance generic shared-memory interconnect (for rings or
otherwise) framework for environments where linux is the underpinning
"host" (physical or virtual). They are distinctly different, but
complementary (the former addresses the part of the front-end, and
latter addresses the back-end, and a different part of the front-end).
In addition, the kvm-connector used in AlacrityVM's design strives to
add value and improve performance via other mechanisms, such as dynamic
allocation, interrupt coalescing (thus reducing exit-ratio, which is a
serious issue in KVM) and priortizable/nestable signals.
Today there is a large performance disparity between what a KVM guest
sees and what a native linux application sees on that same host. Just
take a look at some of my graphs between "virtio", and "native", for
example:
http://developer.novell.com/wiki/images/b/b7/31-rc4_throughput.png
A dominant vbus design principle is to try to achieve the same IO
performance for all "linux applications" whether they be literally
userspace applications, or things like KVM vcpus or Ira's physical
boards. It also aims to solve problems not previously expressible with
current technologies (even virtio), like nested real-time.
And even though you repeatedly insist otherwise, the neat thing here is
that the two technologies mesh (at least under certain circumstances,
like when virtio is deployed on a shared-memory friendly linux backend
like KVM). I hope that my stack diagram below depicts that clearly.
> But that's not a strong argument for vbus; instead of adding vbus you
> could make virtio more friendly to non-virt
Actually, it _is_ a strong argument then because adding vbus is what
helps makes virtio friendly to non-virt, at least for when performance
matters.
> (there's a limit how far you
> can take this, not imposed by the code, but by virtio's charter as a
> virtual device driver framework).
>
>> Going back to our stack diagrams, you could think of a vhost solution
>> like this:
>>
>> --------------------------
>> | virtio-net
>> --------------------------
>> | virtio-ring
>> --------------------------
>> | virtio-bus
>> --------------------------
>> | ? undefined-1 ?
>> --------------------------
>> | vhost
>> --------------------------
>>
>> and you could think of a vbus solution like this
>>
>> --------------------------
>> | virtio-net
>> --------------------------
>> | virtio-ring
>> --------------------------
>> | virtio-bus
>> --------------------------
>> | bus-interface
>> --------------------------
>> | ? undefined-2 ?
>> --------------------------
>> | bus-model
>> --------------------------
>> | virtio-net-device (vhost ported to vbus model? :)
>> --------------------------
>>
>>
>> So the difference between vhost and vbus in this particular context is
>> that you need to have "undefined-1" do device discovery/hotswap,
>> config-space, address-decode/isolation, signal-path routing, memory-path
>> routing, etc. Today this function is filled by things like virtio-pci,
>> pci-bus, KVM/ioeventfd, and QEMU for x86. I am not as familiar with
>> lguest, but presumably it is filled there by components like
>> virtio-lguest, lguest-bus, lguest.ko, and lguest-launcher. And to use
>> more contemporary examples, we might have virtio-domino, domino-bus,
>> domino.ko, and domino-launcher as well as virtio-ira, ira-bus, ira.ko,
>> and ira-launcher.
>>
>> Contrast this to the vbus stack: The bus-X components (when optionally
>> employed by the connector designer) do device-discovery, hotswap,
>> config-space, address-decode/isolation, signal-path and memory-path
>> routing, etc in a general (and pv-centric) way. The "undefined-2"
>> portion is the "connector", and just needs to convey messages like
>> "DEVCALL" and "SHMSIGNAL". The rest is handled in other parts of the
>> stack.
>>
>>
>
> Right. virtio assumes that it's in a virt scenario and that the guest
> architecture already has enumeration and hotplug mechanisms which it
> would prefer to use. That happens to be the case for kvm/x86.
No, virtio doesn't assume that. It's stack provides the "virtio-bus"
abstraction and what it does assume is that it will be wired up to
something underneath. Kvm/x86 conveniently has pci, so the virtio-pci
adapter was created to reuse much of that facility. For other things
like lguest and s360, something new had to be created underneath to make
up for the lack of pci-like support.
vbus, in conjunction with the kvm-connector, tries to unify that process
a little more by creating a PV-optimized bus. The idea is that it can
be reused in that situation instead of creating a new hypervisor
specific bus each time. It's also designed for high-performance, so you
get that important trait for free simply by tying into it.
>
>> So to answer your question, the difference is that the part that has to
>> be customized in vbus should be a fraction of what needs to be
>> customized with vhost because it defines more of the stack.
>
> But if you want to use the native mechanisms, vbus doesn't have any
> added value.
First of all, thats incorrect. If you want to use the "native"
mechanisms (via the way the vbus-connector is implemented, for instance)
you at least still have the benefit that the backend design is more
broadly re-useable in more environments (like non-virt, for instance),
because vbus does a proper job of defining the requisite
layers/abstractions compared to vhost. So it adds value even in that
situation.
Second of all, with PV there is no such thing as "native". It's
software so it can be whatever we want. Sure, you could argue that the
guest may have built-in support for something like PCI protocol.
However, PCI protocol itself isn't suitable for high-performance PV out
of the can. So you will therefore invariably require new software
layers on top anyway, even if part of the support is already included.
And lastly, why would you _need_ to use the so called "native"
mechanism? The short answer is, "you don't". Any given system (guest
or bare-metal) already have a wide-range of buses (try running "tree
/sys/bus" in Linux). More importantly, the concept of adding new buses
is widely supported in both the Windows and Linux driver model (and
probably any other guest-type that matters). Therefore, despite claims
to the contrary, its not hard or even unusual to add a new bus to the mix.
In summary, vbus is simply one more bus of many, purpose built to
support high-end IO in a virt-like model, giving controlled access to
the linux-host underneath it. You can write a high-performance layer
below the OS bus-model (vbus), or above it (virtio-pci) but either way
you are modifying the stack to add these capabilities, so we might as
well try to get this right.
With all due respect, you are making a big deal out of a minor issue.
>
>> And, as
>> eluded to in my diagram, both virtio-net and vhost (with some
>> modifications to fit into the vbus framework) are potentially
>> complementary, not competitors.
>>
>
> Only theoretically. The existing installed base would have to be thrown
> away
"Thrown away" is pure hyperbole. The installed base, worse case, needs
to load a new driver for a missing device. This is pretty much how
every machine works today, anyway. And if loading a driver was actually
some insurmountable hurdle, as its sometimes implied (but its not in
reality), you can alternatively make vbus look like a legacy bus if you
are willing to sacrifice some of features, like exit-ratio reduction and
priority.
FWIW: AlacrityVM isn't willing to sacrifice those features, so we will
provide a Linux and Windows driver for explicit bus support, as well as
open-specs and community development assistance to any other guest that
wants to add support in the future.
> or we'd need to support both.
>
>
No matter what model we talk about, there's always going to be a "both"
since the userspace virtio models are probably not going to go away (nor
should they).
>
>
>>> Without a vbus-connector-falling-dominos, vbus-venet can't do anything
>>> either.
>>>
>> Mostly covered above...
>>
>> However, I was addressing your assertion that vhost somehow magically
>> accomplishes this "container/addressing" function without any specific
>> kernel support. This is incorrect. I contend that this kernel support
>> is required and present. The difference is that its defined elsewhere
>> (and typically in a transport/arch specific way).
>>
>> IOW: You can basically think of the programmed PIO addresses as forming
>> its "container". Only addresses explicitly added are visible, and
>> everything else is inaccessible. This whole discussion is merely a
>> question of what's been generalized verses what needs to be
>> re-implemented each time.
>>
>
> Sorry, this is too abstract for me.
With all due respect, understanding my point above is required to have
any kind of meaningful discussion here.
>
>
>
>>> vbus doesn't do kvm guest address decoding for the fast path. It's
>>> still done by ioeventfd.
>>>
>> That is not correct. vbus does its own native address decoding in the
>> fast path, such as here:
>>
>> http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=kernel/vbus/client.c;h=e85b2d92d629734866496b67455dd307486e394a;hb=e6cbd4d1decca8e829db3b2b9b6ec65330b379e9#l331
>>
>>
>>
>
> All this is after kvm has decoded that vbus is addresses. It can't work
> without someone outside vbus deciding that.
How the connector message is delivered is really not relevant. Some
architectures will simply deliver the message point-to-point (like the
original hypercall design for KVM, or something like Ira's rig), and
some will need additional demuxing (like pci-bridge/pio based KVM).
It's an implementation detail of the connector.
However, the real point here is that something needs to establish a
scoped namespace mechanism, add items to that namespace, and advertise
the presence of the items to the guest. vbus has this facility built in
to its stack. vhost doesn't, so it must come from elsewhere.
>
>> In fact, it's actually a simpler design to unify things this way because
>> you avoid splitting the device model up. Consider how painful the vhost
>> implementation would be if it didn't already have the userspace
>> virtio-net to fall-back on. This is effectively what we face for new
>> devices going forward if that model is to persist.
>>
>
>
> It doesn't have just virtio-net, it has userspace-based hostplug
vbus has hotplug too: mkdir and rmdir
As an added bonus, its device-model is modular. A developer can write a
new device model, compile it, insmod it to the host kernel, hotplug it
to the running guest with mkdir/ln, and the come back out again
(hotunplug with rmdir, rmmod, etc). They may do this all without taking
the guest down, and while eating QEMU based IO solutions for breakfast
performance wise.
Afaict, qemu can't do either of those things.
> and a bunch of other devices impemented in userspace.
Thats fine. I am primarily interested in the high-performance
components, so most of those other items can stay there in userspace if
that is their ideal location.
> Currently qemu has
> virtio bindings for pci and syborg (whatever that is), and device models
> for baloon, block, net, and console, so it seems implementing device
> support in userspace is not as disasterous as you make it to be.
I intentionally qualified "device" with "new" in my statement. And in
that context I was talking about ultimately developing/supporting
in-kernel models, not pure legacy userspace ones. I have no doubt the
implementation of the original userpsace devices was not a difficult or
horrific endeavor.
Requiring new models to be implemented (at least) twice is a poor design
IMO, however. Requiring them to split such a minor portion of their
functionality (like read-only attributes) is a poor design, too. I have
already demonstrated there are other ways to achieve the same
high-performance goals without requiring two models developed/tested
each time and for each manager. For the times I went and tried to
satisfy your request in this manner, developing the code and managing
the resources in two places, for lack of a better description, made me
want to wretch. So I gave up, resolved that my original design was
better, and hoped that I could convince you and the community of the same.
>
>>> Invariably?
>>>
>> As in "always"
>>
>
> Refactor instead of duplicating.
There is no duplicating. vbus has no equivalent today as virtio doesn't
define these layers.
>
>>
>>> Use libraries (virtio-shmem.ko, libvhost.so).
>>>
>> What do you suppose vbus is? vbus-proxy.ko = virtio-shmem.ko, and you
>> dont need libvhost.so per se since you can just use standard kernel
>> interfaces (like configfs/sysfs). I could create an .so going forward
>> for the new ioctl-based interface, I suppose.
>>
>
> Refactor instead of rewriting.
There is no rewriting. vbus has no equivalent today as virtio doesn't
define these layers.
By your own admission, you said if you wanted that capability, use a
library. What I think you are not understanding is vbus _is_ that
library. So what is the problem, exactly?
>
>
>
>>> For kvm/x86 pci definitely remains king.
>>>
>> For full virtualization, sure. I agree. However, we are talking about
>> PV here. For PV, PCI is not a requirement and is a technical dead-end
>> IMO.
>>
>> KVM seems to be the only virt solution that thinks otherwise (*), but I
>> believe that is primarily a condition of its maturity. I aim to help
>> advance things here.
>>
>> (*) citation: xen has xenbus, lguest has lguest-bus, vmware has some
>> vmi-esq thing (I forget what its called) to name a few. Love 'em or
>> hate 'em, most other hypervisors do something along these lines. I'd
>> like to try to create one for KVM, but to unify them all (at least for
>> the Linux-based host designs).
>>
>
> VMware are throwing VMI away (won't be supported in their new product,
> and they've sent a patch to rip it off from Linux);
vmware only cares about x86 iiuc, so probably not a good example.
> Xen has to tunnel
> xenbus in pci for full virtualization (which is where Windows is, and
> where Linux will be too once people realize it's faster). lguest is
> meant as an example hypervisor, not an attempt to take over the world.
So pick any other hypervisor, and the situation is often similar.
>
> "PCI is a dead end" could not be more wrong, it's what guests support.
It's what _some_ guests support. Even for the guests that support it,
it's not well designed for PV. Therefore, you have to do a bunch of
dancing and waste resources on top to squeeze every last drop of
performance out of your platform. In addition, it has a bunch of
baggage that goes with it that is not necessary to do the job in a
software environment. It is therefore burdensome to recreate if you
don't already have something to leverage, like QEMU, just for the sake
of creating the illusion that its there.
Sounds pretty dead to me, sorry. We don't need it.
Alternatively, you can just try to set a stake in the ground for looking
forward and fixing those PV-specific problems hopefully once and for
all, like vbus and the kvm-connector tries to do. Sure, there will be
some degree of pain first as we roll out the subsystem and deploy
support, but thats true for lots of things. It's simply a platform
investment.
> An right now you can have a guest using pci to access a mix of
> userspace-emulated devices, userspace-emulated-but-kernel-accelerated
> virtio devices, and real host devices. All on one dead-end bus. Try
> that with vbus.
vbus is not interested in userspace devices. The charter is to provide
facilities for utilizing the host linux kernel's IO capabilities in the
most efficient, yet safe, manner possible. Those devices that fit
outside that charter can ride on legacy mechanisms if that suits them best.
>
>
>>>> I digress. My point here isn't PCI. The point here is the missing
>>>> component for when PCI is not present. The component that is partially
>>>> satisfied by vbus's devid addressing scheme. If you are going to use
>>>> vhost, and you don't have PCI, you've gotta build something to replace
>>>> it.
>>>>
>>>>
>>> Yes, that's why people have keyboards. They'll write that glue code if
>>> they need it. If it turns out to be a hit an people start having virtio
>>> transport module writing parties, they'll figure out a way to share
>>> code.
>>>
>> Sigh... The party has already started. I tried to invite you months
>> ago...
>>
>
> I've been voting virtio since 2007.
That doesn't have much to do with whats underneath it, since it doesn't
define these layers. See my stack diagram's for details.
>
>>> On the guest side, virtio-shmem.ko can unify the ring access. It
>>> probably makes sense even today. On the host side I eventfd is the
>>> kernel interface and libvhostconfig.so can provide the configuration
>>> when an existing ABI is not imposed.
>>>
>> That won't cut it. For one, creating an eventfd is only part of the
>> equation. I.e. you need to have originate/terminate somewhere
>> interesting (and in-kernel, otherwise use tuntap).
>>
>
> vbus needs the same thing so it cancels out.
No, it does not. vbus just needs a relatively simple single message
pipe between the guest and host (think "hypercall tunnel", if you will).
Per queue/device addressing is handled by the same conceptual namespace
as the one that would trigger eventfds in the model you mention. And
that namespace is built in to the vbus stack, and objects are registered
automatically as they are created.
Contrast that to vhost, which requires some other kernel interface to
exist, and to be managed manually for each object that is created. Your
libvhostconfig would need to somehow know how to perform this
registration operation, and there would have to be something in the
kernel to receive it, presumably on a per platform basis. Solving this
problem generally would probably end up looking eerily like vbus,
because thats what vbus does.
>
>>> Look at the virtio-net feature negotiation. There's a lot more there
>>> than the MAC address, and it's going to grow.
>>>
>> Agreed, but note that makes my point. That feature negotiation almost
>> invariably influences the device-model, not some config-space shim.
>> IOW: terminating config-space at some userspace shim is pointless. The
>> model ultimately needs the result of whatever transpires during that
>> negotiation anyway.
>>
>
> Well, let's see. Can vbus today:
>
> - let userspace know which features are available (so it can decide if
> live migration is possible)
yes, its in sysfs.
> - let userspace limit which features are exposed to the guest (so it can
> make live migration possible among hosts of different capabilities)
yes, its in sysfs.
> - let userspace know which features were negotiated (so it can transfer
> them to the other host during live migration)
no, but we can easily add ->save()/->restore() to the model going
forward, and the negotiated features are just a subcomponent if its
serialized stream.
> - let userspace tell the kernel which features were negotiated (when
> live migration completes, to avoid requiring the guest to re-negotiate)
that would be the function of the ->restore() deserializer.
> - do all that from an unprivileged process
yes, in the upcoming alacrityvm v0.3 with the ioctl based control plane.
> - securely wrt other unprivileged processes
yes, same mechanism plus it has a fork-inheritance model.
Bottom line: vbus isn't done, especially w.r.t. live-migration..but that
is not an valid argument against the idea if you believe in
release-early/release-often. kvm wasn't (isn't) done either when it was
proposed/merged.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* [GIT]: Networking
From: David Miller @ 2009-09-25 21:31 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Forgotten GIT 'add' in CAN driver commit, my bad.
2) AX25 control block refcounting is hosed, fix from Jarek Poplawski.
3) virtio_net driver updates from Rusty Russel
4) TI Davinci checks interrupt pending status wrongly. From Sriram @ TI.
Please pull, thanks a lot!
The following changes since commit 53cddfcc0e760d2b364878b6dadbd0c6d087cfae:
Linus Torvalds (1):
Merge git://git.kernel.org/.../lethal/sh-2.6
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Amit Shah (1):
virtio_net: Check for room in the vq before adding buffer
David S. Miller (2):
Merge branch 'master' of ssh://master.kernel.org/.../rusty/linux-2.6-for-davem
at91_can: Forgotten git 'add' of at91_can.c
Jarek Poplawski (1):
ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
Rusty Russell (5):
virtio_net: skb_orphan() and nf_reset() in xmit path.
virtio_net: return NETDEV_TX_BUSY instead of queueing an extra skb.
virtio_net: don't free buffers in xmit ring
virtio_net: formalize skb_vnet_hdr
virtio_net: avoid (most) NETDEV_TX_BUSY by stopping queue early.
Sriram (1):
TI Davinci EMAC: Fix in vector definition for EMAC_VERSION_2
drivers/net/can/at91_can.c | 1186 ++++++++++++++++++++++++++++++++++++++++++++
drivers/net/davinci_emac.c | 9 +-
drivers/net/virtio_net.c | 229 ++++------
net/ax25/af_ax25.c | 27 +-
4 files changed, 1299 insertions(+), 152 deletions(-)
create mode 100644 drivers/net/can/at91_can.c
^ permalink raw reply
* [PATCH] 3c59x: Rework suspend and resume
From: Anton Vorontsov @ 2009-09-25 20:52 UTC (permalink / raw)
To: David Miller; +Cc: Rafael J. Wysocki, Alan Stern, linux-pm, netdev
As noticed by Alan Stern, there is still one issue with the driver:
we disable PCI IRQ on suspend, but other devices on the same IRQ
line might still need the IRQ enabled to suspend properly.
Nowadays, PCI core handles all power management work by itself, with
one condition though: if we use dev_pm_ops. So, rework the driver to
only quiesce 3c59x internal logic on suspend, while PCI core will
manage PCI device power state with IRQs disabled.
Suggested-by: Rafael J. Wysocki <rjw@sisk.pl>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/3c59x.c | 77 +++++++++++++++++++++++++--------------------------
1 files changed, 38 insertions(+), 39 deletions(-)
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 7cdd4b0..dee2320 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -799,52 +799,54 @@ static void poll_vortex(struct net_device *dev)
#ifdef CONFIG_PM
-static int vortex_suspend(struct pci_dev *pdev, pm_message_t state)
+static int vortex_suspend(struct device *dev)
{
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct net_device *ndev = pci_get_drvdata(pdev);
+
+ if (!ndev || !netif_running(ndev))
+ return 0;
+
+ netif_device_detach(ndev);
+ vortex_down(ndev, 1);
- if (dev && netdev_priv(dev)) {
- if (netif_running(dev)) {
- netif_device_detach(dev);
- vortex_down(dev, 1);
- disable_irq(dev->irq);
- }
- pci_save_state(pdev);
- pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
- pci_disable_device(pdev);
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
- }
return 0;
}
-static int vortex_resume(struct pci_dev *pdev)
+static int vortex_resume(struct device *dev)
{
- struct net_device *dev = pci_get_drvdata(pdev);
- struct vortex_private *vp = netdev_priv(dev);
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct net_device *ndev = pci_get_drvdata(pdev);
int err;
- if (dev && vp) {
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
- err = pci_enable_device(pdev);
- if (err) {
- pr_warning("%s: Could not enable device\n",
- dev->name);
- return err;
- }
- pci_set_master(pdev);
- if (netif_running(dev)) {
- err = vortex_up(dev);
- if (err)
- return err;
- enable_irq(dev->irq);
- netif_device_attach(dev);
- }
- }
+ if (!ndev || !netif_running(ndev))
+ return 0;
+
+ err = vortex_up(ndev);
+ if (err)
+ return err;
+
+ netif_device_attach(ndev);
+
return 0;
}
-#endif /* CONFIG_PM */
+static struct dev_pm_ops vortex_pm_ops = {
+ .suspend = vortex_suspend,
+ .resume = vortex_resume,
+ .freeze = vortex_suspend,
+ .thaw = vortex_resume,
+ .poweroff = vortex_suspend,
+ .restore = vortex_resume,
+};
+
+#define VORTEX_PM_OPS (&vortex_pm_ops)
+
+#else /* !CONFIG_PM */
+
+#define VORTEX_PM_OPS NULL
+
+#endif /* !CONFIG_PM */
#ifdef CONFIG_EISA
static struct eisa_device_id vortex_eisa_ids[] = {
@@ -3191,10 +3193,7 @@ static struct pci_driver vortex_driver = {
.probe = vortex_init_one,
.remove = __devexit_p(vortex_remove_one),
.id_table = vortex_pci_tbl,
-#ifdef CONFIG_PM
- .suspend = vortex_suspend,
- .resume = vortex_resume,
-#endif
+ .driver.pm = VORTEX_PM_OPS,
};
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH net-next-2.6] cxgb3: Added private MAC address and provisioning packet handler for iSCSI
From: David Miller @ 2009-09-25 20:42 UTC (permalink / raw)
To: kxie; +Cc: swise, divy, rranjan, James.Bottomley, michaelc, linux-kernel,
netdev
In-Reply-To: <20090925.121242.184886085.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 25 Sep 2009 12:12:42 -0700 (PDT)
> From: kxie@chelsio.com
> Date: Thu, 24 Sep 2009 18:33:10 -0700
>
>> 00c487ed661c0904757a21b7c958eba59e68482a
>> [PATCH net-next-2.6] cxgb3: Added private MAC address and provisioning packet handler for iSCSI
>>
>> This patch added support of private MAC address per port and provisioning
>> packet handler for iSCSI traffic only.
>>
>> Acked-by: Karen Xie <kxie@chelsio.com>
>> Acked-by: Divy Le Ray <divy@chelsio.com>
>> Signed-off-by: Rakesh Ranjan <rranjan@chelsio.com>
>
> Applied, thanks.
This doesn't even build, reverting:
drivers/scsi/cxgb3i/cxgb3i_iscsi.c: In function ‘cxgb3i_host_set_param’:
drivers/scsi/cxgb3i/cxgb3i_iscsi.c:718: error: ‘struct port_info’ has no member named ‘iscsi_ipv4addr’
drivers/scsi/cxgb3i/cxgb3i_iscsi.c: In function ‘cxgb3i_host_get_param’:
drivers/scsi/cxgb3i/cxgb3i_iscsi.c:755: error: ‘struct port_info’ has no member named ‘iscsi_ipv4addr’
make[3]: *** [drivers/scsi/cxgb3i/cxgb3i_iscsi.o] Error 1
^ permalink raw reply
* Re: [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
From: Jarek Poplawski @ 2009-09-25 20:29 UTC (permalink / raw)
To: Bernard Pidoux
Cc: Ralf Baechle DL5RB, David Miller, Bernard Pidoux F6BVP,
Linux Netdev List, linux-hams
In-Reply-To: <4ABD1EF3.7040400@upmc.fr>
On Fri, Sep 25, 2009 at 09:50:11PM +0200, Bernard Pidoux wrote:
> Hi Jarek,
>
> patch applied to 2.6.31.1 kernel keeping your other AX25 debugging patches.
Actually, only one of them is for debugging.
>
> So far, so good !
Very strange...;-) It seems I might have been wrong and the previous
patch could actually fix those oopses. Then it would point at some
problems while starting netrom connections as the main suspect.
Thanks,
Jarek P.
^ permalink raw reply
* Re: [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
From: Bernard Pidoux @ 2009-09-25 19:50 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Ralf Baechle DL5RB, David Miller, Bernard Pidoux F6BVP,
Linux Netdev List, linux-hams
In-Reply-To: <20090925183504.GA3307@del.dom.local>
Hi Jarek,
patch applied to 2.6.31.1 kernel keeping your other AX25 debugging patches.
So far, so good !
Thanks.
Bernard Pidoux
Jarek Poplawski a écrit :
> On Fri, Sep 25, 2009 at 02:40:52PM +0100, Ralf Baechle DL5RB wrote:
>> On Fri, Sep 25, 2009 at 01:10:38PM +0000, Jarek Poplawski wrote:
>>
>>> This bug isn't responsible for these oopses here, but looks quite
>>> obviously. (I'm not sure if it's easy to test/hit with the common
>>> tools.)
>> The issue your patch fixes is obvious enough.
>
> Yes, with new code there would be no doubt. But here, if you know it's
> worked for some time, you wonder if you're not blind. |-)
>>> Jarek P.
>>> ------------>
>>> [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
>>>
>>> Use ax25_cb_put after ax25_find_cb in ax25_ctl_ioctl.
>>>
>>> Reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>
>>> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>> Reviewed-by: Ralf Baechle <ralf@linux-mips.org>
>>
> Thanks for reviewing,
> Jarek P.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6] cxgb3: Added private MAC address and provisioning packet handler for iSCSI
From: David Miller @ 2009-09-25 19:12 UTC (permalink / raw)
To: kxie; +Cc: swise, divy, rranjan, James.Bottomley, michaelc, linux-kernel,
netdev
In-Reply-To: <200909250133.n8P1XAZb030062@localhost.localdomain>
From: kxie@chelsio.com
Date: Thu, 24 Sep 2009 18:33:10 -0700
> 00c487ed661c0904757a21b7c958eba59e68482a
> [PATCH net-next-2.6] cxgb3: Added private MAC address and provisioning packet handler for iSCSI
>
> This patch added support of private MAC address per port and provisioning
> packet handler for iSCSI traffic only.
>
> Acked-by: Karen Xie <kxie@chelsio.com>
> Acked-by: Divy Le Ray <divy@chelsio.com>
> Signed-off-by: Rakesh Ranjan <rranjan@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
From: David Miller @ 2009-09-25 19:10 UTC (permalink / raw)
To: jarkao2; +Cc: ralf, f6bvp, bernard.pidoux, netdev, linux-hams
In-Reply-To: <20090925183504.GA3307@del.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Fri, 25 Sep 2009 20:35:04 +0200
> On Fri, Sep 25, 2009 at 02:40:52PM +0100, Ralf Baechle DL5RB wrote:
>> > [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
>> >
>> > Use ax25_cb_put after ax25_find_cb in ax25_ctl_ioctl.
>> >
>> > Reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>
>> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>>
>> Reviewed-by: Ralf Baechle <ralf@linux-mips.org>
>>
> Thanks for reviewing,
Applied.
^ permalink raw reply
* Re: [PATCH] drivers/net: ks8851 ethernet network driver - RESUBMIT
From: David Miller @ 2009-09-25 19:09 UTC (permalink / raw)
To: David.Choi; +Cc: greg, netdev, Charles.Li, Choi, jgarzik, shemminger
In-Reply-To: <C43529A246480145B0A6D0234BDB0F0D02127E@MELANITE.micrel.com>
This patch does not apply.
There is already a CONFIG_KS8851 and a drivers/net/ks8851.c driver
in Linus's tree right now. So it completely conflicts with your's
I'm getting burnt out going back and forth trying to apply this
patch and it doesn't apply cleanly or there's already a driver
with that name etc.
This is a complete mess and a very poor driver submission.
Please get things straight, look at how other developers write
their commit messages and signoffs (your's was in bad style and
the signoff was not in the format described in
linux/Documentation/SubmittingPatches, for example).
^ permalink raw reply
* Re: [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
From: Jarek Poplawski @ 2009-09-25 18:35 UTC (permalink / raw)
To: Ralf Baechle DL5RB
Cc: David Miller, Bernard Pidoux F6BVP, Bernard Pidoux,
Linux Netdev List, linux-hams
In-Reply-To: <20090925134052.GA1661@linux-mips.org>
On Fri, Sep 25, 2009 at 02:40:52PM +0100, Ralf Baechle DL5RB wrote:
> On Fri, Sep 25, 2009 at 01:10:38PM +0000, Jarek Poplawski wrote:
>
> > This bug isn't responsible for these oopses here, but looks quite
> > obviously. (I'm not sure if it's easy to test/hit with the common
> > tools.)
>
> The issue your patch fixes is obvious enough.
Yes, with new code there would be no doubt. But here, if you know it's
worked for some time, you wonder if you're not blind. |-)
>
> > Jarek P.
> > ------------>
> > [PATCH] ax25: Fix ax25_cb refcounting in ax25_ctl_ioctl
> >
> > Use ax25_cb_put after ax25_find_cb in ax25_ctl_ioctl.
> >
> > Reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>
> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>
> Reviewed-by: Ralf Baechle <ralf@linux-mips.org>
>
Thanks for reviewing,
Jarek P.
^ permalink raw reply
* Re: [PULL] virtio_net updates
From: David Miller @ 2009-09-25 18:09 UTC (permalink / raw)
To: rusty; +Cc: netdev, herbert, markmc, dineshs, amit.shah
In-Reply-To: <200909241005.59416.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Thu, 24 Sep 2009 10:05:58 +0930
> Now Linus has the prereq add_buf changes, these can all feed via
> you. Note that the driver is changed to return TX_BUSY first which
> is simplest, then complicated again to avoid it.
Pulled, thanks a lot!
^ permalink raw reply
* Re: [PATCH 13/13] TProxy: use the interface primary IP address as a default value for --on-ip
From: Balazs Scheidler @ 2009-09-25 18:07 UTC (permalink / raw)
To: Brian Haley; +Cc: netfilter-devel, netdev
In-Reply-To: <4AB8DC6F.90602@hp.com>
On Tue, 2009-09-22 at 10:17 -0400, Brian Haley wrote:
> Balazs Scheidler wrote:
> > On Mon, 2009-09-21 at 14:00 -0400, Brian Haley wrote:
> >> Balazs Scheidler wrote:
> >>> #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> >>> +
> >>> +static inline const struct in6_addr *
> >>> +tproxy_laddr6(struct sk_buff *skb, const struct in6_addr *user_laddr, const struct in6_addr *daddr)
> >>> +{
> >>> + struct inet6_dev *indev;
> >>> + struct inet6_ifaddr *ifa;
> >>> + struct in6_addr *laddr;
> >>> +
> >>> + if (!ipv6_addr_any(user_laddr))
> >>> + return user_laddr;
> >>> +
> >>> + laddr = NULL;
> >>> + rcu_read_lock();
> >>> + indev = __in6_dev_get(skb->dev);
> >>> + if (indev && (ifa = indev->addr_list)) {
> >>> + laddr = &ifa->addr;
> >>> + }
> >>> + rcu_read_unlock();
> >>> +
> >>> + return laddr ? laddr : daddr;
> >>> +}
> >> You should call ipv6_dev_get_saddr() to get a source address based on the target
> >> destination address.
> >
> > Thanks for this hint, however this is not selecting a source address for
> > a given destination, rather it selects the address where tproxy is
> > redirecting the connection in case the user specified no --on-ip
> > parameter.
> >
> > e.g.
> >
> > ip6tables -A PREROUTING -p tcp --dport 80 -j TPROXY --on-port 50080
> >
> > This should redirect the connection to the primary IP address of the
> > incoming interface. In fact I spent 2 hours to figure out how to find
> > the proper address, and at the end I used the first IP address
> > configured to the interface, seeing that those addresses are sorted in
> > 'scope' order, e.g. link-local and site-local addresses are at the end
> > of the list, thus the front should be ok.
>
> Yes, the addresses are sorted by scope, but just because they're in the
> list doesn't mean they can be used, for example that address might have
> failed DAD or be Deprecated. ipv6_dev_get_saddr() will follow the rules
> from RFC 3484 in picking the best address to use, or none if there isn't
> anything appropriate.
>
> > Since I'm not that much into IPv6, I'd appreciate some help, is
> > ipv6_dev_get_saddr(client_ip_address) indeed the best solution here?
>
> Probably. An alternative might be to use ip6_dst_lookup() (see tcp_v6_connect()),
> but a lot more code for you.
One question, how fast is ipv6_dev_get_saddr()? Since the TPROXY target
can execute on a per-packet path (although the socket match should take
care of packets that belong to already-established connections), this
may be performance critical. Is ipv6_dev_get_saddr() something that I
can call so often?
--
Bazsi
^ permalink raw reply
* Re: TCP stack bug related to F-RTO?
From: Ilpo Järvinen @ 2009-09-25 18:03 UTC (permalink / raw)
To: Joe Cao; +Cc: Ray Lee, Netdev, LKML
In-Reply-To: <773030.8168.qm@web63404.mail.re1.yahoo.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4869 bytes --]
On Fri, 25 Sep 2009, Joe Cao wrote:
> Thanks for the reply! Do you happen to know which patch fixed the
> problem?
You can find those patches from the stable queue git tree. I gave you hint
from what release to look from in the last mail. However, as 2.6.24 is
anyway obsolete my recommendation is that you should probably consider
upgrading to fix all the other bugs that have been found since 2.6.24 was
obsoleted.
> Is there a bug tracking system for linux kernel?
Nothing that knows everything about everything.
> I studied the FRTO code in latest kernel 2.6.31. It seems the problem
> is still there:
>
> 1. Every time a RTO fires, because tcp_is_sackfrto(tp) returns 1,
> tcp_use_frto() returns true. And the server tcp enters FRTO.
> 2. After the head of write queue is retransmitted, two new data packets
> are transmitted, the server receives two dup-ACKs. That will make the
> TCP enter tcp_enter_frto_loss(), however, that only rests ssthresh and
> some other fields.
Perhaps those other fields are far more important than you think... :-)
...Some retransmission would happen here as step 3.
> 3. After another longer RTO fires, because tcp_is_sackfrto(tp) returns
> 1, tcp_use_frto() again returns true. The stack enters FRTO again.
> 4. The above repeats and the stack couldn't retransmits the lost packets
> faster.
>
> Is my understanding above correct?
...No. All magic that happens in tcp_enter_frto_loss should be enough to
really do more than a single retransmission (that is, in any other than
2.6.24 series kernel). There was an unfortunate bug in this area in 2.6.24
which basically undoed the effect of correct actions tcp_enter_frto_loss
did which effectively prevented tcp_xmit_retransmit_queue from doing its
part.
--
i.
--- On Fri, 9/25/09, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> Subject: Re: TCP stack bug related to F-RTO?
> To: "Ray Lee" <ray-lk@madrabbit.org>
> Cc: "Joe Cao" <caoco2002@yahoo.com>, "Netdev" <netdev@vger.kernel.org>, "LKML" <linux-kernel@vger.kernel.org>, jcaoco2002@yahoo.com
> Date: Friday, September 25, 2009, 6:09 AM
> On Thu, 24 Sep 2009, Ray Lee wrote:
>
> > [adding netdev cc:]
> >
> > On Thu, Sep 24, 2009 at 10:43 AM, Joe Cao <caoco2002@yahoo.com>
> wrote:
> > >
> > > Hello,
> > >
> > > I have found the following behavior with
> different versions of linux
> > > kernel. The attached pcap trace is collected with
> server
> > > (192.168.0.13) running 2.6.24 and shows the
> problem. Basically the
> > > behavior is like this:
> > >
> > > 1. The client opens up a big window,
> > > 2. the server sends 19 packets in a row (pkt #14-
> #32 in the trace), but all of them are dropped due to some
> congestion.
> > > 3. The server hits RTO and retransmits pkt #14 in
> #33
> > > 4. The client immediately acks #33 (=#14), and
> the server (seems like to enter F-RTO) expends the window
> and sends *NEW* pkt #35 & #36.=A0 Timeoute is doubled to
> 2*RTO; The client immediately sends two Dup-ack to #35 and
> #36.
> > > 5. after 2*RTO, pkt #15 is retransmitted in #39.
> > > 6. The client immediately acks #39 (=#15) in #40,
> and the server continues to expand the window and sends two
> *NEW* pkt #41 & #42. Now the timeoute is doubled to 4
> *RTO.
> > > 8. After 4*RTO timeout, #16 is retransmitted.
> > > 9....
> > > 10. The above steps repeats for retransmitting
> pkt #16-#32 and each time the timeout is doubled.
> > > 11. It takes a long long time to retransmit all
> the lost packets and before that is done, the client sends a
> RST because of timeout.
> > >
> > > The above behavior looks like F-RTO is in effect.
> And there seems to
> > > be a bug in the TCP's congestion control and
> retransmission algorithm.
> > > Why doesn't the TCP on server (running 2.6.24)
> enter the slow start?
> > > Why should the server take that long to recover
> from a short period
> > > of packet loss?
> > >
> > > Has anyone else noticed similar problem before?
> If my analysis was
> > > wrong, can anyone gives me some pointers to
> what's really wrong and
> > > how to fix it?
>
> Yes, 2.6.24 is an obsoleted version with known wrongs in
> FRTO
> implementation. Fixes never when to 2.6.24 stable series as
> it was
> _already_ obsoleted when the problems where reported and
> found. The
> correct fixes may be found from 2.6.25.7 (.7 iirc) and are
> included from
> 2.6.26 onward too.
>
> Just in case you happen to run ubuntu based kernel from
> that era (of
> course you should be reporting the bug here then...), a
> word of warning:
> it seemed nearly impossible for them to get a simple thing
> like that
> fixed, I haven't been looking if they'd eventually come to
> some sensible
> conclusion in that matter or is it still unresolved (or
> e.g., closed
> without real resolution).
^ permalink raw reply
* [PATCH] drivers/net: ks8851 ethernet network driver - RESUBMIT
From: Choi, David @ 2009-09-25 17:58 UTC (permalink / raw)
To: David Miller; +Cc: greg, netdev, Li, Charles, Choi, jgarzik, shemminger
In-Reply-To: <20090924.163941.156434226.davem@davemloft.net>
Hello David Miller,
This is the re-submission of ks8851 driver. This re-submission fixes up raised issues as followings;
-Remove the unnecessary definitions "#define DEBUG", "#define MALLOC"
-Remove the mutex_lock/unlock because they are redundancy in ks_net_start()
-Add IRQ_NONE in ks_irq() in case that there is no IRQ indication in hardware reg.
-Remove the compile warnings in ks_inblk() and ks_outblk(), by changing logic.
(For this, I am not sure because my compile gcc 4.2.1 does NOT output warning messages.)
Subject : [PATCH] drivers/net: ks8851 ethernet network driver - RESUBMIT
From : David J. Choi (david.choi@micrel.com)
Body of the explanation :
This is the first version of ks8851 16bit MLL Ethernet n etwork driver.
Signed-off-by : David J. Choi
Name : David Miller
To : davem@davemloft.net
CC : greg@kroah.com;netdev@vger.kernel.org;choi@kroah.com;jgarzik@redhat.com;shemminger@vyatta.com
kernel-version : 2.6.31.rc3
Tested-by : David J. Choi
-----------------------------------------------
--- linux-2.6.31-rc3/drivers/net/ks8851_mll.c.orig 2009-09-25 09:48:09.000000000 -0700
+++ linux-2.6.31-rc3/drivers/net/ks8851_mll.c 2009-09-25 09:49:26.000000000 -0700
@@ -0,0 +1,1697 @@
+/**
+ * drivers/net/ks8851_mll.c
+ * Copyright (c) 2009 Micrel Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/**
+ * Supports:
+ * KS8851 16bit MLL chip from Micrel Inc.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
+#include <linux/cache.h>
+#include <linux/crc32.h>
+#include <linux/mii.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+
+#define DRV_NAME "ks8851_mll"
+
+static u8 KS_DEFAULT_MAC_ADDRESS[] = { 0x00, 0x10, 0xA1, 0x86, 0x95, 0x11 };
+#define MAX_RECV_FRAMES 32
+#define MAX_BUF_SIZE 2048
+#define TX_BUF_SIZE 2000
+#define RX_BUF_SIZE 2000
+
+#define KS_CCR 0x08
+#define CCR_EEPROM (1 << 9)
+#define CCR_SPI (1 << 8)
+#define CCR_8BIT (1 << 7)
+#define CCR_16BIT (1 << 6)
+#define CCR_32BIT (1 << 5)
+#define CCR_SHARED (1 << 4)
+#define CCR_32PIN (1 << 0)
+
+/* MAC address registers */
+#define KS_MARL 0x10
+#define KS_MARM 0x12
+#define KS_MARH 0x14
+
+#define KS_OBCR 0x20
+#define OBCR_ODS_16MA (1 << 6)
+
+#define KS_EEPCR 0x22
+#define EEPCR_EESA (1 << 4)
+#define EEPCR_EESB (1 << 3)
+#define EEPCR_EEDO (1 << 2)
+#define EEPCR_EESCK (1 << 1)
+#define EEPCR_EECS (1 << 0)
+
+#define KS_MBIR 0x24
+#define MBIR_TXMBF (1 << 12)
+#define MBIR_TXMBFA (1 << 11)
+#define MBIR_RXMBF (1 << 4)
+#define MBIR_RXMBFA (1 << 3)
+
+#define KS_GRR 0x26
+#define GRR_QMU (1 << 1)
+#define GRR_GSR (1 << 0)
+
+#define KS_WFCR 0x2A
+#define WFCR_MPRXE (1 << 7)
+#define WFCR_WF3E (1 << 3)
+#define WFCR_WF2E (1 << 2)
+#define WFCR_WF1E (1 << 1)
+#define WFCR_WF0E (1 << 0)
+
+#define KS_WF0CRC0 0x30
+#define KS_WF0CRC1 0x32
+#define KS_WF0BM0 0x34
+#define KS_WF0BM1 0x36
+#define KS_WF0BM2 0x38
+#define KS_WF0BM3 0x3A
+
+#define KS_WF1CRC0 0x40
+#define KS_WF1CRC1 0x42
+#define KS_WF1BM0 0x44
+#define KS_WF1BM1 0x46
+#define KS_WF1BM2 0x48
+#define KS_WF1BM3 0x4A
+
+#define KS_WF2CRC0 0x50
+#define KS_WF2CRC1 0x52
+#define KS_WF2BM0 0x54
+#define KS_WF2BM1 0x56
+#define KS_WF2BM2 0x58
+#define KS_WF2BM3 0x5A
+
+#define KS_WF3CRC0 0x60
+#define KS_WF3CRC1 0x62
+#define KS_WF3BM0 0x64
+#define KS_WF3BM1 0x66
+#define KS_WF3BM2 0x68
+#define KS_WF3BM3 0x6A
+
+#define KS_TXCR 0x70
+#define TXCR_TCGICMP (1 << 8)
+#define TXCR_TCGUDP (1 << 7)
+#define TXCR_TCGTCP (1 << 6)
+#define TXCR_TCGIP (1 << 5)
+#define TXCR_FTXQ (1 << 4)
+#define TXCR_TXFCE (1 << 3)
+#define TXCR_TXPE (1 << 2)
+#define TXCR_TXCRC (1 << 1)
+#define TXCR_TXE (1 << 0)
+
+#define KS_TXSR 0x72
+#define TXSR_TXLC (1 << 13)
+#define TXSR_TXMC (1 << 12)
+#define TXSR_TXFID_MASK (0x3f << 0)
+#define TXSR_TXFID_SHIFT (0)
+#define TXSR_TXFID_GET(_v) (((_v) >> 0) & 0x3f)
+
+
+#define KS_RXCR1 0x74
+#define RXCR1_FRXQ (1 << 15)
+#define RXCR1_RXUDPFCC (1 << 14)
+#define RXCR1_RXTCPFCC (1 << 13)
+#define RXCR1_RXIPFCC (1 << 12)
+#define RXCR1_RXPAFMA (1 << 11)
+#define RXCR1_RXFCE (1 << 10)
+#define RXCR1_RXEFE (1 << 9)
+#define RXCR1_RXMAFMA (1 << 8)
+#define RXCR1_RXBE (1 << 7)
+#define RXCR1_RXME (1 << 6)
+#define RXCR1_RXUE (1 << 5)
+#define RXCR1_RXAE (1 << 4)
+#define RXCR1_RXINVF (1 << 1)
+#define RXCR1_RXE (1 << 0)
+#define RXCR1_FILTER_MASK (RXCR1_RXINVF | RXCR1_RXAE | \
+ RXCR1_RXMAFMA | RXCR1_RXPAFMA)
+
+#define KS_RXCR2 0x76
+#define RXCR2_SRDBL_MASK (0x7 << 5)
+#define RXCR2_SRDBL_SHIFT (5)
+#define RXCR2_SRDBL_4B (0x0 << 5)
+#define RXCR2_SRDBL_8B (0x1 << 5)
+#define RXCR2_SRDBL_16B (0x2 << 5)
+#define RXCR2_SRDBL_32B (0x3 << 5)
+/* #define RXCR2_SRDBL_FRAME (0x4 << 5) */
+#define RXCR2_IUFFP (1 << 4)
+#define RXCR2_RXIUFCEZ (1 << 3)
+#define RXCR2_UDPLFE (1 << 2)
+#define RXCR2_RXICMPFCC (1 << 1)
+#define RXCR2_RXSAF (1 << 0)
+
+#define KS_TXMIR 0x78
+
+#define KS_RXFHSR 0x7C
+#define RXFSHR_RXFV (1 << 15)
+#define RXFSHR_RXICMPFCS (1 << 13)
+#define RXFSHR_RXIPFCS (1 << 12)
+#define RXFSHR_RXTCPFCS (1 << 11)
+#define RXFSHR_RXUDPFCS (1 << 10)
+#define RXFSHR_RXBF (1 << 7)
+#define RXFSHR_RXMF (1 << 6)
+#define RXFSHR_RXUF (1 << 5)
+#define RXFSHR_RXMR (1 << 4)
+#define RXFSHR_RXFT (1 << 3)
+#define RXFSHR_RXFTL (1 << 2)
+#define RXFSHR_RXRF (1 << 1)
+#define RXFSHR_RXCE (1 << 0)
+#define RXFSHR_ERR (RXFSHR_RXCE | RXFSHR_RXRF |\
+ RXFSHR_RXFTL | RXFSHR_RXMR |\
+ RXFSHR_RXICMPFCS | RXFSHR_RXIPFCS |\
+ RXFSHR_RXTCPFCS)
+#define KS_RXFHBCR 0x7E
+#define RXFHBCR_CNT_MASK 0x0FFF
+
+#define KS_TXQCR 0x80
+#define TXQCR_AETFE (1 << 2)
+#define TXQCR_TXQMAM (1 << 1)
+#define TXQCR_METFE (1 << 0)
+
+#define KS_RXQCR 0x82
+#define RXQCR_RXDTTS (1 << 12)
+#define RXQCR_RXDBCTS (1 << 11)
+#define RXQCR_RXFCTS (1 << 10)
+#define RXQCR_RXIPHTOE (1 << 9)
+#define RXQCR_RXDTTE (1 << 7)
+#define RXQCR_RXDBCTE (1 << 6)
+#define RXQCR_RXFCTE (1 << 5)
+#define RXQCR_ADRFE (1 << 4)
+#define RXQCR_SDA (1 << 3)
+#define RXQCR_RRXEF (1 << 0)
+#define RXQCR_CMD_CNTL (RXQCR_RXFCTE|RXQCR_ADRFE)
+
+#define KS_TXFDPR 0x84
+#define TXFDPR_TXFPAI (1 << 14)
+#define TXFDPR_TXFP_MASK (0x7ff << 0)
+#define TXFDPR_TXFP_SHIFT (0)
+
+#define KS_RXFDPR 0x86
+#define RXFDPR_RXFPAI (1 << 14)
+
+#define KS_RXDTTR 0x8C
+#define KS_RXDBCTR 0x8E
+
+#define KS_IER 0x90
+#define KS_ISR 0x92
+#define IRQ_LCI (1 << 15)
+#define IRQ_TXI (1 << 14)
+#define IRQ_RXI (1 << 13)
+#define IRQ_RXOI (1 << 11)
+#define IRQ_TXPSI (1 << 9)
+#define IRQ_RXPSI (1 << 8)
+#define IRQ_TXSAI (1 << 6)
+#define IRQ_RXWFDI (1 << 5)
+#define IRQ_RXMPDI (1 << 4)
+#define IRQ_LDI (1 << 3)
+#define IRQ_EDI (1 << 2)
+#define IRQ_SPIBEI (1 << 1)
+#define IRQ_DEDI (1 << 0)
+
+#define KS_RXFCTR 0x9C
+#define RXFCTR_THRESHOLD_MASK 0x00FF
+
+#define KS_RXFC 0x9D
+#define RXFCTR_RXFC_MASK (0xff << 8)
+#define RXFCTR_RXFC_SHIFT (8)
+#define RXFCTR_RXFC_GET(_v) (((_v) >> 8) & 0xff)
+#define RXFCTR_RXFCT_MASK (0xff << 0)
+#define RXFCTR_RXFCT_SHIFT (0)
+
+#define KS_TXNTFSR 0x9E
+
+#define KS_MAHTR0 0xA0
+#define KS_MAHTR1 0xA2
+#define KS_MAHTR2 0xA4
+#define KS_MAHTR3 0xA6
+
+#define KS_FCLWR 0xB0
+#define KS_FCHWR 0xB2
+#define KS_FCOWR 0xB4
+
+#define KS_CIDER 0xC0
+#define CIDER_ID 0x8870
+#define CIDER_REV_MASK (0x7 << 1)
+#define CIDER_REV_SHIFT (1)
+#define CIDER_REV_GET(_v) (((_v) >> 1) & 0x7)
+
+#define KS_CGCR 0xC6
+#define KS_IACR 0xC8
+#define IACR_RDEN (1 << 12)
+#define IACR_TSEL_MASK (0x3 << 10)
+#define IACR_TSEL_SHIFT (10)
+#define IACR_TSEL_MIB (0x3 << 10)
+#define IACR_ADDR_MASK (0x1f << 0)
+#define IACR_ADDR_SHIFT (0)
+
+#define KS_IADLR 0xD0
+#define KS_IAHDR 0xD2
+
+#define KS_PMECR 0xD4
+#define PMECR_PME_DELAY (1 << 14)
+#define PMECR_PME_POL (1 << 12)
+#define PMECR_WOL_WAKEUP (1 << 11)
+#define PMECR_WOL_MAGICPKT (1 << 10)
+#define PMECR_WOL_LINKUP (1 << 9)
+#define PMECR_WOL_ENERGY (1 << 8)
+#define PMECR_AUTO_WAKE_EN (1 << 7)
+#define PMECR_WAKEUP_NORMAL (1 << 6)
+#define PMECR_WKEVT_MASK (0xf << 2)
+#define PMECR_WKEVT_SHIFT (2)
+#define PMECR_WKEVT_GET(_v) (((_v) >> 2) & 0xf)
+#define PMECR_WKEVT_ENERGY (0x1 << 2)
+#define PMECR_WKEVT_LINK (0x2 << 2)
+#define PMECR_WKEVT_MAGICPKT (0x4 << 2)
+#define PMECR_WKEVT_FRAME (0x8 << 2)
+#define PMECR_PM_MASK (0x3 << 0)
+#define PMECR_PM_SHIFT (0)
+#define PMECR_PM_NORMAL (0x0 << 0)
+#define PMECR_PM_ENERGY (0x1 << 0)
+#define PMECR_PM_SOFTDOWN (0x2 << 0)
+#define PMECR_PM_POWERSAVE (0x3 << 0)
+
+/* Standard MII PHY data */
+#define KS_P1MBCR 0xE4
+#define P1MBCR_FORCE_FDX (1 << 8)
+
+#define KS_P1MBSR 0xE6
+#define P1MBSR_AN_COMPLETE (1 << 5)
+#define P1MBSR_AN_CAPABLE (1 << 3)
+#define P1MBSR_LINK_UP (1 << 2)
+
+#define KS_PHY1ILR 0xE8
+#define KS_PHY1IHR 0xEA
+#define KS_P1ANAR 0xEC
+#define KS_P1ANLPR 0xEE
+
+#define KS_P1SCLMD 0xF4
+#define P1SCLMD_LEDOFF (1 << 15)
+#define P1SCLMD_TXIDS (1 << 14)
+#define P1SCLMD_RESTARTAN (1 << 13)
+#define P1SCLMD_DISAUTOMDIX (1 << 10)
+#define P1SCLMD_FORCEMDIX (1 << 9)
+#define P1SCLMD_AUTONEGEN (1 << 7)
+#define P1SCLMD_FORCE100 (1 << 6)
+#define P1SCLMD_FORCEFDX (1 << 5)
+#define P1SCLMD_ADV_FLOW (1 << 4)
+#define P1SCLMD_ADV_100BT_FDX (1 << 3)
+#define P1SCLMD_ADV_100BT_HDX (1 << 2)
+#define P1SCLMD_ADV_10BT_FDX (1 << 1)
+#define P1SCLMD_ADV_10BT_HDX (1 << 0)
+
+#define KS_P1CR 0xF6
+#define P1CR_HP_MDIX (1 << 15)
+#define P1CR_REV_POL (1 << 13)
+#define P1CR_OP_100M (1 << 10)
+#define P1CR_OP_FDX (1 << 9)
+#define P1CR_OP_MDI (1 << 7)
+#define P1CR_AN_DONE (1 << 6)
+#define P1CR_LINK_GOOD (1 << 5)
+#define P1CR_PNTR_FLOW (1 << 4)
+#define P1CR_PNTR_100BT_FDX (1 << 3)
+#define P1CR_PNTR_100BT_HDX (1 << 2)
+#define P1CR_PNTR_10BT_FDX (1 << 1)
+#define P1CR_PNTR_10BT_HDX (1 << 0)
+
+/* TX Frame control */
+
+#define TXFR_TXIC (1 << 15)
+#define TXFR_TXFID_MASK (0x3f << 0)
+#define TXFR_TXFID_SHIFT (0)
+
+#define KS_P1SR 0xF8
+#define P1SR_HP_MDIX (1 << 15)
+#define P1SR_REV_POL (1 << 13)
+#define P1SR_OP_100M (1 << 10)
+#define P1SR_OP_FDX (1 << 9)
+#define P1SR_OP_MDI (1 << 7)
+#define P1SR_AN_DONE (1 << 6)
+#define P1SR_LINK_GOOD (1 << 5)
+#define P1SR_PNTR_FLOW (1 << 4)
+#define P1SR_PNTR_100BT_FDX (1 << 3)
+#define P1SR_PNTR_100BT_HDX (1 << 2)
+#define P1SR_PNTR_10BT_FDX (1 << 1)
+#define P1SR_PNTR_10BT_HDX (1 << 0)
+
+#define ENUM_BUS_NONE 0
+#define ENUM_BUS_8BIT 1
+#define ENUM_BUS_16BIT 2
+#define ENUM_BUS_32BIT 3
+
+#define MAX_MCAST_LST 32
+#define HW_MCAST_SIZE 8
+#define MAC_ADDR_LEN 6
+
+/**
+ * union ks_tx_hdr - tx header data
+ * @txb: The header as bytes
+ * @txw: The header as 16bit, little-endian words
+ *
+ * A dual representation of the tx header data to allow
+ * access to individual bytes, and to allow 16bit accesses
+ * with 16bit alignment.
+ */
+union ks_tx_hdr {
+ u8 txb[4];
+ __le16 txw[2];
+};
+
+/**
+ * struct ks_net - KS8851 driver private data
+ * @net_device : The network device we're bound to
+ * @hw_addr : start address of data register.
+ * @hw_addr_cmd : start address of command register.
+ * @txh : temporaly buffer to save status/length.
+ * @lock : Lock to ensure that the device is not accessed when busy.
+ * @pdev : Pointer to platform device.
+ * @mii : The MII state information for the mii calls.
+ * @frame_head_info : frame header information for multi-pkt rx.
+ * @statelock : Lock on this structure for tx list.
+ * @msg_enable : The message flags controlling driver output (see ethtool).
+ * @frame_cnt : number of frames received.
+ * @bus_width : i/o bus width.
+ * @irq : irq number assigned to this device.
+ * @rc_rxqcr : Cached copy of KS_RXQCR.
+ * @rc_txcr : Cached copy of KS_TXCR.
+ * @rc_ier : Cached copy of KS_IER.
+ * @sharedbus : Multipex(addr and data bus) mode indicator.
+ * @cmd_reg_cache : command register cached.
+ * @cmd_reg_cache_int : command register cached. Used in the irq handler.
+ * @promiscuous : promiscuous mode indicator.
+ * @all_mcast : mutlicast indicator.
+ * @mcast_lst_size : size of multicast list.
+ * @mcast_lst : multicast list.
+ * @mcast_bits : multicast enabed.
+ * @mac_addr : MAC address assigned to this device.
+ * @fid : frame id.
+ * @extra_byte : number of extra byte prepended rx pkt.
+ * @enabled : indicator this device works.
+ *
+ * The @lock ensures that the chip is protected when certain operations are
+ * in progress. When the read or write packet transfer is in progress, most
+ * of the chip registers are not accessible until the transfer is finished and
+ * the DMA has been de-asserted.
+ *
+ * The @statelock is used to protect information in the structure which may
+ * need to be accessed via several sources, such as the network driver layer
+ * or one of the work queues.
+ *
+ */
+
+/* Receive multiplex framer header info */
+struct type_frame_head {
+ u16 sts; /* Frame status */
+ u16 len; /* Byte count */
+};
+
+struct ks_net {
+ struct net_device *netdev;
+ void __iomem *hw_addr;
+ void __iomem *hw_addr_cmd;
+ union ks_tx_hdr txh ____cacheline_aligned;
+ struct mutex lock; /* spinlock to be interrupt safe */
+ struct platform_device *pdev;
+ struct mii_if_info mii;
+ struct type_frame_head *frame_head_info;
+ spinlock_t statelock;
+ u32 msg_enable;
+ u32 frame_cnt;
+ int bus_width;
+ int irq;
+
+ u16 rc_rxqcr;
+ u16 rc_txcr;
+ u16 rc_ier;
+ u16 sharedbus;
+ u16 cmd_reg_cache;
+ u16 cmd_reg_cache_int;
+ u16 promiscuous;
+ u16 all_mcast;
+ u16 mcast_lst_size;
+ u8 mcast_lst[MAX_MCAST_LST][MAC_ADDR_LEN];
+ u8 mcast_bits[HW_MCAST_SIZE];
+ u8 mac_addr[6];
+ u8 fid;
+ u8 extra_byte;
+ u8 enabled;
+};
+
+static int msg_enable;
+
+#define ks_info(_ks, _msg...) dev_info(&(_ks)->pdev->dev, _msg)
+#define ks_warn(_ks, _msg...) dev_warn(&(_ks)->pdev->dev, _msg)
+#define ks_dbg(_ks, _msg...) dev_dbg(&(_ks)->pdev->dev, _msg)
+#define ks_err(_ks, _msg...) dev_err(&(_ks)->pdev->dev, _msg)
+
+#define BE3 0x8000 /* Byte Enable 3 */
+#define BE2 0x4000 /* Byte Enable 2 */
+#define BE1 0x2000 /* Byte Enable 1 */
+#define BE0 0x1000 /* Byte Enable 0 */
+
+/**
+ * register read/write calls.
+ *
+ * All these calls issue transactions to access the chip's registers. They
+ * all require that the necessary lock is held to prevent accesses when the
+ * chip is busy transfering packet data (RX/TX FIFO accesses).
+ */
+
+/**
+ * ks_rdreg8 - read 8 bit register from device
+ * @ks : The chip information
+ * @offset: The register address
+ *
+ * Read a 8bit register from the chip, returning the result
+ */
+static u8 ks_rdreg8(struct ks_net *ks, int offset)
+{
+ u16 data;
+ u8 shift_bit = offset & 0x03;
+ u8 shift_data = (offset & 1) << 3;
+ ks->cmd_reg_cache = (u16) offset | (u16)(BE0 << shift_bit);
+ iowrite16(ks->cmd_reg_cache, ks->hw_addr_cmd);
+ data = ioread16(ks->hw_addr);
+ return (u8)(data >> shift_data);
+}
+
+/**
+ * ks_rdreg16 - read 16 bit register from device
+ * @ks : The chip information
+ * @offset: The register address
+ *
+ * Read a 16bit register from the chip, returning the result
+ */
+
+static u16 ks_rdreg16(struct ks_net *ks, int offset)
+{
+ ks->cmd_reg_cache = (u16)offset | ((BE1 | BE0) << (offset & 0x02));
+ iowrite16(ks->cmd_reg_cache, ks->hw_addr_cmd);
+ return ioread16(ks->hw_addr);
+}
+
+/**
+ * ks_wrreg8 - write 8bit register value to chip
+ * @ks: The chip information
+ * @offset: The register address
+ * @value: The value to write
+ *
+ */
+static void ks_wrreg8(struct ks_net *ks, int offset, u8 value)
+{
+ u8 shift_bit = (offset & 0x03);
+ u16 value_write = (u16)(value << ((offset & 1) << 3));
+ ks->cmd_reg_cache = (u16)offset | (BE0 << shift_bit);
+ iowrite16(ks->cmd_reg_cache, ks->hw_addr_cmd);
+ iowrite16(value_write, ks->hw_addr);
+}
+
+/**
+ * ks_wrreg16 - write 16bit register value to chip
+ * @ks: The chip information
+ * @offset: The register address
+ * @value: The value to write
+ *
+ */
+
+static void ks_wrreg16(struct ks_net *ks, int offset, u16 value)
+{
+ ks->cmd_reg_cache = (u16)offset | ((BE1 | BE0) << (offset & 0x02));
+ iowrite16(ks->cmd_reg_cache, ks->hw_addr_cmd);
+ iowrite16(value, ks->hw_addr);
+}
+
+/**
+ * ks_inblk - read a block of data from QMU. This is called after sudo DMA mode enabled.
+ * @ks: The chip state
+ * @wptr: buffer address to save data
+ * @len: length in byte to read
+ *
+ */
+static inline void ks_inblk(struct ks_net *ks, u16 *wptr, u32 len)
+{
+ len >>= 1;
+ while (len--)
+ *wptr++ = (u16)ioread16(ks->hw_addr);
+}
+
+/**
+ * ks_outblk - write data to QMU. This is called after sudo DMA mode enabled.
+ * @ks: The chip information
+ * @wptr: buffer address
+ * @len: length in byte to write
+ *
+ */
+static inline void ks_outblk(struct ks_net *ks, u16 *wptr, u32 len)
+{
+ len >>= 1;
+ while (len--)
+ iowrite16(*wptr++, ks->hw_addr);
+}
+
+/**
+ * ks_tx_fifo_space - return the available hardware buffer size.
+ * @ks: The chip information
+ *
+ */
+static inline u16 ks_tx_fifo_space(struct ks_net *ks)
+{
+ return ks_rdreg16(ks, KS_TXMIR) & 0x1fff;
+}
+
+/**
+ * ks_save_cmd_reg - save the command register from the cache.
+ * @ks: The chip information
+ *
+ */
+static inline void ks_save_cmd_reg(struct ks_net *ks)
+{
+ /*ks8851 MLL has a bug to read back the command register.
+ * So rely on software to save the content of command register.
+ */
+ ks->cmd_reg_cache_int = ks->cmd_reg_cache;
+}
+
+/**
+ * ks_restore_cmd_reg - restore the command register from the cache and
+ * write to hardware register.
+ * @ks: The chip information
+ *
+ */
+static inline void ks_restore_cmd_reg(struct ks_net *ks)
+{
+ ks->cmd_reg_cache = ks->cmd_reg_cache_int;
+ iowrite16(ks->cmd_reg_cache, ks->hw_addr_cmd);
+}
+
+/**
+ * ks_set_powermode - set power mode of the device
+ * @ks: The chip information
+ * @pwrmode: The power mode value to write to KS_PMECR.
+ *
+ * Change the power mode of the chip.
+ */
+static void ks_set_powermode(struct ks_net *ks, unsigned pwrmode)
+{
+ unsigned pmecr;
+
+ if (netif_msg_hw(ks))
+ ks_dbg(ks, "setting power mode %d\n", pwrmode);
+
+ ks_rdreg16(ks, KS_GRR);
+ pmecr = ks_rdreg16(ks, KS_PMECR);
+ pmecr &= ~PMECR_PM_MASK;
+ pmecr |= pwrmode;
+
+ ks_wrreg16(ks, KS_PMECR, pmecr);
+}
+
+/**
+ * ks_read_config - read chip configuration of bus width.
+ * @ks: The chip information
+ *
+ */
+static void ks_read_config(struct ks_net *ks)
+{
+ u16 reg_data = 0;
+
+ /* Regardless of bus width, 8 bit read should always work.*/
+ reg_data = ks_rdreg8(ks, KS_CCR) & 0x00FF;
+ reg_data |= ks_rdreg8(ks, KS_CCR+1) << 8;
+
+ /* addr/data bus are multiplexed */
+ ks->sharedbus = (reg_data & CCR_SHARED) == CCR_SHARED;
+
+ /* There are garbage data when reading data from QMU,
+ depending on bus-width.
+ */
+
+ if (reg_data & CCR_8BIT) {
+ ks->bus_width = ENUM_BUS_8BIT;
+ ks->extra_byte = 1;
+ } else if (reg_data & CCR_16BIT) {
+ ks->bus_width = ENUM_BUS_16BIT;
+ ks->extra_byte = 2;
+ } else {
+ ks->bus_width = ENUM_BUS_32BIT;
+ ks->extra_byte = 4;
+ }
+}
+
+/**
+ * ks_soft_reset - issue one of the soft reset to the device
+ * @ks: The device state.
+ * @op: The bit(s) to set in the GRR
+ *
+ * Issue the relevant soft-reset command to the device's GRR register
+ * specified by @op.
+ *
+ * Note, the delays are in there as a caution to ensure that the reset
+ * has time to take effect and then complete. Since the datasheet does
+ * not currently specify the exact sequence, we have chosen something
+ * that seems to work with our device.
+ */
+static void ks_soft_reset(struct ks_net *ks, unsigned op)
+{
+ /* Disable interrupt first */
+ ks_wrreg16(ks, KS_IER, 0x0000);
+ ks_wrreg16(ks, KS_GRR, op);
+ mdelay(10); /* wait a short time to effect reset */
+ ks_wrreg16(ks, KS_GRR, 0);
+ mdelay(1); /* wait for condition to clear */
+}
+
+
+/**
+ * ks_read_qmu - read 1 pkt data from the QMU.
+ * @ks: The chip information
+ * @buf: buffer address to save 1 pkt
+ * @len: Pkt length
+ * Here is the sequence to read 1 pkt:
+ * 1. set sudo DMA mode
+ * 2. read prepend data
+ * 3. read pkt data
+ * 4. reset sudo DMA Mode
+ */
+static inline void ks_read_qmu(struct ks_net *ks, u16 *buf, u32 len)
+{
+ u32 r = ks->extra_byte & 0x1 ;
+ u32 w = ks->extra_byte - r;
+
+ /* 1. set sudo DMA mode */
+ ks_wrreg16(ks, KS_RXFDPR, RXFDPR_RXFPAI);
+ ks_wrreg8(ks, KS_RXQCR, (ks->rc_rxqcr | RXQCR_SDA) & 0xff);
+
+ /* 2. read prepend data */
+ /**
+ * read 4 + extra bytes and discard them.
+ * extra bytes for dummy, 2 for status, 2 for len
+ */
+
+ /* use likely(r) for 8 bit access for performance */
+ if (unlikely(r))
+ ioread8(ks->hw_addr);
+ ks_inblk(ks, buf, w + 2 + 2);
+
+ /* 3. read pkt data */
+ ks_inblk(ks, buf, ALIGN(len, 4));
+
+ /* 4. reset sudo DMA Mode */
+ ks_wrreg8(ks, KS_RXQCR, ks->rc_rxqcr);
+}
+
+/**
+ * ks_rcv - read multiple pkts data from the QMU.
+ * @ks: The chip information
+ * @netdev: The network device being opened.
+ *
+ * Read all of header information before reading pkt content.
+ * It is not allowed only port of pkts in QMU after issuing
+ * interrupt ack.
+ */
+static void ks_rcv(struct ks_net *ks, struct net_device *netdev)
+{
+ u32 i;
+ struct type_frame_head *frame_hdr = ks->frame_head_info;
+ struct sk_buff *skb;
+
+ ks->frame_cnt = ks_rdreg16(ks, KS_RXFCTR) >> 8;
+
+ /* read all header information */
+ for (i = 0; i < ks->frame_cnt; i++) {
+ /* Checking Received packet status */
+ frame_hdr->sts = ks_rdreg16(ks, KS_RXFHSR);
+ /* Get packet len from hardware */
+ frame_hdr->len = ks_rdreg16(ks, KS_RXFHBCR);
+ frame_hdr++;
+ }
+
+ frame_hdr = ks->frame_head_info;
+ while (ks->frame_cnt--) {
+ skb = dev_alloc_skb(frame_hdr->len + 16);
+ if (likely(skb && (frame_hdr->sts & RXFSHR_RXFV) &&
+ (frame_hdr->len < RX_BUF_SIZE) && frame_hdr->len)) {
+ skb_reserve(skb, 2);
+ /* read data block including CRC 4 bytes */
+ ks_read_qmu(ks, (u16 *)skb->data, frame_hdr->len + 4);
+ skb_put(skb, frame_hdr->len);
+ skb->dev = netdev;
+ skb->protocol = eth_type_trans(skb, netdev);
+ netif_rx(skb);
+ } else {
+ printk(KERN_ERR "%s: err:skb alloc\n", __func__);
+ ks_wrreg16(ks, KS_RXQCR, (ks->rc_rxqcr | RXQCR_RRXEF));
+ if (skb)
+ dev_kfree_skb_irq(skb);
+ }
+ frame_hdr++;
+ }
+}
+
+/**
+ * ks_update_link_status - link status update.
+ * @netdev: The network device being opened.
+ * @ks: The chip information
+ *
+ */
+
+static void ks_update_link_status(struct net_device *netdev, struct ks_net *ks)
+{
+ /* check the status of the link */
+ u32 link_up_status;
+ if (ks_rdreg16(ks, KS_P1SR) & P1SR_LINK_GOOD) {
+ netif_carrier_on(netdev);
+ link_up_status = true;
+ } else {
+ netif_carrier_off(netdev);
+ link_up_status = false;
+ }
+ if (netif_msg_link(ks))
+ ks_dbg(ks, "%s: %s\n",
+ __func__, link_up_status ? "UP" : "DOWN");
+}
+
+/**
+ * ks_irq - device interrupt handler
+ * @irq: Interrupt number passed from the IRQ hnalder.
+ * @pw: The private word passed to register_irq(), our struct ks_net.
+ *
+ * This is the handler invoked to find out what happened
+ *
+ * Read the interrupt status, work out what needs to be done and then clear
+ * any of the interrupts that are not needed.
+ */
+
+static irqreturn_t ks_irq(int irq, void *pw)
+{
+ struct ks_net *ks = pw;
+ struct net_device *netdev = ks->netdev;
+ u16 status;
+
+ /*this should be the first in IRQ handler */
+ ks_save_cmd_reg(ks);
+
+ status = ks_rdreg16(ks, KS_ISR);
+ if (unlikely(!status)) {
+ ks_restore_cmd_reg(ks);
+ return IRQ_NONE;
+ }
+
+ ks_wrreg16(ks, KS_ISR, status);
+
+ if (likely(status & IRQ_RXI))
+ ks_rcv(ks, netdev);
+
+ if (unlikely(status & IRQ_LCI))
+ ks_update_link_status(netdev, ks);
+
+ if (unlikely(status & IRQ_TXI))
+ netif_wake_queue(netdev);
+
+ if (unlikely(status & IRQ_LDI)) {
+
+ u16 pmecr = ks_rdreg16(ks, KS_PMECR);
+ pmecr &= ~PMECR_WKEVT_MASK;
+ ks_wrreg16(ks, KS_PMECR, pmecr | PMECR_WKEVT_LINK);
+ }
+
+ /* this should be the last in IRQ handler*/
+ ks_restore_cmd_reg(ks);
+ return IRQ_HANDLED;
+}
+
+
+/**
+ * ks_net_open - open network device
+ * @netdev: The network device being opened.
+ *
+ * Called when the network device is marked active, such as a user executing
+ * 'ifconfig up' on the device.
+ */
+static int ks_net_open(struct net_device *netdev)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ int err;
+
+#define KS_INT_FLAGS (IRQF_DISABLED|IRQF_TRIGGER_LOW)
+ /* lock the card, even if we may not actually do anything
+ * else at the moment.
+ */
+
+ if (netif_msg_ifup(ks))
+ ks_dbg(ks, "%s - entry\n", __func__);
+
+ /* reset the HW */
+ err = request_irq(ks->irq, ks_irq, KS_INT_FLAGS, DRV_NAME, ks);
+
+ if (err) {
+ printk(KERN_ERR "Failed to request IRQ: %d: %d\n",
+ ks->irq, err);
+ return err;
+ }
+
+ if (netif_msg_ifup(ks))
+ ks_dbg(ks, "network device %s up\n", netdev->name);
+
+ return 0;
+}
+
+/**
+ * ks_net_stop - close network device
+ * @netdev: The device being closed.
+ *
+ * Called to close down a network device which has been active. Cancell any
+ * work, shutdown the RX and TX process and then place the chip into a low
+ * power state whilst it is not being used.
+ */
+static int ks_net_stop(struct net_device *netdev)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+
+ if (netif_msg_ifdown(ks))
+ ks_info(ks, "%s: shutting down\n", netdev->name);
+
+ netif_stop_queue(netdev);
+
+ kfree(ks->frame_head_info);
+
+ mutex_lock(&ks->lock);
+
+ /* turn off the IRQs and ack any outstanding */
+ ks_wrreg16(ks, KS_IER, 0x0000);
+ ks_wrreg16(ks, KS_ISR, 0xffff);
+
+ /* shutdown RX process */
+ ks_wrreg16(ks, KS_RXCR1, 0x0000);
+
+ /* shutdown TX process */
+ ks_wrreg16(ks, KS_TXCR, 0x0000);
+
+ /* set powermode to soft power down to save power */
+ ks_set_powermode(ks, PMECR_PM_SOFTDOWN);
+ free_irq(ks->irq, netdev);
+ mutex_unlock(&ks->lock);
+ return 0;
+}
+
+
+/**
+ * ks_write_qmu - write 1 pkt data to the QMU.
+ * @ks: The chip information
+ * @pdata: buffer address to save 1 pkt
+ * @len: Pkt length in byte
+ * Here is the sequence to write 1 pkt:
+ * 1. set sudo DMA mode
+ * 2. write status/length
+ * 3. write pkt data
+ * 4. reset sudo DMA Mode
+ * 5. reset sudo DMA mode
+ * 6. Wait until pkt is out
+ */
+static void ks_write_qmu(struct ks_net *ks, u8 *pdata, u16 len)
+{
+ unsigned fid = ks->fid;
+
+ fid = ks->fid;
+ ks->fid = (ks->fid + 1) & TXFR_TXFID_MASK;
+
+ /* reduce the tx interrupt occurrances. */
+ if (!fid)
+ fid |= TXFR_TXIC; /* irq on completion */
+
+ /* start header at txb[0] to align txw entries */
+ ks->txh.txw[0] = cpu_to_le16(fid);
+ ks->txh.txw[1] = cpu_to_le16(len);
+
+ /* 1. set sudo-DMA mode */
+ ks_wrreg8(ks, KS_RXQCR, (ks->rc_rxqcr | RXQCR_SDA) & 0xff);
+ /* 2. write status/lenth info */
+ ks_outblk(ks, ks->txh.txw, 4);
+ /* 3. write pkt data */
+ ks_outblk(ks, (u16 *)pdata, ALIGN(len, 4));
+ /* 4. reset sudo-DMA mode */
+ ks_wrreg8(ks, KS_RXQCR, ks->rc_rxqcr);
+ /* 5. Enqueue Tx(move the pkt from TX buffer into TXQ) */
+ ks_wrreg16(ks, KS_TXQCR, TXQCR_METFE);
+ /* 6. wait until TXQCR_METFE is auto-cleared */
+ while (ks_rdreg16(ks, KS_TXQCR) & TXQCR_METFE)
+ ;
+}
+
+static void ks_disable_int(struct ks_net *ks)
+{
+ ks_wrreg16(ks, KS_IER, 0x0000);
+} /* ks_disable_int */
+
+static void ks_enable_int(struct ks_net *ks)
+{
+ ks_wrreg16(ks, KS_IER, ks->rc_ier);
+} /* ks_enable_int */
+
+/**
+ * ks_start_xmit - transmit packet
+ * @skb : The buffer to transmit
+ * @netdev : The device used to transmit the packet.
+ *
+ * Called by the network layer to transmit the @skb.
+ * spin_lock_irqsave is required because tx and rx should be mutual exclusive.
+ * So while tx is in-progress, prevent IRQ interrupt from happenning.
+ */
+static int ks_start_xmit(struct sk_buff *skb, struct net_device *netdev)
+{
+ int retv = NETDEV_TX_OK;
+ struct ks_net *ks = netdev_priv(netdev);
+
+ disable_irq(netdev->irq);
+ ks_disable_int(ks);
+ spin_lock(&ks->statelock);
+
+ /* Extra space are required:
+ * 4 byte for alignment, 4 for status/length, 4 for CRC
+ */
+
+ if (likely(ks_tx_fifo_space(ks) >= skb->len + 12)) {
+ ks_write_qmu(ks, skb->data, skb->len);
+ dev_kfree_skb(skb);
+ } else
+ retv = NETDEV_TX_BUSY;
+ spin_unlock(&ks->statelock);
+ ks_enable_int(ks);
+ enable_irq(netdev->irq);
+ return retv;
+}
+
+/**
+ * ks_start_rx - ready to serve pkts
+ * @ks : The chip information
+ *
+ */
+static void ks_start_rx(struct ks_net *ks)
+{
+ u16 cntl;
+
+ /* Enables QMU Receive (RXCR1). */
+ cntl = ks_rdreg16(ks, KS_RXCR1);
+ cntl |= RXCR1_RXE ;
+ ks_wrreg16(ks, KS_RXCR1, cntl);
+} /* ks_start_rx */
+
+/**
+ * ks_stop_rx - stop to serve pkts
+ * @ks : The chip information
+ *
+ */
+static void ks_stop_rx(struct ks_net *ks)
+{
+ u16 cntl;
+
+ /* Disables QMU Receive (RXCR1). */
+ cntl = ks_rdreg16(ks, KS_RXCR1);
+ cntl &= ~RXCR1_RXE ;
+ ks_wrreg16(ks, KS_RXCR1, cntl);
+
+} /* ks_stop_rx */
+
+static unsigned long const ethernet_polynomial = 0x04c11db7U;
+
+static unsigned long ether_gen_crc(int length, u8 *data)
+{
+ long crc = -1;
+ while (--length >= 0) {
+ u8 current_octet = *data++;
+ int bit;
+
+ for (bit = 0; bit < 8; bit++, current_octet >>= 1) {
+ crc = (crc << 1) ^
+ ((crc < 0) ^ (current_octet & 1) ?
+ ethernet_polynomial : 0);
+ }
+ }
+ return (unsigned long)crc;
+} /* ether_gen_crc */
+
+/**
+* ks_set_grpaddr - set multicast information
+* @ks : The chip information
+*/
+
+static void ks_set_grpaddr(struct ks_net *ks)
+{
+ u8 i;
+ u32 index, position, value;
+
+ memset(ks->mcast_bits, 0, sizeof(u8) * HW_MCAST_SIZE);
+
+ for (i = 0; i < ks->mcast_lst_size; i++) {
+ position = (ether_gen_crc(6, ks->mcast_lst[i]) >> 26) & 0x3f;
+ index = position >> 3;
+ value = 1 << (position & 7);
+ ks->mcast_bits[index] |= (u8)value;
+ }
+
+ for (i = 0; i < HW_MCAST_SIZE; i++) {
+ if (i & 1) {
+ ks_wrreg16(ks, (u16)((KS_MAHTR0 + i) & ~1),
+ (ks->mcast_bits[i] << 8) |
+ ks->mcast_bits[i - 1]);
+ }
+ }
+} /* ks_set_grpaddr */
+
+/*
+* ks_clear_mcast - clear multicast information
+*
+* @ks : The chip information
+* This routine removes all mcast addresses set in the hardware.
+*/
+
+static void ks_clear_mcast(struct ks_net *ks)
+{
+ u16 i, mcast_size;
+ for (i = 0; i < HW_MCAST_SIZE; i++)
+ ks->mcast_bits[i] = 0;
+
+ mcast_size = HW_MCAST_SIZE >> 2;
+ for (i = 0; i < mcast_size; i++)
+ ks_wrreg16(ks, KS_MAHTR0 + (2*i), 0);
+}
+
+static void ks_set_promis(struct ks_net *ks, u16 promiscuous_mode)
+{
+ u16 cntl;
+ ks->promiscuous = promiscuous_mode;
+ ks_stop_rx(ks); /* Stop receiving for reconfiguration */
+ cntl = ks_rdreg16(ks, KS_RXCR1);
+
+ cntl &= ~RXCR1_FILTER_MASK;
+ if (promiscuous_mode)
+ /* Enable Promiscuous mode */
+ cntl |= RXCR1_RXAE | RXCR1_RXINVF;
+ else
+ /* Disable Promiscuous mode (default normal mode) */
+ cntl |= RXCR1_RXPAFMA;
+
+ ks_wrreg16(ks, KS_RXCR1, cntl);
+
+ if (ks->enabled)
+ ks_start_rx(ks);
+
+} /* ks_set_promis */
+
+static void ks_set_mcast(struct ks_net *ks, u16 mcast)
+{
+ u16 cntl;
+
+ ks->all_mcast = mcast;
+ ks_stop_rx(ks); /* Stop receiving for reconfiguration */
+ cntl = ks_rdreg16(ks, KS_RXCR1);
+ cntl &= ~RXCR1_FILTER_MASK;
+ if (mcast)
+ /* Enable "Perfect with Multicast address passed mode" */
+ cntl |= (RXCR1_RXAE | RXCR1_RXMAFMA | RXCR1_RXPAFMA);
+ else
+ /**
+ * Disable "Perfect with Multicast address passed
+ * mode" (normal mode).
+ */
+ cntl |= RXCR1_RXPAFMA;
+
+ ks_wrreg16(ks, KS_RXCR1, cntl);
+
+ if (ks->enabled)
+ ks_start_rx(ks);
+} /* ks_set_mcast */
+
+static void ks_set_rx_mode(struct net_device *netdev)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ struct dev_mc_list *ptr;
+
+ /* Turn on/off promiscuous mode. */
+ if ((netdev->flags & IFF_PROMISC) == IFF_PROMISC)
+ ks_set_promis(ks,
+ (u16)((netdev->flags & IFF_PROMISC) == IFF_PROMISC));
+ /* Turn on/off all mcast mode. */
+ else if ((netdev->flags & IFF_ALLMULTI) == IFF_ALLMULTI)
+ ks_set_mcast(ks,
+ (u16)((netdev->flags & IFF_ALLMULTI) == IFF_ALLMULTI));
+ else
+ ks_set_promis(ks, false);
+
+ if ((netdev->flags & IFF_MULTICAST) && netdev->mc_count) {
+ if (netdev->mc_count <= MAX_MCAST_LST) {
+ int i = 0;
+ for (ptr = netdev->mc_list; ptr; ptr = ptr->next) {
+ if (!(*ptr->dmi_addr & 1))
+ continue;
+ if (i >= MAX_MCAST_LST)
+ break;
+ memcpy(ks->mcast_lst[i++], ptr->dmi_addr,
+ MAC_ADDR_LEN);
+ }
+ ks->mcast_lst_size = (u8)i;
+ ks_set_grpaddr(ks);
+ } else {
+ /**
+ * List too big to support so
+ * turn on all mcast mode.
+ */
+ ks->mcast_lst_size = MAX_MCAST_LST;
+ ks_set_mcast(ks, true);
+ }
+ } else {
+ ks->mcast_lst_size = 0;
+ ks_clear_mcast(ks);
+ }
+} /* ks_set_rx_mode */
+
+static void ks_set_mac(struct ks_net *ks, u8 *data)
+{
+ u16 *pw = (u16 *)data;
+ u16 w, u;
+
+ ks_stop_rx(ks); /* Stop receiving for reconfiguration */
+
+ u = *pw++;
+ w = ((u & 0xFF) << 8) | ((u >> 8) & 0xFF);
+ ks_wrreg16(ks, KS_MARH, w);
+
+ u = *pw++;
+ w = ((u & 0xFF) << 8) | ((u >> 8) & 0xFF);
+ ks_wrreg16(ks, KS_MARM, w);
+
+ u = *pw;
+ w = ((u & 0xFF) << 8) | ((u >> 8) & 0xFF);
+ ks_wrreg16(ks, KS_MARL, w);
+
+ memcpy(ks->mac_addr, data, 6);
+
+ if (ks->enabled)
+ ks_start_rx(ks);
+}
+
+static int ks_set_mac_address(struct net_device *netdev, void *paddr)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ struct sockaddr *addr = paddr;
+ u8 *da;
+
+ memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
+
+ da = (u8 *)netdev->dev_addr;
+
+ ks_set_mac(ks, da);
+ return 0;
+}
+
+static int ks_net_ioctl(struct net_device *netdev, struct ifreq *req, int cmd)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+
+ if (!netif_running(netdev))
+ return -EINVAL;
+
+ return generic_mii_ioctl(&ks->mii, if_mii(req), cmd, NULL);
+}
+
+static const struct net_device_ops ks_netdev_ops = {
+ .ndo_open = ks_net_open,
+ .ndo_stop = ks_net_stop,
+ .ndo_do_ioctl = ks_net_ioctl,
+ .ndo_start_xmit = ks_start_xmit,
+ .ndo_set_mac_address = ks_set_mac_address,
+ .ndo_set_rx_mode = ks_set_rx_mode,
+ .ndo_change_mtu = eth_change_mtu,
+ .ndo_validate_addr = eth_validate_addr,
+};
+
+/* ethtool support */
+
+static void ks_get_drvinfo(struct net_device *netdev,
+ struct ethtool_drvinfo *di)
+{
+ strlcpy(di->driver, DRV_NAME, sizeof(di->driver));
+ strlcpy(di->version, "1.00", sizeof(di->version));
+ strlcpy(di->bus_info, dev_name(netdev->dev.parent),
+ sizeof(di->bus_info));
+}
+
+static u32 ks_get_msglevel(struct net_device *netdev)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ return ks->msg_enable;
+}
+
+static void ks_set_msglevel(struct net_device *netdev, u32 to)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ ks->msg_enable = to;
+}
+
+static int ks_get_settings(struct net_device *netdev, struct ethtool_cmd *cmd)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ return mii_ethtool_gset(&ks->mii, cmd);
+}
+
+static int ks_set_settings(struct net_device *netdev, struct ethtool_cmd *cmd)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ return mii_ethtool_sset(&ks->mii, cmd);
+}
+
+static u32 ks_get_link(struct net_device *netdev)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ return mii_link_ok(&ks->mii);
+}
+
+static int ks_nway_reset(struct net_device *netdev)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ return mii_nway_restart(&ks->mii);
+}
+
+static const struct ethtool_ops ks_ethtool_ops = {
+ .get_drvinfo = ks_get_drvinfo,
+ .get_msglevel = ks_get_msglevel,
+ .set_msglevel = ks_set_msglevel,
+ .get_settings = ks_get_settings,
+ .set_settings = ks_set_settings,
+ .get_link = ks_get_link,
+ .nway_reset = ks_nway_reset,
+};
+
+/* MII interface controls */
+
+/**
+ * ks_phy_reg - convert MII register into a KS8851 register
+ * @reg: MII register number.
+ *
+ * Return the KS8851 register number for the corresponding MII PHY register
+ * if possible. Return zero if the MII register has no direct mapping to the
+ * KS8851 register set.
+ */
+static int ks_phy_reg(int reg)
+{
+ switch (reg) {
+ case MII_BMCR:
+ return KS_P1MBCR;
+ case MII_BMSR:
+ return KS_P1MBSR;
+ case MII_PHYSID1:
+ return KS_PHY1ILR;
+ case MII_PHYSID2:
+ return KS_PHY1IHR;
+ case MII_ADVERTISE:
+ return KS_P1ANAR;
+ case MII_LPA:
+ return KS_P1ANLPR;
+ }
+
+ return 0x0;
+}
+
+/**
+ * ks_phy_read - MII interface PHY register read.
+ * @netdev: The network device the PHY is on.
+ * @phy_addr: Address of PHY (ignored as we only have one)
+ * @reg: The register to read.
+ *
+ * This call reads data from the PHY register specified in @reg. Since the
+ * device does not support all the MII registers, the non-existant values
+ * are always returned as zero.
+ *
+ * We return zero for unsupported registers as the MII code does not check
+ * the value returned for any error status, and simply returns it to the
+ * caller. The mii-tool that the driver was tested with takes any -ve error
+ * as real PHY capabilities, thus displaying incorrect data to the user.
+ */
+static int ks_phy_read(struct net_device *netdev, int phy_addr, int reg)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ int ksreg;
+ int result;
+
+ ksreg = ks_phy_reg(reg);
+ if (!ksreg)
+ return 0x0; /* no error return allowed, so use zero */
+
+ mutex_lock(&ks->lock);
+ result = ks_rdreg16(ks, ksreg);
+ mutex_unlock(&ks->lock);
+
+ return result;
+}
+
+static void ks_phy_write(struct net_device *netdev,
+ int phy, int reg, int value)
+{
+ struct ks_net *ks = netdev_priv(netdev);
+ int ksreg;
+
+ ksreg = ks_phy_reg(reg);
+ if (ksreg) {
+ mutex_lock(&ks->lock);
+ ks_wrreg16(ks, ksreg, value);
+ mutex_unlock(&ks->lock);
+ }
+}
+
+/**
+ * ks_read_selftest - read the selftest memory info.
+ * @ks: The device state
+ *
+ * Read and check the TX/RX memory selftest information.
+ */
+static int ks_read_selftest(struct ks_net *ks)
+{
+ unsigned both_done = MBIR_TXMBF | MBIR_RXMBF;
+ int ret = 0;
+ unsigned rd;
+
+ rd = ks_rdreg16(ks, KS_MBIR);
+
+ if ((rd & both_done) != both_done) {
+ ks_warn(ks, "Memory selftest not finished\n");
+ return 0;
+ }
+
+ if (rd & MBIR_TXMBFA) {
+ ks_err(ks, "TX memory selftest fails\n");
+ ret |= 1;
+ }
+
+ if (rd & MBIR_RXMBFA) {
+ ks_err(ks, "RX memory selftest fails\n");
+ ret |= 2;
+ }
+
+ ks_info(ks, "the selftest passes\n");
+ return ret;
+}
+
+static void ks_disable(struct ks_net *ks)
+{
+ u16 w;
+
+ w = ks_rdreg16(ks, KS_TXCR);
+
+ /* Disables QMU Transmit (TXCR). */
+ w &= ~TXCR_TXE;
+ ks_wrreg16(ks, KS_TXCR, w);
+
+ /* Disables QMU Receive (RXCR1). */
+ w = ks_rdreg16(ks, KS_RXCR1);
+ w &= ~RXCR1_RXE ;
+ ks_wrreg16(ks, KS_RXCR1, w);
+
+ ks->enabled = false;
+
+} /* ks_disable */
+
+static void ks_setup(struct ks_net *ks)
+{
+ u16 w;
+
+ /**
+ * Configure QMU Transmit
+ */
+
+ /* Setup Transmit Frame Data Pointer Auto-Increment (TXFDPR) */
+ ks_wrreg16(ks, KS_TXFDPR, TXFDPR_TXFPAI);
+
+ /* Setup Receive Frame Data Pointer Auto-Increment */
+ ks_wrreg16(ks, KS_RXFDPR, RXFDPR_RXFPAI);
+
+ /* Setup Receive Frame Threshold - 1 frame (RXFCTFC) */
+ ks_wrreg16(ks, KS_RXFCTR, 1 & RXFCTR_THRESHOLD_MASK);
+
+ /* Setup RxQ Command Control (RXQCR) */
+ ks->rc_rxqcr = RXQCR_CMD_CNTL;
+ ks_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr);
+
+ /**
+ * set the force mode to half duplex, default is full duplex
+ * because if the auto-negotiation fails, most switch uses
+ * half-duplex.
+ */
+
+ w = ks_rdreg16(ks, KS_P1MBCR);
+ w &= ~P1MBCR_FORCE_FDX;
+ ks_wrreg16(ks, KS_P1MBCR, w);
+
+ w = TXCR_TXFCE | TXCR_TXPE | TXCR_TXCRC | TXCR_TCGIP;
+ ks_wrreg16(ks, KS_TXCR, w);
+
+ w = RXCR1_RXFCE | RXCR1_RXBE | RXCR1_RXUE;
+
+ if (ks->promiscuous) /* bPromiscuous */
+ w |= (RXCR1_RXAE | RXCR1_RXINVF);
+ else if (ks->all_mcast) /* Multicast address passed mode */
+ w |= (RXCR1_RXAE | RXCR1_RXMAFMA | RXCR1_RXPAFMA);
+ else /* Normal mode */
+ w |= RXCR1_RXPAFMA;
+
+ ks_wrreg16(ks, KS_RXCR1, w);
+} /*ks_setup */
+
+
+static void ks_setup_int(struct ks_net *ks)
+{
+ ks->rc_ier = 0x00;
+ /* Clear the interrupts status of the hardware. */
+ ks_wrreg16(ks, KS_ISR, 0xffff);
+
+ /* Enables the interrupts of the hardware. */
+ ks->rc_ier = (IRQ_LCI | IRQ_TXI | IRQ_RXI);
+} /* ks_setup_int */
+
+void ks_enable(struct ks_net *ks)
+{
+ u16 w;
+
+ w = ks_rdreg16(ks, KS_TXCR);
+ /* Enables QMU Transmit (TXCR). */
+ ks_wrreg16(ks, KS_TXCR, w | TXCR_TXE);
+
+ /*
+ * RX Frame Count Threshold Enable and Auto-Dequeue RXQ Frame
+ * Enable
+ */
+
+ w = ks_rdreg16(ks, KS_RXQCR);
+ ks_wrreg16(ks, KS_RXQCR, w | RXQCR_RXFCTE);
+
+ /* Enables QMU Receive (RXCR1). */
+ w = ks_rdreg16(ks, KS_RXCR1);
+ ks_wrreg16(ks, KS_RXCR1, w | RXCR1_RXE);
+ ks->enabled = true;
+} /* ks_enable */
+
+static int ks_hw_init(struct ks_net *ks)
+{
+#define MHEADER_SIZE (sizeof(struct type_frame_head) * MAX_RECV_FRAMES)
+ ks->promiscuous = 0;
+ ks->all_mcast = 0;
+ ks->mcast_lst_size = 0;
+
+ ks->frame_head_info = (struct type_frame_head *) \
+ kmalloc(MHEADER_SIZE, GFP_KERNEL);
+ if (!ks->frame_head_info) {
+ printk(KERN_ERR "Error: Fail to allocate frame memory\n");
+ return false;
+ }
+
+ ks_set_mac(ks, KS_DEFAULT_MAC_ADDRESS);
+ return true;
+}
+
+
+static int __devinit ks8851_probe(struct platform_device *pdev)
+{
+ int err = -ENOMEM;
+ struct resource *io_d, *io_c;
+ struct net_device *netdev;
+ struct ks_net *ks;
+ u16 id, data;
+
+ io_d = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ io_c = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+
+ if (!request_mem_region(io_d->start, resource_size(io_d), DRV_NAME))
+ goto err_mem_region;
+
+ if (!request_mem_region(io_c->start, resource_size(io_c), DRV_NAME))
+ goto err_mem_region1;
+
+ netdev = alloc_etherdev(sizeof(struct ks_net));
+ if (!netdev)
+ goto err_alloc_etherdev;
+
+ SET_NETDEV_DEV(netdev, &pdev->dev);
+
+ ks = netdev_priv(netdev);
+ ks->netdev = netdev;
+ ks->hw_addr = ioremap(io_d->start, resource_size(io_d));
+
+ if (!ks->hw_addr)
+ goto err_ioremap;
+
+ ks->hw_addr_cmd = ioremap(io_c->start, resource_size(io_c));
+ if (!ks->hw_addr_cmd)
+ goto err_ioremap1;
+
+ ks->irq = platform_get_irq(pdev, 0);
+
+ if (ks->irq < 0) {
+ err = ks->irq;
+ goto err_get_irq;
+ }
+
+ ks->pdev = pdev;
+
+ mutex_init(&ks->lock);
+ spin_lock_init(&ks->statelock);
+
+ netdev->netdev_ops = &ks_netdev_ops;
+ netdev->ethtool_ops = &ks_ethtool_ops;
+
+ /* setup mii state */
+ ks->mii.dev = netdev;
+ ks->mii.phy_id = 1,
+ ks->mii.phy_id_mask = 1;
+ ks->mii.reg_num_mask = 0xf;
+ ks->mii.mdio_read = ks_phy_read;
+ ks->mii.mdio_write = ks_phy_write;
+
+ ks_info(ks, "message enable is %d\n", msg_enable);
+ /* set the default message enable */
+ ks->msg_enable = netif_msg_init(msg_enable, (NETIF_MSG_DRV |
+ NETIF_MSG_PROBE |
+ NETIF_MSG_LINK));
+ ks_read_config(ks);
+
+ /* simple check for a valid chip being connected to the bus */
+ if ((ks_rdreg16(ks, KS_CIDER) & ~CIDER_REV_MASK) != CIDER_ID) {
+ ks_err(ks, "failed to read device ID\n");
+ err = -ENODEV;
+ goto err_register;
+ }
+
+ if (ks_read_selftest(ks)) {
+ ks_err(ks, "failed to read device ID\n");
+ err = -ENODEV;
+ goto err_register;
+ }
+
+ err = register_netdev(netdev);
+ if (err)
+ goto err_register;
+
+ platform_set_drvdata(pdev, netdev);
+
+ ks_soft_reset(ks, GRR_GSR);
+ ks_hw_init(ks);
+ ks_disable(ks);
+ ks_setup(ks);
+ ks_setup_int(ks);
+ ks_enable_int(ks);
+ ks_enable(ks);
+ memcpy(netdev->dev_addr, ks->mac_addr, 6);
+
+ data = ks_rdreg16(ks, KS_OBCR);
+ ks_wrreg16(ks, KS_OBCR, data | OBCR_ODS_16MA);
+
+ /**
+ * If you want to use the default MAC addr,
+ * comment out the 2 functions below.
+ */
+
+ random_ether_addr(netdev->dev_addr);
+ ks_set_mac(ks, netdev->dev_addr);
+
+ id = ks_rdreg16(ks, KS_CIDER);
+
+ printk(KERN_INFO DRV_NAME
+ " Found chip, family: 0x%x, id: 0x%x, rev: 0x%x\n",
+ (id >> 8) & 0xff, (id >> 4) & 0xf, (id >> 1) & 0x7);
+ return 0;
+
+err_register:
+err_get_irq:
+ iounmap(ks->hw_addr_cmd);
+err_ioremap1:
+ iounmap(ks->hw_addr);
+err_ioremap:
+ free_netdev(netdev);
+err_alloc_etherdev:
+ release_mem_region(io_c->start, resource_size(io_c));
+err_mem_region1:
+ release_mem_region(io_d->start, resource_size(io_d));
+err_mem_region:
+ return err;
+}
+
+static int __devexit ks8851_remove(struct platform_device *pdev)
+{
+ struct net_device *netdev = platform_get_drvdata(pdev);
+ struct ks_net *ks = netdev_priv(netdev);
+ struct resource *iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ unregister_netdev(netdev);
+ iounmap(ks->hw_addr);
+ free_netdev(netdev);
+ release_mem_region(iomem->start, resource_size(iomem));
+ platform_set_drvdata(pdev, NULL);
+ return 0;
+
+}
+
+static struct platform_driver ks8851_platform_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ },
+ .probe = ks8851_probe,
+ .remove = __devexit_p(ks8851_remove),
+};
+
+static int __init ks8851_init(void)
+{
+ return platform_driver_register(&ks8851_platform_driver);
+}
+
+static void __exit ks8851_exit(void)
+{
+ platform_driver_unregister(&ks8851_platform_driver);
+}
+
+module_init(ks8851_init);
+module_exit(ks8851_exit);
+
+MODULE_DESCRIPTION("KS8851 MLL Network driver");
+MODULE_AUTHOR("David Choi <david.choi@micrel.com>");
+MODULE_LICENSE("GPL");
+module_param_named(message, msg_enable, int, 0);
+MODULE_PARM_DESC(message, "Message verbosity level (0=none, 31=all)");
+
--- linux-2.6.31-rc3/drivers/net/Makefile.orig 2009-09-08 09:11:31.000000000 -0700
+++ linux-2.6.31-rc3/drivers/net/Makefile 2009-09-25 09:49:34.000000000 -0700
@@ -88,6 +88,7 @@ obj-$(CONFIG_SKGE) += skge.o
obj-$(CONFIG_SKY2) += sky2.o
obj-$(CONFIG_SKFP) += skfp/
obj-$(CONFIG_KS8842) += ks8842.o
+obj-$(CONFIG_KS8851) += ks8851_mll.o
obj-$(CONFIG_VIA_RHINE) += via-rhine.o
obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o
obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o
--- linux-2.6.31-rc3/drivers/net/Kconfig.orig 2009-09-08 09:10:28.000000000 -0700
+++ linux-2.6.31-rc3/drivers/net/Kconfig 2009-09-25 09:49:39.000000000 -0700
@@ -1729,6 +1729,12 @@ config KS8842
help
This platform driver is for Micrel KSZ8842 chip.
+config KS8851
+ tristate "Micrel KSZ8851"
+ depends on HAS_IOMEM
+ help
+ This platform driver is for Micrel KSZ8851 MLL chip.
+
config VIA_RHINE
tristate "VIA Rhine support"
depends on NET_PCI && PCI
Regards,
David J. Choi
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Thu 9/24/2009 4:39 PM
To: Choi, David
Cc: greg@kroah.com; netdev@vger.kernel.org; Li, Charles; Choi@kroah.com; jgarzik@redhat.com; shemminger@vyatta.com
Subject: Re: [PATCH] ks8851_ml ethernet network driver - FIXED LINE-WRAPPING ISSUE
This is a patch against the driver, not the whole new driver.
We want the whole new driver, with your proper commit log message,
and proper signoffs.
^ 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