From: Nishanth Menon <nm@ti.com>
To: Roger Quadros <rogerq@kernel.org>
Cc: Ravi Gunasekaran <r-gunasekaran@ti.com>,
Maxime Ripard <mripard@kernel.org>,
Simon Glass <sjg@chromium.org>,
Joe Hershberger <joe.hershberger@ni.com>,
Ramon Fried <rfried.dev@gmail.com>,
Siddharth Vadapalli <s-vadapalli@ti.com>,
Javier Martinez Canillas <javierm@redhat.com>,
Peter Robinson <pbrobinson@gmail.com>, <u-boot@lists.denx.de>
Subject: Re: [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl
Date: Thu, 20 Jul 2023 09:00:19 -0500 [thread overview]
Message-ID: <20230720140019.nbyum2nh4vmbfpxn@predict> (raw)
In-Reply-To: <ad1c5085-5c9d-808e-b841-1ee375badb6c@kernel.org>
On 16:56-20230720, Roger Quadros wrote:
> Hi,
>
> On 20/07/2023 16:33, Ravi Gunasekaran wrote:
> >
> >
> > On 7/20/2023 3:25 PM, Maxime Ripard wrote:
> >> Hi,
> >>
> >> This series is based on:
> >> https://lore.kernel.org/all/20230713072019.3153871-1-nm@ti.com/
> >>
> >> It fixes the issue of Linux booting from the DT embedded by U-boot. The
> >> main issue there is that U-Boot doesn't handle the MDIO child node that
> >> might have resources attached to it.
> >>
> >> Thus, any pinctrl configuration that could be attached to the MDIO
> >> child node is effectively ignored. Unfortunately, starting with 6.5-rc1,
> >> Linux does just that.
>
> I didn't get this part. Linux does not ignore pinctrl configuration attached
> to MDIO child node. What changed in 6.5-rc1?
>
> >>
> >> This was solved by duplicating the pinctrl configuration onto the MAC
>
> If I remember right, there is no driver model driver for MDIO in u-boot and
> adding the mdio pinctrl into CPSW DT node was a hack in u-boot.
>
> >> device node. Unfortunately, this doesn't work for Linux since now it has
> >> two devices competing for the same pins.
>
> What has really changed here is that you are passing u-boot's device tree to Linux.
> This has nothing to do with 6.5-rc1 right?
>
> I suppose your solution is still a hack but of lesser evil than
> duplicating MDIO pinctrl in CPSW node.
>
> The proper solution would be to implement driver model for the davinci MDIO driver.
> Siddharth has been working on this. If that is close to ready we should just use
> that instead.
But this allows for a cleaner device tree while the driver can be fixed
up independently, correct? Unfortunately, Siddharth's driver model work,
from what I understand, is around 2024 timeframe.. which is probably not
something that helps us in the community at this point.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
next prev parent reply other threads:[~2023-07-20 14:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 9:55 [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl Maxime Ripard
2023-07-20 9:55 ` [PATCH 1/4] pinctrl: Create a select_state variant with the ofnode Maxime Ripard
2023-07-20 15:56 ` Roger Quadros
2023-07-20 9:55 ` [PATCH 2/4] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node Maxime Ripard
2023-07-20 15:47 ` Roger Quadros
2023-07-21 12:17 ` Maxime Ripard
2023-07-20 9:55 ` [PATCH 3/4] fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1 Maxime Ripard
2023-07-20 9:55 ` [PATCH 4/4] " Maxime Ripard
2023-07-20 15:27 ` Roger Quadros
2023-07-21 7:46 ` Maxime Ripard
2023-07-21 9:14 ` Roger Quadros
2023-07-21 9:23 ` Maxime Ripard
2023-07-20 13:33 ` [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl Ravi Gunasekaran
2023-07-20 13:56 ` Roger Quadros
2023-07-20 14:00 ` Nishanth Menon [this message]
2023-07-20 14:12 ` Maxime Ripard
2023-07-20 14:41 ` Roger Quadros
2023-07-20 14:52 ` Nishanth Menon
2023-07-26 9:14 ` Ravi Gunasekaran
2023-07-26 12:49 ` Maxime Ripard
2023-07-27 5:27 ` Ravi Gunasekaran
2023-07-26 12:52 ` Nishanth Menon
2023-07-27 5:36 ` Ravi Gunasekaran
2023-07-27 7:10 ` Roger Quadros
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=20230720140019.nbyum2nh4vmbfpxn@predict \
--to=nm@ti.com \
--cc=javierm@redhat.com \
--cc=joe.hershberger@ni.com \
--cc=mripard@kernel.org \
--cc=pbrobinson@gmail.com \
--cc=r-gunasekaran@ti.com \
--cc=rfried.dev@gmail.com \
--cc=rogerq@kernel.org \
--cc=s-vadapalli@ti.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/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