Re: [PATCH 3/4] y2038: time: Introduce struct __kernel_old_timeval
> +extern struct __kernel_old_timeval ns_to_kernel_old_timeval(const s64 nsec);
Generally there's no need to mark arguments with arithmethic types as const, as
they are never modified in the calling scope.
> + * legacy timeval structure, only embedded in structures that
> + * traditionally used 'timeval' to pass time intervals (not absolute
> + * times). Do not add new users. If user space fails to compile
> + * here, this is probably because it is not y2038 safe and needs to
> + * be changed to use another interface.
> + */
> +struct __kernel_old_timeval {
> + __kernel_long_t tv_sec; /* seconds */
> + __kernel_long_t tv_usec;/* seconds */
s/seconds/microseconds
> +struct __kernel_old_timeval ns_to_kernel_old_timeval(const s64 nsec)
> +{
> + struct timespec64 ts = ns_to_timespec64(nsec);
> + struct __kernel_old_timeval tv;
> +
> + tv.tv_sec = ts.tv_sec;
> + tv.tv_usec = (suseconds_t) ts.tv_nsec / 1000;
Is ts.tv_nsec guaranteed to never have bits set in the high 32 bits?
In any case, the space before the type cast is a bit confusing to me, I think
it
should be written as:
tv.tv_usec = (suseconds_t)ts.tv_nsec / 1000;
To better show was the higher precedence of the cast is going to result in.
Thanks,
Ingo
Re: [PATCH 0/4] ARM: sunxi: Clean and improvements for multi-cluster SMP
On Thu, Mar 8, 2018 at 11:00 PM, Chen-Yu Tsai wrote: > Hi, > > This series is a bit of cleanup and improvement for the new > multi-cluster SMP code for Allwinner A80 and A83T (soon) SoCs. > > The first patch is just a typo fix. > > The second and third patch add the use of the "enable-method" cpu > property to enable SMP, instead of matching against the machine > compatible. However, due to how init calls are sequenced, we still > need to use a platform early_init call. > > The last patch splits out parts of the SoC-specific init code, i.e. > the device node matching parts. This should help with Mylene's work > on adding support for the A83T. > > Please have a look. > > Regards > ChenYu > > Chen-Yu Tsai (4): > ARM: sunxi: mc-smp: Fix "lookback" typo > ARM: sunxi: mc-smp: Use DT enable-method for sun9i A80 SMP > ARM: dts: sun9i: Add enable-method for SMP support for the A80 SoC > ARM: sunxi: mc-smp: Split out SoC-specific device node lookup sequence Merged all 4 patches. ChenYu
Re: [RFC PATCH -tip 8/9] error-injection: Fix to not enabling preemption in pre_handler
* Masami Hiramatsu wrote: > Since kprobes pre_handler doesn't need to recover preemption > even if it modifies regs->ip anymore, this fixes to remove > the preempt_enable_no_resched() from pre_handler. > > Signed-off-by: Masami Hiramatsu > --- > kernel/fail_function.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/kernel/fail_function.c b/kernel/fail_function.c > index 21b0122cb39c..b1713521f096 100644 > --- a/kernel/fail_function.c > +++ b/kernel/fail_function.c > @@ -176,7 +176,6 @@ static int fei_kprobe_handler(struct kprobe *kp, struct > pt_regs *regs) > override_function_with_return(regs); > /* Kprobe specific fixup */ > reset_current_kprobe(); > - preempt_enable_no_resched(); > return 1; > } So where did the matching preempt_disable() get removed? If it's the 6/9 patch, then this patch (and 8/9) should very much be part of it. There should be no bisection breakage in the series. Thanks, Ingo
Re: [RFC PATCH -tip 0/9] kprobes: Cleanup jprobe implementation
* Masami Hiramatsu wrote: > Hello, > > Since we decided to remove jprobe from kernel last year, > its APIs are disabled and we worked on moving in-kernel > jprobe users to kprobes or trace-events. And now no jprobe > users are here anymore. > > I think it is good time to get rid of jprobe implementation > from the kernel. However, I need other arch developers help > to complete it, since jprobe is implemented multi arch wide. > I can remove those code, but can not test all of those. > > Here is the series of patches to show how to do that. > I tried to remove it from x86 tree. Basically we need to > do 3 things; > > - Remove jprobe functions (register/unregister, >setjump/longjump) from generic/arch-dependent code. >[1/9][2/9][3/9] > - Remove break_handler related code. >[4/9][5/9][6/9] > - Do not disable preemption on exception handler >[7/9][8/9][9/9] > > The [3/9] and [6/9] are destractive changes except for x86 > (means causes build errors) since those arch still have some > references of those functions. So we need to write patches > similar to [2/9] and [5/9] for each arch before applying those. > In this series I sorted it as this order just for review, > [3/9] and [6/9] should be applied after all archs have > been fixed. > > Also, [7/9] is a kind of destractive, which changes required > behavior for the pre_handlers which changes regs->ip. > So we also need a patch similar to [7/9] for each arch too. > Fortunately, current in-tree such user is very limited, both > works only on x86. So it is not hurry, but we need to change > arch dependent code. > > Thank you, > > --- > > Masami Hiramatsu (9): > kprobes: Remove jprobe API implementation > x86: kprobes: Remove jprobe implementation > kprobes: Remove jprobe data structure and interfaces > kprobes: Ignore break_handler > x86: kprobes: Ignore break_handler > kprobes: Remove break_handler from struct kprobe > x86: kprobes: Do not disable preempt on int3 path > error-injection: Fix to not enabling preemption in pre_handler > tracing: kprobes: Fix to not enabling preemption > > > Documentation/kprobes.txt| 13 ++-- > arch/x86/include/asm/kprobes.h |3 - > arch/x86/kernel/kprobes/common.h | 10 --- > arch/x86/kernel/kprobes/core.c | 114 > ++ > arch/x86/kernel/kprobes/ftrace.c | 21 +-- > arch/x86/kernel/kprobes/opt.c|1 > include/linux/kprobes.h | 54 -- > kernel/fail_function.c |1 > kernel/kprobes.c | 115 > ++ > kernel/trace/trace_kprobe.c |3 - > 10 files changed, 20 insertions(+), 315 deletions(-) Nice work, and I love the diffstat, but please do a series that works (builds and boots and has working kprobes) at every interim step. Thanks, Ingo
[PATCH v2 8/8] tpm: move tpm2 code validation to tpm2-space.c
Add new function tpm2_validate_command to tpm2-space.c
that wraps up open coded functionality from tpm_validate_command.
Signed-off-by: Tomas Winkler
---
drivers/char/tpm/tpm-interface.c | 31 ++-
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm2-cmd.c | 1 +
drivers/char/tpm/tpm2-space.c| 32
4 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index d347ad8325c6..93f7c12d4c4d 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -52,40 +52,13 @@ static int tpm_validate_command(struct tpm_chip *chip,
const u8 *cmd,
size_t len)
{
- const struct tpm_input_header *header = (const void *)cmd;
- int i;
- u32 cc;
- u32 attrs;
- unsigned int nr_handles;
-
if (len < TPM_HEADER_SIZE)
return -EINVAL;
- if (!space)
- return 0;
-
- if (chip->flags & TPM_CHIP_FLAG_TPM2 && chip->nr_commands) {
- cc = be32_to_cpu(header->ordinal);
-
- i = tpm2_find_cc(chip, cc);
- if (i < 0) {
- dev_dbg(&chip->dev, "0x%04X is an invalid command\n",
- cc);
- return -EOPNOTSUPP;
- }
-
- attrs = chip->cc_attrs_tbl[i];
- nr_handles =
- 4 * ((attrs >> TPM2_CC_ATTR_CHANDLES) & GENMASK(2, 0));
- if (len < TPM_HEADER_SIZE + 4 * nr_handles)
- goto err_len;
- }
+ if (chip->flags & TPM_CHIP_FLAG_TPM2 && space)
+ return tpm2_validate_command(chip, cmd, len);
return 0;
-err_len:
- dev_dbg(&chip->dev,
- "%s: insufficient command length %zu", __func__, len);
- return -EINVAL;
}
static int tpm_request_locality(struct tpm_chip *chip)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 2b88aadc4743..15453a78a0d0 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -602,6 +602,7 @@ int tpm2_prepare_space(struct tpm_chip *chip, struct
tpm_space *space, u32 cc,
u8 *cmd);
int tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
u32 cc, u8 *buf, size_t *bufsiz);
+int tpm2_validate_command(struct tpm_chip *chip, const u8 *cmd, size_t len);
extern const struct seq_operations tpm2_binary_b_measurements_seqops;
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 80eb4bb5feef..6db13cf801b4 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -1112,3 +1112,4 @@ int tpm2_find_cc(struct tpm_chip *chip, u32 cc)
return -1;
}
+
diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
index 4e4014eabdb9..ed9eff948c05 100644
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -263,6 +263,38 @@ static int tpm2_map_command(struct tpm_chip *chip, u32 cc,
u8 *cmd)
return 0;
}
+int tpm2_validate_command(struct tpm_chip *chip, const u8 *cmd, size_t len)
+{
+ int i;
+ u32 cc;
+ u32 attrs;
+ unsigned int nr_handles;
+
+ if (len < TPM_HEADER_SIZE)
+ return -EINVAL;
+
+ if (!chip->nr_commands)
+ return 0;
+
+ cc = be32_to_cpup((__be32 *)(cmd + 6));
+
+ i = tpm2_find_cc(chip, cc);
+ if (i < 0) {
+ dev_dbg(&chip->dev, "0x%04X is an invalid command\n", cc);
+ return -EOPNOTSUPP;
+ }
+
+ attrs = chip->cc_attrs_tbl[i];
+ nr_handles = 4 * ((attrs >> TPM2_CC_ATTR_CHANDLES) & GENMASK(2, 0));
+ if (len < TPM_HEADER_SIZE + 4 * nr_handles) {
+ dev_dbg(&chip->dev,
+ "%s: insufficient command length %zu", __func__, len);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int tpm2_prepare_space(struct tpm_chip *chip, struct tpm_space *space, u32 cc,
u8 *cmd)
{
--
2.14.3
[PATCH v2 6/8] tpm: factor out tpm_startup function
tpm manual startup is used only from within tpm1 or tpm2
code, hence remove tpm_startup function from tpm-interface.c
and add two static functions implementations tpm1_startup
and tpm2_startup into to tpm1-cmd.c and tpm2-cmd.c respectively.
Signed-off-by: Tomas Winkler
---
drivers/char/tpm/tpm-interface.c | 41
drivers/char/tpm/tpm.h | 1 -
drivers/char/tpm/tpm1-cmd.c | 37 +++-
drivers/char/tpm/tpm2-cmd.c | 34 +++--
4 files changed, 68 insertions(+), 45 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 11899ef32457..90e14462500a 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -313,47 +313,6 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct
tpm_space *space,
}
EXPORT_SYMBOL_GPL(tpm_transmit_cmd);
-#define TPM_ORD_STARTUP 153
-#define TPM_ST_CLEAR 1
-
-/**
- * tpm_startup - turn on the TPM
- * @chip: TPM chip to use
- *
- * Normally the firmware should start the TPM. This function is provided as a
- * workaround if this does not happen. A legal case for this could be for
- * example when a TPM emulator is used.
- *
- * Return: same as tpm_transmit_cmd()
- */
-int tpm_startup(struct tpm_chip *chip)
-{
- struct tpm_buf buf;
- int rc;
-
- dev_info(&chip->dev, "starting up the TPM manually\n");
-
- if (chip->flags & TPM_CHIP_FLAG_TPM2) {
- rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_STARTUP);
- if (rc < 0)
- return rc;
-
- tpm_buf_append_u16(&buf, TPM2_SU_CLEAR);
- } else {
- rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_STARTUP);
- if (rc < 0)
- return rc;
-
- tpm_buf_append_u16(&buf, TPM_ST_CLEAR);
- }
-
- rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
- "attempting to start the TPM");
-
- tpm_buf_destroy(&buf);
- return rc;
-}
-
int tpm_get_timeouts(struct tpm_chip *chip)
{
if (chip->flags & TPM_CHIP_FLAG_HAVE_TIMEOUTS)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 1bed9b5441c5..434f11c23e3e 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -526,7 +526,6 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct
tpm_space *space,
void *buf, size_t bufsiz,
size_t min_rsp_body_length, unsigned int flags,
const char *desc);
-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);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index e2c9f609fe64..85dd0fcbd4cc 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -307,6 +307,40 @@ unsigned long tpm1_calc_ordinal_duration(struct tpm_chip
*chip, u32 ordinal)
}
EXPORT_SYMBOL_GPL(tpm1_calc_ordinal_duration);
+#define TPM_ORD_STARTUP 153
+#define TPM_ST_CLEAR 1
+
+/**
+ * tpm_startup - turn on the TPM
+ * @chip: TPM chip to use
+ *
+ * Normally the firmware should start the TPM. This function is provided as a
+ * workaround if this does not happen. A legal case for this could be for
+ * example when a TPM emulator is used.
+ *
+ * Return: same as tpm_transmit_cmd()
+ */
+static int tpm1_startup(struct tpm_chip *chip)
+{
+ struct tpm_buf buf;
+ int rc;
+
+ dev_info(&chip->dev, "starting up the TPM manually\n");
+
+ rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_STARTUP);
+ if (rc < 0)
+ return rc;
+
+ tpm_buf_append_u16(&buf, TPM_ST_CLEAR);
+
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
+ "attempting to start the TPM");
+
+ tpm_buf_destroy(&buf);
+
+ return rc;
+}
+
int tpm1_get_timeouts(struct tpm_chip *chip)
{
cap_t cap;
@@ -316,7 +350,7 @@ int tpm1_get_timeouts(struct tpm_chip *chip)
rc = tpm1_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap, NULL,
sizeof(cap.timeout));
if (rc == TPM_ERR_INVALID_POSTINIT) {
- if (tpm_startup(chip))
+ if (tpm1_startup(chip))
return rc;
rc = tpm1_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap,
@@ -719,3 +753,4 @@ int tpm1_pm_suspend(struct tpm_chip *chip, int
tpm_suspend_pcr)
return rc;
}
+
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 8114fd59e2c5..07636aa6f1a9 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -1006,6 +1006,36 @@ static int tpm2_get_cc_attrs_tbl(struct tpm_chip *chip)
return rc;
}
+/**
+ * tpm2_startup - turn on the TPM
+ * @chip: TPM chip to use
+ *
+ * Normally the firmware shoul
[PATCH v2 1/8] tpm: move tpm1_pcr_extend to tpm1-cmd.c
Move tpm1_pcr_extend to tpm1-cmd.c and remove
unused pcrextend_header structure.
Signed-off-by: Tomas Winkler
---
drivers/char/tpm/tpm-interface.c | 28
drivers/char/tpm/tpm.h | 2 ++
drivers/char/tpm/tpm1-cmd.c | 23 +++
3 files changed, 25 insertions(+), 28 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 7f6968b750c8..83eeefb2a4af 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -514,34 +514,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(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_EXTEND);
- if (rc)
- return rc;
-
- tpm_buf_append_u32(&buf, pcr_idx);
- tpm_buf_append(&buf, 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(&buf);
- return rc;
-}
-
/**
* tpm_pcr_extend - extend a PCR value in SHA1 bank.
* @chip: a &struct tpm_chip instance, %NULL for the default chip
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 48706f091856..4306c878f1d9 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -535,6 +535,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);
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 14dfb2b9a067..6a0d8717fdf6 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -414,3 +414,26 @@ int tpm1_get_timeouts(struct tpm_chip *chip)
chip->flags |= TPM_CHIP_FLAG_HAVE_TIMEOUTS;
return 0;
}
+
+#define TPM_ORD_PCR_EXTEND 20
+#define EXTEND_PCR_RESULT_SIZE 34
+#define EXTEND_PCR_RESULT_BODY_SIZE 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(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_EXTEND);
+ if (rc)
+ return rc;
+
+ tpm_buf_append_u32(&buf, pcr_idx);
+ tpm_buf_append(&buf, 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(&buf);
+ return rc;
+}
+
--
2.14.3
[PATCH v2 4/8] tpm: move tpm1 selftest code from tpm-interface tpm1-cmd.c
Move the tmp1 selftest code functions to tpm1-cmd.c
and adjust callers to use the new function names.
1. tpm_pcr_read_dev to tpm1_pcr_read_dev
2. tpm_continue_selftest to tpm1_continue_selftest
3. tpm_do_selftest to tpm1_do_selftest
Signed-off-by: Tomas Winkler
---
drivers/char/tpm/st33zp24/st33zp24.c | 2 +-
drivers/char/tpm/tpm-interface.c | 144 +--
drivers/char/tpm/tpm-sysfs.c | 2 +-
drivers/char/tpm/tpm.h | 4 +-
drivers/char/tpm/tpm1-cmd.c | 139 +
drivers/char/tpm/tpm_tis_core.c | 2 +-
6 files changed, 147 insertions(+), 146 deletions(-)
diff --git a/drivers/char/tpm/st33zp24/st33zp24.c
b/drivers/char/tpm/st33zp24/st33zp24.c
index ad03c99899fa..575b7c2eab25 100644
--- a/drivers/char/tpm/st33zp24/st33zp24.c
+++ b/drivers/char/tpm/st33zp24/st33zp24.c
@@ -651,7 +651,7 @@ int st33zp24_pm_resume(struct device *dev)
} else {
ret = tpm_pm_resume(dev);
if (!ret)
- tpm_do_selftest(chip);
+ tpm1_do_selftest(chip);
}
return ret;
} /* st33zp24_pm_resume() */
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 59ca2e30b4d2..a7dfe286b343 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -366,59 +366,6 @@ int tpm_get_timeouts(struct tpm_chip *chip)
}
EXPORT_SYMBOL_GPL(tpm_get_timeouts);
-#define TPM_ORD_CONTINUE_SELFTEST 83
-#define CONTINUE_SELFTEST_RESULT_SIZE 10
-
-static const struct tpm_input_header continue_selftest_header = {
- .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
- .length = cpu_to_be32(10),
- .ordinal = cpu_to_be32(TPM_ORD_CONTINUE_SELFTEST),
-};
-
-/**
- * tpm_continue_selftest -- run TPM's selftest
- * @chip: TPM chip to use
- *
- * Returns 0 on success, < 0 in case of fatal error or a value > 0 representing
- * a TPM error code.
- */
-static int tpm_continue_selftest(struct tpm_chip *chip)
-{
- int rc;
- struct tpm_cmd_t cmd;
-
- cmd.header.in = continue_selftest_header;
- rc = tpm_transmit_cmd(chip, NULL, &cmd, CONTINUE_SELFTEST_RESULT_SIZE,
- 0, 0, "continue selftest");
- return rc;
-}
-
-#define TPM_ORDINAL_PCRREAD 21
-#define READ_PCR_RESULT_SIZE 30
-#define READ_PCR_RESULT_BODY_SIZE 20
-static const struct tpm_input_header pcrread_header = {
- .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
- .length = cpu_to_be32(14),
- .ordinal = cpu_to_be32(TPM_ORDINAL_PCRREAD)
-};
-
-int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
-{
- int rc;
- struct tpm_cmd_t cmd;
-
- cmd.header.in = pcrread_header;
- cmd.params.pcrread_in.pcr_idx = cpu_to_be32(pcr_idx);
- rc = tpm_transmit_cmd(chip, NULL, &cmd, READ_PCR_RESULT_SIZE,
- READ_PCR_RESULT_BODY_SIZE, 0,
- "attempting to read a pcr value");
-
- if (rc == 0)
- memcpy(res_buf, cmd.params.pcrread_out.pcr_result,
- TPM_DIGEST_SIZE);
- return rc;
-}
-
/**
* tpm_is_tpm2 - do we a have a TPM2 chip?
* @chip: a &struct tpm_chip instance, %NULL for the default chip
@@ -459,10 +406,12 @@ int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx, u8
*res_buf)
chip = tpm_chip_find_get(chip);
if (!chip)
return -ENODEV;
+
if (chip->flags & TPM_CHIP_FLAG_TPM2)
rc = tpm2_pcr_read(chip, pcr_idx, res_buf);
else
- rc = tpm_pcr_read_dev(chip, pcr_idx, res_buf);
+ rc = tpm1_pcr_read_dev(chip, pcr_idx, res_buf);
+
tpm_put_ops(chip);
return rc;
}
@@ -513,93 +462,6 @@ int tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx,
const u8 *hash)
}
EXPORT_SYMBOL_GPL(tpm_pcr_extend);
-/**
- * tpm_do_selftest - have the TPM continue its selftest and wait until it
- * can receive further commands
- * @chip: TPM chip to use
- *
- * Returns 0 on success, < 0 in case of fatal error or a value > 0 representing
- * a TPM error code.
- */
-int tpm_do_selftest(struct tpm_chip *chip)
-{
- int rc;
- unsigned int loops;
- unsigned int delay_msec = 100;
- unsigned long duration;
- u8 dummy[TPM_DIGEST_SIZE];
-
- duration = tpm1_calc_ordinal_duration(chip, TPM_ORD_CONTINUE_SELFTEST);
-
- loops = jiffies_to_msecs(duration) / delay_msec;
-
- rc = tpm_continue_selftest(chip);
- /* This may fail if there was no TPM driver during a suspend/resume
-* cycle; some may return 10 (BAD_ORDINAL), others 28 (FAILEDSELFTEST)
-*/
- if (rc)
- return rc;
-
- do {
- /* Attempt to read a PCR value */
- rc = tpm_pcr_read_dev(chip, 0, dummy);
-
- /* Some buggy TPMs will not respond to tpm_tis_ready() for
-* arou
[PATCH v2 5/8] tpm: factor out tpm1 pm suspend flow into tpm1-cmd.c
Factor out tpm1 suspend flow from tpm-interface.c into a new function
tpm1_pm_suspend in tpm1-cmd.c
Signed-off-by: Tomas Winkler
---
drivers/char/tpm/tpm-interface.c | 55
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm1-cmd.c | 54 +++
3 files changed, 60 insertions(+), 50 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index a7dfe286b343..11899ef32457 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -485,15 +485,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.
@@ -501,54 +492,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;
+ int rc = 0;
- u8 dummy_hash[TPM_DIGEST_SIZE] = { 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, &cmd, 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(&chip->dev,
- "Error (%d) sending savestate before suspend\n", rc);
- else if (try > 0)
- dev_warn(&chip->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 6922fdfc4274..1bed9b5441c5 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -529,6 +529,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 6dde18c46820..e2c9f609fe64 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -665,3 +665,57 @@ 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)
+};
+
+/*
+ * We are about to suspend. Save the TPM state
+ * so that it can be restored.
+ */
+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 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++) {
[PATCH v2 2/8] 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.
Signed-off-by: Tomas Winkler
---
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 83eeefb2a4af..6b70cefed505 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -354,52 +354,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(&buf, 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(&buf, subcap_id);
- tpm_buf_append_u32(&buf, 0);
- } else {
- if (subcap_id == TPM_CAP_FLAG_PERM ||
- subcap_id == TPM_CAP_FLAG_VOL)
- tpm_buf_append_u32(&buf, TPM_CAP_FLAG);
- else
- tpm_buf_append_u32(&buf, TPM_CAP_PROP);
-
- tpm_buf_append_u32(&buf, 4);
- tpm_buf_append_u32(&buf, subcap_id);
- }
- rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE,
- min_cap_length, 0, desc);
- if (!rc)
- *cap = *(cap_t *)&buf.data[TPM_HEADER_SIZE + 4];
-
- tpm_buf_destroy(&buf);
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_getcap);
-
int tpm_get_timeouts(struct tpm_chip *chip)
{
if (chip->flags & TPM_CHIP_FLAG_HAVE_TIMEOUTS)
@@ -753,6 +707,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, &cap,
- "attempting to determine the number of PCRS",
- sizeof(cap.num_pcrs));
+ rc = tpm1_getcap(chip, TPM_CAP_PROP_PCR, &cap,
+"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, &cap,
- "attempting to determine the permanent enabled state",
- sizeof(cap.perm_flags));
+ rc = tpm1_getcap(to_tpm_chip(dev), TPM_CAP_FLAG_PERM, &cap,
+"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, &cap,
- "attempting to determine the permanent active state",
- sizeof(cap.perm_flags));
+ rc = tpm1_getcap(to_tpm_chip(dev), TPM_CAP_FLAG_PERM, &cap,
+"attempting to determine the permanent active state",
+sizeof(cap.perm_flags));
if (rc)
return 0;
@@ -166,9 +166,9 @@ static ssize_t owned_show(struct device *dev, struct
device_attribute *attr,
cap_t cap;
ssize_t rc;
- rc = tpm_getcap(to_tpm_chip(dev), TPM_CAP_PROP_OWNER, &cap,
- "attempting to determine the owner state",
- sizeof(cap.owned)
[PATCH v2 7/8] tpm: Move pcr extend to tpm2-cmd.c
Add tpm2_pcr_extend function to tpm2-cmd.c with signature required
by tpm-interface.c. It wraps the original open code
implementation. The original original tpm2_pcr_extend function
is renamed and made static, called only from new tpm2_pcr_extend.
Signed-off-by: Tomas Winkler
---
drivers/char/tpm/tpm-interface.c | 25 +
drivers/char/tpm/tpm.h | 3 +--
drivers/char/tpm/tpm2-cmd.c | 25 +++--
3 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 90e14462500a..d347ad8325c6 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -391,31 +391,16 @@ EXPORT_SYMBOL_GPL(tpm_pcr_read);
int tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash)
{
int rc;
- struct tpm2_digest digest_list[ARRAY_SIZE(chip->active_banks)];
- u32 count = 0;
- int i;
chip = tpm_chip_find_get(chip);
if (!chip)
return -ENODEV;
- if (chip->flags & TPM_CHIP_FLAG_TPM2) {
- memset(digest_list, 0, sizeof(digest_list));
-
- for (i = 0; i < ARRAY_SIZE(chip->active_banks) &&
- chip->active_banks[i] != TPM2_ALG_ERROR; i++) {
- digest_list[i].alg_id = chip->active_banks[i];
- memcpy(digest_list[i].digest, hash, TPM_DIGEST_SIZE);
- count++;
- }
-
- rc = tpm2_pcr_extend(chip, pcr_idx, count, digest_list);
- tpm_put_ops(chip);
- return rc;
- }
-
- rc = tpm1_pcr_extend(chip, pcr_idx, hash,
-"attempting extend a PCR value");
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ rc = tpm2_pcr_extend(chip, pcr_idx, hash);
+ else
+ rc = tpm1_pcr_extend(chip, pcr_idx, hash,
+"attempting extend a PCR value");
tpm_put_ops(chip);
return rc;
}
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 434f11c23e3e..2b88aadc4743 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -578,8 +578,7 @@ static inline u32 tpm2_rc_value(u32 rc)
int tpm2_get_timeouts(struct tpm_chip *chip);
int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
-int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32 count,
- struct tpm2_digest *digests);
+int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash);
int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max);
void tpm2_flush_context_cmd(struct tpm_chip *chip, u32 handle,
unsigned int flags);
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 07636aa6f1a9..80eb4bb5feef 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -223,8 +223,8 @@ struct tpm2_null_auth_area {
*
* Return: Same as with tpm_transmit_cmd.
*/
-int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32 count,
- struct tpm2_digest *digests)
+static int __tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32 count,
+struct tpm2_digest *digests)
{
struct tpm_buf buf;
struct tpm2_null_auth_area auth_area;
@@ -270,6 +270,27 @@ int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx,
u32 count,
return rc;
}
+int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash)
+{
+ int rc;
+ struct tpm2_digest digest_list[ARRAY_SIZE(chip->active_banks)];
+ u32 count = 0;
+ int i;
+
+ memset(digest_list, 0, sizeof(digest_list));
+
+ for (i = 0; i < ARRAY_SIZE(chip->active_banks); i++) {
+ if (chip->active_banks[i] == TPM2_ALG_ERROR)
+ break;
+ digest_list[i].alg_id = chip->active_banks[i];
+ memcpy(digest_list[i].digest, hash, TPM_DIGEST_SIZE);
+ count++;
+ }
+
+ rc = __tpm2_pcr_extend(chip, pcr_idx, count, digest_list);
+ return rc;
+}
+
#define TPM2_GETRANDOM_IN_SIZE \
(sizeof(struct tpm_input_header) + \
--
2.14.3
[PATCH v2 0/8] tpm: factor out tpm1 code into tpm1-cmd.c
Move TPM1 implementation from tpm-interface.c to tpm1-cmd.c
similarly to tpm2-cmd.c, as well as move TPM2 open code flows
into new functions to tpm2-cmd.c
The functions in tpm-interface.c should now be in form:
int tpm_func(struct tpm_chip *chip)
{
if (chip->flags & TPM_CHIP_FLAG_TPM2)
return tpm2_func(chip);
else
return tpm1_func(chip);
}
This is work in progress of possible dropping compiling out one tpm 1.x or tpm
2.x in case
not needed on a target platform.
V2: 1. This resend includes more patches that cleans the tpm-interface.c
completely
2. Fix notorious typo tmp -> tpm, in some patches
Tomas Winkler (8):
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 tpm1 selftest code from tpm-interface tpm1-cmd.c
tpm: factor out tpm1 pm suspend flow into tpm1-cmd.c
tpm: factor out tpm_startup function
tpm: Move pcr extend to tpm2-cmd.c
tpm: move tpm2 code validation to tpm2-space.c
drivers/char/tpm/st33zp24/st33zp24.c | 2 +-
drivers/char/tpm/tpm-interface.c | 425 ++-
drivers/char/tpm/tpm-sysfs.c | 50 ++---
drivers/char/tpm/tpm.h | 18 +-
drivers/char/tpm/tpm1-cmd.c | 358 -
drivers/char/tpm/tpm2-cmd.c | 60 -
drivers/char/tpm/tpm2-space.c| 32 +++
drivers/char/tpm/tpm_tis_core.c | 4 +-
8 files changed, 496 insertions(+), 453 deletions(-)
--
2.14.3
[PATCH v2 3/8] tpm: factor out tpm1_get_random into tpm1-cmd.c
Factor out get random implementation from tpm-interface.c
into tpm1_get_random function in tpm1-cmd.c.
No functional changes.
Signed-off-by: Tomas Winkler
---
drivers/char/tpm/tpm-interface.c | 56
drivers/char/tpm/tpm.h | 2 ++
drivers/char/tpm/tpm1-cmd.c | 54 ++
3 files changed, 61 insertions(+), 51 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 6b70cefed505..59ca2e30b4d2 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -707,14 +707,6 @@ 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),
- .length = cpu_to_be32(14),
- .ordinal = cpu_to_be32(TPM_ORD_GET_RANDOM)
-};
-
/**
* tpm_get_random() - get random bytes from the TPM's RNG
* @chip: a &struct tpm_chip instance, %NULL for the default chip
@@ -725,57 +717,19 @@ static const struct tpm_input_header tpm_getrandom_header
= {
*/
int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max)
{
- struct tpm_cmd_t tpm_cmd;
- u32 recd, num_bytes = min_t(u32, max, TPM_MAX_RNG_DATA), rlength;
- int err, total = 0, retries = 5;
- u8 *dest = out;
-
- if (!out || !num_bytes || max > TPM_MAX_RNG_DATA)
- return -EINVAL;
+ int err;
chip = tpm_chip_find_get(chip);
if (!chip)
return -ENODEV;
- if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
err = tpm2_get_random(chip, out, max);
- tpm_put_ops(chip);
- return err;
- }
-
- 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, &tpm_cmd,
- TPM_GETRANDOM_RESULT_SIZE + num_bytes,
- offsetof(struct tpm_getrandom_out,
- rng_data),
- 0, "attempting get random");
- if (err)
- break;
-
- recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
- if (recd > num_bytes) {
- total = -EFAULT;
- break;
- }
-
- rlength = be32_to_cpu(tpm_cmd.header.out.length);
- if (rlength < offsetof(struct tpm_getrandom_out, rng_data) +
- recd) {
- total = -EFAULT;
- break;
- }
- memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);
-
- dest += recd;
- total += recd;
- num_bytes -= recd;
- } while (retries-- && total < max);
+ else
+ err = tpm1_get_random(chip, out, max);
tpm_put_ops(chip);
- return total ? total : -EIO;
+ return err;
}
EXPORT_SYMBOL_GPL(tpm_get_random);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 1a8ef4d3cb1c..b5fe0269a833 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -537,6 +537,8 @@ int tpm1_pcr_extend(struct tpm_chip *chip, int pcr_idx,
const u8 *hash,
const char *log_msg);
ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
const char *desc, size_t min_cap_length);
+int tpm1_get_random(struct tpm_chip *chip, u8 *out, size_t max);
+
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 903352542192..5b310cf26a56 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -472,3 +472,57 @@ ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id,
cap_t *cap,
return rc;
}
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)
+};
+
+int tpm1_get_random(struct tpm_chip *chip, u8 *out, size_t max)
+{
+ struct tpm_cmd_t tpm_cmd;
+ u32 recd;
+ u32 num_bytes = min_t(u32, max, TPM_MAX_RNG_DATA);
+ u32 rlength;
+ int err, total = 0, retries = 5;
+ u8 *dest = out;
+
+ if (!out || !num_bytes || max > TPM_MAX_RNG_DATA)
+ return -EINVAL;
+
+ do {
+ tpm_cmd.header.in = tpm_getrandom_header;
+ tpm_cmd.params.getrandom_in.num_bytes =
Re: [PATCH v2] net: ipv6: xfrm6_state: remove VLA usage
On Sat, 10 Mar 2018 09:40:44 +0200
Andreas Christoforou wrote:
> diff --git a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c
> index b15075a..270a53a 100644
> --- a/net/ipv6/xfrm6_state.c
> +++ b/net/ipv6/xfrm6_state.c
> @@ -62,7 +62,7 @@ __xfrm6_sort(void **dst, void **src, int n, int (*cmp)(void
> *p), int maxclass)
> {
> int i;
> int class[XFRM_MAX_DEPTH];
> - int count[maxclass];
> + int count[XFRM_MAX_DEPTH];
>
> memset(count, 0, sizeof(count));
Can you perhaps initialize 'count' instead of calling memset(), now?
--
Stefano
[PATCH 1/2] seq_file: allocate seq_file from kmem_cache
For fine-grained debugging and usercopy protection.
Signed-off-by: Alexey Dobriyan
---
fs/seq_file.c| 12 ++--
include/linux/seq_file.h |1 +
init/main.c |1 +
3 files changed, 12 insertions(+), 2 deletions(-)
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -6,6 +6,7 @@
* initial implementation -- AV, Oct 2001.
*/
+#include
#include
#include
#include
@@ -19,6 +20,8 @@
#include
#include
+static struct kmem_cache *seq_file_cache __ro_after_init;
+
static void seq_set_overflow(struct seq_file *m)
{
m->count = m->size;
@@ -51,7 +54,7 @@ int seq_open(struct file *file, const struct seq_operations
*op)
WARN_ON(file->private_data);
- p = kzalloc(sizeof(*p), GFP_KERNEL);
+ p = kmem_cache_zalloc(seq_file_cache, GFP_KERNEL);
if (!p)
return -ENOMEM;
@@ -366,7 +369,7 @@ int seq_release(struct inode *inode, struct file *file)
{
struct seq_file *m = file->private_data;
kvfree(m->buf);
- kfree(m);
+ kmem_cache_free(seq_file_cache, m);
return 0;
}
EXPORT_SYMBOL(seq_release);
@@ -1106,3 +1109,8 @@ seq_hlist_next_percpu(void *v, struct hlist_head __percpu
*head,
return NULL;
}
EXPORT_SYMBOL(seq_hlist_next_percpu);
+
+void __init seq_file_init(void)
+{
+ seq_file_cache = KMEM_CACHE(seq_file, SLAB_PANIC);
+}
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -240,4 +240,5 @@ extern struct hlist_node *seq_hlist_start_percpu(struct
hlist_head __percpu *hea
extern struct hlist_node *seq_hlist_next_percpu(void *v, struct hlist_head
__percpu *head, int *cpu, loff_t *pos);
+void seq_file_init(void);
#endif
--- a/init/main.c
+++ b/init/main.c
@@ -696,6 +696,7 @@ asmlinkage __visible void __init start_kernel(void)
vfs_caches_init();
pagecache_init();
signals_init();
+ seq_file_init();
proc_root_init();
nsfs_init();
cpuset_init();
[PATCH 2/2] seq_file: account everything
All it takes to open a file and read 1 byte from it.
seq_file will be allocated along with any private allocations,
and more importantly seq file buffer which is 1 page by default.
Signed-off-by: Alexey Dobriyan
---
fs/seq_file.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -29,7 +29,7 @@ static void seq_set_overflow(struct seq_file *m)
static void *seq_buf_alloc(unsigned long size)
{
- return kvmalloc(size, GFP_KERNEL);
+ return kvmalloc(size, GFP_KERNEL_ACCOUNT);
}
/**
@@ -566,7 +566,7 @@ static void single_stop(struct seq_file *p, void *v)
int single_open(struct file *file, int (*show)(struct seq_file *, void *),
void *data)
{
- struct seq_operations *op = kmalloc(sizeof(*op), GFP_KERNEL);
+ struct seq_operations *op = kmalloc(sizeof(*op), GFP_KERNEL_ACCOUNT);
int res = -ENOMEM;
if (op) {
@@ -628,7 +628,7 @@ void *__seq_open_private(struct file *f, const struct
seq_operations *ops,
void *private;
struct seq_file *seq;
- private = kzalloc(psize, GFP_KERNEL);
+ private = kzalloc(psize, GFP_KERNEL_ACCOUNT);
if (private == NULL)
goto out;
@@ -1112,5 +1112,5 @@ EXPORT_SYMBOL(seq_hlist_next_percpu);
void __init seq_file_init(void)
{
- seq_file_cache = KMEM_CACHE(seq_file, SLAB_PANIC);
+ seq_file_cache = KMEM_CACHE(seq_file, SLAB_ACCOUNT|SLAB_PANIC);
}
Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework
On Saturday, March 10, 2018 8:41:39 AM CET Doug Smythies wrote: > On 2018.03.09 07:19 Rik van Riel wrote: > > On Fri, 2018-03-09 at 10:34 +0100, Rafael J. Wysocki wrote: > >> Hi All, > >> > >> Thanks a lot for the discussion and testing so far! > >> > >> This is a total respin of the whole series, so please look at it > >> afresh. > >> Patches 2 and 3 are the most similar to their previous versions, but > >> still they are different enough. > > > > This series gives no RCU errors on startup, > > and no CPUs seem to be getting stuck any more. > > Confirmed on my test server. Boot is normal and no other errors, so far. Thanks for testing, much appreciated! > Part 1: Idle test: > > I was able to repeat Mike's higher power issue under very light load, > well no load in my case, with V2. > > V3 is much better. > > A one hour trace on my very idle server was 22 times smaller with V3 > than V2, and mainly due to idle state 4 not exiting and re-entering > every tick time for great periods of time. > > Disclaimer: From past experience, 1 hour is not nearly long enough > for this test. Issues tend to come in bunches, sometimes many hours > apart. > > V2: > Idle State 4: Entries: 1359560 > CPU: 0: Entries: 125305 > CPU: 1: Entries: 62489 > CPU: 2: Entries: 10203 > CPU: 3: Entries: 108107 > CPU: 4: Entries: 19915 > CPU: 5: Entries: 430253 > CPU: 6: Entries: 564650 > CPU: 7: Entries: 38638 > > V3: > Idle State 4: Entries: 64505 > CPU: 0: Entries: 13060 > CPU: 1: Entries: 5266 > CPU: 2: Entries: 15744 > CPU: 3: Entries: 5574 > CPU: 4: Entries: 8425 > CPU: 5: Entries: 6270 > CPU: 6: Entries: 5592 > CPU: 7: Entries: 4574 > > Kernel 4.16-rc4: > Idle State 4: Entries: 61390 > CPU: 0: Entries: 9529 > CPU: 1: Entries: 10556 > CPU: 2: Entries: 5478 > CPU: 3: Entries: 5991 > CPU: 4: Entries: 3686 > CPU: 5: Entries: 7610 > CPU: 6: Entries: 11074 > CPU: 7: Entries: 7466 > > With apologies to those that do not like the term "PowerNightmares", OK, and what exactly do you count as "PowerNightmares"? > it has become very ingrained in my tools: > > V2: > 1 hour idle Summary: > > Idle State 0: Total Entries: 113 : PowerNightmares: 56 : Not PN time > (seconds): 0.001224 : PN time: 65.543239 : Ratio: 53548.397792 > Idle State 1: Total Entries: 1015 : PowerNightmares: 42 : Not PN time > (seconds): 0.053986 : PN time: 21.054470 : Ratio: 389.998703 > Idle State 2: Total Entries: 1382 : PowerNightmares: 17 : Not PN time > (seconds): 0.728686 : PN time: 6.046906 : Ratio: 8.298370 > Idle State 3: Total Entries: 113 : PowerNightmares: 13 : Not PN time > (seconds): 0.069055 : PN time: 6.021458 : Ratio: 87.198002 The V2 had a serious bug, please discard it entirely. > > V3: > 1 hour idle Summary: Average processor package power 3.78 watts > > Idle State 0: Total Entries: 134 : PowerNightmares: 109 : Not PN time > (seconds): 0.000477 : PN time: 144.719723 : Ratio: 303395.646541 > Idle State 1: Total Entries: 1104 : PowerNightmares: 84 : Not PN time > (seconds): 0.052639 : PN time: 74.639142 : Ratio: 1417.943768 > Idle State 2: Total Entries: 968 : PowerNightmares: 141 : Not PN time > (seconds): 0.325953 : PN time: 128.235137 : Ratio: 393.416035 > Idle State 3: Total Entries: 295 : PowerNightmares: 103 : Not PN time > (seconds): 0.164884 : PN time: 97.159421 : Ratio: 589.259243 > > Kernel 4.16-rc4: Average processor package power (excluding a few minutes of > abnormal power) 3.70 watts. > 1 hour idle Summary: > > Idle State 0: Total Entries: 168 : PowerNightmares: 59 : Not PN time > (seconds): 0.001323 : PN time: 81.802197 : Ratio: 61830.836545 > Idle State 1: Total Entries: 1669 : PowerNightmares: 78 : Not PN time > (seconds): 0.022003 : PN time: 37.477413 : Ratio: 1703.286509 > Idle State 2: Total Entries: 1447 : PowerNightmares: 30 : Not PN time > (seconds): 0.502672 : PN time: 0.789344 : Ratio: 1.570296 > Idle State 3: Total Entries: 176 : PowerNightmares: 0 : Not PN time > (seconds): 0.259425 : PN time: 0.00 : Ratio: 0.00 > > Part 2: 100% load on one CPU test. Test duration 4 hours > > V3: Summary: Average processor package power 26.75 watts > > Idle State 0: Total Entries: 10039 : PowerNightmares: 7186 : Not PN time > (seconds): 0.067477 : PN time: 6215.220295 : Ratio: 92108.722903 > Idle State 1: Total Entries: 17268 : PowerNightmares: 195 : Not PN time > (seconds): 0.213049 : PN time: 55.905323 : Ratio: 262.405939 > Idle State 2: Total Entries: 5858 : PowerNightmares: 676 : Not PN time > (seconds): 2.578006 : PN time: 167.282069 : Ratio: 64.888161 > Idle State 3: Total Entries: 1500 : PowerNightmares: 488 : Not PN time > (seconds): 0.772463 : PN time: 125.514015 : Ratio: 162.485472 > > Kernel 4.16-rc4: Summary: Average processor package power 27.41 watts > > Idle State 0: Total Entries: 9096 : PowerNightmares: 6540 : Not PN time > (seconds): 0.051532 : PN time: 7886.309553 : Ratio: 153037.133492 > Idle State 1: Total Entries: 28731 : PowerNightmares: 215 : Not PN time > (seconds): 0.211
Re: [RFC/RFT][PATCH v3 0/6] sched/cpuidle: Idle loop rework
On Saturday, March 10, 2018 6:01:31 AM CET Mike Galbraith wrote: > On Fri, 2018-03-09 at 10:34 +0100, Rafael J. Wysocki wrote: > > Hi All, > > > > Thanks a lot for the discussion and testing so far! > > > > This is a total respin of the whole series, so please look at it afresh. > > Patches 2 and 3 are the most similar to their previous versions, but > > still they are different enough. > > Respin of testdrive... Appreciated, thanks! > i4790 booted nopti nospectre_v2 > > 30 sec tbench > 4.16.0.g1b88acc-master (virgin) > Throughput 559.279 MB/sec 1 clients 1 procs max_latency=0.046 ms > Throughput 997.119 MB/sec 2 clients 2 procs max_latency=0.246 ms > Throughput 1693.04 MB/sec 4 clients 4 procs max_latency=4.309 ms > Throughput 3597.2 MB/sec 8 clients 8 procs max_latency=6.760 ms > Throughput 3474.55 MB/sec 16 clients 16 procs max_latency=6.743 ms > > 4.16.0.g1b88acc-master (+ v2) > Throughput 588.929 MB/sec 1 clients 1 procs max_latency=0.291 ms > Throughput 1080.93 MB/sec 2 clients 2 procs max_latency=0.639 ms > Throughput 1826.3 MB/sec 4 clients 4 procs max_latency=0.647 ms > Throughput 3561.01 MB/sec 8 clients 8 procs max_latency=1.279 ms > Throughput 3382.98 MB/sec 16 clients 16 procs max_latency=4.817 ms > > 4.16.0.g1b88acc-master (+ v3) > Throughput 588.711 MB/sec 1 clients 1 procs max_latency=0.067 ms > Throughput 1077.71 MB/sec 2 clients 2 procs max_latency=0.298 ms This is a bit better than "raw". Around 8-9% I'd say. > Throughput 1803.47 MB/sec 4 clients 4 procs max_latency=0.667 ms This one is too, but not as much. > Throughput 3591.4 MB/sec 8 clients 8 procs max_latency=4.999 ms > Throughput 3444.74 MB/sec 16 clients 16 procs max_latency=1.995 ms And these are slightly worse, but just slightly. > 4.16.0.g1b88acc-master (+ my local patches) > Throughput 722.559 MB/sec 1 clients 1 procs max_latency=0.087 ms > Throughput 1208.59 MB/sec 2 clients 2 procs max_latency=0.289 ms > Throughput 2071.94 MB/sec 4 clients 4 procs max_latency=0.654 ms > Throughput 3784.91 MB/sec 8 clients 8 procs max_latency=0.974 ms > Throughput 3644.4 MB/sec 16 clients 16 procs max_latency=5.620 ms > > turbostat -q -- firefox /root/tmp/video/BigBuckBunny-DivXPlusHD.mkv & sleep > 300;killall firefox > > PkgWatt > 1 2 3 > 4.16.0.g1b88acc-master 6.95 7.03 6.91 (virgin) > 4.16.0.g1b88acc-master 7.20 7.25 7.26 (+v2) > 4.16.0.g1b88acc-master 7.04 6.97 7.07 (+v3) > 4.16.0.g1b88acc-master 6.90 7.06 6.95 (+my patches) > > No change wrt nohz high frequency cross core scheduling overhead, but > the light load power consumption oddity did go away. OK > (btw, don't read anything into max_latency numbers, that's GUI noise) I see. Thanks!
[tip:timers/core] timekeeping/ntp: Don't align NTP frequency adjustments to ticks
Commit-ID: c2cda2a5bda9f1369c9d1ab54a20571c13cf2743
Gitweb: https://git.kernel.org/tip/c2cda2a5bda9f1369c9d1ab54a20571c13cf2743
Author: Miroslav Lichvar
AuthorDate: Fri, 9 Mar 2018 10:42:47 -0800
Committer: Ingo Molnar
CommitDate: Sat, 10 Mar 2018 09:12:41 +0100
timekeeping/ntp: Don't align NTP frequency adjustments to ticks
When the timekeeping multiplier is changed, the NTP error is updated to
correct the clock for the delay between the tick and the update of the
clock. This error is corrected in later updates and the clock appears as
if the frequency was changed exactly on the tick.
Remove this correction to keep the point where the frequency is
effectively changed at the time of the update. This removes a major
source of the NTP error.
Signed-off-by: Miroslav Lichvar
Signed-off-by: John Stultz
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Prarit Bhargava
Cc: Richard Cochran
Cc: Stephen Boyd
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1520620971-9567-2-git-send-email-john.stu...@linaro.org
Signed-off-by: Ingo Molnar
---
kernel/time/timekeeping.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index cd03317e7b57..c1a0ac17336e 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1860,8 +1860,6 @@ static __always_inline void
timekeeping_apply_adjustment(struct timekeeper *tk,
* xtime_nsec_2 = xtime_nsec_1 - offset
* Which simplfies to:
* xtime_nsec -= offset
-*
-* XXX - TODO: Doc ntp_error calculation.
*/
if ((mult_adj > 0) && (tk->tkr_mono.mult + mult_adj < mult_adj)) {
/* NTP adjustment caused clocksource mult overflow */
@@ -1872,7 +1870,6 @@ static __always_inline void
timekeeping_apply_adjustment(struct timekeeper *tk,
tk->tkr_mono.mult += mult_adj;
tk->xtime_interval += interval;
tk->tkr_mono.xtime_nsec -= offset;
- tk->ntp_error -= (interval - offset) << tk->ntp_error_shift;
}
/*
[tip:timers/core] timekeeping/ntp: Determine the multiplier directly from NTP tick length
Commit-ID: 78b98e3c5a66d569a53b8f57b6a698f912794a43
Gitweb: https://git.kernel.org/tip/78b98e3c5a66d569a53b8f57b6a698f912794a43
Author: Miroslav Lichvar
AuthorDate: Fri, 9 Mar 2018 10:42:48 -0800
Committer: Ingo Molnar
CommitDate: Sat, 10 Mar 2018 09:12:41 +0100
timekeeping/ntp: Determine the multiplier directly from NTP tick length
When the length of the NTP tick changes significantly, e.g. when an
NTP/PTP application is correcting the initial offset of the clock, a
large value may accumulate in the NTP error before the multiplier
converges to the correct value. It may then take a very long time (hours
or even days) before the error is corrected. This causes the clock to
have an unstable frequency offset, which has a negative impact on the
stability of synchronization with precise time sources (e.g. NTP/PTP
using hardware timestamping or the PTP KVM clock).
Use division to determine the correct multiplier directly from the NTP
tick length and replace the iterative approach. This removes the last
major source of the NTP error. The only remaining source is now limited
resolution of the multiplier, which is corrected by adding 1 to the
multiplier when the system clock is behind the NTP time.
Signed-off-by: Miroslav Lichvar
Signed-off-by: John Stultz
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Prarit Bhargava
Cc: Richard Cochran
Cc: Stephen Boyd
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1520620971-9567-3-git-send-email-john.stu...@linaro.org
Signed-off-by: Ingo Molnar
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 138
2 files changed, 49 insertions(+), 91 deletions(-)
diff --git a/include/linux/timekeeper_internal.h
b/include/linux/timekeeper_internal.h
index d315c3d6725c..7acb953298a7 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -117,6 +117,8 @@ struct timekeeper {
s64 ntp_error;
u32 ntp_error_shift;
u32 ntp_err_mult;
+ /* Flag used to avoid updating NTP twice with same second */
+ u32 skip_second_overflow;
#ifdef CONFIG_DEBUG_TIMEKEEPING
longlast_warning;
/*
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index c1a0ac17336e..e11760121cb2 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -332,6 +332,7 @@ static void tk_setup_internals(struct timekeeper *tk,
struct clocksource *clock)
tk->tkr_mono.mult = clock->mult;
tk->tkr_raw.mult = clock->mult;
tk->ntp_err_mult = 0;
+ tk->skip_second_overflow = 0;
}
/* Timekeeper helper functions. */
@@ -1799,20 +1800,19 @@ device_initcall(timekeeping_init_ops);
*/
static __always_inline void timekeeping_apply_adjustment(struct timekeeper *tk,
s64 offset,
-bool negative,
-int adj_scale)
+s32 mult_adj)
{
s64 interval = tk->cycle_interval;
- s32 mult_adj = 1;
- if (negative) {
- mult_adj = -mult_adj;
+ if (mult_adj == 0) {
+ return;
+ } else if (mult_adj == -1) {
interval = -interval;
- offset = -offset;
+ offset = -offset;
+ } else if (mult_adj != 1) {
+ interval *= mult_adj;
+ offset *= mult_adj;
}
- mult_adj <<= adj_scale;
- interval <<= adj_scale;
- offset <<= adj_scale;
/*
* So the following can be confusing.
@@ -1873,85 +1873,35 @@ static __always_inline void
timekeeping_apply_adjustment(struct timekeeper *tk,
}
/*
- * Calculate the multiplier adjustment needed to match the frequency
- * specified by NTP
+ * Adjust the timekeeper's multiplier to the correct frequency
+ * and also to reduce the accumulated error value.
*/
-static __always_inline void timekeeping_freqadjust(struct timekeeper *tk,
- s64 offset)
+static void timekeeping_adjust(struct timekeeper *tk, s64 offset)
{
- s64 interval = tk->cycle_interval;
- s64 xinterval = tk->xtime_interval;
- u32 base = tk->tkr_mono.clock->mult;
- u32 max = tk->tkr_mono.clock->maxadj;
- u32 cur_adj = tk->tkr_mono.mult;
- s64 tick_error;
- bool negative;
- u32 adj_scale;
-
- /* Remove any current error adj from freq calculation */
- if (tk->ntp_err_mult)
- xinterval -= tk->cycle_interval;
-
- tk->ntp_tick = ntp_tick_length();
-
- /* Calculate current error per tick */
- tick_error = ntp_tick_length() >> tk->ntp_error_shift;
- tick_error -= (xinterval + tk->xtime_remainder);
-
Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it
On Sat, Mar 10, 2018 at 01:34:45AM +0100, Maciej S. Szmigiero wrote: > Currently, it is very easy to make the AMD microcode update driver crash > or spin on a malformed microcode file since it does very little > consistency checking on data loaded from such file. Sorry but if one has enough permissions to install malformed microcode, crashing the loader is the least of your problems. IOW, I don't see the justification for the unnecessary complication with all those checks. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[tip:locking/core] tools/memory-model: Remove mention of docker/gentoo image
Commit-ID: d095c12c53c7b941ad4ea96dc229a08296b37d2e Gitweb: https://git.kernel.org/tip/d095c12c53c7b941ad4ea96dc229a08296b37d2e Author: Paul E. McKenney AuthorDate: Wed, 7 Mar 2018 09:27:38 -0800 Committer: Ingo Molnar CommitDate: Sat, 10 Mar 2018 10:22:23 +0100 tools/memory-model: Remove mention of docker/gentoo image Because the docker and gentoo images haven't been updated in quite some time, they are likely to provide more confusion than help. This commit therefore removes mention of them from the README file. Reported-by: Alan Stern Signed-off-by: Paul E. McKenney Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Cc: will.dea...@arm.com Link: http://lkml.kernel.org/r/1520443660-16858-2-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/README | 15 --- 1 file changed, 15 deletions(-) diff --git a/tools/memory-model/README b/tools/memory-model/README index ea950c566ffd..0b3a5f3c9ccd 100644 --- a/tools/memory-model/README +++ b/tools/memory-model/README @@ -27,21 +27,6 @@ separately: See "herdtools7/INSTALL.md" for installation instructions. -Alternatively, Abhishek Bhardwaj has kindly provided a Docker image -of these tools at "abhishek40/memory-model". Abhishek suggests the -following commands to install and use this image: - - - Users should install Docker for their distribution. - - docker run -itd abhishek40/memory-model - - docker attach - -Gentoo users might wish to make use of Patrick McLean's package: - - https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/herdtools7 - -These packages may not be up-to-date with respect to the GitHub -repository. - == BASIC USAGE: HERD7
[tip:locking/core] locking/memory-barriers: De-emphasize smp_read_barrier_depends() some more
Commit-ID: f28f0868feb1e79b460131bac37230e303a5f6a4 Gitweb: https://git.kernel.org/tip/f28f0868feb1e79b460131bac37230e303a5f6a4 Author: Paul E. McKenney AuthorDate: Wed, 7 Mar 2018 09:27:37 -0800 Committer: Ingo Molnar CommitDate: Sat, 10 Mar 2018 10:22:22 +0100 locking/memory-barriers: De-emphasize smp_read_barrier_depends() some more This commit makes further changes to memory-barrier.txt to further de-emphasize smp_read_barrier_depends(), but leaving some discussion for historical purposes. Signed-off-by: Paul E. McKenney Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Cc: st...@rowland.harvard.edu Cc: will.dea...@arm.com Link: http://lkml.kernel.org/r/1520443660-16858-1-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- Documentation/memory-barriers.txt | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index da6525bdc3f5..6dafc8085acc 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -52,7 +52,7 @@ CONTENTS - Varieties of memory barrier. - What may not be assumed about memory barriers? - - Data dependency barriers. + - Data dependency barriers (historical). - Control dependencies. - SMP barrier pairing. - Examples of memory barrier sequences. @@ -554,8 +554,15 @@ There are certain things that the Linux kernel memory barriers do not guarantee: Documentation/DMA-API.txt -DATA DEPENDENCY BARRIERS - +DATA DEPENDENCY BARRIERS (HISTORICAL) +- + +As of v4.15 of the Linux kernel, an smp_read_barrier_depends() was +added to READ_ONCE(), which means that about the only people who +need to pay attention to this section are those working on DEC Alpha +architecture-specific code and those working on READ_ONCE() itself. +For those who need it, and for those who are interested in the history, +here is the story of data-dependency barriers. The usage requirements of data dependency barriers are a little subtle, and it's not always obvious that they're needed. To illustrate, consider the @@ -2843,8 +2850,9 @@ as that committed on CPU 1. To intervene, we need to interpolate a data dependency barrier or a read -barrier between the loads. This will force the cache to commit its coherency -queue before processing any further requests: +barrier between the loads (which as of v4.15 is supplied unconditionally +by the READ_ONCE() macro). This will force the cache to commit its +coherency queue before processing any further requests: CPU 1 CPU 2 COMMENT === === === @@ -2873,8 +2881,8 @@ Other CPUs may also have split caches, but must coordinate between the various cachelets for normal memory accesses. The semantics of the Alpha removes the need for hardware coordination in the absence of memory barriers, which permitted Alpha to sport higher CPU clock rates back in the day. However, -please note that smp_read_barrier_depends() should not be used except in -Alpha arch-specific code and within the READ_ONCE() macro. +please note that (again, as of v4.15) smp_read_barrier_depends() should not +be used except in Alpha arch-specific code and within the READ_ONCE() macro. CACHE COHERENCY VS DMA @@ -3039,7 +3047,9 @@ the data dependency barrier really becomes necessary as this synchronises both caches with the memory coherence system, thus making it seem like pointer changes vs new data occur in the right order. -The Alpha defines the Linux kernel's memory barrier model. +The Alpha defines the Linux kernel's memory model, although as of v4.15 +the Linux kernel's addition of smp_read_barrier_depends() to READ_ONCE() +greatly reduced Alpha's impact on the memory model. See the subsection on "Cache Coherency" above.
[tip:locking/core] tools/memory-model: Add documentation of new litmus test
Commit-ID: ff1fe5e079730f138c98b268ce2e8482a1d954b4 Gitweb: https://git.kernel.org/tip/ff1fe5e079730f138c98b268ce2e8482a1d954b4 Author: Paul E. McKenney AuthorDate: Wed, 7 Mar 2018 09:27:39 -0800 Committer: Ingo Molnar CommitDate: Sat, 10 Mar 2018 10:22:23 +0100 tools/memory-model: Add documentation of new litmus test The litmus-tests/README file lacks any mention of the new litmus test ISA2+pooncelock+pooncelock+pombonce.litmus. This commit therefore adds a description of this test. Reported-by: Alan Stern Signed-off-by: Paul E. McKenney Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: aki...@gmail.com Cc: boqun.f...@gmail.com Cc: dhowe...@redhat.com Cc: j.algl...@ucl.ac.uk Cc: linux-a...@vger.kernel.org Cc: luc.maran...@inria.fr Cc: npig...@gmail.com Cc: parri.and...@gmail.com Cc: will.dea...@arm.com Link: http://lkml.kernel.org/r/1520443660-16858-3-git-send-email-paul...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- tools/memory-model/litmus-tests/README | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/memory-model/litmus-tests/README b/tools/memory-model/litmus-tests/README index dca7d823ad57..04096fb8b8d9 100644 --- a/tools/memory-model/litmus-tests/README +++ b/tools/memory-model/litmus-tests/README @@ -32,6 +32,12 @@ IRIW+poonceonces+OnceOnce.litmus order of a pair of writes, where each write is to a different variable by a different process? +ISA2+pooncelock+pooncelock+pombonce.litmus + Tests whether the ordering provided by a lock-protected S + litmus test is visible to an external process whose accesses are + separated by smp_mb(). This addition of an external process to + S is otherwise known as ISA2. + ISA2+poonceonces.litmus As below, but with store-release replaced with WRITE_ONCE() and load-acquire replaced with READ_ONCE().
[tip:locking/core] tools/memory-model: Finish the removal of rb-dep, smp_read_barrier_depends(), and lockless_dereference()
Commit-ID: bd5c0ba2cd78a4c116726ead84f8f37dc92d043e
Gitweb: https://git.kernel.org/tip/bd5c0ba2cd78a4c116726ead84f8f37dc92d043e
Author: Alan Stern
AuthorDate: Wed, 7 Mar 2018 09:27:40 -0800
Committer: Ingo Molnar
CommitDate: Sat, 10 Mar 2018 10:22:23 +0100
tools/memory-model: Finish the removal of rb-dep, smp_read_barrier_depends(),
and lockless_dereference()
Commit:
bf28ae562744 ("tools/memory-model: Remove rb-dep, smp_read_barrier_depends,
and lockless_dereference")
was merged too early, while it was still in RFC form. This patch adds in
the missing pieces.
Akira pointed out some typos in the original patch, and he noted that
cheatsheet.txt should indicate that READ_ONCE() now implies an address
dependency. Andrea suggested documenting the relationship betwwen
unsuccessful RMW operations and address dependencies.
Andrea pointed out that the macro for rcu_dereference() in linux.def
should now use the "once" annotation instead of "deref". He also
suggested that the comments should mention commit:
5a8897cc7631 ("locking/atomics/alpha: Add smp_read_barrier_depends() to
_release()/_relaxed() atomics")
... as an important precursor, and he contributed commit:
cb13b424e986 ("locking/xchg/alpha: Add unconditional memory barrier to
cmpxchg()")
which is another prerequisite.
Suggested-by: Akira Yokosawa
Suggested-by: Andrea Parri
Signed-off-by: Alan Stern
[ Fixed read_read_lock() typo reported by Akira. ]
Signed-off-by: Paul E. McKenney
Acked-by: Andrea Parri
Acked-by: Akira Yokosawa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: boqun.f...@gmail.com
Cc: dhowe...@redhat.com
Cc: j.algl...@ucl.ac.uk
Cc: linux-a...@vger.kernel.org
Cc: luc.maran...@inria.fr
Cc: npig...@gmail.com
Cc: will.dea...@arm.com
Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep,
smp_read_barrier_depends, and lockless_dereference")
Link:
http://lkml.kernel.org/r/1520443660-16858-4-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
tools/memory-model/Documentation/cheatsheet.txt | 6 +++---
tools/memory-model/Documentation/explanation.txt | 4 ++--
tools/memory-model/linux-kernel.def | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/memory-model/Documentation/cheatsheet.txt
b/tools/memory-model/Documentation/cheatsheet.txt
index 04e458acd6d4..956b1ae4aafb 100644
--- a/tools/memory-model/Documentation/cheatsheet.txt
+++ b/tools/memory-model/Documentation/cheatsheet.txt
@@ -1,11 +1,11 @@
Prior Operation Subsequent Operation
--- ---
C Self R W RWM Self R W DR DW RMW SV
- __ - - --- - - -- -- --- --
+ -- - - --- - - -- -- --- --
Store, e.g., WRITE_ONCE()Y Y
-Load, e.g., READ_ONCE() Y YY
-Unsuccessful RMW operation Y YY
+Load, e.g., READ_ONCE() Y Y YY
+Unsuccessful RMW operation Y Y YY
rcu_dereference()Y Y YY
Successful *_acquire() R Y Y Y YY Y
Successful *_release() CY YY W Y
diff --git a/tools/memory-model/Documentation/explanation.txt
b/tools/memory-model/Documentation/explanation.txt
index dae8b8cb2ad3..a727c82bd434 100644
--- a/tools/memory-model/Documentation/explanation.txt
+++ b/tools/memory-model/Documentation/explanation.txt
@@ -826,7 +826,7 @@ A-cumulative; they only affect the propagation of stores
that are
executed on C before the fence (i.e., those which precede the fence in
program order).
-read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
+rcu_read_lock(), rcu_read_unlock(), and synchronize_rcu() fences have
other properties which we discuss later.
@@ -1138,7 +1138,7 @@ final effect is that even though the two loads really are
executed in
program order, it appears that they aren't.
This could not have happened if the local cache had processed the
-incoming stores in FIFO order. In constrast, other architectures
+incoming stores in FIFO order. By contrast, other architectures
maintain at least the appearance of FIFO order.
In practice, this difficulty is solved by inserting a special fence
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index 5dfb9c7f3462..397e4e67e8c8 100644
--- a/tools/memory-model/linux-kernel.def
+++ b/tools/memory-model/linux-kernel.def
@@ -13,7 +13,7 @@ WRITE_ONCE(X,V) { __store{once}(X,V); }
smp_store_release(X,V) { __store{release}(*X,V); }
smp_load_acquire(X) __load{acq
Re: [PATCH v5 02/11] xfs, dax: introduce xfs_dax_aops
> +int dax_set_page_dirty(struct page *page)
> +{
> + /*
> + * Unlike __set_page_dirty_no_writeback that handles dirty page
> + * tracking in the page object, dax does all dirty tracking in
> + * the inode address_space in response to mkwrite faults. In the
> + * dax case we only need to worry about potentially dirty CPU
> + * caches, not dirty page cache pages to write back.
> + *
> + * This callback is defined to prevent fallback to
> + * __set_page_dirty_buffers() in set_page_dirty().
> + */
> + return 0;
> +}
Make this a generic noop_set_page_dirty maybe?
> +EXPORT_SYMBOL(dax_set_page_dirty);
> +
> +void dax_invalidatepage(struct page *page, unsigned int offset,
> + unsigned int length)
> +{
> + /*
> + * There is no page cache to invalidate in the dax case, however
> + * we need this callback defined to prevent falling back to
> + * block_invalidatepage() in do_invalidatepage().
> + */
> +}
Same here.
> +EXPORT_SYMBOL(dax_invalidatepage);
And EXPORT_SYMBOL_GPL for anything dax-related, please.
> +const struct address_space_operations xfs_dax_aops = {
> + .writepages = xfs_vm_writepages,
Please split out the DAX case from xfs_vm_writepages.
This patch should probably also split into VFS and XFS parts.
Re: [PATCH v5 10/11] xfs: prepare xfs_break_layouts() for another layout type
>
> +int
> +xfs_break_layouts(
> + struct inode*inode,
> + uint*iolock,
> + unsigned long flags)
> +{
> + struct xfs_inode*ip = XFS_I(inode);
> + uintiolock_assert = 0;
> + int ret = 0;
> +
> + if (flags & XFS_BREAK_REMOTE)
> + iolock_assert |= XFS_IOLOCK_SHARED|XFS_IOLOCK_EXCL;
> + if (flags & XFS_BREAK_MAPS)
> + iolock_assert |= XFS_MMAPLOCK_EXCL;
> +
> + ASSERT(xfs_isilocked(ip, iolock_assert));
> +
> + if (flags & XFS_BREAK_REMOTE)
> + ret = xfs_break_leased_layouts(inode, iolock);
> + return ret;
This just looks weird as hell. We already pass in what to drop/reacquire
in the iolock argument. I don't think we need another argument controlled
by the same callers to assert it.
> @@ -768,7 +790,7 @@ xfs_file_fallocate(
> struct xfs_inode*ip = XFS_I(inode);
> longerror;
> enum xfs_prealloc_flags flags = 0;
> - uintiolock = XFS_IOLOCK_EXCL;
> + uintiolock = XFS_IOLOCK_EXCL|XFS_MMAPLOCK_EXCL;
This is a behavior change that should not be in a patch titled
"prepare xfs_break_layouts() for another layout type" but in one
explicitly changing this and documenting why.
In summary: I think this should be replaced with a patch that
allows xfs_break_layouts to be called with the mmap lock held, and
change the callers that want the mmap lock to pass it with a good
explanation, and we should get rid of the XFS_BREAK_* flags here.
(need to check the next patch if there is any other good reason for
them to be added later, though).
Re: [PATCH v2] perf machine: Fix load kernel symbol with '-k' option
Hi Jiri,
On Fri, Mar 09, 2018 at 09:56:00PM +0100, Jiri Olsa wrote:
> On Fri, Mar 09, 2018 at 02:05:23PM +0800, Leo Yan wrote:
> > On Hikey arm64 octa A53 platform, when use command './perf report -v
> > -k vmlinux --stdio' it outputs below error info, and it skips to load
> > kernel symbol and doesn't print symbol for event:
> > Failed to open [kernel.kallsyms]_text, continuing without symbols.
> >
> > The regression is introduced by commit ("8c7f1bb37b29 perf machine: Move
> > kernel mmap name into struct machine"), which changes the logic for
> > machine mmap_name by removing function machine__mmap_name() and always
> > use 'machine->mmap_name'. Comparing difference between
> > machine__mmap_name() and 'machine->mmap_name', the later one includes
> > the string for specified kernel vmlinux string with option '-k' in
> > command, but the old function machine__mmap_name() ignores vmlinux
> > path string. As result, event's mmap file name doesn't match with
> > machine mmap file name anymore and it skips to load kernel symbol from
> > vmlinux file.
> >
> > To resolve this issue, this patch adds extra checking for
> > 'symbol_conf.vmlinux_name', when it has been set string so we can know
> > it includes vmlinux path string specified for option '-k'. For this
> > case it sets 'is_kernel_mmap' to true and run into flow to load kernel
> > symbol from vmlinux.
> >
> > This patch has been verified with two commands: './perf report -v
> > -k vmlinux --stdio' and './perf script -v -F cpu,event,ip,sym,symoff
> > -k vmlinux'.
> >
> > Suggested-by: Mathieu Poirier
> > Signed-off-by: Leo Yan
> > ---
> > tools/perf/util/machine.c | 15 ---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> > index 12b7427..3125871 100644
> > --- a/tools/perf/util/machine.c
> > +++ b/tools/perf/util/machine.c
> > @@ -1299,9 +1299,18 @@ static int machine__process_kernel_mmap_event(struct
> > machine *machine,
> > else
> > kernel_type = DSO_TYPE_GUEST_KERNEL;
> >
> > - is_kernel_mmap = memcmp(event->mmap.filename,
> > - machine->mmap_name,
> > - strlen(machine->mmap_name) - 1) == 0;
> > + /*
> > +* When symbol_conf.vmlinux_name is not NULL, it includes the specified
> > +* kernel vmlinux path with option '-k'. So set 'is_kernel_mmap' to
> > +* true for creating machine symbol map.
> > +*/
> > + if (symbol_conf.vmlinux_name)
> > + is_kernel_mmap = true;
> > + else
> > + is_kernel_mmap = memcmp(event->mmap.filename,
> > + machine->mmap_name,
> > + strlen(machine->mmap_name) - 1) == 0;
> > +
> > if (event->mmap.filename[0] == '/' ||
> > (!is_kernel_mmap && event->mmap.filename[0] == '[')) {
> > map = machine__findnew_module_map(machine, event->mmap.start,
>
> right, the mmap gets confused with the vmlinux path, but I wonder
> the fix should be not to include symbol_conf.vmlinux_name in the
> mmap_name like below.. untested
I tested below fixing at my side, and confirm your fixing also can
resolve this issue. After reviewing the change, it's more neat than my
own change . So you could add my test tag :)
Tested-by: Leo Yan
BTW, I have a minor comment for code refactoring, it's up to you if
need or not and if need use a new patch for refactoring, please see below
inline comment.
Thanks,
Leo Yan
> ---
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index 43fbbee409ec..f0cb72022177 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -51,15 +51,9 @@ static void machine__threads_init(struct machine *machine)
> static int machine__set_mmap_name(struct machine *machine)
> {
> if (machine__is_host(machine)) {
> - if (symbol_conf.vmlinux_name)
> - machine->mmap_name = strdup(symbol_conf.vmlinux_name);
> - else
> - machine->mmap_name = strdup("[kernel.kallsyms]");
> + machine->mmap_name = strdup("[kernel.kallsyms]");
> } else if (machine__is_default_guest(machine)) {
> - if (symbol_conf.default_guest_vmlinux_name)
> - machine->mmap_name =
> strdup(symbol_conf.default_guest_vmlinux_name);
> - else
> - machine->mmap_name = strdup("[guest.kernel.kallsyms]");
> + machine->mmap_name = strdup("[guest.kernel.kallsyms]");
> } else {
> if (asprintf(&machine->mmap_name, "[guest.kernel.kallsyms.%d]",
>machine->pid) < 0)
Do you think below format is better or not?
static int machine__set_mmap_name(struct machine *machine)
{
- if (machine__is_host(machine)) {
- if (symbol_conf.vmlinux_name)
- machine->mmap_name = strdup(symbol_conf.vmlinux_name);
-
Re: [PATCH v5 11/11] xfs, dax: introduce xfs_break_dax_layouts()
> +static int xfs_wait_dax_page(
> + atomic_t*count,
> + unsigned intmode)
> +{
Normal XFS style would be:
static int
xfs_wait_dax_page(
atomic_t*count,
unsigned intmode)
{
> + struct page *page = refcount_to_page(count);
> + struct address_space*mapping = page->mapping;
> + struct inode*inode = mapping->host;
> + struct xfs_inode*ip = XFS_I(inode);
Looks we don't really need the mapping and inode variables:
struct page *page = refcount_to_page(count);
struct xfs_inode*ip = XFS_I(page->mapping->host);
> + do {
> + if (flags & XFS_BREAK_REMOTE)
> + ret = xfs_break_leased_layouts(inode, iolock);
> + if (ret)
> + return ret;
> + if (flags & XFS_BREAK_MAPS)
> + ret = xfs_break_dax_layouts(inode, *iolock);
> + /*
> + * EBUSY indicates that we dropped locks and waited for
> + * the dax layout to be released. When that happens we
> + * need to revalidate that no new leases or pinned dax
> + * mappings have been established.
> + */
> + } while (ret == -EBUSY);
Maybe instead of the flags argument this should be a type argument
of something like
enum layout_break_reason {
BREAK_WRITE,/* write to file */
BREAK_TRUNCATE, /* truncate or hole punch */
};
as that makes the intent more clear?
[PATCH v5] Staging: iio: adis16209: Change some macro names
Make some of the macro names according to the names
given in the datasheet of the adis16209 driver and
have slight indentation in field definitions to make
them clearly different from the register addresses.
Signed-off-by: Shreeya Patel
---
Changes in v5
-Re-send the corrected patch.
drivers/staging/iio/accel/adis16209.c | 48 +--
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/iio/accel/adis16209.c
b/drivers/staging/iio/accel/adis16209.c
index d8aef9c..ed2e89f 100644
--- a/drivers/staging/iio/accel/adis16209.c
+++ b/drivers/staging/iio/accel/adis16209.c
@@ -68,21 +68,21 @@
#define ADIS16209_MSC_CTRL_ACTIVE_HIGHBIT(1)
#define ADIS16209_MSC_CTRL_DATA_RDY_DIO2 BIT(0)
-#define ADIS16209_DIAG_STAT_REG0x3C
-#define ADIS16209_DIAG_STAT_ALARM2BIT(9)
-#define ADIS16209_DIAG_STAT_ALARM1BIT(8)
-#define ADIS16209_DIAG_STAT_SELFTEST_FAIL_BIT 5
-#define ADIS16209_DIAG_STAT_SPI_FAIL_BIT 3
-#define ADIS16209_DIAG_STAT_FLASH_UPT_BIT 2
+#define ADIS16209_STAT_REG 0x3C
+#define ADIS16209_STAT_ALARM2 BIT(9)
+#define ADIS16209_STAT_ALARM1 BIT(8)
+#define ADIS16209_STAT_SELFTEST_FAIL_BIT 5
+#define ADIS16209_STAT_SPI_FAIL_BIT 3
+#define ADIS16209_STAT_FLASH_UPT_FAIL_BIT 2
/* Power supply above 3.625 V */
-#define ADIS16209_DIAG_STAT_POWER_HIGH_BIT 1
+#define ADIS16209_STAT_POWER_HIGH_BIT 1
/* Power supply below 3.15 V */
-#define ADIS16209_DIAG_STAT_POWER_LOW_BIT 0
+#define ADIS16209_STAT_POWER_LOW_BIT 0
-#define ADIS16209_GLOB_CMD_REG 0x3E
-#define ADIS16209_GLOB_CMD_SW_RESET BIT(7)
-#define ADIS16209_GLOB_CMD_CLEAR_STAT BIT(4)
-#define ADIS16209_GLOB_CMD_FACTORY_CALBIT(1)
+#define ADIS16209_CMD_REG 0x3E
+#define ADIS16209_CMD_SW_RESETBIT(7)
+#define ADIS16209_CMD_CLEAR_STAT BIT(4)
+#define ADIS16209_CMD_FACTORY_CAL BIT(1)
#define ADIS16209_ERROR_ACTIVE BIT(14)
@@ -238,29 +238,29 @@ static const struct iio_info adis16209_info = {
};
static const char * const adis16209_status_error_msgs[] = {
- [ADIS16209_DIAG_STAT_SELFTEST_FAIL_BIT] = "Self test failure",
- [ADIS16209_DIAG_STAT_SPI_FAIL_BIT] = "SPI failure",
- [ADIS16209_DIAG_STAT_FLASH_UPT_BIT] = "Flash update failed",
- [ADIS16209_DIAG_STAT_POWER_HIGH_BIT] = "Power supply above 3.625V",
- [ADIS16209_DIAG_STAT_POWER_LOW_BIT] = "Power supply below 3.15V",
+ [ADIS16209_STAT_SELFTEST_FAIL_BIT] = "Self test failure",
+ [ADIS16209_STAT_SPI_FAIL_BIT] = "SPI failure",
+ [ADIS16209_STAT_FLASH_UPT_FAIL_BIT] = "Flash update failed",
+ [ADIS16209_STAT_POWER_HIGH_BIT] = "Power supply above 3.625V",
+ [ADIS16209_STAT_POWER_LOW_BIT] = "Power supply below 3.15V",
};
static const struct adis_data adis16209_data = {
.read_delay = 30,
.msc_ctrl_reg = ADIS16209_MSC_CTRL_REG,
- .glob_cmd_reg = ADIS16209_GLOB_CMD_REG,
- .diag_stat_reg = ADIS16209_DIAG_STAT_REG,
+ .glob_cmd_reg = ADIS16209_CMD_REG,
+ .diag_stat_reg = ADIS16209_STAT_REG,
.self_test_mask = ADIS16209_MSC_CTRL_SELF_TEST_EN,
.self_test_no_autoclear = true,
.startup_delay = ADIS16209_STARTUP_DELAY_MS,
.status_error_msgs = adis16209_status_error_msgs,
- .status_error_mask = BIT(ADIS16209_DIAG_STAT_SELFTEST_FAIL_BIT) |
- BIT(ADIS16209_DIAG_STAT_SPI_FAIL_BIT) |
- BIT(ADIS16209_DIAG_STAT_FLASH_UPT_BIT) |
- BIT(ADIS16209_DIAG_STAT_POWER_HIGH_BIT) |
- BIT(ADIS16209_DIAG_STAT_POWER_LOW_BIT),
+ .status_error_mask = BIT(ADIS16209_STAT_SELFTEST_FAIL_BIT) |
+ BIT(ADIS16209_STAT_SPI_FAIL_BIT) |
+ BIT(ADIS16209_STAT_FLASH_UPT_FAIL_BIT) |
+ BIT(ADIS16209_STAT_POWER_HIGH_BIT) |
+ BIT(ADIS16209_STAT_POWER_LOW_BIT),
};
static int adis16209_probe(struct spi_device *spi)
--
2.7.4
Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated
On Wed, 7 Mar 2018 18:43:42 -0500 Paul Moore wrote: > ... and I just realized that linux-audit isn't on the To/CC line, > adding them now. > > Link to the patch is below. > > * https://marc.info/?t=15204188763&r=1&w=2 Yes...I wished I was in on the beginning of this discussion. Here's the problem. We need all tasks auditable unless specifically dismissed as uninteresting. This would be a task,never rule. The way we look at it, is if it boots with audit=1, then we know auditd is expected to run at some point. So, we need all tasks to stay auditable. If they weren't and auditd enabled auditing, then we'd need to walk the whole proctable and stab TIF_AUDIT_SYSCALL into every process in the system. It was decided that this is too ugly. So, we need them all to be auditable if there is any intent to audit. It doesn't matter if there are rules loaded or not. All processes have to stay within reach. What might be acceptable is to add one more state to audit boot variable to indicate that auditing is never expected. We currently have: disabled - which means we'll decide later, enabled, and immutable (no changes allowed). Then have calls to audit_enable or loading rules fail on that flag state so that user space can log that there is a conflict (boot vs daemon) that has to be resolved. As long as we can fail in a discoverable way, I think it would be OK to do something like this. Also, I don't think we want that to be the default state at the moment because the current default is keep all processes auditable. -Steve
[PATCH v2] Staging: iio: adis16209: Move adis16209 driver out of staging
Move the adis16209 driver out of staging directory and merge to the mainline IIO subsystem. Signed-off-by: Shreeya Patel --- Changes in v2 -Re-send the patch after having some cleanups in the file included in this patch. drivers/iio/accel/Kconfig | 12 ++ drivers/iio/accel/Makefile| 1 + drivers/iio/accel/adis16209.c | 329 ++ drivers/staging/iio/accel/Kconfig | 12 -- drivers/staging/iio/accel/Makefile| 1 - drivers/staging/iio/accel/adis16209.c | 329 -- 6 files changed, 342 insertions(+), 342 deletions(-) create mode 100644 drivers/iio/accel/adis16209.c delete mode 100644 drivers/staging/iio/accel/adis16209.c diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig index c6d9517..f95f43c 100644 --- a/drivers/iio/accel/Kconfig +++ b/drivers/iio/accel/Kconfig @@ -5,6 +5,18 @@ menu "Accelerometers" +config ADIS16209 +tristate "Analog Devices ADIS16209 Dual-Axis Digital Inclinometer and Accelerometer" +depends on SPI +select IIO_ADIS_LIB +select IIO_ADIS_LIB_BUFFER if IIO_BUFFER +help + Say Y here to build support for Analog Devices adis16209 dual-axis digital inclinometer + and accelerometer. + + To compile this driver as a module, say M here: the module will be + called adis16209. + config ADXL345 tristate diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile index 368aedb..40861b9 100644 --- a/drivers/iio/accel/Makefile +++ b/drivers/iio/accel/Makefile @@ -4,6 +4,7 @@ # # When adding new entries keep the list in alphabetical order +obj-$(CONFIG_ADIS16209) += adis16209.o obj-$(CONFIG_ADXL345) += adxl345_core.o obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o diff --git a/drivers/iio/accel/adis16209.c b/drivers/iio/accel/adis16209.c new file mode 100644 index 000..ed2e89f --- /dev/null +++ b/drivers/iio/accel/adis16209.c @@ -0,0 +1,329 @@ +/* + * ADIS16209 Dual-Axis Digital Inclinometer and Accelerometer + * + * Copyright 2010 Analog Devices Inc. + * + * Licensed under the GPL-2 or later. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define ADIS16209_STARTUP_DELAY_MS 220 +#define ADIS16209_FLASH_CNT_REG0x00 + +/* Data Output Register Definitions */ +#define ADIS16209_SUPPLY_OUT_REG 0x02 +#define ADIS16209_XACCL_OUT_REG0x04 +#define ADIS16209_YACCL_OUT_REG0x06 +/* Output, auxiliary ADC input */ +#define ADIS16209_AUX_ADC_REG 0x08 +/* Output, temperature */ +#define ADIS16209_TEMP_OUT_REG 0x0A +/* Output, +/- 90 degrees X-axis inclination */ +#define ADIS16209_XINCL_OUT_REG0x0C +#define ADIS16209_YINCL_OUT_REG0x0E +/* Output, +/-180 vertical rotational position */ +#define ADIS16209_ROT_OUT_REG 0x10 + +/* + * Calibration Register Definitions. + * Acceleration, inclination or rotation offset null. + */ +#define ADIS16209_XACCL_NULL_REG 0x12 +#define ADIS16209_YACCL_NULL_REG 0x14 +#define ADIS16209_XINCL_NULL_REG 0x16 +#define ADIS16209_YINCL_NULL_REG 0x18 +#define ADIS16209_ROT_NULL_REG 0x1A + +/* Alarm Register Definitions */ +#define ADIS16209_ALM_MAG1_REG 0x20 +#define ADIS16209_ALM_MAG2_REG 0x22 +#define ADIS16209_ALM_SMPL1_REG0x24 +#define ADIS16209_ALM_SMPL2_REG0x26 +#define ADIS16209_ALM_CTRL_REG 0x28 + +#define ADIS16209_AUX_DAC_REG 0x30 +#define ADIS16209_GPIO_CTRL_REG0x32 +#define ADIS16209_SMPL_PRD_REG 0x36 +#define ADIS16209_AVG_CNT_REG 0x38 +#define ADIS16209_SLP_CNT_REG 0x3A + +#define ADIS16209_MSC_CTRL_REG 0x34 +#define ADIS16209_MSC_CTRL_PWRUP_SELF_TESTBIT(10) +#define ADIS16209_MSC_CTRL_SELF_TEST_EN BIT(8) +#define ADIS16209_MSC_CTRL_DATA_RDY_ENBIT(2) +/* Data-ready polarity: 1 = active high, 0 = active low */ +#define ADIS16209_MSC_CTRL_ACTIVE_HIGHBIT(1) +#define ADIS16209_MSC_CTRL_DATA_RDY_DIO2 BIT(0) + +#define ADIS16209_STAT_REG 0x3C +#define ADIS16209_STAT_ALARM2 BIT(9) +#define ADIS16209_STAT_ALARM1 BIT(8) +#define ADIS16209_STAT_SELFTEST_FAIL_BIT 5 +#define ADIS16209_STAT_SPI_FAIL_BIT 3 +#define ADIS16209_STAT_FLASH_UPT_FAIL_BIT 2 +/* Power supply above 3.625 V */ +#define ADIS16209_STAT_POWER_HIGH_BIT 1 +/* Power supply below 3.15 V */ +#define ADIS16209_STAT_POWER_LOW_BIT 0 + +#define ADIS16209_CMD_REG 0x3E +#define ADIS16209_CMD_SW_RESETBIT(7) +#define ADIS16209_CMD_CLEAR_STAT BIT(4) +#define ADIS16209_CMD_FACTORY_CAL BIT
Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
On Friday 09 March 2018 09:59:39 mario.limoncie...@dell.com wrote: > > > Pali is your concern that this code for matching vendor/subsystem is > > > running > > > on non-Dell too? The only other recommendation I think that can be to > > > restrict > > > to matching Dell OEM strings in SMBIOS table, but I don't think that's > > > any better > > > than the matching for VID/SSVID. > > > > My concern is about adding a new machine specific code into generic > > driver, which check is done just by PCI vendor and subvendor. > > > > In future there can be new models or other PCI devices which matches > > above condition even they would not have any switchable graphics, nor > > they would manufactured by Dell. > > Uh Dell subsystem ID means it's Dell no? What would prevent you to take PCI device marked with Dell ID and put it into non-Dell computer? I do not believe that Dell PCI devices are configured to work only in Dell branded devices and refuse to power up in others. If there is Dell ID then it just means that PCI device itself is Dell's. And not that machine in which that device is plugged is also Dell. > > Also I can imagine that in future (or maybe already now?) it is possible > > to find PCI device which pass above checks and connect this PCI device > > into desktop /server / any non-laptop device. > > > > If this switchable graphics solution is specific to dell laptops, then > > rather checking for PCI vendor/subvevendor main check, there should be > > main check via DMI strings. > > Right now this is affected to both AIO desktop and laptops. > > IIRC you won't end up with switchable graphics in traditional desktop that you > can remove PCI card. If this code was run on a traditional desktop with a > AMD PCI card that BIOS query result should be invalid token (which will infer > switchable off to this routine). > > > > > Hardware is changing relatively quickly and there is absolutely no > > guarantee that e.g. NVIDIA would not start providing audio controller in > > similar like AMD and it would be put in those Dell machines. > > Kai Heng can explain exactly why NVIDIA isn't affected. > This is probably good information to include in the commit message too. Yes, extending commit message is a good idea. But here I'm talking about future, NVIDIA cards could be in future. I still think that whitelisting devices based on vendor ID by some measurements at one time is a bad idea. It is fragile which can stop working in the future. > > > > > > > > > > > > Interesting question would be, how handle this situation Windows? > > > > > > > > I don't know how this platform handles this on Windows, I guess we need > > > > Mario to shed some lights here. > > > > > > Sorry I don't have this information to share. I don't think it's too > > > useful here > > > anyway though because Windows driver architecture is much different in > > > this > > > area. > > > > > > > > > > -- > > Pali Rohár > > pali.ro...@gmail.com -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
On Saturday 10 March 2018 07:50:39 Lukas Wunner wrote: > Pretty much all modern Nvidia GPUs do have an integrated HDA > controller, however it's possible to hide it by clearing a bit > at offset 0x488 in the GPU's config space. Some BIOSes hide > the HDA if no external display is attached. > > I could imagine that the BIOS of the Dell machines in question > hides the HDA if Switchable Graphics is enabled. If that is the > case, be aware that there's an ongoing discussion to always expose > the HDA controller because the behavior of some BIOSes to only > expose the HDA when a display is attached causes massive problems > with Linux' HDA driver: > https://bugs.freedesktop.org/show_bug.cgi?id=75985 > > If we decide to always expose the HDA controller on Nvidia cards, > you may need to also match for the Nvidia vendor ID here. This is probably the example of reason why current solution based on vendor id is fragile and could be broken in future... if such changes to unhide devices are going to be implemented. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Re: Regression from efi: call get_event_log before ExitBootServices
On Fri, Mar 9, 2018 at 5:54 PM Jeremy Cline wrote: > On Fri, Mar 09, 2018 at 10:43:50AM +, Thiebaud Weksteen wrote: > > Thanks a lot for trying out the patch! > > > > Please don't modify your install at this stage, I think we are hitting a > > firmware bug and that would be awesome if we can fix how we are handling it. > > So, if we reach that stage in the function it could either be that: > > * The allocation did not succeed, somehow, but the firmware still returned > > EFI_SUCCEED. > > * The size requested is incorrect (I'm thinking something like a 1G of > > log). This would be due to either a miscalculation of log_size (possible) > > or; the returned values of GetEventLog are not correct. > > I'm sending a patch to add checks for these. Could you please apply and > > retest? > > Again, thanks for helping debugging this. > No problem, thanks for the help :) > With the new patch: > Locating the TCG2Protocol > Calling GetEventLog on TCG2Protocol > Log returned > log_location is not empty > log_size != 0 > log_size < 1M > Allocating memory for storing the logs > Returned from memory allocation > Copying log to new location > And then it hangs. I added a couple more print statements: > diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c > index ee3fac109078..1ab5638bc50e 100644 > --- a/drivers/firmware/efi/libstub/tpm.c > +++ b/drivers/firmware/efi/libstub/tpm.c > @@ -148,8 +148,11 @@ void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > efi_printk(sys_table_arg, "Copying log to new location\n"); > memset(log_tbl, 0, sizeof(*log_tbl) + log_size); > + efi_printk(sys_table_arg, "Successfully memset log_tbl to 0\n"); > log_tbl->size = log_size; > + efi_printk(sys_table_arg, "Set log_tbl->size\n"); > log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2; > + efi_printk(sys_table_arg, "Set log_tbl-version\n"); > memcpy(log_tbl->log, (void *) first_entry_addr, log_size); > efi_printk(sys_table_arg, "Installing the log into the configuration table\n"); > and it's hanging at "memset(log_tbl, 0, sizeof(*log_tbl) + log_size);" Thanks. Well, it looks like the memory that is supposedly allocated is not usable. I'm thinking this is a firmware bug. Ard, would you agree on this assumption? Thoughts on how to proceed? Thanks > Regards, > Jeremy
[GIT PULL REQUEST] watchdog - v4.16 Fixes 2
Hi Linus, Please pull the watchdog fixes for the v4.16 release cycle. This series contains: * f71808e_wdt: Fix magic close handling * sbsa: 32-bit read fix for WCV * hpwdt: Remove legacy NMI sourcing The output from git request-pull: The following changes since commit a17f4f032b61abd998a1f81b206a4517e2e3db2f: watchdog: sp5100_tco.c: fix potential build failure (2018-02-19 17:44:05 +0100) are available in the git repository at: git://www.linux-watchdog.org/linux-watchdog.git tags/linux-watchdog-4.16-fixes-2 for you to fetch changes up to 2b3d89b402b085b08498e896c65267a145bed486: watchdog: hpwdt: Remove legacy NMI sourcing. (2018-03-03 15:52:33 +0100) linux-watchdog 4.16-fixes-2 merge window tag Igor Pylypiv (1): watchdog: f71808e_wdt: Fix magic close handling Jayachandran C (1): watchdog: sbsa: use 32-bit read for WCV Jerry Hoemann (1): watchdog: hpwdt: Remove legacy NMI sourcing. drivers/watchdog/f71808e_wdt.c | 3 +- drivers/watchdog/hpwdt.c | 501 + drivers/watchdog/sbsa_gwdt.c | 3 +- 3 files changed, 13 insertions(+), 494 deletions(-)
[PATCH v2] scripts/kconfig: cleanup symbol handling code
Many of the variable names in scripts/kconfig/symbol.c are
far too terse to the point of not at all identifying _what_
they are actually used for (`p` and `l` as a couple examples),
and overall there is a large amount of code that could use
some cleaning up.
Give more explicit names to these variables, fix a couple cases
where different variables were sharing the same name and shadowing
each other, and overall cleanup a bit of the messiness in
sym_expand_string_value() and sym_escape_string_value()
while maintaining equivalent program behavior.
Suggested-by: Ulf Magnusson
Signed-off-by: Joey Pabalinas
1 file changed, 69 insertions(+), 61 deletions(-)
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 2220bc4b051bd914e3..9ee32ddb44e193719c 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -5,8 +5,8 @@
#include
#include
-#include
#include
+#include
#include
#include "lkc.h"
@@ -337,7 +337,7 @@ void sym_calc_value(struct symbol *sym)
{
struct symbol_value newval, oldval;
struct property *prop;
- struct expr *e;
+ struct expr *expr;
if (!sym)
return;
@@ -469,7 +469,7 @@ void sym_calc_value(struct symbol *sym)
struct symbol *choice_sym;
prop = sym_get_choice_prop(sym);
- expr_list_for_each_sym(prop->expr, e, choice_sym) {
+ expr_list_for_each_sym(prop->expr, expr, choice_sym) {
if ((sym->flags & SYMBOL_WRITE) &&
choice_sym->visible != no)
choice_sym->flags |= SYMBOL_WRITE;
@@ -899,94 +899,100 @@ struct symbol *sym_find(const char *name)
* name to be expanded shall be prefixed by a '$'. Unknown symbol expands to
* the empty string.
*/
-char *sym_expand_string_value(const char *in)
+char *sym_expand_string_value(const char *src)
{
- const char *src;
- char *res;
- size_t reslen;
+ const char *in;
+ char *res, *out;
+ size_t res_len, src_len;
/*
-* Note: 'in' might come from a token that's about to be
+* Note: 'src' might come from a token that'src about to be
* freed, so make sure to always allocate a new string
*/
- reslen = strlen(in) + 1;
- res = xmalloc(reslen);
- res[0] = '\0';
+ res_len = strlen(src) + 1;
+ res = xmalloc(res_len);
+ out = res;
- while ((src = strchr(in, '$'))) {
+ while ((in = strchr(src, '$'))) {
char *p, name[SYMBOL_MAXLENGTH];
- const char *symval = "";
+ const char *sym_val = "";
struct symbol *sym;
- size_t newlen;
+ size_t new_len, sym_len;
- strncat(res, in, src - in);
- src++;
+ strscpy(out, src, in - src);
+ out += in - src;
+ in++;
p = name;
- while (isalnum(*src) || *src == '_')
- *p++ = *src++;
+ while (isalnum(*in) || *in == '_')
+ *p++ = *in++;
*p = '\0';
sym = sym_find(name);
if (sym != NULL) {
sym_calc_value(sym);
- symval = sym_get_string_value(sym);
+ sym_val = sym_get_string_value(sym);
}
- newlen = strlen(res) + strlen(symval) + strlen(src) + 1;
- if (newlen > reslen) {
- reslen = newlen;
- res = xrealloc(res, reslen);
+ sym_len = strlen(sym_val);
+ new_len = sym_len + strlen(res) + strlen(in) + 1;
+ if (new_len > res_len) {
+ res_len = new_len;
+ res = xrealloc(res, res_len);
}
- strcat(res, symval);
- in = src;
+ strscpy(out, sym_val, sym_len);
+ out += sym_len;
+ src = in;
}
- strcat(res, in);
+ src_len = strlen(src);
+ strscpy(out, src, src_len);
+ out += src_len;
+ *out = '\0';
return res;
}
-const char *sym_escape_string_value(const char *in)
+const char *sym_escape_string_value(const char *src)
{
- const char *p;
- size_t reslen;
- char *res;
- size_t l;
+ const char *in;
+ size_t res_len, in_len;
+ char *res, *out;
- reslen = strlen(in) + strlen("\"\"") + 1;
+ res_len = strlen(src) + strlen("\"\"") + 1;
- p = in;
+ in = src;
for (;;) {
- l = strcspn(p, "\"\\");
- p += l;
+ in_len = strcspn(in, "\"\\");
+ in += in_len;
- if (p[0] == '\0')
+ if (*in == '\0')
break;
- reslen++;
- p++;
+
[PATCH] drivers: gpio: pca953x: add compatibility for pcal6524 and pcal9555a
The Pyra-Handheld originally used the tca6424 but recently we have
replaced it by the pin and package compatible pcal6524. So let's
add this to the bindings and the driver.
And while we are at it, the pcal9555a does not have a compatible entry
either but is already supported by the device id table.
Signed-off-by: H. Nikolaus Schaller
---
Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 2 ++
drivers/gpio/gpio-pca953x.c | 4
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
index 0d0158728f89..d2a937682836 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
@@ -16,6 +16,8 @@ Required properties:
nxp,pca9574
nxp,pca9575
nxp,pca9698
+ nxp,pcal6524
+ nxp,pcal9555a
maxim,max7310
maxim,max7312
maxim,max7313
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index a0a5f9730aa7..d2ead4b1cf61 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -70,6 +70,7 @@ static const struct i2c_device_id pca953x_id[] = {
{ "pca9575", 16 | PCA957X_TYPE | PCA_INT, },
{ "pca9698", 40 | PCA953X_TYPE, },
+ { "pcal6524", 24 | PCA953X_TYPE | PCA_INT | PCA_PCAL, },
{ "pcal9555a", 16 | PCA953X_TYPE | PCA_INT | PCA_PCAL, },
{ "max7310", 8 | PCA953X_TYPE, },
@@ -935,6 +936,9 @@ static const struct of_device_id pca953x_dt_ids[] = {
{ .compatible = "nxp,pca9575", .data = OF_957X(16, PCA_INT), },
{ .compatible = "nxp,pca9698", .data = OF_953X(40, 0), },
+ { .compatible = "nxp,pcal6524", .data = OF_953X(24, PCA_INT), },
+ { .compatible = "nxp,pcal9555a", .data = OF_953X(16, PCA_INT), },
+
{ .compatible = "maxim,max7310", .data = OF_953X( 8, 0), },
{ .compatible = "maxim,max7312", .data = OF_953X(16, PCA_INT), },
{ .compatible = "maxim,max7313", .data = OF_953X(16, PCA_INT), },
--
2.12.2
[PATCH] staging: speakup: Add unicode support to the speakup_dummy driver
This extends spk_io_ops with a synth_out_unicode which takes a u16 character
instead of just a byte, and extends spk_ttyio to implement it to emit
utf-8. spk_do_catch_up_unicode can then be introduced to benefit from
synth_out_unicode, and speakup_dummy made to use spk_do_catch_up_unicode instead
of spk_do_catch_up.
Signed-off-by: Samuel Thibault
Index: linux-4.15/drivers/staging/speakup/spk_types.h
===
--- linux-4.15.orig/drivers/staging/speakup/spk_types.h
+++ linux-4.15/drivers/staging/speakup/spk_types.h
@@ -151,6 +151,7 @@ struct spk_synth;
struct spk_io_ops {
int (*synth_out)(struct spk_synth *synth, const char ch);
+ int (*synth_out_unicode)(struct spk_synth *synth, u16 ch);
void (*send_xchar)(char ch);
void (*tiocmset)(unsigned int set, unsigned int clear);
unsigned char (*synth_in)(void);
Index: linux-4.15/drivers/staging/speakup/spk_ttyio.c
===
--- linux-4.15.orig/drivers/staging/speakup/spk_ttyio.c
+++ linux-4.15/drivers/staging/speakup/spk_ttyio.c
@@ -109,6 +109,7 @@ static struct tty_ldisc_ops spk_ttyio_ld
};
static int spk_ttyio_out(struct spk_synth *in_synth, const char ch);
+static int spk_ttyio_out_unicode(struct spk_synth *in_synth, u16 ch);
static void spk_ttyio_send_xchar(char ch);
static void spk_ttyio_tiocmset(unsigned int set, unsigned int clear);
static unsigned char spk_ttyio_in(void);
@@ -117,6 +118,7 @@ static void spk_ttyio_flush_buffer(void)
struct spk_io_ops spk_ttyio_ops = {
.synth_out = spk_ttyio_out,
+ .synth_out_unicode = spk_ttyio_out_unicode,
.send_xchar = spk_ttyio_send_xchar,
.tiocmset = spk_ttyio_tiocmset,
.synth_in = spk_ttyio_in,
@@ -220,6 +222,22 @@ static int spk_ttyio_out(struct spk_synt
return 0;
}
+static int spk_ttyio_out_unicode(struct spk_synth *in_synth, u16 ch)
+{
+ int ret;
+ if (ch < 0x80)
+ ret = spk_ttyio_out(in_synth, ch);
+ else if (ch < 0x800) {
+ ret = spk_ttyio_out(in_synth, 0xc0 | (ch >> 6));
+ ret &= spk_ttyio_out(in_synth, 0x80 | (ch & 0x3f));
+ } else {
+ ret = spk_ttyio_out(in_synth, 0xe0 | (ch >> 12));
+ ret &= spk_ttyio_out(in_synth, 0x80 | ((ch >> 6) & 0x3f));
+ ret &= spk_ttyio_out(in_synth, 0x80 | (ch & 0x3f));
+ }
+ return ret;
+}
+
static int check_tty(struct tty_struct *tty)
{
if (!tty) {
Index: linux-4.15/drivers/staging/speakup/synth.c
===
--- linux-4.15.orig/drivers/staging/speakup/synth.c
+++ linux-4.15/drivers/staging/speakup/synth.c
@@ -51,9 +51,9 @@ static int do_synth_init(struct spk_synt
* For devices that have a "full" notification mechanism, the driver can
* adapt the loop the way they prefer.
*/
-void spk_do_catch_up(struct spk_synth *synth)
+static void _spk_do_catch_up(struct spk_synth *synth, int unicode)
{
- u_char ch;
+ u16 ch;
unsigned long flags;
unsigned long jiff_max;
struct var_t *delay_time;
@@ -62,6 +62,7 @@ void spk_do_catch_up(struct spk_synth *s
int jiffy_delta_val;
int delay_time_val;
int full_time_val;
+ int ret;
jiffy_delta = spk_get_var(JIFFY);
full_time = spk_get_var(FULL);
@@ -80,7 +81,8 @@ void spk_do_catch_up(struct spk_synth *s
synth->flush(synth);
continue;
}
- synth_buffer_skip_nonlatin1();
+ if (!unicode)
+ synth_buffer_skip_nonlatin1();
if (synth_buffer_empty()) {
spin_unlock_irqrestore(&speakup_info.spinlock, flags);
break;
@@ -91,7 +93,11 @@ void spk_do_catch_up(struct spk_synth *s
spin_unlock_irqrestore(&speakup_info.spinlock, flags);
if (ch == '\n')
ch = synth->procspeech;
- if (!synth->io_ops->synth_out(synth, ch)) {
+ if (unicode)
+ ret = synth->io_ops->synth_out_unicode(synth, ch);
+ else
+ ret = synth->io_ops->synth_out(synth, ch);
+ if (!ret) {
schedule_timeout(msecs_to_jiffies(full_time_val));
continue;
}
@@ -116,8 +122,19 @@ void spk_do_catch_up(struct spk_synth *s
}
synth->io_ops->synth_out(synth, synth->procspeech);
}
+
+void spk_do_catch_up(struct spk_synth *synth)
+{
+ _spk_do_catch_up(synth, 0);
+}
EXPORT_SYMBOL_GPL(spk_do_catch_up);
+void spk_do_catch_up_unicode(struct spk_synth *synth)
+{
+ _spk_do_catch_up(synth, 1);
+}
+EXPORT_SYMBOL_GPL(spk_do_catch_up_unicode);
+
void spk_synth_flush(struct spk_synth *synth)
{
synth->io_ops->flush_buf
[RESEND PATCH 1/2] ASoC: Add DT bindings documentation for max9759 amplifier
This patch adds DT bindings documentation for Maxim MAX9759
speaker amplifier.
Reviewed-by: Rob Herring
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/sound/maxim,max9759.txt| 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/maxim,max9759.txt
diff --git a/Documentation/devicetree/bindings/sound/maxim,max9759.txt
b/Documentation/devicetree/bindings/sound/maxim,max9759.txt
new file mode 100644
index 000..737a996
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max9759.txt
@@ -0,0 +1,18 @@
+Maxim MAX9759 Speaker Amplifier
+===
+
+Required properties:
+- compatible : "maxim,max9759"
+- shutdown-gpios : the gpio connected to the shutdown pin
+- mute-gpios : the gpio connected to the mute pin
+- gain-gpios : the 2 gpios connected to the g1 and g2 pins
+
+Example:
+
+max9759: analog-amplifier {
+ compatible = "maxim,max9759";
+ shutdown-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>;
+ mute-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ gain-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>,
+<&gpio3 25 GPIO_ACTIVE_LOW>;
+};
--
2.7.4
[RESEND PATCH 0/2] ASoC: Add support for max9759 Amplifier Driver
The MAX9759 is a gpio controlled speaker amplifier, this patchset add the DT Bindings and the corresponding ASoC component driver. Changes with resend : - Add rob ack on bindings Neil Armstrong (2): ASoC: Add DT bindings documentation for max9759 amplifier ASoC: max9759: Add Amplifier Driver .../devicetree/bindings/sound/maxim,max9759.txt| 18 ++ sound/soc/codecs/Kconfig | 5 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/max9759.c | 207 + 4 files changed, 232 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/maxim,max9759.txt create mode 100644 sound/soc/codecs/max9759.c -- 2.7.4
[PATCH] drm/sun4i: Fix exclusivity of the TCON clocks
From: Ondrej Jirman
Currently the exclusivity is enabled when the rate is set by
the mode setting functions. These functions are called by
mode_set_nofb callback of drm_crc_helper. Then exclusivity
is disabled when tcon is disabled by atomic_disable
callback.
What happens is that mode_set_nofb can be called once when
mode chnages, and afterwards the system can call atomic_enable
and atomic_disable multiple times without further calls to
mode_set_nofb.
This happens:
mode_set_nofb - clk exclusivity is enabled
atomic_enable
atomic_disable - clk exclusivity is disabled
atomic_enable
atomic_disable - clk exclusivity is already disabled, leading to WARN
in clk_rate_exclusive_put
Solution is to enable exclusivity in sun4i_tcon_channel_set_status.
Signed-off-by: Ondrej Jirman
Cc: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index d4a29847dadd..cc29daa062f7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -104,6 +104,7 @@ static void sun4i_tcon_channel_set_status(struct sun4i_tcon
*tcon, int channel,
if (enabled) {
clk_prepare_enable(clk);
+ clk_rate_exclusive_get(clk);
} else {
clk_rate_exclusive_put(clk);
clk_disable_unprepare(clk);
@@ -263,7 +264,7 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon
*tcon,
const struct drm_display_mode *mode)
{
/* Configure the dot clock */
- clk_set_rate_exclusive(tcon->dclk, mode->crtc_clock * 1000);
+ clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
/* Set the resolution */
regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
@@ -428,7 +429,7 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
WARN_ON(!tcon->quirks->has_channel_1);
/* Configure the dot clock */
- clk_set_rate_exclusive(tcon->sclk1, mode->crtc_clock * 1000);
+ clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
--
2.16.2
[RESEND PATCH 2/2] ASoC: max9759: Add Amplifier Driver
The max9759 is a gpio controlled amplifier.
Tested on a Variscite Dart MX6 SoM based custom board.
Signed-off-by: Neil Armstrong
---
sound/soc/codecs/Kconfig | 5 ++
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/max9759.c | 207 +
3 files changed, 214 insertions(+)
create mode 100644 sound/soc/codecs/max9759.c
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 2b331f7..f9ea460 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -98,6 +98,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX98373 if I2C
select SND_SOC_MAX9850 if I2C
select SND_SOC_MAX9860 if I2C
+ select SND_SOC_MAX9759
select SND_SOC_MAX9768 if I2C
select SND_SOC_MAX9877 if I2C
select SND_SOC_MC13783 if MFD_MC13XXX
@@ -1187,6 +1188,10 @@ config SND_SOC_ZX_AUD96P22
config SND_SOC_LM4857
tristate
+config SND_SOC_MAX9759
+ tristate "Maxim MAX9759 speaker Amplifier"
+ select GPIOLIB
+
config SND_SOC_MAX9768
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index da15713..af4238d 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -80,6 +80,7 @@ snd-soc-jz4740-codec-objs := jz4740.o
snd-soc-l3-objs := l3.o
snd-soc-lm4857-objs := lm4857.o
snd-soc-lm49453-objs := lm49453.o
+snd-soc-max9759-objs := max9759.o
snd-soc-max9768-objs := max9768.o
snd-soc-max98088-objs := max98088.o
snd-soc-max98090-objs := max98090.o
@@ -325,6 +326,7 @@ obj-$(CONFIG_SND_SOC_JZ4740_CODEC) +=
snd-soc-jz4740-codec.o
obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o
obj-$(CONFIG_SND_SOC_LM4857) += snd-soc-lm4857.o
obj-$(CONFIG_SND_SOC_LM49453) += snd-soc-lm49453.o
+obj-$(CONFIG_SND_SOC_MAX9759) += snd-soc-max9759.o
obj-$(CONFIG_SND_SOC_MAX9768) += snd-soc-max9768.o
obj-$(CONFIG_SND_SOC_MAX98088) += snd-soc-max98088.o
obj-$(CONFIG_SND_SOC_MAX98090) += snd-soc-max98090.o
diff --git a/sound/soc/codecs/max9759.c b/sound/soc/codecs/max9759.c
new file mode 100644
index 000..ecfb4a8
--- /dev/null
+++ b/sound/soc/codecs/max9759.c
@@ -0,0 +1,207 @@
+// SPDX-Licence-Identifier: GPL-2.0
+/*
+ * MAX9759 Amplifier Driver
+ *
+ * Copyright (c) 2017 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "max9759"
+
+struct max9759 {
+ struct gpio_desc *gpiod_shutdown;
+ struct gpio_desc *gpiod_mute;
+ struct gpio_descs *gpiod_gain;
+ bool is_mute;
+ unsigned int gain;
+};
+
+static int pga_event(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol *control, int event)
+{
+ struct snd_soc_component *c = snd_soc_dapm_to_component(w->dapm);
+ struct max9759 *priv = snd_soc_component_get_drvdata(c);
+
+ if (SND_SOC_DAPM_EVENT_ON(event))
+ gpiod_set_value_cansleep(priv->gpiod_shutdown, 0);
+ else
+ gpiod_set_value_cansleep(priv->gpiod_shutdown, 1);
+
+ return 0;
+}
+
+/* From 6dB to 24dB in steps of 6dB */
+static const DECLARE_TLV_DB_SCALE(speaker_gain_tlv, 600, 600, 0);
+
+static int speaker_gain_control_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *c = snd_soc_kcontrol_component(kcontrol);
+ struct max9759 *priv = snd_soc_component_get_drvdata(c);
+
+ ucontrol->value.integer.value[0] = priv->gain;
+
+ return 0;
+}
+
+static const bool speaker_gain_table[4][2] = {
+ /* G1, G2 */
+ {true, true}, /* +6dB */
+ {false, true}, /* +12dB */
+ {true, false}, /* +18dB */
+ {false, false}, /* +24dB */
+};
+
+static int speaker_gain_control_put(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *c = snd_soc_kcontrol_component(kcontrol);
+ struct max9759 *priv = snd_soc_component_get_drvdata(c);
+
+ if (ucontrol->value.integer.value[0] > 3)
+ return -EINVAL;
+
+ priv->gain = ucontrol->value.integer.value[0];
+
+ /* G1 */
+ gpiod_set_value_cansleep(priv->gpiod_gain->desc[0],
+speaker_gain_table[priv->gain][0]);
+ /* G2 */
+ gpiod_set_value_cansleep(priv->gpiod_gain->desc[1],
+speaker_gain_table[priv->gain][1]);
+
+ return 1;
+}
+
+static int speaker_mute_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *c = snd_soc_kcontrol_component(kcontrol);
+ struct max9759 *priv = snd_soc_component_get_drvdata(c);
+
+ ucontrol->value.integer.value[0] = !priv->is_mute;
+
+ return 0;
+}
+
+static int speaker_mute_put(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_
Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Fri, Mar 09, 2018 at 10:41:20AM -0700, Jonathan Corbet wrote: > On Fri, 9 Mar 2018 00:40:16 +0100 > Jonathan Neuschäfer wrote: > > > The aim of this patchset is to move the GPIO subsystem's documentation > > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx > > and compiled into HTML. I moved everything except for sysfs.txt, because > > this file describes the legacy sysfs ABI, and doesn't seem to serve much > > (non-historical) purpose anymore. > > > > There are still some rough edges: > > > > * I think the API documentation (kernel-doc) should be moved out of > > index.rst into more appropriate files. > > * The headings are arguably wrong, because driver.rst, consumer.rst, > > etc. use the "document title" style, even though they are part of the > > GPIO chapter. But the resulting TOC tree is consistent, and I did not > > want to change almost all headings. > > * Some of the files could use more :c:func:`...` references and general > > ReST polish. > > > > But I don't want to make this patchset too large. > > [For future reference, if you're going to CC me on most of a patch series, > I'd really rather get the whole thing so I don't have to go looking for > it.] Noted. > From a quick look, it seems like a reasonable RST conversion to me. I do > wonder if sysfs.txt should just be removed, since it documents something > we don't want people to use at this point? Historical purposes are well > served by the repository history. > > I'd say changing the headings is worthwhile if it produces a better > result. I just tried this on one file (driver.rst) and it made no difference in the output (neither in the TOC in index.html nor in driver.html). Thanks, Jonathan Neuschäfer > OTOH I'd be wary of adding too much "polish"; we really want to > retain the readability of the plain-text files. > > Anyway, I'm happy to take these through the docs tree or see them go via > GPIO; Linus, what's your preference? > > Thanks, > > jon diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 505ee906d7d9..8eb08005be55 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -1,4 +1,3 @@ - GPIO Descriptor Driver Interface @@ -13,7 +12,7 @@ the structures used to define a GPIO driver: Internal Representation of GPIOs - + Inside a GPIO driver, individual GPIOs are identified by their hardware number, which is a unique number between 0 and n, n being the number of GPIOs managed by @@ -36,7 +35,7 @@ identify GPIOs in a bank of I2C GPIO expanders. Controller Drivers: gpio_chip -= +- In the gpiolib framework each GPIO controller is packaged as a "struct gpio_chip" (see linux/gpio/driver.h for its complete definition) with members @@ -74,7 +73,7 @@ not be required. GPIO electrical configuration -- +~ GPIOs can be configured for several electrical modes of operation by using the .set_config() callback. Currently this API supports setting debouncing and @@ -95,7 +94,7 @@ numbers on the pin controller so they can properly cross-reference each other. GPIOs with debounce support +~~~ Debouncing is a configuration set to a pin indicating that it is connected to a mechanical switch or button, or similar that may bounce. Bouncing means the @@ -112,7 +111,7 @@ is not configurable. GPIOs with open drain/source support - + Open drain (CMOS) or open collector (TTL) means the line is not actively driven high: instead you provide the drain/collector as output, so when the transistor @@ -209,7 +208,7 @@ of actively driving the line low, it is set to input. GPIO drivers providing IRQs +~~~ It is custom that GPIO drivers (GPIO chips) are also providing interrupts, most often cascaded off a parent interrupt controller, and in some special cases the GPIO logic is melded with a SoC's primary interrupt controller. @@ -359,7 +358,7 @@ below exists. Locking IRQ usage -- +~ Input GPIOs can be used as IRQ signals. When this happens, a driver is requested to mark the GPIO as being used as an IRQ:: @@ -378,7 +377,7 @@ When using the gpiolib irqchip helpers, these callback are automatically assigned. Real-Time compliance for GPIO IRQ chips +~~~ Any provider of irqchips needs to be carefully tailored to support Real Time preemption. It is desirable that all irqchips in the GPIO subsystem keep this @@ -404,7 +403,7
Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs
On 03/10/2018 12:01 AM, Pavel Machek wrote:
[...]
>> What file are you opening to cause this?
>
> Strace says:
>
> openat(7, "in_intensity_both_thresh_rising_en",
>>> O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbe83b714) = -1 ENOTTY
>>> (Inappropriate ioctl for device)
> read(3,
> Message from syslogd@localhost at Mar 9 23:54:39 ...
> kernel:[ 3097.357696] Internal error: Oops: 8007 [#2] ARM
>
> So that would be:
>
> ./devices/platform/6800.ocp/48072000.i2c/i2c-2/2-0029/iio:device1/events/in_intensity_both_thresh_rising_en
>
> And indeed, manually cat-ing that file reproduces the problem.
>
> pavel@n900:/sys/devices/platform/6800.ocp/48072000.i2c/i2c-2/2-0029/iio:device1$
> cat name
> tsl2563
>
> I can not find tsl2563 in MAINTAINERS, file is
> ./drivers/iio/light/tsl2563.c . I added few people pointed by git log.
The driver registers event attributes, but does not provide a handle to
access those attributes.
Now the question is how to best handle this case.
1) Return an error when the device is registered and abort registration
2) Skip registering the event attributes
3) Skip registering the event attributes, but print a warning
4) Register the attributes, but return an error when they are accessed
I'd prefer 2 since it offers a nice method of disabling all events for a
device (e.g. if not interrupt is provided).
On the other hand it could cause some confusion during development,
potentially causing the developer to wonder why he doesn't get any event
attributes even though he setup his channel description to have event
attributes.
Patch for 2.
--- a/drivers/iio/industrialio-event.c
+++ b/drivers/iio/industrialio-event.c
@@ -477,7 +477,8 @@ int iio_device_register_eventset(struct iio_dev
struct attribute **attr;
if (!(indio_dev->info->event_attrs ||
- iio_check_for_dynamic_events(indio_dev)))
+ iio_check_for_dynamic_events(indio_dev)) ||
+ !indio_dev->info->read_event_config)
return 0;
indio_dev->event_interface =
Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs
2018-03-10 8:01 GMT+09:00 Pavel Machek :
> Hi!
>
>> > Hmm. Looks like there's a lot of fun to be had with sysfs.
>> >
>> >
>> > pavel@n900:~$ uname -a
>> > Linux n900 4.16.0-rc4-59690-g7f84626-dirty #543 Thu Mar 8 19:53:30 CET
>> > 2018 armv7l GNU/Linux
>> >
>> > [ 306.402496] bq2415x: command Timer reset
>> > [ 312.761322] adp1653 2-0030: Read Addr:03 Val:00 ok
>> > [ 313.264129] Unable to handle kernel NULL pointer dereference at
>> > virtual address 0
>> > 000
>> > [ 313.272308] pgd = 01336620
>> > [ 313.275146] [] *pgd=800af831, *pte=, *ppte=
>> > [ 313.281463] Internal error: Oops: 8007 [#1] ARM
>> > [ 313.286376] Modules linked in:
>> > [ 313.289459] CPU: 0 PID: 3584 Comm: grep Tainted: GW
>> > 4.16.0-rc4-59690-g
>> > 7f84626-dirty #543
>> > [ 313.298919] Hardware name: Nokia RX-51 board
>> > [ 313.303222] PC is at (null)
>> > [ 313.306213] LR is at iio_ev_state_show+0x38/0x54
>> > [ 313.310852] pc : [<>]lr : []psr: a013
>> > [ 313.317169] sp : c7b47e70 ip : c087bb24 fp : 0001
>> > [ 313.322418] r10: cb19e000 r9 : c0857220 r8 : 1000
>> > [ 313.327667] r7 : 0fff r6 : cb711c80 r5 : cb19e000 r4 :
>> >
>> > [ 313.334228] r3 : 0001 r2 : r1 : c087b4dc r0 :
>> > ce584800
>> > [ 313.340789] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
>> > Segment none
>> > [ 313.347991] Control: 10c5387d Table: 87bec019 DAC: 0051
>> > [ 313.353759] Process grep (pid: 3584, stack limit = 0xc4e45eab)
>> > [ 313.359619] Stack: (0xc7b47e70 to 0xc7b48000)
>> > [ 313.364013] 7e60: c05d6988
>> > cb711b00 ce585c00 c0450d68
>> > [ 313.471038] [] (iio_ev_state_show) from []
>> > (dev_attr_show+0x1c/0x4c)
>> > [ 313.479187] [] (dev_attr_show) from []
>> > (sysfs_kf_seq_show+0x90/0x108)
>> > [ 313.487426] [] (sysfs_kf_seq_show) from []
>> > (kernfs_seq_show+0x24/0x28)
>> > [ 313.495758] [] (kernfs_seq_show) from []
>> > (seq_read+0x1dc/0x500)
>> > [ 313.503479] [] (seq_read) from []
>> > (__vfs_read+0x2c/0x120)
>> > [ 313.510681] [] (__vfs_read) from []
>> > (vfs_read+0x88/0x114)
>> > [ 313.517852] [] (vfs_read) from []
>> > (SyS_read+0x40/0x8c)
>> > [ 313.524780] [] (SyS_read) from []
>> > (ret_fast_syscall+0x0/0x54)
>> > [ 313.532318] Exception stack(0xc7b47fa8 to 0xc7b47ff0)
>> > [ 313.537414] 7fa0: 00035330 00042000 0003
>> > 00042000 8000 8000
>> >
>>
>> What file are you opening to cause this?
>
> Strace says:
>
> openat(7, "in_intensity_both_thresh_rising_en",
>> > O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbe83b714) = -1 ENOTTY
>> > (Inappropriate ioctl for device)
> read(3,
> Message from syslogd@localhost at Mar 9 23:54:39 ...
> kernel:[ 3097.357696] Internal error: Oops: 8007 [#2] ARM
>
> So that would be:
>
> ./devices/platform/6800.ocp/48072000.i2c/i2c-2/2-0029/iio:device1/events/in_intensity_both_thresh_rising_en
>
> And indeed, manually cat-ing that file reproduces the problem.
This problem happens when no irq is defined for this device.
In this case, tsl2563_info_no_irq whose read_event_config field is NULL
is selected as iio_info. On the other hand, iio_chan_spec for this
driver always registers event_spec.
So sysfs files related to the channel events are always created even if
no irq is defined.
I think we can fix this issue by defining another iio_chan_spec with
no event_spec for no irq case.
Jonathan, do you have any other idea how to fix this issue?
Re: [PATCH 3/5 V2] tpm2: add longer timeouts for creation commands.
On Tue, 2018-03-06 at 15:19 +, Winkler, Tomas wrote: > > On Tue, 2018-03-06 at 11:25 +0200, Tomas Winkler wrote: > > > TPM2_CC_Create(0x153) and TPM2_CC_CreatePrimary (0x131) involve > > > generation of crypto keys which can be a computationally intensive task. > > > The timeout is set to 3min. > > > Rather than increasing default timeout a new constant is added, to not > > > stall for too long on regular commands failures. > > > > > > Signed-off-by: Tomas Winkler > > > > Why are you radically chaging the default timeout? The commit message > > does not tell anything about that change. > > > > Let me, recheck but it should be same value just converted to msecs. > > > Why couldn't we just have two timeouts: one default and one long that > > would be at least as long as the longest timeout defined in the spec? > > I've tried to explain it in the commit message but apparently has failed. > > We have a default or undefined which should be the same as it was unless I did > some silly mistake in conversion to msecs (will check), ass all others are in > msecs. > It was 2 min = 2 * 60 * HZ (in jiffies) which would be msecs_to_jiffies(2 * 60 > * 1000 = 12) > TPM2_DURATION_DEFAULT = 12 Aah, of course :-) The problem was that I had somehow a blid spot with seeing the msec_to_jiffies() conversion. TPM_NUM_DURATIONS would a better name than TPM_DURATION_MAX because TPM_DURATION_MAX is easy to confuse with TPM_DURATION_* constants. /Jarkko
Re: Nokia N900: refcount_t underflow, use after free
Hi! > >>> Well, there certainly seems to be an obvious bug wherein > >>> isp_detach_iommu() just releases the mapping directly without calling > >>> arm_iommu_detach_device() to balance the equivalent attach. That can't > >>> be helping. > >> > >> Indeed, I have been able to reproduce the same warning using a > >> standalone test module, and the missing arm_iommu_detach_device() is > >> causing the warning after probe (during failure path) or during > >> remove. > > > > Ok do you have an idea how to fix the isp error paths? Untested patch > > would be fine... But it seems that you know what needs to be fixed and > > I don't. > > > > OK, see if the following fixes the issue for you, only build tested. Word-wrapped, so I applied by hand. And yes, the oops at boot is gone. Thanks! (Camera still does not work in -next... kills system. Oh well. Lets debug that some other day.) > 8< - > >From bac9a48fb646dc51f2030d676a0dbe3298c3b134 Mon Sep 17 00:00:00 2001 > From: Suman Anna > Date: Fri, 9 Mar 2018 16:39:59 -0600 > Subject: [PATCH] media: omap3isp: fix unbalanced dma_iommu_mapping > > The OMAP3 ISP driver manages its MMU mappings through the IOMMU-aware > ARM DMA backend. The current code creates a dma_iommu_mapping and > attaches this to the ISP device, but never detaches the mapping in > either the probe failure paths or the driver remove path resulting > in an unbalanced mapping refcount and a memory leak. Fix this properly. > > Reported-by: Pavel Machek > Signed-off-by: Suman Anna Tested-by: Pavel Machek Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 09/11] media: vsp1: Provide support for extended command pools
On 09/03/18 22:04, Kieran Bingham wrote:
> VSPD and VSP-DL devices can provide extended display lists supporting
> extended command display list objects.
>
> These extended commands require their own dma memory areas for a header
> and body specific to the command type.
>
> Implement a command pool to allocate all necessary memory in a single
> DMA allocation to reduce pressure on the TLB, and provide convenvient
s/convenvient/convenient/
> re-usable command objects for the entities to utilise.
> Signed-off-by: Kieran Bingham
> ---
I feel like this adds quite a bit of 'duplication' against the body pool
implementation - and there is scope for re-factoring somehow to make a lot more
of this common.
I think this is still fine to go in as is for now (as an approach that is) - but
I'd like to work out how to make this better as a later task.
Then with a reusable implementation then we can easily move the excess display
list headers (which are currently being allocated 1 for *every dlb* rather than
1 for every dl) to their own pool and allocate as appropriate.
Essentially we have the following 'object's which want to have minimal DMA
allocations (to reduce TLB pressure) - and are all sharing the same size.
- Display list headers (72 or 96 bytes)
- Display list bodys (variable size - multiple per header)
if (VSPD) {
- Extended display list header (16 bytes * number of bodies)
- Extended display list body (autodisp 96 bytes, autofld 160 bytes)
}
The dma_pool API's don't seem to be suitable here because as far as I can tell
it is still calling dma_alloc_coherent for each page.., rather than creating a
large pre-allocated slab and carving from it.
There certainly doesn't seem to be a way to say the number of elements to
pre-allocate... If I'm missing something obvious here - I'd love to hear it as I
don't want to re-invent any wheels!
Surely this similar pattern occurs elsewhere in the kernel ?
--
Kieran
> drivers/media/platform/vsp1/vsp1_dl.c | 189 +++-
> drivers/media/platform/vsp1/vsp1_dl.h | 3 +-
> 2 files changed, 192 insertions(+)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c
> index 36440a2a2c8b..6d17b8bfa21c 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -121,6 +121,30 @@ struct vsp1_dl_body_pool {
> };
>
> /**
> + * struct vsp1_cmd_pool - display list body pool
> + * @dma: DMA address of the entries
> + * @size: size of the full DMA memory pool in bytes
> + * @mem: CPU memory pointer for the pool
> + * @bodies: Array of DLB structures for the pool
> + * @free: List of free DLB entries
> + * @lock: Protects the pool and free list
> + * @vsp1: the VSP1 device
> + */
> +struct vsp1_dl_cmd_pool {
> + /* DMA allocation */
> + dma_addr_t dma;
> + size_t size;
> + void *mem;
> +
> + struct vsp1_dl_ext_cmd *cmds;
> + struct list_head free;
> +
> + spinlock_t lock;
> +
> + struct vsp1_device *vsp1;
> +};
> +
> +/**
> * struct vsp1_dl_list - Display list
> * @list: entry in the display list manager lists
> * @dlm: the display list manager
> @@ -176,6 +200,7 @@ struct vsp1_dl_manager {
> struct vsp1_dl_list *pending;
>
> struct vsp1_dl_body_pool *pool;
> + struct vsp1_dl_cmd_pool *autfld_cmds;
> };
>
> /*
> -
> @@ -339,6 +364,139 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32
> reg, u32 data)
> }
>
> /*
> -
> + * Display List Extended Command Management
> + */
> +
> +enum vsp1_extcmd_type {
> + VSP1_EXTCMD_AUTODISP,
> + VSP1_EXTCMD_AUTOFLD,
> +};
> +
> +struct vsp1_extended_command_info {
> + u16 opcode;
> + size_t body_size;
> +} vsp1_extended_commands[] = {
> + [VSP1_EXTCMD_AUTODISP] = { 0x02, 96 },
> + [VSP1_EXTCMD_AUTOFLD] = { 0x03, 160 },
> +};
> +
> +/**
> + * vsp1_dl_cmd_pool_create - Create a pool of commands from a single
> allocation
> + * @vsp1: The VSP1 device
> + * @type: The command pool type
> + * @num_commands: The quantity of commands to allocate
> + *
> + * Allocate a pool of commands each with enough memory to contain the private
> + * data of each command. The allocation sizes are dependent upon the command
> + * type.
> + *
> + * Return a pointer to a pool on success or NULL if memory can't be
> allocated.
> + */
> +struct vsp1_dl_cmd_pool *
> +vsp1_dl_cmd_pool_create(struct vsp1_device *vsp1, enum vsp1_extcmd_type type,
> + unsigned int num_cmds)
> +{
> + struct vsp1_dl_cmd_pool *pool;
> + unsigned int i;
> + size_t cmd_size;
> +
> + pool = kzalloc(sizeof(*pool), GFP_KERNEL);
> + if (!pool)
> + return NULL;
> +
> + pool->cmds = kcalloc(num_cmds, sizeof(*pool->cmds), GFP_KERNEL);
> + if (!pool->cmds) {
> + kfre
Re: [PATCH] KVM:arm/arm64: dcache need be coherent unconditionally
On Sat, 10 Mar 2018 03:23:18 +,
peng hao wrote:
> >> For emulation devices just like vga, keeping coherent dcache between
> >> guest and host timely is needed.
> >> Now the display of vnc-viewer will not update continuously and the
> >> patch can fix up.
> >>
> >> Signed-off-by: Peng Hao
> >> ---
> >> virt/kvm/arm/mmu.c | 6 ++
> >> 1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> >> index ec62d1c..4a28395e 100644
> >> --- a/virt/kvm/arm/mmu.c
> >> +++ b/virt/kvm/arm/mmu.c
> >> @@ -1416,8 +1416,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> >> phys_addr_t fault_ipa,
> >> kvm_set_pfn_dirty(pfn);
> >> }
> >>
> >> -if (fault_status != FSC_PERM)
> >> -clean_dcache_guest_page(pfn, PMD_SIZE);
> >> +clean_dcache_guest_page(pfn, PMD_SIZE);
> >>
> >> if (exec_fault) {
> >> new_pmd = kvm_s2pmd_mkexec(new_pmd);
> >> @@ -1438,8 +1437,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> >> phys_addr_t fault_ipa,
> >> mark_page_dirty(kvm, gfn);
> >> }
> >>
> >> -if (fault_status != FSC_PERM)
> >> -clean_dcache_guest_page(pfn, PAGE_SIZE);
> >> +clean_dcache_guest_page(pfn, PAGE_SIZE);
> >>
> >> if (exec_fault) {
> >> new_pte = kvm_s2pte_mkexec(new_pte);
> >>
>
> >I'm sorry, but I have to NAK this.
>
> >You're papering over the fundamental issue that you're accessing a
> >cacheable alias of a non cacheable memory. The architecture is very
> >clear about why this doesn't work, and KVM implements the architecture.
>
>
>
> I find that I just encounter the problem after the commit
> '15303ba5d1cd9b28d03a980456c0978c0ea3b208 " .
This should really be a9c0e12ebee5 ("KVM: arm/arm64: Only clean the
dcache on translation fault").
> The commit contains "icache invalidation optimizations, improving VM
> startup time",it changes from unconditionally calling
> coherent_cache_guest_page(including dcache handle) to conditionally
> calling clean_dcache_guest_page.
>
> I trace the display of vnc abnormally and find it generate data
> abort in vga address region with FSC_PERM,and it will not call
> clean_dcache_guest_page . So I think should recover to uncontionally
> calling clean_dcache_guest_page.
[I really hate ranting on a Saturday morning as the sun is finally out
and I could be relaxing in the garden, but hey, I guess that's the
fate of a kernel hacker who made the silly mistake of reading email on
a Saturday morning instead of being out in the garden...]
Even if you enabled dirty tracking on the VGA memory (and thus making
it RO to generate a permission fault), you would end-up cleaning to
the PoC *before* any write has been committed to the page. How useful
is that? You're also pretty lucky that this does a clean+invalidate
(rather than a clean which would be good enough), meaning that QEMU
will in turn miss in the cache (PIPT caches) and read some *stale*
data from memory.
Repeat that often enough, and yes, you can get some sort of
display. Is that the right thing to do? Hell no. You might just as
well have a userspace process thrashing the cache at the PoC, running
concurrently with your VM, it would have a similar effect. It may work
on your particular platform, in some specific conditions, but it just
doesn't work in general.
What you are describing is a long standing issue. VGA emulation never
worked on ARM, because it is fundamentally incompatible with the ARM
memory architecture. Read the various discussions on the list over the
past 4 years or so, read the various presentations I and others have
given about this problem and how to address it[1].
The *real* fix is a one-liner in the Linux VGA driver: map the VGA
memory as cacheable, and stop lying to the guest. Or if you want to
lie to the guest, perform cache maintenance from userspace in QEMU
based on the dirty tracking bitmap that it uses for the VGA memory.
Anything else is out of the scope of the architecture, and I'm not
going to add more crap to satisfy requirements that cannot be
implemented on real HW, let alone in a virtualized environment.
Thanks,
M.
[1] http://events17.linuxfoundation.org/sites/events/files/slides/slides_10.pdf
--
Jazz is not dead, it just smell funny.
Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer wrote: > The aim of this patchset is to move the GPIO subsystem's documentation > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx > and compiled into HTML. Awesome! > I moved everything except for sysfs.txt, because > this file describes the legacy sysfs ABI, and doesn't seem to serve much > (non-historical) purpose anymore. > > There are still some rough edges: > > * I think the API documentation (kernel-doc) should be moved out of > index.rst into more appropriate files. > * The headings are arguably wrong, because driver.rst, consumer.rst, > etc. use the "document title" style, even though they are part of the > GPIO chapter. But the resulting TOC tree is consistent, and I did not > want to change almost all headings. > * Some of the files could use more :c:func:`...` references and general > ReST polish. > > But I don't want to make this patchset too large. It's fine, we take it one step at a time. On Fri, Mar 09, 2018 at 10:41:20AM -0700, Jonathan Corbet wrote: > Anyway, I'm happy to take these through the docs tree or see them go via > GPIO; Linus, what's your preference? I might have some doc patches that could collide so I can take them. I take it there will be a v2? Yours, Linus Walleij
Re: [PATCH] mmc: card: Don't show eMMC RPMB and BOOT areas in /proc/partitions
On Thu, Mar 8, 2018 at 9:36 PM, Alex Lemberg wrote: > On 3/2/18 4:53 AM, Linus Walleij wrote: >> What we need to do is make the "special partitions" part of the >> main block device and stop spawning these special block >> devices for each boot partions or general partitions. In addition, >> each of these boot partitions or general partitions will get their >> own block queue and state container which is not cheap in >> runtime memory footprint terms. >> >> So what I want to do (unless someone beats me to it) it to come >> up with some way making boot and general partitions part >> of the main block device. Possibly the core kernel partitioning >> code needs to be augmented. The tentative idea is to just >> put the sectors representing these partitions after the main >> block device and access them from there, with an offset. > > I don't think that hiding the Boot and RPMB will resolve the problem > described above. Me neither. I'm just trying to discuss the problem lurking behind these partitions. > Boot partition (same as RPMB) in eMMC device is a separate > "physical" partition. > It has its own logical address range and different from general > partition characteristics. Yep. > From the protocol - the access to this partition it requires switch > partition command. Yeah I saw that as well... it's a bit funny. > From the device side - it can be managed in totally different manner > (SLC vs. MLC blocks, etc.) > I think it completely makes sense to allow access to Boot partition from the > user space. For example - to allow R/W the boot image. But this patch doesn't hide the partition from userspace does it? They will still appear in /dev/mmcblk0boot1 etc. Just not reported as "real" partitions in /proc/partitions. Or do I misunderstand it? > AFAIK, in case of SCSI/UFS devices - Boot LUN's are represented as > separate block > device partitions (/dev/sdb, dev/sdc...). > Shouldn't we have the same for eMMC? I think we should, but we have the problem with the boot partitions and general partitions that they do not work anything like SCSCI LUNs. On a SCSI device dd from the whole device will copy all data on the device, the partition table and contents of all partitions. For say /dev/mmcblk0 this is not true of the device contains boot or general partitions, those other partitions will not be copied. Yours, Linus Walleij
Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs
Hi!
On Sat 2018-03-10 12:19:29, Lars-Peter Clausen wrote:
> On 03/10/2018 12:01 AM, Pavel Machek wrote:
> [...]
> >> What file are you opening to cause this?
> >
> > Strace says:
> >
> > openat(7, "in_intensity_both_thresh_rising_en",
> >>> O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 3
> > fstat64(3, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> > ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbe83b714) = -1 ENOTTY
> >>> (Inappropriate ioctl for device)
> > read(3,
> > Message from syslogd@localhost at Mar 9 23:54:39 ...
> > kernel:[ 3097.357696] Internal error: Oops: 8007 [#2] ARM
> >
> > So that would be:
> >
> > ./devices/platform/6800.ocp/48072000.i2c/i2c-2/2-0029/iio:device1/events/in_intensity_both_thresh_rising_en
> >
> > And indeed, manually cat-ing that file reproduces the problem.
> >
> > pavel@n900:/sys/devices/platform/6800.ocp/48072000.i2c/i2c-2/2-0029/iio:device1$
> > cat name
> > tsl2563
> >
> > I can not find tsl2563 in MAINTAINERS, file is
> > ./drivers/iio/light/tsl2563.c . I added few people pointed by git log.
>
> The driver registers event attributes, but does not provide a handle to
> access those attributes.
>
> Now the question is how to best handle this case.
>
> 1) Return an error when the device is registered and abort registration
> 2) Skip registering the event attributes
> 3) Skip registering the event attributes, but print a warning
> 4) Register the attributes, but return an error when they are accessed
>
> I'd prefer 2 since it offers a nice method of disabling all events for a
> device (e.g. if not interrupt is provided).
2 works for me.
Tested-by: Pavel Machek
Reported-by: Pavel Machek
Now grep -ri asdfasdf /sys finishes.
Thanks,
Pavel
> --- a/drivers/iio/industrialio-event.c
> +++ b/drivers/iio/industrialio-event.c
> @@ -477,7 +477,8 @@ int iio_device_register_eventset(struct iio_dev
> struct attribute **attr;
>
> if (!(indio_dev->info->event_attrs ||
> - iio_check_for_dynamic_events(indio_dev)))
> + iio_check_for_dynamic_events(indio_dev)) ||
> + !indio_dev->info->read_event_config)
> return 0;
>
> indio_dev->event_interface =
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling
On Fri, 09 Mar 2018 21:36:12 +, Christoffer Dall wrote: > > On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote: > > I'd be more confident if we did forbid P+A for such interrupts > > altogether, as they really feel like another kind of HW interrupt. > > How about a slightly bigger hammer: Can we avoid doing P+A for level > interrupts completely? I don't think that really makes much sense, and > I think we simply everything if we just come back out and resample the > line. For an edge, something like a network card, there's a potential > performance win to appending a new pending state, but I doubt that this > is the case for level interrupts. I started implementing the same thing yesterday. Somehow, it feels slightly better to have the same flow for all level interrupts, including the timer, and we only use the MI on EOI as a way to trigger the next state of injection. Still testing, but looking good so far. I'm still puzzled that we have this level-but-not-quite behaviour for VFIO interrupts. At some point, it is going to bite us badly. M. -- Jazz is not dead, it just smell funny.
Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it
On 10.03.2018 10:18, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 01:34:45AM +0100, Maciej S. Szmigiero wrote: >> Currently, it is very easy to make the AMD microcode update driver crash >> or spin on a malformed microcode file since it does very little >> consistency checking on data loaded from such file. > > Sorry but if one has enough permissions to install malformed microcode, > crashing the loader is the least of your problems. IOW, I don't see the > justification for the unnecessary complication with all those checks. While I agree this is not a security problem, I cannot agree that these checks are unnecessary driver complication. First, these checks are really just very basic checks like "check whether the loaded file is long enough to actually contain some structure before accessing it" or "don't iterate an array in file without checking if it actually has a terminating element" or "check whether microcode patch length isn't something like 2GB before allocating memory for it". Without them, it is easy to crash the driver when just playing with microcode files (and it turns out that AMD-released microcode files in linux-firmware actually don't contain the newest microcode versions, even for older CPUs). Second, since these checks happen only on a microcode file load (something that 99.9% of systems probably will do just once at boot time) it is hardly a performance-critical path. Third, we still do check consistency of data provided to various root-only syscalls (and these might be much more performance-critical than this code). > Thx. > Thanks, Maciej
Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.
On Tue, 2018-03-06 at 13:36 -0500, Mimi Zohar wrote: > I've heard that some maintainers are moving away from cover letters, > since they are not include in the git repo and are lost. I've seen > Andrew Morton cut and paste the cover letter in the first patch > description of the patch set. When I contribute code, the cover letter helps me to do the Right Thing.. Taking the time to write a proper cover letter helps to do a "mental exercise" that 1. The changes make sense in the first place. 2. Only the necessary is done, not more or less. Even for a small patch set the time used to write the cover letter will pay off because it helps the maitainer to make a fair and educated decision. /Jarkko
Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.
On Wed, 2018-03-07 at 08:54 -0700, Jonathan Corbet wrote: > On Tue, 06 Mar 2018 13:36:36 -0500 > Mimi Zohar wrote: > > > I've heard that some maintainers are moving away from cover letters, > > since they are not include in the git repo and are lost. > > If I get a patch series with a cover letter that should be preserved, I > apply the series in a branch then do a no-ff merge; the cover letter can > then go into the merge commit. There's no reason why cover letters need to > be lost. That is an awesome idea. I'll start using this approach. Thank you. /Jarkko
Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.
On Wed, 2018-03-07 at 11:35 -0500, Mimi Zohar wrote: > On Wed, 2018-03-07 at 08:54 -0700, Jonathan Corbet wrote: > > On Tue, 06 Mar 2018 13:36:36 -0500 > > Mimi Zohar wrote: > > > > > I've heard that some maintainers are moving away from cover letters, > > > since they are not include in the git repo and are lost. > > > > If I get a patch series with a cover letter that should be preserved, I > > apply the series in a branch then do a no-ff merge; the cover letter can > > then go into the merge commit. There's no reason why cover letters need to > > be lost. > > Thanks, Jon. That sounds like a really, good idea. > > Some maintainers are saying to put the Changelog after the "---" so > that it isn't included in the patch description. > > One of the reasons for including the Changelog in the patch > description, is to credit people with bug fixes, important rework of > the patch, etc. This is a really good point. By adding the cover letter to the GIT history helps to better track people who to thank or blame :-) /Jarkko
Re: [PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches
On Fri, 9 Mar 2018 10:56:07 -0800, Alex Hung wrote: > On Fri, Mar 9, 2018 at 5:33 AM, Jean Delvare wrote: > > However it doesn't make sense to commit this change unless there will > > be at least one user of it. What is the status of the piece of code > > which was supposed to use this new feature? > > The original use of DMI on _OSI is no needed anymore - the OEM _OSI > string will always enabled; however, this patch is still needed > because DMI_OEM_STRING are more suitable for many DMI quirks, > especially for Dell systems, and many, if not all, DMI quirks for Dell > systems with DMI_PRODUCT_NAME can be (and should be) replaced by > DMI_OEM_STRING because 1) OEM string contains system id, 2) multiple > product names can be used for the same system id and 3) the number DMI > quirks can be reduced. > > For example, the DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 9020M") in > commit 1f59ab2783aed04f131 can be replaced by > DMI_MATCH_EXACT(DMI_OEM_STRING, "1[0669]") > > I will start sending DMI quirks with DMI_OEM_STRING myself and perhaps > sending a clean up patch to replace DMI_PRODUCT_NAME by DMI_OEM_STRING > for the Dell systems I have access to. With this patch in place first, > I am able to convince others to use DMI_OEM_STRING because there will > fewer risks to spend time in vain. Fair enough. I've fixed the blank line issue and queued your patch for kernel v4.17, thanks for your contribution. -- Jean Delvare SUSE L3 Support
Re: [PATCH v3 3/5] tpm: migrate tpm2_probe() to use struct tpm_buf
On Thu, 2018-03-08 at 13:47 -0800, J Freyensee wrote: > Looks better :-). > > > Acked-by: Jay Freyensee Thank you. /Jarkko
Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it
On Sat, Mar 10, 2018 at 01:26:00PM +0100, Maciej S. Szmigiero wrote: > Without them, it is easy to crash the driver when just playing with > microcode files You're not supposed to play with the microcode files. If you do and something breaks, you get to keep the pieces. If the official microcode files have a problem, then I'm all ears. Anything else contrived which doesn't actually happen unless someone manipulates them is not an issue the microcode loader should protect against. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] net/9p: avoid -ERESTARTSYS leak to userspace
Hi Andrew,
Thank you very much for taking care of this.
Please find my answers to your remarks below.
On Fri, 9 Mar 2018 14:12:52 -0800
Andrew Morton wrote:
> On Fri, 09 Mar 2018 21:41:38 +0100 Greg Kurz wrote:
>
> > If it was interrupted by a signal, the 9p client may need to send some
> > more requests to the server for cleanup before returning to userspace.
> >
> > To avoid such a last minute request to be interrupted right away, the
> > client memorizes if a signal is pending, clears TIF_SIGPENDING, handles
> > the request and calls recalc_sigpending() before returning.
> >
> > Unfortunately, if the transmission of this cleanup request fails for any
> > reason, the transport returns an error and the client propagates it right
> > away, without calling recalc_sigpending().
> >
> > This ends up with -ERESTARTSYS from the initially interrupted request
> > crawling up to syscall exit, with TIF_SIGPENDING cleared by the cleanup
> > request. The specific signal handling code, which is responsible for
> > converting -ERESTARTSYS to -EINTR is not called, and userspace receives
> > the confusing errno value:
> >
> > open: Unknown error 512 (512)
> >
> > This is really hard to hit in real life. I discovered the issue while
> > working on hot-unplug of a virtio-9p-pci device with an instrumented
> > QEMU allowing to control request completion.
> >
> > Both p9_client_zc_rpc() and p9_client_rpc() functions have this buggy
> > error path actually. Their code flow is a bit obscure and the best
> > thing to do would probably be a full rewrite: to really ensure this
> > situation of clearing TIF_SIGPENDING and returning -ERESTARTSYS can
> > never happen.
> >
> > But given the general lack of interest for the 9p code, I won't risk
> > breaking more things. So this patch simply fixes the buggy paths in
> > both functions with a trivial label+goto.
> >
> > Thanks to Laurent Dufour for his help and suggestions on how to find
> > the root cause and how to fix it.
>
> That's a fairly straightforward-looking bug. However the code still
> looks a bit racy:
>
>
> : if (signal_pending(current)) {
> : sigpending = 1;
> : clear_thread_flag(TIF_SIGPENDING);
> : } else
> : sigpending = 0;
> :
>
> what happens if signal_pending(current) becomes true right here?
>
Depending on the transport c->trans_mod->request() could possibly
return -ERESTARTSYS, and we would then recalc_sigpending() and
propagate -ERESTARTSYS to the caller.
> : err = c->trans_mod->request(c, req);
>
>
> I'm surprised that the 9p client is mucking with signals at all.
> Signals are a userspace IPC scheme and kernel code should instead be
> using the more powerful messaging mechanisms which we've developed.
> Ones which don't disrupt userspace state.
>
> Why is this happening? Is there some userspace/kernel interoperation
> involved?
>
Before commit 9523feac272ccad2ad8186ba4fcc89103754de52, we used to rely
on wait_event_interruptible() instead of wait_event_killable(). IIUC,
the purpose of all this sigpending tweaking was just to allow subsequent
cleanup related requests to be issued, without them being interrupted right
away because of the initial signal.
BTW the issue tentatively fixed by commit
9523feac272ccad2ad8186ba4fcc89103754de52
was more deeply investigated since then. It was caused by a bug in QEMU that
got
fixed, and will be available in the next release (2.12). And to cope with
existing
buggy QEMUs, we can assume that a -EINTR response from the server necessarily
means
the corresponding request has been successfully canceled.
Cheers,
--
Greg
Re: KASAN: use-after-free Read in sctp_association_free (2)
On Sat, Mar 10, 2018 at 03:58:04PM +0800, Xin Long wrote: > On Sat, Mar 10, 2018 at 6:08 AM, Neil Horman wrote: > > On Fri, Mar 09, 2018 at 12:59:06PM -0800, syzbot wrote: > >> Hello, > >> > >> syzbot hit the following crash on net-next commit > >> fd372a7a9e5e9d8011a0222d10edd3523abcd3b1 (Thu Mar 8 19:43:48 2018 +) > >> Merge tag 'mlx5-updates-2018-02-28-2' of > >> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux > >> > >> So far this crash happened 2 times on net-next. > >> C reproducer is attached. > >> syzkaller reproducer is attached. > >> Raw console output is attached. > >> compiler: gcc (GCC) 7.1.1 20170620 > >> .config is attached. > >> > >> IMPORTANT: if you fix the bug, please add the following tag to the commit: > >> Reported-by: syzbot+a4e4112c3aff00c8c...@syzkaller.appspotmail.com > >> It will help syzbot understand when the bug is fixed. See footer for > >> details. > >> If you forward the report, please keep this part and the footer. > >> > >> IPVS: ftp: loaded support on port[0] = 21 > >> IPVS: ftp: loaded support on port[0] = 21 > >> IPVS: ftp: loaded support on port[0] = 21 > >> IPVS: ftp: loaded support on port[0] = 21 > >> == > >> BUG: KASAN: use-after-free in sctp_association_free+0x7b7/0x930 > >> net/sctp/associola.c:332 > >> Read of size 8 at addr 8801d8006ae0 by task syzkaller914861/4202 > >> > >> CPU: 1 PID: 4202 Comm: syzkaller914861 Not tainted 4.16.0-rc4+ #258 > >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > >> Google 01/01/2011 > >> Call Trace: > >> __dump_stack lib/dump_stack.c:17 [inline] > >> dump_stack+0x194/0x24d lib/dump_stack.c:53 > >> print_address_description+0x73/0x250 mm/kasan/report.c:256 > >> kasan_report_error mm/kasan/report.c:354 [inline] > >> kasan_report+0x23c/0x360 mm/kasan/report.c:412 > >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > >> sctp_association_free+0x7b7/0x930 net/sctp/associola.c:332 > >> sctp_sendmsg+0xc67/0x1a80 net/sctp/socket.c:2075 > >> inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763 > >> sock_sendmsg_nosec net/socket.c:629 [inline] > >> sock_sendmsg+0xca/0x110 net/socket.c:639 > >> SYSC_sendto+0x361/0x5c0 net/socket.c:1748 > >> SyS_sendto+0x40/0x50 net/socket.c:1716 > >> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 > >> entry_SYSCALL_64_after_hwframe+0x42/0xb7 > >> RIP: 0033:0x446d09 > >> RSP: 002b:7f5dbac21da8 EFLAGS: 0216 ORIG_RAX: 002c > >> RAX: ffda RBX: 006e29fc RCX: 00446d09 > >> RDX: 0001 RSI: 2340 RDI: 0003 > >> RBP: 006e29f8 R08: 204d9000 R09: 001c > >> R10: R11: 0216 R12: > >> R13: 7fff7b26fb1f R14: 7f5dbac229c0 R15: 006e2b60 > >> > > I think we have a corner case with a0ff660058b88d12625a783ce9e5c1371c87951f > > here. If a peeloff event happens during a wait for sendbuf space, EPIPE > > will be > > returned, and the code path appears to call sctp_association_put twice, > > leading > > to the use after free situation. I'll write a patch this weekend > Hi, Neil, you're right. > > I didn't expect peeloff can be done on a NEW asoc, as peeloff needs > assoc_id, which can only be set when connecting has started. > > But I realized that: > f84af33 sctp: factor out sctp_sendmsg_to_asoc from sctp_sendmsg > > moved sctp_primitive_ASSOCIATE(connecting) before sctp_wait_for_sndbuf > (snd buffer waiting). It means peeloff can be done on a NEW asoc. > So you may want to move it back. > I agree with the root cause, but I'm not sure I agree with just moving the wait_for_sndbuf call back above the call to associate. I'm not sure I like relying on placing a call in a spcific order solely to avoid an error condition that might legitimately occur. I think would rather check the return code at the call site for the complete set of conditions for which we should not free the association. Something like this: diff --git a/net/sctp/socket.c b/net/sctp/socket.c index 7d3476a4860d..a68846d2b0ef 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -2071,8 +2071,9 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len) /* Send msg to the asoc */ err = sctp_sendmsg_to_asoc(asoc, msg, msg_len, transport, sinfo); - if (err < 0 && err != -ESRCH && new) - sctp_association_free(asoc); + if ((err != -ESRCH) && (err != -EPIPE)) + if (err < 0 && new) + sctp_association_free(asoc); out_unlock: release_sock(sk); Which I think also avoids the noted conflict. Thoughts? Neil > One good thing is the fix shouldn't touch the conflict on > https://lkml.org/lkml/2018/3/7/1175 > We can fix it right now, I think. But pls double check it before > submitting the patch. We just can't grow up that fixup for linus > tree's
Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
On 9.3.2018 20:05, Rob Herring wrote: > On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. wrote: >> Hi, >> >> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b >> makes microblaze unbootable. >> >> I'm sorry I can't provide any console output, as nothing appears at all, >> even when setting earlyprintk (or at least I wasn't able to get anything >> back!). > > Ah, looks like microblaze doesn't set CONFIG_NO_BOOTMEM and so > memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK && > !CONFIG_NO_BOOTMEM. AFAICT, microblaze doesn't really need bootmem and > it can be removed, but I'm still investigating. Can you try out this > branch[1]. > > Rob > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git > microblaze-fixes > Let me take a look at it on Monday with the rest of patches sent by you. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs signature.asc Description: OpenPGP digital signature
Re: 4.16-rc3 fails to resume on MacBookPro10,1 -
Hi! > > Ok, I've just tested linux-next, and it works ok for me on thinkpad > > x60. (But that's probably rather different configuration from the > > macbook). > > > > Unfortunately, I could not deduce anything useful from the > > backtraces. Andrew, could you try v4.15 with KPTI disabled ? > > > > Thanks, > > > > Pavel > > This is 4.15 kernel with KPTI disabled: > % grep PAGE_TABLE .config > # CONFIG_PAGE_TABLE_ISOLATION is not set > > As I expected it appears no more infomative to me. > > What I really need is some clue as to what is supposed to be happening > at this point. You may want to add some printks to see where it hangs. But maybe before that, you may want to test CPU hotplug, and make sure s2ram works, etc... Perhaps basic-pm-debugging.txt is good place to start? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy
On Fri, Mar 09, 2018 at 06:06:29PM -0500, Waiman Long wrote: > So you are talking about sched_relax_domain_level and That one I wouldn't be sad to see the back of. > sched_load_balance. This one, that's critical. And this is the perfect time to try and fix the whole isolcpus issue. The primary issue is that to make equivalent functionality available through cpuset, we need to basically start all tasks outside the root group. The equivalent of isolcpus=xxx is a cgroup setup like: root / \ systemother Where other has the @xxx cpus and system the remainder and root.sched_load_balance = 0. Back before cgroups (and the new workqueue stuff), we could've started everything in the !root group, no worry. But now that doesn't work, because a bunch of controllers can't deal with that and everything cgroup expects the cgroupfs to be empty on boot. It's one of my biggest regrets that I didn't 'fix' this before cgroups came along. > I have not removed any bits. I just haven't exposed > them yet. It does seem like these 2 control knobs are useful from the > scheduling perspective. Do we also need cpu_exclusive or just the two > sched control knobs are enough? I always forget if we need exclusive for load_balance to work; I'll peruse the document/code.
[PATCH] arm64: dts: uniphier: use proper SPDX-License-Identifier style
According to Documentation/process/license-rules.rst, move the SPDX License Identifier to the very top of the file. I used C++ comment style not only for the SPDX line but for the entire block because this seems Linus' preference [1]. I also dropped the parentheses to follow the examples in that document. [1] https://lkml.org/lkml/2017/11/25/133 Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 16 +++- arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts| 14 ++ arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 ++ arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 16 +++- arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts| 14 ++ arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 14 ++ arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts| 14 ++ arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 14 ++ 8 files changed, 50 insertions(+), 66 deletions(-) diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts index 0feec41..9b4dc41 100644 --- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts +++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts @@ -1,12 +1,10 @@ -/* - * Device Tree Source for UniPhier LD11 Global Board - * - * Copyright (C) 2016-2017 Socionext Inc. - * Author: Masahiro Yamada - * Kunihiko Hayashi - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) - */ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +// +// Device Tree Source for UniPhier LD11 Global Board +// +// Copyright (C) 2016-2017 Socionext Inc. +// Author: Masahiro Yamada +// Kunihiko Hayashi /dts-v1/; #include diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts index dacdea5..b8f6273 100644 --- a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts +++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts @@ -1,11 +1,9 @@ -/* - * Device Tree Source for UniPhier LD11 Reference Board - * - * Copyright (C) 2016 Socionext Inc. - * Author: Masahiro Yamada - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) - */ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +// +// Device Tree Source for UniPhier LD11 Reference Board +// +// Copyright (C) 2016 Socionext Inc. +// Author: Masahiro Yamada /dts-v1/; #include "uniphier-ld11.dtsi" diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi index f9014c8..5f2da73 100644 --- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi +++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi @@ -1,11 +1,9 @@ -/* - * Device Tree Source for UniPhier LD11 SoC - * - * Copyright (C) 2016 Socionext Inc. - * Author: Masahiro Yamada - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) - */ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +// +// Device Tree Source for UniPhier LD11 SoC +// +// Copyright (C) 2016 Socionext Inc. +// Author: Masahiro Yamada #include #include diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts index 6bee22e..fe6608e 100644 --- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts @@ -1,12 +1,10 @@ -/* - * Device Tree Source for UniPhier LD20 Global Board - * - * Copyright (C) 2015-2017 Socionext Inc. - * Author: Masahiro Yamada - * Kunihiko Hayashi - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) - */ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +// +// Device Tree Source for UniPhier LD20 Global Board +// +// Copyright (C) 2015-2017 Socionext Inc. +// Author: Masahiro Yamada +// Kunihiko Hayashi /dts-v1/; #include diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts index 092574d..2c1a92f 100644 --- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts @@ -1,11 +1,9 @@ -/* - * Device Tree Source for UniPhier LD20 Reference Board - * - * Copyright (C) 2015-2016 Socionext Inc. - * Author: Masahiro Yamada - * - * SPDX-License-Identifier: (GPL-2.0+ OR MIT) - */ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +// +// Device Tree Source for UniPhier LD20 Reference Board +// +// Copyright (C) 2015-2016 Socionext Inc. +// Author: Masahiro Yamada /dts-v1/; #include "uniphier-ld20.dtsi" diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi index 3d5ca4b..458b5b8 100644 --- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi @@ -1,11 +1,9 @@ -/* - * Device Tree Source for UniPhier LD20 SoC - * - * Copyright (C) 2015-2016 Socionext Inc. - * Author: Masahiro
[PATCH] ARM: dts: uniphier: use proper SPDX-License-Identifier style
According to Documentation/process/license-rules.rst, move the SPDX
License Identifier to the very top of the file. I used C++ comment
style not only for the SPDX line but for the entire block because
this seems Linus' preference [1]. I also dropped the parentheses to
follow the examples in that document.
[1] https://lkml.org/lkml/2017/11/25/133
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/uniphier-ld4-ref.dts | 14 ++
arch/arm/boot/dts/uniphier-ld4.dtsi | 14 ++
arch/arm/boot/dts/uniphier-ld6b-ref.dts | 14 ++
arch/arm/boot/dts/uniphier-ld6b.dtsi | 14 ++
arch/arm/boot/dts/uniphier-pinctrl.dtsi | 14 ++
arch/arm/boot/dts/uniphier-pro4-ace.dts | 14 ++
arch/arm/boot/dts/uniphier-pro4-ref.dts | 14 ++
arch/arm/boot/dts/uniphier-pro4-sanji.dts| 14 ++
arch/arm/boot/dts/uniphier-pro4.dtsi | 14 ++
arch/arm/boot/dts/uniphier-pro5.dtsi | 14 ++
arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 14 ++
arch/arm/boot/dts/uniphier-pxs2-vodka.dts| 14 ++
arch/arm/boot/dts/uniphier-pxs2.dtsi | 14 ++
arch/arm/boot/dts/uniphier-ref-daughter.dtsi | 14 ++
arch/arm/boot/dts/uniphier-sld8-ref.dts | 14 ++
arch/arm/boot/dts/uniphier-sld8.dtsi | 14 ++
arch/arm/boot/dts/uniphier-support-card.dtsi | 14 ++
17 files changed, 102 insertions(+), 136 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ld4-ref.dts
index a3afd0c..21407e1 100644
--- a/arch/arm/boot/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld4-ref.dts
@@ -1,11 +1,9 @@
-/*
- * Device Tree Source for UniPhier LD4 Reference Board
- *
- * Copyright (C) 2015-2016 Socionext Inc.
- * Author: Masahiro Yamada
- *
- * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Device Tree Source for UniPhier LD4 Reference Board
+//
+// Copyright (C) 2015-2016 Socionext Inc.
+// Author: Masahiro Yamada
/dts-v1/;
#include "uniphier-ld4.dtsi"
diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ld4.dtsi
index 0459e84..37950ad 100644
--- a/arch/arm/boot/dts/uniphier-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
@@ -1,11 +1,9 @@
-/*
- * Device Tree Source for UniPhier LD4 SoC
- *
- * Copyright (C) 2015-2016 Socionext Inc.
- * Author: Masahiro Yamada
- *
- * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Device Tree Source for UniPhier LD4 SoC
+//
+// Copyright (C) 2015-2016 Socionext Inc.
+// Author: Masahiro Yamada
#include
diff --git a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
index 9327f6b..a0a44a4 100644
--- a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
@@ -1,11 +1,9 @@
-/*
- * Device Tree Source for UniPhier LD6b Reference Board
- *
- * Copyright (C) 2015-2016 Socionext Inc.
- * Author: Masahiro Yamada
- *
- * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Device Tree Source for UniPhier LD6b Reference Board
+//
+// Copyright (C) 2015-2016 Socionext Inc.
+// Author: Masahiro Yamada
/dts-v1/;
#include "uniphier-ld6b.dtsi"
diff --git a/arch/arm/boot/dts/uniphier-ld6b.dtsi
b/arch/arm/boot/dts/uniphier-ld6b.dtsi
index 9a7b25c..4d07a94 100644
--- a/arch/arm/boot/dts/uniphier-ld6b.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld6b.dtsi
@@ -1,11 +1,9 @@
-/*
- * Device Tree Source for UniPhier LD6b SoC
- *
- * Copyright (C) 2015-2016 Socionext Inc.
- * Author: Masahiro Yamada
- *
- * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Device Tree Source for UniPhier LD6b SoC
+//
+// Copyright (C) 2015-2016 Socionext Inc.
+// Author: Masahiro Yamada
/*
* LD6b consists of two silicon dies: D-chip and A-chip.
diff --git a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
index de481c3..0468d9a 100644
--- a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
@@ -1,11 +1,9 @@
-/*
- * Device Tree Source for UniPhier SoCs default pinctrl settings
- *
- * Copyright (C) 2015-2017 Socionext Inc.
- * Author: Masahiro Yamada
- *
- * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
- */
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Device Tree Source for UniPhier SoCs default pinctrl settings
+//
+// Copyright (C) 2015-2017 Socionext Inc.
+// Author: Masahiro Yamada
&pinctrl {
pinctrl_aout: aout {
diff --git a/arch/arm/boot/dts/uniphier-pro4-ace.dts
b/arch/arm/boot/dts/uniphier-pro4-ace.dts
index 92b5cbb..db1b089 100644
--- a/arch/arm/boot/dts/uniphier-pro4-ace.dts
+++ b/arch/arm/boot/dts/uniphier-pro4-ace.dts
@
Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it
On 10.03.2018 14:12, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 01:26:00PM +0100, Maciej S. Szmigiero wrote: >> Without them, it is easy to crash the driver when just playing with >> microcode files > > You're not supposed to play with the microcode files. If you do and > something breaks, you get to keep the pieces. > > If the official microcode files have a problem, then I'm all ears. > Anything else contrived which doesn't actually happen unless someone > manipulates them is not an issue the microcode loader should protect > against. > So, shall we remove data consistency checks of various root-only syscalls then? :) Maciej
arch/h8300/include/asm/byteorder.h:5:0: warning: "__BIG_ENDIAN" redefined
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: cdb06e9d8f520c969676e7d6778cffe5894f079f commit: 101110f6271ce956a049250c907bc960030577f8 Kbuild: always define endianess in kconfig.h date: 2 weeks ago config: h8300-h8300h-sim_defconfig (attached as .config) compiler: h8300-linux-gcc (GCC) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 101110f6271ce956a049250c907bc960030577f8 # save the attached .config to linux build tree make.cross ARCH=h8300 All warnings (new ones prefixed by >>): In file included from include/asm-generic/bitops/le.h:6:0, from arch/h8300/include/asm/bitops.h:177, from include/linux/bitops.h:38, from include/linux/log2.h:16, from include/asm-generic/getorder.h:8, from include/asm-generic/page.h:99, from arch/h8300/include/asm/page.h:5, from arch/h8300/include/asm/string.h:8, from include/linux/string.h:20, from include/linux/uuid.h:20, from include/linux/mod_devicetable.h:13, from scripts/mod/devicetable-offsets.c:3: >> arch/h8300/include/asm/byteorder.h:5:0: warning: "__BIG_ENDIAN" redefined #define __BIG_ENDIAN __ORDER_BIG_ENDIAN__ In file included from :0:0: include/linux/kconfig.h:8:0: note: this is the location of the previous definition #define __BIG_ENDIAN 4321 -- In file included from include/asm-generic/bitops/le.h:6:0, from arch/h8300/include/asm/bitops.h:177, from include/linux/bitops.h:38, from include/linux/kernel.h:11, from include/asm-generic/bug.h:18, from arch/h8300/include/asm/bug.h:8, from include/linux/bug.h:5, from include/linux/page-flags.h:10, from kernel/bounds.c:10: >> arch/h8300/include/asm/byteorder.h:5:0: warning: "__BIG_ENDIAN" redefined #define __BIG_ENDIAN __ORDER_BIG_ENDIAN__ In file included from :0:0: include/linux/kconfig.h:8:0: note: this is the location of the previous definition #define __BIG_ENDIAN 4321 In file included from include/asm-generic/bitops/le.h:6:0, from arch/h8300/include/asm/bitops.h:177, from include/linux/bitops.h:38, from include/linux/kernel.h:11, from include/asm-generic/bug.h:18, from arch/h8300/include/asm/bug.h:8, from include/linux/bug.h:5, from include/linux/thread_info.h:12, from include/asm-generic/current.h:5, from ./arch/h8300/include/generated/asm/current.h:1, from include/linux/sched.h:12, from arch/h8300/kernel/asm-offsets.c:13: >> arch/h8300/include/asm/byteorder.h:5:0: warning: "__BIG_ENDIAN" redefined #define __BIG_ENDIAN __ORDER_BIG_ENDIAN__ In file included from :0:0: include/linux/kconfig.h:8:0: note: this is the location of the previous definition #define __BIG_ENDIAN 4321 vim +/__BIG_ENDIAN +5 arch/h8300/include/asm/byteorder.h d2a5f499 Yoshinori Sato 2015-05-11 4 d2a5f499 Yoshinori Sato 2015-05-11 @5 #define __BIG_ENDIAN __ORDER_BIG_ENDIAN__ d2a5f499 Yoshinori Sato 2015-05-11 6 #include d2a5f499 Yoshinori Sato 2015-05-11 7 :: The code at line 5 was first introduced by commit :: d2a5f4999f6c211adf30d9788349e13988d6f2a7 h8300: Assembly headers :: TO: Yoshinori Sato :: CC: Yoshinori Sato --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Sat, Mar 10, 2018 at 12:50:46PM +0100, Linus Walleij wrote:
> On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer
> wrote:
>
> > The aim of this patchset is to move the GPIO subsystem's documentation
> > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx
> > and compiled into HTML.
>
> Awesome!
>
> > I moved everything except for sysfs.txt, because
> > this file describes the legacy sysfs ABI, and doesn't seem to serve much
> > (non-historical) purpose anymore.
> >
> > There are still some rough edges:
> >
> > * I think the API documentation (kernel-doc) should be moved out of
> > index.rst into more appropriate files.
> > * The headings are arguably wrong, because driver.rst, consumer.rst,
> > etc. use the "document title" style, even though they are part of the
> > GPIO chapter. But the resulting TOC tree is consistent, and I did not
> > want to change almost all headings.
> > * Some of the files could use more :c:func:`...` references and general
> > ReST polish.
> >
> > But I don't want to make this patchset too large.
>
> It's fine, we take it one step at a time.
>
> On Fri, Mar 09, 2018 at 10:41:20AM -0700, Jonathan Corbet wrote:
>
> > Anyway, I'm happy to take these through the docs tree or see them go via
> > GPIO; Linus, what's your preference?
>
> I might have some doc patches that could collide so I can take them.
>
> I take it there will be a v2?
Not necessarily, but if I need to rebase on a different branch, or on
future linux-next, I'll do that. (Or if some other issue is found.)
I thought that patch 8/8 currently requires commit 93db446a424c ("mtd:
nand: move raw NAND related code to the raw/ subdir"), which is in next
through Boris Brezillon's nand tree, but this isn't true. The patchset
(currently) applies to both v4.16-rc4 and next, AFAICS.
Thanks,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
Re: [PATCH] scsi: resolve COMMAND_SIZE at compile time
Hi Bart,
On Fri, 9 Mar 2018 22:47:12 +, Bart Van Assche
wrote:
> On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote:
> > +/*
> > + * SCSI command sizes are as follows, in bytes, for fixed size commands,
> > per
> > + * group: 6, 10, 10, 12, 16, 12, 10, 10. The top three bits of an opcode
> > + * determine its group.
> > + * The size table is encoded into a 32-bit value by subtracting each
> > value
> > + * from 16, resulting in a value of 1715488362
> > + * (6 << 28 + 6 << 24 + 4 << 20 + 0 << 16 + 4 << 12 + 6 << 8 + 6 << 4 +
> > 10).
> > + * Command group 3 is reserved and should never be used.
> > + */
> > +#define COMMAND_SIZE(opcode) \
> > + (16 - (15 & (1715488362 >> (4 * (((opcode) >> 5) & 7)
>
> To me this seems hard to read and hard to verify. Could this have been
> written as a combination of ternary expressions, e.g. using a gcc statement
> expression to ensure that opcode is evaluated once?
That’s what I’d tried initially, e.g.
#define COMMAND_SIZE(opcode) ({ \
int index = ((opcode) >> 5) & 7; \
index == 0 ? 6 : (index == 4 ? 16 : index == 3 || index == 5 ? 12 : 10); \
})
But gcc still reckons that results in a VLA, defeating the initial purpose of
the exercise.
Does it help if I make the magic value construction clearer?
#define SCSI_COMMAND_SIZE_TBL ( \
(16 - 6)\
+ ((16 - 10) << 4) \
+ ((16 - 10) << 8) \
+ ((16 - 12) << 12) \
+ ((16 - 16) << 16) \
+ ((16 - 12) << 20) \
+ ((16 - 10) << 24) \
+ ((16 - 10) << 28))
#define COMMAND_SIZE(opcode)\
(16 - (15 & (SCSI_COMMAND_SIZE_TBL >> (4 * (((opcode) >> 5) & 7)
Regards,
Stephen
pgp03pWqk7H6k.pgp
Description: OpenPGP digital signature
[GIT PULL] Kbuild fixes for v4.16-rc5
Hi Linus, Please pull more Kbuild fixes for v4.16. The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kbuild-fixes-v4.16-2 for you to fetch changes up to 55fe6da9efba102866e2fb5b40b04b6a4b26c19e: kbuild: Handle builtin dtb file names containing hyphens (2018-03-09 01:14:38 +0900) Kbuild fixes for v4.16 (2nd) - make fixdep parse kconfig.h to fix missing rebuild - replace hyphens with underscores in builtin DTB label names - fix typos James Hogan (1): kbuild: Handle builtin dtb file names containing hyphens Matteo Croce (1): scripts/bloat-o-meter: fix typos in help Rasmus Villemoes (3): fixdep: remove stale references to uml-config.h fixdep: remove some false CONFIG_ matches fixdep: do not ignore kconfig.h scripts/Makefile.lib | 8 scripts/basic/fixdep.c | 15 +-- scripts/bloat-o-meter | 2 +- 3 files changed, 10 insertions(+), 15 deletions(-) -- Best Regards Masahiro Yamada
Re: [PATCH] device_handler: remove VLAs
Hi Bart,
On Fri, 9 Mar 2018 22:48:10 +, Bart Van Assche
wrote:
> On Fri, 2018-03-09 at 23:32 +0100, Stephen Kitt wrote:
> > In preparation to enabling -Wvla, remove VLAs and replace them with
> > fixed-length arrays instead.
> >
> > scsi_dh_{alua,emc,rdac} use variable-length array declarations to
> > store command blocks, with the appropriate size as determined by
> > COMMAND_SIZE. This patch replaces these with fixed-sized arrays using
> > MAX_COMMAND_SIZE, so that the array size can be determined at compile
> > time.
>
> If COMMAND_SIZE() is evaluated at compile time, do we still need this patch?
The two patches I sent were supposed to be alternative solutions; see
https://marc.info/?l=linux-scsi&m=152063671005295&w=2 for the introduction (I
seem to have messed up the headers, so the mails didn’t end up threaded
properly).
The MAX_COMMAND_SIZE approach is nice and simple, but I thought it worth
eliminating scsi_command_size_tbl while I was at it...
Regards,
Stephen
pgpMBvDcL8Ium.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH -tip 0/9] kprobes: Cleanup jprobe implementation
On Fri, 9 Mar 2018 18:54:02 -0500 Steven Rostedt wrote: > On Fri, 9 Mar 2018 21:35:17 +0900 > Masami Hiramatsu wrote: > > > Hello, > > > > Since we decided to remove jprobe from kernel last year, > > its APIs are disabled and we worked on moving in-kernel > > jprobe users to kprobes or trace-events. And now no jprobe > > users are here anymore. > > > > I think it is good time to get rid of jprobe implementation > > from the kernel. However, I need other arch developers help > > to complete it, since jprobe is implemented multi arch wide. > > I can remove those code, but can not test all of those. > > > > Here is the series of patches to show how to do that. > > I tried to remove it from x86 tree. Basically we need to > > do 3 things; > > > > - Remove jprobe functions (register/unregister, > >setjump/longjump) from generic/arch-dependent code. > >[1/9][2/9][3/9] > > - Remove break_handler related code. > >[4/9][5/9][6/9] > > - Do not disable preemption on exception handler > >[7/9][8/9][9/9] > > > > The [3/9] and [6/9] are destractive changes except for x86 > > (means causes build errors) since those arch still have some > > references of those functions. So we need to write patches > > similar to [2/9] and [5/9] for each arch before applying those. > > In this series I sorted it as this order just for review, > > [3/9] and [6/9] should be applied after all archs have > > been fixed. > > > > Also, [7/9] is a kind of destractive, which changes required > > behavior for the pre_handlers which changes regs->ip. > > So we also need a patch similar to [7/9] for each arch too. > > Fortunately, current in-tree such user is very limited, both > > works only on x86. So it is not hurry, but we need to change > > arch dependent code. > > > > Hi Masami, > > thanks for doing all this. I do want to review this and your other > patch set. Thanks! > I've just been traveling a lot. I came home from California > yesterday and will be leaving Sunday to Portland for ELC. Will you be > there? Oh, no, sorry I'll not be there. Anyway, I will wait for your review. :) > > -- Steve -- Masami Hiramatsu
Re: [PATCH v2 1/4] dt-bindings: mfd: Add Gateworks System Controller bindings
Hi Tim,
On Mon, Mar 5, 2018 at 7:02 PM, Tim Harvey wrote:
> +
> + hwmon@1 { /* A1: Input Voltage */
> + type = <1>;
> + reg = <0x02>;
Unit address (@1) does not match the 'reg' value.
If someone build this example with W=1 a warning will be shown.
Same problem happens in other places of this example.
Re: [PATCH] EDAC, sb_edac: Remove VLA usage
On Fri, Mar 09, 2018 at 09:02:18PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with a fixed-length array instead.
>
> Fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva
> ---
>
> Notice that due to this change, the field max_interleave is no longer
> used after it has been initialized. Maybe it should be removed?
Yes.
> @@ -110,6 +110,7 @@ static const u32 knl_interleave_list[] = {
> 0xdc, 0xe4, 0xec, 0xf4, 0xfc, /* 15-19 */
> 0x104, 0x10c, 0x114, 0x11c, /* 20-23 */
> };
> +#define MAX_INTERLEAVE ARRAY_SIZE(knl_interleave_list)
define that as the max of all interleave lists array sizes so that
people can update it properly when new interleave lists get added.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH net-next] modules: allow modprobe load regular elf binaries
On Fri, Mar 09, 2018 at 06:34:18PM -0800, Alexei Starovoitov wrote:
> On 3/9/18 11:38 AM, Linus Torvalds wrote:
> > On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds
> > wrote:
> > >
> > > How are you going to handle five processes doing the same setup
> > > concurrently?
Let's keep in mind we don't have a formal way to specify this as well
for modules as well, other than kconfig. Ie it'd be up to the author
of the modules to pick this up and make things mutually exclusive.
> > Side note: it's not just serialization. It's also "is it actually up
> > and running".
> >
> > The rule for "request_module()" (for a real module) has been that it
> > returns when the module is actually alive and active and have done
> > their initcalls.
Unfortunately this is not accurate though, the loose grammar around this fact
is one of the reasons why long term I think either new API should be added, or
the existing request_module() API modified.
request_module() is not deterministic today, try_then_request_module() *is* but
its IMHO its a horrible grammatical solution, and I'm not a fan of the idea of
umh modules perpetuating this nonsense *long term*. Details below.
> > The UMH_WAIT_EXEC behavior (ignore the serialization - you could do
> > that in the caller) behavior doesn't actually have any semantics AT
> > ALL. It only means that you get the error returns from execve()
> > itself, so you know that the executable file actually existed and
> > parsed right enough to get started.
> >
> > But you don't actually have any reason to believe that it has *done*
> > anything, and started processing any requests. There's no reason
> > what-so-ever to believe that it has registered itself for any
> > asynchronous requests or anything like that.
>
> I agree that sync approach nicely fits this use case, but waiting
> for umh brings the whole set of suspend/resume issues that
> Luis explained earlier and if I understood his points that stuff
> is still not quite working right
It works enough that suspend works well enough on Linux today, but the primary
reason is that the big kernel/umh.c API user today is the firmware API for the
old fallback firmware interface and it has in place the sync
usermodehelper_read_trylock() and async async usermodehelper_read_lock_wait().
Note that in the fallback case there is just the uevent call.
> and he's planning a set of fixes.
The move of the umh locks out of the non-fallback case was a long term goal I
had which I was planning on doing slowly, but recently got jump started via
v4.14 via commit f007cad159e9 ("Revert "firmware: add sanity check on
shutdown/suspend"). As such that goal is now complete thanks to Linus correctly
pushing it forward.
> I really don't want the unknown timeline of fixes for 'waiting umh'
> to become a blocker for the bpfilter project ...
The reason for me to bring up the suspend stuff was that there no other
*heavy* UMH API users in the kernel today, and just to highlight that
care must be taken if we want to consider in the future further
possibly heavy UMH callers which we *can* expect to be called around
suspend and resume.
*Iff* that will be the case for these new umh userspace modules, we can
evaluate a future plan. But not that this is as vague as suggesting the
same for any further kernel future UMH API user! If the only umh module
we expect for a while will be bpfilter and it we don't expect heavy use
during suspend/resume this is a non-issue and likely won't be for a while,
and all that *should be done* is become aware of the today's limitations
as we *document* any new API, even if its the simple and easy
request_umh_module*() calls.
Today's use of the UMH API to always use helper_lock() and prevent suspend
while a call is being issued should suffice, so long as these umh modules don't
become heavy users during suspend/resume.
Note that there even *further* further advanced suspend/resume considerations
with filesystems but we have a reasonable hand on what to do there [0] and
it frankly isn't *that* much work as I have most of it done already.
The only other suspend optimization I could think of left to evaluate may be
whether or not to we should generalize something like the firmware cache for
other UMH callers but that's really a long term topic.
So I would not say there is pending work left to do, it should suffice
to document the semantics and limitations if the umh modules are to be
added. That's it.
Linus has proven me right that the *concerns* I've had for these corner
cases are just that, and I do believe documenting the limitations should
suffice for new APIs.
[0] https://lkml.kernel.org/r/20180126090923.gd12...@wotan.suse.de
> Also I like Luis suggestion to use some other name than request_module()
> Something like:
> request_umh_module_sync("foo");
> request_umh_module_nowait("foo");
>
> in both cases the kernel would create a pipe, call umh either
> with UMH_WAIT_PROC or UMH_WAIT_EXEC and make sure that umh
> responds to first
Re: [PATCH 0/3] module: process aliasing when debugging
*Poke* Luis On Wed, Nov 29, 2017 at 6:36 PM, Luis R. Rodriguez wrote: > Debugging ineractions with userspace can often be a bit of pain, specially > when trying to figure out who is at fault for an issue. Having the kernel > process aliases when debugging can help us much faster find who is the > culprit to an issue. > > I've been carrying this around privately in my tree since 2016 but it seems > others can benefit from similar debugging functionality so pushing this out > for integration and wider review. > > Further testing, thoughts, reviews, flames are all equally appreciated. > > Luis R. Rodriguez (3): > module: use goto errors on check_modinfo() and layout_and_allocate() > module: add helper get_modinfo_idx() > module: add debugging alias parsing support > > include/linux/module.h | 4 ++ > init/Kconfig | 7 +++ > kernel/module.c| 129 > +++-- > 3 files changed, 135 insertions(+), 5 deletions(-) > > -- > 2.15.0 >
[PATCH v3 00/20] firmware: development for v4.17
Greg,
Here's a respin of what I have queued up for v4.17 for the firmware API. It
combines the cleanup I've been working on and the addition of the new API call
request_firmware_cache() for fixing a corner case suspend issue on some type of
cards with an optimization in place where the firmware is *not* needed on
reboot.
The cleanup work allows us to test the firmware API with one kernel
configuration. I've addressed Kees' feedback on this respin and
combined the code into drivers/base/firmware_class/.
I've made one new test_firmware change in consideration for one firmware
change, the patch "firmware: ensure the firmware cache is not used on
incompatible calls" requires us to modify our tests scripts to use
the APIs sanely as well.
I've put up these changes on my git tree, refer to the branch
"20180307-firmware-dev-for-v4.17" based on linux-next [0] and
the same name based on Linus' tree [1].
Questions, feedback, and specially rants are always welcomed.
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20180307-firmware-dev-for-v4.17
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=20180307-firmware-dev-for-v4.17
Luis R. Rodriguez (20):
test_firmware: add simple firmware firmware test library
test_firmware: enable custom fallback testing on limited kernel
configs
test_firmware: replace syfs fallback check with kconfig_has helper
firmware: enable to split firmware_class into separate target files
firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further
firmware: use helpers for setting up a temporary cache timeout
firmware: move loading timeout under struct firmware_fallback_config
firmware: split firmware fallback functionality into its own file
firmware: move firmware loader into its own directory
firmware: enable run time change of forcing fallback loader
firmware: enable to force disable the fallback mechanism at run time
test_firmware: expand on library with shared helpers
test_firmware: test three firmware kernel configs using a proc knob
rename: _request_firmware_load() fw_load_sysfs_fallback()
firmware: fix checking for return values for fw_add_devm_name()
firmware: add helper to check to see if fw cache is setup
test_firmware: modify custom fallback tests to use unique files
firmware: ensure the firmware cache is not used on incompatible calls
firmware: add request_firmware_cache() to help with cache on reboot
mt7601u: use request_firmware_cache() to address cache on reboot
.../driver-api/firmware/fallback-mechanisms.rst| 2 +-
.../driver-api/firmware/request_firmware.rst | 14 +
MAINTAINERS| 2 +-
drivers/base/Makefile | 2 +-
drivers/base/firmware_loader/Makefile | 7 +
drivers/base/firmware_loader/fallback.c| 674 +
drivers/base/firmware_loader/fallback.h| 67 ++
drivers/base/firmware_loader/fallback_table.c | 55 ++
drivers/base/firmware_loader/firmware.h| 115 +++
.../{firmware_class.c => firmware_loader/main.c} | 833 ++---
drivers/net/wireless/mediatek/mt7601u/mcu.c| 2 +-
include/linux/firmware.h | 3 +
kernel/sysctl.c| 11 +
tools/testing/selftests/firmware/Makefile | 2 +-
tools/testing/selftests/firmware/config| 4 +
tools/testing/selftests/firmware/fw_fallback.sh| 65 +-
tools/testing/selftests/firmware/fw_filesystem.sh | 72 +-
tools/testing/selftests/firmware/fw_lib.sh | 194 +
tools/testing/selftests/firmware/fw_run_tests.sh | 70 ++
19 files changed, 1332 insertions(+), 862 deletions(-)
create mode 100644 drivers/base/firmware_loader/Makefile
create mode 100644 drivers/base/firmware_loader/fallback.c
create mode 100644 drivers/base/firmware_loader/fallback.h
create mode 100644 drivers/base/firmware_loader/fallback_table.c
create mode 100644 drivers/base/firmware_loader/firmware.h
rename drivers/base/{firmware_class.c => firmware_loader/main.c} (60%)
create mode 100755 tools/testing/selftests/firmware/fw_lib.sh
create mode 100755 tools/testing/selftests/firmware/fw_run_tests.sh
--
2.16.2
[PATCH v3 09/20] firmware: move firmware loader into its own directory
This will make it much easier to manage as we manage to
keep trimming componnents down into their own files to more
easily manage and maintain this codebase.
Suggested-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
MAINTAINERS | 2 +-
drivers/base/Makefile | 7 ++-
drivers/base/firmware_loader/Makefile | 7 +++
drivers/base/{firmware_fallback.c => firmware_loader/fallback.c} | 4 ++--
drivers/base/{firmware_fallback.h => firmware_loader/fallback.h} | 0
.../fallback_table.c} | 4 ++--
drivers/base/{firmware_loader.h => firmware_loader/firmware.h}| 0
drivers/base/{firmware_loader.c => firmware_loader/main.c}| 8
8 files changed, 18 insertions(+), 14 deletions(-)
create mode 100644 drivers/base/firmware_loader/Makefile
rename drivers/base/{firmware_fallback.c => firmware_loader/fallback.c} (99%)
rename drivers/base/{firmware_fallback.h => firmware_loader/fallback.h} (100%)
rename drivers/base/{firmware_fallback_table.c =>
firmware_loader/fallback_table.c} (90%)
rename drivers/base/{firmware_loader.h => firmware_loader/firmware.h} (100%)
rename drivers/base/{firmware_loader.c => firmware_loader/main.c} (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index e03a130902cd..6ddd6f4aaffa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5589,7 +5589,7 @@ M:Luis R. Rodriguez
L: linux-kernel@vger.kernel.org
S: Maintained
F: Documentation/firmware_class/
-F: drivers/base/firmware*.c
+F: drivers/base/firmware_loader/
F: include/linux/firmware.h
FLASH ADAPTER DRIVER (IBM Flash Adapter 900GB Full Height PCI Flash Card)
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index b946a408256d..b9539abec675 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -5,17 +5,14 @@ obj-y := component.o core.o bus.o dd.o
syscore.o \
driver.o class.o platform.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o \
- topology.o container.o property.o cacheinfo.o \
- firmware_fallback_table.o
+ topology.o container.o property.o cacheinfo.o
obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
obj-$(CONFIG_ISA_BUS_API) += isa.o
-obj-$(CONFIG_FW_LOADER)+= firmware_class.o
-firmware_class-objs := firmware_loader.o
-firmware_class-$(CONFIG_FW_LOADER_USER_HELPER) += firmware_fallback.o
+obj-y += firmware_loader/
obj-$(CONFIG_NUMA) += node.o
obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
ifeq ($(CONFIG_SYSFS),y)
diff --git a/drivers/base/firmware_loader/Makefile
b/drivers/base/firmware_loader/Makefile
new file mode 100644
index ..a97eeb0be1d8
--- /dev/null
+++ b/drivers/base/firmware_loader/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+# Makefile for the Linux firmware loader
+
+obj-y := fallback_table.o
+obj-$(CONFIG_FW_LOADER)+= firmware_class.o
+firmware_class-objs := main.o
+firmware_class-$(CONFIG_FW_LOADER_USER_HELPER) += fallback.o
diff --git a/drivers/base/firmware_fallback.c
b/drivers/base/firmware_loader/fallback.c
similarity index 99%
rename from drivers/base/firmware_fallback.c
rename to drivers/base/firmware_loader/fallback.c
index 47690207e0ee..9b65837256d6 100644
--- a/drivers/base/firmware_fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -8,8 +8,8 @@
#include
#include
-#include "firmware_fallback.h"
-#include "firmware_loader.h"
+#include "fallback.h"
+#include "firmware.h"
/*
* firmware fallback mechanism
diff --git a/drivers/base/firmware_fallback.h
b/drivers/base/firmware_loader/fallback.h
similarity index 100%
rename from drivers/base/firmware_fallback.h
rename to drivers/base/firmware_loader/fallback.h
diff --git a/drivers/base/firmware_fallback_table.c
b/drivers/base/firmware_loader/fallback_table.c
similarity index 90%
rename from drivers/base/firmware_fallback_table.c
rename to drivers/base/firmware_loader/fallback_table.c
index 53cc4e492520..981419044c7e 100644
--- a/drivers/base/firmware_fallback_table.c
+++ b/drivers/base/firmware_loader/fallback_table.c
@@ -9,8 +9,8 @@
#include
#include
-#include "firmware_fallback.h"
-#include "firmware_loader.h"
+#include "fallback.h"
+#include "firmware.h"
/*
* firmware fallback configuration table
diff --git a/drivers/base/firmware_loader.h
b/drivers/base/firmware_loader/firmware.h
similarity index 100%
rename from drivers/base/firmware_loader.h
rename to drivers/base/firmware_loader/firmware.h
diff --git a/drivers/bas
[PATCH v3 20/20] mt7601u: use request_firmware_cache() to address cache on reboot
request_firmware_cache() will ensure the firmware is available on resume from suspend if on reboot the device retains the firmware. This optimization is in place given otherwise on reboot we have to reload the firmware, the opmization saves us about max 1s, minimum 10ms. Cantabile has reported back this fixes his woes with both suspend and hibernation. Reported-by: Cantabile Tested-by: Cantabile Signed-off-by: Luis R. Rodriguez --- drivers/net/wireless/mediatek/mt7601u/mcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c b/drivers/net/wireless/mediatek/mt7601u/mcu.c index 65a8004418ea..b90456a4b4d7 100644 --- a/drivers/net/wireless/mediatek/mt7601u/mcu.c +++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c @@ -421,7 +421,7 @@ static int mt7601u_load_firmware(struct mt7601u_dev *dev) MT_USB_DMA_CFG_TX_BULK_EN)); if (firmware_running(dev)) - return 0; + return request_firmware_cache(dev->dev, MT7601U_FIRMWARE); ret = request_firmware(&fw, MT7601U_FIRMWARE, dev->dev); if (ret) -- 2.16.2
[PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot
Some devices have an optimization in place to enable the firmware to
be retaineed during a system reboot, so after reboot the device can skip
requesting and loading the firmware. This can save up to 1s in load
time. The mt7601u 802.11 device happens to be such a device.
When these devices retain the firmware on a reboot and then suspend
they can miss looking for the firmware on resume. To help with this we
need a way to cache the firmware when such an optimization has taken
place.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/request_firmware.rst | 14 +
drivers/base/firmware_loader/main.c| 24 ++
include/linux/firmware.h | 3 +++
3 files changed, 41 insertions(+)
diff --git a/Documentation/driver-api/firmware/request_firmware.rst
b/Documentation/driver-api/firmware/request_firmware.rst
index cc0aea880824..b554f4338859 100644
--- a/Documentation/driver-api/firmware/request_firmware.rst
+++ b/Documentation/driver-api/firmware/request_firmware.rst
@@ -44,6 +44,20 @@ request_firmware_nowait
.. kernel-doc:: drivers/base/firmware_class.c
:functions: request_firmware_nowait
+Special optimizations on reboot
+===
+
+Some devices have an optimization in place to enable the firmware to be
+retained during system reboot. When such optimizations are used the driver
+author must ensure the firmware is still available on resume from suspend,
+this can be done with request_firmware_cache() insted of requesting for the
+firmare to be loaded.
+
+request_firmware_cache()
+---
+.. kernel-doc:: drivers/base/firmware_class.c
+ :functions: request_firmware_load
+
request firmware API expected driver use
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index 2913bb0e5e7b..04bf853f60e9 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -656,6 +656,30 @@ int request_firmware_direct(const struct firmware
**firmware_p,
}
EXPORT_SYMBOL_GPL(request_firmware_direct);
+/**
+ * request_firmware_cache: - cache firmware for suspend so resume can use it
+ * @name: name of firmware file
+ * @device: device for which firmware should be cached for
+ *
+ * There are some devices with an optimization that enables the device to not
+ * require loading firmware on system reboot. This optimization may still
+ * require the firmware present on resume from suspend. This routine can be
+ * used to ensure the firmware is present on resume from suspend in these
+ * situations. This helper is not compatible with drivers which use
+ * request_firmware_into_buf() or request_firmware_nowait() with no uevent set.
+ **/
+int request_firmware_cache(struct device *device, const char *name)
+{
+ int ret;
+
+ mutex_lock(&fw_lock);
+ ret = fw_add_devm_name(device, name);
+ mutex_unlock(&fw_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(request_firmware_cache);
+
/**
* request_firmware_into_buf - load firmware into a previously allocated buffer
* @firmware_p: pointer to firmware image
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index d4508080348d..166867910ebc 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -85,4 +85,7 @@ static inline int request_firmware_into_buf(const struct
firmware **firmware_p,
}
#endif
+
+int request_firmware_cache(struct device *device, const char *name);
+
#endif
--
2.16.2
[PATCH v3 13/20] test_firmware: test three firmware kernel configs using a proc knob
Since we now have knobs to twiddle what used to be set on kernel
configurations we can build one base kernel configuration and modify
behaviour to mimic such kernel configurations to test them.
Provided you build a kernel with:
CONFIG_TEST_FIRMWARE=y
CONFIG_FW_LOADER=y
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
We should now be able test all possible kernel configurations
when FW_LOADER=y. Note that when FW_LOADER=m we just don't provide
the built-in functionality of the built-in firmware.
If you're on an old kernel and either don't have /proc/config.gz
(CONFIG_IKCONFIG_PROC) or haven't enabled CONFIG_FW_LOADER_USER_HELPER
we cannot run these dynamic tests, so just run both scripts just
as we used to before making blunt assumptions about your setup
and requirements exactly as we did before.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/Makefile| 2 +-
tools/testing/selftests/firmware/fw_lib.sh | 51 +
tools/testing/selftests/firmware/fw_run_tests.sh | 70
3 files changed, 122 insertions(+), 1 deletion(-)
create mode 100755 tools/testing/selftests/firmware/fw_run_tests.sh
diff --git a/tools/testing/selftests/firmware/Makefile
b/tools/testing/selftests/firmware/Makefile
index 1894d625af2d..826f38d5dd19 100644
--- a/tools/testing/selftests/firmware/Makefile
+++ b/tools/testing/selftests/firmware/Makefile
@@ -3,7 +3,7 @@
# No binaries, but make sure arg-less "make" doesn't trigger "run_tests"
all:
-TEST_PROGS := fw_filesystem.sh fw_fallback.sh
+TEST_PROGS := fw_run_tests.sh
include ../lib.mk
diff --git a/tools/testing/selftests/firmware/fw_lib.sh
b/tools/testing/selftests/firmware/fw_lib.sh
index e3cc4483fdba..98dceb847ba0 100755
--- a/tools/testing/selftests/firmware/fw_lib.sh
+++ b/tools/testing/selftests/firmware/fw_lib.sh
@@ -47,6 +47,34 @@ check_setup()
{
HAS_FW_LOADER_USER_HELPER="$(kconfig_has
CONFIG_FW_LOADER_USER_HELPER=y)"
HAS_FW_LOADER_USER_HELPER_FALLBACK="$(kconfig_has
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y)"
+ PROC_FW_IGNORE_SYSFS_FALLBACK="0"
+ PROC_FW_FORCE_SYSFS_FALLBACK="0"
+
+ if [ -z $PROC_SYS_DIR ]; then
+ PROC_SYS_DIR="/proc/sys/kernel"
+ fi
+
+ FW_PROC="${PROC_SYS_DIR}/firmware_config"
+ FW_FORCE_SYSFS_FALLBACK="$FW_PROC/force_sysfs_fallback"
+ FW_IGNORE_SYSFS_FALLBACK="$FW_PROC/ignore_sysfs_fallback"
+
+ if [ -f $FW_FORCE_SYSFS_FALLBACK ]; then
+ PROC_FW_FORCE_SYSFS_FALLBACK="$(cat $FW_FORCE_SYSFS_FALLBACK)"
+ fi
+
+ if [ -f $FW_IGNORE_SYSFS_FALLBACK ]; then
+ PROC_FW_IGNORE_SYSFS_FALLBACK="$(cat $FW_IGNORE_SYSFS_FALLBACK)"
+ fi
+
+ if [ "$PROC_FW_FORCE_SYSFS_FALLBACK" = "1" ]; then
+ HAS_FW_LOADER_USER_HELPER="yes"
+ HAS_FW_LOADER_USER_HELPER_FALLBACK="yes"
+ fi
+
+ if [ "$PROC_FW_IGNORE_SYSFS_FALLBACK" = "1" ]; then
+ HAS_FW_LOADER_USER_HELPER_FALLBACK="no"
+ HAS_FW_LOADER_USER_HELPER="no"
+ fi
if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
OLD_TIMEOUT="$(cat /sys/class/firmware/timeout)"
@@ -76,6 +104,28 @@ setup_tmp_file()
fi
}
+proc_set_force_sysfs_fallback()
+{
+ if [ -f $FW_FORCE_SYSFS_FALLBACK ]; then
+ echo -n $1 > $FW_FORCE_SYSFS_FALLBACK
+ check_setup
+ fi
+}
+
+proc_set_ignore_sysfs_fallback()
+{
+ if [ -f $FW_IGNORE_SYSFS_FALLBACK ]; then
+ echo -n $1 > $FW_IGNORE_SYSFS_FALLBACK
+ check_setup
+ fi
+}
+
+proc_restore_defaults()
+{
+ proc_set_force_sysfs_fallback 0
+ proc_set_ignore_sysfs_fallback 0
+}
+
test_finish()
{
if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
@@ -93,6 +143,7 @@ test_finish()
if [ -d $FWPATH ]; then
rm -rf "$FWPATH"
fi
+ proc_restore_defaults
}
kconfig_has()
diff --git a/tools/testing/selftests/firmware/fw_run_tests.sh
b/tools/testing/selftests/firmware/fw_run_tests.sh
new file mode 100755
index ..06d638e9dc62
--- /dev/null
+++ b/tools/testing/selftests/firmware/fw_run_tests.sh
@@ -0,0 +1,70 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# This runs all known tests across all known possible configurations we could
+# emulate in one run.
+
+set -e
+
+TEST_DIR=$(dirname $0)
+source $TEST_DIR/fw_lib.sh
+
+export HAS_FW_LOADER_USER_HELPER=""
+export HAS_FW_LOADER_USER_HELPER_FALLBACK=""
+
+run_tests()
+{
+ proc_set_force_sysfs_fallback $1
+ proc_set_ignore_sysfs_fallback $2
+ $TEST_DIR/fw_filesystem.sh
+
+ proc_set_force_sysfs_fallback $1
+ proc_set_ignore_sysfs_fallback $2
+ $TEST_DIR/fw_fallback.sh
+}
+
+run_test_config_0001()
+{
+ echo "-"
+ echo "Running kernel configuration test 1 -- rare"
+ ec
[PATCH v3 18/20] firmware: ensure the firmware cache is not used on incompatible calls
request_firmware_into_buf() explicitly disables the firmware cache,
meanwhile the firmware cache cannot be used when request_firmware_nowait()
is used without the uevent. Enforce a sanity check for this to avoid future
issues undocumented behaviours should misuses of the firmware cache
happen later.
One of the reasons we want to enforce this is the firmware cache is
used for helping with suspend/resume, and if incompatible calls use it
they can stall suspend.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/main.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index b569d8a09392..2913bb0e5e7b 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -431,6 +431,11 @@ static int fw_add_devm_name(struct device *dev, const char
*name)
return 0;
}
#else
+static bool fw_cache_is_setup(struct device *dev, const char *name)
+{
+ return false;
+}
+
static int fw_add_devm_name(struct device *dev, const char *name)
{
return 0;
@@ -672,6 +677,9 @@ request_firmware_into_buf(const struct firmware
**firmware_p, const char *name,
{
int ret;
+ if (fw_cache_is_setup(device, name))
+ return -EOPNOTSUPP;
+
__module_get(THIS_MODULE);
ret = _request_firmware(firmware_p, name, device, buf, size,
FW_OPT_UEVENT | FW_OPT_NOCACHE);
@@ -769,6 +777,12 @@ request_firmware_nowait(
fw_work->opt_flags = FW_OPT_NOWAIT |
(uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
+ if (!uevent && fw_cache_is_setup(device, name)) {
+ kfree_const(fw_work->name);
+ kfree(fw_work);
+ return -EOPNOTSUPP;
+ }
+
if (!try_module_get(module)) {
kfree_const(fw_work->name);
kfree(fw_work);
--
2.16.2
[PATCH v3 12/20] test_firmware: expand on library with shared helpers
This expands our library with as many things we could find which
both scripts we use share.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 31 +++---
tools/testing/selftests/firmware/fw_filesystem.sh | 41 +++---
tools/testing/selftests/firmware/fw_lib.sh| 52 +++
3 files changed, 63 insertions(+), 61 deletions(-)
diff --git a/tools/testing/selftests/firmware/fw_fallback.sh
b/tools/testing/selftests/firmware/fw_fallback.sh
index 323c921a2469..9337a0328627 100755
--- a/tools/testing/selftests/firmware/fw_fallback.sh
+++ b/tools/testing/selftests/firmware/fw_fallback.sh
@@ -6,30 +6,17 @@
# won't find so that we can do the load ourself manually.
set -e
+TEST_REQS_FW_SYSFS_FALLBACK="yes"
+TEST_REQS_FW_SET_CUSTOM_PATH="no"
TEST_DIR=$(dirname $0)
source $TEST_DIR/fw_lib.sh
check_mods
+check_setup
+verify_reqs
+setup_tmp_file
-HAS_FW_LOADER_USER_HELPER=$(kconfig_has CONFIG_FW_LOADER_USER_HELPER=y)
-HAS_FW_LOADER_USER_HELPER_FALLBACK=$(kconfig_has
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y)
-
-if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
- OLD_TIMEOUT=$(cat /sys/class/firmware/timeout)
-else
- echo "usermode helper disabled so ignoring test"
- exit 0
-fi
-
-FWPATH=$(mktemp -d)
-FW="$FWPATH/test-firmware.bin"
-
-test_finish()
-{
- echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout
- rm -f "$FW"
- rmdir "$FWPATH"
-}
+trap "test_finish" EXIT
load_fw()
{
@@ -168,12 +155,6 @@ load_fw_fallback_with_child()
return $RET
}
-trap "test_finish" EXIT
-
-# This is an unlikely real-world firmware content. :)
-echo "ABCD0123" >"$FW"
-NAME=$(basename "$FW")
-
test_syfs_timeout()
{
DEVPATH="$DIR"/"nope-$NAME"/loading
diff --git a/tools/testing/selftests/firmware/fw_filesystem.sh
b/tools/testing/selftests/firmware/fw_filesystem.sh
index 748f2f5737e9..7f47877fa7fa 100755
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -6,38 +6,15 @@
# know so we can be sure we're not accidentally testing the user helper.
set -e
+TEST_REQS_FW_SYSFS_FALLBACK="no"
+TEST_REQS_FW_SET_CUSTOM_PATH="yes"
TEST_DIR=$(dirname $0)
source $TEST_DIR/fw_lib.sh
check_mods
-
-# CONFIG_FW_LOADER_USER_HELPER has a sysfs class under /sys/class/firmware/
-# These days most distros enable CONFIG_FW_LOADER_USER_HELPER but disable
-# CONFIG_FW_LOADER_USER_HELPER_FALLBACK. We use /sys/class/firmware/ as an
-# indicator for CONFIG_FW_LOADER_USER_HELPER.
-HAS_FW_LOADER_USER_HELPER=$(if [ -d /sys/class/firmware/ ]; then echo yes;
else echo no; fi)
-
-if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
- OLD_TIMEOUT=$(cat /sys/class/firmware/timeout)
-fi
-
-OLD_FWPATH=$(cat /sys/module/firmware_class/parameters/path)
-
-FWPATH=$(mktemp -d)
-FW="$FWPATH/test-firmware.bin"
-
-test_finish()
-{
- if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
- echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout
- fi
- if [ "$OLD_FWPATH" = "" ]; then
- OLD_FWPATH=" "
- fi
- echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path
- rm -f "$FW"
- rmdir "$FWPATH"
-}
+check_setup
+verify_reqs
+setup_tmp_file
trap "test_finish" EXIT
@@ -46,14 +23,6 @@ if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
echo 1 >/sys/class/firmware/timeout
fi
-# Set the kernel search path.
-echo -n "$FWPATH" >/sys/module/firmware_class/parameters/path
-
-# This is an unlikely real-world firmware content. :)
-echo "ABCD0123" >"$FW"
-
-NAME=$(basename "$FW")
-
if printf '\000' >"$DIR"/trigger_request 2> /dev/null; then
echo "$0: empty filename should not succeed" >&2
exit 1
diff --git a/tools/testing/selftests/firmware/fw_lib.sh
b/tools/testing/selftests/firmware/fw_lib.sh
index 467567c758b9..e3cc4483fdba 100755
--- a/tools/testing/selftests/firmware/fw_lib.sh
+++ b/tools/testing/selftests/firmware/fw_lib.sh
@@ -43,6 +43,58 @@ check_mods()
fi
}
+check_setup()
+{
+ HAS_FW_LOADER_USER_HELPER="$(kconfig_has
CONFIG_FW_LOADER_USER_HELPER=y)"
+ HAS_FW_LOADER_USER_HELPER_FALLBACK="$(kconfig_has
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y)"
+
+ if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
+ OLD_TIMEOUT="$(cat /sys/class/firmware/timeout)"
+ fi
+
+ OLD_FWPATH="$(cat /sys/module/firmware_class/parameters/path)"
+}
+
+verify_reqs()
+{
+ if [ "$TEST_REQS_FW_SYSFS_FALLBACK" = "yes" ]; then
+ if [ ! "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then
+ echo "usermode helper disabled so ignoring test"
+ exit 0
+ fi
+ fi
+}
+
+setup_tmp_file()
+{
+ FWPATH=$(mktemp -d)
+ FW="$FWPATH/test-firmware.bin"
+ echo "ABCD0123" >"$FW"
+ NAME=$(basename "$FW")
+ if [ "$TEST_REQS_FW_SET_CUSTOM_PATH" = "yes" ]; then
+ echo
[PATCH v3 16/20] firmware: add helper to check to see if fw cache is setup
Add a helper to check if the firmware cache is already setup for a device.
This will be used later.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/main.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index f5046887e362..b569d8a09392 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -396,13 +396,23 @@ static struct fw_name_devm *fw_find_devm_name(struct
device *dev,
return fwn;
}
-/* add firmware name into devres list */
-static int fw_add_devm_name(struct device *dev, const char *name)
+static bool fw_cache_is_setup(struct device *dev, const char *name)
{
struct fw_name_devm *fwn;
fwn = fw_find_devm_name(dev, name);
if (fwn)
+ return true;
+
+ return false;
+}
+
+/* add firmware name into devres list */
+static int fw_add_devm_name(struct device *dev, const char *name)
+{
+ struct fw_name_devm *fwn;
+
+ if (fw_cache_is_setup(dev, name))
return 0;
fwn = devres_alloc(fw_name_devm_release, sizeof(struct fw_name_devm),
--
2.16.2
[PATCH v3 17/20] test_firmware: modify custom fallback tests to use unique files
Users of the custom firmware fallback interface is are not supposed to
use the firmware cache interface, this can happen if for instance the
one of the APIs which use the firmware cache is used first with one
firmware file and then the request_firmware_nowait(uevent=false) API
is used with the same file.
We'll soon become strict about this on the firmware interface to reject
such calls later, so correct the test scripts to avoid such uses as well.
We address this on the tests scripts by simply using unique names when
testing the custom fallback interface.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 20 ++--
tools/testing/selftests/firmware/fw_filesystem.sh | 11 +--
tools/testing/selftests/firmware/fw_lib.sh| 23 +++
3 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/firmware/fw_fallback.sh
b/tools/testing/selftests/firmware/fw_fallback.sh
index 9337a0328627..8e2e34a2ca69 100755
--- a/tools/testing/selftests/firmware/fw_fallback.sh
+++ b/tools/testing/selftests/firmware/fw_fallback.sh
@@ -238,8 +238,10 @@ run_sysfs_main_tests()
run_sysfs_custom_load_tests()
{
- if load_fw_custom "$NAME" "$FW" ; then
- if ! diff -q "$FW" /dev/test_firmware >/dev/null ; then
+ RANDOM_FILE_PATH=$(setup_random_file)
+ RANDOM_FILE="$(basename $RANDOM_FILE_PATH)"
+ if load_fw_custom "$RANDOM_FILE" "$RANDOM_FILE_PATH" ; then
+ if ! diff -q "$RANDOM_FILE_PATH" /dev/test_firmware >/dev/null
; then
echo "$0: firmware was not loaded" >&2
exit 1
else
@@ -247,8 +249,10 @@ run_sysfs_custom_load_tests()
fi
fi
- if load_fw_custom "$NAME" "$FW" ; then
- if ! diff -q "$FW" /dev/test_firmware >/dev/null ; then
+ RANDOM_FILE_PATH=$(setup_random_file)
+ RANDOM_FILE="$(basename $RANDOM_FILE_PATH)"
+ if load_fw_custom "$RANDOM_FILE" "$RANDOM_FILE_PATH" ; then
+ if ! diff -q "$RANDOM_FILE_PATH" /dev/test_firmware >/dev/null
; then
echo "$0: firmware was not loaded" >&2
exit 1
else
@@ -256,8 +260,12 @@ run_sysfs_custom_load_tests()
fi
fi
- if load_fw_custom_cancel "nope-$NAME" "$FW" ; then
- if diff -q "$FW" /dev/test_firmware >/dev/null ; then
+ RANDOM_FILE_REAL="$RANDOM_FILE_PATH"
+ FAKE_RANDOM_FILE_PATH=$(setup_random_file_fake)
+ FAKE_RANDOM_FILE="$(basename $FAKE_RANDOM_FILE_PATH)"
+
+ if load_fw_custom_cancel "$FAKE_RANDOM_FILE" "$RANDOM_FILE_REAL" ; then
+ if diff -q "$RANDOM_FILE_PATH" /dev/test_firmware >/dev/null ;
then
echo "$0: firmware was expected to be cancelled" >&2
exit 1
else
diff --git a/tools/testing/selftests/firmware/fw_filesystem.sh
b/tools/testing/selftests/firmware/fw_filesystem.sh
index 7f47877fa7fa..6452d2129cd9 100755
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -230,10 +230,13 @@ test_wait_and_cancel_custom_load()
test_request_firmware_nowait_custom_nofile()
{
echo -n "Batched request_firmware_nowait(uevent=false) nofile try #$1: "
+ config_reset
config_unset_uevent
- config_set_name nope-test-firmware.bin
+ RANDOM_FILE_PATH=$(setup_random_file_fake)
+ RANDOM_FILE="$(basename $RANDOM_FILE_PATH)"
+ config_set_name $RANDOM_FILE
config_trigger_async &
- test_wait_and_cancel_custom_load nope-test-firmware.bin
+ test_wait_and_cancel_custom_load $RANDOM_FILE
wait
release_all_firmware
echo "OK"
@@ -271,7 +274,11 @@ test_request_firmware_nowait_uevent()
test_request_firmware_nowait_custom()
{
echo -n "Batched request_firmware_nowait(uevent=false) try #$1: "
+ config_reset
config_unset_uevent
+ RANDOM_FILE_PATH=$(setup_random_file)
+ RANDOM_FILE="$(basename $RANDOM_FILE_PATH)"
+ config_set_name $RANDOM_FILE
config_trigger_async
release_all_firmware
echo "OK"
diff --git a/tools/testing/selftests/firmware/fw_lib.sh
b/tools/testing/selftests/firmware/fw_lib.sh
index 98dceb847ba0..9ea31b57d71a 100755
--- a/tools/testing/selftests/firmware/fw_lib.sh
+++ b/tools/testing/selftests/firmware/fw_lib.sh
@@ -104,6 +104,29 @@ setup_tmp_file()
fi
}
+__setup_random_file()
+{
+ RANDOM_FILE_PATH="$(mktemp -p $FWPATH)"
+ # mktemp says dry-run -n is unsafe, so...
+ if [[ "$1" = "fake" ]]; then
+ rm -rf $RANDOM_FILE_PATH
+ sync
+ else
+ echo "ABCD0123" >"$RANDOM_FILE_PATH"
+ fi
+ echo $RANDOM_FILE_PATH
+}
+
+setup_random_file()
+{
+ echo $(__setup_random_file)
+}
+
+setup_random_file_fak
[PATCH v3 15/20] firmware: fix checking for return values for fw_add_devm_name()
Currently fw_add_devm_name() returns 1 if the firmware cache
was already set. This makes it complicated for us to check for
correctness. It is actually non-fatal if the firmware cache
is already setup, so just return 0, and simplify the checkers.
fw_add_devm_name() adds device's name onto the devres for the
device so that prior to suspend we cache the firmware onto memory,
so that on resume the firmware is reliably available. We never
were checking for success for this call though, meaning in some
really rare cases we my have never setup the firmware cache for
a device, which could in turn make resume fail.
This is all theoretical, no known issues have been reported.
This small issue has been present way since the addition of the
devres firmware cache names on v3.7.
Fixes: f531f05ae9437 ("firmware loader: store firmware name into devres list")
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/main.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base/firmware_loader/main.c
index c8966c84bd44..f5046887e362 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -403,7 +403,7 @@ static int fw_add_devm_name(struct device *dev, const char
*name)
fwn = fw_find_devm_name(dev, name);
if (fwn)
- return 1;
+ return 0;
fwn = devres_alloc(fw_name_devm_release, sizeof(struct fw_name_devm),
GFP_KERNEL);
@@ -431,6 +431,7 @@ int assign_fw(struct firmware *fw, struct device *device,
unsigned int opt_flags)
{
struct fw_priv *fw_priv = fw->priv;
+ int ret;
mutex_lock(&fw_lock);
if (!fw_priv->size || fw_state_is_aborted(fw_priv)) {
@@ -447,8 +448,13 @@ int assign_fw(struct firmware *fw, struct device *device,
*/
/* don't cache firmware handled without uevent */
if (device && (opt_flags & FW_OPT_UEVENT) &&
- !(opt_flags & FW_OPT_NOCACHE))
- fw_add_devm_name(device, fw_priv->fw_name);
+ !(opt_flags & FW_OPT_NOCACHE)) {
+ ret = fw_add_devm_name(device, fw_priv->fw_name);
+ if (ret) {
+ mutex_unlock(&fw_lock);
+ return ret;
+ }
+ }
/*
* After caching firmware image is started, let it piggyback
--
2.16.2
[PATCH v3 14/20] rename: _request_firmware_load() fw_load_sysfs_fallback()
This reflects much clearer what is being done.
While at it, kdoc'ify it.
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +-
drivers/base/firmware_loader/fallback.c | 13 ++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index 4055ac76b288..f353783ae0be 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -112,7 +112,7 @@ Since a device is created for the sysfs interface to help
load firmware as a
fallback mechanism userspace can be informed of the addition of the device by
relying on kobject uevents. The addition of the device into the device
hierarchy means the fallback mechanism for firmware loading has been initiated.
-For details of implementation refer to _request_firmware_load(), in particular
+For details of implementation refer to fw_load_sysfs_fallback(), in particular
on the use of dev_set_uevent_suppress() and kobject_uevent().
The kernel's kobject uevent mechanism is implemented in lib/kobject_uevent.c,
diff --git a/drivers/base/firmware_loader/fallback.c
b/drivers/base/firmware_loader/fallback.c
index d6838e7ec00c..0a8ec7fec585 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -535,8 +535,15 @@ fw_create_instance(struct firmware *firmware, const char
*fw_name,
return fw_sysfs;
}
-/* load a firmware via user helper */
-static int _request_firmware_load(struct fw_sysfs *fw_sysfs,
+/**
+ * fw_load_sysfs_fallback - load a firmware via the syfs fallback mechanism
+ * @fw_sysfs: firmware syfs information for the firmware to load
+ * @opt_flags: flags of options, FW_OPT_*
+ * @timeout: timeout to wait for the load
+ *
+ * In charge of constructing a sysfs fallback interface for firmware loading.
+ **/
+static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
unsigned int opt_flags, long timeout)
{
int retval = 0;
@@ -621,7 +628,7 @@ static int fw_load_from_user_helper(struct firmware
*firmware,
}
fw_sysfs->fw_priv = firmware->priv;
- ret = _request_firmware_load(fw_sysfs, opt_flags, timeout);
+ ret = fw_load_sysfs_fallback(fw_sysfs, opt_flags, timeout);
if (!ret)
ret = assign_fw(firmware, device, opt_flags);
--
2.16.2
[PATCH v3 11/20] firmware: enable to force disable the fallback mechanism at run time
You currently need four different kernel builds to test the firmware
API fully. By adding a proc knob to force disable the fallback mechanism
completely we are able to reduce the amount of kernels you need built
to test the firmware API down to two.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/fallback.c | 5 +
drivers/base/firmware_loader/fallback.h | 4
drivers/base/firmware_loader/fallback_table.c | 9 +
3 files changed, 18 insertions(+)
diff --git a/drivers/base/firmware_loader/fallback.c
b/drivers/base/firmware_loader/fallback.c
index 45cc40933a47..d6838e7ec00c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -643,6 +643,11 @@ static bool fw_force_sysfs_fallback(unsigned int opt_flags)
static bool fw_run_sysfs_fallback(unsigned int opt_flags)
{
+ if (fw_fallback_config.ignore_sysfs_fallback) {
+ pr_info_once("Ignoring firmware sysfs fallback due to debugfs
knob\n");
+ return false;
+ }
+
if ((opt_flags & FW_OPT_NOFALLBACK))
return false;
diff --git a/drivers/base/firmware_loader/fallback.h
b/drivers/base/firmware_loader/fallback.h
index ca7e69a8417b..dfebc644ed35 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -14,12 +14,16 @@
* as if one had enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y.
* Useful to help debug a CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
* functionality on a kernel where that config entry has been disabled.
+ * @ignore_sysfs_fallback: force to disable the sysfs fallback mechanism.
+ * This emulates the behaviour as if we had set the kernel
+ * config CONFIG_FW_LOADER_USER_HELPER=n.
* @old_timeout: for internal use
* @loading_timeout: the timeout to wait for the fallback mechanism before
* giving up, in seconds.
*/
struct firmware_fallback_config {
unsigned int force_sysfs_fallback;
+ unsigned int ignore_sysfs_fallback;
int old_timeout;
int loading_timeout;
};
diff --git a/drivers/base/firmware_loader/fallback_table.c
b/drivers/base/firmware_loader/fallback_table.c
index 92365e053e30..7428659d8df9 100644
--- a/drivers/base/firmware_loader/fallback_table.c
+++ b/drivers/base/firmware_loader/fallback_table.c
@@ -39,6 +39,15 @@ struct ctl_table firmware_config_table[] = {
.extra1 = &zero,
.extra2 = &one,
},
+ {
+ .procname = "ignore_sysfs_fallback",
+ .data = &fw_fallback_config.ignore_sysfs_fallback,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_douintvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &one,
+ },
{ }
};
EXPORT_SYMBOL_GPL(firmware_config_table);
--
2.16.2
[PATCH v3 10/20] firmware: enable run time change of forcing fallback loader
Currently one requires to test four kernel configurations to test the
firmware API completely:
0)
CONFIG_FW_LOADER=y
1)
o CONFIG_FW_LOADER=y
o CONFIG_FW_LOADER_USER_HELPER=y
2)
o CONFIG_FW_LOADER=y
o CONFIG_FW_LOADER_USER_HELPER=y
o CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
3) When CONFIG_FW_LOADER=m the built-in stuff is disabled, we have
no current tests for this.
We can reduce the requirements to three kernel configurations by making
fw_config.force_sysfs_fallback a proc knob we flip on off. For kernels that
disable CONFIG_IKCONFIG_PROC this can also enable one to inspect if
CONFIG_FW_LOADER_USER_HELPER_FALLBACK was enabled at build time by checking
the proc value at boot time.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/fallback.c | 1 +
drivers/base/firmware_loader/fallback.h | 4 +++-
drivers/base/firmware_loader/fallback_table.c | 17 +
kernel/sysctl.c | 11 +++
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/base/firmware_loader/fallback.c
b/drivers/base/firmware_loader/fallback.c
index 9b65837256d6..45cc40933a47 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include "fallback.h"
#include "firmware.h"
diff --git a/drivers/base/firmware_loader/fallback.h
b/drivers/base/firmware_loader/fallback.h
index 550498c7fa4c..ca7e69a8417b 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -12,12 +12,14 @@
*
* @force_sysfs_fallback: force the sysfs fallback mechanism to be used
* as if one had enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y.
+ * Useful to help debug a CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
+ * functionality on a kernel where that config entry has been disabled.
* @old_timeout: for internal use
* @loading_timeout: the timeout to wait for the fallback mechanism before
* giving up, in seconds.
*/
struct firmware_fallback_config {
- const bool force_sysfs_fallback;
+ unsigned int force_sysfs_fallback;
int old_timeout;
int loading_timeout;
};
diff --git a/drivers/base/firmware_loader/fallback_table.c
b/drivers/base/firmware_loader/fallback_table.c
index 981419044c7e..92365e053e30 100644
--- a/drivers/base/firmware_loader/fallback_table.c
+++ b/drivers/base/firmware_loader/fallback_table.c
@@ -19,6 +19,9 @@
/* Module or buit-in */
#ifdef CONFIG_FW_LOADER_USER_HELPER
+static unsigned int zero;
+static unsigned int one = 1;
+
struct firmware_fallback_config fw_fallback_config = {
.force_sysfs_fallback =
IS_ENABLED(CONFIG_FW_LOADER_USER_HELPER_FALLBACK),
.loading_timeout = 60,
@@ -26,4 +29,18 @@ struct firmware_fallback_config fw_fallback_config = {
};
EXPORT_SYMBOL_GPL(fw_fallback_config);
+struct ctl_table firmware_config_table[] = {
+ {
+ .procname = "force_sysfs_fallback",
+ .data = &fw_fallback_config.force_sysfs_fallback,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_douintvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &one,
+ },
+ { }
+};
+EXPORT_SYMBOL_GPL(firmware_config_table);
+
#endif
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6c68e771e11d..7a8aa6866764 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -253,6 +253,10 @@ extern struct ctl_table random_table[];
extern struct ctl_table epoll_table[];
#endif
+#ifdef CONFIG_FW_LOADER_USER_HELPER
+extern struct ctl_table firmware_config_table[];
+#endif
+
#ifdef HAVE_ARCH_PICK_MMAP_LAYOUT
int sysctl_legacy_va_layout;
#endif
@@ -748,6 +752,13 @@ static struct ctl_table kern_table[] = {
.mode = 0555,
.child = usermodehelper_table,
},
+#ifdef CONFIG_FW_LOADER_USER_HELPER
+ {
+ .procname = "firmware_config",
+ .mode = 0555,
+ .child = firmware_config_table,
+ },
+#endif
{
.procname = "overflowuid",
.data = &overflowuid,
--
2.16.2
Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences
On Fri, Mar 09, 2018 at 04:21:37PM -0800, Daniel Lustig wrote: > On 3/9/2018 2:57 PM, Palmer Dabbelt wrote: > > On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.and...@gmail.com wrote: > >> On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote: > >>> On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.and...@gmail.com wrote: > >> > >> [...] > >> > >>> >This proposal relies on the generic definition, > >>> > > >>> > include/linux/atomic.h , > >>> > > >>> >and on the > >>> > > >>> > __atomic_op_acquire() > >>> > __atomic_op_release() > >>> > > >>> >above to build the acquire/release atomics (except for the xchg,cmpxchg, > >>> >where the ACQUIRE_BARRIER is inserted conditionally/on success). > >>> > >>> I thought we wanted to use the AQ and RL bits for AMOs, just not for LR/SC > >>> sequences. IIRC the AMOs are safe with the current memory model, but I > >>> might > >>> just have some version mismatches in my head. > >> > >> AMO.aqrl are "safe" w.r.t. the LKMM (as they provide "full-ordering"); > >> OTOH, > >> AMO.aq and AMO.rl present weaknesses that LKMM (and some kernel developers) > >> do not "expect". I was probing this issue in: > >> > >> https://marc.info/?l=linux-kernel&m=151930201102853&w=2 > >> > >> (c.f., e.g., test "RISCV-unlock-lock-read-ordering" from that post). > >> > >> Quoting from the commit message of my patch 1/2: > >> > >> "Referring to the "unlock-lock-read-ordering" test reported below, > >> Daniel wrote: > >> > >> I think an RCpc interpretation of .aq and .rl would in fact > >> allow the two normal loads in P1 to be reordered [...] > >> > >> [...] > >> > >> Likewise even if the unlock()/lock() is between two stores. > >> A control dependency might originate from the load part of > >> the amoswap.w.aq, but there still would have to be something > >> to ensure that this load part in fact performs after the store > >> part of the amoswap.w.rl performs globally, and that's not > >> automatic under RCpc. > >> > >> Simulation of the RISC-V memory consistency model confirmed this > >> expectation." > >> > >> I have just (re)checked these observations against the latest > >> specification, > >> and my results _confirmed_ these verdicts. > > > > Thanks, I must have just gotten confused about a draft spec or something. > > I'm > > pulling these on top or your other memory model related patch. I've renamed > > the branch "next-mm" to be a bit more descriptiove. > > (Sorry for being out of the loop this week, I was out to deal with > a family matter.) > > I assume you're using the herd model? Luc's doing a great job with > that, but even so, nothing is officially confirmed until we ratify > the model. In other words, the herd model may end up changing too. > If something is broken on our end, there's still time to fix it. No need to say :) if you look back at the LKMM as from 2 years ago or as presented last year in LWN, you won't recognize it as such ;-) Spec. do change/evolve, and so do implementations: if ratifications of the RISC-V memory model (or of the LKMM) will enable optimizations/modifications to these implementations (while preserving correctness), I'll be glad to do or to help with them. To answer your question: I used both the herd-based model from INRIA and the operational model from the group in Cambridge (these are referred to in the currently available RISC-V spec.). > > Regarding AMOs, let me copy from something I wrote in a previous > offline conversation: > > > it seems to us that pairing a store-release of "amoswap.rl" with > > a "ld; fence r,rw" doesn't actually give us the RC semantics we've > > been discussing for LKMM. For example: > > > > (a) sd t0,0(s0) > > (b) amoswap.d.rl x0,t1,0(s1) > > ... > > (c) ld a0,0(s1) > > (d) fence r,rw > > (e) sd t2,0(s2) > > > > There, we won't get (a) ordered before (e) regardless of whether > > (b) is RCpc or RCsc. Do you agree? > > At the moment, only the load part of (b) is in the predecessor > set of (d), but the store part of (b) is not. Likewise, the > .rl annotation applies only to the store part of (b), not the > load part. Indeed. (If you want, this is one reason why, with these patches, ".rl" and "fence r,rw" are never "mixed" as in your snipped above unless there is also a "fence rw,rw" in between.) > > This gets back to a question Linus asked last week about > whether the AMO is a single unit or whether it can be > considered to split into a load and a store part (which still > perform atomically). For RISC-V, for right now at least, the > answer is the latter. Is it still the latter for Linux too? Yes: (successful) atomic RMWs all generate (at least) one load event and one store event in LKMM. (This same approach is taken by other hardware models as well...) > > https://lkml.org/lkml/2018/2/26/606 > > > So I think we'll need to make sure we pair .rl with .aq, or that > > we pair fence-based mappings with fence-based
Re: [RFC 0/1] Loading optional firmware
On Fri, Mar 9, 2018 at 2:12 PM, Andres Rodriguez wrote: > Hi Everyone, > > Wanted to inquire your opinions about the following matter. > > We are experiencing some end user confusion regarding the following messages > being printed to dmesg: > > [0.571324] amdgpu :01:00.0: Direct firmware load for > amdgpu/polaris10_pfp_2.bin failed with error -2 > [0.571338] amdgpu :01:00.0: Direct firmware load for > amdgpu/polaris10_me_2.bin failed with error -2 > [0.571348] amdgpu :01:00.0: Direct firmware load for > amdgpu/polaris10_ce_2.bin failed with error -2 > [0.571366] amdgpu :01:00.0: Direct firmware load for > amdgpu/polaris10_mec_2.bin failed with error -2 > [0.571404] amdgpu :01:00.0: Direct firmware load for > amdgpu/polaris10_mec2_2.bin failed with error -2 > > These firmware blobs are optional. If they aren't available, the graphics card > can still function normally. But having these messages causes the user to > think > their current problems are related to missing firmware. > > It would be great if we could have a mechanism that enabled us to load a > firmware blob without any dmesg spew in case of file not found > errors.Currently > request_firmware_direct() implements this functionality, but as a drawback it > forfeits the usermodehelper fallback path. Yeah, this is a common enough reported type of feature request that I think it makes sense to add now. I'll reply to your patch with a bit more details. Luis
[PATCH v3 08/20] firmware: split firmware fallback functionality into its own file
The firmware fallback code is optional. Split that code out to help
distinguish the fallback functionlity from othere core firmware loader
features. This should make it easier to maintain and review code
changes.
The reason for keeping the configuration onto a table which is built-in
if you enable firmware loading is so that we can later enable the kernel
after subsequent patches to tweak this configuration, even if the
firmware loader is modular.
This introduces no functional changes.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/Makefile | 4 +-
drivers/base/firmware_fallback.c | 661 +++
drivers/base/firmware_fallback.h | 61 +++
drivers/base/firmware_fallback_table.c | 29 ++
drivers/base/firmware_loader.c | 803 +
drivers/base/firmware_loader.h | 115 +
6 files changed, 874 insertions(+), 799 deletions(-)
create mode 100644 drivers/base/firmware_fallback.c
create mode 100644 drivers/base/firmware_fallback.h
create mode 100644 drivers/base/firmware_fallback_table.c
create mode 100644 drivers/base/firmware_loader.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index f261143fafbf..b946a408256d 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -5,7 +5,8 @@ obj-y := component.o core.o bus.o dd.o
syscore.o \
driver.o class.o platform.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o \
- topology.o container.o property.o cacheinfo.o
+ topology.o container.o property.o cacheinfo.o \
+ firmware_fallback_table.o
obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
obj-y += power/
@@ -14,6 +15,7 @@ obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
obj-$(CONFIG_ISA_BUS_API) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
firmware_class-objs := firmware_loader.o
+firmware_class-$(CONFIG_FW_LOADER_USER_HELPER) += firmware_fallback.o
obj-$(CONFIG_NUMA) += node.o
obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
ifeq ($(CONFIG_SYSFS),y)
diff --git a/drivers/base/firmware_fallback.c b/drivers/base/firmware_fallback.c
new file mode 100644
index ..47690207e0ee
--- /dev/null
+++ b/drivers/base/firmware_fallback.c
@@ -0,0 +1,661 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "firmware_fallback.h"
+#include "firmware_loader.h"
+
+/*
+ * firmware fallback mechanism
+ */
+
+extern struct firmware_fallback_config fw_fallback_config;
+
+/* These getters are vetted to use int properly */
+static inline int __firmware_loading_timeout(void)
+{
+ return fw_fallback_config.loading_timeout;
+}
+
+/* These setters are vetted to use int properly */
+static void __fw_fallback_set_timeout(int timeout)
+{
+ fw_fallback_config.loading_timeout = timeout;
+}
+
+/*
+ * use small loading timeout for caching devices' firmware because all these
+ * firmware images have been loaded successfully at lease once, also system is
+ * ready for completing firmware loading now. The maximum size of firmware in
+ * current distributions is about 2M bytes, so 10 secs should be enough.
+ */
+void fw_fallback_set_cache_timeout(void)
+{
+ fw_fallback_config.old_timeout = __firmware_loading_timeout();
+ __fw_fallback_set_timeout(10);
+}
+
+/* Restores the timeout to the value last configured during normal operation */
+void fw_fallback_set_default_timeout(void)
+{
+ __fw_fallback_set_timeout(fw_fallback_config.old_timeout);
+}
+
+static long firmware_loading_timeout(void)
+{
+ return __firmware_loading_timeout() > 0 ?
+ __firmware_loading_timeout() * HZ : MAX_JIFFY_OFFSET;
+}
+
+static inline bool fw_sysfs_done(struct fw_priv *fw_priv)
+{
+ return __fw_state_check(fw_priv, FW_STATUS_DONE);
+}
+
+static inline bool fw_sysfs_loading(struct fw_priv *fw_priv)
+{
+ return __fw_state_check(fw_priv, FW_STATUS_LOADING);
+}
+
+static inline int fw_sysfs_wait_timeout(struct fw_priv *fw_priv, long timeout)
+{
+ return __fw_state_wait_common(fw_priv, timeout);
+}
+
+struct fw_sysfs {
+ bool nowait;
+ struct device dev;
+ struct fw_priv *fw_priv;
+ struct firmware *fw;
+};
+
+static struct fw_sysfs *to_fw_sysfs(struct device *dev)
+{
+ return container_of(dev, struct fw_sysfs, dev);
+}
+
+static void __fw_load_abort(struct fw_priv *fw_priv)
+{
+ /*
+* There is a small window in which user can write to 'loading'
+* between loading done and disappearance of 'loading'
+*/
+ if (fw_sysfs_done(fw_priv))
+ return;
+
+ list_del_init(&fw_priv->pending_list);
+ fw_state_aborted(fw_priv);
+}
+
+sta
[PATCH v3 05/20] firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further
All CONFIG_FW_LOADER_USER_HELPER_FALLBACK really is, is just a bool,
initailized at build time. Define it as such. This simplifies the
logic even further, removing now all explicit #ifdefs around the code.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/base/firmware_loader.c b/drivers/base/firmware_loader.c
index 7dd36ace6152..59dba794ce1a 100644
--- a/drivers/base/firmware_loader.c
+++ b/drivers/base/firmware_loader.c
@@ -266,6 +266,22 @@ static inline bool fw_state_is_aborted(struct fw_priv
*fw_priv)
#ifdef CONFIG_FW_LOADER_USER_HELPER
+/**
+ * struct firmware_fallback_config - firmware fallback configuratioon settings
+ *
+ * Helps describe and fine tune the fallback mechanism.
+ *
+ * @force_sysfs_fallback: force the sysfs fallback mechanism to be used
+ * as if one had enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y.
+ */
+struct firmware_fallback_config {
+ bool force_sysfs_fallback;
+};
+
+static const struct firmware_fallback_config fw_fallback_config = {
+ .force_sysfs_fallback =
IS_ENABLED(CONFIG_FW_LOADER_USER_HELPER_FALLBACK),
+};
+
static inline bool fw_sysfs_done(struct fw_priv *fw_priv)
{
return __fw_state_check(fw_priv, FW_STATUS_DONE);
@@ -1151,19 +1167,14 @@ static int fw_load_from_user_helper(struct firmware
*firmware,
return ret;
}
-#ifdef CONFIG_FW_LOADER_USER_HELPER_FALLBACK
-static bool fw_force_sysfs_fallback(unsigned int opt_flags)
-{
- return true;
-}
-#else
static bool fw_force_sysfs_fallback(unsigned int opt_flags)
{
+ if (fw_fallback_config.force_sysfs_fallback)
+ return true;
if (!(opt_flags & FW_OPT_USERHELPER))
return false;
return true;
}
-#endif
static bool fw_run_sysfs_fallback(unsigned int opt_flags)
{
--
2.16.2
[PATCH v3 06/20] firmware: use helpers for setting up a temporary cache timeout
We only use the timeout for the firmware fallback mechanism
except for trying to set the timeout during the cache setup
for resume/suspend. For those cases, setting the timeout should
be a no-op, so just reflect this in code by adding helpers for it.
This change introduces no functional changes.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 49 ++
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/drivers/base/firmware_loader.c b/drivers/base/firmware_loader.c
index 59dba794ce1a..2d819875348d 100644
--- a/drivers/base/firmware_loader.c
+++ b/drivers/base/firmware_loader.c
@@ -191,13 +191,6 @@ static inline bool fw_is_builtin_firmware(const struct
firmware *fw)
}
#endif
-static int loading_timeout = 60; /* In seconds */
-
-static inline long firmware_loading_timeout(void)
-{
- return loading_timeout > 0 ? loading_timeout * HZ : MAX_JIFFY_OFFSET;
-}
-
static void fw_state_init(struct fw_priv *fw_priv)
{
struct fw_state *fw_st = &fw_priv->fw_st;
@@ -282,6 +275,32 @@ static const struct firmware_fallback_config
fw_fallback_config = {
.force_sysfs_fallback =
IS_ENABLED(CONFIG_FW_LOADER_USER_HELPER_FALLBACK),
};
+static int old_timeout;
+static int loading_timeout = 60; /* In seconds */
+
+static inline long firmware_loading_timeout(void)
+{
+ return loading_timeout > 0 ? loading_timeout * HZ : MAX_JIFFY_OFFSET;
+}
+
+/*
+ * use small loading timeout for caching devices' firmware because all these
+ * firmware images have been loaded successfully at lease once, also system is
+ * ready for completing firmware loading now. The maximum size of firmware in
+ * current distributions is about 2M bytes, so 10 secs should be enough.
+ */
+static void fw_fallback_set_cache_timeout(void)
+{
+ old_timeout = loading_timeout;
+ loading_timeout = 10;
+}
+
+/* Restores the timeout to the value last configured during normal operation */
+static void fw_fallback_set_default_timeout(void)
+{
+ loading_timeout = old_timeout;
+}
+
static inline bool fw_sysfs_done(struct fw_priv *fw_priv)
{
return __fw_state_check(fw_priv, FW_STATUS_DONE);
@@ -1206,6 +1225,8 @@ static int fw_sysfs_fallback(struct firmware *fw, const
char *name,
}
static inline void kill_pending_fw_fallback_reqs(bool only_kill_custom) { }
+static inline void fw_fallback_set_cache_timeout(void) { }
+static inline void fw_fallback_set_default_timeout(void) { }
static inline int register_sysfs_loader(void)
{
@@ -1752,7 +1773,6 @@ static void __device_uncache_fw_images(void)
static void device_cache_fw_images(void)
{
struct firmware_cache *fwc = &fw_cache;
- int old_timeout;
DEFINE_WAIT(wait);
pr_debug("%s\n", __func__);
@@ -1760,16 +1780,7 @@ static void device_cache_fw_images(void)
/* cancel uncache work */
cancel_delayed_work_sync(&fwc->work);
- /*
-* use small loading timeout for caching devices' firmware
-* because all these firmware images have been loaded
-* successfully at lease once, also system is ready for
-* completing firmware loading now. The maximum size of
-* firmware in current distributions is about 2M bytes,
-* so 10 secs should be enough.
-*/
- old_timeout = loading_timeout;
- loading_timeout = 10;
+ fw_fallback_set_cache_timeout();
mutex_lock(&fw_lock);
fwc->state = FW_LOADER_START_CACHE;
@@ -1779,7 +1790,7 @@ static void device_cache_fw_images(void)
/* wait for completion of caching firmware for all devices */
async_synchronize_full_domain(&fw_cache_domain);
- loading_timeout = old_timeout;
+ fw_fallback_set_default_timeout();
}
/**
--
2.16.2
[PATCH v3 07/20] firmware: move loading timeout under struct firmware_fallback_config
The timeout is a fallback construct, so we can just stuff the
timeout configuration under struct firmware_fallback_config.
While at it, add a few helpers which vets the use of getting or
setting the timeout as an int. The main use of the timeout is
to set a timeout for completion, and that is used as an unsigned
long. There a few cases however where it makes sense to get or
set the timeout as an int, the helpers annotate these use cases
have been properly vetted for.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 46 ++
1 file changed, 33 insertions(+), 13 deletions(-)
diff --git a/drivers/base/firmware_loader.c b/drivers/base/firmware_loader.c
index 2d819875348d..9757f9fff01e 100644
--- a/drivers/base/firmware_loader.c
+++ b/drivers/base/firmware_loader.c
@@ -266,21 +266,38 @@ static inline bool fw_state_is_aborted(struct fw_priv
*fw_priv)
*
* @force_sysfs_fallback: force the sysfs fallback mechanism to be used
* as if one had enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y.
+ * @old_timeout: for internal use
+ * @loading_timeout: the timeout to wait for the fallback mechanism before
+ * giving up, in seconds.
*/
struct firmware_fallback_config {
- bool force_sysfs_fallback;
+ const bool force_sysfs_fallback;
+ int old_timeout;
+ int loading_timeout;
};
-static const struct firmware_fallback_config fw_fallback_config = {
+static struct firmware_fallback_config fw_fallback_config = {
.force_sysfs_fallback =
IS_ENABLED(CONFIG_FW_LOADER_USER_HELPER_FALLBACK),
+ .loading_timeout = 60,
+ .old_timeout = 60,
};
-static int old_timeout;
-static int loading_timeout = 60; /* In seconds */
+/* These getters are vetted to use int properly */
+static inline int __firmware_loading_timeout(void)
+{
+ return fw_fallback_config.loading_timeout;
+}
+
+/* These setters are vetted to use int properly */
+static void __fw_fallback_set_timeout(int timeout)
+{
+ fw_fallback_config.loading_timeout = timeout;
+}
static inline long firmware_loading_timeout(void)
{
- return loading_timeout > 0 ? loading_timeout * HZ : MAX_JIFFY_OFFSET;
+ return __firmware_loading_timeout() > 0 ?
+ __firmware_loading_timeout() * HZ : MAX_JIFFY_OFFSET;
}
/*
@@ -291,14 +308,14 @@ static inline long firmware_loading_timeout(void)
*/
static void fw_fallback_set_cache_timeout(void)
{
- old_timeout = loading_timeout;
- loading_timeout = 10;
+ fw_fallback_config.old_timeout = __firmware_loading_timeout();
+ __fw_fallback_set_timeout(10);
}
/* Restores the timeout to the value last configured during normal operation */
static void fw_fallback_set_default_timeout(void)
{
- loading_timeout = old_timeout;
+ __fw_fallback_set_timeout(fw_fallback_config.old_timeout);
}
static inline bool fw_sysfs_done(struct fw_priv *fw_priv)
@@ -677,7 +694,7 @@ static void kill_pending_fw_fallback_reqs(bool
only_kill_custom)
static ssize_t timeout_show(struct class *class, struct class_attribute *attr,
char *buf)
{
- return sprintf(buf, "%d\n", loading_timeout);
+ return sprintf(buf, "%d\n", __firmware_loading_timeout());
}
/**
@@ -696,9 +713,12 @@ static ssize_t timeout_show(struct class *class, struct
class_attribute *attr,
static ssize_t timeout_store(struct class *class, struct class_attribute *attr,
const char *buf, size_t count)
{
- loading_timeout = simple_strtol(buf, NULL, 10);
- if (loading_timeout < 0)
- loading_timeout = 0;
+ int tmp_loading_timeout = simple_strtol(buf, NULL, 10);
+
+ if (tmp_loading_timeout < 0)
+ tmp_loading_timeout = 0;
+
+ __fw_fallback_set_timeout(tmp_loading_timeout);
return count;
}
@@ -721,7 +741,7 @@ static int do_firmware_uevent(struct fw_sysfs *fw_sysfs,
struct kobj_uevent_env
{
if (add_uevent_var(env, "FIRMWARE=%s", fw_sysfs->fw_priv->fw_name))
return -ENOMEM;
- if (add_uevent_var(env, "TIMEOUT=%i", loading_timeout))
+ if (add_uevent_var(env, "TIMEOUT=%i", __firmware_loading_timeout()))
return -ENOMEM;
if (add_uevent_var(env, "ASYNC=%d", fw_sysfs->nowait))
return -ENOMEM;
--
2.16.2
[PATCH v3 01/20] test_firmware: add simple firmware firmware test library
We'll expland on this later, for now just add basic module checker.
While at it, move this all to use /bin/bash as we'll have much more
flexibility with it.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 7 ++--
tools/testing/selftests/firmware/fw_filesystem.sh | 20 ++-
tools/testing/selftests/firmware/fw_lib.sh| 44 +++
3 files changed, 51 insertions(+), 20 deletions(-)
create mode 100755 tools/testing/selftests/firmware/fw_lib.sh
diff --git a/tools/testing/selftests/firmware/fw_fallback.sh
b/tools/testing/selftests/firmware/fw_fallback.sh
index 722cad91df74..755147a8c967 100755
--- a/tools/testing/selftests/firmware/fw_fallback.sh
+++ b/tools/testing/selftests/firmware/fw_fallback.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
# This validates that the kernel will fall back to using the fallback mechanism
# to load firmware it can't find on disk itself. We must request a firmware
@@ -6,9 +6,10 @@
# won't find so that we can do the load ourself manually.
set -e
-modprobe test_firmware
+TEST_DIR=$(dirname $0)
+source $TEST_DIR/fw_lib.sh
-DIR=/sys/devices/virtual/misc/test_firmware
+check_mods
# CONFIG_FW_LOADER_USER_HELPER has a sysfs class under /sys/class/firmware/
# These days no one enables CONFIG_FW_LOADER_USER_HELPER so check for that
diff --git a/tools/testing/selftests/firmware/fw_filesystem.sh
b/tools/testing/selftests/firmware/fw_filesystem.sh
index f9508e1a4058..748f2f5737e9 100755
--- a/tools/testing/selftests/firmware/fw_filesystem.sh
+++ b/tools/testing/selftests/firmware/fw_filesystem.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
# This validates that the kernel will load firmware out of its list of
# firmware locations on disk. Since the user helper does similar work,
@@ -6,24 +6,10 @@
# know so we can be sure we're not accidentally testing the user helper.
set -e
-DIR=/sys/devices/virtual/misc/test_firmware
TEST_DIR=$(dirname $0)
+source $TEST_DIR/fw_lib.sh
-test_modprobe()
-{
- if [ ! -d $DIR ]; then
- echo "$0: $DIR not present"
- echo "You must have the following enabled in your kernel:"
- cat $TEST_DIR/config
- exit 1
- fi
-}
-
-trap "test_modprobe" EXIT
-
-if [ ! -d $DIR ]; then
- modprobe test_firmware
-fi
+check_mods
# CONFIG_FW_LOADER_USER_HELPER has a sysfs class under /sys/class/firmware/
# These days most distros enable CONFIG_FW_LOADER_USER_HELPER but disable
diff --git a/tools/testing/selftests/firmware/fw_lib.sh
b/tools/testing/selftests/firmware/fw_lib.sh
new file mode 100755
index ..c14bbca7ecf9
--- /dev/null
+++ b/tools/testing/selftests/firmware/fw_lib.sh
@@ -0,0 +1,44 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Library of helpers for test scripts.
+set -e
+
+DIR=/sys/devices/virtual/misc/test_firmware
+
+PROC_CONFIG="/proc/config.gz"
+TEST_DIR=$(dirname $0)
+
+print_reqs_exit()
+{
+ echo "You must have the following enabled in your kernel:" >&2
+ cat $TEST_DIR/config >&2
+ exit 1
+}
+
+test_modprobe()
+{
+ if [ ! -d $DIR ]; then
+ print_reqs_exit
+ fi
+}
+
+check_mods()
+{
+ trap "test_modprobe" EXIT
+ if [ ! -d $DIR ]; then
+ modprobe test_firmware
+ fi
+ if [ ! -f $PROC_CONFIG ]; then
+ if modprobe configs 2>/dev/null; then
+ echo "Loaded configs module"
+ if [ ! -f $PROC_CONFIG ]; then
+ echo "You must have the following enabled in
your kernel:" >&2
+ cat $TEST_DIR/config >&2
+ echo "Resorting to old heuristics" >&2
+ fi
+ else
+ echo "Failed to load configs module, using old
heuristics" >&2
+ fi
+ fi
+}
--
2.16.2
[PATCH v3 04/20] firmware: enable to split firmware_class into separate target files
The firmware loader code has grown quite a bit over the years.
The practice of stuffing everything we need into one file makes
the code hard to follow.
In order to split the firmware loader code into different components
we must pick a module name and a first object target file. We must
keep the firmware_class name to remain compatible with scripts which
have been relying on the sysfs loader path for years, so the old module
name stays. We can however rename the C file without affecting the
module name.
The firmware_class used to represent the idea that the code was a simple
sysfs firmware loader, provided by the struct class firmware_class.
The sysfs firmware loader used to be the default, today its only the
fallback mechanism.
This only renames the target code then to make emphasis of what the code
does these days. With this change new features can also use a new object
files.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/Makefile| 1 +
drivers/base/{firmware_class.c => firmware_loader.c} | 0
2 files changed, 1 insertion(+)
rename drivers/base/{firmware_class.c => firmware_loader.c} (100%)
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index e32a52490051..f261143fafbf 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
obj-$(CONFIG_ISA_BUS_API) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
+firmware_class-objs := firmware_loader.o
obj-$(CONFIG_NUMA) += node.o
obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
ifeq ($(CONFIG_SYSFS),y)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_loader.c
similarity index 100%
rename from drivers/base/firmware_class.c
rename to drivers/base/firmware_loader.c
--
2.16.2
