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

[Jens Rehsack]

> 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?

As you don't answer to my latest mail - I have no permission to publish
internal code.

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/932fc2fc/attachment.sig>