mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Trent Piepho <trent.piepho@igorinstitute.com>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] net: phy: micrel: sync init code for ksz80xx variants with the kernel driver
Date: Fri, 15 Oct 2021 08:36:58 +0200	[thread overview]
Message-ID: <20211015063658.GB7427@pengutronix.de> (raw)
In-Reply-To: <CAMHeXxMuEMF5yuBkxkNHBVNfO6Yk66mw+5++yesqsOOGSGrBeA@mail.gmail.com>

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@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@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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


  reply	other threads:[~2021-10-15  6:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13  7:53 [PATCH v2 1/2] include/phy: add driver_data to resume more of kernel code Oleksij Rempel
2021-10-13  7:53 ` [PATCH v2 2/2] net: phy: micrel: sync init code for ksz80xx variants with the kernel driver Oleksij Rempel
2021-10-13 10:25   ` Trent Piepho
2021-10-13 11:19     ` Oleksij Rempel
2021-10-14 20:32       ` Trent Piepho
2021-10-15  6:36         ` Oleksij Rempel [this message]
2021-10-15  7:11         ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211015063658.GB7427@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=trent.piepho@igorinstitute.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox