diff mbox series

[net-next,v2,08/11] of: property: Add device link support for PCS

Message ID 20221103210650.2325784-9-sean.anderson@seco.com
State New
Headers
Series net: pcs: Add support for devices probed in the "usual" manner |

Commit Message

Sean Anderson Nov. 3, 2022, 9:06 p.m. UTC 
  This adds device link support for PCS devices. Both the recommended
pcs-handle and the deprecated pcsphy-handle properties are supported.
This should provide better probe ordering.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>
---

(no changes since v1)

 drivers/of/property.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Rob Herring Nov. 7, 2022, 8:10 p.m. UTC | #1 
On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
> This adds device link support for PCS devices. Both the recommended
> pcs-handle and the deprecated pcsphy-handle properties are supported.
> This should provide better probe ordering.
> 
> Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> ---
> 
> (no changes since v1)
> 
>  drivers/of/property.c | 4 ++++
>  1 file changed, 4 insertions(+)

Seems like no dependency on the rest of the series, so I can take this 
patch?

Rob
Vladimir Oltean Nov. 7, 2022, 8:22 p.m. UTC | #2 
On Mon, Nov 07, 2022 at 02:10:10PM -0600, Rob Herring wrote:
> On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
> > This adds device link support for PCS devices. Both the recommended
> > pcs-handle and the deprecated pcsphy-handle properties are supported.
> > This should provide better probe ordering.
> > 
> > Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> > ---
> > 
> > (no changes since v1)
> > 
> >  drivers/of/property.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> 
> Seems like no dependency on the rest of the series, so I can take this 
> patch?

Is fw_devlink well-behaved these days, so as to not break (forever defer)
the probing of the device having the pcs-handle, if no driver probed on
the referenced PCS? Because the latter is what will happen if no one
picks up Sean's patches to probe PCS devices in the usual device model
way, I think.
Sean Anderson Nov. 7, 2022, 8:50 p.m. UTC | #3 
On 11/7/22 15:22, Vladimir Oltean wrote:
> On Mon, Nov 07, 2022 at 02:10:10PM -0600, Rob Herring wrote:
>> On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
>> > This adds device link support for PCS devices. Both the recommended
>> > pcs-handle and the deprecated pcsphy-handle properties are supported.
>> > This should provide better probe ordering.
>> > 
>> > Signed-off-by: Sean Anderson <sean.anderson@seco.com>
>> > ---
>> > 
>> > (no changes since v1)
>> > 
>> >  drivers/of/property.c | 4 ++++
>> >  1 file changed, 4 insertions(+)
>> 
>> Seems like no dependency on the rest of the series, so I can take this 
>> patch?
> 
> Is fw_devlink well-behaved these days, so as to not break (forever defer)
> the probing of the device having the pcs-handle, if no driver probed on
> the referenced PCS? Because the latter is what will happen if no one
> picks up Sean's patches to probe PCS devices in the usual device model
> way, I think.

Last time [1], Saravana suggested to move this to the end of the series to
avoid such problems. FWIW, I just tried booting a LS1046A with the
following patches applied

01/11 (compatibles) 05/11 (device) 08/11 (link) 09/11 (consumer)
=================== ============== ============ ================
Y                   N              Y            N
Y                   Y              Y            Y
Y                   Y              Y            N
N                   Y              Y            N
N                   N              Y            N

and all interfaces probed each time. So maybe it is safe to pick
this patch.

--Sean

[1] https://lore.kernel.org/netdev/CAGETcx97ijCpVyOqCfnrDuGh+SahQCC-3QrJta5HOscUkJQdEw@mail.gmail.com/
Rob Herring Nov. 7, 2022, 9:36 p.m. UTC | #4 
On Mon, Nov 7, 2022 at 2:50 PM Sean Anderson <sean.anderson@seco.com> wrote:
>
> On 11/7/22 15:22, Vladimir Oltean wrote:
> > On Mon, Nov 07, 2022 at 02:10:10PM -0600, Rob Herring wrote:
> >> On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
> >> > This adds device link support for PCS devices. Both the recommended
> >> > pcs-handle and the deprecated pcsphy-handle properties are supported.
> >> > This should provide better probe ordering.
> >> >
> >> > Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> >> > ---
> >> >
> >> > (no changes since v1)
> >> >
> >> >  drivers/of/property.c | 4 ++++
> >> >  1 file changed, 4 insertions(+)
> >>
> >> Seems like no dependency on the rest of the series, so I can take this
> >> patch?
> >
> > Is fw_devlink well-behaved these days, so as to not break (forever defer)
> > the probing of the device having the pcs-handle, if no driver probed on
> > the referenced PCS? Because the latter is what will happen if no one
> > picks up Sean's patches to probe PCS devices in the usual device model
> > way, I think.
>
> Last time [1], Saravana suggested to move this to the end of the series to
> avoid such problems. FWIW, I just tried booting a LS1046A with the
> following patches applied
>
> 01/11 (compatibles) 05/11 (device) 08/11 (link) 09/11 (consumer)
> =================== ============== ============ ================
> Y                   N              Y            N
> Y                   Y              Y            Y
> Y                   Y              Y            N
> N                   Y              Y            N
> N                   N              Y            N
>
> and all interfaces probed each time. So maybe it is safe to pick
> this patch.

Maybe? Just take it with the rest of the series.

Acked-by: Rob Herring <robh@kernel.org>
Saravana Kannan Nov. 8, 2022, 8:56 p.m. UTC | #5 
On Mon, Nov 7, 2022 at 1:36 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Nov 7, 2022 at 2:50 PM Sean Anderson <sean.anderson@seco.com> wrote:
> >
> > On 11/7/22 15:22, Vladimir Oltean wrote:
> > > On Mon, Nov 07, 2022 at 02:10:10PM -0600, Rob Herring wrote:
> > >> On Thu, Nov 03, 2022 at 05:06:47PM -0400, Sean Anderson wrote:
> > >> > This adds device link support for PCS devices. Both the recommended
> > >> > pcs-handle and the deprecated pcsphy-handle properties are supported.
> > >> > This should provide better probe ordering.
> > >> >
> > >> > Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> > >> > ---
> > >> >
> > >> > (no changes since v1)
> > >> >
> > >> >  drivers/of/property.c | 4 ++++
> > >> >  1 file changed, 4 insertions(+)
> > >>
> > >> Seems like no dependency on the rest of the series, so I can take this
> > >> patch?
> > >
> > > Is fw_devlink well-behaved these days, so as to not break (forever defer)
> > > the probing of the device having the pcs-handle, if no driver probed on
> > > the referenced PCS? Because the latter is what will happen if no one
> > > picks up Sean's patches to probe PCS devices in the usual device model
> > > way, I think.
> >
> > Last time [1], Saravana suggested to move this to the end of the series to
> > avoid such problems. FWIW, I just tried booting a LS1046A with the
> > following patches applied
> >
> > 01/11 (compatibles) 05/11 (device) 08/11 (link) 09/11 (consumer)
> > =================== ============== ============ ================
> > Y                   N              Y            N
> > Y                   Y              Y            Y
> > Y                   Y              Y            N
> > N                   Y              Y            N
> > N                   N              Y            N
> >
> > and all interfaces probed each time. So maybe it is safe to pick
> > this patch.
>
> Maybe? Just take it with the rest of the series.
>
> Acked-by: Rob Herring <robh@kernel.org>

Let's have Vladimir ack this. I'm not sure if it's fully safe yet. I
haven't done the necessary fixes for phy-handle yet, but I don't know
how pcs-handle and pcsphy-handle are used or if none of their uses
will hit the chicken and egg problem that some uses of phy-handle hit.

-Saravana
Vladimir Oltean Nov. 9, 2022, 9:56 p.m. UTC | #6 
On Tue, Nov 08, 2022 at 12:56:15PM -0800, Saravana Kannan wrote:
> > > Last time [1], Saravana suggested to move this to the end of the series to
> > > avoid such problems. FWIW, I just tried booting a LS1046A with the
> > > following patches applied
> > >
> > > 01/11 (compatibles) 05/11 (device) 08/11 (link) 09/11 (consumer)
> > > =================== ============== ============ ================
> > > Y                   N              Y            N
> > > Y                   Y              Y            Y
> > > Y                   Y              Y            N
> > > N                   Y              Y            N
> > > N                   N              Y            N
> > >
> > > and all interfaces probed each time. So maybe it is safe to pick
> > > this patch.
> >
> > Maybe? Just take it with the rest of the series.
> >
> > Acked-by: Rob Herring <robh@kernel.org>
> 
> Let's have Vladimir ack this. I'm not sure if it's fully safe yet. I
> haven't done the necessary fixes for phy-handle yet, but I don't know
> how pcs-handle and pcsphy-handle are used or if none of their uses
> will hit the chicken and egg problem that some uses of phy-handle hit.

I can confirm that on today's net-next, the driver owning the pcs-handle
will probe even if the PCS driver is missing. With the mention that it
only does so after the driver_deferred_probe_timeout, which also in
today's net-next is by default 10 seconds if CONFIG_MODULES=y.
diff mbox series

Patch

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 967f79b59016..ec360a616d17 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1318,6 +1318,8 @@  DEFINE_SIMPLE_PROP(pinctrl6, "pinctrl-6", NULL)
 DEFINE_SIMPLE_PROP(pinctrl7, "pinctrl-7", NULL)
 DEFINE_SIMPLE_PROP(pinctrl8, "pinctrl-8", NULL)
 DEFINE_SIMPLE_PROP(remote_endpoint, "remote-endpoint", NULL)
+DEFINE_SIMPLE_PROP(pcs_handle, "pcs-handle", NULL)
+DEFINE_SIMPLE_PROP(pcsphy_handle, "pcsphy-handle", NULL)
 DEFINE_SIMPLE_PROP(pwms, "pwms", "#pwm-cells")
 DEFINE_SIMPLE_PROP(resets, "resets", "#reset-cells")
 DEFINE_SIMPLE_PROP(leds, "leds", NULL)
@@ -1406,6 +1408,8 @@  static const struct supplier_bindings of_supplier_bindings[] = {
 	{ .parse_prop = parse_pinctrl7, },
 	{ .parse_prop = parse_pinctrl8, },
 	{ .parse_prop = parse_remote_endpoint, .node_not_dev = true, },
+	{ .parse_prop = parse_pcs_handle, },
+	{ .parse_prop = parse_pcsphy_handle, },
 	{ .parse_prop = parse_pwms, },
 	{ .parse_prop = parse_resets, },
 	{ .parse_prop = parse_leds, },