Nobody is using stdio_deregister(), remove for good.
Note, even its parameters are not consistent with stdio_register().
So, if anyone want to introduce this again, better with some consistency.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
These prevent the use of IS_ENABLED() and are unnecessary. Drop them and
fix a few code-style nits nearby.
Signed-off-by: Simon Glass <sjg@chromium.org>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
With tighter build flags the fact that <stdio_dev.h> doesn't have a
reference back to MAX_NAMES causes an error. Include <stdio.h> here and
then in common/console.c use MAX_NAMES rather than 3 when working with
stdio_names.
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
With tighter build flags the fact that this header referenced
uchar/ushort without including what typedefs it causes an error. Rather
than add another include here, drop the section in question as it is
unused.
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
With driver model the serial device is often not called "serial". Mark
driver-model stdio devices so that they can be detected and we can look up
the uclass. This is a more reliable way of finding out whether the console
is connected to a serial device or not.
Signed-off-by: Simon Glass <sjg@chromium.org>
This converts the following to Kconfig:
CONFIG_SYS_STDIO_DEREGISTER
This option should never be enabled in SPL, so use
CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER) when checking the option.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Re-sync]
Signed-off-by: Tom Rini <trini@konsulko.com>
With limit of 16 symbols very simple device names derived drom device
tree description could not be displayed correctly.
For example "serial0@0xc0fc1000" will be truncated to sensless
"serial0@0xc0fc10" - note dropped tariling zeros.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In some cases we really want to move forward with a deregister, add a force
parameter to allow this, and replace the dev with a nulldev in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
For some boards board_init() will change GPIOs, so we need to have driver
model available before then. Adjust the board init to arrange this, but
enable it for driver model only, just to be safe.
This does create additional #ifdef logic, but it is safer than trying to
make a pervasive change which may cause some boards to break.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current functions for adding and removing devices require a device name.
This is not convenient for driver model, which wants to store a pointer to
the relevant device. Add new functions which provide this feature and adjust
the old ones to call these.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present stdio device functions do not get any clue as to which stdio
device is being acted on. Some implementations go to great lengths to work
around this, such as defining a whole separate set of functions for each
possible device.
For driver model we need to associate a stdio_dev with a device. It doesn't
seem possible to continue with this work-around approach.
Instead, add a stdio_dev pointer to each of the stdio member functions.
Note: The serial drivers have the same problem, but it is not strictly
necessary to fix that to get driver model running. Also, if we convert
serial over to driver model the problem will go away.
Code size increases by 244 bytes for Thumb2 and 428 for PowerPC.
22: stdio: Pass device pointer to stdio methods
arm: (for 2/2 boards) all +244.0 bss -4.0 text +248.0
powerpc: (for 1/1 boards) all +428.0 text +428.0
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Removed stdio structure ops support on arm_dcc
driver, and need to register with serial core
so-that it can access like remianing serial drivers.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
CONFIG_ARM_DCC_MULTI should be also removed in the patch
"serial: Remove CONFIG_SERIAL_MULTI from serial drivers"
(sha1: a382725060)
Because the driver defines serial_* functions
which cause conflict with serial.c (multiple definition of serial_*)
Removing CONFIG_SERIAL_MULTI function also require to define
default_serial_console for cases where another serial driver
is not available in the system.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Marek Vasut <marex@denx.de>
This patch builds upon the recently introduced CBMEM console
feature of coreboot.
CBMEM console uses a memry area allocated by coreboot to store
the console output. The memory area has a certain structure,
which allows to determine where the buffer is, the buffer size
and the location of the pointer in the buffer. This allows
different phases of the firmware (rom based coreboot, ram based
coreboot, u-boot after relocation with this change) to keep
adding text to the same buffer.
Note that this patch introduces a new console driver and adds the
driver to the list of drivers to be used for console output, i.e.
it engages only after u-boot relocates. Usiong CBMEM console for
capturing the pre-relocation console output will be done under a
separate change.
>From Linux, run the cbmem.py utility (which is a part of the coreboot
package) to see the output, e.g.:
vvvvvvvvvvvvvvvvv
SCSI: AHCI 0001.0300 32 slots 6 ports ? Gbps 0xf impl SATA mode
flags: 64bit ilck stag led pmp pio
...
Magic signature found
Kernel command line: "cros_secure quiet loglevel=1 console=tty2...
^^^^^^^^^^^^^^^^^
Note that the entire u-boot output fits into the buffer only if
the coreboot log level is reduced from the most verbose. Ether
the buffer size will have to be increased, or the coreboot
verbosity permanently reduced.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'trab' board configuration is broken, and there is nobody who is
interested and willing to fix it. Drop it.
This includes support for VFD displays which have always been used by
this board only.
Signed-off-by: Wolfgang Denk <wd@denx.de>
So far the console API uses the following naming convention:
======Extract======
typedef struct device_t;
int device_register (device_t * dev);
int devices_init (void);
int device_deregister(char *devname);
struct list_head* device_get_list(void);
device_t* device_get_by_name(char* name);
device_t* device_clone(device_t *dev);
=======
which is too generic and confusing.
Instead of using device_XX and device_t we change this
into stdio_XX and stdio_dev
This will also allow to add later a generic device mechanism in order
to have support for multiple devices and driver instances.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Edited commit message.
Signed-off-by: Wolfgang Denk <wd@denx.de>
