> On 20 Sep 2017, at 16:41, Bin Meng <bmeng...@gmail.com> wrote: > > Hi Simon, > > On Wed, Sep 20, 2017 at 9:50 PM, Simon Glass <s...@chromium.org> wrote: >> Hi Bin, >> >> On 17 September 2017 at 21:45, Bin Meng <bmeng...@gmail.com> wrote: >>> Hi Simon, >>> >>> On Sun, Sep 17, 2017 at 5:23 AM, Simon Glass <s...@chromium.org> wrote: >>>> Add the logging header file and implementation with some configuration >>>> options to control it. >>>> >>>> Signed-off-by: Simon Glass <s...@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 <s...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot