From: Peter Korsgaard <jacmet@sunsite.dk>
To: "Grant Likely" <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
Date: Tue, 02 Oct 2007 17:58:46 +0200 [thread overview]
Message-ID: <871wcd33ux.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <fa686aa40710020726s330d586p6ece70ae378f1206@mail.gmail.com> (Grant Likely's message of "Tue\, 2 Oct 2007 08\:26\:42 -0600")
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
Grant> static int __devinit
Grant> ulite_of_probe(struct of_device *op, const struct of_device_id *match)
This looks like uartlite code to me ;)
Grant> {
Grant> struct resource res;
Grant> const unsigned int *id;
Grant> int irq, rc;
Grant> dev_dbg(&op->dev, "%s(%p, %p)\n", __FUNCTION__, op, match);
Grant> rc = of_address_to_resource(op->node, 0, &res);
Grant> if (rc) {
Grant> dev_err(&op->dev, "invalide address\n");
Grant> return rc;
Grant> }
Grant> irq = irq_of_parse_and_map(op->node, 0);
Grant> id = of_get_property(op->node, "port-number", NULL);
Grant> return ulite_assign(&op->dev, id ? *id : -1, res.start, irq);
Grant> }
Grant> What advantages do you see with the constructor approach?
One advantage is that it keeps the of stuff out of the drivers. There
already is one bus for platform stuff in the kernel, so from a device
driver writer POV the of stuff is just extra fluff. Imagine the ARM or
MIPS people coming up with 2 other incompatible ways of doing this and
you'll see the drivers bloat.
E.G. I use the smsc911x.c network driver on powerpc which is written
by an ARM guy. Why should he need to care about of stuff in his driver?
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2007-10-02 15:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-30 22:41 [PATCH 2 1/7] Uartlite: Fix reg io to access documented register size Grant Likely
2007-09-30 22:41 ` [PATCH 2 2/7] Uartlite: change name of ports to ulite_ports Grant Likely
2007-10-02 18:46 ` Peter Korsgaard
2007-09-30 22:41 ` [PATCH 2 3/7] Uartlite: Add macro for uartlite device name Grant Likely
2007-10-02 18:45 ` Peter Korsgaard
2007-09-30 22:41 ` [PATCH 2 4/7] Uartlite: Separate the bus binding from the driver proper Grant Likely
2007-09-30 22:42 ` [PATCH 2 5/7] Uartlite: Comment block tidy Grant Likely
2007-10-02 18:46 ` Peter Korsgaard
2007-09-30 22:42 ` [PATCH 2 6/7] Uartlite: Add of-platform-bus binding Grant Likely
2007-10-02 5:53 ` Benjamin Herrenschmidt
2007-10-02 14:26 ` Grant Likely
2007-10-02 15:58 ` Peter Korsgaard [this message]
2007-10-02 16:10 ` Scott Wood
2007-10-02 16:23 ` Grant Likely
2007-10-02 16:10 ` Grant Likely
2007-10-02 22:43 ` Benjamin Herrenschmidt
2007-10-03 4:18 ` Grant Likely
2007-10-03 4:24 ` Benjamin Herrenschmidt
2007-10-03 14:39 ` Grant Likely
2007-10-03 21:21 ` Benjamin Herrenschmidt
2007-10-02 18:49 ` Peter Korsgaard
2007-09-30 22:42 ` [PATCH 2 7/7] Uartlite: Let the console be initialized earlier Grant Likely
2007-10-02 18:48 ` Peter Korsgaard
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=871wcd33ux.fsf@macbook.be.48ers.dk \
--to=jacmet@sunsite.dk \
--cc=grant.likely@secretlab.ca \
--cc=linuxppc-dev@ozlabs.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.