Re: [PATCH] arm64: dts: renesas: white-hawk-cpu: Move avb0 reset gpio to mdio node

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

 



On Mon, Oct 28, 2024 at 7:58 PM Marek Vasut <marex@xxxxxxx> wrote:
> On 10/28/24 11:13 AM, Geert Uytterhoeven wrote:
> >>>>> So, what would you suggest when the PHY nodes would not have compatible
> >>>>> strings?
> >>>> I would suggest keep the PHY compatible strings, because that is the
> >>>> most accurate method to describe the hardware and fulfill the PHY bring
> >>>> up requirements. If the PHY changes on this hardware in some future
> >>>
> >>> That issue is moot for KSZ9031.
> >>
> >> If the PHY won't change, then we can keep the compatible strings ?
> >
> > Sorry for being unclear. I should have written "the PHY bring-up
> > requirements are moot for KSZ9031".
>
> Perhaps, (*) but odd erratas do show up every once in a while, so unless
> you can surely say no such errata will show up for the KSZ9031, can you
> really dismiss the bring up requirements ?
>
> >>>> revision, we can revisit this discussion ? Maybe bootloader-applied DTOs
> >>>> could work then ?
> >>>
> >>> So, what would you suggest when the PHY nodes would not have compatible
> >>> strings?
> >> I hope I already answered that question before.
> >
> > Sorry, I may have missed that?
> >
> > I really prefer not having the PHY compatible strings, as DT should
> > describe only what cannot be auto-detected.
> See paragraph above (*). My take on this is the exact opposite, better
> describe the PHY in DT fully, including compatible strings, so that if
> the PHY driver needs to do some sort of bring up tweak/fix/errata
> workaround/... , it can do so by matching on the compatible string
> without trying to bring the PHY up in some generic and potentially
> problematic way.
>
> The MDIO bus is not discoverable the same way as PCIe or USB is, so I
> don't think the "DT should describe only what cannot be detected" is
> really applicable to MDIO bus the same way it applies to PCIe or USB.

So you think this is similar to SPI NOR, where most FLASHes can be
discovered with the JEDEC READ ID opcode?  See commit 4b0cb4e7ab2f777c
("dt-bindings: mtd: spi-nor: clarify the need for spi-nor compatibles"),
which clarified why no new compatible values are accepted.

Any guidance/opinion from the DT people?
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds





[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux