From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
Subject: Re: [PATCH] spi: enable spi_board_info to be registered after spi_master
Date: Tue, 27 Jul 2010 11:27:16 -0600 [thread overview]
Message-ID: <AANLkTi=C48+mnNjrxha8WqagCybF45f7aTn6nxt2qRuU@mail.gmail.com> (raw)
In-Reply-To: <1280223769-19919-1-git-send-email-feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Tue, Jul 27, 2010 at 3:42 AM, Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> Currently spi_register_board_info() has to be called before its related
> spi_master be registered, otherwise these board info will be just ignored.
>
> This patch will remove this order limit, it adds a global spi master list
> like the existing global board info listr. Whenever a board info is
> registered, the spi master list will be scanned, and a new spi device will
> be created if they match.
>
> Signed-off-by: Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
> drivers/spi/spi.c | 66 +++++++++++++++++++++++++++++++++-------------
> include/linux/spi/spi.h | 3 ++
> 2 files changed, 50 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index b3a1f92..f4a5221 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -196,13 +196,16 @@ EXPORT_SYMBOL_GPL(spi_register_driver);
>
> struct boardinfo {
> struct list_head list;
> - unsigned n_board_info;
> - struct spi_board_info board_info[0];
> + struct spi_board_info board_info;
> };
>
> static LIST_HEAD(board_list);
> static DEFINE_MUTEX(board_lock);
>
> +
> +static LIST_HEAD(master_list);
> +static DEFINE_MUTEX(master_lock);
> +
Protect against global namespace collisions. spi_master_list and
spi_master_list_lock.
You can probably use one mutex for both the board and master lists.
> /**
> * spi_alloc_device - Allocate a new SPI device
> * @master: Controller to which device is connected
> @@ -365,6 +368,19 @@ struct spi_device *spi_new_device(struct spi_master *master,
> }
> EXPORT_SYMBOL_GPL(spi_new_device);
>
> +static void scan_masterlist(struct spi_board_info *bi)
spi_scan_master_list
> +{
> + struct spi_master *master;
> +
> + mutex_lock(&master_lock);
> + list_for_each_entry(master, &master_list, list) {
> + if (master->bus_num != bi->bus_num)
> + continue;
> + (void) spi_new_device(master, bi);
Always check the return value. At the very least print out an error
message. I know you're copying the scan_boardinfo() lead, but that is
a bad example. There are error paths in spi_new_device() that will
not print any output.
> + }
> + mutex_unlock(&master_lock);
> +}
> +
> /**
> * spi_register_board_info - register SPI devices for a given board
> * @info: array of chip descriptors
> @@ -387,41 +403,45 @@ EXPORT_SYMBOL_GPL(spi_new_device);
> int __init
> spi_register_board_info(struct spi_board_info const *info, unsigned n)
> {
> - struct boardinfo *bi;
> + struct boardinfo *bi, *tmp_bi;
> + int i;
>
> - bi = kmalloc(sizeof(*bi) + n * sizeof *info, GFP_KERNEL);
> + bi = kzalloc(n * sizeof *bi, GFP_KERNEL);
sizeof(*bi)
> if (!bi)
> return -ENOMEM;
> - bi->n_board_info = n;
> - memcpy(bi->board_info, info, n * sizeof *info);
>
> + tmp_bi = bi;
> mutex_lock(&board_lock);
> - list_add_tail(&bi->list, &board_list);
> + for (i = 0; i < n; i++, bi++, info++) {
I'd do this the other way around (bi vs. tmp_bi). I think this is
somewhat clearer:
for (i = 0, tmp_bi = bi; i < n; i++, tmp_bi++, info++)
> + memcpy(&bi->board_info, info, sizeof *info);
> + list_add_tail(&bi->list, &board_list);
> + }
> mutex_unlock(&board_lock);
> +
> + bi = tmp_bi;
> + for (i = 0; i < n; i++)
> + scan_masterlist(&bi->board_info);
How does this work? The same board_info struct is passed to
scan_masterlist() multiple times.
> +
> return 0;
> }
>
> /* FIXME someone should add support for a __setup("spi", ...) that
> * creates board info from kernel command lines
> */
> -
> static void scan_boardinfo(struct spi_master *master)
> {
> struct boardinfo *bi;
>
> mutex_lock(&board_lock);
> list_for_each_entry(bi, &board_list, list) {
> - struct spi_board_info *chip = bi->board_info;
> - unsigned n;
> -
> - for (n = bi->n_board_info; n > 0; n--, chip++) {
> - if (chip->bus_num != master->bus_num)
> - continue;
> - /* NOTE: this relies on spi_new_device to
> - * issue diagnostics when given bogus inputs
> - */
> - (void) spi_new_device(master, chip);
> - }
> + struct spi_board_info *chip = &bi->board_info;
> +
> + if (chip->bus_num != master->bus_num)
> + continue;
> + /* NOTE: this relies on spi_new_device to
> + * issue diagnostics when given bogus inputs
> + */
> + (void) spi_new_device(master, chip);
> }
> mutex_unlock(&board_lock);
> }
> @@ -537,6 +557,10 @@ int spi_register_master(struct spi_master *master)
> dev_dbg(dev, "registered master %s%s\n", dev_name(&master->dev),
> dynamic ? " (dynamic)" : "");
>
> + mutex_lock(&master_lock);
> + list_add_tail(&master->list, &master_list);
> + mutex_unlock(&master_lock);
> +
There seems to be a race condition here. If a boardinfo is registered
after this list add, but before scan_boardinfo(master), then a
boardinfo can get parsed twice for a single master. I think the
proper thing to do is to hold the mutex over the whole operation; from
registering the list or master, until after the scan is complete.
Otherwise, in general I like the patch. spin it again to address the
comments, and I think I can get it into linux-next for 2.6.36.
Thanks!
g.
> /* populate children from any spi device tables */
> scan_boardinfo(master);
> status = 0;
> @@ -568,6 +592,10 @@ void spi_unregister_master(struct spi_master *master)
> {
> int dummy;
>
> + mutex_lock(&master_lock);
> + list_del(&master->list);
> + mutex_unlock(&master_lock);
> +
> dummy = device_for_each_child(master->dev.parent, &master->dev,
> __unregister);
> device_unregister(&master->dev);
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index af56071..f4a29b6 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -204,6 +204,7 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
> /**
> * struct spi_master - interface to SPI master controller
> * @dev: device interface to this driver
> + * @list: link with the global spi_master list
> * @bus_num: board-specific (and often SOC-specific) identifier for a
> * given SPI controller.
> * @num_chipselect: chipselects are used to distinguish individual
> @@ -235,6 +236,8 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
> struct spi_master {
> struct device dev;
>
> + struct list_head list;
> +
> /* other than negative (== assign one dynamically), bus_num is fully
> * board-specific. usually that simplifies to being SOC-specific.
> * example: one SOC has three SPI controllers, numbered 0..2,
> --
> 1.7.0.4
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
next prev parent reply other threads:[~2010-07-27 17:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 9:42 [PATCH] spi: enable spi_board_info to be registered after spi_master Feng Tang
[not found] ` <1280223769-19919-1-git-send-email-feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2010-07-27 17:27 ` Grant Likely [this message]
[not found] ` <AANLkTi=C48+mnNjrxha8WqagCybF45f7aTn6nxt2qRuU-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-07-28 1:23 ` Feng Tang
2010-07-28 2:22 ` Feng Tang
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='AANLkTi=C48+mnNjrxha8WqagCybF45f7aTn6nxt2qRuU@mail.gmail.com' \
--to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
--cc=alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org \
--cc=feng.tang-ral2JQCrhuEAvxtiuMwx3w@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).