On Sat, 2 Jan 2010, Geert Uytterhoeven wrote:
> On Tue, Nov 17, 2009 at 10:04, Finn Thain <fth...@telegraphics.com.au>
> wrote:
> > Add platform driver to the pmac-zilog driver for mac 68k, putting the
> > powermac-specific bits inside #ifdef CONFIG_PPC_PMAC.
>
> > --- linux-2.6.31.orig/drivers/serial/pmac_zilog.c 2009-11-17
> > 17:07:28.000000000 +1100
> > +++ linux-2.6.31/drivers/serial/pmac_zilog.c 2009-11-17
> > 17:07:38.000000000 +1100
>
> > @@ -1427,6 +1439,8 @@ static struct uart_ops pmz_pops = {
> > #endif
> > };
> >
> > +#ifdef CONFIG_PPC_PMAC
> > +
> > /*
> > * Setup one port structure after probing, HW is down at this point,
> > * Unlike sunzilog, we don't need to pre-init the spinlock as we don't
> > @@ -1823,6 +1837,88 @@ next:
> > return 0;
> > }
> >
> > +#else
> > +
> > +extern struct platform_device scc_a_pdev, scc_b_pdev;
>
> scripts/checkpatch.pl doesn't like this extern, and it's right.
> Can't this be found using standard platform device/driver matching?
The console initcall and arch initcall order didn't permit me to easily
gather the bootinfo data and populate the platform device resources early
enough. (On powermacs there is the open firmware device tree, but of
course, we don't have one.)
I would like to further adopt the driver model in order to ditch the
macintosh_config global, and I'd also like to have proper nubus device
matching. But I think that the serial console device is a bit exceptional
so I'm not too fussed about these two globals.
Anyway, I don't know of a better way to do the serial console but I'm open
to suggestions.
> BTW, there are a few other minor checkpatch issues with some of the
> other patches in the series, too.
I ran checkpatch on all those patches before I submitted them. I ignored
some of the complaints about whitespace where I felt that checkpatch got
it wrong (space character following tab character, IIRC).
checkpatch found lots of mistakes that I did fix, but it can't determine
the most human readable style in all cases, especially where consistency
with the surrounding code is actually more conducive to readability than
strict but sporadic conformance to simple rules would be.
Finn
>
> Gr{oetje,eeting}s,
>
> Geert
> _______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
