[U-Boot] [u-boot 14/40] usb: dwc3: linux-compat: Add header for dwc3 linux compatibiltiy

Marek Vasut
2015-02-23T14:59:21Z

On Monday, February 23, 2015 at 07:19:03 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 16 February 2015 04:02 PM, Lukasz Majewski wrote:
> > Hi Kishon, Marek
> >
> >> Added a header file to include various linux specific APIs like
> >> pr_debug, WARN_ WARN_ON_ONCE etc.. in order to avoid compilation
> >> error while building dwc3 driver.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >> ---
> >>
> >> drivers/usb/dwc3/linux-compat.h | 30 ++++++++++++++++++++++++++++++
> >> 1 file changed, 30 insertions(+)
> >> create mode 100644 drivers/usb/dwc3/linux-compat.h
> >>
> >> diff --git a/drivers/usb/dwc3/linux-compat.h
> >> b/drivers/usb/dwc3/linux-compat.h new file mode 100644
> >> index 0000000..58c4716
> >> --- /dev/null
> >> +++ b/drivers/usb/dwc3/linux-compat.h
> >> @@ -0,0 +1,30 @@
> >> +/**
> >> + * linux-compat.h - DesignWare USB3 Linux Compatibiltiy Adapter
> >> Header
> >> + *
> >> + * Copyright (C) 2015 Texas Instruments Incorporated -
> >> http://www.ti.com
> >> + *
> >> + * Authors: Kishon Vijay Abraham I <kishon@ti.com>
> >> + *
> >> + * Taken from Linux Kernel v3.16 (drivers/usb/dwc3/core.c) and ported
> >> + * to uboot.
> >> + *
> >> + * SPDX-License-Identifier: GPL-2.0
> >> + *
> >> + */
> >> +
> >> +#ifndef __DWC3_LINUX_COMPAT__
> >> +#define __DWC3_LINUX_COMPAT__
> >> +
> >> +#define pr_debug(format) debug(format)
> >> +#define WARN(val, format, arg...) debug(format, ##arg)
> >> +#define WARN_ON_ONCE(val) debug("Error %d\n", val)
> >> +
> >> +#define BUILD_BUG_ON_NOT_POWER_OF_2(n)
> >> +
> >> +static inline size_t strlcat(char *dest, const char *src, size_t n)
> >> +{
> >> + strcat(dest, src);
> >> + return strlen(dest) + strlen(src);
> >> +}
> >> +
> >> +#endif
> >
> > Similar file has been already added to u-boot.
> > Please look into ./drivers/usb/musb-new/linux-compat.h
> >
> > @Marek - maybe it is time to have a common one?
>
> Can we do this separately?

Would it be too much of a hassle to make a common one please ?

The musb-new (and musb) is a fine example why I don't want to let new drivers
add duplicit code. It was the same with musb-new -- this driver was supposed to
replace musb, but this never happened and now we have two drivers in various
state of support.

Best regards,
Marek Vasut