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

[Jens Rehsack <rehsack@gmail.com>]

> Am 14.02.2020 um 15:28 schrieb Tom Rini <trini@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@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@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@konsulko.com>:
>>>>>>>>> 
>>>>>>>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
>>>>>>>>> 
>>>>>>>>>> From: Jens Rehsack <sno@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@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.
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.

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 :)

Best regards
--
Jens Rehsack - rehsack at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200214/7c4649f9/attachment.sig>