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 v1 2/2] net: phy: micrel: port clock select support
Date: Wed, 13 Oct 2021 13:02:19 +0200	[thread overview]
Message-ID: <20211013110219.GC17532@pengutronix.de> (raw)
In-Reply-To: <CAMHeXxNB6kCyvb_NwueE9FN5V3n6L-Xf=NJa0DS0FO4GY6MiCA@mail.gmail.com>

On Wed, Oct 13, 2021 at 03:43:46AM -0700, Trent Piepho wrote:
> On Wed, Oct 13, 2021 at 3:23 AM Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> >
> > On Wed, Oct 13, 2021 at 01:48:20AM -0700, Trent Piepho wrote:
> > > On Wed, Oct 13, 2021 at 12:29 AM Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> > > > > Note that not just KSZ8081 has this bit.  Also KSZ8021, KSZ8031, and
> > > > > KSZ8051, which has the existing different method to handle it, as
> > > > > described earlier.
> > > >
> > > > ok, i'll sync all of this PHYs with the state of the kernel driver.
> > > > The board fixups should be removed by someone who can confirm it.
> > >
> > > If you copy the entire kernel driver you will massively bloat this
> > > code with stuff that is totally unused.
> >
> > Yes.
> 
> Can you get network support into a Barebox that fits in IMX8 OCRAM?
> Bloat matters. There are things barebox can not do anymore because it
> has grown too large.

Yes. barebox depends on devicetree and most of special PHY
configuration is already provided by devicetree. Your initial suggestion
was to duplicate information provide by DT and put it in to the board
file. Which is exactly opposite of what you wont.

At same time, fixups introduce more issue:
- they are applied on multiple PHYs detected on one board. For example
  boards with switches.
- they are applied on external HW. For example USB adapter with same
  PHY.

> > > > > > +static int kszphy_rmii_clk_sel(struct phy_device *phydev, bool val)
> > > > > > +{
> > > > > > +       int ctrl;
> > > > > > +
> > > > > > +       ctrl = phy_read(phydev, MII_KSZPHY_CTRL);
> > > > > > +       if (ctrl < 0)
> > > > > > +               return ctrl;
> > > > > > +
> > > > > > +       if (val)
> > > > > > +               ctrl |= KSZPHY_RMII_REF_CLK_SEL;
> > > > > > +       else
> > > > > > +               ctrl &= ~KSZPHY_RMII_REF_CLK_SEL;
> > > > > > +
> > > > > > +       return phy_write(phydev, MII_KSZPHY_CTRL, ctrl);
> > > > > > +}
> > > > >
> > > > > phy_set_bits(phydev, MII_KSZPHY_CTRL, KSZ8051_RMII_50MHZ_CLK);
> > > >
> > > > No, it should be synced with kernel not in the opposite way.
> > >
> > > If you want the code to match, then improve the kernel code rather
> > > than make Barebox code worse.  phy_set_bits, phy_clear_bits and
> > > phy_modify exist.  One can not use them if a kernel driver has not
> > > been refactored to use them?
> >
> > Sure. Can you please show example of the kszphy_rmii_clk_sel() refactoring.
> > And how much optimization will it introduce? Please compared with disassembled
> > part.
> 
> struct kszphy_priv *priv = phydev->priv;
> if (priv->set_rmii_clk_sel)
>     phy_set_bits(phydev, MII_KSZPHY_CTRL, KSZ8051_RMII_50MHZ_CLK);

Sorry, it is not correct. It should be:
if (priv->set_rmii_clk_sel)
	phy_set_bits(phydev, MII_KSZPHY_CTRL, KSZ8051_RMII_50MHZ_CLK);
else
	phy_clear_bits(phydev, MII_KSZPHY_CTRL, KSZ8051_RMII_50MHZ_CLK);

There are KSZ PHY variants with opposite meaning of the same bit. So, at
the end I see no advantage of changing it.

> But did you really need me to provide that example?

No, i wont to see what is so special for you about this driver.
There should be reason why thing which you blame, make no sense for me.

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-13 12:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12 10:08 [PATCH v1 1/2] include/phy: add driver_data to resume more of kernel code Oleksij Rempel
2021-10-12 10:08 ` [PATCH v1 2/2] net: phy: micrel: port clock select support Oleksij Rempel
2021-10-12 17:12   ` Trent Piepho
2021-10-13  7:28     ` Oleksij Rempel
2021-10-13  8:48       ` Trent Piepho
2021-10-13 10:23         ` Oleksij Rempel
2021-10-13 10:43           ` Trent Piepho
2021-10-13 11:02             ` Oleksij Rempel [this message]

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=20211013110219.GC17532@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