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 {
next prev parent 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®