* Re: [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification
From: David S. Miller @ 2005-05-31 22:37 UTC (permalink / raw)
To: herbert; +Cc: hadi, kaber, netdev
In-Reply-To: <20050527233741.GA9157@gondor.apana.org.au>
Applied to net-2.6.13, so you have some time to make some changes
to the API before they get cast in stone.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] [NETLINK] Correctly set NLM_F_MULTI without checking the pid
From: David S. Miller @ 2005-05-31 22:37 UTC (permalink / raw)
To: tgraf; +Cc: hadi, netdev
In-Reply-To: <20050527170135.GE15391@postel.suug.ch>
Both patches applied to my net-2.6.13 tree, it should show up on kernel.org
shortly.
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: David S. Miller @ 2005-05-31 22:31 UTC (permalink / raw)
To: tgraf; +Cc: hadi, netdev
In-Reply-To: <20050531222646.GK15391@postel.suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Wed, 1 Jun 2005 00:26:46 +0200
> > Please use explicit "unsigned int flags" instead of "unsigned flags".
>
> I converted this already in the two patches later in the thread.
I see, thanks for pointing this out.
^ permalink raw reply
* Re: r8169 802.1q/MTU bug
From: Francois Romieu @ 2005-05-31 22:31 UTC (permalink / raw)
To: James Harr; +Cc: netdev
In-Reply-To: <200505301927.26110.james@grickle.org>
James Harr <james@grickle.org> :
[...]
> The driver you sent gives me an error when I try to compile and load it with
> 2.6.11.11:
The driver that I sent you builds with 2.6.12-rc4. Please try 2.6.12-rc4 +
the aforementioned driver.
If it still crashes (?), tell if your .config matches:
CONFIG_R8169=m
CONFIG_R8169_NAPI=y
# CONFIG_R8169_VLAN is not set
or:
CONFIG_R8169=m
CONFIG_R8169_NAPI=y
CONFIG_R8169_VLAN=y
An history of the commands issued to set the config before the crash
would be welcome too.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 7/7] [PKT_SCHED] Logic simplifications and codingstyle/whitespace cleanups
From: David S. Miller @ 2005-05-31 22:30 UTC (permalink / raw)
To: tgraf; +Cc: werner, netdev
In-Reply-To: <20050527145611.GY15391@postel.suug.ch>
Ok, I did something tricky to make this all work out and
put the changes in the correct tree cleanly.
I put patches 1-3 into my main net-2.6 tree, they will go to Linus
shortly. Patches 4-7 I put into my net-2.6.13 tree after merging
in the net-2.6 tree (and thus patches 1-3).
I pushed it out to kernel.org, and it should show up on all the
mirrors and the GIT website shortly.
Thanks.
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: Thomas Graf @ 2005-05-31 22:26 UTC (permalink / raw)
To: David S. Miller; +Cc: hadi, netdev
In-Reply-To: <20050531.144338.112623594.davem@davemloft.net>
* David S. Miller <20050531.144338.112623594.davem@davemloft.net> 2005-05-31 14:43
> From: jamal <hadi@cyberus.ca>
> Date: Fri, 27 May 2005 08:32:37 -0400
>
> > This patch rectifies some rtnetlink message builders that derive the
> > flags from the pid. It is now explicit like the other cases
> > which get it right.
> >
> > Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
>
> Please use explicit "unsigned int flags" instead of "unsigned flags".
I converted this already in the two patches later in the thread.
^ permalink raw reply
* Re: [PATCH 3/7] [PKT_SCHED] Disable dsmark debugging messages by default
From: David S. Miller @ 2005-05-31 22:20 UTC (permalink / raw)
To: tgraf; +Cc: werner, netdev
In-Reply-To: <20050527145222.GU15391@postel.suug.ch>
Applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCH 2/7] [PKT_SCHED] make dsmark try using pfifo instead of noop while grafting
From: David S. Miller @ 2005-05-31 22:20 UTC (permalink / raw)
To: tgraf; +Cc: werner, netdev
In-Reply-To: <20050527145136.GT15391@postel.suug.ch>
Applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCH 1/7] [PKT_SCHED] Fix dsmark to count ignored indices while walking
From: David S. Miller @ 2005-05-31 22:20 UTC (permalink / raw)
To: tgraf; +Cc: werner, netdev
In-Reply-To: <20050527145058.GS15391@postel.suug.ch>
Applied, thanks Thomas.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: David S. Miller @ 2005-05-31 22:14 UTC (permalink / raw)
To: jdmason
Cc: mitch.a.williams, hadi, shemminger, netdev, Robert.Olsson,
john.ronciak, ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <200505311707.54487.jdmason@us.ibm.com>
From: Jon Mason <jdmason@us.ibm.com>
Date: Tue, 31 May 2005 17:07:54 -0500
> Of course some performace analysis would have to be done to determine the
> optimal numbers for each speed/duplexity setting per driver.
per cpu speed, per memory bus speed, per I/O bus speed, and add in other
complications such as NUMA
My point is that whatever experimental number you come up with will be
good for that driver on your systems, not necessarily for others.
Even within a system, whatever number you select will be the wrong
thing to use if one starts a continuous I/O stream to the SATA
controller in the next PCI slot, for example.
We keep getting bitten by this, as the Altix perf data continually shows,
and we need to absolutely stop thinking this way.
The way to go is to make selections based upon observed events and
mesaurements.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Jon Mason @ 2005-05-31 22:07 UTC (permalink / raw)
To: Mitch Williams
Cc: jamal, Stephen Hemminger, netdev, Robert.Olsson, Ronciak, John,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <Pine.CYG.4.58.0505311029510.2128@mawilli1-desk2.amr.corp.intel.com>
On Tuesday 31 May 2005 12:35 pm, Mitch Williams wrote:
> On Fri, 27 May 2005, jamal wrote:
> > On Fri, 2005-27-05 at 14:01 -0700, Stephen Hemminger wrote:
> > > Why not just allow adjusting dev->weight via sysfs?
> >
> > I think that should be good enough - and i thought your patch already
> > did this.
> > Adding a shift to the weight in a _weighted_ RR algorithm does sound
> > odd.
>
> Stephen's patch only affects the weight for the backlog device. Exporting
> dev-> weight to sysfs will allow the weight to be set for any network
> device. Which makes perfect sense.
>
> I'll work on getting this done and verifying performance this week.
> Expect a patch in a few days.
>
> Thanks, guys.
>
> -Mitch
It seems to me that the drivers should adjust dev->weight dependent on the
media speed/duplexity of the current link. A 10Mbps link will be constantly
re-enabling interrupts, as the incoming traffic is too slow. Why not have it
be 1/4 the weight of the gigabit NAPI weight, and set it when the link speed
is detected (or forced)?
Of course some performace analysis would have to be done to determine the
optimal numbers for each speed/duplexity setting per driver.
Thanks,
Jon
^ permalink raw reply
* Re: [RFC] textsearch infrastructure et al v2
From: David S. Miller @ 2005-05-31 22:05 UTC (permalink / raw)
To: pablo; +Cc: tgraf, hadi, netdev
In-Reply-To: <42986A85.9060001@eurodev.net>
From: Pablo Neira <pablo@eurodev.net>
Date: Sat, 28 May 2005 14:56:37 +0200
> Netfilter used to follow this approach in early 2.6 kernels and Patrick
> McHardy demostrated with some oprofile stuff that skb_copy_bits
> decreased performance.
This case got converted into what skb_copy_bits() was probably
meant to be, skb_header_pointer().
The idea is, if it's linear in the SKB already (headers almost
certainly are) just pass back the pointer to it, else copy into
the user provided temporary buffer and return a pointer to that.
The text search stuff could easily do the same thing, using
a 32-byte or so sliding window to run the text search on.
^ permalink raw reply
* Re: [RFC] textsearch infrastructure et al v2
From: David S. Miller @ 2005-05-31 21:56 UTC (permalink / raw)
To: tgraf; +Cc: netdev, hadi
In-Reply-To: <20050527224725.GG15391@postel.suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Sat, 28 May 2005 00:47:25 +0200
> Any other ideas around?
You could just fetch "windows" of data.
You can define this window to be 32 bytes, or whatever.
Then you use skb_copy_data() into this 32 byte window scratch
pad the text searcher uses, and you're done. It starts looking
like an MPEG stream parser :-)
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: David S. Miller @ 2005-05-31 21:43 UTC (permalink / raw)
To: hadi; +Cc: tgraf, netdev
In-Reply-To: <1117197157.6688.24.camel@localhost.localdomain>
From: jamal <hadi@cyberus.ca>
Date: Fri, 27 May 2005 08:32:37 -0400
> This patch rectifies some rtnetlink message builders that derive the
> flags from the pid. It is now explicit like the other cases
> which get it right.
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Please use explicit "unsigned int flags" instead of "unsigned flags".
^ permalink raw reply
* Re: [PATCH] shaper.c: fix locking
From: David S. Miller @ 2005-05-31 21:41 UTC (permalink / raw)
To: hch; +Cc: netdev
In-Reply-To: <20050527115450.GA19469@lst.de>
From: Christoph Hellwig <hch@lst.de>
Subject: [PATCH] shaper.c: fix locking
Date: Fri, 27 May 2005 13:54:50 +0200
> o use a semaphore instead of an opencoded and racy lock
> o move locking out of shaper_kick and into the callers - most just
> released the lock before calling shaper_kick
> o remove in_interrupt() tests. from ->close we can always block, from
> ->hard_start_xmit and timer context never
Do you really want to use a semaphore for a lock taken
%99 of the time in software IRQ context, which obviously
cannot sleep?
^ permalink raw reply
* Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way)
From: Grant Grundler @ 2005-05-31 19:03 UTC (permalink / raw)
To: Michael Chan; +Cc: Grant Grundler, David S. Miller, Peter Chubb, netdev
In-Reply-To: <1117561365.4310.22.camel@rh4>
On Tue, May 31, 2005 at 10:42:45AM -0700, Michael Chan wrote:
> No, I mean I will create a patch that will work for older devices that
> do not have the valid LED bits in eeprom.
Ah ok. How can you know if the LED bits are valid (or not)?
I consider this a bug in the eeprom and have set things in motion
(in HP) to correct it since the card is not an obsolete product.
Otherwise, the patch I submitted should be sufficient.
thanks,
grant
^ permalink raw reply
* Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way)
From: Grant Grundler @ 2005-05-31 18:36 UTC (permalink / raw)
To: Michael Chan; +Cc: David S. Miller, Peter Chubb, netdev
In-Reply-To: <1117560157.4310.16.camel@rh4>
On Tue, May 31, 2005 at 10:22:37AM -0700, Michael Chan wrote:
> > Michael,
> > Peter bounced this email to me after we talked about issues he was
> > having with the rx8620 (HP 16-way ia64, sx1000 chipset) "IOX Core LAN".
> > It sounded like the same problem I tracked down with rx8620 IOX Core LAN
> > in March. Here is the summary :
> >
> > | In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting
> > | programmed and how to determine what to program into LED_CTRL. The new
> > | code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write
> > | to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was
> > | saying MODE_MAC (0x0) and that doesn't work.
> >
>
> Thanks Grant, I'll chase this down and find a solution to this problem.
You mean you'll help find a way to reflash the onboard eeprom?
thanks,
grant
^ permalink raw reply
* Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way)
From: Michael Chan @ 2005-05-31 18:22 UTC (permalink / raw)
To: Grant Grundler; +Cc: David S. Miller, Peter Chubb, netdev
In-Reply-To: <20050531190345.GH20793@esmail.cup.hp.com>
On Tue, 2005-05-31 at 12:03 -0700, Grant Grundler wrote:
> On Tue, May 31, 2005 at 10:42:45AM -0700, Michael Chan wrote:
> > No, I mean I will create a patch that will work for older devices that
> > do not have the valid LED bits in eeprom.
>
> Ah ok. How can you know if the LED bits are valid (or not)?
>
There are version numbers and signatures that we may be able to use. I
am working with the firmware engineer to see if we can find a way.
> I consider this a bug in the eeprom and have set things in motion
> (in HP) to correct it since the card is not an obsolete product.
>
> Otherwise, the patch I submitted should be sufficient.
>
I am hoping to have a patch that will work for all older devices instead
of just checking for subvendor IDs, if possible. If not, we'll go with
your patch.
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Stephen Hemminger @ 2005-05-31 17:59 UTC (permalink / raw)
To: Andy Fleming; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com>
Here are some patches:
* allow phy's to be modules
* use driver owner for ref count
* make local functions static where ever possible
* get rid of bus read may sleep implication in comment.
since you are holding phy spin lock it better not!!
Untested since I don't have sungem, but am thinking about this for skge
driver.
Index: skge-phy/drivers/net/phy/davicom.c
===================================================================
--- skge-phy.orig/drivers/net/phy/davicom.c
+++ skge-phy/drivers/net/phy/davicom.c
@@ -60,13 +60,17 @@
#define MII_DM9161_10BTCSR 0x12
#define MII_DM9161_10BTCSR_INIT 0x7800
+MODULE_DESCRIPTION("Davicom PHY driver");
+MODULE_AUTHOR("Andy Fleming");
+MODULE_LICENSE("GPL");
+
struct dm9161_private {
struct timer_list timer;
int resetdone;
};
#define DM9161_DELAY 1
-int dm9161_config_intr(struct phy_device *phydev)
+static int dm9161_config_intr(struct phy_device *phydev)
{
int temp;
@@ -226,6 +230,7 @@ static struct phy_driver dm9161_driver =
.config_aneg = dm9161_config_aneg,
.read_status = genphy_read_status,
.remove = dm9161_remove,
+ .driver = { .owner = THIS_MODULE,},
};
static struct phy_driver dm9131_driver = {
@@ -238,38 +243,33 @@ static struct phy_driver dm9131_driver =
.read_status = genphy_read_status,
.ack_interrupt = dm9161_ack_interrupt,
.config_intr = dm9161_config_intr,
+ .driver = { .owner = THIS_MODULE,},
};
-int __init dm9161_init(void)
+static int __init davicom_init(void)
{
- int retval;
+ int ret;
- retval = phy_driver_register(&dm9161_driver);
+ ret = phy_driver_register(&dm9161_driver);
+ if (ret)
+ goto err1;
- return retval;
-}
+ ret = phy_driver_register(&dm9131_driver);
+ if (ret)
+ goto err2;
+ return 0;
-static void __exit dm9161_exit(void)
-{
+ err2:
phy_driver_unregister(&dm9161_driver);
+ err1:
+ return ret;
}
-module_init(dm9161_init);
-module_exit(dm9161_exit);
-
-int __init dm9131_init(void)
-{
- int retval;
-
- retval = phy_driver_register(&dm9131_driver);
-
- return retval;
-}
-
-static void __exit dm9131_exit(void)
+static void __exit davicom_exit(void)
{
+ phy_driver_unregister(&dm9161_driver);
phy_driver_unregister(&dm9131_driver);
}
-module_init(dm9131_init);
-module_exit(dm9131_exit);
+module_init(davicom_init);
+module_exit(davicom_exit);
Index: skge-phy/drivers/net/phy/marvell.c
===================================================================
--- skge-phy.orig/drivers/net/phy/marvell.c
+++ skge-phy/drivers/net/phy/marvell.c
@@ -45,6 +45,10 @@
#define MII_M1011_IMASK_INIT 0x6400
#define MII_M1011_IMASK_CLEAR 0x0000
+MODULE_DESCRIPTION("Marvell PHY driver");
+MODULE_AUTHOR("Andy Fleming");
+MODULE_LICENSE("GPL");
+
static int marvell_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -119,15 +123,12 @@ static struct phy_driver m88e1101_driver
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
+ .driver = { .owner = THIS_MODULE,},
};
-int __init marvell_init(void)
+static int __init marvell_init(void)
{
- int retval;
-
- retval = phy_driver_register(&m88e1101_driver);
-
- return retval;
+ return phy_driver_register(&m88e1101_driver);
}
static void __exit marvell_exit(void)
Index: skge-phy/drivers/net/phy/lxt.c
===================================================================
--- skge-phy.orig/drivers/net/phy/lxt.c
+++ skge-phy/drivers/net/phy/lxt.c
@@ -58,6 +58,10 @@
#define MII_LXT971_ISR 19 /* Interrupt Status Register */
+MODULE_DESCRIPTION("Intel LXT PHY driver");
+MODULE_AUTHOR("Andy Fleming");
+MODULE_LICENSE("GPL");
+
static int lxt970_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -130,6 +134,7 @@ static struct phy_driver lxt970_driver =
.read_status = genphy_read_status,
.ack_interrupt = lxt970_ack_interrupt,
.config_intr = lxt970_config_intr,
+ .driver = { .owner = THIS_MODULE,},
};
static struct phy_driver lxt971_driver = {
@@ -142,38 +147,33 @@ static struct phy_driver lxt971_driver =
.read_status = genphy_read_status,
.ack_interrupt = lxt971_ack_interrupt,
.config_intr = lxt971_config_intr,
+ .driver = { .owner = THIS_MODULE,},
};
-int __init lxt970_init(void)
+static int __init lxt_init(void)
{
- int retval;
+ int ret;
- retval = phy_driver_register(&lxt970_driver);
+ ret = phy_driver_register(&lxt970_driver);
+ if (ret)
+ goto err1;
- return retval;
-}
+ ret = phy_driver_register(&lxt971_driver);
+ if (ret)
+ goto err2;
+ return 0;
-static void __exit lxt970_exit(void)
-{
+ err2:
phy_driver_unregister(&lxt970_driver);
+ err1:
+ return ret;
}
-module_init(lxt970_init);
-module_exit(lxt970_exit);
-
-int __init lxt971_init(void)
-{
- int retval;
-
- retval = phy_driver_register(&lxt971_driver);
-
- return retval;
-}
-
-static void __exit lxt971_exit(void)
+static void __exit lxt_exit(void)
{
+ phy_driver_unregister(&lxt970_driver);
phy_driver_unregister(&lxt971_driver);
}
-module_init(lxt971_init);
-module_exit(lxt971_exit);
+module_init(lxt_init);
+module_exit(lxt_exit);
Index: skge-phy/drivers/net/phy/qsemi.c
===================================================================
--- skge-phy.orig/drivers/net/phy/qsemi.c
+++ skge-phy/drivers/net/phy/qsemi.c
@@ -59,9 +59,12 @@
#define QS6612_PCR_MLT3_DIS 0x0002
#define QS6612_PCR_SCRM_DESCRM 0x0001
+MODULE_DESCRIPTION("Quality Semiconductor PHY driver");
+MODULE_AUTHOR("Andy Fleming");
+MODULE_LICENSE("GPL");
/* Returns 0, unless there's a write error */
-int qs6612_probe(struct phy_device *phydev)
+static int qs6612_probe(struct phy_device *phydev)
{
/* The PHY powers up isolated on the RPX,
* so send a command to allow operation.
@@ -77,7 +80,7 @@ int qs6612_probe(struct phy_device *phyd
return phy_write(phydev, MII_QS6612_PCR, 0x0dc0);
}
-int qs6612_ack_interrupt(struct phy_device *phydev)
+static int qs6612_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -99,7 +102,7 @@ int qs6612_ack_interrupt(struct phy_devi
return 0;
}
-int qs6612_config_intr(struct phy_device *phydev)
+static int qs6612_config_intr(struct phy_device *phydev)
{
int err;
if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
@@ -123,15 +126,12 @@ static struct phy_driver qs6612_driver =
.read_status = genphy_read_status,
.ack_interrupt = qs6612_ack_interrupt,
.config_intr = qs6612_config_intr,
+ .driver = { .owner = THIS_MODULE,},
};
-int __init qs6612_init(void)
+static int __init qs6612_init(void)
{
- int retval;
-
- retval = phy_driver_register(&qs6612_driver);
-
- return retval;
+ return phy_driver_register(&qs6612_driver);
}
static void __exit qs6612_exit(void)
Index: skge-phy/drivers/net/phy/phy_device.c
===================================================================
--- skge-phy.orig/drivers/net/phy/phy_device.c
+++ skge-phy/drivers/net/phy/phy_device.c
@@ -370,7 +370,7 @@ int genphy_config_advert(struct phy_devi
return adv;
}
-
+EXPORT_SYMBOL(genphy_config_advert);
/* genphy_setup_forced
*
@@ -443,7 +443,7 @@ int genphy_config_aneg(struct phy_device
return err;
}
-
+EXPORT_SYMBOL(genphy_config_aneg);
/* genphy_update_link
*
@@ -567,7 +567,7 @@ int genphy_read_status(struct phy_device
return 0;
}
-
+EXPORT_SYMBOL(genphy_read_status);
static int genphy_probe(struct phy_device *phydev)
{
@@ -624,7 +624,7 @@ static int genphy_probe(struct phy_devic
* set the state to READY (the driver's probe function should
* set it to STARTING if needed).
*/
-int phy_probe(struct device *dev)
+static int phy_probe(struct device *dev)
{
struct phy_device *phydev;
struct phy_driver *phydrv;
@@ -662,7 +662,7 @@ int phy_probe(struct device *dev)
return err;
}
-int phy_remove(struct device *dev)
+static int phy_remove(struct device *dev)
{
struct phy_device *phydev;
@@ -701,13 +701,15 @@ int phy_driver_register(struct phy_drive
return retval;
}
+EXPORT_SYMBOL(phy_driver_register);
void phy_driver_unregister(struct phy_driver *drv)
{
driver_unregister(&drv->driver);
}
+EXPORT_SYMBOL(phy_driver_unregister);
-struct phy_driver genphy_driver = {
+static struct phy_driver genphy_driver = {
.phy_id = 0xffffffff,
.phy_id_mask = 0xffffffff,
.name = "Generic PHY",
@@ -715,15 +717,13 @@ struct phy_driver genphy_driver = {
.features = 0,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
+ .driver = {.owner = THIS_MODULE, },
};
static int __init genphy_init(void)
{
- int retval;
-
- retval = phy_driver_register(&genphy_driver);
+ return phy_driver_register(&genphy_driver);
- return retval;
}
static void __exit genphy_exit(void)
Index: skge-phy/drivers/net/phy/mdio_bus.c
===================================================================
--- skge-phy.orig/drivers/net/phy/mdio_bus.c
+++ skge-phy/drivers/net/phy/mdio_bus.c
@@ -124,7 +124,7 @@ EXPORT_SYMBOL(unregister_mdiobus);
* description: Given a PHY device, and a PHY driver, return 1 if
* the driver supports the device. Otherwise, return 0
*/
-int mdio_bus_match(struct device *dev, struct device_driver *drv)
+static int mdio_bus_match(struct device *dev, struct device_driver *drv)
{
struct phy_device *phydev = to_phy_device(dev);
struct phy_driver *phydrv = to_phy_driver(drv);
@@ -170,7 +170,7 @@ struct bus_type mdio_bus_type = {
.resume = mdio_bus_resume,
};
-int __init mdio_bus_init(void)
+static int __init mdio_bus_init(void)
{
return bus_register(&mdio_bus_type);
}
Index: skge-phy/drivers/net/phy/cicada.c
===================================================================
--- skge-phy.orig/drivers/net/phy/cicada.c
+++ skge-phy/drivers/net/phy/cicada.c
@@ -65,6 +65,9 @@
#define MII_CIS8201_AUXCONSTAT_GBIT 0x0010
#define MII_CIS8201_AUXCONSTAT_100 0x0008
+MODULE_DESCRIPTION("Cicadia PHY driver");
+MODULE_AUTHOR("Andy Fleming");
+MODULE_LICENSE("GPL");
static int cis820x_probe(struct phy_device *phydev)
{
@@ -104,9 +107,9 @@ static int cis820x_config_intr(struct ph
/* Cicada 820x */
static struct phy_driver cis8204_driver = {
- 0x000fc440,
- "Cicada Cis8204",
- 0x000fffc0,
+ .phy_id = 0x000fc440,
+ .name = "Cicada Cis8204",
+ .phy_id_mask = 0x000fffc0,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.probe = &cis820x_probe,
@@ -114,15 +117,12 @@ static struct phy_driver cis8204_driver
.read_status = &genphy_read_status,
.ack_interrupt = &cis820x_ack_interrupt,
.config_intr = &cis820x_config_intr,
+ .driver = { .owner = THIS_MODULE,},
};
-int __init cis8204_init(void)
+static int __init cis8204_init(void)
{
- int retval;
-
- retval = phy_driver_register(&cis8204_driver);
-
- return retval;
+ return phy_driver_register(&cis8204_driver);
}
static void __exit cis8204_exit(void)
Index: skge-phy/drivers/net/phy/phy.c
===================================================================
--- skge-phy.orig/drivers/net/phy/phy.c
+++ skge-phy/drivers/net/phy/phy.c
@@ -42,10 +42,7 @@
int phy_read(struct phy_device *phydev, u16 regnum);
int phy_write(struct phy_device *phydev, u16 regnum, u16 val);
-/* Convenience functions for reading a given PHY register.
- * This MUST NOT be called from interrupt context,
- * because the bus read function may sleep
- * or generally lock up. */
+/* Convenience functions for reading a given PHY register. */
int phy_read(struct phy_device *phydev, u16 regnum)
{
int retval;
@@ -57,6 +54,7 @@ int phy_read(struct phy_device *phydev,
return retval;
}
+EXPORT_SYMBOL(phy_read);
int phy_write(struct phy_device *phydev, u16 regnum, u16 val)
{
@@ -69,6 +67,7 @@ int phy_write(struct phy_device *phydev,
return err;
}
+EXPORT_SYMBOL(phy_write);
int phy_clear_interrupt(struct phy_device *phydev)
@@ -236,7 +235,7 @@ static inline int phy_find_valid(int idx
* duplexes. Drop down by one in this order: 1000/FULL,
* 1000/HALF, 100/FULL, 100/HALF, 10/FULL, 10/HALF
*/
-void phy_sanitize_settings(struct phy_device *phydev)
+static void phy_sanitize_settings(struct phy_device *phydev)
{
u32 features = phydev->supported;
int idx;
@@ -260,7 +259,7 @@ void phy_sanitize_settings(struct phy_de
* 1000/FULL, 1000/HALF, 100/FULL, 100/HALF,
* 10/FULL, 10/HALF. The function bottoms out at 10/HALF.
*/
-void phy_force_reduction(struct phy_device *phydev)
+static void phy_force_reduction(struct phy_device *phydev)
{
int idx;
@@ -323,7 +322,7 @@ static irqreturn_t phy_interrupt(int irq
* Otherwise, we enable the interrupts in the PHY.
* Returns 0 on success.
*/
-int phy_start_interrupts(struct phy_device *phydev)
+static int phy_start_interrupts(struct phy_device *phydev)
{
int err = 0;
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Mitch Williams @ 2005-05-31 17:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Williams, Mitch A, jamal, netdev, Robert.Olsson, Ronciak, John,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <20050531104011.654ad281@dxpl.pdx.osdl.net>
On Tue, 31 May 2005, Stephen Hemminger wrote:
>
> Like this (untested) patch:
>
Gosh, you're making my life too easy. Thanks!
I'll apply this, give it a spin, and let you know what I see.
-Mitch
^ permalink raw reply
* Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way)
From: Michael Chan @ 2005-05-31 17:42 UTC (permalink / raw)
To: Grant Grundler; +Cc: David S. Miller, Peter Chubb, netdev
In-Reply-To: <20050531183653.GF20793@esmail.cup.hp.com>
On Tue, 2005-05-31 at 11:36 -0700, Grant Grundler wrote:
> On Tue, May 31, 2005 at 10:22:37AM -0700, Michael Chan wrote:
> > Thanks Grant, I'll chase this down and find a solution to this problem.
>
> You mean you'll help find a way to reflash the onboard eeprom?
>
No, I mean I will create a patch that will work for older devices that
do not have the valid LED bits in eeprom.
Thanks.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Stephen Hemminger @ 2005-05-31 17:40 UTC (permalink / raw)
To: Mitch Williams
Cc: jamal, Williams, Mitch A, netdev, Robert.Olsson, Ronciak, John,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <Pine.CYG.4.58.0505311029510.2128@mawilli1-desk2.amr.corp.intel.com>
Like this (untested) patch:
Index: napi-sysfs/net/core/net-sysfs.c
===================================================================
--- napi-sysfs.orig/net/core/net-sysfs.c
+++ napi-sysfs/net/core/net-sysfs.c
@@ -184,6 +184,22 @@ static ssize_t store_tx_queue_len(struct
static CLASS_DEVICE_ATTR(tx_queue_len, S_IRUGO | S_IWUSR, show_tx_queue_len,
store_tx_queue_len);
+NETDEVICE_SHOW(weight, fmt_ulong);
+
+static int change_weight(struct net_device *net, unsigned long new_weight)
+{
+ net->weight = new_weight;
+ return 0;
+}
+
+static ssize_t store_weight(struct class_device *dev, const char *buf, size_t len)
+{
+ return netdev_store(dev, buf, len, change_weight);
+}
+
+static CLASS_DEVICE_ATTR(weight, S_IRUGO | S_IWUSR, show_weight,
+ store_weight);
+
static struct class_device_attribute *net_class_attributes[] = {
&class_device_attr_ifindex,
@@ -193,6 +209,7 @@ static struct class_device_attribute *ne
&class_device_attr_features,
&class_device_attr_mtu,
&class_device_attr_flags,
+ &class_device_attr_weight,
&class_device_attr_type,
&class_device_attr_address,
&class_device_attr_broadcast,
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Mitch Williams @ 2005-05-31 17:35 UTC (permalink / raw)
To: jamal
Cc: Stephen Hemminger, Williams, Mitch A, netdev, Robert.Olsson,
Ronciak, John, Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <1117241786.6251.7.camel@localhost.localdomain>
On Fri, 27 May 2005, jamal wrote:
>
> On Fri, 2005-27-05 at 14:01 -0700, Stephen Hemminger wrote:
>
> >
> > Why not just allow adjusting dev->weight via sysfs?
>
> I think that should be good enough - and i thought your patch already
> did this.
> Adding a shift to the weight in a _weighted_ RR algorithm does sound
> odd.
>
Stephen's patch only affects the weight for the backlog device. Exporting
dev-> weight to sysfs will allow the weight to be set for any network
device. Which makes perfect sense.
I'll work on getting this done and verifying performance this week.
Expect a patch in a few days.
Thanks, guys.
-Mitch
^ permalink raw reply
* Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way)
From: Michael Chan @ 2005-05-31 17:22 UTC (permalink / raw)
To: Grant Grundler; +Cc: David S. Miller, Peter Chubb, netdev
In-Reply-To: <20050531153819.GA20793@esmail.cup.hp.com>
On Tue, 2005-05-31 at 08:38 -0700, Grant Grundler wrote:
> Michael,
> Peter bounced this email to me after we talked about issues he was
> having with the rx8620 (HP 16-way ia64, sx1000 chipset) "IOX Core LAN".
> It sounded like the same problem I tracked down with rx8620 IOX Core LAN
> in March. Here is the summary :
>
> | In May, 2004, tg3 v3.4 changed how MAC_LED_CTRL (0x40c) was getting
> | programmed and how to determine what to program into LED_CTRL. The new
> | code trusted NIC_SRAM_DATA_CFG (0x00000b58) to indicate what to write
> | to LED_CTRL and MII EXT_CTRL registers. On "IOX Core Lan", SRAM was
> | saying MODE_MAC (0x0) and that doesn't work.
>
Thanks Grant, I'll chase this down and find a solution to this problem.
^ permalink raw reply
* Re: [PATCH] use mmiowb in tg3_poll
From: Jesse Barnes @ 2005-05-31 16:45 UTC (permalink / raw)
To: hadi; +Cc: Arthur Kepner, Lennert Buytenhek, netdev, gnb
In-Reply-To: <1117544022.6134.54.camel@localhost.localdomain>
On Tuesday, May 31, 2005 5:53 am, jamal wrote:
> Did i read correctly that your reads are about 2x more expensive than
> the writes?
The test above just measures the difference between using a full PIO
read to ensure write ordering vs. the lighter weight mmiowb call. As
for your question though, non-relaxed reads are very expensive on the
Altix platform due to its highly distributed NUMA I/O architecture.
The _relaxed variants can be quite fast however, and can be used
anytime a PIO read doesn't imply anything about previous DMA
transactions.
Jesse
^ 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