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 <mon...@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 <tr...@konsulko.com>:
> >>>>>
> >>>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
> >>>>>
> >>>>>> From: Jens Rehsack <s...@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 <s...@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.

-- 
Tom

Attachment: signature.asc
Description: PGP signature

Reply via email to