| Age | Commit message (Collapse) | Author |
|---|
|
The serial driver subsystem does not need any extra data, so it can use
`struct fdt_driver` directly. The generic fdt_serial_init() first
attempts to match the chosen stdout device, and upon failure matches the
first available serial device in the DT. It is a fatal error if no such
device is found. This matches the behavior of fdt_driver_init_one().
Signed-off-by: Samuel Holland <[email protected]>
Reviewed-by: Anup Patel <[email protected]>
|
|
Indicate that none of these functions modify the devicetree by
constifying the parameter type.
Signed-off-by: Samuel Holland <[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Reviewed-by: Anup Patel <[email protected]>
|
|
While it doesn't look like there are any current cases of using
uninitialized data, let's zero all the UART data members to be
safe. Zero may not actually be better than a random number in
some cases, so all structure members should still be validated
before use, but at least zero is usually easier to debug than
some random stack garbage...
Signed-off-by: Andrew Jones <[email protected]>
Reviewed-by: Anup Patel <[email protected]>
|
|
Instead of having console_putc() and console_getc() callbacks in
platform operations, it will be much simpler for console driver to
directly register these operations as device to the sbi_console
implementation.
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Xiang W <[email protected]>
|
|
We add simple serial framework which will select and use serial driver
based on details in FDT passed by previous booting stage.
Signed-off-by: Anup Patel <[email protected]>
Reviewed-by: Atish Patra <[email protected]>
|
