Re: [PATCH v2 2/2] net: phy: micrel: sync init code for ksz80xx variants with the kernel driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux