Re: [PATCH v6 2/2] dt-bindings: mtd: Document Macronix raw NAND controller bindings
On Thu, 1 Aug 2019 11:55:10 +0800
Mason Yang wrote:
> Document the bindings used by the Macronix raw NAND controller.
>
> Signed-off-by: Mason Yang
> ---
> Documentation/devicetree/bindings/mtd/mxic-nand.txt | 19 +++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/mxic-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/mxic-nand.txt
> b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
> new file mode 100644
> index 000..de37d60
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
> @@ -0,0 +1,19 @@
> +Macronix Raw NAND Controller Device Tree Bindings
> +-
> +
> +Required properties:
> +- compatible: should be "mxicy,multi-itfc-v009-nand-morph"
> +- reg: should contain 1 entry for the registers
> +- interrupts: interrupt line connected to this raw NAND controller
> +- clock-names: should contain "ps", "send" and "send_dly"
> +- clocks: should contain 3 phandles for the "ps", "send" and
> + "send_dly" clocks
> +
> +Example:
> +
> + nand: nand-controller@43c3 {
> + compatible = "mxicy,multi-itfc-v009-nand-morph";
> + reg = <0x43c3 0x1>;
> + clocks = < 0>, < 1>, < 15>;
> + clock-names = "send", "send_dly", "ps";
You should have subnodes describing the NAND connected to the
controller (see [1]).
[1]https://elixir.bootlin.com/linux/v5.3-rc2/source/Documentation/devicetree/bindings/mtd/nand-controller.yaml#L131
> + };
Re: linux-next: build warning after merge of the akpm-current tree
Hi Miles, On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen wrote: > > On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote: > > > > After merging the akpm-current tree, today's linux-next build (powerpc > > ppc64_defconfig) produced this warning: > > > > mm/memcontrol.c: In function 'invalidate_reclaim_iterators': > > mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment > > used as truth value [-Wparentheses] > > } while (memcg = parent_mem_cgroup(memcg)); > >^ > > > > Hi Stephen, > > Thanks for the telling me this. Sorry for the build warning. > Should I send patch v5 to the mailing list to fix this? You might as well (cc'ing Andrew, of course). I would suggest finishing that loop like this: memcg = parent_mem_cgroup(memcg); } while (memcg); rather than adding a set of parentheses. -- Cheers, Stephen Rothwell pgps4vx1GblfD.pgp Description: OpenPGP digital signature
Re: [PATCH v3 2/3] mtd: spi-nor: Move m25p80 code in spi-nor.c
On Thu, 1 Aug 2019 10:00:51 +0530
Vignesh Raghavendra wrote:
> From: Boris Brezillon
>
> The m25p80 driver is actually a generic wrapper around the spi-mem
> layer. Not only the driver name is misleading, but we'd expect such a
> common logic to be directly available in the core. Another reason for
> moving this code is that SPI NOR controller drivers should
> progressively be replaced by SPI controller drivers implementing the
> spi_mem_ops interface, and when the conversion is done, we should have
> a single spi-nor driver directly interfacing with the spi-mem layer.
>
> While moving the code we also fix a longstanding issue when
> non-DMA-able buffers are passed by the MTD layer.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Vignesh Raghavendra
> ---
> v3:
> Simplify register read/write by dropping spi_nor_exec_op() and using
> spi_mem_exec_op() directly
> Modify spi_nor_spimem_xfer_data() to drop "enum spi_nor_protocol proto"
> Fix misc coding style comments by Tudor
>
> v2:
> Add docs for new functions added
> Add spi_nor_ prefix to new functions
> Incorporate Andrey's patches https://lkml.org/lkml/2019/4/1/32
> to avoid looping spi_nor_spimem_* APIs
>
> drivers/mtd/devices/Kconfig | 18 -
> drivers/mtd/devices/Makefile | 1 -
> drivers/mtd/devices/m25p80.c | 347 ---
> drivers/mtd/spi-nor/Kconfig | 2 +
> drivers/mtd/spi-nor/spi-nor.c | 632 --
> include/linux/mtd/spi-nor.h | 3 +
> 6 files changed, 604 insertions(+), 399 deletions(-)
> delete mode 100644 drivers/mtd/devices/m25p80.c
>
[...]
> @@ -348,6 +530,16 @@ static int read_cr(struct spi_nor *nor)
> */
> static int write_sr(struct spi_nor *nor, u8 val)
> {
> + if (nor->spimem) {
> + struct spi_mem_op op =
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRSR, 1),
> +SPI_MEM_OP_NO_ADDR,
> +SPI_MEM_OP_NO_DUMMY,
> +SPI_MEM_OP_DATA_IN(1, nor->bouncebuf, 1));
> +
> + return spi_mem_exec_op(nor->spimem, );
> + }
> +
> nor->bouncebuf[0] = val;
The above line should be moved at the beginning of the function if you
want the spimem path to work correctly.
> return nor->write_reg(nor, SPINOR_OP_WRSR, nor->bouncebuf, 1);
> }
Re: [PATCH] fork: Improve error message for corrupted page tables
On 07/31/2019 03:48 AM, Sai Praneeth Prakhya wrote:
> When a user process exits, the kernel cleans up the mm_struct of the user
> process and during cleanup, check_mm() checks the page tables of the user
> process for corruption (E.g: unexpected page flags set/cleared). For
> corrupted page tables, the error message printed by check_mm() isn't very
> clear as it prints the loop index instead of page table type (E.g: Resident
> file mapping pages vs Resident shared memory pages). Hence, improve the
> error message so that it's more informative.
The loop index in check_mm() also happens to be the index in rss_stat[] which
represents individual memory type stats. But you are right, index value here
in the print does not make any sense.
>
> Without patch:
> --
> [ 204.836425] mm/pgtable-generic.c:29: bad p4d
> 89eb4e92(80025f941467)
> [ 204.836544] BUG: Bad rss-counter state mm:f75895ea idx:0 val:2
> [ 204.836615] BUG: Bad rss-counter state mm:f75895ea idx:1 val:5
> [ 204.836685] BUG: non-zero pgtables_bytes on freeing mm: 20480
>
> With patch:
> ---
> [ 69.815453] mm/pgtable-generic.c:29: bad p4d
> 84653642(80025ca37467)
> [ 69.815872] BUG: Bad rss-counter state mm:014a6c03
> type:MM_FILEPAGES val:2
> [ 69.815962] BUG: Bad rss-counter state mm:014a6c03
> type:MM_ANONPAGES val:5
> [ 69.816050] BUG: non-zero pgtables_bytes on freeing mm: 20480
Yes, this is definitely better.
>
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Andrew Morton
> Suggested-by/Acked-by: Dave Hansen
Though I am not sure, should the above be two separate lines instead ?
> Signed-off-by: Sai Praneeth Prakhya
> ---
> include/linux/mm_types_task.h | 7 +++
> kernel/fork.c | 4 ++--
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_task.h
> index d7016dcb245e..881f4ea3a1b5 100644
> --- a/include/linux/mm_types_task.h
> +++ b/include/linux/mm_types_task.h
> @@ -44,6 +44,13 @@ enum {
> NR_MM_COUNTERS
> };
>
> +static const char * const resident_page_types[NR_MM_COUNTERS] = {
> + "MM_FILEPAGES",
> + "MM_ANONPAGES",
> + "MM_SWAPENTS",
> + "MM_SHMEMPAGES",
> +};
Should index them to match respective typo macros.
[MM_FILEPAGES] = "MM_FILEPAGES",
[MM_ANONPAGES] = "MM_ANONPAGES",
[MM_SWAPENTS] = "MM_SWAPENTS",
[MM_SHMEMPAGES] = "MM_SHMEMPAGES",
> +
> #if USE_SPLIT_PTE_PTLOCKS && defined(CONFIG_MMU)
> #define SPLIT_RSS_COUNTING
> /* per-thread cached information, */
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 2852d0e76ea3..6aef5842d4e0 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -649,8 +649,8 @@ static void check_mm(struct mm_struct *mm)
> long x = atomic_long_read(>rss_stat.count[i]);
>
> if (unlikely(x))
> - printk(KERN_ALERT "BUG: Bad rss-counter state "
> - "mm:%p idx:%d val:%ld\n", mm, i, x);
> + pr_alert("BUG: Bad rss-counter state mm:%p type:%s
> val:%ld\n",
> + mm, resident_page_types[i], x);
It changes the print function as well, though very minor change but perhaps
mention that in the commit message ?
Re: [PATCH v3 1/3] mtd: spi-nor: always use bounce buffer for register read/writes
On Thu, 1 Aug 2019 10:00:50 +0530
Vignesh Raghavendra wrote:
> spi-mem layer expects all buffers passed to it to be DMA'able. But
> spi-nor layer mostly allocates buffers on stack for reading/writing to
> registers and therefore are not DMA'able. Introduce bounce buffer to be
> used to read/write to registers. This ensures that buffer passed to
> spi-mem layer during register read/writes is DMA'able. With this change
> nor->cmd-buf is no longer used, so drop it.
>
> Signed-off-by: Vignesh Raghavendra
> ---
> v3: new patch
>
> drivers/mtd/spi-nor/spi-nor.c | 71 ---
> include/linux/mtd/spi-nor.h | 7 +++-
> 2 files changed, 46 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 03cc788511d5..8685e4ab6a25 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -296,15 +296,14 @@ struct flash_info {
> static int read_sr(struct spi_nor *nor)
> {
> int ret;
> - u8 val;
>
> - ret = nor->read_reg(nor, SPINOR_OP_RDSR, , 1);
> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, nor->bouncebuf, 1);
> if (ret < 0) {
> pr_err("error %d reading SR\n", (int) ret);
> return ret;
> }
>
> - return val;
> + return nor->bouncebuf[0];
> }
>
> /*
> @@ -315,15 +314,14 @@ static int read_sr(struct spi_nor *nor)
> static int read_fsr(struct spi_nor *nor)
> {
> int ret;
> - u8 val;
>
> - ret = nor->read_reg(nor, SPINOR_OP_RDFSR, , 1);
> + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, nor->bouncebuf, 1);
> if (ret < 0) {
> pr_err("error %d reading FSR\n", ret);
> return ret;
> }
>
> - return val;
> + return nor->bouncebuf[0];
> }
>
> /*
> @@ -334,15 +332,14 @@ static int read_fsr(struct spi_nor *nor)
> static int read_cr(struct spi_nor *nor)
> {
> int ret;
> - u8 val;
>
> - ret = nor->read_reg(nor, SPINOR_OP_RDCR, , 1);
> + ret = nor->read_reg(nor, SPINOR_OP_RDCR, nor->bouncebuf, 1);
> if (ret < 0) {
> dev_err(nor->dev, "error %d reading CR\n", ret);
> return ret;
> }
>
> - return val;
> + return nor->bouncebuf[0];
> }
>
> /*
> @@ -351,8 +348,8 @@ static int read_cr(struct spi_nor *nor)
> */
> static int write_sr(struct spi_nor *nor, u8 val)
> {
> - nor->cmd_buf[0] = val;
> - return nor->write_reg(nor, SPINOR_OP_WRSR, nor->cmd_buf, 1);
> + nor->bouncebuf[0] = val;
> + return nor->write_reg(nor, SPINOR_OP_WRSR, nor->bouncebuf, 1);
> }
>
> /*
> @@ -500,31 +497,31 @@ static int set_4byte(struct spi_nor *nor, bool enable)
>* We must clear the register to enable normal behavior.
>*/
> write_enable(nor);
> - nor->cmd_buf[0] = 0;
> - nor->write_reg(nor, SPINOR_OP_WREAR, nor->cmd_buf, 1);
> + nor->bouncebuf[0] = 0;
> + nor->write_reg(nor, SPINOR_OP_WREAR,
> +nor->bouncebuf, 1);
> write_disable(nor);
> }
>
> return status;
> default:
> /* Spansion style */
> - nor->cmd_buf[0] = enable << 7;
> - return nor->write_reg(nor, SPINOR_OP_BRWR, nor->cmd_buf, 1);
> + nor->bouncebuf[0] = enable << 7;
> + return nor->write_reg(nor, SPINOR_OP_BRWR, nor->bouncebuf, 1);
> }
> }
>
> static int s3an_sr_ready(struct spi_nor *nor)
> {
> int ret;
> - u8 val;
>
> - ret = nor->read_reg(nor, SPINOR_OP_XRDSR, , 1);
> + ret = nor->read_reg(nor, SPINOR_OP_XRDSR, nor->bouncebuf, 1);
> if (ret < 0) {
> dev_err(nor->dev, "error %d reading XRDSR\n", (int) ret);
> return ret;
> }
>
> - return !!(val & XSR_RDY);
> + return !!(nor->bouncebuf[0] & XSR_RDY);
> }
>
> static int spi_nor_sr_ready(struct spi_nor *nor)
> @@ -683,7 +680,6 @@ static loff_t spi_nor_s3an_addr_convert(struct spi_nor
> *nor, unsigned int addr)
> */
> static int spi_nor_erase_sector(struct spi_nor *nor, u32 addr)
> {
> - u8 buf[SPI_NOR_MAX_ADDR_WIDTH];
> int i;
>
> if (nor->flags & SNOR_F_S3AN_ADDR_DEFAULT)
> @@ -697,11 +693,12 @@ static int spi_nor_erase_sector(struct spi_nor *nor,
> u32 addr)
>* control
>*/
> for (i = nor->addr_width - 1; i >= 0; i--) {
> - buf[i] = addr & 0xff;
> + nor->bouncebuf[i] = addr & 0xff;
> addr >>= 8;
> }
>
> - return nor->write_reg(nor, nor->erase_opcode, buf, nor->addr_width);
> + return nor->write_reg(nor, nor->erase_opcode, nor->bouncebuf,
> + nor->addr_width);
> }
>
> /**
> @@ -1404,9 +1401,11 @@ static int write_sr_cr(struct spi_nor *nor, u8 *sr_cr)
> {
> int ret;
>
> +
Re: [PATCH 0/3] ARM: dts: aspeed: Deprecate g[45]-style compatibles
On Tue, 30 Jul 2019, at 10:27, Andrew Jeffery wrote: > > > On Tue, 30 Jul 2019, at 07:23, Linus Walleij wrote: > > On Wed, Jul 24, 2019 at 10:13 AM Andrew Jeffery wrote: > > > > > It's probably best if we push the three patches all through one tree > > > rather > > > than fragmenting. Is everyone happy if Joel applies them to the aspeed > > > tree? > > > > If you are sure it will not collide with parallell work in the > > pinctrl tree, yes. > > Acked-by: Linus Walleij > > > > (If it does collide I'd prefer to take the pinctrl patches and fix the > > conflicts in my tree.) > > Fair enough, I don't know the answer so I'll poke around. I don't > really mind > where the series goes in, I just want to avoid landing only part of it > if I split it up. Okay, it currently conflicts with my cleanup-devicetree-warnings series. Joel, do you mind if Linus takes this series through the pinctrl tree, given the fix to the devicetrees is patch 1/3? Andrew
Re: [PATCH 7/9] media: hantro: Add core bits to support H264 decoding
On Thu, 1 Aug 2019 13:06:10 +0900 Tomasz Figa wrote: > Hi Boris, > > On Wed, Jun 19, 2019 at 9:15 PM Boris Brezillon > wrote: > [snip] > > @@ -533,10 +535,21 @@ hantro_queue_setup(struct vb2_queue *vq, unsigned int > > *num_buffers, > > return -EINVAL; > > } > > > > + /* The H264 decoder needs extra size on the output buffer. */ > > + if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE_RAW) > > + extra_size0 = 128 * DIV_ROUND_UP(pixfmt->width, 16) * > > + DIV_ROUND_UP(pixfmt->height, 16); > > + > > I wonder if this shouldn't be accounted for already in the sizeimage > returned by TRY_/S_FMT, so that the application can know the required > buffer size if it uses some external allocator and DMABUF memory type. > I know we had it like this in our downstream code, but it wasn't the > problem because we use minigbm, where we explicitly add the same > padding in the rockchip backend. Any thoughts? Actually, I was wondering why it was not counted in ->sizeimage. I thought you had a good reason to not expose the extra size to userspace so I kept it like that.
Re: [PATCH v7 11/20] cpufreq: tegra124: Add suspend and resume support
On 31-07-19, 14:10, Sowjanya Komatineni wrote: > This patch adds suspend and resume pm ops for cpufreq driver. > > PLLP is the safe clock source for CPU during system suspend and > resume as PLLP rate is below the CPU Fmax at Vmin. > > CPUFreq driver suspend switches the CPU clock source to PLLP and > disables the DFLL clock. > > During system resume, warmboot code powers up the CPU with PLLP > clock source. So CPUFreq driver resume enabled DFLL clock and > switches CPU back to DFLL clock source. > > Signed-off-by: Sowjanya Komatineni > --- > drivers/cpufreq/tegra124-cpufreq.c | 60 > ++ > 1 file changed, 60 insertions(+) Is there any hard dependency of this patch on the rest of the patches? Can I apply it alone to cpufreq tree ? -- viresh
Re: [PATCHv5 25/37] x86/vdso: Switch image on setns()/clone()
On Mon, Jul 29, 2019 at 2:58 PM Dmitry Safonov wrote:
>
> As it has been discussed on timens RFC, adding a new conditional branch
> `if (inside_time_ns)` on VDSO for all processes is undesirable.
> It will add a penalty for everybody as branch predictor may mispredict
> the jump. Also there are instruction cache lines wasted on cmp/jmp.
>
> +#ifdef CONFIG_TIME_NS
> +int vdso_join_timens(struct task_struct *task)
> +{
> + struct mm_struct *mm = task->mm;
> + struct vm_area_struct *vma;
> +
> + if (down_write_killable(>mmap_sem))
> + return -EINTR;
> +
> + for (vma = mm->mmap; vma; vma = vma->vm_next) {
> + unsigned long size = vma->vm_end - vma->vm_start;
> +
> + if (vma_is_special_mapping(vma, _mapping) ||
> + vma_is_special_mapping(vma, _mapping))
> + zap_page_range(vma, vma->vm_start, size);
> + }
This is, unfortunately, fundamentally buggy. If any thread is in the
vDSO or has the vDSO on the stack (due to a signal, for example), this
will crash it. I can think of three solutions:
1. Say that you can't setns() if you have other mms and ignore the
signal issue. Anything with green threads will disapprove. It's also
rather gross.
2. Make it so that you can flip the static branch safely. As in my
other email, you'll need to deal with CoW somehow,
3. Make it so that you can't change timens, or at least that you can't
turn timens on or off, without execve() or fork().
BTW, that static branch probably needs to be aligned to a cache line
or something similar to avoid all the nastiness with trying to poke
text that might be concurrently executing. This will be a mess.
Re: [PATCH v3 3/4] arm64: Make debug exception handlers visible from RCU
Hi Will,
On Wed, 31 Jul 2019 18:26:03 +0100
Will Deacon wrote:
> On Thu, Jul 25, 2019 at 05:16:15PM +0900, Masami Hiramatsu wrote:
> > Make debug exceptions visible from RCU so that synchronize_rcu()
> > correctly track the debug exception handler.
> >
> > This also introduces sanity checks for user-mode exceptions as same
> > as x86's ist_enter()/ist_exit().
> >
> > The debug exception can interrupt in idle task. For example, it warns
> > if we put a kprobe on a function called from idle task as below.
> > The warning message showed that the rcu_read_lock() caused this
> > problem. But actually, this means the RCU is lost the context which
> > is already in NMI/IRQ.
> >
> > /sys/kernel/debug/tracing # echo p default_idle_call >> kprobe_events
> > /sys/kernel/debug/tracing # echo 1 > events/kprobes/enable
> > /sys/kernel/debug/tracing # [ 135.122237]
> > [ 135.125035] =
> > [ 135.125310] WARNING: suspicious RCU usage
> > [ 135.125581] 5.2.0-08445-g9187c508bdc7 #20 Not tainted
> > [ 135.125904] -
> > [ 135.126205] include/linux/rcupdate.h:594 rcu_read_lock() used
> > illegally while idle!
> > [ 135.126839]
> > [ 135.126839] other info that might help us debug this:
> > [ 135.126839]
> > [ 135.127410]
> > [ 135.127410] RCU used illegally from idle CPU!
> > [ 135.127410] rcu_scheduler_active = 2, debug_locks = 1
> > [ 135.128114] RCU used illegally from extended quiescent state!
> > [ 135.128555] 1 lock held by swapper/0/0:
> > [ 135.128944] #0: (ptrval) (rcu_read_lock){}, at:
> > call_break_hook+0x0/0x178
> > [ 135.130499]
> > [ 135.130499] stack backtrace:
> > [ 135.131192] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> > 5.2.0-08445-g9187c508bdc7 #20
> > [ 135.131841] Hardware name: linux,dummy-virt (DT)
> > [ 135.132224] Call trace:
> > [ 135.132491] dump_backtrace+0x0/0x140
> > [ 135.132806] show_stack+0x24/0x30
> > [ 135.133133] dump_stack+0xc4/0x10c
> > [ 135.133726] lockdep_rcu_suspicious+0xf8/0x108
> > [ 135.134171] call_break_hook+0x170/0x178
> > [ 135.134486] brk_handler+0x28/0x68
> > [ 135.134792] do_debug_exception+0x90/0x150
> > [ 135.135051] el1_dbg+0x18/0x8c
> > [ 135.135260] default_idle_call+0x0/0x44
> > [ 135.135516] cpu_startup_entry+0x2c/0x30
> > [ 135.135815] rest_init+0x1b0/0x280
> > [ 135.136044] arch_call_rest_init+0x14/0x1c
> > [ 135.136305] start_kernel+0x4d4/0x500
> > [ 135.136597]
> >
> > So make debug exception visible to RCU can fix this warning.
> >
> > Reported-by: Naresh Kamboju
> > Acked-by: Paul E. McKenney
> > Signed-off-by: Masami Hiramatsu
> > ---
> > Changes in v3:
> > - Make a comment for debug_exception_enter() clearer.
> > ---
> > arch/arm64/mm/fault.c | 40
> > 1 file changed, 40 insertions(+)
> >
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index 9568c116ac7f..ed6c55c87fdc 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -777,6 +777,42 @@ void __init hook_debug_fault_code(int nr,
> > debug_fault_info[nr].name = name;
> > }
> >
> > +/*
> > + * In debug exception context, we explicitly disable preemption.
>
> Maybe add "despite having interrupts disabled"?
OK, I'll add it.
> > + * This serves two purposes: it makes it much less likely that we would
> > + * accidentally schedule in exception context and it will force a warning
> > + * if we somehow manage to schedule by accident.
> > + */
> > +static void debug_exception_enter(struct pt_regs *regs)
> > +{
> > + if (user_mode(regs)) {
> > + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake
> > RCU");
> > + } else {
> > + /*
> > +* We might have interrupted pretty much anything. In
> > +* fact, if we're a debug exception, we can even interrupt
> > +* NMI processing. We don't want this code makes in_nmi()
> > +* to return true, but we need to notify RCU.
> > +*/
> > + rcu_nmi_enter();
> > + }
> > +
> > + preempt_disable();
>
> If you're addingt new functions for entry/exit, maybe move the
> trace_hardirqs_{on,off}() calls in here too?
OK, let's move it in these functions.
Thank you!
>
> Will
--
Masami Hiramatsu
Re: [linux-sunxi] Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality
Dne sreda, 31. julij 2019 ob 14:29:53 CEST je Maxime Ripard napisal(a):
> On Tue, Jul 30, 2019 at 07:57:10PM +0200, Jernej Škrabec wrote:
> > Dne torek, 04. junij 2019 ob 11:38:44 CEST je Code Kipper napisal(a):
> > > On Tue, 4 Jun 2019 at 11:02, Christopher Obbard
wrote:
> > > > On Tue, 4 Jun 2019 at 09:43, Code Kipper wrote:
> > > > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard
> > > > >
> >
> > wrote:
> > > > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekip...@gmail.com
wrote:
> > > > > > > From: Marcus Cooper
> > > > > > >
> > > > > > > The i2s block supports multi-lane i2s output however this
> > > > > > > functionality
> > > > > > > is only possible in earlier SoCs where the pins are exposed and
> > > > > > > for
> > > > > > > the i2s block used for HDMI audio on the later SoCs.
> > > > > > >
> > > > > > > To enable this functionality, an optional property has been
> > > > > > > added to
> > > > > > > the bindings.
> > > > > > >
> > > > > > > Signed-off-by: Marcus Cooper
> > > > > >
> > > > > > I'd like to have Mark's input on this, but I'm really worried
> > > > > > about
> > > > > > the interaction with the proper TDM support.
> > > > > >
> > > > > > Our fundamental issue is that the controller can have up to 8
> > > > > > channels, but either on 4 lines (instead of 1), or 8 channels on 1
> > > > > > (like proper TDM) (or any combination between the two, but that
> > > > > > should
> > > > > > be pretty rare).
> > > > >
> > > > > I understand...maybe the TDM needs to be extended to support this to
> > > > > consider channel mapping and multiple transfer lines. I was thinking
> > > > > about the later when someone was requesting support on IIRC a while
> > > > > ago, I thought masking might of been a solution. These can wait as
> > > > > the
> > > > > only consumer at the moment is LibreELEC and we can patch it there.
> > > >
> > > > Hi Marcus,
> > > >
> > > > FWIW, the TI McASP driver has support for TDM & (i think?) multiple
> > > > transfer lines which are called serializers.
> > > > Maybe this can help with inspiration?
> > > > see
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > > > e/s
> > > > ound/soc/ti/davinci-mcasp.c sample DTS:
> > > >
> > > > {
> > > >
> > > > #sound-dai-cells = <0>;
> > > > status = "okay";
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <_pins>;
> > > >
> > > > op-mode = <0>;
> > > > tdm-slots = <8>;
> > > > serial-dir = <
> > > >
> > > > 2 0 1 0
> > > > 0 0 0 0
> > > > 0 0 0 0
> > > > 0 0 0 0
> > > > >
> > > > >;
> > > >
> > > > tx-num-evt = <1>;
> > > > rx-num-evt = <1>;
> > > >
> > > > };
> > > >
> > > > Cheers!
> > >
> > > Thanks, this looks good.
> >
> > I would really like to see this issue resolved, because HDMI audio support
> > in mainline Linux for those SoCs is long overdue.
> >
> > However, there is a possibility to still add HDMI audio suport (stereo
> > only) even if this issue is not completely solved. If we agree that
> > configuration of channels would be solved with additional property as
> > Christopher suggested, support for >2 channels can be left for a later
> > time when support for that property would be implemented. Currently,
> > stereo HDMI audio support can be added with a few patches.
> >
> > I think all I2S cores are really the same, no matter if internally
> > connected to HDMI controller or routed to pins, so it would make sense to
> > use same compatible for all of them. It's just that those I2S cores which
> > are routed to pins can use only one lane and >2 channels can be used only
> > in TDM mode of operation, if I understand this correctly.
> >
> > New property would have to be optional, so it's omission would result in
> > same channel configuration as it is already present, to preserve
> > compatibility with old device trees. And this mode is already sufficient
> > for stereo HDMI audio support.
>
> Yeah, it looks like a good plan.
>
> > Side note: HDMI audio with current sun4i-i2s driver has a delay (about a
> > second), supposedly because DW HDMI controller automatically generates CTS
> > value based on I2S clock (auto CTS value generation is enabled per
> > DesignWare recomendation for DW HDMI I2S interface).
>
> Is that a constant delay during the audio playback, or only at startup?
I think it's just at startup, e.g. if you're watching movie, audio is in sync,
it's just that first second or so is silent.
>
> > I2S driver from BSP Linux solves that by having I2S clock output
> > enabled all the time. Should this be flagged with some additional
> > property in DT?
>
> I'd say that if the codec has that requirement, then it should be
> between the codec and the DAI, the DT doesn't really have anything to
> do with this.
Ok, but how to communicate that fact to I2S driver then? BSP driver solves
that by using different compatible, but as I said before, I2S cores
Re: [PATCHv5 01/37] ns: Introduce Time Namespace
On Mon, Jul 29, 2019 at 2:58 PM Dmitry Safonov wrote:
>
> From: Andrei Vagin
>
> Time Namespace isolates clock values.
> +static int timens_install(struct nsproxy *nsproxy, struct ns_common *new)
> +{
> + struct time_namespace *ns = to_time_ns(new);
> +
> + if (!thread_group_empty(current))
> + return -EINVAL;
You also need to check for other users of the mm.
> +
> + if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN) ||
> + !ns_capable(current_user_ns(), CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + get_time_ns(ns);
> + get_time_ns(ns);
> + put_time_ns(nsproxy->time_ns);
> + put_time_ns(nsproxy->time_ns_for_children);
> + nsproxy->time_ns = ns;
> + nsproxy->time_ns_for_children = ns;
> + ns->initialized = true;
I really really wish that setns() took an explicit flag for "change
now" or "change for children", since the semantics are different. Oh
well.
Re: [PATCHv5 21/37] x86/vdso: Restrict splitting VVAR VMA
On Mon, Jul 29, 2019 at 2:58 PM Dmitry Safonov wrote: > > Although, time namespace can work with VVAR VMA split, it seems worth > to forbid splitting VVAR resulting in stricter ABI and reducing amount > of corner-cases to consider while working further on VDSO. > > I don't think there is any use-case for partial mremap() of vvar, > but if there is any - this patch can be easily reverted. Seems reasonable to me.
Re: [PATCHv5 23/37] x86/vdso: Add offsets page in vvar
On Mon, Jul 29, 2019 at 2:58 PM Dmitry Safonov wrote:
>
> From: Andrei Vagin
>
> As modern applications fetch time from VDSO without entering the kernel,
> it's needed to provide offsets for userspace code inside time namespace.
>
> A page for timens offsets is allocated on time namespace construction.
> Put that page into VVAR for tasks inside timens and zero page for
> host processes.
>
> As VDSO code is already optimized as much as possible in terms of speed,
> any new if-condition in VDSO code is undesirable; the goal is to provide
> two .so(s), as was originally suggested by Andy and Thomas:
> - for host tasks with optimized-out clk_to_ns() without any penalty
> - for processes inside timens with clk_to_ns()
> For this purpose, define clk_to_ns() under CONFIG_TIME_NS.
>
> To eliminate any performance regression, clk_to_ns() will be called
> under static_branch with follow-up patches, that adds support for
> patching vdso.
>
> VDSO mappings are platform-specific, add Kconfig dependency for arch.
>
> Signed-off-by: Andrei Vagin
> Co-developed-by: Dmitry Safonov
> Signed-off-by: Dmitry Safonov
> ---
> arch/Kconfig | 5 +++
> arch/x86/Kconfig | 1 +
> arch/x86/entry/vdso/vdso-layout.lds.S | 9 -
> arch/x86/entry/vdso/vdso2c.c | 3 ++
> arch/x86/entry/vdso/vma.c | 12 +++
> arch/x86/include/asm/vdso.h | 1 +
> init/Kconfig | 1 +
> lib/vdso/gettimeofday.c | 47 +++
> 8 files changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index a7b57dd42c26..e43d27f510ec 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -729,6 +729,11 @@ config HAVE_ARCH_NVRAM_OPS
> config ISA_BUS_API
> def_bool ISA
>
> +config ARCH_HAS_VDSO_TIME_NS
> + bool
> + help
> +VDSO can add time-ns offsets without entering kernel.
> +
> #
> # ABI hall of shame
> #
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 222855cc0158..91615938b470 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -81,6 +81,7 @@ config X86
> select ARCH_HAS_STRICT_MODULE_RWX
> select ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
> select ARCH_HAS_UBSAN_SANITIZE_ALL
> + select ARCH_HAS_VDSO_TIME_NS
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
> select ARCH_MIGHT_HAVE_PC_PARPORT
> diff --git a/arch/x86/entry/vdso/vdso-layout.lds.S
> b/arch/x86/entry/vdso/vdso-layout.lds.S
> index 93c6dc7812d0..ba216527e59f 100644
> --- a/arch/x86/entry/vdso/vdso-layout.lds.S
> +++ b/arch/x86/entry/vdso/vdso-layout.lds.S
> @@ -7,6 +7,12 @@
> * This script controls its layout.
> */
>
> +#ifdef CONFIG_TIME_NS
> +# define TIMENS_SZ PAGE_SIZE
> +#else
> +# define TIMENS_SZ 0
> +#endif
> +
> SECTIONS
> {
> /*
> @@ -16,7 +22,7 @@ SECTIONS
> * segment.
> */
>
> - vvar_start = . - 3 * PAGE_SIZE;
> + vvar_start = . - (3 * PAGE_SIZE + TIMENS_SZ);
> vvar_page = vvar_start;
>
> /* Place all vvars at the offsets in asm/vvar.h. */
> @@ -28,6 +34,7 @@ SECTIONS
>
> pvclock_page = vvar_start + PAGE_SIZE;
> hvclock_page = vvar_start + 2 * PAGE_SIZE;
> + timens_page = vvar_start + 3 * PAGE_SIZE;
>
> . = SIZEOF_HEADERS;
>
> diff --git a/arch/x86/entry/vdso/vdso2c.c b/arch/x86/entry/vdso/vdso2c.c
> index ce67370d14e5..7380908045c7 100644
> --- a/arch/x86/entry/vdso/vdso2c.c
> +++ b/arch/x86/entry/vdso/vdso2c.c
> @@ -75,12 +75,14 @@ enum {
> sym_vvar_page,
> sym_pvclock_page,
> sym_hvclock_page,
> + sym_timens_page,
> };
>
> const int special_pages[] = {
> sym_vvar_page,
> sym_pvclock_page,
> sym_hvclock_page,
> + sym_timens_page,
> };
>
> struct vdso_sym {
> @@ -93,6 +95,7 @@ struct vdso_sym required_syms[] = {
> [sym_vvar_page] = {"vvar_page", true},
> [sym_pvclock_page] = {"pvclock_page", true},
> [sym_hvclock_page] = {"hvclock_page", true},
> + [sym_timens_page] = {"timens_page", true},
> {"VDSO32_NOTE_MASK", true},
> {"__kernel_vsyscall", true},
> {"__kernel_sigreturn", true},
> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> index 2dc4f0b5481c..9bd66f84db5e 100644
> --- a/arch/x86/entry/vdso/vma.c
> +++ b/arch/x86/entry/vdso/vma.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -23,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #if defined(CONFIG_X86_64)
> unsigned int __read_mostly vdso64_enabled = 1;
> @@ -135,6 +137,16 @@ static vm_fault_t vvar_fault(const struct
> vm_special_mapping *sm,
> if (tsc_pg && vclock_was_used(VCLOCK_HVCLOCK))
> return vmf_insert_pfn(vma, vmf->address,
>
Re: [PATCHv5 28/37] x86/vdso: Enable static branches for the timens vdso
On Mon, Jul 29, 2019 at 2:58 PM Dmitry Safonov wrote:
>
> From: Andrei Vagin
>
> As it has been discussed on timens RFC, adding a new conditional branch
> `if (inside_time_ns)` on VDSO for all processes is undesirable.
>
> Addressing those problems, there are two versions of VDSO's .so:
> for host tasks (without any penalty) and for processes inside of time
> namespace with clk_to_ns() that subtracts offsets from host's time.
>
> The timens code in vdso looks like this:
>
> if (timens_static_branch_unlikely()) {
>clk_to_ns(clk, ts);
> }
I'm confused. Now we effectively have *three* versions: the vDSO
without timens, and vDSO with timens but with it switched off, and the
vDSO with timens on. This seems like too much.
What you need is, IMO, a static-branch-ish thing that is per mm. This
has a fundamental problem that the vDSO can be modified using
FOLL_FORCE. Perhaps any CoW of the vDSO should implicitly switch the
static branch on, which at least gives some degree of correctness even
if it's a bit surprising.
--Andy
Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S
On 7/30/19 11:00 PM, Tao Ren wrote:
> On 7/30/19 10:53 PM, Heiner Kallweit wrote:
>> On 31.07.2019 02:12, Tao Ren wrote:
>>> On 7/29/19 11:00 PM, Heiner Kallweit wrote:
On 30.07.2019 07:05, Tao Ren wrote:
> On 7/29/19 8:35 PM, Andrew Lunn wrote:
>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
>>> ("net: phy: switch drivers to use dynamic feature detection"). As
>>> dynamic
>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber
>>> mode (different sets of MII Control/Status registers being used), let's
>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly.
>>
>> Hi Tao
>>
>> What exactly does it get wrong?
>>
>> Thanks
>> Andrew
>
> Hi Andrew,
>
> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and
> none of the features (1000BaseT/100BaseT/10BaseT) can be detected by
> genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half
> ability in this mode.
>
Are you going to use the PHY in copper or fibre mode?
In case you use fibre mode, why do you need the copper modes set as
supported?
Or does the PHY just start in fibre mode and you want to switch it to
copper mode?
>>>
>>> Hi Heiner,
>>>
>>> The phy starts in fiber mode and that's the mode I want.
>>> My observation is: phydev->link is always 0 (Link status bit is never set
>>> in MII_BMSR) by using dynamic ability detection on my machine. I checked
>>> phydev->supported and it's set to "AutoNeg | TP | MII | Pause | Asym_Pause"
>>> by dynamic ability detection. Is it normal/expected? Or maybe the fix
>>> should go to different places? Thank you for your help.
>>>
>>
>> Not sure whether you stated already which kernel version you're using.
>> There's a brand-new extension to auto-detect 1000BaseX:
>> f30e33bcdab9 ("net: phy: Add more 1000BaseX support detection")
>> It's included in the 5.3-rc series.
>
> I'm running kernel 5.2.0. Thank you for the sharing and I didn't know the
> patch. Let me check it out.
I applied above patch and ca72efb6bdc7 ("net: phy: Add detection of 1000BaseX
link mode support") to my 5.2.0 tree but got following warning when booting up
my machine:
"PHY advertising (0,0200,62c0) more modes than genphy supports, some
modes not advertised".
The BCM54616S PHY on my machine only reports 1000-X features in
RGMII->1000Base-KX mode. Is it a known problem?
Anyways let me see if I missed some dependency/follow-up patches..
Cheers,
Tao
[PATCH 3/5] x86: KVM: svm: clear interrupt shadow on all paths in skip_emulated_instruction()
Regardless of the way how we skip instruction, interrupt shadow needs to be
cleared.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Jim Mattson
---
arch/x86/kvm/svm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 80f576e05112..7c7dff3f461f 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -784,13 +784,15 @@ static void skip_emulated_instruction(struct kvm_vcpu
*vcpu)
EMULATE_DONE)
pr_err_once("KVM: %s: unable to skip instruction\n",
__func__);
- return;
+ goto clear_int_shadow;
}
if (svm->next_rip - kvm_rip_read(vcpu) > MAX_INST_SIZE)
printk(KERN_ERR "%s: ip 0x%lx next 0x%llx\n",
__func__, kvm_rip_read(vcpu), svm->next_rip);
kvm_rip_write(vcpu, svm->next_rip);
+
+clear_int_shadow:
svm_set_interrupt_shadow(vcpu, 0);
}
--
2.20.1
[PATCH 0/5] x86: KVM: svm: get rid of hardcoded instructions lengths
Changes since RFC (It's been awhile and I apologize for that): - Dropped ' + 3' from vmrun_interception() as well. - Added xsetbv's implementation to the emulator [Paolo Bonzini] - Added Jim's R-b tags to PATCHes 2 and 3. - Tested with the newly added 'nrips' svm module parameter. Original description: Jim rightfully complains that hardcoding instuctions lengths is not always correct: additional (redundant) prefixes can be used. Luckily, the ugliness is mostly harmless: modern AMD CPUs support NRIP_SAVE feature but I'd like to clean things up and sacrifice speed in favor of correctness. Vitaly Kuznetsov (5): x86: KVM: svm: don't pretend to advance RIP in case wrmsr_interception() results in #GP x86: KVM: svm: avoid flooding logs when skip_emulated_instruction() fails x86: KVM: svm: clear interrupt shadow on all paths in skip_emulated_instruction() x86: KVM: add xsetbv to the emulator x86: KVM: svm: remove hardcoded instruction length from intercepts arch/x86/include/asm/kvm_emulate.h | 3 ++- arch/x86/kvm/emulate.c | 23 ++- arch/x86/kvm/svm.c | 23 --- arch/x86/kvm/x86.c | 6 ++ 4 files changed, 38 insertions(+), 17 deletions(-) -- 2.20.1
[PATCH 4/5] x86: KVM: add xsetbv to the emulator
To avoid hardcoding xsetbv length to '3' we need to support decoding it in
the emulator.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/kvm_emulate.h | 3 ++-
arch/x86/kvm/emulate.c | 23 ++-
arch/x86/kvm/svm.c | 1 +
arch/x86/kvm/x86.c | 6 ++
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index feab24cac610..77cf6c11f66b 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -229,7 +229,7 @@ struct x86_emulate_ops {
int (*pre_leave_smm)(struct x86_emulate_ctxt *ctxt,
const char *smstate);
void (*post_leave_smm)(struct x86_emulate_ctxt *ctxt);
-
+ int (*set_xcr)(struct x86_emulate_ctxt *ctxt, u32 index, u64 xcr);
};
typedef u32 __attribute__((vector_size(16))) sse128_t;
@@ -429,6 +429,7 @@ enum x86_intercept {
x86_intercept_ins,
x86_intercept_out,
x86_intercept_outs,
+ x86_intercept_xsetbv,
nr_x86_intercepts
};
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 718f7d9afedc..f9e843dd992a 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4156,6 +4156,20 @@ static int em_fxrstor(struct x86_emulate_ctxt *ctxt)
return rc;
}
+static int em_xsetbv(struct x86_emulate_ctxt *ctxt)
+{
+ u32 eax, ecx, edx;
+
+ eax = reg_read(ctxt, VCPU_REGS_RAX);
+ edx = reg_read(ctxt, VCPU_REGS_RDX);
+ ecx = reg_read(ctxt, VCPU_REGS_RCX);
+
+ if (ctxt->ops->set_xcr(ctxt, ecx, ((u64)edx << 32) | eax))
+ return emulate_gp(ctxt, 0);
+
+ return X86EMUL_CONTINUE;
+}
+
static bool valid_cr(int nr)
{
switch (nr) {
@@ -4409,6 +4423,12 @@ static const struct opcode group7_rm1[] = {
N, N, N, N, N, N,
};
+static const struct opcode group7_rm2[] = {
+ N,
+ II(ImplicitOps | Priv, em_xsetbv, xsetbv),
+ N, N, N, N, N, N,
+};
+
static const struct opcode group7_rm3[] = {
DIP(SrcNone | Prot | Priv, vmrun, check_svme_pa),
II(SrcNone | Prot | EmulateOnUD, em_hypercall, vmmcall),
@@ -4498,7 +4518,8 @@ static const struct group_dual group7 = { {
}, {
EXT(0, group7_rm0),
EXT(0, group7_rm1),
- N, EXT(0, group7_rm3),
+ EXT(0, group7_rm2),
+ EXT(0, group7_rm3),
II(SrcNone | DstMem | Mov, em_smsw, smsw), N,
II(SrcMem16 | Mov | Priv, em_lmsw, lmsw),
EXT(0, group7_rm7),
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7c7dff3f461f..f0e7e1b1c017 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -6066,6 +6066,7 @@ static const struct __x86_intercept {
[x86_intercept_ins] = POST_EX(SVM_EXIT_IOIO),
[x86_intercept_out] = POST_EX(SVM_EXIT_IOIO),
[x86_intercept_outs]= POST_EX(SVM_EXIT_IOIO),
+ [x86_intercept_xsetbv] = PRE_EX(SVM_EXIT_XSETBV),
};
#undef PRE_EX
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c6d951cbd76c..9512cc38dfe9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6068,6 +6068,11 @@ static void emulator_post_leave_smm(struct
x86_emulate_ctxt *ctxt)
kvm_smm_changed(emul_to_vcpu(ctxt));
}
+static int emulator_set_xcr(struct x86_emulate_ctxt *ctxt, u32 index, u64 xcr)
+{
+ return __kvm_set_xcr(emul_to_vcpu(ctxt), index, xcr);
+}
+
static const struct x86_emulate_ops emulate_ops = {
.read_gpr= emulator_read_gpr,
.write_gpr = emulator_write_gpr,
@@ -6109,6 +6114,7 @@ static const struct x86_emulate_ops emulate_ops = {
.set_hflags = emulator_set_hflags,
.pre_leave_smm = emulator_pre_leave_smm,
.post_leave_smm = emulator_post_leave_smm,
+ .set_xcr = emulator_set_xcr,
};
static void toggle_interruptibility(struct kvm_vcpu *vcpu, u32 mask)
--
2.20.1
[PATCH 2/5] x86: KVM: svm: avoid flooding logs when skip_emulated_instruction() fails
When we're unable to skip instruction with kvm_emulate_instruction() we
will not advance RIP and most likely the guest will get stuck as
consequitive attempts to execute the same instruction will likely result
in the same behavior.
As we're not supposed to see these messages under normal conditions, switch
to pr_err_once().
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Jim Mattson
---
arch/x86/kvm/svm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7e843b340490..80f576e05112 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -782,7 +782,8 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
if (!svm->next_rip) {
if (kvm_emulate_instruction(vcpu, EMULTYPE_SKIP) !=
EMULATE_DONE)
- printk(KERN_DEBUG "%s: NOP\n", __func__);
+ pr_err_once("KVM: %s: unable to skip instruction\n",
+ __func__);
return;
}
if (svm->next_rip - kvm_rip_read(vcpu) > MAX_INST_SIZE)
--
2.20.1
[PATCH 1/5] x86: KVM: svm: don't pretend to advance RIP in case wrmsr_interception() results in #GP
svm->next_rip is only used by skip_emulated_instruction() and in case
kvm_set_msr() fails we rightfully don't do that. Move svm->next_rip
advancement to 'else' branch to avoid creating false impression that
it's always advanced (and make it look like rdmsr_interception()).
This is a preparatory change to removing hardcoded RIP advancement
from instruction intercepts, no functional change.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7eafc6907861..7e843b340490 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -4447,13 +4447,13 @@ static int wrmsr_interception(struct vcpu_svm *svm)
msr.index = ecx;
msr.host_initiated = false;
- svm->next_rip = kvm_rip_read(>vcpu) + 2;
if (kvm_set_msr(>vcpu, )) {
trace_kvm_msr_write_ex(ecx, data);
kvm_inject_gp(>vcpu, 0);
return 1;
} else {
trace_kvm_msr_write(ecx, data);
+ svm->next_rip = kvm_rip_read(>vcpu) + 2;
return kvm_skip_emulated_instruction(>vcpu);
}
}
--
2.20.1
[PATCH 5/5] x86: KVM: svm: remove hardcoded instruction length from intercepts
Various intercepts hard-code the respective instruction lengths to optimize
skip_emulated_instruction(): when next_rip is pre-set we skip
kvm_emulate_instruction(vcpu, EMULTYPE_SKIP). The optimization is, however,
incorrect: different (redundant) prefixes could be used to enlarge the
instruction. We can't really avoid decoding.
svm->next_rip is not used when CPU supports 'nrips' (X86_FEATURE_NRIPS)
feature: next RIP is provided in VMCB. The feature is not really new
(Opteron G3s had it already) and the change should have zero affect.
Remove manual svm->next_rip setting with hard-coded instruction lengths.
The only case where we now use svm->next_rip is EXIT_IOIO: the instruction
length is provided to us by hardware.
Reported-by: Jim Mattson
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/svm.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f0e7e1b1c017..c6aa66324326 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2907,13 +2907,11 @@ static int nop_on_interception(struct vcpu_svm *svm)
static int halt_interception(struct vcpu_svm *svm)
{
- svm->next_rip = kvm_rip_read(>vcpu) + 1;
return kvm_emulate_halt(>vcpu);
}
static int vmmcall_interception(struct vcpu_svm *svm)
{
- svm->next_rip = kvm_rip_read(>vcpu) + 3;
return kvm_emulate_hypercall(>vcpu);
}
@@ -3701,7 +3699,6 @@ static int vmload_interception(struct vcpu_svm *svm)
nested_vmcb = map.hva;
- svm->next_rip = kvm_rip_read(>vcpu) + 3;
ret = kvm_skip_emulated_instruction(>vcpu);
nested_svm_vmloadsave(nested_vmcb, svm->vmcb);
@@ -3728,7 +3725,6 @@ static int vmsave_interception(struct vcpu_svm *svm)
nested_vmcb = map.hva;
- svm->next_rip = kvm_rip_read(>vcpu) + 3;
ret = kvm_skip_emulated_instruction(>vcpu);
nested_svm_vmloadsave(svm->vmcb, nested_vmcb);
@@ -3742,8 +3738,8 @@ static int vmrun_interception(struct vcpu_svm *svm)
if (nested_svm_check_permissions(svm))
return 1;
- /* Save rip after vmrun instruction */
- kvm_rip_write(>vcpu, kvm_rip_read(>vcpu) + 3);
+ if (!kvm_skip_emulated_instruction(>vcpu))
+ return 1;
if (!nested_svm_vmrun(svm))
return 1;
@@ -3779,7 +3775,6 @@ static int stgi_interception(struct vcpu_svm *svm)
if (vgif_enabled(svm))
clr_intercept(svm, INTERCEPT_STGI);
- svm->next_rip = kvm_rip_read(>vcpu) + 3;
ret = kvm_skip_emulated_instruction(>vcpu);
kvm_make_request(KVM_REQ_EVENT, >vcpu);
@@ -3795,7 +3790,6 @@ static int clgi_interception(struct vcpu_svm *svm)
if (nested_svm_check_permissions(svm))
return 1;
- svm->next_rip = kvm_rip_read(>vcpu) + 3;
ret = kvm_skip_emulated_instruction(>vcpu);
disable_gif(svm);
@@ -3820,7 +3814,6 @@ static int invlpga_interception(struct vcpu_svm *svm)
/* Let's treat INVLPGA the same as INVLPG (can be optimized!) */
kvm_mmu_invlpg(vcpu, kvm_rax_read(>vcpu));
- svm->next_rip = kvm_rip_read(>vcpu) + 3;
return kvm_skip_emulated_instruction(>vcpu);
}
@@ -3843,7 +3836,6 @@ static int xsetbv_interception(struct vcpu_svm *svm)
u32 index = kvm_rcx_read(>vcpu);
if (kvm_set_xcr(>vcpu, index, new_bv) == 0) {
- svm->next_rip = kvm_rip_read(>vcpu) + 3;
return kvm_skip_emulated_instruction(>vcpu);
}
@@ -3920,7 +3912,6 @@ static int task_switch_interception(struct vcpu_svm *svm)
static int cpuid_interception(struct vcpu_svm *svm)
{
- svm->next_rip = kvm_rip_read(>vcpu) + 2;
return kvm_emulate_cpuid(>vcpu);
}
@@ -4250,7 +4241,6 @@ static int rdmsr_interception(struct vcpu_svm *svm)
kvm_rax_write(>vcpu, msr_info.data & 0x);
kvm_rdx_write(>vcpu, msr_info.data >> 32);
- svm->next_rip = kvm_rip_read(>vcpu) + 2;
return kvm_skip_emulated_instruction(>vcpu);
}
}
@@ -4456,7 +4446,6 @@ static int wrmsr_interception(struct vcpu_svm *svm)
return 1;
} else {
trace_kvm_msr_write(ecx, data);
- svm->next_rip = kvm_rip_read(>vcpu) + 2;
return kvm_skip_emulated_instruction(>vcpu);
}
}
--
2.20.1
Re: [PATCH v2] media:dvb-frontends:Remove dvb_pll_devcount and id module parameters.
On Wed, Jul 24, 2019 at 06:36:35AM +0100, Sean Young wrote: > On Sat, Jul 20, 2019 at 11:43:02AM +0530, Vandana BN wrote: > > Syzbot reported global-out-of-bounds Read in dvb_pll_attach, while > > accessing id[dvb_pll_devcount], because dvb_pll_devcount was 65, > > that is more than size of 'id' which is DVB_PLL_MAX(64). > > > > Fix would be to check if DVB_PLL_MAX devices are attached and if so return > > NULL from dvb_pll_attach(). But this will put a limit on the number of > > devices that can be attached. > > Also dvb_pll_devcount and "id" module parameter are used for debugging > > purpose to override/force PLL type. > > So this patch removes these module parameters. > > > > Reported-by: syz...@syzkaller.appspotmail.com > > > > usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the > > software demuxer > > dvbdev: DVB: registering new adapter (774 Friio White ISDB-T USB2.0) > > usb 1-1: media controller created > > dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. > > tc90522 0-0018: Toshiba TC90522 attached. > > usb 1-1: DVB: registering adapter 0 frontend 0 (Toshiba TC90522 ISDB-T > > module)... > > dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-T > > module' registered. > > == > > BUG: KASAN: global-out-of-bounds in dvb_pll_attach+0x6c5/0x830 > > drivers/media/dvb-frontends/dvb-pll.c:798 > > Read of size 4 at addr 89c9e5e0 by task kworker/0:1/12 > > > > CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc6+ #13 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Workqueue: usb_hub_wq hub_event > > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > > dump_stack+0xca/0x13e lib/dump_stack.c:113 > > print_address_description+0x67/0x231 mm/kasan/report.c:188 > > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317 > > kasan_report+0xe/0x20 mm/kasan/common.c:614 > > dvb_pll_attach+0x6c5/0x830 drivers/media/dvb-frontends/dvb-pll.c:798 > > dvb_pll_probe+0xfe/0x174 drivers/media/dvb-frontends/dvb-pll.c:877 > > i2c_device_probe+0x790/0xaa0 drivers/i2c/i2c-core-base.c:389 > > really_probe+0x281/0x660 drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > > __device_attach+0x217/0x360 drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > > i2c_new_client_device+0x5b3/0xc40 drivers/i2c/i2c-core-base.c:778 > > i2c_new_device+0x19/0x50 drivers/i2c/i2c-core-base.c:821 > > dvb_module_probe+0xf9/0x220 drivers/media/dvb-core/dvbdev.c:985 > > friio_tuner_attach+0x125/0x1d0 drivers/media/usb/dvb-usb-v2/gl861.c:536 > > dvb_usbv2_adapter_frontend_init > > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:675 [inline] > > dvb_usbv2_adapter_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:804 > > [inline] > > dvb_usbv2_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:865 [inline] > > dvb_usbv2_probe.cold+0x24dc/0x255d > > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:980 > > usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 > > really_probe+0x281/0x660 drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > > __device_attach+0x217/0x360 drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > > usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 > > generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 > > usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 > > really_probe+0x281/0x660 drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > > __device_attach+0x217/0x360 drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > > usb_new_device.cold+0x8c1/0x1016 drivers/usb/core/hub.c:2534 > > hub_port_connect drivers/usb/core/hub.c:5089 [inline] > > hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] > > port_event drivers/usb/core/hub.c:5350 [inline] > > hub_event+0x1ada/0x3590 drivers/usb/core/hub.c:5432 > > process_one_work+0x905/0x1570 kernel/workqueue.c:2269 > > process_scheduled_works kernel/workqueue.c:2331 [inline] > > worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417 > > kthread+0x30b/0x410 kernel/kthread.c:255 > > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 > > > > The buggy address belongs to the variable: > > id+0x100/0x120
Re: [PATCH net-next 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S
On 7/30/19 10:55 PM, Tao Ren wrote: > On 7/30/19 7:34 PM, Andrew Lunn wrote: >>> Hi Andrew, >>> >>> The BCM54616S PHY on my machine is connected to a BCM5396 switch chip over >>> backplane (1000Base-KX). >> >> Ah, that is different. So the board is using it for RGMII to 1000Base-KX? >> >> phy-mode is about the MAC-PHY link. So in this case RGMII. > > Yes. It's RGMII to 1000Base-KX. > >> There is no DT way to configure the PHY-Switch link. However, it >> sounds like you have the PHY strapped so it is doing 1000BaseX on the >> PHY-Switch link. So do you actually need to configure this? > > The PHY is strapped in RGMII-Fiber Mode (the term used in datasheet), but > besides 1000BaseX, 100Base-FX is also supported in this mode. > The datasheet doesn't say which link type (1000BaseX or 100Base-FX) is active > after reset and I cannot find a way to auto-detect the link type, either. I found bit 0 of 100-FX control register can be used to detect PHY-switch link type (means DT is not needed). Will run more testing and send out v2 patch soon. Thank you all for the input and help. Cheers, Tao
linux-next: build warning after merge of the driver-core tree
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/i2c/i2c-core-acpi.c:347:12: warning: 'i2c_acpi_find_match_adapter'
defined but not used [-Wunused-function]
static int i2c_acpi_find_match_adapter(struct device *dev, const void *data)
^~~
Introduced by commit
00500147cbd3 ("drivers: Introduce device lookup variants by ACPI_COMPANION
device")
--
Cheers,
Stephen Rothwell
pgpdXfqSpbDW7.pgp
Description: OpenPGP digital signature
Re: [PATCH V2 4/9] vhost: reset invalidate_count in vhost_set_vring_num_addr()
On 2019/8/1 上午3:32, Jason Gunthorpe wrote: On Wed, Jul 31, 2019 at 09:29:28PM +0800, Jason Wang wrote: On 2019/7/31 下午8:41, Jason Gunthorpe wrote: On Wed, Jul 31, 2019 at 04:46:50AM -0400, Jason Wang wrote: The vhost_set_vring_num_addr() could be called in the middle of invalidate_range_start() and invalidate_range_end(). If we don't reset invalidate_count after the un-registering of MMU notifier, the invalidate_cont will run out of sync (e.g never reach zero). This will in fact disable the fast accessor path. Fixing by reset the count to zero. Reported-by: Michael S. Tsirkin Did Michael report this as well? Correct me if I was wrong. I think it's point 4 described in https://lkml.org/lkml/2019/7/21/25. I'm not sure what that is talking about But this fixes what I described: https://lkml.org/lkml/2019/7/22/554 Jason I'm sorry I miss this, will add your name as reported-by in the next version. Thanks
Re: [PATCH V2 7/9] vhost: do not use RCU to synchronize MMU notifier with worker
On 2019/8/1 上午3:30, Jason Gunthorpe wrote: On Wed, Jul 31, 2019 at 09:28:20PM +0800, Jason Wang wrote: On 2019/7/31 下午8:39, Jason Gunthorpe wrote: On Wed, Jul 31, 2019 at 04:46:53AM -0400, Jason Wang wrote: We used to use RCU to synchronize MMU notifier with worker. This leads calling synchronize_rcu() in invalidate_range_start(). But on a busy system, there would be many factors that may slow down the synchronize_rcu() which makes it unsuitable to be called in MMU notifier. A solution is SRCU but its overhead is obvious with the expensive full memory barrier. Another choice is to use seqlock, but it doesn't provide a synchronization method between readers and writers. The last choice is to use vq mutex, but it need to deal with the worst case that MMU notifier must be blocked and wait for the finish of swap in. So this patch switches use a counter to track whether or not the map was used. The counter was increased when vq try to start or finish uses the map. This means, when it was even, we're sure there's no readers and MMU notifier is synchronized. When it was odd, it means there's a reader we need to wait it to be even again then we are synchronized. You just described a seqlock. Kind of, see my explanation below. We've been talking about providing this as some core service from mmu notifiers because nearly every use of this API needs it. That would be very helpful. IMHO this gets the whole thing backwards, the common pattern is to protect the 'shadow pte' data with a seqlock (usually open coded), such that the mmu notififer side has the write side of that lock and the read side is consumed by the thread accessing or updating the SPTE. Yes, I've considered something like that. But the problem is, mmu notifier (writer) need to wait for the vhost worker to finish the read before it can do things like setting dirty pages and unmapping page. It looks to me seqlock doesn't provide things like this. The seqlock is usually used to prevent a 2nd thread from accessing the VA while it is being changed by the mm. ie you use something seqlocky instead of the ugly mmu_notifier_unregister/register cycle. Yes, so we have two mappings: [1] vring address to VA [2] VA to PA And have several readers and writers 1) set_vring_num_addr(): writer of both [1] and [2] 2) MMU notifier: reader of [1] writer of [2] 3) GUP: reader of [1] writer of [2] 4) memory accessors: reader of [1] and [2] Fortunately, 1) 3) and 4) have already synchronized through vq->mutex. We only need to deal with synchronization between 2) and each of the reset: Sync between 1) and 2): For mapping [1], I do mmu_notifier_unregister/register. This help to avoid holding any lock to do overlap check. Anyway we only care about one or three pages , but the whole guest memory could be several TBs. For mapping [2], both 1) and 2) are writers, so use spinlock (mmu_lock) to synchronize. Sync between 2) and 3): For mapping [1], both are readers, no need any synchronization. For mapping [2], both 2) and 3) are writers, so synchronize through spinlock (mmu_lock); Sync between 2) and 4): For mapping [1], both are readers, no need any synchronization. For mapping [2], synchronize through RCU (or something simliar to seqlock). You suggestion is about the synchronization of [1] which may make sense, but it could be done on top as an optimization. What this path tries to do is to not use RCU for [2]. Of course, the simplest way is to use vq mutex in 2) but it means: - we must hold vq lock to check range overlap - since the critical section was increased, the worst case is to wait guest memory to be swapped in, this could be even slower than synchronize_rcu(). You are supposed to use something simple like a spinlock or mutex inside the invalidate_range_start to serialized tear down of the SPTEs with their accessors. Technically yes, but we probably can't afford that for vhost fast path, the atomics eliminate almost all the performance improvement brought by this patch on a machine without SMAP. write_seqcount_begin() map = vq->map[X] write or read through map->addr directly write_seqcount_end() There's no rmb() in write_seqcount_begin(), so map could be read before write_seqcount_begin(), but it looks to me now that this doesn't harm at all, maybe we can try this way. That is because it is a write side lock, not a read lock. IIRC seqlocks have weaker barriers because the write side needs to be serialized in some other way. Yes. Having a hard thought of the code, it looks to me write_seqcount_begin()/end() is sufficient here: - Notifier will only assign NULL to map, so it doesn't harm to read map before seq, then we will fallback to normal copy_from/to_user() slow path earlier - if we write through map->addr, it should be done before increasing the seqcount because of the smp_wmb() in write_seqcount_end() - if we read through map->addr which also contain a store to a pointer, we have a good data
Re: [PATCH] linux-next 20190731 - aegis128-core.c fails to build
(+ Arnd)
On Thu, 1 Aug 2019 at 07:52, Valdis Klētnieks wrote:
>
> The recent NEON SIMD patches break the build if CONFIG_CRYPTO_AEGIS128_SIMD
> isn't set:
>
> MODPOST 558 modules
> ERROR: "crypto_aegis128_decrypt_chunk_simd" [crypto/aegis128.ko] undefined!
> ERROR: "crypto_aegis128_update_simd" [crypto/aegis128.ko] undefined!
> ERROR: "crypto_aegis128_encrypt_chunk_simd" [crypto/aegis128.ko] undefined!
> make[1]: *** [scripts/Makefile.modpost:105: modules-modpost] Error 1
> make: *** [Makefile:1299: modules] Error 2
>
> Add proper definitions and stubs to aegis.h so it builds both ways. This
> necessitated moving other stuff from aegis128-core.c to aegis.h so things were
> defined in the proper order.
>
> Signed-off-by: Valdis Kletnieks
Which compiler version are you using? All references to the
crypt_aegis128_xx_simd() routines should disappear if
CONFIG_CRYPTO_AEGIS128_SIMD is not set (in which case have_simd will
always be false and so the compiler should optimize away those calls).
> ---
> diff --git a/crypto/aegis.h b/crypto/aegis.h
> index 4d56a85aea49..50a7496ca4ae 100644
> --- a/crypto/aegis.h
> +++ b/crypto/aegis.h
> @@ -13,6 +13,11 @@
> #include
> #include
>
> +#define AEGIS128_NONCE_SIZE 16
> +#define AEGIS128_STATE_BLOCKS 5
> +#define AEGIS128_KEY_SIZE 16
> +#define AEGIS128_MIN_AUTH_SIZE 8
> +#define AEGIS128_MAX_AUTH_SIZE 16
> #define AEGIS_BLOCK_SIZE 16
>
> union aegis_block {
> @@ -21,6 +26,39 @@ union aegis_block {
> u8 bytes[AEGIS_BLOCK_SIZE];
> };
>
> +struct aegis_state {
> + union aegis_block blocks[AEGIS128_STATE_BLOCKS];
> +};
> +
> +struct aegis_ctx {
> + union aegis_block key;
> +};
> +
> +struct aegis128_ops {
> + int (*skcipher_walk_init)(struct skcipher_walk *walk,
> + struct aead_request *req, bool atomic);
> +
> + void (*crypt_chunk)(struct aegis_state *state, u8 *dst,
> + const u8 *src, unsigned int size);
> +};
> +
> +
> +#ifdef CONFIG_CRYPTO_AEGIS128_SIMD
> +bool crypto_aegis128_have_simd(void);
> +void crypto_aegis128_update_simd(struct aegis_state *state, const void *msg);
> +void crypto_aegis128_encrypt_chunk_simd(struct aegis_state *state, u8 *dst,
> + const u8 *src, unsigned int size);
> +void crypto_aegis128_decrypt_chunk_simd(struct aegis_state *state, u8 *dst,
> + const u8 *src, unsigned int size);
> +#else
> +static inline bool crypto_aegis128_have_simd(void) { return false; }
> +static inline void crypto_aegis128_update_simd(struct aegis_state *state,
> const void *msg) { }
> +static inline void crypto_aegis128_encrypt_chunk_simd(struct aegis_state
> *state, u8 *dst,
> + const u8 *src, unsigned int size) { }
> +static inline void crypto_aegis128_decrypt_chunk_simd(struct aegis_state
> *state, u8 *dst,
> + const u8 *src, unsigned int size) { }
> +#endif
> +
> #define AEGIS_BLOCK_ALIGN (__alignof__(union aegis_block))
> #define AEGIS_ALIGNED(p) IS_ALIGNED((uintptr_t)p, AEGIS_BLOCK_ALIGN)
>
> diff --git a/crypto/aegis128-core.c b/crypto/aegis128-core.c
> index f815b4685156..8b738128a921 100644
> --- a/crypto/aegis128-core.c
> +++ b/crypto/aegis128-core.c
> @@ -20,37 +20,8 @@
>
> #include "aegis.h"
>
> -#define AEGIS128_NONCE_SIZE 16
> -#define AEGIS128_STATE_BLOCKS 5
> -#define AEGIS128_KEY_SIZE 16
> -#define AEGIS128_MIN_AUTH_SIZE 8
> -#define AEGIS128_MAX_AUTH_SIZE 16
> -
> -struct aegis_state {
> - union aegis_block blocks[AEGIS128_STATE_BLOCKS];
> -};
> -
> -struct aegis_ctx {
> - union aegis_block key;
> -};
> -
> -struct aegis128_ops {
> - int (*skcipher_walk_init)(struct skcipher_walk *walk,
> - struct aead_request *req, bool atomic);
> -
> - void (*crypt_chunk)(struct aegis_state *state, u8 *dst,
> - const u8 *src, unsigned int size);
> -};
> -
> static bool have_simd;
>
> -bool crypto_aegis128_have_simd(void);
> -void crypto_aegis128_update_simd(struct aegis_state *state, const void *msg);
> -void crypto_aegis128_encrypt_chunk_simd(struct aegis_state *state, u8 *dst,
> - const u8 *src, unsigned int size);
> -void crypto_aegis128_decrypt_chunk_simd(struct aegis_state *state, u8 *dst,
> - const u8 *src, unsigned int size);
> -
> static void crypto_aegis128_update(struct aegis_state *state)
> {
> union aegis_block tmp;
>
RE: [PATCH 5/6] mtd: spi-nor: Add s3an_post_sfdp_fixups()
Hi Tudor, > -Original Message- > From: tudor.amba...@microchip.com > Sent: Wednesday, July 31, 2019 6:37 PM > To: Naga Sureshkumar Relli ; > boris.brezil...@collabora.com; > marek.va...@gmail.com; vigne...@ti.com > Cc: rich...@nod.at; linux-kernel@vger.kernel.org; > linux-...@lists.infradead.org; > miquel.ray...@bootlin.com; computersforpe...@gmail.com; dw...@infradead.org > Subject: Re: [PATCH 5/6] mtd: spi-nor: Add s3an_post_sfdp_fixups() > > Hi, Naga, > > On 07/31/2019 03:31 PM, Naga Sureshkumar Relli wrote: > >> + if (nor->info->flags & SPI_S3AN) > >> + s3an_post_sfdp_fixups(nor); > >> } > >> > > Instead of checking the flags, why can't we call directly the nor_fixups? > > like Boris implementation nor->info->fixups->post_sfdp() > > https://patchwork.ozlabs.org/patch/1009291/ > > This check will vanish and nor->info->fixups->post_sfdp() will be called > directly once I'll > respin the manufacturer driver part. post_sfdp() will set just flash > parameters. Check Boris' > patch at https://patchwork.ozlabs.org/patch/1009295/ > > I'll try to respin the rest of Boris' patches sometime at the beginning of > the next week. Ok, Thanks. Regards, Naga Sureshkumar Relli > > Cheers, > ta
RE: [PATCH 5/6] mtd: spi-nor: Add s3an_post_sfdp_fixups()
> -Original Message- > From: Boris Brezillon > Sent: Wednesday, July 31, 2019 6:08 PM > To: Naga Sureshkumar Relli > Cc: tudor.amba...@microchip.com; marek.va...@gmail.com; vigne...@ti.com; > rich...@nod.at; linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; > miquel.ray...@bootlin.com; computersforpe...@gmail.com; dw...@infradead.org > Subject: Re: [PATCH 5/6] mtd: spi-nor: Add s3an_post_sfdp_fixups() > > On Wed, 31 Jul 2019 12:31:19 + > Naga Sureshkumar Relli wrote: > > > Hi Tudor, > > > > Thanks for the updates. With these kind of updates, we can add Vendor > > specific Code easily, like Xilinx Dual parallel and stacked modes. > > In these configurations we need to tweak the nor parameters like page_size, > > sectors etc. > > So with the help of these patches. we can easily update these parameters. > > Absolutely not. This is just a solution to recover from broken SFDP tables. Ok. Thanks, Naga Sureshkumar Relli
[PATCH v3 1/3] mtd: spi-nor: always use bounce buffer for register read/writes
spi-mem layer expects all buffers passed to it to be DMA'able. But
spi-nor layer mostly allocates buffers on stack for reading/writing to
registers and therefore are not DMA'able. Introduce bounce buffer to be
used to read/write to registers. This ensures that buffer passed to
spi-mem layer during register read/writes is DMA'able. With this change
nor->cmd-buf is no longer used, so drop it.
Signed-off-by: Vignesh Raghavendra
---
v3: new patch
drivers/mtd/spi-nor/spi-nor.c | 71 ---
include/linux/mtd/spi-nor.h | 7 +++-
2 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 03cc788511d5..8685e4ab6a25 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -296,15 +296,14 @@ struct flash_info {
static int read_sr(struct spi_nor *nor)
{
int ret;
- u8 val;
- ret = nor->read_reg(nor, SPINOR_OP_RDSR, , 1);
+ ret = nor->read_reg(nor, SPINOR_OP_RDSR, nor->bouncebuf, 1);
if (ret < 0) {
pr_err("error %d reading SR\n", (int) ret);
return ret;
}
- return val;
+ return nor->bouncebuf[0];
}
/*
@@ -315,15 +314,14 @@ static int read_sr(struct spi_nor *nor)
static int read_fsr(struct spi_nor *nor)
{
int ret;
- u8 val;
- ret = nor->read_reg(nor, SPINOR_OP_RDFSR, , 1);
+ ret = nor->read_reg(nor, SPINOR_OP_RDFSR, nor->bouncebuf, 1);
if (ret < 0) {
pr_err("error %d reading FSR\n", ret);
return ret;
}
- return val;
+ return nor->bouncebuf[0];
}
/*
@@ -334,15 +332,14 @@ static int read_fsr(struct spi_nor *nor)
static int read_cr(struct spi_nor *nor)
{
int ret;
- u8 val;
- ret = nor->read_reg(nor, SPINOR_OP_RDCR, , 1);
+ ret = nor->read_reg(nor, SPINOR_OP_RDCR, nor->bouncebuf, 1);
if (ret < 0) {
dev_err(nor->dev, "error %d reading CR\n", ret);
return ret;
}
- return val;
+ return nor->bouncebuf[0];
}
/*
@@ -351,8 +348,8 @@ static int read_cr(struct spi_nor *nor)
*/
static int write_sr(struct spi_nor *nor, u8 val)
{
- nor->cmd_buf[0] = val;
- return nor->write_reg(nor, SPINOR_OP_WRSR, nor->cmd_buf, 1);
+ nor->bouncebuf[0] = val;
+ return nor->write_reg(nor, SPINOR_OP_WRSR, nor->bouncebuf, 1);
}
/*
@@ -500,31 +497,31 @@ static int set_4byte(struct spi_nor *nor, bool enable)
* We must clear the register to enable normal behavior.
*/
write_enable(nor);
- nor->cmd_buf[0] = 0;
- nor->write_reg(nor, SPINOR_OP_WREAR, nor->cmd_buf, 1);
+ nor->bouncebuf[0] = 0;
+ nor->write_reg(nor, SPINOR_OP_WREAR,
+ nor->bouncebuf, 1);
write_disable(nor);
}
return status;
default:
/* Spansion style */
- nor->cmd_buf[0] = enable << 7;
- return nor->write_reg(nor, SPINOR_OP_BRWR, nor->cmd_buf, 1);
+ nor->bouncebuf[0] = enable << 7;
+ return nor->write_reg(nor, SPINOR_OP_BRWR, nor->bouncebuf, 1);
}
}
static int s3an_sr_ready(struct spi_nor *nor)
{
int ret;
- u8 val;
- ret = nor->read_reg(nor, SPINOR_OP_XRDSR, , 1);
+ ret = nor->read_reg(nor, SPINOR_OP_XRDSR, nor->bouncebuf, 1);
if (ret < 0) {
dev_err(nor->dev, "error %d reading XRDSR\n", (int) ret);
return ret;
}
- return !!(val & XSR_RDY);
+ return !!(nor->bouncebuf[0] & XSR_RDY);
}
static int spi_nor_sr_ready(struct spi_nor *nor)
@@ -683,7 +680,6 @@ static loff_t spi_nor_s3an_addr_convert(struct spi_nor
*nor, unsigned int addr)
*/
static int spi_nor_erase_sector(struct spi_nor *nor, u32 addr)
{
- u8 buf[SPI_NOR_MAX_ADDR_WIDTH];
int i;
if (nor->flags & SNOR_F_S3AN_ADDR_DEFAULT)
@@ -697,11 +693,12 @@ static int spi_nor_erase_sector(struct spi_nor *nor, u32
addr)
* control
*/
for (i = nor->addr_width - 1; i >= 0; i--) {
- buf[i] = addr & 0xff;
+ nor->bouncebuf[i] = addr & 0xff;
addr >>= 8;
}
- return nor->write_reg(nor, nor->erase_opcode, buf, nor->addr_width);
+ return nor->write_reg(nor, nor->erase_opcode, nor->bouncebuf,
+ nor->addr_width);
}
/**
@@ -1404,9 +1401,11 @@ static int write_sr_cr(struct spi_nor *nor, u8 *sr_cr)
{
int ret;
+ memcpy(nor->bouncebuf, sr_cr, 2);
+
write_enable(nor);
- ret = nor->write_reg(nor, SPINOR_OP_WRSR, sr_cr, 2);
+ ret = nor->write_reg(nor, SPINOR_OP_WRSR, nor->bouncebuf, 2);
if (ret <
[PATCH v3 2/3] mtd: spi-nor: Move m25p80 code in spi-nor.c
From: Boris Brezillon
The m25p80 driver is actually a generic wrapper around the spi-mem
layer. Not only the driver name is misleading, but we'd expect such a
common logic to be directly available in the core. Another reason for
moving this code is that SPI NOR controller drivers should
progressively be replaced by SPI controller drivers implementing the
spi_mem_ops interface, and when the conversion is done, we should have
a single spi-nor driver directly interfacing with the spi-mem layer.
While moving the code we also fix a longstanding issue when
non-DMA-able buffers are passed by the MTD layer.
Signed-off-by: Boris Brezillon
Signed-off-by: Vignesh Raghavendra
---
v3:
Simplify register read/write by dropping spi_nor_exec_op() and using
spi_mem_exec_op() directly
Modify spi_nor_spimem_xfer_data() to drop "enum spi_nor_protocol proto"
Fix misc coding style comments by Tudor
v2:
Add docs for new functions added
Add spi_nor_ prefix to new functions
Incorporate Andrey's patches https://lkml.org/lkml/2019/4/1/32
to avoid looping spi_nor_spimem_* APIs
drivers/mtd/devices/Kconfig | 18 -
drivers/mtd/devices/Makefile | 1 -
drivers/mtd/devices/m25p80.c | 347 ---
drivers/mtd/spi-nor/Kconfig | 2 +
drivers/mtd/spi-nor/spi-nor.c | 632 --
include/linux/mtd/spi-nor.h | 3 +
6 files changed, 604 insertions(+), 399 deletions(-)
delete mode 100644 drivers/mtd/devices/m25p80.c
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 49abbc52457d..f96287c4b789 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -79,24 +79,6 @@ config MTD_DATAFLASH_OTP
other key product data. The second half is programmed with a
unique-to-each-chip bit pattern at the factory.
-config MTD_M25P80
- tristate "Support most SPI Flash chips (AT26DF, M25P, W25X, ...)"
- depends on SPI_MASTER && MTD_SPI_NOR
- select SPI_MEM
- help
- This enables access to most modern SPI flash chips, used for
- program and data storage. Series supported include Atmel AT26DF,
- Spansion S25SL, SST 25VF, ST M25P, and Winbond W25X. Other chips
- are supported as well. See the driver source for the current list,
- or to add other chips.
-
- Note that the original DataFlash chips (AT45 series, not AT26DF),
- need an entirely different driver.
-
- Set up your spi devices with the right board-specific platform data,
- if you want to specify device partitioning or to use a device which
- doesn't support the JEDEC ID instruction.
-
config MTD_MCHP23K256
tristate "Microchip 23K256 SRAM"
depends on SPI_MASTER
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index 94895eab3066..991c8d12c016 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -12,7 +12,6 @@ obj-$(CONFIG_MTD_MTDRAM) += mtdram.o
obj-$(CONFIG_MTD_LART) += lart.o
obj-$(CONFIG_MTD_BLOCK2MTD)+= block2mtd.o
obj-$(CONFIG_MTD_DATAFLASH)+= mtd_dataflash.o
-obj-$(CONFIG_MTD_M25P80) += m25p80.o
obj-$(CONFIG_MTD_MCHP23K256) += mchp23k256.o
obj-$(CONFIG_MTD_SPEAR_SMI)+= spear_smi.o
obj-$(CONFIG_MTD_SST25L) += sst25l.o
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
deleted file mode 100644
index c50888670250..
--- a/drivers/mtd/devices/m25p80.c
+++ /dev/null
@@ -1,347 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * MTD SPI driver for ST M25Pxx (and similar) serial flash chips
- *
- * Author: Mike Lavender, m...@steroidmicros.com
- *
- * Copyright (c) 2005, Intec Automation Inc.
- *
- * Some parts are based on lart.c by Abraham Van Der Merwe
- *
- * Cleaned up and generalized based on mtd_dataflash.c
- */
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-struct m25p {
- struct spi_mem *spimem;
- struct spi_nor spi_nor;
-};
-
-static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
-{
- struct m25p *flash = nor->priv;
- struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
- SPI_MEM_OP_NO_ADDR,
- SPI_MEM_OP_NO_DUMMY,
- SPI_MEM_OP_DATA_IN(len, NULL, 1));
- void *scratchbuf;
- int ret;
-
- scratchbuf = kmalloc(len, GFP_KERNEL);
- if (!scratchbuf)
- return -ENOMEM;
-
- op.data.buf.in = scratchbuf;
- ret = spi_mem_exec_op(flash->spimem, );
- if (ret < 0)
- dev_err(>spimem->spi->dev, "error %d reading %x\n", ret,
- code);
- else
- memcpy(val, scratchbuf, len);
-
- kfree(scratchbuf);
-
- return ret;
-}
-
-static int m25p80_write_reg(struct spi_nor
[PATCH v3 3/3] mtd: spi-nor: Rework hwcaps selection for the spi-mem case
From: Boris Brezillon
The spi-mem layer provides a spi_mem_supports_op() function to check
whether a specific operation is supported by the controller or not.
This is much more accurate than the hwcaps selection logic based on
SPI_{RX,TX}_ flags.
Rework the hwcaps selection logic to use spi_mem_supports_op() when
nor->spimem != NULL.
Signed-off-by: Boris Brezillon
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/spi-nor.c | 183 +++---
include/linux/mtd/spi-nor.h | 14 +++
2 files changed, 161 insertions(+), 36 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 4fae7f92715a..2590d82982e8 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2952,6 +2952,129 @@ static int spi_nor_read_sfdp(struct spi_nor *nor, u32
addr,
return ret;
}
+/**
+ * spi_nor_spimem_check_op - check if the operation is supported
+ * by controller
+ *@nor:pointer to a 'struct spi_nor'
+ *@op: pointer to op template to be checked
+ *
+ * Returns 0 if operation is supported, -ENOTSUPP otherwise.
+ */
+static int spi_nor_spimem_check_op(struct spi_nor *nor,
+ struct spi_mem_op *op)
+{
+ /*
+* First test with 4 address bytes. The opcode itself might
+* be a 3B addressing opcode but we don't care, because
+* SPI controller implementation should not check the opcode,
+* but just the sequence.
+*/
+ op->addr.nbytes = 4;
+ if (!spi_mem_supports_op(nor->spimem, op)) {
+ /* If flash size <16MB, 3 address bytes are sufficient */
+ if (nor->mtd.size <= SZ_16M) {
+ op->addr.nbytes = 3;
+ if (!spi_mem_supports_op(nor->spimem, op))
+ return -ENOTSUPP;
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * spi_nor_spimem_check_readop - check if the read op is supported
+ * by controller
+ *@nor: pointer to a 'struct spi_nor'
+ *@read:pointer to op template to be checked
+ *
+ * Returns 0 if operation is supported, -ENOTSUPP otherwise.
+ */
+static int spi_nor_spimem_check_readop(struct spi_nor *nor,
+ const struct spi_nor_read_command *read)
+{
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(read->opcode, 1),
+ SPI_MEM_OP_ADDR(3, 0, 1),
+ SPI_MEM_OP_DUMMY(0, 1),
+ SPI_MEM_OP_DATA_IN(0, NULL, 1));
+
+ op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(read->proto);
+ op.addr.buswidth = spi_nor_get_protocol_addr_nbits(read->proto);
+ op.data.buswidth = spi_nor_get_protocol_data_nbits(read->proto);
+ op.dummy.buswidth = op.addr.buswidth;
+ op.dummy.nbytes = (read->num_mode_clocks + read->num_wait_states) *
+ op.dummy.buswidth / 8;
+
+ return spi_nor_spimem_check_op(nor, );
+}
+
+/**
+ * spi_nor_spimem_check_pp - check if the page program op is supported
+ * by controller
+ *@nor: pointer to a 'struct spi_nor'
+ *@pp: pointer to op template to be checked
+ *
+ * Returns 0 if operation is supported, -ENOTSUPP otherwise.
+ */
+static int spi_nor_spimem_check_pp(struct spi_nor *nor,
+ const struct spi_nor_pp_command *pp)
+{
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(pp->opcode, 1),
+ SPI_MEM_OP_ADDR(3, 0, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(0, NULL, 1));
+
+ op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(pp->proto);
+ op.addr.buswidth = spi_nor_get_protocol_addr_nbits(pp->proto);
+ op.data.buswidth = spi_nor_get_protocol_data_nbits(pp->proto);
+
+ return spi_nor_spimem_check_op(nor, );
+}
+
+/**
+ * spi_nor_spimem_adjust_hwcaps - Find optimal Read/Write protocol
+ *based on SPI controller capabilities
+ * @nor:pointer to a 'struct spi_nor'
+ * @params: pointer to the 'struct spi_nor_flash_parameter'
+ * representing SPI NOR flash capabilities
+ * @hwcaps: pointer to resulting capabilities after adjusting
+ * according to controller and flash's capability
+ */
+static void
+spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor,
+const struct spi_nor_flash_parameter *params,
+u32 *hwcaps)
+{
+ unsigned int cap;
+
+ /* DTR modes are not supported yet, mask them all. */
+ *hwcaps &= ~SNOR_HWCAPS_DTR;
+
+ /* X-X-X modes are not supported yet, mask them all. */
+ *hwcaps &= ~SNOR_HWCAPS_X_X_X;
+
+ /* Start with read
[PATCH v3 0/3] Merge m25p80 into spi-nor
This is repost of patch 6 and 7 split from from Boris Brezillon's X-X-X
mode support series[1]
Background from cover letter for RFC[1]:
m25p80 is just a simple SPI NOR controller driver (a wrapper around the
SPI mem API). Not only it shouldn't be named after a specific SPI NOR
chip, but it also doesn't deserve a specific driver IMO, especially if
the end goal is to get rid of SPI NOR controller drivers found in
drivers/mtd/spi-nor/ and replace them by SPI mem drivers (which would
be placed in drivers/spi/). With this solution, we declare the SPI NOR
driver as a spi_mem_driver, just like the SPI NAND layer is declared as
a spi_mem driver (patch 1/2).
This solution also allows us to check at a fined-grain level (thanks to
the spi_mem_supports_op() function) which operations are supported and
which ones are not, while the original m25p80 logic was basing this
decision on the SPI_{RX,TX}_{DUAL,QUAD,OCTO} flags only (patch 2/2).
[1] https://patchwork.ozlabs.org/cover/982926/
Tested on TI' DRA7xx EVM with TI QSPI controller (a spi-mem driver) with
DMA (s25fl256) flash. I don't see any performance regression due to
bounce buffer copy introduced by this series
Also tested with cadence-quadspi (a spi-nor driver) driver
Boris Brezillon (2):
mtd: spi-nor: Move m25p80 code in spi-nor.c
mtd: spi-nor: Rework hwcaps selection for the spi-mem case
Vignesh Raghavendra (1):
mtd: spi-nor: always use bounce buffer for register read/writes
drivers/mtd/devices/Kconfig | 18 -
drivers/mtd/devices/Makefile | 1 -
drivers/mtd/devices/m25p80.c | 347 ---
drivers/mtd/spi-nor/Kconfig | 2 +
drivers/mtd/spi-nor/spi-nor.c | 802 +++---
include/linux/mtd/spi-nor.h | 24 +-
6 files changed, 769 insertions(+), 425 deletions(-)
delete mode 100644 drivers/mtd/devices/m25p80.c
--
2.22.0
Re: [PATCH] fork: Improve error message for corrupted page tables
On Wed, 31 Jul 2019 15:36:49 -0700 Sai Praneeth Prakhya
wrote:
> > > +static const char * const resident_page_types[NR_MM_COUNTERS] = {
> > > + "MM_FILEPAGES",
> > > + "MM_ANONPAGES",
> > > + "MM_SWAPENTS",
> > > + "MM_SHMEMPAGES",
> > > +};
> >
> > But please let's not put this in a header file. We're asking the
> > compiler to put a copy of all of this into every compilation unit which
> > includes the header. Presumably the compiler is smart enough not to
> > do that, but it's not good practice.
>
> Thanks for the explanation. Makes sense to me.
>
> Just wanted to check before sending V2,
> Is it OK if I add this to kernel/fork.c? or do you have something else in
> mind?
I was thinking somewhere like mm/util.c so the array could be used by
other code. But it seems there is no such code. Perhaps it's best to
just leave fork.c as it is now.
Re: [PATCH 2/2] net: gmii2rgmii: Switch priv field in mdio device structure
On Wed, Jul 31, 2019 at 03:06:19PM +0530, Harini Katakam wrote: > Use the priv field in mdio device structure instead of the one in > phy device structure. The phy device priv field may be used by the > external phy driver and should not be overwritten. Hi Harini I _think_ you could use dev_set_drvdata(>dev) in xgmiitorgmii_probe() and dev_get_drvdata(>mdiomdio.dev) in _read_status() Andrew
Re: [PATCH 7/9] media: hantro: Add core bits to support H264 decoding
Hi Boris, On Wed, Jun 19, 2019 at 9:15 PM Boris Brezillon wrote: [snip] > @@ -533,10 +535,21 @@ hantro_queue_setup(struct vb2_queue *vq, unsigned int > *num_buffers, > return -EINVAL; > } > > + /* The H264 decoder needs extra size on the output buffer. */ > + if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE_RAW) > + extra_size0 = 128 * DIV_ROUND_UP(pixfmt->width, 16) * > + DIV_ROUND_UP(pixfmt->height, 16); > + I wonder if this shouldn't be accounted for already in the sizeimage returned by TRY_/S_FMT, so that the application can know the required buffer size if it uses some external allocator and DMABUF memory type. I know we had it like this in our downstream code, but it wasn't the problem because we use minigbm, where we explicitly add the same padding in the rockchip backend. Any thoughts? Best regards, Tomasz
[PATCH net-next 05/12] net: hns3: remove unnecessary variable in hclge_get_mac_vlan_cmd_status()
From: Jian Shen
The local variable return_status in hclge_get_mac_val_cmd_status()
is useless. So this patch returns the error code directly, instead of
using this variable. Also, replace some '%d' with '%u' in
hclge_get_mac_val_cmd_status().
Signed-off-by: Jian Shen
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 50 +++---
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 855b65e..4317c8f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -6268,7 +6268,6 @@ static int hclge_get_mac_vlan_cmd_status(struct
hclge_vport *vport,
enum hclge_mac_vlan_tbl_opcode op)
{
struct hclge_dev *hdev = vport->back;
- int return_status = -EIO;
if (cmdq_resp) {
dev_err(>pdev->dev,
@@ -6279,52 +6278,53 @@ static int hclge_get_mac_vlan_cmd_status(struct
hclge_vport *vport,
if (op == HCLGE_MAC_VLAN_ADD) {
if ((!resp_code) || (resp_code == 1)) {
- return_status = 0;
+ return 0;
} else if (resp_code == HCLGE_ADD_UC_OVERFLOW) {
- return_status = -ENOSPC;
dev_err(>pdev->dev,
"add mac addr failed for uc_overflow.\n");
+ return -ENOSPC;
} else if (resp_code == HCLGE_ADD_MC_OVERFLOW) {
- return_status = -ENOSPC;
dev_err(>pdev->dev,
"add mac addr failed for mc_overflow.\n");
- } else {
- dev_err(>pdev->dev,
- "add mac addr failed for undefined, code=%d.\n",
- resp_code);
+ return -ENOSPC;
}
+
+ dev_err(>pdev->dev,
+ "add mac addr failed for undefined, code=%u.\n",
+ resp_code);
+ return -EIO;
} else if (op == HCLGE_MAC_VLAN_REMOVE) {
if (!resp_code) {
- return_status = 0;
+ return 0;
} else if (resp_code == 1) {
- return_status = -ENOENT;
dev_dbg(>pdev->dev,
"remove mac addr failed for miss.\n");
- } else {
- dev_err(>pdev->dev,
- "remove mac addr failed for undefined,
code=%d.\n",
- resp_code);
+ return -ENOENT;
}
+
+ dev_err(>pdev->dev,
+ "remove mac addr failed for undefined, code=%u.\n",
+ resp_code);
+ return -EIO;
} else if (op == HCLGE_MAC_VLAN_LKUP) {
if (!resp_code) {
- return_status = 0;
+ return 0;
} else if (resp_code == 1) {
- return_status = -ENOENT;
dev_dbg(>pdev->dev,
"lookup mac addr failed for miss.\n");
- } else {
- dev_err(>pdev->dev,
- "lookup mac addr failed for undefined,
code=%d.\n",
- resp_code);
+ return -ENOENT;
}
- } else {
- return_status = -EINVAL;
+
dev_err(>pdev->dev,
- "unknown opcode for
get_mac_vlan_cmd_status,opcode=%d.\n",
- op);
+ "lookup mac addr failed for undefined, code=%u.\n",
+ resp_code);
+ return -EIO;
}
- return return_status;
+ dev_err(>pdev->dev,
+ "unknown opcode for get_mac_vlan_cmd_status, opcode=%d.\n", op);
+
+ return -EINVAL;
}
static int hclge_update_desc_vfid(struct hclge_desc *desc, int vfid, bool clr)
--
2.7.4
[PATCH net-next 10/12] net: hns3: fix some reset handshake issue
Currently, the driver sets handshake status to tell the hardware
that the driver have downed the netdev and it can continue with
reset process. The driver will clear the handshake status when
re-initializing the CMDQ, and does not recover this status
when reset fail, which may cause the hardware to wait for
the handshake status to be set and not being able to continue
with reset process.
So this patch delays clearing handshake status just before UP,
and recovers this status when reset fail.
BTW, this patch adds a new function hclge(vf)_reset_handshake() to
deal with the reset handshake issue, and renames
HCLGE(VF)_NIC_CMQ_ENABLE to HCLGE(VF)_NIC_SW_RST_RDY which
represents this register bit more accurately.
Fixes: ada13ee3db7b ("net: hns3: add handshake with hardware while doing reset")
Signed-off-by: Huazhong Tan
Reviewed-by: Peng Li
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 7 +++--
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 7 +++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 23 ++--
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 4 ++-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 7 +++--
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 31 +-
6 files changed, 64 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index c20b972..ecf58cf 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -103,14 +103,17 @@ static void hclge_cmd_config_regs(struct hclge_cmq_ring
*ring)
dma_addr_t dma = ring->desc_dma_addr;
struct hclge_dev *hdev = ring->dev;
struct hclge_hw *hw = >hw;
+ u32 reg_val;
if (ring->ring_type == HCLGE_TYPE_CSQ) {
hclge_write_dev(hw, HCLGE_NIC_CSQ_BASEADDR_L_REG,
lower_32_bits(dma));
hclge_write_dev(hw, HCLGE_NIC_CSQ_BASEADDR_H_REG,
upper_32_bits(dma));
- hclge_write_dev(hw, HCLGE_NIC_CSQ_DEPTH_REG,
- ring->desc_num >> HCLGE_NIC_CMQ_DESC_NUM_S);
+ reg_val = hclge_read_dev(hw, HCLGE_NIC_CSQ_DEPTH_REG);
+ reg_val &= HCLGE_NIC_SW_RST_RDY;
+ reg_val |= ring->desc_num >> HCLGE_NIC_CMQ_DESC_NUM_S;
+ hclge_write_dev(hw, HCLGE_NIC_CSQ_DEPTH_REG, reg_val);
hclge_write_dev(hw, HCLGE_NIC_CSQ_HEAD_REG, 0);
hclge_write_dev(hw, HCLGE_NIC_CSQ_TAIL_REG, 0);
} else {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index cfa77dd..63cf9a7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -907,8 +907,11 @@ struct hclge_serdes_lb_cmd {
#define HCLGE_NIC_CRQ_DEPTH_REG0x27020
#define HCLGE_NIC_CRQ_TAIL_REG 0x27024
#define HCLGE_NIC_CRQ_HEAD_REG 0x27028
-#define HCLGE_NIC_CMQ_EN_B 16
-#define HCLGE_NIC_CMQ_ENABLE BIT(HCLGE_NIC_CMQ_EN_B)
+
+/* this bit indicates that the driver is ready for hardware reset */
+#define HCLGE_NIC_SW_RST_RDY_B 16
+#define HCLGE_NIC_SW_RST_RDY BIT(HCLGE_NIC_SW_RST_RDY_B)
+
#define HCLGE_NIC_CMQ_DESC_NUM 1024
#define HCLGE_NIC_CMQ_DESC_NUM_S 3
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 4317c8f..abe4cee 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3274,6 +3274,19 @@ static int hclge_reset_prepare_down(struct hclge_dev
*hdev)
return ret;
}
+static void hclge_reset_handshake(struct hclge_dev *hdev, bool enable)
+{
+ u32 reg_val;
+
+ reg_val = hclge_read_dev(>hw, HCLGE_NIC_CSQ_DEPTH_REG);
+ if (enable)
+ reg_val |= HCLGE_NIC_SW_RST_RDY;
+ else
+ reg_val &= ~HCLGE_NIC_SW_RST_RDY;
+
+ hclge_write_dev(>hw, HCLGE_NIC_CSQ_DEPTH_REG, reg_val);
+}
+
static int hclge_reset_prepare_wait(struct hclge_dev *hdev)
{
#define HCLGE_RESET_SYNC_TIME 100
@@ -3322,8 +3335,7 @@ static int hclge_reset_prepare_wait(struct hclge_dev
*hdev)
/* inform hardware that preparatory work is done */
msleep(HCLGE_RESET_SYNC_TIME);
- hclge_write_dev(>hw, HCLGE_NIC_CSQ_DEPTH_REG,
- HCLGE_NIC_CMQ_ENABLE);
+ hclge_reset_handshake(hdev, true);
dev_info(>pdev->dev, "prepare wait ok\n");
return ret;
@@ -3354,6 +3366,10 @@ static bool hclge_reset_err_handle(struct hclge_dev
*hdev)
}
hclge_clear_reset_cause(hdev);
+
+ /* recover the handshake status when reset fail */
+
[PATCH net-next 00/12] net: hns3: some code optimizations & bugfixes & features
This patch-set includes code optimizations, bugfixes and features for the HNS3 ethernet controller driver. [patch 01/12] adds support for reporting link change event. [patch 02/12] adds handler for NCSI error. [patch 03/12] fixes bug related to debugfs. [patch 04/12] adds a code optimization for setting ring parameters. [patch 05/12 - 09/12] adds some cleanups. [patch 10/12 - 12/12] adds some patches related to reset issue. Guojia Liao (1): net: hns3: rename a member in struct hclge_mac_ethertype_idx_rd_cmd Huazhong Tan (4): net: hns3: add handler for NCSI error mailbox net: hns3: fix some reset handshake issue net: hns3: clear reset interrupt status in hclge_irq_handle() net: hns3: activate reset timer when calling reset_event Jian Shen (3): net: hns3: add link change event report net: hns3: refine for set ring parameters net: hns3: remove unnecessary variable in hclge_get_mac_vlan_cmd_status() Weihang Li (1): net: hns3: simplify hclge_cmd_query_error() Yufeng Mo (1): net: hns3: do not query unsupported commands in debugfs Yunsheng Lin (2): net: hns3: minor cleanup in hns3_clean_rx_ring net: hns3: minior error handling change for hclge_tm_schd_info_init drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h| 2 + drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 22 ++-- drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 3 +- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 88 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 33 - .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 25 +++- .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 76 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 19 +-- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 137 +++-- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 8 ++ .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 45 +++ .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 18 +-- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 4 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 7 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 60 ++--- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 3 + 16 files changed, 397 insertions(+), 153 deletions(-) -- 2.7.4
[PATCH net-next 02/12] net: hns3: add handler for NCSI error mailbox
When NCSI has HW error, the IMP will report this error to the driver
by sending a mailbox. After received this message, the driver should
assert a global reset to fix this kind of HW error.
Signed-off-by: Huazhong Tan
Reviewed-by: Peng Li
---
drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h| 1 +
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 1 +
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 1 +
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 12
4 files changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
index 1564be5..f8a87f8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
@@ -48,6 +48,7 @@ enum HCLGE_MBX_OPCODE {
HCLGE_MBX_GET_VF_FLR_STATUS = 200, /* (M7 -> PF) get vf reset status */
HCLGE_MBX_PUSH_LINK_STATUS, /* (M7 -> PF) get port link status */
+ HCLGE_MBX_NCSI_ERROR, /* (M7 -> PF) receive a NCSI error */
};
/* below are per-VF mac-vlan subcodes */
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 538d101..c20b972 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -394,6 +394,7 @@ static int hclge_firmware_compat_config(struct hclge_dev
*hdev)
req = (struct hclge_firmware_compat_cmd *)desc.data;
hnae3_set_bit(compat, HCLGE_LINK_EVENT_REPORT_EN_B, 1);
+ hnae3_set_bit(compat, HCLGE_NCSI_ERROR_REPORT_EN_B, 1);
req->compat = cpu_to_le32(compat);
return hclge_cmd_send(>hw, , 1);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 743c9f4..070b9dd 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -1011,6 +1011,7 @@ struct hclge_query_ppu_pf_other_int_dfx_cmd {
};
#define HCLGE_LINK_EVENT_REPORT_EN_B 0
+#define HCLGE_NCSI_ERROR_REPORT_EN_B 1
struct hclge_firmware_compat_cmd {
__le32 compat;
u8 rsv[20];
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index 87de32d..5a7221e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -582,6 +582,15 @@ static bool hclge_cmd_crq_empty(struct hclge_hw *hw)
return tail == hw->cmq.crq.next_to_use;
}
+static void hclge_handle_ncsi_error(struct hclge_dev *hdev)
+{
+ struct hnae3_ae_dev *ae_dev = hdev->ae_dev;
+
+ ae_dev->ops->set_default_reset_request(ae_dev, HNAE3_GLOBAL_RESET);
+ dev_warn(>pdev->dev, "requesting reset due to NCSI error\n");
+ ae_dev->ops->reset_event(hdev->pdev, NULL);
+}
+
void hclge_mbx_handler(struct hclge_dev *hdev)
{
struct hclge_cmq_ring *crq = >hw.cmq.crq;
@@ -740,6 +749,9 @@ void hclge_mbx_handler(struct hclge_dev *hdev)
case HCLGE_MBX_PUSH_LINK_STATUS:
hclge_handle_link_change_event(hdev, req);
break;
+ case HCLGE_MBX_NCSI_ERROR:
+ hclge_handle_ncsi_error(hdev);
+ break;
default:
dev_err(>pdev->dev,
"un-supported mailbox message, code = %d\n",
--
2.7.4
[PATCH net-next 01/12] net: hns3: add link change event report
From: Jian Shen
Previously, PF updates link status per second. For some scenario,
it requires link down event being reported more quickly.
To solve it, firmware pushes the link change event to PF with
CMDQ message, and driver updates the link status directly.
Signed-off-by: Jian Shen
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h| 1 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 25
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 7 +
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 9 +++---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 8 ++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 33 ++
6 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
index 75329ab..1564be5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
@@ -47,6 +47,7 @@ enum HCLGE_MBX_OPCODE {
HCLGE_MBX_GET_MEDIA_TYPE, /* (VF -> PF) get media type */
HCLGE_MBX_GET_VF_FLR_STATUS = 200, /* (M7 -> PF) get vf reset status */
+ HCLGE_MBX_PUSH_LINK_STATUS, /* (M7 -> PF) get port link status */
};
/* below are per-VF mac-vlan subcodes */
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index d9858f2..538d101 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -383,6 +383,22 @@ int hclge_cmd_queue_init(struct hclge_dev *hdev)
return ret;
}
+static int hclge_firmware_compat_config(struct hclge_dev *hdev)
+{
+ struct hclge_firmware_compat_cmd *req;
+ struct hclge_desc desc;
+ u32 compat = 0;
+
+ hclge_cmd_setup_basic_desc(, HCLGE_OPC_M7_COMPAT_CFG, false);
+
+ req = (struct hclge_firmware_compat_cmd *)desc.data;
+
+ hnae3_set_bit(compat, HCLGE_LINK_EVENT_REPORT_EN_B, 1);
+ req->compat = cpu_to_le32(compat);
+
+ return hclge_cmd_send(>hw, , 1);
+}
+
int hclge_cmd_init(struct hclge_dev *hdev)
{
u32 version;
@@ -429,6 +445,15 @@ int hclge_cmd_init(struct hclge_dev *hdev)
hnae3_get_field(version, HNAE3_FW_VERSION_BYTE0_MASK,
HNAE3_FW_VERSION_BYTE0_SHIFT));
+ /* ask the firmware to enable some features, driver can work without
+* it.
+*/
+ ret = hclge_firmware_compat_config(hdev);
+ if (ret)
+ dev_warn(>pdev->dev,
+"Firmware compatible features not enabled(%d).\n",
+ret);
+
return 0;
err_cmd_init:
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 96840d8..743c9f4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -257,6 +257,7 @@ enum hclge_opcode_type {
/* M7 stats command */
HCLGE_OPC_M7_STATS_BD = 0x7012,
HCLGE_OPC_M7_STATS_INFO = 0x7013,
+ HCLGE_OPC_M7_COMPAT_CFG = 0x701A,
/* SFP command */
HCLGE_OPC_GET_SFP_INFO = 0x7104,
@@ -1009,6 +1010,12 @@ struct hclge_query_ppu_pf_other_int_dfx_cmd {
u8 rsv[4];
};
+#define HCLGE_LINK_EVENT_REPORT_EN_B 0
+struct hclge_firmware_compat_cmd {
+ __le32 compat;
+ u8 rsv[20];
+};
+
int hclge_cmd_init(struct hclge_dev *hdev);
static inline void hclge_write_reg(void __iomem *base, u32 reg, u32 value)
{
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 4138780..855b65e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2517,7 +2517,7 @@ static void hclge_reset_task_schedule(struct hclge_dev
*hdev)
>rst_service_task);
}
-static void hclge_task_schedule(struct hclge_dev *hdev)
+void hclge_task_schedule(struct hclge_dev *hdev, unsigned long delay_time)
{
if (!test_bit(HCLGE_STATE_DOWN, >state) &&
!test_bit(HCLGE_STATE_REMOVING, >state) &&
@@ -2526,7 +2526,7 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
hdev->fd_arfs_expire_timer++;
mod_delayed_work_on(cpumask_first(>affinity_mask),
system_wq, >service_task,
- round_jiffies_relative(HZ));
+ delay_time);
}
}
@@ -3636,7 +3636,7 @@ static void hclge_service_task(struct work_struct *work)
hdev->fd_arfs_expire_timer = 0;
}
- hclge_task_schedule(hdev);
+
[PATCH net-next 03/12] net: hns3: do not query unsupported commands in debugfs
From: Yufeng Mo
Some commands are not supported on DCB-unsupported ports.
This patch distinguishes these commands and does not query
unsupported commands in debugfs.
This patch also fix an error in the dump "qos buf cfg"
command in debugfs.
Fixes: 2849d4e7a1be ("net: hns3: Add "tc config" info query function")
Fixes: 7d9d7f8864ba ("net: hns3: Add "qos buffer" config info query function")
Signed-off-by: Yufeng Mo
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 70 ++
1 file changed, 46 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index ab625c7..e987d18 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -325,6 +325,12 @@ static void hclge_dbg_dump_tc(struct hclge_dev *hdev)
struct hclge_desc desc;
int i, ret;
+ if (!hnae3_dev_dcb_supported(hdev)) {
+ dev_info(>pdev->dev,
+"Only DCB-supported dev supports tc\n");
+ return;
+ }
+
hclge_cmd_setup_basic_desc(, HCLGE_OPC_ETS_TC_WEIGHT, true);
ret = hclge_cmd_send(>hw, , 1);
@@ -409,6 +415,12 @@ static void hclge_dbg_dump_tm_pg(struct hclge_dev *hdev)
dev_info(>pdev->dev, "QS_SCH qs_id: %u\n", desc.data[0]);
+ if (!hnae3_dev_dcb_supported(hdev)) {
+ dev_info(>pdev->dev,
+"Only DCB-supported dev supports tm mapping\n");
+ return;
+ }
+
cmd = HCLGE_OPC_TM_BP_TO_QSET_MAPPING;
hclge_cmd_setup_basic_desc(, cmd, true);
ret = hclge_cmd_send(>hw, , 1);
@@ -590,6 +602,12 @@ static void hclge_dbg_dump_tm_map(struct hclge_dev *hdev,
dev_info(>pdev->dev, "%04d | %04d| %02d | %02d\n",
queue_id, qset_id, pri_id, tc_id);
+ if (!hnae3_dev_dcb_supported(hdev)) {
+ dev_info(>pdev->dev,
+"Only DCB-supported dev supports tm mapping\n");
+ return;
+ }
+
cmd = HCLGE_OPC_TM_BP_TO_QSET_MAPPING;
bp_to_qs_map_cmd = (struct hclge_bp_to_qs_map_cmd *)desc.data;
for (group_id = 0; group_id < 32; group_id++) {
@@ -715,6 +733,34 @@ static void hclge_dbg_dump_qos_buf_cfg(struct hclge_dev
*hdev)
dev_info(>pdev->dev, "rx_share_buf: 0x%x\n",
rx_buf_cmd->shared_buf);
+ cmd = HCLGE_OPC_RX_COM_WL_ALLOC;
+ hclge_cmd_setup_basic_desc(desc, cmd, true);
+ ret = hclge_cmd_send(>hw, desc, 1);
+ if (ret)
+ goto err_qos_cmd_send;
+
+ rx_com_wl = (struct hclge_rx_com_wl *)desc[0].data;
+ dev_info(>pdev->dev, "\n");
+ dev_info(>pdev->dev, "rx_com_wl: high: 0x%x, low: 0x%x\n",
+rx_com_wl->com_wl.high, rx_com_wl->com_wl.low);
+
+ cmd = HCLGE_OPC_RX_GBL_PKT_CNT;
+ hclge_cmd_setup_basic_desc(desc, cmd, true);
+ ret = hclge_cmd_send(>hw, desc, 1);
+ if (ret)
+ goto err_qos_cmd_send;
+
+ rx_packet_cnt = (struct hclge_rx_com_wl *)desc[0].data;
+ dev_info(>pdev->dev,
+"rx_global_packet_cnt: high: 0x%x, low: 0x%x\n",
+rx_packet_cnt->com_wl.high, rx_packet_cnt->com_wl.low);
+ dev_info(>pdev->dev, "\n");
+
+ if (!hnae3_dev_dcb_supported(hdev)) {
+ dev_info(>pdev->dev,
+"Only DCB-supported dev supports rx priv wl\n");
+ return;
+ }
cmd = HCLGE_OPC_RX_PRIV_WL_ALLOC;
hclge_cmd_setup_basic_desc([0], cmd, true);
desc[0].flag |= cpu_to_le16(HCLGE_CMD_FLAG_NEXT);
@@ -723,7 +769,6 @@ static void hclge_dbg_dump_qos_buf_cfg(struct hclge_dev
*hdev)
if (ret)
goto err_qos_cmd_send;
- dev_info(>pdev->dev, "\n");
rx_priv_wl = (struct hclge_rx_priv_wl_buf *)desc[0].data;
for (i = 0; i < HCLGE_TC_NUM_ONE_DESC; i++)
dev_info(>pdev->dev,
@@ -758,29 +803,6 @@ static void hclge_dbg_dump_qos_buf_cfg(struct hclge_dev
*hdev)
"rx_com_thrd_tc_%d: high: 0x%x, low: 0x%x\n", i + 4,
rx_com_thrd->com_thrd[i].high,
rx_com_thrd->com_thrd[i].low);
-
- cmd = HCLGE_OPC_RX_COM_WL_ALLOC;
- hclge_cmd_setup_basic_desc(desc, cmd, true);
- ret = hclge_cmd_send(>hw, desc, 1);
- if (ret)
- goto err_qos_cmd_send;
-
- rx_com_wl = (struct hclge_rx_com_wl *)desc[0].data;
- dev_info(>pdev->dev, "\n");
- dev_info(>pdev->dev, "rx_com_wl: high: 0x%x, low: 0x%x\n",
-rx_com_wl->com_wl.high, rx_com_wl->com_wl.low);
-
- cmd = HCLGE_OPC_RX_GBL_PKT_CNT;
- hclge_cmd_setup_basic_desc(desc, cmd, true);
- ret = hclge_cmd_send(>hw, desc, 1);
- if (ret)
-
[PATCH net-next 09/12] net: hns3: rename a member in struct hclge_mac_ethertype_idx_rd_cmd
From: Guojia Liao
The member 'mac_add' defined in hclge_mac_ethertype_idx_rd_cmd
means MAC address, so 'mac_addr' is a better name for it.
Signed-off-by: Guojia Liao
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 070b9dd..cfa77dd 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -828,7 +828,7 @@ struct hclge_mac_ethertype_idx_rd_cmd {
u8 flags;
u8 resp_code;
__le16 vlan_tag;
- u8 mac_add[6];
+ u8 mac_addr[6];
__le16 index;
__le16 ethter_type;
__le16 egress_port;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index e987d18..f16bfc6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -847,9 +847,9 @@ static void hclge_dbg_dump_mng_table(struct hclge_dev *hdev)
memset(printf_buf, 0, HCLGE_DBG_BUF_LEN);
snprintf(printf_buf, HCLGE_DBG_BUF_LEN,
"%02u |%02x:%02x:%02x:%02x:%02x:%02x|",
-req0->index, req0->mac_add[0], req0->mac_add[1],
-req0->mac_add[2], req0->mac_add[3], req0->mac_add[4],
-req0->mac_add[5]);
+req0->index, req0->mac_addr[0], req0->mac_addr[1],
+req0->mac_addr[2], req0->mac_addr[3],
+req0->mac_addr[4], req0->mac_addr[5]);
snprintf(printf_buf + strlen(printf_buf),
HCLGE_DBG_BUF_LEN - strlen(printf_buf),
--
2.7.4
[PATCH net-next 07/12] net: hns3: minior error handling change for hclge_tm_schd_info_init
From: Yunsheng Lin
When hclge_tm_schd_info_update calls hclge_tm_schd_info_init to
initialize the schedule info, hdev->tm_info.num_pg and
hdev->tx_sch_mode is not changed, which makes the checking in
hclge_tm_schd_info_init unnecessary.
So this patch moves the hdev->tm_info.num_pg and hdev->tx_sch_mode
checking into hclge_tm_schd_init and changes the return type of
hclge_tm_schd_info_init from int to void.
Signed-off-by: Yunsheng Lin
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
index 3f41fa2..f30d112 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c
@@ -650,12 +650,8 @@ static void hclge_pfc_info_init(struct hclge_dev *hdev)
}
}
-static int hclge_tm_schd_info_init(struct hclge_dev *hdev)
+static void hclge_tm_schd_info_init(struct hclge_dev *hdev)
{
- if ((hdev->tx_sch_mode != HCLGE_FLAG_TC_BASE_SCH_MODE) &&
- (hdev->tm_info.num_pg != 1))
- return -EINVAL;
-
hclge_tm_pg_info_init(hdev);
hclge_tm_tc_info_init(hdev);
@@ -663,8 +659,6 @@ static int hclge_tm_schd_info_init(struct hclge_dev *hdev)
hclge_tm_vport_info_update(hdev);
hclge_pfc_info_init(hdev);
-
- return 0;
}
static int hclge_tm_pg_to_pri_map(struct hclge_dev *hdev)
@@ -1428,15 +1422,15 @@ int hclge_tm_init_hw(struct hclge_dev *hdev, bool init)
int hclge_tm_schd_init(struct hclge_dev *hdev)
{
- int ret;
-
/* fc_mode is HCLGE_FC_FULL on reset */
hdev->tm_info.fc_mode = HCLGE_FC_FULL;
hdev->fc_mode_last_time = hdev->tm_info.fc_mode;
- ret = hclge_tm_schd_info_init(hdev);
- if (ret)
- return ret;
+ if (hdev->tx_sch_mode != HCLGE_FLAG_TC_BASE_SCH_MODE &&
+ hdev->tm_info.num_pg != 1)
+ return -EINVAL;
+
+ hclge_tm_schd_info_init(hdev);
return hclge_tm_init_hw(hdev, true);
}
--
2.7.4
[PATCH net-next 08/12] net: hns3: simplify hclge_cmd_query_error()
From: Weihang Li
The 4th and 5th parameter of hclge_cmd_query_error is useless, so this
patch removes them.
Signed-off-by: Weihang Li
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c| 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 0a72438..05a4cdb 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -652,16 +652,11 @@ static void hclge_log_error(struct device *dev, char *reg,
* @desc: descriptor for describing the command
* @cmd: command opcode
* @flag: flag for extended command structure
- * @w_num: offset for setting the read interrupt type.
- * @int_type: select which type of the interrupt for which the error
- * info will be read(RAS-CE/RAS-NFE/RAS-FE etc).
*
* This function query the error info from hw register/s using command
*/
static int hclge_cmd_query_error(struct hclge_dev *hdev,
-struct hclge_desc *desc, u32 cmd,
-u16 flag, u8 w_num,
-enum hclge_err_int_type int_type)
+struct hclge_desc *desc, u32 cmd, u16 flag)
{
struct device *dev = >pdev->dev;
int desc_num = 1;
@@ -673,8 +668,6 @@ static int hclge_cmd_query_error(struct hclge_dev *hdev,
hclge_cmd_setup_basic_desc([1], cmd, true);
desc_num = 2;
}
- if (w_num)
- desc[0].data[w_num] = cpu_to_le32(int_type);
ret = hclge_cmd_send(>hw, [0], desc_num);
if (ret)
@@ -872,8 +865,7 @@ static int hclge_config_tm_hw_err_int(struct hclge_dev
*hdev, bool en)
}
/* configure TM QCN hw errors */
- ret = hclge_cmd_query_error(hdev, , HCLGE_TM_QCN_MEM_INT_CFG,
- 0, 0, 0);
+ ret = hclge_cmd_query_error(hdev, , HCLGE_TM_QCN_MEM_INT_CFG, 0);
if (ret) {
dev_err(dev, "fail(%d) to read TM QCN CFG status\n", ret);
return ret;
@@ -1410,7 +1402,7 @@ static int hclge_log_rocee_ecc_error(struct hclge_dev
*hdev)
ret = hclge_cmd_query_error(hdev, [0],
HCLGE_QUERY_ROCEE_ECC_RAS_INFO_CMD,
- HCLGE_CMD_FLAG_NEXT, 0, 0);
+ HCLGE_CMD_FLAG_NEXT);
if (ret) {
dev_err(dev, "failed(%d) to query ROCEE ECC error sts\n", ret);
return ret;
@@ -1434,7 +1426,7 @@ static int hclge_log_rocee_ovf_error(struct hclge_dev
*hdev)
/* read overflow error status */
ret = hclge_cmd_query_error(hdev, [0], HCLGE_ROCEE_PF_RAS_INT_CMD,
- 0, 0, 0);
+ 0);
if (ret) {
dev_err(dev, "failed(%d) to query ROCEE OVF error sts\n", ret);
return ret;
@@ -1483,8 +1475,7 @@ hclge_log_and_clear_rocee_ras_error(struct hclge_dev
*hdev)
/* read RAS error interrupt status */
ret = hclge_cmd_query_error(hdev, [0],
- HCLGE_QUERY_CLEAR_ROCEE_RAS_INT,
- 0, 0, 0);
+ HCLGE_QUERY_CLEAR_ROCEE_RAS_INT, 0);
if (ret) {
dev_err(dev, "failed(%d) to query ROCEE RAS INT SRC\n", ret);
/* reset everything for now */
--
2.7.4
[PATCH net-next 06/12] net: hns3: minor cleanup in hns3_clean_rx_ring
From: Yunsheng Lin
The unused_count variable is used to indicate how many
RX BD need attaching new buffer in hns3_clean_rx_ring,
and the clean_count variable has the similar meaning.
This patch removes the clean_count variable and use
unused_count to uniformly indicate the RX BD that need
attaching new buffer.
This patch also clean up some coding style related to
variable assignment in hns3_clean_rx_ring.
Signed-off-by: Yunsheng Lin
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 79973a0..ed05fb9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2909,24 +2909,22 @@ int hns3_clean_rx_ring(struct hns3_enet_ring *ring, int
budget,
void (*rx_fn)(struct hns3_enet_ring *, struct sk_buff *))
{
#define RCB_NOF_ALLOC_RX_BUFF_ONCE 16
- int recv_pkts, recv_bds, clean_count, err;
int unused_count = hns3_desc_unused(ring);
struct sk_buff *skb = ring->skb;
- int num;
+ int recv_pkts = 0;
+ int recv_bds = 0;
+ int err, num;
num = readl_relaxed(ring->tqp->io_base + HNS3_RING_RX_RING_FBDNUM_REG);
rmb(); /* Make sure num taken effect before the other data is touched */
- recv_pkts = 0, recv_bds = 0, clean_count = 0;
num -= unused_count;
unused_count -= ring->pending_buf;
while (recv_pkts < budget && recv_bds < num) {
/* Reuse or realloc buffers */
- if (clean_count + unused_count >= RCB_NOF_ALLOC_RX_BUFF_ONCE) {
- hns3_nic_alloc_rx_buffers(ring,
- clean_count + unused_count);
- clean_count = 0;
+ if (unused_count >= RCB_NOF_ALLOC_RX_BUFF_ONCE) {
+ hns3_nic_alloc_rx_buffers(ring, unused_count);
unused_count = hns3_desc_unused(ring) -
ring->pending_buf;
}
@@ -2940,7 +2938,7 @@ int hns3_clean_rx_ring(struct hns3_enet_ring *ring, int
budget,
goto out;
} else if (unlikely(err)) { /* Do jump the err */
recv_bds += ring->pending_buf;
- clean_count += ring->pending_buf;
+ unused_count += ring->pending_buf;
ring->skb = NULL;
ring->pending_buf = 0;
continue;
@@ -2948,7 +2946,7 @@ int hns3_clean_rx_ring(struct hns3_enet_ring *ring, int
budget,
rx_fn(ring, skb);
recv_bds += ring->pending_buf;
- clean_count += ring->pending_buf;
+ unused_count += ring->pending_buf;
ring->skb = NULL;
ring->pending_buf = 0;
@@ -2957,8 +2955,8 @@ int hns3_clean_rx_ring(struct hns3_enet_ring *ring, int
budget,
out:
/* Make all data has been write before submit */
- if (clean_count + unused_count > 0)
- hns3_nic_alloc_rx_buffers(ring, clean_count + unused_count);
+ if (unused_count > 0)
+ hns3_nic_alloc_rx_buffers(ring, unused_count);
return recv_pkts;
}
--
2.7.4
[PATCH net-next 04/12] net: hns3: refine for set ring parameters
From: Jian Shen
Previously, when changing the ring parameters, we free the old
ring resources firstly, and then setup the new ring resources.
In some case of an memory allocation fail, there will be no
resources to use. This patch refines it by setup new ring
resources and free the old ring resources in order.
Also reduce the max ring BD number to 32760 according to UM.
Signed-off-by: Jian Shen
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 3 +-
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 88 +++---
3 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index d2df42d..79973a0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3588,7 +3588,7 @@ static int hns3_alloc_ring_memory(struct hns3_enet_ring
*ring)
return ret;
}
-static void hns3_fini_ring(struct hns3_enet_ring *ring)
+void hns3_fini_ring(struct hns3_enet_ring *ring)
{
hns3_free_desc(ring);
devm_kfree(ring_to_dev(ring), ring->desc_cb);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 1a17856..0a970f5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -75,7 +75,7 @@ enum hns3_nic_state {
#define HNS3_TX_TIMEOUT (5 * HZ)
#define HNS3_RING_NAME_LEN 16
#define HNS3_BUFFER_SIZE_2048 2048
-#define HNS3_RING_MAX_PENDING 32768
+#define HNS3_RING_MAX_PENDING 32760
#define HNS3_RING_MIN_PENDING 24
#define HNS3_RING_BD_MULTIPLE 8
/* max frame size of mac */
@@ -642,6 +642,7 @@ void hns3_clean_tx_ring(struct hns3_enet_ring *ring);
int hns3_init_all_ring(struct hns3_nic_priv *priv);
int hns3_uninit_all_ring(struct hns3_nic_priv *priv);
int hns3_nic_reset_all_ring(struct hnae3_handle *h);
+void hns3_fini_ring(struct hns3_enet_ring *ring);
netdev_tx_t hns3_nic_net_xmit(struct sk_buff *skb, struct net_device *netdev);
bool hns3_is_phys_func(struct pci_dev *pdev);
int hns3_clean_rx_ring(
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index fe0f82a..02f46c7 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -867,8 +867,8 @@ static int hns3_get_rxnfc(struct net_device *netdev,
}
}
-static int hns3_change_all_ring_bd_num(struct hns3_nic_priv *priv,
- u32 tx_desc_num, u32 rx_desc_num)
+static void hns3_change_all_ring_bd_num(struct hns3_nic_priv *priv,
+ u32 tx_desc_num, u32 rx_desc_num)
{
struct hnae3_handle *h = priv->ae_handle;
int i;
@@ -881,21 +881,29 @@ static int hns3_change_all_ring_bd_num(struct
hns3_nic_priv *priv,
priv->ring_data[i + h->kinfo.num_tqps].ring->desc_num =
rx_desc_num;
}
-
- return hns3_init_all_ring(priv);
}
-static int hns3_set_ringparam(struct net_device *ndev,
- struct ethtool_ringparam *param)
+static struct hns3_enet_ring *hns3_backup_ringparam(struct hns3_nic_priv *priv)
{
- struct hns3_nic_priv *priv = netdev_priv(ndev);
- struct hnae3_handle *h = priv->ae_handle;
- bool if_running = netif_running(ndev);
- u32 old_tx_desc_num, new_tx_desc_num;
- u32 old_rx_desc_num, new_rx_desc_num;
- int queue_num = h->kinfo.num_tqps;
- int ret;
+ struct hnae3_handle *handle = priv->ae_handle;
+ struct hns3_enet_ring *tmp_rings;
+ int i;
+ tmp_rings = kcalloc(handle->kinfo.num_tqps * 2,
+ sizeof(struct hns3_enet_ring), GFP_KERNEL);
+ if (!tmp_rings)
+ return NULL;
+
+ for (i = 0; i < handle->kinfo.num_tqps * 2; i++)
+ memcpy(_rings[i], priv->ring_data[i].ring,
+ sizeof(struct hns3_enet_ring));
+
+ return tmp_rings;
+}
+
+static int hns3_check_ringparam(struct net_device *ndev,
+ struct ethtool_ringparam *param)
+{
if (hns3_nic_resetting(ndev))
return -EBUSY;
@@ -911,6 +919,25 @@ static int hns3_set_ringparam(struct net_device *ndev,
return -EINVAL;
}
+ return 0;
+}
+
+static int hns3_set_ringparam(struct net_device *ndev,
+ struct ethtool_ringparam *param)
+{
+ struct hns3_nic_priv *priv = netdev_priv(ndev);
+ struct hnae3_handle *h = priv->ae_handle;
+ struct hns3_enet_ring *tmp_rings;
+ bool if_running = netif_running(ndev);
+
[PATCH net-next 12/12] net: hns3: activate reset timer when calling reset_event
When calling hclge_reset_event() within HCLGE_RESET_INTERVAL,
it returns directly now. If no one call it again, then the
error which needs a reset to fix it can not be fixed.
So this patch activates the reset timer for this case, and
adds checking in the end of the reset procedure to make this
error fixed earlier.
Signed-off-by: Huazhong Tan
Reviewed-by: Peng Li
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index c4841c3..b7399f5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3517,7 +3517,15 @@ static void hclge_reset(struct hclge_dev *hdev)
hdev->reset_fail_cnt = 0;
hdev->rst_stats.reset_done_cnt++;
ae_dev->reset_type = HNAE3_NONE_RESET;
- del_timer(>reset_timer);
+
+ /* if default_reset_request has a higher level reset request,
+* it should be handled as soon as possible. since some errors
+* need this kind of reset to fix.
+*/
+ hdev->reset_level = hclge_get_reset_level(ae_dev,
+ >default_reset_request);
+ if (hdev->reset_level != HNAE3_NONE_RESET)
+ set_bit(hdev->reset_level, >reset_request);
return;
@@ -3552,9 +3560,10 @@ static void hclge_reset_event(struct pci_dev *pdev,
struct hnae3_handle *handle)
handle = >vport[0].nic;
if (time_before(jiffies, (hdev->last_reset_time +
- HCLGE_RESET_INTERVAL)))
+ HCLGE_RESET_INTERVAL))) {
+ mod_timer(>reset_timer, jiffies + HCLGE_RESET_INTERVAL);
return;
- else if (hdev->default_reset_request)
+ } else if (hdev->default_reset_request)
hdev->reset_level =
hclge_get_reset_level(ae_dev,
>default_reset_request);
@@ -3584,6 +3593,12 @@ static void hclge_reset_timer(struct timer_list *t)
{
struct hclge_dev *hdev = from_timer(hdev, t, reset_timer);
+ /* if default_reset_request has no value, it means that this reset
+* request has already be handled, so just return here
+*/
+ if (!hdev->default_reset_request)
+ return;
+
dev_info(>pdev->dev,
"triggering reset in reset timer\n");
hclge_reset_event(hdev->pdev, NULL);
--
2.7.4
[PATCH net-next 11/12] net: hns3: clear reset interrupt status in hclge_irq_handle()
Currently, the reset interrupt is cleared in the reset task, which
is too late. Since, when the hardware finish the previous reset,
it can begin to do a new global/IMP reset, if this new coming reset
type is same as the previous one, the driver will clear them together,
then driver can not get that there is another reset, but the hardware
still wait for the driver to deal with the second one.
So this patch clears PF's reset interrupt status in the
hclge_irq_handle(), the hardware waits for handshaking from
driver before doing reset, so the driver and hardware deal with reset
one by one.
BTW, when VF doing global/IMP reset, it reads PF's reset interrupt
register to get that whether PF driver's re-initialization is done,
since VF's re-initialization should be done after PF's. So we add
a new command and a register bit to do that. When VF receive reset
interrupt, it sets up this bit, and PF finishes re-initialization
send command to clear this bit, then VF do re-initialization.
Fixes: 4ed340ab8f49 ("net: hns3: Add reset process in hclge_main")
Signed-off-by: Huazhong Tan
Reviewed-by: Yunsheng Lin
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 8 +
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 34 --
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 29 +++---
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 3 ++
4 files changed, 61 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 63cf9a7..dade20a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -86,6 +86,7 @@ enum hclge_opcode_type {
HCLGE_OPC_QUERY_PF_RSRC = 0x0023,
HCLGE_OPC_QUERY_VF_RSRC = 0x0024,
HCLGE_OPC_GET_CFG_PARAM = 0x0025,
+ HCLGE_OPC_PF_RST_DONE = 0x0026,
HCLGE_OPC_STATS_64_BIT = 0x0030,
HCLGE_OPC_STATS_32_BIT = 0x0031,
@@ -878,6 +879,13 @@ struct hclge_reset_cmd {
u8 rsv[22];
};
+#define HCLGE_PF_RESET_DONE_BITBIT(0)
+
+struct hclge_pf_rst_done_cmd {
+ u8 pf_rst_done;
+ u8 rsv[23];
+};
+
#define HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B BIT(0)
#define HCLGE_CMD_SERDES_PARALLEL_INNER_LOOP_B BIT(2)
#define HCLGE_CMD_SERDES_DONE_BBIT(0)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index abe4cee..c4841c3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2876,10 +2876,15 @@ static irqreturn_t hclge_misc_irq_handle(int irq, void
*data)
break;
}
- /* clear the source of interrupt if it is not cause by reset */
+ hclge_clear_event_cause(hdev, event_cause, clearval);
+
+ /* Enable interrupt if it is not cause by reset. And when
+* clearval equal to 0, it means interrupt status may be
+* cleared by hardware before driver reads status register.
+* For this case, vector0 interrupt also should be enabled.
+*/
if (!clearval ||
event_cause == HCLGE_VECTOR0_EVENT_MBX) {
- hclge_clear_event_cause(hdev, event_cause, clearval);
hclge_enable_vector(>misc_vector, true);
}
@@ -3253,7 +3258,13 @@ static void hclge_clear_reset_cause(struct hclge_dev
*hdev)
if (!clearval)
return;
- hclge_write_dev(>hw, HCLGE_MISC_RESET_STS_REG, clearval);
+ /* For revision 0x20, the reset interrupt source
+* can only be cleared after hardware reset done
+*/
+ if (hdev->pdev->revision == 0x20)
+ hclge_write_dev(>hw, HCLGE_MISC_RESET_STS_REG,
+ clearval);
+
hclge_enable_vector(>misc_vector, true);
}
@@ -3374,6 +3385,18 @@ static bool hclge_reset_err_handle(struct hclge_dev
*hdev)
return false;
}
+static int hclge_set_rst_done(struct hclge_dev *hdev)
+{
+ struct hclge_pf_rst_done_cmd *req;
+ struct hclge_desc desc;
+
+ req = (struct hclge_pf_rst_done_cmd *)desc.data;
+ hclge_cmd_setup_basic_desc(, HCLGE_OPC_PF_RST_DONE, false);
+ req->pf_rst_done |= HCLGE_PF_RESET_DONE_BIT;
+
+ return hclge_cmd_send(>hw, , 1);
+}
+
static int hclge_reset_prepare_up(struct hclge_dev *hdev)
{
int ret = 0;
@@ -3384,6 +3407,11 @@ static int hclge_reset_prepare_up(struct hclge_dev *hdev)
case HNAE3_FLR_RESET:
ret = hclge_set_all_vf_rst(hdev, false);
break;
+ case HNAE3_GLOBAL_RESET:
+ /* fall through */
+ case HNAE3_IMP_RESET:
+ ret = hclge_set_rst_done(hdev);
+ break;
default:
break;
}
diff
Re: [PATCH net-next v2 4/4] net: ftgmac100: Select ASPEED MDIO driver for the AST2600
On Wed, Jul 31, 2019 at 03:09:59PM +0930, Andrew Jeffery wrote: > Ensures we can talk to a PHY via MDIO on the AST2600, as the MDIO > controller is now separate from the MAC. > > Signed-off-by: Andrew Jeffery Reviewed-by: Andrew Lunn Andrew
Re: [PATCH net-next v2 3/4] net: ftgmac100: Add support for DT phy-handle property
On Wed, Jul 31, 2019 at 03:09:58PM +0930, Andrew Jeffery wrote: > phy-handle is necessary for the AST2600 which separates the MDIO > controllers from the MAC. > > I've tried to minimise the intrusion of supporting the AST2600 to the > FTGMAC100 by leaving in place the existing MDIO support for the embedded > MDIO interface. The AST2400 and AST2500 continue to be supported this > way, as it avoids breaking/reworking existing devicetrees. > > The AST2600 support by contrast requires the presence of the phy-handle > property in the MAC devicetree node to specify the appropriate PHY to > associate with the MAC. In the event that someone wants to specify the > MDIO bus topology under the MAC node on an AST2400 or AST2500, the > current auto-probe approach is done conditional on the absence of an > "mdio" child node of the MAC. > > Signed-off-by: Andrew Jeffery Reviewed-by: Andrew Lunn Andrew
Re: [PATCH net-next v2 2/4] net: phy: Add mdio-aspeed
On Wed, Jul 31, 2019 at 03:09:57PM +0930, Andrew Jeffery wrote: > The AST2600 design separates the MDIO controllers from the MAC, which is > where they were placed in the AST2400 and AST2500. Further, the register > interface is reworked again, so now we have three possible different > interface implementations, however this driver only supports the > interface provided by the AST2600. The AST2400 and AST2500 will continue > to be supported by the MDIO support embedded in the FTGMAC100 driver. > > The hardware supports both C22 and C45 mode, but for the moment only C22 > support is implemented. > > Signed-off-by: Andrew Jeffery Reviewed-by: Andrew Lunn Andrew
Re: [PATCH net-next v2 6/6] net: dsa: mv88e6xxx: add PTP support for MV88E6250 family
On Wed, Jul 31, 2019 at 10:23:51AM +0200, Hubert Feurstein wrote: > This adds PTP support for the MV88E6250 family. > > Signed-off-by: Hubert Feurstein Reviewed-by: Andrew Lunn Andrew
Re: [PATCH net-next v2 5/6] net: dsa: mv88e6xxx: order ptp structs numerically ascending
On Wed, Jul 31, 2019 at 10:23:50AM +0200, Hubert Feurstein wrote: > As it is done for all the other structs within this driver. > > Signed-off-by: Hubert Feurstein Reviewed-by: Andrew Lunn Andrew
[PATCH v3 06/26] drm: kirin: Remove out_format from ade_crtc
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch removes the out_format
field in the struct ade_crtc, which was only ever set to
LDI_OUT_RGB_888.
Thus this patch removes the field and instead directly uses
LDI_OUT_RGB_888.
Cc: Rongrong Zou
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Cc: Sam Ravnborg
Reviewed-by: Sam Ravnborg
Signed-off-by: Xu YiPing
[jstultz: reworded commit message]
Signed-off-by: John Stultz
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 756aefd5bcff..73dff21bed6a 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -60,7 +60,6 @@ struct ade_crtc {
struct ade_hw_ctx *ctx;
struct work_struct display_reset_wq;
bool enable;
- u32 out_format;
};
struct ade_plane {
@@ -383,11 +382,10 @@ static irqreturn_t ade_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
-static void ade_display_enable(struct ade_crtc *acrtc)
+static void ade_display_enable(struct ade_hw_ctx *ctx)
{
- struct ade_hw_ctx *ctx = acrtc->ctx;
void __iomem *base = ctx->base;
- u32 out_fmt = acrtc->out_format;
+ u32 out_fmt = LDI_OUT_RGB_888;
/* enable output overlay compositor */
writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY));
@@ -514,7 +512,7 @@ static void ade_crtc_atomic_enable(struct drm_crtc *crtc,
}
ade_set_medianoc_qos(ctx);
- ade_display_enable(acrtc);
+ ade_display_enable(ctx);
ade_dump_regs(ctx->base);
drm_crtc_vblank_on(crtc);
acrtc->enable = true;
@@ -1024,7 +1022,6 @@ static int ade_drm_init(struct platform_device *pdev)
ctx = >ctx;
acrtc = >acrtc;
acrtc->ctx = ctx;
- acrtc->out_format = LDI_OUT_RGB_888;
ret = ade_dts_parse(pdev, ctx);
if (ret)
--
2.17.1
[PATCH v3 05/26] drm: kirin: Remove uncessary parameter indirection
From: Xu YiPing
In a few functions, we pass in a struct ade_crtc, which we only
use to get to the underlying struct ade_hw_ctx.
Thus this patch refactors the functions to just take the
struct ade_hw_ctx directly.
Cc: Rongrong Zou
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Cc: Sam Ravnborg
Reviewed-by: Sam Ravnborg
Signed-off-by: Xu YiPing
[jstultz: reworded commit message]
Signed-off-by: John Stultz
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 9a9e3b688ba3..756aefd5bcff 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -210,11 +210,10 @@ static void ade_set_pix_clk(struct ade_hw_ctx *ctx,
adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
}
-static void ade_ldi_set_mode(struct ade_crtc *acrtc,
+static void ade_ldi_set_mode(struct ade_hw_ctx *ctx,
struct drm_display_mode *mode,
struct drm_display_mode *adj_mode)
{
- struct ade_hw_ctx *ctx = acrtc->ctx;
void __iomem *base = ctx->base;
u32 width = mode->hdisplay;
u32 height = mode->vdisplay;
@@ -301,9 +300,8 @@ static void ade_power_down(struct ade_hw_ctx *ctx)
ctx->power_on = false;
}
-static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
+static void ade_set_medianoc_qos(struct ade_hw_ctx *ctx)
{
- struct ade_hw_ctx *ctx = acrtc->ctx;
struct regmap *map = ctx->noc_regmap;
regmap_update_bits(map, ADE0_QOSGENERATOR_MODE,
@@ -515,7 +513,7 @@ static void ade_crtc_atomic_enable(struct drm_crtc *crtc,
return;
}
- ade_set_medianoc_qos(acrtc);
+ ade_set_medianoc_qos(ctx);
ade_display_enable(acrtc);
ade_dump_regs(ctx->base);
drm_crtc_vblank_on(crtc);
@@ -545,7 +543,7 @@ static void ade_crtc_mode_set_nofb(struct drm_crtc *crtc)
if (!ctx->power_on)
(void)ade_power_up(ctx);
- ade_ldi_set_mode(acrtc, mode, adj_mode);
+ ade_ldi_set_mode(ctx, mode, adj_mode);
}
static void ade_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -558,7 +556,7 @@ static void ade_crtc_atomic_begin(struct drm_crtc *crtc,
if (!ctx->power_on)
(void)ade_power_up(ctx);
- ade_ldi_set_mode(acrtc, mode, adj_mode);
+ ade_ldi_set_mode(ctx, mode, adj_mode);
}
static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
--
2.17.1
Re: [PATCH net-next v2 3/6] net: dsa: mv88e6xxx: introduce invalid_port_mask in mv88e6xxx_info
On Wed, Jul 31, 2019 at 10:23:48AM +0200, Hubert Feurstein wrote: > With this it is possible to mark certain chip ports as invalid. This is > required for example for the MV88E6220 (which is in general a MV88E6250 > with 7 ports) but the ports 2-4 are not routed to pins. > > If a user configures an invalid port, an error is returned. > > Signed-off-by: Hubert Feurstein Reviewed-by: Andrew Lunn Andrew
[PATCH v3 19/26] drm: kirin: Move drm driver to driver data
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the drm_driver
structure to be under device specific driver data.
This will allow us to more easily add support for kirin960
hardware with later patches.
Cc: Rongrong Zou
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Cc: Sam Ravnborg
Reviewed-by: Sam Ravnborg
Signed-off-by: Xu YiPing
[jstultz: Reworded commit message]
Signed-off-by: John Stultz
---
.../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 27 +
.../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38 +--
.../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 1 +
3 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 68efd508d86b..0bc2e538913b 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -1049,6 +1049,32 @@ static const struct drm_mode_config_funcs
ade_mode_config_funcs = {
};
+DEFINE_DRM_GEM_CMA_FOPS(ade_fops);
+
+static struct drm_driver ade_driver = {
+ .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+ DRIVER_ATOMIC,
+ .fops = _fops,
+ .gem_free_object_unlocked = drm_gem_cma_free_object,
+ .gem_vm_ops = _gem_cma_vm_ops,
+ .dumb_create = drm_gem_cma_dumb_create_internal,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_export = drm_gem_prime_export,
+ .gem_prime_import = drm_gem_prime_import,
+ .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+ .gem_prime_vmap = drm_gem_cma_prime_vmap,
+ .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
+ .gem_prime_mmap = drm_gem_cma_prime_mmap,
+
+ .name = "kirin",
+ .desc = "Hisilicon Kirin620 SoC DRM Driver",
+ .date = "20150718",
+ .major = 1,
+ .minor = 0,
+};
+
struct kirin_drm_data ade_driver_data = {
.num_planes = ADE_CH_NUM,
.prim_plane = ADE_CH1,
@@ -1056,6 +1082,7 @@ struct kirin_drm_data ade_driver_data = {
.channel_formats_cnt = ARRAY_SIZE(channel_formats),
.config_max_width = 2048,
.config_max_height = 2048,
+ .driver = _driver,
.crtc_helper_funcs = _crtc_helper_funcs,
.crtc_funcs = _crtc_funcs,
.plane_helper_funcs = _plane_helper_funcs,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 7956d698d368..296661ba300f 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -92,41 +92,6 @@ static int kirin_drm_kms_init(struct drm_device *dev)
return ret;
}
-DEFINE_DRM_GEM_CMA_FOPS(kirin_drm_fops);
-
-static int kirin_gem_cma_dumb_create(struct drm_file *file,
-struct drm_device *dev,
-struct drm_mode_create_dumb *args)
-{
- return drm_gem_cma_dumb_create_internal(file, dev, args);
-}
-
-static struct drm_driver kirin_drm_driver = {
- .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_ATOMIC,
- .fops = _drm_fops,
-
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = _gem_cma_vm_ops,
- .dumb_create= kirin_gem_cma_dumb_create,
-
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_export = drm_gem_prime_export,
- .gem_prime_import = drm_gem_prime_import,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
-
- .name = "kirin",
- .desc = "Hisilicon Kirin SoCs' DRM Driver",
- .date = "20150718",
- .major = 1,
- .minor = 0,
-};
-
static int compare_of(struct device *dev, void *data)
{
return dev->of_node == data;
@@ -134,11 +99,10 @@ static int compare_of(struct device *dev, void *data)
static int kirin_drm_bind(struct device *dev)
{
- struct drm_driver *driver = _drm_driver;
struct drm_device *drm_dev;
int ret;
- drm_dev = drm_dev_alloc(driver, dev);
+ drm_dev = drm_dev_alloc(driver_data->driver, dev);
if (IS_ERR(drm_dev))
return PTR_ERR(drm_dev);
diff --git
Re: [PATCH net-next v2 1/6] net: dsa: mv88e6xxx: add support for MV88E6220
On Wed, Jul 31, 2019 at 10:23:46AM +0200, Hubert Feurstein wrote: > The MV88E6220 is almost the same as MV88E6250 except that the ports 2-4 are > not routed to pins. So the usable ports are 0, 1, 5 and 6. > > Signed-off-by: Hubert Feurstein Reviewed-by: Andrew Lunn Andrew
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/android/vsoc.c: In function 'handle_vsoc_cond_wait':
drivers/staging/android/vsoc.c:440:33: error: passing argument 1 of
'hrtimer_init_sleeper_on_stack' from incompatible pointer type
[-Werror=incompatible-pointer-types]
hrtimer_init_sleeper_on_stack(, CLOCK_MONOTONIC,
^~~
In file included from include/linux/pm.h:16,
from include/linux/device.h:23,
from include/linux/dma-mapping.h:7,
from drivers/staging/android/vsoc.c:19:
include/linux/hrtimer.h:381:67: note: expected 'struct hrtimer_sleeper *' but
argument is of type 'struct hrtimer_sleeper **'
extern void hrtimer_init_sleeper_on_stack(struct hrtimer_sleeper *sl,
^~
Caused by commit
82e18bace3dd ("hrtimer: Consolidate hrtimer_init() + hrtimer_init_sleeper()
calls")
I have added the following patch for today:
From: Stephen Rothwell
Date: Thu, 1 Aug 2019 13:33:44 +1000
Subject: [PATCH] hrtimer: fix typo in hrtimer_init_sleeper_on_stack() conversion
Signed-off-by: Stephen Rothwell
---
drivers/staging/android/vsoc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index 4f7e6c1dce42..1240bb0317d9 100644
--- a/drivers/staging/android/vsoc.c
+++ b/drivers/staging/android/vsoc.c
@@ -437,7 +437,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct
vsoc_cond_wait *arg)
return -EINVAL;
wake_time = ktime_set(arg->wake_time_sec, arg->wake_time_nsec);
- hrtimer_init_sleeper_on_stack(, CLOCK_MONOTONIC,
+ hrtimer_init_sleeper_on_stack(to, CLOCK_MONOTONIC,
HRTIMER_MODE_ABS);
hrtimer_set_expires_range_ns(>timer, wake_time,
current->timer_slack_ns);
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpzOJQWOYR6c.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 3/3] KVM: Fix leak vCPU's VMCS value into other pCPU
On Wed, 31 Jul 2019 at 20:55, Paolo Bonzini wrote: > > On 31/07/19 13:39, Wanpeng Li wrote: > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index ed061d8..12f2c91 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -2506,7 +2506,7 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool > > yield_to_kernel_mode) > > continue; > > if (vcpu == me) > > continue; > > - if (swait_active(>wq) && > > !kvm_arch_vcpu_runnable(vcpu)) > > + if (READ_ONCE(vcpu->preempted) && > > swait_active(>wq)) > > continue; > > if (READ_ONCE(vcpu->preempted) && > > yield_to_kernel_mode && > > !kvm_arch_vcpu_in_kernel(vcpu)) > > > > This cannot work. swait_active means you are waiting, so you cannot be > involuntarily preempted. > > The problem here is simply that kvm_vcpu_has_events is being called > without holding the lock. So kvm_arch_vcpu_runnable is okay, it's the > implementation that's wrong. > > Just rename the existing function to just vcpu_runnable and make a new > arch callback kvm_arch_dy_runnable. kvm_arch_dy_runnable can be > conservative and only returns true for a subset of events, in particular > for x86 it can check: > > - vcpu->arch.pv.pv_unhalted > > - KVM_REQ_NMI or KVM_REQ_SMI or KVM_REQ_EVENT > > - PIR.ON if APICv is set > > Ultimately, all variables accessed in kvm_arch_dy_runnable should be > accessed with READ_ONCE or atomic_read. > > And for all architectures, kvm_vcpu_on_spin should check > list_empty_careful(>async_pf.done) > > It's okay if your patch renames the function in non-x86 architectures, > leaving the fix to maintainers. So, let's CC Marc and Christian since > ARM and s390 have pretty complex kvm_arch_vcpu_runnable as well. Ok, just sent patch to do this. Regards, Wanpeng Li
Re: [PATCH v4 2/2] RISC-V: Implement sparsemem
Hi Logan,
Logan Gunthorpe 於 2019年8月1日 週四 上午1:08寫道：
>
>
>
> On 2019-07-31 12:30 a.m., Greentime Hu wrote:
> > I look this issue more closely.
> > I found it always sets each memblock region to node 0. Does this make sense?
> > I am not sure if I understand this correctly. Do you have any idea for
> > this? Thank you. :)
>
> Yes, I think this is normal. When we talk about memory nodes we're
> talking about NUMA nodes which is unrelated to device tree nodes.
Ok, but it seems the second memblock_region may overwrite the first
memblock_region in for_each_memblock(memory, reg) loop. It always
uses this API to set to node 0.
memblock_set_node(PFN_PHYS(start_pfn),PFN_PHYS(end_pfn - start_pfn),
,0)
> I'm not really sure what's causing the crash. Have you verified it's
> this patch that causes it? Is it related to there being a hole in your
> memory, does it work if you only have one memory node?
>
It works fine if there is only one memory node described in dts.
I think it is related to there being a hole in the device tree script.
I don't actually have a platform with a hole in the memory region, so
I use device tree script to describe it.
The physical address layout will be like this.
2GB-3GB-hole-6GB-7GB
memory@8000 {
device_type = "memory";
reg = <0x0 0x8000 0x0 0x4000>;
};
memory@18000 {
device_type = "memory";
reg = <0x1 0x8000 0x0 0x4000>;
};
Thank you for the quick reply. :)
[PATCH v6 0/2] Add Macronix raw NAND controller driver
Hi, v6 patch including: 1. compatible rename to "mxicy,multi-itfc-v009-nand-morph" 2. remove xxx_clk to xxx in DTS and driver. 3. patch mxic_nfc_data_xfer() v5 patch including: 1. compatible rename to "macronix,nand-controller" 2. handle three clock in one 3. other minor patches v4 patch back to only raw NAND controller driver instead of MFD, raw NAND and SPI driver. This is based on MFD maintainer, Lee Jones comments: MFD is for registering child devices of chips which offer genuine cross-subsystem functionality. It is not designed for mode selecting, or as a place to shove shared code just because a better location doesn't appear to exist. v3 patch is to rename the title of SPI controller driver. "Patch Macronix SPI controller driver according to MX25F0A MFD driver" v2s patches is to support Macronix MX25F0A MFD driver for raw nand and spi controller which is separated form previous patchset: https://patchwork.kernel.org/patch/10874679/ thanks for your review. best regards, Mason Mason Yang (2): mtd: rawnand: Add Macronix raw NAND controller driver dt-bindings: mtd: Document Macronix raw NAND controller bindings .../devicetree/bindings/mtd/mxic-nand.txt | 19 + drivers/mtd/nand/raw/Kconfig | 6 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/mxic_nand.c | 554 + 4 files changed, 580 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/mxic-nand.txt create mode 100644 drivers/mtd/nand/raw/mxic_nand.c -- 1.9.1
[PATCH v6 1/2] mtd: rawnand: Add Macronix raw NAND controller driver
Add a driver for Macronix raw NAND controller. Signed-off-by: Mason Yang --- drivers/mtd/nand/raw/Kconfig | 6 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/mxic_nand.c | 554 +++ 3 files changed, 561 insertions(+) create mode 100644 drivers/mtd/nand/raw/mxic_nand.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index 5a711d8..9cff36a 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -407,6 +407,12 @@ config MTD_NAND_MTK Enables support for NAND controller on MTK SoCs. This controller is found on mt27xx, mt81xx, mt65xx SoCs. +config MTD_NAND_MXIC + tristate "Macronix raw NAND controller" + depends on HAS_IOMEM || COMPILE_TEST + help + This selects the Macronix raw NAND controller driver. + config MTD_NAND_TEGRA tristate "NVIDIA Tegra NAND controller" depends on ARCH_TEGRA || COMPILE_TEST diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index efaf5cd..9b43fbf 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o +obj-$(CONFIG_MTD_NAND_MXIC)+= mxic_nand.o obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o diff --git a/drivers/mtd/nand/raw/mxic_nand.c b/drivers/mtd/nand/raw/mxic_nand.c new file mode 100644 index 000..56e816d --- /dev/null +++ b/drivers/mtd/nand/raw/mxic_nand.c @@ -0,0 +1,554 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2019 Macronix International Co., Ltd. + * + * Author: + * Mason Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "internals.h" + +#define HC_CFG 0x0 +#define HC_CFG_IF_CFG(x) ((x) << 27) +#define HC_CFG_DUAL_SLAVE BIT(31) +#define HC_CFG_INDIVIDUAL BIT(30) +#define HC_CFG_NIO(x) (((x) / 4) << 27) +#define HC_CFG_TYPE(s, t) ((t) << (23 + ((s) * 2))) +#define HC_CFG_TYPE_SPI_NOR0 +#define HC_CFG_TYPE_SPI_NAND 1 +#define HC_CFG_TYPE_SPI_RAM2 +#define HC_CFG_TYPE_RAW_NAND 3 +#define HC_CFG_SLV_ACT(x) ((x) << 21) +#define HC_CFG_CLK_PH_EN BIT(20) +#define HC_CFG_CLK_POL_INV BIT(19) +#define HC_CFG_BIG_ENDIAN BIT(18) +#define HC_CFG_DATA_PASS BIT(17) +#define HC_CFG_IDLE_SIO_LVL(x) ((x) << 16) +#define HC_CFG_MAN_START_ENBIT(3) +#define HC_CFG_MAN_START BIT(2) +#define HC_CFG_MAN_CS_EN BIT(1) +#define HC_CFG_MAN_CS_ASSERT BIT(0) + +#define INT_STS0x4 +#define INT_STS_EN 0x8 +#define INT_SIG_EN 0xc +#define INT_STS_ALLGENMASK(31, 0) +#define INT_RDY_PINBIT(26) +#define INT_RDY_SR BIT(25) +#define INT_LNR_SUSP BIT(24) +#define INT_ECC_ERRBIT(17) +#define INT_CRC_ERRBIT(16) +#define INT_LWR_DISBIT(12) +#define INT_LRD_DISBIT(11) +#define INT_SDMA_INT BIT(10) +#define INT_DMA_FINISH BIT(9) +#define INT_RX_NOT_FULLBIT(3) +#define INT_RX_NOT_EMPTY BIT(2) +#define INT_TX_NOT_FULLBIT(1) +#define INT_TX_EMPTY BIT(0) + +#define HC_EN 0x10 +#define HC_EN_BIT BIT(0) + +#define TXD(x) (0x14 + ((x) * 4)) +#define RXD0x24 + +#define SS_CTRL(s) (0x30 + ((s) * 4)) +#define LRD_CFG0x44 +#define LWR_CFG0x80 +#define RWW_CFG0x70 +#define OP_READBIT(23) +#define OP_DUMMY_CYC(x)((x) << 17) +#define OP_ADDR_BYTES(x) ((x) << 14) +#define OP_CMD_BYTES(x)(((x) - 1) << 13) +#define OP_OCTA_CRC_EN BIT(12) +#define OP_DQS_EN BIT(11) +#define OP_ENHC_EN BIT(10) +#define OP_PREAMBLE_EN BIT(9) +#define OP_DATA_DDRBIT(8) +#define OP_DATA_BUSW(x)((x) << 6) +#define OP_ADDR_DDRBIT(5) +#define OP_ADDR_BUSW(x)((x) << 3) +#define OP_CMD_DDR BIT(2) +#define OP_CMD_BUSW(x) (x) +#define OP_BUSW_1 0 +#define OP_BUSW_2 1 +#define OP_BUSW_4 2 +#define OP_BUSW_8 3 + +#define OCTA_CRC 0x38 +#define OCTA_CRC_IN_EN(s) BIT(3 + ((s) * 16)) +#define OCTA_CRC_CHUNK(s, x) ((fls((x) / 32)) << (1 + ((s) * 16))) +#define OCTA_CRC_OUT_EN(s) BIT(0 + ((s) * 16)) + +#define ONFI_DIN_CNT(s)(0x3c + (s)) + +#define
[PATCH v3 3/3] KVM: Check preempted_in_kernel for involuntary preemption
From: Wanpeng Li
preempted_in_kernel is updated in preempt_notifier when involuntary preemption
ocurrs, it can be stale when the voluntarily preempted vCPUs are taken into
account by kvm_vcpu_on_spin() loop. This patch lets it just check
preempted_in_kernel
for involuntary preemption.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
virt/kvm/kvm_main.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3e1a509..58b9590 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2519,7 +2519,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool
yield_to_kernel_mode)
continue;
if (swait_active(>wq) && !vcpu_runnable(vcpu))
continue;
- if (yield_to_kernel_mode &&
!kvm_arch_vcpu_in_kernel(vcpu))
+ if (READ_ONCE(vcpu->preempted) && yield_to_kernel_mode
&&
+ !kvm_arch_vcpu_in_kernel(vcpu))
continue;
if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
continue;
@@ -4216,7 +4217,7 @@ static void kvm_sched_in(struct preempt_notifier *pn, int
cpu)
{
struct kvm_vcpu *vcpu = preempt_notifier_to_vcpu(pn);
- vcpu->preempted = false;
+ WRITE_ONCE(vcpu->preempted, false);
WRITE_ONCE(vcpu->ready, false);
kvm_arch_sched_in(vcpu, cpu);
@@ -4230,7 +4231,7 @@ static void kvm_sched_out(struct preempt_notifier *pn,
struct kvm_vcpu *vcpu = preempt_notifier_to_vcpu(pn);
if (current->state == TASK_RUNNING) {
- vcpu->preempted = true;
+ WRITE_ONCE(vcpu->preempted, true);
WRITE_ONCE(vcpu->ready, true);
}
kvm_arch_vcpu_put(vcpu);
--
2.7.4
[PATCH v6 2/2] dt-bindings: mtd: Document Macronix raw NAND controller bindings
Document the bindings used by the Macronix raw NAND controller.
Signed-off-by: Mason Yang
---
Documentation/devicetree/bindings/mtd/mxic-nand.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/mxic-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/mxic-nand.txt
b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
new file mode 100644
index 000..de37d60
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
@@ -0,0 +1,19 @@
+Macronix Raw NAND Controller Device Tree Bindings
+-
+
+Required properties:
+- compatible: should be "mxicy,multi-itfc-v009-nand-morph"
+- reg: should contain 1 entry for the registers
+- interrupts: interrupt line connected to this raw NAND controller
+- clock-names: should contain "ps", "send" and "send_dly"
+- clocks: should contain 3 phandles for the "ps", "send" and
+"send_dly" clocks
+
+Example:
+
+ nand: nand-controller@43c3 {
+ compatible = "mxicy,multi-itfc-v009-nand-morph";
+ reg = <0x43c3 0x1>;
+ clocks = < 0>, < 1>, < 15>;
+ clock-names = "send", "send_dly", "ps";
+ };
--
1.9.1
[PATCH v3 2/3] KVM: LAPIC: Don't need to wakeup vCPU twice afer timer fire
From: Wanpeng Li
kvm_set_pending_timer() will take care to wake up the sleeping vCPU which
has pending timer, don't need to check this in apic_timer_expired() again.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/lapic.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0aa1586..685d17c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1548,7 +1548,6 @@ static void kvm_apic_inject_pending_timer_irqs(struct
kvm_lapic *apic)
static void apic_timer_expired(struct kvm_lapic *apic)
{
struct kvm_vcpu *vcpu = apic->vcpu;
- struct swait_queue_head *q = >wq;
struct kvm_timer *ktimer = >lapic_timer;
if (atomic_read(>lapic_timer.pending))
@@ -1566,13 +1565,6 @@ static void apic_timer_expired(struct kvm_lapic *apic)
atomic_inc(>lapic_timer.pending);
kvm_set_pending_timer(vcpu);
-
- /*
-* For x86, the atomic_inc() is serialized, thus
-* using swait_active() is safe.
-*/
- if (swait_active(q))
- swake_up_one(q);
}
static void start_sw_tscdeadline(struct kvm_lapic *apic)
--
2.7.4
[PATCH v3 1/3] KVM: Fix leak vCPU's VMCS value into other pCPU
From: Wanpeng Li
After commit d73eb57b80b (KVM: Boost vCPUs that are delivering interrupts), a
five years old bug is exposed. Running ebizzy benchmark in three 80 vCPUs VMs
on one 80 pCPUs Skylake server, a lot of rcu_sched stall warning splatting
in the VMs after stress testing:
INFO: rcu_sched detected stalls on CPUs/tasks: { 4 41 57 62 77} (detected by
15, t=60004 jiffies, g=899, c=898, q=15073)
Call Trace:
flush_tlb_mm_range+0x68/0x140
tlb_flush_mmu.part.75+0x37/0xe0
tlb_finish_mmu+0x55/0x60
zap_page_range+0x142/0x190
SyS_madvise+0x3cd/0x9c0
system_call_fastpath+0x1c/0x21
swait_active() sustains to be true before finish_swait() is called in
kvm_vcpu_block(), voluntarily preempted vCPUs are taken into account
by kvm_vcpu_on_spin() loop greatly increases the probability condition
kvm_arch_vcpu_runnable(vcpu) is checked and can be true, when APICv
is enabled the yield-candidate vCPU's VMCS RVI field leaks(by
vmx_sync_pir_to_irr()) into spinning-on-a-taken-lock vCPU's current
VMCS.
This patch fixes it by checking conservatively a subset of events.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Christian Borntraeger
Cc: Marc Zyngier
Cc: sta...@vger.kernel.org
Fixes: 98f4a1467 (KVM: add kvm_arch_vcpu_runnable() test to kvm_vcpu_on_spin()
loop)
Signed-off-by: Wanpeng Li
---
v2 -> v3:
* check conservatively a subset of events
v1 -> v2:
* checking swait_active(>wq) for involuntary preemption
arch/mips/kvm/mips.c| 5 +
arch/powerpc/kvm/powerpc.c | 5 +
arch/s390/kvm/kvm-s390.c| 5 +
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/svm.c | 6 ++
arch/x86/kvm/vmx/vmx.c | 6 ++
arch/x86/kvm/x86.c | 23 +++
include/linux/kvm_host.h| 1 +
virt/kvm/arm/arm.c | 5 +
virt/kvm/kvm_main.c | 13 -
10 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index 2cfe839..95a4642 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -98,6 +98,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
return !!(vcpu->arch.pending_exceptions);
}
+bool kvm_arch_dy_runnable(struct kvm_vcpu *vcpu)
+{
+ return kvm_arch_vcpu_runnable(vcpu);
+}
+
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
{
return false;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 0dba7eb..3e34d5f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -50,6 +50,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
return !!(v->arch.pending_exceptions) || kvm_request_pending(v);
}
+bool kvm_arch_dy_runnable(struct kvm_vcpu *vcpu)
+{
+ return kvm_arch_vcpu_runnable(vcpu);
+}
+
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
{
return false;
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 3f520cd8..5623b23 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -3102,6 +3102,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
return kvm_s390_vcpu_has_irq(vcpu, 0);
}
+bool kvm_arch_dy_runnable(struct kvm_vcpu *vcpu)
+{
+ return kvm_arch_vcpu_runnable(vcpu);
+}
+
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
{
return !(vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE);
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7b0a4ee..de39a58 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1175,6 +1175,7 @@ struct kvm_x86_ops {
int (*update_pi_irte)(struct kvm *kvm, unsigned int host_irq,
uint32_t guest_irq, bool set);
void (*apicv_post_state_restore)(struct kvm_vcpu *vcpu);
+ bool (*apicv_test_pi_on)(struct kvm_vcpu *vcpu);
int (*set_hv_timer)(struct kvm_vcpu *vcpu, u64 guest_deadline_tsc,
bool *expired);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7eafc69..1921f37 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5190,6 +5190,11 @@ static void svm_deliver_avic_intr(struct kvm_vcpu *vcpu,
int vec)
kvm_vcpu_wake_up(vcpu);
}
+static bool svm_apicv_test_pi_on(struct kvm_vcpu *vcpu)
+{
+ return false;
+}
+
static void svm_ir_list_del(struct vcpu_svm *svm, struct amd_iommu_pi_data *pi)
{
unsigned long flags;
@@ -7314,6 +7319,7 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.pmu_ops = _pmu_ops,
.deliver_posted_interrupt = svm_deliver_avic_intr,
+ .apicv_test_pi_on = svm_apicv_test_pi_on,
.update_pi_irte = svm_update_pi_irte,
.setup_mce = svm_setup_mce,
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 074385c..863d641 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6117,6 +6117,11 @@ static int vmx_sync_pir_to_irr(struct kvm_vcpu
[PATCH] perf tools: Fix a typo in Makefile
This patch fix a spelling typo in Makefile. Signed-off-by: Masanari Iida --- tools/perf/Documentation/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Documentation/Makefile b/tools/perf/Documentation/Makefile index 6d148a40551c..adc5a7e44b98 100644 --- a/tools/perf/Documentation/Makefile +++ b/tools/perf/Documentation/Makefile @@ -242,7 +242,7 @@ $(OUTPUT)doc.dep : $(wildcard *.txt) build-docdep.perl $(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \ mv $@+ $@ --include $(OUPTUT)doc.dep +-include $(OUTPUT)doc.dep _cmds_txt = cmds-ancillaryinterrogators.txt \ cmds-ancillarymanipulators.txt \ -- 2.23.0.rc0
Re: [PATCH v2 2/2] ARM: dts: aspeed: Add Mihawk BMC platform
Hi Ben,
Comments inline below. Also apologies for the IBM/IPS mixup in the previous
review, I've been corrected :)
On Wed, 31 Jul 2019, at 17:17, Ben Pai wrote:
> The Mihawk BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
>
> Signed-off-by: Ben Pai
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 907
> 2 files changed, 908 insertions(+)
> create mode 100755 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index eb6de52c1936..262345544359 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1281,5 +1281,6 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-opp-vesnin.dtb \
> aspeed-bmc-opp-witherspoon.dtb \
> aspeed-bmc-opp-zaius.dtb \
> + aspeed-bmc-opp-mihawk.dtb \
This is a sorted list, please put it in the right spot.
> aspeed-bmc-portwell-neptune.dtb \
> aspeed-bmc-quanta-q71l.dtb
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> new file mode 100755
> index ..913c94326f3f
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> @@ -0,0 +1,907 @@
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include
> +#include
> +
> +/ {
> + model = "Mihawk BMC";
> + compatible = "ibm,mihawk-bmc", "aspeed,ast2500";
> +
> +
> + chosen {
> + stdout-path =
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory@8000 {
> + reg = <0x8000 0x2000>; /* address and size of
> RAM(512MB) */
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> +
> + gfx_memory: framebuffer {
> + size = <0x0100>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> +
> + video_engine_memory: jpegbuffer {
> + size = <0x0200>;/* 32MM */
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + air-water {
> + label = "air-water";
> + gpios = < ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + checkstop {
> + label = "checkstop";
> + gpios = < ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps0-presence {
> + label = "ps0-presence";
> + gpios = < ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps1-presence {
> + label = "ps1-presence";
> + gpios = < ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + id-button {
> + label = "id-button";
> + gpios = < ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
Delete the #address-cells property (both it and the #size-cells properties
are not needed for the gpio-keys-polled node).
> + poll-interval = <1000>;
> +
> + fan0-presence {
> + label = "fan0-presence";
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + linux,code = <9>;
> + };
> +
> + fan1-presence {
> + label = "fan1-presence";
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + linux,code = <10>;
> + };
> +
> + fan2-presence {
> + label = "fan2-presence";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + linux,code = <11>;
> + };
> +
> + fan3-presence {
> + label = "fan3-presence";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + linux,code = <12>;
> + };
> +
> + fan4-presence {
> + label = "fan4-presence";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + linux,code = <13>;
> + };
> +
> + fan5-presence {
> +
Re: [RFC 1/2] mm/sparsemem: Add vmem_altmap support in vmemmap_populate_basepages()
On 07/31/2019 09:40 PM, Will Deacon wrote: > On Fri, Jun 28, 2019 at 10:14:42AM +0530, Anshuman Khandual wrote: >> Generic vmemmap_populate_basepages() is used across platforms for vmemmap >> as standard or as fallback when huge pages mapping fails. On arm64 it is >> used for configs with ARM64_SWAPPER_USES_SECTION_MAPS applicable both for >> ARM64_16K_PAGES and ARM64_64K_PAGES which cannot use huge pages because of >> alignment requirements. >> >> This prevents those configs from allocating from device memory for vmemap >> mapping as vmemmap_populate_basepages() does not support vmem_altmap. This >> enables that required support. Each architecture should evaluate and decide >> on enabling device based base page allocation when appropriate. Hence this >> keeps it disabled for all architectures to preserve the existing semantics. > > This commit message doesn't really make sense to me. There's a huge amount > of arm64-specific detail, followed by vague references to "this" and > "those" and "that" and I lost track of what you're trying to solve. Hmm, will clean up. > > However, I puzzled through the code and I think it does make sense, so: > > Acked-by: Will Deacon > > assuming you rewrite the commit message. Thanks, will do. > > However, this has a dependency on your hot remove series which has open > comments from Mark Rutland afaict. Yeah it has dependency on the hot-remove series. The only outstanding issue there being whether to call free_empty_tables() in vmemmap tear down path or not. Mark had asked for more details regarding the implications in cases where free_empty_tables() is called or is not called. I did evaluate those details recently and we should be able to take a decision sooner.
[PATCH] tomoyo: Fix incorrect return value from tomoyo_find_next_domain()
When filename exceeds PATH_MAX,
tomoyo_find_next_domain() retval is not ENAMETOOLONG, but ENOENT.
Fix this by retuen kern_path() error.
Signed-off-by: Takeshi Misawa
---
Dear Tetsuo Handa
I found unexpected return value from TOMOYO and try to create a patch.
If this is not acceptable for security reason, please discard this patch.
Regards.
---
security/tomoyo/domain.c | 7 +--
security/tomoyo/realpath.c | 9 +++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
index 8526a0a74023..3d8034701344 100644
--- a/security/tomoyo/domain.c
+++ b/security/tomoyo/domain.c
@@ -723,8 +723,10 @@ int tomoyo_find_next_domain(struct linux_binprm *bprm)
/* Get symlink's pathname of program. */
retval = -ENOENT;
exename.name = tomoyo_realpath_nofollow(original_name);
- if (!exename.name)
+ if (IS_ERR(exename.name)) {
+ retval = PTR_ERR(exename.name);
goto out;
+ }
tomoyo_fill_path_info();
retry:
/* Check 'aggregator' directive. */
@@ -870,7 +872,8 @@ int tomoyo_find_next_domain(struct linux_binprm *bprm)
s->domain_info = domain;
atomic_inc(>users);
}
- kfree(exename.name);
+ if (!IS_ERR(exename.name))
+ kfree(exename.name);
if (!retval) {
ee->r.domain = domain;
retval = tomoyo_environ(ee);
diff --git a/security/tomoyo/realpath.c b/security/tomoyo/realpath.c
index e7832448d721..d73e66be05ef 100644
--- a/security/tomoyo/realpath.c
+++ b/security/tomoyo/realpath.c
@@ -332,10 +332,15 @@ char *tomoyo_realpath_from_path(const struct path *path)
char *tomoyo_realpath_nofollow(const char *pathname)
{
struct path path;
+ char *buf = NULL;
+ int err;
- if (pathname && kern_path(pathname, 0, ) == 0) {
- char *buf = tomoyo_realpath_from_path();
+ if (pathname) {
+ err = kern_path(pathname, 0, );
+ if (unlikely(err))
+ return ERR_PTR(err);
+ buf = tomoyo_realpath_from_path();
path_put();
return buf;
}
--
2.17.1
Re: [RFC 2/2] arm64/mm: Enable device memory allocation and free for vmemmap mapping
On 07/31/2019 09:41 PM, Will Deacon wrote:
> On Fri, Jun 28, 2019 at 10:14:43AM +0530, Anshuman Khandual wrote:
>> This enables vmemmap_populate() and vmemmap_free() functions to incorporate
>> struct vmem_altmap based device memory allocation and free requests. With
>> this device memory with specific atlmap configuration can be hot plugged
>> and hot removed as ZONE_DEVICE memory on arm64 platforms.
>>
>> Cc: Catalin Marinas
>> Cc: Will Deacon
>> Cc: Mark Rutland
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>>
>> Signed-off-by: Anshuman Khandual
>> ---
>> arch/arm64/mm/mmu.c | 57
>> ++---
>> 1 file changed, 37 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 39e18d1..8867bbd 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -735,15 +735,26 @@ int kern_addr_valid(unsigned long addr)
>> }
>>
>> #ifdef CONFIG_MEMORY_HOTPLUG
>> -static void free_hotplug_page_range(struct page *page, size_t size)
>> +static void free_hotplug_page_range(struct page *page, size_t size,
>> +struct vmem_altmap *altmap)
>> {
>> -WARN_ON(!page || PageReserved(page));
>> -free_pages((unsigned long)page_address(page), get_order(size));
>> +if (altmap) {
>> +/*
>> + * vmemmap_populate() creates vmemmap mapping either at pte
>> + * or pmd level. Unmapping request at any other level would
>> + * be a problem.
>> + */
>> +WARN_ON((size != PAGE_SIZE) && (size != PMD_SIZE));
>> +vmem_altmap_free(altmap, size >> PAGE_SHIFT);
>> +} else {
>> +WARN_ON(!page || PageReserved(page));
>> +free_pages((unsigned long)page_address(page), get_order(size));
>> +}
>> }
>>
>> static void free_hotplug_pgtable_page(struct page *page)
>> {
>> -free_hotplug_page_range(page, PAGE_SIZE);
>> +free_hotplug_page_range(page, PAGE_SIZE, NULL);
>> }
>>
>> static void free_pte_table(pmd_t *pmdp, unsigned long addr)
>> @@ -807,7 +818,8 @@ static void free_pud_table(pgd_t *pgdp, unsigned long
>> addr)
>> }
>>
>> static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
>> -unsigned long end, bool sparse_vmap)
>> +unsigned long end, bool sparse_vmap,
>> +struct vmem_altmap *altmap)
>
> Do you still need the sparse_vmap parameter, or can you just pass a NULL
> altmap pointer when sparse_vmap is false?
Yes, we will still require sparse_vmap parameter because vmemmap mapping
does not necessarily be created only for ZONE_DEVICE range with an altmap.
vmemmap can still be present with altmap as NULL (regular memory and device
memory without altmap) in which cases it will not be possible to
differentiate between linear and vmemmap mapping.
Re: [v7 2/2] gpio: aspeed: Add SGPIO driver
On Thu, 1 Aug 2019, at 05:32, Hongwei Zhang wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang
> Reviewed-by: Andrew Jeffery
Adding my Reviewed-by tag is a bit keen, I only gave it for the bindings on v6.
However, having looked over the patch you've addressed all of the issues I've
found, so you can keep it.
Andrew
> ---
> drivers/gpio/sgpio-aspeed.c | 530
>
> 1 file changed, 530 insertions(+)
> create mode 100644 drivers/gpio/sgpio-aspeed.c
>
> diff --git a/drivers/gpio/sgpio-aspeed.c b/drivers/gpio/sgpio-aspeed.c
> new file mode 100644
> index 000..752efea
> --- /dev/null
> +++ b/drivers/gpio/sgpio-aspeed.c
> @@ -0,0 +1,530 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright 2019 American Megatrends International LLC.
> + *
> + * Author: Karthikeyan Mani
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_NR_SGPIO 80
> +
> +#define ASPEED_SGPIO_CTRL0x54
> +
> +#define ASPEED_SGPIO_PINS_MASK GENMASK(9, 6)
> +#define ASPEED_SGPIO_CLK_DIV_MASKGENMASK(31, 16)
> +#define ASPEED_SGPIO_ENABLE BIT(0)
> +
> +struct aspeed_sgpio {
> + struct gpio_chip chip;
> + struct clk *pclk;
> + spinlock_t lock;
> + void __iomem *base;
> + uint32_t dir_in[3];
> + int irq;
> +};
> +
> +struct aspeed_sgpio_bank {
> + uint16_tval_regs;
> + uint16_trdata_reg;
> + uint16_tirq_regs;
> + const char names[4][3];
> +};
> +
> +/*
> + * Note: The "value" register returns the input value when the GPIO is
> + *configured as an input.
> + *
> + *The "rdata" register returns the output value when the GPIO is
> + *configured as an output.
> + */
> +static const struct aspeed_sgpio_bank aspeed_sgpio_banks[] = {
> + {
> + .val_regs = 0x,
> + .rdata_reg = 0x0070,
> + .irq_regs = 0x0004,
> + .names = { "A", "B", "C", "D" },
> + },
> + {
> + .val_regs = 0x001C,
> + .rdata_reg = 0x0074,
> + .irq_regs = 0x0020,
> + .names = { "E", "F", "G", "H" },
> + },
> + {
> + .val_regs = 0x0038,
> + .rdata_reg = 0x0078,
> + .irq_regs = 0x003C,
> + .names = { "I", "J" },
> + },
> +};
> +
> +enum aspeed_sgpio_reg {
> + reg_val,
> + reg_rdata,
> + reg_irq_enable,
> + reg_irq_type0,
> + reg_irq_type1,
> + reg_irq_type2,
> + reg_irq_status,
> +};
> +
> +#define GPIO_VAL_VALUE 0x00
> +#define GPIO_IRQ_ENABLE 0x00
> +#define GPIO_IRQ_TYPE0 0x04
> +#define GPIO_IRQ_TYPE1 0x08
> +#define GPIO_IRQ_TYPE2 0x0C
> +#define GPIO_IRQ_STATUS 0x10
> +
> +static void __iomem *bank_reg(struct aspeed_sgpio *gpio,
> + const struct aspeed_sgpio_bank *bank,
> + const enum aspeed_sgpio_reg reg)
> +{
> + switch (reg) {
> + case reg_val:
> + return gpio->base + bank->val_regs + GPIO_VAL_VALUE;
> + case reg_rdata:
> + return gpio->base + bank->rdata_reg;
> + case reg_irq_enable:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_ENABLE;
> + case reg_irq_type0:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE0;
> + case reg_irq_type1:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE1;
> + case reg_irq_type2:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE2;
> + case reg_irq_status:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_STATUS;
> + default:
> + /* acturally if code runs to here, it's an error case */
> + BUG_ON(1);
> + }
> +}
> +
> +#define GPIO_BANK(x)((x) >> 5)
> +#define GPIO_OFFSET(x) ((x) & 0x1f)
> +#define GPIO_BIT(x) BIT(GPIO_OFFSET(x))
> +
> +static const struct aspeed_sgpio_bank *to_bank(unsigned int offset)
> +{
> + unsigned int bank = GPIO_BANK(offset);
> +
> + WARN_ON(bank >= ARRAY_SIZE(aspeed_sgpio_banks));
> + return _sgpio_banks[bank];
> +}
> +
> +static int aspeed_sgpio_get(struct gpio_chip *gc, unsigned int offset)
> +{
> + struct aspeed_sgpio *gpio = gpiochip_get_data(gc);
> + const struct aspeed_sgpio_bank *bank = to_bank(offset);
> + unsigned long flags;
> + enum aspeed_sgpio_reg reg;
> + bool is_input;
> + int rc = 0;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + is_input = gpio->dir_in[GPIO_BANK(offset)] & GPIO_BIT(offset);
> + reg = is_input ? reg_val : reg_rdata;
> + rc = !!(ioread32(bank_reg(gpio, bank, reg)) & GPIO_BIT(offset));
> +
> + spin_unlock_irqrestore(>lock, flags);
> +
> + return rc;
> +}
> +
> +static void __aspeed_sgpio_set(struct gpio_chip *gc, unsigned int
Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs
On Thu, 2019-08-01 at 11:50 +0900, Masahiro Yamada wrote:
> On Thu, Aug 1, 2019 at 4:04 AM Rikard Falkeborn
> wrote:
> > GENMASK() and GENMASK_ULL() are supposed to be called with the high bit
> > as the first argument and the low bit as the second argument. Mixing
> > them will return a mask with zero bits set.
> >
> > Recent commits show getting this wrong is not uncommon, see e.g.
> > commit aa4c0c9091b0 ("net: stmmac: Fix misuses of GENMASK macro") and
> > commit 9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of GENMASK
> > macro").
> >
> > To prevent such mistakes from appearing again, add compile time sanity
> > checking to the arguments of GENMASK() and GENMASK_ULL(). If both the
> > arguments are known at compile time, and the low bit is higher than the
> > high bit, break the build to detect the mistake immediately.
> >
> > Since GENMASK() is used in declarations, BUILD_BUG_OR_ZERO() must be
> > used instead of BUILD_BUG_ON(), and __is_constexpr() must be used instead
> > of __builtin_constant_p().
> >
> > Commit 95b980d62d52 ("linux/bits.h: make BIT(), GENMASK(), and friends
> > available in assembly") made the macros in linux/bits.h available in
> > assembly. Since neither BUILD_BUG_OR_ZERO() or __is_constexpr() are asm
> > compatible, disable the checks if the file is included in an asm file.
> >
> > Signed-off-by: Rikard Falkeborn
> > ---
> > Joe Perches sent a series to fix the existing misuses of GENMASK() that
> > needs to be merged before this to avoid build failures. Currently, 7 of
> > the patches were not in Linus tree, and 2 were not in linux-next.
> >
> > Also, there's currently no asm users of bits.h, but since it was made
> > asm-compatible just two weeks ago it would be a shame to break it right
> > away...
[]
> > diff --git a/include/linux/bits.h b/include/linux/bits.h
[]
> > #define GENMASK(h, l) \
> > + (GENMASK_INPUT_CHECK(h, l) + \
> > (((~UL(0)) - (UL(1) << (l)) + 1) & \
> > -(~UL(0) >> (BITS_PER_LONG - 1 - (h
> > +(~UL(0) >> (BITS_PER_LONG - 1 - (h)
> >
> > #define GENMASK_ULL(h, l) \
> > + (GENMASK_INPUT_CHECK(h, l) + \
> > (((~ULL(0)) - (ULL(1) << (l)) + 1) & \
> > -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h
> > +(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h)
>
> This is getting cluttered with so many parentheses.
>
> One way of clean-up is to rename the current macros as follows:
>
>GENMASK()-> __GENMASK()
>GENMASK_UL() -> __GENMASK_ULL()
>
> Then,
>
> #define GENMASK(h, l) (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
> #define GENMASK_ULL(h, l) (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l))
Much nicer. It may be better still to use avoid
multiple dereferences of each argument.
Also it'd be useful to rename h and l to something like
high_bit and low_bit or high and low.
Re: [PATCH v3] kbuild: Check for unknown options with cc-option usage in Kconfig and clang
On Wed, Jul 31, 2019 at 1:51 AM Masahiro Yamada
wrote:
>
> On Wed, Jul 31, 2019 at 1:50 AM Nathan Chancellor
> wrote:
> >
> > On Tue, Jul 30, 2019 at 09:48:03AM -0700, Stephen Boyd wrote:
> > > If the particular version of clang a user has doesn't enable
> > > -Werror=unknown-warning-option by default, even though it is the
> > > default[1], then make sure to pass the option to the Kconfig cc-option
> > > command so that testing options from Kconfig files works properly.
> > > Otherwise, depending on the default values setup in the clang toolchain
> > > we will silently assume options such as -Wmaybe-uninitialized are
> > > supported by clang, when they really aren't.
> > >
> > > A compilation issue only started happening for me once commit
> > > 589834b3a009 ("kbuild: Add -Werror=unknown-warning-option to
> > > CLANG_FLAGS") was applied on top of commit b303c6df80c9 ("kbuild:
> > > compute false-positive -Wmaybe-uninitialized cases in Kconfig"). This
> > > leads kbuild to try and test for the existence of the
> > > -Wmaybe-uninitialized flag with the cc-option command in
> > > scripts/Kconfig.include, and it doesn't see an error returned from the
> > > option test so it sets the config value to Y. Then the Makefile tries to
> > > pass the unknown option on the command line and
> > > -Werror=unknown-warning-option catches the invalid option and breaks the
> > > build. Before commit 589834b3a009 ("kbuild: Add
> > > -Werror=unknown-warning-option to CLANG_FLAGS") the build works fine,
> > > but any cc-option test of a warning option in Kconfig files silently
> > > evaluates to true, even if the warning option flag isn't supported on
> > > clang.
> > >
> > > Note: This doesn't change cc-option usages in Makefiles because those
> > > use a different rule that includes KBUILD_CFLAGS by default (see the
> > > __cc-option command in scripts/Kbuild.incluide). The KBUILD_CFLAGS
> > > variable already has the -Werror=unknown-warning-option flag set. Thanks
> > > to Doug for pointing out the different rule.
> > >
> > > [1]
> > > https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option
> > > Cc: Peter Smith
> > > Cc: Nathan Chancellor
> > > Cc: Nick Desaulniers
> > > Cc: Douglas Anderson
> > > Signed-off-by: Stephen Boyd
> >
> > Reviewed-by: Nathan Chancellor
> >
> > > ---
> > > Makefile| 1 +
> > > scripts/Kconfig.include | 2 +-
> > > 2 files changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 9be5834073f8..517d0a3f6539 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -536,6 +536,7 @@ KBUILD_AFLAGS += $(CLANG_FLAGS)
> > > export CLANG_FLAGS
> > > endif
> > >
> > > +
> >
> > Not sure it's worth sending a v4 for but I don't think this should be
> > there.
>
>
> I will remove it when I apply this.
>
Applied to linux-kbuild/fixes. Thanks.
--
Best Regards
Masahiro Yamada
Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs
On Thu, Aug 1, 2019 at 4:04 AM Rikard Falkeborn
wrote:
>
> GENMASK() and GENMASK_ULL() are supposed to be called with the high bit
> as the first argument and the low bit as the second argument. Mixing
> them will return a mask with zero bits set.
>
> Recent commits show getting this wrong is not uncommon, see e.g.
> commit aa4c0c9091b0 ("net: stmmac: Fix misuses of GENMASK macro") and
> commit 9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of GENMASK
> macro").
>
> To prevent such mistakes from appearing again, add compile time sanity
> checking to the arguments of GENMASK() and GENMASK_ULL(). If both the
> arguments are known at compile time, and the low bit is higher than the
> high bit, break the build to detect the mistake immediately.
>
> Since GENMASK() is used in declarations, BUILD_BUG_OR_ZERO() must be
> used instead of BUILD_BUG_ON(), and __is_constexpr() must be used instead
> of __builtin_constant_p().
>
> Commit 95b980d62d52 ("linux/bits.h: make BIT(), GENMASK(), and friends
> available in assembly") made the macros in linux/bits.h available in
> assembly. Since neither BUILD_BUG_OR_ZERO() or __is_constexpr() are asm
> compatible, disable the checks if the file is included in an asm file.
>
> Signed-off-by: Rikard Falkeborn
> ---
> Joe Perches sent a series to fix the existing misuses of GENMASK() that
> needs to be merged before this to avoid build failures. Currently, 7 of
> the patches were not in Linus tree, and 2 were not in linux-next.
>
> Also, there's currently no asm users of bits.h, but since it was made
> asm-compatible just two weeks ago it would be a shame to break it right
> away...
>
> include/linux/bits.h | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/bits.h b/include/linux/bits.h
> index 669d69441a62..73489579eef9 100644
> --- a/include/linux/bits.h
> +++ b/include/linux/bits.h
> @@ -18,12 +18,22 @@
> * position @h. For example
> * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
> */
> +#ifndef __ASSEMBLY__
> +#include
> +#define GENMASK_INPUT_CHECK(h, l) BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> + __is_constexpr(h) && __is_constexpr(l), (l) > (h), 0))
> +#else
> +#define GENMASK_INPUT_CHECK(h, l) 0
> +#endif
> +
> #define GENMASK(h, l) \
> + (GENMASK_INPUT_CHECK(h, l) + \
> (((~UL(0)) - (UL(1) << (l)) + 1) & \
> -(~UL(0) >> (BITS_PER_LONG - 1 - (h
> +(~UL(0) >> (BITS_PER_LONG - 1 - (h)
>
> #define GENMASK_ULL(h, l) \
> + (GENMASK_INPUT_CHECK(h, l) + \
> (((~ULL(0)) - (ULL(1) << (l)) + 1) & \
> -(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h
> +(~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h)
This is getting cluttered with so many parentheses.
One way of clean-up is to rename the current macros as follows:
GENMASK()-> __GENMASK()
GENMASK_UL() -> __GENMASK_ULL()
Then,
#define GENMASK(h, l) (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
#define GENMASK_ULL(h, l) (GENMASK_INPUT_CHECK(h, l) + __GENMASK_ULL(h, l))
--
Best Regards
Masahiro Yamada
linux-next: manual merge of the sound-asoc tree with the sound tree
Hi all,
Today's linux-next merge of the sound-asoc tree got conflicts in:
sound/soc/intel/skylake/skl-nhlt.c
sound/soc/intel/skylake/skl.h
between commit:
1169cbf6b98e ("ASoC: Intel: Skylake: use common NHLT module")
from the sound tree and commit:
bcc2a2dc3ba8 ("ASoC: Intel: Skylake: Merge skl_sst and skl into skl_dev
struct")
from the sound-asoc tree.
I fixed it up (I think, see below (I used the sound tree version of
ound/soc/intel/skylake/skl-nhlt.c)) 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
diff --cc sound/soc/intel/skylake/skl-nhlt.c
index 6f57ceb9efb7,6fc3a190067e..
--- a/sound/soc/intel/skylake/skl-nhlt.c
+++ b/sound/soc/intel/skylake/skl-nhlt.c
diff --cc sound/soc/intel/skylake/skl.h
index f4dd6c767993,600a61f79b0a..
--- a/sound/soc/intel/skylake/skl.h
+++ b/sound/soc/intel/skylake/skl.h
@@@ -16,7 -16,9 +16,8 @@@
#include
#include
#include
-#include "skl-nhlt.h"
#include "skl-ssp-clk.h"
+ #include "skl-sst-ipc.h"
#define SKL_SUSPEND_DELAY 2000
@@@ -128,24 -167,27 +166,24 @@@ struct skl_dsp_ops
int skl_platform_unregister(struct device *dev);
int skl_platform_register(struct device *dev);
- struct nhlt_specific_cfg *skl_get_ep_blob(struct skl *skl, u32 instance,
-struct nhlt_acpi_table *skl_nhlt_init(struct device *dev);
-void skl_nhlt_free(struct nhlt_acpi_table *addr);
+ struct nhlt_specific_cfg *skl_get_ep_blob(struct skl_dev *skl, u32 instance,
u8 link_type, u8 s_fmt, u8 no_ch,
u32 s_rate, u8 dirn, u8 dev_type);
- int skl_nhlt_update_topology_bin(struct skl *skl);
- int skl_init_dsp(struct skl *skl);
- int skl_free_dsp(struct skl *skl);
- int skl_suspend_late_dsp(struct skl *skl);
- int skl_suspend_dsp(struct skl *skl);
- int skl_resume_dsp(struct skl *skl);
- void skl_cleanup_resources(struct skl *skl);
-int skl_get_dmic_geo(struct skl_dev *skl);
+ int skl_nhlt_update_topology_bin(struct skl_dev *skl);
+ int skl_init_dsp(struct skl_dev *skl);
+ int skl_free_dsp(struct skl_dev *skl);
+ int skl_suspend_late_dsp(struct skl_dev *skl);
+ int skl_suspend_dsp(struct skl_dev *skl);
+ int skl_resume_dsp(struct skl_dev *skl);
+ void skl_cleanup_resources(struct skl_dev *skl);
const struct skl_dsp_ops *skl_get_dsp_ops(int pci_id);
void skl_update_d0i3c(struct device *dev, bool enable);
- int skl_nhlt_create_sysfs(struct skl *skl);
- void skl_nhlt_remove_sysfs(struct skl *skl);
- void skl_get_clks(struct skl *skl, struct skl_ssp_clk *ssp_clks);
+ int skl_nhlt_create_sysfs(struct skl_dev *skl);
+ void skl_nhlt_remove_sysfs(struct skl_dev *skl);
+ void skl_get_clks(struct skl_dev *skl, struct skl_ssp_clk *ssp_clks);
struct skl_clk_parent_src *skl_get_parent_clk(u8 clk_id);
- int skl_dsp_set_dma_control(struct skl_sst *ctx, u32 *caps,
+ int skl_dsp_set_dma_control(struct skl_dev *skl, u32 *caps,
u32 caps_size, u32 node_id);
struct skl_module_cfg;
pgpHx7sf2nFtU.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 19/57] iio: Remove dev_err() usage after platform_get_irq()
G'day Stephen,
One comment below.
On 31/07/2019 22:32, Stephen Boyd wrote:
Quoting Phil Reid (2019-07-30 23:42:16)
G'day Stephen,
A comment unrelated to your change.
On 31/07/2019 02:15, Stephen Boyd wrote:
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 32f1c4a33b20..abe99856c823 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -1179,10 +1179,8 @@ static int at91_adc_probe(struct platform_device *pdev)
idev->info = _adc_info;
st->irq = platform_get_irq(pdev, 0);
- if (st->irq < 0) {
- dev_err(>dev, "No IRQ ID is designated\n");
+ if (st->irq < 0)
return -ENODEV;
Should this be returning st->irq instead of -ENODEV?
eg: platform_get_irq can return -EPROBE_DEFER
Pattern is repeated in a number of other places.
Probably? Here's a patch.
8<
From: Stephen Boyd
Subject: [PATCH] iio: Return error values from platform_get_irq*()
Sometimes platform_get_irq*() can return -EPROBE_DEFER, so it's best to
return the actual error value from calling this function instead of
overriding the value to something like -EINVAL or -ENXIO. Except for in
the case when the irq value is 0 and the driver knows that irq 0 isn't
valid. In such a situation, return whatever error value was returned
before this change.
Reported-by: Phil Reid
Cc: Phil Reid
Cc: Jonathan Cameron
Cc: Hartmut Knaack
Cc: Lars-Peter Clausen
Cc: Peter Meerwald-Stadler
Cc: linux-...@vger.kernel.org
Cc: Greg Kroah-Hartman
Signed-off-by: Stephen Boyd
---
drivers/iio/adc/at91_adc.c | 2 +-
drivers/iio/adc/bcm_iproc_adc.c | 2 +-
drivers/iio/adc/fsl-imx25-gcq.c | 4 +---
drivers/iio/adc/lpc32xx_adc.c | 2 +-
drivers/iio/adc/npcm_adc.c | 2 +-
drivers/iio/adc/spear_adc.c | 2 +-
6 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index abe99856c823..2c604198c4b7 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -1180,7 +1180,7 @@ static int at91_adc_probe(struct platform_device *pdev)
st->irq = platform_get_irq(pdev, 0);
if (st->irq < 0)
- return -ENODEV;
+ return st->irq;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/iio/adc/bcm_iproc_adc.c b/drivers/iio/adc/bcm_iproc_adc.c
index 646ebdc0a8b4..6c05ea510c40 100644
--- a/drivers/iio/adc/bcm_iproc_adc.c
+++ b/drivers/iio/adc/bcm_iproc_adc.c
@@ -541,7 +541,7 @@ static int iproc_adc_probe(struct platform_device *pdev)
adc_priv->irqno = platform_get_irq(pdev, 0);
if (adc_priv->irqno <= 0)
- return -ENODEV;
+ return adc_priv->irqno;
return adc_priv->irqno ? : -ENODEV;
ret = regmap_update_bits(adc_priv->regmap, IPROC_REGCTL2,
IPROC_ADC_AUXIN_SCAN_ENA, 0);
diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
index fa71489195c6..ee20ab09abe5 100644
--- a/drivers/iio/adc/fsl-imx25-gcq.c
+++ b/drivers/iio/adc/fsl-imx25-gcq.c
@@ -340,9 +340,7 @@ static int mx25_gcq_probe(struct platform_device *pdev)
priv->irq = platform_get_irq(pdev, 0);
if (priv->irq <= 0) {
- ret = priv->irq;
- if (!ret)
- ret = -ENXIO;
+ ret = priv->irq ? : -ENXIO;
goto err_clk_unprepare;
}
diff --git a/drivers/iio/adc/lpc32xx_adc.c b/drivers/iio/adc/lpc32xx_adc.c
index b896f7ff4572..edbb58212fba 100644
--- a/drivers/iio/adc/lpc32xx_adc.c
+++ b/drivers/iio/adc/lpc32xx_adc.c
@@ -173,7 +173,7 @@ static int lpc32xx_adc_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq <= 0)
- return -ENXIO;
+ return irq ? : -ENXIO;
retval = devm_request_irq(>dev, irq, lpc32xx_adc_isr, 0,
LPC32XXAD_NAME, st);
diff --git a/drivers/iio/adc/npcm_adc.c b/drivers/iio/adc/npcm_adc.c
index 910f3585fa54..1e54a64a4534 100644
--- a/drivers/iio/adc/npcm_adc.c
+++ b/drivers/iio/adc/npcm_adc.c
@@ -225,7 +225,7 @@ static int npcm_adc_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq <= 0) {
- ret = -EINVAL;
+ ret = irq ? : -EINVAL;
goto err_disable_clk;
}
diff --git a/drivers/iio/adc/spear_adc.c b/drivers/iio/adc/spear_adc.c
index 592b97c464da..9b16717ac7e7 100644
--- a/drivers/iio/adc/spear_adc.c
+++ b/drivers/iio/adc/spear_adc.c
@@ -301,7 +301,7 @@ static int spear_adc_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq <= 0) {
- ret = -EINVAL;
+ ret = irq ? : -EINVAL;
goto errout2;
}
--
Regards
Phil Reid
Re: [PATCH] libfdt: reduce the number of headers included from libfdt_env.h
On Tue, Jun 18, 2019 at 1:21 AM Masahiro Yamada
wrote:
>
> Currently, libfdt_env.h includes just for INT_MAX.
>
> pulls in a lots of broat.
>
> Thanks to commit 54d50897d544 ("linux/kernel.h: split *_MAX and *_MIN
> macros into "), can be replaced with
> .
>
> This saves including dozens of headers.
>
> Signed-off-by: Masahiro Yamada
> ---
ping?
> include/linux/libfdt_env.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/libfdt_env.h b/include/linux/libfdt_env.h
> index edb0f0c30904..2231eb855e8f 100644
> --- a/include/linux/libfdt_env.h
> +++ b/include/linux/libfdt_env.h
> @@ -2,7 +2,7 @@
> #ifndef LIBFDT_ENV_H
> #define LIBFDT_ENV_H
>
> -#include /* For INT_MAX */
> +#include /* For INT_MAX */
> #include
>
> #include
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 2/2] cnic: Use refcount_t for refcount
Michael Chan 于2019年8月1日周四 上午1:58写道： > > On Wed, Jul 31, 2019 at 5:22 AM Chuhong Yuan wrote: > > > static void cnic_ctx_wr(struct cnic_dev *dev, u32 cid_addr, u32 off, u32 > > val) > > @@ -494,7 +494,7 @@ int cnic_register_driver(int ulp_type, struct > > cnic_ulp_ops *ulp_ops) > > } > > read_unlock(_dev_lock); > > > > - atomic_set(_ops->ref_count, 0); > > + refcount_set(_ops->ref_count, 0); > > rcu_assign_pointer(cnic_ulp_tbl[ulp_type], ulp_ops); > > mutex_unlock(_lock); > > > > Willem's comment applies here too. The driver needs to be modified to > count from 1 to use refcount_t. > > Thanks. I have revised this problem but find the other two refcounts - cnic_dev::ref_count and cnic_sock::ref_count have no set. I am not sure where to initialize them to 1. Besides, should ulp_ops->ref_count be set to 0 when unregistered?
Re: [PATCH v4] modpost: check for static EXPORT_SYMBOL* functions
On Wed, Jul 31, 2019 at 5:54 PM Masahiro Yamada
wrote:
>
> Hi.
>
>
>
> On Wed, Jul 31, 2019 at 3:12 AM Denis Efremov wrote:
> >
> > This patch adds a check to warn about static EXPORT_SYMBOL* functions
> > during the modpost. In most of the cases, a static symbol marked for
> > exporting is an odd combination that should be fixed either by deleting
> > the exporting mark or by removing the static attribute and adding the
> > appropriate declaration to headers.
> >
> > This check could help to detect the following problems:
> > 1. 550113d4e9f5 ("i2c: add newly exported functions to the header, too")
> > 2. 54638c6eaf44 ("net: phy: make exported variables non-static")
> > 3. 98ef2046f28b ("mm: remove the exporting of totalram_pages")
> > 4. 73df167c819e ("s390/zcrypt: remove the exporting of
> > ap_query_configuration")
> > 5. a57caf8c527f ("sunrpc/cache: remove the exporting of cache_seq_next")
> > 6. e4e4730698c9 ("crypto: skcipher - remove the exporting of
> > skcipher_walk_next")
> > 7. 14b4c48bb1ce ("gve: Remove the exporting of gve_probe")
> > 8. 9b79ee9773a8 ("scsi: libsas: remove the exporting of sas_wait_eh")
> > 9. ...
> >
> > Build time impact, allmodconfig, Dell XPS 15 9570 (measurements 3x):
> > $ make mrproper; make allmodconfig; time make -j12; \
> > git checkout HEAD~1; \
> > make mrproper; make allmodconfig; time make -j12
> > 1.
> >(with patch) 17635,94s user 1895,54s system 1085% cpu 29:59,22 total
> >(w/o patch) 17275,42s user 1803,87s system 1112% cpu 28:35,66 total
> > 2.
> >(with patch) 17369,51s user 1763,28s system % cpu 28:41,47 total
> >(w/o patch) 16880,50s user 1670,93s system 1113% cpu 27:46,56 total
> > 3.
> >(with patch) 17937,88s user 1842,53s system 1109% cpu 29:42,26 total
> >(w/o patch) 17267,55s user 1725,09s system % cpu 28:28,17 total
> >
> > The check adds less than a minute to a usual build.
The build time impact is very limited.
I guess this measurement is unnecessary in the commit log.
--
Best Regards
Masahiro Yamada
Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables
Hi. On Thu, Aug 1, 2019 at 4:44 AM Wolfram Sang wrote: > > Hi Javier, > > thank you for providing the extra information. > > (And Kieran, thanks for the patch!) > > > The other option is to remove i2c_of_match_device() and don't make OF match > > to fallback to i2c_of_match_device_sysfs(). This is what happens in the ACPI > > case, since i2c_device_match() just calls acpi_driver_match_device() > > directly > > and doesn't have a wrapper function that fallbacks to sysfs matching. > > > > In this case an I2C device ID table would be required if the devices have to > > be instantiated through sysfs. That way the I2C table would be used both for > > auto-loading and also to match the device when it doesn't have an of_node. > > That would probably mean that only a minority of drivers will not add an I2C > device ID table because it is easy to add an you get the sysfs feature? > > Then we are back again with the situation that most drivers will have > multiple tables. With the minor change that the I2C device id table is > not required anymore by the core, but it will be just very useful to > have? Or? > > > If the former is the correct way to solve this then the patch looks good to > > me. > > > > Reviewed-by: Javier Martinez Canillas > > For this actual patch from Kieran, I'd like to hear an opinion from the > people maintaining modpost. As you see 'git log scripts/mod/file2alias.c', this file is touched by every subsystem. So, the decision is up to you, Wolfram. And, you can pick this to your tree if you like. The implementation is really trivial. As Javier pointed out, this discussion comes down to "do we want to fall back to i2c_of_match_device_sysfs()?" If a driver supports DT and devices are instantiated via DT, in which situation is this useful? Do legacy non-DT platforms need this? > The aproach looks okay to me, yet I can't > tell how "easy" we are with adding new types like 'i2c_of'. As far as I understood, this patch provides a shorthand. You can save one table, but still get the same MODULE_ALIAS in the *.mod.c file. You need to add two MODULE_DEVICE_TABLE() though. MODULE_DEVICE_TABLE(of, si4713_of_match); MODULE_DEVICE_TABLE(i2c_of, si4713_of_match); -- Best Regards Masahiro Yamada
[PATCH v2] powerpc: Support CMDLINE_EXTEND
Bring powerpc in line with other architectures that support extending or
overriding the bootloader provided command line.
The current behaviour is most like CMDLINE_FROM_BOOTLOADER where the
bootloader command line is preferred but the kernel config can provide a
fallback so CMDLINE_FROM_BOOTLOADER is the default. CMDLINE_EXTEND can
be used to append the CMDLINE from the kernel config to the one provided
by the bootloader.
Signed-off-by: Chris Packham
---
While I'm at it does anyone think it's worth getting rid of the default CMDLINE
value if CMDLINE_BOOL and maybe CMDLINE_BOOL? Every defconfig in the kernel
that sets CMDLINE_BOOL=y also sets CMDLINE to something other than
"console=ttyS0,9600 console=tty0 root=/dev/sda2". Removing CMDLINE_BOOL and
unconditionally setting the default value of CMDLINE to "" would clean up the
Kconfig even more.
Changes in v2:
- incorporate ideas from Christope's patch
https://patchwork.ozlabs.org/patch/1074126/
arch/powerpc/Kconfig| 20 +++-
arch/powerpc/kernel/prom_init.c | 26 +-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 77f6ebf97113..d413fe1b4058 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -852,15 +852,33 @@ config CMDLINE
some command-line options at build time by entering them here. In
most cases you will need to specify the root device here.
+choice
+ prompt "Kernel command line type" if CMDLINE != ""
+ default CMDLINE_FROM_BOOTLOADER
+
+config CMDLINE_FROM_BOOTLOADER
+ bool "Use bootloader kernel arguments if available"
+ help
+ Uses the command-line options passed by the boot loader. If
+ the boot loader doesn't provide any, the default kernel command
+ string provided in CMDLINE will be used.
+
+config CMDLINE_EXTEND
+ bool "Extend bootloader kernel arguments"
+ help
+ The command-line arguments provided by the boot loader will be
+ appended to the default kernel command string.
+
config CMDLINE_FORCE
bool "Always use the default kernel command string"
- depends on CMDLINE_BOOL
help
Always use the default kernel command string, even if the boot
loader passes other arguments to the kernel.
This is useful if you cannot or don't want to change the
command-line options your boot loader passes to the kernel.
+endchoice
+
config EXTRA_TARGETS
string "Additional default image types"
help
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 514707ef6779..df29f141dbd2 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -310,6 +310,25 @@ static size_t __init prom_strlcpy(char *dest, const char
*src, size_t size)
return ret;
}
+static size_t __init prom_strlcat(char *dest, const char *src, size_t count)
+{
+ size_t dsize = prom_strlen(dest);
+ size_t len = prom_strlen(src);
+ size_t res = dsize + len;
+
+ /* This would be a bug */
+ BUG_ON(dsize >= count);
+
+ dest += dsize;
+ count -= dsize;
+ if (len >= count)
+ len = count-1;
+ memcpy(dest, src, len);
+ dest[len] = 0;
+ return res;
+
+}
+
#ifdef CONFIG_PPC_PSERIES
static int __init prom_strtobool(const char *s, bool *res)
{
@@ -761,8 +780,13 @@ static void __init early_cmdline_parse(void)
p = prom_cmd_line;
if ((long)prom.chosen > 0)
l = prom_getprop(prom.chosen, "bootargs", p,
COMMAND_LINE_SIZE-1);
- if (IS_ENABLED(CONFIG_CMDLINE_BOOL) && (l <= 0 || p[0] == '\0')) /* dbl
check */
+
+ if (IS_ENABLED(CONFIG_CMDLINE_FORCE) || l <= 0 || p[0] == '\0')
prom_strlcpy(prom_cmd_line, CONFIG_CMDLINE,
sizeof(prom_cmd_line));
+ else if (IS_ENABLED(CONFIG_CMDLINE_EXTEND))
+ prom_strlcat(prom_cmd_line, " " CONFIG_CMDLINE,
+sizeof(prom_cmd_line));
+
prom_printf("command line: %s\n", prom_cmd_line);
#ifdef CONFIG_PPC64
--
2.22.0
[PATCH] asm-generic: Remove redundant arch-specific rules for simd.h
On Thu, Aug 01, 2019 at 11:53:46AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the crypto tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> scripts/Makefile.asm-generic:25: redundant generic-y found in
> arch/arm/include/asm/Kbuild: simd.h
>
> Introduced by commit
>
> 82cb54856874 ("asm-generic: make simd.h a mandatory include/asm header")
>
> Also the powerpc ppc64_defconfig build produced this warning:
>
> scripts/Makefile.asm-generic:25: redundant generic-y found in
> arch/powerpc/include/asm/Kbuild: simd.h
Thanks for the heads up Stephen. This patch should fix the
warnings.
---8<---
Now that simd.h is in include/asm-generic/Kbuild we don't need
the arch-specific Kbuild rules for them.
Reported-by: Stephen Rothwell
Fixes: 82cb54856874 ("asm-generic: make simd.h a mandatory...")
Signed-off-by: Herbert Xu
diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index 6b2dc15..68ca86f 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -17,7 +17,6 @@ generic-y += parport.h
generic-y += preempt.h
generic-y += seccomp.h
generic-y += serial.h
-generic-y += simd.h
generic-y += trace_clock.h
generated-y += mach-types.h
diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild
index 9a1d2fc..64870c7 100644
--- a/arch/powerpc/include/asm/Kbuild
+++ b/arch/powerpc/include/asm/Kbuild
@@ -11,4 +11,3 @@ generic-y += mcs_spinlock.h
generic-y += preempt.h
generic-y += vtime.h
generic-y += msi.h
-generic-y += simd.h
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
linux-next: build warnings after merge of the crypto tree
Hi all,
After merging the crypto tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
scripts/Makefile.asm-generic:25: redundant generic-y found in
arch/arm/include/asm/Kbuild: simd.h
Introduced by commit
82cb54856874 ("asm-generic: make simd.h a mandatory include/asm header")
Also the powerpc ppc64_defconfig build produced this warning:
scripts/Makefile.asm-generic:25: redundant generic-y found in
arch/powerpc/include/asm/Kbuild: simd.h
--
Cheers,
Stephen Rothwell
pgpw93OhtFD58.pgp
Description: OpenPGP digital signature
[PATCH -next] staging: rtl8723bs: remove set but not used variable 'bEEPROMCheck'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/staging/rtl8723bs//hal/odm_CfoTracking.c: In function
'odm_SetCrystalCap':
drivers/staging/rtl8723bs//hal/odm_CfoTracking.c:14:7: warning:
variable 'bEEPROMCheck' set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/staging/rtl8723bs/hal/odm_CfoTracking.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/odm_CfoTracking.c
b/drivers/staging/rtl8723bs/hal/odm_CfoTracking.c
index a733046..95edd14 100644
--- a/drivers/staging/rtl8723bs/hal/odm_CfoTracking.c
+++ b/drivers/staging/rtl8723bs/hal/odm_CfoTracking.c
@@ -11,11 +11,6 @@ static void odm_SetCrystalCap(void *pDM_VOID, u8 CrystalCap)
{
PDM_ODM_T pDM_Odm = (PDM_ODM_T)pDM_VOID;
PCFO_TRACKING pCfoTrack = _Odm->DM_CfoTrack;
- bool bEEPROMCheck;
- struct adapter *Adapter = pDM_Odm->Adapter;
- struct hal_com_data *pHalData = GET_HAL_DATA(Adapter);
-
- bEEPROMCheck = pHalData->EEPROMVersion >= 0x01;
if (pCfoTrack->CrystalCap == CrystalCap)
return;
--
2.7.4
Re: [PATCH RFC 2/2] futex: Implement mechanism to wait on any of several futexes
On 7/31/19 6:32 PM, Zebediah Figura wrote: On 7/31/19 8:22 PM, Zebediah Figura wrote: On 7/31/19 7:45 PM, Thomas Gleixner wrote: If I assume a maximum of 65 futexes which got mentioned in one of the replies then this will allocate 7280 bytes alone for the futex_q array with a stock debian config which has no debug options enabled which would bloat the struct. Adding the futex_wait_block array into the same allocation becomes larger than 8K which already exceeds thelimit of SLUB kmem caches and forces the whole thing into the page allocator directly. This sucks. Also I'm confused about the 64 maximum resulting in 65 futexes comment in one of the mails. Can you please explain what you are trying to do exatly on the user space side? The extra futex comes from the fact that there are a couple of, as it were, out-of-band ways to wake up a thread on Windows. [Specifically, a thread can enter an "alertable" wait in which case it will be woken up by a request from another thread to execute an "asynchronous procedure call".] It's easiest for us to just add another futex to the list in that case. To be clear, the 64/65 distinction is an implementation detail that's pretty much outside the scope of this discussion. I should have just said 65 directly. Sorry about that. I'd also point out, for whatever it's worth, that while 64 is a hard limit, real applications almost never go nearly that high. By far the most common number of primitives to select on is one. Performance-critical code never tends to wait on more than three. The most I've ever seen is twelve. If you'd like to see the user-side source, most of the relevant code is at [1], in particular the functions __fsync_wait_objects() [line 712] and do_single_wait [line 655]. Please feel free to ask for further clarification. [1] https://github.com/ValveSoftware/wine/blob/proton_4.11/dlls/ntdll/fsync.c In addition, here's an example of how I think it might be useful to expose it to apps at large in a way that's compatible with existing pthread mutexes: https://github.com/Plagman/glibc/commit/3b01145fa25987f2f93e7eda7f3e7d0f2f77b290 This patch hasn't received nearly as much testing as the Wine fsync code path, but that functionality would provide more CPU-efficient ways for thread pool code to sleep in our game engine. We also use eventfd today. For this, I think the expected upper bound for the per-op futex count would be in the same order of magnitude as the logical CPU count on the target machine, similar as the Wine use-case. Thanks, - Pierre-Loup Thanks, tglx
Re: [PATCH] ocfs: further debugfs cleanups
On 19/7/31 21:21, Greg Kroah-Hartman wrote:
> There is no need to check return value of debugfs_create functions, but
> the last sweep through ocfs missed a number of places where this was
> happening. There is also no need to save the individual dentries for
> the debugfs files, as everything is can just be removed at once when the
> directory is removed.
>
> By getting rid of the file dentries for the debugfs entries, a bit of
> local memory can be saved as well.
>
> Cc: Mark Fasheh
> Cc: Joel Becker
> Cc: Andrew Morton
> Cc: Jia Guo
> Cc: ocfs2-de...@oss.oracle.com
> Cc: Joseph Qi
> Signed-off-by: Greg Kroah-Hartman
Looks good to me.
Reviewed-by: Joseph Qi
> ---
> fs/ocfs2/blockcheck.c| 26 -
> fs/ocfs2/cluster/heartbeat.c | 103 +--
> fs/ocfs2/dlm/dlmcommon.h | 1 -
> fs/ocfs2/dlm/dlmdebug.c | 55 ---
> fs/ocfs2/dlm/dlmdebug.h | 16 +-
> fs/ocfs2/dlm/dlmdomain.c | 6 +-
> fs/ocfs2/dlmglue.c | 20 ++-
> fs/ocfs2/ocfs2.h | 3 -
> fs/ocfs2/super.c | 10 +---
> 9 files changed, 60 insertions(+), 180 deletions(-)
>
> diff --git a/fs/ocfs2/blockcheck.c b/fs/ocfs2/blockcheck.c
> index 429e6a8359a5..eaf042feaf5e 100644
> --- a/fs/ocfs2/blockcheck.c
> +++ b/fs/ocfs2/blockcheck.c
> @@ -231,14 +231,6 @@ static int blockcheck_u64_get(void *data, u64 *val)
> }
> DEFINE_SIMPLE_ATTRIBUTE(blockcheck_fops, blockcheck_u64_get, NULL, "%llu\n");
>
> -static struct dentry *blockcheck_debugfs_create(const char *name,
> - struct dentry *parent,
> - u64 *value)
> -{
> - return debugfs_create_file(name, S_IFREG | S_IRUSR, parent, value,
> -_fops);
> -}
> -
> static void ocfs2_blockcheck_debug_remove(struct ocfs2_blockcheck_stats
> *stats)
> {
> if (stats) {
> @@ -250,16 +242,20 @@ static void ocfs2_blockcheck_debug_remove(struct
> ocfs2_blockcheck_stats *stats)
> static void ocfs2_blockcheck_debug_install(struct ocfs2_blockcheck_stats
> *stats,
> struct dentry *parent)
> {
> - stats->b_debug_dir = debugfs_create_dir("blockcheck", parent);
> + struct dentry *dir;
> +
> + dir = debugfs_create_dir("blockcheck", parent);
> + stats->b_debug_dir = dir;
> +
> + debugfs_create_file("blocks_checked", S_IFREG | S_IRUSR, dir,
> + >b_check_count, _fops);
>
> - blockcheck_debugfs_create("blocks_checked", stats->b_debug_dir,
> - >b_check_count);
> + debugfs_create_file("checksums_failed", S_IFREG | S_IRUSR, dir,
> + >b_failure_count, _fops);
>
> - blockcheck_debugfs_create("checksums_failed", stats->b_debug_dir,
> - >b_failure_count);
> + debugfs_create_file("ecc_recoveries", S_IFREG | S_IRUSR, dir,
> + >b_recover_count, _fops);
>
> - blockcheck_debugfs_create("ecc_recoveries", stats->b_debug_dir,
> - >b_recover_count);
> }
> #else
> static inline void ocfs2_blockcheck_debug_install(struct
> ocfs2_blockcheck_stats *stats,
> diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/ocfs2/cluster/heartbeat.c
> index f1b613327ac8..a368350d4c27 100644
> --- a/fs/ocfs2/cluster/heartbeat.c
> +++ b/fs/ocfs2/cluster/heartbeat.c
> @@ -225,10 +225,6 @@ struct o2hb_region {
> unsigned inthr_region_num;
>
> struct dentry *hr_debug_dir;
> - struct dentry *hr_debug_livenodes;
> - struct dentry *hr_debug_regnum;
> - struct dentry *hr_debug_elapsed_time;
> - struct dentry *hr_debug_pinned;
> struct o2hb_debug_buf *hr_db_livenodes;
> struct o2hb_debug_buf *hr_db_regnum;
> struct o2hb_debug_buf *hr_db_elapsed_time;
> @@ -1394,21 +1390,20 @@ void o2hb_exit(void)
> kfree(o2hb_db_failedregions);
> }
>
> -static struct dentry *o2hb_debug_create(const char *name, struct dentry *dir,
> - struct o2hb_debug_buf **db, int db_len,
> - int type, int size, int len, void *data)
> +static void o2hb_debug_create(const char *name, struct dentry *dir,
> + struct o2hb_debug_buf **db, int db_len, int type,
> + int size, int len, void *data)
> {
> *db = kmalloc(db_len, GFP_KERNEL);
> if (!*db)
> - return NULL;
> + return;
>
> (*db)->db_type = type;
> (*db)->db_size = size;
> (*db)->db_len = len;
> (*db)->db_data = data;
>
> - return debugfs_create_file(name, S_IFREG|S_IRUSR, dir, *db,
> -_debug_fops);
> + debugfs_create_file(name, S_IFREG|S_IRUSR, dir, *db, _debug_fops);
> }
>
> static void
Re: [linux-sunxi] Re: [PATCH 1/1] nvmem: sunxi_sid: fix A64 SID controller support
On Wed, Jul 31, 2019 at 1:43 AM Chen-Yu Tsai wrote:
>
> On Wed, Jul 31, 2019 at 3:15 PM Stefan Mavrodiev wrote:
> >
> > Like in H3, A64 SID controller doesn't return correct data
> > when using direct access. It appears that on A64, SID needs
> > 8 bytes of word_size.
> >
> > Workaround is to enable read by registers.
I came up with identical patch while adding A64 support into
sun8i-thermal driver, so:
> >
> > Signed-off-by: Stefan Mavrodiev
>
> Acked-by: Chen-Yu Tsai
Tested-by: Vasily Khoruzhick
>
> And for single patches, you don't need to write a separate cover letter.
> Just put whatever you need to add after the "---" separator.
>
> > ---
> > drivers/nvmem/sunxi_sid.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
> > index a079a80ddf2c..e26ef1bbf198 100644
> > --- a/drivers/nvmem/sunxi_sid.c
> > +++ b/drivers/nvmem/sunxi_sid.c
> > @@ -186,6 +186,7 @@ static const struct sunxi_sid_cfg sun8i_h3_cfg = {
> > static const struct sunxi_sid_cfg sun50i_a64_cfg = {
> > .value_offset = 0x200,
> > .size = 0x100,
> > + .need_register_readout = true,
> > };
> >
> > static const struct sunxi_sid_cfg sun50i_h6_cfg = {
> > --
> > 2.17.1
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/CAGb2v64tzMypnB5Ho2A-gWPk2yYsmH9tNn%2BOKfb51c%2Bd6pK%3Dkw%40mail.gmail.com.
Re: [RFC PATCH 0/7] xfs: add reflink & dedupe support for fsdax.
On 8/1/19 4:33 AM, Goldwyn Rodrigues wrote: On 19:49 31/07, Shiyang Ruan wrote: This patchset aims to take care of this issue to make reflink and dedupe work correctly in XFS. It is based on Goldwyn's patchsets: "v4 Btrfs dax support" and "Btrfs iomap". I picked up some patches related and made a few fix to make it basically works fine. For dax framework: 1. adapt to the latest change in iomap. For XFS: 1. report the source address and set IOMAP_COW type for those write operations that need COW. 2. update extent list at the end. 3. add file contents comparison function based on dax framework. 4. use xfs_break_layouts() to support dax. Shiyang, I think you used the older patches which does not contain the iomap changes which would call iomap_begin() with two iomaps. I have it in the btrfs-iomap Oh, Sorry for my carelessness. This patchset is built on your "Btrfs iomap". I didn't point it out in cover letter. branch and plan to update it today. It is built on v5.3-rcX, so it should contain the changes which moves the iomap code to the different directory. I will build the dax patches on top of that. However, we are making a big dependency chain here Don't worry. It's fine for me. I'll follow your updates. -- Thanks, Shiyang Ruan.
[PATCH -next] intel_th: msu: Fix possible memory leak in mode_store()
'mode' is malloced in mode_store() and should be freed before leaving
from the error handling cases, otherwise it will cause memory leak.
Fixes: 615c164da0eb ("intel_th: msu: Introduce buffer interface")
Signed-off-by: Wei Yongjun
---
drivers/hwtracing/intel_th/msu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/intel_th/msu.c b/drivers/hwtracing/intel_th/msu.c
index fc9f15f36ad4..2e7a04f566d4 100644
--- a/drivers/hwtracing/intel_th/msu.c
+++ b/drivers/hwtracing/intel_th/msu.c
@@ -1849,8 +1849,10 @@ mode_store(struct device *dev, struct device_attribute
*attr, const char *buf,
mode = kstrndup(buf, len, GFP_KERNEL);
i = match_string(msc_mode, ARRAY_SIZE(msc_mode), mode);
- if (i >= 0)
+ if (i >= 0) {
+ kfree(mode);
goto found;
+ }
/* Buffer sinks only work with a usable IRQ */
if (!msc->do_irq) {
Re: [PATCH v2 08/22] staging: erofs: kill CONFIG_EROFS_FS_IO_MAX_RETRIES
On 2019/7/31 23:57, Gao Xiang wrote: > CONFIG_EROFS_FS_IO_MAX_RETRIES seems a runtime setting > and users have no idea about the change in behaviour. > > Let's remove the setting currently and could turn it > into a module parameter if it's really needed. > > Suggested-by: David Sterba > Signed-off-by: Gao Xiang Reviewed-by: Chao Yu Thanks,
Re: [PATCH RFC 2/2] futex: Implement mechanism to wait on any of several futexes
On 7/31/19 8:22 PM, Zebediah Figura wrote: On 7/31/19 7:45 PM, Thomas Gleixner wrote: If I assume a maximum of 65 futexes which got mentioned in one of the replies then this will allocate 7280 bytes alone for the futex_q array with a stock debian config which has no debug options enabled which would bloat the struct. Adding the futex_wait_block array into the same allocation becomes larger than 8K which already exceeds thelimit of SLUB kmem caches and forces the whole thing into the page allocator directly. This sucks. Also I'm confused about the 64 maximum resulting in 65 futexes comment in one of the mails. Can you please explain what you are trying to do exatly on the user space side? The extra futex comes from the fact that there are a couple of, as it were, out-of-band ways to wake up a thread on Windows. [Specifically, a thread can enter an "alertable" wait in which case it will be woken up by a request from another thread to execute an "asynchronous procedure call".] It's easiest for us to just add another futex to the list in that case. To be clear, the 64/65 distinction is an implementation detail that's pretty much outside the scope of this discussion. I should have just said 65 directly. Sorry about that. I'd also point out, for whatever it's worth, that while 64 is a hard limit, real applications almost never go nearly that high. By far the most common number of primitives to select on is one. Performance-critical code never tends to wait on more than three. The most I've ever seen is twelve. If you'd like to see the user-side source, most of the relevant code is at [1], in particular the functions __fsync_wait_objects() [line 712] and do_single_wait [line 655]. Please feel free to ask for further clarification. [1] https://github.com/ValveSoftware/wine/blob/proton_4.11/dlls/ntdll/fsync.c Thanks, tglx
[PATCH] enetc: Select PHYLIB while CONFIG_FSL_ENETC_VF is set
Like FSL_ENETC, when CONFIG_FSL_ENETC_VF is set,
we should select PHYLIB, otherwise building still fails:
drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_open':
enetc.c:(.text+0x2744): undefined reference to `phy_start'
enetc.c:(.text+0x282c): undefined reference to `phy_disconnect'
drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_close':
enetc.c:(.text+0x28f8): undefined reference to `phy_stop'
enetc.c:(.text+0x2904): undefined reference to `phy_disconnect'
drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x3f8): undefined
reference to `phy_ethtool_get_link_ksettings'
drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x400): undefined
reference to `phy_ethtool_set_link_ksettings'
Reported-by: Hulk Robot
Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Signed-off-by: YueHaibing
---
drivers/net/ethernet/freescale/enetc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig
b/drivers/net/ethernet/freescale/enetc/Kconfig
index 46fdf36b..04a59db 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -13,6 +13,7 @@ config FSL_ENETC
config FSL_ENETC_VF
tristate "ENETC VF driver"
depends on PCI && PCI_MSI && (ARCH_LAYERSCAPE || COMPILE_TEST)
+ select PHYLIB
help
This driver supports NXP ENETC gigabit ethernet controller PCIe
virtual function (VF) devices enabled by the ENETC PF driver.
--
2.7.4
Re: Build regressions/improvements in v5.3-rc2
Geert Uytterhoeven writes: > Below is the list of build error/warning regressions/improvements in > v5.3-rc2[1] compared to v5.2[2]. > > Summarized: > - build errors: +10/-1 > - build warnings: +136/-133 > > JFYI, when comparing v5.3-rc2[1] to v5.3-rc1[3], the summaries are: > - build errors: +0/-1 > - build warnings: +125/-31 > > Note that there may be false regressions, as some logs are incomplete. > Still, they're build errors/warnings. > > Happy fixing! ;-) > > Thanks to the linux-next team for providing the build service. > > [1] > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/609488bc979f99f805f34e9a32c1e3b71179d10b/ > (241 out of 242 configs) > [2] > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/0ecfebd2b52404ae0c54a878c872bb93363ada36/ > (all 242 configs) > [3] > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/5f9e832c137075045d15cd6899ab0505cfb2ca4b/ > (241 out of 242 configs) > > > *** ERRORS *** > > 10 error regressions: ... > + /kisskb/src/drivers/net/wireless/intel/iwlwifi/fw/dbg.c: error: call to > '__compiletime_assert_2446' declared with attribute error: BUILD_BUG_ON > failed: err_str[sizeof(err_str) - 2] != '\n': => 2445:3 > + /kisskb/src/drivers/net/wireless/intel/iwlwifi/fw/dbg.c: error: call to > '__compiletime_assert_2452' declared with attribute error: BUILD_BUG_ON > failed: err_str[sizeof(err_str) - 2] != '\n': => 2451:3 > + /kisskb/src/drivers/net/wireless/intel/iwlwifi/fw/dbg.c: error: call to > '__compiletime_assert_2790' declared with attribute error: BUILD_BUG_ON > failed: invalid_ap_str[sizeof(invalid_ap_str) - 2] != '\n': => 2789:5 > + /kisskb/src/drivers/net/wireless/intel/iwlwifi/fw/dbg.c: error: call to > '__compiletime_assert_2801' declared with attribute error: BUILD_BUG_ON > failed: invalid_ap_str[sizeof(invalid_ap_str) - 2] != '\n': => 2800:5 These have been reported and a fix is apparently on its way, but no sign of it yet. https://lore.kernel.org/lkml/20190712001708.170259-1-ndesaulni...@google.com/ cheers
[PATCH] ima: Allow to import the blacklisted cert signed by secondary CA cert
Similar to .ima, the cert imported to .ima_blacklist is able to be
authenticated by a secondary CA cert.
Signed-off-by: Jia Zhang
---
include/keys/system_keyring.h| 6 ++
security/integrity/digsig.c | 6 --
security/integrity/ima/ima_mok.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index c1a96fd..7dc91db 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -31,6 +31,12 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
#define restrict_link_by_builtin_and_secondary_trusted
restrict_link_by_builtin_trusted
#endif
+#ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
+#define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
+#else
+#define restrict_link_to_ima restrict_link_by_builtin_trusted
+#endif
+
#ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
extern int mark_hash_blacklisted(const char *hash);
extern int is_hash_blacklisted(const u8 *hash, size_t hash_len,
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 868ade3..c6f3384 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -33,12 +33,6 @@
".platform",
};
-#ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
-#define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
-#else
-#define restrict_link_to_ima restrict_link_by_builtin_trusted
-#endif
-
int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
const char *digest, int digestlen)
{
diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
index 36cadad..6d0b12d 100644
--- a/security/integrity/ima/ima_mok.c
+++ b/security/integrity/ima/ima_mok.c
@@ -31,7 +31,7 @@ __init int ima_mok_init(void)
if (!restriction)
panic("Can't allocate IMA blacklist restriction.");
- restriction->check = restrict_link_by_builtin_trusted;
+ restriction->check = restrict_link_to_ima;
ima_blacklist_keyring = keyring_alloc(".ima_blacklist",
KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
--
1.8.3.1
Re: [PATCH RFC 2/2] futex: Implement mechanism to wait on any of several futexes
On 7/31/19 7:45 PM, Thomas Gleixner wrote: If I assume a maximum of 65 futexes which got mentioned in one of the replies then this will allocate 7280 bytes alone for the futex_q array with a stock debian config which has no debug options enabled which would bloat the struct. Adding the futex_wait_block array into the same allocation becomes larger than 8K which already exceeds thelimit of SLUB kmem caches and forces the whole thing into the page allocator directly. This sucks. Also I'm confused about the 64 maximum resulting in 65 futexes comment in one of the mails. Can you please explain what you are trying to do exatly on the user space side? The extra futex comes from the fact that there are a couple of, as it were, out-of-band ways to wake up a thread on Windows. [Specifically, a thread can enter an "alertable" wait in which case it will be woken up by a request from another thread to execute an "asynchronous procedure call".] It's easiest for us to just add another futex to the list in that case. I'd also point out, for whatever it's worth, that while 64 is a hard limit, real applications almost never go nearly that high. By far the most common number of primitives to select on is one. Performance-critical code never tends to wait on more than three. The most I've ever seen is twelve. If you'd like to see the user-side source, most of the relevant code is at [1], in particular the functions __fsync_wait_objects() [line 712] and do_single_wait [line 655]. Please feel free to ask for further clarification. [1] https://github.com/ValveSoftware/wine/blob/proton_4.11/dlls/ntdll/fsync.c Thanks, tglx
Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
Nick Desaulniers writes: > Commit r353569 in prerelease Clang-9 is producing a linkage failure: > > ld: drivers/net/wireless/intel/iwlwifi/fw/dbg.o: > in function `_iwl_fw_dbg_apply_point': > dbg.c:(.text+0x827a): undefined reference to `__compiletime_assert_2387' This breakage is also seen in older GCC versions (v4.6.3 at least): drivers/net/wireless/intel/iwlwifi/fw/dbg.c: In function 'iwl_fw_dbg_info_apply.isra.10': drivers/net/wireless/intel/iwlwifi/fw/dbg.c:2445:3: error: call to '__compiletime_assert_2446' declared with attribute error: BUILD_BUG_ON failed: err_str[sizeof(err_str) - 2] != '\n' drivers/net/wireless/intel/iwlwifi/fw/dbg.c:2451:3: error: call to '__compiletime_assert_2452' declared with attribute error: BUILD_BUG_ON failed: err_str[sizeof(err_str) - 2] != '\n' drivers/net/wireless/intel/iwlwifi/fw/dbg.c: In function '_iwl_fw_dbg_apply_point': drivers/net/wireless/intel/iwlwifi/fw/dbg.c:2789:5: error: call to '__compiletime_assert_2790' declared with attribute error: BUILD_BUG_ON failed: invalid_ap_str[sizeof(invalid_ap_str) - 2] != '\n' drivers/net/wireless/intel/iwlwifi/fw/dbg.c:2800:5: error: call to '__compiletime_assert_2801' declared with attribute error: BUILD_BUG_ON failed: invalid_ap_str[sizeof(invalid_ap_str) - 2] != '\n' http://kisskb.ellerman.id.au/kisskb/buildresult/13902155/ Luca, you said this was already fixed in your internal tree, and the fix would appear soon in next, but I don't see anything in linux-next? cheers
