Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

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

 



Timur Tabi wrote:

The question, how should adpt->phy.version be initialized on device tree
and ACPI platforms?

The reason why this is confusing is because there are conflicting
perspectives of this "internal PHY".  It both is and is not part of the
EMAC.  It is a separate block in the chip, and can be replaced with
other SGMII blocks, and in the future there will be a "v3" and maybe a
"v4" or who knows what.  In fact, maybe using version numbers is
inappropriate and we'll need to use vendor names or something.

The problem is that the internal PHY has mechanism for
self-identification.  There is no ACPI or device tree node for it. There
is no register you can query to see if it's there or what version it
is.  The MAC part of the EMAC has no knowledge of the PHY part.  The
driver just has to know it's there.

This is why I'm advocating a separate property (DT and ACPI) to identify
the internal PHY.

So we had some internal discussion on this. Different compatible properties for DT are okay, and for ACPI we'll either create a "phy-version" property (DT-like properties are called DSDs in ACPI) or use an HRV (a specific property for the hardware version).

But this speaks to the greater problem of mapping DT compatible strings to ACPI. Like I said, the ACPI equivalent of a compatible string is the HID. But unlike DT, we cannot create new HIDs whenever we feel like it. The process for generating and assigning HIDs is much more involved, and we do have a very limited namespace.

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux