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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YSUEIriLpcQQYy2k@zn.tnic>
Date:   Tue, 24 Aug 2021 16:37:22 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "Lazar, Lijo" <lijo.lazar@....com>
Cc:     Alex Deucher <alexdeucher@...il.com>,
        Alex Deucher <alexander.deucher@....com>,
        Pratik Vishwakarma <Pratik.Vishwakarma@....com>,
        amd-gfx list <amd-gfx@...ts.freedesktop.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/amdgpu: Fix build with missing
 pm_suspend_target_state module export

On Tue, Aug 24, 2021 at 07:22:46PM +0530, Lazar, Lijo wrote:
> 'pm_suspend_target_state' is only available when CONFIG_PM_SLEEP
> is set/enabled.

pm_suspend_target_state is available only when CONFIG_SUSPEND is
enabled. The extern thing is only a forward declaration.

> OTOH, when both SUSPEND and HIBERNATION are not set,
> PM_SLEEP is not set, so this variable cannot be used.

And it will not be used.

> ../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: In function
> ‘amdgpu_acpi_is_s0ix_active’:
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:1046:11: error:
> ‘pm_suspend_target_state’ undeclared (first use in this function); did you
> mean ‘__KSYM_pm_suspend_target_state’?
>     return pm_suspend_target_state == PM_SUSPEND_TO_IDLE;
>            ^~~~~~~~~~~~~~~~~~~~~~~
>            __KSYM_pm_suspend_target_state

That looks like the .config didn't have CONFIG_SUSPEND enabled.

> Also use shorter IS_ENABLED(CONFIG_foo) notation for checking the
> 2 config symbols.

What shorter notation?

> So it does look like that error can be extracted as well in some
> config.

Yah, when CONFIG_SUSPEND=n.

> Well, now it doesn't seem to be a better one. The original one checked
> both.

I don't see a reason for checking both.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ