Re: [PATCH v5 3/4] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap
On 06/27/18 at 11:14pm, Pavel Tatashin wrote:
> Honestly, I do not like this new agrument, but it will do for now. I
> could not think of a better way without rewriting everything.
>
> Reviewed-by: Pavel Tatashin
>
> However, I will submit a series of patches to cleanup sparse.c and
> completely remove large and confusing temporary buffers: map_map, and
> usemap_map. In those patches, I will remove alloc_usemap_and_memmap().
Great, look forward to seeing them, I can help review.
> On Tue, Jun 26, 2018 at 9:31 PM Baoquan He wrote:
> >
> > alloc_usemap_and_memmap() is passing in a "void *" that points to
> > usemap_map or memmap_map. In next patch we will change both of the
> > map allocation from taking 'NR_MEM_SECTIONS' as the length to taking
> > 'nr_present_sections' as the length. After that, the passed in 'void*'
> > needs to update as things get consumed. But, it knows only the
> > quantity of objects consumed and not the type. This effectively
> > tells it enough about the type to let it update the pointer as
> > objects are consumed.
> >
> > Signed-off-by: Baoquan He
> > ---
> > mm/sparse.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index 71ad53da2cd1..b2848cc6e32a 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
> > @@ -489,10 +489,12 @@ void __weak __meminit
> > vmemmap_populate_print_last(void)
> > /**
> > * alloc_usemap_and_memmap - memory alloction for pageblock flags and
> > vmemmap
> > * @map: usemap_map for pageblock flags or mmap_map for vmemmap
> > + * @unit_size: size of map unit
> > */
> > static void __init alloc_usemap_and_memmap(void (*alloc_func)
> > (void *, unsigned long, unsigned
> > long,
> > - unsigned long, int), void *data)
> > + unsigned long, int), void *data,
> > + int data_unit_size)
> > {
> > unsigned long pnum;
> > unsigned long map_count;
> > @@ -569,7 +571,8 @@ void __init sparse_init(void)
> > if (!usemap_map)
> > panic("can not allocate usemap_map\n");
> > alloc_usemap_and_memmap(sparse_early_usemaps_alloc_node,
> > - (void *)usemap_map);
> > + (void *)usemap_map,
> > + sizeof(usemap_map[0]));
> >
> > #ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
> > size2 = sizeof(struct page *) * NR_MEM_SECTIONS;
> > @@ -577,7 +580,8 @@ void __init sparse_init(void)
> > if (!map_map)
> > panic("can not allocate map_map\n");
> > alloc_usemap_and_memmap(sparse_early_mem_maps_alloc_node,
> > - (void *)map_map);
> > + (void *)map_map,
> > + sizeof(map_map[0]));
> > #endif
> >
> > for_each_present_section_nr(0, pnum) {
> > --
> > 2.13.6
> >
Re: [PATCH v21 2/4] mailbox: mediatek: Add Mediatek CMDQ driver
On Thu, 2018-06-28 at 09:57 +0800, CK Hu wrote:
> Hi, Houlong:
>
> On Wed, 2018-06-27 at 19:53 +0800, houlong wei wrote:
> > On Wed, 2018-02-21 at 11:53 +0800, CK Hu wrote:
> > > Hi, Houlong:
> > >
> > > I've one inline comment.
> > >
> > > On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote:
> > > > From: "hs.l...@mediatek.com"
> > > >
> > > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > > CMDQ is used to help write registers with critical time limitation,
> > > > such as updating display configuration during the vblank. It controls
> > > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > > Currently, CMDQ only supports display related hardwares, but we expect
> > > > it can be extended to other hardwares for future requirements.
> > > >
> > > > Signed-off-by: Houlong Wei
> > > > Signed-off-by: HS Liao
> > > > Signed-off-by: CK Hu
> > > > ---
> > > > drivers/mailbox/Kconfig | 10 +
> > > > drivers/mailbox/Makefile |2 +
> > > > drivers/mailbox/mtk-cmdq-mailbox.c | 594
> > > > ++
> > > > include/linux/mailbox/mtk-cmdq-mailbox.h | 77
> > > > 4 files changed, 683 insertions(+)
> > > > create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> > > > create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> > > >
> > > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> > > > index ba2f152..43bb26f 100644
> > > > --- a/drivers/mailbox/Kconfig
> > > > +++ b/drivers/mailbox/Kconfig
> > > > @@ -171,4 +171,14 @@ config BCM_FLEXRM_MBOX
> > > > Mailbox implementation of the Broadcom FlexRM ring manager,
> > > > which provides access to various offload engines on Broadcom
> > > > SoCs. Say Y here if you want to use the Broadcom FlexRM.
> > > > +
>
> [...]
>
> > > > +
> > > > +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread
> > > > *thread)
> > > > +{
> > > > + struct cmdq *cmdq;
> > > > + struct cmdq_task *task;
> > > > + unsigned long curr_pa, end_pa;
> > > > +
> > > > + cmdq = dev_get_drvdata(thread->chan->mbox->dev);
> > > > +
> > > > + /* Client should not flush new tasks if suspended. */
> > > > + WARN_ON(cmdq->suspended);
> > > > +
> > > > + task = kzalloc(sizeof(*task), GFP_ATOMIC);
> > > > + task->cmdq = cmdq;
> > > > + INIT_LIST_HEAD(&task->list_entry);
> > > > + task->pa_base = pkt->pa_base;
> > > > + task->thread = thread;
> > > > + task->pkt = pkt;
> > > > +
> > > > + if (list_empty(&thread->task_busy_list)) {
> > > > + WARN_ON(clk_enable(cmdq->clock) < 0);
> > > > + WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
> > > > +
> > > > + writel(task->pa_base, thread->base +
> > > > CMDQ_THR_CURR_ADDR);
> > > > + writel(task->pa_base + pkt->cmd_buf_size,
> > > > + thread->base + CMDQ_THR_END_ADDR);
> > > > + writel(CMDQ_THR_IRQ_EN, thread->base +
> > > > CMDQ_THR_IRQ_ENABLE);
> > > > + writel(CMDQ_THR_ENABLED, thread->base +
> > > > CMDQ_THR_ENABLE_TASK);
> > > > +
> > > > + mod_timer(&thread->timeout,
> > > > + jiffies + msecs_to_jiffies(CMDQ_TIMEOUT_MS));
> > > > + } else {
> > > > + WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
> > > > + curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR);
> > > > + end_pa = readl(thread->base + CMDQ_THR_END_ADDR);
> > > > +
> > > > + /*
> > > > +* Atomic execution should remove the following wfe,
> > > > i.e. only
> > > > +* wait event at first task, and prevent to pause when
> > > > running.
> > > > +*/
> > > > + if (thread->atomic_exec) {
> > > > + /* GCE is executing if command is not WFE */
> > > > + if (!cmdq_thread_is_in_wfe(thread)) {
> > > > + cmdq_thread_resume(thread);
> > > > + cmdq_thread_wait_end(thread, end_pa);
> > > > + WARN_ON(cmdq_thread_suspend(cmdq,
> > > > thread) < 0);
> > > > + /* set to this task directly */
> > > > + writel(task->pa_base,
> > > > + thread->base +
> > > > CMDQ_THR_CURR_ADDR);
> > > > + } else {
> > > > + cmdq_task_insert_into_thread(task);
> > > > + cmdq_task_remove_wfe(task);
> > > > + smp_mb(); /* modify jump before enable
> > > > thread */
> > > > + }
> > > > + } else {
> > > > + /* check boundary */
> > > > + if (curr_pa == end_pa - CMDQ
Re: [[LINUX PATCH v10] 1/4] Devicetree: Add pl353 smc controller devicetree binding information
On Thu, Jun 21, 2018 at 8:43 AM Naga Sureshkumar Relli wrote: Thanks for your patch! > Add pl353 static memory controller devicetree binding information. > > Signed-off-by: Naga Sureshkumar Relli > +Device tree bindings for ARM PL353 static memory controller > + > +PL353 static memory controller supports two kinds of memory > +interfaces.i.e NAND and SRAM/NOR interfaces. > +The actual devices are instantiated from the child nodes of pl353 smc node. See and reference the special PrimeCell DT bindings: Documentation/devicetree/bindings/arm/primecell.txt > +Required properties: > +- compatible : Must be "arm,pl353-smc-r2p1" Should be: "arm,pl353-smc-r2p1", "arm,primecell"; It will be possible for the Linux AMBA core to probe the device from just reading out the primecell ID registers, so the first compatible string will not even be used by many OS:es. > +- reg : Controller registers map and length. > +- clock-names : List of input clock names - "ref_clk", "aper_clk" > + (See clock bindings for details). The AMBA primecell peripheral clock (clocking the silicon) must be named "apb_pclk". > +- clocks : Clock phandles (see clock bindings for details). > +- address-cells: Must be 1. > +- size-cells : Must be 1. > + > +Child nodes: > + For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash" drivers are > +supported as child nodes. > + > +for NAND partition information please refer the below file > +Documentation/devicetree/bindings/mtd/partition.txt > + > +Example: > + smcc: memory-controller@e000e000 > + compatible = "arm,pl353-smc-r2p1" Add , "arm,primecell"; > + clock-names = "memclk", "aclk"; This doesn't even have the same name as in the bindings above, I think the latter should be named "apb_pclk". Otherwise it looks good! Yours, Linus Walleij
Re: [[LINUX PATCH v10] 2/4] memory: pl353: Add driver for arm pl353 static memory controller
On Thu, Jun 21, 2018 at 8:43 AM Naga Sureshkumar Relli wrote: > Add driver for arm pl353 static memory controller. This controller is used in > Xilinx Zynq SoC for interfacing the NAND and NOR/SRAM memory devices. > > Signed-off-by: Naga Sureshkumar Relli (...) > +config PL353_SMC > + tristate "ARM PL35X Static Memory Controller(SMC) driver" > + default y > + depends on ARM > + depends on ARCH_ZYNQ depends on ARM_AMBA > +#include This is a PrimeCell with the ARM primecell ID registers specified, so it should not use platform device. Use It further needs to match on these magic values (found in 0xfe0 etc) and use the name "apb_pclk" for the peripheral (silicon) clock. See examples such as: drivers/mmc/host/mmci.c drivers/tty/serial/amba-pl011.c drivers/video/fbdev/amba-clcd.c drivers/hwtracing/coresight/* etc for examples. Also see and reference the special PrimeCell DT bindings: Documentation/devicetree/bindings/arm/primecell.txt Yours, Linus Walleij
Re: [RFC PATCH 2/5] dt-bindings: xilinx: Add missing zynq boards
On 28.6.2018 07:42, Luis Araneda wrote: > The bindings were missing when adding the device-tree files > Also, improve description of existing boards > > Signed-off-by: Luis Araneda > --- > .../devicetree/bindings/arm/xilinx.txt| 22 +-- > 1 file changed, 20 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt > b/Documentation/devicetree/bindings/arm/xilinx.txt > index b9043bc35..f1e911058 100644 > --- a/Documentation/devicetree/bindings/arm/xilinx.txt > +++ b/Documentation/devicetree/bindings/arm/xilinx.txt > @@ -8,15 +8,33 @@ Required root node properties: > > Additional compatible strings: > > -- Xilinx internal board cc108 > +- Xilinx CC108 board No reason to remove internal word from here. >"xlnx,zynq-cc108" > > -- Xilinx internal board zc770 with different FMC cards > +- Avnet MicroZed board > + "avnet,zynq-microzed" > + > +- Adapteva Parallella board > + "adapteva,parallella" > + > +- Xilinx ZC702 board > + "xlnx,zynq-zc702" > + > +- Xilinx ZC706 board > + "xlnx,zynq-zc706" > + > +- Xilinx ZC770 board, with different FMC cards >"xlnx,zynq-zc770-xm010" >"xlnx,zynq-zc770-xm011" >"xlnx,zynq-zc770-xm012" >"xlnx,zynq-zc770-xm013" > > +- Avnet ZedBoard board > + "avnet,zynq-zed" > + > +- Digilent Zybo board > + "digilent,zynq-zybo" > + > - Digilent Zybo Z7 board >"digilent,zynq-zybo-z7" > > Not a problem to add missing strings. Thanks, Michal
Re: [RFC PATCH 5/5] arm: dts: zynq: remove "zynq" prefix from compatible property
On 28.6.2018 07:42, Luis Araneda wrote:
> The value "zynq" isn't officially part of the model on any board.
> Additionally, the value is redundant as it's included in a
> subsequent value of the property.
>
> Signed-off-by: Luis Araneda
> ---
> .../devicetree/bindings/arm/xilinx.txt| 22 +--
> arch/arm/boot/dts/zynq-cc108.dts | 2 +-
> arch/arm/boot/dts/zynq-microzed.dts | 2 +-
> arch/arm/boot/dts/zynq-zc702.dts | 2 +-
> arch/arm/boot/dts/zynq-zc706.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm010.dts| 2 +-
> arch/arm/boot/dts/zynq-zc770-xm011.dts| 2 +-
> arch/arm/boot/dts/zynq-zc770-xm012.dts| 2 +-
> arch/arm/boot/dts/zynq-zc770-xm013.dts| 2 +-
> arch/arm/boot/dts/zynq-zedboard.dts | 2 +-
> arch/arm/boot/dts/zynq-zybo-z7.dts| 2 +-
> arch/arm/boot/dts/zynq-zybo.dts | 2 +-
> 12 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt
> b/Documentation/devicetree/bindings/arm/xilinx.txt
> index d10adc4d0..0785acce4 100644
> --- a/Documentation/devicetree/bindings/arm/xilinx.txt
> +++ b/Documentation/devicetree/bindings/arm/xilinx.txt
> @@ -9,34 +9,34 @@ Required root node properties:
> Additional compatible strings:
>
> - Xilinx CC108 board
> - "xlnx,zynq-cc108"
> + "xlnx,cc108"
>
> - Avnet MicroZed board
> - "avnet,zynq-microzed"
> + "avnet,microzed"
>
> - Adapteva Parallella board
>"adapteva,parallella"
>
> - Xilinx ZC702 board
> - "xlnx,zynq-zc702"
> + "xlnx,zc702"
>
> - Xilinx ZC706 board
> - "xlnx,zynq-zc706"
> + "xlnx,zc706"
>
> - Xilinx ZC770 board, with different FMC cards
> - "xlnx,zynq-zc770-xm010"
> - "xlnx,zynq-zc770-xm011"
> - "xlnx,zynq-zc770-xm012"
> - "xlnx,zynq-zc770-xm013"
> + "xlnx,zc770-xm010"
> + "xlnx,zc770-xm011"
> + "xlnx,zc770-xm012"
> + "xlnx,zc770-xm013"
>
> - Avnet ZedBoard board
> - "avnet,zynq-zedboard"
> + "avnet,zedboard"
>
> - Digilent Zybo board
> - "digilent,zynq-zybo"
> + "digilent,zybo"
>
> - Digilent Zybo Z7 board
> - "digilent,zynq-zybo-z7"
> + "digilent,zybo-z7"
>
> ---
>
> diff --git a/arch/arm/boot/dts/zynq-cc108.dts
> b/arch/arm/boot/dts/zynq-cc108.dts
> index 8b9ab9bba..ccff20099 100644
> --- a/arch/arm/boot/dts/zynq-cc108.dts
> +++ b/arch/arm/boot/dts/zynq-cc108.dts
> @@ -13,7 +13,7 @@
>
> / {
> model = "Xilinx CC108 board";
> - compatible = "xlnx,zynq-cc108", "xlnx,zynq-7000";
> + compatible = "xlnx,cc108", "xlnx,zynq-7000";
>
> aliases {
> ethernet0 = &gem0;
> diff --git a/arch/arm/boot/dts/zynq-microzed.dts
> b/arch/arm/boot/dts/zynq-microzed.dts
> index 3cc957428..ef55adb02 100644
> --- a/arch/arm/boot/dts/zynq-microzed.dts
> +++ b/arch/arm/boot/dts/zynq-microzed.dts
> @@ -8,7 +8,7 @@
>
> / {
> model = "Avnet MicroZed board";
> - compatible = "avnet,zynq-microzed", "xlnx,zynq-7000";
> + compatible = "avnet,microzed", "xlnx,zynq-7000";
>
> aliases {
> ethernet0 = &gem0;
> diff --git a/arch/arm/boot/dts/zynq-zc702.dts
> b/arch/arm/boot/dts/zynq-zc702.dts
> index 3f84b94db..bd633a9bc 100644
> --- a/arch/arm/boot/dts/zynq-zc702.dts
> +++ b/arch/arm/boot/dts/zynq-zc702.dts
> @@ -8,7 +8,7 @@
>
> / {
> model = "Xilinx ZC702 board";
> - compatible = "xlnx,zynq-zc702", "xlnx,zynq-7000";
> + compatible = "xlnx,zc702", "xlnx,zynq-7000";
>
> aliases {
> ethernet0 = &gem0;
> diff --git a/arch/arm/boot/dts/zynq-zc706.dts
> b/arch/arm/boot/dts/zynq-zc706.dts
> index a15908cac..f4805f01b 100644
> --- a/arch/arm/boot/dts/zynq-zc706.dts
> +++ b/arch/arm/boot/dts/zynq-zc706.dts
> @@ -8,7 +8,7 @@
>
> / {
> model = "Xilinx ZC706 board";
> - compatible = "xlnx,zynq-zc706", "xlnx,zynq-7000";
> + compatible = "xlnx,zc706", "xlnx,zynq-7000";
>
> aliases {
> ethernet0 = &gem0;
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm010.dts
> b/arch/arm/boot/dts/zynq-zc770-xm010.dts
> index 0e1bfdd34..21f457656 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm010.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm010.dts
> @@ -9,7 +9,7 @@
>
> / {
> model = "Xilinx ZC770 XM010 board";
> - compatible = "xlnx,zynq-zc770-xm010", "xlnx,zynq-7000";
> + compatible = "xlnx,zc770-xm010", "xlnx,zynq-7000";
>
> aliases {
> ethernet0 = &gem0;
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm011.dts
> b/arch/arm/boot/dts/zynq-zc770-xm011.dts
> index b7f65862c..e4a0b2629 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm011.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm011.dts
> @@ -9,7 +9,7 @@
>
> / {
> model = "Xilinx ZC770 XM011 board";
> - compatible = "xlnx,zynq-zc770-xm011", "xlnx,zynq-7000";
> + compatible = "xlnx,zc770-xm011", "xlnx,zynq-7000";
>
> aliases {
>
Re: [RFC PATCH 4/5] arm: dts: zynq: rename board zed to zedboard
On 28.6.2018 07:42, Luis Araneda wrote:
> The real name of the board is ZedBoard, from Avnet
>
> Signed-off-by: Luis Araneda
> ---
> Documentation/devicetree/bindings/arm/xilinx.txt | 2 +-
> arch/arm/boot/dts/Makefile| 2 +-
> arch/arm/boot/dts/{zynq-zed.dts => zynq-zedboard.dts} | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
> rename arch/arm/boot/dts/{zynq-zed.dts => zynq-zedboard.dts} (93%)
>
> diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt
> b/Documentation/devicetree/bindings/arm/xilinx.txt
> index f1e911058..d10adc4d0 100644
> --- a/Documentation/devicetree/bindings/arm/xilinx.txt
> +++ b/Documentation/devicetree/bindings/arm/xilinx.txt
> @@ -30,7 +30,7 @@ Additional compatible strings:
>"xlnx,zynq-zc770-xm013"
>
> - Avnet ZedBoard board
> - "avnet,zynq-zed"
> + "avnet,zynq-zedboard"
>
> - Digilent Zybo board
>"digilent,zynq-zybo"
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 37a3de760..e4c39e26f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1108,7 +1108,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
> zynq-zc770-xm011.dtb \
> zynq-zc770-xm012.dtb \
> zynq-zc770-xm013.dtb \
> - zynq-zed.dtb \
> + zynq-zedboard.dtb \
> zynq-zybo.dtb \
> zynq-zybo-z7.dtb
> dtb-$(CONFIG_MACH_ARMADA_370) += \
> diff --git a/arch/arm/boot/dts/zynq-zed.dts
> b/arch/arm/boot/dts/zynq-zedboard.dts
> similarity index 93%
> rename from arch/arm/boot/dts/zynq-zed.dts
> rename to arch/arm/boot/dts/zynq-zedboard.dts
> index bf3e26dbf..540581c56 100644
> --- a/arch/arm/boot/dts/zynq-zed.dts
> +++ b/arch/arm/boot/dts/zynq-zedboard.dts
> @@ -8,7 +8,7 @@
>
> / {
> model = "Avnet ZedBoard board";
> - compatible = "avnet,zynq-zed", "xlnx,zynq-7000";
> + compatible = "avnet,zynq-zedboard", "xlnx,zynq-7000";
>
> aliases {
> ethernet0 = &gem0;
>
It will just cause confusion and I can't see any benefit to rename this
file. If you want to state different compatible string with full board
name I am fine with that but that's it.
Thanks,
Michal
Re: moving affs + RDB partition support to staging?
Anything done to RDBs for Linux must remain 100.000% compatible with existing
Amiga equipment. Otherwise, what's the point of bothering to use RDBs?
Note, as an experiment I had a CrossDOS partition on a hard disk briefly. So
some amazing nonsense is possible. I concluded that for me it was not something
I wanted to do. Alternative techniques worked well enough.
That brings to the fore an interesting question. Why bother with RDBs over 2TB
unless you want a disk with one single partition? This Win10 monster I am using
has a modest BIOS driver partition for the OS and a giant data partition. That
smaller partition would easily work with any RDB/Filesystem combination since
2.0. So there are some good workarounds that are probably "safer" and at least
as flexible as RDBs, one Linux has used for a very long time, too.
With that it is easy in concept to put together a dual boot system with all the
disks and partitions readable if you play the proper games at the filesystem
level and keep individual partitions small. The filesystem would have to take on
some of the attributes of a device driver, though. A 281 TB disk made up of 2 TB
partitions should be possible to create if you think it through. (Note that with
RDBs the CHS disk description is purely an abstraction that has no relationship
to anything inside the disk. The same tricks could exist at the filesystem level.)
As for existing tools screwing up, do you think that is an excuse to perpetuate
the failure?
If we are speaking Linux for m68k, what does it do when confronted with which is
described with a size larger than 32 bits? Before it had everything inside it
that refers to positions within a file by byte index with an __int64 type of
storage did it throw up it's hands, corrupt the disk, or what? If the m68k Linux
is a failure perhaps it doesn't matter what you do for Linuxoids. (I'll stick
with the x64 version in that case. And I never go back to earlier versions for
games since I consider a good compiler is the best game around. It's better than
a blank piece of paper for possibilities.)
As I have said, for the RDB parser fix the famndool thing. Do fix it right in
such a manner that if somebody compiles it against a version with no 64 bit
device code it will throw a proper overflow error and protect the user. Users
are dumb. We like to think of ourselves as smart. Let's try to be smart about
this where we can so fingers can't point back at us rather than the fool that
made some other error.
And do remember, I am merely (and vociferously) advising rather than dictating.
You don't need my approval to proceed. I may want my name noted as an early
contributor only. Meanwhile I spit out ideas as they come to me. One or more of
them might be good. And offering alternatives is better than simply saying "No"
most of the time.
If people are using RDBs for TB level disks I doubt they can remember which is
the left shoe when they are getting dressed in the morning before going out in
the yard to beat some dead horses. Or else maybe they just want to see how far
they can flog the m68k architecture as a mental challenge. In that case, taking
it too seriously could hurt. Note that I am mostly ignoring m68k Linux. People
using that are hard core. People using x86/x64 Linux aren't such hard core
folks. And I bet most of them want to read the disks so they can copy stuff to
Amiga Forever or WinUAE running on other architectures. So TB is not likely to
be an issue for them, either.
{^_^}
On 20180627 22:43, Michael Schmitz wrote:
Joanne,
Linux on m68k has supported lseek64 (or llseek) for a long time (from glibc
version 2.1 according to what I found). About the only area where we are limited
by 32 bits is the virtual memory size.
I'm not proposing to modify the RDB format definition, though an extension to
store 64 bit offsets separate from the 32 bit ones would be one way to make
certain such disks are safe to use on 3.1 and earlier versions of AmigaOS.
(Another one would be to modify the disk drivers on older versions to do the
offset calculation in 64 bit, and check for overflow just as we do here. Not
sure whether that's feasible. And as you so eloquently describe, we can't rely
on users listening.)
Either way, we need the cooperation of partitioning tool writers to ensure
partition information that is prone to overflows is never stored in the 32 bit,
classic RDB. That appears to have failed already, as Martin's experience
illustrates.
I'm only concerned with fixing the (dangerous) but in the Linux partition format
parser for RDB. Refusing to use any partitions that will cause havoc on old
AmigaOS versions is all I can do to try and get the users' attention.
Your warning makes me wonder whether the log message should just say 'report
this bug to linux-m...@vger.kernel.org' to
Re: [RFC PATCH 3/5] arm: dts: zynq: correct and improve the model property of dt files
On 28.6.2018 07:42, Luis Araneda wrote:
> Replace the current value of the model property by a more accurate
> description of each board (which includes the manufacturer), as some
> of the boards had the same value ("Xilinx Zynq")
>
> Signed-off-by: Luis Araneda
> ---
> arch/arm/boot/dts/zynq-cc108.dts | 2 +-
> arch/arm/boot/dts/zynq-microzed.dts| 2 +-
> arch/arm/boot/dts/zynq-parallella.dts | 2 +-
> arch/arm/boot/dts/zynq-zc702.dts | 2 +-
> arch/arm/boot/dts/zynq-zc706.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm010.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm011.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm012.dts | 2 +-
> arch/arm/boot/dts/zynq-zc770-xm013.dts | 2 +-
> arch/arm/boot/dts/zynq-zed.dts | 2 +-
> arch/arm/boot/dts/zynq-zybo-z7.dts | 2 +-
> arch/arm/boot/dts/zynq-zybo.dts| 2 +-
> 12 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/zynq-cc108.dts
> b/arch/arm/boot/dts/zynq-cc108.dts
> index 1a0f631c1..8b9ab9bba 100644
> --- a/arch/arm/boot/dts/zynq-cc108.dts
> +++ b/arch/arm/boot/dts/zynq-cc108.dts
> @@ -12,8 +12,8 @@
> /include/ "zynq-7000.dtsi"
>
> / {
> + model = "Xilinx CC108 board";
> compatible = "xlnx,zynq-cc108", "xlnx,zynq-7000";
> - model = "Xilinx Zynq";
>
> aliases {
> ethernet0 = &gem0;
> diff --git a/arch/arm/boot/dts/zynq-microzed.dts
> b/arch/arm/boot/dts/zynq-microzed.dts
> index e40f40a7f..3cc957428 100644
> --- a/arch/arm/boot/dts/zynq-microzed.dts
> +++ b/arch/arm/boot/dts/zynq-microzed.dts
> @@ -7,7 +7,7 @@
> /include/ "zynq-7000.dtsi"
>
> / {
> - model = "Zynq MicroZED Development Board";
> + model = "Avnet MicroZed board";
> compatible = "avnet,zynq-microzed", "xlnx,zynq-7000";
>
> aliases {
> diff --git a/arch/arm/boot/dts/zynq-parallella.dts
> b/arch/arm/boot/dts/zynq-parallella.dts
> index c05f4b67d..54592aeb9 100644
> --- a/arch/arm/boot/dts/zynq-parallella.dts
> +++ b/arch/arm/boot/dts/zynq-parallella.dts
> @@ -12,7 +12,7 @@
> /include/ "zynq-7000.dtsi"
>
> / {
> - model = "Adapteva Parallella Board";
> + model = "Adapteva Parallella board";
> compatible = "adapteva,parallella", "xlnx,zynq-7000";
>
> aliases {
> diff --git a/arch/arm/boot/dts/zynq-zc702.dts
> b/arch/arm/boot/dts/zynq-zc702.dts
> index f2330b0cb..3f84b94db 100644
> --- a/arch/arm/boot/dts/zynq-zc702.dts
> +++ b/arch/arm/boot/dts/zynq-zc702.dts
> @@ -7,7 +7,7 @@
> #include "zynq-7000.dtsi"
>
> / {
> - model = "Zynq ZC702 Development Board";
> + model = "Xilinx ZC702 board";
> compatible = "xlnx,zynq-zc702", "xlnx,zynq-7000";
>
> aliases {
> diff --git a/arch/arm/boot/dts/zynq-zc706.dts
> b/arch/arm/boot/dts/zynq-zc706.dts
> index 3ad1260ff..a15908cac 100644
> --- a/arch/arm/boot/dts/zynq-zc706.dts
> +++ b/arch/arm/boot/dts/zynq-zc706.dts
> @@ -7,7 +7,7 @@
> #include "zynq-7000.dtsi"
>
> / {
> - model = "Zynq ZC706 Development Board";
> + model = "Xilinx ZC706 board";
> compatible = "xlnx,zynq-zc706", "xlnx,zynq-7000";
>
> aliases {
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm010.dts
> b/arch/arm/boot/dts/zynq-zc770-xm010.dts
> index 6884f1ad6..0e1bfdd34 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm010.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm010.dts
> @@ -8,8 +8,8 @@
> #include "zynq-7000.dtsi"
>
> / {
> + model = "Xilinx ZC770 XM010 board";
> compatible = "xlnx,zynq-zc770-xm010", "xlnx,zynq-7000";
> - model = "Xilinx Zynq";
>
> aliases {
> ethernet0 = &gem0;
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm011.dts
> b/arch/arm/boot/dts/zynq-zc770-xm011.dts
> index b78883cee..b7f65862c 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm011.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm011.dts
> @@ -8,8 +8,8 @@
> #include "zynq-7000.dtsi"
>
> / {
> + model = "Xilinx ZC770 XM011 board";
> compatible = "xlnx,zynq-zc770-xm011", "xlnx,zynq-7000";
> - model = "Xilinx Zynq";
>
> aliases {
> i2c0 = &i2c1;
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm012.dts
> b/arch/arm/boot/dts/zynq-zc770-xm012.dts
> index c3169d636..d2359b789 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm012.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm012.dts
> @@ -8,8 +8,8 @@
> #include "zynq-7000.dtsi"
>
> / {
> + model = "Xilinx ZC770 XM012 board";
> compatible = "xlnx,zynq-zc770-xm012", "xlnx,zynq-7000";
> - model = "Xilinx Zynq";
>
> aliases {
> i2c0 = &i2c0;
> diff --git a/arch/arm/boot/dts/zynq-zc770-xm013.dts
> b/arch/arm/boot/dts/zynq-zc770-xm013.dts
> index 8bb66859d..651913f1a 100644
> --- a/arch/arm/boot/dts/zynq-zc770-xm013.dts
> +++ b/arch/arm/boot/dts/zynq-zc770-xm013.dts
> @@ -8,8 +8,8 @@
> #include "zynq-7000.dtsi"
>
> / {
> + model = "Xilinx ZC770 XM013 board";
> compatible = "xlnx,zynq-zc770-xm013", "xlnx,zynq-7000";
> - model = "Xilinx Zynq";
>
>
Re: [PATCH v5 4/4] mm/sparse: Optimize memmap allocation during sparse_init()
On 06/27/18 at 11:19pm, Pavel Tatashin wrote:
> > Signed-off-by: Baoquan He
> >
> > Signed-off-by: Baoquan He
>
> Please remove duplicated signed-off
Done.
>
> > if (!usemap) {
> > ms->section_mem_map = 0;
> > + nr_consumed_maps++;
>
> Currently, we do not set ms->section_mem_map to 0 when fail to
> allocate usemap, only when fail to allocate mmap we set
> section_mem_map to 0. I think this is an existing bug.
Yes, found it when changing code. Later in sparse_init(), added checking
to see if usemap is available, otherwise also do "ms->section_mem_map = 0;"
to clear its ->section_mem_map.
Here if want to be perfect, we may need to free the relevant memmap
because usemap is allocated together, memmap could be allocated one
section by one section. I didn't do that because usemap allocation is
smaller one, if that allocation even failed in this early system
initializaiton stage, the kernel won't live long, so don't bother to do
that to complicate code.
>
> Reviewed-by: Pavel Tatashin
Re: [RFC PATCH 1/5] arm: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed boards
On 28.6.2018 07:42, Luis Araneda wrote:
> Both boards are made by Avnet, Inc.
>
> Signed-off-by: Luis Araneda
> ---
> arch/arm/boot/dts/zynq-microzed.dts | 2 +-
> arch/arm/boot/dts/zynq-zed.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/zynq-microzed.dts
> b/arch/arm/boot/dts/zynq-microzed.dts
> index aa4a0b6de..e40f40a7f 100644
> --- a/arch/arm/boot/dts/zynq-microzed.dts
> +++ b/arch/arm/boot/dts/zynq-microzed.dts
> @@ -8,7 +8,7 @@
>
> / {
> model = "Zynq MicroZED Development Board";
> - compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
> + compatible = "avnet,zynq-microzed", "xlnx,zynq-7000";
>
> aliases {
> ethernet0 = &gem0;
> diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
> index 53c6883ce..98381cc85 100644
> --- a/arch/arm/boot/dts/zynq-zed.dts
> +++ b/arch/arm/boot/dts/zynq-zed.dts
> @@ -8,7 +8,7 @@
>
> / {
> model = "Zynq Zed Development Board";
> - compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";
> + compatible = "avnet,zynq-zed", "xlnx,zynq-7000";
>
> aliases {
> ethernet0 = &gem0;
>
Unfortunately we don't know who is parsing this string. It means please
keep that origin compatible string there.
I have no problem with this.
compatible = "avnet,zynq-zed", "xlnx,zynq-zed", "xlnx,zynq-7000";
Thanks,
Michal
[PATCH v6 4/5] mm/sparse: Optimize memmap allocation during sparse_init()
In sparse_init(), two temporary pointer arrays, usemap_map and map_map
are allocated with the size of NR_MEM_SECTIONS. They are used to store
each memory section's usemap and mem map if marked as present. With
the help of these two arrays, continuous memory chunk is allocated for
usemap and memmap for memory sections on one node. This avoids too many
memory fragmentations. Like below diagram, '1' indicates the present
memory section, '0' means absent one. The number 'n' could be much
smaller than NR_MEM_SECTIONS on most of systems.
|1|1|1|1|0|0|0|0|1|1|0|0|...|1|0||1|0|...|1||0|1|...|0|
---
0 1 2 3 4 5 i i+1 n-1 n
If fail to populate the page tables to map one section's memmap, its
->section_mem_map will be cleared finally to indicate that it's not present.
After use, these two arrays will be released at the end of sparse_init().
In 4-level paging mode, each array costs 4M which can be ignorable. While
in 5-level paging, they costs 256M each, 512M altogether. Kdump kernel
Usually only reserves very few memory, e.g 256M. So, even thouth they are
temporarily allocated, still not acceptable.
In fact, there's no need to allocate them with the size of NR_MEM_SECTIONS.
Since the ->section_mem_map clearing has been deferred to the last, the
number of present memory sections are kept the same during sparse_init()
until we finally clear out the memory section's ->section_mem_map if its
usemap or memmap is not correctly handled. Thus in the middle whenever
for_each_present_section_nr() loop is taken, the i-th present memory
section is always the same one.
Here only allocate usemap_map and map_map with the size of
'nr_present_sections'. For the i-th present memory section, install its
usemap and memmap to usemap_map[i] and mam_map[i] during allocation. Then
in the last for_each_present_section_nr() loop which clears the failed
memory section's ->section_mem_map, fetch usemap and memmap from
usemap_map[] and map_map[] array and set them into mem_section[]
accordingly.
Signed-off-by: Baoquan He
Reviewed-by: Pavel Tatashin
---
mm/sparse-vmemmap.c | 5 +++--
mm/sparse.c | 43 ++-
2 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 68bb65b2d34d..e1a54ba411ec 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -281,6 +281,7 @@ void __init sparse_mem_maps_populate_node(struct page
**map_map,
unsigned long pnum;
unsigned long size = sizeof(struct page) * PAGES_PER_SECTION;
void *vmemmap_buf_start;
+ int nr_consumed_maps = 0;
size = ALIGN(size, PMD_SIZE);
vmemmap_buf_start = __earlyonly_bootmem_alloc(nodeid, size * map_count,
@@ -295,8 +296,8 @@ void __init sparse_mem_maps_populate_node(struct page
**map_map,
if (!present_section_nr(pnum))
continue;
- map_map[pnum] = sparse_mem_map_populate(pnum, nodeid, NULL);
- if (map_map[pnum])
+ map_map[nr_consumed_maps] = sparse_mem_map_populate(pnum,
nodeid, NULL);
+ if (map_map[nr_consumed_maps++])
continue;
pr_err("%s: sparsemem memory map backing failed some memory
will not be available\n",
__func__);
diff --git a/mm/sparse.c b/mm/sparse.c
index 4458a23e5293..e1767d9fe4f3 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -386,6 +386,7 @@ static void __init sparse_early_usemaps_alloc_node(void
*data,
unsigned long pnum;
unsigned long **usemap_map = (unsigned long **)data;
int size = usemap_size();
+ int nr_consumed_maps = 0;
usemap = sparse_early_usemaps_alloc_pgdat_section(NODE_DATA(nodeid),
size * usemap_count);
@@ -397,9 +398,10 @@ static void __init sparse_early_usemaps_alloc_node(void
*data,
for (pnum = pnum_begin; pnum < pnum_end; pnum++) {
if (!present_section_nr(pnum))
continue;
- usemap_map[pnum] = usemap;
+ usemap_map[nr_consumed_maps] = usemap;
usemap += size;
- check_usemap_section_nr(nodeid, usemap_map[pnum]);
+ check_usemap_section_nr(nodeid, usemap_map[nr_consumed_maps]);
+ nr_consumed_maps++;
}
}
@@ -424,27 +426,31 @@ void __init sparse_mem_maps_populate_node(struct page
**map_map,
void *map;
unsigned long pnum;
unsigned long size = sizeof(struct page) * PAGES_PER_SECTION;
+ int nr_consumed_maps;
size = PAGE_ALIGN(size);
map = memblock_virt_alloc_try_nid_raw(size * map_count,
PAGE_SIZE, __pa(MAX_DMA_ADDRESS),
BOOTMEM_ALLOC_ACCESSIBLE, nodeid);
if (map) {
+ nr_c
[PATCH v6 3/5] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap
alloc_usemap_and_memmap() is passing in a "void *" that points to
usemap_map or memmap_map. In next patch we will change both of the
map allocation from taking 'NR_MEM_SECTIONS' as the length to taking
'nr_present_sections' as the length. After that, the passed in 'void*'
needs to update as things get consumed. But, it knows only the
quantity of objects consumed and not the type. This effectively
tells it enough about the type to let it update the pointer as
objects are consumed.
Signed-off-by: Baoquan He
Reviewed-by: Pavel Tatashin
---
mm/sparse.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 6a706093307d..4458a23e5293 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -486,10 +486,12 @@ void __weak __meminit vmemmap_populate_print_last(void)
/**
* alloc_usemap_and_memmap - memory alloction for pageblock flags and vmemmap
* @map: usemap_map for pageblock flags or mmap_map for vmemmap
+ * @unit_size: size of map unit
*/
static void __init alloc_usemap_and_memmap(void (*alloc_func)
(void *, unsigned long, unsigned long,
- unsigned long, int), void *data)
+ unsigned long, int), void *data,
+ int data_unit_size)
{
unsigned long pnum;
unsigned long map_count;
@@ -566,7 +568,8 @@ void __init sparse_init(void)
if (!usemap_map)
panic("can not allocate usemap_map\n");
alloc_usemap_and_memmap(sparse_early_usemaps_alloc_node,
- (void *)usemap_map);
+ (void *)usemap_map,
+ sizeof(usemap_map[0]));
#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
size2 = sizeof(struct page *) * NR_MEM_SECTIONS;
@@ -574,7 +577,8 @@ void __init sparse_init(void)
if (!map_map)
panic("can not allocate map_map\n");
alloc_usemap_and_memmap(sparse_early_mem_maps_alloc_node,
- (void *)map_map);
+ (void *)map_map,
+ sizeof(map_map[0]));
#endif
for_each_present_section_nr(0, pnum) {
--
2.13.6
[PATCH v6 2/5] mm/sparsemem: Defer the ms->section_mem_map clearing
In sparse_init(), if CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y, system
will allocate one continuous memory chunk for mem maps on one node and
populate the relevant page tables to map memory section one by one. If
fail to populate for a certain mem section, print warning and its
->section_mem_map will be cleared to cancel the marking of being present.
Like this, the number of mem sections marked as present could become
less during sparse_init() execution.
Here just defer the ms->section_mem_map clearing if failed to populate
its page tables until the last for_each_present_section_nr() loop. This
is in preparation for later optimizing the mem map allocation.
Signed-off-by: Baoquan He
Reviewed-by: Pavel Tatashin
---
mm/sparse-vmemmap.c | 4
mm/sparse.c | 15 ---
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index bd0276d5f66b..68bb65b2d34d 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -292,18 +292,14 @@ void __init sparse_mem_maps_populate_node(struct page
**map_map,
}
for (pnum = pnum_begin; pnum < pnum_end; pnum++) {
- struct mem_section *ms;
-
if (!present_section_nr(pnum))
continue;
map_map[pnum] = sparse_mem_map_populate(pnum, nodeid, NULL);
if (map_map[pnum])
continue;
- ms = __nr_to_section(pnum);
pr_err("%s: sparsemem memory map backing failed some memory
will not be available\n",
__func__);
- ms->section_mem_map = 0;
}
if (vmemmap_buf_start) {
diff --git a/mm/sparse.c b/mm/sparse.c
index 6314303130b0..6a706093307d 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -441,17 +441,13 @@ void __init sparse_mem_maps_populate_node(struct page
**map_map,
/* fallback */
for (pnum = pnum_begin; pnum < pnum_end; pnum++) {
- struct mem_section *ms;
-
if (!present_section_nr(pnum))
continue;
map_map[pnum] = sparse_mem_map_populate(pnum, nodeid, NULL);
if (map_map[pnum])
continue;
- ms = __nr_to_section(pnum);
pr_err("%s: sparsemem memory map backing failed some memory
will not be available\n",
__func__);
- ms->section_mem_map = 0;
}
}
#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
@@ -479,7 +475,6 @@ static struct page __init
*sparse_early_mem_map_alloc(unsigned long pnum)
pr_err("%s: sparsemem memory map backing failed some memory will not be
available\n",
__func__);
- ms->section_mem_map = 0;
return NULL;
}
#endif
@@ -583,17 +578,23 @@ void __init sparse_init(void)
#endif
for_each_present_section_nr(0, pnum) {
+ struct mem_section *ms;
+ ms = __nr_to_section(pnum);
usemap = usemap_map[pnum];
- if (!usemap)
+ if (!usemap) {
+ ms->section_mem_map = 0;
continue;
+ }
#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
map = map_map[pnum];
#else
map = sparse_early_mem_map_alloc(pnum);
#endif
- if (!map)
+ if (!map) {
+ ms->section_mem_map = 0;
continue;
+ }
sparse_init_one_section(__nr_to_section(pnum), pnum, map,
usemap);
--
2.13.6
[PATCH v6 0/5] mm/sparse: Optimize memmap allocation during sparse_init()
This is v6 post. In sparse_init(), two temporary pointer arrays, usemap_map and map_map are allocated with the size of NR_MEM_SECTIONS. They are used to store each memory section's usemap and mem map if marked as present. In 5-level paging mode, this will cost 512M memory though they will be released at the end of sparse_init(). System with few memory, like kdump kernel which usually only has about 256M, will fail to boot because of allocation failure if CONFIG_X86_5LEVEL=y. In this patchset, optimize the memmap allocation code to only use usemap_map and map_map with the size of nr_present_sections. This makes kdump kernel boot up with normal crashkernel='' setting when CONFIG_X86_5LEVEL=y. The old version can be found below: v5: http://lkml.kernel.org/r/20180627013116.12411-1-...@redhat.com v4: http://lkml.kernel.org/r/20180521101555.25610-1-...@redhat.com v3: https://lkml.org/lkml/2018/2/27/928 V1 can be found here: https://www.spinics.net/lists/linux-mm/msg144486.html Change log: v5->v6: Oscar found the redundant "struct mem_section *ms" definition and in the old patch 2/4, after deferring the clearing of section_mem_map. Clean them up in this version. Pavel pointed out that allocating memmap together for one node at one time should be a default behaviour for all ARCH-es. And if failed on large memory, it will drop to the fallback to allocate memmap for one section at one time, it shoult not break anything. Add patch 5/5 to remove CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER and clean up the related codes. v4->v5: Improve patch 3/4 log according to Dave's suggestion. Correct the wrong copy&paste of making 'nr_consumed_maps' to 'alloc_usemap_and_memmap' mistakenly which is pointed out by Dave in patch 4/4 code comment. Otherwise, no code change in this version. v3->v4: Improve according to Dave's three concerns which are in patch 0004: Rename variable 'idx_present' to 'nr_consumed_maps' which used to index the memmap and usemap of present sections. Add a check if 'nr_consumed_maps' goes beyond nr_present_sections. Add code comment above the final for_each_present_section_nr() to tell why 'nr_consumed_maps' need be increased in each iteration whether the 'ms->section_mem_map' need cleared or out. v2->v3: Change nr_present_sections as __initdata and add code comment according to Andrew's suggestion. Change the local variable 'i' as idx_present which loops over the present sections, and improve the code. These are suggested by Dave and Pankaj. Add a new patch 0003 which adds a new parameter 'data_unit_size' to function alloc_usemap_and_memmap() in which we will update 'data' to make it point at new position. However its type 'void *' can't give us needed info to do that. Need pass the unit size in. So change code in patch 0004 accordingly. This is a code bug fix found when tested the memory deployed on multiple nodes. v1-v2: Split out the nr_present_sections adding as a single patch for easier reviewing. Rewrite patch log according to Dave's suggestion. Fix code bug in patch 0002 reported by test robot. Baoquan He (5): mm/sparse: Add a static variable nr_present_sections mm/sparsemem: Defer the ms->section_mem_map clearing mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap mm/sparse: Optimize memmap allocation during sparse_init() mm/sparse: Remove CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER mm/Kconfig | 4 -- mm/sparse-vmemmap.c | 9 ++--- mm/sparse.c | 109 3 files changed, 62 insertions(+), 60 deletions(-) -- 2.13.6
[PATCH v6 1/5] mm/sparse: Add a static variable nr_present_sections
It's used to record how many memory sections are marked as present
during system boot up, and will be used in the later patch.
Signed-off-by: Baoquan He
Reviewed-by: Pavel Tatashin
---
mm/sparse.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/mm/sparse.c b/mm/sparse.c
index f13f2723950a..6314303130b0 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -200,6 +200,12 @@ static inline int next_present_section_nr(int section_nr)
(section_nr <= __highest_present_section_nr));\
section_nr = next_present_section_nr(section_nr))
+/*
+ * Record how many memory sections are marked as present
+ * during system bootup.
+ */
+static int __initdata nr_present_sections;
+
/* Record a memory area against a node. */
void __init memory_present(int nid, unsigned long start, unsigned long end)
{
@@ -229,6 +235,7 @@ void __init memory_present(int nid, unsigned long start,
unsigned long end)
ms->section_mem_map = sparse_encode_early_nid(nid) |
SECTION_IS_ONLINE;
section_mark_present(ms);
+ nr_present_sections++;
}
}
}
--
2.13.6
[PATCH v6 5/5] mm/sparse: Remove CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
Pavel pointed out that the behaviour of allocating memmap together
for one node should be defaulted for all ARCH-es. It won't break
anything because it will drop to the fallback action to allocate
imemmap for each section at one time if failed on large chunk of
memory.
So remove CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER and clean up the
related codes.
Signed-off-by: Baoquan He
Cc: Pavel Tatashin
---
mm/Kconfig | 4
mm/sparse.c | 32 ++--
2 files changed, 2 insertions(+), 34 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index ce95491abd6a..75a196bf83e6 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -115,10 +115,6 @@ config SPARSEMEM_EXTREME
config SPARSEMEM_VMEMMAP_ENABLE
bool
-config SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
- def_bool y
- depends on SPARSEMEM && X86_64
-
config SPARSEMEM_VMEMMAP
bool "Sparse Memory virtual memmap"
depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE
diff --git a/mm/sparse.c b/mm/sparse.c
index e1767d9fe4f3..d18e2697a781 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -458,7 +458,6 @@ void __init sparse_mem_maps_populate_node(struct page
**map_map,
}
#endif /* !CONFIG_SPARSEMEM_VMEMMAP */
-#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
static void __init sparse_early_mem_maps_alloc_node(void *data,
unsigned long pnum_begin,
unsigned long pnum_end,
@@ -468,22 +467,6 @@ static void __init sparse_early_mem_maps_alloc_node(void
*data,
sparse_mem_maps_populate_node(map_map, pnum_begin, pnum_end,
map_count, nodeid);
}
-#else
-static struct page __init *sparse_early_mem_map_alloc(unsigned long pnum)
-{
- struct page *map;
- struct mem_section *ms = __nr_to_section(pnum);
- int nid = sparse_early_nid(ms);
-
- map = sparse_mem_map_populate(pnum, nid, NULL);
- if (map)
- return map;
-
- pr_err("%s: sparsemem memory map backing failed some memory will not be
available\n",
- __func__);
- return NULL;
-}
-#endif
void __weak __meminit vmemmap_populate_print_last(void)
{
@@ -545,14 +528,11 @@ void __init sparse_init(void)
{
unsigned long pnum;
struct page *map;
+ struct page **map_map;
unsigned long *usemap;
unsigned long **usemap_map;
- int size;
+ int size, size2;
int nr_consumed_maps = 0;
-#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
- int size2;
- struct page **map_map;
-#endif
/* see include/linux/mmzone.h 'struct mem_section' definition */
BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
@@ -579,7 +559,6 @@ void __init sparse_init(void)
(void *)usemap_map,
sizeof(usemap_map[0]));
-#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
size2 = sizeof(struct page *) * nr_present_sections;
map_map = memblock_virt_alloc(size2, 0);
if (!map_map)
@@ -587,7 +566,6 @@ void __init sparse_init(void)
alloc_usemap_and_memmap(sparse_early_mem_maps_alloc_node,
(void *)map_map,
sizeof(map_map[0]));
-#endif
/* The numner of present sections stored in nr_present_sections
* are kept the same since mem sections are marked as present in
@@ -613,11 +591,7 @@ void __init sparse_init(void)
continue;
}
-#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
map = map_map[nr_consumed_maps];
-#else
- map = sparse_early_mem_map_alloc(pnum);
-#endif
if (!map) {
ms->section_mem_map = 0;
nr_consumed_maps++;
@@ -631,9 +605,7 @@ void __init sparse_init(void)
vmemmap_populate_print_last();
-#ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
memblock_free_early(__pa(map_map), size2);
-#endif
memblock_free_early(__pa(usemap_map), size);
}
--
2.13.6
mmotm 2018-06-27-23-21 uploaded
The mm-of-the-moment snapshot 2018-06-27-23-21 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (4.x or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 4.18-rc2: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch * lib-percpu_idac-dont-do-alloc-from-per-cpu-list-if-there-is-none.patch * revert-mm-vmstatc-fix-vmstat_update-preemption-bug.patch * slub-fix-failure-when-we-delete-and-create-a-slab-cache.patch * x86-e820-put-e820_type_ram-regions-into-memblockreserved.patch * include-dax-new-return-type-vm_fault_t.patch * kasan-depend-on-config_slub_debug.patch * proc-condemn-myself-to-maintainers.patch * memcg-remove-memcg_cgroup-id-from-idr-on-mem_cgroup_css_alloc-failure.patch * slub-track-number-of-slabs-irrespective-of-config_slub_debug.patch * userfaultfd-hugetlbfs-fix-userfaultfd_huge_must_wait-pte-access.patch * mm-hugetlb-yield-when-prepping-struct-pages.patch * kasan-fix-shadow_size-calculation-error-in-kasan_module_alloc.patch * revert-lib-test_printfc-call-wait_for_random_bytes-before-plain-%p-tests.patch * arm-arch-arm-include-asm-pageh-needs-personalityh.patch * dax-remove-vm_mixedmap-for-fsdax-and-device-dax.patch * prctl-add-pr_et_pdeathsig_proc.patch * ntfs-dont-disable-interrupts-during-kmap_atomic.patch * ntfs-aops-remove-vla-usage.patch * ntfs-decompress-remove-vla-usage.patch * ntfs-mft-remove-vla-usage.patch * sh-make-use-of-for_each_node_by_type.patch * h8300-correct-signature-of-test_bit.patch * ocfs2-return-erofs-when-filesystem-becomes-read-only.patch * ocfs2-return-erofs-when-filesystem-becomes-read-only-checkpatch-fixes.patch * ocfs2-clean-up-some-unnecessary-code.patch * ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch * ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery.patch * ocfs2-dont-use-iocb-when-eiocbqueued-returns.patch * ocfs2-fix-a-misuse-a-of-brelse-after-failing-ocfs2_check_dir_entry.patch * ocfs2-dont-put-and-assigning-null-to-bh-allocated-outside.patch * ocfs2-dlmglue-clean-up-timestamp-handling.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch * dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch * namei-allow-restricted-o_creat-of-fifos-and-regular-files.patch * vfs-discard-attr_attr_flag.patch * vfs-simplify-seq_file-iteration-code-and-interface.patch mm.patch * mm-convert-return-type-of-handle_mm_fault-caller-to-vm_fault_t.patch * mm-skip-invalid-pages-block-at-a-time-in-zero_resv_unresv.patch * thp-use-mm_file_counter-to-determine-update-which-rss-counter.patch * tools-modifying-page-types-to-include-shared-map-counts.patch * tools-modifying-page-types-to-include-shared-map-counts-checkpatch-fixes.patch * tools-adding-support-for-idle-page-tracking-to-
Re: [alsa-devel] [PATCH v2 1/2] ASoC: qcom: dt-bindings: Add sdm845 machine bindings
Thanks Rob for reviewing.
On 6/26/2018 12:47 AM, Rob Herring wrote:
On Thu, Jun 21, 2018 at 04:23:18PM +0530, Rohit kumar wrote:
Add devicetree bindings documentation file for SDM845 sound card.
Signed-off-by: Rohit kumar
---
.../devicetree/bindings/sound/qcom,sdm845.txt | 82 ++
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/qcom,sdm845.txt
diff --git a/Documentation/devicetree/bindings/sound/qcom,sdm845.txt
b/Documentation/devicetree/bindings/sound/qcom,sdm845.txt
new file mode 100644
index 000..68feb08
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,sdm845.txt
@@ -0,0 +1,82 @@
+* Qualcomm Technologies Inc. SDM845 ASoC sound card driver
+
+This binding describes the SDM845 sound card, which uses qdsp for audio.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,sdm845-sndcard"
+
+- qcom,audio-routing:
Use just 'audio-routing'.
This is same which is being followed in apq8096 machine driver. As all
qcom machine drivers will
mostly follow the same design, Vinod asked to pull out the APIs in
common file - https://patchwork.kernel.org/patch/10479625/ .
Same is for qcom,model. I will add missing documentation for it in the
next patchset.
+ Usage: Optional
+ Value type:
+ Definition: A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names could be power supplies, MicBias
+ of codec and the jacks on the board.
+
+- cdc-vdd-supply:
+ Usage: Optional
+ Value type:
+ Definition: phandle of regulator supply required for codec vdd.
The codec supply should be in the codec node.
Sure. Will add this in codec driver.
+
+= dailinks
+Each subnode of sndcard represents either a dailink, and subnodes of each
+dailinks would be cpu/codec/platform dais.
+
+- link-name:
+ Usage: required
+ Value type:
+ Definition: User friendly name for dai link
+
+= CPU, PLATFORM, CODEC dais subnodes
+- cpu:
+ Usage: required
+ Value type:
+ Definition: cpu dai sub-node
+
+- codec:
+ Usage: required
+ Value type:
+ Definition: codec dai sub-node
+
+- platform:
+ Usage: Optional
+ Value type:
+ Definition: platform dai sub-node
+
+- sound-dai:
+ Usage: required
+ Value type:
+ Definition: dai phandle/s and port of CPU/CODEC/PLATFORM node.
+
+Example:
+
+audio {
+ compatible = "qcom,sdm845-sndcard";
+ qcom,model = "sdm845-snd-card";
Not documented. Just use 'model'.
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pri_mi2s_active &pri_mi2s_ws_active>;
+ pinctrl-1 = <&pri_mi2s_sleep &pri_mi2s_ws_sleep>;
+
+ cdc-vdd-supply = <&pm8998_l14>;
+
+ mm1-dai-link {
+ link-name = "MultiMedia1";
+ cpu {
+ sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
+ };
+ };
+
+ pri-mi2s-dai-link {
+ link-name = "PRI MI2S Playback";
+ cpu {
+ sound-dai = <&q6afedai PRIMARY_MI2S_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6routing>;
+ };
+ };
+};
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Regards,
Rohit
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
linux-next: Tree for Jun 28
Hi all, Changes since 20180627: The sunxi tree gained a build failure so I used the version from next-20180627. The btrfs-kdave tree gained a build failure so I used the version from next-20180626. The drm tree lost its build failure. The xarray tree gained a conflict against the wireless-drivers-next tree. Non-merge commits (relative to Linus' tree): 2513 2732 files changed, 87273 insertions(+), 42976 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 281 trees (counting Linus' and 65 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (f57494321cbf Merge tag 'xfs-4.18-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (bcb3726a6034 kbuild: reword help of LD_DEAD_CODE_DATA_ELIMINATION) Merging arc-current/for-curr (6ddb19a32e79 ARC: Improve cmpxchg syscall implementation) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (7838306f5ace Merge branch 'perf/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (22db552b50fa powerpc/powermac: Fix rtc read/write functions) Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (2d2595719a97 nfp: cast sizeof() to int when comparing with error code) Merging bpf/master (dd349c3ffd93 selftests: bpf: notification about privilege required to run test_lwt_seg6local.sh testing script) Merging ipsec/master (7284fdf39a91 esp6: fix memleak on error path in esp6_input) Merging netfilter/master (b36e4523d4d5 netfilter: nf_conncount: fix garbage collection confirm race) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (92963318a255 mt7601u: remove warning when avg_rssi is zero) Merging mac80211/master (bf2b61a6838f cfg80211: fix rcu in cfg80211_unregister_wdev) Merging rdma-fixes/for-rc (b697d7d8c741 IB/hfi1: Fix incorrect mixing of ERR_PTR and NULL return values) Merging sound-current/for-linus (4fb88a15f5dd ALSA: hda - Handle pm failure during hotplug) Merging sound-asoc-fixes/for-linus (cf6c692c746c Merge branch 'asoc-4.18' into asoc-linus) Merging regmap-fixes/for-linus (7daf201d7fe8 Linux 4.18-rc2) Merging regulator-fixes/for-linus (bd4929a3ac1e Merge branch 'regulator-4.18' into regulator-linus) Merging spi-fixes/for-linus (58c2ec73d535 Merge branch 'spi-4.18' into spi-linus) Merging pci-current/for-linus (925d31668d5b PCI: controller: Move PCI_DOMAINS selection to arch Kconfig) Merging driver-core.current/driver-core-linus (7daf201d7fe8 Linux 4.18-rc2) Merging tty.current/tty-linus (ce397d215ccd Linux 4.18-rc1) Merging usb.current/usb-linus (90f26cc6bb90 usb: chipidea: host: fix disconnection detect issue) Merging usb-gadget-fixes/fixes (1d8e5c002758 dwc2: gadget: Fix ISOC IN DDMA P
Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece
On Thu, 28 Jun 2018 13:35:15 +0800 "Huang\, Ying" wrote: > Andrew Morton writes: > > > On Thu, 28 Jun 2018 13:29:09 +0800 "Huang\, Ying" > > wrote: > > > >> Andrew Morton writes: > >> > >> > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" > >> > wrote: > >> > > >> >> This is the final step of THP (Transparent Huge Page) swap > >> >> optimization. After the first and second step, the splitting huge > >> >> page is delayed from almost the first step of swapout to after swapout > >> >> has been finished. In this step, we avoid splitting THP for swapout > >> >> and swapout/swapin the THP in one piece. > >> > > >> > It's a tremendously good performance improvement. It's also a > >> > tremendously large patchset :( > >> > > >> > And it depends upon your > >> > mm-swap-fix-race-between-swapoff-and-some-swap-operations.patch and > >> > mm-fix-race-between-swapoff-and-mincore.patch, the first of which has > >> > been floating about since February without adequate review. > >> > > >> > I'll give this patchset a spin in -mm to see what happens and will come > >> > back later to take a closer look. But the best I can do at this time > >> > is to hopefully cc some possible reviewers :) > >> > >> Thanks a lot for your help! Hope more people can review it! > > > > I took it out of -mm again, temporarily. Due to a huge tangle with the > > xarray conversions in linux-next. > > No problem. I will rebase the patchset on your latest -mm tree, or the > next version to be released? We need to figure that out with Matthew. Probably the xarray conversions are simpler and more mature so yes, probably they should be staged first.
Re: [PATCH 2/3] k3dma: add support to reserved minimum channels
On 22-06-18, 11:24, Guodong Xu wrote:
> From: Li Yu
>
> On k3 series of SoC, DMA controller reserves some channels for
> other on-chip coprocessors. By adding support to dma_min_chan, kernel
> will not be able to use these reserved channels.
>
> One example is on Hi3660 platform, channel 0 is reserved to lpm3.
>
> Please also refer to Documentation/devicetree/bindings/dma/k3dma.txt
and if some other platform has channel X marked for co-processor, maybe
a last channel or something in middle, how will this work then?
I am thinking this should be a mask, rather than min.
>
> Signed-off-by: Li Yu
> Signed-off-by: Guodong Xu
> ---
> drivers/dma/k3dma.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/k3dma.c b/drivers/dma/k3dma.c
> index fa31cccbe04f..13cec12742e3 100644
> --- a/drivers/dma/k3dma.c
> +++ b/drivers/dma/k3dma.c
> @@ -113,6 +113,7 @@ struct k3_dma_dev {
> struct dma_pool *pool;
> u32 dma_channels;
> u32 dma_requests;
> + u32 dma_min_chan;
> unsigned intirq;
> };
>
> @@ -309,7 +310,7 @@ static void k3_dma_tasklet(unsigned long arg)
>
> /* check new channel request in d->chan_pending */
> spin_lock_irq(&d->lock);
> - for (pch = 0; pch < d->dma_channels; pch++) {
> + for (pch = d->dma_min_chan; pch < d->dma_channels; pch++) {
> p = &d->phy[pch];
>
> if (p->vchan == NULL && !list_empty(&d->chan_pending)) {
> @@ -326,7 +327,7 @@ static void k3_dma_tasklet(unsigned long arg)
> }
> spin_unlock_irq(&d->lock);
>
> - for (pch = 0; pch < d->dma_channels; pch++) {
> + for (pch = d->dma_min_chan; pch < d->dma_channels; pch++) {
> if (pch_alloc & (1 << pch)) {
> p = &d->phy[pch];
> c = p->vchan;
> @@ -825,6 +826,8 @@ static int k3_dma_probe(struct platform_device *op)
> "dma-channels", &d->dma_channels);
> of_property_read_u32((&op->dev)->of_node,
> "dma-requests", &d->dma_requests);
> + of_property_read_u32((&op->dev)->of_node,
> + "dma-min-chan", &d->dma_min_chan);
> }
>
> d->clk = devm_clk_get(&op->dev, NULL);
> @@ -848,12 +851,12 @@ static int k3_dma_probe(struct platform_device *op)
> return -ENOMEM;
>
> /* init phy channel */
> - d->phy = devm_kcalloc(&op->dev,
> - d->dma_channels, sizeof(struct k3_dma_phy), GFP_KERNEL);
> + d->phy = devm_kcalloc(&op->dev, (d->dma_channels - d->dma_min_chan),
> + sizeof(struct k3_dma_phy), GFP_KERNEL);
> if (d->phy == NULL)
> return -ENOMEM;
>
> - for (i = 0; i < d->dma_channels; i++) {
> + for (i = d->dma_min_chan; i < d->dma_channels; i++) {
> struct k3_dma_phy *p = &d->phy[i];
>
> p->idx = i;
> --
> 2.17.1
--
~Vinod
Re: [PATCH v7 00/29] Add support for mediatek SOC MT2712
On Thu, Jun 28, 2018 at 11:45:37AM +0800, Stu Hsieh wrote: > Hi, Daniel Vetter: > > On Mon, 2018-06-25 at 10:47 +0200, Daniel Vetter wrote: > > On Wed, Jun 20, 2018 at 04:19:02PM +0800, Stu Hsieh wrote: > > > This patch add support for the Mediatek MT2712 DISP subsystem. > > > MT2712 is base on MT8173, there are some difference as following: > > > MT2712 support three disp output(two ovl and one rdma) > > > > > > Change in v6: > > > - Update commit message for the patch > > > "drm/mediatek: Update the definition of connection from RDMA1 to DPI0" > > > > Just a drive-by comment on the mediatek driver: > > > > As far as I can see mtk_drm_gem.c reimplements the cma helpers as a > > copypaste job. Any reasons why you're not using the normal cma helpers? > > > > Thanks, Daniel > > > > > In the beginning, we develop mtk_drm_gem.c by referring other platform. > We will try to use the normal cma helpers according to your idea. Sounds great if you can do this as a longer-term refactoring task! I discussed this also a bit with Philipp on irc, and he said there's possible a need to support non-contig buffers in mtk. If that can't be done using cma helpers (usually you have an iommu in such a case, which again gives you a contig buffer in device-address space, and that can be used by cma I think), then I think it would still be useful if you use the cma helpers for the contig buffers. But then wrap them in some mtk code to switch between the two. Cheers, Daniel > > Thanks, > Stu > > > > Stu Hsieh (29): > > > drm/mediatek: update dt-bindings for mt2712 > > > drm/mediatek: support maximum 64 mutex mod > > > drm/mediatek: add ddp component AAL1 > > > drm/mediatek: add ddp component OD1 > > > drm/mediatek: add ddp component PWM1 > > > drm/mediatek: add ddp component PWM2 > > > drm/mediatek: add component DPI1 > > > drm/mediatek: add component DSI2 > > > drm/mediatek: add component DSI3 > > > drm/mediatek: add the DSI1 for component init condition > > > drm/mediatek: add connection from OD1 to RDMA1 > > > drm/mediatek: Update the definition of connection from RDMA1 to DPI0 > > > drm/mediatek: add connection from RDMA0 to DPI0 > > > drm/mediatek: add connection from RDMA0 to DSI2 > > > drm/mediatek: add connection from RDMA0 to DSI3 > > > drm/mediatek: add connection from RDMA1 to DPI1 > > > drm/mediatek: add connection from RDMA1 to DSI1 > > > drm/mediatek: add connection from RDMA1 to DSI2 > > > drm/mediatek: add connection from RDMA1 to DSI3 > > > drm/mediatek: add connection from RDMA2 to DPI0 > > > drm/mediatek: add connection from RDMA2 to DPI1 > > > drm/mediatek: add connection from RDMA2 to DSI1 > > > drm/mediatek: add connection from RDMA2 to DSI2 > > > drm/mediatek: add connection from RDMA2 to DSI3 > > > drm/mediatek: add DPI1 support for mutex > > > drm/mediatek: add DSI2 support for mutex > > > drm/mediatek: add DSI3 support for mutex > > > drm/mediatek: add third ddp path > > > drm/mediatek: Add support for mediatek SOC MT2712 > > > > > > .../bindings/display/mediatek/mediatek,disp.txt| 2 +- > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 3 + > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 235 > > > ++--- > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 15 +- > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 10 +- > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 - > > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 5 +- > > > 7 files changed, 274 insertions(+), 43 deletions(-) > > > > > > -- > > > 2.12.5 > > > > > > ___ > > > dri-devel mailing list > > > dri-de...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 1/3] dt-bindings: k3dma: add optional property dma_min_chan
On 22-06-18, 11:24, Guodong Xu wrote: > From: Li Yu > > Add optional property dma_min_chan for k3dma. > > Signed-off-by: Li Yu > --- > Documentation/devicetree/bindings/dma/k3dma.txt | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/dma/k3dma.txt > b/Documentation/devicetree/bindings/dma/k3dma.txt > index 4945aeac4dc4..2fa1370c3173 100644 > --- a/Documentation/devicetree/bindings/dma/k3dma.txt > +++ b/Documentation/devicetree/bindings/dma/k3dma.txt > @@ -12,6 +12,11 @@ Required properties: > have specific request line > - clocks: clock required > > +Optional properties: > +- dma_min_chan: the minimum number of DMA channel which begin to use > + the default value is 0, but in some platform is Sorry I don't understand this property, we already have dma-channels which describes the channels in a controller. What is purpose of this ? > + configured 1, like hi3660 platform > + > Example: > > Controller: > @@ -21,6 +26,7 @@ Controller: > #dma-cells = <1>; > dma-channels = <16>; > dma-requests = <27>; > + dma_min_chan = <1>; > interrupts = <0 12 4>; > clocks = <&pclk>; > }; > -- > 2.17.1 -- ~Vinod
Re: [PATCH] dmaengine: pl330: report BURST residue granularity
On 19-06-18, 15:20, Marek Szyprowski wrote: > The reported residue is already calculated in BURST unit granularity, so > advertise this capability properly to other devices in the system. Applied, thanks -- ~Vinod
Re: [12/24] proc: Add fs_context support to procfs [ver #7]
On Tue, Jun 26, 2018 at 09:57:07AM +0100, David Howells wrote:
> Andrei Vagin wrote:
>
> > > > > - mnt = kern_mount_data(&proc_fs_type, ns, 0);
> > >
> > > Here ns->user_ns and get_current_cred()->user_ns are not always equal
> >
> > What do you think about the attached patch?
> > ...
> > - fc = vfs_new_fs_context(&proc_fs_type, NULL, 0,
> > - FS_CONTEXT_FOR_KERNEL_MOUNT);
> > + fc = vfs_new_fs_context_userns(&proc_fs_type, NULL, 0,
> > + FS_CONTEXT_FOR_KERNEL_MOUNT, ns->user_ns);
>
> Or you could just change fc->user_ns immediately after calling
> vfs_new_fs_context(). This is what network filesystems should do with
> fc->net_ns, for example.
Ok, it works for me. The patch is attached.
>
> > -struct fs_context *vfs_new_fs_context(struct file_system_type *fs_type,
> > +struct fs_context *vfs_new_fs_context_userns(struct file_system_type
> > *fs_type,
> > struct dentry *reference,
> > unsigned int sb_flags,
> > - enum fs_context_purpose purpose)
> > + enum fs_context_purpose purpose,
> > + struct user_namespace *user_ns)
>
>
> If you'd really rather add a new parameter, please don't rename the function
> to vfs_new_fs_context_userns() - just add a new parameter. There don't need
> to be two versions of it.
>
>
> This brings me to another thought: I want to add the ability to let
> namespaces be configured by userspace, for example:
It may be a good feature, but I am not sure about procfs. A procfs
instance is created per pidns, so they should have the same owner
userns.
>
> fd = fsopen("nfs");
> sprintf(buf, "ns user %d", my_user_ns_fd);
> write(fd, buf);
> sprintf(buf, "ns net %d", my_net_ns_fd);
> write(fd, buf);
> write(fd, "s fedoraproject.org:/pub");
> write(fd, "o intr");
> ...
>
> I think therefore, I might need to insert another phase between creating the
> context and calling the filesystem initialiser:
>
> fc = vfs_new_fs_context(&afs_fs_type, mntpt, 0,
> FS_CONTEXT_FOR_SUBMOUNT);
>
> followed by:
>
> vfs_sb_set_namespace(fc, THIS_IS_USER_NS, user_ns);
> vfs_sb_set_namespace(fc, THIS_IS_NET_NS, net_ns);
>
> but then we'd need to do:
>
> vfs_begin_options(fc);
>
> before continuing (unless we made this happen automatically on the receipt of
> the first option):
>
> afs_mntpt_set_params(fc, mntpt);
> vfs_get_tree(fc);
> mnt = vfs_create_mount(fc, 0);
>
> Alternatively, we could do the namespace setting after initialisation and let
> the fs apply the changes itself.
>
> David
>From 2297ffb333a7bcee466a5273a3fc84202b9695a6 Mon Sep 17 00:00:00 2001
From: Andrei Vagin
Date: Wed, 27 Jun 2018 22:45:43 -0700
Subject: [PATCH] proc: set a proper user namespace for fs_context
A user namespace should be taken from a pidns for which a procfs is created.
Signed-off-by: Andrei Vagin
---
fs/proc/root.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/proc/root.c b/fs/proc/root.c
index efbdc08a3c86..59aaf06a40c7 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -303,6 +303,11 @@ int pid_ns_prepare_proc(struct pid_namespace *ns)
if (IS_ERR(fc))
return PTR_ERR(fc);
+ if (fc->user_ns != ns->user_ns) {
+ put_user_ns(fc->user_ns);
+ fc->user_ns = get_user_ns(ns->user_ns);
+ }
+
ctx = fc->fs_private;
if (ctx->pid_ns != ns) {
put_pid_ns(ctx->pid_ns);
--
2.17.0
Re: moving affs + RDB partition support to staging?
Joanne,
Linux on m68k has supported lseek64 (or llseek) for a long time (from
glibc version 2.1 according to what I found). About the only area where
we are limited by 32 bits is the virtual memory size.
I'm not proposing to modify the RDB format definition, though an
extension to store 64 bit offsets separate from the 32 bit ones would be
one way to make certain such disks are safe to use on 3.1 and earlier
versions of AmigaOS. (Another one would be to modify the disk drivers on
older versions to do the offset calculation in 64 bit, and check for
overflow just as we do here. Not sure whether that's feasible. And as
you so eloquently describe, we can't rely on users listening.)
Either way, we need the cooperation of partitioning tool writers to
ensure partition information that is prone to overflows is never stored
in the 32 bit, classic RDB. That appears to have failed already, as
Martin's experience illustrates.
I'm only concerned with fixing the (dangerous) but in the Linux
partition format parser for RDB. Refusing to use any partitions that
will cause havoc on old AmigaOS versions is all I can do to try and get
the users' attention.
Your warning makes me wonder whether the log message should just say
'report this bug to linux-m...@vger.kernel.org' to at least try and
educate any that respond about the dangers of their partitioning scheme
before telling them about the override option. Problem with that is, in
about three years no one will remember any of this ...
Cheers,
Michael
Am 28.06.2018 um 15:44 schrieb jdow:
Michael, as long as m68k only supports int fseek( int ) 4 GB * block
size is your HARD limit. Versions that support __int64 fseek64( __int64
) can work with larger disks. RDBs could include RDSK and a new set of
other blocks that replace the last two characters with "64" and use
__int64 where needed in the various values. That way a clever disk
partitioner could give allow normal (32 bit) RDB definitions where
possible. Then at least SOME of the disk could be supported AND a very
clever filesystem that abstracts very large disks properly could give
access to the whole disk. (Read the RDBs first 32 bits. Then if a
filesystem or driveinit was loaded re-read the RDBs to see if new 64 bit
partitions are revealed.
I could be wrong but I do not think RDBs could be safely modified any
other way to work. And, trust me as I bet this is still true, you will
need a SERIOUSLY good bomb shelter on the Moon if you change RDBs.
Suppose Joe Amigoid uses it, and then Joe Amigoid loads Amigados 2.4
because he wants to run a game that crashes on anything newer. Then Joe
got far enough something writes to the disk and data is corrupted. Note
further that Amigoids do NOT, repeat NOT, listen to facts in such cases.
Hell, some of them never listened to facts about an incident at Jerry
Pournelle's place when a 1.1 DPaint session with Kelly Freas hung and we
lost a delightful drawing. Jerry reported it. Amigoids screamed. I tried
to tell them I was there, it was my machine, and 1.1 was, indeed, crap.
{o.o}
On 20180627 02:00, Michael Schmitz wrote:
Joanne,
I'm not at all allergic to avoiding RDB at all cost for new disks. If
AmigaOS 4.1 supports more recent partition formats, all the better.
This is all about supporting use of legacy RDB disks on Linux (though
2 TB does stretch the definition of 'legacy' a little). My interest in
this is to ensure we can continue to use RDB format disks on m68k
Amiga computers which have no other way to boot Linux from disk.
Not proposing to change the RDB format at all, either. Just trying to
make sure we translate RDB info into Linux 512-byte block offset and
size numbers correctly. The kernel won't modify the RDB at all
(intentionally, that is - with the correct choice of partition sizes,
Martin might well have wiped out his RDB with the current version of
the parser).
The choice of refusing to mount a disk (or mounting read-only) rests
with the VFS drivers alone - AFFS in that case. Not touching any of
that. At partition scan time, we only have the option of making the
partition available (with a warning printed), or refusing to make it
available to the kernel. Once it's made available, all bets are off.
From what Martin writes, his test case RDB was valid and worked as
expected on 32 bit AmigaOS (4.1). Apparently, that version has the
necessary extensions to handle the large offsets resulting from 2 TB
disks. Not sure what safeguards are in place when connecting such a
disk to older versions of AmigaOS, but that is a different matter
entirely.
The overflows in partition offset and size are the only ones I can see
in the partition parser - there is no other overflow I've identified.
I just stated that in order to place a partition towards the end of a
2 TB disk, the offset calculation will overflow regardless of what
combination of rdb->rd
[RFC PATCH 4/5] arm: dts: zynq: rename board zed to zedboard
The real name of the board is ZedBoard, from Avnet
Signed-off-by: Luis Araneda
---
Documentation/devicetree/bindings/arm/xilinx.txt | 2 +-
arch/arm/boot/dts/Makefile| 2 +-
arch/arm/boot/dts/{zynq-zed.dts => zynq-zedboard.dts} | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
rename arch/arm/boot/dts/{zynq-zed.dts => zynq-zedboard.dts} (93%)
diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt
b/Documentation/devicetree/bindings/arm/xilinx.txt
index f1e911058..d10adc4d0 100644
--- a/Documentation/devicetree/bindings/arm/xilinx.txt
+++ b/Documentation/devicetree/bindings/arm/xilinx.txt
@@ -30,7 +30,7 @@ Additional compatible strings:
"xlnx,zynq-zc770-xm013"
- Avnet ZedBoard board
- "avnet,zynq-zed"
+ "avnet,zynq-zedboard"
- Digilent Zybo board
"digilent,zynq-zybo"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 37a3de760..e4c39e26f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1108,7 +1108,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zc770-xm011.dtb \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb \
- zynq-zed.dtb \
+ zynq-zedboard.dtb \
zynq-zybo.dtb \
zynq-zybo-z7.dtb
dtb-$(CONFIG_MACH_ARMADA_370) += \
diff --git a/arch/arm/boot/dts/zynq-zed.dts
b/arch/arm/boot/dts/zynq-zedboard.dts
similarity index 93%
rename from arch/arm/boot/dts/zynq-zed.dts
rename to arch/arm/boot/dts/zynq-zedboard.dts
index bf3e26dbf..540581c56 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zedboard.dts
@@ -8,7 +8,7 @@
/ {
model = "Avnet ZedBoard board";
- compatible = "avnet,zynq-zed", "xlnx,zynq-7000";
+ compatible = "avnet,zynq-zedboard", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
--
2.18.0
[RFC PATCH 0/5] arm: dts: zynq: improvements and cleanup
This series attempts to standardize device naming and improve
its information for better identification
The values of the "compatible" and "model" device-tree properties
are corrected for some devices, adding complementary information
when necessary
Additionally, a device-tree file is renamed to reflect the real model
of the device
I'm sending the series as an RFC because I don't know if
device-tree files can be renamed and properties be changed
(the last patch in particular)
The patches are sorted (descending) by what I think is
the probability of being accepted
Luis Araneda (5):
arm: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed
boards
dt-bindings: xilinx: Add missing zynq boards
arm: dts: zynq: correct and improve the model property of dt files
arm: dts: zynq: rename board zed to zedboard
arm: dts: zynq: remove "zynq" prefix from compatible property
.../devicetree/bindings/arm/xilinx.txt| 34 ++-
arch/arm/boot/dts/Makefile| 2 +-
arch/arm/boot/dts/zynq-cc108.dts | 4 +--
arch/arm/boot/dts/zynq-microzed.dts | 4 +--
arch/arm/boot/dts/zynq-parallella.dts | 2 +-
arch/arm/boot/dts/zynq-zc702.dts | 4 +--
arch/arm/boot/dts/zynq-zc706.dts | 4 +--
arch/arm/boot/dts/zynq-zc770-xm010.dts| 4 +--
arch/arm/boot/dts/zynq-zc770-xm011.dts| 4 +--
arch/arm/boot/dts/zynq-zc770-xm012.dts| 4 +--
arch/arm/boot/dts/zynq-zc770-xm013.dts| 4 +--
.../dts/{zynq-zed.dts => zynq-zedboard.dts} | 4 +--
arch/arm/boot/dts/zynq-zybo-z7.dts| 4 +--
arch/arm/boot/dts/zynq-zybo.dts | 4 +--
14 files changed, 50 insertions(+), 32 deletions(-)
rename arch/arm/boot/dts/{zynq-zed.dts => zynq-zedboard.dts} (89%)
--
2.18.0
[RFC PATCH 2/5] dt-bindings: xilinx: Add missing zynq boards
The bindings were missing when adding the device-tree files Also, improve description of existing boards Signed-off-by: Luis Araneda --- .../devicetree/bindings/arm/xilinx.txt| 22 +-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index b9043bc35..f1e911058 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -8,15 +8,33 @@ Required root node properties: Additional compatible strings: -- Xilinx internal board cc108 +- Xilinx CC108 board "xlnx,zynq-cc108" -- Xilinx internal board zc770 with different FMC cards +- Avnet MicroZed board + "avnet,zynq-microzed" + +- Adapteva Parallella board + "adapteva,parallella" + +- Xilinx ZC702 board + "xlnx,zynq-zc702" + +- Xilinx ZC706 board + "xlnx,zynq-zc706" + +- Xilinx ZC770 board, with different FMC cards "xlnx,zynq-zc770-xm010" "xlnx,zynq-zc770-xm011" "xlnx,zynq-zc770-xm012" "xlnx,zynq-zc770-xm013" +- Avnet ZedBoard board + "avnet,zynq-zed" + +- Digilent Zybo board + "digilent,zynq-zybo" + - Digilent Zybo Z7 board "digilent,zynq-zybo-z7" -- 2.18.0
[RFC PATCH 5/5] arm: dts: zynq: remove "zynq" prefix from compatible property
The value "zynq" isn't officially part of the model on any board.
Additionally, the value is redundant as it's included in a
subsequent value of the property.
Signed-off-by: Luis Araneda
---
.../devicetree/bindings/arm/xilinx.txt| 22 +--
arch/arm/boot/dts/zynq-cc108.dts | 2 +-
arch/arm/boot/dts/zynq-microzed.dts | 2 +-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm010.dts| 2 +-
arch/arm/boot/dts/zynq-zc770-xm011.dts| 2 +-
arch/arm/boot/dts/zynq-zc770-xm012.dts| 2 +-
arch/arm/boot/dts/zynq-zc770-xm013.dts| 2 +-
arch/arm/boot/dts/zynq-zedboard.dts | 2 +-
arch/arm/boot/dts/zynq-zybo-z7.dts| 2 +-
arch/arm/boot/dts/zynq-zybo.dts | 2 +-
12 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt
b/Documentation/devicetree/bindings/arm/xilinx.txt
index d10adc4d0..0785acce4 100644
--- a/Documentation/devicetree/bindings/arm/xilinx.txt
+++ b/Documentation/devicetree/bindings/arm/xilinx.txt
@@ -9,34 +9,34 @@ Required root node properties:
Additional compatible strings:
- Xilinx CC108 board
- "xlnx,zynq-cc108"
+ "xlnx,cc108"
- Avnet MicroZed board
- "avnet,zynq-microzed"
+ "avnet,microzed"
- Adapteva Parallella board
"adapteva,parallella"
- Xilinx ZC702 board
- "xlnx,zynq-zc702"
+ "xlnx,zc702"
- Xilinx ZC706 board
- "xlnx,zynq-zc706"
+ "xlnx,zc706"
- Xilinx ZC770 board, with different FMC cards
- "xlnx,zynq-zc770-xm010"
- "xlnx,zynq-zc770-xm011"
- "xlnx,zynq-zc770-xm012"
- "xlnx,zynq-zc770-xm013"
+ "xlnx,zc770-xm010"
+ "xlnx,zc770-xm011"
+ "xlnx,zc770-xm012"
+ "xlnx,zc770-xm013"
- Avnet ZedBoard board
- "avnet,zynq-zedboard"
+ "avnet,zedboard"
- Digilent Zybo board
- "digilent,zynq-zybo"
+ "digilent,zybo"
- Digilent Zybo Z7 board
- "digilent,zynq-zybo-z7"
+ "digilent,zybo-z7"
---
diff --git a/arch/arm/boot/dts/zynq-cc108.dts b/arch/arm/boot/dts/zynq-cc108.dts
index 8b9ab9bba..ccff20099 100644
--- a/arch/arm/boot/dts/zynq-cc108.dts
+++ b/arch/arm/boot/dts/zynq-cc108.dts
@@ -13,7 +13,7 @@
/ {
model = "Xilinx CC108 board";
- compatible = "xlnx,zynq-cc108", "xlnx,zynq-7000";
+ compatible = "xlnx,cc108", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
index 3cc957428..ef55adb02 100644
--- a/arch/arm/boot/dts/zynq-microzed.dts
+++ b/arch/arm/boot/dts/zynq-microzed.dts
@@ -8,7 +8,7 @@
/ {
model = "Avnet MicroZed board";
- compatible = "avnet,zynq-microzed", "xlnx,zynq-7000";
+ compatible = "avnet,microzed", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 3f84b94db..bd633a9bc 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -8,7 +8,7 @@
/ {
model = "Xilinx ZC702 board";
- compatible = "xlnx,zynq-zc702", "xlnx,zynq-7000";
+ compatible = "xlnx,zc702", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index a15908cac..f4805f01b 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -8,7 +8,7 @@
/ {
model = "Xilinx ZC706 board";
- compatible = "xlnx,zynq-zc706", "xlnx,zynq-7000";
+ compatible = "xlnx,zc706", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
diff --git a/arch/arm/boot/dts/zynq-zc770-xm010.dts
b/arch/arm/boot/dts/zynq-zc770-xm010.dts
index 0e1bfdd34..21f457656 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm010.dts
@@ -9,7 +9,7 @@
/ {
model = "Xilinx ZC770 XM010 board";
- compatible = "xlnx,zynq-zc770-xm010", "xlnx,zynq-7000";
+ compatible = "xlnx,zc770-xm010", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
diff --git a/arch/arm/boot/dts/zynq-zc770-xm011.dts
b/arch/arm/boot/dts/zynq-zc770-xm011.dts
index b7f65862c..e4a0b2629 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm011.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm011.dts
@@ -9,7 +9,7 @@
/ {
model = "Xilinx ZC770 XM011 board";
- compatible = "xlnx,zynq-zc770-xm011", "xlnx,zynq-7000";
+ compatible = "xlnx,zc770-xm011", "xlnx,zynq-7000";
aliases {
i2c0 = &i2c1;
diff --git a/arch/arm/boot/dts/zynq-zc770-xm012.dts
b/arch/arm/boot/dts/zynq-zc770-xm012.dts
index d2359b789..d2ee09590 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm012.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm012.dts
@@ -9,7 +9,7 @@
/ {
model = "Xilinx ZC77
[RFC PATCH 3/5] arm: dts: zynq: correct and improve the model property of dt files
Replace the current value of the model property by a more accurate
description of each board (which includes the manufacturer), as some
of the boards had the same value ("Xilinx Zynq")
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-cc108.dts | 2 +-
arch/arm/boot/dts/zynq-microzed.dts| 2 +-
arch/arm/boot/dts/zynq-parallella.dts | 2 +-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm010.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm011.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm012.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm013.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
arch/arm/boot/dts/zynq-zybo-z7.dts | 2 +-
arch/arm/boot/dts/zynq-zybo.dts| 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-cc108.dts b/arch/arm/boot/dts/zynq-cc108.dts
index 1a0f631c1..8b9ab9bba 100644
--- a/arch/arm/boot/dts/zynq-cc108.dts
+++ b/arch/arm/boot/dts/zynq-cc108.dts
@@ -12,8 +12,8 @@
/include/ "zynq-7000.dtsi"
/ {
+ model = "Xilinx CC108 board";
compatible = "xlnx,zynq-cc108", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 = &gem0;
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
index e40f40a7f..3cc957428 100644
--- a/arch/arm/boot/dts/zynq-microzed.dts
+++ b/arch/arm/boot/dts/zynq-microzed.dts
@@ -7,7 +7,7 @@
/include/ "zynq-7000.dtsi"
/ {
- model = "Zynq MicroZED Development Board";
+ model = "Avnet MicroZed board";
compatible = "avnet,zynq-microzed", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index c05f4b67d..54592aeb9 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -12,7 +12,7 @@
/include/ "zynq-7000.dtsi"
/ {
- model = "Adapteva Parallella Board";
+ model = "Adapteva Parallella board";
compatible = "adapteva,parallella", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index f2330b0cb..3f84b94db 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -7,7 +7,7 @@
#include "zynq-7000.dtsi"
/ {
- model = "Zynq ZC702 Development Board";
+ model = "Xilinx ZC702 board";
compatible = "xlnx,zynq-zc702", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 3ad1260ff..a15908cac 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -7,7 +7,7 @@
#include "zynq-7000.dtsi"
/ {
- model = "Zynq ZC706 Development Board";
+ model = "Xilinx ZC706 board";
compatible = "xlnx,zynq-zc706", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc770-xm010.dts
b/arch/arm/boot/dts/zynq-zc770-xm010.dts
index 6884f1ad6..0e1bfdd34 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm010.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM010 board";
compatible = "xlnx,zynq-zc770-xm010", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 = &gem0;
diff --git a/arch/arm/boot/dts/zynq-zc770-xm011.dts
b/arch/arm/boot/dts/zynq-zc770-xm011.dts
index b78883cee..b7f65862c 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm011.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm011.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM011 board";
compatible = "xlnx,zynq-zc770-xm011", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
i2c0 = &i2c1;
diff --git a/arch/arm/boot/dts/zynq-zc770-xm012.dts
b/arch/arm/boot/dts/zynq-zc770-xm012.dts
index c3169d636..d2359b789 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm012.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm012.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM012 board";
compatible = "xlnx,zynq-zc770-xm012", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
i2c0 = &i2c0;
diff --git a/arch/arm/boot/dts/zynq-zc770-xm013.dts
b/arch/arm/boot/dts/zynq-zc770-xm013.dts
index 8bb66859d..651913f1a 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm013.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm013.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM013 board";
compatible = "xlnx,zynq-zc770-xm013", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 = &gem1;
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 98381cc85..bf3e26dbf 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -7,7 +7,7 @@
#include "z
[RFC PATCH 1/5] arm: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed boards
Both boards are made by Avnet, Inc.
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-microzed.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
index aa4a0b6de..e40f40a7f 100644
--- a/arch/arm/boot/dts/zynq-microzed.dts
+++ b/arch/arm/boot/dts/zynq-microzed.dts
@@ -8,7 +8,7 @@
/ {
model = "Zynq MicroZED Development Board";
- compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
+ compatible = "avnet,zynq-microzed", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 53c6883ce..98381cc85 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -8,7 +8,7 @@
/ {
model = "Zynq Zed Development Board";
- compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";
+ compatible = "avnet,zynq-zed", "xlnx,zynq-7000";
aliases {
ethernet0 = &gem0;
--
2.18.0
Re: [PATCH] Fixed typo on line 733.
On Wed, 27 Jun 2018 20:54:34 +0200, Guy Chronister wrote: > > Signed-off-by: Guy Chronister The code change itself is good, but the subject is wrong, and there is no changelog texts. Please describe what it really fixes. It's not about typo fix, but it fixes a real bug, and this has to be written in the subject and explained in more details in the changelog. thanks, Takashi > --- > sound/pci/oxygen/oxygen_mixer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/pci/oxygen/oxygen_mixer.c b/sound/pci/oxygen/oxygen_mixer.c > index 81af21a..ba87213 100644 > --- a/sound/pci/oxygen/oxygen_mixer.c > +++ b/sound/pci/oxygen/oxygen_mixer.c > @@ -730,7 +730,7 @@ static int ac97_fp_rec_volume_put(struct snd_kcontrol > *ctl, > oldreg = oxygen_read_ac97(chip, 1, AC97_REC_GAIN); > newreg = oldreg & ~0x0707; > newreg = newreg | (value->value.integer.value[0] & 7); > - newreg = newreg | ((value->value.integer.value[0] & 7) << 8); > + newreg = newreg | ((value->value.integer.value[1] & 7) << 8); > change = newreg != oldreg; > if (change) > oxygen_write_ac97(chip, 1, AC97_REC_GAIN, newreg); > -- > 2.7.4 > >
Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece
Andrew Morton writes: > On Thu, 28 Jun 2018 13:29:09 +0800 "Huang\, Ying" > wrote: > >> Andrew Morton writes: >> >> > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" >> > wrote: >> > >> >> This is the final step of THP (Transparent Huge Page) swap >> >> optimization. After the first and second step, the splitting huge >> >> page is delayed from almost the first step of swapout to after swapout >> >> has been finished. In this step, we avoid splitting THP for swapout >> >> and swapout/swapin the THP in one piece. >> > >> > It's a tremendously good performance improvement. It's also a >> > tremendously large patchset :( >> > >> > And it depends upon your >> > mm-swap-fix-race-between-swapoff-and-some-swap-operations.patch and >> > mm-fix-race-between-swapoff-and-mincore.patch, the first of which has >> > been floating about since February without adequate review. >> > >> > I'll give this patchset a spin in -mm to see what happens and will come >> > back later to take a closer look. But the best I can do at this time >> > is to hopefully cc some possible reviewers :) >> >> Thanks a lot for your help! Hope more people can review it! > > I took it out of -mm again, temporarily. Due to a huge tangle with the > xarray conversions in linux-next. No problem. I will rebase the patchset on your latest -mm tree, or the next version to be released? Best Regards, Huang, Ying
Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece
On Thu, 28 Jun 2018 13:29:09 +0800 "Huang\, Ying" wrote: > Andrew Morton writes: > > > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" > > wrote: > > > >> This is the final step of THP (Transparent Huge Page) swap > >> optimization. After the first and second step, the splitting huge > >> page is delayed from almost the first step of swapout to after swapout > >> has been finished. In this step, we avoid splitting THP for swapout > >> and swapout/swapin the THP in one piece. > > > > It's a tremendously good performance improvement. It's also a > > tremendously large patchset :( > > > > And it depends upon your > > mm-swap-fix-race-between-swapoff-and-some-swap-operations.patch and > > mm-fix-race-between-swapoff-and-mincore.patch, the first of which has > > been floating about since February without adequate review. > > > > I'll give this patchset a spin in -mm to see what happens and will come > > back later to take a closer look. But the best I can do at this time > > is to hopefully cc some possible reviewers :) > > Thanks a lot for your help! Hope more people can review it! I took it out of -mm again, temporarily. Due to a huge tangle with the xarray conversions in linux-next.
Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece
Andrew Morton writes: > On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" wrote: > >> This is the final step of THP (Transparent Huge Page) swap >> optimization. After the first and second step, the splitting huge >> page is delayed from almost the first step of swapout to after swapout >> has been finished. In this step, we avoid splitting THP for swapout >> and swapout/swapin the THP in one piece. > > It's a tremendously good performance improvement. It's also a > tremendously large patchset :( > > And it depends upon your > mm-swap-fix-race-between-swapoff-and-some-swap-operations.patch and > mm-fix-race-between-swapoff-and-mincore.patch, the first of which has > been floating about since February without adequate review. > > I'll give this patchset a spin in -mm to see what happens and will come > back later to take a closer look. But the best I can do at this time > is to hopefully cc some possible reviewers :) Thanks a lot for your help! Hope more people can review it! Best Regards, Huang, Ying
Re: general protection fault in vmx_vcpu_run
On Sat, Apr 14, 2018 at 3:07 AM, syzbot wrote: > syzbot has found reproducer for the following crash on upstream commit > 1bad9ce155a7c010a9a5f3261ad12a6a8eccfb2c (Fri Apr 13 19:27:11 2018 +) > Merge tag 'sh-for-4.17' of git://git.libc.org/linux-sh > syzbot dashboard link: > https://syzkaller.appspot.com/bug?extid=cc483201a3c6436d3550 > > So far this crash happened 4 times on upstream. > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6257386297753600 > syzkaller reproducer: > https://syzkaller.appspot.com/x/repro.syz?id=4808329293463552 > Raw console output: > https://syzkaller.appspot.com/x/log.txt?id=4943675322793984 > Kernel config: > https://syzkaller.appspot.com/x/.config?id=-5947642240294114534 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+cc483201a3c6436d3...@syzkaller.appspotmail.com > It will help syzbot understand when the bug is fixed. #syz dup: BUG: unable to handle kernel paging request in vmx_vcpu_run > IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready > IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready > 8021q: adding VLAN 0 to HW filter on device team0 > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > Modules linked in: > CPU: 0 PID: 6472 Comm: syzkaller667776 Not tainted 4.16.0+ #1 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:vmx_vcpu_run+0x95f/0x25f0 arch/x86/kvm/vmx.c:9746 > RSP: 0018:8801c95bf368 EFLAGS: 00010002 > RAX: 8801b44df6e8 RBX: 8801ada0ec40 RCX: 1100392b7e78 > RDX: RSI: 81467b15 RDI: 8801ada0ec50 > RBP: 8801b44df790 R08: 8801c4efe780 R09: fbfff1141218 > R10: fbfff1141218 R11: 88a090c3 R12: 8801b186aa90 > R13: 8801ae61e000 R14: dc00 R15: 8801ae61e3e0 > FS: 7fa147982700() GS:8801db00() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: CR3: 0001d780d000 CR4: 001426f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > Code: 8b a9 68 03 00 00 4c 8b b1 70 03 00 00 4c 8b b9 78 03 00 00 48 8b 89 > 08 03 00 00 75 05 0f 01 c2 eb 03 0f 01 c3 48 89 4c 24 08 59 <0f> 96 81 88 56 > 00 00 48 89 81 00 03 00 00 48 89 99 18 03 00 00 > RIP: vmx_vcpu_run+0x95f/0x25f0 arch/x86/kvm/vmx.c:9746 RSP: 8801c95bf368 > ---[ end trace ffd91ebc3bb06b01 ]--- > Kernel panic - not syncing: Fatal exception > Shutting down cpus with NMI > Dumping ftrace buffer: >(ftrace buffer empty) > Kernel Offset: disabled > Rebooting in 86400 seconds.. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/37b58a0569c49b70%40google.com. > > For more options, visit https://groups.google.com/d/optout.
Re: KASAN: stack-out-of-bounds Read in vmx_vcpu_run
On Thu, Jun 28, 2018 at 7:24 AM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:debd52a05061 Merge tag 'scsi-fixes' of git://git.kernel.or.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1058cc9f80 > kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370 > dashboard link: https://syzkaller.appspot.com/bug?extid=74aad0c92138fdbff11f > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+74aad0c92138fdbff...@syzkaller.appspotmail.com #syz dup: BUG: unable to handle kernel paging request in vmx_vcpu_run > == > BUG: KASAN: stack-out-of-bounds in msr_write_intercepted > arch/x86/kvm/vmx.c:2338 [inline] > BUG: KASAN: stack-out-of-bounds in vmx_vcpu_run+0x23ba/0x2600 > arch/x86/kvm/vmx.c:10160 > Read of size 8 at addr 88019755f7a0 by task syz-executor5/21645 > > CPU: 0 PID: 21645 Comm: syz-executor5 Not tainted 4.18.0-rc2+ #119 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 > print_address_description+0x6c/0x20b mm/kasan/report.c:256 > kasan_report_error mm/kasan/report.c:354 [inline] > kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > msr_write_intercepted arch/x86/kvm/vmx.c:2338 [inline] > vmx_vcpu_run+0x23ba/0x2600 arch/x86/kvm/vmx.c:10160 > WARNING: kernel stack frame pointer at b24d5c50 in > syz-executor5:21645 has bad value adda72ba > unwind stack type:0 next_sp: (null) mask:0x2 graph_idx:0 > f6bc44a5: 88019755f210 (0x88019755f210) > 3207c122: 812a9095 (show_trace_log_lvl+0x1f6/0x28c) > 4e97c852: 811f576a (vmx_vcpu_run+0x23ba/0x2600) > cd5e7e10: 88019755f368 (0x88019755f368) > b3ed19e4: 0002 (0x2) > 967e7c78: 0001 (0x1) > 57be443f: 880197558000 (0x880197558000) > 7809f181: 88019756 (0x88019756) > a0a291fa: ... > 677def61: 880197558000 (0x880197558000) > 7321ac4a: 88019756 (0x88019756) > 7423cee7: ... > a148b5c1: 0002 (0x2) > a37f5c7d: 8801b1ba2780 (0x8801b1ba2780) > 8234600d: 0001 (0x1) > d6767ac7: 88019755f360 (0x88019755f360) > d047810d: 88019755f140 (0x88019755f140) > b15843e3: 811f576a (vmx_vcpu_run+0x23ba/0x2600) > e6b8af55: ... > 77346d63: f6729f4af8185300 (0xf6729f4af8185300) > 62093407: 0016 (0x16) > 581fc196: ... > 7a661406: 88f1b0a0 (pv_cpu_ops+0x120/0x120) > a4980fed: (0x) > 708d3d3f: 88019755f220 (0x88019755f220) > bdc264ab: 812a9163 (show_stack+0x38/0x3a) > ced6bc99: 88019755f2d0 (0x88019755f2d0) > 8c2e2231: 878af5b5 (dump_stack+0x1c9/0x2b4) > 41a32e6b: fbfff11e3614 (0xfbfff11e3614) > e10c52bf: dc00 (0xdc00) > 4d053b1b: 110032eabe49 (0x110032eabe49) > 35d88931: 41b58ab3 (0x41b58ab3) > 4a562365: 88bd7ad4 (regoff.34027+0x3680f4/0x37ac50) > 9f1914b6: 878af3ec (dump_stack_print_info.cold.2+0x52/0x52) > f03e0fba: 8163049b (printk+0xa7/0xcf) > d8655ef3: 41b58ab3 (0x41b58ab3) > e16aa3ec: 88bedb4c (K512_4+0x130c/0x120414) > a10fbcdd: 816303f4 (kmsg_dump_rewind_nolock+0xe4/0xe4) > 95377466: 89029bc0 (kmem_cache_boot+0x320/0x320) > 258ab7c5: 0008 (0x0008) > 244091b8: 88019755f318 (0x88019755f318) > f6a76323: 88019755f2c8 (0x88019755f2c8) > eb8ea1b3: f6729f4af8185300 (0xf6729f4af8185300) > 64c60c7f: ea00065d57c0 (0xea00065d57c0) > 8343ef5c: 0008 (0x8) > e70d1b6e: 88019755f7a0 (0x88019755f7a0) > 3a3b04c2: 811f576a (vmx_vcpu_run+0x23ba/0x2600) > cf60c7bc: 88019755f7a0 (0x88019755f7a0) > 72788657: 88019755f308 (0x88019755f308) > 6a758353: 81b9e384 (print_address_description+0x6c/0x20b) > 33ab7b1c: 88019755f7a0 (0x88019755f7a0) > 0bc48851: 0008 (0x8) > fb786515: ... > eb1d1d22: 811f576a (vmx_vcpu_run+0x23ba/0x2600) > 51fa6761: 88019755f7a
KASAN: stack-out-of-bounds Read in vmx_vcpu_run
Hello, syzbot found the following crash on: HEAD commit:debd52a05061 Merge tag 'scsi-fixes' of git://git.kernel.or.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1058cc9f80 kernel config: https://syzkaller.appspot.com/x/.config?x=a63be0c83e84d370 dashboard link: https://syzkaller.appspot.com/bug?extid=74aad0c92138fdbff11f compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+74aad0c92138fdbff...@syzkaller.appspotmail.com == BUG: KASAN: stack-out-of-bounds in msr_write_intercepted arch/x86/kvm/vmx.c:2338 [inline] BUG: KASAN: stack-out-of-bounds in vmx_vcpu_run+0x23ba/0x2600 arch/x86/kvm/vmx.c:10160 Read of size 8 at addr 88019755f7a0 by task syz-executor5/21645 CPU: 0 PID: 21645 Comm: syz-executor5 Not tainted 4.18.0-rc2+ #119 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 msr_write_intercepted arch/x86/kvm/vmx.c:2338 [inline] vmx_vcpu_run+0x23ba/0x2600 arch/x86/kvm/vmx.c:10160 WARNING: kernel stack frame pointer at b24d5c50 in syz-executor5:21645 has bad value adda72ba unwind stack type:0 next_sp: (null) mask:0x2 graph_idx:0 f6bc44a5: 88019755f210 (0x88019755f210) 3207c122: 812a9095 (show_trace_log_lvl+0x1f6/0x28c) 4e97c852: 811f576a (vmx_vcpu_run+0x23ba/0x2600) cd5e7e10: 88019755f368 (0x88019755f368) b3ed19e4: 0002 (0x2) 967e7c78: 0001 (0x1) 57be443f: 880197558000 (0x880197558000) 7809f181: 88019756 (0x88019756) a0a291fa: ... 677def61: 880197558000 (0x880197558000) 7321ac4a: 88019756 (0x88019756) 7423cee7: ... a148b5c1: 0002 (0x2) a37f5c7d: 8801b1ba2780 (0x8801b1ba2780) 8234600d: 0001 (0x1) d6767ac7: 88019755f360 (0x88019755f360) d047810d: 88019755f140 (0x88019755f140) b15843e3: 811f576a (vmx_vcpu_run+0x23ba/0x2600) e6b8af55: ... 77346d63: f6729f4af8185300 (0xf6729f4af8185300) 62093407: 0016 (0x16) 581fc196: ... 7a661406: 88f1b0a0 (pv_cpu_ops+0x120/0x120) a4980fed: (0x) 708d3d3f: 88019755f220 (0x88019755f220) bdc264ab: 812a9163 (show_stack+0x38/0x3a) ced6bc99: 88019755f2d0 (0x88019755f2d0) 8c2e2231: 878af5b5 (dump_stack+0x1c9/0x2b4) 41a32e6b: fbfff11e3614 (0xfbfff11e3614) e10c52bf: dc00 (0xdc00) 4d053b1b: 110032eabe49 (0x110032eabe49) 35d88931: 41b58ab3 (0x41b58ab3) 4a562365: 88bd7ad4 (regoff.34027+0x3680f4/0x37ac50) 9f1914b6: 878af3ec (dump_stack_print_info.cold.2+0x52/0x52) f03e0fba: 8163049b (printk+0xa7/0xcf) d8655ef3: 41b58ab3 (0x41b58ab3) e16aa3ec: 88bedb4c (K512_4+0x130c/0x120414) a10fbcdd: 816303f4 (kmsg_dump_rewind_nolock+0xe4/0xe4) 95377466: 89029bc0 (kmem_cache_boot+0x320/0x320) 258ab7c5: 0008 (0x0008) 244091b8: 88019755f318 (0x88019755f318) f6a76323: 88019755f2c8 (0x88019755f2c8) eb8ea1b3: f6729f4af8185300 (0xf6729f4af8185300) 64c60c7f: ea00065d57c0 (0xea00065d57c0) 8343ef5c: 0008 (0x8) e70d1b6e: 88019755f7a0 (0x88019755f7a0) 3a3b04c2: 811f576a (vmx_vcpu_run+0x23ba/0x2600) cf60c7bc: 88019755f7a0 (0x88019755f7a0) 72788657: 88019755f308 (0x88019755f308) 6a758353: 81b9e384 (print_address_description+0x6c/0x20b) 33ab7b1c: 88019755f7a0 (0x88019755f7a0) 0bc48851: 0008 (0x8) fb786515: ... eb1d1d22: 811f576a (vmx_vcpu_run+0x23ba/0x2600) 51fa6761: 88019755f7a0 (0x88019755f7a0) 241d6f8f: 88019755f350 (0x88019755f350) 64caa33c: 81b9e765 (kasan_report.cold.7+0x242/0x2fe) 61971ddf: 0082 (0x82) c8bdbff7: f6729f4af8185300 (0xf6729f4af8185300) 4dad3fe7: 1000 (0x10
Re: [PATCH v4 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices
On Thu, Jun 28, 2018 at 11:06:13AM +0800, Sean Wang wrote:
> On Wed, 2018-06-27 at 20:04 +0300, Andy Shevchenko wrote:
> > On Wed, Jun 27, 2018 at 7:59 PM, Andy Shevchenko
> > wrote:
> > > On Wed, Jun 27, 2018 at 8:43 AM, wrote:
> > >> From: Sean Wang
> > >> +#include
> > >> +#include
> >
> > >> + /* Enable the power domain and clock the device requires. */
> > >> + pm_runtime_enable(dev);
> > >> + err = pm_runtime_get_sync(dev);
> > >> + if (err < 0)
> > >> + goto err_pm2;
> > >> +err_pm1:
> > >> + pm_runtime_put_sync(dev);
> > >> +err_pm2:
> > >> + pm_runtime_disable(dev);
Please name error labels after what they do, not using numbers (see
CodingStyle). Here you could use err_disable_rpm instead of err_pm2, for
example.
Also, if you really want to undo pm_runtime_get_sync() failing above,
you still need a pm_runtime_put_noidle() to balance the usage count.
> > >> +struct mtk_stp_hdr {
> > >> + __u8 prefix;
> > >> + __u8 dlen1:4;
> > >> + __u8 type:4;
> >
> > >> + __u8 dlen2:8;
> > >> + __u8 cs;
> > >> +} __packed;
Perhaps too much context have been lost here, but unless you're sharing
this struct with user space, you should be using u8 (without __) above
(and elsewhere).
Johan
[PATCH v2 2/2] leds: sc27xx: Add pattern_set/get/clear interfaces for LED controller
This patch implements the 'pattern_set', 'pattern_get' and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
---
Changes from v1:
- No updates.
---
drivers/leds/leds-sc27xx-bltc.c | 160 +++
1 file changed, 160 insertions(+)
diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..898f92d 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
/* PMIC global control register definition */
@@ -32,8 +33,13 @@
#define SC27XX_DUTY_MASK GENMASK(15, 0)
#define SC27XX_MOD_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
#define SC27XX_LEDS_OFFSET 0x10
#define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +128,157 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum
led_brightness value)
return err;
}
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ struct regmap *regmap = leds->priv->regmap;
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ int err;
+
+ mutex_lock(&leds->priv->lock);
+
+ /* Reset the rise, high, fall and low time to zero. */
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+ regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+ err = regmap_update_bits(regmap, ctrl_base,
+ (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+ mutex_unlock(&leds->priv->lock);
+
+ return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ int len)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ u32 base = sc27xx_led_get_offset(leds);
+ u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+ u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+ struct regmap *regmap = leds->priv->regmap;
+ int err;
+
+ /*
+* Must contain 4 patterns to configure the rise time, high time, fall
+* time and low time to enable the breathing mode.
+*/
+ if (len != SC27XX_LEDS_PATTERN_CNT)
+ return -EINVAL;
+
+ mutex_lock(&leds->priv->lock);
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE0,
+SC27XX_CURVE_L_MASK, pattern[0].delta_t);
+ if (err)
+ goto out;
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE1,
+SC27XX_CURVE_L_MASK, pattern[1].delta_t);
+ if (err)
+ goto out;
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE0,
+SC27XX_CURVE_H_MASK,
+pattern[2].delta_t << SC27XX_CURVE_SHIFT);
+ if (err)
+ goto out;
+
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE1,
+SC27XX_CURVE_H_MASK,
+pattern[3].delta_t << SC27XX_CURVE_SHIFT);
+ if (err)
+ goto out;
+
+
+ err = regmap_update_bits(regmap, base + SC27XX_LEDS_DUTY,
+SC27XX_DUTY_MASK,
+(pattern[0].brightness << SC27XX_DUTY_SHIFT) |
+SC27XX_MOD_MASK);
+ if (err)
+ goto out;
+
+ /* Enable the LED breathing mode */
+ err = regmap_update_bits(regmap, ctrl_base,
+SC27XX_LED_RUN << ctrl_shift,
+SC27XX_LED_RUN << ctrl_shift);
+
+out:
+ mutex_unlock(&leds->priv->lock);
+
+ return err;
+}
+
+static struct led_pattern *sc27xx_led_pattern_get(struct led_classdev *ldev,
+ int *len)
+{
+ struct sc27xx_led *leds = to_sc27xx_led(ldev);
+ u32 base = sc27xx_led_get_offset(leds);
+ struct regmap *regmap = leds->priv->regmap;
+ struct led_pattern *pattern;
+ int i, err;
+ u32 val;
+
+ /*
+* Must allocate 4 patterns to show the rise time, high time, fall time
+* and low time.
+*/
+ pattern = kcalloc(SC27XX_LEDS_PATTERN_CNT, sizeof(*pattern),
+ GFP_KERNEL);
+ if (!pattern)
+ return ERR_PTR(-ENOMEM);
+
+ mutex_lock(&leds->priv->lock);
+
+ err = regmap_read(regmap, base + SC27XX_LEDS_CURVE0, &val);
+ if (err)
+ goto out;
+
+ patte
[PATCH v2 1/2] leds: core: Introduce generic pattern interface
From: Bjorn Andersson
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This adds a new optional operator that LED class drivers can implement
if they support such functionality as well as a new device attribute to
configure the pattern for a given LED.
[Baolin Wang did some minor improvements.]
Signed-off-by: Bjorn Andersson
Signed-off-by: Baolin Wang
---
Changes from v1:
- Add some comments suggested by Pavel.
- Change 'delta_t' can be 0.
Note: I removed the pattern repeat check and will get the repeat number by
adding
one extra file named 'pattern_repeat' according to previous discussion.
---
Documentation/ABI/testing/sysfs-class-led | 17
drivers/leds/led-class.c | 121 +
include/linux/leds.h | 19 +
3 files changed, 157 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-led
b/Documentation/ABI/testing/sysfs-class-led
index 5f67f7a..aec0284 100644
--- a/Documentation/ABI/testing/sysfs-class-led
+++ b/Documentation/ABI/testing/sysfs-class-led
@@ -61,3 +61,20 @@ Description:
gpio and backlight triggers. In case of the backlight trigger,
it is useful when driving a LED which is intended to indicate
a device in a standby like state.
+
+What: /sys/class/leds//pattern
+Date: June 2018
+KernelVersion: 4.18
+Description:
+ Specify a pattern for the LED, for LED hardware that support
+ altering the brightness as a function of time.
+
+ The pattern is given by a series of tuples, of brightness and
+ duration (ms). The LED is expected to traverse the series and
+ each brightness value for the specified duration. Duration of
+ 0 means brightness should immediately change to new value.
+
+ As LED hardware might have different capabilities and precision
+ the requested pattern might be slighly adjusted by the driver
+ and the resulting pattern of such operation should be returned
+ when this file is read.
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 3c7e348..1c23f63 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -74,6 +74,125 @@ static ssize_t max_brightness_show(struct device *dev,
}
static DEVICE_ATTR_RO(max_brightness);
+static ssize_t pattern_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_pattern *pattern;
+ size_t offset = 0;
+ int count, n, i;
+
+ if (!led_cdev->pattern_get)
+ return -EOPNOTSUPP;
+
+ pattern = led_cdev->pattern_get(led_cdev, &count);
+ if (IS_ERR_OR_NULL(pattern))
+ return PTR_ERR(pattern);
+
+ for (i = 0; i < count; i++) {
+ n = snprintf(buf + offset, PAGE_SIZE - offset, "%d %d",
+pattern[i].brightness, pattern[i].delta_t);
+
+ if (offset + n >= PAGE_SIZE)
+ goto err_nospc;
+
+ offset += n;
+
+ if (i < count - 1)
+ buf[offset++] = ' ';
+ }
+
+ buf[offset++] = '\n';
+
+ kfree(pattern);
+ return offset;
+
+err_nospc:
+ kfree(pattern);
+ return -ENOSPC;
+}
+
+static ssize_t pattern_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_pattern *pattern = NULL;
+ unsigned long val;
+ char *sbegin;
+ char *elem;
+ char *s;
+ int ret, len = 0;
+ bool odd = true;
+
+ s = sbegin = kstrndup(buf, size, GFP_KERNEL);
+ if (!s)
+ return -ENOMEM;
+
+ /* Trim trailing newline */
+ s[strcspn(s, "\n")] = '\0';
+
+ /* If the remaining string is empty, clear the pattern */
+ if (!s[0]) {
+ ret = led_cdev->pattern_clear(led_cdev);
+ goto out;
+ }
+
+ pattern = kcalloc(size, sizeof(*pattern), GFP_KERNEL);
+ if (!pattern) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ /* Parse out the brightness & delta_t touples */
+ while ((elem = strsep(&s, " ")) != NULL) {
+ ret = kstrtoul(elem, 10, &val);
+ if (ret)
+ goto out;
+
+ if (odd) {
+ pattern[len].brightness = val;
+ } else {
+ pattern[len].delta_t = val;
+ len++;
+ }
+
+ odd = !odd;
+ }
+
+ /*
+* Fail if we didn't find any data points or last data point was partial
+*/
+ if (!len || !odd) {
+ ret = -EINVAL;
Re: [PATCH tip/core/rcu 13/22] rcu: Fix grace-period hangs due to race with CPU offline
On Wed, Jun 27, 2018 at 07:51:34PM +0200, Peter Zijlstra wrote: > On Wed, Jun 27, 2018 at 08:57:21AM -0700, Paul E. McKenney wrote: > > > Another variant, which simply skips the wakeup whever ran on an offline > > > CPU, relying on the wakeup from rcutree_migrate_callbacks() right after > > > the CPU really is dead. > > > > Cute! ;-) > > > > And a much smaller change. > > > > However, this means that if someone indirectly and erroneously causes > > rcu_report_qs_rsp() to be invoked from an offline CPU, the result is an > > intermittent and difficult-to-debug grace-period hang. A lockdep splat > > whose stack trace directly implicates the culprit is much better. > > How so? We do an unconditional wakeup right after finding the offline > cpu dead. There is only very limited code between offline being true and > the CPU reporting in dead. I am thinking more generally than this particular patch. People sometimes invoke things from places they shouldn't, for example, the situation leading to your patch that allows use of RCU much earlier in the CPU-online process. It is nicer to get a splat in those situations than a silent hang. Thanx, Paul
Re: [PATCH tip/core/rcu 16/27] rcu: Add comment documenting how rcu_seq_snap works
On Wed, Jun 27, 2018 at 11:27:26AM -0700, Joel Fernandes wrote:
[..]
> > > > s = __ALIGN_MASK(s, RCU_SEQ_STATE_MASK);
> > > >
> > >
> > > I agree with Peter's suggestions for both the verbiage reduction in the
> > > comments in the header, as the new code he is proposing is more
> > > self-documenting. I believe I proposed a big comment just because the code
> > > wasn't self-documenting or obvious previously so needed an explanation.
> > >
> > > How would you like to proceed? Let me know what you guys decide, I am
> > > really
> > > Ok with anything. If you guys agree, should I write a follow-up patch with
> > > Peter's suggestion that applies on top of this one? Or do we want to drop
> > > this one in favor of Peter's suggestion?
> >
> > Shortening the comment would be good, so please do that.
Paul,
Do you want to fold the below patch into the original one? Or do you prefer I
resent the original patch fixed up?
Following is the patch ontop of current 'dev' branch in your tree, with the
excessive comments removed.
Thanks to Peter for suggesting!
---8<---
From: "Joel Fernandes (Google)"
Subject: [PATCH] rcu: Remove excessive commentary on rcu_seq_snap
There isn't a strong need to explain in excessive detail about
rcu_seq_snap with an example. Remove unnecessary and redundant comments.
Suggested-by: Peter Zijlstra
Fixes: 9701945dd79e ("rcu: Add comment documenting how rcu_seq_snap works")
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcu.h | 22 --
1 file changed, 22 deletions(-)
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 0af6ce6d8b66..4d04683c31b2 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -101,28 +101,6 @@ static inline void rcu_seq_end(unsigned long *sp)
* current time. This value is the current grace-period number plus two to the
* power of the number of low-order bits reserved for state, then rounded up to
* the next value in which the state bits are all zero.
- *
- * In the current design, RCU_SEQ_STATE_MASK=3 and the least significant bit of
- * the seq is used to track if a GP is in progress or not. Given this, it is
- * sufficient if we add (6+1) and mask with ~3 to get the next GP. Let's see
- * why with an example:
- *
- * Say the current seq is 12 which is 0b1100 (GP is 3 and state bits are 0b00).
- * To get to the next GP number of 4, we have to add 0b100 to this (0x1 << 2)
- * to account for the shift due to 2 state bits. Now, if the current seq is
- * 13 (GP is 3 and state bits are 0b01), then it means the current grace period
- * is already in progress so the next GP that a future call back will be queued
- * to run at is GP+2 = 5, not 4. To account for the extra +1, we just overflow
- * the 2 lower bits by adding 0b11. In case the lower bit was set, the overflow
- * will cause the extra +1 to the GP, along with the usual +1 explained before.
- * This gives us GP+2. Finally we mask the lower to bits by ~0x3 in case the
- * overflow didn't occur. This masking is needed because in case RCU was idle
- * (no GP in progress so lower 2 bits are 0b00), then the overflow of the lower
- * 2 state bits wouldn't occur, so we mask to zero out those lower 2 bits.
- *
- * In other words, the next seq can be obtained by (0b11 + 0b100) & (~0b11)
- * which can be generalized to:
- * seq + (RCU_SEQ_STATE_MASK + (RCU_SEQ_STATE_MASK + 1)) &
(~RCU_SEQ_STATE_MASK)
*/
static inline unsigned long rcu_seq_snap(unsigned long *sp)
{
--
2.18.0.rc2.346.g013aa6912e-goog
Re: [PATCH 12/14] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire
Hi Ben,
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
> is currently unused on OpenPower systems.
>
> This adds an alternative to the fsi-master-gpio driver that
> uses that coprocessor instead of bit banging from the ARM
> core itself. The end result is about 4 times faster.
>
> The firmware for the coprocessor and its source code can be
> found at https://github.com/ozbenh/cf-fsi and is system specific.
>
> Currently tested on Romulus and Palmetto systems.
>
> Signed-off-by: Benjamin Herrenschmidt
Nice work. I gave this a spin on Romulus and it looked good.
If you run it through sparse there are a bunch of things to fix. I've
also got some comments below.
> --- /dev/null
> +++ b/drivers/fsi/cf-fsi-fw.h
> @@ -0,0 +1,131 @@
Copyright?
> +#ifndef __CF_FSI_FW_H
> +#define __CF_FSI_FW_H
> +
> +/*
> + * uCode file layout
> + *
> + * ...03ff : m68k exception vectors
> + * 0400...04ff : Header info & boot config block
> + * 0500... : Code & stack
> + */
> diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
> new file mode 100644
> index ..6b17f27c27f6
> --- /dev/null
> +++ b/drivers/fsi/fsi-master-ast-cf.c
> @@ -0,0 +1,1376 @@
> +// SPDX-License-Identifier: GPL-2.0
Normally 2+ for new IBM code? You also need something like this on the
next line:
// Copyright 2018 IBM Corp
> +static int read_copro_response(struct fsi_master_acf *master, uint8_t size,
> + __be32 *response, u8 *tag)
> +{
> + u8 rtag = readb(master->sram + STAT_RTAG);
> + u8 rcrc = readb(master->sram + STAT_RCRC);
> + __be32 rdata = 0;
> + u32 crc;
> + u8 ack;
> +
> + *tag = ack = rtag & 3;
> +
> + /* we have a whole message now; check CRC */
> + crc = crc4(0, 1, 1);
> + crc = crc4(crc, rtag, 4);
> + if (ack == FSI_RESP_ACK && size) {
> + rdata = readl(master->sram + RSP_DATA);
> + crc = crc4(crc, be32_to_cpu(rdata), 32);
> + if (response)
> + *response = rdata;
> + }
> + crc = crc4(crc, rcrc, 4);
> +
> + trace_fsi_master_acf_copro_response(master, rtag, rcrc, rdata, crc ==
> 0);
> +
> + if (crc) {
> + /*
> +* Check if it's all 1's or all 0's, that probably means
> +* the host is off
> +*/
> + if ((rtag == 0xf && rcrc == 0xf) || (rtag == 0 && rcrc == 0))
> + return -ENODEV;
> + dev_dbg(master->dev, "Bad response CRC !\n");
> + return -EAGAIN;
> + }
> + return 0;
> +}
> +
> +static int send_term(struct fsi_master_acf *master, uint8_t slave)
> +{
> + struct fsi_msg cmd;
> + uint8_t tag;
> + int rc;
> +
> + build_term_command(&cmd, slave);
> +
> + rc = send_request(master, &cmd, true);
> + if (rc) {
> + dev_warn(master->dev, "Error %d sending term\n", rc);
> + return rc;
> + }
> +
> + rc = read_copro_response(master, 0, NULL, &tag);
> + if (rc < 0) {
> + dev_err(master->dev,
> + "TERM failed; lost communication with
> slave\n");
> + return -EIO;
> + } else if (tag != FSI_RESP_ACK) {
> + dev_err(master->dev, "TERM failed; response %d\n", tag);
> + return -EIO;
> + }
> + return 0;
> +}
> +
> +static void dump_trace(struct fsi_master_acf *master)
> +{
> + char trbuf[52];
I was checking that this was big enough.
52 = 16 * 3 + '\n' + \0' = 50?
Looks to be okay.
> + char *p;
> + int i;
> +
> + dev_dbg(master->dev,
> + "CMDSTAT:%08x RTAG=%02x RCRC=%02x RDATA=%02x #INT=%08x\n",
> + be32_to_cpu(readl(master->sram + CMD_STAT_REG)),
> + readb(master->sram + STAT_RTAG),
> + readb(master->sram + STAT_RCRC),
> + be32_to_cpu(readl(master->sram + RSP_DATA)),
> + be32_to_cpu(readl(master->sram + INT_CNT)));
> +
> + for (i = 0; i < 512; i++) {
> + uint8_t v;
> + if ((i % 16) == 0)
> + p = trbuf;
> + v = readb(master->sram + TRACEBUF + i);
> + p += sprintf(p, "%02x ", v);
> + if (((i % 16) == 15) || v == TR_END)
> + dev_dbg(master->dev, "%s\n", trbuf);
> + if (v == TR_END)
> + break;
> + }
> +}
> +
> +static int handle_response(struct fsi_master_acf *master,
> + uint8_t slave, uint8_t size, void *data)
> +{
> + int busy_count = 0, rc;
> + int crc_err_retries = 0;
> + struct fsi_msg cmd;
> + __be32 response;
> + uint8_t tag;
> +retry:
> + rc = read_copro_response(master, size, &response, &tag);
> +
> + /* Handle retr
RE: [[LINUX PATCH v10] 4/4] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi Miquel, > -Original Message- > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > Sent: Wednesday, June 27, 2018 8:53 PM > To: Naga Sureshkumar Relli > Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org; > computersforpe...@gmail.com; marek.va...@gmail.com; f.faine...@gmail.com; > mma...@broadcom.com; rog...@ti.com; la...@linux-mips.org; a...@thorsis.com; > honghui.zh...@mediatek.com; linux-...@lists.infradead.org; > linux-kernel@vger.kernel.org; > nagasureshkumarre...@gmail.com; Michal Simek > Subject: Re: [[LINUX PATCH v10] 4/4] mtd: rawnand: pl353: Add basic driver > for arm > pl353 smc nand interface > > Hi Naga, > > This is not an issue at all but I think [PATCH vX Y/Z] is a preferred and > shorter suffix, you > can create it automatically by using > > git format-patch -v X ^.. --cover-letter Ok. > > > On Thu, 21 Jun 2018 12:12:31 +0530, Naga Sureshkumar Relli > wrote: > > > Add driver for arm pl353 static memory controller nand interface with > > HW ECC support. This controller is used in Xilinx Zynq SoC for > > interfacing the NAND flash memory. > > > > Signed-off-by: Naga Sureshkumar Relli > > > > --- > > Changes in 10: > > - Typos correction like nand to NAND and soc to SOC etc.. > > - Defined macros for the values in pl353_nand_calculate_hwecc() > > - Modifed ecc_status from int to char in pl353_nand_calculate_hwecc() > > - Changed the return type form int to bool to the function > >onehot() > > - Removed udelay(1000) in pl353_cmd_function, as it is not required > > - Dropped ecc->hwctl = NULL in pl353_ecc_init() > > - Added an error message in pl353_ecc_init(), when there is no matching > >oobsize > > - Changed the variable from xnand to xnfc > > - Added logic to get mtd->name from DT, if it is specified in DT > > Changes in v9: > > - Addressed the below comments given by Miquel > > - instead of using pl353_nand_write32, use directly writel_relaxed > > - Fixed check patch warnings > > - Renamed write_buf/read_buf to write_data_op/read_data_op > > - use BIT macro instead of 1 << nr > > - Use NAND_ROW_ADDR_3 flag > > - Use nand_wait_ready() > > - Removed swecc functions > > - Use address cycles as per size, instead of reading it from > > Parameter page > > - Instead of writing too many patterns, use optional property Changes > > in v8: > > - Added exec_op() implementation > > - Fixed the below v7 review comments > > - removed mtd_info from pl353_nand_info struct > > - Corrected ecc layout offsets > > - Added on-die ecc support > > Changes in v7: > > - Currently not implemented the memclk rate adjustments. I will > >look into this later and once the basic driver is accepted. > > - Fixed GPL licence ident > > Changes in v6: > > - Fixed the checkpatch.pl reported warnings > > - Using the address cycles information from the onfi param page > >earlier it is hardcoded to 5 in driver Changes in v5: > > - Configure the nand timing parameters as per the onfi spec Changes in v4: > > - Updated the driver to sync with pl353_smc driver APIs Changes in > > v3: > > - implemented the proper error codes > > - further breakdown this patch to multiple sets > > - added the controller and driver details to Documentation section > > - updated the licenece to GPLv2 > > - reorganized the pl353_nand_ecc_init function Changes in v2: > > - use "depends on" rather than "select" option in kconfig > > - remove unused variable parts > > --- > > drivers/mtd/nand/raw/Kconfig |7 + > > drivers/mtd/nand/raw/Makefile |1 + > > drivers/mtd/nand/raw/pl353_nand.c | 1309 > > + > > 3 files changed, 1317 insertions(+) > > create mode 100644 drivers/mtd/nand/raw/pl353_nand.c > > > > diff --git a/drivers/mtd/nand/raw/Kconfig > > b/drivers/mtd/nand/raw/Kconfig index 6871ff0..1c5d528 100644 > > --- a/drivers/mtd/nand/raw/Kconfig > > +++ b/drivers/mtd/nand/raw/Kconfig > > @@ -530,4 +530,11 @@ config MTD_NAND_MTK > > Enables support for NAND controller on MTK SoCs. > > This controller is found on mt27xx, mt81xx, mt65xx SoCs. > > > > +config MTD_NAND_PL353 > > + tristate "ARM Pl353 NAND flash driver" > > + depends on MTD_NAND && ARM > > + depends on PL353_SMC > > + help > > + Enables support for PrimeCell Static Memory Controller PL353. > > + > > endif # MTD_NAND > > diff --git a/drivers/mtd/nand/raw/Makefile > > b/drivers/mtd/nand/raw/Makefile index 165b7ef..1c702e1 100644 > > --- a/drivers/mtd/nand/raw/Makefile > > +++ b/drivers/mtd/nand/raw/Makefile > > @@ -56,6 +56,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_PL353) += pl353_nand.o > > > > nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o > > n
Re: [PATCH -mm -v4 00/21] mm, THP, swap: Swapout/swapin THP in one piece
On Fri, 22 Jun 2018 11:51:30 +0800 "Huang, Ying" wrote: > This is the final step of THP (Transparent Huge Page) swap > optimization. After the first and second step, the splitting huge > page is delayed from almost the first step of swapout to after swapout > has been finished. In this step, we avoid splitting THP for swapout > and swapout/swapin the THP in one piece. It's a tremendously good performance improvement. It's also a tremendously large patchset :( And it depends upon your mm-swap-fix-race-between-swapoff-and-some-swap-operations.patch and mm-fix-race-between-swapoff-and-mincore.patch, the first of which has been floating about since February without adequate review. I'll give this patchset a spin in -mm to see what happens and will come back later to take a closer look. But the best I can do at this time is to hopefully cc some possible reviewers :)
Re: [PATCH] proc: condemn myself to MAINTAINERS
On Wed, 27 Jun 2018 21:18:34 -0700 Joe Perches wrote: > On Wed, 2018-06-27 at 18:13 -0700, Andrew Morton wrote: > > On Wed, 27 Jun 2018 18:05:35 -0700 Joe Perches wrote: > > > > > On Wed, 2018-06-27 at 22:48 +0300, Alexey Dobriyan wrote: > > > > I know I'll regret it. > > > > > > This wasn't applied back in February? > > > > Well I thought it was, but I can't find such a patch anywhere. > > https://patchwork.kernel.org/patch/10196137/ Ah, OK. You asked a question so I took a pass, awaiting the reply which never came. > btw: > > Isn't your mail archive the seed file for the new lkml archive? > https://www.kernel.org/lore.html I believe so. > Maybe there are gaps there too? Not many. A few perhaps, where I fat-fingered things or where mail server glitches happened. But gaps will be few.
Re: [PATCH 2/4] ARM: dts: imx6qdl-zii-rdu2: Populate RAVE SP EEPROM nodes
On Wed, Jun 27, 2018 at 9:24 PM Andrey Smirnov wrote:
>
> ZII's RDU1s come with two EEPROMs attached to RAVE SP. Add
Ugh, the description should read RDU2, not RDU1. Will fix in v2,
tomorrow. Sorry about that.
Thanks,
Andrey Smirnov
> corresponding nodes to make them availible.
>
> Cc: Fabio Estevam
> Cc: Nikita Yushchenko
> Cc: Lucas Stach
> Cc: cphe...@gmail.com
> Cc: Shawn Guo
> Cc: Rob Herring
> Cc: Mark Rutland
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov
> ---
> arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> index 19a075aee19e..e4630481d951 100644
> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> @@ -320,10 +320,28 @@
> rave-sp {
> compatible = "zii,rave-sp-rdu2";
> current-speed = <100>;
> + #address-cells = <1>;
> + #size-cells = <1>;
>
> watchdog {
> compatible = "zii,rave-sp-watchdog";
> };
> +
> + eeprom@a3 {
> + compatible = "zii,rave-sp-eeprom";
> + reg = <0xa3 0x4000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + zii,eeprom-name = "dds-eeprom";
> + };
> +
> + eeprom@a4 {
> + compatible = "zii,rave-sp-eeprom";
> + reg = <0xa4 0x4000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + zii,eeprom-name = "main-eeprom";
> + };
> };
> };
>
> --
> 2.17.1
>
[PATCH 2/2] ARM: dts: imx51-babbage: Make use of pinctrl_usbh1reg
Pinctrl_usbh1reg defines pinmux setting for reset GPIO used by
usbh1phy, but is not referenced by that node. Fix that.
Cc: Fabio Estevam
Cc: Shawn Guo
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
arch/arm/boot/dts/imx51-babbage.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts
b/arch/arm/boot/dts/imx51-babbage.dts
index 541c6e67ad1a..19d3f0127f91 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -177,6 +177,8 @@
usbh1phy: usbh1phy@1 {
compatible = "usb-nop-xceiv";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1reg>;
reg = <1>;
clocks = <&clk_usb>;
clock-names = "main_clk";
--
2.17.1
[PATCH 1/2] ARM: dts: imx51-babbage: Fix reg for usbh1phy
There's already a USB PHY with reg of zero on that bus - usbphy0, used
by usbotg (included from imx51.dtsi). Move usbh1phy to @1 avoid
address collision.
Cc: Fabio Estevam
Cc: Shawn Guo
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
arch/arm/boot/dts/imx51-babbage.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts
b/arch/arm/boot/dts/imx51-babbage.dts
index b8ca73d3d379..541c6e67ad1a 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -175,9 +175,9 @@
#size-cells = <0>;
compatible = "simple-bus";
- usbh1phy: usbh1phy@0 {
+ usbh1phy: usbh1phy@1 {
compatible = "usb-nop-xceiv";
- reg = <0>;
+ reg = <1>;
clocks = <&clk_usb>;
clock-names = "main_clk";
reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
--
2.17.1
Re: [PATCH v10 00/14] Krait clocks + Krait CPUfreq
Hi Thierry, On 6/27/2018 3:01 PM, Thierry Escande wrote: > Hi Sricharan, > > On 19/06/2018 15:45, Sricharan R wrote: >> Sricharan R (2): >> clk: qcom: Add safe switch hook for krait mux clocks >> dt-bindings: cpufreq: Document operating-points-v2-krait-cpu >> >> Stephen Boyd (12): >> ARM: Add Krait L2 register accessor functions >> clk: qcom: Add support for High-Frequency PLLs (HFPLLs) >> clk: qcom: Add HFPLL driver >> dt-bindings: clock: Document qcom,hfpll >> clk: qcom: Add MSM8960/APQ8064's HFPLLs >> clk: qcom: Add IPQ806X's HFPLLs >> clk: qcom: Add support for Krait clocks >> clk: qcom: Add KPSS ACC/GCC driver >> dt-bindings: arm: Document qcom,kpss-gcc >> clk: qcom: Add Krait clock controller driver >> dt-bindings: clock: Document qcom,krait-cc >> cpufreq: Add module to register cpufreq on Krait CPUs > > Tested on apq8064 (db600c). > > Tested-By: Thierry Escande > Thanks for testing this !! I Will try to merge the kryo cpu-freq and this one if that looks neat. Regards, Sricharan -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/4] ARM: dts: imx51-zii-rdu1: Populate RAVE SP EEPROM nodes
ZII's RDU1s come with up to 3 EEPROMs attached to RAVE SP. Add
corresponding nodes to make them availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 29
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index ad2445dfa91d..c6da263cf210 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -578,6 +578,8 @@
rave-sp {
compatible = "zii,rave-sp-rdu1";
current-speed = <38400>;
+ #address-cells = <1>;
+ #size-cells = <1>;
watchdog {
compatible = "zii,rave-sp-watchdog";
@@ -590,6 +592,33 @@
pwrbutton {
compatible = "zii,rave-sp-pwrbutton";
};
+
+ eeprom@a3 {
+ compatible = "zii,rave-sp-eeprom";
+ reg = <0xa3 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ zii,eeprom-name = "dds-eeprom";
+ };
+
+ eeprom@a4 {
+ compatible = "zii,rave-sp-eeprom";
+ reg = <0xa4 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ zii,eeprom-name = "main-eeprom";
+ };
+
+ eeprom@ae {
+ compatible = "zii,rave-sp-eeprom";
+ reg = <0xae 0x200>;
+ zii,eeprom-name = "switch-eeprom";
+ /*
+* Not all RDU1s have this functionality, so we
+* rely on the bootloader to enable this
+*/
+ status = "disabled";
+ };
};
};
--
2.17.1
[PATCH 3/4] ARM: dts: imx6qdl-zii-rdu2: Populate RAVE SP backlight node
RAVE SP found on RDU2 implements backlight control compatible with the
rave-sp-backlight driver. Add a node to make it availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index e4630481d951..48da4b15da09 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -327,6 +327,10 @@
compatible = "zii,rave-sp-watchdog";
};
+ backlight {
+ compatible = "zii,rave-sp-backlight";
+ };
+
eeprom@a3 {
compatible = "zii,rave-sp-eeprom";
reg = <0xa3 0x4000>;
--
2.17.1
[PATCH 4/4] ARM: dts: imx6qdl-zii-rdu2: Populate RAVE SP power button node
RAVE SP found on RDU2 implements power button control compatible with
the rave-sp-pwrbutton driver. Add a node to make it availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 48da4b15da09..869dfd8431a1 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -331,6 +331,10 @@
compatible = "zii,rave-sp-backlight";
};
+ pwrbutton {
+ compatible = "zii,rave-sp-pwrbutton";
+ };
+
eeprom@a3 {
compatible = "zii,rave-sp-eeprom";
reg = <0xa3 0x4000>;
--
2.17.1
[PATCH 2/4] ARM: dts: imx6qdl-zii-rdu2: Populate RAVE SP EEPROM nodes
ZII's RDU1s come with two EEPROMs attached to RAVE SP. Add
corresponding nodes to make them availible.
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 19a075aee19e..e4630481d951 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -320,10 +320,28 @@
rave-sp {
compatible = "zii,rave-sp-rdu2";
current-speed = <100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
watchdog {
compatible = "zii,rave-sp-watchdog";
};
+
+ eeprom@a3 {
+ compatible = "zii,rave-sp-eeprom";
+ reg = <0xa3 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ zii,eeprom-name = "dds-eeprom";
+ };
+
+ eeprom@a4 {
+ compatible = "zii,rave-sp-eeprom";
+ reg = <0xa4 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ zii,eeprom-name = "main-eeprom";
+ };
};
};
--
2.17.1
[PATCH 0/4] RDU1/2 latest supported RAVE SP nodes
Shawn: These are patches adding the rest of RAVE SP child nodes covering all the rest of currently supported MFD cells. There's more to be added, once more drivers get accepted upstream. The bindings three drivers mentioned are availible in: Documentation/devicetree/bindings/nvmem/zii,rave-sp-eeprom.txt Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt Feedback is welcome! Thanks, Andrey Smirnov Andrey Smirnov (4): ARM: dts: imx51-zii-rdu1: Populate RAVE SP EEPROM nodes ARM: dts: imx6qdl-zii-rdu2: Populate RAVE SP EEPROM nodes ARM: dts: imx6qdl-zii-rdu2: Populate RAVE SP backlight node ARM: dts: imx6qdl-zii-rdu2: Populate RAVE SP power button node arch/arm/boot/dts/imx51-zii-rdu1.dts| 29 + arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 26 ++ 2 files changed, 55 insertions(+) -- 2.17.1
Re: [PATCH] proc: condemn myself to MAINTAINERS
On Wed, 2018-06-27 at 18:13 -0700, Andrew Morton wrote: > On Wed, 27 Jun 2018 18:05:35 -0700 Joe Perches wrote: > > > On Wed, 2018-06-27 at 22:48 +0300, Alexey Dobriyan wrote: > > > I know I'll regret it. > > > > This wasn't applied back in February? > > Well I thought it was, but I can't find such a patch anywhere. https://patchwork.kernel.org/patch/10196137/ btw: Isn't your mail archive the seed file for the new lkml archive? https://www.kernel.org/lore.html Maybe there are gaps there too?
Re: [PATCH RESEND 0/3] K2G: mmc: Update mmc dt node to use
Santosh, On Friday 22 June 2018 03:46 PM, Kishon Vijay Abraham I wrote: > Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc > binding. > > I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP. > Everyone who use a custom .config should also enable > CONFIG_MMC_SDHCI_OMAP for MMC to work. Can this series be merged? Thanks Kishon
Re: [PATCH 14/14] arm: dts: OpenPower Palmetto system can use coprocessor for FSI
On 27 June 2018 at 08:56, Benjamin Herrenschmidt wrote: > This switches away from userspace bitbanging to kernel FSI > using the coprocessor. > > Signed-off-by: Benjamin Herrenschmidt As with the other patch, I will take this through the ASPEED SoC tree once we've got acks on the bindings. Cheers, Joel
Re: [PATCH 13/14] arm: dts: OpenPower Romulus system can use coprocessor for FSI
On 27 June 2018 at 08:56, Benjamin Herrenschmidt
wrote:
> Signed-off-by: Benjamin Herrenschmidt
I will take this through the ASPEED SoC tree once we've got acks on
the bindings.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index 347938673c83..070b8f8f1d62 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -37,6 +37,11 @@
> compatible = "shared-dma-pool";
> reusable;
> };
> +
> + coldfire_memory: codefire_memory@9ef0 {
> + reg = <0x9ef0 0x0010>;
> + no-map;
> + };
> };
>
> leds {
> @@ -56,10 +61,16 @@
> };
>
> fsi: gpio-fsi {
> - compatible = "fsi-master-gpio", "fsi-master";
> + compatible = "ibm,fsi-master-ast2500-cf", "fsi-master";
> #address-cells = <2>;
> #size-cells = <0>;
> - no-gpio-delays;
> +
> + memory-region = <&coldfire_memory>;
> + sram = <&sram>;
> + cvic = <&cvic>;
> +
> + fw-name = "romulus";
> + fw-platform-sig = <0x526d>;
>
> clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> data-gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
> --
> 2.17.1
>
Re: [PATCH 09/14] fsi: master-gpio: Add missing release function
On 27 June 2018 at 08:56, Benjamin Herrenschmidt wrote: > The embedded struct device needs a release function to be > able to successfully remove the driver. > > We remove the devm_gpiod_put() as they are unnecessary > (the resources will be released automatically) and because > fsi_master_unregister() will cause the master structure to > be freed. > > Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley
Re: [PATCH 11/14] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"
On 27 June 2018 at 08:56, Benjamin Herrenschmidt wrote: > This isn't per-se a real device, it's a pseudo-device that > represents the use of the Aspeed built-in ColdFire to > implement the FSI protocol by bitbanging the GPIOs instead > of doing it from the ARM core. > > Thus it's a drop-in replacement for the existing > fsi-master-gpio pseudo-device for use on systems for which > a corresponding firmware file exists. It has most of the > same properties, plus some more needed to operate the > coprocessor. > > Signed-off-by: Benjamin Herrenschmidt Acked-by: Joel Stanley
Re: [PATCH 07/14] fsi: master-gpio: Remove unused definitions
On 27 June 2018 at 08:55, Benjamin Herrenschmidt wrote: > Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley
Re: [PATCH 08/14] fsi: master-gpio: Remove "GPIO" prefix on some definitions
On 27 June 2018 at 08:55, Benjamin Herrenschmidt wrote: > Some definitions are generic to the FSI protocol or any > give master implementation. Rename them to remove the > "GPIO" prefix in preparation for moving them to a common > header. > > Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley
Re: [PATCH 10/14] fsi: Move various master definitions to a common header
On 27 June 2018 at 08:56, Benjamin Herrenschmidt wrote: > This moves the definitions for various protocol details > (message & response codes, delays etc...) out of > fsi-master-gpio.c to fsi-master.h in order to share them > with other master implementations. > > Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley
Re: [PATCH 06/14] fsi: master-gpio: Add more tracepoints
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> This adds a few more tracepoints that have proven useful when
> debugging issues with the FSI bus.
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
> ---
> drivers/fsi/fsi-master-gpio.c | 16 ---
> include/trace/events/fsi_master_gpio.h | 59 ++
> 2 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c
> index 48e0e65b2982..a00a85aa6d56 100644
> --- a/drivers/fsi/fsi-master-gpio.c
> +++ b/drivers/fsi/fsi-master-gpio.c
> @@ -130,10 +130,17 @@ static void set_sda_output(struct fsi_master_gpio
> *master, int value)
>
> static void clock_zeros(struct fsi_master_gpio *master, int count)
> {
> + trace_fsi_master_gpio_clock_zeros(master, count);
> set_sda_output(master, 1);
> clock_toggle(master, count);
> }
>
> +static void echo_delay(struct fsi_master_gpio *master)
> +{
> + clock_zeros(master, master->t_echo_delay);
> +}
This doesn't look like it belongs in this patch.
You've just moved it up. Not worth a re-spin.
> +
> +
> static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg
> *msg,
> uint8_t num_bits)
> {
> @@ -279,16 +286,19 @@ static void build_ar_command(struct fsi_master_gpio
> *master,
> addr_bits = 2;
> opcode_bits = 2;
> opcode = FSI_GPIO_CMD_SAME_AR;
> + trace_fsi_master_gpio_cmd_same_addr(master);
>
> } else if (check_relative_address(master, id, addr, &rel_addr)) {
> /* 8 bits plus sign */
> addr_bits = 9;
> addr = rel_addr;
> opcode = FSI_GPIO_CMD_REL_AR;
> + trace_fsi_master_gpio_cmd_rel_addr(master, rel_addr);
>
> } else {
> addr_bits = 21;
> opcode = FSI_GPIO_CMD_ABS_AR;
> + trace_fsi_master_gpio_cmd_abs_addr(master, addr);
> }
>
> /*
> @@ -337,12 +347,6 @@ static void build_epoll_command(struct fsi_gpio_msg
> *cmd, uint8_t slave_id)
> msg_push_crc(cmd);
> }
>
> -static void echo_delay(struct fsi_master_gpio *master)
> -{
> - set_sda_output(master, 1);
> - clock_toggle(master, master->t_echo_delay);
> -}
> -
> static void build_term_command(struct fsi_gpio_msg *cmd, uint8_t slave_id)
> {
> cmd->bits = 0;
Re: [PATCH 02/14] fsi: Move code around to avoid forward declaration
On 27 June 2018 at 08:53, Benjamin Herrenschmidt wrote: > Move fsi_slave_set_smode() and its helpers to before it's > first user and remove the corresponding forward declaration. > > Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley
Re: [PATCH 05/14] fsi: master-gpio: Add support for link_config
On 27 June 2018 at 08:55, Benjamin Herrenschmidt wrote: > To configure the send and echo delays > > Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley
Re: [PATCH 03/14] fsi: Add mechanism to set the tSendDelay and tEchoDelay values
On 27 June 2018 at 08:55, Benjamin Herrenschmidt
wrote:
> Those values control the amount of "dummy" clocks between commands and
> between a command and its response.
>
> This adds a way to configure them from sysfs (to be later extended to
> defaults in the device-tree). The default remains 16 (the HW default).
We should add these to Documentation/ABI/testing/sysfs-bus-fsi.
> This is only supported if the backend supports the new link_config()
> callback to configure the generation of those delays.
>
> Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Joel Stanley
> ---
> ---
> drivers/fsi/fsi-core.c | 109 ---
> drivers/fsi/fsi-master.h | 2 +
> 2 files changed, 93 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index 2f6f9b8c75e4..1ae5be31b4bf 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -81,6 +81,8 @@ struct fsi_slave {
> int id;
> int link;
> uint32_tsize; /* size of slave address space */
> + u8 t_send_delay;
> + u8 t_echo_delay;
> };
>
> #define to_fsi_master(d) container_of(d, struct fsi_master, dev)
> @@ -239,15 +241,15 @@ static inline uint32_t fsi_smode_sid(int x)
> return (x & FSI_SMODE_SID_MASK) << FSI_SMODE_SID_SHIFT;
> }
>
> -static uint32_t fsi_slave_smode(int id)
> +static uint32_t fsi_slave_smode(int id, u8 t_senddly, u8 t_echodly)
Can I buy you a vowel? :)
> {
> return FSI_SMODE_WSC | FSI_SMODE_ECRC
> | fsi_smode_sid(id)
> - | fsi_smode_echodly(0xf) | fsi_smode_senddly(0xf)
> + | fsi_smode_echodly(t_echodly - 1) |
> fsi_smode_senddly(t_senddly - 1)
> | fsi_smode_lbcrr(0x8);
> }
>
Re: [PATCH 04/14] fsi: master-gpio: Rename and adjust send delay
On 27 June 2018 at 08:53, Benjamin Herrenschmidt wrote: > What the driver called "FSI_GPIO_PRIME_SLAVE_CLOCKS" is what > the FSI spec calls tSendDelay and should be 16 clocks by > default. > > Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley
RE: [PATCH 4.4 00/24] 4.4.138-stable review
> -Original Message- > From: stable-ow...@vger.kernel.org On Behalf > Of Ben Hutchings [..] > 3.18 and 4.4 are still missing this important fix to early parameter > parsing: > > commit 02afeaae9843733a39cd9b11053748b2d1dc5ae7 > Author: Dave Hansen > Date: Tue Dec 22 14:52:38 2015 -0800 > > x86/boot: Fix early command-line parsing when matching at end I have cherry-picked that commit into both 3.18.y and 4.4.y (it applies cleanly) and tested them on my machine. Both worked correctly. Test method: - Added printks to the functions that detect noxsave, noxsaves and noxsaveopt - Booted both kernels with and without the commit, and adding the kernel parameter "noxsave" - Checked that "noxsaves" and "noxsaveopt" do not appear on dmesg anymore after the commit. Thanks, Daniel
xfs: Deadlock between fs_reclaim and sb_internal
Hello Darrick,
Lockdep is reporting a deadlock with following trace. Saw this on my
powerpc vm with 4GB of ram, running Linus/master kernel. Though, I
don't have exact testcase to reproduce it. Is this something known?
[ 1797.620389] ==
[ 1797.620541] WARNING: possible circular locking dependency detected
[ 1797.620695] 4.18.0-rc2+ #2 Not tainted
[ 1797.620791] --
[ 1797.620942] kswapd0/362 is trying to acquire lock:
[ 1797.621067] 01ad2774 (sb_internal){.+.+}, at:
xfs_trans_alloc+0x284/0x360 [xfs]
[ 1797.621616]
[ 1797.621616] but task is already holding lock:
[ 1797.621779] bb0609ea (fs_reclaim){+.+.}, at:
__fs_reclaim_acquire+0x10/0x60
[ 1797.622090]
[ 1797.622090] which lock already depends on the new lock.
[ 1797.622090]
[ 1797.622266]
[ 1797.622266] the existing dependency chain (in reverse order) is:
[ 1797.622440]
[ 1797.622440] -> #1 (fs_reclaim){+.+.}:
[ 1797.622609]fs_reclaim_acquire.part.22+0x44/0x60
[ 1797.622764]kmem_cache_alloc+0x60/0x500
[ 1797.622983]kmem_zone_alloc+0xb4/0x168 [xfs]
[ 1797.623220]xfs_trans_alloc+0xac/0x360 [xfs]
[ 1797.623454]xfs_vn_update_time+0x278/0x420 [xfs]
[ 1797.623576]touch_atime+0xfc/0x120
[ 1797.623668]generic_file_read_iter+0x95c/0xbd0
[ 1797.623948]xfs_file_buffered_aio_read+0x98/0x2e0 [xfs]
[ 1797.624190]xfs_file_read_iter+0xac/0x170 [xfs]
[ 1797.624304]__vfs_read+0x128/0x1d0
[ 1797.624388]vfs_read+0xbc/0x1b0
[ 1797.624476]kernel_read+0x60/0xa0
[ 1797.624562]prepare_binprm+0xf8/0x1f0
[ 1797.624676]__do_execve_file.isra.13+0x7ac/0xc80
[ 1797.624791]sys_execve+0x58/0x70
[ 1797.624880]system_call+0x5c/0x70
[ 1797.624965]
[ 1797.624965] -> #0 (sb_internal){.+.+}:
[ 1797.625119]lock_acquire+0xec/0x310
[ 1797.625204]__sb_start_write+0x18c/0x290
[ 1797.625435]xfs_trans_alloc+0x284/0x360 [xfs]
[ 1797.625692]xfs_iomap_write_allocate+0x230/0x470 [xfs]
[ 1797.625945]xfs_map_blocks+0x1a8/0x610 [xfs]
[ 1797.626181]xfs_do_writepage+0x1a8/0x9e0 [xfs]
[ 1797.626414]xfs_vm_writepage+0x4c/0x78 [xfs]
[ 1797.626527]pageout.isra.17+0x180/0x680
[ 1797.626640]shrink_page_list+0xe0c/0x1470
[ 1797.626758]shrink_inactive_list+0x3a4/0x890
[ 1797.626872]shrink_node_memcg+0x268/0x790
[ 1797.626986]shrink_node+0x124/0x630
[ 1797.627089]balance_pgdat+0x1f0/0x550
[ 1797.627204]kswapd+0x214/0x8c0
[ 1797.627301]kthread+0x1b8/0x1c0
[ 1797.627389]ret_from_kernel_thread+0x5c/0x88
[ 1797.627509]
[ 1797.627509] other info that might help us debug this:
[ 1797.627509]
[ 1797.627684] Possible unsafe locking scenario:
[ 1797.627684]
[ 1797.627820]CPU0CPU1
[ 1797.627965]
[ 1797.628072] lock(fs_reclaim);
[ 1797.628166]lock(sb_internal);
[ 1797.628308]lock(fs_reclaim);
[ 1797.628453] lock(sb_internal);
[ 1797.628551]
[ 1797.628551] *** DEADLOCK ***
[ 1797.628551]
[ 1797.628693] 1 lock held by kswapd0/362:
[ 1797.628779] #0: bb0609ea (fs_reclaim){+.+.}, at:
__fs_reclaim_acquire+0x10/0x60
[ 1797.628955]
[ 1797.628955] stack backtrace:
[ 1797.629067] CPU: 18 PID: 362 Comm: kswapd0 Not tainted 4.18.0-rc2+ #2
[ 1797.629199] Call Trace:
[ 1797.629311] [c000f4ebaff0] [c0cc4414] dump_stack+0xe8/0x164
(unreliable)
[ 1797.629473] [c000f4ebb040] [c01a9f54]
print_circular_bug.isra.17+0x284/0x3d0
[ 1797.629639] [c000f4ebb0e0] [c01aed58]
__lock_acquire+0x1d48/0x2020
[ 1797.629797] [c000f4ebb260] [c01af7cc] lock_acquire+0xec/0x310
[ 1797.629933] [c000f4ebb330] [c0454c5c]
__sb_start_write+0x18c/0x290
[ 1797.630191] [c000f4ebb380] [d9b7896c]
xfs_trans_alloc+0x284/0x360 [xfs]
[ 1797.630443] [c000f4ebb3e0] [d9b58958]
xfs_iomap_write_allocate+0x230/0x470 [xfs]
[ 1797.630710] [c000f4ebb560] [d9b2c760] xfs_map_blocks+0x1a8/0x610
[xfs]
[ 1797.630961] [c000f4ebb5d0] [d9b2eb20]
xfs_do_writepage+0x1a8/0x9e0 [xfs]
[ 1797.631223] [c000f4ebb6b0] [d9b2f3a4] xfs_vm_writepage+0x4c/0x78
[xfs]
[ 1797.631384] [c000f4ebb720] [c03692e0] pageout.isra.17+0x180/0x680
[ 1797.631557] [c000f4ebb800] [c036ccfc]
shrink_page_list+0xe0c/0x1470
[ 1797.631730] [c000f4ebb920] [c036e064]
shrink_inactive_list+0x3a4/0x890
[ 1797.631912] [c000f4ebb9f0] [c036ef48]
shrink_node_memcg+0x268/0x790
[ 1797.632078] [c000f4ebbb00] [c036f594] shrink_node+0x124/0x630
[ 1797.632213] [c000f4ebbbd0] [c03714e0] balance_pgdat+0x1f0/0x550
[ 1797.632350] [c000f4ebbcd0] [c0371a54] kswapd+0x214/0x8c0
[ 1797.632488] [c000f4ebbdc0] [c00
Re: [PATCH v7 1/4] phy: Update PHY power control sequence
On 6/19/2018 2:06 PM, Can Guo wrote: > All PHYs should be powered on before register configuration starts. And > only PCIe PHYs need an extra power control before deasserts reset state. > > Signed-off-by: Can Guo > --- > drivers/phy/qualcomm/phy-qcom-qmp.c | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) Reviewed-by: Manu Gautam -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: moving affs + RDB partition support to staging?
Michael, as long as m68k only supports int fseek( int ) 4 GB * block size is
your HARD limit. Versions that support __int64 fseek64( __int64 ) can work with
larger disks. RDBs could include RDSK and a new set of other blocks that replace
the last two characters with "64" and use __int64 where needed in the various
values. That way a clever disk partitioner could give allow normal (32 bit) RDB
definitions where possible. Then at least SOME of the disk could be supported
AND a very clever filesystem that abstracts very large disks properly could give
access to the whole disk. (Read the RDBs first 32 bits. Then if a filesystem or
driveinit was loaded re-read the RDBs to see if new 64 bit partitions are revealed.
I could be wrong but I do not think RDBs could be safely modified any other way
to work. And, trust me as I bet this is still true, you will need a SERIOUSLY
good bomb shelter on the Moon if you change RDBs. Suppose Joe Amigoid uses it,
and then Joe Amigoid loads Amigados 2.4 because he wants to run a game that
crashes on anything newer. Then Joe got far enough something writes to the disk
and data is corrupted. Note further that Amigoids do NOT, repeat NOT, listen to
facts in such cases. Hell, some of them never listened to facts about an
incident at Jerry Pournelle's place when a 1.1 DPaint session with Kelly Freas
hung and we lost a delightful drawing. Jerry reported it. Amigoids screamed. I
tried to tell them I was there, it was my machine, and 1.1 was, indeed, crap.
{o.o}
On 20180627 02:00, Michael Schmitz wrote:
Joanne,
I'm not at all allergic to avoiding RDB at all cost for new disks. If AmigaOS
4.1 supports more recent partition formats, all the better. This is all about
supporting use of legacy RDB disks on Linux (though 2 TB does stretch the
definition of 'legacy' a little). My interest in this is to ensure we can
continue to use RDB format disks on m68k Amiga computers which have no other way
to boot Linux from disk.
Not proposing to change the RDB format at all, either. Just trying to make sure
we translate RDB info into Linux 512-byte block offset and size numbers
correctly. The kernel won't modify the RDB at all (intentionally, that is - with
the correct choice of partition sizes, Martin might well have wiped out his RDB
with the current version of the parser).
The choice of refusing to mount a disk (or mounting read-only) rests with the
VFS drivers alone - AFFS in that case. Not touching any of that. At partition
scan time, we only have the option of making the partition available (with a
warning printed), or refusing to make it available to the kernel. Once it's made
available, all bets are off.
From what Martin writes, his test case RDB was valid and worked as expected on
32 bit AmigaOS (4.1). Apparently, that version has the necessary extensions to
handle the large offsets resulting from 2 TB disks. Not sure what safeguards are
in place when connecting such a disk to older versions of AmigaOS, but that is a
different matter entirely.
The overflows in partition offset and size are the only ones I can see in the
partition parser - there is no other overflow I've identified. I just stated
that in order to place a partition towards the end of a 2 TB disk, the offset
calculation will overflow regardless of what combination of rdb->rdb_BlockBytes
and sector addresses stored in the RDB (in units of 512 byte blocks) we use:
blksize = be32_to_cpu( rdb->rdb_BlockBytes ) / 512;
nr_sects = (be32_to_cpu(pb->pb_Environment[10]) + 1 -
be32_to_cpu(pb->pb_Environment[9])) *
be32_to_cpu(pb->pb_Environment[3]) *
be32_to_cpu(pb->pb_Environment[5]) *
blksize;
if (!nr_sects)
continue;
start_sect = be32_to_cpu(pb->pb_Environment[9]) *
be32_to_cpu(pb->pb_Environment[3]) *
be32_to_cpu(pb->pb_Environment[5]) *
blksize;
But in the interest of avoiding any accidental use of a RDB partition where
calculations currently overflow, I'll make the default behaviour to bail out
(instead of using wrong offset or size as we currently do). Given the
'eat_my_RDB_disk=1' boot option, the user may proceed at their own risk (though
I still can't see what harm should result from now translating a well formed
v4.1 2 TB disk RDB correctly for the first time).
Whether or not Linux correctly handles AFFS filesystems larger than 1 TB is a
matter for VFS experts. Bailing out on nr_sects overflowing ought to prevent
accidental use of AFFS filesystems on RDB disks which I suppose is the majority
of use cases.
Bugs in partitioning tools on Linux are entirely out of scope - the partitioning
Re: [PATCH v7 2/4] phy: General struct and field cleanup
On 6/19/2018 2:06 PM, Can Guo wrote: > Move MSM8996 specific PHY vreg list struct name to a genernal one as it is > used by all PHYs. Add a specific field to handle dual lane situation. > > Signed-off-by: Can Guo > --- > drivers/phy/qualcomm/phy-qcom-qmp.c | 25 ++--- > 1 file changed, 14 insertions(+), 11 deletions(-) Reviewed-by: Manu Gautam -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v7 3/4] phy: Add QMP phy based UFS phy support for sdm845
Hi,
On 6/19/2018 2:06 PM, Can Guo wrote:
> +static int qcom_qmp_phy_poweron(struct phy *phy)
> +{
> + struct qmp_phy *qphy = phy_get_drvdata(phy);
> + struct qcom_qmp *qmp = qphy->qmp;
> + const struct qmp_phy_cfg *cfg = qmp->cfg;
> + void __iomem *pcs = qphy->pcs;
> + void __iomem *status;
> + unsigned int mask, val;
> + int ret = 0;
> +
> + if (cfg->type != PHY_TYPE_UFS)
> + return 0;
> +
> + /*
> + * For UFS PHY that has not software reset control, serdes start
> + * should only happen when UFS driver explicitly calls phy_power_on
> + * after it deasserts software reset.
> + */
Instead of relying on UFS glue driver to assert/de-assert PHY
which requires UFS PHY initialization to be split in init() and
poweron(), we can rather register reset_controller from ufs-qcom
driver.
PHY driver can then assert/de-assert as per UFS PHY requirement
in init() function itself and there won't be any need to have
poweron() routine for UFS as init can perform complete PHY
initialization without any dependency on ufs-qcom glue driver.
-Manu
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] ARM: dts: imx6sll: declare src module to be compatible to imx51's src
On Wed, Jun 20, 2018 at 04:38:37PM +0800, Anson Huang wrote: > i.MX6SLL uses same SRC module as i.MX51, add "fsl,imx51-src" > compatible string to enable SRC driver to support setting > CPU resume address for cpu-idle and suspend/resume. > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH v5 4/4] mm/sparse: Optimize memmap allocation during sparse_init()
> Signed-off-by: Baoquan He
>
> Signed-off-by: Baoquan He
Please remove duplicated signed-off
> if (!usemap) {
> ms->section_mem_map = 0;
> + nr_consumed_maps++;
Currently, we do not set ms->section_mem_map to 0 when fail to
allocate usemap, only when fail to allocate mmap we set
section_mem_map to 0. I think this is an existing bug.
Reviewed-by: Pavel Tatashin
Re: [PATCH v5 3/4] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap
Honestly, I do not like this new agrument, but it will do for now. I
could not think of a better way without rewriting everything.
Reviewed-by: Pavel Tatashin
However, I will submit a series of patches to cleanup sparse.c and
completely remove large and confusing temporary buffers: map_map, and
usemap_map. In those patches, I will remove alloc_usemap_and_memmap().
On Tue, Jun 26, 2018 at 9:31 PM Baoquan He wrote:
>
> alloc_usemap_and_memmap() is passing in a "void *" that points to
> usemap_map or memmap_map. In next patch we will change both of the
> map allocation from taking 'NR_MEM_SECTIONS' as the length to taking
> 'nr_present_sections' as the length. After that, the passed in 'void*'
> needs to update as things get consumed. But, it knows only the
> quantity of objects consumed and not the type. This effectively
> tells it enough about the type to let it update the pointer as
> objects are consumed.
>
> Signed-off-by: Baoquan He
> ---
> mm/sparse.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 71ad53da2cd1..b2848cc6e32a 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -489,10 +489,12 @@ void __weak __meminit vmemmap_populate_print_last(void)
> /**
> * alloc_usemap_and_memmap - memory alloction for pageblock flags and
> vmemmap
> * @map: usemap_map for pageblock flags or mmap_map for vmemmap
> + * @unit_size: size of map unit
> */
> static void __init alloc_usemap_and_memmap(void (*alloc_func)
> (void *, unsigned long, unsigned long,
> - unsigned long, int), void *data)
> + unsigned long, int), void *data,
> + int data_unit_size)
> {
> unsigned long pnum;
> unsigned long map_count;
> @@ -569,7 +571,8 @@ void __init sparse_init(void)
> if (!usemap_map)
> panic("can not allocate usemap_map\n");
> alloc_usemap_and_memmap(sparse_early_usemaps_alloc_node,
> - (void *)usemap_map);
> + (void *)usemap_map,
> + sizeof(usemap_map[0]));
>
> #ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
> size2 = sizeof(struct page *) * NR_MEM_SECTIONS;
> @@ -577,7 +580,8 @@ void __init sparse_init(void)
> if (!map_map)
> panic("can not allocate map_map\n");
> alloc_usemap_and_memmap(sparse_early_mem_maps_alloc_node,
> - (void *)map_map);
> + (void *)map_map,
> + sizeof(map_map[0]));
> #endif
>
> for_each_present_section_nr(0, pnum) {
> --
> 2.13.6
>
Re: [PATCH 0/2] Avoid firmware warning in imx-sdma
On Fri, Jun 22, 2018 at 04:49:49PM +0200, Sebastian Reichel wrote: > Subject: Avoid firmware warning in imx-sdma > > Hi, > > I grabbed the first patch from patchwork from an 2017 patch series. As far as > I > could see, their usecase vanished due to switching to sync FW API (that > already > supports NOWARN). This series fixes a kernel warning in imx-sdma driver, which > works fine with ROM firmware (and already prints an info message about ROM > firmware being used due to missing firmware file). This has been tested on > arch/arm/boot/dts/imx53-ppd.dts. Please read these threads about the state of affairs with respect to data driven Vs functional API evolution on the firmware API [0] and my latests recommendation for what to do for the async firmware API [1]. Then, recently I've come to realize that perhaps the best thing actually is to *break* the cycle for the async API and make it more functional driven. For instance the call to not use the uevent should be made a separate call as only two drivers use it: o CONFIG_LEDS_LP55XX_COMMON o CONFIG_DELL_RBU Using a struct would make it data driven. A flags approach would make it more flexible and I although I think this is reasonable, if we wanted to match the sync API, we'd have one call per variation. It is therefore subjective whether or not to keep a flags based mechanism for the async API or not. If we at least use flags, we'd just break away from the sync approach. I'll let Kees and Greg pick and choose how they would prefer to see this broken down now as I am off on vacation today and won't be back until the middle of next month. [0] https://lkml.kernel.org/r/20180421173650.gw14...@wotan.suse.de [1] https://lkml.kernel.org/r/20180422202609.gx14...@wotan.suse.de Luis
Re: [PATCH v5 2/4] mm/sparsemem: Defer the ms->section_mem_map clearing
Once you remove the ms mentioned by Oscar:
Reviewed-by: Pavel Tatashin
On Wed, Jun 27, 2018 at 6:59 PM Baoquan He wrote:
>
> On 06/27/18 at 11:54am, Oscar Salvador wrote:
> > On Wed, Jun 27, 2018 at 09:31:14AM +0800, Baoquan He wrote:
> > > In sparse_init(), if CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y, system
> > > will allocate one continuous memory chunk for mem maps on one node and
> > > populate the relevant page tables to map memory section one by one. If
> > > fail to populate for a certain mem section, print warning and its
> > > ->section_mem_map will be cleared to cancel the marking of being present.
> > > Like this, the number of mem sections marked as present could become
> > > less during sparse_init() execution.
> > >
> > > Here just defer the ms->section_mem_map clearing if failed to populate
> > > its page tables until the last for_each_present_section_nr() loop. This
> > > is in preparation for later optimizing the mem map allocation.
> > >
> > > Signed-off-by: Baoquan He
> > > ---
> > > mm/sparse-vmemmap.c | 1 -
> > > mm/sparse.c | 12
> > > 2 files changed, 8 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> > > index bd0276d5f66b..640e68f8324b 100644
> > > --- a/mm/sparse-vmemmap.c
> > > +++ b/mm/sparse-vmemmap.c
> > > @@ -303,7 +303,6 @@ void __init sparse_mem_maps_populate_node(struct page
> > > **map_map,
> > > ms = __nr_to_section(pnum);
> > > pr_err("%s: sparsemem memory map backing failed some memory
> > > will not be available\n",
> > >__func__);
> > > - ms->section_mem_map = 0;
> >
> > Since we are deferring the clearing of section_mem_map, I guess we do not
> > need
> >
> > struct mem_section *ms;
> > ms = __nr_to_section(pnum);
> >
> > anymore, right?
>
> Right, good catch, thanks.
>
> I will post a new round to fix this.
>
> >
> > > }
> > >
> > > if (vmemmap_buf_start) {
> > > diff --git a/mm/sparse.c b/mm/sparse.c
> > > index 6314303130b0..71ad53da2cd1 100644
> > > --- a/mm/sparse.c
> > > +++ b/mm/sparse.c
> > > @@ -451,7 +451,6 @@ void __init sparse_mem_maps_populate_node(struct page
> > > **map_map,
> > > ms = __nr_to_section(pnum);
> > > pr_err("%s: sparsemem memory map backing failed some memory
> > > will not be available\n",
> > >__func__);
> > > - ms->section_mem_map = 0;
> >
> > The same goes here.
> >
> >
> >
> > --
> > Oscar Salvador
> > SUSE L3
>
Re: [PATCH v5 1/4] mm/sparse: Add a static variable nr_present_sections
Reviewed-by: Pavel Tatashin
On Tue, Jun 26, 2018 at 9:31 PM Baoquan He wrote:
>
> It's used to record how many memory sections are marked as present
> during system boot up, and will be used in the later patch.
>
> Signed-off-by: Baoquan He
> ---
> mm/sparse.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index f13f2723950a..6314303130b0 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -200,6 +200,12 @@ static inline int next_present_section_nr(int section_nr)
> (section_nr <= __highest_present_section_nr));\
> section_nr = next_present_section_nr(section_nr))
>
> +/*
> + * Record how many memory sections are marked as present
> + * during system bootup.
> + */
> +static int __initdata nr_present_sections;
> +
> /* Record a memory area against a node. */
> void __init memory_present(int nid, unsigned long start, unsigned long end)
> {
> @@ -229,6 +235,7 @@ void __init memory_present(int nid, unsigned long start,
> unsigned long end)
> ms->section_mem_map = sparse_encode_early_nid(nid) |
> SECTION_IS_ONLINE;
> section_mark_present(ms);
> + nr_present_sections++;
> }
> }
> }
> --
> 2.13.6
>
Re: [PATCH v4 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices
On Wed, 2018-06-27 at 20:04 +0300, Andy Shevchenko wrote:
> On Wed, Jun 27, 2018 at 7:59 PM, Andy Shevchenko
> wrote:
> > On Wed, Jun 27, 2018 at 8:43 AM, wrote:
> >> From: Sean Wang
> >>
> >
> >> +config BT_HCIBTUART_MTK
> >> + tristate "MediaTek HCI UART driver"
> >> + depends on BT_HCIBTUART
> >
> >> + default y
> >
> > Perhaps it's an overkill for users which would like to have less
> > amount on stuff in kernel.
> >
Sure, the default y will be removed
> >
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
>
> Perhaps alphabetically ordered?
>
They seem already in alphabetically ordered
> + blank line.
>
A blank line will be added here
> >
> >> +#include
> >> +#include
>
> >> + /* Enable the power domain and clock the device requires. */
> >> + pm_runtime_enable(dev);
> >> + err = pm_runtime_get_sync(dev);
> >> + if (err < 0)
> >> + goto err_pm2;
>
> Should be err_pm1 here.
Label err_pm1 and err_pm2 can be swapped for the readability and this
doesn't have any effect on the logic.
> Yes, that's correct.
>
> >> +err_pm1:
> >> + pm_runtime_put_sync(dev);
> >> +err_pm2:
> >> + pm_runtime_disable(dev);
>
> >> +#define MTK_WMT_CMD_SIZE (MTK_WMT_HDR_SIZE + MTK_STP_HDR_SIZE + \
> >> +MTK_STP_TLR_SIZE + HCI_ACL_HDR_SIZE)
>
> It would look slightly better if you start on new line like
> #define FOO \
> (BAR + BAZ)
>
Thanks for your pointing out. I also found that the macro is not being
used by anyone, it can be removed freely.
> >> +struct mtk_stp_hdr {
> >> + __u8 prefix;
> >> + __u8 dlen1:4;
> >> + __u8 type:4;
>
> >> + __u8 dlen2:8;
>
> u8 already 8 bit.
>
the superfluous :8 for dlen2 will be removed
> >> + __u8 cs;
> >> +} __packed;
>
Re: moving affs + RDB partition support to staging?
The issue is what happens when one of those disks appears on a 3.1 system.
{^_^}
On 20180627 01:03, Martin Steigerwald wrote:
Dear Joanne.
jdow - 27.06.18, 08:24:
You allergic to using a GPT solution? It will get away from some of
the evils that RDB has inherent in it because they are also features?
(Loading a filesystem or DriveInit code from RDBs is just asking for
a nearly impossible to remove malware infection.) Furthermore, any 32
bit system that sees an RDSK block is going to try to translate it.
If you add a new RDB format you are going to get bizarre and probably
quite destructive results from the mistake. Fail safe is a rather
good notion, methinks.
Personally I figure this is all rather surreal. 2TG of junk on an
Amiga system seems utterly outlandish to me. You cited another
overflow potential. There are at least three we've identified, I
believe. Are you 100% sure there are no more? The specific one you
mention of translating RDB to Linux has a proper solution in the RDB
reader. It should recover such overflow errors in the RDB as it can
with due care and polish. It should flag any other overflow error it
detects within the RDBs and return an error such as to leave the disk
unmounted or mounted read-only if you feel like messing up a poor
sod's backups. The simple solution is to read each of the variables
with the nominal RDB size and convert it to uint64_t before
calculating byte indices.
However, consider my inputs as advice from an adult who has seen the
Amiga Elephant so to speak. I am not trying to assert any control. Do
as you wish; but, I would plead with you to avoid ANY chance you can
for the user to make a bonehead stupid move and lose all his
treasured disk archives. Doing otherwise is very poor form.
I am pretty confident that larger than 2 TiB disks are fully supported
within AmigaOS 4, as I outlined in my other mail.
So with all due respect: I used a larger than 2 TiB disk in AmigaOS 4 in
2012 already *just* fine. I even found I had the same questions back
then, and researched it. Which lead to this official article back then:
http://wiki.amigaos.net/wiki/RDB
I am also pretty sure that AmigaOS still uses RDB as partitioning
format. They support MBR. I don´t think AmigaOS 4.1 supports GPT.
Whether to implement that of course is the decision of AmigaOS 4
development team. I am no longer a member of it since some time.
Linux m68k should already be able to use disks in GPT format, but you
likely won´t be able to read them in AmigaOS, unless there is some third
party support for it meanwhile.
Thanks,
Martin
{o.o} Joanne "Said enough, she has" Dow
On 20180626 18:07, Michael Schmitz wrote:
Joanne,
As far as I have been able to test, the change is backwards
compatible (RDB partitions from an old disk 80 GB disk are still
recognized OK). That"s only been done on an emulator though.
Your advice about the dangers of using RDB disks that would have
failed the current Linux RDB parser on legacy 32 bit systems is well
taken though. Maybe Martin can clarify that for me - was the 2 TB
disk in question ever used on a 32 bit Amiga system?
RDB disk format is meant for legacy use only, so I think we can get
away with printing a big fat warning during boot, advising the user
that the oversize RDB partition(s) scanned are not compatible with
legacy 32 bit AmigaOS. With the proposed fix they will work under
both AmigaOS 4.1 and Linux instead of truncating the first
overflowing partition at disk end and trashing valid partitions
that overlap, which is what Martin was after.
If that still seems too risky, we can make the default behaviour to
bail out once a potential overflow is detected, and allow the user
to
override that through a boot parameter. I'd leave that decision up
for the code review on linux-block.
Two more comments: Linux uses 512 byte block sizes for the partition
start and size calculations, so a change of the RDB blocksize to
reduce the block counts stored in the RDB would still result in the
same overflow. And amiga-fdisk is indeed utterly broken and needs
updating (along with probably most legacy m68k partitioners). Adrian
has advertised parted as replacement for the old tools - maybe this
would make a nice test case for parted?
Cheers,
Michael
On Tue, Jun 26, 2018 at 9:45 PM, jdow wrote:
If it is not backwards compatible I for one would refuse to use it.
And if it still mattered that much to me I'd also generate a
reasonable alternative. Modifying RDBs nay not be even an
approximation of a good idea. You'd discover that as soon as an
RDB uint64_t disk is tasted by a uint32_t only system. If it is
for your personal use then you're entirely free to reject my
advice and are probably smart enough to keep it working for
yourself.
GPT is probably the right way to go. Preserve the ability to read
RDBs for legacy disks only.
{^_^}
On 20180626 01:31, Michael Schmitz wrote:
Joanne,
I think we all agree tha
Re: moving affs + RDB partition support to staging?
FFS is limited to 2 GHz file size if you don't want any corruption using
fseek(). Otherwise it can go to 4 GHz sort of safely.
{^_^}
On 20180627 00:57, Martin Steigerwald wrote:
Michael Schmitz - 27.06.18, 03:07:
Joanne,
As far as I have been able to test, the change is backwards compatible
(RDB partitions from an old disk 80 GB disk are still recognized OK).
That"s only been done on an emulator though.
Your advice about the dangers of using RDB disks that would have
failed the current Linux RDB parser on legacy 32 bit systems is well
taken though. Maybe Martin can clarify that for me - was the 2 TB disk
in question ever used on a 32 bit Amiga system?
Sure! Are there actually *any* 64 bit Amiga systems? I am not completely
sure architecture-wise, but the operating system is still just 32-Bit.
However, on AmigaOS officially since at least 3.5/3.9 there are various
mechanisms to handle 64-bit block numbers for disk devices, called
NSD64, TD64 and scsi direct¹. One of them, NSD 64 in AmigaOS 3.5/3.9, is
part of the operating system. First via SetPatch based update to
Kickstart ROM, but with AmigaOS 4.x its just included.
[1] http://www.amigawiki.de/doku.php?id=de:system:filesystems_limits
(I do not agree with maximum filesystem size limits stated there for
Amiga Fast Filesystem (FFS), but well, for early FFS versions they could
have been true, I am pretty sure that at least with higher block sizes
you can have FFS > 2 GiB in size. And I remember having had JFXS and I
think also SFS2 partitions in AmigaOS 4 with more than 100 GiB.)
RDB disk format is meant for legacy use only, so I think we can get
away with printing a big fat warning during boot, advising the user
that the oversize RDB partition(s) scanned are not compatible with
legacy 32 bit AmigaOS. With the proposed fix they will work under both
AmigaOS 4.1 and Linux instead of truncating the first overflowing
partition at disk end and trashing valid partitions that overlap,
which is what Martin was after.
They are compatible. For AmigaOS 4.x I am completely sure, cause I
installed and used the disk there. That was the original motivation for
my Linux bug report back then: I used the disk in AmigaOS 4 *just fine*
and it broke in Linux. I used Media Toolbox in order to create the RDB I
posted back then.
Its difficult to find proof for my claims online, but here is an
official one:
http://wiki.amigaos.net/wiki/RDB
Limits of filesystem sizes may of course be different, but here we are
talking about RDB.
Also this confirms that RDB only uses 512 byte block size on AmigaOS 4.
Hmmm, I even created the page back then. Interestingly at about the same
time I made the bug report about the Linux issue. The calculations in
there are not really from me. I bet I copied them over from what other
AmigaOS developers wrote on development mailing lists, at that time.
With their agreement. I think I started my research back then due by my
own question on: Will such a large disk actually work in AmigaOS?
It is all a long time ago…
If that still seems too risky, we can make the default behaviour to
bail out once a potential overflow is detected, and allow the user to
override that through a boot parameter. I'd leave that decision up for
the code review on linux-block.
Two more comments: Linux uses 512 byte block sizes for the partition
start and size calculations, so a change of the RDB blocksize to
reduce the block counts stored in the RDB would still result in the
same overflow. And amiga-fdisk is indeed utterly broken and needs
updating (along with probably most legacy m68k partitioners). Adrian
has advertised parted as replacement for the old tools - maybe this
would make a nice test case for parted?
I always used AmigaOS based tools to partition in RDB format, cause I
never trusted amiga-fdisk :).
On Tue, Jun 26, 2018 at 9:45 PM, jdow wrote:
If it is not backwards compatible I for one would refuse to use it.
And if it still mattered that much to me I'd also generate a
reasonable alternative. Modifying RDBs nay not be even an
approximation of a good idea. You'd discover that as soon as an RDB
uint64_t disk is tasted by a uint32_t only system. If it is for
your personal use then you're entirely free to reject my advice and
are probably smart enough to keep it working for yourself.
GPT is probably the right way to go. Preserve the ability to read
RDBs for legacy disks only.
{^_^}
On 20180626 01:31, Michael Schmitz wrote:
Joanne,
I think we all agree that doing 32 bit calculations on 512-byte
block
addresses that overflow on disks 2 TB and larger is a bug, causing
the issues Martin reported. Your patch addresses that by using the
correct data type for the calculations (as do other partition
parsers that may have to deal with large disks) and fixes Martin's
bug, so appears to be the right thing to do.
Using 64 bit data types for disks smaller than 2 TB where
calculations don't currently overflow
Re: [PATCH v4 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices
On Wed, 2018-06-27 at 19:59 +0300, Andy Shevchenko wrote: > On Wed, Jun 27, 2018 at 8:43 AM, wrote: > > From: Sean Wang > > > > > +config BT_HCIBTUART_MTK > > + tristate "MediaTek HCI UART driver" > > + depends on BT_HCIBTUART > > > + default y > > Perhaps it's an overkill for users which would like to have less > amount on stuff in kernel. sure, the default y will be removed > > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > [ ... ] > > MODULE_DEVICE_TABLE(of, btuart_of_match_table); > > -- > > 2.7.4 > > > > >
Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks
On (06/20/18 12:38), Linus Torvalds wrote: > On Wed, Jun 20, 2018 at 11:50 AM Sergey Senozhatsky > wrote: > > > > It's not UART on its own that immediately calls into printk(), that would > > be trivial to fix, it's all those subsystems that serial console driver > > can call into. > > We already have the whole PRINTK_SAFE_CONTEXT_MASK model that only > adds it to a secondary buffer if you get recursion. Why isn't that > triggering? That's the whole point of it. Linus, Alan, Steven, are you on board with the patch set? What shall I do to improve it? PRINTK_SAFE_CONTEXT_MASK is what we answer nowadays when someone says "printk causes deadlocks". We really can't remove all printk-s that can cause uart->...->printk->uart recursion, and the only other option is to use spin_trylock on uart_port->lock in every driver and discard con->write() if we see that we have re-entered uart. I'd rather use per-CPU printk_safe buffer in this case. -ss
Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()
On 06/27/2018 10:02 AM, Jan Kara wrote: > On Wed 27-06-18 08:57:18, Jason Gunthorpe wrote: >> On Wed, Jun 27, 2018 at 02:42:55PM +0200, Jan Kara wrote: >>> On Wed 27-06-18 13:59:27, Michal Hocko wrote: On Wed 27-06-18 13:53:49, Jan Kara wrote: > On Wed 27-06-18 13:32:21, Michal Hocko wrote: [...] >> Appart from that, do we really care about 32b here? Big DIO, IB users >> seem to be 64b only AFAIU. > > IMO it is a bad habit to leave unpriviledged-user-triggerable oops in the > kernel even for uncommon platforms... Absolutely agreed! I didn't mean to keep the blow up for 32b. I just wanted to say that we can stay with a simple solution for 32b. I thought the g-u-p-longterm has plugged the most obvious breakage already. But maybe I just misunderstood. >>> >>> Most yes, but if you try hard enough, you can still trigger the oops e.g. >>> with appropriately set up direct IO when racing with writeback / reclaim. >> >> gup longterm is only different from normal gup if you have DAX and few >> people do, which really means it doesn't help at all.. AFAIK?? > > Right, what I wrote works only for DAX. For non-DAX situation g-u-p > longterm does not currently help at all. Sorry for confusion. > OK, I've got an early version of this up and running, reusing the page->lru fields. I'll clean it up and do some heavier testing, and post as a PATCH v2. One question though: I'm still vague on the best actions to take in the following functions: page_mkclean_one try_to_unmap_one At the moment, they are both just doing an evil little early-out: if (PageDmaPinned(page)) return false; ...but we talked about maybe waiting for the condition to clear, instead? Thoughts? And if so, does it sound reasonable to refactor wait_on_page_bit_common(), so that it learns how to wait for a bit that, while inside struct page, is not within page->flags? thanks, -- John Hubbard NVIDIA
Re: [PATCH v2 0/3] printk: Deadlock in NMI regression
On (06/27/18 16:08), Petr Mladek wrote: > > kernel/printk/printk.c | 57 +++- > kernel/printk/printk_safe.c | 58 > + Shall we just merge these two? -ss
[PATCH] hwspinlock: Fix incorrect return pointers
The commit 4f1acd758b08 ("hwspinlock: Add devm_xxx() APIs to request/free
hwlock") introduces one bug, that will return one error pointer if failed
to request one hwlock, but we expect NULL pointer on error for consumers.
This patch will fix this issue.
Reported-by: Dan Carpenter
Signed-off-by: Baolin Wang
---
drivers/hwspinlock/hwspinlock_core.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index e16d648..2bad40d 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -877,10 +877,10 @@ struct hwspinlock *devm_hwspin_lock_request(struct device
*dev)
ptr = devres_alloc(devm_hwspin_lock_release, sizeof(*ptr), GFP_KERNEL);
if (!ptr)
- return ERR_PTR(-ENOMEM);
+ return NULL;
hwlock = hwspin_lock_request();
- if (!IS_ERR(hwlock)) {
+ if (hwlock) {
*ptr = hwlock;
devres_add(dev, ptr);
} else {
@@ -913,10 +913,10 @@ struct hwspinlock
*devm_hwspin_lock_request_specific(struct device *dev,
ptr = devres_alloc(devm_hwspin_lock_release, sizeof(*ptr), GFP_KERNEL);
if (!ptr)
- return ERR_PTR(-ENOMEM);
+ return NULL;
hwlock = hwspin_lock_request_specific(id);
- if (!IS_ERR(hwlock)) {
+ if (hwlock) {
*ptr = hwlock;
devres_add(dev, ptr);
} else {
--
1.7.9.5
Re: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
On Thu, Jun 28, 2018 at 01:40:30AM +, Gaoming (ming, consumer BG) wrote: > Hi tytso, > > I have checked that make_ext4fs code was deleted o Jun 21th 2018 on master > branch of /system/extras repository. > e.g. > https://android-review.googlesource.com/c/platform/system/extras/+/708003 Make_ext4fs was fixed not create invalid file systems a *long* time ago. What I'm not sure about is why the patch hasn't gotten out to more Android manufacters sooner. It should have been fixed by sometime in 2012 --- I complained to the Android team in early 2011. What I don't understand is why people are coming out of the woodwork *now*. - Ted
Re: [PATCH v3 17/24] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > DW HDMI PHY driver and PHY clock driver share same registers. Make sure > that DW HDMI PHY setup code doesn't change any clock related bits. > During initialization, set PHY PLL parent bit to 0. > > Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai and maybe a fixes tag?
Re: [PATCH v2 3/3] printk/nmi: Prevent deadlock when accessing the main log buffer in NMI
On (06/27/18 16:20), Petr Mladek wrote:
> +/*
> + * Marks a code that might produce many messages in NMI context
> + * and the risk of losing them is more critical than eventual
> + * reordering.
> + *
> + * It has effect only when called in NMI context. Then printk()
> + * will try to store the messages into the main logbuf directly
> + * and use the per-CPU buffers only as a fallback when the lock
> + * is not available.
> + */
> +void printk_nmi_direct_enter(void)
> +{
> + if (this_cpu_read(printk_context) & PRINTK_NMI_CONTEXT_MASK)
> + this_cpu_or(printk_context, PRINTK_NMI_DIRECT_CONTEXT_MASK);
> +}
A side note: This nesting also handles recursive printk-s for us.
NMI:
printk_nmi_enter
ftrace_dump
printk_nmi_direct_enter
vprintk_func
spin_lock(logbuf_lock)
vprintk_store
vsprintf
WARN_ON
vprintk_func
vprintk_nmi
> __printf(1, 0) int vprintk_func(const char *fmt, va_list args)
> {
> + /*
> + * Try to use the main logbuf even in NMI. But avoid calling console
> + * drivers that might have their own locks.
> + */
> + if ((this_cpu_read(printk_context) & PRINTK_NMI_DIRECT_CONTEXT_MASK) &&
> + raw_spin_trylock(&logbuf_lock)) {
> + int len;
> +
> + len = vprintk_store(0, LOGLEVEL_DEFAULT, NULL, 0, fmt, args);
> + raw_spin_unlock(&logbuf_lock);
> + defer_console();
> + return len;
> + }
So, maybe, something a bit better than defer_console().
Otherwise,
Acked-by: Sergey Senozhatsky
-ss
Re: [PATCH] ARM: dts: imx6: RIoTboard Add chosen stdout-path property
On Mon, Jun 18, 2018 at 05:42:57PM +0200, Emmanuel Vadot wrote: > The RIoTboard debug uart is connected to serial1. > Add a chosen property in the DTS so OS knows what serial port to use for > the console. > > Signed-off-by: Emmanuel Vadot Applied, thanks.
Re: [PATCH v2 2/3] printk: Create helper function to queue deferred console handling
On (06/28/18 11:16), Sergey Senozhatsky wrote: > > You can just call vprintk_emit(LOGLEVEL_SCHED) from vprintk_func(), > then you don't need to factor out vprintk_deferred() and vprintk_emit(). > Any reason for that split? My bad, no you can't. I forgot that for direct_nmi vprintk_func() logbuf_lock is locked at the upper level - vprintk_func(). -ss
Re: [PATCH v2 2/3] printk: Create helper function to queue deferred console handling
On (06/27/18 16:08), Petr Mladek wrote:
> -int vprintk_deferred(const char *fmt, va_list args)
> +void defer_console(void)
> {
> - int r;
> -
> - r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args);
> -
> preempt_disable();
> __this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
> irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
> preempt_enable();
> +}
> +
> +int vprintk_deferred(const char *fmt, va_list args)
> +{
> + int r;
> +
> + r = vprintk_emit(0, LOGLEVEL_SCHED, NULL, 0, fmt, args);
> + defer_console();
>
> return r;
You can just call vprintk_emit(LOGLEVEL_SCHED) from vprintk_func(),
then you don't need to factor out vprintk_deferred() and vprintk_emit().
Any reason for that split?
I'd also may be prefer to have a bit different name. I'm talking
about defer_console().
Other than that
Acked-by: Sergey Senozhatsky
-ss
Re: [PATCH v10 2/2] Refactor part of the oom report in dump_header
On Sat, 23 Jun 2018 22:12:51 +0800 ufo19890...@gmail.com wrote: > From: yuzhoujian > > The current system wide oom report prints information about the victim > and the allocation context and restrictions. It, however, doesn't > provide any information about memory cgroup the victim belongs to. This > information can be interesting for container users because they can find > the victim's container much more easily. > > I follow the advices of David Rientjes and Michal Hocko, and refactor > part of the oom report. After this patch, users can get the memcg's > path from the oom report and check the certain container more quickly. > > The oom print info after this patch: > oom-kill:constraint=,nodemask=,oom_memcg=,task_memcg=,task=,pid=,uid= > > Signed-off-by: yuzhoujian > --- > Below is the part of the oom report in the dmesg > ... > [ 134.873392] panic invoked oom-killer: > gfp_mask=0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null), order=0, > oom_score_adj=0 > > ... > > [ 134.873480] > oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),task_memcg=/test/test1/test2,task=panic,pid= > 8669, uid=0 We're displaying nodemask twice there. Avoidable? Also, the spaces after pid= and uid= don't seem useful. Why not use plain old %d?
Re: [PATCH v2 1/3] printk: Split the code for storing a message into the log buffer
On (06/27/18 16:08), Petr Mladek wrote: [..] > if (dict) > lflags |= LOG_PREFIX|LOG_NEWLINE; > > - printed_len = log_output(facility, level, lflags, dict, dictlen, text, > text_len); > + return log_output(facility, level, lflags, > + dict, dictlen, text, text_len); > +} YAYY! Acked-by: Sergey Senozhatsky -ss
