linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Peter Korsgaard" <jacmet@sunsite.dk>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
Date: Tue, 2 Oct 2007 10:10:20 -0600	[thread overview]
Message-ID: <fa686aa40710020910u3a679ea2m15b005d0ba5fb054@mail.gmail.com> (raw)
In-Reply-To: <871wcd33ux.fsf@macbook.be.48ers.dk>

On 10/2/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "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?

The problem is that driver specific constructor code needs to be
written regardless.  Where should it live?  With the driver or in the
arch code?  Actually, with the arch code doesn't work well either
because multiple archs will be using of_platform (microblaze for
example), so they need to live somewhere common.

My opinion is that since it is driver-specific code anyway, then it
belongs with the driver.  Plus a driver writer for ARM doesn't need to
write them.  It's the powerpc or microblaze developer who will do it.
If the driver maintainer doesn't want the binding in the main driver
.c file, then the binding can easily be in an additional .c file
without needing to add a constructor.  (Kind of like how many USB host
controllers are managed)

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

  parent reply	other threads:[~2007-10-02 16:10 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
2007-10-02 16:10         ` Scott Wood
2007-10-02 16:23           ` Grant Likely
2007-10-02 16:10         ` Grant Likely [this message]
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=fa686aa40710020910u3a679ea2m15b005d0ba5fb054@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=jacmet@sunsite.dk \
    --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 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).