search for: nouveau_evaluate_mux_dsm

This is especially true when variables or functions are just called dsm without precising the v1. Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 64 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +-- drm/nouveau/nouveau_drm.c | 4 +-- drm/nouveau/nouveau_vga.c | 10 ++++---- 4 files changed, 41 insertions(+), 41

This is especially true when variables or functions are just called dsm without specifying the v1. Changes since v1: * Fix typo in commit explanation * Change has_dsm to has_mux in nouveau_dsm_detect Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 72 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +--

...ENODEV; >> >> should this be AE_ERROR? > > I would say no, because ACPI was parsed correctly, just that we didn't it give the correct arguments, or rather, the _DSM we tested isn't an Optimus one, but it could a mux or gmux. And I used ENODEV as it is the value returned by nouveau_evaluate_mux_dsm in the same context. Hm ok. It just seemed odd to be returning AE_* in one context, and -ENODEV in another context -- they're different types of errors. However if the caller handles it, I guess it's OK... I haven't looked at the API in depth. > >> >>> + } else...

On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: > Most _DSM will return an integer value of 0x80000002 when given an unknown > UUID, revision ID or function ID. Checking locally allows us to differentiate > that case from other ACPI errors, and to not report a "failed to evaluate _DSM" > if 0x80000002 is returned which was confusing.