On 29/09/2020 14:43, Andrew Lunn wrote:
On Tue, Sep 29, 2020 at 10:47:03AM +0530, Calvin Johnson wrote:
Hi Grant,
On Fri, Sep 25, 2020 at 02:34:21PM +0100, Grant Likely wrote:
+DSDT entry for MDIO node
+------------------------
+a) Silicon Component
+--------------------
+ Scope(_SB)
+ {
+ Device(MDI0) {
+ Name(_HID, "NXP0006")
+ Name(_CCA, 1)
+ Name(_UID, 0)
+ Name(_CRS, ResourceTemplate() {
+ Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
+ Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
+ {
+ MDI0_IT
+ }
+ }) // end of _CRS for MDI0
+ Name (_DSD, Package () {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package () {
+ Package () {"little-endian", 1},
+ }
Adopting the 'little-endian' property here makes little sense. This looks
like legacy from old PowerPC DT platforms that doesn't belong here. I would
drop this bit.
I'm unable to drop this as the xgmac_mdio driver relies on this variable to
change the io access to little-endian. Default is big-endian.
Please see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/freescale/xgmac_mdio.c?h=v5.9-rc7#n55
Hi Calvin
Are we talking about the bus controller endiannes, or the CPU
endianness?
This is orthogonal to the MDIO bus issue. This is a legacy of the xgmac
IP block originating in PowerPC platforms with a big-endian bus wiring.
The flag here tells the driver to use little endian when accessing MMIO
registers.
If we are talking about the CPU endiannes, are you plan on supporting
any big endian platforms using ACPI? If not, just hard code it.
Newbie ACPI question: Does ACPI even support big endian CPUs, given
its x86 origins? >
If this is the bus controller endianness, are all the SoCs you plan to
support via ACPI the same endianness? If they are all the same, you
can hard code it.
I would agree. The ACPI and DT probe paths are different. It would be
easy to automatically set the little-endian flag by default when xgmac
is described via ACPI.
g.
