From: Peter Samuelson <peter@cadcamlab.org>
To: Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org
Subject: Re: i2c-amd766 driver for 2.5.50
Date: Sun, 1 Dec 2002 17:34:51 -0600 [thread overview]
Message-ID: <20021201233451.GB4182@cadcamlab.org> (raw)
Cosmetic stuff..
> --- clean.2.5/drivers/i2c/busses/Makefile 2002-12-01 16:56:56.000000000 +0100
> +++ linux-sensors/drivers/i2c/busses/Makefile 2002-12-01 17:57:14.000000000 +0100
> @@ -0,0 +1,10 @@
> +#
> +# Makefile for the kernel hardware sensors bus drivers.
> +#
> +
> +MOD_LIST_NAME := SENSORS_BUS_MODULES
> +
> +obj-$(CONFIG_I2C_MAINBOARD) += i2c-mainboard.o
> +obj-$(CONFIG_I2C_AMD756) += i2c-amd756.o
> +
> +include $(TOPDIR)/Rules.make
MOD_LIST_NAME was deprecated in 2.3. 'include Rules.make' was
deprecated in 2.5. Also appears in drivers/i2c/chips/Makefile.
> +#ifndef PCI_DEVICE_ID_AMD_756
> +#define PCI_DEVICE_ID_AMD_756 0x740B
> +#endif
> +#ifndef PCI_DEVICE_ID_AMD_766
> +#define PCI_DEVICE_ID_AMD_766 0x7413
> +#endif
> +#ifndef PCI_DEVICE_ID_NVIDIA_NFORCE_SMBUS
> +#define PCI_DEVICE_ID_NVIDIA_NFORCE_SMBUS 0x01B4
> +#endif
These are all in pci_ids.h already, under other names. If these names
are better, they should replace the others.
> +struct sd {
> + const unsigned short vendor;
> + const unsigned short device;
> + const unsigned short function;
> + const char* name;
> + int amdsetup:1;
> +};
> +
> +static struct sd supported[] = {
> + {PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_756, 3, "AMD756", 1},
> + {PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_766, 3, "AMD766", 1},
> + {PCI_VENDOR_ID_AMD, 0x7443, 3, "AMD768", 1},
> + {PCI_VENDOR_ID_NVIDIA, 0x01B4, 1, "nVidia nForce", 0},
> + {0, 0, 0}
> +};
You should also have a struct pci_device_id[] here, so you can have a
MODULE_DEVICE_TABLE().
> +/* OK, this is not exactly good programming practice, usually. But it is
> + very code-efficient in this case. */
> +
> + ERROR4:
> + i2c_detach_client(new_client);
No need to apologise for goto error unwinding - it's all over the kernel.
> +void adm1021_dec_use(struct i2c_client *client)
> +{
> +#ifdef MODULE
> + MOD_DEC_USE_COUNT;
> +#endif
> +}
No need for #ifdef. Also found in lm75_inc_use() and elsewhere.
> +void adm1021_update_client(struct i2c_client *client)
> +{
> + struct adm1021_data *data = client->data;
> +
> + down(&data->update_lock);
> +
> + if ((jiffies - data->last_updated > HZ + HZ / 2) ||
> + (jiffies < data->last_updated) || !data->valid) {
if (time_after(jiffies, data->last_updated + HZ+HZ/2) || !data->valid) {
It *appears* the (jiffies < data->last_updated) test is unnecessary.
> +EXPORT_NO_SYMBOLS;
Deprecated (from lm75.c).
General comment: what's up with /proc/sys/dev/ versus /proc/driver/
versus sysfs? Do we really need all three?
Peter
next reply other threads:[~2002-12-01 23:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-01 23:34 Peter Samuelson [this message]
2002-12-02 0:55 ` Pavel Machek
2002-12-02 1:56 ` Peter Samuelson
-- strict thread matches above, loose matches on Subject: below --
2002-12-01 17:36 Pavel Machek
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=20021201233451.GB4182@cadcamlab.org \
--to=peter@cadcamlab.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/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®