From: David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
To: Christian Pellegrin <chripell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Christian Pellegrin <chripell-VaTbYqLCNhc@public.gmane.org>,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org
Subject: Re: [PATCH RESEND] max3100 driver
Date: Wed, 24 Sep 2008 21:56:29 -0700 [thread overview]
Message-ID: <200809242156.29505.david-b@pacbell.net> (raw)
In-Reply-To: <12219154581088-git-send-email-chripell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
You got this working ... congrats! :)
Small suggestion: next time you resend this, make sure
that $SUBJECT mentions it's a UART driver. Maybe even that
it's a SPI UART driver. That should help get more comments.
On Saturday 20 September 2008, Christian Pellegrin wrote:
> +struct plat_max3100 {
> +/* force MAX3100 in loopback */
> + int loopback;
> +/* 0 for 3.6864 Mhz, 1 for 1.8432 */
> + int crystal;
> +/* for archs like PXA with only edge irqs */
> + int only_edge_irq;
> +/* MAX3100 has a shutdown pin. This is a hook
> + called on suspend and resume to activate it.*/
> + void (*max3100_hw_suspend) (int suspend);
> +/* poll time for ctr signals in ms, 0 disables (so no hw flow
> + * ctrl is possible) */
> + int poll_time;
> +};
This is a bit picky, but it's the first thing I noticed when
scanning the patch ... wierd comment layout! Either indent
those all, or (better) convert to kerneldoc style.
Potentially less picky: probe() doesn't lock max3100s[],
neither does remove(), and in fact there seems to be no
lock for that table. Which suggests trouble in cases like
concurrent I/O (including open) and driver remove(). You
should probably just allocate a mutex to help control that
table, like most other drivers.
And is that workqueue single threaded?
I just skimmed the rest of the driver. Seems to be
fairly straightforward -- at least the non-TTY bits.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Christian Pellegrin <chripell@gmail.com>
Cc: spi-devel-general@lists.sourceforge.net,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
Christian Pellegrin <chripell@fsfe.org>,
alan@lxorguk.ukuu.org.uk, linux-serial@vger.kernel.org
Subject: Re: [spi-devel-general] [PATCH RESEND] max3100 driver
Date: Wed, 24 Sep 2008 21:56:29 -0700 [thread overview]
Message-ID: <200809242156.29505.david-b@pacbell.net> (raw)
In-Reply-To: <12219154581088-git-send-email-chripell@gmail.com>
You got this working ... congrats! :)
Small suggestion: next time you resend this, make sure
that $SUBJECT mentions it's a UART driver. Maybe even that
it's a SPI UART driver. That should help get more comments.
On Saturday 20 September 2008, Christian Pellegrin wrote:
> +struct plat_max3100 {
> +/* force MAX3100 in loopback */
> + int loopback;
> +/* 0 for 3.6864 Mhz, 1 for 1.8432 */
> + int crystal;
> +/* for archs like PXA with only edge irqs */
> + int only_edge_irq;
> +/* MAX3100 has a shutdown pin. This is a hook
> + called on suspend and resume to activate it.*/
> + void (*max3100_hw_suspend) (int suspend);
> +/* poll time for ctr signals in ms, 0 disables (so no hw flow
> + * ctrl is possible) */
> + int poll_time;
> +};
This is a bit picky, but it's the first thing I noticed when
scanning the patch ... wierd comment layout! Either indent
those all, or (better) convert to kerneldoc style.
Potentially less picky: probe() doesn't lock max3100s[],
neither does remove(), and in fact there seems to be no
lock for that table. Which suggests trouble in cases like
concurrent I/O (including open) and driver remove(). You
should probably just allocate a mutex to help control that
table, like most other drivers.
And is that workqueue single threaded?
I just skimmed the rest of the driver. Seems to be
fairly straightforward -- at least the non-TTY bits.
next prev parent reply other threads:[~2008-09-25 4:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-20 12:57 [PATCH RESEND] max3100 driver Christian Pellegrin
[not found] ` <12219154581088-git-send-email-chripell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-09-25 4:56 ` David Brownell [this message]
2008-09-25 4:56 ` [spi-devel-general] " David Brownell
[not found] ` <200809242156.29505.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
2008-09-25 7:07 ` chri
2008-09-25 7:07 ` [spi-devel-general] " chri
-- strict thread matches above, loose matches on Subject: below --
2007-12-28 13:01 chripell
2007-12-29 1:38 ` Jan Engelhardt
2007-12-29 6:34 ` chri
2007-12-29 10:27 ` chripell
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=200809242156.29505.david-b@pacbell.net \
--to=david-b-ybekhbn/0ldr7s880joybq@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org \
--cc=chripell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=chripell-VaTbYqLCNhc@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
/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.