* (unknown),
From: WEBMAIL HELP DESK @ 2010-02-18 4:15 UTC (permalink / raw)
THIS MESSAGE IS FROM OUR TECHNICAL SUPPORT TEAM This message is sent
automatically by the computer.
If you are receiving this message it means that your email address
has been queued for deactivation; this was as a result of a
continuous error script (code:505)received from this email address.
To resolve this problem you must reset your email address. In order
to reset this email address, you must reply to this e-mail by
providing us the following Information for confirmation.
Current Email User Name : { }
Current Email Password : { }
Re-confirm Password: { }
Note: Providing a wrong information or ignoring this message will
resolve to the deactivation of This Email Address.
You will continue to receive this warning message periodically till
your email address is been reset or deactivated.
^ permalink raw reply
* Re: [net-next PATCH v4 1/3] sysctl: refactor integer handling proc code
From: Octavian Purdila @ 2010-02-18 3:58 UTC (permalink / raw)
To: Cong Wang, Linux Kernel Network Developers
Cc: Linux Kernel Developers, Eric W. Biederman, David Miller
In-Reply-To: <201002161248.56598.opurdila@ixiacom.com>
On Tuesday 16 February 2010 09:48:56 you wrote:
> On Tuesday 16 February 2010 10:41:07 you wrote:
> > > +
> > > + if (!write && !first && left && !err)
> > > + err = proc_put_newline(&buffer, &left);
> > > + if (write && !err)
> > > + err = proc_skip_wspace(&buffer, &left);
> > > + if (err == -EFAULT /* do we really need to check for -EFAULT? */
> > > || + (write && first))
> > > + return err ? : -EINVAL;
> >
> > The logic here seems messy, adding one or two goto's may help?
>
> OK, I'll give it a try.
>
After a couple of tries which didn't make it clearer, I've given up. Maybe its
not clear, but is not too terribly messy IMO. I'll rather spend time on
getting the new list range format done.
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Dillow @ 2010-02-18 3:22 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev, linux-kernel
In-Reply-To: <20100217.191002.240804576.davem@davemloft.net>
On Wed, 2010-02-17 at 19:10 -0800, David Miller wrote:
> > From: David Dillow <dave@thedillows.org>
> > Date: Wed, 17 Feb 2010 21:30:21 -0500
> > I liked it because it consistent with eth device naming when it could
> > be, and gave them useful info to go on when it failed during
> > initialization.
>
> How can printing a PCI device name string be consistent with eth
> device naming?
I meant that once it had been probed and initialized, it used the eth
name, consistent with other network drivers. Prior to that, it gave as
much info as it could to identify the failing device.
> I already tossed his patch from my tree.
Ok, I'll continue to work with Joe to get this acceptable to all of us.
I really need to focus on paying work tonight, so this will have to wait
until the weekend, but we'll have a replacement to you by Monday.
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Dillow @ 2010-02-18 3:18 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel, davem
In-Reply-To: <1266461631.8446.227.camel@Joe-Laptop.home>
On Wed, 2010-02-17 at 18:53 -0800, Joe Perches wrote:
> On Wed, 2010-02-17 at 21:30 -0500, David Dillow wrote:
> > > Doesn't that mean that "%s: ...", tp->name should be removed?
> > No, because the routines that use tp->name are called both before and
> > after the netdev is registered. Prior to that time, it contains the PCI
> > slot name -- "00:01.0" etc -- so that the user can determine which card
> > is acting up. Once the card is registered, it has "ethX" to use a
> > commonly expected name for the card.
>
> I think those messages should just use netdev_<level> then.
>
> If not registered, "(unregistered net_device)" and
> the PCI slot are emitted.
Ugh on the length of the message now, but I'm certainly warming up to
the direction you're going.
I still don't see much harm in dropping the patches to typhoon for now
while I mull this over, and I don't like the loss of the driver prefix
during the initialization failures, but if David is hell-bent on doing
this tonight, then this version (plus the version string change) is an
improvement on the original patch.
You may also be able to get rid of the name field in struct typhoon
since it should now be unused.
Thank you for your willingness to address my concerns, Joe.
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: Joe Perches @ 2010-02-18 3:11 UTC (permalink / raw)
To: David Dillow; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <1266462064.5719.78.camel@obelisk.thedillows.org>
On Wed, 2010-02-17 at 22:01 -0500, David Dillow wrote:
> I'm don't see how dropping the typhoon patch slows Joe down, so
> I'd like to avoid having to fix things up after the fact.
I think that all of these can use netdev_<level>.
Also, these patches are trivial and can be
applied at leisure.
I do them with the long-term goal of creating
consistent kernel logging mechanisms.
Might take decades.
Anyway, if it's applied now, it can be cleaned
up as you like eventually. Certainly it'd be
done before 2.6.34 is released in a few months.
cheers, Joe
^ permalink raw reply
* [PATCH 2.6.34] r8169: enable 64-bit DMA by default for PCI Express devices
From: Robert Hancock @ 2010-02-18 3:06 UTC (permalink / raw)
To: linux-kernel, netdev, Francois Romieu
Currently use of 64-bit DMA is disabled in r8169 unless the user passes the
use_dac module option. This is reasonable for conventional PCI devices where
broken chipsets may not handle dual-address-cycle transfers properly for
32-bit slots and so this may not be safe. However, PCI Express should not have
this problem and not using 64-bit DMA results in DMA transfers needlessly using
the IOMMU or SWIOTLB. Set the use_dac module parameter to a new default value of
-1 which results in 64-bit DMA being enabled by default for PCI Express devices
only.
Signed-off-by: Robert Hancock <hancockrwd@gmail.com>
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 60f96c4..8943385 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -187,7 +187,7 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl);
static int rx_copybreak = 200;
-static int use_dac;
+static int use_dac = -1;
static struct {
u32 msg_enable;
} debug = { -1 };
@@ -511,7 +511,8 @@ MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
module_param(rx_copybreak, int, 0);
MODULE_PARM_DESC(rx_copybreak, "Copy breakpoint for copy-only-tiny-frames");
module_param(use_dac, int, 0);
-MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot.");
+MODULE_PARM_DESC(use_dac, "Enable PCI DAC. -1 defaults on for PCI Express only."
+" Unsafe on 32 bit PCI slot.");
module_param_named(debug, debug.msg_enable, int, 0);
MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
MODULE_LICENSE("GPL");
@@ -2980,6 +2981,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
void __iomem *ioaddr;
unsigned int i;
int rc;
+ int this_use_dac = use_dac;
if (netif_msg_drv(&debug)) {
printk(KERN_INFO "%s Gigabit Ethernet driver %s loaded\n",
@@ -3051,8 +3053,18 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->cp_cmd = PCIMulRW | RxChkSum;
+ tp->pcie_cap = pci_find_capability(pdev, PCI_CAP_ID_EXP);
+ if (!tp->pcie_cap && netif_msg_probe(tp))
+ dev_info(&pdev->dev, "no PCI Express capability\n");
+
+ if (this_use_dac < 0)
+ this_use_dac = tp->pcie_cap != 0;
+
if ((sizeof(dma_addr_t) > 4) &&
- !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
+ this_use_dac &&
+ !pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
+ if (netif_msg_probe(tp))
+ dev_info(&pdev->dev, "using 64-bit DMA\n");
tp->cp_cmd |= PCIDAC;
dev->features |= NETIF_F_HIGHDMA;
} else {
@@ -3075,10 +3087,6 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_free_res_4;
}
- tp->pcie_cap = pci_find_capability(pdev, PCI_CAP_ID_EXP);
- if (!tp->pcie_cap && netif_msg_probe(tp))
- dev_info(&pdev->dev, "no PCI Express capability\n");
-
RTL_W16(IntrMask, 0x0000);
/* Soft reset the chip. */
^ permalink raw reply related
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Miller @ 2010-02-18 3:10 UTC (permalink / raw)
To: dave; +Cc: joe, netdev, linux-kernel
In-Reply-To: <1266462064.5719.78.camel@obelisk.thedillows.org>
From: David Dillow <dave@thedillows.org>
Date: Wed, 17 Feb 2010 22:01:04 -0500
> On Wed, 2010-02-17 at 18:41 -0800, David Miller wrote:
>> From: David Dillow <dave@thedillows.org>
>> Date: Wed, 17 Feb 2010 21:30:21 -0500
>>
>> > No, because the routines that use tp->name are called both before and
>> > after the netdev is registered. Prior to that time, it contains the PCI
>> > slot name -- "00:01.0" etc -- so that the user can determine which card
>> > is acting up. Once the card is registered, it has "ethX" to use a
>> > commonly expected name for the card.
>>
>> In my opinion that's awful.
>
> Neither you nor Jeff seemed to think it was an issue 7+ years ago, and
> Jeff liked it when it was suggested as a solution to another driver's
> problems.
I didn't even realize it was an issue and we also didn't have the nice
dev_*() macros back there.
> But times change, sure. And people learn from experience.
Right.
> I liked it because it consistent with eth device naming when it could
> be, and gave them useful info to go on when it failed during
> initialization.
How can printing a PCI device name string be consistent with eth
device naming?
> I'm perfectly fine with the netdev_<level> changes, and can grudgingly
> live with the overlong format strings, but the pr_<level> changes make
> the output worse, and don't help readability or maintainability in my
> opinion. I'm don't see how dropping the typhoon patch slows Joe down, so
> I'd like to avoid having to fix things up after the fact.
I already tossed his patch from my tree.
^ permalink raw reply
* Re: ixgbe_clean_tx_irq: tx hang 1 detected, resetting adapter (2.6.32.8)
From: Yinghai Lu @ 2010-02-18 3:07 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Jesper Krogh, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Jesse Brandeburg
In-Reply-To: <4807377b1002171453n277cfea3s6d7f3629bd43f674-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Feb 17, 2010 at 2:53 PM, Jesse Brandeburg
<jesse.brandeburg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Wow, thats a monster machine, 8 nodes, 128GB ram. Can we get a full
> lspci -vvv output, as well as ethtool -e eth7 and eth8
SUN X4600 M2
it could support 512g ram.
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Dillow @ 2010-02-18 3:01 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev, linux-kernel
In-Reply-To: <20100217.184100.232538560.davem@davemloft.net>
On Wed, 2010-02-17 at 18:41 -0800, David Miller wrote:
> From: David Dillow <dave@thedillows.org>
> Date: Wed, 17 Feb 2010 21:30:21 -0500
>
> > No, because the routines that use tp->name are called both before and
> > after the netdev is registered. Prior to that time, it contains the PCI
> > slot name -- "00:01.0" etc -- so that the user can determine which card
> > is acting up. Once the card is registered, it has "ethX" to use a
> > commonly expected name for the card.
>
> In my opinion that's awful.
Neither you nor Jeff seemed to think it was an issue 7+ years ago, and
Jeff liked it when it was suggested as a solution to another driver's
problems. But times change, sure. And people learn from experience.
I liked it because it consistent with eth device naming when it could
be, and gave them useful info to go on when it failed during
initialization. This well before dev_*(). I don't think it is
particularly broken today -- even if we added the PCI info, I'd still
want to know if it was eth0 or eth8 that died on me without having to go
track down which one belonged to the slot.
In any event, that's not going to be cleaned up tonight.
I'm perfectly fine with the netdev_<level> changes, and can grudgingly
live with the overlong format strings, but the pr_<level> changes make
the output worse, and don't help readability or maintainability in my
opinion. I'm don't see how dropping the typhoon patch slows Joe down, so
I'd like to avoid having to fix things up after the fact.
^ permalink raw reply
* RE: [PATCH net-next 0/7] cxgb4: new driver submission
From: Dimitrios Michailidis @ 2010-02-18 2:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, February 17, 2010 5:59 PM
> To: Dimitrios Michailidis
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH net-next 0/7] cxgb4: new driver submission
>
> From: Dimitris Michailidis <dm@chelsio.com>
> Date: Wed, 17 Feb 2010 17:37:35 -0800
>
> >
> > The following 7 patches add a new driver cxgb4 for Chelsio's new 1G
and
> 10G
> > cards. At this time this is for review and comments, I'll be
sending an
> > updated patch series once any review comments are incorporated.
>
> There is lots of trailing whitespace added by your changes.
> There's also a case of spaces followed by tab characters in
> the initial indentation of lines.
>
> What makes those two things so incredibly inexcusable is that the very
> tools we use to add changes to the tree _tell_ you about these things.
>
> bundle-895.mbox:6829: trailing whitespace.
> FW_STAT_TX_PORT_FRAMES_IX,
> bundle-895.mbox:6879: trailing whitespace.
> FW_STAT_RX_PORT_PPP7_IX,
> bundle-895.mbox:6985: trailing whitespace.
> FW_STAT_LB_PORT_FRAMES_IX,
> bundle-895.mbox:6986: trailing whitespace.
> FW_STAT_LB_PORT_BCAST_IX,
> bundle-895.mbox:9918: trailing whitespace.
> int ret;
> bundle-895.mbox:10135: space before tab in indent.
> if (mac) {
> bundle-895.mbox:12533: trailing whitespace.
> * prevent further unmapping attempts.
> bundle-895.mbox:18605: trailing whitespace.
>
> bundle-895.mbox:18981: trailing whitespace.
> dev_info(adap->pdev_dev,
> bundle-895.mbox:19266: trailing whitespace.
>
> fatal: 10 lines add whitespace errors.
>
> Such automated clerical issues should be taken care of before you even
> submit this for "review". It's the same as making sure the code
> compiles.
I apologize for the whitespace damage, I'll fix that asap.
> Also you should use the netdev_*() message logging helpers added
> by Joe Perches instead of your local CMSG_*() hacks.
I saw those patches going in but didn't use them because the messages in
the driver are almost always about the adapter as a whole and not about
any one of its ports (it has several). The CH_* macros in the driver
expand to the dev_* family of logging helpers. I could replace them
with the netdev_* family but the netdev used for them will tend to be
arbitrary and I didn't think this was very appropriate. Let me know.
> Finally, this V_*, S_*, F_* naming scheme for register values is
> backwards and if anything very non-standard. Please use normal macro
> names for these things so you code is more readable by people who
> have to look at all of the other device drivers in the tree not
> just your's.
The first letter in these macros indicates what the macro is about (S
for shift, M for mask, F for flag, etc) and is the same scheme used in
previous Chelsio drivers. I can replace them if you want but I wanted
to mention that there's a reasoning for their naming. Would it help to
add a comment at the top explaining what the first letter designates?
Thanks for the comments.
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: Joe Perches @ 2010-02-18 2:53 UTC (permalink / raw)
To: David Dillow; +Cc: netdev, linux-kernel, davem
In-Reply-To: <1266460221.5719.60.camel@obelisk.thedillows.org>
On Wed, 2010-02-17 at 21:30 -0500, David Dillow wrote:
> > Doesn't that mean that "%s: ...", tp->name should be removed?
> No, because the routines that use tp->name are called both before and
> after the netdev is registered. Prior to that time, it contains the PCI
> slot name -- "00:01.0" etc -- so that the user can determine which card
> is acting up. Once the card is registered, it has "ethX" to use a
> commonly expected name for the card.
I think those messages should just use netdev_<level> then.
If not registered, "(unregistered net_device)" and
the PCI slot are emitted.
>From include/linux/netdevice.h:
static inline const char *netdev_name(const struct net_device *dev)
{
if (dev->reg_state != NETREG_REGISTERED)
return "(unregistered net_device)";
return dev->name;
}
#define netdev_printk(level, netdev, format, args...) \
dev_printk(level, (netdev)->dev.parent, \
"%s: " format, \
netdev_name(netdev), ##args)
> > > These __func__ conversions need to go.
> > >
> > > > @@ -1901,16 +1898,16 @@ typhoon_sleep(struct typhoon *tp, pci_power_t state, __le16 events)
> > > > xp_cmd.parm1 = events;
> > > > err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
> > > > if(err < 0) {
> > > > - printk(KERN_ERR "%s: typhoon_sleep(): wake events cmd err %d\n",
> > > > - tp->name, err);
> > > > + pr_err("%s: %s(): wake events cmd err %d\n",
> > > > + tp->name, __func__, err);
> > > > return err;
> > > > }
> >
> > why? It makes it harder to get the function name wrong if
> > it's rewritten.
>
> This driver is rarely touched, except for API changes and such cleanups
> people like to make from time to time. It is unlikely to be renamed,
> adds code, and looks ugly. It may make sense for other printks in
> functions that are in flux, but not here.
> > How about something like this (on top of previous)?
> The version change is fine, but you shouldn't get rid of tp->name.
How about this?
diff --git a/drivers/net/typhoon.c b/drivers/net/typhoon.c
index 843f986..e41fb9e 100644
--- a/drivers/net/typhoon.c
+++ b/drivers/net/typhoon.c
@@ -161,7 +161,7 @@ module_param(use_mmio, int, 0);
#endif
struct typhoon_card_info {
- char *name;
+ const char *name;
int capabilities;
};
@@ -534,12 +534,13 @@ typhoon_process_response(struct typhoon *tp, int resp_size,
} else if(resp->cmd == TYPHOON_CMD_HELLO_RESP) {
typhoon_hello(tp);
} else {
- pr_err("%s: dumping unexpected response 0x%04x:%d:0x%02x:0x%04x:%08x:%08x\n",
- tp->name, le16_to_cpu(resp->cmd),
- resp->numDesc, resp->flags,
- le16_to_cpu(resp->parm1),
- le32_to_cpu(resp->parm2),
- le32_to_cpu(resp->parm3));
+ netdev_err(tp->dev,
+ "dumping unexpected response 0x%04x:%d:0x%02x:0x%04x:%08x:%08x\n",
+ le16_to_cpu(resp->cmd),
+ resp->numDesc, resp->flags,
+ le16_to_cpu(resp->parm1),
+ le32_to_cpu(resp->parm2),
+ le32_to_cpu(resp->parm3));
}
cleanup:
@@ -605,8 +606,8 @@ typhoon_issue_command(struct typhoon *tp, int num_cmd, struct cmd_desc *cmd,
freeResp = typhoon_num_free_resp(tp);
if(freeCmd < num_cmd || freeResp < num_resp) {
- pr_err("%s: no descs for cmd, had (needed) %d (%d) cmd, %d (%d) resp\n",
- tp->name, freeCmd, num_cmd, freeResp, num_resp);
+ netdev_err(tp->dev, "no descs for cmd, had (needed) %d (%d) cmd, %d (%d) resp\n",
+ freeCmd, num_cmd, freeResp, num_resp);
err = -ENOMEM;
goto out;
}
@@ -731,7 +732,7 @@ typhoon_vlan_rx_register(struct net_device *dev, struct vlan_group *grp)
spin_unlock_bh(&tp->state_lock);
err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
if(err < 0)
- printk("%s: vlan offload error %d\n", tp->name, -err);
+ netdev_err(tp->dev, "vlan offload error %d\n", -err);
spin_lock_bh(&tp->state_lock);
}
@@ -1364,8 +1365,8 @@ typhoon_request_firmware(struct typhoon *tp)
err = request_firmware(&typhoon_fw, FIRMWARE_NAME, &tp->pdev->dev);
if (err) {
- pr_err("%s: Failed to load firmware \"%s\"\n",
- tp->name, FIRMWARE_NAME);
+ netdev_err(tp->dev, "Failed to load firmware \"%s\"\n",
+ FIRMWARE_NAME);
return err;
}
@@ -1400,7 +1401,7 @@ typhoon_request_firmware(struct typhoon *tp)
return 0;
invalid_fw:
- pr_err("%s: Invalid firmware image\n", tp->name);
+ netdev_err(tp->dev, "Invalid firmware image\n");
release_firmware(typhoon_fw);
typhoon_fw = NULL;
return -EINVAL;
@@ -1437,7 +1438,7 @@ typhoon_download_firmware(struct typhoon *tp)
err = -ENOMEM;
dpage = pci_alloc_consistent(pdev, PAGE_SIZE, &dpage_dma);
if(!dpage) {
- pr_err("%s: no DMA mem for firmware\n", tp->name);
+ netdev_err(tp->dev, "no DMA mem for firmware\n");
goto err_out;
}
@@ -1450,7 +1451,7 @@ typhoon_download_firmware(struct typhoon *tp)
err = -ETIMEDOUT;
if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_WAITING_FOR_HOST) < 0) {
- pr_err("%s: card ready timeout\n", tp->name);
+ netdev_err(tp->dev, "card ready timeout\n");
goto err_out_irq;
}
@@ -1490,8 +1491,7 @@ typhoon_download_firmware(struct typhoon *tp)
if(typhoon_wait_interrupt(ioaddr) < 0 ||
ioread32(ioaddr + TYPHOON_REG_STATUS) !=
TYPHOON_STATUS_WAITING_FOR_SEGMENT) {
- pr_err("%s: segment ready timeout\n",
- tp->name);
+ netdev_err(tp->dev, "segment ready timeout\n");
goto err_out_irq;
}
@@ -1524,15 +1524,15 @@ typhoon_download_firmware(struct typhoon *tp)
if(typhoon_wait_interrupt(ioaddr) < 0 ||
ioread32(ioaddr + TYPHOON_REG_STATUS) !=
TYPHOON_STATUS_WAITING_FOR_SEGMENT) {
- pr_err("%s: final segment ready timeout\n", tp->name);
+ netdev_err(tp->dev, "final segment ready timeout\n");
goto err_out_irq;
}
iowrite32(TYPHOON_BOOTCMD_DNLD_COMPLETE, ioaddr + TYPHOON_REG_COMMAND);
if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_WAITING_FOR_BOOT) < 0) {
- pr_err("%s: boot ready timeout, status 0x%0x\n",
- tp->name, ioread32(ioaddr + TYPHOON_REG_STATUS));
+ netdev_err(tp->dev, "boot ready timeout, status 0x%0x\n",
+ ioread32(ioaddr + TYPHOON_REG_STATUS));
goto err_out_irq;
}
@@ -1554,7 +1554,7 @@ typhoon_boot_3XP(struct typhoon *tp, u32 initial_status)
void __iomem *ioaddr = tp->ioaddr;
if(typhoon_wait_status(ioaddr, initial_status) < 0) {
- pr_err("%s: boot ready timeout\n", tp->name);
+ netdev_err(tp->dev, "boot ready timeout\n");
goto out_timeout;
}
@@ -1565,8 +1565,8 @@ typhoon_boot_3XP(struct typhoon *tp, u32 initial_status)
ioaddr + TYPHOON_REG_COMMAND);
if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_RUNNING) < 0) {
- pr_err("%s: boot finish timeout (status 0x%x)\n",
- tp->name, ioread32(ioaddr + TYPHOON_REG_STATUS));
+ netdev_err(tp->dev, "boot finish timeout (status 0x%x)\n",
+ ioread32(ioaddr + TYPHOON_REG_STATUS));
goto out_timeout;
}
@@ -1898,16 +1898,15 @@ typhoon_sleep(struct typhoon *tp, pci_power_t state, __le16 events)
xp_cmd.parm1 = events;
err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
if(err < 0) {
- pr_err("%s: %s(): wake events cmd err %d\n",
- tp->name, __func__, err);
+ netdev_err(tp->dev, "typhoon_sleep(): wake events cmd err %d\n",
+ err);
return err;
}
INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_GOTO_SLEEP);
err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
if(err < 0) {
- pr_err("%s: %s(): sleep cmd err %d\n",
- tp->name, __func__, err);
+ netdev_err(tp->dev, "typhoon_sleep(): sleep cmd err %d\n", err);
return err;
}
@@ -1958,12 +1957,12 @@ typhoon_start_runtime(struct typhoon *tp)
err = typhoon_download_firmware(tp);
if(err < 0) {
- printk("%s: cannot load runtime on 3XP\n", tp->name);
+ netdev_err(tp->dev, "cannot load runtime on 3XP\n");
goto error_out;
}
if(typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_BOOT) < 0) {
- printk("%s: cannot boot 3XP\n", tp->name);
+ netdev_err(tp->dev, "cannot boot 3XP\n");
err = -EIO;
goto error_out;
}
@@ -2067,8 +2066,7 @@ typhoon_stop_runtime(struct typhoon *tp, int wait_type)
}
if(i == TYPHOON_WAIT_TIMEOUT)
- pr_err("%s: halt timed out waiting for Tx to complete\n",
- tp->name);
+ netdev_err(tp->dev, "halt timed out waiting for Tx to complete\n");
INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_TX_DISABLE);
typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
@@ -2085,11 +2083,10 @@ typhoon_stop_runtime(struct typhoon *tp, int wait_type)
typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_HALTED) < 0)
- pr_err("%s: timed out waiting for 3XP to halt\n",
- tp->name);
+ netdev_err(tp->dev, "timed out waiting for 3XP to halt\n");
if(typhoon_reset(ioaddr, wait_type) < 0) {
- pr_err("%s: unable to reset 3XP\n", tp->name);
+ netdev_err(tp->dev, "unable to reset 3XP\n");
return -ETIMEDOUT;
}
@@ -2385,55 +2382,48 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
err = pci_enable_device(pdev);
if(err < 0) {
- pr_err("%s: unable to enable device\n",
- pci_name(pdev));
+ netdev_err(dev, "unable to enable device\n");
goto error_out_dev;
}
err = pci_set_mwi(pdev);
if(err < 0) {
- pr_err("%s: unable to set MWI\n", pci_name(pdev));
+ netdev_err(dev, "unable to set MWI\n");
goto error_out_disable;
}
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if(err < 0) {
- pr_err("%s: No usable DMA configuration\n",
- pci_name(pdev));
+ netdev_err(dev, "No usable DMA configuration\n");
goto error_out_mwi;
}
/* sanity checks on IO and MMIO BARs
*/
if(!(pci_resource_flags(pdev, 0) & IORESOURCE_IO)) {
- pr_err("%s: region #1 not a PCI IO resource, aborting\n",
- pci_name(pdev));
+ netdev_err(dev, "region #1 not a PCI IO resource, aborting\n");
err = -ENODEV;
goto error_out_mwi;
}
if(pci_resource_len(pdev, 0) < 128) {
- pr_err("%s: Invalid PCI IO region size, aborting\n",
- pci_name(pdev));
+ netdev_err(dev, "Invalid PCI IO region size, aborting\n");
err = -ENODEV;
goto error_out_mwi;
}
if(!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
- pr_err("%s: region #1 not a PCI MMIO resource, aborting\n",
- pci_name(pdev));
+ netdev_err(dev, "region #1 not a PCI MMIO resource, aborting\n");
err = -ENODEV;
goto error_out_mwi;
}
if(pci_resource_len(pdev, 1) < 128) {
- pr_err("%s: Invalid PCI MMIO region size, aborting\n",
- pci_name(pdev));
+ netdev_err(dev, "Invalid PCI MMIO region size, aborting\n");
err = -ENODEV;
goto error_out_mwi;
}
err = pci_request_regions(pdev, "typhoon");
if(err < 0) {
- pr_err("%s: could not request regions\n",
- pci_name(pdev));
+ netdev_err(dev, "could not request regions\n");
goto error_out_mwi;
}
@@ -2444,8 +2434,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
ioaddr = pci_iomap(pdev, use_mmio, 128);
if (!ioaddr) {
- pr_err("%s: cannot remap registers, aborting\n",
- pci_name(pdev));
+ netdev_err(dev, "cannot remap registers, aborting\n");
err = -EIO;
goto error_out_regions;
}
@@ -2455,8 +2444,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
shared = pci_alloc_consistent(pdev, sizeof(struct typhoon_shared),
&shared_dma);
if(!shared) {
- pr_err("%s: could not allocate DMA memory\n",
- pci_name(pdev));
+ netdev_err(dev, "could not allocate DMA memory\n");
err = -ENOMEM;
goto error_out_remap;
}
@@ -2479,7 +2467,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
* 5) Put the card to sleep.
*/
if (typhoon_reset(ioaddr, WaitSleep) < 0) {
- pr_err("%s: could not reset 3XP\n", pci_name(pdev));
+ netdev_err(dev, "could not reset 3XP\n");
err = -EIO;
goto error_out_dma;
}
@@ -2491,12 +2479,6 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_master(pdev);
pci_save_state(pdev);
- /* dev->name is not valid until we register, but we need to
- * use some common routines to initialize the card. So that those
- * routines print the right name, we keep our oun pointer to the name
- */
- tp->name = pci_name(pdev);
-
typhoon_init_interface(tp);
typhoon_init_rings(tp);
@@ -2570,9 +2552,6 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if(register_netdev(dev) < 0)
goto error_out_reset;
- /* fixup our local name */
- tp->name = dev->name;
-
pci_set_drvdata(pdev, dev);
netdev_info(dev, "%s at %s 0x%llx, %pM\n",
^ permalink raw reply related
* Re: [PATCH] IPv6: convert mc_lock to spinlock
From: David Miller @ 2010-02-18 2:49 UTC (permalink / raw)
To: shemminger; +Cc: yoshfuji, netdev
In-Reply-To: <20100217182859.3a4f30de@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 17 Feb 2010 18:28:59 -0800
> Only used for writing, so convert to spinlock
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
That's an overwhelmingly clear cut case for me.
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH] drivers/net/tehuti.c: Reapply use DEFINE_PCI_DEVICE_TABLE()
From: David Miller @ 2010-02-18 2:48 UTC (permalink / raw)
To: joe; +Cc: adobriyan, netdev
In-Reply-To: <63f0493c99e6bc106b8e61f9a7471f3bb0edf7d5.1266458260.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Wed, 17 Feb 2010 18:08:55 -0800
> Commit 865a21a5e3d1b384c559a44c898fcad93e187b82 overwrote
> commit a3aa18842a5303fc28fcc4d57dbd16618bd830a0
>
> Fix it.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Miller @ 2010-02-18 2:41 UTC (permalink / raw)
To: dave; +Cc: joe, netdev, linux-kernel
In-Reply-To: <1266460221.5719.60.camel@obelisk.thedillows.org>
From: David Dillow <dave@thedillows.org>
Date: Wed, 17 Feb 2010 21:30:21 -0500
> No, because the routines that use tp->name are called both before and
> after the netdev is registered. Prior to that time, it contains the PCI
> slot name -- "00:01.0" etc -- so that the user can determine which card
> is acting up. Once the card is registered, it has "ethX" to use a
> commonly expected name for the card.
In my opinion that's awful.
Pick one or the other format. For things that happen both
before and after netdev registry we really should provide
one style of device identification and those provided
by dev_*() are probably the best in these situations.
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Dillow @ 2010-02-18 2:30 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel, davem
In-Reply-To: <1266459504.8446.201.camel@Joe-Laptop.home>
On Wed, 2010-02-17 at 18:18 -0800, Joe Perches wrote:
> On Wed, 2010-02-17 at 20:59 -0500, David Dillow wrote:
> > On Wed, 2010-02-17 at 17:02 -0800, Joe Perches wrote:
> > > Use pr_<level>
> > > Use netdev_<level>
> >
> > The way the driver uses tp->name, most of the pr_<level> changes add an
> > extraneous "typhoon:" to the front of the messages, which is not
> > desirable. Your absolute change-over from PFX/ERR_PFX to pr_fmt()
> > KBUILD_MODNAME misses the distinction between the message where the
> > prefix is needed, and where it isn't.
>
> Doesn't that mean that "%s: ...", tp->name should be removed?
No, because the routines that use tp->name are called both before and
after the netdev is registered. Prior to that time, it contains the PCI
slot name -- "00:01.0" etc -- so that the user can determine which card
is acting up. Once the card is registered, it has "ethX" to use a
commonly expected name for the card.
> > The netdev_<level> changes are much more palatable to me than the
> > pr_<level> ones. I have no problem getting behind those.
> >
> > > Coalesce long formats
> >
> > I don't like these changes very much, either. I tend to work in 80 char
> > terminals, and the wrap of a few characters is usually annoying.
>
> Linus prefers formats not be split across multiple lines.
> http://lkml.org/lkml/2008/2/23/251
> I can change it back if you want, no matter to me.
I'd prefer it, but I don't think it is really worth the effort now.
> > These __func__ conversions need to go.
> >
> > > @@ -1901,16 +1898,16 @@ typhoon_sleep(struct typhoon *tp, pci_power_t state, __le16 events)
> > > xp_cmd.parm1 = events;
> > > err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
> > > if(err < 0) {
> > > - printk(KERN_ERR "%s: typhoon_sleep(): wake events cmd err %d\n",
> > > - tp->name, err);
> > > + pr_err("%s: %s(): wake events cmd err %d\n",
> > > + tp->name, __func__, err);
> > > return err;
> > > }
>
> why? It makes it harder to get the function name wrong if
> it's rewritten.
This driver is rarely touched, except for API changes and such cleanups
people like to make from time to time. It is unlikely to be renamed,
adds code, and looks ugly. It may make sense for other printks in
functions that are in flux, but not here.
> How about something like this (on top of previous)?
The version change is fine, but you shouldn't get rid of tp->name.
^ permalink raw reply
* [PATCH] IPv6: convert mc_lock to spinlock
From: Stephen Hemminger @ 2010-02-18 2:28 UTC (permalink / raw)
To: David Miller,
YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
Only used for writing, so convert to spinlock
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/net/if_inet6.h 2010-02-17 17:31:40.353868234 -0800
+++ b/include/net/if_inet6.h 2010-02-17 17:31:57.069744558 -0800
@@ -156,7 +156,7 @@ struct inet6_dev {
struct ifmcaddr6 *mc_list;
struct ifmcaddr6 *mc_tomb;
- rwlock_t mc_lock;
+ spinlock_t mc_lock;
unsigned char mc_qrv;
unsigned char mc_gq_running;
unsigned char mc_ifc_count;
--- a/net/ipv6/mcast.c 2010-02-17 17:32:25.486242516 -0800
+++ b/net/ipv6/mcast.c 2010-02-17 17:36:08.025743316 -0800
@@ -793,10 +793,10 @@ static void mld_add_delrec(struct inet6_
}
spin_unlock_bh(&im->mca_lock);
- write_lock_bh(&idev->mc_lock);
+ spin_lock_bh(&idev->mc_lock);
pmc->next = idev->mc_tomb;
idev->mc_tomb = pmc;
- write_unlock_bh(&idev->mc_lock);
+ spin_unlock_bh(&idev->mc_lock);
}
static void mld_del_delrec(struct inet6_dev *idev, struct in6_addr *pmca)
@@ -804,7 +804,7 @@ static void mld_del_delrec(struct inet6_
struct ifmcaddr6 *pmc, *pmc_prev;
struct ip6_sf_list *psf, *psf_next;
- write_lock_bh(&idev->mc_lock);
+ spin_lock_bh(&idev->mc_lock);
pmc_prev = NULL;
for (pmc=idev->mc_tomb; pmc; pmc=pmc->next) {
if (ipv6_addr_equal(&pmc->mca_addr, pmca))
@@ -817,7 +817,8 @@ static void mld_del_delrec(struct inet6_
else
idev->mc_tomb = pmc->next;
}
- write_unlock_bh(&idev->mc_lock);
+ spin_unlock_bh(&idev->mc_lock);
+
if (pmc) {
for (psf=pmc->mca_tomb; psf; psf=psf_next) {
psf_next = psf->sf_next;
@@ -832,10 +833,10 @@ static void mld_clear_delrec(struct inet
{
struct ifmcaddr6 *pmc, *nextpmc;
- write_lock_bh(&idev->mc_lock);
+ spin_lock_bh(&idev->mc_lock);
pmc = idev->mc_tomb;
idev->mc_tomb = NULL;
- write_unlock_bh(&idev->mc_lock);
+ spin_unlock_bh(&idev->mc_lock);
for (; pmc; pmc = nextpmc) {
nextpmc = pmc->next;
@@ -1696,7 +1697,7 @@ static void mld_send_cr(struct inet6_dev
int type, dtype;
read_lock_bh(&idev->lock);
- write_lock_bh(&idev->mc_lock);
+ spin_lock(&idev->mc_lock);
/* deleted MCA's */
pmc_prev = NULL;
@@ -1730,7 +1731,7 @@ static void mld_send_cr(struct inet6_dev
} else
pmc_prev = pmc;
}
- write_unlock_bh(&idev->mc_lock);
+ spin_unlock(&idev->mc_lock);
/* change recs */
for (pmc=idev->mc_list; pmc; pmc=pmc->next) {
@@ -2311,7 +2312,7 @@ void ipv6_mc_up(struct inet6_dev *idev)
void ipv6_mc_init_dev(struct inet6_dev *idev)
{
write_lock_bh(&idev->lock);
- rwlock_init(&idev->mc_lock);
+ spin_lock_init(&idev->mc_lock);
idev->mc_gq_running = 0;
setup_timer(&idev->mc_gq_timer, mld_gq_timer_expire,
(unsigned long)idev);
^ permalink raw reply
* Re: [PATCH net-next 00/15] drivers/net: Use (pr|netdev|netif)_<level> macros
From: Joe Perches @ 2010-02-18 2:20 UTC (permalink / raw)
To: David Miller
Cc: dave, netdev, zambrano, mchan, eilong, romieu, shemminger,
mcarlson, linux-kernel
In-Reply-To: <20100217.180608.245806237.davem@davemloft.net>
On Wed, 2010-02-17 at 18:06 -0800, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 17 Feb 2010 18:01:22 -0800 (PST)
> > From: David Dillow <dave@thedillows.org>
> > Date: Wed, 17 Feb 2010 21:00:47 -0500
> >> Have you pushed? I'd rather some of the typhoon ones not go in.
> > Why not?
> Please answer soon, I'm not going to wait around for you to "get
> around" to providing a reason for the typhoon changes to not go in.
Dave Dillow did give reasons for his dislike.
Perhaps passing in transit?
http://lkml.org/lkml/2010/2/17/458
^ permalink raw reply
* Re: [PATCH net-next 00/15] drivers/net: Use (pr|netdev|netif)_<level> macros
From: David Dillow @ 2010-02-18 2:19 UTC (permalink / raw)
To: David Miller
Cc: joe, netdev, zambrano, mchan, eilong, romieu, shemminger,
mcarlson, linux-kernel
In-Reply-To: <20100217.180608.245806237.davem@davemloft.net>
On Wed, 2010-02-17 at 18:06 -0800, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> > From: David Dillow <dave@thedillows.org>
> >> Have you pushed? I'd rather some of the typhoon ones not go in.
> >
> > Why not?
>
> Please answer soon, I'm not going to wait around for you to "get
> around" to providing a reason for the typhoon changes to not go in.
I answered before I asked the question about your push, but it didn't go
to you, only Joe, netdev, and LKML. I mentioned this privately, but
perhaps our messages crossed in flight?
I understand your need to get this settled quickly, and I'll respond as
fast as I can, but someone has to put the kids to bed here on the east
coast. ;)
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: Joe Perches @ 2010-02-18 2:18 UTC (permalink / raw)
To: David Dillow; +Cc: netdev, linux-kernel
In-Reply-To: <1266458370.5719.43.camel@obelisk.thedillows.org>
On Wed, 2010-02-17 at 20:59 -0500, David Dillow wrote:
> On Wed, 2010-02-17 at 17:02 -0800, Joe Perches wrote:
> > Use pr_<level>
> > Use netdev_<level>
>
> The way the driver uses tp->name, most of the pr_<level> changes add an
> extraneous "typhoon:" to the front of the messages, which is not
> desirable. Your absolute change-over from PFX/ERR_PFX to pr_fmt()
> KBUILD_MODNAME misses the distinction between the message where the
> prefix is needed, and where it isn't.
Doesn't that mean that "%s: ...", tp->name should be removed?
> The netdev_<level> changes are much more palatable to me than the
> pr_<level> ones. I have no problem getting behind those.
>
> > Coalesce long formats
>
> I don't like these changes very much, either. I tend to work in 80 char
> terminals, and the wrap of a few characters is usually annoying.
Linus prefers formats not be split across multiple lines.
http://lkml.org/lkml/2008/2/23/251
I can change it back if you want, no matter to me.
> I don't have very much to do on this driver these days, so I'll defer to
> others on this issue. However, if you're going to be reformatting
> things, please pull things up a line when you shorten things enough to
> fit.
I try do that when I see it.
I prefer to use arguments on a separate line when all arguments
don't fit on a single one.
> But not here -- perhaps an 80 char limit, I've not looked at the patched
> file:
>
> > @@ -1492,7 +1490,7 @@ typhoon_download_firmware(struct typhoon *tp)
> > if(typhoon_wait_interrupt(ioaddr) < 0 ||
> > ioread32(ioaddr + TYPHOON_REG_STATUS) !=
> > TYPHOON_STATUS_WAITING_FOR_SEGMENT) {
> > - printk(KERN_ERR "%s: segment ready timeout\n",
> > + pr_err("%s: segment ready timeout\n",
> > tp->name);
Doesn't fit tp->name on 80 cols
> These __func__ conversions need to go.
>
> > @@ -1901,16 +1898,16 @@ typhoon_sleep(struct typhoon *tp, pci_power_t state, __le16 events)
> > xp_cmd.parm1 = events;
> > err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
> > if(err < 0) {
> > - printk(KERN_ERR "%s: typhoon_sleep(): wake events cmd err %d\n",
> > - tp->name, err);
> > + pr_err("%s: %s(): wake events cmd err %d\n",
> > + tp->name, __func__, err);
> > return err;
> > }
why? It makes it harder to get the function name wrong if
it's rewritten.
> Pull up tp->name?
> > @@ -2089,11 +2085,11 @@ typhoon_stop_runtime(struct typhoon *tp, int wait_type)
> > typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
> >
> > if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_HALTED) < 0)
> > - printk(KERN_ERR "%s: timed out waiting for 3XP to halt\n",
> > + pr_err("%s: timed out waiting for 3XP to halt\n",
> > tp->name);
>
> Please don't change this printk(), or change the version string, as
> you'll have a redundant "typhoon:" in there now.
How about something like this (on top of previous)?
diff --git a/drivers/net/typhoon.c b/drivers/net/typhoon.c
index 843f986..6fa887a 100644
--- a/drivers/net/typhoon.c
+++ b/drivers/net/typhoon.c
@@ -136,7 +136,7 @@ static const int multicast_filter_limit = 32;
#include "typhoon.h"
static char version[] __devinitdata =
- "typhoon.c: version " DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
+ "version " DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
MODULE_AUTHOR("David Dillow <dave@thedillows.org>");
MODULE_VERSION(DRV_MODULE_VERSION);
@@ -534,8 +534,8 @@ typhoon_process_response(struct typhoon *tp, int resp_size,
} else if(resp->cmd == TYPHOON_CMD_HELLO_RESP) {
typhoon_hello(tp);
} else {
- pr_err("%s: dumping unexpected response 0x%04x:%d:0x%02x:0x%04x:%08x:%08x\n",
- tp->name, le16_to_cpu(resp->cmd),
+ pr_err("dumping unexpected response 0x%04x:%d:0x%02x:0x%04x:%08x:%08x\n",
+ le16_to_cpu(resp->cmd),
resp->numDesc, resp->flags,
le16_to_cpu(resp->parm1),
le32_to_cpu(resp->parm2),
@@ -605,8 +605,8 @@ typhoon_issue_command(struct typhoon *tp, int num_cmd, struct cmd_desc *cmd,
freeResp = typhoon_num_free_resp(tp);
if(freeCmd < num_cmd || freeResp < num_resp) {
- pr_err("%s: no descs for cmd, had (needed) %d (%d) cmd, %d (%d) resp\n",
- tp->name, freeCmd, num_cmd, freeResp, num_resp);
+ pr_err("no descs for cmd, had (needed) %d (%d) cmd, %d (%d) resp\n",
+ freeCmd, num_cmd, freeResp, num_resp);
err = -ENOMEM;
goto out;
}
@@ -731,7 +731,7 @@ typhoon_vlan_rx_register(struct net_device *dev, struct vlan_group *grp)
spin_unlock_bh(&tp->state_lock);
err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
if(err < 0)
- printk("%s: vlan offload error %d\n", tp->name, -err);
+ pr_err("vlan offload error %d\n", -err);
spin_lock_bh(&tp->state_lock);
}
@@ -1364,8 +1364,7 @@ typhoon_request_firmware(struct typhoon *tp)
err = request_firmware(&typhoon_fw, FIRMWARE_NAME, &tp->pdev->dev);
if (err) {
- pr_err("%s: Failed to load firmware \"%s\"\n",
- tp->name, FIRMWARE_NAME);
+ pr_err("Failed to load firmware \"%s\"\n", FIRMWARE_NAME);
return err;
}
@@ -1400,7 +1399,7 @@ typhoon_request_firmware(struct typhoon *tp)
return 0;
invalid_fw:
- pr_err("%s: Invalid firmware image\n", tp->name);
+ pr_err("Invalid firmware image\n");
release_firmware(typhoon_fw);
typhoon_fw = NULL;
return -EINVAL;
@@ -1437,7 +1436,7 @@ typhoon_download_firmware(struct typhoon *tp)
err = -ENOMEM;
dpage = pci_alloc_consistent(pdev, PAGE_SIZE, &dpage_dma);
if(!dpage) {
- pr_err("%s: no DMA mem for firmware\n", tp->name);
+ pr_err("no DMA mem for firmware\n");
goto err_out;
}
@@ -1450,7 +1449,7 @@ typhoon_download_firmware(struct typhoon *tp)
err = -ETIMEDOUT;
if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_WAITING_FOR_HOST) < 0) {
- pr_err("%s: card ready timeout\n", tp->name);
+ pr_err("card ready timeout\n");
goto err_out_irq;
}
@@ -1490,8 +1489,7 @@ typhoon_download_firmware(struct typhoon *tp)
if(typhoon_wait_interrupt(ioaddr) < 0 ||
ioread32(ioaddr + TYPHOON_REG_STATUS) !=
TYPHOON_STATUS_WAITING_FOR_SEGMENT) {
- pr_err("%s: segment ready timeout\n",
- tp->name);
+ pr_err("segment ready timeout\n");
goto err_out_irq;
}
@@ -1524,15 +1522,15 @@ typhoon_download_firmware(struct typhoon *tp)
if(typhoon_wait_interrupt(ioaddr) < 0 ||
ioread32(ioaddr + TYPHOON_REG_STATUS) !=
TYPHOON_STATUS_WAITING_FOR_SEGMENT) {
- pr_err("%s: final segment ready timeout\n", tp->name);
+ pr_err("final segment ready timeout\n");
goto err_out_irq;
}
iowrite32(TYPHOON_BOOTCMD_DNLD_COMPLETE, ioaddr + TYPHOON_REG_COMMAND);
if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_WAITING_FOR_BOOT) < 0) {
- pr_err("%s: boot ready timeout, status 0x%0x\n",
- tp->name, ioread32(ioaddr + TYPHOON_REG_STATUS));
+ pr_err("boot ready timeout, status 0x%0x\n",
+ ioread32(ioaddr + TYPHOON_REG_STATUS));
goto err_out_irq;
}
@@ -1554,7 +1552,7 @@ typhoon_boot_3XP(struct typhoon *tp, u32 initial_status)
void __iomem *ioaddr = tp->ioaddr;
if(typhoon_wait_status(ioaddr, initial_status) < 0) {
- pr_err("%s: boot ready timeout\n", tp->name);
+ pr_err("boot ready timeout\n");
goto out_timeout;
}
@@ -1565,8 +1563,8 @@ typhoon_boot_3XP(struct typhoon *tp, u32 initial_status)
ioaddr + TYPHOON_REG_COMMAND);
if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_RUNNING) < 0) {
- pr_err("%s: boot finish timeout (status 0x%x)\n",
- tp->name, ioread32(ioaddr + TYPHOON_REG_STATUS));
+ pr_err("boot finish timeout (status 0x%x)\n",
+ ioread32(ioaddr + TYPHOON_REG_STATUS));
goto out_timeout;
}
@@ -1898,16 +1896,16 @@ typhoon_sleep(struct typhoon *tp, pci_power_t state, __le16 events)
xp_cmd.parm1 = events;
err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
if(err < 0) {
- pr_err("%s: %s(): wake events cmd err %d\n",
- tp->name, __func__, err);
+ pr_err("%s(): wake events cmd err %d\n",
+ __func__, err);
return err;
}
INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_GOTO_SLEEP);
err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
if(err < 0) {
- pr_err("%s: %s(): sleep cmd err %d\n",
- tp->name, __func__, err);
+ pr_err("%s(): sleep cmd err %d\n",
+ __func__, err);
return err;
}
@@ -1958,12 +1956,12 @@ typhoon_start_runtime(struct typhoon *tp)
err = typhoon_download_firmware(tp);
if(err < 0) {
- printk("%s: cannot load runtime on 3XP\n", tp->name);
+ pr_err("cannot load runtime on 3XP\n");
goto error_out;
}
if(typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_BOOT) < 0) {
- printk("%s: cannot boot 3XP\n", tp->name);
+ pr_err("cannot boot 3XP\n");
err = -EIO;
goto error_out;
}
@@ -2067,8 +2065,7 @@ typhoon_stop_runtime(struct typhoon *tp, int wait_type)
}
if(i == TYPHOON_WAIT_TIMEOUT)
- pr_err("%s: halt timed out waiting for Tx to complete\n",
- tp->name);
+ pr_err("halt timed out waiting for Tx to complete\n");
INIT_COMMAND_NO_RESPONSE(&xp_cmd, TYPHOON_CMD_TX_DISABLE);
typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
@@ -2085,11 +2082,10 @@ typhoon_stop_runtime(struct typhoon *tp, int wait_type)
typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_HALTED) < 0)
- pr_err("%s: timed out waiting for 3XP to halt\n",
- tp->name);
+ pr_err("timed out waiting for 3XP to halt\n");
if(typhoon_reset(ioaddr, wait_type) < 0) {
- pr_err("%s: unable to reset 3XP\n", tp->name);
+ pr_err("unable to reset 3XP\n");
return -ETIMEDOUT;
}
@@ -2376,8 +2372,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev = alloc_etherdev(sizeof(*tp));
if(dev == NULL) {
- pr_err("%s: unable to alloc new net device\n",
- pci_name(pdev));
+ pr_err("%s: unable to alloc new net device\n", pci_name(pdev));
err = -ENOMEM;
goto error_out;
}
@@ -2385,8 +2380,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
err = pci_enable_device(pdev);
if(err < 0) {
- pr_err("%s: unable to enable device\n",
- pci_name(pdev));
+ pr_err("%s: unable to enable device\n", pci_name(pdev));
goto error_out_dev;
}
@@ -2398,8 +2392,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if(err < 0) {
- pr_err("%s: No usable DMA configuration\n",
- pci_name(pdev));
+ pr_err("%s: No usable DMA configuration\n", pci_name(pdev));
goto error_out_mwi;
}
@@ -2432,8 +2425,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
err = pci_request_regions(pdev, "typhoon");
if(err < 0) {
- pr_err("%s: could not request regions\n",
- pci_name(pdev));
+ pr_err("%s: could not request regions\n", pci_name(pdev));
goto error_out_mwi;
}
@@ -2455,8 +2447,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
shared = pci_alloc_consistent(pdev, sizeof(struct typhoon_shared),
&shared_dma);
if(!shared) {
- pr_err("%s: could not allocate DMA memory\n",
- pci_name(pdev));
+ pr_err("%s: could not allocate DMA memory\n", pci_name(pdev));
err = -ENOMEM;
goto error_out_remap;
}
@@ -2493,7 +2484,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
/* dev->name is not valid until we register, but we need to
* use some common routines to initialize the card. So that those
- * routines print the right name, we keep our oun pointer to the name
+ * routines print the right name, we keep our own pointer to the name
*/
tp->name = pci_name(pdev);
@@ -2501,16 +2492,14 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
typhoon_init_rings(tp);
if(typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST) < 0) {
- pr_err("%s: cannot boot 3XP sleep image\n",
- pci_name(pdev));
+ pr_err("%s: cannot boot 3XP sleep image\n", pci_name(pdev));
err = -EIO;
goto error_out_reset;
}
INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_MAC_ADDRESS);
if(typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp) < 0) {
- pr_err("%s: cannot read MAC address\n",
- pci_name(pdev));
+ pr_err("%s: cannot read MAC address\n", pci_name(pdev));
err = -EIO;
goto error_out_reset;
}
@@ -2530,7 +2519,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_VERSIONS);
if(typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp) < 0) {
pr_err("%s: Could not get Sleep Image version\n",
- pci_name(pdev));
+ pci_name(pdev));
goto error_out_reset;
}
@@ -2547,8 +2536,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->capabilities |= TYPHOON_WAKEUP_NEEDS_RESET;
if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) {
- pr_err("%s: cannot put adapter to sleep\n",
- pci_name(pdev));
+ pr_err("%s: cannot put adapter to sleep\n", pci_name(pdev));
err = -EIO;
goto error_out_reset;
}
^ permalink raw reply related
* linux-next: manual merge of the net tree with the kvm tree
From: Stephen Rothwell @ 2010-02-18 2:15 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Jan Kiszka, Avi Kivity
Hi all,
Today's linux-next merge of the net tree got a conflict in
Documentation/feature-removal-schedule.txt between commit
f5c9db332c54af513e5bee5cd84f5aadb8d21f55 ("KVM: Plan obsolescence of
kernel allocated slots, paravirt mmu") from the kvm tree and commit
79e95f4717767e9ddc4dbec5d778f0c9970eed34 ("CAPI: Schedule capifs for
removal") from the net tree.
Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc Documentation/feature-removal-schedule.txt
index 47a6554,721a2aa..0000000
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@@ -545,30 -524,10 +524,40 @@@ Who: Hans de Goede <hdegoede@redhat.com
----------------------------
+What: KVM memory aliases support
+When: July 2010
+Why: Memory aliasing support is used for speeding up guest vga access
+ through the vga windows.
+
+ Modern userspace no longer uses this feature, so it's just bitrotted
+ code and can be removed with no impact.
+Who: Avi Kivity <avi@redhat.com>
+
+----------------------------
+
+What: KVM kernel-allocated memory slots
+When: July 2010
+Why: Since 2.6.25, kvm supports user-allocated memory slots, which are
+ much more flexible than kernel-allocated slots. All current userspace
+ supports the newer interface and this code can be removed with no
+ impact.
+Who: Avi Kivity <avi@redhat.com>
+
+----------------------------
+
+What: KVM paravirt mmu host support
+When: January 2011
+Why: The paravirt mmu host support is slower than non-paravirt mmu, both
+ on newer and older hardware. It is already not exposed to the guest,
+ and kept only for live migration purposes.
+Who: Avi Kivity <avi@redhat.com>
++
++----------------------------
++
+ What: capifs
+ When: February 2011
+ Files: drivers/isdn/capi/capifs.*
+ Why: udev fully replaces this special file system that only contains CAPI
+ NCCI TTY device nodes. User space (pppdcapiplugin) works without
+ noticing the difference.
+ Who: Jan Kiszka <jan.kiszka@web.de>
^ permalink raw reply
* [PATCH] drivers/net/tehuti.c: Reapply use DEFINE_PCI_DEVICE_TABLE()
From: Joe Perches @ 2010-02-18 2:08 UTC (permalink / raw)
To: David Miller; +Cc: Alexey Dobriyan, netdev
Commit 865a21a5e3d1b384c559a44c898fcad93e187b82 overwrote
commit a3aa18842a5303fc28fcc4d57dbd16618bd830a0
Fix it.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/tehuti.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tehuti.c b/drivers/net/tehuti.c
index b295b92..2517cc0 100644
--- a/drivers/net/tehuti.c
+++ b/drivers/net/tehuti.c
@@ -66,7 +66,7 @@
#include "tehuti.h"
-static struct pci_device_id __devinitdata bdx_pci_tbl[] = {
+static DEFINE_PCI_DEVICE_TABLE(bdx_pci_tbl) = {
{0x1FC9, 0x3009, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{0x1FC9, 0x3010, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{0x1FC9, 0x3014, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
--
1.7.0.14.g7e948
^ permalink raw reply related
* Re: [PATCH net-next 00/15] drivers/net: Use (pr|netdev|netif)_<level> macros
From: David Dillow @ 2010-02-18 2:00 UTC (permalink / raw)
To: David Miller
Cc: joe, netdev, zambrano, mchan, eilong, romieu, shemminger,
mcarlson, linux-kernel
In-Reply-To: <20100217.174615.133415843.davem@davemloft.net>
On Wed, 2010-02-17 at 17:46 -0800, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Wed, 17 Feb 2010 17:01:47 -0800
>
> > Use the newly added netdev_<level> and netif_<level> logging macros
> > in some of the drivers.
> >
> > Adds some message logging consistency.
> >
> > pci-skeleton had a checkpatch style cleaning as well.
>
> The sis190.c and tg3.c changes didn't apply due to other
> recent commits into the net-next-2.6 tree
>
> I applied all of the others.
Have you pushed? I'd rather some of the typhoon ones not go in.
^ permalink raw reply
* Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Dillow @ 2010-02-18 1:59 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel
In-Reply-To: <40a714d7757b0c24f3f0737f028d0242853f935b.1266454576.git.joe@perches.com>
On Wed, 2010-02-17 at 17:02 -0800, Joe Perches wrote:
> Use pr_<level>
> Use netdev_<level>
The way the driver uses tp->name, most of the pr_<level> changes add an
extraneous "typhoon:" to the front of the messages, which is not
desirable. Your absolute change-over from PFX/ERR_PFX to pr_fmt()
KBUILD_MODNAME misses the distinction between the message where the
prefix is needed, and where it isn't.
The netdev_<level> changes are much more palatable to me than the
pr_<level> ones. I have no problem getting behind those.
> Coalesce long formats
I don't like these changes very much, either. I tend to work in 80 char
terminals, and the wrap of a few characters is usually annoying. I can
use a wider term, sure, but then you obscure the hint about too-deep
nesting that the more narrow terminal gives you. Also, it leaves
droppings about on those rare occasions when the code is printed 2-up.
I don't have very much to do on this driver these days, so I'll defer to
others on this issue. However, if you're going to be reformatting
things, please pull things up a line when you shorten things enough to
fit. You did it here:
> @@ -606,9 +605,8 @@ typhoon_issue_command(struct typhoon *tp, int num_cmd, struct cmd_desc *cmd,
> freeResp = typhoon_num_free_resp(tp);
>
> if(freeCmd < num_cmd || freeResp < num_resp) {
> - printk("%s: no descs for cmd, had (needed) %d (%d) cmd, "
> - "%d (%d) resp\n", tp->name, freeCmd, num_cmd,
> - freeResp, num_resp);
> + pr_err("%s: no descs for cmd, had (needed) %d (%d) cmd, %d (%d) resp\n",
> + tp->name, freeCmd, num_cmd, freeResp, num_resp);
> err = -ENOMEM;
> goto out;
> }
But not here -- perhaps an 80 char limit, I've not looked at the patched
file:
> @@ -1492,7 +1490,7 @@ typhoon_download_firmware(struct typhoon *tp)
> if(typhoon_wait_interrupt(ioaddr) < 0 ||
> ioread32(ioaddr + TYPHOON_REG_STATUS) !=
> TYPHOON_STATUS_WAITING_FOR_SEGMENT) {
> - printk(KERN_ERR "%s: segment ready timeout\n",
> + pr_err("%s: segment ready timeout\n",
> tp->name);
> goto err_out_irq;
> }
These __func__ conversions need to go.
> @@ -1901,16 +1898,16 @@ typhoon_sleep(struct typhoon *tp, pci_power_t state, __le16 events)
> xp_cmd.parm1 = events;
> err = typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
> if(err < 0) {
> - printk(KERN_ERR "%s: typhoon_sleep(): wake events cmd err %d\n",
> - tp->name, err);
> + pr_err("%s: %s(): wake events cmd err %d\n",
> + tp->name, __func__, err);
> return err;
> }
Pull up tp->name?
> @@ -2089,11 +2085,11 @@ typhoon_stop_runtime(struct typhoon *tp, int wait_type)
> typhoon_issue_command(tp, 1, &xp_cmd, 0, NULL);
>
> if(typhoon_wait_status(ioaddr, TYPHOON_STATUS_HALTED) < 0)
> - printk(KERN_ERR "%s: timed out waiting for 3XP to halt\n",
> + pr_err("%s: timed out waiting for 3XP to halt\n",
> tp->name);
Please don't change this printk(), or change the version string, as
you'll have a redundant "typhoon:" in there now.
> @@ -2384,11 +2372,11 @@ typhoon_init_one(struct pci_dev *pdev, const > struct pci_device_id *ent
> int err = 0;
>
> if(!did_version++)
>- printk(KERN_INFO "%s", version);
>+ pr_info("%s", version);
Pull up pci_name()? Or does that overflow 80 chars?
> @@ -2384,11 +2372,11 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> dev = alloc_etherdev(sizeof(*tp));
> if(dev == NULL) {
> - printk(ERR_PFX "%s: unable to alloc new net device\n",
> + pr_err("%s: unable to alloc new net device\n",
> pci_name(pdev));
> err = -ENOMEM;
> goto error_out;
> @@ -2397,20 +2385,20 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> err = pci_enable_device(pdev);
> if(err < 0) {
> - printk(ERR_PFX "%s: unable to enable device\n",
> + pr_err("%s: unable to enable device\n",
> pci_name(pdev));
> goto error_out_dev;
> }
>
> err = pci_set_mwi(pdev);
> if(err < 0) {
> - printk(ERR_PFX "%s: unable to set MWI\n", pci_name(pdev));
> + pr_err("%s: unable to set MWI\n", pci_name(pdev));
> goto error_out_disable;
> }
>
> err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
> if(err < 0) {
> - printk(ERR_PFX "%s: No usable DMA configuration\n",
> + pr_err("%s: No usable DMA configuration\n",
> pci_name(pdev));
> goto error_out_mwi;
> }
> @@ -2523,7 +2509,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_MAC_ADDRESS);
> if(typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp) < 0) {
> - printk(ERR_PFX "%s: cannot read MAC address\n",
> + pr_err("%s: cannot read MAC address\n",
> pci_name(pdev));
> err = -EIO;
> goto error_out_reset;
> @@ -2561,7 +2547,7 @@ typhoon_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> tp->capabilities |= TYPHOON_WAKEUP_NEEDS_RESET;
>
> if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) {
> - printk(ERR_PFX "%s: cannot put adapter to sleep\n",
> + pr_err("%s: cannot put adapter to sleep\n",
> pci_name(pdev));
> err = -EIO;
> goto error_out_reset;
^ permalink raw reply
* Re: [PATCH net-next 00/15] drivers/net: Use (pr|netdev|netif)_<level> macros
From: David Miller @ 2010-02-18 2:06 UTC (permalink / raw)
To: dave
Cc: joe, netdev, zambrano, mchan, eilong, romieu, shemminger,
mcarlson, linux-kernel
In-Reply-To: <20100217.180122.195704088.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 17 Feb 2010 18:01:22 -0800 (PST)
> From: David Dillow <dave@thedillows.org>
> Date: Wed, 17 Feb 2010 21:00:47 -0500
>
>> Have you pushed? I'd rather some of the typhoon ones not go in.
>
> Why not?
Please answer soon, I'm not going to wait around for you to "get
around" to providing a reason for the typhoon changes to not go in.
I want to push this our so Joe can continue his work.
And if the reason is "this makes some pending patches I have not apply
any more", that's not a valid reason.
^ permalink raw reply
* Re: [PATCH net-next 00/15] drivers/net: Use (pr|netdev|netif)_<level> macros
From: David Miller @ 2010-02-18 2:01 UTC (permalink / raw)
To: dave
Cc: joe, netdev, zambrano, mchan, eilong, romieu, shemminger,
mcarlson, linux-kernel
In-Reply-To: <1266458447.5719.44.camel@obelisk.thedillows.org>
From: David Dillow <dave@thedillows.org>
Date: Wed, 17 Feb 2010 21:00:47 -0500
> On Wed, 2010-02-17 at 17:46 -0800, David Miller wrote:
>> From: Joe Perches <joe@perches.com>
>> Date: Wed, 17 Feb 2010 17:01:47 -0800
>>
>> > Use the newly added netdev_<level> and netif_<level> logging macros
>> > in some of the drivers.
>> >
>> > Adds some message logging consistency.
>> >
>> > pci-skeleton had a checkpatch style cleaning as well.
>>
>> The sis190.c and tg3.c changes didn't apply due to other
>> recent commits into the net-next-2.6 tree
>>
>> I applied all of the others.
>
> Have you pushed? I'd rather some of the typhoon ones not go in.
Why not?
^ 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