[PATCH v5 07/21] tpm: move tpm_getcap to tpm1-cmd.c
1. Move tpm_getcap to tpm1-cmd. Rename the function to tpm1_getcap.
2. Remove unused tpm_getcap_header with unused constant
as this functionality is already implemented using tpm_buf construct.
Fixes warning:
drivers/char/tpm/tpm-interface.c:452:38: warning: ‘tpm_getcap_header’ defined
but not used [-Wunused-const-variable=]
static const struct tpm_input_header tpm_getcap_header = {
^
3. Drop unused TPM_DIGEST_SIZE. It's already defined in
include/linux/tpm.h
Signed-off-by: Tomas Winkler
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
---
V2-V3: Rebase
V4-V5: Resend
drivers/char/tpm/tpm-interface.c | 47 +---
drivers/char/tpm/tpm-sysfs.c | 48 ++---
drivers/char/tpm/tpm.h | 4 ++--
drivers/char/tpm/tpm1-cmd.c | 51 +---
drivers/char/tpm/tpm_tis_core.c | 2 +-
5 files changed, 71 insertions(+), 81 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index ac73e6ac3d83..a94a88f9f91c 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -454,52 +454,6 @@ int tpm_startup(struct tpm_chip *chip)
return rc;
}
-#define TPM_DIGEST_SIZE 20
-#define TPM_RET_CODE_IDX 6
-#define TPM_INTERNAL_RESULT_SIZE 200
-#define TPM_ORD_GET_CAP 101
-#define TPM_ORD_GET_RANDOM 70
-
-static const struct tpm_input_header tpm_getcap_header = {
- .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
- .length = cpu_to_be32(22),
- .ordinal = cpu_to_be32(TPM_ORD_GET_CAP)
-};
-
-ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
- const char *desc, size_t min_cap_length)
-{
- struct tpm_buf buf;
- int rc;
-
- rc = tpm_buf_init(, TPM_TAG_RQU_COMMAND, TPM_ORD_GET_CAP);
- if (rc)
- return rc;
-
- if (subcap_id == TPM_CAP_VERSION_1_1 ||
- subcap_id == TPM_CAP_VERSION_1_2) {
- tpm_buf_append_u32(, subcap_id);
- tpm_buf_append_u32(, 0);
- } else {
- if (subcap_id == TPM_CAP_FLAG_PERM ||
- subcap_id == TPM_CAP_FLAG_VOL)
- tpm_buf_append_u32(, TPM_CAP_FLAG);
- else
- tpm_buf_append_u32(, TPM_CAP_PROP);
-
- tpm_buf_append_u32(, 4);
- tpm_buf_append_u32(, subcap_id);
- }
- rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE,
- min_cap_length, 0, desc);
- if (!rc)
- *cap = *(cap_t *)[TPM_HEADER_SIZE + 4];
-
- tpm_buf_destroy();
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_getcap);
-
int tpm_get_timeouts(struct tpm_chip *chip)
{
if (chip->flags & TPM_CHIP_FLAG_HAVE_TIMEOUTS)
@@ -857,6 +811,7 @@ int tpm_pm_resume(struct device *dev)
}
EXPORT_SYMBOL_GPL(tpm_pm_resume);
+#define TPM_ORD_GET_RANDOM 70
#define TPM_GETRANDOM_RESULT_SIZE 18
static const struct tpm_input_header tpm_getrandom_header = {
.tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index 83a77a445538..008515314ae3 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -106,9 +106,9 @@ static ssize_t pcrs_show(struct device *dev, struct
device_attribute *attr,
char *str = buf;
struct tpm_chip *chip = to_tpm_chip(dev);
- rc = tpm_getcap(chip, TPM_CAP_PROP_PCR, ,
- "attempting to determine the number of PCRS",
- sizeof(cap.num_pcrs));
+ rc = tpm1_getcap(chip, TPM_CAP_PROP_PCR, ,
+"attempting to determine the number of PCRS",
+sizeof(cap.num_pcrs));
if (rc)
return 0;
@@ -132,9 +132,9 @@ static ssize_t enabled_show(struct device *dev, struct
device_attribute *attr,
cap_t cap;
ssize_t rc;
- rc = tpm_getcap(to_tpm_chip(dev), TPM_CAP_FLAG_PERM, ,
- "attempting to determine the permanent enabled state",
- sizeof(cap.perm_flags));
+ rc = tpm1_getcap(to_tpm_chip(dev), TPM_CAP_FLAG_PERM, ,
+"attempting to determine the permanent enabled state",
+sizeof(cap.perm_flags));
if (rc)
return 0;
@@ -149,9 +149,9 @@ static ssize_t active_show(struct device *dev, struct
device_attribute *attr,
cap_t cap;
ssize_t rc;
- rc = tpm_getcap(to_tpm_chip(dev), TPM_CAP_FLAG_PERM, ,
- "attempting to determine the permanent active state",
- sizeof(cap.perm_flags));
+ rc = tpm1_getcap(to_tpm_chip(dev), TPM_CAP_FLAG_PERM, ,
+"attempting to determine the permanent active state",
+sizeof(cap.perm_flags));
[PATCH v5 16/21] tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure
1. Use tpm_buf in tpm1_get_random()
2. Fix comment in tpm_get_random() so it is clear that
the function is expected to return number of random bytes.
Signed-off-by: Tomas Winkler
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
---
V3: New in the series.
V4: Resend.
V5: A small adjustment in the kdoc.
drivers/char/tpm/tpm-interface.c | 2 +-
drivers/char/tpm/tpm.h | 11 --
drivers/char/tpm/tpm1-cmd.c | 84 +++-
3 files changed, 49 insertions(+), 48 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 98f9a0bbeed9..0af71d53d129 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -586,7 +586,7 @@ EXPORT_SYMBOL_GPL(tpm_pm_resume);
* @out: destination buffer for the random bytes
* @max: the max number of bytes to write to @out
*
- * Return: same as with tpm_transmit_cmd()
+ * Return: number of random bytes read or a negative error value.
*/
int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max)
{
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 4ccffbb56864..d6eca81a011a 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -396,20 +396,9 @@ struct tpm_pcrread_in {
* compiler warnings about stack frame size. */
#define TPM_MAX_RNG_DATA 128
-struct tpm_getrandom_out {
- __be32 rng_data_len;
- u8 rng_data[TPM_MAX_RNG_DATA];
-} __packed;
-
-struct tpm_getrandom_in {
- __be32 num_bytes;
-} __packed;
-
typedef union {
struct tpm_pcrread_in pcrread_in;
struct tpm_pcrread_out pcrread_out;
- struct tpm_getrandom_in getrandom_in;
- struct tpm_getrandom_out getrandom_out;
} tpm_cmd_params;
struct tpm_cmd_t {
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 8a84db315676..b5c4fa158c30 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -505,58 +505,70 @@ ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id,
cap_t *cap,
EXPORT_SYMBOL_GPL(tpm1_getcap);
#define TPM_ORD_GET_RANDOM 70
-#define TPM_GETRANDOM_RESULT_SIZE 18
-static const struct tpm_input_header tpm_getrandom_header = {
- .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
- .length = cpu_to_be32(14),
- .ordinal = cpu_to_be32(TPM_ORD_GET_RANDOM)
-};
+struct tpm1_get_random_out {
+ __be32 rng_data_len;
+ u8 rng_data[TPM_MAX_RNG_DATA];
+} __packed;
-int tpm1_get_random(struct tpm_chip *chip, u8 *out, size_t max)
+/**
+ * tpm1_get_random() - get random bytes from the TPM's RNG
+ * @chip: a tpm_chip instance
+ * @dest: destination buffer for the random bytes
+ * @max: the maximum number of bytes to write to @dest
+ *
+ * Return:
+ * * number of bytes read
+ * * -errno or a TPM return code otherwise
+ */
+int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
{
- struct tpm_cmd_t tpm_cmd;
+ struct tpm1_get_random_out *out;
+ u32 num_bytes = min_t(u32, max, TPM_MAX_RNG_DATA);
+ struct tpm_buf buf;
+ u32 total = 0;
+ int retries = 5;
u32 recd;
- u32 num_bytes = min_t(u32, max, TPM_MAX_RNG_DATA);
- u32 rlength;
- int err, total = 0, retries = 5;
- u8 *dest = out;
+ int rc;
- if (!out || !num_bytes || max > TPM_MAX_RNG_DATA)
- return -EINVAL;
+ rc = tpm_buf_init(, TPM_TAG_RQU_COMMAND, TPM_ORD_GET_RANDOM);
+ if (rc)
+ return rc;
do {
- tpm_cmd.header.in = tpm_getrandom_header;
- tpm_cmd.params.getrandom_in.num_bytes = cpu_to_be32(num_bytes);
-
- err = tpm_transmit_cmd(chip, NULL, _cmd,
- TPM_GETRANDOM_RESULT_SIZE + num_bytes,
- offsetof(struct tpm_getrandom_out,
- rng_data),
- 0, "attempting get random");
- if (err)
- break;
+ tpm_buf_append_u32(, num_bytes);
+
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE,
+ sizeof(out->rng_data_len), 0,
+ "attempting get random");
+ if (rc)
+ goto out;
- recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
+ out = (struct tpm1_get_random_out *)[TPM_HEADER_SIZE];
+
+ recd = be32_to_cpu(out->rng_data_len);
if (recd > num_bytes) {
- total = -EFAULT;
- break;
+ rc = -EFAULT;
+ goto out;
}
- rlength = be32_to_cpu(tpm_cmd.header.out.length);
- if (rlength < TPM_HEADER_SIZE +
- offsetof(struct tpm_getrandom_out,
[PATCH v5 10/21] tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
Factor out TPM 1.x suspend flow from tpm-interface.c into a new function
tpm1_pm_suspend() in tpm1-cmd.c
Signed-off-by: Tomas Winkler
---
V2-V3: Rebase
V4: 1. Add kdoc for tpm1_pm_suspend().
2. Fix commit message.
V5: Adjust the kdoc to the new standard.
drivers/char/tpm/tpm-interface.c | 55
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm1-cmd.c | 61
3 files changed, 67 insertions(+), 50 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 70b20b4c789a..25242190a941 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -585,15 +585,6 @@ int tpm_send(struct tpm_chip *chip, void *cmd, size_t
buflen)
}
EXPORT_SYMBOL_GPL(tpm_send);
-#define TPM_ORD_SAVESTATE 152
-#define SAVESTATE_RESULT_SIZE 10
-
-static const struct tpm_input_header savestate_header = {
- .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
- .length = cpu_to_be32(10),
- .ordinal = cpu_to_be32(TPM_ORD_SAVESTATE)
-};
-
/*
* We are about to suspend. Save the TPM state
* so that it can be restored.
@@ -601,54 +592,18 @@ static const struct tpm_input_header savestate_header = {
int tpm_pm_suspend(struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
- struct tpm_cmd_t cmd;
- int rc, try;
-
- u8 dummy_hash[TPM_DIGEST_SIZE] = { 0 };
+ int rc = 0;
- if (chip == NULL)
+ if (!chip)
return -ENODEV;
if (chip->flags & TPM_CHIP_FLAG_ALWAYS_POWERED)
return 0;
- if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
tpm2_shutdown(chip, TPM2_SU_STATE);
- return 0;
- }
-
- /* for buggy tpm, flush pcrs with extend to selected dummy */
- if (tpm_suspend_pcr)
- rc = tpm1_pcr_extend(chip, tpm_suspend_pcr, dummy_hash,
-"extending dummy pcr before suspend");
-
- /* now do the actual savestate */
- for (try = 0; try < TPM_RETRY; try++) {
- cmd.header.in = savestate_header;
- rc = tpm_transmit_cmd(chip, NULL, , SAVESTATE_RESULT_SIZE,
- 0, 0, NULL);
-
- /*
-* If the TPM indicates that it is too busy to respond to
-* this command then retry before giving up. It can take
-* several seconds for this TPM to be ready.
-*
-* This can happen if the TPM has already been sent the
-* SaveState command before the driver has loaded. TCG 1.2
-* specification states that any communication after SaveState
-* may cause the TPM to invalidate previously saved state.
-*/
- if (rc != TPM_WARN_RETRY)
- break;
- tpm_msleep(TPM_TIMEOUT_RETRY);
- }
-
- if (rc)
- dev_err(>dev,
- "Error (%d) sending savestate before suspend\n", rc);
- else if (try > 0)
- dev_warn(>dev, "TPM savestate took %dms\n",
-try * TPM_TIMEOUT_RETRY);
+ else
+ rc = tpm1_pm_suspend(chip, tpm_suspend_pcr);
return rc;
}
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index fd945fc828b6..862c9262e037 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -543,6 +543,7 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct
tpm_space *space,
int tpm_startup(struct tpm_chip *chip);
int tpm_get_timeouts(struct tpm_chip *);
+int tpm1_pm_suspend(struct tpm_chip *chip, int tpm_suspend_pcr);
int tpm1_do_selftest(struct tpm_chip *chip);
int tpm1_auto_startup(struct tpm_chip *chip);
int tpm1_get_timeouts(struct tpm_chip *chip);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index a69a02366c32..3bd9f1fa77ce 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -666,3 +666,64 @@ int tpm1_auto_startup(struct tpm_chip *chip)
rc = -ENODEV;
return rc;
}
+
+#define TPM_ORD_SAVESTATE 152
+#define SAVESTATE_RESULT_SIZE 10
+static const struct tpm_input_header savestate_header = {
+ .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
+ .length = cpu_to_be32(10),
+ .ordinal = cpu_to_be32(TPM_ORD_SAVESTATE)
+};
+
+/**
+ * tpm1_pm_suspend() - pm suspend handler
+ * @chip: TPM chip to use.
+ * @tpm_suspend_pcr: flush pcr for buggy TPM chips.
+ *
+ * The functions saves the TPM state to be restored on resume.
+ *
+ * Return:
+ * * 0 on success,
+ * * < 0 on error.
+ */
+int tpm1_pm_suspend(struct tpm_chip *chip, int tpm_suspend_pcr)
+{
+ u8 dummy_hash[TPM_DIGEST_SIZE] = { 0 };
+ struct tpm_cmd_t cmd;
+ int rc, try;
+
+ /* for buggy tpm, flush pcrs with extend to selected
[PATCH v5 01/21] tpm2: add new tpm2 commands according to TCG 1.36
1. TPM2_CC_LAST has moved from 182 to 193
2. Convert tpm2_ordinal_duration from an array into a switch statement,
as there are not so many commands that require special duration
relative to a number of commands, the switch statement function
is called tpm2_ordinal_duration_index().
3. Fix kdoc comments for tpm2_calc_ordinal_duration().
Signed-off-by: Tomas Winkler
Tested-by: Jarkko Sakkinen
---
V2-V3: Rebase.
V4: 1. Fix kdoc
2. Rename tpm2_ordinal_duration() to tpm2_ordinal_duration_index()
3. Move the two functions close to each other in the file.
V5: Adjust the kdoc to the new standard.
drivers/char/tpm/tpm.h | 41 +---
drivers/char/tpm/tpm2-cmd.c | 241 +---
2 files changed, 118 insertions(+), 164 deletions(-)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f20dc8ece348..0f08518b525d 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -134,22 +134,31 @@ enum tpm2_algorithms {
};
enum tpm2_command_codes {
- TPM2_CC_FIRST = 0x011F,
- TPM2_CC_CREATE_PRIMARY = 0x0131,
- TPM2_CC_SELF_TEST = 0x0143,
- TPM2_CC_STARTUP = 0x0144,
- TPM2_CC_SHUTDOWN= 0x0145,
- TPM2_CC_CREATE = 0x0153,
- TPM2_CC_LOAD= 0x0157,
- TPM2_CC_UNSEAL = 0x015E,
- TPM2_CC_CONTEXT_LOAD= 0x0161,
- TPM2_CC_CONTEXT_SAVE= 0x0162,
- TPM2_CC_FLUSH_CONTEXT = 0x0165,
- TPM2_CC_GET_CAPABILITY = 0x017A,
- TPM2_CC_GET_RANDOM = 0x017B,
- TPM2_CC_PCR_READ= 0x017E,
- TPM2_CC_PCR_EXTEND = 0x0182,
- TPM2_CC_LAST= 0x018F,
+ TPM2_CC_FIRST = 0x011F,
+ TPM2_CC_HIERARCHY_CONTROL = 0x0121,
+ TPM2_CC_HIERARCHY_CHANGE_AUTH = 0x0129,
+ TPM2_CC_CREATE_PRIMARY = 0x0131,
+ TPM2_CC_SEQUENCE_COMPLETE = 0x013E,
+ TPM2_CC_SELF_TEST = 0x0143,
+ TPM2_CC_STARTUP = 0x0144,
+ TPM2_CC_SHUTDOWN= 0x0145,
+ TPM2_CC_NV_READ = 0x014E,
+ TPM2_CC_CREATE = 0x0153,
+ TPM2_CC_LOAD= 0x0157,
+ TPM2_CC_SEQUENCE_UPDATE = 0x015C,
+ TPM2_CC_UNSEAL = 0x015E,
+ TPM2_CC_CONTEXT_LOAD= 0x0161,
+ TPM2_CC_CONTEXT_SAVE= 0x0162,
+ TPM2_CC_FLUSH_CONTEXT = 0x0165,
+ TPM2_CC_VERIFY_SIGNATURE= 0x0177,
+ TPM2_CC_GET_CAPABILITY = 0x017A,
+ TPM2_CC_GET_RANDOM = 0x017B,
+ TPM2_CC_PCR_READ= 0x017E,
+ TPM2_CC_PCR_EXTEND = 0x0182,
+ TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,
+ TPM2_CC_HASH_SEQUENCE_START = 0x0186,
+ TPM2_CC_CREATE_LOADED = 0x0191,
+ TPM2_CC_LAST= 0x0193, /* Spec 1.36 */
};
enum tpm2_permanent_handles {
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 3acf4fd4e5a5..f08478c78bf7 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -40,129 +40,100 @@ static struct tpm2_hash tpm2_hash_map[] = {
{HASH_ALGO_SM3_256, TPM2_ALG_SM3_256},
};
-/*
- * Array with one entry per ordinal defining the maximum amount
- * of time the chip could take to return the result. The values
- * of the SHORT, MEDIUM, and LONG durations are taken from the
- * PC Client Profile (PTP) specification.
- * LONG_LONG is for commands that generates keys which empirically
- * takes longer time on some systems.
+/**
+ * tpm2_ordinal_duration_index() - returns an index to the chip duration table
+ * @ordinal: TPM command ordinal.
+ *
+ * The function returns an index to the chip duration table
+ * (enum tpm_duration), that describes the maximum amount of
+ * time the chip could take to return the result for a particular ordinal.
+ *
+ * The values of the MEDIUM, and LONG durations are taken
+ * from the PC Client Profile (PTP) specification (750, 2000 msec)
+ *
+ * LONG_LONG is for commands that generates keys which empirically takes
+ * a longer time on some systems.
+ *
+ * Return:
+ * * TPM_MEDIUM
+ * * TPM_LONG,
+ * * TPM_LONG_LONG
+ * * TPM_UNDEFINED.
*/
-static const u8 tpm2_ordinal_duration[TPM2_CC_LAST - TPM2_CC_FIRST + 1] = {
- TPM_UNDEFINED, /* 11F */
- TPM_UNDEFINED, /* 120 */
- TPM_LONG, /* 121 */
- TPM_UNDEFINED, /* 122 */
- TPM_UNDEFINED, /* 123 */
- TPM_UNDEFINED, /* 124 */
- TPM_UNDEFINED, /* 125 */
- TPM_UNDEFINED, /* 126 */
- TPM_UNDEFINED, /* 127 */
- TPM_UNDEFINED, /* 128 */
- TPM_LONG, /* 129 */
- TPM_UNDEFINED, /* 12a */
- TPM_UNDEFINED, /* 12b */
- TPM_UNDEFINED, /* 12c */
-
[PATCH v5 06/21] tpm: move tpm1_pcr_extend to tpm1-cmd.c
Move tpm1_pcr_extend to tpm1-cmd.c and remove
unused pcrextend_header structure and
EXTEND_PCR_RESULT_SIZE and EXTEND_PCR_RESULT_BODY_SIZE
defines.
Fixes warning:
drivers/char/tpm/tpm-interface.c:609:38: warning: ‘pcrextend_header’ defined
but not used [-Wunused-const-variable=]
static const struct tpm_input_header pcrextend_header = {
^~~~
Signed-off-by: Tomas Winkler
Reviewed-by: Jarkko Sakkinen
---
V2-V3: Rebase
V4: Remove defines.
V5: Resend.
drivers/char/tpm/tpm-interface.c | 28
drivers/char/tpm/tpm.h | 2 ++
drivers/char/tpm/tpm1-cmd.c | 21 +
3 files changed, 23 insertions(+), 28 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1fa0300f3829..ac73e6ac3d83 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -614,34 +614,6 @@ int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx, u8
*res_buf)
}
EXPORT_SYMBOL_GPL(tpm_pcr_read);
-#define TPM_ORD_PCR_EXTEND 20
-#define EXTEND_PCR_RESULT_SIZE 34
-#define EXTEND_PCR_RESULT_BODY_SIZE 20
-static const struct tpm_input_header pcrextend_header = {
- .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
- .length = cpu_to_be32(34),
- .ordinal = cpu_to_be32(TPM_ORD_PCR_EXTEND)
-};
-
-static int tpm1_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash,
- char *log_msg)
-{
- struct tpm_buf buf;
- int rc;
-
- rc = tpm_buf_init(, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_EXTEND);
- if (rc)
- return rc;
-
- tpm_buf_append_u32(, pcr_idx);
- tpm_buf_append(, hash, TPM_DIGEST_SIZE);
-
- rc = tpm_transmit_cmd(chip, NULL, buf.data, EXTEND_PCR_RESULT_SIZE,
- EXTEND_PCR_RESULT_BODY_SIZE, 0, log_msg);
- tpm_buf_destroy();
- return rc;
-}
-
/**
* tpm_pcr_extend - extend a PCR value in SHA1 bank.
* @chip: a tpm_chip instance, %NULL for the default chip
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index a97d72fcda5b..3fb268f43955 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -549,6 +549,8 @@ int tpm_do_selftest(struct tpm_chip *chip);
int tpm1_auto_startup(struct tpm_chip *chip);
int tpm1_get_timeouts(struct tpm_chip *chip);
unsigned long tpm1_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
+int tpm1_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash,
+ const char *log_msg);
unsigned long tpm_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
int tpm_pm_suspend(struct device *dev);
int tpm_pm_resume(struct device *dev);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 978946748ea3..ec242397e6dc 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -413,3 +413,24 @@ int tpm1_get_timeouts(struct tpm_chip *chip)
chip->flags |= TPM_CHIP_FLAG_HAVE_TIMEOUTS;
return 0;
}
+
+#define TPM_ORD_PCR_EXTEND 20
+int tpm1_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash,
+ const char *log_msg)
+{
+ struct tpm_buf buf;
+ int rc;
+
+ rc = tpm_buf_init(, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_EXTEND);
+ if (rc)
+ return rc;
+
+ tpm_buf_append_u32(, pcr_idx);
+ tpm_buf_append(, hash, TPM_DIGEST_SIZE);
+
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE,
+ TPM_DIGEST_SIZE, 0, log_msg);
+
+ tpm_buf_destroy();
+ return rc;
+}
--
2.14.4
[PATCH v5 00/21] tpm: separate tpm 1.x and tpm 2.x commands
This patch series provides initial separation of tpm 1.x and tpm 2.x commands, in foresight that the tpm 1.x chips will eventually phase out and can be compiled out for modern systems. A new file is added tpm1-cmd.c that contains tpm 1.x specific commands. In addition, tpm 1.x commands are now implemented using tpm_buf structure and instead of tpm_cmd_t construct. The latter is now removed. Note: my tpm 1.x HW availability is limited hence some more testing is needed. This series also contains two trivial cleanups and addition of new commands by TCG spec 1.36, now supported on new Intet's platforms. Tomas Winkler (21): tpm2: add new tpm2 commands according to TCG 1.36 tpm: sort objects in the Makefile tpm: factor out tpm 1.x duration calculation to tpm1-cmd.c tpm: add tpm_calc_ordinal_duration() wrapper tpm: factor out tpm_get_timeouts() tpm: move tpm1_pcr_extend to tpm1-cmd.c tpm: move tpm_getcap to tpm1-cmd.c tpm: factor out tpm1_get_random into tpm1-cmd.c tpm: move tpm 1.x selftest code from tpm-interface.c tpm1-cmd.c tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c tpm: factor out tpm_startup function tpm: move pcr extend code to tpm2-cmd.c tpm: add tpm_auto_startup() into tpm-interface.c tpm: tpm-interface.c drop unused macros tpm: tpm-space.c remove unneeded semicolon tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure tpm1: implement tpm1_pcr_read_dev() using tpm_buf structure tmp1: rename tpm1_pcr_read_dev to tpm1_pcr_read(). tpm1: reimplement SAVESTATE using tpm_buf tpm1: reimplement tpm1_continue_selftest() using tpm_buf tpm: use u32 instead of int for PCR index drivers/char/tpm/Makefile| 16 +- drivers/char/tpm/st33zp24/st33zp24.c | 2 +- drivers/char/tpm/tpm-chip.c | 11 +- drivers/char/tpm/tpm-interface.c | 841 +++ drivers/char/tpm/tpm-sysfs.c | 52 +-- drivers/char/tpm/tpm.h | 98 ++-- drivers/char/tpm/tpm1-cmd.c | 781 drivers/char/tpm/tpm2-cmd.c | 344 +++--- drivers/char/tpm/tpm2-space.c| 2 +- drivers/char/tpm/tpm_i2c_nuvoton.c | 10 +- drivers/char/tpm/tpm_tis_core.c | 10 +- include/linux/tpm.h | 11 +- security/integrity/ima/ima_crypto.c | 5 +- 13 files changed, 1121 insertions(+), 1062 deletions(-) create mode 100644 drivers/char/tpm/tpm1-cmd.c -- 2.14.4
[PATCH v5 06/21] tpm: move tpm1_pcr_extend to tpm1-cmd.c
Move tpm1_pcr_extend to tpm1-cmd.c and remove
unused pcrextend_header structure and
EXTEND_PCR_RESULT_SIZE and EXTEND_PCR_RESULT_BODY_SIZE
defines.
Fixes warning:
drivers/char/tpm/tpm-interface.c:609:38: warning: ‘pcrextend_header’ defined
but not used [-Wunused-const-variable=]
static const struct tpm_input_header pcrextend_header = {
^~~~
Signed-off-by: Tomas Winkler
Reviewed-by: Jarkko Sakkinen
---
V2-V3: Rebase
V4: Remove defines.
V5: Resend.
drivers/char/tpm/tpm-interface.c | 28
drivers/char/tpm/tpm.h | 2 ++
drivers/char/tpm/tpm1-cmd.c | 21 +
3 files changed, 23 insertions(+), 28 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1fa0300f3829..ac73e6ac3d83 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -614,34 +614,6 @@ int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx, u8
*res_buf)
}
EXPORT_SYMBOL_GPL(tpm_pcr_read);
-#define TPM_ORD_PCR_EXTEND 20
-#define EXTEND_PCR_RESULT_SIZE 34
-#define EXTEND_PCR_RESULT_BODY_SIZE 20
-static const struct tpm_input_header pcrextend_header = {
- .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
- .length = cpu_to_be32(34),
- .ordinal = cpu_to_be32(TPM_ORD_PCR_EXTEND)
-};
-
-static int tpm1_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash,
- char *log_msg)
-{
- struct tpm_buf buf;
- int rc;
-
- rc = tpm_buf_init(, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_EXTEND);
- if (rc)
- return rc;
-
- tpm_buf_append_u32(, pcr_idx);
- tpm_buf_append(, hash, TPM_DIGEST_SIZE);
-
- rc = tpm_transmit_cmd(chip, NULL, buf.data, EXTEND_PCR_RESULT_SIZE,
- EXTEND_PCR_RESULT_BODY_SIZE, 0, log_msg);
- tpm_buf_destroy();
- return rc;
-}
-
/**
* tpm_pcr_extend - extend a PCR value in SHA1 bank.
* @chip: a tpm_chip instance, %NULL for the default chip
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index a97d72fcda5b..3fb268f43955 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -549,6 +549,8 @@ int tpm_do_selftest(struct tpm_chip *chip);
int tpm1_auto_startup(struct tpm_chip *chip);
int tpm1_get_timeouts(struct tpm_chip *chip);
unsigned long tpm1_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
+int tpm1_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash,
+ const char *log_msg);
unsigned long tpm_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
int tpm_pm_suspend(struct device *dev);
int tpm_pm_resume(struct device *dev);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 978946748ea3..ec242397e6dc 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -413,3 +413,24 @@ int tpm1_get_timeouts(struct tpm_chip *chip)
chip->flags |= TPM_CHIP_FLAG_HAVE_TIMEOUTS;
return 0;
}
+
+#define TPM_ORD_PCR_EXTEND 20
+int tpm1_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash,
+ const char *log_msg)
+{
+ struct tpm_buf buf;
+ int rc;
+
+ rc = tpm_buf_init(, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_EXTEND);
+ if (rc)
+ return rc;
+
+ tpm_buf_append_u32(, pcr_idx);
+ tpm_buf_append(, hash, TPM_DIGEST_SIZE);
+
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE,
+ TPM_DIGEST_SIZE, 0, log_msg);
+
+ tpm_buf_destroy();
+ return rc;
+}
--
2.14.4
[PATCH v5 00/21] tpm: separate tpm 1.x and tpm 2.x commands
This patch series provides initial separation of tpm 1.x and tpm 2.x commands, in foresight that the tpm 1.x chips will eventually phase out and can be compiled out for modern systems. A new file is added tpm1-cmd.c that contains tpm 1.x specific commands. In addition, tpm 1.x commands are now implemented using tpm_buf structure and instead of tpm_cmd_t construct. The latter is now removed. Note: my tpm 1.x HW availability is limited hence some more testing is needed. This series also contains two trivial cleanups and addition of new commands by TCG spec 1.36, now supported on new Intet's platforms. Tomas Winkler (21): tpm2: add new tpm2 commands according to TCG 1.36 tpm: sort objects in the Makefile tpm: factor out tpm 1.x duration calculation to tpm1-cmd.c tpm: add tpm_calc_ordinal_duration() wrapper tpm: factor out tpm_get_timeouts() tpm: move tpm1_pcr_extend to tpm1-cmd.c tpm: move tpm_getcap to tpm1-cmd.c tpm: factor out tpm1_get_random into tpm1-cmd.c tpm: move tpm 1.x selftest code from tpm-interface.c tpm1-cmd.c tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c tpm: factor out tpm_startup function tpm: move pcr extend code to tpm2-cmd.c tpm: add tpm_auto_startup() into tpm-interface.c tpm: tpm-interface.c drop unused macros tpm: tpm-space.c remove unneeded semicolon tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure tpm1: implement tpm1_pcr_read_dev() using tpm_buf structure tmp1: rename tpm1_pcr_read_dev to tpm1_pcr_read(). tpm1: reimplement SAVESTATE using tpm_buf tpm1: reimplement tpm1_continue_selftest() using tpm_buf tpm: use u32 instead of int for PCR index drivers/char/tpm/Makefile| 16 +- drivers/char/tpm/st33zp24/st33zp24.c | 2 +- drivers/char/tpm/tpm-chip.c | 11 +- drivers/char/tpm/tpm-interface.c | 841 +++ drivers/char/tpm/tpm-sysfs.c | 52 +-- drivers/char/tpm/tpm.h | 98 ++-- drivers/char/tpm/tpm1-cmd.c | 781 drivers/char/tpm/tpm2-cmd.c | 344 +++--- drivers/char/tpm/tpm2-space.c| 2 +- drivers/char/tpm/tpm_i2c_nuvoton.c | 10 +- drivers/char/tpm/tpm_tis_core.c | 10 +- include/linux/tpm.h | 11 +- security/integrity/ima/ima_crypto.c | 5 +- 13 files changed, 1121 insertions(+), 1062 deletions(-) create mode 100644 drivers/char/tpm/tpm1-cmd.c -- 2.14.4
Re: [PATCH] gpio: omap: get rid of the conditional PM runtime calls
* Grygorii Strashko [180928 21:44]: > As result safely drop !BANK_USED() checks from omap_gpio_request/free(), > omap_gpio_irq_bus_lock/unlock() and enable PM runtime management for OMAP > GPIO IRQ chip. Nice to get rid of the conditional PM runtime calls :) Tony
Re: [PATCH v7 0/6] seccomp trap to userspace
On Fri, Sep 28, 2018 at 3:16 PM, Michael Kerrisk (man-pages) wrote: > Hi Tycho, > > On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote: >> >> On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) wrote: >> > Hi Tycho, >> > >> > On 09/27/2018 05:11 PM, Tycho Andersen wrote: >> > > Hi all, >> > > >> > > Here's v7 of the seccomp trap to userspace set. There are various minor >> > > changes and bug fixes, but two major changes: >> > > >> > > * We now pass fds to the tracee via an ioctl, and do it immediately when >> > >the ioctl is called. For this we needed some help from the vfs, so >> > >I've put the one patch in this series and cc'd fsdevel. This does have >> > >the advantage that the feature is now totally decoupled from the rest >> > >of the set, which is itself useful (thanks Andy!) >> > > >> > > * Instead of putting all of the notification related stuff into the >> > >struct seccomp_filter, it now lives in its own struct notification, >> > >which is pointed to by struct seccomp_filter. This will save a lot of >> > >memory (thanks Tyler!) >> > >> > Is there a documentation (man page) patch for this API change? >> >> Not yet, but once we decide on a final API I'll prepare one. > > Honestly, the production of such documentation should be part of the > evolution towards the final API... > > Documentation is not an afterthought. It's a tool for pushing you, the > developer (and others, your reviewers) to more deeply consider your > design. In Tycho's defense, he did write up documentation in Documentation/ for the feature, so it won't be an afterthought. :) But yes, there's no manpage delta yet. -Kees -- Kees Cook Pixel Security
Re: [PATCH] gpio: omap: get rid of the conditional PM runtime calls
* Grygorii Strashko [180928 21:44]: > As result safely drop !BANK_USED() checks from omap_gpio_request/free(), > omap_gpio_irq_bus_lock/unlock() and enable PM runtime management for OMAP > GPIO IRQ chip. Nice to get rid of the conditional PM runtime calls :) Tony
Re: [PATCH v7 0/6] seccomp trap to userspace
On Fri, Sep 28, 2018 at 3:16 PM, Michael Kerrisk (man-pages) wrote: > Hi Tycho, > > On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote: >> >> On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) wrote: >> > Hi Tycho, >> > >> > On 09/27/2018 05:11 PM, Tycho Andersen wrote: >> > > Hi all, >> > > >> > > Here's v7 of the seccomp trap to userspace set. There are various minor >> > > changes and bug fixes, but two major changes: >> > > >> > > * We now pass fds to the tracee via an ioctl, and do it immediately when >> > >the ioctl is called. For this we needed some help from the vfs, so >> > >I've put the one patch in this series and cc'd fsdevel. This does have >> > >the advantage that the feature is now totally decoupled from the rest >> > >of the set, which is itself useful (thanks Andy!) >> > > >> > > * Instead of putting all of the notification related stuff into the >> > >struct seccomp_filter, it now lives in its own struct notification, >> > >which is pointed to by struct seccomp_filter. This will save a lot of >> > >memory (thanks Tyler!) >> > >> > Is there a documentation (man page) patch for this API change? >> >> Not yet, but once we decide on a final API I'll prepare one. > > Honestly, the production of such documentation should be part of the > evolution towards the final API... > > Documentation is not an afterthought. It's a tool for pushing you, the > developer (and others, your reviewers) to more deeply consider your > design. In Tycho's defense, he did write up documentation in Documentation/ for the feature, so it won't be an afterthought. :) But yes, there's no manpage delta yet. -Kees -- Kees Cook Pixel Security
[PATCH] mm: enforce THP for VM_NOHUGEPAGE dax mappings
commit baabda261424517110ea98c6651f632ebf2561e3 ("mm: always enable thp
for dax mappings") says madvise hguepage policy makes less sense for
dax, and force enabling thp for dax mappings in all cases, even though
THP is set to "never".
However, transparent_hugepage_enabled() may return false if
VM_NOHUGEPAGE is set even though the mapping is dax.
So, move is_vma_dax() check to the very beginning to enforce THP for dax
mappings in all cases.
Cc: Dan Williams
Cc: Jan Kara
Cc: Ross Zwisler
Cc: "Kirill A. Shutemov"
Signed-off-by: Yang Shi
---
I didn't find anyone mention the check should be before VM_NOHUGEPAGE in
the review for Dan's original patch. And, that patch commit log states
clearly that THP for dax mapping for all cases even though THP is never.
So, I'm supposed it should behave in this way.
include/linux/huge_mm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 99c19b0..b2ad305 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -95,6 +95,9 @@ extern ssize_t single_hugepage_flag_show(struct kobject *kobj,
static inline bool transparent_hugepage_enabled(struct vm_area_struct *vma)
{
+ if (vma_is_dax(vma))
+ return true;
+
if (vma->vm_flags & VM_NOHUGEPAGE)
return false;
@@ -107,9 +110,6 @@ static inline bool transparent_hugepage_enabled(struct
vm_area_struct *vma)
if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_FLAG))
return true;
- if (vma_is_dax(vma))
- return true;
-
if (transparent_hugepage_flags &
(1 << TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG))
return !!(vma->vm_flags & VM_HUGEPAGE);
--
1.8.3.1
[PATCH] mm: enforce THP for VM_NOHUGEPAGE dax mappings
commit baabda261424517110ea98c6651f632ebf2561e3 ("mm: always enable thp
for dax mappings") says madvise hguepage policy makes less sense for
dax, and force enabling thp for dax mappings in all cases, even though
THP is set to "never".
However, transparent_hugepage_enabled() may return false if
VM_NOHUGEPAGE is set even though the mapping is dax.
So, move is_vma_dax() check to the very beginning to enforce THP for dax
mappings in all cases.
Cc: Dan Williams
Cc: Jan Kara
Cc: Ross Zwisler
Cc: "Kirill A. Shutemov"
Signed-off-by: Yang Shi
---
I didn't find anyone mention the check should be before VM_NOHUGEPAGE in
the review for Dan's original patch. And, that patch commit log states
clearly that THP for dax mapping for all cases even though THP is never.
So, I'm supposed it should behave in this way.
include/linux/huge_mm.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 99c19b0..b2ad305 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -95,6 +95,9 @@ extern ssize_t single_hugepage_flag_show(struct kobject *kobj,
static inline bool transparent_hugepage_enabled(struct vm_area_struct *vma)
{
+ if (vma_is_dax(vma))
+ return true;
+
if (vma->vm_flags & VM_NOHUGEPAGE)
return false;
@@ -107,9 +110,6 @@ static inline bool transparent_hugepage_enabled(struct
vm_area_struct *vma)
if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_FLAG))
return true;
- if (vma_is_dax(vma))
- return true;
-
if (transparent_hugepage_flags &
(1 << TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG))
return !!(vma->vm_flags & VM_HUGEPAGE);
--
1.8.3.1
Re: [PATCH 05/13] staging:rtl8192u: Remove AdvCoding and GreenField - Style
On Fri, Sep 28, 2018 at 05:31:40PM +0300, Dan Carpenter wrote:
> On Wed, Sep 26, 2018 at 08:16:56PM +0100, John Whitmore wrote:
> > The member variables AdvCoding and GreenField are unused in code so
> > have been removed from the structure and associated initialisation
> > function.
> >
> > This is a coding style change which should have no impact on runtime
> > code execution.
> >
> > Signed-off-by: John Whitmore
> > ---
> > drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 2 --
> > drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 2 --
> > 2 files changed, 4 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > index 64d5359cf7e2..83fb8f34ccbd 100644
> > --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > @@ -39,10 +39,8 @@ enum ht_extension_chan_offset {
> >
> > struct ht_capability_ele {
> > //HT capability info
> > - u8 AdvCoding:1;
> > u8 ChlWidth:1;
> > u8 MimoPwrSave:2;
> > - u8 GreenField:1;
> > u8 ShortGI20Mhz:1;
> > u8 ShortGI40Mhz:1;
> > u8 TxSTBC:1;
>
> I feel like we discussed this before. I'm pretty sure this comes from
> the firmware and so the format can't be changed. When I look at
> rtllib_parse_mife_generic() then I think that "info_element" probably
> comes from the firmware.
>
> I wouldn't want to accept this with out someone testing it.
>
> regards,
> dan carpenter
>
Thank you and sorry about not helping the signal to noise ratio on here.
I agree that a bit field like that and it looks like it comes from
firmware, but my question or possibly obsession was where. There are
structures inside structures, but they are all allocated from RAM.
Because of that I expected to find a memcopy from the device, or given
that the bitfield is initialised with values that it might be memcopy'd
to the device. I just couldn't find that memcopy, but that's down to
my untrained eye. I'll stumble across it in some obscure corner of the
driver.
Re: [PATCH 05/13] staging:rtl8192u: Remove AdvCoding and GreenField - Style
On Fri, Sep 28, 2018 at 05:31:40PM +0300, Dan Carpenter wrote:
> On Wed, Sep 26, 2018 at 08:16:56PM +0100, John Whitmore wrote:
> > The member variables AdvCoding and GreenField are unused in code so
> > have been removed from the structure and associated initialisation
> > function.
> >
> > This is a coding style change which should have no impact on runtime
> > code execution.
> >
> > Signed-off-by: John Whitmore
> > ---
> > drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 2 --
> > drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 2 --
> > 2 files changed, 4 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > index 64d5359cf7e2..83fb8f34ccbd 100644
> > --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > @@ -39,10 +39,8 @@ enum ht_extension_chan_offset {
> >
> > struct ht_capability_ele {
> > //HT capability info
> > - u8 AdvCoding:1;
> > u8 ChlWidth:1;
> > u8 MimoPwrSave:2;
> > - u8 GreenField:1;
> > u8 ShortGI20Mhz:1;
> > u8 ShortGI40Mhz:1;
> > u8 TxSTBC:1;
>
> I feel like we discussed this before. I'm pretty sure this comes from
> the firmware and so the format can't be changed. When I look at
> rtllib_parse_mife_generic() then I think that "info_element" probably
> comes from the firmware.
>
> I wouldn't want to accept this with out someone testing it.
>
> regards,
> dan carpenter
>
Thank you and sorry about not helping the signal to noise ratio on here.
I agree that a bit field like that and it looks like it comes from
firmware, but my question or possibly obsession was where. There are
structures inside structures, but they are all allocated from RAM.
Because of that I expected to find a memcopy from the device, or given
that the bitfield is initialised with values that it might be memcopy'd
to the device. I just couldn't find that memcopy, but that's down to
my untrained eye. I'll stumble across it in some obscure corner of the
driver.
Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev
On 9/28/18 11:22 PM, Tony Lindgren wrote:
> * Dmitry Osipenko [180928 20:13]:
>> Tony, could you please give a try to the patch below?
>>
>> Do the following:
>>
>> 1) git cherry-pick 696861761a58d8c93605b5663824929fb6540f16
>> 2) git cherry-pick 456e7cdf3b1a14e2606b8b687385ab2e3f23a49a
>> 3) Apply this patch:
>
> Seems to be getting closer, system boots up and starts
> init, but then I start getting tons of this on beagle-x15:
Tony, could you please try this one? Fixed couple more bugs, should be good now.
>From 9c7382b1a28692576cbe00f57fdea0d25b27cc4c Mon Sep 17 00:00:00 2001
From: Dmitry Osipenko
Date: Fri, 28 Sep 2018 21:49:20 +0300
Subject: [PATCH] Fixup regulator_balance_voltage() v2
---
drivers/regulator/core.c | 83
1 file changed, 50 insertions(+), 33 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 282511508698..2f3b1cf19bd5 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -105,7 +105,7 @@ static int _notifier_call_chain(struct regulator_dev *rdev,
unsigned long event, void *data);
static int _regulator_do_set_voltage(struct regulator_dev *rdev,
int min_uV, int max_uV);
-static int regulator_balance_voltage(struct regulator_dev *rdev,
+static int regulator_balance_voltage(struct regulator *regulator,
suspend_state_t state);
static int regulator_set_voltage_rdev(struct regulator_dev *rdev,
int min_uV, int max_uV,
@@ -2330,7 +2330,7 @@ int regulator_enable(struct regulator *regulator)
ret = _regulator_enable(rdev);
/* balance only if there are regulators coupled */
if (rdev->coupling_desc.n_coupled > 1)
- regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+ regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (ret != 0 && rdev->supply)
@@ -2440,7 +2440,7 @@ int regulator_disable(struct regulator *regulator)
regulator_lock_dependent(rdev);
ret = _regulator_disable(rdev);
if (rdev->coupling_desc.n_coupled > 1)
- regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+ regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (ret == 0 && rdev->supply)
@@ -2494,7 +2494,7 @@ int regulator_force_disable(struct regulator *regulator)
regulator->uA_load = 0;
ret = _regulator_force_disable(regulator->rdev);
if (rdev->coupling_desc.n_coupled > 1)
- regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+ regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (rdev->supply)
@@ -3099,12 +3099,8 @@ static int regulator_set_voltage_unlocked(struct
regulator *regulator,
voltage->min_uV = min_uV;
voltage->max_uV = max_uV;
- ret = regulator_check_consumers(rdev, _uV, _uV, state);
- if (ret < 0)
- goto out2;
-
/* for not coupled regulators this will just set the voltage */
- ret = regulator_balance_voltage(rdev, state);
+ ret = regulator_balance_voltage(regulator, state);
if (ret < 0)
goto out2;
@@ -3187,7 +3183,10 @@ static int regulator_set_voltage_rdev(struct
regulator_dev *rdev, int min_uV,
return ret;
}
-static int regulator_get_optimal_voltage(struct regulator_dev *rdev)
+static int regulator_get_optimal_voltage(struct regulator *regulator,
+struct regulator_dev *rdev,
+int *min_uV, int *max_uV,
+suspend_state_t state)
{
struct coupling_desc *c_desc = >coupling_desc;
struct regulator_dev **c_rdevs = c_desc->coupled_rdevs;
@@ -3198,20 +3197,29 @@ static int regulator_get_optimal_voltage(struct
regulator_dev *rdev)
int i, ret;
/* If consumers don't provide any demands, set voltage to min_uV */
- desired_min_uV = rdev->constraints->min_uV;
- desired_max_uV = rdev->constraints->max_uV;
- ret = regulator_check_consumers(rdev,
- _min_uV,
- _max_uV, PM_SUSPEND_ON);
- if (ret < 0)
- goto out;
+ if (regulator->rdev == rdev) {
+ desired_min_uV = regulator->voltage[state].min_uV;
+ desired_max_uV = regulator->voltage[state].max_uV;
+
+ ret = regulator_check_consumers(rdev,
+ _min_uV,
+ _max_uV,
+ state);
+ if (ret < 0)
+ goto out;
+ } else {
+ desired_min_uV =
Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev
On 9/28/18 11:22 PM, Tony Lindgren wrote:
> * Dmitry Osipenko [180928 20:13]:
>> Tony, could you please give a try to the patch below?
>>
>> Do the following:
>>
>> 1) git cherry-pick 696861761a58d8c93605b5663824929fb6540f16
>> 2) git cherry-pick 456e7cdf3b1a14e2606b8b687385ab2e3f23a49a
>> 3) Apply this patch:
>
> Seems to be getting closer, system boots up and starts
> init, but then I start getting tons of this on beagle-x15:
Tony, could you please try this one? Fixed couple more bugs, should be good now.
>From 9c7382b1a28692576cbe00f57fdea0d25b27cc4c Mon Sep 17 00:00:00 2001
From: Dmitry Osipenko
Date: Fri, 28 Sep 2018 21:49:20 +0300
Subject: [PATCH] Fixup regulator_balance_voltage() v2
---
drivers/regulator/core.c | 83
1 file changed, 50 insertions(+), 33 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 282511508698..2f3b1cf19bd5 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -105,7 +105,7 @@ static int _notifier_call_chain(struct regulator_dev *rdev,
unsigned long event, void *data);
static int _regulator_do_set_voltage(struct regulator_dev *rdev,
int min_uV, int max_uV);
-static int regulator_balance_voltage(struct regulator_dev *rdev,
+static int regulator_balance_voltage(struct regulator *regulator,
suspend_state_t state);
static int regulator_set_voltage_rdev(struct regulator_dev *rdev,
int min_uV, int max_uV,
@@ -2330,7 +2330,7 @@ int regulator_enable(struct regulator *regulator)
ret = _regulator_enable(rdev);
/* balance only if there are regulators coupled */
if (rdev->coupling_desc.n_coupled > 1)
- regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+ regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (ret != 0 && rdev->supply)
@@ -2440,7 +2440,7 @@ int regulator_disable(struct regulator *regulator)
regulator_lock_dependent(rdev);
ret = _regulator_disable(rdev);
if (rdev->coupling_desc.n_coupled > 1)
- regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+ regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (ret == 0 && rdev->supply)
@@ -2494,7 +2494,7 @@ int regulator_force_disable(struct regulator *regulator)
regulator->uA_load = 0;
ret = _regulator_force_disable(regulator->rdev);
if (rdev->coupling_desc.n_coupled > 1)
- regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+ regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
if (rdev->supply)
@@ -3099,12 +3099,8 @@ static int regulator_set_voltage_unlocked(struct
regulator *regulator,
voltage->min_uV = min_uV;
voltage->max_uV = max_uV;
- ret = regulator_check_consumers(rdev, _uV, _uV, state);
- if (ret < 0)
- goto out2;
-
/* for not coupled regulators this will just set the voltage */
- ret = regulator_balance_voltage(rdev, state);
+ ret = regulator_balance_voltage(regulator, state);
if (ret < 0)
goto out2;
@@ -3187,7 +3183,10 @@ static int regulator_set_voltage_rdev(struct
regulator_dev *rdev, int min_uV,
return ret;
}
-static int regulator_get_optimal_voltage(struct regulator_dev *rdev)
+static int regulator_get_optimal_voltage(struct regulator *regulator,
+struct regulator_dev *rdev,
+int *min_uV, int *max_uV,
+suspend_state_t state)
{
struct coupling_desc *c_desc = >coupling_desc;
struct regulator_dev **c_rdevs = c_desc->coupled_rdevs;
@@ -3198,20 +3197,29 @@ static int regulator_get_optimal_voltage(struct
regulator_dev *rdev)
int i, ret;
/* If consumers don't provide any demands, set voltage to min_uV */
- desired_min_uV = rdev->constraints->min_uV;
- desired_max_uV = rdev->constraints->max_uV;
- ret = regulator_check_consumers(rdev,
- _min_uV,
- _max_uV, PM_SUSPEND_ON);
- if (ret < 0)
- goto out;
+ if (regulator->rdev == rdev) {
+ desired_min_uV = regulator->voltage[state].min_uV;
+ desired_max_uV = regulator->voltage[state].max_uV;
+
+ ret = regulator_check_consumers(rdev,
+ _min_uV,
+ _max_uV,
+ state);
+ if (ret < 0)
+ goto out;
+ } else {
+ desired_min_uV =
[PATCH v5 4/4] drivers: clk: Add ZynqMP clock driver
From: Jolly Shah
This patch adds CCF compliant clock driver for ZynqMP.
Clock driver queries supported clock information from
firmware and regiters pll and output clocks with CCF.
Signed-off-by: Rajan Vaja
Signed-off-by: Tejas Patel
Signed-off-by: Shubhrajyoti Datta
Signed-off-by: Jolly Shah
Acked-by: Olof Johansson
---
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/zynqmp/Kconfig | 10 +
drivers/clk/zynqmp/Makefile | 4 +
drivers/clk/zynqmp/clk-gate-zynqmp.c | 144 +++
drivers/clk/zynqmp/clk-mux-zynqmp.c | 141 +++
drivers/clk/zynqmp/clk-zynqmp.h | 68
drivers/clk/zynqmp/clkc.c| 716 +++
drivers/clk/zynqmp/divider.c | 217 +++
drivers/clk/zynqmp/pll.c | 335
include/linux/firmware/xlnx-zynqmp.h | 1 +
11 files changed, 1638 insertions(+)
create mode 100644 drivers/clk/zynqmp/Kconfig
create mode 100644 drivers/clk/zynqmp/Makefile
create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h
create mode 100644 drivers/clk/zynqmp/clkc.c
create mode 100644 drivers/clk/zynqmp/divider.c
create mode 100644 drivers/clk/zynqmp/pll.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 98ce9fc..ab2ea76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -253,5 +253,6 @@ source "drivers/clk/sunxi-ng/Kconfig"
source "drivers/clk/tegra/Kconfig"
source "drivers/clk/ti/Kconfig"
source "drivers/clk/uniphier/Kconfig"
+source "drivers/clk/zynqmp/Kconfig"
endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71ec41e..b6ac0d2 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -100,3 +100,4 @@ obj-$(CONFIG_X86) += x86/
endif
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
+obj-$(CONFIG_COMMON_CLK_ZYNQMP) += zynqmp/
diff --git a/drivers/clk/zynqmp/Kconfig b/drivers/clk/zynqmp/Kconfig
new file mode 100644
index 000..1708605
--- /dev/null
+++ b/drivers/clk/zynqmp/Kconfig
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config COMMON_CLK_ZYNQMP
+ bool "Support for Xilinx ZynqMP Ultrascale+ clock controllers"
+ depends on ARCH_ZYNQMP || COMPILE_TEST
+ depends on ZYNQMP_FIRMWARE
+ help
+ Support for the Zynqmp Ultrascale clock controller.
+ It has a dependency on the PMU firmware.
+ Say Y if you want to include clock support.
diff --git a/drivers/clk/zynqmp/Makefile b/drivers/clk/zynqmp/Makefile
new file mode 100644
index 000..0ec24bf
--- /dev/null
+++ b/drivers/clk/zynqmp/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+# Zynq Ultrascale+ MPSoC clock specific Makefile
+
+obj-$(CONFIG_ARCH_ZYNQMP) += pll.o clk-gate-zynqmp.o divider.o
clk-mux-zynqmp.o clkc.o
diff --git a/drivers/clk/zynqmp/clk-gate-zynqmp.c
b/drivers/clk/zynqmp/clk-gate-zynqmp.c
new file mode 100644
index 000..83b236f
--- /dev/null
+++ b/drivers/clk/zynqmp/clk-gate-zynqmp.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq UltraScale+ MPSoC clock controller
+ *
+ * Copyright (C) 2016-2018 Xilinx
+ *
+ * Gated clock implementation
+ */
+
+#include
+#include
+#include "clk-zynqmp.h"
+
+/**
+ * struct clk_gate - gating clock
+ * @hw:handle between common and hardware-specific interfaces
+ * @flags: hardware-specific flags
+ * @clk_id:Id of clock
+ */
+struct zynqmp_clk_gate {
+ struct clk_hw hw;
+ u8 flags;
+ u32 clk_id;
+};
+
+#define to_zynqmp_clk_gate(_hw) container_of(_hw, struct zynqmp_clk_gate, hw)
+
+/**
+ * zynqmp_clk_gate_enable() - Enable clock
+ * @hw:handle between common and hardware-specific interfaces
+ *
+ * Return: 0 on success else error code
+ */
+static int zynqmp_clk_gate_enable(struct clk_hw *hw)
+{
+ struct zynqmp_clk_gate *gate = to_zynqmp_clk_gate(hw);
+ const char *clk_name = clk_hw_get_name(hw);
+ u32 clk_id = gate->clk_id;
+ int ret;
+ const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+ ret = eemi_ops->clock_enable(clk_id);
+
+ if (ret)
+ pr_warn_once("%s() clock enabled failed for %s, ret = %d\n",
+__func__, clk_name, ret);
+
+ return ret;
+}
+
+/*
+ * zynqmp_clk_gate_disable() - Disable clock
+ * @hw:handle between common and hardware-specific interfaces
+ */
+static void zynqmp_clk_gate_disable(struct clk_hw *hw)
+{
+ struct zynqmp_clk_gate *gate = to_zynqmp_clk_gate(hw);
+ const char *clk_name = clk_hw_get_name(hw);
+ u32 clk_id = gate->clk_id;
+ int ret;
+ const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+ ret = eemi_ops->clock_disable(clk_id);
+
+ if
[PATCH v5 4/4] drivers: clk: Add ZynqMP clock driver
From: Jolly Shah
This patch adds CCF compliant clock driver for ZynqMP.
Clock driver queries supported clock information from
firmware and regiters pll and output clocks with CCF.
Signed-off-by: Rajan Vaja
Signed-off-by: Tejas Patel
Signed-off-by: Shubhrajyoti Datta
Signed-off-by: Jolly Shah
Acked-by: Olof Johansson
---
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/zynqmp/Kconfig | 10 +
drivers/clk/zynqmp/Makefile | 4 +
drivers/clk/zynqmp/clk-gate-zynqmp.c | 144 +++
drivers/clk/zynqmp/clk-mux-zynqmp.c | 141 +++
drivers/clk/zynqmp/clk-zynqmp.h | 68
drivers/clk/zynqmp/clkc.c| 716 +++
drivers/clk/zynqmp/divider.c | 217 +++
drivers/clk/zynqmp/pll.c | 335
include/linux/firmware/xlnx-zynqmp.h | 1 +
11 files changed, 1638 insertions(+)
create mode 100644 drivers/clk/zynqmp/Kconfig
create mode 100644 drivers/clk/zynqmp/Makefile
create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h
create mode 100644 drivers/clk/zynqmp/clkc.c
create mode 100644 drivers/clk/zynqmp/divider.c
create mode 100644 drivers/clk/zynqmp/pll.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 98ce9fc..ab2ea76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -253,5 +253,6 @@ source "drivers/clk/sunxi-ng/Kconfig"
source "drivers/clk/tegra/Kconfig"
source "drivers/clk/ti/Kconfig"
source "drivers/clk/uniphier/Kconfig"
+source "drivers/clk/zynqmp/Kconfig"
endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71ec41e..b6ac0d2 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -100,3 +100,4 @@ obj-$(CONFIG_X86) += x86/
endif
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
+obj-$(CONFIG_COMMON_CLK_ZYNQMP) += zynqmp/
diff --git a/drivers/clk/zynqmp/Kconfig b/drivers/clk/zynqmp/Kconfig
new file mode 100644
index 000..1708605
--- /dev/null
+++ b/drivers/clk/zynqmp/Kconfig
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config COMMON_CLK_ZYNQMP
+ bool "Support for Xilinx ZynqMP Ultrascale+ clock controllers"
+ depends on ARCH_ZYNQMP || COMPILE_TEST
+ depends on ZYNQMP_FIRMWARE
+ help
+ Support for the Zynqmp Ultrascale clock controller.
+ It has a dependency on the PMU firmware.
+ Say Y if you want to include clock support.
diff --git a/drivers/clk/zynqmp/Makefile b/drivers/clk/zynqmp/Makefile
new file mode 100644
index 000..0ec24bf
--- /dev/null
+++ b/drivers/clk/zynqmp/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+# Zynq Ultrascale+ MPSoC clock specific Makefile
+
+obj-$(CONFIG_ARCH_ZYNQMP) += pll.o clk-gate-zynqmp.o divider.o
clk-mux-zynqmp.o clkc.o
diff --git a/drivers/clk/zynqmp/clk-gate-zynqmp.c
b/drivers/clk/zynqmp/clk-gate-zynqmp.c
new file mode 100644
index 000..83b236f
--- /dev/null
+++ b/drivers/clk/zynqmp/clk-gate-zynqmp.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Zynq UltraScale+ MPSoC clock controller
+ *
+ * Copyright (C) 2016-2018 Xilinx
+ *
+ * Gated clock implementation
+ */
+
+#include
+#include
+#include "clk-zynqmp.h"
+
+/**
+ * struct clk_gate - gating clock
+ * @hw:handle between common and hardware-specific interfaces
+ * @flags: hardware-specific flags
+ * @clk_id:Id of clock
+ */
+struct zynqmp_clk_gate {
+ struct clk_hw hw;
+ u8 flags;
+ u32 clk_id;
+};
+
+#define to_zynqmp_clk_gate(_hw) container_of(_hw, struct zynqmp_clk_gate, hw)
+
+/**
+ * zynqmp_clk_gate_enable() - Enable clock
+ * @hw:handle between common and hardware-specific interfaces
+ *
+ * Return: 0 on success else error code
+ */
+static int zynqmp_clk_gate_enable(struct clk_hw *hw)
+{
+ struct zynqmp_clk_gate *gate = to_zynqmp_clk_gate(hw);
+ const char *clk_name = clk_hw_get_name(hw);
+ u32 clk_id = gate->clk_id;
+ int ret;
+ const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+ ret = eemi_ops->clock_enable(clk_id);
+
+ if (ret)
+ pr_warn_once("%s() clock enabled failed for %s, ret = %d\n",
+__func__, clk_name, ret);
+
+ return ret;
+}
+
+/*
+ * zynqmp_clk_gate_disable() - Disable clock
+ * @hw:handle between common and hardware-specific interfaces
+ */
+static void zynqmp_clk_gate_disable(struct clk_hw *hw)
+{
+ struct zynqmp_clk_gate *gate = to_zynqmp_clk_gate(hw);
+ const char *clk_name = clk_hw_get_name(hw);
+ u32 clk_id = gate->clk_id;
+ int ret;
+ const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+ ret = eemi_ops->clock_disable(clk_id);
+
+ if
[PATCH v5 0/4] drivers: clk: Add ZynqMP clock driver support
This patchset adds CCF compliant clock driver for ZynqMP.Clock driver queries supported clock information from firmware and regiters pll and output clocks with CCF. This patch series is earlier reveiwed as part of FW patchset (https://patchwork.kernel.org/cover/10555405/). FW driver from that patchset is merged. This patchset contains only clock driver and is based on top of xilinx firmware patch set available in below tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=next/drivers v5: - Added "Acked-by: Olof Johansson " for patches v4: - Fixed minor review comments received for v3 patchset v3: - Added check to pass only valid ioctls for ioctl eemi api - Added eemi documentation including ioctl details Jolly Shah (1): drivers: clk: Add ZynqMP clock driver Rajan Vaja (3): Documentation: xilinx: Add documentation for eemi APIs firmware: xilinx: Add zynqmp IOCTL API for device control dt-bindings: clock: Add bindings for ZynqMP clock driver .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 53 ++ Documentation/xilinx/eemi.txt | 67 ++ drivers/clk/Kconfig| 1 + drivers/clk/Makefile | 1 + drivers/clk/zynqmp/Kconfig | 10 + drivers/clk/zynqmp/Makefile| 4 + drivers/clk/zynqmp/clk-gate-zynqmp.c | 144 + drivers/clk/zynqmp/clk-mux-zynqmp.c| 141 drivers/clk/zynqmp/clk-zynqmp.h| 68 ++ drivers/clk/zynqmp/clkc.c | 716 + drivers/clk/zynqmp/divider.c | 217 +++ drivers/clk/zynqmp/pll.c | 335 ++ drivers/firmware/xilinx/zynqmp.c | 42 ++ include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 include/linux/firmware/xlnx-zynqmp.h | 5 +- 15 files changed, 1919 insertions(+), 1 deletion(-) create mode 100644 Documentation/xilinx/eemi.txt create mode 100644 drivers/clk/zynqmp/Kconfig create mode 100644 drivers/clk/zynqmp/Makefile create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h create mode 100644 drivers/clk/zynqmp/clkc.c create mode 100644 drivers/clk/zynqmp/divider.c create mode 100644 drivers/clk/zynqmp/pll.c create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h -- 2.7.4
[PATCH v5 0/4] drivers: clk: Add ZynqMP clock driver support
This patchset adds CCF compliant clock driver for ZynqMP.Clock driver queries supported clock information from firmware and regiters pll and output clocks with CCF. This patch series is earlier reveiwed as part of FW patchset (https://patchwork.kernel.org/cover/10555405/). FW driver from that patchset is merged. This patchset contains only clock driver and is based on top of xilinx firmware patch set available in below tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=next/drivers v5: - Added "Acked-by: Olof Johansson " for patches v4: - Fixed minor review comments received for v3 patchset v3: - Added check to pass only valid ioctls for ioctl eemi api - Added eemi documentation including ioctl details Jolly Shah (1): drivers: clk: Add ZynqMP clock driver Rajan Vaja (3): Documentation: xilinx: Add documentation for eemi APIs firmware: xilinx: Add zynqmp IOCTL API for device control dt-bindings: clock: Add bindings for ZynqMP clock driver .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 53 ++ Documentation/xilinx/eemi.txt | 67 ++ drivers/clk/Kconfig| 1 + drivers/clk/Makefile | 1 + drivers/clk/zynqmp/Kconfig | 10 + drivers/clk/zynqmp/Makefile| 4 + drivers/clk/zynqmp/clk-gate-zynqmp.c | 144 + drivers/clk/zynqmp/clk-mux-zynqmp.c| 141 drivers/clk/zynqmp/clk-zynqmp.h| 68 ++ drivers/clk/zynqmp/clkc.c | 716 + drivers/clk/zynqmp/divider.c | 217 +++ drivers/clk/zynqmp/pll.c | 335 ++ drivers/firmware/xilinx/zynqmp.c | 42 ++ include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 include/linux/firmware/xlnx-zynqmp.h | 5 +- 15 files changed, 1919 insertions(+), 1 deletion(-) create mode 100644 Documentation/xilinx/eemi.txt create mode 100644 drivers/clk/zynqmp/Kconfig create mode 100644 drivers/clk/zynqmp/Makefile create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c create mode 100644 drivers/clk/zynqmp/clk-zynqmp.h create mode 100644 drivers/clk/zynqmp/clkc.c create mode 100644 drivers/clk/zynqmp/divider.c create mode 100644 drivers/clk/zynqmp/pll.c create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h -- 2.7.4
[PATCH v5 1/4] Documentation: xilinx: Add documentation for eemi APIs
From: Rajan Vaja
Add documentation for embedded energy management interface (EEMI)
APIs. It includes information about eemi ops and how to use them.
It also includes API information and supported IOCTL IDs which can
be used for device and control configuration.
Signed-off-by: Rajan Vaja
Signed-off-by: Jolly Shah
Acked-by: Olof Johansson
---
Documentation/xilinx/eemi.txt | 67 +++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/xilinx/eemi.txt
diff --git a/Documentation/xilinx/eemi.txt b/Documentation/xilinx/eemi.txt
new file mode 100644
index 000..0ab686c
--- /dev/null
+++ b/Documentation/xilinx/eemi.txt
@@ -0,0 +1,67 @@
+-
+Xilinx Zynq MPSoC EEMI Documentation
+-
+
+Xilinx Zynq MPSoC Firmware Interface
+-
+The zynqmp-firmware node describes the interface to platform firmware.
+ZynqMP has an interface to communicate with secure firmware. Firmware
+driver provides an interface to firmware APIs. Interface APIs can be
+used by any driver to communicate with PMC(Platform Management Controller).
+
+Embedded Energy Management Interface (EEMI)
+--
+The embedded energy management interface is used to allow software
+components running across different processing clusters on a chip or
+device to communicate with a power management controller (PMC) on a
+device to issue or respond to power management requests.
+
+EEMI ops is a structure containing all eemi APIs supported by Zynq MPSoC.
+The zynqmp-firmware driver maintain all EEMI APIs in zynqmp_eemi_ops
+structure. Any driver who want to communicate with PMC using EEMI APIs
+can call zynqmp_pm_get_eemi_ops().
+
+Example of EEMI ops:
+
+ /* zynqmp-firmware driver maintain all EEMI APIs */
+ struct zynqmp_eemi_ops {
+ int (*get_api_version)(u32 *version);
+ int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
+ };
+
+ static const struct zynqmp_eemi_ops eemi_ops = {
+ .get_api_version = zynqmp_pm_get_api_version,
+ .query_data = zynqmp_pm_query_data,
+ };
+
+Example of EEMI ops usage:
+
+ static const struct zynqmp_eemi_ops *eemi_ops;
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ eemi_ops = zynqmp_pm_get_eemi_ops();
+ if (!eemi_ops)
+ return -ENXIO;
+
+ ret = eemi_ops->query_data(qdata, ret_payload);
+
+IOCTL
+--
+IOCTL API is for device control and configuration. It is not a system
+IOCTL but it is an EEMI API. This API can be used by master to control
+any device specific configuration. IOCTL definitions can be platform
+specific. This API also manage shared device configuration.
+
+The following IOCTL IDs are valid for device control:
+- IOCTL_SET_PLL_FRAC_MODE 8
+- IOCTL_GET_PLL_FRAC_MODE 9
+- IOCTL_SET_PLL_FRAC_DATA 10
+- IOCTL_GET_PLL_FRAC_DATA 11
+
+Refer EEMI API guide [0] for IOCTL specific parameters and other EEMI APIs.
+
+References
+--
+[0] Embedded Energy Management Interface (EEMI) API guide:
+
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
--
2.7.4
[PATCH v5 2/4] firmware: xilinx: Add zynqmp IOCTL API for device control
From: Rajan Vaja
Add ZynqMP firmware IOCTL API to control and configure
devices like PLLs, SD, Gem, etc.
Signed-off-by: Rajan Vaja
Signed-off-by: Jolly Shah
Acked-by: Olof Johansson
---
drivers/firmware/xilinx/zynqmp.c | 42
include/linux/firmware/xlnx-zynqmp.h | 4 +++-
2 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2..9a1c72a 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -428,6 +428,47 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32
*parent_id)
return ret;
}
+/**
+ * zynqmp_is_valid_ioctl() - Check whether IOCTL ID is valid or not
+ * @ioctl_id: IOCTL ID
+ *
+ * Return: 1 if IOCTL is valid else 0
+ */
+static inline int zynqmp_is_valid_ioctl(u32 ioctl_id)
+{
+ switch (ioctl_id) {
+ case IOCTL_SET_PLL_FRAC_MODE:
+ case IOCTL_GET_PLL_FRAC_MODE:
+ case IOCTL_SET_PLL_FRAC_DATA:
+ case IOCTL_GET_PLL_FRAC_DATA:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+/**
+ * zynqmp_pm_ioctl() - PM IOCTL API for device control and configs
+ * @node_id: Node ID of the device
+ * @ioctl_id: ID of the requested IOCTL
+ * @arg1: Argument 1 to requested IOCTL call
+ * @arg2: Argument 2 to requested IOCTL call
+ * @out: Returned output value
+ *
+ * This function calls IOCTL to firmware for device control and configuration.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2,
+ u32 *out)
+{
+ if (!zynqmp_is_valid_ioctl(ioctl_id))
+ return -EINVAL;
+
+ return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, ioctl_id,
+ arg1, arg2, out);
+}
+
static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -440,6 +481,7 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_getrate = zynqmp_pm_clock_getrate,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
+ .ioctl = zynqmp_pm_ioctl,
};
/**
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130..7a9db08 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -34,7 +34,8 @@
enum pm_api_id {
PM_GET_API_VERSION = 1,
- PM_QUERY_DATA = 35,
+ PM_IOCTL = 34,
+ PM_QUERY_DATA,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
PM_CLOCK_GETSTATE,
@@ -99,6 +100,7 @@ struct zynqmp_eemi_ops {
int (*clock_getrate)(u32 clock_id, u64 *rate);
int (*clock_setparent)(u32 clock_id, u32 parent_id);
int (*clock_getparent)(u32 clock_id, u32 *parent_id);
+ int (*ioctl)(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, u32 *out);
};
#if IS_REACHABLE(CONFIG_ARCH_ZYNQMP)
--
2.7.4
[PATCH v5 1/4] Documentation: xilinx: Add documentation for eemi APIs
From: Rajan Vaja
Add documentation for embedded energy management interface (EEMI)
APIs. It includes information about eemi ops and how to use them.
It also includes API information and supported IOCTL IDs which can
be used for device and control configuration.
Signed-off-by: Rajan Vaja
Signed-off-by: Jolly Shah
Acked-by: Olof Johansson
---
Documentation/xilinx/eemi.txt | 67 +++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/xilinx/eemi.txt
diff --git a/Documentation/xilinx/eemi.txt b/Documentation/xilinx/eemi.txt
new file mode 100644
index 000..0ab686c
--- /dev/null
+++ b/Documentation/xilinx/eemi.txt
@@ -0,0 +1,67 @@
+-
+Xilinx Zynq MPSoC EEMI Documentation
+-
+
+Xilinx Zynq MPSoC Firmware Interface
+-
+The zynqmp-firmware node describes the interface to platform firmware.
+ZynqMP has an interface to communicate with secure firmware. Firmware
+driver provides an interface to firmware APIs. Interface APIs can be
+used by any driver to communicate with PMC(Platform Management Controller).
+
+Embedded Energy Management Interface (EEMI)
+--
+The embedded energy management interface is used to allow software
+components running across different processing clusters on a chip or
+device to communicate with a power management controller (PMC) on a
+device to issue or respond to power management requests.
+
+EEMI ops is a structure containing all eemi APIs supported by Zynq MPSoC.
+The zynqmp-firmware driver maintain all EEMI APIs in zynqmp_eemi_ops
+structure. Any driver who want to communicate with PMC using EEMI APIs
+can call zynqmp_pm_get_eemi_ops().
+
+Example of EEMI ops:
+
+ /* zynqmp-firmware driver maintain all EEMI APIs */
+ struct zynqmp_eemi_ops {
+ int (*get_api_version)(u32 *version);
+ int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
+ };
+
+ static const struct zynqmp_eemi_ops eemi_ops = {
+ .get_api_version = zynqmp_pm_get_api_version,
+ .query_data = zynqmp_pm_query_data,
+ };
+
+Example of EEMI ops usage:
+
+ static const struct zynqmp_eemi_ops *eemi_ops;
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ eemi_ops = zynqmp_pm_get_eemi_ops();
+ if (!eemi_ops)
+ return -ENXIO;
+
+ ret = eemi_ops->query_data(qdata, ret_payload);
+
+IOCTL
+--
+IOCTL API is for device control and configuration. It is not a system
+IOCTL but it is an EEMI API. This API can be used by master to control
+any device specific configuration. IOCTL definitions can be platform
+specific. This API also manage shared device configuration.
+
+The following IOCTL IDs are valid for device control:
+- IOCTL_SET_PLL_FRAC_MODE 8
+- IOCTL_GET_PLL_FRAC_MODE 9
+- IOCTL_SET_PLL_FRAC_DATA 10
+- IOCTL_GET_PLL_FRAC_DATA 11
+
+Refer EEMI API guide [0] for IOCTL specific parameters and other EEMI APIs.
+
+References
+--
+[0] Embedded Energy Management Interface (EEMI) API guide:
+
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
--
2.7.4
[PATCH v5 2/4] firmware: xilinx: Add zynqmp IOCTL API for device control
From: Rajan Vaja
Add ZynqMP firmware IOCTL API to control and configure
devices like PLLs, SD, Gem, etc.
Signed-off-by: Rajan Vaja
Signed-off-by: Jolly Shah
Acked-by: Olof Johansson
---
drivers/firmware/xilinx/zynqmp.c | 42
include/linux/firmware/xlnx-zynqmp.h | 4 +++-
2 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2..9a1c72a 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -428,6 +428,47 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32
*parent_id)
return ret;
}
+/**
+ * zynqmp_is_valid_ioctl() - Check whether IOCTL ID is valid or not
+ * @ioctl_id: IOCTL ID
+ *
+ * Return: 1 if IOCTL is valid else 0
+ */
+static inline int zynqmp_is_valid_ioctl(u32 ioctl_id)
+{
+ switch (ioctl_id) {
+ case IOCTL_SET_PLL_FRAC_MODE:
+ case IOCTL_GET_PLL_FRAC_MODE:
+ case IOCTL_SET_PLL_FRAC_DATA:
+ case IOCTL_GET_PLL_FRAC_DATA:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+/**
+ * zynqmp_pm_ioctl() - PM IOCTL API for device control and configs
+ * @node_id: Node ID of the device
+ * @ioctl_id: ID of the requested IOCTL
+ * @arg1: Argument 1 to requested IOCTL call
+ * @arg2: Argument 2 to requested IOCTL call
+ * @out: Returned output value
+ *
+ * This function calls IOCTL to firmware for device control and configuration.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2,
+ u32 *out)
+{
+ if (!zynqmp_is_valid_ioctl(ioctl_id))
+ return -EINVAL;
+
+ return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, ioctl_id,
+ arg1, arg2, out);
+}
+
static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -440,6 +481,7 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_getrate = zynqmp_pm_clock_getrate,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
+ .ioctl = zynqmp_pm_ioctl,
};
/**
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130..7a9db08 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -34,7 +34,8 @@
enum pm_api_id {
PM_GET_API_VERSION = 1,
- PM_QUERY_DATA = 35,
+ PM_IOCTL = 34,
+ PM_QUERY_DATA,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
PM_CLOCK_GETSTATE,
@@ -99,6 +100,7 @@ struct zynqmp_eemi_ops {
int (*clock_getrate)(u32 clock_id, u64 *rate);
int (*clock_setparent)(u32 clock_id, u32 parent_id);
int (*clock_getparent)(u32 clock_id, u32 *parent_id);
+ int (*ioctl)(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2, u32 *out);
};
#if IS_REACHABLE(CONFIG_ARCH_ZYNQMP)
--
2.7.4
[PATCH v5 3/4] dt-bindings: clock: Add bindings for ZynqMP clock driver
From: Rajan Vaja
Add documentation to describe Xilinx ZynqMP clock driver
bindings.
Signed-off-by: Rajan Vaja
Signed-off-by: Jolly Shah
Reviewed-by: Rob Herring
Reviewed-by: Stephen Boyd
---
.../firmware/xilinx/xlnx,zynqmp-firmware.txt | 53 ++
include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 +
2 files changed, 169 insertions(+)
create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h
diff --git
a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
index 1b431d9..614bac5 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -17,6 +17,53 @@ Required properties:
- "smc" : SMC #0, following the SMCCC
- "hvc" : HVC #0, following the SMCCC
+--
+Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
+Zynq MPSoC firmware interface
+--
+The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
+tree. It reads required input clock frequencies from the devicetree and acts
+as clock provider for all clock consumers of PS clocks.
+
+See clock_bindings.txt for more information on the generic clock bindings.
+
+Required properties:
+ - #clock-cells: Must be 1
+ - compatible: Must contain: "xlnx,zynqmp-clk"
+ - clocks: List of clock specifiers which are external input
+ clocks to the given clock controller. Please refer
+ the next section to find the input clocks for a
+ given controller.
+ - clock-names:List of clock names which are exteral input
clocks
+ to the given clock controller. Please refer to the
+ clock bindings for more details.
+
+Input clocks for zynqmp Ultrascale+ clock controller:
+
+The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock
+inputs. These required clock inputs are:
+ - pss_ref_clk (PS reference clock)
+ - video_clk (reference clock for video system )
+ - pss_alt_ref_clk (alternative PS reference clock)
+ - aux_ref_clk
+ - gt_crx_ref_clk (transceiver reference clock)
+
+The following strings are optional parameters to the 'clock-names' property in
+order to provide an optional (E)MIO clock source:
+ - swdt0_ext_clk
+ - swdt1_ext_clk
+ - gem0_emio_clk
+ - gem1_emio_clk
+ - gem2_emio_clk
+ - gem3_emio_clk
+ - mio_clk_XX # with XX = 00..77
+ - mio_clk_50_or_51#for the mux clock to gem tsu from 50 or 51
+
+
+Output clocks are registered based on clock information received
+from firmware. Output clocks indexes are mentioned in
+include/dt-bindings/clock/xlnx,zynqmp-clk.h.
+
---
Example
---
@@ -25,5 +72,11 @@ firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
+ zynqmp_clk: clock-controller {
+ #clock-cells = <1>;
+ compatible = "xlnx,zynqmp-clk";
+ clocks = <_ref_clk>, <_clk>,
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
+ clock-names = "pss_ref_clk", "video_clk",
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
+ };
};
};
diff --git a/include/dt-bindings/clock/xlnx,zynqmp-clk.h
b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
new file mode 100644
index 000..4aebe6e
--- /dev/null
+++ b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
@@ -0,0 +1,116 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Xilinx Zynq MPSoC Firmware layer
+ *
+ * Copyright (C) 2014-2018 Xilinx, Inc.
+ *
+ */
+
+#ifndef _DT_BINDINGS_CLK_ZYNQMP_H
+#define _DT_BINDINGS_CLK_ZYNQMP_H
+
+#define IOPLL 0
+#define RPLL 1
+#define APLL 2
+#define DPLL 3
+#define VPLL 4
+#define IOPLL_TO_FPD 5
+#define RPLL_TO_FPD6
+#define APLL_TO_LPD7
+#define DPLL_TO_LPD8
+#define VPLL_TO_LPD9
+#define ACPU 10
+#define ACPU_HALF 11
+#define DBF_FPD12
+#define DBF_LPD13
+#define DBG_TRACE 14
+#define DBG_TSTMP 15
+#define DP_VIDEO_REF 16
+#define DP_AUDIO_REF 17
+#define DP_STC_REF 18
+#define GDMA_REF 19
+#define DPDMA_REF 20
+#define DDR_REF21
+#define SATA_REF 22
+#define PCIE_REF 23
+#define GPU_REF24
+#define GPU_PP0_REF25
+#define GPU_PP1_REF26
[PATCH v5 3/4] dt-bindings: clock: Add bindings for ZynqMP clock driver
From: Rajan Vaja
Add documentation to describe Xilinx ZynqMP clock driver
bindings.
Signed-off-by: Rajan Vaja
Signed-off-by: Jolly Shah
Reviewed-by: Rob Herring
Reviewed-by: Stephen Boyd
---
.../firmware/xilinx/xlnx,zynqmp-firmware.txt | 53 ++
include/dt-bindings/clock/xlnx,zynqmp-clk.h| 116 +
2 files changed, 169 insertions(+)
create mode 100644 include/dt-bindings/clock/xlnx,zynqmp-clk.h
diff --git
a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
index 1b431d9..614bac5 100644
--- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
@@ -17,6 +17,53 @@ Required properties:
- "smc" : SMC #0, following the SMCCC
- "hvc" : HVC #0, following the SMCCC
+--
+Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
+Zynq MPSoC firmware interface
+--
+The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
+tree. It reads required input clock frequencies from the devicetree and acts
+as clock provider for all clock consumers of PS clocks.
+
+See clock_bindings.txt for more information on the generic clock bindings.
+
+Required properties:
+ - #clock-cells: Must be 1
+ - compatible: Must contain: "xlnx,zynqmp-clk"
+ - clocks: List of clock specifiers which are external input
+ clocks to the given clock controller. Please refer
+ the next section to find the input clocks for a
+ given controller.
+ - clock-names:List of clock names which are exteral input
clocks
+ to the given clock controller. Please refer to the
+ clock bindings for more details.
+
+Input clocks for zynqmp Ultrascale+ clock controller:
+
+The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock
+inputs. These required clock inputs are:
+ - pss_ref_clk (PS reference clock)
+ - video_clk (reference clock for video system )
+ - pss_alt_ref_clk (alternative PS reference clock)
+ - aux_ref_clk
+ - gt_crx_ref_clk (transceiver reference clock)
+
+The following strings are optional parameters to the 'clock-names' property in
+order to provide an optional (E)MIO clock source:
+ - swdt0_ext_clk
+ - swdt1_ext_clk
+ - gem0_emio_clk
+ - gem1_emio_clk
+ - gem2_emio_clk
+ - gem3_emio_clk
+ - mio_clk_XX # with XX = 00..77
+ - mio_clk_50_or_51#for the mux clock to gem tsu from 50 or 51
+
+
+Output clocks are registered based on clock information received
+from firmware. Output clocks indexes are mentioned in
+include/dt-bindings/clock/xlnx,zynqmp-clk.h.
+
---
Example
---
@@ -25,5 +72,11 @@ firmware {
zynqmp_firmware: zynqmp-firmware {
compatible = "xlnx,zynqmp-firmware";
method = "smc";
+ zynqmp_clk: clock-controller {
+ #clock-cells = <1>;
+ compatible = "xlnx,zynqmp-clk";
+ clocks = <_ref_clk>, <_clk>,
<_alt_ref_clk>, <_ref_clk>, <_crx_ref_clk>;
+ clock-names = "pss_ref_clk", "video_clk",
"pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
+ };
};
};
diff --git a/include/dt-bindings/clock/xlnx,zynqmp-clk.h
b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
new file mode 100644
index 000..4aebe6e
--- /dev/null
+++ b/include/dt-bindings/clock/xlnx,zynqmp-clk.h
@@ -0,0 +1,116 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Xilinx Zynq MPSoC Firmware layer
+ *
+ * Copyright (C) 2014-2018 Xilinx, Inc.
+ *
+ */
+
+#ifndef _DT_BINDINGS_CLK_ZYNQMP_H
+#define _DT_BINDINGS_CLK_ZYNQMP_H
+
+#define IOPLL 0
+#define RPLL 1
+#define APLL 2
+#define DPLL 3
+#define VPLL 4
+#define IOPLL_TO_FPD 5
+#define RPLL_TO_FPD6
+#define APLL_TO_LPD7
+#define DPLL_TO_LPD8
+#define VPLL_TO_LPD9
+#define ACPU 10
+#define ACPU_HALF 11
+#define DBF_FPD12
+#define DBF_LPD13
+#define DBG_TRACE 14
+#define DBG_TSTMP 15
+#define DP_VIDEO_REF 16
+#define DP_AUDIO_REF 17
+#define DP_STC_REF 18
+#define GDMA_REF 19
+#define DPDMA_REF 20
+#define DDR_REF21
+#define SATA_REF 22
+#define PCIE_REF 23
+#define GPU_REF24
+#define GPU_PP0_REF25
+#define GPU_PP1_REF26
Re: [PATCH] fix memory leak in ramoops_init
In the future, please use scripts/get_maintainer.pl to find your To/Cc list. :)
On Mon, Sep 17, 2018 at 2:15 AM, nixiaoming wrote:
> 1, memory leak in ramoops_register_dummy.
>dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL);
>but no free when platform_device_register_data return fail
Yup, that's a problem.
> 2, if kzalloc(sizeof(*dummy_data), GFP_KERNEL) return NULL,
> but platform_driver_register(_driver) return 0
>kfree(NULL) in ramoops_exit
> so, add return val for ramoops_register_dummy, and check it in ramoops_init
The kfree(NULL) isn't a problem, but a NULL platform_data implies
device tree data is expected, so it'll just confuse things. However,
since the dummy platform data is optional, there's no need to plumb
the return value back up. Either it gets set up correctly, or there is
a pr_info() about why it has been ignored.
> 3, memory leak in ramoops_init.
>miss platform_device_unregister(dummy) and kfree(dummy_data)
>when platform_driver_register(_driver) return fail
Agreed.
> Signed-off-by: nixiaoming
> ---
> fs/pstore/ram.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index bd9812e..331b600 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -604,17 +604,17 @@ static struct platform_driver ramoops_driver = {
> },
> };
>
> -static void ramoops_register_dummy(void)
> +static int ramoops_register_dummy(void)
Another bug is that this should actually be __init (it's only called
by an __init).
> {
> if (!mem_size)
> - return;
> + return -EINVAL;
>
> pr_info("using module parameters\n");
>
> dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL);
> if (!dummy_data) {
> pr_info("could not allocate pdata\n");
> - return;
> + return -ENOMEM;
> }
>
> dummy_data->mem_size = mem_size;
> @@ -636,13 +636,25 @@ static void ramoops_register_dummy(void)
> if (IS_ERR(dummy)) {
> pr_info("could not create platform device: %ld\n",
> PTR_ERR(dummy));
> + kfree(dummy_data);
> + return PTR_ERR(dummy);
> }
> + return 0;
> }
>
> static int __init ramoops_init(void)
> {
> - ramoops_register_dummy();
> - return platform_driver_register(_driver);
> + int ret = ramoops_register_dummy();
> +
> + if (ret != 0)
> + return ret;
> +
> + ret = platform_driver_register(_driver);
> + if (ret != 0) {
> + platform_device_unregister(dummy);
> + kfree(dummy_data);
> + }
> + return ret;
> }
> postcore_initcall(ramoops_init);
>
> --
> 1.9.0
>
I'll send an updated patch with a similar fix...
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH] fix memory leak in ramoops_init
In the future, please use scripts/get_maintainer.pl to find your To/Cc list. :)
On Mon, Sep 17, 2018 at 2:15 AM, nixiaoming wrote:
> 1, memory leak in ramoops_register_dummy.
>dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL);
>but no free when platform_device_register_data return fail
Yup, that's a problem.
> 2, if kzalloc(sizeof(*dummy_data), GFP_KERNEL) return NULL,
> but platform_driver_register(_driver) return 0
>kfree(NULL) in ramoops_exit
> so, add return val for ramoops_register_dummy, and check it in ramoops_init
The kfree(NULL) isn't a problem, but a NULL platform_data implies
device tree data is expected, so it'll just confuse things. However,
since the dummy platform data is optional, there's no need to plumb
the return value back up. Either it gets set up correctly, or there is
a pr_info() about why it has been ignored.
> 3, memory leak in ramoops_init.
>miss platform_device_unregister(dummy) and kfree(dummy_data)
>when platform_driver_register(_driver) return fail
Agreed.
> Signed-off-by: nixiaoming
> ---
> fs/pstore/ram.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index bd9812e..331b600 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -604,17 +604,17 @@ static struct platform_driver ramoops_driver = {
> },
> };
>
> -static void ramoops_register_dummy(void)
> +static int ramoops_register_dummy(void)
Another bug is that this should actually be __init (it's only called
by an __init).
> {
> if (!mem_size)
> - return;
> + return -EINVAL;
>
> pr_info("using module parameters\n");
>
> dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL);
> if (!dummy_data) {
> pr_info("could not allocate pdata\n");
> - return;
> + return -ENOMEM;
> }
>
> dummy_data->mem_size = mem_size;
> @@ -636,13 +636,25 @@ static void ramoops_register_dummy(void)
> if (IS_ERR(dummy)) {
> pr_info("could not create platform device: %ld\n",
> PTR_ERR(dummy));
> + kfree(dummy_data);
> + return PTR_ERR(dummy);
> }
> + return 0;
> }
>
> static int __init ramoops_init(void)
> {
> - ramoops_register_dummy();
> - return platform_driver_register(_driver);
> + int ret = ramoops_register_dummy();
> +
> + if (ret != 0)
> + return ret;
> +
> + ret = platform_driver_register(_driver);
> + if (ret != 0) {
> + platform_device_unregister(dummy);
> + kfree(dummy_data);
> + }
> + return ret;
> }
> postcore_initcall(ramoops_init);
>
> --
> 1.9.0
>
I'll send an updated patch with a similar fix...
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH v7 0/6] seccomp trap to userspace
Hi Tycho, On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote: > > On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) wrote: > > Hi Tycho, > > > > On 09/27/2018 05:11 PM, Tycho Andersen wrote: > > > Hi all, > > > > > > Here's v7 of the seccomp trap to userspace set. There are various minor > > > changes and bug fixes, but two major changes: > > > > > > * We now pass fds to the tracee via an ioctl, and do it immediately when > > >the ioctl is called. For this we needed some help from the vfs, so > > >I've put the one patch in this series and cc'd fsdevel. This does have > > >the advantage that the feature is now totally decoupled from the rest > > >of the set, which is itself useful (thanks Andy!) > > > > > > * Instead of putting all of the notification related stuff into the > > >struct seccomp_filter, it now lives in its own struct notification, > > >which is pointed to by struct seccomp_filter. This will save a lot of > > >memory (thanks Tyler!) > > > > Is there a documentation (man page) patch for this API change? > > Not yet, but once we decide on a final API I'll prepare one. Honestly, the production of such documentation should be part of the evolution towards the final API... Documentation is not an afterthought. It's a tool for pushing you, the developer (and others, your reviewers) to more deeply consider your design. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH v7 0/6] seccomp trap to userspace
Hi Tycho, On Sat, 29 Sep 2018 at 00:04, Tycho Andersen wrote: > > On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) wrote: > > Hi Tycho, > > > > On 09/27/2018 05:11 PM, Tycho Andersen wrote: > > > Hi all, > > > > > > Here's v7 of the seccomp trap to userspace set. There are various minor > > > changes and bug fixes, but two major changes: > > > > > > * We now pass fds to the tracee via an ioctl, and do it immediately when > > >the ioctl is called. For this we needed some help from the vfs, so > > >I've put the one patch in this series and cc'd fsdevel. This does have > > >the advantage that the feature is now totally decoupled from the rest > > >of the set, which is itself useful (thanks Andy!) > > > > > > * Instead of putting all of the notification related stuff into the > > >struct seccomp_filter, it now lives in its own struct notification, > > >which is pointed to by struct seccomp_filter. This will save a lot of > > >memory (thanks Tyler!) > > > > Is there a documentation (man page) patch for this API change? > > Not yet, but once we decide on a final API I'll prepare one. Honestly, the production of such documentation should be part of the evolution towards the final API... Documentation is not an afterthought. It's a tool for pushing you, the developer (and others, your reviewers) to more deeply consider your design. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
On 29.09.2018 00:00, Chris Clayton wrote: > Thanks Maciej. > > On 28/09/2018 16:54, Maciej S. Szmigiero wrote: >> Hi, >> >>> Hi, >>> >>> I upgraded my kernel to 4.18.10 recently and have since been experiencing >>> network problems after resuming from a >>> suspend to RAM or disk. I previously had 4.18.6 and that was OK. >>> >>> The pattern of the problem is that when I first boot, the network is fine. >>> But, after resume from suspend I find that >>> the time taken for a ping of one of my ISP's nameservers increases from >>> 14-15ms to more than 1000ms. Moreover, when I >>> open a browser (chromium or firefox), it fails to retrieve my home page >>> (https://www.google.co.uk) and pings of the >>> nameserver fail with the message "Destination Host Unreachable". Often, I >>> can revive the network by stopping it with >>> /sbin/if(down,up} but sometimes it is necessary to also remove the r8169 >>> module and load it again. >> >> Please have a look at the following thread: >> https://lkml.org/lkml/2018/9/25/1118 >> > > I applied your patch for the 4.18 stable kernels to 4.18.10, but the problem > is not solved by it. Similarly, I applied > Heiner's patch to the 4.19, but again the problem is not solved. > I think we talk about two different issues here. The one the fix is for has no link to suspend/resume. Chris, the lspci output doesn't provide enough detail to determine the exact chip version. Can you provide the dmesg part with the XID? According to your lspci output neither MSI nor MSI-X is active. Do you have to use nomsi for whatever reason? Heiner >> Maciej >> > Chris >
Re: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
On 29.09.2018 00:00, Chris Clayton wrote: > Thanks Maciej. > > On 28/09/2018 16:54, Maciej S. Szmigiero wrote: >> Hi, >> >>> Hi, >>> >>> I upgraded my kernel to 4.18.10 recently and have since been experiencing >>> network problems after resuming from a >>> suspend to RAM or disk. I previously had 4.18.6 and that was OK. >>> >>> The pattern of the problem is that when I first boot, the network is fine. >>> But, after resume from suspend I find that >>> the time taken for a ping of one of my ISP's nameservers increases from >>> 14-15ms to more than 1000ms. Moreover, when I >>> open a browser (chromium or firefox), it fails to retrieve my home page >>> (https://www.google.co.uk) and pings of the >>> nameserver fail with the message "Destination Host Unreachable". Often, I >>> can revive the network by stopping it with >>> /sbin/if(down,up} but sometimes it is necessary to also remove the r8169 >>> module and load it again. >> >> Please have a look at the following thread: >> https://lkml.org/lkml/2018/9/25/1118 >> > > I applied your patch for the 4.18 stable kernels to 4.18.10, but the problem > is not solved by it. Similarly, I applied > Heiner's patch to the 4.19, but again the problem is not solved. > I think we talk about two different issues here. The one the fix is for has no link to suspend/resume. Chris, the lspci output doesn't provide enough detail to determine the exact chip version. Can you provide the dmesg part with the XID? According to your lspci output neither MSI nor MSI-X is active. Do you have to use nomsi for whatever reason? Heiner >> Maciej >> > Chris >
RE: [PATCH v3 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V
From: Yi Sun Sent: Wednesday, September 26, 2018 11:02 PM > Follow PV spinlock mechanism to implement the callback functions > to allow the CPU idling and kicking operations on Hyper-V. > > Cc: "K. Y. Srinivasan" > Cc: Haiyang Zhang > Cc: Stephen Hemminger > Cc: Thomas Gleixner > Cc: Michael Kelley (EOSG) > Signed-off-by: Yi Sun > --- Reviewed-by: Michael Kelley
RE: [PATCH v3 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V
From: Yi Sun Sent: Wednesday, September 26, 2018 11:02 PM > Follow PV spinlock mechanism to implement the callback functions > to allow the CPU idling and kicking operations on Hyper-V. > > Cc: "K. Y. Srinivasan" > Cc: Haiyang Zhang > Cc: Stephen Hemminger > Cc: Thomas Gleixner > Cc: Michael Kelley (EOSG) > Signed-off-by: Yi Sun > --- Reviewed-by: Michael Kelley
Re: [PATCH] nvmem: Convert to using %pOFn instead of device_node.name
On Mon, Aug 27, 2018 at 8:55 PM Rob Herring wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Srinivas Kandagatla
> Signed-off-by: Rob Herring
> ---
> drivers/nvmem/core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Ping. This has no dependencies, so please apply.
Rob
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index aa1657831b70..6988ee9f11ba 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -304,6 +304,7 @@ static void nvmem_cell_drop(struct nvmem_cell *cell)
> mutex_lock(_cells_mutex);
> list_del(>node);
> mutex_unlock(_cells_mutex);
> + kfree(cell->name);
> kfree(cell);
> }
>
> @@ -879,7 +880,7 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node
> *np,
> cell->nvmem = nvmem;
> cell->offset = be32_to_cpup(addr++);
> cell->bytes = be32_to_cpup(addr);
> - cell->name = cell_np->name;
> + cell->name = kasprintf(GFP_KERNEL, "%pOFn", cell_np);
>
> addr = of_get_property(cell_np, "bits", );
> if (addr && len == (2 * sizeof(u32))) {
> @@ -904,6 +905,7 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node
> *np,
> return cell;
>
> err_sanity:
> + kfree(cell->name);
> kfree(cell);
>
> err_mem:
> --
> 2.17.1
>
Re: [PATCH] nvmem: Convert to using %pOFn instead of device_node.name
On Mon, Aug 27, 2018 at 8:55 PM Rob Herring wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Srinivas Kandagatla
> Signed-off-by: Rob Herring
> ---
> drivers/nvmem/core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Ping. This has no dependencies, so please apply.
Rob
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index aa1657831b70..6988ee9f11ba 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -304,6 +304,7 @@ static void nvmem_cell_drop(struct nvmem_cell *cell)
> mutex_lock(_cells_mutex);
> list_del(>node);
> mutex_unlock(_cells_mutex);
> + kfree(cell->name);
> kfree(cell);
> }
>
> @@ -879,7 +880,7 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node
> *np,
> cell->nvmem = nvmem;
> cell->offset = be32_to_cpup(addr++);
> cell->bytes = be32_to_cpup(addr);
> - cell->name = cell_np->name;
> + cell->name = kasprintf(GFP_KERNEL, "%pOFn", cell_np);
>
> addr = of_get_property(cell_np, "bits", );
> if (addr && len == (2 * sizeof(u32))) {
> @@ -904,6 +905,7 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node
> *np,
> return cell;
>
> err_sanity:
> + kfree(cell->name);
> kfree(cell);
>
> err_mem:
> --
> 2.17.1
>
Bad MAINTAINERS pattern in section 'SYNOPSYS DESIGNWARE AXI DMAC DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 14171 SYNOPSYS DESIGNWARE AXI DMAC DRIVER 14172 M: Eugeniy Paltsev 14173 S: Maintained --> 14174 F: drivers/dma/dwi-axi-dmac/ 14175 F: Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt Commit that introduced this: commit 1fe20f1b84548bbcf48b6659ea171cd46618ea3a Author: Eugeniy Paltsev Date: Tue Mar 6 14:46:14 2018 +0300 dmaengine: Introduce DW AXI DMAC driver This patch adds support for the DW AXI DMAC controller. DW AXI DMAC is a part of HSDK development board from Synopsys. In this driver implementation only DMA_MEMCPY transfers are supported. Signed-off-by: Eugeniy Paltsev Signed-off-by: Vinod Koul MAINTAINERS|6 + drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/dw-axi-dmac/Makefile |1 + drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 1008 drivers/dma/dw-axi-dmac/dw-axi-dmac.h | 334 6 files changed, 1360 insertions(+) No commit with drivers/dma/dwi-axi-dmac/ found
Bad MAINTAINERS pattern in section 'Texas Instruments' System Control Interface (TISCI) Protocol Driver'
Please fix this defect appropriately.
linux-next MAINTAINERS section:
14531 Texas Instruments' System Control Interface (TISCI) Protocol
Driver
14532 M: Nishanth Menon
14533 M: Tero Kristo
14534 M: Santosh Shilimkar
14535 L: linux-arm-ker...@lists.infradead.org
14536 S: Maintained
14537 F:
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
14538 F: drivers/firmware/ti_sci*
14539 F: include/linux/soc/ti/ti_sci_protocol.h
14540 F:
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
--> 14541 F: include/dt-bindings/genpd/k2g.h
14542 F: drivers/soc/ti/ti_sci_pm_domains.c
14543 F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
14544 F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
14545 F: drivers/clk/keystone/sci-clk.c
14546 F: drivers/reset/reset-ti-sci.c
Commit that introduced this:
commit 7cc119f29b197f967161ca94c9d5cb5073b4b52b
Author: Dave Gerlach
Date: Tue Apr 4 08:59:27 2017 -0700
dt-bindings: Add TI SCI PM Domains
Add a generic power domain implementation, TI SCI PM Domains, that
will hook into the genpd framework and allow the TI SCI protocol to
control device power states.
Also, provide macros representing each device index as understood
by TI SCI to be used in the device node power-domain references.
These are identifiers for the K2G devices managed by the PMMC.
Acked-by: Santosh Shilimkar
Reviewed-by: Ulf Hansson
Acked-by: Rob Herring
Signed-off-by: Nishanth Menon
Signed-off-by: Dave Gerlach
Signed-off-by: Santosh Shilimkar
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 57 ++
MAINTAINERS| 2 +
include/dt-bindings/genpd/k2g.h| 90 ++
3 files changed, 149 insertions(+)
Last commit with include/dt-bindings/genpd/k2g.h
commit d16645054d2f55e4011c9725ddf2dbe6177e942a
Author: Dave Gerlach
Date: Fri Jul 21 09:38:36 2017 -0700
dt-bindings: Drop k2g genpd device ID macros
Commit 7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains") introduced a
number of K2G_DEV_x macros to represent each device ID available on the
K2G platform for use by the genpd, clock, and reset drivers. Rather than
use these macros, which are only used in the device tree for property
values and not actually used by the drivers, let's just use the device
ID number directly in the device tree to avoid macro bloat.
Acked-by: Rob Herring
Signed-off-by: Dave Gerlach
Signed-off-by: Santosh Shilimkar
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 5 +-
include/dt-bindings/genpd/k2g.h| 90 --
2 files changed, 3 insertions(+), 92 deletions(-)
[PATCH RESEND] net: phy: Convert to using %pOFn instead of device_node.name
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Andrew Lunn
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Reviewed-by: Florian Fainelli
Signed-off-by: Rob Herring
---
David, Resending because you superseded this one for some reason. It
shouldn't be. Perhaps because the subject was similar to others?
Rob
drivers/net/phy/mdio-thunder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio-thunder.c b/drivers/net/phy/mdio-thunder.c
index 564616968cad..1546f6398831 100644
--- a/drivers/net/phy/mdio-thunder.c
+++ b/drivers/net/phy/mdio-thunder.c
@@ -73,8 +73,8 @@ static int thunder_mdiobus_pci_probe(struct pci_dev *pdev,
err = of_address_to_resource(node, 0, );
if (err) {
dev_err(>dev,
- "Couldn't translate address for \"%s\"\n",
- node->name);
+ "Couldn't translate address for \"%pOFn\"\n",
+ node);
break;
}
--
2.17.1
Bad MAINTAINERS pattern in section 'SYNOPSYS DESIGNWARE AXI DMAC DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 14171 SYNOPSYS DESIGNWARE AXI DMAC DRIVER 14172 M: Eugeniy Paltsev 14173 S: Maintained --> 14174 F: drivers/dma/dwi-axi-dmac/ 14175 F: Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt Commit that introduced this: commit 1fe20f1b84548bbcf48b6659ea171cd46618ea3a Author: Eugeniy Paltsev Date: Tue Mar 6 14:46:14 2018 +0300 dmaengine: Introduce DW AXI DMAC driver This patch adds support for the DW AXI DMAC controller. DW AXI DMAC is a part of HSDK development board from Synopsys. In this driver implementation only DMA_MEMCPY transfers are supported. Signed-off-by: Eugeniy Paltsev Signed-off-by: Vinod Koul MAINTAINERS|6 + drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/dw-axi-dmac/Makefile |1 + drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 1008 drivers/dma/dw-axi-dmac/dw-axi-dmac.h | 334 6 files changed, 1360 insertions(+) No commit with drivers/dma/dwi-axi-dmac/ found
Bad MAINTAINERS pattern in section 'Texas Instruments' System Control Interface (TISCI) Protocol Driver'
Please fix this defect appropriately.
linux-next MAINTAINERS section:
14531 Texas Instruments' System Control Interface (TISCI) Protocol
Driver
14532 M: Nishanth Menon
14533 M: Tero Kristo
14534 M: Santosh Shilimkar
14535 L: linux-arm-ker...@lists.infradead.org
14536 S: Maintained
14537 F:
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
14538 F: drivers/firmware/ti_sci*
14539 F: include/linux/soc/ti/ti_sci_protocol.h
14540 F:
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
--> 14541 F: include/dt-bindings/genpd/k2g.h
14542 F: drivers/soc/ti/ti_sci_pm_domains.c
14543 F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
14544 F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
14545 F: drivers/clk/keystone/sci-clk.c
14546 F: drivers/reset/reset-ti-sci.c
Commit that introduced this:
commit 7cc119f29b197f967161ca94c9d5cb5073b4b52b
Author: Dave Gerlach
Date: Tue Apr 4 08:59:27 2017 -0700
dt-bindings: Add TI SCI PM Domains
Add a generic power domain implementation, TI SCI PM Domains, that
will hook into the genpd framework and allow the TI SCI protocol to
control device power states.
Also, provide macros representing each device index as understood
by TI SCI to be used in the device node power-domain references.
These are identifiers for the K2G devices managed by the PMMC.
Acked-by: Santosh Shilimkar
Reviewed-by: Ulf Hansson
Acked-by: Rob Herring
Signed-off-by: Nishanth Menon
Signed-off-by: Dave Gerlach
Signed-off-by: Santosh Shilimkar
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 57 ++
MAINTAINERS| 2 +
include/dt-bindings/genpd/k2g.h| 90 ++
3 files changed, 149 insertions(+)
Last commit with include/dt-bindings/genpd/k2g.h
commit d16645054d2f55e4011c9725ddf2dbe6177e942a
Author: Dave Gerlach
Date: Fri Jul 21 09:38:36 2017 -0700
dt-bindings: Drop k2g genpd device ID macros
Commit 7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains") introduced a
number of K2G_DEV_x macros to represent each device ID available on the
K2G platform for use by the genpd, clock, and reset drivers. Rather than
use these macros, which are only used in the device tree for property
values and not actually used by the drivers, let's just use the device
ID number directly in the device tree to avoid macro bloat.
Acked-by: Rob Herring
Signed-off-by: Dave Gerlach
Signed-off-by: Santosh Shilimkar
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 5 +-
include/dt-bindings/genpd/k2g.h| 90 --
2 files changed, 3 insertions(+), 92 deletions(-)
[PATCH RESEND] net: phy: Convert to using %pOFn instead of device_node.name
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Andrew Lunn
Cc: "David S. Miller"
Cc: net...@vger.kernel.org
Reviewed-by: Florian Fainelli
Signed-off-by: Rob Herring
---
David, Resending because you superseded this one for some reason. It
shouldn't be. Perhaps because the subject was similar to others?
Rob
drivers/net/phy/mdio-thunder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio-thunder.c b/drivers/net/phy/mdio-thunder.c
index 564616968cad..1546f6398831 100644
--- a/drivers/net/phy/mdio-thunder.c
+++ b/drivers/net/phy/mdio-thunder.c
@@ -73,8 +73,8 @@ static int thunder_mdiobus_pci_probe(struct pci_dev *pdev,
err = of_address_to_resource(node, 0, );
if (err) {
dev_err(>dev,
- "Couldn't translate address for \"%s\"\n",
- node->name);
+ "Couldn't translate address for \"%pOFn\"\n",
+ node);
break;
}
--
2.17.1
Bad MAINTAINERS pattern in section 'USER-MODE LINUX (UML)'
Please fix this defect appropriately. linux-next MAINTAINERS section: 15491 USER-MODE LINUX (UML) 15492 M: Jeff Dike 15493 M: Richard Weinberger 15494 L: linux...@lists.infradead.org 15495 W: http://user-mode-linux.sourceforge.net 15496 T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git 15497 S: Maintained 15498 F: Documentation/virtual/uml/ 15499 F: arch/um/ 15500 F: arch/x86/um/ 15501 F: fs/hostfs/ --> 15502 F: fs/hppfs/ Commit that introduced this: commit 679655daffdd2725b66ba2c5a759bbcb316fca5a Author: Joe Perches Date: Tue Apr 7 20:44:32 2009 -0700 MAINTAINERS - Add file patterns Better description of file pattern tag "F:" Add file exclusion tag "X:" Add patterns to sections Signed-off-by: Joe Perches MAINTAINERS | 1194 ++- 1 file changed, 1193 insertions(+), 1 deletion(-) Last commit with fs/hppfs/ commit f74a14e870c80d6261afed66d4bad779c1213e03 Author: Richard Weinberger Date: Tue Apr 21 20:52:26 2015 +0200 um: Remove hppfs hppfs (honeypot procfs) was an attempt to use UML as honeypot. It was never stable nor in heavy use. As Al Viro and Christoph Hellwig pointed some major issues out it is better to let it die. Signed-off-by: Richard Weinberger arch/um/Kconfig.um | 15 -- fs/Makefile| 1 - fs/hppfs/Makefile | 6 - fs/hppfs/hppfs.c | 766 - 4 files changed, 788 deletions(-)
Bad MAINTAINERS pattern in section 'USER-MODE LINUX (UML)'
Please fix this defect appropriately. linux-next MAINTAINERS section: 15491 USER-MODE LINUX (UML) 15492 M: Jeff Dike 15493 M: Richard Weinberger 15494 L: linux...@lists.infradead.org 15495 W: http://user-mode-linux.sourceforge.net 15496 T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git 15497 S: Maintained 15498 F: Documentation/virtual/uml/ 15499 F: arch/um/ 15500 F: arch/x86/um/ 15501 F: fs/hostfs/ --> 15502 F: fs/hppfs/ Commit that introduced this: commit 679655daffdd2725b66ba2c5a759bbcb316fca5a Author: Joe Perches Date: Tue Apr 7 20:44:32 2009 -0700 MAINTAINERS - Add file patterns Better description of file pattern tag "F:" Add file exclusion tag "X:" Add patterns to sections Signed-off-by: Joe Perches MAINTAINERS | 1194 ++- 1 file changed, 1193 insertions(+), 1 deletion(-) Last commit with fs/hppfs/ commit f74a14e870c80d6261afed66d4bad779c1213e03 Author: Richard Weinberger Date: Tue Apr 21 20:52:26 2015 +0200 um: Remove hppfs hppfs (honeypot procfs) was an attempt to use UML as honeypot. It was never stable nor in heavy use. As Al Viro and Christoph Hellwig pointed some major issues out it is better to let it die. Signed-off-by: Richard Weinberger arch/um/Kconfig.um | 15 -- fs/Makefile| 1 - fs/hppfs/Makefile | 6 - fs/hppfs/hppfs.c | 766 - 4 files changed, 788 deletions(-)
Bad MAINTAINERS pattern in section 'STI CEC DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 13992 STI CEC DRIVER 13993 M: Benjamin Gaignard 13994 S: Maintained --> 13995 F: drivers/staging/media/st-cec/ 13996 F: Documentation/devicetree/bindings/media/stih-cec.txt Commit that introduced this: commit 82abbea734d659b4218ad06734b4927b43261985 Author: Randy Dunlap Date: Fri Jul 21 13:32:27 2017 -0700 MAINTAINERS: fix alphabetical ordering Fix major alphabetic errors. No attempt to fix items that all begin with the same word (like ARM, BROADCOM, DRM, EDAC, FREESCALE, INTEL, OMAP, PCI, SAMSUNG, TI, USB, etc.). (diffstat +/- is different by one line because TI KEYSTONE MULTICORE had 2 blank lines after it.) Signed-off-by: Randy Dunlap Acked-by: Andrew Morton Signed-off-by: Linus Torvalds MAINTAINERS | 1683 +-- 1 file changed, 841 insertions(+), 842 deletions(-) Last commit with drivers/staging/media/st-cec/ commit fc4e009c6c986a8cc717dc070d65ccb60d7de91a Author: Benjamin Gaignard Date: Tue Jan 3 12:54:56 2017 -0200 [media] stih-cec: add CEC notifier support By using the CEC notifier framework there is no longer any reason to manually set the physical address. This was the one blocking issue that prevented this driver from going out of staging, so do this move as well. Signed-off-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab drivers/media/platform/Kconfig | 18 + drivers/media/platform/Makefile| 1 + .../st-cec => media/platform/sti/cec}/Makefile | 0 .../st-cec => media/platform/sti/cec}/stih-cec.c | 31 +++--- drivers/staging/media/Kconfig | 2 -- drivers/staging/media/Makefile | 1 - drivers/staging/media/st-cec/Kconfig | 8 -- drivers/staging/media/st-cec/TODO | 7 - 8 files changed, 47 insertions(+), 21 deletions(-)
Bad MAINTAINERS pattern in section 'STAGING - FLARION FT1000 DRIVERS'
Please fix this defect appropriately. linux-next MAINTAINERS section: 13899 STAGING - FLARION FT1000 DRIVERS 13900 M: Marek Belisko 13901 S: Odd Fixes --> 13902 F: drivers/staging/ft1000/ Commit that introduced this: commit a0138163cfbfdfbdc20e4477c77bd7046bd66bb4 Author: Joe Perches Date: Tue Jul 5 15:21:34 2011 -0700 MAINTAINERS: Add remaining staging entries Add the staging entries from various TODO files to MAINTAINERS. Add a few web links as well. Miscellaneous staging typo section header fix. Signed-off-by: Joe Perches Signed-off-by: Greg Kroah-Hartman MAINTAINERS | 69 - 1 file changed, 68 insertions(+), 1 deletion(-) Last commit with drivers/staging/ft1000/ commit 6512edec48b2ccfe9bb969ce26ebbbcd49de6c4b Author: Deepa Dinamani Date: Wed Oct 21 18:42:37 2015 -0700 staging: ft1000: remove obsolete driver Remove support for Qleadtek Flash-OFDM modems. Telecom carrier is discontinuing service for the radio technology. See http://www.gtigroup.org/news/ind/2015-08-18/6996.html. Suggested-by: Arnd Bergmann Signed-off-by: Deepa Dinamani Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman drivers/staging/Kconfig|2 - drivers/staging/Makefile |1 - drivers/staging/ft1000/Kconfig | 22 - drivers/staging/ft1000/Makefile|3 - drivers/staging/ft1000/TODO|9 - drivers/staging/ft1000/ft1000-pcmcia/Makefile |2 - drivers/staging/ft1000/ft1000-pcmcia/boot.h| 158 -- drivers/staging/ft1000/ft1000-pcmcia/ft1000.h | 70 - drivers/staging/ft1000/ft1000-pcmcia/ft1000.img| Bin 305770 -> 0 bytes drivers/staging/ft1000/ft1000-pcmcia/ft1000_cs.c | 158 -- drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c | 762 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 2068 drivers/staging/ft1000/ft1000-usb/Makefile |3 - drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 789 .../staging/ft1000/ft1000-usb/ft1000_download.c| 1058 -- drivers/staging/ft1000/ft1000-usb/ft1000_hw.c | 1586 --- drivers/staging/ft1000/ft1000-usb/ft1000_ioctl.h | 123 -- drivers/staging/ft1000/ft1000-usb/ft1000_usb.c | 248 --- drivers/staging/ft1000/ft1000-usb/ft1000_usb.h | 150 -- drivers/staging/ft1000/ft1000-usb/ft3000.img | Bin 280414 -> 0 bytes drivers/staging/ft1000/ft1000.h| 366 21 files changed, 7578 deletions(-)
Re: Bad MAINTAINERS pattern in section 'ARM/NUVOTON NPCM ARCHITECTURE'
On Fri, Sep 28, 2018 at 2:51 PM Joe Perches wrote: > > Please fix this defect appropriately. > > linux-next MAINTAINERS section: > > 1781ARM/NUVOTON NPCM ARCHITECTURE > 1782M: Avi Fishman > 1783M: Tomer Maimon > 1784R: Patrick Venture > 1785R: Nancy Yuen > 1786R: Brendan Higgins > 1787L: open...@lists.ozlabs.org (moderated for > non-subscribers) > 1788S: Supported > 1789F: arch/arm/mach-npcm/ > 1790F: arch/arm/boot/dts/nuvoton-npcm* > --> 1791F: include/dt-bindings/clock/nuvoton,npcm7xx-clks.h > 1792F: drivers/*/*npcm* > 1793F: Documentation/devicetree/bindings/*/*npcm* > 1794F: Documentation/devicetree/bindings/*/*/*npcm* > > Commit that introduced this: > > commit 6a498e06ba22872d3a27cc0dae77b9314b1de48b > Author: Brendan Higgins > Date: Thu Aug 17 09:44:32 2017 -0700 > > MAINTAINERS: Add entry for the Nuvoton NPCM architecture > > Add maintainers and reviewers for the Nuvoton NPCM architecture. > > Signed-off-by: Brendan Higgins > Reviewed-by: Tomer Maimon > Reviewed-by: Avi Fishman > Signed-off-by: Arnd Bergmann > > MAINTAINERS | 14 ++ > 1 file changed, 14 insertions(+) > > No commit with include/dt-bindings/clock/nuvoton,npcm7xx-clks.h found Ah, looks like it should actually be include/dt-bindings/clock/nuvoton,npcm7xx-clock.h. We probably changed it in one of the revisions and forgot to update it. >
Bad MAINTAINERS pattern in section 'STI CEC DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 13992 STI CEC DRIVER 13993 M: Benjamin Gaignard 13994 S: Maintained --> 13995 F: drivers/staging/media/st-cec/ 13996 F: Documentation/devicetree/bindings/media/stih-cec.txt Commit that introduced this: commit 82abbea734d659b4218ad06734b4927b43261985 Author: Randy Dunlap Date: Fri Jul 21 13:32:27 2017 -0700 MAINTAINERS: fix alphabetical ordering Fix major alphabetic errors. No attempt to fix items that all begin with the same word (like ARM, BROADCOM, DRM, EDAC, FREESCALE, INTEL, OMAP, PCI, SAMSUNG, TI, USB, etc.). (diffstat +/- is different by one line because TI KEYSTONE MULTICORE had 2 blank lines after it.) Signed-off-by: Randy Dunlap Acked-by: Andrew Morton Signed-off-by: Linus Torvalds MAINTAINERS | 1683 +-- 1 file changed, 841 insertions(+), 842 deletions(-) Last commit with drivers/staging/media/st-cec/ commit fc4e009c6c986a8cc717dc070d65ccb60d7de91a Author: Benjamin Gaignard Date: Tue Jan 3 12:54:56 2017 -0200 [media] stih-cec: add CEC notifier support By using the CEC notifier framework there is no longer any reason to manually set the physical address. This was the one blocking issue that prevented this driver from going out of staging, so do this move as well. Signed-off-by: Benjamin Gaignard Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab drivers/media/platform/Kconfig | 18 + drivers/media/platform/Makefile| 1 + .../st-cec => media/platform/sti/cec}/Makefile | 0 .../st-cec => media/platform/sti/cec}/stih-cec.c | 31 +++--- drivers/staging/media/Kconfig | 2 -- drivers/staging/media/Makefile | 1 - drivers/staging/media/st-cec/Kconfig | 8 -- drivers/staging/media/st-cec/TODO | 7 - 8 files changed, 47 insertions(+), 21 deletions(-)
Bad MAINTAINERS pattern in section 'STAGING - FLARION FT1000 DRIVERS'
Please fix this defect appropriately. linux-next MAINTAINERS section: 13899 STAGING - FLARION FT1000 DRIVERS 13900 M: Marek Belisko 13901 S: Odd Fixes --> 13902 F: drivers/staging/ft1000/ Commit that introduced this: commit a0138163cfbfdfbdc20e4477c77bd7046bd66bb4 Author: Joe Perches Date: Tue Jul 5 15:21:34 2011 -0700 MAINTAINERS: Add remaining staging entries Add the staging entries from various TODO files to MAINTAINERS. Add a few web links as well. Miscellaneous staging typo section header fix. Signed-off-by: Joe Perches Signed-off-by: Greg Kroah-Hartman MAINTAINERS | 69 - 1 file changed, 68 insertions(+), 1 deletion(-) Last commit with drivers/staging/ft1000/ commit 6512edec48b2ccfe9bb969ce26ebbbcd49de6c4b Author: Deepa Dinamani Date: Wed Oct 21 18:42:37 2015 -0700 staging: ft1000: remove obsolete driver Remove support for Qleadtek Flash-OFDM modems. Telecom carrier is discontinuing service for the radio technology. See http://www.gtigroup.org/news/ind/2015-08-18/6996.html. Suggested-by: Arnd Bergmann Signed-off-by: Deepa Dinamani Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman drivers/staging/Kconfig|2 - drivers/staging/Makefile |1 - drivers/staging/ft1000/Kconfig | 22 - drivers/staging/ft1000/Makefile|3 - drivers/staging/ft1000/TODO|9 - drivers/staging/ft1000/ft1000-pcmcia/Makefile |2 - drivers/staging/ft1000/ft1000-pcmcia/boot.h| 158 -- drivers/staging/ft1000/ft1000-pcmcia/ft1000.h | 70 - drivers/staging/ft1000/ft1000-pcmcia/ft1000.img| Bin 305770 -> 0 bytes drivers/staging/ft1000/ft1000-pcmcia/ft1000_cs.c | 158 -- drivers/staging/ft1000/ft1000-pcmcia/ft1000_dnld.c | 762 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 2068 drivers/staging/ft1000/ft1000-usb/Makefile |3 - drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 789 .../staging/ft1000/ft1000-usb/ft1000_download.c| 1058 -- drivers/staging/ft1000/ft1000-usb/ft1000_hw.c | 1586 --- drivers/staging/ft1000/ft1000-usb/ft1000_ioctl.h | 123 -- drivers/staging/ft1000/ft1000-usb/ft1000_usb.c | 248 --- drivers/staging/ft1000/ft1000-usb/ft1000_usb.h | 150 -- drivers/staging/ft1000/ft1000-usb/ft3000.img | Bin 280414 -> 0 bytes drivers/staging/ft1000/ft1000.h| 366 21 files changed, 7578 deletions(-)
Re: Bad MAINTAINERS pattern in section 'ARM/NUVOTON NPCM ARCHITECTURE'
On Fri, Sep 28, 2018 at 2:51 PM Joe Perches wrote: > > Please fix this defect appropriately. > > linux-next MAINTAINERS section: > > 1781ARM/NUVOTON NPCM ARCHITECTURE > 1782M: Avi Fishman > 1783M: Tomer Maimon > 1784R: Patrick Venture > 1785R: Nancy Yuen > 1786R: Brendan Higgins > 1787L: open...@lists.ozlabs.org (moderated for > non-subscribers) > 1788S: Supported > 1789F: arch/arm/mach-npcm/ > 1790F: arch/arm/boot/dts/nuvoton-npcm* > --> 1791F: include/dt-bindings/clock/nuvoton,npcm7xx-clks.h > 1792F: drivers/*/*npcm* > 1793F: Documentation/devicetree/bindings/*/*npcm* > 1794F: Documentation/devicetree/bindings/*/*/*npcm* > > Commit that introduced this: > > commit 6a498e06ba22872d3a27cc0dae77b9314b1de48b > Author: Brendan Higgins > Date: Thu Aug 17 09:44:32 2017 -0700 > > MAINTAINERS: Add entry for the Nuvoton NPCM architecture > > Add maintainers and reviewers for the Nuvoton NPCM architecture. > > Signed-off-by: Brendan Higgins > Reviewed-by: Tomer Maimon > Reviewed-by: Avi Fishman > Signed-off-by: Arnd Bergmann > > MAINTAINERS | 14 ++ > 1 file changed, 14 insertions(+) > > No commit with include/dt-bindings/clock/nuvoton,npcm7xx-clks.h found Ah, looks like it should actually be include/dt-bindings/clock/nuvoton,npcm7xx-clock.h. We probably changed it in one of the revisions and forgot to update it. >
Bad MAINTAINERS pattern in section 'SOFTWARE DELEGATED EXCEPTION INTERFACE (SDEI)'
Please fix this defect appropriately. linux-next MAINTAINERS section: 13609 SOFTWARE DELEGATED EXCEPTION INTERFACE (SDEI) 13610 M: James Morse 13611 L: linux-arm-ker...@lists.infradead.org 13612 S: Maintained 13613 F: Documentation/devicetree/bindings/arm/firmware/sdei.txt 13614 F: drivers/firmware/arm_sdei.c 13615 F: include/linux/sdei.h --> 13616 F: include/uapi/linux/sdei.h Commit that introduced this: commit ad6eb31ef90355993eb55ff77e0e855ae7d91e4c Author: James Morse Date: Mon Jan 8 15:38:09 2018 + firmware: arm_sdei: Add driver for Software Delegated Exceptions The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement firmware notifications (such as firmware-first RAS) or promote an IRQ that has been promoted to a firmware-assisted NMI. Add the code for detecting the SDEI version and the framework for registering and unregistering events. Subsequent patches will add the arch-specific backend code and the necessary power management hooks. Only shared events are supported, power management, private events and discovery for ACPI systems will be added by later patches. Signed-off-by: James Morse Signed-off-by: Catalin Marinas MAINTAINERS | 9 + arch/arm64/include/asm/sdei.h | 8 + drivers/firmware/Kconfig | 8 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_sdei.c | 619 ++ include/linux/arm_sdei.h | 79 ++ include/uapi/linux/arm_sdei.h | 73 + 7 files changed, 797 insertions(+) No commit with include/uapi/linux/sdei.h found
Bad MAINTAINERS pattern in section 'SOFTWARE DELEGATED EXCEPTION INTERFACE (SDEI)'
Please fix this defect appropriately. linux-next MAINTAINERS section: 13609 SOFTWARE DELEGATED EXCEPTION INTERFACE (SDEI) 13610 M: James Morse 13611 L: linux-arm-ker...@lists.infradead.org 13612 S: Maintained 13613 F: Documentation/devicetree/bindings/arm/firmware/sdei.txt 13614 F: drivers/firmware/arm_sdei.c 13615 F: include/linux/sdei.h --> 13616 F: include/uapi/linux/sdei.h Commit that introduced this: commit ad6eb31ef90355993eb55ff77e0e855ae7d91e4c Author: James Morse Date: Mon Jan 8 15:38:09 2018 + firmware: arm_sdei: Add driver for Software Delegated Exceptions The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement firmware notifications (such as firmware-first RAS) or promote an IRQ that has been promoted to a firmware-assisted NMI. Add the code for detecting the SDEI version and the framework for registering and unregistering events. Subsequent patches will add the arch-specific backend code and the necessary power management hooks. Only shared events are supported, power management, private events and discovery for ACPI systems will be added by later patches. Signed-off-by: James Morse Signed-off-by: Catalin Marinas MAINTAINERS | 9 + arch/arm64/include/asm/sdei.h | 8 + drivers/firmware/Kconfig | 8 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_sdei.c | 619 ++ include/linux/arm_sdei.h | 79 ++ include/uapi/linux/arm_sdei.h | 73 + 7 files changed, 797 insertions(+) No commit with include/uapi/linux/sdei.h found
Bad MAINTAINERS pattern in section 'SOFTWARE DELEGATED EXCEPTION INTERFACE (SDEI)'
Please fix this defect appropriately. linux-next MAINTAINERS section: 13609 SOFTWARE DELEGATED EXCEPTION INTERFACE (SDEI) 13610 M: James Morse 13611 L: linux-arm-ker...@lists.infradead.org 13612 S: Maintained 13613 F: Documentation/devicetree/bindings/arm/firmware/sdei.txt 13614 F: drivers/firmware/arm_sdei.c --> 13615 F: include/linux/sdei.h 13616 F: include/uapi/linux/sdei.h Commit that introduced this: commit ad6eb31ef90355993eb55ff77e0e855ae7d91e4c Author: James Morse Date: Mon Jan 8 15:38:09 2018 + firmware: arm_sdei: Add driver for Software Delegated Exceptions The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement firmware notifications (such as firmware-first RAS) or promote an IRQ that has been promoted to a firmware-assisted NMI. Add the code for detecting the SDEI version and the framework for registering and unregistering events. Subsequent patches will add the arch-specific backend code and the necessary power management hooks. Only shared events are supported, power management, private events and discovery for ACPI systems will be added by later patches. Signed-off-by: James Morse Signed-off-by: Catalin Marinas MAINTAINERS | 9 + arch/arm64/include/asm/sdei.h | 8 + drivers/firmware/Kconfig | 8 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_sdei.c | 619 ++ include/linux/arm_sdei.h | 79 ++ include/uapi/linux/arm_sdei.h | 73 + 7 files changed, 797 insertions(+) No commit with include/linux/sdei.h found
Re: [PATCH v7 0/6] seccomp trap to userspace
On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) wrote: > Hi Tycho, > > On 09/27/2018 05:11 PM, Tycho Andersen wrote: > > Hi all, > > > > Here's v7 of the seccomp trap to userspace set. There are various minor > > changes and bug fixes, but two major changes: > > > > * We now pass fds to the tracee via an ioctl, and do it immediately when > >the ioctl is called. For this we needed some help from the vfs, so > >I've put the one patch in this series and cc'd fsdevel. This does have > >the advantage that the feature is now totally decoupled from the rest > >of the set, which is itself useful (thanks Andy!) > > > > * Instead of putting all of the notification related stuff into the > >struct seccomp_filter, it now lives in its own struct notification, > >which is pointed to by struct seccomp_filter. This will save a lot of > >memory (thanks Tyler!) > > Is there a documentation (man page) patch for this API change? Not yet, but once we decide on a final API I'll prepare one. Cheers, Tycho
Bad MAINTAINERS pattern in section 'SOFTWARE DELEGATED EXCEPTION INTERFACE (SDEI)'
Please fix this defect appropriately. linux-next MAINTAINERS section: 13609 SOFTWARE DELEGATED EXCEPTION INTERFACE (SDEI) 13610 M: James Morse 13611 L: linux-arm-ker...@lists.infradead.org 13612 S: Maintained 13613 F: Documentation/devicetree/bindings/arm/firmware/sdei.txt 13614 F: drivers/firmware/arm_sdei.c --> 13615 F: include/linux/sdei.h 13616 F: include/uapi/linux/sdei.h Commit that introduced this: commit ad6eb31ef90355993eb55ff77e0e855ae7d91e4c Author: James Morse Date: Mon Jan 8 15:38:09 2018 + firmware: arm_sdei: Add driver for Software Delegated Exceptions The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement firmware notifications (such as firmware-first RAS) or promote an IRQ that has been promoted to a firmware-assisted NMI. Add the code for detecting the SDEI version and the framework for registering and unregistering events. Subsequent patches will add the arch-specific backend code and the necessary power management hooks. Only shared events are supported, power management, private events and discovery for ACPI systems will be added by later patches. Signed-off-by: James Morse Signed-off-by: Catalin Marinas MAINTAINERS | 9 + arch/arm64/include/asm/sdei.h | 8 + drivers/firmware/Kconfig | 8 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_sdei.c | 619 ++ include/linux/arm_sdei.h | 79 ++ include/uapi/linux/arm_sdei.h | 73 + 7 files changed, 797 insertions(+) No commit with include/linux/sdei.h found
Re: [PATCH v7 0/6] seccomp trap to userspace
On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) wrote: > Hi Tycho, > > On 09/27/2018 05:11 PM, Tycho Andersen wrote: > > Hi all, > > > > Here's v7 of the seccomp trap to userspace set. There are various minor > > changes and bug fixes, but two major changes: > > > > * We now pass fds to the tracee via an ioctl, and do it immediately when > >the ioctl is called. For this we needed some help from the vfs, so > >I've put the one patch in this series and cc'd fsdevel. This does have > >the advantage that the feature is now totally decoupled from the rest > >of the set, which is itself useful (thanks Andy!) > > > > * Instead of putting all of the notification related stuff into the > >struct seccomp_filter, it now lives in its own struct notification, > >which is pointed to by struct seccomp_filter. This will save a lot of > >memory (thanks Tyler!) > > Is there a documentation (man page) patch for this API change? Not yet, but once we decide on a final API I'll prepare one. Cheers, Tycho
Re: [RFC/RFT PATCH v1 0/9] mtd: fsl: quadspi: Fixes for fsl-quadspi.c driver (vybrid HW)
Hi Lukasz, On Thu, 27 Sep 2018 00:07:30 +0200 Lukasz Majewski wrote: > Please find following set of patches, which provide improved behaviour > of the fsl-quadspi.c driver on Vybrid vf610 HW. > > Below code is based on previous work done by Albert ARIBAUD: > https://patchwork.ozlabs.org/patch/675401/ > > I've cleaned up the code a bit, make separate patches, exclude not > needed parts and port it to v4.19-rc3. > > After applying those patches, the quadspi controller on vf610 works > with UBI/UBIFS. > The problem is with some corner case writes to raw MTD device > (like writing 1023B with single byte writes). Those fail sometimes. > > Regression tests can be found in the following repository: > https://github.com/lmajewski/tests-spi/tree/master/tests > > (Please read README.txt). > > The NXP's community thread regarding HW issues in this block on > the vf610: > https://community.nxp.com/thread/485139 > > Maybe those patches will be helpful with the new, work in progress > driver for spi-fsl-qspi.c Talking about that, can you try to port your fixes on top of Frieder's patchset? I'm pretty sure some bug fixes are irrelevant after the migration to spi-mem (patch 1, 3, 4, 5, 6, 7 and 9 should be dropped I think). > > Lukasz Majewski (9): > Revert "mtd: fsl-quadspi: Rename SEQID_QUAD_READ to SEQID_READ" > mtd: qspi: Provide quirk to read only half of RX buffer (NXP's vybrid) > mtd: spi: Do not setup the default seqid as we got it set for DUAL and > QUAD > mtd: spi: Modify the HW capability mask according to supported RX > lanes > mtd: spi: Provide LUT entry to perform DUAL read > mtd: spi: Enhance the fsl_qspi_read() method to support DUAL and QUAD > mtd: spi: Add SPI_NOR_DUAL_READ property for the 'n25q128a13' Micron > memory > mtd: spi: Allocate memory corresponding to maximal fsl-quadspi.c > controller area > mtd: spi: Skip reading the Serial Flash Discoverable Parameters
Re: [RFC/RFT PATCH v1 0/9] mtd: fsl: quadspi: Fixes for fsl-quadspi.c driver (vybrid HW)
Hi Lukasz, On Thu, 27 Sep 2018 00:07:30 +0200 Lukasz Majewski wrote: > Please find following set of patches, which provide improved behaviour > of the fsl-quadspi.c driver on Vybrid vf610 HW. > > Below code is based on previous work done by Albert ARIBAUD: > https://patchwork.ozlabs.org/patch/675401/ > > I've cleaned up the code a bit, make separate patches, exclude not > needed parts and port it to v4.19-rc3. > > After applying those patches, the quadspi controller on vf610 works > with UBI/UBIFS. > The problem is with some corner case writes to raw MTD device > (like writing 1023B with single byte writes). Those fail sometimes. > > Regression tests can be found in the following repository: > https://github.com/lmajewski/tests-spi/tree/master/tests > > (Please read README.txt). > > The NXP's community thread regarding HW issues in this block on > the vf610: > https://community.nxp.com/thread/485139 > > Maybe those patches will be helpful with the new, work in progress > driver for spi-fsl-qspi.c Talking about that, can you try to port your fixes on top of Frieder's patchset? I'm pretty sure some bug fixes are irrelevant after the migration to spi-mem (patch 1, 3, 4, 5, 6, 7 and 9 should be dropped I think). > > Lukasz Majewski (9): > Revert "mtd: fsl-quadspi: Rename SEQID_QUAD_READ to SEQID_READ" > mtd: qspi: Provide quirk to read only half of RX buffer (NXP's vybrid) > mtd: spi: Do not setup the default seqid as we got it set for DUAL and > QUAD > mtd: spi: Modify the HW capability mask according to supported RX > lanes > mtd: spi: Provide LUT entry to perform DUAL read > mtd: spi: Enhance the fsl_qspi_read() method to support DUAL and QUAD > mtd: spi: Add SPI_NOR_DUAL_READ property for the 'n25q128a13' Micron > memory > mtd: spi: Allocate memory corresponding to maximal fsl-quadspi.c > controller area > mtd: spi: Skip reading the Serial Flash Discoverable Parameters
Bad MAINTAINERS pattern in section 'SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 12851 SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER 12852 M: Łukasz Stelmach 12853 L: linux-samsung-...@vger.kernel.org 12854 S: Maintained 12855 F: drivers/char/hw_random/exynos-trng.c --> 12856 F: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt Commit that introduced this: commit 6cd225cc5d8a6526b2bea41955882be55d4f109e Author: Łukasz Stelmach Date: Fri Dec 22 17:48:35 2017 +0100 hwrng: exynos - add Samsung Exynos True RNG driver Add support for True Random Number Generator found in Samsung Exynos 5250+ SoCs. Signed-off-by: Łukasz Stelmach Reviewed-by: Krzysztof Kozlowski Acked-by: Philippe Ombredanne Signed-off-by: Herbert Xu MAINTAINERS | 7 ++ drivers/char/hw_random/Kconfig | 12 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/exynos-trng.c | 237 +++ 4 files changed, 257 insertions(+) No commit with Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt found
Bad MAINTAINERS pattern in section 'SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 12851 SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER 12852 M: Łukasz Stelmach 12853 L: linux-samsung-...@vger.kernel.org 12854 S: Maintained 12855 F: drivers/char/hw_random/exynos-trng.c --> 12856 F: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt Commit that introduced this: commit 6cd225cc5d8a6526b2bea41955882be55d4f109e Author: Łukasz Stelmach Date: Fri Dec 22 17:48:35 2017 +0100 hwrng: exynos - add Samsung Exynos True RNG driver Add support for True Random Number Generator found in Samsung Exynos 5250+ SoCs. Signed-off-by: Łukasz Stelmach Reviewed-by: Krzysztof Kozlowski Acked-by: Philippe Ombredanne Signed-off-by: Herbert Xu MAINTAINERS | 7 ++ drivers/char/hw_random/Kconfig | 12 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/exynos-trng.c | 237 +++ 4 files changed, 257 insertions(+) No commit with Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt found
Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)
On Fri, Sep 28, 2018 at 5:12 PM Jann Horn wrote: > > On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin > wrote: > > On 28/09/2018 11:26, Thomas Gleixner wrote: > > > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote: > > >> For situations where sysadmins might want to allow different level of > > >> access control for different PMUs, we start creating per-PMU > > >> perf_event_paranoid controls in sysfs. > > >> > > >> These work in equivalent fashion as the existing perf_event_paranoid > > >> sysctl, which now becomes the parent control for each PMU. > > >> > > >> On PMU registration the global/parent value will be inherited by each > > >> PMU, > > >> as it will be propagated to all registered PMUs when the sysctl is > > >> updated. > > >> > > >> At any later point individual PMU access controls, located in > > >> /device//perf_event_paranoid, can be adjusted to achieve > > >> fine grained access control. > > >> > > >> Discussion from previous posting: > > >> https://lkml.org/lkml/2018/5/21/156 > > > > > > This is really not helpful. The cover letter and the change logs should > > > contain a summary of that discussion and a proper justification of the > > > proposed change. Just saying 'sysadmins might want to allow' is not useful > > > at all, it's yet another 'I want a pony' thing. > > > > Okay, for the next round I will expand the cover letter with at least > > one concrete example on how it is usable and summarize the discussion a bit. > > > > > I read through the previous thread and there was a clear request to > > > involve > > > security people into this. Especially those who are deeply involved with > > > hardware side channels. I don't see anyone Cc'ed on the whole series. > > > > Who would you recommend I add? Because I really don't know.. > > > > > For the record, I'm not buying the handwavy 'more noise' argument at > > > all. It wants a proper analysis and we need to come up with criteria which > > > PMUs can be exposed at all. > > > > > > All of this want's a proper documentation clearly explaining the risks and > > > scope of these knobs per PMU. Just throwing magic knobs at sysadmins and > > > then saying 'its their problem to figure it out' is not acceptable. > > > > Presumably you see adding fine grained control as diminishing the > > overall security rather than raising it? Could you explain why? Because > > incompetent sysadmin will turn it off for some PMU, while without having > > the fine-grained control they wouldn't turn it off globally? > > > > This feature was requested by the exact opposite concern, that in order > > to access the i915 PMU, one has to compromise the security of the entire > > system by allowing access to *all* PMU's. > > > > Making this ability fine-grained sounds like a logical solution for > > solving this weakening of security controls. > > > > Concrete example was that on video transcoding farms users want to > > monitor the utilization of GPU engines (like CPU cores) and they can do > > that via the i915 PMU. But for that to work today they have to dial down > > the global perf_event_paranoid setting. Obvious improvement was to allow > > them to only dial down the i915.perf_event_paranoid setting. As such, > > for this specific use case at least, the security is increased. > > Which paranoia level would be used for the i915.perf_event_paranoid > setting in such a case? Ah, I guess the answer is "0", since you want to see data about what other users are doing. Does the i915 PMU expose sampling events, counting events, or both? The thing about sampling events is that they AFAIK always let the user pick arbitrary data to collect - like register contents, or userspace stack memory -, and independent of the performance counter being monitored, this kind of access should not be permitted to other contexts. (But it might be that I misunderstand how perf works - I'm not super familiar with its API.)
Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)
On Fri, Sep 28, 2018 at 5:12 PM Jann Horn wrote: > > On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin > wrote: > > On 28/09/2018 11:26, Thomas Gleixner wrote: > > > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote: > > >> For situations where sysadmins might want to allow different level of > > >> access control for different PMUs, we start creating per-PMU > > >> perf_event_paranoid controls in sysfs. > > >> > > >> These work in equivalent fashion as the existing perf_event_paranoid > > >> sysctl, which now becomes the parent control for each PMU. > > >> > > >> On PMU registration the global/parent value will be inherited by each > > >> PMU, > > >> as it will be propagated to all registered PMUs when the sysctl is > > >> updated. > > >> > > >> At any later point individual PMU access controls, located in > > >> /device//perf_event_paranoid, can be adjusted to achieve > > >> fine grained access control. > > >> > > >> Discussion from previous posting: > > >> https://lkml.org/lkml/2018/5/21/156 > > > > > > This is really not helpful. The cover letter and the change logs should > > > contain a summary of that discussion and a proper justification of the > > > proposed change. Just saying 'sysadmins might want to allow' is not useful > > > at all, it's yet another 'I want a pony' thing. > > > > Okay, for the next round I will expand the cover letter with at least > > one concrete example on how it is usable and summarize the discussion a bit. > > > > > I read through the previous thread and there was a clear request to > > > involve > > > security people into this. Especially those who are deeply involved with > > > hardware side channels. I don't see anyone Cc'ed on the whole series. > > > > Who would you recommend I add? Because I really don't know.. > > > > > For the record, I'm not buying the handwavy 'more noise' argument at > > > all. It wants a proper analysis and we need to come up with criteria which > > > PMUs can be exposed at all. > > > > > > All of this want's a proper documentation clearly explaining the risks and > > > scope of these knobs per PMU. Just throwing magic knobs at sysadmins and > > > then saying 'its their problem to figure it out' is not acceptable. > > > > Presumably you see adding fine grained control as diminishing the > > overall security rather than raising it? Could you explain why? Because > > incompetent sysadmin will turn it off for some PMU, while without having > > the fine-grained control they wouldn't turn it off globally? > > > > This feature was requested by the exact opposite concern, that in order > > to access the i915 PMU, one has to compromise the security of the entire > > system by allowing access to *all* PMU's. > > > > Making this ability fine-grained sounds like a logical solution for > > solving this weakening of security controls. > > > > Concrete example was that on video transcoding farms users want to > > monitor the utilization of GPU engines (like CPU cores) and they can do > > that via the i915 PMU. But for that to work today they have to dial down > > the global perf_event_paranoid setting. Obvious improvement was to allow > > them to only dial down the i915.perf_event_paranoid setting. As such, > > for this specific use case at least, the security is increased. > > Which paranoia level would be used for the i915.perf_event_paranoid > setting in such a case? Ah, I guess the answer is "0", since you want to see data about what other users are doing. Does the i915 PMU expose sampling events, counting events, or both? The thing about sampling events is that they AFAIK always let the user pick arbitrary data to collect - like register contents, or userspace stack memory -, and independent of the performance counter being monitored, this kind of access should not be permitted to other contexts. (But it might be that I misunderstand how perf works - I'm not super familiar with its API.)
Re: [PATCH 3/3] seccomp: introduce read protection for struct seccomp
On Fri, Sep 28, 2018 at 11:54:22PM +0200, Jann Horn wrote: > On Fri, Sep 28, 2018 at 11:36 PM Tycho Andersen wrote: > > On Fri, Sep 28, 2018 at 11:10:48PM +0200, Jann Horn wrote: > > > On Fri, Sep 28, 2018 at 10:56 PM Tycho Andersen wrote: > > > > > > > > On Fri, Sep 28, 2018 at 10:33:34PM +0200, Jann Horn wrote: > > > > > On Fri, Sep 28, 2018 at 5:47 PM Tycho Andersen wrote: > > > > > > As Jann pointed out, there is a race between > > > > > > SECCOMP_FILTER_FLAG_TSYNC and > > > > > > the ptrace code that can inspect a filter of another process. Let's > > > > > > introduce read locking into the two ptrace accesses so that we > > > > > > don't race. > > > > > > > > > > Hmm. Is that true? The ptrace code uses get_nth_filter(), which holds > > > > > the siglock while grabbing the seccomp filter and bumping its > > > > > refcount. And TSYNC happens from seccomp_set_mode_filter(), which > > > > > takes the siglock. So this looks okay to me? > > > > > > > > Oh, yes, you're right. So I guess we should just change the comment to > > > > say we're using siglock to represent the read lock. > > > > > > Hmm... actually, looking at this closer, I think you only need the > > > siglock for writing. As far as I can tell, any read (no matter if > > > current or non-current) can just use READ_ONCE(), because once a > > > seccomp filter is in a task's seccomp filter chain, it can't be freed > > > until the task reaches free_task() and calls put_seccomp_filter() from > > > there. And if the task whose seccomp filter you're trying to read can > > > reach free_task(), you have bigger problems. > > > > Ok; looks like get_nth_filter() took the siglock anyway. Since we get > > the filters in these two functions in get_nth_filter(), I think it's > > enough just to just, > > > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > > index f65d47650ac1..79d833ed4c34 100644 > > --- a/kernel/seccomp.c > > +++ b/kernel/seccomp.c > > @@ -1001,7 +1001,7 @@ static struct seccomp_filter *get_nth_filter(struct > > task_struct *task, > > return ERR_PTR(-EINVAL); > > } > > > > - orig = task->seccomp.filter; > > + orig = READ_ONCE(task->seccomp.filter); > > __get_seccomp_filter(orig); > > spin_unlock_irq(>sighand->siglock); > > Huh? Now you're holding the siglock *and* you're using READ_ONCE()? > I'm not sure what you're trying to accomplish here. Yes, let's just drop this patch all together. Tycho
Re: [PATCH 3/3] seccomp: introduce read protection for struct seccomp
On Fri, Sep 28, 2018 at 11:54:22PM +0200, Jann Horn wrote: > On Fri, Sep 28, 2018 at 11:36 PM Tycho Andersen wrote: > > On Fri, Sep 28, 2018 at 11:10:48PM +0200, Jann Horn wrote: > > > On Fri, Sep 28, 2018 at 10:56 PM Tycho Andersen wrote: > > > > > > > > On Fri, Sep 28, 2018 at 10:33:34PM +0200, Jann Horn wrote: > > > > > On Fri, Sep 28, 2018 at 5:47 PM Tycho Andersen wrote: > > > > > > As Jann pointed out, there is a race between > > > > > > SECCOMP_FILTER_FLAG_TSYNC and > > > > > > the ptrace code that can inspect a filter of another process. Let's > > > > > > introduce read locking into the two ptrace accesses so that we > > > > > > don't race. > > > > > > > > > > Hmm. Is that true? The ptrace code uses get_nth_filter(), which holds > > > > > the siglock while grabbing the seccomp filter and bumping its > > > > > refcount. And TSYNC happens from seccomp_set_mode_filter(), which > > > > > takes the siglock. So this looks okay to me? > > > > > > > > Oh, yes, you're right. So I guess we should just change the comment to > > > > say we're using siglock to represent the read lock. > > > > > > Hmm... actually, looking at this closer, I think you only need the > > > siglock for writing. As far as I can tell, any read (no matter if > > > current or non-current) can just use READ_ONCE(), because once a > > > seccomp filter is in a task's seccomp filter chain, it can't be freed > > > until the task reaches free_task() and calls put_seccomp_filter() from > > > there. And if the task whose seccomp filter you're trying to read can > > > reach free_task(), you have bigger problems. > > > > Ok; looks like get_nth_filter() took the siglock anyway. Since we get > > the filters in these two functions in get_nth_filter(), I think it's > > enough just to just, > > > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > > index f65d47650ac1..79d833ed4c34 100644 > > --- a/kernel/seccomp.c > > +++ b/kernel/seccomp.c > > @@ -1001,7 +1001,7 @@ static struct seccomp_filter *get_nth_filter(struct > > task_struct *task, > > return ERR_PTR(-EINVAL); > > } > > > > - orig = task->seccomp.filter; > > + orig = READ_ONCE(task->seccomp.filter); > > __get_seccomp_filter(orig); > > spin_unlock_irq(>sighand->siglock); > > Huh? Now you're holding the siglock *and* you're using READ_ONCE()? > I'm not sure what you're trying to accomplish here. Yes, let's just drop this patch all together. Tycho
Bad MAINTAINERS pattern in section 'RENESAS R-CAR GYROADC DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 12496 RENESAS R-CAR GYROADC DRIVER 12497 M: Marek Vasut 12498 L: linux-...@vger.kernel.org 12499 S: Supported --> 12500 F: drivers/iio/adc/rcar_gyro_adc.c Commit that introduced this: commit 059c53b3232960cfd38cc46de0a7bedd642021f5 Author: Marek Vasut Date: Sat Jan 28 00:08:37 2017 +0100 iio: adc: Add Renesas GyroADC driver Add IIO driver for the Renesas RCar GyroADC block. This block is a simple 4/8-channel ADC which samples 12/15/24 bits of data every cycle from all channels. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Simon Horman Cc: Jonathan Cameron Cc: linux-renesas-...@vger.kernel.org Cc: Wolfram Sang Signed-off-by: Jonathan Cameron MAINTAINERS| 6 + drivers/iio/adc/Kconfig| 13 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/rcar-gyroadc.c | 631 + 4 files changed, 651 insertions(+) No commit with drivers/iio/adc/rcar_gyro_adc.c found
Bad MAINTAINERS pattern in section 'RENESAS R-CAR GYROADC DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 12496 RENESAS R-CAR GYROADC DRIVER 12497 M: Marek Vasut 12498 L: linux-...@vger.kernel.org 12499 S: Supported --> 12500 F: drivers/iio/adc/rcar_gyro_adc.c Commit that introduced this: commit 059c53b3232960cfd38cc46de0a7bedd642021f5 Author: Marek Vasut Date: Sat Jan 28 00:08:37 2017 +0100 iio: adc: Add Renesas GyroADC driver Add IIO driver for the Renesas RCar GyroADC block. This block is a simple 4/8-channel ADC which samples 12/15/24 bits of data every cycle from all channels. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Simon Horman Cc: Jonathan Cameron Cc: linux-renesas-...@vger.kernel.org Cc: Wolfram Sang Signed-off-by: Jonathan Cameron MAINTAINERS| 6 + drivers/iio/adc/Kconfig| 13 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/rcar-gyroadc.c | 631 + 4 files changed, 651 insertions(+) No commit with drivers/iio/adc/rcar_gyro_adc.c found
Bad MAINTAINERS pattern in section 'NCP FILESYSTEM'
Please fix this defect appropriately.
linux-next MAINTAINERS section:
10052 NCP FILESYSTEM
10053 M: Petr Vandrovec
10054 S: Obsolete
--> 10055 F: drivers/staging/ncpfs/
Commit that introduced this:
commit 1bb8155080c652c4853e6228f8f0d262b3049699
Author: Stephen Hemminger
Date: Tue Nov 14 08:37:15 2017 -0800
ncpfs: move net/ncpfs to drivers/staging/ncpfs
The Netware Core Protocol is a file system that talks to
Netware clients over IPX. Since IPX has been dead for many years
move the file system into staging for eventual interment.
Signed-off-by: Stephen Hemminger
Acked-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
MAINTAINERS| 2 +-
drivers/staging/Kconfig| 2 ++
drivers/staging/Makefile | 1 +
{fs => drivers/staging}/ncpfs/Kconfig | 0
{fs => drivers/staging}/ncpfs/Makefile | 0
drivers/staging/ncpfs/TODO | 4
{fs => drivers/staging}/ncpfs/dir.c| 0
{fs => drivers/staging}/ncpfs/file.c | 0
{fs => drivers/staging}/ncpfs/getopt.c | 0
{fs => drivers/staging}/ncpfs/getopt.h | 0
{fs => drivers/staging}/ncpfs/inode.c | 0
{fs => drivers/staging}/ncpfs/ioctl.c | 0
{fs => drivers/staging}/ncpfs/mmap.c | 0
{fs => drivers/staging}/ncpfs/ncp_fs.h | 0
{fs => drivers/staging}/ncpfs/ncp_fs_i.h | 0
{fs => drivers/staging}/ncpfs/ncp_fs_sb.h | 0
{fs => drivers/staging}/ncpfs/ncplib_kernel.c | 0
{fs => drivers/staging}/ncpfs/ncplib_kernel.h | 0
{fs => drivers/staging}/ncpfs/ncpsign_kernel.c | 0
{fs => drivers/staging}/ncpfs/ncpsign_kernel.h | 0
{fs => drivers/staging}/ncpfs/sock.c | 0
{fs => drivers/staging}/ncpfs/symlink.c| 0
fs/Kconfig | 1 -
fs/Makefile| 1 -
24 files changed, 8 insertions(+), 3 deletions(-)
Last commit with drivers/staging/ncpfs/
commit bd32895c750bcd2b511bf93917bf7ae723e3d0b6
Author: Greg Kroah-Hartman
Date: Fri Jun 1 20:23:10 2018 +0200
staging: ncpfs: delete it
The ncpfs code moved into the staging tree back in November 2017 and no
one has complained or even noticed it was gone. Because of that, let's
just delete it.
Cc: Stephen Hemminger
Cc: David S. Miller
Signed-off-by: Greg Kroah-Hartman
drivers/staging/Kconfig|2 -
drivers/staging/Makefile |1 -
drivers/staging/ncpfs/Kconfig | 108 ---
drivers/staging/ncpfs/Makefile | 17 -
drivers/staging/ncpfs/TODO |4 -
drivers/staging/ncpfs/dir.c| 1232 -
drivers/staging/ncpfs/file.c | 263 ---
drivers/staging/ncpfs/getopt.c | 76 --
drivers/staging/ncpfs/getopt.h | 17 -
drivers/staging/ncpfs/inode.c | 1067 -
drivers/staging/ncpfs/ioctl.c | 923 --
drivers/staging/ncpfs/mmap.c | 125 ---
drivers/staging/ncpfs/ncp_fs.h | 101 ---
drivers/staging/ncpfs/ncp_fs_i.h | 31 -
drivers/staging/ncpfs/ncp_fs_sb.h | 174 -
drivers/staging/ncpfs/ncplib_kernel.c | 1326
drivers/staging/ncpfs/ncplib_kernel.h | 215 --
drivers/staging/ncpfs/ncpsign_kernel.c | 128 ---
drivers/staging/ncpfs/ncpsign_kernel.h | 27 -
drivers/staging/ncpfs/sock.c | 855
drivers/staging/ncpfs/symlink.c| 182 -
21 files changed, 6874 deletions(-)
Bad MAINTAINERS pattern in section 'PARALLEL LCD/KEYPAD PANEL DRIVER'
Please fix this defect appropriately.
linux-next MAINTAINERS section:
11056 PARALLEL LCD/KEYPAD PANEL DRIVER
11057 M: Willy Tarreau
11058 M: Ksenija Stanojevic
11059 S: Odd Fixes
11060 F: Documentation/auxdisplay/lcd-panel-cgram.txt
--> 11061 F: drivers/misc/panel.c
Commit that introduced this:
commit 7683e9e529258d01ce99216ad3be21f59eff83ec
Author: Linus Torvalds
Date: Sun Jul 23 16:06:21 2017 -0700
Properly alphabetize MAINTAINERS file
This adds a perl script to actually parse the MAINTAINERS file, clean up
some whitespace in it, warn about errors in it, and then properly sort
the end result.
My perl-fu is atrocious, so the script has basically been created by
randomly putting various characters in a pile, mixing them around, and
then looking it the end result does anything interesting when used as a
perl script.
Signed-off-by: Linus Torvalds
MAINTAINERS | 3585 +-
scripts/parse-maintainers.pl | 77 +
2 files changed, 1868 insertions(+), 1794 deletions(-)
Last commit with drivers/misc/panel.c
commit 51c1e9b554c996284d5d3bd44da829f41a49a21b
Author: Andy Shevchenko
Date: Tue Apr 4 20:25:21 2017 +0300
auxdisplay: Move panel.c to drivers/auxdisplay folder
It looks like panel.c belongs to auxdisplay subsystem.
Move it to drivers/auxdisplay folder.
No functional changes intended.
Acked-by: Geert Uytterhoeven
Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman
drivers/auxdisplay/Kconfig | 280 +++
drivers/auxdisplay/Makefile | 1 +
drivers/{misc => auxdisplay}/panel.c | 0
drivers/misc/Kconfig | 280 ---
drivers/misc/Makefile| 1 -
5 files changed, 281 insertions(+), 281 deletions(-)
Bad MAINTAINERS pattern in section 'MULTIPLEXER SUBSYSTEM'
Please fix this defect appropriately. linux-next MAINTAINERS section: 9976MULTIPLEXER SUBSYSTEM 9977M: Peter Rosin 9978S: Maintained 9979F: Documentation/ABI/testing/sysfs-class-mux* 9980F: Documentation/devicetree/bindings/mux/ --> 9981F: include/linux/dt-bindings/mux/ 9982F: include/linux/mux/ 9983F: drivers/mux/ Commit that introduced this: commit 256ac0375098e50d59c415fcbb561f2927fa8780 Author: Peter Rosin Date: Sun May 14 21:51:05 2017 +0200 dt-bindings: document devicetree bindings for mux-controllers and gpio-mux Allow specifying that a single multiplexer controller can be used to control several parallel multiplexers, thus enabling sharing of the multiplexer controller by different consumers. Add a binding for a first mux controller in the form of a GPIO based mux controller. Acked-by: Jonathan Cameron Acked-by: Rob Herring Signed-off-by: Peter Rosin Signed-off-by: Greg Kroah-Hartman Documentation/devicetree/bindings/mux/gpio-mux.txt | 69 + .../devicetree/bindings/mux/mux-controller.txt | 157 + MAINTAINERS| 6 + include/dt-bindings/mux/mux.h | 16 +++ 4 files changed, 248 insertions(+) No commit with include/linux/dt-bindings/mux/ found
Bad MAINTAINERS pattern in section 'NCP FILESYSTEM'
Please fix this defect appropriately.
linux-next MAINTAINERS section:
10052 NCP FILESYSTEM
10053 M: Petr Vandrovec
10054 S: Obsolete
--> 10055 F: drivers/staging/ncpfs/
Commit that introduced this:
commit 1bb8155080c652c4853e6228f8f0d262b3049699
Author: Stephen Hemminger
Date: Tue Nov 14 08:37:15 2017 -0800
ncpfs: move net/ncpfs to drivers/staging/ncpfs
The Netware Core Protocol is a file system that talks to
Netware clients over IPX. Since IPX has been dead for many years
move the file system into staging for eventual interment.
Signed-off-by: Stephen Hemminger
Acked-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
MAINTAINERS| 2 +-
drivers/staging/Kconfig| 2 ++
drivers/staging/Makefile | 1 +
{fs => drivers/staging}/ncpfs/Kconfig | 0
{fs => drivers/staging}/ncpfs/Makefile | 0
drivers/staging/ncpfs/TODO | 4
{fs => drivers/staging}/ncpfs/dir.c| 0
{fs => drivers/staging}/ncpfs/file.c | 0
{fs => drivers/staging}/ncpfs/getopt.c | 0
{fs => drivers/staging}/ncpfs/getopt.h | 0
{fs => drivers/staging}/ncpfs/inode.c | 0
{fs => drivers/staging}/ncpfs/ioctl.c | 0
{fs => drivers/staging}/ncpfs/mmap.c | 0
{fs => drivers/staging}/ncpfs/ncp_fs.h | 0
{fs => drivers/staging}/ncpfs/ncp_fs_i.h | 0
{fs => drivers/staging}/ncpfs/ncp_fs_sb.h | 0
{fs => drivers/staging}/ncpfs/ncplib_kernel.c | 0
{fs => drivers/staging}/ncpfs/ncplib_kernel.h | 0
{fs => drivers/staging}/ncpfs/ncpsign_kernel.c | 0
{fs => drivers/staging}/ncpfs/ncpsign_kernel.h | 0
{fs => drivers/staging}/ncpfs/sock.c | 0
{fs => drivers/staging}/ncpfs/symlink.c| 0
fs/Kconfig | 1 -
fs/Makefile| 1 -
24 files changed, 8 insertions(+), 3 deletions(-)
Last commit with drivers/staging/ncpfs/
commit bd32895c750bcd2b511bf93917bf7ae723e3d0b6
Author: Greg Kroah-Hartman
Date: Fri Jun 1 20:23:10 2018 +0200
staging: ncpfs: delete it
The ncpfs code moved into the staging tree back in November 2017 and no
one has complained or even noticed it was gone. Because of that, let's
just delete it.
Cc: Stephen Hemminger
Cc: David S. Miller
Signed-off-by: Greg Kroah-Hartman
drivers/staging/Kconfig|2 -
drivers/staging/Makefile |1 -
drivers/staging/ncpfs/Kconfig | 108 ---
drivers/staging/ncpfs/Makefile | 17 -
drivers/staging/ncpfs/TODO |4 -
drivers/staging/ncpfs/dir.c| 1232 -
drivers/staging/ncpfs/file.c | 263 ---
drivers/staging/ncpfs/getopt.c | 76 --
drivers/staging/ncpfs/getopt.h | 17 -
drivers/staging/ncpfs/inode.c | 1067 -
drivers/staging/ncpfs/ioctl.c | 923 --
drivers/staging/ncpfs/mmap.c | 125 ---
drivers/staging/ncpfs/ncp_fs.h | 101 ---
drivers/staging/ncpfs/ncp_fs_i.h | 31 -
drivers/staging/ncpfs/ncp_fs_sb.h | 174 -
drivers/staging/ncpfs/ncplib_kernel.c | 1326
drivers/staging/ncpfs/ncplib_kernel.h | 215 --
drivers/staging/ncpfs/ncpsign_kernel.c | 128 ---
drivers/staging/ncpfs/ncpsign_kernel.h | 27 -
drivers/staging/ncpfs/sock.c | 855
drivers/staging/ncpfs/symlink.c| 182 -
21 files changed, 6874 deletions(-)
Bad MAINTAINERS pattern in section 'PARALLEL LCD/KEYPAD PANEL DRIVER'
Please fix this defect appropriately.
linux-next MAINTAINERS section:
11056 PARALLEL LCD/KEYPAD PANEL DRIVER
11057 M: Willy Tarreau
11058 M: Ksenija Stanojevic
11059 S: Odd Fixes
11060 F: Documentation/auxdisplay/lcd-panel-cgram.txt
--> 11061 F: drivers/misc/panel.c
Commit that introduced this:
commit 7683e9e529258d01ce99216ad3be21f59eff83ec
Author: Linus Torvalds
Date: Sun Jul 23 16:06:21 2017 -0700
Properly alphabetize MAINTAINERS file
This adds a perl script to actually parse the MAINTAINERS file, clean up
some whitespace in it, warn about errors in it, and then properly sort
the end result.
My perl-fu is atrocious, so the script has basically been created by
randomly putting various characters in a pile, mixing them around, and
then looking it the end result does anything interesting when used as a
perl script.
Signed-off-by: Linus Torvalds
MAINTAINERS | 3585 +-
scripts/parse-maintainers.pl | 77 +
2 files changed, 1868 insertions(+), 1794 deletions(-)
Last commit with drivers/misc/panel.c
commit 51c1e9b554c996284d5d3bd44da829f41a49a21b
Author: Andy Shevchenko
Date: Tue Apr 4 20:25:21 2017 +0300
auxdisplay: Move panel.c to drivers/auxdisplay folder
It looks like panel.c belongs to auxdisplay subsystem.
Move it to drivers/auxdisplay folder.
No functional changes intended.
Acked-by: Geert Uytterhoeven
Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman
drivers/auxdisplay/Kconfig | 280 +++
drivers/auxdisplay/Makefile | 1 +
drivers/{misc => auxdisplay}/panel.c | 0
drivers/misc/Kconfig | 280 ---
drivers/misc/Makefile| 1 -
5 files changed, 281 insertions(+), 281 deletions(-)
Bad MAINTAINERS pattern in section 'MULTIPLEXER SUBSYSTEM'
Please fix this defect appropriately. linux-next MAINTAINERS section: 9976MULTIPLEXER SUBSYSTEM 9977M: Peter Rosin 9978S: Maintained 9979F: Documentation/ABI/testing/sysfs-class-mux* 9980F: Documentation/devicetree/bindings/mux/ --> 9981F: include/linux/dt-bindings/mux/ 9982F: include/linux/mux/ 9983F: drivers/mux/ Commit that introduced this: commit 256ac0375098e50d59c415fcbb561f2927fa8780 Author: Peter Rosin Date: Sun May 14 21:51:05 2017 +0200 dt-bindings: document devicetree bindings for mux-controllers and gpio-mux Allow specifying that a single multiplexer controller can be used to control several parallel multiplexers, thus enabling sharing of the multiplexer controller by different consumers. Add a binding for a first mux controller in the form of a GPIO based mux controller. Acked-by: Jonathan Cameron Acked-by: Rob Herring Signed-off-by: Peter Rosin Signed-off-by: Greg Kroah-Hartman Documentation/devicetree/bindings/mux/gpio-mux.txt | 69 + .../devicetree/bindings/mux/mux-controller.txt | 157 + MAINTAINERS| 6 + include/dt-bindings/mux/mux.h | 16 +++ 4 files changed, 248 insertions(+) No commit with include/linux/dt-bindings/mux/ found
Re: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
Thanks Maciej. On 28/09/2018 16:54, Maciej S. Szmigiero wrote: > Hi, > >> Hi, >> >> I upgraded my kernel to 4.18.10 recently and have since been experiencing >> network problems after resuming from a >> suspend to RAM or disk. I previously had 4.18.6 and that was OK. >> >> The pattern of the problem is that when I first boot, the network is fine. >> But, after resume from suspend I find that >> the time taken for a ping of one of my ISP's nameservers increases from >> 14-15ms to more than 1000ms. Moreover, when I >> open a browser (chromium or firefox), it fails to retrieve my home page >> (https://www.google.co.uk) and pings of the >> nameserver fail with the message "Destination Host Unreachable". Often, I >> can revive the network by stopping it with >> /sbin/if(down,up} but sometimes it is necessary to also remove the r8169 >> module and load it again. > > Please have a look at the following thread: > https://lkml.org/lkml/2018/9/25/1118 > I applied your patch for the 4.18 stable kernels to 4.18.10, but the problem is not solved by it. Similarly, I applied Heiner's patch to the 4.19, but again the problem is not solved. > Maciej > Chris
Re: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
Thanks Maciej. On 28/09/2018 16:54, Maciej S. Szmigiero wrote: > Hi, > >> Hi, >> >> I upgraded my kernel to 4.18.10 recently and have since been experiencing >> network problems after resuming from a >> suspend to RAM or disk. I previously had 4.18.6 and that was OK. >> >> The pattern of the problem is that when I first boot, the network is fine. >> But, after resume from suspend I find that >> the time taken for a ping of one of my ISP's nameservers increases from >> 14-15ms to more than 1000ms. Moreover, when I >> open a browser (chromium or firefox), it fails to retrieve my home page >> (https://www.google.co.uk) and pings of the >> nameserver fail with the message "Destination Host Unreachable". Often, I >> can revive the network by stopping it with >> /sbin/if(down,up} but sometimes it is necessary to also remove the r8169 >> module and load it again. > > Please have a look at the following thread: > https://lkml.org/lkml/2018/9/25/1118 > I applied your patch for the 4.18 stable kernels to 4.18.10, but the problem is not solved by it. Similarly, I applied Heiner's patch to the 4.19, but again the problem is not solved. > Maciej > Chris
Bad MAINTAINERS pattern in section 'MIPS/LOONGSON3 ARCHITECTURE'
Please fix this defect appropriately. linux-next MAINTAINERS section: 9766MIPS/LOONGSON3 ARCHITECTURE 9767M: Huacai Chen 9768L: linux-m...@linux-mips.org 9769S: Maintained 9770F: arch/mips/loongson64/ 9771F: arch/mips/include/asm/mach-loongson64/ 9772F: drivers/platform/mips/cpu_hwmon.c 9773F: drivers/*/*loongson3* --> 9774F: drivers/*/*/*loongson3* Commit that introduced this: commit ffe1f9356fbe55df7dd7f7f6b050ee8b7136611f Author: Huacai Chen Date: Thu Dec 7 14:31:08 2017 +0800 MAINTAINERS: Add Loongson-2/Loongson-3 maintainers Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen as the MIPS/Loongson-3 maintainer. [r...@linux-mips.org: Don't put all of drivers/platform/mips/ into these two entries but rather only the files required even though at this time the Loongson platforms are the only users of drivers/platform/mips/.] Signed-off-by: Huacai Chen Signed-off-by: Jiaxun Yang Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Stephen Rothwell Cc: James Hogan Cc: Rui Wang Cc: Binbin Zhou Cc: Ce Sun Cc: Yao Wang Cc: Liangliang Huang Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Jiaxun Yang Cc: r...@hev.cc Cc: zhoubb.aa...@gmail.com Cc: huangll...@163.com Cc: 513434...@qq.com Cc: 1393699...@qq.com Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Huacai Chen Patchwork: https://patchwork.linux-mips.org/patch/17888/ Signed-off-by: Ralf Baechle Signed-off-by: James Hogan MAINTAINERS | 19 +++ 1 file changed, 19 insertions(+) No commit with drivers/*/*/*loongson3* found
Bad MAINTAINERS pattern in section 'MIPS/LOONGSON3 ARCHITECTURE'
Please fix this defect appropriately. linux-next MAINTAINERS section: 9766MIPS/LOONGSON3 ARCHITECTURE 9767M: Huacai Chen 9768L: linux-m...@linux-mips.org 9769S: Maintained 9770F: arch/mips/loongson64/ 9771F: arch/mips/include/asm/mach-loongson64/ 9772F: drivers/platform/mips/cpu_hwmon.c 9773F: drivers/*/*loongson3* --> 9774F: drivers/*/*/*loongson3* Commit that introduced this: commit ffe1f9356fbe55df7dd7f7f6b050ee8b7136611f Author: Huacai Chen Date: Thu Dec 7 14:31:08 2017 +0800 MAINTAINERS: Add Loongson-2/Loongson-3 maintainers Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen as the MIPS/Loongson-3 maintainer. [r...@linux-mips.org: Don't put all of drivers/platform/mips/ into these two entries but rather only the files required even though at this time the Loongson platforms are the only users of drivers/platform/mips/.] Signed-off-by: Huacai Chen Signed-off-by: Jiaxun Yang Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Stephen Rothwell Cc: James Hogan Cc: Rui Wang Cc: Binbin Zhou Cc: Ce Sun Cc: Yao Wang Cc: Liangliang Huang Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Jiaxun Yang Cc: r...@hev.cc Cc: zhoubb.aa...@gmail.com Cc: huangll...@163.com Cc: 513434...@qq.com Cc: 1393699...@qq.com Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Huacai Chen Patchwork: https://patchwork.linux-mips.org/patch/17888/ Signed-off-by: Ralf Baechle Signed-off-by: James Hogan MAINTAINERS | 19 +++ 1 file changed, 19 insertions(+) No commit with drivers/*/*/*loongson3* found
Bad MAINTAINERS pattern in section 'MIPS/LOONGSON3 ARCHITECTURE'
Please fix this defect appropriately. linux-next MAINTAINERS section: 9766MIPS/LOONGSON3 ARCHITECTURE 9767M: Huacai Chen 9768L: linux-m...@linux-mips.org 9769S: Maintained 9770F: arch/mips/loongson64/ 9771F: arch/mips/include/asm/mach-loongson64/ 9772F: drivers/platform/mips/cpu_hwmon.c --> 9773F: drivers/*/*loongson3* 9774F: drivers/*/*/*loongson3* Commit that introduced this: commit ffe1f9356fbe55df7dd7f7f6b050ee8b7136611f Author: Huacai Chen Date: Thu Dec 7 14:31:08 2017 +0800 MAINTAINERS: Add Loongson-2/Loongson-3 maintainers Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen as the MIPS/Loongson-3 maintainer. [r...@linux-mips.org: Don't put all of drivers/platform/mips/ into these two entries but rather only the files required even though at this time the Loongson platforms are the only users of drivers/platform/mips/.] Signed-off-by: Huacai Chen Signed-off-by: Jiaxun Yang Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Stephen Rothwell Cc: James Hogan Cc: Rui Wang Cc: Binbin Zhou Cc: Ce Sun Cc: Yao Wang Cc: Liangliang Huang Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Jiaxun Yang Cc: r...@hev.cc Cc: zhoubb.aa...@gmail.com Cc: huangll...@163.com Cc: 513434...@qq.com Cc: 1393699...@qq.com Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Huacai Chen Patchwork: https://patchwork.linux-mips.org/patch/17888/ Signed-off-by: Ralf Baechle Signed-off-by: James Hogan MAINTAINERS | 19 +++ 1 file changed, 19 insertions(+) No commit with drivers/*/*loongson3* found
Bad MAINTAINERS pattern in section 'MIPS/LOONGSON3 ARCHITECTURE'
Please fix this defect appropriately. linux-next MAINTAINERS section: 9766MIPS/LOONGSON3 ARCHITECTURE 9767M: Huacai Chen 9768L: linux-m...@linux-mips.org 9769S: Maintained 9770F: arch/mips/loongson64/ 9771F: arch/mips/include/asm/mach-loongson64/ 9772F: drivers/platform/mips/cpu_hwmon.c --> 9773F: drivers/*/*loongson3* 9774F: drivers/*/*/*loongson3* Commit that introduced this: commit ffe1f9356fbe55df7dd7f7f6b050ee8b7136611f Author: Huacai Chen Date: Thu Dec 7 14:31:08 2017 +0800 MAINTAINERS: Add Loongson-2/Loongson-3 maintainers Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen as the MIPS/Loongson-3 maintainer. [r...@linux-mips.org: Don't put all of drivers/platform/mips/ into these two entries but rather only the files required even though at this time the Loongson platforms are the only users of drivers/platform/mips/.] Signed-off-by: Huacai Chen Signed-off-by: Jiaxun Yang Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Stephen Rothwell Cc: James Hogan Cc: Rui Wang Cc: Binbin Zhou Cc: Ce Sun Cc: Yao Wang Cc: Liangliang Huang Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Jiaxun Yang Cc: r...@hev.cc Cc: zhoubb.aa...@gmail.com Cc: huangll...@163.com Cc: 513434...@qq.com Cc: 1393699...@qq.com Cc: linux-m...@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Huacai Chen Patchwork: https://patchwork.linux-mips.org/patch/17888/ Signed-off-by: Ralf Baechle Signed-off-by: James Hogan MAINTAINERS | 19 +++ 1 file changed, 19 insertions(+) No commit with drivers/*/*loongson3* found
Bad MAINTAINERS pattern in section 'MIPS/LOONGSON2 ARCHITECTURE'
Please fix this defect appropriately.
linux-next MAINTAINERS section:
9757MIPS/LOONGSON2 ARCHITECTURE
9758M: Jiaxun Yang
9759L: linux-m...@linux-mips.org
9760S: Maintained
9761F: arch/mips/loongson64/*{2e/2f}*
9762F: arch/mips/include/asm/mach-loongson64/
9763F: drivers/*/*loongson2*
--> 9764F: drivers/*/*/*loongson2*
Commit that introduced this:
commit ffe1f9356fbe55df7dd7f7f6b050ee8b7136611f
Author: Huacai Chen
Date: Thu Dec 7 14:31:08 2017 +0800
MAINTAINERS: Add Loongson-2/Loongson-3 maintainers
Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen
as the MIPS/Loongson-3 maintainer.
[r...@linux-mips.org: Don't put all of drivers/platform/mips/ into these
two entries but rather only the files required even though at this time
the Loongson platforms are the only users of drivers/platform/mips/.]
Signed-off-by: Huacai Chen
Signed-off-by: Jiaxun Yang
Cc: Linus Torvalds
Cc: Greg Kroah-Hartman
Cc: Stephen Rothwell
Cc: James Hogan
Cc: Rui Wang
Cc: Binbin Zhou
Cc: Ce Sun
Cc: Yao Wang
Cc: Liangliang Huang
Cc: Fuxin Zhang
Cc: Zhangjin Wu
Cc: Jiaxun Yang
Cc: r...@hev.cc
Cc: zhoubb.aa...@gmail.com
Cc: huangll...@163.com
Cc: 513434...@qq.com
Cc: 1393699...@qq.com
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: Huacai Chen
Patchwork: https://patchwork.linux-mips.org/patch/17888/
Signed-off-by: Ralf Baechle
Signed-off-by: James Hogan
MAINTAINERS | 19 +++
1 file changed, 19 insertions(+)
No commit with drivers/*/*/*loongson2* found
Bad MAINTAINERS pattern in section 'MIPS/LOONGSON2 ARCHITECTURE'
Please fix this defect appropriately.
linux-next MAINTAINERS section:
9757MIPS/LOONGSON2 ARCHITECTURE
9758M: Jiaxun Yang
9759L: linux-m...@linux-mips.org
9760S: Maintained
9761F: arch/mips/loongson64/*{2e/2f}*
9762F: arch/mips/include/asm/mach-loongson64/
9763F: drivers/*/*loongson2*
--> 9764F: drivers/*/*/*loongson2*
Commit that introduced this:
commit ffe1f9356fbe55df7dd7f7f6b050ee8b7136611f
Author: Huacai Chen
Date: Thu Dec 7 14:31:08 2017 +0800
MAINTAINERS: Add Loongson-2/Loongson-3 maintainers
Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen
as the MIPS/Loongson-3 maintainer.
[r...@linux-mips.org: Don't put all of drivers/platform/mips/ into these
two entries but rather only the files required even though at this time
the Loongson platforms are the only users of drivers/platform/mips/.]
Signed-off-by: Huacai Chen
Signed-off-by: Jiaxun Yang
Cc: Linus Torvalds
Cc: Greg Kroah-Hartman
Cc: Stephen Rothwell
Cc: James Hogan
Cc: Rui Wang
Cc: Binbin Zhou
Cc: Ce Sun
Cc: Yao Wang
Cc: Liangliang Huang
Cc: Fuxin Zhang
Cc: Zhangjin Wu
Cc: Jiaxun Yang
Cc: r...@hev.cc
Cc: zhoubb.aa...@gmail.com
Cc: huangll...@163.com
Cc: 513434...@qq.com
Cc: 1393699...@qq.com
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: Huacai Chen
Patchwork: https://patchwork.linux-mips.org/patch/17888/
Signed-off-by: Ralf Baechle
Signed-off-by: James Hogan
MAINTAINERS | 19 +++
1 file changed, 19 insertions(+)
No commit with drivers/*/*/*loongson2* found
Re: [PATCH v7 0/6] seccomp trap to userspace
Hi Tycho, On 09/27/2018 05:11 PM, Tycho Andersen wrote: Hi all, Here's v7 of the seccomp trap to userspace set. There are various minor changes and bug fixes, but two major changes: * We now pass fds to the tracee via an ioctl, and do it immediately when the ioctl is called. For this we needed some help from the vfs, so I've put the one patch in this series and cc'd fsdevel. This does have the advantage that the feature is now totally decoupled from the rest of the set, which is itself useful (thanks Andy!) * Instead of putting all of the notification related stuff into the struct seccomp_filter, it now lives in its own struct notification, which is pointed to by struct seccomp_filter. This will save a lot of memory (thanks Tyler!) Is there a documentation (man page) patch for this API change? Thanks, Michael v6 discussion: https://lkml.org/lkml/2018/9/6/769 Thoughts welcome, Tycho Tycho Andersen (6): seccomp: add a return code to trap to userspace seccomp: make get_nth_filter available outside of CHECKPOINT_RESTORE seccomp: add a way to get a listener fd from ptrace files: add a replace_fd_files() function seccomp: add a way to pass FDs via a notification fd samples: add an example of seccomp user trap Documentation/ioctl/ioctl-number.txt | 1 + .../userspace-api/seccomp_filter.rst | 89 +++ fs/file.c | 22 +- include/linux/file.h | 8 + include/linux/seccomp.h | 14 +- include/uapi/linux/ptrace.h | 2 + include/uapi/linux/seccomp.h | 42 +- kernel/ptrace.c | 4 + kernel/seccomp.c | 527 ++- samples/seccomp/.gitignore| 1 + samples/seccomp/Makefile | 7 +- samples/seccomp/user-trap.c | 312 + tools/testing/selftests/seccomp/seccomp_bpf.c | 607 +- 13 files changed, 1617 insertions(+), 19 deletions(-) create mode 100644 samples/seccomp/user-trap.c
Re: [PATCH v7 0/6] seccomp trap to userspace
Hi Tycho, On 09/27/2018 05:11 PM, Tycho Andersen wrote: Hi all, Here's v7 of the seccomp trap to userspace set. There are various minor changes and bug fixes, but two major changes: * We now pass fds to the tracee via an ioctl, and do it immediately when the ioctl is called. For this we needed some help from the vfs, so I've put the one patch in this series and cc'd fsdevel. This does have the advantage that the feature is now totally decoupled from the rest of the set, which is itself useful (thanks Andy!) * Instead of putting all of the notification related stuff into the struct seccomp_filter, it now lives in its own struct notification, which is pointed to by struct seccomp_filter. This will save a lot of memory (thanks Tyler!) Is there a documentation (man page) patch for this API change? Thanks, Michael v6 discussion: https://lkml.org/lkml/2018/9/6/769 Thoughts welcome, Tycho Tycho Andersen (6): seccomp: add a return code to trap to userspace seccomp: make get_nth_filter available outside of CHECKPOINT_RESTORE seccomp: add a way to get a listener fd from ptrace files: add a replace_fd_files() function seccomp: add a way to pass FDs via a notification fd samples: add an example of seccomp user trap Documentation/ioctl/ioctl-number.txt | 1 + .../userspace-api/seccomp_filter.rst | 89 +++ fs/file.c | 22 +- include/linux/file.h | 8 + include/linux/seccomp.h | 14 +- include/uapi/linux/ptrace.h | 2 + include/uapi/linux/seccomp.h | 42 +- kernel/ptrace.c | 4 + kernel/seccomp.c | 527 ++- samples/seccomp/.gitignore| 1 + samples/seccomp/Makefile | 7 +- samples/seccomp/user-trap.c | 312 + tools/testing/selftests/seccomp/seccomp_bpf.c | 607 +- 13 files changed, 1617 insertions(+), 19 deletions(-) create mode 100644 samples/seccomp/user-trap.c
Bad MAINTAINERS pattern in section 'MEN Z069 WATCHDOG DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 9483MEN Z069 WATCHDOG DRIVER 9484M: Johannes Thumshirn 9485L: linux-watch...@vger.kernel.org 9486S: Maintained --> 9487F: drivers/watchdog/menz069_wdt.c Commit that introduced this: commit 81ceed41d0c2b2c9300de7bc30c1451680257f52 Author: Johannes Thumshirn Date: Mon Jul 16 09:25:10 2018 +0200 watchdog: add driver for the MEN 16z069 IP-Core Add a driver for the MEN 16z069 Watchdog and Reset Controller IP-Core. Signed-off-by: Johannes Thumshirn Reviewed-by: Michael Moese Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck MAINTAINERS | 6 ++ drivers/watchdog/Kconfig | 10 +++ drivers/watchdog/Makefile | 1 + drivers/watchdog/menz69_wdt.c | 170 ++ 4 files changed, 187 insertions(+) No commit with drivers/watchdog/menz069_wdt.c found
Bad MAINTAINERS pattern in section 'MEN Z069 WATCHDOG DRIVER'
Please fix this defect appropriately. linux-next MAINTAINERS section: 9483MEN Z069 WATCHDOG DRIVER 9484M: Johannes Thumshirn 9485L: linux-watch...@vger.kernel.org 9486S: Maintained --> 9487F: drivers/watchdog/menz069_wdt.c Commit that introduced this: commit 81ceed41d0c2b2c9300de7bc30c1451680257f52 Author: Johannes Thumshirn Date: Mon Jul 16 09:25:10 2018 +0200 watchdog: add driver for the MEN 16z069 IP-Core Add a driver for the MEN 16z069 Watchdog and Reset Controller IP-Core. Signed-off-by: Johannes Thumshirn Reviewed-by: Michael Moese Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck MAINTAINERS | 6 ++ drivers/watchdog/Kconfig | 10 +++ drivers/watchdog/Makefile | 1 + drivers/watchdog/menz69_wdt.c | 170 ++ 4 files changed, 187 insertions(+) No commit with drivers/watchdog/menz069_wdt.c found
Re: [PATCH] input: sun4i-lradc: Convert to using %pOFn instead of device_node.name
On Mon, Aug 27, 2018 at 8:54 PM Rob Herring wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Hans de Goede
> Cc: Dmitry Torokhov
> Cc: Maxime Ripard
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> drivers/input/keyboard/sun4i-lradc-keys.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Ping.
>
> diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c
> b/drivers/input/keyboard/sun4i-lradc-keys.c
> index a37c172452e6..57272df34cd5 100644
> --- a/drivers/input/keyboard/sun4i-lradc-keys.c
> +++ b/drivers/input/keyboard/sun4i-lradc-keys.c
> @@ -185,19 +185,19 @@ static int sun4i_lradc_load_dt_keymap(struct device
> *dev,
>
> error = of_property_read_u32(pp, "channel", );
> if (error || channel != 0) {
> - dev_err(dev, "%s: Inval channel prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval channel prop\n", pp);
> return -EINVAL;
> }
>
> error = of_property_read_u32(pp, "voltage", >voltage);
> if (error) {
> - dev_err(dev, "%s: Inval voltage prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval voltage prop\n", pp);
> return -EINVAL;
> }
>
> error = of_property_read_u32(pp, "linux,code", >keycode);
> if (error) {
> - dev_err(dev, "%s: Inval linux,code prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval linux,code prop\n", pp);
> return -EINVAL;
> }
>
> --
> 2.17.1
>
Re: [PATCH] input: sun4i-lradc: Convert to using %pOFn instead of device_node.name
On Mon, Aug 27, 2018 at 8:54 PM Rob Herring wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Hans de Goede
> Cc: Dmitry Torokhov
> Cc: Maxime Ripard
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Rob Herring
> ---
> drivers/input/keyboard/sun4i-lradc-keys.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Ping.
>
> diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c
> b/drivers/input/keyboard/sun4i-lradc-keys.c
> index a37c172452e6..57272df34cd5 100644
> --- a/drivers/input/keyboard/sun4i-lradc-keys.c
> +++ b/drivers/input/keyboard/sun4i-lradc-keys.c
> @@ -185,19 +185,19 @@ static int sun4i_lradc_load_dt_keymap(struct device
> *dev,
>
> error = of_property_read_u32(pp, "channel", );
> if (error || channel != 0) {
> - dev_err(dev, "%s: Inval channel prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval channel prop\n", pp);
> return -EINVAL;
> }
>
> error = of_property_read_u32(pp, "voltage", >voltage);
> if (error) {
> - dev_err(dev, "%s: Inval voltage prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval voltage prop\n", pp);
> return -EINVAL;
> }
>
> error = of_property_read_u32(pp, "linux,code", >keycode);
> if (error) {
> - dev_err(dev, "%s: Inval linux,code prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval linux,code prop\n", pp);
> return -EINVAL;
> }
>
> --
> 2.17.1
>
Re: [PATCH 3/3] seccomp: introduce read protection for struct seccomp
On Fri, Sep 28, 2018 at 11:36 PM Tycho Andersen wrote: > On Fri, Sep 28, 2018 at 11:10:48PM +0200, Jann Horn wrote: > > On Fri, Sep 28, 2018 at 10:56 PM Tycho Andersen wrote: > > > > > > On Fri, Sep 28, 2018 at 10:33:34PM +0200, Jann Horn wrote: > > > > On Fri, Sep 28, 2018 at 5:47 PM Tycho Andersen wrote: > > > > > As Jann pointed out, there is a race between > > > > > SECCOMP_FILTER_FLAG_TSYNC and > > > > > the ptrace code that can inspect a filter of another process. Let's > > > > > introduce read locking into the two ptrace accesses so that we don't > > > > > race. > > > > > > > > Hmm. Is that true? The ptrace code uses get_nth_filter(), which holds > > > > the siglock while grabbing the seccomp filter and bumping its > > > > refcount. And TSYNC happens from seccomp_set_mode_filter(), which > > > > takes the siglock. So this looks okay to me? > > > > > > Oh, yes, you're right. So I guess we should just change the comment to > > > say we're using siglock to represent the read lock. > > > > Hmm... actually, looking at this closer, I think you only need the > > siglock for writing. As far as I can tell, any read (no matter if > > current or non-current) can just use READ_ONCE(), because once a > > seccomp filter is in a task's seccomp filter chain, it can't be freed > > until the task reaches free_task() and calls put_seccomp_filter() from > > there. And if the task whose seccomp filter you're trying to read can > > reach free_task(), you have bigger problems. > > Ok; looks like get_nth_filter() took the siglock anyway. Since we get > the filters in these two functions in get_nth_filter(), I think it's > enough just to just, > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > index f65d47650ac1..79d833ed4c34 100644 > --- a/kernel/seccomp.c > +++ b/kernel/seccomp.c > @@ -1001,7 +1001,7 @@ static struct seccomp_filter *get_nth_filter(struct > task_struct *task, > return ERR_PTR(-EINVAL); > } > > - orig = task->seccomp.filter; > + orig = READ_ONCE(task->seccomp.filter); > __get_seccomp_filter(orig); > spin_unlock_irq(>sighand->siglock); Huh? Now you're holding the siglock *and* you're using READ_ONCE()? I'm not sure what you're trying to accomplish here. > since once it's returned from get_nth_filter() we don't need to worry > about multiple accesses? > > Tycho
Bad MAINTAINERS pattern in section 'LANTIQ / INTEL Ethernet drivers'
Please fix this defect appropriately. linux-next MAINTAINERS section: 8155LANTIQ / INTEL Ethernet drivers 8156M: Hauke Mehrtens 8157L: net...@vger.kernel.org 8158S: Maintained 8159F: net/dsa/tag_gswip.c 8160F: drivers/net/ethernet/lantiq_xrx200.c 8161F: drivers/net/dsa/lantiq_pce.h --> 8162F: drivers/net/dsa/intel_gswip.c Commit that introduced this: commit 14fceff4771e51b23b4485b575cf9e5b3414b89b Author: Hauke Mehrtens Date: Sun Sep 9 22:20:39 2018 +0200 net: dsa: Add Lantiq / Intel DSA driver for vrx200 This adds the DSA driver for the GSWIP Switch found in the VRX200 SoC. This switch is integrated in the DSL SoC, this SoC uses a GSWIP version 2.1, there are other SoCs using different versions of this IP block, but this driver was only tested with the version found in the VRX200. Currently only the basic features are implemented which will forward all packages to the CPU and let the CPU do the forwarding. The hardware also support Layer 2 offloading which is not yet implemented in this driver. The GPHY FW loaded is now done by this driver and not any more by the separate driver in drivers/soc/lantiq/gphy.c, I will remove this driver is a separate patch. to make use of the GPHY this switch driver is needed anyway. Other SoCs have more embedded GPHYs so this driver should support a variable number of GPHYs. After the firmware was loaded the GPHY can be probed on the MDIO bus and it behaves like an external GPHY, without the firmware it can not be probed on the MDIO bus. The clock names in the sysctrl.c file have to be changed because the clocks are now used by a different driver. This should be cleaned up and a real common clock driver should provide the clocks instead. Signed-off-by: Hauke Mehrtens Signed-off-by: David S. Miller MAINTAINERS |2 + arch/mips/lantiq/xway/sysctrl.c |8 +- drivers/net/dsa/Kconfig |8 + drivers/net/dsa/Makefile|1 + drivers/net/dsa/lantiq_gswip.c | 1169 +++ drivers/net/dsa/lantiq_pce.h| 153 + 6 files changed, 1337 insertions(+), 4 deletions(-) No commit with drivers/net/dsa/intel_gswip.c found
Re: [PATCH] fix memory leak in ramoops_init
On Fri, Sep 28, 2018 at 2:26 PM, Andrew Morton wrote: > On Mon, 17 Sep 2018 17:15:31 +0800 nixiaoming wrote: > >> 1, memory leak in ramoops_register_dummy. >>dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL); >>but no free when platform_device_register_data return fail >> >> 2, if kzalloc(sizeof(*dummy_data), GFP_KERNEL) return NULL, >> but platform_driver_register(_driver) return 0 >>kfree(NULL) in ramoops_exit >> so, add return val for ramoops_register_dummy, and check it in ramoops_init >> >> 3, memory leak in ramoops_init. >>miss platform_device_unregister(dummy) and kfree(dummy_data) >>when platform_driver_register(_driver) return fail > > Looks right. > > It's unclear (to me) who maintains fs/pstore/ram.c. Let's add some > Cc's and see if we can catch a reviewed-by. It's me: PSTORE FILESYSTEM M: Kees Cook M: Anton Vorontsov M: Colin Cross M: Tony Luck S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/pstore F: fs/pstore/ F: include/linux/pstore* F: drivers/firmware/efi/efi-pstore.c F: drivers/acpi/apei/erst.c F: Documentation/admin-guide/ramoops.rst F: Documentation/devicetree/bindings/reserved-memory/ramoops.txt K: \b(pstore|ramoops) I'll take review it and take it via the pstore tree. Thanks! -Kees -- Kees Cook Pixel Security
Re: [PATCH] mailbox: Convert to using %pOFn instead of device_node.name
On Mon, Aug 27, 2018 at 8:54 PM Rob Herring wrote: > > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. > > Cc: Jassi Brar > Signed-off-by: Rob Herring > --- > drivers/mailbox/ti-msgmgr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Ping. > > diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c > index 5bceafbf6699..713d701b6568 100644 > --- a/drivers/mailbox/ti-msgmgr.c > +++ b/drivers/mailbox/ti-msgmgr.c > @@ -560,8 +560,8 @@ static struct mbox_chan *ti_msgmgr_of_xlate(struct > mbox_controller *mbox, > } > > err: > - dev_err(inst->dev, "Queue ID %d, Proxy ID %d is wrong on %s\n", > - req_qid, req_pid, p->np->name); > + dev_err(inst->dev, "Queue ID %d, Proxy ID %d is wrong on %pOFn\n", > + req_qid, req_pid, p->np); > return ERR_PTR(-ENOENT); > } > > -- > 2.17.1 >
Bad MAINTAINERS pattern in section 'LOCKING PRIMITIVES'
Please fix this defect appropriately. linux-next MAINTAINERS section: 8566LOCKING PRIMITIVES 8567M: Peter Zijlstra 8568M: Ingo Molnar 8569M: Will Deacon 8570L: linux-kernel@vger.kernel.org 8571T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core 8572S: Maintained 8573F: Documentation/locking/ 8574F: include/linux/lockdep.h 8575F: include/linux/spinlock*.h 8576F: arch/*/include/asm/spinlock*.h 8577F: include/linux/rwlock*.h 8578F: include/linux/mutex*.h --> 8579F: arch/*/include/asm/mutex*.h 8580F: include/linux/rwsem*.h 8581F: arch/*/include/asm/rwsem.h 8582F: include/linux/seqlock.h 8583F: lib/locking*.[ch] 8584F: kernel/locking/ 8585X: kernel/locking/locktorture.c Commit that introduced this: commit d4c3be70ca0e7a1ae308bedd3462900c61e97b11 Author: Ingo Molnar Date: Thu Jun 9 12:20:25 2016 +0200 MAINTAINERS: Update locking tree description and file patterns Update the file patterns, the Git tree URI and also widen the scope from 'LOCKDEP and LOCKSTAT' to 'LOCKING PRIMITIVES'. Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Andrew Morton Cc: Thomas Gleixner Cc: Paul E. McKenney Cc: linux-kernel@vger.kernel.org MAINTAINERS | 16 1 file changed, 12 insertions(+), 4 deletions(-) Last commit with arch/*/include/asm/mutex*.h commit 890658b7ab48d1362a0362df842cecc73c83146f Author: Peter Zijlstra Date: Tue Aug 23 13:36:04 2016 +0200 locking/mutex: Kill arch specific code Its all generic atomic_long_t stuff now. Tested-by: Jason Low Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-a...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar arch/alpha/include/asm/mutex.h | 9 --- arch/arc/include/asm/mutex.h| 18 - arch/arm/include/asm/mutex.h| 21 -- arch/arm64/include/asm/Kbuild | 1 - arch/avr32/include/asm/mutex.h | 9 --- arch/blackfin/include/asm/Kbuild| 1 - arch/c6x/include/asm/mutex.h| 6 -- arch/cris/include/asm/mutex.h | 9 --- arch/frv/include/asm/mutex.h| 9 --- arch/h8300/include/asm/mutex.h | 9 --- arch/hexagon/include/asm/mutex.h| 8 --- arch/ia64/include/asm/mutex.h | 90 arch/m32r/include/asm/mutex.h | 9 --- arch/m68k/include/asm/Kbuild| 1 - arch/metag/include/asm/Kbuild | 1 - arch/microblaze/include/asm/mutex.h | 1 - arch/mips/include/asm/Kbuild| 1 - arch/mn10300/include/asm/mutex.h| 16 - arch/nios2/include/asm/mutex.h | 1 - arch/openrisc/include/asm/mutex.h | 27 arch/parisc/include/asm/Kbuild | 1 - arch/powerpc/include/asm/mutex.h| 132 arch/s390/include/asm/mutex.h | 9 --- arch/score/include/asm/mutex.h | 6 -- arch/sh/include/asm/mutex-llsc.h| 109 - arch/sh/include/asm/mutex.h | 12 arch/sparc/include/asm/Kbuild | 1 - arch/tile/include/asm/Kbuild| 1 - arch/um/include/asm/Kbuild | 1 - arch/unicore32/include/asm/mutex.h | 20 -- arch/x86/include/asm/mutex.h| 5 -- arch/x86/include/asm/mutex_32.h | 110 -- arch/x86/include/asm/mutex_64.h | 127 -- arch/xtensa/include/asm/mutex.h | 9 --- include/asm-generic/mutex-dec.h | 88 include/asm-generic/mutex-null.h| 19 -- include/asm-generic/mutex-xchg.h| 120 include/asm-generic/mutex.h | 9 --- 38 files changed, 1026 deletions(-)
Re: [PATCH 3/3] seccomp: introduce read protection for struct seccomp
On Fri, Sep 28, 2018 at 11:36 PM Tycho Andersen wrote: > On Fri, Sep 28, 2018 at 11:10:48PM +0200, Jann Horn wrote: > > On Fri, Sep 28, 2018 at 10:56 PM Tycho Andersen wrote: > > > > > > On Fri, Sep 28, 2018 at 10:33:34PM +0200, Jann Horn wrote: > > > > On Fri, Sep 28, 2018 at 5:47 PM Tycho Andersen wrote: > > > > > As Jann pointed out, there is a race between > > > > > SECCOMP_FILTER_FLAG_TSYNC and > > > > > the ptrace code that can inspect a filter of another process. Let's > > > > > introduce read locking into the two ptrace accesses so that we don't > > > > > race. > > > > > > > > Hmm. Is that true? The ptrace code uses get_nth_filter(), which holds > > > > the siglock while grabbing the seccomp filter and bumping its > > > > refcount. And TSYNC happens from seccomp_set_mode_filter(), which > > > > takes the siglock. So this looks okay to me? > > > > > > Oh, yes, you're right. So I guess we should just change the comment to > > > say we're using siglock to represent the read lock. > > > > Hmm... actually, looking at this closer, I think you only need the > > siglock for writing. As far as I can tell, any read (no matter if > > current or non-current) can just use READ_ONCE(), because once a > > seccomp filter is in a task's seccomp filter chain, it can't be freed > > until the task reaches free_task() and calls put_seccomp_filter() from > > there. And if the task whose seccomp filter you're trying to read can > > reach free_task(), you have bigger problems. > > Ok; looks like get_nth_filter() took the siglock anyway. Since we get > the filters in these two functions in get_nth_filter(), I think it's > enough just to just, > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > index f65d47650ac1..79d833ed4c34 100644 > --- a/kernel/seccomp.c > +++ b/kernel/seccomp.c > @@ -1001,7 +1001,7 @@ static struct seccomp_filter *get_nth_filter(struct > task_struct *task, > return ERR_PTR(-EINVAL); > } > > - orig = task->seccomp.filter; > + orig = READ_ONCE(task->seccomp.filter); > __get_seccomp_filter(orig); > spin_unlock_irq(>sighand->siglock); Huh? Now you're holding the siglock *and* you're using READ_ONCE()? I'm not sure what you're trying to accomplish here. > since once it's returned from get_nth_filter() we don't need to worry > about multiple accesses? > > Tycho
Bad MAINTAINERS pattern in section 'LANTIQ / INTEL Ethernet drivers'
Please fix this defect appropriately. linux-next MAINTAINERS section: 8155LANTIQ / INTEL Ethernet drivers 8156M: Hauke Mehrtens 8157L: net...@vger.kernel.org 8158S: Maintained 8159F: net/dsa/tag_gswip.c 8160F: drivers/net/ethernet/lantiq_xrx200.c 8161F: drivers/net/dsa/lantiq_pce.h --> 8162F: drivers/net/dsa/intel_gswip.c Commit that introduced this: commit 14fceff4771e51b23b4485b575cf9e5b3414b89b Author: Hauke Mehrtens Date: Sun Sep 9 22:20:39 2018 +0200 net: dsa: Add Lantiq / Intel DSA driver for vrx200 This adds the DSA driver for the GSWIP Switch found in the VRX200 SoC. This switch is integrated in the DSL SoC, this SoC uses a GSWIP version 2.1, there are other SoCs using different versions of this IP block, but this driver was only tested with the version found in the VRX200. Currently only the basic features are implemented which will forward all packages to the CPU and let the CPU do the forwarding. The hardware also support Layer 2 offloading which is not yet implemented in this driver. The GPHY FW loaded is now done by this driver and not any more by the separate driver in drivers/soc/lantiq/gphy.c, I will remove this driver is a separate patch. to make use of the GPHY this switch driver is needed anyway. Other SoCs have more embedded GPHYs so this driver should support a variable number of GPHYs. After the firmware was loaded the GPHY can be probed on the MDIO bus and it behaves like an external GPHY, without the firmware it can not be probed on the MDIO bus. The clock names in the sysctrl.c file have to be changed because the clocks are now used by a different driver. This should be cleaned up and a real common clock driver should provide the clocks instead. Signed-off-by: Hauke Mehrtens Signed-off-by: David S. Miller MAINTAINERS |2 + arch/mips/lantiq/xway/sysctrl.c |8 +- drivers/net/dsa/Kconfig |8 + drivers/net/dsa/Makefile|1 + drivers/net/dsa/lantiq_gswip.c | 1169 +++ drivers/net/dsa/lantiq_pce.h| 153 + 6 files changed, 1337 insertions(+), 4 deletions(-) No commit with drivers/net/dsa/intel_gswip.c found
Re: [PATCH] fix memory leak in ramoops_init
On Fri, Sep 28, 2018 at 2:26 PM, Andrew Morton wrote: > On Mon, 17 Sep 2018 17:15:31 +0800 nixiaoming wrote: > >> 1, memory leak in ramoops_register_dummy. >>dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL); >>but no free when platform_device_register_data return fail >> >> 2, if kzalloc(sizeof(*dummy_data), GFP_KERNEL) return NULL, >> but platform_driver_register(_driver) return 0 >>kfree(NULL) in ramoops_exit >> so, add return val for ramoops_register_dummy, and check it in ramoops_init >> >> 3, memory leak in ramoops_init. >>miss platform_device_unregister(dummy) and kfree(dummy_data) >>when platform_driver_register(_driver) return fail > > Looks right. > > It's unclear (to me) who maintains fs/pstore/ram.c. Let's add some > Cc's and see if we can catch a reviewed-by. It's me: PSTORE FILESYSTEM M: Kees Cook M: Anton Vorontsov M: Colin Cross M: Tony Luck S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/pstore F: fs/pstore/ F: include/linux/pstore* F: drivers/firmware/efi/efi-pstore.c F: drivers/acpi/apei/erst.c F: Documentation/admin-guide/ramoops.rst F: Documentation/devicetree/bindings/reserved-memory/ramoops.txt K: \b(pstore|ramoops) I'll take review it and take it via the pstore tree. Thanks! -Kees -- Kees Cook Pixel Security
Re: [PATCH] mailbox: Convert to using %pOFn instead of device_node.name
On Mon, Aug 27, 2018 at 8:54 PM Rob Herring wrote: > > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. > > Cc: Jassi Brar > Signed-off-by: Rob Herring > --- > drivers/mailbox/ti-msgmgr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Ping. > > diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c > index 5bceafbf6699..713d701b6568 100644 > --- a/drivers/mailbox/ti-msgmgr.c > +++ b/drivers/mailbox/ti-msgmgr.c > @@ -560,8 +560,8 @@ static struct mbox_chan *ti_msgmgr_of_xlate(struct > mbox_controller *mbox, > } > > err: > - dev_err(inst->dev, "Queue ID %d, Proxy ID %d is wrong on %s\n", > - req_qid, req_pid, p->np->name); > + dev_err(inst->dev, "Queue ID %d, Proxy ID %d is wrong on %pOFn\n", > + req_qid, req_pid, p->np); > return ERR_PTR(-ENOENT); > } > > -- > 2.17.1 >
Bad MAINTAINERS pattern in section 'LOCKING PRIMITIVES'
Please fix this defect appropriately. linux-next MAINTAINERS section: 8566LOCKING PRIMITIVES 8567M: Peter Zijlstra 8568M: Ingo Molnar 8569M: Will Deacon 8570L: linux-kernel@vger.kernel.org 8571T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core 8572S: Maintained 8573F: Documentation/locking/ 8574F: include/linux/lockdep.h 8575F: include/linux/spinlock*.h 8576F: arch/*/include/asm/spinlock*.h 8577F: include/linux/rwlock*.h 8578F: include/linux/mutex*.h --> 8579F: arch/*/include/asm/mutex*.h 8580F: include/linux/rwsem*.h 8581F: arch/*/include/asm/rwsem.h 8582F: include/linux/seqlock.h 8583F: lib/locking*.[ch] 8584F: kernel/locking/ 8585X: kernel/locking/locktorture.c Commit that introduced this: commit d4c3be70ca0e7a1ae308bedd3462900c61e97b11 Author: Ingo Molnar Date: Thu Jun 9 12:20:25 2016 +0200 MAINTAINERS: Update locking tree description and file patterns Update the file patterns, the Git tree URI and also widen the scope from 'LOCKDEP and LOCKSTAT' to 'LOCKING PRIMITIVES'. Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Andrew Morton Cc: Thomas Gleixner Cc: Paul E. McKenney Cc: linux-kernel@vger.kernel.org MAINTAINERS | 16 1 file changed, 12 insertions(+), 4 deletions(-) Last commit with arch/*/include/asm/mutex*.h commit 890658b7ab48d1362a0362df842cecc73c83146f Author: Peter Zijlstra Date: Tue Aug 23 13:36:04 2016 +0200 locking/mutex: Kill arch specific code Its all generic atomic_long_t stuff now. Tested-by: Jason Low Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-a...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar arch/alpha/include/asm/mutex.h | 9 --- arch/arc/include/asm/mutex.h| 18 - arch/arm/include/asm/mutex.h| 21 -- arch/arm64/include/asm/Kbuild | 1 - arch/avr32/include/asm/mutex.h | 9 --- arch/blackfin/include/asm/Kbuild| 1 - arch/c6x/include/asm/mutex.h| 6 -- arch/cris/include/asm/mutex.h | 9 --- arch/frv/include/asm/mutex.h| 9 --- arch/h8300/include/asm/mutex.h | 9 --- arch/hexagon/include/asm/mutex.h| 8 --- arch/ia64/include/asm/mutex.h | 90 arch/m32r/include/asm/mutex.h | 9 --- arch/m68k/include/asm/Kbuild| 1 - arch/metag/include/asm/Kbuild | 1 - arch/microblaze/include/asm/mutex.h | 1 - arch/mips/include/asm/Kbuild| 1 - arch/mn10300/include/asm/mutex.h| 16 - arch/nios2/include/asm/mutex.h | 1 - arch/openrisc/include/asm/mutex.h | 27 arch/parisc/include/asm/Kbuild | 1 - arch/powerpc/include/asm/mutex.h| 132 arch/s390/include/asm/mutex.h | 9 --- arch/score/include/asm/mutex.h | 6 -- arch/sh/include/asm/mutex-llsc.h| 109 - arch/sh/include/asm/mutex.h | 12 arch/sparc/include/asm/Kbuild | 1 - arch/tile/include/asm/Kbuild| 1 - arch/um/include/asm/Kbuild | 1 - arch/unicore32/include/asm/mutex.h | 20 -- arch/x86/include/asm/mutex.h| 5 -- arch/x86/include/asm/mutex_32.h | 110 -- arch/x86/include/asm/mutex_64.h | 127 -- arch/xtensa/include/asm/mutex.h | 9 --- include/asm-generic/mutex-dec.h | 88 include/asm-generic/mutex-null.h| 19 -- include/asm-generic/mutex-xchg.h| 120 include/asm-generic/mutex.h | 9 --- 38 files changed, 1026 deletions(-)
Bad MAINTAINERS pattern in section 'KEYS/KEYRINGS:'
Please fix this defect appropriately. linux-next MAINTAINERS section: 8087KEYS/KEYRINGS: 8088M: David Howells 8089L: keyri...@vger.kernel.org 8090S: Maintained 8091F: Documentation/security/keys/core.rst 8092F: include/linux/key.h 8093F: include/linux/key-type.h --> 8094F: include/linux/keyctl.h 8095F: include/uapi/linux/keyctl.h 8096F: include/keys/ 8097F: security/keys/ Commit that introduced this: commit 7683e9e529258d01ce99216ad3be21f59eff83ec Author: Linus Torvalds Date: Sun Jul 23 16:06:21 2017 -0700 Properly alphabetize MAINTAINERS file This adds a perl script to actually parse the MAINTAINERS file, clean up some whitespace in it, warn about errors in it, and then properly sort the end result. My perl-fu is atrocious, so the script has basically been created by randomly putting various characters in a pile, mixing them around, and then looking it the end result does anything interesting when used as a perl script. Signed-off-by: Linus Torvalds MAINTAINERS | 3585 +- scripts/parse-maintainers.pl | 77 + 2 files changed, 1868 insertions(+), 1794 deletions(-) Last commit with include/linux/keyctl.h commit 607ca46e97a1b6594b29647d98a32d545c24bdff Author: David Howells Date: Sat Oct 13 10:46:48 2012 +0100 UAPI: (Scripted) Disintegrate include/linux Signed-off-by: David Howells Acked-by: Arnd Bergmann Acked-by: Thomas Gleixner Acked-by: Michael Kerrisk Acked-by: Paul E. McKenney Acked-by: Dave Jones include/linux/Kbuild | 379 - include/linux/a.out.h | 196 +-- include/linux/acct.h | 108 +- include/linux/adb.h | 39 +- include/linux/adfs_fs.h | 42 +- include/linux/agpgart.h | 86 +- include/linux/apm_bios.h | 125 +- include/linux/atalk.h | 43 +- include/linux/atm.h | 238 +-- include/linux/atm_tcp.h | 54 +- include/linux/atmdev.h| 213 +-- include/linux/audit.h | 381 + include/linux/auto_fs.h | 68 +- include/linux/auxvec.h| 33 +- include/linux/binfmts.h | 19 +- include/linux/blktrace_api.h | 142 +- include/linux/bsg.h | 63 +- include/linux/capability.h| 346 + include/linux/cciss_ioctl.h | 86 +- include/linux/cdrom.h | 902 +-- include/linux/cm4000_cs.h | 60 +- include/linux/cn_proc.h | 103 +- include/linux/coda.h | 680 + include/linux/coda_psdev.h| 26 +- include/linux/connector.h | 56 +- include/linux/cramfs_fs.h | 86 +- include/linux/cuda.h | 25 +- include/linux/cyclades.h | 426 +- include/linux/dccp.h | 236 +-- include/linux/dlm.h | 62 +- include/linux/dlm_plock.h | 37 +- include/linux/edd.h | 158 +- include/linux/elf.h | 414 + include/linux/elfcore.h | 102 +- include/linux/errno.h |5 +- include/linux/errqueue.h | 25 +- include/linux/ethtool.h | 1076 + include/linux/eventpoll.h | 53 +- include/linux/falloc.h|7 +- include/linux/fanotify.h | 114 +- include/linux/fb.h| 403 + include/linux/fcntl.h | 50 +- include/linux/fd.h| 380 + include/linux/filter.h| 133 +- include/linux/flat.h | 50 +- include/linux/fs.h| 333 + include/linux/fsl_hypervisor.h| 180 +-- include/linux/futex.h | 150 +- include/linux/gameport.h | 26 +- include/linux/genetlink.h | 82 +- include/linux/hdlc.h | 13 +- include/linux/hdlcdrv.h | 104 +- include/linux/hid.h | 46 +- include/linux/hiddev.h| 190 +-- include/linux/hidraw.h| 40 +-
Bad MAINTAINERS pattern in section 'KEYS/KEYRINGS:'
Please fix this defect appropriately. linux-next MAINTAINERS section: 8087KEYS/KEYRINGS: 8088M: David Howells 8089L: keyri...@vger.kernel.org 8090S: Maintained 8091F: Documentation/security/keys/core.rst 8092F: include/linux/key.h 8093F: include/linux/key-type.h --> 8094F: include/linux/keyctl.h 8095F: include/uapi/linux/keyctl.h 8096F: include/keys/ 8097F: security/keys/ Commit that introduced this: commit 7683e9e529258d01ce99216ad3be21f59eff83ec Author: Linus Torvalds Date: Sun Jul 23 16:06:21 2017 -0700 Properly alphabetize MAINTAINERS file This adds a perl script to actually parse the MAINTAINERS file, clean up some whitespace in it, warn about errors in it, and then properly sort the end result. My perl-fu is atrocious, so the script has basically been created by randomly putting various characters in a pile, mixing them around, and then looking it the end result does anything interesting when used as a perl script. Signed-off-by: Linus Torvalds MAINTAINERS | 3585 +- scripts/parse-maintainers.pl | 77 + 2 files changed, 1868 insertions(+), 1794 deletions(-) Last commit with include/linux/keyctl.h commit 607ca46e97a1b6594b29647d98a32d545c24bdff Author: David Howells Date: Sat Oct 13 10:46:48 2012 +0100 UAPI: (Scripted) Disintegrate include/linux Signed-off-by: David Howells Acked-by: Arnd Bergmann Acked-by: Thomas Gleixner Acked-by: Michael Kerrisk Acked-by: Paul E. McKenney Acked-by: Dave Jones include/linux/Kbuild | 379 - include/linux/a.out.h | 196 +-- include/linux/acct.h | 108 +- include/linux/adb.h | 39 +- include/linux/adfs_fs.h | 42 +- include/linux/agpgart.h | 86 +- include/linux/apm_bios.h | 125 +- include/linux/atalk.h | 43 +- include/linux/atm.h | 238 +-- include/linux/atm_tcp.h | 54 +- include/linux/atmdev.h| 213 +-- include/linux/audit.h | 381 + include/linux/auto_fs.h | 68 +- include/linux/auxvec.h| 33 +- include/linux/binfmts.h | 19 +- include/linux/blktrace_api.h | 142 +- include/linux/bsg.h | 63 +- include/linux/capability.h| 346 + include/linux/cciss_ioctl.h | 86 +- include/linux/cdrom.h | 902 +-- include/linux/cm4000_cs.h | 60 +- include/linux/cn_proc.h | 103 +- include/linux/coda.h | 680 + include/linux/coda_psdev.h| 26 +- include/linux/connector.h | 56 +- include/linux/cramfs_fs.h | 86 +- include/linux/cuda.h | 25 +- include/linux/cyclades.h | 426 +- include/linux/dccp.h | 236 +-- include/linux/dlm.h | 62 +- include/linux/dlm_plock.h | 37 +- include/linux/edd.h | 158 +- include/linux/elf.h | 414 + include/linux/elfcore.h | 102 +- include/linux/errno.h |5 +- include/linux/errqueue.h | 25 +- include/linux/ethtool.h | 1076 + include/linux/eventpoll.h | 53 +- include/linux/falloc.h|7 +- include/linux/fanotify.h | 114 +- include/linux/fb.h| 403 + include/linux/fcntl.h | 50 +- include/linux/fd.h| 380 + include/linux/filter.h| 133 +- include/linux/flat.h | 50 +- include/linux/fs.h| 333 + include/linux/fsl_hypervisor.h| 180 +-- include/linux/futex.h | 150 +- include/linux/gameport.h | 26 +- include/linux/genetlink.h | 82 +- include/linux/hdlc.h | 13 +- include/linux/hdlcdrv.h | 104 +- include/linux/hid.h | 46 +- include/linux/hiddev.h| 190 +-- include/linux/hidraw.h| 40 +-
