sd-device: add support for second modalias#18163
Closed
khfeng wants to merge 1 commit intosystemd:mainfrom
Closed
Conversation
bluca
reviewed
Jan 8, 2021
ACPI device can have two modaliases if it has DT namespace [1]. They are created by kernel function __acpi_device_uevent_modalias(): $ cat /sys/bus/platform/devices/AHC1EC0\:00/uevent MODALIAS=acpi:AHC1EC0: MODALIAS=of:NadecTCadvantech,ahc1ec0 Because of the nature of hashmap, the second modalias always replaces the first modalias, preventing driver loading for first modalias. So use a different key, MODALIAS1, for the second modalias to solve the issue. [1] https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
khfeng
force-pushed
the
second-modalias
branch
from
ff3f4a7 to
30e283c
Compare
Member
|
I am sorry but the event env block from the kernel is no longer suitable as env block? Thats just broken. Is there any other kernel subsystem that passes uevent blocks to userspace with non-unique keys? This is a corruption of the kernel interface and should be fixed in kernel space, not worked around in userspace |
Member
|
Hmm, @gregkh you are the Linux device model maintainer, any chance you can weigh in? are uevent env blocks no longer supposed to contain only unique keys? People generally assume they consist of unique keys only. If they aren#t this would break a ton of userspace. @khfeng why doesn't the kernel expose the second modalias line under a unique key name? i.e. |
Contributor
Author
Seems like only ACPI subsystem can have non-unique keys.
I can't find any guarantee in the kernel doc or API states that the key in uevent file is and has to be unique. So while I do understand it's not desirable, I don't think this is a workaround. |
Contributor
Author
Contributor
|
I'm sorry, but I don't understand the problem here. What does not have "unique keys"? What is a "key" here? Drivers can have loads of MODALIAS entries, always have, what has changed to cause a problem here? |
Contributor
Author
|
@gregkh some ACPI device can have DT compatible ID [1]. Kernel exposes them as two The problem is, systemd-udevd first stores key When executing rule This PR is an attempt to make sure the |
Member
The problem is that there are now Maybe it never was declared that keys in |
Member
|
@khfeng the offending devices in sysfs, what do they actually export in the |
Contributor
|
Ah, a modalias of a device, not a driver, sorry, was confused here. Odd, but as drivers can handle multiple MODALIAS values today, I don't see why a device can't do the same thing so userspace should handle this. And yes @poettering , I don't think we ever declared that keys in uevent files had to be unique, sorry. If we had done that, then yes, this would be a kernel bug. But they really aren't "keys" but rather, "attributes", or some other term that is being used to describe something that you might have multiple of. |
Member
|
@gregkh well, but no userspace app is prepared for that... given it's not documented you might not break documented API with that, but certainly assumed API all over the place. If you allow this suddenly, then you basically have to go through all userspace and fix that up. And what for? Why not just make official what everybody so far assumed, and say that @gregkh what is the |
Contributor
Author
@poettering yes, two lines for two modaliases: |
Member
|
also, this means old udev and userspace won't work correctly on new kernels anymore. We'd have to make a public announcement about that again, and that people need to update. I mean, I am not actually opposed to breaking API if the old logic was really broken. But I don't see thta here. The assumption that keys in How do you thin udev rules should work if they aren't unique btw? i.e. if someone has I mean, by insisting that uevent keys don't have to be unique you are not just breaking udev code, but actually udev semantics in a quite drastic way. |
Contributor
|
While I would like to say this is a "bug", it has been this way for ACPI devices since 2007, when the ACPI bus first got support for MODALIAS entries. So nothing has "changed" in the kernel related to this, sorry. |
Contributor
|
And if you all want to change this, and really, I think it should be changed, please contact the ACPI kernel developers and work with them to figure out how to properly support their multiple lists of aliases for devices. Feel free to cc: me on the emails, thanks! |
Contributor
Author
|
It was introduced by commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present"), which was included in Linux v4.0. |
Contributor
Author
|
Anyway, let me start a discussion on mailing list. |
Contributor
|
Oops, good catch, yes, that's the right commit. from 2015, a bit newer :) |
Member
|
i am irritated they did the change without checking whether it actually works, and noone noticed... |
Contributor
Author
|
To be fair, these kind of devices (supports both ACPI and Device Tree) are more likely to be used on embedded systems. AFAIK most embedded systems don't use systemd. So if we are to change the kernel side of thing, we need to be extra careful. |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 20, 2021
Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in uevent file if conditions are met. This breaks systemd-udevd, which assumes each "key" in uevent file is unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load driver for the first MODALIAS. Right now it doesn't seem to have any user relies on the second MODALIAS, so change it to OF_MODALIAS to workaround the issue. Reference: systemd/systemd#18163 Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 20, 2021
Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in uevent file if conditions are met. This breaks systemd-udevd, which assumes each "key" in uevent file is unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load driver for the first MODALIAS. Right now it doesn't seem to have any user relies on the second MODALIAS, so change it to OF_MODALIAS to workaround the issue. Reference: systemd/systemd#18163 Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Cc: AceLan Kao <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Greg Kroah-Hartman <[email protected]>, Cc: Mika Westerberg <[email protected]>, Cc: Andy Shevchenko <[email protected]> Signed-off-by: Kai-Heng Feng <[email protected]>
Contributor
Author
|
End up stripping away the ACPI modalias and at kernel side. Still, thanks for reviewing! |
Member
|
That's great news, thanks for following up! |
woodsts
pushed a commit
to woodsts/linux-stable
that referenced
this pull request
Feb 3, 2021
commit 36af2d5 upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
woodsts
pushed a commit
to woodsts/linux-stable
that referenced
this pull request
Feb 3, 2021
commit 36af2d5 upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Whissi
pushed a commit
to Whissi/linux-stable
that referenced
this pull request
Feb 3, 2021
commit 36af2d5 upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Whissi
pushed a commit
to Whissi/linux-stable
that referenced
this pull request
Feb 3, 2021
commit 36af2d5 upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
evdenis
pushed a commit
to evdenis/linux-floppy
that referenced
this pull request
Feb 4, 2021
Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
Claymore1297
pushed a commit
to Claymore1297/kernel_oneplus_sm8150
that referenced
this pull request
Feb 4, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
miraclestars
pushed a commit
to miraclestars/android_kernel_samsung_sm8250
that referenced
this pull request
Feb 4, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream.
Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when
"compatible" is present") may create two "MODALIAS=" in one uevent
file if specific conditions are met.
This breaks systemd-udevd, which assumes each "key" in one uevent file
to be unique. The internal implementation of systemd-udevd overwrites
the first MODALIAS with the second one, so its kmod rule doesn't load
the driver for the first MODALIAS.
So if both the ACPI modalias and the OF modalias are present, use the
latter to ensure that there will be only one MODALIAS.
Link: systemd/systemd#18163
Suggested-by: Mika Westerberg <[email protected]>
Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
Signed-off-by: Kai-Heng Feng <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Cc: 4.1+ <[email protected]> # 4.1+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
whyredfire
pushed a commit
to whyredfire/android_kernel_xiaomi_ginkgo
that referenced
this pull request
Feb 4, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
melles1991
pushed a commit
to CraftRom/Chidori-Kernel_onclite
that referenced
this pull request
Feb 4, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
freeza-inc
pushed a commit
to freeza-inc/bm-galaxy-s20-ultra-snap-r
that referenced
this pull request
Feb 4, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream.
Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when
"compatible" is present") may create two "MODALIAS=" in one uevent
file if specific conditions are met.
This breaks systemd-udevd, which assumes each "key" in one uevent file
to be unique. The internal implementation of systemd-udevd overwrites
the first MODALIAS with the second one, so its kmod rule doesn't load
the driver for the first MODALIAS.
So if both the ACPI modalias and the OF modalias are present, use the
latter to ensure that there will be only one MODALIAS.
Link: systemd/systemd#18163
Suggested-by: Mika Westerberg <[email protected]>
Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
Signed-off-by: Kai-Heng Feng <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Cc: 4.1+ <[email protected]> # 4.1+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Blacksuan19
pushed a commit
to Blacksuan19/kernel_dark_ages_phoenix
that referenced
this pull request
Feb 4, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Blacksuan19
pushed a commit
to Blacksuan19/kernel_dark_ages_vince
that referenced
this pull request
Feb 4, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
DillerOFire
pushed a commit
to Project-Fluid-Devices/kernel_xiaomi_sdm660
that referenced
this pull request
Feb 5, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
SudhakarJha
pushed a commit
to SudhakarJha/android_kernel_xiaomi_msm8953
that referenced
this pull request
Feb 5, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
kimocoder
pushed a commit
to kimocoder/android_kernel_oneplus_oneplus6
that referenced
this pull request
Feb 6, 2021
commit 36af2d5 upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
kimocoder
pushed a commit
to kimocoder/android_kernel_oneplus_oneplus6
that referenced
this pull request
Feb 6, 2021
commit 36af2d5 upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Claymore1297
pushed a commit
to Claymore1297/kernel_oneplus_sdm845
that referenced
this pull request
Feb 7, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
SGCMarkus
pushed a commit
to SGCMarkus/android_kernel_lge_sm8150
that referenced
this pull request
Feb 7, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
3EleVen
pushed a commit
to 3EleVen/kernel_xiaomi_mido
that referenced
this pull request
Feb 7, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
krazey
pushed a commit
to krazey/android_kernel_samsung_universal9810
that referenced
this pull request
Feb 10, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
it-is-a-robot
pushed a commit
to openeuler-mirror/kernel
that referenced
this pull request
Feb 11, 2021
commit 36af2d5 upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Yang Yingliang <[email protected]>
Jimbo77
pushed a commit
to Jimbo77/Jimbok_common_sm8250-R
that referenced
this pull request
Feb 11, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
bananafunction
pushed a commit
to bananafunction/android_kernel_sony_msm8998
that referenced
this pull request
Feb 11, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
bananafunction
pushed a commit
to bananafunction/android_kernel_sony_msm8998
that referenced
this pull request
Feb 11, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
javashin
pushed a commit
to javashin/android_kernel_motorola_sdm632
that referenced
this pull request
Feb 11, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Jimbo77
pushed a commit
to Jimbo77/Jimbok_common_sm8250-R
that referenced
this pull request
Feb 11, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this pull request
Feb 13, 2021
Source: Kernel.org MR: 108725 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y ChangeID: 93603a27fc31f3161bfe30c867c07b407e187e35 Description: commit 36af2d5 upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Armin Kuster <[email protected]>
rzlamrr
pushed a commit
to silont-project/kernel_xiaomi_ginkgo
that referenced
this pull request
Feb 13, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. Commit 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: systemd/systemd#18163 Suggested-by: Mika Westerberg <[email protected]> Fixes: 8765c5b ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Cc: 4.1+ <[email protected]> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: rzlamrr <[email protected]>
d4rk-lucif3r
pushed a commit
to d4rk-lucif3r/LuciferKernel
that referenced
this pull request
Feb 16, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream.
Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when
"compatible" is present") may create two "MODALIAS=" in one uevent
file if specific conditions are met.
This breaks systemd-udevd, which assumes each "key" in one uevent file
to be unique. The internal implementation of systemd-udevd overwrites
the first MODALIAS with the second one, so its kmod rule doesn't load
the driver for the first MODALIAS.
So if both the ACPI modalias and the OF modalias are present, use the
latter to ensure that there will be only one MODALIAS.
Link: systemd/systemd#18163
Suggested-by: Mika Westerberg <[email protected]>
Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
Signed-off-by: Kai-Heng Feng <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Cc: 4.1+ <[email protected]> # 4.1+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Arsh Anwar <[email protected]>
d4rk-lucif3r
pushed a commit
to d4rk-lucif3r/LuciferKernel
that referenced
this pull request
Feb 16, 2021
commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream.
Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when
"compatible" is present") may create two "MODALIAS=" in one uevent
file if specific conditions are met.
This breaks systemd-udevd, which assumes each "key" in one uevent file
to be unique. The internal implementation of systemd-udevd overwrites
the first MODALIAS with the second one, so its kmod rule doesn't load
the driver for the first MODALIAS.
So if both the ACPI modalias and the OF modalias are present, use the
latter to ensure that there will be only one MODALIAS.
Link: systemd/systemd#18163
Suggested-by: Mika Westerberg <[email protected]>
Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
Signed-off-by: Kai-Heng Feng <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Cc: 4.1+ <[email protected]> # 4.1+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Arsh Anwar <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ACPI device can have two modaliases if it has DT namespace [1]. They are
created by kernel function __acpi_device_uevent_modalias():
$ cat /sys/bus/platform/devices/AHC1EC0:00/uevent
MODALIAS=acpi:AHC1EC0:
MODALIAS=of:NadecTCadvantech,ahc1ec0
Because of the nature of hashmap, the second modalias always replaces
the first modalias, preventing driver loading for first modalias.
So use a different key, MODALIAS1, for the second modalias to solve
the issue.
[1] https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id