Hi Alexey, On Mon, Jan 11, 2016 at 11:50 AM, Alexey Brodkin <alexey.brod...@synopsys.com> wrote: > Hi Joe, > > On Mon, 2016-01-11 at 10:54 -0600, Joe Hershberger wrote: >> Hi Alexey, >> >> On Mon, Jan 11, 2016 at 3:45 AM, Alexey Brodkin >> <alexey.brod...@synopsys.com> wrote: >> > Hi Joe, >> > >> > On Wed, 2015-12-23 at 19:44 +0300, Alexey Brodkin wrote: >> > > From: Sascha Hauer <s.ha...@pengutronix.de> >> > > >> > > of_set_phy_supported allows overwiting hardware capabilities of >> > > a phy with values from the devicetree. This does not work with >> > > the genphy driver though because the genphys config_init function >> > > will overwrite all values adjusted by of_set_phy_supported. Fix >> > > this by initialising the genphy features in the phy_driver struct >> > > and in config_init just limit the features to the ones the hardware >> > > can actually support. The resulting features are a subset of the >> > > devicetree specified features and the hardware features. >> > > >> > > This is a copy of the patch from Linux kernel, see >> > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c242a47238fa2a6a54af8a16e62b54e6e031d4bc >> > > >> > > Signed-off-by: Sascha Hauer <s.ha...@pengutronix.de> >> > > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> >> > > Cc: Joe Hershberger <joe.hershber...@ni.com> >> > > --- >> > >> > Any chance for that one to be applied? >> >> I'll review when the merge window opens. >> >> > This patch is required to implement phy max >> > speed limitation by subsequent patches. >> >> Any reason you did not send as a series if there are dependencies? > > I thought about putting some of those patches in one series initially but then > decided to send them separately. > > Even though together they solve one particular problem (ability to > set phy speed limit) they are a bit different by their nature. > > http://patchwork.ozlabs.org/patch/560608/, > http://patchwork.ozlabs.org/patch/560634/ and > http://patchwork.ozlabs.org/patch/560635/ are back-ports from Linux kernel > and could be actually applied separately because they are not related to > each other. > > Following two are really preparatory for implementing capping: > http://patchwork.ozlabs.org/patch/560636/ > http://patchwork.ozlabs.org/patch/560637/ > > ...in patch I actually forgot to send out... (will do it shortly). > > And finally http://patchwork.ozlabs.org/patch/560638/ really a plain fix > for DW GMAC driver which may happen in case of phy force set lower than > possible. So it will easily manifest if all above is applied. > > That said it was conscious decision but probably incorrect one. > > If you do think it all fits well in a series I'll re-send it that way.
If there is no build or functionality breaking order dependency then it's ok that they are not in a series. If there is any dependency like that, then I would appreciate a series so that I know what order to apply them without having to figure it out. Thanks, -Joe _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
