| Message ID | 20221103210650.2325784-9-sean.anderson@seco.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | net: pcs: Add support for devices probed in the "usual" manner | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | fail | build log |
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
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.
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/
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>
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
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 --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, },
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(+)