| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <6ebdf08060c245a8a44fc4263eb308cc@HXTBJIDCEMVIW02.hxtcorp.net>
Date: Sat, 10 Nov 2018 09:10:34 +0000
From: "Wang, Dongsheng" <dongsheng.wang@...-semitech.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "timur@...nel.org" <timur@...nel.org>,
"Zheng, Joey" <yu.zheng@...-semitech.com>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] acpi: Add acpi mdio support code
Hi Andrew,
On 2018/11/9 7:23, Andrew Lunn wrote:
> On Thu, Nov 08, 2018 at 03:21:29PM +0800, Wang Dongsheng wrote:
>> Originally I just push "phy-handle" support for ACPI on the QCOM QDF2400
>> platform. After some discussion and following Andrew's advice, I send
>> out with a generic version of ACPI.
>>
>> Current there is no clear documentation about MDIO/PHY for ACPI, so when
>> I reading some documents about ACPI [1], I think we just need to reuse the
>> DT binding in the ACPI.[2]. However, this series of patches are not
>> fully compatible with all contents specified in DT binding.
>>
>> The most important thing about this iseries is link the phy device and
>> fwnode of acpi. Besides, we need to carry out bus scan at the mdio
>> register. Therefore, I am not compatible with more DT binding properties
>> in this series of patches. More support will be in the follow-up patches
>> support, or some people do the support.
>>
>> Example:
>> Based on ACPI doc:
>> Documentation/acpi/dsd/data-node-references.txt
>> Documentation/acpi/dsd/graph.txt
>> With _DSD device properties we can finally do this:
>> Device (MDIO) {
>> Name (_DSD, Package () {
>> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
>> Package () { Package () { "ethernet-phy@0", PHY0 }, }
>> })
>> Name (PHY0, Package() {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () { "reg", 0x0 }, }
>> })
> I don't know much about ACPI. I do know DT. MDIO busses can have
> multiple PHYs on them. Is the following valid to list two PHYs?
>
> Device (MDIO) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> })
> Name (PHY0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x0 }, }
> })
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@10", PHY1 }, }
> })
> Name (PHY1, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x10 }, }
> })
> }
Multiple PHYs example:
Device (MDIO)
{
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "ethernet-phy@0", PHY0 },
Package () { "ethernet-phy@1", PHY1 },
...
...
}
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x0 },
}
})
Name (PHY1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x1 },
}
})
}
Device (MAC0)
{
// _DSD: Device-Specific Data
Name (_DSD, Package (0x02) {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device
Properties for _DSD */,
Package () {
Package () { "phy-handle", Package () { \_SB.MDIO,
"ethernet-phy@0" } },
...
...
}
})
}
Device (MAC1)
{
// _DSD: Device-Specific Data
Name (_DSD, Package (0x02) {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device
Properties for _DSD */,
Package () {
Package () { "phy-handle", Package () { \_SB.MDIO,
"ethernet-phy@1" } },
...
...
}
})
}
>
> An MDIO bus can also have more than PHYs on them. There can be
> Ethernet switches. Broadcom also have some with generic PHY devices on
> them, and other odd things. That means whatever is on an MDIO bus is a
> device in the Linux device model. How does that work? Do we need some
> form Device (PHY) {}?
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b") describes a ACPI data node.
The data node can contain property or pointer.
Let's look at the table I'm using:
Device (MAC1)
{
// _DSD: Device-Specific Data
Name (_DSD, Package (0x02) {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device
Properties for _DSD */,
Package (0x07) {
Package () { "phy-handle", Package () { \_SB.MAC1.MDIO,
"ethernet-phy@1" } },
Package () { "dev-refs", \_SB.MAC0 },
Package () { "refs0-dev", Package () { \_SB.MAC1.MDIO,
"refs@0" } },
Package () { "refs1-dev", Package () { \_SB.MAC1.MDIO,
"refs@1" } },
...
...
}
})
Device (MDIO)
{
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "ethernet-phy@1", PHY1 },
Package () { "refs@0", REF0},
Package () { "refs@1", REF1},
}
})
//Contain a property
Name (PHY1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x1 },
}
})
//Point to a device
Name (REF0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "child-refs-dev", \_SB.MAC0 },
}
})
//Contain a property and a pointer that point to a device
Name (REF1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "property", 0x5 },
Package () { "child-refs-dev", \_SB.MAC0 },
}
})
}
}
> Device (MDIO) {
> Device (PHY) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> })
> Name (PHY0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x0 }, }
> })
> }
> Device (PHY) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@10", PHY1 }, }
> })
> Name (PHY1, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x10 }, }
> })
> Device (SWITCH) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "switch@11", SWITCH0 }, }
> })
> Name (SWITCH0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x11 }, }
> })
> }
Device (MDIO)
{
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "ethernet-phy@1", PHY1 },
Package () { "switch@0", SW00 },
Package () { "switch@1", SW01 },
}
})
//Contain a property
Name (PHY1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x1 },
}
})
Name (SW00, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reg", 0x0 },
}
})
Name (SW01, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "property", 0x5 },
}
})
}
> }
>
> I'm just trying to ensure whatever is defined is flexible enough that
> we really can later support everything which DT does. We have PHYs on
> MDIO busses, inside switches, which are on MDIO busses, which are
> inside Ethernet interfaces, etc.
I think it can be satisfied. See the table I'm using above.
> An MDIO bus is very similar to an i2c bus. How is that described in
> ACPI? Anything we can learn from that?
About the data node, I just read the Kernel Documentation/acpi/dsd/
And others learn from ACPI spec.
Cheers,
Dongsheng
Powered by blists - more mailing lists