[U-Boot] [PATCH] net: phy: genphy: Allow overwriting features

[Joe Hershberger]

Hi Alexey,

On Mon, Jan 11, 2016 at 11:50 AM, Alexey Brodkin
<Alexey.Brodkin at 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.Brodkin at synopsys.com> wrote:
>> > Hi Joe,
>> >
>> > On Wed, 2015-12-23 at 19:44 +0300, Alexey Brodkin wrote:
>> > > From: Sascha Hauer <s.hauer at 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.hauer at pengutronix.de>
>> > > Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
>> > > Cc: Joe Hershberger <joe.hershberger at 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