Re: [PATCH v2 2/2] Add PWM fan controller driver for LGM SoC
On Thu, Jun 25, 2020 at 12:23:54PM +0800, Tanwar, Rahul wrote:
>
> Hi Philipp,
>
> On 18/6/2020 8:25 pm, Philipp Zabel wrote:
> > Hi Rahul,
> >
> > On Thu, 2020-06-18 at 20:05 +0800, Rahul Tanwar wrote:
> >> Intel Lightning Mountain(LGM) SoC contains a PWM fan controller.
> >> This PWM controller does not have any other consumer, it is a
> >> dedicated PWM controller for fan attached to the system. Add
> >> driver for this PWM fan controller.
> >>
> >> Signed-off-by: Rahul Tanwar
> >> ---
> >> drivers/pwm/Kconfig | 9 +
> >> drivers/pwm/Makefile| 1 +
> >> drivers/pwm/pwm-intel-lgm.c | 400
> >>
> >> 3 files changed, 410 insertions(+)
> >> create mode 100644 drivers/pwm/pwm-intel-lgm.c
> >>
> > [...]
> >> diff --git a/drivers/pwm/pwm-intel-lgm.c b/drivers/pwm/pwm-intel-lgm.c
> >> new file mode 100644
> >> index ..3c7077acb161
> >> --- /dev/null
> >> +++ b/drivers/pwm/pwm-intel-lgm.c
> >> @@ -0,0 +1,400 @@
> > [...]
> >> +static int lgm_pwm_probe(struct platform_device *pdev)
> >> +{
> >> + struct lgm_pwm_chip *pc;
> >> + struct device *dev = >dev;
> >> + void __iomem *io_base;
> >> + int ret;
> >> +
> >> + pc = devm_kzalloc(dev, sizeof(*pc), GFP_KERNEL);
> >> + if (!pc)
> >> + return -ENOMEM;
> >> +
> >> + io_base = devm_platform_ioremap_resource(pdev, 0);
> >> + if (IS_ERR(io_base))
> >> + return PTR_ERR(io_base);
> >> +
> >> + pc->regmap = devm_regmap_init_mmio(dev, io_base, _regmap_config);
> >> + if (IS_ERR(pc->regmap)) {
> >> + ret = PTR_ERR(pc->regmap);
> >> + dev_err(dev, "failed to init register map: %pe\n", pc->regmap);
> >> + return ret;
> >> + }
> >> +
> >> + pc->clk = devm_clk_get(dev, NULL);
> >> + if (IS_ERR(pc->clk)) {
> >> + ret = PTR_ERR(pc->clk);
> >> + dev_err(dev, "failed to get clock: %pe\n", pc->clk);
> >> + return ret;
> >> + }
> >> +
> >> + pc->rst = devm_reset_control_get(dev, NULL);
> >> + if (IS_ERR(pc->rst)) {
> >> + ret = PTR_ERR(pc->rst);
> >> + dev_err(dev, "failed to get reset control: %pe\n", pc->rst);
> >> + return ret;
> >> + }
> > Please use devm_reset_control_get_exclusive() to make it explicit an
> > that exclusive reset control is requested. Given how the reset control
> > is used, I think this driver could also use
> > devm_reset_control_get_shared() to potentially allow sharing a reset
> > line with other devices.
>
> devm_reset_control_get() is a wrapper for devm_reset_control_get_exclusive().
> Code as below:
> static inline struct reset_control *devm_reset_control_get(
> struct device *dev, const char *id)
> {
> return devm_reset_control_get_exclusive(dev, id);
> }
> Am i missing something else?
Obviously you're missing the comment above of_reset_control_get about
some functions being compatibility wrappers.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH] mm/spase: never partially remove memmap for early section
> Am 25.06.2020 um 01:47 schrieb Dan Williams : > > On Wed, Jun 24, 2020 at 3:44 PM Wei Yang > wrote: > [..] >>> So, you are right that there is a mismatch here, but I think the >>> comprehensive fix is to allow early sections to be partially >>> depopulated/repopulated rather than have section_activate() and >>> section_deacticate() special case early sections. The special casing >>> is problematic in retrospect as section_deactivate() can't be >>> maintained without understand special rules in section_activate(). >> >> Hmm... This means we need to adjust pfn_valid() too, which always return true >> for early sections. > > Right, rather than carry workarounds in 3 locations, and the bug that > has resulted from then getting out of sync, just teach early section > mapping to allow for the subsection populate/depopulate. > I prefer the easy fix first - IOW what we Here here. Especially, pfn_to_online_page() will need changes as well. At least my ack stands.
Re: [PATCH -v2.1] x86/msr: Filter MSR writes
On Mon, Jun 15, 2020 at 08:38:37AM +0200, Borislav Petkov wrote:
> Here's an improved v2 with sparse warnings fixed:
>
> ---
> Disable writing to MSRs from userspace by default. Writes can still be
> allowed by supplying the allow_writes=1 module parameter and the kernel
> will be tainted so that it shows in oopses.
>
> Having unfettered access to all MSRs on a system is and has always been
> a disaster waiting to happen. Think performance counter MSRs, MSRs with
> sticky or locked bits, MSRs making major system changes like loading
> microcode, MTRRs, PAT configuration, TSC counter, security mitigations
> MSRs, you name it.
>
> This also destroys all the kernel's caching of MSR values for
> performance, as the recent case with MSR_AMD64_LS_CFG showed.
>
> Another example is writing MSRs by mistake by simply typing the wrong
> MSR address. System freezes have been experienced that way.
>
> In general, poking at MSRs under the kernel's feet is a bad bad idea.
>
> So disable poking directly at the MSRs by default. If userspace still
> wants to do that, then proper interfaces should be defined which
> are under the kernel's control and accesses to those MSRs can be
> synchronized and sanitized properly.
>
> Changelog:
> - taint before WRMSR, all
> - make param 0600, Sean.
> - do not deny but log writes by default, Linus.
>
> [ Fix sparse warnings ]
> Reported-by: kernel test robot
> Signed-off-by: Borislav Petkov
A few non-functional nits below.
Tested-by: Sean Christopherson
> ---
> arch/x86/kernel/msr.c | 69 +++
> 1 file changed, 69 insertions(+)
>
> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> index 1547be359d7f..576c43e39247 100644
> --- a/arch/x86/kernel/msr.c
> +++ b/arch/x86/kernel/msr.c
> @@ -42,6 +42,14 @@
> static struct class *msr_class;
> static enum cpuhp_state cpuhp_msr_state;
>
> +enum allow_write_msrs {
> + MSR_WRITES_ON,
> + MSR_WRITES_OFF,
> + MSR_WRITES_DEFAULT,
> +};
> +
> +static enum allow_write_msrs allow_writes = MSR_WRITES_DEFAULT;
> +
> static ssize_t msr_read(struct file *file, char __user *buf,
> size_t count, loff_t *ppos)
> {
> @@ -70,6 +78,24 @@ static ssize_t msr_read(struct file *file, char __user
> *buf,
> return bytes ? bytes : err;
> }
>
> +static int filter_write(u32 reg)
> +{
> + switch (allow_writes) {
> + case MSR_WRITES_ON: return 0; break;
> + case MSR_WRITES_OFF: return -EPERM; break;
The breaks after the returns are unnecessary.
> + default: break;
> + }
> +
> + if (reg == MSR_IA32_ENERGY_PERF_BIAS)
> + return 0;
> +
> + pr_err_ratelimited("Write to unrecognized MSR 0x%x by %s\n"
> +"Please report to x...@kernel.org\n",
> +reg, current->comm);
Maybe s/unrecognized/unauthorized? Unrecognized implies the kernel doesn't
know anything about the MSR being written, which may not hold true.
> + return 0;
> +}
> +
> static ssize_t msr_write(struct file *file, const char __user *buf,
>size_t count, loff_t *ppos)
> {
> @@ -84,6 +110,10 @@ static ssize_t msr_write(struct file *file, const char
> __user *buf,
> if (err)
> return err;
>
> + err = filter_write(reg);
> + if (err)
> + return err;
> +
> if (count % 8)
> return -EINVAL; /* Invalid chunk size */
>
> @@ -92,9 +122,13 @@ static ssize_t msr_write(struct file *file, const char
> __user *buf,
> err = -EFAULT;
> break;
> }
> +
> + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
> +
> err = wrmsr_safe_on_cpu(cpu, reg, data[0], data[1]);
> if (err)
> break;
> +
Random leftover whitespace change.
> tmp += 2;
> bytes += 8;
> }
Re: [RFC] Reed-Solomon Code: Update no_eras to the actual number of errors
On Wed, 2020-06-24 at 22:35 -0700, Kees Cook wrote:
> On Wed, Jun 24, 2020 at 09:10:53PM -0700, Aiden Leong wrote:
> > Corr and eras_pos are updated to actual correction pattern and erasure
> > positions, but no_eras is not.
[]
> > @@ -312,14 +313,21 @@
> > eras_pos[j++] = loc[i] - pad;
> > }
> > }
> > + if (no_eras > 0)
> > + *no_eras = j;
>
> Is this meant to be "if (j > 0)" or "if (no_eras != NULL)" ? It's
> uncommon to use > 0 for a pointer value.
>
> > } else if (data && par) {
> > /* Apply error to data and parity */
> > + j = 0;
> > for (i = 0; i < count; i++) {
> > if (loc[i] < (nn - nroots))
> > data[loc[i] - pad] ^= b[i];
> > else
> > par[loc[i] - pad - len] ^= b[i];
> > + if (b[i])
> > + j++;
> > }
> > + if (no_eras > 0)
> > + *no_eras = j;
>
> I assume it's a pointer test, so both would be:
>
> if (no_eras_ptr != NULL)
> *no_eras_ptr = j;
More common still would be
if (no_eras_ptr)
*no_eras_ptr = j;
though I think using _ptr is too Hungarian.
Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()
On 2020-06-24 20:02, Souptick Joarder wrote:
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information. This is case 5 as per document [1].
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: Souptick Joarder
Cc: John Hubbard
Cc: Boris Ostrovsky
Cc: Paul Durrant
---
Hi,
I'm compile tested this, but unable to run-time test, so any testing
help is much appriciated.
drivers/xen/privcmd.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 0da417c..eb05254 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -595,7 +595,7 @@ static int lock_pages(
if (requested > nr_pages)
return -ENOSPC;
- page_count = get_user_pages_fast(
+ page_count = pin_user_pages_fast(
(unsigned long) kbufs[i].uptr,
requested, FOLL_WRITE, pages);
if (page_count < 0) {
@@ -612,13 +612,7 @@ static int lock_pages(
static void unlock_pages(struct page *pages[], unsigned int nr_pages)
{
- unsigned int i;
-
- for (i = 0; i < nr_pages; i++) {
- if (!PageDirty(page))
- set_page_dirty_lock(page);
- put_page(pages[i]);
- }
+ unpin_user_pages_dirty_lock(pages, nr_pages, 1);
"true", not "1", is the correct way to call that function.
Also, this approach changes the behavior slightly, but I think it's
reasonable to just set_page_dirty_lock() on the whole range--hard to
see much benefit in checking PageDirty first.
}
static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
thanks,
--
John Hubbard
NVIDIA
Re: [PATCH 3/8] arm64: dts: qcom: sdm630: Add tsens node
On Wed, Jun 24, 2020 at 8:32 PM Konrad Dybcio wrote: > > Interesting, the downstream DTS only mentions the 0x010AD one.. > Are you sure you're not looking at 636/660? > I looked a bit closer. So there are two instances of the controller but the platform doesn't have as many sensors. So using just one controller is fine. I suspect the other controller might be disabled in firmware. Regards, Amit
RE: [PATCH -next] scsi: ufs: allow exynos ufs driver to build as module
>
> Allow Exynos UFS driver to build as a module.
> This patch fix the below build issue reported by
> kernel build robot.
>
> drivers/scsi/ufs/ufs-exynos.o: in function `exynos_ufs_probe':
> drivers/scsi/ufs/ufs-exynos.c:1231: undefined reference to
> `ufshcd_pltfrm_init'
> drivers/scsi/ufs/ufs-exynos.o: in function `exynos_ufs_pre_pwr_mode':
> drivers/scsi/ufs/ufs-exynos.c:635: undefined reference to
> `ufshcd_get_pwr_dev_param'
> drivers/scsi/ufs/ufs-exynos.o:undefined reference to
> `ufshcd_pltfrm_shutdown'
> drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_suspend'
> drivers/scsi/ufs/ufs-exynos.o:undefined reference to `ufshcd_pltfrm_resume'
> drivers/scsi/ufs/ufs-exynos.o:undefined reference to
> `ufshcd_pltfrm_runtime_suspend'
> drivers/scsi/ufs/ufs-exynos.o:undefined reference to
> `ufshcd_pltfrm_runtime_resume'
> drivers/scsi/ufs/ufs-exynos.o:undefined reference to
> `ufshcd_pltfrm_runtime_idle'
>
> Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos
> SoCs")
> Reported-by: kernel test robot
> Signed-off-by: Alim Akhtar
Reviewed-by: Avri Altman
Re: [RFC] Reed-Solomon Code: Update no_eras to the actual number of errors
On Wed, Jun 24, 2020 at 09:10:53PM -0700, Aiden Leong wrote:
> Corr and eras_pos are updated to actual correction pattern and erasure
> positions, but no_eras is not.
>
> When this library is used to recover lost bytes, we normally memset the
> lost trunk of bytes to zero as a placeholder. Unfortunately, if the lost
> byte is zero, b[i] is zero too. Without correct no_eras, users won't be
> able to determine the valid length of corr and eras_pos.
>
> Signed-off-by: Aiden Leong
> ---
> drivers/md/dm-verity-fec.c | 2 +-
> fs/pstore/ram_core.c| 2 +-
> include/linux/rslib.h | 4 ++--
> lib/reed_solomon/decode_rs.c| 20 ++--
> lib/reed_solomon/reed_solomon.c | 4 ++--
> lib/reed_solomon/test_rslib.c | 18 --
> 6 files changed, 32 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c
> index fb41b4f23c48..ae8366a50244 100644
> --- a/drivers/md/dm-verity-fec.c
> +++ b/drivers/md/dm-verity-fec.c
> @@ -50,7 +50,7 @@ static int fec_decode_rs8(struct dm_verity *v, struct
> dm_verity_fec_io *fio,
> for (i = 0; i < v->fec->roots; i++)
> par[i] = fec[i];
>
> - return decode_rs8(fio->rs, data, par, v->fec->rsn, NULL, neras,
> + return decode_rs8(fio->rs, data, par, v->fec->rsn, NULL, ,
> fio->erasures, 0, NULL);
> }
>
> diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
> index aa8e0b65ff1a..fcc661a60640 100644
> --- a/fs/pstore/ram_core.c
> +++ b/fs/pstore/ram_core.c
> @@ -115,7 +115,7 @@ static int persistent_ram_decode_rs8(struct
> persistent_ram_zone *prz,
>
> for (i = 0; i < prz->ecc_info.ecc_size; i++)
> prz->ecc_info.par[i] = ecc[i];
> - return decode_rs8(prz->rs_decoder, data, prz->ecc_info.par, len,
> + return decode_rs8(prz->rs_decoder, data, prz->ecc_info.par, ,
> NULL, 0, NULL, 0, NULL);
This looks like the wrong arg changed -- did you compile test this?
> }
>
> diff --git a/include/linux/rslib.h b/include/linux/rslib.h
> index 238bb85243d3..80662abc9af7 100644
> --- a/include/linux/rslib.h
> +++ b/include/linux/rslib.h
> @@ -64,7 +64,7 @@ int encode_rs8(struct rs_control *rs, uint8_t *data, int
> len, uint16_t *par,
> #endif
> #ifdef CONFIG_REED_SOLOMON_DEC8
> int decode_rs8(struct rs_control *rs, uint8_t *data, uint16_t *par, int len,
> - uint16_t *s, int no_eras, int *eras_pos, uint16_t invmsk,
> + uint16_t *s, int *no_eras, int *eras_pos, uint16_t invmsk,
> uint16_t *corr);
> #endif
>
> @@ -75,7 +75,7 @@ int encode_rs16(struct rs_control *rs, uint16_t *data, int
> len, uint16_t *par,
> #endif
> #ifdef CONFIG_REED_SOLOMON_DEC16
> int decode_rs16(struct rs_control *rs, uint16_t *data, uint16_t *par, int
> len,
> - uint16_t *s, int no_eras, int *eras_pos, uint16_t invmsk,
> + uint16_t *s, int *no_eras, int *eras_pos, uint16_t invmsk,
> uint16_t *corr);
> #endif
>
> diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c
> index 805de84ae83d..122bc08eb75f 100644
> --- a/lib/reed_solomon/decode_rs.c
> +++ b/lib/reed_solomon/decode_rs.c
> @@ -24,6 +24,7 @@
> int count = 0;
> int num_corrected;
> uint16_t msk = (uint16_t) rs->nn;
> + int no_eras_orig = no_eras ? *no_eras : 0;
To avoid code churn, I would name this int no_eras, and change the arg
to something like no_eras_ptr:
int no_eras = no_eras_ptr ? *no_eras_ptr : 0;
>
> /*
>* The decoder buffers are in the rs control struct. They are
> @@ -106,11 +107,11 @@
> memset([1], 0, nroots * sizeof(lambda[0]));
> lambda[0] = 1;
>
> - if (no_eras > 0) {
> + if (no_eras_orig > 0) {
> /* Init lambda to be the erasure locator polynomial */
> lambda[1] = alpha_to[rs_modnn(rs,
> prim * (nn - 1 - (eras_pos[0] + pad)))];
> - for (i = 1; i < no_eras; i++) {
> + for (i = 1; i < no_eras_orig; i++) {
> u = rs_modnn(rs, prim * (nn - 1 - (eras_pos[i] + pad)));
> for (j = i + 1; j > 0; j--) {
> tmp = index_of[lambda[j - 1]];
> @@ -129,8 +130,8 @@
>* Begin Berlekamp-Massey algorithm to determine error+erasure
>* locator polynomial
>*/
> - r = no_eras;
> - el = no_eras;
> + r = no_eras_orig;
> + el = no_eras_orig;
> while (++r <= nroots) { /* r is the step number */
> /* Compute discrepancy at the r-th step in poly-form */
> discr_r = 0;
> @@ -158,8 +159,8 @@
> } else
> t[i + 1] = lambda[i + 1];
> }
> - if (2 * el <= r + no_eras - 1) {
> - el = r + no_eras - el;
> +
[PATCH] ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU
On a 144 thread system, `perf ftrace` takes about 20 seconds to start
up, due to calling synchronize_rcu() for each CPU.
cat /proc/108560/stack
0xc0003e7eb336f470
__switch_to+0x2e0/0x480
__wait_rcu_gp+0x20c/0x220
synchronize_rcu+0x9c/0xc0
ring_buffer_reset_cpu+0x88/0x2e0
tracing_reset_online_cpus+0x84/0xe0
tracing_open+0x1d4/0x1f0
On a system with 10x more threads, it starts to become an annoyance.
Batch these up so we disable all the per-cpu buffers first, then
synchronize_rcu() once, then reset each of the buffers. This brings
the time down to about 0.5s.
Cc: Paul McKenney
Cc: Anton Blanchard
Cc: Steven Rostedt
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Nicholas Piggin
---
include/linux/ring_buffer.h | 1 +
kernel/trace/ring_buffer.c | 85 +++--
kernel/trace/trace.c| 4 +-
3 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index c76b2f3b3ac4..136ea0997e6d 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -143,6 +143,7 @@ bool ring_buffer_iter_dropped(struct ring_buffer_iter
*iter);
unsigned long ring_buffer_size(struct trace_buffer *buffer, int cpu);
void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu);
+void ring_buffer_reset_online_cpus(struct trace_buffer *buffer);
void ring_buffer_reset(struct trace_buffer *buffer);
#ifdef CONFIG_RING_BUFFER_ALLOW_SWAP
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index b8e1ca48be50..3f1fd02bd14a 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -270,6 +270,9 @@ EXPORT_SYMBOL_GPL(ring_buffer_event_data);
#define for_each_buffer_cpu(buffer, cpu) \
for_each_cpu(cpu, buffer->cpumask)
+#define for_each_online_buffer_cpu(buffer, cpu)\
+ for_each_cpu_and(cpu, buffer->cpumask, cpu_online_mask)
+
#define TS_SHIFT 27
#define TS_MASK((1ULL << TS_SHIFT) - 1)
#define TS_DELTA_TEST (~TS_MASK)
@@ -4484,6 +4487,26 @@ rb_reset_cpu(struct ring_buffer_per_cpu *cpu_buffer)
rb_head_page_activate(cpu_buffer);
}
+/* Must have disabled the cpu buffer then done a synchronize_rcu */
+static void reset_disabled_cpu_buffer(struct ring_buffer_per_cpu *cpu_buffer)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(_buffer->reader_lock, flags);
+
+ if (RB_WARN_ON(cpu_buffer, local_read(_buffer->committing)))
+ goto out;
+
+ arch_spin_lock(_buffer->lock);
+
+ rb_reset_cpu(cpu_buffer);
+
+ arch_spin_unlock(_buffer->lock);
+
+ out:
+ raw_spin_unlock_irqrestore(_buffer->reader_lock, flags);
+}
+
/**
* ring_buffer_reset_cpu - reset a ring buffer per CPU buffer
* @buffer: The ring buffer to reset a per cpu buffer of
@@ -4492,7 +4515,6 @@ rb_reset_cpu(struct ring_buffer_per_cpu *cpu_buffer)
void ring_buffer_reset_cpu(struct trace_buffer *buffer, int cpu)
{
struct ring_buffer_per_cpu *cpu_buffer = buffer->buffers[cpu];
- unsigned long flags;
if (!cpumask_test_cpu(cpu, buffer->cpumask))
return;
@@ -4503,24 +4525,42 @@ void ring_buffer_reset_cpu(struct trace_buffer *buffer,
int cpu)
/* Make sure all commits have finished */
synchronize_rcu();
- raw_spin_lock_irqsave(_buffer->reader_lock, flags);
+ reset_disabled_cpu_buffer(cpu_buffer);
- if (RB_WARN_ON(cpu_buffer, local_read(_buffer->committing)))
- goto out;
+ atomic_dec(_buffer->record_disabled);
+ atomic_dec(_buffer->resize_disabled);
+}
+EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu);
- arch_spin_lock(_buffer->lock);
+/**
+ * ring_buffer_reset_cpu - reset a ring buffer per CPU buffer
+ * @buffer: The ring buffer to reset a per cpu buffer of
+ * @cpu: The CPU buffer to be reset
+ */
+void ring_buffer_reset_online_cpus(struct trace_buffer *buffer)
+{
+ struct ring_buffer_per_cpu *cpu_buffer;
+ int cpu;
- rb_reset_cpu(cpu_buffer);
+ for_each_online_buffer_cpu(buffer, cpu) {
+ cpu_buffer = buffer->buffers[cpu];
- arch_spin_unlock(_buffer->lock);
+ atomic_inc(_buffer->resize_disabled);
+ atomic_inc(_buffer->record_disabled);
+ }
- out:
- raw_spin_unlock_irqrestore(_buffer->reader_lock, flags);
+ /* Make sure all commits have finished */
+ synchronize_rcu();
- atomic_dec(_buffer->record_disabled);
- atomic_dec(_buffer->resize_disabled);
+ for_each_online_buffer_cpu(buffer, cpu) {
+ cpu_buffer = buffer->buffers[cpu];
+
+ reset_disabled_cpu_buffer(cpu_buffer);
+
+ atomic_dec(_buffer->record_disabled);
+ atomic_dec(_buffer->resize_disabled);
+ }
}
-EXPORT_SYMBOL_GPL(ring_buffer_reset_cpu);
/**
* ring_buffer_reset - reset a ring buffer
@@ -4528,10 +4568,27 @@
[PATCH 5.7.y] erofs: fix partially uninitialized misuse in z_erofs_onlinepage_fixup
From: Gao Xiang
commit 3c597282887fd55181578996dca52ce697d985a5 upstream.
Hongyu reported "id != index" in z_erofs_onlinepage_fixup() with
specific aarch64 environment easily, which wasn't shown before.
After digging into that, I found that high 32 bits of page->private
was set to 0x rather than 0 (due to z_erofs_onlinepage_init
behavior with specific compiler options). Actually we only use low
32 bits to keep the page information since page->private is only 4
bytes on most 32-bit platforms. However z_erofs_onlinepage_fixup()
uses the upper 32 bits by mistake.
Let's fix it now.
Reported-and-tested-by: Hongyu Jin
Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc: # 4.19+
Reviewed-by: Chao Yu
Link: https://lore.kernel.org/r/20200618234349.22553-1-hsiang...@aol.com
Signed-off-by: Gao Xiang
---
The same as 5.4.y.
fs/erofs/zdata.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/erofs/zdata.h b/fs/erofs/zdata.h
index 7824f5563a55..9b66c28b3ae9 100644
--- a/fs/erofs/zdata.h
+++ b/fs/erofs/zdata.h
@@ -144,22 +144,22 @@ static inline void z_erofs_onlinepage_init(struct page
*page)
static inline void z_erofs_onlinepage_fixup(struct page *page,
uintptr_t index, bool down)
{
- unsigned long *p, o, v, id;
-repeat:
- p = _private(page);
- o = READ_ONCE(*p);
+ union z_erofs_onlinepage_converter u = { .v = _private(page) };
+ int orig, orig_index, val;
- id = o >> Z_EROFS_ONLINEPAGE_INDEX_SHIFT;
- if (id) {
+repeat:
+ orig = atomic_read(u.o);
+ orig_index = orig >> Z_EROFS_ONLINEPAGE_INDEX_SHIFT;
+ if (orig_index) {
if (!index)
return;
- DBG_BUGON(id != index);
+ DBG_BUGON(orig_index != index);
}
- v = (index << Z_EROFS_ONLINEPAGE_INDEX_SHIFT) |
- ((o & Z_EROFS_ONLINEPAGE_COUNT_MASK) + (unsigned int)down);
- if (cmpxchg(p, o, v) != o)
+ val = (index << Z_EROFS_ONLINEPAGE_INDEX_SHIFT) |
+ ((orig & Z_EROFS_ONLINEPAGE_COUNT_MASK) + (unsigned int)down);
+ if (atomic_cmpxchg(u.o, orig, val) != orig)
goto repeat;
}
--
2.24.0
Re: [PATCH v4 4/7] ACPI: button: Use input_device_enabled() helper
On Mon, Jun 08, 2020 at 01:22:08PM +0200, Andrzej Pietrasiewicz wrote:
> A new helper is available, so use it.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/acpi/button.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index ff7ab291f678..4deb2b48d03c 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -411,7 +411,7 @@ static void acpi_button_notify(struct acpi_device
> *device, u32 event)
> input = button->input;
> if (button->type == ACPI_BUTTON_TYPE_LID) {
> mutex_lock(>input->mutex);
> - users = button->input->users;
> + users = input_device_enabled(button->input);
> mutex_unlock(>input->mutex);
> if (users)
This chunk (pre-patch) is really wrong. 'users' value is obsolete and
can not be trusted the moment we unlocked the mutex. "if" needs to be
inside critical section.
> acpi_lid_update_state(device, true);
> @@ -460,7 +460,7 @@ static int acpi_button_resume(struct device *dev)
>
> button->suspended = false;
> mutex_lock(>mutex);
> - if (button->type == ACPI_BUTTON_TYPE_LID && input->users) {
> + if (button->type == ACPI_BUTTON_TYPE_LID &&
> input_device_enabled(input)) {
> button->last_state = !!acpi_lid_evaluate_state(device);
> button->last_time = ktime_get();
> acpi_lid_initialize_state(device);
> --
> 2.17.1
>
Thanks.
--
Dmitry
Re: [Nouveau] [RESEND PATCH 1/3] nouveau: fix migrate page regression
On Thu, 25 Jun 2020 at 15:23, Ben Skeggs wrote:
>
> On Tue, 23 Jun 2020 at 10:51, John Hubbard wrote:
> >
> > On 2020-06-22 16:38, Ralph Campbell wrote:
> > > The patch to add zero page migration to GPU memory inadvertantly included
> >
> > inadvertently
> >
> > > part of a future change which broke normal page migration to GPU memory
> > > by copying too much data and corrupting GPU memory.
> > > Fix this by only copying one page instead of a byte count.
> > >
> > > Fixes: 9d4296a7d4b3 ("drm/nouveau/nouveau/hmm: fix migrate zero page to
> > > GPU")
> > > Signed-off-by: Ralph Campbell
> > > ---
> > > drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > > b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > > index e5c230d9ae24..cc9993837508 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > > @@ -550,7 +550,7 @@ static unsigned long
> > > nouveau_dmem_migrate_copy_one(struct nouveau_drm *drm,
> > >DMA_BIDIRECTIONAL);
> > > if (dma_mapping_error(dev, *dma_addr))
> > > goto out_free_page;
> > > - if (drm->dmem->migrate.copy_func(drm, page_size(spage),
> > > + if (drm->dmem->migrate.copy_func(drm, 1,
> > > NOUVEAU_APER_VRAM, paddr, NOUVEAU_APER_HOST,
> > > *dma_addr))
> > > goto out_dma_unmap;
> > > } else {
> > >
> >
> >
> > I Am Not A Nouveau Expert, nor is it really clear to me how
> > page_size(spage) came to contain something other than a page's worth of
> > byte count, but this fix looks accurate to me. It's better for
> > maintenance, too, because the function never intends to migrate "some
> > number of bytes". It intends to migrate exactly one page.
> >
> > Hope I'm not missing something fundamental, but:
> I'm actually a bit confused here too. Because, it *looks* like the
> function takes a byte count, not a page count, and unless I'm missing
> something too, it's setup the copy class for a byte count also.
No, nevermind.. I was looking at nvc0b5_migrate_clear() :)
>
> >
> > Reviewed-by: John Hubbard >
> >
> > thanks,
> > --
> > John Hubbard
> > NVIDIA
> > ___
> > Nouveau mailing list
> > nouv...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
stable-rc/linux-5.6.y bisection: baseline.dmesg.crit on bcm2837-rpi-3-b
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* *
* If you do send a fix, please include this trailer:*
* Reported-by: "kernelci.org bot" *
* *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
stable-rc/linux-5.6.y bisection: baseline.dmesg.crit on bcm2837-rpi-3-b
Summary:
Start: 61aba373f570 Linux 5.6.19
Plain log:
https://storage.kernelci.org/stable-rc/linux-5.6.y/v5.6.19/arm64/defconfig/gcc-8/lab-baylibre/baseline-bcm2837-rpi-3-b.txt
HTML log:
https://storage.kernelci.org/stable-rc/linux-5.6.y/v5.6.19/arm64/defconfig/gcc-8/lab-baylibre/baseline-bcm2837-rpi-3-b.html
Result: 9cf5d5444c78 Revert "cgroup: Add memory barriers to plug
cgroup_rstat_updated() race window"
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: stable-rc
URL:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.6.y
Target: bcm2837-rpi-3-b
CPU arch: arm64
Lab:lab-baylibre
Compiler: gcc-8
Config: defconfig
Test case: baseline.dmesg.crit
Breaking commit found:
---
commit 9cf5d5444c78c14bb9f90dd21cef361ee14ba64b
Author: Tejun Heo
Date: Thu Apr 9 14:55:35 2020 -0400
Revert "cgroup: Add memory barriers to plug cgroup_rstat_updated() race
window"
[ Upstream commit d8ef4b38cb69d907f9b0e889c44d05fc0f890977 ]
This reverts commit 9a9e97b2f1f2 ("cgroup: Add memory barriers to plug
cgroup_rstat_updated() race window").
The commit was added in anticipation of memcg rstat conversion which needed
synchronous accounting for the event counters (e.g. oom kill count).
However,
the conversion didn't get merged due to percpu memory overhead concern which
couldn't be addressed at the time.
Unfortunately, the patch's addition of smp_mb() to cgroup_rstat_updated()
meant that every scheduling event now had to go through an additional full
barrier and Mel Gorman noticed it as 1% regression in netperf UDP_STREAM
test.
There's no need to have this barrier in tree now and even if we need
synchronous accounting in the future, the right thing to do is separating
that
out to a separate function so that hot paths which don't care about
synchronous behavior don't have to pay the overhead of the full barrier.
Let's
revert.
Signed-off-by: Tejun Heo
Reported-by: Mel Gorman
Link: http://lkml.kernel.org/r/20200409154413.gk3...@techsingularity.net
Cc: v4.18+
Signed-off-by: Sasha Levin
diff --git a/kernel/cgroup/rstat.c b/kernel/cgroup/rstat.c
index 6f87352f8219..41ca996568df 100644
--- a/kernel/cgroup/rstat.c
+++ b/kernel/cgroup/rstat.c
@@ -33,12 +33,9 @@ void cgroup_rstat_updated(struct cgroup *cgrp, int cpu)
return;
/*
-* Paired with the one in cgroup_rstat_cpu_pop_updated(). Either we
-* see NULL updated_next or they see our updated stat.
-*/
- smp_mb();
-
- /*
+* Speculative already-on-list test. This may race leading to
+* temporary inaccuracies, which is fine.
+*
* Because @parent's updated_children is terminated with @parent
* instead of NULL, we can tell whether @cgrp is on the list by
* testing the next pointer for NULL.
@@ -134,13 +131,6 @@ static struct cgroup *cgroup_rstat_cpu_pop_updated(struct
cgroup *pos,
*nextp = rstatc->updated_next;
rstatc->updated_next = NULL;
- /*
-* Paired with the one in cgroup_rstat_cpu_updated().
-* Either they see NULL updated_next or we see their
-* updated stat.
-*/
- smp_mb();
-
return pos;
}
---
Git bisection log:
---
git bisect start
# good: [7111951b8d4973bda27ff663f2cf18b663d15b48] Linux 5.6
git bisect good 7111951b8d4973bda27ff663f2cf18b663d15b48
# bad: [61aba373f5708f2aebc3f72078e51949a068aa6f] Linux 5.6.19
git bisect bad 61aba373f5708f2aebc3f72078e51949a068aa6f
# good: [0bc4d081e87ef8fd43baeed7141267e558896f86] RDMA/cm: Fix an error check
in cm_alloc_id_priv()
git bisect good 0bc4d081e87ef8fd43baeed7141267e558896f86
# good: [0deceb85de592b89f6476e2bfcb5321a95d23126]
Re: [Nouveau] [RESEND PATCH 1/3] nouveau: fix migrate page regression
On Tue, 23 Jun 2020 at 10:51, John Hubbard wrote:
>
> On 2020-06-22 16:38, Ralph Campbell wrote:
> > The patch to add zero page migration to GPU memory inadvertantly included
>
> inadvertently
>
> > part of a future change which broke normal page migration to GPU memory
> > by copying too much data and corrupting GPU memory.
> > Fix this by only copying one page instead of a byte count.
> >
> > Fixes: 9d4296a7d4b3 ("drm/nouveau/nouveau/hmm: fix migrate zero page to
> > GPU")
> > Signed-off-by: Ralph Campbell
> > ---
> > drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > index e5c230d9ae24..cc9993837508 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> > @@ -550,7 +550,7 @@ static unsigned long
> > nouveau_dmem_migrate_copy_one(struct nouveau_drm *drm,
> >DMA_BIDIRECTIONAL);
> > if (dma_mapping_error(dev, *dma_addr))
> > goto out_free_page;
> > - if (drm->dmem->migrate.copy_func(drm, page_size(spage),
> > + if (drm->dmem->migrate.copy_func(drm, 1,
> > NOUVEAU_APER_VRAM, paddr, NOUVEAU_APER_HOST,
> > *dma_addr))
> > goto out_dma_unmap;
> > } else {
> >
>
>
> I Am Not A Nouveau Expert, nor is it really clear to me how
> page_size(spage) came to contain something other than a page's worth of
> byte count, but this fix looks accurate to me. It's better for
> maintenance, too, because the function never intends to migrate "some
> number of bytes". It intends to migrate exactly one page.
>
> Hope I'm not missing something fundamental, but:
I'm actually a bit confused here too. Because, it *looks* like the
function takes a byte count, not a page count, and unless I'm missing
something too, it's setup the copy class for a byte count also.
>
> Reviewed-by: John Hubbard
>
> thanks,
> --
> John Hubbard
> NVIDIA
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [PATCH v4 3/7] ACPI: button: Access input device's users under appropriate mutex
On Wed, Jun 24, 2020 at 05:00:09PM +0200, Rafael J. Wysocki wrote:
> On Mon, Jun 8, 2020 at 1:22 PM Andrzej Pietrasiewicz
> wrote:
> >
> > Inspecting input device's 'users' member should be done under device's
> > mutex, so add appropriate invocations.
> >
> > Signed-off-by: Andrzej Pietrasiewicz
>
> This looks like a fix that might be applied independently of the other
> patches in the series.
>
> Do you want me to pick it up?
If you pick it we'll have to have a dance with this series. Can I apply
instead?
I do not think this change has any practical effect as nobody
attaches/detached input handlers or opening/closing input devices when
system goes through device resume phase.
>
> > ---
> > drivers/acpi/button.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index 78cfc70cb320..ff7ab291f678 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -456,13 +456,16 @@ static int acpi_button_resume(struct device *dev)
> > {
> > struct acpi_device *device = to_acpi_device(dev);
> > struct acpi_button *button = acpi_driver_data(device);
> > + struct input_dev *input = button->input;
> >
> > button->suspended = false;
> > - if (button->type == ACPI_BUTTON_TYPE_LID && button->input->users) {
> > + mutex_lock(>mutex);
> > + if (button->type == ACPI_BUTTON_TYPE_LID && input->users) {
> > button->last_state = !!acpi_lid_evaluate_state(device);
> > button->last_time = ktime_get();
> > acpi_lid_initialize_state(device);
> > }
> > + mutex_unlock(>mutex);
> > return 0;
> > }
> > #endif
> > --
> > 2.17.1
> >
Thanks.
--
Dmitry
[PATCH 5.4.y] erofs: fix partially uninitialized misuse in z_erofs_onlinepage_fixup
From: Gao Xiang
commit 3c597282887fd55181578996dca52ce697d985a5 upstream.
Hongyu reported "id != index" in z_erofs_onlinepage_fixup() with
specific aarch64 environment easily, which wasn't shown before.
After digging into that, I found that high 32 bits of page->private
was set to 0x rather than 0 (due to z_erofs_onlinepage_init
behavior with specific compiler options). Actually we only use low
32 bits to keep the page information since page->private is only 4
bytes on most 32-bit platforms. However z_erofs_onlinepage_fixup()
uses the upper 32 bits by mistake.
Let's fix it now.
Reported-and-tested-by: Hongyu Jin
Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc: # 4.19+
Reviewed-by: Chao Yu
Link: https://lore.kernel.org/r/20200618234349.22553-1-hsiang...@aol.com
Signed-off-by: Gao Xiang
---
This fix has been merged into Linus's tree just now.
The 5.4 backport can be trivially applied, though I sent out
together with 4.19...
fs/erofs/zdata.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/erofs/zdata.h b/fs/erofs/zdata.h
index faf950189bd7..568d5a493876 100644
--- a/fs/erofs/zdata.h
+++ b/fs/erofs/zdata.h
@@ -148,22 +148,22 @@ static inline void z_erofs_onlinepage_init(struct page
*page)
static inline void z_erofs_onlinepage_fixup(struct page *page,
uintptr_t index, bool down)
{
- unsigned long *p, o, v, id;
-repeat:
- p = _private(page);
- o = READ_ONCE(*p);
+ union z_erofs_onlinepage_converter u = { .v = _private(page) };
+ int orig, orig_index, val;
- id = o >> Z_EROFS_ONLINEPAGE_INDEX_SHIFT;
- if (id) {
+repeat:
+ orig = atomic_read(u.o);
+ orig_index = orig >> Z_EROFS_ONLINEPAGE_INDEX_SHIFT;
+ if (orig_index) {
if (!index)
return;
- DBG_BUGON(id != index);
+ DBG_BUGON(orig_index != index);
}
- v = (index << Z_EROFS_ONLINEPAGE_INDEX_SHIFT) |
- ((o & Z_EROFS_ONLINEPAGE_COUNT_MASK) + (unsigned int)down);
- if (cmpxchg(p, o, v) != o)
+ val = (index << Z_EROFS_ONLINEPAGE_INDEX_SHIFT) |
+ ((orig & Z_EROFS_ONLINEPAGE_COUNT_MASK) + (unsigned int)down);
+ if (atomic_cmpxchg(u.o, orig, val) != orig)
goto repeat;
}
--
2.24.0
[PATCH 4.19.y] erofs: fix partially uninitialized misuse in z_erofs_onlinepage_fixup
From: Gao Xiang
commit 3c597282887fd55181578996dca52ce697d985a5 upstream.
Hongyu reported "id != index" in z_erofs_onlinepage_fixup() with
specific aarch64 environment easily, which wasn't shown before.
After digging into that, I found that high 32 bits of page->private
was set to 0x rather than 0 (due to z_erofs_onlinepage_init
behavior with specific compiler options). Actually we only use low
32 bits to keep the page information since page->private is only 4
bytes on most 32-bit platforms. However z_erofs_onlinepage_fixup()
uses the upper 32 bits by mistake.
Let's fix it now.
Reported-and-tested-by: Hongyu Jin
Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc: # 4.19+
Reviewed-by: Chao Yu
Link: https://lore.kernel.org/r/20200618234349.22553-1-hsiang...@aol.com
Signed-off-by: Gao Xiang
---
This fix has been merged into Linus's tree just now (today).
Since the patch could not directly be applied to 4.19, manually handle this.
drivers/staging/erofs/unzip_vle.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/erofs/unzip_vle.h
b/drivers/staging/erofs/unzip_vle.h
index 684ff06fc7bf..630fd1f4f123 100644
--- a/drivers/staging/erofs/unzip_vle.h
+++ b/drivers/staging/erofs/unzip_vle.h
@@ -169,22 +169,22 @@ static inline void z_erofs_onlinepage_init(struct page
*page)
static inline void z_erofs_onlinepage_fixup(struct page *page,
uintptr_t index, bool down)
{
- unsigned long *p, o, v, id;
-repeat:
- p = _private(page);
- o = READ_ONCE(*p);
+ union z_erofs_onlinepage_converter u = { .v = _private(page) };
+ int orig, orig_index, val;
- id = o >> Z_EROFS_ONLINEPAGE_INDEX_SHIFT;
- if (id) {
+repeat:
+ orig = atomic_read(u.o);
+ orig_index = orig >> Z_EROFS_ONLINEPAGE_INDEX_SHIFT;
+ if (orig_index) {
if (!index)
return;
- BUG_ON(id != index);
+ DBG_BUGON(orig_index != index);
}
- v = (index << Z_EROFS_ONLINEPAGE_INDEX_SHIFT) |
- ((o & Z_EROFS_ONLINEPAGE_COUNT_MASK) + (unsigned)down);
- if (cmpxchg(p, o, v) != o)
+ val = (index << Z_EROFS_ONLINEPAGE_INDEX_SHIFT) |
+ ((orig & Z_EROFS_ONLINEPAGE_COUNT_MASK) + (unsigned int)down);
+ if (atomic_cmpxchg(u.o, orig, val) != orig)
goto repeat;
}
--
2.24.0
Re: [PATCH 2/2][v3] PM / s2idle: Code cleanup to make s2idle consistent with normal idle path
Hi Rafael,
On Tue, Jun 23, 2020 at 07:57:59PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
> Subject: [PATCH] cpuidle: Rearrange s2idle-specific idle state entry code
>
> Implement call_cpuidle_s2idle() in analogy with call_cpuidle()
> for the s2idle-specific idle state entry and invoke it from
> cpuidle_idle_call() to make the s2idle-specific idle entry code
> path look more similar to the "regular" idle entry one.
>
> No intentional functional impact.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpuidle/cpuidle.c |6 +++---
> kernel/sched/idle.c | 15 +++
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> Index: linux-pm/kernel/sched/idle.c
> ===
> --- linux-pm.orig/kernel/sched/idle.c
> +++ linux-pm/kernel/sched/idle.c
> @@ -96,6 +96,15 @@ void __cpuidle default_idle_call(void)
> }
> }
>
> +static int call_cpuidle_s2idle(struct cpuidle_driver *drv,
> +struct cpuidle_device *dev)
> +{
> + if (current_clr_polling_and_test())
> + return -EBUSY;
> +
> + return cpuidle_enter_s2idle(drv, dev);
> +}
> +
> static int call_cpuidle(struct cpuidle_driver *drv, struct cpuidle_device
> *dev,
> int next_state)
> {
> @@ -171,11 +180,9 @@ static void cpuidle_idle_call(void)
> if (idle_should_enter_s2idle()) {
> rcu_idle_enter();
>
> - entered_state = cpuidle_enter_s2idle(drv, dev);
> - if (entered_state > 0) {
> - local_irq_enable();
> + entered_state = call_cpuidle_s2idle(drv, dev);
I guess this changes the context a little bit that(comparing to [1/2 patch],
after this modification, when we found that TIF_NEED_RESCHED is set we can have
a second chance in the following call_cpuidle to do a second s2idle try. However
in [1/2 patch], it might exit the s2idle phase directly once when we see
TIF_NEED_RESCHED is set(because entered_state is postive we treat it as a
successful
s2idle). In summary I think the change (patch [2/2]) is more robust.
Acked-by: Chen Yu
Thanks,
Chenyu
Re: [PATCH v6 1/6] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
On Mon 15 Jun 05:02 PDT 2020, Rajendra Nayak wrote:
> geni serial needs to express a perforamnce state requirement on CX
> powerdomain depending on the frequency of the clock rates.
> Use OPP table from DT to register with OPP framework and use
> dev_pm_opp_set_rate() to set the clk/perf state.
>
> Signed-off-by: Rajendra Nayak
> Reviewed-by: Matthias Kaehlcke
> Cc: Greg Kroah-Hartman
> Cc: Akash Asthana
> Cc: linux-ser...@vger.kernel.org
Picked up patch 1 and 2 through the qcom tree.
As Mark requested, please don't lump together patches that doesn't
actually depend on each other in the same series - it's quite confusing
to know what to pick and not.
Regards,
Bjorn
> ---
> This patch needs to land via the msm tree. Greg had this already pulled in,
> but later dropped it on my request.
> No change in v6, just resposting it here so Bjorn/Andy can pull it in.
>
> drivers/tty/serial/qcom_geni_serial.c | 34 +-
> include/linux/qcom-geni-se.h | 4
> 2 files changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/serial/qcom_geni_serial.c
> b/drivers/tty/serial/qcom_geni_serial.c
> index 457c0bf..a90f8ec 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -962,7 +963,7 @@ static void qcom_geni_serial_set_termios(struct uart_port
> *uport,
> goto out_restart_rx;
>
> uport->uartclk = clk_rate;
> - clk_set_rate(port->se.clk, clk_rate);
> + dev_pm_opp_set_rate(uport->dev, clk_rate);
> ser_clk_cfg = SER_CLK_EN;
> ser_clk_cfg |= clk_div << CLK_DIV_SHFT;
>
> @@ -1231,8 +1232,11 @@ static void qcom_geni_serial_pm(struct uart_port
> *uport,
> if (new_state == UART_PM_STATE_ON && old_state == UART_PM_STATE_OFF)
> geni_se_resources_on(>se);
> else if (new_state == UART_PM_STATE_OFF &&
> - old_state == UART_PM_STATE_ON)
> + old_state == UART_PM_STATE_ON) {
> + /* Drop the performance state vote */
> + dev_pm_opp_set_rate(uport->dev, 0);
> geni_se_resources_off(>se);
> + }
> }
>
> static const struct uart_ops qcom_geni_console_pops = {
> @@ -1351,13 +1355,25 @@ static int qcom_geni_serial_probe(struct
> platform_device *pdev)
> if (of_property_read_bool(pdev->dev.of_node, "cts-rts-swap"))
> port->cts_rts_swap = true;
>
> + port->se.opp_table = dev_pm_opp_set_clkname(>dev, "se");
> + if (IS_ERR(port->se.opp_table))
> + return PTR_ERR(port->se.opp_table);
> + /* OPP table is optional */
> + ret = dev_pm_opp_of_add_table(>dev);
> + if (!ret) {
> + port->se.has_opp_table = true;
> + } else if (ret != -ENODEV) {
> + dev_err(>dev, "invalid OPP table in device tree\n");
> + return ret;
> + }
> +
> uport->private_data = drv;
> platform_set_drvdata(pdev, port);
> port->handle_rx = console ? handle_rx_console : handle_rx_uart;
>
> ret = uart_add_one_port(drv, uport);
> if (ret)
> - return ret;
> + goto err;
>
> irq_set_status_flags(uport->irq, IRQ_NOAUTOEN);
> ret = devm_request_irq(uport->dev, uport->irq, qcom_geni_serial_isr,
> @@ -1365,7 +1381,7 @@ static int qcom_geni_serial_probe(struct
> platform_device *pdev)
> if (ret) {
> dev_err(uport->dev, "Failed to get IRQ ret %d\n", ret);
> uart_remove_one_port(drv, uport);
> - return ret;
> + goto err;
> }
>
> /*
> @@ -1382,11 +1398,16 @@ static int qcom_geni_serial_probe(struct
> platform_device *pdev)
> if (ret) {
> device_init_wakeup(>dev, false);
> uart_remove_one_port(drv, uport);
> - return ret;
> + goto err;
> }
> }
>
> return 0;
> +err:
> + if (port->se.has_opp_table)
> + dev_pm_opp_of_remove_table(>dev);
> + dev_pm_opp_put_clkname(port->se.opp_table);
> + return ret;
> }
>
> static int qcom_geni_serial_remove(struct platform_device *pdev)
> @@ -1394,6 +1415,9 @@ static int qcom_geni_serial_remove(struct
> platform_device *pdev)
> struct qcom_geni_serial_port *port = platform_get_drvdata(pdev);
> struct uart_driver *drv = port->uport.private_data;
>
> + if (port->se.has_opp_table)
> + dev_pm_opp_of_remove_table(>dev);
> + dev_pm_opp_put_clkname(port->se.opp_table);
> dev_pm_clear_wake_irq(>dev);
> device_init_wakeup(>dev, false);
> uart_remove_one_port(drv, >uport);
> diff --git a/include/linux/qcom-geni-se.h b/include/linux/qcom-geni-se.h
> index dd46494..6b78094 100644
> --- a/include/linux/qcom-geni-se.h
> +++ b/include/linux/qcom-geni-se.h
> @@
Re: [PATCH v3 08/15] arm64: kvm: Split hyp/switch.c to VHE/nVHE
Hi David, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.8-rc2 next-20200624] [cannot apply to kvmarm/next arm64/for-next/core arm-perf/for-next/perf] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/David-Brazdil/Split-off-nVHE-hyp-code/20200618-203230 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 1b5044021070efa3259f3e9548dc35d1eb6aa844 config: arm64-randconfig-r021-20200624 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 8911a35180c6777188fefe0954a2451a2b91deaf) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> arch/arm64/kvm/hyp/nvhe/switch.c:244:28: warning: no previous prototype for >> function 'hyp_panic' [-Wmissing-prototypes] void __hyp_text __noreturn hyp_panic(struct kvm_cpu_context *host_ctxt) ^ arch/arm64/kvm/hyp/nvhe/switch.c:244:1: note: declare 'static' if the function is not intended to be used outside of this translation unit void __hyp_text __noreturn hyp_panic(struct kvm_cpu_context *host_ctxt) ^ static 1 warning generated. vim +/hyp_panic +244 arch/arm64/kvm/hyp/nvhe/switch.c 243 > 244 void __hyp_text __noreturn hyp_panic(struct kvm_cpu_context *host_ctxt) --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [v2,net-next 2/4] net: enetc: add support max frame size for tc flower offload
From: Po Liu Date: Wed, 24 Jun 2020 17:36:29 +0800 > From: Po Liu > > Base on the tc flower offload police action add max frame size by the > parameter 'mtu'. Tc flower device driver working by the IEEE 802.1Qci > stream filter can implement the max frame size filtering. Add it to the > current hardware tc flower stearm filter driver. > > Signed-off-by: Po Liu Applied.
Re: [v2,net-next 1/4] net: qos: add tc police offloading action with max frame size limit
From: Po Liu Date: Wed, 24 Jun 2020 17:36:28 +0800 > From: Po Liu > > Current police offloading support the 'burst'' and 'rate_bytes_ps'. Some > hardware own the capability to limit the frame size. If the frame size > larger than the setting, the frame would be dropped. For the police > action itself already accept the 'mtu' parameter in tc command. But not > extend to tc flower offloading. So extend 'mtu' to tc flower offloading. > > Signed-off-by: Po Liu Applied.
Re: [v2,net-next 4/4] net: enetc add tc flower offload flow metering policing action
From: Po Liu Date: Wed, 24 Jun 2020 17:36:31 +0800 > From: Po Liu > > Flow metering entries in IEEE 802.1Qci is an optional function for a > flow filtering module. Flow metering is two rates two buckets and three > color marker to policing the frames. This patch only enable one rate one > bucket and in color blind mode. Flow metering instance are as > specified in the algorithm in MEF 10.3 and in Bandwidth Profile > Parameters. They are: > > a) Flow meter instance identifier. An integer value identifying the flow > meter instance. The patch use the police 'index' as thin value. > b) Committed Information Rate (CIR), in bits per second. This patch use > the 'rate_bytes_ps' represent this value. > c) Committed Burst Size (CBS), in octets. This patch use the 'burst' > represent this value. > d) Excess Information Rate (EIR), in bits per second. > e) Excess Burst Size per Bandwidth Profile Flow (EBS), in octets. > And plus some other parameters. This patch set EIR/EBS default disable > and color blind mode. > > v1->v2 changes: > - Use div_u64() as division replace the '/' report: > > Reported-by: kernel test robot > All errors (new ones prefixed by >>): > >ld: drivers/net/ethernet/freescale/enetc/enetc_qos.o: in function > `enetc_flowmeter_hw_set': >>> enetc_qos.c:(.text+0x66): undefined reference to `__udivdi3' > > > Signed-off-by: Po Liu Applied.
Re: [v2,net-next 3/4] net: qos: police action add index for tc flower offloading
From: Po Liu Date: Wed, 24 Jun 2020 17:36:30 +0800 > From: Po Liu > > Hardware device may include more than one police entry. Specifying the > action's index make it possible for several tc filters to share the same > police action when installing the filters. > > Propagate this index to device drivers through the flow offload > intermediate representation, so that drivers could share a single > hardware policer between multiple filters. > > v1->v2 changes: > - Update the commit message suggest by Ido Schimmel > > Signed-off-by: Po Liu Applied.
Re: [PATCH V8 0/8] Add interconnect support to QSPI and QUP drivers
On Tue 23 Jun 03:38 PDT 2020, Akash Asthana wrote: > This patch series is based on tag "next-20200622" of linux-next tree. > Series applied to the qcom tree, thank you and thanks for the Acks. Regards, Bjorn > High level design: > - QUP wrapper/common driver. >Vote for QUP core on behalf of earlycon from probe. >Remove BW vote during earlycon exit call > > - SERIAL driver. >Vote only for CPU/CORE path because driver is in FIFO mode only >Vote/unvote from qcom_geni_serial_pm func. >Bump up the CPU vote from set_termios call based on real time need > > - I2C driver. >Vote for CORE/CPU/DDR path >Vote/unvote from runtime resume/suspend callback >As bus speed for I2C is fixed from probe itself no need for bump up. > > - SPI QUP driver. >Vote only for CPU/CORE path because driver is in FIFO mode only >Vote/unvote from runtime resume/suspend callback >Bump up CPU vote based on real time need per transfer. > > - QSPI driver. >Vote only for CPU path >Vote/unvote from runtime resume/suspend callback >Bump up CPU vote based on real time need per transfer. > > Changes in V2: > - Add devm_of_icc_get() API interconnect core. > - Add ICC support to common driver to fix earlyconsole crash. > > Changes in V3: > - Define common ICC APIs in geni-se driver and use it across geni based >I2C,SPI and UART driver. > > Changes in V4: > - Add a patch to ICC core to scale peak requirement >as twice of average if it is not mentioned explicilty. > > Changes in V5: > - As per Georgi's suggestion removed patch from ICC core for assuming >peak_bw as twice of average when it's not mentioned, instead assume it >equall to avg_bw and keep this assumption in ICC client itself. > - As per Matthias suggestion use enum for GENI QUP ICC paths. > > Changes in V6: > - No Major change > > Changes in V7: > - As per Matthias's comment removed usage of peak_bw variable because we > don't >have explicit peak requirement, we were voting peak = avg and this can be >tracked using single variable for avg bw. > - As per Matthias's comment improved print log. > > Changes in V8: > - Add [PATCH V8 5/8] to factor out common code for clock setting. > - Combine ICC voting and clock setting to single API. [PATCH V8 6/8] > - Add ICC voting per transfer because in case of multi message, >transfer frequency can vary for each message/transfer.[PATCH V8 6/8] > > Akash Asthana (7): > soc: qcom: geni: Support for ICC voting > soc: qcom-geni-se: Add interconnect support to fix earlycon crash > i2c: i2c-qcom-geni: Add interconnect support > tty: serial: qcom_geni_serial: Add interconnect support > spi: spi-geni-qcom: Add interconnect support > spi: spi-qcom-qspi: Add interconnect support > arm64: dts: sc7180: Add interconnect for QUP and QSPI > > Douglas Anderson (1): > spi: spi-geni-qcom: Combine the clock setting code > > arch/arm64/boot/dts/qcom/sc7180.dtsi | 127 > drivers/i2c/busses/i2c-qcom-geni.c| 26 +- > drivers/soc/qcom/qcom-geni-se.c | 150 > ++ > drivers/spi/spi-geni-qcom.c | 100 +++ > drivers/spi/spi-qcom-qspi.c | 56 - > drivers/tty/serial/qcom_geni_serial.c | 38 - > include/linux/qcom-geni-se.h | 40 + > 7 files changed, 496 insertions(+), 41 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na > Linux Foundation Collaborative Project >
ath9k broken [was: Linux 5.7.3]
On 25. 06. 20, 0:05, Gabriel C wrote: > Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman > : >> >> I'm announcing the release of the 5.7.3 kernel. >> > > Hello Greg, > >> Qiujun Huang (5): >> ath9k: Fix use-after-free Read in htc_connect_service >> ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx >> ath9k: Fix use-after-free Write in ath9k_htc_rx_msg >> ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb >> ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb >> > > We got a report on IRC about 5.7.3+ breaking a USB ath9k Wifi Dongle, > while working fine on <5.7.3. > > I don't have myself such HW, and the reported doesn't have any experience > in bisecting the kernel, so we build kernels, each with one of the > above commits reverted, > to find the bad commit. > > The winner is: > > commit 6602f080cb28745259e2fab1a4cf55eeb5894f93 > Author: Qiujun Huang > Date: Sat Apr 4 12:18:38 2020 +0800 > > ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb > > commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream. > ... > > Reverting this one fixed his problem. Obvious question: is 5.8-rc1 (containing the commit) broken too? I fail to see how the commit could cause an issue like this. Is this really reproducibly broken with the commit and irreproducible without it? As it looks like a USB/wiring problem: usb 1-2: USB disconnect, device number 2 ath: phy0: Reading Magic # failed ath: phy0: Unable to initialize hardware; initialization status: -5 ... usb 1-2: device descriptor read/64, error -110 usb 1-2: device descriptor read/64, error -71 Ccing ath9k maintainers too. > I don't have so much info about the HW, besides a dmesg showing the > phy breaking. > I also added the reporter to CC too. > > https://gist.github.com/AngryPenguinPL/1e545f0da3c2339e443b9e5044fcccea > > If you need more info, please let me know and I'll try my best to get > it as fast as possible for you. thanks, -- js
[Question]many kernel error "neighbour: ndisc_cache: neighbor table overflow!"
Hi Folks, In one of our big cluster, due to capacity increase, more servers are added to the cluster, and we saw from many pserver reporting error message below: "neighbour: ndisc_cache: neighbor table overflow!" We've tested increasing the gc_thresh values in sysctl.conf, after reboot, the errors are gone +# Threshold when garbage collector becomes more aggressive about +# purging entries. Entries older than 5 seconds will be cleared +# when over this number. Default: 512 +net.ipv4.neigh.default.gc_thresh2 = 4096 +net.ipv6.neigh.default.gc_thresh2 = 4096 + +# Maximum number of non-PERMANENT neighbor entries allowed. Increase +# this when using large numbers of interfaces and when communicating +# with large numbers of directly-connected peers. Default: 1024 +net.ipv4.neigh.default.gc_thresh3 = 8192 +net.ipv6.neigh.default.gc_thresh3 = 8192 But we still have many systems running in production, so my question is: is it safe to apply the setting on the fly when servers are running with busy traffic? or we have to apply the setting only through sysctl during boot? Most of our servers with default settings are running kernel 4.14.137~4.14.154 Thanks in advance! Best regards! Jack Wang
Re: [PATCH net 0/3] net: bcmgenet: use hardware padding of runt frames
From: Doug Berger Date: Wed, 24 Jun 2020 18:14:52 -0700 > Now that scatter-gather and tx-checksumming are enabled by default > it revealed a packet corruption issue that can occur for very short > fragmented packets. > > When padding these frames to the minimum length it is possible for > the non-linear (fragment) data to be added to the end of the linear > header in an SKB. Since the number of fragments is read before the > padding and used afterward without reloading, the fragment that > should have been consumed can be tacked on in place of part of the > padding. > > The third commit in this set corrects this by removing the software > padding and allowing the hardware to add the pad bytes if necessary. > > The first two commits resolve warnings observed by the kbuild test > robot and are included here for simplicity of application. Series applied, thank you.
Re: [PATCH] venus: move buffer calculation to driver
Hi Stanimir, A gentle reminder for the review. Thanks, Dikshita On 2020-06-09 17:24, Dikshita Agarwal wrote: Right now we get buffer requirements from fw. The call to get these requirements is a blocking call and takes a lot of time. This change calculates all the buffer requirement within driver and this removes the necessity for get buffer requirements call. Signed-off-by: Dikshita Agarwal --- drivers/media/platform/qcom/venus/Makefile |2 +- drivers/media/platform/qcom/venus/buffers.c| 1312 drivers/media/platform/qcom/venus/buffers.h| 44 + drivers/media/platform/qcom/venus/core.h |1 + drivers/media/platform/qcom/venus/helpers.c|3 + .../media/platform/qcom/venus/hfi_platform_data.h |3 + drivers/media/platform/qcom/venus/vdec.c |3 + 7 files changed, 1367 insertions(+), 1 deletion(-) create mode 100644 drivers/media/platform/qcom/venus/buffers.c create mode 100644 drivers/media/platform/qcom/venus/buffers.h diff --git a/drivers/media/platform/qcom/venus/Makefile b/drivers/media/platform/qcom/venus/Makefile index 3878bc9..bb6a378 100644 --- a/drivers/media/platform/qcom/venus/Makefile +++ b/drivers/media/platform/qcom/venus/Makefile @@ -4,7 +4,7 @@ venus-core-objs += core.o helpers.o firmware.o \ hfi_venus.o hfi_msgs.o hfi_cmds.o hfi.o \ hfi_parser.o pm_helpers.o dbgfs.o \ - hfi_platform_data.o + hfi_platform_data.o buffers.o venus-dec-objs += vdec.o vdec_ctrls.o venus-enc-objs += venc.o venc_ctrls.o diff --git a/drivers/media/platform/qcom/venus/buffers.c b/drivers/media/platform/qcom/venus/buffers.c new file mode 100644 index 000..bd5071b --- /dev/null +++ b/drivers/media/platform/qcom/venus/buffers.c @@ -0,0 +1,1312 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ + +#include "buffers.h" +#include "hfi_platform_data.h" + +/* minimum number of input buffers */ +#define MIN_INPUT_BUFFERS 4 + +/* minimum number of output buffers */ +#define MIN_ENC_OUTPUT_BUFFERS 4 + +#define HFI_COLOR_FORMAT_YUV420_NV12_UBWC_Y_TILE_WIDTH 32 +#define HFI_COLOR_FORMAT_YUV420_NV12_UBWC_Y_TILE_HEIGHT 8 +#define HFI_COLOR_FORMAT_YUV420_NV12_UBWC_UV_TILE_WIDTH 16 +#define HFI_COLOR_FORMAT_YUV420_NV12_UBWC_UV_TILE_HEIGHT 8 +#define HFI_COLOR_FORMAT_YUV420_TP10_UBWC_Y_TILE_WIDTH 48 +#define HFI_COLOR_FORMAT_YUV420_TP10_UBWC_Y_TILE_HEIGHT 4 +#define BUFFER_ALIGNMENT_4096_BYTES 4096 +#define VENUS_METADATA_STRIDE_MULTIPLE 64 +#define VENUS_METADATA_HEIGHT_MULTIPLE 16 + +#define BUFFER_ALIGNMENT_SIZE(x) x + +#define VENUS_DMA_ALIGNMENT BUFFER_ALIGNMENT_SIZE(256) + +#define MAX_FE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE 64 +#define MAX_FE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE 64 +#define MAX_FE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE 64 +#define MAX_FE_NBR_DATA_LUMA_LINE_BUFFER_SIZE 640 +#define MAX_FE_NBR_DATA_CB_LINE_BUFFER_SIZE 320 +#define MAX_FE_NBR_DATA_CR_LINE_BUFFER_SIZE 320 + +#define MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE (128 / 8) +#define MAX_SE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE (128 / 8) +#define MAX_SE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE (128 / 8) + +#define MAX_PE_NBR_DATA_LCU64_LINE_BUFFER_SIZE (64 * 2 * 3) +#define MAX_PE_NBR_DATA_LCU32_LINE_BUFFER_SIZE (32 * 2 * 3) +#define MAX_PE_NBR_DATA_LCU16_LINE_BUFFER_SIZE (16 * 2 * 3) + +#define MAX_TILE_COLUMNS 32 /* 8K/256 */ + +#define NUM_HW_PIC_BUF 10 +#define BIN_BUFFER_THRESHOLD (1280 * 736) +#define H264D_MAX_SLICE 1800 +#define SIZE_H264D_BUFTAB_T 256 // sizeof(h264d_buftab_t) aligned to 256 +#define SIZE_H264D_HW_PIC_T BIT(11) // sizeof(h264d_hw_pic_t) 32 aligned +#define SIZE_H264D_BSE_CMD_PER_BUF (32 * 4) +#define SIZE_H264D_VPP_CMD_PER_BUF 512 + +// Line Buffer definitions +/* one for luma and 1/2 for each chroma */ +#define SIZE_H264D_LB_FE_TOP_DATA(width, height) \ + (MAX_FE_NBR_DATA_LUMA_LINE_BUFFER_SIZE * \ + ALIGN(width, 16) * 3) + +#define SIZE_H264D_LB_FE_TOP_CTRL(width, height) \ + (MAX_FE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE * \ + ((width + 15) >> 4)) + +#define SIZE_H264D_LB_FE_LEFT_CTRL(width, height) \ + (MAX_FE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE * \ + ((height + 15) >> 4)) + +#define SIZE_H264D_LB_SE_TOP_CTRL(width, height) \ + (MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE * \ + ((width + 15) >> 4)) + +#define SIZE_H264D_LB_SE_LEFT_CTRL(width, height) \ + (MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE * \ + ((height + 15) >> 4)) + +#define SIZE_H264D_LB_PE_TOP_DATA(width, height) \ + (MAX_PE_NBR_DATA_LCU64_LINE_BUFFER_SIZE * \ + ((width + 15) >> 4)) + +#define SIZE_H264D_LB_VSP_TOP(width, height) \ + width + 15) >> 4) << 7)) + +#define SIZE_H264D_LB_RECON_DMA_METADATA_WR(width, height) \ + (ALIGN(height, 16) * 32) + +#define SIZE_H264D_QP(width, height) \ + (((width + 63) >> 6) * ((height
Re: [PATCH] venus: move platform specific data to platform file
Hi Stanimir,
A gentle reminder for the review.
On 2020-05-29 12:37, Dikshita Agarwal wrote:
Move all data specific to platform into a separate file.
Signed-off-by: Dikshita Agarwal
---
drivers/media/platform/qcom/venus/Makefile | 3 +-
drivers/media/platform/qcom/venus/core.c | 20 ++---
drivers/media/platform/qcom/venus/core.h | 10 +--
drivers/media/platform/qcom/venus/helpers.c| 6 ++--
.../media/platform/qcom/venus/hfi_platform_data.c | 35
++
.../media/platform/qcom/venus/hfi_platform_data.h | 27
+
drivers/media/platform/qcom/venus/pm_helpers.c | 1 +
7 files changed, 73 insertions(+), 29 deletions(-)
create mode 100644
drivers/media/platform/qcom/venus/hfi_platform_data.c
create mode 100644
drivers/media/platform/qcom/venus/hfi_platform_data.h
diff --git a/drivers/media/platform/qcom/venus/Makefile
b/drivers/media/platform/qcom/venus/Makefile
index dfc6368..3878bc9 100644
--- a/drivers/media/platform/qcom/venus/Makefile
+++ b/drivers/media/platform/qcom/venus/Makefile
@@ -3,7 +3,8 @@
venus-core-objs += core.o helpers.o firmware.o \
hfi_venus.o hfi_msgs.o hfi_cmds.o hfi.o \
- hfi_parser.o pm_helpers.o dbgfs.o
+ hfi_parser.o pm_helpers.o dbgfs.o \
+ hfi_platform_data.o
venus-dec-objs += vdec.o vdec_ctrls.o
venus-enc-objs += venc.o venc_ctrls.o
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index bbb394c..4fde4aa 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -20,6 +20,7 @@
#include "core.h"
#include "firmware.h"
#include "pm_helpers.h"
+#include "hfi_platform_data.h"
static void venus_event_notify(struct venus_core *core, u32 event)
{
@@ -222,6 +223,8 @@ static int venus_probe(struct platform_device
*pdev)
return ret;
}
+ core->hfi_data = venus_get_hfi_platform(core->res->hfi_version);
+
ret = dma_set_mask_and_coherent(dev, core->res->dma_mask);
if (ret)
return ret;
@@ -461,17 +464,6 @@ static __maybe_unused int
venus_runtime_resume(struct device *dev)
{ 244800, 1 }, /* 1920x1080@30 */
};
-static const struct codec_freq_data sdm845_codec_freq_data[] = {
- { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_ENC, 675, 10 },
- { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_ENC, 675, 10 },
- { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_ENC, 675, 10 },
- { V4L2_PIX_FMT_MPEG2, VIDC_SESSION_TYPE_DEC, 200, 10 },
- { V4L2_PIX_FMT_H264, VIDC_SESSION_TYPE_DEC, 200, 10 },
- { V4L2_PIX_FMT_HEVC, VIDC_SESSION_TYPE_DEC, 200, 10 },
- { V4L2_PIX_FMT_VP8, VIDC_SESSION_TYPE_DEC, 200, 10 },
- { V4L2_PIX_FMT_VP9, VIDC_SESSION_TYPE_DEC, 200, 10 },
-};
-
static const struct bw_tbl sdm845_bw_table_enc[] = {
{ 1944000, 1612000, 0, 2416000, 0 },/* 3840x2160@60 */
{ 972000, 951000, 0, 1434000, 0 },/* 3840x2160@30 */
@@ -493,8 +485,6 @@ static __maybe_unused int
venus_runtime_resume(struct device *dev)
.bw_tbl_enc_size = ARRAY_SIZE(sdm845_bw_table_enc),
.bw_tbl_dec = sdm845_bw_table_dec,
.bw_tbl_dec_size = ARRAY_SIZE(sdm845_bw_table_dec),
- .codec_freq_data = sdm845_codec_freq_data,
- .codec_freq_data_size = ARRAY_SIZE(sdm845_codec_freq_data),
.clks = {"core", "iface", "bus" },
.clks_num = 3,
.vcodec0_clks = { "core", "bus" },
@@ -516,8 +506,6 @@ static __maybe_unused int
venus_runtime_resume(struct device *dev)
.bw_tbl_enc_size = ARRAY_SIZE(sdm845_bw_table_enc),
.bw_tbl_dec = sdm845_bw_table_dec,
.bw_tbl_dec_size = ARRAY_SIZE(sdm845_bw_table_dec),
- .codec_freq_data = sdm845_codec_freq_data,
- .codec_freq_data_size = ARRAY_SIZE(sdm845_codec_freq_data),
.clks = {"core", "iface", "bus" },
.clks_num = 3,
.vcodec0_clks = { "vcodec0_core", "vcodec0_bus" },
@@ -562,8 +550,6 @@ static __maybe_unused int
venus_runtime_resume(struct device *dev)
.bw_tbl_enc_size = ARRAY_SIZE(sc7180_bw_table_enc),
.bw_tbl_dec = sc7180_bw_table_dec,
.bw_tbl_dec_size = ARRAY_SIZE(sc7180_bw_table_dec),
- .codec_freq_data = sdm845_codec_freq_data,
- .codec_freq_data_size = ARRAY_SIZE(sdm845_codec_freq_data),
.clks = {"core", "iface", "bus" },
.clks_num = 3,
.vcodec0_clks = { "vcodec0_core", "vcodec0_bus" },
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 82438f1..86dc443 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -34,13 +34,6 @@ struct reg_val {
u32 value;
};
-struct codec_freq_data {
- u32 pixfmt;
- u32 session_type;
- unsigned long vpp_freq;
- unsigned long vsp_freq;
-};
-
struct bw_tbl {
u32
Re: [PATCH] venus: Add platform specific capabilities
Hi Stanimir,
A gentle reminder for the review.
Thanks,
Dikshita
On 2020-05-29 12:48, Dikshita Agarwal wrote:
Add platform specific capabilities and use them
in place of firmware capabilities.
Signed-off-by: Dikshita Agarwal
---
drivers/media/platform/qcom/venus/core.c | 3 +
drivers/media/platform/qcom/venus/hfi_helper.h | 3 +-
drivers/media/platform/qcom/venus/hfi_parser.c | 21 +--
.../media/platform/qcom/venus/hfi_platform_data.c | 153
-
.../media/platform/qcom/venus/hfi_platform_data.h | 37 -
5 files changed, 193 insertions(+), 24 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 4fde4aa..8221e5c 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -273,6 +273,9 @@ static int venus_probe(struct platform_device
*pdev)
if (ret)
goto err_venus_shutdown;
+ if (core->hfi_data && core->hfi_data->venus_parse_resources)
+ venus_parse_resources(core);
+
ret = hfi_core_init(core);
if (ret)
goto err_venus_shutdown;
diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h
b/drivers/media/platform/qcom/venus/hfi_helper.h
index f6613df..1671012 100644
--- a/drivers/media/platform/qcom/venus/hfi_helper.h
+++ b/drivers/media/platform/qcom/venus/hfi_helper.h
@@ -520,7 +520,8 @@
enum hfi_version {
HFI_VERSION_1XX,
HFI_VERSION_3XX,
- HFI_VERSION_4XX
+ HFI_VERSION_4XX,
+ HFI_VERSION_6XX
};
struct hfi_buffer_info {
diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c
b/drivers/media/platform/qcom/venus/hfi_parser.c
index 7f515a4..b4b60e1 100644
--- a/drivers/media/platform/qcom/venus/hfi_parser.c
+++ b/drivers/media/platform/qcom/venus/hfi_parser.c
@@ -10,30 +10,11 @@
#include "core.h"
#include "hfi_helper.h"
#include "hfi_parser.h"
+#include "hfi_platform_data.h"
typedef void (*func)(struct venus_caps *cap, const void *data,
unsigned int size);
-static void init_codecs(struct venus_core *core)
-{
- struct venus_caps *caps = core->caps, *cap;
- unsigned long bit;
-
- for_each_set_bit(bit, >dec_codecs, MAX_CODEC_NUM) {
- cap = [core->codecs_count++];
- cap->codec = BIT(bit);
- cap->domain = VIDC_SESSION_TYPE_DEC;
- cap->valid = false;
- }
-
- for_each_set_bit(bit, >enc_codecs, MAX_CODEC_NUM) {
- cap = [core->codecs_count++];
- cap->codec = BIT(bit);
- cap->domain = VIDC_SESSION_TYPE_ENC;
- cap->valid = false;
- }
-}
-
static void for_each_codec(struct venus_caps *caps, unsigned int
caps_num,
u32 codecs, u32 domain, func cb, void *data,
unsigned int size)
diff --git a/drivers/media/platform/qcom/venus/hfi_platform_data.c
b/drivers/media/platform/qcom/venus/hfi_platform_data.c
index 9d9035f..fc838f5 100644
--- a/drivers/media/platform/qcom/venus/hfi_platform_data.c
+++ b/drivers/media/platform/qcom/venus/hfi_platform_data.c
@@ -5,8 +5,132 @@
#include "hfi_platform_data.h"
#include "core.h"
+void init_codecs(struct venus_core *core)
+{
+ struct venus_caps *caps = core->caps, *cap;
+ unsigned long bit;
+
+ for_each_set_bit(bit, >dec_codecs, MAX_CODEC_NUM) {
+ cap = [core->codecs_count++];
+ cap->codec = BIT(bit);
+ cap->domain = VIDC_SESSION_TYPE_DEC;
+ cap->valid = false;
+ }
+
+ for_each_set_bit(bit, >enc_codecs, MAX_CODEC_NUM) {
+ cap = [core->codecs_count++];
+ cap->codec = BIT(bit);
+ cap->domain = VIDC_SESSION_TYPE_ENC;
+ cap->valid = false;
+ }
+}
+
+static void parse_codecs(struct venus_core *core)
+{
+ const struct venus_hfi_platform_data *hfi_data = core->hfi_data;
+ const struct venus_codecs *codecs = hfi_data->venus_codecs;
+ unsigned int i, codecs_size;
+
+ core->enc_codecs = 0;
+ core->dec_codecs = 0;
+ codecs_size = hfi_data->venus_codecs_size;
+
+ for (i = 0; i < codecs_size; i++) {
+ if (codecs[i].domain == VIDC_SESSION_TYPE_ENC)
+ core->enc_codecs |= codecs[i].codecs;
+ else
+ core->dec_codecs |= codecs[i].codecs;
+ }
+ init_codecs(core);
+}
+
+static int fill_raw_fmt(struct venus_capability *hfi_data_caps,
+ struct venus_caps *core_caps)
+{
+ if ((core_caps->num_pl + 1) == HFI_MAX_PROFILE_COUNT)
+ return -EINVAL;
+
+ core_caps->fmts[core_caps->num_fmts].buftype =
+ hfi_data_caps->capability_type;
+ core_caps->fmts[core_caps->num_fmts].fmt =
+ hfi_data_caps->defaul_value;
+ core_caps->num_fmts += 1;
+
+ return 0;
+}
[PATCH v2] tpm: tpm2-space: Resize session and context buffers dynamically
Re-allocate context and session buffers when needed. Scale them in page
increments so that the reallocation is only seldomly required, and thus
causes minimal stress to the system. Add a static maximum limit of four
pages for buffer sizes.
Cc: James Bottomley
Suggested-by: Stefan Berger
Signed-off-by: Jarkko Sakkinen
---
Tested only for compilation.
v2: TPM2_SPACE_DEFAULT_BUFFER_SIZE
drivers/char/tpm/tpm2-space.c | 87 ---
include/linux/tpm.h | 6 ++-
2 files changed, 64 insertions(+), 29 deletions(-)
diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
index 982d341d8837..b8ece01d6afb 100644
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -15,6 +15,9 @@
#include
#include "tpm.h"
+#define TPM2_SPACE_DEFAULT_BUFFER_SIZE PAGE_SIZE
+#define TPM2_SPACE_MAX_BUFFER_SIZE (4 * PAGE_SIZE)
+
enum tpm2_handle_types {
TPM2_HT_HMAC_SESSION= 0x0200,
TPM2_HT_POLICY_SESSION = 0x0300,
@@ -40,16 +43,21 @@ static void tpm2_flush_sessions(struct tpm_chip *chip,
struct tpm_space *space)
int tpm2_init_space(struct tpm_space *space)
{
- space->context_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ space->context_buf = kzalloc(TPM2_SPACE_DEFAULT_BUFFER_SIZE,
+GFP_KERNEL);
if (!space->context_buf)
return -ENOMEM;
- space->session_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ space->session_buf = kzalloc(TPM2_SPACE_DEFAULT_BUFFER_SIZE,
+GFP_KERNEL);
if (space->session_buf == NULL) {
kfree(space->context_buf);
+ space->context_buf = NULL;
return -ENOMEM;
}
+ space->context_size = TPM2_SPACE_DEFAULT_BUFFER_SIZE;
+ space->session_size = TPM2_SPACE_DEFAULT_BUFFER_SIZE;
return 0;
}
@@ -116,11 +124,13 @@ static int tpm2_load_context(struct tpm_chip *chip, u8
*buf,
return 0;
}
-static int tpm2_save_context(struct tpm_chip *chip, u32 handle, u8 *buf,
-unsigned int buf_size, unsigned int *offset)
+static int tpm2_save_context(struct tpm_chip *chip, u32 handle, u8 **buf,
+unsigned int *buf_size, unsigned int *offset)
{
- struct tpm_buf tbuf;
+ unsigned int new_buf_size;
unsigned int body_size;
+ struct tpm_buf tbuf;
+ void *new_buf;
int rc;
rc = tpm_buf_init(, TPM2_ST_NO_SESSIONS, TPM2_CC_CONTEXT_SAVE);
@@ -131,31 +141,48 @@ static int tpm2_save_context(struct tpm_chip *chip, u32
handle, u8 *buf,
rc = tpm_transmit_cmd(chip, , 0, NULL);
if (rc < 0) {
- dev_warn(>dev, "%s: failed with a system error %d\n",
-__func__, rc);
- tpm_buf_destroy();
- return -EFAULT;
+ rc = -EFAULT;
+ goto err;
} else if (tpm2_rc_value(rc) == TPM2_RC_REFERENCE_H0) {
- tpm_buf_destroy();
- return -ENOENT;
+ rc = -ENOENT;
+ goto out;
} else if (rc) {
- dev_warn(>dev, "%s: failed with a TPM error 0x%04X\n",
-__func__, rc);
- tpm_buf_destroy();
- return -EFAULT;
+ rc = -EFAULT;
+ goto err;
}
body_size = tpm_buf_length() - TPM_HEADER_SIZE;
- if ((*offset + body_size) > buf_size) {
- dev_warn(>dev, "%s: out of backing storage\n", __func__);
- tpm_buf_destroy();
- return -ENOMEM;
+ /* We grow the buffer in page increments. */
+ new_buf_size = PFN_UP(*offset + body_size);
+
+ if (new_buf_size > TPM2_SPACE_MAX_BUFFER_SIZE) {
+ rc = -ENOMEM;
+ goto err;
}
- memcpy([*offset], [TPM_HEADER_SIZE], body_size);
+ if (new_buf_size > *buf_size) {
+ new_buf = krealloc(*buf, new_buf_size, GFP_KERNEL);
+ if (!new_buf) {
+ rc = -ENOMEM;
+ goto err;
+ }
+
+ *buf = new_buf;
+ *buf_size = new_buf_size;
+ }
+
+ memcpy(*buf + *offset, [TPM_HEADER_SIZE], body_size);
*offset += body_size;
+
+out:
tpm_buf_destroy();
- return 0;
+ return rc;
+
+err:
+ dev_warn(>dev, "%s: ret=%d\n", __func__, rc);
+
+ tpm_buf_destroy();
+ return rc;
}
void tpm2_flush_space(struct tpm_chip *chip)
@@ -311,8 +338,10 @@ int tpm2_prepare_space(struct tpm_chip *chip, struct
tpm_space *space, u8 *cmd,
sizeof(space->context_tbl));
memcpy(>work_space.session_tbl, >session_tbl,
sizeof(space->session_tbl));
- memcpy(chip->work_space.context_buf, space->context_buf, PAGE_SIZE);
- memcpy(chip->work_space.session_buf, space->session_buf, PAGE_SIZE);
+
Re: [PATCH] tpm: tpm2-space: Resize session and context buffers dynamically
On Thu, Jun 25, 2020 at 07:24:20AM +0300, Jarkko Sakkinen wrote: > Re-allocate context and session buffers when needed. Scale them in page > increments so that the reallocation is only seldomly required, and thus > causes minimal stress to the system. Add a static maximum limit of four > pages for buffer sizes. > > Cc: James Bottomley > Suggested-by: Stefan Berger > Signed-off-by: Jarkko Sakkinen I'd actually consider #define TPM2_SPACE_DEFAULT_BUFFER_SIZE PAGE_SIZE #define TPM2_SPACE_MAX_BUFFER_SIZE (4 * PAGE_SIZE) /JQ4KKO
[PATCH] tpm: tpm2-space: Resize session and context buffers dynamically
Re-allocate context and session buffers when needed. Scale them in page
increments so that the reallocation is only seldomly required, and thus
causes minimal stress to the system. Add a static maximum limit of four
pages for buffer sizes.
Cc: James Bottomley
Suggested-by: Stefan Berger
Signed-off-by: Jarkko Sakkinen
---
Tested only for compilation.
drivers/char/tpm/tpm2-space.c | 80 ---
include/linux/tpm.h | 6 ++-
2 files changed, 59 insertions(+), 27 deletions(-)
diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
index 982d341d8837..acb9e82bf9e8 100644
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -15,6 +15,8 @@
#include
#include "tpm.h"
+#define TPM2_SPACE_MAX_BUFFER_SIZE (4 * PAGE_SIZE)
+
enum tpm2_handle_types {
TPM2_HT_HMAC_SESSION= 0x0200,
TPM2_HT_POLICY_SESSION = 0x0300,
@@ -47,9 +49,12 @@ int tpm2_init_space(struct tpm_space *space)
space->session_buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (space->session_buf == NULL) {
kfree(space->context_buf);
+ space->context_buf = NULL;
return -ENOMEM;
}
+ space->context_size = PAGE_SIZE;
+ space->session_size = PAGE_SIZE;
return 0;
}
@@ -116,11 +121,13 @@ static int tpm2_load_context(struct tpm_chip *chip, u8
*buf,
return 0;
}
-static int tpm2_save_context(struct tpm_chip *chip, u32 handle, u8 *buf,
-unsigned int buf_size, unsigned int *offset)
+static int tpm2_save_context(struct tpm_chip *chip, u32 handle, u8 **buf,
+unsigned int *buf_size, unsigned int *offset)
{
- struct tpm_buf tbuf;
+ unsigned int new_buf_size;
unsigned int body_size;
+ struct tpm_buf tbuf;
+ void *new_buf;
int rc;
rc = tpm_buf_init(, TPM2_ST_NO_SESSIONS, TPM2_CC_CONTEXT_SAVE);
@@ -131,31 +138,48 @@ static int tpm2_save_context(struct tpm_chip *chip, u32
handle, u8 *buf,
rc = tpm_transmit_cmd(chip, , 0, NULL);
if (rc < 0) {
- dev_warn(>dev, "%s: failed with a system error %d\n",
-__func__, rc);
- tpm_buf_destroy();
- return -EFAULT;
+ rc = -EFAULT;
+ goto err;
} else if (tpm2_rc_value(rc) == TPM2_RC_REFERENCE_H0) {
- tpm_buf_destroy();
- return -ENOENT;
+ rc = -ENOENT;
+ goto out;
} else if (rc) {
- dev_warn(>dev, "%s: failed with a TPM error 0x%04X\n",
-__func__, rc);
- tpm_buf_destroy();
- return -EFAULT;
+ rc = -EFAULT;
+ goto err;
}
body_size = tpm_buf_length() - TPM_HEADER_SIZE;
- if ((*offset + body_size) > buf_size) {
- dev_warn(>dev, "%s: out of backing storage\n", __func__);
- tpm_buf_destroy();
- return -ENOMEM;
+ /* We grow the buffer in page increments. */
+ new_buf_size = PFN_UP(*offset + body_size);
+
+ if (new_buf_size > TPM2_SPACE_MAX_BUFFER_SIZE) {
+ rc = -ENOMEM;
+ goto err;
}
- memcpy([*offset], [TPM_HEADER_SIZE], body_size);
+ if (new_buf_size > *buf_size) {
+ new_buf = krealloc(*buf, new_buf_size, GFP_KERNEL);
+ if (!new_buf) {
+ rc = -ENOMEM;
+ goto err;
+ }
+
+ *buf = new_buf;
+ *buf_size = new_buf_size;
+ }
+
+ memcpy(*buf + *offset, [TPM_HEADER_SIZE], body_size);
*offset += body_size;
+
+out:
tpm_buf_destroy();
- return 0;
+ return rc;
+
+err:
+ dev_warn(>dev, "%s: ret=%d\n", __func__, rc);
+
+ tpm_buf_destroy();
+ return rc;
}
void tpm2_flush_space(struct tpm_chip *chip)
@@ -311,8 +335,10 @@ int tpm2_prepare_space(struct tpm_chip *chip, struct
tpm_space *space, u8 *cmd,
sizeof(space->context_tbl));
memcpy(>work_space.session_tbl, >session_tbl,
sizeof(space->session_tbl));
- memcpy(chip->work_space.context_buf, space->context_buf, PAGE_SIZE);
- memcpy(chip->work_space.session_buf, space->session_buf, PAGE_SIZE);
+ memcpy(chip->work_space.context_buf, space->context_buf,
+ space->context_size);
+ memcpy(chip->work_space.session_buf, space->session_buf,
+ space->session_size);
rc = tpm2_load_space(chip);
if (rc) {
@@ -492,7 +518,8 @@ static int tpm2_save_space(struct tpm_chip *chip)
continue;
rc = tpm2_save_context(chip, space->context_tbl[i],
- space->context_buf, PAGE_SIZE,
+ >context_buf,
+
Re: [PATCH v2 2/2] Add PWM fan controller driver for LGM SoC
Hi Philipp,
On 18/6/2020 8:25 pm, Philipp Zabel wrote:
> Hi Rahul,
>
> On Thu, 2020-06-18 at 20:05 +0800, Rahul Tanwar wrote:
>> Intel Lightning Mountain(LGM) SoC contains a PWM fan controller.
>> This PWM controller does not have any other consumer, it is a
>> dedicated PWM controller for fan attached to the system. Add
>> driver for this PWM fan controller.
>>
>> Signed-off-by: Rahul Tanwar
>> ---
>> drivers/pwm/Kconfig | 9 +
>> drivers/pwm/Makefile| 1 +
>> drivers/pwm/pwm-intel-lgm.c | 400
>>
>> 3 files changed, 410 insertions(+)
>> create mode 100644 drivers/pwm/pwm-intel-lgm.c
>>
> [...]
>> diff --git a/drivers/pwm/pwm-intel-lgm.c b/drivers/pwm/pwm-intel-lgm.c
>> new file mode 100644
>> index ..3c7077acb161
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-intel-lgm.c
>> @@ -0,0 +1,400 @@
> [...]
>> +static int lgm_pwm_probe(struct platform_device *pdev)
>> +{
>> +struct lgm_pwm_chip *pc;
>> +struct device *dev = >dev;
>> +void __iomem *io_base;
>> +int ret;
>> +
>> +pc = devm_kzalloc(dev, sizeof(*pc), GFP_KERNEL);
>> +if (!pc)
>> +return -ENOMEM;
>> +
>> +io_base = devm_platform_ioremap_resource(pdev, 0);
>> +if (IS_ERR(io_base))
>> +return PTR_ERR(io_base);
>> +
>> +pc->regmap = devm_regmap_init_mmio(dev, io_base, _regmap_config);
>> +if (IS_ERR(pc->regmap)) {
>> +ret = PTR_ERR(pc->regmap);
>> +dev_err(dev, "failed to init register map: %pe\n", pc->regmap);
>> +return ret;
>> +}
>> +
>> +pc->clk = devm_clk_get(dev, NULL);
>> +if (IS_ERR(pc->clk)) {
>> +ret = PTR_ERR(pc->clk);
>> +dev_err(dev, "failed to get clock: %pe\n", pc->clk);
>> +return ret;
>> +}
>> +
>> +pc->rst = devm_reset_control_get(dev, NULL);
>> +if (IS_ERR(pc->rst)) {
>> +ret = PTR_ERR(pc->rst);
>> +dev_err(dev, "failed to get reset control: %pe\n", pc->rst);
>> +return ret;
>> +}
> Please use devm_reset_control_get_exclusive() to make it explicit an
> that exclusive reset control is requested. Given how the reset control
> is used, I think this driver could also use
> devm_reset_control_get_shared() to potentially allow sharing a reset
> line with other devices.
devm_reset_control_get() is a wrapper for devm_reset_control_get_exclusive().
Code as below:
static inline struct reset_control *devm_reset_control_get(
struct device *dev, const char *id)
{
return devm_reset_control_get_exclusive(dev, id);
}
Am i missing something else?
Regards,
Rahul
[RFC] Reed-Solomon Code: Update no_eras to the actual number of errors
Corr and eras_pos are updated to actual correction pattern and erasure
positions, but no_eras is not.
When this library is used to recover lost bytes, we normally memset the
lost trunk of bytes to zero as a placeholder. Unfortunately, if the lost
byte is zero, b[i] is zero too. Without correct no_eras, users won't be
able to determine the valid length of corr and eras_pos.
Signed-off-by: Aiden Leong
---
drivers/md/dm-verity-fec.c | 2 +-
fs/pstore/ram_core.c| 2 +-
include/linux/rslib.h | 4 ++--
lib/reed_solomon/decode_rs.c| 20 ++--
lib/reed_solomon/reed_solomon.c | 4 ++--
lib/reed_solomon/test_rslib.c | 18 --
6 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c
index fb41b4f23c48..ae8366a50244 100644
--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -50,7 +50,7 @@ static int fec_decode_rs8(struct dm_verity *v, struct
dm_verity_fec_io *fio,
for (i = 0; i < v->fec->roots; i++)
par[i] = fec[i];
- return decode_rs8(fio->rs, data, par, v->fec->rsn, NULL, neras,
+ return decode_rs8(fio->rs, data, par, v->fec->rsn, NULL, ,
fio->erasures, 0, NULL);
}
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index aa8e0b65ff1a..fcc661a60640 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -115,7 +115,7 @@ static int persistent_ram_decode_rs8(struct
persistent_ram_zone *prz,
for (i = 0; i < prz->ecc_info.ecc_size; i++)
prz->ecc_info.par[i] = ecc[i];
- return decode_rs8(prz->rs_decoder, data, prz->ecc_info.par, len,
+ return decode_rs8(prz->rs_decoder, data, prz->ecc_info.par, ,
NULL, 0, NULL, 0, NULL);
}
diff --git a/include/linux/rslib.h b/include/linux/rslib.h
index 238bb85243d3..80662abc9af7 100644
--- a/include/linux/rslib.h
+++ b/include/linux/rslib.h
@@ -64,7 +64,7 @@ int encode_rs8(struct rs_control *rs, uint8_t *data, int len,
uint16_t *par,
#endif
#ifdef CONFIG_REED_SOLOMON_DEC8
int decode_rs8(struct rs_control *rs, uint8_t *data, uint16_t *par, int len,
- uint16_t *s, int no_eras, int *eras_pos, uint16_t invmsk,
+ uint16_t *s, int *no_eras, int *eras_pos, uint16_t invmsk,
uint16_t *corr);
#endif
@@ -75,7 +75,7 @@ int encode_rs16(struct rs_control *rs, uint16_t *data, int
len, uint16_t *par,
#endif
#ifdef CONFIG_REED_SOLOMON_DEC16
int decode_rs16(struct rs_control *rs, uint16_t *data, uint16_t *par, int len,
- uint16_t *s, int no_eras, int *eras_pos, uint16_t invmsk,
+ uint16_t *s, int *no_eras, int *eras_pos, uint16_t invmsk,
uint16_t *corr);
#endif
diff --git a/lib/reed_solomon/decode_rs.c b/lib/reed_solomon/decode_rs.c
index 805de84ae83d..122bc08eb75f 100644
--- a/lib/reed_solomon/decode_rs.c
+++ b/lib/reed_solomon/decode_rs.c
@@ -24,6 +24,7 @@
int count = 0;
int num_corrected;
uint16_t msk = (uint16_t) rs->nn;
+ int no_eras_orig = no_eras ? *no_eras : 0;
/*
* The decoder buffers are in the rs control struct. They are
@@ -106,11 +107,11 @@
memset([1], 0, nroots * sizeof(lambda[0]));
lambda[0] = 1;
- if (no_eras > 0) {
+ if (no_eras_orig > 0) {
/* Init lambda to be the erasure locator polynomial */
lambda[1] = alpha_to[rs_modnn(rs,
prim * (nn - 1 - (eras_pos[0] + pad)))];
- for (i = 1; i < no_eras; i++) {
+ for (i = 1; i < no_eras_orig; i++) {
u = rs_modnn(rs, prim * (nn - 1 - (eras_pos[i] + pad)));
for (j = i + 1; j > 0; j--) {
tmp = index_of[lambda[j - 1]];
@@ -129,8 +130,8 @@
* Begin Berlekamp-Massey algorithm to determine error+erasure
* locator polynomial
*/
- r = no_eras;
- el = no_eras;
+ r = no_eras_orig;
+ el = no_eras_orig;
while (++r <= nroots) { /* r is the step number */
/* Compute discrepancy at the r-th step in poly-form */
discr_r = 0;
@@ -158,8 +159,8 @@
} else
t[i + 1] = lambda[i + 1];
}
- if (2 * el <= r + no_eras - 1) {
- el = r + no_eras - el;
+ if (2 * el <= r + no_eras_orig - 1) {
+ el = r + no_eras_orig - el;
/*
* 2 lines below: B(x) <-- inv(discr_r) *
* lambda(x)
@@ -312,14 +313,21 @@
eras_pos[j++] = loc[i] - pad;
}
}
+ if (no_eras > 0)
+
[tip:auto-latest] BUILD SUCCESS 9f2a2b6c23758d798f548911f6119def723d1029
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git auto-latest branch HEAD: 9f2a2b6c23758d798f548911f6119def723d1029 Merge branch 'core/urgent' elapsed time: 725m configs tested: 106 configs skipped: 4 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arc haps_hs_smp_defconfig s390 allyesconfig powerpc g5_defconfig mipsjmr3927_defconfig sh se7751_defconfig arm imx_v6_v7_defconfig armxcep_defconfig arm pxa255-idp_defconfig arm tango4_defconfig arm pxa_defconfig arm lpc18xx_defconfig mips ip27_defconfig arm eseries_pxa_defconfig mips loongson3_defconfig pariscallnoconfig armlart_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20200624 i386 randconfig-a006-20200624 i386 randconfig-a003-20200624 i386 randconfig-a001-20200624 i386 randconfig-a005-20200624 i386 randconfig-a004-20200624 i386 randconfig-a013-20200624 i386 randconfig-a016-20200624 i386 randconfig-a012-20200624 i386 randconfig-a014-20200624 i386 randconfig-a011-20200624 i386 randconfig-a015-20200624 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig umallnoconfig um defconfig um allmodconfig um allyesconfig x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64
Re: KASAN: null-ptr-deref Write in blk_mq_map_swqueue
On 2020-06-24 20:01, syzbot wrote: > This bug is marked as fixed by commit: > blk-mq: Fix a recently introduced regression in > But I can't find it in any tested tree for more than 90 days. > Is it a correct commit? Please update it by replying: > #syz fix: exact-commit-title > Until then the bug is still considered open and > new crashes with the same signature are ignored. #syz fix: blk-mq: Fix a recently introduced regression in blk_mq_realloc_hw_ctxs()
Re: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option
On Thu, Jun 25, 2020 at 10:00:09AM +0800, Nicolas Boichat wrote:
> On Thu, Jun 25, 2020 at 1:25 AM Alexei Starovoitov
> wrote:
> >
> > On Wed, Jun 24, 2020 at 9:07 AM Steven Rostedt wrote:
> > >
> > > On Wed, 24 Jun 2020 16:45:24 +0800
> > > Nicolas Boichat wrote:
> > >
> > > > trace_printk is only meant as a debugging tool, and should never be
> > > > compiled into production code without source code changes, as
> > > > indicated by the warning that shows up on boot if any trace_printk
> > > > is called:
> > > > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
> > > > ** **
> > > > ** trace_printk() being used. Allocating extra memory. **
> > > > ** **
> > > > ** This means that this is a DEBUG kernel and it is **
> > > > ** unsafe for production use. **
> > > >
> > > > If this option is set to n, the kernel will generate a build-time
> > > > error if trace_printk is used.
> > > >
> > > > Signed-off-by: Nicolas Boichat
> > >
> > > Interesting. Note, this will prevent modules with trace_printk from
> > > being loaded as well.
> >
> > Nack.
> > The message is bogus. It's used in production kernels.
> > bpf_trace_printk() calls it.
>
> Interesting. BTW, the same information (trace_printk is for debugging
> only) is repeated all over the place, including where bpf_trace_printk
> is documented:
> https://elixir.bootlin.com/linux/latest/source/include/linux/kernel.h#L757
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L706
> https://elixir.bootlin.com/linux/latest/source/kernel/trace/trace.c#L3157
>
> Steven added that warning (2184db46e425c ("tracing: Print nasty banner
> when trace_printk() is in use")), so maybe he can confirm if it's
> still relevant.
The banner is nasty and it's actively causing harm.
Every few month I have to explain to users that it's absolulte ok to
ignore that banner. Nothing bad is happening with the kernel.
The kernel is still perfectly safe for production use.
It's not a debug kernel.
What bpf_trace_printk() doc is saying that it's not recommended to use
this helper for production bpf programs. There are better alternatives.
It is absolutely fine to use bpf_trace_printk() to debug production and
experimental bpf programs on production servers, android phones and
everywhere else.
> Also, note that emitting the build error is behind a Kconfig option,
> you don't have to select it if you don't want to (the default is =y
> which allows trace_printk).
>
> If the overhead is real, we (Chrome OS) would like to make sure
> trace_printk does not slip into production kernels (we do want to
> provide basic tracing support so we can't just remove CONFIG_TRACING
> as a whole which would make trace_printk no-ops). I could also imagine
> potential security issues if people print raw pointers/sensitive data
> in trace_printk, assuming that the code is for debugging only.
>
> Also, the fact that the kernel test robot already found a stray
> trace_printk in drivers/usb/cdns3/gadget.c makes me think that this
> change is working as intended ,-) (we're going to need to add a few
> Kconfig deps though for other debugging options that intentionally use
> trace_printk).
Re: linux-next: build failure after merge of the rcu tree
On Thu, Jun 25, 2020 at 12:57:53PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the rcu tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> kernel/rcu/tree.c: In function 'rcu_dynticks_eqs_enter':
> kernel/rcu/tree.c:251:8: error: implicit declaration of function
> 'arch_atomic_add_return'; did you mean 'atomic_add_return'?
> [-Werror=implicit-function-declaration]
> 251 | seq = arch_atomic_add_return(RCU_DYNTICK_CTRL_CTR, >dynticks);
> |^~
> |atomic_add_return
> kernel/rcu/tree.c: In function 'rcu_dynticks_eqs_exit':
> kernel/rcu/tree.c:281:3: error: implicit declaration of function
> 'arch_atomic_andnot'; did you mean 'atomic_andnot'?
> [-Werror=implicit-function-declaration]
> 281 | arch_atomic_andnot(RCU_DYNTICK_CTRL_MASK, >dynticks);
> | ^~
> | atomic_andnot
> kernel/rcu/tree.c: In function 'rcu_dynticks_curr_cpu_in_eqs':
> kernel/rcu/tree.c:314:11: error: implicit declaration of function
> 'arch_atomic_read'; did you mean 'atomic_read'?
> [-Werror=implicit-function-declaration]
> 314 | return !(arch_atomic_read(>dynticks) & RCU_DYNTICK_CTRL_CTR);
> | ^~~~
> | atomic_read
>
> Caused by commit
>
> d2f8491368e5 ("rcu: Fixup noinstr warnings")
>
> I reverted that commit for today.
MIPS doesn't much like it, either. I hope to get an update tomorrow.
Apologies for the hassle!
Thanx, Paul
Re: linux-next: manual merge of the rcu tree with the tip tree
On Thu, Jun 25, 2020 at 12:44:52PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rcu tree got a conflict in:
>
> include/linux/smp.h
>
> between commit:
>
> 380dc20ce843 ("smp, irq_work: Continue smp_call_function*() and irq_work*()
> integration")
>
> from the tip tree and commit:
>
> 7effc6f7b465 ("EXP kernel/smp: Provide CSD lock timeout diagnostics")
>
> from the rcu tree.
>
> I have no idea how to fix this up ...
I have an interesting forward-port in my future, it seems.
> I fixed it up (I just effectively reverted the rcu tree commit) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
For the time being, I will move this out of my rcu/next pile.
Thanx, Paul
linux-next: build warning after merge of the scsi tree
Hi all,
After merging the scsi tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: missing MODULE_LICENSE() in drivers/scsi/ufs/ufs-exynos.o
Introduced by commit
55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs")
(not sure why I missed this earlier, sorry)
--
Cheers,
Stephen Rothwell
pgp2bY4BKRlHm.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Switch SPI to use GPIO for CS
Hi, On Wed, Jun 24, 2020 at 6:25 PM Stephen Boyd wrote: > > Quoting Douglas Anderson (2020-06-24 17:08:04) > > The geni SPI protocol appears to have been designed without taking > > Linux needs into account. In all the normal flows it takes care of > > setting chip select itself. However, Linux likes to manage the chip > > select so it can do fancy things. > > > > Back when we first landed the geni SPI driver we worked around this > > by: > > - Always setting the FRAGMENTATION bit in transfers, which (I believe) > > tells the SPI controller not to mess with the chip select during > > transfers. > > - Controlling the chip select manually by sending the SPI controller > > commands to assert or deassert the chip select. > > > > Our workaround was fine and it's been working OK, but it's really > > quite inefficient. A normal SPI transaction now needs to do: > > 1. Start a command to set the chip select. > > 2. Wait for an interrupt from controller saying chip select done. > > 3. Do a transfer. > > 4. Start a command to unset the chip select. > > 5. Wait for an interrupt from controller saying chip select done. > > I thought the GENI hardware was supposed to be able to queue commands up > and then plow through them to interrupt the CPU when it finished. If > that was supported would there be any problems? I assume we could remove > the wait for CS disable and interrupt on step 5 and also the wait for > CS/interrupt on step 2 because it is bundled with the transfer in step > 3. Do you have any details or pointers to documentation on said ability to queue commands? I don't think I've ever heard of it. How exactly would it work, anyway? There's no sequence number or anything in GENI and there's a single "DONE" interrupt that signals both "CS Done" and "Transfer Done", so without some really good docs I'd have a really hard time figuring out how this is supposed to work. > Where is the delay? On step 2 where we wait to transfer or at step 5 > when we wait for CS to be dropped, or both? Presumably every CS change takes the same amount of time? ...so I'd say "both". If it really matters I can try to measure. > > Things are made a bit worse because the Linux GPIO framework assumes > > that setting a chip select is quick. Thus the SPI core can be seen to > > tell us to set our chip select even when it's already in the right > > state and we were dutifully kicking off commands and waiting for > > interrupts. While we could optimize that particular case, we'd still > > be left with the slowness when we actually needed to toggle the chip > > select. > > One thing to note is that the GPIO driver doesn't tell us that it has > actually asserted/deasserted the GPIO. It writes to the controller and > moves on so we don't know when it has actually gone into effect. > Hopefully moving to GPIO mode doesn't mean we get weird problems where > CS isn't asserted yet and a transfer starts wiggling the lines. cs-gpios is a pretty normal Linux concept and not something I invented. It's documented to work just fine and I can't see this as being a real problem. > > All the chip select lines can actually be muxed to be GPIOs and > > there's really no downside in doing so. Now Linux can assert and > > deassert the chip select at will with a simple MMIO write. > > > > The SPI driver will still have the ability to set the chip select, but > > not we just won't use it. > > s/not/now/? Sigh. I always make that typo. I can spin if need be to fix. > > With this change I tested reading the firmware off the EC connected to > > a ChromeOS device (flashrom -p ec -r ...). I saw about a 25% speedup > > in total runtime of the command and a 30% reduction in interrupts > > generated (measured by /proc/interrupts). > > I see nothing wrong with specifying the CS gpios in DT. Seems like that > should always be there and then the driver should decide to use GPIO > mode or not. So > > Reviewed-by: Stephen Boyd > > for that part. I appreciate the tag, but I'm not sure it's working the way you're thinking it does? See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/spi/spi-controller.yaml >From there, when you specify spi-gpios it's saying: definitely use this GPIO as the chip select, don't use your native one. The bindings explicitly show how you would specify the native GPIO. If we wanted the SPI controller to decide one way or the other on its own, I guess we'd need an entirely new property saying that if it wanted to control its chip select with GPIO then here's the GPIO and then we'd need to provide a pinmux config for that. That feels overkill to me since I really see no reason not to use it as a GPIO. It's kinda like saying: if an SoC provided two different ways to set a pin, one of which always delayed 50 us to assert and one that asserted instantly, do we really need to write drivers to support both modes? No. The mode which delays 50 us is useless
Re: [PATCH v1 1/3] scsi: ufs: add write booster feature support
Hi Steev, On Wed, 2020-06-24 at 11:15 -0500, Steev Klimaszewski wrote: > On 6/23/20 8:53 PM, Stanley Chu wrote: > > Hi Steev, > > > > Please help try below simple patch to see if above WriteBooster messages > > can be eliminated. > > > > > > --- > > drivers/scsi/ufs/ufshcd.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > > index f173ad1bd79f..089c0785f0b3 100644 > > --- a/drivers/scsi/ufs/ufshcd.c > > +++ b/drivers/scsi/ufs/ufshcd.c > > @@ -6985,6 +6985,8 @@ static int ufs_get_device_desc(struct ufs_hba > > *hba) > > dev_info->wspecversion == 0x220 || > > (hba->dev_quirks & UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES)) > > ufshcd_wb_probe(hba, desc_buf); > > + else > > + hba->caps &= ~UFSHCD_CAP_WB_EN; > > > > /* > > * ufshcd_read_string_desc returns size of the string > > Hi Stanley, > > That worked. > > > 1. > [0.704775] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: > Unable to find vdd-hba-supply regulator, assuming enabled > 2. > [0.704781] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: > Unable to find vccq-supply regulator, assuming enabled > 3. > [0.704783] ufshcd-qcom 1d84000.ufshc: ufshcd_populate_vreg: > Unable to find vccq2-supply regulator, assuming enabled > 4. > [0.705618] ufshcd-qcom 1d84000.ufshc: Found QC Inline Crypto > Engine (ICE) v3.1.75 > 5. > [0.707496] scsi host0: ufshcd > 6. > [0.720415] ALSA device list: > 7. > [0.720422] No soundcards found. > 8. > [0.734245] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, > TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], > rate = 0 > 9. > [0.845159] ufshcd-qcom 1d84000.ufshc: ufshcd_print_pwr_info:[RX, > TX]: gear=[3, 3], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2 > 10. > [0.846399] ufshcd-qcom 1d84000.ufshc: > ufshcd_find_max_sup_active_icc_level: Regulator capability was not > set, actvIccLevel=0 > 11. > [0.849258] scsi 0:0:0:49488: Well-known LUNSAMSUNG > KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 > 12. > [0.853372] scsi 0:0:0:49476: Well-known LUNSAMSUNG > KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 > 13. > [0.855135] scsi 0:0:0:49456: Well-known LUNSAMSUNG > KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 > 14. > [0.857050] scsi 0:0:0:0: Direct-Access SAMSUNG > KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 > 15. > [0.858297] sd 0:0:0:0: Power-on or device reset occurred > 16. > [0.859985] scsi 0:0:0:1: Direct-Access SAMSUNG > KLUDG4U1EA-B0C1 0500 PQ: 0 ANSI: 6 > 17. > [0.860702] sd 0:0:0:0: [sda] 29765632 4096-byte logical blocks: > (122 GB/114 GiB) > > (full dmesg output at https://pastebin.com/Pvfqe42P ) > > I guess you can throw my Tested-by on there. > Thanks so much for the test! I have re-sent the patch with your "Tested-By" tag : ) Thanks a lot, Stanley Chu
[PATCH v1] driver core: Fix suspend/resume order issue with deferred probe
Under the following conditions:
- driver A is built in and can probe device-A
- driver B is a module and can probe device-B
- device-A is supplier of device-B
Without this patch:
1. device-A is added.
2. device-B is added.
3. dpm_list is now [device-A, device-B].
4. driver-A defers probe of device-A.
5. deferred probe of device-A is reattempted
6. device-A is moved to end of dpm_list.
6. dpm_list is now [device-B, device-A].
7. driver-B is loaded and probes device-B.
8. dpm_list stays as [device-B, device-A].
Suspend (which goes in the reverse order of dpm_list) fails because
device-A (supplier) is suspended before device-B (consumer).
With this patch:
1. device-A is added.
2. device-B is added.
3. dpm_list is now [device-A, device-B].
4. driver-A defers probe of device-A.
5. deferred probe of device-A is reattempted later.
6. dpm_list is now [device-B, device-A].
7. driver-B is loaded and probes device-B.
8. dpm_list is now [device-A, device-B].
Suspend works because device-B (consumer) is suspended before device-A
(supplier).
Fixes: 494fd7b7ad10 ("PM / core: fix deferred probe breaking suspend resume
order")
Fixes: 716a7a259690 ("driver core: fw_devlink: Add support for batching fwnode
parsing")
Cc: Geert Uytterhoeven
Signed-off-by: Saravana Kannan
---
drivers/base/dd.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9a1d940342ac..52b2148c7983 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -109,6 +109,8 @@ static void deferred_probe_work_func(struct work_struct
*work)
* probe makes that very unsafe.
*/
device_pm_move_to_tail(dev);
+ /* Greg/Rafael: SHOULD I DELETE THIS? ^^ I think I should, but
+* I'm worried if it'll have some unintended consequeneces. */
dev_dbg(dev, "Retrying from deferred list\n");
bus_probe_device(dev);
@@ -557,6 +559,20 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
goto re_probe;
}
+ /*
+* The devices are added to the dpm_list (resume/suspend (reverse
+* order) list) as they are registered with the driver core. But the
+* order the devices are added doesn't necessarily match the real
+* dependency order.
+*
+* The successful probe order is a much better signal. If a device just
+* probed successfully, then we know for sure that all the devices that
+* probed before it don't depend on the device. So, we can safely move
+* the device to the end of the dpm_list. As more devices probe,
+* they'll automatically get ordered correctly.
+*/
+ device_pm_move_to_tail(dev);
+
pinctrl_init_done(dev);
if (dev->pm_domain && dev->pm_domain->sync)
--
2.27.0.111.gc72c7da667-goog
Re: [PATCH v3 0/2] net: phy: call phy_disable_interrupts() in phy_init_hw()
On 6/24/2020 4:34 PM, David Miller wrote: > From: Florian Fainelli > Date: Wed, 24 Jun 2020 15:10:51 -0700 > >> Did you mean that you applied v4? It does not look like you pushed your >> local changes to net-next yet, so I cannot tell for sure. > > I ended up applying v4, yes. > OK, just making sure :) thanks! -- Florian
[PATCH v2] scsi: ufs: Disable WriteBooster capability in non-supported UFS device
If UFS device is not qualified to enter the detection of WriteBooster
probing by disallowed UFS version or device quirks, then WriteBooster
capability in host shall be disabled to prevent any WriteBooster
operations in the future.
Fixes: 3d17b9b5ab11 ("scsi: ufs: Add write booster feature support")
Signed-off-by: Stanley Chu
Tested-by: Steev Klimaszewski
Reviewed-by: Avri Altman
---
drivers/scsi/ufs/ufshcd.c | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f173ad1bd79f..c62bd47beeaa 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6847,21 +6847,31 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
static void ufshcd_wb_probe(struct ufs_hba *hba, u8 *desc_buf)
{
+ struct ufs_dev_info *dev_info = >dev_info;
u8 lun;
u32 d_lu_wb_buf_alloc;
if (!ufshcd_is_wb_allowed(hba))
return;
+ /*
+* Probe WB only for UFS-2.2 and UFS-3.1 (and later) devices or
+* UFS devices with quirk UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES
+* enabled
+*/
+ if (!(dev_info->wspecversion >= 0x310 ||
+ dev_info->wspecversion == 0x220 ||
+(hba->dev_quirks & UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES)))
+ goto wb_disabled;
if (hba->desc_size[QUERY_DESC_IDN_DEVICE] <
DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP + 4)
goto wb_disabled;
- hba->dev_info.d_ext_ufs_feature_sup =
+ dev_info->d_ext_ufs_feature_sup =
get_unaligned_be32(desc_buf +
DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP);
- if (!(hba->dev_info.d_ext_ufs_feature_sup & UFS_DEV_WRITE_BOOSTER_SUP))
+ if (!(dev_info->d_ext_ufs_feature_sup & UFS_DEV_WRITE_BOOSTER_SUP))
goto wb_disabled;
/*
@@ -6870,17 +6880,17 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, u8
*desc_buf)
* a max of 1 lun would have wb buffer configured.
* Now only shared buffer mode is supported.
*/
- hba->dev_info.b_wb_buffer_type =
+ dev_info->b_wb_buffer_type =
desc_buf[DEVICE_DESC_PARAM_WB_TYPE];
- hba->dev_info.b_presrv_uspc_en =
+ dev_info->b_presrv_uspc_en =
desc_buf[DEVICE_DESC_PARAM_WB_PRESRV_USRSPC_EN];
- if (hba->dev_info.b_wb_buffer_type == WB_BUF_MODE_SHARED) {
- hba->dev_info.d_wb_alloc_units =
+ if (dev_info->b_wb_buffer_type == WB_BUF_MODE_SHARED) {
+ dev_info->d_wb_alloc_units =
get_unaligned_be32(desc_buf +
DEVICE_DESC_PARAM_WB_SHARED_ALLOC_UNITS);
- if (!hba->dev_info.d_wb_alloc_units)
+ if (!dev_info->d_wb_alloc_units)
goto wb_disabled;
} else {
for (lun = 0; lun < UFS_UPIU_MAX_WB_LUN_ID; lun++) {
@@ -6891,7 +6901,7 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, u8
*desc_buf)
(u8 *)_lu_wb_buf_alloc,
sizeof(d_lu_wb_buf_alloc));
if (d_lu_wb_buf_alloc) {
- hba->dev_info.wb_dedicated_lu = lun;
+ dev_info->wb_dedicated_lu = lun;
break;
}
}
@@ -6977,14 +6987,7 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
ufs_fixup_device_setup(hba);
- /*
-* Probe WB only for UFS-3.1 devices or UFS devices with quirk
-* UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES enabled
-*/
- if (dev_info->wspecversion >= 0x310 ||
- dev_info->wspecversion == 0x220 ||
- (hba->dev_quirks & UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES))
- ufshcd_wb_probe(hba, desc_buf);
+ ufshcd_wb_probe(hba, desc_buf);
/*
* ufshcd_read_string_desc returns size of the string
--
2.18.0
Re: KASAN: null-ptr-deref Write in blk_mq_map_swqueue
This bug is marked as fixed by commit: blk-mq: Fix a recently introduced regression in But I can't find it in any tested tree for more than 90 days. Is it a correct commit? Please update it by replying: #syz fix: exact-commit-title Until then the bug is still considered open and new crashes with the same signature are ignored.
linux-next: build failure after merge of the rcu tree
Hi all,
After merging the rcu tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
kernel/rcu/tree.c: In function 'rcu_dynticks_eqs_enter':
kernel/rcu/tree.c:251:8: error: implicit declaration of function
'arch_atomic_add_return'; did you mean 'atomic_add_return'?
[-Werror=implicit-function-declaration]
251 | seq = arch_atomic_add_return(RCU_DYNTICK_CTRL_CTR, >dynticks);
|^~
|atomic_add_return
kernel/rcu/tree.c: In function 'rcu_dynticks_eqs_exit':
kernel/rcu/tree.c:281:3: error: implicit declaration of function
'arch_atomic_andnot'; did you mean 'atomic_andnot'?
[-Werror=implicit-function-declaration]
281 | arch_atomic_andnot(RCU_DYNTICK_CTRL_MASK, >dynticks);
| ^~
| atomic_andnot
kernel/rcu/tree.c: In function 'rcu_dynticks_curr_cpu_in_eqs':
kernel/rcu/tree.c:314:11: error: implicit declaration of function
'arch_atomic_read'; did you mean 'atomic_read'?
[-Werror=implicit-function-declaration]
314 | return !(arch_atomic_read(>dynticks) & RCU_DYNTICK_CTRL_CTR);
| ^~~~
| atomic_read
Caused by commit
d2f8491368e5 ("rcu: Fixup noinstr warnings")
I reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpSc0j4xzjdu.pgp
Description: OpenPGP digital signature
[PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty
Previously, if lock_pages() end up partially mapping pages, it used
to return -ERRNO due to which unlock_pages() have to go through
each pages[i] till *nr_pages* to validate them. This can be avoided
by passing correct number of partially mapped pages & -ERRNO separately,
while returning from lock_pages() due to error.
With this fix unlock_pages() doesn't need to validate pages[i] till
*nr_pages* for error scenario and few condition checks can be ignored.
As discussed, pages need to be marked as dirty before unpinned it in
unlock_pages() which was oversight.
Signed-off-by: Souptick Joarder
Cc: John Hubbard
Cc: Boris Ostrovsky
Cc: Paul Durrant
---
Hi,
I'm compile tested this, but unable to run-time test, so any testing
help is much appriciated.
drivers/xen/privcmd.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index a250d11..0da417c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch(
static int lock_pages(
struct privcmd_dm_op_buf kbufs[], unsigned int num,
- struct page *pages[], unsigned int nr_pages)
+ struct page *pages[], unsigned int nr_pages, int *pinned)
{
unsigned int i;
+ int errno = 0, page_count = 0;
for (i = 0; i < num; i++) {
unsigned int requested;
- int pinned;
+ *pinned += page_count;
requested = DIV_ROUND_UP(
offset_in_page(kbufs[i].uptr) + kbufs[i].size,
PAGE_SIZE);
if (requested > nr_pages)
return -ENOSPC;
- pinned = get_user_pages_fast(
+ page_count = get_user_pages_fast(
(unsigned long) kbufs[i].uptr,
requested, FOLL_WRITE, pages);
- if (pinned < 0)
- return pinned;
+ if (page_count < 0) {
+ errno = page_count;
+ return errno;
+ }
- nr_pages -= pinned;
- pages += pinned;
+ nr_pages -= page_count;
+ pages += page_count;
}
- return 0;
+ return errno;
}
static void unlock_pages(struct page *pages[], unsigned int nr_pages)
{
unsigned int i;
- if (!pages)
- return;
-
for (i = 0; i < nr_pages; i++) {
- if (pages[i])
- put_page(pages[i]);
+ if (!PageDirty(page))
+ set_page_dirty_lock(page);
+ put_page(pages[i]);
}
}
@@ -630,6 +631,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void
__user *udata)
struct xen_dm_op_buf *xbufs = NULL;
unsigned int i;
long rc;
+ int pinned = 0;
if (copy_from_user(, udata, sizeof(kdata)))
return -EFAULT;
@@ -683,9 +685,11 @@ static long privcmd_ioctl_dm_op(struct file *file, void
__user *udata)
goto out;
}
- rc = lock_pages(kbufs, kdata.num, pages, nr_pages);
- if (rc)
+ rc = lock_pages(kbufs, kdata.num, pages, nr_pages, );
+ if (rc < 0) {
+ nr_pages = pinned;
goto out;
+ }
for (i = 0; i < kdata.num; i++) {
set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr);
--
1.9.1
[PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()
In 2019, we introduced pin_user_pages*() and now we are converting
get_user_pages*() to the new API as appropriate. [1] & [2] could
be referred for more information. This is case 5 as per document [1].
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: Souptick Joarder
Cc: John Hubbard
Cc: Boris Ostrovsky
Cc: Paul Durrant
---
Hi,
I'm compile tested this, but unable to run-time test, so any testing
help is much appriciated.
drivers/xen/privcmd.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 0da417c..eb05254 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -595,7 +595,7 @@ static int lock_pages(
if (requested > nr_pages)
return -ENOSPC;
- page_count = get_user_pages_fast(
+ page_count = pin_user_pages_fast(
(unsigned long) kbufs[i].uptr,
requested, FOLL_WRITE, pages);
if (page_count < 0) {
@@ -612,13 +612,7 @@ static int lock_pages(
static void unlock_pages(struct page *pages[], unsigned int nr_pages)
{
- unsigned int i;
-
- for (i = 0; i < nr_pages; i++) {
- if (!PageDirty(page))
- set_page_dirty_lock(page);
- put_page(pages[i]);
- }
+ unpin_user_pages_dirty_lock(pages, nr_pages, 1);
}
static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
--
1.9.1
Re: [PATCH v5 1/2] acpi: Extend TPM2 ACPI table with missing log fields
On Thu, Jun 25, 2020 at 05:52:56AM +0300, Jarkko Sakkinen wrote:
> On Thu, Jun 25, 2020 at 05:34:38AM +0300, Jarkko Sakkinen wrote:
> > On Wed, Jun 24, 2020 at 08:38:25PM -0400, Stefan Berger wrote:
> > > On 6/24/20 8:00 PM, Jarkko Sakkinen wrote:
> > > > On Tue, Jun 23, 2020 at 08:06:35AM -0400, Stefan Berger wrote:
> > > > > From: Stefan Berger
> > > > >
> > > > > Recent extensions of the TPM2 ACPI table added 3 more fields
> > > > > including 12 bytes of start method specific parameters and Log Area
> > > > > Minimum Length (u32) and Log Area Start Address (u64). So, we extend
> > > > > the existing structure with these fields to allow non-UEFI systems
> > > > > to access the TPM2's log.
> > > > >
> > > > > The specification that has the new fields is the following:
> > > > >TCG ACPI Specification
> > > > >Family "1.2" and "2.0"
> > > > >Version 1.2, Revision 8
> > > > >
> > > > > Adapt all existing table size calculations to use
> > > > > offsetof(struct acpi_table_tpm2, start_method_specific)
> > > > > [where start_method_specific is a newly added field]
> > > > > rather than sizeof(struct acpi_table_tpm2) so that the addition
> > > > > of the new fields does not affect current systems that may not
> > > > > have them.
> > > > >
> > > > I found at least one regression from this patch. Please remove my
> > > > reviewed-by comment form the next version.
> > > >
> > > > Should have:
> > > >
> > > >Link:
> > > > https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification_v1.20_r8.pdf
> > > >
> > > > Please, add this.
> > > >
> > > > > Signed-off-by: Stefan Berger
> > > > > Cc: linux-a...@vger.kernel.org
> > > > > Acked-by: Rafael J. Wysocki
> > > > > Reviewed-by: Jarkko Sakkinen
> > > > > ---
> > > > > drivers/char/tpm/tpm_crb.c | 13 ++---
> > > > > drivers/char/tpm/tpm_tis.c | 4 +++-
> > > > > include/acpi/actbl3.h | 5 +++--
> > > > > 3 files changed, 16 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > > > > index a9dcf31eadd2..0565aa5482f9 100644
> > > > > --- a/drivers/char/tpm/tpm_crb.c
> > > > > +++ b/drivers/char/tpm/tpm_crb.c
> > > > > @@ -669,7 +669,9 @@ static int crb_acpi_add(struct acpi_device
> > > > > *device)
> > > > > status = acpi_get_table(ACPI_SIG_TPM2, 1,
> > > > > (struct acpi_table_header **) );
> > > > > - if (ACPI_FAILURE(status) || buf->header.length < sizeof(*buf)) {
> > > > > + if (ACPI_FAILURE(status) || buf->header.length <
> > > > > + offsetof(struct acpi_table_tpm2,
> > > > > + start_method_specific)) {
> > > > > dev_err(dev, FW_BUG "failed to get TPM2 ACPI table\n");
> > > > > return -EINVAL;
> > > > > }
> > > > > @@ -684,14 +686,19 @@ static int crb_acpi_add(struct acpi_device
> > > > > *device)
> > > > > return -ENOMEM;
> > > > > if (sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
> > > > > - if (buf->header.length < (sizeof(*buf) +
> > > > > sizeof(*crb_smc))) {
> > > > > + if (buf->header.length <
> > > > > + (offsetof(struct acpi_table_tpm2,
> > > > > + start_method_specific) +
> > > > Should be
> > > >
> > > >offsetof(struct acpti_table_tpm2, log_area_minimum_length)
> > >
> > >
> > > The old code had sizeof(*buf) with buf being 'struct acpi_table_tpm2' and
> > > that was equivalent to offsetof(struct acpi_table_tpm2,
> > > start_method_specific) since 'start_method_specific' is the first new
> > > field
> > > that we are adding right here. Also see 3rd paragraph in the patch
> > > description. The replacement rule described there should apply to all
> > > sizeof() calculations on 'struct acpi_table_tpm2.'
> >
> > Aren't you ignoring sizeof(*crb_smc) then?
>
> Duh, it's there I see. Sorry, my mistake.
>
> Please put the new fields in a separate struct:
>
> struct acpi_tpm2_phy {
> u8 start_method_specific[12];
> u32 log_area_minimum_length;
> u64 log_area_start_address;
> };
>
> This way we don't have to obfuscate all the calculations and zero out
> the need for 1/2 in this patch set.
Also remark that, if you continue the current patch, that would need
tested-by from ARM whereas a new struct does not because the ARM code
is intact.
/Jarkko
Re: [PATCH v5 1/2] acpi: Extend TPM2 ACPI table with missing log fields
On Thu, Jun 25, 2020 at 05:34:38AM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 24, 2020 at 08:38:25PM -0400, Stefan Berger wrote:
> > On 6/24/20 8:00 PM, Jarkko Sakkinen wrote:
> > > On Tue, Jun 23, 2020 at 08:06:35AM -0400, Stefan Berger wrote:
> > > > From: Stefan Berger
> > > >
> > > > Recent extensions of the TPM2 ACPI table added 3 more fields
> > > > including 12 bytes of start method specific parameters and Log Area
> > > > Minimum Length (u32) and Log Area Start Address (u64). So, we extend
> > > > the existing structure with these fields to allow non-UEFI systems
> > > > to access the TPM2's log.
> > > >
> > > > The specification that has the new fields is the following:
> > > >TCG ACPI Specification
> > > >Family "1.2" and "2.0"
> > > >Version 1.2, Revision 8
> > > >
> > > > Adapt all existing table size calculations to use
> > > > offsetof(struct acpi_table_tpm2, start_method_specific)
> > > > [where start_method_specific is a newly added field]
> > > > rather than sizeof(struct acpi_table_tpm2) so that the addition
> > > > of the new fields does not affect current systems that may not
> > > > have them.
> > > >
> > > I found at least one regression from this patch. Please remove my
> > > reviewed-by comment form the next version.
> > >
> > > Should have:
> > >
> > >Link:
> > > https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification_v1.20_r8.pdf
> > >
> > > Please, add this.
> > >
> > > > Signed-off-by: Stefan Berger
> > > > Cc: linux-a...@vger.kernel.org
> > > > Acked-by: Rafael J. Wysocki
> > > > Reviewed-by: Jarkko Sakkinen
> > > > ---
> > > > drivers/char/tpm/tpm_crb.c | 13 ++---
> > > > drivers/char/tpm/tpm_tis.c | 4 +++-
> > > > include/acpi/actbl3.h | 5 +++--
> > > > 3 files changed, 16 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > > > index a9dcf31eadd2..0565aa5482f9 100644
> > > > --- a/drivers/char/tpm/tpm_crb.c
> > > > +++ b/drivers/char/tpm/tpm_crb.c
> > > > @@ -669,7 +669,9 @@ static int crb_acpi_add(struct acpi_device *device)
> > > > status = acpi_get_table(ACPI_SIG_TPM2, 1,
> > > > (struct acpi_table_header **) );
> > > > - if (ACPI_FAILURE(status) || buf->header.length < sizeof(*buf)) {
> > > > + if (ACPI_FAILURE(status) || buf->header.length <
> > > > + offsetof(struct acpi_table_tpm2,
> > > > +start_method_specific)) {
> > > > dev_err(dev, FW_BUG "failed to get TPM2 ACPI table\n");
> > > > return -EINVAL;
> > > > }
> > > > @@ -684,14 +686,19 @@ static int crb_acpi_add(struct acpi_device
> > > > *device)
> > > > return -ENOMEM;
> > > > if (sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
> > > > - if (buf->header.length < (sizeof(*buf) +
> > > > sizeof(*crb_smc))) {
> > > > + if (buf->header.length <
> > > > + (offsetof(struct acpi_table_tpm2,
> > > > + start_method_specific) +
> > > Should be
> > >
> > >offsetof(struct acpti_table_tpm2, log_area_minimum_length)
> >
> >
> > The old code had sizeof(*buf) with buf being 'struct acpi_table_tpm2' and
> > that was equivalent to offsetof(struct acpi_table_tpm2,
> > start_method_specific) since 'start_method_specific' is the first new field
> > that we are adding right here. Also see 3rd paragraph in the patch
> > description. The replacement rule described there should apply to all
> > sizeof() calculations on 'struct acpi_table_tpm2.'
>
> Aren't you ignoring sizeof(*crb_smc) then?
Duh, it's there I see. Sorry, my mistake.
Please put the new fields in a separate struct:
struct acpi_tpm2_phy {
u8 start_method_specific[12];
u32 log_area_minimum_length;
u64 log_area_start_address;
};
This way we don't have to obfuscate all the calculations and zero out
the need for 1/2 in this patch set.
/Jarkko
[PATCH] [net/ipv6] Remove redundant null check in rt_mt6
rh cannot be NULL here since its already checked above assignment and is being dereferenced before. Remove the redundant null check. Signed-off-by: Gaurav Singh --- net/ipv6/netfilter/ip6t_rt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/netfilter/ip6t_rt.c b/net/ipv6/netfilter/ip6t_rt.c index f633dc84ca3f..733c83d38b30 100644 --- a/net/ipv6/netfilter/ip6t_rt.c +++ b/net/ipv6/netfilter/ip6t_rt.c @@ -89,8 +89,7 @@ static bool rt_mt6(const struct sk_buff *skb, struct xt_action_param *par) !((rtinfo->flags & IP6T_RT_RES) && (((const struct rt0_hdr *)rh)->reserved))); - ret = (rh != NULL) && - (segsleft_match(rtinfo->segsleft[0], rtinfo->segsleft[1], + ret = (segsleft_match(rtinfo->segsleft[0], rtinfo->segsleft[1], rh->segments_left, !!(rtinfo->invflags & IP6T_RT_INV_SGS))) && (!(rtinfo->flags & IP6T_RT_LEN) || -- 2.17.1
Re: [PATCH 05/10] mfd: sprd-sc27xx-spi: Fix symbol 'sprd_pmic_detect_charger_type' was not declared warning
Hi Lee, On Wed, Jun 24, 2020 at 11:07 PM Lee Jones wrote: > > Sparse reports: > > drivers/mfd/sprd-sc27xx-spi.c:59:23: warning: symbol > 'sprd_pmic_detect_charger_type' was not declared. Should it be static? > > ... due to a missing header file. > > Cc: > Cc: Orson Zhai > Cc: Baolin Wang > Cc: Chunyan Zhang > Signed-off-by: Lee Jones Thanks. Reviewed-by: Baolin Wang > --- > drivers/mfd/sprd-sc27xx-spi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c > index 6cde47243..c305e941e435c 100644 > --- a/drivers/mfd/sprd-sc27xx-spi.c > +++ b/drivers/mfd/sprd-sc27xx-spi.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > -- > 2.25.1 > -- Baolin Wang
[PATCH] [net/ipv6] Remove redundant null check in hbh_mt6
oh cannot be NULL since its already checked above after assignment and is being dereferenced before. Remove the redundant null check. Signed-off-by: Gaurav Singh --- net/ipv6/netfilter/ip6t_hbh.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/netfilter/ip6t_hbh.c b/net/ipv6/netfilter/ip6t_hbh.c index 467b2a86031b..e7a3fb9355ee 100644 --- a/net/ipv6/netfilter/ip6t_hbh.c +++ b/net/ipv6/netfilter/ip6t_hbh.c @@ -86,8 +86,7 @@ hbh_mt6(const struct sk_buff *skb, struct xt_action_param *par) ((optinfo->hdrlen == hdrlen) ^ !!(optinfo->invflags & IP6T_OPTS_INV_LEN; - ret = (oh != NULL) && - (!(optinfo->flags & IP6T_OPTS_LEN) || + ret = (!(optinfo->flags & IP6T_OPTS_LEN) || ((optinfo->hdrlen == hdrlen) ^ !!(optinfo->invflags & IP6T_OPTS_INV_LEN))); -- 2.17.1
linux-next: manual merge of the rcu tree with the tip tree
Hi all,
Today's linux-next merge of the rcu tree got a conflict in:
include/linux/smp.h
between commit:
380dc20ce843 ("smp, irq_work: Continue smp_call_function*() and irq_work*()
integration")
from the tip tree and commit:
7effc6f7b465 ("EXP kernel/smp: Provide CSD lock timeout diagnostics")
from the rcu tree.
I have no idea how to fix this up ...
I fixed it up (I just effectively reverted the rcu tree commit) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp71qceBRVdo.pgp
Description: OpenPGP digital signature
[PATCH] [net/ipv6] remove redundant null check in frag_mt6
fh cannot be NULL since its already checked above after assignment and is being dereferenced before. Remove the redundant null check. Signed-off-by: Gaurav Singh --- net/ipv6/netfilter/ip6t_frag.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/netfilter/ip6t_frag.c b/net/ipv6/netfilter/ip6t_frag.c index fb914a1e..3aad6439386b 100644 --- a/net/ipv6/netfilter/ip6t_frag.c +++ b/net/ipv6/netfilter/ip6t_frag.c @@ -85,8 +85,7 @@ frag_mt6(const struct sk_buff *skb, struct xt_action_param *par) !((fraginfo->flags & IP6T_FRAG_NMF) && (ntohs(fh->frag_off) & IP6_MF))); - return (fh != NULL) && - id_match(fraginfo->ids[0], fraginfo->ids[1], + return id_match(fraginfo->ids[0], fraginfo->ids[1], ntohl(fh->identification), !!(fraginfo->invflags & IP6T_FRAG_INV_IDS)) && !((fraginfo->flags & IP6T_FRAG_RES) && -- 2.17.1
[PATCH] [net/ipv6] Remove redundant null check in ah_mt6
ah cannot be NULL since its already checked above after assignment and is being dereferenced before in pr(). Remove the redundant null check. Signed-off-by: Gaurav Singh --- net/ipv6/netfilter/ip6t_ah.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/netfilter/ip6t_ah.c b/net/ipv6/netfilter/ip6t_ah.c index 4e15a14435e4..70da2f2ce064 100644 --- a/net/ipv6/netfilter/ip6t_ah.c +++ b/net/ipv6/netfilter/ip6t_ah.c @@ -74,8 +74,7 @@ static bool ah_mt6(const struct sk_buff *skb, struct xt_action_param *par) ahinfo->hdrres, ah->reserved, !(ahinfo->hdrres && ah->reserved)); - return (ah != NULL) && - spi_match(ahinfo->spis[0], ahinfo->spis[1], + return spi_match(ahinfo->spis[0], ahinfo->spis[1], ntohl(ah->spi), !!(ahinfo->invflags & IP6T_AH_INV_SPI)) && (!ahinfo->hdrlen || -- 2.17.1
cocci script from 2016 - assignment in if ?
https://lore.kernel.org/patchwork/patch/649705/ Any particular reason this wasn't applied? I ask because I added something similar recently to checkpatch.
Re: [PATCH v5 1/2] acpi: Extend TPM2 ACPI table with missing log fields
On Wed, Jun 24, 2020 at 08:38:25PM -0400, Stefan Berger wrote:
> On 6/24/20 8:00 PM, Jarkko Sakkinen wrote:
> > On Tue, Jun 23, 2020 at 08:06:35AM -0400, Stefan Berger wrote:
> > > From: Stefan Berger
> > >
> > > Recent extensions of the TPM2 ACPI table added 3 more fields
> > > including 12 bytes of start method specific parameters and Log Area
> > > Minimum Length (u32) and Log Area Start Address (u64). So, we extend
> > > the existing structure with these fields to allow non-UEFI systems
> > > to access the TPM2's log.
> > >
> > > The specification that has the new fields is the following:
> > >TCG ACPI Specification
> > >Family "1.2" and "2.0"
> > >Version 1.2, Revision 8
> > >
> > > Adapt all existing table size calculations to use
> > > offsetof(struct acpi_table_tpm2, start_method_specific)
> > > [where start_method_specific is a newly added field]
> > > rather than sizeof(struct acpi_table_tpm2) so that the addition
> > > of the new fields does not affect current systems that may not
> > > have them.
> > >
> > I found at least one regression from this patch. Please remove my
> > reviewed-by comment form the next version.
> >
> > Should have:
> >
> >Link:
> > https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification_v1.20_r8.pdf
> >
> > Please, add this.
> >
> > > Signed-off-by: Stefan Berger
> > > Cc: linux-a...@vger.kernel.org
> > > Acked-by: Rafael J. Wysocki
> > > Reviewed-by: Jarkko Sakkinen
> > > ---
> > > drivers/char/tpm/tpm_crb.c | 13 ++---
> > > drivers/char/tpm/tpm_tis.c | 4 +++-
> > > include/acpi/actbl3.h | 5 +++--
> > > 3 files changed, 16 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > > index a9dcf31eadd2..0565aa5482f9 100644
> > > --- a/drivers/char/tpm/tpm_crb.c
> > > +++ b/drivers/char/tpm/tpm_crb.c
> > > @@ -669,7 +669,9 @@ static int crb_acpi_add(struct acpi_device *device)
> > > status = acpi_get_table(ACPI_SIG_TPM2, 1,
> > > (struct acpi_table_header **) );
> > > - if (ACPI_FAILURE(status) || buf->header.length < sizeof(*buf)) {
> > > + if (ACPI_FAILURE(status) || buf->header.length <
> > > + offsetof(struct acpi_table_tpm2,
> > > + start_method_specific)) {
> > > dev_err(dev, FW_BUG "failed to get TPM2 ACPI table\n");
> > > return -EINVAL;
> > > }
> > > @@ -684,14 +686,19 @@ static int crb_acpi_add(struct acpi_device *device)
> > > return -ENOMEM;
> > > if (sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
> > > - if (buf->header.length < (sizeof(*buf) + sizeof(*crb_smc))) {
> > > + if (buf->header.length <
> > > + (offsetof(struct acpi_table_tpm2,
> > > + start_method_specific) +
> > Should be
> >
> >offsetof(struct acpti_table_tpm2, log_area_minimum_length)
>
>
> The old code had sizeof(*buf) with buf being 'struct acpi_table_tpm2' and
> that was equivalent to offsetof(struct acpi_table_tpm2,
> start_method_specific) since 'start_method_specific' is the first new field
> that we are adding right here. Also see 3rd paragraph in the patch
> description. The replacement rule described there should apply to all
> sizeof() calculations on 'struct acpi_table_tpm2.'
Aren't you ignoring sizeof(*crb_smc) then?
>
> I'll address the other issues.
>
>
> Stefan
Re: [PATCH 1/5] Huawei BMA: Adding Huawei BMA driver: host_edma_drv
Hi, Thank you for the patch! Yet something to improve: [auto build test ERROR on sparc-next/master] [also build test ERROR on linux/master linus/master ipvs/master v5.8-rc2] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/yunaixin03610-163-com/Adding-Huawei-BMA-drivers/20200623-014140 base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git master config: x86_64-allyesconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-13) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:67:5: warning: no previous prototype for 'edma_param_get_statics' [-Wmissing-prototypes] 67 | int edma_param_get_statics(char *buf, const struct kernel_param *kp) | ^~ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:142:5: warning: no previous prototype for '__atu_config_H' [-Wmissing-prototypes] 142 | s32 __atu_config_H(struct pci_dev *pdev, unsigned int region, | ^~ In file included from drivers/net/ethernet/huawei/bma/edma_drv/bma_devintf.h:20, from drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:21: drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c: In function 'ioremap_pme_bar1_mem': >> drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.h:80:17: error: implicit >> declaration of function 'ioremap_nocache'; did you mean 'ioremap_cache'? >> [-Werror=implicit-function-declaration] 80 | #define IOREMAP ioremap_nocache | ^~~ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:246:7: note: in expansion of macro 'IOREMAP' 246 | IOREMAP(bma_pci_dev->bma_base_phy_addr, | ^~~ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:245:30: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 245 | bma_pci_dev->bma_base_addr = | ^ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c: In function 'ioremap_bar_mem': drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:310:31: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 310 | bma_pci_dev->kbox_base_addr = | ^ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c: At top level: drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:328:5: warning: no previous prototype for 'pme_pci_enable_msi' [-Wmissing-prototypes] 328 | int pme_pci_enable_msi(struct pci_dev *pdev) | ^~ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:354:5: warning: no previous prototype for 'pci_device_init' [-Wmissing-prototypes] 354 | int pci_device_init(struct pci_dev *pdev, struct bma_pci_dev_s *bma_pci_dev) | ^~~ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:383:5: warning: no previous prototype for 'pci_device_config' [-Wmissing-prototypes] 383 | int pci_device_config(struct pci_dev *pdev) | ^ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:505:12: warning: no previous prototype for 'bma_pci_init' [-Wmissing-prototypes] 505 | int __init bma_pci_init(void) |^~~~ drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.c:518:13: warning: no previous prototype for 'bma_pci_cleanup' [-Wmissing-prototypes] 518 | void __exit bma_pci_cleanup(void) | ^~~ cc1: some warnings being treated as errors vim +80 drivers/net/ethernet/huawei/bma/edma_drv/bma_pci.h 76 77 #ifdef CONFIG_ARM64 78 #define IOREMAP ioremap_wc 79 #else > 80 #define IOREMAP ioremap_nocache 81 #endif 82 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH v2] tpm_tis: Remove the HID IFX0102
Acer C720 running Linux v5.3 reports this in klog:
tpm_tis: 1.2 TPM (device-id 0xB, rev-id 16)
tpm tpm0: tpm_try_transmit: send(): error -5
tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
tpm_tis tpm_tis: Could not get TPM timeouts and durations
tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
tpm tpm0: tpm_try_transmit: send(): error -5
tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
tpm_tis 00:08: Could not get TPM timeouts and durations
ima: No TPM chip found, activating TPM-bypass!
tpm_inf_pnp 00:08: Found TPM with ID IFX0102
% git --no-pager grep IFX0102 drivers/char/tpm
drivers/char/tpm/tpm_infineon.c:{"IFX0102", 0},
drivers/char/tpm/tpm_tis.c: {"IFX0102", 0}, /* Infineon */
Obviously IFX0102 was added to the HID table for the TCG TIS driver by
mistake.
Fixes: 93e1b7d42e1e ("[PATCH] tpm: add HID module parameter")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203877
Cc: Kylene Jo Hall
Reported-by: Ferry Toth:
Signed-off-by: Jarkko Sakkinen
---
v2:
git diff -R HEAD~1 -- drivers/char/tpm/tpm2-space.c | patch -p1
git diff -R HEAD~1 -- include/linux/tpm.h | patch -p1
drivers/char/tpm/tpm_tis.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index e7df342a317d..c58ea10fc92f 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -238,7 +238,6 @@ static int tpm_tis_pnp_init(struct pnp_dev *pnp_dev,
static struct pnp_device_id tpm_pnp_tbl[] = {
{"PNP0C31", 0}, /* TPM */
{"ATM1200", 0}, /* Atmel */
- {"IFX0102", 0}, /* Infineon */
{"BCM0101", 0}, /* Broadcom */
{"BCM0102", 0}, /* Broadcom */
{"NSC1200", 0}, /* National */
--
2.25.1
Re: [PATCH] tpm_tis: Remove the HID IFX0102
On Thu, Jun 25, 2020 at 02:00:33AM +0300, Jarkko Sakkinen wrote:
> Acer C720 running Linux v5.3 reports this in klog:
>
> tpm_tis: 1.2 TPM (device-id 0xB, rev-id 16)
> tpm tpm0: tpm_try_transmit: send(): error -5
> tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
> tpm_tis tpm_tis: Could not get TPM timeouts and durations
> tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
> tpm tpm0: tpm_try_transmit: send(): error -5
> tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
> tpm_tis 00:08: Could not get TPM timeouts and durations
> ima: No TPM chip found, activating TPM-bypass!
> tpm_inf_pnp 00:08: Found TPM with ID IFX0102
>
> % git --no-pager grep IFX0102 drivers/char/tpm
> drivers/char/tpm/tpm_infineon.c: {"IFX0102", 0},
> drivers/char/tpm/tpm_tis.c: {"IFX0102", 0}, /* Infineon */
>
> Obviously IFX0102 was added to the HID table for the TCG TIS driver by
> mistake.
>
> Fixes: 93e1b7d42e1e ("[PATCH] tpm: add HID module parameter")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203877
> Cc: Kylene Jo Hall
> Reported-by: Ferry Toth:
> Signed-off-by: Jarkko Sakkinen
Sending v2 some unrelated stuff by mistake.
/Jarkko
Re: [PATCH 02/22] kbuild: add support for Clang LTO
Hi Sami, On Wed, Jun 24, 2020 at 01:31:40PM -0700, 'Sami Tolvanen' via Clang Built Linux wrote: > This change adds build system support for Clang's Link Time > Optimization (LTO). With -flto, instead of ELF object files, Clang > produces LLVM bitcode, which is compiled into native code at link > time, allowing the final binary to be optimized globally. For more > details, see: > > https://llvm.org/docs/LinkTimeOptimization.html > > The Kconfig option CONFIG_LTO_CLANG is implemented as a choice, > which defaults to LTO being disabled. To use LTO, the architecture > must select ARCH_SUPPORTS_LTO_CLANG and support: > > - compiling with Clang, > - compiling inline assembly with Clang's integrated assembler, > - and linking with LLD. > > While using full LTO results in the best runtime performance, the > compilation is not scalable in time or memory. CONFIG_THINLTO > enables ThinLTO, which allows parallel optimization and faster > incremental builds. ThinLTO is used by default if the architecture > also selects ARCH_SUPPORTS_THINLTO: > > https://clang.llvm.org/docs/ThinLTO.html > > To enable LTO, LLVM tools must be used to handle bitcode files. The > easiest way is to pass the LLVM=1 option to make: > > $ make LLVM=1 defconfig > $ scripts/config -e LTO_CLANG > $ make LLVM=1 > > Alternatively, at least the following LLVM tools must be used: > > CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm > > To prepare for LTO support with other compilers, common parts are > gated behind the CONFIG_LTO option, and LTO can be disabled for > specific files by filtering out CC_FLAGS_LTO. > > Note that support for DYNAMIC_FTRACE and MODVERSIONS are added in > follow-up patches. > > Signed-off-by: Sami Tolvanen > --- > Makefile | 16 > arch/Kconfig | 66 +++ > include/asm-generic/vmlinux.lds.h | 11 -- > scripts/Makefile.build| 9 - > scripts/Makefile.modfinal | 9 - > scripts/Makefile.modpost | 24 ++- > scripts/link-vmlinux.sh | 32 +++ > 7 files changed, 151 insertions(+), 16 deletions(-) > > diff --git a/Makefile b/Makefile > index ac2c61c37a73..0c7fe6fb2143 100644 > --- a/Makefile > +++ b/Makefile > @@ -886,6 +886,22 @@ KBUILD_CFLAGS+= $(CC_FLAGS_SCS) > export CC_FLAGS_SCS > endif > > +ifdef CONFIG_LTO_CLANG > +ifdef CONFIG_THINLTO > +CC_FLAGS_LTO_CLANG := -flto=thin $(call cc-option, -fsplit-lto-unit) > +KBUILD_LDFLAGS += --thinlto-cache-dir=.thinlto-cache > +else > +CC_FLAGS_LTO_CLANG := -flto > +endif > +CC_FLAGS_LTO_CLANG += -fvisibility=default > +endif > + > +ifdef CONFIG_LTO > +CC_FLAGS_LTO := $(CC_FLAGS_LTO_CLANG) > +KBUILD_CFLAGS+= $(CC_FLAGS_LTO) > +export CC_FLAGS_LTO > +endif > + > # arch Makefile may override CC so keep this after arch Makefile is included > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) > > diff --git a/arch/Kconfig b/arch/Kconfig > index 8cc35dc556c7..e00b122293f8 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -552,6 +552,72 @@ config SHADOW_CALL_STACK > reading and writing arbitrary memory may be able to locate them > and hijack control flow by modifying the stacks. > > +config LTO > + bool > + > +config ARCH_SUPPORTS_LTO_CLANG > + bool > + help > + An architecture should select this option if it supports: > + - compiling with Clang, > + - compiling inline assembly with Clang's integrated assembler, > + - and linking with LLD. > + > +config ARCH_SUPPORTS_THINLTO > + bool > + help > + An architecture should select this option if it supports Clang's > + ThinLTO. > + > +config THINLTO > + bool "Clang ThinLTO" > + depends on LTO_CLANG && ARCH_SUPPORTS_THINLTO > + default y > + help > + This option enables Clang's ThinLTO, which allows for parallel > + optimization and faster incremental compiles. More information > + can be found from Clang's documentation: > + > + https://clang.llvm.org/docs/ThinLTO.html > + > +choice > + prompt "Link Time Optimization (LTO)" > + default LTO_NONE > + help > + This option enables Link Time Optimization (LTO), which allows the > + compiler to optimize binaries globally. > + > + If unsure, select LTO_NONE. > + > +config LTO_NONE > + bool "None" > + > +config LTO_CLANG > + bool "Clang's Link Time Optimization (EXPERIMENTAL)" > + depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD I am curious, what is the reason for gating this at clang 11.0.0? Presumably this? https://github.com/ClangBuiltLinux/linux/issues/510 It might be nice to notate this so that we do not have to wonder :) Cheers, Nathan
Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
Hi Geoff, On Wed, Jun 24, 2020 at 06:18:48PM -0700, Geoff Levand wrote: > Hi Nathan, > > On 6/23/20 8:59 PM, Nathan Chancellor wrote: > > These are not true arrays, they are linker defined symbols, which are > > just addresses. Using the address of operator silences the warning > > and does not change the resulting assembly with either clang/ld.lld > > or gcc/ld (tested with diff + objdump -Dr). > > Thanks for your patch. I tested this patch applied to v5.8-rc2 on a > PS3 and it seems OK. > > Tested-by: Geoff Levand Thanks a lot for the quick response and testing, I really appreciate it! Cheers, Nathan
Re: [PATCH v3 1/1] eventfd: implementation of EFD_MASK flag
Hi Damian,
On Tue, Jun 23, 2020 at 06:21:28PM +0900, Damian Hobson-Garcia wrote:
> On 2020-06-19 7:16 p.m., Paul Elder wrote:
> > Hello Damian, Martin, and all,
> >
> > I came across this (quite old by now) patch to extend eventfd's polling
> > functionality. I was wondering what happened to it (why it hasn't been
> > merged yet) and if we could, or what is needed to, move it forward.
>
> I think there was an open question about whether it was
> best to move the definitions of EFD_SEMAPHORE, etc out of
> /include/linux/eventfd.h and into a newly created
> /include/uapi/linux/eventfd.h as this patch does.
I would have thought that defining EFD_SEMAPHORE in a public API header
would be best, but it seems that glibc has its own definition in
bits/eventfd.h. I don't know what is usually preferred in these cases.
> I don't know if the maintainers have any concerns on this matter, or the
> patch in general, that would prevent this from moving forward.
Thanks for your reply. It seems a good way forward would be to resubmit
the patch then.
> > I was thinking to use it for V4L2 events support via polling in the V4L2
> > compatibility layer for libcamera [1]. We can signal V4L2 buffer
> > availability POLLOUT via write(), but there is no way to signal V4L2
> > events, as they are signaled via POLLPRI.
> >
> > [1] https://libcamera.org/docs.html#id1
> >
> > On Thu, Oct 15, 2015 at 10:42:08AM +0900, Damian Hobson-Garcia wrote:
> >> From: Martin Sustrik
> >>
> >> When implementing network protocols in user space, one has to implement
> >> fake file descriptors to represent the sockets for the protocol.
> >>
> >> Polling on such fake file descriptors is a problem (poll/select/epoll
> >> accept only true file descriptors) and forces protocol implementers to use
> >> various workarounds resulting in complex, non-standard and convoluted APIs.
> >>
> >> More generally, ability to create full-blown file descriptors for
> >> userspace-to-userspace signalling is missing. While eventfd(2) goes half
> >> the way towards this goal it has follwoing shorcomings:
> >>
> >> I. There's no way to signal POLLPRI, POLLHUP etc.
> >> II. There's no way to signal arbitrary combination of POLL* flags. Most
> >> notably, simultaneous !POLLIN and !POLLOUT, which is a perfectly valid
> >> combination for a network protocol (rx buffer is empty and tx buffer is
> >> full), cannot be signaled using eventfd.
> >>
> >> This patch implements new EFD_MASK flag which solves the above problems.
> >>
> >> The semantics of EFD_MASK are as follows:
> >>
> >> eventfd(2):
> >>
> >> If eventfd is created with EFD_MASK flag set, it is initialised in such a
> >> way as to signal no events on the file descriptor when it is polled on.
> >> The 'initval' argument is ignored.
> >>
> >> write(2):
> >>
> >> User is allowed to write only buffers containing a 32-bit value
> >> representing any combination of event flags as defined by the poll(2)
> >> function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.). Specified events
> >> will be signaled when polling (select, poll, epoll) on the eventfd is
> >> done later on.
> >>
> >> read(2):
> >>
> >> read is not supported and will fail with EINVAL.
> >>
> >> select(2), poll(2) and similar:
> >>
> >> When polling on the eventfd marked by EFD_MASK flag, all the events
> >> specified in last written event flags shall be signaled.
> >>
> >> Signed-off-by: Martin Sustrik
> >>
> >> [dhobs...@igel.co.jp: Rebased, and resubmitted for Linux 4.3]
> >> Signed-off-by: Damian Hobson-Garcia
> >> ---
> >> fs/eventfd.c | 102
> >> ++-
> >> include/linux/eventfd.h | 16 +--
> >> include/uapi/linux/eventfd.h | 33 ++
> >> 3 files changed, 126 insertions(+), 25 deletions(-)
> >> create mode 100644 include/uapi/linux/eventfd.h
> >>
> >> diff --git a/fs/eventfd.c b/fs/eventfd.c
> >> index 8d0c0df..1310779 100644
> >> --- a/fs/eventfd.c
> >> +++ b/fs/eventfd.c
> >> @@ -2,6 +2,7 @@
> >> * fs/eventfd.c
> >> *
> >> * Copyright (C) 2007 Davide Libenzi
> >> + * Copyright (C) 2013 Martin Sustrik
> >> *
> >> */
> >>
> >> @@ -22,18 +23,31 @@
> >> #include
> >> #include
> >>
> >> +#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
> >> +#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE | EFD_MASK)
> >> +#define EFD_MASK_VALID_EVENTS (POLLIN | POLLPRI | POLLOUT | POLLERR |
> >> POLLHUP)
> >> +
> >> struct eventfd_ctx {
> >>struct kref kref;
> >>wait_queue_head_t wqh;
> >> - /*
> >> - * Every time that a write(2) is performed on an eventfd, the
> >> - * value of the __u64 being written is added to "count" and a
> >> - * wakeup is performed on "wqh". A read(2) will return the "count"
> >> - * value to userspace, and will reset "count" to zero. The kernel
> >> - * side eventfd_signal() also, adds to the "count" counter and
> >> - * issue a wakeup.
> >> - */
> >> - __u64 count;
> >> + union {
Re: [PATCH 1/3] v4l2-subdev: Add subdev ioctl support for ENUM/GET/SET INPUT
Hi Jacopo,
On Wed, Jun 24, 2020 at 09:53:07AM +0200, Jacopo Mondi wrote:
> On Tue, Jun 16, 2020 at 12:00:15PM +0200, Ramzi BEN MEFTAH wrote:
> > From: Steve Longerbeam
>
> +Niklas, +Laurent
>
> Niklas, Laurent, how does this play with CAP_IO_MC ?
I don't think it's related to CAP_IO_MC, but I don't think it's a good
idea either :-) Routing doesn't go through the subdev [gs]_input
operations in MC-based drivers. It should be configured through link
setup instead. This patch goes in the wrong direction, sorry Steve.
> > This commit enables VIDIOC_ENUMINPUT, VIDIOC_G_INPUT, and VIDIOC_S_INPUT
> > ioctls for use via v4l2 subdevice node.
> >
> > This commit should probably not be pushed upstream, because the (old)
> > idea of video inputs conflicts with the newer concept of establishing
> > media links between src->sink pads.
> >
> > However it might make sense for some subdevices to support enum/get/set
> > inputs. One example would be the analog front end subdevice for the
> > ADV748x. By providing these ioctls, selecting the ADV748x analog inputs
> > can be done without requiring the implementation of media entities that
> > would define the analog source for which to establish a media link.
> >
> > Signed-off-by: Steve Longerbeam
> > ---
> > drivers/media/v4l2-core/v4l2-subdev.c | 9 +
> > include/media/v4l2-subdev.h | 11 +++
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
> > b/drivers/media/v4l2-core/v4l2-subdev.c
> > index 6b989fe..73fbfe9 100644
> > --- a/drivers/media/v4l2-core/v4l2-subdev.c
> > +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> > @@ -378,6 +378,15 @@ static long subdev_do_ioctl(struct file *file,
> > unsigned int cmd, void *arg)
> > return -ENOTTY;
> > return v4l2_querymenu(vfh->ctrl_handler, arg);
> >
> > + case VIDIOC_ENUMINPUT:
> > + return v4l2_subdev_call(sd, video, enuminput, arg);
> > +
> > + case VIDIOC_G_INPUT:
> > + return v4l2_subdev_call(sd, video, g_input, arg);
> > +
> > + case VIDIOC_S_INPUT:
> > + return v4l2_subdev_call(sd, video, s_input, *(u32 *)arg);
> > +
> > case VIDIOC_G_CTRL:
> > if (!vfh->ctrl_handler)
> > return -ENOTTY;
> > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> > index f7fe78a..6e1a9cd 100644
> > --- a/include/media/v4l2-subdev.h
> > +++ b/include/media/v4l2-subdev.h
> > @@ -383,6 +383,14 @@ struct v4l2_mbus_frame_desc {
> > * @g_input_status: get input status. Same as the status field in the
> > * _input
> > *
> > + * @enuminput: enumerate inputs. Should return the same input status as
> > + * @g_input_status if the passed input index is the currently active
> > + * input.
> > + *
> > + * @g_input: returns the currently active input index.
> > + *
> > + * @s_input: set the active input.
> > + *
> > * @s_stream: used to notify the driver that a video stream will start or
> > has
> > * stopped.
> > *
> > @@ -423,6 +431,9 @@ struct v4l2_subdev_video_ops {
> > int (*g_tvnorms)(struct v4l2_subdev *sd, v4l2_std_id *std);
> > int (*g_tvnorms_output)(struct v4l2_subdev *sd, v4l2_std_id *std);
> > int (*g_input_status)(struct v4l2_subdev *sd, u32 *status);
> > + int (*enuminput)(struct v4l2_subdev *sd, struct v4l2_input *input);
> > + int (*g_input)(struct v4l2_subdev *sd, u32 *index);
> > + int (*s_input)(struct v4l2_subdev *sd, u32 index);
> > int (*s_stream)(struct v4l2_subdev *sd, int enable);
> > int (*g_pixelaspect)(struct v4l2_subdev *sd, struct v4l2_fract *aspect);
> > int (*g_frame_interval)(struct v4l2_subdev *sd,
--
Regards,
Laurent Pinchart
Re: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option
On Thu, Jun 25, 2020 at 1:25 AM Alexei Starovoitov
wrote:
>
> On Wed, Jun 24, 2020 at 9:07 AM Steven Rostedt wrote:
> >
> > On Wed, 24 Jun 2020 16:45:24 +0800
> > Nicolas Boichat wrote:
> >
> > > trace_printk is only meant as a debugging tool, and should never be
> > > compiled into production code without source code changes, as
> > > indicated by the warning that shows up on boot if any trace_printk
> > > is called:
> > > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
> > > ** **
> > > ** trace_printk() being used. Allocating extra memory. **
> > > ** **
> > > ** This means that this is a DEBUG kernel and it is **
> > > ** unsafe for production use. **
> > >
> > > If this option is set to n, the kernel will generate a build-time
> > > error if trace_printk is used.
> > >
> > > Signed-off-by: Nicolas Boichat
> >
> > Interesting. Note, this will prevent modules with trace_printk from
> > being loaded as well.
>
> Nack.
> The message is bogus. It's used in production kernels.
> bpf_trace_printk() calls it.
Interesting. BTW, the same information (trace_printk is for debugging
only) is repeated all over the place, including where bpf_trace_printk
is documented:
https://elixir.bootlin.com/linux/latest/source/include/linux/kernel.h#L757
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L706
https://elixir.bootlin.com/linux/latest/source/kernel/trace/trace.c#L3157
Steven added that warning (2184db46e425c ("tracing: Print nasty banner
when trace_printk() is in use")), so maybe he can confirm if it's
still relevant.
Also, note that emitting the build error is behind a Kconfig option,
you don't have to select it if you don't want to (the default is =y
which allows trace_printk).
If the overhead is real, we (Chrome OS) would like to make sure
trace_printk does not slip into production kernels (we do want to
provide basic tracing support so we can't just remove CONFIG_TRACING
as a whole which would make trace_printk no-ops). I could also imagine
potential security issues if people print raw pointers/sensitive data
in trace_printk, assuming that the code is for debugging only.
Also, the fact that the kernel test robot already found a stray
trace_printk in drivers/usb/cdns3/gadget.c makes me think that this
change is working as intended ,-) (we're going to need to add a few
Kconfig deps though for other debugging options that intentionally use
trace_printk).
Re: [PATCH v3 3/4] docs: Add documentation for user space client interface
Hi Mani, On 6/18/20 11:39 PM, Manivannan Sadhasivam wrote: On Thu, Jun 11, 2020 at 11:13:43AM -0700, Hemant Kumar wrote: MHI user space client driver is creating device file node for user application to perform file operations. File operations are handled by MHI core driver. Currently Loopback MHI channel is supported by this driver. Signed-off-by: Hemant Kumar --- Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 19 +++ 2 files changed, 20 insertions(+) create mode 100644 Documentation/mhi/uci.rst diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst index 1d8dec3..c75a371 100644 --- a/Documentation/mhi/index.rst +++ b/Documentation/mhi/index.rst @@ -9,6 +9,7 @@ MHI mhi topology + uci .. only:: subproject and html diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst new file mode 100644 index 000..a5c5c4f --- /dev/null +++ b/Documentation/mhi/uci.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +User space Client Interface (UCI) Stick to 'Userspace' everywhere. Done. += + +UCI driver enables user space clients to communicate to external MHI devices +like modem and WLAN. It creates standard character device file nodes for user UCI driver creates a single char device, isn't it? No, it is created per device name. For example Loopback has its own char device file node. if we add another channel for a new mhi device new device file node would be created. +space clients to perform open, read, write, pool and close file operations. + poll? Btw, you need to mention explicitly how this char device can be used. You are just mentioning standard file operations. Will fix poll.My idea was indeed to mention generic file operations so that we dont have to be specific with use case. Any userspace entity who wants to communicate over mhi can use the driver. Reason we have this driver is to abstract the mhi core specific details. Even for loopback use case, userspace can echo to device file node on one channel and get a same in response from another channel back. I can add more examples of other user space drivers use case if that helps. +Device file node is created with format:- + +/dev/mhi__ + +controller_name is the name of underlying bus used to transfer data. underlying controller instance. Done. +mhi_device_name is the name of the MHI channel being used by MHI client What do you mean by MHI client here? Are you referring to userspace client? yes. i can say "MHI client in userspace"? +to send or receive data using MHI protocol. MHI channels are statically +defined by MHI specification. Driver currently supports LOOPBACK channel +index 0 (Host to device) and 1 (Device to Host). s/index/identifier Done. And explain a bit on how this LOOPBACK channel is getting used. Done. Thanks, Mani -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH net 1/3] net: bcmgenet: re-remove bcmgenet_hfb_add_filter
On 6/24/2020 6:14 PM, Doug Berger wrote:
> This function was originally removed by Baoyou Xie in
> commit e2072600a241 ("net: bcmgenet: remove unused function in
> bcmgenet.c") to prevent a build warning.
>
> Some of the functions removed by Baoyou Xie are now used for
> WAKE_FILTER support so his commit was reverted, but this function
> is still unused and the kbuild test robot dutifully reported the
> warning.
>
> This commit once again removes the remaining unused hfb functions.
>
> Fixes: 14da1510fedc ("Revert "net: bcmgenet: remove unused function in
> bcmgenet.c"")
> Reported-by: kbuild test robot
> Signed-off-by: Doug Berger
Acked-by: Florian Fainelli
--
Florian
Re: [PATCH net 2/3] net: bcmgenet: use __be16 for htons(ETH_P_IP)
On 6/24/2020 6:14 PM, Doug Berger wrote:
> The 16-bit value that holds a short in network byte order should
> be declared as a restricted big endian type to allow type checks
> to succeed during assignment.
>
> Fixes: 3e370952287c ("net: bcmgenet: add support for ethtool rxnfc flows")
> Reported-by: kbuild test robot
> Signed-off-by: Doug Berger
Acked-by: Florian Fainelli
--
Florian
Re: [PATCH net 3/3] net: bcmgenet: use hardware padding of runt frames
On 6/24/2020 6:14 PM, Doug Berger wrote:
> When commit 474ea9cafc45 ("net: bcmgenet: correctly pad short
> packets") added the call to skb_padto() it should have been
> located before the nr_frags parameter was read since that value
> could be changed when padding packets with lengths between 55
> and 59 bytes (inclusive).
>
> The use of a stale nr_frags value can cause corruption of the
> pad data when tx-scatter-gather is enabled. This corruption of
> the pad can cause invalid checksum computation when hardware
> offload of tx-checksum is also enabled.
>
> Since the original reason for the padding was corrected by
> commit 7dd399130efb ("net: bcmgenet: fix skb_len in
> bcmgenet_xmit_single()") we can remove the software padding all
> together and make use of hardware padding of short frames as
> long as the hardware also always appends the FCS value to the
> frame.
>
> Fixes: 474ea9cafc45 ("net: bcmgenet: correctly pad short packets")
> Signed-off-by: Doug Berger
Acked-by: Florian Fainelli
--
Florian
Re: [PATCH v4 00/11] kunit: create a centralized executor to dispatch all KUnit tests
Glad this is back out there: a couple of minor nitpicks below: On Thu, Jun 25, 2020 at 4:58 AM Brendan Higgins wrote: > > ## TL;DR > > This patchset adds a centralized executor to dispatch tests rather than > relying on late_initcall to schedule each test suite separately along > with a couple of new features that depend on it. > > Also, sorry for the extreme delay in getting this out. Part of the delay > came from finding that there were actually several architectures that > the previous revision of this patchset didn't work on, so I went through > and attempted to test this patchset on every architecture - more on that > later. > > ## What am I trying to do? > > Conceptually, I am trying to provide a mechanism by which test suites > can be grouped together so that they can be reasoned about collectively. > The last two of three patches in this series add features which depend > on this: > > PATCH 8/11 Prints out a test plan[1] right before KUnit tests are run; >this is valuable because it makes it possible for a test >harness to detect whether the number of tests run matches the >number of tests expected to be run, ensuring that no tests >silently failed. The test plan includes a count of tests that >will run. With the centralized executor, the tests are >located in a single data structure and thus can be counted. > This appears to actually be patch 9/11. > PATCH 9/11 Add a new kernel command-line option which allows the user to >specify that the kernel poweroff, halt, or reboot after >completing all KUnit tests; this is very handy for running >KUnit tests on UML or a VM so that the UML/VM process exits >cleanly immediately after running all tests without needing a >special initramfs. The centralized executor provides a >definitive point when all tests have completed and the >poweroff, halt, or reboot could occur. This seems to have been merged into the above patch (9/11). > In addition, by dispatching tests from a single location, we can > guarantee that all KUnit tests run after late_init is complete, which > was a concern during the initial KUnit patchset review (this has not > been a problem in practice, but resolving with certainty is nevertheless > desirable). > > Other use cases for this exist, but the above features should provide an > idea of the value that this could provide. > > ## Changes since last revision: > - On the last revision I got some messages from 0day that showed that >this patchset didn't work on several architectures, one issue that >this patchset addresses is that we were aligning both memory segments >as well as structures in the segments to specific byte boundaries >which was incorrect. > - The issue mentioned above also caused me to test on additional >architectures which revealed that some architectures other than UML >do not use the default init linker section macro that most >architectures use. There are now several new patches (2, 3, 4, and >6). > - Fixed a formatting consistency issue in the kernel params >documentation patch (9/9). > - Add a brief blurb on how and when the kunit_test_suite macro works. > > ## Remaining work to be done: > > The only architecture for which I was able to get a compiler, but was > apparently unable to get KUnit into a section that the executor to see > was m68k - not sure why. > > Alan Maguire (1): > kunit: test: create a single centralized executor for all tests > > Brendan Higgins (10): > vmlinux.lds.h: add linker section for KUnit test suites > arch: arm64: add linker section for KUnit test suites > arch: microblaze: add linker section for KUnit test suites > arch: powerpc: add linker section for KUnit test suites > arch: um: add linker section for KUnit test suites > arch: xtensa: add linker section for KUnit test suites > init: main: add KUnit to kernel init > kunit: test: add test plan to KUnit TAP format > Documentation: Add kunit_shutdown to kernel-parameters.txt > Documentation: kunit: add a brief blurb about kunit_test_suite > > .../admin-guide/kernel-parameters.txt | 8 ++ > Documentation/dev-tools/kunit/usage.rst | 5 ++ > arch/arm64/kernel/vmlinux.lds.S | 3 + > arch/microblaze/kernel/vmlinux.lds.S | 4 + > arch/powerpc/kernel/vmlinux.lds.S | 4 + > arch/um/include/asm/common.lds.S | 4 + > arch/xtensa/kernel/vmlinux.lds.S | 4 + > include/asm-generic/vmlinux.lds.h | 8 ++ > include/kunit/test.h | 73 - > init/main.c | 4 + > lib/kunit/Makefile| 3 +- > lib/kunit/executor.c | 63 +++ > lib/kunit/test.c | 13 +-- >
Re: [PATCH drivers/misc 0/4] lkdtm: Various clean ups
On 6/24/20 3:35 PM, Randy Dunlap wrote:
> On 6/24/20 3:23 PM, Randy Dunlap wrote:
>> On 6/24/20 3:01 PM, Richard Weinberger wrote:
>>> On Wed, Jun 24, 2020 at 11:29 PM Randy Dunlap wrote:
On 6/24/20 1:36 PM, Kees Cook wrote:
> On Wed, Jun 24, 2020 at 09:23:25AM +0200, Richard Weinberger wrote:
>> - Ursprüngliche Mail -
> Regardless, it seems arch/x86/um/asm/desc.h is not needed any more?
>>>
True that, we can rip the file.
>>>
>>> Has anyone fixed the uml build errors?
>>
>> I didn't realize that this is a super urgent issue. ;-)
>>
>> Kees, if you want you can carry a patch in your series, I'll ack it.
>> Otherwise I can also do a patch and bring it via the uml tree upstream
>> as soon more fixes queued up.
>
> I think the lkdtm change will tweak this bug, so I'm happy to carry the
> patch (I just haven't had time to create and test one). Is it really
> just as simple as removing arch/x86/um/asm/desc.h?
>
I just tried that and the build is still failing, so No, it's not that
simple.
But thanks for offering.
I'll just ignore the UML build errors for now.
>>>
>>> This is a allyesconfig?
>>> I just gave CONFIG_LKDTM=y a try, builds fine here.
>>>
>>
>> I'm building linux-next and it fails.
>
> More specifically, uml for i386 fails. x86_64 is OK.
> The problem is with the file.
> I'm tampering with it...
I'm not getting anywhere with this. Too many mazes of tiny twisty passages.
>>> But the desc.h in uml is still in vain and can be deleted AFAICT.
Looks like lkdtm/bugs.c needs to get/use arch/x86/include/asm/processor.h
but it actually uses arch/x86/um/asm/processor*.h, which does not have the
needed structs etc.
Here are the build errors and warnings that I am seeing with allmodconfig:
CC [M] drivers/misc/lkdtm/bugs.o
In file included from ../arch/x86/include/asm/desc.h:11:0,
from ../drivers/misc/lkdtm/bugs.c:17:
../arch/x86/include/asm/cpu_entry_area.h:65:42: error: invalid application of
‘sizeof’ to incomplete type ‘struct x86_hw_tss’
unsigned long stack[(PAGE_SIZE - sizeof(struct x86_hw_tss)) / sizeof(unsigned
long)];
^~
../arch/x86/include/asm/cpu_entry_area.h:66:20: error: field ‘tss’ has
incomplete type
struct x86_hw_tss tss;
^~~
../arch/x86/include/asm/cpu_entry_area.h:89:26: error: field ‘entry_stack_page’
has incomplete type
struct entry_stack_page entry_stack_page;
^~~~
../arch/x86/include/asm/cpu_entry_area.h:100:20: error: field ‘tss’ has
incomplete type
struct tss_struct tss;
^~~
In file included from ../drivers/misc/lkdtm/bugs.c:17:0:
../arch/x86/include/asm/desc.h:45:25: error: ‘GDT_ENTRIES’ undeclared here (not
in a function); did you mean ‘LDT_ENTRIES’?
struct desc_struct gdt[GDT_ENTRIES];
^~~
LDT_ENTRIES
../arch/x86/include/asm/desc.h: In function ‘__set_tss_desc’:
../arch/x86/include/asm/desc.h:186:10: error: ‘__KERNEL_TSS_LIMIT’ undeclared
(first use in this function); did you mean ‘__KERNEL__’?
__KERNEL_TSS_LIMIT);
^~
__KERNEL__
../arch/x86/include/asm/desc.h:186:10: note: each undeclared identifier is
reported only once for each function it appears in
../arch/x86/include/asm/desc.h: In function ‘native_set_ldt’:
../arch/x86/include/asm/desc.h:202:40: error: ‘GDT_ENTRY_LDT’ undeclared (first
use in this function); did you mean ‘GDT_ENTRY_INIT’?
write_gdt_entry(get_cpu_gdt_rw(cpu), GDT_ENTRY_LDT,
^
../arch/x86/include/asm/desc.h:123:75: note: in definition of macro
‘write_gdt_entry’
#define write_gdt_entry(dt, entry, desc, type) native_write_gdt_entry(dt,
entry, desc, type)
^
../arch/x86/include/asm/desc.h: In function ‘native_load_tr_desc’:
../arch/x86/include/asm/desc.h:259:31: error: ‘GDT_ENTRY_TSS’ undeclared (first
use in this function); did you mean ‘GDT_ENTRIES’?
asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
^
GDT_ENTRIES
../arch/x86/include/asm/desc.h: In function ‘native_load_tls’:
../arch/x86/include/asm/desc.h:278:33: error: ‘struct thread_struct’ has no
member named ‘tls_array’
gdt[GDT_ENTRY_TLS_MIN + i] = t->tls_array[i];
^~
In file included from ../arch/x86/include/asm/string.h:3:0,
from ../include/linux/string.h:20,
from ../arch/x86/um/asm/processor_32.h:9,
from ../arch/x86/um/asm/processor.h:10,
from ../include/linux/rcupdate.h:30,
from ../include/linux/rculist.h:11,
from ../include/linux/pid.h:5,
from
Re: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option
On Thu, Jun 25, 2020 at 12:04 AM Steven Rostedt wrote: > > On Wed, 24 Jun 2020 16:45:24 +0800 > Nicolas Boichat wrote: > > > trace_printk is only meant as a debugging tool, and should never be > > compiled into production code without source code changes, as > > indicated by the warning that shows up on boot if any trace_printk > > is called: > > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE ** > > ** ** > > ** trace_printk() being used. Allocating extra memory. ** > > ** ** > > ** This means that this is a DEBUG kernel and it is ** > > ** unsafe for production use. ** > > > > If this option is set to n, the kernel will generate a build-time > > error if trace_printk is used. > > > > Signed-off-by: Nicolas Boichat > > Interesting. Note, this will prevent modules with trace_printk from > being loaded as well. Err, all of these changes are in macros (nothing gets built in the kernel), so this will prevent modules with trace_printk from being _built_. Now, if you set the option to =y when building the module (separately, even though the rest of the kernel has =n) then I don't see why the module could not be loaded. > > -- Steve
Re: [PATCH v33 02/21] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control hardware bits
On Wed, Jun 24, 2020 at 07:34:40AM -0700, Sean Christopherson wrote:
> On Wed, Jun 24, 2020 at 03:04:34PM +0200, Borislav Petkov wrote:
> > On Thu, Jun 18, 2020 at 01:08:24AM +0300, Jarkko Sakkinen wrote:
> > > From: Sean Christopherson
> > >
> > > Add X86_FEATURE_SGX_LC, which informs whether or not the CPU supports SGX
> > > Launch Control.
> > >
> > > Add MSR_IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}, which when combined contain a
> > > SHA256 hash of a 3072-bit RSA public key. SGX backed software packages, so
> > > called enclaves, are always signed. All enclaves signed with the public
> > > key
> > > are unconditionally allowed to initialize. [1]
> > >
> > > Add FEATURE_CONTROL_SGX_LE_WR bit of the feature control MSR, which
> > > informs
> >
> > LE_WR or LC_ENABLED?
>
> It should be FEAT_CTL_SGX_LC_ENABLED, i.e. the actual code is correct. We
> updated the #define to use the SDM name to be consistent with the other bits
> and neglected to update the changelog.
>
> Thanks!
>
> > With that addressed:
> >
> > Reviewed-by: Borislav Petkov
I'll update the commit according to this information.
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> > https://people.kernel.org/tglx/notes-about-netiquette
Thank you.
/Jarkko
Re: Null-ptr-deref due to "vfs, fsinfo: Add an RCU safe per-ns mount list"
Hi all,
On Wed, 24 Jun 2020 11:57:07 -0400 Qian Cai wrote:
>
> On Wed, May 13, 2020 at 12:29:52AM +0100, David Howells wrote:
> > Qian Cai wrote:
> >
> > > Reverted the linux-next commit ee8ad8190cb1 (“vfs, fsinfo: Add an RCU
> > > safe per-ns mount list”) fixed the null-ptr-deref.
> >
> > Okay, I'm dropping this commit for now.
>
> What's the point of re-adding this buggy patch to linux-next again since
> 0621 without fixing the previous reported issue at all? Reverting the
> commit will still fix the crash below immediately, i.e.,
>
> dbc87e74d022 ("vfs, fsinfo: Add an RCU safe per-ns mount list")
I have added a revert of that commit to linux-next today.
--
Cheers,
Stephen Rothwell
pgpIXwKK165W0.pgp
Description: OpenPGP digital signature
Re: [PATCH v33 01/21] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits
On Mon, Jun 22, 2020 at 07:37:11PM +0200, Borislav Petkov wrote: > On Thu, Jun 18, 2020 at 01:08:23AM +0300, Jarkko Sakkinen wrote: > > From: Sean Christopherson > > > > Add X86_FEATURE_SGX from CPUID.(EAX=7, ECX=1), which informs whether the > > CPU has SGX. > > > > Add X86_FEATURE_SGX1 and X86_FEATURE_SGX2 from CPUID.(EAX=12H, ECX=0), > > which describe the level of SGX support available [1]. > > > > Add IA32_FEATURE_CONTROL_SGX_ENABLE. BIOS can use this bit to opt-in SGX > > I'm guessing that wants to be > > IA32_FEATURE_CONTROL.SGX_ENABLE > > judging by the diff and the SDM chapter. Underscore must be just a typo. > > > before locking the feature control MSR [2]. > > > > [1] Intel SDM: 36.7.2 Intel® SGX Resource Enumeration Leaves > > [2] Intel SDM: 36.7.1 Intel® SGX Opt-In Configuration > > > > Cc: Borislav Petkov > > Acked-by: Jethro Beekman > > Signed-off-by: Sean Christopherson > > Co-developed-by: Jarkko Sakkinen > > Signed-off-by: Jarkko Sakkinen > > --- > > arch/x86/include/asm/cpufeature.h| 5 +++-- > > arch/x86/include/asm/cpufeatures.h | 7 ++- > > arch/x86/include/asm/disabled-features.h | 18 +++--- > > arch/x86/include/asm/msr-index.h | 1 + > > arch/x86/include/asm/required-features.h | 2 +- > > arch/x86/kernel/cpu/common.c | 4 > > tools/arch/x86/include/asm/cpufeatures.h | 7 ++- > > Also, please drop this change to tools/, see > > https://lkml.kernel.org/r/20200622141737.ga30...@kernel.org > > from today. OK I reverted it [*]. > With those addressed: > > Reviewed-by: Borislav Petkov Thank you, I'll update this to the commit. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette [*] By "git diff -R HEAD~1 -- tools/arch/x86/include/asm/cpufeatures.h | patch -p1". /Jarkko
Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Switch SPI to use GPIO for CS
Quoting Douglas Anderson (2020-06-24 17:08:04)
> The geni SPI protocol appears to have been designed without taking
> Linux needs into account. In all the normal flows it takes care of
> setting chip select itself. However, Linux likes to manage the chip
> select so it can do fancy things.
>
> Back when we first landed the geni SPI driver we worked around this
> by:
> - Always setting the FRAGMENTATION bit in transfers, which (I believe)
> tells the SPI controller not to mess with the chip select during
> transfers.
> - Controlling the chip select manually by sending the SPI controller
> commands to assert or deassert the chip select.
>
> Our workaround was fine and it's been working OK, but it's really
> quite inefficient. A normal SPI transaction now needs to do:
> 1. Start a command to set the chip select.
> 2. Wait for an interrupt from controller saying chip select done.
> 3. Do a transfer.
> 4. Start a command to unset the chip select.
> 5. Wait for an interrupt from controller saying chip select done.
I thought the GENI hardware was supposed to be able to queue commands up
and then plow through them to interrupt the CPU when it finished. If
that was supported would there be any problems? I assume we could remove
the wait for CS disable and interrupt on step 5 and also the wait for
CS/interrupt on step 2 because it is bundled with the transfer in step
3.
Where is the delay? On step 2 where we wait to transfer or at step 5
when we wait for CS to be dropped, or both?
>
> Things are made a bit worse because the Linux GPIO framework assumes
> that setting a chip select is quick. Thus the SPI core can be seen to
> tell us to set our chip select even when it's already in the right
> state and we were dutifully kicking off commands and waiting for
> interrupts. While we could optimize that particular case, we'd still
> be left with the slowness when we actually needed to toggle the chip
> select.
One thing to note is that the GPIO driver doesn't tell us that it has
actually asserted/deasserted the GPIO. It writes to the controller and
moves on so we don't know when it has actually gone into effect.
Hopefully moving to GPIO mode doesn't mean we get weird problems where
CS isn't asserted yet and a transfer starts wiggling the lines.
>
> All the chip select lines can actually be muxed to be GPIOs and
> there's really no downside in doing so. Now Linux can assert and
> deassert the chip select at will with a simple MMIO write.
>
> The SPI driver will still have the ability to set the chip select, but
> not we just won't use it.
s/not/now/?
>
> With this change I tested reading the firmware off the EC connected to
> a ChromeOS device (flashrom -p ec -r ...). I saw about a 25% speedup
> in total runtime of the command and a 30% reduction in interrupts
> generated (measured by /proc/interrupts).
I see nothing wrong with specifying the CS gpios in DT. Seems like that
should always be there and then the driver should decide to use GPIO
mode or not. So
Reviewed-by: Stephen Boyd
for that part.
>
> Signed-off-by: Douglas Anderson
> ---
>
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 57
> 1 file changed, 49 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 3a8076c8bdbf..74c8503b560e 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -1204,65 +1213,97 @@ pinmux {
> qup_spi0_default: qup-spi0-default {
> pinmux {
> pins = "gpio34", "gpio35",
> - "gpio36", "gpio37";
> + "gpio36";
> function = "qup00";
> };
> + pinmux-cs {
> + pins = "gpio37";
> + function = "gpio";
> + };
> };
>
> qup_spi1_default: qup-spi1-default {
> pinmux {
> pins = "gpio0", "gpio1",
> - "gpio2", "gpio3";
> + "gpio2";
> function = "qup01";
> };
> + pinmux-cs {
> + pins = "gpio3";
> + function = "gpio";
> + };
> };
>
> qup_spi3_default: qup-spi3-default {
> pinmux {
> pins = "gpio38", "gpio39",
> -
Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
Hi Nathan, On 6/23/20 8:59 PM, Nathan Chancellor wrote: > These are not true arrays, they are linker defined symbols, which are > just addresses. Using the address of operator silences the warning > and does not change the resulting assembly with either clang/ld.lld > or gcc/ld (tested with diff + objdump -Dr). Thanks for your patch. I tested this patch applied to v5.8-rc2 on a PS3 and it seems OK. Tested-by: Geoff Levand
[PATCH net 2/3] net: bcmgenet: use __be16 for htons(ETH_P_IP)
The 16-bit value that holds a short in network byte order should
be declared as a restricted big endian type to allow type checks
to succeed during assignment.
Fixes: 3e370952287c ("net: bcmgenet: add support for ethtool rxnfc flows")
Reported-by: kbuild test robot
Signed-off-by: Doug Berger
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index f1fa11665319..c63f01e2bb03 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -610,8 +610,9 @@ static int bcmgenet_hfb_create_rxnfc_filter(struct
bcmgenet_priv *priv,
{
struct ethtool_rx_flow_spec *fs = >fs;
int err = 0, offset = 0, f_length = 0;
- u16 val_16, mask_16;
u8 val_8, mask_8;
+ __be16 val_16;
+ u16 mask_16;
size_t size;
u32 *f_data;
--
2.7.4
Re: [PATCH v5 00/27] clk: bcm: rpi: Add support for BCM2711 firmware clocks
Quoting Maxime Ripard (2020-06-15 01:40:40) > Hi, > > Since the whole DRM/HDMI support began to grow fairly big, I've chosen > to split away the two discussions between the firmware clocks and the > HDMI support. > I see one problem. WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/bcm/clk-bcm2711-dvp.o Can you send a followup patch to fix this?
[PATCH net 1/3] net: bcmgenet: re-remove bcmgenet_hfb_add_filter
This function was originally removed by Baoyou Xie in
commit e2072600a241 ("net: bcmgenet: remove unused function in
bcmgenet.c") to prevent a build warning.
Some of the functions removed by Baoyou Xie are now used for
WAKE_FILTER support so his commit was reverted, but this function
is still unused and the kbuild test robot dutifully reported the
warning.
This commit once again removes the remaining unused hfb functions.
Fixes: 14da1510fedc ("Revert "net: bcmgenet: remove unused function in
bcmgenet.c"")
Reported-by: kbuild test robot
Signed-off-by: Doug Berger
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 77 --
1 file changed, 77 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index ff31da0ed846..f1fa11665319 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -459,17 +459,6 @@ static inline void bcmgenet_rdma_ring_writel(struct
bcmgenet_priv *priv,
genet_dma_ring_regs[r]);
}
-static bool bcmgenet_hfb_is_filter_enabled(struct bcmgenet_priv *priv,
- u32 f_index)
-{
- u32 offset;
- u32 reg;
-
- offset = HFB_FLT_ENABLE_V3PLUS + (f_index < 32) * sizeof(u32);
- reg = bcmgenet_hfb_reg_readl(priv, offset);
- return !!(reg & (1 << (f_index % 32)));
-}
-
static void bcmgenet_hfb_enable_filter(struct bcmgenet_priv *priv, u32 f_index)
{
u32 offset;
@@ -533,19 +522,6 @@ static void bcmgenet_hfb_set_filter_length(struct
bcmgenet_priv *priv,
bcmgenet_hfb_reg_writel(priv, reg, offset);
}
-static int bcmgenet_hfb_find_unused_filter(struct bcmgenet_priv *priv)
-{
- u32 f_index;
-
- /* First MAX_NUM_OF_FS_RULES are reserved for Rx NFC filters */
- for (f_index = MAX_NUM_OF_FS_RULES;
-f_index < priv->hw_params->hfb_filter_cnt; f_index++)
- if (!bcmgenet_hfb_is_filter_enabled(priv, f_index))
- return f_index;
-
- return -ENOMEM;
-}
-
static int bcmgenet_hfb_validate_mask(void *mask, size_t size)
{
while (size) {
@@ -744,59 +720,6 @@ static int bcmgenet_hfb_create_rxnfc_filter(struct
bcmgenet_priv *priv,
return err;
}
-/* bcmgenet_hfb_add_filter
- *
- * Add new filter to Hardware Filter Block to match and direct Rx traffic to
- * desired Rx queue.
- *
- * f_data is an array of unsigned 32-bit integers where each 32-bit integer
- * provides filter data for 2 bytes (4 nibbles) of Rx frame:
- *
- * bits 31:20 - unused
- * bit 19- nibble 0 match enable
- * bit 18- nibble 1 match enable
- * bit 17- nibble 2 match enable
- * bit 16- nibble 3 match enable
- * bits 15:12 - nibble 0 data
- * bits 11:8 - nibble 1 data
- * bits 7:4 - nibble 2 data
- * bits 3:0 - nibble 3 data
- *
- * Example:
- * In order to match:
- * - Ethernet frame type = 0x0800 (IP)
- * - IP version field = 4
- * - IP protocol field = 0x11 (UDP)
- *
- * The following filter is needed:
- * u32 hfb_filter_ipv4_udp[] = {
- * Rx frame offset 0x00: 0x, 0x, 0x, 0x,
- * Rx frame offset 0x08: 0x, 0x, 0x000F0800, 0x00084000,
- * Rx frame offset 0x10: 0x, 0x, 0x, 0x00030011,
- * };
- *
- * To add the filter to HFB and direct the traffic to Rx queue 0, call:
- * bcmgenet_hfb_add_filter(priv, hfb_filter_ipv4_udp,
- * ARRAY_SIZE(hfb_filter_ipv4_udp), 0);
- */
-int bcmgenet_hfb_add_filter(struct bcmgenet_priv *priv, u32 *f_data,
- u32 f_length, u32 rx_queue)
-{
- int f_index;
-
- f_index = bcmgenet_hfb_find_unused_filter(priv);
- if (f_index < 0)
- return -ENOMEM;
-
- if (f_length > priv->hw_params->hfb_filter_size)
- return -EINVAL;
-
- bcmgenet_hfb_set_filter(priv, f_data, f_length, rx_queue, f_index);
- bcmgenet_hfb_enable_filter(priv, f_index);
-
- return 0;
-}
-
/* bcmgenet_hfb_clear
*
* Clear Hardware Filter Block and disable all filtering.
--
2.7.4
[PATCH net 3/3] net: bcmgenet: use hardware padding of runt frames
When commit 474ea9cafc45 ("net: bcmgenet: correctly pad short
packets") added the call to skb_padto() it should have been
located before the nr_frags parameter was read since that value
could be changed when padding packets with lengths between 55
and 59 bytes (inclusive).
The use of a stale nr_frags value can cause corruption of the
pad data when tx-scatter-gather is enabled. This corruption of
the pad can cause invalid checksum computation when hardware
offload of tx-checksum is also enabled.
Since the original reason for the padding was corrected by
commit 7dd399130efb ("net: bcmgenet: fix skb_len in
bcmgenet_xmit_single()") we can remove the software padding all
together and make use of hardware padding of short frames as
long as the hardware also always appends the FCS value to the
frame.
Fixes: 474ea9cafc45 ("net: bcmgenet: correctly pad short packets")
Signed-off-by: Doug Berger
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index c63f01e2bb03..af924a8b885f 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2042,11 +2042,6 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff *skb,
struct net_device *dev)
goto out;
}
- if (skb_padto(skb, ETH_ZLEN)) {
- ret = NETDEV_TX_OK;
- goto out;
- }
-
/* Retain how many bytes will be sent on the wire, without TSB inserted
* by transmit checksum offload
*/
@@ -2093,6 +2088,9 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff *skb,
struct net_device *dev)
len_stat = (size << DMA_BUFLENGTH_SHIFT) |
(priv->hw_params->qtag_mask << DMA_TX_QTAG_SHIFT);
+ /* Note: if we ever change from DMA_TX_APPEND_CRC below we
+* will need to restore software padding of "runt" packets
+*/
if (!i) {
len_stat |= DMA_TX_APPEND_CRC | DMA_SOP;
if (skb->ip_summed == CHECKSUM_PARTIAL)
--
2.7.4
[PATCH net 0/3] net: bcmgenet: use hardware padding of runt frames
Now that scatter-gather and tx-checksumming are enabled by default it revealed a packet corruption issue that can occur for very short fragmented packets. When padding these frames to the minimum length it is possible for the non-linear (fragment) data to be added to the end of the linear header in an SKB. Since the number of fragments is read before the padding and used afterward without reloading, the fragment that should have been consumed can be tacked on in place of part of the padding. The third commit in this set corrects this by removing the software padding and allowing the hardware to add the pad bytes if necessary. The first two commits resolve warnings observed by the kbuild test robot and are included here for simplicity of application. Doug Berger (3): net: bcmgenet: re-remove bcmgenet_hfb_add_filter net: bcmgenet: use __be16 for htons(ETH_P_IP) net: bcmgenet: use hardware padding of runt frames drivers/net/ethernet/broadcom/genet/bcmgenet.c | 88 ++ 1 file changed, 5 insertions(+), 83 deletions(-) -- 2.7.4
Re: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option
On Wed, Jun 24, 2020 at 9:57 PM Jason Gunthorpe wrote:
>
> On Wed, Jun 24, 2020 at 04:45:24PM +0800, Nicolas Boichat wrote:
> > trace_printk is only meant as a debugging tool, and should never be
> > compiled into production code without source code changes, as
> > indicated by the warning that shows up on boot if any trace_printk
> > is called:
> > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
> > ** **
> > ** trace_printk() being used. Allocating extra memory. **
> > ** **
> > ** This means that this is a DEBUG kernel and it is **
> > ** unsafe for production use. **
> >
> > If this option is set to n, the kernel will generate a build-time
> > error if trace_printk is used.
> >
> > Signed-off-by: Nicolas Boichat
> > include/linux/kernel.h | 17 -
> > kernel/trace/Kconfig | 9 +
> > 2 files changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > index 196607aaf653082..b6addc6ba669e85 100644
> > +++ b/include/linux/kernel.h
> > @@ -721,10 +721,15 @@ do {
> > \
> > #define trace_printk(fmt, ...) \
> > do { \
> > char ___STR[] = __stringify((__VA_ARGS__)); \
> > + \
> > + __static_assert(\
> > + IS_ENABLED(CONFIG_TRACING_ALLOW_PRINTK),\
> > + "trace_printk called, please enable
> > CONFIG_TRACING_ALLOW_PRINTK."); \
> > + \
>
> Why __static_assert not normal static_assert?
Oh, I misread the macro code (and didn't read the comment above in
include/linux/build_bug.h). static_assert would be just fine.
>
> Jason
Re: [v3] arm64: dts: sc7180: add nodes for idp display
Quoting Harigovindan P (2020-02-17 00:58:42)
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 388f50ad4fde..349db8fe78a5 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -232,6 +233,57 @@ vreg_bob: bob {
> };
> };
>
> + {
> + status = "okay";
> +
> + vdda-supply = <_l3c_1p2>;
> +
> + panel@0 {
> + compatible = "visionox,rm69299-1080p-display";
> + reg = <0>;
> +
> + vdda-supply = <_l8c_1p8>;
> + vdd3p3-supply = <_l18a_2p8>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + reset-gpios = <_gpio 3 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <_in>;
> + data-lanes = <0 1 2 3>;
Is this property needed? If it's the default assumption it would be nice
to omit it so that we don't have to think about it.
> + };
> + };
> + };
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> pinctrl-names = "default";
> @@ -289,6 +341,17 @@ _1_qmpphy {
>
> /* PINCTRL - additions to nodes defined in sc7180.dtsi */
>
> +_gpio {
> + disp_pins: disp-pins {
Curious how this works. It looks like PMIC GPIOS are expecting the node
to look like:
disp_pins: disp-pins {
pinconf {
pins = "gpio3";
function = PMIC_GPIO_FUNC_FUNC1;
qcom,drive-strength = ;
power-source = ;
bias-disable;
output-low;
};
but this doesn't use the macros or the subnode for pinconf. Why? Also,
the PM6150_GPIO_VPH macro doesn't exist.
> + pins = "gpio3";
> + function = "func1";
> + qcom,drive-strength = <2>;
> + power-source = <0>;
> + bias-disable;
> + output-low;
> + };
> +};
> +
[rcu:rcu/urgent 1/1] kernel/rcu/tree.c:253:8: error: implicit declaration of function 'arch_atomic_add_return'; did you mean
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
rcu/urgent
head: 239341154165cec3676955bab4cc1d61852257ed
commit: 239341154165cec3676955bab4cc1d61852257ed [1/1] rcu: Fixup noinstr
warnings
config: m68k-randconfig-r016-20200624 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 239341154165cec3676955bab4cc1d61852257ed
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
kernel/rcu/tree.c: In function 'rcu_dynticks_eqs_enter':
>> kernel/rcu/tree.c:253:8: error: implicit declaration of function
>> 'arch_atomic_add_return'; did you mean 'atomic_add_return'?
>> [-Werror=implicit-function-declaration]
253 | seq = arch_atomic_add_return(RCU_DYNTICK_CTRL_CTR, >dynticks);
|^~
|atomic_add_return
kernel/rcu/tree.c: In function 'rcu_dynticks_eqs_exit':
>> kernel/rcu/tree.c:283:3: error: implicit declaration of function
>> 'arch_atomic_andnot'; did you mean 'atomic_andnot'?
>> [-Werror=implicit-function-declaration]
283 | arch_atomic_andnot(RCU_DYNTICK_CTRL_MASK, >dynticks);
| ^~
| atomic_andnot
kernel/rcu/tree.c: In function 'rcu_dynticks_curr_cpu_in_eqs':
>> kernel/rcu/tree.c:316:11: error: implicit declaration of function
>> 'arch_atomic_read'; did you mean 'atomic_read'?
>> [-Werror=implicit-function-declaration]
316 | return !(arch_atomic_read(>dynticks) & RCU_DYNTICK_CTRL_CTR);
| ^~~~
| atomic_read
In file included from kernel/rcu/tree.c:4308:
kernel/rcu/tree_stall.h: In function 'check_slow_task':
kernel/rcu/tree_stall.h:240:19: warning: variable 'rnp' set but not used
[-Wunused-but-set-variable]
240 | struct rcu_node *rnp;
| ^~~
cc1: some warnings being treated as errors
vim +253 kernel/rcu/tree.c
235
236 /*
237 * Record entry into an extended quiescent state. This is only to be
238 * called when not already in an extended quiescent state, that is,
239 * RCU is watching prior to the call to this function and is no longer
240 * watching upon return.
241 */
242 static noinstr void rcu_dynticks_eqs_enter(void)
243 {
244 struct rcu_data *rdp = this_cpu_ptr(_data);
245 int seq;
246
247 /*
248 * CPUs seeing atomic_add_return() must see prior RCU read-side
249 * critical sections, and we also must force ordering with the
250 * next idle sojourn.
251 */
252 rcu_dynticks_task_trace_enter(); // Before ->dynticks update!
> 253 seq = arch_atomic_add_return(RCU_DYNTICK_CTRL_CTR,
> >dynticks);
254 // RCU is no longer watching. Better be in extended quiescent
state!
255 WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
256 (seq & RCU_DYNTICK_CTRL_CTR));
257 /* Better not have special action (TLB flush) pending! */
258 WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
259 (seq & RCU_DYNTICK_CTRL_MASK));
260 }
261
262 /*
263 * Record exit from an extended quiescent state. This is only to be
264 * called from an extended quiescent state, that is, RCU is not watching
265 * prior to the call to this function and is watching upon return.
266 */
267 static noinstr void rcu_dynticks_eqs_exit(void)
268 {
269 struct rcu_data *rdp = this_cpu_ptr(_data);
270 int seq;
271
272 /*
273 * CPUs seeing atomic_add_return() must see prior idle sojourns,
274 * and we also must force ordering with the next RCU read-side
275 * critical section.
276 */
277 seq = arch_atomic_add_return(RCU_DYNTICK_CTRL_CTR,
>dynticks);
278 // RCU is now watching. Better not be in an extended quiescent
state!
279 rcu_dynticks_task_trace_exit(); // After ->dynticks update!
280 WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
281 !(seq & RCU_DYNTICK_CTRL_CTR));
282 if (seq & RCU_DYNTICK_CTRL_MASK) {
> 283 arch_atomic_andnot(RCU_DYNTICK_CTRL_MASK,
> >dynticks);
284 smp_mb__after_atomic(); /* _exit after clearing mask. */
285 }
286
Re: [PATCH 3/3] x86/ptrace: Fix 32-bit PTRACE_SETREGS vs fsbase and gsbase
On Wed, Jun 24, 2020 at 3:50 PM Andy Lutomirski wrote:
>
> Debuggers expect that doing PTRACE_GETREGS, then poking at a tracee
> and maybe letting it run for a while, then doing PTRACE_SETREGS will
> put the tracee back where it was. In the specific case of a 32-bit
> tracer and tracee, the PTRACE_GETREGS/SETREGS data structure doesn't
> have fs_base or gs_base fields, so FSBASE and GSBASE fields are
> never stored anywhere. Everything used to still work because
> nonzero FS or GS would result full reloads of the segment registers
> when the tracee resumes, and the bases associated with FS==0 or
> GS==0 are irrelevant to 32-bit code.
>
> Adding FSGSBASE support broke this: when FSGSBASE is enabled, FSBASE
> and GSBASE are now restored independently of FS and GS for all tasks
> when context-switched in. This means that, if a 32-bit tracer
> restores a previous state using PTRACE_SETREGS but the tracee's
> pre-restore and post-restore bases don't match, then the tracee is
> resumed with the wrong base.
>
> Fix it by explicitly loading the base when a 32-bit tracer pokes FS
> or GS on a 64-bit kernel.
> diff --git a/tools/testing/selftests/x86/fsgsbase_restore.c
> b/tools/testing/selftests/x86/fsgsbase_restore.c
> new file mode 100644
> index ..70502a708dee
> --- /dev/null
> +++ b/tools/testing/selftests/x86/fsgsbase_restore.c
> + if (false && syscall(SYS_modify_ldt, 1, , sizeof(desc)) == 0) {
Whoops. That 'false &&' shouldn't be there. Want a v2?
Re: [GIT PULL] erofs fixes for 5.8-rc3
The pull request you sent on Thu, 25 Jun 2020 05:08:53 +0800: > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git > tags/erofs-for-5.8-rc3-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8be3a53e18e0e1a98f288f6c7f5e9da3adbe9c49 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] virtio: fixes, tests
The pull request you sent on Wed, 24 Jun 2020 05:08:01 -0400: > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fc10807db5ced090d83cec167e87c95a47452d24 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[RESEND PATCH v10] dt-bindings: ufs: Add bindings for Samsung ufs host
This patch adds DT bindings for Samsung ufs hci
Reviewed-by: Rob Herring
Signed-off-by: Alim Akhtar
---
Hi Rob
This is just a rebase on your's dt/next
This patch was part of [1]
[1] https://lkml.org/lkml/2020/5/27/1697
.../bindings/ufs/samsung,exynos-ufs.yaml | 89 +++
1 file changed, 89 insertions(+)
create mode 100644
Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
new file mode 100644
index ..38193975c9f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ufs/samsung,exynos-ufs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC series UFS host controller Device Tree Bindings
+
+maintainers:
+ - Alim Akhtar
+
+description: |
+ Each Samsung UFS host controller instance should have its own node.
+ This binding define Samsung specific binding other then what is used
+ in the common ufshcd bindings
+ [1] Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+
+properties:
+
+ compatible:
+enum:
+ - samsung,exynos7-ufs
+
+ reg:
+items:
+ - description: HCI register
+ - description: vendor specific register
+ - description: unipro register
+ - description: UFS protector register
+
+ reg-names:
+items:
+ - const: hci
+ - const: vs_hci
+ - const: unipro
+ - const: ufsp
+
+ clocks:
+items:
+ - description: ufs link core clock
+ - description: unipro main clock
+
+ clock-names:
+items:
+ - const: core_clk
+ - const: sclk_unipro_main
+
+ interrupts:
+maxItems: 1
+
+ phys:
+maxItems: 1
+
+ phy-names:
+const: ufs-phy
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - phys
+ - phy-names
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+ufs: ufs@1557 {
+ compatible = "samsung,exynos7-ufs";
+ reg = <0x1557 0x100>,
+ <0x15570100 0x100>,
+ <0x15571000 0x200>,
+ <0x15572000 0x300>;
+ reg-names = "hci", "vs_hci", "unipro", "ufsp";
+ interrupts = ;
+ clocks = <_fsys1 ACLK_UFS20_LINK>,
+<_fsys1 SCLK_UFSUNIPRO20_USER>;
+ clock-names = "core_clk", "sclk_unipro_main";
+ pinctrl-names = "default";
+ pinctrl-0 = <_rst_n _refclk_out>;
+ phys = <_phy>;
+ phy-names = "ufs-phy";
+};
+...
base-commit: b3a9e3b9622ae10064826dccb4f7a52bd88c7407
prerequisite-patch-id: e0425bbe8f2aff3882b728a0caf0218b6b3e9b6e
prerequisite-patch-id: c8c8502c512f9d6fdaf7d30e54dde3e68c3d855b
prerequisite-patch-id: 8505df2fd70632150b50543cadc6fd7dd42d191c
prerequisite-patch-id: 1a9701ab83425940c8aacb76737edb57ab815e47
prerequisite-patch-id: 7881e0b87f1f04f657d9e6d450fb5231ad6ffa1a
prerequisite-patch-id: 01dbc0e550e3fcad6e525e7e3183f9f0312e8496
prerequisite-patch-id: ad801812fff960abab3f27d2c7383be9fd9aa439
prerequisite-patch-id: 65474c9540e6dc749d30223897de1f486d6b3843
prerequisite-patch-id: 64b58cd4c5ecfacf28fc20c31a6617092a1e1931
prerequisite-patch-id: 9bcdd2995fd3f6361f8d5e89c56645058ac9ff96
--
2.17.1
Re: [PATCH v5 27/27] clk: bcm: rpi: Remove the quirks for the CPU clock
Quoting Maxime Ripard (2020-06-15 01:41:07) > The CPU clock has had so far a bunch of quirks to expose the clock tree > properly, but since we reverted to exposing them through the MMIO driver, > we can remove that code from the firmware driver. > > Acked-by: Nicolas Saenz Julienne > Tested-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Applied to clk-next
Re: [PATCH v5 25/27] clk: bcm2835: Allow custom CCF flags for the PLLs
Quoting Maxime Ripard (2020-06-15 01:41:05) > While some clock types allow for each clock to specify its own custom > flags, the PLLs can't. We will need this for the PLLB, so let's add it. > > Acked-by: Nicolas Saenz Julienne > Tested-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Applied to clk-next
Re: [PATCH v5 26/27] clk: bcm2835: Don't cache the PLLB rate
Quoting Maxime Ripard (2020-06-15 01:41:06) > The PLLB rate will be changed through the firmware clocks drivers and will > change behind this drivers' back, so we don't want to cache the rate. > > Acked-by: Nicolas Saenz Julienne > Tested-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Applied to clk-next
Re: [PATCH v5 18/27] clk: bcm: rpi: Make the PLLB registration function return a clk_hw
Quoting Maxime Ripard (2020-06-15 01:40:58) > The raspberrypi_register_pllb has been returning an integer so far to > notify whether the functions has exited successfully or not. > > However, the OF provider functions in the clock framework require access to > the clk_hw structure so that we can expose those clocks to device tree > consumers. > > Since we'll want that for the future clocks, let's return a clk_hw pointer > instead of the return code. > > Cc: Michael Turquette > Cc: linux-...@vger.kernel.org > Acked-by: Nicolas Saenz Julienne > Reviewed-by: Stephen Boyd > Tested-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Applied to clk-next
Re: [PATCH v5 22/27] clk: bcm: rpi: Give firmware clocks a name
Quoting Maxime Ripard (2020-06-15 01:41:02) > We've registered the firmware clocks using their ID as name, but it's much > more convenient to register them using their proper name. Since the > firmware doesn't provide it, we have to duplicate it. > > Acked-by: Nicolas Saenz Julienne > Tested-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Applied to clk-next
Re: [PATCH v5 20/27] clk: bcm: rpi: Add an enum for the firmware clocks
Quoting Maxime Ripard (2020-06-15 01:41:00) > While the firmware allows us to discover the available clocks, we need to > discriminate those clocks to only register the ones meaningful to Linux. > The firmware also doesn't provide a clock name, so having a list of the ID > will help us to give clocks a proper name later on. > > Acked-by: Nicolas Saenz Julienne > Tested-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Applied to clk-next
Re: [PATCH v5 23/27] Revert "clk: bcm2835: remove pllb"
Quoting Maxime Ripard (2020-06-15 01:41:03) > This reverts commit 2256d89333bd17b8b56b42734a7e1046d52f7fc3. Since we > will be expanding the firmware clock driver, we'll need to remove the > quirks to deal with the PLLB. However, we still want to expose the clock > tree properly, so having that clock in the MMIO driver will allow that. > > Acked-by: Nicolas Saenz Julienne > Tested-by: Nicolas Saenz Julienne > Signed-off-by: Maxime Ripard > --- Applied to clk-next
