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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox