On 11/10/22 11:00, Vladimir Oltean wrote:
> On Thu, Nov 10, 2022 at 10:39:30AM -0500, Sean Anderson wrote:
>> On 11/10/22 10:29, Vladimir Oltean wrote:
>> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
>> >> On 11/9/22 17:41, Vladimir Oltean wrote:
>> >> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
>> >> >> Several (later) patches in this series cannot be applied until a stable
>> >> >> release has occured containing the dts updates.
>> >> >
>> >> > New kernels must remain compatible with old device trees.
>> >>
>> >> Well, this binding is not present in older device trees, so it needs to
>> >> be added before these patches can be applied. It also could be possible
>> >> to manually bind the driver using e.g. a helper function (like what is
>> >> done with lynx_pcs_create_on_bus). Of course this would be tricky,
>> >> because we would need to unbind any generic phy driver attached, but
>> >> avoid unbinding an existing Lynx PCS driver.
>> >
>> > If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
>> > these PCS devices, would it be possible to probe them in a generic way
>> > as MDIO devices, if they lack a compatible string?
>>
>> PCS devices are not PHYs, and they do not necessarily conform to the
>> standard PHY registers. Some PCS devices aren't even on MDIO busses (and
>> are instead memory-mapped). To implement this, I think we would need to be
>> very careful. There's also the issue where PCS devices might not be
>> accessable before their mode is selected by the MAC or SerDes.
>
> I don't get where you're going with this. Does any of these arguments
> apply to the Lynx PCS? If not, then what is the problem to using their
> PHY ID register as a mechanism to auto-bind their PCS driver in lack of
> a compatible string?
>
> You already accept a compromise by having lynx_pcs_create_on_bus() be a
> platform-specific way of instantiating a PCS. However, the only thing
> that's platform-specific in the lynx_pcs_create_on_bus() implementation
> is the modalias string:
>
> struct phylink_pcs *lynx_pcs_create_on_bus(struct device *dev,
> struct mii_bus *bus, int addr)
> {
> struct mdio_device *mdio;
> struct phylink_pcs *pcs;
> int err;
>
> mdio = mdio_device_create(bus, addr);
> if (IS_ERR(mdio))
> return ERR_CAST(mdio);
>
> mdio->bus_match = mdio_device_bus_match;
> strncpy(mdio->modalias, "lynx-pcs", sizeof(mdio->modalias)); // <----- this
> err = mdio_device_register(mdio);
> if (err) {
> mdio_device_free(mdio);
> return ERR_PTR(err);
> }
>
> pcs = pcs_get_by_dev(dev, &mdio->dev);
> mdio_device_free(mdio);
> return pcs;
> }
> EXPORT_SYMBOL(lynx_pcs_create_on_bus);
>
> Otherwise it could have been named just as well "pcs_create_on_bus()".
Yes, this could be made generic when we convert other drivers. This
really is just intended for (non-dt) platform devices. It might even be
better to do this with swnodes...
> And this is what I'm saying. What if instead of probing based on
> modalias, this function is made to bind the driver to the device based
> on the PHY ID?
>
> The point about this functionality being generic or not is totally moot,
> since it's the driver who *decides* to call it (and wouldn't do so, if
> it wasn't an MDIO device; see, there's an "mii_bus *bus" argument).
>
> It could work both with LS1028A (enetc, felix, where there is no
> pcs-handle), and it could also work with DPAA1/DPAA2, where there is a
> pcs-handle but there is no compatible string for the PCS.
The crucial difference here is that if we have a pcs-handle property,
then the node it points to will have a device created by the MDIO
subsystem automatically. The reason for this create_on_bus stuff
is to make the process of
1. Create an MDIO bus with no firmware node
2. Create some MDIO devices on that bus
3. Bind them to the correct driver
4. Get the PCS from the driver
less error prone. But for pcs-handle stuff, this should be something
like
1. pcs_find_fwnode()
2. Look up the device for this node
3. Bind it to the correct driver (but taking care that we don't unbind
an existing driver if it is correct).
And then the driver can call pcs_get().
With your suggestion to use PHY_ID, we wouldn't need that. But we would
still need driver involvement, since probing MDIO busses is not safe in
general (since as Andrew mentioned there are things on the busses which
don't have PHY ID registers). And IMO if we need the driver to go "yes,
it's OK to probe this non-phy on this bus," then we might as well do
what I described above. This could be a bus flag, which I think would
work with existing devices.
I'm worried that this could cause regressions and take a while to iron
out. My current approach is fairly conservative and doesn't require
changes to unaffected code.
>> >> As I understand it, kernels must be compatible with device trees from a
>> >> few kernels before and after. There is not a permanent guarantee of
>> >> backwards compatibility (like userspace has) because otherwise we would
>> >> never be able to make internal changes (such as what is done in this
>> >> series). I have suggested deferring these patches until after an LTS
>> >> release as suggested by Rob last time [1].
>> >>
>> >> --Sean
>> >>
>> >> [1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@xxxxxxxxxx/
>> >
>> > Internal changes limit themselves to what doesn't break compatibility
>> > with device trees in circulation. DT bindings are ABI. Compared to the
>> > lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
>> > sorry. The kernel has to continue probing them as Lynx PCS devices even
>> > in lack of a compatible string.
>>
>> I believe the idea here is to allow some leeway when updating so that
>> the kernel and device tree don't have to always be in sync. However, we
>> don't have to support a situation where the kernel is constantly updated
>> but the device tree is never updated. As long as a reasonable effort is
>> made to update (or *not* update) both the kernel and device tree, there
>> is no problem.
>
> I don't think you'd have this opinion if device trees were not
> maintained in the same git tree as the kernel itself. You have to
> consider the case where the device tree blob is provided by a firmware
> (say U-Boot) which you don't update in lockstep with the kernel.
> Has nothing to do with "reasonable" or not.
This is exactly the reason why I am saying that we need to have the
device tree updates in the kernel for a bit before these latter patches
can get merged. Actually, it is probably unlikely that these will make
it into the next LTS release (either 6.0 or 6.1), so these will probably
be in device trees for a year before the kernel starts using them. But
once that is done, we are free to require them.
--Sean
