From: cyril@ti.com (Cyril Chemparathy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 04/12] spi: add ti-ssp spi master driver
Date: Wed, 17 Nov 2010 12:35:37 -0500 [thread overview]
Message-ID: <4CE41269.2040303@ti.com> (raw)
In-Reply-To: <20101117161130.GC5757@angua.secretlab.ca>
On 11/17/2010 11:11 AM, Grant Likely wrote:
[...]
> To start, I'm not a fan of matching by name. It's fragile because it
> makes assumptions about how devices will be names when they actually
> appear (ie. Sometimes .id is dynamically assigned). Ideally I'd
> prefer to have direct references (ie. pointers) to the devices that
> need to be registered, which *shouldn't* be difficult to handle. That
> guarantees that the correct device is always referenced. (aside: the
> device-tree use case provides this information by having direct
> 'phandle' references between dependencies.)
The pointer approach is possibly problematic with devices that get
registered by other drivers/masters (mfd, spi, i2c, etc.). With these
devices the board doesn't really have a reference to the device in question.
Something along the following lines may be better:
int device_requires(struct device *dev, const char *res);
int device_provides(struct device *provider, const char *res);
where res is a string of the form "gpio:25", "regulator:vlcd", or even
"dev:<dev_name>".
device_requires() would typically be used by board implementations, and
device_provides() would be called by gpiolib, regulator core, device
core, etc.
I guess this is somewhat along the lines of an earlier discussion on the
PPC list ([1] below), except that the drivers don't get probed until
specified prereqs are available.
Regards
Cyril.
[1] http://www.spinics.net/lists/linux-embedded/msg02764.html
next prev parent reply other threads:[~2010-11-17 17:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 19:12 [PATCH v5 00/12] tnetv107x ssp drivers Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 01/12] misc: add driver for sequencer serial port Cyril Chemparathy
2010-11-16 7:10 ` Grant Likely
2010-11-16 16:15 ` Cyril Chemparathy
2010-11-16 20:35 ` Grant Likely
2010-11-16 21:19 ` Cyril Chemparathy
2010-11-16 22:23 ` Russell King - ARM Linux
2010-11-16 23:57 ` Grant Likely
2010-11-15 19:12 ` [PATCH v5 02/12] davinci: add tnetv107x ssp platform device Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 03/12] davinci: add ssp config for tnetv107x evm board Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 04/12] spi: add ti-ssp spi master driver Cyril Chemparathy
2010-11-15 21:59 ` Ryan Mallon
2010-11-16 7:22 ` Grant Likely
2010-11-16 7:47 ` Grant Likely
2010-11-16 11:34 ` Mark Brown
2010-11-16 20:45 ` Grant Likely
2010-11-16 22:48 ` Mark Brown
2010-11-17 0:17 ` Cyril Chemparathy
2010-11-17 13:31 ` Mark Brown
2010-11-17 15:25 ` David Brownell
2010-11-17 17:54 ` Cyril Chemparathy
2010-11-17 16:11 ` Grant Likely
2010-11-17 17:23 ` Mark Brown
2010-11-17 17:35 ` Cyril Chemparathy [this message]
2010-11-18 5:46 ` Greg KH
2010-11-25 23:32 ` Rafael J. Wysocki
2010-11-16 14:19 ` David Brownell
2010-11-15 19:12 ` [PATCH v5 05/12] davinci: add spi devices on tnetv107x evm Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 06/12] regulator: add driver for tps6524x regulator Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 07/12] davinci: add tnetv107x evm regulators Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 08/12] gpio: add ti-ssp gpio driver Cyril Chemparathy
2010-11-15 22:38 ` Ryan Mallon
2010-11-16 19:38 ` Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 09/12] davinci: add tnetv107x evm ti-ssp gpio device Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 10/12] backlight: add support for tps6116x controller Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 11/12] davinci: add tnetv107x evm backlight device Cyril Chemparathy
2010-11-15 19:12 ` [PATCH v5 12/12] davinci: add tnetv107x evm i2c eeprom device Cyril Chemparathy
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=4CE41269.2040303@ti.com \
--to=cyril@ti.com \
--cc=linux-arm-kernel@lists.infradead.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).