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

[Jens Rehsack]

> 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"/...

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