| 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
| ||
|
Message-ID: <5036592.TuXAnGzk4M@vostro.rjw.lan>
Date: Fri, 11 Jan 2013 22:23:34 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Toshi Kani <toshi.kani@...com>
Cc: lenb@...nel.org, gregkh@...uxfoundation.org,
akpm@...ux-foundation.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
bhelgaas@...gle.com, isimatu.yasuaki@...fujitsu.com,
jiang.liu@...wei.com, wency@...fujitsu.com, guohanjun@...wei.com,
yinghai@...nel.org, srivatsa.bhat@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
On Thursday, January 10, 2013 04:40:19 PM Toshi Kani wrote:
> Added include/linux/sys_hotplug.h, which defines the system device
> hotplug framework interfaces used by the framework itself and
> handlers.
>
> The order values define the calling sequence of handlers. For add
> execute, the ordering is ACPI->MEM->CPU. Memory is onlined before
> CPU so that threads on new CPUs can start using their local memory.
> The ordering of the delete execute is symmetric to the add execute.
>
> struct shp_request defines a hot-plug request information. The
> device resource information is managed with a list so that a single
> request may target to multiple devices.
>
> Signed-off-by: Toshi Kani <toshi.kani@...com>
> ---
> include/linux/sys_hotplug.h | 181 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 181 insertions(+)
> create mode 100644 include/linux/sys_hotplug.h
>
> diff --git a/include/linux/sys_hotplug.h b/include/linux/sys_hotplug.h
> new file mode 100644
> index 0000000..86674dd
> --- /dev/null
> +++ b/include/linux/sys_hotplug.h
> @@ -0,0 +1,181 @@
> +/*
> + * sys_hotplug.h - System device hot-plug framework
> + *
> + * Copyright (C) 2012 Hewlett-Packard Development Company, L.P.
> + * Toshi Kani <toshi.kani@...com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _LINUX_SYS_HOTPLUG_H
> +#define _LINUX_SYS_HOTPLUG_H
> +
> +#include <linux/list.h>
> +#include <linux/device.h>
> +
> +/*
> + * System device hot-plug operation proceeds in the following order.
> + * Validate phase -> Execute phase -> Commit phase
> + *
> + * The order values below define the calling sequence of platform
> + * neutral handlers for each phase in ascending order. The order
> + * values of firmware-specific handlers are defined in sys_hotplug.h
> + * under firmware specific directories.
> + */
> +
> +/* All order values must be smaller than this value */
> +#define SHP_ORDER_MAX 0xffffff
> +
> +/* Add Validate order values */
> +
> +/* Add Execute order values */
> +#define SHP_MEM_ADD_EXECUTE_ORDER 100
> +#define SHP_CPU_ADD_EXECUTE_ORDER 110
> +
> +/* Add Commit order values */
> +
> +/* Delete Validate order values */
> +#define SHP_CPU_DEL_VALIDATE_ORDER 100
> +#define SHP_MEM_DEL_VALIDATE_ORDER 110
> +
> +/* Delete Execute order values */
> +#define SHP_CPU_DEL_EXECUTE_ORDER 10
> +#define SHP_MEM_DEL_EXECUTE_ORDER 20
> +
> +/* Delete Commit order values */
> +
> +/*
> + * Hot-plug request types
> + */
> +#define SHP_REQ_ADD 0x000000
> +#define SHP_REQ_DELETE 0x000001
> +#define SHP_REQ_MASK 0x0000ff
> +
> +/*
> + * Hot-plug phase types
> + */
> +#define SHP_PH_VALIDATE 0x000000
> +#define SHP_PH_EXECUTE 0x000100
> +#define SHP_PH_COMMIT 0x000200
> +#define SHP_PH_MASK 0x00ff00
> +
> +/*
> + * Hot-plug operation types
> + */
> +#define SHP_OP_HOTPLUG 0x000000
> +#define SHP_OP_ONLINE 0x010000
> +#define SHP_OP_MASK 0xff0000
> +
> +/*
> + * Hot-plug phases
> + */
> +enum shp_phase {
> + SHP_ADD_VALIDATE = (SHP_REQ_ADD|SHP_PH_VALIDATE),
> + SHP_ADD_EXECUTE = (SHP_REQ_ADD|SHP_PH_EXECUTE),
> + SHP_ADD_COMMIT = (SHP_REQ_ADD|SHP_PH_COMMIT),
> + SHP_DEL_VALIDATE = (SHP_REQ_DELETE|SHP_PH_VALIDATE),
> + SHP_DEL_EXECUTE = (SHP_REQ_DELETE|SHP_PH_EXECUTE),
> + SHP_DEL_COMMIT = (SHP_REQ_DELETE|SHP_PH_COMMIT)
> +};
> +
> +/*
> + * Hot-plug operations
> + */
> +enum shp_operation {
> + SHP_HOTPLUG_ADD = (SHP_OP_HOTPLUG|SHP_REQ_ADD),
> + SHP_HOTPLUG_DEL = (SHP_OP_HOTPLUG|SHP_REQ_DELETE),
> + SHP_ONLINE_ADD = (SHP_OP_ONLINE|SHP_REQ_ADD),
> + SHP_ONLINE_DEL = (SHP_OP_ONLINE|SHP_REQ_DELETE)
> +};
> +
> +/*
> + * Hot-plug device classes
> + */
> +enum shp_class {
> + SHP_CLS_INVALID = 0,
> + SHP_CLS_CPU = 1,
> + SHP_CLS_MEMORY = 2,
> + SHP_CLS_HOSTBRIDGE = 3,
> + SHP_CLS_CONTAINER = 4,
> +};
> +
> +/*
> + * Hot-plug device information
> + */
> +union shp_dev_info {
> + struct shp_cpu {
> + u32 cpu_id;
> + } cpu;
> +
> + struct shp_memory {
> + int node;
> + u64 start_addr;
> + u64 length;
> + } mem;
> +
> + struct shp_hostbridge {
> + } hb;
> +
> + struct shp_node {
> + } node;
> +};
> +
> +struct shp_device {
> + struct list_head list;
> + struct device *device;
> + enum shp_class class;
> + union shp_dev_info info;
> +};
> +
> +/*
> + * Hot-plug request
> + */
> +struct shp_request {
> + /* common info */
> + enum shp_operation operation; /* operation */
> +
> + /* hot-plug event info: only valid for hot-plug operations */
> + void *handle; /* FW handle */
What's the role of handle here?
> + u32 event; /* FW event */
> +
> + /* device resource info */
> + struct list_head dev_list; /* shp_device list */
> +};
> +
> +/*
> + * Inline Utility Functions
> + */
> +static inline bool shp_is_hotplug_op(enum shp_operation operation)
> +{
> + return (operation & SHP_OP_MASK) == SHP_OP_HOTPLUG;
> +}
> +
> +static inline bool shp_is_online_op(enum shp_operation operation)
> +{
> + return (operation & SHP_OP_MASK) == SHP_OP_ONLINE;
> +}
> +
> +static inline bool shp_is_add_op(enum shp_operation operation)
> +{
> + return (operation & SHP_REQ_MASK) == SHP_REQ_ADD;
> +}
> +
> +static inline bool shp_is_add_phase(enum shp_phase phase)
> +{
> + return (phase & SHP_REQ_MASK) == SHP_REQ_ADD;
> +}
> +
> +/*
> + * Externs
> + */
> +typedef int (*shp_func)(struct shp_request *req, int rollback);
> +extern int shp_register_handler(enum shp_phase phase, shp_func func, u32 order);
> +extern int shp_unregister_handler(enum shp_phase phase, shp_func func);
> +extern int shp_submit_req(struct shp_request *req);
> +extern struct shp_request *shp_alloc_request(enum shp_operation operation);
> +extern void shp_add_dev_info(struct shp_request *shp_req,
> + struct shp_device *shp_dev);
> +
> +#endif /* _LINUX_SYS_HOTPLUG_H */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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