netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Dawe <rich@phekda.gotadsl.co.uk>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: netdev@oss.sgi.com, jgarzik@pobox.com
Subject: Re: [PATCH]: r8169: Message level support
Date: Sun, 27 Feb 2005 22:43:01 +0000	[thread overview]
Message-ID: <42224CF5.5090601@phekda.gotadsl.co.uk> (raw)
In-Reply-To: <20050226203518.GA14688@electric-eye.fr.zoreil.com>

Hello.

Thanks for reviewing the patch, Francois and Jeff. I'll send an updated 
version sometime in the next week.

Francois Romieu wrote:
> Jeff, can you send a ack/nack if you disagree with the remarks below ?
> 
> Richard Dawe <rich@phekda.gotadsl.co.uk> :
> [...]
> 
>>There seems to be a mixture of drivers using a bitfield and a level. 
>>Which is the currently preferred mechanism?
> 
> 
> They do not offer exactly the same range. I prefer to keep both as the
> module option is not that expensive.

OK.

[snip]
> 1 - I am not fond of shouting macro. Everything starts turnings caps.
>     Any reason to not use "dprintk" ?

(dprintk vs. DPRINTK)

I prefer macros to be uppercase, to make it obvious that they're macros. 
  But this isn't a strong preference.

I'll make it lowercase.

> 2 - Imho the driver should not poke its nose into the guts of netif_msg_xxx().
>     It defeats its whole purpose. Any objection to not use it explicitely ?

No objection at all.

In my first patch I did exactly that. But then I used the e100 driver as 
a model, which sticks its nose into the guts.

I'll use the netif_msg_xxx() macros.

> 3 - If PFX is included, we'll have a mix of printk and dprintk. My personal
>     taste would be to not include it in the definition of the macro.

I'll go with Jeff here, which is that "PFX should only be used in probe 
paths".

[snip]
> It's up to you but I'd rather see:
> #define RTL8169_DEF_MSG_ENABLE \
> 	(NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK)

I'll use that.

> [...]
> @@ -433,10 +443,10 @@ static void rtl8169_hw_start(struct net_
>  static int rtl8169_close(struct net_device *dev);
>  static void rtl8169_set_rx_mode(struct net_device *dev);
>  static void rtl8169_tx_timeout(struct net_device *dev);
> -static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev);
> +static struct net_device_stats *rtl8169_get_stats(struct net_device *dev);
>  static int rtl8169_rx_interrupt(struct net_device *, struct rtl8169_private *,
>  				void __iomem *);
> -static int rtl8169_change_mtu(struct net_device *netdev, int new_mtu);
> +static int rtl8169_change_mtu(struct net_device *dev, int new_mtu);
>  static void rtl8169_down(struct net_device *dev);
>  
>  #ifdef CONFIG_R8169_NAPI
> 
> Separate patch please.

OK, will do.

[snip]
> -static void rtl8169_link_option(int idx, u8 *autoneg, u16 *speed, u8 *duplex)
> +static void rtl8169_link_option(struct net_device *dev, int idx, u8 *autoneg, u16 *speed, u8 *duplex)
>  {
> +	struct rtl8169_private *tp = netdev_priv(dev);
>  	struct {
>  		u16 speed;
>  		u8 duplex;
> 
> Why not give a struct rtl8169_private * as argument to this function ?

Er, no idea why I didn't. I'll do that. ;)

> [...]
> 
>>@@ -871,6 +881,18 @@ static void rtl8169_get_regs(struct net_
>>         spin_unlock_irqrestore(&tp->lock, flags);
>> }
>> 
>>+static u32 r8169_get_msglevel(struct net_device *dev)
>>+{
>>+	struct rtl8169_private *tp = netdev_priv(dev);
>>+	return tp->msg_enable;
>>+}
> 
> 
> 
> Variable declaration and code are always separated by an empty
> line in the current driver. Please keep it this way.

Will do.

>> 
>> 	for (p = mac_print; p->msg; p++) {
>> 		if (tp->mac_version == p->version) {
>>-			dprintk("mac_version == %s (%04d)\n", p->msg,
>>-				  p->version);
>>+			if (netif_msg_hw(tp))
>>+				printk(KERN_DEBUG
>>+				       "mac_version == %s (%04d)\n",
> 
> 
> No need to add a line: you are allowed to use the whole 80 cols range.

I think I did that for consistency with another printk that was split 
across lines.

I'll fix the case above as you'd like.

[snip]
>>@@ -1169,7 +1200,8 @@ rtl8169_init_board(struct pci_dev *pdev,
>> 	/* dev zeroed in alloc_etherdev */
>> 	dev = alloc_etherdev(sizeof (*tp));
>> 	if (dev == NULL) {
>>-		printk(KERN_ERR PFX "unable to alloc new ethernet\n");
>>+		if (debug & NETIF_MSG_PROBE)
>>+			printk(KERN_ERR PFX "unable to alloc new ethernet\n");
>> 		goto err_out;
>> 	}
>> 
> 
> 
> Can you do something like:
> 
> struct {
> 	u32 msg_enable;
> } debug;
> 
> This way it will be possible to issue netif_msg_probe(&debug).

Yes, good idea!

>>@@ -1177,10 +1209,15 @@ rtl8169_init_board(struct pci_dev *pdev,
>> 	SET_NETDEV_DEV(dev, &pdev->dev);
>> 	tp = netdev_priv(dev);
>> 
>>+	tp->msg_enable = debug;
>>+
>> 	/* enable device (incl. PCI PM wakeup and hotplug setup) */
>> 	rc = pci_enable_device(pdev);
>> 	if (rc) {
>>-		printk(KERN_ERR PFX "%s: enable failure\n", pdev->slot_name);
>>+		if (netif_msg_probe(tp))
>>+			printk(KERN_ERR PFX
>>+			       "%s: enable failure\n",
>>+			       pdev->slot_name);
> 
> 
> Use dprintk ?

Original dprintk or the DPRINTK used in my patch? If you mean DPRINTK, 
then it wouldn't work, because DPRINTK includes dev->name. At this point 
in the code, dev->name is not defined.

Perhaps I could modifying DPRINTK (*) to use dev->name if defined, 
otherwise fall back on PFX.

(*) I'm not ignoring the future renaming of DPRINTK to dprintk. I'm just 
trying to avoid confusion when talking about this patch.

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ]

"You can't evaluate a man by logic alone."
   -- McCoy, "I, Mudd", Star Trek

  parent reply	other threads:[~2005-02-27 22:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-26 17:11 [PATCH]: r8169: Message level support Richard Dawe
2005-02-26 20:35 ` Francois Romieu
2005-02-26 21:20   ` Jeff Garzik
2005-02-27 22:43   ` Richard Dawe [this message]
2005-02-27 23:52     ` Francois Romieu
2005-02-28 17:27       ` [PATCH 1/2] r8169: Jumbo Frames mini-increase Jon Mason
2005-02-28 19:32         ` Francois Romieu
2005-02-28 19:41           ` Jon Mason
2005-02-28 20:19           ` Jeff Garzik
2005-02-28 20:56             ` Jon Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42224CF5.5090601@phekda.gotadsl.co.uk \
    --to=rich@phekda.gotadsl.co.uk \
    --cc=jgarzik@pobox.com \
    --cc=netdev@oss.sgi.com \
    --cc=romieu@fr.zoreil.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).