From: Andrew Lunn <andrew@lunn.ch> Date: 2021-11-23 04:12:59
On Tue, Nov 23, 2021 at 09:33:03AM +0800, zhuyinbo wrote:
在 2021/11/22 下午10:07, Andrew Lunn 写道:
On Mon, Nov 22, 2021 at 08:14:57PM +0800, Yinbo Zhu wrote:
After module compilation, module alias mechanism will generate a ugly
mdio modules alias configure if ethernet phy was selected, this patch
is to fixup mdio alias garbled code.
In addition, that ugly alias configure will cause ethernet phy module
doens't match udev, phy module auto-load is fail, but add this patch
that it is well mdio driver alias configure match phy device uevent.
What PHY do you have problems with? What is the PHY id and which
driver should be loaded.
This code has existed a long time, so suddenly saying it is wrong and
changing it needs a good explanation why it is wrong. Being ugly is
not a good reason.
Andrew
Hi Andrew,
Use default mdio configure, After module compilation, mdio alias configure
is following and it doesn't match
the match phy dev(mdio dev) uevent, because the mdio alias configure
"0000000101000001000011111001????" include "?" and
A PHY ID generally break up into 3 parts.
The OUI of the manufacture.
The device.
The revision
The ? means these bits don't matter. Those correspond to the
revision. Generally, a driver can driver any revision of the PHY,
which is why those bits don't matter.
So when a driver probes with the id 00000001010000010000111110010110
we expect user space to find the best match, performing wildcard
expansion. So the ? will match anything.
Since this is worked for a long time, do you have an example where it
is broken? If so, which PHY driver? If it is broken, no driver is
loaded, or the wrong driver is loaded, i expect it is a bug in a
specific driver. And we should fix that bug in the specific driver.
Andrew
On Tue, Nov 23, 2021 at 09:33:03AM +0800, zhuyinbo wrote:
quoted
在 2021/11/22 下午10:07, Andrew Lunn 写道:
On Mon, Nov 22, 2021 at 08:14:57PM +0800, Yinbo Zhu wrote:
After module compilation, module alias mechanism will generate a ugly
mdio modules alias configure if ethernet phy was selected, this patch
is to fixup mdio alias garbled code.
In addition, that ugly alias configure will cause ethernet phy module
doens't match udev, phy module auto-load is fail, but add this patch
that it is well mdio driver alias configure match phy device uevent.
What PHY do you have problems with? What is the PHY id and which
driver should be loaded.
This code has existed a long time, so suddenly saying it is wrong and
changing it needs a good explanation why it is wrong. Being ugly is
not a good reason.
Andrew
Hi Andrew,
Use default mdio configure, After module compilation, mdio alias configure
is following and it doesn't match
the match phy dev(mdio dev) uevent, because the mdio alias configure
"0000000101000001000011111001????" include "?" and
A PHY ID generally break up into 3 parts.
The OUI of the manufacture.
The device.
The revision
The ? means these bits don't matter. Those correspond to the
revision. Generally, a driver can driver any revision of the PHY,
which is why those bits don't matter.
So when a driver probes with the id 00000001010000010000111110010110
we expect user space to find the best match, performing wildcard
expansion. So the ? will match anything.
Since this is worked for a long time, do you have an example where it
is broken? If so, which PHY driver? If it is broken, no driver is
loaded, or the wrong driver is loaded, i expect it is a bug in a
specific driver. And we should fix that bug in the specific driver.
Andrew
Hi Andrew,
The string like "0000000101000001000011111001????" dont't match any mdio driver, and i said it include "? that "?" doesn't match any driver, in addition that include Binary digit
like "0000000101000001000011111001", that binary digit doesn't match any driver, that should use Hexadecimal for phy id, and I test on some platform, not only a platform, it isn't some
specifi driver issue, it is gerneral issue. please you note. that phy driver match phy device must use whole string "MODALIAS=xxxyyzz", not partial match.
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-11-23 13:54:36
quoted
quoted
Hi Andrew,
Use default mdio configure, After module compilation, mdio alias configure
is following and it doesn't match
the match phy dev(mdio dev) uevent, because the mdio alias configure
"0000000101000001000011111001????" include "?" and
A PHY ID generally break up into 3 parts.
The OUI of the manufacture.
The device.
The revision
The ? means these bits don't matter. Those correspond to the
revision. Generally, a driver can driver any revision of the PHY,
which is why those bits don't matter.
So when a driver probes with the id 00000001010000010000111110010110
we expect user space to find the best match, performing wildcard
expansion. So the ? will match anything.
Since this is worked for a long time, do you have an example where it
is broken? If so, which PHY driver? If it is broken, no driver is
loaded, or the wrong driver is loaded, i expect it is a bug in a
specific driver. And we should fix that bug in the specific driver.
Andrew
Hi Andrew,
The string like "0000000101000001000011111001????" dont't match any mdio driver, and i said it include "? that "?" doesn't match any driver, in addition that include Binary digit
like "0000000101000001000011111001", that binary digit doesn't match any driver, that should use Hexadecimal for phy id, and I test on some platform, not only a platform, it isn't some
specifi driver issue, it is gerneral issue. please you note. that phy driver match phy device must use whole string "MODALIAS=xxxyyzz", not partial match.
Please give a concrete example. Show us udev logs of it not working,
it failing to find a match.
Andrew
Hi Andrew,
Use default mdio configure, After module compilation, mdio alias configure
is following and it doesn't match
the match phy dev(mdio dev) uevent, because the mdio alias configure
"0000000101000001000011111001????" include "?" and
A PHY ID generally break up into 3 parts.
The OUI of the manufacture.
The device.
The revision
The ? means these bits don't matter. Those correspond to the
revision. Generally, a driver can driver any revision of the PHY,
which is why those bits don't matter.
So when a driver probes with the id 00000001010000010000111110010110
we expect user space to find the best match, performing wildcard
expansion. So the ? will match anything.
Since this is worked for a long time, do you have an example where it
is broken? If so, which PHY driver? If it is broken, no driver is
loaded, or the wrong driver is loaded, i expect it is a bug in a
specific driver. And we should fix that bug in the specific driver.
Andrew
Hi Andrew,
The string like "0000000101000001000011111001????" dont't match any mdio driver, and i said it include "? that "?" doesn't match any driver, in addition that include Binary digit
like "0000000101000001000011111001", that binary digit doesn't match any driver, that should use Hexadecimal for phy id, and I test on some platform, not only a platform, it isn't some
specifi driver issue, it is gerneral issue. please you note. that phy driver match phy device must use whole string "MODALIAS=xxxyyzz", not partial match.
Please give a concrete example. Show us udev logs of it not working,
it failing to find a match.
Andrew
Hi Andrew,
I don't get udev log, but I can find that phy module wether be load
by lsmod ways, and you can try
it in any a phy deice and in any arch platform. in addition, I
will send v2 version patch that need consider
some phy device doesn't follow IEEE802.3 protocol strictly and
doesn't read phy id from phy register successfully,
please review.
Brs,
Yinbo Zhu.
From: "Russell King (Oracle)" <linux@armlinux.org.uk> Date: 2021-11-26 10:59:42
On Fri, Nov 26, 2021 at 05:34:36PM +0800, zhuyinbo wrote:
Hi Andrew,
I don't get udev log, but I can find that phy module wether be load by
lsmod ways, and you can try
it in any a phy deice and in any arch platform. in addition, I will
send v2 version patch that need consider
some phy device doesn't follow IEEE802.3 protocol strictly and doesn't
read phy id from phy register successfully,
I'm not sure I understand what you've said above correctly.
You seem to be saying that the module has been loaded (it appears in
lsmod) but it doesn't get bound to the PHY device? If that is correct,
there isn't a problem with the modalias, but there's something wrong
in the driver matching.
The last sentence seems to point at a completely different problem -
one concerning an inability to correctly read the PHY ID from the PHY
itself. If that's the case, then that isn't a problem with modalias,
it's a problem with reading the PHY ID.
The existing modalias scheme doesn't care about the format of the ID.
Normally the least significant four bits are the PHY revision, but that
doesn't always hold. Let's take a couple of examples:
The PHY ID for a Marvell PHY is 0x01410dd1. This will expand to:
mdio:00000001010000010000110111010001
The kernel modalias tables will be generated from an ID of 0x01410dd0
with a mask of 0xfffffff0. The mask means "ignore the bottom four bits".
So, we end up with this in the module's alias table:
mdio:0000000101000001000011011101????
udev knows that "?" is a wildcard. Consequently the above matches.
On an Atheros PHY, this has an ID value of 0x004dd072. The driver also
has a value of 0x004dd072 and a mask of 0xffffffef, meaning bit 4 is
ignored:
mdio:00000000010011011101000001110010 <= PHY ID
mdio:000000000100110111010000011?0010 <= module alias table
This will also match a PHY with id 0x004dd062.
mdio:00000000010011011101000001100010 <= PHY ID
The current modalias approach is flexible. Publishing the raw hex ID
and having an exact match is too inflexible for phylib and will lead to
users reporting regressions.
Please show us:
1) the contents of the phy_id file for the PHY you are having problems
with. This can be found in /sys/bus/mdio_bus/devices/.../phy_id
2) which driver in the kernel is a problem.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!