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

[Michal Simek <michal.simek@xilinx.com>]

On 14. 02. 20 16:20, Jens Rehsack wrote:
> 
> 
>> Am 14.02.2020 um 15:43 schrieb Tom Rini <trini@konsulko.com>:
>>
>> On Fri, Feb 14, 2020 at 03:40:05PM +0100, Jens Rehsack wrote:
>>>
>>>
>>>> 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.
>>
>> I'm sure you are.
> 
> Really - I'm not. I have very low experience in u-boot at all. Maybe it's getting
> better over time, but for the very moment I disagree :P

I am also sure that you will be fine.

>>> 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,
> 
> I can review zync boards and figure out how the topic, bitmain, opalkelly use
> there some common stuff. But mind: I do not have any zync system and can't test
> anything. So it will be completely dry what will come out.

Just do that changes how they should look like. I also don't have some
of these boards but we can ask others to test and ack.


>> 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.
> 
> The "superlink" is using a lot of configured stuff from freescale/common - and
> different machines configure it differently (for reason), especially old PowerPC
> and newer arm64 ones.

Feel free to choose platforms which you know but we really need to have
a use in mainline code to see usage. If this is useful we will convert
Zynq platforms based on the same pattern later.

Thanks,
Michal