[PATCH] drivers vs. obj

[Myles Watson]

On Thu, Sep 24, 2009 at 12:52 AM, Stefan Reinauer wrote:
Myles Watson wrote:
> Are there other differences?  Should I2C devices use objects, since
> you can't scan for them?

Some structures defined in the code are put in an extra section in the
binary for enumeration. Those are:

#define __console    __attribute__((used,
__section__(".rodata.console_drivers")))
#define __cpu_driver __attribute__((used,__section__(".rodata.cpu_driver")))
#define __pci_driver __attribute__((used,__section__(".rodata.pci_driver")))

All others don't need to be "drivers"

Stefan

---------------
Based on that, here's a patch that changes drivers that aren't console, pci,
or cpu, to obj.

The most common one was mainboard.c as a driver.

Boot tested with Tyan s2895.

Signed-off-by: Myles Watson

Thanks,
Myles

PS.  It looks like the rtl8168 driver ought to go somewhere more general in
the tree.

[Stefan Reinauer]

Myles Watson wrote:
> PS.  It looks like the rtl8168 driver ought to go somewhere more
> general in the tree.

It's not really a driver but only keeps the device allocator from trying
to execute an option rom where there is none. I'm not sure if that
really happens on other boards with that chip...

Stefan

[Myles Watson]

On Fri, Sep 25, 2009 at 2:25 PM, Stefan Reinauer  wrote:
> Myles Watson wrote:
> > PS.  It looks like the rtl8168 driver ought to go somewhere more
> > general in the tree.
>
> It's not really a driver but only keeps the device allocator from trying
> to execute an option rom where there is none. I'm not sure if that
> really happens on other boards with that chip...

I don't know how common that is.  Maybe there should be a flavor of
the onboard driver for that.

Thanks,
Myles

[Stefan Reinauer]

Myles Watson wrote:
> On Fri, Sep 25, 2009 at 2:25 PM, Stefan Reinauer  wrote:
> > Myles Watson wrote:
> > > PS.  It looks like the rtl8168 driver ought to go somewhere more
> > > general in the tree.
> >
> > It's not really a driver but only keeps the device allocator from trying
> > to execute an option rom where there is none. I'm not sure if that
> > really happens on other boards with that chip...
>
> I don't know how common that is.  Maybe there should be a flavor of
> the onboard driver for that.

Ah, I looked at that driver today... Should we drop that, now that we
have CBFS everywhere?
It was only used for onboard pci devices with option roms in the system
bios. Which is no longer done that way...

[Myles Watson]

> > > > PS.  It looks like the rtl8168 driver ought to go somewhere more
> > > > general in the tree.
>
> Ah, I looked at that driver today... Should we drop that, now that we
> have CBFS everywhere?
> It was only used for onboard pci devices with option roms in the system
> bios. Which is no longer done that way...

I'd ack that patch.

Myles

[Stefan Reinauer]

Myles Watson wrote:
> >>> PS.  It looks like the rtl8168 driver ought to go somewhere more
> >>> general in the tree.
>
> Ah, I looked at that driver today... Should we drop that, now that we
> have CBFS everywhere?
> It was only used for onboard pci devices with option roms in the
> system
> bios. Which is no longer done that way...
>
>
> I'd ack that patch.

Ok, I put it on my todo list.. right now there's 139 references of that
driver in the code, so it's more than a quick shot on a tired evening..
BTW, I am hunting another bug with an onboard rtl8168 that comes up as
an 8129 after reset... (Seems it can't read its EEPROM anymore after
Linux talked to it) .. hope to get a patch done for that today.

Stefan

[Myles Watson]

On Thu, Sep 24, 2009 at 2:59 PM, Myles Watson  wrote:
> On Thu, Sep 24, 2009 at 12:52 AM, Stefan Reinauer 
> wrote:
> Myles Watson wrote:
> > Are there other differences?  Should I2C devices use objects, since
> > you can't scan for them?
>
> Some structures defined in the code are put in an extra section in the
> binary for enumeration. Those are:
>
> #define __console    __attribute__((used,
> __section__(".rodata.console_drivers")))
> #define __cpu_driver __attribute__((used,__section__(".rodata.cpu_driver")))
> #define __pci_driver __attribute__((used,__section__(".rodata.pci_driver")))
>
> All others don't need to be "drivers"
>
> Stefan
>
> Based on that, here's a patch that changes drivers that aren't console, pci,
> or cpu, to obj.
>
> The most common one was mainboard.c as a driver.
>
> Boot tested with Tyan s2895.
>
> Signed-off-by: Myles Watson

Ping.

[Patrick Georgi]

Am 24.09.2009 22:59, schrieb Myles Watson:
> Based on that, here's a patch that changes drivers that aren't console,
> pci, or cpu, to obj.
>
> The most common one was mainboard.c as a driver.
>
> Boot tested with Tyan s2895.
>
> Signed-off-by: Myles Watson

I updated the patch, with all the boards converted that appeared in
Kconfig after this patch was made, too. There's not a single driver in
src/mainboard left.

Signed-off-by: Patrick Georgi

[Myles Watson]

On Tue, Feb 23, 2010 at 8:37 AM, Patrick Georgi wrote:
> Am 24.09.2009 22:59, schrieb Myles Watson:
> > Based on that, here's a patch that changes drivers that aren't console,
> > pci, or cpu, to obj.
> >
> > The most common one was mainboard.c as a driver.
> >
> > Boot tested with Tyan s2895.
> >
> > Signed-off-by: Myles Watson
>
> I updated the patch, with all the boards converted that appeared in
> Kconfig after this patch was made, too. There's not a single driver in
> src/mainboard left.
>
> Signed-off-by: Patrick Georgi

Index: src/mainboard/roda/rk886ex/Makefile.inc
===================================================================
--- src/mainboard/roda/rk886ex/Makefile.inc    (revision 5149)
+++ src/mainboard/roda/rk886ex/Makefile.inc    (working copy)
@@ -21,10 +21,10 @@
 ## This mainboard requires DCACHE_AS_RAM enabled. It won't work without.
 ##

-driver-y += mainboard.o
-driver-y += m3885.o
-driver-y += ec.o
-driver-y += rtl8168.o
+obj-y += mainboard.o
+obj-y += m3885.o
+obj-y += ec.o
+obj-y += rtl8168.o

It looks like rtl8168 should stay a driver, since it's a PCI device. I don't
know about m3885.o and ec.o. I'm also not sure about the debug devices.  Are
they considered PCI?  It's been a long time since I thought about this.

Thanks,
Myles

[Patrick Georgi]

Am 23.02.2010 17:28, schrieb Myles Watson:
> -driver-y += mainboard.o
> -driver-y += m3885.o
> -driver-y += ec.o
> -driver-y += rtl8168.o
> +obj-y += mainboard.o
> +obj-y += m3885.o
> +obj-y += ec.o
> +obj-y += rtl8168.o
>
> It looks like rtl8168 should stay a driver, since it's a PCI device. I
> don't know about m3885.o and ec.o. I'm also not sure about the debug
> devices.  Are they considered PCI?  It's been a long time since I
> thought about this.

As I understand it, the main criterion was if they're using the linker
magic. I couldn't find any of that in there, but maybe that's just too
hidden for my (short, I admit) glance?

Patrick

[Stefan Reinauer]

On 2/23/10 4:37 PM, Patrick Georgi wrote:
> Am 24.09.2009 22:59, schrieb Myles Watson:
> > Based on that, here's a patch that changes drivers that aren't console,
> > pci, or cpu, to obj.
> >
> > The most common one was mainboard.c as a driver.
> >
> > Boot tested with Tyan s2895.
> >
> > Signed-off-by: Myles Watson
>
> I updated the patch, with all the boards converted that appeared in
> Kconfig after this patch was made, too. There's not a single driver in
> src/mainboard left.
>
> Signed-off-by: Patrick Georgi

Acked-by: Stefan Reinauer

[Stefan Reinauer]

On 2/23/10 5:29 PM, Patrick Georgi wrote:
> Am 23.02.2010 17:28, schrieb Myles Watson:
> > -driver-y += mainboard.o
> > -driver-y += m3885.o
> > -driver-y += ec.o
> > -driver-y += rtl8168.o
> > +obj-y += mainboard.o
> > +obj-y += m3885.o
> > +obj-y += ec.o
> > +obj-y += rtl8168.o
> >
> > It looks like rtl8168 should stay a driver, since it's a PCI device. I
> > don't know about m3885.o and ec.o. I'm also not sure about the debug
> > devices.  Are they considered PCI?  It's been a long time since I
> > thought about this.
>
> As I understand it, the main criterion was if they're using the linker
> magic. I couldn't find any of that in there, but maybe that's just too
> hidden for my (short, I admit) glance?

No, that's right.. the EC code is only called from mainboard.c and the
SMM handler