[PATCH v2 2/2] net: phy: micrel: sync init code for ksz80xx variants with the kernel driver
Oleksij Rempel
o.rempel at pengutronix.de
Thu Oct 14 23:36:58 PDT 2021
On Thu, Oct 14, 2021 at 01:32:27PM -0700, Trent Piepho wrote:
> On Wed, Oct 13, 2021 at 4:19 AM Oleksij Rempel <o.rempel at pengutronix.de> wrote:
> > On Wed, Oct 13, 2021 at 03:25:17AM -0700, Trent Piepho wrote:
> > > On Wed, Oct 13, 2021 at 2:43 AM Oleksij Rempel <o.rempel at pengutronix.de> wrote:
> > > >
> > > > Sync part of barebox micrel driver with the kernel v5.15-rc1.
> > > > This change will affect most of by barebox supported 100Mbit/ksz80xx PHY
> > > > variants and provide unified devicetree support for LED and clock configuration.
> > >
> > > I already added LED mode OF support to this driver.
> >
> > Yes, it was partially incorrect. It attempted to write to not existing or not
> > documented register of PHY_ID_KS8737.
>
> That is not true. KS8737 would only attempt to set the led mode bits
> if the device tree tries to set the led mode. Since KS8737 does not
> have a led mode selection, the device tree should not have this, and
> there is no problem.
>
> If you want a device tree validator, then use the yaml dts spec to do
> this in the proper way, at build time.
Please, verify your suggestion.
> The bootloader has the the
> most constrained size of any part of a Linux system and is also the
> most critical for device start up time. It is the worst possible
> place to put a dts validator.
After you'll spend time on verifying your previous suggestion. I'll be
able to explain, why this part has tiny problem.
> > This is the reason why I prefer to share driver code base with kernel,
> > where possible.
>
> You again ignore there are two ways to do this.
Board code and phy fixups? Please reread my previous answer. But from
your yuml suggestion I hope to know main misunderstanding in this
discussion.
> Make the kernel match Barebox where the Barebox code is better.
>From this discussion, i assume you are using linux kernel. This "bad"
kernel code runs on your system and many other devices in the world.
But, you actually do not care to send kernel patches. So, kernel code
quality is not a big issue for you? The code which actually runs on your
system?
Well, it looks like, your code quality concept seems to be limited by
definition of code size, at least for barebox. But, I hope, after you
understand the root of PHY related challenges, you'll understand why
most of your suggestion will work only on some limited amount of use
cases.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the barebox
mailing list