[coreboot] [poll] device_t

[Aaron Durbin]

On Fri, May 8, 2015 at 12:16 PM, Patrick Georgi <pgeorgi at google.com> wrote:
> 2015-05-08 17:31 GMT+02:00 Aaron Durbin <adurbin at google.com>:
>> In romstage *both* struct device and device_t are present but are
>> completely different types. It's the romstage, ramstage, and smm
>> overlap that is large and extremely annoying to deal with.
> History time:
> Until not too long ago, bootblock and romstage used u32 device_t,
> ramstage used struct device, smm didn't really matter and nothing else
> existed.
> This was further enforced by struct device being available in ramstage
> _only_. We now have a read-only view of the device tree available in
> romstage that makes things look more complicated.
>
> One of the ideas that led to the devicetree in romstage was to make
> struct device the default interface where possible, together with the
> aforementioned isolation of romcc based code. Essentially: for romcc,
> use u32. For everything else, struct device.
>
> We may want to determine first what data structure we want to use in
> each stage. This could be 'u32 for all hardware accesses, with some
> struct device -> u32 conversion to move from devicetree to hardware',
> which sounds like what you propose (and is completely contrary to that
> other idea).

No. I was suggesting doing a struct device lookup from a u32 one.

Anyway, I think it's constructive to look at use cases. The struct
device code assumes that one has a reference to the struct device in
ramstage by way the state machine acting on each device. But then we
have to add lookup routines because that's not always the valid use
case. Even though struct device is there in romstage it's not used at
all for IO (as you mentioned the plan was never realized). A lot of
the juggling of types comes from the fact that there are statically
known pci devices, and one wants to talk to them outside of the
ramstage boot state machine. romstage has no concept nor a way to get
at each device w/o doing the tree walk. That coupled with IO routines
only operating on u32 devices makes one do the necessary back bends.

Can at least a short term goal be to remove the crufty handling found
in the examples I provided? Those are not the only 2, I'm sure. Does
that mean we bring in static.c for all stages? What about the dynamic
ops handling currently available in ramstage? Does that apply to all
stages?

I also wouldn't frame the discussion around the 'fate of device_t'.
It's really more about defining the semantics for the IO routines on
devices for each stage: how does one get a reference to said device?
how does one do that IO? Can the same code be compiled in all stages
w/o having to put per-compilation unit c preprocessor switches?

-Aaron