From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER
Date: Fri, 14 Feb 2020 08:45:16 -0500 [thread overview]
Message-ID: <20200214134516.GU18302@bill-the-cat> (raw)
In-Reply-To: <898b4eb5-6028-f7b9-833d-8ca7823dcd09@xilinx.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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200214/08d4faca/attachment.sig>
next prev parent reply other threads:[~2020-02-14 13:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 13:33 [PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER Jens Rehsack
2020-02-13 15:01 ` Tom Rini
2020-02-13 16:57 ` Jens Rehsack
2020-02-13 17:48 ` Tom Rini
2020-02-14 9:36 ` Michal Simek
2020-02-14 11:37 ` Jens Rehsack
2020-02-14 11:49 ` Michal Simek
2020-02-14 13:45 ` Tom Rini [this message]
2020-02-14 14:21 ` Jens Rehsack
2020-02-14 14:28 ` Tom Rini
2020-02-14 14:40 ` Jens Rehsack
2020-02-14 14:43 ` Tom Rini
2020-02-14 15:20 ` Jens Rehsack
2020-02-17 9:42 ` Michal Simek
2020-02-14 12:08 ` Fabio Estevam
2020-02-14 12:22 ` Jens Rehsack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200214134516.GU18302@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox