mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: John Rose <johnrose@austin.ibm.com>
Cc: Rusty Russell <rusty@au1.ibm.com>,
	linux-kernel@vger.kernel.org, gregkh@us.ibm.com,
	Mike Wortman <wortman@us.ibm.com>
Subject: Re: [PATCH] PPC64 PCI Hotplug Driver for RPA
Date: Mon, 16 Feb 2004 18:35:14 +0000	[thread overview]
Message-ID: <20040216183514.A19426@infradead.org> (raw)
In-Reply-To: <1076955716.10484.21.camel@verve.austin.ibm.com>; from johnrose@austin.ibm.com on Mon, Feb 16, 2004 at 12:21:56PM -0600

On Mon, Feb 16, 2004 at 12:21:56PM -0600, John Rose wrote:
> +#if !defined(CONFIG_HOTPLUG_PCI_MODULE)
> +	#define MY_NAME "rpaphp"
> +#else
> +	#define MY_NAME THIS_MODULE->name
> +#endif

Umm, what's this?  Checking CONFIG_FOO_MODULE is basically always wrong
and especially in this case.  Just use "rpaphp" always.

> +static int num_slots = 0;

No need to initialized variables to 0

> +static int enable_slot		(struct hotplug_slot *slot);
> +static int disable_slot		(struct hotplug_slot *slot);
> +static int set_attention_status (struct hotplug_slot *slot, u8 value);
> +static int get_power_status	(struct hotplug_slot *slot, u8 *value);
> +static int get_attention_status	(struct hotplug_slot *slot, u8 *value);
> +static int get_adapter_status	(struct hotplug_slot *slot, u8 *value);
> +static int get_max_bus_speed	(struct hotplug_slot *hotplug_slot, enum pci_bus_speed *value);
> +static int get_cur_bus_speed	(struct hotplug_slot *hotplug_slot, enum pci_bus_speed *value);

The larger whitespace before the opening brace aren't exatly linux
codingstyle..

> +static struct pci_dev *rpaphp_find_bridge_pdev(struct slot *slot)
> +{
> +	struct pci_dev		*retval_dev = NULL;
> +
> +	retval_dev = rpaphp_find_pci_dev(slot->dn);
> +
> +	return retval_dev;
> +}

This is horribly verbose.  Why not simply

static struct pci_dev *rpaphp_find_bridge_pdev(struct slot *slot)
{
	return rpaphp_find_pci_dev(slot->dn);
}

dito for rpaphp_find_adapter_pdev

In fact this is only used once so the wrapper looks rather useless.

> +/* Inline functions to check the sanity of a pointer that is passed to us */
> +static inline int slot_paranoia_check(struct slot *slot, const char *function)
> +{
> +	if (!slot) {
> +		dbg("%s - slot == NULL\n", function);
> +		return -1;
> +	}
> +
> +	if (!slot->hotplug_slot) {
> +		dbg("%s - slot->hotplug_slot == NULL!\n", function);
> +		return -1;
> +	}
> +	return 0;
> +}
> +
> +static inline struct slot *get_slot(struct hotplug_slot *hotplug_slot, const char *function)
> +{
> +	struct slot *slot;
> +
> +	if (!hotplug_slot) {
> +		dbg("%s - hotplug_slot == NULL\n", function);
> +		return NULL;
> +	}

If you have a method that per specification doesn't get a NULL pointer adding
these kinds of checks is bad.  Getting a NULL pointer would be against the
codified guaranteeds and your system already is bad trouble - better panic
ASAP by dereferencing the NULL pointer than waiting longer and possibly
corrupting data.

> +static int init_slots (void)
> +{
> +	int 			retval = 0;
> +
> +	retval = rpaphp_add_slot(NULL);
> +
> +	return retval;
> +}

Same strange verbosity as above.

> +static int __init rpaphp_init(void)
> +{
> +	int retval = 0;
> +
> +	info(DRIVER_DESC " version: " DRIVER_VERSION "\n");
> +
> +	rpaphp_debug = debug;
> +
> +	/* read all the PRA info from the system */
> +	retval = init_rpa();
> +
> +	return retval;

Again..  Btw, why do you have rpaphp_debug and debug?  Just using one is
much less confusing.

> +static void __exit rpaphp_exit(void)
> +{
> +	cleanup_slots();
> +}

Why the wrapping?

> +	}
> +	else {

linux coding style says this is

	} else {


  reply	other threads:[~2004-02-16 18:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-11  1:08 johnrose
2004-02-15  8:58 ` Rusty Russell
2004-02-16 18:18   ` John Rose
2004-02-16 18:21   ` John Rose
2004-02-16 18:35     ` Christoph Hellwig [this message]
     [not found]       ` <4033B983.6060809@ltcfwd.linux.ibm.com>
2004-02-18 19:17         ` Greg KH
     [not found]           ` <4033CC29.3010508@ltcfwd.linux.ibm.com>
2004-02-18 20:57             ` Greg KH
2004-02-18 22:27         ` Rusty Russell
2004-02-11  1:12 johnrose
2004-02-18 20:57 ` Greg KH

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=20040216183514.A19426@infradead.org \
    --to=hch@infradead.org \
    --cc=gregkh@us.ibm.com \
    --cc=johnrose@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@au1.ibm.com \
    --cc=wortman@us.ibm.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

all inboxes | Powered by JetHome®