On 7/11/24 15:44, Nícolas F. R. A. Prado wrote:
On Thu, Jul 11, 2024 at 01:53:37PM -0600, Shuah Khan wrote:
On 7/10/24 15:49, Shuah Khan wrote:
On 7/10/24 07:11, Greg Kroah-Hartman wrote:
On Fri, Jul 05, 2024 at 07:29:53PM -0400, Nícolas F. R. A. Prado wrote:
Log errors are the most widely used mechanism for reporting issues in the kernel. When an error is logged using the device helpers, eg dev_err(), it gets metadata attached that identifies the subsystem and device where the message is coming from. This series makes use of that metadata in a new test to report which devices logged errors.
The first two patches move a test and a helper script to keep things organized before this new test is added in the third patch.
It is expected that there might be many false-positive error messages throughout the drivers code which will be reported by this test. By having this test in the first place and working through the results we can address those occurrences by adjusting the loglevel of the messages that turn out to not be real errors that require the user's attention. It will also motivate additional error messages to be introduced in the code to detect real errors where they turn out to be missing, since it will be possible to detect said issues automatically.
As an example, below you can see the test result for mt8192-asurada-spherion. The single standing issue has been investigated and will be addressed in an EC firmware update [1]:
TAP version 13 1..1 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `model_name' property: -6 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `energy_full_design' property: -6 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5 not ok 1 +power_supply:sbs-8-000b Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
[1] https://lore.kernel.org/all/cf4d8131-4b63-4c7a-9f27-5a0847c656c4@notapiano
Signed-off-by: Nícolas F. R. A. Prado nfraprado@collabora.com
Acked-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
Is this dependent on a linux-next?
Didn't apply to linux-kselftest next.
I tried applying these on top of linux-kselftest next which is at Linux 6.10-rc7 + other patches.
I am not sure what is wrong - first patch applies and the second and third don't.
git am fails and manual patch application worked for 2/3, same thing with 3.3 - these should apply cleanly since they don't have obvious conflicts.
Please clean this up and send me updated series adding Greg's ack.
Oh, now I see what happened. I recently sent another series that touches the same file (tools/testing/selftests/devices/test_discoverable_devices.py): "kselftest: devices: Allow running test on more platforms" https://lore.kernel.org/all/20240613-kselftest-discoverable-probe-mt8195-kci...
That was already merged through the usb tree, and is present on next (on which I based this series).
In this case I imagine it's best if this series gets picked through the usb tree, right? Even if I rebase on kselftest's next, there will be conflicts.
I see. No problem. It can go through usb tree
Acked-by: Shuah Khan skhan@linuxfoundation.org
thanks, -- Shuah