* [PATCH 19/28] drm/mediatek: add connection from RDMA2 to DPI1
From: CK Hu @ 2018-06-13 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528876862.11190.35.camel@mtksdccf07>
Hi, Stu:
On Wed, 2018-06-13 at 16:01 +0800, Stu Hsieh wrote:
> Hi, CK:
>
>
> On Wed, 2018-06-13 at 15:13 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > This patch add the connection from RDMA2 to DPI1
> > >
> > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index 31a0832ef9ec..2d883815d79c 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > @@ -93,9 +93,11 @@
> > > #define RDMA1_MOUT_DPI0 0x2
> > > #define RDMA1_MOUT_DPI1 0x3
> > > #define RDMA2_MOUT_DPI0 0x2
> > > +#define RDMA2_MOUT_DPI1 0x3
> >
> > Usually, each bit of a mout register represent a output enable. Is this
> > value 0x3 a correct value?
> >
> > Regards,
> > CK
> >
> In HW CONFIG SPEC or MT2712_E2_MMSYS_Change_note show as following:
>
> Bit(s) Name Description
> 2:0 DISP_RDMA2_SOUT_SEL_IN 0: output to dsi0
> 1: outptu to dsi1
> 2: output to dpi0
> 3: output to dpi1
> 4: output to dsi2
> 5: output to dsi3
>
> So, 0x3 is correct value.
The data sheet use the term SOUT match its function, so I think driver
have better change the naming to SOUT.
Regards,
CK
>
> Regard,
> Stu
>
> > > #define DPI0_SEL_IN_RDMA1 0x1
> > > #define DPI0_SEL_IN_RDMA2 0x3
> > > #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
> > > #define DSI1_SEL_IN_RDMA1 0x1
> > > #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> > > #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> > > @@ -199,6 +201,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > > value = RDMA2_MOUT_DPI0;
> > > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > > + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > > + value = RDMA2_MOUT_DPI1;
> > > } else {
> > > value = 0;
> > > }
> > > @@ -233,6 +238,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > value = DPI0_SEL_IN_RDMA2;
> > > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > + value = DPI1_SEL_IN_RDMA2;
> > > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > > value = COLOR1_SEL_IN_OVL1;
> >
> >
>
>
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Masahiro Yamada @ 2018-06-13 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613072649.dzbusalsfqlgymew@flea>
Hi.
2018-06-13 16:26 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
> On Mon, Jun 11, 2018 at 03:53:41PM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>> > Hi Maxime,
>> >
>> >
>> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
>> >> Hi Mike, Stephen,
>> >>
>> >> Please merge the following changes for the next merge window, thanks!
>> >>
>> >> Maxime
>> >>
>> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>> >>
>> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>> >>
>> >> are available in the Git repository at:
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
>> >>
>> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
>> >>
>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
>> >>
>> >> ----------------------------------------------------------------
>> >> Allwinner clock changes for 4.18
>> >>
>> >> Not a lot of changes for this release, but two quite important features
>> >> were added: the H6 PRCM clock support, and the needed changes to the R40
>> >> clock driver to allow for the EMAC to operate.
>> >>
>> >> ----------------------------------------------------------------
>> >> Icenowy Zheng (3):
>> >> clk: sunxi-ng: add support for H6 PRCM CCU
>> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
>> >>
>> >
>> >
>> >
>> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
>> > not included in the pull request?
>> >
>> >
>> > You said "I've picked it up"
>> > https://patchwork.kernel.org/patch/10348031/
>>
>> It looks like it was accidentally dropped after a rebase.
>> Not quite sure what happened there. Maxime?
>
> I'm not quite sure what happened, sorry, but this should have
> definitely been part of that PR :/
>
Stephen offered to pick it up directly for -rc2.
Is that OK with you?
I am fine if it is well-organized between you and Stephen.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
From: Paul Kocialkowski @ 2018-06-13 8:16 UTC (permalink / raw)
To: linux-arm-kernel
This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70.
The offending commit triggers a run-time fault when accessing the panel
element of the sun4i_tcon structure when no such panel is attached.
It was apparently assumed in said commit that a panel is always used with
the TCON. Although it is often the case, this is not always true.
For instance a bridge might be used instead of a panel.
This issue was discovered using an A13-OLinuXino, that uses the TCON
in RGB mode for a simple DAC-based VGA bridge.
Cc: stable at vger.kernel.org
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 -------------------------
1 file changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c3d92d537240..8045871335b5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,7 +17,6 @@
#include <drm/drm_encoder.h>
#include <drm/drm_modes.h>
#include <drm/drm_of.h>
-#include <drm/drm_panel.h>
#include <uapi/drm/drm_mode.h>
@@ -350,9 +349,6 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon,
static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
const struct drm_display_mode *mode)
{
- struct drm_panel *panel = tcon->panel;
- struct drm_connector *connector = panel->connector;
- struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -410,27 +406,6 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
- /*
- * On A20 and similar SoCs, the only way to achieve Positive Edge
- * (Rising Edge), is setting dclk clock phase to 2/3(240?).
- * By default TCON works in Negative Edge(Falling Edge),
- * this is why phase is set to 0 in that case.
- * Unfortunately there's no way to logically invert dclk through
- * IO_POL register.
- * The only acceptable way to work, triple checked with scope,
- * is using clock phase set to 0? for Negative Edge and set to 240?
- * for Positive Edge.
- * On A33 and similar SoCs there would be a 90? phase option,
- * but it divides also dclk by 2.
- * Following code is a way to avoid quirks all around TCON
- * and DOTCLOCK drivers.
- */
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
- clk_set_phase(tcon->dclk, 240);
-
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
- clk_set_phase(tcon->dclk, 0);
-
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
val);
--
2.17.0
^ permalink raw reply related
* [PATCH 14/28] drm/mediatek: add connection from RDMA1 to DPI1
From: CK Hu @ 2018-06-13 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528876574.11190.32.camel@mtksdccf07>
Hi, Stu:
On Wed, 2018-06-13 at 15:56 +0800, Stu Hsieh wrote:
> Hi, CK:
>
> On Wed, 2018-06-13 at 14:13 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > This patch add the connection from RDMA1 to DPI1
> > >
> > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index fed1b5704355..4abd5dabeccf 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > @@ -85,7 +85,9 @@
> > > #define RDMA0_MOUT_DSI2 0x4
> > > #define RDMA0_MOUT_DSI3 0x5
> > > #define RDMA1_MOUT_DPI0 0x2
> > > +#define RDMA1_MOUT_DPI1 0x3
> >
> > Usually, each bit of a mout register represent a output enable. Is this
> > value 0x3 a correct value?
> >
> > Regards,
> > CK
> >
> In HW CONFIG SPEC show as following
>
> Bit(s) Name Description
> 2:0 DISP_PATH1_SOUT_SEL_IN 0 : Output to DSI0
> 1: Ooutput to DSI1
> 2: Ooutput to DPI
> 3: Ooutput to DPI1
> 4: Ooutput to DSI2
> 5: Ooutput to DSI3
> 6 : reserved
> 7: Ooutput to DISP_UFOE
>
> So, 0x3 is correct value
It looks like that RDMA1 output is also SOUT, use the naming SOUT would
be better.
Regards,
CK
>
> Regard,
> Stu
>
>
> > > #define DPI0_SEL_IN_RDMA1 0x1
> > > +#define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > > #define COLOR1_SEL_IN_OVL1 0x1
> > >
> > > #define OVL_MOUT_EN_RDMA 0x1
> > > @@ -171,6 +173,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > > value = RDMA1_MOUT_DPI0;
> > > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > > + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > > + value = RDMA1_MOUT_DPI1;
> > > } else {
> > > value = 0;
> > > }
> > > @@ -190,6 +195,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > value = DPI0_SEL_IN_RDMA1;
> > > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > + value = DPI1_SEL_IN_RDMA1;
> > > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > > value = COLOR1_SEL_IN_OVL1;
> >
> >
>
>
^ permalink raw reply
* [PATCH] MAINTAINERS: Remove the AT91 clk driver entry
From: Boris Brezillon @ 2018-06-13 8:29 UTC (permalink / raw)
To: linux-arm-kernel
I've stopped actively maintaining this driver for quite some time
already, and at91 maintainers are doing a good job at maintaining it.
Remove the AT91 clk driver entry so that the driver automatically
falls under the "ARM/Microchip (AT91) SoC support" entry.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
---
MAINTAINERS | 5 -----
1 file changed, 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 634abf4569c4..491cc42ab65f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1242,11 +1242,6 @@ F: arch/arm/mach-aspeed/
F: arch/arm/boot/dts/aspeed-*
N: aspeed
-ARM/ATMEL AT91 Clock Support
-M: Boris Brezillon <boris.brezillon@bootlin.com>
-S: Maintained
-F: drivers/clk/at91
-
ARM/CALXEDA HIGHBANK ARCHITECTURE
M: Rob Herring <robh@kernel.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
--
2.14.1
^ permalink raw reply related
* [PATCH 13/28] drm/mediatek: add connection from RDMA0 to DSI3
From: Stu Hsieh @ 2018-06-13 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528877112.30263.24.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 16:05 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Wed, 2018-06-13 at 15:46 +0800, Stu Hsieh wrote:
> > Hi, CK:
> >
> > On Wed, 2018-06-13 at 13:45 +0800, CK Hu wrote:
> > > Hi, Stu:
> > >
> > > Two inline comment.
> > >
> > > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > > This patch add the connection from RDMA0 to DSI3
> > > >
> > > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
> > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> > > > 2 files changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > index c08aed8dae44..fed1b5704355 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > @@ -83,6 +83,7 @@
> > > > #define GAMMA_MOUT_EN_RDMA1 0x1
> > > > #define RDMA0_MOUT_DPI0 0x2
> > > > #define RDMA0_MOUT_DSI2 0x4
> > > > +#define RDMA0_MOUT_DSI3 0x5
> > >
> > > Usually, each bit of a mout register represent a output enable. Is this
> > > value 0x5 is a correct value?
> >
> > In hw CONFIG SPEC show as following:
> > Bit(s) Name Description
> > 2:0 DISP_PATH0_SOUT_SEL_IN 0 : Output to DSI0
> > 1: Ooutput to DSI1
> > 2: Ooutput to DPI
> > 3: Ooutput to DPI1
> > 4: Ooutput to DSI2
> > 5: Ooutput to DSI3
> > 6 : reserved
> > 7: Ooutput to DISP_UFOE
> > So, the value 0x5 is correct value.
> >
>
> From the definition, it looks like that RDMA0 could only single output
> (output to only one destination at one moment). The register naming
> 'DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN' (MOUT means output to multiple
> destination simultaneously) would confuse me. If the data sheet use the
> confused naming, I think I could just accept it.
>
> Regards,
> CK
>
OK, I would change the definition name from
DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN to DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN
> > Regard,
> > Stu
> >
> > >
> > > > #define RDMA1_MOUT_DPI0 0x2
> > > > #define DPI0_SEL_IN_RDMA1 0x1
> > > > #define COLOR1_SEL_IN_OVL1 0x1
> > > > @@ -164,6 +165,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > > > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> > > > *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> > > > value = RDMA0_MOUT_DSI2;
> > > > + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> > > > + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> > > > + value = RDMA0_MOUT_DSI3;
> > > > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > > > *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > > > value = RDMA1_MOUT_DPI0;
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > index fe6fdc021fc7..22f4c72fa785 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > > @@ -228,7 +228,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> > > > [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
> > > > [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
> > > > [DDP_COMPONENT_DSI2] = { MTK_DSI, 2, NULL },
> > > > - [DDP_COMPONENT_DSI2] = { MTK_DSI, 3, NULL },
> > > > + [DDP_COMPONENT_DSI3] = { MTK_DSI, 3, NULL },
> > >
> > > I think this is not related to this patch.
> > OK
> >
> > >
> > > Regards,
> > > CK
> > >
> > > > [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> > > > [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
> > > > [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
> > >
> > >
> >
> >
>
>
^ permalink raw reply
* [PATCH 14/28] drm/mediatek: add connection from RDMA1 to DPI1
From: Stu Hsieh @ 2018-06-13 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528878446.30263.30.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 16:27 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Wed, 2018-06-13 at 15:56 +0800, Stu Hsieh wrote:
> > Hi, CK:
> >
> > On Wed, 2018-06-13 at 14:13 +0800, CK Hu wrote:
> > > Hi, Stu:
> > >
> > > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > > This patch add the connection from RDMA1 to DPI1
> > > >
> > > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > index fed1b5704355..4abd5dabeccf 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > @@ -85,7 +85,9 @@
> > > > #define RDMA0_MOUT_DSI2 0x4
> > > > #define RDMA0_MOUT_DSI3 0x5
> > > > #define RDMA1_MOUT_DPI0 0x2
> > > > +#define RDMA1_MOUT_DPI1 0x3
> > >
> > > Usually, each bit of a mout register represent a output enable. Is this
> > > value 0x3 a correct value?
> > >
> > > Regards,
> > > CK
> > >
> > In HW CONFIG SPEC show as following
> >
> > Bit(s) Name Description
> > 2:0 DISP_PATH1_SOUT_SEL_IN 0 : Output to DSI0
> > 1: Ooutput to DSI1
> > 2: Ooutput to DPI
> > 3: Ooutput to DPI1
> > 4: Ooutput to DSI2
> > 5: Ooutput to DSI3
> > 6 : reserved
> > 7: Ooutput to DISP_UFOE
> >
> > So, 0x3 is correct value
>
> It looks like that RDMA1 output is also SOUT, use the naming SOUT would
> be better.
>
> Regards,
> CK
>
OK, I would change the definition name from
DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN to DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN
Regard,
STu
> >
> > Regard,
> > Stu
> >
> >
> > > > #define DPI0_SEL_IN_RDMA1 0x1
> > > > +#define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > > > #define COLOR1_SEL_IN_OVL1 0x1
> > > >
> > > > #define OVL_MOUT_EN_RDMA 0x1
> > > > @@ -171,6 +173,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > > > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > > > *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > > > value = RDMA1_MOUT_DPI0;
> > > > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > > > + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > > > + value = RDMA1_MOUT_DPI1;
> > > > } else {
> > > > value = 0;
> > > > }
> > > > @@ -190,6 +195,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > > > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > > > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > > value = DPI0_SEL_IN_RDMA1;
> > > > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > > > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > > + value = DPI1_SEL_IN_RDMA1;
> > > > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > > > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > > > value = COLOR1_SEL_IN_OVL1;
> > >
> > >
> >
> >
>
>
^ permalink raw reply
* [PATCH v4 6/6] dt-bindings: media: rcar-vin: Clarify optional props
From: jacopo mondi @ 2018-06-13 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612154553.kgqnqkwv3y6srivg@kekkonen.localdomain>
Hi Sakari,
On Tue, Jun 12, 2018 at 06:45:53PM +0300, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Tue, Jun 12, 2018 at 04:26:06PM +0200, Jacopo Mondi wrote:
> > Add a note to the R-Car VIN interface bindings to clarify that all
> > properties listed as generic properties in video-interfaces.txt can
> > be included in port at 0 endpoint, but if not explicitly listed in the
> > interface bindings documentation, they do not modify it behaviour.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > Documentation/devicetree/bindings/media/rcar_vin.txt | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index 8130849..03544c7 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -55,6 +55,12 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> > instances that are connected to external pins should have port 0.
> >
> > - Optional properties for endpoint nodes of port at 0:
> > +
> > + All properties described in [1] and which apply to the selected
> > + media bus type could be optionally listed here to better describe
> > + the current hardware configuration, but only the following ones do
> > + actually modify the VIN interface behaviour:
> > +
>
> I don't think this should be needed. You should only have properties that
> describe the hardware configuration in a given system.
>
There has been quite some debate on this, and please bear with me
here for re-proposing it: I started by removing properties in some DT
files for older Renesas board which listed endpoint properties not
documented in the VIN's bindings and not parsed by the VIN driver [1]
Niklas (but Simon and Geert seems to agree here) opposed to that
patch, as those properties where described in 'video-interfaces.txt' and
even if not parsed by the current driver implementation, they actually
describe hardware. I rebated that only properties listed in the device
bindings documentation should actually be used, and having properties
not parsed by the driver confuses users, which may expect changing
them modifies the interface configuration, which does not happens at
the moment.
This came out as a middle ground from a discussion with Niklas. As
stated in the cover letter if this patch makes someone uncomfortable, feel
free to drop it not to hold back the rest of the series which has been
well received instead.
Thanks
j
[1] https://www.spinics.net/lists/arm-kernel/msg656302.html
> > - hsync-active: see [1] for description. Default is active high.
> > - vsync-active: see [1] for description. Default is active high.
> > - data-enable-active: polarity of CLKENB signal, see [1] for
> > --
> > 2.7.4
> >
>
> --
> Sakari Ailus
> sakari.ailus at linux.intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/e8557938/attachment.sig>
^ permalink raw reply
* [PATCH 19/28] drm/mediatek: add connection from RDMA2 to DPI1
From: Stu Hsieh @ 2018-06-13 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528877675.30263.27.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 16:14 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Wed, 2018-06-13 at 16:01 +0800, Stu Hsieh wrote:
> > Hi, CK:
> >
> >
> > On Wed, 2018-06-13 at 15:13 +0800, CK Hu wrote:
> > > Hi, Stu:
> > >
> > > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > > This patch add the connection from RDMA2 to DPI1
> > > >
> > > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > index 31a0832ef9ec..2d883815d79c 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > @@ -93,9 +93,11 @@
> > > > #define RDMA1_MOUT_DPI0 0x2
> > > > #define RDMA1_MOUT_DPI1 0x3
> > > > #define RDMA2_MOUT_DPI0 0x2
> > > > +#define RDMA2_MOUT_DPI1 0x3
> > >
> > > Usually, each bit of a mout register represent a output enable. Is this
> > > value 0x3 a correct value?
> > >
> > > Regards,
> > > CK
> > >
> > In HW CONFIG SPEC or MT2712_E2_MMSYS_Change_note show as following:
> >
> > Bit(s) Name Description
> > 2:0 DISP_RDMA2_SOUT_SEL_IN 0: output to dsi0
> > 1: outptu to dsi1
> > 2: output to dpi0
> > 3: output to dpi1
> > 4: output to dsi2
> > 5: output to dsi3
> >
> > So, 0x3 is correct value.
>
> The data sheet use the term SOUT match its function, so I think driver
> have better change the naming to SOUT.
>
> Regards,
> CK
>
The definition DISP_REG_CONFIG_DISP_RDMA2_SOUT is use term SOUT in this
patch.
Regard,
Stu
> >
> > Regard,
> > Stu
> >
> > > > #define DPI0_SEL_IN_RDMA1 0x1
> > > > #define DPI0_SEL_IN_RDMA2 0x3
> > > > #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > > > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
> > > > #define DSI1_SEL_IN_RDMA1 0x1
> > > > #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> > > > #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> > > > @@ -199,6 +201,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > > > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > > > *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > > > value = RDMA2_MOUT_DPI0;
> > > > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > > > + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > > > + value = RDMA2_MOUT_DPI1;
> > > > } else {
> > > > value = 0;
> > > > }
> > > > @@ -233,6 +238,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > > > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > > > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > > value = DPI0_SEL_IN_RDMA2;
> > > > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > > > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > > + value = DPI1_SEL_IN_RDMA2;
> > > > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > > > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > > > value = COLOR1_SEL_IN_OVL1;
> > >
> > >
> >
> >
>
>
^ permalink raw reply
* [PATCH] mm: cma: honor __GFP_ZERO flag in cma_alloc()
From: Marek Szyprowski @ 2018-06-13 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20180613085851eucas1p20337d050face8ff8ea87674e16a9ccd2@eucas1p2.samsung.com>
cma_alloc() function has gfp mask parameter, so users expect that it
honors typical memory allocation related flags. The most imporant from
the security point of view is handling of __GFP_ZERO flag, because memory
allocated by this function usually can be directly remapped to userspace
by device drivers as a part of multimedia processing and ignoring this
flag might lead to leaking some kernel structures to userspace.
Some callers of this function (for example arm64 dma-iommu glue code)
already assumed that the allocated buffers are cleared when this flag
is set. To avoid such issues, add simple code for clearing newly
allocated buffer when __GFP_ZERO flag is set. Callers will be then
updated to skip implicit clearing or adjust passed gfp flags.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
mm/cma.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 5809bbe360d7..1106d5aef2cc 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -464,6 +464,13 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
start = bitmap_no + mask + 1;
}
+ if (ret == 0 && gfp_mask & __GFP_ZERO) {
+ int i;
+
+ for (i = 0; i < count; i++)
+ clear_highpage(page + i);
+ }
+
trace_cma_alloc(pfn, page, count, align);
if (ret && !(gfp_mask & __GFP_NOWARN)) {
--
2.17.1
^ permalink raw reply related
* [PATCH 19/28] drm/mediatek: add connection from RDMA2 to DPI1
From: CK Hu @ 2018-06-13 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528880291.11190.45.camel@mtksdccf07>
Hi, Stu:
On Wed, 2018-06-13 at 16:58 +0800, Stu Hsieh wrote:
> Hi, CK:
>
> On Wed, 2018-06-13 at 16:14 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > On Wed, 2018-06-13 at 16:01 +0800, Stu Hsieh wrote:
> > > Hi, CK:
> > >
> > >
> > > On Wed, 2018-06-13 at 15:13 +0800, CK Hu wrote:
> > > > Hi, Stu:
> > > >
> > > > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > > > This patch add the connection from RDMA2 to DPI1
> > > > >
> > > > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > > > ---
> > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > index 31a0832ef9ec..2d883815d79c 100644
> > > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > > > @@ -93,9 +93,11 @@
> > > > > #define RDMA1_MOUT_DPI0 0x2
> > > > > #define RDMA1_MOUT_DPI1 0x3
> > > > > #define RDMA2_MOUT_DPI0 0x2
> > > > > +#define RDMA2_MOUT_DPI1 0x3
> > > >
> > > > Usually, each bit of a mout register represent a output enable. Is this
> > > > value 0x3 a correct value?
> > > >
> > > > Regards,
> > > > CK
> > > >
> > > In HW CONFIG SPEC or MT2712_E2_MMSYS_Change_note show as following:
> > >
> > > Bit(s) Name Description
> > > 2:0 DISP_RDMA2_SOUT_SEL_IN 0: output to dsi0
> > > 1: outptu to dsi1
> > > 2: output to dpi0
> > > 3: output to dpi1
> > > 4: output to dsi2
> > > 5: output to dsi3
> > >
> > > So, 0x3 is correct value.
> >
> > The data sheet use the term SOUT match its function, so I think driver
> > have better change the naming to SOUT.
> >
> > Regards,
> > CK
> >
>
> The definition DISP_REG_CONFIG_DISP_RDMA2_SOUT is use term SOUT in this
> patch.
>
I know, but RDMA2_MOUT_DPI1 should be changed to RDMA2_SOUT_DPI1.
Regards,
CK
> Regard,
> Stu
>
> > >
> > > Regard,
> > > Stu
> > >
> > > > > #define DPI0_SEL_IN_RDMA1 0x1
> > > > > #define DPI0_SEL_IN_RDMA2 0x3
> > > > > #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > > > > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
> > > > > #define DSI1_SEL_IN_RDMA1 0x1
> > > > > #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> > > > > #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> > > > > @@ -199,6 +201,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > > > > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > > > > *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > > > > value = RDMA2_MOUT_DPI0;
> > > > > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > > > > + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > > > > + value = RDMA2_MOUT_DPI1;
> > > > > } else {
> > > > > value = 0;
> > > > > }
> > > > > @@ -233,6 +238,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > > > > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > > > > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > > > value = DPI0_SEL_IN_RDMA2;
> > > > > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > > > > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > > > + value = DPI1_SEL_IN_RDMA2;
> > > > > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > > > > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > > > > value = COLOR1_SEL_IN_OVL1;
> > > >
> > > >
> > >
> > >
> >
> >
>
>
^ permalink raw reply
* [PATCH 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: kbuild test robot @ 2018-06-13 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613161314.14894-3-yixun.lan@amlogic.com>
Hi Liang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mtd/nand/next]
[also build test ERROR on v4.17 next-20180613]
[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/Yixun-Lan/mtd-rawnand-meson-add-Amlogic-NAND-driver-support/20180613-161917
base: git://git.infradead.org/linux-mtd.git nand/next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-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
GCC_VERSION=7.2.0 make.cross ARCH=sparc64
All error/warnings (new ones prefixed by >>):
In file included from drivers/mtd/nand/raw/meson_nand.c:21:0:
>> drivers/clk/meson/clk-regmap.h:22:16: error: field 'hw' has incomplete type
struct clk_hw hw;
^~
>> drivers/mtd/nand/raw/meson_nand.c:951:2: error: field name not in record or union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd/nand/raw/meson_nand.c:951:2: note: (near initialization for 'sd_emmc_c_ext_clk0_sel')
>> drivers/mtd/nand/raw/meson_nand.c:952:4: error: 'struct clk_init_data' has no member named 'name'
.name = "sd_emmc_c_nand_clk_mux",
^~~~
>> drivers/mtd/nand/raw/meson_nand.c:952:11: warning: excess elements in struct initializer
.name = "sd_emmc_c_nand_clk_mux",
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:952:11: note: (near initialization for '(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:953:4: error: 'struct clk_init_data' has no member named 'ops'
.ops = &clk_regmap_mux_ops,
^~~
drivers/mtd/nand/raw/meson_nand.c:953:10: warning: excess elements in struct initializer
.ops = &clk_regmap_mux_ops,
^
drivers/mtd/nand/raw/meson_nand.c:953:10: note: (near initialization for '(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:954:4: error: 'struct clk_init_data' has no member named 'parent_names'
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:954:19: warning: excess elements in struct initializer
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:954:19: note: (near initialization for '(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:955:4: error: 'struct clk_init_data' has no member named 'num_parents'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~~
In file included from include/linux/list.h:9:0,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from include/linux/platform_device.h:14,
from drivers/mtd/nand/raw/meson_nand.c:9:
>> include/linux/kernel.h:71:25: warning: excess elements in struct initializer
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
>> drivers/mtd/nand/raw/meson_nand.c:955:18: note: in expansion of macro 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~
include/linux/kernel.h:71:25: note: (near initialization for '(anonymous)')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
>> drivers/mtd/nand/raw/meson_nand.c:955:18: note: in expansion of macro 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~
>> drivers/mtd/nand/raw/meson_nand.c:956:4: error: 'struct clk_init_data' has no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^~~~~
>> drivers/mtd/nand/raw/meson_nand.c:956:12: error: 'CLK_SET_RATE_PARENT' undeclared here (not in a function); did you mean 'DL_STATE_DORMANT'?
.flags = CLK_SET_RATE_PARENT,
^~~~~~~~~~~~~~~~~~~
DL_STATE_DORMANT
drivers/mtd/nand/raw/meson_nand.c:956:12: warning: excess elements in struct initializer
drivers/mtd/nand/raw/meson_nand.c:956:12: note: (near initialization for '(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:951:37: error: invalid use of undefined type 'struct clk_init_data'
.hw.init = &(struct clk_init_data) {
^
>> drivers/mtd/nand/raw/meson_nand.c:965:12: error: 'CLK_DIVIDER_ROUND_CLOSEST' undeclared here (not in a function); did you mean 'DIV_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
^~~~~~~~~~~~~~~~~~~~~~~~~
DIV_ROUND_CLOSEST
>> drivers/mtd/nand/raw/meson_nand.c:965:40: error: 'CLK_DIVIDER_ONE_BASED' undeclared here (not in a function); did you mean 'CLK_DIVIDER_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
^~~~~~~~~~~~~~~~~~~~~
CLK_DIVIDER_ROUND_CLOSEST
drivers/mtd/nand/raw/meson_nand.c:967:2: error: field name not in record or union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd/nand/raw/meson_nand.c:967:2: note: (near initialization for 'sd_emmc_c_ext_clk0_div')
drivers/mtd/nand/raw/meson_nand.c:968:4: error: 'struct clk_init_data' has no member named 'name'
.name = "sd_emmc_c_nand_clk_div",
^~~~
drivers/mtd/nand/raw/meson_nand.c:968:11: warning: excess elements in struct initializer
.name = "sd_emmc_c_nand_clk_div",
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:968:11: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c:969:4: error: 'struct clk_init_data' has no member named 'ops'
.ops = &clk_regmap_divider_ops,
^~~
drivers/mtd/nand/raw/meson_nand.c:969:10: warning: excess elements in struct initializer
.ops = &clk_regmap_divider_ops,
^
drivers/mtd/nand/raw/meson_nand.c:969:10: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c:970:4: error: 'struct clk_init_data' has no member named 'parent_names'
.parent_names = (const char *[]){ "sd_emmc_c_nand_clk_mux" },
^~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:970:19: warning: excess elements in struct initializer
.parent_names = (const char *[]){ "sd_emmc_c_nand_clk_mux" },
^
drivers/mtd/nand/raw/meson_nand.c:970:19: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c:971:4: error: 'struct clk_init_data' has no member named 'num_parents'
.num_parents = 1,
^~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:971:18: warning: excess elements in struct initializer
.num_parents = 1,
^
drivers/mtd/nand/raw/meson_nand.c:971:18: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c:972:4: error: 'struct clk_init_data' has no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^~~~~
drivers/mtd/nand/raw/meson_nand.c:972:12: warning: excess elements in struct initializer
.flags = CLK_SET_RATE_PARENT,
^~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:972:12: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c: In function 'meson_nfc_clk_init':
>> drivers/mtd/nand/raw/meson_nand.c:1007:38: error: implicit declaration of function '__clk_get_name'; did you mean 'clk_get_rate'? [-Werror=implicit-function-declaration]
sd_emmc_ext_clk0_parent_names[i] = __clk_get_name(clk);
^~~~~~~~~~~~~~
clk_get_rate
>> drivers/mtd/nand/raw/meson_nand.c:1007:36: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
sd_emmc_ext_clk0_parent_names[i] = __clk_get_name(clk);
^
>> drivers/mtd/nand/raw/meson_nand.c:1011:8: error: implicit declaration of function 'devm_clk_register'; did you mean 'device_register'? [-Werror=implicit-function-declaration]
clk = devm_clk_register(nfc->dev, &mux->hw);
^~~~~~~~~~~~~~~~~
device_register
cc1: some warnings being treated as errors
--
In file included from drivers/mtd//nand/raw/meson_nand.c:21:0:
>> drivers/clk/meson/clk-regmap.h:22:16: error: field 'hw' has incomplete type
struct clk_hw hw;
^~
drivers/mtd//nand/raw/meson_nand.c:951:2: error: field name not in record or union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd//nand/raw/meson_nand.c:951:2: note: (near initialization for 'sd_emmc_c_ext_clk0_sel')
drivers/mtd//nand/raw/meson_nand.c:952:4: error: 'struct clk_init_data' has no member named 'name'
.name = "sd_emmc_c_nand_clk_mux",
^~~~
drivers/mtd//nand/raw/meson_nand.c:952:11: warning: excess elements in struct initializer
.name = "sd_emmc_c_nand_clk_mux",
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:952:11: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:953:4: error: 'struct clk_init_data' has no member named 'ops'
.ops = &clk_regmap_mux_ops,
^~~
drivers/mtd//nand/raw/meson_nand.c:953:10: warning: excess elements in struct initializer
.ops = &clk_regmap_mux_ops,
^
drivers/mtd//nand/raw/meson_nand.c:953:10: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:954:4: error: 'struct clk_init_data' has no member named 'parent_names'
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:954:19: warning: excess elements in struct initializer
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:954:19: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:955:4: error: 'struct clk_init_data' has no member named 'num_parents'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~~
In file included from include/linux/list.h:9:0,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from include/linux/platform_device.h:14,
from drivers/mtd//nand/raw/meson_nand.c:9:
>> include/linux/kernel.h:71:25: warning: excess elements in struct initializer
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
drivers/mtd//nand/raw/meson_nand.c:955:18: note: in expansion of macro 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~
include/linux/kernel.h:71:25: note: (near initialization for '(anonymous)')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
drivers/mtd//nand/raw/meson_nand.c:955:18: note: in expansion of macro 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:956:4: error: 'struct clk_init_data' has no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^~~~~
drivers/mtd//nand/raw/meson_nand.c:956:12: error: 'CLK_SET_RATE_PARENT' undeclared here (not in a function); did you mean 'DL_STATE_DORMANT'?
.flags = CLK_SET_RATE_PARENT,
^~~~~~~~~~~~~~~~~~~
DL_STATE_DORMANT
drivers/mtd//nand/raw/meson_nand.c:956:12: warning: excess elements in struct initializer
drivers/mtd//nand/raw/meson_nand.c:956:12: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:951:37: error: invalid use of undefined type 'struct clk_init_data'
.hw.init = &(struct clk_init_data) {
^
drivers/mtd//nand/raw/meson_nand.c:965:12: error: 'CLK_DIVIDER_ROUND_CLOSEST' undeclared here (not in a function); did you mean 'DIV_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
^~~~~~~~~~~~~~~~~~~~~~~~~
DIV_ROUND_CLOSEST
drivers/mtd//nand/raw/meson_nand.c:965:40: error: 'CLK_DIVIDER_ONE_BASED' undeclared here (not in a function); did you mean 'CLK_DIVIDER_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
^~~~~~~~~~~~~~~~~~~~~
CLK_DIVIDER_ROUND_CLOSEST
drivers/mtd//nand/raw/meson_nand.c:967:2: error: field name not in record or union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd//nand/raw/meson_nand.c:967:2: note: (near initialization for 'sd_emmc_c_ext_clk0_div')
drivers/mtd//nand/raw/meson_nand.c:968:4: error: 'struct clk_init_data' has no member named 'name'
.name = "sd_emmc_c_nand_clk_div",
^~~~
drivers/mtd//nand/raw/meson_nand.c:968:11: warning: excess elements in struct initializer
.name = "sd_emmc_c_nand_clk_div",
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:968:11: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:969:4: error: 'struct clk_init_data' has no member named 'ops'
.ops = &clk_regmap_divider_ops,
^~~
drivers/mtd//nand/raw/meson_nand.c:969:10: warning: excess elements in struct initializer
.ops = &clk_regmap_divider_ops,
^
drivers/mtd//nand/raw/meson_nand.c:969:10: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:970:4: error: 'struct clk_init_data' has no member named 'parent_names'
.parent_names = (const char *[]){ "sd_emmc_c_nand_clk_mux" },
^~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:970:19: warning: excess elements in struct initializer
.parent_names = (const char *[]){ "sd_emmc_c_nand_clk_mux" },
^
drivers/mtd//nand/raw/meson_nand.c:970:19: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:971:4: error: 'struct clk_init_data' has no member named 'num_parents'
.num_parents = 1,
^~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:971:18: warning: excess elements in struct initializer
.num_parents = 1,
^
drivers/mtd//nand/raw/meson_nand.c:971:18: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:972:4: error: 'struct clk_init_data' has no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^~~~~
drivers/mtd//nand/raw/meson_nand.c:972:12: warning: excess elements in struct initializer
.flags = CLK_SET_RATE_PARENT,
^~~~~~~~~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:972:12: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c: In function 'meson_nfc_clk_init':
drivers/mtd//nand/raw/meson_nand.c:1007:38: error: implicit declaration of function '__clk_get_name'; did you mean 'clk_get_rate'? [-Werror=implicit-function-declaration]
sd_emmc_ext_clk0_parent_names[i] = __clk_get_name(clk);
^~~~~~~~~~~~~~
clk_get_rate
drivers/mtd//nand/raw/meson_nand.c:1007:36: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
sd_emmc_ext_clk0_parent_names[i] = __clk_get_name(clk);
^
drivers/mtd//nand/raw/meson_nand.c:1011:8: error: implicit declaration of function 'devm_clk_register'; did you mean 'device_register'? [-Werror=implicit-function-declaration]
clk = devm_clk_register(nfc->dev, &mux->hw);
^~~~~~~~~~~~~~~~~
device_register
cc1: some warnings being treated as errors
vim +/hw +22 drivers/clk/meson/clk-regmap.h
ea11dda9 Jerome Brunet 2018-02-12 10
ea11dda9 Jerome Brunet 2018-02-12 11 /**
ea11dda9 Jerome Brunet 2018-02-12 12 * struct clk_regmap - regmap backed clock
ea11dda9 Jerome Brunet 2018-02-12 13 *
ea11dda9 Jerome Brunet 2018-02-12 14 * @hw: handle between common and hardware-specific interfaces
ea11dda9 Jerome Brunet 2018-02-12 15 * @map: pointer to the regmap structure controlling the clock
ea11dda9 Jerome Brunet 2018-02-12 16 * @data: data specific to the clock type
ea11dda9 Jerome Brunet 2018-02-12 17 *
ea11dda9 Jerome Brunet 2018-02-12 18 * Clock which is controlled by regmap backed registers. The actual type of
ea11dda9 Jerome Brunet 2018-02-12 19 * of the clock is controlled by the clock_ops and data.
ea11dda9 Jerome Brunet 2018-02-12 20 */
ea11dda9 Jerome Brunet 2018-02-12 21 struct clk_regmap {
ea11dda9 Jerome Brunet 2018-02-12 @22 struct clk_hw hw;
ea11dda9 Jerome Brunet 2018-02-12 23 struct regmap *map;
ea11dda9 Jerome Brunet 2018-02-12 24 void *data;
ea11dda9 Jerome Brunet 2018-02-12 25 };
ea11dda9 Jerome Brunet 2018-02-12 26
:::::: The code at line 22 was first introduced by commit
:::::: ea11dda9e091aba0fe6497108477699286a2d036 clk: meson: add regmap clocks
:::::: TO: Jerome Brunet <jbrunet@baylibre.com>
:::::: CC: Neil Armstrong <narmstrong@baylibre.com>
---
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: 53278 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/76026361/attachment-0001.gz>
^ permalink raw reply
* [PATCH 1/3] rtc: ftrtc010: switch to devm_rtc_allocate_device
From: Linus Walleij @ 2018-06-13 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-1-alexandre.belloni@bootlin.com>
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> Switch to devm_rtc_allocate_device/rtc_register_device. This allow or
> further improvement and simplifies ftrtc010_rtc_remove().
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/3] rtc: ftrtc010: handle dates after 2106
From: Linus Walleij @ 2018-06-13 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-2-alexandre.belloni@bootlin.com>
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> Use correct types for offset and time and use
> rtc_time64_to_tm/rtc_tm_to_time64 to handle dates after 2106 properly.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/3] rtc: ftrtc010: let the core handle range
From: Linus Walleij @ 2018-06-13 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-3-alexandre.belloni@bootlin.com>
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> The current range handling is highly suspicious. Anyway, let the core
> handle it.
Hmmm. I have datasheets, do you need some input about the hardware?
Something I should patch?
> The RTC has a 32 bit counter on top of days + hh:mm:ss registers.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Maxime Ripard @ 2018-06-13 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAR0TZEp9JfJAf3gmE1v6ig04TZ-NCiXm5_zYdpsQwhuRw@mail.gmail.com>
On Wed, Jun 13, 2018 at 05:16:30PM +0900, Masahiro Yamada wrote:
> Hi.
>
> 2018-06-13 16:26 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
> > On Mon, Jun 11, 2018 at 03:53:41PM +0800, Chen-Yu Tsai wrote:
> >> Hi,
> >>
> >> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
> >> <yamada.masahiro@socionext.com> wrote:
> >> > Hi Maxime,
> >> >
> >> >
> >> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
> >> >> Hi Mike, Stephen,
> >> >>
> >> >> Please merge the following changes for the next merge window, thanks!
> >> >>
> >> >> Maxime
> >> >>
> >> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >> >>
> >> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >> >>
> >> >> are available in the Git repository at:
> >> >>
> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
> >> >>
> >> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
> >> >>
> >> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
> >> >>
> >> >> ----------------------------------------------------------------
> >> >> Allwinner clock changes for 4.18
> >> >>
> >> >> Not a lot of changes for this release, but two quite important features
> >> >> were added: the H6 PRCM clock support, and the needed changes to the R40
> >> >> clock driver to allow for the EMAC to operate.
> >> >>
> >> >> ----------------------------------------------------------------
> >> >> Icenowy Zheng (3):
> >> >> clk: sunxi-ng: add support for H6 PRCM CCU
> >> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
> >> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
> >> >>
> >> >
> >> >
> >> >
> >> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
> >> > not included in the pull request?
> >> >
> >> >
> >> > You said "I've picked it up"
> >> > https://patchwork.kernel.org/patch/10348031/
> >>
> >> It looks like it was accidentally dropped after a rebase.
> >> Not quite sure what happened there. Maxime?
> >
> > I'm not quite sure what happened, sorry, but this should have
> > definitely been part of that PR :/
> >
>
> Stephen offered to pick it up directly for -rc2.
> Is that OK with you?
>
> I am fine if it is well-organized between you and Stephen.
Yep, that definitely works for me.
Sorry again,
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/206a5b4d/attachment.sig>
^ permalink raw reply
* [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: Vadim Lomovtsev @ 2018-06-13 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612.152540.1304714747425091865.davem@davemloft.net>
Sorry for delay.
On Tue, Jun 12, 2018 at 03:25:40PM -0700, David Miller wrote:
> From: Dean Nelson <dnelson@redhat.com>
> Date: Mon, 11 Jun 2018 06:22:14 -0500
>
> > On 06/10/2018 02:35 PM, David Miller wrote:
> >> From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> >> Date: Fri, 8 Jun 2018 02:27:59 -0700
> >>
> >>> + /* Save message data locally to prevent them from
> >>> + * being overwritten by next ndo_set_rx_mode call().
> >>> + */
> >>> + spin_lock(&nic->rx_mode_wq_lock);
> >>> + mode = vf_work->mode;
> >>> + mc = vf_work->mc;
> >>> + vf_work->mc = NULL;
> >
> > If I'm reading this code correctly, I believe nic->rx_mode_work.mc
> > will
> > have been set to NULL before the lock is dropped by
> > nicvf_set_rx_mode_task() and acquired by nicvf_set_rx_mode().
> >
> >
> >>> + spin_unlock(&nic->rx_mode_wq_lock);
> >> At the moment you drop this lock, the memory behind 'mc' can be
> >> freed up by:
> >>
> >>> + spin_lock(&nic->rx_mode_wq_lock);
> >>> + kfree(nic->rx_mode_work.mc);
> >
> > So the kfree() will be called with a NULL pointer and quickly return.
> >
> >
> >> And you'll crash when you dereference it above via
> >> __nicvf_set_rx_mode_task().
> >>
> >
> > I believe the call to kfree() in nicvf_set_rx_mode() is there to free
> > up a mc_list that has been allocated by nicvf_set_rx_mode() during a
> > previous callback to the function, one that has not yet been processed
> > by nicvf_set_rx_mode_task().
> >
> > In this way only the last 'unprocessed' callback to
> > nicvf_set_rx_mode()
> > gets processed should there be multiple callbacks occurring between
> > the
> > times the nicvf_set_rx_mode_task() runs.
> >
> > In my testing with this patch, this is what I see happening.
>
> You're right, my bad.
>
> Patch applied.
Thank you for your time.
WBR,
Vadim
^ permalink raw reply
* [PATCH v3 3/3] arm64/mm: migrate swapper_pg_dir and tramp_pg_dir
From: James Morse @ 2018-06-13 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606043921.19851-4-yaojun8558363@gmail.com>
Hi Jun,
On 06/06/18 05:39, Jun Yao wrote:
> Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
> do not correlate with kernel's address.
This is all to make 'KSMA' harder, where an single arbitrary write is used to
add a block mapping to the page-tables, giving the attacker full access to
physical memory.
This series is pretty complicated, and would still be overcome by arbitrary-read
of __pa_swapper_pg_dir. Any attacker already has to defeat KASLR, but I guess
that can be done without having read-access.
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 94056e064c6f..ba0b55158971 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -637,10 +647,29 @@ static void __init map_kernel(pgd_t *pgdp)
> */
> void __init paging_init(void)
> {
> - phys_addr_t pgd_phys = early_pgtable_alloc();
> - pgd_t *pgdp = pgd_set_fixmap(pgd_phys);
> + phys_addr_t pgd_phys;
> + pgd_t *pgdp;
> + phys_addr_t mem_size;
>
> - __pa_swapper_pg_dir = __pa_symbol(swapper_pg_dir);
> + mem_size = __pa_symbol(swapper_pg_dir) + PAGE_SIZE
> + - (__pa_symbol(idmap_pg_dir) + IDMAP_DIR_SIZE);
> +
> + if (mem_size == PAGE_SIZE) {
> + pgd_phys = early_pgtable_alloc();
This is where we migrated swapper_pg_dir to, its the first memblock_alloc()
call, and is guaranteed to be at the top of memory. Moving this allocation later
will still cause a predictable page to be allocated as this setup code is the
only thing running. I don't think we are in a better position after this series.
Ideally we would put these pgd entries in the read-only section. We only modify
swapper_pg_dir for vmalloc()/vmap() once its generated, which we could do
through a fixmap entry.
Like this, an attacker can find where swapper_pg_dir is, but can't write to it.
(the tricky bit will be breaking swapper_pg_dir up, as we free parts of it)
Thanks,
James
^ permalink raw reply
* [PATCH 3/3] rtc: ftrtc010: let the core handle range
From: Alexandre Belloni @ 2018-06-13 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdabaH2yiYNnQHBru=-Snb3Eeni2eDAa9mjsa-3DqMC72g@mail.gmail.com>
On 13/06/2018 11:10:35+0200, Linus Walleij wrote:
> On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > The current range handling is highly suspicious. Anyway, let the core
> > handle it.
>
> Hmmm. I have datasheets, do you need some input about the hardware?
> Something I should patch?
>
Nothing to do as you seemed to confirm what I did was OK. I could find
why it was set to 2148 in the first place. Maybe it correspond to the
default days, hours minutes, second values on the SoC.
> > The RTC has a 32 bit counter on top of days + hh:mm:ss registers.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: kbuild test robot @ 2018-06-13 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613161314.14894-3-yixun.lan@amlogic.com>
Hi Liang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mtd/nand/next]
[also build test ERROR on v4.17 next-20180613]
[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/Yixun-Lan/mtd-rawnand-meson-add-Amlogic-NAND-driver-support/20180613-161917
base: git://git.infradead.org/linux-mtd.git nand/next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> drivers/mtd/nand/raw/meson_nand.c:21:10: fatal error: clk-regmap.h: No such file or directory
#include "clk-regmap.h"
^~~~~~~~~~~~~~
compilation terminated.
vim +21 drivers/mtd/nand/raw/meson_nand.c
> 21 #include "clk-regmap.h"
22
---
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: 62787 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/043f3907/attachment-0001.gz>
^ permalink raw reply
* [PATCH v1 0/4] add mailbox support for i.MX7D
From: A.s. Dong @ 2018-06-13 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601083411.s35c2floqdas6qni@pengutronix.de>
Hi Robert,
Thanks for the forwarding.
> -----Original Message-----
> From: Robert Schwebel [mailto:r.schwebel at pengutronix.de]
> Sent: Friday, June 1, 2018 4:34 PM
> To: Oleksij Rempel <o.rempel@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>; Fabio Estevam
> <fabio.estevam@nxp.com>; Rob Herring <robh+dt@kernel.org>; Mark
> Rutland <mark.rutland@arm.com>; linux-clk at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; kernel at pengutronix.de;
> devicetree at vger.kernel.org; A.s. Dong <aisheng.dong@nxp.com>; dl-linux-
> imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v1 0/4] add mailbox support for i.MX7D
>
> On Fri, Jun 01, 2018 at 08:58:17AM +0200, Oleksij Rempel wrote:
> > This patches are providing support for mailbox (Messaging Unit) for
> > i.MX7D. Functionality was tested on PHYTEC phyBOARD-Zeta i.MX7D with
> > Linux running on all cores: ARM Cortex-A7 and ARM Cortex-M4.
> >
Thanks for the patch.
> > Both parts of i.MX messaging Unit are visible for all CPUs available
> > on i.MX7D. Communication worked independent of MU side in
> combination
> > with CPU. For example MU-A used on ARM Cortex-A7 and MU-B used on
> ARM
> > Cortex-M4 or other ways around.
> >
> > The question to NXP developers: are there are limitations or
> > recommendations about MU vs CPU combination? The i.MX7D
> documentation
> > talks about "Processor A" and "Processor B". It is not quite clear
> > what processor it actually is (A7 or M4).
The MU vs CPU combination usually are defined by HW design.
It, MU Side A/B, can either be used by both CPU (A core and M core)
or fixed to one side.
For MX7D case, both side memory map can be accessed by both CPU
Including Interrupt signals. But the recommendation is A core using
MU side A and M core using MU side B.
Regards
Dong Aisheng
>
> Adding Dong Aisheng and NXP linux team to Cc:.
>
> rsc
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7Cf53
> d9c9cdd744878740f08d5c79a7a1e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C636634388645464924&sdata=2ehh92tNbfwf3fJTp%2Fx7IUOgGSU
> h6pyrc2XsdRJkTw4%3D&reserved=0 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Suzuki K Poulose @ 2018-06-13 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612204802.GA15817@rob-hp-laptop>
Hi Rob,
On 12/06/18 21:48, Rob Herring wrote:
> On Fri, Jun 01, 2018 at 02:16:05PM +0100, Suzuki K Poulose wrote:
>> The coresight drivers relied on default bindings for graph
>> in DT, while reusing the "reg" field of the "ports" to indicate
>> the actual hardware port number for the connections. However,
>> with the rules getting stricter w.r.t to the address mismatch
>> with the label, it is no longer possible to use the port address
>> field for the hardware port number. Hence, we add an explicit
>> property to denote the hardware port number, "coresight,hwid"
>> which must be specified for each "endpoint".
>>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Rob Herring <robh@kernel.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> .../devicetree/bindings/arm/coresight.txt | 26 +++++++++---
>> drivers/hwtracing/coresight/of_coresight.c | 46 ++++++++++++++++------
>> 2 files changed, 54 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
>> index bd36e40..385581a 100644
>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>> @@ -104,7 +104,11 @@ properties to uniquely identify the connection details.
>> "slave-mode"
>>
>> * Hardware Port number at the component:
>> - - The hardware port number is assumed to be the address of the "port" component.
>> + - (Obsolete) The hardware port number is assumed to be the address of the "port" component.
>> + - Each "endpoint" must define the hardware port of the local end of the
>> + connection using the following property:
>> + "coresight,hwid" - 32bit integer, hardware port number at the local end.
>
> "coresight" is not a vendor and properties are in the form
> [<vendor>,]<prop-name>.
OK. The issue here is that a coresight component could be an Arm IP or
a custom partner IP. So, the vendor could be either arm or the partner id.
However, this property is kind of a generic one for the Coresight family,
which is why we opted for "coresight". What is the guideline for such
cases ?
Or in other words I see the following possible options :
1) coresight,hwid - coresight generic
2) arm,coresight-hwid - arm vendor, however the device could be from any vendor.
3) hwid - Generic
4) none of the above, something completely different.
What do you recommend from the above ?
>> +
>>
>>
>> Example:
>> @@ -120,6 +124,7 @@ Example:
>> etb_in_port: endpoint at 0 {
>
> There shouldn't be a unit address here because there is no reg property.
>
>> slave-mode;
>> remote-endpoint = <&replicator_out_port0>;
>> + coresight,hwid = <0>;
>
> It doesn't make sense for these to be in the endpoint. If you had
> multiple endpoints, then you would have to duplicate it. "ports" are
> a single data stream. "endpoints" are connections to that stream. So if
> you have a muxed (input) or fanout/1-to-many (output) connection, then
> you have multiple endpoints.
We do have many-to-1 input (e.g, funnels) and 1-to-many outputs
(e.g replicators). However, we have (so far) used only one endpoint per
port.
Also we could potentially have multiple data streams flowing through
the ports, which gets filtered to different ports in 1-to-many components
(read programmable-replicator).
So the point is we have a shared path which carries different data
streams with mux/demux components. I am open for suggestions based on
the above facts.
>
> The same applied to the slave-mode property, but that ship has sailed.
> No reason to continue that though.
>
>> };
>> };
>> };
>> @@ -134,6 +139,7 @@ Example:
>> tpiu_in_port: endpoint at 0 {
>> slave-mode;
>> remote-endpoint = <&replicator_out_port1>;
>> + coresight,hwid = <0>;
>> };
>> };
>> };
>> @@ -154,6 +160,7 @@ Example:
>> reg = <0>;
>> replicator_out_port0: endpoint {
>> remote-endpoint = <&etb_in_port>;
>> + coresight,hwid = <0>;
>> };
>> };
>>
>> @@ -161,15 +168,17 @@ Example:
>> reg = <1>;
>> replicator_out_port1: endpoint {
>> remote-endpoint = <&tpiu_in_port>;
>> + coresight,hwid = <1>;
>> };
>> };
>>
>> /* replicator input port */
>> port at 2 {
>> - reg = <0>;
>> + reg = <1>;
>
> This will still get flagged as an error. reg must be 2 here.
Sorry, thats a mistake. I will fix it.
Cheers
Suzuki
^ permalink raw reply
* [PATCH v3 4/6] dmaengine: imx-sdma: remove usless lock
From: Sascha Hauer @ 2018-06-13 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528729173-28684-5-git-send-email-yibin.gong@nxp.com>
On Mon, Jun 11, 2018 at 10:59:31PM +0800, Robin Gong wrote:
> No need anymore for 'lock' now since virtual dma will provide
> the common lock instead.
This can be merged into the last patch, maybe rephrasing the commit
message from "revert..." to what is being done. To me "revert" sounds
like the commit was wrong, but it wasn't at that time.
Sascha
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> drivers/dma/imx-sdma.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index e0af8ee..f150b38 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -349,7 +349,6 @@ struct sdma_channel {
> unsigned long event_mask[2];
> unsigned long watermark_level;
> u32 shp_addr, per_addr;
> - spinlock_t lock;
> enum dma_status status;
> struct imx_dma_data data;
> };
> @@ -1907,7 +1906,6 @@ static int sdma_probe(struct platform_device *pdev)
> struct sdma_channel *sdmac = &sdma->channel[i];
>
> sdmac->sdma = sdma;
> - spin_lock_init(&sdmac->lock);
>
> sdmac->channel = i;
> sdmac->vc.desc_free = sdma_desc_free;
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Bob Ham @ 2018-06-13 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d041794-ba90-a9a6-0886-0ca18dab62b9@redhat.com>
On 13/06/18 08:28, Hans de Goede wrote:
> On 05-06-18 20:18, Bob Ham wrote:
>> It's a fine point but it makes me nervous.? I originally based my .dts
>> on sun4i-a10-inet1.dts.? I've CC'd the original copyright holder, Hans
>> de Goede.? Hans, are you willing to give permission for the license
>> notice to be replaced with just an SPDX header indicating the dual
>> licensing?
>
> Yes that is fine by me and you've my permission to switch to using
> just the SPDX header.
Excellent, thanks! :-)
--
Bob Ham <rah@settrans.net>
for (;;) { ++pancakes; }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2913 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/b4d4d5c8/attachment.sig>
^ permalink raw reply
* [PATCH v3 5/6] dmaengine: imx-sdma: remove the maximum limation for bd numbers
From: Sascha Hauer @ 2018-06-13 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528729173-28684-6-git-send-email-yibin.gong@nxp.com>
In the subject: s/limation/limitation/
Sascha
On Mon, Jun 11, 2018 at 10:59:32PM +0800, Robin Gong wrote:
> No this limitation now after virtual dma used since bd is allocated
> dynamically instead of static.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> drivers/dma/imx-sdma.c | 14 --------------
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index f150b38..0b0588d2 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -292,7 +292,6 @@ struct sdma_context_data {
> u32 scratch7;
> } __attribute__ ((packed));
>
> -#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
>
> struct sdma_engine;
>
> @@ -1296,13 +1295,6 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
> if (ret)
> goto err_bd_out;
>
> - if (sg_len > NUM_BD) {
> - dev_err(sdma->dev, "SDMA channel %d: maximum number of sg exceeded: %d > %d\n",
> - channel, sg_len, NUM_BD);
> - ret = -EINVAL;
> - goto err_bd_out;
> - }
> -
> desc->chn_count = 0;
> for_each_sg(sgl, sg, sg_len, i) {
> struct sdma_buffer_descriptor *bd = &desc->bd[i];
> @@ -1412,12 +1404,6 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
> if (ret)
> goto err_bd_out;
>
> - if (num_periods > NUM_BD) {
> - dev_err(sdma->dev, "SDMA channel %d: maximum number of sg exceeded: %d > %d\n",
> - channel, num_periods, NUM_BD);
> - goto err_bd_out;
> - }
> -
> if (period_len > 0xffff) {
> dev_err(sdma->dev, "SDMA channel %d: maximum period size exceeded: %zu > %d\n",
> channel, period_len, 0xffff);
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ 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