From: Greg KH <greg@kroah.com>
To: Wen Xiong <wendyx@us.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [ patch 4/7] drivers/serial/jsm: new serial device driver
Date: Fri, 4 Mar 2005 14:01:19 -0800 [thread overview]
Message-ID: <20050304220116.GA1201@kroah.com> (raw)
In-Reply-To: <4228CE41.2000102@us.ltcfwd.linux.ibm.com>
On Fri, Mar 04, 2005 at 04:08:17PM -0500, Wen Xiong wrote:
> +int get_jsm_board_number(void)
> +{
> + struct list_head *tmp;
> + struct jsm_board *cur_board_entry;
> + int adapter_count = 0;
> + u64 lock_flags;
> +
> + spin_lock_irqsave(&jsm_board_head_lock, lock_flags);
> + list_for_each(tmp, &jsm_board_head) {
> + cur_board_entry =
> + list_entry(tmp, struct jsm_board,
> + jsm_board_entry);
> + adapter_count++;
> + }
> + spin_unlock_irqrestore(&jsm_board_head_lock, lock_flags);
> +
> + return adapter_count;
> +}
Should this be static?
And it's returning the number of boards, not the current board number,
right?
And you have a indenting error in the list_for_each() section...
> +static ssize_t jsm_driver_version_show(struct device_driver *ddp, char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "jsm_version: %s\n", "jsm: 1.1-1-INKERNEL");
Shouldn't that value also be in MODULE_VERSION()? And if so, it should
be a #define somewhere.
Also, don't put "jsm:" in your sysfs files, the file name describes what
the value should be. That goes for a lot of your sysfs files.
> +static ssize_t jsm_driver_debug_show(struct device_driver *ddp, char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "0x%x\n", debug);
> +}
"debug" is not a nice variable to have in the global namespace :(
Also, why not just make this a module paramater, that way it can be
modified through that interface, and you don't have to create your own?
> +#define JSM_VERIFY_BOARD(p, bd) \
> + if (!p) \
> + return 0; \
> + bd = (struct jsm_board *)dev_get_drvdata(p); \
Cast is not needed.
> + if (!bd) \
> + return 0; \
> + if (bd->state != BOARD_READY) \
> + return 0; \
Don't break out of functions from within a macro. Will cause headaches
for people reviewing your code in the future.
And shouldn't you be returning an error if one of these checks fail?
> +static ssize_t jsm_ports_state_show(struct device *p, char *buf)
> +{
> + struct jsm_board *bd;
> + int count = 0;
> + int i = 0;
> +
> + JSM_VERIFY_BOARD(p, bd);
> +
> + for (i = 0; i < bd->nasync; i++) {
> + count += snprintf(buf + count, PAGE_SIZE - count,
> + "%d %s\n", bd->channels[i]->ch_portnum,
> + bd->channels[i]->ch_open_count ? "Open" : "Closed");
> + }
> + return count;
No, make this a per-port value. You are showing more than one value in
a single file. You do this for a few other sysfs files :(
And who cares about this value?
> +static ssize_t jsm_ports_baud_show(struct device *p, char *buf)
> +{
> + struct jsm_board *bd;
> + int count = 0;
> + int i = 0;
> +
> + JSM_VERIFY_BOARD(p, bd);
> +
> + for (i = 0; i < bd->nasync; i++) {
> + count += snprintf(buf + count, PAGE_SIZE - count,
> + "%d %d\n", bd->channels[i]->ch_portnum, bd->channels[i]->ch_old_baud);
> + }
> + return count;
> +}
> +static DEVICE_ATTR(ports_baud, S_IRUSR, jsm_ports_baud_show, NULL);
What's wrong with the standard tty ioctls that return this value, and
the other values you are exporting through sysfs? What is all of this
data needed for?
> +#define JSM_VERIFY_CHANNEL(p, ch) \
> + if (!p) \
> + return 0; \
> + ch = (struct jsm_channel *)class_get_devdata(p);\
> + if (!ch) \
> + return 0; \
> + if (ch->ch_bd->state != BOARD_READY) \
> + return 0; \
Again, don't put return in a macro, and return an error if there really
is one.
thanks,
greg k-h
next prev parent reply other threads:[~2005-03-05 0:13 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-27 23:39 [ patch 4/7] drivers/serial/jsm: new serial device driver Wen Xiong
2005-02-28 3:21 ` Christoph Hellwig
2005-02-28 6:39 ` Greg KH
2005-03-04 21:08 ` Wen Xiong
2005-03-04 22:01 ` Greg KH [this message]
2005-03-07 22:46 ` Wen Xiong
2005-03-08 6:44 ` Greg KH
2005-03-08 18:55 ` Wen Xiong
2005-03-08 23:58 ` Greg KH
2005-03-09 15:47 ` Wen Xiong
2005-03-09 16:35 ` Greg KH
2005-03-09 17:18 ` Wen Xiong
2005-03-09 18:58 ` Greg KH
2005-03-11 15:29 ` [ patch 1/5] " Wen Xiong
2005-03-12 13:06 ` Domen Puncer
2005-03-14 17:35 ` Wen Xiong
2005-03-14 20:24 ` Domen Puncer
2005-03-14 21:24 ` Wen Xiong
2005-03-11 15:32 ` [ patch 2/5] " Wen Xiong
2005-03-30 14:55 ` Russell King
2005-03-11 15:38 ` [ patch 3/5] " Wen Xiong
2005-03-11 15:53 ` Arjan van de Ven
2005-03-11 16:39 ` Wen Xiong
2005-03-11 16:46 ` Arjan van de Ven
2005-03-11 22:34 ` Wen Xiong
2005-03-30 15:01 ` Russell King
2005-03-11 15:38 ` [ patch 4/5] " Wen Xiong
2005-03-11 15:38 ` [ patch 5/5] " Wen Xiong
2005-03-09 16:11 ` [ patch 4/7] " Russell King
-- strict thread matches above, loose matches on Subject: below --
2005-03-08 21:47 Kilau, Scott
2005-03-09 0:02 ` Greg KH
2005-03-09 16:16 ` Russell King
2005-03-09 2:36 Kilau, Scott
2005-03-09 5:50 ` 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=20050304220116.GA1201@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wendyx@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.