* Compat-wireless for 2.6.35 final - 802.11, Bluetooth, Ethernet backported
From: Luis R. Rodriguez @ 2010-08-04 21:50 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Linus released 2.6.35 so we get our respective compat-wireless-2.6.35
released which backports the kernel's 802.11, Bluetooth and some
Ethernet drivers down to kernels >= 2.6.27. Goal is to always backport
all drivers down to the oldest supported 2.6. kenrel release listed on
kernel.org. Some drivers are backported to even further older kernels
(ath9k should go down to 2.6.23), to enable only one driver use the
./scripts/driver-select script. You can get compat-wireless-2.6.35
from:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/compat-wireless-2.6.35-0.tar.bz2
sha1sum: a718b6377136560894e7919304d0cf7a5106815b
compat-wireless code metrics
491756 - Total lines of upstream code being pulled
1394 - backport code changes
1163 - backport code additions
231 - backport code deletions
5737 - backport from compat module
7131 - total lines of backport code
1.45 - % of code consists of backport work
Base tree: linux-2.6-allstable.git
Base tree version: v2.6.35
compat-wireless release: compat-wireless-v2.6.35-0
Since we can have extra fixes within compat.git / compat-wireless.git
for stable releases in between stable kernel extra version updates I'm
started to rely on -release_number tag postfixes to the release tag.
So this release has the -0 release number, if we get a new fix/update
on this package before 2.6.35.1 we'll have compat-wireless-2.6.35-1,
and so on.
Changes that went into the Linux kernel for this release:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/ChangeLog-2.6.35-wireless
This comes from:
git log v2.6.34..HEAD \
net/wireless/ \
net/mac80211/ \
net/rfkill/ \
drivers/net/wireless/ \
net/bluetooth/ \
drivers/net/atl1c/ \
drivers/net/atl1e/ \
drivers/net/atlx/ \
drivers/bluetooth/ \
include/linux/nl80211.h \
include/linux/rfkill.h \
include/net/cfg80211.h \
include/net/regulatory.h \
include/net/cfg80211.h
For more information see:
http://wireless.kernel.org/en/users/Download/stable
compat-wireless makes use of the compat.git tree which provides a
generic Linux kernel compatibility module which besides providing
generic kernel helpers also backports the new rfkill, pm-qos and
firmware_class stuff. The updates from compat since the 2.6.34 kernel
release are:
Hauke Mehrtens (7):
compat: backport eth_change_mtu and eth_validate_addr
compat: move kparam_{block,unblock}_sysfs_write
compat: move usb_{alloc,free}_coherent
compat: update bitops.h and wireless.h
compat: move kparam_{block,unblock}_sysfs_write
compat: backport small functions and defines
compat: use kernel pm_qos_params.h
Luis R. Rodriguez (11):
compat: add new way to backport the usage of net_device_ops
compat: add the rest of the missing netdev_attach_ops()
compat: add the ndo_select_queue for netdev_attach_ops()
compat: add compat_version read-only module parameter
Modify the compat print
Add the COMPAT_BASE_TREE and COMPAT_BASE_TREE_VERSION
Add a COMPAT_PROJECT tag
Fix the syntax for the defines passed for compat
Remove the stupid SET_NETDEVOP
compat: create the udev directories for compat_firmware file
compat: backport USHRT_MAX, SHRT_MAX and SHRT_MIN
Rajkumar Manoharan (1):
compat: Fix panic caused by NULL pointer derefence in rtnl_fill_ifinfo
compat-wireless changes since the compat-wireless-2.6.34 release are:
Bruno Randolf (1):
compat-wireless: fix 07-change-default-rate-alg.patch
Hauke Mehrtens (23):
compat-wireless: rename {free,alloc}_ieee80211 to {free,alloc}_libipw
compat-wireless: fix building of iwmc3200wifi
compat-wireless: remove some uneeded header files
compat-wireless: update config symbols
compat-wireless: add orinoco to compat-wireless
compat-wireless: remove rename {free,alloc}_ieee80211 patch
compat-wireless: refresh patch to apply again
compat-wireless: Backport changes in pcmcia system
compat-wireless: fix use of device_create
compat-wireless: use wireless_handlers for wext functions.
compat-wireless: backport convert multicast list to list_head.
compat-wireless: Remove use of sdio quirks attribute
compat-wireless: include net and trace includes form compat.
compat-wireless: refresh patches
compat-wireless: updates for orinoco
compat-wireless: backport pm_qos_{add,remove,update}_request
compat-wireless: make patches apply again
Revert "compat-wireless: fix 07-change-default-rate-alg.patch"
compat-wireless: Update Readme to reflect changes
compat-wireless: update clean scripts
compat-wireless: use /etc/init.d/ and not sudo service
compat-wireless: run refresh only on last applied directory
compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
Luis R. Rodriguez (77):
./scripts/admin-update.sh refresh
./scripts/admin-update.sh refres
admin-update refresh the patches
driver-select: enable listing of ath9k_htc
driver-select: fix selecting ath9k_htc
admin-update refresh
Fix patches/06-header-changes.patch
Fix patches/13-trace.patch
admin-update refresh
admin-update refresh
admin-update refresh
Update USB makefile for new driver ipheth.o
./scripts/admin-update.sh refresh
compat-wireless: make use of new netdev_attach_ops() for orinoco
scripts/admin-update.sh refresh
Make rndis_host use netdev_attach_ops()
usbnet: use netdev_attach_ops()
rndis_wlan: fix backport of netdev_attach_ops() usage
rndis_wlan: use netdev_attach_ops()
mac80211: use netdev_attach_ops()
admin-update refresh
b44: use netdev_attach_ops()
ipw2100: use netdev_attach_ops()
ipw2200: use netdev_attach_ops()
libertas: use netdev_attach_ops()
mac80211_hwsim: use netdevice_attach_ops()
bnep, atl1e, atl1c: use netdev_attach_ops()
atl1: use netdev_attach_ops()
atl2: use netdev_attach_ops()
./scripts/admin-update.sh refresh
./scripts/admin-update.sh refresh
Change admin-update.sh to use system version files
Remove double line on admin-update.sh
Split up the NOSTDINC_FLAGS into a few lines
Use the defines to tag the compat module
Fix dependency on on WEXT
Fix the CREL compat-wireless release name on top level Makefile
Fix gen-compat-autoconf.sh for new version name changes
Fix scripts/driver-select due to new version changes
Add the compat to the unload of the modules
compat-wireless: add linux-next-pending, crap patch dirs and nagometer
rm -rf drivers when running scripts/admin-update.sh
compat-wireless: add a set of pending patches for linux-wireless
compat-wireless: add the Kconfig for drivers
compat-wireless: add some Atheros crap patches
compat-wireless: run ./scripts/compat_firmware_install
compat-wireless: remove some new files upon make clean
compat-wireless: add the new versioning files to .gitignore
Revert "compat-wireless: run ./scripts/compat_firmware_install"
compat-wireless: remove pending patches as of next-20100525
compat-wireless: ./scripts/admin-update.sh refresh
compat-wireless: fix backport code calculation
compat-wireless: only copy existing Kconfig files
compat-wireless: ./scripts/admin-update.sh -p refresh
compat-wireless: fix typo for used color for nagometer
compat-wireless: add new set of pending patches for 2010-05-25
compat-wireless: update the atheros crap patches
compat-wireless: clarify usage of linux-next-cherry-pick for bleeding edge
compat-wireless: remove two pending patches now upstream
compat-wireless: add pending fix patch for ath9k
compat-wireless: fixes offsets for
07-change-default-rate-alg.patch for 2.6.35-rc1
./scripts/admin-update.sh refresh
compat-wireless: fix hunks for crap/0002-ath9k-Add-pktlog-support.patch
compat-wireless: accept extra arguments for scripts/gen-stable-release.sh
Remove sucked in patch post 2.6.35-rc1
compat-wireless: add -n -p -c support for gen-stable-release.sh
compat-wireless: optimize branch selection on gen-stable-release.sh
compat-wireless: update the usage() print for gen-stable-release.sh
compat-wireless: fix target kernel expecations on gen-stable-release.sh
compat-wireless: Drop all the linux-next-pending patches
compat-wireless: remove the crap patches
compat-wireless: refresh hunks for 2.6.35-rc2
compat-wireless: refresh hunks for 2.6.35-rc2 as of June 11 2010
compat-wireless: fix patch patches/25-multicast-list_head.patch
for BT bnet
compat-wireless: ./scripts/admin-update.sh refresh
compta-wireless: update unload script
compat-wireless: refresh patches for 2.6.36-rc6
Paul Fertser (1):
compat-wireless: driver-select: add b43 to the list
Pavel Roskin (9):
compat-wireless: disable rt2800 if crc_ccitt is not available
compat-wireless: disable wl1251 SPI and wl1271 if crc7 is not available
compat-wireless: add support for ath9k_htc
compat-wireless: update 22-multiqueue.patch for the current linux-next
compat-wireless: remove patch part dealing with net/net_namespace.h
compat-wireless: remove 13-trace.patch, it's handled in compat now
compat-wireless: remove 25-device_create.patch, it's handled by compat
compat-wireless: find the actual remote URL
compat-wireless: fix fallbacks for unknown branch, remote or remote URL
Walter Goldens (2):
compat-wireless, unload rt2800usb
compat-wireless: rt2x00 added to driver-select
Thanks to the contributors!
Luis
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2010-08-04 21:53 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20100804.134115.260072845.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 04 Aug 2010 13:41:15 -0700 (PDT)
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed, 4 Aug 2010 12:06:47 -0700
>
>> On Tue, Aug 3, 2010 at 8:38 PM, David Miller <davem@davemloft.net> wrote:
>>>
>>> Another release, another merge window, another set of networking
>>> changes to merge :-)
>>
>> Ok, merged. But you should double-check my merge resolution fixes,
>
> Will do, thanks a lot.
I just double-checked everything and it all looks fine, thanks
again.
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn)
From: Eric W. Biederman @ 2010-08-04 22:04 UTC (permalink / raw)
To: Greg KH; +Cc: Michael Leun, netdev, davem, linux-kernel
In-Reply-To: <20100804214618.GA6289@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Wed, Aug 04, 2010 at 03:35:43PM +0200, Michael Leun wrote:
>> Hi,
>>
>> On Sun, 11 Jul 2010 19:29:39 +0200
>> Michael Leun <lkml20100708@newton.leun.net> wrote:
>>
>> [...]
>> > Jul 10 20:02:36 doris kernel: unregister_netdevice: waiting for lo to
>> > become free. Usage count = 3 [repeated]
Does this repeat indefinitely, or are there only a couple of repetitions?
If this repeats indefinitely every 5 seconds or so we have a serious bug.
Otherwise we just have cleanup taking longer than it should, which isn't
ideal but it is much less severe.
>> > Now one might say it is fault of openvpn (used OpenVPN 2.1_rc20
>> > i586-suse-linux - the one in openSuSE 11.2 package), openvpn didn't
>> > close some ressource and ssh does fine.
>> >
>> > But: should'nt kernel clean up after process when it exits?
>> > And/or: Should'nt kernel clean up if last process in network namespace
>> > exits - there is nothing left which might use that interface?!
>> >
>> > Greg KH <greg@kroah.com> wrote:
>> >
>> > > Yes, you are correct. Care to resend all of this to the
>> > > network-namespace developer(s) and the netdev mailing list so that
>> > > the correct people are notified so they can fix it all?
>> >
>> > [X] done - hopefully, cannot find a particular network namespace
>> > developer in MAINTAINERS or source files. If such a one exists, please
>> > forward.
>>
>> Did'nt work. Got no reaction from network mailinglist at all and bug
>> still is in 2.6.35.
>
> Eric, here's a bug with the network namespace stuff, care to work on
> resolving it?
Greg thanks for forwarding this in my direction.
Eric
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn) (was Re: sysfs bug when using tun with network namespaces)
From: Michael Leun @ 2010-08-04 22:11 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev, davem, linux-kernel
In-Reply-To: <20100804214618.GA6289@kroah.com>
Hi,
On Wed, 4 Aug 2010 14:46:18 -0700
Greg KH <greg@kroah.com> wrote:
> Eric, here's a bug with the network namespace stuff, care to work on
> resolving it?
Just in case I provide the complete scenario again below.
If I can help somehow (provide further information, test something...)
of course I'll happily do so.
In an network namespace I can use an tun/tap tunnel through ssh and
when closing that namespace then eveything is fine.
But when using openvpn (also tunnel trough tun/tap) in an network
namespace and then closing that namespace I get:
unregister_netdevice: waiting for lo to become free
[repeated]
Please see the following two examples showing that difference:
# > unshare -n /bin/bash
# > # how to setup veth device pair to get connectivity into namespace not shown here
# > tunctl -u ml -t tap1
# > ssh -o Tunnel=Ethernet -w 1:1 somewhere
[ running some traffic over tap1 not shown here ]
^d # logging out from somewhere
# > tunctl -d tap1
# > exit # logging out from shell in network namespace
Now the veth device pair used automagically vanishes and nothing
from that different network namespace remains - very well.
but
# > unshare -n /bin/bash
# > # how to setup veth device pair to get connectivity into namespace not shown here
# > openvpn --config some.config
[ running some traffic over vpn device not shown here ]
^c # stopping openvpn
# > lsof -i
# > netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
# > ps ax|grep openvpn|grep -v grep
# > # cannot find anything that suggests there is anything left from that openvpn session
# > exit # logging out from shell in network namespace
Now I get
Jul 10 20:02:36 doris kernel: unregister_netdevice: waiting for lo to
become free. Usage count = 3 [repeated]
Now one might say it is fault of openvpn (used OpenVPN 2.1_rc20
i586-suse-linux - the one in openSuSE 11.2 package - EDIT: meanwhile it
is 2.1.1, openSuSE 11.3 ), openvpn didn't close some ressource and ssh
does fine.
But: should'nt kernel clean up after process when it exits?
And/or: Should'nt kernel clean up if last process in network namespace
exits - there is nothing left which might use that interface?!
--
MfG,
Michael Leun
^ permalink raw reply
* [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-04 22:14 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org, linux-omap@vger.kernel.org,
damm@opensource.se, lethal@linux-sh.org, rjw@sisk.pl,
eric.y.miao@gmail.com, netdev@vger.kernel.org, Greg Kroah-Hartman,
alan, zt.tmzt
Inspiration for this comes from:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
RFC: http://lkml.org/lkml/2010/8/3/496
Patch is unchanged from the RFC. Reviews seemed generally positive
and it seemed this was desired functionality.
INTRO
As SOCs become more popular, the desire to quickly define a simple,
but functional, bus type with only a few unique properties becomes
desirable. As they become more complicated, the ability to nest these
simple busses and otherwise orchestrate them to match the actual
topology also becomes desirable.
EXAMPLE USAGE
/arch/ARCH/MY_ARCH/my_bus.c:
#include <linux/device.h>
#include <linux/platform_device.h>
struct bus_type my_bus_type = {
.name = "mybus",
};
EXPORT_SYMBOL_GPL(my_bus_type);
struct platform_device sub_bus1 = {
.name = "sub_bus1",
.id = -1,
.dev.bus = &my_bus_type,
}
EXPORT_SYMBOL_GPL(sub_bus1);
struct platform_device sub_bus2 = {
.name = "sub_bus2",
.id = -1,
.dev.bus = &my_bus_type,
}
EXPORT_SYMBOL_GPL(sub_bus2);
static int __init my_bus_init(void)
{
int error;
platform_bus_type_init(&my_bus_type);
error = bus_register(&my_bus_type);
if (error)
return error;
error = platform_device_register(&sub_bus1);
if (error)
goto fail_sub_bus1;
error = platform_device_register(&sub_bus2);
if (error)
goto fail_sub_bus2;
return error;
fail_sub_bus2:
platform_device_unregister(&sub_bus1);
fail_sub_bus2:
bus_unregister(&my_bus_type);
return error;
}
postcore_initcall(my_bus_init);
EXPORT_SYMBOL_GPL(my_bus_init);
/drivers/my_driver.c
static struct platform_driver my_driver = {
.driver = {
.name = "my-driver",
.owner = THIS_MODULE,
.bus = &my_bus_type,
},
};
/somewhere/my_device.c
static struct platform_device my_device = {
.name = "my-device",
.id = -1,
.dev.bus = &my_bus_type,
.dev.parent = &sub_bus_1.dev,
};
Notice that for a device / driver, only 3 lines were added to
switch from the platform bus to the new my_bus. This is
especially valuable if we consider supporting a legacy SOCs
and new SOCs where the same driver is used, but may need to
be on either the platform bus or the new my_bus. The above
code then becomes:
(possibly in a header)
#ifdef CONFIG_MY_BUS
#define MY_BUS_TYPE &my_bus_type
#else
#define MY_BUS_TYPE NULL
#endif
/drivers/my_driver.c
static struct platform_driver my_driver = {
.driver = {
.name = "my-driver",
.owner = THIS_MODULE,
.bus = MY_BUS_TYPE,
},
};
Which will allow the same driver to easily to used on either
the platform bus or the newly defined bus type.
This will build a device tree that mirrors the actual configuration:
/sys/bus
|-- my_bus
| |-- devices
| | |-- sub_bus1 -> ../../../devices/platform/sub_bus1
| | |-- sub_bus2 -> ../../../devices/platform/sub_bus2
| | |-- my-device -> ../../../devices/platform/sub_bus1/my-device
| |-- drivers
| | |-- my-driver
Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
---
drivers/base/platform.c | 30 ++++++++++++++++++++++++++----
include/linux/platform_device.h | 2 ++
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..c86be03 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
if (!pdev->dev.parent)
pdev->dev.parent = &platform_bus;
- pdev->dev.bus = &platform_bus_type;
+ if (!pdev->dev.bus)
+ pdev->dev.bus = &platform_bus_type;
if (pdev->id != -1)
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
@@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
*/
int platform_driver_register(struct platform_driver *drv)
{
- drv->driver.bus = &platform_bus_type;
+ if (!drv->driver.bus)
+ drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
@@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
* if the probe was successful, and make sure any forced probes of
* new devices fail.
*/
- spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
drv->probe = NULL;
if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
- spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
if (code != retval)
platform_driver_unregister(drv);
@@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
};
EXPORT_SYMBOL_GPL(platform_bus_type);
+/** platform_bus_type_init - fill in a pseudo-platform-bus
+ * @bus: foriegn bus type
+ *
+ * This init is basically a selective memcpy that
+ * won't overwrite any user-defined attributes and
+ * only copies things that platform bus defines anyway
+ */
+void platform_bus_type_init(struct bus_type *bus)
+{
+ if (!bus->dev_attrs)
+ bus->dev_attrs = platform_bus_type.dev_attrs;
+ if (!bus->match)
+ bus->match = platform_bus_type.match;
+ if (!bus->uevent)
+ bus->uevent = platform_bus_type.uevent;
+ if (!bus->pm)
+ bus->pm = platform_bus_type.pm;
+}
+EXPORT_SYMBOL_GPL(platform_bus_type_init);
+
int __init platform_bus_init(void)
{
int error;
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 5417944..fa8c35a 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -79,6 +79,8 @@ extern int platform_driver_probe(struct platform_driver *driver,
#define platform_get_drvdata(_dev) dev_get_drvdata(&(_dev)->dev)
#define platform_set_drvdata(_dev,data) dev_set_drvdata(&(_dev)->dev, (data))
+extern void platform_bus_type_init(struct bus_type *);
+
extern struct platform_device *platform_create_bundle(struct platform_driver *driver,
int (*probe)(struct platform_device *),
struct resource *res, unsigned int n_res,
--
1.7.2
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* Re: [PATCH net-next 09/14] tg3: Improve small packet performance
From: Anton Blanchard @ 2010-08-04 22:27 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev, andy, Michael Chan
In-Reply-To: <1280784368-4226-9-git-send-email-mcarlson@broadcom.com>
Hi,
Just saw this go in:
> static inline u32 tg3_tx_avail(struct tg3_napi *tnapi)
> {
> - smp_mb();
> + /* Tell compiler to fetch tx indices from memory. */
> + barrier();
> return tnapi->tx_pending -
> ((tnapi->tx_prod - tnapi->tx_cons) & (TG3_TX_RING_SIZE - 1));
> }
Which worries me. Are we sure we don't need any ordering (eg smp_rmb)?
A compiler barrier does nothing to ensure two loads are ordered.
Anton
^ permalink raw reply
* Re: [PATCH net-next 09/14] tg3: Improve small packet performance
From: Matt Carlson @ 2010-08-04 22:46 UTC (permalink / raw)
To: Anton Blanchard
Cc: Matthew Carlson, davem@davemloft.net, netdev@vger.kernel.org,
andy@greyhouse.net, Michael Chan
In-Reply-To: <20100804222741.GA18708@kryten>
On Wed, Aug 04, 2010 at 03:27:41PM -0700, Anton Blanchard wrote:
>
> Hi,
>
> Just saw this go in:
>
> > static inline u32 tg3_tx_avail(struct tg3_napi *tnapi)
> > {
> > - smp_mb();
> > + /* Tell compiler to fetch tx indices from memory. */
> > + barrier();
> > return tnapi->tx_pending -
> > ((tnapi->tx_prod - tnapi->tx_cons) & (TG3_TX_RING_SIZE - 1));
> > }
>
> Which worries me. Are we sure we don't need any ordering (eg smp_rmb)?
> A compiler barrier does nothing to ensure two loads are ordered.
>
> Anton
The compiler barrier makes sure the loads stay roughly in the same
location. In the places where the ordering really matters, we have the
memory barrier inlined into the calling code. In the rest of the
places, we can relax the ordering requirement because the final value is
just used as an estimate.
^ permalink raw reply
* Re: [PATCH net-next 09/14] tg3: Improve small packet performance
From: Michael Chan @ 2010-08-04 22:47 UTC (permalink / raw)
To: Anton Blanchard
Cc: Matthew Carlson, davem@davemloft.net, netdev@vger.kernel.org,
andy@greyhouse.net
In-Reply-To: <20100804222741.GA18708@kryten>
On Wed, 2010-08-04 at 15:27 -0700, Anton Blanchard wrote:
> Hi,
>
> Just saw this go in:
>
> > static inline u32 tg3_tx_avail(struct tg3_napi *tnapi)
> > {
> > - smp_mb();
> > + /* Tell compiler to fetch tx indices from memory. */
> > + barrier();
> > return tnapi->tx_pending -
> > ((tnapi->tx_prod - tnapi->tx_cons) & (TG3_TX_RING_SIZE - 1));
> > }
>
> Which worries me. Are we sure we don't need any ordering (eg smp_rmb)?
> A compiler barrier does nothing to ensure two loads are ordered.
We generally only get an estimate of the available tx ring size when we
call tg3_tx_avail(), so memory barriers are not generally needed. We
put a compiler barrier there to make sure that the compiler will fetch
the tx_prod and tx_cons from memory to give us a better estimate.
In specific cases detailed in the patch description, we do need memory
barriers when we call netif_tx_stop_queue() and then check for the tx
ring. We decided to put memory barriers exactly where they're needed
instead of inside tg3_tx_avail() which is an overkill.
Thanks.
^ permalink raw reply
* Re: Yet another bridge netfilter crash
From: Changli Gao @ 2010-08-04 23:00 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Herbert Xu, Stephen Hemminger, netdev
In-Reply-To: <4C5995C2.1010909@trash.net>
On Thu, Aug 5, 2010 at 12:30 AM, Patrick McHardy <kaber@trash.net> wrote:
> Am 23.07.2010 17:26, schrieb Herbert Xu:
>> On Fri, Jul 23, 2010 at 05:17:42PM +0200, Patrick McHardy wrote:
>>>
>>>> There's also the matter of fragments jumping between bridges.
>>>
>>> Conntrack zones can be used to avoid that, but that currently needs
>>> manual configuration.
>>
>> I think this is something that we need to fix. Because as it
>> stands, it can still crash if you get the wrong nf_bridge.
>>
>> The reason is that skb->dev does not hold a ref count. So the
>> reassembly code just throws it away and always uses the dev of
>> the last fragment.
>>
>> This breaks when two bridges combine to reassemble a single
>> packet, as the nf_bridge attribute of the reassembled packet
>> may come from an skb whose device is now dead. This is then
>> used to fill in the skb->dev (via nf_bridge->physindev).
>
> We could perform a new device lookup on reassembly as we do
> when expiring a fragment queue, but we probably shouldn't even
> be reassembling fragments from different bridges. One way to
> avoid this would be to automatically assign each bridge device
> to a different conntrack zone, but conntrack zones are limited
> to 2^16 and this might also have other unwanted side-effects.
>
> Until we come up with something better the best fix seems to
> be to perform the device lookup based on the iif.
How about holding physindev and physoutdev when queueing the skbs into
frag queue, and take the skb->dev(bridge NIC) as a key when queueing
the skbs from bridges?
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Using virtio as a physical (wire-level) transport
From: Ira W. Snyder @ 2010-08-04 23:04 UTC (permalink / raw)
To: Michael S. Tsirkin, Rusty Russell; +Cc: netdev, Zang Roy, virtualization
Hello Michael, Rusty,
I'm trying to figure out how to use virtio-net and vhost-net to
communicate over a physical transport (PCI bus) instead of shared
memory (for example, qemu/kvm guest).
We've talked about this several times in the past, and I currently have
some time to devote to this again. I'm trying to figure out if virtio is
still a viable solution, or if it has been evolved such that it is
unusable for this application.
I am trying to create a generic system to allow the type of
communications described below. I would like to create something that
can be easily ported to any slave computer which meets the following
requirements:
1) it is a PCI slave (agent) (it acts like any other PCI card)
2) it has an inter-processor communications mechanism
3) it has a DMA engine
There is a reasonable amount of demand for such a system. I get
inquiries about the prototype code I posted to linux-netdev at least
once a month. This sort of system is used regularly in the
telecommunications industry, among others.
Here is a quick drawing of the system I work with. Please forgive my
poor ascii art skills.
+-----------------+
| master computer |
| | +-------------------+
| PCI slot #1 | <-- physical connection --> | slave computer #1 |
| virtio-net if#1 | | vhost-net if#1 |
| | +-------------------+
| |
| | +-------------------+
| PCI slot #2 | <-- physical connection --> | slave computer #2 |
| virtio-net if#2 | | vhost-net if#2 |
| | +-------------------+
| |
| | +-------------------+
| PCI slot #n | <-- physical connection --> | slave computer #n |
| virtio-net if#n | | vhost-net if#n |
| | +-------------------+
+-----------------+
The reason for using vhost-net on the "slave" side is because vhost-net
is the component that performs data copies. In most cases, the slave
computers are non-x86 and have DMA controllers. DMA is an absolute
necessity when copying data across the PCI bus.
Do you think virtio is a viable solution to solve this problem? If not,
can you suggest anything else?
Another reason I ask this question is that I have previously invested
several months implementing a similar solution, only to have it outright
rejected for "not being the right way". If you don't think something
like this has any hope, I'd rather not waste another month of my life.
If you can think of a solution that is likely to be "the right way", I'd
rather you told me before I implement any code.
Making my life harder since the last time I tried this, mainline commit
7c5e9ed0c (virtio_ring: remove a level of indirection) has removed the
possibility of using an alternative virtqueue implementation. The commit
message suggests that you might be willing to add this capability back.
Would this be an option?
Thanks for your time,
Ira
^ permalink raw reply
* Re: [PATCH net-next 09/14] tg3: Improve small packet performance
From: Anton Blanchard @ 2010-08-04 23:08 UTC (permalink / raw)
To: Michael Chan
Cc: Matthew Carlson, davem@davemloft.net, netdev@vger.kernel.org,
andy@greyhouse.net
In-Reply-To: <1280962049.7554.25.camel@HP1>
Hi,
> We generally only get an estimate of the available tx ring size when we
> call tg3_tx_avail(), so memory barriers are not generally needed. We
> put a compiler barrier there to make sure that the compiler will fetch
> the tx_prod and tx_cons from memory to give us a better estimate.
>
> In specific cases detailed in the patch description, we do need memory
> barriers when we call netif_tx_stop_queue() and then check for the tx
> ring. We decided to put memory barriers exactly where they're needed
> instead of inside tg3_tx_avail() which is an overkill.
Thanks Matt and Michael. I was pretty sure you were thinking about
ordering issues but wanted to double check.
Anton
^ permalink raw reply
* GIT: net-*2.6 rebased...
From: David Miller @ 2010-08-04 23:21 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, sfr
Both net-2.6 and net-next-2.6 have been rebased.
To be honest, if you've been pulling from my tree you can just keep
doing so if you want, it will look just as if I had merged Linus's
tree into net-2.6 et al.
All work will go into net-2.6 for the time being, this means only
bug fixes and such.
Once -rc1 goes out, changes can start flowing into net-next-2.6
once more.
Please adhere to these rules, it helps keep the tree stable and
preserve the limited sanity still remaining in folks like Stephen
Rothwell. :-)
Thanks.
^ permalink raw reply
* bne2 rx packet drop?
From: Rusty Russell @ 2010-08-04 23:29 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev
Hi Michael (and netdev!)
I've got a customer seeing ~1000 rx packets dropped per day (on a busy
interface, bonding) via 'netstat -ni' RX-DRP's field across their 4-node
cluster. The code seems to put checksum_discard and mac_discard into
that counter, so I'm not sure what the root cause is.
Any hints? What are the conditions which cause mac_discard?
Thanks!
Rusty.
^ permalink raw reply
* Re: bne2 rx packet drop?
From: Michael Chan @ 2010-08-04 23:47 UTC (permalink / raw)
To: Rusty Russell; +Cc: netdev@vger.kernel.org
In-Reply-To: <201008050859.57659.rusty@rustcorp.com.au>
On Wed, 2010-08-04 at 16:29 -0700, Rusty Russell wrote:
> Hi Michael (and netdev!)
>
> I've got a customer seeing ~1000 rx packets dropped per day (on a busy
> interface, bonding) via 'netstat -ni' RX-DRP's field across their 4-node
> cluster. The code seems to put checksum_discard and mac_discard into
> that counter, so I'm not sure what the root cause is.
>
> Any hints? What are the conditions which cause mac_discard?
>
Please ask the customer for ethtool -S ethx. It has a number of
different counters for rx dropped packets so we can get a better idea of
what's happening.
Thanks.
^ permalink raw reply
* [PATCH] net: use the nf_bridge of the last received skb in a fragment queue
From: Changli Gao @ 2010-08-04 23:53 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy,
Stephen Hemminger, netdev, netfilter-devel, Changli Gao
As we don't hold references to net devices in nf_bridge_info to prevent the
net devices go, we should always use the nf_bridge of the last received skb
in a fragment queue.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/ipv4/ip_fragment.c | 11 ++++++++---
net/ipv6/netfilter/nf_conntrack_reasm.c | 10 ++++++++--
net/ipv6/reassembly.c | 11 ++++++++---
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index b7c4165..cd0a630 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -88,7 +88,7 @@ int ip_frag_mem(struct net *net)
}
static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
- struct net_device *dev);
+ struct net_device *dev, struct sk_buff *curr);
struct ip4_create_arg {
struct iphdr *iph;
@@ -478,7 +478,7 @@ found:
if (qp->q.last_in == (INET_FRAG_FIRST_IN | INET_FRAG_LAST_IN) &&
qp->q.meat == qp->q.len)
- return ip_frag_reasm(qp, prev, dev);
+ return ip_frag_reasm(qp, prev, dev, skb);
write_lock(&ip4_frags.lock);
list_move_tail(&qp->q.lru_list, &qp->q.net->lru_list);
@@ -494,7 +494,7 @@ err:
/* Build a new IP datagram from all its fragments. */
static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
- struct net_device *dev)
+ struct net_device *dev, struct sk_buff *curr)
{
struct net *net = container_of(qp->q.net, struct net, ipv4.frags);
struct iphdr *iph;
@@ -579,6 +579,11 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
head->next = NULL;
head->dev = dev;
head->tstamp = qp->q.stamp;
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_get(curr->nf_bridge);
+ nf_bridge_put(head->nf_bridge);
+ head->nf_bridge = curr->nf_bridge;
+#endif
iph = ip_hdr(head);
iph->frag_off = 0;
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 098a050..b5afad3 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -385,7 +385,8 @@ err:
* the last and the first frames arrived and all the bits are here.
*/
static struct sk_buff *
-nf_ct_frag6_reasm(struct nf_ct_frag6_queue *fq, struct net_device *dev)
+nf_ct_frag6_reasm(struct nf_ct_frag6_queue *fq, struct net_device *dev,
+ struct sk_buff *curr)
{
struct sk_buff *fp, *op, *head = fq->q.fragments;
int payload_len;
@@ -464,6 +465,11 @@ nf_ct_frag6_reasm(struct nf_ct_frag6_queue *fq, struct net_device *dev)
head->dev = dev;
head->tstamp = fq->q.stamp;
ipv6_hdr(head)->payload_len = htons(payload_len);
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_get(curr->nf_bridge);
+ nf_bridge_put(head->nf_bridge);
+ head->nf_bridge = curr->nf_bridge;
+#endif
/* Yes, and fold redundant checksum back. 8) */
if (head->ip_summed == CHECKSUM_COMPLETE)
@@ -622,7 +628,7 @@ struct sk_buff *nf_ct_frag6_gather(struct sk_buff *skb, u32 user)
if (fq->q.last_in == (INET_FRAG_FIRST_IN | INET_FRAG_LAST_IN) &&
fq->q.meat == fq->q.len) {
- ret_skb = nf_ct_frag6_reasm(fq, dev);
+ ret_skb = nf_ct_frag6_reasm(fq, dev, clone);
if (ret_skb == NULL)
pr_debug("Can't reassemble fragmented packets\n");
}
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 545c414..9ea4308 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -95,7 +95,7 @@ int ip6_frag_mem(struct net *net)
}
static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *prev,
- struct net_device *dev);
+ struct net_device *dev, struct sk_buff *curr);
/*
* callers should be careful not to use the hash value outside the ipfrag_lock
@@ -429,7 +429,7 @@ found:
if (fq->q.last_in == (INET_FRAG_FIRST_IN | INET_FRAG_LAST_IN) &&
fq->q.meat == fq->q.len)
- return ip6_frag_reasm(fq, prev, dev);
+ return ip6_frag_reasm(fq, prev, dev, skb);
write_lock(&ip6_frags.lock);
list_move_tail(&fq->q.lru_list, &fq->q.net->lru_list);
@@ -453,7 +453,7 @@ err:
* the last and the first frames arrived and all the bits are here.
*/
static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *prev,
- struct net_device *dev)
+ struct net_device *dev, struct sk_buff *curr)
{
struct net *net = container_of(fq->q.net, struct net, ipv6.frags);
struct sk_buff *fp, *head = fq->q.fragments;
@@ -548,6 +548,11 @@ static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *prev,
head->tstamp = fq->q.stamp;
ipv6_hdr(head)->payload_len = htons(payload_len);
IP6CB(head)->nhoff = nhoff;
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_get(curr->nf_bridge);
+ nf_bridge_put(head->nf_bridge);
+ head->nf_bridge = curr->nf_bridge;
+#endif
/* Yes, and fold redundant checksum back. 8) */
if (head->ip_summed == CHECKSUM_COMPLETE)
^ permalink raw reply related
* Re: bne2 rx packet drop?
From: Rusty Russell @ 2010-08-05 0:08 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev
In-Reply-To: <201008050859.57659.rusty@rustcorp.com.au>
On Thu, 5 Aug 2010 08:59:57 am Rusty Russell wrote:
> Hi Michael (and netdev!)
Subject should read bnx2 of course...
More coffee...
Rusty.
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn) (was Re: sysfs bug when using tun with network namespaces)
From: Eric W. Biederman @ 2010-08-05 0:12 UTC (permalink / raw)
To: Michael Leun; +Cc: Greg KH, netdev, davem, linux-kernel
In-Reply-To: <20100805001105.5a3453ed@xenia.leun.net>
Michael Leun <lkml20100708@newton.leun.net> writes:
> Hi,
>
> On Wed, 4 Aug 2010 14:46:18 -0700
> Greg KH <greg@kroah.com> wrote:
>
>> Eric, here's a bug with the network namespace stuff, care to work on
>> resolving it?
>
> Just in case I provide the complete scenario again below.
>
> If I can help somehow (provide further information, test something...)
> of course I'll happily do so.
>
> In an network namespace I can use an tun/tap tunnel through ssh and
> when closing that namespace then eveything is fine.
>
> But when using openvpn (also tunnel trough tun/tap) in an network
> namespace and then closing that namespace I get:
>
> unregister_netdevice: waiting for lo to become free
> [repeated]
>
> Please see the following two examples showing that difference:
>
> # > unshare -n /bin/bash
> # > # how to setup veth device pair to get connectivity into namespace not shown here
> # > tunctl -u ml -t tap1
> # > ssh -o Tunnel=Ethernet -w 1:1 somewhere
> [ running some traffic over tap1 not shown here ]
> ^d # logging out from somewhere
> # > tunctl -d tap1
> # > exit # logging out from shell in network namespace
>
> Now the veth device pair used automagically vanishes and nothing
> from that different network namespace remains - very well.
>
> but
>
> # > unshare -n /bin/bash
> # > # how to setup veth device pair to get connectivity into namespace not shown here
> # > openvpn --config some.config
> [ running some traffic over vpn device not shown here ]
> ^c # stopping openvpn
> # > lsof -i
> # > netstat -an
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address
> State Active UNIX domain sockets (servers and established)
> Proto RefCnt Flags Type State I-Node Path
> # > ps ax|grep openvpn|grep -v grep
> # > # cannot find anything that suggests there is anything left from that openvpn session
> # > exit # logging out from shell in network namespace
>
> Now I get
>
> Jul 10 20:02:36 doris kernel: unregister_netdevice: waiting for lo to
> become free. Usage count = 3 [repeated]
How many times?
> Now one might say it is fault of openvpn (used OpenVPN 2.1_rc20
> i586-suse-linux - the one in openSuSE 11.2 package - EDIT: meanwhile it
> is 2.1.1, openSuSE 11.3 ), openvpn didn't close some ressource and ssh
> does fine.
>
> But: should'nt kernel clean up after process when it exits?
> And/or: Should'nt kernel clean up if last process in network namespace
> exits - there is nothing left which might use that interface?!
We do, and the only place you will see:
unregister_netdevice: waiting for lo to become free. Usage count = 3 [repeated]
is when the a network namespace is being cleaned up.
However it looks like something is either taking a long time to get
cleaned up, or there is a bug and something is failing to get cleaned
up altogether thus resulting in an infinite stream of messages about waiting
for lo to become free.
I know of cases where a recent kernel can be slow to cleanup everything
attached to lo. I don't know of any cases where it will actually fail
to clean up lo. So I suspect all you are seeing is clean up process that
is slow and annoying not wrong.
Eric
^ permalink raw reply
* Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Kevin Hilman @ 2010-08-05 0:16 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-omap@vger.kernel.org, damm@opensource.se,
lethal@linux-sh.org, rjw@sisk.pl, eric.y.miao@gmail.com,
netdev@vger.kernel.org, Greg Kroah-Hartman, alan, zt.tmzt,
grant.likely, magnus.damm
In-Reply-To: <4C59E654.1090403@codeaurora.org>
Patrick Pannuto <ppannuto@codeaurora.org> writes:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
Also, later in that thread I also wrote[1] what seems to be the core of
what you've done here: namely, allow platform_devices and
platform_drivers to to be used on custom busses. Patch is at the end of
this mail with a more focused changelog. As Greg suggested in his reply
to your first version, this part could be merged today, and the
platform_bus_init stuff could be added later, after some more review.
Some comments below...
> INTRO
>
> As SOCs become more popular, the desire to quickly define a simple,
> but functional, bus type with only a few unique properties becomes
> desirable. As they become more complicated, the ability to nest these
> simple busses and otherwise orchestrate them to match the actual
> topology also becomes desirable.
>
> EXAMPLE USAGE
>
> /arch/ARCH/MY_ARCH/my_bus.c:
>
> #include <linux/device.h>
> #include <linux/platform_device.h>
>
> struct bus_type my_bus_type = {
> .name = "mybus",
> };
> EXPORT_SYMBOL_GPL(my_bus_type);
>
> struct platform_device sub_bus1 = {
> .name = "sub_bus1",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus1);
>
> struct platform_device sub_bus2 = {
> .name = "sub_bus2",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus2);
>
> static int __init my_bus_init(void)
> {
> int error;
> platform_bus_type_init(&my_bus_type);
> error = bus_register(&my_bus_type);
> if (error)
> return error;
>
> error = platform_device_register(&sub_bus1);
> if (error)
> goto fail_sub_bus1;
>
> error = platform_device_register(&sub_bus2);
> if (error)
> goto fail_sub_bus2;
>
> return error;
>
> fail_sub_bus2:
> platform_device_unregister(&sub_bus1);
> fail_sub_bus2:
> bus_unregister(&my_bus_type);
>
> return error;
> }
> postcore_initcall(my_bus_init);
> EXPORT_SYMBOL_GPL(my_bus_init);
>
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = &my_bus_type,
> },
> };
>
> /somewhere/my_device.c
> static struct platform_device my_device = {
> .name = "my-device",
> .id = -1,
> .dev.bus = &my_bus_type,
> .dev.parent = &sub_bus_1.dev,
> };
>
> Notice that for a device / driver, only 3 lines were added to
> switch from the platform bus to the new my_bus. This is
> especially valuable if we consider supporting a legacy SOCs
> and new SOCs where the same driver is used, but may need to
> be on either the platform bus or the new my_bus. The above
> code then becomes:
>
> (possibly in a header)
> #ifdef CONFIG_MY_BUS
> #define MY_BUS_TYPE &my_bus_type
> #else
> #define MY_BUS_TYPE NULL
> #endif
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = MY_BUS_TYPE,
> },
> };
>
> Which will allow the same driver to easily to used on either
> the platform bus or the newly defined bus type.
Except it requires a re-compile.
Rather than doing this at compile time, it would be better to support
legacy devices at runtime. You could handle this by simply registering
the driver on the custom bus and the platform_bus and let the bus
matching code handle it. Then, the same binary would work on both
legacy and updated SoCs.
>
> This will build a device tree that mirrors the actual configuration:
> /sys/bus
> |-- my_bus
> | |-- devices
> | | |-- sub_bus1 -> ../../../devices/platform/sub_bus1
> | | |-- sub_bus2 -> ../../../devices/platform/sub_bus2
> | | |-- my-device -> ../../../devices/platform/sub_bus1/my-device
> | |-- drivers
> | | |-- my-driver
>
>
> Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
> ---
> drivers/base/platform.c | 30 ++++++++++++++++++++++++++----
> include/linux/platform_device.h | 2 ++
> 2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 4d99c8b..c86be03 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
> if (!pdev->dev.parent)
> pdev->dev.parent = &platform_bus;
>
> - pdev->dev.bus = &platform_bus_type;
> + if (!pdev->dev.bus)
> + pdev->dev.bus = &platform_bus_type;
>
> if (pdev->id != -1)
> dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
> @@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
> */
> int platform_driver_register(struct platform_driver *drv)
> {
> - drv->driver.bus = &platform_bus_type;
> + if (!drv->driver.bus)
> + drv->driver.bus = &platform_bus_type;
> if (drv->probe)
> drv->driver.probe = platform_drv_probe;
> if (drv->remove)
> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
> * if the probe was successful, and make sure any forced probes of
> * new devices fail.
> */
> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
> drv->probe = NULL;
> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
> retval = -ENODEV;
> drv->driver.probe = platform_drv_probe_fail;
> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
Up to here, this looks exactly what I wrote in thread referenced above.
>
> if (code != retval)
> platform_driver_unregister(drv);
> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
> };
> EXPORT_SYMBOL_GPL(platform_bus_type);
>
> +/** platform_bus_type_init - fill in a pseudo-platform-bus
> + * @bus: foriegn bus type
> + *
> + * This init is basically a selective memcpy that
> + * won't overwrite any user-defined attributes and
> + * only copies things that platform bus defines anyway
> + */
minor nit: kernel doc style has wrong indentation
> +void platform_bus_type_init(struct bus_type *bus)
> +{
> + if (!bus->dev_attrs)
> + bus->dev_attrs = platform_bus_type.dev_attrs;
> + if (!bus->match)
> + bus->match = platform_bus_type.match;
> + if (!bus->uevent)
> + bus->uevent = platform_bus_type.uevent;
> + if (!bus->pm)
> + bus->pm = platform_bus_type.pm;
> +}
> +EXPORT_SYMBOL_GPL(platform_bus_type_init);
With this approach, you should note in the comments/changelog that
any selective customization of the bus PM methods must be done after
calling platform_bus_type_init().
Also, You've left out the legacy PM methods here. That implies that
moving a driver from the platform_bus to the custom bus is not entirely
transparent. If the driver still has legacy PM methods, it would stop
working on the custom bus.
While this is good motivation for converting a driver to dev_pm_ops, at
a minimum it should be clear in the changelog that the derivative busses
do not support legacy PM methods. However, since it's quite easy to do,
and you want the derivative busses to be *exactly* like the platform bus
except where explicitly changed, I'd suggest you also check/copy the
legacy PM methods.
In addition, you've missed several fields in 'struct bus_type'
(bus_attr, drv_attr, p, etc.) Without digging deeper into the driver
core, I'm not sure if they are all needed at init time, but it should be
clear in the comments why they can be excluded.
Kevin
[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31289.html
>From b784009af1d0a7065dc5e58a13ce29afa3432d3e Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@deeprootsystems.com>
Date: Mon, 28 Jun 2010 16:08:14 -0700
Subject: [PATCH] driver core: allow platform_devices and platform_drivers on custom busses
This allows platform_devices and platform_drivers to be registered onto
custom busses that are compatible with the platform_bus.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
drivers/base/platform.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..2cf55e2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
if (!pdev->dev.parent)
pdev->dev.parent = &platform_bus;
- pdev->dev.bus = &platform_bus_type;
+ if (!pdev->dev.bus)
+ pdev->dev.bus = &platform_bus_type;
if (pdev->id != -1)
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
@@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
*/
int platform_driver_register(struct platform_driver *drv)
{
- drv->driver.bus = &platform_bus_type;
+ if (!drv->driver.bus)
+ drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
@@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
* if the probe was successful, and make sure any forced probes of
* new devices fail.
*/
- spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
drv->probe = NULL;
if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
- spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
if (code != retval)
platform_driver_unregister(drv);
--
1.7.2.1
^ permalink raw reply related
* Re: [patch] netfilter: default to NF_DROP in sip_help_tcp()
From: Simon Horman @ 2010-08-05 0:34 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, netdev
In-Reply-To: <4C599102.9050500@trash.net>
On Wed, Aug 04, 2010 at 06:10:42PM +0200, Patrick McHardy wrote:
> Am 04.08.2010 10:07, schrieb Simon Horman:
> > On Wed, Jul 14, 2010 at 02:23:01PM +0200, Patrick McHardy wrote:
> >> On 10.07.2010 05:16, Simon Horman wrote:
> >>> I initially noticed this because of the compiler warning below, but it does
> >>> seem to be a valid concern in the case where ct_sip_get_header() returns 0
> >>> in the first iteration of the while loop.
> >>>
> >>> net/netfilter/nf_conntrack_sip.c: In function 'sip_help_tcp':
> >>> net/netfilter/nf_conntrack_sip.c:1379: warning: 'ret' may be used uninitialized in this function
> >>
> >> Thanks Simon. I've applied the patch, but changed NF_DROP to
> >> NF_ACCEPT since we should avoid dropping packets with unknown
> >> contents (not SIP) if possible.
> >
> > Hi Patrick,
> >
> > I'm not seeing this patch in nf-next-2.6.
> > Am I looking in the wrong place?
>
> I was struggling with some file system corruption and didn't manage
> to send it out in time, sorry. I'll include it in the next batch of
> patches for .36 and will also push it to -stable.
Thanks, I'm happy so long as it makes it eventually.
^ permalink raw reply
* Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-05 0:57 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-omap@vger.kernel.org, damm@opensource.se,
lethal@linux-sh.org, rjw@sisk.pl, eric.y.miao@gmail.com,
netdev@vger.kernel.org, Greg Kroah-Hartman, alan, zt.tmzt,
grant.likely, magnus.damm
In-Reply-To: <877hk56hiy.fsf@deeprootsystems.com>
On 08/04/2010 05:16 PM, Kevin Hilman wrote:
> Patrick Pannuto <ppannuto@codeaurora.org> writes:
>
>> Inspiration for this comes from:
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>
> Also, later in that thread I also wrote[1] what seems to be the core of
> what you've done here: namely, allow platform_devices and
> platform_drivers to to be used on custom busses. Patch is at the end of
> this mail with a more focused changelog. As Greg suggested in his reply
> to your first version, this part could be merged today, and the
> platform_bus_init stuff could be added later, after some more review.
> Some comments below...
>
I can split this into 2 patches.
Was your patch sent to linux-kernel or just linux-omap? I'm not on linux-omap...
>> [snip]
>>
>> Which will allow the same driver to easily to used on either
>> the platform bus or the newly defined bus type.
>
> Except it requires a re-compile.
>
> Rather than doing this at compile time, it would be better to support
> legacy devices at runtime. You could handle this by simply registering
> the driver on the custom bus and the platform_bus and let the bus
> matching code handle it. Then, the same binary would work on both
> legacy and updated SoCs.
>
Can you safely register a driver on more than one bus? I didn't think
that was safe -- normally it's impossible since you're calling
struct BUS_TYPE_driver mydriver;
BUS_TYPE_driver_register(&mydriver)
but now we have multiple "bus types" that are all actually platform type; still,
at a minimum you would need:
struct platform_driver mydrvier1 = {
.driver.bus = &sub_bus1,
};
struct platform_driver mydrvier2 = {
.driver.bus = &sub_bus2,
};
which would all point to the same driver functions, yet the respective devices
attached for the "same" driver would be on different buses. I fear this might
confuse some drivers. I don't think dynamic bus assignment is this easy
In short: I do not believe the same driver can be registered on multiple
different buses -- if this is wrong, please correct me.
>
> Up to here, this looks exactly what I wrote in thread referenced above.
>
It is, you just went on vacation :)
>>
>> if (code != retval)
>> platform_driver_unregister(drv);
>> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
>> };
>> EXPORT_SYMBOL_GPL(platform_bus_type);
>>
>> +/** platform_bus_type_init - fill in a pseudo-platform-bus
>> + * @bus: foriegn bus type
>> + *
>> + * This init is basically a selective memcpy that
>> + * won't overwrite any user-defined attributes and
>> + * only copies things that platform bus defines anyway
>> + */
>
> minor nit: kernel doc style has wrong indentation
>
will fix
>> +void platform_bus_type_init(struct bus_type *bus)
>> +{
>> + if (!bus->dev_attrs)
>> + bus->dev_attrs = platform_bus_type.dev_attrs;
>> + if (!bus->match)
>> + bus->match = platform_bus_type.match;
>> + if (!bus->uevent)
>> + bus->uevent = platform_bus_type.uevent;
>> + if (!bus->pm)
>> + bus->pm = platform_bus_type.pm;
>> +}
>> +EXPORT_SYMBOL_GPL(platform_bus_type_init);
>
> With this approach, you should note in the comments/changelog that
> any selective customization of the bus PM methods must be done after
> calling platform_bus_type_init().
No they don't. If you call platform_bus_type_init first then you'll
just overwrite them with new values; if you call it second then they
will all already be well-defined and thus not overwritten.
>
> Also, You've left out the legacy PM methods here. That implies that
> moving a driver from the platform_bus to the custom bus is not entirely
> transparent. If the driver still has legacy PM methods, it would stop
> working on the custom bus.
>
> While this is good motivation for converting a driver to dev_pm_ops, at
> a minimum it should be clear in the changelog that the derivative busses
> do not support legacy PM methods. However, since it's quite easy to do,
> and you want the derivative busses to be *exactly* like the platform bus
> except where explicitly changed, I'd suggest you also check/copy the
> legacy PM methods.
>
> In addition, you've missed several fields in 'struct bus_type'
> (bus_attr, drv_attr, p, etc.) Without digging deeper into the driver
> core, I'm not sure if they are all needed at init time, but it should be
> clear in the comments why they can be excluded.
>
I copied everything that was defined for platform_bus_type:
struct bus_type platform_bus_type = {
.name = "platform",
.dev_attrs = platform_dev_attrs,
.match = platform_match,
.uevent = platform_uevent,
.pm = &platform_dev_pm_ops,
};
EXPORT_SYMBOL_GPL(platform_bus_type);
struct bus_type {
const char *name;
struct bus_attribute *bus_attrs;
struct device_attribute *dev_attrs;
struct driver_attribute *drv_attrs;
int (*match)(struct device *dev, struct device_driver *drv);
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
int (*probe)(struct device *dev);
int (*remove)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
const struct dev_pm_ops *pm;
struct bus_type_private *p;
};
It is my understanding that everything that I did not copy *should* remain
unique to each bus; remaining fields will be filled in by bus_register and
should not be copied.
> Kevin
>
> [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31289.html
>
>
> From b784009af1d0a7065dc5e58a13ce29afa3432d3e Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@deeprootsystems.com>
> Date: Mon, 28 Jun 2010 16:08:14 -0700
> Subject: [PATCH] driver core: allow platform_devices and platform_drivers on custom busses
>
> This allows platform_devices and platform_drivers to be registered onto
> custom busses that are compatible with the platform_bus.
>
> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
> ---
> drivers/base/platform.c | 10 ++++++----
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 4d99c8b..2cf55e2 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
> if (!pdev->dev.parent)
> pdev->dev.parent = &platform_bus;
>
> - pdev->dev.bus = &platform_bus_type;
> + if (!pdev->dev.bus)
> + pdev->dev.bus = &platform_bus_type;
>
> if (pdev->id != -1)
> dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
> @@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
> */
> int platform_driver_register(struct platform_driver *drv)
> {
> - drv->driver.bus = &platform_bus_type;
> + if (!drv->driver.bus)
> + drv->driver.bus = &platform_bus_type;
> if (drv->probe)
> drv->driver.probe = platform_drv_probe;
> if (drv->remove)
> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
> * if the probe was successful, and make sure any forced probes of
> * new devices fail.
> */
> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
> drv->probe = NULL;
> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
> retval = -ENODEV;
> drv->driver.probe = platform_drv_probe_fail;
> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
>
> if (code != retval)
> platform_driver_unregister(drv);
If you would like to lead this effort, please do so; I did not mean to step
on your toes, it's just that this is an issue for me as well. You had
indicated that you were going on vacation for a month and I had not seen any
more follow-up on this issue, so I forged ahead. If you'd like me to drop it,
please let me know and I will - but also please send stuff like this to wider
distribution than just linux-omap; it has much greater reach (and interest).
Thanks,
-Pat
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 3/3] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: Bill Fink @ 2010-08-05 1:22 UTC (permalink / raw)
To: xeb; +Cc: netdev
In-Reply-To: <E1OgbWT-0004Ij-00.xeb-mail-ru@f134.mail.ru>
On Wed, 04 Aug 2010, xeb@mail.ru wrote:
> This is patch 3/3 which contains MAINTAINERS file modification.
>
> ---
> MAINTAINERS | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 02f75fc..313d829 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6450,6 +6450,20 @@ M: "Maciej W. Rozycki" <macro@linux-mips.org>
> S: Maintained
> F: drivers/serial/zs.*
>
> +GRE DEMULTIPLEXER DRIVER
> +M: Dmitry Kozlov <xeb@mail.ru>
> +L: linux-net@vger.kernel.org
Shouldn't this also be:
+L: netdev@vger.kernel.org
just like the PPTP DRIVER entry below?
-Bill
> +S: Maintained
> +F: net/ipv4/gre.c
> +F: include/net/gre.h
> +
> +PPTP DRIVER
> +M: Dmitry Kozlov <xeb@mail.ru>
> +L: netdev@vger.kernel.org
> +S: Maintained
> +F: drivers/net/pptp.c
> +W: http://accel-pptp.sourceforge.net/
> +
> THE REST
> M: Linus Torvalds <torvalds@linux-foundation.org>
> L: linux-kernel@vger.kernel.org
^ permalink raw reply
* Re: [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Magnus Damm @ 2010-08-05 2:32 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-omap@vger.kernel.org, damm@opensource.se,
lethal@linux-sh.org, rjw@sisk.pl, eric.y.miao@gmail.com,
netdev@vger.kernel.org, Greg Kroah-Hartman, alan, zt.tmzt
In-Reply-To: <4C59E654.1090403@codeaurora.org>
On Thu, Aug 5, 2010 at 7:14 AM, Patrick Pannuto <ppannuto@codeaurora.org> wrote:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>
> RFC: http://lkml.org/lkml/2010/8/3/496
> Patch is unchanged from the RFC. Reviews seemed generally positive
> and it seemed this was desired functionality.
Thanks for your patch, it's really nice to see work done in this area!
I'd like to see something like this merged in the not so distant
future. At this point I'm not so concerned about the details, so I'll
restrict myself to this:
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = &my_bus_type,
> },
> };
I would really prefer not to have the bus type in the here. I
understand it's needed at this point, but I wonder if it's possible to
adjust the device<->driver matching for platform devices to allow any
type of pseudo-platform bus_type.
The reason why I'd like to avoid having the bus type in the driver is
that I'd like to reuse the platform driver across multiple
architectures and buses. For instance, on the SH architecture and
SH-Mobile ARM we have SoCs with SCIF hardware blocks driven by the
sh-sci.c serial driver. The sh-sci.c platform driver supports a wide
range of different SCI(F)(A)(B) hardware blocks, and on any given SoC
there is a mix of SCIF blocks spread out on different buses.
At this point our SH platform drivers are unaware where their driver
instanced are located on the SoC. The I/O address and IRQs are
assigned via struct resource and clocks are managed through clkdev. I
believe that adding the bus type in the driver will violate this
abstraction and make it more difficult to just instantiate a driver
somewhere on the SoC.
> /somewhere/my_device.c
> static struct platform_device my_device = {
> .name = "my-device",
> .id = -1,
> .dev.bus = &my_bus_type,
> .dev.parent = &sub_bus_1.dev,
> };
This I don't mind at all. Actually, this is the place where the
topology should be defined IMO.
Cheers,
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* [PATCH] virtio_net: implements ethtool_ops.get_drvinfo
From: Rusty Russell @ 2010-08-05 3:32 UTC (permalink / raw)
To: netdev; +Cc: Michael S. Tsirkin, Taku Izumi
I often use "ethtool -i" command to check what driver controls the
ehternet device. But because current virtio_net driver doesn't
support "ethtool -i", it becomes the following:
# ethtool -i eth3
Cannot get driver information: Operation not supported
This patch simply adds the "ethtool -i" support. The following is the
result when using the virtio_net driver with my patch applied to.
# ethtool -i eth3
driver: virtio_net
version: N/A
firmware-version: N/A
bus-info: virtio0
Personally, "-i" is one of the most frequently-used option, and most
network drivers support "ethtool -i", so I think virtio_net also
should do.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (use ARRAY_SIZE)
---
drivers/net/virtio_net.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Index: net-next.35/drivers/net/virtio_net.c
===================================================================
--- net-next.35.orig/drivers/net/virtio_net.c
+++ net-next.35/drivers/net/virtio_net.c
@@ -701,6 +701,19 @@ static int virtnet_close(struct net_devi
return 0;
}
+static void virtnet_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *drvinfo)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ struct virtio_device *vdev = vi->vdev;
+
+ strncpy(drvinfo->driver, KBUILD_MODNAME, ARRAY_SIZE(drvinfo->driver));
+ strncpy(drvinfo->version, "N/A", ARRAY_SIZE(drvinfo->version));
+ strncpy(drvinfo->fw_version, "N/A", ARRAY_SIZE(drvinfo->fw_version));
+ strncpy(drvinfo->bus_info, dev_name(&vdev->dev),
+ ARRAY_SIZE(drvinfo->bus_info));
+}
+
static int virtnet_set_tx_csum(struct net_device *dev, u32 data)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -813,6 +825,7 @@ static void virtnet_vlan_rx_kill_vid(str
}
static const struct ethtool_ops virtnet_ethtool_ops = {
+ .get_drvinfo = virtnet_get_drvinfo,
.set_tx_csum = virtnet_set_tx_csum,
.set_sg = ethtool_op_set_sg,
.set_tso = ethtool_op_set_tso,
^ permalink raw reply
* Re: [PATCH] virtio_net: implements ethtool_ops.get_drvinfo
From: Ben Hutchings @ 2010-08-05 3:47 UTC (permalink / raw)
To: Rusty Russell; +Cc: netdev, Michael S. Tsirkin, Taku Izumi
In-Reply-To: <201008051302.06045.rusty@rustcorp.com.au>
On Thu, 2010-08-05 at 13:02 +0930, Rusty Russell wrote:
> I often use "ethtool -i" command to check what driver controls the
> ehternet device. But because current virtio_net driver doesn't
> support "ethtool -i", it becomes the following:
>
> # ethtool -i eth3
> Cannot get driver information: Operation not supported
>
> This patch simply adds the "ethtool -i" support. The following is the
> result when using the virtio_net driver with my patch applied to.
>
> # ethtool -i eth3
> driver: virtio_net
> version: N/A
> firmware-version: N/A
> bus-info: virtio0
>
> Personally, "-i" is one of the most frequently-used option, and most
> network drivers support "ethtool -i", so I think virtio_net also
> should do.
[...]
This information is already available generically through sysfs:
basename $(readlink /sys/class/net/eth3/device)
basename $(readlink /sys/class/net/eth3/device/driver)
Given that, we should either recommend that people use that method
instead, or we should add an equivalent default implementation of the
get_drvinfo operation.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: GIT: net-*2.6 rebased...
From: Stephen Rothwell @ 2010-08-05 4:11 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100804.162141.15218463.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
Hi Dave,
On Wed, 04 Aug 2010 16:21:41 -0700 (PDT) David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>
> Please adhere to these rules, it helps keep the tree stable and
> preserve the limited sanity still remaining in folks like Stephen
> Rothwell. :-)
Now I am not sure if I should be insulted :-)
/me locks up all his sharp objects
--
Cheers,
Stephen Rothwell sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ 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