> Am 14.02.2020 um 14:45 schrieb Tom Rini <tr...@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 <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.
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 - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP