* [PATCH v2 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER)
From: Laura Abbott @ 2017-12-04 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512059986-21325-1-git-send-email-will.deacon@arm.com>
On 11/30/2017 08:39 AM, Will Deacon wrote:
> Hi again,
>
> This is version two of the patches previously posted here:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/542751.html
>
> Changes since v1 include:
>
> * Based on v4.15-rc1
> * Trampoline moved into FIXMAP area
> * Explicit static key replaced by cpu cap
> * Disable SPE for userspace profiling if kernel unmapped at EL0
> * Changed polarity of cpu feature to match config option
> * Changed command-line option so we can force on in future if necessary
> * Changed Falkor workaround to invalidate different page within 2MB region
> * Reworked alternative sequences in entry.S, since the NOP slides with
> kaiser=off were measurable
>
> I experimented with leaving the vbar set to point at the kaiser vectors,
> but I couldn't measure any performance improvement from that and it made
> the code slightly more complicated, so I've left it as-is.
>
> Patches based on 4.15-rc1 and also pushed here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kaiser
>
> Feedback welcome, particularly on a better name for the command-line option.
>
I ran this with one of the LTP mmap tests over the weekend. The mmap
test completed successfully but later the machine was spewing I/O
errors. I think this is because of the hardware and not the patches
so I'm running again for good measure.
> Will
>
> --->8
>
> Will Deacon (18):
> arm64: mm: Use non-global mappings for kernel space
> arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN
> arm64: mm: Move ASID from TTBR0 to TTBR1
> arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum
> #E1003
> arm64: mm: Rename post_ttbr0_update_workaround
> arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN
> arm64: mm: Allocate ASIDs in pairs
> arm64: mm: Add arm64_kernel_unmapped_at_el0 helper
> arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI
> arm64: entry: Add exception trampoline page for exceptions from EL0
> arm64: mm: Map entry trampoline into trampoline and kernel page tables
> arm64: entry: Explicitly pass exception level to kernel_ventry macro
> arm64: entry: Hook up entry trampoline to exception vectors
> arm64: erratum: Work around Falkor erratum #E1003 in trampoline code
> arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native
> tasks
> arm64: entry: Add fake CPU feature for unmapping the kernel at EL0
> arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0
> perf: arm_spe: Disallow userspace profiling when
> arm_kernel_unmapped_at_el0()
>
> arch/arm64/Kconfig | 30 +++--
> arch/arm64/include/asm/asm-uaccess.h | 25 +++--
> arch/arm64/include/asm/assembler.h | 27 +----
> arch/arm64/include/asm/cpucaps.h | 3 +-
> arch/arm64/include/asm/fixmap.h | 4 +
> arch/arm64/include/asm/kernel-pgtable.h | 12 +-
> arch/arm64/include/asm/mmu.h | 10 ++
> arch/arm64/include/asm/mmu_context.h | 9 +-
> arch/arm64/include/asm/pgtable-hwdef.h | 1 +
> arch/arm64/include/asm/pgtable-prot.h | 21 +++-
> arch/arm64/include/asm/pgtable.h | 1 +
> arch/arm64/include/asm/proc-fns.h | 6 -
> arch/arm64/include/asm/tlbflush.h | 16 ++-
> arch/arm64/include/asm/uaccess.h | 21 +++-
> arch/arm64/kernel/asm-offsets.c | 6 +-
> arch/arm64/kernel/cpufeature.c | 41 +++++++
> arch/arm64/kernel/entry.S | 190 +++++++++++++++++++++++++++-----
> arch/arm64/kernel/process.c | 12 +-
> arch/arm64/kernel/vmlinux.lds.S | 17 +++
> arch/arm64/lib/clear_user.S | 2 +-
> arch/arm64/lib/copy_from_user.S | 2 +-
> arch/arm64/lib/copy_in_user.S | 2 +-
> arch/arm64/lib/copy_to_user.S | 2 +-
> arch/arm64/mm/cache.S | 2 +-
> arch/arm64/mm/context.c | 36 +++---
> arch/arm64/mm/mmu.c | 23 ++++
> arch/arm64/mm/proc.S | 12 +-
> arch/arm64/xen/hypercall.S | 2 +-
> drivers/perf/arm_spe_pmu.c | 7 ++
> 29 files changed, 407 insertions(+), 135 deletions(-)
>
^ permalink raw reply
* [linux-sunxi] [PATCH 0/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks
From: André Przywara @ 2017-12-04 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204051912.7485-1-wens@csie.org>
On 04/12/17 05:19, Chen-Yu Tsai wrote:
> Hi,
>
> This is a small fix to get MMC performance up to proper speeds on the
Maybe a small fix for a skilled developer, but a giant leap for all
users ;-)
MMC performance goes from: (4.15-rc1)
SD: Timing buffered disk reads: 36 MB in 3.17 seconds = 11.35 MB/sec
eMMC: Timing buffered disk reads: 66 MB in 3.03 seconds = 21.81 MB/sec
to: (4.15-rc2 plus those two patches)
SD: Timing buffered disk reads: 68 MB in 3.01 seconds = 22.61 MB/sec
eMMC: Timing buffered disk reads: 132 MB in 3.01 seconds = 43.80 MB/sec
So yes, factor of two ...
Tested-by: Andre Przywara <andre.przywara@arm.com>
Given the impact I wonder if this is a candidate for stable as well.
> A64. According to the BSP kernel, the MMC module clocks have a /2 fixed
> post-divider between the clock output and the MMC module, like what
> we've seen with the "new MMC timing mode" on the A83T, but the A64 does
> not have the mode switch.
>
> Sub-par performance was observed on the Banana Pi M64 eMMC. It only
> reached half the read throughput of other Banana Pi boards, using a
> standard sequential readout with a large block size. After these
> patches, the performance is up to spec.
>
> The A64 can also do DDR transfer modes, but the clock delay config
> registers in the MMC module are different from what we've seen so
> far.
But the BSP doesn't set those as well, does it? I mean to remember that
they were all zero, expect for HS200/HS400?
Thanks!
Andre.
One can just force enable DDR modes without tuning the delays,
> and it does work. Proper support for this is left for another time.
>
>
> ChenYu
>
> Chen-Yu Tsai (2):
> clk: sunxi-ng: Support fixed post-dividers on MP style clocks
> clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module
> clocks
>
> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 +++++++++++++++++++++++------------
> drivers/clk/sunxi-ng/ccu_mp.c | 20 ++++++++++--
> drivers/clk/sunxi-ng/ccu_mp.h | 24 +++++++++++++++
> 3 files changed, 79 insertions(+), 22 deletions(-)
>
^ permalink raw reply
* [linux-sunxi] [PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks
From: André Przywara @ 2017-12-04 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204051912.7485-3-wens@csie.org>
On 04/12/17 05:19, Chen-Yu Tsai wrote:
> On the A64, the MMC module clocks are fixed in the new timing mode,
> i.e. they do not have a bit to select the mode. These clocks have
> a 2x divider somewhere between the clock and the MMC module.
>
> To be consistent with other SoCs supporting the new timing mode,
> we model the 2x divider as a fixed post-divider on the MMC module
> clocks.
>
> This patch adds the post-dividers to the MMC clocks.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 +++++++++++++++++++++++------------
> 1 file changed, 37 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> index 2bb4cabf802f..ee9c12cf3f08 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> @@ -400,28 +400,45 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", mod0_default_parents, 0x080,
> BIT(31), /* gate */
> 0);
>
> +/*
> + * MMC clocks are the new timing mode (see A83T & H3) variety, but without
> + * the mode switch. This means they have a 2x post divider between the clock
> + * and the MMC module. This is not documented in the manual, but is taken
> + * into consideration when setting the mmc module clocks in the BSP kernel.
> + * Without it, MMC performance is degraded.
> + *
> + * We model it here to be consistent with other SoCs supporting this mode.
> + * The alternative would be to add the 2x multiplier when setting the MMC
> + * module clock in the MMC driver, just for the A64.
> + */
> static const char * const mmc_default_parents[] = { "osc24M", "pll-periph0-2x",
> "pll-periph1-2x" };
> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", mmc_default_parents, 0x088,
> - 0, 4, /* M */
> - 16, 2, /* P */
> - 24, 2, /* mux */
> - BIT(31), /* gate */
> - 0);
> -
> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", mmc_default_parents, 0x08c,
> - 0, 4, /* M */
> - 16, 2, /* P */
> - 24, 2, /* mux */
> - BIT(31), /* gate */
> - 0);
> -
> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mmc_default_parents, 0x090,
> - 0, 4, /* M */
> - 16, 2, /* P */
> - 24, 2, /* mux */
> - BIT(31), /* gate */
> - 0);
> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc0_clk, "mmc0",
> + mmc_default_parents, 0x088,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 2, /* post-div */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc1_clk, "mmc1",
> + mmc_default_parents, 0x08c,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 2, /* post-div */
> + 0);
> +
> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc2_clk, "mmc2",
> + mmc_default_parents, 0x090,
> + 0, 4, /* M */
> + 16, 2, /* P */
> + 24, 2, /* mux */
> + BIT(31), /* gate */
> + 2, /* post-div */
> + 0);
>
> static const char * const ts_parents[] = { "osc24M", "pll-periph0", };
> static SUNXI_CCU_MP_WITH_MUX_GATE(ts_clk, "ts", ts_parents, 0x098,
>
^ permalink raw reply
* [linux-sunxi] [PATCH 1/2] clk: sunxi-ng: Support fixed post-dividers on MP style clocks
From: André Przywara @ 2017-12-04 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204051912.7485-2-wens@csie.org>
Hi Chen-Yu,
On 04/12/17 05:19, Chen-Yu Tsai wrote:
> On the A64, the MMC module clocks are fixed in the new timing mode,
> i.e. they do not have a bit to select the mode. These clocks have
> a 2x divider somewhere between the clock and the MMC module.
>
> To be consistent with other SoCs supporting the new timing mode,
> we model the 2x divider as a fixed post-divider on the MMC module
> clocks.
>
> To do this, we first add fixed post-divider to the MP style clocks,
> which the MMC module clocks are.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/clk/sunxi-ng/ccu_mp.c | 20 ++++++++++++++++++--
> drivers/clk/sunxi-ng/ccu_mp.h | 24 ++++++++++++++++++++++++
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
> index 688855e7dc8c..5d0af4051737 100644
> --- a/drivers/clk/sunxi-ng/ccu_mp.c
> +++ b/drivers/clk/sunxi-ng/ccu_mp.c
> @@ -50,12 +50,19 @@ static unsigned long ccu_mp_round_rate(struct ccu_mux_internal *mux,
> unsigned int max_m, max_p;
> unsigned int m, p;
>
> + if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
> + rate *= cmp->fixed_post_div;
Can't you just initialise fixed_post_div to 1 normally and save the
CCU_FEATURE_FIXED_POSTDIV?
> +
> max_m = cmp->m.max ?: 1 << cmp->m.width;
> max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
>
> ccu_mp_find_best(*parent_rate, rate, max_m, max_p, &m, &p);
> + rate = *parent_rate / p / m;
> +
> + if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
> + rate /= cmp->fixed_post_div;
>
> - return *parent_rate / p / m;
> + return rate;
> }
>
> static void ccu_mp_disable(struct clk_hw *hw)
> @@ -83,6 +90,7 @@ static unsigned long ccu_mp_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
> {
> struct ccu_mp *cmp = hw_to_ccu_mp(hw);
> + unsigned long rate;
> unsigned int m, p;
> u32 reg;
>
> @@ -101,7 +109,11 @@ static unsigned long ccu_mp_recalc_rate(struct clk_hw *hw,
> p = reg >> cmp->p.shift;
> p &= (1 << cmp->p.width) - 1;
>
> - return (parent_rate >> p) / m;
> + rate = (parent_rate >> p) / m;
> + if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
> + rate /= cmp->fixed_post_div;
> +
> + return rate;
> }
>
> static int ccu_mp_determine_rate(struct clk_hw *hw,
> @@ -129,6 +141,10 @@ static int ccu_mp_set_rate(struct clk_hw *hw, unsigned long rate,
> max_m = cmp->m.max ?: 1 << cmp->m.width;
> max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
>
> + /* Adjust target rate according to post-dividers */
> + if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV)
> + rate = rate * cmp->fixed_post_div;
> +
> ccu_mp_find_best(parent_rate, rate, max_m, max_p, &m, &p);
>
> spin_lock_irqsave(cmp->common.lock, flags);
> diff --git a/drivers/clk/sunxi-ng/ccu_mp.h b/drivers/clk/sunxi-ng/ccu_mp.h
> index aaef11d747ea..5107635e61de 100644
> --- a/drivers/clk/sunxi-ng/ccu_mp.h
> +++ b/drivers/clk/sunxi-ng/ccu_mp.h
> @@ -33,9 +33,33 @@ struct ccu_mp {
> struct ccu_div_internal m;
> struct ccu_div_internal p;
> struct ccu_mux_internal mux;
> +
> + unsigned int fixed_post_div;
> +
> struct ccu_common common;
> };
>
> +#define SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(_struct, _name, _parents, _reg, \
> + _mshift, _mwidth, \
> + _pshift, _pwidth, \
> + _muxshift, _muxwidth, \
> + _gate, _postdiv, _flags) \
> + struct ccu_mp _struct = { \
> + .enable = _gate, \
> + .m = _SUNXI_CCU_DIV(_mshift, _mwidth), \
> + .p = _SUNXI_CCU_DIV(_pshift, _pwidth), \
> + .mux = _SUNXI_CCU_MUX(_muxshift, _muxwidth), \
> + .fixed_post_div = _postdiv, \
> + .common = { \
> + .reg = _reg, \
> + .features = CCU_FEATURE_FIXED_POSTDIV, \
> + .hw.init = CLK_HW_INIT_PARENTS(_name, \
> + _parents, \
> + &ccu_mp_ops, \
> + _flags), \
> + } \
> + }
> +
This looks suspiciously like a copy of the macro below. What about you
define the one below as a special case of this new one above?
Should be even more straightforward with defaulting postdiv to 1 and
loosing the feature flags.
Cheers,
Andre.
> #define SUNXI_CCU_MP_WITH_MUX_GATE(_struct, _name, _parents, _reg, \
> _mshift, _mwidth, \
> _pshift, _pwidth, \
>
^ permalink raw reply
* [PATCH v2 4/8] clocksource: owl: Prepare S700
From: Andreas Färber @ 2017-12-04 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171113233427.5386-5-afaerber@suse.de>
Hi Daniel,
Am 14.11.2017 um 00:34 schrieb Andreas F?rber:
> Actions S700 has two 2Hz timers like S500, and four TIMx timers like S900.
>
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
> ---
> v1 -> v2:
> * Adopted TIMER_OF_DECLARE() (Daniel)
>
> drivers/clocksource/owl-timer.c | 1 +
> 1 file changed, 1 insertion(+)
Are you planning to queue this v2 patch for 4.16?
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH 1/3] dt-bindings: pwm: update bindings for the Meson-AXG
From: Rob Herring @ 2017-12-04 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204060018.8856-2-yixun.lan@amlogic.com>
On Mon, Dec 04, 2017 at 02:00:16PM +0800, Yixun Lan wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Update the doc to explicitly support Meson-AXG
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> Documentation/devicetree/bindings/pwm/pwm-meson.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: thermal/armada: describe AP806 and CP110
From: Rob Herring @ 2017-12-04 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f8c589337a4fb78852eadf15058e8f8d132d4dc0.1512299484.git.baruch@tkos.co.il>
On Sun, Dec 03, 2017 at 01:11:21PM +0200, Baruch Siach wrote:
> Add compatible strings for AP806 and CP110 that are part of the Armada 8k/7k
> line of SoCs.
>
> Add a note on the difference in the size of the control area in different
> bindings. This is an existing difference between the Armada 375 binding and
> the rest. The new AP806 and CP110 bindings are similar to the existing Armada
> 375 in this regard.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> v2: No change
> ---
> Documentation/devicetree/bindings/thermal/armada-thermal.txt | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] pinctrl: gemini: Support drive strength setting
From: Rob Herring @ 2017-12-04 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171202112309.5726-1-linus.walleij@linaro.org>
On Sat, Dec 02, 2017 at 12:23:09PM +0100, Linus Walleij wrote:
> The Gemini pin controller can set drive strength for a few
> select groups of pins (not individually). Implement this
> for GMAC0 and 1 (ethernet ports), IDE and PCI.
>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> The DT binding part is just using generic bindings, so should be
> pretty uncontroversial.
> ---
> .../bindings/pinctrl/cortina,gemini-pinctrl.txt | 3 +
> drivers/pinctrl/pinctrl-gemini.c | 81 ++++++++++++++++++++++
> 2 files changed, 84 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH net-next 1/2 v6] net: ethernet: Add DT bindings for the Gemini ethernet
From: Rob Herring @ 2017-12-04 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171202110640.5284-1-linus.walleij@linaro.org>
On Sat, Dec 02, 2017 at 12:06:39PM +0100, Linus Walleij wrote:
> This adds the device tree bindings for the Gemini ethernet
> controller. It is pretty straight-forward, using standard
> bindings and modelling the two child ports as child devices
> under the parent ethernet controller device.
>
> Cc: devicetree at vger.kernel.org
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Cc: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../bindings/net/cortina,gemini-ethernet.txt | 92 ++++++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
>
> diff --git a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
> new file mode 100644
> index 000000000000..35fa3abd1c73
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
> @@ -0,0 +1,92 @@
> +Cortina Systems Gemini Ethernet Controller
> +==========================================
> +
> +This ethernet controller is found in the Gemini SoC family:
> +StorLink SL3512 and SL3516, also known as Cortina Systems
> +CS3512 and CS3516.
> +
> +Required properties:
> +- compatible: must be "cortina,gemini-ethernet"
> +- reg: must contain the global registers and the V-bit and A-bit
> + memory areas, in total three register sets.
> +- syscon: a phandle to the system controller
> +- #address-cells: must be specified, must be <1>
> +- #size-cells: must be specified, must be <1>
> +- ranges: should be state like this giving a 1:1 address translation
> + for the subnodes
> +
> +The subnodes represents the two ethernet ports in this device.
> +They are not independent of each other since they share resources
> +in the parent node, and are thus children.
> +
> +Required subnodes:
> +- port0: contains the resources for ethernet port 0
> +- port1: contains the resources for ethernet port 1
> +
> +Required subnode properties:
> +- compatible: must be "cortina,gemini-ethernet-port"
> +- reg: must contain two register areas: the DMA/TOE memory and
> + the GMAC memory area of the port
> +- interrupts: should contain the interrupt line of the port.
> + this is nominally a level interrupt active high.
> +- resets: this must provide an SoC-integrated reset line for
> + the port.
> +- clocks: this should contain a handle to the PCLK clock for
> + clocking the silicon in this port
> +- clock-names: must be "PCLK"
> +
> +Optional subnode properties:
> +- phy-mode: see ethernet.txt
> +- phy-handle: see ethernet.txt
> +
> +Example:
> +
> +mdio-bus {
> + (...)
> + phy0: ethernet-phy at 1 {
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
> + phy1: ethernet-phy at 3 {
> + reg = <3>;
> + device_type = "ethernet-phy";
> + };
> +};
> +
> +
> +ethernet at 60000000 {
> + compatible = "cortina,gemini-ethernet";
> + reg = <0x60000000 0x4000>, /* Global registers, queue */
> + <0x60004000 0x2000>, /* V-bit */
> + <0x60006000 0x2000>; /* A-bit */
> + syscon = <&syscon>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
Would be better to define the actual range used by child nodes.
> +
> + gmac0: port0 {
Needs a unit-address. Building with W=1 (or W=2) will tell you this.
As port is used by the OF graph binding, use ethernet-port at ... instead.
> + compatible = "cortina,gemini-ethernet-port";
> + reg = <0x60008000 0x2000>, /* Port 0 DMA/TOE */
> + <0x6000a000 0x2000>; /* Port 0 GMAC */
> + interrupt-parent = <&intcon>;
> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
> + resets = <&syscon GEMINI_RESET_GMAC0>;
> + clocks = <&syscon GEMINI_CLK_GATE_GMAC0>;
> + clock-names = "PCLK";
> + phy-mode = "rgmii";
> + phy-handle = <&phy0>;
> + };
> +
> + gmac1: port1 {
> + compatible = "cortina,gemini-ethernet-port";
> + reg = <0x6000c000 0x2000>, /* Port 1 DMA/TOE */
> + <0x6000e000 0x2000>; /* Port 1 GMAC */
> + interrupt-parent = <&intcon>;
> + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
> + resets = <&syscon GEMINI_RESET_GMAC1>;
> + clocks = <&syscon GEMINI_CLK_GATE_GMAC1>;
> + clock-names = "PCLK";
> + phy-mode = "rgmii";
> + phy-handle = <&phy1>;
> + };
> +};
> --
> 2.14.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V5 4/7] OF: properties: Implement get_match_data() callback
From: Rob Herring @ 2017-12-04 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <590f0536-b73d-ee32-a284-32e564af2f57@codeaurora.org>
On Mon, Dec 04, 2017 at 01:05:51PM -0500, Sinan Kaya wrote:
> On 12/4/2017 11:23 AM, Rob Herring wrote:
> > On Fri, Dec 1, 2017 at 10:27 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> >> Now that we have a get_match_data() callback as part of the firmware node,
> >> implement the OF specific piece for it.
> >>
> >> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> >> ---
> >> drivers/of/property.c | 17 +++++++++++++++++
> >> 1 file changed, 17 insertions(+)
> >>
> ..
>
> >>
> >> +void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode,
> >> + const struct device_driver *drv)
> >> +{
> >> + const struct device_node *node = to_of_node(fwnode);
> >> + const struct of_device_id *match;
> >> +
> >> + if (!node)
> >> + return NULL;
> >
> > of_match_node checks this.
>
> I see a check for the matches argument but not for the node argument.
> Am I missing something?
Ah yes, you are right.
>
> >
> >> +
> >> + match = of_match_node(drv->of_match_table, node);
> >> + if (!match)
> >> + return NULL;
> >> +
> >> + return (void *)match->data;
> >
> > Don't need a cast here.
>
> I can fix this.
>
> >
> > of_device_get_match_data() already does most of this, but getting a
> > device ptr from fwnode_handle may not be possible?
>
> I couldn't figure out how to do that. Do you have a suggestion?
> I have been looking for examples with no luck.
Change the property API to pass struct device instead. That's maybe not
worth it.
Rob
^ permalink raw reply
* [PATCH V5 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
From: Rob Herring @ 2017-12-04 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512188864-773-2-git-send-email-okaya@codeaurora.org>
On Fri, Dec 01, 2017 at 11:27:38PM -0500, Sinan Kaya wrote:
> A new version of the HIDMA IP has been released with bug fixes. Bumping the
> hardware version to differentiate from others.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> index 55492c2..5d93d6d 100644
> --- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> @@ -47,8 +47,8 @@ When the OS is not in control of the management interface (i.e. it's a guest),
> the channel nodes appear on their own, not under a management node.
>
> Required properties:
> -- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
> -for MSI capable HW.
> +- compatible: must contain "qcom,hidma-1.0" for initial HW or
> + "qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
Hopefully 1.2 corresponds to some actual version numbering and not just
something you made up. I'd really rather have SoC based compatible
strings unless you have dozens of SoCs for each version. I'll probably
just say the same thing again when 1.3 or 2.0 gets added...
Reviewed-by: Rob Herring <robh@kernel.org>
> - reg: Addresses for the transfer and event channel
> - interrupts: Should contain the event interrupt
> - desc-count: Number of asynchronous requests this channel can handle
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH V5 2/7] ACPI / bus: Introduce acpi_get_match_data() function
From: Sinan Kaya @ 2017-12-04 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0gCkY80+A=cZKzhKhxKObSgqN3k1JGgGQgW5cwRSvqt_Q@mail.gmail.com>
On 12/4/2017 4:59 PM, Rafael J. Wysocki wrote:
> On Sat, Dec 2, 2017 at 5:27 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> OF has of_device_get_match_data() function to extract driver specific data
>> structure. Add a similar function for ACPI.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Haven't I ACKed this already?
>
> Anyway, please resend the whole series with a CC to linux-acpi.
Yeah, you acked the previous one. Then, I changed the calling parameter from
struct device to struct acpi_device and removed your ACK.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V5 2/7] ACPI / bus: Introduce acpi_get_match_data() function
From: Rafael J. Wysocki @ 2017-12-04 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512188864-773-3-git-send-email-okaya@codeaurora.org>
On Sat, Dec 2, 2017 at 5:27 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> OF has of_device_get_match_data() function to extract driver specific data
> structure. Add a similar function for ACPI.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Haven't I ACKed this already?
Anyway, please resend the whole series with a CC to linux-acpi.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 0/4] Move DP phy switch to PHY driver
From: Heiko Stübner @ 2017-12-04 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=XVCCbh6P-WweccyKiNy2RJRhqY-6gpf7BVkY4oqdDZbg@mail.gmail.com>
Hi,
Am Montag, 4. Dezember 2017, 08:08:31 CET schrieb Doug Anderson:
> On Sun, Dec 3, 2017 at 11:46 PM, Heiko St?bner <heiko@sntech.de> wrote:
> > Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> >> On 2017?12?02? 05:58, Heiko Stuebner wrote:
> >> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> >> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong <zyw@rock-chips.com>
wrote:
> >> >>> Thank you for mentioning this patch.
> >> >>>
> >> >>> I think the focus of the discussion is: can we put the grf control
> >> >>> bit
> >> >>> to
> >> >>> dts.
> >> >>>
> >> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
> >> >>> "uphy_dp_sel"
> >> >>>
> >> >>> can help to switch these 2 phy. So I think this bit can be considered
> >> >>> as
> >> >>> a
> >> >>> part of
> >> >>>
> >> >>> Type-C phy, these 2 phy have different bits, just similar to other
> >> >>> bits
> >> >>> (such as "pipe-status").
> >> >>>
> >> >>> Put them to DTS file might be a accepted practice.
> >> >>
> >> >> I guess the first step would be finding the person to make a decision.
> >> >> Is that Heiko? Olof? Kishon? Rob?. As I see it there are a few
> >> >> options:
> >> >>
> >> >> 1. Land this series as-is. This makes the new bit work just like all
> >> >> the other ones next to it. If anyone happens to try to use an old
> >> >> device tree on a new kernel they'll break. Seems rather unlikely
> >> >> given that the whole type C PHY is not really fully functional
> >> >> upstream, but technically this is a no-no from a device tree
> >> >> perspective.
> >> >>
> >> >> 2. Change the series to make this property optional. If it's not
> >> >> there then the code behaves like it always did. This would address
> >> >> the "compatibility" problem but likely wouldn't actually help any real
> >> >> people, and it would be extra work.
> >> >>
> >> >> 3. Redo the driver to deprecate all the old offsets / bits and just
> >> >> put the table in the driver, keyed off the compatible string and base
> >> >> address if the IO memory.
> >> >>
> >> >>
> >> >> I can't make this decision. It's up to those folks who would be
> >> >> landing the patch and I'd be happy with any of them. What I'm less
> >> >> happy with, however, is the indecision preventing forward progress.
> >> >> We should pick one of the above things and land it. My own personal
> >> >> bias is #1: just land the series. No real people will be hurt and
> >> >> it's just adding another property that matches the ones next to it.
> >> >
> >> > I'd second that #1 . That whole type-c phy thingy never fully worked in
> >> > the past (some for the never used dp output), so personally I don't
> >> > have
> >> > issues with going that route.
> >> >
> >> >> From a long term perspective (AKA how I'd write the next driver like
> >> >>
> >> >> this) I personally lean towards to "tables in the driver, not in the
> >> >> device tree" but quite honestly I'm happy to take whatever direction
> >> >> the maintainers give.
> >> >
> >> > It looks like we're in agreement here :-) . GRF stuff should not leak
> >> > into
> >> > the devicetree, as it causes endless headaches later. But I guess we'll
> >> > need to live with the ones that happened so far.
> >>
> >> So, the first step is: move all the private property of tcphy to
> >> drivers/phy/rockchip/phy-rockchip-typec.c.
> >> Second step: new a member: uphy-dp-sel.
> >> In my mind, we should have discussed these properties before, and then I
> >> moved them all into DTS.
> >
> > Actually, I was agreeing with Doug, that we probably don't need to rework
> > the type-c phy driver. As most properties for it are in the devicetree
> > right now we'll need to support them for backwards-compatiblity anyway.
> >
> > And yes, there probably was discussion over dts vs. driver-table when the
> > type-c driver was introduced, but I either missed it or wasn't firm enough
> > back then ;-) .
> >
> > Hence the "we'll need to live with it" for the type-c phy, but should not
> > do similar things in future drivers.
>
> So I guess now we're just waiting for some agreement from Kishon that
> he's willing to land the PHY change? Heiko: presumably you could
> apply the DP change to drm-misc? ...or is there some other process
> needed there?
I was lagging behind a bit with the drm-misc account request but have
done so now. So once I got the hang of how drm-misc works and Kishon
has picked the phy-part I can most likely push the drm part (or Sandy,
depending on who is faster).
As for process, I don't think there is special care necessary. When
you get the intermediate case of phy-change but no drm-change
everything will just revert to how it works now anyway.
Heiko
^ permalink raw reply
* [PATCH v6 12/13] ASoC: add bindings for stm32 DFSDM filter
From: Rob Herring @ 2017-12-04 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512150020-20335-13-git-send-email-arnaud.pouliquen@st.com>
On Fri, Dec 01, 2017 at 06:40:19PM +0100, Arnaud Pouliquen wrote:
> Add bindings that describes audio settings to support
> Digital Filter for pulse density modulation(PDM) microphone.
>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> ---
> .../devicetree/bindings/sound/st,stm32-adfsdm.txt | 62 ++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Rob Herring @ 2017-12-04 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201120708.30129-1-matthias.bgg@gmail.com>
On Fri, Dec 01, 2017 at 01:07:06PM +0100, Matthias Brugger wrote:
> The ethsys registers a reset controller, so we need to specify a
> reset cell. This patch fixes the documentation.
>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> 1 file changed, 1 insertion(+)
For all 3,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/6] dt-bindings: marvell: Add documentation for the North Bridge PM on Armada 37xx
From: Rob Herring @ 2017-12-04 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201112508.14121-2-gregory.clement@free-electrons.com>
On Fri, Dec 01, 2017 at 12:25:03PM +0100, Gregory CLEMENT wrote:
> Extend the documentation of the Armada 37xx SoC with the the North
> Bridge Power Management component.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> .../devicetree/bindings/arm/marvell/armada-37xx.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> index 51336e5fc761..7ad9830d9177 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> @@ -14,3 +14,22 @@ following property before the previous one:
> Example:
>
> compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
> +
> +
> +Power management
> +----------------
> +
> +For power management (particularly DVFS and AVS), the North Bridge
> +Power Management component is needed:
> +
> +Required properties:
> +- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
> +- reg : the register start and length for the North Bridge
> + Power Management
> +
> +Example:
> +
> +nb_pm: nb_pm at 14000 {
Don't use underscore in node or property names. "syscon" is a better
choice here.
> + compatible = "marvell,armada-3700-nb-pm", "syscon";
> + reg = <0x14000 0x60>;
> +}
> --
> 2.15.0
>
^ permalink raw reply
* [PATCH 2/4] dt-bindings: PCI: dra7xx: Add bindings for unaligned access in host mode
From: Rob Herring @ 2017-12-04 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201061311.16691-3-vigneshr@ti.com>
On Fri, Dec 01, 2017 at 11:43:09AM +0530, Vignesh R wrote:
> Update device tree binding documentation of TI's dra7xx PCI controller
> for enabling unaligned mem access as applicable not just in EP mode but
> in host mode as well.
>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
> ---
> Documentation/devicetree/bindings/pci/ti-pci.txt | 5 +++++
> 1 file changed, 5 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 2/4] clk: meson-axg: add clocks dt-bindings required header
From: Rob Herring @ 2017-12-04 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201012452.27086-3-yixun.lan@amlogic.com>
On Fri, Dec 01, 2017 at 09:24:50AM +0800, Yixun Lan wrote:
> From: Qiufang Dai <qiufang.dai@amlogic.com>
>
> Add the required header for the clocks ID dt-bindings
> exported from various subsystem in the Meson-AXG SoC.
>
> Signed-off-by: Qiufang Dai <qiufang.dai@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> include/dt-bindings/clock/axg-clkc.h | 71 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644 include/dt-bindings/clock/axg-clkc.h
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH RFC 1/2] dt-bindings: Add vendor prefix for Brava Home
From: Rob Herring @ 2017-12-04 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512067334-12761-1-git-send-email-jagan@amarulasolutions.com>
On Fri, Dec 01, 2017 at 12:12:13AM +0530, Jagan Teki wrote:
> Added 'brava' as a vendor prefix for Brava Home, Inc.
> which is consumer electronics and IoT company.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH RFC 2/2] arm64: allwinner: a64: Add Brava Keller initial support
From: Rob Herring @ 2017-12-04 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uEdsj=qxUf3O0S0vDqgXgosvBYG6BGbf6cYn3aNreTPaQ@mail.gmail.com>
On Thu, Nov 30, 2017 at 10:36:55PM +0100, Philippe Ombredanne wrote:
> Jagan,
>
> On Thu, Nov 30, 2017 at 7:42 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> []
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> > new file mode 100644
> > index 0000000..f5303a3
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-brava-keller.dts
> > @@ -0,0 +1,244 @@
> > +/*
> > + * Copyright (C) 2017 Jagan Teki <jagan@amarulasolutions.com>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License, or (at your option) any later version.
> > + *
> > + * This library is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
>
> Rather than this long boilerplate, you might want to use the SPDX ids,
> as started by Greg and documented by Thomas.
> Noe that Linus wants the // comment style for the license line, and
> since there is only two line left here I suggest using it for both
> lines.
> You can check also the recent doc patch posted by Thomas (tglx) and
> comments from Linus and Greg.
>
> So I guess you could use this:
>
> > +// Copyright (C) 2017 Jagan Teki <jagan@amarulasolutions.com>
> > +// SPDX-License-Indentifier: (GPL-2.0+ OR MIT)
Other way around. Make SPDX-License-Indentifier the first line.
> NB: what you call X11 is has the MIT license id in the SPDX license list.
Right. That was a common mistake or abiguity in the dts files.
> So you could replace 32 lines by only two lines :) it'[s neat right?
>
> And this would also help as we have tagged already ~15K files, so it
> would help to use this for new files so the amount of cleanup work
> still left does not increase. Thank you for your kind consideration!
I've been nuging folks to do that for a while now. Of course, now we
need to go move the ids to the first line at some point.
Rob
^ permalink raw reply
* [PATCH][v3] dt-bindings: ifc: Update endianness usage
From: Rob Herring @ 2017-12-04 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512029196-7158-1-git-send-email-prabhakar.kushwaha@nxp.com>
On Thu, Nov 30, 2017 at 01:36:36PM +0530, Prabhakar Kushwaha wrote:
> IFC controller version < 2.0 support IFC register access as
> big endian. These controller version also require IFC NOR signals to
> be connected in reverse order with NOR flash.
>
> IFC >= 2.0 is other way around.
>
> So updating IFC binding to take care of both using endianness field.
>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> ---
> Changes for v2: updated subject
> Changes for v3: fixed typo for "big-endian"
>
> Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> index 89427b0..824a2ca 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> @@ -18,8 +18,10 @@ Properties:
> interrupt (NAND_EVTER_STAT). If there is only one,
> that interrupt reports both types of event.
>
> -- little-endian : If this property is absent, the big-endian mode will
> - be in use as default for registers.
> +- little-endian or big-endian : It represents how IFC registers to be accessed.
> + It also represents connection between controller and
> + NOR flash. If this property is absent, the big-endian
> + mode will be in use as default.
My question on the prior version remains. I think if you need to handle
more than just register endianness, that should be done with the
compatible string.
Rob
^ permalink raw reply
* [PATCH 2/2] ahci: mtk: Change driver name to ahci-mtk
From: Tejun Heo @ 2017-12-04 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201104722.17353-1-matthias.bgg@gmail.com>
On Fri, Dec 01, 2017 at 11:47:22AM +0100, Matthias Brugger wrote:
> The driver name "ahci" is already used by the ahci platform driver.
> This leads to the following error:
> Error: Driver 'ahci' is already registered, aborting...
>
> Change the name to ahci-mtk to fix this.
>
> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Applied to libata/for-4.15-fixes.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH v3 16/16] KVM: arm/arm64: Move vcpu_load call after kvm_vcpu_first_run_init
From: Christoffer Dall @ 2017-12-04 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-1-cdall@kernel.org>
From: Christoffer Dall <christoffer.dall@linaro.org>
Moving the call to vcpu_load() in kvm_arch_vcpu_ioctl_run() to after
we've called kvm_vcpu_first_run_init() simplifies some of the vgic and
there is also no need to do vcpu_load() for things such as handling the
immediate_exit flag.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arch_timer.c | 4 ----
virt/kvm/arm/arm.c | 12 +++++-------
virt/kvm/arm/vgic/vgic-init.c | 11 -----------
3 files changed, 5 insertions(+), 22 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 4151250ce8da..801fecfee299 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -839,11 +839,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
return ret;
no_vgic:
- preempt_disable();
timer->enabled = 1;
- kvm_timer_vcpu_load_vgic(vcpu);
- preempt_enable();
-
return 0;
}
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a760ef1803be..991f1aa70fb9 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -622,8 +622,6 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
if (unlikely(!kvm_vcpu_initialized(vcpu)))
return -ENOEXEC;
- vcpu_load(vcpu);
-
ret = kvm_vcpu_first_run_init(vcpu);
if (ret)
goto out;
@@ -631,13 +629,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
if (run->exit_reason == KVM_EXIT_MMIO) {
ret = kvm_handle_mmio_return(vcpu, vcpu->run);
if (ret)
- goto out;
+ return ret;
}
- if (run->immediate_exit) {
- ret = -EINTR;
- goto out;
- }
+ if (run->immediate_exit)
+ return -EINTR;
+
+ vcpu_load(vcpu);
if (vcpu->sigset_active)
sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 62310122ee78..a0688ef52ad7 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -300,17 +300,6 @@ int vgic_init(struct kvm *kvm)
dist->initialized = true;
- /*
- * If we're initializing GICv2 on-demand when first running the VCPU
- * then we need to load the VGIC state onto the CPU. We can detect
- * this easily by checking if we are in between vcpu_load and vcpu_put
- * when we just initialized the VGIC.
- */
- preempt_disable();
- vcpu = kvm_arm_get_running_vcpu();
- if (vcpu)
- kvm_vgic_load(vcpu);
- preempt_enable();
out:
return ret;
}
--
2.14.2
^ permalink raw reply related
* [PATCH v3 15/16] KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN
From: Christoffer Dall @ 2017-12-04 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-1-cdall@kernel.org>
From: Christoffer Dall <christoffer.dall@linaro.org>
Calling vcpu_load() registers preempt notifiers for this vcpu and calls
kvm_arch_vcpu_load(). The latter will soon be doing a lot of heavy
lifting on arm/arm64 and will try to do things such as enabling the
virtual timer and setting us up to handle interrupts from the timer
hardware.
Loading state onto hardware registers and enabling hardware to signal
interrupts can be problematic when we're not actually about to run the
VCPU, because it makes it difficult to establish the right context when
handling interrupts from the timer, and it makes the register access
code difficult to reason about.
Luckily, now when we call vcpu_load in each ioctl implementation, we can
simply remove the call from the non-KVM_RUN vcpu ioctls, and our
kvm_arch_vcpu_load() is only used for loading vcpu content to the
physical CPU when we're actually going to run the vcpu.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
arch/arm64/kvm/guest.c | 3 ---
virt/kvm/arm/arm.c | 9 ---------
2 files changed, 12 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index d7e3299a7734..959e50d2588c 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -363,8 +363,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
{
int ret = 0;
- vcpu_load(vcpu);
-
trace_kvm_set_guest_debug(vcpu, dbg->control);
if (dbg->control & ~KVM_GUESTDBG_VALID_MASK) {
@@ -386,7 +384,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
}
out:
- vcpu_put(vcpu);
return ret;
}
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 8223c59be507..a760ef1803be 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -381,14 +381,11 @@ static void vcpu_power_off(struct kvm_vcpu *vcpu)
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
- vcpu_load(vcpu);
-
if (vcpu->arch.power_off)
mp_state->mp_state = KVM_MP_STATE_STOPPED;
else
mp_state->mp_state = KVM_MP_STATE_RUNNABLE;
- vcpu_put(vcpu);
return 0;
}
@@ -397,8 +394,6 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
{
int ret = 0;
- vcpu_load(vcpu);
-
switch (mp_state->mp_state) {
case KVM_MP_STATE_RUNNABLE:
vcpu->arch.power_off = false;
@@ -410,7 +405,6 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
ret = -EINVAL;
}
- vcpu_put(vcpu);
return ret;
}
@@ -1003,8 +997,6 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
struct kvm_device_attr attr;
long r;
- vcpu_load(vcpu);
-
switch (ioctl) {
case KVM_ARM_VCPU_INIT: {
struct kvm_vcpu_init init;
@@ -1081,7 +1073,6 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = -EINVAL;
}
- vcpu_put(vcpu);
return r;
}
--
2.14.2
^ permalink raw reply related
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