* Re: [PATCH 0/2] ks8842: Support for passing flags via platform data and 100 Mbps support
From: Richard Röjfors @ 2010-07-25 12:13 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1280003108.28285.279.camel@debian>
On 07/24/2010 10:25 PM, Richard Röjfors wrote:
> To follow are two patches
> * Introduce a flags field in the platform data.
> * removes flow control and advertise 100Mbps
Forget these two patches, I missed the patch from David Choi.
My patches won't apply after his.
--Richard
^ permalink raw reply
* Re: [PATCH] CAN: Add Flexcan CAN controller driver
From: Marc Kleine-Budde @ 2010-07-25 12:01 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: wg, socketcan-core, netdev, davem
In-Reply-To: <4C4C1EDE.7020400@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]
Oliver Hartkopp wrote:
> first of all thanks for your contribution of the flexcan driver!
You're welcome!
> But i have a question regarding the Kconfig change that has been finally
> committed to net-next-2.6.
> It looks like the pulled code has some extra HAVE_CAN_FLEXCAN config option -
> which may be something of your debugging environment - which was not part of
> the original posted patch, where CAN_FLEXCAN depended on (ARCH_MX25 || ARCH_MX35).
Indeed this was not in the patch that Wolfgang Acked.
However, after Wolfgang's Ack I discussed the arm patches with the imx
people. I switched to dynamically registered devies, which is a more
modern way of registering them. And this led to the
"IMX_HAVE_PLATFORM_FLEXCAN" symbol (see below) and then we thought a
platform independent "HAVE_CAN_FLEXCAN" is even better.
So this was intentional (and in the latest patch I posed with the final
pull request.)
> Please see the two posted sections below ...
> The depency of (ARCH_MX25 || ARCH_MX35) makes more sense to me ;-)
The idea behind the "HAVE_CAN_FLEXCAN" is that all architectures select
this symbol if they have a flexcan core (which is supported by this
driver). On the imx platform we make this even in finer granularity.
BTW: If we on ARM finally have OF tree support we can change this easily
without needing to go over the net-next-2.6 tree.
Have a look at the corresponding ARM commits:
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=d7aec06a0decceabde9d9be6957229485568964b
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=b5a326c8c0a01692e710fc6086ddf84128b7a7d3
Here in detail+
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blob;f=arch/arm/plat-mxc/devices/Kconfig;h=9ab784b776f9192a33feaff37ff21be99b0a3691;hb=d7aec06a0decceabde9d9be6957229485568964b
We define a symbol without a prompt "IMX_HAVE_PLATFORM_FLEXCAN" for the
imx arm platform. This symbol selects "HAVE_CAN_FLEXCAN".
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blob;f=arch/arm/plat-mxc/devices/platform-flexcan.c;h=5e97a01f14f3eb106750f00d8a0fffb66f2c9563;hb=d7aec06a0decceabde9d9be6957229485568964b
A selected "IMX_HAVE_PLATFORM_FLEXCAN" symbol activates some glue code
that's used to create the individual flexcan devices.
It's up to the individual board code to select the
"IMX_HAVE_PLATFORM_FLEXCAN" symbol. This patch adds the flexcan support
on the pcm043:
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blobdiff;f=arch/arm/mach-mx3/Kconfig;h=03563eb997c0f761ea7d7e14d155facfce880e03;hp=e063657e1bf4c3f3d56a67e70bc3f17b333cfb55;hb=b5a326c8c0a01692e710fc6086ddf84128b7a7d3;hpb=d7aec06a0decceabde9d9be6957229485568964b
I hope that answers you question,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCH] CAN: Add Flexcan CAN controller driver
From: Oliver Hartkopp @ 2010-07-25 11:24 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: wg, socketcan-core, netdev, davem
In-Reply-To: <1279816844-12138-1-git-send-email-mkl@pengutronix.de>
Hello Marc,
first of all thanks for your contribution of the flexcan driver!
But i have a question regarding the Kconfig change that has been finally
committed to net-next-2.6.
It looks like the pulled code has some extra HAVE_CAN_FLEXCAN config option -
which may be something of your debugging environment - which was not part of
the original posted patch, where CAN_FLEXCAN depended on (ARCH_MX25 || ARCH_MX35).
Please see the two posted sections below ...
The depency of (ARCH_MX25 || ARCH_MX35) makes more sense to me ;-)
Regards,
Oliver
On 22.07.2010 18:40, Marc Kleine-Budde wrote:
> Hello,
>
> sorry for the confusion about the last minute problem with the driver,
> it was false alarm. Someone had troubles a driver derived from fsl's
> original one.
>
> David, please feel free to merge the driver now. :)
>
> Cheers, Marc
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 2c5227c..9d9e453 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -73,6 +73,15 @@ config CAN_JANZ_ICAN3
> This driver can also be built as a module. If so, the module will be
> called janz-ican3.ko.
>
> +config HAVE_CAN_FLEXCAN
> + bool
> +
> +config CAN_FLEXCAN
> + tristate "Support for Freescale FLEXCAN based chips"
> + depends on CAN_DEV && HAVE_CAN_FLEXCAN
> + ---help---
> + Say Y here if you want to support for Freescale FlexCAN.
> +
> source "drivers/net/can/mscan/Kconfig"
>
> source "drivers/net/can/sja1000/Kconfig"
On 21.07.2010 23:04, Marc Kleine-Budde wrote:
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 2c5227c..25924dd 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -73,6 +73,12 @@ config CAN_JANZ_ICAN3
> This driver can also be built as a module. If so, the module will be
> called janz-ican3.ko.
>
> +config CAN_FLEXCAN
> + tristate "Support for Freescale FLEXCAN based chips"
> + depends on CAN_DEV && (ARCH_MX25 || ARCH_MX35)
> + ---help---
> + Say Y here if you want to support for Freescale FlexCAN.
> +
> source "drivers/net/can/mscan/Kconfig"
>
> source "drivers/net/can/sja1000/Kconfig"
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Michael S. Tsirkin @ 2010-07-25 10:04 UTC (permalink / raw)
To: Tejun Heo
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <4C4BEAA2.6040301@kernel.org>
On Sun, Jul 25, 2010 at 09:41:22AM +0200, Tejun Heo wrote:
> Hello,
>
> On 07/24/2010 09:14 PM, Michael S. Tsirkin wrote:
> >> I've created kthread_worker in wq#for-next tree and already converted
> >> ivtv to use it. Once this lands in mainline, I think converting vhost
> >> to use it would be better choice. kthread worker code uses basically
> >> the same logic used in the vhost_workqueue code but is better
> >> organized and documented. So, I think it would be better to stick
> >> with the original implementation, as otherwise we're likely to just
> >> decrease test coverage without much gain.
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
> >
> > Sure, if we keep using workqueue. But I'd like to investigate this
> > direction a bit more because there's discussion to switching from kthread to
> > regular threads altogether.
>
> Hmmm? It doesn't have much to do with workqueue. kthread_worker is a
> simple wrapper around kthread. It now assumes kthread but changing it
> to be useable with any thread shouldn't be too hard. Wouldn't that be
> better?
Yes, of course, when common code becomes available we should
switch to that.
> >> I don't think doing this before executing the function is correct,
> >
> > Well, before I execute the function work is NULL, so this is skipped.
> > Correct?
> >
> >> so
> >> you'll have to release the lock, execute the function, regrab the lock
> >> and then do the flush processing.
> >>
> >> Thanks.
> >
> > It's done in the loop, so I thought we can reuse the locking
> > done for the sake of processing the next work item.
> > Makes sense?
>
> Yeap, right. I think it would make much more sense to use common code
> when it becomes available but if you think the posted change is
> necessary till then, please feel free to go ahead.
>
> Thanks.
>
> --
> tejun
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Eric Dumazet @ 2010-07-25 8:27 UTC (permalink / raw)
To: David Miller; +Cc: greearb, netdev
In-Reply-To: <20100724.213519.260107516.davem@davemloft.net>
Le samedi 24 juillet 2010 à 21:35 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 24 Jul 2010 16:13:15 +0200
>
> > I am not sure David will accept the patch !
>
> I don't think I can apply this, sorry :-)
Absolutely.
It might be possible for pktgen to use a pool of prebuilt pages to avoid
the cost of clearing pages. This wont work for skb without frags, unless
we change skb_release_data() (it calls kfree(skb->head), I dont think we
can trap this one...)
One better idea would be to take an extra reference on skb before giving
it to transmit, and maintain a list of skbs to recycle once their
refcount hits 1 (our reference). We could avoid most of the skb
setup/freeing costs (no more memory allocations/freeing)
I'll take a look after my vacations, unless someone motivated enough
beats me of course :)
Thanks !
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Tejun Heo @ 2010-07-25 7:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <20100724191447.GA4972@redhat.com>
Hello,
On 07/24/2010 09:14 PM, Michael S. Tsirkin wrote:
>> I've created kthread_worker in wq#for-next tree and already converted
>> ivtv to use it. Once this lands in mainline, I think converting vhost
>> to use it would be better choice. kthread worker code uses basically
>> the same logic used in the vhost_workqueue code but is better
>> organized and documented. So, I think it would be better to stick
>> with the original implementation, as otherwise we're likely to just
>> decrease test coverage without much gain.
>>
>> http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
>
> Sure, if we keep using workqueue. But I'd like to investigate this
> direction a bit more because there's discussion to switching from kthread to
> regular threads altogether.
Hmmm? It doesn't have much to do with workqueue. kthread_worker is a
simple wrapper around kthread. It now assumes kthread but changing it
to be useable with any thread shouldn't be too hard. Wouldn't that be
better?
>> I don't think doing this before executing the function is correct,
>
> Well, before I execute the function work is NULL, so this is skipped.
> Correct?
>
>> so
>> you'll have to release the lock, execute the function, regrab the lock
>> and then do the flush processing.
>>
>> Thanks.
>
> It's done in the loop, so I thought we can reuse the locking
> done for the sake of processing the next work item.
> Makes sense?
Yeap, right. I think it would make much more sense to use common code
when it becomes available but if you think the posted change is
necessary till then, please feel free to go ahead.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] Driver-core: Always create class directories for classses that support namespaces.
From: Eric W. Biederman @ 2010-07-25 5:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Berg, Kay Sievers, Andrew Morton, Greg KH,
Rafael J. Wysocki, Maciej W. Rozycki, netdev,
<linux-kernel@vger.kernel.org> Marcel Holtmann,
linux-bluetooth, Greg KH
In-Reply-To: <20100722185449.GB528@suse.de>
This fixes the regression in 2.6.35-rcX where bluetooth network devices would
fail to be deleted from sysfs, causing their destruction and recreation to
fail. In addition this fixes the mac80211_hwsim driver where it would leave
around sysfs files when the driver was removed. This problem is discussed at
https://bugzilla.kernel.org/show_bug.cgi?id=16257
The reason for the regression is that the network namespace support added to
sysfs expects and requires that network devices be put in directories that can
contain only network devices. Today get_device_parent almost provides that
guarantee for all class devices, except for a specific exception when the
parent of a class devices is a class device. It would be nice to simply
remove that arguably incorrect special case, but apparently the input devices
depend on it being there. So I have only removed it for class devices with
network namespace support. Which today are the network devices.
It has been suggested that a better fix would be to change the parent device
from a class device to a bus device, which in the case of the bluetooth driver
would change /sys/class/bluetooth to /sys/bus/bluetoth, I can not see how we
would avoid significant userspace breakage if we were to make that change.
Adding an extra directory in the path to the device will also be userspace
visible but it is much less likely to break things. Everything is still
accessible from /sys/class (for example), and it fixes two bugs. Adding an
extra directory fixes a 3 year old regression introduced with the new sysfs
layout that makes if impossible to rename bnep0 network devices to names that
conflict with hci device attributes like hci_revsion. Adding an additional
directory remove the new failure modes introduced by the network namespace
code.
If it weren't for the regession in the renaming of network devices I would
figure out how to just make the sysfs code deal with this configuration of
devices.
In summary this patch fixes regressions by changing:
"/sys/class/bluetooth/hci0/bnep0" to "/sys/class/bluetooth/hci0/net/bnep0".
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
p.s. Linus my apologies for sending this directly but I have gotten an
incredible amount of flak trying to fix this problem, and I would like
not to leave an accidental regression whose cause is well known in
2.6.35 if I can help it.
drivers/base/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 9630fbd..9b9d3bd 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -673,7 +673,7 @@ static struct kobject *get_device_parent(struct device *dev,
*/
if (parent == NULL)
parent_kobj = virtual_device_parent(dev);
- else if (parent->class)
+ else if (parent->class && !dev->class->ns_type)
return &parent->kobj;
else
parent_kobj = &parent->kobj;
--
1.6.5.2.143.g8cc62
^ permalink raw reply related
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: David Miller @ 2010-07-25 4:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: greearb, netdev
In-Reply-To: <1279980795.2451.157.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 24 Jul 2010 16:13:15 +0200
> I am not sure David will accept the patch !
I don't think I can apply this, sorry :-)
^ permalink raw reply
* [PATCHv2 NEXT 1/2] qlcnic: fix loopback test
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1280032338-7002-1-git-send-email-amit.salecha@qlogic.com>
o Loopback not supported for virtual function.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 2 --
drivers/net/qlcnic/qlcnic_ethtool.c | 10 ++++++++--
drivers/net/qlcnic/qlcnic_main.c | 18 ------------------
3 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index fad8e9a..9703893 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1301,8 +1301,6 @@ struct qlcnic_nic_template {
int (*get_mac_addr) (struct qlcnic_adapter *, u8*);
int (*config_bridged_mode) (struct qlcnic_adapter *, u32);
int (*config_led) (struct qlcnic_adapter *, u32, u32);
- int (*set_ilb_mode) (struct qlcnic_adapter *);
- void (*clear_ilb_mode) (struct qlcnic_adapter *);
int (*start_firmware) (struct qlcnic_adapter *);
};
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 7d6558e..9328d59 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -678,6 +678,12 @@ static int qlcnic_loopback_test(struct net_device *netdev)
int max_sds_rings = adapter->max_sds_rings;
int ret;
+ if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC) {
+ dev_warn(&adapter->pdev->dev, "Loopback test not supported"
+ "for non privilege function\n");
+ return 0;
+ }
+
if (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
return -EIO;
@@ -685,13 +691,13 @@ static int qlcnic_loopback_test(struct net_device *netdev)
if (ret)
goto clear_it;
- ret = adapter->nic_ops->set_ilb_mode(adapter);
+ ret = qlcnic_set_ilb_mode(adapter);
if (ret)
goto done;
ret = qlcnic_do_ilb_test(adapter);
- adapter->nic_ops->clear_ilb_mode(adapter);
+ qlcnic_clear_ilb_mode(adapter);
done:
qlcnic_diag_free_res(netdev, max_sds_rings);
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f1f7acf..f147958 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -107,8 +107,6 @@ static void qlcnic_config_indev_addr(struct net_device *dev, unsigned long);
static int qlcnic_start_firmware(struct qlcnic_adapter *);
static void qlcnic_dev_set_npar_ready(struct qlcnic_adapter *);
-static void qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *);
-static int qlcnicvf_set_ilb_mode(struct qlcnic_adapter *);
static int qlcnicvf_config_led(struct qlcnic_adapter *, u32, u32);
static int qlcnicvf_config_bridged_mode(struct qlcnic_adapter *, u32);
static int qlcnicvf_start_firmware(struct qlcnic_adapter *);
@@ -381,8 +379,6 @@ static struct qlcnic_nic_template qlcnic_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnic_config_bridged_mode,
.config_led = qlcnic_config_led,
- .set_ilb_mode = qlcnic_set_ilb_mode,
- .clear_ilb_mode = qlcnic_clear_ilb_mode,
.start_firmware = qlcnic_start_firmware
};
@@ -390,8 +386,6 @@ static struct qlcnic_nic_template qlcnic_vf_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnicvf_config_bridged_mode,
.config_led = qlcnicvf_config_led,
- .set_ilb_mode = qlcnicvf_set_ilb_mode,
- .clear_ilb_mode = qlcnicvf_clear_ilb_mode,
.start_firmware = qlcnicvf_start_firmware
};
@@ -2841,18 +2835,6 @@ qlcnicvf_config_led(struct qlcnic_adapter *adapter, u32 state, u32 rate)
return -EOPNOTSUPP;
}
-static int
-qlcnicvf_set_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return -EOPNOTSUPP;
-}
-
-static void
-qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return;
-}
-
static ssize_t
qlcnic_store_bridged_mode(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
--
1.6.0.2
^ permalink raw reply related
* [PATCHv2 NEXT 2/2] qlcnic: fix diag resource allocation
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Sony Chacko
In-Reply-To: <1280032338-7002-1-git-send-email-amit.salecha@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
netif_device_attach missing from error path in qlcnic_diag_alloc_res
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f147958..b9615bd 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1176,6 +1176,7 @@ int qlcnic_diag_alloc_res(struct net_device *netdev, int test)
ret = qlcnic_fw_create_ctx(adapter);
if (ret) {
qlcnic_detach(adapter);
+ netif_device_attach(netdev);
return ret;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCHv2 0/2]qlcnic: diagnostic fixes
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi
Series v2 of 2 patches to fix diagnostic test.
Apply them on net-next.
-Amit
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: pskb_expand_head() optimization
From: David Miller @ 2010-07-25 4:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: andrea, netdev
In-Reply-To: <1279861748.2482.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 23 Jul 2010 07:09:08 +0200
> [PATCH net-next-2.6] net: pskb_expand_head() optimization
>
> Move frags[] at the end of struct skb_shared_info, and make
> pskb_expand_head() copy only the used part of it instead of whole array.
>
> This should avoid kmemcheck warnings and speedup pskb_expand_head() as
> well, avoiding a lot of cache misses.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Maybe it's just that people aren't running kmemcheck when a
pskb_expand_head() triggers, who knows.
Anyways, since we skip the ->frag[] array in skb alloc, etc.,
your patch is of course fine.
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] net sched: fix race in mirred device removal
From: David Miller @ 2010-07-25 4:04 UTC (permalink / raw)
To: shemminger; +Cc: hadi, netdev
In-Reply-To: <20100722214504.42e0e7de@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Jul 2010 21:45:04 -0700
> This fixes hang when target device of mirred packet classifier
> action is removed.
>
> If a mirror or redirection action is configured to cause packets
> to go to another device, the classifier holds a ref count, but was assuming
> the adminstrator cleaned up all redirections before removing. The fix
> is to add a notifier and cleanup during unregister.
>
> The new list is implicitly protected by RTNL mutex because
> it is held during filter add/delete as well as notifier.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: remove sysctl jiffies conversion on gc_elasticity and min_adv_ms
From: David Miller @ 2010-07-25 4:03 UTC (permalink / raw)
To: mzhang; +Cc: netdev
In-Reply-To: <4C48BA82.6020904@mvista.com>
From: Min Zhang <mzhang@mvista.com>
Date: Thu, 22 Jul 2010 14:39:14 -0700
> sysctl output ipv6 gc_elasticity and min_adv_mss as values divided by
> HZ. However, they are not in unit of jiffies, since ip6_rt_min_advmss
> refers to packet size and ip6_rt_fc_elasticity is used as scaler as in
> expire>>ip6_rt_gc_elasticity, so replace the jiffies conversion
> handler will regular handler for them.
>
> This has impact on scripts that are currently working assuming the
> divide by HZ, will yield different results with this patch in place.
>
> Signed-off-by: Min Zhang <mzhang@mvista.com>
Your email client corrupted your patch, turning tab characters into
spaces. This makes your patch unusable.
Please resubmit this patch properly so that I can use it.
Thanks.
^ permalink raw reply
* Re: [patch 2.6.35] WiMAX pull request
From: David Miller @ 2010-07-25 3:52 UTC (permalink / raw)
To: inaky; +Cc: netdev, wimax, inaky.perez-gonzalez
In-Reply-To: <cover.1279843906.git.inaky.perez-gonzalez@intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Thu, 22 Jul 2010 17:15:13 -0700
> The following changes since commit a385a53e659b35ebee604889e21c40e5c336941f:
> Inaky Perez-Gonzalez (1):
> wimax/i2400m: fix missing endian correction read in fw loader
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git wimax-2.6.35.y
>
> Patches follow for reviewing convenience.
>
> Alexey Shvetsov (1):
> wimax/i2400m: Add PID & VID for Intel WiMAX 6250
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add attribute to indicate hw address assignment type
From: David Miller @ 2010-07-25 3:50 UTC (permalink / raw)
To: sassmann
Cc: bhutchings, abadea, netdev, linux-kernel, gospo, gregory.v.rose,
alexander.h.duyck, leedom, harald
In-Reply-To: <4C485A0C.7020500@redhat.com>
From: Stefan Assmann <sassmann@redhat.com>
Date: Thu, 22 Jul 2010 16:47:40 +0200
> On 22.07.2010 16:07, Ben Hutchings wrote:
>> On Thu, 2010-07-22 at 14:50 +0200, Stefan Assmann wrote:
>>> On 21.07.2010 15:54, Ben Hutchings wrote:
>>>> On Wed, 2010-07-21 at 10:10 +0200, Stefan Assmann wrote:
>>>>> I put Alex' idea into code for further discussion, keeping the names
>>>>> mentioned here until we agree on the scope of this attribute. When we
>>>>> have settled I'll post a patch with proper patch description.
>>>> [...]
>>>>
>>>> Just a little nitpick: I think it would be clearer to use a more
>>>> specific term like 'address source' or 'address assignment type' rather
>>>> than 'address type'.
>>>
>>> Here's a proposal for the final patch.
>>
>> Looks good, but...
...
>> ...why '|=' and not '='?
>
> The intention is to use addr_assign_type as a bit field.
>
> Okay it it might not make too much sense to 'steal' a random MAC
> address but in case we add more types later it might get useful.
I think the patch is good enough to go into net-next-2.6 as-is, anything
remaining is a refinement or one sort or another.
So applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH for-2.6.35] tun: avoid BUG, dump packet on GSO errors
From: David Miller @ 2010-07-25 3:47 UTC (permalink / raw)
To: herbert; +Cc: mst, netdev
In-Reply-To: <20100722130512.GA29088@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Jul 2010 21:05:12 +0800
> Michael S. Tsirkin <mst@redhat.com> wrote:
>> There are still some LRO cards that cause GSO errors in tun,
>> and BUG on this is an unfriendly way to tell the admin
>> to disable LRO.
>>
>> Further, experience shows we might have more GSO bugs lurking.
>> See https://bugzilla.kernel.org/show_bug.cgi?id=16413
>> as a recent example.
>> dumping a packet will make it easier to figure it out.
>>
>> Replace BUG with warning+dump+drop the packet to make
>> GSO errors in tun less critical and easier to debug.
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Tested-by: Alex Unigovsky <unik@compot.ru>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: fix ethtool stats
From: David Miller @ 2010-07-25 3:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, eric.dumazet
In-Reply-To: <20100723234252.18203.56378.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Jul 2010 16:44:21 -0700
> From: Eric Dumazet <eric.dumazet@gmail.com>
>
> In latest changes about 64bit stats on 32bit arches,
> [commit 28172739f0a276eb8 (net: fix 64 bit counters on 32 bit arches)],
> I missed ixgbe uses a bit of magic in its ixgbe_gstrings_stats
> definition.
>
> IXGBE_NETDEV_STAT() must now assume offsets relative to
> rtnl_link_stats64, not relative do dev->stats.
>
> As a bonus, we also get 64bit stats on ethtool -S
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Stephen Ko <stephen.s.ko@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH NEXT 2/2] qlcnic: diag fixes
From: David Miller @ 2010-07-25 3:42 UTC (permalink / raw)
To: gustavo; +Cc: amit.salecha, netdev, ameen.rahman
In-Reply-To: <20100724165343.GC9787@vigoh>
From: "Gustavo F. Padovan" <gustavo@padovan.org>
Date: Sat, 24 Jul 2010 13:53:43 -0300
> Hi Amit,
>
> * amit.salecha@qlogic.com <amit.salecha@qlogic.com> [2010-07-24 00:24:26 -0700]:
>
>> From: Amit Kumar Salecha <amit.salecha@qlogic.com>
>>
>> o Loopback not supported for virtual function.
>> o netif_device_attach was missing in error path from
>> qlcnic_diag_alloc_res
>
> This second part should be a new commit actually. It fixes a different
> thing.
Agreed.
^ permalink raw reply
* Re: [PATCH NEXT 1/2] qlcnic: fix bandwidth check
From: David Miller @ 2010-07-25 3:42 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, rajesh.borundia
In-Reply-To: <1279956266-23445-2-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Sat, 24 Jul 2010 00:24:25 -0700
> From: Rajesh Borundia <rajesh.borundia@qlogic.com>
>
> Fix maximum and minmum bandwith value.
>
> Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: set device in RLB ARP packet handler
From: David Miller @ 2010-07-25 3:38 UTC (permalink / raw)
To: andy; +Cc: fubar, greg.edwards, netdev, bonding-devel, linux-kernel
In-Reply-To: <20100723202648.GU7497@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Fri, 23 Jul 2010 16:26:48 -0400
> On Fri, Jul 23, 2010 at 01:02:04PM -0700, Jay Vosburgh wrote:
>>
>> From: Greg Edwards <greg.edwards@hp.com>
>>
>> After:
>>
>> commit 6146b1a4da98377e4abddc91ba5856bef8f23f1e
>> Author: Jay Vosburgh <fubar@us.ibm.com>
>> Date: Tue Nov 4 17:51:15 2008 -0800
>>
>> bonding: Fix ALB mode to balance traffic on VLANs
>>
>> the dev field in the RLB ARP packet handler was set to NULL to wildcard
>> and accommodate balancing VLANs on top of bonds.
>>
>> This has the side-effect of the packet handler being called against
>> other, non RLB-enabled bonds, and a kernel oops results when it tries to
>> dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be
>> set for those bonds, e.g. active-backup.
>>
>> With the __netif_receive_skb() changes from:
>>
>> commit 1f3c8804acba841b5573b953f5560d2683d2db0d
>> Author: Andy Gospodarek <andy@greyhouse.net>
>> Date: Mon Dec 14 10:48:58 2009 +0000
>>
>> bonding: allow arp_ip_targets on separate vlans to use arp validation
>>
>> frames received on VLANs correctly make their way to the bond's handler,
>> so we no longer need to wildcard the device.
>>
>> The oops can be reproduced by:
>>
>> modprobe bonding
>>
>> echo active-backup > /sys/class/net/bond0/bonding/mode
>> echo 100 > /sys/class/net/bond0/bonding/miimon
>> ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
>> echo +eth0 > /sys/class/net/bond0/bonding/slaves
>> echo +eth1 > /sys/class/net/bond0/bonding/slaves
>>
>> echo +bond1 > /sys/class/net/bonding_masters
>> echo balance-alb > /sys/class/net/bond1/bonding/mode
>> echo 100 > /sys/class/net/bond1/bonding/miimon
>> ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
>> echo +eth2 > /sys/class/net/bond1/bonding/slaves
>> echo +eth3 > /sys/class/net/bond1/bonding/slaves
>>
>> Pass some traffic on bond0. Boom.
>>
>> [ Tested, behaves as advertised. I do not believe a test of the bonding
>> mode is necessary, as there is no race between the packet handler and
>> the bonding mode changing (the mode can only change when the device is
>> closed). Also updated the log message to include the reproduction and
>> full commit ids. -J ]
>>
>> Signed-off-by: Greg Edwards <greg.edwards@hp.com>
>> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>
> Acked-by: Andy Gospodarek <andy@greyhouse.net>
This seems serious enough to put into net-2.6, so that's where I applied
it.
Thanks!
^ permalink raw reply
* [PATCH] 3c59x: Add ethtool WOL support
From: Andrew O. Shadoura @ 2010-07-25 2:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Netdev mailing list, Linux kernel mailing list
This patch adds wrappers for ethtool to get or set wake-on-LAN
setting without re-inserting the kernel module.
Signed-off-by: Andrew O. Shadoura <andrew@beldisplaytech.com>
---
Hello.
I've actually tested this patch on a machine with a network
card that's idenfied by lsusb as "3c905C-TX/TX-M", and it seems
to work.
---
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index d75803e..a452dfe 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -2909,6 +2909,36 @@ static void vortex_get_drvinfo(struct net_device *dev,
}
}
+static void vortex_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct vortex_private *vp = netdev_priv(dev);
+
+ spin_lock_irq(&vp->lock);
+ wol->supported = WAKE_MAGIC;
+
+ wol->wolopts = 0;
+ if (vp->enable_wol)
+ wol->wolopts |= WAKE_MAGIC;
+ spin_unlock_irq(&vp->lock);
+}
+
+static int vortex_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct vortex_private *vp = netdev_priv(dev);
+ if (wol->wolopts & ~WAKE_MAGIC)
+ return -EINVAL;
+
+ spin_lock_irq(&vp->lock);
+ if (wol->wolopts & WAKE_MAGIC)
+ vp->enable_wol = 1;
+ else
+ vp->enable_wol = 0;
+ acpi_set_WOL(dev);
+ spin_unlock_irq(&vp->lock);
+
+ return 0;
+}
+
static const struct ethtool_ops vortex_ethtool_ops = {
.get_drvinfo = vortex_get_drvinfo,
.get_strings = vortex_get_strings,
@@ -2920,6 +2950,8 @@ static const struct ethtool_ops vortex_ethtool_ops = {
.set_settings = vortex_set_settings,
.get_link = ethtool_op_get_link,
.nway_reset = vortex_nway_reset,
+ .get_wol = vortex_get_wol,
+ .set_wol = vortex_set_wol,
};
#ifdef CONFIG_PCI
--
WBR, Andrew
^ permalink raw reply related
* [PATCH 2.6.35-rc1] net-next: Fix an overflow bug in vmxnet3 Tx descriptor
From: Bhavesh Davda @ 2010-07-25 0:43 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
---
Fix an overflow bug in vmxnet3 Tx descriptor
This patch fixes a bug where a 16K buffer on a Tx descriptor was overflowing
into the 'gen' bit in the descriptor thereby corrupting the descriptor and
stalling the transmit ring.
Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
Signed-off-by: Matthew Delco <delcoM@vmware.com>
Signed-off-by: Ronghua Zhang <ronghua@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 9d64186..abe0ff5 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -664,8 +664,13 @@ vmxnet3_map_pkt(struct sk_buff *skb, struct vmxnet3_tx_ctx *ctx,
while (len) {
u32 buf_size;
- buf_size = len > VMXNET3_MAX_TX_BUF_SIZE ?
- VMXNET3_MAX_TX_BUF_SIZE : len;
+ if (len < VMXNET3_MAX_TX_BUF_SIZE) {
+ buf_size = len;
+ dw2 |= len;
+ } else {
+ buf_size = VMXNET3_MAX_TX_BUF_SIZE;
+ /* spec says that for TxDesc.len, 0 == 2^14 */
+ }
tbi = tq->buf_info + tq->tx_ring.next2fill;
tbi->map_type = VMXNET3_MAP_SINGLE;
@@ -673,13 +678,13 @@ vmxnet3_map_pkt(struct sk_buff *skb, struct vmxnet3_tx_ctx *ctx,
skb->data + buf_offset, buf_size,
PCI_DMA_TODEVICE);
- tbi->len = buf_size; /* this automatically convert 2^14 to 0 */
+ tbi->len = buf_size;
gdesc = tq->tx_ring.base + tq->tx_ring.next2fill;
BUG_ON(gdesc->txd.gen == tq->tx_ring.gen);
gdesc->txd.addr = cpu_to_le64(tbi->dma_addr);
- gdesc->dword[2] = cpu_to_le32(dw2 | buf_size);
+ gdesc->dword[2] = cpu_to_le32(dw2);
gdesc->dword[3] = 0;
dev_dbg(&adapter->netdev->dev,
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 762a6a7..2121c73 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -68,10 +68,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.13.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.14.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000B00
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000E00
/*
^ permalink raw reply related
* [PATCH 2/2] ks8842: Advertise 100Mbps
From: Richard Röjfors @ 2010-07-24 20:25 UTC (permalink / raw)
To: netdev; +Cc: davem
This patch makes sure that the ks8842 also advertises 100Mbps
during autonegotiation.
If the ks8842 is connected via VLB, the bus is slower
than 100Mbps ethernet. It turned out using flow control
in the chip was not optimal, so that non default setting
is removed.
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
---
diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
index 48e4582..ea22f29 100644
--- a/drivers/net/ks8842.c
+++ b/drivers/net/ks8842.c
@@ -254,10 +254,8 @@ static void ks8842_reset_hw(struct ks8842_adapter *adapter)
/* Enable QMU Transmit flow control / transmit padding / Transmit CRC */
ks8842_write16(adapter, 16, 0x000E, REG_TXCR);
- /* enable the receiver, uni + multi + broadcast + flow ctrl
- + crc strip */
- ks8842_write16(adapter, 16, 0x8 | 0x20 | 0x40 | 0x80 | 0x400,
- REG_RXCR);
+ /* enable the receiver, uni + multi + broadcast + crc strip */
+ ks8842_write16(adapter, 16, 0x8 | 0x20 | 0x40 | 0x80, REG_RXCR);
/* TX frame pointer autoincrement */
ks8842_write16(adapter, 17, 0x4000, REG_TXFDPR);
@@ -274,13 +272,11 @@ static void ks8842_reset_hw(struct ks8842_adapter *adapter)
/* enable no excessive collison drop */
ks8842_enable_bits(adapter, 32, 1 << 3, REG_SGCR2);
- /* Enable port 1 force flow control / back pressure / transmit / recv */
- ks8842_write16(adapter, 48, 0x1E07, REG_P1CR2);
+ /* Enable port 1 / back pressure / transmit / recv */
+ ks8842_write16(adapter, 48, 0xE07, REG_P1CR2);
/* restart port auto-negotiation */
ks8842_enable_bits(adapter, 49, 1 << 13, REG_P1CR4);
- /* only advertise 10Mbps */
- ks8842_clear_bits(adapter, 49, 3 << 2, REG_P1CR4);
/* Enable the transmitter */
ks8842_enable_tx(adapter);
^ permalink raw reply related
* [PATCH 1/2] ks8842: Add flags in the platform data
From: Richard Röjfors @ 2010-07-24 20:25 UTC (permalink / raw)
To: netdev; +Cc: davem
Previously the driver did a write to a timberdale specific register.
Timberdale is a FPGA used in some hardware setup which communicates
to the ks8842 via VLB.
A flag field is introduced where it is possible to pass a flag if
the ks8842 is connected via timberdale. Otherwise the driver won't
try to access timberdale registers.
If the timberdale flag is passed the driver also acks interrupts
in the FPGA, this is a bit more polite to the FPGA state machine.
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
---
diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
index 0be9261..48e4582 100644
--- a/drivers/net/ks8842.c
+++ b/drivers/net/ks8842.c
@@ -33,7 +33,13 @@
#define DRV_NAME "ks8842"
/* Timberdale specific Registers */
-#define REG_TIMB_RST 0x1c
+#define REG_TIMB_RST 0x1c
+#define REG_TIMB_FIFO 0x20
+#define REG_TIMB_ISR 0x24
+#define REG_TIMB_IER 0x28
+#define REG_TIMB_IAR 0x2C
+#define REQ_TIMB_DMA_RESUME 0x30
+
/* KS8842 registers */
@@ -121,6 +127,7 @@ struct ks8842_adapter {
spinlock_t lock; /* spinlock to be interrupt safe */
struct work_struct timeout_work;
struct net_device *netdev;
+ u8 flags;
};
static inline void ks8842_select_bank(struct ks8842_adapter *adapter, u16 bank)
@@ -195,12 +202,15 @@ static void ks8842_reset(struct ks8842_adapter *adapter)
/* The KS8842 goes haywire when doing softare reset
* a work around in the timberdale IP is implemented to
* do a hardware reset instead
- ks8842_write16(adapter, 3, 1, REG_GRR);
- msleep(10);
- iowrite16(0, adapter->hw_addr + REG_GRR);
- */
- iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
- msleep(20);
+ */
+ if (adapter->flags & KS8842_FLAGS_TIMB) {
+ iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
+ msleep(20);
+ } else {
+ ks8842_write16(adapter, 3, 1, REG_GRR);
+ msleep(10);
+ iowrite16(0, adapter->hw_addr + REG_GRR);
+ }
}
static void ks8842_update_link_status(struct net_device *netdev,
@@ -463,6 +473,10 @@ void ks8842_tasklet(unsigned long arg)
/* Ack */
ks8842_write16(adapter, 18, isr, REG_ISR);
+ /* Ack in the timberdale IP as well */
+ if (adapter->flags & KS8842_FLAGS_TIMB)
+ iowrite32(0x1, adapter->hw_addr + REG_TIMB_IAR);
+
if (!netif_running(netdev))
return;
@@ -687,6 +701,8 @@ static int __devinit ks8842_probe(struct platform_device *pdev)
/* Check if a mac address was given */
i = netdev->addr_len;
if (pdata) {
+ adapter->flags = pdata->flags;
+
for (i = 0; i < netdev->addr_len; i++)
if (pdata->macaddr[i] != 0)
break;
diff --git a/include/linux/ks8842.h b/include/linux/ks8842.h
index da0341b..12b4bda 100644
--- a/include/linux/ks8842.h
+++ b/include/linux/ks8842.h
@@ -21,14 +21,18 @@
#include <linux/if_ether.h>
+#define KS8842_FLAGS_TIMB 0x01
+
/**
* struct ks8842_platform_data - Platform data of the KS8842 network driver
* @macaddr: The MAC address of the device, set to all 0:s to use the on in
* the chip.
+ * @flags: Flags to the drivers which configures the hardware setup
*
*/
struct ks8842_platform_data {
u8 macaddr[ETH_ALEN];
+ u8 flags;
};
#endif
^ permalink raw reply related
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