On Fri, Feb 14, 2020 at 03:40:05PM +0100, Jens Rehsack wrote: > > > > Am 14.02.2020 um 15:28 schrieb Tom Rini <[email protected]>: > > > > On Fri, Feb 14, 2020 at 03:21:44PM +0100, Jens Rehsack wrote: > >> > >> > >>> Am 14.02.2020 um 14:45 schrieb Tom Rini <[email protected]>: > >>> > >>> 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. > >> > >> 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. -- Tom
signature.asc
Description: PGP signature
