diff mbox series

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

Message ID 20200213133353.20353-1-sno@netbsd.org
State Deferred
Delegated to: Tom Rini
Headers show
Series {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER | expand

Commit Message

Jens Rehsack Feb. 13, 2020, 1:33 p.m. UTC 
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(-)

Comments

Tom Rini Feb. 13, 2020, 3:01 p.m. UTC | #1 
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!
Jens Rehsack Feb. 13, 2020, 4:57 p.m. UTC | #2 
> 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?

Best regards
--
Jens Rehsack - rehsack@gmail.com
Tom Rini Feb. 13, 2020, 5:48 p.m. UTC | #3 
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!
Michal Simek Feb. 14, 2020, 9:36 a.m. UTC | #4 
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.

For zynq there are some boards like topic, bitmain, opalkelly  which are
staying in own folder but sourcing zynq board.c.

Thanks,
Michal
Jens Rehsack Feb. 14, 2020, 11:37 a.m. UTC | #5 
> 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"/...

Best regards
--
Jens Rehsack - rehsack@gmail.com
Michal Simek Feb. 14, 2020, 11:49 a.m. UTC | #6 
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.

Thanks,
Michal
Fabio Estevam Feb. 14, 2020, 12:08 p.m. UTC | #7 
On Fri, Feb 14, 2020 at 6:36 AM Michal Simek <monstr@monstr.eu> wrote:

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

Agreed.

SYS_SUPPLIER is introduced in this patch, but there is currently no user.
Jens Rehsack Feb. 14, 2020, 12:22 p.m. UTC | #8 
> Am 14.02.2020 um 13:08 schrieb Fabio Estevam <festevam@gmail.com>:
> 
> On Fri, Feb 14, 2020 at 6:36 AM Michal Simek <monstr@monstr.eu> wrote:
> 
>> 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.
> 
> Agreed.
> 
> SYS_SUPPLIER is introduced in this patch, but there is currently no user.

The intent is to introduce it since it is missing for described use case.
I do not intend to review any BSP whether it can make benefits of this.
I'm fine to keep the usage intern only when it's unwanted.

I agree to submit an example - created especially for demonstration
purposes without any code in it.

When this is enough, please tell me.

Best regards
--
Jens Rehsack - rehsack@gmail.com
Tom Rini Feb. 14, 2020, 1:45 p.m. UTC | #9 
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.
Jens Rehsack Feb. 14, 2020, 2:21 p.m. UTC | #10 
> 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?

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

Best regards
--
Jens Rehsack - rehsack@gmail.com
Tom Rini Feb. 14, 2020, 2:28 p.m. UTC | #11 
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.
Jens Rehsack Feb. 14, 2020, 2:40 p.m. UTC | #12 
> 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@gmail.com
Tom Rini Feb. 14, 2020, 2:43 p.m. UTC | #13 
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.

> 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.
Jens Rehsack Feb. 14, 2020, 3:20 p.m. UTC | #14 
> 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

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

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

Best regards
--
Jens Rehsack - rehsack@gmail.com
Michal Simek Feb. 17, 2020, 9:42 a.m. UTC | #15 
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
diff mbox series

Patch

diff --git a/Makefile b/Makefile
index 0af89e0a78..94ef1e5003 100644
--- a/Makefile
+++ b/Makefile
@@ -427,7 +427,7 @@  UBOOTRELEASE = $(shell cat include/config/uboot.release 2> /dev/null)
 UBOOTVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
 
 export VERSION PATCHLEVEL SUBLEVEL UBOOTRELEASE UBOOTVERSION
-export ARCH CPU BOARD VENDOR SOC CPUDIR BOARDDIR
+export ARCH CPU BOARD VENDOR SUPPLIER SOC CPUDIR BOARDDIR
 export CONFIG_SHELL HOSTCC HOSTCFLAGS HOSTLDFLAGS CROSS_COMPILE AS LD CC
 export CPP AR NM LDR STRIP OBJCOPY OBJDUMP
 export MAKE LEX YACC AWK PERL PYTHON PYTHON2 PYTHON3
@@ -721,9 +721,11 @@  c_flags := $(KBUILD_CFLAGS) $(cpp_flags)
 # U-Boot objects....order is important (i.e. start must be first)
 
 HAVE_VENDOR_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(VENDOR)/common/Makefile),y,n)
+HAVE_SUPPLIER_COMMON_LIB = $(if $(wildcard $(srctree)/board/$(SUPPLIER)/common/Makefile),y,n)
 
 libs-y += lib/
 libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
+libs-$(HAVE_SUPPLIER_COMMON_LIB) += board/$(SUPPLIER)/common/
 libs-$(CONFIG_OF_EMBED) += dts/
 libs-y += fs/
 libs-y += net/
diff --git a/arch/Kconfig b/arch/Kconfig
index ae9c93ed7b..512ba7c0ac 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -248,6 +248,18 @@  config SYS_SOC
 	  This is optional.  For those targets without the SoC directory,
 	  leave this option empty.
 
+config SYS_SUPPLIER
+	string
+	help
+	  This option should contain the supplier name of the target soc.
+	  One could even distinguish between SYS_SUPPLIER and SYS_VENDOR as
+	  SYS_SOC_VENDOR and SYS_BOARD_VENDOR.  If it is set and
+	  board/<CONFIG_SYS_SUPPLIER>/common/Makefile exists, the supplier
+	  common directory is compiled.
+
+	  This is optional.  For those targets without the vendor directory,
+	  leave this option empty.
+
 config SYS_VENDOR
 	string
 	help
diff --git a/config.mk b/config.mk
index caf0dd9b81..993d5a2b40 100644
--- a/config.mk
+++ b/config.mk
@@ -17,8 +17,9 @@  LDFLAGS :=
 LDFLAGS_FINAL :=
 LDFLAGS_STANDALONE :=
 OBJCOPYFLAGS :=
-# clear VENDOR for tcsh
+# clear VENDOR & SUPPLIER for tcsh
 VENDOR :=
+SUPPLIER :=
 #########################################################################
 
 ARCH := $(CONFIG_SYS_ARCH:"%"=%)
@@ -32,6 +33,9 @@  BOARD := $(CONFIG_SYS_BOARD:"%"=%)
 ifneq ($(CONFIG_SYS_VENDOR),)
 VENDOR := $(CONFIG_SYS_VENDOR:"%"=%)
 endif
+ifneq ($(CONFIG_SYS_SUPPLIER),)
+SUPPLIER := $(CONFIG_SYS_SUPPLIER:"%"=%)
+endif
 ifneq ($(CONFIG_SYS_SOC),)
 SOC := $(CONFIG_SYS_SOC:"%"=%)
 endif