On 04/09/2018 16:03:51-0700, Paul Burton wrote: > Well, it sounded like David is OK with this all going through the MIPS > tree, though we'd need an ack for the PHY parts. > > Alternatively I'd be happy for the DT changes to go through the net-next > tree, which may make more sense given that the .dts changes are pretty > trivial in comparison with the driver changes. If David wants to do that > then for patches 1 & 8: > > Acked-by: Paul Burton <paul.burton@xxxxxxxx> > > Either way there may be conflicts for ocelot.dtsi when it comes to > merging to master, but they should be simple to resolve. It seems > Wolfram already took your DT changes for I2C so there's probably going > to be multiple trees updating that file this cycle already anyway. > Actually, I think Wolfram meant that he took the bindings so you can take the DT patches for i2c. > Ideally I'd say "don't break bisection" but that's sort of a separate > issue here since even if you restructure your series to do that it would > still need to go through one tree. For example you could adjust > mscc_ocelot_probe() to handle either the reg property or the syscon, > then adjust the DT to use the syscon, then remove the code dealing with > the reg property, and I'd consider that a good idea anyway but it would > still probably all need to go through one tree to make sure things get > merged in the right order & avoid breaking bisection. > I don't really think bisection is important at this stage but if you don't want to break it, then I guess it makes more sense to have the whole series through net. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
