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: <94F2FBAB4432B54E8AACC7DFDE6C92E37D2BEAE4@ORSMSX112.amr.corp.intel.com>
Date:	Fri, 17 Apr 2015 03:48:12 +0000
From:	"Moore, Robert" <robert.moore@...el.com>
To:	"Zheng, Lv" <lv.zheng@...el.com>,
	Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>,
	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>
CC:	"lenb@...nel.org" <lenb@...nel.org>,
	"hdegoede@...hat.com" <hdegoede@...hat.com>,
	"tj@...nel.org" <tj@...nel.org>,
	"mjg59@...f.ucam.org" <mjg59@...f.ucam.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"al.stone@...aro.org" <al.stone@...aro.org>,
	"graeme.gregory@...aro.org" <graeme.gregory@...aro.org>,
	"leo.duran@....com" <leo.duran@....com>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>
Subject: RE: [V8 PATCH 1/3] ACPICA: Add ACPI _CLS processing

Yes, this is a good question that we should think about.
Bob


> -----Original Message-----
> From: Zheng, Lv
> Sent: Thursday, April 16, 2015 6:46 PM
> To: Suravee Suthikulpanit; rjw@...ysocki.net;
> mika.westerberg@...ux.intel.com; Moore, Robert; hanjun.guo@...aro.org
> Cc: lenb@...nel.org; hdegoede@...hat.com; tj@...nel.org;
> mjg59@...f.ucam.org; gregkh@...uxfoundation.org; al.stone@...aro.org;
> graeme.gregory@...aro.org; leo.duran@....com; linux-ide@...r.kernel.org;
> linux-acpi@...r.kernel.org; linux-kernel@...r.kernel.org; linaro-
> acpi@...ts.linaro.org
> Subject: RE: [V8 PATCH 1/3] ACPICA: Add ACPI _CLS processing
> 
> Before back porting this to ACPICA, let me ask one simple question.
> According to the spec, the _CLS is optional and PCI specific.
> So why should we implement it in ACPICA core not OSPM specific modules?
> If this need to be implemented in ACPICA, then what about the following
> device identification objects?
> _DDN, _HRV, _MLS, _PLD, _STR, _SUN
> 
> Thanks and best regards
> -Lv
> 
> > From: Suravee Suthikulpanit [mailto:Suravee.Suthikulpanit@....com]
> > Sent: Tuesday, March 31, 2015 5:56 AM
> >
> > ACPI Device configuration often contain _CLS object to suppy
> > PCI-defined class code for the device. This patch introduces logic to
> > process the _CLS object.
> >
> > Acked-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
> > Reviewed-by: Hanjun Guo <hanjun.guo@...aro.org>
> > Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>
> > ---
> >  drivers/acpi/acpica/acutils.h  |  3 ++
> > drivers/acpi/acpica/nsxfname.c | 21 ++++++++++--
> >  drivers/acpi/acpica/utids.c    | 73
> ++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 95 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/acutils.h
> > b/drivers/acpi/acpica/acutils.h index c2f03e8..2aef850 100644
> > --- a/drivers/acpi/acpica/acutils.h
> > +++ b/drivers/acpi/acpica/acutils.h
> > @@ -430,6 +430,9 @@ acpi_status
> >  acpi_ut_execute_CID(struct acpi_namespace_node *device_node,
> >  		    struct acpi_pnp_device_id_list ** return_cid_list);
> >
> > +acpi_status
> > +acpi_ut_execute_CLS(struct acpi_namespace_node *device_node,
> > +		    struct acpi_pnp_device_id **return_id);
> >  /*
> >   * utlock - reader/writer locks
> >   */
> > diff --git a/drivers/acpi/acpica/nsxfname.c
> > b/drivers/acpi/acpica/nsxfname.c index d66c326..590ef06 100644
> > --- a/drivers/acpi/acpica/nsxfname.c
> > +++ b/drivers/acpi/acpica/nsxfname.c
> > @@ -276,11 +276,12 @@ acpi_get_object_info(acpi_handle handle,
> >  	struct acpi_pnp_device_id *hid = NULL;
> >  	struct acpi_pnp_device_id *uid = NULL;
> >  	struct acpi_pnp_device_id *sub = NULL;
> > +	struct acpi_pnp_device_id *cls = NULL;
> >  	char *next_id_string;
> >  	acpi_object_type type;
> >  	acpi_name name;
> >  	u8 param_count = 0;
> > -	u8 valid = 0;
> > +	u16 valid = 0;
> >  	u32 info_size;
> >  	u32 i;
> >  	acpi_status status;
> > @@ -320,7 +321,7 @@ acpi_get_object_info(acpi_handle handle,
> >  	if ((type == ACPI_TYPE_DEVICE) || (type == ACPI_TYPE_PROCESSOR)) {
> >  		/*
> >  		 * Get extra info for ACPI Device/Processor objects only:
> > -		 * Run the Device _HID, _UID, _SUB, and _CID methods.
> > +		 * Run the Device _HID, _UID, _SUB, _CID and _CLS methods.
> >  		 *
> >  		 * Note: none of these methods are required, so they may or
> may
> >  		 * not be present for this device. The Info->Valid bitfield is
> used
> > @@ -351,6 +352,14 @@ acpi_get_object_info(acpi_handle handle,
> >  			valid |= ACPI_VALID_SUB;
> >  		}
> >
> > +		/* Execute the Device._CLS method */
> > +
> > +		status = acpi_ut_execute_CLS(node, &cls);
> > +		if (ACPI_SUCCESS(status)) {
> > +			info_size += cls->length;
> > +			valid |= ACPI_VALID_CLS;
> > +		}
> > +
> >  		/* Execute the Device._CID method */
> >
> >  		status = acpi_ut_execute_CID(node, &cid_list); @@ -468,6
> +477,11 @@
> > acpi_get_object_info(acpi_handle handle,
> >  							sub, next_id_string);
> >  	}
> >
> > +	if (cls) {
> > +		next_id_string = acpi_ns_copy_device_id(&info->cls,
> > +							cls, next_id_string);
> > +	}
> > +
> >  	if (cid_list) {
> >  		info->compatible_id_list.count = cid_list->count;
> >  		info->compatible_id_list.list_size = cid_list->list_size; @@ -
> 507,6
> > +521,9 @@ cleanup:
> >  	if (sub) {
> >  		ACPI_FREE(sub);
> >  	}
> > +	if (cls) {
> > +		ACPI_FREE(cls);
> > +	}
> >  	if (cid_list) {
> >  		ACPI_FREE(cid_list);
> >  	}
> > diff --git a/drivers/acpi/acpica/utids.c b/drivers/acpi/acpica/utids.c
> > index 27431cf..9745065 100644
> > --- a/drivers/acpi/acpica/utids.c
> > +++ b/drivers/acpi/acpica/utids.c
> > @@ -416,3 +416,76 @@ cleanup:
> >  	acpi_ut_remove_reference(obj_desc);
> >  	return_ACPI_STATUS(status);
> >  }
> > +
> > +/********************************************************************
> > +***********
> > + *
> > + * FUNCTION:    acpi_ut_execute_CLS
> > + *
> > + * PARAMETERS:  device_node         - Node for the device
> > + *              return_id           - Where the string UID is returned
> > + *
> > + * RETURN:      Status
> > + *
> > + * DESCRIPTION: Executes the _CLS control method that returns PCI-
> defined
> > + *              class code of the device. The ACPI spec define _CLS as
> a
> > + *              package with three integers. The returned string has
> format:
> > + *
> > + *                      "bbsspp"
> > + *              where:
> > + *                  bb = Base-class code
> > + *                  ss = Sub-class code
> > + *                  pp = Programming Interface code
> > + *
> > +
> > +*********************************************************************
> > +*********/
> > +
> > +acpi_status
> > +acpi_ut_execute_CLS(struct acpi_namespace_node *device_node,
> > +		    struct acpi_pnp_device_id **return_id) {
> > +	struct acpi_pnp_device_id *cls;
> > +	union acpi_operand_object *obj_desc;
> > +	union acpi_operand_object **cls_objects;
> > +	acpi_status status;
> > +
> > +	ACPI_FUNCTION_TRACE(ut_execute_CLS);
> > +	status = acpi_ut_evaluate_object(device_node, METHOD_NAME__CLS,
> > +					 ACPI_BTYPE_PACKAGE, &obj_desc);
> > +	if (ACPI_FAILURE(status))
> > +		return_ACPI_STATUS(status);
> > +
> > +	cls_objects = obj_desc->package.elements;
> > +
> > +	if (obj_desc->common.type == ACPI_TYPE_PACKAGE &&
> > +	    obj_desc->package.count == 3 &&
> > +	    cls_objects[0]->common.type == ACPI_TYPE_INTEGER &&
> > +	    cls_objects[1]->common.type == ACPI_TYPE_INTEGER &&
> > +	    cls_objects[2]->common.type == ACPI_TYPE_INTEGER) {
> > +
> > +		/* Allocate a buffer for the CLS */
> > +		cls = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_pnp_device_id) +
> > +					 (acpi_size) 7);
> > +		if (!cls) {
> > +			status = AE_NO_MEMORY;
> > +			goto cleanup;
> > +		}
> > +
> > +		cls->string =
> > +		    ACPI_ADD_PTR(char, cls, sizeof(struct
> acpi_pnp_device_id));
> > +
> > +		sprintf(cls->string, "%02x%02x%02x",
> > +			(u8)ACPI_TO_INTEGER(cls_objects[0]->integer.value),
> > +			(u8)ACPI_TO_INTEGER(cls_objects[1]->integer.value),
> > +			(u8)ACPI_TO_INTEGER(cls_objects[2]->integer.value));
> > +		cls->length = 7;
> > +		*return_id = cls;
> > +	} else {
> > +		status = AE_AML_OPERAND_TYPE;
> > +	}
> > +
> > +cleanup:
> > +
> > +	/* On exit, we must delete the return object */
> > +
> > +	acpi_ut_remove_reference(obj_desc);
> > +	return_ACPI_STATUS(status);
> > +}
> > --
> > 2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ