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 <[email protected]>: > >> > >> 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 <[email protected]>: > >>>>> > >>>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote: > >>>>> > >>>>>> From: Jens Rehsack <[email protected]> > >>>>>> > >>>>>> 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 <[email protected]> > >>>>>> --- > >>>>>> 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
signature.asc
Description: PGP signature
