[PATCH v4 3/6] efi_loader: Add SPI I/O protocol support
Paul Barker
paul.barker at sancloud.com
Tue Oct 25 18:39:48 CEST 2022
Hi Ilias,
On 24/10/2022 12:54, Ilias Apalodimas wrote:
> Hi Paul,
>
> I think the series overall is in a good state, but we are trying to figure
> out if we can avoid defining SPI uuid's in the DT. OTOH U-Boot uses the DT
> for it's config so that might be okay...
What may make sense is to prefix the DT property names with `u-boot,`.
i.e. they'd become:
* u-boot,uefi-spi-vendor
* u-boot,uefi-spi-part-number
* u-boot,uefi-spi-io-guid
For the sandbox tests it makes sense to keep the configuration in
arch/sandbox/dts/test.dts. However for a real device such as the
SanCloud BBE it makes sense to keep the dts file in line with the Linux
kernel dts file and add the configuration to a new file
arch/arm/dts/am335x-sancloud-bbe-lite-u-boot.dtsi which will be picked
up by the build system. That keeps the configuration separate from the
upstream dts file and matches what we do for properties like
`u-boot,dm-spl`.
Does that sound like a good way forward?
>
> [...]
>
>> +{
>> + struct efi_spi_peripheral *peripheral = bus->peripheral_list;
>> +
>> + while (peripheral) {
>> + struct efi_spi_peripheral *next =
>> + peripheral->next_spi_peripheral;
>> + destroy_efi_spi_peripheral(peripheral);
>> + peripheral = next;
>> + }
>> + free(bus->friendly_name);
>> + free(bus);
>> +}
>> +
>> +static efi_status_t efi_spi_new_handle(const efi_guid_t *guid, void *proto)
>> +{
>> + efi_status_t status;
>> + efi_handle_t handle;
>> +
>> + status = efi_create_handle(&handle);
>> + if (status != EFI_SUCCESS) {
>> + printf("Failed to create EFI handle\n");
>> + goto fail_1;
>> + }
>> +
>> + status = efi_add_protocol(handle, guid, proto);
>
> Apologies for this it's my fault, but can you replace efi_add_protocol ->
> efi_install_multiple_protocol_interfaces?
> commit 05c4c9e21ae6 ("efi_loader: define internal implementations of install/uninstallmultiple")
> has some details on why. A bit annoying but the change is straightforward
I'll change this for v5.
>
>> + if (status != EFI_SUCCESS) {
>> + printf("Failed to add protocol\n");
>> + goto fail_2;
>> + }
>> +
>> + return EFI_SUCCESS;
>> +
>> +fail_2:
>> + efi_delete_handle(handle);
>
> Same here, just uninstall the protocol
As above.
>
>> +fail_1:
>> + return status;
>> +}
>> +
>> +static void
>> +efi_spi_init_part(struct efi_spi_part *part,
>> + struct spi_slave *target,
>> + efi_string_t vendor_utf16,
>> + efi_string_t part_number_utf16
>> +)
>> +{
>> + part->vendor = vendor_utf16;
>> + part->part_number = part_number_utf16;
>> + part->min_clock_hz = 0;
>> + part->max_clock_hz = target->max_hz;
>> + part->chip_select_polarity =
>> + (target->mode & SPI_CS_HIGH) ? true : false;
>> +}
>> +
>
>
> Thanks!
> /Ilias
Thanks,
--
Paul Barker
Principal Software Engineer
SanCloud Ltd
e: paul.barker at sancloud.com
w: https://sancloud.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA67255DFCCE62ECD.asc
Type: application/pgp-keys
Size: 6758 bytes
Desc: OpenPGP public key
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221025/58177c7b/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221025/58177c7b/attachment.sig>
More information about the U-Boot
mailing list