[v10,04/17] core/fdt: OPAL API opal_get_device_tree()

Gavin Shan <gwshan@linux.vnet.ibm.com> writes:
> This implements OPAL API opal_get_device_tree(), which will be used
> to retrieve the device sub-tree introduced by newly hot plugged PCI
> devices.
>
> The argument @phandle of the API indicates the specified device
> node that is the PCI slot's device node in PCI hotplug case. @buf
> is the memory buffer allocated from kernel to hold the FDT blob.
> @len is the length of the memory buffer. The FDT blob is put into
> the memory buffer indicated by @buf and OPAL_SUCCESS is returned
> on success. Otherwise, errcode is returned accordingly.
>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> ---
>  core/fdt.c         | 111 +++++++++++++++++++++++++++++++++++------------------
>  include/opal-api.h |   3 +-
>  2 files changed, 75 insertions(+), 39 deletions(-)

Also need to add doc/opal-api/opal-get-device-tree-118.txt.

Here's the start of it:



> diff --git a/core/fdt.c b/core/fdt.c
> index a9392b1..f82927a 100644
> --- a/core/fdt.c
> +++ b/core/fdt.c
...
> -		fdt_create(fdt, len);
> +static int64_t opal_get_device_tree(uint32_t phandle,
> +				    uint64_t buf,
> +				    uint64_t len)

Another thought on API - have len be a pointer, and in the event of
OPAL_NO_MEM, have it set to a value that will work for this phandle
(assuming nothing more changes in the meantime) - and have that work if
buf is NULL and len=0.

Except that the fdt code fights us against that a bit... but it should
be possible to fix it up to do a decent calculation.

On Wed, May 11, 2016 at 11:42:01AM +1000, Stewart Smith wrote:
>Gavin Shan <gwshan@linux.vnet.ibm.com> writes:
>> This implements OPAL API opal_get_device_tree(), which will be used
>> to retrieve the device sub-tree introduced by newly hot plugged PCI
>> devices.
>>
>> The argument @phandle of the API indicates the specified device
>> node that is the PCI slot's device node in PCI hotplug case. @buf
>> is the memory buffer allocated from kernel to hold the FDT blob.
>> @len is the length of the memory buffer. The FDT blob is put into
>> the memory buffer indicated by @buf and OPAL_SUCCESS is returned
>> on success. Otherwise, errcode is returned accordingly.
>>
>> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>> ---
>>  core/fdt.c         | 111 +++++++++++++++++++++++++++++++++++------------------
>>  include/opal-api.h |   3 +-
>>  2 files changed, 75 insertions(+), 39 deletions(-)
>
>Also need to add doc/opal-api/opal-get-device-tree-118.txt.
>
>Here's the start of it:
>
>diff --git a/doc/opal-api/opal-get-device-tree-118.txt b/doc/opal-api/opal-get-device-tree-118.txt
>new file mode 100644
>index 000000000000..17fec7461a8d
>--- /dev/null
>+++ b/doc/opal-api/opal-get-device-tree-118.txt
>@@ -0,0 +1,24 @@
>+OPAL_GET_DEVICE_TREE
>+--------------------
>+
>+Get part of the current device tree.
>+
>+Parameters:
>+	uint32_t phandle: phandle of the subtree to get
>+	uint64_t buf: buffer for flattended device tree
>+	uint64_t len: length of buffer
>+
>+Calling:
>+
>+The typical use for OPAL_GET_DEVICE_TREE is after the host has been notified
>+of a change to hardware at runtime.
>+
>+Return Codes:
>+OPAL_SUCCESS
>+- Successfully wrote flattened device tree into buf
>+OPAL_PARAMETER:
>+- buf, len or phandle is invalid
>+OPAL_NO_MEM:
>+- not enough room in buffer for device tree.
>+OPAL_EMPTY:
>+- nothing to flatten
>
>

I didn't notice we alrady had the short description directory for OPAL APIs.
Thanks, Stewart. I will add one based on what is given by you.

>> diff --git a/core/fdt.c b/core/fdt.c
>> index a9392b1..f82927a 100644
>> --- a/core/fdt.c
>> +++ b/core/fdt.c
>...
>> -		fdt_create(fdt, len);
>> +static int64_t opal_get_device_tree(uint32_t phandle,
>> +				    uint64_t buf,
>> +				    uint64_t len)
>
>Another thought on API - have len be a pointer, and in the event of
>OPAL_NO_MEM, have it set to a value that will work for this phandle
>(assuming nothing more changes in the meantime) - and have that work if
>buf is NULL and len=0.
>
>Except that the fdt code fights us against that a bit... but it should
>be possible to fix it up to do a decent calculation.
>

Yeah, I will enhance it in next revision like this: The required FDT
blob buffer size is returned when @buf is NULL.

Thanks,
Gavin

>
>-- 
>Stewart Smith
>OPAL Architect, IBM.