summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * | test: dm: Add tests for regmap managed API and regmap fieldsJean-Jacques Hiblot2020-09-302-0/+211
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tests rely on a dummy driver to allocate and initialize the regmaps and the regmap fields using the managed API. The first test checks if the regmap config fields like width, reg_offset_shift, range specifiers, etc work. The second test checks if regmap fields behave properly (mask and shift are ok) by peeking into the regmap. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | test/py: allow multi-digit index in in_tree()Pratyush Yadav2020-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When more nodes are added for a uclass the index might go into two or more digits. This means that there are less spaces printed because they are used up by the extra digits. Update the regular expression to allow variable-length spacing between the class name and and index. This was discovered when adding a simple_bus node in test.dts made test_bind_unbind_with_uclass() fail because the index went up to 10. Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
| * | regmap: Add support for regmap fieldsJean-Jacques Hiblot2020-09-302-0/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | A regmap field is an abstraction available in Linux. It provides to access bitfields in a regmap without having to worry about shifts and masks. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
| * | regmap: Allow devices to specify regmap range start and size in configPratyush Yadav2020-09-302-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some devices need to calculate the regmap base address at runtime. This makes it impossible to use device tree to get the regmap base. Instead, allow devices to specify it in the regmap config. This will create a regmap with a single range that corresponds to the start and size given by the driver. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | regmap: Add regmap_init_mem_range()Pratyush Yadav2020-09-302-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now, the base of a regmap can only be obtained from the device tree. This makes it impossible for devices which calculate the base at runtime to use a regmap. An example of such a device is the Cadence Sierra PHY. Allow creating a regmap with one range whose start and size can be specified by the driver based on calculations at runtime. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | regmap: Allow left shifting register offset before accessPratyush Yadav2020-09-302-1/+11
| | | | | | | | | | | | | | | | | | | | | Drivers can configure it to adjust the final read/write location. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | regmap: Allow specifying read/write widthPratyush Yadav2020-09-302-19/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now, regmap_read() and regmap_write() read/write a 32-bit value only. To write other lengths, regmap_raw_read() and regmap_raw_write() need to be used. This means that any driver ported from Linux that relies on regmap_{read,write}() to know the size already has to be updated at each callsite. This makes the port harder to maintain. So, allow specifying the read/write width to make it easier to port the drivers, since now the only change needed is when initializing the regmap. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | regmap: zero out the regmap on allocationPratyush Yadav2020-09-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some fields will be introduced in the regmap structure that should be set to 0 by default. So, once we allocate a regmap, make sure it is zeroed out to avoid unexpected defaults for those values. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | regmap: Add devm_regmap_init()Jean-Jacques Hiblot2020-09-302-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of new linux drivers are using managed-API to allocate resources. To ease porting drivers from linux to U-Boot, introduce devm_regmap_init() as a managed API to get a regmap from the device tree. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
| * | test: gpio: Add tests for the managed APIJean-Jacques Hiblot2020-09-304-4/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a test to verify that GPIOs can be acquired/released using the managed API. Also check that the GPIOs are released when the consumer device is removed. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
| * | drivers: gpio: Add a managed API to get a GPIO from the device-treeJean-Jacques Hiblot2020-09-302-0/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add managed functions to get a gpio from the devce-tree, based on a property name (minus the '-gpios' suffix) and optionally an index. When the device is unbound, the GPIO is automatically released and the data structure is freed. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
| * | test: reset: Add tests for the managed APIJean-Jacques Hiblot2020-09-304-6/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | The tests are basically the same as for the regular API. Except that the reset are initialized using the managed API, and no freed manually. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
| * | drivers: reset: Add a managed API to get reset controllers from the DTJean-Jacques Hiblot2020-09-302-5/+248
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | Add managed functions to get a reset_ctl from the device-tree, based on a name or an index. Also add a managed functions to get a reset_ctl_bulk (array of reset_ctl) from the device-tree. When the device is unbound, the reset controllers are automatically released and the data structure is freed. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
* | Merge branch 'next' of https://gitlab.denx.de/u-boot/custodians/u-boot-riscv ↵Tom Rini2020-09-3033-211/+357
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | into next - Disable CMD_IRQ for RISC-V. - Update sipeed/maix doc - Obtain reg of SiFive RAM via dev_read_addr_index() instead of regmap API. - Cleans up RISC-V timer drivers and converts them to DM. - Correctly handle IPIs already pending upon prior stage bootloader (on the K210)
| * | riscv: Add some comments to start.SSean Anderson2020-09-301-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds comments regarding the ordering and purpose of certain instructions as I understand them. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
| * | riscv: Ensure gp is NULL or points to valid dataSean Anderson2020-09-302-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This ensures constructs like `if (gd & gd->...) { ... }` work when accessing the global data pointer. Without this change, it was possible for a very early trap to cause _exit_trap to directly or indirectly (through printf) to read arbitrary memory. This could cause a second trap, preventing show_regs from being printed. printf (and specifically puts) uses gd to determine what function to print with. These functions in turn use gd to find the serial device, etc. However, before accessing gd, puts first checks to see if it is non-NULL. This indicates an existing (perhaps undocumented) assumption that either gd is NULL or it is completely valid. Before this patch, gd either points to unexpected data (because it retains the value it did from the prior-stage) or points to uninitialized data (because it has not yet been initialized by board_init_f_init_reserve) until the hart has acquired available_harts_lock. This can cause two problems, depending on the value of gd->flags. If GD_FLG_SERIAL_READY is unset, then some garbage data will be printed to stdout, but there will not be a second trap. However, if GD_FLG_SERIAL_READY is set, then puts will try to print with serial_puts, which will likely cause a second trap. After this patch, gd is zero up until either a hart has set it in wait_for_gd_init, or until it is set by arch_init_gd. This prevents its usage before its data is initialized because both handle_trap and puts ensure that gd is nonzero before using it. After gd has been set, it is OK to access it because its data has been cleared (and so flags is valid). XIP cannot use locks because flash is not writable. This leaves it vulnerable to the same class of bugs regarding already-pending IPIs as before this series. Fixing that would require finding another method of synchronization, which is outside the scope of this series. Fixes: 7c6ca03eae ("riscv: additional crash information") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
| * | riscv: Consolidate fences into AMOs for available_harts_lockSean Anderson2020-09-301-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | We can reduce the number of instructions needed to use available_harts_lock by using the aq and rl suffixes for AMOs. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
| * | riscv: Clear pending IPIs on initializationSean Anderson2020-09-301-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though we no longer call smp_function if an IPI was not sent by U-Boot, we still need to clear any IPIs which were pending from the execution environment. Otherwise, secondary harts will busy-wait in secondary_hart_loop, instead of relaxing. Along with the previous commit ("riscv: Use a valid bit to ignore already-pending IPIs"), this fixes SMP booting on the Kendryte K210. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
| * | riscv: Use a valid bit to ignore already-pending IPIsSean Anderson2020-09-302-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some IPIs may already be pending when U-Boot is started. This could be a problem if a secondary hart tries to handle an IPI before the boot hart has initialized the IPI device. To be specific, the Kendryte K210 ROM-based bootloader does not clear IPIs before passing control to U-Boot. Without this patch, the secondary hart jumps to address 0x0 as soon as it enters secondary_hart_loop, and then hangs in its trap handler. This commit introduces a valid bit so secondary harts know when and IPI originates from U-Boot, and it is safe to use the IPI API. The valid bit is initialized to 0 by board_init_f_init_reserve. Before this, secondary harts wait in wait_for_gd_init. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
| * | riscv: Match memory barriers between send_ipi_many and handle_ipiSean Anderson2020-09-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without a matching barrier on the write side, the barrier in handle_ipi does nothing. It was entirely possible for the boot hart to write to addr, arg0, and arg1 *after* sending the IPI, because there was no barrier on the sending side. Fixes: 90ae281437 ("riscv: add option to wait for ack from secondary harts in smp functions") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
| * | Revert "riscv: Clear pending interrupts before enabling IPIs"Sean Anderson2020-09-301-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clearing MIP.MSIP is not guaranteed to do anything by the spec. In addition, most existing RISC-V hardware does nothing when this bit is set. The following commits "riscv: Use a valid bit to ignore already-pending IPIs" and "riscv: Clear pending IPIs on initialization" should implement the original intent of the reverted commit in a more robust manner. This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
| * | riscv: Update SiFive device tree for new CLINT driverSean Anderson2020-09-302-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | We currently do this in a u-boot specific dts, but hopefully we can get these bindings added in Linux in the future. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Pragnesh Patel <pragnesh.patel@openfive.com> Reviewed-by: Bin Meng <bin.meng@windriver.com>
| * | riscv: Update Kendryte device tree for new CLINT driverSean Anderson2020-09-301-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The interrupt controller property is removed from the clint binding because the clint is not an interrupt-controller. That is, no other devices have an interrupt which is controlled by the clint. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com>
| * | riscv: clk: Add CLINT clock to kendryte clock driverSean Anderson2020-09-302-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Another "virtual" clock (in the sense that it isn't configurable). This could possibly be done as a clock in the device tree, but I think this is a bit cleaner. Signed-off-by: Sean Anderson <seanga2@gmail.com>
| * | riscv: Rework Sifive CLINT as UCLASS_TIMER driverSean Anderson2020-09-302-32/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts the clint driver from the riscv-specific interface to be a DM-based UCLASS_TIMER driver. In addition, the SiFive DDR driver previously implicitly depended on the CLINT to select REGMAP. Unlike Andes's PLMT/PLIC (which AFAIK never have anything pass it a dtb), the SiFive CLINT is part of the device tree passed in by qemu. This device tree doesn't have a clocks or clock-frequency property on clint, so we need to fall back on the timebase-frequency property. Perhaps in the future we can get a clock-frequency property added to the qemu dtb. Unlike with the Andes PLMT, the Sifive CLINT is also an IPI controller. RISCV_SYSCON_CLINT is retained for this purpose. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Pragnesh Patel <pragnesh.patel@openfive.com>
| * | riscv: Clean up initialization in Andes PLICSean Anderson2020-09-301-33/+25
| | | | | | | | | | | | | | | | | | | | | This merges the PLIC initialization code from two functions into one. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com>
| * | riscv: Rework Andes PLMT as a UCLASS_TIMER driverSean Anderson2020-09-304-32/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts the PLMT driver from the riscv-specific timer interface to be a DM-based UCLASS_TIMER driver. The clock-frequency/clocks properties are preferred over timebase-frequency for two reasons. First, properties which affect a device should be located near its binding in the device tree. Using timebase-frequency only really makes sense when the cpu itself is the timer device. This is the case when we read the time from a CSR, but not when there is a separate device. Second, it lets the device use the clock subsystem which adds flexibility. If the device is configured for a different clock speed, the timer can adjust itself. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com>
| * | timer: Add a test for timer_timebase_fallbackSean Anderson2020-09-305-10/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To test this function, sandbox CPU must set cpu_platdata.timebase_freq on bind. It also needs to expose a method to set the current cpu. I also make some most members of cpu_sandbox_ops static. On the timer side, the device tree property sandbox,timebase-frequency-fallback controls whether sandbox_timer_probe falls back to time_timebase_fallback or to SANDBOX_TIMER_RATE. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | timer: Add helper for drivers using timebase fallbackSean Anderson2020-09-302-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function is designed to be used when a timer used to be initialized by the cpu (e.g. RISC-V timers), but now is initialized by dm_timer_init. In such a case, the timer may prefer to use the clocks and clock-frequency properties, but should be able to fall back on using the cpu's timebase-frequency. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
| * | riscv: Rework riscv timer driver to only support S-modeSean Anderson2020-09-308-71/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The riscv-timer driver currently serves as a shim for several riscv timer drivers. This is not too desirable because it bypasses the usual timer selection via the driver model. There is no easy way to specify an alternate timing driver, or have the tick rate depend on the cpu's configured frequency. The timer drivers also do not have device structs, and so have to rely on storing parameters in gd_t. Lastly, there is no initialization call, so driver init is done in the same function which reads the time. This can result in confusing error messages. To a user, it looks like the driver failed when trying to read the time, whereas it may have failed while initializing. This patch removes the shim functionality from the riscv-timer driver, and has it instead implement the former rdtime.c timer driver. This is because existing u-boot users who pass in a device tree (e.g. qemu) do not create a timer device for S-mode u-boot. The existing behavior of creating the riscv-timer device in the riscv cpu driver must be kept. The actual reading of the CSRs has been redone in the style of Linux's get_cycles64. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
| * | ram: sifive: Remove regmap dependencyBin Meng2020-09-301-9/+3
| | | | | | | | | | | | | | | | | | | | | The usage of regmap API in the SiFive RAM driver is not correct. The reg address should be obtained via dev_read_addr_index() API. Signed-off-by: Bin Meng <bin.meng@windriver.com>
| * | ram: sifive: Check return value on clk_enable()Bin Meng2020-09-301-0/+5
| | | | | | | | | | | | | | | | | | | | | The return value should be checked otherwise it's useless to assign the return value to 'ret'. Signed-off-by: Bin Meng <bin.meng@windriver.com>
| * | doc/sipeed/maix: describe RESET and BOOT buttonHeinrich Schuchardt2020-09-301-2/+6
| | | | | | | | | | | | | | | | | | | | | In the boot flow description add the RESET and BOOT button as well as the function of the DTR and RTS lines of the serial interface. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| * | doc: correct kflash settings for Maix One DockHeinrich Schuchardt2020-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The correct kflash parameter value for the Maix One Dock is "dan". See: https://github.com/sipeed/platform-kendryte210/blob/master/boards/sipeed-maix-one-dock.json#L22 Fixes: 137dc153fda9 ("doc: riscv: Update documentation for Sipeed MAIX boards") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| * | cmd: irq: disable CMD_IRQ for riscv archPragnesh Patel2020-09-301-1/+1
| |/ | | | | | | | | | | | | | | | | For RISC-V arch, no need for CMD_IRQ so disable the same. Signed-off-by: Pragnesh Patel <pragnesh.patel@sifive.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Bin Meng <bin.meng@windriver.com>
* | Merge branch '2020-09-29-dev_xxx-print-improvement' into nextTom Rini2020-09-3048-407/+486
|\ \ | |/ |/| | | | | - Improve our dev_xxx(..) wrappers to be generally used and available rather than discarded at link/compile time.
| * dm: Print device name in dev_xxx like LinuxSean Anderson2020-09-301-28/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adorns messages generated by dev_xxx with the device and driver names. It also redirects dev_xxx to log when it is available. The names of these functions very roughly take inspiration from Linux, but there is no deeper correlation. Both struct udevice and struct device are supported when logging, though logging with struct device is no better than using log_xxx. The latter is supported because of the large amount of existing code which logs with struct device. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * dm: Use symbolic constants for log levels in dev_xxxSean Anderson2020-09-301-10/+11
| | | | | | | | | | | | | | | | This substitutes literal log levels with their symbolic constants. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * video: stm32: Fix not calling dev_xxx with a deviceSean Anderson2020-09-301-10/+14
| | | | | | | | | | | | | | | | | | There is no member `dev` in dw_mipi_dsi, but there is one in mipi_dsi_host, so use that. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * usb: musb-new: sunxi: Fix not calling dev_err with a deviceSean Anderson2020-09-301-4/+5
| | | | | | | | | | | | | | | | This driver does not use DM, so we need to use a struct device instead of a struct udevice. Not ideal, but it'll have to do for now. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * usb: dwc3: Don't include asm-generic/io.hSean Anderson2020-09-301-1/+0
| | | | | | | | | | | | | | | | This can conflict with asm/io.h on some archs, and it isn't needed to build dwc3-generic.c Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * usb: dwc3: ti: Fix not calling dev_err with a deviceSean Anderson2020-09-301-2/+2
| | | | | | | | | | | | | | This driver does not use DM, so use log_xxx instead. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * usb: dwc3: Fix not calling dev_xxx with a deviceSean Anderson2020-09-303-18/+21
| | | | | | | | | | | | | | | | This logs with the device from struct dwc3. Some files also need to include dm.h so fields in udevice can be accessed. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * usb: dwc2: Fix not calling dev_xxx with a deviceSean Anderson2020-09-301-16/+23
| | | | | | | | | | | | | | | | | | | | | | This adds a dev argument to some functions so dev_xxx always has a device to log with. In one instance we must use use a different log function when we are compiled without DM_USB. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * usb: cdns3: Fix not calling dev_xxx with a deviceSean Anderson2020-09-302-4/+4
| | | | | | | | | | | | | | ep0.c also need to include dm.h so dev_xxx can access udevice fields. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * sysreset: ti: Fix not calling dev_err with a deviceSean Anderson2020-09-301-2/+1
| | | | | | | | | | | | | | The rst variable doesn't exist. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * spi: zynqmp_gqspi: Fix not calling dev_err with a deviceSean Anderson2020-09-301-3/+3
| | | | | | | | | | | | | | | | Use `bus` instead of `dev`. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Michal Simek <michal.simek@xilinx.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * spi: sunxi: Fix not calling dev_err with a deviceSean Anderson2020-09-301-3/+3
| | | | | | | | | | | | | | Use `bus` and not `dev`. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * soc: qualcomm: Fix not calling dev_err with a deviceSean Anderson2020-09-301-1/+1
| | | | | | | | | | | | | | | | Remove the indirection. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
| * remoteproc: k3: Fix not calling dev_xxx with a deviceSean Anderson2020-09-301-4/+5
| | | | | | | | | | | | | | Pass a device to functions which log with one. Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com>