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

Fri Feb 14 15:43:55 CET 2020

On Fri, Feb 14, 2020 at 03:40:05PM +0100, Jens Rehsack wrote:
> 
> 
> > Am 14.02.2020 um 15:28 schrieb Tom Rini <trini at konsulko.com>:
> > 
> > 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.
> 
> Yes, but I do not intend to refactor u-boot code. I'm not qualified to do that.

I'm sure you are.

> Further: I'm in such a case not sure if it's the right tactic.
> Since the SYS_SUPPLIER is introduced to have a 2nd vendor. When there're
> BSP's from Vendors using common code from others and customers want to derive
> from there, a 3rd level is relevant.

Yes, there's a number of platforms just like that in mainline today.
Michal noted a few of them and I noted others.

> The entire idea is allowing machine builders to have an independent upper
> level (vendor) from a lower level (supplier).
> 
> What you tell me would finally mean: vendor should be a list of paths instead
> of a single path.
> 
> However - when you name a few places which could reasonably refactored, I'm
> happy to give it a shot. Without guarantee :)

Well, the platforms Michal noted, and the boards under board/technexion/
that reference board/freescale/common/pfuze.o

If none of that really fits, perhaps you should just be doing:
obj-y += ../../freescale/common/whatever.o
in your superlink platforms.

-- 
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/9f9ebf8b/attachment.sig>