[U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Rob Clark]

On Wed, Oct 4, 2017 at 12:29 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 10/04/2017 05:25 PM, Alexander Graf wrote:
>>
>>
>> On 04.10.17 16:57, Rob Clark wrote:
>>> On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt
>>> <xypron.glpk at gmx.de> wrote:
>>>> On 10/04/2017 04:14 PM, Rob Clark wrote:
>>>>> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt
>>>>> <xypron.glpk at gmx.de> wrote:
>>>>>> Queued and signaled describe boolean states of events.
>>>>>> So let's use type bool and rename the structure members to is_queued
>>>>>> and is_signaled.
>>>>>>
>>>>>> Update the comments for is_queued and is_signaled.
>>>>>
>>>>> Reviewed-by: Rob Clark <robdclark at gmail.com>
>>>>>
>>>>> It would be kinda nice to merge my efi_event fixes and rework to use
>>>>> an arbitrary sized list of events before making too many more
>>>>> efi_event changes, since that is kind of annoying to keep rebasing ;-)
>>>>>
>>>>> BR,
>>>>> -R
>>>>
>>>> I would not mind if you patch went first.
>>>>
>>>> But your patch
>>>> https://patchwork.ozlabs.org/patch/812967/
>>>> is not applicable to U-Boot master and needs rebasing anyway.
>>>
>>> jfyi, I have it (and other pending patches) rebased on latest master
>>> (as of ~yesterday) here:
>>>
>>>    https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell
>>>
>>> I wasn't planning on resending until I get further with FAT write
>>> stuff (currently on a local branch, although I might not get much time
>>> to work on in the next week or two).. although I can re-send it or any
>>> of the other patches to get Shell.efi working if wanted.  (Note that
>>> I'm also using your patch for efi watchdog support, that was one of
>>> the other required bits.)
>>>
>>> Not sure what agraf's plan is but I think the needed bits for
>>> Shell.efi are mergable already.
>>
>> I don't have a concrete plan - in general I consider patches that have
>> unaddressed review comments as "not to be applied atm" though and I'm
>> not sure I have anything pending from you that would not fall into that
>> category :).
>>
>> Can you split off a series that has Heinrich's blessing to get us as far
>> as we can, so we can keep your queue short?
>>
>
> These are the two first patches in Rob's queue:
>
> efi_loader: support 16 protocols per efi_object
> https://patchwork.ozlabs.org/patch/806167/
>
> efi_loader: allow creating new handles
> https://patchwork.ozlabs.org/patch/806173/

btw, you can add for these two:

Reviewed-by: Rob Clark <robdclark at gmail.com>

> Please, merge these.
>
> I am aware that we need to convert the protocols list to a linked list
> and will do so in a later patch.
>
> Please, also merge this patch that definitively does not interfere with
> Rob's work:
>
> efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST
> https://patchwork.ozlabs.org/patch/816412/
>
> Best regards
>
> Heinrich
>
>>>
>>>> Please, add the missing check that the event pointer is valid.
>>>> The EFI code checks other arguments rigorously so we should do the same
>>>> for pointers. It would be very hard to debug a problem in an EFI
>>>> application otherwise.
>>>
>>> I'm a bit undecided on this, since we have other places where there is
>>> no good way to check the validity of a pointer.  (For example file or
>>> disk objects.)  I was thinking about perhaps implementing a
>>> compile-time optional feature using a hashtable to map objects to type
>>> so we can add in some type checking, at the expense of extra runtime
>>> overhead.  Probably not something you'd want to ship enabled, but it
>>> would be useful for debugging.
>>
>> Feel free to implement just the boilerplate for it with a function that
>> always returns true:
>>
>> static int efi_ptr_valid(void *foo)
>> {
>>     return 1;
>> }
>>
>> which we can then later on improve to do actual checking if we care. The
>> least we can do is probably to check for alignment problems.
>>
>>
>> Alex
>>
>