[PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER

[Tom Rini]

On Fri, Feb 14, 2020 at 03:21:44PM +0100, Jens Rehsack wrote:
> 
> 
> > Am 14.02.2020 um 14:45 schrieb Tom Rini <trini at konsulko.com>:
> > 
> > On Fri, Feb 14, 2020 at 12:49:36PM +0100, Michal Simek wrote:
> >> On 14. 02. 20 12:37, Jens Rehsack wrote:
> >>> 
> >>> 
> >>>> Am 14.02.2020 um 10:36 schrieb Michal Simek <monstr at monstr.eu>:
> >>>> 
> >>>> On 13. 02. 20 18:48, Tom Rini wrote:
> >>>>> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote:
> >>>>>> 
> >>>>>> 
> >>>>>>> Am 13.02.2020 um 16:01 schrieb Tom Rini <trini at konsulko.com>:
> >>>>>>> 
> >>>>>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
> >>>>>>> 
> >>>>>>>> From: Jens Rehsack <sno at NetBSD.org>
> >>>>>>>> 
> >>>>>>>> Introduce SUPPLIER analogous to VENDOR to allow (from customer perspective)
> >>>>>>>> a VENDOR using it's SUPPLIER's common/ code.
> >>>>>>>> 
> >>>>>>>> This is reasonable, when a VENDOR (from customer perspective) builds
> >>>>>>>> several machines sharing some features (e.g. some FPGA which has to be
> >>>>>>>> initialized during u-boot) but wants to use common NXP or Samsung code
> >>>>>>>> for the BSP instead of copying and create merge overhead.
> >>>>>>>> 
> >>>>>>>> Signed-off-by: Jens Rehsack <sno at NetBSD.org>
> >>>>>>>> ---
> >>>>>>>> Makefile     |  4 +++-
> >>>>>>>> arch/Kconfig | 12 ++++++++++++
> >>>>>>>> config.mk    |  6 +++++-
> >>>>>>>> 3 files changed, 20 insertions(+), 2 deletions(-)
> >>>>>>> 
> >>>>>>> Can you provide a follow-up where this it clearer / easier to do
> >>>>>>> something than today?  Thanks!
> >>>>>> 
> >>>>>> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common
> >>>>>> NXP code for the Management Complex is needed. I2C code either - this
> >>>>>> covers board/freescale/common/...
> >>>>>> 
> >>>>>> Given you build machines from there with different SoCs under a
> >>>>>> new label - let's call it SuperLink, so you have
> >>>>>> * board/freescale/common
> >>>>>> * board/superlink/common
> >>>>>> * board/superlink/legacy-tune <-- based on some PowerPC
> >>>>>> * board/superlink/easy-tune <-- based on LS2088
> >>>>>> * board/superlink/heavy-tune <-- based on LX2160
> >>>>>> 
> >>>>>> All *-tune machines the customer buys from SuperLink have a
> >>>>>> similar FPGA (there is a little bit more, but for the vision
> >>>>>> it's probably better to stay small) and a similar external
> >>>>>> PMIC/BMC.
> >>>>>> 
> >>>>>> But SuperLink still uses code from board/freescale/common (their
> >>>>>> supplier) and it's not reasonable to copy those.
> >>>>>> 
> >>>>>> I rate all this not suitable for a commit message. How do
> >>>>>> you suggest to proceed?
> >>>>> 
> >>>>> Well, lets add in Michal as there are Zynq examples that could be
> >>>>> cleaned up with what you're proposing.  Similarly, Vanessa and Otavio
> >>>>> might have thoughts here as they could rework some of the TechNexion
> >>>>> boards.  And Fabio for WaRP7 (and aside, should both warp/warp7 be moved
> >>>>> from board/ to some sub-directory?).  Thanks all!
> >>>> 
> >>>> I think it will be the best to take any of your example and simply
> >>>> create a series where this is applied to see if that code looks better
> >>>> then before. Applying this without usage doesn't make sense.
> >>> 
> >>> I don't understand what you propose. Do you ask me to show internal
> >>> sources or the result of `find {...} -type f` or the content of our
> >>> Kconfig or defconfig?
> >>> 
> >>> I'll try to do as much as I can (I'm sure, showing internal code won't
> >>> be permitted).
> >>> 
> >>>> For zynq there are some boards like topic, bitmain, opalkelly  which are
> >>>> staying in own folder but sourcing zynq board.c.
> >>> 
> >>> As said, freescale common code stays in board/freescale/common/ - and
> >>> our code is in board/"superlink"/...
> >> 
> >> I expect that you will find any example in the current code which can
> >> use this feature. It means you can enable this feature and any current
> >> configuration will really use it and will be regularly used/covered by
> >> testing.
> >> Adding feature which none will use in mainline should be IMHO nacked.
> > 
> > Yes.  All of the boards / people I added to the thread here have
> > platforms that would be able to leverage this idea, so I was hoping they
> > might have a perspective on if it would be clear than just:
> > obj-y += ../../<vendor>/common/whatever.o
> > like is done today.
> 
> So a PATCH-set with (likely non-working) examples will be fine or not?

No, but there are a number of existing configs that could be changed to
use the framework you're suggesting.  So far it seems like the feedback
has been that maybe this would be cleaner than just what I said above,
but you need to convert some of them to use this, so we can see if it's
really cleaner or not.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200214/33bd8783/attachment.sig>