[OpenBIOS] [PATCH 2/2] SPARC64: add an eeprom node to the device tree

[Mark Cave-Ayland]

On 19/01/15 16:34, Mark Cave-Ayland wrote:

> On 19/01/15 13:24, Artyom Tarasenko wrote:
> 
>> Hi Mark,
>>
>> back then I was in a hurry to get it in an upcoming release. Now as we
>> are not in a rush...
> 
> Ha! ;)
> 
>> On Mon, Jan 19, 2015 at 2:09 PM, Mark Cave-Ayland
>> <mark.cave-ayland at ilande.co.uk> wrote:
>>> From: Artyom Tarasenko <atar4qemu at gmail.com>
>>>
>>> Add eeprom node to the device tree to make device visible for
>>> the guest OS.
>>>
>>> Signed-off-by: Artyom Tarasenko <atar4qemu at gmail.com>
>>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk>
>>> ---
>>>  openbios-devel/drivers/pci.c |   20 ++++++++++++++++++++
>>>  1 file changed, 20 insertions(+)
>>>
>>> diff --git a/openbios-devel/drivers/pci.c b/openbios-devel/drivers/pci.c
>>> index 3260354..366f4a1 100644
>>> --- a/openbios-devel/drivers/pci.c
>>> +++ b/openbios-devel/drivers/pci.c
>>> @@ -831,6 +831,26 @@ int ebus_config_cb(const pci_config_t *config)
>>>
>>>      set_property(dev, "ranges", (char *)props, ncells * sizeof(props[0]));
>>>
>>> +    /*  Build eeprom node */
>>> +    fword("new-device");
>>> +    PUSH(0x14);
>>> +    fword("encode-int");
>>> +    PUSH(0x2000);
>>
>> PUSH(NVRAM_BASE)
>>
>>> +    fword("encode-int");
>>> +    fword("encode+");
>>> +    PUSH(0x2000);
>>
>> PUSH(NVRAM_SIZE);
>>
>>> +    fword("encode-int");
>>> +    fword("encode+");
>>> +    push_str("reg");
>>> +    fword("property");
>>> +
>>> +    push_str("mk48t59");
>>> +    fword("model");
>>> +
>>> +    push_str("eeprom");
>>> +    fword("device-name");
>>> +    fword("finish-device");
>>> +
>>>  #ifdef CONFIG_DRIVER_FLOPPY
>>>      ob_floppy_init(config->path, "fdthree", 0x3f0ULL, 0);
>>>  #endif
>>> --
>>> 1.7.10.4
> 
> Looks fairly sensible. I'll make the changes and respin in a bit...

Having looked at this again, the main issue is that with doing this we
start to bring in an architecture dependency into drivers/pci.c which I
don't think particularly buys us much, particularly as all of the other
ebus devices with _init() functions are still initialised with their bus
offset address without more friendly macros.

So I'm inclined to leave this as is for the moment unless someone feels
particularly strongly about it.


ATB,

Mark.