* [PATCH] ARM: dts: imx6q-h100: use usdhc2 VSELECT
From: Fabio Estevam @ 2017-12-16 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215092624.12806-1-m.tretter@pengutronix.de>
Hi Michael,
On Fri, Dec 15, 2017 at 7:26 AM, Michael Tretter
<m.tretter@pengutronix.de> wrote:
> The uSDHC controller directly provides a VSELECT signal that can be
> muxed to the external voltage select. Mux the VSELECT directly to avoid
> using a GPIO.
>
> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Much simpler :-)
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 33/45] arch/arm: remove duplicate includes
From: Pravin Shedge @ 2017-12-16 11:43 UTC (permalink / raw)
To: linux-arm-kernel
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
---
arch/arm/crypto/aes-ce-glue.c | 1 -
arch/arm/mach-sa1100/hackkit.c | 1 -
arch/arm/mm/mmu.c | 2 --
arch/arm/xen/mm.c | 1 -
arch/arm64/kernel/armv8_deprecated.c | 1 -
arch/arm64/kernel/fpsimd.c | 1 -
6 files changed, 7 deletions(-)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index d0a9cec..5affb84 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -10,7 +10,6 @@
#include <asm/hwcap.h>
#include <asm/neon.h>
-#include <asm/hwcap.h>
#include <crypto/aes.h>
#include <crypto/internal/simd.h>
#include <crypto/internal/skcipher.h>
diff --git a/arch/arm/mach-sa1100/hackkit.c b/arch/arm/mach-sa1100/hackkit.c
index 643d5f2..0016d25 100644
--- a/arch/arm/mach-sa1100/hackkit.c
+++ b/arch/arm/mach-sa1100/hackkit.c
@@ -22,7 +22,6 @@
#include <linux/serial_core.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
-#include <linux/tty.h>
#include <linux/gpio.h>
#include <linux/leds.h>
#include <linux/platform_device.h>
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e46a6a4..56d265e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -23,7 +23,6 @@
#include <asm/sections.h>
#include <asm/cachetype.h>
#include <asm/fixmap.h>
-#include <asm/sections.h>
#include <asm/setup.h>
#include <asm/smp_plat.h>
#include <asm/tlb.h>
@@ -36,7 +35,6 @@
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <asm/mach/pci.h>
-#include <asm/fixmap.h>
#include "fault.h"
#include "mm.h"
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 785d2a5..8ba803b 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -8,7 +8,6 @@
#include <linux/of_address.h>
#include <linux/slab.h>
#include <linux/types.h>
-#include <linux/dma-mapping.h>
#include <linux/vmalloc.h>
#include <linux/swiotlb.h>
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index c33b5e4..6c25b8a 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -21,7 +21,6 @@
#include <asm/traps.h>
#include <asm/kprobes.h>
#include <linux/uaccess.h>
-#include <asm/cpufeature.h>
#define CREATE_TRACE_POINTS
#include "trace-events-emulation.h"
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 5084e69..2f822dc2 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -31,7 +31,6 @@
#include <linux/percpu.h>
#include <linux/prctl.h>
#include <linux/preempt.h>
-#include <linux/prctl.h>
#include <linux/ptrace.h>
#include <linux/sched/signal.h>
#include <linux/sched/task_stack.h>
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Rafael J. Wysocki @ 2017-12-16 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0iaYAodhiQm3=7OMhtqP3JXoX_RTrYMRDxVwO=3hTL7Bg@mail.gmail.com>
On Fri, Dec 15, 2017 at 3:29 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Fri, Dec 15, 2017 at 5:25 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Document the devicetree bindings that describe Texas Instruments
>> opp-supply which allow a platform to describe multiple regulators and
>> additional information, such as registers containing data needed to
>> program aforementioned regulators.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>
> I need an ACK from Rob on this one.
Actually, how this (and the next patch) is related to the [1-2/4]?
^ permalink raw reply
* [RFC 1/5] [media] rc: update sunxi-ir driver to get base frequency from devicetree
From: Mauro Carvalho Chehab @ 2017-12-16 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-2-embed3d@gmail.com>
Em Sat, 16 Dec 2017 03:49:10 +0100
Philipp Rossak <embed3d@gmail.com> escreveu:
Hi Phillip,
This is not a full review of this patchset. I just want to point you
that you should keep supporting existing DT files.
> This patch updates the sunxi-ir driver to set the ir base clock from
> devicetree.
>
> This is neccessary since there are different ir recievers on the
> market, that operate with different frequencys. So this value needs to
> be set depending on the attached receiver.
Please don't break backward compatibility with old DT files. In this
specific case, it seems simple enough to be backward-compatible.
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
> ---
> drivers/media/rc/sunxi-cir.c | 20 +++++++++++---------
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> index 97f367b446c4..55b53d6463e9 100644
> --- a/drivers/media/rc/sunxi-cir.c
> +++ b/drivers/media/rc/sunxi-cir.c
> @@ -72,12 +72,6 @@
> /* CIR_REG register idle threshold */
> #define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
>
> -/* Required frequency for IR0 or IR1 clock in CIR mode */
> -#define SUNXI_IR_BASE_CLK 8000000
> -/* Frequency after IR internal divider */
> -#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
Keep those to definitions...
> -/* Sample period in ns */
> -#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
> /* Noise threshold in samples */
> #define SUNXI_IR_RXNOISE 1
> /* Idle Threshold in samples */
> @@ -122,7 +116,7 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
> /* for each bit in fifo */
> dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
> rawir.pulse = (dt & 0x80) != 0;
> - rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
> + rawir.duration = ((dt & 0x7f) + 1) * ir->rc->rx_resolution;
> ir_raw_event_store_with_filter(ir->rc, &rawir);
> }
> }
> @@ -148,6 +142,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> struct device_node *dn = dev->of_node;
> struct resource *res;
> struct sunxi_ir *ir;
> + u32 b_clk_freq;
>
> ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
> if (!ir)
> @@ -172,6 +167,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> return PTR_ERR(ir->clk);
> }
>
> + /* Required frequency for IR0 or IR1 clock in CIR mode */
> + if (of_property_read_u32(dn, "base-clk-frequency", &b_clk_freq)) {
> + dev_err(dev, "failed to get ir base clock frequency.\n");
> + return -ENODATA;
> + }
> +
And here, instead of returning an error, if the property can't be read,
it means it is an older DT file. Just default to SUNXI_IR_BASE_CLK.
This will make it backward-compatible with old DT files that don't have
such property.
Regards,
Mauro
> /* Reset (optional) */
> ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
> if (IS_ERR(ir->rst))
> @@ -180,7 +181,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
> + ret = clk_set_rate(ir->clk, b_clk_freq);
> if (ret) {
> dev_err(dev, "set ir base clock failed!\n");
> goto exit_reset_assert;
> @@ -225,7 +226,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
> ir->rc->dev.parent = dev;
> ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
> - ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
> + /* Frequency after IR internal divider with sample period in ns */
> + ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
> ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
> ir->rc->driver_name = SUNXI_IR_DEV;
>
Thanks,
Mauro
^ permalink raw reply
* [PATCH 6/8] drm/sun4i: sun4i_layer: Wire in the frontend
From: kbuild test robot @ 2017-12-16 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0cd2570c9cbe20d094cee0e8e9918c3a0f6af2fa.1513178989.git-series.maxime.ripard@free-electrons.com>
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on ]
url: https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
base:
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
WARNING: modpost: missing MODULE_LICENSE() in arch/arm/common/bL_switcher_dummy_if.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/auxdisplay/img-ascii-lcd.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/cpufreq/mediatek-cpufreq.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ath79.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/iio/accel/kxsd9-i2c.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/iio/adc/qcom-vadc-common.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/mtk-vcodec/mtk-vcodec-common.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/soc_camera/soc_scale_crop.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/tegra-cec/tegra_cec.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/mmc/host/renesas_sdhi_core.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/denali_pci.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/cirrus/cs89x0.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/qualcomm/phy-qcom-ufs.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/pinctrl/pxa/pinctrl-pxa2xx.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/power/reset/zx-reboot.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/soc/qcom/rmtfs_mem.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/staging/comedi/drivers/ni_atmio.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/video/fbdev/mmp/mmp_disp.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in sound/soc/codecs/snd-soc-pcm512x-spi.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in sound/soc/ux500/snd-soc-ux500-mach-mop500.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in sound/soc/ux500/snd-soc-ux500-plat-dma.o
see include/linux/module.h for more information
>> ERROR: "sun4i_frontend_update_formats" [drivers/gpu/drm/sun4i/sun4i-backend.ko] undefined!
>> ERROR: "sun4i_frontend_update_buffer" [drivers/gpu/drm/sun4i/sun4i-backend.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 64661 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171216/9eb1088e/attachment-0001.gz>
^ permalink raw reply
* [PATCH 07/25] arm: keystone: dts: Remove leading 0x and 0s from bindings notation
From: santosh.shilimkar at oracle.com @ 2017-12-16 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215124638.30233-1-malat@debian.org>
On 12/15/17 4:46 AM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__elinux.org_Device-5FTree-5FLinux-23Linux-5Fconventions&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=hWpFvp_cTkkwMMULcvbV65orOO9Gv3OUaY0ATWhQwak&m=4zPLm6aGenI9keAZLborgvk3tLzaGsH_T4xXnh1mN3c&s=nCTYz6lbODdmoNqNYOTb6wm8nNYWW-AZlwiaUp7gpmM&e=
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
Looks good.
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
^ permalink raw reply
* [PATCH 2/8] ARM: dts: keystone*: Use a single soc0 instance
From: santosh.shilimkar at oracle.com @ 2017-12-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1fce818d-f1a2-818d-7db8-d15a345f4c1e@ti.com>
On 12/15/17 5:38 AM, Nishanth Menon wrote:
> Crap.. couple of typos crept in. Apologies - Santosh, if you dont want
> to manualy change, I can rebase and repost if you like to any branch of
> your choice.
>
Just post it against for_4.16/keystone-dts
^ permalink raw reply
* [Question ]: Avoid kernel panic when killing an application if happen RAS page table error
From: gengdongjiu @ 2017-12-16 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215193551.GD27160@bombadil.infradead.org>
On 2017/12/16 3:35, Matthew Wilcox wrote:
>> It's going to be complicated to do, I don't think its worth the effort.
> We can find a bit in struct page that we guarantee will only be set if
> this is allocated as a pagetable. Bit 1 of the third union is currently
> available (compound_head is a pointer if bit 0 is set, so nothing is
> using bit 1). We can put a pointer to the mm_struct in the same word.
>
> Finding all the allocated pages will be the tricky bit. We could put a
> list_head into struct page; perhaps in the same spot as page_deferred_list
> for tail pages. Then we can link all the pagetables belonging to
> this mm together and tear them all down if any of them get an error.
> They'll repopulate on demand. It won't be quick or scalable, but when
> the alternative is death, it looks relatively attractive.
Thanks for the comments, I will check it in detailed and investigate whether it is worth to do for it.
Thanks!
>
> .
>
^ permalink raw reply
* [PATCH 5/8] drm/sun4i: Add a driver for the display frontend
From: kbuild test robot @ 2017-12-16 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <600d29233eb0dcca3af815fbed8995e35f78b4ee.1513178989.git-series.maxime.ripard@free-electrons.com>
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on ]
url: https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702
base:
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
Note: the linux-review/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702 HEAD c38c4ce4b14c4c68a9fde0cc35ead5b1c894776b builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_bind':
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:22: error: implicit declaration of function 'sun4i_backend_find_frontend'; did you mean 'sun4i_backend_bind'? [-Werror=implicit-function-declaration]
backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
sun4i_backend_bind
>> drivers/gpu/drm/sun4i/sun4i_backend.c:370:20: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
^
cc1: some warnings being treated as errors
vim +370 drivers/gpu/drm/sun4i/sun4i_backend.c
346
347 static int sun4i_backend_bind(struct device *dev, struct device *master,
348 void *data)
349 {
350 struct platform_device *pdev = to_platform_device(dev);
351 struct drm_device *drm = data;
352 struct sun4i_drv *drv = drm->dev_private;
353 struct sun4i_backend *backend;
354 const struct sun4i_backend_quirks *quirks;
355 struct resource *res;
356 void __iomem *regs;
357 int i, ret;
358
359 backend = devm_kzalloc(dev, sizeof(*backend), GFP_KERNEL);
360 if (!backend)
361 return -ENOMEM;
362 dev_set_drvdata(dev, backend);
363
364 backend->engine.node = dev->of_node;
365 backend->engine.ops = &sun4i_backend_engine_ops;
366 backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
367 if (backend->engine.id < 0)
368 return backend->engine.id;
369
> 370 backend->frontend = sun4i_backend_find_frontend(drv, dev->of_node);
371 if (IS_ERR(backend->frontend)) {
372 dev_err(dev, "Couldn't find matching frontend, frontend features disabled\n");
373 }
374
375 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
376 regs = devm_ioremap_resource(dev, res);
377 if (IS_ERR(regs))
378 return PTR_ERR(regs);
379
380 backend->reset = devm_reset_control_get(dev, NULL);
381 if (IS_ERR(backend->reset)) {
382 dev_err(dev, "Couldn't get our reset line\n");
383 return PTR_ERR(backend->reset);
384 }
385
386 ret = reset_control_deassert(backend->reset);
387 if (ret) {
388 dev_err(dev, "Couldn't deassert our reset line\n");
389 return ret;
390 }
391
392 backend->bus_clk = devm_clk_get(dev, "ahb");
393 if (IS_ERR(backend->bus_clk)) {
394 dev_err(dev, "Couldn't get the backend bus clock\n");
395 ret = PTR_ERR(backend->bus_clk);
396 goto err_assert_reset;
397 }
398 clk_prepare_enable(backend->bus_clk);
399
400 backend->mod_clk = devm_clk_get(dev, "mod");
401 if (IS_ERR(backend->mod_clk)) {
402 dev_err(dev, "Couldn't get the backend module clock\n");
403 ret = PTR_ERR(backend->mod_clk);
404 goto err_disable_bus_clk;
405 }
406 clk_prepare_enable(backend->mod_clk);
407
408 backend->ram_clk = devm_clk_get(dev, "ram");
409 if (IS_ERR(backend->ram_clk)) {
410 dev_err(dev, "Couldn't get the backend RAM clock\n");
411 ret = PTR_ERR(backend->ram_clk);
412 goto err_disable_mod_clk;
413 }
414 clk_prepare_enable(backend->ram_clk);
415
416 if (of_device_is_compatible(dev->of_node,
417 "allwinner,sun8i-a33-display-backend")) {
418 ret = sun4i_backend_init_sat(dev);
419 if (ret) {
420 dev_err(dev, "Couldn't init SAT resources\n");
421 goto err_disable_ram_clk;
422 }
423 }
424
425 backend->engine.regs = devm_regmap_init_mmio(dev, regs,
426 &sun4i_backend_regmap_config);
427 if (IS_ERR(backend->engine.regs)) {
428 dev_err(dev, "Couldn't create the backend regmap\n");
429 return PTR_ERR(backend->engine.regs);
430 }
431
432 list_add_tail(&backend->engine.list, &drv->engine_list);
433
434 /*
435 * Many of the backend's layer configuration registers have
436 * undefined default values. This poses a risk as we use
437 * regmap_update_bits in some places, and don't overwrite
438 * the whole register.
439 *
440 * Clear the registers here to have something predictable.
441 */
442 for (i = 0x800; i < 0x1000; i += 4)
443 regmap_write(backend->engine.regs, i, 0);
444
445 /* Disable registers autoloading */
446 regmap_write(backend->engine.regs, SUN4I_BACKEND_REGBUFFCTL_REG,
447 SUN4I_BACKEND_REGBUFFCTL_AUTOLOAD_DIS);
448
449 /* Enable the backend */
450 regmap_write(backend->engine.regs, SUN4I_BACKEND_MODCTL_REG,
451 SUN4I_BACKEND_MODCTL_DEBE_EN |
452 SUN4I_BACKEND_MODCTL_START_CTL);
453
454 /* Set output selection if needed */
455 quirks = of_device_get_match_data(dev);
456 if (quirks->needs_output_muxing) {
457 /*
458 * We assume there is no dynamic muxing of backends
459 * and TCONs, so we select the backend with same ID.
460 *
461 * While dynamic selection might be interesting, since
462 * the CRTC is tied to the TCON, while the layers are
463 * tied to the backends, this means, we will need to
464 * switch between groups of layers. There might not be
465 * a way to represent this constraint in DRM.
466 */
467 regmap_update_bits(backend->engine.regs,
468 SUN4I_BACKEND_MODCTL_REG,
469 SUN4I_BACKEND_MODCTL_OUT_SEL,
470 (backend->engine.id
471 ? SUN4I_BACKEND_MODCTL_OUT_LCD1
472 : SUN4I_BACKEND_MODCTL_OUT_LCD0));
473 }
474
475 return 0;
476
477 err_disable_ram_clk:
478 clk_disable_unprepare(backend->ram_clk);
479 err_disable_mod_clk:
480 clk_disable_unprepare(backend->mod_clk);
481 err_disable_bus_clk:
482 clk_disable_unprepare(backend->bus_clk);
483 err_assert_reset:
484 reset_control_assert(backend->reset);
485 return ret;
486 }
487
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 23186 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171216/09df427a/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 10/10] arm64: dts: qcom: msm8916: add nodes for i2c1, i2c3, i2c5
From: Bjorn Andersson @ 2017-12-16 5:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-11-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Please move pinconf settings into the structure in
apq8016-sbc-soc-pins.dtsi (didn't see this when commenting on the
previous patch).
Apart from this, the patch looks good.
Regards,
Bjorn
> ---
> Changes in v2:
> - Reworded commit title
> - Changed size to 0x500
>
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 48 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 42 ++++++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 45 ++++++++++++++++++++++++++++
> 3 files changed, 135 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 53c1ddd281a4..11305015ba0b 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -630,6 +630,22 @@
> };
> };
>
> +&i2c1_default {
> + pinconf {
> + pins = "gpio2", "gpio3";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +&i2c1_sleep {
> + pinconf {
> + pins = "gpio2", "gpio3";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
> &i2c2_default {
> pinconf {
> pins = "gpio6", "gpio7";
> @@ -646,6 +662,22 @@
> };
> };
>
> +&i2c3_default {
> + pinconf {
> + pins = "gpio10", "gpio11";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +&i2c3_sleep {
> + pinconf {
> + pins = "gpio10", "gpio11";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
> &i2c4_default {
> pinconf {
> pins = "gpio14", "gpio15";
> @@ -662,6 +694,22 @@
> };
> };
>
> +&i2c5_default {
> + pinconf {
> + pins = "gpio18", "gpio19";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +};
> +
> +&i2c5_sleep {
> + pinconf {
> + pins = "gpio18", "gpio19";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
> &i2c6_default {
> pinconf {
> pins = "gpio22", "gpio23";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> index 7704ddecb6c4..44e68860fc8c 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> @@ -152,6 +152,20 @@
> };
> };
>
> + i2c1_default: i2c1_default {
> + pinmux {
> + function = "blsp_i2c1";
> + pins = "gpio2", "gpio3";
> + };
> + };
> +
> + i2c1_sleep: i2c1_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio2", "gpio3";
> + };
> + };
> +
> i2c2_default: i2c2_default {
> pinmux {
> function = "blsp_i2c2";
> @@ -166,6 +180,20 @@
> };
> };
>
> + i2c3_default: i2c3_default {
> + pinmux {
> + function = "blsp_i2c3";
> + pins = "gpio10", "gpio11";
> + };
> + };
> +
> + i2c3_sleep: i2c3_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio10", "gpio11";
> + };
> + };
> +
> i2c4_default: i2c4_default {
> pinmux {
> function = "blsp_i2c4";
> @@ -180,6 +208,20 @@
> };
> };
>
> + i2c5_default: i2c5_default {
> + pinmux {
> + function = "blsp_i2c5";
> + pins = "gpio18", "gpio19";
> + };
> + };
> +
> + i2c5_sleep: i2c5_sleep {
> + pinmux {
> + function = "gpio";
> + pins = "gpio18", "gpio19";
> + };
> + };
> +
> i2c6_default: i2c6_default {
> pinmux {
> function = "blsp_i2c6";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index ac440f287633..7478c7337995 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -455,6 +455,21 @@
> status = "disabled";
> };
>
> + blsp_i2c1: i2c at 78b5000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x078b5000 0x500>;
> + interrupts = <GIC_SPI 95 0>;
> + clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> + <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>;
> + clock-names = "iface", "core";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&i2c1_default>;
> + pinctrl-1 = <&i2c1_sleep>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> blsp_i2c2: i2c at 78b6000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078b6000 0x500>;
> @@ -470,6 +485,21 @@
> status = "disabled";
> };
>
> + blsp_i2c3: i2c at 78b7000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x078b7000 0x500>;
> + interrupts = <GIC_SPI 97 0>;
> + clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> + <&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
> + clock-names = "iface", "core";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&i2c3_default>;
> + pinctrl-1 = <&i2c3_sleep>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> blsp_i2c4: i2c at 78b8000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078b8000 0x500>;
> @@ -485,6 +515,21 @@
> status = "disabled";
> };
>
> + blsp_i2c5: i2c at 78b9000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x078b9000 0x500>;
> + interrupts = <GIC_SPI 99 0>;
> + clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> + <&gcc GCC_BLSP1_QUP5_I2C_APPS_CLK>;
> + clock-names = "iface", "core";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&i2c5_default>;
> + pinctrl-1 = <&i2c5_sleep>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> blsp_i2c6: i2c at 78ba000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078ba000 0x500>;
> --
> 2.15.0
>
^ permalink raw reply
* [PATCH v2 09/10] arm64: dts: qcom: msm8916: normalize I2C and SPI nodes
From: Bjorn Andersson @ 2017-12-16 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-10-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> The QUP core can be used either for I2C or SPI, so the same IP is mapped
> by a driver or the other. SPI bindings use a leading 0 for the start
> address and a size of 0x600, I2C bindings don't have the leading 0 and
> have a size 0x1000.
>
> To make them more similar, add the leading 0 to I2C bindings and changes
> the size to 0x500 for all of them, as this is the actual size of these
> blocks. Also align the second entry of the clocks array.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 08/10] arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings
From: Bjorn Andersson @ 2017-12-16 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-9-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> Nodes relative to the first sdhc node were interlaced with node of the
> second sdhc. Move sdhc2_cd_pin with its siblings to prevent that. Also
> rename the grouping node from sdhc2_cd_pin to pmx_sdc2_cd_pin, as
> "pmx_sdc" is the prefix used by other nodes.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 07/10] arm64: dts: qcom: msm8916: drop remaining unused pinconfs
From: Bjorn Andersson @ 2017-12-16 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-8-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> This commit drops pin configs that cannot be moved to board files as
> no boards use them.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 06/10] arm64: dts: qcom: msm8916: move pinconfs to board files
From: Bjorn Andersson @ 2017-12-16 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-7-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> Following a suggestion from Bjorn Andersson [1], this commit moves
> electrical specifications which were defined in mms8916-pins.dtsi to
> board files, where they actually belong.
>
> Pinmuxing is kept in the platform file because there are no alternative
> pins on which all these functions could be routed, so this part is
> indeed common to all boards using this SoC.
>
> [1] https://www.spinics.net/lists/devicetree/msg201764.html
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
> Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
I like the move, but I would prefer that you mimic the base structure,
rather than just appending properties based on labels.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 05/10] arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically
From: Bjorn Andersson @ 2017-12-16 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-6-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> Also, it was using whitespaces for indentation on some lines, fix that
> while moving it.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Rather than extending single nodes like this I would prefer that we
bring in the associated pmic node, by this we avoid just having a huge
flat list of nodes. I.e. that we make this:
&pm8916_1 {
codec at f000 {
status = "okay";
clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
clock-names = "mclk";
qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
};
};
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 04/10] arm64: dts: qcom: msm8916: drop unused board-specific nodes
From: Bjorn Andersson @ 2017-12-16 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-5-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> These nodes reserve and configure some pins as GPIOs. They are not
> generic pinctrls, they actually belong to board files but they are not
> used by any other node, so just drop them altogether.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Let's introduce them back into the db410c when we define a client.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: gengdongjiu @ 2017-12-16 4:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79ccc7df-802b-e25c-05cf-b1ecc7c05569@huawei.com>
On 2017/12/16 12:08, gengdongjiu wrote:
> On 2017/12/15 23:50, James Morse wrote:
>> + case ESR_ELx_AET_UER: /* Uncorrected Recoverable */
>> + /*
>> + * The CPU can't make progress. The exception may have
>> + * been imprecise.
>> + */
>> + return true;
> For Recoverable error (UER), the error has not been silently propagated,
> and has not been architecturally consumed by the PE, and
> The exception is precise and PE can recover execution from the preferred return address of the exception.
> so I do not think it should be panic here if the SError come from user space instead of coming from kernel space.
I paste the spec definition for the Recoverable error (UER) which got from [0]
Recoverable error (UER)
The state of the PE is Recoverable if all of the following are true:
? The error has not been silently propagated.
? The error has not been architecturally consumed by the PE. (The PE architectural state is not infected.)
? The exception is precise and PE can recover execution from the preferred return address of the exception, if software locates and repairs the error.
The PE cannot make correct progress without either consuming the error or otherwise making the error unrecoverable. The error remains latent in the system.
If software cannot locate and repair the error, either the application or the VM, or both, must be isolated by software.
[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf
>> +
^ permalink raw reply
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: gengdongjiu @ 2017-12-16 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A0B1334.7060500@arm.com>
[...]
>
>> + case ESR_ELx_AET_UER: /* The error has not been propagated */
>> + /*
>> + * Userspace only handle the guest SError Interrupt(SEI) if the
>> + * error has not been propagated
>> + */
>> + run->exit_reason = KVM_EXIT_EXCEPTION;
>> + run->ex.exception = ESR_ELx_EC_SERROR;
>> + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>> + return 0;
>
> We should not pass RAS notifications to user space. The kernel either handles
> them, or it panics(). User space shouldn't even know if the kernel supports RAS
For the ESR_ELx_AET_UER(Recoverable error), let us see its definition
below, which get from [0]
The state of the PE is Recoverable if all of the following are true:
? The error has not been silently propagated.
? The error has not been architecturally consumed by the PE. (The PE
architectural state is not infected.)
? The exception is precise and PE can recover execution from the
preferred return address of the exception, if software locates and
repairs the error.
The PE cannot make correct progress without either consuming the error
or otherwise making the error unrecoverable. The error remains latent
in the system.
If software cannot locate and repair the error, either the application
or the VM, or both, must be isolated by software.
so we can see the exception is precise and PE can recover execution
from the preferred return address of the exception, so let guest
handling it is
better, for example, if it is guest application RAS error, we can kill
the guest application instead of panic whole OS; if it is guest kernel
RAS error, guest will panic.
Host does not know which application of guest has error, so host can
not handle it, panic OS is not a good choice for the Recoverable
error.
[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf
> until it gets an MCEERR signal.
user space will detect whether kernel support RAS before handing it.
>
> You're making your firmware-first notification an EL3->EL0 signal, bypassing the OS.
>
> If we get a RAS SError and there are no CPER records or values in the ERR nodes,
> we should panic as it looks like the CPU/firmware is broken. (spurious RAS errors)
>
>
>> + default:
>> + /*
>> + * Until now, the CPU supports RAS and SEI is fatal, or host
>> + * does not support to handle the SError.
>> + */
>> + panic("This Asynchronous SError interrupt is dangerous, panic");
>> + }
>> +
>> + return 0;
>> +}
>> +
>> /*
>> * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
>> * proper exit to userspace.
>
>
>
> James
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: gengdongjiu @ 2017-12-16 4:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215155101.23505-5-james.morse@arm.com>
On 2017/12/15 23:50, James Morse wrote:
> + case ESR_ELx_AET_UER: /* Uncorrected Recoverable */
> + /*
> + * The CPU can't make progress. The exception may have
> + * been imprecise.
> + */
> + return true;
For Recoverable error (UER), the error has not been silently propagated,
and has not been architecturally consumed by the PE, and
The exception is precise and PE can recover execution from the preferred return address of the exception.
so I do not think it should be panic here if the SError come from user space instead of coming from kernel space.
> +
^ permalink raw reply
* [PATCH] drm: Fix possible deadlock in drm_mode_config_cleanup()
From: kbuild test robot @ 2017-12-16 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213085720.6059-1-m.szyprowski@samsung.com>
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next drm-intel/for-linux-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Marek-Szyprowski/drm-Fix-possible-deadlock-in-drm_mode_config_cleanup/20171216-102239
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
kernel/sched/core.c:5113: warning: No description found for parameter 't'
kernel/sched/core.c:5113: warning: Excess function parameter 'interval' description in 'sched_rr_get_interval'
drivers/gpio/gpiolib.c:601: warning: No description found for parameter '16'
drivers/gpio/gpiolib.c:601: warning: Excess struct member 'events' description in 'lineevent_state'
include/linux/iio/iio.h:610: warning: No description found for parameter 'iio_dev'
include/linux/iio/iio.h:610: warning: Excess function parameter 'indio_dev' description in 'iio_device_register'
include/linux/iio/trigger.h:79: warning: No description found for parameter 'owner'
fs/inode.c:1680: warning: No description found for parameter 'rcu'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_transaction'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_next_transaction'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_list'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_vfs_inode'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_flags'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_rsv_handle'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_reserved'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_type'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_line_no'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_start_jiffies'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_requested_credits'
include/linux/jbd2.h:497: warning: No description found for parameter 'saved_alloc_context'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_chkpt_bhs'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_devname'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_average_commit_time'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_min_batch_time'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_max_batch_time'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_commit_callback'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_failed_commit'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_chksum_driver'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_csum_seed'
fs/jbd2/transaction.c:511: warning: No description found for parameter 'type'
fs/jbd2/transaction.c:511: warning: No description found for parameter 'line_no'
fs/jbd2/transaction.c:641: warning: No description found for parameter 'gfp_mask'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_pin'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_unpin'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_res_obj'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_get_sg_table'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_import_sg_table'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_vmap'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_vunmap'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_mmap'
include/drm/drm_mode_config.h:778: warning: No description found for parameter 'connector_free_works'
include/drm/drm_mode_config.h:778: warning: No description found for parameter 'connector_free_queue'
include/drm/drm_mode_config.h:778: warning: No description found for parameter 'modifiers_property'
>> include/drm/drm_mode_config.h:778: warning: Excess struct member 'pending_connector_free_works' description in 'drm_mode_config'
>> include/drm/drm_mode_config.h:778: warning: Excess struct member 'pending_connector_free_queue' description in 'drm_mode_config'
include/drm/drm_mode_config.h:778: warning: Excess struct member 'modifiers' description in 'drm_mode_config'
include/drm/drm_plane.h:552: warning: No description found for parameter 'modifiers'
include/drm/drm_plane.h:552: warning: No description found for parameter 'modifier_count'
drivers/gpu/drm/drm_edid.c:4837: warning: No description found for parameter 'is_hdmi2_sink'
drivers/gpu/drm/drm_syncobj.c:306: warning: No description found for parameter 'file_private'
drivers/gpu/drm/drm_syncobj.c:306: warning: No description found for parameter 'syncobj'
drivers/gpu/drm/drm_syncobj.c:306: warning: No description found for parameter 'handle'
drivers/gpu/drm/drm_syncobj.c:307: warning: No description found for parameter 'file_private'
drivers/gpu/drm/drm_syncobj.c:307: warning: No description found for parameter 'syncobj'
drivers/gpu/drm/drm_syncobj.c:307: warning: No description found for parameter 'handle'
drivers/gpu/drm/i915/i915_gem.c:548: warning: No description found for parameter 'rps_client'
drivers/gpu/drm/i915/i915_gem.c:548: warning: Excess function parameter 'rps' description in 'i915_gem_object_wait'
Error: Cannot open file drivers/gpu/drm/i915/intel_guc_loader.c
WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -function GuC-specific firmware loader drivers/gpu/drm/i915/intel_guc_loader.c' failed with return code 1
Error: Cannot open file drivers/gpu/drm/i915/intel_guc_loader.c
Error: Cannot open file drivers/gpu/drm/i915/intel_guc_loader.c
WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -internal drivers/gpu/drm/i915/intel_guc_loader.c' failed with return code 2
drivers/gpu/host1x/bus.c:50: warning: No description found for parameter 'driver'
drivers/gpu/drm/tve200/tve200_drv.c:1: warning: no structured comments found
net/core/dev.c:1678: warning: Excess function parameter 'dev' description in 'call_netdevice_notifiers_info'
net/core/dev.c:6361: warning: No description found for parameter 'extack'
net/core/dev.c:6384: warning: No description found for parameter 'extack'
include/linux/rcupdate.h:571: ERROR: Unexpected indentation.
include/linux/rcupdate.h:575: ERROR: Unexpected indentation.
include/linux/rcupdate.h:579: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/rcupdate.h:581: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/rcupdate.h:581: WARNING: Inline literal start-string without end-string.
kernel/time/timer.c:1253: ERROR: Unexpected indentation.
kernel/time/timer.c:1255: ERROR: Unexpected indentation.
kernel/time/timer.c:1256: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:110: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:113: ERROR: Unexpected indentation.
include/linux/wait.h:115: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/time/hrtimer.c:989: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/signal.c:325: WARNING: Inline literal start-string without end-string.
include/linux/iio/iio.h:219: ERROR: Unexpected indentation.
include/linux/iio/iio.h:220: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/iio/iio.h:226: WARNING: Definition list ends without a blank line; unexpected unindent.
drivers/ata/libata-core.c:5913: ERROR: Unknown target name: "hw".
drivers/message/fusion/mptbase.c:5051: WARNING: Definition list ends without a blank line; unexpected unindent.
drivers/tty/serial/serial_core.c:1899: WARNING: Definition list ends without a blank line; unexpected unindent.
include/linux/regulator/driver.h:271: ERROR: Unknown target name: "regulator_regmap_x_voltage".
include/linux/spi/spi.h:373: ERROR: Unexpected indentation.
drivers/w1/w1_io.c:197: WARNING: Definition list ends without a blank line; unexpected unindent.
net/core/dev.c:4483: ERROR: Unknown target name: "page_is".
Documentation/trace/ftrace-uses.rst:53: WARNING: Definition list ends without a blank line; unexpected unindent.
Documentation/trace/ftrace-uses.rst:89: WARNING: Inline emphasis start-string without end-string.
Documentation/trace/ftrace-uses.rst:89: WARNING: Inline emphasis start-string without end-string.
Documentation/errseq.rst:: WARNING: document isn't included in any toctree
Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in any toctree
Documentation/trace/ftrace-uses.rst:: WARNING: document isn't included in any toctree
Documentation/virtual/kvm/vcpu-requests.rst:: WARNING: document isn't included in any toctree
Documentation/dev-tools/kselftest.rst:15: WARNING: Could not lex literal_block as "c". Highlighting skipped.
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
vim +778 include/drm/drm_mode_config.h
28575f16 Daniel Vetter 2016-11-14 @778
:::::: The code at line 778 was first introduced by commit
:::::: 28575f165d36051310d7ea2350e2011f8095b6fb drm: Extract drm_mode_config.[hc]
:::::: TO: Daniel Vetter <daniel.vetter@ffwll.ch>
:::::: CC: Daniel Vetter <daniel.vetter@ffwll.ch>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6843 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171216/5ccb7fc1/attachment-0001.gz>
^ permalink raw reply
* [PATCH v4 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board
From: Yixun Lan @ 2017-12-16 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216035527.96952-1-yixun.lan@amlogic.com>
This is tested in the S400 dev board which use a RTL8211F PHY,
and the pins connect to the 'eth_rgmii_y_pins' group.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..8932654f5090 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -17,6 +17,13 @@
};
};
+ðmac {
+ status = "okay";
+ phy-mode = "rgmii";
+ pinctrl-0 = <ð_rgmii_y_pins>;
+ pinctrl-names = "default";
+};
+
&uart_AO {
status = "okay";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-16 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216035527.96952-1-yixun.lan@amlogic.com>
Add DT info for the stmmac ethernet MAC which found in
the Amlogic's Meson-AXG SoC, also describe the ethernet
pinctrl & clock information here.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d288d4724ae3..dea1bc31b4de 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -155,6 +156,19 @@
};
};
+ ethmac: ethernet at ff3f0000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0x0 0xff3f0000 0x0 0x10000
+ 0x0 0xff634540 0x0 0x8>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "macirq";
+ clocks = <&clkc CLKID_ETH>,
+ <&clkc CLKID_FCLK_DIV2>,
+ <&clkc CLKID_MPLL2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ status = "disabled";
+ };
+
gic: interrupt-controller at ffc01000 {
compatible = "arm,gic-400";
reg = <0x0 0xffc01000 0 0x1000>,
@@ -215,6 +229,46 @@
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+ eth_rgmii_x_pins: eth-x-rgmii {
+ mux {
+ groups = "eth_mdio_x",
+ "eth_mdc_x",
+ "eth_rgmii_rx_clk_x",
+ "eth_rx_dv_x",
+ "eth_rxd0_x",
+ "eth_rxd1_x",
+ "eth_rxd2_rgmii",
+ "eth_rxd3_rgmii",
+ "eth_rgmii_tx_clk",
+ "eth_txen_x",
+ "eth_txd0_x",
+ "eth_txd1_x",
+ "eth_txd2_rgmii",
+ "eth_txd3_rgmii";
+ function = "eth";
+ };
+ };
+
+ eth_rgmii_y_pins: eth-y-rgmii {
+ mux {
+ groups = "eth_mdio_y",
+ "eth_mdc_y",
+ "eth_rgmii_rx_clk_y",
+ "eth_rx_dv_y",
+ "eth_rxd0_y",
+ "eth_rxd1_y",
+ "eth_rxd2_rgmii",
+ "eth_rxd3_rgmii",
+ "eth_rgmii_tx_clk",
+ "eth_txen_y",
+ "eth_txd0_y",
+ "eth_txd1_y",
+ "eth_txd2_rgmii",
+ "eth_txd3_rgmii";
+ function = "eth";
+ };
+ };
+
pwm_a_a_pins: pwm_a_a {
mux {
groups = "pwm_a_a";
--
2.15.1
^ permalink raw reply related
* [PATCH v4 0/2] Add ethernet support for Meson-AXG SoC
From: Yixun Lan @ 2017-12-16 3:55 UTC (permalink / raw)
To: linux-arm-kernel
This series try to add support for the ethernet MAC controller
found in Meson-AXG SoC, and also enable it in the S400 board.
Hi Kevin:
You still need to at least merge the clock patch[3] in order to
compile the DTS, or just merge the tag from meson-clock's tree[6]
- the tag is 'meson-clk-for-v4.16-2', since the clock part already
taken there.
Changes in v4 since [5]:
- rebase to kevin's v4.16/dt64
- fix order
Changes in v3 since [4]:
- put clock DT info in soc.dtsi
- separate DT for 'add support for the controller' vs 'enable in board'
Changes in v2 since [1]:
- rebase to kevin's v4.16/dt64 branch
- add Neil's Reviewed-by
- move clock info to board.dts instead of in soc.dtsi
- drop "meson-axg-dwmac" compatible string, since we didn't use this
we could re-add it later when we really need.
- note: to make ethernet work properly,it depend on clock & pinctrl[2],
to compile the DTS, the patch [3] is required.
the code part will be taken via clock & pinctrl subsystem tree.
[5]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005783.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005784.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005785.html
[4]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005768.html
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html
[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html
[3]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html
[6] git://github.com/BayLibre/clk-meson.git
Yixun Lan (2):
ARM64: dts: meson-axg: add ethernet mac controller
ARM64: dts: meson-axg: enable ethernet for A113D S400 board
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
--
2.15.1
^ permalink raw reply
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: gengdongjiu @ 2017-12-16 3:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A3419FF.30101@arm.com>
Hi James,
On 2017/12/16 2:52, James Morse wrote:
>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown below:
>>
>> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
>> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>>
>> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify trigger method, which all
>>
>> not involve _trigger_ an SError.
> It's a policy choice. How does your virtual CPU notify RAS errors to its virtual
> software? You could use SError for SIGBUS_MCEERR_AR, it depends on what type of
> CPU you are trying to emulate.
>
> I'd suggest using NOTIFY_SEA for SIGBUS_MCEERR_AR as it avoids problems where
> the guest doesn't take the SError immediately, instead tries to re-execute the
I agree it is better to use NOTIFY_SEA for SIGBUS_MCEERR_AR in this case.
> code KVM has unmapped from stage2 because its corrupt. (You could detect this
> happening in Qemu and try something else)For something else, using NOTIFY_SEI for SIGBUS_MCEERR_AR? At current implementation,
It seems only have this case that "KVM has unmapped from stage2", do you thing we still have something else?
>
>
> Synchronous/asynchronous external abort matters to the CPU, but once the error
> has been notified to software the reasons for this distinction disappear. Once
> the error has been handled, all trace of this distinction is gone.
>
> CPER records only describe component failures. You are trying to re-create some
> state that disappeared with one of the firmware-first abstractions. Trying to
> re-create this information isn't worth the effort as the distinction doesn't
> matter to linux, only to the CPU.
>
>
>> so there is no chance for Qemu to trigger the SError when gets the SIGBUS_MCEERR_A{O,R}.
> You mean there is no reason for Qemu to trigger an SError when it gets a signal
> from the kernel.
>
> The reasons the CPU might have to generate an SError don't apply to linux and
> KVM user space. User-space will never get a signal for an uncontained error, we
> will always panic(). We can't give user-space a signal for imprecise exceptions,
> as it can't return from the signal. The classes of error that are left are
> covered by polled/irq and NOTIFY_SEA.
>
> Qemu can decide to generate RAS SErrors for SIGBUS_MCEERR_AR if it really wants
> to, (but I don't think you should, the kernel may have unmapped the page at PC
> from stage2 due to corruption).
yes, you also said you do not want to generate RAS SErrors for SIGBUS_MCEERR_AR,
so Qemu does not know in which condition to generate RAS SErrors.
>
> I think the problem here is you're applying the CPU->software behaviour and
> choices to software->software. By the time user-space gets the error, the
> behaviour is different.
In the KVM, as a policy choice to reserve this API to specify guest ESR and drive to trigger SError is OK,
At least for Qemu it does not know in which condition to trigger it.
^ permalink raw reply
* [PATCH v3 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-16 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ho9mz94dg.fsf@baylibre.com>
HI Kevin
On 12/16/2017 03:29 AM, Kevin Hilman wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
>> Add DT info for the stmmac ethernet MAC which found in
>> the Amlogic's Meson-AXG SoC, also describe the ethernet
>> pinctrl & clock information here.
>>
>> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> This patch does not apply, and dependencies are not described.
>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index d356ce74ad89..94c4972222b7 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -7,6 +7,7 @@
>> #include <dt-bindings/gpio/gpio.h>
>> #include <dt-bindings/interrupt-controller/irq.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/clock/axg-clkc.h>
>>
>> / {
>> compatible = "amlogic,meson-axg";
>> @@ -148,6 +149,19 @@
>> #address-cells = <0>;
>> };
>>
>> + ethmac: ethernet at ff3f0000 {
>> + compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
>> + reg = <0x0 0xff3f0000 0x0 0x10000
>> + 0x0 0xff634540 0x0 0x8>;
>> + interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "macirq";
>> + clocks = <&clkc CLKID_ETH>,
>> + <&clkc CLKID_FCLK_DIV2>,
>> + <&clkc CLKID_MPLL2>;
>> + clock-names = "stmmaceth", "clkin0", "clkin1";
>> + status = "disabled";
>> + };
>> +
>> hiubus: bus at ff63c000 {
>> compatible = "simple-bus";
>> reg = <0x0 0xff63c000 0x0 0x1c00>;
>
> Based on the hiubus node, presumably this depends on the patch from the
> clock series.
>
yes, it depend on clock, also the pinctrl patch
>> @@ -194,6 +208,46 @@
>> #gpio-cells = <2>;
>> gpio-ranges = <&pinctrl_periphs 0 0 86>;
>> };
>
> I'm not sure where this part is coming from, but it causes the rest of
> it to not apply.
>
> Please be sure to describe all dependencies.
>
.
exactly, it depend on pinctrl
actually, once you apply the clock & pinctrl DT patch, this one should
go fine. I will send another v4 which base on your recent v4.16/dt64
branch for your convenience.
Yixun
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox