On 10/2/07, Peter Korsgaard <[EMAIL PROTECTED]> wrote:
> >>>>> "Grant" == Grant Likely <[EMAIL PROTECTED]> 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.
[EMAIL PROTECTED]
(403) 399-0195
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
