* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Daniel Lezcano @ 2015-05-19 9:59 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Paul Bolle, Peter Hurley,
Andy Shevchenko, Chanwoo Choi, Russell King, Joe Perches,
Vladimir Zapolskiy, Lee Jones, Daniel Thompson, Jonathan Corbet,
Pawel Moll, Mark Rutland
In-Reply-To: <CALszF6Asfke0-cMQJcEQ8ya+rbPPPhUc6aXTZXQvQ8QF66cwYQ@mail.gmail.com>
On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>
>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>
>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>>
>>>>>>
>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>> prescalers.
>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>
>>>>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>>> ---
>>>>>>> drivers/clocksource/Kconfig | 8 ++
>>>>>>> drivers/clocksource/Makefile | 1 +
>>>>>>> drivers/clocksource/timer-stm32.c | 184
>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>> 3 files changed, 193 insertions(+)
>>>>>>> create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>
>>>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>>>> index bf9364c..2443520 100644
>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>> Support to use the timers of EFM32 SoCs as clock source
>>>>>>> and
>>>>>>> clock
>>>>>>> event device.
>>>>>>>
>>>>>>> +config CLKSRC_STM32
>>>>>>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>
>>>>>
>>>>> The interactive bool is necessary if we want to be able to
>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>
>>>>> Note that other timer drivers are doing the same thing today
>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>
>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>
>>>>
>>>>
>>>> Actually, we try to keep the timer selection non-interactive and let the
>>>> platform's Kconfig to select the timer.
>>>
>>>
>>> Ok.
>>>
>>>>
>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>> created a precedence. I would like to get rid of the interactive timer
>>>> selection but I did not have time to go through this yet.
>>>
>>>
>>> Indeed, consistency is important.
>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>> thing.
>>> IMHO, it is more a subsystem's maintainer choice.
>>>
>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>> I'm fine to provide you a new version without COMPILE_TEST.
>>> Doing that, the interactive selection will disappear too.
>>>
>>> I can provide you a new version this evenning.
>>
>>
>> Ok, great.
>
> Is the below Kconfig entry fine for you?
>
> config CLKSRC_STM32
> def_bool y if ARCH_STM32
> select CLKSRC_MMIO
config CLKSRC_STM32
bool
select CLKSRC_MMIO
and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> Best regards,
> Maxime
>
>
>>
>> Thanks
>> -- Daniel
>>
>>
>>>>
>>>>
>>>>
>>>> --
>>>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>>
>>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>
>>
>>
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v9] scsi: ufs: add ioctl interface for query request
From: Gilad Broner @ 2015-05-19 10:02 UTC (permalink / raw)
To: James.Bottomley
Cc: linux-kernel, linux-scsi, linux-arm-msm, linux-scsi-owner,
subhashj, ygardi, draviv, Noa Rubens, Raviv Shvili, Gilad Broner,
Vinayak Holikatti, James E.J. Bottomley, open list:ABI/API
In-Reply-To: <1432029766-16456-1-git-send-email-gbroner@codeaurora.org>
From: Dolev Raviv <draviv@codeaurora.org>
This patch exposes the ioctl interface for UFS driver via SCSI device
ioctl interface. As of now UFS driver would provide the ioctl for query
interface to connected UFS device.
Changes from V8:
Removed error prints and cleaned up some typos.
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Noa Rubens <noag@codeaurora.org>
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
---
drivers/scsi/ufs/ufs.h | 53 +++--------
drivers/scsi/ufs/ufshcd.c | 205 +++++++++++++++++++++++++++++++++++++++++-
include/scsi/scsi.h | 1 +
include/uapi/scsi/Kbuild | 1 +
include/uapi/scsi/ufs/Kbuild | 3 +
include/uapi/scsi/ufs/ioctl.h | 57 ++++++++++++
include/uapi/scsi/ufs/ufs.h | 66 ++++++++++++++
7 files changed, 342 insertions(+), 44 deletions(-)
create mode 100644 include/uapi/scsi/ufs/Kbuild
create mode 100644 include/uapi/scsi/ufs/ioctl.h
create mode 100644 include/uapi/scsi/ufs/ufs.h
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 42c459a..1f023c4 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -38,6 +38,7 @@
#include <linux/mutex.h>
#include <linux/types.h>
+#include <scsi/ufs/ufs.h>
#define MAX_CDB_SIZE 16
#define GENERAL_UPIU_REQUEST_SIZE 32
@@ -71,6 +72,16 @@ enum {
UFS_UPIU_RPMB_WLUN = 0xC4,
};
+/**
+ * ufs_is_valid_unit_desc_lun - checks if the given LUN has a unit descriptor
+ * @lun: LU number to check
+ * @return: true if the lun has a matching unit descriptor, false otherwise
+ */
+static inline bool ufs_is_valid_unit_desc_lun(u8 lun)
+{
+ return (lun == UFS_UPIU_RPMB_WLUN || (lun < UFS_UPIU_MAX_GENERAL_LUN));
+}
+
/*
* UFS Protocol Information Unit related definitions
*/
@@ -126,35 +137,6 @@ enum {
UPIU_QUERY_FUNC_STANDARD_WRITE_REQUEST = 0x81,
};
-/* Flag idn for Query Requests*/
-enum flag_idn {
- QUERY_FLAG_IDN_FDEVICEINIT = 0x01,
- QUERY_FLAG_IDN_PWR_ON_WPE = 0x03,
- QUERY_FLAG_IDN_BKOPS_EN = 0x04,
-};
-
-/* Attribute idn for Query requests */
-enum attr_idn {
- QUERY_ATTR_IDN_ACTIVE_ICC_LVL = 0x03,
- QUERY_ATTR_IDN_BKOPS_STATUS = 0x05,
- QUERY_ATTR_IDN_EE_CONTROL = 0x0D,
- QUERY_ATTR_IDN_EE_STATUS = 0x0E,
-};
-
-/* Descriptor idn for Query requests */
-enum desc_idn {
- QUERY_DESC_IDN_DEVICE = 0x0,
- QUERY_DESC_IDN_CONFIGURAION = 0x1,
- QUERY_DESC_IDN_UNIT = 0x2,
- QUERY_DESC_IDN_RFU_0 = 0x3,
- QUERY_DESC_IDN_INTERCONNECT = 0x4,
- QUERY_DESC_IDN_STRING = 0x5,
- QUERY_DESC_IDN_RFU_1 = 0x6,
- QUERY_DESC_IDN_GEOMETRY = 0x7,
- QUERY_DESC_IDN_POWER = 0x8,
- QUERY_DESC_IDN_MAX,
-};
-
enum desc_header_offset {
QUERY_DESC_LENGTH_OFFSET = 0x00,
QUERY_DESC_DESC_TYPE_OFFSET = 0x01,
@@ -247,19 +229,6 @@ enum bkops_status {
BKOPS_STATUS_MAX = BKOPS_STATUS_CRITICAL,
};
-/* UTP QUERY Transaction Specific Fields OpCode */
-enum query_opcode {
- UPIU_QUERY_OPCODE_NOP = 0x0,
- UPIU_QUERY_OPCODE_READ_DESC = 0x1,
- UPIU_QUERY_OPCODE_WRITE_DESC = 0x2,
- UPIU_QUERY_OPCODE_READ_ATTR = 0x3,
- UPIU_QUERY_OPCODE_WRITE_ATTR = 0x4,
- UPIU_QUERY_OPCODE_READ_FLAG = 0x5,
- UPIU_QUERY_OPCODE_SET_FLAG = 0x6,
- UPIU_QUERY_OPCODE_CLEAR_FLAG = 0x7,
- UPIU_QUERY_OPCODE_TOGGLE_FLAG = 0x8,
-};
-
/* Query response result code */
enum {
QUERY_RESULT_SUCCESS = 0x00,
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 648a446..4674dee 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3,7 +3,7 @@
*
* This code is based on drivers/scsi/ufs/ufshcd.c
* Copyright (C) 2011-2013 Samsung India Software Operations
- * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
*
* Authors:
* Santosh Yaraganavi <santosh.sy@samsung.com>
@@ -39,6 +39,7 @@
#include <linux/async.h>
#include <linux/devfreq.h>
+#include <scsi/ufs/ioctl.h>
#include "ufshcd.h"
#include "unipro.h"
@@ -74,6 +75,9 @@
/* Interrupt aggregation default timeout, unit: 40us */
#define INT_AGGR_DEF_TO 0x02
+/* IOCTL opcode for command - ufs set device read only */
+#define UFS_IOCTL_BLKROSET BLKROSET
+
#define ufshcd_toggle_vreg(_dev, _vreg, _on) \
({ \
int _ret; \
@@ -1885,7 +1889,7 @@ static inline int ufshcd_read_unit_desc_param(struct ufs_hba *hba,
* Unit descriptors are only available for general purpose LUs (LUN id
* from 0 to 7) and RPMB Well known LU.
*/
- if (lun != UFS_UPIU_RPMB_WLUN && (lun >= UFS_UPIU_MAX_GENERAL_LUN))
+ if (!ufs_is_valid_unit_desc_lun(lun))
return -EOPNOTSUPP;
return ufshcd_read_desc_param(hba, QUERY_DESC_IDN_UNIT, lun,
@@ -4236,6 +4240,202 @@ static void ufshcd_async_scan(void *data, async_cookie_t cookie)
ufshcd_probe_hba(hba);
}
+/**
+ * ufshcd_query_ioctl - perform user read queries
+ * @hba: per-adapter instance
+ * @lun: used for lun specific queries
+ * @buffer: user space buffer for reading and submitting query data and params
+ *
+ * Returns 0 for success or negative error code otherwise
+ *
+ * Expected/Submitted buffer structure is struct ufs_ioctl_query_data.
+ * It will read the opcode, idn and buf_length parameters, and put the
+ * response in the buffer field while updating the used size in buf_length.
+ */
+static int ufshcd_query_ioctl(struct ufs_hba *hba, u8 lun, void __user *buffer)
+{
+ struct ufs_ioctl_query_data *ioctl_data;
+ int err = 0;
+ int length = 0;
+ void *data_ptr;
+ bool flag;
+ u32 att;
+ u8 index;
+ u8 *desc = NULL;
+
+ if (!buffer)
+ return -EINVAL;
+
+ ioctl_data = kzalloc(sizeof(struct ufs_ioctl_query_data), GFP_KERNEL);
+ if (!ioctl_data) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ /* extract params from user buffer */
+ if (copy_from_user(ioctl_data, buffer, sizeof(*ioctl_data))) {
+ err = -EFAULT;
+ goto out_release_mem;
+ }
+
+ /* verify legal parameters & send query */
+ switch (ioctl_data->opcode) {
+ case UPIU_QUERY_OPCODE_READ_DESC:
+ switch (ioctl_data->idn) {
+ case QUERY_DESC_IDN_DEVICE:
+ case QUERY_DESC_IDN_CONFIGURAION:
+ case QUERY_DESC_IDN_INTERCONNECT:
+ case QUERY_DESC_IDN_GEOMETRY:
+ case QUERY_DESC_IDN_POWER:
+ index = 0;
+ break;
+ case QUERY_DESC_IDN_UNIT:
+ if (!ufs_is_valid_unit_desc_lun(lun)) {
+ err = -EINVAL;
+ goto out_release_mem;
+ }
+ index = lun;
+ break;
+ default:
+ goto out_einval;
+ }
+ length = min_t(int, QUERY_DESC_MAX_SIZE,
+ ioctl_data->buf_size);
+ desc = kzalloc(length, GFP_KERNEL);
+ if (!desc) {
+ err = -ENOMEM;
+ goto out_release_mem;
+ }
+ err = ufshcd_query_descriptor(hba, ioctl_data->opcode,
+ ioctl_data->idn, index, 0, desc, &length);
+ break;
+ case UPIU_QUERY_OPCODE_READ_ATTR:
+ switch (ioctl_data->idn) {
+ case QUERY_ATTR_IDN_BOOT_LU_EN:
+ case QUERY_ATTR_IDN_POWER_MODE:
+ case QUERY_ATTR_IDN_ACTIVE_ICC_LVL:
+ case QUERY_ATTR_IDN_OOO_DATA_EN:
+ case QUERY_ATTR_IDN_BKOPS_STATUS:
+ case QUERY_ATTR_IDN_PURGE_STATUS:
+ case QUERY_ATTR_IDN_MAX_DATA_IN:
+ case QUERY_ATTR_IDN_MAX_DATA_OUT:
+ case QUERY_ATTR_IDN_REF_CLK_FREQ:
+ case QUERY_ATTR_IDN_CONF_DESC_LOCK:
+ case QUERY_ATTR_IDN_MAX_NUM_OF_RTT:
+ case QUERY_ATTR_IDN_EE_CONTROL:
+ case QUERY_ATTR_IDN_EE_STATUS:
+ case QUERY_ATTR_IDN_SECONDS_PASSED:
+ index = 0;
+ break;
+ case QUERY_ATTR_IDN_DYN_CAP_NEEDED:
+ case QUERY_ATTR_IDN_CORR_PRG_BLK_NUM:
+ index = lun;
+ break;
+ default:
+ goto out_einval;
+ }
+ err = ufshcd_query_attr(hba, ioctl_data->opcode,
+ ioctl_data->idn, index, 0, &att);
+ break;
+ case UPIU_QUERY_OPCODE_READ_FLAG:
+ switch (ioctl_data->idn) {
+ case QUERY_FLAG_IDN_FDEVICEINIT:
+ case QUERY_FLAG_IDN_PERMANENT_WPE:
+ case QUERY_FLAG_IDN_PWR_ON_WPE:
+ case QUERY_FLAG_IDN_BKOPS_EN:
+ case QUERY_FLAG_IDN_PURGE_ENABLE:
+ case QUERY_FLAG_IDN_FPHYRESOURCEREMOVAL:
+ case QUERY_FLAG_IDN_BUSY_RTC:
+ break;
+ default:
+ goto out_einval;
+ }
+ err = ufshcd_query_flag(hba, ioctl_data->opcode,
+ ioctl_data->idn, &flag);
+ break;
+ default:
+ goto out_einval;
+ }
+
+ if (err)
+ goto out_release_mem;
+
+ /*
+ * copy response data
+ * As we might end up reading less data then what is specified in
+ * "ioctl_data->buf_size". So we are updating "ioctl_data->
+ * buf_size" to what exactly we have read.
+ */
+ switch (ioctl_data->opcode) {
+ case UPIU_QUERY_OPCODE_READ_DESC:
+ ioctl_data->buf_size = min_t(int, ioctl_data->buf_size, length);
+ data_ptr = desc;
+ break;
+ case UPIU_QUERY_OPCODE_READ_ATTR:
+ ioctl_data->buf_size = sizeof(u32);
+ data_ptr = &att;
+ break;
+ case UPIU_QUERY_OPCODE_READ_FLAG:
+ ioctl_data->buf_size = 1;
+ data_ptr = &flag;
+ break;
+ default:
+ BUG_ON(true);
+ }
+
+ /* copy to user */
+ err = copy_to_user(buffer, ioctl_data, sizeof(*ioctl_data));
+ if (!err)
+ err = copy_to_user(buffer + sizeof(*ioctl_data), data_ptr,
+ ioctl_data->buf_size);
+ if (err)
+ err = -EFAULT;
+
+ goto out_release_mem;
+
+out_einval:
+ err = -EINVAL;
+out_release_mem:
+ kfree(ioctl_data);
+ kfree(desc);
+out:
+ return err;
+}
+
+/**
+ * ufshcd_ioctl - ufs ioctl callback registered in scsi_host
+ * @dev: scsi device required for per LUN queries
+ * @cmd: command opcode
+ * @buffer: user space buffer for transferring data
+ *
+ * Supported commands:
+ * UFS_IOCTL_QUERY
+ */
+static int ufshcd_ioctl(struct scsi_device *dev, int cmd, void __user *buffer)
+{
+ struct ufs_hba *hba = shost_priv(dev->host);
+ int err = 0;
+
+ BUG_ON(!hba);
+
+ switch (cmd) {
+ case UFS_IOCTL_QUERY:
+ pm_runtime_get_sync(hba->dev);
+ err = ufshcd_query_ioctl(hba, ufshcd_scsi_to_upiu_lun(dev->lun),
+ buffer);
+ pm_runtime_put_sync(hba->dev);
+ break;
+ case UFS_IOCTL_BLKROSET:
+ err = -ENOIOCTLCMD;
+ break;
+ default:
+ err = -EINVAL;
+ break;
+ }
+
+ return err;
+}
+
static struct scsi_host_template ufshcd_driver_template = {
.module = THIS_MODULE,
.name = UFSHCD,
@@ -4248,6 +4448,7 @@ static struct scsi_host_template ufshcd_driver_template = {
.eh_abort_handler = ufshcd_abort,
.eh_device_reset_handler = ufshcd_eh_device_reset_handler,
.eh_host_reset_handler = ufshcd_eh_host_reset_handler,
+ .ioctl = ufshcd_ioctl,
.this_id = -1,
.sg_tablesize = SG_ALL,
.cmd_per_lun = UFSHCD_CMD_PER_LUN,
diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index d0a66aa..3feb501 100644
--- a/include/scsi/scsi.h
+++ b/include/scsi/scsi.h
@@ -569,6 +569,7 @@ static inline int scsi_is_wlun(u64 lun)
* Here are some scsi specific ioctl commands which are sometimes useful.
*
* Note that include/linux/cdrom.h also defines IOCTL 0x5300 - 0x5395
+ * include/uapi/scsi/ufs/ioctl.h defines 0x5388
*/
/* Used to obtain PUN and LUN info. Conflicts with CDROMAUDIOBUFSIZ */
diff --git a/include/uapi/scsi/Kbuild b/include/uapi/scsi/Kbuild
index 75746d5..d404525 100644
--- a/include/uapi/scsi/Kbuild
+++ b/include/uapi/scsi/Kbuild
@@ -1,5 +1,6 @@
# UAPI Header export list
header-y += fc/
+header-y += ufs/
header-y += scsi_bsg_fc.h
header-y += scsi_netlink.h
header-y += scsi_netlink_fc.h
diff --git a/include/uapi/scsi/ufs/Kbuild b/include/uapi/scsi/ufs/Kbuild
new file mode 100644
index 0000000..cc3ef20
--- /dev/null
+++ b/include/uapi/scsi/ufs/Kbuild
@@ -0,0 +1,3 @@
+# UAPI Header export list
+header-y += ioctl.h
+header-y += ufs.h
diff --git a/include/uapi/scsi/ufs/ioctl.h b/include/uapi/scsi/ufs/ioctl.h
new file mode 100644
index 0000000..bc4eed7
--- /dev/null
+++ b/include/uapi/scsi/ufs/ioctl.h
@@ -0,0 +1,57 @@
+#ifndef UAPI_UFS_IOCTL_H_
+#define UAPI_UFS_IOCTL_H_
+
+#include <linux/types.h>
+
+/*
+ * IOCTL opcode for ufs queries has the following opcode after
+ * SCSI_IOCTL_GET_PCI
+ */
+#define UFS_IOCTL_QUERY 0x5388
+
+/**
+ * struct ufs_ioctl_query_data - used to transfer data to and from user via ioctl
+ * @opcode: type of data to query (descriptor/attribute/flag)
+ * @idn: id of the data structure
+ * @buf_size: number of allocated bytes/data size on return
+ * @buffer: data location
+ *
+ * Received: buffer and buf_size (available space for transferred data)
+ * Submitted: opcode, idn, length, buf_size
+ */
+struct ufs_ioctl_query_data {
+ /*
+ * User should select one of the opcode defined in "enum query_opcode".
+ * Please check include/uapi/scsi/ufs/ufs.h for the definition of it.
+ * Note that only UPIU_QUERY_OPCODE_READ_DESC,
+ * UPIU_QUERY_OPCODE_READ_ATTR & UPIU_QUERY_OPCODE_READ_FLAG are
+ * supported as of now. All other query_opcode would be considered
+ * invalid.
+ * As of now only read query operations are supported.
+ */
+ __u32 opcode;
+ /*
+ * User should select one of the idn from "enum flag_idn" or "enum
+ * attr_idn" or "enum desc_idn" based on whether opcode above is
+ * attribute, flag or descriptor.
+ * Please check include/uapi/scsi/ufs/ufs.h for the definition of it.
+ */
+ __u8 idn;
+ /*
+ * User should specify the size of the buffer (buffer[0] below) where
+ * it wants to read the query data (attribute/flag/descriptor).
+ * As we might end up reading less data then what is specified in
+ * buf_size. So we are updating buf_size to what exactly we have read.
+ */
+ __u16 buf_size;
+ /*
+ * placeholder for the start of the data buffer where kernel will copy
+ * the query data (attribute/flag/descriptor) read from the UFS device
+ * Note:
+ * For Read Attribute you will have to allocate 4 bytes
+ * For Read Flag you will have to allocate 1 byte
+ */
+ __u8 buffer[0];
+};
+
+#endif /* UAPI_UFS_IOCTL_H_ */
diff --git a/include/uapi/scsi/ufs/ufs.h b/include/uapi/scsi/ufs/ufs.h
new file mode 100644
index 0000000..894ea45
--- /dev/null
+++ b/include/uapi/scsi/ufs/ufs.h
@@ -0,0 +1,66 @@
+#ifndef UAPI_UFS_H_
+#define UAPI_UFS_H_
+
+/* Flag idn for Query Requests*/
+enum flag_idn {
+ QUERY_FLAG_IDN_FDEVICEINIT = 0x01,
+ QUERY_FLAG_IDN_PERMANENT_WPE = 0x02,
+ QUERY_FLAG_IDN_PWR_ON_WPE = 0x03,
+ QUERY_FLAG_IDN_BKOPS_EN = 0x04,
+ QUERY_FLAG_IDN_RESERVED1 = 0x05,
+ QUERY_FLAG_IDN_PURGE_ENABLE = 0x06,
+ QUERY_FLAG_IDN_RESERVED2 = 0x07,
+ QUERY_FLAG_IDN_FPHYRESOURCEREMOVAL = 0x08,
+ QUERY_FLAG_IDN_BUSY_RTC = 0x09,
+};
+
+/* Attribute idn for Query requests */
+enum attr_idn {
+ QUERY_ATTR_IDN_BOOT_LU_EN = 0x00,
+ QUERY_ATTR_IDN_RESERVED = 0x01,
+ QUERY_ATTR_IDN_POWER_MODE = 0x02,
+ QUERY_ATTR_IDN_ACTIVE_ICC_LVL = 0x03,
+ QUERY_ATTR_IDN_OOO_DATA_EN = 0x04,
+ QUERY_ATTR_IDN_BKOPS_STATUS = 0x05,
+ QUERY_ATTR_IDN_PURGE_STATUS = 0x06,
+ QUERY_ATTR_IDN_MAX_DATA_IN = 0x07,
+ QUERY_ATTR_IDN_MAX_DATA_OUT = 0x08,
+ QUERY_ATTR_IDN_DYN_CAP_NEEDED = 0x09,
+ QUERY_ATTR_IDN_REF_CLK_FREQ = 0x0A,
+ QUERY_ATTR_IDN_CONF_DESC_LOCK = 0x0B,
+ QUERY_ATTR_IDN_MAX_NUM_OF_RTT = 0x0C,
+ QUERY_ATTR_IDN_EE_CONTROL = 0x0D,
+ QUERY_ATTR_IDN_EE_STATUS = 0x0E,
+ QUERY_ATTR_IDN_SECONDS_PASSED = 0x0F,
+ QUERY_ATTR_IDN_CNTX_CONF = 0x10,
+ QUERY_ATTR_IDN_CORR_PRG_BLK_NUM = 0x11,
+};
+
+/* Descriptor idn for Query requests */
+enum desc_idn {
+ QUERY_DESC_IDN_DEVICE = 0x0,
+ QUERY_DESC_IDN_CONFIGURAION = 0x1,
+ QUERY_DESC_IDN_UNIT = 0x2,
+ QUERY_DESC_IDN_RFU_0 = 0x3,
+ QUERY_DESC_IDN_INTERCONNECT = 0x4,
+ QUERY_DESC_IDN_STRING = 0x5,
+ QUERY_DESC_IDN_RFU_1 = 0x6,
+ QUERY_DESC_IDN_GEOMETRY = 0x7,
+ QUERY_DESC_IDN_POWER = 0x8,
+ QUERY_DESC_IDN_RFU_2 = 0x9,
+ QUERY_DESC_IDN_MAX,
+};
+
+/* UTP QUERY Transaction Specific Fields OpCode */
+enum query_opcode {
+ UPIU_QUERY_OPCODE_NOP = 0x0,
+ UPIU_QUERY_OPCODE_READ_DESC = 0x1,
+ UPIU_QUERY_OPCODE_WRITE_DESC = 0x2,
+ UPIU_QUERY_OPCODE_READ_ATTR = 0x3,
+ UPIU_QUERY_OPCODE_WRITE_ATTR = 0x4,
+ UPIU_QUERY_OPCODE_READ_FLAG = 0x5,
+ UPIU_QUERY_OPCODE_SET_FLAG = 0x6,
+ UPIU_QUERY_OPCODE_CLEAR_FLAG = 0x7,
+ UPIU_QUERY_OPCODE_TOGGLE_FLAG = 0x8,
+};
+#endif /* UAPI_UFS_H_ */
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Maxime Coquelin @ 2015-05-19 10:02 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Paul Bolle, Peter Hurley,
Andy Shevchenko, Chanwoo Choi, Russell King, Joe Perches,
Vladimir Zapolskiy, Lee Jones, Daniel Thompson, Jonathan Corbet,
Pawel Moll, Mark Rutland, Ian Campbell
In-Reply-To: <555B098A.8030202-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> On 05/19/2015 11:44 AM, Maxime Coquelin wrote:
>>
>> 2015-05-19 11:06 GMT+02:00 Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>>
>>> On 05/19/2015 10:55 AM, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-19 10:16 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>
>>>>>
>>>>> On 05/18/2015 04:03 PM, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-05-18 15:10 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 05/09/2015 09:53 AM, Maxime Coquelin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> STM32 MCUs feature 16 and 32 bits general purpose timers with
>>>>>>>> prescalers.
>>>>>>>> The drivers detects whether the time is 16 or 32 bits, and applies a
>>>>>>>> 1024 prescaler value if it is 16 bits.
>>>>>>>>
>>>>>>>> Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>>>>> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>>>>> ---
>>>>>>>> drivers/clocksource/Kconfig | 8 ++
>>>>>>>> drivers/clocksource/Makefile | 1 +
>>>>>>>> drivers/clocksource/timer-stm32.c | 184
>>>>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>>>>> 3 files changed, 193 insertions(+)
>>>>>>>> create mode 100644 drivers/clocksource/timer-stm32.c
>>>>>>>>
>>>>>>>> diff --git a/drivers/clocksource/Kconfig
>>>>>>>> b/drivers/clocksource/Kconfig
>>>>>>>> index bf9364c..2443520 100644
>>>>>>>> --- a/drivers/clocksource/Kconfig
>>>>>>>> +++ b/drivers/clocksource/Kconfig
>>>>>>>> @@ -106,6 +106,14 @@ config CLKSRC_EFM32
>>>>>>>> Support to use the timers of EFM32 SoCs as clock source
>>>>>>>> and
>>>>>>>> clock
>>>>>>>> event device.
>>>>>>>>
>>>>>>>> +config CLKSRC_STM32
>>>>>>>> + bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>>>>>>>> + depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Are the interactive bool and the 'COMPILE_TEST' necessary ?
>>>>>>>
>>>>>>
>>>>>> The interactive bool is necessary if we want to be able to
>>>>>> select/deselect it in COMPILE_TEST configuration.
>>>>>> And personnaly, I think COMPILE_TEST use makes sense.
>>>>>>
>>>>>> Note that other timer drivers are doing the same thing today
>>>>>> (CLKSRC_EFM32, SH_TIMER_CMT, EM_TIMER_STI...).
>>>>>>
>>>>>> Do you have a specific concern regarding COMPILE_TEST?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Actually, we try to keep the timer selection non-interactive and let
>>>>> the
>>>>> platform's Kconfig to select the timer.
>>>>
>>>>
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>> I like when the code is consistent. The COMPILE_TEST was introduced and
>>>>> created a precedence. I would like to get rid of the interactive timer
>>>>> selection but I did not have time to go through this yet.
>>>>
>>>>
>>>>
>>>> Indeed, consistency is important.
>>>> On my side, I don't have a strong opinion regarding the COMPILE_TEST
>>>> thing.
>>>> IMHO, it is more a subsystem's maintainer choice.
>>>>
>>>> So, if as a maintainer you don't use it and prefer not supporting it,
>>>> I'm fine to provide you a new version without COMPILE_TEST.
>>>> Doing that, the interactive selection will disappear too.
>>>>
>>>> I can provide you a new version this evenning.
>>>
>>>
>>>
>>> Ok, great.
>>
>>
>> Is the below Kconfig entry fine for you?
>>
>> config CLKSRC_STM32
>> def_bool y if ARCH_STM32
>> select CLKSRC_MMIO
>
>
> config CLKSRC_STM32
> bool
> select CLKSRC_MMIO
>
> and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
the one intruducing ARCH_STM32.
Thanks,
Maxime
>
>
>> Best regards,
>> Maxime
>>
>>
>>>
>>> Thanks
>>> -- Daniel
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM
>>>>> SoCs
>>>>>
>>>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>>>> <http://twitter.com/#!/linaroorg> Twitter |
>>>>> <http://www.linaro.org/linaro-blog/> Blog
>>>>>
>>>
>>>
>>> --
>>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>>
>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Arnd Bergmann @ 2015-05-19 10:55 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Daniel Lezcano, Uwe Kleine-König, Andreas Färber,
Geert Uytterhoeven, Rob Herring, Philipp Zabel, Linus Walleij,
Stefan Agner, Peter Meerwald, Paul Bolle, Peter Hurley,
Andy Shevchenko, Chanwoo Choi, Russell King, Joe Perches,
Vladimir Zapolskiy, Lee Jones, Daniel Thompson, Jonathan Corbet,
Pawel Moll, Mark Rutland
In-Reply-To: <CALszF6AJ3Zf598wYeUx=iNWHHKT24xUyfagB=+4GocwZ-Fd-0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tuesday 19 May 2015 12:02:59 Maxime Coquelin wrote:
> >
> > config CLKSRC_STM32
> > bool
> > select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
>
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.
>
>
Please also make it possible to select this driver on other architectures
with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
Arnd
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Thomas Gleixner @ 2015-05-19 12:56 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Daniel Lezcano, Uwe Kleine-König, Andreas Färber,
Geert Uytterhoeven, Rob Herring, Philipp Zabel, Linus Walleij,
Arnd Bergmann, Stefan Agner, Peter Meerwald, Paul Bolle,
Peter Hurley, Andy Shevchenko, Chanwoo Choi, Russell King,
Joe Perches, Vladimir Zapolskiy, Lee Jones, Daniel Thompson,
Jonathan Corbet, Pawel Moll
In-Reply-To: <CALszF6AJ3Zf598wYeUx=iNWHHKT24xUyfagB=+4GocwZ-Fd-0g@mail.gmail.com>
On Tue, 19 May 2015, Maxime Coquelin wrote:
> 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> >> Is the below Kconfig entry fine for you?
> >>
> >> config CLKSRC_STM32
> >> def_bool y if ARCH_STM32
> >> select CLKSRC_MMIO
> >
> >
> > config CLKSRC_STM32
> > bool
> > select CLKSRC_MMIO
> >
> > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
>
> Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> the one intruducing ARCH_STM32.
Folks, can you please trim your replies. It's a PITA to scroll down
through several pages to find a single line of content.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Russell King - ARM Linux @ 2015-05-19 13:00 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Maxime Coquelin, Daniel Lezcano, Uwe Kleine-König,
Andreas Färber, Geert Uytterhoeven, Rob Herring,
Philipp Zabel, Linus Walleij, Arnd Bergmann, Stefan Agner,
Peter Meerwald, Paul Bolle, Peter Hurley, Andy Shevchenko,
Chanwoo Choi, Joe Perches, Vladimir Zapolskiy, Lee Jones,
Daniel Thompson, Jonathan Corbet, Pawel Moll
In-Reply-To: <alpine.DEB.2.11.1505191455540.4225@nanos>
On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
> On Tue, 19 May 2015, Maxime Coquelin wrote:
> > 2015-05-19 11:59 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> > >> Is the below Kconfig entry fine for you?
> > >>
> > >> config CLKSRC_STM32
> > >> def_bool y if ARCH_STM32
> > >> select CLKSRC_MMIO
> > >
> > >
> > > config CLKSRC_STM32
> > > bool
> > > select CLKSRC_MMIO
> > >
> > > and in the arch/arm/mach-stm32/Kconfig add select CLKSRC_STM32
> >
> > Ok, I will send a patch for arch/arm/Kconfig, as Arnd already applied
> > the one intruducing ARCH_STM32.
>
> Folks, can you please trim your replies. It's a PITA to scroll down
> through several pages to find a single line of content.
Absolutely right. Too many people do not do this, and it's a waste of
readers time. Maybe we should start ignoring emails which contain only
quoted mail in the first 50 lines.
Also, cutting the rest of the email below the point which you've finished
replying is good etiquette as well. I've seen a number of posts where
people have added their signature mid-mail and left a huge chunk of quoted
mail below. That's just not on either.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Richard Guy Briggs @ 2015-05-19 13:09 UTC (permalink / raw)
To: Paul Moore
Cc: Eric W. Biederman, Linux API, Linux Containers,
linux-kernel@vger.kernel.org, Andy Lutomirski, linux-audit,
Al Viro, Network Development, Linux FS Devel, Eric Paris,
Serge E. Hallyn
In-Reply-To: <CAHC9VhQs6pxFC3dvZic5XzuJr1xdJZyPjXdBoipwY3OOkng0ng@mail.gmail.com>
On 15/05/16, Paul Moore wrote:
> On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> > Paul Moore <paul@paul-moore.com> writes:
> >> On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >>> On 05/15/2015 05:05 PM, Paul Moore wrote:
> >>>> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
> >>>>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> >>>>>> On 15/05/14, Paul Moore wrote:
> >>>>>>> * Look at our existing audit records to determine which records should
> >>>>>>> have
> >>>>>>> namespace and container ID tokens added. We may only want to add the
> >>>>>>> additional fields in the case where the namespace/container ID tokens are
> >>>>>>> not the init namespace.
> >>>>>> If we have a record that ties a set of namespace IDs with a container
> >>>>>> ID, then I expect we only need to list the containerID along with auid
> >>>>>> and sessionID.
> >>>>> The problem here is that the kernel has no concept of a "container", and I
> >>>>> don't think it makes any sense to add one just for audit. "Container" is a
> >>>>> marketing term used by some userspace tools.
> >>>>>
> >>>>> I can imagine that both audit could benefit from a concept of a
> >>>>> namespace *path* that understands nesting (e.g. root/2/5/1 or
> >>>>> something along those lines). Mapping these to "containers" belongs
> >>>>> in userspace, I think.
> >>>> It might be helpful to climb up a few levels in this thread ...
> >>>>
> >>>> I think we all agree that containers are not a kernel construct. I further
> >>>> believe that the kernel has no business generating container IDs, those should
> >>>> come from userspace and will likely be different depending on how you define
> >>>> "container". However, what is less clear to me at this point is how the
> >>>> kernel should handle the setting, reporting, and general management of this
> >>>> container ID token.
> >>>>
> >>> Wouldn't the easiest thing be to just treat add a containerid to the
> >>> process context like auid.
> >>
> >> I believe so. At least that was the point I was trying to get across
> >> when I first jumped into this thread.
> >
> > It sounds nice but containers are not just a per process construct.
> > Sometimes you might know anamespace but not which process instigated
> > action to happen on that namespace.
>
> >From an auditing perspective I'm not sure we will ever hit those
> cases; did you have a particular example in mind?
The example that immediately came to mind when I first read Eric's
comment was a packet coming in off a network in a particular network
namespace. That could narrow it down to a subset of containers based on
which network namespace it inhabits, but since it isn't associated with
a particular task yet (other than a kernel thread) it will not be
possible to select the precise nsproxy, let alone the container.
> paul moore
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Maxime Coquelin @ 2015-05-19 13:17 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Thomas Gleixner, Daniel Lezcano, Uwe Kleine-König,
Andreas Färber, Geert Uytterhoeven, Rob Herring,
Philipp Zabel, Linus Walleij, Arnd Bergmann, Stefan Agner,
Peter Meerwald, Paul Bolle, Peter Hurley, Andy Shevchenko,
Chanwoo Choi, Joe Perches, Vladimir Zapolskiy, Lee Jones,
Daniel Thompson, Jonathan Corbet, Pawel Moll
In-Reply-To: <20150519130028.GF2067-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-05-19 15:00 GMT+02:00 Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>:
> On Tue, May 19, 2015 at 02:56:43PM +0200, Thomas Gleixner wrote:
>> Folks, can you please trim your replies. It's a PITA to scroll down
>> through several pages to find a single line of content.
>
> Absolutely right. Too many people do not do this, and it's a waste of
> readers time. Maybe we should start ignoring emails which contain only
> quoted mail in the first 50 lines.
>
> Also, cutting the rest of the email below the point which you've finished
> replying is good etiquette as well. I've seen a number of posts where
> people have added their signature mid-mail and left a huge chunk of quoted
> mail below. That's just not on either.
>
Ok, I will take care of that.
Sorry for the inconvenience,
Maxime
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Maxime Coquelin @ 2015-05-19 13:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Daniel Lezcano, Uwe Kleine-König, Andreas Färber,
Geert Uytterhoeven, Rob Herring, Philipp Zabel, Linus Walleij,
Stefan Agner, Peter Meerwald, Paul Bolle, Peter Hurley,
Andy Shevchenko, Chanwoo Choi, Russell King, Joe Perches,
Vladimir Zapolskiy, Lee Jones, Daniel Thompson, Jonathan Corbet,
Pawel Moll, Mark Rutland
In-Reply-To: <6177628.0ZDPLeVyah@wuerfel>
2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> Please also make it possible to select this driver on other architectures
> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
You proposal is to revert back to the original patch, except that
ARCH_STM32 should select CLKSRC_STM32, right?
Daniel, what do you think?
Regards,
Maxime
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Daniel Lezcano @ 2015-05-19 13:49 UTC (permalink / raw)
To: Maxime Coquelin, Arnd Bergmann
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Stefan Agner,
Peter Meerwald, Paul Bolle, Peter Hurley, Andy Shevchenko,
Chanwoo Choi, Russell King, Joe Perches, Vladimir Zapolskiy,
Lee Jones, Daniel Thompson, Jonathan Corbet, Pawel Moll,
Mark Rutland, Ian Campbell
In-Reply-To: <CALszF6BZKD-CPTZ6Hc85wv2Z3Y7JmUv-cMkBtbk2Ga6WeeWU=A@mail.gmail.com>
On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
>> Please also make it possible to select this driver on other architectures
>> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
>
> You proposal is to revert back to the original patch, except that
> ARCH_STM32 should select CLKSRC_STM32, right?
>
> Daniel, what do you think?
It is not exactly as the initial patch.
I think Arnd is proposing:
config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if COMPILE_TEST
select CLKSRC_MMIO
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Arnd Bergmann @ 2015-05-19 14:05 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Mark Rutland, linux-doc@vger.kernel.org, Linus Walleij,
Will Deacon, Stefan Agner, Nikolay Borisov, Peter Meerwald,
linux-api@vger.kernel.org, Lee Jones, Kees Cook, Linux-Arch,
Daniel Thompson, Russell King, Jonathan Corbet, Jiri Slaby,
Mauro Carvalho Chehab, Chanwoo Choi, Andy Shevchenko,
Antti Palosaari, Geert Uytterhoeven, linux-serial@vger.kernel.org,
Uwe
In-Reply-To: <555B3F80.8070605@linaro.org>
On Tuesday 19 May 2015 15:49:52 Daniel Lezcano wrote:
> On 05/19/2015 03:42 PM, Maxime Coquelin wrote:
> > 2015-05-19 12:55 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> >> Please also make it possible to select this driver on other architectures
> >> with COMPILE_TEST, so we get coverage from all the x86 test infrastructure.
> >
> > You proposal is to revert back to the original patch, except that
> > ARCH_STM32 should select CLKSRC_STM32, right?
> >
> > Daniel, what do you think?
>
> It is not exactly as the initial patch.
>
> I think Arnd is proposing:
>
> config CLKSRC_STM32
> bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> select CLKSRC_MMIO
Yes, that's fine, although we might also need a 'depends on OF'
line, not sure.
Arnd
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Paul Moore @ 2015-05-19 14:27 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Eric W. Biederman, Linux API, Linux Containers,
linux-kernel@vger.kernel.org, Andy Lutomirski, linux-audit,
Al Viro, Network Development, Linux FS Devel, Eric Paris,
Serge E. Hallyn
In-Reply-To: <20150519130911.GB20131@madcap2.tricolour.ca>
On Tue, May 19, 2015 at 9:09 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 15/05/16, Paul Moore wrote:
>> On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman wrote:
>> > It sounds nice but containers are not just a per process construct.
>> > Sometimes you might know anamespace but not which process instigated
>> > action to happen on that namespace.
>>
>> From an auditing perspective I'm not sure we will ever hit those
>> cases; did you have a particular example in mind?
>
> The example that immediately came to mind when I first read Eric's
> comment was a packet coming in off a network in a particular network
> namespace. That could narrow it down to a subset of containers based on
> which network namespace it inhabits, but since it isn't associated with
> a particular task yet (other than a kernel thread) it will not be
> possible to select the precise nsproxy, let alone the container.
Thanks, I was stuck thinking about syscall based auditing and forgot
about the various LSM based audit records. Of all people you would
think I would remember per-packet audit records ;)
Anyway, in this case I think including the namespace ID is sufficient,
largely because the container userspace doesn't have access to the
packet at this point. In order to actually receive the data the
container's userspace will need to issue a syscall where we can
include the container ID. An overly zealous security officer who
wants to trace all the kernel level audit events, like the one you
describe, can match up the namespace to a container in post-processing
if needed.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Maxime Coquelin @ 2015-05-19 14:41 UTC (permalink / raw)
To: Daniel Lezcano, Arnd Bergmann
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Stefan Agner,
Peter Meerwald, Paul Bolle, Peter Hurley, Andy Shevchenko,
Chanwoo Choi, Russell King, Joe Perches, Vladimir Zapolskiy,
Lee Jones, Daniel Thompson, Jonathan Corbet, Pawel Moll,
Mark Rutland, Ian Campbell
In-Reply-To: <555B3F80.8070605@linaro.org>
2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
>
>
> It is not exactly as the initial patch.
>
> I think Arnd is proposing:
>
> config CLKSRC_STM32
> bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> select CLKSRC_MMIO
>
Isn't "depends on OF" missing for COMPILE_TEST case?
Other than that, I'm fine with the proposal.
Daniel, is it the case for you too?
Regards,
Maxime
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Russell King - ARM Linux @ 2015-05-19 14:50 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Daniel Lezcano, Arnd Bergmann, Uwe Kleine-König,
Andreas Färber, Geert Uytterhoeven, Rob Herring,
Philipp Zabel, Linus Walleij, Stefan Agner, Peter Meerwald,
Paul Bolle, Peter Hurley, Andy Shevchenko, Chanwoo Choi,
Joe Perches, Vladimir Zapolskiy, Lee Jones, Daniel Thompson,
Jonathan Corbet, Pawel Moll, Mark Rutland
In-Reply-To: <CALszF6A-De6dvcRNoa9ruL+y6Wt_rc7bi-O-VxHWkFF9NSt5_g@mail.gmail.com>
On Tue, May 19, 2015 at 04:41:58PM +0200, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> >
> >
> > It is not exactly as the initial patch.
> >
> > I think Arnd is proposing:
> >
> > config CLKSRC_STM32
> > bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> > select CLKSRC_MMIO
> >
>
> Isn't "depends on OF" missing for COMPILE_TEST case?
config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if COMPILE_TEST
depends on OF
select CLKSRC_MMIO
This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
it's always going to be for that case, right?) while allowing the option
to be visible when both OF!=n and COMPILE_TEST!=n.
Remember,
bool "string" if <condition-affects-visibility-of-string>
depends on <condition-affects-config-symbol-availability>
The former merely hides the option from the user _if_ the condition fails.
The latter _disables_ the option completely (except if you try and select
it, at which point you end up with a Kconfig warning about that.)
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU
From: Peter Zijlstra @ 2015-05-19 14:53 UTC (permalink / raw)
To: Robert Bragg
Cc: dri-devel, David Airlie, linux-api, intel-gfx, linux-kernel,
Ingo Molnar, Paul Mackerras, Arnaldo Carvalho de Melo,
Daniel Vetter
In-Reply-To: <CAMou1-1Q1_kKGrRPz36Fox=gxhGF6v+DiR5HZ6TOyQyxtMsysA@mail.gmail.com>
On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote:
> On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote:
> >
> >> I've changed the uapi for configuring the i915_oa specific attributes
> >> when calling perf_event_open(2) whereby instead of cramming lots of
> >> bitfields into the perf_event_attr config members, I'm now
> >> daisy-chaining a drm_i915_oa_event_attr_t structure off of a single
> >> config member that's extensible and validated in the same way as the
> >> perf_event_attr struct. I've found this much nicer to work with while
> >> being neatly extensible too.
> >
> > This worries me a bit.. is there more background for this?
>
> Would it maybe be helpful to see the before and after? I had kept this
> uapi change in a separate patch for a while locally but in the end
> decided to squash it before sending out my updated series.
>
> Although I did find it a bit awkward with the bitfields, I was mainly
> concerned about the extensibility of packing logically separate
> attributes into the config members and had heard similar concerns from
> a few others who had been experimenting with my patches too.
>
> A few simple attributes I can think of a.t.m that we might want to add
> in the future are:
> - control of the OABUFFER size
> - a way to ask the kernel to collect reports at the beginning and end
> of batch buffers, in addition to periodic reports
> - alternative ways to uniquely identify a context to support tools
> profiling a single context not necessarily owned by the current
> process
>
> It could also be interesting to expose some counter configuration
> through these attributes too. E.g. on Broadwell+ we have 14 'Flexible
> EU' counters included in the OA unit reports, each with a 16bit
> configuration.
>
> In a more extreme case it might also be useful to allow userspace to
> specify a complete counter config, which (depending on the
> configuration) could be over 100 32bit values to select the counter
> signals + configure the corresponding combining logic.
>
> Since this pmu is in a device driver it also seemed reasonably
> appropriate to de-couple it slightly from the core perf_event_attr
> structure by allowing driver extensible attributes.
>
> I wonder if it might be less worrisome if the i915_oa_copy_attr() code
> were instead a re-usable utility perhaps maintained in events/core.c,
> so if other pmu drivers were to follow suite there would be less risk
> of a mistake being made here?
So I had a peek at:
https://01.org/sites/default/files/documentation/observability_performance_counters_haswell.pdf
In an attempt to inform myself of how the hardware worked. But the
document is rather sparse (and does not include broadwell).
So from what I can gather there's two ways to observe the counters,
through MMIO or trough the ring-buffer, which in turn seems triggered by
a MI_REPORT_PERF_COUNT command.
[ Now the document talks about shortcomings of this scheme, where the
MI_REPORT_PERF_COUNT command can only be placed every other command, but
a single command can contain so much computation that this is not fine
grained enough -- leading to the suggestion of a timer/cycle based
reporting, but that is not actually mentioned afaict ]
Now the MI_REPORT_PERF_COUNT can select a vector (Counter Select) of
which events it will write out.
This covers the regular 'A' counters. Is this correct?
Then there are the 'B' counters, which appear to be programmable through
the CEC MMIO registers.
These B events can also be part of the MI_REPORT_PERF_COUNT vector.
Right?
So for me the 'natural' way to represent this in perf would be through
event groups. Create a perf event for every single event -- yes this is
53 events.
Use the MMIO reads for the regular read() interface, and use a hrtimer
placing MI_REPORT_PERF_COUNT commands, with a counter select mask
covering the all events in the current group, for sampling.
Then obtain the vector values using PERF_SAMPLE_READ and
PERF_FORMAT_READ -- and use the read txn support to consume the
ring-buffer vectors instead of the MMIO registers.
You can use the perf_event_attr::config to select the counter (A0-A44,
B0-B7) and use perf_event_attr::config1 (low and high dword) for the
corresponding CEC registers.
This does not require random per driver ABI extentions for
perf_event_attr, nor your custom output format.
Am I missing something obvious here?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Daniel Lezcano @ 2015-05-19 15:03 UTC (permalink / raw)
To: Maxime Coquelin, Arnd Bergmann
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Stefan Agner,
Peter Meerwald, Paul Bolle, Peter Hurley, Andy Shevchenko,
Chanwoo Choi, Russell King, Joe Perches, Vladimir Zapolskiy,
Lee Jones, Daniel Thompson, Jonathan Corbet, Pawel Moll,
Mark Rutland, Ian Campbell
In-Reply-To: <CALszF6A-De6dvcRNoa9ruL+y6Wt_rc7bi-O-VxHWkFF9NSt5_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 05/19/2015 04:41 PM, Maxime Coquelin wrote:
> 2015-05-19 15:49 GMT+02:00 Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>
>>
>> It is not exactly as the initial patch.
>>
>> I think Arnd is proposing:
>>
>> config CLKSRC_STM32
>> bool "Clocksource for STM32 SoCs" if COMPILE_TEST
>> select CLKSRC_MMIO
>>
>
> Isn't "depends on OF" missing for COMPILE_TEST case?
Hmm, yes. Probably.
> Other than that, I'm fine with the proposal.
> Daniel, is it the case for you too?
Yep.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v8 09/16] clockevents/drivers: Add STM32 Timer driver
From: Maxime Coquelin @ 2015-05-19 15:34 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Daniel Lezcano, Arnd Bergmann, Uwe Kleine-König,
Andreas Färber, Geert Uytterhoeven, Rob Herring,
Philipp Zabel, Linus Walleij, Stefan Agner, Peter Meerwald,
Paul Bolle, Peter Hurley, Andy Shevchenko, Chanwoo Choi,
Joe Perches, Vladimir Zapolskiy, Lee Jones, Daniel Thompson,
Jonathan Corbet, Pawel Moll, Mark Rutland
In-Reply-To: <20150519145006.GH2067@n2100.arm.linux.org.uk>
2015-05-19 16:50 GMT+02:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> config CLKSRC_STM32
> bool "Clocksource for STM32 SoCs" if COMPILE_TEST
> depends on OF
> select CLKSRC_MMIO
>
> This permits CLKSRC_STM32 to be selected by STM32 (provided OF is enabled,
> it's always going to be for that case, right?) while allowing the option
> to be visible when both OF!=n and COMPILE_TEST!=n.
Yes OF is always enabled when STM32.
So it fits our needs, as we only want the option to be visible when
both OF!=n and COMPILE_TEST!=n.
>
> Remember,
>
> bool "string" if <condition-affects-visibility-of-string>
> depends on <condition-affects-config-symbol-availability>
>
> The former merely hides the option from the user _if_ the condition fails.
> The latter _disables_ the option completely (except if you try and select
> it, at which point you end up with a Kconfig warning about that.)
Thanks for the reminder!
Maxime
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Christoph Lameter @ 2015-05-19 15:37 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, Serge Hallyn, Andrew Morton, Jarkko Sakkinen,
Ted Ts'o, Andrew G. Morgan, Linux API, Mimi Zohar,
Michael Kerrisk, Austin S Hemmelgarn, linux-security-module,
Aaron Jones, Serge Hallyn, LKML, Markku Savela, Kees Cook,
Jonathan Corbet
In-Reply-To: <CALCETrXKRt9MJQEZc=EEGMFB_vwKDQbZ7ReMNqE-5tRTxxJu2Q@mail.gmail.com>
On Mon, 18 May 2015, Andy Lutomirski wrote:
> > Could you provide an example to demonstrate how it is to be used?
> > Something similar to what I had in my patch?
> >
>
> Do you mean something like:
>
> setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service
> --euid=500 --ruid=500 bash
Ok that means we also depend on a tool upgrade.
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Andy Lutomirski @ 2015-05-19 17:20 UTC (permalink / raw)
To: Christoph Lameter
Cc: Jarkko Sakkinen, Ted Ts'o, Andrew G. Morgan, Andrew Morton,
Serge Hallyn, Michael Kerrisk, Mimi Zohar, Linux API,
Austin S Hemmelgarn, linux-security-module, Aaron Jones, LKML,
Serge Hallyn, Markku Savela, Kees Cook, Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1505191036490.28005@gentwo.org>
On May 19, 2015 8:37 AM, "Christoph Lameter" <cl@linux.com> wrote:
>
> On Mon, 18 May 2015, Andy Lutomirski wrote:
>
> > > Could you provide an example to demonstrate how it is to be used?
> > > Something similar to what I had in my patch?
> > >
> >
> > Do you mean something like:
> >
> > setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service
> > --euid=500 --ruid=500 bash
>
> Ok that means we also depend on a tool upgrade.
>
I think this is unavoidable, unless we want to change the semantics of
inheritable caps, and that would open a giant can of worms.
--Andy
^ permalink raw reply
* Re: [PATCH man-pages v2] capabilities.7, prctl.2: Document ambient capabilities
From: Andy Lutomirski @ 2015-05-19 17:21 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Andy Lutomirski, Serge Hallyn, Andrew Morton, Jarkko Sakkinen,
Ted Ts'o, Andrew G. Morgan, Linux API, Mimi Zohar,
Austin S Hemmelgarn, linux-security-module, Aaron Jones,
Serge Hallyn, LKML, Markku Savela, Kees Cook, Jonathan Corbet
In-Reply-To: <555AECC3.4040408@gmail.com>
On Tue, May 19, 2015 at 12:56 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> Hi Andy,
>
> Thanks for this patch. There are some broken pieces though. Also,
> I have some minor questions about the API design. See below.
>
> On 05/15/2015 08:43 AM, Andy Lutomirski wrote:
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>> ---
>>
>> There was no v1. I'm calling this v2 to keep it in sync with the kernel
>> patch versioning.
>>
>> man2/prctl.2 | 10 ++++++++++
>> man7/capabilities.7 | 32 ++++++++++++++++++++++++++------
>> 2 files changed, 36 insertions(+), 6 deletions(-)
>>
>> diff --git a/man2/prctl.2 b/man2/prctl.2
>> index b352f6283624..5861e3aefe9a 100644
>> --- a/man2/prctl.2
>> +++ b/man2/prctl.2
>> @@ -949,6 +949,16 @@ had been called.
>> For further information on Intel MPX, see the kernel source file
>> .IR Documentation/x86/intel_mpx.txt .
>> .\"
>> +.TP
>> +.BR PR_CAP_AMBIENT " (since Linux 4.2)"
>> +Reads or changes the ambient capability set. If arg2 is PR_CAP_AMBIENT_RAISE,
>> +then the capability specified in arg3 is added to the ambient set. This will
>> +fail, returning EPERM, if the capability is not already both permitted and
>> +inheritable or if the SECBIT_NO_CAP_AMBIENT_RAISE securebit is set. If arg2
>> +is PR_CAP_AMBIENT_LOWER, then the capability specified in arg3 is removed
>> +from the ambient set. If arg2 is PR_CAP_AMBIENT_GET, then
>> +.BR prctl (2)
>> +will return 1 if the capability in arg3 is in the ambient set and 0 if not.
>
> Some API design questions:
>
> 1. We already have prctl() operations that work on some capability sets:
> PR_CAPBSET_READ and PR_CAPBSET_DROP. These don't use arg3; the operation
> is directly encoded in the first argument of prctl(). Just to keep some
> consistency, why not do things the same way for these new operations?
I'm torn. On the one hand, consistency is nice. On the other hand,
prctl is a mess and trying to organize new additions seems like a good
idea.
>
> Also, you could opt for some consistency in the naming, so using "READ"
> rather than "GET", for example. On the other hand, both "READ" and "GET"
> are suboptimal names: this is really a test operation. So, maybe a
> clean break to a good name, PR_CAP_AMBIENT_IS_SET, is best?
I like IS_SET.
>
> Thus:
>
> prctl(PR_CAP_AMBIENT_READ, cap, 0, 0, 0); // or PR_CAP_AMBIENT_IS_SET?
> prctl(PR_CAP_AMBIENT_RAISE, cap, 0, 0, 0);
> prctl(PR_CAP_AMBIENT_LOWER, cap, 0, 0, 0);
>
> 2. In terms of the API design, would it be useful to have a prctl() operation
> that clears the entire ambient set?
>
> prctl(PR_CAP_AMBIENT_ZERO, 0, 0, 0, 0); // or PR_CAP_AMBIENT_EMPTY?
Seems like a good idea. How about _CLEAR?
>
>> .SH RETURN VALUE
>> On success,
>> .BR PR_GET_DUMPABLE ,
>> diff --git a/man7/capabilities.7 b/man7/capabilities.7
>> index d75ec65de05b..dae62f0be3b7 100644
>> --- a/man7/capabilities.7
>> +++ b/man7/capabilities.7
>> @@ -697,13 +697,26 @@ a program whose associated file capabilities grant that capability).
>> .IR Inheritable :
>> This is a set of capabilities preserved across an
>> .BR execve (2).
>> -It provides a mechanism for a process to assign capabilities
>> -to the permitted set of the new program during an
>> -.BR execve (2).
>> +Inheritable capabilities remain inheritable when executing any program,
>> +and inheritable capabilities are added to the permitted set when executing
>> +a program that has the corresponding bits set in the file inheritable set.
>> +When executing programs without file capabilities, ambient capabilities
>
> That last line is incomplete. Something needs adding/removing.
Whoops, will fix.
>
>> .TP
>> .IR Effective :
>> This is the set of capabilities used by the kernel to
>> perform permission checks for the thread.
>> +.TP
>> +.IR Ambient " (since Linux 4.2) :"
>
> Minor knit: s/ :/:/ for next version.
Will fix.
>
>> +This is a set of capabilities that are preserved across an
>> +.BR execve (2)
>> +of a program that does not have file capabilities. The ambient capability
>> +set obeys the invariant that no capability can ever be ambient if it is
>> +not both permitted and inheritable. Ambient capabilities are, with some
>> +exceptions, preserved in the permitted set and added to the effective
>> +set when
>> +.BR execve (2)
>> +is called. The ambient capability set is modified using
>> +.BR prctl (2).
>
> I think it would be helpful to add a couple of sentences here on why the
> ambient set is useful (i.e., explain what deficiencies in the pre-existing
> API are addressed by the addition of this set--a brief piece from your
> 1/2 patch, for example).
Will do.
--Andy
^ permalink raw reply
* Re: [Y2038] kernel/libc uapi changes for y2038
From: John Stultz @ 2015-05-19 17:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux API, klibc, libc-alpha, y2038 Mailman List, musl, lkml,
Rich Felker, cferris, Elliott Hughes, Joseph S. Myers
In-Reply-To: <2664016.bYZKg6FQqR@wuerfel>
On Mon, May 18, 2015 at 2:53 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> In the patch series I posted recently [1], I introduce new system calls to deal
> with modified data structures, but left the question open on how these should
> be best accessed from libc. The patches introduce a new __kernel_time64_t type
> and based on that five new data structured: struct __kernel_timespec,
> struct __kernel_itimerspec, struct __kernel_stat, struct __kernel_rusage,
> and struct __kernel_timex. This works fine for the case when all libc
> implementations provide their own definitions to user space, but not for
> the simplest case (e.g. klibc) where the user-visible structures come directly
> from the kernel uapi headers.
>
> I still don't know what model the various libc developers prefer, so here is
> an alternative approach, as a patch on top of the previous series:
>
> Now, we rename the original structures to struct __old_kernel_*, and use a
> macro to define either the __old_kernel_* or the __kernel_* structure name
> to the name we actually want in user space, based on a __KERNEL_TIME_BITS
> macro that can be set to either 32 or 64 for 32-bit architectures by
> the libc. Depending on that macro, the compiler will either see one
> of these combinations (for each of the five structures):
>
> a) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 32:
>
> struct timespec based on 32-bit __kernel_time_t
> struct __kernel_timespec based on 64-bit __kernel_time64_t
>
> b) __BITS_PER_LONG == 64 && __KERNEL_TIME_BITS == 64:
>
> struct timespec based on 64-bit __kernel_time_t
> struct __kernel_timespec based on 64-bit __kernel_time64_t
>
> c) __BITS_PER_LONG == 32 && __KERNEL_TIME_BITS == 64:
>
> struct __old_kernel_timespec based on 32-bit __kernel_time_t
> struct timespec based on 64-bit __kernel_time64_t
>
> Would this work for everyone? Any alternative suggestions?
>
> Arnd
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/log/?h=y2038-syscalls
> https://lwn.net/Articles/643407/
>
> diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> index 23e6c416b85f..ecdaf4f77f35 100644
> --- a/include/uapi/asm-generic/bitsperlong.h
> +++ b/include/uapi/asm-generic/bitsperlong.h
> @@ -12,4 +12,13 @@
> #define __BITS_PER_LONG 32
> #endif
>
> +/*
> + * Traditionally we define defines 'time_t' as 'long', but we need to
> + * migrate to a 64-bit type until 2038. This one is designed to be
> + * overridden by user space if it's prepared to handle 64-bit time_t.
> + */
> +#ifndef __KERNEL_TIME_BITS
> +#define __KERNEL_TIME_BITS __BITS_PER_LONG
> +#endif
> +
> #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
> diff --git a/include/uapi/asm-generic/kernel_stat.h b/include/uapi/asm-generic/kernel_stat.h
> index d1db22583046..3693496c78aa 100644
> --- a/include/uapi/asm-generic/kernel_stat.h
> +++ b/include/uapi/asm-generic/kernel_stat.h
> @@ -1,6 +1,14 @@
> #ifndef __ASM_GENERIC_KERNEL_STAT_H
> #define __ASM_GENERIC_KERNEL_STAT_H
>
> +#include <asm/bitsperlong.h>
> +
> +#if __KERNEL_TIME_BITS == 32 || __BITS_PER_LONG == 64
> +#define __old_kernel_stat2 stat
> +#else
> +#define __kernel_stat stat
> +#endif
> +
> /*
> * The new structure that works on both 32-bit and 64-bit and survives y2038
> * The layout matches 'struct stat' from asm-generic/stat.h on 64-bit
> diff --git a/include/uapi/asm-generic/stat.h b/include/uapi/asm-generic/stat.h
> index 64c32ba7c1a9..f66b28b96c8d 100644
> --- a/include/uapi/asm-generic/stat.h
> +++ b/include/uapi/asm-generic/stat.h
> @@ -22,7 +22,7 @@
>
> #define STAT_HAVE_NSEC 1
>
> -struct stat {
> +struct __old_kernel_stat2 {
> unsigned long st_dev; /* Device. */
> unsigned long st_ino; /* File serial number. */
> unsigned int st_mode; /* File mode. */
> diff --git a/include/uapi/linux/resource.h b/include/uapi/linux/resource.h
> index c4f3ba44db00..9a3876cc4436 100644
> --- a/include/uapi/linux/resource.h
> +++ b/include/uapi/linux/resource.h
> @@ -3,10 +3,16 @@
>
> #include <linux/time.h>
> #include <linux/types.h>
> +#include <asm/bitsperlong.h>
>
> /*
> * Resource control/accounting header file for linux
> */
> +#if __KERNEL_TIME_BITS == 32 || __BITS_PER_LONG == 64
> +#define __old_kernel_rusage rusage
> +#else
> +#define __kernel_rusage rusage
> +#endif
This all looks ok to me. Though I wonder if it would be cleaner to
have all these conditional definitions in one header, rather then
littered about in a ton of files.
I'm torn because having the definitions close to the underlying
structure helps folks reading through the code, but it still seems a
little bit messy.
thanks
-john
^ permalink raw reply
* Re: [PATCH man-pages v2] capabilities.7, prctl.2: Document ambient capabilities
From: Michael Kerrisk (man-pages) @ 2015-05-19 19:13 UTC (permalink / raw)
To: Andy Lutomirski
Cc: mtk.manpages, Andy Lutomirski, Serge Hallyn, Andrew Morton,
Jarkko Sakkinen, Ted Ts'o, Andrew G. Morgan, Linux API,
Mimi Zohar, Austin S Hemmelgarn, linux-security-module,
Aaron Jones, Serge Hallyn, LKML, Markku Savela, Kees Cook,
Jonathan Corbet
In-Reply-To: <CALCETrWn2zB2reYjXbA5iUJpwwZ-0S2tr3Q1nS2+Z-Rcir2udQ@mail.gmail.com>
Hi Andy,
On 05/19/2015 07:21 PM, Andy Lutomirski wrote:
> On Tue, May 19, 2015 at 12:56 AM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> Hi Andy,
>>
>> Thanks for this patch. There are some broken pieces though. Also,
>> I have some minor questions about the API design. See below.
>>
>> On 05/15/2015 08:43 AM, Andy Lutomirski wrote:
>>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>>> ---
>>>
>>> There was no v1. I'm calling this v2 to keep it in sync with the kernel
>>> patch versioning.
>>>
>>> man2/prctl.2 | 10 ++++++++++
>>> man7/capabilities.7 | 32 ++++++++++++++++++++++++++------
>>> 2 files changed, 36 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/man2/prctl.2 b/man2/prctl.2
>>> index b352f6283624..5861e3aefe9a 100644
>>> --- a/man2/prctl.2
>>> +++ b/man2/prctl.2
>>> @@ -949,6 +949,16 @@ had been called.
>>> For further information on Intel MPX, see the kernel source file
>>> .IR Documentation/x86/intel_mpx.txt .
>>> .\"
>>> +.TP
>>> +.BR PR_CAP_AMBIENT " (since Linux 4.2)"
>>> +Reads or changes the ambient capability set. If arg2 is PR_CAP_AMBIENT_RAISE,
>>> +then the capability specified in arg3 is added to the ambient set. This will
>>> +fail, returning EPERM, if the capability is not already both permitted and
>>> +inheritable or if the SECBIT_NO_CAP_AMBIENT_RAISE securebit is set. If arg2
>>> +is PR_CAP_AMBIENT_LOWER, then the capability specified in arg3 is removed
>>> +from the ambient set. If arg2 is PR_CAP_AMBIENT_GET, then
>>> +.BR prctl (2)
>>> +will return 1 if the capability in arg3 is in the ambient set and 0 if not.
>>
>> Some API design questions:
>>
>> 1. We already have prctl() operations that work on some capability sets:
>> PR_CAPBSET_READ and PR_CAPBSET_DROP. These don't use arg3; the operation
>> is directly encoded in the first argument of prctl(). Just to keep some
>> consistency, why not do things the same way for these new operations?
>
> I'm torn. On the one hand, consistency is nice. On the other hand,
> prctl is a mess
Agreed.
> and trying to organize new additions seems like a good
> idea.
Sure, but what is your organizing principle here? (I don't feel strongly
about it, but it's not clear to me what trumps the (mild) degree of
consistency that I suggest.)
>> Also, you could opt for some consistency in the naming, so using "READ"
>> rather than "GET", for example. On the other hand, both "READ" and "GET"
>> are suboptimal names: this is really a test operation. So, maybe a
>> clean break to a good name, PR_CAP_AMBIENT_IS_SET, is best?
>
> I like IS_SET.
Okay.
>> Thus:
>>
>> prctl(PR_CAP_AMBIENT_READ, cap, 0, 0, 0); // or PR_CAP_AMBIENT_IS_SET?
>> prctl(PR_CAP_AMBIENT_RAISE, cap, 0, 0, 0);
>> prctl(PR_CAP_AMBIENT_LOWER, cap, 0, 0, 0);
>>
>> 2. In terms of the API design, would it be useful to have a prctl() operation
>> that clears the entire ambient set?
>>
>> prctl(PR_CAP_AMBIENT_ZERO, 0, 0, 0, 0); // or PR_CAP_AMBIENT_EMPTY?
>
> Seems like a good idea. How about _CLEAR?
Also good.
[...]
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Christoph Lameter @ 2015-05-19 20:03 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jarkko Sakkinen, Ted Ts'o, Andrew G. Morgan, Andrew Morton,
Serge Hallyn, Michael Kerrisk, Mimi Zohar, Linux API,
Austin S Hemmelgarn, linux-security-module, Aaron Jones, LKML,
Serge Hallyn, Markku Savela, Kees Cook, Jonathan Corbet
In-Reply-To: <CALCETrV1+3ZuL0MkqQaRoQ8r2V=EcQQEodOdCdP0p-BK1PixGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 19 May 2015, Andy Lutomirski wrote:
> On May 19, 2015 8:37 AM, "Christoph Lameter" <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On Mon, 18 May 2015, Andy Lutomirski wrote:
> >
> > > > Could you provide an example to demonstrate how it is to be used?
> > > > Something similar to what I had in my patch?
> > > >
> > >
> > > Do you mean something like:
> > >
> > > setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service
> > > --euid=500 --ruid=500 bash
> >
> > Ok that means we also depend on a tool upgrade.
> >
>
> I think this is unavoidable, unless we want to change the semantics of
> inheritable caps, and that would open a giant can of worms.
Ok then include a patch and references to that material. Or did I just not
see that?
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Andy Lutomirski @ 2015-05-19 20:07 UTC (permalink / raw)
To: Christoph Lameter
Cc: Jarkko Sakkinen, Ted Ts'o, Andrew G. Morgan, Andrew Morton,
Serge Hallyn, Michael Kerrisk, Mimi Zohar, Linux API,
Austin S Hemmelgarn, linux-security-module, Aaron Jones, LKML,
Serge Hallyn, Markku Savela, Kees Cook, Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1505191502570.31044-gkYfJU5Cukgdnm+yROfE0A@public.gmane.org>
On Tue, May 19, 2015 at 1:03 PM, Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, 19 May 2015, Andy Lutomirski wrote:
>
>> On May 19, 2015 8:37 AM, "Christoph Lameter" <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote:
>> >
>> > On Mon, 18 May 2015, Andy Lutomirski wrote:
>> >
>> > > > Could you provide an example to demonstrate how it is to be used?
>> > > > Something similar to what I had in my patch?
>> > > >
>> > >
>> > > Do you mean something like:
>> > >
>> > > setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service
>> > > --euid=500 --ruid=500 bash
>> >
>> > Ok that means we also depend on a tool upgrade.
>> >
>>
>> I think this is unavoidable, unless we want to change the semantics of
>> inheritable caps, and that would open a giant can of worms.
>
> Ok then include a patch and references to that material. Or did I just not
> see that?
>
It's in the cover letter, rather vaguely. I think I want to change
the setpriv syntax a bit before sending it upstream, though -- it's
sucks that you have to duplicate the option.
Perhaps the ambient-caps option should implicitly raise inheritable
caps if they're not already raised. Or maybe the absence of an
inh-caps rule should cause any requested ambient caps to be made
inheritable as well.
--Andy
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Aaron Jones @ 2015-05-19 20:22 UTC (permalink / raw)
To: Andy Lutomirski, Christoph Lameter
Cc: Jarkko Sakkinen, Ted Ts'o, Andrew G. Morgan, Andrew Morton,
Serge Hallyn, Michael Kerrisk, Mimi Zohar, Linux API,
Austin S Hemmelgarn, linux-security-module, LKML, Serge Hallyn,
Markku Savela, Kees Cook, Jonathan Corbet
In-Reply-To: <CALCETrW6DndOnC5ego+R5rwjoXeFo04cSO4Z2qZnhiJpEPBE=Q@mail.gmail.com>
On 19/05/15 20:07, Andy Lutomirski wrote:> It's in the cover letter,
rather vaguely. I think I want to change
> the setpriv syntax a bit before sending it upstream, though -- it's
> sucks that you have to duplicate the option.
>
> Perhaps the ambient-caps option should implicitly raise inheritable
> caps if they're not already raised. Or maybe the absence of an
> inh-caps rule should cause any requested ambient caps to be made
> inheritable as well.
>
> --Andy
I propose an additional --ambient-inh option to copy everything from
--inh-caps to the ambient set. Explicit is better than implicit.
--
Aaron Jones
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox