diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/api/linker_lists.rst | 59 | ||||
| -rw-r--r-- | doc/board/emulation/index.rst | 1 | ||||
| -rw-r--r-- | doc/board/emulation/qemu_capsule_update.rst | 210 | ||||
| -rw-r--r-- | doc/device-tree-bindings/video/syncoam,seps525.txt | 24 | ||||
| -rw-r--r-- | doc/driver-model/debugging.rst | 2 | ||||
| -rw-r--r-- | doc/driver-model/design.rst | 179 | ||||
| -rw-r--r-- | doc/driver-model/ethernet.rst | 12 | ||||
| -rw-r--r-- | doc/driver-model/of-plat.rst | 70 | ||||
| -rw-r--r-- | doc/driver-model/remoteproc-framework.rst | 4 | ||||
| -rw-r--r-- | doc/driver-model/spi-howto.rst | 36 | ||||
| -rw-r--r-- | doc/driver-model/usb-info.rst | 18 | ||||
| -rw-r--r-- | doc/imx/clk/ccf.txt | 2 |
12 files changed, 459 insertions, 158 deletions
diff --git a/doc/api/linker_lists.rst b/doc/api/linker_lists.rst index 72f514e0ac..7063fdc831 100644 --- a/doc/api/linker_lists.rst +++ b/doc/api/linker_lists.rst @@ -96,5 +96,64 @@ defined for the whole list and each sub-list: %u_boot_list_2_drivers_2_pci_3 %u_boot_list_2_drivers_3 +Alignment issues +---------------- + +The linker script uses alphabetic sorting to group the different linker +lists together. Each group has its own struct and potentially its own +alignment. But when the linker packs the structs together it cannot ensure +that a linker list starts on the expected alignment boundary. + +For example, if the first list has a struct size of 8 and we place 3 of +them in the image, that means that the next struct will start at offset +0x18 from the start of the linker_list section. If the next struct has +a size of 16 then it will start at an 8-byte aligned offset, but not a +16-byte aligned offset. + +With sandbox on x86_64, a reference to a linker list item using +ll_entry_get() can force alignment of that particular linker_list item, +if it is in the same file as the linker_list item is declared. + +Consider this example, where struct driver is 0x80 bytes:: + + ll_entry_declare(struct driver, fred, driver) + + ... + + void *p = ll_entry_get(struct driver, fred, driver) + +If these two lines of code are in the same file, then the entry is forced +to be aligned at the 'struct driver' alignment, which is 16 bytes. If the +second line of code is in a different file, then no action is taken, since +the compiler cannot update the alignment of the linker_list item. + +In the first case, an 8-byte 'fill' region is added:: + + .u_boot_list_2_driver_2_testbus_drv + 0x0000000000270018 0x80 test/built-in.o + 0x0000000000270018 _u_boot_list_2_driver_2_testbus_drv + .u_boot_list_2_driver_2_testfdt1_drv + 0x0000000000270098 0x80 test/built-in.o + 0x0000000000270098 _u_boot_list_2_driver_2_testfdt1_drv + *fill* 0x0000000000270118 0x8 + .u_boot_list_2_driver_2_testfdt_drv + 0x0000000000270120 0x80 test/built-in.o + 0x0000000000270120 _u_boot_list_2_driver_2_testfdt_drv + .u_boot_list_2_driver_2_testprobe_drv + 0x00000000002701a0 0x80 test/built-in.o + 0x00000000002701a0 _u_boot_list_2_driver_2_testprobe_drv + +With this, the linker_list no-longer works since items after testfdt1_drv +are not at the expected address. + +Ideally we would have a way to tell gcc not to align structs in this way. +It is not clear how we could do this, and in any case it would require us +to adjust every struct used by the linker_list feature. + +The simplest fix seems to be to force each separate linker_list to start +on the largest possible boundary that can be required by the compiler. This +is the purpose of CONFIG_LINKER_LIST_ALIGN + + .. kernel-doc:: include/linker_lists.h :internal: diff --git a/doc/board/emulation/index.rst b/doc/board/emulation/index.rst index 1adefee155..a09ead1c35 100644 --- a/doc/board/emulation/index.rst +++ b/doc/board/emulation/index.rst @@ -10,3 +10,4 @@ Emulation qemu-mips qemu-riscv qemu-x86 + qemu_capsule_update diff --git a/doc/board/emulation/qemu_capsule_update.rst b/doc/board/emulation/qemu_capsule_update.rst new file mode 100644 index 0000000000..9fec75f8f1 --- /dev/null +++ b/doc/board/emulation/qemu_capsule_update.rst @@ -0,0 +1,210 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2020, Linaro Limited + +Enabling UEFI Capsule Update feature +------------------------------------ + +Support has been added for the UEFI capsule update feature which +enables updating the U-Boot image using the UEFI firmware management +protocol (fmp). The capsules are not passed to the firmware through +the UpdateCapsule runtime service. Instead, capsule-on-disk +functionality is used for fetching the capsule from the EFI System +Partition (ESP) by placing the capsule file under the +\EFI\UpdateCapsule directory. + +Currently, support has been added on the QEMU ARM64 virt platform for +updating the U-Boot binary as a raw image when the platform is booted +in non-secure mode, i.e. with CONFIG_TFABOOT disabled. For this +configuration, the QEMU platform needs to be booted with +'secure=off'. The U-Boot binary placed on the first bank of the NOR +flash at offset 0x0. The U-Boot environment is placed on the second +NOR flash bank at offset 0x4000000. + +The capsule update feature is enabled with the following configuration +settings:: + + CONFIG_MTD=y + CONFIG_FLASH_CFI_MTD=y + CONFIG_CMD_MTDPARTS=y + CONFIG_CMD_DFU=y + CONFIG_DFU_MTD=y + CONFIG_PCI_INIT_R=y + CONFIG_EFI_CAPSULE_ON_DISK=y + CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y + CONFIG_EFI_CAPSULE_FIRMWARE=y + CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y + CONFIG_EFI_CAPSULE_FMP_HEADER=y + +In addition, the following config needs to be disabled(QEMU ARM specific):: + + CONFIG_TFABOOT + +The capsule file can be generated by using the GenerateCapsule.py +script in EDKII:: + + $ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \ + <capsule_file_name> --fw-version <val> --lsv <val> --guid \ + e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose --update-image-index \ + <val> --verbose <u-boot.bin> + +The above is a wrapper script(GenerateCapsule) which eventually calls +the actual GenerateCapsule.py script. + +As per the UEFI specification, the capsule file needs to be placed on +the EFI System Partition, under the \EFI\UpdateCapsule directory. The +EFI System Partition can be a virtio-blk-device. + +Before initiating the firmware update, the efi variables BootNext, +BootXXXX and OsIndications need to be set. The BootXXXX variable needs +to be pointing to the EFI System Partition which contains the capsule +file. The BootNext, BootXXXX and OsIndications variables can be set +using the following commands:: + + => efidebug boot add 0 Boot0000 virtio 0:1 <capsule_file_name> + => efidebug boot next 0 + => setenv -e -nv -bs -rt -v OsIndications =0x04 + => saveenv + +Finally, the capsule update can be initiated with the following +command:: + + => efidebug capsule disk-update + +The updated U-Boot image will be booted on subsequent boot. + +Enabling Capsule Authentication +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The UEFI specification defines a way of authenticating the capsule to +be updated by verifying the capsule signature. The capsule signature +is computed and prepended to the capsule payload at the time of +capsule generation. This signature is then verified by using the +public key stored as part of the X509 certificate. This certificate is +in the form of an efi signature list (esl) file, which is embedded as +part of the platform's device tree blob using the mkeficapsule +utility. + +On the QEMU virt platforms, the device-tree is generated on the fly +based on the devices configured. This device tree is then passed on to +the various software components booting on the platform, including +U-Boot. Therefore, on the QEMU virt platform, the signatute is +embedded on an overlay. This overlay is then applied at runtime to the +base platform device-tree. Steps needed for embedding the esl file in +the overlay are highlighted below. + +The capsule authentication feature can be enabled through the +following config, in addition to the configs listed above for capsule +update:: + + CONFIG_EFI_CAPSULE_AUTHENTICATE=y + +The public and private keys used for the signing process are generated +and used by the steps highlighted below:: + + 1. Install utility commands on your host + * OPENSSL + * efitools + + 2. Create signing keys and certificate files on your host + + $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=CRT/ \ + -keyout CRT.key -out CRT.crt -nodes -days 365 + $ cert-to-efi-sig-list CRT.crt CRT.esl + + $ openssl x509 -in CRT.crt -out CRT.cer -outform DER + $ openssl x509 -inform DER -in CRT.cer -outform PEM -out CRT.pub.pem + + $ openssl pkcs12 -export -out CRT.pfx -inkey CRT.key -in CRT.crt + $ openssl pkcs12 -in CRT.pfx -nodes -out CRT.pem + +The capsule file can be generated by using the GenerateCapsule.py +script in EDKII:: + + $ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \ + <capsule_file_name> --monotonic-count <val> --fw-version \ + <val> --lsv <val> --guid \ + e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose \ + --update-image-index <val> --signer-private-cert \ + /path/to/CRT.pem --trusted-public-cert \ + /path/to/CRT.pub.pem --other-public-cert /path/to/CRT.pub.pem \ + <u-boot.bin> + +Place the capsule generated in the above step on the EFI System +Partition under the EFI/UpdateCapsule directory + +For embedding the public key certificate, the following steps need to +be followed:: + + 1. Generate a skeleton overlay dts file, with a single fragment + node and an empty __overlay__ node + + A typical skeleton overlay file will look like this + + /dts-v1/; + /plugin/; + + / { + fragment@0 { + target-path = "/"; + __overlay__ { + }; + }; + }; + + + 2. Convert the dts to a corresponding dtb with the following + command + ./scripts/dtc/dtc -@ -I dts -O dtb -o <ov_dtb_file_name> \ + <dts_file> + + 3. Run the dtb file generated above through the mkeficapsule tool + in U-Boot + ./tools/mkeficapsule -O <pub_key.esl> -D <ov_dtb> + +Running the above command results in the creation of a 'signature' +node in the dtb, under which the public key is stored as a +'capsule-key' property. The '-O' option is to be used since the +public key certificate(esl) file is being embedded in an overlay. + +The dtb file embedded with the certificate is now to be placed on an +EFI System Partition. This would then be loaded and "merged" with the +base platform flattened device-tree(dtb) at runtime. + +Build U-Boot with the following steps(QEMU ARM64):: + + $ make qemu_arm64_defconfig + $ make menuconfig + Disable CONFIG_TFABOOT + Enable CONFIG_EFI_CAPSULE_AUTHENTICATE + Enable all configs needed for capsule update(listed above) + $ make all + +Boot the platform and perform the following steps on the U-Boot +command line:: + + 1. Enable capsule authentication by setting the following env + variable + + => setenv capsule_authentication_enabled 1 + => saveenv + + 2. Load the overlay dtb to memory and merge it with the base fdt + + => fatload virtio 0:1 <$fdtovaddr> EFI/<ov_dtb_file> + => fdt addr $fdtcontroladdr + => fdt resize <size_of_ov_dtb_file> + => fdt apply <$fdtovaddr> + + 3. Set the following environment and UEFI boot variables + + => setenv -e -nv -bs -rt -v OsIndications =0x04 + => efidebug boot add 0 Boot0000 virtio 0:1 <capsule_file_name> + => efidebug boot next 0 + => saveenv + + 4. Finally, the capsule update can be initiated with the following + command + + => efidebug capsule disk-update + +On subsequent reboot, the platform should boot the updated U-Boot binary. diff --git a/doc/device-tree-bindings/video/syncoam,seps525.txt b/doc/device-tree-bindings/video/syncoam,seps525.txt new file mode 100644 index 0000000000..e1e0db9d71 --- /dev/null +++ b/doc/device-tree-bindings/video/syncoam,seps525.txt @@ -0,0 +1,24 @@ +spi based seps525 framebuffer display driver + +Driver for seps525 display controller (in spi mode), This binding supports selection +of spi chipselect, spi max frequency, gpio to drive dc and reset pin of seps525 +controller and spi transaction bit length. + +Required properties: +- compatible: "syncoam,seps525" +- reg: Specifies the chip-select the seps525 is connected to on the spi bus +- reset-gpios: gpio connected to reset pin of seps525 controller. +- dc-gpios: gpio connected to dc pin of seps525 controller: +- buswidth: bitlength of each spi transaction + +Example: + displayspi@0 { + compatible = "syncoam,seps525"; + reg = <0>; + spi-max-frequency = <10000000>; + spi-cpol; + spi-cpha; + buswidth = <8>; + reset-gpios = <&gpio 0x1c GPIO_ACTIVE_LOW>; + dc-gpios = <&gpio 0x1b GPIO_ACTIVE_HIGH>; + }; diff --git a/doc/driver-model/debugging.rst b/doc/driver-model/debugging.rst index c59bf6763b..bbb2794340 100644 --- a/doc/driver-model/debugging.rst +++ b/doc/driver-model/debugging.rst @@ -46,7 +46,7 @@ to see errors. Common ones are: going. - -EINVAL which typically indicates that something was missing or wrong in the device tree node. Check that everything is correct and look at the - ofdata_to_platdata() method in the driver. + of_to_plat() method in the driver. If there is no error, you should check if the device is actually bound. Call dm_dump_all() just before you locate the device to make sure it exists. diff --git a/doc/driver-model/design.rst b/doc/driver-model/design.rst index 96525b6ccc..ffed7d5f79 100644 --- a/doc/driver-model/design.rst +++ b/doc/driver-model/design.rst @@ -59,7 +59,7 @@ uclass: The demo class is pretty simple, but not trivial. The intention is that it can be used for testing, so it will implement all driver model features and provide good code coverage of them. It does have multiple drivers, it -handles parameter data and platdata (data which tells the driver how +handles parameter data and plat (data which tells the driver how to operate on a particular platform) and it uses private driver data. To try it, see the example session below:: @@ -282,7 +282,7 @@ in drivers/demo/demo-simple.c: static int simple_hello(struct udevice *dev, int ch) { - const struct dm_demo_pdata *pdata = dev_get_platdata(dev); + const struct dm_demo_pdata *pdata = dev_get_plat(dev); printf("Hello from %08x: %s %d\n", map_to_sysmem(dev), pdata->colour, pdata->sides); @@ -333,11 +333,11 @@ Briefly, they are: * bind - make the driver model aware of a device (bind it to its driver) * unbind - make the driver model forget the device - * ofdata_to_platdata - convert device tree data to platdata - see later + * of_to_plat - convert device tree data to plat - see later * probe - make a device ready for use * remove - remove a device so it cannot be used until probed again -The sequence to get a device to work is bind, ofdata_to_platdata (if using +The sequence to get a device to work is bind, of_to_plat (if using device tree) and probe. @@ -396,7 +396,7 @@ The data can be interpreted by the drivers however they like - it is basically a communication scheme between the board-specific code and the generic drivers, which are intended to work on any board. -Drivers can access their data via dev->info->platdata. Here is +Drivers can access their data via dev->info->plat. Here is the declaration for the platform data, which would normally appear in the board file. @@ -410,7 +410,7 @@ in the board file. static const struct driver_info info[] = { { .name = "demo_shape_drv", - .platdata = &red_square, + .plat = &red_square, }, }; @@ -420,9 +420,9 @@ in the board file. Device Tree ----------- -While platdata is useful, a more flexible way of providing device data is +While plat is useful, a more flexible way of providing device data is by using device tree. In U-Boot you should use this where possible. Avoid -sending patches which make use of the U_BOOT_DEVICE() macro unless strictly +sending patches which make use of the U_BOOT_DRVINFO() macro unless strictly necessary. With device tree we replace the above code with the following device tree @@ -436,7 +436,7 @@ fragment: sides = <4>; }; -This means that instead of having lots of U_BOOT_DEVICE() declarations in +This means that instead of having lots of U_BOOT_DRVINFO() declarations in the board file, we put these in the device tree. This approach allows a lot more generality, since the same board file can support many types of boards (e,g. with the same SoC) just by using different device trees. An added @@ -448,24 +448,24 @@ The easiest way to make this work it to add a few members to the driver: .. code-block:: c - .platdata_auto_alloc_size = sizeof(struct dm_test_pdata), - .ofdata_to_platdata = testfdt_ofdata_to_platdata, + .plat_auto = sizeof(struct dm_test_pdata), + .of_to_plat = testfdt_of_to_plat, -The 'auto_alloc' feature allowed space for the platdata to be allocated -and zeroed before the driver's ofdata_to_platdata() method is called. The -ofdata_to_platdata() method, which the driver write supplies, should parse -the device tree node for this device and place it in dev->platdata. Thus +The 'auto' feature allowed space for the plat to be allocated +and zeroed before the driver's of_to_plat() method is called. The +of_to_plat() method, which the driver write supplies, should parse +the device tree node for this device and place it in dev->plat. Thus when the probe method is called later (to set up the device ready for use) the platform data will be present. -Note that both methods are optional. If you provide an ofdata_to_platdata +Note that both methods are optional. If you provide an of_to_plat method then it will be called first (during activation). If you provide a probe method it will be called next. See Driver Lifecycle below for more details. -If you don't want to have the platdata automatically allocated then you -can leave out platdata_auto_alloc_size. In this case you can use malloc -in your ofdata_to_platdata (or probe) method to allocate the required memory, +If you don't want to have the plat automatically allocated then you +can leave out plat_auto. In this case you can use malloc +in your of_to_plat (or probe) method to allocate the required memory, and you should free it in the remove method. The driver model tree is intended to mirror that of the device tree. The @@ -515,11 +515,23 @@ cases. While it might be tempting to automatically renumber the devices where there are gaps in the sequence, this can lead to confusion and is not the way that U-Boot works. -Each device can request a sequence number. If none is required then the -device will be automatically allocated the next available sequence number. +Where a device gets its sequence number is controlled by the DM_SEQ_ALIAS +Kconfig option, which can have a different value in U-Boot proper and SPL. +If this option is not set, aliases are ignored. -To specify the sequence number in the device tree an alias is typically -used. Make sure that the uclass has the DM_UC_FLAG_SEQ_ALIAS flag set. +Even if CONFIG_DM_SEQ_ALIAS is enabled, the uclass must still have the +DM_UC_FLAG_SEQ_ALIAS flag set, for its devices to be sequenced by aliases. + +With those options set, devices with an alias (e.g. "serial2") will get that +sequence number (e.g. 2). Other devices get the next available number after all +aliases and all existing numbers. This means that if there is just a single +alias "serial2", unaliased serial devices will be assigned 3 or more, with 0 and +1 being unused. + +If CONFIG_DM_SEQ_ALIAS or DM_UC_FLAG_SEQ_ALIAS are not set, all devices will get +sequence numbers in a simple ordering starting from 0. To find the next number +to allocate, driver model scans through to find the maximum existing number, +then uses the next one. It does not attempt to fill in gaps. .. code-block:: none @@ -546,12 +558,18 @@ More commonly you can use node references, which expand to the full path: The alias resolves to the same string in this case, but this version is easier to read. -Device sequence numbers are resolved when a device is probed. Before then -the sequence number is only a request which may or may not be honoured, -depending on what other devices have been probed. However the numbering is -entirely under the control of the board author so a conflict is generally -an error. +Device sequence numbers are resolved when a device is bound and the number does +not change for the life of the device. + +There are some situations where the uclass must allocate sequence numbers, +since a strictly increase sequence (with devicetree nodes bound first) is not +suitable. An example of this is the PCI bus. In this case, you can set the +uclass DM_UC_FLAG_NO_AUTO_SEQ flag. With this flag set, only devices with an +alias will be assigned a number by driver model. The rest is left to the uclass +to sort out, e.g. when enumerating the bus. +Note that changing the sequence number for a device (e.g. in a driver) is not +permitted. If it is felt to be necessary, ask on the mailing list. Bus Drivers ----------- @@ -587,9 +605,9 @@ Each of the devices is connected to a different address on the USB bus. The bus device wants to store this address and some other information such as the bus speed for each device. -To achieve this, the bus device can use dev->parent_platdata in each of its +To achieve this, the bus device can use dev->parent_plat in each of its three children. This can be auto-allocated if the bus driver (or bus uclass) -has a non-zero value for per_child_platdata_auto_alloc_size. If not, then +has a non-zero value for per_child_plat_auto. If not, then the bus device or uclass can allocate the space itself before the child device is probed. @@ -647,32 +665,36 @@ Bind stage U-Boot discovers devices using one of these two methods: -- Scan the U_BOOT_DEVICE() definitions. U-Boot looks up the name specified +- Scan the U_BOOT_DRVINFO() definitions. U-Boot looks up the name specified by each, to find the appropriate U_BOOT_DRIVER() definition. In this case, - there is no path by which driver_data may be provided, but the U_BOOT_DEVICE() - may provide platdata. + there is no path by which driver_data may be provided, but the U_BOOT_DRVINFO() + may provide plat. - Scan through the device tree definitions. U-Boot looks at top-level nodes in the the device tree. It looks at the compatible string in each node and uses the of_match table of the U_BOOT_DRIVER() structure to find the right driver for each node. In this case, the of_match table may provide a - driver_data value, but platdata cannot be provided until later. + driver_data value, but plat cannot be provided until later. For each device that is discovered, U-Boot then calls device_bind() to create a new device, initializes various core fields of the device object such as name, uclass & driver, initializes any optional fields of the device object that are -applicable such as of_offset, driver_data & platdata, and finally calls the +applicable such as of_offset, driver_data & plat, and finally calls the driver's bind() method if one is defined. At this point all the devices are known, and bound to their drivers. There is a 'struct udevice' allocated for all devices. However, nothing has been activated (except for the root device). Each bound device that was created -from a U_BOOT_DEVICE() declaration will hold the platdata pointer specified +from a U_BOOT_DRVINFO() declaration will hold the plat pointer specified in that declaration. For a bound device created from the device tree, -platdata will be NULL, but of_offset will be the offset of the device tree +plat will be NULL, but of_offset will be the offset of the device tree node that caused the device to be created. The uclass is set correctly for the device. +The device's sequence number is assigned, either the requested one or the next +available one (after all aliases are processed) if nothing particular is +requested. + The device's bind() method is permitted to perform simple actions, but should not scan the device tree node, not initialise hardware, nor set up structures or allocate memory. All of these tasks should be left for @@ -690,52 +712,52 @@ Most devices have data in the device tree which they can read to find out the base address of hardware registers and parameters relating to driver operation. This is called 'ofdata' (Open-Firmware data). -The device's_ofdata_to_platdata() implemnents allocation and reading of -platdata. A parent's ofdata is always read before a child. +The device's of_to_plat() implemnents allocation and reading of +plat. A parent's ofdata is always read before a child. The steps are: - 1. If priv_auto_alloc_size is non-zero, then the device-private space + 1. If priv_auto is non-zero, then the device-private space is allocated for the device and zeroed. It will be accessible as dev->priv. The driver can put anything it likes in there, but should use it for run-time information, not platform data (which should be static and known before the device is probed). - 2. If platdata_auto_alloc_size is non-zero, then the platform data space + 2. If plat_auto is non-zero, then the platform data space is allocated. This is only useful for device tree operation, since otherwise you would have to specific the platform data in the - U_BOOT_DEVICE() declaration. The space is allocated for the device and - zeroed. It will be accessible as dev->platdata. + U_BOOT_DRVINFO() declaration. The space is allocated for the device and + zeroed. It will be accessible as dev->plat. - 3. If the device's uclass specifies a non-zero per_device_auto_alloc_size, + 3. If the device's uclass specifies a non-zero per_device_auto, then this space is allocated and zeroed also. It is allocated for and stored in the device, but it is uclass data. owned by the uclass driver. It is possible for the device to access it. - 4. If the device's immediate parent specifies a per_child_auto_alloc_size + 4. If the device's immediate parent specifies a per_child_auto then this space is allocated. This is intended for use by the parent device to keep track of things related to the child. For example a USB flash stick attached to a USB host controller would likely use this space. The controller can hold information about the USB state of each of its children. - 5. If the driver provides an ofdata_to_platdata() method, then this is + 5. If the driver provides an of_to_plat() method, then this is called to convert the device tree data into platform data. This should do various calls like dev_read_u32(dev, ...) to access the node and store - the resulting information into dev->platdata. After this point, the device + the resulting information into dev->plat. After this point, the device works the same way whether it was bound using a device tree node or - U_BOOT_DEVICE() structure. In either case, the platform data is now stored - in the platdata structure. Typically you will use the - platdata_auto_alloc_size feature to specify the size of the platform data + U_BOOT_DRVINFO() structure. In either case, the platform data is now stored + in the plat structure. Typically you will use the + plat_auto feature to specify the size of the platform data structure, and U-Boot will automatically allocate and zero it for you before - entry to ofdata_to_platdata(). But if not, you can allocate it yourself in - ofdata_to_platdata(). Note that it is preferable to do all the device tree - decoding in ofdata_to_platdata() rather than in probe(). (Apart from the + entry to of_to_plat(). But if not, you can allocate it yourself in + of_to_plat(). Note that it is preferable to do all the device tree + decoding in of_to_plat() rather than in probe(). (Apart from the ugliness of mixing configuration and run-time data, one day it is possible that U-Boot will cache platform data for devices which are regularly de/activated). - 5. The device is marked 'platdata valid'. + 6. The device is marked 'plat valid'. Note that ofdata reading is always done (for a child and all its parents) before probing starts. Thus devices go through two distinct states when @@ -744,7 +766,7 @@ the device up. Having probing separate from ofdata-reading helps deal with of-platdata, where the probe() method is common to both DT/of-platdata operation, but the -ofdata_to_platdata() method is implemented differently. +of_to_plat() method is implemented differently. Another case has come up where this separate is useful. Generation of ACPI tables uses the of-platdata but does not want to probe the device. Probing @@ -755,18 +777,18 @@ even be possible to probe the device - e.g. an SD card which is not present will cause an error on probe, yet we still must tell Linux about the SD card connector in case it is used while Linux is running. -It is important that the ofdata_to_platdata() method does not actually probe +It is important that the of_to_plat() method does not actually probe the device itself. However there are cases where other devices must be probed -in the ofdata_to_platdata() method. An example is where a device requires a +in the of_to_plat() method. An example is where a device requires a GPIO for it to operate. To select a GPIO obviously requires that the GPIO device is probed. This is OK when used by common, core devices such as GPIO, clock, interrupts, reset and the like. If your device relies on its parent setting up a suitable address space, so that dev_read_addr() works correctly, then make sure that the parent device -has its setup code in ofdata_to_platdata(). If it has it in the probe method, +has its setup code in of_to_plat(). If it has it in the probe method, then you cannot call dev_read_addr() from the child device's -ofdata_to_platdata() method. Move it to probe() instead. Buses like PCI can +of_to_plat() method. Move it to probe() instead. Buses like PCI can fall afoul of this rule. Activation/probe @@ -780,28 +802,24 @@ as above and then following these steps (see device_probe()): This means (for example) that an I2C driver will require that its bus be activated. - 2. The device's sequence number is assigned, either the requested one - (assuming no conflicts) or the next available one if there is a conflict - or nothing particular is requested. - - 4. The device's probe() method is called. This should do anything that + 2. The device's probe() method is called. This should do anything that is required by the device to get it going. This could include checking that the hardware is actually present, setting up clocks for the hardware and setting up hardware registers to initial values. The code in probe() can access: - - platform data in dev->platdata (for configuration) + - platform data in dev->plat (for configuration) - private data in dev->priv (for run-time state) - uclass data in dev->uclass_priv (for things the uclass stores about this device) - Note: If you don't use priv_auto_alloc_size then you will need to + Note: If you don't use priv_auto then you will need to allocate the priv space here yourself. The same applies also to - platdata_auto_alloc_size. Remember to free them in the remove() method. + plat_auto. Remember to free them in the remove() method. - 5. The device is marked 'activated' + 3. The device is marked 'activated' - 10. The uclass's post_probe() method is called, if one exists. This may + 4. The uclass's post_probe() method is called, if one exists. This may cause the uclass to do some housekeeping to record the device as activated and 'known' by the uclass. @@ -837,27 +855,20 @@ remove it. This performs the probe steps in reverse: 4. The device memory is freed (platform data, private data, uclass data, parent data). - Note: Because the platform data for a U_BOOT_DEVICE() is defined with a + Note: Because the platform data for a U_BOOT_DRVINFO() is defined with a static pointer, it is not de-allocated during the remove() method. For a device instantiated using the device tree data, the platform data will be dynamically allocated, and thus needs to be deallocated during the remove() method, either: - - if the platdata_auto_alloc_size is non-zero, the deallocation + - if the plat_auto is non-zero, the deallocation happens automatically within the driver model core; or - - when platdata_auto_alloc_size is 0, both the allocation (in probe() - or preferably ofdata_to_platdata()) and the deallocation in remove() + - when plat_auto is 0, both the allocation (in probe() + or preferably of_to_plat()) and the deallocation in remove() are the responsibility of the driver author. - 5. The device sequence number is set to -1, meaning that it no longer - has an allocated sequence. If the device is later reactivated and that - sequence number is still free, it may well receive the name sequence - number again. But from this point, the sequence number previously used - by this device will no longer exist (think of SPI bus 2 being removed - and bus 2 is no longer available for use). - - 6. The device is marked inactive. Note that it is still bound, so the + 5. The device is marked inactive. Note that it is still bound, so the device structure itself is not freed at this point. Should the device be activated again, then the cycle starts again at step 2 above. @@ -890,14 +901,14 @@ original patches, but makes at least the following changes: the driver operations structure in the driver, rather than passing it to the driver bind function. - Rename some structures to make them more similar to Linux (struct udevice - instead of struct instance, struct platdata, etc.) + instead of struct instance, struct plat, etc.) - Change the name 'core' to 'uclass', meaning U-Boot class. It seems that this concept relates to a class of drivers (or a subsystem). We shouldn't use 'class' since it is a C++ reserved word, so U-Boot class (uclass) seems better than 'core'. - Remove 'struct driver_instance' and just use a single 'struct udevice'. This removes a level of indirection that doesn't seem necessary. -- Built in device tree support, to avoid the need for platdata +- Built in device tree support, to avoid the need for plat - Removed the concept of driver relocation, and just make it possible for the new driver (created after relocation) to access the old driver data. I feel that relocation is a very special case and will only apply to a few @@ -920,7 +931,7 @@ property can provide better control granularity on which device is bound before relocation. While with DM_FLAG_PRE_RELOC flag of the driver all devices with the same driver are bound, which requires allocation a large amount of memory. When device tree is not used, DM_FLAG_PRE_RELOC is the -only way for statically declared devices via U_BOOT_DEVICE() to be bound +only way for statically declared devices via U_BOOT_DRVINFO() to be bound prior to relocation. It is possible to limit this to specific relocation steps, by using diff --git a/doc/driver-model/ethernet.rst b/doc/driver-model/ethernet.rst index 1f5310daaa..cdbccca34d 100644 --- a/doc/driver-model/ethernet.rst +++ b/doc/driver-model/ethernet.rst @@ -25,17 +25,17 @@ the UCLASS_ETH .id field in the U-Boot driver struct: .name = "eth_ape", .id = UCLASS_ETH, .of_match = eth_ape_ids, - .ofdata_to_platdata = eth_ape_ofdata_to_platdata, + .of_to_plat = eth_ape_of_to_plat, .probe = eth_ape_probe, .ops = ð_ape_ops, - .priv_auto_alloc_size = sizeof(struct eth_ape_priv), - .platdata_auto_alloc_size = sizeof(struct eth_ape_pdata), + .priv_auto = sizeof(struct eth_ape_priv), + .plat_auto = sizeof(struct eth_ape_pdata), .flags = DM_FLAG_ALLOC_PRIV_DMA, }; struct eth_ape_priv contains runtime per-instance data, like buffers, pointers to current descriptors, current speed settings, pointers to PHY related data -(like struct mii_dev) and so on. Declaring its size in .priv_auto_alloc_size +(like struct mii_dev) and so on. Declaring its size in .priv_auto will let the driver framework allocate it at the right time. It can be retrieved using a dev_get_priv(dev) call. @@ -43,7 +43,7 @@ struct eth_ape_pdata contains static platform data, like the MMIO base address, a hardware variant, the MAC address. ``struct eth_pdata eth_pdata`` as the first member of this struct helps to avoid duplicated code. If you don't need any more platform data beside the standard member, -just use sizeof(struct eth_pdata) for the platdata_auto_alloc_size. +just use sizeof(struct eth_pdata) for the plat_auto. PCI devices add a line pointing to supported vendor/device ID pairs: @@ -96,7 +96,7 @@ operations. You often do things here such as resetting the MAC and/or PHY, and waiting for the link to autonegotiate. You should also take the opportunity to program the device's MAC address with the enetaddr member of the generic struct eth_pdata (which would be the first member of your -own platdata struct). This allows the rest of U-Boot to dynamically change +own plat struct). This allows the rest of U-Boot to dynamically change the MAC address and have the new settings be respected. The **send** function does what you think -- transmit the specified packet diff --git a/doc/driver-model/of-plat.rst b/doc/driver-model/of-plat.rst index 58481665ce..4ef2fe699a 100644 --- a/doc/driver-model/of-plat.rst +++ b/doc/driver-model/of-plat.rst @@ -21,7 +21,7 @@ SoCs require a 16KB SPL image which must include a full MMC stack. In this case the overhead of device tree access may be too great. It is possible to create platform data manually by defining C structures -for it, and reference that data in a U_BOOT_DEVICE() declaration. This +for it, and reference that data in a U_BOOT_DRVINFO() declaration. This bypasses the use of device tree completely, effectively creating a parallel configuration mechanism. But it is an available option for SPL. @@ -79,7 +79,7 @@ SPL/TPL and should be tested with: A new tool called 'dtoc' converts a device tree file either into a set of struct declarations, one for each compatible node, and a set of -U_BOOT_DEVICE() declarations along with the actual platform data for each +U_BOOT_DRVINFO() declarations along with the actual platform data for each device. As an example, consider this MMC node: .. code-block:: none @@ -155,47 +155,41 @@ and the following device declarations: .card_detect_delay = 0xc8, }; - U_BOOT_DEVICE(dwmmc_at_ff0c0000) = { + U_BOOT_DRVINFO(dwmmc_at_ff0c0000) = { .name = "rockchip_rk3288_dw_mshc", - .platdata = &dtv_dwmmc_at_ff0c0000, - .platdata_size = sizeof(dtv_dwmmc_at_ff0c0000), + .plat = &dtv_dwmmc_at_ff0c0000, + .plat_size = sizeof(dtv_dwmmc_at_ff0c0000), .parent_idx = -1, }; - void dm_populate_phandle_data(void) { - } - The device is then instantiated at run-time and the platform data can be accessed using: .. code-block:: c struct udevice *dev; - struct dtd_rockchip_rk3288_dw_mshc *plat = dev_get_platdata(dev); + struct dtd_rockchip_rk3288_dw_mshc *plat = dev_get_plat(dev); This avoids the code overhead of converting the device tree data to -platform data in the driver. The ofdata_to_platdata() method should +platform data in the driver. The of_to_plat() method should therefore do nothing in such a driver. Note that for the platform data to be matched with a driver, the 'name' -property of the U_BOOT_DEVICE() declaration has to match a driver declared +property of the U_BOOT_DRVINFO() declaration has to match a driver declared via U_BOOT_DRIVER(). This effectively means that a U_BOOT_DRIVER() with a 'name' corresponding to the devicetree 'compatible' string (after converting it to a valid name for C) is needed, so a dedicated driver is required for each 'compatible' string. -In order to make this a bit more flexible U_BOOT_DRIVER_ALIAS macro can be +In order to make this a bit more flexible DM_DRIVER_ALIAS macro can be used to declare an alias for a driver name, typically a 'compatible' string. This macro produces no code, but it is by dtoc tool. The parent_idx is the index of the parent driver_info structure within its -linker list (instantiated by the U_BOOT_DEVICE() macro). This is used to support -dev_get_parent(). The dm_populate_phandle_data() is included to allow for -fix-ups required by dtoc. It is not currently used. The values in 'clocks' are -the index of the driver_info for the target device followed by any phandle -arguments. This is used to support device_get_by_driver_info_idx(). +linker list (instantiated by the U_BOOT_DRVINFO() macro). This is used to support +dev_get_parent(). -During the build process dtoc parses both U_BOOT_DRIVER and U_BOOT_DRIVER_ALIAS +During the build process dtoc parses both U_BOOT_DRIVER and DM_DRIVER_ALIAS to build a list of valid driver names and driver aliases. If the 'compatible' string used for a device does not not match a valid driver name, it will be checked against the list of driver aliases in order to get the right driver @@ -222,7 +216,7 @@ all the limitations metioned in caveats above. Therefore it is recommended that the of-platdata structure should be used only in the probe() method of your driver. It cannot be used in the -ofdata_to_platdata() method since this is not called when platform data is +of_to_plat() method since this is not called when platform data is already present. @@ -232,9 +226,9 @@ How to structure your driver Drivers should always support device tree as an option. The of-platdata feature is intended as a add-on to existing drivers. -Your driver should convert the platdata struct in its probe() method. The +Your driver should convert the plat struct in its probe() method. The existing device tree decoding logic should be kept in the -ofdata_to_platdata() method and wrapped with #if. +of_to_plat() method and wrapped with #if. For example: @@ -242,7 +236,7 @@ For example: #include <dt-structs.h> - struct mmc_platdata { + struct mmc_plat { #if CONFIG_IS_ENABLED(OF_PLATDATA) /* Put this first since driver model will copy the data here */ struct dtd_mmc dtplat; @@ -254,11 +248,11 @@ For example: int fifo_depth; }; - static int mmc_ofdata_to_platdata(struct udevice *dev) + static int mmc_of_to_plat(struct udevice *dev) { #if !CONFIG_IS_ENABLED(OF_PLATDATA) /* Decode the device tree data */ - struct mmc_platdata *plat = dev_get_platdata(dev); + struct mmc_plat *plat = dev_get_plat(dev); const void *blob = gd->fdt_blob; int node = dev_of_offset(dev); @@ -270,7 +264,7 @@ For example: static int mmc_probe(struct udevice *dev) { - struct mmc_platdata *plat = dev_get_platdata(dev); + struct mmc_plat *plat = dev_get_plat(dev); #if CONFIG_IS_ENABLED(OF_PLATDATA) /* Decode the of-platdata from the C structures */ @@ -291,29 +285,29 @@ For example: .name = "mmc_drv", .id = UCLASS_MMC, .of_match = mmc_ids, - .ofdata_to_platdata = mmc_ofdata_to_platdata, + .of_to_plat = mmc_of_to_plat, .probe = mmc_probe, - .priv_auto_alloc_size = sizeof(struct mmc_priv), - .platdata_auto_alloc_size = sizeof(struct mmc_platdata), + .priv_auto = sizeof(struct mmc_priv), + .plat_auto = sizeof(struct mmc_plat), }; - U_BOOT_DRIVER_ALIAS(mmc_drv, vendor_mmc) /* matches compatible string */ + DM_DRIVER_ALIAS(mmc_drv, vendor_mmc) /* matches compatible string */ -Note that struct mmc_platdata is defined in the C file, not in a header. This +Note that struct mmc_plat is defined in the C file, not in a header. This is to avoid needing to include dt-structs.h in a header file. The idea is to keep the use of each of-platdata struct to the smallest possible code area. There is just one driver C file for each struct, that can convert from the of-platdata struct to the standard one used by the driver. -In the case where SPL_OF_PLATDATA is enabled, platdata_auto_alloc_size is +In the case where SPL_OF_PLATDATA is enabled, plat_auto is still used to allocate space for the platform data. This is different from the normal behaviour and is triggered by the use of of-platdata (strictly -speaking it is a non-zero platdata_size which triggers this). +speaking it is a non-zero plat_size which triggers this). The of-platdata struct contents is copied from the C structure data to the start of the newly allocated area. In the case where device tree is used, the platform data is allocated, and starts zeroed. In this case the -ofdata_to_platdata() method should still set up the platform data (and the +of_to_plat() method should still set up the platform data (and the of-platdata struct will not be present). SPL must use either of-platdata or device tree. Drivers cannot use both at @@ -336,10 +330,12 @@ Otherwise (such as in U-Boot proper) these structs are not available. This prevents them being used inadvertently. All usage must be bracketed with #if CONFIG_IS_ENABLED(OF_PLATDATA). -The dt-platdata.c file contains the device declarations and is is built in -spl/dt-platdata.c. It additionally contains the definition of -dm_populate_phandle_data() which is responsible of filling the phandle -information by adding references to U_BOOT_DEVICE by using DM_GET_DEVICE +The dt-plat.c file contains the device declarations and is is built in +spl/dt-plat.c. + +The dm_populate_phandle_data() function that was previous needed has now been +removed, since dtoc can address the drivers directly from dt-plat.c and does +not need to fix up things at runtime. The pylibfdt Python module is used to access the devicetree. diff --git a/doc/driver-model/remoteproc-framework.rst b/doc/driver-model/remoteproc-framework.rst index f21de0a10f..566495a21c 100644 --- a/doc/driver-model/remoteproc-framework.rst +++ b/doc/driver-model/remoteproc-framework.rst @@ -125,9 +125,9 @@ a simplified definition of a device is as follows: .driver_plat_data = &mydriver_data; }; - U_BOOT_DEVICE(proc_3_demo) = { + U_BOOT_DRVINFO(proc_3_demo) = { .name = "sandbox_test_proc", - .platdata = &proc_3_test, + .plat = &proc_3_test, }; There can be additional data that may be desired depending on the diff --git a/doc/driver-model/spi-howto.rst b/doc/driver-model/spi-howto.rst index 9631a5059d..97fbf750cb 100644 --- a/doc/driver-model/spi-howto.rst +++ b/doc/driver-model/spi-howto.rst @@ -69,7 +69,7 @@ Put this code at the bottom of your existing driver file: return NULL; } - static int exynos_spi_ofdata_to_platdata(struct udevice *dev) + static int exynos_spi_of_to_plat(struct udevice *dev) { return -ENODEV; } @@ -138,7 +138,7 @@ Put this code at the bottom of your existing driver file: .id = UCLASS_SPI, .of_match = exynos_spi_ids, .ops = &exynos_spi_ops, - .ofdata_to_platdata = exynos_spi_ofdata_to_platdata, + .of_to_plat = exynos_spi_of_to_plat, .probe = exynos_spi_probe, .remove = exynos_spi_remove, }; @@ -209,7 +209,7 @@ DM tells you. The name is not quite right. So in this case we would use: .. code-block:: c - struct exynos_spi_platdata { + struct exynos_spi_plat { enum periph_id periph_id; s32 frequency; /* Default clock frequency, -1 for none */ struct exynos_spi *regs; @@ -217,7 +217,7 @@ DM tells you. The name is not quite right. So in this case we would use: }; -Write ofdata_to_platdata() [for device tree only] +Write of_to_plat() [for device tree only] ------------------------------------------------- This method will convert information in the device tree node into a C @@ -231,7 +231,7 @@ tree, but we need to tell it the size: U_BOOT_DRIVER(spi_exynos) = { ... - .platdata_auto_alloc_size = sizeof(struct exynos_spi_platdata), + .plat_auto = sizeof(struct exynos_spi_plat), Here is a sample function. It gets a pointer to the platform data and @@ -239,9 +239,9 @@ fills in the fields from device tree. .. code-block:: c - static int exynos_spi_ofdata_to_platdata(struct udevice *bus) + static int exynos_spi_of_to_plat(struct udevice *bus) { - struct exynos_spi_platdata *plat = bus->platdata; + struct exynos_spi_plat *plat = bus->plat; const void *blob = gd->fdt_blob; int node = dev_of_offset(bus); @@ -270,20 +270,20 @@ fills in the fields from device tree. Add the platform data [non-device-tree only] -------------------------------------------- -Specify this data in a U_BOOT_DEVICE() declaration in your board file: +Specify this data in a U_BOOT_DRVINFO() declaration in your board file: .. code-block:: c - struct exynos_spi_platdata platdata_spi0 = { + struct exynos_spi_plat platdata_spi0 = { .periph_id = ... .frequency = ... .regs = ... .deactivate_delay_us = ... }; - U_BOOT_DEVICE(board_spi0) = { + U_BOOT_DRVINFO(board_spi0) = { .name = "exynos_spi", - .platdata = &platdata_spi0, + .plat = &platdata_spi0, }; You will unfortunately need to put the struct definition into a header file @@ -335,7 +335,7 @@ DM can auto-allocate this also: U_BOOT_DRIVER(spi_exynos) = { ... - .priv_auto_alloc_size = sizeof(struct exynos_spi_priv), + .priv_auto = sizeof(struct exynos_spi_priv), Note that this is created before the probe method is called, and destroyed @@ -357,7 +357,7 @@ what you can copy out to set things up. static int exynos_spi_probe(struct udevice *bus) { - struct exynos_spi_platdata *plat = dev_get_platdata(bus); + struct exynos_spi_plat *plat = dev_get_plat(bus); struct exynos_spi_priv *priv = dev_get_priv(bus); priv->regs = plat->regs; @@ -437,7 +437,7 @@ Here is an example for the speed part: static int exynos_spi_set_speed(struct udevice *bus, uint speed) { - struct exynos_spi_platdata *plat = bus->platdata; + struct exynos_spi_plat *plat = bus->plat; struct exynos_spi_priv *priv = dev_get_priv(bus); int ret; @@ -585,7 +585,7 @@ The new version looks like this: static void spi_cs_activate(struct udevice *dev) { struct udevice *bus = dev->parent; - struct exynos_spi_platdata *pdata = dev_get_platdata(bus); + struct exynos_spi_plat *pdata = dev_get_plat(bus); struct exynos_spi_priv *priv = dev_get_priv(bus); /* If it's too soon to do another transaction, wait */ @@ -621,7 +621,7 @@ needs, but this is the minimum. U_BOOT_DRIVER(exynos_spi) = { ... - .per_child_auto_alloc_size = sizeof(struct spi_slave), + .per_child_auto = sizeof(struct spi_slave), } @@ -657,8 +657,8 @@ A little note about SPI uclass features The SPI uclass keeps some information about each device 'dev' on the bus: - struct dm_spi_slave_platdata: - This is device_get_parent_platdata(dev). + struct dm_spi_slave_plat: + This is device_get_parent_plat(dev). This is where the chip select number is stored, along with the default bus speed and mode. It is automatically read from the device tree in spi_child_post_bind(). It must not diff --git a/doc/driver-model/usb-info.rst b/doc/driver-model/usb-info.rst index 1817df420f..24d1e81a6c 100644 --- a/doc/driver-model/usb-info.rst +++ b/doc/driver-model/usb-info.rst @@ -39,31 +39,31 @@ as drivers in the USB uclass. For example: .name = "ehci_tegra", .id = UCLASS_USB, .of_match = ehci_usb_ids, - .ofdata_to_platdata = ehci_usb_ofdata_to_platdata, + .of_to_plat = ehci_usb_of_to_plat, .probe = tegra_ehci_usb_probe, .remove = tegra_ehci_usb_remove, .ops = &ehci_usb_ops, - .platdata_auto_alloc_size = sizeof(struct usb_platdata), - .priv_auto_alloc_size = sizeof(struct fdt_usb), + .plat_auto = sizeof(struct usb_plat), + .priv_auto = sizeof(struct fdt_usb), .flags = DM_FLAG_ALLOC_PRIV_DMA, }; Here ehci_usb_ids is used to list the controllers that the driver supports. Each has its own data value. Controllers must be in the UCLASS_USB uclass. -The ofdata_to_platdata() method allows the controller driver to grab any +The of_to_plat() method allows the controller driver to grab any necessary settings from the device tree. The ops here are ehci_usb_ops. All EHCI drivers will use these same ops in most cases, since they are all EHCI-compatible. For EHCI there are also some special operations that can be overridden when calling ehci_register(). -The driver can use priv_auto_alloc_size to set the size of its private data. +The driver can use priv_auto to set the size of its private data. This can hold run-time information needed by the driver for operation. It exists when the device is probed (not when it is bound) and is removed when the driver is removed. -Note that usb_platdata is currently only used to deal with setting up a bus +Note that usb_plat is currently only used to deal with setting up a bus in USB device mode (OTG operation). It can be omitted if that is not supported. @@ -93,14 +93,14 @@ The following primary data structures are in use: handles that). Once the device is set up, you can find the device descriptor and current configuration descriptor in this structure. -- struct usb_platdata: +- struct usb_plat: This holds platform data for a controller. So far this is only used as a work-around for controllers which can act as USB devices in OTG mode, since the gadget framework does not use driver model. -- struct usb_dev_platdata: +- struct usb_dev_plat: This holds platform data for a device. You can access it for a - device 'dev' with dev_get_parent_platdata(dev). It holds the device + device 'dev' with dev_get_parent_plat(dev). It holds the device address and speed - anything that can be determined before the device driver is actually set up. When probing the bus this structure is used to provide essential information to the device driver. diff --git a/doc/imx/clk/ccf.txt b/doc/imx/clk/ccf.txt index e40ac360e8..f47ca8832d 100644 --- a/doc/imx/clk/ccf.txt +++ b/doc/imx/clk/ccf.txt @@ -37,7 +37,7 @@ Design decisions: modify clk-uclass.c file and add there struct uc_clk_priv, which would have clock related members (like pointer to clk). As of this writing there is no such need, so to avoid extra allocations (as it can be auto allocated by - setting .per_device_auto_alloc_size = sizeof(struct uc_clk_priv)) the + setting .per_device_auto = sizeof(struct uc_clk_priv)) the uclass_priv stores the pointer to struct clk. * Non-CCF clocks do not have a pointer to a clock in clk->dev->priv. In the case |