[U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com>]

> On 20 Sep 2017, at 16:41, Bin Meng <bmeng.cn@gmail.com> wrote:
> 
> Hi Simon,
> 
> On Wed, Sep 20, 2017 at 9:50 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>> 
>> On 17 September 2017 at 21:45, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>> 
>>> On Sun, Sep 17, 2017 at 5:23 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Add the logging header file and implementation with some configuration
>>>> options to control it.
>>>> 
>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>> ---
>>>> 
>>>> MAINTAINERS                       |   9 ++
>>>> common/Kconfig                    |  56 +++++++++
>>>> common/Makefile                   |   1 +
>>>> common/log.c                      | 246 +++++++++++++++++++++++++++++++++++++
>>>> include/asm-generic/global_data.h |   5 +
>>>> include/log.h                     | 247 ++++++++++++++++++++++++++++++++++++--
>>>> 6 files changed, 555 insertions(+), 9 deletions(-)
>>>> create mode 100644 common/log.c
>>>> 
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 04acf2b89d..eb420afa8d 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -290,6 +290,15 @@ S: Maintained
>>>> T:     git git://git.denx.de/u-boot-i2c.git
>>>> F:     drivers/i2c/
>>>> 
>>>> +LOGGING
>>>> +M:     Simon Glass <sjg@chromium.org>
>>>> +S:     Maintained
>>>> +T:     git git://git.denx.de/u-boot.git
>>>> +F:     common/log.c
>>>> +F:     cmd/log.c
>>>> +F:     test/log/log_test.c
>>>> +F:     test/py/tests/test_log.py
>>> 
>>> test/log/log_test.c and test/py/tests/test_log.py have not been
>>> introduced at this point.
>> 
>> OK I can tweak that,
>> [..]
>> 
>>>> +/**
>>>> + * struct log_driver - a driver which accepts and processes log records
>>>> + *
>>>> + * @name: Name of driver
>>>> + */
>>>> +struct log_driver {
>>>> +       const char *name;
>>>> +       /**
>>>> +        * emit() - emit a log record
>>>> +        *
>>>> +        * Called by the log system to pass a log record to a particular driver
>>>> +        * for processing. The filter is checked before calling this function.
>>>> +        */
>>>> +       int (*emit)(struct log_device *ldev, struct log_rec *rec);
>>>> +};
>>>> +
>>> 
>>> So we are creating a new type of non-DM driver which is log-specific?
>>> How about we add this emit to the existing uclass driver that can be
>>> used as the log driver? (eg: blk devices with file system?)
>> 
>> Yes that's right. I think I can link it to DM once it starts up, but a
>> logging of DM start-up is useful.
>> 
>> Re your idea are you saying add an emit() method to UCLASS_BLK?
>> 
> 
> Yep, something like
> 
> #ifdef CONFIG_LOG
>    .log_emit = xxx_log_emit,
> #endif
> 
> Probably we need a flag to find out which driver provides such log
> functionality.

I had started to sketch (but have been able to fully flesh this out, due to 
other priorities intervening) a mechanism for MISC devices that might
be a good fit for this.

My work centers around the idea of having devices comply to “protocols”
and was aimed at distinguishing between an efuse-device and a GbE 
RGMII-control (one where we need to adjust the RGMII clock depending
on the link rate the PHY negotiated) device.

I.e. I had started to implement something along the lines of:

	/**
	 * misc_supports - tests if a misc device complies to a given protocol
	 *
	 * protocols can either be ‘how data is processed after calling write()’,
	 * ‘how data is presented for a read()’ or ‘what ioctl-values are supported’.
	 * The assumption is that protocols can be versioned and higher versions
	 * offer full backward compatibility (i.e. a client for “Ethernet PHY control, v1”
	 * can work with a driver implementing v1 or any higher version).
	 */
	bool misc_supports(struct udevice *dev, const char *protocol, u32 version);

and a way to register a list of protocols as part of the misc uclass-priv for
any given driver.

This would allow us to enumerate all MISC devices until we find one that
complies to the ‘logging’-protocol and then invoke write or ioctl on it.

Regards,
Philipp.